好的，我们立刻继续对3GPP TS 32.255规范的深度解读。
在前几篇文章中，我们已经像信令工程师一样，追踪了计费信息在SMF和CHF之间流动的完整过程。现在，我们将转换视角，戴上计费中心（Billing Domain）数据分析师的帽子，来探究计FF费流程的最终产物——CDR（Charging Data Record，计费数据记录），也就是我们常说的“话单”，是如何诞生、成长并最终被“盖棺定论”的。
本篇文章将深入5.2.3节，为您揭示话单“前世今生”的完整故事：它在何种契机下被创建？在漫长的服务过程中，哪些事件会为它添上浓墨重彩的一笔？又是什么样的重要节点，需要它生成一份“阶段性总结”？最后，它又是如何被最终关闭，成为一份不可更改的“历史档案”的。
深度解析 3GPP TS 32.255：5.2.3 CDR Generation (话单的“前世今生”)
本文技术原理深度参考了3GPP TS 32.255 V18.6.0 (2024-12) Release 18规范中，关于“5.2.3 CDR generation”的核心章节，旨在为读者全面解析CHF如何根据来自SMF的计费请求，触发话单（CDR）的开启、信息追加、部分关闭和最终关闭的全生命周期管理机制。
1. CDR的诞生与归宿 (5.2.3.1 Introduction)
在开始探索CDR的生命周期之前，我们首先要明确它的起点和终点。
The CHF CDRs for PDU session charging and roaming QBC are generated by the CHF to collect charging information that they subsequently transfer to the Charging Gateway Function (CGF).
深度解析：
这段话清晰地定义了CDR的“出生地”和“第一站”。
- 出生地 (Generator)：CHF。所有的计费信息在CHF这里被汇聚、处理，并最终被“写入”到CDR这个标准化的数据结构中。CHF是CDR的唯一创作者。
- 第一站 (First Hop)：CGF。CHF生成CDR后，并不会直接将其写入最终的计费数据库，而是通过
Ga接口（参考5.2.4节）将这些一条条的记录实时或准实时地传送给CGF。CGF负责将来自网络中成百上千个CHF实例的CDR进行收集、聚合和格式化，最终生成符合标准格式的话单文件，再通过Bd接口（参考5.2.5节）传送给最终的计费域（BD）。
两种核心的记账哲学
As an alternative to the default CHF behaviour, the “Individual Partial record” mechanism can be used based on Operator’s policy configured in the CHF. In this case a new CDR shall be opened for each Charging Data Request[Initial, Update, Termination]…
在探索具体触发器之前，我们必须理解CHF在记录CDR时存在的两种根本不同的“哲学”：
- 默认行为（Default Mechanism / 追加模式）：想象一个笔记本。CHF为一次PDU会话打开一页（一个CDR），在整个会話期间，无论SMF发送多少次
[Update]请求，CHF都只是在这一页上不断追加新的内容。只有当会话结束时，这一页才算写完。 - 独立部分记录（Individual Partial Record / 快照模式）：想象一个每次都用新便签纸的习惯。在这种模式下，CHF的记录行为非常“激进”。每一次收到SMF的请求（无论是
[Initial]还是[Update]），CHF都会生成一个全新的、独立的CDR（一张新的便签纸），记录下当前时间点的信息，然后立刻关闭它。
这两种模式的选择由运营商策略决定。追加模式信令效率高，CDR数量少，但单个CDR可能非常庞大。快照模式会产生海量的CDR，但每个CDR都非常小，记录了某个精确时间点的状态快照，便于进行更实时的数据分析。在下文的讨论中，我们将主要基于更常见的“默认行为”进行解读。
2. CDR的诞生：“开卷立传” (5.2.3.2.1 General & 5.2.3.2.4 Closure)
一个CDR的生命，始于[Initial]，终于[Termination]。
A CHF CDR shall be opened when the CHF receives Charging Data Request[Initial]. When the CHF receives Charging Data Request[Termination], the charging information shall be added in the PDU session charging CHF CDR and the CDR shall be closed.
深度解析：
- 开启（Opening）：CHF收到来自SMF的
Charging Data Request[Initial]消息，是其开启一个新CDR的唯一且强制的触发条件。这个动作标志着一次计费服务的正式开始，CHF会为这个CDR分配一个唯一的记录序列号，并记录下会话的各种静态信息，如用户ID、PDU会getSession ID、DNN等。 - 关闭（Closure）：CHF收到来自SMF的
Charging Data Request[Termination]消息，是其最终关闭一个CDR的最主要的触发条件。CHF会将这个最后的消息中携带的使用量追加到CDR中，然后将CDR的状态标记为“Closed”，并填上记录关闭原因（如“用户正常释放”）。这份CDR的故事到此完结。
3. CDR的成长：“添砖加瓦” (5.2.3.2.2 Information Addition)
在CDR从开启到关闭的漫长过程中，它的内容会不断丰富。本节定义了哪些事件只会向CDR中“追加信息”，而不会改变其“Open”的状态。
规范中的**“Table 5.2.3.2.2.1: Triggers for CHF CDR charging information addition”**列出了这些触发器。
| Trigger Conditions (节选) | 适用场景 |
|---|---|
| QoS change | Converged / Offline |
| User Location change | Converged / Offline |
| Time/Volume threshold reached | Converged only |
| Time/Volume/Unit quota exhausted | Converged only |
深度解析与场景再现：
用户小杰正在进行一次长达数小时的PDU会话。
-
场景一：网络状态变化 小杰在城市中移动，手机的QoS、位置、服务小区不断变化。这些事件触发SMF发送
[Update]请求。CHF收到后，它只是将这些新的状态信息（如“时间T1，用户在小区A，QoS为X”；“时间T2，用户在小区B，QoS为Y”）以及期间的流量，作为新的条目追加到那个仍然打开的CDR里。这些是会话内部的常规状态变化，无需中断CDR的连续性。 -
场景二：在线计费的“心跳” 小杰在玩游戏，CHF为他授予了100MB的配额。当他用到80MB（达到阈值）或100MB（配额耗尽）时，SMF会发送
[Update]请求。CHF收到后，同样只是将这次的用量信息追加到CDR中，并下发新的配额。这个过程可能会在一次游戏会话中发生几十次，它们都被视为同一次服务的延续，记录在同一个CDR里。
核心逻辑：信息追加类型的触发器，对应的都是服务内在的、连续的状态演变或常规的资源交互。CHF的任务就是忠实地记录下这些“成长”的轨迹。
4. CDR的“里程碑”：部分记录关闭 (5.2.3.2.3 Partial Record Closure)
对于一次可能持续几天甚至几周的PDU会话（例如物联网设备），如果等到最后才生成一个巨大的CDR，会带来很多问题：计费处理延迟、数据丢失风险大、无法进行周期性分析。为此，3GPP引入了“部分记录关闭”（Partial Record Closure）机制，即生成阶段性话单。
When the CHF receives Charging Data Request [Update], with the change conditions identified in Table 5.2.3.2.3.1, the charging information shall be added in the PDU session charging CHF CDR, before the CDR is closed and a subsequent CHF CDR shall be opened with an incremented Sequence Number…
深度解析：
这个机制就像是在写一部长篇小说。当一个重要的章节结束时，作者会做一个阶段性的存档。
- 流程：
- 一个重大的网络事件发生（见下表）。
- SMF发送
[Update]请求，报告该事件。 - CHF收到后，执行“三步操作”： a. 将本次上报的最终信息追加到当前的CDR中。 b. 关闭（Close）当前的CDR，我们称之为“部分话单”（Partial CDR）。 c. 立刻为同一次PDU会话开启一个全新的CDR，并将内部的记录序列号（Record Sequence Number）加一。
- 关联性：所有这些属于同一次PDU会话的部分话单，会拥有相同的用户ID和Charging Identifier，但有连续递增的序列号（1, 2, 3…）。这使得后端的计费系统能够将这些“章节”重新拼接成一个完整的故事。
规范中的**“Table 5.2.3.2.3.1: Triggers for CHF CDR partial record closure”**列出了这些“重大”事件。
| Trigger Conditions (节选) | 逻辑解读 |
|---|---|
| PLMN change | 用户的计费归属发生了根本改变（漫游），必须生成一份结算清单。 |
| RAT type change | 接入网络类型发生重大变化（如5G←>4G），可能对应不同资费，需要分割。 |
| Handover complete | 一次系统间的切换完成，标志着一个网络状态的稳定结束和另一个的开始。 |
| Addition/Removal of access/UPF | PDU会话的拓扑结构发生重大改变，需要生成一个快照。 |
| Expiry of data time/volume limit per PDU session | 达到了一个会话级的总时长或总流量上限，标志着一个大的计费周期的结束。 |
核心逻辑：部分记录关闭类型的触发器，对应的都是标志着服务上下文发生重大、非连续性变化的边界事件。CHF通过生成部分话单，为这次计费服务在时间轴上打下一个个清晰的“里程碑”，确保了长周期会话计费的可管理性和及时性。
5. “国际版话单”：漫游QBC的CDR (5.2.3.3)
当用户漫游时，VPLMN的V-CHF生成的CDR，其用途、内容和触发器都与HPLMN的H-CHF有所不同。
A Roaming QBC CHF CDR is used to collect charging information related to Roaming QBC in V-SMF… QoS flow containers per PDU session can be added in the CHF CDRs… A Roaming QBC CHF CDR shall be opened when the CHF receives Charging Data Request [Initial] indicating “in-bound roamer”.
深度解析：
- 目的不同：这份CDR不是给用户出账单的，而是VPLMN用来和HPLMN进行网间结算的“对公账单”。
- 内容不同：它不关心用户用了什么App（Rating Group），而是以**QoS流（QFI）**为核心。CDR中会包含一个个“QFI容器”，详细记录了VPLMN为每个等级的QoS流分别承载了多少流量。
- 触发器不同：它的信息追加和部分关闭触发器也围绕着QBC来设计。例如，
Table 5.2.3.3.2.1和Table 5.2.3.3.3.1中，核心的触发器是QoS change、User Location change等影响承载成本的事件，而完全没有与在线计费（Quota）相关的触发器。
这个独立的漫游QBC CDR体系，再次印证了5G计费中“用户零售计费”和“网间批发结算”双轨并行、逻辑分离的精妙设计。
文章结尾
通过对5.2.3节的深度解读，我们已经完整地掌握了一份CDR从诞生到归档的全过程。我们理解了，CDR的生命周期管理并非简单的记录，而是一套由CHF主导的、事件驱动的精密机制。
- Open: 因
[Initial]而生，开启记录。 - Add: 因常规
[Update]而成长，不断追加内容。 - Partial Close: 因重大
[Update]而“立碑”，生成阶段性快照。 - Final Close: 因
[Termination]而终，完成历史使命。
我们还理解了“默认追加”和“独立快照”这两种不同的记账哲学，以及用户话单（PDU Session CDR）与结算话单（Roaming QBC CDR）在内容和逻辑上的本质区别。
至此，计费信息在核心网内部的流动与处理过程已基本清晰。在后续的文章中，我们将继续沿着数据的旅程，探索CDR是如何通过Ga和Bd接口，最终抵达计费中心，并转化成我们手机上收到的那张账单的。
FAQ环节
Q1：CDR的“信息追加”和“部分记录关闭”有什么本质区别？ A1：本质区别在于CDR的连续性。信息追加只是在当前打开的CDR上增加新的信息条目，CDR本身保持“Open”状态，序列号不变。这对应的是服务内在的连续变化。而部分记录关闭是一个“承前启后”的动作，它会先关闭当前的CDR，然后立刻为同一个P-DU会话开启一个序列号+1的新CDR。这对应的是服务上下文发生的重大边界事件。
Q2：运营商为什么需要“部分记录关闭”机制？直接等到会话结束生成一个总话单不好吗？ A2：对于可能持续数天甚至数月的长连接（如物联网设备），只在最后生成总话单会带来巨大问题：1) 计费延迟：运营商无法按天或按月进行收入核算。2) 数据丢失风险：如果CHF在会话结束前发生故障，可能会丢失长时间的计费数据。3) 系统压力：处理一个极度庞大的CDR对计费系统是巨大的挑战。部分记录关闭机制通过生成阶段性的小话单，解决了以上所有问题。
Q3：谁来决定CHF是采用“默认追加模式”还是“独立快照模式”来记录CDR？ A3：这是由运营商的策略决定的，并在CHF中进行配置。这通常取决于运营商的计费系统（BD）和大数据平台的架构。如果后端系统希望进行非常实时的计费分析，可能会倾向于采用“独立快照模式”（Individual Partial record），因为每条消息都会生成一个立即可用的CDR。如果后端系统是传统的批处理模式，则更倾向于“默认追加模式”，以减少CDR的总量和数据处理的复杂性。
Q4：CDR中的“记录序列号”（Record Sequence Number）有什么用？ A4：它的核心作用是关联部分话单。当一个PDU会话因为“部分记录关闭”机制而产生了多个Partial CDR时，这些CDR会共享同一个Charging Identifier，但会拥有连续递增的序列号（如1, 2, 3…）。后端的计费系统在处理时，就可以根据这个序列号，将这些离散的CDR按时间顺序正确地拼接起来，还原出一次完整的服务使用历史。
Q5：漫游时产生的QBC CDR，最终会发给我的归属运营商吗？
A5：是的。VPLMN的V-CHF生成的QBC CDR，经过CGF处理后，会通过运营商之间的清算系统（如DCH/FCH），以标准的文件格式（如TAP/RAP）交换给您的归-属运营商（HPLMN）。HPLMN的结算部门会依据这些文件，向VPLMN支付相应的网络使用费。这份CDR是运营商之间“亲兄弟，明算账”的凭证，但它不会直接影响您的个人手机账单内容。