Using IEEE 1588 PTP in Video Networks

The IEEE 1588 Precision Timing Protocol defines a set of techniques for synchronizing various devices across packet-based networks, including Ethernet switches and IP routers.
Author:
Publish date:
Image placeholder title

Wes Simpson The IEEE 1588 Precision Timing Protocol (PTP) defines a set of techniques for synchronizing various devices across packet-based networks, including Ethernet switches and IP routers. This standard, which was originally developed for industrial automation and control applications, has begun to be used in several video networking applications.

In particular, 1588 can be used to synchronize multiple cameras with a common time code, as well as to lock video and audio devices to a uniform timebase.

In an earlier column (“IEEE 1588 Precision Time Protocol,” Video Networking, February 2013), I explained 1588’s basic concept of using two-way delay measurement to set clocks based on the measured difference from a master reference. In this column, I will describe the various types of clocks that can be used within a 1588 system, and also look at the timing accuracies that can be achieved both with and without specialized Ethernet hardware.

CLOCK TYPES
Three different clock functions are defined in the 1588 standard:

• The Grandmaster acts as the primary reference for all other clocks and devices in the network;

• Boundary clocks can extend the reach of 1588 signals to cover large networks, and

• Transparent clocks allow 1588 synchronization messages to be accurately transferred across devices and sub-networks that introduce delay.

Working together, these different clocks produce a robust, accurate timing distribution system.

Each 1588 network is designed to use a clock signal that originates from a single grandmaster clock. When multiple potential grandmaster source clocks are present, a sophisticated algorithm is used to select one of the candidate clocks as the grandmaster. This determination is based on the accuracy of the clock as well as its traceability to a stable reference.

All slave devices in a network need to have a traceable reference to the same grandmaster to ensure accurate synchronization. Provisions are also made in the standard for automatic fail-over to a backup grandmaster in the event that the primary grandmaster is no longer available.

Boundary clocks can be used to propagate PTP signals across networks to reach remote nodes or to ensure coverage of networks with large quantities of devices.

Each boundary clock acts as a slave to a grandmaster or other reference clock via one input port, and acts as a master to other devices via output ports. This arrangement helps to distribute the clock to all of the devices that need it. Switches and routers targeted for the 1588 market can have built-in boundary clocks. All the boundary clocks in a system can be configured to automatically select a common grandmaster clock from one or more candidate clocks.

Transparent clocks are useful for dealing with network elements that introduce variable amounts of packet delay and could therefore interfere with the accuracy of PTP synchronization. Transparent clocks have the ability to modify timestamps contained within 1588 PTP messages. These modifications are done to account for the delay incurred by PTP packets in transiting through buffers or other sources of delay within a transport device or collection of devices.

Image placeholder title

Fig. 1: A network with two grandmaster clocks, one active and one as a standby; two boundary clocks that are used to distribute the signals from the grandmaster; and an Ethernet switch that has a transparent clock to accommodate variable packet queuing delays. Fig. 1 shows a network with two grandmaster clocks, one active and one as a standby; two boundary clocks that are used to distribute the signals from the grandmaster; and an Ethernet switch that has a transparent clock to accommodate variable packet queuing delays.

SYNCHRONIZATION ACROSS NETWORKS
Clock synchronization can be achieved across a network either with or without hardware support. When hardware support is available in the interface chips within both networking equipment and the attached devices, extremely tight clock accuracies can be achieved. Without the specialized circuits needed to precisely measure packet ingress and egress times, clock synchronization can still be achieved using software techniques, although at looser tolerances.

Different applications require different levels of clocking accuracy.

For straightforward timecode synchronization between different cameras, larger clock inaccuracies can be tolerated. Timecode coordination requires accuracy levels on the order of 10–20 milliseconds with good long-term stability (hours for a shoot), so software clock synchronization will normally be sufficient.

Accurately synchronizing video and audio devices may require a higher level of accuracy, on the order of a few milliseconds to support a consistent relationship between video frames and digital audio frames, and to allow for easy editing across multiple audio tracks. Accuracies on the order of 1–2 milliseconds can be achieved on constrained networks with low traffic loads (and therefore low packet delay variation) to permit accurate software-based synchronization.

Live switching of uncompressed SDI video signals and distribution of audio signals within venues that use phased speaker arrays requires very accurate clocks, synchronized to better than a microsecond, ideally. To achieve this level of precision, hardware support for processing PTP timestamps is required on each Ethernet interface on every device along a timing path. This level of precision would allow two HD-SDI signals to be switched without having to re-synchronize them. Feeding properly phased audio signals to maintain a coherent sound field also requires very accurate clocks that can only be achieved using hardware timestamping.

One other area where hardware-based clocking shows improved performance is in the amount of time required to achieve synchronization. Software-only systems need to process multiple PTP packets in order to find the “lucky” packets that have experienced the minimum amount of delay while transiting through the path from the grandmaster to the slave device. This can take many seconds, depending on the rate at which PTP packets are being sent. In contrast, systems that support hardware timestamping can be accurately synchronized after a single PTP transaction.

Thanks to Pete Gilchriest of ARG ElectroDesign for his accurate suggestions.

Wes Simpson is an industry consultant and author of “Video Over IP, Second Edition,” from Focal Press. Your comments are welcome towes.simpson@gmail.com.