這個UE屬於哪一位訂閱用戶？
是否允許這個UE存取目前的網路？
是否存在仍可重複使用的既有移動性上下文？
這個UE訂閱了哪些網路切片與存取能力，應由哪一個AMF提供服務？
5G裝置開機後，在建立使用者資料服務之前，核心網路必須先回答這些基本問題。這些工作會在5G初始註冊期間完成。從信令追蹤的角度來看，這個程序遠不只是簡單的「送出註冊請求，然後註冊成功」。從UE送出Registration Request，到最後回傳Registration Complete之間，網路可能需要進行身分處理、舊AMF上下文取得、5G-AKA認證、NAS安全建立、UDM註冊、訂閱資料取得以及存取策略處理。
研究這個程序時，常見的錯誤是試圖依序背下每一則訊息。更實用的方法，是理解AMF在每一個階段要解決什麼問題。完整信令路徑可以理解為：識別提出請求的UE、建立可信任身分、補齊必要的用戶上下文，最後才完成註冊。
初始註冊確立UE存取網路的資格
5GS中的註冊並不是單一程序。依觸發原因不同，UE可能執行Initial Registration、Mobility Registration Update、Periodic Registration Update或Emergency Registration。UE會透過Registration Request中的5GS registration type欄位指出目前適用的註冊程序。
Initial Registration通常發生在UE開機並進入5GS時。為了方便理解，它常被拿來與LTE/EPC的Attach程序比較，但兩者不應視為完全相同。在5G Core的服務化架構中，移動性管理、認證、訂閱資料與策略控制分散在AMF、AUSF、UDM及PCF等不同網路功能中。因此，一次註冊程序可能包含多個網路功能之間的服務化互動。
更重要的是，Initial Registration主要建立存取與移動性管理狀態，而不是建立使用者資料工作階段。網路必須識別UE、建立移動性上下文、確認允許的NSSAI與適用的區域限制，並建立後續信令所需的安全關係。只有在這些條件就緒後，UE才具備提出PDU Session請求的基礎。
因此，收到Registration Accept並不會自動表示用戶已經可以存取網際網路。註冊與PDU Session建立是5G Core中的兩個獨立階段。
Registration Request讓UE進入5G Core註冊流程
核心網路的註冊程序從NAS Registration Request開始。UE先透過無線介面將NAS訊息送到gNB，接著gNB在NGAP Initial UE Message中攜帶NAS-PDU送往AMF。對核心網路工程師而言，這則訊息就是整個註冊程序進入核心網路的起點。
除了攜帶Registration Request之外，Initial UE Message也會向AMF提供NR-CGI、TAI等存取位置資訊。NAS訊息本身還可能包含5GS registration type、5GS mobile identity、UE Security Capability與Requested NSSAI等參數。
這些參數不只是簡單的UE能力清單。AMF會利用它們判斷註冊程序應如何繼續。Registration Type用來確認UE執行的是Initial Registration或其他類型的註冊更新；mobile identity用來判斷既有的用戶上下文能否與該UE建立關聯；Requested NSSAI表示UE要求的網路切片；UE Security Capability則為後續NAS安全演算法選擇提供依據。
有一個細節很容易被誤解：執行Initial Registration的UE並不代表完全沒有先前的5G資訊。如果UE仍保存先前分配的5G-GUTI，它可以在新的Initial Registration Request中帶上該身分。網路能否直接重複使用與這個身分相關的資訊，會直接影響後續流程。
新AMF解析身分並取得既有UE上下文
假設某個UE先前已在廣州的5GS完成註冊，之後關機並移動到北京，再透過北京的gNB重新開機接入。此時UE由新的AMF提供服務，但仍可能保留先前由廣州AMF分配的5G-GUTI。
5G-GUTI中的GUAMI可以提供協助識別舊AMF的資訊。如果新AMF判斷舊網路功能仍可能保存有用的UE上下文，它可以透過AMF之間的通訊要求UE Context Transfer，並取得SUPI、GPSI、PEI以及部分移動性管理上下文等資訊。
這說明一個重要觀念：「Initial」描述的是目前這一次註冊程序的類型，並不表示該用戶第一次進入5G網路。UE仍可能保留先前分配的5G身分，而新AMF也可能重複使用舊AMF中的上下文。
並非每一次Initial Registration都需要與舊AMF互動。如果新AMF已經具備所需的身分資訊，或沒有可用的既有UE上下文，信令路徑可能會不同。如果AMF仍需要UE的SUCI，可以送出Identity Request，UE再透過Identity Response回傳所要求的身分。
因此，在封包追蹤中沒有看到Identity Request或UE Context Transfer，本身並不能代表註冊失敗。首先應確認AMF目前已經掌握哪些身分與上下文資訊。
5G-AKA將宣告的身分驗證為可信任用戶
僅知道UE聲稱自己是誰，還不足以讓網路信任該身分。因此，程序會進入最重要的安全階段之一：認證。
AMF必須找到能夠對該用戶進行認證的AUSF。在服務化5G Core中，這通常會透過NRF進行網路功能探索。AMF依所需服務與用戶相關資訊選擇合適的AUSF執行個體，並送出認證請求。
接著AUSF會與歸屬網路UDM相關的認證功能協同運作。使用SUCI時，歸屬網路可以還原對應的SUPI，並準備5G-AKA所需的認證資料。之後AMF透過NAS Authentication Request向UE送出RAND、AUTN等參數。UE使用USIM中保存的憑證執行認證計算，並在Authentication Response中回傳包含RES*的結果。
認證並不是由單一網路功能完成一次簡單比對。服務網路側與歸屬網路側會分別執行各自的驗證。AMF根據UE回傳的回應計算HRES*並與HXRES*比較，AUSF則將回傳的RES*與預期的XRES*進行驗證。只有所需的驗證都成功後，網路才會將該用戶身分視為已通過認證。
認證完成後，網路通常會建立或更新NAS Security Context。AMF依據UE Security Capability等資訊選擇適當的完整性保護與加密演算法，並透過Security Mode程序保護後續重要的NAS信令。
從工程角度來看，這個階段形成一條清楚的安全邊界：認證之前，網路處理的是一台正在要求存取的裝置；認證與NAS安全成功建立之後，AMF便擁有可信任且受保護的UE控制面上下文。
訂閱與策略資料補齊UE上下文
認證成功回答了「用戶身分是否真實」這個問題，但AMF仍需要知道該用戶在目前網路中實際被允許做什麼。下一階段會把已完成認證的身分進一步補齊成可供存取與移動性管理使用的上下文。
AMF選擇合適的UDM，並透過3GPP存取將自己註冊為目前服務該SUPI的AMF。這項註冊很重要，因為UDM需要知道之後與該用戶有關的移動性通知、去註冊事件或訂閱資料變更應該送到哪一個AMF。
接著AMF取得Access and Mobility Subscription Data。依用戶訂閱設定不同，其中可能包含Subscribed NSSAI、UE-AMBR、週期性註冊參數、RAT限制與區域限制。認證確認的是身分是否有效，而訂閱資料回答的是另一個問題：這個已確認有效的用戶，在目前網路中被允許做什麼？
AMF也可能取得之後用於SMF選擇的訂閱資料，包括與S-NSSAI、DNN以及預設DNN相關的資訊。閱讀信令追蹤時，這一點常造成混淆：如果註冊階段已經出現SMF Selection Subscription Data，是否表示SMF已經參與目前的程序？
不一定。此時AMF只是取得未來選擇SMF時可能需要的資訊。Initial Registration並不要求同時建立PDU Session，因此AMF可以在不建立SM Context、也不啟動實際SMF工作階段管理程序的情況下取得這些訂閱資料。
在存取策略方面，AMF也可以選擇PCF並建立AM Policy Association。PCF回傳的策略可能影響特定區域的存取限制等事項。到這個階段，AMF中保存的UE上下文已從基本身分資訊擴展成身分、安全、訂閱、切片、位置與策略資訊的組合。
Registration Accept將註冊結果套用到UE與gNB
前面的多數處理都發生在核心網路內部，但最終結果仍必須傳送到存取網路和UE。當所需條件全部滿足後，AMF向gNB送出Initial Context Setup Request，攜帶建立UE上下文所需的資訊，並將NAS Registration Accept傳遞給UE。
Registration Accept可以包含新分配的5G-GUTI、Allowed NSSAI、週期性註冊計時器T3512，以及適用的Tracking Area清單等資訊。這些參數決定UE如何維持在5GS中的註冊狀態、目前可使用哪些切片，以及之後何時需要執行Periodic Registration Update。
同時，gNB透過Initial Context Setup程序建立相應的UE上下文。完成處理後，gNB回傳Initial Context Setup Response。接著UE透過向AMF送出NAS Registration Complete確認註冊結果。
因此，Registration Accept與Registration Complete並不只是單純的成功通知。它們會把核心網路內部形成的註冊結果實際套用到UE與RAN，使網路、gNB及裝置進入一致的5GS註冊狀態。
註冊與PDU Session建立屬於不同的信令路徑
分析完整信令序列時，必須清楚區分這兩者。5GS Initial Registration完成後，AMF已知道用戶是誰、UE位於何處、允許哪些存取區域與切片，以及適用的安全和移動性上下文。但上述步驟都不會自動建立使用者面的資料路徑。
若UE要存取網際網路或企業資料網路，仍需要執行PDU Session Establishment。此時SMF負責工作階段管理，選擇或控制UPF，並透過N4下發PDR、FAR、QER與URR等使用者面規則。gNB與UPF之間的N3資源也會在工作階段建立過程中準備。
在實際疑難排解中，這會形成兩類完全不同的故障：
註冊失敗：重點檢查UE身分、認證、NAS安全、UDM訂閱資料、NSSAI、區域限制以及AMF策略處理。
註冊成功但資料服務無法使用：應將調查方向轉向PDU Session建立、SMF、UPF、N3/N4信令與使用者面轉送，而不是反覆檢查Registration Request與Registration Accept。
清楚掌握這條邊界可以大幅縮短5GC疑難排解時間。裝置顯示5G圖示，只代表無線存取與註冊已達到某個狀態；實際資料連線是否建立，仍取決於工作階段管理與使用者面程序。
把追蹤內容當成狀態轉換，而不是訊息清單
標準信令流程圖通常刻意設計得很完整，因為需要涵蓋不同電信業者、漫遊情境、存取類型以及選用的網路功能。但實際網路封包追蹤不一定會出現參考程序中的每一個步驟：可能沒有舊AMF互動、可能不需要Identity Request、可能未使用EIR，而一般NR存取程序也不會包含只適用於其他存取類型的網路功能。
排查Initial Registration時，更有效的方法是追蹤UE狀態如何逐步變化：
Registration Request抵達AMF
→ 解析UE身分與既有上下文
→ 建立認證與NAS安全
→ 從UDM取得訂閱資料
→ 從PCF取得適用的存取策略
→ AMF完成註冊上下文
→ 傳送Registration Accept
→ UE回傳Registration Complete
如果Registration Request已抵達AMF但認證始終沒有開始，應優先檢查身分處理與網路功能選擇。如果認證成功但沒有回傳Registration Accept，則繼續檢查UDM資料、NSSAI、存取限制與策略處理。如果Registration Accept已完成，而問題是使用者資料無法運作，調查方向就應迅速轉向PDU Session信令路徑。
因此，理解5G Initial Registration的重點並不是背下數十則訊息，而是追蹤AMF中的UE上下文如何逐步完整：從收到存取請求，到知道用戶是誰，再到證明該身分可信任，最後確認該用戶以哪些條件被允許維持5GS註冊狀態。
常見問題
Registration Accept中的T3512有什麼作用？
T3512控制UE註冊後的週期性註冊更新行為。UE不會在沒有週期性移動性管理互動的情況下無限期保持註冊。網路可以利用這個計時器定義UE何時應執行Periodic Registration Update。
為什麼有些商用5G註冊追蹤中看不到EIR？
設備身分檢查是選用功能。是否部署EIR，以及在什麼條件下觸發設備身分檢查，取決於電信業者的架構與營運政策。因此，在其他步驟正常的Initial Registration程序中沒有EIR信令，並不足以證明存在故障。
為什麼標準5G NR註冊流程中通常沒有N3IWF？
N3IWF主要用於不受信任的non-3GPP存取，例如某些透過Wi-Fi存取5G Core的情境。當UE透過標準3GPP NR存取直接連線到gNB時，存取路徑由NG-RAN提供，因此N3IWF通常不會出現在註冊信令中。
為什麼不同廠商追蹤中的NRF網路功能探索次數可能不同？
實際5G Core實作可能因網路功能探索快取、靜態設定、SCP部署模式以及廠商特定的服務路由行為而不同。因此，不需要在每一次服務操作之前都看到完整的NRF網路功能探索交換。分析追蹤時，應將已選擇的NF執行個體與後續服務請求建立關聯，而不是只根據NRF訊息數量判斷程序是否正確。
