People ask me what a solutions engineer does. The short version is that I listen first. A customer tells me what they need, and my job is to design something that actually works for the people who'll run it every day.
This project started that way and evolved into what we now call the IP Convergence Framework. Here's how it came together, in plain terms.
The customer is a broadcaster I can't name. Think of them as a network of networks. They ingest sports, news, and movies from many providers, assemble them into 16 channels, and send those channels to more than 1,000 sites around the world. Most of it went out via satellite, and the facility ran on traditional broadcast hardware: master control rooms, large video routers, all in one building.
Then they needed to relocate that facility to a new location. They didn't want to unplug all that hardware, put it on a truck, and plug it back in somewhere else. They wanted to use the move to move as much of it as possible into the cloud. They also wanted to lower their costs. And they needed it to work for their operators, who were used to running a broadcast plant in a certain way.
My first pitch was: have all your providers send their feeds directly to the cloud and turn the satellite off. It wasn't that easy. Some providers couldn't yet send to the cloud, so some signals still had to come in via satellite. The design had to handle both. That turned out to matter, because almost every broadcaster I talk to is in the same mixed situation.
I followed three rules.
1. Don't make operators learn an entirely new way of working.
"We needed to make it operator-friendly. We wanted operators in the new facility not to have to conceive of a whole new way of doing things." At a TV station, every signal goes through a video router, and operators choose where each one goes. So we built the same thing in the cloud. Zixi acts as a virtual router. BroadView built a routing panel that looks like the one you'd see in a station: pick the input, pick the output, done. The master control rooms, built on Grass Valley, are designed to feel like the ones operators already know.
2. Send each type of content down the right path.
By routing single high-bitrate sources through a unified workflow, we drastically cut storage costs while maintaining pristine quality for both broadcast and streaming. Live content like sports and news is routed to Grass Valley's cloud master control rooms for full broadcast-quality control, while all other content is processed via Uplynk. Everything is recorded using HLS at 12 Mbps. The top layer of this stream is dedicated exclusively to our HLS Editor and MP4 creation, preserving maximum quality for prerecorded playback in Grass Valley. The remaining layers directly handle standard streaming. This single-recording approach serves both broadcast and streaming destinations perfectly, eliminating the need to store and track a duplicate high-bitrate copy. That cuts storage costs significantly!
3. Build it so it can grow without a redesign.
The customer launched with more than 1,000 endpoints and told us they plan to reach 2,000. Getting there doesn't mean starting over. We add capacity to the pieces that need it. New channels or FAST channels can be added the same way.
Four companies built the core of it, and each one does what it's best at:
It all runs on AWS, in two separate regions. If one has a problem, the other takes over automatically.
The streaming layer touches almost everything. Content enters through the router and is recorded by Uplynk. Editors trim it, mark ad breaks, update audio and captions in our native HLS editor. From there, it goes one of two ways. Streaming channels play out directly from Uplynk's channel scheduler. Anything going to live playout is exported for Grass Valley to pick up. So, the content moves through us more than through any other piece. We also put it into one consistent format, so every other system knows what it's getting. The other reason is that someone has to own the whole picture. As the integrator, Uplynk's job was to make four companies' products work as one system for this customer. That's the part I'm proudest of.
They moved a facility that was almost entirely hardware-based in a single building to the cloud. Operators can run channels from the new building, from home, or from a phone. If bad weather keeps people from getting in, the channels keep running. Engineers can pull up a feed and check its quality from anywhere. Latency remained at broadcast levels. Storage costs dropped because we stopped keeping huge, high-bitrate copies of everything.
The FCC is auctioning part of the C-band spectrum, and the auction must close by July 2027. If you're still sending feeds over C-band, you're likely weighing your options right now. This framework shows you don't have to choose just one replacement. Each site can receive its feed over whatever path is available. You can ask providers for only the feeds you need and move them over one at a time rather than all at once. Your operators retain the control and visibility they're used to. None of this is theory. It's running in production today, and we've already adapted it for a second deployment.
On Thursday, November 12, at 11am ET, I'll walk through how it works with partners from Zixi, Grass Valley, and BroadView. Bring your questions.
If you want the full technical detail now, you can download the framework.
Download the IP Convergence Framework →