51学通信

深度解析 3GPP TS 32.240：5.2 Charging data transfer (计费数据传输)

25分钟阅读

深度解析 3GPP TS 32.240：5.2 Charging data transfer (计费数据传输)

本文技术原理深度参考了3GPP TS 32.240 V18.9.0 (2024-12) Release 18规范中，关于“5.2 Charging data transfer”的核心章节，旨在为读者清晰地描绘出计费信息在网络内部从产生到最终汇集的完整旅程。

在上一篇文章中，我们跟随主角小美，了解了计费数据是如何在各种网络功能（NF）中被“生成”的。然而，生成数据仅仅是万里长征的第一步。这些分散在网络各个角落的原始计费信息，必须经过一条精确、可靠的传输链路，才能被汇集、处理，最终形成我们手机上的话费账单。

今天，我们将继续小美的5G探索之旅，扮演一名“计费数据快递员”，追踪这些重要的数据包，看看它们在网络中究竟经历了一场怎样的“奇幻漂流”。这场旅行将分为三条截然不同的路线：传统的离线计费“邮政系统”、实时的在线计费“加密专线”，以及5G时代融合的“智慧物流平台”。

1. 计费数据传输概述

规范原文 5.2.0： Clause 5.1 describes the generation of charging information, events and records and quota supervision across the various logical functions. In the present clause, the relation between the events, records, Credit-Control sessions and CDR files is explained.

规范开宗明义地指出，本章节的核心任务是解释清楚“计费事件（events）”、“计费记录（records/CDRs）”、“信控会话（Credit-Control sessions）”和“CDR文件（CDR files）”之间的关系。这正是我们要追踪的数据在不同阶段的不同形态。

  • 计费事件 (Charging Event): 这是最原始的数据包，由CTF产生，记录了单次的网络行为。
  • 计费记录 (CDR - Charging Data Record): 由多个计费事件加工、合并而成，是对一次完整业务（如一次通话、一次上网）的标准化描述。
  • 信控会话 (Credit-Control Session): 这是在线计费的专属概念，是网络功能与OCS之间为了进行实时额度控制而建立的持续性会话。
  • CDR文件 (CDR File): 将成千上万条CDR打包在一起，形成一个文件，最终传送给计费中心。

现在，让我们系好安全带，开始追踪小美的计费数据包。

2. 路线一：离线计费的数据之旅 (Offline Charging)

离线计费就像一个庞大而严谨的传统邮政系统，它的特点是“存储-转发”，数据一步步被收集、处理和传递。这条路线主要涉及三个关键的“中转站”和它们之间的“交通干线”（参考点）。

2.1 第一站：从CTF到CDF (通过Rf接口) - 打包原始包裹

我们的旅程始于计费事件的产生地——CTF。CTF就像遍布城市每个角落的“收件点”，它收集了最原始的计费信息。

规范原文 5.2.1.1： In event based charging, a network / user event (e.g. MM submission) corresponds to a single chargeable event. In session based charging, at least two chargeable events are needed, one each to describe the start and the end of the session, respectively… The CTF transforms each chargeable event into a charging event and forwards these charging events to the CDF in real-time.

CTF将用户的行为（可计费事件）转换成标准格式的“计费事件”，然后通过Rf接口这条路，实时地发送给它的第一个目的地——CDF（Charging Data Function，计费数据功能）。

场景解读：

还记得小美早上发送的那条彩信（MMS）吗？在她点击发送后，MMSF（彩信功能）中的CTF立即生成了一个计费事件。这个事件就像一个原始的快递包裹，上面贴着标签：“来自小美，内容：彩信，大小：XX KB”。CTF立即通过Rf接口，将这个“包裹”发往CDF。

对于小美下午观看的长时间体育直播，CTF的行为则更复杂。

  • 直播开始时，它会生成一个“会话开始”事件。
  • 直播过程中，如果网络策略变化（比如切换到不同的网络质量QoS），或者达到一定时长/流量，它会生成“会话中更新”事件。
  • 直播结束时，它会生成一个“会话结束”事件。

所有这些描述同一场直播的事件，都会被源源不断地通过Rf接口发送给CDF。Rf接口是计费数据离开其产生源头的第一条必经之路。

2.2 第二站：从CDF到CGF (通过Ga接口) - 分拣与组装

CDF是整个离线计费流程中的“区域分拣中心”。它的核心职责是接收来自一个或多个CTF的零散的“计费事件包裹”，并将它们加工成标准化的“计费数据记录（CDR）”。

规范原文 5.2.1.2： Upon receiving a charging event, the CDF uses the event to create/open a CDR (both event and session based charging), or to add information to an existing open CDR… In session based charging, a CDR is opened when the initial charging event… is received. Information is added to the CDR upon receiving interim charging events.

CDF收到彩信的计费事件后，由于这是一次性业务，它很快就处理完毕，生成了一条完整的CDR。

但对于小美的直播会话，CDF的工作就复杂多了。它首先根据“会話开始”事件，创建并打开一个CDR。然后，它会耐心等待所有与这次直播相关的“会话中更新”事件，并把这些信息不断填充到这个打开的CDR中。直到收到“会话结束”事件，CDF才会最终完成并关闭这条CDR。

关键知识点：部分CDR (Partial CDRs)

如果小美的直播看了很久，比如3个小时，让CDF一直维持一个打开的CDR长达3小时，风险很高（比如系统故障导致数据丢失）。因此，规范引入了“部分CDR”机制。

规范原文 5.2.1.2： When a CDR is closed and the session is still active, a subsequent CDR is opened. Hence multiple “partial CDRs” may be needed to completely describe the session… Therefore, two formats are considered for Partial CDRs:

  • a Fully Qualified Partial CDR that contains the complete set of CDR Fields, and
  • a Reduced Partial CDR that contains all the Mandatory fields (M) and ONLY the changes that occurred in any other field relative to the previous partial CDR.

CDF可以根据配置的触发器（如时长限制、流量限制、计费条件变化次数限制），在一个长的会话中生成多条CDR。例如，每15分钟就关闭当前的CDR，并为同一个会串立即打开一条新的CDR。这样，一个3小时的直播就可能产生了12条部分CDR。

这12条CDR又分为两种：

  • 完全限定部分CDR (FQPC - Fully Qualified Partial CDR): 第一条CDR必须是FQPC，它包含了这次会话所有的详细信息，就像快递的第一箱货物，上面有完整的收件人、发件人、地址等所有信息。
  • 简化部分CDR (RPC - Reduced Partial CDR): 后续的11条CDR可以是RPC。它们只记录与前一条CDR相比发生变化的信息，以及一些强制性字段。例如，如果小美的位置没变，RPC中就不会重复记录位置信息。这就像快递的后续箱子，上面可能只写着“第2/12箱”，节省了空间和处理开销。

当CDF制作好这些CDR后，它会通过Ga接口，将这些CDR一条条地近实时地发送给下一个中转站——CGF（Charging Gateway Function，计费网关功能）。

2.3 第三站：从CGF到计费域 (通过Bx接口) - 打包与发货

CGF是离线计费数据流出通信核心网之前的最后一站，可以看作是“国家级物流中转枢纽”。它的职责是收集来自所有CDF的CDR，进行最终的打包和归档。

规范原文 5.2.1.3： The CGF is responsible for persistent CDR storage, for preparing CDR files and transferring them to the BD via the Bx reference point. To this end, the CGF provides one or more files on which to store the CDRs…

CGF内部会同时打开多个文件，它会根据CDR的类型（如语音CDR、数据CDR、彩信CDR）、来源CDF等规则，将收到的CDR分类存放到不同的文件中。这就像物流枢纽把发往北京的货物和发往上海的货物理到不同的集装箱里。

这些文件会在满足特定条件时被关闭，例如：

  • 文件大小达到上限（如100MB）。
  • 文件开启时间超过限制（如15分钟）。
  • 文件内的CDR数量达到上限（如10000条）。
  • 到达了某个特定的时刻（如每天的午夜）。

文件一旦关闭，就意味着它已经“打包完成，待发货”。CGF随后会通过Bx接口，将这些CDR文件传输给最终的目的地——运营商的计费域（BD, Billing Domain）。Bx接口通常使用标准的文件传输协议（如FTP、FTAM）。

计费域收到CDR文件后，就会进行批价、合账、出账等操作，最终生成小美下个月的话费账单。至此，离线计费的数据传输之旅宣告结束。

规范中的 “Figure 5.2.1.2.1: Possible Configurations of Ga and Bx CDR Formats” 清晰地展示了CDF、CGF和BD之间关于CDR格式处理的三种配置模式：

  • a) 默认模式： CDF生成完整的CDR（Complete Partial CDR，即FQPC），通过Ga和Bx传输，CGF和BD都处理完整的CDR。这是所有系统必须支持的基础模式。
  • b) CGF转换模式： CDF生成简化的CDR（Reduced Partial CDR，即RPC）以节省Ga接口带宽，CGF负责将RPC转换成完整的CDR再通过Bx发送给BD。这要求CGF具备“还原”信息的能力。
  • c) 端到端简化模式： CDF生成RPC，CGF直接透传，由最终的BD来处理RPC。这要求BD也具备处理简化CDR的能力，可以最大程度地节省网络和系统资源。

3. 路线二：在线计费的数据之旅 (Online Charging)

与离线计费的“邮政系统”不同，在线计费的数据传输更像一次实时的银行卡交易。数据不是单向流动，而是一次快速的、有来有回的“请求-响应”交互。这条路线的核心是CTF与OCS（Online Charging System）之间通过Ro接口建立的“加密专线”。

规范原文 5.2.2： In online charging, charging events mirroring the resource usage request of the user are transferred from the CTF to the OCF via the Ro reference point… For event based charging, the Credit-Control procedure in the OCS may or may not involve reservation of units… For session based charging, at least two chargeable events are needed…

场景解读：

我们再次回到小美（预付费用户）观看体育直播的场景，聚焦于数据传输的交互过程：

  1. 请求授权（Initial Request）： 直播开始，SMF中的CTF立刻通过Ro接口向OCS发送一个“Credit-Control-Request [Initial]”消息。这个消息就像刷卡机向银行发送的交易请求：“用户小美想看视频，请求授权。”

  2. 授予配额（Initial Answer）： OCS验证身份、查询余额后，通过Ro接口返回一个“Credit-Control-Answer [Initial]”消息。这好比银行的回应：“授权通过，本次交易额度上限为100MB。”

  3. 更新配额（Update Request/Answer）： 当100MB配额即将用尽时，CTF会再次通过Ro接口向OCS发送“Credit-Control-Request [Update]”消息，请求新的配额。OCS则会返回“Credit-Control-Answer [Update]”，授予下一批配额。这个一来一回的交互会持续进行。

  4. 终止会话（Termination Request/Answer）： 直播结束，CTF通过Ro接口发送最后的“Credit-Control-Request [Termination]”消息，报告本次会话最终用掉的资源。OCS进行最终扣费后，返回“Credit-Control-Answer [Termination]”，关闭这次信控会话。这相当于交易完成，银行打印出最终的收据。

在线计费的数据传输核心在于其实时性和交互性。每一次资源的使用都必须得到OCS的明确许可，数据传输是双向的、状态化的，与离线计费的单向、无状态的“存储-转发”模式形成了鲜明对比。

4. 路线三：融合计费的5G新干线 (Converged Charging)

进入5G时代，随着网络架构向服务化（SBA）演进，计费系统也迎来了革命性的升级——融合计费系统（CCS）。离线和在线不再是两条独立的“公路”，而是被整合到了一条统一的、高效的“高速铁路”上。这条新干线就是Nchf接口。

规范原文 5.2.3： In converged charging, charging events mirroring the resource usage request of the user are transferred from the CTF or CEF to the CHF via the Nchf service-based interface… The CTF determines whether to use Event based charging (IEC and PEC) or Session based charging (SCUR and ECUR).

在5G架构下，CTF不再直接与CDF或OCF对话，而是作为“计费服务消费者”，去调用融合计费功能（CHF, Charging Function）提供的Nchf_ConvergedCharging服务。

场景解读：

小美在5G网络下使用任何业务，无论是发彩信还是看直播，SMF（或其他NF）中的CTF都会通过Nchf接口向CHF发起服务请求。

这个请求本身包含了所有必要的信息，CHF可以根据请求中的参数以及用户签约信息，智能地判断这次请求应该走“在线计费流程”（需要额度管理）还是“离线计费流程”（无需额度管理）。

  • 对于预付费的小美： CHF会启动在线计费逻辑，进行实时的配额授予和监督。
  • 对于后付费的小美： CHF会启动离线计费逻辑，直接记录消费，用于后续生成CDR。

Nchf接口的本质是基于HTTP/2的RESTful API调用，它统一了接口，简化了架构，使得计费逻辑更加灵活和集中。它就像一个万能的智慧物流平台，你只需要提交一个标准化的订单，平台会根据订单的性质（是否需要“货到付款”的信控）自动选择最优的处理和配送路径。

FAQ 环节

Q1：Rf接口和Ga接口都用于离线计费，它们传输的内容有什么本质区别？ A1：这是一个核心问题。Rf接口传输的是“计费事件（Charging Events）”，而Ga接口传输的是“计费数据记录（CDRs）”。

  • Rf上的计费事件是相对原始、零散的数据，它只是对网络中发生的某个特定时间点的行为的描述，例如“会话开始”、“QoS发生变化”。
  • Ga上的CDR是经过CDF处理和组装后的“成品”。CDF会将来自Rf的多个相关事件（如同一个会话的开始、更新、结束事件）进行关联、合并和格式化，最终生成一条或多条结构化的、信息完整的CDR。可以说，CDF扮演了从“原始素材”到“标准化记录”的加工角色。

Q2：为什么离线计费需要CGF（计费网关）这个角色？为什么不让CDF直接将CDR文件发送给计费域（BD）？ A2：设立CGF主要出于架构解耦、可靠性和管理效率的考虑：

  1. 汇聚与解耦： 一个运营商网络中可能有成百上千个CDF实例（每个都可能与特定的网络功能如SMF部署在一起）。CGF作为一个中心化的网关，可以汇聚来自所有CDF的CDR流，为计费域提供一个单一、稳定的对接点。这大大降低了计费域与核心网的耦合度。
  2. 可靠性与缓冲： CGF负责CDR的持久化存储。即使计费域出现故障或网络中断，CDR也会安全地存储在CGF中，待连接恢复后重新传输，保证了计费数据的完整不丢失。它起到了一个巨大的缓冲池作用。
  3. 格式转换与预处理： CGF可以执行CDR文件的格式转换、校验、过滤和路由等预处理工作，减轻了计费域的负担。例如，它可以将来自不同厂商、格式略有差异的CDR统一成标准格式再发送出去。

Q3：在线计费（Online Charging）流程中会生成CDR吗？如果生成，是在哪里生成的？ A3：会的。虽然在线计费的核心是实时信控，但运营商同样有统计分析、详单查询等需求，这些都需要CDR。根据规范（在4.3.2.3章节提及），如果需要为在线计费的用户生成CDR，这个任务由OCS/CCS自身来完成。OCS/CCS内部会集成一个CDF的功能模块。当OCS/CCS处理在线计费的Credit-Control请求时，它会利用这些信息，在内部生成CDR，然后通过自己集成的CGF功能，走标准的Bx接口将CDR文件发送给计费域。

Q4：5G的Nchf融合计费接口相比于4G的Rf（离线）和Ro（在线）分离接口，最大的优势是什么？ A4：最大的优势是架构的简化、统一和灵活性。

  1. 统一接口： 无论是离线还是在线计费，网络功能（如SMF）都只需要对接Nchf这一个服务化接口，大大降低了NF开发的复杂性。
  2. 集中化逻辑： 计费策略（判断走在线还是离线）从各个NF上移到了CHF中，使得策略的修改和部署更加集中和便捷，无需改动大量的网络功能。
  3. 服务化能力： 基于SBA架构，CHF可以被网络中的任何授权NF灵活调用，实现了计费能力的按需服务。同时，CHF自身也可以实现负载均衡、高可用等云原生特性，比传统的网元形态更具弹性。

Q5：小美在观看直播时，从4G网络无缝切换到了5G网络，她的计费会话会中断吗？数据传输是如何衔接的？ A5：在设计良好的4G/5G互操作场景中，计费会话不会中断。当发生4G到5G的切换时，会话会从PGW-C/SMF（4G核心网）平滑迁移到SMF（5G核心网）。计费层面会发生以下衔接：

  1. 4G侧会话终止： 原先与PGW-C对接的OCS/CHF会话会正常终止。PGW-C会向OCS/CHF发送一个包含“切换”原因的最终计费报告，结算在4G网络下使用的流量。
  2. 5G侧会话建立： 切换后的5G SMF会立即向同一个CHF（或根据路由策略选择新的CHF）发起一个新的Nchf计费会话建立请求，携带会话连续性的标识。
  3. CHF关联会话： CHF能够识别出这是一个由切换引起的连续会话，从而保证用户的计费策略、累计用量等信息得以延续。 对用户小美来说，这个过程是完全无感的，她的直播不会中断，计费也会被准确地分段记录和处理。

关系图谱