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.

Let us know what you think…

Log-in or Register for free to post comments…

You might also like...

Essential Guide: Live IP Delivery

Broadcasting used to be simple. It required one TV station sending one signal to multiple viewers. Everyone received the same imagery at the same time. That was easy.

Cost-effective IP Contribution and Distribution

Saving dollars is one of the reasons broadcasters are moving to IP. Network speeds have now reached a level where real-time video and audio distribution is a realistic option. Taking this technology to another level, Rohde and Schwarz demonstrate in…

The Migration to IP: The Revolution Continues

Are you an IT engineer having trouble figuring out why the phones, computers and printer systems work but the networked video doesn’t? Or maybe you have 10-15 years of experience with video production equipment but really don’t understand why…

Broadcast For IT - Part 20 - IP Systems

In principle, IP systems for broadcasting should not differ from those for IT. However, as we have seen in the previous nineteen articles in this series, reliably distributing video and audio is highly reliant on accurate timing. In this article,…

Broadcast For IT - Part 17 - Compression Formats

The bewildering number of video and audio compression formats available is difficult for those new to the industry to come to terms with. For broadcast engineers and IT engineers to work effectively together, IT engineers must understand the formats used,…