Related content:

This article provides an extensive reference resource for broadcast system designers, engineers and the community of product designers leveraging the NMOS standards to create effecitve, robust systems.

Introducing AMWA

The Networked Media Open Specifications (NMOS) specifications have been developed and published by the Advanced Media Workflow Association (AMWA). This is a broadcast industry association founded in 2000. AMWA collaborates with other organizations to create standards and guidance. Use them to help migration from conventional broadcast hardware infrastructure to an IP based solution. Prior to NMOS, AMWA developed other technology solutions and continues to work on new initiatives such as IPMX and ProAV:

• FIMS - Framework for Interoperable Media Service provides a framework for integrating hardware and software in TV production environments.
• AAF - The Advanced Authoring Format is a file format designed to carry multimedia assets. A sub-set of AAF is often carried in SMPTE MXF file containers which are designed to be portable across a variety of NLE systems. MXF is derived from the earlier Open Media Framework Interchange file format.
• MXF & AAF - Specifications that facilitate the adoption of AAF and MXF files and how best to deploy them from production to distribution.
  

ST 2110 Benefits From NMOS Support

When SMPTE introduced ST 2110, the original design was scoped around the delivery of SDI video over an IP network. The main focus was transport and there was no support for routing and resource management. Revisions in 2022 stabilized and extended the scope. Other parts continue to be published occasionally as they are completed.

Some early detractors criticized ST 2110 claiming that it was incomplete. Standards often rely on other documents to provide additional context and coverage. This avoids the tendency for a standard to become too large and unwieldy and avoids re-inventing too many wheels. ST 2110 benefits from the complimentary NMOS standards developed by AMWA. Taking both into consideration creates a much more complete picture. ST 2110 is an essence transport technology while NMOS is the supporting metadata framework that helps to manage and deploy it.

About NMOS

NMOS describes features, message protocols and formats for the control plane in an IP enabled infrastructure. It is not a controller in itself. NMOS facilitates the interoperation of the connected media devices and software. This is fundamental to connecting senders and receivers in your ST 2110 environment.

Modern hardware with an embedded Ethernet RJ45 connector often has a web-based administration user interface (UI). Adding NMOS support is an incremental change to provide the additional URL endpoints to support the protocol handlers. Software based products can run in virtualized containers that host a web server to support the NMOS handlers. Some work is necessary to integrate the back end of the web server so the page requests can interact with the hardware or internal software services.

NMOS is an open-source solution designed to work with locally connected devices or cloud-based services. This open-source nature avoids vendor lock-in which improves the modular nature of your architecture. Solutions from a variety of vendors are more easily integrated because they behave in a consistent way. It also allows alternative vendor solutions to be plugged in as replacements when your needs change or when scaling is required.

There are many benefits to using AMWA NMOS protocols in your IP studio architecture:

• There is now no need for manufacturers of hardware or software to develop proprietary protocols. This avoids locking customers into a single manufacturer.
• Easier integration of products from different manufacturers.
• Customers can choose the best solution for each part of the workflow.
• Status and health monitoring is easier and can operate through a unified user interface.

Consult EBU document Tech 3371 to see how NMOS integrates into the Technology Pyramid for implementing Media Nodes. The JT-NM Technical Recommendation TR-1001 covers additional related material.

Although the NMOS specifications were initially created to supplement ST 2110 architectures, they are relevant to other activities outside of a ST 2110 environment. NMOS facilitates the management of IPMX, ProAV and AES67 resources as well as ST 2110. It is also an integral part of creating effective software defined systems, and workflows that leverage cloud compute infrastructure.

Drivers & Abstraction Layers

A significant proportion of software development normalizes disparate hardware and software interfaces. Low-level device drivers convert proprietary API calls that drive a hardware interface so that the application layer can interact with them using the same functional calls. Additional layers such as Metal in the macOS environment provide higher-level capabilities and completely hide the underlying hardware and software implementation.

Sometimes a driver will simulate features not supported by the target device in order to support the top-level API. This extends the life of older legacy devices that have been replaced by modern counterparts.

NMOS does a similar job to a device driver by providing a common API to proprietary hardware and software used for media delivery. This greatly simplifies the application layer and constructing dashboard consoles that exploit NMOS will be significantly easier.

Resource Management

NMOS manages a central inventory of the available and reachable resources across your infrastructure. Resources include the following:

• Sources.
• Flows.
• Senders.
• Receivers.
• Nodes.
• Controls.
• Services.

Having an inventory makes it easier to find devices. Request their metadata and determine whether they support send or receive behaviors. Drilling down into the available detail reveals which media formats are supported. This level of granularity helps build flexible user interface consoles. Given a choice of media type and format, present the compatible senders and receivers to the user for selection. Streams can be gathered using a natural grouping to match the correct audio stream to a video, or possibly choose one of several alternatives for localization. Devices can be labelled so they are easy to find again later. Tag them to apply searches and filters. More detailed descriptive text attached to a device can describe special instructions for using it.

Refer to these NMOS documents for more information:

Signal Management

Having identified the devices, managing the signals routed between them is necessary. A node graph system would be an intuitive way to design a UI for this. Connect the senders and receivers to indicate the flows.

Joining senders to receivers is typically done via a virtualized matrix. This allows the same output to be routed to one or more inputs on other devices. This is conceptually the same as a hardware matrix switcher but uses IP routing instead.

NMOS manages these media types:

• Video streams.
• Multiple audio streams.
• Timed-text streams.
• Other timed metadata.
• GPIO, events and triggers.
• Tally information for control consoles.

Analytics and logging can take place in the NMOS environment to generate metadata for later performance and traffic studies.

Some of this activity may happen inside the devices whilst other things are transported between them.

NMOS can simplify the deployment of multicasting. Previously, this would need to be configured inside a device but NMOS externalizes it.

NMOS manages senders and receivers. Since it is just routing information from sources to destinations, it can control the routing of data and event triggers as well as media. A switch on a console can be used as a sender. An indicator lamp or tally display is a receiver. This is similar to the Scada system used for building industrial process control systems.

Routing a copy of an audio stream to a process that averages the audio level and emits a value periodically implements a basic VU meter. That could be built with a Raspberry PI or Arduino IoT device. NMOS would treat it as a receiver for audio streams and a sender for the audio level data value. It can route that data value onwards to an indicator on the console. Here is a conceptual design of this simple use-case:

The localizer represents that part of the virtualized routing matrix that selects the required audio language. The output is split two ways to different receivers.

Appropriate stream format selection is implicit in the connection of a sender to a receiver. AMWA provides Best Common Practice (BCP) documents. They describe how to use NMOS with streams other than ST 2110 carrying SDI content.

NMOS can pause and resume the output from a sender when necessary. If your NMOS resources are configured correctly, everything should work as expected.

Refer to these NMOS documents for more information regarding the connection of devices, mapping audio channels and compressed streams: 

These documents describe device control and status monitoring:

These documents contain guidance for configuring device and media parameters:

User Interface Design

Be sure to observe the most important Prime-Directive when integrating user interface actions and indicators:

1. The button triggers the event.
2. The event performs the action.
3. The observed change of state of the target triggers a UI update event.
4. The UI update event calls a handler to action.
5. The UI indicator appearance is only updated by that handler based on the observed state.

This ensures that indicators indicate the correct state after the action is completed. If you change the indicator as part of the initial call-to-action, the indicated state is not correctly synchronized if the action fails.

Security Recommendations

Read the guide to security implementation in NMOS document INFO-002. Other documents address specific aspects of security. All of these NMOS documents are relevant to securing your system against unwanted intrusions:

One of the output documents from the JT-NM Tested program is a Cyber-Security report. Consult this for basic guidance on security countermeasures that are important to implement.

There are other additional IP specific security countermeasures not covered by JT-NM. Consult the Open Worldwide Application Security Project (OWASP) for valuable guidance and intrusion testing tools.

The Building Blocks

Within an NMOS managed ST 2110 infrastructure there are various behaviors that the individual entities can adopt. Some devices may support multiple behaviors. For example, an ST 2110 sender is distinctly different to a receiver but a processing node might support both behaviors and consume incoming content and dispatch it onwards after processing.

Other services are provided by the network infrastructure. These are the principal component building blocks:

The relationship between these components is illustrated by this diagram (based on a similar one in the AMWA documentation).

A Media Node is a physical or logical group of behaviors with a mix of Senders and Receivers. The discovery process is described by the NMOS IS-04 specification. Document IS-05 describes how they are controlled. Some media nodes may be sender only or receiver only.

The Broadcast Controller uses the NMOS protocols to manage the connections between the media nodes. This is also described in the JT-NM Technical Report TR-1001.

Several NMOS standards should be consulted first:

• IS-04 describes how devices can discover one another.
• IS-05 describes the connections between each device.
• IS-09 describes the system parameters that the media nodes need.

A Sender may generate one or more streams from its input source. For example, a hardware device with an SDI connector for input can transmit IP packets on the network via an Ethernet connector as its output. Multiple streams provide redundancy and all the streams must conform to these SMPTE standards:

• ST 2110-20 - Uncompressed Active Video.
• ST 2110-30 - PCM Digital Audio.
• ST 2110-31 - AES3 Transparent Transport.
• ST 2110-40 - SMPTE ST 291-1 Ancillary Data.

A Receiver consumes one or more of the streams created by a sender. Redundant systems designed for resilient use allow the receiver to consume multiple sender streams to provide resilience against packet loss.

The Dynamic Host Configuration Protocol (DHCP) is a network service that defines the network configuration centrally. A server vends the necessary details when requested by a client device. It is possible that the IP address defined in this way will change from time to time. NMOS manages this via the registry so that nodes are only identified by name.

Precisions Time Protocol (PTP) network services ensure all the media nodes are synchronized.

The Domain Name System (DNS) configurations are shared from a central network name server to convert symbolic (human readable) host names to IP addresses used for packet routing. If DHCP changes the IP addresses, then this must be carefully integrated with the NMOS registry so devices are still reachable by name.

The Difference Between A URI, URN & URL

In the NMOS documentation, the messaging format and device identification uses several terms which sound as if they are the same thing:

• URI - Uniform Resource Identifier.
• URN - Uniform Resource Name.
• URL - Uniform Resource Locator.

These are all different notational forms that can be used to describe resources in an NMOS environment. The appropriate format is dependent on the context where it is used.

URI - Uniform Resource Identifiers

A Uniform Resource Identifier is a description of a resource. The resource is identified by name or location. When it is identified purely by name, then it is considered to be a URN and should have the urn: prefix. If it describes a location, then it is a URL and has a transport scheme prefix.

W3C suggested that we should always use the term URI to describe the location of web pages. Popular convention suggests that we use URL instead to describe web-requests and URN to describe abstract resources. Only use URI when the resource could be either.

URN - Uniform Resource Names

URL - Uniform Resource Locators

About Request-response Transactions

JSON - JavaScript Object Notation Basics

JavaScript Object Notation describes an object graph using a pure text format. 

It was originally designed by Douglas Crockford to implement real-time server to browser session data transports. The original concept is simple and exploits JavaScript’s native ability to execute code passed as data.

The JSON content must therefore conform to executable JavaScript syntax. Later extensions to JSON to support Unicode required updates to the ECMA 262 Core JavaScript standard for this to be supported. The JSON format is also standardized as ECMA-404. Download both of these standards free-of-charge from the ECMA web site. The JSON functionality is very easy to understand. The ECMA-404 standard uses syntax diagrams to explain how the parser works. Just follow the path like a railway layout. Here is the syntax diagram for a JSON value:

The equivalent JSON payload is constructed from individual nested atoms. Recall that we saw similar atomic nesting structures in AV media files. These hierarchical tree structures crop up everywhere in IT and AV media systems and are visible inside web-bowsers as the Document Object Model (DOM).

This is the JSON serialized version of the object graph:

Distinguishing Resources From One Another

Several mechanisms exist to identify unique resources. This is granular enough to identify different time-based variants of each resource too. These properties are used to explicitly identify a target resource:

Identifying Resources With A UUID

Core resources such as Sources, Flows, and Nodes must be uniquely identified. They use a Universally Unique Identifier (UUID) which is a 128-bit value. UUIDs are standardized by the Open Software Foundation (OSF). Microsoft implements a similar scheme but describes them as a GUID.

There is a conventional format for UUIDs which are always expressed in hexadecimal notation - shown below.

The first 20 digits are based on timestamp values. This guarantees the uniqueness of the UUID. The last 12 digits identify the node. That could be an Ethernet Mac address for example.

There is a small caveat that a UUID might be duplicated elsewhere but the likelihood is so near zero that it is practically unique worldwide. This is because the first part of the UUID value is derived from a timestamp measured in increments of 4-micro-seconds. The odds of two identical UUIDs being created at the exact same time are astronomical. They would also need to have an identical Node value to cause a collision. It is not impossible but very unlikely.

Identifying Flow Transitions With Version Values

Tagging Resources For Searching

Adding tags to resources increases the number of possible search options. Attach tags to individual resources and maintain a super-set in the central registry. User interfaces can use that when building search panes in the console.

The search-engine can therefore locate all the content recorded from a particular studio by filtering resources via the appropriate tags.

What Happens When A Node Starts Up

When a device is booted, it needs to start up various software processes and join the NMOS environment. This is a simplified step-by-step description:

Once a resource is registered, NMOS can ascertain whether it is a sender or receiver and what kind of media is compatible with it. Once NMOS knows this, it can present matching senders and receivers to the dashboard for an operator to connect them together.

Accessing The Document Collection

AMWA manages the editorial process for these standards using Continuous Integration techniques similar to those used by DevOps engineers who maintain source code. The document source is maintained as a collection of Markdown files in a Git repository. When changes are made, the repository is rendered to create the online version. This takes care of dependencies between documents and applies some editorial styling and checks as the web content is manufactured. It is a clever solution to managing a large collection of related cross-referring documents.

The downside is that there is no static PDF copy available for offline reading and the documents need to be read online in a web-browser. The lack of a PDF is purposeful and avoids the circulation of obsolete documents after changes have been made. NMOS is still a work-in-progress.

Read the NMOS documents here:

Documents are classified according to the kind of guidance they provide:

AMWA publishes a roadmap of currently in progress and planned standards development work. This helps long-term strategy planning, although it is difficult to predict exact timescales when standards will be ready for release.

Other Knowledge Sources

Useful resources are downloadable from the web-sites of these collaborating organizations:

• AIMS - Alliance for IP Media Solutions.
• AMWA - Advanced Media Workflow Association.
• VSF - Video Services Forum.
• AES - Audio Engineering Society.
• EBU - European Broadcasting Union.
• SMPTE - Society of Motion Picture and Television Engineers.
• JT-NM - Joint Taskforce On Network Media.

JT-NM

AMWA is a core member of the Joint Taskforce on Networked Media (JT-NM). This is a close collaboration between the AMWA, VSF, EBU and SMPTE organizations.

The IP Showcase Events

Annual industry conferences (NAB and IBC) often feature IP Showcase technical presentation streams. Tutorials and presentations are available online to explore after the conference event. Find their resources here:

Plug-fests

Periodically the industry gathers together to run ‘plug-fest’ events where the equipment and software manufacturers bring their products and test them in a realistic scenario. Many manufacturers and customers have collaborated to run these test programs to validate the NMOS protocols.

The JT-NM Tested program lists products that have been checked by industry experts at these plug-fests. Their conformance to the specification provides a degree of confidence that things have worked. The results from IBC 2022 (the latest) have been published along with earlier reports.

Compatible Products

AMWA maintains a list of compatible products that are available. Some are commercial while others are free and open-sourced. Whilst they don’t claim that the list is exhaustive, manufacturers can self-register products that are not already included. Check out the current list of products here:

Related Standards

These standards are relevant to working with the NMOS and ST 2110 architecture.

Conclusion

Explore the AMWA web site for tutorials and guidance. This is the authoritative source for NMOS material. The organizations that AMWA collaborates with also provide useful resources. There is a lot of help available to get you started.

Reading the NMOS documentation requires some patience and dedication. The first pass through the documents is easier if you just accept some of the statements on faith. Read the documents again, armed with the insights from your first pass. It gradually becomes clearer each time you open and read another one of the documents.

Discern the difference in formatting of the URN vs URL values. It helps to understand the IS documents better.

Review the API calls, this assists in understanding the URL request-response behavior. In particular, click on the highlighted buttons to see the request/response formats and the JSON syntax.

Review the JT-NM document describing the EBU Reference Architecture. This is the result of an important collaboration between the EBU, SMPTE and VSF.

As yet, there is no authoritative reference handbook describing how to build an NMOS compatible system. Gleaning the information from the AMWA NMOS documents and distilling it into a practical guide would be incredibly useful.

For the time being you need to use empirical knowledge and consult multiple sources and aggregate the findings to build up a complete picture.