Network slicing is the key feature that validates the 5G Standalone core. However, if deployed on congested radio, it could disrupt the public internet. India’s telecom regulator has addressed this issue in draft legislation. This is an appropriate time to revisit the fundamentals: what a slice is at the protocol level, how 5G enforces quality of service within and across slices, where the design encounters its physical limit at the shared cell, and why this limit is now a compliance issue rather than solely an engineering challenge.
This article is technical in nature. The regulatory discussion appears at the end, as understanding the underlying technology is essential before interpreting the rules.
What a network slice actually is
A network slice is a complete, logically isolated end-to-end network — radio, transport, and core — instantiated over shared physical infrastructure and tailored to a specific set of service requirements. The important words are end-to-end and logically isolated. A slice is not a RAN feature or a core feature; it is a coordinated behavior across the whole system, and it only exists in its full form on 5G Standalone (5G-SA), where the 5G Core (5GC) is present, and the network is no longer anchored to a 4G EPC.
In 3GPP terms, a slice is identified by an S-NSSAI — Single Network Slice Selection Assistance Information. Each S-NSSAI carries two fields:
- SST (Slice/Service Type) — an 8-bit value describing the kind of slice. 3GPP standardizes a handful: SST 1 for eMBB, SST 2 for URLLC, SST 3 for massive IoT (mMTC), SST 4 for V2X, SST 5 for high-performance machine-type communications. Operators can also define private SST values.
- SD (Slice Differentiator) — an optional 24-bit field that distinguishes multiple slices of the same type. Two enterprises can each buy an eMBB slice (SST 1) and be separated by SD.
A collection of S-NSSAIs is an NSSAI, and the standard defines several flavors the device and network negotiate: the Configured NSSAI provisioned on the device, the Requested NSSAI the UE asks for, the Subscribed NSSAI held in the UDM, and the Allowed NSSAI the network ultimately grants. Slice selection is arbitrated by a dedicated core function, the NSSF (Network Slice Selection Function), which maps a requested slice to a Network Slice Instance (NSI) and to an appropriate AMF. Downstream, each slice can have its own SMF and UPF (session management and user-plane forwarding), while some control-plane functions like the AMF may be shared. This is the architectural point that matters: the core can be genuinely partitioned per slice, with dedicated user-plane processing.
Why one network cannot serve every service the same way
Slicing exists because 5G was designed around three usage scenarios with mutually incompatible demands:
- eMBB (Enhanced Mobile Broadband) — high throughput, dense user populations, high mobility. This is the smartphone experience and fixed wireless access. It wants capacity.
- URLLC (Ultra-Reliable Low-Latency Communications) — mission-critical control: industrial automation, remote surgery, smart-grid protection, transport safety. It wants deterministic latency and reliability, and it will trade throughput to get them.
- mMTC (massive Machine-Type Communications) — vast numbers of low-power sensors sending small, non-time-critical payloads. It wants connection density and battery life, not speed.
A single flat network cannot be optimized for all three scenarios at once. The radio and scheduling policies required for URLLC are inefficient for eMBB, and mMTC optimizations do not benefit the others. Previous generations required use cases to adapt to the network. Slicing reverses this: the network adapts to the use case. This shift is the core commercial value of slicing, enabled by 5G’s more granular QoS model.
How 5G enforces QoS: the flow-level machinery
To understand slicing QoS, you have to understand the object 5G actually polices: the QoS Flow. It is the finest granularity of QoS differentiation in a PDU session, identified by a QFI (QoS Flow Identifier). Every packet is classified into a QoS Flow, and every QoS Flow is bound to a 5QI (5G QoS Identifier).
The 5QI is a pointer into a table of QoS characteristics standardized in 3GPP TS 23.501. Each standardised 5QI defines:
- Resource type — GBR (Guaranteed Bit Rate), Non-GBR, or Delay-critical GBR.
- Priority level — used by the scheduler to arbitrate between flows.
- Packet Delay Budget (PDB) — the target upper bound on latency.
- Packet Error Rate (PER) — the tolerable loss.
- Averaging window and Maximum Data Burst Volume for the GBR classes.
So 5QI 1 is conversational voice (GBR, tight delay); 5QI 9 is the workhorse non-GBR value typically used for the default internet bearer; the 5QI 8x range covers delay-critical GBR for automation and V2X. This table is the vocabulary in which “quality” is expressed across the whole system.
Sitting alongside the 5QI is ARP — Allocation and Retention Priority — which is not about scheduling packets but about admission and survival. ARP carries a priority level plus a pre-emption capability and pre-emption vulnerability. When a cell is full, ARP decides which new flows get admitted and, critically, which existing flows get dropped to make room. ARP is the mechanism that determines who loses under contention.
In the RAN, QoS Flows are mapped to Data Radio Bearers (DRBs), and the gNB scheduler uses 5QI priority, GBR guarantees, and ARP to allocate radio resources for each transmission. This leads to the physical layer, where slicing ambitions are constrained by limited spectrum.
Where slicing meets its limit: the Physical Resource Block
Everything above is logical. The Physical Resource Block (PRB) is not. A PRB is 12 consecutive subcarriers in frequency across one slot in time — the fundamental unit the scheduler allocates to user equipment in an OFDMA cell. A cell has a fixed pool of PRBs determined by its channel bandwidth and numerology, and that pool is finite, shared, and the same pool every slice on that cell must draw from.
This is the central issue. Core slicing can be partitioned with dedicated UPFs and isolated SMFs, and transport can be separated using hard pipes. However, at the air interface, all slices on a cell compete for the same PRBs. RAN slicing manages this through radio resource management policies: hard policies reserve dedicated PRB sets per slice, which are guaranteed but inefficient when idle; soft policies share PRBs with slice-aware prioritization, which is efficient but depends on scheduler performance under load. Ultimately, a premium slice’s guarantee is valid only if sufficient PRBs are available during peak demand.
PRB utilization, defined as the fraction of a cell’s PRB pool that is scheduled, is the most reliable indicator of whether slicing is safe on a given cell. When PRB utilization nears saturation during peak hours, the scheduler must prioritize, and ARP and 5QI priority will pre-empt lower-priority traffic. The default, non-GBR, 5QI-9 internet slice used by most subscribers is most at risk of being deprioritized. This outcome is not hypothetical; it is the expected result of running a prioritized premium slice on a congested cell without sufficient capacity. Net-neutrality frameworks were designed to prevent this scenario.
The measurement layer: counting congestion the network can see
3GPP anticipated that slices would need to be measured, not just configured. TS 28.552 (“Management and orchestration; 5G performance measurements”) defines the performance counters, and TS 28.554 the derived KPIs, including PRB usage measurements that can be resolved per S-NSSAI. In principle, an operator can report how loaded each cell is, and how much of that load each slice is responsible for.
The busy-hour framing matters here. Congestion Busy-hour measurement is critical. Congestion occurs during peak hours, not as a daily average, and each cell has its own peak period. For example, office district cells saturate during working hours, while those on major roads peak during commutes. Measuring PRB utilization during each cell’s busy hour, defined as the hour with maximum combined uplink and downlink data, is the only way to identify when slicing may impact the internet slice. Daily averages obscure these critical events.o not close: network-side PM counters are self-reported by the operator’s own OSS. They describe what the network believes it delivered. They are not the same as what a device at the edge of a cell, on a specific slice, in the busy hour, actually experienced. That distinction — network-reported performance versus independently measured experience — is the pivot on which slicing accountability now turns.
From engineering to enforcement: how a regulator translated this
On 5 August 2026, India’s Telecom Regulatory Authority (TRAI) published draft amendments to its 2024 Quality of Service regulations that map this technical reality onto enforceable rules. What is notable — and technically literate — is what TRAI chose not to do. It did not attempt to license slice designs, cap the number of slices, or pre-approve use cases. It regulated the one variable that actually determines whether slicing harms the public user: busy-hour radio congestion.
The core of the framework is a new QoS parameter: the proportion of 5G cells whose daily PRB utilization exceeds 80% during the cell busy hour, with a benchmark of no more than 1% of cell-days. The measurement explicitly follows the 3GPP/TEC-adopted PRB definition, includes carrier-aggregation cells, and requires per-slice PRB reporting for granularity. Around that metric sits a hard remediation ladder: breach 80% on five days in a month and the operator must augment capacity; fail to clear it after a month, and the cell must be removed from network slicing — with the same cells barred from breaching for more than two consecutive months. Congestion is not something an operator can pay a penalty to keep; the slice comes off the cell.
Three further provisions translate the flow-level machinery directly into rules:
- A 21-day pre-launch capacity gate. Before launching any new slice, an operator must file proposed and existing slice parameters and demonstrate sufficient cell capacity, plus run a forward-looking quarterly capacity assessment two quarters ahead covering per-cell busy-hour load, backhaul, projected growth, declared data rates, and latency requirements.
- Each eMBB slice is a separate tariff offering, with speed compliance ensured per slice. A tariff is deemed non-compliant if, for at least one technology, the 80th-percentile measured download or upload speed falls below the offered typical speed — and operators must now declare typical speeds per technology (4G vs 5G) rather than quoting a single lowest-technology figure while delivering many times that on 5G.
- 5QI/ARP parity for same-service slices. Different slices carrying the same service — for example, general internet — must use the same 3GPP 5QI value with equal ARP. This is the cleanest safeguard in the document: it neutralizes the obvious abuse of spinning up a “fast” internet slice and a throttled “basic” one, and it does so mechanically, at the QoS-identifier level, rather than relying on after-the-fact enforcement discretion.
The key technical point is that network slicing is fundamentally a QoS innovation, and its success depends entirely on radio capacity. The 5GC provides logical isolation, the 5QI/QFI/ARP stack offers detailed quality definitions, and TS 28.552 supplies the necessary counters. However, every slice on a cell still competes for the same finite PRBs, and any guarantee made to one slice relies on a shared resource with unpredictable peak demand.
For operators, slice monetization becomes a capacity commitment. Selling any premium, low-latency, or high-uplink slice requires maintaining sufficient busy-hour headroom on the relevant cells. This represents a capital expenditure obligation tied to each SLA, rather than a purely software-based margin.
For the industry’s measurement layer, this represents a fundamental change. When each slice is a separately compliant tariff with independently verifiable speed floors, “advertised versus delivered” becomes a matter of evidence rather than marketing. The key question shifts from overall 5G network speed to whether a specific slice meets its declared performance at the 80th percentile during the busy hour, for each technology and area. This creates a per-slice, per-tariff, per-technology attribution challenge. Network-reported counters alone cannot credibly answer this, as the reporting entity is also the subject of measurement. Independent, device-side experience measurement becomes essential for verifying compliance.
Slicing has always been the measure of whether 5G-SA fulfills its promise. The true test lies not in the core, where the architecture is robust, but at the air interface, where resources are limited. Both engineering and regulatory efforts are now focused on this critical point.