Beacon Vector Routing Scalable Point-to-point Routing in Wireless Sensor Networks

1. Beacon Vector RoutingScalablePoint-to-point Routing in Wireless Sensor Networks Rodrigo Fonseca, Sylvia Ratnasamy, David Culler, Scott Shenker, Ion Stoica Sahara Retreat, June 2004

2. Routing in Sensor Networks • Large scale sensor networks will be deployed, and require richer inter-node communication • In-network storage (DCS, GHT, DIM, DIFS) • In-network processing • “Fireworks routing” • Need point-to-point routing to scale • Many nodes • Many flows • Different densities

3. Goals (when we started out) Point-to-point routing that is: • Scalable – low control overhead, small routing tables • Robust – node failure, wireless vagaries • Efficient – low routing stretch

4. Goals (after we started on an implementation) Point-to-point routing that is: • SIMPLE – minimum *required* state, assumptions • Scalable – low control overhead, small routing tables • Robust – node failure, wireless vagaries • Efficient – low routing stretch

5. Scalable routing • Internet scales via address aggregation • Can’t do with sensor networks • On demand flooding • Scales poorly with #nodes, #flows • Tree-based routing (hierarchical) • Fragile for more general many-to-many • Geographic Routing • Scalable • Uses local information, reference to global space

6. Geographic Routing • General algorithm • Nodes know theirs and neighbors’ geo position • Greedy forwarding towards destination position • Fallback mode if greedy fails • Routing gradient • Computable for each neighbor, from coordinates • Local routing state, local control traffic • What if geographic information is not available?

7. Beacon Vector Routing • Solution: fake geography • Create a routing gradient from connectivity information rather than geography • Nodes assigned positions based based on connectivity • Greedy forwarding on this space • Other approaches • NoGeo, GEM • Landmark Routing, Ascent

8. Outline (from here on) • Beacon-Vector Routing • Algorithm • Evaluation • Simulation • Real implementation

9. Beacon-Vector: Algorithm • 3 pieces • Deriving positions • Forwarding rules • Lookup: mapping node IDs  positions • Will not talk about this today

10. Beacon-Vector: deriving positions • r beacon nodes (B0,B1,…,Br) flood the network; a node q’s position, P(q), is its distance in hops to each beacon P(q) =  B1(q), B2(q),…,Br(q)  • Node p advertises its coordinates using the k closest beacons (we call this set of beacons C(k,p)) • Nodes know their own and neighbors’ positions • Nodes also know how to get to each beacon

11. Beacon-Vector: forwarding • Define the distance between two nodes P and Q as • To reach destination Q, choose neighbor to reduce distk(*,Q) • If no neighbor improves, enter Fallback mode: route towards the beacon which is closer to the destination • If Fallback fails, and you reach the beacon, do a scoped flood

12. 0,3,3 2,1,3 3,0,3 1,2,3 3,1,2 1,3,2 2,2,2 2,3,1 3,2,1 3,3,0 Simple example B1 B2 B3

13. D=4 D=4 D=2 D=2 Fallback towards B1 D=4 D=4 D=4 D=4 Simple example Route from 3,2,1 to 1,2,3 B1 B2 0,3,3 2,1,3 3,0,3 1,2,3 3,1,2 1,3,2 2,2,2 2,3,1 3,2,1 3,3,0 B3

14. Evaluation - Simulation • Packet level simulator in C++ • Simple radio model • Circular radius, “boolean connectivity” • No loss, no contention • Larger scale, isolate algorithmic issues

15. Evaluation - Implementation • Real implementation and testing in TinyOS on mica2dot Berkeley motes • 4KB of RAM! • Judicious use of memory for neighbor tables, network buffers, etc • Low power radios • Changing and imperfect connectivity • Asymmetric links • Low correlation with distance • Two testbeds • Intel Research Berkeley, 23 motes • Soda Hall, UCB, 42 motes

16. Simulation Results

17. Effect of the number of beacons BVR, 3200 nodes Can achieve performance comparable to that using true positions

18. Scaling the number of nodesNumber of beacons needed to sustain 95% performance Beaconing overhead grows slowly with network size (less than 2% of nodes for larger networks)

19. Effect of Density Great benefit for deriving coordinates from connectivity, rather than positions

20. Scope of floods

21. Other results from simulation • Stretch was consistently low • Less than 1.1 in all tests • Performance with obstacles • Modeled as walls in the network ‘arena’ • Very low sensitivity for obstacles, differently from geographic forwarding

22. Simulation Results • Performance similar to that of Geographic Routing (small fraction of floods) • Small number of beacons needed (<2% of nodes for over 95% of success rate w/o flooding) • Scope of floods is small • Resilient to low density and obstacles • Low stretch

23. Implementation Results

24. Routing performance • Soda Testbed, 3100+ random pairs • 88.4% success w/o flood • 4.57% flood (avg. dist 2.6) • 0.5% stuck (no good neighbor to forward) • 6.5% drops (contention and radio drops)

25. Coordinate stability • Coordinates were found to be very stable • E.g., almost 80% of the nodes had 2 or fewer changes, and over 90% of the changes were smaller than 3 hops

26. Implementation Results • Success rates and flood scopes agree with simulation • Sustained high throughput (in comparison to the network capacity) • Coordinates were found to be stable • Few changes observed, small changes

27. Conclusions and Future Work • BVR is simple, robust to node failures, scalable, and presents efficient routes • Using connectivity for deriving routes is good for low density/obstacles • The implementation results indicate that it can work in real settings • We still need to • Better study how performance is linked to radio stability, and to high churn rates • Implement applications on top of BVR

28. Thank you

29. Backups

30. Implementation (1/3) • Link Estimation • Passive link estimation: count missed and xmitted packets, exponential moving average • Link cache: can’t store all neighbors, have to select best neighbors • Neighbor selection • Chicken and egg problem: want to store best quality neighbors, but to get quality, have to store neighbor info.

31. Implementation (2/3) • Distance estimation • How to determine the number of hops to the beacon? • We maintain a tree rooted at each beacon, optimizing for good quality paths from the nodes to the root • Distance is depth in each tree

32. Implementation (3/3) • Route selection • Neighbors are sorted by distance to destination, link quality • Link level acks are used (max 5) • If transmission fails (no ack), choose next best, or fallback node

33. Beacon-Vector Routing: forwarding bvr_forward(node D, pkt P) { // first try greedy forwarding node N = neighbor with MIN distk(N,D) if( distk(N,D) < MIN_DIST from pkt P) pkt P.MIN_DIST = distk(N,D) return N // greedy failed, use fallback fallback_bcn = beacon closest to D if(fallback_bcn != me) return parent(fallback_bcn) // fallback failed flood with scope Bfallback_bcn(D) }

34. Obstacles • Network size is 200x200 units • Numbers indicate success rate without flood for BVR, and success rate of greedy geographic routing in parenthesis () • BVR much less sensitive to obstacles

35. Metrics • Success rate without flood • How often flooding is not required • Flood scope • Maximum distance of flood from beacon • Path stretch • Number of hops taken over path length of greedy routing with true positions • Load • Messages forwarded per node

36. Settling on 10 routing beacons Can achieve performance comparable to that using true positions Effect of the number of beacons