在排查 5G 核心网用户面问题时，经常会遇到一种情况：UE 注册正常，PDU Session 已建立，PDR 能正确识别流量，FAR 也按预期路径转发数据包，但 SMF 侧看到的使用量计数器却始终没有变化。计费事件可能没有被触发，配额控制也可能没有在预期时机响应。很多时候，数据包转发本身完全正常，真正缺少的是一种机制，用来告诉 UPF 应该如何测量用户面使用量，以及何时把测量结果报告给控制面。这个机制就是 N4 接口上的 URR（Usage Reporting Rule，使用量报告规则）。

URR 不负责决定数据包应该转发到哪里，也不会直接执行带宽限制。它告诉 UPF：哪些已匹配的流量需要测量、这些使用量应该如何测量，以及在什么条件下应将测量结果报告给控制面。 因此，URR 让用户面流量不再只是被转发，还可以被计量。实际测量由 UPF 执行，SMF 通过 PFCP 下发报告条件，生成的 Usage Report 则在用户面与控制面之间形成持续的反馈闭环。

URR 在 N4 规则框架中解决什么问题？

理解 URR 最直接的方法，是把它的职责与 PDR、FAR 和 QER 区分开来。UPF 收到数据包后，PDR 首先判断该数据包属于哪类流量；完成分类后，FAR 决定数据包应如何处理以及转发到哪里；QER 则应用所需的 QoS 处理。URR 回答的是另一个问题：这些流量实际已经使用了多少？

PFCP 中主要的规则类型可以概括为：

PDR：这是什么流量？
FAR：数据包应该如何处理，并转发到哪里？
QER：这类流量应该应用什么 QoS 处理？
URR：这些流量已经使用了多少，以及何时应该报告这些使用量？

URR 需要与相关 PDR 建立关联。原因很直接：如果 UPF 还不知道哪些数据包属于某个 UE、业务或流量流，就无法有意义地测量“用户已经使用了多少”。当 PDR 识别出目标流量后，与之关联的 URR 才能对这些匹配数据包的使用量进行测量。如果一个 PDU Session 中包含多个 PDR，也可以使用不同 URR 建立更细粒度的使用量测量关系。

因此，排查 URR 问题时，第一个问题通常不应该是“URR 是否已经下发？”，而应该是：“当前被测流量由哪个 PDR 匹配？该 PDR 引用了哪个 URR ID？” 如果这个关联缺失或错误，后续的测量与报告阶段就无法按预期工作。

URR 如何定义 UPF 要测量的内容？

URR 不只是一个简单的流量计数器。Create URR 中最先定义的要素之一是 Measurement Method（测量方法），它告诉 UPF 应该测量哪一种“使用量”。根据业务需求，测量可以基于流量、时间或事件。

对于常见分组数据业务，基于流量的测量通常最容易观察。UPF 可以测量上行、下行以及总流量，Volume Measurement 中的相关字段则用于指明包含哪些统计项。流量按字节累加，因此 URR 可以统计总使用量，也可以根据配置区分 UL 和 DL 流量。

如果启用了所需能力，测量还可以包含数据包数量。例如，Measurement Information 中的 MNOP 标志可以要求 UPF 测量上行、下行以及总数据包数。这样，运营人员看到的不仅是传输了多少字节，还可以看到在测量周期内处理了多少个数据包。

基于时间的测量关注业务持续时长。根据配置，它可以涉及 Time Threshold、Time Quota、Inactivity Detection Time 以及适用的时间测量机制等参数。基于事件的测量则可以统计特定业务事件，并在事件数量达到指定值时进行报告。

因此，Measurement Method 回答了 URR 最基础的问题：对于这条规则而言，“使用量”究竟指什么？ 如果不先明确这一点，在分析 PFCP 消息时就很容易混淆 Threshold、Quota 和 Reporting Trigger。所选择的测量方法会直接影响 UPF 维护的计数器类型、Usage Report 的格式，以及 SMF 对结果的解释方式。

Reporting Trigger 决定 UPF 何时必须发送报告

只有测量方法还不够。如果 UPF 只是不断累加计数器，却没有任何报告条件，那么 SMF 就没有一个明确的时点来接收结果。因此，Reporting Trigger（报告触发条件） 也是 URR 机制的核心组成部分。

这些触发条件可以根据网络策略组合使用。PERIO 可用于周期性报告；VOLTH 表示达到流量阈值时应生成报告；TIMTH 对应时间阈值；当 UPF 检测到流量开始或停止时，START 和 STOPT 可以触发 Usage Report。

另一组触发条件与配额控制关系更紧密。VOLQU 与流量配额条件相关，TIMQU 与时间配额条件相关，EVEQU 与事件配额条件相关。当已经授予配额，但用户在指定时间内没有产生用户面流量时，还可以使用 Quota Holding Time。

尤其需要区分 Threshold（阈值） 和 Quota（配额），因为它们在 PFCP 中承担不同作用，在跟踪分析时也经常被混淆：

Threshold 主要关注的是何时应该报告测量结果，而 Quota 更接近于还剩多少资源可以使用。如果 PFCP 跟踪中只看到设置了 VOLTH 或 VOLQU，但工程师没有继续检查对应的 Threshold 或 Quota 参数，就很容易误判实际业务逻辑。

例如，如果配置了 VOLTH，但没有正确定义对应的 Volume Threshold，那么 UPF 就没有一个有意义的流量边界来触发预期报告。

UPF 如何把使用量结果发送给 SMF？

URR 机制通过 PFCP Session Report 流程形成完整反馈闭环。一旦满足 URR 定义的报告条件，UPF 不一定需要等待 SMF 主动查询计数器，而可以直接向 SMF 发送 PFCP Session Report Request。

当 Report Type 表明消息中包含 Usage Report 时，SMF 可以识别这是一个用户使用量报告事件。分析时有几个字段尤其重要：URR ID 用于标识是哪条规则生成了报告；UR-SEQN 标识该 URR 的 Usage Report 序号；Usage Report Trigger 则说明生成报告的原因。

实际测量值会出现在与 Measurement Method 相对应的字段中。对于基于流量的测量，Volume Measurement 可以包含总量、上行和下行使用量；对于基于时间的测量，Duration Measurement 更为重要。Start Time、End Time、Time of First Packet 和 Time of Last Packet 等字段也可以帮助确定报告覆盖的准确测量区间。

收到 Usage Report 并不一定意味着流程结束。根据业务逻辑，SMF 还可以继续发送 PFCP Session Modification 来更新 URR，例如修改报告阈值、分配新的配额，或调整下一次报告的触发条件。

完整的 URR 工作流程可以概括为：

SMF 下发 URR → UPF 测量匹配流量 → 满足 Reporting Trigger 条件 → UPF 发送 Usage Report → SMF 处理使用量结果 → 如有需要则更新 URR。

因此，使用量报告并不只是 UPF 上传一个计数器值，而是一个动态过程：控制面定义测量策略，用户面执行测量，结果持续反馈给控制面。任何一个阶段出现问题，都可能导致使用量数值不准确或报告缺失。

Volume Threshold 如何触发实际的 Usage Report？

把 URR 放到具体流量场景中会更容易理解。假设 SMF 在 PFCP Session Establishment 过程中创建一条 URR，并指示 UPF 对某个指定 PDR 匹配到的流量采用基于流量的测量，同时启用 VOLTH 作为 Reporting Trigger。

如果 Volume Threshold 配置为 TOVOL，取值为 10240 字节，这条规则并不是说用户最多只能使用 10240 字节，而是表示：当测得的上行与下行总流量达到该阈值时，UPF 应生成 Usage Report。

随着 UE 开始产生流量，UPF 会继续正常转发数据包，同时累加 URR 定义的使用量计数器。当累计流量达到报告阈值后，UPF 发送 PFCP Session Report Request。Usage Report 会把 VOLTH 标记为触发原因，而 Volume Measurement 则包含实际总使用量以及相应的上行、下行数值。

最终报告值并不一定恰好停在 10240 字节。UPF 是在处理真实数据包的过程中判断阈值，一个完整数据包可能会让累计使用量从阈值以下直接跃升到阈值以上。因此，Usage Report 中的数值略高于配置的 Threshold 并不矛盾。

由此可以得到分析 URR 行为时的一条重要原则：Threshold 是报告边界，而不是把测量值截断到某个精确数字的机制。 如果同时配置了 Quota，配额耗尽可能会触发额外的控制行为，但应把它作为独立的控制路径分析，而不要与简单的阈值触发报告混为一谈。

URR 排障应按四层展开：关联、测量、触发与报告

URR 问题往往不容易被发现，因为用户面业务本身可能看起来完全正常。UE 可以访问网络，PDR 匹配正确，FAR 也持续转发数据包，但后台看到的使用量计数器仍然错误，可能没有生成 Usage Report，或者达到阈值后预期的控制面事件始终没有发生。

因此，排查 URR 时不应从“用户能否访问网络？”开始，而应沿着完整的使用量测量链逐层检查。

首先确认 PDR 与 URR 的关联

先找出实际匹配当前流量的 PDR，再确认与之关联的 URR ID。一个 PFCP Session 可能包含多个 PDR 和多个 URR。即使某条 URR 的所有参数看起来都正确，如果分析的是错误的 URR，也无法解释当前的使用量结果。

一种典型问题是 PDR 的匹配条件已经发生变化，但 URR 仍然与之前的 PDR ID 关联。此时，测量目标本身已经偏离了实际流量。

然后核对 Measurement Method 和方向

检查 URR 配置的是 Volume、Duration 还是 Event 测量。如果使用基于流量的测量，还要确认规则测量的是 Total、UL、DL，还是同时包含数据包计数。

当上行和下行统计与预期不一致时，这一步尤其重要。有些看似故障的情况，只是因为 URR 只测量一个方向，而测试流量实际走的是另一个方向，因此预期计数器一直没有变化。

检查 Reporting Trigger 及其对应 Threshold

如果 UPF 没有生成报告，应确认控制面实际请求了哪一种触发条件。配置了 VOLTH 却没有合适的 Volume Threshold，或者在没有启用 PERIO 的情况下期待周期性报告，都会导致实际结果与预期业务行为不同。

同样，基于时间的报告也应结合相关时间测量参数和监控条件一起解释，而不能只孤立查看某一个触发标志。

最后跟踪 PFCP Session Report

触发条件满足后，确认 UPF 是否发送了预期的 Usage Report。需要结合当前 PFCP Session 检查 Report Type、URR ID、UR-SEQN 和 Usage Report Trigger。

如果 UPF 已经生成报告，但没有出现新的配额、阈值或后续控制动作，排障重点就应该转向 SMF 以及后续控制面逻辑，而不是继续停留在 UPF 计数器上。

如果问题涉及 QoS 执行前或执行后的测量，还需要检查 Measurement Information 和 Usage Information 中的相关标志。URR 并不是一个孤立的数字。测量时间窗口、被测流量以及执行测量时所处的处理阶段都会影响最终使用量数值应如何解释。

很多“使用量对不上”的案例，并不是 UPF 计数器本身错误，而是实际测量范围与预期计费范围之间不一致。

URR 把用户面流量转化为控制面可计量的信息

PDR、FAR 和 QER 主要描述数据包在 UPF 内如何被识别、转发并接受 QoS 处理。URR 增加了另一项关键能力：让控制面能够知道用户面流量实际已经消耗了多少。

URR 使用 Measurement Method 定义测量范围，使用 Reporting Trigger 决定何时需要报告，并通过 Threshold、Quota、Monitoring Time 等参数控制使用量测量的不同阶段。满足所需条件后，UPF 会通过 PFCP Usage Report 把结果发送回 SMF，之后控制面可以在需要时更新 URR 或执行其他策略动作。

因此，理解 URR 最实用的方法不是记住几十个 Information Element，而是沿着一条完整链路理解：

PDR 选择要测量的流量 → URR 定义测量方法 → UPF 持续测量使用量 → Reporting Trigger 决定何时报告 → Usage Report 把结果返回 SMF → SMF 按需更新控制策略。

当这条链路明确后，Volume Threshold、Volume Quota、Measurement Period、Monitoring Time 以及各种 Reporting Trigger 就不再是彼此孤立的 PFCP 字段，而是同一套 5G 使用量测量与报告机制中的不同控制点。

对于需要按使用量计费、实时配额管理，或根据使用情况动态调整策略的业务，这套机制提供了基础，使 5G 用户面不仅能够转发流量，还能做到可测量、可控制。

常见问题