Message Fact Sheet

Protocol	nas	Network	5g
Spec	3GPP TS 24.501	Spec Section	8.2.6
Direction	UE to AMF	Message Type	5GMM signaling

Full message name	5G NAS - Registration Request
Protocol	NAS
Technology	5G
Direction	UE to AMF
Interface	N1
Signaling bearer / channel	NAS signaling / Dedicated NAS message, often transported via RRCSetupComplete or ULInformationTransfer on the access side
Typical trigger	Initial registration, mobility registration update, periodic registration update, or re-registration after loss of context.
Main purpose	Allow the network to identify the UE, understand the registration type, and trigger authentication and security setup.
Main specification	3GPP TS 24.501, 8.2.6
Release added	Release 15
Procedures where used	5G Initial Registration, Mobility Registration Update, Periodic Registration Update
Related timers	T3510, T3560
Related cause values	5GS registration type, 5GMM cause values returned later in Registration Reject

What is Registration Request in simple terms?

Starts a 5G registration or mobility update by sending UE identity and registration intent to the core.

Allow the network to identify the UE, understand the registration type, and trigger authentication and security setup.

Why this message matters

Registration Request is the UE's opening 5G NAS message. It tells the AMF what kind of registration the UE wants, who the UE claims to be, and how the network should begin the registration procedure.

Where this message appears in the call flow

5G Initial Registration

Call flow position: First NAS message from UE toward the AMF after RRC connection establishment completes.

Typical state: UE moving from RM-DEREGISTERED or no valid 5GMM context toward registration.

Preconditions:

UE has selected a suitable cell and completed initial access.
RRC connection establishment has progressed far enough to carry NAS.
UE has chosen the intended registration type.

Next likely message: Authentication Request or Identity Request

Mobility Registration Update

Call flow position: Opening NAS message when the UE needs to refresh mobility management context because of mobility.

Typical state: UE has a previous context but must update registration with the network.

Preconditions:

UE has valid access to the cell.
Triggering mobility condition has occurred.

Next likely message: Authentication Request, Security Mode Command, or Registration Accept depending on context

Call flow position

Previous message(s): RRCSetupComplete, Initial UE Message

Next message(s): Authentication Request, Identity Request, Registration Accept

Message direction and transport

Sender and receiver: UE to AMF

Interface: N1

Domain: Core-side mobility management message with radio-side transport dependency

Signaling bearer: NAS signaling

Logical channel: Dedicated NAS message, often transported via RRCSetupComplete or ULInformationTransfer on the access side

Transport / encapsulation: NAS 5GS message carried end-to-end between UE and AMF

Security context: Plain NAS during initial registration is common; later mobility or periodic updates can use protected NAS headers when a valid NAS security context exists.

Message Structure Overview

Registration Request is a NAS 5GMM message rather than an ASN.1 RRC or NGAP message.
The message header identifies the protocol discriminator, security header type, and message type before the 5GMM information elements appear.
Engineers should focus first on registration type, identity form, ngKSI, and whether the message is plain or integrity protected.

Structure Syntax

This message is not typically analyzed as ASN.1 on the wire. Engineers usually inspect it as a NAS or protocol field decode rather than an ASN.1 tree.

Registration Request is typically decoded as a NAS 5GS message using 24.501 information element structure, not as an ASN.1 tree like RRC or NGAP.

Decoded Message Dump

Registration Request
  Extended Protocol Discriminator: 5G Mobility Management
  Security Header Type: Plain NAS
  Message Type: Registration Request
  5GS Registration Type: Initial Registration
  ngKSI: No key is available
  5GS Mobile Identity: SUCI
  UE Security Capability:
    5G-EA: 128-5G-EA1, 128-5G-EA2
    5G-IA: 128-5G-IA1, 128-5G-IA2

How to read this dump

Check whether the security header type matches the scenario. Plain NAS is normal for initial registration before NAS security exists.
The registration type must match the intended procedure. A mobility update value in an initial attach scenario is suspicious.
The identity form matters. SUCI is common in fresh registration, while later updates may use temporary identities depending on context.

Important Information Elements

IE	Required	Description
`5GS registration type`	Yes	Indicates whether the request is initial, mobility update, periodic update, and so on.
`ngKSI`	Yes	Identifies the key set in use or indicates that no valid native security context exists.
`5GS mobile identity`	Yes	Usually carries SUCI during initial registration.
`UE security capability`	Optional	Lists NAS and AS security algorithms supported by the UE.

Detailed field explanation

`5GS registration type`

Indicates whether the request is initial, mobility update, periodic update, and so on.

Presence: Required

`ngKSI`

Identifies the key set in use or indicates that no valid native security context exists.

Presence: Required

`5GS mobile identity`

Usually carries SUCI during initial registration.

Presence: Required

`UE security capability`

Lists NAS and AS security algorithms supported by the UE.

Presence: Optional

What to check in logs and traces

Confirm the 5GS registration type matches the call flow under test.
Inspect ngKSI and determine whether the UE claims an existing security context or no key available.
Decode the 5GS mobile identity carefully and verify SUCI formatting, PLMN, routing indicator, and protection scheme fields when present.
Correlate the NAS message with the surrounding RRC and NGAP transport messages, especially RRCSetupComplete and Initial UE Message.
Check what the AMF returns next: Authentication Request, Identity Request, Security Mode Command, Registration Accept, or Registration Reject.

Common Issues and Troubleshooting

Registration Request is present but the AMF immediately rejects or ignores the procedure.

Likely cause: The registration type, UE identity, or access context is inconsistent with the scenario or AMF expectation.

What to inspect: Check 5GS registration type, identity encoding, TAI, and whether the NAS message was transported correctly through Initial UE Message.

Next step: Compare the message with a known-good trace and validate identity and mobility context formatting.

Registration Request is missing from the trace even though the UE completed access.

Likely cause: The UE may have failed before building the dedicated NAS message, or the trace capture starts too late and misses RRCSetupComplete / NGAP transport.

What to inspect: Check RRCSetupComplete, Initial UE Message, and capture points on both access and N2 sides.

Next step: Expand trace scope and confirm the UE actually reached the NAS transfer step.

Registration fails after the message because of security negotiation.

Likely cause: UE security capability, ngKSI, or AMF policy is incompatible with what the network expects.

What to inspect: Check UE security capability fields and the subsequent Authentication Request / Security Mode Command exchange.

Next step: Validate configured algorithms and compare against a successful registration trace.

Detailed explanation

5G NAS - Registration Request Explained

Registration Request is the UE’s opening 5GMM NAS message for most 5G registration and registration-update procedures. It tells the AMF what kind of registration the UE wants, what identity it is presenting, and whether the UE already has usable NAS security context.

For beginners, the simple meaning is: this is the UE asking the 5G core network to register it or refresh its mobility context.
For engineers, it is one of the most important NAS messages in the entire database because it determines how the AMF will handle identity, authentication, security, and final registration outcome.

What is Registration Request in simple terms?

The UE sends this message to start or refresh its NAS registration relationship with the network. It tells the AMF:

what registration procedure branch is intended
what UE identity is available
whether existing security context is valid
what security capabilities the UE supports

Why this message matters

This message matters because many later NAS outcomes depend on it:

a wrong 5GS Registration Type can send the procedure down the wrong path
an unexpected identity format can trigger identity or reject handling
a bad ngKSI value can confuse security context handling
capability mismatches can surface later during authentication or security mode

If a registration trace looks wrong early, Registration Request is usually the first message engineers inspect closely.

Where this message appears in the call flow

UE                              gNB / AMF
|--- RRC Setup Complete -------->|
|--- Registration Request ------>|
|<-- Identity / Authentication --|
|<-- Registration Accept or -----|
|<-- Registration Reject --------|

On the access side, the NAS payload is commonly carried inside RRC Setup Complete and then forwarded toward the AMF in Initial UE Message.

Transport characteristics

Direction: UE to AMF
Interface: N1
Transport on access side: usually via RRC Setup Complete or UL Information Transfer
Security expectation: plain NAS is normal for fresh initial registration; protected NAS may appear in later update scenarios

What Registration Request means operationally

Operationally, this is the UE’s first clear statement of what it wants from the 5G core. It is the message that transitions the trace from radio-only access handling into actual 5GMM decision making.

In practice, the most useful first checks are:

5GS Registration Type
ngKSI
5GS Mobile Identity
UE Security Capability

Those fields explain what the AMF is likely to do next.

Important Information Elements

IE	Why it matters
`5GS Registration Type`	Tells the AMF whether this is initial registration, mobility update, periodic update, or another registration mode.
`ngKSI`	Shows whether the UE claims an existing native security context or no key available.
`5GS Mobile Identity`	Usually carries `SUCI` in fresh registration and is critical for identity troubleshooting.
`UE Security Capability`	Explains what NAS and AS algorithm support the UE advertises.

Example message dump

Registration Request
  Extended Protocol Discriminator: 5G Mobility Management
  Security Header Type: Plain NAS
  Message Type: Registration Request
  5GS Registration Type: Initial Registration
  ngKSI: No key is available
  5GS Mobile Identity: SUCI
  UE Security Capability:
    5G-EA: 128-5G-EA1, 128-5G-EA2
    5G-IA: 128-5G-IA1, 128-5G-IA2

How to read this dump

Read 5GS Registration Type first because it defines the intended procedure.
Check ngKSI next to understand security-context expectations.
Decode the mobile identity carefully, especially when SUCI is present.
Then correlate the request with the immediate AMF response such as identity, authentication, accept, or reject.

What to check in logs

verify that the registration type matches the scenario under test
inspect identity encoding and confirm whether SUCI or temporary identity usage is expected
check ngKSI and UE security capabilities before troubleshooting later authentication or reject behavior
correlate the NAS message with RRC Setup Complete and Initial UE Message to rule out transport problems

FAQ

Does Registration Request always contain SUCI?

On initial registration it usually does, but later procedures may use a temporary identity depending on context.

Can Registration Request be protected?

Yes. After security is established, later registration updates can use a protected NAS header.

Summary

Starts a 5G registration or mobility update by sending UE identity and registration intent to the core.

Advanced Engineer Notes

A plain Registration Request during initial registration is normal because NAS security is typically not established yet.
The same message name appears in multiple scenarios, so the registration type and identity form are critical for interpretation.
Troubleshooting often requires cross-correlation with RRCSetupComplete and Initial UE Message because transport issues can look like NAS issues.

LTE / 5G / Variant Comparison

LTE / EPS analogue

LTE uses Attach Request or Tracking Area Update Request in EPS NAS rather than 5GS Registration Request, so the high-level purpose is similar but the message structure and procedure naming differ.

Related message pages

Related Procedures

Related Tools

Use This Reference in Practice

Decode this message with the 3GPP Decoder, inspect the related message database, or open the matching call flow to see where this signaling step fits in the full procedure.