3GLTEInfo Text-based logo for the 3GLTEInfo telecom engineering reference platform. 3GLTE INFO TELECOM ENGINEERING REFERENCE
Menu
5G Troubleshooting

AMF Selection and GUAMI Issues

AMF-selection problems happen after the UE reaches the first dedicated NAS handoff point, but before the access attempt lands cleanly on the correct AMF and continues through normal registration. These failures are often misread as generic registration problems, even though the first hard break is usually stale 5G-GUTI context, inconsistent GUAMI hints, wrong AMF routing, or missing AMF-selection assistance from the access side.

Use this page when RRCSetupComplete is already present and the problem sits between that UE handoff and the Initial UE Message path toward the intended AMF.

Where AMF Selection Sits in the Procedure Chain

Stay on this page when radio access works far enough to bridge NAS upward, but the AMF targeting or UE identity continuity still looks wrong.

Access-side prerequisites

AMF selection handoff

  • UE provides available identity or AMF hints
  • gNB builds Initial UE Message
  • NG-RAN may use available AMF-related fields for routing or selection
  • registration lands on an AMF instance

Failure branches

  • no usable AMF hint
  • stale or wrong GUAMI context
  • AMF selected but does not match UE context
  • wrong AMF routing leading to later registration failure

Baseline Successful Flow

Use these simplified ladders to separate a clean AMF-selection handoff from a wrong-context routing path.

Call Flow: Normal AMF Selection During Access

Normal AMF selection during 5G access RRCSetupComplete carries available continuity fields, the gNB builds Initial UE Message, and registration continues on the intended AMF. UE gNB / NG-RAN AMF 1. RRCSetupComplete selectedPLMN-Identity registeredAMF? guami-Type? ng-5G-S-TMSI-Value? 2. Initial UE Message Selected PLMN Identity AMF Set ID / Pointer 5G-S-TMSI when available 3. Registration continues on the intended AMF

Call Flow: Wrong AMF Selection Path

Wrong AMF selection during 5G access RRCSetupComplete is forwarded, but stale or wrong AMF context causes Initial UE Message to land on the wrong AMF path and downstream failure appears later. UE gNB / NG-RAN AMF-A / AMF-B 1. RRCSetupComplete 2. Initial UE Message uses stale or wrong AMF hint for routing 3. Registration continues on the wrong AMF path and mismatch appears downstream

Fast Triage by Failure Pattern

Separate stale context, missing context, and wrong routing early. They can look similar later, but they do not come from the same root cause.

Wrong AMF selected

  • stale 5G-GUTI or GUAMI
  • wrong AMF hint used during access
  • gNB routing or selection mismatch

Registration starts inconsistently after mobility

  • stored AMF context stale
  • GUAMI no longer valid in serving area
  • wrong reuse of old identity context

No explicit AMF-selection clue available

  • UE using generic or random identity path
  • gNB must rely on broader AMF selection logic
  • issue may be area or routing based rather than UE-context based

Later failures hide the first break

  • authentication blamed too early
  • Registration Reject treated as primary issue
  • actual break is AMF targeting or identity-context mismatch

5G-GUTI and GUAMI Checkpoints

5G-GUTI is built from GUAMI plus 5G-TMSI, so stale or inconsistent GUAMI is one of the clearest root-cause buckets for AMF-selection issues. If you need the identity structure itself, see 5GS UE and Network Identities.

What to verify

  • does the UE present a 5G-GUTI-related context or a random identity path
  • is the GUAMI consistent with the currently serving PLMN and area
  • do the AMF Region ID, AMF Set ID, and AMF Pointer values still make operational sense
  • is the issue reproducible only after mobility, idle return, or area change

Example: Stale GUAMI or 5G-GUTI context

Observed behavior
- access succeeds up to RRCSetupComplete
- UE provides prior identity context
- registration attempt lands on an unexpected or no-longer-valid AMF path

Checks
- decode 5G-GUTI if available
- compare GUAMI fields against current serving PLMN and AMF area
- verify whether the stale identity path appears only after mobility or return from idle

RRCSetupComplete AMF-Selection Fields

RRCSetupComplete is the earliest UE-side message where AMF continuity hints can appear before NGAP forwarding happens.

What to check in the message

  • selectedPLMN-Identity
  • optional registeredAMF
  • optional guami-Type
  • optional s-NSSAI-List
  • mandatory dedicatedNAS-Message
  • optional ng-5G-S-TMSI-Value

Example: RRCSetupComplete carries unusable AMF hint

Observed behavior
- RRCSetupComplete is present
- selected PLMN is correct
- AMF-related optional fields do not align with expected core targeting

Checks
- verify registeredAMF
- verify guami-Type
- verify ng-5G-S-TMSI-Value
- compare against current PLMN and AMF deployment expectations

NGAP Initial UE Message AMF-Selection Checks

Initial UE Message is the clean breakpoint between “UE signalled the right thing” and “gNB used it correctly for AMF routing.”

What to verify

  • Selected PLMN Identity
  • AMF Set ID
  • AMF Pointer
  • 5G-S-TMSI
  • whether the gNB routed the request to the expected AMF pool or instance

No-AMF-Hint vs Wrong-AMF-Hint Analysis

These two failure modes can look similar later, but one is missing selection assistance and the other is incorrect continuity information.

No-AMF-hint case

  • UE does not provide a useful prior AMF continuity hint
  • gNB must rely on serving-area and routing logic
  • problem tends to look like area or routing inconsistency

Wrong-AMF-hint case

  • UE provides identity or context hint
  • gNB uses it, but the context is stale or not valid for the current area or PLMN
  • problem tends to look deterministic after certain mobility or recovery scenarios

Call Flow: No useful AMF hint available

  • RRCSetupComplete carries minimal or no AMF hint
  • Initial UE Message relies on selected PLMN and serving-area routing
  • outcome depends on generic AMF pool selection logic

Practical Troubleshooting Workflow

Confirm the break is really in AMF targeting, then decode the continuity clues before diving into later authentication or reject analysis.

2. Decode the AMF continuity clues

  • 5G-GUTI if present
  • GUAMI structure
  • registeredAMF
  • guami-Type
  • ng-5G-S-TMSI-Value
  • NGAP AMF Set ID, AMF Pointer, and Selected PLMN Identity

3. Separate stale context from missing context

  • stale-context branch means wrong or outdated GUAMI or 5G-GUTI
  • missing-context branch means generic AMF selection path only
  • routing branch means gNB, area, or AMF-pool selection problem

4. Escalate to the right team

  • access-side field encoding or forwarding issue
  • NG-RAN AMF selection and routing logic
  • AMF-pool or region configuration
  • UE identity continuity and stale GUAMI handling
  • only then move to broader NAS or core procedure troubleshooting

Evidence Checklist for Escalation

Carry both sides of the handoff: the UE continuity hints from RRC and the AMF-selection fields or destination details from NGAP.

Minimum RRC evidence

  • RRCSetupComplete
  • selectedPLMN-Identity
  • registeredAMF if present
  • guami-Type if present
  • ng-5G-S-TMSI-Value if present
  • dedicatedNAS-Message presence

Minimum NGAP evidence

  • Initial UE Message
  • Selected PLMN Identity
  • AMF Set ID
  • AMF Pointer
  • 5G-S-TMSI
  • destination AMF identity or AMF pool used

Minimum core and context evidence

  • 5G-GUTI if known
  • GUAMI fields decoded
  • current serving PLMN, TAC, or AMF area
  • whether the same UE works after power cycle or context reset
  • whether the problem appears after mobility, idle return, or area transition

Specification Map

  • TS 23.501: 5G-GUTI and GUAMI structure
  • TS 38.331: RRCSetupComplete AMF-related fields
  • TS 38.413: Initial UE Message AMF-selection fields
  • TS 23.502: registration procedure context around AMF selection

FAQ

What is the difference between GUAMI and 5G-GUTI?

GUAMI identifies the AMF within the serving PLMN, while 5G-GUTI combines GUAMI with the 5G-TMSI to form a UE temporary identity. In troubleshooting, GUAMI is the AMF-targeting clue and 5G-GUTI is the wider continuity context that carries it.

Which RRCSetupComplete fields matter for AMF selection?

The most useful fields are selectedPLMN-Identity, registeredAMF when present, guami-Type when present, ng-5G-S-TMSI-Value when present, and the dedicated NAS message. Those fields help the gNB preserve or infer the intended AMF path.

What should I check in Initial UE Message for AMF targeting?

Check Selected PLMN Identity, AMF Set ID, AMF Pointer, and 5G-S-TMSI when present, then verify which AMF pool or instance actually received the message. That separates UE hint problems from gNB routing problems.

How do I distinguish stale GUAMI from missing AMF hint information?

A stale-context case usually has AMF continuity information present but no longer valid for the current PLMN or area. A missing-context case has little or no usable hint at all, so selection falls back to generic serving-area routing.

When should I blame AMF selection instead of Registration Reject causes?

Blame AMF selection first when RRC access succeeds, Initial UE Message is built, and the wrong AMF path appears to be chosen before authentication or explicit reject analysis becomes meaningful. A later reject can be a downstream symptom of landing on the wrong AMF context.

Related Pages