ST 2110 in the WAN – Part 3
So far most of the work related to SMPTE 2110 has focused on studio environments. For good reasons. That’s where the transition from SDI to ST-2110 starts, and that’s where you reap many of the benefits. But as pointed out in the first our view post about ST-2110, key drivers for moving from SDI to IP are about enabling new remote and distributed workflows. And when moving to distributed workflows, understanding wide area network (WAN) characteristics and capabilities is crucial. The WAN is right in the middle of your workflow and needs to be taken into consideration.
That’s why it’s now time to look closer at some of challenges that arise when you bring SMPTE 2110 across a wide area network. These challenges can roughly be categorized into two groups, challenges that are new with ST-2110 and challenges that remain from when we carried SDI over WAN. An example of the first one is identification of SMPTE 2110 essence streams and an example of the latter is lossless transmission of large constant bitrate (CBR) streams.
This article primarily focuses on challenges that are new with ST-2110, but will start off with some of those that remain from the past, as they are equally important to keep in mind.
WAN challenges that remain the same
The fact that we move from SDI to IP doesn’t fundamentally change what the carried media is used for. It is still high-quality media, used for professional production of high value content. And that’s why many of the basic requirements from the past remain the same going forward.
Recover from glitches, faults and failures
To begin with, broadcast quality video is still a constant bit rate (CBR) stream that cannot handle loss. Loss of data means loss of video. And that’s why technologies like forward error correction (FEC), retransmission (ARQ) and hitless protection (1+1) remains important to handle glitches, faults and failures. Providing the bandwidth and the backup paths these technologies require is reasonably simple in a studio and campus environments, but is challenging in wide area networks.
While FEC, retransmission and hitless protection help against glitches, faults and failures they don’t help if your network is continuously overloaded. And that’s why bandwidth guarantees also remains crucial for carrying IP-based video. Again something that’s reasonably simple to accomplish in a studio environment, either by overprovisioning capacity or by using per-node bandwidth reservation technologies as there is only one or a few link hops and nodes from source to destination. It’s a lot more challenging when going across long distances and a mix of underlying infrastructures.
Guaranteeing bandwidth without operational complexity remains one of the key challenges for transporting production quality video over wide areas.
Enable consistent multicast workflows
The need for multicast remains with ST-2110, and while it is simple to accomplish in the studio where you have equipment dedicated to your live production workflows, it is difficult in the WAN where you share the underlying infrastructure.
And while you can build a dedicated WAN on top of your own fibers or wavelengths to solve multicast, this will severely limit your reach and flexibility. If you do so, your multicast solution will be very different for say an internet contribution link than it is for your fiber-based links. And it will be equally different when you lease a VPN service, compared to when you lease an Ethernet service.
Consistent multicast capabilities on any underlying infrastructure has always been a challenge in WAN environments, and continues to be so also with SMPTE 2110.
New WAN challenges with SMPTE 2110
What’s perhaps more interesting than challenges that remain from the past are those that are new. Some can be derived directly from the technical differences between ST-2110 and SDI, such as the need for retaining stream identification. While others are related to new distributed ways of working, such as the need for multi-domain network control.
Stream identification and complaint handover
One of the first and perhaps most obvious challenges is how to manage stream identification in the WAN. Each essence stream has its own identification, which is crucial in order to know what stream contains what piece of content. And when bringing streams across a WAN it is important that we maintain this identification, meaning we cannot use WAN technology that removes identification information from the essence streams.
But handing over ST-2110 streams that are standards compliant is not only about retaining stream identification. The standards also specify the amount of data bursts a receiver must be able to handle. Wide area networks naturally accumulate bursts, and thus increase the burstiness. A stream that is compliant when leaving a studio, may no longer be compliant after moving across the WAN. Designing a WAN that does not increase burstiness is key to standards compliant ST-2110 transport.
With essence streams also comes the requirement to actually treat all streams independently, and to keep the separated. This is the only way each essence stream can be routed and directed to where it needs to go. But it’s also the only way you can assign different protection mechanisms and priorities to different streams and to make sure that one stream never affects the quality and characteristics of another stream.
Guaranteeing bandwidth and defining priorities per stream obviously becomes even more important when mixing live traffic with file transfers and archiving. Something you don’t do in a studio or campus network, but that’s quite common in wide area networks.
Timing and synchronization
As already mentioned in the previous our view post on ST-2110, the shift from a synchronous technology (SDI) to an asynchronous technology (IP) means that we need a way of synchronizing our sources, so that all elementary streams can be joined up into one and the same production. With SDI this was not needed, as audio and video streams were kept together in one and the same SDI frame and therefore always in sync with each other. SMPTE 2110 solves this by carrying timing information with each elementary stream and by making sure that each source is synchronized in time with good enough accuracy.
On top of synchronizing feeds in time there is also a need to convey play-out timing with really high quality to meet the needs of professional media production. This is actually where the real challenge lies, as this is where accuracy requirements are really high. But it is also a challenge that is well known in WAN environments, as the same had to be done when transporting SDI over IP. To solve this in the past each vendor came up with their own solution to synchronize over IP. The difference now is that ST-2110 specifies how to do it in a standardized way using PTP (IEEE 1588).
But to sync sources and destinations there are actually several alternatives, and GPS is typically the first choice. But GPS also comes with quite a few challenges. For remote venues, GPS may not be feasible, and you may need other solutions for backup, protection against jamming and spoofing or because of regulatory requirements. And this is where PTP comes in. It lets you synchronize nodes across an asynchronous IP network, bringing back our ability to use the transport network to synchronize multiple content sources and destinations.
What’s challenging about PTP is that it demands very low network jitter (delay variation) to reach the accuracy demanded in broadcast environments. In a studio where PTP timing data is sent across one or a few network switches that are dedicated to live production this is less of an issue. Especially as switches in studio environments tend to provide hardware based on-path support for PTP to improve accuracy. But over the WAN, where distances are longer and the number of hops larger, PTP accuracy becomes a major challenge.
Our testing shows that to get the accuracy needed you need a WAN with on-path support for synchronization/PTP. The telco industry started facing very similar challenges almost a decade ago when building out mobile broadband networks, but despite them leading the way, it is still pretty much impossible to lease WAN connectivity with PTP support.
In practice that means that you either cannot use lease infrastructure to carry SMPTE 2110 and PTP, or that you need a media network overlay providing on-path PTP support on top of non-PTP aware infrastructure.
Automated network control
The workflow flexibility that ST 2110 enables comes with requirements to automate workflows through a centralized broadcast controller. And to automate workflows, you also need to automate network connectivity. Meaning that the broadcast controller needs to be able to set up, modify and tear down connections between source and destination. As described in “What is SMPTE 2110 and NMOS all about” this is done using NMOS, more specifically NMOS IS-06.
And of course, when those same workflows cross multiple locations, the broadcast controller needs to set up connectivity not only within the studio but also in the WAN. And it needs to be able to not only provision connectivity, it also needs to be able to reserve bandwidth. On all links to all locations. And to do all of this in a manageable way, network control needs to be separated into multiple control domains, typically one per location.
And this is really where the challenges begin. What does this setup look like and who controls what? A broadcast controller in studio A should of course be able to request network connectivity in studio A. But how about network connectivity in the WAN or even in studio B, something that would be required for a distributed workflow to be entirely managed by one organization (owning the controller in studio A). How do you manage these access rights? And how do you keep such a setup secure, avoiding that a single broadcast controller can take down the WAN and multiple studios either due to bugs and human errors or due to malicious attacks?
Consistent performance with scalability
The big difference when distributing production is that suddenly your WAN is closely intertwined with your workflow. One key to making this manageable is that the WAN must provide consistency, that it behaves the same no matter the time of day, no matter the network load and no matter the location. If not, your production workflows will need to continuously adapt.
When production also utilize cloud resources there will also be real-time workflow changes, leading to real-time traffic changes in the network. You may use a resource one minute, and let go of it the next. What resources are allocated will adapt to actual workflow needs – an encoding instance will only be there when it’s actually needed. But the network needs to do more than just adapt to changing bandwidth needs when resources are used and not. There will also be changing traffic paths and characteristics requirements, as for example transcoding might happen in one datacenter today, but move to another one tomorrow.
On top of providing consistent performance, there are also scalability challenges when distributing workflows. How to make sure that we can add locations over time? Perhaps you use two studios today, but do you design the WAN so that you can add a third studio in the future without impacting existing workflows? If you don’t, then the workflow flexibility promised by SMPTE 2110 will never come to life.
Monitoring with varying expectations
While maintaining consistent performance is key, knowing that you actually do so is even more important. That’s the only way you can be really sure that an issue in your production is not related to a change in the network. And when workflows get more flexible, knowing what’s going on becomes even more important.
Keeping track of each and every stream as well as each and every link is a must. With SDI based services the quality was a bit more black or white, on or off. There were clear characteristics specs. With IP based streams there could be degradations that are acceptable depending on quality expectations. So monitoring becomes a more complex topic, as what and how to monitor becomes tied to expectations.
When SMPTE 2110 workflows move from a single studio into a wide area network, a new set of challenges arise. Issues that may have been easy to solve inside of the studio suddenly become tricky in the WAN. And this shouldn’t come as a surprise, as we are used to this from our SDI-based past, where there were plenty of WAN-specific challenges.
Some of our challenges from the past, such as bandwidth guarantees and WAN multicast, even remain in an ST 2110-based future. But there is a large number of new challenges that we need to take care of. From those specific to the ST-2110 format that needs to be taken into consideration to remain standards compliant, to challenges that are operational or related to retaining broadcast quality.
And while these challenges are not impossible to solve, they shouldn’t be taken lightly. As a user of SMPTE 2110 it is important that you take the time to design and build a wide area network that truly supports you in making the most out of your transition from SDI to IP and SMPTE 2110.
ALL SMPTE 2110 POSTS
- Part 1 – How is SMPTE 2110 changing live production?
- Part 2 – What is SMPTE 2110 and NMOS all about?
- Part 3 – SMPTE 2110 challenges in Wide Area Networks (WANs)
- Part 4 – SMPTE 2110 benefits and business case
SMPTE ST 2110 WALL CHART