Mobility Registration Update maintains an already registered UE’s mobility context when its location or negotiated registration information changes. It balances reachability with signaling load: a registered UE does not repeat initial registration after every cell change. Ordinary 3GPP access mobility within 5GS follows the paths below; EPS interworking and special access cases need additional procedures.
Identify the trigger and Registration Area
A Tracking Area (TA) is identified by a TAI. The Registration Area is the network-assigned set of TAs in which the UE may move without updating registration solely because of a TA change. If the assigned list contains TA1 and TA2, moving between them does not by itself require an update. Entry into TA3 outside that list is a typical mobility trigger, even if the same AMF serves all three TAs.
Leaving the Registration Area is not the only trigger. Changes to negotiated capabilities or protocol parameters and certain network indications can also require mobility registration updating without a TA change. Check the actual trigger and the 5GS registration type in Registration Request. Timer-driven periodic registration updating is a distinct case.
Read Registration Request in its access context
The UE normally retains a 5G-GUTI, registration parameters and a NAS security context. Registration Request identifies the update through the 5GS registration type. Depending on the applicable conditions, it can carry the existing 5G-GUTI, Last Visited Registered TAI, UE Security Capability, PDU Session Status and Requested NSSAI. These information elements are not an unconditional checklist for every request.
When the UE establishes a new RAN signaling context, the gNB forwards the NAS request in NGAP Initial UE Message with access-location information such as TAI and NR-CGI. If an appropriate UE-associated signaling connection already exists, NAS transport follows that existing connection. Initial UE Message is therefore not mandatory for every mobility update.
Separate same-AMF and inter-AMF processing
| Case | Context handling |
|---|---|
| Same serving AMF | The AMF uses its existing UE context, processes the new information and determines the applicable Registration Area. No inter-AMF context transfer is needed merely because the TA list changes. |
| New serving AMF | The new AMF identifies the old AMF using the existing temporary identity and applicable selection information, then attempts context retrieval where required. AMF selection is not a fixed one-to-one map from each TA. |
In the inter-AMF case, Namf_Communication_UEContextTransfer retrieves available identity, mobility and security context from the old AMF. The transferred information can include SUPI, GPSI and PEI where available, together with access and mobility context. Failure to locate or validate the old context can require identity and security procedures rather than making the UE permanently unidentifiable.
Context reuse does not guarantee that authentication is skipped. Identity Request/Identity Response and authentication such as 5G-AKA are performed when the specification and security conditions require them. A successful transfer also does not make every identity or security procedure mandatory. Inspect context validity and integrity checks before interpreting a shorter trace as incomplete.
Understand UDM, discovery and policy steps
When serving-AMF registration must change, the new AMF uses Nudm_UECM_Registration to update the UDM’s serving relationship for the relevant access. Under the specified conditions, UDM notifies the old AMF through Nudm_UECM_DeregistrationNotification. This clears the previous serving relationship; it should not be confused with a universal UE-facing deregistration exchange.
The AMF obtains or reuses the required subscription data and subscriptions to changes. Access and mobility data can include GPSI, subscribed slice information, subscribed UE-AMBR, periodic registration parameters, RAT restrictions and service-area restrictions. Separate SMF selection data can include DNN information associated with an S-NSSAI.
NRF discovery is used when needed to locate network functions; every update does not require a fresh discovery transaction. Likewise, the AMF selects or updates the PCF AM Policy Association when required rather than unconditionally establishing a new association. UDM registration, subscription retrieval and policy processing can be abbreviated when valid state is retained.
PDU Session Status helps reconcile session state. Existing sessions may require SMF context updates or user-plane activation, depending on the request and mobility case. Registration acceptance alone neither creates a new PDU session nor proves that user-plane service has resumed.
Interpret Registration Accept and completion correctly
Registration Accept provides the registration result and applicable parameters such as a TAI list, Allowed NSSAI and T3512. Do not assume every optional information element is present in every response. For a successful mobility registration update, a new 5G-GUTI is allocated according to TS 24.501; it can be supplied through the registration procedure or the applicable generic UE configuration update procedure.
The UE sends Registration Complete when confirmation is required, notably when Registration Accept contains a new 5G-GUTI. Its presence must be interpreted against the received information elements. The AMF can use NGAP Initial Context Setup when establishing the needed RAN context; other context and NAS transport procedures apply when that context already exists. Registration Accept is not invariably tied to a new Initial Context Setup exchange.
Follow a practical trace checklist
Confirm the trigger, stored TAI list, current TAI and registration type before examining later messages.
Identify the serving AMF and whether context transfer is actually required. For retrieval failures, check 5G-GUTI/GUAMI, AMF addressing and integrity results.
If processing stops in the core, inspect required UDM registration, subscription access, policy results and area restrictions; absence of an optional transaction is not proof of failure.
If acceptance does not reach the UE, correlate NAS, NGAP, RAN context and transport logs. Then check any required completion and session recovery separately.
FAQs
Does changing cell always trigger a mobility update?
No. A cell change or a TA change inside the assigned Registration Area alone does not require it. Other specified registration-update conditions can still apply.
Does leaving the Registration Area always change the AMF?
No. The same AMF may serve the new TA and update the UE’s Registration Area using its existing context.
How does periodic registration updating differ?
Its trigger is the applicable periodic timer behavior, not necessarily movement. Both use Registration Request, so inspect the registration type rather than relying on the message name.
Is movement from 4G to 5G the same procedure?
It can use the same registration type, but the source context differs. EPS-to-5GS interworking can involve MME context, mapped identities and N26 where supported. Do not apply an intra-5GS old-AMF flow to every EPS interworking case.
Technical references
For the registration framework and conditional core-network steps, see 3GPP TS 23.502, Release 18, especially clause 4.2.2.2.
For NAS triggers, temporary identities and completion conditions, see 3GPP TS 24.501, Release 18, especially clauses 5.4.4 and 5.5.1.3.
For the separate timer-driven case, read Periodic Registration Update.
