5G Emergency PDU Session Establishment Call Flow
5G Emergency PDU Session Establishment creates the session needed for emergency signaling or emergency service delivery in the 5G system.
The important question is not only whether the session is accepted, but whether it is accepted with the right emergency-service behavior and actually supports the intended service.
Introduction
This page is for engineers analyzing emergency session setup as an end-to-end service path rather than as a generic data-session event.
The strongest checkpoints are the emergency service intent, the resulting session profile, the final accept or reject, and the first real emergency signaling that follows.
What Is Emergency PDU Session Establishment in Simple Terms?
- What starts the procedure: The UE needs a session for emergency service access or emergency IMS behavior.
- What the UE and network want to achieve: Create a usable emergency-capable session with the right routing and policy treatment.
- What success looks like: The emergency session is accepted and emergency signaling works.
- What failure means: The session is rejected, mis-profiled, or accepted without working service behavior.
Why this procedure matters
Emergency-session analysis needs stronger discipline than ordinary setup analysis because the cost of a superficially successful but unusable session is much higher.
Quick Fact Sheet
| Procedure name | 5G Emergency PDU Session Establishment |
|---|---|
| Domain | 5G NR + 5GC emergency-service data-session setup |
| Main trigger | UE needs a session to support emergency service access or emergency IMS behavior |
| Start state | UE may be registered or performing emergency-related access, but emergency service transport is not yet active |
| End state | An emergency-capable session exists with policy and routing aligned for emergency service handling |
| Main nodes | UE, gNB, AMF, SMF, UPF, policy and emergency-service functions |
| Main protocols | NAS, NGAP, PFCP, policy handling, emergency IMS or service signaling |
| Main success outcome | Emergency session is accepted and supports the intended emergency signaling or service path |
| Main failure outcome | Emergency service access cannot obtain a usable session or obtains the wrong profile |
| Most important messages | PDU Session Establishment Request, Accept or Reject, emergency-related policy and session parameters |
| Main specs | TS 23.502, TS 24.501, TS 23.167, TS 23.501 |
Preconditions
- The UE has a legitimate emergency service need.
- The serving network supports emergency session handling for the subscriber context.
- The core network can apply the emergency-service session profile correctly.
- The downstream emergency service path is reachable after session setup.
Nodes and Interfaces
Nodes involved
| Node | Role in this procedure |
|---|---|
| UE | Requests the emergency-capable session and uses it for emergency signaling or service access. |
| gNB | Carries the signaling and applies access-side treatment during emergency service setup. |
| AMF | Coordinates NAS transport and emergency-oriented control handling. |
| SMF | Creates the emergency session and applies the right routing and policy behavior. |
| UPF | Anchors the emergency service data path. |
| Emergency policy / service functions | Ensure the session is treated according to emergency-service rules. |
Interfaces used
| Interface | Path | Role |
|---|---|---|
| NR-Uu | UE <-> gNB | Carries the emergency session signaling and later emergency data or IMS traffic. |
| N1 | UE <-> AMF | Carries the emergency session request and result. |
| N2 | gNB <-> AMF | Supports the control path for emergency session setup. |
| N11 | AMF <-> SMF | Builds the emergency session profile in the core. |
| N4 / N3 | SMF <-> UPF and gNB <-> UPF | Install and use the emergency session path. |
End-to-End Call Flow
UE gNB AMF SMF UPF / emergency path
| | | | |
|-- Emergency session request ------->|----------------->|----------------->|
| | | |-- setup path ---->|
| | | |<-- profile ready -|
|<-- Accept / Reject -----------------|<-----------------| |
|==== emergency signaling over created session ==========================>|Major Phases
| Phase | What happens |
|---|---|
| 1. Emergency service need appears | The UE needs emergency signaling or emergency voice/data service treatment. |
| 2. Session request | The UE requests a session with emergency-service intent. |
| 3. Emergency policy and path creation | The core applies the session profile, routing, and policy behavior allowed for emergency service. |
| 4. Session acceptance | The UE receives the emergency session outcome and activates the path. |
| 5. Service validation | Emergency signaling or service access proves the session is really usable. |
Step-by-Step Breakdown
Emergency service demand is identified
Sender -> receiver: UE emergency client -> NAS stack
Message(s): Emergency service trigger
Purpose: Start the special session-setup path needed for emergency service handling.
State or context change: The UE moves from generic connectivity concerns into emergency-specific access behavior.
Note: Keep emergency session intent separate from ordinary IMS or internet session intent throughout the trace.
The UE requests an emergency-capable session
Sender -> receiver: UE -> gNB -> AMF -> SMF
Message(s): PDU Session Establishment Request
Purpose: Ask the network for the session needed to reach emergency service functions.
State or context change: The network evaluates emergency service policy and allowed session treatment.
Note: Emergency setup often looks like normal session setup unless you inspect the service intent and resulting policy carefully.
The core creates the emergency session profile
Sender -> receiver: AMF <-> SMF <-> UPF
Message(s): Emergency session creation and PFCP setup
Purpose: Create the correct routing, QoS, and service treatment for emergency access.
State or context change: The session gains a specific emergency-service transport role.
Note: The strongest check here is whether the resulting session is really aligned with emergency service handling, not merely accepted.
The UE receives the session result
Sender -> receiver: SMF -> AMF -> gNB -> UE
Message(s): PDU Session Establishment Accept or Reject
Purpose: Tell the UE whether the emergency session is available and how to use it.
State or context change: The UE either activates the emergency path or enters failure handling.
Note: Emergency troubleshooting must classify reject causes cleanly because fallback handling can depend on them.
Emergency service signaling validates the session
Sender -> receiver: UE <-> emergency service path
Message(s): Emergency registration, SIP, or service packets
Purpose: Prove the emergency session really supports the intended service.
State or context change: The session becomes operational for emergency use.
Note: An Accept without working emergency signaling is still an incomplete 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 emergency-capable session creation. | Inspect service intent, DNN, slice, and session type. |
| PDU Session Establishment Accept | NAS | SMF -> UE via AMF | Confirms the emergency session can be used. | Check whether the returned profile matches emergency service expectations. |
| PDU Session Establishment Reject | NAS | SMF -> UE via AMF | Shows the session could not be created. | Use reject cause to guide fallback or emergency access analysis. |
| Emergency service signaling | Application / IMS | UE <-> emergency service functions | Proves the session works for the intended emergency outcome. | Best final validation step. |
Important Parameters to Inspect
| Parameter | What it is | Where it appears | Why it matters | Common issues |
|---|---|---|---|---|
| Emergency service intent | Why the session is being created. | Request and service context | Separates emergency cases from generic session setup. | Without it, the trace is easily misclassified. |
| DNN and slice | Target service and routing profile. | Request and Accept | Shows whether the network built the intended emergency path. | Wrong profile can still produce a valid-looking session. |
| QoS and policy treatment | Service behavior of the emergency session. | Accept and policy state | Important for proving the session is prioritized and routable as expected. | Weak treatment causes later service failure. |
| PDU Session ID | Identifier of the emergency session. | Request and Accept | Keeps emergency troubleshooting tied to the right session. | Wrong correlation hides the real failure. |
| Post-accept service signaling | Real emergency application behavior after setup. | After session acceptance | Best proof of usable emergency connectivity. | Accept alone is not enough. |
Success Criteria
- The emergency session is created with the intended service profile.
- The returned session parameters align with emergency service expectations.
- The UE activates the session successfully.
- Emergency signaling or service behavior works over the session.
Common Failures and Troubleshooting
| Symptom | Likely cause | Where to inspect | Relevant message(s) | Relevant interface(s) | Likely next step |
|---|---|---|---|---|---|
| Emergency session is rejected | The emergency path could not be created with the available policy or service conditions. | Request contents and reject cause. | Establishment Request, Reject | N1, N11 | Use the reject cause before assuming radio access is the main problem. |
| Session is accepted but emergency service still fails | The transport exists, but emergency-layer service prerequisites are still wrong. | Accept contents, routing, and emergency application signaling. | Establishment Accept | N3, service layer | This is an end-to-end service problem after session setup. |
| The wrong service profile is created | The network built a generic session instead of an emergency-capable one. | DNN, slice, QoS, and policy profile. | Request, Accept | N1, policy | This is a correctness issue, not just an availability issue. |
| Emergency signaling is unstable after acceptance | QoS or routing behavior is insufficient for the intended service path. | First emergency packets and service timing. | Post-accept traffic | NR-Uu, N3 | Treat this as a post-establishment service-quality failure. |
What to Check in Logs and Traces
- Start by proving the emergency service intent behind the session request.
- Inspect DNN, slice, QoS, and policy profile in the created session.
- Use the Accept or Reject outcome to separate availability from later service correctness.
- Correlate the session with the first emergency signaling packets after setup.
- Treat an accepted but unusable emergency path as a service failure after setup, not a success.
Related Pages
Related sub-procedures
- 5G Emergency Registration
- 5G IMS PDU Session Establishment
- VoNR Emergency Call
- 5G PDU Session Establishment
Related message reference pages
Related troubleshooting pages
Notes
An emergency session must be validated against real emergency behavior. Message success alone is not the target.
FAQ
What is Emergency PDU Session Establishment?
It is the session-setup path used when the UE needs connectivity for emergency service handling.
How is it different from ordinary PDU Session Establishment?
The service intent, policy treatment, and validation target are emergency-specific.
What proves success?
The emergency session is accepted and real emergency signaling or service access works over it.
What should I inspect first?
Start with the emergency service intent, then validate the created session profile and the first real service signaling.
Why can an accepted emergency session still be a problem?
Because acceptance alone does not prove correct emergency routing, QoS, or service behavior.