Home / Call Flows / 5G / IMS PDU Session Establishment for Voice

5G IMS PDU Session Establishment for Voice

call-flow 5G | IMS | PDU Session | Voice | QoS

IMS PDU Session Establishment for Voice is the 5G session-management flow that prepares the packet path used by VoNR registration and later voice service.

The goal is not only to get an IP session. The goal is to get the right IMS voice-support session with the policy and QoS that real voice service expects.

Introduction

This page treats the session as a voice-readiness procedure rather than as generic connectivity.

If the session is wrong, later IMS registration, call setup, or voice quality problems will often be blamed on SIP even though the real issue started here.

What Is IMS PDU Session Establishment for Voice in Simple Terms?

What starts the procedure: The UE needs the IMS voice-support path required for VoNR service.
What the UE and network want to achieve: Build a packet session with the right profile, policy, and QoS for voice.
What success looks like: The session is accepted and later IMS voice procedures work cleanly over it.
What failure means: The session is missing, rejected, or built with the wrong behavior for voice.

Why this procedure matters

This is one of the earliest places where voice-readiness can fail while everything still looks superficially healthy at the access layer.

Quick Fact Sheet

Procedure name	5G IMS PDU Session Establishment for Voice
Domain	5G session management for IMS voice signaling and media readiness
Main trigger	The UE needs the IMS service data path required for VoNR registration or voice continuity
Start state	UE is on 5GS but the IMS voice-support session is not yet usable
End state	An IMS-capable PDU session exists with policy and QoS suitable for voice service
Main nodes	UE, gNB, AMF, SMF, UPF, PCF, IMS core
Main protocols	PDU Session Establishment, QoS policy, SIP over the new session
Main success outcome	The UE can use the session for IMS registration and later voice signaling or media setup
Main failure outcome	The session is missing, mis-profiled, or lacks the treatment needed for real voice service
Most important messages	PDU Session Establishment Request, Accept, QoS rules, later REGISTER or INVITE
Main specs	TS 23.502, TS 24.501, TS 23.501, TS 24.229

Preconditions

The UE is already registered in 5GS.
The subscription and policy environment allow an IMS voice-support session.
The target IMS service profile is known and provisioned.
Later IMS registration or voice procedures can be validated after session setup.

Nodes and Interfaces

Nodes involved

Node	Role in this procedure
UE	Requests the IMS voice-support session that will carry registration and voice-related traffic.
gNB	Applies the access-side treatment needed once the session is active.
AMF	Relays the session request and coordinates core-side session creation.
SMF and UPF	Create the user-plane path and install QoS and policy treatment for IMS voice service.
PCF	Provides voice-related policy and QoS decisions that shape how the session behaves.
IMS core	Uses the resulting session for SIP registration and later VoNR call control.

Interfaces used

Interface	Path	Role
N1	UE <-> AMF	Carries the NAS session request and final acceptance.
N2	gNB <-> AMF	Supports access-side setup for the new service path.
N11 and N4	AMF / SMF / UPF	Create the session and install the user-plane handling.
NR-Uu and N3	UE/gNB/UPF	Carry the later IMS signaling and voice-related packet treatment.

End-to-End Call Flow

UE              gNB / AMF            SMF / UPF / PCF            IMS
|-- PDU Session Establishment Req ------->|                       |
|<-- PDU Session Establishment Accept ----|                       |
|================ REGISTER / INVITE over the new voice session ==>|

Major Phases

Phase	What happens
1. Voice-service need appears	The UE needs an IMS-capable path specifically suitable for voice service.
2. Session request	The UE requests the voice-support PDU session.
3. Policy and QoS installation	The network creates the session with voice-aware treatment.
4. Voice-service readiness	The UE can now register to IMS or continue with VoNR procedures.

Step-by-Step Breakdown

The UE decides that voice-capable IMS connectivity is needed

Sender -> receiver: UE service logic -> NAS stack

Message(s): Voice-registration or voice-service trigger

Purpose: Start the session setup path that makes VoNR service possible.

State or context change: The UE leaves generic 5GS access and enters voice-service preparation.

Note: This differs from generic data-session setup because the end goal is voice readiness, not only IP connectivity.

The UE sends the PDU Session Establishment Request

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

Message(s): PDU Session Establishment Request

Purpose: Request the specific service path that will support IMS voice registration and call control.

State or context change: The core begins creating the session and selecting policy treatment.

Note: DNN, slice, and service intent are the first things to inspect here.

The network creates the session with voice-aware QoS and policy

Sender -> receiver: SMF <-> UPF / PCF

Message(s): Session creation, QoS rules, and policy installation

Purpose: Make sure the resulting session is actually usable for voice and IMS behavior.

State or context change: The packet path becomes service-aware instead of generic best-effort connectivity.

Note: A session can succeed on paper but still be wrong for voice if QoS or policy is weak.

The UE receives Accept and proceeds to IMS voice procedures

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

Message(s): PDU Session Establishment Accept

Purpose: Confirm the new voice-support session and let the UE continue with registration or call setup.

State or context change: The UE now has the service path required for VoNR registration and later call flows.

Note: The best proof is what happens next: IMS registration and voice signaling should actually work over the new session.

Important Messages in This Flow

Message	Protocol	Direction	Purpose in this procedure	What to inspect briefly
PDU Session Establishment Request	NAS	UE -> core	Starts creation of the voice-support session.	Inspect DNN, slice, and service intent.
PDU Session Establishment Accept	NAS	Core -> UE	Confirms the voice-support session parameters.	Check QoS rules, session profile, and address context.
REGISTER or INVITE over the new session	SIP	UE -> IMS	Prove that the session is functionally useful for voice service.	This is where the session moves from theoretical to operational success.

Important Parameters to Inspect

Parameter	What it is	Where it appears	Why it matters	Common issues
DNN / service profile	The network profile used for IMS voice service.	Request and Accept	Shows whether the UE asked for the right service path.	Wrong service profile causes later IMS failure even when session setup succeeds.
QoS rules	The treatment applied to the new session.	Accept and policy path	Critical for SIP stability and voice continuity.	Weak QoS creates subtle post-setup voice issues.
Slice selection	The slice context used for the service.	Request and network selection	Important when voice behavior depends on slice policy.	Unexpected slice can cause routing or policy mismatch.
Post-session IMS behavior	Whether registration or call signaling works afterward.	After Accept	This is the practical proof of success.	A clean Accept without working SIP is still a failed service experience.
Voice continuity expectation	Whether the session supports not only registration but later voice procedures.	Whole end-to-end chain	Keeps the analysis focused on voice readiness rather than generic connectivity.	Generic connectivity assumptions often hide the real issue.

Success Criteria

The voice-support session is accepted with the expected service profile.
Policy and QoS treatment are aligned with voice requirements.
The packet path is usable immediately for IMS voice procedures.
Later voice-related SIP signaling succeeds over the new session.

Common Failures and Troubleshooting

Symptom	Likely cause	Where to inspect	Relevant message(s)	Relevant interface(s)	Likely next step
The session is accepted but voice still does not work	The session exists but is not correct for real IMS voice service.	Accept contents, QoS, and later IMS behavior.	Accept, later REGISTER or INVITE	Session + IMS	This is one of the most common voice-readiness traps.
The wrong service profile is built	The UE or network selected a non-voice session profile.	DNN, slice, and policy context.	Request and Accept	N1 / N11	The session can still look formally successful.
The session is rejected	Subscription, policy, or service configuration did not allow the voice-support path.	Reject cause and request contents.	Request, Reject	Core session path	Classify the reject before changing radio assumptions.
Voice quality problems start immediately after session creation	QoS or policy treatment is insufficient for voice behavior.	QoS rules and first voice-service use.	Accept and post-setup media	User plane	This is not only a SIP problem.

What to Check in Logs and Traces

Check the request intent before assuming generic session setup is enough.
Inspect DNN, slice, and QoS in the Accept carefully.
Use later IMS registration or INVITE behavior to prove operational success.
Do not stop at “session accepted” if the user complaint is really about voice service.

Related sub-procedures

Related message reference pages

Related troubleshooting pages

FAQ

What is IMS PDU Session Establishment for Voice?

It is the session-management procedure that creates the specific 5G data path needed for IMS voice registration and later VoNR service.

How is it different from a generic IMS PDU session page?

This page focuses specifically on the voice-readiness outcome, including QoS and operational voice continuity.

What proves success?

The Accept looks correct and IMS voice procedures actually work over the new session.

What should I inspect first?

Start with DNN, slice, and QoS in the request and accept, then validate real SIP voice behavior.

Why can registration still fail after the session is built?

Because packet connectivity alone does not guarantee correct IMS policy, DNS, or voice treatment.