5G IMS PDU Session Establishment Call Flow
5G IMS PDU Session Establishment is the session-management flow that creates the data path used for IMS signaling and voice-related service behavior.
It combines NAS session setup, policy and QoS application, and handoff into IMS-layer service so the UE can actually register and use voice features.
Introduction
This page focuses on the IMS-specific interpretation of 5G PDU session establishment rather than on generic data connectivity.
In practical troubleshooting, success is not just a clean NAS Accept. The real target is an IMS-capable path whose DNN, slice, QoS, and later SIP behavior all line up with voice and signaling expectations.
What Is IMS PDU Session Establishment in Simple Terms?
- What starts the procedure: The UE needs an IMS-capable data path for SIP registration or voice service.
- What the UE and network want to achieve: Create a PDU session with the right policy and QoS treatment for IMS traffic.
- What success looks like: The UE receives PDU Session Establishment Accept and can use the session for IMS registration or voice signaling.
- What failure means: The session is rejected, built with the wrong profile, or accepted without being usable for real IMS service.
Why this procedure matters
IMS service often fails in ways that look like SIP trouble, radio trouble, or generic session trouble. A structured IMS PDU-session analysis keeps the service intent visible from the first NAS request through later SIP use.
Quick Fact Sheet
| Procedure name | 5G IMS PDU Session Establishment |
|---|---|
| Domain | 5G NR + 5GC session setup for IMS voice and SIP services |
| Main trigger | UE needs an IMS-capable PDU session for registration, voice, or supplementary services |
| Start state | UE is registered in 5GS but does not yet have the IMS service data path ready |
| End state | IMS PDU session is active with the QoS and policy context needed for IMS signaling and voice |
| Main nodes | UE, gNB, AMF, SMF, UPF, PCF, IMS core |
| Main protocols | NAS, NGAP, PFCP, PCC/QoS policy, SIP over the established data session |
| Main success outcome | UE receives PDU Session Establishment Accept and can perform IMS registration or voice service over the new path |
| Main failure outcome | IMS PDU session is rejected, mis-profiled, or established without the policy and QoS needed for real voice service |
| Most important messages | PDU Session Establishment Request, PDU Session Establishment Accept, QoS rules and session AMBR, later IMS registration messages |
| Main specs | TS 23.502, TS 24.501, TS 23.501, TS 29.244, TS 24.229 |
Preconditions
- The UE is already registered in 5GS.
- The subscription and policy environment allow an IMS-capable session.
- The target DNN and slice selection for IMS are known and permitted.
- IMS-layer prerequisites such as service configuration exist beyond the session itself.
Nodes and Interfaces
Nodes involved
| Node | Role in this procedure |
|---|---|
| UE | Requests an IMS-dedicated or IMS-usable PDU session and later uses it for SIP registration or voice signaling. |
| gNB | Applies the radio and QoS treatment linked to the session and forwards the NAS session signaling. |
| AMF | Relays the NAS session request and coordinates the access-side acceptance path. |
| SMF | Creates the PDU session, selects the UPF, installs QoS rules, and coordinates policy handling for IMS traffic. |
| UPF | Provides the user-plane anchor for IMS packets once the session is active. |
| PCF | Supplies policy and charging rules that influence IMS QoS, session behavior, and service treatment. |
| IMS core | Consumes the established data path for SIP registration and later media-related control signaling. |
Interfaces used
| Interface | Path | Role |
|---|---|---|
| NR-Uu | UE <-> gNB | Carries the NAS transport and applies access-side QoS behavior for the IMS session. |
| N1 | UE <-> AMF | Carries the PDU Session Establishment Request and accept or reject result. |
| N2 | gNB <-> AMF | Carries access-side setup toward the serving gNB. |
| N11 | AMF <-> SMF | Creates the requested PDU session and coordinates the NAS response payload. |
| N4 / N3 | SMF <-> UPF and gNB <-> UPF | Install and use the user-plane path that will carry IMS signaling and media support traffic. |
| Rx / policy-related control | PCF <-> service functions | Provide the QoS or policy context expected for IMS behavior. |
End-to-End Call Flow
UE gNB AMF SMF / UPF / PCF
| | | |
|-- PDU Session Establishment Req -->|-------------------->|
| | |<-- policy/QoS -----|
| | |<-- session created -|
|<-- PDU Session Establishment Accept-| |
|==== IMS SIP registration / service over new session =====>|Major Phases
| Phase | What happens |
|---|---|
| 1. IMS service need appears | The UE needs an IMS-capable data path for SIP registration, re-registration, or voice-related service. |
| 2. Session request | The UE sends PDU Session Establishment Request with the DNN, S-NSSAI, and session details relevant for IMS access. |
| 3. Session creation and policy application | The AMF and SMF create the session while policy and QoS decisions are applied for the IMS service profile. |
| 4. Access-side bearer and QoS activation | The network installs the user-plane and radio-side treatment needed for IMS packets. |
| 5. IMS service use | The UE receives PDU Session Establishment Accept and can move on to SIP registration or voice signaling. |
Step-by-Step Breakdown
UE decides that IMS connectivity is needed
Sender -> receiver: UE internal IMS client -> UE NAS stack
Message(s): Service or IMS registration trigger
Purpose: Start creation of the PDU session that will carry IMS traffic.
State or context change: The UE moves from generic 5G registration into IMS service preparation.
Note: A normal data session and an IMS-capable session can look similar unless you inspect DNN, slice, and QoS intent carefully.
UE sends PDU Session Establishment Request
Sender -> receiver: UE -> gNB -> AMF -> SMF
Message(s): PDU Session Establishment Request
Purpose: Ask the core to create the PDU session that will support IMS signaling and related service treatment.
State or context change: The SMF starts session creation and evaluates the requested DNN, S-NSSAI, and session type.
Note: The request is where you confirm whether the UE really asked for the IMS path you expected.
SMF selects UPF and policy treatment
Sender -> receiver: SMF <-> UPF and policy functions
Message(s): Session creation and QoS rule installation
Purpose: Build the user-plane path and service profile suitable for IMS use.
State or context change: The network commits to a session topology and QoS behavior for IMS packets.
Note: Many voice-quality problems start here because the session succeeds but the QoS profile is not what IMS expected.
Network returns session acceptance
Sender -> receiver: SMF -> AMF -> gNB -> UE
Message(s): PDU Session Establishment Accept
Purpose: Deliver the final session parameters and allow the UE to activate the IMS data path.
State or context change: The UE learns the session identity, address information, and policy-linked behavior.
Note: Read the accept carefully before jumping into IMS-layer analysis. Many problems are already obvious in the session response.
UE uses the session for IMS registration or voice signaling
Sender -> receiver: UE -> IMS core across gNB and UPF
Message(s): IMS SIP registration or service signaling over the new session
Purpose: Validate that the established PDU session is functionally usable for IMS service.
State or context change: The UE moves from session setup into real IMS application use.
Note: A successful PDU session without working SIP registration is still only a partial success.
Important Messages in This Flow
| Message | Protocol | Direction | Purpose in this procedure | What to inspect briefly |
|---|---|---|---|---|
| PDU Session Establishment Request | NAS | UE -> SMF via AMF | Starts the IMS session creation path. | Inspect DNN, S-NSSAI, PDU session type, SSC mode, and requested capabilities. |
| PDU Session Establishment Accept | NAS | SMF -> UE via AMF | Confirms that the IMS session is created and provides the session parameters. | Check QoS rules, session AMBR, PDU address, and whether the profile matches IMS expectations. |
| PDU Session Establishment Reject | NAS | SMF -> UE via AMF | Shows that the requested IMS session could not be created. | Use the reject cause to separate subscription, slice, DNN, and policy issues. |
| IMS registration messages | SIP | UE <-> IMS core | Validate that the new session works for real IMS service. | If SIP fails after a good accept, inspect DNS, policy, or IMS-layer prerequisites rather than only NAS. |
Important Parameters to Inspect
| Parameter | What it is | Where it appears | Why it matters | Common issues |
|---|---|---|---|---|
| DNN | Data network name used for the requested service. | PDU Session Establishment Request and Accept | Confirms whether the UE really asked for the IMS service path. | Wrong DNN is one of the quickest ways to build the wrong session successfully. |
| S-NSSAI | Slice selection context for the session. | Session request and network selection path | Useful when IMS behavior depends on the chosen slice or roaming policy. | Unexpected slice can cause policy or routing mismatch. |
| PDU Session Type | IPv4, IPv6, or IPv4v6 session behavior. | Request and Accept | Explains whether IMS addressing and later SIP transport can work as expected. | Type mismatch can break later service even when session setup passed. |
| QoS rules and session AMBR | Policy and bandwidth behavior for the session. | Accept and policy handling | Critical for IMS signaling stability and voice treatment. | Weak or incorrect QoS profile leads to subtle post-setup failures. |
| PDU Session ID | Identifier of the created session. | Request, Accept, later modification flows | Lets you correlate IMS session setup with later QoS or SIP issues. | Wrong correlation can make separate sessions look like one broken path. |
Success Criteria
- The requested IMS-oriented session is accepted with the expected DNN, slice, and IP parameters.
- QoS and policy treatment are appropriate for IMS signaling and voice support.
- The user-plane path is usable through gNB and UPF.
- IMS registration or later voice-related signaling works over the session.
Common Failures and Troubleshooting
| Symptom | Likely cause | Where to inspect | Relevant message(s) | Relevant interface(s) | Likely next step |
|---|---|---|---|---|---|
| Session request is rejected | Subscription, DNN, slice, or policy conditions did not allow IMS session creation. | Request contents and reject cause. | PDU Session Establishment Request, Reject | N1, N11 | Classify the reject correctly before changing access or IMS settings. |
| Session is accepted but IMS registration fails | The data path exists, but IMS-layer prerequisites or policy details are wrong. | Accept contents, DNS resolution, SIP reachability, and policy profile. | PDU Session Establishment Accept, SIP REGISTER | N3, application layer | Do not treat all IMS failures as session-establishment failures. |
| Voice signaling is unstable after setup | QoS or policy treatment is not aligned with the expected IMS service quality. | QoS rules, session AMBR, and radio-side bearer mapping. | PDU Session Establishment Accept | NR-Uu, N3, policy | A clean session setup can still mask a weak QoS profile. |
| Wrong session is built successfully | The UE asked for or received a non-IMS session profile by mistake. | DNN, slice, and Accept contents. | PDU Session Establishment Request, Accept | N1, N11 | This is a configuration correctness issue, not a transport failure. |
Related Pages
Related sub-procedures
Related message reference pages
Related troubleshooting pages
FAQ
What is IMS PDU Session Establishment?
It is the 5G session setup path used to create the data connectivity required for IMS services such as SIP registration and voice.
Is it different from generic PDU Session Establishment?
The core signaling is similar, but the service intent, DNN, QoS, and policy treatment are tuned for IMS use.
What confirms success?
A good PDU Session Establishment Accept followed by working IMS registration or voice signaling over the new session.
Why can IMS still fail after session setup succeeds?
Because SIP, DNS, policy, or QoS handling can still be wrong even when the NAS session path completed successfully.
What should I inspect first?
Start with DNN, S-NSSAI, QoS rules, and the Accept contents before moving up into IMS-layer troubleshooting.