5G Slicing Demands New OSS Tricks
The operational gap is the reason slicing revenue hasn’t materialised.
The industry has spent years explaining why network slicing will produce new revenue, and comparatively little time on what has to be true operationally before an operator can sell one against an SLA. That gap is not a marketing problem. It is the reason the revenue hasn’t arrived.
What actually breaks when a service lasts thirty minutes?
Almost every assumption your OSS was built on.
Service catalogues were designed for services that persist. A circuit is provisioned, it exists, it is billed monthly, and eventually it is decommissioned — a lifecycle measured in years, with a human somewhere in each transition. A slice spun up for a stadium concert, an eight-hour enterprise event, or a single drone mission has no place to live in that model. It needs to exist, carry an SLA, generate a billing event, and close itself, all within the window a traditional provisioning workflow would still be waiting for approval.
The same applies downstream. Assurance systems assume a service you can look up. Billing assumes a cycle. Inventory assumes a topology that was accurate when someone last ran discovery. Ephemeral services break all three at once.
Why does topology have to be live?
Because in a slice-bound network it stops being a diagram and becomes a state.
Most OSS topology views are static: accurate as of the last inventory run, useful for planning, inert during an event. That is tolerable when the network changes on a change-control calendar. It is useless when slices anchor to new edge nodes, mobile assets re-associate with different antennas, and the shape of the service changes minute to minute.
If the topology view does not update as the network moves, nothing built on top of it can be slice-aware — because every impact assessment is computed against a picture that is already wrong.
What does correlation mean when the network reshapes itself?
The same thing it always meant, against a target that will not hold still.
A switch port flaps and a traditional OSS produces fifty independent alarms — every camera that lost connectivity, every endpoint that lost backhaul, every interface that timed out. What an operator needs instead is one alert carrying impact context: which endpoints are affected, which slices are degraded, which missions are at risk, and what that means for the SLA attached to each.
That requires correlation resolved against live topology rather than against a rules file, and it is the same architecture that collapses forty-nine ONT alarms into one service event on a fibre network. The platform page covers how.
How do you tell whether a platform is actually slice-aware?
Three tests, and they work on any vendor’s demo including ours.
Does the topology view update while you watch? Ask them to move something — launch the mission, shift the asset — and watch the map. If connections do not change as the network changes, the platform is rendering a diagram, not tracking a state.
Can the service catalogue hold a thirty-minute service? Ask them to launch one, then look at the catalogue. There should be a new entry — name, start time, SLA, billing event — that did not exist before, and it should close itself when the mission ends. If the catalogue cannot handle an ephemeral lifecycle natively, slicing cannot be sold against an SLA.
Does correlation actually consolidate? Ask them to trigger a port flap. If the screen still shows fifty alarms, you are looking at legacy correlation with a slice-shaped label on it.
If you only have ten minutes at a booth, collapse all three into one question: show me an alarm storm and tell me which single mission was impacted. A platform that answers that in real time can operate ephemeral services. One that cannot, cannot.
Does this matter if you don’t sell slicing?
The drone-and-port scenario is a vivid way to demonstrate the architecture, but the architecture is general. The same operational model handles a stadium slice with SLA-backed performance, private 5G for an eight-hour enterprise event, connected-vehicle handoffs across cell boundaries, broadcast slices from venues, and emergency response slices during a disaster.
If any of those are on your roadmap — and for an operator with 5G investment to defend, at least one usually is — the operational architecture is the part that has to exist first.
What has actually been demonstrated?
A multi-vendor Catalyst project at TM Forum DTW Ignite 2026: three sites, 113 devices across cameras, switches, antennas, drones and edge compute, six equipment vendors, with topology reshaping continuously and the full ephemeral service lifecycle — provisioning through to revenue recognition — completing in under sixty seconds, demonstrated live.
Being straight about what that is: a proof of concept, not a production deployment. What it proves is that the architecture works — that the data pipeline, correlation engine, service modelling, and visualisation layer do what they claim when connected end to end. It is not theoretical slideware, and it is also not a reference customer. Both things are true.
Get the white paper
The full paper adds the technical depth behind each of the above — the service modelling required for ephemeral lifecycles, the correlation architecture, and what the order-to-revenue path looks like when it has to complete in under a minute.
About Rapax
Rapax is an AI-native network service assurance and automation platform for telecom operators, bringing fault, performance, topology, and service management into one system worked by six AI agents. It deploys on Kubernetes in cloud or on-premise environments, including local model inference. Rapax is a business unit of Citus Technologies, LLC.
Shawn Ennis is the Founder & CEO of Citus Technologies and the founder of Rapax. He spent 25 years in telecom operations, holds 12 patents in network management and service assurance, and previously founded Assure1 — acquired by Oracle in 2021.
Not ready to download? Book fifteen minutes — no prep, no deck. cal.com/shawn-ennis · sales@rapax.app · More white papers