51学通信

深度解析 3GPP TS 32.240：4 Common charging architecture and framework (通用计费架构与框架)

20分钟阅读

深度解析 3GPP TS 32.240：4 Common charging architecture and framework (通用计费架构与框架)

本文技术原理深度参考了3GPP TS 32.240 V18.9.0 (2024-12) Release 18规范中，关于“4 Common charging architecture and framework”的核心章节。本章是整个3GPP计费体系的基石，它定义了所有计费活动的“建筑蓝图”和“操作法则”。理解了它，就等于掌握了解读后续所有具体计费规范的钥匙。

在之前的章节中，我们已经跟随主角小美，通过具体的业务场景体验了计费的各个方面。我们看到了数据是如何生成、传输、关联和配置的。现在，是时候让我们退后一步，从用户的微观视角，上升到架构师的宏观视角，来审视整个5G计費大厦的“结构设计图”——这正是第四章的核心内容。

本章的目的，是建立一个**通用的、无处不在的（ubiquitous）**逻辑计费架构。这意味着，无论我们讨论的是数据业务（TS 32.255）、IMS业务（TS 32.260）还是短信业务（TS 32.274），它们底层的计费模型、功能组件和基本原则都遵循着第四章所描绘的这同一张蓝图。

1. 计费机制 (Charging Mechanisms) - 计费大厦的三种运营模式

在动工建造一座大厦之前，设计师首先要确定它的核心运营模式。3GPP的计费架构师们为这座大厦设计了三种核心的“运营模式”，以适应不同用户的消费习惯和运营商的管理需求。

规范原文 4.1.0 General： 3GPP networks provide functions that implement offline and/or online charging mechanisms on the domain (e.g. EPC), subsystem (e.g. IMS) and service (e.g. MMS) levels.

这三种模式分别是：离线计费、在线计费和融合计费。

1.1 离线计费 (Offline charging) - “信用卡”模式

规范原文 4.1.1 Offline charging： In conclusion, offline charging is a mechanism where charging information does not affect, in real-time, the service rendered.

离线计费的核心是**“先享后付”**。它就像使用信用卡消费，你在商场购物时，服务（获得商品）不会因为你的银行账户正在后台进行复杂的清算而中断。银行只是默默记下你的消费记录，然后在月底给你寄送账单。

  • 技术实现：网络功能（如SMF）中的CTF会实时收集小美的网络使用信息，将其打包成计费事件，发送给离线计费系统（OFCS）。OFCS将这些事件加工成CDR话单，最终传送到计费域（BD）进行批价和出账。
  • 用户体验：小美（后付费用户）可以流畅地使用网络，完全感受不到后台计费系统的存在。她的服务体验和计费过程是完全解耦的。

1.2 在线计费 (Online charging) - “储蓄卡/预付卡”模式

规范原文 4.1.2 Online charging： In conclusion, online charging is a mechanism where charging information can affect, in real-time, the service rendered and therefore a direct interaction of the charging mechanism with the control of network resource usage is required.

在线计费的核心是**“先付后享”或“实时控制”**。它就像使用储蓄卡或预付卡，每次消费前，收银台都必须实时连接到银行，检查你的余额是否足够。如果余额不足，交易会当场失败。

  • 技术实现：网络功能中的CTF在允许小美使用资源之前，必须向在线计费系统（OCS）发起授权请求。OCS实时检查小美的账户余额，授予一定的配额（如100MB流量或5分钟通话）。CTF必须实时监控配额的使用，并在用尽前再次申请。
  • 用户体验：小美（预付费用户）的每一次网络行为都受到账户余额的实时控制。计费过程和她的服务体验是紧密耦合的，计费系统可以直接“影响（affect）”甚至中断她的服务。

1.3 融合计费 (Converged charging) - “现代金融App”模式

规范原文 4.1.3 Converged charging： Converged charging is a process where online and offline charging are combined. The charging information is utilized by CCS in one converged charging service which offers charging with and without quota management, as well as charging information record generation.

融合计费是5G时代的主流。它不再将离线和在线视为两个独立的系统，而是将其功能融合到一个统一的融合计费系统（CCS）中。这就像一个现代的金融App，它既可以绑定你的信用卡（离线模式），也可以管理你的储蓄账户（在线模式），并提供统一的账单和消费分析。

  • 技术实现：网络功能（如SMF）只需要对接一个统一的计费接口（Nchf）。请求发送给CCS后，由CCS内部的融合计费功能（CHF）根据用户的签约类型（预付费或后付费）智能地决定是启动“配额管理（quota management）”流程，还是仅仅进行“话单记录生成（record generation）”。
  • 运营商优势：大大简化了网络架构和管理成本。运营商无需维护两套独立的计费系统，可以用一套统一的策略和平台来管理所有用户。

2. 通用顶层架构 (High level common architecture) - 计费大厦的设计总图

确定了运营模式后，我们来看看这座大厦的设计总图。第四章通过一系列架构图，为我们展示了计费功能组件之间的逻辑关系。

规范中的 “Figure 4.2.1.1: Logical ubiquitous charging architecture and information flows” 是理解整个计费体系的“第一图”，也是最重要的图。它清晰地描绘了计费大厦的三个主要“功能区”：

  • 离线计费区 (OFFLINE CHARGING)：展示了数据从网络实体（NEs）流向计费数据功能（CDF），再到计费网关功能（CGF），最终通过Bx接口到达计费域（BILLING DOMAIN）的经典路径。
  • 在线计费区 (ONLINE CHARGING)：展示了数据从网络实体（NEs）直接与在线计费系统（OCS）进行实时交互的路径。
  • 融合计费区 (CONVERGED ONLINE OFFLINE CHARGING)：展示了5G网络功能（NFs）通过统一的Nchf接口，与融合计费系统（CCS）进行交互的新模式。

随后的 Figure 4.2.2.1 和 Figure 4.2.3.1 等图，则分别详细描绘了在非5G（基于传统参考点，如Rf, Ro）和5G（基于服务化接口，如Nchf）两种不同技术体制下，这张总图的具体实现。

3. 计费功能 (Charging functions) - 计费大厦里的专业工种

如果说架构图是设计图，那么计费功能（Charging Functions）就是图纸上标注的、负责不同工作的专业“工种”。

3.1 离线计费的工种 (Offline charging functions)

  1. CTF (Charging Trigger Function - 计费触发功能)

    • 职责：驻扎在每一个产生计费信息的网络功能（如SMF, AMF, SMSF等）内部的“现场勘探员”。它负责实时监控网络资源的使用，一旦发现可计费的行为，就立即生成“计费事件”。
    • 类比：工地的传感器，检测到有车辆进出就立刻记录一次。

  2. CDF (Charging Data Function - 计费数据功能)

    • 职责：接收来自一个或多个CTF的零散的“计费事件”，并根据规则将它们组装成一条条结构化的、完整的“计费数据记录（CDR）”。
    • 类比：工地的档案管理员，把传感器的零散记录整理成一份份标准的施工日报（CDR）。

  3. CGF (Charging Gateway Function - 计费网关功能)

    • 职责：作为核心网与计费域之间的“大门”。它负责收集所有CDF生成的CDR，进行持久化存储、格式校验、文件打包，并最终通过Bx接口将CDR文件安全地传输给计费域。
    • 类比：工地的总调度室，将所有日报归档、打包，然后定期用卡车（Bx接口）运送到总部（计费域）。

3.2 在线计费的工种 (Online charging functions)

  1. CTF (增强型)

    • 职责：除了具备离线模式的监控能力外，在线CTF还被赋予了**“执行”的能力。它必须能够暂停用户的业务请求，等待OCS的授权；在收到授权后，它必须严格监督配额的使用；在配额用尽或OCS指令下，它必须能够终止**用户的服务。
    • 类比：带有门禁系统的智能传感器，不仅能记录，还能根据远程指令开关大门。

  2. OCS (Online Charging System - 在线计费系统)

    • 职责：整个在线计费的“大脑”。它负责实时处理CTF的授权请求，并进行账户管理和费率计算。OCS内部又细分为几个专业工种：
      • OCF (Online Charging Function): OCS的“前台接待”，负责与CTF直接对话。
      • RF (Rating Function): “定价专家”，负责根据复杂的资费策略，计算出一次业务请求需要多少钱或多少单元。
      • ABMF (Account Balance Management Function): “金库保管员”，负责管理用户的账户余额，执行预留和扣款操作。

3.3 融合计费的工种 (Converged charging functions)

融合计费是对上述工种的一次“机构改革”，旨在提质增效。

  1. CCS (Converged Charging System - 融合计费系统)

    • 职责：一个统一的计费平台，整合了离线和在线计费的所有能力。

  2. CHF (Charging Function - 计费功能)

    • 职责：CCS的核心，是新一代的“全能经理”。它内部整合了OCF（在线处理）和CDF（离线处理）的能力。当CTF通过Nchf接口发来请求时，CHF能够智能判断，并分发给内部相应的处理流水线。
    • RF和ABMF：这两位专家（定价专家和金库保管员）现在都直接向CHF这位全能经理汇报工作。

4. 架构映射 (Architecture mapping) - 从蓝图到施工

规范原文 4.5 Architecture mapping： The following sub-clauses describe how the logical ubiquitous charging architecture can be mapped onto physical components and interfaces within the scope of 3GPP standards.

第四章的最后一部分，也是非常重要的一部分，是告诉我们这张逻辑蓝图在现实世界中可以如何“施工建造”。它阐明了这些逻辑功能（如CDF, CGF）并非一定要是独立的物理设备。

例如，对于离线计费，规范在 Figure 4.5.1.1 到 4.5.1.4 中给出了四种典型的部署方案：

  1. 完全集成：CDF和CGF都集成在产生计费事件的网元（NE）内部。NE直接生成CDR文件。这种方式最简单，但耦合度高。
  2. CDF集成，CGF独立：NE内部集成了CDF，生成CDR后通过Ga接口发送给一个独立的CGF设备。这是非常主流的部署方式。
  3. 完全分离：CDF和CGF都是独立的物理设备。NE通过Rf接口给CDF发事件，CDF通过Ga接口给CGF发CDR。这种方式最灵活，解耦最彻底。
  4. CDF/CGF合并：CDF和CGF部署在同一个独立的物理设备中，NE通过Rf接口直接与这个“计费处理中心”对话。

这种灵活性，使得运营商可以根据自身的网络规模、成本考虑和运维模式，选择最适合自己的“施工方案”。

FAQ 环节

Q1：为什么3GPP要定义一个“通用”的计费架构？为每个业务单独设计不是更直接吗？ A1：定义通用架构是出于可扩展性、可维护性和成本效益的考虑。

  1. 可扩展性：未来5G会催生无数新业务。如果每个业务都重新发明一套计费轮子，系统将变得无比复杂和混乱。有了通用架构，任何新业务只需要复用这些标准的计费组件和接口，实现“即插即用”。
  2. 可维护性：统一的架构意味着统一的接口、协议和数据模型。这大大降低了运营商的运维难度和人员培训成本。
  3. 成本效益：设备商可以研发通用的计费产品（如独立的CGF、融合的CCS），运营商可以按需采购，形成了健康的产业生态。避免了为每个小众业务进行昂贵的定制开发。

Q2：CTF、CDF、CGF这些“功能”是硬件盒子还是软件？ A2：它们都是逻辑功能，在物理实现上绝大多数是软件。CTF是嵌入在其他网络功能（如SMF）软件代码中的一个模块。CDF和CGF可以是独立的软件应用，运行在通用服务器或虚拟机/容器中。它们也可以被集成到其他网元的软件中。关键是理解它们的“职责”，而不是它们的“物理形态”。

Q3：5G时代的CHF和4G时代的OCS/OFCS相比，最大的进步是什么？ A3：最大的进步是**“融合”与“服务化”**。

  1. 融合：CHF将原本分离的在线和离线处理逻辑统一在一个功能实体内，通过单一的Nchf接口对外提供服务。这解决了4G中网络功能需要同时维护Rf（离线）和Ro（在线）两套复杂接口的问题。
  2. 服务化：CHF是基于5G SBA（服务化架构）设计的，它将计费能力封装成网络服务（如Nchf_ConvergedCharging），可以被网络中任何经过授权的NF（服务消费者）按需调用。这使得计费能力的部署、升级和扩展变得像云服务一样灵活和弹性。

Q4：架构图中，为什么在线计费（OCS）没有像离线计费那样经过CGF再到计费域（BD）的路径？ A4：这是一个很好的观察。架构总图（如4.2.1.1）主要强调的是实时控制流。在线计费的核心是CTF与OCS之间的实时交互，用于额度控制，因此图中重点描绘了这条闭环链路。然而，这并不意味着OCS不产生话单。如前文FAQ所述，OCS内部通常也会集成CDF/CGF的功能，当需要为在线用户生成话单用于后台分析或详单查询时，OCS会自己生成CDR文件，并通过Bx接口发送给BD。只是这条“离线”路径对于OCS的实时功能来说是次要的，所以在顶层逻辑图中被简化了。

Q5：对于一个网络工程师来说，理解这个通用计费架构有什么实际意义？ A5：意义重大。

  1. 问题排查：当出现计费问题时（如话单丢失、计费不准），工程师可以依据这张架构图，清晰地判断问题可能出在哪个环节（是CTF没上报事件？是CDF生成CDR异常？还是CGF文件传输失败？），从而快速定位故障。
  2. 网络规划：在规划和部署新业务时，工程师需要参照这个架构，确保所有相关的网元都正确配置了计费功能，并打通了到计费系统的接口（Rf/Ro或Nchf）。
  3. 跨域协作：计费问题往往涉及多个团队（核心网、IT、计费中心）。这套通用架构提供了一套共同的“语言”和“地图”，使得不同领域的专家可以高效地沟通和协作。

关系图谱