一个常见的 5G 用户面故障场景起初很容易让人困惑：PDU Session 已成功建立，UE 获得了 IP 地址，PDR 正确匹配预期流量，FAR 中也包含 FORW，数据包甚至已经开始传输。但用户仍然遇到视频缓冲、下载速率异常偏低，或者只有单向流量能够正常工作的情况。
出现这种情况时，仅检查 PDR 和 FAR 可能仍然找不到原因。问题可能并不在于 流量是否被正确识别 或 数据包被转发到了哪里，而是在于 允许转发之后，UPF 对这部分流量应用了哪一种 QoS 策略。在 N4 接口的 PFCP 规则体系中， QER（QoS Enforcement Rule，QoS 执行规则） 负责在 UPF 中实施这些 QoS 策略。它可以控制流量是否允许通过、限制上行或下行速率、把流量关联到某个 QoS Flow，并应用传输层标记。因此，要理解完整的用户面行为，需要把 PDR、FAR 和 QER 一起分析。
为什么 PDR 和 FAR 已经正常工作后仍然需要 QER？
理解 QER 最简单的方法，是把 UPF 中不同规则的职责分开来看。
PDR 首先回答“这是什么流量？”它通过 PDI、UE IP 地址、F-TEID、SDF Filter 等条件检测并分类数据包。流量识别完成后，FAR 回答下一个问题：“这个数据包接下来应该怎么处理，又应该转发到哪里？”
但允许一个数据包转发，并不意味着它可以不受任何限制地传输。如果网络仍然需要控制速率、Gate 状态、QoS Flow 关联或传输层标记，UPF 就必须应用关联的 QER。
因此，一个典型的处理顺序可以简化为：
PDR 识别流量 → FAR 决定转发动作 → QER 执行 QoS 策略。
这些规则不是互相替代，而是协同工作。数据包可以正确匹配 PDR，也可以被 FAR 允许转发，但仍然受到 QER 所定义的速率限制或 Gate 条件约束。没有 QER，UPF 可能知道数据包应该被转发，却缺少描述这些流量从 QoS 角度应该如何处理的同等策略信息。
QER 在什么时候安装？为什么后续还可能被更新？
在 PDU Session 的 PFCP Session Establishment 过程中，QER 通常由 SMF 作为用户面规则的一部分下发到 UPF。它并不是 UPF 在观察到流量之后自行创建的一条 QoS 规则。控制面决定应执行什么 QoS 行为，而 UPF 负责执行最终下发的规则。
QER 并不一定在整个会话生命周期内保持不变。如果业务运行期间策略发生变化，SMF 可以通过 PFCP Session Modification 更新现有 QER。因此，订阅策略、应用策略或其他控制面决策的变化，都可能带来新的速率限制、不同的 Gate 状态、改变 QoS Flow 关联或其他 QoS 参数。
因此，故障排查不能只停留在最初的 Create QER。如果 QoS 问题是在会话运行一段时间后才出现，还应继续检查后续的 Update QER 信息，并与初始参数进行比较。
从控制面角度看，SMF 使用的 QoS 策略可能来自本地配置，也可能来自与 PCF 相关的策略信息。当策略到达 N4 接口时，会被表示为 UPF 可以执行的 PFCP 规则。根据业务设计，QoS 执行可以作用于 PDU Session 级别、QoS Flow 级别，也可以针对更具体的 SDF 或应用流量。
为什么会话看起来正常时 Gate Status 仍然可能阻断流量？
Gate Status 是 QER 中最直接的参数之一，因为它可以立即改变流量是否允许通过。
上行和下行 Gate 状态可以分别控制。Gate 为 OPEN 时，对应方向的流量可以继续通过；Gate 为 CLOSED 时，对应方向的流量会被 QoS 执行规则阻断。
因此，一个典型的排查过程可能是：
PDU Session 已成功建立；
UE 已获得 IP 地址；
PDR 匹配正确；
FAR 中包含 FORW；
但应用流量仍然无法正常工作。
此时应检查关联 QER 中的 UL Gate 和 DL Gate。因为两个方向分别控制，所以可能出现一个 Gate 为 OPEN、另一个为 CLOSED 的情况。最终症状可能表现为单向用户面故障：UE 可以接收下行流量，却无法成功发送上行流量，或者相反。
这就是为什么 QER 是一条执行规则，而不仅仅是描述性的 QoS 属性。它的参数可以直接决定某类流量是否允许继续通过 UPF。
MBR、GBR 和 Packet Rate 分别控制什么？
Gate Status 回答的是“流量能不能通过？”与速率相关的参数回答的是另一个问题：“允许通过多少流量，以什么速率通过？”QER 可以同时根据比特率和包速率执行限制。
最大比特率（MBR）
MBR 定义匹配流量的最大比特率，并且可以分别配置上行和下行方向。在 5GC 环境中，根据规则设计，具体限制可以对应会话级限制、某个特定 QoS Flow，或者更具体的业务流。
如果用户可以正常访问业务，但吞吐量总是稳定停在一个可重复出现的上限附近，那么关联 QER 中的 MBR 就是值得检查的参数之一。
MBR 很容易与无线侧容量混淆。无线条件良好、传输带宽充足，并不保证应用可以使用全部物理容量。如果 UPF 被要求执行更低的 MBR，用户面吞吐量就会持续受这一限制约束。因此，排查低吞吐量时还应检查 N4 上的 QoS 规则，而不能只关注无线性能。
保证比特率（GBR）
GBR 描述需要一定资源保障的流量所对应的保证比特率，也可以分别针对上行和下行方向指定。
GBR 可能用于需要更可预测性能的业务，例如某些实时语音、视频或其他对 QoS 敏感的应用。它不能被看成一个孤立数字，还需要结合对应的 QoS Flow 和整体 QoS 策略一起理解。
从概念上看，MBR 定义允许速率的上限，而 GBR 描述业务策略中所要求的保证速率。
包速率（Packet Rate）
有些流量仅用比特率并不能准确描述。QER 还可以包含 Packet Rate 参数，用于限制指定时间周期内允许通过的数据包数量。
这对会产生大量小数据包的业务尤其重要，例如 DNS 事务、IoT keepalive 或类似信令的流量。它们的总比特率可能仍然较低，但每秒包数却很高。在这种情况下，只检查 MBR 可能无法解释观察到的 QoS 行为。
当触发包速率限制后，即使整体带宽占用看起来不高，用户也可能遇到更高延迟、响应变慢或请求失败。
QFI、Flow Level Marking 和 PPI 在 QER 中分别起什么作用？
QER 不只是一个限速器。除了 Gate Status、MBR 和 GBR，它还可以携带与 QoS Flow 标识和数据包处理相关的参数。这些参数共同决定用户面中的流量如何被处理。
QoS Flow 标识符（QFI）
QFI 用于标识一个 QoS Flow。一个 PDU Session 可以包含多个 QoS Flow，从而让不同业务流量接受不同的 QoS 处理。
从用户面角度看，QFI 表示某个数据包关联的是哪一个 QoS Flow。在 QER 中，这个标识符可用于把相应的 QoS 执行行为与对应的 QoS Flow 关联起来。
如果规则中的 QFI 与预期的业务设计不一致，即使速率参数本身看起来正确，流量也可能被关联到错误的 QoS Flow，从而获得与原设计不同的资源处理方式。
DL Flow Level Marking
QER 可以要求 UPF 对下行流量应用流级标记，例如为 IP 传输网络设置某个 DSCP 值。
这种标记并不决定数据包属于哪个 5G QoS Flow。它影响的是数据包进入 IP 传输网络之后，如何被识别和处理。
如果传输层标记不正确，5G QoS 本身可能配置正确，但下游传输网络仍可能以错误的优先级处理该数据包。
Paging Policy Indicator（PPI）
PPI 与下行流量的寻呼策略处理相关。在适用的转发场景中，QER 可以提供与寻呼策略有关的信息，从而让涉及寻呼行为时的不同流量得到差异化处理。
对于当前不处于活动用户面状态的 UE，不同类型的下行流量可能具有不同的寻呼影响。PPI 提供的信息可以作为这种差异化处理的一部分。
Averaging Window
速率执行不能总是只根据某一个数据包的瞬时状态判断。Averaging Window 定义的是评估比特率相关行为时使用的时间窗口。
较短的窗口会更快响应突发流量，较长的窗口则会形成更平滑的平均值，并以不同方式容忍短时间突发。这也是为什么分析 QER 不能只看 QER ID 和 MBR。最终 QoS 行为可能由多个参数共同决定。
如何利用 PFCP 消息验证 QER 是否按预期工作？
分析 QER 最有价值的方法，并不是记住每一个 Information Element，而是把 PFCP 规则与实际业务症状对应起来。
例如，一条 Create QER 可能包含：
QER ID = 1；
UL Gate = OPEN；
DL Gate = OPEN；
UL MBR = 100000 kbps；
DL MBR = 150000 kbps。
这些数值只是示例，但说明了一个重要问题： Gate 为 OPEN 并不意味着不存在 QoS 限制。 流量可以被允许通过，同时仍然受到 MBR 的限制。
一个实用的排查顺序可以按照以下步骤进行：
先识别 PDR。 确定到底是哪一条 PDR 匹配了受影响的流量。如果选错 PDR，预期的 QER 就不会正确应用。
检查 PDR 引用的 QER ID。 不要脱离上下文去检查 PFCP Session 中的每一条 QER。先确定与当前分析流量真正关联的是哪一条 QER。
检查 Create QER 和 Update QER。 确认当前实际生效的规则是否在后续 PFCP Session Modification 中被修改。QoS 问题可能来自后续更新，而不是最初的会话建立。
检查 Gate Status。 分别核对上行和下行 Gate 状态。只有一个方向 Gate 关闭，也会造成单向业务故障。
检查 MBR、GBR 和 Packet Rate。 把配置限制与实际吞吐量或数据包行为进行比较，尤其是在业务总是停在固定速率附近时。
检查 QFI 和其他 QoS 参数。 确认预期的 QoS Flow、标记以及与寻呼相关的设置是否与业务设计一致。
把规则与真实用户面流量进行比较。 PFCP 表示 UPF 预期应该执行什么；吞吐量测试和抓包则显示实际发生了什么。两者之间的差异通常是最有价值的故障线索。
这种方法比孤立解释某一个 QER 字段更可靠。PFCP 信令告诉我们 UPF 应该执行什么，而用户面测试显示的是 实际观察到的结果。比较这两个视角，是判断 QER 是否按预期工作的关键。
FAQ
QER 与 FAR 最主要的区别是什么？
FAR 主要决定匹配后的数据包应该如何处理以及转发到哪里，包括 FORW、DROP、BUFF 等动作。QER 则执行与 QoS 相关的行为，例如 Gate 控制、速率限制、QoS Flow 关联以及传输层标记。两者通常都在 PDR 完成流量识别后发挥作用。可以简单理解为：FAR 决定 数据包要转发到哪里，以及如何转发，而 QER 决定 应该对这部分流量应用什么 QoS 处理。
为什么 Gate Status 为 OPEN 时用户吞吐量仍然可能很低？
OPEN 只表示对应方向的流量允许通过，并不会取消其他 QoS 限制。仍然需要检查 MBR、GBR、Packet Rate 以及关联的 QoS Flow。如果 MBR 配置低于可用的无线或传输容量，即使上下行 Gate 都完全打开，吞吐量仍然会受到限制。
QER 只能在 PFCP Session Establishment 期间创建吗？
不是。QER 可以在 PFCP Session Establishment 期间创建，之后还可以通过 PFCP Session Modification 修改。如果会话运行之后 QoS 行为发生变化，应检查后续 Update QER，而不能只分析最初的 Create QER。
QFI 和 QER 是同一个概念吗？
不是。QFI 是 QoS Flow 的标识符，而 QER 是由 UPF 执行的一条 QoS 规则。QER 可以包含或引用 QFI 信息，从而把特定 QoS 处理关联到对应的 QoS Flow。QFI 标识的是 哪一个 QoS Flow ；QER 定义的是 如何对这部分流量执行 QoS 控制。
为什么 PDR 已经匹配、FAR 也允许转发，流量仍然可能失败？
因为用户面处理并不一定在 FAR 结束。允许转发之后，关联的 QER 仍可能应用 Gate Status、MBR、GBR、Packet Rate 或其他 QoS 约束。因此，故障排查应把 PDR、FAR 和 QER 看作一条连续处理链。其中任何一个阶段不匹配，都可能影响最终业务结果。
