A network slice with guaranteed QoS is a capability, not a product. See how context-aware charging turns slice and QoS data into sellable offers.
A network capability is not yet a commercial product
When an operator brings a 5G standalone core online and stands up its first network slices, the engineering milestone is real: the network can now guarantee a performance profile to a specific set of users, isolated from everyone else’s traffic.
What it cannot do, on its own, is sell that.
Between the capability and the product sits a layer of commercial machinery. Someone has to define who may buy the slice, what exactly is included, how the price is structured, how delivery is measured, and how it all lands on an invoice the enterprise customer recognizes.
Charging is the point where network context becomes a price — and, in many organizations, it is also the point where slice offers slow down.
This article walks the path from slice to revenue: what the network actually sends to the charging system, why that data alone is not yet an offer, where traditional rating implementations create friction, and — just as importantly — what charging does not solve, so the rest of the delivery chain gets planned rather than discovered.
What the 5G core sends to charging
5G charging is built on the Converged Charging System defined by 3GPP in Releases 15 and 16. As subscribers consume services, the Session Management Function (SMF) sends charging data requests to the Charging Function (CHF) over the Nchf service-based interface.
Those requests are rich. Alongside usage counts and subscriber identifiers, the standardized charging information includes the S-NSSAI — the identifier that names the network slice a session runs on (TS 32.255, with slice management charging covered in TS 28.201 and TS 28.202) — and QoS-related data describing how the traffic is being treated.
In other words, the raw ingredients of a slice-aware price arrive with every charging request. The standard has done its part. The interesting questions start on the receiving side.
S-NSSAI, QoS and enterprise context are not the same thing
It helps to keep three layers apart, because slice projects often blur them.
S-NSSAI
The S-NSSAI is the network’s name for a slice — a technical routing identity. It tells you which slice a session used, and nothing else.
QoS profile
The QoS profile describes how traffic is treated within that slice: guaranteed bit rates, latency targets, priority. Two sessions on the same slice can receive different QoS treatment.
Enterprise context
The enterprise context is the commercial meaning: which customer this is, under which contract, at which site, on which service tier, with how many authorized devices. None of that travels in the charging stream — it lives in the BSS, in the product catalog and the customer’s account.
A sellable offer needs all three joined together. “Premium uplink for customer X’s production site, up to 40 devices, at tier 2 pricing” is a statement that maps a technical identifier (the S-NSSAI), a performance treatment (the QoS profile) and a commercial construct (the contract) onto one another.
Building and maintaining that mapping is where many slice-monetization projects discover their real scope.
Why traditional rating implementations slow offer creation
Here is the common friction point, and it is a pattern across generations of charging technology rather than a flaw of any one product.
Most charging systems fix the set of attributes their rating logic can reference at design time. The slice identifier and QoS data may arrive in every request, but until they are modeled in as rateable inputs, no price can depend on them.
Making them rateable typically means a data-model extension, new rating templates, a regression cycle, and a slot in a release calendar. Historically this was a defensible trade-off — a fixed model keeps real-time performance predictable — but the consequence is that every new context-driven offer becomes an engineering project, and enterprise deals that should take weeks inherit a software-release timeline.
How flexible service fields and rate-plan mappings help
Tridens Monetization approaches this differently: the fields carried in a charging request are available to rating as a matter of configuration, not modeling.
Concretely, that means the S-NSSAI and QoS parameters arriving over the platform’s 5G HTTP/2 interface (with Diameter and RADIUS supported for earlier network generations) can be referenced directly in rating rules, alongside attributes held on the customer, account and subscription — including custom fields such as site, tenant or contract tier.
A product owner maps slice identifiers to catalog offers, attaches per-device pricing from the account’s registered device count, defines a QoS uplift as an orderable add-on, and adds session-duration or volume-based components where the deal needs them.
Each of these is a plan component in the product catalog, published without an engineering ticket.
The mapping layer is the quiet hero here. Once “S-NSSAI X on contract Y means offer Z” is expressed as configuration, the same construct is reused for the next slice, the next site and the next customer — which is what eventually turns slice monetization from a project into a catalog.
What charging can and cannot solve
An honest boundary makes the whole design more credible, so let’s draw it.
Charging determines the price, meters consumption in real time, enforces allowances, and produces the charges that reach the invoice.
What charging does not do is put the customer on the slice. Admission to a slice, and the QoS a session receives, are decided by subscription data, policy and orchestration — in 3GPP terms, the territory of functions like UDM, PCF and NSSF, together with the provisioning processes that configure them.
A complete enterprise offer therefore always spans entitlement, policy, provisioning, charging and the commercial contract.
Planning all five from the start avoids the awkward late discovery that the pricing works perfectly for a slice nobody has been granted access to.
Ready to get started?
Map slice, QoS, contract, and usage attributes into charging models your teams can configure.
Example: premium connectivity for live video production
This use case is not hypothetical. Deutsche Telekom already sells 5G Live Video Production: slicing-based connectivity for broadcasters and mobile journalists, available as a bookable option on top of a business tariff, with no setup cost or monthly fee for the option itself and a usage price of €50 net per SIM card for each started 15 minutes of a booked event.
It works with professional streaming backpacks — and, in its Mobile Journalism variant, with selected smartphones.
Read the offer from the rating side
Read from the rating side, that public price structure is a compact checklist of attribute questions. The charge multiplies per SIM in use — a live count of devices on the slice. It accrues per started 15-minute increment — time-based rating with an explicit rounding rule.
It applies only within a booked event window — a validity period the catalog has to model. And the option presupposes a specific base tariff — a compatibility rule between catalog items. Nothing on that list is exotic; the point is that each element must be expressible as configuration, or the offer inherits a release timeline.
The same building blocks extend naturally to richer deals. A three-day production might instead be priced as a per-registered-device daily rate with a data allowance and per-gigabyte overage, plus a QoS uplift the customer orders for broadcast windows.
In rating terms: the S-NSSAI in the charging stream attaches the premium tariff, the device count comes from the account’s subscriptions, the uplift prices flagged sessions at a higher tier, and usage accumulates against the allowance with overage rated in real time — no surprises after the event.
Provisioning and policy grant the devices access for the event window; charging prices what the network then delivers; the enterprise receives one consolidated, itemized invoice per production.
With the mapping in place, each of these variants is catalog configuration — which matters, because event-driven deals do not wait for release calendars.
From a custom integration to a reusable catalog offer
The first slice deal is often treated as bespoke. It doesn’t have to stay that way.
The same building blocks — slice-to-offer mapping, per-device components, time-boxed event windows, QoS tiers, allowances — reassemble into an industrial-campus product: a fixed site, a monthly per-site fee, per-device pricing and an SLA tier, sold from the same catalog with different values.
That is the practical test of the approach: the second offer should be a variant, not a second project.
The broader principle is that what you can sell tracks what your rating layer can reference. For enterprise 5G, that means network context — slice, QoS, session — mapped cleanly onto commercial terms.
If you’d like to see how slice- and QoS-aware rating would handle a deal on your own roadmap, we’d be glad to walk through it with you. Schedule a demo.
FAQ about context-aware charging
Does the 5G standard support charging per network slice?
Yes. The 3GPP Converged Charging System carries the S-NSSAI in the charging data sent from the SMF to the CHF, and dedicated specifications cover slice-related charging. The open question in a given deployment is whether the rating implementation lets prices reference those delivered values without a data-model project.
What is the difference between an S-NSSAI and an enterprise slice offer?
The S-NSSAI is a technical identifier — the network’s name for a slice. An enterprise offer is a commercial construct: a contract, a site, a device count, a price structure. Monetizing slices means mapping the first onto the second, and keeping that mapping maintainable as offers multiply.
Does charging give a customer access to a slice?
No. Slice admission and QoS treatment are governed by subscription data, policy and provisioning. Charging meters and prices what the network delivers, and enforces commercial limits such as allowances. A complete offer needs both sides planned together.
How does Tridens Monetization support slice-aware offers?
Fields carried in the charging request — including the slice identifier and QoS parameters over 5G HTTP/2, with Diameter and RADIUS also supported — can be referenced directly in rating rules and combined with customer, account and subscription attributes. Offer structures such as per-device pricing, QoS uplifts and allowances are configured in the product catalog, and converged charging and billing carry the results through to a single enterprise invoice.
