5G 網路中有一種常見故障情境，表面上看似很簡單：UE 注冊成功，PDU Session 已建立，IP 位址也分配正確，但網頁無法訪問，甚至最基本的 Ping 流量也不通。封包擷取可能顯示流量已經透過 N3 到達 UPF，却沒有相應的封包從預期路徑發出。如果排查始終只盯著 AMF 信令和 PDU Session 建立結果，真正的原因往往很難定位。
PDU Session 成功建立，並不自動意味著使用者平面轉送路徑已經可用。UPF 收到封包後，首先使用 PDR 識別流量，然後應用關聯的 FAR（Forwarding Action Rule，轉送動作規則） 決定下一步如何處理：轉送、丟棄、緩衝或複製封包。FAR 還可以定義目的介面，以及是否需要建立外層 GTP-U 隧道標頭。
從故障排查角度看，這一區分非常有用：PDR 回答的是 “這個封包屬於哪個會話和哪條服務流？”，而 FAR 回答的是 “封包已經識別出來，UPF 接下來應該如何處理？” 當控制平面流程看起來都正常，但使用者流量仍然失敗時，N4 介面上的 FAR 就成為必須重點檢查的位置。
為什麼 PDU Session 建立成功仍不能保證使用者平面連通？
PDU Session Establishment 流程完成，只能說明所需的控制平面會話資源已經初始化。真正的應用流量仍依賴由 gNB、N3、UPF 和 N6 組成的完整使用者平面路徑。
對於典型的 Internet PDU Session，上行流量從 UE 到達 gNB，經 GTP-U 通道封裝後透過 N3 送到 UPF。UPF 需要刪除相應的外層隧道標頭，識別流量，並把原始封包轉送到資料網路。下行方向則相反：流量從 N6 進入 UPF，UPF 識別對應的 PDU Session，獲取 gNB 使用者平面隧道資訊，添加所需的 GTP-U 外層標頭，再透過 N3 把封包發送給 gNB。
這種轉送能力並不會因為 PDU Session 已經建立就自動生效。SMF 必須透過 N4 向 UPF 下發適當的 PFCP 規則。PDR 用於識別匹配流量，FAR 則定義流量完成分類後要執行的轉送動作。正確的使用者平面處理需要兩類規則共同工作。
當所有控制平面信令看起來都正常，但服務仍然不可用時，可以把問題拆成兩個核心問題：
PDR 是否正確識別了當前流量？
封包識別後，關聯的 FAR 是否包含正確的處理和轉送參數？
把注意力放在 PDR 與 FAR 的關係上，通常比反覆從頭檢查整個 PDU Session 建立流程更高效。
FAR 實際告訴 UPF 做什麼？
FAR 是 PFCP 框架中的轉送規則，由 SMF 透過 N4 下發到 UPF，並透過 PDR 引用的 FAR ID 與流量關聯。封包一旦匹配該 PDR，UPF 就執行被引用 FAR 所定義的處理行為。
一個 FAR 可以包含多個 Information Element。進行使用者平面故障排查時，以下字段尤其重要：
| FAR 參數 | 主要作用 |
|---|---|
| FAR ID | 在 PFCP 會話中唯一標識 FAR 實例，使 PDR 能够引用正確的轉送規則 |
| Apply Action | 定義基本的封包動作，包括轉送、丟棄、緩衝或複製 |
| Forwarding Parameters | 定義需要轉送時使用的目的位置、Network Instance、通道封裝以及其他參數 |
| Duplicating Parameters | 啟用流量複製時，定義封包副本應如何轉送 |
| BAR ID | 引用 Buffering Action Rule，用於控制封包緩衝行為 |
實際使用中，Apply Action 和 Forwarding Parameters 是最容易混淆的兩個部分。Apply Action 回答 “應該執行什麼動作？”，而 Forwarding Parameters 回答 “如果要轉送，這個封包應該如何發送、發到哪裡？”
僅僅在 Apply Action 中看到 FORW 標誌，並不能證明下行路徑已經完整。Destination Interface、Network Instance、Outer Header Creation 資訊以及其他相關轉送參數仍然必須正確。
Apply Action 如何決定第一步封包處理動作？
Apply Action 由一組位標誌表示，用來指示 UPF 對匹配的封包執行哪些基本操作。這些標誌並不只是簡單互斥的選項，需要結合 PFCP 會話和具體服務情境理解其含義。
DROP： 丟棄匹配的封包。
FORW： 按照適用的 Forwarding Parameters 轉送封包。
BUFF： 緩衝封包，而不是立即轉送。
NOCP： 用於緩衝情境，當需要緩衝的下行資料到達時通知控制平面。
DUPL： 建立封包副本，並按照 Duplicating Parameters 對該副本進行處理。
為什麼需要 BUFF 和 NOCP？
典型情境是 UE 處於空閒狀態，當前沒有可立即使用的下行使用者平面路徑。此時下行流量可能已經到達 UPF，但還無法送達 UE。UPF 可以先緩衝封包，並在需要時使用相應的控制平面通知機制，從而觸發尋呼或使用者平面路徑恢復等後續流程。
BUFF 只表示需要緩衝。具體如何緩衝由 BAR 等相關規則控制，因此排查時不能只看 BUFF 標誌。
為什麼 DUPL 不只是“把封包再轉送一次”？
DUPL 會建立一個獨立的封包副本。原始封包繼續按照正常路徑處理，而副本則由 Duplicating Parameters 獨立控制。這個副本可以使用不同的 Destination Interface、Outer Header 設定、Transport Level Marking 或 Forwarding Policy。
因此，鏡像或複製流量不能預設與原始服務流量走同一條路徑。Duplicating Parameters 需要單獨檢查。
Forwarding Parameters 如何決定封包真正發到哪裡？
當 Apply Action 包含 FORW 時，Forwarding Parameters 決定實際轉送路徑。在排查使用者平面故障時，有幾個字段尤其重要。
Destination Interface
Destination Interface 定義 UPF 完成處理後應把封包發送到哪個邏輯介面。典型下行情境通常設定為 Access，表示封包應發往 gNB。上行流量一般轉送到 Core 側。
錯誤的 Destination Interface 會造成一種不易察覺的故障：PDR 匹配完全正確，但封包被送往錯誤的邏輯介面，而控制平面可能看不到明顯異常。
Network Instance
Network Instance 標識轉送使用的邏輯網路上下文。在存在多個 DNN、切片或資料網路，需要保持流量隔離的部署中尤其重要。
排查 N6 連通性或私有網路服務時，只檢查實體網路是否可達還不够。FAR 中的 Network Instance 也必須與對應的 UPF 設定一致。兩者不匹配會導致流量無法進入預期的網路上下文。
Outer Header Creation
Outer Header Creation 是 N3 下行轉送中的關鍵參數之一。從 N6 進入 UPF 的封包包含原始 UE 負載。要透過 N3 把該封包發給 gNB，UPF 必須添加所需的 GTP-U/UDP/IP 外層封裝。
Outer Header Creation 提供執行這一操作所需的資訊，包括 gNB 使用者平面位址、N3 隧道 TEID 以及外層標標頭類型。
很多“下行流量已經到達 UPF，但 N3 上看不到對應封包”的問題，都可以追溯到 FAR 這一部分資訊缺失或錯誤，例如 TEID 錯誤或 gNB 位址錯誤。
其他 Forwarding Parameters
Forwarding Parameters 還可以包含 Redirect Information、Transport Level Marking、Forwarding Policy、Header Enrichment、Linked Traffic Endpoint ID、Proxying、Destination Interface Type 等可選資訊。
Transport Level Marking 可用於給轉送封包應用所需的 DSCP 標記。Forwarding Policy 可以引用 UPF 本機設定的轉送策略。Header Enrichment 用於適用服務中的附加頭處理。並不是每個 FAR 都包含全部這些 Information Element，實際内容取決於 PFCP 信令和服務要求。
為什麼會話建立後還可能更新下行 FAR？
在初始 PDU Session Establishment 流程中，SMF 可以在 UPF 中建立第一批 PDR 和 FAR。但在這個時間點，gNB 可能還沒有完成下行 N3 使用者平面資源分配，因此最終的隧道 TEID 和 gNB 使用者平面位址可能尚未提供給 SMF。
當 gNB 完成資源分配，相應的 N3 使用者平面資訊也到達 SMF 後，SMF 可以發送 PFCP Session Modification ，把現有 FAR 更新為所需的下行隧道參數。
更新後的下行 FAR 可以包含以下關鍵轉送資訊：
Destination Interface = Access，表示向Access 側轉送；
適用的 Network Instance；
Outer Header Creation = GTP-U/UDP/IPv4 或其他適用的外層標標頭類型；
gNB N3 使用者平面 IP 位址以及已分配的隧道 TEID。
因此，故障排查不能只檢查 PFCP Session Establishment Request 就結束。初始 FAR 可能只包含基礎轉送動作，而真正建立 N3 下行通道所需的資訊，可能在之後透過 PFCP Session Modification 才寫入。
如果分析時忽略了後續更新，就很容易把正常的分階段規則下發過程誤認為 FAR 設定缺失或不完整。
FAR 如何把下行流量重新送入 N3 通道？
沿著完整的下行封包路徑分析，可以更直觀地理解 FAR 的作用。
來自外部伺服器的封包透過 N6 到達 UPF。UPF 使用 PDR 識別該流量，並把它關聯到正確的 PDU Session，然後讀取該 PDR 引用的 FAR。
如果 Apply Action 包含 FORW，UPF 就會評估 Forwarding Parameters。Destination Interface 設定為 Access，表示封包應發送到無線Access 側。Outer Header Creation 中包含構造 GTP-U 外層標頭所需的 gNB 通道位址和 TEID。隨後 UPF 對原始封包進行封裝，並透過 N3 發送給 gNB。
完整路徑可以概括為：
下行封包從 N6 到達 → PDR 識別 UE 流量 → FAR 執行 FORW → UPF 獲取 gNB N3 隧道參數 → UPF 建立 GTP-U 外層標頭 → 封包透過 N3 發送給 gNB。
這也說明了 FAR 與 GTP-U 的區別。GTP-U 是承載使用者資料的隧道協定，而 FAR 是 UPF 的決策規則，用於控制 是否需要建立外層隧道標頭、應使用哪組隧道資訊，以及封包應該發往哪個邏輯介面。
因此，在 N3 封包擷取中看到錯誤 TEID 只是表面症狀。排查還應繼續回溯到控制平面：gNB 是否分配了正確的使用者平面資訊？SMF 是否正確收到？這些資訊隨後是否透過 N4 更新寫入了正確的 FAR？
如何利用 FAR 排查 PDU Session 已建立但沒有資料連通的問題？
如果 UE 注冊正常，PDU Session 也已經建立，但服務仍不可用，可以按照 UPF 實際的封包處理順序排查，而不是從頭重新回放整個注冊流程。
一套實用的 FAR 排查順序如下：
確認封包是否到達 UPF。 如果 N3 或 N6 上沒有封包到達，問題位於 FAR 上游，應優先檢查 UE、gNB 或傳輸路徑。
確認 PDR 是否匹配封包。 只有關聯的 PDR 先識別出封包，FAR 才有流量可處理。
核對 PDR 引用的 FAR ID。 確保已經正確匹配的封包沒有被關聯到錯誤的轉送規則。
檢查 Apply Action。 確認設定的行為是 FORW、DROP、BUFF，還是適用標誌的組合。
檢查 Destination Interface 和 Network Instance。 確認封包被發送到正確的邏輯方向和網路上下文。
檢查 Outer Header Creation。 對於 N3 下行流量，應核對 gNB 位址、TEID 和外層標標頭類型。
檢查 PFCP Session Modification 消息。 不要只查看初始 Create FAR，還要確認 gNB 隧道資訊之後是否已經更新到 UPF。
交叉比對 N3 和 N6 封包擷取。 把 PFCP 規則預期的行為，與 UPF 實際發送的封包進行對比。
這種方法的主要優勢，是控制平面規則與使用者平面封包擷取可以相互驗證。PFCP 信令說明 UPF 應該 如何轉送封包，而 N3 和 N6 封包擷取則顯示 UPF 實際 做了什麼。
當這兩種視角不一致時，故障範圍通常可以縮小到三類：N4 規則下發錯誤、UPF 規則執行錯誤，或使用者平面傳輸路徑存在問題。這比沒有明確方向地檢查整個 5G Core 高效得多。
FAQ
FAR 與 PDR 最主要的區別是什麼？
PDR 負責封包檢測和分類，用於回答封包屬於哪個會話、哪條服務流等問題。FAR 則定義匹配之後如何處理，包括封包應該怎樣處理以及轉送到哪裡。PDR 透過 FAR ID 引用對應的 FAR。
為什麼 Apply Action 已包含 FORW，轉送仍然可能失敗？
FORW 只表示應該執行轉送。轉送是否成功仍取決於關聯的 Forwarding Parameters。如果 Destination Interface、Network Instance 或 Outer Header Creation 資訊錯誤，封包仍可能無法到達預期目的地。N3 TEID 錯誤或 gNB 使用者平面位址錯誤就是典型例子。
為什麼第一次 PFCP Session Establishment 中的 FAR 有時沒有完整的 N3 隧道資訊？
PDU Session 建立是一個多步驟過程。初始 PFCP Session 建立時，gNB 可能還沒有分配最終的下行 N3 使用者平面資源。等 gNB 通道位址和 TEID 可用後，SMF 可以透過 PFCP Session Modification 更新 FAR。因此，故障排查除了初始建立消息，還必須繼續跟蹤後續 N4 交互。
Outer Header Creation 與 PDR 的 Outer Header Removal 有什麼關係？
兩者用於通道處理的相反方向。對於從 N3 到達的上行流量，Outer Header Removal 用於刪除相應的 GTP-U 外層標頭；對於 UPF 透過 N3 發出的下行流量，FAR 中的 Outer Header Creation 提供建立新 GTP-U 外層標頭所需的資訊。二者共同支持使用者平面通道封裝與解封裝的兩個方向。
如果 N3 上的 TEID 錯了，排查是否只需要關注 GTP-U？
不需要。N3 封包擷取只能說明當前使用的 TEID 不正確。隧道資訊最初由 gNB 产生，經 SMF 處理後，再透過 N4 下發到 FAR。因此，應繼續追蹤 gNB 的資源分配、SMF 接收到的資訊，以及 PFCP Session Modification 中對 FAR 的更新，才能定位真正原因。
