5GS registration type, 5GMM cause values returned later in Registration Reject
Main specification
3GPP TS 24.501, 8.2.6
What this message does 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 is used
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
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.
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
What this message does
The UE sends Registration Request as the opening NAS message for most 5G mobility and attach-style procedures.
Troubleshooting notes
Check whether the 5GS registration type matches the scenario under test.
Validate identity formatting when decoding SUCI fields.
If the network rejects the message, compare UE security capability against AMF policy.
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.
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.