5G Slice Mobility Procedure Explained
Introduction
The Slice Mobility Procedure describes what happens to slice access when a UE moves between cells, tracking areas, or service regions and the available S-NSSAIs may change.
In practice, this is where engineers check whether the UE keeps the expected slice after mobility, whether the Allowed NSSAI is updated correctly, and whether later session procedures still align with the new serving area.
This page is most useful when read together with Network Slice Selection, Slice Authentication, and 5G Mobility Registration Update.
The main procedural references are:
- 3GPP TS 23.501 - System Architecture for the 5G System
- 3GPP TS 23.502 - 5G System Procedures
- 3GPP TS 24.501 - NAS Protocol
What Slice Mobility Means
Slice mobility is not just radio mobility. It is the service-level question of whether the UE can continue using the same slice after it moves into a different area or serving context.
| Mobility aspect | Why it matters |
|---|---|
| Tracking area change | Often triggers Mobility Registration Update, where allowed slice information may be refreshed. |
| Allowed NSSAI refresh | The network may remove, replace, or preserve slices depending on coverage and policy in the new area. |
| Session continuity | Existing or future PDU sessions may fail if the required slice is no longer available. |
| AMF or policy domain change | Different AMF or service-region logic can alter slice behavior after mobility. |
Network Functions Involved
| Network Function | Role in slice mobility |
|---|---|
| UE | Moves into a new area and triggers registration update or service continuity checks. |
| gNB | Provides the new access context and system information for the moved UE. |
| AMF | Updates mobility context and may refresh allowed slice information for the UE. |
| NSSF | May help determine slice suitability in the new serving area. |
| SMF | Later reflects whether slice continuity still works for session establishment or modification. |
Slice Mobility Call Flow Position
UE gNB AMF NSSF / Policy
| | | |
|-- Move to new area ----------->| |
|-- Registration Request ------->| |
| (Mobility Update) | |
| |--------------->| |
| | |-- slice check -->|
| | |<-- slice result -|
|<-- Registration Accept --------| |
| (Updated Allowed NSSAI) | | The important point is that mobility itself is often successful, but the slice result after mobility may still change and affect later service use.
Step-by-Step Slice Mobility Procedure
Step 1: UE Moves into a New Service Area
The UE enters a new tracking area or policy region where the available slice set may differ from the previous one.
What to inspect
- New TAI / tracking area
- Serving PLMN
- Whether the move crosses an operator-defined slice availability boundary
Step 2: Mobility Registration Update Is Triggered
If the new area is outside the current registration area list, the UE performs Mobility Registration Update.
This is usually the point where the network can refresh the allowed slice set.
What to inspect
- Registration type = mobility updating
- Requested NSSAI in the update
- Whether the UE is carrying stale configured slice information
Step 3: Network Re-evaluates Slice Availability
The AMF and related functions determine whether the UE can keep the same slice in the new area.
What to inspect
- Allowed NSSAI before and after mobility
- Any rejected or missing S-NSSAI values
- AMF change or policy domain change
Step 4: Later Service Procedures Confirm the Result
After mobility, the real test is whether the UE can still use the intended slice for service procedures such as PDU Session Establishment.
What to inspect
- PDU session requested S-NSSAI after mobility
- DNN / slice combination
- Whether session rejection started only after the area change
Common Failure Patterns
| Failure pattern | Typical engineering meaning |
|---|---|
| Slice disappears after movement | The new area does not support that slice or the subscriber is not authorized there. |
| Registration update succeeds but service fails | Mobility succeeded, but the slice no longer matches DNN or session policy. |
| Different behavior across neighboring areas | Slice deployment, policy, or AMF handling is inconsistent between regions. |
| Unexpected Allowed NSSAI after AMF change | The new AMF or policy domain is applying different slice selection logic. |
What to Check in Logs and Traces
- Allowed NSSAI before mobility and after mobility update.
- Any change in AMF, TAI list, or serving PLMN.
- Requested NSSAI sent during the update.
- Whether the later PDU session request uses a slice that is no longer allowed.
- Whether the issue is area-specific and repeatable by location.
Related Procedures
Recommended Reference Specifications
- 3GPP TS 23.501 - System Architecture for the 5G System
- 3GPP TS 23.502 - 5G System Procedures
- 3GPP TS 24.501 - NAS Protocol
- 3GPP TS 29.531 - NSSF Services and APIs