chapter 6 time synchronization

Chapter 6Time 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) 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. Summary112/04/21

2 Jang Ping Sheu

6.1 The Problems of Time Synchronization Why Need for Time Synchronization (TS)?

Many of the applications of WSN needs the event with time stamp

Ordering of the samples for reportingEvents are reported by multiple nodesWhen WSN is energy save enabled, it need all nodes to

be in sync in order to be in Idle or Active modeMedium Access Layer (MAC) Scheduling (ex: TDMA)Order of messages may change while transmission

112/04/213 Jang Ping Sheu

Sources of Inaccuracies

A local software clock of node i at time t Li(t) = i Hi(t) + i

Hi(t): hardware clock of node i at time t

i :clock drift rate of node i

i :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 (ppm) Oscillator frequency is time variable

Long-term variation: oscillator aging Short-term variation: environment (temperature,

pressure, supply voltage, ...)4

112/04/21Jang Ping Sheu

General Properties of TS Algorithms

Physical time vs. logical time External vs. internal synchronization

Algorithms may or may not require TS with external time scale like UTC

Global vs. local algorithms Keep all nodes of a WSN synchronized or only a local

neighborhood? Absolute vs. relative time

Many applications need only accurate time difference and it would be sufficient to estimate the drift instead of phase offset

5112/04/21

Jang Ping Sheu

General Properties of TS Algorithms

Hardware vs. software-based mechanisms A GPS receiver would be a hardware solution, but often

too heavy weight/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 TS 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

6112/04/21

Jang Ping Sheu

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?

7112/04/21

Jang Ping Sheu

Fundamental Building Blocks of TS 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 packetsClock 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 multi-hop network8


Constraints for TS in WSNs

Scale to large networks of unreliable nodes Quite diverse precision requirements,

from micro seconds 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

9112/04/21

Jang Ping Sheu

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



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



A time service for the Internet - synchronizes clients to UTC (Coordinated Universal Time)

1

2

3

2

3 3

Reliability from redundant paths, scalable, authenticates time sources

Primary servers are connected to UTC sourcesSecondary servers are synchronized to primary servers

Synchronization subnet - lowest level servers in users’ computers


Network Time Protocol (NTP) Messages exchanged between a pair of NTP peers

All modes use UDP Each message bears timestamps of recent events:

Local time of Send and Receive of previous message Local time 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-1Ti-2

Ti-3

Server B

Server A

Time

m m'

Time



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 + oi (1) and Ti = Ti-1 + t’ – oi (2)

This gives us (by adding the equations (1) and (2)): di = t + t’ = Ti-2 - Ti-3 + Ti - Ti-1

Also (by subtracting the equations (1) – (2)): oi = o + (t’ - t )/2 where o = (Ti-2 - Ti-3 + Ti-1 - Ti)/2

Using the fact that t, t’ > 0 it can be shown that o - di /2 ≤ oi ≤ o + di /2 .

Thus oi is an estimate of the offset and di is a measure of the

delay 112/04/2115 Jang Ping Sheu


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 TS

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

17112/04/21

Jang Ping Sheu

LTS – Lightweight TS

Two components: Pair-wise synchronization:

based on sender/receiver technique

Network wide synchronization: Minimum-height spanning tree construction with reference node

as root

18112/04/21

Jang Ping Sheu

i j

Trigger resynchronization

Format synch packet

Timestamp packet with

Hand over packet for transmission

Start packet transmission

Operating system, channel access

Propagation delay

Packet transmission time

Packet reception interrupt

Timestamp with

Timestamp with

Format synch answer packet




Timestamp with

OS, Channel access

19

LTS – Pairwise Synchronization

112/04/21

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

20 112/04/21Jang Ping Sheu

i j


Format synch packet





Propagation delay



Timestamp with

Timestamp with





Timestamp with

OS, Channel access

21

Li(t5)

112/04/21

i j


Format synch packet





Propagation delay



Timestamp with

Timestamp with





Timestamp with

OS, Channel access

22

t5 >= t1+ τ +tp

where τ :propagation delay

tp :packet transmission time

Li(t5)


i j


Format synch packet





Propagation delay



Timestamp with

Timestamp with





Timestamp with

OS, Channel access

23

t5 <= t8- τ- tp

where τ :propagation delay

tp :packet transmission time

Li(t5)

112/04/21

i j


Format synch packet





Propagation delay



Timestamp with

Timestamp with





Timestamp with

OS, Channel access

24

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

Li(t5)

112/04/21


Under the assumption that the remaining uncertainty is allocated equally to both i and j, node i can estimate Li(t5) as

25112/04/21

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

Jang Ping Sheu


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


i j


Format synch packet





Propagation delay



Timestamp with

Timestamp with





Timestamp with

OS, Channel access

27112/04/21

Jang Ping Sheu


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

28112/04/21

Jang Ping Sheu

LTS – Pairwise Synchronization – Error Analysis

29

Pair-wise difference in packet reception time (μ sec)

Nu

mb

er of trials


LTS – Network Wide 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

30112/04/21

Jang Ping Sheu

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



Network ModelThe network is “always-on”Every node maintains 16-bit register as clockSensor has unique IDBuild hierarchical topology for the networkNode at level i can connect with at least one node

at level i-1



Level discovery PhaseTrivial

Synchronization PhasePair-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 receives ack. and we have 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

B

T1

T2 T1,T2,T3

T4

T1: A is sender, starting sync by sending synchronization_pulse packet to B with timestamp T1 T2: B receive the synchronization _pulse packet and timestamping immediately T3: B replies acknowledgement containing T1,T2,T3 T4: A receives an Ack and gets timestamp

At time T1At time T4At time T2At timeT3


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


Flooding Time Synchronization Protocol (FTSP)


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 IDEach synchronization message contains three

fields: TimeStamp RootID SeqNum

The node with the smallest ID will be only one root in the whole network



The root election phase FTSP utilizes a simple election process based on unique

node IDs

Synchronization phase



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


FTSP Time Synchronization

Local and global time Each node maintains both a local and a global time. Both the clock offset and skew between the local and

global clocks are estimated using linear regression

Hierarchy Global time is synchronized to the local time of an

elected leader Utilizes asynchronous diffusion: each node sends one

synchronization msg per 30 seconds, constant network load

Sequence number, incremented only be the elected leader

FTSP Time Synchronization

Robustness If leader fails, new leader is elected automatically. The

new leader keeps the offset and skew of the old global time

Fault tolerant: nodes can enter and leave the network, links can fail, nodes can be mobile, topology can change

Platform independent: uses the time stamping module

B

C


Root

A

SynchronizedNode

Unsynchronizednode

Timestamp rootID seqNum




FTSP Experimental Evaluation

0

10

20

30

40

50

60

70

80

90

100

0:00

0:10

0:20

0:30

0:40

0:50

1:00

1:10

1:20

1:30

1:40

1:50

2:00

2:10

2:20

2:30

2:40

2:50

3:00

3:10

3:20

3:30

3:40

3:50

4:00

time (hh:mm)

mic

rose

con

ds

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

per

cen

tag

e

average pairwise error (μs)maximum pairwise error (μs)synchronized motes (%)

`

A B D E FC

1st leader

2nd leader

1st leader turned off

random nodes turned off/on

50% turned off

all turned back onall turned on

topology:

avg. error: 1.6 μsmax. error: 6.1 μs per hop

Ratio-based Time Synchronization Protocol (RSP)


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


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:

: 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

(1)



calculate the clock drift ratio

θ = (T3 − T1)/(T4 −T2).

Reference node

Sensor node


Each node can estimate the local time of reference node in the following way:

Reference node

Sensor node

: the local time of sensor node: the corresponding local time of the reference node.: the initial offset between reference node and sensor node.

(3)



It can be calculated using linear interpolation with the four time-stamps

the can be derived as follows

(4)



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)



R S

(T1)

Reference node

Sensor node

(T3)



6.3. Protocols Based on Receiver/Receiver Synchronization


Protocols Based on Receiver/Receiver Synchronization

In this class of schemesThe receivers of packets synchronize among each

other, not with the transmitter of the packetReference 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


Reference Broadcast Synchronization (RBS)

IntroductionReference broadcasts do not have an explicit

timestampReceivers 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)


Reference Broadcast Synchronization (RBS) Difference between RBS & Traditional

synchronization protocolRBS

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



i R j


Timestamp withPacket reception

interrupt

Receiver uncertainty

Timestamp with

Send

Send

61112/04/21

Jang Ping Sheu


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


Reference Broadcast Synchronization (RBS) Types of errors in RBS

The propagation delay between two nodesThe delay between receiving the last bit and

generating the packet reception interruptThe delay between receiving the packet interrupt

and timestamping the packetThe drift between timestamping in the interrupt

routine and exchanging the observed timestampts


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



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

Least-squares linear regression drawn through the points represents the best linear fit to the data



Step1: Transmitter broadcasts Step2: Receiver records its

local clock, and exchange observation

Step3:Use Least-squares linear regression to

estimate phase offset

BA

Transmitter

Receiver

Reference PacketReference Packet

A:Local time B:Local time

Finish RBS


Reference Broadcast Synchronization (RBS)The phase offset with the clock skew is

estimated by:Least-squares linear regression graphFrom 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 : Offset of the nodes’ clock


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



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

69112/04/21

Jang Ping Sheu


Communication costs: 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

70112/04/21

Jang Ping Sheu

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


Hierarchy Referencing Time Synchronization (HRTS)



Goal :Synchronize the WSN in a lightweight manner

Idea Combine the benefits of LTS and RBS


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


Hierarchy Referencing Time Synchronization (HRTS) LTS : Pairwise Synchronization

n1

Sync packetSync packet

n2

Record t2

Reply packetReply packet

Record t1Record t4 Record t3

In this packet contains t2 and t3



112/04/2176


LTS : Pair-wise 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, three packets can synchronize every node in one

hop Combining the two protocol’s benefit, the HRTS finds

good solution to synchronize nodes in hierarchical way



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)



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

80

2

))()(())()(( 3412,

tLtLtLtLO iRRi

iR


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

81112/04/21

Jang Ping Sheu

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

82112/04/21

Jang Ping Sheu

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


Summary

Some of the presented protocols take significant advantage of WSN uniqueness like:small propagation delaysthe ability to influence the node firmware to

timestamp outgoing packets late, incoming packets early


References

[1] Ed. Ivan Stojmenovic, Handbook of Sensor Networks Algorithms and Architectures, 2005.

[2] F. Sivrikaya,and B.Yener, Time Synchronization in Sensor Networks: A Survey,2004. (www.cs.rpi.edu/~yener/PAPERS/WINET/timesync04.pdf)

[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, 1992.

[6] D. L. Mills. Improved Algorithms for Synchronizing Computer Network Clocks. IEEE/ACM Transactions on Networking, 3(3): 245–254, 1995.

[7] D. L. Mills. Adaptive Hybrid Clock Discipline Algorithm for the Network Time Protocol. IEEE/ACM Transactions on Networking, 6(5): 505–514, 1998.


References[8] S. Ganeriwal, R. Kumar, S. Adlakha, and M. Srivastava. Network-Wide Time

Synchronization in Sensor Networks. Technical Report NESL 01-01-2003, Networked and Embedded Systems Lab (NESL), University of California, Los Angeles (UCLA), 2003.

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

[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, 2004 .

[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. 25-35, Sep. 2008.

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

112/04/2187

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.


chapter 6 time synchronization

Documents

time synchronization

time tqi

time stampordering

time synchronization

time synchronization

jang ping sheujang ping

external time scale

accurate time difference