910 likes | 1.44k Views
Chapter 6 Time Synchronization. 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)
E N D
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
6.1 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
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, ...)
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
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
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?
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 each other in a multihop network
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
6.2 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?
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
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
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 Coordinated Universal Time (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
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
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)
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)
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
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
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 imprecision is preferred • Synchronization imprecision is the sum of variability in data from the server to the root
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
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
LTS – Pair-wise Synchronization • Assumptions: • Node i’s original aim is to estimate the true offset O = Δ(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 Δ(t5) and assumes Δ(t5) = Δ(t1) • There is one propagation delay τ and one packet transmission delay tp between nodes i and j
Li(t5) t5 >= t1+ τ+tp where τ :propagation delay tp:packet transmission time
t5 <= t8- τ- tp where τ :propagation delay tp:packet transmission time Li(t5)
The uncertainty is in the interval [Li(t1) +τ+ tp, Li(t8) - τ – tp – (Lj(t6) – Lj(t5)] Li(t5)
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
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
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
Number of trials Pair-wise difference in packet reception time (μsec) LTS – Pairwise Synchronization – Error Analysis
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
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
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
Timing-sync Protocol for Sensor Networks (TPSN) • Level discovery Phase • Trivial • Synchronization Phase • Pair-wise sync is performed along the edge of hierarchical structure
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
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
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
Timing-sync Protocol for Sensor Networks (TPSN) • Simulation and Comparison
Timing-sync Protocol for Sensor Networks (TPSN) • Simulation and Comparison
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
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
Flooding Time Synchronization Protocol (FTSP) • The root election phase • FTSP utilizes a simple election process based on unique node IDs • Synchronization phase
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
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
Flooding Time Synchronization Protocol (FTSP) Timestamp Timestamp Timestamp rootID rootID rootID seqNum seqNum seqNum Root A B C
Flooding Time Synchronization Protocol (FTSP) • Simulation and Conclusion