1. Time Synchronization for Wireless Sensor Networks
Proposal for Ph.D. Thesis
University of California, Los Angeles
Department of Computer Science
April 10, 2001
Jeremy Elson

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?
Circulatory Net

3. new challenges Energy constraints imposed by unattended systems.
Scaling challenges due to very large numbers of sensors.
Level of dynamics:
Environmental: obstacles, weather, terrain, etc.
System: large number of nodes, failures.

4. Part I:
Defining the Problem

5. time synchronization
Time sync is critical at many layers

6. time synchronization Time sync is critical at many layers
Beam-forming, localization, distributed DSP

7. time synchronization Time sync is critical at many layers
Beam-forming, localization, distributed DSP
Data aggregation & caching
t=1
t=0
t=2
t=3

8. 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 can’t
predict exactly when packet will arrive
Time

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

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

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

12. related work Clock sync over computer networks
Protocols: NTP, Berkeley, Cristian’s probabilistic alg
Stable frequency standards
Cesium, Rubidium, temperature-controlled…
National time standards
USNO’s time, UTC/TAI
Two-way satellite time transfer, GPS
Virtual clocks (Lamport)

13. what’s wrong with what’s there?
Existing work is a critical building block
BUT...
Energy
e.g., we can’t 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…

14. our approach Use multiple modes Use tiered architectures
Extend existing sync methods
Develop new methods, and compositions of methods
Characterize these methods
Use tiered architectures
Not a single hardware platform but a range of hardware
Analogy: memory hierarchy
The set as a whole can (?) be necessary and sufficient, to minimize resource waste
Don’t spend energy to get better sync than app needs

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

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

17. Part II:
Initial
Experimentation

18. post-facto sync Basic idea:
A set of receivers is waiting for an event
Locally timestamp an event when it happens
After the fact, reconcile clocks
Allows us to avoid wasting energy on sync when it is not needed
Train clocks with NTP; beacon after event
NTP is good at correcting frequency
A local “pulse” is good at correcting phase
How well does the combination work?

19. expected error sources
Clock skew
We hope to reduce this with NTP; BUT
Temperature variations likely in sensor nets
Nondeterministic delays on receivers
Not considering senders to be synced helps!
Propagation delay
Using RF to sync works if we’re measuring sound, not if we’re measuring RF

20. an initial experiment Create a (wired) stimulus sent to 10 nodes…
We know it arrives at each node simultaneously
With how much error can we timestamp it? (All timestamps should be the same)
Four methods:
NTP alone
Sync pulse alone
Pulse + active NTP
Pulse + disconnected NTP

22. the experiment says…?
Sync pulse much better than NTP: 100usec vs. 1usec (clock resolution=1usec)
At the cost of a localized timebase
Pulse+NTP=10x better than either alone
Multi-modal solutions are good!
Important: We do as well when we train NTP first, then cut off its time source
No time source needed = no radio listening = much lower energy expenditure

23. Part III:
Thesis Plan

24. future work: 1 Repeat experiment in wireless context
Test determinism of different ways of sending the pulse (radios, light?)
Multi-hop sync: pulse chaining
Characterize - error vs. distance
analogous to our current “error vs. time”
Better understand limitations and uses of existing methods (NTP, GPS, etc.)

25. future work: 2 Testbed for object tracking
In cooperation with Girod: acoustic ranging
Uses time sync in two ways:
Each localization point requires sync
Integration of points over time requires sync
Implement “synched msg” primitive using beacons

26. future work: 3 Work in simulation (somewhat less well defined)
Explore aspects of sync without “burden” of real implementations:
Scaling
Adaptive fidelity
Automatic mode selection
Certain “tuning knobs”

27. that’s all, folks!
Thank you!