5G Network Slicing: The Complete Guide — Architecture, Deployment & Field Reality

Champions League final, 80,000 people in the stadium. Three slices active on the same physical network, invisible to each other. The URLLC slice carries real-time video feeds from public safety surveillance cameras at sub-15ms latency. The eMBB slice delivers multi-angle 4K streaming to spectators at 100 Mbps guaranteed per cell. The mMTC slice collects data from 12,000 structural pressure sensors embedded under the stands. Three virtual networks. One physical infrastructure. None of them knows the others exist.

That is the promise of 5G network slicing. And like many promises in telecom, it is technically feasible, architecturally elegant, and commercially almost nowhere in 2026.

This guide covers the complete slicing architecture, from S-NSSAI to 5QI, from NSSF to NSACF, from 3GPP theory to field deployment reality. No marketing. Specifications, limitations, and the actual state of play.

The airplane analogy: understanding slicing in 30 seconds

Network slicing works like a commercial flight. One physical aircraft (the network), but three classes of service with radically different SLAs.

First class (URLLC) guarantees a lie-flat seat, gourmet dining, and priority boarding. The SLA is contractual: if the service is not delivered, there is compensation. Business class (eMBB) offers a wide seat and a decent meal, but without the absolute guarantee. Economy (mMTC) packs the maximum number of passengers at the lowest cost per seat.

All share the same plane, the same crew, the same runway. But the resources allocated to each (space, food, staff) are isolated. The first-class passenger does not experience the economy boarding queue. The economy passenger cannot occupy a first-class seat, even if it is empty.

Slicing replicates this logic on a 5G SA network. Same physical infrastructure (gNB, transport, core), but dedicated radio resources, network functions, and QoS policies per slice.

Architecture: how a slice is identified, selected, and admitted

S-NSSAI: the slice identity card

Each slice is identified by an S-NSSAI (Single Network Slice Selection Assistance Information), defined in 3GPP TS 23.501. The S-NSSAI consists of two fields:

• SST (Slice/Service Type): an 8-bit value defining the service category. Three values are standardized by 3GPP: SST=1 (eMBB), SST=2 (URLLC), SST=3 (mMTC). SST=4 is reserved for V2X (Vehicle-to-Everything). Values 5 through 127 are reserved for future standardized use. Values 128 through 255 are available for operator-defined slices.

• SD (Slice Differentiator): an optional 24-bit value distinguishing multiple slices sharing the same SST. Example: an operator deploys two URLLC slices, one for a hospital (SD=0x000001) and one for an automotive manufacturer (SD=0x000002). Same SST=2, two completely separate slices.

The UE transmits its Requested NSSAI in the NAS Registration Request message. This NSSAI is a list of S-NSSAIs the terminal wants to access. The operator configures the Default NSSAI in the USIM or via the UDM. After negotiation, the AMF returns the Allowed NSSAI in the Registration Accept.

NSSF: the slice router

The NSSF (Network Slice Selection Function) intervenes when the AMF receiving the UE request cannot serve the requested S-NSSAIs. The NSSF determines:

1. The set of S-NSSAIs the UE is authorized to use (intersection of Requested NSSAI, Subscribed S-NSSAI in UDM, and S-NSSAIs configured on the PLMN).
2. The target AMF capable of serving those S-NSSAIs (if the initial AMF cannot).
3. The mapping between the subscription S-NSSAI (HPLMN) and the visited network S-NSSAI (VPLMN) in roaming scenarios.

The NSSF is not optional in a network offering commercial slicing. Without it, slice selection relies entirely on static AMF configuration, which does not scale.

NSACF: admission control (Release 17)

The NSACF (Network Slice Admission Control Function), introduced in 3GPP Release 17, solves a problem that Release 15 left open: how many UEs can simultaneously access a given slice?

Without NSACF, a URLLC slice configured for 500 sessions can end up with 5,000 registered terminals. The SLA collapses because there is no counting and rejection mechanism at the gate. The NSACF maintains the count of registered UEs per S-NSSAI and rejects new registrations when maximum capacity is reached.

It is the equivalent of gate control at the aircraft: even if 300 people hold tickets, the plane has only 200 seats.

The 5QI framework: QoS at the flow level

The 5QI (5G QoS Identifier) replaces the QCI (QoS Class Identifier) from 4G. It defines the treatment characteristics of a data flow within a slice. A single slice can contain multiple different 5QIs.

GBR vs non-GBR

Flows are divided into two categories:

• GBR (Guaranteed Bit Rate): the network reserves bandwidth. If the flow does not use it, the bandwidth is wasted. Used for voice, real-time video, and industrial control.
• Non-GBR: no reservation. The flow gets whatever is available. Used for web browsing, adaptive streaming, and IoT traffic.

Key 5QI values

5QI	Type	Latency budget	Packet error rate	Typical use
1	GBR	100 ms	10^-2	Voice (VoNR)
2	GBR	150 ms	10^-3	Conversational video
3	GBR	50 ms	10^-3	Real-time gaming
5	Non-GBR	100 ms	10^-6	IMS signaling
9	Non-GBR	300 ms	10^-6	Video streaming, web
82	GBR	10 ms	10^-4	V2X drone control
83	GBR	10 ms	10^-4	V2X cooperative driving
85	Non-GBR	5 ms	10^-5	High-priority URLLC

The QCI-to-5QI mapping is direct for standardized values (QCI 1 = 5QI 1, etc.), but 5G adds specific values for new use cases (V2X, industrial URLLC) that did not exist in 4G.

A critical point for field engineers: the 5QI configured in the PCF is not necessarily the one enforced by the gNB. Verification requires capturing the PDU Session Establishment Accept message in NAS signaling, which contains the QoS Profile actually assigned.

End-to-end slicing: RAN, transport, core

True slicing is end-to-end. Slicing the core alone is not enough. Each network segment must carry the isolation.

RAN slice

At the radio level, slicing relies on two mechanisms:

• BWP (Bandwidth Part): the gNB can assign different spectrum portions to different slices. A URLLC slice may receive a narrow BWP with 30 kHz SCS (short slots = low latency), while an eMBB slice gets a wide BWP with 15 kHz SCS.
• Isolated scheduling: the gNB scheduler allocates PRBs (Physical Resource Blocks) per slice according to configured priority rules. A URLLC slice always takes priority over an eMBB slice for the same PRBs.

In practice, most current deployments do not use separate BWPs per slice. RAN slicing relies primarily on scheduler configuration, which provides logical but not physical isolation. The difference is measurable in the field: under congestion, a “priority” slice can still experience degradation if the scheduler is not properly dimensioned.

Transport slice

The transport segment (between gNB and core) uses standard network segmentation mechanisms:

• VLAN tagging: each slice maps to a distinct VLAN on the backhaul and midhaul.
• MPLS / Segment Routing: for IP/MPLS transport networks, each slice maps to a specific LSP or SID-list.
• FlexE (Flexible Ethernet): for physical-layer Ethernet isolation with dedicated transmission calendars.

Core slice

At the 5G Core level, each slice can have:

• Dedicated SMF: independent session management.
• Dedicated UPF: isolated user plane with a distinct egress gateway.
• Dedicated PCF: slice-specific QoS policies.
• Shared or dedicated NF instances: depending on the required isolation level, the AMF, NRF, and AUSF can be shared across slices (logical isolation) or duplicated (physical isolation).

NFV and SDN: the technical enablers

Network slicing would not exist without two technologies that made it possible.

NFV (Network Functions Virtualization) enables deploying network functions (AMF, SMF, UPF) as containers or virtual machines, instantiable on demand. Without NFV, creating a new slice would mean deploying physical hardware, a process taking weeks or months.

SDN (Software-Defined Networking) enables configuring data paths in the transport layer programmatically. An SDN controller can create an isolated path between the gNB and a slice’s UPF in seconds, where manual router configuration would take hours.

Together, NFV and SDN transform the network into a programmable platform where a slice can be created, modified, and deleted via API. This is the foundation of MANO (Management and Network Orchestration) as defined by ETSI.

Real deployment status in 2026

The reality of commercial slicing in 2026 is less glamorous than MWC keynotes.

What is actually being sold:

• Enterprise eMBB slices with guaranteed throughput. This is essentially a mobile VPN with SLA. Asian operators (China Mobile, SK Telecom, KT) sell it at scale. In Europe, Deutsche Telekom and Vodafone offer pilot programs, primarily for sports events and industrial campuses.
• Temporary “boost” slices for events (stadiums, exhibitions). T-Mobile US announced a dynamic slicing system for 2026, but pricing details remain unclear.

What remains at pilot stage:

• Commercial URLLC slicing. The 1 ms latency specified by 3GPP is not achieved end-to-end under real-world conditions. Pilot deployments typically measure 5-15 ms, which remains excellent but does not match the marketing promise.
• Inter-operator slicing for multinational enterprises. GSMA is working on specifications, but slice roaming is not operational in production.

What does not exist yet:

• Dedicated commercial mMTC slicing. IoT sensors use slices sharing standard infrastructure without specific SLAs.
• On-demand dynamic slicing via API (the CAMARA/NEF concept). Announced everywhere, deployed nowhere.

The business model question

How do you price a slice? That is the multi-billion-dollar question that nobody has solved.

Models being explored include:

• SLA-based pricing: the customer pays for guarantees (50 Mbps minimum, 20 ms maximum latency) rather than data volume. Logical, but complex to measure and guarantee.
• Event-based pricing: a slice active for 3 hours during a football match with 80,000 spectators. Price negotiated case by case. Not scalable.
• API-based pricing: the CAMARA model where an application requests a QoS boost in real time and pays per use. Elegant in theory, nonexistent in practice.
• Enterprise plan with included slice: a 5G Business subscription that includes an eMBB slice with guaranteed throughput. This is what sells best today, but the differentiation from a simple dedicated APN is weak.

The fundamental problem is that most enterprises do not know what a slice is, do not know what they could do with one, and cannot see the difference from a 4G connection with configured QoS. The market education effort is massively underestimated.

The tension: promise vs reality

Network slicing has been standardized since 3GPP Release 15 (2018). Eight years later, the number of commercial slices sold worldwide is counted in hundreds, not millions.

The reasons for this gap are not technical. The architecture works. The specifications are complete. The equipment supports slicing. The problem is threefold:

1. BSS/OSS stack is not ready. Provisioning, monitoring, and billing a slice in real time requires a back-end systems overhaul that most operators have not completed.
2. Demand is not structured. Verticals (industry, healthcare, transport) have not yet formulated clear requirements in slicing terms. They ask for connectivity, not slices.
3. ROI is not proven. Initial deployments have not yet demonstrated that a slice generates more revenue than a dedicated APN with QoS. The concentration of 91% of slicing revenue in Asia-Pacific (essentially China) confirms this.

What this means for field engineers

For RF engineers and field technicians, slicing changes the nature of network validation. Measuring RSRP, RSRQ, and SINR is no longer sufficient. You must verify that the slice is correctly selected, that QoS is enforced, and that isolation holds under stress.

In practice, field verifications include:

1. Capture the Registration Accept: verify that the Allowed NSSAI contains the expected S-NSSAIs for the test terminal.
2. Capture the PDU Session Establishment Accept: verify the assigned S-NSSAI, 5QI, and GBR/MBR/AMBR parameters.
3. Cross-slice load testing: saturate an eMBB slice while measuring latency and jitter on a URLLC slice sharing the same gNB. Any correlation between eMBB load and URLLC degradation indicates an isolation failure.
4. Handover with slice: verify that the S-NSSAI is preserved after an intra-frequency or inter-frequency handover. The RRC Reconfiguration message must carry the slice information.

These verifications require an L3 protocol decoder capable of parsing NAS and RRC messages in real time. Smartphone-based network diagnostic tools enable this capture directly from the Qualcomm chipset, without dedicated scanner equipment.

For a deeper look at the intersection of slicing and critical infrastructure security, see our article on 5G network slicing and the NIS2 Directive.

Conclusion

Network slicing is the most ambitious idea in 5G. Dividing a physical network into isolated virtual networks, each with its own guaranteed end-to-end SLA, is an architecturally elegant and technically feasible concept.

The architecture is there. S-NSSAI, NSSF, NSACF, the 5QI framework, RAN/transport/core slicing: the puzzle pieces have been defined for years. The equipment supports them.

But the commercial reality of 2026 is sober. Slicing sells in China, is being tested in Europe, and is promised everywhere else. The business model remains unclear. The BSS/OSS stack is not ready. Enterprise demand is not structured.

For operators, the question is not whether slicing works. It works. The question is how to sell it, how to price it, and how to prove to the customer that what they are paying beyond a dedicated APN is worth the premium.

For field engineers, slicing adds a dimension to network validation. L3 signaling is no longer optional: it is the only way to verify that the slice exists beyond the configuration.