Registration Accept is the 5GMM message the AMF sends when it accepts UE registration and returns the mobility, security, and reachability context the UE needs to operate in the 5GS.
Message Fact Sheet
Protocol
nas
Network
5g
Spec
3GPP TS 24.501
Spec Section
8.2.7
Direction
AMF to UE
Message Type
5GMM signaling
Full message name
5G NAS - Registration Accept
Protocol
NAS
Technology
5G
Direction
AMF to UE
Interface
N1
Signaling bearer / channel
NAS signaling / Dedicated NAS message, commonly transported over DL Information Transfer on the access side
Typical trigger
Sent after the network accepts initial registration, mobility registration update, periodic registration update, or a related re-registration flow.
Main purpose
Confirms successful 5G registration and delivers the accepted registration context, allowed NSSAI, timers, tracking-area information, and related network parameters.
Registration Accept is the 5GMM message the AMF sends when it accepts UE registration and returns the mobility, security, and reachability context the UE needs to operate in the 5GS.
Confirms successful 5G registration and delivers the accepted registration context, allowed NSSAI, timers, tracking-area information, and related network parameters.
Why this message matters
Registration Accept is the network's success message for 5G registration. It tells the UE that registration worked and gives back the identity, tracking-area, timer, and service context the UE will use next.
Where this message appears in the call flow
5G Initial Registration
Call flow position: Returned by the AMF after authentication and NAS security when the UE is successfully accepted into the 5GS.
Typical state: UE is moving into a registered 5GMM context.
Preconditions:
Registration Request has been received and validated.
Any required identity, authentication, and NAS security procedures have completed successfully.
The AMF has selected the registration context to return to the UE.
Next likely message: Registration Complete
Mobility Registration Update
Call flow position: Used when the network accepts a mobility-related registration update and returns refreshed mobility-management context.
Typical state: UE already has context but is updating it because of mobility or policy change.
Preconditions:
The UE has reached the AMF through a valid access path.
The AMF accepts the updated registration state.
Next likely message: Registration Complete or direct continuation into normal service
Domain: Core-side mobility management message with radio-side transport dependency
Signaling bearer: NAS signaling
Logical channel: Dedicated NAS message, commonly transported over DL Information Transfer on the access side
Transport / encapsulation: NAS 5GS message carried end-to-end between AMF and UE
Security context: Usually sent after NAS security is established, so engineers commonly expect integrity protection and often ciphering depending on procedure state.
Message Structure Overview
Registration Accept is a NAS 5GMM message, so engineers read it as a 24.501 information-element structure rather than an ASN.1 tree.
The message is operationally important because it is where the network returns the accepted mobility context, reachability scope, and periodic update behavior.
In traces, the most useful first checks are security protection, registration result, TAI list, allocated 5G-GUTI, and timer values such as T3512.
ASN.1 Message Syntax for 5G NAS - Registration Accept
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 Accept is decoded using 24.501 NAS information element rules rather than ASN.1 syntax like RRC or NGAP.
5G NAS - Registration Accept - Example Dump
Registration Accept
Extended Protocol Discriminator: 5G Mobility Management
Security Header Type: Integrity protected and ciphered
Message Type: Registration Accept
5GS Registration Result: 3GPP access
5G-GUTI: 02 F1 10 00 01 AB CD EF 12 34
TAI List:
PLMN: 001-01
TAC: 0x1001
TAC: 0x1002
Allowed NSSAI:
S-NSSAI: SST 1, SD 0x112233
T3512 Value: 54 minutes
Network Feature Support:
IMS voice over PS supported: true
How to read this dump
The first practical check is whether the message is protected as expected for the procedure stage.
5GS registration result should match the access type the UE is using and should not conflict with later service behavior.
5G-GUTI allocation is important because later paging, mobility update, and AMF correlation often depend on it.
T3512 is operationally important because wrong timer values can later look like periodic-registration issues rather than accept-message issues.
Important Information Elements
IE
Required
Description
5GS registration result
Yes
Confirms what kind of 5GS registration was accepted and whether the UE is registered for the expected service type.
5G-GUTI
Optional
Provides the temporary UE identity the network allocates for later mobility management and paging correlation.
TAI list
Yes
Defines the tracking areas where the UE is considered registered and reachable.
Allowed NSSAI
Optional
Tells the UE which requested or network-provided slices are actually allowed after registration.
T3512 value
Optional
Controls periodic registration update behavior and is one of the first timers engineers inspect after successful registration.
LADN information / network feature support
Optional
Carries optional service and local-area network context that explains later service behavior.
Detailed field explanation
5GS registration result
Confirms what kind of 5GS registration was accepted and whether the UE is registered for the expected service type.
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.
5G-GUTI
Provides the temporary UE identity the network allocates for later mobility management and paging correlation.
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.
TAI list
Defines the tracking areas where the UE is considered registered and reachable.
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.
Allowed NSSAI
Tells the UE which requested or network-provided slices are actually allowed after registration.
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.
T3512 value
Controls periodic registration update behavior and is one of the first timers engineers inspect after successful registration.
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.
LADN information / network feature support
Carries optional service and local-area network context that explains later service behavior.
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.
What to check in logs and traces
Confirm the Registration Accept follows the expected authentication and NAS security sequence.
Check whether the NAS security header matches the scenario. A successful post-security Registration Accept is usually protected.
Inspect the 5GS registration result and verify it matches the expected 3GPP or non-3GPP access context.
Decode the allocated 5G-GUTI carefully and correlate it with later paging and mobility-management traces.
Review the TAI list and ensure the UE is registered in the expected tracking-area scope.
Check Allowed NSSAI, timer values such as T3512, and any network feature support fields that explain later UE behavior.
Correlate what the UE sends next, especially Registration Complete or immediate service activity.
Common Issues and Troubleshooting
Registration Accept is present but the UE does not complete registration.
Likely cause: The UE may reject or mis-handle a returned parameter such as the 5G-GUTI, TAI list, or allowed slice context, or the trace may hide a later NAS issue.
What to inspect: Check the exact returned IE set, UE capability alignment, and whether Registration Complete or a status message follows.
Next step: Compare the accept message with a known-good trace and inspect the next UL NAS transfer from the UE.
Registration succeeds but later mobility or paging behavior is wrong.
Likely cause: The returned mobility context may be inconsistent, especially TAI list, 5G-GUTI handling, or timer configuration.
What to inspect: Check TAI list contents, GUTI allocation, periodic update timer values, and later paging identity usage.
Next step: Correlate the Registration Accept with later paging, mobility update, and deregistration traces.
The UE receives Registration Accept but slice or service behavior is unexpected.
Likely cause: Allowed NSSAI, feature support, or optional service-related IEs may differ from the requested or expected context.
What to inspect: Check Allowed NSSAI, LADN-related information, and network feature support fields.
Next step: Compare the accepted network context with the original Registration Request and subscription expectations.
LTE / 5G / Variant Comparison
LTE / EPS analogue
LTE uses Attach Accept or Tracking Area Update Accept in EPS NAS for similar success paths, but the 5GS message structure, slice context, and timer set differ.
FAQ
What does Registration Accept do in 5G?
It tells the UE that the AMF accepted registration and returns the mobility and service context the UE should use in the 5GS.
Who sends Registration Accept?
The AMF sends it to the UE over NAS, usually after authentication and NAS security are complete.
Is Registration Accept protected?
In most normal successful registration flows after NAS security setup, yes. Engineers commonly expect integrity protection and often ciphering.
What comes after Registration Accept?
The next common NAS message is Registration Complete, followed by normal service procedures such as session establishment or paging reachability.
Why is T3512 important in Registration Accept?
Because it controls periodic registration update behavior and strongly influences later mobility-management timing analysis.
Does Registration Accept include reject causes?
No. It is a success message. Problems are usually inferred from missing or inconsistent returned context, or from later UE behavior.
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.