Implementing PTP aka SMPTE ST 2110-10

There is an ongoing discussion in the industry of how to maintain consistent timecode and sync/genlock between systems and devices in facilities and in the field. As the transition to IP moves forward there is a need to maintain existing systems managed by genlock and tri-level sync. However IP doesn’t support either of those older technologies. Introducing PTP.

During a recent adventure of an IP network implementation, one of the discoveries was that PTP is very chatty on the network and can cause traffic congestion. One of the design considerations with PTP to consider is the number of PTP devices any clock/switch can support. Just because there are open ports does not mean the PTP clock can support the same number of PTP devices as there are ports.

Another consideration is the current requirement to have each PTP end device configured manually so the network understood “who” they were, “where” they were and “what” they were. In other words, device name, network location and master or slave.

The SMPTE ST 2110 suite of standards includes ST 2110 -10 aka Precision Time Protocol or PTP. PTP began life as IEEE 1588 before its adoption and becoming SMPTE 2059-1/2. Then it was renamed to become a component of the SMPTE ST 2110 family it has now been anointed as ST 2110-10.

There are plenty of articles discussing the packet configurations and timing strings extolling the benefit of PTP over NTP (Network Time Protocol). PTP master and slave clocks and what the datagram looks like are well documented.

Understanding PTP

However, the information and guidelines needed to implement PTP across an IP network with the rest of the SMPTE ST 2110 essence and NMOS is still a bit of a science project.

PTP or ST 2110-10 is generated by a grandmaster clock that is external to the core switch fabric, similar to how genlock is generated by a master sync generator. Genlock is distributed throughout a facility and each end device is “timed” to the master generator, adjusting for latency and aligning all signals with a high degree of accuracy to assure seamless switching. PTP performs the same level of timing only in a slightly different way.

In the new world order of ST 2110 - IP video and audio, network topology and design have also evolved. PTP introduces the grandmaster clock, not to be confused with a regular old master clock and how it was distributed by distribution amplifiers with re-clocking. PTP uses a combination of ordinary, transparent and boundary clocks that are active components inside the IP switches.

Figure 1. The grandmaster clock has multiple chores with PTP using a combination of transparent and boundary clocks, which are part of the IP switches.  (Click to enlarge).

Figure 1. The grandmaster clock has multiple chores with PTP using a combination of transparent and boundary clocks, which are part of the IP switches. (Click to enlarge).

The grandmaster sends PTP into the network; it then propagates throughout the network topology. Similar to how genlock has distribution limitations without re-clocking or re-generation, there are limitations to PTP propagation that also require re-clocking.

This is where the network topology and switching fabric play a significant role. PTP is integral to the network and uses masters and slaves to maintain the accuracy needed to support IP in SMPTE ST 2110. As it turns out, the network topology looks surprisingly familiar to what is required by NMOS. What a coincidence! The network topology needs to support the accuracy of the timing data.

One of the evolutions in network design to support low-latency performance was to find better ways to control network traffic routing. Spanning tree, rapid spanning tree and shortest path bridging are protocols typically used in network design to reduce latency, and prioritize traffic. Leaf and spine topology replaces the need for these protocols.

Now, let us define some key terms and system components.

PTP Grandmaster Clock
PTP Grandmaster Clock is the IP network equivalent of the master sync generator, it is an external device that connects to the core network router. The grandmaster uses a GPS signal to resolve and synchronize time to GPS a standards based time source (atomic/cesium) such as NIST – National Institute of Standards and Technology-( Using the grandmaster generates a highly accurate, nano-second time and frequency synchronization that is inserted into the IP network.

Ordinary Master Clock
Ordinary Master Clock is an active component in the core router or main switch and is the first PTP entry point into the network. The ordinary master clock receives the time packets from the grandmaster and propagates them across the network to the other clocks and are also used as end nodes on any network that is connected to devices requiring synchronization.

Transparent Clock
The Transparent Clock is a component of a network switch. The transparent clock measures and adjusts for packet delay aka latency or timing error. The transparent clock computes the variable delay as the PTP packets pass through a switch or router. The switch acts as a transparent clock between master and slave clocks in a distributed network. The transparent clock will relay the master’s PTP sync. The PTP master clock can support a limited number of slaves. As the network gets more congested packet scheduling across the network can add delays, which in turn cause inaccurate time synchronization. The transparent clock adjusts the PTP messages to remove the delays of its own packet processing to compensate for delays in PTP messaging.

Boundary Clock
The Boundary Clock switch will have a PTP master clock. It can act as both an ordinary master clock and slave clock. The boundary clock is a slave to the ordinary master or grandmaster clock and will be the ordinary master clock for the endpoint devices attached to it. The boundary clock ensures that the PTP master clocks are not oversubscribed. This greatly improves the accuracy of the PTP time and the system scalability by reducing the number of hops between the master and end points. Boundary clocks can also be deployed to deliver better scale because they reduce the number of sessions and the number of packets per second that must be delivered by the master.

While the different clocks communicate with each other calculating delays and initiating compensation, there is only one grandmaster as the originating time source. There is no reverse communication between the grandmaster and the transparent and boundary clock.

There are a few new network design considerations needed to implement PTP, fortunately NMOS has the same requirements. Introducing SMPTE ST 2110 brings a new network topology called Leaf Spine, which is needed to support both PTP and NMOS. Leaf Spine will be discussed in a separate article, where we will examine its benefits and how it reduces some of the latency issues in early network designs.

There are a few interesting implementation questions regarding SMPTE ST 2110-10 and how it works across the entire broadcast environment. SMPTE ST 2110 is a facility infrastructure set of standards that only applies to streams (essence) and does not apply to file movement. Consider that in most instances the introduction of an IP (ST 2110) production studio will be an upgrade or replacement of an existing SDI studio. This means there is still a significant number of devices requiring genlock and timecode.

The result is that PTP needs to not only co-exist with genlock and timecode, they all need to be fully time aligned and synchronized. At a number of recent industry events, there have been statements that the ST 2110 standards are in-plant transport protocols. Does that mean genlock and SMPTE timecode are still relevant for contribution and distribution? If a mobile unit is all IP with ST 2110 and then uses J2K for return to the broadcast center where does PTP fit in? The truck may be PTP, the broadcast center may be PTP but the contribution link remains genlock and timecode.

This requires a continuing discussion in the migration to IP.

Editor’s Note: Gary Olson has written a book on IP technology, “Planning and Designing the IP Broadcast Facility – A New Puzzle to Solve”, which is available from major book sellers.

Let us know what you think…

Log-in or Register for free to post comments…

You might also like...

OTT - What and Where to Monitor – Part 3

In the last two articles in this series we looked at why we need to monitor in OTT. Then, through analysing a typical OTT distribution chain, we sought to understand where the technical points of demarcation and challenges arise. In…

Why We Need OTT Monitoring – Part 2

In the previous article in this series, “Understanding OTT Systems”, we looked at the fundamental differences between unidirectional broadcast and OTT delivery. We investigated the complexity of OTT delivery and observed an insight into the multi-service provider silo culture. In thi…

Essential Guide: When to Virtualize IP

Moving to IP opens a whole plethora of options for broadcasters. Engineers often speak of the advantages of scalability and flexibility in IP systems. But IP systems take on many flavors, from on-prem to off-prem, private and public cloud. And…

Understanding OTT Systems - Part 1

In this series of articles, we investigate OTT distribution networks to better understand the unique challenges ahead and how to solve them. Unlike traditional RF broadcast and cable platform delivery networks, OTT comprises of many systems operated by different companies…

Data Recording and Transmission: Channel Coding

John Watkinson introduces the idea of channel coding to convert the uncontrolled characteristics of data into something that works within the limitations of real media.