好的，我们立即开始下一部分的深度解读。
在Part 1中，我们已经理解了计费会话的生命周期和驱动它的核心——触发器机制。现在，我们将进入整个5G数据计费规范中信息量最大、细节最丰富的“藏宝图”——默认触发器表。这张表是网络工程师的“行动手册”，详细定义了在PDU会话的每一个关键时刻，SMF应该如何与CHF进行交互。
由于表格内容极其详尽，我们将按照逻辑，结合具体场景，逐类解析这些触发器，力求将这张看似复杂的表格变得清晰易懂。
深度解析 3GPP TS 32.255：5.2.1 融合计费场景基础原则 (Part 2 - 触发器详解与FBC/QBC机制)
本文技术原理深度参考了3GPP TS 32.255 V18.6.0 (2024-12) Release 18规范中，关于“5.2.1 Basic principles”的核心章节，特别是“Table 5.2.1.4-1: Default Trigger conditions in SMF”和“Table 5.2.1.4-2: Chargeable events and their related actions in SMF”，旨在为读者庖丁解牛般地拆解5G计费触发器的具体工作机制。
1. 解读“天书”：默认触发器表 (Table 5.2.1.4-1)
这张表格是CHF与SMF之间关于何时以及如何上报计费信息的“默认契约”。它定义了一系列默认的触发条件、它们的触发级别、在不同计费模式下的默认报告类型（立即/延迟），以及CHF是否有权限去修改这些默认行为。
让我们将这张大表拆解为几大逻辑类别，结合我们熟悉的主角“小杰”的5G生活，来逐一攻克。
1.1 会话的起点与终点 (Session Start/Stop Triggers)
| Trigger Conditions | Trigger level | Converged Default | CHF allowed to change | Message |
|---|---|---|---|---|
| Start of PDU Session | PDU session | Immediate | Not Applicable | Charging Data Request [Initial] |
| Start of the Service data flow | RG | Immediate | No | Charging Data Request [Initial] or [Update] |
| Termination of service data flow | RG | Immediate | No | Charging Data Request [Update] |
| End of PDU session | PDU session | Immediate | No | Charging Data Request [Termination] |
深度解析与场景再现：
- PDU会话建立 (Start of PDU Session)：小杰早晨开机，PDU会话建立。这是一个立即报告事件，SMF必须立刻发送
Initial请求，为整个会话“开户”，这是毋庸置疑的。CHF无权改变这一行为。 - 业务流开始 (Start of SDF)：小杰点开了一个需要在线计费的游戏App。
If quota management is required, and valid quota for this rating group does not exist 这是最典型的“业务流开始”触发场景。SMF发现这个游戏被映射到一个新的Rating Group，并且自己手上没有这个Rating Group的可用配额。它必须立即向CHF发送
Update请求去“要钱”（申请配-额），否则游戏就无法运行。 - 业务流终止 (Termination of SDF)：小杰退出游戏。SMF检测到对应Rating Group下的最后一个业务数据流消失了。这是一个立即报告事件，SMF会发送
Update消息，通知CHF“这个计费项结束了”，以便CHF可以进行阶段性结算。 - PDU会話结束 (End of PDU session)：小杰关闭移动数据。这是一个立即报告事件，SMF必须立刻发送
Termination请求，为整个会话“结账”。
1.2 网络环境的变化 (Network Condition Change Triggers)
这类触发器反映了用户所处的网络环境的动态变化。
| Trigger Conditions | Trigger level | Converged Default | CHF allowed to change |
|---|---|---|---|
| QoS change | PDU session/RG | Deferred | Yes |
| User Location change | PDU session/RG | Deferred | Yes |
| Serving Node change | PDU session/RG | Deferred | Yes |
| PLMN change | PDU session/RG | Immediate | Yes |
| RAT type change | PDU session/RG | Immediate | Yes |
深度解析与场景再现：
小杰正乘坐高铁，手机网络环境在不断变化。
- QoS变更 (QoS change)：小杰正在看的视频，由于网络拥塞，清晰度从高清（高QoS）降为标清（低QoS）。这是一个延迟报告事件。SMF会默默记录下QoS变化的时间点和前后的使用量，等到下次有机会再一并上报。因为这种微小的QoS抖动通常不影响计费策略，频繁上报会浪费信令。
- 位置/服务节点变更 (User Location/Serving Node change)：高铁每经过一个基站，都会发生切换。这同样是延迟报告事件，理由同上，为了避免信令风暴。
- PLMN/RAT变更 (PLMN/RAT type change)：
- 高铁穿过省界，小杰的手机漫游到了邻省运营商的网络（PLMN change）。
- 高铁进入隧道，5G信号消失，手机无缝回落到了4G网络（RAT type change）。 这两个事件都被设为立即报告。为什么？因为它们通常意味着计费策略的根本性改变（例如，可能触发漫游计费，或者4G/5G的套餐资费不同）。CHF需要立即得知这一变化，以便下发新的计费规则。
CHF对这些触发器大多拥有修改权限（Yes）。例如，对于VIP用户，运营商可能希望每次QoS变化都立即上报以进行精细的SLA监控，此时CHF就可以在响应中将QoS change的报告模式修改为Immediate。
1.3 配额管理的核心 (Quota Management Triggers)
这是在线计费的“心跳”，确保用户不会超额消费。
| Trigger Conditions | Trigger level | Converged Default | CHF allowed to change |
|---|---|---|---|
| Volume/Time/Unit threshold reached | RG | Immediate | No (threshold value is configurable by CHF) |
| Volume/Time/Unit quota exhausted | RG | Immediate | No |
| Re-authorization request by CHF | RG | Immediate | No |
深度解析与场景再现：
CHF为小杰的游戏业务（按时长计费）授予了10分钟的配额，并设置了80%的阈值。
- 阈值到达 (Threshold reached)：小杰玩了8分钟游戏，达到了阈值。这是一个立即报告事件。SMF立刻向CHF发送
Update请求，报告已用时长，并提前申请下一笔配额。这样设计是为了“无缝续杯”，在当前配额耗尽前，新的配额就已经准备好了，保证业务不中断。 - 配额耗尽 (Quota exhausted)：如果因为网络延迟等原因，SMF没来得及在耗尽前收到新配额，当10分钟配额用完时，
Quota exhausted事件被触发。SMF同样会立即上报，并等待CHF的下一步指示（是授予新配额，还是根据策略终止服务）。 - CHF强制再授权 (Re-authorization request by CHF)：在小杰玩游戏的第5分钟，他的账户发生了一些变化（例如，他通过营业厅App刚充了值）。CHF希望立刻重新评估他的信用和计费策略，于是主动向SMF发送了一个“再授权”请求。SMF收到后，会立即触发一次
Update流程，向CHF报告当前用量并获取最新的计费指令。
这些核心的配额管理触发器，CHF都无权关闭，只能调整阈值的具体数值，确保了在线计费体系的强制性和可靠性。
1.4 复杂拓扑与切换 (Topology & Handover Triggers)
这类触发器应对5G灵活的网络拓扑和移动性。
| Trigger Conditions | Trigger level | Converged Default | CHF allowed to change |
|---|---|---|---|
| Addition/Removal of UPF | PDU session/RG | Immediate | Yes |
| Insertion/Removal of I-SMF | PDU Session | Deferred | Yes |
| Handover start | PDU session | Immediate | Yes |
| Handover complete | PDU session | Immediate | Yes |
深度解析与场景再现：
- UPF增/删 (Addition/Removal of UPF)：小杰的PDU会话最初只有一个中心UPF。当他开始玩需要边缘计算的云游戏时，网络为他新增了一个边缘UPF。这是一个立即报告事件。SMF必须立刻通知CHF：“现在有两个UPF在为这个会话服务了”。这对于CHF进行多UPF的配额分配和使用量汇总至关重要。
- I-SMF增/删 (Insertion/Removal of I-SMF)：小杰开车进入了一个由I-SMF管理的工业园区。网络为他的会话插入了一个I-SMF。这是一个延迟报告事件。因为I-SMF的计费信息是汇聚到锚点SMF再统一上报的，对CHF来说是透明的，所以这个拓扑变化本身不需要立即通知CHF。
- 切换开始/完成 (Handover start/complete)：当小杰的手机准备从5G切换到4G时，
Handover start事件触发，这是一个立即报告。SMF需要立刻上报，以便CHF可以准备好4G网络的计费策略。切换完成后，Handover complete事件触发，同样立即报告，确认切换成功，并开始执行新的计费策略。
2. FBC 与 QBC 的核心机制
理解了触发器之后，我们再回头看5.2.1.4节（FBC）和5.2.1.6节（QBC）的描述，就会豁然开朗。
5.2.1.4 Flow Based Charging (FBC)
For FBC charging, the SMF categorizes the service data flows within PDU session data traffic by rating group and / or combination of the rating group and service id. The level of the reporting and charging method is defined per PCC rule. When a service data flow is governed by a PCC Rule indicated with “Online” charging method, quota management is required… When a service data flow is governed by a PCC Rule indicated with “Offline” charging method, quota management is not required…
深度解析：
FBC是5G计费对最终用户收费的基础。其核心逻辑可以总结为：
- 分类：SMF根据PCF下发的PCC规则，将数据包识别并归类到不同的Rating Group。
- 决策：PCC规则中会明确指出每个Rating Group应该采用“Online”还是“Offline”计费。
- 执行：
- Online：SMF必须为这个Rating Group向CHF申请和管理配额，并严格遵守“阈值到达”、“配额耗尽”等
Immediate触发器的规定。 - Offline：SMF无需申请配额，只需记录该Rating Group的使用量，在遇到其他触发器或会话结束时一并上报即可。
- Online：SMF必须为这个Rating Group向CHF申请和管理配额，并严格遵守“阈值到达”、“配额耗尽”等
The amount of data counted shall be the user plane payload at the UPF separated between UL and DL.
规范再次强调，计费的统计对象是用户面净荷（即去除了各种隧道头的数据），并且上下行必须分开统计。
5.2.1.6 QoS flow Based Charging (QBC)
QoS flow Based Charging allows the SMF to collect charging information related to data volumes per PDU session, categorized per QoS Flow for roaming charging scenarios. Quota management is not applicable for QBC.
深度解析：
QBC是专为漫游网间结算而生的机制。其核心逻辑是：
- 分类：SMF不再关心业务是什么（Rating Group），而是关心承载业务的QoS Flow的身份（通过QFI - QoS Flow Identifier来识别）。
- 决策：QBC不涉及配额管理（
Quota management is not applicable）。因为它不是为了控制用户消费，而是为了事后算账。 - 执行：SMF按每个QFI分别统计流量，并根据“漫游计费协议”（Roaming Charging Profile）中定义的QBC触发器（例如，QoS变更、PLMN变更等）来生成计费报告。这些报告（CDR）将成为运营商之间结算费用的法律依据。
FBC vs QBC 总结：
- 目的不同：FBC面向最终用户，有Online/Offline之分；QBC面向运营商结算，只有Offline模式。
- 分类依据不同：FBC依据业务（Rating Group）；QBC依据承载质量（QFI）。
- 控制逻辑不同：FBC涉及复杂的配额管理；QBC不涉及配额管理。
在一个漫游PDU会话中，FBC和QBC是同时启用、并行工作的。SMF会同时维护两套账本，一套用于对小杰收费，另一套用于和漫游地运营商算账。
文章结尾
通过对5.2.1节核心表格和FBC/QBC机制的拆解，我们已经深入到5G融合计费的“引擎室”。我们不仅了解了计费会话生命周期中的每一个关键事件，还掌握了这些事件如何被精确地分类、监控，并通过“立即”或“延迟”的机制高效地报告给计费中心。更重要的是，我们清晰地区分了面向用户的FBC和面向结算的QBC这两种核心计费范式。
这张看似复杂的触发器表，实际上是5G网络智能化和精细化运营能力的集中体现。它将网络中纷繁复杂的事件，抽象为一套标准化的、可远程配置的计费行为逻辑，为运营商实现灵活多样的商业模式奠定了坚实的技术基础。
在下一篇文章中，我们将继续沿着5.2.1节的脉络，探讨在更复杂的SSC Mode 3、多UPF场景、以及被赞助连接等特殊情况下的计费处理细节。
FAQ环节
Q1：Table 5.2.1.4-1中，“CHF allowed to change”列的“Yes”和“No”分别意味着什么？ A1：这一列定义了CHF对SMF默认行为的控制权限。“No”意味着这是强制性的核心规则，CHF无权更改。例如，“PDU会话开始/结束”必须立即报告，CHF不能让SMF延迟报告。而“Yes”意味着这是一种灵活的策略，CHF可以在计费响应消息中下发指令，改变SMF的默认行为。例如，默认情况下“QoS变更”是延迟报告，但CHF可以根据业务需求，将其改为立即报告。
Q2：SMF如何知道某个业务流应该使用在线计费还是离线计费？ A2：这个决策权在PCF（策略控制功能）。PCF会下发PCC规则给SMF，规则中会明确为每个业务流（通过Rating Group标识）指定一个“计费方法”（Charging Method），即“Online”或“Offline”。SMF只是一个执行者，它根据PCC规则的指示来决定是否需要为某个业务向CHF申请配额。
Q3：为什么像“用户位置变更”这类事件默认是“延迟报告”？这样不会导致计费不准吗？ A3：不会导致不准，反而是一种效率优化。SMF在检测到“位置变更”时，会立即结束在旧位置的统计，并开启在新位置的统计，确保了使用量按位置被精确分割。它只是将这份分割好的“旧位置”的用量报告暂存起来，而不是立刻发送。这样做的目的是为了避免在用户高速移动时（如坐高铁），因频繁的位置变更而产生大量的计费信令，造成网络拥塞。等到有更紧急的事件（如配额用尽）需要上报时，再将这些暂存的报告一并带上，从而在保证数据准确性的前提下，大大提升了信令效率。
Q4：一个PDU会话中可以同时存在在线计费和离线计费的业务吗？ A4：是的，完全可以。这就是融合计费的强大之处。例如，在一个PDU会话中，您使用运营商自有应用（如音乐App）的流量，PCC规则可能将其指定为“Offline”计费（月底统一出账）；而您同时使用第三方应用（如玩一款大型网游）的流量，PCC规则可能将其指定为“Online”计费，需要实时从您的游戏点券或账户余额中扣除。SMF能够在一个会话内同时管理这两种模式。
Q5：QBC（基于QoS流的计费）和漫游结算有什么关系？为什么它不使用配额管理？ A5：QBC是专为漫游场景下运营商之间的批发结算而设计的。运营商之间的结算是基于“我为你提供了什么质量的服务”，而不是“你的用户具体用了什么App”。因此，QBC以QoS流（QFI）为统计单位，因为它直接反映了网络承载的质量等级。它不使用配额管理，因为结算的目的是事后算账，而不是实时控制漫游用户的消费行为——那是用户归属运营商（HPLMN）通过FBC和在线计费来做的事情。VPLMN只需要准确记录并报告它提供的服务即可。