Home / Call Flows / 5G / ATSSS Traffic Switching

5G ATSSS Traffic Switching Call Flow

call-flow 5G NR | ATSSS | Multi-Access | Traffic Switching | Continuity

5G ATSSS Traffic Switching is the multi-access procedure that moves active traffic completely from one access path to another.

It combines switching policy, target-path preparation, and post-move continuity validation into one service-migration workflow.

Introduction

This page is useful when a session should leave one access entirely and continue on another, such as moving from a degraded path to a healthier one.

The best analysis pattern is to identify the source path, the target path, the moment of movement, and whether any old-path traffic survived afterward.

What Is ATSSS Traffic Switching in Simple Terms?

What starts the procedure: The network decides that traffic should move fully to a different access path.
What the UE and network want to achieve: Complete a clean path migration without breaking service.
What success looks like: Traffic leaves the old path and continues stably on the new one.
What failure means: Traffic is stranded, duplicated, or unstable during or after the move.

Why this procedure matters

Switching is one of the clearest operational ATSSS events because packet movement should be visible. A good page helps separate true switching from half-complete migration or accidental splitting.

Quick Fact Sheet

Procedure name	5G ATSSS Traffic Switching
Domain	5G multi-access traffic movement from one active access path to another
Main trigger	Policy or service conditions require full session traffic to move from one access path to another
Start state	ATSSS-capable service exists and traffic is already flowing over one active access path
End state	Traffic is fully moved to the target access while session continuity is preserved
Main nodes	UE, gNB, non-3GPP access, AMF, SMF, UPF, policy functions
Main protocols	NAS, policy control, session update, user-plane path validation
Main success outcome	All relevant traffic leaves the old access and continues on the new target access cleanly
Main failure outcome	Traffic is duplicated, partially stranded, or falls into instability while the switch is attempted
Most important messages	Policy-driven session updates, path-state updates, live packet movement from source path to target path
Main specs	TS 23.501, TS 23.502, ATSSS architecture and policy behavior

Preconditions

The UE and network support ATSSS multi-access behavior.
A session is already active on at least one access path.
A valid target access path is available for the switch.
Policy logic has a clear reason to prefer full movement.

Nodes and Interfaces

Nodes involved

Node	Role in this procedure
UE	Moves its active traffic behavior from the old access path to the newly preferred one.
Current source access	Carries the session traffic before the switch begins.
Target access	Becomes the new carrier of the session traffic after the switch.
AMF	Maintains the registration and access-control state needed during the transition.
SMF	Coordinates the session-level behavior that enables full path switching.
UPF	Applies the forwarding changes needed so the target path becomes active for the session.
Policy functions	Decide when a full switch is preferable to steering or splitting.

Interfaces used

Interface	Path	Role
N1	UE <-> AMF	Carries session updates when UE-visible behavior changes are needed.
N11 / policy control	AMF/SMF <-> policy functions	Translate switching intent into session behavior.
User-plane paths	Source/target access <-> UPF	Show where traffic is before, during, and after the switch.

End-to-End Call Flow

UE         source access        target access        SMF / UPF / policy
|                  |                  |                    |
|==== traffic on source path ==================================>|
|                  |                  |<-- prepare target --|
|==== traffic migrates to target path =========================>|
|.... source path should go idle / clean up ...................|

Major Phases

Phase	What happens
1. Switch decision	The network decides traffic should leave the current access and fully move to another one.
2. Target path preparation	The target path is readied so the switch can happen cleanly.
3. Traffic handoff	Traffic leaves the source path and is redirected to the target path.
4. Post-switch cleanup	Residual source-path behavior is removed.
5. Stable service on the target path	The session continues fully on the new access.

Step-by-Step Breakdown

Policy decides a full switch is needed

Sender -> receiver: Policy functions -> SMF

Message(s): Switching rule or service-trigger update

Purpose: Choose full path migration instead of simple preference or simultaneous use.

State or context change: The session enters a full migration workflow between accesses.

Note: This is what separates switching from steering. The goal is to move all relevant traffic, not just prefer a path.

The target path is prepared

Sender -> receiver: SMF / UPF / target access context

Message(s): Session and forwarding update for the target path

Purpose: Make the new access path capable of carrying the session before traffic leaves the old one.

State or context change: The session now has a ready target even though live traffic may still use the source path.

Note: If the target path is not truly ready first, switching becomes packet loss by design.

Traffic moves off the old path

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

Message(s): Live packet redirection under ATSSS switching policy

Purpose: Migrate the active session flow from one access to the other.

State or context change: The target path becomes the live carrier of service.

Note: Packet capture should show a real handoff in path usage, not just control-plane intent.

The old access path is cleaned up

Sender -> receiver: Source access / UPF state

Message(s): Residual source-path removal and observation

Purpose: Prevent stale forwarding or duplicate delivery after the switch.

State or context change: The source path should no longer own the active traffic.

Note: Residual old-path packets are one of the clearest switching failure signatures.

Service is validated on the new path

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

Message(s): Post-switch traffic and quality observation

Purpose: Prove that the session is stable after the switch, not just relocated in theory.

State or context change: The switch settles into normal service on the target access.

Note: Measure continuity, not just direction of traffic.

Important Messages in This Flow

Message	Protocol	Direction	Purpose in this procedure	What to inspect briefly
Switching policy update	Policy / session control	Policy functions <-> SMF	Defines that traffic must move fully to the new path.	Use this to anchor the start of the switch.
Session modification or path update	Control	Network -> UE / UPF	Makes the target path operational for the switch.	Important for seeing whether the network prepared the target cleanly.
Traffic movement on packet traces	User plane	UE <-> source/target access <-> UPF	Shows the actual migration from old path to new path.	This is the strongest proof of success.
Residual source-path packets	User plane	Source path observation	Reveal incomplete cleanup after switching.	Useful for spotting hidden duplicate or stale forwarding.

Important Parameters to Inspect

Parameter	What it is	Where it appears	Why it matters	Common issues
Source and target access path	The old path being left and the new one being adopted.	Policy and live traffic observation	Core identity of the switching event.	Without both, the move is hard to prove.
Switch timing	When traffic actually left the old path and appeared on the new one.	Control and packet traces	Key for judging interruption and continuity.	Long gaps may still be operational failure.
Residual old-path state	Any leftover traffic or forwarding on the source side.	Post-switch observation	Shows whether the move truly completed.	Residual state creates duplicate delivery and confusion.
Service quality after switch	Latency, continuity, and packet behavior on the target path.	Live service observation	Proves the target path is not only active but healthy.	A switched path with poor service is still a bad outcome.
Policy reason for switching	Why the network chose full movement instead of steering or splitting.	Policy context	Explains the intended outcome and helps judge whether the result matches the need.	Missing reason makes the event look random.

Success Criteria

The target access path is prepared before traffic leaves the source.
The active session moves to the new path with acceptable interruption.
Residual source-path state is removed cleanly.
Service remains stable after the switch.

Common Failures and Troubleshooting

Symptom	Likely cause	Where to inspect	Relevant message(s)	Relevant interface(s)	Likely next step
Traffic is split unintentionally instead of switched	The old path remained active when the goal was full migration.	Packet traces on source and target paths.	Live traffic observation	User plane	This is the main difference between failed switching and intentional splitting.
Traffic pauses for too long during the move	Target preparation or path convergence was too slow.	Switch timing and first target-path packets.	Control update and packets	User plane	A technically successful move can still be a service failure.
The switch happens, but the target path is unstable	The target path was chosen but cannot sustain the service well.	Post-switch KPIs and packet continuity.	Post-switch traffic	User plane	Always judge the target path, not only the act of movement.
Old-path traffic never fully disappears	Cleanup was incomplete or policy enforcement drifted.	Residual source-path packets and UPF state.	Post-switch observation	User plane	This creates long-tail operational issues after the nominal switch.

Related sub-procedures

Related message reference pages

Related troubleshooting pages

FAQ

What is ATSSS Traffic Switching?

It is the procedure that moves active session traffic fully from one access path to another.

How is it different from steering?

Steering prefers a path, while switching aims to migrate the traffic completely to the new path.

What proves success?

Traffic leaves the old path, appears on the new one, and stays stable there.

What should I inspect first?

Start with the source and target paths, switching trigger, and packet movement timing.

Why can switching fail even with a clean policy update?

Because the target path may not be ready or the source path may not have been cleaned up properly.