在 5G 核心網路中，AMF 池通常用於提高可用性並實現負載分擔，但僅僅部署多個 AMF 實例並不足夠。當 gNB 連接到 AMF 池時，它不僅需要知道哪些 AMF 在線，還需要瞭解每個 AMF 服務的 GUAMI、支援的 PLMN 與網路切片、相對容量，以及某個 AMF 因維護退出服務時流量應如何重新定向。
N2 介面為這些資訊交換提供控制面通道。它承載於 SCTP 之上，並使用 NGAP 信令在 gNB 與 AMF 之間交換能力資訊和同步狀態。網路初始建立時，首先建立 SCTP 關聯，隨後執行 NG Setup 過程。運作期間，如果 AMF 的容量、GUAMI 資訊或 SCTP 端點發生變化，需要通過設定更新過程通知 gNB。在計畫維護之前，AMF 還可以指示哪些 GUAMI 即將不可用，並提供備用 AMF 的相關資訊。
因此，AMF 池中的 N2 介面應被理解為一種持續維護的控制關係，而不是一次設定後長期不變的連接。按照這一視角，就更容易把建立、更新和重選過程理解為一個完整的管理流程。
為甚麼 AMF 池僅有連接建立還不夠
從基本連通性的角度看，一旦 gNB 與 AMF 之間建立 SCTP 關聯，兩個節點就可以交換 NGAP 訊息。但對於 AMF 池而言，僅僅連通並不足夠。
一個服務區域內可能包含 AMF1、AMF2、AMF3 等多個 AMF 實例。gNB 不僅要知道這些 AMF 是否可達，還要知道它們支援哪些 GUAMI、PLMN 和切片，以及當前各 AMF 適合承擔多大的相對負載。否則，即使所有 SCTP 關聯都處於 UP 狀態，gNB 仍可能缺少為新 UE 選擇合適 AMF 所需的資訊。
N2 介面管理可以分為三個主要階段：
| 過程 | 典型觸發條件 | 主要目的 |
|---|---|---|
| N2 建立 | 站點首次啓用、網路啓動，或首次與某個 AMF 建立關聯 | 建立 SCTP 關聯，並通過 NG Setup 交換 gNB 與 AMF 參數 |
| AMF Configuration Update | 相對容量、GUAMI 資訊或 SCTP 端點發生變化 | 使 gNB 與最新 AMF 設定保持同步，並支援後續 UE 分配 |
| AMF Status Indication | 軟體升級、計畫維護，或其他導致 AMF 部分能力暫時不可用的情況 | 通知 gNB 特定 GUAMI 已不可用，並在需要時支援 AMF 重選 |
這三個過程分別對應 AMF 關係生命週期中的三個階段：初始探索、能力或設定變化，以及暫時退出服務。把它們放在一起理解，可以更清楚地看出 AMF 池如何在多個核心網路節點之間實現負載分擔和計畫維護。
SCTP 與 NG Setup 在 N2 建立過程中分別做甚麼？
在工程討論中，這一整個階段通常被統稱為“N2 建立”。但從協議層面看，它實際上由兩個連續步驟組成：先建立 SCTP 關聯，再執行 NGAP 的 NG Setup 過程。
gNB 首先需要獲得 AMF 側 N2 介面的 SCTP 端點地址。該地址可以靜態設定，也可以通過適當的地址解析機制取得。隨後，gNB 與 AMF 建立 SCTP 關聯。
典型的 SCTP 關聯建立包含四次交互：INIT、INIT ACK、COOKIE ECHO 和 COOKIE ACK。完成這些交互後，傳輸層即可承載 NGAP 信令。不過此時 gNB 仍未獲得所需的全部 AMF 服務資訊，因此還要繼續執行 NG Setup。
gNB 發送 NG Setup Request，其中可能包含 Global gNB ID、Supported TA List、RAN Node Name 和 Default Paging DRX 等資訊。從實際作用看，這條訊息用於告知 AMF：哪個 RAN 節點正在接入、該節點支援哪些追蹤區，以及其基本運作參數。
AMF 收到請求後返回 NG Setup Response。響應中包含關鍵的 AMF 側資訊，包括 AMF Name、Served GUAMI List、支援的 PLMN 資訊以及 RelativeAMFCapacity。
RelativeAMFCapacity 在 AMF 池中尤其重要。它不能簡單理解為某個 AMF 能支援的最大使用者數，而是一個相對容量參考值，gNB 可以據此比較多個 AMF，並為後續 UE 的 AMF 選擇和負載分擔作出決策。
如果池中包含 AMF1、AMF2 和 AMF3，gNB 可以通過相同流程與相關 AMF 建立 N2 關聯，並取得各節點返回的服務資訊和相對容量資訊。正是這些資訊，使多個 AMF 能夠作為協調工作的資源池運作，而不是彼此孤立的控制面節點。
封包擷取也能清楚看到這一順序：先出現 SCTP 握手，隨後是 NG Setup Request 和 NG Setup Response 訊息。基礎 N2 關聯準備就緒後，與 UE 相關的注冊和移動性信令即可使用這條已建立的控制面路徑。
為甚麼 AMF 能力變化時必須更新 gNB？
AMF 池的運作狀態並非靜態不變。在雲化 5G 核心網路中，隨著使用者需求增加，AMF 可能進行擴充；其 GUAMI 資訊、服務區域、端點地址或處理能力也可能發生變化。
如果 gNB 始終使用網路初始啓動時獲得的參數，RAN 側的 AMF 選擇邏輯可能無法反映核心網路的實際能力。這正是 AMF Configuration Update 過程發揮作用的場景。
該過程並不針對某個特定 UE，而是用於讓 AMF 向 NG-RAN 通知自身設定的變化。例如，AMF 擴充後，其相對處理能力可能提高，此時可以向 gNB 回報新的 RelativeAMFCapacity。GUAMI 資訊變化也可以通過同一過程同步，SCTP 端點地址的新增或刪除同樣如此。
例如，編排或管理系統檢測到 AMF1 承載的使用者數量顯著增加，並自動擴充其處理資源。擴充後，AMF1 能夠承擔更高比例的控制面負載，因此相應調整其容量值。
隨後，AMF1 向 gNB 發送 AMF CONFIGURATION UPDATE。訊息中可以包含更新後的 GUAMI 資訊、新的 RelativeAMFCapacity 值以及 SCTP 端點變化。gNB 套用更新後，返回 AMF CONFIGURATION UPDATE ACKNOWLEDGE。
此後，當有新的 UE 接入，或 gNB 需要重新執行 AMF 選擇時，就可以使用更新後的資訊，而不是繼續依賴網路初始啓動時學習到的舊值。
這體現了 AMF 池運作中的一個重要原則：負載分擔並不是在網路啓動時只計算一次，而是可以隨著核心網路資源變化持續調整。
這一點在雲原生 5G 核心網路中尤其重要。計算資源可以動態彈性擴縮，但計算能力增加並不會自動改變 RAN 側的 AMF 選擇行為。更新後的控制面參數還必須傳遞給 gNB。AMF Configuration Update 正是把核心網路資源變化與 RAN 側選擇行為變化連接起來的信令機制。
維護前，gNB 如何為 AMF 重選做好準備？
擴充意味著增加能力，而維護則相反：由於軟體升級、計畫維護或其他維運任務，某個 AMF 可能需要暫時不可用。
如果 AMF 未通知 NG-RAN 就直接離線，gNB 可能仍根據之前保存的資訊繼續選擇該 AMF，直到出現失敗。在 AMF 池中，更合理的做法是在 AMF 真正退出服務前，提前告知 gNB 哪些 AMF 識別即將不可用。
NGAP 中的 AMF Status Indication 過程用於處理這類 AMF 管理場景。
假設 AMF1 需要進行軟體升級。在維護開始前，AMF1 可以向 gNB 發送 AMF STATUS INDICATION，並識別即將不可用的 GUAMI。如果訊息中還包含 Backup AMF Name，例如 AMF2，並且相關能力得到支援，gNB 就可以在後續重選時將該 AMF 納入考慮。
gNB 收到狀態指示後，會將所指示的 GUAMI 視為不可用，並據此調整後續的 AMF 選擇和重選。
這並不意味著所有現有 UE 上下文都會在同一時刻被機械地從 AMF1 遷移到 AMF2。其目的在於：當後續需要執行 AMF 選擇或重選時，避免 NG-RAN 繼續選擇一個正在退出服務的 AMF。
例如，當某個 UE 之後發起移動性注冊更新時，gNB 可以將相關信令路由到另一個 AMF。新的 AMF 隨後可以繼續提供移動性管理功能，並在過程要求時為 UE 分配新的 5G-GUTI。
從維運角度看，AMF Status Indication 本質上是一種計畫退出服務機制。它把“AMF1 即將進入維護”這樣的維運事件轉換為 NG-RAN 能夠理解並在 AMF 真正不可用前使用的協議級狀態資訊。
AMF 池通過這三個過程究竟在管理甚麼？
如果分別學習 NG Setup、AMF Configuration Update 和 AMF Status Indication，它們很容易看起來像三個彼此無關的 NGAP 過程。但從 AMF 池整個生命週期來看，三者之間的關係就會清晰得多。
NG Setup 用於建立初始關係。 當 gNB 首次連接某個 AMF 時，需要知道正在與哪個 AMF 通信、該 AMF 提供哪些服務，以及它在池中的相對處理能力。
AMF Configuration Update 用於處理能力和設定變化。 此時 AMF 仍然可用，但其 GUAMI 資訊、相對容量或傳輸端點發生變化，因此 NG-RAN 需要刷新已保存的資訊。
AMF Status Indication 用於處理可用性變化。 當某個 AMF 準備維護或暫時退出服務時，gNB 需要把相關 GUAMI 視為不可用，並為後續 AMF 重選做好準備。
這三個過程共同維護 gNB 所需的一項關鍵運作檢視：哪些 AMF 可用、它們提供哪些服務、適合承擔多大的相對負載，以及哪些 AMF 正在退出服務。
因此，僅部署多個 AMF 實例並不能讓 AMF 池自動獲得高可用能力。gNB 必須持續維護最新的 AMF 能力與狀態檢視，並在執行選擇決策時使用這些資訊。只有這樣，多 AMF 部署才能真正支援負載分擔、彈性彈性擴縮和計畫維護。
同樣的邏輯也適用於故障排除。首先確認 SCTP 關聯是否正常，再檢查 NG Setup 是否成功完成。如果連接仍處於活動狀態但負載分配異常，應檢查 AMF Configuration Update 信令和 RelativeAMFCapacity；如果流量仍被導向正在退出服務的 AMF，則需要檢查 AMF Status Indication、GUAMI 可用性資訊以及 AMF 重選行為。
常見問題
封包擷取時如何快速區分 SCTP 故障與 NGAP 故障？
首先檢查 SCTP 關聯是否成功建立。如果 INIT、INIT ACK、COOKIE ECHO 和 COOKIE ACK 交互未完成，問題仍位於傳輸層。如果 SCTP 已建立，但沒有收到 NG Setup Response，或者返回了 NGAP 層錯誤，則應繼續檢查 NGAP 參數、TA 設定、PLMN 資訊和 AMF 側設置。
RelativeAMFCapacity 是否表示 AMF 能支援的最大 UE 數量？
不是。RelativeAMFCapacity 更適合理解為 AMF 池內使用的相對容量指標。它幫助 NG-RAN 在選擇時比較不同 AMF 的相對處理能力，不能直接把它解釋為絕對的使用者數量上限。
GUAMI 資訊變化後，只修改 AMF 本地設定為甚麼不夠？
gNB 已經保存了通過 N2 介面獲得的 AMF 服務資訊。如果 AMF 修改 GUAMI 設定卻沒有通知 NG-RAN，雙方對 AMF 識別和服務可用性的認知可能出現不一致。因此，需要通過相應的 NGAP 管理過程同步更新後的資訊。
AMF Status Indication 是否必須始終包含 Backup AMF Name？
不是。Backup AMF Name 是可選資訊。即使訊息中不包含它，NG-RAN 仍需處理被識別為不可用的 GUAMI，並執行相應的 AMF 管理和重選行為。如果包含 Backup AMF Name，且 NG-RAN 支援對應過程，則可以在重選時考慮指定的備用 AMF。
