深度解析 3GPP TS 32.240：5.3 Charging levels and correlation (计费级别与计费关联)
本文技术原理深度参考了3GPP TS 32.240 V18.9.0 (2024-12) Release 18规范中，关于“5.3 Charging levels and correlation”的核心章节，旨在为读者揭示5G网络如何通过一个分层、关联的立体计费模型，精准捕捉并核算每一次复杂通信服务的价值。
在之前的章节中，我们已经了解了计费数据的生成与传输。然而，现代通信业务，尤其是像高清视频通话或云游戏这样的5G杀手级应用，绝不是一次简单的数据传输。它是一个涉及多个网络层面、多种资源消耗的复杂协同过程。
那么，网络是如何区分“为数据管道付费”和“为通话服务本身付费”的呢？当一个用户行为同时产生了多种费用时，计费系统又是如何确保将这些账单准确无误地归属到同一次业务，而不是张冠李戴呢？
这就是本章将要揭示的核心——计费的分层与关联。今天，让我们再次跟随主角小美，通过她发起的一场5G高清视频通话（VoNR），来深入探索这个立体计费模型的奥秘。
特别说明： 本文参考的TS 32.240 V18.9.0版本中，5.3.1至5.3.3章节包含了“Editor’s note: To be completed.”的标记。这意味着在规范的当前版本中，这些章节的具体内容仍在制定中。因此，本文将基于规范标题的逻辑含义、行业共识以及关联规范的原理，对这些计费级别的概念进行前瞻性解读，并重点详述规范中已有明确内容的5.3.4 计费数据关联部分。
1. 计费的维度：三个核心级别
想象一下，小美要给她的朋友打一通VoNR视频电话。这次通话至少涉及到三个层面的资源消耗，3GPP的计费模型也相应地定义了三个计费级别来分别衡量它们。
1.1 承载层计费 (Bearer level charging)
这是计费体系的最底层，关注的是“路”的价值，即为数据传输所建立的管道。
规范原文 5.3.1： Bearer level charging
Editor’s note: To be completed. The use of EBCF and SBCF in the sub-clauses for all the three charging levels shall also be described here.
概念解读：
尽管此章节细节待定，但“承载层计费”的概念是明确的。它指的是针对为用户业务建立的特定数据承载（Bearer）或PDU会话（PDU Session）的计费。计费的依据通常是数据量（用了多少GB）、时长（管道占用了多久），以及最重要的——服务质量（QoS）。
场景解读：
小美发起VoNR视频通话时，她的手机和5G网络（具体由SMF负责）会协商建立一个或多个专用的QoS流（QoS Flow）。为了保证视频通话的流畅，这个QoS流会被赋予特定的高优先级和低时延保障（例如，5QI=1或2）。
承载层计费，就是针对这个“VIP数据通道”的计费。SMF中的CTF会记录这个通道消耗了多少上行和下行流量。运营商可以制定这样的资费策略：“普通上网流量0.1元/MB，但VoNR高清视频通话的专用通道流量0.3元/MB”。这个针对数据管道本身质量和用量的计费，就是承载层计费。
1.1.1 基于承载/电信/补充业务的承载计费 (Bearer charging based on bearer / tele- / supplementary service)
规范原文 5.3.1.1： Editor’s note: To be completed.
此节旨在细化承载计费的具体类型，可能包括基础的数据承载、传统的电信业务（如语音）以及补充业务（如呼叫转移）在承载层的计费方式。
1.1.2 基于流的承载计费 (Flow based bearer charging)
规范原文 5.3.1.2： Editor’s note: To be completed.
这是PCC（策略与计费控制）架构的核心。它允许对同一个PDU会话内的不同业务流（IP Flow）进行差异化计费。例如，在小美的VoNR通话中，语音流和视频流可以被识别并映射到不同的QoS流，从而实现对视频和语音流量的分别计费。
1.2 子系统层计费 (Subsystem level charging)
如果说承载层计费是为“路”付费，那么子系统层计费就是为路上跑的“车”——特定的服务会话——付费。
规范原文 5.3.2： Subsystem level charging
Editor’s note: To be completed.
概念解读：
子系统层计费主要针对的是IMS（IP多媒体子系统）这样的服务控制层。它不关心底层传输了多少数据比特，而是关心服务会话本身。计费的依据通常是会话时长、会话次数或服务类型。
场景解读：
小美的VoNR通话，本质上是一个IMS会话。IMS核心网的网元（如P-CSCF, S-CSCF）中的CTF，会记录这次IMS会话的建立、持续和释放。它们的计费视角是：“小美与朋友的VoNR通话，从xx:xx开始，到yy:yy结束，总共通话了15分钟。”
运营商可以制定这样的资費：“VoNR通话，每分钟0.2元”。这个费用与底层承载跑了多少MB流量无关，是独立于承载层计费的。这就解释了为什么有时候我们打电话是按分钟计费，而打电话消耗的流量又是另外一回事。
1.3 服务层计费 (Service level charging)
这是计费体系的最顶层，关注的是在“车”上装载的“特殊货物”——增值服务。
规范原文 5.3.3： Service level charging
Editor’s note: To be completed.
概念解读：
服务层计费针对的是由应用服务器（AS）提供的、超出基础通信能力范围的增值服务。
场景解读：
在与朋友视频通话时，小美启用了一项“实时AI字幕翻译”功能，这项功能由运营商的某个应用服务器提供。AS中的CTF就会触发一次服务层计费事件。
这个计费事件的内容可能是：“用户小美，在她的VoNR通话中，使用了AI字幕翻译服务，按次收费5元。” 这笔费用既不依赖于通话时长，也和流量无关，它是对特定增值服务的一次性计费。
小结： 小美的一通VoNR视频电话，在3GPP的立体计费模型下，可能同时产生了三种费用：
- 承载层费用：为保障通话质量的VIP数据通道所消耗的流量费用。
- 子系统层费用：IMS通话会话本身按时长计算的费用。
- 服务层费用：通话中使用的AI翻译增值服务按次计算的费用。
这三层费用由网络中不同位置的CTF（SMF、IMS-CSCF、AS）独立生成。一个严峻的问题随之而来：当计费中心收到这三笔账单时，它如何知道这三笔完全不同的费用都源自小美 同一次 视频通话呢？答案就是——计费关联。
2. 计费的粘合剂：计费数据关联 (Charging data correlation)
计费关联是整个计费体系的神经中枢，它负责将不同层面、不同来源的计费信息“粘合”在一起，确保计费的准确性和一致性。
2.1 关联的基础：充电标识符 (Charging Identifier)
规范原文 5.3.4.0： The correlation is based on specific access network charging identifier:
- Circuit Switched domain: MSC address and Call Reference Number;
- Packet Switched domain: P-GW address and EPC Charging ID;
- 5G Data connectivity domain: 5GC Charging ID;
- Fixed Broadband Access: Multimedia Charging ID;
- IM Subsystem: IMS Charging Identifier.
网络中的每一次会话，在其各自的层面都会被分配一个唯一的ID。这就像我们寄快递时，包裹本身有一个运单号，如果这个包裹是某个大宗订单的一部分，这个订单还有一个总订单号。
- 小美的数据通道（PDU Session）被分配了一个5GC Charging ID。
- 她的IMS视频通话会话被分配了一个IMS Charging Identifier (ICID)。
关联的核心，就是在不同层级的计费记录中，设法包含其他层级的ID。
2.2 内部关联：Intra-level correlation
这种关联发生在同一个计费层级内部，用于将描述同一个会话的多条部分CDR（Partial CDRs）关联起来。
规范原文 5.3.4.1： The intra-level correlation aggregates the charging events belonging to the same charging session, e.g. over a time period, and implies the generation of interim charging records.
场景解读：
小美的VoNR通话持续了1小时。底层的SMF可能会每15分钟生成一条部分CDR，总共4条。计费中心如何知道这4条独立的CDR都属于同一次数据会话呢？
答案很简单：这4条部分CDR中，都会包含完全相同的5GC Charging ID。这个ID就像一条绳子，将这4个“碎片”牢牢地串在一起，使得计费系统可以轻松地将它们还原成一次完整的1小时数据会话。
2.3 跨层关联：Inter-level correlation
这是最关键也最复杂的关联，它发生在不同计费级别之间，用于粘合描述同一个用户业务的不同层面的计费记录。
规范原文 5.3.4.2： The inter-level correlation combines the charging events belonging to the same service but generated by different CTFs e.g. for PS access control via IM Subsystem.
场景解读：
现在来解决我们之前提出的核心问题：如何将承载层的流量CDR和子系统层的IMS通话CDR关联起来？ 这个过程像一场精密的接力赛：
- ID的诞生： 小美发起通话，IMS核心网（P-CSCF）首先为这次通话创建一个唯一的IMS Charging Identifier (ICID)。
- ID的传递： 在IMS会话建立过程中，IMS核心网通过信令交互，经由PCF（策略控制功能），将这个ICID传递给了负责承载层的SMF。
- ID的记录： SMF收到这个ICID后，如获至宝。在它后续为这个PDU会话生成的所有承载层CDR中，不仅会包含自己的5GC Charging ID，还会专门开辟一个字段，记录下来自IMS层的ICID。
- 关联的实现： 现在，计费中心收到了两类CDR：一类来自IMS核心网，以ICID为主要标识；另一类来自SMF，同时包含了5GC Charging ID和ICID。计费系统只需做一个简单的数据库关联查询（JOIN on ICID），就能瞬间将特定通话时长的费用和该通话消耗的流量费用完美地对应起来。
通过这种跨层关联机制，运营商可以实现复杂的组合计费策略，例如：“每月前300分钟VoNR通话，免通话费，只收流量费；超出300分钟后，通话费和流量费双重收取。”
2.4 跨网关联：Inter-network correlation
这种关联发生在不同运营商网络之间，主要用于漫游和网间结算。
规范原文 5.3.4.3： To enable the different operators involved in IMS sessions to identify each other, the Inter Operator Identification concept (IOI) is introduced. IOI allows operators involved with session signalling to identify each other by exchanging operator identification information within the SIP signalling.
场景解读：
假设小美的朋友使用的是另一家运营商B的网络。当小美的通话信令从她的归属运营商A网络发送到运营商B网络时，需要有一种机制让双方明确知道“我是谁”以及“我要和谁通话”，以便将来进行费用结算。这就是IOI（Inter Operator Identifier）的作用。
- 始发IOI： 当通话信令离开运营商A时，会被打上一个标签，即“始发IOI”，内容是运营商A的全球唯一标识。
- 终结IOI： 当通话信令到达运营商B时，运营商B会在响应信令中打上自己的标签，即“终结IOI”。
- 传输IOI： 如果中间还经过了第三方转接网络C，那么还会有“传输IOI”。
这些IOI信息会被记录在各自运营商生成的CDR中。在月底结算时，运营商A的计费中心就可以根据CDR中的IOI，准确地向运营商B支付网间结算费用。
3. IMS计费的完整性保证
由于IMS业务的复杂性，一次呼叫信令可能经过多个网元（NE）和应用服务器（AS）。如何确保所有参与方的计费信息都被完整收集了呢？
规范原文 5.3.4.4.2： Based on operator policy, each IMS NE for which the CTF is generating charging events, shall include its own address or specific NE identifier into the initial SIP request to be sent out within the trust domain.
规范为此设计了一种“路径追踪”机制：
- 初始的SIP信令请求就像一张“旅行卡”。
- 每经过一个会产生计费话单的IMS网元（如P-CSCF, S-CSCF, AS），这个网元就会在“旅行卡”上盖上自己的“印章”（地址或ID）。
- 当信令路径走完，最终的响应消息会携带这张盖满了印章的“旅行卡”返回。
- 最初发起请求的网元，在它生成的CDR中，会包含这张“旅行卡”的完整信息，即所有参与计费的网元列表。
这样，计费域在后台处理时，就可以根据这个列表，核对是否收到了来自所有“盖章”网元的CDR。如果发现缺少了某个网元的CDR，就可以触发告警或异常处理流程，从而最大限度地避免了计费信息的丢失和收入的流失。
FAQ 环节
Q1：为什么需要将计费划分成承载层、子系统层和服务器层？统一只按流量计费不可以吗？ A1：统一按流量计费是一种简化的模型，但在商业上和技术上都存在局限性。分层计费模型提供了更强的灵活性和商业价值：
- 价值区分： 不同的服务层级代表了不同的价值。保障通话质量的“VIP通道”（承载层QoS）比普通上网通道更有价值；一次通话服务（子系统层）本身也具有独立于流量的通信价值；而AI翻译等增值服务（服务层）价值更高。分层计费使得运营商可以对不同价值的服务进行差异化定价。
- 业务解耦： 很多业务，如VoNR，其时长和流量并非线性关系（例如，静止画面和动态画面的流量消耗差异巨大）。如果只按流量计费，无法准确衡量用户对“通信服务”本身的使用。分层计费将业务和承载解耦，可以同时提供“X元包Y分钟通话”和“A元包B GB流量”两种独立的计费模式。
- 生态合作： 服务层计费是与第三方应用提供商合作的基础。运营商可以为第三方提供的增值服务（如云游戏加速、付费表情包）提供计费通道，并从中分成。
Q2：Inter-level correlation (跨层关联) 是如何技术实现的？ICID是如何从IMS域传递到分组域的SMF的？ A2：这是一个非常深入的技术问题。这个传递过程是策略与计费控制（PCC）架构的核心功能之一。简化来说，流程如下：
- IMS域的P-CSCF与策略控制功能PCF建立交互。在IMS会话注册和建立过程中，P-CSCF会将ICID等会话信息上报给PCF。
- PCF同时与分组域的SMF保持着策略控制会话。PCF在收到来自IMS域的业务信息后，会制定相应的策略（如为该业务流建立专用QoS Flow）和计费规则。
- 关键一步：PCF会将包含ICID的计费关联信息，作为计费规则的一部分，通过Nsmf_PDUSession_UpdateSMContext服务下发给SMF。
- SMF收到这些规则后，一方面按要求建立或修改QoS流，另一方面将这个ICID保存在PDU会话的上下文中，用于后续生成CDR。
Q3：如果跨层关联失败，比如SMF没有正确收到ICID，会有什么后果？ A3：后果可能很严重，主要体现在计费混乱和收入损失：
- 计费不准确： 计费中心会收到“孤儿”CDR，即无法确定某段大流量消耗究竟是由哪次具体通话引起的。这可能导致无法对高价值业务（如VoNR）进行准确计费，只能按普通的“垃圾流量”进行计费，造成收入损失。
- 策略执行错误： 如果运营商的策略是“VoNR通话流量免费”，但由于关联失败，SMF无法识别这段流量属于VoNR，就可能会错误地对用户收取了本应免费的流量费，引发客户投诉。
- 用户详单错误： 用户查询详单时，可能看到一笔“未知”的流量费用，而无法与自己的通话记录对应起来，严重影响用户体验和品牌信任度。
Q4：Intra-level correlation (内部关联) 中提到的Reduced Partial CDR (RPC) 相比Fully Qualified Partial CDR (FQPC) 有什么好处？ A4：RPC的核心好处是节省资源。在一个长时间的会话中（如看电影），会生成非常多的部分CDR。
- 如果每一条都是FQPC，那么大量不变的信息（如用户ID、设备ID、会话开始时间、接入位置等）会在每一条CDR中重复出现，这会消耗大量的网络带宽（在Ga接口上传输）和存储空间（在CGF和BD中存储）。
- 而采用RPC后，只有第一条是FQPC，后续的RPC只记录变化量和必要字段，大大减少了每条CDR的大小，从而节省了从CDF到CGF再到BD的整条链路的资源开销，提高了计费系统的整体处理效率。
Q5：Inter-network correlation (跨网关联) 的IOI信息是强制的吗？小运营商或专网可以不使用吗？ A5：对于需要进行公共电信网络互联互通并进行商业结算的场景，使用IOI基本上是强制性的行业规范和事实标准。没有IOI，运营商之间就无法可靠地识别对方，也就无法进行自动化的漫游和网间话务清算。这就像国际贸易没有标准的报关单和原产地证明一样。 然而，在一些特定场景下，可能不使用或使用私有的标识：
- 私有网络/专网： 在完全隔离的企业专网或垂直行业网络中，如果不存在与其他运营商的结算需求，可以不使用标准的IOI体系。
- 双边协定： 两个运营商之间可以通过特殊的双边协定，采用私有的、非标准的标识进行结算，但这会增加系统复杂性，不利于拓展更多的合作伙伴。 因此，对于任何想融入全球电信生态的运营商来说，支持标准的IOI是必不可少的能力。