NMOS IN AN IP WORLD A CONCISE GUIDE by Steve Holmes and Kevin Salvidge
CREATED BY THE Advanced Media Workflow Association (AMWA), NMOS stands for Networked Media Open Specifications. No relation to its co-acronym: N-type Metal-Oxide Semiconductors.
AMWA’s NMOS is industry developed, free of charge and available to everyone. Its purpose is to enable the interoperability and management of IP-connected audio and video devices.
Figure 1 shows an example of an NMOS system. NMOS can be used to create and manage small and large multi-vendor systems. It lets you find, connect and configure media devices to enable video and audio on your IP network. Most importantly, it provides a simple vendor-neutral way to connect SMPTE ST 2110 senders and receivers.
An NMOS system essentially consists of three components (Figure 2). The registry server goes out and helps find all the senders and receivers in a connected facility. It puts these into a registry database and makes them available in the query service for the external control devices that interface into a customer’s particular equipment.
ST 2110 is a suite of specific protocols. NMOS follows the same approach based on a group of interface specifications (IS). IS-04
through IS-12 are itemized in the table shown below as Figure 3.
In NMOS terminology, a ‘device’ represents a logical block of functionality. Devices are located inside a ‘node’. An example would be a vision mixer which receives and sends on the network. Its capabilities and location are advertised via the application
programming interface (API). These nodes send their session description protocol (SDP) files to the NMOS registration and discovery system (RDS).
Device discovery and registration (IS-04)
IS-04 is used for finding NMOS nodes and their devices on the network, describing their capabilities and advertising the locations of other APIs. Each node sends its SDP file to the NMOS RDS. The file has all the data needed to be used by the NMOS system for connecting a sender to a receiver.
The registration API creates a table of available resources which the receivers will find and forward as an SDP text file. This file denotes what a sender and a receiver are and do.
The node API discovers the senders and receivers, then registers their existence. Figure 4 illustrates the process of NMOS device registration. A well-defined NMOS system behaves exactly like an SDI router.
Device connection management (IS-05)
IS-05 is the control part of NMOS. It is an API that provides the means to create a connection between a device in an NMOS-compatible system and other devices by the use of senders and receivers. Under control of the NMOS admin server/user interface, the server will send an SDP file to the receiver for the sender to connect to. In a conventional consumer off-the-shelf
(COTS) IP system, the receiver will issue a request to the multicast network switch for the entity to be connected to the receiver. The IP switch will then forward the requested multicast IP flow to the receiver. In a system where a COTS switch is not involved, the SDP file will be sent to the receiver to set up the receiver’s local interface (IP address and port). The user interface server API will configure the network element to send the flow to the appropriate receiver. The process is illustrated in Figure 5.
Session Description Protocol
Session Description Protocol (SDP) has been used in the IP world for many years. Originally published as a proposal in 1998 and subsequently refined, it encompasses all the fields and connection data needed for video. Endpoints in the NMOS environment need to be able to find the registration and discovery instances that make up the RDS. This can be accomplished by hard-coding endpoints with the IP address of the RDS but a simpler and more flexible method is to use Domain Name System Service Discovery (DNSSD). Figure 6 shows an example.
DNS provides a mechanism that allows endpoints to resolve IP addresses from host names. When you type Google.com into a web browser, a DNS server looks up the domain Google and finds the IP address to connect you using that IP address. DNS-SD provides the additional ability to discover hosts that provide specific network services from service type records. The control network for NMOS and the RDS are quite often on different networks or subnets in SMPTE 2110 systems so we need a way of knowing the address of the RDS server on the other network/subnet to be able to register a device in the RDS.
NMOS troubleshooting
It is not uncommon for an OB project to start with the entire vehicle preconfigured for 1080i operation but you actually need it configured for 1080p. So the engineer in charge switches all the cameras to 1080p but the receiver is still configured for 1080i and will remain so until an updated SDP is be sent. It is not quite like SDI where the video payload ID travels with the video signal.
NMOS is HTTP so you can check connections with a laptop by typing the relevant IP address, RDS address or node.
The system will then issue a reply. You should always look at the SDP file on the receiving device first. The control system may not show the formatted SDP.
Figure 7 shows an error one company had. The last RTP packet type contained the wrong RTP packet type value, shown in red.
Figure 8 depicts an NMOS troubleshooting display on a Leader LV5600 SDI/IP waveform monitor. This provides easy access to the NMOS IS-05 connection list, highlighting video receiver 1, current time, input, source ID, destination and response. Detailed parameters are displayed in the lower section of the screen.
Figure 9 depicts the NMOS troubleshooting display on a PHABRIX Qx Series SDI/IP rasterizer. Operators can gain a complete overview of the NMOS receiver and sender status at a glance, with a simple and intuitive green tick-box display along with active receiver SDP record and human-readable tree view of the IS05 JavaScript Object Notation with expand/collapse for rapid
navigation.
NMOS error-tracking examples
Switching from progressive to interlaced scan is an example of a potential NMOS ‘gotcha’, illustrated in Figure 10.
The sender node changes its format and duly issues new SDP data to the registration server which then forwards the SDP data to the registry database (Figure 11). But all devices that had connected still have the old data. To overcome this issue, the NMOS admin server needs to be manually instructed to send an updated SDP entry to all receivers.
Frequently Asked Questions
Q: In a multi-facility environment, can you have a distributed NMOS server? Maybe something that uses primary/secondary redundancy? Not all devices allow for static NMOS addresses but I can’t have multiple facilities operating on a single VLAN to allow multicast DNS. It would be nice if I could have multiple NMOS servers synchronized to each other and allow devices to talk to the local server for its database. Do you know of anything like that?
A: Redundancy would have to be 1 x n server side.
Q: I think Imagine’s Magellan Control System updates SDP files automatically on changes to the senders. That’s what we use, and I’d say changes like format and multicast address update automatically about 70% of the time.
A: Yes, most all senders will update the RDS but all receivers still have the old SDP file because that was sent from the vendor control system; there is no record in the NMOS system about which receivers are connected to which sender. 70% of the time may not be good enough.
Q: Not many 2110 networks run DNS services. Is there a common implementation for DNS in these instances? Separate server or on the router orchestrator?
A: It is the RDS that is doing an DNS announce that the nodes find. Click here for more information. Riedel’s NMOS explorer uses Apple’s Bonjour implementation of zero-configuration networking, a set of technologies that includes service discovery.
Q: How do you know which port to use on which nodes or RDS?
A: You set this when setting up your system, just like setting an IP address. You set a port for the RDS and you set ports for receivers and senders.
Q: What NMOS deficiencies have you found?
A: One of the biggest is that it is up to outside equipment to maintain a database of which receivers are connected to which senders. If the sender changes a parameter, it is not automatically sent to all receivers. In SDI the VPID goes where the video goes so everyone gets the update. Vendor interpretations of NMOS can differ. Some receivers require the grandmaster to be on the same network. If the Best Master Clock Algorithm has changed the grandmaster since the SDP was created, that too can cause issues. And if the configuration of a sender changes, how are all the receivers updated?
In summary, NMOS is a very useful set of protocols in an IP networking context but introduces an extra layer of system configuration which requires careful monitoring. Leader and Phabrix instruments make this easy by allowing fast access to the connection list and related metadata.
If you would like to learn more about NMOS and its deployment in SMPTE ST 2110 environments, please visit the Leader Electronics of Europe YouTube channel by clicking here.
* Steve Holmes is a Solutions Architect and Application Engineer at Leader Instruments Corporation, USA, focusing on SMPTE 2110 IP Video, PTP, monitoring, 4K, HDR and video test solutions. Steve has over 35 years of video application engineering experience including 21 years of video application engineering with Tektronix and 21 years with GTE/Verizon installing, teaching, engineering and managing video and CATV systems.
** Kevin Salvidge commenced his broadcast industry career in 1986 as a commissioning engineer at Marconi Instruments, progressing to Sony Transcom, Tektronix, GVG/Thomson and Sony Broadcast. He joined Leader in August 2015 and is now Sales Engineering & Marketing Manager at Leader Electronics of Europe.
