Networked media in the facility - Part 3

In Tuesday's last group of afternoon sessions, three separate sessions looked closely at the role of PTP (Precision Time Protocol) in the networked facility of today and the future. Consultant Paul Briscoe got everything rolling with a session on "Network Delivered References - Under the Hood and Across the System." Echoing the day's proceedings, Briscoe noted that "IT has arrived." Going forward, said Briscoe, "we must support legacy performance requirements because the legacy gear will be out there for some time." "It would be nice to have one distribution infrastructure," he enumerated. "We’d like to have one method, not many, to carry all references. We want to provide redundancy in the distribution. We want something to support new/future standards, something that can be externally/globally referenced, and we'd like something as close to plug-and-play as today. Most importantly, we want something that can run over a network."

The solution is IEEE 1588 Precision Time Protocol (PTP) which delivers precision tine to slave devices over the network, runs on IP (and Layer 2) networks, and provides for a Grandmaster and slave devices, said Briscoe. "PTP transfers precision time to many slave devices over the network," he said. "PTP transfers frequency via running time via a 1 GHz virtual clock (timebase). Phase is also transferred in the same way, with a counter value of zero. When locked to an external authoritative source, multiple independent masters will have same time and frequency: global locking is possible."

There is, however, the "greenfield" problem: people will not build entirely brand-new facilities.  "We have to build it with technologies that already exist. If someone has a genlocked system, they have to work together. How do you deploy PTP references with legacy systems? Both systems need to have the same timebase."

"Generating synchronous video signals from just time" was presented by Harmonic USA's J. Patrick Waddell. "The concept that a video generator can create a genlocked output signal with only the knowledge of the correct current time seems radical," he noted. Yet SMPTE is preparing to publish a pair of key standards, which define exactly how to do just this. Recapping PTP, Waddell reported that SMPTE ST 2059-2, the SMPTE profile for IEEE 1588, is one of those key standards. He also described the "daily jam," an optional daily procedure carried out within a facility that uses ST 12-1 time code, to ensure that the station’s time of day matches the civil time (clock on the wall). Adjustments such as daylight savings, leap seconds can be made, he added.

"You must provide a means to actually time the device to its place within the plant," continued Waddell. "Signals do travel at the speed of light after all. A well designed device should remain locked even if PTP reference is removed. The amount of drift in a few minutes (or even hours) should not be very much." Giving a practical example, at noon Pacific Time today the value of "t" was 1,413,917.035 seconds past the SMPTE Epoch. We're 3/100th of a second past noon. It booted and got its clock locked, right at noon, said Waddell. "That's pretty good and what we're accustomed to seeing in the SDI world today. Quicklock and good accuracy was what we were after. It's a little painful but we can do it."

"PTP deployment in Large Networks - Traps and Pitfalls" was presented by Nikolaus Kerö, Oregano Systems, Austria and Thomas Kernen, Cisco, Switzerland (Tobias Muller is listed on the presentation but was not present). What is an IP flow able to do in large implementations was the focus of their study, said Kero. Clock synchronization is a basic mandatory service to be able to create an IP flow. "We looked how to deploy PTP in a large network," he said. PTP is a well established time transfer function over Ethernet/IP, but only too for small and stable networks. In broadcasting, there are both small and large networks with diverse requirements. "High availability vs low cost, high accuracy and fast locking are some of those issues," he said.

Kemen went over the best practices in large scale PTP Design:  source-specific multicast (232/8) by which the source tree removes ASM Rendez-Vous Points constraints and offers better control over multicast sources; administratively scoped (239/9) is not mutually exclusive; Time to Live request changing it fro 1 to "whatever you prefer" (typically set to 64, 128, 255). "And ensure that PTP packets are processed with highest priority, and aren’t delayed by other classes of traffic," he said. 

PTP-aware networks include transparent and/or boundary clocks, boundary clocks at the network edge and hardware processing of PTP messages. "We're not trying to scare you but, on the journey to employing PTP, there are things you have to be aware of," he concluded. "By mitigating PDV effects, you can significantly improve PTP accuracy."

Kero concluded that node and network design/configuration are equally important. Large networks require dedicated planning, characterization and testing, testing, testing. "PTP-aware networks improve accuracy for mission critical systems," he said.