The Sponsors Perspective: PTP In LANs & WANs - An Essential Component In IP Broadcast Infrastructure
PTP - as a precise network timing technology has been available for nearly two decades. It is already widely used in Telecommunication networks, Finance and Trading platforms, substation automation networks and many more industries. Every industry has its own demands such as target accuracy on the end nodes, or whether it should be used locally or via wide area connections. Furthermore, there is often the question of whether existing network components should be re-used or if they will be replaced.
Meinberg has served customers in those industries with PTP solutions for 15 years. Throughout this time, Meinberg gained a huge amount of practical experience in the productive use of PTP.
The migration from an SDI based studio infrastructure to an IP environment according to SMPTE ST 2110 enforces the use of the Precision Time Protocol. Here, PTP clients must keep a maximum time offset of 1 µs between each other to comply with the SMPTE ST 2059-2 profile. Taking into account that there is usually a high traffic load in the network due to the transport of uncompressed video and audio streams, the use of PTP compliant switches is highly recommended, although it is not enforced by the PTP profile. As the migration to IP is usually a greenfield approach in terms of the IP equipment, the availability of PTP compliant switches in those networks is no longer an issue.
As well as local installations, some Meinberg customers have been looking for solutions to provide time synchronization via long distance connections to facilitate remote production scenarios. In those cases, a PTP-aware connection is often not available.
There can be several solutions for this scenario. First of all, you need a nonlinear clock filter algorithm in the PTP Slave to remove the effects of packet jitter via the non PTP-aware network path. Furthermore, in the case where the network path changes, you need a method for detecting any changes in the asymmetry that can occur during the path reconfiguration. Depending on the magnitude of the general asymmetry of the path, a recalibration of the time reference, such as the GPS at the remote location, would be necessary.
In complex network scenarios with a high packet delay variation and a large asymmetry, a GPS-assisted approach at the remote location will become necessary. Meticulous readers may be asking why you would not just restrict yourself to only using GPS as a reference source in this scenario. The answer is because of the rising risk of vulnerabilities from jamming (disturbing) or even spoofing (manipulating) the GPS signal. There is a trend in the industry to avoid the absolute dependence on these kind of satellite-based time sources. This is especially concerning where large-scale remote production events take place, such as the Olympic games, or areas with political instabilities, as it is possible for attacks against the GPS signals to occur. Therefore, PTP can help to keep the timing distribution within a critical infrastructure up and running at all times, even without being available.
Daniel Boldt, Head of Software Development, Meinberg.
Another very important aspect is the monitoring of the PTP infrastructure. Even now there is still no standardized approach to how a PTP node should be monitored and which information should be provided. However, there is currently an ongoing activity at SMPTE to standardize such an approach.
To improve monitoring, Meinberg introduced “SyncMon” a couple of years ago as an extension to the PTPv2 protocol. This approach not only allows PTP node monitoring in terms of status information but additionally allows accuracy measurements of PTP Slaves which support this extension. It was created as the self-reporting sync status of a PTP Slave does not need to be 100% correct all of the time as there may be occasional network asymmetries or failures in boundary or slave clocks. However, with the help of the “SyncMon”, the actual accuracy of a PTP node can be validated as an independent reference.
Speaking of Boundary Clocks, it is essential to monitor them as they have an internal clock that needs to be adjusted. Ideally, all boundary clocks should have their outputs measured using a connected slave unit (a “probe) that reports any offset compared to the time reference. In the scenario where a boundary clock would produce such a drift, all PTP slaves connected to this boundary clock would follow it, although they would report a healthy state. Therefore, actively measuring boundary clock outputs will make troubleshooting PTP issues easier as the root cause of a failure can be identified very quickly.
Meinberg has provided synchronization equipment for a number of ST 2110 projects during the last few years, including BBC Wales and the Swiss SRF. Furthermore, the German public TV broadcaster WDR worked together with Meinberg to build-up a PTP distribution over a wide area network to serve remote studios located in different cities with PTP coming from a central location. After nearly 4 years of building a network that connects several radio studios in the western part of Germany, those radio studios receive the PTP signal without a local GPS installation, and then contribute RAVENNA streams to the radio program broadcast from a centralized studio. For this project Meinberg’s modular synchronization platform “IMS” was chosen because it has the flexibility to provide the timing gateway between telecom and broadcast networks.
For smaller studio environments, the new microSync 7xx/8xx platform for broadcast environments is now available. With the microSync, Meinberg now offers a product line for the broadcasters that provides PTP functionality and legacy base band sync signals at low cost in a compact device. All PTP platforms will soon be upgraded to support the latest PTP standard while keeping support for the previous version.
Supported by
You might also like...
Designing IP Broadcast Systems - The Book
Designing IP Broadcast Systems is another massive body of research driven work - with over 27,000 words in 18 articles, in a free 84 page eBook. It provides extensive insight into the technology and engineering methodology required to create practical IP based broadcast…
Demands On Production With HDR & WCG
The adoption of HDR requires adjustments in workflow that place different requirements on both people and technology, especially when multiple formats are required simultaneously.
If It Ain’t Broke Still Fix It: Part 2 - Security
The old broadcasting adage: ‘if it ain’t broke don’t fix it’ is no longer relevant and potentially highly dangerous, especially when we consider the security implications of not updating software and operating systems.
Standards: Part 21 - The MPEG, AES & Other Containers
Here we discuss how raw essence data needs to be serialized so it can be stored in media container files. We also describe the various media container file formats and their evolution.
NDI For Broadcast: Part 3 – Bridging The Gap
This third and for now, final part of our mini-series exploring NDI and its place in broadcast infrastructure moves on to a trio of tools released with NDI 5.0 which are all aimed at facilitating remote and collaborative workflows; NDI Audio,…