Beacon Location Service A Location Service for Point-to- Point Routing in Wireless Sensor Networks EECS Department University of California, Berkeley Jorge Ortiz, Chris R. Baker, Daekyeong Moon, Rodrigo Fonseca, and Ion Stoica
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Beacon Location ServiceA Location Service for Point-to-Point Routing in
Wireless Sensor Networks
EECS DepartmentUniversity of California, Berkeley
Jorge Ortiz, Chris R. Baker, Daekyeong Moon, Rodrigo Fonseca, and Ion Stoica
2
What's Missing in Point-to-point Routing for Sensornets?
Address space derived from network topology
Routing performed over address space
Application wants to route over name space
Names do not change
Location Service maps names to addresses
3
Point-to-point routing classes
These need a location service!
Geographic coordinates
GPSR, GOAFR+
Virtual coordinates
No-Geo, GEM, BVR, S4
Hierarchical
Landmark
Shortest path based (flood path-discovery)
AODV, DSDV
DHT-based
VRR
4
Location Service Requirements
Provide a mechanism that closes the loop for
point-to-point routing schemes
Added location service traffic should not overload
the network
Point-to-point schemes usually have some amount of
maintenance traffic
Maintain a high overall routing success rate from the
point of view of the application
5
BLS Design Assumptions
Dynamic, topologically derived addresses Each node has a unique name
There exists a set of anchor nodes (beacons)
that all nodes in the network know how to
route to
These nodes are used as the location
servers
6
BLS Basic Design
Single rendezvous point
Distributed set of
lookup serversBA
LS
Publish(B, addr(B))
Send(addr(A),addr(B),data)
Reply(addr(B))
Query(B)
B | addr(B)
7
BLS Implementation Uses Beacon Vector Routing [Fonseca et al,
NSDI '05] as underlying routing layer
Beacons used as location servers
Hash-based rendezvous with global hash function
Same hash function used to publish and query TinyOS implementation
~2.3K memory footprint (BLS)~3500 lines of Code (BVR + BLS)
8
BLS Example
2
3
1
1
2
3
4 56
7
8
9
1011
hash(1)=3
hash(10)=1
hash(6)=2
hash(11)=3
hash(3)=1
hash(9)=3hash(7)=1
hash(4)=2
beacon1
beacon2
beacon3Query(addr(1), addr(8), 9)
hash(9)=3
Reply(addr(8),addr(1),addr(9))Send(addr(1),addr(9),data)
9 | addr(9)
3 | addr(3)7 | addr(7)10 | addr(10)
1 | addr(1)9 | addr(9)11 | addr(11)
2 | addr(2)6 | addr(6)12 | addr(12)
12
hash(12)=2
9
Overview Problem statement and motivation
BLS Design: Assumptions and Choices
Implementation decisions and example
Evaluation
Metrics
Simulation
Parameter tuning and results
Testbed
Overall Performance
Comparison Study: TinyAODV and VRR
Conclusion
10
Evaluation Metrics
Routing success rate
Location service (query and reply)
Total (query and reply and data)
Minimize message overhead on the
network
Minimize query + reply hopcount
distribution
11
Evaluation Simulation
Scale, Parameter Tuning, different topologies
Up to 400 nodes
Random beacon placement
Testbed
Real environment, verify simulation results
Berkeley sMote testbed: 35 mica2dots, 3-4 hop
diameter
Beacons chosen a priori
12
Testbed Topology and Location Server Selection
13
Experimental Setup
BVR Warm-up phase (wait for >90% routing success)
Local cache disabled
No misses at beacon cache
14
Naïve Implementation Results Poor scalability: 200 nodes and 8 beacons yield low
success rate
High success rate with BVR alone for similar setups
Conjecture: Beacons overloaded
Added beacons: 200 nodes and up to 32 beacons
Results remained poor
Logs indicated overall congestion in both cases
Set out to reduce lookup traffic
Aggressive in-network caching
15
Eavesdropping Example
2
3
1
1
2
3
4 56
7
8
9
1011
beacon1
beacon2
beacon3Query(addr(1), addr(8), 9)
hash(9)=3
Reply(addr(8),addr(1),addr(9))Send(addr(1),addr(9),data)
9 | addr(9)
3 | addr(3)7 | addr(7)10 | addr(10)
1 | addr(1)9 | addr(9)11 | addr(11)
2 | addr(2)6 | addr(6)12 | addr(12)
12
hash(12)=2
9 | addr(9)
9 | addr(9)
9 | addr(9)
hash(9)=3
Query + Reply
9 | addr(9)
Send(addr(3),addr(9),data)
16
Eavesdropping Improves Performance and Scalability
Original With Eavesdropping
16.4
17
Eavesdropping Reduces Message Overhead (TOSSIM Results)
16.4% Average MsgReduction
26.8% Average MsgReduction
35 Nodes 100 Nodes
18
BLS Success Rate (Testbed)
19
BLS Hopcount Distribution
(Testbed)Query Reply
Data
20
BLS/BVR vs TinyAODV Comparison Experimental Setup
AODV part of ZigBee standard
Bounded destination set size at 7 to prevent
cache-entry replacement
Vary the number of senders [1, 5, 15, 28]
First request to send to a destination node
invokes path-discovery process (flooding)
21
BLS/BVR Outperforms TinyAODV
BLS TinyAODV
22
BLS/BVR vs VRR Experimental Setup
Virtual Ring Routing [Caesar et al, SIGCOMM '06]
Routes directly to names
Route data packet from random source to
random destination
Varying send rates
23
BLS/BVR Performance Comparable to VRR
Hopcount distribution for simulated cache hit rates
Amortized send cost decreases with increased cache hit rate
24
Conclusion A subset of point-to-point routing schemes need a
location service
Simple design yields comparable performance to
state-of-the-art point-to-point routing schemes
BLS can be used over various beacon-based
routing schemes
Code available soon
26
BLS Hopcount Distribution (Testbed)
27
Summary of Message Overhead with Eavesdropping
TOSSIM: 16.4% reduction in message overhead for 35 nodes
TOSSIM: 26.8% reduction in message overhead
for 100 nodes
Testbed (35 motes): 11% reduction in message
overhead per node
28
DHT Application Successfully Written over BLS/BVR
99% success rate for application send requests
29
Eavesdrop Reduces Message Overhead (Testbed Results)
30
Future work
Caching and Workloads
Mobility and churn
BLS over various beacon-based routing
schemes
More optimizations
31
Extra
BLS and BVR - ~3500 lines of code
BLS and BVR ~3700 bytes of RAM
LRU cache replacement
32
New Title
Management and control of specific nodes (i.e. network health monitoring)
Data Centric Storage Pursuer-Evader application Derived from the topology
33
Experimental Setup (TOSSIM)
Local cache lookup turned off (each send request invokes the BLS lookup process)
Beacon cache size set to large enough to fit all
registered nodes
Warm-up necessary for BVR establishment (link
estimator, neighbor selection, coordinate setup)
>=90% BVR routing success before BLS experiments
started
Beacons randomly placed in TOSSIM simulations
34
Experimental setup (Testbed)
BVR Warmup period
>= 90% BVR routing success rate
UC Berkeley sMote testbed – 35 mica2dots
Network diameter between 3 and 4 hops
Beacons chosen a priori
35
Eavesdropping message overhead
35 Nodes
Testbed Results
TOSSIM
100 Nodes
36
Naïve Implementation Results Results obtained in
TOSSIM
Paths to beacons
congested
Added Beacons to
spread load
Eavesdropping
implemented
37
Tuned Parameters
38
Overview
Point-to-point routing motivation Location service assumptions and design BLS design and implementation Experimental results Conclusion and questions
39
Overview
Point-to-point routing motivation Location service assumptions and design BLS design and implementation Experimental results Conclusion and questions
40
Overview
Point-to-point routing motivation Location service assumptions and design BLS design and implementation Experimental results Conclusion and questions
41
Overview
Point-to-point routing motivation Location service assumptions and design BLS design and implementation Experimental results Conclusion and questions
Related Documents
