好的，我们继续这场对5G计费规范的微观探索。在上一篇文章中，我们已经深度剖析了CTF（如SMF）发送给CHF的计费请求，理解了CTF是如何用一种结构化的语言来“讲述”业务故事。现在，我们将转换视角，站在计费大脑——CHF的角度，来看看它是如何“回应”这些请求的。回应不仅是对请求的确认，更是一种授权、一种指令、一种策略的下发。
深度解析 3GPP TS 32.290：7 Message contents (Part 2 - 回应的智慧：CHF的“圣旨”)
本文技术原理深度参考了3GPP TS 32.290 V18.9.0 (2025-03) Release 18规范中，关于“Table 7.2: Common Data structure of Charging Data Response”的核心内容，旨在为读者深度剖析计费响应消息的每一个信息单元（IE）及其背后的商业与技术逻辑。
如果说计费请求是前线将领（CTF）呈上的“奏折”，那么计费响应就是中央枢纽（CHF）下发的“圣旨”。这份“圣旨”不仅要对奏折中的事项做出批复（成功或失败），更重要的是，它要为前线的下一步行动提供明确的授权和指导（授予多少配额？遵循哪些新规则？）。
今天，我们将聚焦于Table 7.2，这份定义了计费数据响应通用结构的“纲领性文件”。我们将继续以智能工厂维修工程师**“老王”**的AR维护任务为背景，看看当SMF为他呈上复杂的融合计费请求后，CHF是如何用一份精妙的响应，来运筹帷幄、决胜千里的。
1. 响应的“框架”：通用数据结构概览
与请求一样，Charging Data Response也是一个标准化的JSON对象结构，被Create、Update和Release等操作的响应消息共同使用。它不仅是对请求的确认，更是CHF实施计费策略、下发控制指令的核心载体。
我们将Table 7.2中的字段，同样按逻辑功能划分为几个“章节”来解读。
2. “批复已阅”—— 事务与结果信息
响应的开篇，首先要对收到的请求给出一个明确的处理结果，并盖上“时间戳”，确保每次交互都有据可查。
-
Session Identifier(会话标识符)：如果这是对一个Create请求的响应，CHF将在这里生成并返回一个全新的、在CHF范围内唯一的会札ID。这个ID将成为后续所有交互的“档案编号”。如果这是对Update或Release的响应，CHF会原样返回请求中的Session Identifier，以示确认。 -
Invocation Timestamp(调用时间戳)：记录了CHF生成这个响应的精确时间。 -
Invocation Sequence Number(调用序列号)：CHF会原样返回请求中的序列号。这使得CTF能够将响应与之前发送的某个特定请求精确地匹配起来，尤其是在网络存在延迟和乱序的情况下。 -
Invocation Result(调用结果)：这是响应中最直接的“态度”。它是一个包含结果码和可选附加信息的结构体。- 成功: 例如
DIAMETER_SUCCESS。 - 失败: 例如
DIAMETER_CREDIT_LIMIT_REACHED（余额不足）、DIAMETER_USER_UNKNOWN（用户不存在）。Failed parameter字段还会指出是请求中的哪个参数导致了失败。
- 成功: 例如
-
Failure Handling(故障处理)：这是一个非常关键的策略下发字段。CHF可以在响应中，动态地为CTF指定当后续与CHF的通信发生故障（如超时）时，应该采取何种策略（Terminate,Continue,Retry_and_terminate）。这使得运营商可以根据用户等级、业务类型等，为不同的会话下发差异化的容错策略。
3. “这是你的令牌”—— 核心：配额授权与控制
这是在线计费和融合计费响应的核心，是CHF下发“授权令”的部分。它通过一个可重复的结构体Multiple Unit Information，来分别为请求中的不同业务（Rating Group）进行授权。
Multiple Unit Information(多单元信息)：这是一个容器，如果请求中包含了多个Multiple Unit Usage，响应中也会有一一对应的Multiple Unit Information实例。
让我们深入这个“授权书”的内部，看看它的内容。
-
Rating Group(计费组)：明确本次授权是针对哪个业务的，例如RG 1（老王的AR视频流）。 -
Result Code(结果码)：针对单个计费组的结果码。这使得CHF可以实现精细化的控制。例如，在一个融合计费请求中，CHF可以对AR业务（RG 1）返回成功，但对VoNR业务（RG 3）返回“余额不足”，从而只中断VoNR通话，而不影响核心的AR维护任务。 -
Granted Unit(授予单元)：这是配额本身。如果CTF在请求中申请了配额，CHF将在这里给出最终批复的数量。这个数量可能等于、小于甚至大于请求的数量，完全由CHF的策略决定。它同样是一个结构体，可以包含：Time(时长)Total Volume(总流量)- …等等
-
Validity Time(有效时间)：为本次授予的配额设置一个“保质期”。例如，授予1GB流量，但Validity Time设置为3600秒。如果1小时后，这1GB流量还没用完，它也会失效，CTF必须重新申请。这可以防止配额被无限期占用。 -
Time Quota Threshold/Volume Quota Threshold(时间/流量配额门限)：这是驱动再授权的核心指令。CHF在这里明确告知CTF：“我给了你1GB流量，但当剩余流量低于100MB时，你必须立刻向我汇报并申请下一个配额。” 这个门限是实现业务连续性的关键。 -
Final Unit Indication(最终单元指示 FUI)：当CHF判断这是能为该业务授予的最后一个配额时，会包含此字段。它会指示CTF在用完这个配额后，是TERMINATE（终止）、REDIRECT（重定向）还是RESTRICT_ACCESS（限制访问）。
场景应用：
SMF为老王的AR视频流（RG 1）申请了1GB流量。CHF的响应中，针对RG 1的Multiple Unit Information可能是这样的：
{
"ratingGroup": 1,
"resultCode": "DIAMETER_SUCCESS",
"grantedUnit": {
"totalVolume": 1073741824 // 1GB in bytes
},
"volumeQuotaThreshold": 104857600 // 100MB
}这份响应清晰地告诉SMF：你的请求通过了，这是1GB的令牌，油表灯在剩余100MB时会亮，到时候记得来加油！
4. “这是新的游戏规则”—— 策略与触发器下发
除了授权配额，CHF还利用响应消息，动态地向CTF下发新的“游戏规则”。
-
Triggers(触发器)：CHF可以在响应中，为CTF重新定义一套需要监控的触发器。Triggers at Session level: 在Multiple Unit Information之外，有一个全局的Triggers字段，用于定义对整个PDU会话生效的触发器（如位置变更）。Triggers at Rating Group level: 在每个Multiple Unit Information内部，也可以有独立的Triggers字段，用于定义只对特定业务生效的触发器（如QoS变更）。 CHF可以随时增加、删除或修改触发器的类型及其报告类别（立即/延迟），从而实现对计费策略的动态调整。
-
Supported Features(支持的特性)：CHF告知CTF，对于你在请求中声明支持的那些特性，我（CHF）这边也支持哪些。这是一种双向的能力确认。 -
Session Failover(会话故障转移)：CHF通过这个布尔值告知CTF，我是否支持会话故障转移。如果为true，意味着CTF可以在与当前CHF实例通信失败时，尝试将计费会话切换到一个备用的CHF实例，而会话上下文可以保持。
场景应用：
在一次Update响应中，CHF发现工厂正在进行网络升级，可能会频繁发生QoS波动。为了更精确地计费，CHF可以在响应中下发一个新的Triggers列表，将QOS_CHANGE从原来的“延迟报告”临时修改为“立即报告”。SMF收到后，就会立即采用这个新的、更严格的监控规则。
5. 完整的“圣旨”：Table 7.2全览
现在，让我们以专业的视角，审视规范中定义的完整响应表格结构。
Table 7.2: Common Data structure of Charging Data Response
| Information Element | Converged Charging Category | Offline Only Charging Category | Description |
|---|---|---|---|
| Session Identifier | Oc | Oc | 标识计费会话。 |
| Invocation Timestamp | M | M | CHF生成响应的时间戳。 |
| Invocation Result | Oc | Oc | 计费服务调用的结果（成功/失败）。 |
| … | … | … | … |
| Failure Handling | Oc | Oc | 指示当发生故障时，NF消费者应执行的故障处理行为。 |
| Invocation Sequence Number | M | M | NF消费者请求中的序列号。 |
| Session Failover | Oc | Oc | 指示是否支持对正在进行的计费会话进行故障转移。 |
| Multiple Unit Information | Oc | - | 包含配额管理和/或用量报告的信息。 |
| Result Code | Oc | - | 计费组配额分配的结果。 |
| Rating Group | OM | - | 一个计费组的标识符。 |
| Granted Unit | Oc | - | 授予的配额，作为对Requested Unit的响应。 |
| Tariff Time Change | Oc | - | 资费将发生变化的时间点。 |
| Time | Oc | - | 授予的时间量。 |
| Total Volume | Oc | - | 授予的总流量。 |
| … | … | … | … |
| Validity Time | Oc | - | 限制已授予配额有效性的时间。 |
| Final Unit Indication | Oc | - | 指示这是服务的最后一个配额。 |
| Time Quota Threshold | Oc | - | 秒级的配额门限。 |
| Volume Quota Threshold | Oc | - | 字节级的配额门限。 |
| … | … | … | … |
| Triggers | Oc | - | 与计费组相关的用量报告触发器。 |
| … | … | … | … |
| Triggers | Oc | Oc | 与计费会话相关的用量报告触发器。 |
(注：为简洁起见，表格已作精简)
总结
Charging Data Response并非一次简单的应答，它是CHF智慧的结晶，是一份包含了授权、指令、策略和预案的综合性文件。通过对Table 7.2的深度解剖，我们看到了CHF这位“指挥官”是如何通过一份响应来调度整个计费战场的：
- 结果明确：通过
Invocation Result，清晰地告知“行”或“不行”，以及“为什么不行”。 - 授权精准：通过
Multiple Unit Information，为不同的业务（Rating Group）量身定制配额（Granted Unit）、门限（Threshold）和“最终指令”（FUI）。 - 策略灵活：通过
Triggers和Failure Handling等字段，动态地向CTF下发最新的监控规则和应急预案。 - 高可用保障：通过
Session Failover等机制，为计费会话的连续性提供了架构层面的支持。
这份响应的智慧，在于它将复杂的计费策略和控制逻辑，分解为了一系列标准化的、可由机器清晰解读的信息单元，并通过一次交互，高效地传递给策略的执行者。
至此，我们已经完整地剖析了计费请求与响应这对核心的“对话”。我们不仅知道了CTF如何“说”，也知道了CHF如何“答”。在下一篇文章中，我们将继续分析Notify等特殊消息的结构，完成对5G计费“语言学”的全面探索。
FAQ - 常见问题解答
Q1：为什么Multiple Unit Information中的Rating Group字段是OM（Optional Mandatory，可选强制）？什么情况下可以不带这个字段？
A1：这是一个非常细节但重要的问题。Rating Group在Multiple Unit Information中通常是强制的，因为它需要明确地与请求中的某个Multiple Unit Usage对应。但在一个特殊场景下可以省略：当一个PDU会话中只有一个计费组时。在这种“单一业务”的简单场景下，请求和响应都只有一个Multiple Unit ...结构，此时Rating Group字段可以省略，双方默认该信息适用于唯一的那个计费组。这是一种为了简化信令而做的优化。
Q2：CHF授予的配额（Granted Unit）可以比CTF请求的（Requested Unit）更多或更少吗？
A2：完全可以。CHF拥有最终的决定权。
- 少于请求：最常见的情况。例如，用户余额只够支付500MB的费用，但SMF请求了1GB，CHF就会只授予500MB。
- 等于请求：常规情况，用户信用良好，策略允许。
- 多于请求：也可能发生。例如，为了减少信令交互，对于一个非常稳定的长连接业务（如物联网），即使SMF每次只申请10MB，CHF的策略也可能一次性授予100MB，并设置一个合适的门限，以降低计费系统的交互频率。
Q3：Tariff Time Change字段是做什么用的？
A3：Tariff Time Change（资费时间变更）用于处理预付费用户的资费切换场景。例如，一个套餐在晚上11点后流量单价会减半。当用户的一个计费会话跨越了晚上11点这个时间点，CHF可以在Update响应的Granted Unit中包含这个字段，例如："tariffTimeChange": "2025-10-06T23:00:00Z"。这等于告诉SMF：“你当前的配额在23点整会失效，届时你必须立即发起一次Update，我会根据新的夜间费率给你批复新配额。” 这确保了资费的精确切换。
Q4：Quota Holding Time字段有什么作用？
A4：Quota Holding Time（配额持有时间）是一个用于防止CTF“失联”后配额被无限期占用的安全机制。假设CHF授予了SMF一个配额，并设置了Quota Holding Time为300秒。如果CHF在300秒内没有收到来自这个SMF的任何Update或Release消息，CHF就可以单方面认定该会话已异常中断，并主动释放为该配额预留的资源。这在CTF崩溃且无法正常释放会话的场景下非常有用，可以避免账户资金被“死锁”。
Q5：Charging Notify Request和Charging Notify Response的消息结构是怎样的？
A5：根据Table 7.3和Table 7.4，它们的消息结构相对简单：
Charging Notify Request(CHF → CTF): 核心字段是Notify URI（之前CTF提供的回调地址）、Notification type（Re-authorization 或 Termination）、以及可选的Service Identifier/Rating Group来指定通知的范围。Charging Notify Response(CTF → CHF): 这是一个非常简单的确认响应，核心字段只有一个Invocation Result，用于告知CHF通知已收到，成功或失败。它不包含任何业务数据。