Emergency — emergency calls (emergency calls in the 5GC)¶

Learning objectives¶

After reading this chapter, you will be able to:

• Explain what an emergency call (Emergency) is different about compared with an ordinary voice call (VoNR).
• Explain the mechanism by which a UE that cannot receive ordinary services (no SIM / cannot authenticate / restricted in the serving area) can nonetheless have its emergency call accepted.
• Explain why a dedicated registration type called Emergency Registration exists.
• Explain, without asserting, that skipping authentication (NIA0/NEA0) may be permitted in a "regulatory- and operator-policy-dependent" manner.
• Diagram the flow by which an emergency call is established on top of an emergency PDU Session and priority assurance (ARP, etc.).

Prerequisites¶

• VoNR (Voice over NR) — an emergency call is a special case of a voice call. It shares the foundation of IMS + QoS Flow.
• Registration (initial registration) — on top of understanding ordinary registration, this layers on a separate type called "emergency registration."
• Authentication — the biggest difference is that authentication may be skipped for an emergency call.
• Security — the context for NIA0/NEA0 (Null algorithms).
• Supplementary: AMF / SMF / PCF / AUSF

What you'll learn in this chapter¶

• Why — why only emergency calls get special treatment.
• Basic Concept — the idea that "even when the gate for ordinary service is closed, only the emergency window is kept open."
• The three differences unique to emergency calls — acceptance of unregistered UEs, skipping authentication, and priority.
• Architecture — the actors of the 5GC, IMS, and PSAP involved in an emergency call.
• Procedure — Call Flow — emergency registration → emergency PDU Session → emergency call establishment.
• The positioning of NIA0/NEA0 — permitting Null algorithms for UEs that cannot be authenticated (regulatory/implementation-dependent).
• Comparison with VoNR / Release differences / Trouble Shooting / FAQ / Practice

Why — why only emergency calls get special treatment¶

Normally, the 5GC provides service only to "UEs that have registered correctly and passed authentication." A UE with no SIM, that fails authentication, or that is restricted in its serving area — such a UE is denied ordinary service.

However, emergency calls (110/119/911, etc.) are the exception. Because lives are at stake, the regulations of many countries require operators to "establish emergency calls as far as possible, even for UEs that cannot receive ordinary service." Here lies the fundamental reason for treating emergency calls separately from ordinary calls.

The main ways an emergency call differs from an ordinary call are the following three points.

• Acceptance of unregistered UEs — even a UE that would normally be rejected may be allowed a special registration purely for the emergency call (Emergency Registration).
• Possibility of skipping authentication — for a UE that cannot be authenticated, an emergency call may be permitted with no encryption or integrity protection (NIA0/NEA0 = Null algorithms).
• Priority — an emergency call is top priority. Resources are secured preferentially even under congestion (ARP, etc.).

Overview¶

An emergency call, too, is built on the same foundation as an ordinary VoNR: IMS (call control) + the 5GC's QoS Flow (the guaranteed lane). What differs is "how far the entrance gate is opened" and "priority."

1. The registration entrance — even when a UE cannot register normally, it can obtain minimal acceptance via a separate type called Emergency Registration (regulatory/implementation-dependent).
2. The authentication gate — for a UE that cannot be authenticated, there can be a configuration that lets it through with no encryption (NIA0/NEA0) (regulatory/implementation-dependent).
3. The emergency path — it sets up a PDU Session (emergency DNN) dedicated to the emergency call, selects the emergency P-CSCF to reach IMS, and ultimately connects to the PSAP (the emergency call answering authority).
4. Priority — the emergency call's QoS Flow is secured with priority via ARP (Allocation and Retention Priority), etc., and is protected even under congestion.

Basic Concept — a beginner-friendly explanation¶

An emergency call can be likened to "the emergency side door of a building closed for the night."

• The ordinary front entrance (ordinary registration and authentication) cannot be entered without ID (SIM/authentication).
• However, only the emergency side door is opened for the sake of human life even when ID cannot be verified (whether it is opened depends on the policy of the building = operator/regulation).
• Once inside, you are guided to the emergency contact (PSAP) with top priority. You are let through ahead of other visitors (priority).

In short, an emergency call is "a limited, top-priority alternate route for UEs that cannot pass the ordinary gate." What differs decisively from ordinary VoNR, however, is that whether the side door is opened at all is itself a regulatory and operator decision.

The three differences unique to emergency calls (differences from VoNR)¶

The ordinary VoNR voice-call establishment flow (IMS PDU Session → SIP registration → voice QoS Flow) is left to the VoNR chapter; here we concentrate on the differences unique to emergency calls.

Architecture¶

graph LR
    UE["UE
(even unregistered)"] -- "N1(NAS: Emergency Registration)" --> AMF["AMF"]
    UE -- "Emergency call(SIP/RTP)" --> IMS["IMS
(emergency P-CSCF=AF)"]
    AMF -- "N11" --> SMF["SMF"]
    SMF -- "N4" --> UPF["UPF"]
    IMS -- "N5" --> PCF["PCF"]
    PCF -- "N7" --> SMF
    SMF -- "N2(via AMF)" --> RAN["NG-RAN"]
    UPF -- "N6(emergency DNN)" --> IMS
    IMS -- "Emergency call routing" --> PSAP["PSAP
(emergency call answering authority)"]

How to read the diagram: the skeleton is the same as ordinary VoNR, but the entrance differs. The UE requests Emergency Registration on the AMF over N1 (NAS) (even a UE that cannot register normally may be accepted). Authentication may be skipped (NIA0/NEA0, regulatory/implementation-dependent). Thereafter it sets up a PDU Session on the emergency DNN (UE⇔UPF⇔N6⇔IMS), the emergency P-CSCF requests priority-tagged QoS from the PCF over N5 as an AF, and the emergency call is ultimately routed to the PSAP.

Network Function¶

Interface¶

Procedure — Call Flow¶

Understand an emergency call in three stages: (A) Emergency Registration → (B) emergency PDU Session establishment → (C) IMS emergency call establishment (to the PSAP). Pay attention to the differences from VoNR (acceptance of unregistered UEs, skipping authentication, and priority).

sequenceDiagram
    participant UE
    participant AMF
    participant AUSF
    participant SMF
    participant PCF
    participant IMS as IMS(emergency P-CSCF=AF)
    participant PSAP

    Note over UE,AMF: (A) Emergency Registration (unregistered UEs may also be accepted)
    UE->>AMF: Registration Request (5GS registration type = Emergency)
    alt When authentication is possible
        AMF->>AUSF: Authentication
        AUSF-->>AMF: Authentication success
    else When authentication is not possible (regulatory/implementation-dependent)
        Note over AMF,AUSF: Skip authentication → may continue with NIA0/NEA0 (Null)
    end
    AMF-->>UE: Registration Accept (Emergency Registered)

    Note over UE,SMF: (B) Emergency PDU Session establishment (emergency DNN)
    UE->>SMF: PDU Session Establishment Request (for Emergency)
    SMF->>PCF: N7 SM Policy (priority: ARP, etc.)
    SMF-->>UE: Emergency PDU Session established

    Note over UE,PSAP: (C) IMS emergency call establishment
    UE->>IMS: SIP INVITE (emergency call, emergency P-CSCF)
    IMS->>PCF: N5 Npcf_PolicyAuthorization (priority QoS request)
    PCF->>SMF: N7 SM Policy update (5QI=1 GBR + priority ARP)
    IMS->>PSAP: Emergency call routing
    UE->>PSAP: Call established (RTP voice)

Explanation of the procedure:

1. (A) Emergency Registration — the UE sends a Registration Request with the registration type set to "Emergency." Even a UE that cannot register normally (no SIM / cannot authenticate / restricted in the serving area) may have this emergency registration accepted (regulatory/implementation-dependent). When authentication is possible it authenticates as usual, but when authentication is not possible there can be a configuration that skips authentication and continues with NIA0/NEA0 (Null algorithms) (regulatory/implementation-dependent).
2. (B) Emergency PDU Session establishment — the UE establishes a dedicated PDU Session on the emergency DNN. At this time the PCF passes a policy including the priority (ARP, etc.), and the SMF secures it with priority.
3. (C) IMS emergency call establishment — the UE sends a SIP INVITE to the emergency P-CSCF, and the P-CSCF requests priority QoS (5QI=1, GBR + priority ARP) from the PCF over N5 as an AF. IMS detects the emergency call, routes it to the PSAP, and the voice (RTP) is established. The establishment mechanism of the voice QoS Flow itself is the same as (C) in VoNR.

Signal Flow¶

The positioning of NIA0/NEA0 (Null algorithms)¶

When accepting a UE that cannot be authenticated for an emergency call, Null algorithms that apply no encryption or integrity protection may be used.

Comparison with VoNR¶

• Commonalities: both are established on IMS (call control) + the 5GC's QoS Flow (the guaranteed lane). The establishment mechanism of the voice QoS Flow (the P-CSCF requests QoS from the PCF over N5 as an AF → PCF→N7→SMF→N4/N2) is the same, using 5QI=1 (conversational voice, GBR) / 5QI=5 (IMS signaling, Non-GBR) (the standardized 5QIs of TS 23.501 §5.7.4).
• Differences: an emergency call differs in that it (1) may accept an unregistered UE (Emergency Registration) / (2) may skip authentication (NIA0/NEA0) / (3) is secured with top priority (ARP, etc.) / (4) connects to the PSAP via the emergency P-CSCF. Items (1) and (2) depend heavily on regulatory and operator policy.

Release differences¶

• Rel-15: the framework of IMS emergency calls and emergency registration in 5GS was specified. However, in early deployments there were many areas where VoNR/emergency calls were not provided, and there were operations in which emergency calls fell back to 4G (EPS) (in the context of EPS Fallback).
• Rel-16 and later: enhancements related to emergency calls and emergency services. The detailed feature additions and section numbers are to be confirmed against each TS (this chapter does not assert).

Trouble Shooting¶

3GPP Specification¶

• 3GPP TS 23.501 — 5G system architecture. General provisions for emergency services (section number to be confirmed)
• 3GPP TS 23.502 — Procedures. The procedures for emergency registration and emergency PDU Session establishment (section number to be confirmed)
• 3GPP TS 24.501 — NAS (5GMM/5GSM). The emergency registration type (registration type=Emergency), etc. (section number to be confirmed)
• 3GPP TS 33.501 — Security. The conditions for permitting emergency calls by UEs that cannot be authenticated and NIA0/NEA0 (Null algorithms) (section number to be confirmed)
• 3GPP TS 23.167 — IMS Emergency Sessions (IMS emergency calls and PSAP routing; this chapter gives only an overview; to be checked)
• 3GPP TS 23.501 §5.7.4 — the standardized 5QI table (5QI=1 conversational voice/GBR, 5QI=5 IMS signaling/Non-GBR; even an emergency call uses these for voice)

FAQ¶

Q. Can I make an emergency call even with a smartphone that has no SIM? A. It depends on the regulations, the operator's policy, and the implementation. In the 3GPP framework, there is a mechanism to accept an emergency call via Emergency Registration even for a UE that cannot register normally, but whether it is actually in effect depends on the country's regulations and the operator's configuration, and cannot be asserted.

Q. How does an emergency call by a UE that cannot be authenticated communicate? A. There can be a configuration in which it continues with no encryption or integrity protection by means of NIA0/NEA0 (Null algorithms) (the TS 33.501 series, regulatory/implementation-dependent). This is an exception for the limited situation of an emergency call and is not used for ordinary calls.

Q. Does an emergency call use the same IMS as an ordinary call? A. It uses IMS in the same way, but the UE selects the emergency P-CSCF, and IMS detects the emergency call and routes it to the PSAP (the emergency call answering authority). The establishment mechanism of the voice QoS Flow itself is common with VoNR.

Q. Do emergency calls get through even under congestion? A. Because an emergency call is secured with top priority via ARP (Allocation and Retention Priority), etc., it is prioritized over ordinary calls even under congestion (the degree of priority is in part implementation-dependent).

Summary¶

• An emergency call (Emergency) is a special case of a voice call (VoNR); the foundation (IMS + QoS Flow) is common, but "the entrance gate" and "priority" differ.
• The differences unique to emergency calls are the four points: (1) acceptance of unregistered UEs (Emergency Registration) / (2) skipping authentication (NIA0/NEA0) / (3) top-priority assurance (ARP, etc.) / (4) reaching the PSAP via the emergency P-CSCF.
• (1) acceptance of unregistered UEs, (2) skipping authentication, and permitting NIA0/NEA0 depend heavily on the country's regulations, the operator's policy, and the implementation, and cannot be asserted.
• The procedure is in the order (A) Emergency Registration → (B) emergency PDU Session (emergency DNN) → (C) IMS emergency call (to the PSAP).
• The voice itself uses the same 5QI=1 (conversational voice, GBR) as ordinary VoNR (TS 23.501 §5.7.4).

Practice — comprehension check and exercises¶

Comprehension check¶

Exercises¶

• Try to draw a diagram of where the Call Flow is the same and where it differs between ordinary Registration and Emergency Registration (hint: focus on the handling of the authentication step).
• Try to organize the conditions under which "an emergency call from a SIM-less smartphone" is established, from the perspectives of regulation, operator policy, and NIA0/NEA0 (the trick is to avoid assertions and express it in terms of dependencies).

Next Step¶

• VoNR (Voice over NR) — return to the ordinary voice call that is the foundation of the emergency call and deepen it.
• Authentication — confirm the original form of the authentication that may be skipped for an emergency call.
• Security — the overall picture of security algorithms, including NIA0/NEA0.
• QoS (5G QoS model) — the details of priority assurance such as ARP, 5QI, and GBR.