51学通信

深度解析 3GPP TS 32.290：5.2 Online charging scenario (在线计费场景)

25分钟阅读

好的，我们无缝衔接上一篇的内容，继续深入探索3GPP计費规范的另一半江山——在线计费。

深度解析 3GPP TS 32.290：5.2 Online charging scenario (在线计费场景)

本文技术原理深度参考了3GPP TS 32.290 V18.9.0 (2025-03) Release 18规范中，关于“5.2 Online charging scenario”的核心章节，旨在为读者提供一个关于5G在线计费全景视图。

在上一篇文章中，我们跟随物流无人机“迅翼-007”体验了5G离线计费的“先消费，后记账”模式。那种模式建立在信任和批处理的基础上，非常适合企业和后付费用户。然而，对于广大的预付费用户以及需要进行严格成本控制的业务，我们需要一种更为精密的实时交互机制。这就是我们今天要探讨的主角——在线计费（Online Charging）。

为了让这个过程更加贴近生活，我们请出今天的主角——“美美”。她是一位时尚的都市白领，也是一位精打细算的5G预付费套餐用户。她的手机账户余额决定了她能享受多长时间的5G冲浪乐趣。今天，我们将跟随美美一天的数字生活，来揭示5G在线计费系统是如何像一位“贴身管家”一样，实时管理她的每一分钱和每一MB流量的。

1. 在线计费：实时信控的“先授权，后使用”

在线计费，又常被称为信用控制（Credit Control），其核心思想与离线计费截然相反。它要求在服务交付的之前或之中，网络必须与计费系统进行实时交互，以获取使用资源的授权。如果授权失败（例如，余额不足），服务将被拒绝或中止。

这种模式就像使用预付卡购物，每一笔消费都必须先确认卡内有足够的余额，否则交易就会失败。在5G网络中，这意味着美美想看的每一个高清视频、想玩的每一局云游戏，都必须先得到计费系统的“点头许可”。

1.1 基本原则 (Basic Principles)

和离线计费一样，规范首先将我们引向了那个纲领性的文件。

5.2.1 Basic principles Basic principles for online charging are defined in TS 32.240.

TS 32.240为在线计费定义了几个关键原则：

  • 实时授权：任何需要在线计费的业务，在启动前都必须向计费系统（在传统架构中称为OCS - Online Charging System）请求授权。
  • 配额管理 (Quota Management)：计费系统不会一次性授权无限量的资源。相反，它会根据用户余额、套餐情况等，批复一个固定数量的资源“配额”（Quota），例如100MB流量或10分钟通话时长。
  • 单元预留 (Unit Reservation)：在授予配额时，计費系统会从用户的账户中“预留”或“冻结”与该配额等值的金额，确保这笔钱不会被其他业务同时使用。
  • 再授权 (Re-authorization)：当用户使用的资源即将耗尽已授予的配额时，网络中的CTF（计费触发功能）必须在配额用完之前，主动向计费系统发起新的配额请求。这个过程会循环进行，保证业务的连续性。
  • 最终上报与终止：业务结束后，CTF会上报本次配额中实际使用的资源量。计费系统根据上报的实际用量，从预留的金额中进行扣费，并将剩余未使用的预留金额“解冻”，返还到用户账户。

现在，让我们看看这些原则如何在美美的5G生活中具体体现。

场景设定：美美的5G手机里有100元的预付余额。她手机上网产生的数据流量，都受到运营商核心网中的**CHF（Charging Function）的实时监控。在这里，CHF扮演了传统OCS的角色，与作为CTF的SMF（Session Management Function）**进行着毫秒级的紧密协作。

2. 在线计费的三大核心场景

规范为我们描绘了在线计费纷繁复杂的世界，并将其归纳为几种典型的场景。

5.2.2.1 Introduction The following basic scenarios are used: 1 Immediate Event Charging … 2 Event charging with Unit Reservation … 3 Session charging with Unit Reservation …

这三种场景——立即事件计费（IEC）、带单元预留的事件计费 和 带单元预留的会话计费——覆盖了从一次性购买到持续性数据业务的各种情况。同时，规范还引入了两个正交的概念维度，使得场景的组合更加丰富：

  • 单元确定 (Unit Determination)：决定本次服务需要多少“单元”（如时长、次数、流量）的过程。可以是分散式的（由CTF，如SMF决定）或集中式的（由CHF决定）。
  • 计费费率 (Rating)：为这些“单元”定价的过程。同样，可以是分散式的（CTF本地有费率表）或集中式的（由CHF统一定价）。

规范特别指出，“集中式单元确定”和“分散式计费费率”的组合是不可能的。这很好理解：如果连服务需要多少单元都得去问CHF（集中式），那么CTF本地自然也就不可能知道该如何为这个未知的服务量来定价了（分散式）。

现在，让我们跟随美美一天的活动，来逐一拆解这些场景。

2.1 场景一：立即事件计费 (Immediate Event Charging, IEC)

任务背景：上午10点，美美在地铁上，看到一个应用商店的推广，提供一款“AI壁纸生成”工具的24小时VIP体验资格，价格为5元。她决定购买。这是一个典型的一次性、即时生效的事件。

这种场景通常采用分散式单元确定和集中式计费费率。也就是说，CTF（此处可能是应用处理相关的某个NF）明确知道这次请求是“购买一个24小时VIP体验”（单元确定），但具体需要扣多少钱，以及美美的账户是否有足够余额，则需要去问CHF（集中式费率和账户管理）。

尽管TS 32.290没有像离线计费那样为IEC提供单独的流程图，但其逻辑与离线事件计费（PEC）的图非常相似，关键区别在于计费交互发生在服务交付之前。我们可以将其流程理解为：

  1. 服务请求：美美点击“购买”按钮。CTF收到请求。
  2. 计费数据请求[事件]：与PEC不同，CTF在交付服务前，立即向CHF发送计费请求，请求扣费5元。
  3. 账户与计费控制：CHF收到请求，检查美美的账户余额（100元）。余额充足，于是执行扣款，余额变为95元。
  4. 计费数据响应[事件]：CHF向CTF返回成功响应，告知“扣款成功，可以交付服务”。
  5. 服务交付：CTF收到成功响应后，为美美的账号激活“AI壁纸生成”工具的24小时VIP权限。

整个过程确保了只有在成功付费后，服务才会被授予，完美体现了在线计费的预付费控制核心。

2.2 场景二：带单元预留的事件计费 (Event charging with Unit Reservation)

这个场景比IEC稍微复杂一点，它适用于那些需要先确保资源可用，然后再完成业务的事件。例如，发送一条高价值的商业彩信，系统需要先预留费用，在确认彩信成功发送后再进行实际扣费。

2.3 场景三：带单元预留的会话计费 (Session charging with Unit Reservation)

任务背景：下午茶时间，美美决定放松一下，打开视频App观看一部超高清电影。这是一个持续消耗数据流量的会话类业务，也是在线计费最复杂、最核心的应用场景。

这个过程完美地诠释了TS 32.240中定义的在线计费所有原则。我们来详细拆解这个信令交互的“舞蹈”。

阶段一：会话建立与首次配额申请

  1. 服务请求：美美点击电影播放键。她的手机请求建立一个用于视频流的PDU会话。请求到达SMF（CTF）。SMF识别出这是一个需要在线计费的业务。

  2. 计费数据请求[初始]：SMF并不知道美美的账户情况，于是它先向CHF发起一个首次计费数据请求（Charging Data Request [Initial]）。这个请求中，SMF会向CHF申请一个初始配额，比如，它可能会说：“这个用户要看视频了，请先给我批100MB的流量配额（Requested Unit）”。这属于分散式单元确定。

  3. 账户、计费与预留控制：CHF收到请求后，开始繁忙地工作：

    • 检查余额：查看美美的账户，余额100元，充足。
    • 计费定价：根据美美的套餐，计算出100MB流量需要花费的金额，比如是2元（集中式计费费率）。
    • 资金预留：在美美的账户中，将这2元钱的状态变为“预留”，此时她的可用余额暂时减少了2元，以防这笔钱被其他并发业务（如后台应用更新）占用。
    • 授予配额：决定批复这个请求。

  4. 计费数据响应[初始]：CHF向SMF返回一个计费响应（Charging Data Response [Initial]）。这个响应消息是授权的核心，它会告诉SMF：“授权请求通过，现授予你100MB流量配额（Granted Unit）。当配额使用到80%（即80MB）时，请立即向我申请下一次配额。” 这个80%就是所谓的门限（Threshold）。

阶段二：会话进行与配额的循环申请（再授权）

  1. 服务交付与用量监控：SMF收到了“尚方宝剑”（100MB配额），于是允许PDU会话传输数据。电影开始缓冲并流畅播放。同时，SMF内部的“计数器”开始严密监控美美消耗的下行流量。

  2. 触发再授权：电影播放了几分钟后，SMF的计数器显示已用流量达到了80MB，这精准地命中了CHF下发的门限。再授权的时刻到了！

  3. 计费数据请求[更新]：SMF在100MB配额用完之前，立刻向CHF发起下一次计费数据请求（Charging Data Request [Update]）。在这个请求中，SMF会同时做两件事：

    • 上报用量：报告上一个配额中实际已经使用的80MB流量（Used Unit）。
    • 申请新配额：再次请求新的100MB流量配额（Requested Unit）。

  4. 账户更新与新配额授予：CHF收到更新请求后，再次执行一系列操作：

    • 结算上次用量：根据上报的80MB用量，CHF从之前预留的2元钱中，实际扣除对应的费用（例如1.6元），并将剩余的0.4元预留金“解冻”，返还到美美的可用余额中。
    • 处理新请求：重复阶段一的第3步，检查余额、计算新100MB配额的费用、预留资金。
    • 授予新配額：向SMF返回带有新的100MB配额和新门限的响应消息。

这个“监控 -> 到达门限 -> 上报用量并申请新配额 -> 结算旧配额并授予新配额”的循环会一直持续下去，只要美美的电影不停止，并且她的账户余额充足。这保证了她的观影体验无缝衔接，不会因为计费交互而发生卡顿。

阶段三：会话终止与最终结算

  1. 服务释放：电影结束，美美关闭了视频App。手机请求释放PDU会话。

  2. 计费数据请求[终止]：在释放会话时，SMF会进行最后一次“盘点”。假设在最后一个100MB的配额中，美美只用了40MB。SMF会向CHF发起最后一次计费数据请求（Charging Data Request [Termination]），其中包含了这最后的40MB用量。

  3. 最终结算：CHF收到终止请求后，执行最后一次结算。它根据上报的40MB用量，从为这100MB预留的2元钱中，扣除实际费用（例如0.8元），并将剩余的1.2元全部“解冻”，返还到美美的账户。

  4. 关闭计费会话：CHF关闭与该PDU会话关联的所有计费上下文，并向SMF返回最终响应。整个在线计费会话至此干净利落地结束。

关于5.2.2.2 Scenarios的说明 值得注意的是，规范中5.2.2.2这一节非常简短。

5.2.2.2 Scenarios The scenarios described in TS 32.299, clauses 5.2.2.1, 5.2.2.2 and 5.2.2.3, apply with the CHF acting as an OCF.

这是一个典型的引用说明。TS 32.299是早期基于Diameter协议的计费规范，而我们当前解读的TS 32.290是基于服务化接口（SBI）的。这句话的含义是，尽管底层通信协议和接口变了（从Diameter变成了HTTP/JSON），但在线计费的核心逻辑场景和交互模型（如IEC、带预留的会话计费等）是被继承和沿用的。在5G SBA架构中，CHF承担了原来OCS/OCF（Online Charging Function）的角色，继续执行这些经典的计费流程。

3. 总结与展望

通过跟随美美一天的5G生活，我们深入了解了在线计费的精髓。与离线计费相比，在线计费是一个高度动态、实时的交互过程。它通过配额授权和信用控制，为运营商实现预付费业务、流量套餐封顶、漫游费用控制、企业子账户限额管理等多样化的商业模式提供了坚实的技术保障。

特性在线计费 (Online Charging)离线计费 (Offline Charging)
核心思想先授权，后使用先使用，后记账
与业务关系实时交互，控制业务的开始、持续和终止业务完成后上报，不干预业务执行
主要产物实时的授权/拒绝信令，最终也会生成CDR批处理的CDR文件
关键技术配额管理、单元预留、门限触发、再授权事件/会话上报（Initial, Update, Terminate）
适用场景预付费用户、套餐封顶、漫游控制、实时策略后付费用户、企业用户、物联网、网间结算
“美美”示例观看高清电影，实时申请和消耗流量配额（不适用，她是预付费用户）

至此，我们已经完整地剖析了3GPP TS 32.290中定义的两种基本计费场景。然而，5G的计费远不止于此。在接下来的文章中，我们将进入一个更为激动人心的话题——融合计费（Converged Charging）。届时，我们将看到5G如何将在线计费和离线计费的优点合二为一，用一套架构、一套接口实现所有业务的计费需求。敬请期待！

FAQ - 常见问题解答

Q1：如果美美的手机余额在看电影中途用完了，会发生什么？ A1：这是一个经典的在线计费场景。当SMF向CHF申请下一个流量配额时，CHF会检查美美的余额。如果发现余额不足以支付所申请的最小配额，CHF会拒绝该授权请求。在响应消息中，它会明确告知SMF授权失败，原因为“信用额度用尽”。同时，CHF可能会下发一个“最终单元指示”（Final Unit Indication, FUI），指令SMF执行特定动作，最常见的动作就是**终止（Terminate）**业务。SMF收到指令后，会立即终止该PDU会话，美美的电影就会中断，手机通常会收到运营商的余额不足提醒。

Q2：在5G服务化架构（SBA）中，谁扮演了传统4G网络中OCS（Online Charging System）的角色？ A2：在5G SBA中，**CHF（Charging Function）**整合并演进了传统网络中离线计费系统（OFCS）和在线计费系统（OCS）的功能。当CHF处理需要实时信用控制的业务时，它就扮演了OCS的角色。这种功能上的融合是5G核心网设计理念的体现，旨在简化网络架构，提高灵活性和效率。

Q3：什么是“单元预留（Unit Reservation）”，为什么它很重要？ A3：“单元预留”是在线计费中的一个关键金融操作。当计费系统（CHF）授予一个资源配额时，它会从用户的账户中“冻结”与该配额等值的金额。这笔钱并没有被真正扣除，但用户也暂时无法使用它。这非常重要，因为它可以防止“信用超支”。例如，如果用户账户只有5元，在观看视频（业务A）的同时，后台应用（业务B）也想发起数据传输，如果没有预留机制，两个业务的计费请求可能都会被授权，导致总费用超过5元。预留机制确保了为业务A预留的钱，不会被业务B“抢走”，保证了计费的严谨性。

Q4：为什么在线计费会话需要设置“门限（Threshold）”来触发再授权，而不是等配额完全用完再申请？ A4：这是为了保证业务的连续性和用户体验。从SMF发起再授权请求，到CHF处理并返回响应，这个过程虽然很快（毫秒级），但仍然需要时间。如果等配额完全用完再申请，那么在这段信令交互的时间里，用户将没有可用的配额，导致业务（如视频、游戏）发生卡顿或中断。通过设置门限（如80%），可以在旧配额耗尽之前就提前获取新配额，实现新旧配额的无缝切换，确保用户体验的流畅。

Q5：分散式和集中式的“单元确定”与“计费费率”在实际部署中有什么不同含义？ A5：这反映了网络功能和计费策略的灵活性。

  • 分散式单元确定 + 集中式计费费率（最常见）：CTF（如SMF）根据业务特性决定需要多少资源（比如“给我100MB流量”），而价格和信用控制由CHF统一管理。这使得网络设备专注于业务处理，计费策略集中管理，易于更新和维护。
  • 集中式单元确定 + 集中式计费费率：CTF甚至不知道该申请多少资源，它只是告诉CHF“用户要开始一项视频业务了”，由CHF根据用户套餐、网络状况等策略，决定首次授予多少配额。这种模式赋予了计费系统更大的控制权。 这种灵活的组合允许运营商根据不同的业务类型和商业模式，选择最适合的计费交互模型。

关系图谱