好的，我们正式开启对3GPP TS 32.255规范第5.2章的深度探索。这一章将从原则走向实践，通过具体的场景和流程，为我们揭示5G融合计费系统内部真实的消息交互和逻辑决策过程。
由于5.2.1节内容详尽，特别是涉及复杂的触发器机制，我们将遵循规范拆解规则，将其分为多篇进行解读。本文为Part 1，将重点聚焦于一个计费会话的完整生命周期管理，以及驱动这一切的核心机制——计费触发器。
深度解析 3GPP TS 32.255：5.2.1 融合计费场景基础原则 (Part 1 - 计费会话与触发器机制)
本文技术原理深度参考了3GPP TS 32.255 V18.6.0 (2024-12) Release 18规范中，关于“5.2.1 Basic principles”的核心章节，旨在为读者详细阐述5G融合计费会话的生命周期管理，以及驱动计费行为的“立即报告”与“延迟报告”触发器机制。
在前面的系列文章中，我们已经了解了5G计费需要“做什么”（原则）和它的“组织架构”（Architecture）。现在，我们将深入探讨它到底“怎么做”。我们将再次请出老朋友“小杰”，跟随他开启全新的一天，从他清晨拿起手机的那一刻起，观察一个完整的5G计费会话是如何被“开启”、“维护”和“关闭”的。
1. 计费会话的生命周期管理 (Lifecycle Management)
5.2.1.1节为我们描绘了一幅计费会话从生到死的全景图。这不仅仅是技术流程，更是运营商精细化运营的基石。
Converged charging may be performed by the SMF interacting with CHF using Nchf specified in TS 32.290 and TS 32.291. In order to provide the data required for the management activities outlined in TS 32.240 (Credit-Control, accounting, billing, statistics etc.), the SMF shall be able to perform converged charging for each of the following:
- Charging data related to PDU session;
- Charging data related to service data flows within the PDU session.
深度解析：
这段原文强调，SMF与CHF的交互是所有融合计费活动的核心。计费的粒度可以是粗犷的整个PDU会话，也可以是精细的每个业务数据流（SDF）。而管理这一切的，是一套标准化的“三部曲”式消息交互。
The SMF initiates a charging session with Charging Data Request/Response [Initial], updates the charging session with Charging Data Request/Response [Update], and terminates the charging session with Charging Data Request/Response [Termination].
这三组核心消息，定义了一个计费会话的完整生命周期。让我们通过小杰的早晨来体验这个过程。
1.1 [Initial] - “开席立账”
清晨7点，小杰的闹钟响起，他拿起手机解锁，手机屏幕点亮，自动连接上5G网络，一个PDU会话随之建立。
- SMF的动作：作为PDU会话的管理者，SMF立即承担起“账房先生”的职责。它会封装一个**
Charging Data Request [Initial]**（初始计费请求）消息，发送给CHF。 - 消息内涵：这个消息就像是在餐厅落座后，服务员为客人开的第一个账单。它包含了这次“宴席”的所有基本信息：
- 客人身份：小杰的SUPI（用户永久标识）。
- 餐桌号：本次PDU会话的Charging Identifier。
- 预点菜单（可选）：如果小杰一上来就要用需要在线计费的业务，SMF可能会在这个初始消息里就为这个业务申请初始配额。
- CHF的响应：CHF收到后，会返回一个
Charging Data Response [Initial]消息，表示“账单已开，准许上菜”。对于在线计费业务，CHF会在此消息中授予第一笔配额。
1.2 [Update] - “席间加菜与记账”
小杰在上班的地铁上，先是刷了10分钟新闻（通用流量），然后开始观看昨晚没看完的电视剧（定向流量）。
- 触发事件：在这个过程中，会发生很多“计费值得关注”的事件。例如：
- 他开始看视频，一个新的业务数据流（SDF）启动了。
- 他获得了100MB的定向视频流量配额，快用完时。
- 地铁进入了一个运营商搞活动的“免费流量”地铁站（PRA）。
- SMF的动作：每当这些事件（我们稍后称之为“触发器”）发生时，SMF就会发送一个**
Charging Data Request [Update]**（更新计费请求）消息给CHF。 - 消息内涵：这就像是席间，小杰新点了一道菜，或者服务员看到他杯里的酒快喝完了，主动过来添酒。消息里会包含：
- 已消费情况：到目前为止，通用流量用了多少，定向流量用了多少。
- 事件描述：触发这次更新的具体原因，比如“配额阈值到达”或“用户位置变更”。
- 新的请求（可选）：为视频业务再次申请100MB配额。
- CHF的响应：CHF收到后，更新内部的话单记录（CDR），并返回
Charging Data Response [Update]，授予新的配额。
1.3 [Termination] - “结账离席”
晚上回到家，小杰连接上Wi-Fi，并关闭了手机的移动数据。PDU会话随之结束。
- SMF的动作：SMF检测到PDU会话释放，它会执行最后一次计费动作——发送**
Charging Data Request [Termination]**（终止计费请求）。 - 消息内涵：这相当于小杰用餐完毕，喊服务员“买单”。这个消息包含了本次会话从开始到结束的所有最终消费统计。
- CHF的响应：CHF收到后，将最后的这点使用量追加到话单（CDR）中，然后彻底关闭这份话单，存档待查。它会返回
Charging Data Response [Termination]，确认“账已结清，会话结束”。
1.4 特殊机制：会话“休眠”与唤醒
In order to avoid a charging session remaining inactive for a long period of time, upon expiry of the Unit Count Inactivity Timer, the charging session may be terminated by the SMF sending Charging Data Request [Termination], indicating the PDU session shall continue and the CHF can expect a later Charging Data Request [Initial] request for the same PDU session with the original Charging Identifier and new session identifier.
深度解析：
这是一个非常重要的网络优化机制。想象一下，小杰打开手机后，PDU会话建立了，但他在接下来的几个小时里一直没用手机上网，没有任何数据流量。
- 资源占用：虽然没有流量，但这个活跃的计费会话在SMF和CHF中都占用了宝贵的内存和计算资源。
- “休眠”操作：为了避免资源浪费，SMF内部有一个“单位计数非活跃计时器”（Unit Count Inactivity Timer）。如果这个计时器超时（比如，2小时内没有任何计费相关的流量或事件），SMF就会主动发送一个
Termination消息给CHF，先关闭当前的计费会话，释放CHF侧的资源。 - “唤醒”操作：但请注意，此时PDU会话本身并未中断。当几个小时后，小杰再次点开App时，SMF会立刻为这个“还在继续”的PDU会话，重新发起一次
Initial请求，开启一个新的计费会话。为了保证关联性，这个新的请求会携带与旧会话相同的Charging Identifier。
这个机制就像酒店的“夜审”，在客人还在住店但深夜没有活动时，先把当天的账结了，第二天再开新的账单，既保证了账目清晰，又优化了系统资源。
2. 计费的“遥控开关”——触发器机制 (Trigger Mechanism)
是什么决定了SMF何时应该发送Update消息？答案就是本节的核心——触发器（Triggers），也称为可计费事件（chargeable events）。
The Charging Data Request is issued by the SMF towards the CHF when certain conditions (chargeable events) are met.
CHF就像一个拿着遥控器的人，它通过在Charging Data Response消息中下发一系列“触发器”，来精确遥控SMF的计费上报行为。规范将这些触发器分为两大类。
2.1 立即报告 (Immediate Report) - “十万火急，立刻汇报！”
immediate report: chargeable events for which, when occurring, the current counts are closed and sent together with the charging data generated by the SMF towards the CHF in a Charging Data Request. New counts are started by the SMF.
深度解析：
这类触发器对应的是对计费决策有即时影响的关键事件。一旦发生，SMF必须“放下手中一切活计”，立刻打包当前所有业务的已使用量，发送一个Update消息给CHF。
场景举例：
小杰的50GB通用流量套餐只剩下最后1MB了。CHF在上次给SMF授权配额时，就下发了一个“配额阈值到达”的immediate report触发器。
- 事件发生：小杰随手刷新了一下网页，消耗了0.2MB流量，剩余配额低于了设定的阈值。
- SMF立即行动：SMF检测到该事件，立即执行：
- 关闭当前计数：记录下从上次报告到现在，通用流量、视频流量等各自又用了多少。
- 打包发送：生成一个
Update请求，包含这些最新的使用量，并明确告知CHF触发原因是“配额阈值到达”。 - 开启新的计数：从零开始新的统计周期。
- CHF决策：CHF收到后，发现小杰的套餐即将用尽，可能会做出决策，比如通过PCF降低小杰的网速，或者向他发送一条提醒短信。
典型的立即报告触发器还包括：QoS发生重大变化（比如从高清视频切换到普通浏览）、用户进入或离开特定计费区域（PRA）、PDU会话终止等。
2.2 延迟报告 (Deferred Report) - “事情记下了，回头一起说”
deferred report: chargeable events for which, when occurring, the current counts are closed and stored together with the charging data generated by the SMF. The stored counts will be sent to the CHF in next a Charging Data Request. New counts are started by the SMF.
深度解析：
这类触发器对应的事件虽然也需要记录，但它们本身并不紧急，不需要立即中断计费流程去上报。SMF在检测到这类事件后，会先把当前的统计数据“暂存”起来，然后开启新的统计，等待下一次“真正”需要上报的时候（比如遇到一个立即报告事件，或者会话结束），再把所有暂存的数据一并打包发送。
场景举例：
CHF可能对“服务节点变更”（比如小杰的手机从一个基站切换到另一个基站）配置了deferred report触发器。
- 事件发生：小杰的地铁经过了一站，手机无感地切换到了下一个基站。
- SMF“默默记下”：SMF检测到服务节点变更，它会：
- 关闭并暂存：记录下在旧基站下使用了多少流量，并将这份“小账单”存放在本地缓存里。
- 开启新计数：在新基站下从零开始统计。
- 保持沉默：不向CHF发送任何消息。
- 合并上报：几分钟后，小杰的视频流量配额用尽（一个
immediate report事件），SMF需要向CHF发送Update请求。此时，它会把刚才因基站切换而暂存的那份“小账单”和当前最新的使用量数据，一起打包发送给CHF。
这么做的好处：极大地减少了网络中的信令交互次数。如果每次基站切换都立即上报，对于高速移动的用户来说，将会产生海量的计费信令风暴。延迟报告机制，在保证数据不丢失的前提下，实现了信令效率的最大化。
3. 触发器的分层管理艺术 (Hierarchical Trigger Management)
为了实现更精细化的控制，CHF下发的触发器还可以在不同的层级上生效。
Flow Based Charging (FBC) triggers Two level of triggers can be supplied by the CHF:
- Triggers associated to the PDU session.
- Triggers associated to a rating group within the PDU session.
QoS flow Based Charging (QBC) triggers Two level of triggers can be supplied by the CHF:
- Triggers associated to the PDU session.
- Triggers associated to a QoS Flow within the PDU session.
深度解析：
CHF对SMF的“遥控”是立体式的，分为宏观和微观两个层面。
-
PDU会话级触发器（宏观调控）：这类触发器作用于整个PDU会话。例如，“用户位置进入漫游区域”、“整个PDU会话的总时长超过24小时”、“PDU会话的承载网络从5G切换到4G”。这些事件影响的是整个会话的基本属性，因此触发的是全局性的计费动作。
-
业务/QoS级触发器（微观管理）：这类触发器仅作用于特定的业务流或QoS流。
- FBC下的Rating Group级触发器：小杰的通用流量（Rating Group 1）配额用尽，只会触发针对这个Rating Group的计费上报和配额再申请，完全不影响他正在使用的、配额还很充足的视频定向流量（Rating Group 2）的计费周期。
- QBC下的QoS Flow级触发器：在漫游结算场景中，运营商间的协议可能是按QoS流等级定价。当小杰的VoNR通话（一个高优先级的QoS流）结束时，可能会触发一个QoS Flow级的报告，而他同时在进行的网页浏览（另一个低优先级的QoS流）则不受影响。
这种分层管理的能力，使得5G计费系统既能“高瞻远瞩”地把握会话全局，又能“明察秋毫”地对每个细分业务进行独立、无干扰的精细化管理。
文章结尾
通过对5.2.1节前半部分的解读，我们已经掌握了5G融合计费场景的运作核心：一个由**“Initial-Update-Termination”三部曲构成的清晰的会话生命周期，以及一套由CHF远程遥控、分为“立即/延迟”两种模式、并作用于“会话/业务”**两个层级的精密的触发器机制。
这套机制是后续所有复杂计费流程的基础。在下一篇文章中，我们将“撸起袖子”，深入到规范中最令人“望而生畏”但也最有价值的部分——那张庞大的默认触发器条件表（Table 5.2.1.4.1），逐一分析在PDU会话建立、修改、切换、终止的各个阶段，究竟是哪些具体的网络事件在幕后驱动着计费的齿轮。敬请期待！
FAQ环节
Q1：什么是计费会话的“三部曲”？ A1：计费会话的“三部曲”是指管理其生命周期的三种核心消息交互：1) [Initial]（初始请求/响应），在PDU会话建立时，由SMF发起，用于在CHF侧“开户立账”；2) [Update]（更新请求/响应），在会话持续期间，由SMF根据CHF下发的触发器在特定事件发生时发起，用于报告使用量、申请新配额等；3) [Termination]（终止请求/响应），在PDU会话结束时，由SMF发起，用于做最后的用量结算并关闭话单。
Q2：“立即报告”和“延迟报告”触发器的主要区别和设计目的是什么？ A2：主要区别在于报告的实时性。立即报告在事件发生时会立刻触发SMF向CHF发送消息，因为它通常关联到需要CHF立即做决策的紧急事件（如配额用尽、SLA可能违约）。延迟报告在事件发生时，SMF仅在本地记录，等到下一次有立即报告事件或会话结束时才“顺便”上报，它的主要设计目的是为了大幅减少因频繁但不紧急的事件（如基站切换）而产生的信令开销，提升网络效率。
Q3：CHF是如何“遥控”SMF的计费行为的？
A3：CHF通过在给SMF的Charging Data Response消息中携带一个“触发器列表”来实现遥控。这个列表明确告诉了SMF需要监控哪些网络事件（如QoS变更、位置变更、配额阈值等），以及每个事件对应的报告模式是“立即”还是“延迟”，作用层级是“整个PDU会话”还是“某个特定的Rating Group”。SMF就像一个忠实的执行者，完全按照这份“指令清单”来工作。
Q4：为什么需要区分PDU会话级和Rating Group级的触发器？ A4：为了实现精细化和差异化的业务管理。PDU会话级触发器处理的是影响整个连接的宏观事件，如用户漫游了，整个计费策略可能都需要调整。而Rating Group级触发器处理的是某个具体业务的微观事件，如您的视频定向流量包用完了，网络只需要针对视频业务进行处理（如限速或转为通用流量计费），而不应该影响您同时在使用的、计费策略完全不同的其他应用（如微信）。这种分层管理保证了业务间的隔离和计费的精确。
Q5：如果我的手机长时间没上网，计费会话会一直存在吗？ A5：不一定。为了节省网络资源，SMF有一个“单位计数非活跃计时器”（Unit Count Inactivity Timer）。如果您的PDU会话在一段时间内（例如2小时）没有任何数据流量或计费相关事件，SMF可能会主动终止当前的计费会话以释放CHF侧的资源。但这并不会断开您的网络连接。当您再次使用数据时，SMF会为同一個PDU会话重新发起一个新的计费会话，保证服务的连续性。