5G Emergency Registration Procedure Call Flow
5G Emergency Registration is the access and NAS procedure that gives a UE limited emergency service when normal registration is missing, rejected, or not usable.
It joins emergency radio access, emergency NAS registration, and limited-service acceptance into one practical path toward emergency communication.
Introduction
The 5G Emergency Registration procedure exists so emergency service is still possible even when the UE cannot rely on ordinary registration and ordinary service admission.
The key engineering question is not whether the UE became fully registered for all services, but whether it correctly entered emergency-capable limited service state and could continue toward the emergency call or session path.
What Is Emergency Registration in Simple Terms?
- What starts the procedure: The UE needs emergency service while normal registration is missing or unusable.
- What the UE and network want to achieve: Allow emergency-limited service quickly and safely.
- What success looks like: The UE receives Registration Accept for the emergency branch and can continue emergency signaling.
- What failure means: The UE never reached emergency-limited registration or later emergency service could not proceed.
Why this procedure matters
Emergency Registration is one of the highest-impact control procedures in the 5G system because it protects emergency reachability when normal service assumptions are broken. Analysis has to stay focused on emergency admission and emergency continuity rather than on ordinary-service expectations.
Quick Fact Sheet
| Procedure name | 5G Emergency Registration Procedure |
|---|---|
| Domain | 5G NR + 5GC emergency access and limited-service registration |
| Main trigger | UE needs emergency service while normal registration is absent, rejected, or not usable |
| Start state | UE can reach NR radio but does not have a normal service context that can support the emergency attempt |
| End state | UE obtains limited emergency registration so emergency signaling and service can continue |
| Main nodes | UE, gNB, AMF, emergency service functions, optional UDM or AUSF checks |
| Main protocols | RRC, NAS, NGAP, emergency service handling |
| Main success outcome | Emergency Registration Accept puts the UE into emergency-capable limited service state |
| Main failure outcome | Emergency registration is rejected or the UE never becomes reachable enough to deliver the emergency request |
| Most important messages | RRC Setup Request, Registration Request (Emergency), Registration Accept, Registration Complete |
| Main specs | TS 23.502, TS 24.501, TS 33.501, TS 38.300, TS 38.331 |
Preconditions
- The UE can reach a suitable NR cell for emergency access.
- The UE has an emergency-service trigger such as an emergency call attempt.
- The network supports emergency-limited registration handling.
- The UE and network can exchange the emergency NAS request over a valid radio-control path.
Nodes and Interfaces
Nodes involved
| Node | Role in this procedure |
|---|---|
| UE | Detects the emergency need, requests emergency registration, and uses the returned limited-service context to continue emergency signaling. |
| gNB | Provides emergency-capable radio access and relays the NAS emergency registration exchange. |
| AMF | Processes emergency registration, applies limited-service policy, and coordinates the UE emergency reachability state. |
| Emergency service functions | Receive the UE later in the emergency voice or emergency-session path once limited registration is granted. |
| UDM / AUSF | May still contribute identity or subscriber checks when the network supports them, but the procedure is focused on emergency access continuity rather than normal service onboarding. |
Interfaces used
| Interface | Path | Role |
|---|---|---|
| NR-Uu | UE <-> gNB | Carries emergency access setup and the NAS emergency registration message. |
| N1 | UE <-> AMF | Carries Registration Request, Registration Accept, and Registration Complete for the emergency branch. |
| N2 | gNB <-> AMF | Relays the emergency registration signaling and access-control handling between RAN and core. |
| Core emergency service paths | AMF <-> emergency functions | Support the later emergency call or emergency-session branch after limited registration is accepted. |
End-to-End Call Flow
UE gNB AMF Emergency Functions
| | | |
|-- emergency ---->| | |
|-- RRC Setup ---->| | |
|-- Registration Request (Emergency)->| |
| | |-- emergency policy |
|<-- Registration Accept -------------| |
|-- Registration Complete ----------->| |
|==== emergency service may continue =====================>|Major Phases
| Phase | What happens |
|---|---|
| 1. Emergency trigger | The UE detects an emergency service attempt and decides ordinary service or ordinary registration is not enough. |
| 2. Emergency access setup | The UE establishes radio signaling with an emergency establishment cause so NAS emergency registration can be delivered. |
| 3. Emergency Registration Request | The UE sends Registration Request using the emergency registration type. |
| 4. Limited-service validation | The AMF validates the request under emergency rules and decides whether emergency-limited registration can be granted. |
| 5. Accept and completion | The UE receives Registration Accept, applies the emergency result, and confirms with Registration Complete where applicable. |
Step-by-Step Breakdown
UE detects emergency-service need
Sender -> receiver: UE internal service logic
Message(s): Emergency number or emergency-session trigger
Purpose: Start an emergency-specific access path even when normal service conditions are not available.
State or context change: UE shifts from normal-service expectations to emergency-limited handling.
Note: The first useful check is whether the UE really classified the service as emergency and not as an ordinary failed call attempt.
Emergency RRC access is established
Sender -> receiver: UE -> gNB
Message(s): RRC Setup Request, RRC Setup, RRC Setup Complete
Purpose: Create the emergency-capable radio-control path needed for the NAS exchange.
State or context change: UE becomes signaling-ready with emergency access context.
Note: Look closely at the establishment cause and whether radio access itself blocked the procedure before NAS emergency handling began.
UE sends emergency Registration Request
Sender -> receiver: UE -> gNB -> AMF
Message(s): Registration Request with emergency registration type
Purpose: Tell the core that the UE needs limited registration for emergency service.
State or context change: AMF starts an emergency registration branch instead of a normal registration path.
Note: Registration type, emergency indication, identity availability, and UE capability are the first fields to inspect.
AMF performs emergency-limited validation
Sender -> receiver: AMF and optional subscriber checks
Message(s): Emergency registration decision handling
Purpose: Apply emergency policy and decide whether the UE can be admitted for limited service.
State or context change: The UE either receives emergency-limited acceptance or the emergency path stops.
Note: This branch is intentionally not identical to full normal registration. A reduced check set can still be correct if the result is limited emergency service only.
UE applies emergency acceptance and completes
Sender -> receiver: AMF -> UE -> AMF
Message(s): Registration Accept, Registration Complete
Purpose: Finalize the emergency registration result so later emergency signaling can proceed.
State or context change: UE enters emergency-capable limited service mode.
Note: Inspect the registration result carefully. Success here means emergency-limited service, not ordinary full-service registration.
Important Messages in This Flow
| Message | Protocol | Direction | Purpose in this procedure | What to inspect briefly |
|---|---|---|---|---|
| RRC Setup Request | RRC | UE -> gNB | Starts the radio-control path needed for emergency NAS signaling. | Check emergency establishment cause and whether cell access itself succeeded. |
| Registration Request | NAS | UE -> AMF | Requests emergency registration under limited-service rules. | Inspect emergency registration type, identity, and emergency indication. |
| Registration Accept | NAS | AMF -> UE | Returns the emergency-limited registration result. | Verify that the result reflects emergency service rather than normal unrestricted service. |
| Registration Complete | NAS | UE -> AMF | Confirms that the UE applied the emergency registration result. | Confirm it is present when expected and that the UE transitions into limited service mode. |
Important Parameters to Inspect
| Parameter | What it is | Where it appears | Why it matters | Common issues |
|---|---|---|---|---|
| Registration type | Indicates that the NAS registration branch is emergency registration. | Registration Request | Separates this path from normal initial or update registration. | If misread, engineers can mistakenly troubleshoot it as failed ordinary registration. |
| Emergency indication and service category | Flags that emergency handling is required and may identify service class. | UE service trigger and Registration Request | Explain why the network applies limited emergency logic. | Missing or incorrect emergency marking can block the expected emergency branch. |
| UE identity | Identity provided if available for the emergency attempt. | Registration Request | Helps the network correlate subscriber context when possible without making normal service a prerequisite. | Identity may be partial, unavailable, or not enough for normal service logic. |
| Registration result | Returned result that tells the UE what service level was granted. | Registration Accept | Shows whether the UE obtained emergency-limited service successfully. | A valid emergency result can look weaker than full registration but still be correct. |
| Access establishment cause | RRC cause used to obtain emergency radio access. | RRC Setup Request | Proves that the emergency path started correctly from the radio side. | Wrong cause can send the UE into the wrong admission branch. |
Success Criteria
- The UE obtains radio access using the emergency branch.
- Registration Request clearly signals the emergency registration type.
- Registration Accept returns an emergency-limited result the UE can use.
- The UE can continue toward the later emergency service workflow using the accepted limited context.
Common Failures and Troubleshooting
| Symptom | Likely cause | Where to inspect | Relevant message(s) | Relevant interface(s) | Likely next step |
|---|---|---|---|---|---|
| UE cannot reach emergency Registration Request | Radio access failed before emergency NAS signaling could start. | RRC establishment cause, cell selection, and access reject behavior. | RRC Setup Request, RRC Setup | NR-Uu | Treat it as emergency access failure first, not as a core-only registration issue. |
| Emergency Registration Request is sent but rejected | Network policy, emergency handling limits, or malformed emergency indicators prevented acceptance. | Registration type, emergency indication, and the reject reason. | Registration Request, Registration Reject | N1, N2 | Confirm the UE used the emergency branch correctly before assuming the network refused emergency service improperly. |
| Registration Accept arrives but later emergency service still fails | Emergency-limited registration succeeded, but the later emergency session or call path failed. | Registration result, later IMS or emergency-session setup, and policy restrictions. | Registration Accept and follow-on emergency signaling | N1, N2, core emergency service paths | Do not stop at registration success. Correlate it with the next emergency procedure. |
| Registration Complete is missing | The UE did not finish the final NAS confirmation or the return path was lost. | Registration Accept contents and uplink NAS continuity. | Registration Accept, Registration Complete | N1, NR-Uu, N2 | Check whether the UE entered limited service anyway before deciding the whole flow failed. |
What to Check in Logs and Traces
- Check that the UE really treated the case as emergency service before reading the NAS registration outcome.
- Inspect the RRC establishment cause and whether emergency radio access succeeded cleanly.
- Verify the registration type in Registration Request is the emergency branch.
- Read the registration result carefully in Registration Accept; emergency-limited acceptance is the expected success state.
- Correlate the registration result with the later emergency call or emergency session behavior before closing the case.
Related Pages
Related sub-procedures
- 5G Initial Registration
- 5G Authentication Procedure
- VoNR Emergency Call
- 5G IMS PDU Session Establishment
Related message reference pages
Related troubleshooting pages
Notes
Emergency Registration success is not the same as normal-service success. The practical checkpoint is whether the UE enters emergency-capable limited service and can continue toward the emergency service path.
FAQ
What is 5G Emergency Registration?
It is the limited-service registration procedure that lets the UE reach emergency services even when normal service is not available.
Is it the same as Initial Registration?
No. Emergency Registration is a special branch focused on emergency access and limited service rather than full normal-service onboarding.
Does the network always run full authentication first?
Not necessarily. Emergency handling may apply reduced or different validation so emergency access is not blocked by missing normal-service context.
What confirms success?
A Registration Accept showing emergency-limited service, followed by later emergency signaling or Registration Complete where applicable.
What should I inspect first in a failing trace?
Start with emergency classification, RRC establishment cause, the emergency registration type in Registration Request, and the returned registration result.