NAS 5G AMF to UE 3GPP TS 24.501

5G NAS - Registration Accept

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.
Main specification	3GPP TS 24.501, 8.2.7
Release added	Release 15
Procedures where used	5G Initial Registration, Mobility Registration Update, Periodic Registration Update
Related timers	T3550, T3512
Related cause values	Registration Accept does not carry reject causes, Problems are inferred from missing mandatory context, bad timers, or later UE behavior

What is Registration Accept in simple terms?

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

Call flow position

Previous message(s): Registration Request, Authentication Response, Security Mode Complete

Next message(s): Registration Complete, Configuration update handling, PDU session establishment

Message direction and transport

Sender and receiver: AMF to UE

Interface: N1

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.

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 Accept is decoded using 24.501 NAS information element rules rather than ASN.1 syntax like RRC or NGAP.

Decoded Message 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

`5G-GUTI`

Provides the temporary UE identity the network allocates for later mobility management and paging correlation.

Presence: Optional

`TAI list`

Defines the tracking areas where the UE is considered registered and reachable.

Presence: Required

`Allowed NSSAI`

Tells the UE which requested or network-provided slices are actually allowed after registration.

Presence: Optional

`T3512 value`

Controls periodic registration update behavior and is one of the first timers engineers inspect after successful registration.

Presence: Optional

`LADN information / network feature support`

Carries optional service and local-area network context that explains later service behavior.

Presence: Optional

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.

Detailed explanation

5G NAS - Registration Accept Explained

Registration Accept is the 5G NAS success message the network sends when it accepts UE registration. In simple terms, it means the AMF has decided to register the UE and is now returning the mobility, identity, timer, and service context the UE should use in the 5GS.

For beginners, the simple meaning is: Registration Accept is the network saying “registration worked, here is your 5G operating context.”
For experienced engineers, it is one of the most useful NAS messages for checking final registration result, 5G-GUTI allocation, TAI scope, Allowed NSSAI, and periodic update timing.

What is Registration Accept in simple terms?

The UE asks to register by sending Registration Request. The network authenticates and secures the procedure. If everything is valid, the AMF sends Registration Accept back to the UE.

This message tells the UE:

registration was accepted
what temporary identity it should use
which tracking areas are valid
which slice context is allowed
what timer values and feature context apply next

Why this message matters

This message matters because many later behaviors depend on it:

paging and reachability often depend on the returned 5G-GUTI
mobility behavior depends on the returned TAI list
periodic update behavior depends on T3512
slice-related service behavior depends on Allowed NSSAI

So even when registration appears successful, engineers often come back to Registration Accept to understand why later behavior looks wrong.

Where this message appears in the call flow

A simplified successful path is:

UE sends Registration Request
AMF may trigger Identity and Authentication
NAS security is activated
AMF sends Registration Accept
UE responds with Registration Complete

Mini sequence:

UE                              gNB / AMF
|                                 |
|--- Registration Request ------->|
|<-- Authentication Request ------|
|--- Authentication Response ---->|
|<-- Security Mode Command -------|
|--- Security Mode Complete ----->|
|<-- Registration Accept ---------|
|--- Registration Complete ------>|

So Registration Accept sits at the point where the network finishes accepting the UE into 5GMM registered state.

Transport characteristics

sender: AMF
receiver: UE
interface: N1
transport on access side: commonly carried through DL Information Transfer
signaling context: NAS 5GMM
security expectation: usually integrity protected and often ciphered

On the radio side, this is not an RRC message by itself. It is a NAS payload that depends on access-side transport through RRC and NGAP signaling.

What Registration Accept means operationally

Operationally, Registration Accept is the AMF’s final positive registration decision plus the context the UE must use after success.

This is the message where engineers verify:

what registration result was actually granted
which temporary identity the UE should use next
where the UE is considered reachable
which slice context was really accepted
which timers will drive later mobility behavior

That is why this message often explains later paging, periodic update, or service issues even when the registration itself looked successful.

Important Information Elements

IE	Why it matters
`5GS registration result`	Confirms what type of registration was accepted.
`5G-GUTI`	Returned temporary identity used later in mobility and paging analysis.
`TAI list`	Shows where the UE is considered registered and reachable.
`Allowed NSSAI`	Explains what slice context the network actually accepted.
`T3512 value`	Drives periodic registration update timing.
`Network feature support`	Helps explain later service behavior such as IMS voice support.

Example message 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

Security Header Type should match the expected protected stage of the procedure.
5GS Registration Result tells you what kind of access registration the AMF accepted.
5G-GUTI should be saved and later matched against paging and mobility signaling.
TAI List tells the UE where it is registered without needing another update.
Allowed NSSAI explains whether the network accepted the slice context the UE wanted.
T3512 Value is important for later periodic registration update timing.

What to check in logs

verify that identity, authentication, and NAS security completed before the message arrived
inspect the returned 5G-GUTI and correlate it with later paging and mobility traces
check TAI List, Allowed NSSAI, and T3512 before troubleshooting later service behavior
confirm the UE follows with Registration Complete instead of silently restarting the procedure

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.

Summary

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.

Advanced Engineer Notes

In engineering work, Registration Accept is one of the most important places to inspect the network's final mobility-management decision rather than just the success status.
A clean accept message with a bad follow-on Registration Complete or later service failure should not automatically be diagnosed as a registration-accept problem.
Many field issues that appear later in paging, periodic updates, or slice behavior can be traced back to values first returned here.

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.

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.