dB Broadcast Explains Precision Time Protocol (PTP)

In this article, dB Broadcast introduces the standards that define Precision Time Protocol (PTP), and gives an overview of the protocols and architectures involved. dB is currently delivering flagship broadcast facilities, incorporating cutting edge designs and full-IP solutions, of which PTP is an integral part – but what exactly is it?

In SMPTE ST 2022-6 networks, PTP (IEEE 1588 - 2008, also known as IEEE 1588 version 2) is used to provide the genlock functionality to allow frame accurate switching and video processing. However, the adoption of SMPTE ST 2110 networks introduces a critical additional role for PTP. With SMPTE 2110, the video, audio and metadata essence are carried on separate IP flows, which means that a mechanism is required to reconstruct the timing relationships between these essences. This is achieved by using PTP timing as the reference for all the RTP time-stamps used by all devices in the network. As a result, it is now particularly important for video engineers to have a high-level understanding of PTP.

PTP is simply a mechanism that is used to synchronise the real-time clocks of all devices in the network. The highest-level source of PTP network time is referred to as the Grandmaster. In broadcast applications this will in turn normally be locked to GPS, GLONASS or both. The PTP standard used in SMPTE ST 2110 applications is defined by SMPTE ST 2059 parts 1 & 2. SMPTE ST 2059-2 is a PTP profile, which uses IEEE 1588 version 2. Devices that use IEEE 1588 version 1 (IEEE 1588 – 2002) will not interoperate with devices that use version 2 and therefore cannot be used in SMPTE 2110 networks.

Devices that derive their timing from PTP are known as Slaves and a group of devices that are synchronised together is known as a Domain. Within a domain, the device that provides the source of PTP timing is known as the Master.

Clocks in one domain may not necessarily be synchronised to clocks in another domain, although in a broadcast network it is typical to have all domains synchronised to a single grandmaster.

Within a PTP domain there are several message types used to establish time. Announce messages are used to establish the synchronisation hierarchy to determine which clock becomes the master and at the highest level the grandmaster.

To provide system timing resilience, the Best Master Clock Algorithm (BMCA) is used to determine the most appropriate grandmaster as well as the other masters within each PTP domain. The BMCA also provides the mechanism to allow the most accurate master to take over automatically from the grandmaster if it loses GPS lock, loses network connection, or is unable to continue to act as grandmaster for any other reason.

The BMCA uses various criteria to determine which device should become master. These are listed below in priority order:
1. User Definable Priority 1 Field (the lowest value <= 128 wins for masters, slave only clocks are usually set to 255)
2. Clock Class (e.g. GPS locked or free running using a local oscillator)
3. Clock Accuracy
4. Clock Variance (jitter and wander)
5. User Definable Priority 2 Field (the lowest value <= 128 wins for masters, slave only clocks are usually set to 255)
6. Clock Source Port ID (usually the Ethernet MAC Address)

Once a master is established, it sends sync and follow-up messages that are used by slaves to begin to derive the time. Although it is easy for the slave to determine the propagation delay from the master to the slave, the slave also needs to know the reverse path delay. This is achieved by the slave sending a Delay Request message to the master. Once received by the master, it time-stamps the time of receipt and sends this back to the slave as a Delay Response message.

Unfortunately, the delays in switched or routed IP networks may be both variable and asymmetric (different in the forward and reverse paths). Slave devices must therefore periodically send Delay Request messages to the master to update their clocks.

The Slave must calculate the offset between its own clock and that of the master as well as the path delay in both the forward and reverse paths. To do this it derives the MasterToSlave delay (T2-T1) and the SlaveToMaster delay (T4-T3). For the slave time to be perfectly correct, the propagation delay in both directions must be equal. If the propagation delay in both directions is different, then the slave adjusts its clock by a value of half the asymmetry. For this reason, it is desirable to avoid excessive asymmetry in PTP networks.

Masters and slaves are known as Ordinary Clocks and are devices that are at either end of a domain, so are not switches or routers. A slave only clock never acts as a master, whereas a master/slave clock can act as either. A preferred grandmaster is configured never to act as a slave.

In any IP video network that relies upon PTP for timing, it is important that switches and routers are “PTP Aware”, which allows them to offset their own queuing delay of PTP messages in one of two ways. The first is by the switch acting as a Transparent Clock, which hardware time-stamps sync and delay request messages on arrival and departure adding the difference to a Correction Field in the message.

The second method is to act as a Boundary Clock, which receives time from the PTP domain master on one slave port and provides one or more master ports to downstream slaves in a second PTP Domain and in the process, removes the delay effect of its own queue.

PTP systems take careful design and a series of full scale network tests to get the solution right so as not to overload the network switch CPU's, grandmasters or endpoints. dB Broadcast has completed a number of major IP projects that have incorporated PTP timing systems, and dB has been responsible for leading the architectural design, driving product roadmaps/design and for continual product and integration testing of IP video systems.

www.dbbroadcast.co.uk