深度解析 3GPP TS 32.240：5.1 Charging data generation and quota supervision (计费数据生成与配额监督)
本文技术原理深度参考了3GPP TS 32.240 V18.9.0 (2024-12) Release 18规范中，关于“5.1 Charging data generation and quota supervision”的核心章节，旨在为读者提供一个关于5G系统中最基础、最核心的计费信息是如何产生并受到实时监控的全景视图。
在移动通信的世界里，每一次通话、每一次上网、每一条消息，背后都有一套极其精密和复杂的计费系统在默默工作。这套系统的稳定与否，直接关系到运营商的收入和用户的体验。而这一切的起点，都源于最基础的环节——计费数据的生成与配额的监督。
今天，我们将化繁为简，跟随一位名叫小美（一位热爱探索5G新科技的数码爱好者）的虚拟主角，在她一天的生活中，揭开3GPP计费体系的神秘面纱，看看网络是如何精准捕捉她的每一次网络行为，并进行计费处理的。
1. 计费的起点：CTF的无处不在
要理解计费，首先要认识一个关键的角色——CTF（Charging Trigger Function，计费触发功能）。它就像网络世界中无处不在的“传感器”和“记录员”。
规范原文 5.1： The CTF embedded in all charging relevant network elements/network functions collects charging information within the NE/NF concerning the use of network resources by the mobile end users. These network resources may pertain to bearer (e.g. CS, PS), PDU session (e.g. 5GS), subsystem (e.g. IMS sessions) or service (e.g. MMS) usage / consumption.
这段话的核心思想是，CTF并非一个独立的物理设备，而是被“嵌入”到几乎所有与计费相关的网络功能（NF）或网络元素（NE）中的一种逻辑功能。无论是处理数据连接的SMF（会话管理功能）、处理移动性管理的AMF（接入和移动性管理功能），还是处理短信的SMSF（短信功能），内部都潜藏着一个CTF。
场景解读：
小美的一天开始了。清晨，她用手机制作了一张精美的早安彩信（MMS），发送给了家人。当她点击“发送”的那一刻，这个看似简单的动作，立即触发了她手机归属网络中MMSF（彩信功能）内部的CTF。
这个CTF就像一个尽职的管家，立刻开始记录：“用户小美，在某年某月某日某时某分，使用彩信业务，彩信大小为XX KB，发送对象是号码YYYY”。它收集的这些原始信息，就是所有计费流程的数据源头。
这些信息覆盖了从传统的电路域（CS）、分组域（PS），到5G核心网的PDU会话，再到IMS子系统以及具体的MMS等各种业务。可以说，只要用户在网络中产生了可能需要付费的行为，就一定有某个CTF在背后默默观察和记录。
2. 两种命运：离线计费与在线计费
CTF收集到的原始信息，接下来会走向两条截然不同的处理路径：离线计费（Offline Charging）和在线计费（Online Charging）。这两种方式决定了用户是“先消费，后付款”还是“先付款，后消费”。
2.1 离线计费：秋后算账的后付费模式
离线计费是为后付费用户（例如，每月收到账单再缴费的用户）设计的。它的核心特点是，计费过程不影响用户正在进行的服务。
规范原文 5.1： The purpose of offline charging is to transform the charging information into CDRs that are post-processed within the BD, e.g. for the purpose of generating bills. While the collection of charging information used for the CDRs occurs during the network resource usage, there is no impact of offline charging on the use of the resources.
这里的关键点是“no impact”——没有影响。网络只是默默地把用户的消费行为记录下来，生成一份详细的“消费清单”，也就是CDR（Charging Data Record，计费数据记录）。这份清单随后被送到运营商的计费域（BD, Billing Domain）进行后续处理，比如合并计算、打折优惠，最终生成用户下个月的话费账单。
场景解读：
假设小美是一位后付费用户。她发送彩信的行为被MMSF中的CTF捕捉后，CTF会生成一个“计费事件”，并将其发送给离线计费系统中的CDF（Charging Data Function，计费数据功能）。CDF收到这个事件后，会生成一条关于这条彩信的CDR。
整个过程中，小美的彩信发送完全不受影响，无论网络后台在做什么，她的彩信都会被正常发送出去。她只需要在下个月收到账单时，为这条彩信付费即可。这就是典型的“先斩后奏”模式。
2.2 在线计费：实时控制的预付费模式
在线计费则完全相反，它主要服务于预付费用户（例如，需要先充值话费才能使用的用户）。它的核心是实时信控（Credit-Control），即在用户使用资源 之前，必须先向计费系统“申请授权”。
规范原文 5.1： The purpose of online charging is to furnish charging information to the OCS/CCS in order to perform Credit-Control before the network resource usage is permitted. To this end, a prepaid subscriber account has to exist in the OCS/CCS, against which the resource usage can be billed.
这里的关键词是“before… permitted”——在被允许之前。用户的每一次消费请求，网络都必须先去在线计费系统（OCS, Online Charging System）或融合计费系统（CCS, Converged Charging System）查询该用户的账户余额是否充足。只有得到OCS/CCS的“许可”，业务才能继续。
场景解读：
现在，我们假设小美是一位预付费用户，她的账户里有50元余额。她要发送的彩信，根据资费标准需要0.5元。
- MMSF中的CTF捕捉到她的发送请求。
- CTF立即暂停发送动作，并将一个“计费事件”（包含业务类型、预计费用等信息）发送给OCS。
- OCS收到请求，查询小美的账户，发现有50元余额，足够支付。
- OCS从她的账户中扣除0.5元（或预留0.5元），然后向MMSF返回一个“授权”消息。
- MMSF收到授权后，才正式将彩信发送出去。
如果此时小美的余额只有0.1元，OCS就会返回一个“拒绝”消息，MMSF则会中止发送，小美的手机上可能会收到一条发送失败的提示。这就是在线计费的实时控制能力。
3. 在线计费的两种核心机制：直接计费 vs. 单元预留
在线计费根据业务的特点，又分为两种更精细的控制方式：直接计费（Direct Debiting）和单元预留（Unit Reservation）。
3.1 直接计费 (Direct Debiting)
这种方式适用于那些一次性、资源消耗量在发起时就已知的业务。
规范原文 5.1： Direct Debiting: the requested resource can be determined and billed in a one-off procedure. In that case, the resource usage is debited from the subscriber account immediately when processing the charging event, and the permission for the resource usage is returned to the network.
可以简单理解为“一口价”业务。业务请求发生时，费用是固定的、已知的。计费系统可以直接从用户账户里扣除这笔钱，然后授权业务执行。
场景解读：
中午休息时，小美在公司楼下的自动售货机买了一瓶饮料，她选择了运营商提供的“话费支付”功能。售货机通过网络向运营商发起了一个支付请求，比如“为用户小美支付5元”。
这个请求被网络捕获后，CTF将其打包成一个计费事件发给OCS。OCS一看，这是一个金额固定的交易（5元），于是直接检查小美余额是否大于5元。如果够，就立即扣除5元，并向网络返回授权。网络再通知售货机，支付成功，饮料掉落。
这个过程就是一次典型的直接计费。彩信发送、短信发送、应用内购买固定价格的道具等，都属于此范畴。
3.2 单元预留 (Unit Reservation)
这种方式是为那些持续时间长、资源消耗量不确定的“会话类”业务量身定做的，比如上网、通话、看视频等。
规范原文 5.1： Unit Reservation: the OCS/CCS cannot a priori know the amount of resources that the end user may eventually consume… In this case, a certain amount of (monetary or non-monetary) units is blocked, or reserved, on the subscriber’s account on the OCS/CCS, and permission to use an amount of resources that matches the unit reservation is returned to the network.
由于网络无法预知小美这次上网会用掉多少流量，或者这通电话会打多久，所以不可能一次性扣费。于是，聪明的计费系统采用了“单元预留”的策略，可以通俗地理解为“批次授权，用完再续”。
场景解读：
下班路上，小美在地铁里开始观看一场高清体育赛事直播。这对预付费的她来说，是一次典型的会话类业务。
-
会话开始 - 首次申请配额： 当她点开直播APP，手机向网络（具体由SMF中的CTF负责）发起了数据连接请求。CTF立刻向OCS发起了一个在线计费会话的建立请求。 OCS收到请求，它不知道小美要看多久，于是根据运营商的策略（比如，先批100MB流量或者等值的5元钱），在小美的50元余额中“冻结”了5元，这笔钱暂时不能用于其他业务。 然后，OCS向SMF返回一个授权消息，内容是：“已授权，配额为100MB”。
-
会话进行中 - 配额监督与再次申请： SMF收到了100MB的配额，于是允许小美的直播视频流通过。同时，SMF内部的CTF开始像一个精准的流量计，实时监控小美消耗的流量。 时间流逝，直播很精彩，小美消耗的流量很快达到了90MB（通常会有一个阈值，如90%）。CTF监测到后，立即向OCS发送“中间计费请求”，报告：“上次的100MB快用完了，请求新的配额”。 OCS收到请求，检查小美剩余的45元余额，再次批复了100MB（冻结第二个5元），并将新配额下发给SMF。SMF收到新配额后，小美的直播得以无缝继续。这个“申请-下发-监控”的过程会循环往复。
-
会话结束 - 最终结算： 地铁到站，小美关闭了直播APP，手机发起了连接释放流程。SMF中的CTF检测到会话结束，它会立即向OCS发送一个“最终计费请求”。 这个请求中包含了本次会话的总计费信息，比如：“会话结束。在最后一个配额（100MB）中，实际使用了30MB”。 OCS收到这个最终报告后，进行结算。它会从最后冻结的5元中，按30MB的实际用量扣费（假设是1.5元），并将剩余未使用的70MB对应的金额（3.5元）“解冻”，返还到小美的账户可用余额中。至此，整个在线计费会话完美闭环。
通过这种精巧的单元预留机制，运营商既保证了预付费用户不会透支消费，又提供了流畅不中断的业务体验。
4. 事件驱动 VS 会话驱动：计费的两种基本模型
从上面的场景中，我们可以总结出计费的两种基本模型：事件计费和会话计费。
4.1 事件计费 (Event based charging)
它处理的是孤立的、一次性的用户行为。
规范原文 5.1： Event based charging. The (chargeable) event is recognised in the NE /NF that handles it, based on e.g. signalling exchange between the user equipment and the NE/NF. The event is then mapped onto a single charging event…
- 在线模式 (Online Charging): 通常采用直接计费（IEC - Immediate Event Charging）或带有单元预留的事件计费（ECUR - Event Charging with Unit Reservation）。例如，发送一条短信是IEC；购买一个游戏道具，系统可能会预留费用，确认成功后再扣款，这就是ECUR。
- 离线模式 (Offline Charging): CTF将事件报告给CDF，CDF生成一条独立的CDR。一个事件对应一条CDR。
小美发送彩信、话费买饮料，都属于事件计费的范畴。
4.2 会话计费 (Session based charging)
它处理的是具有明确开始、持续和结束状态的连续性用户行为。
规范原文 5.1： Session based charging. The start of the user session is recognised by the NE/NF that handles the session… This chargeable event is then mapped onto a charging event as specified in the middle tier TS that applies to that NE/NF.
- 在线模式 (Online Charging): 必须使用带有单元预留的会话计费（SCUR - Session based Charging with Unit Reservation）。网络与OCS之间会建立一个持续的信控会话，包含至少一次“initial”请求、零次或多次“interim”请求，以及一次“final”请求。
- 离线模式 (Offline Charging): 一个用户会话会触发CTF生成多个计费事件（开始、中间更新、结束等）。CDF会将这些事件关联起来，生成一张或多张“部分CDR”（Partial CDR）。例如，一个长达2小时的上网会话，可能会被切分成多个15分钟的CDR，以确保计费信息能及时处理，防止数据丢失。
小美观看体育直播，就是一次典型的会话计费。
5. 总结
通过跟随小美一天的数字生活，我们深入剖析了3GPP计费体系中最基础也最关键的一环——5.1 计费数据生成与配额监督。
- 一切始于嵌入在各个网络功能中的CTF，它负责捕捉用户的每一个“可计费事件”。
- 根据用户的付费类型，数据会流向离线计费（生成CDR，用于事后出账）或在线计费（与OCS/CCS实时交互，进行信控）。
- 在线计费又根据业务特性，采用直接计费（用于“一口价”业务）或单元预留（用于流量、时长等“会话类”业务）的精细化控制手段。
- 无论是离线还是在线，计费模型都可以归为事件计费和会话计费两大类，分别对应一次性操作和持续性会话。
理解了这些基本原理，就等于拿到了解读后续更复杂的计费策略、计费关联、漫游计费等高级主题的钥匙。在接下来的文章中，我们将继续沿着规范的脉络，探索5G计费世界更深层次的奥秘。
FAQ 环节
Q1：什么是“可计费事件 (Chargeable Event)”和“计费事件 (Charging Event)”？它们有何区别？ A1：这是一个非常好的问题，两者概念很接近但有区别。“可计费事件”是指在网络中发生的、可能需要收费的用户或系统行为的原始事实，例如“用户发起了一次通话”。而“计费事件”是CTF将可计费事件进行处理和格式化后，用于在计费系统各组件之间（如CTF到CDF/OCF）传递的消息。可以理解为，“可计费事件”是“原材料”，而“计费事件”是经过初步加工的“半成品”，包含了标准的参数和格式，便于后续处理。
Q2：对于在线计费中的“单元预留”，运营商如何决定每次给用户分配多少配额？ A2：配额的大小是由运营商在OCS/CCS系统中配置的策略决定的，没有统一的硬性标准。运营商会综合考虑多种因素来优化这个策略：
- 用户业务类型： 观看高清视频和浏览网页的配额大小可能不同。
- 网络信令负荷： 配额太小会导致频繁的“中间计费请求”，增加网络信令开销；配额太大则可能“冻结”用户过多余额，影响其使用其他并行业务（如边看视频边接电话）。
- 用户价值等级： 高价值用户的初始配额可能会更大。
- 实时网络状况： 在网络拥塞时，可能会动态调整配额策略。 这是一个在用户体验和网络效率之间寻求平衡的动态优化过程。
Q3：一个用户的同一个网络行为，能否同时触发离线计费和在线计费？ A3：完全可以，并且这种情况很常见。规范中明确提到 “Note also that online and offline charging may occur simultaneously”。例如，一个预付费用户在使用数据业务时，网络会通过在线计费（单元预留）来实时控制他的流量使用，确保他不透支。同时，网络也可以为这次数据会话生成详细的CDR，通过离线计费流程送往后台系统。这样做的好处是，运营商不仅能通过CDR进行大数据分析、用户行为建模、网络流量统计等，还能在需要时为预付费用户提供详单查询服务。
Q4：在小美观看直播的例子中，如果她的手机在会话中途突然断电关机，计费会如何处理？ A4：这是一个典型的异常场景处理。手机突然断电，网络侧（如SMF）会因为心跳超时等机制，检测到PDU会话的异常中断。此时，SMF中的CTF会生成一个包含“异常终止原因”的“最终计费请求”发送给OCS。OCS收到后，会根据已用流量（例如，SMF报告在断电前已使用了多少MB）进行结算，并将预留但未使用的配额所对应的金额返还给用户账户。这样能确保即使用户异常掉线，也只按实际使用量扣费，保证了计费的公平性。
Q5：直接计费（Direct Debiting）和带单元预留的事件计费（ECUR）有什么核心区别？ A5：两者都用于事件型业务，但核心区别在于扣款和业务执行的“原子性”。
- 直接计费(IEC/Direct Debiting): 扣款和授权是一步完成的。OCS直接扣费，然后返回“许可”。网络收到许可后才执行业务。如果后续业务执行失败（比如短信发送失败），可能需要一个“冲正”或“退款”的流程，这在某些场景下会增加系统复杂性。
- 带单元预留的事件计费(ECUR): 分为两步。第一步，OCS先“预留/冻结”费用，然后返回授权；第二步，网络执行业务后，将执行结果（成功或失败）报告给OCS。OCS根据结果决定是“确认扣款”（从预留金额中）还是“取消预留”（返还金额）。ECUR流程更严谨，能更好地处理业务执行失败的情况，避免了复杂的退款逻辑。选择哪种方式取决于业务的重要性和对失败场景处理的严格程度。