Why AMWA NMOS Has Superseded AES70 for Connection Management

Posted on by

In the transition to IP-based media infrastructures, particularly those built on SMPTE ST 2110 and AES67, the industry faced a critical decision: how to discover devices and manage the complex connections between them. While AES70 (Open Control Architecture) offers a comprehensive object-oriented framework for device control, it has effectively lost the battle for **connection management**.

Despite AES70’s theoretical capabilities to handle stream connections, the industry has overwhelmingly adopted AMWA NMOS (Networked Media Open Specifications) as the de facto standard for connecting senders and receivers. For systems integrators and facility architects, the message is clear: when it comes to connection management, NMOS is the required “special sauce,” while AES70’s routing mechanisms should be considered deprecated in favor of the IS-04/IS-05 stack.

The Reality of Adoption: A One-Horse Race

The primary argument for replacing AES70 with NMOS for connection management is simple: ubiquity driven by industry mandates. While AES70 defines mechanisms for connection management—specifically through classes like `OcaMediaTransportApplication` and `OcaStreamNetwork`—these features have not seen the wide-scale adoption necessary to ensure multi-vendor interoperability.

In contrast, AMWA NMOS IS-04 (Discovery & Registration) and IS-05 (Device Connection Management) have been cemented as the “bedrock” of modern IP facilities. This dominance is enforced by the **JT-NM TR-1001-1 Technical Recommendation**, which explicitly mandates that media nodes in engineered networks “shall expose an AMWA IS-05… device connection management API” and “shall register using the IS-04 registration API”.

Leading industry bodies, including the EBU and SMPTE, have aligned behind this mandate. The EBU’s “Technology Pyramid for Media Nodes” places AMWA IS-04 and IS-05 as the minimum requirements for Operational Control, relegating other methods to niche or proprietary status. Consequently, almost all new SMPTE ST 2110 products incorporate NMOS IS-04 and IS-05, making it the “lowest common denominator” for device detection and routing.

The Efficiency of IS-05 vs. The Complexity of OCA

AES70 is an object-oriented architecture designed to model the entire internal function of a device, from gain controls to firmware management. While powerful for deep device surgery, using such a heavy, complex architecture simply to patch a stream from Device A to Device B is inefficient compared to the web-friendly approach of NMOS.

NMOS IS-05 was built specifically to solve the “transport-independent” connection problem that ST 2110 left open. It utilizes a lightweight, RESTful API structure that allows controllers to stage and activate connections using standard SDP (Session Description Protocol) files. This approach essentially allows an IP system to behave with the push-button simplicity of a traditional SDI router.

Furthermore, NMOS separates the concerns of **connection** from **control**.
* **IS-05** handles the “patching” of streams (multicast joins, SDP transport).
* **IS-08** handles the mapping of audio channels within those streams.
* **IS-04** maintains an up-to-date registry of resources.

This modularity allows integrators to build systems where connection management is standardized and automated, without requiring the deep, device-specific object models demanded by AES70.

AES70: A Control Protocol, Not a Connection Manager

AES70 proponents may argue that the standard is intended to complement media transport architectures. Indeed, AES70 allows for an “AES70 Adaptation” to manage connections. However, the complexity of implementing these adaptations has stifled adoption. For example, managing an AES67 connection via AES70 requires creating specific `OcaNetworkInterface` objects, `Aes67OcaMediaTransportApplication` classes, and handling complex object numbering.

In comparison, an NMOS controller simply queries a registry (IS-04) and sends a JSON transport file to a receiver (IS-05) to establish a connection.

Even the documentation for AES70 acknowledges its limitations in scope, noting that it addresses “device control and monitoring only” and does not define the transport scheme itself. While AES70 remains a valid option for controlling specific device parameters (like a fader level or a mute button), the industry has signaled that it should not be used for the logical routing of media streams. Even in the realm of device control, AMWA is moving forward with **IS-12 (NMOS Control Protocol)**, further encroaching on the territory previously held by AES70.

Conclusion: Deprecate to Integrate

To achieve the “truly open sandbox dream” of IP interoperability, the industry must stop fragmenting connection management strategies. While AES70 remains a robust specification for deep device internal control, its use for connection management has become obsolete in the face of the JT-NM TR-1001-1 mandates.

Integrators and manufacturers should view NMOS IS-04 and IS-05 as the non-negotiable standard for routing. Attempting to force AES70 into the connection management role adds unnecessary complexity and breaks the standardized interoperability that broadcasters demand. It is time to treat AES70’s connection management features as deprecated legacy technology and embrace the NMOS stack as the singular solution for IP media routing.