5G Troubleshooting

Emergency Registration Issues

Emergency registration problems are not the same as ordinary registration failures. The UE may be operating with limited service, may be camped on an acceptable cell rather than a suitable cell, and may follow different NAS rules for identity, authentication, and authorization handling.

This page is written as a fault-isolation guide for the emergency registration path. It helps separate no emergency-capable cell or limited service, emergency registration type not supported by the AMF, identity and authentication handled differently for emergency, and cases where emergency registration succeeds but later emergency service setup still fails.

What This Page Covers

Limited-service and acceptable-cell access

Emergency-capable access path before normal service exists.

Emergency registration path over 3GPP access

The distinct NAS registration branch for emergency handling.

AMF support and AMF rejection

Emergency registration type support versus core-side rejection.

Authentication-bypass or tolerant handling

Emergency policy may skip or tolerate failed authentication differently.

Separation from normal registration troubleshooting

Do not treat this as an ordinary NAS registration branch.

Emergency Registration Ladder

Use this ladder to keep the limited-service and emergency-only path separate from normal registration troubleshooting.

1. UE reaches limited service

  • UE is not necessarily in normal service
  • UE may camp on an acceptable cell
  • emergency-capable access path is still possible

2. UE initiates registration

3. Identity is presented

  • valid 5G-GUTI if available
  • SUCI if available
  • PEI if no SUPI and no valid 5G-GUTI

4. AMF evaluates emergency support

  • AMF supports emergency registration
  • or AMF rejects emergency registration type

5. Authentication and security branch

  • authentication may be performed
  • or AMF may skip authentication and security setup
  • NAS security protection can differ depending on outcome

6. Emergency registration outcome

  • emergency registration accepted
  • emergency registration rejected
  • fallback to another PLMN, SNPN, or alternate emergency path

Baseline Successful Call Flow

Start with the accepted emergency path first, then compare it to rejection or alternate-selection cases later on the page.

Call Flow: Emergency Registration Accepted

Emergency registration accepted The UE reaches limited service, sends Registration Request with emergency registration type, the AMF supports the emergency branch, and registration is accepted so emergency service can continue. UE gNB / NG-RAN AMF / AUSF / UDM 1. Limited service or acceptable cell emergency-capable access path exists 2. Registration Request, reg type = emergency 3. AMF supports emergency may skip auth/security or continue despite auth failure 4. Registration Accept, emergency service can continue

Symptoms and Fast Triage

Start by deciding whether the first hard break is radio-side limited service, emergency registration type handling, emergency identity rules, or later service continuation.

Limited service exists, but emergency registration never starts

  • acceptable-cell issue
  • access path not reaching registration
  • wrong branch before NAS begins

Emergency Registration Request is sent, but AMF rejects quickly

  • AMF does not support emergency registration
  • emergency registration type not accepted on that AMF or area

Identity handling looks different from normal registration

  • PEI used instead of SUCI
  • no valid 5G-GUTI available
  • identity path is different by design in emergency mode

Authentication fails, but emergency flow may still continue

  • AMF policy supports unauthenticated emergency registration
  • normal registration assumptions were applied to an emergency branch

Emergency registration succeeds, but service fails later

  • registration itself may be fine
  • later emergency session or service continuation is the next branch

Acceptable Cell and Limited-Service Checks

Radio-side service level matters first. Emergency troubleshooting starts with acceptable-cell access and limited service, not with normal-service assumptions.

What to verify

  • UE reached limited service
  • cell is acceptable for emergency service
  • problem is not just no normal service
  • UE can still attempt the access path needed for emergency registration

Example: Limited service exists, but registration does not start

Observed behavior
- UE shows limited service or emergency-only conditions
- acceptable cell appears reachable
- no successful emergency registration attempt follows

Checks
- confirm limited-service state
- confirm acceptable-cell criteria are met
- confirm the issue is not earlier random-access or RRC-setup failure

Emergency Registration Type Handling

The registration type is the key NAS indicator that tells the network this should be handled under the emergency branch rather than the normal branch.

What the UE indicates

What the AMF may do

  • support emergency registration
  • or reject emergency registration type if not configured for it

Call Flow: Emergency Registration Type Rejected

Emergency registration type rejected The UE sends Registration Request with emergency registration type, the AMF is not configured to support it, and Registration Reject is returned. UE gNB / NG-RAN AMF 1. Registration Request, reg type = emergency 2. AMF not configured for emergency registration 3. Registration Reject

Identity Handling in Emergency Registration

Emergency identity handling can differ from normal registration by design, so do not treat every difference as malformed NAS behavior. Use 5GS UE and Network Identities if you need to decode how PEI, SUCI, SUPI, or 5G-GUTI should appear.

What to check

  • is 5G-GUTI valid or stale
  • is SUCI present when expected
  • is PEI used because no SUPI or valid 5G-GUTI path exists
  • is NSSAI omitted as expected for emergency registration

Example: Emergency identity path differs from normal registration

Observed behavior
- UE attempts emergency registration
- identity content differs from normal-registration expectations

Interpretation
- this may be correct emergency behavior rather than malformed NAS
- check whether the UE had no SUPI and no valid 5G-GUTI
- confirm whether PEI appears where engineers expected SUCI

Authentication and Security Differences

Do not apply normal registration expectations blindly. Emergency registration can follow a different authentication and NAS security policy path.

  • failed authentication may not always mean the procedure must stop
  • missing normal subscription or restriction checks may be intentional
  • authentication behavior depends on AMF emergency policy

Call Flow: Authentication Failure but Emergency Registration May Continue

Emergency path with unauthenticated handling Registration Request with emergency registration reaches the AMF side, authentication is attempted or considered, and the AMF may still continue emergency handling. UE gNB / NG-RAN AMF / AUSF 1. Registration Request, reg type = emergency 2. Auth attempted or considered auth may fail AMF may continue emergency path 3. Registration Accept or later emergency continuation

Emergency Registration Not Accepted by the Network

A failure here may not be a hard stop. In some deployments the next question is whether the UE tried another selectable PLMN or SNPN emergency path.

Call Flow: Emergency Registration Rejected, Alternate Selection Attempted

Emergency registration rejected with alternate selection attempt Registration Request for emergency services is rejected, then the UE may try PLMN or SNPN selection and retry emergency registration elsewhere. UE gNB / NG-RAN AMF 1. Registration Request, reg type = emergency 2. Emergency registration not accepted 3. Registration Reject 4. UE may attempt PLMN or SNPN selection and retry

Practical Troubleshooting Workflow

1. Confirm the registration type

  • was the UE really using emergency registration
  • or is this a normal registration failure during an emergency scenario

2. Confirm service level at the radio side

  • limited service available
  • acceptable cell found
  • access path viable

3. Decode emergency-specific NAS behavior

  • PEI versus SUCI or 5G-GUTI
  • NSSAI omitted
  • AMF support for emergency registration
  • authentication skipped, failed, or completed

4. Separate the root-cause family

  • no acceptable cell or no limited service
  • emergency registration type unsupported by AMF
  • identity path confusion
  • emergency authentication or security policy issue
  • later emergency service setup issue outside registration

Evidence Checklist for Escalation

Minimum UE evidence

  • limited-service indication
  • registration type used
  • identity form in Registration Request
  • whether retry on another PLMN or SNPN was attempted

Minimum radio and access evidence

  • acceptable-cell status
  • SIB1 or basic access context
  • whether RRC setup succeeded far enough for NAS registration attempt

Minimum core evidence

  • AMF support configuration for emergency registration
  • authentication attempted, skipped, or failed
  • Registration Accept or Reject outcome
  • whether subscription or restriction checks were intentionally bypassed

Minimum context summary

  • current PLMN or SNPN
  • whether shared-network behavior applies
  • whether UE had a valid 5G-GUTI
  • whether issue affects all emergency attempts or only specific areas

Specification Map

  • TS 38.304: limited service and acceptable-cell behavior
  • TS 24.501: emergency registration type and emergency registration handling
  • TS 23.502: emergency registration procedure behavior, identity handling, and AMF support logic
  • TS 38.331: access-side precondition context if needed

FAQ

What is the difference between limited service and emergency registration?

Limited service is the radio-side service state where the UE may still obtain emergency-capable access on an acceptable cell. Emergency registration is the NAS procedure branch the UE then uses when it actually attempts emergency registration toward the core.

Can emergency registration work on an acceptable cell even when normal service is unavailable?

Yes. That is one of the key differences in this branch. Normal service depends on a suitable cell, while emergency-capable limited service can still be possible on an acceptable cell.

When can PEI be used instead of SUCI in emergency registration?

PEI can be used when the UE has no SUPI and no valid 5G-GUTI for the emergency registration path. That is different from the identity expectation in ordinary registration troubleshooting.

Can authentication fail and emergency registration still continue?

Yes, depending on AMF support and emergency policy. In some emergency cases the AMF can skip authentication and security setup for unauthenticated emergency registration, or continue even when authentication does not complete normally.

What happens if the AMF does not support emergency registration?

The AMF rejects the Registration Request that indicates emergency registration. After that, the right troubleshooting question may be whether the UE should try another selectable PLMN or SNPN, rather than treating the failure as a normal registration reject case.

When should I move from this page to later emergency service setup troubleshooting?

Move on when emergency registration itself succeeds but the later emergency session, IMS, or service continuation still fails. At that point the first hard break is no longer the registration branch.

Related Pages