| 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 |
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.
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.
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:
Next likely message: Authentication Request or Identity Request
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:
Next likely message: Authentication Request, Security Mode Command, or Registration Accept depending on context
Previous message(s): RRCSetupComplete, Initial UE Message
Next message(s): Authentication Request, Identity Request, Registration Accept
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.
This message is not typically analyzed as ASN.1 on the wire. It is usually read as a NAS or protocol field structure instead.
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.
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
| 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. |
5GS registration typeIndicates whether the request is initial, mobility update, periodic update, and so on.
Presence: Required
In practice: In practice, compare this field with the original request and with any later release-dependent optional fields so you can see whether the network accepted the same service model the UE asked for.
ngKSIIdentifies the key set in use or indicates that no valid native security context exists.
Presence: Required
In practice: In practice, compare this field with the original request and with any later release-dependent optional fields so you can see whether the network accepted the same service model the UE asked for.
5GS mobile identityUsually carries SUCI during initial registration.
Presence: Required
In practice: In practice, compare this field with the original request and with any later release-dependent optional fields so you can see whether the network accepted the same service model the UE asked for.
UE security capabilityLists NAS and AS security algorithms supported by the UE.
Presence: Optional
In practice: In practice, compare this field with the original request and with any later release-dependent optional fields so you can see whether the network accepted the same service model the UE asked for.
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.
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.
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.
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.
On initial registration it usually does, but later procedures may use a temporary identity depending on context.
Yes. After security is established, later registration updates can use a protected NAS header.
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.