Home / Call Flows / 5G / ATSSS Traffic Splitting

5G ATSSS Traffic Splitting Call Flow

call-flow 5G NR | ATSSS | Multi-Access | Traffic Splitting | Parallel Paths

5G ATSSS Traffic Splitting is the multi-access procedure that keeps more than one path active for the same session at the same time.

It joins multi-path policy intent, parallel path preparation, and live packet distribution into one ATSSS operating mode.

Introduction

This page is most useful when the network deliberately wants to share service across multiple accesses instead of choosing only one.

The right analysis pattern is to identify the participating paths, confirm that packets are really distributed across them, and then judge whether the resulting service is actually better or worse.

What Is ATSSS Traffic Splitting in Simple Terms?

What starts the procedure: The network decides a session should use multiple access paths at once.
What the UE and network want to achieve: Distribute traffic concurrently while keeping the service stable.
What success looks like: Traffic is shared across paths in a controlled and useful way.
What failure means: The split harms service, collapses to one path, or becomes unstable.

Why this procedure matters

Traffic splitting is one of the easiest ATSSS modes to misunderstand because visible activity on multiple paths does not automatically mean a good outcome. A structured page keeps packet distribution tied to real service quality.

Quick Fact Sheet

Procedure name	5G ATSSS Traffic Splitting
Domain	5G simultaneous multi-access traffic distribution across more than one path
Main trigger	Policy or service logic decides that traffic should be distributed across multiple accesses at the same time
Start state	ATSSS-capable session exists and more than one usable access path is available
End state	Traffic is deliberately shared across paths while the session remains stable and predictable
Main nodes	UE, gNB, non-3GPP access, AMF, SMF, UPF, policy functions
Main protocols	NAS, policy control, session update, multi-path user-plane observation
Main success outcome	Packets are spread across the intended accesses in a controlled way and service quality improves or remains stable
Main failure outcome	Traffic duplication, imbalance, reordering pain, or unstable service appears during attempted splitting
Most important messages	Policy-driven split decision, session updates, live packet distribution across paths
Main specs	TS 23.501, TS 23.502, ATSSS architecture and multi-access continuity behavior

Preconditions

The UE and network support ATSSS multi-access operation.
A session exists that can use multiple simultaneous paths.
At least two paths are healthy enough to participate in the split.
Policy logic has a concrete reason to choose concurrent path use.

Nodes and Interfaces

Nodes involved

Node	Role in this procedure
UE	Implements simultaneous multi-access behavior and sends or receives traffic across more than one path.
3GPP access	Carries part of the split session traffic.
Non-3GPP access	Carries another portion of the same split traffic.
AMF	Maintains the access and control context while the session uses multiple paths.
SMF	Coordinates the session behavior that enables deliberate path sharing.
UPF	Applies forwarding behavior consistent with the split traffic model.
Policy functions	Determine when splitting is better than steering or full switching.

Interfaces used

Interface	Path	Role
N1	UE <-> AMF	Carries session updates when UE-visible multi-access behavior changes.
N11 / policy control	AMF/SMF <-> policy functions	Translate the split policy into session handling.
Parallel user-plane paths	3GPP/non-3GPP access <-> UPF	Reveal whether traffic is really distributed across multiple accesses.

End-to-End Call Flow

UE          3GPP access        non-3GPP access       SMF / UPF / policy
|                  |                  |                    |
|<==== split policy / session update =====================>|
|==== packets over path A ================================>|
|==== packets over path B ================================>|
|.... ongoing balance and service-quality validation ......|

Major Phases

Phase	What happens
1. Split decision	The network decides the session should use more than one access at the same time.
2. Multi-path preparation	Each participating path is prepared to carry its portion of traffic.
3. Live distribution begins	Traffic starts using multiple paths simultaneously.
4. Balance and stability validation	The network checks whether the split behavior is healthy and beneficial.
5. Ongoing split operation	The session continues under controlled multi-access distribution.

Step-by-Step Breakdown

Policy selects simultaneous multi-access use

Sender -> receiver: Policy functions -> SMF

Message(s): Traffic-splitting decision

Purpose: Choose deliberate concurrent path use instead of preferring or replacing a single path.

State or context change: The session enters a true multi-path operational mode.

Note: This is the defining conceptual difference between splitting and the other ATSSS modes.

Participating paths are prepared

Sender -> receiver: SMF / UPF / access contexts

Message(s): Session and path updates for multi-path service

Purpose: Make sure each path can carry its part of the service without accidental overload or mismatch.

State or context change: The session becomes ready to distribute traffic intentionally.

Note: A weak second path turns splitting into instability instead of resilience.

Traffic begins flowing across both paths

Sender -> receiver: UE <-> multiple accesses <-> UPF

Message(s): Live packets distributed across paths

Purpose: Implement the split model in real service conditions.

State or context change: The session is no longer tied to a single active path.

Note: Packet-level evidence is mandatory here. Otherwise a supposed split may actually be failed switching or weak steering.

Balance and ordering behavior are observed

Sender -> receiver: UE and network observation

Message(s): Operational packet distribution and quality outcomes

Purpose: Check whether the distribution helps service instead of creating reordering or inconsistency.

State or context change: The split either settles into a healthy pattern or begins harming the application.

Note: Traffic splitting can be technically active and still operationally harmful if path characteristics differ too much.

The network maintains or revises the split strategy

Sender -> receiver: Policy functions <-> live service context

Message(s): Ongoing multi-access policy observation

Purpose: Keep the split useful as conditions evolve.

State or context change: The session remains in controlled multi-path service or transitions to another ATSSS mode.

Note: A good split strategy may later switch back to steering or switching depending on conditions.

Important Messages in This Flow

Message	Protocol	Direction	Purpose in this procedure	What to inspect briefly
Splitting policy decision	Policy / control	Policy functions <-> SMF	Defines that multiple paths should be used simultaneously.	Anchor the multi-path mode here.
Session update for multi-path behavior	Control	Network -> UE / UPF	Makes the split strategy operational for the session.	Check whether the session actually became eligible for concurrent path use.
Distributed traffic on packet traces	User plane	UE <-> parallel accesses <-> UPF	Proves whether the session is truly using multiple paths.	This is the clearest operational validation.
Quality and ordering observation	Operational evidence	UE / network monitoring	Shows whether the split helps or harms the service.	Important because technically successful split can still be poor service.

Important Parameters to Inspect

Parameter	What it is	Where it appears	Why it matters	Common issues
Participating paths	The accesses that share the session traffic.	Policy and packet observation	Define the topology of the split behavior.	Missing one path makes the analysis incomplete.
Distribution balance	How traffic is shared across the available paths.	Live packet observation	Important for judging whether the split is controlled or accidental.	Severe imbalance may mean the split is not really functioning.
Path characteristic mismatch	Differences in latency, quality, or stability between the accesses.	Operational observation	Strongly affects whether split service stays healthy.	Large mismatch can create reordering pain.
Application impact	What the service experiences once traffic is split.	End-to-end observation	Final proof of whether splitting is beneficial.	Do not confuse visible activity with good service.
Fallback or mode-change behavior	Whether the session later returns to steering or switching.	Longer-running policy observation	Helpful when a split is only temporary under changing conditions.	Ignoring mode changes leads to wrong conclusions.

Success Criteria

Multiple paths are intentionally prepared for the same session.
Live packets are distributed across the intended accesses.
Distribution remains stable enough for the service profile.
The application experience stays acceptable or improves.

Common Failures and Troubleshooting

Symptom	Likely cause	Where to inspect	Relevant message(s)	Relevant interface(s)	Likely next step
Traffic is active on two paths but service gets worse	The split is operational, but path mismatch or reordering hurts the application.	Packet ordering, latency spread, and application behavior.	Live split traffic	User plane	This is a real split failure, not a success.
Only one path carries meaningful traffic	The split policy exists, but the second path is not contributing materially.	Distribution balance and packet counts.	Live packet distribution	User plane	That often means you are really seeing steering, not splitting.
Split traffic becomes unstable over time	One or both participating paths are too variable for sustained concurrent use.	Longer observation window and path-quality changes.	Operational monitoring	User plane	Short captures can hide this problem.
The session flips between modes unexpectedly	Policy logic is not keeping a stable split strategy and moves back toward steering or switching.	Policy timing and live distribution pattern.	Control plus traffic observation	Policy, user plane	Mode confusion is common in ATSSS analysis.

Related sub-procedures

Related message reference pages

Related troubleshooting pages

FAQ

What is ATSSS Traffic Splitting?

It is the procedure that distributes traffic across multiple access paths at the same time.

How is it different from switching?

Switching moves the session fully to one path, while splitting keeps multiple paths active concurrently.

What proves success?

Traffic is visibly distributed across paths and the service remains stable or improves.

What should I inspect first?

Start with which paths are supposed to participate, how traffic is balanced, and what the application experiences.

Why can splitting be harmful even when it is active?

Because big path differences can create reordering, jitter, or unstable service.