Alternative Single Network Slice Selection Assistance Information

Description

The Alternative S-NSSAI is a Rel-19 concept introduced in 3GPP TS 23.501 and referenced in TS 29.502 for the NSSF/NRF service-based interfaces. In 5G System (5GS) network slicing, a UE registers with the network and receives an Allowed NSSAI — a list of S-NSSAIs (each composed of an SST and optional SD) that the UE is permitted to use in the current Registration Area. Each S-NSSAI identifies a network slice instance (NSI) or a set of NSIs providing specific service characteristics. When a slice identified by an S-NSSAI in the Allowed NSSAI becomes temporarily unavailable — for example due to slice congestion, NSI failure, or resource constraints — the AMF needs a mechanism to redirect the UE's PDU session or service request to a functionally compatible slice rather than rejecting the request outright.

The Alternative S-NSSAI provides exactly this mechanism. For a given S-NSSAI in the Allowed NSSAI, the network (typically the NSSF or the AMF itself, based on operator policy and slice availability information) can associate one or more Alternative S-NSSAIs that are considered compatible — meaning they satisfy the same or overlapping service requirements (e.g., same slice/service type, comparable QoS, similar feature set). When the AMF detects that the original S-NSSAI is unavailable or congested, it replaces that S-NSSAI with the Alternative S-NSSAI in the Allowed NSSAI communicated to the UE, so that subsequent UE requests referencing the original slice are transparently mapped to the alternative one.

Architecturally, this involves several network functions. The NSSF (Network Slice Selection Function) determines the Allowed NSSAI and can provide alternative slice mappings based on slice availability and load. The AMF enforces the substitution and maintains the mapping for the duration of the UE's registration. The UDM stores subscription data including subscribed S-NSSAIs, which constrain which alternatives are permissible. The PCF may provide policy information that influences slice selection. TS 29.502 defines the service-based interface (Nnssf) messages used to request and return slice selection information, which in Rel-19 can carry alternative S-NSSAI information.

The mechanism operates at registration and at service request time. During registration, the AMF obtains the Allowed NSSAI; if some S-NSSAIs are unavailable, the AMF may include Alternative S-NSSAIs. When the UE later requests a PDU session for a slice that has been substituted, the AMF (and SMF) use the alternative to establish the session on a compatible NSI. This avoids session establishment failures and improves user experience during partial slice outages.

Key considerations include: compatibility criteria (the alternative must meet the UE's service requirements), operator policy (which alternatives are allowed), and consistency (the UE must be informed of the substitution so it uses the correct S-NSSAI in subsequent requests). The Alternative S-NSSAI is distinct from the concept of a mapped S-NSSAI used in roaming (which maps a visited-network S-NSSAI to a home-network S-NSSAI); the alternative is about availability-driven substitution within the same network.

Purpose & Motivation

Network slicing allows operators to run multiple logical networks on shared infrastructure, but slices are not always available — an NSI may be congested, undergoing maintenance, or partially failed. Before Rel-19, when an S-NSSAI in the Allowed NSSAI became unavailable, the network had limited options: it could reject the UE's PDU session establishment request, or the UE could be forced to re-register and obtain a new Allowed NSSAI. Both outcomes degrade service continuity and user experience, and re-registration is costly in terms of signaling and latency.

The Alternative S-NSSAI solves this by giving the network a graceful degradation path. Instead of failing a request, the AMF can substitute a compatible slice that is available, allowing the service to continue with equivalent or acceptable characteristics. This is particularly valuable for mission-critical services, massive IoT deployments, and scenarios where slice availability fluctuates due to dynamic resource allocation or failures.

The concept also supports operator flexibility: operators can define compatibility relationships between slices (e.g., an enhanced mobile broadband slice and a general-purpose slice) and let the network automatically fall back when the preferred slice is unavailable. This reduces manual intervention, improves resilience, and aligns with the broader 5G goal of dynamic, software-defined network management. Introduced in Rel-19, it reflects the maturation of network slicing from static provisioning toward adaptive, availability-aware slice management.