工程師剛開始接觸 5G 核心網路介面時，通常會從 N1 一路背到 N50：記住兩端的網路功能、所使用的協議，以及在 4G 中最接近的對應關係。這種方法在入門階段可能有幫助，但到了部署、信令分析和故障排除時很快就不夠用了。實際工作中，更有價值的問題是：這條介面屬於接入、會話管理、策略控制還是使用者平面？它承載的是 NAS、GTP-U、PFCP，還是某項 SBI 服務？出現問題後，下一步應該沿哪條控制路徑繼續分析？

這也是 5GC 與 EPC 之間最重要的架構差異之一。5G 並不是簡單地把 S1、S11、Gx、S6a 等介面換個名稱，而是在保留部分參考點介面的同時，引入基於服務的架構（Service-Based Architecture，SBA），使控制平面網路功能能夠通過服務呼叫進行交互。因此，分析 5GC 介面時，最好同時從參考點和 SBA 服務兩個視角進行理解。

如何理解 SBA 與參考點架構

理解 5GC 可以採用兩個有用的視角。第一個是傳統的參考點架構，它描述兩個功能實體之間的邏輯關係，例如 UE 與 AMF 之間的 N1、gNB 與 AMF 之間的 N2、gNB 與 UPF 之間的 N3，以及 SMF 與 UPF 之間的 N4。第二個是 SBA 視角，在該模式下，AMF、SMF、PCF、UDM、AUSF、NSSF、NEF 和 NRF 等控制平面網路功能被視為服務生產者和服務消費者。

這兩個視角並不矛盾。參考點模型適合追蹤端到端信令路徑，而 SBA 更便於理解動態網路功能發現、服務呼叫和服務擴展。

以 N2 為例，它具有非常明確的端點關係：gNB 連接 AMF，並通過 NGAP 傳輸 NAS 信令、支持連接管理。N3 則連接 gNB 與 UPF，通過 GTP-U 承載使用者平面流量。這類介面具有清晰的點到點路徑特徵。

但當 AMF 訪問 UDM、AUSF 或 PCF 時，關注重點就會轉向這些網路功能所開放的服務。N8 用於 AMF 與 UDM 之間獲取移動性管理訂閱資訊，N12 支持 AMF 與 AUSF 之間的驗證管理，N15 則允許 AMF 獲取與移動性相關的策略。這些關係體現了 5GC 控制平面從傳統專用協議向基於 HTTP/2 的服務交互遷移。

這意味著，在分析封包擷取或架構圖時，工程師不應把 N8 之類的介面僅理解為一條固定的物理連接。更重要的是判斷哪個 NF 正在消費哪個服務、該服務實例如何被發現，以及當前 HTTP/2 事務處於服務流程的哪個階段。

核心介面可以如何分組？

與其逐個記憶介面編號，更實用的方法是按照介面所支撐的網路功能進行分組。出現某條信令時，工程師可以先判斷它屬於哪一類功能，再進一步定位到具體介面。

接入與使用者平面路徑

N1、N2 和 N3 構成 5G 接入側最基礎的一組介面。N1 位於 UE 與 AMF 之間，在 5G NAS 中承載移動性管理和會話管理資訊。N2 連接 gNB 與 AMF，通過 NGAP 傳輸 NAS 信令並支持連接管理。N3 連接 gNB 與 UPF，通過 GTP-U 承載實際使用者平面流量。

在核心網路內部，UPF 可以繼續通過 N9 使用 GTP-U 轉發使用者流量，而 UPF 通過 N6 連接外部資料網路（Data Network，DN）。N6 上的流量已經不是 5G 特有的控制信令，而是網頁內容、圖片、影片以及其他使用者資料等應用層 IP 流量。

因此，如果 UE 註冊成功、PDU 會話也已建立，但業務流量仍無法通過，故障排除通常應從 AMF 控制平面轉移到 N3、UPF 轉發行為、N6 以及外部 DN。

會話與使用者平面控制

N4 是 5GC 中最重要的控制介面之一，位於 SMF 與 UPF 之間並使用 PFCP。SMF 負責會話控制，UPF 負責資料包轉發，因此 N4 用於下發轉發規則並控制使用者平面行為。

N11 連接 AMF 與 SMF，主要承載 PDU 會話管理相關信令。當 UE 發起 PDU Session Establishment 時，AMF 會把會話管理請求交給 SMF 繼續處理。如果註冊成功但 PDU 會話建立失敗，N11 及後續 SMF 流程通常是重點排查位置。

N16 支持 SMF 實例之間的交互，包括與 SMF 重選相關的流程。與 EPC 相比，5GC 將控制功能拆分為更多獨立 NF。過去集中在 MME、SGW 或 PGW 中的職責，被分配給 AMF、SMF、PCF、UDM 等功能，從而形成新的服務關係。

策略、驗證與訂閱資料

策略控制主要以 PCF 為中心。N7 連接 SMF 與 PCF，用於請求與會話管理相關的策略。N5 位於 PCF 與 AF 之間，承載應用層業務參數和需求。N15 則允許 AMF 獲取與移動性相關的策略。

在訂閱資料方面，N8 允許 AMF 訪問 UDM 並獲取移動性管理訂閱資訊，N10 連接 SMF 與 UDM，用於獲取會話管理相關的訂閱資料。驗證進一步拆分為 AMF 與 AUSF 之間的 N12，以及 AUSF 與 UDM 之間的 N13。

這種拆分非常重要。在 EPC 中，HSS 承擔了大量使用者訂閱和驗證資料功能；在 5GC 中，這些職責被更精細地分配給 UDM、AUSF 及相關資料存儲功能。發生驗證失敗時，只確認使用者資料是否存在已經不夠，工程師還需要判斷失敗發生在 AMF 發起驗證時、AUSF 處理過程中，還是 AUSF 從 UDM 獲取所需資訊時。

高級服務介面負責甚麼？

當介面範圍超出 N1 至 N16 後，5GC 介面模型的擴展性體現得更加明顯。隨著網路切片、能力開放、網路分析、漫游和資料解耦等功能引入，更多介面圍繞獨立網路功能建立起來。

N22 連接 AMF 與 NSSF，用於網路切片選擇。N34 連接 NSSF 與 NWDAF，使網路分析結果能夠支持切片相關決策。NWDAF 還可通過 N23 向 PCF 提供分析資訊，讓分析資料參與策略決策。因此，策略控制不再只能依賴靜態訂閱資訊和預定義規則。

能力開放主要涉及 NEF。N29 位於 SMF 與 NEF 之間，N30 連接 NEF 與 PCF，N33 支持 API 與 AF 之間的服務呼叫。因此，NEF 位於外部應用和核心網路能力之間的重要位置，為向應用側服務受控開放網路能力提供機制。

資料存儲也被進一步拆分。N35 連接 UDM 與 UDR，用於存儲訂閱資料；N36 連接 PCF 與 UDR，用於存儲策略資料；N37 允許 NEF 訪問 UDR，以處理能力開放和應用相關資料。UDSF 還用於非結構化資料存儲，支持計算與存儲功能分離。

在漫游和電信業者互聯場景中，還會涉及更多介面，包括拜訪地 PCF 與歸屬地 PCF 之間的 N24、拜訪地 NRF 與歸屬地 NRF 之間的 N27、V-NSSF 與 H-NSSF 之間的 N31，以及 V-SEPP 與 H-SEPP 之間的 N32。SEPP 在電信業者邊界提供安全控制。這些介面在單電信業者本地測試環境中未必常見，但在分析漫游架構時非常重要。

計費功能也在從傳統基於 Diameter 的模式向服務化交互遷移。N28 連接 PCF 與 CHF，使計費相關資訊能夠支持 PCC 規則決策；N40 連接 SMF 與 CHF。N41 至 N49 在相關規範範圍內保留。另一個專用介面是 N50，它連接 AMF 與 CBCF，用於公眾預警和災害告警服務。

5GC 對應到 EPC 時應注意甚麼？

從 4G 遷移到 5G 時，EPC 經驗仍然非常有用，但不能把兩者關係理解為機械的一對一替換。5GC 與 EPC 介面之間的相似性主要是功能層面的參考，而不是完全等價。

有些對應比較直觀。N2 在功能上可與 S1-MME 對比，N3 類似 S1-U。N4 在基於 CUPS 的 EPC 架構中，與 Sxa、Sxb 和 Sxc 在功能上相近。從策略控制角度看，N7 可與 Gx 對比，而 N5 有助於理解過去與 Rx 相關的應用策略角色。

在使用者訂閱與驗證功能上也能看到類似的演進。N8 可在功能上與 MME 和 HSS 之間 S6a 交互的一部分進行對比。支持 AMF 之間移動性管理的 N14，可與 MME 之間的 S10 對比；用於設備身份檢查的 N17，則在功能上對應 MME 與 EIR 之間的 S13 交互。

不過，許多 5GC 介面在 4G 中並沒有直接對應項，例如用於切片選擇的 N22、用於網路分析的 N23、用於跨域 NRF 發現的 N27，以及圍繞基於 UDR 的資料存儲建立的介面。這些關係是隨著 5GC 基於服務的架構和更高程度的功能解耦而出現的。

因此，更合理的遷移方法是先比較功能，再比較信令機制，而不是強行讓每個 N 介面對應某個 S 介面或 Diameter 參考點。協議演進尤其明顯：EPC 控制平面信令大量依賴 Diameter 和 GTPv2，而如今許多 5GC 控制平面交互已採用基於 HTTP/2 的 SBI 服務。

5GC 介面分析的實用方法

在實際 5GC 信令分析中，從業務現象反向追蹤，往往比從某個介面編號正向分析更有效。如果 UE 無法註冊，應從 N1、N2 以及後續 AMF 驗證和使用者資料流程入手。如果註冊成功但 PDU 會話失敗，則繼續檢查 N11、SMF、N7、N10 和 N4。如果 PDU 會話成功，但使用者流量無法到達資料網路，則應把重點轉向 N3、UPF 轉發和 N6。

對於策略相關問題，應繼續沿 N7 和 PCF 相關信令鏈分析。對於切片選擇問題，應重點檢查 AMF 與 NSSF 之間的 N22。對於能力開放或應用驅動的策略需求，則應把分析延伸到 NEF、AF 和 PCF 相關介面。一旦建立“業務階段—網路功能—介面—協議”四層對應，幾十條 N 介面就會更容易理解。

從架構學習到現網故障排除，5GC 介面分析最重要的是理解各功能之間的關係。接入層負責把 UE 接入核心網路，會話管理負責建立 PDU Session，策略和訂閱服務決定如何處理該會話，使用者平面承載實際應用流量，而 SBA 則讓各控制平面功能通過服務化交互協同工作。理解這套端到端邏輯，比單純背完整的介面表更具工程價值。

常見問題

N 介面編號越大，是否代表功能越新？

不是。N 介面編號用於標識架構中的邏輯參考點，並不表示技術代際、重要程度或時間先後。N1、N2 和 N3 是 5GC 最基礎的介面之一，而較高編號的介面中既包含較新的功能關係，也包含預留參考點。

所有 5GC 控制平面介面都使用 HTTP/2 嗎？

不是。許多與 SBA 相關的控制平面交互使用 HTTP/2，但 5GC 還包含多種其他協議。N2 使用 NGAP，N3 和 N9 使用 GTP-U，N4 使用 PFCP，UE 與 AMF 之間的通訊還涉及 5G NAS。因此，故障排除應先識別介面類型，再選擇合適的協議分析方法。

為甚麼封包擷取中有時看不到 N 介面名稱？

N 介面名稱表示架構中的邏輯參考點。封包擷取通常顯示實際協議，例如 HTTP/2、NGAP、PFCP 或 GTP-U，以及通訊網路功能的 IP 地址。因此，需要根據兩端 NF 的角色和正在分析的服務流程來判斷其對應的邏輯 N 介面。

5GC 測試網是否需要部署所有已定義介面？

不需要。實際出現哪些介面取決於網路規模、已啓用業務，以及部署是否支持漫游、網路切片、能力開放、網路分析或公眾預警等功能。基礎註冊和資料連接只會使用完整 5GC 介面體系中的一部分。