1 / 92

Chapter 6 Time Synchronization

This chapter explores various time synchronization protocols in wireless sensor networks, including protocols based on sender/receiver synchronization and receiver/receiver synchronization. It discusses the challenges of time synchronization and the different properties and performance metrics of these protocols.

mount
Download Presentation

Chapter 6 Time Synchronization

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. Chapter 6Time Synchronization

  2. Outline • 6.1. The Problems of Time Synchronization • 6.2. Protocols Based on Sender/Receiver Synchronization • Network Time Protocol (NTP) • Timing-sync Protocol for Sensor Networks (TPSN) • Flooding Time Synchronization Protocol (FTSP) • 6.2.4. Ratio-based time Synchronization Protocol (RSP) • 6.3. Protocols Based on Receiver/Receiver Synchronization • Reference Broadcast Synchronization (RBS) • Hierarchy Referencing Time Synchronization (HRTS) • 6.4. Summary

  3. 6.1. The Problems of Time Synchronization

  4. The Problems of Time Synchronization • Why Need for Time Synchronization? • Many of the applications of WSN needs the event with time stamp • Ordering of the samples for reporting • Events are reported by multiple nodes • When WSN is energy save enabled, it need all nodes to be in sync in order to be in Idle or Active mode • Medium Access Layer (MAC) Scheduling (ex: TDMA) • Order of messages may change while transmission

  5. Sources of Inaccuracies • A local software clock of node i at time tLi(t) = qiHi(t) + fi • Hi(t): hardware clock of node i at time t • qi :clock drift rate of node i • fi :phase shift of node i • Actual oscillators have random deviations from nominal frequency (drift, skew) • additional pulses or lost pulses over the time of one million pulses at nominal rate • Oscillator frequency is time variable • Long-term variation: oscillator aging • Short-term variation: environment (temperature, pressure, supply voltage, ...)

  6. General Properties of Time Synchronization Algorithms • Physical time vs. logical time • External vs. internal synchronization • Global vs. local algorithms • Keep all nodes of a WSN synchronized or only a local neighborhood? • Absolute vs. relative time • Only accurate time difference • Sufficient to estimate the drift instead of phase offset

  7. General Properties of Time Synchronization Algorithms • Hardware vs. software-based mechanisms • A GPS receiver would be a hardware solution, but often too heavyweight/costly/energy-consuming in WSN nodes, and in addition a line-of-sight to at least four satellites is required • A-priori vs. a-posteriori synchronization • Is time synchronization achieved before or after an interesting event?  Post-facto synchronization: is triggered by an external event • Deterministic vs. stochastic precision bounds • Local clock update discipline • No backward jumps of local clocks • No sudden jumps

  8. Performance Metrics and Fundamental Structure • Metrics: • Precision: maximum synchronization error for deterministic algorithms, mean error /stddev /quantiles for stochastic ones • Energy costs, e.g. # of exchanged packets, computational costs • Memory requirements • Fault tolerance: what happens when nodes die?

  9. Fundamental Building Blocks of Time Synchronization Algorithms • Resynchronization event detection block: • when to trigger a time synchronization round? • Remote clock estimation block: • figuring out the other nodes clocks with the help of exchanging packets • Clock correction block: • compute adjustments for own local clock based on remote clock estimation • Synchronization mesh setup block: • figure out which node synchronizes with which other nodes

  10. Constraints for Time Synchronization in WSNs • Scale to large networks of unreliable nodes • Quite diverse precision requirements, • from ms to tens of seconds • Use of extra hardware is mostly not an option • Low mobility • Often there are no fixed upper bounds on packet delivery delay • Negligible propagation delay between neighboring nodes is negligible • Manual node configuration is not an option

  11. 6.2. Protocols Based on Sender/Receiver Synchronization

  12. Protocols Based on Sender/Receiver Synchronization • In this kind of protocols, a receiver synchronizes to the clock of a sender • The classical Network Time Protocol (NTP) belongs to this class • We have to consider two steps: Pair-wise synchronization • How does a single receiver synchronize to a single sender? • Network wide synchronization • How to figure out who synchronizes with whom to keep the whole network / parts of it synchronized?

  13. Network Time Protocol (NTP) • Synchronizing Physical Clocks • Computer Clocks in distributed system not in consistent • Need to synchronize clocks • External synchronization (ES) • Synchronized with an external reliable time source S • |S - C| < D, where C is computer’s clock • Internal synchronization (IS) • Synchronized with other computer in the distributed system • | Ci - Cj| < D • IS does not imply ES • Clock Ci and Cj may drift together • ES implies IS • Within bound 2D

  14. Network Time Protocol (NTP) • Distributed System Type • Synchronous distributed system • Known upper bound on transmission delay • Simplifies synchronization • One process p1 sends its local time t to process p2 in a message m • p2 could set its clock to t + Ttrans , where Ttrans is transmission delay from p1 to p2 • Ttrans is unknown but min≤Ttrans≤max • Set clock to t + (max - min)/2 then skew ≤ (max - min)/2 • Asynchronous distributed system • Internet is asynchronous system • Ttrans = min + x where x≥ 0

  15. mr mt p Time server S Network Time Protocol (NTP) • Cristian’s method (1989) for an asynchronous system • A time server S receives signals from a UTC source • Process p requests time in mr and receives t in mtfrom S • p sets its clock to t - Tround/2 • Accuracy ± (Tround/2- min) : • because the earliest time S puts t in message mt is min after p sent mr. • thelatest time was min before mtarrivedat p • the time by S’s clock when mt arrives is in the range [t + min, t + Tround - min] • Troundis observed round-trip time • min is minimum delay between p and S

  16. Network Time Protocol (NTP) • Issues with Christian’s Algorithms • A single time server might fail, so they suggest the use of a group of synchronized servers • It does not deal with faulty servers • No authentication mechanism • Inaccuracy increases if the delay between messages is non-negligible

  17. Network Time Protocol (NTP) Primary servers are connected to UTC sources 1 Secondary servers are synchronized to primary servers Synchronization subnet - lowest level servers in users’ computers 2 2 3 3 3 Reliability from redundant paths, scalable, authenticates time sources • A time service for the Internet - synchronizes clients to UTC (Coordinated Universal Time)

  18. Network Time Protocol (NTP) • Synchronisation of servers • The synchronization subnet can reconfigure if failures occur, e.g. • a primary that loses its UTC source can become a secondary • a secondary that loses its primary can use another primary • Modes of synchronization: • Multicast • A server within a high speed LAN multicasts time to others which set clocks assuming some delay (not very accurate) • Procedure call • A server accepts requests from other computers (like Cristiain’s algorithm). Higher accuracy. Useful if no hardware multicast. • Symmetric • Pairs of servers exchange messages containing time information • Used where very high accuracies are needed (e.g. for higher levels)

  19. Network Time Protocol (NTP) Server B Ti-2 Ti-1 Time m m' Time Ti-3 Ti Server A • Messages exchanged between a pair of NTP peers • All modes use UDP • Each message bears timestamps of recent events: • Local times of Send and Receive of previous message • Local times of Send of current message • Recipient notes the time of receipt ( we have Ti-3, Ti-2, Ti-1, Ti) • In symmetric mode there can be a non-negligible delay between messages

  20. Network Time Protocol (NTP) • Accuracy of NTP • For each pair of messages between two servers, • NTP estimates an offset oi between the two clocks and a delay di (total time for the two messages, which take t and t’) • Ti-2 = Ti-3+ t + o and Ti = Ti-1+ t’ - o • This gives us (by adding the equations) : • di = t + t’ = Ti-2 - Ti-3 + Ti - Ti-1 • Also (by subtracting the equations) • o = oi + (t’ - t )/2 where oi = (Ti-2 - Ti-3 + Ti-1 - Ti)/2 • Using the fact that t, t’ >0 it can be shown that • oi - di /2 ≤ o ≤ oi + di /2 . • Thus oi is an estimate of the offset and di is a measure of the delay

  21. Network Time Protocol (NTP) • Techniques to Improve Accuracy • NTP servers filter pairs <oi, di>, estimating reliability from variation, allowing them to select peers • High variability in successive pairs implies unreliable data • Accuracy depends on the delay between the NTP servers • Accuracy of 10s of millisecs over Internet paths (1 on LANs) • Peer selection • Lower layer peer favoured over higher layer server • Peer with lower synchronization dispersion is preferred • Synchronization dispersion is the sum of variability in data from the server to the root

  22. LTS – Lightweight Time Synchronization • Overall goal: • Synchronize the clocks of all sensor nodes of a subset of nodes to one reference clock (e.g. equipped with GPS receivers) • Considers only phase shifts • Does not try to correct different drift rates

  23. LTS – Lightweight Time Synchronization • Two components: • Pair-wise synchronization: • based on sender/receiver technique • Network wide synchronization: • Minimum-height spanning tree construction with reference node as root

  24. LTS – Pairwise Synchronization

  25. LTS – Pair-wise Synchronization • Assumptions: • Node i’s original aim is to estimate the true offset O = D(t1) = Li(t1) – Lj(t1), where Li(tj) is the local software clock of node i at time tj • During the whole process the drift is negligible  the algorithm in fact estimates D(t5) and assumes D(t5) = D(t1) • Propagation delay τ and packet transmission delay tp are known to nodes i and j

  26. Li(t5)

  27. Li(t5) t5 >= t1+ τ+tp where τ :propagation delay tp:packet transmission time

  28. t5 <= t8- τ- tp where τ :propagation delay tp:packet transmission time Li(t5)

  29. The uncertainty is in the interval [Li(t1) +τ+ tp, Li(t8) - τ – tp – (Lj(t6) – Lj(t5)] Li(t5)

  30. LTS – Pair-wise Synchronization • Under the assumption that the remaining uncertainty is allocated equally to both i and j, node i can estimate Li(t5) as This exchange takes two packets. If node j should also learn about the offset, a third packet is needed from i to j carrying O

  31. LTS – Pair-wise Synchronization • Sources of inaccuracies: • Medium access delay • Interrupt latencies upon receiving packets • Delays between packet interrupts and time-stamping operation • Delay in operating system and protocol stack

  32. LTS – Pair-wise Synchronization • Improvements: • Let node i timestamp its packet after the MAC delay, immediately before transmitting the first bit • This would remove the uncertainty due to i’s operating system, protocol stack and the MAC delay!! • Let node j timestamp receive packets as early as possible, e.g. in the interrupt routine • This removes the delay between packet interrupts and time-stamping from the uncertainty, and leaves only interrupt latencies

  33. LTS – Pair-wise Synchronization – Error Analysis • Pairwise differences in time-stamping times at a set of receivers when time-stamping happens in the interrupt routine (Berkeley motes) • The motes raise an I/O pin at the same time they timestamp the packet • I/O signals were picked by an external logic analyzer • Another node send 160 pulse packets at random time • For each pulse packets, the difference of each of 10 possible receiver pairs are captured.

  34. Number of trials Pair-wise difference in packet reception time (μsec) LTS – Pairwise Synchronization – Error Analysis

  35. LTS – Networkwide Synchronization • This way a spanning tree is created • But one should not allow arbitrary spanning trees • Consider a node i with hop distance hi to the root node • Assume that: • all synchronization errors are independent • Hence, a minimum spanning tree minimizes synchronization errors

  36. Timing-sync Protocol for Sensor Networks (TPSN) • Introduction • We present a Timing-sync Protocol for Sensor Networks (TPSN) that works on the conventional approach of sender-receiver synchronization • Pair-wise-protocol: time-stamping at node i happens immediately before first bit appears on the medium, and time-stamping at node j happens in interrupt routine

  37. Timing-sync Protocol for Sensor Networks (TPSN) • Network Model • The network is “always-on” • Every node maintains 16-bit register as clock • Sensor has unique ID • Build hierarchical topology for the network • Node at level i can connect with at least one node at level i-1

  38. Timing-sync Protocol for Sensor Networks (TPSN) • Level discovery Phase • Trivial • Synchronization Phase • Pair-wise sync is performed along the edge of hierarchical structure

  39. Timing-sync Protocol for Sensor Networks (TPSN) • Level discovery Phase • The root node is assigned a level 0 and it initiates this phase by broadcasting a level_discovery packet • level_discovery packet contains the identity and the level of the sender • The immediate neighbors of the root node receive this packet and assign themselves a level (level= level +1) • This process is continued and eventually every node in the network is assigned a level. On being assigned a level, a node neglects any such future packets. This makes sure that no flooding congestion takes place in this phase

  40. Timing-sync Protocol for Sensor Networks (TPSN) • Synchronization Phase • T1: A is sender, starting sync by sending synchronization_pulse packet to B • T2 = T1 + Δ + d, where • Δ is the clock offset • d is propagation delay • T3: B replies acknowledgement containing T1, T2, T3 • T4: A receive ack. and T4 = T3 – Δ + d. So: • Δ = [(T2－T1) － (T4－T3)] / 2 • d = [(T2－T1) ＋ (T4－ T3)] / 2

  41. Timing-sync Protocol for Sensor Networks (TPSN) • Synchronization Phase A receive an Ack and get timestamp T4 B replies acknowledgement containing T1,T2,T3 T1: A is sender, starting sync by sending synchronization_pulse packet to B with timestamp T1 TB receive the synchronization _pulse packet and ti2:mestamping immediately T1,T2,T3 T2 B T1 A T4 At time t1 At time t4 At time t2 At time t3

  42. Timing-sync Protocol for Sensor Networks (TPSN) • Simulation and Comparison

  43. Timing-sync Protocol for Sensor Networks (TPSN) • Simulation and Comparison

  44. Flooding Time Synchronization Protocol (FTSP)

  45. Flooding Time Synchronization Protocol (FTSP) • Introduction • The FTSP synchronizes the time to possibly multiple receivers utilizing a single radio message • Linear regression is used in FTSP to compensate for clock drift

  46. Flooding Time Synchronization Protocol (FTSP) • Network Model • Every node in the network has a unique ID • Each synchronization message contains three fields: • TimeStamp • RootID • SeqNum • The node with the smallest ID will be only one root in the whole network

  47. Flooding Time Synchronization Protocol (FTSP) • The root election phase • FTSP utilizes a simple election process based on unique node IDs • Synchronization phase

  48. Flooding Time Synchronization Protocol (FTSP) • The root election phase • When a node does not receive new time synchronization messages for a number of message broadcast periods • The node declares itself to be the root • Whenever a node receives a message, the node with higher IDs give up being root • Eventually there will be only one root

  49. Flooding Time Synchronization Protocol (FTSP) • Synchronization phase • Root and synchronized node broadcast synchronization message • Nodes receive synchronization message from root or synchronized node • When a node collects enough synchronization message, it estimates the offset and becomes synchronized node

More Related