好的，我们继续解读TR 21.918的后续章节。
深度解析 3GPP TR 21.918：29.2 Charging Aspects of B2B (B2B计费方面) & 29.3 CHF Distributed Availability (CHF分布式可用性)
本文技术原理深度参考了3GPP TR 21.918 V18.0.0 (2025-03) Release 18规范中，关于“29.2 Charging Aspects of B2B”和“29.3 CHF Distributed Availability”的核心章节。本文将合并解读这两个高度相关的章节，旨在为读者深入剖析5G-Advanced如何对其计费架构进行深刻变革，通过引入B2B计费模型和分布式CHF部署，来满足垂直行业多样化的商业模式需求，并为超低时延等新兴业务的商业化变现奠定基础。
在5G时代，运营商的商业模式，正在从传统的“向个人用户卖流量”（B2C），向更广阔的“向千行百业卖服务”（B2B/B2B2C）转型。一个企业可能会租赁一个网络切片、调用一组开放API、或者为一个应用申请端到端的QoS保障。这些复杂的B2B商业场景，对5G的计费系统提出了全新的挑战。
传统的、以单个UE、单个PDU会话为中心的计费模型，已难以应对。如何清晰地区分“企业客户”（Tenant）和“终端用户”（Subscriber）的账单？如何为网络切片、API调用等“非连接”类的服务进行计费？当URLLC等业务要求计费交互的时延也达到毫秒级时，集中式的计费中心（CHF, Charging Function）又如何应对？
为了回答这些问题，3GPP在Release 18中，对融合计费系统（CCS）进行了两大关键演进。29.2章节聚焦于商业模型的变革，正式引入了B2B计费架构；而29.3章节则聚焦于部署架构的变革，探讨了CHF的分布式部署。
今天，我们的主角，是一家领先的云游戏公司的商务拓展总监，李总。他正在与运营商洽谈一项合作：将他们公司的云游戏平台，作为一个SLA保障的“优质业务”，集成到运营商的5G网络中。让我们跟随李总的商业谈判，看看29.2和29.3章节是如何为他的合作方案，提供标准化的计费与部署支撑的。
1. 商业模式的重塑：B2B计费架构 (解读 29.2)
李总的需求: 他希望运营商能够直接向他的公司，而不是向玩游戏的最终用户，收取网络资源使用费。计费的维度，应该是基于他公司业务的整体网络消耗，例如，“为我公司所有游戏玩家消耗的总流量”、“为保障游戏体验所占用的网络切片资源”等。
1010015 Charging Aspects of B2B (B2B_CH) This work item specifies the structure of B2B charging, by describing the reference of the applicable charging principles and architectures for B2B charging, and specifying the common charging information for B2B charging.
29.2章节为此定义了一系列B2B计费架构，其核心是引入了一个新的逻辑实体——B-CHF（Business CHF）。
Three B2B charging architectures and related charging principles are described in the Annex G in TS 32.240. The second architecture supports the intermediate interaction between NF(CTF) and B-CHF via C-CHF… The interaction between CHFs is supported by the Nchf service-based interface… To support the identification of business subscriber, the “tenant identifier” is specified as a common charging information…
让我们重点解读其中最典型、最灵活的“架构二”：通过C-CHF中介的B2B计费。
- C-CHF (Consumer CHF): 消费者计费功能。这基本等同于传统的CHF，它依然面向最终用户，负责处理单个UE、单个PDU会话的计费事件。
- B-CHF (Business CHF): 企业客户计费功能。这是一个新的逻辑实体，它面向企业客户（如李总的公司）。
- Tenant Identifier: 为了区分不同的企业客户，引入了一个新的标识——“租户ID”（Tenant Identifier）。李总的公司会被分配一个唯一的Tenant ID。
- “背靠背”的计费流程:
- 一个玩家（最终用户）正在玩李总公司的云游戏。相关的网络功能（如SMF, NEF），依然像往常一样，将计费事件（如流量、时长、QoS）上报给服务于该玩家的C-CHF。
- 同时，这些计费事件中，会附带上一个关键的新信息——Tenant ID（例如，“
cloud_game_inc_001”）。这个ID可以由PCF根据业务流的特征（如目标应用服务器地址）来确定。 - 关键一步: C-CHF在处理完这笔针对玩家的计费记录后（例如，从玩家的“游戏流量包”中扣除流量），它会识别出这个事件还关联了一个Tenant ID。于是，C-CHF会“背靠背”地，将这笔计费事件的副本，转发给与该Tenant ID关联的B-CHF。
- B-CHF收到后，将这笔费用，记在李总公司的账户上。
通过这套巧妙的“双边记账”模式，运营商成功地将一笔网络消费行为，同时映射到了C端（消费者）和B端（企业）两个不同的计费维度上，为复杂的B2B2C商业模式（例如，玩家购买游戏加速包，运营商与游戏公司进行收入分成）提供了灵活、清晰的计费基础。
2. 部署架构的变革：CHF的分布式可用性 (解读 29.3)
李总的另一个需求: 他的云游戏，特别是其中的VR云游戏，对时延要求极高。不仅业务时延要低，连计费授信（Credit Control）的交互时延，也必须控制在毫秒级。如果每次授信请求，都需要从边缘的UPF，长途跋涉到位于省中心的集中式CHF，这个时延是无法接受的。
990029 CHF Distributed Availability (DIST_CH) This work item describes how CHF can be deployed in a distributed manner in order to support:
- Use cases that require real-time charging (e.g. URLLC)
- Workload distribution across 5GS (increase redundancy and availability)
- UE mobility between Edges
- Distributed CCS discovery
29.3章节为此明确了CHF的分布式部署能力。
- 从“中央银行”到“社区支行”: 传统的CHF是高度集中化的“中央银行”。而分布式架构，则允许运营商将CHF的功能，以下沉的形式，部署到网络的边缘（Edge），靠近用户和业务发生地，形成一个个“社区支行”。
Currently, the CHF is usually deployed in a centralized model, though, it can be possible to deploy it at the Edge… The possibility of deploying the CHF at the Edge is quite relevant for facilitating the support of real-time charging use cases, and would enable the selection of the CHF which is closer to the Edge Enablement Server (EES).
2.1 分布式CHF的核心价值
- 支持实时计费: 对于李总的VR云游戏，其业务流由边缘UPF处理。这个UPF可以直接与同机房部署的边缘CHF进行计费交互，授信请求的往返时延可以从几十毫秒降低到1-2毫秒，完全满足URLLC业务的需求。
- 提升可用性与冗余度: 多个分布式CHF实例可以互为备份，当某个实例发生故障时，业务可以快速切换到其他实例，提升了计费系统的整体可用性。
- 支持边缘间的移动性: 当一个游戏玩家从一个边缘节点覆盖区，移动到另一个边缘节点覆盖区时，其计费会话也需要在两个边缘CHF之间进行平滑的迁移。分布式架构是实现这种“计费上下文迁移”的基础。
2.2 架构的演进
Therefore, a new annex (F) was included in TS 32.240 with the following information:
- Functional architecture of a centralized and Local/Edge CHF Deployment Model. It makes visible the possibility of having the CHF deployment in a distributed manner.
为了支撑这种分布式部署，DIST_CH工作项在计费架构规范TS 32.240中，增加了一个新的附录，明确了**“集中式 + 本地/边缘CHF”**的混合部署模型。在这个模型中，边缘CHF负责处理实时的、高频的计费授信请求，而集中的CHF则负责进行最终的话单合成、账单生成、以及跨区域的数据汇总和清算，两者各司其职。
3. B2B与分布式的协同
现在，让我们将B2B计费和分布式CHF这两大增强结合起来看。
在李总的云游戏合作方案中，一个完整的计费流程将是这样的：
- 边缘实时交互: 玩家在边缘节点A进行游戏。边缘UPF将实时的流量信息，上报给同机房部署的边缘C-CHF。
- 租户识别: 边缘C-CHF识别出这笔流量关联了李总公司的Tenant ID。
- 本地B2B记账: 边缘C-CHF随即通过高速内部网络，将这笔计费事件，也同步给同机房或同区域部署的边缘B-CHF，记入李总公司的实时账本。
- 后台数据汇总: 在非实时（例如，每小时一次）的周期，所有的边缘CHF，会将处理过的计费数据，批量地同步回位于省中心的集中式CHF。
- 账单生成: 月底，集中的CHF根据汇总的数据，分别为最终用户和李总的公司，生成各自的最终账单。
这套“本地实时处理 + 中心后台汇总”的分布式B2B计费架构，完美地兼顾了实时业务的低时延需求和B2B商业模式的灵活性，为李总的合作方案，提供了坚实、可落地的计费技术支撑。
总结
3GPP TR 21.918的29.2和29.3章节，共同构成了5G-Advanced计费体系的一次深刻的“供给侧改革”。它们将计费系统从一个被动的“后台记账员”，升级为了一个能够主动适应多样化商业模式、支撑实时性业务的“前台业务伙伴”。
- 通过引入B2B计费架构和Tenant ID，5G计费系统第一次获得了原生支持企业客户维度的能力，打破了长期以来“以个人用户为中心”的计费模型，为运营商向垂直行业转型，提供了最基础的商业变现工具。
- 通过明确CHF的分布式部署模型，5G计费系统解决了**实时性业务（如URLLC）**的计费延迟瓶颈，并极大地提升了计费系统的可用性和弹性，为网络向更边缘、更分布式的云原生架构演进，扫清了障碍。
对于像李总这样的行业合作伙伴，这些增强意味着他们可以与运营商进行更灵活、更深入的商业模式创新，无论是收入分成、SLA保障，还是按需订购网络能力，都有了标准化的计费方案作为支撑。
一个能够精准匹配B2B商业模式、并能适应边缘化和实时化业务需求的计费系统，是5G-Advanced赋能千行百业的“点金石”。29.2和29.3章节的演进，正在为5G的商业成功，注入最强劲的动力。
FAQ - 常见问题解答
Q1：B2B计费中的B-CHF（企业客户计费功能）和C-CHF（消费者计费功能）是两个独立的物理设备吗？
A1：不一定。B-CHF和C-CHF是逻辑功能上的划分。在实际部署中，它们可以：1）合一部署：运行在同一套融合计费系统（CCS）软件中，只是内部处理逻辑和数据模型不同。这是最常见、最经济的部署方式。2）分开部署：对于大型运营商，也可能将其部署为两个独立的系统，例如，一个专门服务于公众市场，另一个专门服务于政企市场。关键在于，无论如何部署，它们之间都需要通过标准化的Nchf接口进行交互。
Q2：什么是“租户ID”（Tenant Identifier）？它是由谁分配和管理的？ A2：“租户ID”是一个唯一标识企业客户的字符串。它是由运营商分配和管理的。当一个企业（如李总的云游戏公司）与运营商签订B2B服务协议时，运营商就会在其CRM（客户关系管理）和计费系统中，为这个企业创建一个账户，并为其分配一个唯一的Tenant ID。之后，在所有与该企业业务相关的网络策略（如PCF中的策略规则）和计费流程中，都会带上这个ID，作为企业身份的唯一标识。
Q3：分布式CHF是如何保证计费数据的一致性的？例如，一个用户的余额信息是如何在多个边缘CHF之间同步的？ A3：这是一个核心的挑战，通常采用**“中心化状态，分布式处理”的模式。1）状态中心化：用户的核心账户信息，如余额、信用额度、套餐余量等，依然唯一地存储在集中的CHF（或关联的数据库）**中。这保证了数据的一致性。2）处理分布式：当边缘CHF需要进行一次实时授信时（例如，扣费1元），它会向中心CHF发起一次快速的“预授权”请求。中心CHF在确认余额充足后，会为该边缘CHF“预留”1元的额度，并将授权返回。边缘CHF就在本地，基于这个预留的额度，进行高频的、实时的计费交互。当预留额度即将用完时，再向中心发起下一次“预授权”。3.）数据异步同步：边缘CHF会将详细的计费流水（CDR），异步地、批量地同步回中心CHF，用于最终的账单合成和审计。
Q4：CHF的分布式部署，是否意味着每个边缘机房都需要部署一套完整的计费系统？ A4：不一定。分布式部署是分层、分级的。并非所有的CHF功能都需要下沉。通常，只有那些对时延最敏感的功能，如在线计费功能（OCF）中的计费和授信（Rating & Credit Control）部分，才会被下沉到边缘。而那些非实时的、可以异步处理的功能，如离线计费功能（CDF）、账单生成、报表分析等，依然会保留在集中的CHF中。这种“混合部署”模式，可以在满足实时性需求和控制部署成本之间，取得最佳的平衡。
Q5：这些计费架构的演进，对第三方应用开发者（AF）有什么影响？ A5：有积极的影响，主要是提升了商业模式的透明度和可控性。1）清晰的成本模型：通过B2B计费，开发者（或其公司）可以获得一份清晰的、面向自己业务的“网络账单”，准确地知道自己的应用消耗了多少网络资源、成本是多少。2）SLA与成本挂钩：开发者在通过NEF API申请网络能力（如QoS保障）时，可以更清晰地了解到不同SLA等级对应的价格，从而做出更优的成本效益决策。3）赋能新业务: 例如，一个需要URLLC能力的应用，在有了分布式CHF的支持后，其“实时计费”瓶颈被打通，商业模式才真正变得可行。总而言之，一个更先进、更灵活的计费系统，是催生和繁荣上层应用生态的重要土壤。