非常好，我们继续这场穿越3GPP规范的深度探索之旅。在前几章中，我们已经见证了5G计费系统在理想状态下的完美运作。但现实世界充满了不确定性，网络会抖动，服务器会宕机，消息会丢失。一个真正强大的系统，不仅在于它平时能做什么，更在于它在“逆境”中如何自处。本章，我们将深入探讨5G计费的“免疫系统”——**错误处理（Error Handling）**机制。

深度解析 3GPP TS 32.290：5.5 Error handling (错误处理机制)

本文技术原理深度参考了3GPP TS 32.290 V18.9.0 (2025-03) Release 18规范中，关于“5.5 Error handling”的核心章节，旨在为读者提供一个关于5G计费系统鲁棒性与弹性的全景视图。

我们已经了解了离线、在线和融合计费的宏伟架构，以及各种精细化的控制功能。但所有这些都建立在一个假设之上：通信是可靠的。当这个假设被打破时会发生什么？CTF（如SMF）向CHF发送的计费请求超时了怎么办？CHF收到了一个意料之外的消息又该如何应对？本章内容，正是解答这些关键问题的“应急预案手册”。

为了让这些看似枯燥的错误处理流程变得惊心动魄，今天我们的主角是**“智驾-01”**，一辆先进的L4级自动驾驶出租车。它正载着一位贵宾穿梭于城市，其导航、感知、决策系统都高度依赖5G网络提供的多种服务，例如高精地图实时更新（在线计费）、乘客信息娱乐（融合计费）以及车辆遥测数据上报（离线计费）。对于“智驾-01”而言，任何因计费系统故障导致的服务中断都可能是灾难性的。因此，它的计费交互过程，必须具备顶级的容错能力。

1. 故障处理 (Failure handling): 系统韧性的第一道防线

故障处理机制定义了当通信的一方（CTF或CHF）检测到严重错误（如对端不可达）时，应该采取的宏观策略。

1.1 CTF检测到的故障 (CTF detected failure): 前线的决断

作为计费交互的发起者，CTF（通常是SMF）是第一个能感知到CHF“失联”的角色。当它发送计费请求后，在预设的时间内没有收到任何响应（请求超时），故障就发生了。

5.5.1.1 CTF detected failure The failure handling determines what to do if the sending of charging data request to the CHF… without response in a period of time (request times out). In the case of the NF consumer (CTF) towards CHF request times out, NF consumer (CTF) uses application level failure handling (Terminate, Continue, Retry_and_terminate). Failure handling may be received from the CHF previously or may be locally configured.

规范为CTF提供了三种应急预案，这三种预案的选择，体现了用户体验与运营商风险之间的权衡。

场景：“智驾-01”的SMF正在为其高精地图更新服务（一项在线计费业务）申请下一个流量配额，但请求超时，主用CHF似乎不可达。SMF必须立刻做出决断：

1. Terminate (终止)：最保守、对运营商最安全的策略。一旦计费链路中断，立即终止相关服务。对于“智驾-01”，这意味着高精地图更新服务会被立刻停止。车辆可能会降级到依赖本地缓存地图的模式，虽然牺牲了最新的实时路况，但确保了不会产生无法计费的流量，避免了运营商的损失。

2. Continue (继续)：最大胆、用户体验最好的策略。即使计费链路中断，SMF仍允许服务继续运行一段时间。在此期间，SMF会像一个离线计费节点一样，在本地缓存所有产生的计费信息。它“赌”计费链路很快会恢复，届时再将缓存的数据一并上报。对于“智驾-01”，这意味着乘客几乎感觉不到任何异常，高精地图继续更新。但如果CHF长时间无法恢复，运营商将承担这段时间的流量成本。

3. Retry_and_terminate (重试并终止)：最常见、最均衡的策略。它结合了高可用性设计。SMF首先会尝试将计费请求发送给一个备用CHF。这种主备关系通常通过网络中的NRF（网络功能仓库功能）发现和配置。如果连接备用CHF也失败了，SMF才会选择终止服务。这是兼顾了服务连续性和风险控制的理想方案。

这个关键的故障处理策略，可以由CHF在之前的计费响应中动态下发给CTF，也可以在CTF上进行本地静态配置。CHF下发的动态策略优先级更高。

1.2 CHF检测到的故障 (CHF detected failure): 大脑的自愈

CHF作为计费系统的核心，也可能会检测到来自CTF的异常。

5.5.1.2 CHF detected failure The CHF closes a CDR and all the reserved resources are freed for the charging session when it detects that expected charging data request for a particular session have not been received for a period of time.

• “心跳”超时：对于一个活跃的在线计费会话，CHF期望能周期性地收到CTF的[Update]请求。如果CHF在远超预期的时间内（例如，几倍的配额有效期）都没有收到任何消息，它会认为CTF或UE已经异常离线。为了防止资源泄露（例如，预留的资金被永久冻结），CHF会主动关闭这个会话的CDR，释放所有相关资源。

此外，CHF还具备处理消息乱序或丢失的强大能力，展现了其设计的鲁棒性：

• 重复的[Initial]：一个会话已经建立，但CHF又收到了一个针对此会话的[Initial]请求（可能是CTF侧故障重启导致）。CHF不会拒绝，而是会将其处理为有效请求，并返回已存在的会G话ID，帮助CTF同步状态。
• 孤立的[Update]或[Termination]：CHF收到了一个[Update]请求，但在其数据库中却找不到对应的会话（可能是[Initial]消息在网络中丢失了）。CHF不会丢弃这个消息，而是会基于这个[Update]消息的信息，即时创建一个新的计费会话上下文，并处理其中的用量信息。这最大程度地保证了计费信息的完整性，避免了因初始消息丢失而导致整个会话无法计费的灾难。

1.3 作为消费者的CHF检测到的故障 (CHF as NF Consumer detected failure): 漫游中的信任链

这个场景主要应用于漫游，特别是当一个CHF需要向另一个CHF（例如，V-CHF向H-CHF）请求计费授权时。

5.5.1.3 CHF as NF Consumer detected failure …in the case of the consumer CHF towards producer CHF request times out and without alternative producer CHF, consumer CHF decides how to handle the charging session with NF (CTF) based on the operator agreement…

场景：“智驾-01”漫游到了邻市，其计费由本地运营商的V-CHF处理。V-CHF需要向“智驾-01”归属运营商的H-CHF申请配额。此时，V-CHF与H-CHF之间的链路中断了。

V-CHF（作为消费者）将根据运营商之间的**漫游协议（Operator Agreement）**来决策。

• 信任模式：如果协议允许，V-CHF可以暂时“垫付”信用，继续为“智驾-01”的SMF授权配额，并缓存计费信息，待链路恢复后再与H-CHF进行对账和结算。
• 保守模式：如果协议要求严格的实时信用控制，V-CHF将拒绝为SMF授权，导致“智驾-01”的漫游服务中断。

2. 重试处理 (Retry handling): 不轻易放弃的坚持

重试处理是故障处理（Failure Handling）的具体实施步骤之一，它定义了当请求超时后，如何进行“再试一次”。

5.5.2 Retry handling In case a NF consumer (CTF) does not receive a Charging Data Response, it may retransmit the Charging Data Request message. The number of retries and delay between retries shall be locally configured in the NF consumer (CTF).

场景：“智驾-01”的SMF发送的计费请求超时了，其本地配置的重试机制被激活：最多重试3次，每次间隔500毫秒。

重试机制的关键在于如何让接收方（CHF）识别出这是一个重传的请求，而不是一个全新的请求，以避免重复计费。

If the retried charging data request [Initial] is received by the same CHF, the uniqueness checking may be based on the Charging Identifier… If the retried request is charging data request [Update] or charging data request [Termination], the uniqueness checking may based on the inspection of the Charging Session Identifier and Invocation Sequence Number pair. If retried message shall have the same Invocation Sequence Number as the original… the Invocation Sequence Number shall not be incremented when the message is retried.

这里的机制非常精妙：

• 对于[Initial]请求：由于此时还没有会话ID，CHF通过Charging Identifier（由CTF生成的一个唯一标识）来检测重复。
• 对于[Update]和[Termination]请求：CHF通过“Session Identifier + Invocation Sequence Number（调用序列号）”这个组合键来识别。
  • 关键点：重传报文的调用序列号必须与原始报文的序列号保持完全相同。例如，一个序列号为10的[Update]请求超时了，SMF重传时，其序列号依然是10。如果CHF已经处理过序列号为10的请求，就会忽略这个重传报文，只返回之前的处理结果。而一个新的请求，其序列号会是11。

3. 响应码处理 (Response code handling): 读懂”失败”的信号

不是所有的失败都是超时。有时，CHF会明确地返回一个错误响应码，告知CTF请求处理失败以及失败的原因。

5.5.3 Response code handling The Charging Data Response includes a response code (i.e. Invocation Result Code in Invocation Result) which may indicate an error. The response codes supported by Nchf_ConvergedCharging service operations are specified 3GPP TS 32.291.

TS 32.291（定义了计费接口协议）中定义了大量的错误码，例如：

• DIAMETER_CREDIT_LIMIT_REACHED：信用额度用尽。
• DIAMETER_USER_UNKNOWN：用户不存在。
• DIAMETER_RATING_FAILED：计费定价失败。

CTF的行为将取决于具体的错误码。

A NF Consumer (CTF) receiving a Charging Data Response [Initial] with a response code indicating the… request [Initial] was unsuccessfully processed, shall perform the error handling applicable to the response code and may send a Charging Data Request [Termination] to the CHF.

场景：“智驾-01”的SMF为乘客的VR电影服务申请配额，但CHF返回了CREDIT_LIMIT_REACHED。

1. SMF收到这个明确的拒绝信号。
2. 它会理解为该服务无法继续。
3. 根据本地策略，SMF会执行相应的“终止动作”，例如中断VR电影的数据流。
4. 在某些情况下，即使是[Initial]请求失败，SMF也可能会发送一个[Termination]请求去“清理”可能在CHF侧创建的、不完整的会话资源，确保状态的一致性。

此外，规范还提到了Multiple Unit Information中可以携带针对特定计费组（Rating Group）的错误码。这意味着在一个包含多个业务的融合计费请求中，CHF可以精细地做到：授权“智驾-01”的导航流量（RG1），但拒绝其乘客的VR电影流量（RG2，因为该乘客的子账户余额不足）。这进一步展现了5G计费的精细化控制能力。

总结

错误处理机制是5G计费系统健壮性的基石，是确保商业成功和用户信任的“隐形守护者”。通过为自动驾驶汽车“智驾-01”在一次虚拟的“故障之旅”中保驾护航，我们看到了这套机制的精密与强大：

• 分层的决策体系：从CTF前线的自主决断（Terminate/Continue），到CHF大脑的自我修复（处理乱序/丢失消息），再到漫游场景下基于协议的信任判断，构成了立体的防御体系。
• 严谨的重试与去重：通过调用序列号等机制，确保了在不可靠网络下的“尽力而为”，同时又避免了“好心办坏事”的重复计费。
• 清晰的信号语言：丰富的错误响应码让系统间的“对话”不再模糊，使得每一次失败都有据可查，有策可依。

正是这些深植于规范细节中的错误处理逻辑，才使得5G网络能够承载像自动驾驶这样对可靠性、连续性要求达到极致的严苛应用。它们确保了即使在最坏的情况下，系统也能以一种可预测的、安全的方式运行，将损失和风险降至最低。

---

FAQ - 常见问题解答

Q1：在CTF检测到故障时，选择Terminate（终止）和Continue（继续）策略，分别适用于哪些业务场景？ A1：这是一个典型的风险与体验的权衡。

• Terminate 适用于高价值、大流量、或者运营商无法承担任何收入损失风险的业务。例如，高清视频直播、在线游戏、或者对一个信用等级不高的预付费用户的上网业务。一旦计费失效，立即停止服务是首选。
• Continue 适用于**低价值、小流量、或者为了保障极端重要的用户体验（如VIP客户）**的业务。例如，物联网设备上报的零星心跳包、VoNR（5G语音）通话（保障通话连续性远比几秒钟的话费重要）、或者自动驾驶车辆的紧急安全信令。在这些场景下，短暂的计费中断带来的损失，远小于业务中断造成的恶劣影响。

Q2：“故障处理 (Failure Handling)” 和 “重试处理 (Retry Handling)” 有什么区别？ A2：它们是不同层面的概念。重试处理是故障处理的一种具体手段和过程。

• 故障处理是一个宏观的策略，它定义了当一个请求最终被认定为失败后（例如，经过多次重试依然失败），系统应该怎么办（Terminate或Continue）。
• 重试处理是一个微观的机制，它定义了在请求第一次失败后，系统应该如何尝试去挽救它（重传几次？间隔多久？是否切换到备用节点？）。重试是过程，而故障处理策略是这个过程失败后的最终“结局”。

Q3：系统如何保证重试的计费请求不会导致用户被重复扣费？ A3：通过**幂等性（Idempotency）**设计。CHF通过唯一的标识符来识别每一个请求，确保即使同一个请求被接收多次，也只会被处理一次。

• 对于会话的第一个请求（[Initial]），使用Charging Identifier。
• 对于后续请求（[Update]、[Termination]），使用Session Identifier和Invocation Sequence Number的组合。 关键在于，重传请求的Invocation Sequence Number不会增加。CHF只要检查到“这个会话ID+这个序列号”的组合已经被成功处理过，就会直接丢弃这个重复的请求，只返回之前保存的响应。

Q4：什么是会话故障转移（Session Failover），它是如何实现的？ A4：会话故障转移是高可用性（HA）计费架构的核心。它指的是当主CHF节点故障时，CTF（SMF）能够无缝地将计费会话切换到一个备用CHF节点上。这通常通过以下方式实现：

1. 节点发现：SMF通过向NRF查询，获取一个CHF服务实例列表，其中可能包含主备信息或多个对等实例。
2. 重试与切换：当SMF向主CHF的请求超时，其Retry_and_terminate策略会指示它从CHF列表中选择下一个可用的实例进行重试。
3. 上下文同步（可选）：在更高级的架构中，主备CHF之间可能有状态同步机制，使得备CHF能够接管会话而无需从头开始。但在3GPP基本规范中，通常是备CHF在收到切换来的请求后，重建会话上下文。

Q5：如果一个会话的[Initial]请求丢失了，但CHF收到了后续的[Update]请求，计费会话还能建立吗？计费会准确吗？ A5：是的，会话还能建立，并且计费依然是准确的。这是CHF鲁棒性设计的一个关键体现（见5.5.1.2）。当CHF收到一个它不认识的会话ID的[Update]请求时，它会：

1. 即时创建会话：它不会拒绝请求，而是会根据这个[Update]请求中包含的用户标识、业务信息等，动态地创建一个新的计费会话上下文。
2. 处理用量：然后，它会正常处理这个[Update]请求中携带的用量信息。 虽然[Initial]消息丢失了，但从第一个到达的[Update]开始的所有后续用量都会被正确记录，这确保了运营商的收入损失降到最低。