51学通信

深度解析 3GPP TS 32.290：6 Service definition (服务定义) - Part 3 Nchf_OfflineOnlyCharging服务的“精简之道”

19分钟阅读

好的，我们继续对3GPP TS 32.290规范的深度剖析。在上一章中，我们详细拆解了功能强大的Nchf_ConvergedCharging服务及其“四大金刚”操作。现在，我们将目光转向一个更为专注和轻量级的服务——Nchf_OfflineOnlyCharging。这可以看作是融合计费大家族中的一位“专科医生”，专注于处理一类特定的计费场景。

深度解析 3GPP TS 32.290：6 Service definition (服务定义) - Part 3: Nchf_OfflineOnlyCharging服务的“精简之道”

本文技术原理深度参考了3GPP TS 32.290 V18.9.0 (2025-03) Release 18规范中，关于“6.5 Nchf_OfflineOnlyCharging service”的核心章节，旨在为读者阐明5G中纯离线计费服务的定位、架构及其与融合计费的关系。

在5G这个宏大的生态系统中，并非所有业务都需要像VR直播或自动驾驶那样复杂的融合计费策略。想象一下城市里的智能水表，它可能每隔一小时才通过5G网络上报一次读数；或者是一个环境监测传感器，每天只发送几次温湿度数据。对于这类业务，强制使用包含复杂配额管理和实时信控逻辑的融合计费服务，无异于“杀鸡用牛刀”。

为了应对这类纯粹的“先使用，后记账”场景，并进一步优化网络信令和处理效率，3GPP定义了一个专门的服务：Nchf_OfflineOnlyCharging。

今天，我们的主角是一家名为**“物联无限”**的物联网公司。他们部署了数百万计的智能传感器，用于监测城市基础设施。这些设备的数据传输具有流量小、非实时、周期性的特点，是纯离线计费的完美应用场景。我们将通过这家公司的业务，来理解Nchf_OfflineOnlyCharging服务的精简与高效。

1. 纯离线计费服务：专注与简化

首先，让我们从服务的总体描述开始，理解它的核心定位。

6.5.1 General Service description: The OfflineOnlyCharging service provides charging for session based NF services. This OfflineCharging service offers charging information record generation.

与Nchf_ConvergedCharging服务的描述相比，这里的定义非常简洁，只强调了两点：

  1. 用于会话类服务（session based NF services）：这意味着它依然遵循会话计费的“Create-Update-Release”模型。
  2. 提供计费信息记录生成（charging information record generation）：其唯一的目标就是生成CDR。

这里没有提及任何关于“配额管理（quota management）”或“在线计费”的字眼。这清晰地表明，Nchf_OfflineOnlyCharging服务被严格限定在离线计费的范畴内，它剥离了所有与在线信控相关的复杂逻辑，变得更加轻量和专注。

接下来，Table 6.5.1-1: NF services provided by the CHF为我们展示了其服务操作。

Service NameService OperationsOperation SemanticsExample Consumer(s)
Nchf_OfflineOnlyChargingCreateRequest/ResponseSMF, IMS-Node
UpdateRequest/ResponseSMF, IMS-Node
ReleaseRequest/ResponseSMF, IMS-Node

可以看到，这个服务由Create、Update和Release三个核心操作组成。与融合计费服务相比，它缺少了由CHF主动发起的Notify操作。这是因为纯离线计费不涉及实时的策略变更（如余额变化、欺诈检测等），因此不需要CHF具备主动通知CTF的能力。

2. Create 操作：离线会话的开启

Create操作依然是所有计费会话的起点。

6.5.2 Nchf_OfflineOnlyCharging_Create service operation Description: Provides charging capabilities before service delivery, offers charging information record generation. Provides means for the NF Consumer to create the resource of the charging session. The service operation shall open a CDR in the CHF…

核心职责与融合计费的对比：

  • 相同点：都在业务交付前调用，目的都是在CHF中创建计费会话资源，并打开一个CDR。
  • 不同点：
    • 输入参数简化：Inputs, Optional中不再有Requested service units这样的配额请求参数。整个交互流程不涉及配额协商。
    • 输出参数简化：Outputs, Optional中也不再有Granted service units、validity time等配额授予相关的参数。输出参数中最关键的可能是triggers，CHF依然可以通过这个参数告诉CTF，在何种情况下需要进行中间汇报。

场景应用： “物联无限”公司的一个智能水表需要上报数据，它向网络请求建立一个PDU会话。

  1. SMF收到请求，并通过策略（例如，基于该设备使用的特定APN或S-NSSAI）识别出这是一个纯离线计费的物联网业务。
  2. SMF选择调用Nchf_OfflineOnlyCharging_Create服务。
  3. 在请求中，SMF只携带了水表的身份标识（SUPI/GPSI）和服务标识。
  4. CHF收到请求，在内部创建计费会话，打开一个CDR，并返回成功响应。响应中可能包含一个触发器，例如“每累计1MB流量或每隔24小时，上报一次用量”。
  5. SMF允许PDU会话建立，水表开始传输数据。

3. Update 操作：用量的周期性汇报

Update操作负责在会话过程中，根据触发条件，周期性地汇报使用量。

6.5.3 Nchf_OfflineOnlyCharging_Update service operation Description: Provides charging capabilities during service delivery, charging information record generation. If the trigger conditions occurs, this operation may cause update of the CDR or production of an interim CDR in the CHF.

核心职责与融合计费的对比：

  • 相同点：都在业务进行中，由CTF根据触发器调用，目的是上报用量并更新CDR。
  • 不同点：
    • 目的单一：这个Update操作的唯一目的就是“汇报工作”，即Usage Reporting。它不承担“申请资源”的任务。
    • 参数简化：输入参数中同样没有Requested service units，整个消息体更小，处理逻辑更简单。

场景应用： 智能水表的PDU会话可能会持续数天甚至数月。

  1. 会话建立24小时后，SMF上配置的“时长触发器”被触发。
  2. SMF统计在这24小时内，该水表总共使用了5KB的数据流量。
  3. SMF调用Nchf_OfflineOnlyCharging_Update操作，将这5KB的用量上报给CHF。
  4. CHF找到对应的CDR，将这5KB的使用量追加进去。
  5. 这个Update过程会根据触发器设置，每天或每当流量累积到一定程度时重复进行。

4. Release 操作：离线会话的终结

Release操作为纯离线计费会话画上一个句号。

6.5.4 Nchf_OfflineOnlyCharging_Release service operation Description: Provides charging capabilities after service delivery, charging information record generation. Provides means for the NF Consumer to release the resource of the charging session. The charging delete request is used to close the CDR in the CHF if it has been opened.

核心职责与融合计费的对比：

  • 完全一致：Release操作在纯离线和融合计费中的职责几乎是完全相同的。都是在业务结束后，上报最后一段用量，并通知CHF关闭CDR、释放资源。

场景应用： 智能水表因为电池耗尽或设备维护需要下线，主动请求释放PDU会话。

  1. SMF在释放会话前，统计从上一次Update到现在的用量（例如，2KB）。
  2. SMF调用Nchf_OfflineOnlyCharging_Release，上报这最后的2KB用量。
  3. CHF收到请求，进行最终的用量累加，然后将这个持续了很久的CDR的状态置为“关闭”，等待后续批处理和出账。
  4. SMF拆除PDU会话，计费流程结束。

5. 融合计费 vs. 纯离线计费：如何选择？

通过以上的分析，我们可以看到Nchf_OfflineOnlyCharging服务就像是Nchf_ConvergedCharging服务的一个“瘦身版”或“精简模式”。那么，在实际网络中，运营商和设备商该如何做出选择呢？

特性Nchf_ConvergedCharging (融合计费)Nchf_OfflineOnlyCharging (纯离线计费)
核心能力在线 + 离线 + 动态切换仅离线
关键机制配额管理、实时信控周期性用量上报
服务操作Create, Update, Release, NotifyCreate, Update, Release
接口复杂度较高，参数丰富较低，参数精简
信令开销相对较高（尤其在线模式）较低
适用场景消费者业务、企业专网、URLLC、需要复杂策略的业务海量物联网（mMTC）、后台数据同步、纯后付费业务
“物联无限”公司不适用，过于复杂和浪费资源最佳选择

选择的智慧： 对于SMF这样的通用会话管理节点，它必须支持功能更强大的Nchf_ConvergedCharging服务，因为它需要有能力处理网络中所有类型的业务。

然而，对于一个特定的业务场景，PCF（策略控制功能）可以在为PDU会话下发PCC（策略与计费控制）规则时，明确指示SMF：“对于这个APN/S-NSSAI的业务，请使用纯离线计费模式。”

在这种情况下，SMF虽然调用的是Nchf_ConvergedCharging服务的接口，但它在整个会话生命周期中，行为模式会退化成纯离线计费的模式：

  • Create请求中不带配额申请。
  • Update请求中不带配额申请。
  • 忽略所有配额相关的响应参数。
  • 不处理Notify消息。

所以，可以理解为Nchf_OfflineOnlyCharging服务在逻辑上是Nchf_ConvergedCharging服务的一个严格子集。3GPP单独定义它，更多的是为了一些功能单一、轻量级的NF消费者（例如，某个专用的IMS节点或物联网网关）提供一个更简洁、更易于实现的接口规范。而对于功能全面的SMF来说，它通过在调用融合计费服务时“约束自己的行为”，来达到纯离线计费的效果。

总结

Nchf_OfflineOnlyCharging服务的出现，体现了3GPP在设计5G架构时的实用主义和效率优先原则。它承认并非所有场景都需要“航空母舰”级别的融合计费能力，为海量的、简单的物联网连接提供了一艘“轻快驱逐舰”。

通过为“物联无限”公司的传感器业务选择最合适的计费模式，我们理解了纯离线计费的“精简之道”：

  • 专注：只做一件事——生成计费记录，剥离所有在线信控的干扰。
  • 高效：更简单的操作、更少的参数、更低的信令开销，使其能够以极高的效率处理海量计费会话的开启、更新和关闭。
  • 兼容：其核心的Create-Update-Release模型与融合计费一脉相承，使得SMF等核心NF可以平滑地在两种模式间切换，而无需改变底层的状态机。

至此，我们已经完成了对3GPP TS 32.290规范第5章和第6章所有核心服务和场景的解读。我们已经构建了对5G计费系统“能做什么”（第5章）和“如何做”（第6章）的完整认知。接下来的章节将深入到消息体的数据结构层面，那将是一场更为微观的探索。

FAQ - 常见问题解答

Q1：既然Nchf_ConvergedCharging服务可以通过不带配额请求的方式来实现离线计费，为什么3GPP还要单独定义一个Nchf_OfflineOnlyCharging服务？ A1：这主要是出于简化实现、明确意图和标准化的考虑。

  1. 简化实现：对于一些功能非常专一的NF（例如，一个只处理某种特定M2M业务的网关），它们的设计目标就是轻量化。让它们去实现完整的、复杂的融合计费接口是一种负担。提供一个简化的纯离线接口，可以降低这些NF的开发和测试复杂度。
  2. 明确意图：当一个NF消费者调用Nchf_OfflineOnlyCharging服务时，它非常明确地向CHF声明：“我处理的业务绝对不需要在线计费。” 这种清晰的“契约”有助于CHF进行内部的资源调度和优化。
  3. 标准化：为纯离线计费定义一个标准服务，使得不同厂商实现的、只支持离线计费的NF之间可以互通，避免了大家都去“猜测”应该如何使用融合计费接口来实现离线功能。

Q2：Nchf_OfflineOnlyCharging服务缺少Notify操作，这意味着什么？ A2：这意味着在纯离线计费会话中，计费策略是相对静态的。CHF无法在会话过程中，主动地去改变CTF的行为。例如，CHF无法命令CTF突然改变计费触发器，或者强制终止一个会话。所有的计费策略都在会话开始时（Create操作的响应中）确定下来，并在整个会话生命周期中保持不变。这符合离线计费“非侵入式”的特点，即计费系统只做记录，不干预业务。

Q3：一个SMF需要同时支持调用Nchf_ConvergedCharging和Nchf_OfflineOnlyCharging两个服务吗？ A3：通常不需要。一个功能完备的SMF，只需要实现对Nchf_ConvergedCharging服务的调用（作为NF Consumer）即可。因为如前所述，融合计费服务完全有能力处理纯离线计费的场景。SMF会根据PCF下发的策略，决定在调用融合服务时，其“行为”是融合模式还是纯离线模式。单独定义Nchf_OfflineOnlyCharging更多是为那些轻量级的、专用的NF消费者准备的。

Q4：在使用纯离线计费服务时，如果CHF节点发生故障，CTF（SMF）的故障处理机制（如Terminate, Continue）还适用吗？ A4：是的，依然适用。5.5章定义的错误处理机制是通用的。当SMF向CHF发送Create/Update/Release请求超时时，它依然需要根据本地配置或之前从PCF获取的策略，来决定是终止业务（Terminate）还是继续并缓存计费数据（Continue）。对于大多数物联网离线业务，Continue策略可能更常见，因为业务的连续性（如保证数据上报）通常比单次计费信息的实时性更重要，并且缓存数据等待CHF恢复是一种低风险、高收益的容错方案。

Q5：纯离线计费和离线事件计费（Post Event Charging, PEC）有什么区别？ A5：它们描述的是不同层面的概念。

  • 纯离线计费 (Nchf_OfflineOnlyCharging服务) 描述的是一个**会话（Session）**的计费模式，这个会话有开始（Create）、中间（Update）和结束（Release），适用于持续一段时间的连接，例如智能水表的长期PDU会话。
  • 离线事件计费 (PEC) 描述的是一个**单一事件（Event）**的计费模式，它没有中间状态，业务完成即计费完成。例如，发送一条短信。 在实现上，PEC可以通过调用一次Nchf_ConvergedCharging_Create（标记为事件类型）来完成。而纯离线计费会话则需要Create, Update, Release三个操作的完整配合。

关系图谱