The Precision Time Protocol (PTP) is a protocol for clock synchronization throughout a computer network with relatively high precision as compared to using the earlier developed Network Time Protocol (NTP) and therefore potentially higher accuracy depending on the configuration. In a local area network (LAN), accuracy can be sub-microsecond making it suitable for measurement and control systems applications. PTP can be used to synchronize financial transactions, mobile phone tower transmissions, sub-sea acoustic arrays, and networks that require precise timing as an alternative to using the timestamp of satellite navigation signals or where sub-nanosecond accuracy as provided by the White Rabbit Project is unnecessary.

The first version of PTP, IEEE 1588-2002, was published in 2002. IEEE 1588-2008, also known as PTP Version 2, is not backward compatible with the 2002 version. IEEE 1588-2019 was published in November 2019 and includes backward-compatible improvements to the 2008 publication. IEEE 1588-2008 includes a profile concept defining PTP operating parameters and options. Several profiles have been defined for applications including telecommunications, electric power distribution and audiovisual uses. is an adaptation of PTP, called gPTP, for use with Audio Video Bridging (AVB) and Time-Sensitive Networking (TSN).

History

According to John Eidson, who led the IEEE 1588-2002 standardization effort, "IEEE 1588 is designed to fill a niche not well served by either of the two dominant protocols, NTP and GPS. IEEE 1588 is designed for local systems requiring accuracies beyond those attainable using NTP. It is also designed for applications that cannot bear the cost of a GPS receiver at each node, or for which GPS signals are inaccessible."

PTP was originally defined in the IEEE 1588-2002 standard, officially titled Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems, and published in 2002. In 2008, IEEE 1588-2008 was released as a revised standard; also known as PTP version 2 (PTPv2), it improves accuracy, precision and robustness but is not backward compatible with the original 2002 version. IEEE 1588-2019 was published in November 2019, is informally known as PTPv2.1 and includes backwards-compatible improvements to the 2008 publication.

Architecture

The IEEE 1588 standards describe a hierarchical master–slave architecture for clock distribution consisting of one or more network segments and one or more clocks. An ordinary clock is a device with a single network connection that is either the source of or the destination for a synchronization reference. A source is called a master (alternately timeTransmitter), and a destination is called a slave (alternately timeReceiver

A relatively simple PTP architecture consists of ordinary clocks on a single-segment network with no boundary clocks. A grandmaster is elected and all other clocks synchronize to it.

IEEE 1588-2008 introduces a clock associated with network equipment used to convey PTP messages. The transparent clock modifies PTP messages as they pass through the device. Timestamps in the messages are corrected for time spent traversing the network equipment. This scheme improves distribution accuracy by compensating for delivery variability across the network.

PTP typically uses the same epoch as Unix time (start of 1 January 1970). While the Unix time is based on Coordinated Universal Time (UTC) and is subject to leap seconds, PTP is based on International Atomic Time (TAI). The PTP grandmaster communicates the current offset between UTC and TAI, so that UTC can be computed from the received PTP time.

Protocol details

Synchronization and management of a PTP system is achieved through the exchange of messages across the communications medium. To this end, PTP uses the following message types.

  • Sync, Follow_Up, Delay_Req and Delay_Resp messages are used by ordinary and boundary clocks and communicate time-related information used to synchronize clocks across the network.
  • Pdelay_Req, Pdelay_Resp and Pdelay_Resp_Follow_Up are used by transparent clocks to measure delays across the communications medium so that they can be compensated for by the system. Transparent clocks and these messages associated with them are not available in the original IEEE 1588-2002 PTPv1 standard, and were added in PTPv2.
  • Announce messages are used by the best master clock algorithm in IEEE 1588-2008 to build a clock hierarchy and select the grandmaster.
  • Management messages are used by network management to monitor, configure and maintain a PTP system.
  • Signaling messages are used for non-time-critical communications between clocks. Signaling messages were introduced in IEEE 1588-2008.

Messages are categorized as event and general messages. Event messages are time-critical in that accuracy in transmission and receipt timestamp accuracy directly affects clock distribution accuracy. Sync, Delay_Req, Pdelay_Req and Pdelay_resp are event messages. General messages are more conventional protocol data units in that the data in these messages is of importance to PTP, but their transmission and receipt timestamps are not. Announce, Follow_Up, Delay_Resp, Pdelay_Resp_Follow_Up, Management and Signaling messages are members of the general message class. but this has been extended to include IPv6 in IEEE 1588-2008. The BMCA only considers the self-declared quality of clocks and does not take network link quality into consideration.

Synchronization

Via BMCA, PTP selects a source of time for an IEEE 1588 domain and for each network segment in the domain.

Clocks determine the offset between themselves and their leader. Let the variable <math>t</math> represent physical time. For a given follower device, the offset <math>o(t)</math> at time <math>t</math> is defined by:

:<math>\ o(t) = s(t) - m(t)</math>

where <math>s(t)</math> represents the time measured by the follower clock at physical time <math>t</math>, and <math>m(t)</math> represents the time measured by the leader clock at physical time <math>t</math>.

The leader periodically broadcasts the current time as a message to the other clocks. Under IEEE 1588-2002 broadcasts are up to once per second. Under IEEE 1588-2008, up to 10 per second are permitted.

center|thumb|549px|IEEE 1588 synchronization mechanism and delay calculation

Each broadcast begins at time <math>T_1</math> with a Sync message sent by the leader to all the clocks in the domain. A clock receiving this message takes note of the local time <math>T_1'</math> when this message is received.

The leader may subsequently send a multicast Follow_Up with accurate <math>T_1</math> timestamp. Not all leaders have the ability to present an accurate timestamp in the Sync message. It is only after the transmission is complete that they are able to retrieve an accurate timestamp for the Sync transmission from their network hardware. Leaders with this limitation use the Follow_Up message to convey <math>T_1</math>. Leaders with PTP capabilities built into their network hardware are able to present an accurate timestamp in the Sync message and do not need to send Follow_Up messages.

In order to accurately synchronize to their leader, clocks must individually determine the network transit time of the Sync messages. The transit time is determined indirectly by measuring round-trip time from each clock to its leader. The clocks initiate an exchange with their leader designed to measure the transit time <math>d</math>. The exchange begins with a clock sending a Delay_Req message at time <math>T_2</math> to the leader. The leader receives and timestamps the Delay_Req at time <math>T_2'</math> and responds with a Delay_Resp message. The leader includes the timestamp <math>T_2'</math> in the Delay_Resp message.

Through these exchanges a clock learns <math>T_1</math>, <math>T_1'</math>, <math>T_2</math> and <math>T_2'</math>.

If <math>d</math> is the transit time for the Sync message, and <math>\tilde{o}</math> is the constant offset between leader and follower clocks, then

:<math>\ T_1' - T_1 = \tilde{o} + d \text{ and } \ T_2' - T_2 = - \tilde{o} + d</math>

Combining the above two equations, we find that

:<math>\tilde{o} = \frac 1 2 (T_1'-T_1-T_2'+T_2)</math>

The clock now knows the offset <math>\tilde{o}</math> during this transaction and can correct itself by this amount to bring it into agreement with their leader.

One assumption is that this exchange of messages happens over a period of time so small that this offset can safely be considered constant over that period. Another assumption is that the transit time of a message going from the leader to a follower is equal to the transit time of a message going from the follower to the leader. Finally, it is assumed that both the leader and follower can accurately measure the time they send or receive a message. The degree to which these assumptions hold true determines the accuracy of the clock at the follower device.

  • The Institute of Embedded Systems (InES) of the Zurich University of Applied Sciences/ZHAW is addressing the practical implementation and application of PTP.
  • IEEE 1588 is a key technology in the LXI Standard for Test and Measurement communication and control.
  • IEEE 802.1AS-2011 is part of the IEEE Audio Video Bridging (AVB) group of standards. It specifies a profile for the use of IEEE 1588-2008 for time synchronization over a virtual bridged local area network as defined by IEEE 802.1Q. In particular, 802.1AS defines how IEEE 802.3 (Ethernet), IEEE 802.11 (Wi-Fi), and MoCA can all be parts of the same PTP timing domain.
  • SMPTE 2059-2 is a PTP profile for use in synchronization of broadcast media systems.
  • The AES67 audio networking interoperability standard includes a PTPv2 profile compatible with SMPTE ST2059-2.
  • Dante uses PTPv1 for synchronization.
  • Q-LAN and RAVENNA

See also

Notes

References

  • NIST IEEE 1588 site
  • PTP documentation at InES
  • PTP and Synchronization of LTE mobile networks
  • PTP explained under the installation / maintenance point of view
  • Hirschmann PTP Whitepaper
  • PTP overview in Cisco CGS 2520 Switch Software Configuration Guide
  • Perspectives and priorities on RuggedCom Smart Grid Research IEC 61850 Technologies
  • Projects with Smart Substation Solution
  • The White Rabbit Project PTP
  • IEC&IEEE Precision Time Protocol, Pacworld, September 2016
  • IEC 62439-3 Annexes A-E Redundant attachment of clocks and network management
  • PTPv2 Timing protocol in AV networks
  • FSMLabs: Single source IEEE PTP 1588 cannot meet financial regulatory standards
  • A PTP Testing Guide for Reliable and Accurate Verification by Fran Hens (ALBEDO 2019)