1 / 54

Taming the Underlying Challenges of Reliable Multihop Routing in Sensor Networks

Taming the Underlying Challenges of Reliable Multihop Routing in Sensor Networks. Alec Woo, Terence Tong, David Culler SenSys 2003. Key Observations. Many wireless links are lossy Loss rate may change dynamically Environmental factors Highly correlated behavior of an application

callia
Download Presentation

Taming the Underlying Challenges of Reliable Multihop Routing in Sensor Networks

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Taming the Underlying Challenges of Reliable Multihop Routing in Sensor Networks Alec Woo, Terence Tong, David Culler SenSys 2003

  2. Key Observations • Many wireless links are lossy • Loss rate may change dynamically • Environmental factors • Highly correlated behavior of an application • Routing should consider these underlying factors • A lot of existing work on routing are based on abstract MAC & physical layer model • Simply assume 802.11 takes care of MAC layer issues

  3. Contributions • Empirical link quality observation • Connectivity analysis • Likelihood of the success of a communication • Distance, residual energy, congestion, channel contention,… • Link quality estimation • Neighborhood management • Routing for periodic data collection applications

  4. Empirical Observation of Link Characteristics • Measure loss rates between many different pairs of nodes at different distances • Starting point for development of a practical topology formation and routing • A sequence of linearly arranged sensor nodes with a spacing of 2 feet • One transmitter sends packets 200 packets at the rate of 8 packets/sec • Remaining nodes counts the number of successfully received packets • Environment? Indoor? Outdoor? Obstacles??

  5. Empirical Results

  6. A simple probabilistic means can be used to capturethe link behavior in simulations • Connected region • Transitional region: link probability with mean & variance from the empirical data • Disconnected region

  7. References • Spherical radio range assumption in current research • Localization, Sensing Coverage, Topology Control • Radio Irregularity • Deepak Ganesan, etc., “Complex Behavior at Scale: An Experimental Study of Low-Power Wireless Sensor Networks” , UCLA/CSD-TR 02-0013, 2002 • Alberto Cerpa, etc., “SCALE: A Tool for Simple Connectivity Assessment in Lossy Environments”, CENS-TR 03-0021, 2003 • Jerry Y. Zhao, etc., “Understanding Packet Delivery Performance in Dense Wireless Sensor Network”, ACM SenSys, 2003 • Alec Woo, etc., “Taming the Underlying Challenges of Reliable Multihop Routing in Sensor Networks”, ACM SenSys, 2003 • DOI Concept • Tian He, etc., “Range-Free Localization Schemes in Large Scale Sensor Networks”, MobiCom, 2003

  8. Link Estimation • Individual nodes estimate link quality by observing packet success and loss events • Usethe estimated link quality as the cost metric for routing • Good estimator should: • React quickly to potentially large changes in link quality • Stable • Small memory footprint • Simple, lightweight computation

  9. WMEWMA • Snooping • Track the sequence numbers of the packets from each source to infer losses • Window mean with EWMA • WMEWMA(t, a) = (#packets received in t) / max(#packets expected in t, packets received in t) • t, a: tuning parameters • t: #message opportunities • Take average in a window • Take EWMA of the average

  10. WMEWA (t =30, a =0.6)

  11. Neighborhood Management • Neighborhood table • Record information about nodes from which it receives packets • MAC address, routing cost, parent address, child flag, reception (inbound) link quality, send (outbound) link quality, link estimator data structures • Propagate back to the neighbors as the outbound rather than inbound link quality is needed for cost-based routing • The receiving node may update its own table based on the received information possibly indicating topology changes  Distance-vector based routing • How does a node determine which nodes it should keep in the table? • Keep a sufficient number of good neighbors in the table • Similar to cache management

  12. Background: Distance vector routing • Link state routing algorithm • Assume knowledge of the network topology and all link costs • Apply Dijkstra algorithm to find the shortest path from one source to all the other nodes • Implemented via link state broadcast [Perlmann 1999] • Distance vector routing • Iterative, distributed, asynchronous algorithm • Receive from immediate neighbors • Perform a calculation and broadcast the result back to the neighbors • Also called Bellman-Ford algorithm • For example, look up http://en.wikipedia.org/wiki/Distance-vector_routing_protocol

  13. Management Policies • Insertion • Heard from a non-resident source • Adaptive down-sampling technique • Probability of insertion =N/T = neighbor table size / #distinct neighbors • At most N messages can be inserted for every T messages • Eviction • FIFO, Least-Recently Heard, CLOCK, Frequency

  14. Frequency Algorithm Keep a frequency count for each entry in the table Reinforce a node by incrementing its count A new node will be inserted if there is an entry with a zero count Otherwise, decrement the count of all entries and drop the new candidate #Good neighbors maintainable (table size 40)

  15. Cost-based routing • Key ideas • Minimize the cost that is abstract measure of distance • Could be #hops, #retransmissions, etc. • Minimize #retransmissions: A longer path with fewer #retransmission could be better than a shorter path with more retransmissions! • Distance-vector based approach implemented by the parent selection component • Periodically run parent selection to identify one of the neighbors for routing • May also locally broadcast a route message including parent address, estimated routing cost to the sink, and a list of reception link estimations of neighbors • A receiving node mayupdate the neighbor table based on the received info or drop it • Flag a child in the table to avoid a cycle • When a cycle is detected trigger parent selection without the current parent

  16. Routing Framework

  17. Underlying Issues • Parent selection • If connectivity to the current parent is lost, a node disjoins from the tree, and sets its routing cost to infinity  Reselect a parent • Rate of parent change • Periodic: Parent selection for every route update msg from neighbors incurs a domino effect of route changes • Parent snooping • For example, quickly learn routing info • Cycles • Monitor forwarding traffic and snoop on the parent address in each neighbor’s msg -> Identify child nodes and don’t consider them as potential parents

  18. Underlying Issues • Duplicate packet elimination • Use sender address & sequence number • Queue management • Give priority to originating traffic assuming originating data rate is lower than forwarding rate • General fair queuing is not considered in this paper • Relation to link estimation • Link failure detection based on a fixed number of consecutive xmission failures can be ineffective over semi-lossy links • Link quality estimation can be a better judgment of link failure • Bidirectional link estimations can avoid routing over asymmetric links • Stability and agility of link estimators can significantly affect routing • Final tuning must be done while observing its effect on routing performance

  19. Cost metric • MT (Minimum Transmission) metric: • Expected number of transmissions along the path • For each link, MT cost is estimated by 1/(Forward link quality) * 1/(Backward link quality) • Inherently non-linear • For MT, a substantial noise margin should be used in parent select to enhance stability • Reliability • Another cost metric • Product of link qualities along the path • Not explored in this paper

  20. Performance Evaluation: Tested Routing Algorithms • Shortest Path • Conventional distance-vector approach • Each node picks a minimum hop-count neighbor as the parent and set its own hop-count to one greater than its parent • Two variations for performance analysis • SP: A node is a neighbor if a packet is received from it • SP(t): A node is a neighbor if its link quality exceeds the threshold t • t = 70%: only consider the links in the effective region • t = 40%: also consider good links in the transitional region

  21. Performance Evaluation: Tested Routing Algorithms • Minimum Transmission (MT) • Use the expected #transmissions as the cost metric • Use a new path if the new cost is lesser by a noise margin • MTTM • Assume a neighbor table can maintain only 20 entries • Broadcast • Root periodically floods the network • A node chooses a parent that forwards the flooded msg to itself first in each epoch • Use the reverse path to reach the root

  22. Performance Evaluation: Tested Routing Algorithms • Destination Sequence Distance Vector (DSDV) • Choose a parent based on the freshest sequence number from the root to avoid a cycle • Maintain a minimum hop count when possible • Ignore link quality: Consider a node a neighbor once heard from it • Periodically reevaluate

  23. Packet level simulations • Built a discrete time, event-driven simulator in Matlab • Network of 400 nodes: 20 * 20 grid with 8 feet spacing • Sink is placed at a corner to maximize the network depth

  24. Packet level simulation Hop Distribution Path reliability over distance

  25. Packet level simulation

  26. Empirical study of a sensor field • Evaluate SP(40%), SP(70%), MT • 50 Berkeley motes inside a building • 5 * 10 grid w/ 8 foot spacing • 90% link quality in 8 feet • 3 inches above the ground

  27. Hop Distribution • SP(70) failed to • construct a routing • tree • - MT congested: Triple the data origination and route update rate • Link Quality of MT • Vary around 70% • SP(70) may suffer

  28. E2E success rate Stability

  29. Irregular Indoor Network • 30 nodes scattered around an indoor office of 1000ft2 Link Estimation of a node to its neighbors over time E2E Success Rate

  30. Conclusions • Link quality estimation and neighborhood management are essential to reliable routing • WMEWMA is a simple, memory efficient estimator that reacts quickly yet relatively stable • MT (Minimum Transmissions) is an effective metric for cost-based routing • The combinations of these techniques can yield high E2E success rates

  31. Beacon Vector Routing: Scalable Point-to-Point Routing in Wireless Sensornets R. Fonseca et al. NSDI ’05

  32. Motivation • Most existing protocols only support basic many-to-one or one-to-many routing primitives (e.g., Directed diffusion, TAG, …) • More point-to-point routing protocols have recently been proposed • Applications: Pursuer-evader game, spatial queries, reactive tasking, multi-dimensional range queries, data centric storage, … • No practical and broadly applicable implementation of point-to-point routing in WSNs

  33. Design Goals • Develop & implement a point-point routing protocol: • Simple with minimal complexity • Make minimal assumptions about radio quality, presence of GPS, … • Use TinyOS tree construction prtocol

  34. Key Ideas • Randomly select a few beacon nodes • Construct trees from the beacons to every other node • Every node knows its distance (#hops) to every beacon by using the standard reverse path tree construction • These beacon vectors serve as coordinates • Apply simple greedy, geographic forwarding

  35. Approach • Nodes periodically send a local broadcast to announce their coordinates • A node q’s position P(q) = <q1, q2, …, qr> where qi is #hops from node q to beacon i • Distance function δ(p, d) to measure how good p would be as a next hop to reach the destination d • Choose a node whose coordinates are more to the sink’s • Move towards a beacon when the destination is closer to the beacon than the current node • Move away from a beacon when the destination is further from the beacon than the current node

  36. Fallback mode • If a node cannot make a progress towards the destination itself, it forwards the packet to the parent in the corresponding beacon tree • A parent does the same thing • First try to apply greed forwarding • If it doesn’t work, rely on the fallback mode • If the closest beacon still cannot find the destination, it does scoped flooding

  37. Beacon maintenance • Route based on the beacons the source and destination have in common • Does not require perfect beacon info. • Each entry in the beacon vector has a sequence number • Periodically updated by the corresponding beacon • Timeout • If the #beacons < r, non-beacon nodes nominate themselves as beacons

  38. Location directory • Depending on the application, a source may first have to look up the destination coordinates by name • Use beacons as storage • Hashing H: nodeid → beaconid [14] • Each node k that wants to be a destination periodically publishes its coordinates to its corresponding beacon bk = H(k) • When a node wants to route to node k, it sends a lookup request to bk • Cache the coordinates

  39. Simulation Results • Assumptions for high level simulation • Fixed circular radio range • Ignore the network capacity and congestion • Ignore packet losses • Place nodes uniformly at random in a square planner region • 3200 nodes uniformly distributed in a 200 * 200 unit area • Radio range is 8 units • Average node degree is 16 • Vary #total beacons and #routing beacons

  40. Greedy success rate

  41. Success ratio given 10 routing beacons

  42. On-demand two hop neighbor acquisition • At lower densities, each node has fewer immediate neighbors • The performance of greedy routing drops • Add a neighbor’s neighbors to the routing table, if greedy forwarding is impossible

  43. #beacons required to achieve less than 5% scoped floods • On-demand two hop neighbor acquistion • Start with one hop neighbors • Fetch neigbor’s neigbors when there’s a void

  44. Performance under obstacles • Place horizontal & vertical walls with lengths of 10 or 20 units when the radio range is 8 units

  45. Prototype evaluation • Office-Net: 42 mica2dot motes in a 20m * 50m office • Univ-Net: 74 mica2dot motes deployed across multiple student offices on a single floor in a UC Berkeley building

  46. Link quality vs. distance • Orthogonal! (in Office-Net) • Contradicts to circular radio assumptions made by geographic routing protocols • BVR is connectivity based

  47. Routing performance in Office-Net • - Success rate > 98% • 1.2% of the reqeusts resulted in scoped flooding • average scope of 2 hops • - Contention drops < 0.1%

  48. Routing performance in Univ-Net • - Success rate > 98% • 5.5% of the reqeusts resulted in scoped flooding • average scope of 2 hops • - Contention drops < 0.1%

  49. Office-Net success rate

  50. Beacon failure • TOSSIM – TinyOS simulator • 100 motes with 8 beacons • Expected node degree of 12 • TOSSIM’s lossy link generator • Based on empirical data to simulate lossy and asymmetric connectivity

More Related