Home / Call Flows / 5G / Session Recovery after Mobility / Path Switch

5G Session Recovery after Mobility / Path Switch Call Flow

call-flow 5G NR | 5GC | Mobility | Path Switch | SMF | UPF

5G Session Recovery after Mobility / Path Switch focuses on what happens to an active data session after a mobility event changes the serving access path.

The key engineering job is to prove that traffic moved to the new path correctly and that stale state did not survive on the old one.

Introduction

This page is for the post-handover part of the story: the session may have existed before the move, but it still needs recovery or validation afterward.

In practical troubleshooting, the strongest checkpoints are the affected PDU Session ID, the old and new path state, PFCP updates, and the first real packets after mobility.

What Is Session Recovery after Mobility / Path Switch in Simple Terms?

What starts the procedure: A mobility event changes the serving path of an active session.
What the UE and network want to achieve: Restore or validate the session on the new path without losing service.
What success looks like: Traffic continues on the target path and the source path is cleaned up.
What failure means: The path switch is stale, broken, partial, or applied to the wrong session.

Why this procedure matters

Many mobility incidents are really session-recovery incidents. A successful handover headline can hide a completely broken post-move data path.

Quick Fact Sheet

Procedure name	5G Session Recovery after Mobility / Path Switch
Domain	5G NR + 5GC post-mobility session recovery and path repair
Main trigger	Mobility or path switch leaves an active session needing validation or repair
Start state	UE had an active session before mobility, but post-handover continuity is uncertain or degraded
End state	The session is validated or repaired and the post-mobility path carries traffic correctly
Main nodes	UE, source and target gNB, AMF, SMF, UPF
Main protocols	Mobility signaling, NGAP, NAS as needed, PFCP, user-plane validation
Main success outcome	The session survives the mobility event and traffic continues over the correct new path
Main failure outcome	The handover succeeds, but the session path is stale, broken, or inconsistently updated
Most important messages	Handover-related signaling, path-switch updates, PFCP changes, Service Request or session updates when needed
Main specs	TS 23.502, TS 23.501, TS 38.300

5G Session Recovery after Mobility and Path Switch procedure flow

Preconditions

A valid active PDU session existed before mobility.
A mobility event or handover changed the serving access path.
The network can update the session path toward the new serving node.
Traffic checks are available to validate the recovered path.

Nodes and Interfaces

Nodes involved

Node	Role in this procedure
UE	Keeps service active while the network repairs or validates the moved session path.
Source gNB	Participates in the mobility transition and hands context away.
Target gNB	Becomes the serving access node and depends on correct path-switch completion.
AMF	Coordinates mobility control and any related session recovery signaling.
SMF	Repairs or confirms the post-mobility session path.
UPF	Must forward traffic toward the correct new access-side anchor after mobility.

Interfaces used

Interface	Path	Role
NR-Uu	UE <-> target gNB	Carries the recovered service after mobility.
N2	gNB <-> AMF	Carries mobility and path-switch coordination.
N11	AMF <-> SMF	Connects mobility outcome to session recovery logic.
N4 / N3	SMF <-> UPF and target gNB <-> UPF	Re-anchor or validate the user-plane path after mobility.
N1	UE <-> AMF	May be used if additional recovery signaling is needed from the UE side.

End-to-End Call Flow

UE          source gNB        target gNB           AMF / SMF / UPF
|                |                  |                    |
|==== active traffic on source path ====================>|
|---- mobility / handover ------------------------------>|
|                |----------------->|                    |
|                |                  |<-- path switch ----|
|==== traffic should continue on target path ==========>|

Major Phases

Phase	What happens
1. Mobility event completes	The UE moves, but continuity of the session still needs validation.
2. Path-switch or recovery decision	The network determines whether the session path is healthy after the move.
3. Session path repair	SMF and UPF update the forwarding state toward the new serving access path.
4. UE/service validation	Traffic checks whether the recovered path is operational.
5. Stable post-mobility service	The session continues correctly after the transition.

Step-by-Step Breakdown

A mobility event changes the serving access path

Sender -> receiver: Source gNB -> target gNB with AMF coordination

Message(s): Handover and path-switch-related signaling

Purpose: Move the UE while preserving or later restoring the active session.

State or context change: The session enters a post-mobility validation phase.

Note: A successful handover does not automatically prove a healthy data session afterward.

The network checks whether the old path is still valid

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

Message(s): Post-mobility session evaluation

Purpose: Identify whether the pre-mobility user-plane path must be changed or repaired.

State or context change: The core decides if the session is healthy, stale, or partially updated.

Note: This is the step that separates clean continuity from hidden stale-path failures.

The path switch or recovery update is applied

Sender -> receiver: SMF <-> UPF and target gNB

Message(s): PFCP update and path-switch-related transport update

Purpose: Point the session toward the correct post-mobility access anchor.

State or context change: The moved session becomes aligned to the new access side.

Note: Look for old and new path identifiers side by side whenever possible.

The UE or network validates recovered traffic

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

Message(s): First packets after mobility and any related recovery signaling

Purpose: Prove the session is usable on the new path.

State or context change: The session becomes either healthy again or clearly broken.

Note: Post-handover packets are often more revealing than the control-plane success message.

Residual stale state is checked

Sender -> receiver: Source and target path monitoring

Message(s): Old-path and new-path observation

Purpose: Confirm that the source path is cleaned up and the target path owns the service.

State or context change: The network reaches a stable post-mobility state.

Note: Residual source-path traffic is a strong sign of incomplete session recovery.

Important Messages in This Flow

Message	Protocol	Direction	Purpose in this procedure	What to inspect briefly
Handover-related signaling	NGAP / RAN	Source gNB, target gNB, AMF	Explains why the session path needed recovery or validation.	Use it to anchor the timing of the event.
Path-switch update	Control / transport	AMF, SMF, target gNB	Moves the session toward the new access side.	Critical for understanding the transition.
PFCP session update	PFCP	SMF <-> UPF	Repairs the user-plane anchor after mobility.	Best view of whether the data path was actually updated.
First post-mobility packets	User plane	UE <-> target path	Validate service continuity after the move.	This is the real success measure.

Important Parameters to Inspect

Parameter	What it is	Where it appears	Why it matters	Common issues
Affected PDU Session ID	Session being recovered after mobility.	All related traces	Keeps the analysis tied to the correct session.	Wrong session correlation is common in mobility cases.
Source and target path identifiers	Old and new access anchors for the session.	Mobility and PFCP updates	Reveal whether the path really moved.	Without them, stale-path issues are hard to prove.
Recovery timing	Delay between mobility event and restored traffic.	Post-handover observation	Important for judging service continuity quality.	Long gaps are operationally significant.
QoS after mobility	Service treatment after the path switch.	Post-recovery state	Shows whether continuity is not only alive but correct.	Changed QoS can masquerade as path failure.
Residual source-path traffic	Any traffic still using the old path.	After recovery	Strong indicator of incomplete cleanup.	Should not be ignored.

Success Criteria

The correct active session is recovered after mobility.
The user-plane path is updated toward the target serving access side.
Traffic continues over the target path with acceptable quality.
Residual source-path state is removed cleanly.

Common Failures and Troubleshooting

Symptom	Likely cause	Where to inspect	Relevant message(s)	Relevant interface(s)	Likely next step
Handover succeeds but data stops	The mobility control plane completed, but session recovery failed.	Post-handover PFCP state and first packets.	Path-switch updates	N3, N4, N2	This is the classic post-handover session failure.
Traffic partially works with high loss or delay	Recovery is incomplete or QoS changed unexpectedly during the move.	Timing, QoS, and transport state after mobility.	Post-recovery traffic	NR-Uu, N3	Treat degraded continuity as a real failure case.
Source path remains active	Old forwarding state was not cleaned up fully.	Residual source-path traffic and PFCP cleanup.	Post-recovery observation	N4, source path	This can create duplicated or misrouted traffic.
The wrong session is repaired	Recovery actions were applied to a different active session.	PDU Session ID correlation across mobility and PFCP traces.	All related signaling	N11, N4	Always verify this early in multi-session traces.

What to Check in Logs and Traces

Anchor everything on the affected PDU Session ID.
Record the mobility event timing before reading post-event traffic behavior.
Inspect PFCP updates to see whether the user-plane anchor really moved.
Compare source-path vs target-path traffic after the event.
Treat degraded continuity, not only total outage, as a real recovery problem.

Related sub-procedures

Related message reference pages

Related troubleshooting pages

Notes

Post-handover traffic is the truth source. If the session does not behave correctly on the target path, the recovery is not complete no matter how clean the control plane looks.

FAQ

What is Session Recovery after Mobility / Path Switch?

It is the set of actions that validate or repair a PDU session after the UE moves and the serving path changes.

Is this just handover?

No. Handover moves the UE, but session recovery proves the data path still works afterward.

What proves success?

Traffic moves to the new path, the old path is cleaned up, and service continues correctly.

What should I inspect first?

Start with the affected session ID, the path-switch timing, and the first packets after mobility.

Why can the session fail after a successful handover?

Because control-plane mobility completion does not guarantee user-plane path recovery.