好的，我们正式进入规范的微观世界。在前几章中，我们已经从宏观上理解了5G计费的场景、服务和框架。现在，我们将拿起“手术刀”，解剖构成这一切的基础——消息体本身。这就像我们已经欣赏了一部精彩的电影，现在要去分析它的剧本，看看每一个词、每一个标点是如何共同构建出宏大叙事的。
由于第7章内容极其详尽，我们将遵循“长章节拆分”的原则，将其分为几篇文章。本文将专注于整个计费交互的“开场白”——计费数据请求（Charging Data Request）的结构。
深度解析 3GPP TS 32.290：7 Message contents (Part 1 - 请求的艺术：CTF的“独白”)
本文技术原理深度参考了3GPP TS 32.290 V18.9.0 (2025-03) Release 18规范中，关于“Table 7.1: Common Data structure of Charging Data Request”的核心内容，旨在为读者深度剖析计费请求消息的每一个信息单元（IE）及其背后的逻辑。
欢迎来到5G计费的“DNA测序”实验室。到目前为止，我们已经知道CTF（如SMF）会向CHF发送Create、Update和Release等请求，但这些请求的“信封”里究竟装着什么样的“信”？CTF是如何用一种标准化的、滴水不漏的“语言”，向CHF讲述一个用户业务的完整故事的？
答案就藏在本章的表格中。今天，我们将聚焦于Table 7.1，这份定义了计费数据请求通用结构的“天书”。为了让这份“天书”变得生动可读，我们的主角是一位在未来智能工厂工作的资深维修工程师——“老王”。他正佩戴着5G AR头盔，对一条复杂的自动化生产线进行维护。他的一举一动，都将转化为计费请求中一个个精确的数据字段。
1. 请求的“剧本”：通用数据结构概览
在5G服务化架构（SBA）中，所有通信都基于HTTP/2和JSON。我们即将分析的Table 7.1，本质上就是一个JSON对象的数据结构定义。这个结构被Create、Update和Release等操作共同使用，形成了一个统一的“请求模板”。
老王的AR维护任务是一个典型的融合计费场景，他的PDU会话中同时承载着多种业务：
- 业务A（在线计费）：AR头盔的高清视频流和实时3D模型渲染，需要超低时延和高带宽，必须进行实时配额管理。
- 业务B（离线计费）：生产线传感器数据的后台同步，流量不大，对时延不敏感，只需事后记账。
- 业务C（在线计费）：与远在德国的总工程师进行的VoNR高清语音通话。
现在，当SMF为老王的这个复杂会话发起计费请求时，它究竟是如何组织语言的呢？我们将Table 7.1中的字段，按逻辑功能划分为几个“段落”来解读。
2. “我是谁，我在哪？”—— 身份与会话信息
计费请求的第一段，必须清晰地回答最基本的问题：这是关于“谁”的、“哪个”会话，以及作为请求方的“我”又是谁。
-
Session Identifier(会话标识符)：这是一个由CHF在响应Create请求时生成的唯一ID。在后续的所有Update和Release请求中，SMF都必须带上这个ID。它就像是这次AR维护任务在计费系统中的“档案编号”，确保所有相关的报告都能被归档到同一个地方。 -
Subscriber Identifier(用户标识符)：这明确了服务的使用者，也就是老王。它通常是SUPI或GPSI。这是CHF进行用户账户匹配和策略查询的根本依据。 -
Tenant Identifier(租户标识符)：这是一个面向企业客户（2B）的重要字段。老王是智能工厂的员工，这个字段将标识出“智能工厂”这个商业实体。这使得运营商可以为整个工厂进行统一出账，而不是为老王个人。 -
NF Consumer Identification(NF消费者标识)：这是请求方SMF的“自报家门”。它是一个结构体，包含了NF Functionality(功能，如SM-Service)、NF Name(唯一实例名，如UUID)、NF Address(IP地址/FQDN) 和NF PLMN ID(所属运营商网络)。这使得CHF不仅知道“谁在用服务”，还知道“谁在为他记账”，对于问题定位和网络管理至关重要。 -
Charging Identifier(计费标识符)：这个ID由SMF生成，用于在CTF和CHF之间关联计费信息。它与Session Identifier的主要区别在于生成方不同，且在某些特定场景下（如[Initial]请求重试时），它可以帮助CHF识别重复请求。
3. “何时，为何事而来？”—— 事务与触发信息
第二段内容，是关于本次通信本身的元数据，它解释了这次请求发生的时间、原因以及可靠性保障机制。
-
Invocation Timestamp(调用时间戳)：记录了SMF生成这个请求的精确时间。这是所有计费和审计的基础。 -
Invocation Sequence Number(调用序列号)：这是保证消息顺序和防止重复处理的“生命线”。从Create请求开始（序列号通常为0或1），每次SMF发送新的Update或Release请求，这个序列号都会递增。CHF会严格检查这个序列号，如果收到了一个已经处理过的序列号，就会忽略它。 -
Retransmission Indicator(重传指示器)：一个布尔值。如果SM-F因为超时而重传一个请求，它会将此位置为true。这明确告知CHF：“你可能已经见过这个请求了，请注意查重。” -
Triggers(触发器)：这是一个非常丰富的字段，它直接回答了“为何而来”的问题。它是一个数组，可以包含多个触发事件。- 场景A（QoS变化）: 老王的AR应用需要渲染一个极其复杂的3D模型，PCF下发策略提升了其QoS。SMF会立刻发起
Update请求，Triggers字段中会包含QOS_CHANGE。 - 场景B（配额门限）: 老王的AR视频流用完了90%的配额，SMF发起
Update请求，Triggers字段会包含QUOTA_THRESHOLD。 - 场景C（位置变更）: 老王从工厂的A车间走到了B车间，UE上报了新的位置。
Triggers字段会包含USER_LOCATION_CHANGE。 通过这个字段，CHF可以清晰地了解导致这次计费上报的上下文，从而应用正确的计费逻辑。
- 场景A（QoS变化）: 老王的AR应用需要渲染一个极其复杂的3D模型，PCF下发策略提升了其QoS。SMF会立刻发起
4. “我用了什么，我还想要什么？”—— 核心：用量与配额
这是计费请求的核心，是“信”的正文。它通过一个可重复的结构体Multiple Unit Usage，来分别描述不同业务的使用情况。
Multiple Unit Usage(多单元使用量)：这是一个容器，可以出现多次。在老王的场景中，SMF会为业务A（AR）、业务B（传感器）和业务C（VoNR）分别填充一个Multiple Unit Usage实例。
让我们深入这个“容器”内部，看看它的精妙结构。
-
Rating Group(计費组)：每个Multiple Unit Usage的唯一标识，例如RG 1对应AR，RG 2对应传感器，RG 3对应VoNR。这是CHF区分不同业务、应用不同费率和策略的基础。 -
Requested Unit(请求单元)：只在需要在线计费的业务中出现。当SMF为AR业务（RG 1）上报用量时，会在这里填写它希望获得的下一个配额，例如：“请再给我1GB流量”。而为传感器业务（RG 2，离线计费）上报时，这个字段会留空。 -
Used Unit Container(已使用单元容器)：这是对上一个计费周期用量的详细报告。它本身也是一个复杂的结构体：Time/Total Volume/Uplink Volume/Downlink Volume: 分别报告了使用的时长和流量。Triggers/Trigger Timestamp: 再次声明是哪个触发器，在什么时间，导致了这个用量报告的生成。Quota management Indicator(配额管理指示器): 这是一个至关重要的枚举值，明确告知CHF本次上报的用量是在何种模式下产生的。ONLINE_CHARGING: 表示这是在线计费模式下的用量，例如老王的AR视频流。OFFLINE_CHARGING: 表示这是离线计费模式下的用量，例如传感器数据。QUOTA_MANAGEMENT_SUSPENDED: 表示这是在配额管理被临时挂起期间产生的用量。
通过Rating Group的区分，以及Requested Unit和Quota management Indicator字段的灵活使用，SMF可以在一个Charging Data Request消息中，完美地向CHF描述清楚老王这个融合了多种计费模式的复杂业务场景。
5. 其他信息
请求的最后，还包含了一些用于特定场景和提供附加信息的字段。
One-time Event/One-time Event Type: 用于非会话类的一次性事件计费。Supported Features: SMF向CHF声明自己支持哪些可选的计费特性。这是一种能力协商机制。Service Specification Information: 提供本次请求遵循的3GPP规范版本信息，主要用于信息和调试目的。
6. 完整的“剧本”：Table 7.1全览
现在，我们已经将请求的“剧本”按段落拆解完毕。让我们以专业的视角，审视规范中定义的完整表格结构。
Table 7.1: Common Data structure of Charging Data Request
| Information Element | Converged Charging Category | Offline Only Charging Category | Description |
|---|---|---|---|
| Session Identifier | Oc | Oc | 标识计费会话。 |
| Subscriber Identifier | Oc | OM | 标识使用服务的个人用户。 |
| Tenant Identifier | Oc | - | 标识使用服务的商业用户（租户）。 |
| NF Consumer Identification | M | M | 标识计费服务的消费者NF。 |
| … (sub-fields) | … | … | … |
| Charging Identifier | OM | - | 允许关联计费信息的标识符。 |
| Invocation Timestamp | M | M | NF消费者发起服务调用的时间戳。 |
| Invocation Sequence Number | M | M | 一次计费会话中服务调用的序列号。 |
| Retransmission Indicator | Oc | Oc | 指示该消息是否为重传。 |
| One-time Event | Oc | - | 指示这是事件计费。 |
| One-time Event Type | Oc | - | 指示一次性事件的类型（立即或事后）。 |
| … | … | … | … |
| Triggers | Oc | Oc | 标识触发请求的事件。 |
| Multiple Unit Usage | Oc | Oc | 包含配额管理请求和/或用量报告的参数。 |
| Rating Group | M | M | 标识一个计费组。 |
| Requested Unit | Oc | - | 指示需要配额管理，并包含请求的服务单元数量。 |
| Time | Oc | - | 请求的时间量。 |
| Total Volume | Oc | - | 请求的总流量（双向）。 |
| … | … | … | … |
| Used Unit Container | Oc | Oc | 包含已使用的非货币服务单元数量。 |
| Triggers | Oc | Oc | 本次用量报告的原因。 |
| Trigger Timestamp | Oc | Oc | 触发器的时间戳。 |
| Time | Oc | Oc | 已使用的时间量。 |
| Total Volume | Oc | Oc | 已使用的总流量。 |
| … | … | … | … |
| Quota management Indicator | Oc | - | 指示上报的用量是否在配额管理控制下。 |
| … | … | … | … |
(注：为简洁起见，表格已作精简，M表示强制，O表示可选，c表示有条件，M/c下标表示适用性)
总结
通过对Table 7.1的深度解剖，我们发现，一个计费请求远不止是简单的数字上报。它是一份高度结构化、信息极其丰富的“独白”，由CTF（SMF）这位“一线记者”，向CHF这位“总编辑”生动地讲述着一个用户业务的完整故事。
这份“独白”逻辑严谨，层次分明：
- 开场：清晰交代了人物（Subscriber）、事件（Session）和讲述者（NF Consumer）。
- 上下文：阐明了时间（Timestamp）、动机（Triggers）和可靠性保障（Sequence Number）。
- 核心情节：通过可重复的
Multiple Unit Usage结构，为不同业务线（Rating Group）分别叙事，精准地区分了在线计费的“预支与偿还”（Requested Unit&Used Unit）和离线计费的“纯粹记录”。
正是这份“剧本”的精妙设计，使得5G计费系统能够从容应对从个人娱乐到工业生产的各种复杂场景。现在，我们已经完全理解了CTF的“诉求”。在下一篇文章中，我们将切换视角，看看CHF这位“总编辑”是如何回复的，共同解读Charging Data Response的奥秘。
FAQ - 常见问题解答
Q1：为什么在请求中需要那么多不同的标识符，如Session Identifier、Subscriber Identifier和Charging Identifier？
A1：这些标识符在计费系统中扮演着不同层次的“钥匙”角色，缺一不可。
Subscriber Identifier(如SUPI) 是用户维度的钥匙，用于关联到用户的账户、套餐和策略。Session Identifier是业务会话维度的钥匙，由CHF生成，用于将一个持续业务（如PDU会话）的所有Update和Release操作关联在一起。Charging Identifier是CTF侧会话维度的钥匙，由CTF生成，主要用于辅助关联和在某些初始请求的异常场景（如重试）下帮助CHF进行去重。 它们共同构建了一个立体化的关联体系，确保了计费的准确无误。
Q2：Requested Unit和Used Unit Container这两个结构最核心的区别是什么？
A2：它们代表了计费交互中两个相反方向的动作：“索取”与“汇报”。
Requested Unit是CTF向CHF的**“索取”，代表“为了接下来的业务，我想要**多少资源？”。它是在线计费的核心，用于申请配额。Used Unit Container是CTF向CHF的**“汇报”，代表“从上次通信到现在，我已经用掉**了多少资源？”。它是在线和离线计费都需要的部分，用于报告用量。在一个典型的在线计费Update请求中，这两个字段通常会同时出现。
Q3：Invocation Sequence Number（调用序列号）是如何工作的？
A3：它是一个在单个计费会话中单调递增的计数器。会话的第一个请求（通常是Create）序列号为N，后续的Update或Release请求的序列号依次为N+1, N+2, N+3… CHF会记录下当前会话已成功处理的最高序列号。如果它收到一个序列号小于或等于已记录最高值的请求，就判定其为重复或过时的消息，并予以忽略。这是一种简单而高效的机制，用于保证消息在传输层之外的应用层面的有序性和幂等性。
Q4：一个Charging Data Request消息可以同时包含在线和离线计费业务的信息吗？
A4：可以，这正是融合计费的强大之处。通过使用多个Multiple Unit Usage信息单元来实现。例如，SMF可以为老王的AR视频流（在线）构建一个Multiple Unit Usage，其中包含Rating Group=1, Requested Unit和Used Unit Container（Quota management Indicator设为ONLINE）；同时为后台传感器数据（离线）构建另一个Multiple Unit Usage，其中包含Rating Group=2, 没有Requested Unit，只有Used Unit Container（Quota management Indicator设为OFFLINE）。这两个结构会放在同一个Charging Data Request消息中发送。
Q5：决定一个业务流（Service Data Flow）属于哪个Rating Group，并采用何种计费模式（在线/离线）的，是SMF自己吗？
A5：不是SMF自己决定的。这个决策权属于策略控制功能PCF (Policy Control Function)。在PDU会话建立或修改时，PCF会根据用户的签约信息、网络策略、以及所请求的应用等，生成一套PCC（Policy and Charging Control）规则下发给SMF。这些规则中会明确定义：何种数据流（通过SDF模板识别）应该被映射到哪个Rating Group，以及这个Rating Group应该采用在线计费还是离线计费。SMF是这些策略的执行者，它根据PCF的指令来填充Charging Data Request中的相应字段。