Time Synchronization for Wireless Sensor Networks

1
Time SynchronizationforWireless Sensor Networks

• Jeremy Elson
• Department of Computer Science
• Final Defense
• jelson_at_cs.ucla.edu
• http//google.com/q?jeremyelson

May 16, 2003
2
Contributions

• Description of the problem axes, shortcomings
• Implementation, characterization of
• Reference-Broadcast Synchronization
• Federation of broadcast domains
• Post-facto synchronization
• Application experience
• What general lessons did we learn?

3
Does timesync matter?

• 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

4
Time Sync can be the Limiting Factor
Localization Experiment
Courtesy of H. Wang, Prof K. Yao, et. al.
5
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

6
Beam-forming, localization, distributed
DSP small scope, short lifetime, high precision
7
Target tracking larger scope, longer
lifetime, but lower required precision
t2
t3
t1
t0
8
Isnt 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...)

9
So whats wrong?

• Existing work is a critical building block

BUT...

• This isnt 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

10
Infrastructure vs. Ad-Hoc

• NTP provides UTC to the entire Internet
• But wait, youre 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 isnt ubiquitous in sensor nets
• GPS doesnt work indoors, in the forest,
  underwater, on Mars
• What happens without infrastructure?

11
Poor Topologies
Master
Stratum 2
Stratum 3
A
C
?????
B
Should A or C serve as Bs master? Either
decision leads to poor sync with the other.
12
Mundane Reasons

• Cost
• We cant 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

13
So what do we do?

• New architectural directions fortime
  synchronization in sensor networks

14
Leveraging the Medium

• Strict layering and levels of abstraction prevent
  us from exploiting domain knowledge
• 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

15
Traditional sync
Problem Many sources of unknown,
nondeterministic latency between timestamp and
its reception
Sender
Receiver
Send time
Receive Time
At the tone t1
NIC
NIC
Access Time
Propagation Time
Physical Media
16
Reference Broadcasts
Sync 2 receivers with each other, NOT sender with
receiver
Sender
Receiver
Receiver
Receive Time
NIC
NIC
NIC
I saw it at t4
I saw it at t5
Propagation Time
Physical Media
17
RBS reduces error by removing much of it from the
critical path
NIC
Sender

Receiver 1

Receiver 2
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
18
Receiver Determinism
1st testbed Berkeley motes with narrowband
(19.2K) radios
19
Time
20
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

21
Clock Resolution
22
Clock Resolution
RBS degraded slightly (6us to 8us) NTP degraded
severely (51us to 1542us)
23
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!
Here 3 sec after red pulse!
Here 1 sec after blue pulse!
Here 1 sec afterred pulse!
Here 0 sec after blue pulse!
24
Time Routing
The physical topology can be easily converted to
a logical topology links represent possible
clock conversions
1
2
5
A
B
6
3
4
7
C
8
9
D
10
11
Use shortest path search to find a time
route Edges can be weighted by error estimates
25
Multi-Hop RBS
Error (and std dev) over multiple hops, in usec
3.68 /- 2.57
2.73 /- 2.42
2.73 /- 1.91
1.85 /- 1.28
26
Post-Facto Sync

• 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 its
  easier to predict the past than future

27
Post-Facto Sync
Sync pulses
Drift Estimate
Test pulses
7usec error after 60 seconds of silence
28
Applications

• A few brief anecdotes

29
Acoustic Localization
30
Correlation

• Green is reference, Red is measured
• Signals aligned to offset yielding max correlation

Amplitude
Time in Samples (20 uS)
31
Commercial Version

• Sensoria Corp under contract from DARPA
• Goal Nodes localize themselves within 1m, MOVE
  to fill in gaps
• Network completely self-organizing, autonomous
• Uses RBS timesync for acoustic localization

32
Commercial Version
10 MOBILE nodes, 1 is deactivated, and then...
33
Lessons Learned

• Whats the big picture?

34
We need many methods
Goal make the set rich enough to minimize waste
Time Sync Parameter Space (max error, lifetime,
scope, etc.)
Available Sync Methods
Better
Application Requirement
Better
35
We need many methods
Goal make the set rich enough to minimize waste
Time Sync Parameter Space (max error, lifetime,
scope, etc.)
Ideally, methods should be tunable
Better
Application Requirement
Better
36
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, whats the time there?
• This model buys us enormous freedom!

37
No global timescale
A
C
B
Your clock is your clock. Just know how your
clock relates to others.
38
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?

39
Contributions

• 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!

40
Thank you!