Practical Asynchronous Neighbor Discovery and Rendezvous for Mobile Sensing Applications

1

Practical Asynchronous Neighbor Discoveryand Rendezvous for Mobile Sensing Applications

Prabal Dutta and David Culler

Computer Science DivisionUniversity of California, Berkeley{prabal,culler}@cs.berkeley.edu

Sensys’08 – 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?– Can’t 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”, Sensys’07, 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

Talking Docking Flocking

[Liu04]

[Choudury04,07]

[Wark07]

[Malinowski07]

[Borriello04]

[Huang05] [Huang05] [Huang05]

[UP08]

[Eisenman08]

Three interaction patterns.Three operating regimes: symmetric, asymmetric,

hybrid

5

Some asynchronous neighbor discovery techniques exist

• 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 (E{Tlisten/2})

– Rendezvous when these listen and transmit times overlap

• Overhearing problem

TL Rt

87

21

109

43

1211

65

2019

1413

2221

1615

2423

1817

3231

2625

3433

2827

3635

3029

CCAO(15 ms)

in T2

m

m

But requires global agreement onthe minimum node duty cycle (B-MAC)

or unclear termination condition (X-MAC)

6

Variations on a theme

T

L

R

t

8721

10943

121165

20191413

22211615

24231817

32312625

34332827

36353029

m

m

• Birthday [McGlynn01]• Randomly choose to listen,

transmit or be idle (sleep)• Not deterministic

• Combinatoric [Zheng03]• Requires symmetric design• Asymmetric schedule NP hard• Not distributed

• Quorum [Tseng02]• Listen during a row • Transmit during a column• Used by some TDMA protocols• Global agreement on duty cycle

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 = 7+15k, 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

event void Timer.fired() { if (c % p1 == 0) || (c % p2 == 0) { wake(); // 1 beacon(); // 2 listen(Tslot); // 3 beacon(); // 4 sleep(); // 5 } c++;}

21 53 4

At 2% duty cycle,with Tslot = 10 ms,

and (p1,p2) = (97, 103),150 rendezvous / hour or

1 rendezvous every 24 seconds5 ms ≤ Tslot ≤ 25 ms

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

+DC pi1 pi21 1

+5% = 37 431 1

=

+5% = 23 1571 1

11

Ensuring bi-directional discovery during rendezvous

i

j

i leads j i and j in syncCSMA/CA

12

A more realistic example of Disco operation

• 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

i j Rt

87

21

109

43

1211

65

2019

1413

2221

1615

2423

1817

3231

2625

3433

2827

3635

3029

B/L/BO(11 ms)in Disco

m

m21

15

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 longDisco and Quorum track each other

Disco using balanced primes in

symmetric pairs

16

Practice often beats theory

Theory

Practice

17

Choice of primes and pairs greatly affects discovery latency

Birthday

Unbalanced primes in asymmetric pairsshow best latency(23,157), (29,67)

Unbalanced primes in symmetric pairsshow worst latency(23,157), (23,157)

Balanced primes in symmetric pairsshow average latency(37,43), (37,43)

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(101*103)Worst case:

O(101*10103)≈ 1

100

19

A concrete example: the benefits of good primes and pairs

Discovery occurs more quickly in75% of cases

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

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

Sink nodes

Cattle nodes

[Wark07]

DC = 3% = (3%+3%)/2

(61,73), (61,73)

DC = 3% = (2%+4%)/2

(97,103), (47,53)

DC = 3% = (1%+5%)/2

(191,211), (37,43)

Useful when applicationhas 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 beaconsinterface 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

100 s

2%

10 ms

Assumes:1. Balanced

primes2. Symmetric

pairs

25

Select different node classesand their operating duty cycles

Sink node

Cattle nodes

[Wark07]

Disco.setDutyCycle(1); Disco.setNodeClass(2);Disco.setBeaconMode(TRUE);

Disco.setDutyCycle(5); Disco.setNodeClass(1);Disco.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

Original B-MAC has O(9) ms “slot”

CC2420 LPL in TinyOS 2.x has O(15 ms) CCACC2420 LPP in TinyOS 2.x has O(20 ms) “slot”

[Dut

ta0

5]

Optimized CCA uses O(3 ms) “slot”[Hui

08]

[Mus

aloi

u08]

[Disc

o]

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%

failedrendezvo

us

slotsoverlap

expectedrendezvou

s

failedrendezvou

s

earlyrendezvou

s

earlyrendezvou

s

Early rendezvous may still occur

No clock skew

i’s clock is fast

j’s clock is fast

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

“Weather + mobility = uncertain energy budget”- Jacob Sorber, Sensys 2007

J. Sorber et al., “Eon: A Language and Runtime for Perpetual Systems”, Sensys’07, Sydney, Australia

J. Taneja, J. Jeong, and D. Culler, “Design, Modeling, and Capacity Planning for Micro-Solar Power Sensor Networks”, IPSN/SPOTS’08, St. Louis, MO, USA

“Canopy + no mobility = uncertain energy budget”- Jay Taneja IPSN 2008

Mobility or not, energy income is often quite variable

34

A concrete example: the benefits of good primes and pairs

Discovery occurs more quickly in75% of cases

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

Conclusion: asymmetryhelps most of the time;

Take advantage if possible.