在擷取 5G 註冊信令時，工程師通常不難找到 Initial UE Message、Uplink NAS Transport 等 NGAP 訊息。真正更難的問題往往在底層：一個 N2 信令封包如何離開 gNB，穿過傳輸網路和資料中心，最終到達執行 AMF 服務的伺服器？如果 AMF 已虛擬化並執行在 VM 中，gNB 實際上是與哪個端點建立 SCTP 關聯？PTN 閘道、資料中心邊界路由器、EOR 交換器和 TOR 交換器分別起什麼作用？當信令失敗時，故障排除應從 NGAP、SCTP、IP 路由，還是第 2 層 MAC 轉送開始？

這些問題看起來分屬不同的工程領域。無線團隊關注 gNB，核心網路團隊關注 AMF 和 NGAP，傳輸團隊負責 PTN，資料中心團隊則管理交換器和伺服器。但在一條正常工作的 N2 路徑中，這些元件實際上構成一條連續的鏈路。gNB 收到的 NAS Registration Request 並不會直接“跳”到 AMF。gNB 先把訊息從 RRC 側中繼到 NGAP，再透過 SCTP 和 IP 封裝，經過多個第 3 層和第 2 層網路節點，最終送入執行 AMF 程序的運算環境。將邏輯協定路徑與實際實體網路路徑結合起來看，比簡單做一次“能不能 ping 通 AMF”的測試，更容易定位 N2 路由問題。

N2 介面實際在轉送什麼？

N2 是 gNB 與 AMF 之間的信令介面。在 UE 註冊、移動性管理及其他 5G 控制面程序中，UE 產生 NAS 訊息，而 gNB 承擔關鍵的中繼作用。gNB 將從 UE 接收到的 NAS-PDU 放入相應的 NGAP 訊息中，再透過 N2 傳送至 AMF；下行方向則執行相反過程。因此，理解 N2 信令時，需要把應用層訊息本身與承載該訊息的傳輸路徑區分開來。

以 UE 發起註冊為例。UE 首先透過無線協定堆疊向 gNB 傳送 NAS Registration Request。對於這類信令，gNB 不是最終的應用端點，它的作用是把 NAS-PDU 放入 NGAP 訊息，並透過已經建立的 N2 傳輸關係轉送給 AMF。從較高層次看，UE 側依次透過 NAS、RRC、PDCP、RLC、MAC 和 L1 處理該訊息；在 gNB 側，NAS 訊息從無線側協定堆疊中繼到 NGAP，然後透過 SCTP、IP、第 2 層和第 1 層承載；到達 AMF 後，封包按相反方向逐層解封裝，直到 NAS 訊息進入 NAS 處理層。

一個常見誤解是把“gNB 轉送 NAS”理解成與 IP 路由器相同的轉送。實際上兩者發生在不同層次。gNB 首先完成從 NAS/RRC 到 NGAP 的協定級中繼，並生成新的 N2 側 SCTP/IP 封包。傳輸網路和資料中心網路不需要理解酬載中究竟是 Registration Request 還是其他 NAS 程序，它們只需依據 IP 路由、MAC 位址和介面資訊轉送封包。

NGAP 程序還可以分為 UE 關聯程序和非 UE 關聯程序。NAS Transport 和 Initial Context Setup 屬於 UE 關聯程序，而 NG Setup 屬於節點級非 UE 關聯程序。這個區分在故障排除中很有用：如果某個 gNB 下所有 UE 都無法與 AMF 通訊，應優先檢查節點級 N2 關係、SCTP 和 IP 路由；如果只有一個 UE 受影響，則應沿該 UE 的 NGAP 和 NAS 上下文繼續故障排除。

N2 信令從 gNB 到 AMF 會經過哪些網路節點？

邏輯架構圖通常把 N2 畫成 gNB 與 AMF 之間的一條直線。這種表示方式便於說明介面關係，卻看不到信令流量實際經過的網路路徑。在真實部署中，gNB 很少透過一條實體鏈路直接連接到 AMF 伺服器。RAN 與核心網路資料中心之間通常存在傳輸網路，而資料中心內部還會使用路由器、交換器以及伺服器網路。

一條簡化的 N2 傳輸路徑可以表示為：gNB 先把流量傳送給第 3 層 PTN 閘道，封包穿過傳輸網路到達資料中心第 3 層邊界路由器，再經過 EOR 和 TOR 交換器，最終到達承載 AMF 的伺服器。PTN 負責把 gNB 側 IP 流量傳送至區域或中心資料中心；資料中心邊界的第 3 層路由器再把 N2 封包路由到正確的伺服器網路；在資料中心內部，EOR 和 TOR 交換器執行第 2 層交換，直到乙太網路訊框到達承載 AMF 工作負載的伺服器介面。

在雲化 5G 核心網路中，“AMF 在哪台裝置上”不能只用實體伺服器來回答。AMF 可能作為虛擬化網路功能執行在通用計算節點上，同一台實體伺服器還可能承載 OAM 虛擬機、其他網路功能或多個服務實例。例如，一台 VM 可以執行負責 NAS、NGAP 和 SCTP 處理的 AMF 服務。但從 gNB 的角度，真正重要的是 AMF 對外提供的 N2 服務 IP 端點，而不是機架上的實體伺服器標籤。

這意味著，N2 故障排除至少涉及三種不同的“位置”概念。其中，實體位置用於識別工作負載所在的機架和實體主機；邏輯位置用於識別承載 AMF 的 VM 或服務實例；網路位置則是 gNB 建立 SCTP 關聯時所使用的 AMF N2 IP 位址。即使實體伺服器、VM 和 AMF 程序看起來都正常，N2 仍可能無法到達，因為 VLAN、預設閘道、IP 路由、交換器連接埠或虛擬交換層沒有把流量正確送到該 N2 位址。

N2 路徑上的路由與轉送有什麼區別？

把 N2 信令封包送到 AMF，並不是有一張路由表就夠了。從網路處理角度，需要區分“路由”和“轉送”。路由通常是第 3 層功能。裝置收到 IP 封包後，會在路由表中查詢目的 IP，確定輸出介面並選擇合適的下一個跳點。在 N2 路徑上，gNB、第 3 層 PTN 閘道和資料中心邊界路由器都需要具備相應的 IP 路由資訊。這些路由可以靜態設定，也可以透過動態路由協定學習。

假設 gNB 的 N2 來源位址為 A，AMF 的 N2 位址為 B。gNB 不需要知道 B 位於哪個實體伺服器機架，只需要知道去往包含 B 的子網路時，應把封包交給哪個下一個跳點閘道。PTN 中的第 3 層裝置也根據各自的路由表作出相同判斷，直到封包進入包含 AMF 的資料中心網路。

路由決定封包下一步該去哪裡，但封包仍需透過目前實體鏈路傳送。如果使用乙太網路，裝置會添加包含來源 MAC 和目的 MAC 位址的乙太網路訊框標頭，交換器再依據 MAC 位址表轉送該訊框。因此，同一個 N2 IP 封包在跨越不同第 3 層跳點時，其外層第 2 層標頭可能會變化。IP 層持續表示 gNB 與 AMF 之間的端到端關係，而 MAC 位址只對目前的第 2 層網路區段有意義。

在資料中心內部，EOR 和 TOR 交換器主要執行第 2 層交換。當資料中心第 3 層路由器把 N2 封包送入正確的伺服器側第 2 層域後，EOR 和 TOR 交換器會依據 MAC 表把乙太網路訊框轉送到目標伺服器連接埠。理解這一點對封包擷取分析非常重要：不同封包擷取點看到不同的 MAC 位址，並不代表封包改變了最終目的地；而來源與目的 IP 位址保持不變，也不代表封包沒有經過中間裝置、而是直接在兩個端點之間傳輸。

為什麼 SCTP 關聯是 N2 故障排除的關鍵邊界？

NGAP 並不是直接執行在 IP 上，而是執行在 SCTP 之上。因此，一條可用的 N2 路徑首先必須具備 IP 可達性，然後才能成功建立 SCTP 關聯。這形成了清晰的故障排除依賴關係：IP 路由有問題，SCTP 就無法建立；沒有 SCTP，NGAP 就無法工作；沒有 NGAP，NAS 信令也就無法成功中繼。

但反過來並不一定成立。能 ping 通 AMF 只能說明存在一定程度的 IP 可達性，並不能證明所需 SCTP 服務可達、SCTP 關聯能夠建立、NGAP 參數正確，或 AMF 應用程序工作正常。

• 第一步，驗證 IP 路徑。檢查 gNB 的 N2 位址、子網路遮罩、預設閘道以及通往 AMF N2 位址的路由。接著確認 PTN 閘道和資料中心第 3 層裝置同時具備前向路由和回程路由。回程路由尤其容易被忽略：從 gNB 傳出的封包可能已經順利到達 AMF，但 AMF 卻沒有通往 gNB 子網路的有效回程路由。由於 N2 是雙向信令介面，兩個方向都必須可達。

• 第二步，確認 SCTP 確實已經建立。確認 IP 可達後，檢查 gNB 與 AMF 是否完成 SCTP 關聯程序並進入 Established 狀態。如果關聯始終無法建立，應檢查傳輸層連接埠、本機 IP 綁定、ACL、防火牆以及路徑上的安全策略。真實資料中心還可能部署 IDS/IPS、負載平衡器、SDN 元件以及其他安全或流量控制系統，這些裝置即使沒有出現在簡化架構圖中，也可能影響 SCTP。

• 第三步，再向上檢查 NGAP 和 NAS。只有在 SCTP 關聯穩定後，才應分析 NG Setup、Initial UE Message 和 NAS Transport。如果 SCTP 正常但 NG Setup 失敗，問題已經從 IP 傳輸層上移到 N2 應用或設定邏輯。如果 NG Setup 成功，但某個特定 UE 的註冊信令沒有到達 AMF，則應繼續跟蹤 Initial UE Message、UE-NGAP-ID 和 NAS-PDU。這種分層方法可以避免一個常見錯誤：還沒確認 NAS 訊息是否真正跨過 N2 介面，就直接開始故障排除 NAS。

如何透過封包擷取還原完整的 N2 信令路徑？

理解 N2 路由的真正價值，會在封包擷取和故障隔離時體現出來。當 gNB 與 AMF 之間的信令失敗時，應從傳輸層開始逐層向上檢查，而且封包擷取位置非常關鍵。gNB 側封包擷取可以確認信令是否真正離開基地台；PTN 或資料中心邊界附近的封包擷取可以判斷封包是否進入核心網路區域；伺服器側封包擷取則可以確認 N2 封包是否實際到達承載 AMF 工作負載的主機。如果 gNB 側能夠看到發出的 SCTP INIT，而 AMF 主機完全看不到，那麼故障幾乎可以確定在中間網路，而不是 NGAP 應用邏輯。

擷取封包後，先確認來源與目的 IP 位址是否符合設計。如果 AMF 已遷移、擴充或移動到新的 VM，而 gNB 仍指向舊的 N2 位址，那麼即使 NGAP 設定表面上沒有變化，信令也可能走錯路徑。接著沿第 3 層裝置逐一檢查每個跳點的路由。在 gNB、PTN 閘道和資料中心路由器上，檢查通往 AMF 子網路的路由，包括輸出介面、下一跳和回程路徑。如果使用動態路由，不要只看設定中是否啟用了路由協定，還要確認該路由確實已經學習並安裝到轉送表中。

如果封包已經到達資料中心第 3 層邊界，卻仍無法到達 AMF 伺服器，故障排除重點就應從 IP 路由轉向第 2 層轉送。檢查 EOR 和 TOR 交換器上的 VLAN 成員關係、MAC 位址學習、伺服器側連接埠狀態，以及伺服器或虛擬交換層是否連接到正確的服務網路。最後，把這些網路結果與 SCTP 狀態關聯起來。如果雙向 IP 路徑正常但 SCTP 仍無法建立，則檢查 SCTP 連接埠處理、IP 綁定和 AMF 程序本身。一旦 SCTP 建立成功，就可以在更清晰的故障邊界下繼續分析 NGAP 和 NAS。

從端到端看，“N2 信令路由”實際上包含兩個不同但連續的過程。第一個發生在 gNB 內部：NAS 訊息從 UE 的無線側到達 gNB，被中繼到 NGAP 訊息中，再透過 SCTP 和 IP 封裝，以便在 N2 網路上傳輸。

第二個過程發生在傳輸網路和資料中心內部。這些網路裝置並不關心酬載中是 Registration Request 還是 Initial Context Setup 程序，它們只依據第 3 層 IP 路由和第 2 層 MAC 轉送，逐跳把封包送向執行 AMF 服務的運算環境。

在實際工程中，故障排除 N2 最有效的方法，是始終保持端到端視角：

UE NAS → gNB 中繼 → NGAP → SCTP → IP 路由 → 第 2 層轉送 → AMF 伺服器 → AMF 程序

按這條鏈路逐層檢查後，很多最初看起來很複雜的“註冊失敗”“N2 不可達”或“SCTP 關聯失敗”，最終都可以歸結為一個更具體的問題：封包究竟停在了哪一層、哪一個跳點？

常見問題

N2 信令會經過 UPF 嗎？

在正常 5G 架構下，N2 控制面路徑不依賴 UPF。N2 連接 gNB 與 AMF，而 UPF 主要參與使用者面路徑。當 N2 不可達時，應把故障排除重點放在 gNB 與 AMF 之間的控制面傳輸路徑，而不是從 N3 使用者面隧道開始。

為什麼在不同位置擷取同一個 N2 封包時，MAC 位址會變化？

MAC 位址屬於目前的第 2 層網路區段。封包跨過第 3 層路由裝置後，會為下一條鏈路重新封裝新的第 2 層標頭。因此，即使端到端的 gNB 與 AMF IP 位址仍屬於同一條 N2 通訊流，來源與目的 MAC 位址也可能隨每個跳點而變化。

為什麼 gNB 能 ping 通 AMF，SCTP 仍可能失敗？

Ping 主要驗證基於 ICMP 的 IP 可達性。SCTP 還取決於傳輸層連接埠處理、本機 IP 綁定、ACL、防火牆、安全策略以及 AMF 應用程序。因此，IP 可達只是 N2 通訊的前提，並不能保證 SCTP 或 NGAP 正常工作。

如果 AMF 執行在虛擬機中，gNB 需要知道實體伺服器的位置嗎？

不需要。gNB 使用 AMF 的 N2 服務 IP 位址建立 N2 連接，而不是依據實體伺服器的位置。實體主機、虛擬交換器、VM 對應和資料中心內部拓撲都屬於實作細節，但這些元件仍必須把發往 AMF N2 端點的封包正確送到對應的服務實例。

為什麼故障排除 N2 問題時既要檢查前向路由，也要檢查回程路由？

NGAP 和 SCTP 都是雙向的。即使從 gNB 傳出的封包能夠到達 AMF，如果 AMF 沒有通往 gNB 子網路的有效回程路由，SCTP 握手和後續 NGAP 程序仍會失敗。因此，單向可達並不足以證明 N2 路徑完整。