1 / 47

Time Synchronization in Sensor Networks

Time Synchronization in Sensor Networks. EE206A Athanasios Stathopoulos Huiyu Luo. Time Synchronization in Ad Hoc Networks. Kay Romer. The Sensor Network Here. Nodes are highly dynamic & sparsely distributed Links are short range and short lived

torgny
Télécharger la présentation

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. Time Synchronization in Sensor Networks EE206A Athanasios Stathopoulos Huiyu Luo

  2. Time Synchronization in Ad Hoc Networks Kay Romer

  3. The Sensor Network Here • Nodes are highly dynamic & sparsely distributed • Links are short range and short lived • Messages are transmitted in a store and forward fashion 1 2 3

  4. Synch Sensor Network • Temporal relations play an important role in sensor fusion Which event happened first? • Physical time is itself part of information: e.g. Estimation of target position, direction, speed Providing fire breaking time

  5. Difficulties! • No periodic message exchange is guarante-ed to occur among nodes There may be no links at all • Transmission delay between two nodes is hard to estimate The link distance changes all the time

  6. About Computer Clocks • Clocks in computers • Clock Skew  • Due to the clock drift, the local clock need to be periodically synchronized to maintain an accurate global time

  7. Synchronization Scheme • Don’t try to synchronize local clocks all the time • Generate time stamps to record the events’ occurring time • The time stamps are updated along its way by each node using its own local clock • As the result of clock shift and message propagation delay, the final time stamp is expressed as a lower and upper bound

  8. An Example When 1 senses an event, it starts counting time with its clock. 1 sends 2 a message regarding the event, and a time stamp including how long the time has elapsed since the event 1 2 3 N

  9. 1 2 3 N A Example (Continued) 2 estimates the transmission delay to the time stamp and continues counting the time Messages are forwarded the same fashion as 12 to node N N is able to recover the time by looking at the time stamp

  10. Assumptions • Maximum clock skew is known • The link can survive long enough so that a synchronization message can be sent after the application message

  11. Time Transformation • Recall • Real time estimation based on clock 1 • Time difference in local clock 2

  12. t4 t5 t6 M1 ACK1 M2 ACK2 t3 t1 t2 Message Delay Estimate delay for M2 Sender: Receiver: Receiver Sender

  13. Note • A transmission of M2 is necessary for receiver to obtain an estimation of delay! Dummy message might need to be sent • It is desirable to make the interval between M1 and M2 short • Notation idle=t2-t1 rtt=t3-t2

  14. 1 2 3 N Add Them Together! • Node N puts together the time counted by all the nodes and message delays idle1 idle2 rtt1 rtt2 r1 r2 r3 rN s1 sN s2 s3 3 N 1 2

  15. This Results in

  16. Evaluation Shows • Inaccuracy is proportional to time stamp length • Time stamp length increases linearly with • the age of time stamp • the number of hops S1 S2

  17. A Simulation • Number of hops <= 5 • Age of time stamp <= 500 s • Length of time stamp <= 3 ms • Able to distinguish two events with time separation >= 6 ms

  18. Possible Improvements • Store and forward the history of time stamp. • Look for common node in history when two time stamps overlap • When events have overlapping time stamps • Use statistical tools to analyze the probability that one event happens before another

  19. Conclusion • The difficulties in synchronizing a type of sensor network are being considered • A new scheme has been proposed • Provides low overhead for a sparse sensor network with low data rate • The time estimation is well bounded • The scheme is evaluated and possible improvements are further proposed

  20. Network-wide Time Synchronization in Sensor Networks Saurabh Ganeriwal Ram Kumar Sachin Adlakha Mani Srivastava

  21. Basic Concept • First create a hierarchical topology in the level discovery phase • As a result, each node is assigned a unique level:0 (root node)12…N • A time synchronization phase is initialized by the root node • Each node synchs to the node which is one level lower than itself

  22. Sender Initiated Synch • Clock drift  and propagation delay d between two nodes are estimated by T2 T3 Receiver T1 T4 Sender

  23. Algorithms • Level discovery • Time synchronization • New node: Level request • Root node dies: Local leader election

  24. Level Discovery • Root node initiates the phase by broadcast-ing a level_discovery packet • Upon receiving the packet, each node assi-gns itself a level and broadcast a new level-_discovery packet • Eventually each node in the network is assigned a unique level

  25. Time Synchronization • Root starts the phase by broadcasting a time_synch packet • Nodes in level one wait for some random time and start a two way message exchange to synch their local clocks • This is carried out throughout the whole network

  26. Special Cases • If a node is not assigned a level due to collision or new node, level request is being sent to recover a level from its neighbors • If the root node dies, the level one nodes will undergo a local leader election algorithm

  27. Simulation • Overhead time vs. # of nodes

  28. Simulation • Accuracy synch error vs. level #

  29. Conclusion • A synchronization scheme for absolute time in sensor networks was introduced • The algorithms are scalable since • The accuracy is independent of number of nodes and node clock drift • The overhead is linearly proportional to the network size

  30. Fine-Grained Network Time Synchronization using Reference BroadcastsJeremy Elson, Lewis Girod and Deborah EstrinLECS Lab, UCLA

  31. 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 • E.g. Internet (coarse grain synchronization) • Inefficient when fine-grain sync is required • E.g. sensornet applications: localization, beamforming, TDMA scheduling etc

  32. Sources of time synchronization error • Send time • Kernel processing • Context switches • Transfer from host to NIC • Access time • Specific to MAC protocol • E.g. in Ethernet, sender must wait for clear channel • Propagation time • Dominant factor in WANs • Router-induced delays • Very small in LANs • Receive time • Common denominator: non-determinism

  33. Proposed solution: Reference Broadcast Synchronization • RBS synchronizes a set of receivers with each other • In contrast, traditional timesync protocols synchronize a sender with a receiver • Nodes periodically send beacon messages to their neighbors • Requirement: broadcast medium • No-go for point-to-point links • But, can be extended beyond a LAN

  34. RBS: Minimizing the critical path • 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 All figures from Elson et. al.

  35. RBS: 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

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

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

  38. RBS: Clock skew estimation • 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 • RBS compensation: instead of averaging phase offsets, perform least-squares linear regression • 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

  39. RBS: Clock skew estimationImplementation 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

  40. RBS: Comparison with NTP • Comparison performed on commodity hardware • IPAQs running Linux • 802.11 wireless Ethernet adapters • RBS, NTP are user-space drivers • 3 different synchronization schemes • RBS • NTP • NTP-Offset • NTP by default limits rate at which it corrects phase error • Although it still keeps an estimate of it • meant to prevent transient frequency errors from being visible in applications • Solved by querying NTP daemon on each trial • Two traffic scenarios • Light load • Heavy load

  41. RBS: Comparison with NTPResults

  42. RBS: Multi-Hop 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) • Desired time = E1(R7)-E7(R7)

  43. Physical topology Logical topology. Edges are drawn between nodes that have received a common broadcast RBS: Multi-Hop synchronization(cont’d) • Path through logical topology represents a series of timebase 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

  44. GPS Clocks • GPS system’s master clock always kept to within 1 usec accuracy of USNO’s master clock • Each satellite has 4 atomic clocks on board • Always kept within 250 nsec accuracy of each other • LOS to only one satellite needed to extract time information • GPS clock can generate an interrupt every second (thereby sending a PPS) • PPS accuracy of commercial GPS clocks is 1 usec • Cost: ~ $400

  45. RBS: Synchronization with external time scale (GPS) • Absolute time synchronization required for many applications • Reference timescales available via systems like GPS • A GPS receiver can be a node in the RBS-synchronized network • PPS output is the reference broadcast • Host node attached to GPS receiver synchronizes its clock to the GPS time • Phase and skew of node’s clock relative to GPS time can be recovered using presented algorithms • Other nodes can use GPS time by finding multihop conversion route

  46. RBS: Conclusions • Synchronizes a set of receivers with each other • Broadcasts remove largest sources of non-deterministic error • Residual receiver error is often a well-behaved distribution • RBS outperforms NTP • 8 times better for light load • Remarkable performance on heavy load • Multiple broadcasts allow estimation of clock skew • Useful for post-facto synchronization • Extendable across broadcast domains • Can use global timescale • Cannot be applied to the Internet at large • Only works with broadcast medium, not point-to-point links

  47. References • Kay Romer Time Synchronization in Ad Hoc Networks • Saurabh Ganeriwal et al. Network-wide Time Synchronization in Sensor Networks • Jeremy Elson et al. Fine-Grained Network Time Synchronization Using Reference Broadcasts • http://www.gpsclock.com/gps.html

More Related