Home / Call Flows / 5G / ATSSS Traffic Steering

5G ATSSS Traffic Steering Call Flow

call-flow 5G | ATSSS | Multi-Access | Policy | Session Management

5G ATSSS traffic steering is the multi-access procedure where traffic for an active session is guided toward a preferred access path under network policy.

It combines ATSSS capability, policy-driven session behavior, and live path selection across available accesses.

Introduction

ATSSS steering is easiest to misunderstand when engineers only look at registration capability or only look at packet captures in isolation.

A good analysis connects the two: first prove the session is eligible for steering, then verify which access the policy intended, and finally confirm that the traffic really follows that path in operation.

What Is ATSSS Traffic Steering in Simple Terms?

What starts the procedure: The network policy decides an active session should prefer a particular access path.
What the UE and network want to achieve: Keep the session active while steering traffic over the intended access.
What success looks like: Traffic moves over the preferred path and stays stable under the active steering policy.
What failure means: The wrong path carries the traffic, steering oscillates, or the policy has no practical effect.

Why this procedure matters

ATSSS steering is where multi-access theory meets real packet behavior. A page like this helps distinguish capability, policy intent, and actual forwarding outcome instead of treating them as the same thing.

Quick Fact Sheet

Procedure name	5G ATSSS Traffic Steering
Domain	5G access traffic steering across 3GPP and non-3GPP paths
Main trigger	Network policy decides that an active session should prefer one access path or steer traffic dynamically
Start state	UE has ATSSS-capable connectivity and at least one session that can use multiple access options
End state	Traffic is steered according to policy across the intended access path while the session remains active
Main nodes	UE, gNB, non-3GPP access, AMF, SMF, UPF, policy functions
Main protocols	NAS, session management, policy control, multi-access traffic handling
Main success outcome	The session remains stable while traffic follows the intended steering policy across the preferred access path
Main failure outcome	Traffic is not steered as intended, access selection oscillates, or the session behaves inconsistently across multi-access paths
Most important messages	Registration and session setup context, policy-driven session modification, ATSSS-related path treatment
Main specs	TS 23.501, TS 23.502, TS 24.501, related ATSSS architecture procedures

Preconditions

The UE and network support ATSSS-capable service.
A relevant PDU session exists and can use multiple access options.
At least two meaningful access paths are available to the service model.
Policy logic is in place to decide the preferred path for the traffic.

Nodes and Interfaces

Nodes involved

Node	Role in this procedure
UE	Implements ATSSS-capable traffic behavior and follows steering policy across available access paths.
gNB	Provides the 3GPP access leg that may carry some or all session traffic under the steering policy.
Non-3GPP access	Provides an alternate path that may also carry session traffic depending on steering rules.
AMF	Maintains registration and multi-access control context for the UE.
SMF	Owns the session and the policy-driven handling of ATSSS traffic steering behavior.
UPF	Applies the forwarding behavior required by the active ATSSS policy and session state.
Policy functions	Decide when traffic should prefer one access, move between accesses, or be constrained by service policy.

Interfaces used

Interface	Path	Role
N1	UE <-> AMF	Carries the registration and session context that make ATSSS possible.
N11	AMF <-> SMF	Coordinates session state and policy-driven updates.
N3 / user-plane paths	Access networks <-> UPF	Carry the live traffic that will be steered across available accesses.
Policy control path	SMF <-> policy functions	Provides the steering decision logic for the session.

End-to-End Call Flow

UE        3GPP access / non-3GPP      AMF / SMF / policy        UPF
|                  |                         |                  |
|==== active session context ===============>|                  |
|                  |                         |-- steering rule ->|
|<===== traffic follows preferred path under active policy =====>|
|                  |                         |                  |

Major Phases

Phase	What happens
1. Multi-access capability and session context	The UE already has the registration and session prerequisites needed for ATSSS-capable service.
2. Steering policy decision	The policy framework decides that traffic should prefer one access or shift according to service conditions.
3. Session or path update	The network applies the steering behavior to the active session and informs the relevant functions.
4. Traffic steering in operation	Live traffic starts following the preferred access path under the active steering rule.
5. Verification and continuity	The session remains stable while engineers confirm the intended path is really being used.

Step-by-Step Breakdown

UE and network have ATSSS-capable context

Sender -> receiver: UE <-> 5GC with available multi-access options

Message(s): Existing registration and session context

Purpose: Provide the foundation on which steering behavior can operate.

State or context change: The session is eligible for multi-access policy decisions.

Note: ATSSS troubleshooting is rarely meaningful unless you first confirm the session and access prerequisites really exist.

Policy decides how traffic should be steered

Sender -> receiver: Policy functions -> SMF

Message(s): Steering rule or policy update

Purpose: Choose which access path should carry the relevant traffic under current conditions.

State or context change: The session gains a preferred path behavior rather than purely static forwarding.

Note: The steering intent is the main object to preserve during analysis. Otherwise later path changes look random.

Session state is updated for steering behavior

Sender -> receiver: SMF <-> AMF / UPF / UE context

Message(s): Session update or policy-driven modification

Purpose: Install the path preference and make it operational on the active session.

State or context change: The session becomes steering-aware and ready to route traffic according to policy.

Note: This can look like ordinary session modification unless you keep the multi-access goal in mind.

Traffic is steered toward the preferred path

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

Message(s): Live application traffic under ATSSS policy

Purpose: Actually move packets using the intended preferred access path.

State or context change: Traffic behavior reflects the steering policy instead of default or static routing.

Note: Control-plane success means little if packet captures show the wrong access path still carrying the traffic.

Continuity is monitored as conditions evolve

Sender -> receiver: UE and network policy observation

Message(s): Ongoing traffic and policy outcomes

Purpose: Ensure steering remains stable and beneficial over time.

State or context change: The session continues under controlled multi-access behavior rather than unstable path oscillation.

Note: Oscillation is a common hidden failure mode in steering scenarios.

Important Messages in This Flow

Message	Protocol	Direction	Purpose in this procedure	What to inspect briefly
Registration and ATSSS-capability context	NAS	UE <-> network	Provide the foundational capability and registration state for ATSSS behavior.	Verify that the UE and network really negotiated the context needed for multi-access service.
Session modification or policy-driven update	NAS / policy	Network <-> UE/session functions	Carry the steering-related change to the active session.	Inspect which session changed and what steering behavior was intended.
Live traffic path observation	User plane	UE <-> access networks <-> UPF	Shows whether steering is really happening on the intended path.	This is the practical proof of success or failure.

Important Parameters to Inspect

Parameter	What it is	Where it appears	Why it matters	Common issues
Access preference policy	Rule that selects which access should carry the traffic.	Policy and session update context	Defines what steering success should look like.	If unclear, later path behavior is impossible to judge.
Eligible PDU session	The session whose traffic is subject to steering.	Session management context	Critical when multiple sessions exist with different behavior.	Wrong session correlation creates false ATSSS conclusions.
Access availability state	Whether 3GPP and non-3GPP paths are both usable.	Runtime service context	Explains why policy may choose or avoid a given access.	Unavailable alternate access can make a good policy look broken.
Observed live path	Which path packets actually used.	Traffic capture and forwarding state	The most direct validation of steering behavior.	Control-plane intent without path change is not real steering.
Stability over time	Whether the path choice remains consistent or oscillates.	Operational observation	Important because unstable steering degrades service even when the policy is technically active.	Rapid flipping between accesses harms latency and user experience.

Success Criteria

The session is truly eligible for ATSSS steering.
Policy logic clearly identifies the preferred access path.
The active session is updated to reflect the steering rule.
Live traffic consistently uses the intended path with acceptable service quality.

Common Failures and Troubleshooting

Symptom	Likely cause	Where to inspect	Relevant message(s)	Relevant interface(s)	Likely next step
Traffic keeps using the wrong access	The steering policy did not get applied or the session is not actually eligible.	Session identity, policy context, and packet path observation.	Policy update and live traffic	User plane, policy	Prove path selection with packet evidence before changing control-plane assumptions.
Traffic oscillates between accesses	Policy thresholds or runtime conditions are too unstable for clean steering.	Policy timing and path changes over time.	Operational traffic behavior	User plane	This is a quality problem even if all sessions stay formally up.
ATSSS looks configured but has no effect	Only the foundational capability exists; the actual steering rule or session update did not happen.	ATSSS capability context and later policy-driven modification.	Registration context, session update	N1, N11	Separate capability from active steering behavior.
Session becomes unstable after steering starts	The preferred path cannot sustain the policy or traffic mix.	Access quality, service continuity, and traffic outcomes.	Session modification and live traffic	User plane	Look at service quality, not just whether the path changed.

Related sub-procedures

Related message reference pages

Related troubleshooting pages

FAQ

What is ATSSS traffic steering?

It is the policy-driven behavior that steers session traffic across available 3GPP and non-3GPP accesses.

Is steering the same as switching or splitting?

No. Steering usually means preferring one access path. Switching and splitting are related but distinct multi-access behaviors.

How do I prove steering is working?

You need both the control-plane policy context and live packet evidence showing that traffic uses the intended path.

Why can steering fail even when configuration exists?

Because capability alone does not guarantee that the active session received a usable steering rule or that the chosen access path remains viable.

What should I inspect first?

Start with which session is supposed to be steered, what access preference policy applies, and which path the packets actually use.