240 likes | 419 Views
An Architecture for Context-Aware Adaptation of Routing in Delay-Tolerant Networks. Agoston Petz , Angela Hennessy, Brenton Walker, Chien -Liang Fok , and Christine Julien. 10 MAR. 2012. GRINDELWALD, SWITZERLAND. Motivation.
E N D
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
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
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
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
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
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
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
Our architecture • General Arch. Our Implementation
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
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
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
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
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
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)
Evaluation (cont.) • Proteus robot shownin evaluation environment
Results (Three-Node) • CANC reached fullrank faster • Due to more efficient use of the link • Much lower overhead~2000 total encodingssent vs. ~6000
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
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
VMT Results • Latency and overhead results
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
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
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
Thanks! • ?/!