As the broadcast and media industry moves from SDI-based workflows to media over IP, the concept of timing synchronisation, or genlock, doesn’t go away; it changes. All those requirements of frequency lock, phase lock, frame timing, and so on still exist. We just solve the problem in a different way in IP.
Conceptually, the way we achieve genlock in an IP system is to use SMPTE ST 2059, which builds on the IEEE 1588 Precision Time Protocol (PTP) standard designed to enable precise synchronisation of clocks across a network.
Unlike analogue genlock, which is virtually impossible to get wrong, SMPTE ST 2059/PTP systems offer plenty of opportunity for poor implementation. That’s why, despite countless successful media-over-IP deployments and the undeniable benefits of IP-based operations, there remains within the industry some perception that PTP is hard or that it doesn’t work. Fortunately, the truth is that SMPTE ST 2059/PTP systems can be deployed and commissioned easily if you follow best practices. And today, best practices for PTP are well-established. (See “Best Practices for PTP Network Architecture/Topology” from the AIMS IP Oktoberfest 2020.)
PTP: Tested in tougher industries than ours
Media over IP has become standard, and with it the implementation of SMPTE ST 2059/PTP. After all, every SMPTE ST 2110 deployment requires a SMPTE ST 2059/PTP infrastructure.
But well before PTP became familiar to the broadcast and media world, it had become a vital tool in other applications and industries — stock trading in the financial sector, power distribution monitoring in the energy sector, node synchronisation in 5G telecom networks, and an array of scientific use cases. In almost every case, those applications ask more of PTP than does the conventional media-over-IP workflow. Whereas broadcasters aim for a few microseconds of accuracy, other industries demand nanosecond-level synchronisation.
In short, PTP is a proven protocol that can (and does) readily deliver the performance essential for media over IP. Fear of implementation shouldn’t be an obstacle to moving forward with an IP migration. The industry’s continued and successful shift is evidence of that.
Bleeding-edge and early adopters have already embraced SMPTE ST 2110 IP-based workflows. Standards-based solutions have been on the market for quite some time now, and interoperability is continually being established through real-world deployments and programs such as JT-NM Tested. All the core standards are complete, and the focus of further development and education has turned to making them even better and easier to use. Other than the usual considerations around buying cycles, budget, and roadmap, there are no true blocking factors preventing organisations and facilities from moving to IP.
What to know when you go (to IP)
When you do begin the process of designing, deploying, and commissioning your own SMPTE ST 2059/PTP system, start by ensuring you’ve got someone on your team who is knowledgeable in PTP. While generic IP knowledge is useful and ST 2110 expertise even better, moderate understanding of PTP on top of that can be valuable throughout the process, as well as for support, troubleshooting, and maintenance further down the road.
Your PTP expert should be able to walk through PTP best practices in designing and deploying the system. (By the way, of all those best practices, the most important is to use boundary clocks and put all ports, or interfaces, that aren’t connected to a GM into leader-only mode. This significantly enhances the security of your overall ST 2110 system.) Again, you’ll find ample resources online to help you navigate this process and deploy a properly functioning PTP system.
Though best practices will aid you in deploying your SMPTE ST 2059/PTP system correctly, thorough testing is critical. PTP systems can be tricky in that they can appear to be functioning at 100 per cent and then, later, when something bad happens and the system has to failover, it becomes clear that the it wasn’t quite configured properly. Using a commissioning checklist can help you walk through and test each and every element of your system. It can be a long and tedious process, but it’s well worth the effort to prevent months or years of unexplained on-air glitches or mysterious gremlins plaguing your broadcasts.
Finally, once your system is live, implement monitoring and diagnostics for the entire PTP infrastructure so that you’re made aware of any errors, issues, or security threats. A new recommended practice (RP 2059-15 YANG Data Model for ST 2059-2 PTP Device Monitoring in Professional Broadcast Applications) makes system monitoring much simpler. A draft is now available on GitHub.
Follow industry best practices, take the time to test thoroughly, and establish continuous PTP monitoring, and you’ll have a healthy SMPTE ST 2059/PTP system that supports your SMPTE ST 2110 IP-based workflows beautifully so that you can start taking advantage of media over IP across your operations and business.
