VoNR Emergency Call Procedure
VoNR Emergency Call is the emergency voice procedure that carries urgent service requests across 5G SA and IMS toward the emergency-service path.
It is not just a normal VoNR call with a different number. The network must apply emergency classification, priority treatment, and correct routing from the start.
Introduction
A good emergency procedure must work end to end: the UE must identify the service as emergency, the network must preserve or create the required access and session readiness, and IMS must route the call toward the emergency-service authority.
Because the operational stakes are higher than in normal voice service, troubleshooting should start with correct classification and routing before moving into generic SIP details.
What Is VoNR Emergency Call in Simple Terms?
- What starts the procedure: The user dials an emergency number or starts an emergency-service request.
- What the UE and network want to achieve: Route the call quickly and correctly to the emergency-service path with usable voice continuity.
- What success looks like: The emergency center answers and the caller has stable voice communication.
- What failure means: The call is misclassified, misrouted, delayed, or connected without usable audio.
Why this procedure matters
Emergency voice handling is one of the highest-impact service flows on the network. A small routing or readiness error has much larger consequences than in ordinary call handling.
Quick Fact Sheet
| Procedure name | VoNR Emergency Call |
|---|---|
| Domain | Emergency voice service over 5G SA and IMS |
| Main trigger | The UE dials an emergency number or invokes emergency service while on 5G |
| Start state | The UE needs urgent emergency voice service and may require emergency-specific registration, session, or routing handling |
| End state | The emergency session reaches the emergency call-control path and voice service is established toward the emergency center |
| Main nodes | UE, gNB, AMF, IMS core, E-CSCF, PSAP |
| Main protocols | Emergency service indication, session setup, SIP INVITE, RTP, emergency routing |
| Main success outcome | The emergency call is prioritized, routed correctly, and connected to the emergency center |
| Main failure outcome | The emergency call is delayed, misrouted, or never connected despite the urgent service need |
| Most important messages | Emergency registration or session handling, INVITE with emergency indication, 200 OK |
| Main specs | TS 23.167, TS 23.502, TS 24.229 |
Preconditions
- The UE can access 5G service and trigger the emergency branch.
- The network supports emergency handling through the required access and IMS path.
- Emergency routing logic and emergency-service destination handling are configured.
- Voice media continuity can be established once the emergency call is answered.
Nodes and Interfaces
Nodes involved
| Node | Role in this procedure |
|---|---|
| UE | Recognizes emergency service intent, starts the emergency signaling path, and provides identity and location context when available. |
| gNB and AMF | Provide the 5G access continuity and service handling needed to support emergency call setup. |
| IMS core and E-CSCF | Recognize the emergency session and route it toward the correct emergency service handling path. |
| PSAP | Receives the emergency call and establishes the voice session with the caller. |
Interfaces used
| Interface | Path | Role |
|---|---|---|
| NR-Uu | UE <-> gNB | Carries the access and radio continuity needed for emergency service over 5G. |
| N1 and N2 | UE/gNB <-> AMF | Carry any registration, session, or service handling needed before IMS emergency signaling. |
| IMS SIP path | UE <-> IMS / E-CSCF | Carries the emergency INVITE and answer signaling. |
| Emergency voice media path | UE <-> PSAP through IMS and user plane | Carries the actual emergency voice session after call acceptance. |
End-to-End Call Flow
UE 5G access / IMS / E-CSCF PSAP
|-- emergency trigger ------------------------------>|
|-- emergency INVITE ------------------------------->|
|<------------------- progress / answer -------------|
|-- ACK -------------------------------------------->|
|=============== emergency voice media ==============|Major Phases
| Phase | What happens |
|---|---|
| 1. Emergency service intent | The UE recognizes an emergency number or emergency-service request. |
| 2. Emergency access readiness | The network ensures registration, session, and policy state are sufficient for the emergency branch. |
| 3. Emergency IMS routing | The INVITE is marked as emergency traffic and routed through the E-CSCF path. |
| 4. Emergency answer and media | The emergency center answers and the voice session becomes active. |
Step-by-Step Breakdown
The UE identifies the attempt as an emergency call
Sender -> receiver: UE internal call-control -> network access handling
Message(s): Emergency dial string or emergency service trigger
Purpose: Start the emergency branch instead of a normal commercial voice call path.
State or context change: The procedure changes from generic voice service into emergency-priority service handling.
Note: Always confirm whether the trace is really emergency-classified. Normal voice and emergency voice diverge early.
Emergency-specific access or session readiness is ensured
Sender -> receiver: UE <-> AMF / session path
Message(s): Emergency registration or emergency PDU session handling where applicable
Purpose: Provide the minimum service state needed to support the emergency call reliably.
State or context change: The network prepares the UE for prioritized emergency signaling.
Note: Some failures happen before SIP because the emergency branch never got the right access or session treatment.
The UE sends the emergency INVITE toward IMS
Sender -> receiver: UE -> IMS -> E-CSCF
Message(s): INVITE with emergency indication such as urn:service:sos
Purpose: Route the call through the emergency service path rather than normal commercial routing.
State or context change: The session is now handled by emergency-aware IMS routing logic.
Note: Request-URI and emergency indicators are key here. Misclassification leads to the wrong downstream path immediately.
The emergency center answers and the call becomes active
Sender -> receiver: PSAP / emergency side -> UE
Message(s): 100 Trying, 180 Ringing or equivalent progress, 200 OK, ACK, RTP
Purpose: Complete the emergency session setup and start urgent voice service.
State or context change: The caller is connected to the emergency service operator.
Note: Emergency success means correct routing and real audio continuity, not only an IMS provisional response.
Important Messages in This Flow
| Message | Protocol | Direction | Purpose in this procedure | What to inspect briefly |
|---|---|---|---|---|
| Emergency service indication | Service / SIP context | UE -> network | Marks the session as an emergency call. | Check that the call was really classified as emergency from the start. |
| Emergency session or registration handling | NAS / session management | UE <-> core | Prepare the UE for emergency service where required. | Useful when emergency setup fails before SIP call routing. |
| INVITE with emergency routing context | SIP | UE -> IMS / E-CSCF | Starts the emergency call toward the emergency-routing path. | Inspect the emergency Request-URI and service indicators carefully. |
| 200 OK | SIP | Emergency side -> UE | Confirms emergency call acceptance. | This is the best SIP-layer success checkpoint before media analysis. |
Important Parameters to Inspect
| Parameter | What it is | Where it appears | Why it matters | Common issues |
|---|---|---|---|---|
| Emergency service classification | Whether the network and UE both treated the call as emergency traffic. | At call start | Explains whether the emergency-specific routing and priority path should apply. | Wrong classification causes misrouting to normal voice logic. |
| Emergency routing target | The path toward the E-CSCF and PSAP. | INVITE routing | Determines whether the call reaches the correct emergency authority. | Incorrect routing is one of the highest-risk failures in this family. |
| Location context | Location information sent or derived for emergency handling. | Emergency setup and IMS context | Important for routing and emergency-service support. | Missing or stale location affects routing quality and service handling. |
| Priority and resource treatment | How the network prioritizes the emergency branch. | Access and session phases | Separates emergency behavior from normal commercial service. | Weak prioritization leads to delay or failure under load. |
| Post-answer media continuity | Whether the caller can actually speak to the emergency center. | After 200 OK | Real voice continuity is the true end goal of the procedure. | Signaling success alone is not enough in emergency service. |
Success Criteria
- The call is recognized and handled as emergency traffic from the start.
- The access and session path are ready for emergency service handling.
- The emergency-routing path reaches the correct downstream authority.
- The caller gets stable, usable voice connectivity after answer.
Common Failures and Troubleshooting
| Symptom | Likely cause | Where to inspect | Relevant message(s) | Relevant interface(s) | Likely next step |
|---|---|---|---|---|---|
| The call is not treated as emergency traffic | The procedure stayed on the normal voice branch instead of the emergency branch. | Emergency indicators and early classification. | Early service context, INVITE | Cross-layer service logic | This is the first thing to rule out. |
| Emergency routing is wrong | The session was emergency-classified but reached the wrong downstream path. | E-CSCF routing, target selection, and location context. | INVITE routing | IMS emergency path | This is more severe than normal voice misrouting because the destination matters urgently. |
| The emergency call sets up slowly or fails under congestion | Priority treatment or access continuity is inadequate. | Access readiness, session handling, and prioritization. | Pre-SIP and call-setup timing | 5G access and service policy | Emergency traffic should be separated from normal-service timing expectations. |
| Signaling succeeds but audio is bad | The emergency session is connected but media continuity is poor. | Post-answer RTP and QoS behavior. | 200 OK and media start | User plane | This is still a service failure because the emergency operator must be audible. |
What to Check in Logs and Traces
- Verify emergency classification before deep trace reading.
- Check whether the network used the correct emergency-routing path.
- Separate pre-SIP readiness problems from later SIP issues.
- Treat media quality after answer as a first-class success criterion.
Related Pages
Related sub-procedures
Related message reference pages
Related troubleshooting pages
FAQ
What is a VoNR Emergency Call?
It is the 5G SA emergency voice procedure that routes the caller through IMS emergency handling toward the emergency service center.
Does it use normal VoNR routing?
No. It uses emergency-aware classification and routing, typically involving the E-CSCF path.
What proves success?
The call is emergency-classified correctly, routed to the emergency service path, answered, and carries usable voice media.
What should I inspect first?
Start with emergency classification and routing, then confirm access readiness and final media continuity.
Why is this different from a normal VoNR call?
Because the service priority, routing target, and operational risk are different from ordinary commercial voice service.