WSN Chapter 6 Time Synchronizatione

Chapter 6
Time Synchronization
Outline
6.1. The Problems of Time Synchronization
6.2. Protocols Based on Sender/Receiver Synchronization
6.3. Protocols Based on Receiver/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)
Reference Broadcast Synchronization (RBS)
Hierarchy Referencing Time Synchronization (HRTS)
6.4. Summary
02/05/15
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
02/05/15
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
Oscillator frequency is time variable
Long-term variation: oscillator aging
Short-term variation: environment (temperature, pressure,
supply voltage, ...)
02/05/15
General Properties of Time Synchronization

Algorithms
Physical time vs. logical time
External vs. internal synchronization
Global vs. local algorithms
Absolute vs. relative time
Keep all nodes of a WSN synchronized or only a local

neighborhood?
Only accurate time difference
Sufficient to estimate the drift instead of phase offset
02/05/15
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
02/05/15
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?
02/05/15
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
02/05/15
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
02/05/15
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?
10
02/05/15
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 computers 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
11
02/05/15
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
12
02/05/15
Cristians 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) :
13
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 Ss 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
mr
mt
Time server S
02/05/15
Issues with Christians 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
14
No authentication mechanism
Inaccuracy increases if the delay between messages is nonnegligible
02/05/15
A time service for the Internet - synchronizes clients

to UTC (Coordinated Universal Time)
Reliability from redundant paths, scalable, authenticates time
Primary servers are connected to UTC sources
sources
Secondary servers are synchronized to primary
servers
Synchronization subnet - lowest level servers in
users computers
1
2
15
2
3
02/05/15
Synchronisation of servers
The synchronization subnet can reconfigure if failures occur, e.g.
Modes of synchronization:
Multicast
A server accepts requests from other computers (like Cristiains algorithm).

Higher accuracy. Useful if no hardware multicast.
Symmetric
16
A server within a high speed LAN multicasts time to others which set
clocks assuming some delay (not very accurate)
Procedure call
a primary that loses its UTC source can become a secondary

a secondary that loses its primary can use another primary
Pairs of servers exchange messages containing time information

Used where very high accuracies are needed (e.g. for higher levels)
02/05/15
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
Server B
Ti-2
Ti-1
Time
m
17
Server A
Ti-3
m'
Ti
Time
02/05/15
Accuracy of NTP
18
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
02/05/15
Techniques to Improve Accuracy
NTP servers filter pairs <oi, di>, estimating reliability from

variation, allowing them to select peers
19
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
02/05/15
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
20
02/05/15
LTS Lightweight Time Synchronization
Two components:
21
Pair-wise synchronization:
based on sender/receiver technique
Network wide synchronization:
Minimum-height spanning tree construction with reference
node as root
02/05/15
LTS Pairwise Synchronization
Trigger resynchronization
Format synch packet
Timestamp packet with
Hand over packet for transmission
Operating system,
channel access
Start packet transmission
Propagation delay
Packet transmission time
Packet reception interrupt

Timestamp with
Format synch answer packet
Timestamp with
Hand over packet
for transmission
OS, Channel access
22
Timestamp with
02/05/15
LTS Pair-wise Synchronization
Assumptions:
Node is 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
23
02/05/15
Format synch packet
Operating system,
channel access
Propagation delay
Li(t5)
Timestamp with
Timestamp with
Hand over packet
for transmission
OS, Channel access
24
Timestamp with
02/05/15
Format synch packet
Operating system,
channel access
Propagation delay
Li(t5)
Timestamp with
Timestamp with
Hand over packet
for transmission
t5 >= t1+ +tp
OS, Channel access

where :propagation delay

25
tp :packet transmission time
Timestamp with
02/05/15
t5 <= t8- - tp
Format synch packet
where :propagation delay
tp :packet transmission time
Operating system,
channel access
Propagation delay
Li(t5)
Timestamp with
Timestamp with
Hand over packet
for transmission
OS, Channel access
26
Timestamp with
02/05/15
The uncertainty is in the interval [Li(t1) + + tp, Li(t8) -

tp (Lj(t6) Lj(t5)]
Format synch packet
Operating system,
channel access
Propagation delay
Li(t5)
Timestamp with
Timestamp with
Hand over packet
for transmission
OS, Channel access
27
Timestamp with
02/05/15
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
28
02/05/15
Sources of inaccuracies:
29
Medium access delay

Interrupt latencies upon receiving packets
Delays between packet interrupts and time-stamping
operation
Delay in operating system and protocol stack
02/05/15
Format synch packet
Operating system,
channel access
Propagation delay

Timestamp with
Timestamp with
Hand over packet
for transmission
OS, Channel access
30
Timestamp with
02/05/15
Improvements:
31
Let node i timestamp its packet after the MAC delay,

immediately before transmitting the first bit
This would remove the uncertainty due to is 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
02/05/15
LTS Pairwise Synchronization

Error Analysis
Number of trials
Pair-wise difference in packet reception time (sec)
32
02/05/15
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
33
02/05/15
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
34
02/05/15

(TPSN)
Network Model
35
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
02/05/15

(TPSN)
Level discovery Phase
Trivial
Synchronization Phase
36
Pair-wise sync is performed along the edge of hierarchical

structure
02/05/15

(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
37
02/05/15

(TPSN)
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
38
02/05/15

(TPSN)
A receive an Ack and get timestamp T4
B
replies
acknowledgement
T1:
TB
Areceive
is sender,
the starting
synchronization
synccontaining
by sending
_pulse packet and
T1,T2,T3
synchronization_pulse
ti2:mestamping immediately
packet to B with timestamp T1
T2
T1,T2,T3
T1
A
T4
39
At time t3
t1
t4
t2
02/05/15

(TPSN)
Simulation and Comparison
40
02/05/15

(TPSN)
Simulation and Comparison
41
02/05/15
Flooding Time Synchronization

Protocol (FTSP)
42
02/05/15
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
43
02/05/15

(FTSP)
Network Model
Every node in the network has a unique ID

Each synchronization message contains three fields:
44
TimeStamp
RootID
SeqNum
The node with the smallest ID will be only one root in the
whole network
02/05/15
The root election phase
FTSP utilizes a simple election process based on unique

node IDs
Synchronization phase
45
02/05/15

(FTSP)
The root election phase
46
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
02/05/15

(FTSP)
Synchronization phase
47
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
02/05/15

Timestamp
rootID
Root
seqNum
Timestamp
rootID
seqNum
B
C
Synchronized
Node
48
Unsynchronized
node
02/05/15

(FTSP)
Simulation and Conclusion
49
02/05/15
Ratio-based Time Synchronization

Protocol (RSP)
50
02/05/15
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
51
02/05/15

(RSP)
The local clock time of a sensor device is provided by the quartz oscillator
inside itself
Transformation formula between t and Ci (t):

(1)
: the local clock time of a sensor node i.

t : the Coordinated Universal Time (UTC).
: the drift ratio
: the offset of node is clock at time t .
By (1), the local clock times of two sensor nodes i and j have the following
relationship:
(2)
: relative drift ratio between nodes i and j

: offset between the clocks of nodes i and j
52
02/05/15

(RSP)
Reference node
Sensor node
calculate the clock drift ratio

= (T3 T1)/(T4 T2).
53
02/05/15

(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.
54
02/05/15

(RSP)
It can be calculated using linear interpolation with the four timestamps
the
55
can be derived as follows
(4)
02/05/15

(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)
56
02/05/15

(RSP)
Reference node
Sensor node
(T13)
57
02/05/15
6.3. Protocols Based on

Receiver/Receiver Synchronization
58
02/05/15
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
59
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
02/05/15
Introduction
60
Reference broadcasts do not have an explicit timestamp

Receivers use reference broadcasts arrival time as a point of
reference for comparing nodes clocks
Receivers synchronizes with one another using the
messages timestamp (which is different from one receiver to
another)
02/05/15
Types of errors in traditional synchronization protocol
61
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
02/05/15
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
62
02/05/15
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
63
02/05/15
The phase offset with the clock skew is estimated by:
64
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
02/05/15
Basic idea to estimate phase offset and clock skew for

non-deterministic receivers:
65
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
02/05/15
Reference Broadcast Synchronization

(RBS)
i
Packet reception
interrupt
Receiver uncertainty
Timestamp with
Packet reception
interrupt
Timestamp with
Send
Send
66

Formula for calculating the phase offset and clock
skew of receiver r1 with another receiver r2:
Let tr,b be rs 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
67
02/05/15

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
68
02/05/15

Step1: Transmitter
Step2: Receiver
records its
broadcasts
local
clock,Least-squares
and exchange
Step3:Use
observation
linear
regression to
Finish
RBSoffset
estimate
phase
Reference
Packet
A:Local
time
A
B:Local
time
B
Transmitter
Receiver
69
02/05/15

(RBS)
Communication costs:
70
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
02/05/15

(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
71
02/05/15
Conclusion
72
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
02/05/15
Hierarchy Referencing Time

Synchronization (HRTS)
73
02/05/15
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
74
02/05/15

(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
75
02/05/15

(HRTS)
LTS : Pairwise Synchronization
Record tt14
Record
n1
n2
Sync packet
Reply packet
Record t32
In this packet contains t2 and t3

76
02/05/15

(HRTS)
77
02/05/15

(HRTS)
LTS : Pairwise Synchronization
Benefit of RBS
Offset : O = (t5 )=Li(t5) - Lj(t5)= [Li(t8)+ Li(t1)- Lj(t6)- Lj(t5)] / 2

Benefit : only two packet transmissions with each pair
Idea : ignore transmission delay
By this idea, one packet can synchronize every node in one
hop
Combining the two protocols benefit, the HRTS finds

good solution to synchronize nodes in hierarchical way
78
02/05/15

(HRTS)
79
02/05/15

(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 is clock
80
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)

02/05/15

(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
OR ,i
( Li (t2 ) LR (t1 )) ( LR (t4 ) Li (t3 ))
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(t2)
and OR,j = OR,i Oj,i
81
02/05/15

(HRTS)- Discussion
Node j is not involved in any packet exchange
by this scheme is possible to synchronize an arbitrary
number of nodes to Rs clock with only three packets!!
The synchronization uncertainty comes from:
82
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
02/05/15

(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
83
Rationale: keep MAC delay small
02/05/15

(HRTS)
84
02/05/15
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
85
02/05/15
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
86
02/05/15
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): 245254, 1995.
[7] D. L. Mills. Adaptive Hybrid Clock Discipline Algorithm for the Network Time
Protocol. IEEE/ACM Transactions on Networking, 6(5): 505514, 1998.
87
02/05/15
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 138149, Los Angeles, CA, November
2003.
[10] Mikls Marti , Branislav Kusy , Gyula Simon , kos Ldeczi, 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
88
02/05/15
Communications Review, 8(1): 125139, 2004.
Recommend Reading
Particular Challenges and Constraints for Time Synchronization

Algorithms in WSN
J. Elson and K. Romer. 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)
89
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.
02/05/15

WSN Chapter 6 Time Synchronizatione

Diunggah oleh

Informasi Dokumen

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

WSN Chapter 6 Time Synchronizatione

Diunggah oleh

Hak Cipta:

Format Tersedia

Chapter 6

6.1. The Problems of Time Synchronization

6.2. Protocols Based on Sender/Receiver Synchronization

6.3. Protocols Based on Receiver/Receiver Synchronization

Network Time Protocol (NTP)

6.1 The Problems of Time Synchronization

Why Need for Time Synchronization?

Many of the applications of WSN needs the event with time

i :clock drift rate of node i

Actual oscillators have random deviations from nominal

General Properties of Time Synchronization

Absolute vs. relative time

Keep all nodes of a WSN synchronized or only a local

General Properties of Time Synchronization

Hardware vs. software-based mechanisms

A GPS receiver would be a hardware solution, but often too

A-priori vs. a-posteriori synchronization

Is time synchronization achieved before or after an

Deterministic vs. stochastic precision bounds

No backward jumps of local clocks

Performance Metrics and Fundamental

Fundamental Building Blocks of Time

Constraints for Time Synchronization in

from ms to tens of seconds

Use of extra hardware is mostly not an option

6.2 Protocols Based on Sender/Receiver

In this kind of protocols, a receiver synchronizes to the

Network wide synchronization

How to figure out who synchronizes with whom to

Network Time Protocol (NTP)

Synchronizing Physical Clocks

Computer Clocks in distributed system not in consistent

Network Time Protocol (NTP)

Distributed System Type

Synchronous distributed system

Asynchronous distributed system

Network Time Protocol (NTP)

Cristians method (1989) for an asynchronous system

Network Time Protocol (NTP)

Issues with Christians Algorithms

A single time server might fail, so they suggest the use of a

Inaccuracy increases if the delay between messages is nonnegligible

Network Time Protocol (NTP)

A time service for the Internet - synchronizes clients

Network Time Protocol (NTP)

The synchronization subnet can reconfigure if failures occur, e.g.

A server accepts requests from other computers (like Cristiains algorithm).

a primary that loses its UTC source can become a secondary

Pairs of servers exchange messages containing time information

Network Time Protocol (NTP)

Messages exchanged between a pair of NTP peers

All modes use UDP

Local times of Send and Receive of previous message

Network Time Protocol (NTP)

For each pair of messages between two servers,

Network Time Protocol (NTP)

Techniques to Improve Accuracy

NTP servers filter pairs <oi, di>, estimating reliability from

High variability in successive pairs implies unreliable data

Accuracy depends on the delay between the NTP servers

LTS Lightweight Time Synchronization

Synchronize the clocks of all sensor nodes of a subset of

Considers only phase shifts

LTS Lightweight Time Synchronization