Home / Call Flows / 5G / Slice Mobility Procedure

5G Slice Mobility Procedure

call-flow 5G NR | Slice Mobility | NSSAI | AMF | Allowed NSSAI

5G Slice Mobility Procedure explains how slice availability changes when a UE moves between areas, tracking domains, or policy regions.

The key idea is simple: radio mobility success does not guarantee slice continuity success. The UE may move cleanly and still lose the slice it expected to use afterward.

Introduction

This page is most useful when service works in one area and fails in another, or when movement triggers a subtle change in Allowed NSSAI that only becomes visible during later service use.

In practice, the most important checks are the Allowed NSSAI before movement, the Allowed NSSAI after movement, and the first post-mobility service request that tries to use the slice.

What Is Slice Mobility Procedure in Simple Terms?

What starts the procedure: The UE moves into a new area where slice availability may differ.
What the UE and network want to achieve: Preserve a usable slice context across movement or update it correctly.
What success looks like: The UE stays allowed on the expected slice and real service still works after movement.
What failure means: Movement succeeds but slice continuity changes or breaks afterward.

Why this procedure matters

Slice mobility is where location, policy, and service intent finally meet. If it is misdiagnosed as pure handover trouble, the real cause stays hidden.

Quick Fact Sheet

Procedure name	5G Slice Mobility Procedure
Domain	Slice continuity and Allowed NSSAI refresh during UE movement
Main trigger	The UE moves into a new area where slice availability or policy may differ
Start state	UE already has slice context but movement may invalidate or change it
End state	The UE keeps, loses, or changes slice access based on the new serving context
Main nodes	UE, gNB, AMF, NSSF, SMF
Main protocols	Mobility Registration Update, Allowed NSSAI refresh, slice-aware session validation
Main success outcome	Movement completes and the UE retains a usable slice context in the new area
Main failure outcome	Mobility succeeds at radio level but slice continuity breaks afterward
Most important messages	Registration Request (Mobility Updating), Registration Accept, Allowed NSSAI
Main specs	TS 23.501, TS 23.502, TS 24.501, TS 29.531

Preconditions

The UE already has valid slice context before movement.
The UE moves into a new area that may have different slice support or policy.
The network can return refreshed Allowed NSSAI during mobility update handling.
Later service procedures can confirm whether continuity survived the move.

Nodes and Interfaces

Nodes involved

Node	Role in this procedure
UE	Moves into a new area and triggers update handling if the old slice context may no longer be valid.
gNB	Provides the new access path and relays the update signaling after movement.
AMF	Refreshes the mobility and slice context for the UE in the new area.
NSSF	May help determine whether the same slice remains suitable in the new serving area.
SMF	Later proves whether the refreshed slice context still supports actual service and session behavior.

Interfaces used

Interface	Path	Role
NR-Uu	UE <-> gNB	Carries the access and signaling restoration needed after movement.
N1	UE <-> AMF	Carries the mobility update and the refreshed Allowed NSSAI result.
N2	gNB <-> AMF	Relays the new access context after movement.
N22 / policy path	AMF <-> NSSF or related functions	Supports slice re-evaluation in the new area where applicable.

End-to-End Call Flow

UE                gNB                AMF              NSSF / policy
|-- move to new area -->|                  |                    |
|-- Registration Request ----------------->|                    |
|                                          |-- slice check ---->|
|                                          |<-- slice result ---|
|<-- Registration Accept (updated Allowed NSSAI) -------------|
|==== post-mobility service validates continuity =============>|

Major Phases

Phase	What happens
1. Movement changes serving context	The UE enters a new tracking or policy area where slice availability may differ.
2. Mobility update starts	The UE sends mobility-related update signaling and the network refreshes location context.
3. Slice context is re-evaluated	The serving network decides whether the old slice can remain available in the new area.
4. Service continuity is validated	Later service requests prove whether the refreshed slice context still works.

Step-by-Step Breakdown

UE moves into a new area with potentially different slice availability

Sender -> receiver: UE movement -> serving gNB / AMF context

Message(s): Area change leading to mobility update

Purpose: Trigger slice and registration re-evaluation after movement.

State or context change: The UE may still be radio-reachable, but its old slice assumptions are no longer guaranteed.

Note: This is where engineers must separate radio mobility success from slice continuity success.

UE sends mobility Registration Request

Sender -> receiver: UE -> gNB -> AMF

Message(s): Registration Request with mobility updating type

Purpose: Refresh the registration and reachability context after movement.

State or context change: The AMF now has a chance to refresh Allowed NSSAI for the new serving environment.

Note: If the issue only appears after movement, this update is the first slice-context checkpoint to inspect.

The network re-evaluates slice availability in the new area

Sender -> receiver: AMF <-> NSSF / policy functions

Message(s): Allowed NSSAI refresh and slice suitability checks

Purpose: Determine whether the UE can keep the same slice after movement or must change to a different allowed set.

State or context change: The new serving area becomes the authority for what slice behavior is still valid.

Note: Engineers often miss this because the mobility update may look clean while the slice result quietly changes underneath it.

Later service requests validate post-mobility slice continuity

Sender -> receiver: UE -> AMF / SMF

Message(s): PDU Session Establishment Request or later service signaling after movement

Purpose: Show whether the refreshed slice context still supports real service in the new area.

State or context change: The slice result becomes visible through real service continuity, not only through the update result itself.

Note: A successful mobility update with broken post-mobility service usually points to slice continuity trouble rather than radio failure.

Important Messages in This Flow

Message	Protocol	Direction	Purpose in this procedure	What to inspect briefly
Registration Request	NAS	UE -> AMF	Starts the mobility update that can also refresh slice context.	Inspect mobility updating type and any slice-related context carried with the update.
Registration Accept	NAS	AMF -> UE	Returns refreshed mobility and Allowed NSSAI context.	Compare pre-mobility and post-mobility Allowed NSSAI carefully.
PDU Session Establishment Request	NAS	UE -> core	Later proves whether slice continuity actually survived the move.	Use this as the operational proof rather than relying only on the update result.

Important Parameters to Inspect

Parameter	What it is	Where it appears	Why it matters	Common issues
Pre-mobility Allowed NSSAI	The slice set available before the move.	Before movement	Provides the baseline for continuity comparison.	Without the baseline, post-mobility changes are easy to miss.
Post-mobility Allowed NSSAI	The slice set returned after the move.	Registration Accept after movement	Shows whether the slice context stayed the same, changed, or shrank.	Unexpected changes here explain later service breaks quickly.
Area and TAI context	The serving-area information associated with the movement.	Mobility update path	Explains why the slice result may differ by location.	Area-specific policy can look like random failure if location context is ignored.
AMF or policy domain change	Whether the control context itself changed after movement.	During or after mobility update	Can explain different slice behavior even with similar radio conditions.	A new AMF or policy domain may apply different slice handling.
Post-mobility session behavior	Whether real service still works on the expected slice.	After movement	This is the practical proof of slice continuity.	Registration can succeed while service continuity still breaks.

Success Criteria

The mobility update reflects the new serving area correctly.
Allowed NSSAI stays consistent with the intended slice or changes in an explainable way.
Later service requests still match the refreshed slice context.
The UE continues to use the expected slice after movement.

Common Failures and Troubleshooting

Symptom	Likely cause	Where to inspect	Relevant message(s)	Relevant interface(s)	Likely next step
The slice disappears after movement	The new area no longer allows the slice or applies different policy.	Allowed NSSAI before and after movement.	Registration Accept after move	N1, policy domain	This is the classic slice-mobility symptom.
Mobility succeeds but service fails afterward	Radio movement completed, but the refreshed slice context no longer supports the intended service.	Post-mobility Allowed NSSAI and later session request.	Registration Accept, PDU Session Establishment Request	N1, N11	This is not mainly a handover failure.
Neighboring areas behave differently	Slice deployment or policy differs by location or AMF domain.	TAI, AMF, and Allowed NSSAI changes.	Registration Accept after movement	Area-specific slice policy	A repeatable geography pattern is a strong clue.
AMF change alters slice behavior unexpectedly	The new control domain applies different slice-selection logic.	AMF continuity and slice result.	Mobility update path	Control-plane domain	This is often blamed on the UE even though the policy domain changed.

What to Check in Logs and Traces

Compare pre-mobility and post-mobility Allowed NSSAI directly.
Use TAI and AMF context to explain why the result may have changed.
Separate radio mobility success from slice continuity success.
Validate the outcome with the first post-mobility service request on the expected slice.

Related sub-procedures

Related message reference pages

Related troubleshooting pages

FAQ

What is Slice Mobility Procedure?

It is the slice-continuity procedure that explains what happens to slice access after the UE moves into a new serving context.

Is this just radio mobility?

No. Radio mobility is only part of it. The key question is whether the same slice remains allowed and usable afterward.

What should I inspect first?

Start with Allowed NSSAI before and after the move, then check whether later service still uses the expected slice.

Why can service fail after a successful mobility update?

Because the network may accept the mobility update while still changing the slice result in the new area.

When is this especially important?

When service works in one area and breaks after movement into another area or AMF domain.