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

CS213 - January 28, 2003
2
Part I Defining the Problem
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

5
time synchronization

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

6
time synchronization

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

t1
t0
t2
t3
7
time synchronization

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

Radio On
Radio Off
Sender
Radio Off
Receiver
Guard band due to clock skew receiver
cant predict exactly when packet will arrive
Time
8
time synchronization

• Time sync is critical at many layers
• Beam-forming, localization, distributed DSP
• Data aggregation caching
• TDMA guard bands
• Clock sync for TDMA is more important in sensor
  nets, compared to traditional nets
• Listening is EXPENSIVE
• Infrequent data means infrequent sync
• Small data means guard band is relatively big

9
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,
  certain crypto algorithms, database consistency,
  etc.)

10
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

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

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

13
Energy, Energy, Energy
Old assumptions no longer hold

• Sending a packet is free
• Every bit transmitted brings the network closer
  to its death (Greg Pottie)
• Listening to the network is free
• Almost as bad as sending! (at low powers)
• Using a little CPU continuously is free
• Lowest-power systems go to sleep completely
  cant apply continuous frequency corrections

14
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?

15
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.
16
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

17
Part II So what do we do?
18
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
19
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
20
No global timescale
A
C
B
Your clock is your clock. Just know how your
clock relates to others.
21
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

22
Leveraging the Medium

• Wireless networks often use network interfaces
  with physical-layer broadcasts
• Reference Broadcast Synchronization leverages
  this property to remove the most nondeterministic
  part of the system from the critical path

23
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
24
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
25
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
26
Receiver Determinism
1st testbed Berkeley motes with narrowband
(19.2K) radios
27
Well-Behaved Good

• Well behaved distributions are useful
• Error can be reduced statistically, by sending
  multiple pulses over time and averaging
• Also, easier to model/simulate
• Problem Clock skew
• It takes time to send multiple pulses
• By the time we do, clocks will have drifted
• So dont average fit a line instead

28
Time
29
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

30
Clock Resolution
31
Clock Resolution
RBS degraded slightly (6us to 8us) NTP degraded
severely (51us to 1542us)
32
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!
33
Time Routing
Consider a physical topology consisting of
broadcasters (A, B, C..) and receivers (1, 2, 3)
1
2
5
A
B
6
3
4
7
C
8
9
D
10
11
(In reality, a node can play both roles)
34
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
35
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
36
post-facto sync

• Traditional protocols keep clocks synced all the
  time this is expensive! (CPU, radio)
• Solution timestamp an event with your local
  clock synchronize aftwards
• Big win if app needs synced time occasionally
  and unpredictably
• You can never predict the future as well as you
  can predict the past

37
Can post-facto work?
Sync pulses
Drift Estimate
Test pulses
7usec error after 60 seconds of silence
38
Summary of RBS

• RBS can improve accuracy by removing sender from
  the critical path
• Multi-hop algorithm can extend RBS property
  across broadcast domains, and to external
  standards such as UTC
• Implemented on 4 different CPU/radio platforms
  no MAC tinkering required
• Facilitates post-facto sync (save energy by only
  syncing after an event of interest) and peer to
  peer sync (no global timescale)

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

40
Thank you!