What is NMOS?

Many engineers believed that the release of SMPTE2110 was sufficient to ensure compatibility for all the gear in a media IP-centric environment. Not so, the standard defines the transport layer only. Complying with ST2110 will only guarantee a signal will pass through a compliant network and can be decoded by a compliant device. It doesn’t specify the IP addressing schemes, multicasting schemes, codec types, bit rates, formats, etc. Currently, all these parameters for each device must be manually configured, making automation difficult. Enter NMOS.

Building IP networks is currently at the similar state general computing was prior to plug-n-play and DHCP some 15 years ago. You could make a computer work on a network, but the engineer had to manually configure the network card on each device. NMOS is addressing this much as Microsoft provided automatic network configuration for laptop computers, home networks, and Wi-Fi.

NMOS-Another Piece of the IP Puzzle

NMOS stands for, Networked Media Open Specification and it is being developed through an organization called AMWA-Advanced Media Workflow Association. AMWA is the group developing the network protocols that ST2110 needs to operate on an IP network. What you say, not SMPTE!

Once upon a time, AMWA was working in parallel on the networking pieces while SMPTE was working on ST2110. Along the way, SMPTE ratified ST2110 and parsed out the networking pieces to AMWA to finish and publish. Along comes NMOS which are open specifications in the form of API’s (remember the early days of Linux). API’s or Application Program Interfaces are the programming guidelines to develop communications between devices. Sometimes the API is a pre-programmed module or plug-in, but most times its guidelines for someone to write code with specific commands and structure that another device can interpret. Anyone remember RS422?

NMOS provides discovery, registration and control for the SMPTE ST2110 suite. Wait, doesn’t SMPTE ST2110 capture that? Well sorry, but no. It seems while SMPTE, VSF, IEEE, IETF AND AMWA were all playing together on the essence and timing components aka content, the networking pieces (discovery, registration and control) were separated out and following a different track. So in the new world of IP over a network, the components that control and manage the devices on the network are not fully integrated in the SMPTE standard and aren’t yet even their own standard, just an open source specification. Haven’t we been down this road before? An open specification is not even a protocol, more like a polite suggestion of a code base that anyone can adopt and adapt.

There are currently three NMOS specifications critical to ST2110, two are published and one is pending approval. They are posted on the AMWA GitHub site and anyone can download them. Because it’s open source, the code can be modified or customized by each user. How does this affect interoperability?

Note: As I was writing this article, Microsoft acquired GitHub. It is unknown the impact it will have on “Open Source”!!! 

According to one manufacturer, because this is an open specification and not a standard or integrated in ST2110, manufacturers are not obligated to incorporate it and even if they do, they may not implement the same way. But then he said, it makes good business sense to stay compatible and that should help. 

  • IS-04 (Published) - Discovery and Registration – This specification is the API that discovers and registers devices as they are connected to the network, it is installed on each device and communicates with IS-05.
  • API IS-05 (Published) - Connection Management - It’s important to note that this API needs to run on each media device in conjunction with the IS-04 API. IS-05 allows the configuration of connections between devices called Senders and Receivers. An end point device can be a sender, receiver or both. As an example, a camera is a sender, a production switcher is both sender and receiver.
  • IS-06 (Pending) Network Control - This standard enables a broadcast controller to view the entire network topology and controls the creation/retrieval/update/deletion of flows in the network between endpoints. This specification includes network monitoring and diagnostics. Note it says “broadcast controller”, that would be the NMOS server. 

How Does NMOS Work?

Recall some points made in the article “Surviving the Early Adoption to IP.” Let's look at the entire ST2110 topology. The first thing I’d like to mention is that at SMPTE’s Bits on the Bay conference it was clear that the ST2110 standard was an in plant or in facility set of standards. It does not apply to contribution or distribution, which will likely remain J2K. This also means that not all networks are created equal.

The move to software defined networking lifts the routing and management of the network out of the devices and moves it into a server. Now the network services and configurations can be protected, network upgrades can be non-disruptive and additional layers of management and control services can be implemented. So where does NMOS fit in? SMPTE ST2110 encompasses video, audio, timecode, sync and ancillary data. NMOS is the media network management layer in the stack. In a typical IT network there are domain controllers and active directory services that manage traffic. Taking this one level deeper, NMOS gets more specific to media devices.

Implementing NMOS is a Multi-Part Process

On the endpoint side, each manufacturer needs to embed the appropriate API’s in their devices, build an interface accessible by a user and integrate NMOS with their product. The integration includes sending and receiving NMOS along with the ST2110 essence package. The NMOS server is the controller that manages the transport and communication between devices, a broadcast controller, across the entire media network. This is essentially another layer in the full network and functions like an SDN. See Figure 1. 

Figure 1. Example ST2110 software defined network.

Figure 1. Example ST2110 software defined network.

NMOS is implemented in a hub and spoke topology as a layer in broadcast networks in some ways similar to the way the PTP Grand Master clock that is external to the core network router and switches before it’s introduced in the network as one of the ST2110 layers. The NMOS server integrates the same way. Once NMOS is introduced into the network it manages communications between all the endpoint devices. On the device side, NMOS is critical to direct the traffic flow of the essence packages. NMOS is also providing the negotiation between multicast and unicast.

Looking at this as SDN, the core, spline and leaf switches are managed by a network controller. The NMOS broadcast controller only communicates on the network to devices that have the NMOS API embedded.

Given the importance of NMOS, let's hope it will become part of the ST2110 Standard to insure interoperability in the management and control of media on the IP network.

Editor’s Note: Gary Olson has a book on IP technology, “Planning and Designing the IP Broadcast Facility – A New Puzzle to Solve”, which is available at bookstores and online.

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