Time Synchronizationfor Wireless Sensor Networks

Importance of timesync

• Internet Time Synchronization– Critical in some contexts (e.g. crypto,

distributed packet traces)

– A convenience in many other contexts

• Sensor Network Synchronization– Fundamental to its purpose: data fusion

– Physical time needed to relate events in the physical world

Heterogeneity • Time sync is critical at many layers

– Beam-forming, localization, distributed DSP

– Data aggregation & caching

– TDMA guard bands

– “Traditional” uses (debugging, user interaction…)

• But time sync needs are non-uniform– Maximum Error

– Lifetime

– Scope & Availability

– Efficiency (use of power and time)

– Cost and form factor

Beam-forming, localization, distributed Digital Signal Processing: small scope, short lifetime, high precision

t=3

t=2

t=1

t=0

Target tracking:larger scope, longer lifetime,but lower required precision

Isn’t this solved?

• NTP (Network Time Protocol)– Ubiquitous in the Internet

– Variants appearing in sensor networks

• 802.11 synchronization– Precise clock agreement within a cluster

• GPS, WWVB, other radio time services

• High-stability oscillators (Rubidium, Cesium...)

So what’s wrong?

• This isn’t the Internet– Important assumptions no longer hold

• (fewer resources available for synchronization…)

– Sensor apps have stronger requirements• (…but we have to do better than the Internet anyway)

• Energy, energy energy:– Listening to the network is no longer free; even occasional CPU

use can have a major impact

• Existing work is a critical building blockBUT...

Infrastructure vs. Ad-Hoc

• “NTP provides UTC to the entire Internet”– But wait, you’re cheating! UTC is distributed to

many places in the network out of band via various radio services (WWV, GPS, …)

– Path from clients to a canonical clock is short

• Infrastructure isn’t ubiquitous in sensor nets– GPS doesn’t work indoors, in the forest,

underwater, on Mars…

• What happens without infrastructure?

Poor Topologies

Master

Stratum 2

Stratum 3

?????

A C

B

Should A or C serve as B’s master?Either decision leads to poor sync with the other.

“Mundane” Reasons

• Cost– We can’t put a $500 Rubidium oscillator or a

$50 GPS receiver on a $5 sensor node

• Form factor– Nodes are small, extra components are large

• Not actually a mundane limitation if it changes the economics of the sensor net

So what do we do?

New architectural directions fortime synchronization in sensor networks

Leveraging the Medium

• Wireless networks often use network interfaces with physical-layer broadcasts

• Reference Broadcast Synchronization takes advantage of this to remove most of the non-determinism from the critical path

4 Time Components in Traditional sync

Sender Receiver

At the tone: t=1

NIC

Physical Media

NIC

Send time

Access Time

Propagation Time

Receive Time

Problem: Many sources of unknown, nondeterministiclatency between timestamp and its reception

Reference Broadcasts

Sender Receiver

NIC

Physical Media

NIC

Propagation Time

Receive Time

Sync 2 receivers with each other, NOT sender with receiver

Receiver

NICI saw itat t=4 I saw it

at t=5

NICSender

Receiver 1

Receiver 2

Critical Path

NICSender

Receiver

Critical PathTime

RBS reduces error byremoving much of it from the critical path

Traditional critical path:From the time the sender

reads its clock, to when the receiver reads its clock

RBS: Only sensitive to the differences in receive time

and propagation delay

Receiver Determinism

1st testbed: Berkeley motes with narrowband (19.2K) radios

Time

Comparison to NTP• Second implementation:

– Compaq IPAQs (small Linux machines)

– 11mbit 802.11 PCMCIA cards

• Ran NTP, RBS-Userspace, RBS-Kernel– NTP synced to GPS clock every 16 secs

– NTP with phase correction, too; it did worse (!)

• In each case, asked 2 IPAQs to raise a GPIO line high at the same time; differences measured with logic analyzer

“Here 0 sec after blue pulse!”

“Here 1 sec after blue pulse!”

“Here 3 sec afterred pulse!”

“Here 1 sec afterred pulse!”

Multi-Hop RBS• Some nodes broadcast RF synchronization pulses

• Receivers in a neighborhood are synced by using the pulse as a time reference. (The pulse senders are not synced.)

• Nodes that hear both can relate the time bases to each other

“Red pulse 2 secafter blue pulse!”

1

3

2

A4

8

C

5

7

6B

10

D11

9

1

3

2

4

8

5

7

6

10 11

9

Time RoutingThe physical topology can be easily

converted to a logical topology; links represent possible clock conversions

Use shortest path search to find a “time route”;Edges can be weighted by error estimates

Multi-Hop RBS

0

1

2

3

4

5

6

7

1 Hop 2 Hop 3 Hop 4 Hop

Error (usec)

Std Dev

Error

1.85 +/- 1.28

2.73 +/- 1.912.73 +/- 2.42

3.68 +/- 2.57

Error (and std dev) over multiple hops, in usec

• Most protocols stay synced all the time

• Post-facto sync:– Clocks start out unsynchronized

– A set of receivers waits for an interesting event

– Locally timestamp an event when it happens

– After the fact, reconcile clocks

• Avoids wasting energy on unneeded sync; it’s easier to predict the past than future

“Post-Facto” Sync

Post-Facto Sync

Test pulses

Sync pulses

Drift Estimate

7usec error after 60 seconds of silence

Applications

A few brief anecdotes

Acoustic Localization

Correlation • Green is reference, Red is measured

– Signals aligned to offset yielding max correlation

Time in Samples (20 uS)

Am

plit

ude

Lessons Learned

What’s the big picture?

We need many methods

Time Sync Parameter Space:(max error, lifetime, scope, etc.)

Application Requirement

Available SyncMethods

Better

Better

Goal: make the set rich enough to minimize waste

We need many methods

Time Sync Parameter Space:(max error, lifetime, scope, etc.)

Application Requirement

Better

Better

Goal: make the set rich enough to minimize waste

Ideally, methodsshould be tunable

A new service model

• Traditional time synchronization: “What time is it”?– Forces clocks to be synchronized all the time

– Forces synchronization to pick one timescale

• Our new model: explicit conversions– What time is it here?

– For a given time here, what’s the time there?

• This model buys us enormous freedom!

No global timescale

A C

B

Your clock is your clock.Just know how your clock relates to others.

Future Work

• RBS is “under-specified” -- Who broadcasts? How is information disseminated?– Are there standard, easily configured solutions?

• Can we exploit global knowledge?– Initial work by Karp, Shenker is promising

• Is post-facto sync really practical?– Does it save enough energy and have a low

enough cost in lost precision?

Summary• Time sync is critical for sensor networks

• Existing solutions are inadequate: insufficient precision, wasteful of energy

• Fruitful new ideas have come about that never would have developed in the Internet:– Leverage the broadcast channel

– Use local timescales

– Sync after the fact

• A new service model is more expressive

• New field = new problems = new solutions!