Home / Call Flows / 5G / NTN Handover / Mobility Handling

5G NTN Handover / Mobility Handling Call Flow

call-flow 5G NR | NTN | Mobility | Handover | Continuity

5G NTN Handover / Mobility Handling explains how service is preserved when an NTN-served UE changes serving context.

It combines NTN-aware mobility preparation, execution signaling, and post-move service validation into one continuity procedure.

Introduction

This page picks up after NTN registration and focuses on what happens when the UE must keep service across a non-terrestrial mobility event.

The winning troubleshooting pattern is to follow the move from source context to target context, then verify that the session path and first packets really converged afterward.

What Is NTN Handover / Mobility Handling in Simple Terms?

What starts the procedure: The UE needs to move between NTN serving contexts while keeping service alive.
What the UE and network want to achieve: Preserve continuity across the NTN mobility transition.
What success looks like: The UE moves cleanly and service works in the new context.
What failure means: Execution appears fine but post-mobility service does not recover correctly.

Why this procedure matters

In NTN, mobility success is not just about access movement. It is about whether the new context can actually carry service under unusual timing and path constraints.

Quick Fact Sheet

Procedure name	5G NTN Handover / Mobility Handling
Domain	5G non-terrestrial mobility continuity and service preservation
Main trigger	A UE on NTN service experiences movement, beam change, satellite coverage transition, or access-context change that requires mobility handling
Start state	UE is already registered and in service over an NTN-aware access path
End state	Service continuity is preserved or cleanly re-established under the new NTN mobility context
Main nodes	UE, NTN access node, source and target access context, AMF, SMF, UPF
Main protocols	RRC-like mobility control, NGAP-like access coordination, NAS service continuity signaling, PFCP as needed
Main success outcome	The UE keeps or restores service while the network updates the NTN mobility context cleanly
Main failure outcome	Mobility control appears to progress, but timing, path state, or service continuity fails during the NTN transition
Most important messages	Mobility preparation and execution signaling, path update handling, Service Request or recovery signaling when needed
Main specs	TS 23.501, TS 23.502, NTN mobility adaptations, TS 38.300 family

5G NTN Handover and Mobility Handling call flow

Preconditions

The UE already has active NTN service.
A viable target NTN context can be prepared.
The network can update session continuity after the move.
Post-mobility traffic is available to validate the result.

Nodes and Interfaces

Nodes involved

Node	Role in this procedure
UE	Experiences NTN coverage or mobility changes and must preserve service under non-terrestrial timing and continuity assumptions.
Source NTN access context	Holds the pre-mobility service path and related access state.
Target NTN access context	Becomes the new service anchor after the mobility event.
AMF	Coordinates control-plane continuity for the mobility transition.
SMF	Ensures the session path still matches the new access state after mobility.
UPF	Supports the continued or recovered data path after NTN mobility handling.

Interfaces used

Interface	Path	Role
NTN radio access path	UE <-> source/target NTN access	Carries the mobility-sensitive access behavior.
N2-like access coordination	Access context <-> AMF	Coordinates mobility-control and continuity updates.
N11	AMF <-> SMF	Connects mobility outcome to session continuity decisions.
N4 / user-plane path	SMF <-> UPF and access <-> UPF	Update or validate the active session path after the NTN movement.
N1	UE <-> AMF	May carry service-recovery or continuation signaling if the mobility event needs higher-layer help.

End-to-End Call Flow

UE            source NTN         target NTN           AMF / SMF / UPF
|                  |                  |                    |
|==== active service on source context ====================>|
|---- mobility trigger ------------------------------------>|
|                  |---- prepare ------>|                    |
|                  |<--- execute ------>|                    |
|==== service should continue on target NTN context ======>|

Major Phases

Phase	What happens
1. NTN mobility trigger	Coverage movement, beam change, orbital geometry, or service-area change pushes the UE toward a new access context.
2. Mobility preparation	The network prepares the target context and continuity expectations.
3. Mobility execution	The UE transitions toward the new NTN serving context.
4. Path and service validation	The network checks that session continuity still works after the move.
5. Stable post-mobility NTN service	The UE continues service or uses follow-up recovery procedures where needed.

Step-by-Step Breakdown

The UE reaches an NTN mobility boundary

Sender -> receiver: UE with source NTN access context

Message(s): Mobility trigger based on coverage or service movement

Purpose: Identify that the current NTN context is no longer ideal for continued service.

State or context change: The UE moves from stable NTN service toward a mobility transition window.

Note: In NTN, timing and geometry-related movement can matter as much as conventional cell change.

The target access context is prepared

Sender -> receiver: Source / target NTN context <-> AMF

Message(s): Mobility preparation signaling

Purpose: Create the next serving context before the UE commits to the change.

State or context change: The network has a candidate target context ready for service continuation.

Note: A weak target preparation stage often explains why later continuity fails even if the move itself seems clean.

The UE executes the mobility transition

Sender -> receiver: Source NTN context -> target NTN context

Message(s): Mobility command, execution, and access reattachment behavior

Purpose: Move the UE to the new serving context while minimizing service disruption.

State or context change: The pre-mobility service path is replaced or reanchored toward the target context.

Note: Do not judge success only by execution signaling. Post-mobility service is the real checkpoint.

The network validates path continuity

Sender -> receiver: AMF <-> SMF <-> UPF and UE traffic

Message(s): Path updates, PFCP changes, or service recovery signaling

Purpose: Make sure the session path and access path still agree after the move.

State or context change: Service becomes either healthy again or clearly degraded after mobility.

Note: This is where many NTN mobility failures hide, especially when timing and path convergence are tight.

Later service is monitored under the new NTN context

Sender -> receiver: UE <-> target access <-> UPF

Message(s): Post-mobility packets and ongoing service observation

Purpose: Confirm that the move delivered not only signaling success but lasting service continuity.

State or context change: The NTN mobility event settles into normal service or escalates into a recovery procedure.

Note: A trace that ends at handover execution misses the most important part of the procedure.

Important Messages in This Flow

Message	Protocol	Direction	Purpose in this procedure	What to inspect briefly
Mobility preparation signaling	Access / control	Source and target context <-> AMF	Builds the new NTN serving context before execution.	Anchor the transition timing here.
Mobility execution signaling	Access / control	Network -> UE	Moves the UE to the new NTN service context.	Useful for separating preparation failure from execution failure.
Path update or PFCP change	Control / PFCP	AMF/SMF/UPF	Aligns the session path with the new access-side reality.	Best proof that service continuity was addressed, not only access movement.
First post-mobility packets	User plane	UE <-> target access <-> UPF	Prove whether the new NTN context actually carries service.	This is the final success checkpoint.

Important Parameters to Inspect

Parameter	What it is	Where it appears	Why it matters	Common issues
Source and target NTN context	Serving access state before and after the move.	Mobility preparation and execution	Needed to prove what changed during the event.	Weak correlation makes the trace unreadable.
Mobility trigger reason	Why the NTN transition happened.	Preparation context	Explains whether the move was expected or reactive.	Missing trigger context leads to wrong assumptions.
Session continuity state	How the active session should survive the transition.	AMF / SMF / UPF updates	Core test of success after NTN mobility.	Service continuity is often the real failure domain.
Post-mobility timing	Delay between move and restored service.	Execution and first packets	Important in NTN where propagation and access timing are already unusual.	Long gaps may still be unacceptable even if service returns.
Residual old-path state	Any source-side context still carrying traffic after the move.	Post-mobility observation	Shows whether cleanup and reanchoring were complete.	Residual state can create ghost failures.

Success Criteria

The target NTN context is prepared with the right continuity assumptions.
The UE completes the serving-context change cleanly.
Session and path state converge after the move.
Post-mobility packets confirm stable service in the target context.

Common Failures and Troubleshooting

Symptom	Likely cause	Where to inspect	Relevant message(s)	Relevant interface(s)	Likely next step
Mobility control completes but service is lost	The access move happened, but session continuity or path validation failed afterward.	Path updates and first post-mobility packets.	Execution plus post-mobility validation	N4, user plane	This is the classic hidden mobility-continuity failure.
The UE oscillates between NTN contexts	Target stability or mobility policy is too weak for a clean transition.	Repeated preparation and execution cycles.	Mobility preparation / execution	Access path	Repeated movement is a real service-quality issue.
Old path remains active after the move	Cleanup of the source context is incomplete.	Residual source traffic and path state.	Post-mobility observation	User plane	This can cause duplicate or stale service behavior.
Mobility delay is technically successful but operationally poor	The procedure converged, but too slowly for the service profile carried over NTN.	Move timing, service interruption, and packet gap.	End-to-end timing	Access path, user plane	Success needs to be measured against service continuity, not only protocol completion.

Related sub-procedures

Related message reference pages

Related troubleshooting pages

FAQ

What is NTN Handover / Mobility Handling?

It is the set of procedures that preserve or restore service when an NTN-served UE changes serving context.

Is it just normal handover with a different radio?

No. The core mobility logic is familiar, but NTN timing, coverage geometry, and path convergence make the operational behavior different.

What proves success?

The new NTN context carries stable service after the move, not just a clean execution message.

What should I inspect first?

Start with the source and target context, the mobility trigger, and the first packets after the transition.

Why is this page separate from NTN registration?

Because registration proves access entry, while this page focuses on preserving continuity after the UE is already in service.