Description
Network Slice Selection Assistance Information (NSSAI) is a fundamental concept and data structure in 5G System (5GS) architecture, introduced in 3GPP Release 15. It is the mechanism by which a User Equipment (UE) communicates its desired network slice(s) to the network during registration and session establishment procedures. An NSSAI is not a single identifier but a collection, typically containing one or more Single Network Slice Selection Assistance Information (S-NSSAI) elements. Each S-NSSAI is the unique identifier for a specific network slice instance or slice type that a UE is permitted to access.
An S-NSSAI itself is composed of two parts: a Slice/Service Type (SST) and an optional Slice Differentiator (SD). The SST is a mandatory 8-bit field that indicates the expected network slice behavior in terms of features and services (e.g., enhanced Mobile Broadband - eMBB, Ultra-Reliable Low Latency Communications - URLLC, Massive IoT - MIoT). The SD is an optional 24-bit field used to differentiate among multiple network slice instances of the same SST, allowing an operator to deploy several slices for the same service type but for different tenants or use cases. The UE obtains the S-NSSAIs it is allowed to use from its subscription profile, often configured via the home operator.
During the initial registration procedure, the UE includes a Requested NSSAI in the Registration Request message sent to the Access and Mobility Management Function (AMF) via the (R)AN. The Requested NSSAI contains the S-NSSAIs the UE wishes to register for in the current registration area. The AMF, in conjunction with the Network Slice Selection Function (NSSF) and subscription data from the Unified Data Management (UDM), validates these requests. The network then responds with an Allowed NSSAI, which is the set of S-NSSAIs the UE is permitted to use in the current registration area. The UE stores this Allowed NSSAI and includes a subset of it, called the Configured NSSAI for the serving Public Land Mobile Network (PLMN), in subsequent registration and PDU Session Establishment requests. This process ensures the UE is connected to the correct AMF and Session Management Function (SMF) instances that support the requested slices, enabling the tailored connectivity and resource allocation that defines network slicing.
Purpose & Motivation
NSSAI was created to solve the critical problem of slice selection and routing in a 5G network where multiple logical networks (slices) coexist on shared physical infrastructure. In pre-5G systems, a UE simply attached to "the network." With network slicing, a UE may need access to several distinct logical networks simultaneously—for example, one for regular internet browsing (eMBB), one for a corporate VPN, and one for a low-latency gaming service. The network needed a standardized way for the UE to signal which of these logical networks it required for a given communication context.
The NSSAI mechanism provides this signaling. It addresses the limitation of earlier networks which lacked a native, standardized identifier for service-specific network partitions. Without NSSAI, implementing slicing would require non-standard, proprietary signaling or inefficient over-the-top solutions. NSSAI enables efficient network resource utilization by allowing the (R)AN and core network to direct traffic to the specific set of network functions (AMF, SMF, UPF, etc.) instantiated for a slice. This is essential for meeting the diverse Key Performance Indicators (KPIs) of different services, as it ensures the UE's data plane and control plane are handled by functions configured with the appropriate policies (e.g., latency, bandwidth, security). Its introduction was a cornerstone in making the 5G vision of customized logical networks a practical reality.
Classification
Release Timeline
Detected Changes Across Releases
from 3GPP Change RequestsSpecific changes extracted from the „Change history“ tables of 3GPP specifications (606 CRs across 5 releases). Complements the general historical overview above with the evidence-based evolution of this function.
In Release 15, the foundational framework for NSSAI was established, introducing key concepts such as the Allowed NSSAI, Configured NSSAI, and Requested NSSAI to enable network slice selection. The release specified procedures for handling S-NSSAI during mobility between EPS and 5GS, including storing the Configured NSSAI upon PLMN change and incorporating received S-NSSAI into requests during inter-system change. It also introduced mechanisms like the Target NSSAI for steering UEs to supporting cells and clarified functionalities for congestion control, overload control, and the handling of rejected or alternative S-NSSAIs.
- Handling of S-NSSAI and PDU session ID during mobility between EPS and 5GS TS 24.301CR2965
- S-NSSAI info for PDN connection established over ePDG/EPC TS 24.302CR0666
- Including S-NSSAI received in EPS in Requested NSSAI and in PDU session establishment request upon inter-system change from S1 mode to N1 mode TS 24.501CR0082
- Storing Configured NSSAI when the PLMN is changed TS 24.501CR0203
- Addition of NSSAI Test Mode TS 38.509CR0018
- Correction of the definitions of Allowed NSSAI and Configured NSSAI TS 23.501CR0005
+ 74 more changes
In Release 16, key enhancements for NSSAI included the introduction of a **Pending NSSAI** to manage network slice-specific authentication and authorization procedures and the formal definition of a **Partially Allowed NSSAI**, which indicates S-NSSAIs usable only in specific Tracking Areas within a registration area. The release also expanded support by allowing the use of S-NSSAI for non-3GPP access and introduced mechanisms for handling S-NSSAI-based congestion backoff timers and registration rejection when no allowed S-NSSAI is available.
- 23.501 part of PCF selection for PDU sessions with same DNN and S-NSSAI TS 23.501CR1375
- NSSAI not allowed for MA PDU session establishment TS 24.501CR1271
- "S-NSSAI not available in the current PLMN" when non NSSAA supported UE requesting the S-NSSAI subjects to NSSAA TS 24.501CR1598
- NSSAI storage impact with NSSAA TS 24.501CR1602
- Introduction of NSSAI efficient signalling for IoT devices TS 24.501CR1657
- Handling of S-NSSAIs in the pending NSSAI TS 24.501CR1889
+ 116 more changes
In Release 17, enhancements to NSSAI introduced the concept of a "Partially Allowed NSSAI," which indicates S-NSSAIs the UE can use only in specific Tracking Areas within its Registration Area, with each S-NSSAI associated with a list of supporting TAs. The release also defined procedures for determining a "Target NSSAI" to steer the UE to cells supporting specific network slices and clarified its association with an RFSP Index for the NG-RAN. Furthermore, it specified that the UPF can allocate internal resources based on both the Network Instance and the S-NSSAI provided during PDU session establishment.
- Support multiple NSACFs for one S-NSSAI during UE mobility TS 23.501CR2909
- Support of the default configured NSSAI in the SNPN TS 24.501CR3260
- DNN/S-NSSAI providing in PDU session establishment for SNPN onboarding TS 24.501CR3322
- New cause value for rejected NSSAI TS 24.501CR3106
- S-NSSAI rejected due to maximum number of UEs reached and BO timer value TS 24.501CR3123
- PDU session establishment with the DNN/S-NSSAI for UAS service from the UE whch has valid aerial subscription but UUAA-MM is failed abnormally TS 24.501CR3792
+ 148 more changes
In Release 18, key enhancements for NSSAI included the introduction of a Partially Allowed NSSAI, which indicates S-NSSAIs the UE can use only in specific Tracking Areas within its Registration Area, and the introduction of an Alternative S-NSSAI determined by the NSSF for network slice replacement. Furthermore, the release specified procedures for storing S-NSSAI validity time and location availability information, and enhanced support for LADN services per DNN and S-NSSAI combination.
- N3IWF selection enhancement for support of S-NSSAI needed by UE TS 23.501CR3707
- TNGF selection enhancement for support of S-NSSAI needed by UE TS 23.501CR3953
- Introduction of partially Allowed NSSAI and Partially Rejected S-NSSAI TS 23.501CR4035
- Introduction of Alternative S-NSSAI replacement determined by NSSF TS 23.501CR4036
- Updates on S-NSSAI Location Availability information TS 23.501CR4487
- Storage of S-NSSAI validity time information TS 23.501CR4488
+ 201 more changes
In Release 19, the NSSAI function was enhanced with new capabilities for managing Alternative and Configured NSSAI, including procedures for storing Alternative NSSAI in non-volatile memory and its deletion based on time validity information. The release introduced clarifications for slice handling during AF-requested modifications and interactions with Partially Allowed NSSAI, while also providing corrections for definitions like HPLMN S-NSSAI and requirements for NSSAI inclusion modes. Furthermore, it specified support for S-NSSAI selection while a UE is in EPS and added mechanisms for S-NSSAI granularity in energy consumption exposure.
- Provisioning an S-NSSAI via the PDN CONNECTIVITY REQUEST message TS 24.301CR3655
- DNN association for served S-NSSAI in Terminal Response for PLI - list of slices information and Envelope (Event Download slice status) command TS 31.111CR0871
- S-NSSAI selection while in EPS TS 23.501CR5866
- Support for S-NSSAI granularity energy consumption exposure TS 23.501CR5956
- Correction about Default Configured NSSAI TS 23.501CR5472
- Clarification on Configured NSSAI in AF Requested modification of the Set of Network Slice(s) for a UE TS 23.501CR6114
+ 37 more changes
Explore further
Broader topics and technologies where NSSAI plays a role.
Defining Specifications
3GPP specifications that define or reference NSSAI, with the latest known release. Sourced from the 3GPP document catalog — see methodology.
| Specification | Title | Release |
|---|---|---|
| TS 23.501 vk00 | 5G System Architecture Stage 2 | Rel-20 |
| TS 23.700 vk00 | XR Services Application Enablement Layer | Rel-20 |
| TS 24.301 vj60 | NAS protocol for Evolved Packet System | Rel-19 |
| TS 24.302 vj00 | Access to EPC via non-3GPP networks; Stage 3 | Rel-19 |
| TS 24.501 vj50 | 5G NAS Protocols Specification | Rel-19 |
| TS 24.890 vg00 | 5G NAS Protocol for 5GS Stage 3 | Rel-16 |
| TS 26.501 vj30 | 5G Media Streaming (5GMS) Architecture | Rel-19 |
| TS 26.804 vj10 | 5G Media Streaming Extensions Study | Rel-19 |
| TS 26.891 vg00 | Media Distribution Services in 5G System | Rel-16 |
| TS 28.202 vj00 | 5G Network Slice Management Charging | Rel-19 |
| TS 28.541 vk00 | 5G Network Resource Model (NRM) Stage 2/3 | Rel-20 |
| TS 28.801 vf10 | Management and Orchestration of Network Slicing | Rel-15 |
| TS 29.503 vj50 | UDM Service Based Interface Stage 3 | Rel-19 |
| TS 29.507 vj40 | 5G Access & Mobility Policy Control Service | Rel-19 |
| TS 29.508 vj40 | 5G Session Management Event Exposure Service | Rel-19 |
| TS 29.513 vj40 | 5G PCC Signalling Flows & QoS Mapping | Rel-19 |
| TS 29.518 vj50 | AMF Service Based Interface Protocol | Rel-19 |
| TS 29.541 vj30 | NEF Service-Based Interfaces for NIDD & SMS | Rel-19 |
| TS 29.562 vj40 | HSS Services for IMS & GBA Interworking | Rel-19 |
| TS 29.890 vg00 | CT3 5G System Technical Report | Rel-16 |
| TS 31.111 vj30 | USIM Application Toolkit (USAT) Specification | Rel-19 |
| TS 32.899 vf10 | 5G Charging Architecture Study | Rel-15 |
| TS 33.117 vk00 | Catalogue of General Security Assurance Requirements | Rel-20 |
| TS 33.501 vk00 | 5G Security Architecture and Procedures | Rel-20 |
| TS 36.331 vj00 | LTE RRC Protocol Specification | Rel-19 |
| TS 37.473 vj00 | W1 Application Protocol (W1AP) Specification | Rel-19 |
| TS 37.483 vj10 | E1 Application Protocol (E1AP) | Rel-19 |
| TS 38.413 vj10 | NG Application Protocol (NGAP) | Rel-19 |
| TS 38.423 vj10 | Xn Application Protocol (XnAP) specification | Rel-19 |
| TS 38.463 vj00 | E1 Application Protocol (E1AP) | Rel-19 |
| TS 38.473 vj10 | 5G F1 Application Protocol (F1AP) | Rel-19 |
| TS 38.509 vi00 | Special conformance testing functions for UE | Rel-18 |
