Clock Synchronization for Wireless Sensor Networks: A Survey

1
Clock Synchronization for Wireless Sensor
Networks A Survey

• Bharath Sundararaman, Ugo Buy, and Ajay D.
  Kshemkalyani
• Department of Computer Science
• University of Illinois at Chicago

2
Outline

• I. Introduction
• II. Synchronization protocols
• III. Comparison
• IV. Conclusion comments

3
I. Introduction
4
Why synchronization?

• The time of the day at which an event happened.
• The time interval between two events.
• The relative ordering of events.

5
Requirements

• Cope with unreliable network transmission and
  unbounded message latencies.
• Able to estimate the local time on the other
  nodes clock.
• Time must never run backward.
• Should not degrade system performance.

6
Several issues in synchronization (1/5)

• Master-slave v.s. peer-to-peer synchronization
• Master-slave. The slave node consider the clock
  reading of the master as the reference time and
  attempt to synchronize with the master.
• Peer-to-peer. Any node can communicate directly
  with every node in the network. They are more
  flexible but are also more difficult to control.

7
Several issues in synchronization (2/5)

• Clock correction versus untethered clocks
• Clock correction. Correcting the local clock in
  each node to run on par with a global time scale
  or an atomic clock.
• Untethered clock. Build a table of parameters
  that relate the local clock of each node to the
  local clock of every other node in the network.
  When timestamps are exchanged between nodes, they
  are transformed to the local clock values of the
  receiving node.

8
Several issues in synchronization (3/5)

• Internal synchronization v.s. external
  synchronization
• Internal synchronization. The goal is to
  minimize the maximum difference between the
  readings of local clocks of the sensors.
• External synchronization. A standard source of
  time is provided.

9
Several issues in synchronization (4/5)

• Probabilistic v.s. deterministic synchronization
• Probabilistic synchronization. Provide a
  probabilistic guarantee on the maximum clock
  offset with a failure probability that can be
  bounded or determined.
• Deterministic synchronization. Guarantee an
  upper bound on the clock offset with certainty.

10
Several issues in synchronization (5/5)

• Sender-to-receiver v.s. receiver-to-receiver
  synchronization
• Sender-to-receiver synchronization. The receiver
  synchronizes with the sender using the time
  stamps received. Message delay is calculated by
  measuring the round-trip delay.
• Receiver-to-receiver synchronization. If any two
  receivers receives the same message in single-hop
  transmission, they receive it at approximately
  the same time. The receivers exchange the time
  at which they received the same message and
  compute their offset based on the difference in
  reception time.

11
Terminology (1/3)

• Time The time of a clock in a machine p is given
  by the function Cp(t), where Cp(t) t for a
  perfect clock.
• Frequency Frequency is the rate at which a
  clock progresses. The frequency at time t of
  clock Ca is Ca(t).
• Offset Clock offset is the difference between
  the time reported by a clock and the real time.

12
Terminology (2/3)

• Skew The skew of a clock is the difference in
  the frequencies of the clock and the perfect
  clock. The skew of a clock Ca relative to clock
  Cb at time t is (Ca(t) - Cb(t)).
• Drift (rate) The drift of clock Ca is the second
  derivative of the clock value with respect to
  time, namely Ca (t). The drift of clock Ca
  relative to clock Cb at time t is (Ca (t) -
  Cb (t)).

13
Terminology (3/3)

• A timer is said to be working within its
  specification if
• where constant ? is the maximum skew rate
  specified by the manufacturer.

14
II. Synchronization protocols
15
Remote clock reading method

• The client then sets its time to Stime (accurate
  time from the server) (T1-T0)/2 (time required
  to transmit the message).
• The time for any message to be sent is highly
  variable due to network traffic and message
  routing.

16
Time transmission method (1/2)

• M is the source node and S is the target node.
• M sends a series of synchronization messages to
  S. The ith message is sent at time Ti of Ms
  clock and received at time Ri of Ss clock.

S
Ti
M
Ri
17
Time transmission method (2/2)
d the offset between clock S and M d message
delay
18
Set-valued estimation method (1/3)

• We assume that the local times ti and tj on
  processors Pi and Pj ,respectively, can be
  related by the linear equation
• ti aijtj bij
• where aij and bij represent the relative skew and
  offset between the two hardware clocks.
• Time-stamped triples.

19
Set-valued estimation method (2/3)
20
Set-valued estimation method (3/3)
21
Reference broadcast synchronization (1/5)

• RBS seeks to reduce nondeterministic latency
  using receiver-to-receiver synchronization and to
  conserve energy via post-facto synchronization.

22
Reference broadcast synchronization (2/5)
Time critical path nondeterministic delay
23
Reference broadcast synchronization (3/5)

• Receiver j will compute its offset relative to
  any other receiver i as the average of clock
  differences for each packet received by nodes i
  and j.

24
Reference broadcast synchronization (4/5)
25
Reference broadcast synchronization (5/5)

• The largest sources of error are removed.
• Require O(n2) message exchanges for a network of
  n nodes.

26
Romers protocol (1/4)

• Uses innovative time transformation algorithm for
  achieving clock synchronization
• Assumptions
• There is a maximum skew ? of computer clocks
• Whenever a message is exchanged between two
  nodes, the connection remains long enough for the
  two nodes to exchange one additional message.

27
Romers protocol (2/4)

• Real time difference ?t
• Computer clock difference ?C1, ?C2
• Skew upper bound for node 1 and node 2 are ?1 and
  ?2,, respectively.

28
Romers protocol (3/4)

• The message delay between two node is estimated
  by bounding it within interval
• 0, rtt

29
Romers protocol (4/4)

• Require low resource and message overhead.
• The synchronization error increases with the
  number of hops along the path of the message
  containing the timestamp.

30
Timing-sync Protocol for sensor networks (1/3)

• A self-configuring hierarchical structure.
• A node in this structure can simultaneous act as
  a synchronization server to a number of client
  nodes and as a synchronization client to another
  node.

31
Timing-sync Protocol for sensor networks (2/3)

• Two phase.
• Level discovery phase. It is based on
  constrained flooding. The root node is assigned
  level 0 The receiver assign themselves a level
  that is one greater than the level in the packet
  received.
• Synchronization phase. T2T1dd and d represents
  the clock offset between two nodes and d
  represents the propagation delay.

32
Timing-sync Protocol for sensor networks (3/3)

• The protocol is scalable and the accuracy does
  not degrade significantly as the size of the
  network is increased.
• The protocol requires a hierarchical
  infrastructure which makes it unsuitable for
  highly mobile nodes.

33
III. Comparison
34
Quantitatively evaluation (1/2)

• Synchronization precision
• Piggybacking
• Reduction of message traffic
• Computational complexity
• Run time and memory requirements
• Number of messages exchanged
• Convergence time
• Total time required to synchronize a network
• Network size
• Compatibility with sleep mode
• Synchronize and active only when application
  demands it.

35
Quantitatively evaluation (2/2)
36
Qualitatively evaluation (1/2)

• Energy efficiency
• Accuracy
• How well the time maintained within the network
  is true to the standard time
• Scalability
• Overall complexity
• Fault tolerance
• Poor reliability of message delivery

37
Qualitatively evaluation (2/2)
38
IV. Conclusion comments
39
Conclusion

• The design considerations presented will help
  designers in building successful synchronization
  scheme, best tailored to his application.

40
Comments

• Pros
• It is a good start to begin studying
  synchronization.
• Design tradeoffs are discussed and these help us
  in designing synchronization protocols.
• Cons
• Some protocols description are too rough to be
  useful.
• The authors didnt conduct any experiment to
  verify the claimed results.