Scalable Routing in Sensor Networks

1
Scalable Routing in Sensor Networks

• Sylvia Ratnasamy
• Intel Research Berkeley
• Joint work with Rodrigo Fonseca, Jiong Shen,
  David Culler, Scott Shenker, Ion Stoica
• UCLA, Dec 05, 2003

2
Routing in Sensor Networks

• Assumption Large-scale sensor networks of the
  future
• will require rich inter-node communication
• in-network storage DCS, Dimensions, GHT, DIFS,
  DIM,
• in-network tasking, processing,
• Today, (almost) no ad-hoc routing that scales to
• many nodes
• many flows
• rich communication patterns

3
Scaling Ad Hoc Routing

• Internet scales via address aggregation
• ad hoc networks cant use aggregation
• On-demand flooding
• scales poorly with nodes, communication patterns
• Hierarchical (tree-based) routing
• great for many-to-one fragile for general
  any-to-any
• Only scalable solution geographic routing

4
Geographic Routing

• Basic Approach
• nodes know their own and neighbors geo
  locations
• greedy forwarding to the destinations location
• fallback scheme when greedy fails (e.g., GPSR,
  GEAR, GLS, )
• Scalable local routing state and control traffic
  
• Problem What if this location information is not
  available?

5
Routing without Location Information

• Our approach fake geography
• nodes assigned positions based on connectivity,
  not geography
• regular geographic routing over these positions
• Problem Deriving routable positions from limited
  connectivity information
• Two approaches (at least)
• Embed nodes in a virtual coordinate system GEM,
  NoGeo
• Position nodes relative to some landmark nodes
  LR, Ascent
• Focus of this talk is on (2) will consider
  tradeoffs later in the talk

6
Outline (from here on)

• Beacon-Vector Routing
• Goals
• Algorithm
• Evaluation
• Beacon-Vector vs. GEM/NoGe0
• Disclaimer All this is still very much work in
  progress!!

7
Goals (when we started out)

• Any-to-any routing that is
• Scalable low control overhead, small routing
  tables
• Robust node failure, wireless vagaries
• Efficient low routing stretch

8
Goals (after we started on an implementation)

• Any-to-any routing that is
• SIMPLE minimum required state, assumptions
• Scalable low control overhead, small routing
  tables
• Robust node failure, wireless vagaries
• Efficient low routing stretch

9
Beacon-Vector Algorithm

• 3 pieces
• Deriving positions
• Forwarding rules
• Lookup mapping node IDs ? positions

10
Beacon-Vector deriving positions

• K beacon nodes (B0,B1,,Bk) flood the network a
  node Qs position, Q(K), is its distance in hops
  to each beacon Q(K)B0Q0 , B1Q1 ,, BkQk
  (w.l.o.g. assume Q0 Q1 Qk)
• Define distance between two nodes P and Q as
• dist(k, P, Q) ??iPi Qi where Qi hops
  from beacon I to node Q
• Nodes know their own and neighbors positions to
  reach destination Q, forward to reduce dist(k,,Q)

k i1
11
Beacon-Vector Routing forwarding

• bvr_forward(node Dk, pkt P)
• // first try greedy forwarding
• foreach( i k to 1 )
• node N neighbor with MIN dist(i,N,D)
• if( dist(i,N,D) N
• // greedy failed, use fallback
• fallback_bcn beacon closest to D
• if(fallback_bcn ! me) return parent(fallback_bcn
  )
• // fallback failed
• flood with scope Dfallback_bcn

12
Beacon-Vector Routing details
I

• Observation beacons that pull are good guides
• Beacon weights in distance metric ? ?i Pi Qi
  
• ?i 10 if Pi Qi 1 otherwise
• Need compact node positions to reduce per-packet
  overhead
• For routing, a nodes position is defined by its
  k ( B) closest beacons
• Open question optimal distance metric, weights,
  beacons,

Q
P
13
Routing to Node Identifiers

• Beacon-Vector routes to node positions need a
  lookup mechanism to map node identifiers to
  positions GLS, GHT
• Our solution Use beacons to store mapping
• given a node identifier, use consistent hashing
  to determine which beacon stores its position
• simple, but imposes additional load on beacons
• BVLookup enables routing to any node identifier
  (IP-like)

14
Beacon-Vector recap

• 3 pieces
• Deriving positions B beacons flood the network
• Forwarding rules based on neighbor positions and
  state in packet header
• Lookup beacons store node ID ? position mapping

15
Outline

• Beacon-Vector Routing
• Goals
• Algorithm
• Evaluation
• Beacon-Vector vs. GEM/NoGeo
• Disclaimer All this is still very much work in
  progress!!

16
Evaluation

• High level simulator
• Basic algorithmic evaluation, scale
• C, circular radio cells, binary connectivity
• TOSSIM/Intel Ethernet Testbed (ongoing work)
• prototype implementation evaluation
• realistic packet loss, failure, MAC layer effects

17
Evaluation Metrics

• Performance metrics
• success rate without flooding
• path stretch
• Overhead
• total beacons needed (flooding overhead)
• beacons used for routing (per-packet overhead)
• neighbors (per-node routing table)
• Scalability
• network size
• network density

18
Beaconing overhead
3200 nodes u.a.r in grid Success rate with true
positions 96.3
19
Beaconing overhead
3200 nodes u.a.r. in grid Success rate with
true positions 96.3
success rate 96 (w/o fallback91) avg(ngbrs)
15.0 avg(hops) 17.5, path stretch
1.05 avg(flood hops)3.7 90le load 48 (37 for
true postn)
20
Beaconing overhead
Can achieve performance comparable to that using
true positions
3200 nodes u.a.r. in grid Success rate with
true positions 96.3
Settling on 10 routing beacons
21
Routing State Overhead
3200 nodes, 10 routing beacons
Success rate w/o flooding
1-hop neighbors True postns. (high dens)
96.3 True postns. (lo density) 61.0
beacons
22
Routing State Overhead
3200 nodes, 10 routing beacons
Success rate w/o flooding
1-hop neighbors True postns. (high dens)
96.3 True postns. (lo density) 61.0
Inherent tradeoff between routing state and the
efficacy of greedy routing
beacons
23
Routing state overhead

• Goal high success rate with low per-node
  neighbor state
• Observation local minima
• Mechanism On-demand neighbor acquisition
• node starts with its immediate neighbors
• fetches its neighbors neighbors if it cannot
  forward a packet greedily

24
Routing state overhead
3200 nodes, 10 routing beacons
Success rate w/o flooding
1-hop neighbors True postns. (high dens)
96.3 True postns. (lo density) 61.0
1-hop on-demand 2-hop True postns. (high dens)
99.5 True postns. (lo density) 82.7
beacons
25
Routing state overhead
3200 nodes, 10 routing beacons
avg(neighbors) 17.0 5 nodes go out 2 hops
avg(neighbors) 12.7 15 nodes go out 2 hops
Success rate w/o flooding
1-hop neighbors True postns. (high dens)
96.3 True postns. (lo density) 61.0
1-hop on-demand 2-hop True postns. (high dens)
99.5 True postns. (lo density) 82.7
beacons
26
Routing state overhead
3200 nodes, 10 routing beacons
avg(neighbors) 17.0 5 nodes go out 2 hops
avg(neighbors) 12.7 15 nodes go out 2 hops
Success rate w/o flooding
1-hop neighbors True postns. (high dens)
96.3 True postns. (lo density) 61.0
1-hop on-demand 2-hop True postns. (high dens)
99.5 True postns. (lo density) 82.7
beacons
Augmenting routing state on demand is a big win!
27
Scaling Network Size
3200 nodes, 10 routing beacons
Beacons for 95 success rate
50
200
800
3200
12800
Network size
Beaconing overhead grows slowly with network size
28
Evaluation summary

• Beacon-Vector performance
• overhead scales well with network size and
  density
• outperforms true geography at lower densities
• Other results
• probabilistic connectivity 2-3 degradation
• obstacles upto 40 improvement relative to true
  positions
• shapes circle, cross, star layouts
• Many open questions remain
• Robustness under failure (TOSSIM)
• Prototype evaluation (Intel testbed)

29
Robustness

• 2 main concerns
• Node failure can trigger re-labeling
• Hopefully rare (at reasonable densities), and
  incremental
• While in flux, can leave breadcrumbs at the
  closest beacon to update stale destination
  positions
• Beacon failure
• Expire coordinates
• Flux Ignore beacon if nodes have inconsistent
  views
• Replacement beacon via preconfigured ordering
• Ongoing evaluation to validate the above intuition

30
Implementation current status

• Prototype in TinyOS for the Mica2 motes
• exports a route-to-coordinates interface
• assumes preconfigured and perennial beacons
• Currently testing on the Intel Lab testbed and
  under TOSSIM
• small scale (20 motes) but comprehensive logging
• Sample (and only ?) implementation result 20
  nodes, 4 beacons

31
Outline

• Beacon-Vector Routing
• Goals
• Algorithm
• Evaluation
• Beacon-Vector vs. GEM/NoGeo
• Disclaimer All this is still very much work in
  progress!!

32
NoGeo

• Basic approach
• embed nodes in a virtual coordinate space (e.g.,
  2d Cartesian)
• space is a well-defined, global frame of
  reference
• GEM similar approach, different algorithm
• Constructing this virtual coordinate space is
  non-trivial
• NoGeo requires perimeter detection and layout
• GEM requires patching voids in the space
• For routing, Beacon-Vector is simpler
• However, one of the primary motivations behind
  NoGeo/GEM was to support data-centric storage

33
Data-Centric Storage (DCS) background

• Store data, by name, within the sensor network
• associate datas name with a node
• user queries routed to the associated storage
  node
• Interface
• Put(k,v) stores v, the data value, according to
  key k
• Get(k)retrieves the value associated with key k
• Essentially a Distributed Hash Table (DHT) on a
  sensor network
• actively researched (3yrs) in the context of the
  Internet

34
DCS over NoGeo/GEM

• Mechanism
• Hash data names to coordinates in the virtual
  space
• Use GEM/NoGeo to route to these coordinates
• Store data at the node closest to these
  coordinates
• Simple
• little added mechanism over and above regular
  routing
• DCS over Beacon-Vector follows a different
  approach

35
DCS over Beacon-Vector Routing

• Internet DHTs overlay topology that forms a
  virtual space
• IP connects nodes in the overlay (logical ?
  physical links)
• BVLookup enables routing to node identifiers
• like IP, but on a sensornet
• Hence, can use standard Internet DHT algorithms
  to overlay a DHT on a sensor network
• Feasible, but not necessarily trivial
• added mechanism for DHT overlay maintenance
• non-optimal DHT paths

36
Beacon-Vector vs. NoGeo/GEM summary

• NoGeo/GEM embed nodes in a virtual coordinate
  space
• Forming this space is non-trivial
• However, given this space, supporting DCS is
  simple
• Beacon-Vector landmarks, but no global
  coordinate space
• Routing is easy
• Building a DHT is more complex
• Open question Is there a middle ground? Define a
  global frame of reference based on beacon
  positions?

37
Conclusion

• Coordinate-based routing is scalable
• local state with greedy forwarding
• no route setup, discovery
• Can derive routable coordinates even without
  location information
• Different emerging approaches to deriving
  coordinates
• embedding in a virtual space
• positioning relative to landmarks
• still need to fully understand the tradeoffs
  involved

38
Backup
39
Scope of flood for failed routes
40
Routing state overhead
3200 nodes, 50 beacons, 10 routing beacons
Number of neighbors
Success rate w/o floodingh
similarity threshold
similarity threshold
41
Scaling Network Size
10 routing beacons avg(ngbrs) 15.0
Beacon nodes for 95 success rate
50
200
800
3200
12800
Network size
42
Probabilistic connectivity

• 3200 nodes without 2-hops on-demand
• Prob1.0 for d radioRange/2 d 1.5radioRange 0.0
  otherwise
• Success rate 94.8, avg(nbrs)16.0
• Prob1.0 for d linearly radioRange/2 d 1.5radioRang 0.0
  otherwise
• Success rate 97.0, avg(nbrs)16.7
• Prob1.0 for d radioRange/2 d 1.5radioRange 0.0
  otherwise
• Success rate 89.0, avg(nbrs)11.0

43
Obstacles
3200 nodes placed u.a.r. in a 200 200 grid
BV success rate (success rate with true positions)
44
Implementation architecture
Replicates pkts sent/rcvd
Outgoing queue
Promiscuous mode
45
Implementation current status

• Prototype in TinyOS for the Mica2 motes
• exports a route-to-coordinates interface
• Routing state maintenance
• Assumes preconfigured and perennial beacons
• Bidirectional loss-driven link estimation
• Beacons flood periodically tree constructed
  using link estimates
• Nodes periodically beacon their immediate
  neighbors
• Currently testing on the Intel Lab testbed and
  under TOSSIM
• small scale (15 motes)
• complete, ordered logging via Ethernet backend

46
DHTs on the Internet

• Approach
• Nodes form an overlay topology that represents a
  virtual geometry
• Data name mapped to a point in the geometric
  space stored at the node assigned to that
  portion of the space
• DHT overlay construction
• geometry dictates connectivity within the overlay
  (logical links)
• IP connects nodes at the logical level (logical
  ? physical link)
• Hence, can route through the geometric space