Clock Synchronization: Overview and Outlook

Clock Synchronization:

Overview and Outlook

Synchronization as Network Service

•Reference clocks know correct time

•Daemons consult

•Daemons consult reference clock and distribute time to clients

How to Achieve Accuracy

•Time is sent from sender to receiver

•Network delay deteriorates result

•Must be added to transmitted value

•Receivers can tune each other (internal synchronization)

•Network delay must be measured

•Network delay must be measured

•Round-trip delay

•Timestamps are inserted in messages

•Node knows the communication delay

Various Approaches: internal and external synchronization

Internal clock synchronization

What for? –Application Fields

•Distributed measurement systems

•Synchronized data sampling

•Distributed control systems

•Correlation of sensor signals

•Synchronization of actuators

•Synchronization of actuators

•Reliable data transmission

•Secure data transmission

•Avoidance of replay attacks

•Network access

•Basis for TDMA schemes

Synchronization to measure time-of-flight

• Measuring time-of-flight or round-trip-time allows localization (if travelling speed is known e.g. 30cm/ns)

• Location range ±10 m _⇒⇒⇒⇒10 ns accuracy

• Ethernet-based networks

20cm/ns and the knowledge of length allows computing the delay between two nodes or infrastructure points

delay between two nodes or infrastructure points

• Wireless-based networks

Normally round trip time is used for ranging purposes

-Delay of retransmission should be known and fixed

-The time instant of transmission and of reception should be

known

Distributed Measurements

•Detection of power line failures

•Delay analysis of transient signals

Automation Network and Control Systems

•Classical usage

•Local control loops

•Configuration over the fieldbus

•Set point values

•More recent usage

•Distributed control systems

•Control loop in corporate fieldbus

•Example: x-by-wire systems

•Synchronization allows to be independent on network delay

Application Bottlenecks

•Standard protocol stacks do not care about Real Time

•Time required for data provision and processing is independent of communication (and could be variable)

•OS and application could have their clocks, different from communication servo clock

•Synchronized clocks can help… but communication, OS and application should share the same clock

and application should share the same clock

Same Clock

RTE: performance indicators

•IEC 61784-2 Industrial communication networks –Profiles– Part 2:

Additional fieldbus profiles for real-time networks based on ISO/IEC 8802-3 suggests some performance indicators

•Delivery time

Time needed to deliver the ADPU -Application Protocol Data Unit- (measured at the interface between the application process and the Fieldbus application entity).

•Maximum Delivery time (two cases)

No transmission errors, one lost frame with recovery

•Throughput RTE

•Throughput RTE

Total amount of ADPU data (by octet length) on one link per second

•Non RTE bandwidth (related to Throughput RTE)

% of bandwidth that can be used for non-RTE communication on one link

•Time synchronization accuracy

Maximum deviation between any two node clocks

•Non-time-based synchronization accuracy

Maximum jitter of the cyclic behavior of any two nodes (triggering event for cycle)

•Redundancy recovery time

Overall performance indicators

• Communication stacks have their own performance indicators

• OS have different indicators and a different way to experimentally evaluate them

• Applications are normally evaluated by means of I/O

• Applications are normally evaluated by means of I/O

… overall evaluation of performance is difficult

Universal Time, UT

•Defined by the earth's rotation

•Astronomical observations

•Motion of GPS satellites

•Slightly irregular

•There are several different definitions of UT, but the difference between them is always less than about 0.03 s difference between them is always less than about 0.03 s

Universal Time

•UT0, "raw" uncorrected UT

•Derived from meridian circle observations

•UT1

•UT0 corrected for polar wandering (precession)

•UT2

•UT2

•UT1 corrected for seasonal variations

International Atomic Time

•Temps Atomique International, TAI

•Weighted average of ~200 atomic clocks

•50 national laboratories

•TAI -UT1 = 0 on 1958 Jan 1

Universal Time Coordinated

•UTC, Coordinated Universal Time

•TAI + integral number of seconds

•Leap seconds to keep UTC -UT < 0.9 s

(Next leap second to be added has been programmed 2012 Jun 30th)

•UTC follows Gregorian Calendar (days, hours, minutes,…) and support Julian Date (since Jan 1, 4713 BC Greenwich noon=JD0, 29May2012 = Julian day number is 2456076)

•UTC days contain exactly 86,400 SI seconds (60 s per minute). ..but the mean solar day is slightly longer than 86,400 SI seconds, therefore, occasionally the last minute of a UTC day is adjusted to

Universal Time Coordinated

•Introduced in 1972

- In 1955 the cesium atomic clock replaced astronomic observation 1 January 1972 00:00:00 UTC = 1 January 1972 00:00:10 TAI

(same tick rate)

- UTC Format: 1970-01-01T00:00:00Z (“zulu” format)

- This is “the starting point” for Unix time (Posix time), that counts - This is “the starting point” for Unix time (Posix time), that counts the number -32bit- of seconds elapsed (not counting leap seconds)

- Overflow at 03:14:07 UTC 2038-01-19 (231 seconds)

- 32 bit for fractional part (0,4 ns as the resolution)

•Used in Internet and WWW (NTP or SNTP protocol)

GPS (Global Positioning System) Time

•Kept by US Naval Observatory

•Reference two cesium and two rubidium atomic clocks

•is kept as closely as possible to UTC

•Offset to UTC is given in GPS Navigation Message

•Each GPS satellite continuously

•Each GPS satellite continuously broadcasts a navigation message (50bits/s) composed of 5 subframes (37500bits) and sent at a precise time

•Galileo Time

•Will be kept by European agencies

GPS Time of the last 180 days

NTP Timescale

Network Time Protocol, NTP

•NTP timescale based on the UTC timescale,

•First Tick: 0n 1 January 1972 (UTC)

•Insertion of leap seconds: conversion between NTP and UTC has to be modified

•After leap second insertion (stop counting), timescales resume ticking as if the leap had never happened.

Servo clock

• Each node (transceiver) has its own quartz oscillator Fosc with a related counter Cosc (time Tosc=Cosc/Fosc)

• A servo clock Thw can be locked to Tosc

(time Thw=Thw,offs+khw·Tosc where normally khw=1)

• Thw,offs can be adjusted according to the time offset error TOE TOE = <expected time> - Thw Thw,offs = Thw,offs + TOE TOE = <expected time> - Thw Thw,offs = Thw,offs + TOE

• khw can be adjusted according to the time drift (rate) error TDE TDE = (<expected time>_i - <expected time>_i-1)/(Thw_i – Thw_i-1 ) khw = khw·TDE

• Other servo clocks can be managed at OS or application level -> how to lock a servo clock to another servo clock

Oscillator Model Frequency

•Clocks depend on oscillators (temperature, voltage –batteries-, quality,…)

•A good synchronization implies periodic compensation of offset θ _{and rate} π •If at time t0 Clock1 and Clock2 are synchronized with error ε_(t0)

Clock2 (offset correction) From clock1:

Oscillator Model Frequency

Frequency f(t) as a function of time t

Frequency Offset

Aging Factor

Environmental Term Jitter noise

Short-Term Noise

Quality of Clocks

Problem: Determine the local quality w/o reference clock

•Accuracy

•Precision

•ALLAN deviation for phase errors

•ALLAN deviation takes in account noise that cannot be compensated with offset and rate correction

Short-Term Noise

• Allan Variance as a function of τ is the synchronization interval (constant, typical value τ = few seconds)

QZ = Quartz Crystal Oscillator RB = Rubidium Gas-Cell

CS = Cesium-beam

Finding the best master

• In order to have good external synchronization, the best clock source should be found

• Who has the best Allan deviation

Synchronization protocol stacks

• Wired

• fieldbus (broadcast message)

• Ethernet (NTP, over UDP/IP port 123, 1ms accuracy)

• Real-time Ethernet (PTP or IEEE1588, over Ethernet or UDP/IP –v2 only-, better than 100ns)

• Powerline (target: 1ms for metering, <1µs for power quality)

• Wireless (target: 1ms, 1ns if localization is required)

• GPS-synchronization

• A GPS-receiver provides a 1pps signal or synchronization over protocols (e.g. IEEE1588)

NTP -Network Time Protocol

NTP -Network Time Protocol

•Structure

•Minimum-weight spanning tree of time severs

•Remote clock reading of all peer time servers

•Well engineered statistical algorithms for data filtering and clock selection

NTP –Pros and Cons

•Pros

•Available, standardized and field proven

•Cons

•Complex error modes to handle large and unreliable networks (Internet)

networks (Internet)

•Behavior in small systems not investigated

•Supports only ms-range accuracy

•Deterministic analysis not available

•Not suitable for provably correct, dependable systems

IEEE1588-2002 (PTP Precision Time Protocol)

Messages:

Sync:multicast

Follow_up:multicast

Master Clock Slave Clock

Sync message

Tm1 Tm1+Off Ts1

Ts2 Ts2 - Off

Follow_Up with the Sync transmission precision_Timestamp

Master_to_slave Delay

IEEE 1588 assumes network propagation delay to be symmetric One_way_delay = (master_to_slave_delay+slave_to_master_delay)/2= ((Ts1-Tm1)+(Tm2-Ts2))/2 Follow_up:multicast Delay_Req:unicast Delay_Res:unicast Time (slave clock) Delay_Req

Delay_Res with the Delay_Req receiving precision_Timestamp Tm2 Time (master clock) Slave_to_Master Delay Ts1= Tm1 + Off + master_to_slave_delay Tm2= Ts2 – Off + slave_to_master_delay

•Mapping

• mapping to UDP/IP (not only Ethernet)

•Type length value (TLV) field

• additional fields for arbitrary information (e.g. security)

•Alternate master

IEEE1588-2008 (PTP Precision Time Protocol)

•Alternate master

• a backup master that runs if the selected master fails

•Security

• authentication, key-distribution

•Transparent clock

PTP: Boundary and transparent clock

If several networks share the medium, the “master clock” synchronizes its own network, while the other networks can be synchronized by means of some

shared nodes (clock uncertainty propagation)

Boundary clock (IEEE1588-V1)

A shared node acts as a “slave clock” of a network and as a “master clock” of the other one

This node blocks PTP messages

Transparent clock (IEEE1588-V2)

A shared node corrects timestamping information according to the delays it introduces (internal switch delays and cable delays)

The PLC (powerline) communication media

•Compared with COTS Ethernet, fieldbusses

•Noisy, poor data transmission rate

•Communication may be interrupted

•Transmission power is limited due to EMC regulations

•Extensive signal processing due to channel characteristics

•Result: additional, but deterministic signal delay

•Channel adaptation not possible

•Channel adaptation not possible

•Counter measures against reflections, multi-path transmission not possible

•Every node may also be a repeater, since some nodes are not reachable by AP, Bridges directly

PLC: Network Topology

•Non-stable topology

•Suppliers switch subnets for load balancing

•Nodes may be reachable (synchronized) by multiple Aps (with multiple

Aps (with multiple accuracies)

•Nodes, subnets may be switched from one domain to another

•IEEE1588-v2 compliant solutions

•The problem of the choice of synchronization interval

IEEE1588 for PLC Side

•Drawbacks of IEEE1588 in PLC,

•Limited transmission bandwidth

•Poor reliability

•Non-stable topology

•Asymmetric Delay

•TDMA oriented network

•But with…

•But with…

•PLC-receiver side generated follow-up packets

•Fixed-Value Delay-Response Packets

•PTP is possible!

•Advantage:

•Full IEEE1588 stack is usable

IEEE1588

Synchronization in wireless fieldbus

• Clock synchronization among wireless sensor nodes allows data sorting, but … s? ms? µs? ns?

• A very good synchronization…

Allows power saving

(transmitter and receiver are turned on only when needed)

Wastes power

Wastes power

(more data and messages must be transmitted)

bad synchronization good synchronization

Tx data data Tx sync data sync

Synchronization protocols for WSN

• PTP is a complex stack …(not very used)

•Requires IPv6 (6LowPAN) and UDP stack

• There are many synchronization protocols for WSN, trading accuracy with complexity (power consumption)

• e.g. TPSN is a light version of PTP (round trip time)

• e.g. TPSN is a light version of PTP (round trip time)

• e.g. LTS corrects only offset (no drift, identical nodes)

Flooding Time Synchronization Protocol (FTSP)

Reference Broadcast Synchronization (RBS)

• Receivers synchronize each other (optimal for internal synchronization)

i R j

Packet reception interrupt

Tim estam p with

Packet reception interrupt Receiver uncertainty

Timestamp with