好的，我们正式进入规范的第6章。这一章将我们的视角从用户业务的“外部交互”转向了5G核心网内部的“社交规则”。如果说前几章定义了计费系统需要完成的“任务”，那么本章将揭示计费功能（CHF）是如何融入5G服务化架构（SBA）这个庞大的生态系统，并让其他网络功能（NF）找到它、信任它、并与之高效协作的。
深度解析 3GPP TS 32.290：6 Service definition (服务定义) - Part 1: 5G计费功能的“社交网络”
本文技术原理深度参考了3GPP TS 32.290 V18.9.0 (2025-03) Release 18规范中，关于“6.1 NF service framework”的核心章节，旨在为读者揭示5G计费功能在服务化架构中的生命周期与交互模型。
在前几篇文章中，我们已经像电影导演一样，指挥着无人机、电竞选手和自动驾驶汽车，演绎了5G计费的各种宏大叙事。我们知道了计费系统能做什么。但我们还未曾探究一个更根本的问题：在一个由成百上千个微服务组成的、云原生化的5G核心网中，一个SMF（会话管理功能）究竟是如何在茫茫“人海”中，精准地找到它应该与之对话的那个CHF（计费功能）的？
欢迎来到5G核心网的“社交俱乐部”。本章，我们将为网络功能（NF）赋予人格。我们的新主角，是一个刚刚被部署上线的、全新的CHF实例，我们称之为**“小C”。它的使命，是向网络中的其他成员宣告自己的存在，并开始提供计费服务。而它的引路人，是5G核心网的“社群管理员”和“中央登记处”——NRF（网络功能仓库功能），我们称之为“大N”**。
1. 计费的基石：网络功能服务框架 (NF service framework)
在深入细节之前，我们必须理解5G核心网的灵魂——服务化架构（SBA）。与4G时代基于点对点专用协议（如Diameter）的“烟囱式”架构不同，SBA借鉴了IT领域的微服务思想。每个网络功能（NF）都是一个独立的服务生产者（Producer）和/或消费者（Consumer），它们之间通过标准的HTTP/JSON API进行通信。
这种架构的“交通枢纽”和“黄页目录”，就是NRF。任何NF想要在5G核心网中提供服务或使用服务，都必须遵循一套严格的“社交礼仪”，这套礼仪就是本章的核心。
6.1 NF service framework 5G Charging Function supports to interact with NRF, as specified in clause 7.1 of TS 23.501 and clauses 4.17 and 5.2.7 of TS 23.502 to enable following functionalities:
- CHF instance(s) registration, CHF service(s) instance(s) registration in a CHF instance.
- CHF instance(s) update, CHF service(s) instance(s) update in a CHF instance.
- CHF instance(s) deregistration.
- CHF instance(s) and CHF service(s) instance(s) discovery by CHF service consumer.
规范开篇就列出了一个NF（在这里是CHF）的完整生命周期管理功能，这一切都围绕着与NRF的交互展开。让我们跟随“小C”的脚步，来体验这完整的“入职-履新-离职”流程。
2. “我来了！”：CHF的注册流程 (Registration)
场景：凌晨2点，运营商的运维工程师成功在上海数据中心部署了一个新的CHF实例——“小C”。当“小C”的进程第一次启动，它的首要任务，就是在5G核心网这个庞大的组织中“报到”，让所有人都知道它的存在和能力。
- CHF instance(s) registration, CHF service(s) instance(s) registration in a CHF instance.
这个过程分为两步：
- NF实例注册：作为“小C”这个软件实例本身的注册。
- 服务实例注册：在“小C”这个实例上，注册它能提供的具体服务（例如，
Nchf_ConvergedCharging服务）。
“小C”会调用NRF提供的Nnrf_NFManagement_NFRegister服务。它向“大N”提交了一份详尽的“个人简历”。
The Nnrf_NFManagement_NFRegister service invoked by CHF for CHF instance(s) and CHF service(s) instance(s) registration described in the TS 29.510 may include in particular:
- Range(s) of SUPIs.
- Range(s) of GPSIs.
- Range(s) of PLMNs.
- CHF Group ID.
- CHF set ID.
- CHF service set ID.
这份简历里的每一个字段都至关重要，它定义了“小C”的“管辖范围”和“身份背景”。
-
Range(s) of SUPIs / GPSIs：这是最重要的信息之一。“小C”向“大N”声明：“我负责处理用户ID（SUPI）在460-00-1234567890到460-00-1234599999这个号段内的所有用户的计费业务。” 这就像是在社区登记处划分片警的管区。当一个属于这个号段的用户发起业务时，“大N”就知道应该把计费请求导向“小C”。 -
Range(s) of PLMNs：声明“小C”服务的网络范围，例如它只服务于中国移动（PLMN ID: 46000）的用户。 -
CHF Group ID：声明“小C”所属的群组。这通常用于地理位置或管理域的划分。例如，CHF-Group-Shanghai-DC。这有助于实现基于地理位置的NF选择，让上海的SMF优先选择上海的CHF，以降低时延。 -
CHF set ID / CHF service set ID：这是实现**高可用性（HA）**的关键。一个“Set”可以被理解为一个高可用组。例如，“小C”可能还有一个孪生兄弟“小C-backup”，它们共同组成一个CHF-Set-01。“小C”是主用，小C-backup是备用。当“小C”宕机时，“大N”可以智能地将流量切换到小C-backup，保证业务不中断。
“大N”收到这份简历后，会将其记录在自己的数据库中。至此，“小C”正式“入职”，成为了5G核心网大家庭的一员。
3. “情况有变！”：CHF的更新流程 (Update)
场景：随着业务的发展，运营商决定将另一批用户的计费也划归给“小C”管理。运维工程师更新了“小C”的配置。此时，“小C”需要立即将这个变化同步给整个网络。
- CHF instance(s) update, CHF service(s) instance(s) update in a CHF instance.
“小C”会再次调用Nnrf_NFManagement服务，但这次是更新操作。它向“大N”提交一份更新后的简历，比如，Range(s) of SUPIs字段现在包含了新的号段。
这个更新机制保证了NRF中的信息始终是最新的，是SBA架构动态性和灵活性的体现。任何NF的扩容、缩容或能力变更，都能实时地被网络中的其他成员感知到。
4. “我走了！”：CHF的注销流程 (Deregistration)
场景：在稳定运行了一段时间后，“小C”所在的物理服务器需要进行硬件升级，必须下线维护。在关闭“小C”进程之前，一个优雅的“告别”是必不可少的。
- CHF instance(s) deregistration.
“小C”会向“大N”发送一个注销请求。这相当于是在“社群”里宣告：“各位，我要下线一段时间，请不要再把新的工作派给我了。”
“大N”收到请求后，会将“小C”的注册信息从其服务目录中移除。这样，后续的SMF在查询CHF时，就不会再得到“小C”的地址。这确保了不会有新的计费请求被发送到一个即将关闭的实例上，避免了业务失败。
思考：如果“小C”异常崩溃，来不及注销怎么办？ 这是真实世界中常见的问题。NRF为此设计了“心跳”或“健康检查”机制。NRF会周期性地检查已注册NF实例的存活状态。如果“小C”在预设的时间内没有响应NRF的健康检查，NRF会判定其已“死亡”，并强制将其注销，这是一种被动的、容错的注销机制。
5. “谁是我的CHF？”：SMF的发现流程 (Discovery)
我们已经看完了CHF的生命周期。现在，让我们切换视角，看看服务消费者是如何找到它的。我们的另一个主角——**SMF实例“小S”**登场了。
场景：“小S”刚刚收到了一个来自用户460-00-1234567890的PDU会话建立请求。这是一个需要计费的业务，“小S”必须找到正确的CHF来处理它。
- CHF instance(s) and CHF service(s) instance(s) discovery by CHF service consumer.
“小S”不知道哪个CHF负责这个用户，于是它向万能的“大N”（NRF）发起了求助，调用了Nnrf_NFDiscovery_NFDiscover服务。这个求助请求非常具体：
“大N你好，我需要一个能够提供Nchf_ConvergedCharging服务的CHF实例，它需要满足以下条件：
- 服务的PLMN是
46000。 - 能够处理
SUPI为460-00-1234567890的用户。 - 最好是在
Shanghai-DC这个区域内（以降低时延）。”
“大N”在自己的数据库中进行快速检索，它会匹配所有已注册CHF实例的“简历”。很快，它就找到了完全符合条件的“小C”。于是，“大N”将“小C”的服务地址（通常是一个FQDN或IP地址）返回给了“小S”。
拿到地址后，“小S”就可以与“小C”建立直接的HTTP/2连接，并开始发送我们前几章讨论过的Charging Data Request消息了。
6. CHF的“家族体系”：高可用性模型
为了保证计费这个核心业务的7x24小时不间断，单个CHF实例是远远不够的。规范在这里对CHF的高可用性模型做了补充说明。
A CHF instance is either a part of:
- a primary CHF instance and secondary CHF instance pair, or
- a CHF set.
这定义了两种主流的冗余备份模式：
-
主备对（primary CHF instance and secondary CHF instance pair）：这是传统的主备模式。一个主CHF处理所有业务，一个备CHF处于热备状态，时刻准备接管。当主CHF通过健康检查被发现故障时，NRF会将其标记为不可用，并将后续的发现请求指向备CHF。
-
CHF集（a CHF set）：这是更符合云原生思想的模式。一个CHF Set由多个对等的、状态可以同步的CHF实例组成。它们可以同时处理业务，实现负载均衡。当其中一个实例宕机，NRF会简单地将其从可用列表中移除，剩余的实例会分担它的负载。这种模式提供了更好的水平扩展性和弹性。
无论是哪种模式，其核心都依赖于我们上面讨论的注册、健康检查和发现机制。NRF就像一个智能的负载均衡器和故障切换控制器，为整个计费系统的稳定运行提供了坚实的保障。
总结
本章虽然没有深入具体的计费业务流程，但它所描述的NF服务框架，是理解整个5G SBA架构和融合计费系统运作方式的“钥匙”。通过将网络功能人格化，我们看到了一个动态、自治、高度协同的内部世界：
- 新来的**“小C”（CHF）通过向“大N”**（NRF）注册，宣告自己的能力和管辖范围，完成了“入职”。
- 当职责变化时，“小C”通过更新流程，保持自己在“大N”处的档案始终最新。
- 需要帮助的**“小S”**（SMF），通过向“大N”发现，可以像查电话本一样，精准地找到能够帮助它的“小C”。
- 当“小C”需要下线时，它通过注销流程，礼貌地“告别”，确保工作的平稳交接。
这个基于“注册-发现”的“社交模型”，取代了4G时代复杂的、静态配置的节点间关系，为5G网络的弹性、可扩展性和自动化运维奠定了基础。正是有了这个强大的服务框架，我们前面所讨论的所有复杂的计费功能，才得以在现实世界的运营商网络中，稳定、高效地运行。
在下一篇文章中，我们将回到计费服务本身，深入剖析Nchf_ConvergedCharging这个核心服务，以及它所包含的Create, Update, Release等具体的操作，敬请期待。
FAQ - 常见问题解答
Q1：什么是NRF，为什么说它是5G SBA的“大脑”或“交通枢纽”？ A1：NRF（Network Repository Function）是5G服务化架构（SBA）中的一个核心网络功能。它扮演着“注册中心”和“发现中心”的角色。所有其他NF实例在启动时，都必须向NRF注册自己的信息（如身份、地址、能力、服务范围等）。当一个NF（消费者）需要使用另一个NF（生产者）的服务时，它会向NRF查询，NRF根据查询条件返回一个或多个满足条件的生产者NF实例的地址。没有NRF，SBA中的各个NF将无法相互找到，整个核心网就会陷入瘫痪。因此，NRF是实现SBA动态、灵活、解耦特性的关键。
Q2：SMF每次处理PDU会话时，都需要向NRF查询一次CHF吗？ A2：不一定。为了提高效率，SMF在第一次成功发现某个CHF实例后，通常会将其地址缓存起来。在后续处理属于该CHF管辖范围内的其他用户会话时，SMF会直接使用缓存的地址，而无需每次都去查询NRF。当然，这个缓存有有效期，并且当SMF发现连接缓存的CHF地址失败时，它会清除缓存并重新向NRF发起发现流程。这种“查询一次，缓存复用”的机制，在效率和动态性之间取得了很好的平衡。
Q3：CHF注册到NRF的信息中，最重要的参数是什么？为什么？
A3：最重要的参数是定义其“管辖范围”的参数，特别是**Range(s) of SUPIs/GPSIs**。因为这是NRF进行CHF实例选择（CHF Selection）最主要的依据。在一个大型网络中，通常会部署多个CHF实例或集群，每个负责一部分用户。通过精确地划分用户ID范围，NRF可以将不同用户的计费请求路由到正确的CHF进行处理，这是实现计费系统水平扩展和负载分担的基础。
Q4：如果一个CHF实例崩溃了，没有来得及向NRF注销，会发生什么？ A4：这会触发NRF的健康检查和故障处理机制。NRF会周期性地向已注册的NF实例发送心跳探测消息。如果一个CHF实例在连续几次探测中都未能响应，NRF就会判定该实例已发生故障。此时，NRF会：
- 更新实例状态：将该CHF实例的状态标记为
SUSPENDED或UNAVAILABLE。 - 停止路由：在后续的NF发现请求中，不再返回这个故障实例的地址。
- 触发告警：通知网管系统，以便运维人员进行干预。 这个机制保证了网络的自愈能力，能够自动隔离故障节点，避免故障扩散。
Q5：CHF Set和CHF Group ID有什么区别？ A5：它们是用于实现不同目的的组织概念。
- CHF Set ID 主要用于高可用性（High Availability）和负载均衡。一个Set内的所有CHF实例通常功能对等，可以相互替代。当SMF发现一个CHF Set时，它可以选择其中的任何一个健康实例进行通信，或者当一个实例失败时，可以无缝切换到Set内的另一个实例。
- CHF Group ID 主要用于管理和策略上的分组，通常与地理位置或网络切片相关。例如，一个运营商可能有一个“北京数据中心CHF组”和一个“广州数据中心CHF组”。SMF在发现CHF时，可以指定优先选择与自己地理位置相同的Group，以优化网络时延。一个Group内可以包含多个CHF Set。所以，Group的粒度比Set更大。