Configured NSSAI
How Slice Provisioning Reaches the Device
In a 5G system the network can be partitioned into logical slices, each tailored to a service class such as enhanced mobile broadband, ultra-reliable low-latency communication, or massive machine-type communication. A device cannot request an arbitrary slice; it may only ask for slices it has been provisioned to use. The Configured NSSAI is the mechanism that carries that provisioning to the UE. It is a per-PLMN list, meaning the operator that owns a given network identity provisions a distinct set of S-NSSAIs for that identity, and the device keeps separate Configured NSSAIs for each PLMN it has been configured for.
Each entry is a Single Network Slice Selection Assistance Information value, or S-NSSAI. An S-NSSAI is built from a mandatory 8-bit Slice/Service Type (SST) and an optional 24-bit Slice Differentiator (SD), giving a 32-bit identifier when both fields are present. The SST values 1, 2, 3, 4, and 5 are standardized for eMBB, URLLC, MIoT, V2X, and HMTC (high-performance machine-type communications) respectively, while operator-specific SST values occupy the higher range. The SD distinguishes multiple instances of the same service type, for example two URLLC slices serving different enterprise tenants on one network.
The list arrives on the device through one of several paths: pre-provisioned on the USIM, delivered by device management, or pushed over the air by the AMF in a Configuration Update Command after registration. Whichever path is used, the Configured NSSAI sets the ceiling on what the UE may legitimately request, while the Allowed NSSAI returned by the network sets what is granted for the current registration area.
S-NSSAI Structure and Limits
S-NSSAI = SST (8 bits) [ + SD (24 bits) ] → up to 32 bits total
List size limits (3GPP TS 23.501 / TS 24.501):
|Configured NSSAI| ≤ 16 S-NSSAIs per PLMN
|Requested NSSAI| ≤ 8 S-NSSAIs (NAS signaling)
|Allowed NSSAI| ≤ 8 S-NSSAIs per access type
Standardized SST values:
SST 1 → eMBB, SST 2 → URLLC, SST 3 → MIoT, SST 4 → V2X, SST 5 → HMTC
Requested NSSAI ⊆ (Configured NSSAI ∪ previously Allowed NSSAI). The AMF, with the NSSF, derives Allowed NSSAI ⊆ Subscribed S-NSSAIs. SD presence is optional; an S-NSSAI with SST only is valid.
NSSAI Types Compared
| NSSAI Type | Stored / Sent By | Scope | Max S-NSSAIs | Role |
|---|---|---|---|---|
| Configured NSSAI | UE (provisioned) | Per PLMN | 16 | Permission ceiling for what the UE may request |
| Default Configured NSSAI | UE (from HPLMN) | Any PLMN with no specific list | 16 | Fallback when no PLMN-specific entry exists |
| Requested NSSAI | UE → AMF | Registration Request | 8 | What the device asks for at registration |
| Allowed NSSAI | AMF → UE | Per registration area / access | 8 | What the network authorizes for current use |
| Rejected NSSAI | AMF → UE | Whole PLMN or RA | n/a | S-NSSAIs the network declines, with a cause |
Frequently Asked Questions
What is the difference between Configured NSSAI, Requested NSSAI, and Allowed NSSAI?
The Configured NSSAI is the device-stored set of S-NSSAIs a UE may use in a given PLMN, up to 16 entries. From it the UE derives the Requested NSSAI (capped at 8) sent in the Registration Request, optionally adding S-NSSAIs from a previously received Allowed NSSAI. The AMF, consulting the NSSF and subscription data, returns the Allowed NSSAI in Registration Accept; that is the subset actually authorized for the current registration area. In short, Configured is the ceiling, Requested is the ask, and Allowed is the grant.
How is the Default Configured NSSAI used when no PLMN-specific entry exists?
The Default Configured NSSAI is a fallback list provisioned by the Home PLMN that a UE applies in any serving network for which it has neither a PLMN-specific Configured NSSAI nor a slice mapping. On first registration in such a network the UE builds the Requested NSSAI from this default, typically containing SST 1 (eMBB), so it always has a usable starting slice. Once the network returns an Allowed NSSAI and a PLMN-specific Configured NSSAI via the Configuration Update Command, the UE stores that per-PLMN list and uses it thereafter.
How does the AMF update a UE Configured NSSAI after registration?
The AMF pushes an updated, PLMN-specific Configured NSSAI using the UE Configuration Update procedure, sending a Configuration Update Command NAS message. It can carry the new Configured NSSAI, the Allowed NSSAI, and the mapping between serving-PLMN and Home-PLMN S-NSSAIs. Depending on the indicated flags the UE may need to acknowledge or perform a re-registration to apply the change, letting operators provision a new slice such as a URLLC slice over the air without a SIM swap.