Fine-Grained Network Synchronization Using Reference Broadcast

1. FINE-GRAINED NETWORK SYNCHRONIZATION USING REFERENCE BROADCASTPRESENTED BY ANJU SURYAWANSHI MITA RANA

2. Table of contents • Time synchronization- Introduction • Related work • Traditional synchronization methods-NTP • Challenges for time-sync in Sensor networks • Reference Broadcast Synchronization • Multi-hop Time Synchronization • Conclusion

3. INTRODUCTION • Time Synchronization A method which allows individual entities in a group to synchronize their clocks w.r.t each other or to some coordinated universal time (UTC). • Need For Time synchronization -Agreeing on a common time scale -Track relative order of events • Co-ordinate future events • Order logged events for debugging

4. Continued>>> • Time sync is critical at many layers - Beam-forming, localization, distributed DSP - Data aggregation & caching - DMA guard bands -“Traditional” uses (debugging, user interaction…) • Time sync in sensor networks -Sensor data fusion -Coordinated actuation -Power-efficient duty cycling

5. How Time Synchronization is Achieved • Wired Network -- NTP (Network Time Protocol) - most widely used time-synchronization protocol for large multi-hop networks. - allows construction of a hierarchy of time servers rooted at sources of external time (example- UTC) • Wireless Network -- RBS (Reference Broadcast Synchronization)

6. Related Work • Settling times for GPS synchronized clocks may be too long or unavailable. (sensor power/cost issues too) • CesiumSpray – similar but unable to unify multiple domains w/o a common external time source. • Liao et al – similar time bounds, but they require guarantees about the underlying network • Others – similar time bounds, but require tight coupling of the application with the MAC (add a deterministic bit-detector)

7. Traditional synchronization methods-NTP overview • Most widely used time synchronization protocol - Hierarchical: server, client, peer --stratum levels - Redundant: each daemon can use several independent time sources --Daemon can pick the most accurate one • Perfectly acceptable for most cases

8. Traditional synchronization methods-NTP overview continued E.g. Internet (coarse grain synchronization) - Inefficient when fine-grain sync is required --E.g. sensor net applications: localization, beam forming, TDMA scheduling etc • Stands out by virtue of its scalability, self-configuration in large multi-hop networks, robustness to failures and ubiquitous deployment

9. SENSOR NETWORKS: A NEW DOMAIN • Wireless Sensor Networks (WSN) consists of large numbers of cooperating small-scale nodes, spread over a geographical area, each capable of limited computation, wireless communication, and sensing. Why existing solutions for wired networks (NTP) won’t work ? - Energy constrained. - Dynamic topology. - No infrastructure support.

10. REFERENCE BROADCAST SYSTEM • Exploits the broadcast channel available in many physical-layer networks. -- Works by sending periodic reference beacons to a set of receivers using physical layer broadcasts. -- Broadcasts do not contain a time-stamp. -- Broadcasts used as a relative time reference to synchronize a set of receivers. • Scheme is receiver-receiver as opposed to sender-receiver (NTP).

11. REFERENCE BROADCAST SYSTEM • Tries to achieve accuracy by removing the sender’s non-determinism from the system. • Federate clocks over different broadcast domains with little loss of accuracy over multiple hops.

12. SOURCES OF TIME SYNCHRONIZATION ERROR • SEND TIME – message from host to network interface • ACCESS TIME – contention on the transmit channel (contention-based MACs, ex: Ethernet). • PROPAGATION TIME – transit, includes queuing & switching delay at routers. • RECEIVE TIME – delay between arrival at network interface & notifying the host

13. RBS: Minimizing the critical path Critical path analysis for traditional protocols Critical path analysis for RBS • RBS removes send and access time 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

14. RBS: Phase offset estimation • Sequence of Events - A transmitter broadcasts a reference packet to two receivers (i and j). - Each receiver records the time that the reference was received, according to its local clock. - The receivers exchange their observations. - Based on this single broadcast the receivers can form a relative timescale

15. RBS: Phase offset estimation (cont’d) • 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 observe -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:

16. RBS: Phase offset estimation Numerical analysis results • Numerical analysis for m=1..50, n=2..20 • 1000 trials for each m, n - Results: mean dispersion, std.dev • 2-receiver case - 30 broadcasts improve precision from 11 usec to 1.6 usec • 20-receiver case - Dispersion reduced down to 5.6 usec

17. To be continued by Mita

18. RBS: Clock skew estimation • What is Clock Skew ? The change in frequency of the oscillator over time. • Why is it necessary ? Clock Skew is major source of error. • Oscillator Characteristics - Accuracy - Agreement between the oscillator’s actual and expected frequencies - Stability - An oscillators tendency to stay at the same frequency over a period • To calculate clock skew, least squares linear regression is performed -The slope of the best fit line through the phase offsets can give the relative clock skew of the remote node.

19. Implementation on Berkeley Motes • First test - 5 Berkeley motes sending out reference pulses periodically at 2 micro sec clock resolution. - Residual error detected: 11.2 micro sec • Second Test - Used motes as ‘NIC’ cards for std. Linux boxes. - Modified Linux kernel to time-stamp serial port interrupts for reduction in phase calculation error. - Tried to test the clock skew measurement algorithm by sending a few synchronization pulses, then silencing the radio for a minute and sending synchronization pulses again. - Residual error detected: 7.4 micro sec

21. RBS: Comparison with NTP • Implemented RBS under same constraints as NTP. • Ran RBS as a UNIX daemon on a Compaq IPAQ, with “Familiar” Linux running, using UDP datagram as motes. • Daemon ran completely in user space • 3 different synchronization schemes - RBS - NTP - NTP-Offset - Test application queried the NTP daemon for the clock’s phase offset and subtracted it from the test pulse time. • Two traffic scenarios tested - Light load - Heavy load

22. RBS: Comparison with NTPResults

23. Test Results • RBS performs 8 times better than NTP in the same environment. • The performance of RBS remains almost the same even with heavy traffic. • The performance of NTP degrades 30 fold in the presence of heavy traffic

24. Kernel Time-stamping • Kernel Time stamping significantly improved the performance over the same setup • 1.85 ± 1.28 microseconds from 6.29 ± 6.45 microseconds.

25. Application to Post-Facto synchronization • What is Post-Facto synchronization ? Post-facto synchronization strives to conserve energy in sensor nodes by not keeping the clocks in continuous synchrony. Clocks are synchronized only when an event of interest occurs. • RBS clock skew estimator acts as an effective form of post-facto synchronization. • Once nodes power up from deep sleep and exchange updates, exact time of events of interest can be calculated using backwards extrapolation of clock-skew. • Saves power in a sensor network; NTP is particularly unsuited to these deep sleep situations.

26. Summary of Advantages and Limitations of RBS • Advantages - Receiver-Receiver mechanism, hence most sources of non-deterministic latency removed giving high precision. - Multiple reference broadcasts reduce synchronization offset. - Outliers and lost packets are handled gracefully. - Allows nodes to construct local timescales which is sufficient for applications like sensor networks. • Limitations - It requires a network with a physical broadcast channel . - It can not be used, for example, in networks that employ point-to-point links.

27. Multi-Hop Time Synchronization • Goal: compare times of two events that occurred near receivers 1 and 7 Nodes A and B periodically send sync pulses Node 4’s unique position allows it to relate clocks from one cluster to the other. • Multihop algorithm Receivers R1 and R7 observe events at times E1(R1) and E7(R7). R4 uses A’s pulses to establish best-fit line, in order to convert E1(R1) to E1(R4) Similarly, R4 converts E1(R4) to E1(R7) Time elapsed between the events= E1(R7)-E7(R7)

28. RBS: Multi-Hop synchronization(cont’d) Logical topology. Edges are drawn between nodes that have received a common broadcast Physical topology • Path through logical topology represents a series of time base conversions - By performing shortest-path search one can automatically find the conversion series. - Weights can be used to represent quality of conversion and improve shortest-path algorithm results • Problem: shortest-path algorithms don’t scale due to dependence on global information • Solution: Time conversion can be built into the packet forwarding mechanism

29. Measured performance of Multihop RBS • Series of timestamp conversion are required ,which introduces synchronization error. • Average n-hop path error is approximately calculated as σ*n0.5 .

30. Synchronization with external timescales • The concept of RBS can be extended to include external timescales • Only one node is required to be as the reference external timescale, for e.g. a special node can be GPS enabled and can synchronize its own clock externally • Then other nodes can convert their time to GPS times using the conversion algorithms.

31. Conclusion • NTP is the choice protocol over the internet and intranet and other wired networks • RBS works very well in wireless networks as opposed to using NTP • RBS Removes non-determinism via broadcast • Multiple broadcasts allow estimation of clock skew - Useful for post-facto synchronization • Localized & global timescales

32. Pros and Cons • Pros- - A very simple yet effective algorithm is used to correct clock skew. - Even though number of test conducted were low but number of trials in each test were enough. - Comparison between RBS and NTP is done in a effective way to prove that RBS works well in wireless network. • Cons- • Limited no. of receivers are taken into consideration during estimation of Phase offset. • Only two test were conducted to determine the best fit line. - Number of domain Considered in Multi-Hop time synchronization is Limited.

33. References • lecs.cs.ucla.edu/Publications/papers/broadcast-osdi.pdf • en.wikipedia.org/wiki/Wireless_sensor_network • www.isi.edu/scadds/papers/timesync.pdf • www.circlemud.org/~jelson/writings/timesync/ • lecs.cs.ucla.edu/~jelson/dissertation-final.pdf

34. THANK YOU

35. QUESTIONS?