1 / 35

Table of contents

FINE-GRAINED NETWORK SYNCHRONIZATION USING REFERENCE BROADCAST PRESENTED BY ANJU SURYAWANSHI MITA RANA. Table of contents. Time synchronization- Introduction Related work Traditional synchronization methods-NTP Challenges for time-sync in Sensor networks

malina
Download Presentation

Table of contents

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

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

  21. RBS: Comparison with NTPResults

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

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

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

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

  26. 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)

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

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

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

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

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

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

  33. THANK YOU

  34. QUESTIONS?

More Related