Time Synchronization for Wireless Sensor Networks

1
Time SynchronizationforWireless Sensor Networks

• Jeremy Elson, Lew Girod, and Deborah Estrin
• University of California, Los Angeles
• jelson_at_acm.org
• http//google.com/q?jeremyelson

Center for Embedded Network Sensing
2
The Story of CENS
Conveniently reduced to one simple slide

• CENS is implementation-focused, so must address
  problems that can be ignored in simulations,
  analyses, small-scale systems
• With a different domain comes different
  assumptions a lot of existing work cant be
  applied directly
• Old problems new domain new solutions
  fertile ground for significant new research

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 synchronization

• Time sync is critical at many layers
• Beam-forming, localization, distributed DSP

5
time synchronization

• Time sync is critical at many layers
• Beam-forming, localization, distributed DSP
• Data aggregation caching

t2
t3
t1
t0
6
time synchronization

• 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

7
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...)

8
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)

9
Obsolete Assumptions

• Energy, energy, energy
• Every bit transmitted brings the network closer
  to its death (Greg Pottie)
• Small but continuous CPU use can cost you dearly
• No infrastructure available
• NTP is really only used for the last mile
• Where do you put the master in a large network?
• Cant listen to GPS indoors, under foliage, on
  Mars
• Cost and form factor
• Cant put a 50 GPS receiver or a 500 oscillator
  on a 5 mote

10
A palette of sync 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
11
A palette of sync 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
12
No Global Timescale
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.
13
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
14
Receiver Determinism
1st testbed Berkeley motes with narrowband
(19.2K) radios
15
Time
16
Clock Resolution
17
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!
18
Post-Facto Sync

• Most protocols stay synced all the time this is
  expensive! (CPU, radio)
• 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 the future
• Big win for occasional, unpredictable events

19
Can post-facto work?
Sync pulses
Drift Estimate
Test pulses
7usec error after 60 seconds of silence
20
Conclusions

• 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
• New field new problems new solutions!

21
Thank you!