Time Synchronization for Wireless Sensor Networks

1
Time SynchronizationforWireless Sensor Networks

• University of California, Los Angeles
• Department of Computer Science
• jelson_at_circlemud.org
• http//www.circlemud.org/jelson

Jeremy Elson 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
new challenges

• Energy constraints imposed by unattended systems.
• Scaling challenges due to very large numbers of
  sensors.
• Self-Configuration Often no infrastructure
  available
• Autonomy No user to fix problems!
• Level of dynamics
• Environmental obstacles, weather, terrain, etc.
• System large number of nodes, failures.

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

t1
t0
t2
t3
6
whats wrong with whats there?

• Existing work is a critical building block

BUT...

• Energy
• e.g., we cant always be listening or using CPU!
• Wide range of requirements within a single app
  no method optimal on all axes
• Cost and form factor can disposable motes have
  GPS receivers, expensive oscillators? Completely
  changes the economics
• Needs to be fully decentralized,
  infrastructure-free

7
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
• Tiered Architectures Range of node capabilities

8
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
9
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
10
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
11
Receiver Determinism
Testbed Berkeley motes with narrowband (19.2K)
radios
12
gaussian 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
• Solution dont average fit a line instead!

13
Time
14
rbs sync advantages

• 11usec precision over 19.2K radios wow!
• 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

15
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

16
Clock Resolution
17
Clock Resolution
RBS degraded slightly (6us to 8us) NTP degraded
severely (51us to 1542us)
18
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

Blue pulse 2 secafter red pulse!
Here 3 sec after blue pulse!
Here 1 sec after red pulse!
Here 1 sec afterblue pulse!
Here 0 sec after red pulse!
19
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
20
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
21
post-facto sync (well, pre)
Sync pulses
Drift Estimate
Test pulses
7usec error after 60 seconds of silence
22
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)