Although SMPTEs ST2022-6 and ST2110 are proving their value as broadcasters migrate to IP infrastructures, they are limited to the actual distribution of the raw media essence and metadata. It’s only when we start to dig into this that we realize the functionality we’ve taken for granted has to be redesigned.

In some respects, it’s unfair to compare SDI and IP due to differences in their topology. SDI is static in nature whereas IP networks are dynamic from the ground up. Labeling an SDI circuit on a router is usually a one-off process as point-to-point circuits rarely change due to the work involved in running new cables. Tie-lines provide some flexibility in SDI as they are method to improve connectivity, but they are a primitive and limited attempt.

Mapping IP Addresses

IP networks are by definition flexible. That said, we do need some constants and MAC addressing used in ethernet provides this. Every ethernet device, whether it’s a camera, production switcher, sound console or loudspeaker, has its own unique MAC address for each port that is issued by the IEEE. Actual IP addresses however are dynamic and can be changed.

It’s to our advantage to change the mapping between an ethernet MAC address and an IP address as this helps with maintenance. For example, camera-1 will have its own unique MAC address but will have an assigned IP address, the MAC address defines the physical device, but the IP address specifies the function for camera-1. In effect, there is a logical mapping between the cameras physical MAC address and the functionality provided by the IP address.

Logically mapping the function to a physical device address allows the device to be replaced without having to notify all the other devices on the rest of the network. As far as they are concerned the IP address hasn’t changed so the function of the device hasn’t changed either. It’s still a camera, the functionality of it has not changed (assuming all the essence parameters are maintained).

This may be considered an oversimplification of the actual events going on under the hood, but the end result for flexibility cannot be denied. This is just one example of the dynamic systems that the philosophy of IP offers.

Managing Change

As with all dynamic systems that are able to change without apparent notice, we need to bring some form of order to them, and this is where control systems excel.

AMWA publish the NMOS suite of standards to deliver order in the context of the broadcast IP world. Although SMPTE have done an outstanding job of defining how we transport video, audio and metadata essence over IP networks, it’s NMOS that delivers a manageable system.

Discovery and registration were some of the early wins for NMOS. As with the early days of IP in the office workplace, discovery and registration came after the transporting of data in IP networks. When we have tens of devices on a network it’s relatively easy to physically assign IP addresses, such as maintaining a spreadsheet of MAC and IP address mappings. But when we have thousands of devices then this method becomes near impossible, especially when considering the thousands of multicast streams available in the network.

New Discovery

AMWA provide a discovery and registration system through IS-04 (Discovery and Registration) but the new IS-06 Network Controller specification now encapsulates much of its functionality through the LLDP (Link Layer Discovery Protocol). Although IS-04 and IS-06 can work independently, AMWA recommend the use of IS-04 even if IS-06 is adopted to maintain a more fully automated system.

IS-06 is an API (Application Programming Interface) to provide network control functionality. The IS-06 network controller API sits between the broadcast controller and the network controller, in effect abstracting away the network controller’s operation through a common API.

The network controller provides the low-level functionality for network routing and monitoring and may well be proprietary. Common interfaces are available such as NETCONF (Network Configuration Protocol) or OpenFLow. For example, NETDONF is a generic protocol defined in RFC6241 that is supported by major switch and network infrastructure providers. It provides functionality such as maintaining an inventory of devices on the network as well as their operational status, network operations analysis, and potential security issues.

SDN API

Although the network controller provides valuable information for the network administrators, it is far too detailed for normal business operations provided by Software Defined Network systems. In effect, this is what IS-06 is facilitating. It isn’t an SDN in its own right but provides a consistent interface for vendors who do provide SDNs. The SDN may well be connected to multiple networks and even non-IP networks such as SDI so that the underlying operation of the networks can be abstracted away to provide a convenient and consistent control platform.

The LLDP is a vendor neutral protocol provided by IS-06 and uses the IEEE 802.1AB-2016 standard. This specifies that devices on the network send LLDP messages periodically to advertise their identities and capabilities. The protocol is flexible as it uses TLV (type-length-value) data structures. Some of these type-identifiers are specified and mandatory, but others can be defined by the user to specify attributes of the device.

A microphone might have a TLV type “preamp_gain” with a value 30dB, indicating to others the gain of the preamp. This information can be gathered by IS-06 connected devices so that the ‘bigger picture’ can be determined by the users.

Managing Oversubscription

Monitoring is even more important in dynamic IP systems as by definition, the network data flow changes continuously. Before forwarding flows such as multicast streams, the SDN must be sure sufficient bandwidth exists on the link. IS-06 provides functionality to help achieve this.

Automation is crucial for modern broadcasters. The adoption of IP infrastructures greatly simplifies this as we have a common interface. Instead of thinking in terms of relay closures and opto-isolators, GPIO has taken on a whole new approach with the release of IS-07 event and tally specification.

GPIOs have served the broadcast industry well ever since the first time we placed a tally light on top of a camera. They still have their place and will be used for countless years to come, but the way we use them can now move from relays to event messages.

Moving To Event Triggers

At its base level, a GPIO is an event trigger. They do have some impediments as they exhibit a certain amount of latency due to the relay closure and require physical interfaces to connect them to servers. But the underlying information they are exchanging is incredibly important.

IS-07 not only allows us to replicate GPIOs in a flexible and scalable message format, but also allows us to build on this concept and deliver time accurate messages with event timestamps and expanded messaging structures. This can be used to trigger playout on video disk players or a complex sequence of graphics on a production switcher macro.

Combined with PTP (Precision Timing Protocol), IS-07 event messages open up a whole new world of automation for us. We can still emulate the sending of a GPO but now we can send the messages over efficient IP networks instead of bulky and expensive copper control cables. Most of the time GPO transmission is free as we can use existing IP networks for the transport stream.

AMWA has provided new functionality through IS-06 and IS-07 that not only allows us greater control of IP infrastructures, but also greatly improves integration. Broadcasters now have the opportunity to improve efficiencies and enhance their workflows, especially as they progress through their IP transition journey.