Home / Call Flows / 5G / PDU Session Modification

5G PDU Session Modification Procedure Call Flow

call-flow 5G NR | 5GC | NAS | SMF | UPF | QoS

5G PDU Session Modification updates an already-established PDU session when QoS, policy, routing, or service behavior needs to change.

It is the procedure that keeps a session usable as traffic conditions, policy decisions, or service expectations evolve.

Introduction

This is the session-management update path engineers use when the UE already has connectivity but the session profile is no longer correct for the service it is carrying.

The strongest troubleshooting pattern is to compare the old session behavior, the requested or policy-driven change, the delivered modification command, and the first real packets after the update.

What Is PDU Session Modification in Simple Terms?

What starts the procedure: A live session needs different QoS, filters, policy treatment, or routing.
What the UE and network want to achieve: Update the active PDU session without tearing it down and recreating it.
What success looks like: The modification completes and the session behaves according to the new service profile.
What failure means: The change is rejected, partial, or technically accepted but operationally wrong.

Why this procedure matters

A large share of real 5G service issues are modification problems rather than establishment problems. If you misclassify them, you waste time chasing registration or transport layers that are not actually broken.

Quick Fact Sheet

Procedure name	5G PDU Session Modification Procedure
Domain	5G NR + 5GC session update and QoS change handling
Main trigger	Existing session needs updated QoS, policy, route, or service treatment
Start state	UE already has an active PDU session
End state	The session remains active but with updated parameters and user-plane treatment
Main nodes	UE, gNB, AMF, SMF, UPF, PCF
Main protocols	NAS, NGAP, PFCP, QoS policy signaling
Main success outcome	Modification command completes and the changed QoS or forwarding behavior works in live traffic
Main failure outcome	The session stays active but the requested update is rejected, partial, or operationally wrong
Most important messages	PDU Session Modification Command, PDU Session Modification Complete, related PFCP updates
Main specs	TS 23.502, TS 24.501, TS 23.501, TS 29.244

5G PDU Session Modification procedure flow across UE, gNB, AMF, SMF, and UPF

Preconditions

A valid PDU session already exists.
The network can identify the session context and the reason a change is needed.
SMF, UPF, and policy functions can apply the updated session profile.
The UE can receive and process the modification command successfully.

Nodes and Interfaces

Nodes involved

Node	Role in this procedure
UE	Applies the new QoS rules, packet filters, and session parameters for the already-active PDU session.
gNB	Adapts access-side QoS and transport behavior that matches the modified session treatment.
AMF	Carries the NAS signaling path between UE and SMF.
SMF	Decides what changes are allowed and updates session, policy, and UPF state.
UPF	Implements the new forwarding, QoS enforcement, and packet detection behavior.
PCF	Supplies updated policy decisions when the modification is policy-driven.

Interfaces used

Interface	Path	Role
NR-Uu	UE <-> gNB	Carries modified access-side QoS behavior and later traffic.
N1	UE <-> AMF	Carries the modification command and completion result.
N2	gNB <-> AMF	Allows access-side context to stay aligned with the modified session.
N11	AMF <-> SMF	Coordinates the session update decision and NAS payload generation.
N4 / N3	SMF <-> UPF and gNB <-> UPF	Install new forwarding rules and keep the user plane aligned to the updated session.

End-to-End Call Flow

UE                gNB                AMF                SMF                UPF
|                  |                  |                  |                  |
|<-- Modification Command ------------|<-----------------|                  |
|                  |                  |                  |-- PFCP update -->|
|                  |                  |                  |<-- updated rules -|
|-- Modification Complete ----------->|----------------->|----------------->|
|==== traffic follows updated QoS and forwarding ========================>|

Major Phases

Phase	What happens
1. Change need appears	A policy, application, service, or mobility event requires an existing session to change behavior.
2. Update decision	The UE or network requests a modification to the current PDU session context.
3. Core and UPF update	The SMF updates QoS, filters, routing, or policy-linked state and pushes the change to the UPF.
4. UE application	The network instructs the UE to apply the updated session settings.
5. Service validation	Traffic confirms the modified session works as intended after the change.

Step-by-Step Breakdown

A session change is triggered

Sender -> receiver: UE or network policy logic

Message(s): Policy trigger, service request, or mobility-driven update

Purpose: Identify that the current PDU session no longer matches the needed service behavior.

State or context change: The session is active but needs changed parameters.

Note: Separate a true modification case from a new-session case before interpreting the signaling.

The session modification is evaluated

Sender -> receiver: UE -> AMF -> SMF or network-internal trigger

Message(s): PDU Session Modification handling

Purpose: Decide whether the requested QoS or service change is allowed.

State or context change: The SMF works against existing session and policy context.

Note: Use the session ID and old-vs-new QoS values to keep the analysis grounded.

UPF and policy state are updated

Sender -> receiver: SMF <-> UPF and policy functions

Message(s): PFCP rule changes, QoS and filter updates

Purpose: Turn the approved modification into actual user-plane behavior.

State or context change: The modified session design is staged in the core network.

Note: Many field failures are partial updates where NAS looks good but UPF enforcement is stale.

The network sends PDU Session Modification Command

Sender -> receiver: SMF -> AMF -> UE

Message(s): PDU Session Modification Command

Purpose: Tell the UE exactly what has changed in the active session.

State or context change: The UE receives the new QoS rules and session behavior details.

Note: Compare the command to the requested change, not only to the previous Accept.

The UE confirms and traffic proves the change

Sender -> receiver: UE -> AMF and user plane

Message(s): PDU Session Modification Complete

Purpose: Confirm that the UE accepted the change and that the updated session behaves correctly.

State or context change: The modified session becomes operational.

Note: The best proof is application traffic that now follows the expected QoS or routing treatment.

Important Messages in This Flow

Message	Protocol	Direction	Purpose in this procedure	What to inspect briefly
PDU Session Modification Command	NAS	SMF -> UE via AMF	Instructs the UE to apply updated session settings.	Inspect updated QoS rules, QFIs, filters, and any removed resources.
PDU Session Modification Complete	NAS	UE -> SMF via AMF	Confirms the UE applied the new session settings.	Use it to separate command delivery issues from later service failures.
PFCP session update	PFCP	SMF <-> UPF	Applies the new forwarding and enforcement behavior in the UPF.	Check QER, FAR, and PDR alignment with the requested service change.
Related policy decision	Policy	PCF -> SMF	Explains why the session profile had to change.	Helpful when modification appears unexpected from the UE perspective.

Important Parameters to Inspect

Parameter	What it is	Where it appears	Why it matters	Common issues
PDU Session ID	Identifier of the session being changed.	Modification command and session context	Lets you correlate the update to the correct active session.	Wrong correlation can make the wrong session look broken.
QFI and QoS rules	QoS treatment applied to flows in the session.	Command and UPF state	Critical for proving whether the requested service change actually happened.	Mismatch causes silent quality or reachability failures.
Packet filters	Rules that bind traffic to the right QoS behavior.	Command and UPF state	Help explain how application traffic is classified after the update.	Wrong filters create partial service failures.
AMBR and policy profile	Bandwidth and policy treatment attached to the session.	Policy decision and NAS update	Important for congestion, voice, or premium-service behavior.	Looks healthy until real traffic load appears.
Cause or trigger context	Why the modification happened.	Trigger source and policy path	Separates user-driven changes from network-enforced behavior.	Without it, troubleshooting becomes guesswork.

Success Criteria

The correct active session is modified without creating a new session accidentally.
The UE receives and applies the updated session settings.
UPF and access-side enforcement match the new QoS and filter rules.
Real traffic demonstrates the intended service behavior after the change.

Common Failures and Troubleshooting

Symptom	Likely cause	Where to inspect	Relevant message(s)	Relevant interface(s)	Likely next step
Modification command never arrives	The change was not successfully signaled toward the UE.	SMF decision path, N1 transport, and UE reachability.	Modification Command	N1, N11	Separate session-update failure from generic UE signaling failure.
Command arrives but traffic behavior does not change	UPF or access-side enforcement did not line up with the NAS update.	PFCP state, QFI behavior, and first application packets after the change.	Modification Command, Complete	N3, N4	This is the classic partial-update failure pattern.
Wrong QoS profile is applied	The modification was processed against the wrong policy or service intent.	Updated QoS rules, policy inputs, and old-vs-new session profile.	Modification Command	Policy, N11	Compare requested behavior against actual delivered profile.
Session becomes unstable after modification	The update itself succeeded, but service continuity was weakened by the change.	Traffic loss, latency spike, filter mismatch, or radio-side bearer behavior.	Post-modification traffic	NR-Uu, N3	Treat this as a correctness issue after modification, not a release failure.

What to Check in Logs and Traces

Correlate everything using the PDU Session ID before comparing old and new state.
Inspect the Modification Command for QFI, filter, and policy changes, not just whether it arrived.
Check PFCP updates to confirm the UPF actually changed forwarding behavior.
Validate the result with live application traffic after the update, especially under load.
When the change looks unexpected, trace the policy trigger that caused it.

Related sub-procedures

Related message reference pages

Related troubleshooting pages

Notes

Modification success is not just message success. The winning check is whether the session now behaves like the updated service profile intended.

FAQ

What is 5G PDU Session Modification?

It is the procedure used to change the parameters of an already-active PDU session without creating a new one.

What usually triggers it?

QoS changes, policy updates, service changes, mobility events, or application-driven requirements.

What proves success?

The UE completes the modification and live traffic follows the new QoS or routing behavior correctly.

How is it different from PDU Session Establishment?

Establishment creates a new session. Modification updates an existing session.

What should I inspect first?

Start with the session ID, the trigger for change, the modification command, and UPF rule updates.