1 / 135

Lecture #5: Time Synchronization in Sensor Networks

Lecture #5: Time Synchronization in Sensor Networks. Ack: Slides from Saurabh Ganeriwal, Jeremy Elson. Self Configuration in Sensor Networks. Operate in the presence of obstacles. Ad-Hoc Deployment. Rapid Infrastructure Setup. Self-configuration Challenges. This Lecture.

amal
Télécharger la présentation

Lecture #5: Time Synchronization in Sensor Networks

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Lecture #5: Time Synchronization in Sensor Networks Ack: Slides from Saurabh Ganeriwal, Jeremy Elson

  2. Self Configuration in Sensor Networks Operate in the presence of obstacles Ad-Hoc Deployment Rapid Infrastructure Setup

  3. Self-configuration Challenges This Lecture • Timing synchronization • When did an event take place? • Node Localization • Where did an event take place? • Calibration • What is the value of an event? Self-configuration crucial to relate to the physical world!

  4. Reading List for this Lecture: Required • RATS - S. Ganeriwal, D. Ganesan, M. Hansen, M. B. Srivastava, D. Estrin, “Predictive time synchronization for long-lived sensor networks,” NESL Technical Report, November 2004. • http://nesl.ee.ucla.edu/courses/ee202b/2006s/papers/L05/Ganeriwal05_NESLTechReport.pdf • FTSP - M. Maroti, B. Kusy, G. Simon, A. Ledeczi, “The Flooding Time Synchronization Protocol,” In the Proceedings of the Second ACM Conference on Embedded Networked Sensor Systems (SenSys), 2004. • http://nesl.ee.ucla.edu/courses/ee202b/2006s/papers/L05/Maroti04_SenSys.pdf

  5. Reading List for this Lecture: Optional • RBS - J. Elson, L. Girod, D. Estrin, “Fine-Grained Network Time Synchronization using Reference Broadcasts,” In Proceedings of the Fifth Symposium on Operating Systems Design and Implementation (OSDI 2002), Boston, MA. December 2002. • http://nesl.ee.ucla.edu/courses/ee202b/2006s/papers/L05/Elson02_OSDI.pdf • TPSN - S. Ganeriwal, R. Kumar, M. B. Srivastava, “Timing-sync protocol for sensor networks,” In Proceedings of the First ACM Conference on Embedded Networked Sensor Systems (SenSys), 2003. • http://nesl.ee.ucla.edu/courses/ee202b/2006s/papers/L05/Ganeriwal03_SenSys.pdf • NTP - D. Mills, “Internet Time Synchronization: The Network Time Protocol,” In Zhonghua Yang and T. Anthony Marsland, editors, Global States and Time in Distributed Systems, IEEE Computer Society Press, 1994. • http://www.eecis.udel.edu/~mills/database/papers/trans.pdf • Leslie Lamport, “Time, clocks, and the ordering of events in a distributed system”, ACM Journal of communications, 1978. • http://portal.acm.org/citation.cfm?id=359563

  6. Reading List for this Lecture: Optional • GPS Clocks: http://www.gpsclock.com/gps.html • Kay Romer, “Time Synchronization in Ad Hoc Networks,” ACM MobiHoc.

  7. Importance of Time in Sensor Networks • Time is critical at many layers in sensor nets • Beam-forming, localization, tracking, distributed DSP

  8. Importance of Time in Sensor Networks • Time is critical at many layers in sensor nets • Beam-forming, localization, tracking, distributed DSP • Data aggregation & caching t=1 t=0 t=2 t=3

  9. Importance of Time in Sensor Networks • Beam-forming, localization • Data aggregation & catching • Security protocols • MAC layer design • Adaptive topology management schemes • Absolute time of occurrence • Coordinated robotics • Debugging • User Interface • ……

  10. The Myth of Simultaneity: “Event 1 and event 2 at same time” Event 1 Event 2 Observer A: Event 2 is earlier than Event 1 Observer B: Event 2 is simultaneous to Event 1 Observer C: Event 1 is earlier than Event 2 Why synchronized time?

  11. The Myth of Simultaneity: “Event 1 and event 2 at same time” Event 1 Event 2 Observer A: Event 2 is earlier than Event 1 Observer B: Event 2 is simultaneous to Event 1 Observer C: Event 1 is earlier than Event 2 Why synchronized time? • Ordering of events • Coordinated actuation • Data logging • Absolute time of occurrence • Performance measurement • …..

  12. What does being synchronized mean? • Clock Skew • The difference in time values of two clocks is called clock skew • Synchronization • Two clocks are said to be synchronized at a particular instance of time if the clock skew of the two clocks is less than some specified constant δ • A set of clocks are said to be synchronized if the clock skew of any two clocks in this set is less than δ • Clock Synchronization requires: • Each node can read the other nodes’ clock values • Unpredicted communication delay • Time must never run backward • Operation repetition

  13. Time synchronization in sensor networks. Why it is so crucial?

  14. Parametric, Time-domain Beamforming M2 1 3 d1 2 d2 Y Search angle P d3 f M3 X Start of sampling • Collect synchronized samples from 3 motes • Hypothesize a search angle f • Calculate delays d1, d2, d3 for each search angle f • Shift and Sum the synchronized waveforms as if the source was at angle f • Choose the angle fm that makes the sum maximum Figure source: Courtesy of Vlassios Tsiatsis

  15. Impact of Time Sync Accuracy on Acoustic Source Localization Localization Experiment TDOA with Constrained Least Squares method CRB: Cramer-Rao-Bound, the minimal estimation error bound no matter what methods are used. AML: Approximate Maximum Likelihood estimation Ack: H. Wang, K. Yao, et. al.

  16. MAC layer design Radio On Radio Off Sender Radio Off Receiver Guard band due to clock skew; receiver can’t predict exactly when packet will arrive Time

  17. Time Synchronization Quality Metrics • Maximum Error • Lifetime • Scope & Availability • Efficiency (use of power and time) • Cost and form factor …

  18. Measuring Time

  19. Time & Clocks • How to define time? • Sun • 1s = 1day/(24*60*60) • Atomic • 1s = Time a cesium atom needs for 9192631770 state transitions • Universal Time Coordinated (UTC) • Now a standard for time measure. • Clocks: Measure of time! • Oscillator and counter • Synchronized time -> Synchronized clocks • Errors • Clock skew (offset): Difference between time on two clocks. • Different start times • Clock drift: Count at different rates. • Different frequency of the oscillator.

  20. Oscillators Cost Drift rate Rubidium ~10-15 s / day High Atomic Clocks Cesium ~10-12 s / day Desktop ~10-6 s / day ~10-6 s / hr IPAQs Quartz ~10-6 s / s Low Motes

  21. Atomic Clock CPU power drawn by motes ~ 25 mW Cost will be the deciding factor!

  22. Time e11 e12 e13 P1 e11 e12 e13 P1 e21 e22 e23 e24 e25 P2 e21 e22 e23 e24 e25 P2 e32 e33 e34 e32 e33 e34 P3 P3 e31 Logical Clocks: “Time” = Number Assignedto an Event Satisfying Causality Time e31 “Time, Clocks, and the Ordering of Events in a Distributed System”, Leslie Lamport, Communications of the ACM, July 1978, Volume 21, Number 7.

  23. Implementing Logical Clocks:Happened-before Relationship “” • With synchronized physical clocks: An event a happened before an event b if a happened at an earlier time than b • Without physical clocks: • The events at a node form a sequence, where a occurs before b in this sequence if a happens before b • Assume sending and receiving a message is an event in a node • The relation “” on the set of events in a distributed system is the smallest relation satisfying the following three conditions: • If a and b are events in the same node, and a comes before b, then ab • If a is the sending of a packet by one node and b is the receipt of the same message by another node, then ab • If ab and bc, then ac • Two distinct events a and b are said to be concurrent if ab and ba • Irreflexive partial ordering • a a • Another definition: ab is a causally affected b

  24. Implementing Logical Clocks • Just a way of assigning a number to an event, where the number is the time at which the event occurs. • Define a clock Ci for each process Ni • Assigns a number Ci(a) to any event a in that process • The entire system of clocks is represented by the function C which assigns to any event b the number C(b), where C(b) =Cj(b) if b is an event in process Nj • The clocks Ci are logical clocks rather than physical clocks • The logical clocks is correct if the events of the system that are related to each other by the happened-before relation can be properly ordered using these clocks • Clock condition: for any event a, b, if ab then C(a) <C(b)

  25. Implementing Logical Clocks • According to the definition of Happened-before relation, the clock condition is satisfied if the following two conditions hold: • C1: if a and b are events in node Ni, and a comes before b, then Ci(a) < Ci(b) • C2: if a is the sending of a message by node Ni and b is the receipt of that message by node Nj, then Ci(a)<Cj(b) • To meet C1: • IR1: each node Ni increments Ci between any two successive events • To meet C2: • IR2: (a) if event a is the sending of a message m by node Ni, then the message m contains a timestamp Tm = Ci(a). • (b) Upon receiving a message m, node Nj sets Cj greater than or equal to its present value and greater than Tm

  26. Total Ordering of Events • One can use the logical clocks satisfying the Clock Condition to place a total ordering on the set of all system events. • Simply order the events by the times at which occur • To break the ties, use any arbitrary total ordering of the processes, i.e. node id • Using this method, one can assign a unique timestamp to each event in a distributed system to provide a total ordering of all events • Very useful in distributed system!

  27. Time Synchronization Approaches in Distributed Systems

  28. GPS overview T1 = t1 + |X-s1|/c Gather four satellite signals and solve the non-linear system of equations. Satellite have atomic clocks (four on each), kept within 250 ns of each other.Need only one satellite in “position hold” mode after <x, y, z> is known. Figure source: http://www.dependability.org/wg10.4/timedepend/03-Schmi.pdf

  29. GPS Evaluation • Pros • Accuracy ~ 10-100ns (1 PPS signal in GPS) • Reliable operation • Cons • Cannot work indoors, with foliage, obstructions, under water • If something goes bad, delay for correcting it can be as large as 30 minutes. • Neutral • Expensive ~ Cheapest GPS receiver 50 US dollars. • Energy hungry! • Cautionory note • Not all GPS receivers designed for time • Some need three satellites in view • Some create time glitches when switching to different satellite • Some user serial output as opposed to PPS, and worse, consider it a “low priority” task and can delay time code output by random amount of delays if busy computing. • NMEA-0183 standard protocol on serial lines doesn’t support preciese timecode • Serial port drivers and UART buffering a problem too.

  30. NIST Radio Time Service: WWVBin Fort Collins, CO • Continuously broadcasts time and frequency signals at 60 KHz using a 50 KW radiated power transmitter • Carrier frequency provides stable frequency reference traceable to the national standard • Less than 1 part in 10^12 uncertainty • BCD time code synchronized to 60 KHz carrier, and broadcast at a rate of 1 bit per second using pulse width modulatiuon • Year, day of year, hour, minute, second (31 bits) • flags indicating status of day light saving time, leap year, and leap seconds • It path delay is removed (e.g. by averaging), WWVB provides uncertainty of less than 100 microseconds relative to UTC • Also available via phone • < 30 ms delay with landline, < 1 ms stability • > 100 ms with cell phones • > 250-500 ms with satellite connections • Coverage area (signal > 100 microvolt per meter) varies • Contracts during day, expands during night • Similar services WWV and WWVH for worldwide users 1600 UTC 0400 UTC

  31. Why not put a WWVB receiver at every sensor node? • Outages: typically available for ~ 20 hours/day • Other 4 hours you are stuck with an uncompensated clock oscillator • Most WWVB receivers synchronize to WWVB intermittently, and do so by jumps • Since they don’t report when these jumps take place, there is no good way to process their timestamps • Inexpensive WWVB receivers are limited to 0.5s accuracy • Listening on a radio is not cheap - energy!!!

  32. Send at T1 802.11 Synchronization Base station Clients just adopt the timestamp in the beacon packet Very simple, Provides ms accuracy. Neglects packet delay and delay jitters • This approach used by electronic products such as wall clocks, clock radio, wrist watches etc. worldwide to synchronize via WWVB/WWV/WWVH signals • Can do better by compensating for propagation delay

  33. Recv at T2 Send at T1 T2 = T1 + DELAY + OFFSET Client Peer A B Recv at T4 Send at T3 T4 = T3 + DELAY- OFFSET OFFSET = {(T2-T1)-(T4-T3)}/2 DELAY = {(T2-T1)+(T4-T3)}/2 NTP: Internet Synchronization

  34. Peer 1 Filter 1 Intersection and Clustering Algorithms Peer 2 Filiter 2 Combining Algorithm Loop Filter P/F-Lock Loop Peer 3 Filter 3 LCO NTP Messages Timestamps NTP details • Level n synchronizes to level n-1 • Level 1 synchronizes to UTC via GPS, WWVB etc. • Multiple synchronization peers -> redundancy and diversity • Path from clients to a canonical clock is short • Data filters -> Sliding window • Intersection and clustering algorithms -> Discard outliers • Combining algorithm -> Weight samples • Loop filter and local clock oscillator (LCO) -> implement hybrid phase/frequency-lock feedback loop to minimize jitter Figure source: RFC on NTP

  35. NTPD: NTP Dameon Capabilities • NTPD can compare your local clock against an external reference time source over a long period of time. • It can then measure the 'drift' of the clock and apply a correction. This will keep the clock more accurate even if the external synchronization is later removed. It will also reduce the need to 'jump' your clock to keep it in synch. • NTPD can allow a computer with a more accurate time source to provide time to other computers. More than 100,000 computers currently form a network of time servers and clients on the Internet. • This network can have many levels. For example, a computer with a GPS clock can provide synchronization for several servers which in turn provide synchronization to thousands of client computers. • NTPD can compare time accuracy and stability from numerous sources and pick the best one to lock your computer's clock onto. • If your GPS clock suddenly goes haywire, NTPD is smart enough to know not to listen to it. • NTPD can filter multiple time readings to reduce the effects of jitter. • A single time reading may be off due to network congestion or server load. NTPD is smart enough to pick the best readings and use them. • NTPD also monitors its own accuracy and the reliability of all the time sources it is using. • This statistical information is invaluable in determining of your clocks are actually synchronized. It will also tell you if a change you have made has actually made things better or worse. • NTPD, originally from Unix world, now works for almost all modern OS

  36. Impact of Poor Topologies in NTP 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.

  37. NTP Evaluation • Pros • Readily available • Industry standard • Achieves secure and stable sync to ms accuracy • Cons • Designed for ms accuracy only! • Not flexible • Designed for constant operation in the background at low rates • E.g. it took NTP an hour to reduce error to 60 microseconds with maximum polling rate of 16 sec. • Neutral • Not energy friendly!

  38. What is so different in sensor networks? Why can we now use NTP or GPS?

  39. Varying demands Beam-forming, localization, distributed DSP: small scope, short lifetime, high precision Figure source: Courtesy of Jeremy Elson

  40. Varying demands Target tracking: larger scope, longer lifetime, but lower required precision t=2 t=3 t=1 t=0 Figure source: Courtesy of Jeremy Elson

  41. Synchronization Demands Multi-modal • Event ordering • “Did event 1 happened before/after/with event 2?” • Internal Synchronization • “All cameras should be on after 5 minutes” • External Synchronization • “Show me targets detected between 2:00 & 8:00 p.m.” • Hybrid Synchronization • Target tracking: Convert propagation delay of 1.5ms to distance using speed of 345m/s. Energy, Energy, Energy,…. Scalable µs – ms accuracy

  42. Comparison Specialized costly hardware Cannot work indoors

  43. Synchronizing a pair of sensor nodes

  44. RBS: Synchronize Receivers Based on CesiumSpray system by Verissimo and Rodrigues Receiver-receiver Synchronization Figure source: Courtesy of Jeremy Elson

  45. Magic behind RBS NIC Sender Receiver Critical Path Time 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 Figure source: Courtesy of Jeremy Elson

  46. Observations about RBS • RBS removes send and accesstime errors • Broadcast is used as a relative time reference • Each receiver synchronizing to a reference packet • Ref. packet was injected into the channel at the same instant for all receivers • Message doesn’t contain timestamp • Almost any broadcast packet can be used, e.g ARP, RTS/CTS, route discovery packets, etc

  47. Phase Offset Estimation • Simplest case: single pulse, two receivers • Xmitter broadcasts reference packet • Each receiver records the time that beacon was received according to its local clock • Receivers exchange observations • Sufficient information to form a local (relative) timescale • However, global timescales are also important • Extending simple case to many receivers • Assumptions • Propagation delay is zero • No clock skew • Receiver non-determinism (error) is Gaussian • Sending more messages increases precision • Transmitter broadcasts m packets • Each receiver records time the beacon was observed • Receivers exchange observations • Receiver i computes phase offset to receiver j as the average of the offsets implied by each pulse received by both nodes • Result:

  48. Receiver Determinism Mica1 motes with narrowband (19.2K) radios

  49. 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 • Oscillator characteristics • Accuracy: difference between expected and actual frequency • Difference: Frequency error (usually 10-4 – 10-6) • Stability: tendency to stay at same frequency over time • Phase difference between two nodes’ clocks will change due to frequency differences • Solution: don’t average; fit a line instead! • Frequency and phase of local node’s clock recovered from slope and intercept of the line • Fitting a line assumes that frequency is stable • Assume high short-term frequency stability • Ignore data more than a few minutes old

  50. Clock Skew Estimation Results • 2 receivers (motes): r1, r2 • Point (0,0) marks the first pulse • Receivers synchronized, no clock skew • Clock skew increases as time increases • Linear fit gives good results • With clock skew estimation, sufficient information exists to convert any time value generated by r1’s clock to a time value that would have been generated by r2’s clock • 30 broadcasts improve precision from 11 us to 1.6 us between two receivers • Dispersion down to 5.6 us among 20 receivers Time

More Related