Chapter 6
Time Synchronization
Outline

6.1. The Problems of Time Synchronization

6.2. Protocols Based on Sender/Receiver Synchronization





Network Time Protocol (NTP)
Timing-sync Protocol for Sensor Networks (TPSN)
Flooding Time Synchronization Protocol (FTSP)
6.2.4. Ratio-based time Synchronization Protocol (RSP)
6.3. Protocols Based on Receiver/Receiver Synchronization



Reference Broadcast Synchronization (RBS)
Hierarchy Referencing Time Synchronization (HRTS)
6.4. Summary
2
2016/3/14
6.1 The Problems of Time Synchronization

Why Need for Time Synchronization?






3
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
2016/3/14
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, ...)

4
2016/3/14
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


5
Only accurate time difference
Sufficient to estimate the drift instead of phase offset
2016/3/14
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



6
No backward jumps of local clocks
No sudden jumps
2016/3/14
Performance Metrics and Fundamental
Structure

Metrics:




7
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?
2016/3/14
Fundamental Building Blocks of Time
Synchronization Algorithms




8
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
2016/3/14
Constraints for Time Synchronization in
WSNs


Scale to large networks of unreliable nodes
Quite diverse precision requirements,






9
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
2016/3/14
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
2016/3/14
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
11
2016/3/14
Network Time Protocol (NTP)

Distributed System Type

Synchronous distributed system
 Known upper bound on transmission delay
 Simplifies synchronization
 One process p1 sends its local time t to process p2 in a
message m
 p2 could set its clock to t + Ttrans , where Ttrans is
transmission delay from p1 to p2
 Ttrans is unknown but min ≤ Ttrans ≤ max
 Set clock to t + (max - min)/2 then skew ≤ (max - min)/2

Asynchronous distributed system
 Internet is asynchronous system
 Ttrans = min + x where x ≥ 0
12
2016/3/14
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
mr
13
p
mt
Time server S
2016/3/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


14
No authentication mechanism
Inaccuracy increases if the delay between messages is nonnegligible
2016/3/14
Network Time Protocol (NTP)

A time service for the Internet - synchronizes clients
to UTC (Coordinated Universal Time)
Reliability
from
redundant
paths,toscalable,
authenticates time
Primary
servers
are connected
UTC sources
sources
Secondary servers are synchronized to primary
servers
Synchronization subnet - lowest level servers in
users’ computers
1
2
15
3
2
3
3
2016/3/14
Network Time Protocol (NTP)

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 Cristiain’s 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)
2016/3/14
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
Server B
Ti-2
Ti-1
Time
m
17
Server A
Ti-3
m'
Ti
Time
2016/3/14
Network Time Protocol (NTP)

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
2016/3/14
Network Time Protocol (NTP)

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
2016/3/14
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
2016/3/14
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
2016/3/14
LTS – Pairwise Synchronization
i
j
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
Start packet transmission
Packet reception interrupt
22
Timestamp with
2016/3/14
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
23
2016/3/14
i
j
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
Li(t5)
Timestamp with
Format synch answer packet
Timestamp with
Hand over packet
for transmission
OS, Channel access
Start packet transmission
Packet reception interrupt
24
Timestamp with
2016/3/14
i
j
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
Li(t5)
Timestamp with
Format synch answer packet
Timestamp with
Hand over packet
for transmission
t5 >= t1+ τ +tp
where τ :propagation delay
OS, Channel access
Start packet transmission
Packet reception interrupt
25
tp :packet transmission time
Timestamp with
2016/3/14
i
j
Trigger resynchronization
t5 <= t8- τ- tp
where τ :propagation delay
tp :packet transmission time
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
Li(t5)
Timestamp with
Format synch answer packet
Timestamp with
Hand over packet
for transmission
OS, Channel access
Start packet transmission
Packet reception interrupt
26
Timestamp with
2016/3/14
j
The uncertainty is in thei interval [L
i(t1) + τ + tp, Li(t8) τ – tp – (Lj(t6) – Lj(t5)]
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
Li(t5)
Timestamp with
Format synch answer packet
Timestamp with
Hand over packet
for transmission
OS, Channel access
Start packet transmission
Packet reception interrupt
27
Timestamp with
2016/3/14
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
28
2016/3/14
LTS – Pair-wise Synchronization

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
2016/3/14
i
j
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
Start packet transmission
Packet reception interrupt
30
Timestamp with
2016/3/14
LTS – Pair-wise Synchronization

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 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
2016/3/14
LTS – Pairwise Synchronization
– Error Analysis
Number of trials
Pair-wise difference in packet reception time (μsec)
32
2016/3/14
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
2016/3/14
Timing-sync Protocol for Sensor Networks
(TPSN)

Introduction


34
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
2016/3/14
Timing-sync Protocol for Sensor Networks
(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
2016/3/14
Timing-sync Protocol for Sensor Networks
(TPSN)

Level discovery Phase


Trivial
Synchronization Phase

36
Pair-wise sync is performed along the edge of hierarchical
structure
2016/3/14
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
37
2016/3/14
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

38
2016/3/14
Timing-sync Protocol for Sensor Networks
(TPSN)

Synchronization Phase
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
B
T1
A
T4
39
At time t3
t1
t4
t2
2016/3/14
Timing-sync Protocol for Sensor Networks
(TPSN)

Simulation and Comparison
40
2016/3/14
Timing-sync Protocol for Sensor Networks
(TPSN)

Simulation and Comparison
41
2016/3/14
Flooding Time Synchronization
Protocol (FTSP)
42
2016/3/14
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
2016/3/14
Flooding Time Synchronization Protocol
(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
2016/3/14
Flooding Time Synchronization Protocol (FTSP)

The root election phase


FTSP utilizes a simple election process based on unique node
IDs
Synchronization phase
45
2016/3/14
Flooding Time Synchronization Protocol
(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
2016/3/14
Flooding Time Synchronization Protocol
(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
2016/3/14
Flooding Time Synchronization Protocol (FTSP)
Timestamp
rootID
Root
seqNum
Timestamp
rootID
seqNum
A
B
C
Synchronized
Node
48
Unsynchronized
node
2016/3/14
Flooding Time Synchronization Protocol
(FTSP)

Simulation and Conclusion
49
2016/3/14
Ratio-based Time Synchronization
Protocol (RSP)
50
2016/3/14
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
2016/3/14
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):
(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 .

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
2016/3/14
Ratio-based Time Synchronization Protocol
(RSP)
Reference node
Sensor node
calculate the clock drift ratio
θ = (T3 − T1)/(T4 −T2).
53
2016/3/14
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.
54
2016/3/14
Ratio-based Time Synchronization Protocol
(RSP)
It can be calculated using linear interpolation with the four timestamps
the
55
can be derived as follows
(4)
2016/3/14
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)
56
2016/3/14
Ratio-based Time Synchronization Protocol
(RSP)
Reference node
Sensor node
R
S
(T31)
57
2016/3/14
6.3. Protocols Based on
Receiver/Receiver Synchronization
58
2016/3/14
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)


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
2016/3/14
Reference Broadcast Synchronization (RBS)

Introduction



60
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)
2016/3/14
Reference Broadcast Synchronization (RBS)

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
2016/3/14
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
62
2016/3/14
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
63
2016/3/14
Reference Broadcast Synchronization (RBS)

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
2016/3/14
Reference Broadcast Synchronization (RBS)

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
2016/3/14
Reference Broadcast Synchronization (RBS)
i
R
j
Packet reception
interrupt
Receiver uncertainty
Timestamp with
Packet reception
interrupt
Timestamp with
Send
Send
66
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
67
2016/3/14
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
68
2016/3/14
Reference Broadcast Synchronization (RBS)
Step1: Transmitter
Step2: Receiver
records its
broadcasts
local
clock,Least-squares
and exchange
Step3:Use
observation
linear regression
to estimate
Finishoffset
RBS
phase
Reference
Packet
A:Local
time
A
B:Local
time
B
Transmitter
Receiver
69
2016/3/14
Reference Broadcast Synchronization (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
2016/3/14
Reference Broadcast Synchronization (RBS)

Communication costs:



71
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
2016/3/14
Reference Broadcast Synchronization (RBS)

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
2016/3/14
Hierarchy Referencing Time
Synchronization (HRTS)
73
2016/3/14
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
2016/3/14
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
75
2016/3/14
Hierarchy Referencing Time Synchronization
(HRTS)

LTS : Pairwise Synchronization
At
At time
time tt3241
Record tt14
Record
n1
n2
Record t32
Sync packet
Reply packet
In this packet contains t2 and t3
76
2016/3/14
Hierarchy Referencing Time Synchronization
(HRTS)
77
2016/3/14
Hierarchy Referencing Time Synchronization
(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 protocol’s benefit, the HRTS finds
good solution to synchronize nodes in hierarchical way
78
2016/3/14
Hierarchy Referencing Time Synchronization
(HRTS)
79
2016/3/14
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


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)
2016/3/14
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
OR ,i



( Li (t2 )  LR (t1 ))  ( LR (t4 )  Li (t3 ))

2
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
81
2016/3/14
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:


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
2016/3/14
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

83
Rationale: keep MAC delay small
2016/3/14
Hierarchy Referencing Time Synchronization
(HRTS)
84
2016/3/14
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
2016/3/14
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
2016/3/14
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.
87
2016/3/14
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
88 Service for Wireless Sensor Networks. ACM SIGMOBILE Mobile Computing and
2016/3/14
Communications Review, 8(1): 125–139, 2004.
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)

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.
2016/3/14