ST-2110: Overview

In the first part of this series, we explored the stages that led to the creation of ST-2110. We also mentioned some standards that, insofar as they present similar functions, would deserve more equitable treatment by the industry: IETF specifications, NDI, or OMT, for example.

In this part, we will present a macro view of the ST-2110-10 Professional Media over Managed IP Networks: System Timing and Definitions standard: the advances it proposes compared to ST-2022-6, as well as the consequences - beneficial or not - related to using the IP protocol as a transport layer.

1 - History

Technologies that preceded the ST-2110 standard.

2 - Overview

The fundamental strengths and limitations of ST-2110.

3 - Codecs and Infrastructure

Impact on networks and format selection.

4 - Transport and Signaling

Transmission protocols, limitations and improvement directions.

5 - NMOS

The essential building block for ST-2110 production.

6 - Conclusion

Should we invest in coaxial cable recycling companies?

ST-2110: Overview

In this section, we will focus particularly on the key principles of ST-2110, defined in the ST-2110-10 Professional Media over Managed IP Networks: System Timing and Definitions document, which exposes the fundamental transmission principles of ST 2110.

Common Time Reference

ST 2110 defines a universal time reference that allows precise synchronization of all streams together and provides them with absolute timecode.

The Problem

The foundation of signal digitization or transmission relies on clocks. Everywhere, we need to divide time into equal parts or know the time: digital equipment that populates our broadcast infrastructures is full of small clocks. Unfortunately, the physical limitations of electronic components mean that none of these clocks are synchronous: their dials don’t show the same time, and their hands don’t tick at quite the same speed.

In SDI, this synchronization is achieved in two ways: on one hand, using a blackburst generator, whose signal injected into genlock ports ensures synchronous timing of equipment. On the other hand, inserting timecodes allows adding temporal information to the signal.

Thus, all SDI clocks in an infrastructure beat in time and drift in harmony. If the architecture has planned for it, they also simultaneously display the same timecode…​ without guarantee that the timecode is continuous, or has any relationship with UT time.

The Solution

ST-2110 kills two birds with one stone by defining ST 2059 as the temporal backbone. This standard defines the use of the PTPv2 standard as a provider of a common reference to replace both the blackburst generator and an absolute timecode based on universal time.

By timestamping each signal with this common reference, it becomes possible to precisely determine the transmission time of each frame, thus offering considerable advantages:

  • It’s possible to synchronize any ST-2110 streams from anywhere, whether geographically or by equipment, with precision far below the time of one image.

  • It becomes possible to precisely calculate transmission quality metrics, such as jitter.

  • This greatly simplifies clock management in equipment that must process streams from different sources.

Essence Separation

By separating video, audio, and data, ST 2110 frees itself from the constraints inherited from SDI and ST 2022, and allows broadcasting each essence only to the concerned equipments.

IP presents two major advantages: simultaneous transmission of multiple signals within the same cable, and the ability to route these signals from one point to one or more other points dynamically. ST-2110 perfectly exploits these two capabilities by separating the transmission of each essence, which brings considerable advantages:

  • It’s finally possible to abstract from this analog signal heritage that blanking intervals represent! There are no more limitations in terms of bitrate or number of tracks associated with our video: no more 16 audio track limit for a 3G-SDI signal.

  • There’s no longer an obligation to pass video through multiple equipment pieces to enrich the signal: associated data can be sent by equipment different from the video, with the common time reference still ensuring synchronization of the whole. No more inserters to add audio, SCTE-104 commands, and others to the signal.

  • IP infrastructure routing capabilities are used to their full potential: graphics equipment only consumes video streams. Audio watermarking equipment only consumes audio streams. Fewer resources, more efficiency.

  • The service concept becomes logical: to build a service, just choose all the streams that compose it. You can build 50 services using the same video stream and adding variants on audio or associated data without duplication.

Security

The absence of security mechanisms at the protocol level is a major gap for a standard dedicated to an industry that is part of critical infrastructure sectors, regularly targeted by cyberattacks.

Security is, for now, absolutely not addressed by the standard: yet, while it’s obvious that a large part of security constraints must be handled directly by the network infrastructure, there are still some points that should be managed at the protocol level.

At minimum, the standard should provide native mechanisms preventing a malicious actor from discretely substituting one stream for another, or preventing a legitimate receiver from accessing content it shouldn’t be able to broadcast.

The standard must allow for each stream to authenticate its source to ensure a stream comes from an authorized equipment, and especially guarantee its integrity to detect illicit content modifications. Ideally, the standard should also provide a way to encrypt streams to avoid transmitting information in clear text over the network.

Interoperability

Interoperability is a central issue for ST 2110, handled by the JT-NM consortium which publishes recommendations and conducts test campaigns.

To guarantee that equipment from different manufacturers can actually work together, the EBU, SMPTE, AMWA, and VSF created the JT-NM group (Joint Task Force on Networked Media). This consortium notably published the JT-NM TR-1001 recommendation, which defines the minimal ecosystem for deploying and interconnecting systems based on ST 2110.

In addition, JT-NM Tested interoperability test campaigns are regularly organized, where manufacturers submit their products for independent validation. These campaigns verify compliance, detect implementation divergences, and provide end users with concrete guarantees on equipment compatibility.

Transport over IP

Universality of the transport layer, routing, business infrastructure convergence, on-premise/cloud protocol standardization…​ ST 2110 benefits from IP flexibility and an entire ecosystem deployed for decades.

But this flexibility has a cost that isn’t just financial. Partly due to infrastructure complexity and operational constraints in terms of redundancy and security. On the other hand, business teams will need to be trained on IP transport…​ and network teams will need to be trained on business issues.

Considerable advantages…​

No need to dwell on the general benefits of IP: for nearly 30 years that everyone has been using it to transport video streams, they are well known. ST 2110 arrives chronologically last in a world saturated with video over IP: traditional broadcast players, streaming platforms, social networks…​

The main interest in our context lies primarily in infrastructure and transport protocol convergence. Where it was once necessary to maintain several technologies in parallel (SDI for video, MADI or AES for audio, ASI for broadcasting, IP for telephony…​), one is now sufficient.

Furthermore, it becomes possible to rely directly on existing IP networks: site interconnections, already deployed dark fiber, operator networks…​ all of this becomes usable for broadcast content transport.

Finally, IP opens access to considerable progress made in recent years in virtualization and cloud. These advances bring major benefits to the broadcast world, such as elasticity, resilience, geographic redundancy, automatic scaling.

…​ at the price of complexity that is no less significant.

IP is a universe where NOTHING is simple.

Difficulties begin from the study phase: backbone dimensioning, choice between monolithic or spine/leaf architecture, redundancy implementation, load management, security and isolation, geographic equipment positioning, power supply…​ The subjects are numerous and require sharp network expertise.

Then comes initial deployment and configuration: routing, QoS, multicast, security again — with ACLs and firewall rules. Here too, nothing is obvious, especially since latent problems can slip in to resurface on the exact day of production deployment.

Once in production, support and maintenance can be acrobatic: software patches and version upgrades, active configuration modifications, new connections are almost daily operations that must be performed without service interruption. Network diagnosis is sometimes a nightmare: intermittent packet loss, PTP synchronization problems…​ At some clients, despite having competent network teams, IP infrastructure-related incidents remain the primary cause of our support interventions. Diagnosis and resolution sometimes require days of work from multiple people, including on subjects that could seem trivial. And finally…​ documentation must be exhaustive and kept perfectly up to date, representing a gigantic workload when considering the number of necessary equipment pieces.

Finally, scaling and migration are also delicate subjects: it remains simpler to change an SDI grid than to migrate a network core.

And teams to train

In practice, business and network teams work side by side, but with little permeability. The former would like the network to adapt to their needs, while the latter (often outsourced) focus on "plumbing," without always precisely understanding the nature of transported data. From this arise tensions, accentuated by security constraints that, as necessary as they are, add difficulty and friction points at all levels.

For an ST 2110 ecosystem to function correctly, training is unavoidable. Business teams must understand the transport infrastructure they rely on. On their side, the network team must make the effort to take height in the OSI model and familiarize themselves with business specificities, keeping in mind that they manage an essential link that remains in service of broadcasting.

All this also involves adopting common language and methodologies: the ticket system works excessively well for a printer problem that no longer works, but trying to impose it on the business team when the final control room no longer receives streams from a studio poses obvious reactivity problems.

Nothing insurmountable, but these are issues that take time and must be anticipated upstream. These problems have existed for a long time, and some are still not resolved.

1 - History

3 - Codecs and Infrastructure

Bibliography

[1] SMPTE ST 2110-10:2022. Professional Media Over Managed IP Networks: System Timing and Definitions. Society of Motion Picture and Television Engineers, 2017.

[2] SMPTE ST 2059:2021. SMPTE Profile for Use of IEEE Std 1588 Precision Time Protocol in Professional Broadcast Applications. Society of Motion Picture and Television Engineers, 2021.

[3] IEEE 1588-2019. IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems. Institute of Electrical and Electronics Engineers, 2019.

[4] JT-NM TR-1001. System Environment and Device Behaviors For SMPTE ST 2110 Media Nodes in Engineered Networks. Joint Task Force on Networked Media, 2020.