Home / Call Flows / 5G / Inter-AMF Mobility

5G Inter-AMF Mobility Procedure Call Flow

call-flow 5G NR | 5GC | AMF Change | NAS Mobility | N8

5G Inter-AMF Mobility is the mobility procedure where a UE moves into responsibility of a different AMF while trying to preserve registration and active-session continuity.

The critical distinction is that the mobility anchor in the core changes, not only the radio serving node.

Introduction

This page explains how the source AMF transfers context, how the UE completes Registration Update under the target AMF, and how session continuity is validated afterward.

In practical analysis, the most useful checkpoints are the reason for AMF change, N8 context transfer quality, Registration Request and Accept, and post-transfer session behavior.

What Is Inter-AMF Mobility in Simple Terms?

What starts the procedure: The UE moves or policy changes into a region served by another AMF.
What the UE and network want to achieve: Move AMF ownership cleanly without losing mobility or session continuity.
What success looks like: The target AMF accepts the UE and service remains usable.
What failure means: Context transfer, NAS update, or session continuity breaks during AMF change.

Why this procedure matters

Inter-AMF mobility is where radio movement, NAS registration, and session continuity all meet. If you only inspect one layer, the root cause is easy to miss.

Quick Fact Sheet

Procedure name	5G Inter-AMF Mobility
Domain	5G Core mobility across AMF service regions
Main trigger	UE mobility or policy causes the serving AMF to change
Start state	UE is registered under a source AMF and moves into target-AMF responsibility
End state	UE is successfully anchored under the target AMF with session continuity preserved
Main nodes	UE, source gNB, target gNB, source AMF, target AMF, SMF, UPF
Main protocols	NAS registration update, N2 mobility support, N8 context transfer, session continuity handling
Main success outcome	AMF responsibility changes cleanly and service continues without losing the UE context
Main failure outcome	Context transfer, registration update, or session continuity breaks during the AMF change
Most important messages	Measurement Report or mobility trigger, Registration Request, Registration Accept, context transfer signaling
Main specs	TS 23.502, TS 23.501, TS 24.501

Preconditions

The UE is already registered under a source AMF.
A radio or policy condition requires the target AMF to take ownership.
N8 context transfer is available between source and target AMFs.
Active sessions can be kept aligned through SMF and UPF continuity handling.

Nodes and Interfaces

Nodes involved

Node	Role in this procedure
UE	Moves into the new AMF region and completes the NAS mobility update under the target AMF.
Source gNB	Participates in the radio-side mobility branch before or during AMF change conditions.
Target gNB	Provides the radio anchor after the move into the new AMF region.
Source AMF	Transfers mobility, security, and session-related context toward the new AMF.
Target AMF	Becomes the new mobility anchor for the UE after the change.
SMF / UPF	Preserve or repair session continuity as the mobility anchor changes.

Interfaces used

Interface	Path	Role
NR-Uu	UE <-> gNB	Carries the radio-side mobility and later NAS exchange.
N2	gNB <-> AMF	Carries gNB-to-AMF mobility coordination.
N8	Source AMF <-> target AMF	Transfers UE, security, and mobility context across AMF regions.
N11	AMF <-> SMF	Keeps session-management continuity aligned with the new AMF ownership.

End-to-End Call Flow

UE                Source AMF              Target AMF              SMF / UPF
|                     |                        |                    |
|..... movement into new AMF region ..........|                    |
|                     |-- context transfer --->|------------------->|
|-- Registration Request --------------------->|                    |
|<-- Registration Accept ----------------------|                    |
|==== session continuity should remain usable ====================>|

Major Phases

Phase	What happens
1. Mobility into a new AMF region	Radio or registration-area movement creates the need for a new serving AMF.
2. Source-to-target context transfer	The source AMF shares UE and session-related context with the target AMF.
3. UE NAS update under the target AMF	The UE performs the registration update that makes the new AMF authoritative.
4. Session continuity alignment	SMF and user-plane continuity are validated against the new mobility anchor.
5. Stable post-transfer mobility state	The UE continues service under the target AMF without stale source context.

Step-by-Step Breakdown

A movement or policy event requires AMF change

Sender -> receiver: UE mobility path -> source network

Message(s): Mobility trigger and region change condition

Purpose: Recognize that the current AMF should no longer be the mobility anchor.

State or context change: The mobility branch becomes an inter-AMF case rather than only a radio move.

Note: Not every radio handover is inter-AMF. The AMF region boundary or policy decision is the key distinction.

The source AMF transfers context to the target AMF

Sender -> receiver: Source AMF -> target AMF

Message(s): N8 context transfer

Purpose: Move mobility, security, and session-related context before the target AMF takes ownership.

State or context change: The target AMF becomes prepared to serve the UE.

Note: If the N8 transfer is weak or incomplete, later NAS failures often get blamed on the UE incorrectly.

The UE performs Registration Update toward the target AMF

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

Message(s): Registration Request

Purpose: Make the new AMF the active mobility anchor from the UE perspective.

State or context change: The UE transitions from source-AMF ownership to target-AMF ownership.

Note: Use the registration type and identity handling to confirm this was a mobility-driven update, not an unrelated NAS branch.

The target AMF accepts the UE context

Sender -> receiver: Target AMF -> UE

Message(s): Registration Accept

Purpose: Confirm the UE is now served by the new AMF and can continue normally.

State or context change: The core-mobility anchor change becomes visible to the UE as complete.

Note: Registration Accept is the main NAS success checkpoint, but session continuity still needs separate validation.

Session continuity and stale-source cleanup are validated

Sender -> receiver: Target AMF <-> SMF / UPF

Message(s): Session continuity checks and source cleanup

Purpose: Ensure the AMF change did not leave stale source state or break active sessions.

State or context change: The inter-AMF mobility branch ends in stable target-side ownership.

Note: A clean AMF transfer with broken data continuity is still only a partial success.

Important Messages in This Flow

Message	Protocol	Direction	Purpose in this procedure	What to inspect briefly
Registration Request	NAS	UE -> target AMF via target gNB	Starts the UE-visible ownership change toward the target AMF.	Check mobility-driven registration type and UE identity context.
Registration Accept	NAS	Target AMF -> UE	Confirms the new AMF now serves the UE.	Primary NAS success sign for the transfer.
Context transfer signaling	Core control	Source AMF -> target AMF	Moves mobility, security, and session context across AMFs.	This is where hidden root causes often live.
Session continuity validation	Core / user plane	Target AMF, SMF, UPF	Proves active services stayed aligned after the AMF move.	Needed to go beyond pure NAS success.

Important Parameters to Inspect

Parameter	What it is	Where it appears	Why it matters	Common issues
AMF region or selection reason	Why the target AMF should take ownership.	Pre-transfer decision stage	Explains why this is truly inter-AMF mobility.	Without it, the move can be misclassified.
UE identity continuity	How the target AMF recognizes and accepts the UE.	Registration Request and context transfer	Critical for correct NAS completion.	Identity mismatch is a frequent failure source.
Security context transfer	Whether the target AMF got the right security state.	N8 transfer and NAS protection	Important for successful protected NAS exchange.	Security mismatch creates confusing downstream failures.
Registration outcome	Whether the target AMF accepted the mobility update.	Registration Accept / Reject path	Main NAS result of the AMF change.	Do not stop there if sessions are active.
Post-transfer session continuity	Whether active sessions remained usable after the AMF change.	SMF / UPF validation	Separates pure mobility-anchor success from end-to-end success.	This is often the hidden user impact point.

Success Criteria

The target AMF is selected for a valid reason and receives correct context.
The UE completes Registration Update toward the target AMF cleanly.
Security and identity continuity remain intact.
Sessions remain usable after the AMF change.

Common Failures and Troubleshooting

Symptom	Likely cause	Where to inspect	Relevant message(s)	Relevant interface(s)	Likely next step
Context transfer is incomplete or wrong	The target AMF does not receive enough valid state from the source AMF.	N8 transfer details and later NAS behavior.	Context transfer stage	N8	Often surfaces later as NAS or session trouble.
Registration Update fails at the target AMF	The UE reaches the new area but cannot complete the ownership change.	Registration Request, identity handling, and NAS protection.	Registration Request / Reject	N1, N2	This is the clearest NAS failure branch.
AMF change completes but sessions break	Mobility-anchor transfer succeeded but session continuity did not.	Registration Accept plus post-transfer traffic and SMF alignment.	Registration Accept and later traffic	N11, N3	Do not call this a full success.
Source state remains stale after transfer	Old AMF-side assumptions or cleanup issues persist after the change.	Source-versus-target ownership and cleanup timing.	Post-transfer control state	N8, N11	Can create confusing duplicate or inconsistent behavior.

What to Check in Logs and Traces

Start by proving why the AMF changed.
Inspect the N8 context transfer before blaming the UE or radio path.
Use Registration Request and Registration Accept as the main NAS checkpoints.
Validate security and identity continuity through the change.
Check post-transfer session behavior so you do not mistake NAS success for full success.

Related sub-procedures

Related message reference pages

Related troubleshooting pages

FAQ

What is 5G Inter-AMF Mobility?

It is the mobility procedure where UE ownership moves from one AMF to another.

Is it always tied to handover?

Often it is associated with mobility, but the key feature is the AMF ownership change, not just the radio move.

What proves success?

The target AMF accepts the UE and active sessions remain usable afterward.

What should I inspect first?

Start with why the AMF changed, then the N8 context transfer, then Registration Request and Accept.

Why can service still fail after Registration Accept?

Because AMF-anchor success does not automatically prove session continuity and data-plane alignment.