This article will discuss the recent advances of AMWA NMOS and explain how IS-04 Registration and Discovery and IS-05 Connection Management can lead to plug-and-play-like installations. The use of IP devices and signals with automatic address assignment are key factors in this discussion.

Workflows: Old Versus New

In a baseband broadcast scenario, a Sender and a Receiver have always been individually identifiable by their physical connectors. Thus, the “one-to-one” connection between a Sender and a Receiver has always had an underlying, physical “one-to-one” connection. Assuming that the routing from the SDI output of a camera to the SDI input to a screen is fixed, an operator can connect source and destination simply by connecting a cable.

With IP, this relationship differs. Since the shared medium of Ethernet allows transportation of AES67 or ST2110-30, together with ST2110-20 or other traffic in parallel, a physical port must be treated separately from the essence Sender and Receiver.

Regarding the connection of a Sender and Receiver, the underlying physical connection can no longer be taken as an identifier. Instead, the identification of a Sender or Receiver now needs to be defined by a combination of the source IP address, the destination IP address and, in the case of 2110 or AES67 traffic, the UDP port*. But operators should not have to be bothered to type in IP addresses and take care to maintain them in a broadcast environment.

Similar to a PC that retrieves IP addresses automatically and is also identifiable by its unique hostname, IS-04 and IS-05 can allow automatic workflows for broadcast.

* UDP (User Datagram Protocol) is an alternative communications protocol to Transmission Control Protocol (TCP) and is used primarily to establish low-latency and loss-tolerating connections between applications on the internet.

IS-04

The AMWA IS-04 data model currently describes human-readable identifiers that hold the information and configurations of a broadcast device. A device that implements the current open-source APIs will “advertise” all available “Sources” (Stage Announce), “Senders” (2110-30 Out 1), “Receivers” (2110-30 In 1), and “Flows” (uncompressed 24bit 48kHz). Overarching these elements is the “Device” (Artist Client Card AES67-108-G2) and the “Node” (Artist 64 Frame). 

IS-04 offers three APIs:

• Node API: Exposed by every IS-04 Node and describes the above data model. Can be used to get information about a Node directly from the Node itself.
• Registration API: Used by a Node to register all resources of its current, particular data model to a central registration service. This API is exposed by a central service with database capabilities. Each time the configuration of the Node changes, for example, when streams are activated or deactivated, the Node will update its representation via the Registration API.
• Query API: Exposed by the same registration service and used by any control surface or user interface to retrieve information from any Node via a single interface. In this manner, the control systems do not have to query all Nodes on the network for information. They retrieve live updates from the central source of information.

By employing a control system that uses the IS-04 Query API, all IS-04 Devices can be discovered and modeled into a user interface, assuming that Nodes have already registered via the Registration API. The user interface can then list all available Senders and Receivers, similar to a physical patch panel of coax connectors. Riedel’s NMOS Explorer is an example of one user interface and is freeware, available at https://myriedel.riedel.net.

To connect a Sender and a Receiver, the identification needs to be known. For dynamic connection management, it is also necessary to start and stop Senders and Receivers in order to avoid unwanted traffic. Additionally, a Receiver needs a description of the underlying flow to be successfully received and in order to reserve sufficient bandwidth.

IS-05

IS-05 specifies the transport Parameters of IP addresses and ports and allows them to be staged and activated via the same type of API as IS-04. As soon as a control system has knowledge of available Senders and Receivers, it can configure addresses, regardless of make and brand.

For the Flow description, IS-05 specifies a “transportfile” address. An HTTP GET on that address delivers the Session Description Protocol (SDP) of the underlying flow to the control system. The SDP needs to resemble the flow currently connected to that Sender and must be compliant with the underlying standard. For an audio stream following AES67, the SDP needs to comply with AES67:2015. For a video stream following SMPTE ST 2110-20, the SDP needs to comply with the SMPTE ST 2110 suite of standards. The API can also be adapted for future Senders that may use different transport mechanisms or compression simply by storing and altering the identification in the “transportfile.” The transport parameters do not change when a flow is compressed.

By connecting a Sender to a Receiver via IS-05, a control system will retrieve the “transportfile” from the Sender and send it to the IS-05-compliant receiver. The Receiver is then configured for the stream about to be coming in.

The physical act of connecting a cable to a coaxial port in the IP world is described and executed by activating the “Master Enable” switch via IS-05. The receiver will issue an IGMP join, and the stream is connected.

“Plug-and-play” workflow with the help of IS-04 and IS-05

For connecting Senders and Receivers, IS-05 offers all of the needed parameters and allows the ability to alter them through a unified API, and then IS-04 identifies which Senders and Receivers exist. Therefore, if a user wants to use an IP-based control panel to connect Senders and Receivers, the following steps are implemented into a broadcast control system by IS-04 and IS-05:

1. Devices retrieve configuration port and media port IP addresses via DHCP.
2. IS-04 Node implementation discovers IS-04 registry in the network by mDNS or DNS entry.
3. IS-04 Node on devices registers NMOS Node for advertising the API via Config Port.
4. IS-04 implementation on devices registers all Senders and Receivers including information about IS-05 control.
5. The control system learns of all Senders and Receivers via the IS-04 Query API and can then automatically define multicast addresses for all Senders via IS-05 staged transport parameters.
6. A control panel can then be populated with all Senders and Receivers using the connected source and destination information of the Node API as label information.
7. Through user interaction via drag/drop or push of destination and source buttons, the control system retrieves the “transportfile” of the Sender representing the source and POSTs it to the desired Receiver.

This interaction can be implemented for all devices supporting IS-04 and IS-05 and offers interoperable connection management. The following figure visualizes the above interaction between a control system, two nNodes, an IS-04 Registry, and a DHCP Server.  

Security

AMWA’s specifications define the APIs and the workflows to be used. The correct use of authentication, authorization, or accounting (AAA) mechanisms are currently outside the scope of IS-04 and IS-05. Nevertheless, recent activities within AMWA work on specifying additions to the currently used IP techniques of IS-04 and IS-05.

The use of TLS (HTTPS) allows obscuring the exchange of data between Senders, Receivers, the registry, and control systems. To enable TLS, all participating devices need to exchange keys beforehand to ensure proper decrypting and encrypting of messages.  

More information about HTTPS and key exchanging can be found in a recent whitepaper published by the BBC’s R&D department that focuses specifically on the broadcast market and which methods are already being used in new AMWA activities. (https://www.bbc.co.uk/rd/publications/whitepaper337).

An authorization method is also needed as a second critical way of securing NMOS IS-05. By introducing an authorization server to the network that monitors all online Nodes and control systems, “permissions” can be issued to controllers based on user requirements. An IS-05 control system from a rogue laptop in the facility could then be prevented from starting or stopping streams.

Conclusion

In this article, we described the abstract architecture of a broadcast system for traditional baseband systems as well as IP-based systems. Clearly, additional means for identification and discovery are needed. AMWA IS-04 offers a representation of broadcast media devices and an open-source description of the API, along with recommended practices that are available and easy to implement. To use IP media essences in a dynamic fashion, the IS-05 API was introduced for connection management.

IS-05 offers all the necessary parameters to connect an AES67 and ST 2110-2, -30, or -40 Sender to a similar Receiver, both in unicast and multicast. While some additions would provide even more usability for the user, the current specification can serve as a de-facto standard for SMPTE and AES-based devices. Through application of the widely used HTTP protocol, IS-04 and IS-05 can easily be secured using common techniques.

Adding standard IT mechanisms like DHCP and DNS can offer “plug-and-play” workflows that do not require manually configuring IP addresses and would also make the transition to IPv6 much easier.