51学通信

深度解析TS 29.244：5.4 Policy and Charging Control (策略与计费控制) - Part 3 预定义规则、计费与应用上报

31分钟阅读

深度解析TS 29.244：5.4 Policy and Charging Control (策略与计费控制) - Part 3 预定义规则、计费与应用上报

本文技术原理深度参考了3GPP TS 29.244 V18.9.0 (2025-03) Release 18规范中，关于“5.4.9 Provisioning of Predefined PCC/ADC Rules”、“5.4.10 Charging”以及“5.4.11 (Un)solicited Application Reporting”的核心章节，旨在为读者提供一个关于预定义规则、计费实现与动态应用上报机制的全景视图。

引言

在前两篇文章中，我们已经深入探讨了PCC架构的基础机制（业务检测、门控、QoS控制）和高级流量管控手段（标记、监控、重定向与疏导）。这些机制共同构成了SMF通过N4接口指挥UPF处理数据流的“语法”。现在，我们将进入更为贴近运营商实际运营的领域，探讨如何利用这些“语法”来构建高效、可盈利且具备智能感知的网络服务。

本篇文章将聚焦于三大核心主题：预定义规则、计费、以及应用上报。这三者分别回答了三个关键问题：

  1. 效率：当网络中有成千上万的用户使用相同的策略时，如何最快、最省信令地激活这些策略？这就是“预定义规则”要解决的问题。
  2. 变现：运营商如何将网络能力转化为商业价值？“计费”机制是这一切的基石，它精确度量用户的资源消耗，并与在线/离线计费系统联动。
  3. 智能：网络如何动态感知用户行为，并据此触发相应的策略或增值服务？“应用上报”机制赋予了网络这种“嗅觉”。

我们将继续跟随5G用户小明的一天。今天，小明被一款新推出的“5G云游戏”应用所吸引，这款应用宣称可以提供极致的低延迟体验，但需要付费订阅。从他决定试用开始，我们将看到预定义规则如何为他秒速开通服务，在线计费系统如何实时监控他的游戏流量，以及网络如何在他启动和关闭游戏时，向上层策略大脑进行汇报。

1. 预定义PCC/ADC规则的下发 (5.4.9 Provisioning of Predefined PCC/ADC Rules)

想象一下，如果每次有用户开通一项热门业务，SMF都需要将一大堆PDR、FAR、QER、URR规则的详细参数通过N4接口下发给UPF，这将产生巨大的信令开销。为了提升效率，3GPP设计了预定义规则机制。

A Predefined PCC rule is preconfigured in the PCEF, e.g. a PGW (for EPC) or SMF (for 5GC). Predefined PCC rules can be activated or deactivated by the PCRF/PCF at any time. The Predefined PCC rules may be grouped allowing the PCRF/PCF to dynamically activate a set of PCC rules. For EPC a predefined ADC rule is preconfigured in the TDF. … Predefined ADC rules within the TDF may be grouped allowing the PCRF to dynamically activate a set of ADC rules.

规范指出，所谓的预定义PCC/ADC规则，是预先配置在策略执行点（如5GC的SMF）或流量检测功能（如EPC的TDF）中的规则集。策略控制核心（PCF/PCRF）可以随时通过名字或分组来激活或去激活这些规则，而无需下发规则的全部细节。TS 29.244进一步阐述了这些来自上层的“意图”如何被翻译成N4接口上的具体行动。

1.1 动态规则强制执行

第一种方式是，规则本身预定义在CP功能（如SMF）中。当SMF收到PCF激活预定义规则的指令后，它会在本地查找该规则的完整定义，然后动态地生成并下发一系列PFCP规则给UPF。

The CP function may enforce an activated predefined PCC or ADC rule by the PCRF/PCF in the UP function by:

  • determining the service data filters or application IDs referred by the activated predefined PCC or ADC rule(s) and the corresponding QoS and charging control information respectively;
  • creating the necessary PDR(s) to identify the service data flow(s), application(s) …
  • creating the necessary QER … FAR … URR(s) … and then:
  • associating the created URR(s) … FAR … to the newly created PDR(s).

这种方式虽然仍然需要下发完整的PFCP规则，但将策略的复杂性收敛在了CP功能侧，UPF无需感知“预定义规则”的概念，其配置模型保持了一致性。

场景代入：小明订阅“云游戏”标准版

小明打开运营商APP，看到了“5G云游戏”的订阅选项。他选择了“标准版”，每月30元。

  1. 策略激活：小明的操作通过APP后台通知了PCF。PCF查询后得知，“云游戏标准版”对应的预定义PCC规则名为“CloudGame-Standard”。PCF于是向SMF发送指令：“为用户小明激活规则‘CloudGame-Standard’”。
  2. SMF翻译与下发：SMF在自己的配置中找到了“CloudGame-Standard”的定义，它包含：
    • 应用ID：“CloudGame-App”。
    • QoS：需要保证5Mbps下行速率，峰值10Mbps。
    • 计费：计入“云游戏”专属流量包。
  3. SMF随即向UPF发送一条PFCP Session Modification Request，其中包含了为实现上述策略而动态创建的全套规则：一条Create PDR（用于识别CloudGame-App），一条Create QER（用于执行5/10Mbps的速率限制），以及一条Create URR（用于计量游戏流量）。

1.2 UPF侧预配置规则的激活

更高效的方式是将这些通用的策略模板直接预配置在UPF中。这样，SMF激活服务时，只需告诉UPF要激活哪个“套餐”即可。

Optionally, the traffic handling policies common to many PFCP sessions (i.e. predefined PDR(s) / QER(s) / FAR(s) / URR(s)) may be configured in the UP function. The CP function may activate these traffic handling policies by including the Activate Predefined Rules IE or by including predefined FAR/URR/QER ID(s) (of which the most significant bit is set to “1”) within … a PFCP Session Establishment Request; or … a PFCP Session Modification Request.

这里提到了两种激活方式：

  • 通过名称激活：使用Activate Predefined Rules IE，其中包含一个预定义规则的名称。这个名称通常对应UPF本地配置的一整套PDR、FAR、QER、URR。
  • 通过ID激活：在创建或更新PDR时，直接引用预定义的FAR ID、URR ID、QER ID。规范约定，这些预定义规则的ID，其最高有效位（第8位）被设置为“1”，以区别于动态规则ID。

场景代入：小明升级为“云游戏Pro版”

玩了一会儿，小明觉得“标准版”画质不够好，决定升级到“Pro版”。

  1. 策略决策：“云游戏Pro版”是一项非常普遍的业务，其策略模板“CloudGame-Pro”早已被运营商预置到了网络中所有的UPF里。这个模板定义了更高的QoS（如GBR 20Mbps）和独立的计费规则。
  2. SMF激活指令：小明在APP上点击升级后，PCF通知SMF为他激活“CloudGame-Pro”规则。
  3. SMF不再需要下发冗长的规则细节，而是向UPF发送一条PFCP Session Modification Request。其中，它可能会创建一个新的PDR，或者更新已有的游戏PDR。在这条Create PDR或Update PDR IE中，SMF包含了一个关键信息：Activate Predefined Rules IE，其内容就是字符串“CloudGame-Pro”。
  4. UPF本地激活：UPF收到这个指令后，在自己的预配置库中查找名为“CloudGame-Pro”的规则集，并将其中的PDR模板、FAR、QER、URR全部激活并与小明的PFCP会话关联起来。瞬间，小明的游戏流量就被切换到了更高质量的QoS通道上。整个过程信令极其精简高效。

1.3 预定义规则的去激活

服务的开通需要激活规则，服务的关闭或变更则需要去激活。

For deactivating predefined rules which have been activated in the UP function using a Predefined Rule Name, the CP function shall include the Deactivate Predefined Rules IE in the Update PDR IE … For deactivating predefined FAR(s) /URR(s) / QER(s) which have been activated … by including predefined FAR/URR/QER ID(s) …, the CP function may include Remove FAR IE(s), Remove URR IE(s) and/or Remove QER IE(s) …

同样地，去激活也分为两种方式：

  • 通过名称去激活：如果当初是通过Activate Predefined Rules IE激活的，现在就可以通过Deactivate Predefined Rules IE来取消整个规则集的激活。
  • 通过ID移除：如果当初是在PDR中直接关联了预定义的FAR/URR/QER ID，现在就可以通过发送Remove FAR、Remove URR或Remove QER消息（携带相应的预定义ID）来解除这些规则与PDR的关联。

2. 计费 (5.4.10 Charging)

计费是移动网络运营的核心。TS 29.244详细描述了PCC架构中的计费策略是如何通过N4接口在用户面落地的。其本质是基于用量监控（Usage Monitoring） 的策略执行。

Charging is supported by the CP function by activating in the UP function the measurement and reporting of the accumulated usage of network resources … The CP function shall control the usage measurement and reporting in the UP function by:

  • creating the necessary PDR(s) …
  • creating URR(s) for each Charging Key, combination of Charging Key and Service ID …
  • associating the URR(s) to the relevant PDRs …

简而言之，计费的PFCP实现流程是：

  1. 识别计费对象：通过PDR识别出需要计费的流量，如某个应用、某个QoS流，或者整个PDU会话。
  2. 创建计量桶：为每个计费项（由Charging Key等标识）创建一个URR。这个URR就像一个水表，专门计量特定流量的用量。
  3. 关联：将URR与PDR关联起来，告诉UPF“匹配这条规则的流量，请用这个水表来计量”。

2.1 在线计费（Online Charging）

在线计费，也称预付费，是计费场景中最典型和复杂的一种。它要求网络在用户的信用额度（Quota）耗尽前停止服务，以避免产生坏账。

For online charging, or for converged charging making use of quotas, the CP function shall provision the URR with the Volume (or Time) Quota, and with the Volume (or Time) Quota if a quota threshold was received from the OCS, as specified in clause 5.2.2.2. … when exhausing this quota, the CP function shall redirect the traffic towards a redirect destination as specified in clause 5.4.7 upon being notified that the final quota has been reached …

我们通过小明的“云游戏Pro版”体验来详细拆解这个流程，并参考规范附录C中的流程图Figure C.2.1.1-1。假设Pro版服务按流量计费，小明账户里有100元，单价为1元/GB。

  1. 首次申请信用：当小明启动游戏时，SMF向OCS（在线计费系统）为该业务申请信用额度。OCS检查小明账户余额后，决定先授予10GB的配额（Quota），并要求SMF在额度剩余1GB时（即用了9GB后）上报用量并申请新的信用。
  2. 下发计费规则：SMF向UPF发送PFCP Session Modification Request，其中包含一条Update URR（或Create URR），这条URR针对云游戏业务，并包含两个关键IE：
    • Volume Threshold (容量阈值) = 9 GB。
    • Volume Quota (容量配额) = 10 GB。
  3. 用量上报与持续转发：小明畅玩游戏。当UPF上的URR计数器累计到9GB时，达到了Volume Threshold。UPF立即向SMF发送PFCP Session Report Request，报告已使用9GB。重要的是，此时UPF并不会停止转发数据，因为它还有1GB的配额余量（10GB - 9GB）。它会继续为小明服务，直到10GB配额全部用完。
  4. 再次申请信用：SMF收到用量报告后，再次向OCS申请信用。OCS再次授予10GB，同样要求在用完9GB时上报。
  5. 更新配额：SMF再次向UPF发送PFCP Session Modification Request，更新同一条URR，将Volume Threshold和Volume Quota重新设置为9GB和10GB。UPF收到新配额后，会从当前已用量（可能已经超过了上次上报的9GB，比如是9.2GB）开始，继续在新配额下计数。
  6. 最终配额与停止服务：这个过程循环往复。最后一次，小明的账户余额只够买5GB流量了。OCS在回复SMF时，会告知这是一个最终配额（Final Quota）。
  7. 下发最终配额：SMF向UPF下发更新后的URR，这次只包含Volume Quota = 5GB，不再有Volume Threshold。
  8. 配额耗尽与停止转发：当UPF计量到这5GB流量也用完时，它会向SMF发送最后一次用量报告，报告触发原因是Volume Quota耗尽。同时，UPF将立即停止转发匹配该PDR的所有后续数据包。
  9. 终止服务：SMF收到最终报告后，执行服务终止逻辑，例如，可以指示UPF将后续的游戏流量重定向到一个充值页面。

2.2 应对资费变更

运营商的资费可能会在特定时间点发生变化（如零点之后进入夜间优惠套餐）。为了实现精确计费，需要在资费变更的瞬间，对变更前后的流量进行分别统计。

To avoid the risk of signalling storms between the CP and UP functions at times of tariff change, the CP function may include the Monitoring Time IE and zero or more Additional Monitoring IEs in the URR and set it to the time of tariff change to request the UP function to report separately the resource usage before and after the time of tariff change.

Monitoring Time IE就是为了这个目的而设计的。SMF可以在URR中设置一个未来的时间点。当UPF的系统时钟到达该时间点时，它会自动将此刻之前的用量打一个包，生成一份用量报告；然后重置计数器（或阈值），继续计量该时间点之后的用量。这确保了在资费变更的精确时刻，用量被清晰地分割开来，避免了账务纠纷。

3. (非)请求的应用上报 (5.4.11 (Un)solicited Application Reporting)

除了被动地执行策略，网络还需要具备主动感知能力，即当检测到用户开始或停止使用某个特定应用时，能够主动通知策略控制中心，以便触发动态策略。

For 5GC, solicited Application Reporting refers to the process of reporting the start or stop of applications by the SMF to the PCF. See 3GPP TS 23.503 and 3GPP TS 29.512. Unsolicited application reporting is not applicable for 5GC.

在5GC中，应用上报是“请求式（Solicited）”的，即由PCF预先向SMF订阅，要求当某个应用启动或停止时进行上报。其PFCP实现机制如下：

The CP function shall instruct the UP function to detect and report applications by:

  • creating the necessary PDR(s) to represent the applications to detect;
  • creating a URR with the Reporting Trigger IE set to detect the start and/or stop of Traffic;
  • …
  • associating the URR to the PDR.

3.1 上报应用启动/停止

流程非常直观：SMF创建一个用于识别目标应用的PDR，再创建一个特殊的URR，其Reporting Trigger中包含Start of Traffic或Stop of Traffic标志位，然后将二者关联。

场景代入：网络感知小明开关游戏 运营商为了分析“云游戏Pro”业务的使用情况，希望知道用户何时开始和结束游戏。

  1. 订阅事件：PCF向SMF订阅“CloudGame-Pro”应用（由特定应用ID标识）的启动和停止事件。
  2. PFCP配置：SMF向UPF下发一条Create URR，其Reporting Trigger中同时设置了Start of Traffic和Stop of Traffic两个标志位。这条URR被关联到识别“CloudGame-Pro”的PDR上。
  3. 上报启动：当小明启动游戏，第一个游戏数据包到达UPF并匹配了该PDR时，UPF检测到Start of Traffic触发器，立刻生成一份PFCP Session Report Request发往SMF。这份报告的Usage Report中，Usage Report Trigger被设置为’Start of Traffic’。
  4. 上报停止：小明玩了很久，最后关闭了游戏。UPF在一段时间内没有再收到该PDR匹配的数据包（具体超时逻辑由UPF实现），判定业务已停止，于是再次生成一份报告，这次的Usage Report Trigger被设置为’Stop of Traffic’。

3.2 上报内容

为了让PCF做出更精准的决策，UPF在上报时会提供丰富的上下文信息。

When detecting the start or stop of an application, the UP function shall then initiate the PFCP Session Report procedure and send a Usage Report … The UP function shall also include the following information in the Usage Report:

  • … Application ID;
  • … Flow Information including the Flow Description and the Flow Direction …;
  • … Application-Instance-Identifier …; and
  • if no UE IP address was provisioned in the PDI, the UE’s IP address …

上报内容包括：

  • 应用ID：明确是哪个应用触发了上报。
  • 流信息（Flow Information）：包含了数据流的五元组信息。这极其有用，因为它让PCF可以为这个特定的数据流（例如，小明与某个特定游戏服务器的连接）制定一个精细化的PCC规则。
  • 应用实例ID（Application-Instance-Identifier）：由UPF生成，用于唯一标识这一次的应用会话。当后续上报该应用停止时，会携带相同的ID，使得PCF可以准确地将启动和停止事件配对。

3.3 结合零配额实现“先授权，后通信”

应用上报机制与零配额（Zero Quota）相结合，可以实现一种非常强大的控制模式：在用户流量真正通过网络之前，先将其“截停”，等待上层应用或策略系统授权后，再放行。

the CP function may include a zero quota together with a FAR ID for Quota Action IE in the URR to instruct the UP function to drop or buffer the packets pertaining to the detected application traffic before the quota is granted in the subsequent PFCP Session Modification Request message.

场景代入：小明试玩付费关卡 小明的“云游戏Pro”中有一个特殊的付费关卡。运营商策略是，用户首次进入该关卡时，需要弹窗确认付费。

  1. 初始配置：SMF为该付费关卡（通过特定的服务器IP或应用特征识别）配置了一条PDR。与该PDR关联的URR中，Reporting Trigger设置为Start of Traffic，同时Volume Quota被设置为 0。此外，该URR还关联了一个FAR ID for Quota Action，指向一条指示动作为**BUFF（缓冲）**的FAR。
  2. 触发与截停：小明点击进入付费关卡，第一个数据包发往UPF。
    • UPF匹配PDR，Start of Traffic触发器被激活，UPF立即向SMF上报应用启动事件。
    • 同时，UPF检查URR，发现配额为0，于是执行配额耗尽动作——查找FAR ID for Quota Action，将该数据包缓冲起来，而不是丢弃或转发。
  3. 应用层交互：SMF收到报告后，通过PCF通知游戏应用服务器。游戏APP在小明的手机上弹出一个付费确认框。
  4. 授权与放行：小明点击“确认支付”。支付成功后，应用服务器通知PCF，PCF通知SMF。SMF从OCS获取到新的配额，然后向UPF发送PFCP Session Modification Request，更新该URR，为其设置一个非零的Volume Quota。
  5. 业务恢复：UPF收到新配额后，立即将缓冲区中的数据包发出，并允许后续的游戏流量正常通过。对小明而言，他只是看到了一个付费弹窗，确认后游戏就无缝地继续了，完全没有感觉到网络的中断。

总结

在本篇文章中，我们深入探讨了PCC策略落地执行的三个高级方面，它们将基础的网络能力转化为高效、可盈利的商业实践：

  • 预定义规则 (5.4.9)：通过在UPF侧预配置通用策略模板，SMF只需通过一个简单的名称或ID即可激活或去激活复杂的服务策略，极大地降低了信令开销，提升了业务开通和变更的效率。
  • 计费 (5.4.10)：基于URR的用量监控机制，通过设置阈值（Threshold）和配额（Quota），实现了与在线计费系统（OCS）的紧密联动。阈值触发信用再申请，配额耗尽则停止服务，从而构成了在线计费的闭环控制。
  • 应用上报 (5.4.11)：通过在URR中设置启动/停止流量的触发器，使得UPF具备了主动感知用户应用行为的能力，并能将带有丰富上下文（如流信息、实例ID）的事件上报给SMF/PCF，为动态策略决策和“先授权后通信”等高级业务模式提供了可能。

这些机制的组合使用，使得运营商能够灵活设计和部署各种复杂的业务套餐，实现从“尽力而为”的管道工到“智能服务”提供商的转变。在下一篇文章中，我们将继续解析5.4章的剩余部分，探讨一些更为具体的策略执行技术，如传输层标记和延迟PDR激活等。

FAQ

Q1：使用“预定义规则”有什么好处？它与SMF动态生成规则有什么区别？ A1：主要好处是效率和信令开销的降低。当一项业务策略非常通用（例如标准视频业务的QoS），将其作为“预定义规则”配置在UPF中后，SMF在为用户激活此业务时，无需再下发包含所有PDR/QER/URR细节的冗长消息，只需发送一个简短的“激活”指令，如规则名称即可。这大大减少了N4接口的信令负荷，加快了业务的响应速度。而动态生成规则则是SMF将所有规则的细节实时计算并下发给UPF，灵活性更高，但信令开销也更大。

Q2：在线计费中，URR的“Volume Threshold”（容量阈值）和“Volume Quota”（容量配额）是如何协同工作的？ A2：“Volume Quota”是OCS授予的总信用额度，代表用户最多能使用的流量。当这个额度用完时，UPF必须停止转发数据。“Volume Threshold”则是一个提前告警的触发点，通常设置为略小于配额的值。当用量达到阈值时，UPF会向SMF上报用量，以便SMF提前向OCS申请下一个周期的信用，但此时UPF并不会停止转发数据，用户可以继续使用阈值和配额之间的余量。这种“边用边申请”的机制保证了用户业务的连续性。

Q3：什么是“（非）请求的应用上报”，它在5GC和EPC中有什么不同？ A3：应用上报是指UPF在检测到用户开始或停止使用某个特定应用时，主动向CP功能（SMF）报告的机制。在5GC中，该功能是“请求式（solicited）”的，即必须由PCF先向SMF订阅，SMF再指令UPF去监视和上报特定应用的行为。而在EPC架构中，除了请求式，还支持“非请求式（unsolicited）”，即TDF可以根据本地策略，主动上报它认为有价值的应用启动/停止事件，即便没有收到PCRF的预先订阅。

Q4：为什么在应用上报时，UPF上报的“Flow Information”（流信息）非常重要？ A4：“Flow Information”包含了被检测到的应用数据流的五元组信息（源/目的IP、源/目的端口、协议）。这使得PCF可以从一个宽泛的应用识别（例如“所有视频流量”）下钻到一个极其具体的数据流（例如“小明手机与特定视频服务器之间的这条TCP连接”）。PCF可以基于这个精确的流信息，生成一条专门针对它的、高度定制化的PCC规则（如提升QoS或重定向），从而实现非常精细化的策略控制。

Q5：如何利用应用上报和零配额实现“先付费再使用”的业务模式？ A5：通过组合PFCP规则可以实现。首先，SMF为该付费业务配置一个PDR。其次，配置一个关联的URR，其触发器设置为Start of Traffic，并将Volume Quota设置为0。最后，配置一个当配额为0时执行的动作，例如通过FAR ID for Quota Action指向一条行为为BUFF（缓冲）的FAR。当用户首次访问该业务时，UPF会检测到流量并上报启动事件，同时因为配额为0而将数据包缓冲起来。上层系统收到事件后引导用户付费。支付成功后，SMF下发新的、非零的配额给URR，UPF随即释放缓冲的数据包并允许业务流量通过。

关系图谱