Designing IP Broadcast Systems: NMOS

SMPTE have delivered reliable low latency video and audio distribution over IP networks, but it’s NMOS that is delivering solutions to discovery & registration challenges that satisfy operational requirements.

ST2110 has delivered, it provides low latency video, audio, and metadata distribution for broadcast infrastructures all over IP. However, further challenges occur when we start to investigate the nuts and bolts of making systems work in practical applications.

Traditional broadcast systems have benefited from point-to-point circuit switched infrastructures where sources and destinations employed labels to identify them. This methodology has worked well but the fixed nature of the circuits highlights the principal benefit of IP infrastructures, that is, they are dynamic and greatly flexible. Flexibility is important as broadcasters can add and remove cameras and microphones and assign them to production switchers and sound consoles. The difficulty arises when we try and identify each of these devices so we can route them.

In the IP world, it’s worth reviewing what is meant by routing, specifically because data-link layers such as Ethernet uses packet switching. To achieve packet switching, the layer-2 switcher must know which of its ports to send the packet to. This is achieved using the source and destination MAC addresses when working within a single broadcast network. If an IP packet needs to be moved outside of the current layer-2 network, then it must either be bridged to another layer-2 network or switched using layer-3 routers. Consequently, each switch and router must keep a track of the layer-2 frame addresses (MACs) and the layer-3 IP addresses.

Within enterprise broadcast networks the IP address of each device is often fixed for infrastructure critical equipment such as network storage devices and servers. Broadcast infrastructures often replicate this with cameras, microphones, monitors, sound consoles and production switchers, but in doing so, they all need an IP address. Keeping track of every device IP address within the broadcast facility is a challenge to say the least. Furthermore, it’s not unusual for devices to have multiple network interface cards and therefore multiple IP addresses. For example, a camera may have multiple network interfaces, one IP address for its video transport, another for monitoring, and a third for control. Separating the physical ports in this way will help separate the video, monitoring and control from each other thus reducing the risk of congestion and latency, but in doing so, will require at least one IP address for each network interface.

Life gets even more interesting when we consider the signal distribution within a broadcast infrastructure. To maintain efficiency and reduce the risk of congestion broadcasters will employ multicast streams. In the same way that a video or audio distribution amplifier provides a one-to-many distribution for each circuit they are connected to, then multicast-enabled routers provide similar one-to-many mapping.  A multicast address is identified using a specific IP address range from 224.0.0.0 to 239.255.255.255. In a broadcast infrastructure a subset of these addresses can represent individual video and audio signal flows, thus further complicating the task of mapping devices and signal flows to IP addresses.

NMOS (Network Media Open Specification) was developed by AMWA, the Advanced Media Workflow Association. This group of specifications solves many of the challenges just listed, and a few more. It essentially delivers a discovery and registration specification that allows a device to be plugged into the network and then identified by a centralized controller that maps a human readable label to the IP address.

Figure 1 - The NMOS registration and discovery system provides a single source-of-truth for the devices, such as cameras, sound consoles, and production switchers, that are registered in the broadcast infrastructure. The query service allows devices, such as the sound console, to find authenticated and trusted devices on the network such as microphones and loudspeakers.

Figure 1 - The NMOS registration and discovery system provides a single source-of-truth for the devices, such as cameras, sound consoles, and production switchers, that are registered in the broadcast infrastructure. The query service allows devices, such as the sound console, to find authenticated and trusted devices on the network such as microphones and loudspeakers.

To truly understand the power of NMOS think in terms of mobile phones, laptops, and notebooks. When a user of one of these devices enters a WiFi area, their device sends registration messages to the networks DHCP server which allocates an IP address and makes the DNS and Authentication server addresses known, thus allowing the user to automatically log on to the network. Although NMOS is some way from dynamically allocating IP addresses in practical applications, when implemented correctly, it has the potential to operate in a similar automated manner. For example, when an NMOS compatible camera is first presented to a network it will contact the discovery and registration server and be “registered” onto the network (using the NMOS specification IS-04). This is a database that is updated within the registration server so that other devices on the network can “see” the device. Admittedly, other devices need to poll the registration server to detect that a new device is available, but doing so provides a mapping between IP addresses and human readable labels, as well as providing a centralized method of knowing which devices are available and when, in other words, a single source of truth for the whole broadcast infrastructure.

This provides huge potential for IP infrastructures. For example, a production switcher can determine how many video sources and destinations are available within the whole network without manual configuration. If camera-1 in studio-A goes faulty and camera-2 is used to replace it, then all devices that are receiving camera-1’s video will need to be updated, this might include ISO recorders, clean feeds, and graphics processing equipment. In a traditional SDI system this would be relatively straight forward as MCR could re-route the signals from their SDI-router control panel. However, in the IP world, life is much more challenging as the MCR engineer will need a list of IP addresses and associated labels so they can update each of the devices that needs to receive the new camera stream. Using a centralized registration system makes this much easier as one single entry is changed within the registration database which will then feed into all the other receiving equipment. In effect, this presents a single source of truth.

NMOS haven’t stopped with discovery and registration and have gone further in replicating and specifying many of the other systems that we’ve taken for granted in circuit switched infrastructures.

IS-05 provides device connection management so that multiple devices can be connected without the need for a larger network management system. When connecting devices to the network then there is much more going on than just IP addresses. In the SDI/AES world we worked with very specific formats such as 1080i59.94 or 720p25, but in the IP world, to truly adopt the flexibility it offers, then we cannot take for granted that the signals are going to comply with a small subset of every potential video or audio format. Instead, they must be defined explicitly using SDP (Session Description Protocol) files. These form part of the device detection and registration system but in smaller designs where a centralized database approach isn’t practical, then IS-05 provides this functionality for device-to-device registration.

IS-07 makes provision for event messaging and tally. The humble GPIO lives on in the form of IS-07, albeit as an incredibly flexible messaging system. This messaging system allows devices to send out-of-band messages to each other so that communications can be established outside of vendor specific protocols. They can be time triggered and thus provide for relatively complex and flexible methods of automation.

IS-08 provides for audio shuffling so that audio streams can be mixed and matched within a network. IS-09 encourages interaction between NMOS nodes so that common global configuration parameters can be determined across a complete system.

As broadcasters become more and more aware of the need to improve security in their networks and adopt methodologies such as zero trust policies, then security in registration and discovery also needs to be improved. NMOS have achieved this by providing IS-10 – Network Authorization. This either accepts or rejects devices as they are connected to networks. When connected to the appropriate authorization servers such as RADIUS and Active Directory through systems such as Oauth-2 and OpenID, networks supporting IS-04 and IS-10 can provide high levels of security as only authenticated devices will be made available to other devices on the network, which in turn will only allow users to select trusted devices.

SMPTE have done a fantastic job of specifying signal distribution in IP infrastructures delivering low latency and high reliability. However, it is NMOS who are bringing “systems” protocol solutions to broadcasters so that they can develop and build IP infrastructures that are practical and usable.

Part of a series supported by

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,…