Network Slicing (S-NSSAI / NSSAI) in 5G NR
Slices end to end — S-NSSAI (SST/SD), the Requested/Allowed/Configured/Subscribed NSSAI, slice selection at registration, and how slices reach the RAN and RRC.
One physical 5G network, many logical ones. Network slicing lets an operator carve a single deployment into independent end-to-end networks — a slice tuned for phones streaming video, another for near-real-time control traffic, a third for a swarm of cheap sensors — all running on the same radio and core. This page is grounded in TS 23.501 (system architecture), TS 23.502 (procedures) and TS 38.300 (NR overall description).
Introduction
Network slicing is 5G's answer to a single question: how do you run services with contradictory requirements on one shared network without building separate hardware for each? A slice is a complete, self-contained logical network — its own control-plane and user-plane functions, its own policy and QoS — provisioned on top of shared radio, transport and core infrastructure and identified by an S-NSSAI.
Slicing touches the UE's whole lifecycle. It first appears at Registration, when the UE tells the network which slices it wants (Requested NSSAI) and the network decides which it may use (Allowed NSSAI). It reappears at every PDU session establishment, where each session is bound to exactly one slice, selecting that slice's SMF and UPF. And it stays live in the RAN, where the gNB applies slice-specific radio resource management to each bearer. Slice identity threads through NAS, NGAP and RRC.
It matters because eMBB, URLLC and massive IoT genuinely want opposite things — raw throughput, ultra-low latency, and cheap devices at enormous scale. A single network tuned as a compromise serves none of them well. Slicing gives each use case its own tuned, isolated virtual network, letting one operator sell a factory-automation slice, a mobile-broadband slice and an IoT slice off the same towers and the same core.
On this page
Why slicing is needed
In plain words: think of one motorway repainted into dedicated lanes. An ambulance lane kept clear for emergencies (URLLC), a wide freight lane for heavy loads (eMBB), and a narrow lane packed with mopeds (massive IoT) — same tarmac, same bridges, but each lane has its own rules so a traffic jam of mopeds never blocks the ambulance. A slice is a lane: a logical network with its own guarantees, painted onto shared physical infrastructure.
Concretely, three pressures make slicing necessary. First, irreconcilable requirements: URLLC needs millisecond latency and extreme reliability, eMBB needs gigabit throughput, MIoT needs to admit millions of tiny devices — no single set of RRM and core settings optimises all three. Second, isolation: a premium customer paying for guaranteed latency must not have it eroded by another tenant's traffic surge, so slices need blast-radius separation across core, transport and radio. Third, independent lifecycle and business models: an operator wants to sell, scale, and manage each slice separately — a new enterprise customer should get a new slice, not a new network. The S-NSSAI is the single identifier that makes all of this addressable end-to-end.
A partition of one 5G network into multiple end-to-end logical networks. Each slice spans the RAN, transport and core, has dedicated core-network functions (its own SMF/UPF, sometimes AMF), and is identified by an S-NSSAI.
eMBB, URLLC and massive IoT want opposite things — huge throughput vs. ultra-low latency vs. tiny cheap radios at scale. One network tuned for all three serves none well. Slices give each use case its own tuned, isolated network without duplicating hardware.
The UE asks for slices at Registration (Requested NSSAI); the AMF, helped by the NSSF, grants an Allowed NSSAI; each PDU session is then bound to one S-NSSAI + DNN, selecting that slice's SMF/UPF; and the RAN applies slice-specific RRM/QoS.
What a Network Slice Is
A slice is a complete, isolated logical network — its own control-plane and user-plane functions, its own policy and QoS treatment — provisioned on top of shared physical infrastructure. Instead of building one network that compromises between everyone's needs, the operator builds several virtual ones, each optimised for a specific use case, and steers each UE and each data flow onto the right one.
One line to remember: a slice is identified by an S-NSSAI, a UE talks to a set of slices called an NSSAI, and every PDU session lives inside exactly one slice.
It helps to separate three ideas that are easy to conflate. The S-NSSAI is the identifier of a slice. A Network Slice Instance (NSI) is the actual deployed set of network-function instances and resources that realise that slice — one S-NSSAI can map to one or more NSIs, and an NSI can be dedicated to one slice or shared by several. A Network Slice Subnet Instance (NSSI) is a management-plane building block (RAN part, core part, transport part) that composes into an NSI. Day-to-day RAN and core signalling deals only with the S-NSSAI; the NSI/NSSI concepts live in the management and orchestration domain (OSS/NFVO).
S-NSSAI = SST + SD
The S-NSSAI (Single Network Slice Selection Assistance Information) is the identifier for a single slice. It has two parts:
| Field | Size | Meaning |
|---|---|---|
SST (Slice/Service Type) | 8 bits | Mandatory. Names the kind of slice — its expected behaviour in terms of features and services. Some values are standardised so slices roam consistently across operators. |
SD (Slice Differentiator) | 24 bits | Optional. Distinguishes multiple slices of the same SST — e.g. two separate eMBB slices for two enterprise tenants. |
So an S-NSSAI is at most 32 bits (SST only = 8 bits; SST+SD = 32 bits). The standardised SST values let a slice mean the same thing everywhere:
SST value | Slice type | Optimised for |
|---|---|---|
| 1 | eMBB (enhanced Mobile Broadband) | High throughput — video, general smartphone data. |
| 2 | URLLC (Ultra-Reliable Low-Latency Comm.) | Low latency and high reliability — industrial control, remote operation. |
| 3 | MIoT (Massive IoT) | Huge numbers of low-cost, low-power devices — sensors, meters. |
| 4 | V2X | Vehicle-to-everything communications. |
| 5 | HMTC (High-Performance Machine-Type Comm.) | Demanding industrial/automation traffic (added in later releases). |
An NSSAI (the plural form) is simply a set of S-NSSAIs — up to eight can apply to a UE in a given registration. So "S-NSSAI" is one slice; "NSSAI" is a collection of slices.
Standardised vs. operator-specific: only the low SST values (1–5) are standardised for cross-network consistency. Above the standardised range an operator can define its own SST meanings, and the SD is entirely operator-assigned — which is how an operator gives each enterprise customer its own private slice under, say, SST=1.
The NSSAI Flavours — who sets which
The same idea (a set of S-NSSAIs) shows up in several forms, each owned by a different node and used at a different moment. Getting these straight is most of understanding slicing.
| NSSAI type | Who sets it | When / meaning |
|---|---|---|
Configured NSSAI | Serving PLMN (provisioned to UE), or default | Pre-configured in the UE, valid for a PLMN. What the UE draws on to build its request before it knows anything else. A Default Configured NSSAI applies to any PLMN with no specific config. |
Requested NSSAI | UE | Sent by the UE in the Registration Request — the slices it wants to use, drawn from Configured/Allowed NSSAI. |
Subscribed S-NSSAIs | HSS/UDM (subscription) | The slices the subscriber is entitled to, retrieved by the AMF from the UDM. One or more may be flagged as Default S-NSSAI. |
Allowed NSSAI | AMF (with NSSF) | The slices the network grants for this registration/access type; returned in the Registration Accept. The UE may open PDU sessions only on these. |
Rejected NSSAI | AMF | Requested slices that were refused, each with a cause (not available in this TA, not subscribed, or failed slice-specific authorization). |
Pending NSSAI | AMF | Slices whose NSSAA (slice-specific authentication) has not yet completed — not usable until authorization succeeds. |
Default S-NSSAI | Subscription (UDM) | Used when the UE sends no Requested NSSAI, or none of its requested slices are permitted — so the UE always lands on something usable. |
Mental model: the UE asks (Requested, built from Configured), the subscription entitles (Subscribed + Default), and the network decides (Allowed minus Rejected/Pending). The Allowed NSSAI is the contract the UE then lives by, and it is scoped per access type (3GPP and non-3GPP have their own Allowed NSSAI).
How Slicing Works End to End
Slice selection threads through registration, session setup and the RAN. Follow one UE through it:
1. Registration. The UE includes its Requested NSSAI in the Registration Request. Slice selection can even influence which AMF serves the UE — if the initial AMF can't support the requested slices, the request is redirected to one that can. 2. AMF + NSSF decide. The serving AMF checks the Requested NSSAI against the Subscribed S-NSSAIs and slice availability, calling the NSSF when needed, and computes the Allowed NSSAI (plus any Rejected NSSAI). 3. Registration Accept. The AMF returns the Allowed NSSAI to the UE. 4. PDU session establishment. When the UE opens a PDU session it names one S-NSSAI (from the Allowed set) and a DNN; the AMF selects an SMF for that slice (discovering it via the NRF), which selects a UPF — so the user-plane path is slice-specific. 5. RAN setup. Over NGAP (N2) the core signals the S-NSSAI to the gNB — the Allowed NSSAI arrives in Initial Context Setup Request, and each slice's S-NSSAI is carried in PDU Session Resource Setup Request — so the gNB knows which slice each data radio bearer belongs to and can apply slice-specific RRM and QoS. RRC carries slice-related information as needed.
Requested NSSAI becomes an Allowed NSSAI at the AMF (with the NSSF and UDM subscription); each PDU session then binds a single S-NSSAI + DNN to its own SMF/UPF.Slice Selection: NSSF, AMF Re-routing and the NRF
Choosing the right slice — and the right functions to serve it — is a small orchestration in itself. Several network functions cooperate:
| Function | Role in slice selection |
|---|---|
AMF | Anchors the UE's NAS; computes the Allowed NSSAI; must itself support all the UE's allowed slices (an AMF serves a set of slices). |
NSSF (Network Slice Selection Function) | Given the Requested NSSAI, subscription and TA, returns the Allowed NSSAI, the mapping to home S-NSSAIs (roaming), the target AMF Set, and the NSI ID(s) to use. |
NRF (Network Repository Function) | Discovers the SMF/UPF (and other NF) instances that belong to a given S-NSSAI / NSI, so the AMF/SMF pick slice-correct peers. |
UDM / UDR | Holds the Subscribed S-NSSAIs and the Default S-NSSAI. |
PCF | Provides the UE with URSP rules that map applications/traffic to S-NSSAIs (next section). |
A subtle but important detail is AMF re-routing. The RAN picks an initial AMF for a registering UE (often a default AMF), because at that instant the gNB only has limited assistance information. If that initial AMF cannot serve the UE's Requested NSSAI, it consults the NSSF, obtains a target AMF Set, and the registration is redirected to a suitable AMF — either directly (AMF-to-AMF over the service-based interface) or via the RAN (the initial AMF returns a Reroute NAS message and the gNB re-sends the initial NAS message to an AMF in the target set). Only after this does the UE settle on an AMF that supports its Allowed NSSAI.
URSP — Steering Which Traffic Uses Which Slice
Knowing the Allowed slices is not enough; the UE must also decide which application's traffic goes on which slice. That decision is driven by the URSP (UE Route Selection Policy), a set of rules the PCF delivers to the UE (via the AMF, as part of UE policy).
Each URSP rule pairs a Traffic Descriptor — what to match — with one or more Route Selection Descriptors — where to send it:
| URSP rule part | Contains |
|---|---|
| Traffic Descriptor | Application identifier (OSId + OS App Id), IP 3/5-tuple, non-IP descriptor, DNN, FQDN, connection capabilities. |
| Route Selection Descriptor | The target S-NSSAI, DNN, SSC mode, preferred access type (3GPP / non-3GPP), and PDU session type — with a precedence value. |
When an application starts sending, the UE evaluates its URSP rules in precedence order, finds the matching Traffic Descriptor, and reads the Route Selection Descriptor to learn the S-NSSAI and DNN. If a PDU session to that (S-NSSAI, DNN) already exists it is reused; otherwise the UE triggers a new PDU session establishment on that slice. This is how, for example, a factory-control app lands on the URLLC slice while the browser stays on the eMBB slice — automatically, without the user choosing.
Two halves of "which slice": the Allowed NSSAI says which slices the UE may use; the URSP says which slice each flow should use. Both are needed to route real traffic.
Slice Authorization (NSSAA) and Admission Control (NSAC)
Some slices need more than a subscription flag, and every slice needs a way to stop being overrun. Two mechanisms handle this.
NSSAA — Network Slice-Specific Authentication and Authorization. A slice can be marked (in the subscription) as requiring an extra authentication beyond the primary 5G-AKA registration — for example an enterprise slice that authenticates the user against the enterprise's own DN-AAA server (AAA-S). The AMF runs an EAP exchange (relayed via the AUSF/NSSAAF to the AAA-S) for each such S-NSSAI. Until it succeeds, that S-NSSAI sits in the Pending NSSAI; on success it moves to the Allowed NSSAI, on failure to the Rejected NSSAI. NSSAA can also be re-run or revoked mid-session by the network.
NSAC — Network Slice Admission Control. An operator may cap how much a slice can carry — a maximum number of registered UEs and/or a maximum number of PDU sessions per S-NSSAI. The NSACF (Network Slice Admission Control Function) tracks these counts; the AMF/SMF check with it and reject registration on, or session establishment for, a slice whose quota is already reached. This protects a premium slice's guarantees from simple overload.
| Mechanism | What it enforces | Key node |
|---|---|---|
NSSAA | Extra per-slice user authentication/authorization (EAP to DN-AAA) | AMF + NSSAAF + AAA-S |
NSAC | Max registered UEs / max PDU sessions per slice (quota) | NSACF |
Slicing While Roaming
Slice identifiers are PLMN-specific, so roaming needs a translation layer. The UE, in a visited network (VPLMN), works with VPLMN S-NSSAI values, but its subscription and (for home-routed traffic) its slices live in the home network (HPLMN) under HPLMN S-NSSAI values.
Two things make this work. First, the UE stores a Mapping Of its NSSAIs — Configured, Requested and Allowed NSSAI each carry a mapping from the serving-PLMN S-NSSAI to the corresponding home S-NSSAI. Second, the visited and home NSSFs (vNSSF/hNSSF) cooperate during registration to produce a consistent Allowed NSSAI and mapping. For home-routed sessions the user plane returns to the HPLMN (via home UPF), so the home slice's treatment applies; for local breakout the visited network serves the session under a mapped visited slice. The upshot: the UE experiences the "same" slice while the two operators each use their own S-NSSAI values underneath.
Isolation and RAN Resource Management
Slicing is only useful if slices don't trample each other. Isolation happens at every layer: separate core functions per slice (control and user plane), transport-network isolation between sites, and on the RAN, slice-aware radio resource management.
Once the gNB learns each bearer's S-NSSAI over NGAP, it can treat radio resources per slice. Typical mechanisms: reserving a share of PRBs for a slice (an RRM policy ratio, often min/max guaranteed) so a burst on eMBB can't starve a URLLC slice's latency budget; a slice-aware scheduler that prioritises one slice's transmissions; and slice admission control at the RAN that rejects a new DRB on a slice whose radio resources are exhausted. How aggressively resources are partitioned versus shared is a vendor/operator RRM policy — 3GPP defines the S-NSSAI signalling and the requirement to support differentiated handling, not the exact algorithm. The RAN also advertises which slices it supports (per TA/cell) so the core only assigns UEs to slices the cell can actually serve.
Transport slicing completes the picture between the RAN and core — techniques such as VLANs, MPLS/segment routing, or FlexE hard-partition the fronthaul/backhaul so a slice's packets get isolated bandwidth and latency across the transport network too. End-to-end isolation is therefore a stack: dedicated (or shared-with-guarantees) NFs in the core, an isolated transport path, and slice-aware RRM in the RAN.
Slices are not necessarily available everywhere. Slice availability is defined per Tracking Area (TA): a given S-NSSAI may be supported in some TAs and not others, which is exactly why the NSSF exists and why the Allowed NSSAI is scoped to registration area and access type. If the UE moves into an area where an allowed slice isn't supported, that slice can end up in the Rejected NSSAI and the affected PDU sessions are released or relocated.
Isolation in one breath: separate core functions per slice + isolated transport + slice-aware RRM at the gNB + per-TA availability. Together they keep a busy eMBB slice from breaking a URLLC slice's guarantees.
LTE ↔ NR: LTE had no true network slicing. The closest analogues were DECOR (Dedicated Core Networks) and eDECOR, which steered a UE to a dedicated core using a UE Usage Type — but that was coarse, core-only, and chose a whole CN rather than an end-to-end logical network. 5G replaces this with the fine-grained, RAN-to-core S-NSSAI: a UE can use up to eight slices simultaneously, each PDU session bound to its own slice, with slice-aware RRM in the gNB — none of which the EPC/E-UTRAN could express.
⚠ Common pitfalls / gotchas
- Treating "NSSAI" as one slice. An S-NSSAI is one slice; an NSSAI is a set of them. The various flavours (Configured / Requested / Allowed / Rejected / Pending) are different sets owned by different nodes.
- Forgetting the eight-slice limit. At most eight S-NSSAIs apply to a UE per registration and access type — a real cap when designing device slice profiles.
- Assuming a slice exists everywhere. Availability is per-TA. A slice in the
Allowed NSSAIcan still be unusable after mobility and end upRejected, tearing down its PDU sessions. - Ignoring URSP. Being allowed a slice does not route traffic to it; without a matching URSP rule the UE won't steer an application onto the intended slice.
- Confusing SD scope. The same
SDvalue under differentSSTs, or across PLMNs, means different slices — and roaming needs the home/visited S-NSSAI mapping to line them up.
Summary
A network slice is an end-to-end logical network — RAN, transport and core — identified by an S-NSSAI (SST, 8 bits, mandatory; SD, 24 bits, optional). A UE works with a set of slices, an NSSAI (up to eight per registration), and the flavours matter: the UE asks with Requested NSSAI, the subscription entitles via Subscribed/Default S-NSSAI, and the network grants the Allowed NSSAI (with Rejected/Pending for the rest).
The lifecycle runs Registration → AMF/NSSF decision → PDU session bound to one S-NSSAI + DNN → NGAP signalling of the S-NSSAI to the gNB → slice-aware RRM. Supporting machinery fills the gaps: the NRF discovers slice-correct NFs, AMF re-routing moves a UE to an AMF that supports its slices, URSP from the PCF steers each application to a slice, NSSAA adds per-slice authentication, and NSAC (via the NSACF) caps registered UEs and PDU sessions per slice.
The one-line takeaway: the S-NSSAI is the thread that ties a use case to dedicated (or guaranteed-share) resources from the gNB scheduler all the way to the UPF — and isolation across core, transport and radio, plus per-TA availability, is what makes the guarantee real.
Q. What exactly is an S-NSSAI made of, and which part is mandatory?
A. An S-NSSAI identifies a single slice and consists of a mandatory SST (Slice/Service Type, 8 bits — e.g. 1 = eMBB, 2 = URLLC, 3 = MIoT, 4 = V2X) and an optional SD (Slice Differentiator, 24 bits) that distinguishes multiple slices of the same SST. An NSSAI is a set of up to eight S-NSSAIs.
Q. How does the Requested NSSAI become the Allowed NSSAI?
A. The UE sends the Requested NSSAI in the Registration Request. The AMF checks it against the Subscribed S-NSSAIs from the UDM and against per-TA slice availability, consulting the NSSF when needed, and returns the permitted subset as the Allowed NSSAI in the Registration Accept (with refused slices in the Rejected NSSAI and any awaiting slice-auth in the Pending NSSAI).
Q. How does the gNB learn which slice a PDU session belongs to?
A. Over NGAP (N2): the S-NSSAI is carried in messages such as PDU Session Resource Setup, and the Allowed NSSAI is provided in Initial Context Setup. The gNB uses this to apply slice-specific RRM and QoS to the corresponding radio bearers.
Q. What is the difference between the Allowed NSSAI and URSP?
A. The Allowed NSSAI defines which slices the UE may use in this registration. The URSP (from the PCF) tells the UE which slice each application/flow should use, by matching a Traffic Descriptor to a Route Selection Descriptor (S-NSSAI + DNN). One authorizes; the other routes.
Q. Why might a UE's registration be re-routed to a different AMF?
A. Because an AMF only serves a set of slices. If the RAN's initially-selected AMF cannot support the UE's Requested NSSAI, the NSSF returns a target AMF Set and the registration is redirected (directly or via a Reroute NAS message through the RAN) to an AMF that supports the UE's slices.
Q. What is NSSAA, and how does it show up to the UE?
A. Network Slice-Specific Authentication and Authorization is an extra EAP-based authentication for slices that require it (e.g. to an enterprise DN-AAA). Until it completes, the S-NSSAI stays in the Pending NSSAI; success moves it to Allowed, failure to Rejected.
Quick LTE 4G / 5G NR Interview Questions — Slice Selection
Q. How does a UE end up connected to the correct network slice — what actually drives the AMF's slice selection?
A. The UE includes Requested NSSAI (a list of S-NSSAIs it wants) in its Registration Request, based on what's configured/allowed for it. The AMF checks this against the subscriber's allowed slices (from UDM) and, if the current AMF doesn't support the needed slice, may redirect the UE to a different AMF that does (via NSSF lookup) before finalizing which slices the UE is actually granted (Allowed NSSAI).
Q. What happens if a UE requests a slice it isn't subscribed to?
A. The AMF's NSSF-assisted selection process filters against the subscription data from UDM; a non-subscribed slice is simply excluded from the resulting Allowed NSSAI returned to the UE — the UE doesn't get an error for the whole registration, just a reduced set of usable slices compared to what it asked for.
Q. Why does slice selection sometimes require an AMF change mid-registration, when the UE is already talking to an AMF?
A. Not every AMF supports every slice (AMFs can be deployed with limited slice support for isolation/scaling reasons). If the initially-contacted AMF can't serve one of the UE's requested slices, it queries the NSSF, which can return a different, slice-capable AMF — triggering a RAN-assisted AMF reroute before registration completes, rather than the original AMF trying to serve a slice it has no capability for.
Where slicing connects
Slicing decides which logical network a flow uses; the QoS model decides how that flow is treated inside it, and the registration and N2 procedures are where slice information is exchanged.