5G Slicing · Solex Network Solutions

# A Game Changer For Telecom In May 2026, Airtel started selling a faster lane on its own network. Jio, which had ten slices running in production nine months earlier, had already stopped short of selling one. By August, TRAI had opened a consultation that could decide whether either of them is allowed to.

That is network slicing arriving in India — not as a lab demo, but as a tariff plan, a rival's objection and a regulatory paper, all inside ninety days.

This article covers what a slice actually is at the protocol level, why 5G needed the concept when 4G already had QoS, how the identifiers and signalling really work, what Airtel and Jio have each built, and why the answer to "why postpaid and not prepaid" lives in a subscription database rather than in the radio.

The problem slicing solves

A mobile network is one physical asset serving demands that actively contradict each other.

A person streaming a film wants sustained throughput and does not care about a 60 ms delay. A remote-controlled crane wants a 10 ms budget it can rely on and barely any throughput at all. A million electricity meters want almost nothing, once a day, but there are a million of them and each registration costs signalling. A broadcaster uplinking from a stadium wants guaranteed uplink at the exact moment fifty thousand phones around them are also uploading.

Build one network tuned for the film and the crane misses its deadline. Tune it for the crane and you have thrown away capacity the film would have used. Historically operators resolved this by not resolving it: they built for the average, sold best-effort, and told the crane operator to buy a private network.

Slicing is the proposal that one physical network can present itself as several logically independent networks, each with its own performance profile, its own management lifecycle, and its own service-level agreement.

Why 4G could not already do this

This is the objection every experienced engineer raises, and it is a good one. LTE already had QCI values, dedicated bearers, ARP, and separate APNs. You could absolutely give VoLTE a guaranteed bitrate bearer and leave web traffic on best-effort. So what is new?

The honest answer: slicing is not a QoS mechanism. QoS still exists, unchanged in principle, inside a slice. A PDU session on a slice still carries QoS flows, each with a 5QI and a QFI. If you have read about QFI and 5QI, none of that is replaced.

What slicing adds is three things QoS never provided:

Isolation of resources, not just prioritisation of packets. A QCI tells the scheduler which packet to send first. A slice can reserve a percentage of physical resource blocks that other slices cannot touch even when the reserved ones sit idle.

Independent lifecycle. A slice has its own network functions — or at least its own logically separated instances — that can be scaled, upgraded, and failed independently. You can restart the IoT slice's SMF without touching the consumer slice's. On LTE, an EPC upgrade was an EPC upgrade.

A commercial and management boundary. A slice has an owner, a template, an SLA, and its own performance reports. It is a product with a service catalogue entry, not a configuration value buried in a policy table.

Put crudely: QoS decides which packet goes first. Slicing decides whose network it is.

What a slice actually is

A network slice is a logical end-to-end network composed of three slice subnets that most discussions forget to mention separately:

RAN slice subnet — scheduler configuration, resource block allocation policy, admission thresholds at the gNB
Core slice subnet — the set of network functions serving that slice, and the rules for selecting them
Transport slice subnet — the VLANs, VPNs or segment-routing policies carrying that slice's traffic between the radio site and the data centre

Every one of the three must cooperate or the slice is theatre. This is the single most common failure in slicing projects: a beautifully isolated core, a correctly configured RAN, and a shared 10G ring in the middle that both slices contend for. The SLA is then decided by the domain nobody put in the diagram.

3GPP defines the management side in TS 28.530 (concepts), TS 28.531 (provisioning) and TS 28.541 (the resource model, where the SLA parameters actually live). The GSMA layers a commercial vocabulary on top with the Generic Slice Template in NG.116 — a standard list of attributes such as guaranteed downlink throughput, latency, availability, and maximum supported UEs, so a slice can be ordered from a catalogue instead of negotiated bespoke.

The identifier chain

This is where slicing gets concrete, and where most trace analysis goes wrong.

A slice is identified by an S-NSSAI — Single Network Slice Selection Assistance Information. It has two parts:

S-NSSAI = SST (8 bits) + SD (24 bits, optional)

SST is the Slice/Service Type — what kind of slice this is. The standardised values are deliberately few:

1 — eMBB, enhanced Mobile Broadband
2 — URLLC, ultra-reliable low-latency
3 — MIoT, massive IoT
4 — V2X
5 — HMTC, high-performance machine-type communications

SD is the Slice Differentiator, and it is what makes slicing commercially useful. SST alone gives you five slices worldwide. SST plus SD lets an operator run 1/000001 for consumer broadband, 1/000002 for a premium consumer tier, and 1/000101 for a specific enterprise customer's broadband slice — all of them eMBB, all of them distinct networks.

Note carefully: a premium consumer slice and an ordinary consumer slice are usually the same SST. The differentiation is entirely in the SD and in the policy attached to it. Anyone expecting a "priority" slice to show up as an exotic slice type in a trace will be disappointed.

The five NSSAIs, and why there are five

An NSSAI is just a list of S-NSSAIs. There are several kinds and they are constantly confused with one another:

Configured NSSAI — provisioned on the UE for a given PLMN. What the device knows about before it asks.

Requested NSSAI — what the UE puts in its Registration Request. Its opening bid.

Subscribed S-NSSAIs — what the subscription record in the UDM says this customer is entitled to. One or more may be flagged as default, meaning "use this if the UE asks for nothing useful." This is the field that decides whether a customer is on the premium slice. Remember it — everything commercial comes back to it.

Allowed NSSAI — what the AMF actually grants, per access type. Capped at eight S-NSSAIs per registration. A UE cannot be on fifty slices at once.

Rejected NSSAI — what was refused, with a cause distinguishing "not available in this PLMN" from "not available in this registration area", which matters enormously when you are debugging a slice that works in one city and not another.

There is also a Pending NSSAI, used when a slice requires its own authentication before it can be granted.

How a UE lands on a slice

The sequence, in the order you will see it:

The UE includes the Requested NSSAI in RRC signalling as it connects, not just in NAS. This is deliberate: the gNB needs it before it can pick an AMF, because different slices may be served by different AMF sets.
The gNB performs AMF selection using that NSSAI.
The AMF retrieves the Subscribed S-NSSAIs from the UDM.
If the decision is non-trivial, the AMF asks the NSSF — the Network Slice Selection Function — which returns the Allowed NSSAI, the AMF set that should serve it, and where to find the right NRF.
The AMF returns the Allowed NSSAI in the Registration Accept. The UE now knows which slices it may use.
Later, for actual traffic, the UE sends a PDU Session Establishment Request carrying one S-NSSAI and one DNN. A PDU session belongs to exactly one slice. Traffic to two slices means two PDU sessions.
The SMF and UPF are selected by NRF discovery scoped by that S-NSSAI, which is how a slice gets its own user plane.
The S-NSSAI is carried to the gNB in the NGAP PDU Session Resource Setup Request, so the RAN knows which slice's resource policy to apply to that session's radio bearers.

URSP: how an app lands on a slice without the user knowing

Steps 1 to 8 explain how a device uses a slice. They do not explain how your banking app ends up on the enterprise slice while your video app stays on the consumer one.

That is URSP — UE Route Selection Policy — pushed to the device by the PCF over NAS. A URSP rule is a pair: a traffic descriptor (application identifier, IP triple, domain name, DNN, connection capability) and a route selection descriptor telling the UE which S-NSSAI, DNN and SSC mode to use for traffic matching it.

URSP is the difference between slicing as an infrastructure feature and slicing as a product. Without it, a slice applies to a whole device. With it, a slice applies to a flow — and the operator can change that policy over the air, per subscriber, without touching the network.

How a slice is actually enforced

Everything above is identifiers and selection. None of it makes anything faster. The enforcement is elsewhere, and it is worth being blunt about where.

In the core

Selection by S-NSSAI, and either separate NF instances per slice or shared NFs that are slice-aware. Full separation gives real fault isolation and real cost. Most operators run shared control plane functions with separated user plane — a dedicated UPF per major slice — because the UPF is where throughput and latency are actually won or lost, and where an enterprise's traffic can be kept physically off the consumer path.

Two functions matter more than their obscurity suggests:

NSACF — the Network Slice Admission Control Function, added in Release 17. It enforces the maximum number of UEs and the maximum number of PDU sessions on a slice. This is not a minor feature. An SLA promising a latency figure is unenforceable if an unbounded number of devices can join; NSACF is the mechanism that turns "we promise 20 ms" into something an operator can actually stand behind. It is also, inevitably, the mechanism that lets an operator keep a premium tier scarce.

NSSAAF — Network Slice-Specific Authentication and Authorisation. A slice can demand its own EAP-based authentication against the enterprise's AAA server, over and above normal 5G authentication. A factory can say: being a valid subscriber is not sufficient to enter my slice.

In the RAN

This is where slicing lives or dies, because the radio is the scarce resource. The core has spare CPU; the cell does not have spare spectrum.

The RAN resource model in TS 28.541 expresses a slice's entitlement as ratios of physical resource blocks:

Dedicated ratio — PRBs reserved for this slice, unusable by others even when idle
Minimum ratio — a floor this slice is guaranteed when it wants it, borrowable by others when it does not
Maximum ratio — a ceiling, so one slice cannot consume the cell

Those three options are three completely different products. Dedicated resources give a genuine hard guarantee and waste capacity by definition. A minimum ratio gives a soft guarantee that only bites under congestion and wastes nothing. For a consumer "priority" product on a national macro network, the minimum-ratio model is the only economically sane choice — you are buying a better position in the queue when the queue exists, not a private lane that sits empty at 3 a.m.

Release 18 added NSAG, the Network Slice AS Group, which lets slice awareness reach cell reselection and random access — so a device can prefer cells that actually support its slice, and get prioritised access when contending. Before that, a UE could camp happily on a cell that could not serve its slice at all.

In transport

Segment routing policies, VPNs, VLANs, or hard partitioning with FlexE. The IETF has been building a parallel vocabulary here, and this domain is where an otherwise correct slice quietly fails. If your RAN guarantees 30% of PRBs and your core has a dedicated UPF, but both slices share one congested backhaul link, you have built an expensive illusion.

India, for real

Now the part that is not textbook.

Jio built it first and did not sell it

In August 2025, Jio Platforms announced ten live 5G network slices running nationwide, covering enterprise, IoT, gaming, its JioAirFiber fixed-wireless service, and mission-critical communications. Notably, Jio runs its own in-house 5G standalone core and its own network slicing platform, rather than a vendor's — an unusual position globally, and one that gives it unusually direct control over slice provisioning.

Then it stopped. In April 2026, Jio's strategy head Anshuman Thakur explained the pause with a sentence worth quoting exactly:

We need to ensure that we are fully regulatory compliant, but these products are ready for the market.

Two blockers, both non-technical. First, no regulatory clarity on whether a paid priority tier survives India's net neutrality rules. Second, no evidence Indian consumers would pay for it — Jio's ARPU had grown 3.8% year-on-year to around ₹214 a month, and the question of whether a subscriber at that price point will add a premium tier is a real one.

Airtel sold it first

On 19–21 May 2026, Airtel launched Priority Postpaid, marketed around "Fastlane" technology — India's first commercial consumer slicing product, and one of the first anywhere aimed at ordinary consumers rather than enterprises or first responders.

The shape of the offer:

Plans from ₹449 + GST for an individual up to ₹1,749 + GST for a family of five, with OTT bundles increasing up the stack
Postpaid only. Prepaid customers cannot buy it; they must migrate
Automatically enabled for existing postpaid customers, with no activation step
Requires a 5G standalone-capable handset with current firmware — non-standalone devices cannot be sliced at all, because there is no 5G core in the NSA path to select a slice with
Both Nokia and Ericsson publicly confirmed their technology underpins it; Airtel had separately contracted Ericsson in February 2025 for 5G core, signalling controller, and 5G SA-enabled charging and policy, explicitly citing slicing-based monetisation

Airtel's own description is that during congestion, Priority subscribers receive preferential treatment. CEO Shashwat Sharma called it "a superior, more reliable, and dependable experience." Note what is not claimed: a peak speed, a latency figure, or an SLA. That is a carefully drafted promise, and the drafting tells you it is a minimum-ratio scheduling priority rather than a dedicated resource guarantee.

One detail from the first weeks is worth noting, because it is the architecture leaking through the marketing. Despite "automatic" enablement, users with recent standalone-capable flagships reported the Airtel app telling them the feature was not enabled. That is what a device-capability gate looks like from the outside: the slice is provisioned in the subscription, but the device must support the SA path and be recognised as doing so before anything happens. Airtel's own investor materials call the offering "Postpaid FastLane" rather than Priority Postpaid, which suggests the internal product and the consumer brand were not settled at the same time.

Airtel has not published its slice configuration, so the specific SD values and RRM ratios are not public. What is not inference is the architecture: postpaid-only differentiation on a 5G SA network, gated on SA handset support, can only be implemented through subscription-driven slice selection.

Why postpaid and not prepaid

This is the question the launch actually raises, and the answer is more interesting than "postpaid customers pay more."

The radio has no idea what prepaid means. A gNB scheduler knows S-NSSAIs, QoS flows, and resource ratios. Nothing in the RAN carries a billing model. Nor does the AMF, the SMF, or the UPF.

The gate is in the Subscribed S-NSSAIs in the UDM. When Airtel moves a customer onto Priority Postpaid, the material change is that their subscription record gains the premium S-NSSAI, probably marked as default. Everything downstream follows automatically: the AMF reads it at registration, puts it in the Allowed NSSAI, the UE establishes its PDU session on it, NGAP carries the S-NSSAI to the gNB, and the gNB applies that slice's RRM policy to the radio bearers.

Which explains the "automatically enabled, no activation needed" detail in the marketing. There is nothing for the customer to do because the change happens in a database in the core, and the device simply receives a different Allowed NSSAI the next time it registers.

So technically prepaid slicing is trivial — it is the same provisioning write. The reasons it is not offered are commercial, and one of them is genuinely technical in disguise:

A fast lane only works if it is a minority. With a minimum-ratio RRM policy, the premium slice's advantage is exactly the gap between its guaranteed floor and everyone else's share of the remainder.

Put Airtel's own numbers against that. For the quarter ended June 2026 it reported roughly 30 million postpaid customers — a single-digit percentage of its Indian mobile base — against a blended ARPU of ₹264. Reserving a meaningful PRB floor for that group costs the other ninety-odd percent very little, because the group is small. Extend the same floor to the majority and the guarantee stops meaning anything, since the resource being divided has not grown by one hertz.

Priority is a positional good. Sell it to everyone and you have sold nothing. That is not a cynical observation about telecom marketing; it is a property of a scheduler dividing a fixed number of resource blocks.

Then the ordinary commercial reasons: prepaid ARPU around ₹200 makes a ₹449 add-on larger than the base plan; postpaid is a contract relationship with KYC and credit history, which is a far more comfortable basis for anything resembling a service guarantee; and gating a desirable feature behind postpaid is itself a migration lever in a market where Airtel's leadership has said publicly that "the price architecture in this country is broken."

The regulator arrives

Jio's caution turned out to be well judged.

TRAI opened a consultation on 5 August 2026 proposing to bring network slicing formally inside the Quality of Service regulations, with comments due 26 August 2026 and counter-comments by 7 September 2026. The substance is unusually specific for a document at this stage:

Operators must file slice details with TRAI around a 21-day window and demonstrate sufficient capacity — press summaries differ on whether the clock runs before launch or from slice creation, so read the paper rather than the coverage
Fewer than 1% of tested 5G cells should show daily PRB utilisation above 80%
If a cell exceeds 80% PRB utilisation for five days in a month, the operator must add capacity — or remove that cell from slicing
Each eMBB slice is treated as a separate tariff offering with its own independent QoS compliance

Read the second and third points again, because they are the cleverest part. TRAI has not tried to ban fast lanes or define fairness philosophically. It has picked the same unit the RAN scheduler uses — the physical resource block — and said: you may sell priority, but not out of capacity you do not have. If the cell is genuinely congested, the premium slice comes off that cell rather than the ordinary users absorbing the cost.

That is a regulator writing rules in the network's own vocabulary, and it converts a political argument into a measurable one.

The strongest objection to it

The 80% rule is elegant, and it may still be the wrong instrument. The sharpest critique has come from Parag Kar, formerly Qualcomm's VP for government affairs in India, and it deserves stating properly because it is not the usual net-neutrality complaint.

His argument: 80% is a congestion alarm, not a fairness test. PRB utilisation measures how much of the cell is in use. It says nothing about how that use was divided between premium and ordinary users. Worse, the metric is gameable in a direction that hurts exactly the people it is meant to protect. Suppose ordinary users demand 70 units of capacity and premium users 20, totalling 90% — over the threshold. An operator can rate-limit the ordinary traffic down to 55 units, bringing measured utilisation to 75% and back into compliance, while the premium slice is untouched and the suppressed ordinary demand simply goes unserved. The cell now reports as healthy. The regulation has been satisfied by throttling the very users it was written for.

The fix implied by that critique is to measure per-slice PRB share and per-slice user experience rather than aggregate cell utilisation — harder to collect, much harder to game. Whether TRAI moves that way is one of the more consequential open questions in the consultation.

The positions are also less tidy than the headlines suggest. Jio wrote to the DoT describing slicing-based deployment as "a legitimate exercise of 5G network capabilities, provided they comply with applicable provisions of the Unified Licence and TRAI regulations" — support with a conditional attached, from a company defending technology it has already built while slowing down the rival who shipped first. Jio and Vodafone Idea have both previously argued that preferential treatment could discriminate against other subscribers. Airtel's position is that differentiated capability is essential for advanced applications.

Everyone is arguing their book. That does not make any of them wrong.

The use cases that actually pay

Strip away the slide decks and commercial slicing has clustered into a short list:

Public safety. T-Mobile's T-Priority in the US is the clearest example — a slice for first responders, where the value is that it works when the cell is saturated by everyone else, which is precisely when responders need it.

Live event and broadcast contribution. Guaranteed uplink from a venue where the ordinary network has collapsed under fifty thousand phones. Short-duration, high-value, and it sells because the alternative is a satellite truck.

Enterprise and industrial. Factory automation, robotics, logistics. Often the honest comparison is not to a slice but to a private network, and the slice wins on cost while losing on control.

Fixed wireless access. Underrated and quietly the most economically real. FWA and mobile traffic have incompatible profiles, and separating them by slice lets an operator sell home broadband without the two products degrading each other. Jio putting JioAirFiber on its own slice is exactly this.

Consumer premium tiers. The newest, the least proven, and the one Airtel has now bet on publicly.

Massive IoT. A slice tuned for signalling efficiency rather than throughput, keeping millions of meters from polluting the consumer control plane.

The future

Some of this is reasonably safe to predict and some is not, and it is worth separating them.

Reasonably safe. Slicing shifts from selling a faster pipe to selling a guaranteed one. That requires closed-loop assurance — continuous measurement against the SLA with automatic remediation — and it requires NSACF-style admission control to be used seriously rather than left at defaults. The regulatory direction reinforces this: once a slice is a tariff offering with its own QoS compliance, "we prioritised you a bit" stops being a sufficient description of what was sold.

Reasonably safe. The commercial vehicle will increasingly be an API rather than a plan. GSMA Open Gateway and CAMARA expose a Quality-on-Demand interface where an application requests a QoS profile for a specific session — a surgeon's video feed, a drone's control link, a payment burst — and the network provisions it for minutes rather than months. This is a better fit for how software is actually built than asking a developer to negotiate a slice contract, and it lets an operator monetise the same underlying slices many times over. If consumer slicing turns out to be a footnote, this is likely where the money actually was.

Likely. Slice management becomes AI-operated before it becomes AI-designed. Roughly two in three operators report deploying or testing agentic AI in their core networks, and slice assurance — thousands of counters, continuous SLA arithmetic, remediation that must happen faster than a human ticket — is an obvious early target.

Uncertain. Whether consumers will pay. Airtel is running the experiment in public, at scale, in the most price-sensitive large market on earth. Whatever happens will be studied by every operator that has been debating this internally for five years. If ₹449 works in India, it works anywhere.

Uncertain. Whether regulators globally converge on TRAI's approach. The PRB-utilisation test is the most concrete regulatory instrument anyone has proposed for slicing. It could become a template — or it could turn out to be unenforceable at scale and quietly disappear.

Further out. In 6G discussions, slicing tends to dissolve into a more general idea: not a small number of pre-provisioned logical networks, but per-application, per-session negotiated service contracts, with the network composing resources on demand. Slicing as we describe it today may end up looking like a transitional design — the step where the industry learned that logical separation is possible, before it learned to do it continuously.

Where to see it in a trace

For anyone with access to a live SA network, the identifier chain is straightforward to follow:

Registration Request — the Requested NSSAI, both in the RRC container and in NAS. Check whether they match; a mismatch is a real and confusing failure mode.

Registration Accept — the Allowed NSSAI. Compare it to what was requested. Anything missing should appear in the Rejected NSSAI with a cause, and that cause distinguishes a PLMN-wide problem from a registration-area one.

PDU Session Establishment Request — the single S-NSSAI and DNN pair. One session, one slice.

NGAP PDU Session Resource Setup Request — the S-NSSAI as the RAN receives it. If the slice is correct in NAS but absent here, your problem is between AMF and gNB, not in the device.

Three habits worth building:

Check the SD, not just the SST. Premium and ordinary consumer slices are usually both SST 1. The SST tells you almost nothing.

Count the Allowed NSSAI. Eight is the ceiling. A device that mysteriously cannot reach a ninth slice is not broken.

Check PRB utilisation per slice, not just per cell. This is now the number the regulator cares about, and it is the only measurement that tells you whether a guarantee is real or decorative.

We teach 5G core architecture end to end — including slice selection, URSP, and reading real registration traces — in our 5G Core (SA) course.