An Architecture for Context-Aware Adaptation of Routing in Delay-Tolerant Networks

1. An Architecture for Context-Aware Adaptation of Routingin Delay-Tolerant Networks AgostonPetz, Angela Hennessy, Brenton Walker, Chien-Liang Fok, and Christine Julien 10 MAR. 2012 GRINDELWALD, SWITZERLAND

2. Motivation • Prior work on network-coded routing for DTN2 suffered from “unintelligent” contact utilization • Led to wasted bandwidth due to • Lack of regard for the relative information diversity of different nodes • Lack of awareness of who should control the channel during contacts • In general, this is a problem for all DTN routing protocols • Unless they specifically build in such intelligence

3. Motivation (cont.) • Many routing protocols utilize context to minimize overhead • Each has specific mechanisms (e.g. RIB in Prophet) We are motivated by a desire to unify router intelligence into a framework that can be used to adapt many different protocols across a wide range of available context

4. Context for DTN Routing • In general, any data relevant to the performance of routing protocols • Lots of applicable context is not easily accessible from within BP and router implementations, some is* • E.g. location, destination, speed, comm. capabilities, battery life, decoding matrix rank*, cache size* • Aggregating “network” specific context requires a context-sharing mechanism • We rely on sharing context world viewswhen nodes meet • World View holds entire collection of relevant context

5. Network-Coding in DTNs • Send linear combinations of fragments • A receiver can collect any ten pieces and recover data 1MB 1MB 1MB 1MB 1MB 1MB 1MB 1MB 1MB 1MB Joe ∑ 1MB 1MB 1MB 1MB 1MB 1MB 1MB 1MB 1MB 1MB 1MB 1MB 1MB 1MB 1MB sam bob amy

6. Context-based adaptation • Accomplished by means of a Context Agent • CA aggregates context and makes routing adaptation decisions • And an adaptation portal through which the internals of DTN routers can be cleanly exposed to external applications • Accomplished by means of the TCL-based command line interface of DTN2

7. Why not use the external router? • DTN2’s external router interface is similar • However, the unit of control is the individual bundle • The ER only allows for decisions to be made on a per-bundle and per-contact basis • We wanted to make higher-level adaptation decisions • Across multiple simultaneous links • Across different interfaces (for multiple PHY technologies) • Per GUID, potentially thousands of bundles • * Some of this is specific to network coding, but much is generally applicable as well

8. Our architecture • General Arch. Our Implementation

9. Context Agent • Aggregates and adapts to context information • Multi-threaded design able to collect context two ways • Either acting as client to fetch context or periodically sample some value OR • Acting as a server which listens for observations • Our CANC Context Agent collects • Geo-Context: by listening for location updates from our mobility service (Pharos Testbed Controller) • Route-Context: by proactively sampling GUID and decoding matrix rank through the Adaptation Portal

10. Context ``World-View’’ • Consists of geo-tagged and time-stamped tuples of context information stored in a map of the network • E.g. { type : value } • For example: { decode-rank : 300/1000 } • Periodically shared with nearby nodes • Using context beacons • World-views are merged to produce a local view of the global network state • Values with the latest timestamp replace older observations

11. World-View (cont.) • An example for network coded routing • Area split into grid • Ranks of all observed static nodesare stored in grid • Embodies DTN “communities” or“relatively-static” ad-hoc networks • Eventually (through merging) all nodes are able to learn the locations of source, sink, and otherstatic nodes

12. Adaptation Portal • Implemented through DTN2’s TCL Command Line Interface • Router-Specific • Any implementation needs • Router specific adaptationroutines (to tweak internals)hooked to TCL CLI • Example: NC Adaptation • Mechanisms are not independent Adaptation Mechanisms for NC

13. Context-based rate adaptation • Destination and ‘role’aware protocol • Learns the location ofthe source and sinkthrough the world-view • Adapts the encodingrate between a pair ofnodes ‘CANC’ Adaptation Rules

14. Evaluation using mobile nodes • Compared CANC Router with non-adaptive network coding router (SimpleNC) • Using autonomous mobile robots from the PharosTestbed • Indoor tests due to inclement whether • Camera-based line-following for navigation • Linux v.2.6 with x86 motherboards • Commodity Atheros 802.11b/g wireless cards (very poor range indoors due to proximity to ground)

15. Evaluation (cont.) • Proteus robot shownin evaluation environment

16. Experimental Setup

17. Results (Three-Node) • CANC reached fullrank faster • Due to more efficient use of the link • Much lower overhead~2000 total encodingssent vs. ~6000

18. Results (Five-Node) • Mule and Sourceomitted for clarity • Even larger latency gains than 3-nodeexperiment • Overhead gains • ~7000 encodings for CANCR vs. ~17000 for SimpleNC

19. VMT Results • Performed same experiment with Virtual Mesh Test (VMT) mobile wireless testbed • Commodity wireless hardware with an emulated channel • Mobility physically emulated using hardware attenuators to mimic path-loss (based on expected path loss calculation) • Very similar results to Pharos experiments • In terms of decoding matrix rank vs. time • Greater repeatability allowed us to reason about standard deviation

20. VMT Results • Latency and overhead results

21. Conclusion • Context-based adaptation improves efficiency and latency • Verified for network coded routing • Hypothesis: it will work for other routers as well • Flexible context agent allows for aggregation of many types of context • Architecture splits context adaptation from the Bundle Protocol Framework • DTN2 adaptation portal allows for access to router internals

22. Future Work • Creating better and more efficient world views • More efficient sharing • Bloom filter-based compression using Grapevine • Better merging algorithms • Establishing ‘trust’ based on multiple conflicting reports • Decaying trust to account for stale observations • Path-aware geographical context • Use a mule’s intended path to predict information diversity

23. Future Work (cont.) • Code Release • Proof-of-concept perl code is ugly • We are re-coding the Context Agent in Python • Adding mechanism for users to add rules to control adaptation

24. Thanks! • ?/!