5G Initial UE Message Explained

The Initial UE Message is one of the most important NGAP messages in a 5G core access trace. It is the message the NG-RAN sends to the AMF when the RAN has received the first uplink NAS message from the UE and needs to forward it into the 5G core.

For analyzing call flows, this is the point where the access side hands over the UE’s first core-facing signaling message to the AMF. In a live decode, it usually marks the transition from pure radio access procedure handling into core-network mobility management.

Why the Initial UE Message matters

This message is operationally important because it does several things at once:

  • transfers the first NAS message from UE to AMF
  • creates the first UE-associated NGAP identity on the RAN side
  • tells the AMF where the UE is located
  • tells the AMF why the UE requested RRC establishment
  • optionally provides 5G-S-TMSI so the AMF can identify the UE faster
  • optionally asks the AMF to start Initial Context Setup

If this message is missing, malformed, routed to the wrong AMF, or carries inconsistent identity or location information, the whole registration or service request flow can fail very early.

Initial UE Message in the 5G call flow

A simplified sequence is:

  1. UE accesses the cell and completes the required access-side setup.

  2. UE sends an RRC/NAS-bearing uplink message toward the NG-RAN.

  3. NG-RAN extracts the initial NAS message and wraps it in Initial UE Message.

  4. NG-RAN sends Initial UE Message to the AMF over N2 / NGAP.

  5. AMF processes the NAS content and responds using procedures such as:

    • Downlink NAS Transport
    • Initial Context Setup Request
    • Reroute NAS Request

In an initial registration trace, the NAS payload is typically Registration Request. In a CM-IDLE service request scenario, the NAS payload may be Service Request and the N2 parameters include the same identity, location, and establishment-cause context.

Initial UE Message is NGAP, not NAS

A frequent mistake in field analysis is to treat Initial UE Message as a NAS message. It is not.

  • Protocol: NGAP
  • Interface: N2 / NG interface
  • Direction: NG-RAN to AMF
  • Role: Container for a UE-originated NAS message plus access-side context

The NAS message is carried inside the NAS-PDU IE. The RAN forwards that NAS payload transparently, meaning the NG-RAN does not semantically process the UE-AMF NAS content in this message.

That distinction matters during troubleshooting because:

  • NAS decoding problems may actually be inside the NAS-PDU
  • AMF selection problems may be due to 5G-S-TMSI or location information
  • admission or service-priority behavior may be driven by RRC Establishment Cause

Message class and NGAP procedure behavior

Initial UE Message is an NGAP initiating message. It is not a request/response pair with its own successful or unsuccessful outcome at the NGAP message definition level.

That means you usually diagnose success or failure by looking at the follow-on procedures, not by expecting an explicit Initial UE Message response. The next message from the AMF side is often one of these:

  • Downlink NAS Transport
  • Initial Context Setup Request
  • Reroute NAS Request

ASN.1 style structure

A simplified structure looks like this:

NGAP-PDU
└── initiatingMessage
    ├── procedureCode: id-InitialUEMessage
    ├── criticality: ignore
    └── value: InitialUEMessage
        └── protocolIEs
            ├── RAN UE NGAP ID
            ├── NAS-PDU
            ├── User Location Information
            ├── RRC Establishment Cause
            ├── 5G-S-TMSI                         (optional)
            ├── AMF Set ID                        (optional)
            ├── UE Context Request                (optional)
            ├── Allowed NSSAI                     (optional)
            ├── Source to Target AMF Info Reroute (optional)
            ├── Selected PLMN Identity            (optional)
            ├── IAB Node Indication               (optional)
            ├── CE-mode-B Support Indicator       (optional)
            ├── LTE-M Indication                  (optional)
            ├── EDT Session                       (optional)
            ├── Authenticated Indication          (optional)
            ├── NPN Access Information            (optional)
            └── RedCap Indication                 (optional)

For decoder implementation, this is the key point: four IEs are mandatory, and the rest depend on procedure flavor, access type, identity availability, and release-specific features.

Mandatory IEs in detail

1. RAN UE NGAP ID

This is the UE identity allocated by the NG-RAN node for use over NGAP. It is mandatory and uniquely identifies the UE context from the RAN side.

Why it matters

This IE is the anchor for correlating later NGAP signaling before or while AMF-side identity becomes fully established.

Troubleshooting value

If the wrong RAN UE NGAP ID is reused, duplicated, or mismatched in later procedures, trace correlation becomes unreliable and UE-specific NGAP signaling can break.

2. NAS-PDU

This IE carries the UE to AMF NAS message. It is the real payload that the core is waiting for.

Common NAS payloads

Typical examples include:

  • Registration Request
  • Service Request
  • other initial NAS messages that start or re-establish core-side signaling

Why it matters

The AMF’s next action is largely determined by what is inside this NAS-PDU.

Troubleshooting value

If the NAS-PDU is malformed, secured incorrectly, or inconsistent with the identity context provided by the RAN, the AMF may reject the procedure even though the NGAP envelope looks fine.

3. User Location Information

This IE gives the AMF the UE location at the time the initial NAS message arrived. For NR access, it commonly includes NR CGI and TAI.

Why it matters

The AMF uses this for mobility management, tracking area handling, access validation, and policy decisions.

Troubleshooting value

If the TAI, PLMN, or CGI is incorrect, the AMF may reject the NAS procedure, select the wrong policy, or route the UE incorrectly.

4. RRC Establishment Cause

This IE tells the AMF why the UE initiated the RRC setup on the access side.

Typical values include:

  • emergency
  • highPriorityAccess
  • mt-Access
  • mo-Signalling
  • mo-Data
  • mo-VoiceCall
  • mo-VideoCall
  • mo-SMS
  • mps-PriorityAccess
  • mcs-PriorityAccess
  • notAvailable
  • mo-ExceptionData

Why it matters

This is not just radio-side metadata. It can influence priority handling and special procedure behavior in the core.

Troubleshooting value

If the establishment cause does not match the scenario, you may see unexpected admission or service handling. The notAvailable value is especially important in fallback scenarios where resume or re-establishment maps back into connection establishment behavior.

High-value optional IEs

5G-S-TMSI

This is one of the most important optional fields. If the NG-RAN received 5G-S-TMSI from the radio interface, it should include it.

Why it matters

The AMF can use it for UE identification and AMF selection. In many practical traces, this is the quickest way for the core to associate the request with an existing UE context.

Troubleshooting value

If the AMF expected 5G-S-TMSI and it is absent, the procedure can fail. This is one of the first things to verify in service request and resume-like flows.

UE Context Request

This IE tells the AMF that the NG-RAN wants a context to be set up.

Why it matters

If present, it triggers Initial Context Setup from the AMF toward the NG-RAN.

Troubleshooting value

If the AMF never sends Initial Context Setup when expected, check whether this IE was actually present.

Allowed NSSAI

This optional IE carries slice information relevant to AMF handling and reroute logic.

Why it matters

Slice-aware AMF selection and UE processing can depend on this information in some flows.

Troubleshooting value

In network slicing issues, compare this field against the NAS Requested NSSAI / Allowed NSSAI logic and the selected AMF behavior.

AMF Set ID

This field is particularly important in reroute scenarios.

Why it matters

If present, it indicates that the message has been rerouted and the AMF should process it accordingly.

Troubleshooting value

If a Registration Request appears to land at the wrong AMF first and then gets redirected, this IE helps explain what happened.

Source to Target AMF Information Reroute

This IE appears in AMF reallocation scenarios.

Why it matters

It preserves reroute-related context when the message is redirected toward a new AMF.

Troubleshooting value

When debugging AMF reselection or rerouting, this IE can explain how context moved from the initial AMF to the target AMF.

Selected PLMN Identity

This field identifies the selected PLMN in applicable scenarios.

Why it matters

It becomes important in shared-network or multi-PLMN deployments.

Troubleshooting value

If the UE appears to be handled under the wrong PLMN context, inspect this IE together with TAI and NAS PLMN-related behavior.

Release-specific and deployment-specific optional IEs

Later releases extend Initial UE Message with optional fields such as:

  • IAB Node Indication
  • CE-mode-B Support Indicator
  • LTE-M Indication
  • EDT Session
  • Authenticated Indication
  • NPN Access Information
  • RedCap Indication

These fields are not present in every deployment, but they matter in specialized environments such as:

  • IAB
  • coverage enhancement scenarios
  • LTE-M / NB-IoT related deployments
  • non-public networks
  • RedCap deployments

For protocol databases and decoders, these optional fields should not be ignored just because they are rare. They often explain behavior that otherwise looks vendor-specific.

Common scenarios where Initial UE Message is used

1. Initial Registration

This is the classic case. The UE sends Registration Request, and the NG-RAN forwards it to the AMF in Initial UE Message.

This is the case most associate with Initial UE Message, and rightly so.

2. Registration Update while the UE is CM-IDLE

If the UE is not already in an active UE-associated NG connection, the RAN uses Initial UE Message to carry the NAS request to the AMF.

3. UE Triggered Service Request from CM-IDLE

In service request handling from CM-IDLE, the N2 step includes:

  • 5G-S-TMSI
  • selected PLMN / PLMN+NID
  • location information
  • establishment cause
  • UE Context Request

These are exactly the kinds of fields you inspect in an Initial UE Message decode for service restoration.

This is a very important distinction.

Initial UE Message

Use this when:

  • the NG-RAN has received the first uplink NAS message
  • a UE-associated NG signaling context is not yet fully in place for this exchange
  • the RAN needs to introduce the UE to the AMF side

Use this when:

  • the UE-associated NG context already exists
  • later UE-to-AMF NAS signaling is being exchanged

Practical decoder rule

If you are looking at the very first N2 NAS transfer after access establishment, it is typically Initial UE Message, not Uplink NAS Transport.

What to check in a live trace

Check 1: Does the NAS-PDU match the scenario?

Examples:

  • Registration flow should normally carry Registration Request
  • Service restoration should carry Service Request

If the wrong NAS message is present, the AMF response will look inconsistent even though the NGAP message itself may be perfectly encoded.

Check 2: Is 5G-S-TMSI present when expected?

This is a top troubleshooting point. Missing 5G-S-TMSI can cause identification or routing issues.

Check 3: Does the location information match the serving cell?

Verify:

  • PLMN
  • TAC
  • NR CGI

A mismatch here can explain AMF rejection, wrong policy, or wrong slice behavior.

Check 4: Is the RRC Establishment Cause reasonable?

For example:

  • mo-Signalling is common for registration
  • emergency has special handling implications
  • priority-related causes can affect treatment through the system

Check 5: Was UE Context Request set?

If the NG-RAN expected context setup and the AMF did not deliver it, verify whether this IE was actually present.

Check 6: Was the message rerouted?

Look for:

  • AMF Set ID
  • Source to Target AMF Information Reroute

These fields are strong clues in AMF reselection or reroute investigations.

Abnormal condition to remember

One subtle but important rule is this:

If the AMF expected 5G-S-TMSI in the Initial UE Message and it was not received, the AMF treats the procedure as failed.

This is a high-value log-analysis clue because the failure may look like a generic core-side reject unless you inspect the NGAP layer closely.

Decoder implementation notes

For a robust NGAP decoder or protocol database entry, handle Initial UE Message as:

  • an initiating-only NGAP elementary procedure

  • a message with mandatory core envelope IEs

  • a transparent carrier for a NAS-PDU

  • a message whose optional IEs materially affect:

    • AMF selection
    • rerouting
    • initial context setup
    • slice handling
    • special deployment behavior

Also make sure your decoder clearly separates:

  • NGAP envelope fields
  • embedded NAS content
  • location and identity context
  • release-specific optional extensions

That separation makes troubleshooting much faster in production logs.

Summary

If you are searching for 5G Initial UE Message, NGAP Initial UE Message decode, 3GPP TS 38.413 Initial UE Message, or how Registration Request reaches the AMF in 5G, the key idea is this:

Initial UE Message is the NGAP message that the NG-RAN uses to forward the UE’s first uplink NAS message to the AMF, together with the RAN-side identity, location, and establishment context required to begin core-network processing.

FAQ

What is Initial UE Message in 5G?

It is the NGAP message sent by the NG-RAN to the AMF to forward the UE's first uplink NAS message and establish the initial UE-associated NG signaling context.

Is Initial UE Message a NAS message?

No. It is an NGAP message that transports a NAS-PDU inside it.

What NAS message is usually carried in Initial UE Message?

Common examples are Registration Request and CM-IDLE Service Request related NAS messages.

What is the difference between Initial UE Message and Uplink NAS Transport?

Initial UE Message is used for the first uplink NAS transfer when no UE-associated NG context has been set up yet. Uplink NAS Transport is used later once the UE-associated NG context already exists.

Summary

NGAP initiating message used by the NG-RAN to transfer the UE's first uplink NAS message to the AMF.