Insights From the JT-NM Tested Program Why Test ST 2110 Devices?

A SMPTE ST 2110-networked environment must deliver all of the benefits of an IP infrastructure – with the predictability of SDI – in order for it to be useful. This challenge can be met only when the infrastructure is well-managed and edge devices respect specifications. A rogue ST 2110 device may not deliver as expected, which would be bad enough. More importantly, it could adversely affect other functioning devices and lead to unpredictable general failure, which could be catastrophic. 

With this in mind, the first step to take after acquiring a new ST 2110 device for a broadcast network is to make sure that it is a good “network citizen.” A good network citizen will not affect the network or disrupt operations when it is directly connected to an on-air production environment. The second step is to actually test the promised functionality and its compliance to SMPTE standards and industry norms. For example, a production environment that is architected around ST 2022-7 redundancy would be very poorly-served if devices do not actually support the ST 2022-7 specification properly – which could ultimately lead to disruptions. 

It is important to understand that some devices might actually work well in a small synthetic setup, but fail when put into a real working environment. Due to a number of unaccounted variables, a simple pass-fail test may not be sufficient to make informed decisions on choice of equipment. For example, network packet timing is very different when several transmitters are sending to one receiver compared to a single transmitter sending to a receiver. The timing of a sender is also different if it sends a single ST 2110 flow vs. several flows. Another typical testing pitfall is the dependence on one kind of transmitter. A receiver might work great with a narrow gapped transmitter – like an SDI-to-IP gateway – but not work well with a wide linear transmitter. 

At first glance, issues like these may not appear to be a problem if the environment may only contain narrow gapped devices. However, knowing the functional boundaries of a working environment is critical to maintaining future expansion. Misinformed decisions taken today may limit future capability and possibilities, (e.g. supporting wide senders). To pre-empt this, it is advisable to build up a test suite that pushes the test boundaries for imperfect, but sufficiently good cases. It is only with these types of tests that informed decisions could be made, eventually leading to judicious ST 2110 device purchases, safe device firmware/software updates, and beneficial service agreements.

A basic sender test includes connecting a known ST 2110 receiver to allow for visual monitoring. However, the main sender tests mostly concentrate on capturing the ST 2110 signals from the sender as PCAP files. 

Capturing a PCAP file of an ST 2110 signal can be difficult. When dealing with uncompressed ST 2110-20 video, the data rate required can be high. For a UHD signal at 59.94 Hz, the bandwidth hovers around 11Gbps or 1.4GBps. Not only do these captures require high-bandwidth capture to disk without packet loss, but they also require high-precision timestamping for proper post analysis for compliance – both of which are not easy to accomplish without specialized equipment. 

Please note that ST 2022-7 testing adds further complexity where double the bandwidth is required for primary and redundancy captured PCAP file. It is worth noting that, given proper timestamps, a separate file can also be suitable for this test.

Once the challenge of capturing accurate and representative PCAP files is completed, these files should be loaded in EBU’s Live IP Software Toolkit (LIST). LIST is another industry-specific, open-source application. It analyzes PCAP files and reports any specification compliance issues it finds. LIST is an easy and intuitive tool to use. However, it can be a difficult to set up.

LIST is available as a Docker container or online. The online version requires uploading the PCAP file to the cloud for analysis. Depending on the organization’s network environment, this does not always work. The Docker container version requires installing Docker on the test system. Again, depending on the network environment, this might be challenging. LIST provides a summary of all of the tests it performs on the signal in the PCAP file and highlights the issues it finds. In the example below, it analyzed a 1920x1080p @ 59.94 signal and found no issues. The PCAP analysis tests should be done for various resolutions and for all video, audio, and ancillary flow types.

As mentioned earlier, the basic ST 2022-7 sender tests are done at the same time as the regular sender tests. The ST 2022-7 receiver tests are broken down in two categories: basic and advanced. The basic tests can be done in the lab without any specialized equipment. An ST 2022-7 reference sender will need to be set up, and the receiver will need to be programmed to listen to the signal. Then, one of the two media interfaces will need to be disconnected. As long as one of the two media interfaces remains connected, there should be no disturbance in the received signal. The signal can be disconnected either by unplugging the connector or by turning off the port in the switch. It is important to leave enough time after re-connecting the signal for things to go back to normal. It is also necessary to wait for the network switch to re-negotiate the connection before getting the DHCP address back, getting the IGMP to flow again, and then finally disconnecting the other side (to test both connections).

The advanced test involves putting a network emulator in the path between the sender and the receiver to generate more dynamic errors in the flow. Again, it is important to make sure the receiver is able to retrieve the signal without disturbance. The network emulator is able to generate much better granularity of the test signal. It can switch the signal on and off at a packet boundary, and does not have to wait seconds between disturbing one side of the signal versus the other. 

During the development of the receiver test plan, it became obvious to the expert group that using a perfectly compliant ST 2110 signal is not sufficient to test receivers. The concept of a reference sender that can be programmed to generate the different combinations of valid ST 2110 signals was identified as a key missing component to being able to confidently test receiver compliance. A reference sender can be defined as an ST 2110 flow generator that:

1. Provides narrow, narrow-linear, and wide packet timing.
2. Simulates typical signal delays that can occur in a production network.
3. Generates both a perfect signal in the middle of the target specification, and a valid signal that hovers around the edges of the target specification. 

In order to certify a receiver, it is important not only to use a reliable sender, but also to use an actual reference sender. The receiver under test should be tested to support the full specification, not just show that it can receive a perfect signal.

As part of Matrox’s development of multiple generations of ST 2110 Network Interface Controller (NIC) cards, our labs were quickly filled up with various homegrown tools that enable internal validation and subsequent participation at the JT NM Tested programs. These tools, built out of necessity, have played an important role in the deployment of solid ST 2110 devices. In consultation with partners demanding to have access to these tools, Matrox has packaged these into a 1-RU appliance.

Ready to learn more?

See how Matrox VERO can help.

Request more info