Network Slice Selection Assistance Information (NSSAI) is a signaling parameter set in the 5G System Architecture that enables User Equipment (UE) to request and the network to authorize access to specific Network Slice instances. It is the fundamental identifier that maps a device's service requirements—such as latency, throughput, or reliability—to a logical end-to-end network partition during the initial access and Protocol Data Unit (PDU) Session establishment phases.
Glossary
Network Slice Selection Assistance Information (NSSAI)

What is Network Slice Selection Assistance Information (NSSAI)?
A collection of parameters used by User Equipment (UE) to select a specific Network Slice instance during the 5G registration procedure.
The NSSAI is composed of a collection of Single NSSAIs (S-NSSAIs), each uniquely identifying a slice type via a Slice/Service Type (SST) and an optional Slice Differentiator (SD). The 5G Core's Network Slice Selection Function (NSSF) processes the Requested NSSAI from the UE against the Subscribed NSSAI to select the appropriate Access and Mobility Management Function (AMF) and target slice instance, enforcing Slice Admission Control and isolation policies.
Key Characteristics of NSSAI
The Network Slice Selection Assistance Information (NSSAI) is a fundamental collection of identifiers that enables User Equipment (UE) to request and connect to specific network slice instances during the 5G registration procedure.
Single NSSAI (S-NSSAI)
The atomic unit of slice identification, consisting of two mandatory components:
- Slice/Service Type (SST): An 8-bit standardized or non-standardized value defining the expected network slice behavior (e.g., SST=1 for eMBB, SST=2 for URLLC).
- Slice Differentiator (SD): An optional 24-bit field that complements the SST to distinguish among multiple slices with the same SST but different tenants or service requirements.
An S-NSSAI can be expressed as either SST-only or SST+SD, providing granularity for up to 256 standardized service types.
Configured NSSAI
A list of S-NSSAIs provisioned in the UE by the serving network, typically containing one or more entries. This list defines which network slices the UE is authorized to access within the current registration area.
Key behaviors:
- The UE stores the Configured NSSAI per Public Land Mobile Network (PLMN).
- The Access and Mobility Management Function (AMF) may update this list during registration or configuration update procedures.
- A Default Configured NSSAI is applied when no specific configuration exists for a PLMN.
Requested NSSAI
The set of S-NSSAIs that the UE includes in its Registration Request message to the AMF. This list is derived from the Configured NSSAI and represents the specific slices the UE intends to connect to.
Selection logic:
- The UE's Non-Access Stratum (NAS) layer constructs this list based on application requirements and the available Configured NSSAI.
- The AMF validates the Requested NSSAI against the UE's subscription information retrieved from the Unified Data Management (UDM).
- If validation fails, the AMF may reject the request or redirect the UE to a default slice.
Allowed NSSAI
The definitive list of S-NSSAIs that the AMF authorizes the UE to use within the current registration area. This is the output of the network's slice admission control process.
Critical properties:
- The Allowed NSSAI is a subset of the Requested NSSAI, filtered by subscription and network capability.
- It may include S-NSSAIs with different SST or SD values than those requested, if the network applies slice remapping.
- The UE uses this list to determine which Protocol Data Unit (PDU) sessions can be established on which slices.
Subscribed S-NSSAIs
The permanent list of S-NSSAIs stored in the UE's subscription profile within the UDM. This represents the contractual agreement between the network operator and the subscriber.
Enforcement mechanism:
- During registration, the AMF retrieves the Subscribed S-NSSAIs from the UDM.
- Any S-NSSAI in the Requested NSSAI that is not present in the subscription is rejected.
- For each subscribed S-NSSAI, the UDM may specify whether it is the default S-NSSAI for the subscriber.
NSSAI Inclusion Modes
The 3GPP standard defines several modes governing how NSSAI is transmitted during signaling procedures:
- Mode A: UE includes S-NSSAI in Radio Resource Control (RRC) messages, enabling the gNB to perform slice-aware admission control before establishing RRC connection.
- Mode B: UE includes S-NSSAI only in NAS messages, keeping slice information transparent to the RAN.
- Mode C: UE includes S-NSSAI in both RRC and NAS messages, providing slice awareness to both the RAN and core network.
- Mode D: Network triggers slice re-selection by providing a new Allowed NSSAI.
Enabling Efficiency, Speed & Accuracy
Intelligent Analysis, Decision & Execution
We build AI systems for teams that need search across company data, workflow automation across tools, or AI features inside products and internal software.
Talk to Us
Search across company data
Give teams answers from docs, tickets, runbooks, and product data with sources and permissions.
Useful when people spend too long searching or get different answers from different systems.

Automate internal workflows
Use AI to route work, draft outputs, trigger actions, and keep approvals and logs in place.
Useful when repetitive work moves across multiple tools and teams.

Add AI to products and internal tools
Build assistants, guided actions, or decision support into the software your team or customers already use.
Useful when AI needs to be part of the product, not a separate tool.
Frequently Asked Questions
Essential questions and answers about Network Slice Selection Assistance Information (NSSAI), the critical parameter set that enables User Equipment to identify and connect to specific 5G network slice instances during registration.
Network Slice Selection Assistance Information (NSSAI) is a collection of parameters used by User Equipment (UE) and the 5G Core Network to identify and select a specific Network Slice instance during the UE's registration procedure. Defined in 3GPP TS 23.501, NSSAI serves as the fundamental addressing mechanism for network slicing, enabling a single physical 5G infrastructure to present multiple logical networks to devices. The NSSAI is composed of one or more Single NSSAIs (S-NSSAIs), each uniquely identifying a slice through a combination of a Slice/Service Type (SST) and an optional Slice Differentiator (SD). The UE provides Requested NSSAI in its Registration Request, and the network responds with an Allowed NSSAI that specifies which slices the UE is authorized to use within its current Registration Area. This mechanism ensures that devices only access slices aligned with their subscription profiles and service requirements.
Related Terms
Explore the core components and operational mechanisms that interact with the Network Slice Selection Assistance Information (NSSAI) to enable end-to-end 5G slicing.

About the author
Prasad Kumkar
CEO & MD, Inference Systems
Prasad Kumkar is the CEO & MD of Inference Systems and writes about AI systems architecture, LLM infrastructure, model serving, evaluation, and production deployment. Over 5+ years, he has worked across computer vision models, L5 autonomous vehicle systems, and LLM research, with a focus on taking complex AI ideas into real-world engineering systems.
His work and writing cover AI systems, large language models, AI agents, multimodal systems, autonomous systems, inference optimization, RAG, evaluation, and production AI engineering.
Partnered with leading AI, data, and software stack.
How We Work
Custom AI workflows for your Business
One-fit-all AI don't work for modern businesses. At Inferensys, we aim to understand your business & custom requirements; which we use to define most efficient agentic workflows, the data, and the tools for your business.
01
Review the use case
We understand the task, the users, and where AI can actually help.
Read more02
Pick the right approach
We define what needs search, automation, or product integration.
Read more03
Build the first useful version
We implement the part that proves the value first.
Read more04
Improve from there
We add the checks and visibility needed to keep it useful.
Read moreThe first call is a practical review of your use case and the right next step.
Talk to Us