System Reliability for Broadcast-over-IP applications
Image:istock.com/Henrik5000
From headend to backend, passing through contribution and distribution networks, IP is now almost everywhere in broadcast infrastructure, with its use only increasing. On the production and playout side of the business that’s also now set to dramatically increase. This is due to the flexibility of IP-based systems, their relatively low cost and their high performance: they are increasingly prevalent across digital video technologies and installations. However, transmitting data over IP networks is not an easy task. Transmission channel capacity isn’t infinite but a huge amount of data can be required to be sent simultaneously. Even if broadcast networks are properly structured and with enough capacity, IP packets still undergo a lot of challenges to reach their destination. Additionally, the different appliances used in a system can also be the cause of erroneous data in a transmission that operators need to detect and manage adequately.What are the sources of errors in an infrastructure?
Problems inherent to appliances
In every system, several different appliances are involved, in most of cases these are supplied by different manufacturers. For instance, let’s take the example of a DTT headend as shown below.
DTT headend
Due to the complexity of these systems, the sheer number of possible configurations and the hardware and the software reliability of each piece of equipment, a system must be continuously monitored and irregularities must be properly handled for efficient operation of a network. Indeed, instability in one piece of equipment can lead to bits/bytes/packet errors in the data flow.
Inherent IP network issues
The fundamental composition of an IP network infrastructure means there’s a variety of potential issues while distributing data. The main problems encountered are delay, jitter and the reordering of packets.
Delay: At each network node a packet is analyzed so it’s routed to the correct destination. The time needed to process a packet is variable according to the capabilities of the node as well as the number of packets in the node’s queue that are waiting to be processed. The treatment time on each node adds a delay in the transmission of a packet across the network and can even cause its loss, for instance when the queue of a node is already full when the packet arrives. Besides the processing time needed in each node, a propagation delay is added according to the physical characteristics of each network interconnection.
Network delay
Jitter: In addition to the delay, queuing and serialization in the network path cause jitter. The packets sent at a regular pace from the source reach the destination with varying latencies.
Reordering: Even if packets are sent in the right order from the source they can arrive reordered at their destination. It can happen if the packets follow different network paths or if they are processed in parallel on devices that don’t maintain packet ordering.
jitter and re-ordering are both problems
What‘s the impact on A/V applications?
Nowadays, when audio and video data are transported over unreliable IP networks, most infrastructure uses the MPEG-TS protocol.
This protocol gathers all of the audio and video data into one bitstream and adds information about the stream organization (SI/PSI - Service Information/Program Specific Information). It also provides a mechanism for error correction. MPEG-T: “Measurement Guidelines for DVB Systems”, describes exhaustively the way to monitor the transport of MPEG signals accurately.
Network and appliance problems - causing packet loss, delays or data alteration - have an impact on receivers and transmitters in a broadcast system.
Impact on the transmission system
Let’s look at a very basic broadcast infrastructure: a DTT headend distributing its signal to several transmission sites through an IP network. A degradation of the data contained in the signal generated by the headend can cause the core of the transmission antenna (i.e. the modulator) to fail in its task.
Depending on an RF transmitter’s configuration, the antenna will simply stop emitting or would emit dummy data. Furthermore, with the OFDM modulators available today, the time needed to resynchronize after receiving mistaken data is also important.
The result of the above is an interruption of the service for consumers, who no longer receive any data, receive dummy data or find themselves in a scrambled SFN area.
Consumers can find themselves in a scrambled SFN area
Impact on receivers
Data contained in the MPEG-TS streams are necessary for the receiver to decode the streams properly. According to the bits or packets altered during the transmission over the IP network, the result for the viewer can be harmless - without any perceivable effects or with the sporadic appearance of macroblocks - or it can be critical, causing black screens for a random duration.
Indeed, some information contained in the SI/PSI is mandatory so the receiver can properly decode the content. If key information is damaged and cannot be corrected then the service may stop. Another example of critical data is the I-frames, or IDR sent in a GoP (Group of Pictures). These frames are independent frames while others frames are predictive, meaning that they refer to information contained in the previous or the next frames of the stream. So, errors in an independent frame have a high impact on the receiver, as they are propagated over several frames, while the impact is lower for predictive frames.
In digital TV transmission, all of these issues lead to a poor experience for the viewers and a money loss for the broadcasters as they do not meet SLA requirements.
In order to differentiate from the competitors, TV service providers can improve their service up time by increasing the reliability of their network.
How to detect and manage problems?
Coping with equipment trouble
As explained previously, errors can be generated in the data stream by equipment. In order to ensure a system operates correctly, the integrity of the data must be continuously checked on the equipment output side.
For data transported over MPEG-TS, the ETR290 1/2/3 conditions can be used for verification. Several parameters can be verified depending on the application. For instance, in DVB-T2 applications, specific extra parameters can be used to check the integrity of the T2-MI stream.
Once an error has been detected, the operator needs to have redundant equipment to run in place of the one that is failing.
Equipment providing automatic redundancy of appliances based on ETR290 1/2/3 (or T2-MI) criteria is available on the market. This kind of equipment switches automatically to the backup technology if the one currently used is in failure
If main and backup equipment aren’t synchronized, because the outputs aren’t deterministic, switchover isn’t seamless. This results in missing packets or duplicated packets on the output of the redundant equipment after a switchover.
Solutions to synchronize T2 gateways are also available on the market. By synchronizing outputs, the IP switch is able to perform seamlessly as the output streams are identical. A seamless switchover is totally transparent for any equipment located after the automatic redundancy technology, preventing any loss of synchronization in the system.
Coping with IP network problems
Increase reliability by securing the data
Adapting the network configuration can lead to strong improvements in transmission performance and reliability.
Firstly, reliability can be increased by using fast and error-free transport protocols over IP. Technologies like MPLS have been specially designed to improve the delivery of media data over an IP network.
Furthermore, broadcast over IP technologies offer several solutions to cope with the different issues:
- Algorithms for error correction (bit errors and packet losses, like FEC);
- Information added to cope with the packet loss and the reordering (like RTP).
Generally, choosing the stream configuration to be transported is a tradeoff between the robustness of the signal and the bitrate: operators need to use the configuration appropriate for their application.
Increase reliability by improving infrastructure robustness
Redundancy is also another way to secure a broadcast channel. Providing alternative transmission paths can strongly increase service availability.
Redundancy can be provided:
- Between the appliances providing the services;
- Between the different networks paths used to transmit the signal.
Nowadays, equipment that provides automatic IP network redundancy and that’s easy to integrate with existing infrastructure is available on the market. These are designed to cope with any transport errors in a network.
This kind of equipment provides major benefits compared to appliances that aren’t dedicated to the task and also to using humans to do the monitoring. They are created especially for the monitoring of audio and video data over IP networks and provide a real value add.
The schema below shows an architecture typically used by an operator to secure their distribution network:
- On the end of each path an Ethernet switch is installed.
- The two Ethernet switches are periodically polled by a Network Management System (NMS). It checks the status of the currently used network.
- If a failure occurs on this port (for instance if the port is shutdown or if no more data arrives) the NMS can switch and enable the backup path.
As this solution is not dedicated to securing the transport of audio and video data over networks, there are several disadvantages:
- The latency for a complete switchover is high, implying losses of high number of packets that could lead to TV glitches or TV blackout
- The monitoring parameters are very basic:
- They refer to the full IP stream and not to a specific service into the stream
- They do not provide specific switching criteria for audio/video transport streams
Two ways to provide IP-based redundancy with dedicated equipment in a DTT environment
IP redundancy in CATV environment
In the headend, content distribution appliances are secured using the specific technology explained previously. If one of the content streams fails, the backup is instantaneously and automatically used.
In the backend site, dedicated equipment provides automatic and seamless redundancy between the two distribution paths to cope with any failures that can occur during the transport of IP packets.
Using this kind of product, users have the opportunity to strongly secure their distribution network by performing automatic IP redundancy between IP networks based on ETR290 1/2/3 criteria, RTP packets losses, streams bitrates and RJ45 errors.
For example, if an IP packet is lost on the main path for a given stream and cannot be repaired (using FEC) then the IP redundancy equipment will replace the faulty stream with its associated stream via the backup path.
This technology also automatically provides a selection of the best streams available in a set of streams present on its inputs.
Furthermore, for the specific case of 1+1 network redundancy, these products are able to resynchronize the streams arriving from two different network paths and to perform seamless switching, making any transport failures invisible for the transmitters and the final viewers. A large input buffer is needed, allowing support of big variation in transmission times between the two network paths. For instance the difference in transmission time between satellite distribution and a fiber network can be high and the IP switch must be able to handle this variation.
The SMPTE-2022 standard defines a way to perform seamless switching between streams sent over two different network paths but it relies on a RTP header that must be identical on both paths. The IP redundancy technology that we have been discussing is able to synchronize the two paths based on the TS content and therefore supports streams with different RTP headers.
Finally, thanks to feature like “bypass”, operators can prevent the creation of any single point of failure in the system ensuring customers a 100 per cent service availability.
With relatively low impact on CAPEX, these solutions are cost-effective: using them can make the difference between your service and that of your competitors. This strongly increases your customers’ positive experience with a quick ROI.
Conclusion
There are several problems that are inherent in complex infrastructures and the transmission of data over IP. These problems are critical in TV broadcast applications and need to be properly managed through the chain to be able to reach SLA requirements and to provide to consumers the best user experience.
As explained in this paper, these problems can be overcome by appropriate system configuration as well as correct technology choices.
Jean-Baptiste Marie is product marketing engineer at ENENSYS Technologies.
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,…