As newsrooms transition to cloud workflows, one of the biggest challenges is integrating modern cloud-based editorial tools with legacy studio equipment. Graphics engines, video servers, automation systems, and playout controllers inside a control room typically rely on MOS, serial protocols, or local-area communication. Cloud-based systems exist outside that environment. They cannot directly connect to MOS devices due to firewalls, NAT boundaries, and security policies.
This is where the MOS gateway becomes essential.
A MOS gateway acts as the translator between cloud editorial tools and on-prem devices. It is the bridge that allows cloud-native rundown software to work seamlessly with equipment designed decades earlier.
The gateway communicates upward to the cloud using encrypted WebSockets or REST APIs. It communicates downward to studio hardware using MOS messages, TCP sockets, or custom device protocols. This dual-language architecture enables real-time end-to-end synchronization.
The MOS gateway maintains several important responsibilities.
First, it handles device registration. Each MOS device has a MOSID, and the gateway maps these IDs to specific endpoints. It also monitors heartbeats to ensure devices remain online. If a device disconnects, the gateway manages retries and reconnect logic so the cloud system remains consistent.
Second, the gateway receives rundown changes from the cloud. When a producer updates a story, script, or graphic assignment in a rundown system like Falcon Rundown, the gateway receives the update and generates the appropriate MOS messages. These may include:
- roCreate
- roReplace
- roDelete
- roStorySend
- roStoryReplace
- roStoryMove
- mosObjCreate
The gateway ensures messages are delivered in the correct order so MOS devices remain structurally synchronized. Determinism is crucial because MOS devices assume sequential consistency.
Third, the gateway supports object storage and handoff. Many MOS messages include references to media objects such as graphics templates or video files. The gateway may fetch or cache these objects locally on behalf of the device. When the graphics engine requests a specific MOS object, the gateway provides it.
Fourth, the gateway supports bidirectional updates. For example, a graphics engine may create a MOS object representing a lower third. The gateway sends this object back to the cloud. The editorial system now knows which graphics are available. This creates a fully integrated editorial and technical ecosystem.
Fifth, the gateway enables local failover behavior. If the cloud connection is interrupted, the gateway can continue serving the last known rundown state locally until connectivity is restored. This prevents studio systems from crashing during outages.
Another important function is security. Cloud based systems cannot open arbitrary inbound ports into broadcast facilities. Instead, the gateway creates a single outbound connection to the cloud. Behind this connection, multiple MOS devices can operate safely without requiring public exposure.
MOS gateways also provide version translation for older devices. Some facilities run legacy MOS implementations. The gateway normalizes message formats so even old equipment can operate with modern broadcast rundown software.
Finally, MOS gateways provide a crucial performance buffer. Cloud systems operate over the internet with variable latency. MOS devices require strict timing. The gateway smooths these differences by managing message queues and delivering updates at the pace expected by local systems.
Falcon Rundown’s cloud integration architecture is built around this gateway philosophy. Instead of forcing broadcasters to replace expensive studio hardware, the system seamlessly integrates with what they already use. This extends the life of MOS devices and reduces upgrade costs.
The MOS gateway is essentially the glue between two worlds. It allows the future of broadcasting to coexist with the past. Without this layer, cloud editorial tools would be isolated, unusable in real broadcast environments.