好的，我们立即开始下一篇规范的深度解读。
在前几章中，我们已经完整地追踪了计费信息在网络功能实体（NF）之间流动的“路径”和“时机”。现在，我们将深入到这些流动的“货物”本身——计费数据——的内部结构中。我们将像一位语言学家一样，逐一解析构成5G计费“语言”的每一个“单词”和“语法”，理解它们的确切含义和用途。
由于第6章内容极其丰富，是整个计费规范的数据字典，我们将首先聚焦于6.1节，并对其进行一次完整的、系统性的解读。在开始之前，我们先快速回顾并收尾5.2节的最后两个小节。
深度解析 3GPP TS 32.255：6.1 5G数据连接计费的数据描述 (Data description)
本文技术原理深度参考了3GPP TS 32.255 V18.6.0 (2024-12) Release 18规范中，关于“6.1 Data description for 5G data connectivity charging”的核心章节，旨在为读者提供一份关于5G计费消息和CDR内容的详尽“数据字典”，全面解析其中每一个关键信息元素的含义与作用。
承前启后：计费数据的“物流”之旅 (5.2.4 & 5.2.5 简述)
在深入数据内容之前，我们先完成数据“物流”的最后两站。5.2.3节告诉我们，CDR在CHF中诞生。那么，它如何被送往最终目的地——计费中心（BD）呢？
- 5.2.4 Ga record transfer flows：定义了CHF（作为CDF）如何将一条条生成的CDR实时或准实时地传送给计费网关（CGF）。这条“传送带”就是
Ga接口。它保证了CDR能够被及时地从网络中收集起来。 - 5.2.5 Bd CDR file transfer：定义了CGF在收集了足够多的CDR后，如何将它们打包成标准格式的话单文件（File），并通过
Bd接口（通常是FTP/SFTP）批量发送给计费域（BD）。这是CDR数据进入后台处理系统的“最后一公里”。
简单来说，Ga是记录（Record）的传输，Bd是文件（File）的传输。 完成了这两步，计费数据的“旅程”才算完整。现在，让我们打开这些数据“包裹”，看看里面到底装了什么。
引言：计费“福尔摩斯”的案件卷宗
为了让枯燥的数据字段变得生动，我们引入一位新角色：运营商计费稽核部门的资深专家，“李探长”。他接到一个棘手的投诉：用户小杰声称自己上个月的“云游戏加速包”被多收了费。李探长的任务，就是通过分析SMF与CHF之间捕获的计费消息，以及最终生成的CDR，来还原事实真相，找出问题的根源。他手上的这些消息和记录，就是本章要解读的核心内容。
1. 计费交互的“信封”：消息内容概览 (6.1.1 Message contents)
The Charging Data Request and Charging Data Response are specified in TS 32.290 and include charging information. The Charging Data Request can be of type [Initial, Update, Termination].
李探长拿到的第一份证物，是SMF和CHF之间的一系列交互报文。这些报文就像一个个信封，外面标明了是Charging Data Request（SMF发给CHF的请求）还是Charging Data Response（CHF的回应），以及信件类型是[Initial]、[Update]还是[Termination]。
Table 6.1.1.1.1: Converged charging messages reference table
| Message | Source | Destination |
|---|---|---|
| Charging Data Request | SMF, CHF | CHF |
| Charging Data Response | CHF | SMF, CHF |
深度解析：这张表告诉我们，Request消息的发起方主要是SMF，但在高级的Inter-CHF交互中，一个CHF（如V-CHF）也可以向另一个CHF（如H-CHF）发起请求。而Response消息的发起方永远是CHF。李探长的任务，就是拆开这些“信封”，仔细检查里面的内容。
2. SMF的“呈堂证供”：Charging Data Request消息详解 (6.1.1.2)
李探长首先打开了SMF发给CHF的Charging Data Request消息。这是整个案件最原始、最关键的证据。规范中的**“Table 6.1.1.2.1: Charging Data Request message contents”**详细列出了这份“证供”的构成。我们将其分为几个逻辑部分来解读。
第一部分：案件基本信息 (Session & Subscriber Info)
| Information Element | Category (Conv.) | Description |
|---|---|---|
| Session Identifier | OC | 会话标识符 |
| Subscriber Identifier | OM | 用户标识符 (SUPI) |
| Tenant Identifier | OC | 租户标识符 |
- 李探长的分析：这是卷宗的首页。“Subscriber Identifier”告诉他这起案件的主角是小杰（通过SUPI识别）。“Session Identifier”则是CHF为这次计费会话分配的内部ID，用于关联后续的所有
Update和Termination消息。“Tenant Identifier”则用于B2B场景，如果小杰正在使用的是公司购买的网络切片，这里就会填上他公司的ID。
第二部分：报案人信息 (NF Consumer Info)
| Information Element | Category (Conv.) | Description |
|---|---|---|
| NF Consumer Identification | M | 发起请求的网络功能信息 |
| … (NF Name, Address, etc.) | OC | … |
| Invocation Timestamp | M | 请求发起的时间戳 |
- 李探长的分析：这部分记录了“报案人”——SMF——的详细信息，包括它的身份、地址、所在网络（PLMN ID）等。
Invocation Timestamp则精确记录了“报案”时间。这些信息对于故障定位和多SMF场景下的问题追溯至关重要。
第三部分：核心诉求 - 用量汇报与配额申请 (Usage & Quota Info)
这是消息的核心内容，直接关系到小杰的费用问题。
| Information Element | Category (Conv.) | Description |
|---|---|---|
| Multiple Unit Usage | OC | 多单元使用量 |
| ├─ Rating Group | M | 评级组 (e.g., 云游戏) |
| ├─ Used Unit Container | OC | 已使用单元容器 |
| │ ├─ Service Identifier | OC | 业务标识符 |
| │ ├─ Quota management Indicator | OC | 配额管理指示 |
| │ ├─ Triggers | OC | 触发器 |
| │ ├─ Uplink/Downlink Volume | OC | 上下行流量 |
| ├─ Requested Unit | OC | 请求的单元 (申请配额) |
| PDU Container Information | OC | PDU容器信息 |
- 李探长的分析：
- 李探长在一条
[Update]消息的Multiple Unit Usage部分找到了关键证据。 - 他看到了一个
Rating Group为“CloudGaming”的条目。 - 在
Used Unit Container中，他发现Uplink Volume为10MB，Downlink Volume为150MB，这记录了小杰从上次报告到现在，玩游戏实际消耗的流量。Triggers字段显示，这次上报的原因是“quotaExhausted”（配额耗尽）。 - 紧接着，在
Requested Unit部分，他看到了SMF正在为这个Rating Group申请新的一笔配额。 PDU Container Information则包含了更丰富的业务上下文，比如这次计费的业务是在哪个RAT类型、哪个位置发生的。
- 李探长在一条
第四部分：完整的现场快照 (PDU Session Context)
除了核心的用量，Request消息还携带了大量描述PDU会话当前状态的上下文信息。
| Information Element | Category (Conv.) | Description |
|---|---|---|
| PDU Session Charging Information | OM | PDU会話计费信息 (核心) |
| ├─ Charging Id | OM | 计费ID |
| ├─ User Location Info | OC | 用户位置信息 |
| ├─ Network Slice Instance Identifier | OM | 网络切片实例标识符 (S-NSSAI) |
| ├─ RAT Type | OC | 无线接入技术类型 |
| ├─ Data Network Name Identifier | M | DNN |
| … | … | … |
| Roaming QBC information | OM | 漫游QBC信息 |
- 李探长的分析：这部分就像是案件的“现场照片”，提供了完整的上下文。李探长通过
PDU Session Charging Information，可以了解到：Charging Id确认了这属于小杰的哪一次上网过程。User Location Info和RAT Type告诉他，这笔费用发生在5G网络下的“中央商务区”基站。S-NSSAI显示，小杰正在使用运营商为“云游戏”专门优化的高性能网络切片。Roaming QBC information字段的存在与否，可以让他判断这是否是一次漫游会话。
3. CHF的“判决书”：Charging Data Response消息详解 (6.1.1.3)
李探长接着分析CHF的回应消息。这是CHF对SMF请求的“判决”，直接决定了网络下一步的行为。规范中的**“Table 6.1.1.3.1: Charging Data Response message contents”**列出了其详细结构。
第一部分：判决结果 (Invocation Result)
| Information Element | Category (Conv.) | Description |
|---|---|---|
| Invocation Result Code | OC | 调用结果码 (成功/失败) |
| Failed Parameter | OC | 失败参数 |
- 李探长的分析：这是“判决书”的结论。如果
Result Code显示成功，说明请求被正常处理。如果失败，Failed Parameter会告诉SMF具体是哪个参数出了问题，便于快速定位。
第二部分：配额授权与指令 (Granted Quota & Instructions)
| Information Element | Category (Conv.) | Description |
|---|---|---|
| Multiple Unit Information | OC | 多单元信息 |
| ├─ Rating Group | M | 评级组 |
| ├─ Granted Unit | OC | 授予的单元 (下发配额) |
| │ ├─ Time / Total Volume | OC | 时长/流量配额 |
| ├─ Final Unit Indication | OC | 最终单元指示 |
| ├─ Triggers | OC | 下发的触发器 |
- 李探长的分析：
- 李探长在CHF的响应中，找到了针对“CloudGaming”这个
Rating Group的Multiple Unit Information。 - 在
Granted Unit中，他看到CHF新授予了200MB的流量配额。 Final Unit Indication字段如果存在，则表明这是最后一笔配额，耗尽后将执行终止行为。- 最关键的是
Triggers字段。李探长发现，CHF在这里下发了一个新的触发器：“当用户位置进入‘家庭宽带优惠区’时，立即报告”。这表明CHF的策略是动态的，它会根据用户行为调整SMF的监控策略。
- 李探长在CHF的响应中，找到了针对“CloudGaming”这个
4. 最终的“结案陈词”：CDR内容详解 (6.1.3)
在分析完所有交互消息后，李探长调取了这次PDU会话最终生成的CDR。这份由CHF精心撰写的“结案报告”，汇总了整个会话期间的所有关键信息。规范中的**“Table 6.1.3.2.1: PDU session charging CHF record data”**定义了它的结构。
| Information Element | Category | Description |
|---|---|---|
| Record Type | M | 记录类型 (CHF record) |
| Subscriber Identifier | OM | 用户标识符 |
| NF Consumer Information | M | SMF信息 |
| List of Multiple Unit Usage | OM | 所有用量变化的列表 |
| Record Opening Time | M | 记录打开时间 |
| Duration | M | 记录总时长 |
| Record Sequence Number | C | 记录序列号 (用于部分话单) |
| Cause for Record Closing | M | 记录关闭原因 |
| Record Extensions | OC | 记录扩展 |
- 李探长的最终分析：
- CDR就像是本次计费案件的完整卷宗。它包含了小杰的身份、服务他的SMF信息。
List of Multiple Unit Usage字段最为庞大，它是一个列表，详细记录了在整个会话期间，每一次[Update]交互上报的用量信息，以及每次变化发生的时间、地点、原因等。李探长可以像看电影回放一样，追溯小杰的完整使用轨迹。Record Opening Time和Duration记录了这次服务的起止时间。Record Sequence Number的存在，让他可以判断这是否是一份部分话单，并能找到它的“前篇”和“后篇”。Cause for Record Closing字段最终告诉他，这次会话是因为“用户正常释放”而结束的。
通过对这份CDR的完整分析，李探长最终发现，是由于小杰在一次SSC Mode 3切换中，新旧SMF之间的上下文传递出现了微小偏差，导致一小部分游戏流量被错误地计入了通用流量的Rating Group。案件告破！
文章结尾
通过扮演“李探长”的角色，我们对6.1节所定义的5G计费数据结构进行了一次彻底的“勘查”。我们理解了，计费的精确性，源于其数据结构的严谨性。
- Charging Data Request是SMF提交的、包含丰富现场上下文的“证据”。
- Charging Data Response是CHF下发的、包含授权和新指令的“判决”。
- CDR是CHF最终生成的、记录了案件全过程的、不可篡改的“历史档案”。
掌握了这份“数据字典”，我们才算真正掌握了5G计费的语言。在接下来的文章中，我们将继续深入第6章的后续部分，探索在更复杂的场景下（如漫游、互操作），这些数据结构会发生哪些有趣的扩展和变化。
FAQ环节
Q1：Charging Data Request/Response消息和CDR有什么区别？
A1：它们是过程和结果的关系。Charging Data Request/Response是SMF和CHF之间在会话过程中的实时交互消息，用于报告用量、申请配额和传递指令，是动态的、过程性的。而CDR是由CHF生成的最终产物，它汇总了整个计费会话期间所有交互的关键信息，形成一份静态的、完整的、用于事后审计和出账的记录。
Q2：在这些表格中，“Category”列的M, O, C代表什么？为什么这么重要？
A2：它们代表了字段的强制性等级：**M (Mandatory)**表示该字段必须存在；**O (Optional)**表示该字段可选；**C (Conditional)**表示该字段在特定条件下必须存在。这对于设备开发和互联互通至关重要。例如，Subscriber Identifier在正常会话中是M，但在紧急会话中可能是O。遵循这些规则，才能保证不同厂商的SMF和CHF能够正确地“对话”。
Q3：PDU Session Charging Information和PDU Container Information看起来很像，有什么区别？
A3：PDU Session Charging Information包含的是描述整个PDU会话的、相对静态的属性，如PDU Session ID、DNN、S-NSSAI等，这些信息在会话生命周期内通常不変。而PDU Container Information（作为Used Unit Container的一部分）包含的是描述某一段具体使用量发生时的动态上下文，如这段流量发生时的RAT类型、用户位置、业务流的QoS等。前者是“户口本”，后者是“事件快照”。
Q4：为什么计费消息中需要包含如此详细的NF（网络功能）信息，比如SMF的名字、地址？ A4：这主要是为了可追溯性（Traceability）和故障定位。在一个大型运营商网络中，可能有成百上千个SMF实例。当计费出现问题时，详细的NF信息可以帮助运维人员快速定位到是哪个具体的SMF实例上报的数据有误。在复杂的分布式或漫游场景下，这些信息更是还原完整信令链路、诊断问题的关键。
Q5：CHF生成的CDR最终去了哪里？它和我的手机账单是什么关系？ A5：CHF生成的CDR会经过CGF（计费网关）的收集和打包，最终以话单文件的形式发送到运营商的计费域（BD）。在BD中，这些原始、详细的CDR会经过一系列后台系统的处理，包括：批价（根据您的套餐，为每一条记录计算费用）、合帐（将您名下所有服务的费用合并）、出账（生成您最终看到的账单）。所以，CDR是您手机账单最原始的数据源。