Which subscriber does this UE belong to?

Is it allowed to access the current network?

Is there any previous mobility context that can still be reused?

Which network slices and access capabilities is it subscribed to, and which AMF should serve the UE?

When a 5G device powers on, the core network has to answer these basic questions before user data services can be established. They are handled during 5G Initial Registration. From a signaling-trace perspective, the procedure is far more than a simple "registration request followed by registration success." Between the UE sending a Registration Request and eventually returning Registration Complete, the network may perform identity handling, old AMF context retrieval, 5G-AKA authentication, NAS security establishment, UDM registration, subscription-data retrieval and access-policy processing.

A common mistake when studying this procedure is trying to memorize every message in sequence. A more practical approach is to ask what problem the AMF is solving at each stage. The complete signaling path can be understood as follows: identify the requesting UE, establish a trusted identity, complete the required subscriber context, and only then finalize registration.

Initial Registration Establishes the UE's Right to Access the Network

Registration in 5GS is not a single procedure. Depending on the trigger, the UE may perform Initial Registration, Mobility Registration Update, Periodic Registration Update or Emergency Registration. The UE indicates the applicable procedure through the 5GS registration type field in the Registration Request.

Initial Registration commonly occurs when a UE powers on and enters the 5GS. It is often compared with the LTE/EPC Attach procedure for learning purposes, but the two should not be treated as identical. In the 5G Core service-based architecture, mobility management, authentication, subscriber data and policy control are distributed across network functions such as the AMF, AUSF, UDM and PCF. A single registration procedure can therefore involve multiple service-based interactions between network functions.

More importantly, Initial Registration primarily establishes Access and Mobility Management state rather than a user data session. The network must identify the UE, establish mobility context, determine the allowed NSSAI and applicable area restrictions, and create the security relationship required for subsequent signaling. Only after these conditions are in place does the UE have the foundation needed to request a PDU Session.

For this reason, receiving a Registration Accept does not automatically mean that the subscriber can already access the Internet. Registration and PDU Session establishment are separate stages in the 5G Core.

Registration Request Brings the UE into the 5G Core

The core-network registration procedure begins with the NAS Registration Request. The UE first sends the NAS message over the radio interface to the gNB. The gNB then carries the NAS-PDU toward the AMF inside an NGAP Initial UE Message. For a core-network engineer, this message is the entry point of the entire registration procedure.

In addition to carrying the Registration Request, the Initial UE Message provides the AMF with access-location information such as NR-CGI and TAI. The NAS message itself may contain parameters including the 5GS registration type, 5GS mobile identity, UE Security Capability and Requested NSSAI.

These parameters are more than a simple list of UE capabilities. The AMF uses them to determine how the registration should proceed. The Registration Type identifies whether the UE is performing Initial Registration or another type of registration update. The mobile identity determines whether existing subscriber context can be associated with the UE. Requested NSSAI indicates the network slices the UE is requesting, while UE Security Capability provides input for subsequent NAS security algorithm selection.

One detail is easy to misunderstand: a UE performing Initial Registration does not necessarily have no previous 5G information. If the UE still stores a previously assigned 5G-GUTI, it may include that identity in a new Initial Registration Request. Whether the network can reuse information associated with that identity directly affects the next steps of the procedure.

The New AMF Resolves Identity and Previous UE Context

Consider a UE that was previously registered with a 5GS in Guangzhou, powered off, moved to Beijing and then powered on again through a Beijing gNB. The UE is now served by a new AMF, but it may still retain the 5G-GUTI previously assigned by the AMF in Guangzhou.

The GUAMI contained in the 5G-GUTI can provide information that helps identify the previous AMF. If the new AMF determines that the old network function may still hold useful UE context, it can request UE Context Transfer through inter-AMF communication and retrieve information such as SUPI, GPSI, PEI and portions of the mobility-management context.

This illustrates an important point: "Initial" describes the type of the current registration procedure. It does not mean that the subscriber is entering a 5G network for the first time. The UE may still hold a previously assigned 5G identity, and the new AMF may be able to reuse context from the old AMF.

Old AMF interaction is not required in every Initial Registration procedure. If the new AMF already has the identity information it needs, or if no previous UE context is available, the signaling path can be different. If the AMF still needs the UE's SUCI, it can send an Identity Request, and the UE returns the requested identity in an Identity Response.

As a result, the absence of an Identity Request or UE Context Transfer in a packet trace does not by itself indicate a registration failure. The first question should be what identity and context information the AMF already has.

5G-AKA Turns a Claimed Identity into a Trusted Subscriber

Knowing who the UE claims to be is not enough for the network to trust it. The procedure therefore moves into one of its most important security stages: authentication.

The AMF must identify an AUSF capable of authenticating the subscriber. In a service-based 5G Core, this commonly involves Network Function discovery through the NRF. Based on the required service and subscriber-related information, the AMF identifies an appropriate AUSF instance and sends an authentication request.

The AUSF then works with authentication functions associated with the home-network UDM. When SUCI is used, the home network can recover the corresponding SUPI and prepare the authentication data required for 5G-AKA. The AMF subsequently delivers parameters such as RAND and AUTN to the UE in a NAS Authentication Request. The UE performs the authentication calculation using credentials stored in the USIM and returns an Authentication Response containing RES*.

Authentication is not based on a single comparison performed by one network function. The serving side and home-network side perform their respective checks. The AMF derives HRES* from the response received from the UE and compares it with HXRES*. The AUSF verifies the returned RES* against the expected XRES*. Only when the required verification succeeds does the network accept the subscriber identity as authenticated.

After authentication, the network normally establishes or updates the NAS Security Context. Based on information such as UE Security Capability, the AMF selects appropriate integrity-protection and ciphering algorithms and uses the Security Mode procedure so that subsequent critical NAS signaling can be protected.

From an engineering perspective, this stage forms a clear security boundary: before authentication, the network is processing a device requesting access; after Authentication and NAS Security are successfully established, the AMF has a trusted and protected UE control-plane context.

Subscription and Policy Data Complete the UE Context

Successful authentication answers the question of whether the subscriber identity is genuine, but the AMF still needs to know what the subscriber is actually allowed to do in the network. The next stage turns an authenticated identity into an actionable access and mobility context.

The AMF selects the appropriate UDM and registers itself as the AMF currently serving the SUPI over 3GPP access. This registration is important because the UDM needs to know which AMF should receive later mobility-related notifications, deregistration events or subscription-data changes for that subscriber.

The AMF then retrieves Access and Mobility Subscription Data. Depending on the subscriber profile, this can include subscribed NSSAI, UE-AMBR, periodic registration parameters, RAT restrictions and area restrictions. Authentication therefore confirms that the identity is valid, while subscription data answers a different question: what is this valid subscriber permitted to do in the current network?

The AMF may also retrieve subscription data that will later be used for SMF selection, including information associated with S-NSSAI, DNNs and a default DNN. This often creates confusion when reading signaling traces: if SMF Selection Subscription Data already appears during registration, has the SMF already become part of the procedure?

Not necessarily. At this stage, the AMF is only obtaining information that may be needed for a future SMF selection. Initial Registration does not require a PDU Session to be established at the same time, so the AMF can retrieve this subscription data without creating an SM Context or involving an active SMF session-management procedure.

For access policy, the AMF may also select a PCF and establish an AM Policy Association. Policy returned by the PCF can influence matters such as access restrictions for particular areas. By this point, the UE context held by the AMF has evolved from a basic identity into a combination of identity, security, subscription, slicing, location and policy information.

Registration Accept Applies the Result to the UE and gNB

Most of the preceding work takes place inside the core network. The final result still has to be delivered to the access network and the UE. Once the required conditions are satisfied, the AMF sends an Initial Context Setup Request to the gNB, carrying information needed to establish the UE context and delivering the NAS Registration Accept toward the UE.

A Registration Accept can include information such as a newly assigned 5G-GUTI, Allowed NSSAI, the periodic registration timer T3512 and the applicable Tracking Area list. These parameters determine how the UE remains registered in the 5GS, which slices it may currently use, and when it will later need to perform a periodic registration update.

At the same time, the gNB establishes the corresponding UE context through the Initial Context Setup procedure. After completing its processing, the gNB returns an Initial Context Setup Response. The UE then acknowledges the registration result by sending a NAS Registration Complete to the AMF.

Registration Accept and Registration Complete are therefore more than simple success notifications. They apply the registration result created inside the core network to both the UE and the RAN, bringing the network, gNB and device into a consistent 5GS registration state.

Registration and PDU Session Establishment Are Separate Signaling Paths

This distinction is essential when analyzing the complete signaling sequence. Once 5GS Initial Registration is complete, the AMF knows who the subscriber is, where the UE is located, which access areas and slices are permitted, and which security and mobility context applies. None of these steps automatically establishes a user-plane data path.

To access the Internet or an enterprise data network, the UE still needs to perform PDU Session Establishment. At that stage, the SMF becomes responsible for session management, selects or controls the UPF, and provisions user-plane rules such as PDR, FAR, QER and URR over N4. N3 resources between the gNB and UPF are also prepared as part of the session-establishment process.

In operational troubleshooting, this creates two very different failure categories:

Registration failure: focus on UE identity, authentication, NAS Security, UDM subscription data, NSSAI, area restrictions and AMF policy processing.

Registration succeeds but data service does not work: move the investigation toward PDU Session establishment, SMF, UPF, N3/N4 signaling and user-plane forwarding rather than repeatedly inspecting Registration Request and Registration Accept.

Keeping this boundary clear can significantly shorten 5GC troubleshooting. A 5G indicator on the device only shows that radio access and registration have reached a certain state. Whether an actual data connection has been established still depends on session-management and user-plane procedures.

Read the Trace as a State Transition, Not a List of Messages

Standard signaling diagrams are intentionally comprehensive because they need to cover different operators, roaming scenarios, access types and optional network functions. A live network trace, however, will not necessarily contain every step shown in a reference procedure. There may be no Old AMF interaction, Identity Request may not be necessary, EIR may not be used, and a normal NR access procedure will not include network functions that only apply to other access types.

A more useful way to troubleshoot Initial Registration is to follow how the UE state changes:

       Registration Request reaches the AMF
       → UE identity and previous context are resolved
       → Authentication and NAS Security are established
       → Subscription data is retrieved from the UDM
       → Applicable access policy is obtained from the PCF
       → The AMF completes the registration context
       → Registration Accept is delivered
       → The UE returns Registration Complete    

If the Registration Request reaches the AMF but Authentication never begins, investigate identity handling and network-function selection first. If authentication succeeds but Registration Accept is not returned, continue with UDM data, NSSAI, access restrictions and policy processing. If Registration Accept has already completed and the problem is that user data does not work, the investigation should move quickly toward the PDU Session signaling path.

Understanding 5G Initial Registration is therefore less about memorizing dozens of messages and more about following how the UE context inside the AMF becomes progressively complete: from receiving an access request, to knowing who the subscriber is, to proving that identity is trusted, and finally to knowing how that subscriber is allowed to remain registered in the 5GS.

FAQ

What Does T3512 in Registration Accept Do?

T3512 controls the UE's periodic registration update behavior after registration. A UE does not remain registered indefinitely without periodic mobility-management interaction. The network can use this timer to define when the UE should perform a Periodic Registration Update.

Why Is EIR Missing from Some Commercial 5G Registration Traces?

Equipment identity checking is optional. Whether an EIR is deployed and under what conditions an Equipment Identity Check is triggered depend on the operator's architecture and operational policies. The absence of EIR signaling in an otherwise normal Initial Registration procedure is therefore not sufficient evidence of a fault.

Why Is N3IWF Normally Absent from a Standard 5G NR Registration?

N3IWF is mainly used for untrusted non-3GPP access, such as certain Wi-Fi access scenarios into the 5G Core. When the UE connects directly through a gNB over standard 3GPP NR access, the NG-RAN provides the access path, so N3IWF is not normally part of the registration signaling.

Why Can NRF Discovery Appear a Different Number of Times in Different Vendor Traces?

Real 5G Core implementations can differ because of NF discovery caching, static configuration, SCP deployment models and vendor-specific service-routing behavior. A complete NRF Discovery exchange therefore does not have to appear before every service operation. Trace analysis should correlate the selected NF instance with the subsequent service request rather than judging the procedure only by the number of NRF messages.