Practical Asynchronous Neighbor Discovery - PowerPoint PPT Presentation

1 / 34
About This Presentation
Title:

Practical Asynchronous Neighbor Discovery

Description:

How can two systems that are. rarely co-located. awake infrequently ... Disco: a new asynchronous neighbor discovery algorithm ... – PowerPoint PPT presentation

Number of Views:65
Avg rating:3.0/5.0
Slides: 35
Provided by: eecsBe
Category:

less

Transcript and Presenter's Notes

Title: Practical Asynchronous Neighbor Discovery


1
Practical Asynchronous Neighbor Discovery and
Rendezvous for Mobile Sensing Applications
Prabal Dutta and David Culler
Computer Science Division University of
California, Berkeley prabal,culler_at_cs.berkeley.e
du
Sensys08 Raleigh, NC Nov. 5-7, 2008
2
Mobility makes energy and communication
challenges fundamentally harder
  • Energy
  • Must carry it along with the node
  • Or harvest it from the ambient environment
  • And deal with inherent uncertainty of harvesting
  • Link dynamics
  • Link. What link?
  • Never before seen link
  • What radio channel?
  • When to look?
  • Cant just probe during deployment
  • History is a poor guide
  • History is no guide

Weather mobility uncertain energy budget -
Jacob Sorber, Sensys 2007
J. Sorber et al., Eon A Language and Runtime
for Perpetual Systems, Sensys07, Sydney,
Australia
3
Mobility makes asynchronous neighbor discovery
a fundamental problem
  • The asynchronous neighbor discovery problem
  • How can two systems that are
  • rarely co-located
  • awake infrequently
  • operating with independent duty cycles
  • discover each other
  • without prior knowledge of potential encounters
  • without external assistance?

4
Emerging class of low-power mobile sensing
applications
Three interaction patterns.
Three operating regimes symmetric, asymmetric,
hybrid
Docking
Flocking
Talking
Liu04
Wark07
UP08
Malinowski07
Eisenman08
Choudury04,07
Borriello04
Huang05
Huang05
Huang05
5
Some asynchronous neighbor discovery techniques
exist
m
  • Quorum Tseng02
  • Divide time into m x m intervals
  • Listen during a column
  • Transmit during a row
  • Rendezvous at their intersection
  • Used by LPL (B-MAC, X-MAC)
  • Listen periodically (m Tlisten)
  • Transmit long preambles or same packet
    repeatedly, periodically (ETlisten/2)
  • Rendezvous when these listen and transmit times
    overlap
  • Overhearing problem

2
1
4
3
6
5
8
7
10
9
12
11
14
13
16
15
18
17
m
20
19
22
21
24
23
26
25
28
27
30
29
32
31
34
33
36
35
CCA O(15 ms) in T2
But requires global agreement on the minimum node
duty cycle (B-MAC) or unclear termination
condition (X-MAC)
T
L
R
t
6
Variations on a theme
m
t
  • Quorum Tseng02
  • Listen during a row
  • Transmit during a column
  • Used by some TDMA protocols
  • Global agreement on duty cycle

T
m
L
R
  • Birthday McGlynn01
  • Randomly choose to listen, transmit or be idle
    (sleep)
  • Not deterministic
  • Combinatoric Zheng03
  • Requires symmetric design
  • Asymmetric schedule NP hard
  • Not distributed

7
Disco a new asynchronous neighbor discovery
algorithmthat is fully distributed and allows
local duty cycle choices
  • Two nodes, i and j
  • start their counters ci and cj
  • at arbitrary times, say x 1 and x 2
  • increment counters with equal period Tslot
  • and wake up at some relatively prime intervals,
    say mi 3 and mj 5
  • Dark cells indicate times when node i and j turn
    on radios
  • Both nodes are awake at times x 7 and x 22
  • This rendezvous pattern repeats for x 715k, ?k
    ? Z
  • Works by virtue of the Chinese Remainder Theorem
  • Provided periods mi 3 and mj 5 are relatively
    prime
  • Disco uses two primes/node to ensure pairwise
    relative primes

The choice of primes is a critical design
consideration that enables great flexibility
with relative simplicity
8
A glimpse of Disco in operation
At 2 duty cycle, with Tslot 10 ms, and (p1,p2)
(97, 103), 150 rendezvous / hour or 1
rendezvous every 24 seconds
5 ms Tslot 25 ms
5
2
1
3
4
event void Timer.fired() if (c p1 0)
(c p2 0) wake() // 1
beacon() // 2 listen(Tslot) // 3
beacon() // 4 sleep() // 5
c
with Tslot 25 ms, 60 rendezvous / hour or 1
rendezvous every 60 seconds
9
Outline
  • Introduction
  • Related Work
  • Disco Overview
  • How does it work?
  • From duty cycle to primes
  • Slot design to ensure rendezvous
  • A complete example
  • Duty cycle as a function of latency
  • (A lot of other details are in the paper)
  • How well does it work?
  • How is it used?
  • What are its limitations?

10
Choosing primes from the duty cycle
1
1
DC


pi1
pi2
1
1
5

37
43
1
1
5

23
157
11
Ensuring bi-directional discovery during
rendezvous
i
j
i leads j
i and j in sync CSMA/CA
12
A more realistic example of Disco operation
m
  • Node i is awake at times
  • 5, 10, 15, 20, 25, 30, 25, and
  • 7, 14, 21, 28, 35
  • Node j is awake at times
  • 1, 6, 11, 16, 21, 26, 31, and
  • 1, 8, 15, 22, 29, 36
  • Nodes i and j are both awake at
  • 15, 22
  • Two primes per node ensures even if both nodes
    pick same primes, discovery will occur

15
m
21
B/L/B O(11 ms) in Disco
i
j
R
t
13
Outline
  • Introduction
  • Related Work
  • Disco Overview
  • How does it work?
  • How well does it work?
  • Discovery latency
  • Choice of prime pairs
  • Duty cycle asymmetry
  • How is it used?
  • What are its limitations?

14
First, some terminology
  • Discovery latency time to rendezvous from an
    unsynchronized state
  • Slot length the time to beacon listen (Tslot)
  • Beacon rate number of beacons per second
  • Balanced primes when intra-node primes are
    approximately equal (e.g. 5 1/37 1/43)
  • Unbalanced primes when intra-node primes are
    significantly different (e.g. 5 1/23 1/157)
  • Symmetric pairs when inter-node pairs are
    identical (e.g. both nodes i and j chooses (37,
    43))
  • Aymmetric pairs when inter-node pairs are
    distinct (e.g. node i chooses (37, 43) and node j
    chooses (23, 157))

15
CDF of discovery latency for the Disco, Quorum,
and Birthday operating at the same duty cycle (5)
Birthday starts strong but the tail is long
Disco and Quorum track each other
Disco using balanced primes in symmetric pairs
16
Practice often beats theory
Practice
Theory
17
Choice of primes and pairs greatly affects
discovery latency
Balanced primes in symmetric pairs show average
latency (37,43), (37,43)
Unbalanced primes in asymmetric pairs show best
latency (23,157), (29,67)
Birthday
Unbalanced primes in symmetric pairs show worst
latency (23,157), (23,157)
5
18
Limit of the ratio between the best (U/A) and
worst (U/S)discovery latency is equal to the
duty cycle
Example 1 (1/101 1/10103) (1/103
1/3433)
Best cast O(101103) Worst case O(10110103)
1 100

19
A concrete example the benefits of good primes
and pairs
Discovery occurs more slowly in 19 of cases
And the really bad pairing is quite rare
Four unique pairs for a 5 duty cycle (23,157),
(29,67), (31,59), (37,43)
CDF of discovery latencies for the 16 distinct
combinations
Discovery occurs more quickly in 75 of cases
Conclusion asymmetry helps most of the
time. Take advantage if possible.
20
Discovery latency decreases with increasing
asymmetryin pairwise duty cycles for a fixed
average duty cycle
DC 3 (24)/2 (97,103), (47,53)
DC 3 (15)/2 (191,211), (37,43)
Cattle nodes
DC 3 (33)/2 (61,73), (61,73)
Wark07
Sink nodes
Useful when application has natural asymmetry,
like Docking
21
Neighbor discovery in clusters
2 (97,103)
Time to discovery of first node is short. Sharing
neighbor information could be useful
22
Outline
  • Introduction
  • Related Work
  • Disco Overview
  • How does it work?
  • How well does it work?
  • How is it used?
  • Simple API
  • Discovery latency driven
  • Node asymmetry
  • What are its limitations?

23
Disco allows applications set duty cycle, node
class, and beacon mode, and also piggyback data
on beacons
  • interface Discovery
  • // Request a duty cycle between 0 and 100
    percent
  • command uint8_t setDutyCycle(uint8_t
    dutycycle)
  • command uint8_t getDutyCycle()
  • // Set the node class to reduce inter-class
    latency
  • command error_t setNodeClass(uint8_t classid)
  • command uint_t getNodeClass()
  • // Select beacon-and-listen or listen-only mode
  • command error_t setBeaconMode(bool beacon)
  • command bool getBeaconMode()
  • // Request, event, callback for app-specific
    payload
  • command error_t requestBroadcast()
  • event error_t fetchPayload(void buf, uint8_t
    len)
  • event message_t received(message_t msg, void
    buf,
  • uint8_t len)

24
If the discovery window is small, select a
maximum discovery latency and compute duty cycle
  • Assumes
  • Balanced primes
  • Symmetric pairs

10 ms
2
100 s
25
Select different node classesand their operating
duty cycles
Disco.setDutyCycle(1) Disco.setNodeClass(2) Dis
co.setBeaconMode(TRUE)
Cattle nodes
Wark07
Sink node
Disco.setDutyCycle(5) Disco.setNodeClass(1) Dis
co.setBeaconMode(TRUE)
26
Outline
  • Introduction
  • Related Work
  • Disco Overview
  • How does it work?
  • How well does it work?
  • How is it used?
  • What are its limitations?
  • Not all slots are equal
  • Robustness to clock skew
  • Duty cycle adaptation left to application

27
The analysis uses slot length, but not all
slots are equal
Disco tested with 5, 10, 25 ms slots
Disco
CC2420 LPL in TinyOS 2.x has O(15 ms) CCA
Musaloiu08
CC2420 LPP in TinyOS 2.x has O(20 ms) slot
Hui08
Optimized CCA uses O(3 ms) slot
Original B-MAC has O(9) ms slot
Dutta05
Real figures of merit are both slot length and
?p(t)dt
28
A clock skew of 50 ppm could result in a failure
to rendezvous as expected at duty cycles below 1
slots overlap
expected rendezvous
No clock skew
is clock is fast
failed rendezvous
early rendezvous
js clock is fast
failed rendezvous
early rendezvous
Early rendezvous may still occur
29
Summary
  • Finding needles of connectivity in haystacks of
    time
  • A simple scheduling algorithm to ensure temporal
    overlap
  • A solution to the low-power asynchronous neighbor
    discovery problem in mobile sensing applications
  • Distributed algorithm allows independent choices
  • As easy as picking a pair of primes and counting
  • Often better performance in practice than in
    theory

30
Questions?
31
Backup slides
32
Common interaction patterns in mobile systems
  • Talking. Two nodes meet, exchange data, and
    diverge.
  • Docking. A mobile node discovers a static node
    situated at a rendezvous point
  • Flocking. A group of nodes move together as a unit

33
Mobility makes energy availability highly
variable,so per-node duty cycles might vary
considerably
Canopy no mobility uncertain energy
budget - Jay Taneja IPSN 2008
Weather mobility uncertain energy budget -
Jacob Sorber, Sensys 2007
J. Sorber et al., Eon A Language and Runtime
for Perpetual Systems, Sensys07, Sydney,
Australia
J. Taneja, J. Jeong, and D. Culler, Design,
Modeling, and Capacity Planning for Micro-Solar
Power Sensor Networks, IPSN/SPOTS08, St. Louis,
MO, USA
Mobility or not, energy income is often quite
variable
34
A concrete example the benefits of good primes
and pairs
Four unique pairs for a 5 duty cycle (23,157),
(29,67), (31,59), (37,43)
Conclusion asymmetry helps most of the
time Take advantage if possible.
Discovery occurs more slowly in 19 of cases
And the really bad pairing is quite rare
CDF of discovery latencies for the 16 distinct
combinations
Discovery occurs more quickly in 75 of cases
Write a Comment
User Comments (0)
About PowerShow.com