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，表示向接入侧转发；
适用的 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，表示数据包应发送到无线接入侧。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 的更新，才能定位真正原因。
