In times of SDI, the world of controllers was pretty simple: a broadcast controller was the main tool and front end for your operations. Those controllers often worked with a combination of hardware panels and software user interfaces and provided signal routing across your baseband router infrastructure, have built-in label, UMD, tally and joystick override management and allow real-time parameter control. Over time, broadcast-controllers have evolved and offer monitoring and some level of automation, for example to schedule actions in the future or to automatically loop in a processing device such as an upconverter from a resource pool when an SD source needs to be routed to an HD destination.
With the move from SDI to IP, SDI routers got replaced by one or multiple switches and the media endpoints (i.e. senders and receivers). A new type of controller came into play for broadcasters: SDN controllers that manage both the real-time IP networks and the media endpoints. The SDN-controller has the same job as your SDI router previously had; it connects inputs with outputs, ideally as fast and as deterministic as it was the case in SDI. There is a plethora of different technologies, specifications, standards and switching paradigms available, every SDN controller works slightly differently. Finally, you can also find network controllers in the market which focus mainly on controlling the network, and less on managing the media edge device. For more information on SDN control, have a look at our recent white paper.
SDN-controllers for the broadcast market typically have a northbound-interface that make them look like a traditional router for other systems, i.e. a broadcast-controller can use the very same adapter (protocol) to interface with the SDN-controller than in the past when connecting to an SDI router.
Some vendors have developed new SDN-controllers, some broadcast controllers have expanded their functionality to also act as SDN-controllers. Often, those controllers are called (SDN) orchestrators, and this is where confusion already starts. Even worse, broadcasters realize that with the challenges and the complexity, dynamics and agility an all-IP facility offers, a combination of a broadcast controller and an SDN controller is not enough anymore.
An additional layer on top is required to “put things together”, to manage all technical, operational services and business workflows end to end; let’s call this an “orchestration layer”.
So what is the answer when you plan an all-IP facility and ask multiple vendors: “can you do orchestration?” For sure, the answer will be “YES” from everybody, but it’s not sure that everybody is talking about the same thing. The term “orchestration” is used in many ways by many different people.
Let us start with one conclusion: orchestration is more than switching signals in an IP network.
Ideally, a broadcaster wants to buy a product that combines all features of an SDN-controller, broadcast-controller, and top-level orchestration layer in a single solution. Let’s call this an “orchestration platform”.
In part II of this blog, we will have a look at what an orchestration platform does and how it manages your services, productions and events from all angles, starting from secure onboarding of resources, monitoring your infrastructure, managing physical and virtual resources, connectivity, capacity up to the complete lifecycle of events and productions.
You will see that DataMiner can offer a complete orchestration solution including SDN-control and features of a typical broadcast-controller. There are also use cases in which it becomes clear that interfacing with third-party SDN- or broadcast-controllers achieves the best solution for your operations.
3 thoughts on “Controllers and Orchestrators for Broadcast: which is which? – Part I”
Wow, very crisp.
Nicely elaborated. Thanks Thomas.