IEEE 1588 Precision Time Protocol

Wes Simpson

Every broadcaster knows how important precise timing is for coordinating the actions of video cameras, servers, routers, displays, compression systems, and wide range of other equipment. Providing multidevice synchronization using trilevel sync signals transmitted through dedicated coaxial networks is straightforward, if somewhat costly. Making the transition to do this over Ethernet- based networks can appear, at first, to be a daunting challenge, because of these networks’ inherent random-access, asynchronous nature. Fortunately, industry organizations like the IEEE have developed the 1588 Precision Time Protocol for doing exactly what is needed: distributing a precise, common clock to a large collection of devices solely through the use of an Ethernet system.

AUTOMATION ORIGINS
IEEE 1588, officially named “Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems,” was originally designed for industrial automation systems. In these systems, distributed clocks that are accurate down to the submicrosecond range can be extremely useful for ensuring that large, moving chunks of metal are properly choreographed. Automobile control systems have started to benefit from this technology, and so have mobile phone systems, which need precise timing to coordinate cellular handoffs between base stations as users move between different coverage areas. PTP also allows Ethernet networks to behave more like telecom circuits used for synchronous data applications.

BBC’s StageBox carries all of the signals needed by a
studio camera over a single, two-way Ethernet cable.
One growing application for PTP is delivering audio signals over Ethernet to distributed speakers, where timing needs to be accurate to within a microsecond to preserve proper audio phase relationships. For video, another challenge is synchronizing multiple cameras. According to SMPTE RP-168, digital video signals should be in synchronization to a reference input to within ±1.5 microseconds. Earlier this year, the BBC announced a system called StageBox that carries all of the signals needed by a studio camera over a single, two-way Ethernet cable, including (compressed) high-definition video, associated sound channels, talkback, tally lights, timecode and a genlock signal. IEEE 1588 networks are also accurate enough to be used to provide synchronization and distribute signals within single-frequency network (SFN) over-the-air broadcast systems.

TECHNOLOGY FOR SYNCHRONIZATION
In order to closely synchronize clocks distributed across an Ethernet system, specialized hardware is added to Ethernet interface chips to make highly accurate data timing measurements. This hardware makes a precise measurement of the time at which an Ethernet data frame moves from the MAC (Media Access Control) circuitry to the physical (PHY) interface on a 1588-compliant interface chip. Using these time stamp values, software inside the connected devices can determine how much delay exists between any two interfaces on a network, and if there is any offset between the clocks in the devices.

Using the illustration in Fig. 1, we can see how a delay measurement can be made between two devices, labeled Initiator and Responder. To begin, the Initiator sends a timing request message, and records the timestamp T1 when the Ethernet frame begins its journey through the circuit that connects the two devices. This Ethernet frame transits the network during time d (which we are trying to measure) and arrives at the Responder at time T2, which is recorded in the responder. The Responder then creates and sends a response Ethernet frame back to the Initiator containing the value of T2. The hardware in the Responder records the time that the response message leaves as T3. After passing through the delay d once again in transit, the response message arrives at the Initiator, causing that device to record timestamp T4. All that is left to be done is for the Responder to send a follow-up message to the Initiator that contains the value of timestamp T3. Once the Initiator has the value of all four timestamps (T1, T2, T3, and T4), it can make a simple calculation to figure out the value of d. This is done by subtracting the turn-around time in the Responder from the total time required for the round trip and then dividing the result by two. In formula form:

d=1/2((T4-T1)-(T3-T2))

Fig. 1: Delay measurement between two devices. This, of course, assumes that the one-way delays are symmetrical, which is fairly safe considering that the length of the cable is the same in both directions, and the electronics on the ends of the circuit are probably very similar. In the case of wireless links, where the propagation delay can change quickly, the technical challenge of synchronizing clocks is much more difficult.

A similar process can be used to determine the offset between two clocks at adjacent nodes once the propagation delay between them is known. Once the offset and delay between two nodes is known, one of the clocks can be adjusted to synchronize with the other. Of course, this begs the question of which clock should be used as the grandmaster, and IEEE 1588 makes provisions for determining which clock in a distributed network should be treated as the master as well as providing a mechanism for master clock redundancy.

Increasingly, audio and video devices are incorporating IEEE 1588 capabilities, as are some newer Ethernet switches. As PTP technology proliferates, more uses will certainly be found for accurately synchronized systems elements spread across networks.

Thanks to Pete Gilchriest of ARG ElectroDesign for his “timely” comments

Wes Simpson

Wes Simpson is President of Telecom Product Consulting, an independent consulting firm that focuses on video and telecommunications products. He has 30 years experience in the design, development and marketing of products for telecommunication applications. He is a frequent speaker at industry events such as IBC, NAB and VidTrans and is author of the book Video Over IP and a frequent contributor to TV Tech. Wes is a founding member of the Video Services Forum.