Presentation is loading. Please wait.

Presentation is loading. Please wait.

Chapter 6 Time Synchronization

Similar presentations


Presentation on theme: "Chapter 6 Time Synchronization"— Presentation transcript:

1 Chapter 6 Time 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) 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 時間同步的演算法,主要有兩種類型 Sender/Receiver Receiver/Receiver 以Sender/Receiver方式的演算法,包含NTP、TPSN、FTSP、RSP 而以Receiver/Receiver方式的演算法,則包含RBS與HRTS 2017/4/20

3 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 為什麼需要時間同步? 1. 有許多的WSN中的應用,需要事件發生時的時間資料。 2. 當有取樣資料回報時,需要有時間的次序。 3. 事件從許多個節點回報時,也需要有時間的資料,才能知道先後次序。 4. 當WSN中的節點,開啟Energy save的功能後,需要所有的節點彼此有時間同步,才能讓節點間彼此知道還時該Idle何時該Active。 5. MAC的Scheduling也需要時間同步才能達成 6. 當傳送資料時,資料的順序可能會改變,因此需要時間同步,才能知道每個資料彼此間的先後次序。 2017/4/20

4 Sources of Inaccuracies
A local software clock of node i at time t Li(t) = qi Hi(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, ...) 2017/4/20

5 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 2017/4/20

6 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 2017/4/20

7 Performance Metrics and Fundamental Structure
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? 2017/4/20

8 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 2017/4/20

9 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 2017/4/20

10 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? 2017/4/20

11 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 2017/4/20

12 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 For internal synchronization discuss min is the time to transmit a message when nothing else is going on. max is the upper bound .The internet is an asynchronous system because there is no upper bound on message transmission delays. 2017/4/20 12

13 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 mt from 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. the latest time was min before mt arrived at p the time by S’s clock when mt arrives is in the range [t + min, t + Tround - min] Tround is observed round-trip time min is minimum delay between p and S The algorithm is probabilistic. Works if round trip times are shortB mr mt p Time server S 2017/4/20 13

14 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 2017/4/20

15 Network Time Protocol (NTP)
A time service for the Internet - synchronizes clients to UTC (Coordinated Universal Time) Reliability from redundant paths, scalable, authenticates time sources Primary servers are connected to UTC sources Secondary servers are synchronized to primary servers Synchronization subnet - lowest level servers in users’ computers animates the points reliability, primary and secondary servers 1 2 3 2017/4/20 15

16 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) 2017/4/20

17 Network Time Protocol (NTP)
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 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 Ti Ti-1 Ti-2 Ti-3 Server B Server A Time m m' 2017/4/20 17

18 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 from the above: o-oi = (t’-t)/2 therefore |o-oi| = |t’-t|/2 now |t’-t| <= |t’+t| = di therefore |o-oi| <=di/2. i.e. o-oi<=dii/2 or o<oi+di/2 also -o+oi<= di/2 i.e. oi-di/2 <= o 2017/4/20 18

19 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 2017/4/20

20 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 2017/4/20

21 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 2017/4/20

22 LTS – Pairwise Synchronization
2017/4/20

23 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 2017/4/20

24 Li(t5) 2017/4/20

25 where τ :propagation delay tp :packet transmission time
Li(t5) t5 >= t1+ τ +tp where τ :propagation delay tp :packet transmission time 2017/4/20

26 where τ :propagation delay tp :packet transmission time
t5 <= t8- τ- tp where τ :propagation delay tp :packet transmission time Li(t5) 2017/4/20

27 The uncertainty is in the interval [Li(t1) + τ + tp, Li(t8) - τ – tp – (Lj(t6) – Lj(t5)]
2017/4/20

28 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 2017/4/20

29 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 2017/4/20

30 2017/4/20

31 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 2017/4/20

32 LTS – Pairwise Synchronization – Error Analysis
Pair-wise difference in packet reception time (μsec) Number of trials 2017/4/20

33 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 2017/4/20

34 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 Tpsn 的簡介 主要講說 tspn 是傳統的 傳送端 – 接收端 同步方式 他是一個類似LTS(兩兩同步)的 協定 但主要差別是在TPSN 蓋TIMESTAMP 的時機 最後PAPER 有跟 RBS 作比較 2017/4/20

35 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 解說 network model 重點在 第3,4 和 5 行 Tpsn 的網路是層狀架構 2017/4/20

36 Timing-sync Protocol for Sensor Networks (TPSN)
Level discovery Phase Trivial Synchronization Phase Pair-wise sync is performed along the edge of hierarchical structure Tpsn protocol 分成兩個 phase 第一個phase 大概是用broadcast的方式 從root 開始,讓每個node找出自己的在第几個level 第二個phase 就是兩兩作同步的phase 2017/4/20

37 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 從root 開始 用 broadcast的方式找出自己對應的level 例如 root 的level 是0 所以root 會broadcast 自己的level 訊息,收到封包的node 會把自己的level 定為 0+1 = 1(packet 中的 level 加1) 當確認自己level 後的node 會同樣broadcast 自己的level 訊息 如此類推 2017/4/20

38 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 Tpsn 的核心 說明 只要在 t1 t2 t3 t4 等時間點蓋timestamp 就能計算出時間差 Δ 重點他跟TLS 不一樣的地方是 蓋 timestamp 的timing Tpsn 是在底層蓋timestamp 讓誤差達到最小 2017/4/20

39 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 T B receive the synchronization _pulse packet and ti2:mestamping immediately T2 T1,T2,T3 B Tpsn 同步時傳送封包的過程 和 說明 T1 A T4 At time t3 At time t2 At time t1 At time t4 2017/4/20

40 Timing-sync Protocol for Sensor Networks (TPSN)
Simulation and Comparison 比較 tpsn 和 rbs 的誤差值 從數據中顯示 Tpsn 比 rbs 好 2017/4/20

41 Timing-sync Protocol for Sensor Networks (TPSN)
Simulation and Comparison 分析 tpsn 在 mutihop 下 的誤差 2017/4/20

42 Flooding Time Synchronization Protocol (FTSP)
2017/4/20

43 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 2017/4/20

44 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 2017/4/20

45 Flooding Time Synchronization Protocol (FTSP)
The root election phase FTSP utilizes a simple election process based on unique node IDs Synchronization phase 流程分兩個phase The root election phase Synchronization phase 2017/4/20

46 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 1.如果node經過一段時間沒收到 同步的封包,他就把自已當做root 2.如果收到其他人的同步封包,自已的id比別人大就放棄成為root 3.最後只剩下一個node做為root 2017/4/20

47 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 同步phase 1.Root和已經同步的node廣播同步封包 2.Node從這兩種來源收到同步封包 3.當有足夠的資料就做線性回歸,來估算自已的local time 和global time的轉換 2017/4/20

48 Flooding Time Synchronization Protocol (FTSP)
Timestamp rootID seqNum Timestamp rootID seqNum Root Timestamp rootID seqNum A B C Synchronized Node Unsynchronized node 2017/4/20

49 Flooding Time Synchronization Protocol (FTSP)
Simulation and Conclusion 黑線:網路中任兩個node的差值平均 紅線:網路中任兩個node的差值,最大的 藍線:已經同步的node數百分比 2017/4/20

50 Ratio-based Time Synchronization Protocol (RSP)
2017/4/20

51 Ratio-based Time Synchronization Protocol (RSP)
The RSP use two synchronization messages to synchronize the clock of the receiver with that of sender The RSP also can extend to multi-hop synchronization The nodes in the wireless sensor network construct a tree structure and the root of this tree is the synchronization root The global time of the root is flooding out to the nodes through the tree structure 2017/4/20

52 Ratio-based Time Synchronization Protocol (RSP)
The local clock time of a sensor device is provided by the quartz oscillator inside itself Transformation formula between t and Ci (t): By (1), the local clock times of two sensor nodes i and j have the following relationship: (1) : the local clock time of a sensor node i. t : the Coordinated Universal Time (UTC). : the drift ratio : the offset of node i’s clock at time t . (2) : relative drift ratio between nodes i and j : offset between the clocks of nodes i and j 2017/4/20

53 Ratio-based Time Synchronization Protocol (RSP)
Reference node Sensor node calculate the clock drift ratio θ = (T3 − T1)/(T4 −T2). 2017/4/20

54 Ratio-based Time Synchronization Protocol (RSP)
Reference node Sensor node Each node can estimate the local time of reference node in the following way: (3) : the local time of sensor node :the corresponding local time of the reference node. : the initial offset between reference node and sensor node. 2017/4/20

55 Ratio-based Time Synchronization Protocol (RSP)
It can be calculated using linear interpolation with the four time-stamps the can be derived as follows (4) 2017/4/20

56 Ratio-based Time Synchronization Protocol (RSP)
Therefore, we can derive (5) from (3) and (4): Each sensor node can estimate the local time of reference node, that is, the global time of the network (5) 2017/4/20

57 Ratio-based Time Synchronization Protocol (RSP)
Reference node Sensor node R S 參考點連續傳兩筆封包並計算上面的參數,使一般節點可與參考點達到同步 (T3) (T1) 2017/4/20

58 6.3. Protocols Based on Receiver/Receiver Synchronization
2017/4/20

59 Protocols Based on Receiver/Receiver Synchronization
In this class of schemes The receivers of packets synchronize among each other, not with the transmitter of the packet Reference Broadcast Synchronization (RBS) Synchronize receivers within a single broadcast domain RBS does not modify the local clocks of nodes, but computes a table of conversion parameters for each peer in a broadcast domain 2017/4/20

60 Reference Broadcast Synchronization (RBS)
Introduction Reference broadcasts do not have an explicit timestamp Receivers use reference broadcast’s arrival time as a point of reference for comparing nodes’ clocks Receivers synchronizes with one another using the message’s timestamp (which is different from one receiver to another) 收到同步封包的mote是和其他收到同樣封包的mote做時間同步,而不是封包來源的mote RBS維護一個TABLE來當mote與mote之間時間轉換的查詢表 2017/4/20

61 Reference Broadcast Synchronization (RBS)
Types of errors in traditional synchronization protocol Send time latency time spent at the sender to construct the message Access time latency time spent at the sender to wait for access to transmit the message Prorogation time latency time spent by the message in traveling from the sender to the receiver Receive time latency time spent at the receiver to receive the message from the channel and to notify the host RBS以前的同步方法會有的誤差來源 2017/4/20

62 Reference Broadcast Synchronization (RBS)
Types of errors in RBS Phase error due to nodes’ clock that contains different times Clock skew due to nodes’ clock that run at different rates RBS的同步方法會有的誤差來源 2017/4/20

63 Reference Broadcast Synchronization (RBS)
Difference between RBS & Traditional synchronization protocol RBS Synchronizes a set of receivers with one another Supports both single hop and multi-hop networks Traditional Senders synchronizes with receivers mostly supports only single hop networks RBS與傳統的差異比較 2017/4/20

64 Reference Broadcast Synchronization (RBS)
The phase offset with the clock skew is estimated by: Least-squares linear regression graph From the best-fit line of the graph, following can be inferred: Slope of the line : Clock skew of the nodes’ clock Intercept of the line : Phase of the nodes’ clock RBS如何解決 clock skew的問題 斜率:clock skew的比值 截距:經過時間的轉換 2017/4/20

65 Reference Broadcast Synchronization (RBS)
Basic idea to estimate phase offset and clock skew for non-deterministic receivers: Transmitter broadcasts m reference packets Each of the n receivers records the time that the reference was received, according to its local clock The receivers exchange their observation Each receiver i can compute its phase offset to any other receiver j Drift can be neglected when observations are exchanged quickly after reference packets Drift can be estimated jointly with offset O when a number of periodic observations of Oi,j have been collected Receiver交換收到同步封包的時間點,每個receiver再各自算出轉換的offset 2017/4/20

66 Reference Broadcast Synchronization (RBS)

67 Reference Broadcast Synchronization (RBS)
Formula for calculating the phase offset and clock skew of receiver r1 with another receiver r2: Let tr,b be r’s clock when it received broadcast b for each pulse k that was received by receivers r1 and r2 , we plot a graph : x = tr1, k y = tr2,k – tr1,k Diagonal line drawn through the points represents the best linear fit to the data 與basic相差無幾,只是用線性回歸來估算轉換的比值 2017/4/20

68 Reference Broadcast Synchronization (RBS)
Diagonal line minimizes the residual error (RMS) Therefore, we go for calculating the slope and intercept of the diagonal line Time value of r1 is converted to time value of r2 by combining the slope and intercept data obtained 2017/4/20

69 Reference Broadcast Synchronization (RBS)
Step1: Transmitter broadcasts Step2: Receiver records its local clock, and exchange observation Step3:Use Least-squares linear regression to estimate phase offset Finish RBS Reference Packet Reference Packet A:Local time B:Local time B A Transmitter Receiver 2017/4/20

70 Reference Broadcast Synchronization (RBS)
Communication costs: Be m the number of nodes in the broadcast domain First scheme: reference node collects the observations of the nodes, computes the offsets and sends them back  2 m packets Second scheme: reference node collects the observations of the nodes, computes the offsets and keeps them, but has responsibility for timestamp conversions and forwarder selection  m packets 2017/4/20

71 Reference Broadcast Synchronization (RBS)
Communication costs: Be m the number of nodes in the broadcast domain Third scheme: each node transmits its observation individually to the other members of the broadcast domain  m (m-1) packets Fourth scheme: each node broadcasts its observation  m packets, but unreliable delivery 2017/4/20

72 Reference Broadcast Synchronization (RBS)
Conclusion Collisions are a problem: the reference packets trigger all nodes simultaneously to tell the world about their observations Computational costs: least-squares approximation is not cheap! Can be used without external timescales Does not require tight coupling between sender and its network interface 2017/4/20

73 Hierarchy Referencing Time Synchronization (HRTS)
2017/4/20

74 Hierarchy Referencing Time Synchronization (HRTS)
Goal : Synchronize the vast majority of a WSN in a lightweight manner Idea Combine the benefits of LTS and RBS Main idea of HRTS comes from lightweight. LTS reduce packet load, and RBS promote LTS to nodes in one hop. 2017/4/20

75 Hierarchy Referencing Time Synchronization (HRTS)
LTS : Lightweight Time Synchronization Goal Synchronize the clocks of all sensor nodes of a subset of nodes to one reference clock It considers only phase shifts and does not try to correct different drift rates LTS is pairwise time synchronization protocol, so with lightweight packet LTS can synchronize two nodes. 2017/4/20

76 Hierarchy Referencing Time Synchronization (HRTS)
LTS : Pairwise Synchronization At time t3 At time t2 At time t4 At time t1 n1 n2 Record t1 Record t4 Record t2 Record t3 Sync packet Reply packet LTS uses only two packet. This slide shows how it works. In this packet contains t2 and t3 2017/4/20

77 Hierarchy Referencing Time Synchronization (HRTS)
The figure is the flow of LTS. 2017/4/20

78 Hierarchy Referencing Time Synchronization (HRTS)
LTS : Pairwise Synchronization Offset : O = Δ(t5 )=Li(t5) - Lj(t5)= [Li(t8)+ Li(t1)- Lj(t6)- Lj(t5)] / 2 Benefit : only two packet transmissions with each pair Benefit of RBS Idea : ignore transmission delay By this idea, one packet can synchronize every node in one hop Combining the two protocol’s benefit, the HRTS finds good solution to synchronize nodes in hierarchical way This slide shows offset calculating and benefit of LTS. Li(t5) = [Li(t8) + Li(t1)- (Lj(t6)- Lj(t5))] / 2 2017/4/20

79 Hierarchy Referencing Time Synchronization (HRTS)
The figure is the flow of HRTS. 2017/4/20

80 Hierarchy Referencing Time Synchronization (HRTS)
Timeline: Root node triggers time synchronization at t1 with timestamp LR(t1) Node i timestamps packet at time t2 with Li(t2) and node j timestamps it at t2’ with Lj(t2’) Node i formats a packet and timestamps it at time t3 with Li(t3) – the packet includes the values Li(t2) and Li(t3) Root node R timestamps the answer packet at time t4 with LR(t4) and computes its offset OR,i with node i’s clock OR,i =Li(t2) - LR(t2) = Li(t2) – (LR(t1) + LR(t4) – (Li(t3)- Li(t2))/2 =[ (Li(t2) - LR(t1)) – (LR(t4)- Li(t3))]/2 Root node R broadcasts the values OR,i and Li(t2) LR(t2) = (LR(t1) + LR(t4) – (Li(t3)- Li(t2))/2 2017/4/20

81 Hierarchy Referencing Time Synchronization (HRTS)
The root node R can estimate the offset OR,i between its own clock and the local clock i in a similar fashion as the protocol LTS Root R broadcast the values O and Li(t2) to all nodes Node i simply subtract the offset OR,i from its local clock Node j can compute Oj,i directly as Oj,i = Li(t2) – Lj(t’2) and OR,j = OR,i – Oj,i 2017/4/20

82 Hierarchy Referencing Time Synchronization (HRTS)- Discussion
Node j is not involved in any packet exchange  by this scheme is possible to synchronize an arbitrary number of nodes to R’s clock with only three packets!! The synchronization uncertainty comes from: The error introduced by R when estimating OR,i The error introduced by setting t2 = t2’ This makes HRTS only feasible for geographically small broadcast domains 2017/4/20

83 Hierarchy Referencing Time Synchronization (HRTS)- Discussion
Both kinds of uncertainty can again be reduced by: timestamping outgoing packets as lately as possible (relevant for t1 and t3) timestamping incoming packets as early as possible (relevant for t2, t2’, t4 ) The authors propose to use extra channels for synchronization traffic when late timestamping of outgoing packets is not an option Rationale: keep MAC delay small 2017/4/20

84 Hierarchy Referencing Time Synchronization (HRTS)
This slide shows how HRTS works. 2017/4/20

85 Summary Time synchronization is important for both WSN applications and protocols Using hardware like GPS receivers is typically not an option, so extra protocols are needed Post-facto synchronization allows for time synchronization on demand, otherwise clock drifts would require frequent resynchronization and thus a constant energy drain 對於WSN的應用和通訊協定來說,時間同步是很重要的 使用硬體如GPS接收器是很典型的方法,但非唯一的選擇,所以透過額外的通訊協定,達成時間同步是必須的 事後回溯(Post-facto) 時間同步,應該是隨選式(On Demand)的時間同步,也就是有需求時才進行時間同步,否則為了克服時間漂移的問題,將會需要經常性的重新時間同步和不停的消耗能量。 2017/4/20

86 Summary Some of the presented protocols take significant advantage of WSN peculiarity like: small propagation delays the ability to influence the node firmware to timestamp outgoing packets late, incoming packets early 某些已提出來的時間同步通訊協定,善用WSN的特質優勢,例如: 較小的傳遞延遲。 有能力影響節點的韌體,最後才在即將發送出去的封包中加上時間戳記,以及在一接收到的封包中最早加上時間戳記。 2017/4/20

87 References [1] Ed. Ivan Stojmenovic, Handbook of Sensor Networks Algorithms and Architectures, [2] F. Sivrikaya,and B.Yener, Time Synchronization in Sensor Networks: A Survey,2004. ( [2] J. Elson, L. Girod, and D. Estrin ,Fine-Grained Network Time Synchronization using Reference Broadcasts. (In Proceedings of the Fifth Symposium on OSDI 2002) [3] S. Ganeriwal, R. Kumar, and M. Srivastava, Timing-Sync Protocol for Sensor Networks. (SenSys ’03) [5] D. L. Mills. Network Time Protocol (Version 3) Specification, Implementation and Analysis. RFC 1305, [6] D. L. Mills. Improved Algorithms for Synchronizing Computer Network Clocks. IEEE/ACM Transactions on Networking, 3(3): 245–254, [7] D. L. Mills. Adaptive Hybrid Clock Discipline Algorithm for the Network Time Protocol. IEEE/ACM Transactions on Networking, 6(5): 505–514, 1998. 2017/4/20

88 References [8] S. Ganeriwal, R. Kumar, S. Adlakha, and M. Srivastava. Network-Wide Time Synchronization in Sensor Networks. Technical Report NESL , Networked and Embedded Systems Lab (NESL), University of California, Los Angeles (UCLA), [9] S. Ganeriwal, R. Kumar, and M. B. Srivastava. Timing-Sync Protocol for Sensor Networks. In Proceedings of the 1st ACM International Conference on Embedded Networked Sensor Systems (SenSys), pages 138–149, Los Angeles, CA, November [10] Miklós Maróti ,  Branislav Kusy ,  Gyula Simon ,  Ákos Lédeczi, The Flooding Time Synchronization Protocol, In Proceedings of the 2ed ACM International Conference on Embedded Networked Sensor Systems (SenSys), pages 39 – 49, Baltimore, MD, USA, [11] J.-P. Sheu, W.-K. Hu, and J.-C. Lin, Ratio-Based Time Synchronization Protocol in Wireless Sensor Networks, Telecommunication Systems, Vol. 39, No. 1, pp , Sep [12] J. Elson, L. Girod, and D. Estrin. Fine-Grained Network Time Synchronization using Reference Broadcasts. In Proceedings of the Fifth Symposium on Operating Systems Design and Implementation (OSDI 2002), Boston, MA, December 2002. [13] H. Dai and R. Han. TSync: A Lightweight Bidirectional Time Synchronization Service for Wireless Sensor Networks. ACM SIGMOBILE Mobile Computing and Communications Review, 8(1): 125–139, 2004. 2017/4/20

89 Recommend Reading Particular Challenges and Constraints for Time Synchronization Algorithms in WSN J. Elson and K. R¨omer. Wireless Sensor Networks: A New Regime for Time Synchronization. In Proceedings of the First Workshop on Hot Topics In Networks (HotNets-I), Princeton, NJ, October 2002. J. E. Elson. Time Synchronization in Wireless Sensor Networks. PhD dissertation, University of California, Los Angeles, CA, Department of Computer Science, 2003. Other Time Synchronization Protocol Lightweight time synchronization protocol (LTS) J. V. Greunen and J. Rabaey. Lightweight Time Synchronization for Sensor Networks. In Proceedings of the 2nd ACM International Workshop on Wireless Sensor Networks and Applications (WSNA), San Diego, CA, September 2003. 2017/4/20


Download ppt "Chapter 6 Time Synchronization"

Similar presentations


Ads by Google