Time Synchronization for Wireless Sensor Networks

1
Time SynchronizationforWireless Sensor Networks

• University of California, Los Angeles
• Department of Computer Science
• jelson_at_acm.org
• http//google.com/q?jeremyelson

Jeremy Elson, Lew Girod, and Deborah Estrin
2
wireless sensor networks
Environmental Monitoring

• New technologies have reduced the cost, size, and
  power of micro-sensors and wireless interfaces.
• Systems can
• Sense phenomena at close range
• Embedded into environment
• These systems will revolutionize
• Environmental monitoring
• Disaster scenarios
• Fantastic Voyage?

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 apps

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

5
time sync apps

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

t2
t3
t1
t0
6
Isnt this solved?

• NTP (Network Time Protocol)
• Ubiquitous in the Internet
• Variants appearing in sensor networks
• Many other LAN clock agreement algs.
• 802.11 synchronization
• Precise clock agreement within a cluster
• GPS, WWVB, other radio time services
• High-stability oscillators

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

8
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

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

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

12
So what do we do?
13
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
14
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
15
new sync methods

• Reference-broadcast synchronization Very high
  precision sync with slow radios
• Beacons are transmitted, using physical-layer
  broadcast, to a set of receivers
• Time sync is based on the difference between
  reception times dont sync sender w/ receiver
• Post-facto synchronization Dont waste energy on
  sync when it is not needed
• Timestamp events using free-running clocks
• After the fact, reconcile clocks
• Peer-to-peer sync no master clock or global time
• Tiered Architectures Range of node capabilities

16
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
17
reference broadcast sync
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
18
RBS reduces error by removing much of it from the
critical path
NIC
NIC
Sender
Sender


Receiver
Receiver 1

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

21
Time
22
rbs sync advantages

• 11usec precision over 19.2K radios
• (old -- without high precision bit detection)
• local or relative time peer to peer sync
• allows seamless exchange of messages about the
  local area no error due to the master sync
  server being far away
• (NTP allows sync without an external ref., but
  some node still needs to be defined as time)
• Graceful handling of lost packets, outliers

23
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

24
Clock Resolution
25
Clock Resolution
RBS degraded slightly (6us to 8us) NTP degraded
severely (51us to 1542us)
26
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!
27
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
28
Multi-Hop RBS Experiment
3.68 /- 2.57
2.73 /- 2.42
2.73 /- 1.91
1.85 /- 1.28
29
external standards (UTC)
The multihop algorithm can also be easily used to
sync an RBS domain to an external standard such
as UTC
1
2
5
A
B
6
3
4
7
C
8
9
GPS
D
GPS
10
11
GPSs PPS generates a series of fake
broadcasts received by node 11s local clock
and UTC
30
post-facto sync (well, pre)
Sync pulses
Drift Estimate
Test pulses
7usec error after 60 seconds of silence
31
summary

• 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
• Facilitates tiered architectures (some nodes have
  GPS, some dont)
• Facilitates post-facto sync (save energy by only
  syncing after an event of interest) and peer to
  peer sync (no global timescale)