At the recent IBC conference, vendors were showing ST2110 compatible products. The IP pavilion was there to demonstrate how it all works nicely together, all interoperable, etc. There were sessions to introduce and provide the information and knowledge to implement ST2110. And a few announcements about new facilities and mobile units all IP based on ST2110.
And then there’s NMOS. One of the new challenges in introducing IP and ST2110 is the network and configuring the devices onto the network so they can find each other and play nicely together. There’s the new leaf spine network topology and lots to configure when devices are attached to the network. We’ve been hearing about Software Defined Networking (SDN) for a while, and now it’s actually real and here (sort of).
As my colleague Michael Grotticelli, writes in his article and stated by AMWA the author of NMOS, it’s a set of written guidelines to write programming code that will enable networked attached devices to communicate in the same “language”. Hmm!
At NAB NY, I wandered around asking folks about NMOS and mostly received blank stares. One or two kind people remembered the article I wrote, but not what it is, what it does, or how it does it. And most importantly WHO does it. As Michael discovered, the claim is to be a specification for Discovery & Registration, Device Connection Management and Network Control, Event & Tally, Audio Channel Mapping and Interoperable Security. Unfortunately, it’s a little unclear what this means.
Once a device is assigned an IP address either with DHCP or as a static address, the network knows where it is. The core router or SDN manages the connection and network control and network and device security is its own knowledge space.
So, where does NMOS fit in?
It’s not really the SDN, or is it part of the SDN if the “broadcast controller” hosts NMOS, and it lives near the core router and supports the entire media network? The NMOS specifications are text files on GitHub that anyone can download and follow to write code. The implementation of NMOS requires a computer or server on the network that acts as the host or broadcast controller that inserts and manages NMOS on the media network.
There are no instructions or specifications on how to deploy it or what the broadcast controller configuration is. Let’s look at the image above provided by AMWA as an explanation of NMOS IS-04. Is this something an engineer can use to design the implementation of NMOS into a broadcast network? The Amber and Blue networks appear to be redundant network segments. However, is the Control Network the core router or SDN? What’s a Media Node? Is it a production device? Are DHCP devices on the network or on DHCP controllers? Basic network design typically includes a DNS controller. What function does the broadcast controller provide? And is IS-04 a service, a device or a server? PTP is provided by the master clock and distributed over the network. IS-04 is only one of the NMOS specifications. How do the others get deployed?
A small note, the NMOS API needs a sender and receiver. So, on the device side, vendors need to voluntarily include the API in their product. It’s unclear, is the broadcast controller a product or a generic server that requires someone to write the API for the host controller? Whew!!!
As of this writing, the systems and facilities built or under construction have not deployed any of the NMOS API’s and there are no vendors that are currently claiming they have implemented NMOS into their products.
Design and house engineers are working to understand the required network topology for ST2110 with the considerations for PTP and how to properly configure the leaf spine correctly to assure proper network performance. Selecting the correct network switches, configuring and optimizing each network segment is daunting enough. The engineers I spoke to were barely aware of NMOS and did not consider it a priority.
There are a considerable number of parameters to configure in each device for ST2110 and each installation is different. It’s a brave new world and additional layers of complexity i.e. NMOS are not at the top of anyone’s list right now.
If vendors chose to include NMOS in their devices and also include the server side as a product, there is a higher probability of interest. There’s always room for helpful tools to install, configure and manage facilities. However, the tools need to be complete and provide the information needed to use them effectively. If the design engineer or the house engineer need to write program code using an API specification, there’s a good probability it won’t happen, or it will not be a core component of the system design.
As we are in the early days of ST2110 adoption and implementations, getting the network right is everyone’s primary consideration. Now, layer in contribution and distribution which do not use ST2110 or NMOS. These have their own standards and design points.
It’s easy to understand why NMOS may be a next generation consideration in the evolution to IP.
You might also like...
HDR offers unbelievable new opportunities for broadcast television. Not only do we have massively improved dynamic range with the potential of eye-watering contrast ratios, but we also have the opportunity to work with a significantly increased color gamut to deliver…
Sound engineers have spent over twenty years implementing and improving audio over IP systems. This has given audio a head-start in the race to migrate to IP. Not only does the sound seamlessly transfer across networks but recent designs have…
In the fourth and final part of this series, we wrap up with an explanation on how PTP is used to support SMPTE ST 2110 based services, we dive into timing constraints related to using COTS (Commercial Off-The-Shelf) hardware, i.e.:…
This past summer the NBA did a little experimenting using 5G and mobile phones to cover their summer league. This is not User Generated Content (UGC) by any means. It also was not an off the shelf deployment of 5G…
In the previous two parts of this four-part series, we covered the basic principles of PTP and explained how time transfer can be made highly reliable using both the inherent methods IEE1588 provides as well as various complementing redundancy technologies.…