Everyone’s talking about QoD. Here’s what it actually is, how it works, and why it’s turning into one of the more important conversations in Network APIs right now.
The problem QoD solves
Every connection to a mobile network today is, by default, “best effort.” The network does its best to carry your traffic, but nothing is guaranteed — not the bandwidth, not the priority over other traffic, not what happens when the network gets busy. Most of the time, that’s fine. Best-effort connectivity is what the internet has run on for decades.
But some applications can’t run on “probably.” A live broadcast can’t afford to lose bandwidth halfway through a match. A remote-controlled drone can’t afford a dropped connection mid-flight. A payment terminal can’t afford a timeout at the till.
For use cases like these, “best effort” isn’t a technical limitation you work around, it’s a dealbreaker. Quality on Demand exists to close that gap.
What Quality on Demand actually is
Quality on Demand (QoD) is a Network API that lets an application or a business ask the mobile network for a specific level of performance, for a defined period of time, instead of simply relying on best-effort connectivity.
In practice, that means an app can ask the network for things like:
- Better performance for a particular session — for example, a live video feed
- Priority over other traffic when the network gets busy
- A defined quality level when the application actually needs it
Crucially, QoD isn’t a new kind of network. It’s a way of asking more from the network that’s already there — through a standardised API call, not a custom integration or a special SIM.
How it works, in plain terms
QoD is standardised through CAMARA, an open-source project hosted by the Linux Foundation and working closely with GSMA Open Gateway to create common Network APIs that can work across operators. At a basic level, the flow looks like this: an application calls the QoD API and says what it needs — for which device or session, what level of quality, and for how long. The network either accepts the request or doesn’t. If it does, that session gets the requested treatment for the agreed period.
That’s the same standardisation idea behind other Network APIs you may have come across (SIM Swap, Number Verification, Device Location) just applied to network performance instead of identity or location.
A concrete example
Broadcast is one of the clearest examples of QoD in action right now.
Live production has increasingly moved onto public 4G and 5G for contribution and outside-broadcast links — but a broadcaster covering a live sports match doesn’t want to simply hope the network holds up for those two hours. With QoD, they can ask the network for the performance they need for that particular production, rather than relying entirely on best effort.
The same logic applies well beyond broadcast: cloud gaming sessions that need consistently low latency, remote-controlled vehicles and drones that can’t tolerate a dropped link, or payment terminals that need a reliable connection at the moment of transaction.
Where QoD is today — and what’s still missing
Here’s the part that doesn’t always make it into the pitch: making the QoD API available is only the first step.
Turning that API into something a CSP can confidently sell as a product — and an enterprise customer can confidently depend on — is a different problem. In practice, enterprises may also need to see what the network quality looks like before or during a session, know whether the promised service is actually being delivered, recover automatically if something goes wrong, or book connectivity ahead of a scheduled event.
In other words, the API being available and QoD becoming a trustworthy, sellable product are two different milestones. And much of the opportunity now lies in closing that gap.
Why this matters for CSPs
For a CSP, QoD represents a genuine opportunity to monetise something that’s traditionally been bundled into connectivity: network performance itself. Enterprises in broadcast, gaming, mobility and other sectors already place real value on reliable, predictable connectivity. QoD gives CSPs a way to expose that capability directly to applications and businesses through Network APIs.
But getting from “the API exists” to a product a CSP can sell reliably is the real work, and it’s exactly what we focus on. That’s the step that turns QoD from a technical capability into something customers will actually pay for.
___
SliceFinity is the platform that turns Network APIs into revenue — exposing, orchestrating and productising network capabilities into enterprise-ready services.
About the author
