Beacon Vector Routing: Scalable Point-to-Point Routing in Wireless Sensornets

Beacon Vector Routing: Scalable Point-to-Point Routing in Wireless Sensornets R. Fonseca, Berkeley; S. Ratnasamy, Intel Research; J. Zhao, ICI; C. T. Ee, D. Culler, S. Shenker, and I. Stoica, Berkeley NSDI 2005

The BVR Algorithm Algorithm in three distinct parts: Greedy forwarding Fallback Mode Scoped Flooding

The BVR Algorithm Define location based on number of hops to the routing beacons Each node stores its location as a vector of hop counts. P(q) = <q1,q2,q3,…qr> e.g. <5,1,6,4,3,5,7,9,3> Packets are routed based on these vectors

The BVR Algorithm Nodes retain the position of their neighboring nodes. A nodes neighborhood is the collection of nodes one hop away, for most nodes.

The BVR Algorithm The algorithm compares the difference between the packet’s destination and the current node’s neighbors. Distance function Main Rule: Minimize the sum of the differences for the beacons that are closer to the destination d than to the current routing node p Ties in the Above are broken by this rule: Minimize the sum of the distances to the farther beacons

BVR Algorithm

Algorithm in operation

4 <2,5,8> <3,4,4> <1,4,6> 1 5 6 b1 <2,3,4> <0,3,6> 3 2 <1,4,7> <1,2,5> 15 7 <4,4,3> <1,3,3> 14 8 <5,3,2> <5,2,1> <4,1,2> 12 10 9 13 Beacon b2 b3 Source 11 <5,2,3> Destination

4 <2,5,8> <3,4,4> <1,4,6> 1 5 6 b1 <2,3,4> <0,3,6> 3 2 <1,4,7> <1,2,5> 15 7 <4,4,3> <1,3,3> 14 8 <5,3,2> <5,2,1> <4,1,2> Hop 1: - only one decision 12 10 9 13 Beacon b2 b3 Source 11 <5,2,3> Destination

4 <2,5,8> <3,4,4> <1,4,6> 1 5 6 b1 <2,3,4> <0,3,6> 3 2 <1,4,7> <1,2,5> 15 7 <4,4,3> <1,3,3> 14 8 <5,3,2> <5,2,1> <4,1,2> Hop 2: 1:<0,2,6> = 8 3:<0,0,4> = 4 Choose node 3 12 10 9 13 Beacon b2 b3 Source 11 <5,2,3> Destination

4 <2,5,8> <3,4,4> <1,4,6> 1 5 6 b1 <2,3,4> <0,3,6> 3 2 <1,4,7> <1,2,5> 15 7 <4,4,3> <1,3,3> 14 8 <5,3,2> <5,2,1> <4,1,2> Hop 3: 2:<0,1,5> = 6 4:<0,1,4> = 5 7:<0,1,3> = 4 Choose node 7 12 10 9 13 Beacon b2 b3 Source 11 <5,2,3> Destination

4 <2,5,8> <3,4,4> <1,4,6> 1 5 6 b1 <2,3,4> <0,3,6> 3 2 <1,4,7> <1,2,5> 15 7 <4,4,3> <1,3,3> 14 8 <5,3,2> <5,2,1> <4,1,2> Hop 4: 3:<0,0,4> = 4 5:<0,0,2> = 2 8:<0,0,2> = 2 -> tie! 12 10 9 13 Beacon b2 b3 Source 11 <5,2,3> Destination

4 <2,5,8> <3,4,4> <1,4,6> 1 5 6 b1 <2,3,4> <0,3,6> 3 2 <1,4,7> <1,2,5> 15 7 <4,4,3> <1,3,3> 14 8 <5,3,2> Reverse metrics: 5:<3,0,0> = 3 8:<3,2,0> = 5 Choose 5 <5,2,1> <4,1,2> Hop 4: 3:<0,0,4> = 4 5:<0,0,2> = 2 8:<0,0,2> = 2 -> tie! 12 10 9 13 Beacon b2 b3 Source 11 <5,2,3> Destination

4 <2,5,8> <3,4,4> <1,4,6> 1 5 6 b1 <2,3,4> <0,3,6> 3 2 <1,4,7> <1,2,5> 15 7 <4,4,3> <1,3,3> 14 8 <5,3,2> <5,2,1> <4,1,2> Hop 5: 4:<0,1,4> = 5 6:<0,1,2> = 3 7:<0,1,3> = 4 Choose node 6 12 10 9 13 Beacon b2 b3 Source 11 <5,2,3> Destination

4 <2,5,8> <3,4,4> <1,4,6> 1 5 6 b1 <2,3,4> <0,3,6> 3 2 <1,4,7> <1,2,5> 15 7 <4,4,3> <1,3,3> 14 8 <5,3,2> <5,2,1> <4,1,2> Hop 6: 5: <0,0,2> = 2 15: <0,1,1> = 2 -> tie! 12 10 9 13 Beacon b2 b3 Source 11 <5,2,3> Destination

4 <2,5,8> <3,4,4> <1,4,6> 1 5 6 b1 <2,3,4> <0,3,6> 3 2 <1,4,7> <1,2,5> 15 7 <4,4,3> <1,3,3> 14 Reverse metrics: 5: <3,0,0> = 3 15: <1,0,0> = 1 Choose 15 8 <5,3,2> <5,2,1> <4,1,2> Hop 6: 5: <0,0,2> = 2 15: <0,1,1> = 2 -> tie! 12 10 9 13 Beacon b2 b3 Source 11 <5,2,3> Destination

4 <2,5,8> <3,4,4> <1,4,6> 1 5 6 b1 <2,3,4> <0,3,6> 3 2 <1,4,7> <1,2,5> 15 7 <4,4,3> <1,3,3> 14 8 <5,3,2> <5,2,1> <4,1,2> Hop 7: 14: <0,0,0> = 0 Found node! 12 10 9 13 Beacon b2 b3 Source 11 <5,2,3> Destination

BVR: Fallback Mode It is possible for greedy forwarding to fail. This happens when no neighbor would improve the minimum distance metric When this happens the protocol uses fallback mode

BVR: Fallback Mode Forward packet towards the beacon closest to the destination Parent goes back to forwarding normally: first with greedy forwarding and then fallback mode

BVR: Scoped Flooding When fallback mode fails the algorithm resorts to scoped flooding In scoped flooding the node knows the number of hops away the destination is, but not the direction Floods only the number of hops needed

Example: non-ideal case Example where algorithm resorts to flooding

b2 <3,0> <2,1> <0,3> <3,1> b1 <1,3> <2,2> <1,2> <3,4> <2,3> Beacon Source Destination

b2 <3,0> <2,1> <0,3> <3,1> b1 <1,3> <2,2> <1,2> Calculate forward: <1-3,3-4> = <0,0> <1-3,2-4> = <0,0> Calculate reverse: <3-1,4-3> = <2,1> <3-1,4-2> = <2,2> <3,4> <2,3> Beacon Source Destination

b2 <3,0> <2,1> <0,3> <3,1> b1 <1,3> <2,2> <1,2> Calculate forward: <1-3,3-4> = <0,0> <1-3,2-4> = <0,0> Calculate reverse: <3-1,4-3> = <2,1> <3-1,4-2> = <2,2> <3,4> <2,3> Beacon Would forward to <1,3>, but not closer then where we’ve already been. Initiate scoped flooding for 3 units away. For such a small network, touches every node. Source Destination

Adding another beacon fixes problem b2 <3,0,3> <2,1,2> <0,3,2> <3,1,4> b3 b1 <1,3,3> <2,3,0> <2,2,4> <1,2,1> Calculate forward: <3-3,1-4,4-1> = <0,0,3> <1-3,3-4,3-1> = <0,0,2> <3,4,1> <2,3,2> Beacon Source Destination

Adding another beacon fixes problem b2 <3,0,3> <2,1,2> <0,3,2> <3,1,4> b3 b1 <1,3,3> <2,3,0> <2,2,4> <1,2,1> Calculate forward: <0-3,3-4,2-1> = <0,0,1> <2-3,3-4,2-1> = <0,0,1> <2-3,3-4,0-1> = <0,0,0> <3,4,1> <2,3,2> Beacon Source Destination

Adding another beacon fixes problem b2 <3,0,3> <2,1,2> <0,3,2> <3,1,4> b3 b1 <1,3,3> <2,3,0> <2,2,4> <1,2,1> Calculate forward: <1-3,2-4,1-1> = <0,0,0> <3-3,4-4,1-1> = <0,0,0> Tie! Calculate reverse: <3-1,4-2,1-1> = <2,2,0> <3-3,4-4,1-1> = <0,0,0> -> forward to destination <3,4,1> <2,3,2> Beacon Source Destination

Location Directory How does the sender get the coordinates of the destination? Like a DNS service. Submits node ID Responds with location Hash function correlates nodes with certain beacons Beacons must store all thestate data of the nodes associated with it

Beacon Vector Routing: Scalable Point-to-Point Routing in Wireless Sensornets