Time Synchronization for Wireless Sensor Networks

1. Time Synchronizationfor Wireless Sensor Networks

2. Importance of timesync • 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

3. Heterogeneity • 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

4. Beam-forming, localization, distributed Digital Signal Processing: small scope, short lifetime, high precision

5. Target tracking: larger scope, longer lifetime, but lower required precision t=2 t=3 t=1 t=0

6. Isn’t 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...)

7. So what’s wrong? • Existing work is a critical building block • This isn’t 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) • Energy, energy energy: • Listening to the network is no longer free; even occasional CPU use can have a major impact BUT...

8. Infrastructure vs. Ad-Hoc • “NTP provides UTC to the entire Internet” • But wait, you’re 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 isn’t ubiquitous in sensor nets • GPS doesn’t work indoors, in the forest, underwater, on Mars… • What happens without infrastructure?

9. Poor Topologies Master Stratum 2 A C Stratum 3 B ????? Should A or C serve as B’s master? Either decision leads to poor sync with the other.

10. “Mundane” Reasons • Cost • We can’t 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

11. So what do we do? New architectural directions fortime synchronization in sensor networks

12. Leveraging the Medium • Wireless networks often use network interfaces with physical-layer broadcasts • Reference Broadcast Synchronization takes advantage of this to remove most of the non-determinism from the critical path

13. 4 Time Components in Traditional sync Problem: Many sources of unknown, nondeterministic latency between timestamp and its reception Sender Receiver Send time Receive Time At the tone: t=1 NIC NIC Access Time Propagation Time Physical Media

14. Reference Broadcasts Sync 2 receivers with each other, NOT sender with receiver Sender Receiver Receiver Receive Time NIC NIC NIC I saw it at t=4 I saw it at t=5 Propagation Time Physical Media

15. NIC Sender Receiver Critical Path Time 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

16. Receiver Determinism 1st testbed: Berkeley motes with narrowband (19.2K) radios

17. Time

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

19. 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!”

20. 1 2 5 6 3 4 7 8 9 10 11 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

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

22. “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; it’s easier to predict the past than future

23. Post-Facto Sync Sync pulses Drift Estimate Test pulses 7usec error after 60 seconds of silence

24. Applications A few brief anecdotes

25. Acoustic Localization

26. Correlation • Green is reference, Red is measured • Signals aligned to offset yielding max correlation Amplitude Time in Samples (20 uS)

27. Lessons Learned What’s the big picture?

28. We need many 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

29. We need many 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

30. A new service model • Traditional time synchronization: “What time is it”? • Forces clocks to be synchronized all the time • Forces synchronization to pick one timescale • Our new model: explicit conversions • What time is it here? • For a given time here, what’s the time there? • This model buys us enormous freedom!

31. No global timescale A C B Your clock is your clock. Just know how your clock relates to others.

32. Future Work • RBS is “under-specified” -- Who broadcasts? How is information disseminated? • Are there standard, easily configured solutions? • Can we exploit global knowledge? • Initial work by Karp, Shenker is promising • Is post-facto sync really practical? • Does it save enough energy and have a low enough cost in lost precision?

33. Summary • 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 • A new service model is more expressive • New field = new problems = new solutions!