Broadcasters Need New Skills For Negotiating SLAs Over IP
EBU guidelines a technical parameters for media transport SLA
Broadcasters are increasingly migrating to IP based data networks for video distribution to cut costs and reach new audiences, but some are then finding it difficult to negotiate rigorous SLAs (Service Level Agreements) that underpin performance, robustness and availability. Part of the problem is that Telcos and others providing the IP transport services are themselves not fully up to steam with the more stringent requirements broadcasters have over QoS and reliability.
Now the EBU (European Broadcasting Union) has published a pair of documents, one high level and one going into technical depth that will help broadcasters plug this skills gap and learn how to negotiate SLAs with IP service providers more effectively.
The first document explains why SLAs are needed to achieve a common understanding by both parties to avoid disputes when problems occur. The high level document also establishes the distinctive features that AV (audio/video) SLAs have and why they are more stringent than for general data. Bit rates not only need to be high for video but have to be sustained at a certain guaranteed minimum level, while latency has to be kept within bounds. Availability also has to be higher, especially for delivery of premium live content where the consequence of a short loss of service during a major sporting event for example would be very serious for the broadcaster or operator. By contrast an email going down for a few minutes might hardly be noticed by users. We are talking therefore of at least “five nines” 99.999% availability for some video distribution services, equating to at most five minutes downtime in a year.
The second low level paper then drills down into the details of how SLAs should be framed and take account of the properties of IP networks with which broadcasters may not be so familiar. One is their bursty nature resulting from not having permanently dedicated end-to end circuits. In practical terms this means that the spacing between the IP packets that carry the AV is not constant, which means that buffers are needed to smooth out the stream for final delivery to the access network or end device. This increases latency, since the end-to-end delay is determined by the time it takes for the slowest IP packet to reach the egress point of the IP network. While some video services, such as catch up TV or VOD (Video On Demand) can tolerate some delay, others cannot. For say a live interview involving people in different locations, the maximum tolerable end to end delay is only about 50 ms, which therefore has to be specified in an SLA associated with video transport for that service.
Another important aspect of IP networks to consider when framing SLAs is that they do not always deliver the headline bit rate specified by the service provider. The service might advertise 100 Mbps but only actually deliver 80 Mbps after internal overheads have taken their toll. Sometimes it is worse than that with services that only guarantee bit rates up to half the headline rate. It may be then that a broadcaster needing a minimum of 100 Mbps will have to stipulate 200 Mbps in the SLA.
Forward Error Correction
As the EBU papers emphasize, equal care needs to be taken over availability and robustness aspects of the SLAs. Here we are talking about catering for events that cause some IP packets to be dropped, or else complete network failure. For many non-video applications packet loss can be addressed by resending them after this has been noted via the TCP protocol, but in the case of live video at any rate this is too late. By the time a packet has been resent the associated video sequence has probably already been played out. For this reason Forward Error Correction (FEC) is used for on the fly protection against loss of IP packets by adding some extra information enabling reconstruction of the full sequence. But there is a tradeoff in that FEC consumes more bandwidth and so still adds a bit to latency as a result. FEC processing also incurs a small delay. The degree of FEC protection incorporated therefore has to be balanced against latency and bandwidth cost, depending on factors such as nature of the service and quality of the network, and then incorporated in the SLA.
Broadcasters will probably also want to guard against total network failure via path protection mechanisms that also need to be built into the SLA. Fundamentally path protection is very simple in that it just means having two or more independent paths between network entry and egress points. But the devil is in the detail that SLAs have to deal with. For example it may be costly to have a standby path engineered with the same level of bitrate, latency, jitter and overall QoS as the main path. If the main link only goes down a few minutes a year the broadcaster may decide it can afford to have the standby at a lower specification, just to maintain some level of service before the main path comes back up.
There are many other considerations relating to performance, resiliency and availability dealt with in the EBU’s low level technical paper.
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,…