在5G網路中，UE完成註冊後，核心網路需要持續掌握UE大致所在的位置，以便在尋呼、入站服務或下行資料到達時能夠找到它。但UE不會一直停留在同一位置，它可能從一個Tracking Area移動到另一個Tracking Area，甚至離開目前AMF的服務範圍。如果UE每次移動後都重新註冊，控制面信令負擔會迅速增加；如果始終不更新位置，網路最終又可能無法判斷應該到哪裡尋找UE。 行動性註冊更新 正是為了在位置準確度與信令負擔之間取得平衡。
初次研究5GC信令時，一個常見問題是：UE明明已經註冊，為什麼移動到新區域後還要再次傳送Registration Request？切換到另一個gNB是否一定會觸發更新？進入新的Tracking Area是否就代表AMF必須更換？這些問題都指向同一個原則：UE仍然維持在5GS Registered狀態，但目前位置可能已經離開網路先前分配的Registration Area。因此，5GC需要更新UE的位置，判斷Serving AMF是否繼續維持不變，並為下一階段的移動分配適用的Registration Area。這不是再次執行開機初始註冊，UE也不會每次更換小區都重新註冊，而是用來維持UE的5GS行動性上下文連續性的機制。
離開Registration Area是行動性更新的關鍵觸發條件
5GC中的註冊不只包含Initial Registration。Registration Request中攜帶的5GS registration type可用來區分Initial Registration、Mobility Registration Update、Periodic Registration Update與Emergency Registration等流程。在行動場景中，最容易混淆的問題之一，就是Tracking Area（TA）與Registration Area之間的差異。
TA是網路進行位置管理所使用的基本區域之一，而Registration Area則是由一個或多個TA組成的範圍，AMF允許UE在此範圍內維持註冊狀態。Registration Area可以只包含一個TA，也可以包含多個TA。假設某個AMF服務TA1、TA2、TA3與TA4，但依照該UE的行動特性，只把TA1與TA2分配為目前的Registration Area。當UE從TA1移動到TA2時，它仍在已註冊區域內，因此不會只因TA改變就執行Mobility Registration Update。
當UE繼續移動到TA3，而TA3不屬於目前儲存的Registration Area時，情況就不同了。UE偵測到目前TAI已位於註冊區域之外，於是傳送新的NAS Registration Request，並將5GS registration type設定為 mobility registration updating。因此，小區變更不會自動觸發Mobility Registration Update，甚至TA變更也不一定會觸發。典型觸發條件是UE進入目前Registration Area之外的TA。
這正是Registration Area概念存在的意義。它允許UE在一定範圍內移動，而不需要每次跨越TA邊界都與5GC互動，藉此在位置準確度與控制面信令負載之間取得平衡。對於移動範圍較廣的UE，網路可以分配較大的TA清單；需要更精確的位置追蹤時，也可以縮小Registration Area。因此，Registration Area本身就是行動性管理政策的一部分。
Registration Request如何把既有行動性狀態帶回5GC？
Mobility Registration Update與Initial Registration最明顯的差異在於，UE並不是一個完全未知的用戶。它已完成5GS註冊，通常仍保留網路分配的5G-GUTI、Registration Area以及相關NAS上下文。因此，新的Registration Request不是從零開始建立身分，而是在告訴網路：「我還是你已經知道的那個UE，只是我的行動位置改變了。」
UE先透過新的gNB建立控制面存取，接著gNB在NGAP Initial UE Message中將NAS Registration Request送往AMF。除了NAS-PDU之外，Initial UE Message還提供目前NR-CGI與TAI等存取位置資訊。在典型的Mobility Registration Update中，Registration Request可能攜帶多個重要資訊元素：5GS registration type指出流程類型為mobility registration updating；5G-GUTI協助網路識別與UE上一次註冊相關的AMF或GUAMI；Last Visited Registered TAI提供UE先前註冊位置的參考；UE Security Capability描述所支援的NAS加密與完整性保護演算法；PDU Session Status反映UE認為仍處於啟用狀態的PDU Session；Requested NSSAI則可在適用時提供UE要求的網路切片。
因此，在信令追蹤分析中，第一個問題不應該是後續是否再次進行認證，而應先確認Registration Request本身是否明確表明這是Mobility Registration Update，而不是Initial Registration。如果註冊類型被錯誤解讀，後續整條信令流程就很容易從錯誤角度進行分析。
為什麼同AMF更新與跨AMF更新會走不同流程？
離開Registration Area不一定代表離開目前AMF的服務範圍。這項差異會直接決定後續信令流程的複雜程度，也是分析Mobility Registration Update時首先要辨識的分支之一。
Serving AMF維持不變
假設某個AMF同時服務TA1與TA2，而網路先前只把TA1分配為UE的Registration Area。當UE從TA1移動到TA2時，TA2位於目前Registration Area之外，因此需要執行Mobility Registration Update。不過，TA2仍屬於同一個AMF的服務範圍。
在這種情況下，並不存在真正的Old AMF到New AMF遷移。目前AMF已經持有UE的行動性上下文，只需要處理新的位置、更新Registration Area，並重新整理必要的政策或上下文資訊。Registration Area發生變化，但Serving AMF不變。
Serving AMF發生變化
當UE從一個AMF服務的TA移動到另一個AMF服務的TA時，流程會更加複雜。例如，UE可能已在AMF1下完成註冊，並取得與AMF1關聯的5G-GUTI。之後UE透過新的gNB進入AMF2的服務範圍，此時New AMF需要知道這個UE是誰、之前由哪個AMF為它服務，以及哪些上下文可以繼續沿用。
因此，跨AMF的Mobility Registration Update不只是位置更新，還涉及 將UE的行動性管理上下文從原Serving AMF移交 給新的Serving AMF。
New AMF如何找到Old AMF並取得UE Context？
在跨AMF移動場景中，New AMF收到Registration Request後首先要解決的問題，不是用戶能否建立資料服務，而是辨識先前由哪個AMF管理該UE。5G-GUTI在這裡扮演重要角色。暫時身分中與GUAMI相關的資訊可以協助網路識別先前服務該UE的AMF。New AMF據此確認Old AMF，並透過Namf_Communication服務要求既有的UE Context。
典型邏輯很直接：UE使用先前的5G-GUTI傳送Mobility Registration Update；New AMF從5G-GUTI中擷取與AMF相關的身分資訊；辨識出Old AMF；New AMF要求UE Context；Old AMF回傳可轉移的行動性上下文。這些回傳資訊可以協助New AMF恢復SUPI、GPSI、PEI以及部分Access and Mobility Context等身分與行動性資訊，使新的Serving AMF能夠以既有UE狀態為基礎繼續處理，而不是把裝置當成完全未知的UE。
從Old AMF取得上下文，不代表後續所有安全流程一定都能跳過。如果既有身分資訊或安全上下文不足，網路仍可能再次要求UE的SUCI，並依照目前安全條件執行身分驗證或5G-AKA認證。因此，分析信令時應避免兩種僵化假設：Mobility Registration Update不一定需要完整重新認證，但存在可用的Old AMF Context也不能保證認證絕對不會再次發生。是否出現Identity Request或完整5G-AKA，取決於所轉移的UE Context、NAS Security Context以及網路政策。
UDM、NRF與PCF如何完成Serving AMF接管？
從Old AMF取得UE Context並不代表服務關係已經完全轉移。在5GC中，用戶位置與服務狀態分散在多個網路功能之中。尤其是UDM必須知道目前由哪個AMF負責服務該UE。
New AMF可以透過NRF探索能提供所需服務的UDM，接著在UDM中登記新的3GPP Access Registration。這一步在跨AMF場景中特別重要，因為UDM中的Serving AMF紀錄需要從Old AMF轉移到New AMF。之後，UDM可向Old AMF觸發相應的Deregistration Notification，以釋放先前的服務關係。
New AMF還需要取得目前的Access and Mobility Subscription Data，其中可能包含GPSI、Subscribed NSSAI、UE-AMBR、週期性註冊參數、RAT限制與區域存取限制。如果後續PDU Session處理需要選擇SMF，AMF也可以取得SMF Selection Subscription Data，包括與相關S-NSSAI關聯的DNN與Default DNN資訊，並訂閱相應訂閱資料的變更。PCF則透過提供Access and Mobility Policy補充這個流程。New AMF可以選擇適當的PCF並建立AM Policy Association，以取得區域限制等行動性政策資訊。
這些步驟解決的是不同問題。Old AMF Context告訴New AMF，UE先前處於什麼狀態；UDM Registration告訴核心網路，目前由哪個AMF服務UE；Subscription Data告訴New AMF，該用戶被允許使用哪些服務；PCF Policy告訴AMF，目前適用哪些行動性與存取規則。因此，Mobility Registration Update不能簡化成「AMF更新一個TAI」。在跨AMF場景中，它同時完成行動性管理責任從一個AMF轉移到另一個AMF。
Registration Accept如何定義UE下一階段的移動範圍？
身分、上下文、訂閱資料與政策處理完成後，AMF需要把新的註冊狀態同時套用到gNB與UE。典型流程中，AMF可以透過NGAP Initial Context Setup Request在gNB中建立或更新UE相關上下文，同時向UE下發NAS Registration Accept。
Registration Accept最重要的意義並不只是表示註冊成功。該訊息也會提供用來定義UE下一階段移動行為的參數。跨AMF移動後可能會分配新的5G-GUTI，以反映新的Serving AMF；Allowed NSSAI指出目前允許UE使用的網路切片；T3512定義後續Periodic Registration Update相關的計時；TA List，也就是Registration Area，則告訴UE在不觸發同類型Mobility Registration Update的情況下，可以在哪些TA之間移動並維持註冊狀態。
gNB完成相應的上下文處理後，回傳Initial Context Setup Response，UE接著傳送Registration Complete，本次Mobility Registration Update至此完成。從狀態轉移角度，可以概括為：UE離開原有Registration Area；Registration Request把先前的行動性身分帶入5GC；網路判斷Serving AMF是否需要變更；如有需要，從Old AMF轉移UE Context；New AMF完成UDM註冊並取得必要的訂閱與政策資訊；Registration Accept下送新的5G-GUTI與Registration Area；最後UE回傳Registration Complete。
故障排除也可以沿著同一狀態鏈進行。如果Registration Request已經到達New AMF，但無法定位Old AMF，應重點檢查5G-GUTI、GUAMI與AMF定址。如果Old AMF Context已成功取得，但流程停在UDM階段，下一步應檢查UDM探索、AMF Registration以及訂閱資料取得。如果核心網路內部處理已完成，但Registration Accept仍未到達UE，則應繼續檢查政策結果、區域限制、NGAP下行信令與RAN上下文建立。理解5GC Mobility Registration Update的重點不是記住數十條HTTP/2與NGAP訊息，而是理解已註冊UE移動後，網路如何回答三個問題： UE現在在哪裡、應由哪個AMF繼續管理它，以及下一階段移動應套用哪個Registration Area？
常見問題
UE每次進入新的Tracking Area都要執行Mobility Registration Update嗎？
不一定。關鍵在於新的TA是否仍屬於UE目前的Registration Area。如果AMF已經把TA1與TA2分配為UE的Registration Area，那麼從TA1移動到TA2通常不會只因TA改變就觸發此更新。進入Registration Area之外的TA才是典型觸發條件。
Mobility Registration Update一定會更換AMF嗎？
不會。UE可能已離開目前Registration Area，但新的TA仍屬於同一個AMF的服務範圍。在這種情況下，Serving AMF維持不變。只有當UE進入需要由另一個AMF服務的區域時，才需要進行Old AMF到New AMF的上下文轉移。
每次Mobility Registration Update都會重複執行5G-AKA嗎？
不能假設存在固定規則。是否重複執行身分程序或5G-AKA，取決於目前可用的UE Context、NAS Security Context以及網路政策。如果有效上下文仍可繼續使用，部分安全流程可能不需要完整重複；如果身分或安全條件不足，網路則可能再次執行必要的認證步驟。
UE從4G移動到5G時的更新，與5GC內部的Mobility Registration Update有什麼不同？
兩種場景都可能使用Mobility Registration Update這個註冊類型，但行動性上下文的來源不同。完全在5GS內部的移動通常涉及Old AMF與New AMF之間的行動性上下文；而從4G到5G的閒置模式互通場景還可能涉及MME、N26以及EPS與5GS上下文之間的轉換。分析信令追蹤時，第一步應先判斷UE是在5GS內部移動，還是從EPC進入5GC。
