Vendor Content.
Three Tips To Accelerate Your IP (ST 2110) Deployments
Once logged in you can set content preferences to let us know what you are interested in and whether you want to receive email from us.
Already Registered? Login
The year 2020 was a big milestone for the broadcast industry. All major events were cancelled, but media operations still needed to produce shows and events even during the crisis. More than ever, broadcasters turned to the remote production and IP production; in fact, according to Omdia, 37% of media enterprises are now set to embrace remote production on IP.
As a solution provider, Riedel envisioned the convergence of IP on premise with SMPTE ST 2110 and the great connection for remote production with compressed IP. In this article, we offer some tips that can help broadcasters accelerate their ST 2110 deployments.
Tip 1: Architect Your Network Well
There is a lot to consider when designing an ST2110 IP network architecture: redundancy, delays in your network, whether to take a spine-leaf or monolith approach (or a combination), VLAN, multicast… the list goes on. Let’s tackle a few of these considerations as we proceed in our ST2110 journey.
Most importantly, you should design your network for to fit both your equipment and your needs. For instance, a huge monolithic switch doesn’t make sense at all if you have AES67 devices only. Identify your needs in terms of growth based on existing gear, media protection, data segregation, bandwidth management, and your own network policies.
Spine-leaf Versus Monolithic
Those are the two most common approaches. Like a traditional SDI router, the monolithic switch approach (see figure 1) uses large, overprovisioned switches occupying multiple rack units with big routing cores. Network operators can add cards to increase the connections with equipment and to add switching capability. A big concern with these switches is capacity – where there is no room for more cards, there is no room for the system’s growth. One big advantage of a monolithic switch, however, is the non-blocking aspect, because of the overprovision inside the switch.
The spine-leaf approach (see figure 2) is a distributed method adopted by multiple data centers and cloud networks (you can find more information on the web on equal-cost multi-path routing (ECMP) in cloud data centers). Spine-leaf requires careful attention to design because the connection to the leaf can cause blocking when not designed properly. Let’s assume you are connecting 4 x 100Gbps links from the spine to the leaf, with a theoretical aspect of 37 UHD signals (for this example, the UHD signal is at 59.94, representing approximately 10.6Gbps of video throughput). But the reality is different, as stated by Robert Welch from Arista: “If in theory a 100G link states 100Gbps, in practicality (due mainly to hashing algorithm), it is a good practice to leave some headroom (25% unused) to avoid any oversubscription at any time. In typical broadcast IP installations, everything is always active.” One big advantage of spine-leaf is that it scales better than a monolithic switch.
Figure 1. Monolithic versus Spine-Leaf approach (TOR – Top of Rack).
Redundant Versus Non-redundant Networks
It’s important to make this decision in an early stage. Two basic questions can help you in the process: Am I doing live production? Is my content recorded and does it need to be used on demand? If you said yes to the first question, your best bet is a redundant network. A non-redundant network is probably the better choice for recorded content. One other aspect of a redundant “red-blue” network is maintenance, which allows you to stay operational on one network while you’re doing maintenance to the other.
Figure 2. Redundant versus non-redundant network.
VLAN
Let’s touch quickly on the Virtual Local Area Network (VLAN) approach, which enables the entire network to be compartmentalized by function. If you are using in-band control, one VLAN can be created for each control port. VLANs are essential for network optimization and offer enhanced security and quality of service (QoS).
In-band And Out-of-band Control
In-band signaling and management is the sending of control information within the same band or channel (in our case, a red-blue network) as is used for audio, video, or data. This contrasts with out-of-band (OOB) signaling, which is sent over a different network. Please note that OOB control will required a larger number of switches to connect the equipment and the cost will be higher. The following image shows the differences (Figure 3).
Quick note on the in-band system: In some implementations, only one connection is kept (for example on the RED network). This can lead to a delay when a user wants to change a route (TAKE command), for example if the RED is not available for some reason, then the control must switch on the BLUE network, causing bigger delay on the TAKE command. Carefully designed products will have heartbeat to detect failure or will keep two connections available.
Figure 3. OOB versus in-band control.
Multicast Traffic Handling, IGMP, PIM Or SDN
Multicast is a vital transmission scheme for ST 2110 that addresses one-to-many transmissions just as the distribution amplifier does in an SDI infrastructure. There are various options available: in small deployments, where scalability is limited, network architects can decide to go with an IGMP L2 (IGMP snooping) solution. With bigger infrastructures, IGMP L3, protocol-independent multicast (PIM), or a software-defined network (SDN) are recommended.
Tip 2: Timing Is Still Critical For IP
As in SDI, timing is crucial for a workable ST 2110 network. SMPTE ST 2110 addresses timing by specifying that precision time protocol (PTP) must be used for synchronization. In addition, ST 2059-1 defined the media clock to have a value of zero at SMPTE Epoch, and ST2059-2 defined the profile of the PTP to ensure that all ST 2110 senders and receivers work together. Since the audio format used in ST 2110 is AES67, to ensure compatibility between pure AES67 devices and ST 2110, the AES group has issued AES-R16-2016. This standard stipulates the number of PTP exchanges per second as 8 . Note: It’s critical that your vendors of both AES67 and ST2110 equipment follow the AES-R16-2016 specifications!
PTP Grand Masters
PTP grand masters (GMs) are extremely important to the audio and ancillary essences of synchronized video. This mechanism timestamps the packet (in the RTP header) to maintain synchronization between all the essences. There are a few points to remember related to PTP GMs. First, the selection is done by the PTP best master clock algorithm (BMCA). The algorithm decision tree is shown in the following image (Figure 4). Care should be taken in selecting the GM, since GMs vary in terms of characteristics, numbers of possible devices supported, precision, etc.
Please note: With respect to PTP, a network architect will need to answer questions like: “Is the GPS-locked GM necessary? How is PTP failover handled?” These questions are related to your current network implementation, which is why your network architect should work closely with your broadcast engineer to answer them.
Figure 4. BCMA decision tree.
As mentioned earlier, PTP GMs can address multiples devices, but it is good practice (experts could say mandatory) to use PTP-aware switches with boundary clocks or transparent clocks. The following image (figure 5) explains these two modes. The boundary clock is the more precise and more scalable option.
Figure 5. Transparent versus boundary clock systems.
While the exchange mechanism of the PTP GM is out of the scope of this article, we have one final point to make about PTP GM exchange messages. There are typically three different types of exchange messages: unicast, multicast, and hybrid (see figure 6). Care should be taken when selecting broadcast equipment, since not all solutions support all three modes.
Figure 6. Types of PTP messages (unicast, multicast, hybrid).
Tip 3: Find The Experts
The broadcast market is experiencing its biggest video and media transition in decades. To accelerate the deployment of ST 2110 networks, it’s important to choose your partners carefully, from manufacturers to system integrators. In the recent deployments on which we have collaborated, we concluded that video engineers need counterpart network engineers and good communication between them... when things become challenging an engineer with experience in both fields is a great asset. Your expert should also be your reference for the equipment you have, be it media or IP fabric. They will guide you and help you define each node’s function and characteristic. There is no point in buying a speed boat if you have no one who can drive it and if you have no one who knows the quirk of the river you are navigating.
Conclusion
This paper briefly describes three tips for accelerating IP deployments. Of course, this is a 10,000-foot view of the subject. There are many more tips we could add to the list, such as telemetry to diagnose your network, test equipment needed for IP, orchestrators, network control, and many more. In summary, these three basics tips will help you carefully design your IP network from the beginning of the project, carefully distribute and set up the PTP to ensure all the essences are correctly aligned (via timestamp), and choose your team wisely to ensure that your IP deployment is not only completed quickly but operates successfully.