什麼時候會觸發AMF重分配？

帶AMF重分配的Initial Registration並不是所有5GC註冊的預設路徑。它的觸發條件比較明確：網路已經部署Network Slicing，而且最初接收Registration Request的AMF無法服務UE最終需要的網路切片。

在普通註冊場景中，gNB選擇的Initial AMF本身就支持所需S-NSSAI，因此身分處理、認證、訂閱資料取得以及Registration Accept都可以在同一個AMF上完成。

只有當後續流程獲得的新資訊表明當前AMF與UE允許使用或預設應使用的切片不匹配時，才需要進行重分配。其邏輯可以概括為：

Registration Request到達Initial AMF
           → Initial AMF執行必要的註冊處理
           → 獲得完整的UE訂閱與切片資訊
           → Initial AMF判斷自己無法服務目標S-NSSAI
           → 呼叫NSSF確定合適的服務範圍
           → 註冊流程移交給Target AMF

這裡需要避免一個常見誤解：同一條註冊信令中出現兩個AMF，並不自動意味著原AMF故障，也不代表發生了AMF Pool負載平衡。在這個流程中，真正的觸發原因是當前AMF的切片服務能力與UE最終需要的網路切片不匹配。

為什麼gNB一開始可能選到不合適的AMF？

第一次分析AMF重分配時，很容易認為是gNB做出了錯誤選擇。如果不同AMF分別服務不同切片，為什麼RAN不能從一開始就把UE送到正確的AMF？

主要原因是gNB執行第一次AMF選擇時，可能還沒有足夠的資訊。假設一輛聯網汽車第一次開機，所使用的5G USIM訂閱了兩個網路切片：

• eMBB切片（S-NSSAI1）：用於車載資訊娛樂和普通資料業務；

• V2X切片（S-NSSAI3）：用於車聯網通訊以及自動駕駛相關業務。

假設該使用者的Default S-NSSAI是V2X切片，但UE第一次進入5GS，沒有有效的5G-GUTI，並且Registration Request中也沒有攜帶Requested NSSAI。此時，gNB沒有直接依據判斷UE最終應該由與V2X切片關聯的AMF提供服務。

正常情況下，gNB在選擇AMF時可以利用GUAMI、UE請求的S-NSSAI以及本地AMF設定等資訊。但在這個場景中，GUAMI和Requested NSSAI都不可用，因此gNB只能依據當前已知資訊以及本地預設選擇策略，先選擇一個Initial AMF。

如果gNB最初選擇了服務eMBB切片的AMF1，Registration Request就會透過NGAP Initial UE Message被送到AMF1。

這個AMF最終與UE的切片需求不匹配，並不一定說明gNB設定錯誤。更準確的理解是：第一次選擇AMF時，RAN尚未掌握足夠資訊來確定UE最終需要的特定切片AMF。

Initial AMF如何發現切片不匹配？

當Registration Request到達Initial AMF後，AMF並不會立即查詢NSSF。此時它仍缺少足夠的使用者資訊，無法判斷自己是否就是最終正確的服務AMF。

AMF首先按照正常Initial Registration邏輯執行所需流程，包括UE身分處理、AUSF選擇、5G-AKA Authentication以及相關NAS安全過程。

這一階段的關鍵結果之一，是AMF確認UE身分並獲得SUPI。有了SUPI之後，Initial AMF即可定位合適的UDM，並取得UE的Access and Mobility Subscription Data。

到這個階段，網路掌握的資訊已經遠多於Registration Request剛到達時。UDM返回的訂閱資料可以包含使用者的Subscribed NSSAI和Default S-NSSAI。

繼續使用聯網汽車的場景：Initial AMF屬於eMBB服務域，但訂閱資料表明UE同時訂閱了eMBB和V2X，而Default S-NSSAI指向V2X，也就是S-NSSAI3。

此時Initial AMF最終能夠得出gNB先前無法得出的結論：雖然它可以接收並開始處理Initial Registration，但並不適合作為UE預設V2X切片的長期服務AMF。這個判斷就是觸發AMF重分配的關鍵點。

gNB階段：只有有限的存取資訊
           → Initial AMF階段：UE身分得到確認
           → UDM階段：獲得實際訂閱的NSSAI資訊
           → 發現當前AMF與目標切片不相容

因此，AMF重分配並不是註冊進行到一半時隨意改變決定，而是核心網路在使用者身分和切片資訊逐步完整後，能夠做出更準確的服務AMF選擇。

NSSF如何確定新的服務AMF？

當Initial AMF確認自己無法服務目標切片後，並不會自行隨便選擇另一個AMF，而是呼叫Network Slice Selection Function，也就是NSSF。

Initial AMF透過Nnssf_NSSelection服務發起Network Slice Selection請求。輸入資訊可以包括UE訂閱的S-NSSAI、當前AMF資訊以及UE當前TAI。目的在於確定當前註冊區域允許使用哪些切片，以及應該由哪個AMF集合提供服務。

NSSF返回的Authorized Network Slice Information可能包括：

• Allowed NSSAI：UE在當前條件下獲准使用的網路切片；

• Configured NSSAI：在需要時可以提供給UE的切片設定；

• Target AMF Set：能夠服務相關網路切片的AMF集合；

• Rejected NSSAI：在當前TA或相關條件下無法接受的切片。

需要區分Target AMF Set和Target AMF。NSSF首先要做的是確定哪個AMF集合合適，也就是根據切片與位置條件縮小候選範圍，而不是直接返回某一個具體AMF的位址。

獲得Target AMF Set後，Initial AMF可以利用NRF中註冊的NF執行個體資訊，查詢該集合中各AMF的位址、能力、權重和運作狀態，再決定由哪個具體Target AMF接手Registration。

這幾個網路功能之間的關係可以概括為：

UDM：提供UE的切片訂閱資訊
           → Initial AMF：判斷自身服務能力不匹配
           → NSSF：確定授權切片和Target AMF Set
           → NRF：提供集合內可用AMF執行個體資訊
           → Initial AMF：選擇Target AMF

在這個流程中，NSSF的作用並不是傳統意義上的負載平衡，而是把切片需求映射到能夠滿足該需求的AMF服務範圍。

Registration Request如何移交給Target AMF？

確定Target AMF之後，UE不需要重新發送一份全新的Registration Request。網路只需要把已經進行中的註冊流程以及必要上下文轉移過去，讓新的AMF繼續處理即可。

可使用兩種轉發機制：透過gNB間接轉發，或者由Initial AMF與Target AMF之間直接轉發。

透過gNB間接轉發

在間接轉發方式下，Initial AMF向gNB發送NGAP Reroute NAS Request。該訊息攜帶與原始Initial UE Message相關的資訊以及Target AMF Set ID，指示NG-RAN對當前NAS Registration訊息進行重新路由。

隨後，gNB向Target AMF發送新的Initial UE Message，其中包含原始Registration Request NAS-PDU。控制平面路徑可以表示為：

UE → gNB → Initial AMF → Reroute NAS Request → gNB → Target AMF

UE不需要重新進行RRC接入。NG-RAN只是將現有的Registration NAS訊息重新路由到合適的AMF。

AMF之間直接轉發

在直接轉發方式下，Initial AMF不會再把訊息送回gNB，而是透過5GC服務化介面，將N1訊息和Registration Context直接傳給Target AMF。

Initial AMF呼叫Namf_Communication_N1MessageNotify，並把完整的Registration Request連同Registration Context Container一起發送給Target AMF。

被轉移的資訊並不只是一條NAS訊息。Registration Context還可以包含UE Context、Access Type、gNB資訊、User Location、Allowed NSSAI、Configured NSSAI、Rejected NSSAI以及繼續處理註冊所需的其他資訊。

UE → gNB → Initial AMF → Namf_Communication_N1MessageNotify → Target AMF

兩種信令路徑不同，但目標相同：讓Target AMF拿到繼續Registration所需的NAS訊息和上下文，而無需從頭重新執行整個Initial Registration流程。

Target AMF接手後，會完成剩餘的註冊處理，並向UE返回Registration Accept。該回應反映切片選擇和AMF重分配結果，可能包含Allowed NSSAI、Configured NSSAI、Rejected NSSAI以及新分配的5G-GUTI。

從UE角度看，最重要的結果是註冊成功，網路返回當前區域可用的切片以及新的5GS行動性上下文。內部服務AMF的變化對UE基本透明。

如何在信令追蹤中確認AMF重分配？

帶AMF重分配的Initial Registration很容易被誤判為異常註冊路由，或者被認為第一次AMF選擇失敗。更有效的疑難排解方式不是逐條比較訊息編號，而是沿著兩條主線分析：切片如何確定，以及上下文如何轉移。

一條正常的信令序列應該能夠幫助工程師回答以下問題：

為什麼Registration Request最先到達這個Initial AMF？
           → Initial AMF從哪裡獲得UE的Subscribed / Default NSSAI？
           → 什麼原因使AMF判斷自己無法繼續服務UE？
           → NSSF返回的是哪個Target AMF Set？
           → 最終選擇了哪個具體Target AMF？
           → Registration Context透過哪條路徑轉移？

如果Initial AMF已經獲得切片訂閱資訊，也確認自己無法服務UE，但隨後沒有出現NSSF選擇流程，排查重點應放在NSSF發現、Nnssf_NSSelection請求以及相關Slice設定上。

如果NSSF已經返回Target AMF Set，卻無法確定具體Target AMF，接下來應檢查AMF Set設定、NRF中的NF Profiles、AMF執行個體狀態以及能力資訊。

如果已經出現NGAP Reroute NAS Request，但Target AMF始終沒有收到新的Initial UE Message，疑難排解重點就應從切片選擇轉向gNB上的NAS重新路由，以及到Target AMF的N2可達性。

如果使用直接轉發，則應在追蹤中檢查Namf_Communication_N1MessageNotify和Registration Context，而不是等待這條路徑中本來就不會出現的Reroute NAS Request。

從完整流程來看，AMF重分配解決的是一個非常具體的問題：第一次選擇AMF時可用資訊不完整，而核心網路在獲得完整使用者身分和切片訂閱資訊後，會重新修正服務AMF的選擇結果。

UE剛進入網路時，gNB可能只掌握有限的GUAMI資訊、Requested NSSAI資訊或本地預設AMF設定。完成認證和訂閱資料取得後，5GC才最終能夠判斷使用者獲准使用哪些切片。隨後NSSF把Slice Requirement轉換成Target AMF Set，NRF則幫助識別能夠繼續Registration的實際AMF執行個體。

因此，分析這條信令流程時，最有價值的問題不是“為什麼註冊進行到一半AMF突然變了？”，而是：網路是在什麼階段最終獲得了足夠的資訊，可以確定究竟應該由哪個AMF繼續為UE提供服務？

常見問題

AMF重分配與AMF Pool中的負載平衡相同嗎？

不相同。AMF Pool負載平衡通常關注多個AMF執行個體之間的容量、權重和高可用性分布；而這個流程中的AMF重分配，是因為Initial AMF無法服務UE最終需要的網路切片。兩種機制最終都可能讓UE使用不同的服務AMF，但觸發條件和信令邏輯有本質區別。

部署Network Slicing後，每次都需要NSSF選擇和AMF重分配嗎？

不需要。即使網路已經部署Network Slicing，只要gNB最初選擇的AMF已經能夠服務UE最終需要的切片，就無需進行AMF重分配。重分配只是註冊流程中的條件分支，並不是所有切片網路都必須執行的步驟。

UE能直接發現註冊過程中AMF發生了變化嗎？

從UE角度看，它主要關注Registration是否成功，以及網路返回哪些Allowed NSSAI、Configured NSSAI、Rejected NSSAI和5G-GUTI。AMF重分配和Registration Context轉移屬於5GC內部控制流程，對UE基本透明。

間接轉發和直接轉發哪一種一定更常見？

僅依據流程定義無法得出統一結論。實際採用哪種機制取決於5GC部署架構、供應商實作、AMF之間的服務化通訊能力，以及RAN和核心網路設定。實際疑難排解應以實際網路中觀察到的信令路徑為準。