In a 5G network, once a UE has completed registration, the core network needs to maintain a general awareness of where that UE is located so it can be reached when paging, incoming services or downlink data arrive. A UE, however, does not remain in one place. It may move from one Tracking Area to another or even leave the service area of its current AMF. If the UE had to perform a new registration after every movement, control-plane signaling would become excessive. If it never updated its location, the network could eventually lose track of where to reach it. Mobility Registration Update is designed to balance location accuracy with signaling overhead.
A common question when first studying 5GC signaling is: if the UE has already registered, why does it need to send another Registration Request after moving to a new area? Does crossing into another gNB always trigger an update? Does entering a new Tracking Area always mean the AMF must change? These questions point to the same principle: the UE remains in the 5GS Registered state, but its current location may have moved outside the Registration Area previously assigned by the network. The 5GC therefore needs to update the UE's location, determine whether the serving AMF should remain the same, and assign the Registration Area that applies to the next stage of mobility. This is not another power-on registration, nor does the UE re-register every time it changes cell. It is a mechanism for maintaining continuity of the UE's 5GS mobility context.
Leaving the Registration Area Is the Key Mobility Update Trigger
Registration in the 5GC is not limited to Initial Registration. The 5GS registration type carried in the Registration Request distinguishes between procedures such as Initial Registration, Mobility Registration Update, Periodic Registration Update and Emergency Registration. In mobility scenarios, one of the most common sources of confusion is the difference between a Tracking Area (TA) and a Registration Area.
A TA is one of the basic areas used by the network for location management, while a Registration Area is a set of TAs within which the AMF allows the UE to remain registered. A Registration Area may contain only one TA or several TAs. Suppose an AMF serves TA1, TA2, TA3 and TA4, but assigns TA1 and TA2 to a particular UE as its current Registration Area based on mobility behavior. When that UE moves from TA1 to TA2, it is still inside the registered area and does not need to perform a Mobility Registration Update simply because the TA has changed.
The situation changes when the UE moves on to TA3 and TA3 is not part of the currently stored Registration Area. The UE detects that the current TAI is outside its registered area, sends a new NAS Registration Request and sets the 5GS registration type to mobility registration updating. A cell change therefore does not automatically trigger a Mobility Registration Update, and even a TA change does not always trigger one. The typical trigger is entry into a TA that lies outside the UE's current Registration Area.
This is the purpose of the Registration Area concept. It allows a UE to move within a defined range without interacting with the 5GC every time it crosses a TA boundary, helping balance location accuracy against control-plane signaling load. The network may assign a larger TA list to a UE with a broader mobility pattern or reduce the Registration Area when more precise location tracking is desirable. The Registration Area itself is therefore part of mobility-management policy.
How Does the Registration Request Carry Existing Mobility State Back into the 5GC?
The clearest difference between Mobility Registration Update and Initial Registration is that the UE is not an entirely unknown subscriber. It has already completed 5GS registration and normally retains information such as the network-assigned 5G-GUTI, its Registration Area and relevant NAS context. The new Registration Request is therefore not used to establish identity from scratch. Instead, it tells the network: "I am the same UE you already know, but my mobility location has changed."
The UE first establishes control-plane access through the new gNB. The gNB then carries the NAS Registration Request to the AMF in an NGAP Initial UE Message. In addition to the NAS-PDU, the Initial UE Message provides access-location information such as the current NR-CGI and TAI. In a typical Mobility Registration Update, the Registration Request may carry several important information elements: the 5GS registration type identifies the procedure as mobility registration updating; the 5G-GUTI helps the network identify the AMF or GUAMI associated with the UE's previous registration; the Last Visited Registered TAI provides a reference to the UE's previously registered location; UE Security Capability describes the supported NAS ciphering and integrity-protection algorithms; PDU Session Status reflects which PDU Sessions the UE believes are still active; and Requested NSSAI can provide the network slices requested by the UE when applicable.
During trace analysis, the first question should therefore not be whether authentication occurs later in the procedure. The first check is whether the Registration Request itself clearly identifies this as a Mobility Registration Update rather than an Initial Registration. If the registration type is interpreted incorrectly, the rest of the signaling flow can easily be analyzed from the wrong perspective.
Why Do Same-AMF and Inter-AMF Updates Follow Different Paths?
Leaving the Registration Area does not necessarily mean leaving the service area of the current AMF. This distinction directly determines how complex the rest of the signaling procedure becomes and is one of the first branches to identify during Mobility Registration Update analysis.
Serving AMF Remains the Same
Suppose an AMF serves both TA1 and TA2, while the network previously assigned only TA1 as the UE's Registration Area. When the UE moves from TA1 into TA2, TA2 lies outside its current Registration Area, so a Mobility Registration Update is required. However, TA2 is still within the service area of the same AMF.
In this case, there is no actual Old AMF-to-New AMF migration. The current AMF already holds the UE's mobility context and only needs to process the new location, update the Registration Area and refresh any required policy or context information. The Registration Area changes, but the Serving AMF does not.
Serving AMF Changes
The procedure becomes more complex when the UE moves from a TA served by one AMF into a TA served by another AMF. For example, the UE may have completed registration under AMF1 and received a 5G-GUTI associated with AMF1. After moving through a new gNB into the service area of AMF2, the new AMF needs to know who the UE is, which AMF previously served it and which context can be reused.
An inter-AMF Mobility Registration Update is therefore more than a location update. It also involves handover of the UE's mobility-management context from the previous serving AMF to the new one.
How Does the New AMF Find the Old AMF and Retrieve UE Context?
In an inter-AMF mobility scenario, the first problem the New AMF must solve after receiving the Registration Request is not whether the subscriber can establish data service. It is identifying which AMF previously managed the UE. The 5G-GUTI plays an important role here. GUAMI-related information contained in the temporary identity helps the network identify the AMF that previously served the UE. The New AMF can then determine the Old AMF and request the existing UE Context through the Namf_Communication service.
The typical logic is straightforward: the UE sends a Mobility Registration Update using its previous 5G-GUTI; the New AMF extracts the AMF-related identity from the 5G-GUTI; the Old AMF is identified; the New AMF requests the UE Context; and the Old AMF returns the mobility context that can be transferred. This returned information can help the New AMF recover identity and mobility information such as SUPI, GPSI, PEI and parts of the Access and Mobility Context, allowing the new serving AMF to continue from an existing UE state rather than treating the device as completely unknown.
Obtaining context from the Old AMF does not mean that every subsequent security procedure can always be skipped. If the available identity information or security context is insufficient, the network may still request the UE's SUCI again and perform identity verification or 5G-AKA Authentication according to the current security conditions. Trace analysis should therefore avoid two rigid assumptions: Mobility Registration Update does not always require a complete new authentication, but an available Old AMF Context does not guarantee that authentication will never occur. Whether Identity Request or full 5G-AKA appears depends on the transferred UE Context, the NAS Security Context and network policy.
How Do UDM, NRF and PCF Complete the Serving-AMF Takeover?
Retrieving the UE Context from the Old AMF does not mean that the service relationship has been fully transferred. In the 5GC, user location and service state are distributed across several network functions. In particular, the UDM needs to know which AMF is now responsible for serving the UE.
The New AMF can use the NRF to discover a UDM providing the required services and then register the new 3GPP Access Registration in the UDM. This step is especially important in an inter-AMF scenario because the serving-AMF record in the UDM needs to move from the Old AMF to the New AMF. The UDM can then trigger the relevant Deregistration Notification toward the Old AMF so the previous serving relationship can be released.
The New AMF also needs the current Access and Mobility Subscription Data, which may include GPSI, Subscribed NSSAI, UE-AMBR, periodic registration parameters, RAT restrictions and area-access restrictions. If later PDU Session handling requires SMF selection, the AMF can also retrieve SMF Selection Subscription Data, including DNN and Default DNN information associated with the relevant S-NSSAI, and subscribe to changes in the corresponding subscription data. The PCF complements this process by providing Access and Mobility Policy. The New AMF can select the appropriate PCF and establish an AM Policy Association to obtain mobility-policy information such as area restrictions.
These steps solve different problems. The Old AMF Context tells the New AMF what state the UE previously had. UDM Registration tells the core network which AMF now serves the UE. Subscription Data tells the New AMF what the subscriber is allowed to use. PCF Policy tells the AMF which mobility and access rules currently apply. For that reason, a Mobility Registration Update should not be reduced to "the AMF updates a TAI." In an inter-AMF scenario, it also transfers responsibility for mobility management from one AMF to another.
How Does Registration Accept Define the UE's Next Mobility Range?
Once identity, context, subscription data and policy processing are complete, the AMF needs to apply the new registration state to both the gNB and the UE. In a typical procedure, the AMF can use an NGAP Initial Context Setup Request to establish or update UE-related context in the gNB while delivering the NAS Registration Accept to the UE.
The most important part of the Registration Accept is not simply that registration has succeeded. The message also provides parameters that define how the UE should operate during the next stage of mobility. A new 5G-GUTI may be assigned after an inter-AMF move to reflect the new serving AMF. Allowed NSSAI identifies the network slices currently permitted for the UE. T3512 defines the timing associated with future Periodic Registration Update. The TA List, or Registration Area, tells the UE which TAs it may move through while remaining registered without triggering another Mobility Registration Update of the same type.
After the gNB completes the corresponding context processing, it returns an Initial Context Setup Response, and the UE sends Registration Complete. The current Mobility Registration Update is then finished. From a state-transition perspective, the flow can be summarized as follows: the UE leaves its existing Registration Area; the Registration Request carries the previous mobility identity into the 5GC; the network determines whether the Serving AMF must change; UE Context is transferred from the Old AMF when required; the New AMF completes UDM registration and obtains the necessary subscription and policy information; Registration Accept provides the new 5G-GUTI and Registration Area; and the UE finally returns Registration Complete.
Troubleshooting can follow the same state chain. If the Registration Request reaches the New AMF but the Old AMF cannot be located, checks should focus on the 5G-GUTI, GUAMI and AMF addressing. If the Old AMF Context is successfully retrieved but the procedure stops at the UDM stage, the next checks should cover UDM discovery, AMF Registration and subscription-data retrieval. If the internal core-network processing completes but no Registration Accept reaches the UE, the investigation should continue with policy results, area restrictions, NGAP downlink signaling and RAN context establishment. The goal of understanding 5GC Mobility Registration Update is therefore not to memorize dozens of HTTP/2 and NGAP messages, but to understand how the network answers three questions after a registered UE moves: where is the UE now, which AMF should continue managing it, and which Registration Area should apply to its next period of mobility?
FAQ
Does the UE Perform a Mobility Registration Update Every Time It Enters a New Tracking Area?
Not necessarily. The key question is whether the new TA is still part of the UE's current Registration Area. If the AMF has already assigned TA1 and TA2 as the UE's Registration Area, moving from TA1 to TA2 would not normally trigger this update simply because the TA changed. Entering a TA outside the Registration Area is the typical trigger condition.
Does Mobility Registration Update Always Change the AMF?
No. The UE may leave its current Registration Area while the new TA still belongs to the service area of the same AMF. In that case, the Serving AMF remains unchanged. Old AMF-to-New AMF context transfer is required only when the UE moves into an area that needs to be served by another AMF.
Does Every Mobility Registration Update Repeat 5G-AKA?
No fixed rule should be assumed. Whether identity procedures or 5G-AKA are repeated depends on the available UE Context, NAS Security Context and network policy. If valid context can continue to be used, some security procedures may not need to be repeated in full. If identity or security conditions are insufficient, the network may perform the necessary authentication steps again.
How Is a 5GC Mobility Registration Update Different from an Update When a UE Moves from 4G to 5G?
Both scenarios may use the Mobility Registration Update registration type, but the source of the mobility context is different. Mobility entirely within the 5GS typically involves mobility context between an Old AMF and a New AMF. An idle-mode interworking scenario from 4G to 5G may additionally involve the MME, N26 and translation between EPS and 5GS context. When analyzing a signaling trace, the first step is to determine whether the UE is moving within the 5GS or entering the 5GC from the EPC.
