51学通信

深度解析 3GPP TS 23.335：Annex A.4 通知流程实例 (IMS能力变更 & AS数据更新)

19分钟阅读

深度解析 3GPP TS 23.335：Annex A.4 通知流程实例 (IMS能力变更 & AS数据更新)

本文技术原理深度参考了3GPP TS 23.335 V18.0.0 (2024-03) Release 18规范中，关于“Annex A (informative): Information flows”中的 A.4 章节。本文旨在将第5.8章中抽象的通知理论，通过具体、生动的网络事件进行实例化，为您揭示UDC（用户数据融合）架构下事件驱动机制的实际运作方式。

在前三篇附录实例的深度解析中，我们已经见证了UDC架构如何优雅地支撑查询、更新和订阅这三大核心流程。我们看到，无论是外部网元还是应用服务器，它们的需求最终都会被前端（FE）“翻译”成统一的、面向数据的Ud接口操作。

今天，我们终于来到了整个事件驱动闭环的“收获”季节——通知流程。当UDR（用户数据存储库）中被订阅的数据真正发生变化时，会发生什么？这份“情报”是如何被打包、路由，并最终精准送达关心它的实体手中的？

我们将继续跟随用户张伟、运维专家李工和**“智行伴侶”App**的故事，通过两个截然不同但都极具代表性的场景，来完整体验UDC通知机制的强大与灵活。

1. 通知实例的开场白 (A.4.1 General)

规范在A.4.1章节中，为我们勾勒出通知流程实例的核心框架。

When user data (temporary or permanent) has been modified, the application front-end may require a notification. When an UDC-external entity modifies subscribable data in the UDR via an application FE, this application FE shall send notifications to other UDC-external entities on supported UDC-external interfaces as part of its application logic (if so required). Notifications to other UDC-external entities to which this FE is not connected, or to other AS which subscribed to notifications, require notification on the Ud-Interface.

这段话信息量巨大，为我们揭示了通知流程的两种主要模式：

  1. FE自主通知：当一个“聪明的”FE（如HSS-FE）处理完一次数据更新后，它可以根据自己掌握的订阅信息，主动地向其他外部实体（如AS）发送通知。
  2. UDR驱动通知：当一个“功能单一的”FE（如Provisioning-FE）更新了数据，但它本身不具备通知外部实体的能力时，UDR必须介入。UDR会向一个“聪明的”FE发送一个内部的Ud通知，委托它去完成对外部实体的通知任务。

这两种模式的并存，正是UDC架构强大适应性的体现。接下来，我们将通过两个实例，分别观摩这两种模式的实战应用。

2. 场景一：运营商的“幕后操作”——IMS能力变更 (A.4.2)

场景设定：运维专家李工接到网络优化部门的指令，需要对一部分用户的IMS服务进行升级，将他们迁移到新部署的、性能更强的S-CSCF集群上。用户张伟就在这次迁移名单中。为了实现平滑迁移，李工需要强制张伟当前的IMS注册失效，以便他的手机能自动重新注册到新的S-CSCF上。

这个由运营商发起的内部维护操作，将触发一次经典的、由UDR驱动的通知流程。让我们参考规范中的“Figure A.4.2-1: IMS service data change information flow example with Ud notification towards HSS-FE”。

2.1 步骤 1 & 2: 李工通过开通系统更新数据

  1. The operator changes the capabilities to move the user to a new S-CSCF, the user is administratively de-registered and S-CSCF is cleared (via Provisioning FE).
  2. After applying the proper access control…, the UDR updates the requested data (e.g. registration status, user capabilities, etc.)

李工在他的运维支撑系统（OSS，一个典型的Provisioning-FE）上，对张伟的IMS数据进行了修改。他清除了UDR中记录的张伟当前所注册的S-CSCF名称，并将他的注册状态标记为“行政注销”（administratively de-registered）。这个Update data request通过Provisioning-FE发送给了UDR，UDR在校验权限后，成功执行了数据更新。

2.2 步骤 3: UDR的觉醒——主动委托HSS-FE

Provisioning-FE的任务到此为止，它是一个“功能单一”的执行者，并不知道如何与IMS网络中的S-CSCF进行交互。但UDR知道！它在更新完数据后，立刻检查是否有相关的订阅或本地策略。

  1. The UDR checks if a FE is required to be notified upon these modified data. If so, it selects a FE supporting the HSS application and sends a notification which contains the user data needed by the FE to perform its application logic (old/new user status, S-CSCF name, etc.)

UDR发现，用户的IMS注册状态发生了重要变更，根据其内部策略，此事必须通知HSS应用。于是，通知流程的第二种模式被激活：

  1. UDR的决策：“这次更新来自一个Provisioning-FE，它无法完成后续的IMS信令操作。我必须找一个‘专家’来处理。”
  2. 选择专家：UDR在其管理的FE列表中，选择了一个当前可用的、支持HSS应用的HSS-FE（例如HSS-FE-05）。
  3. 发送委托：UDR向HSS-FE-05发送了一条notification request（即Ud-Notify）。这份通知里不仅包含了变更的数据，更像是一份工作指令：“张伟的S-CSCF信息已被清除，请你去处理后续事宜。”

2.3 步骤 4-6: HSS-FE执行指令，完成闭环

  1. HSS-FE acknowledges the notification.
  2. The user is de-registered from S-CSCF1 by HSS-FE.
  3. S-CSCF1 acknowledges the Cx command.

HSS-FE收到UDR的“委托”后，立即行动起来：

  1. 它首先向UDR回复一个确认消息（Ack），表示“任务收到”。
  2. 接着，它执行自己的核心业务逻辑。根据通知内容，它知道必须强制用户从旧的S-CSCF（我们称之为S-CSCF1）上注销。于是，它通过Diameter Cx接口，向S-CSCF1发送了一条Cx-Deregister（注销）命令。
  3. S-CSCF1收到命令后，清除了与张伟相关的所有会话信息，并向HSS-FE返回确认。

至此，李工的“幕后操作”大功告成。张伟的手机会因为IMS注册失效而自动发起重新注册，届时网络将为他选择一个新的、性能更强的S-CSCF。整个过程中，张伟可能毫无感知，但他的服务质量却得到了提升。

3. 场景二：应用间的“连锁反应”——AS数据更新 (A.4.3 & A.4.4)

这个场景更为复杂和有趣，它展示了一个AS的数据更新，如何触发对另一个AS的通知。规范为此提供了两种实现模式，其关键区别在于UDR是否需要发送内部的Ud-Notify。

3.1 模式一：由“聪明的”FE自主通知 (A.4.3 Without Ud-Notify)

场景设定：张伟同时在使用两款应用。一款是**“云同步”App (AS1)，用于同步他的个人状态（如“会议中”、“驾车中”）。另一款是我们的老朋友“智行伴侶”App (AS2)**，它已经订阅了张伟的个人状态变化，以便在他“驾车中”时自动开启静音模式。

现在，张伟手动在“云同步”App (AS1)上将自己的状态设置为“驾车中”。

流程解析 (Figure A.4.3-1):

  1. AS1发起更新 (步骤1-6)：AS1通过Sh-Update请求，经由一个HSS-FE（我们称之为HSS-FE-A），成功更新了UDR中张伟的个人状态数据。这个流程与我们之前在A.2.3中学习的IMS业务变更实例非常相似。
  2. 关键点 (步骤5)：“Since the update data request was sent by an FE which can contact AS2 and there is no other AS which subscribed to changes in repository data, the UDR does not send Ud-notify.” UDR在处理完更新后，发现这次更新的发起者HSS-FE-A本身就是一个“聪明的”HSS-FE，它具备了处理Sh接口通知的能力。并且，HSS-FE-A在更新前查询数据时，已经可以获取到AS2的订阅信息。因此，UDR认为HSS-FE-A完全有能力自己完成对AS2的通知，所以UDR不发送内部的Ud-Notify。
  3. HSS-FE-A自主行动 (步骤7-8)：HSS-FE-A在收到UDR的更新成功确认后，检查自己掌握的订阅信息，发现AS2订阅了此项数据。于是，它主动地通过Sh接口向AS2发送了一条Sh-Notif（推送通知）。
  4. 闭环完成：“智行伴侶”App (AS2)收到了通知，自动为张伟的手机开启了静音模式。

3.2 模式二：由UDR委托“专家”FE通知 (A.4.4 With Ud-Notify)

场景设定：这次，张伟的某项数据（例如，计费信息Charging Information）发生了变化。订阅这项数据的是一个第三方计费分析应用AS。但这次数据变化的发起者，不是另一个AS，而是李工通过他的**OSS系统 (Provisioning-FE)**进行的。

流程解析 (Figure A.4.4-1):

  1. OSS发起更新 (步骤1-6)：李工通过OSS系统，经由Provisioning-FE，成功更新了UDR中张伟的计费信息。这个流程与A.4.2中的场景非常相似。
  2. 关键点 (步骤7)：“…and the update data request was sent by a non HSS-FE (that is, a FE which cannot contact the AS), the UDR selects an HSS-FE and sends Notify Request to the selected FE.” UDR在处理完更新后，进行了判断：
    • 发起者：Provisioning-FE。
    • 发起者能力：它是一个“功能单一”的FE，不懂Sh接口，无法与AS对话。
    • 订阅者：有一个AS订阅了此数据。
    • UDR的决策：我必须介入！于是，UDR激活了通知流程，选择了一个“专家”——某个可用的HSS-FE，并向它发送了Ud-Notify，指令它去通知那个AS。
  3. HSS-FE执行委托 (步骤8-10)：被选中的HSS-FE收到了UDR的Notify Request，它解析指令，得知需要通知哪个AS以及通知内容。于是，它构造Sh-Notif消息发送给那个计费分析AS，并在收到AS的确认后，再向UDR回复确认，完成整个委托任务。

4. 最终章：订阅的生命周期管理 (A.4.5 & A.4.6)

规范的最后，A.4.5和A.4.6还展示了订阅过期后的处理逻辑。当数据发生变化，UDR或FE在准备发送通知时，如果发现对应的订阅已经过期，那么它将不会发送通知，而是会触发一个取消订阅的流程，将这条过期的、无用的订阅记录从系统中清理出去。这体现了UDC系统良好的“自我清洁”和生命周期管理能力。

FAQ 环节

Q1：通知流程中的“自主通知”和“委托通知”这两种模式，其选择的关键依据是什么？ A1：关键依据是发起数据更新的FE的能力。

  • 如果发起更新的FE（如HSS-FE）本身就具备了与订阅者（如AS）进行通信的能力（例如，支持Sh接口），并且能够获取到订阅信息，那么就倾向于采用“自主通知”模式（即A.4.3中的without Ud-Notify），由这个FE自行完成通知，效率更高。
  • 如果发起更新的FE（如Provisioning-FE）是一个功能单一的实体，不具备通知订阅者的能力，那么UDR就必须介入，采用“委托通知”模式（即A.4.4中的with Ud-Notify），选择一个有能力的“专家”FE（如HSS-FE）来代为完成通知任务。

Q2：在A.4.2的IMS能力变更实例中，为什么需要通知HSS-FE？这个通知最终实现了什么业务目的？ A2：通知HSS-FE是因为，仅仅在UDR中修改用户的S-CSCF数据是不够的，这只是数据层面的变更。为了让这个变更在网络中真正生效，必须执行一个信令层面的操作。HSS-FE作为IMS网络的控制核心，有能力执行这个操作。这个通知最终实现的业务目的，是触发HSS-FE向用户当前所在的旧S-CSCF发送一条强制注销命令（Cx-Deregister），从而迫使用户终端重新发起注册，进而被网络分配到新的S-CSCF上，完成用户的平滑迁移。

Q3：从A.4.3和A.4.4的对比来看，UDC架构的设计有多灵活？ A3：这两个实例极好地展示了UDC架构的高度灵活性和智能性。它不搞“一刀切”，而是能够根据上下文智能地选择最优的通知路径。当路径最短、最高效时（由智能FE自主通知），它就走捷径；当需要绕道、需要“专家”介入时（由UDR委托通知），它也能智能地进行调度和委托。这种能力使得UDC可以兼容各种能力参差不齐的FE，并始终保证端到端的业务流程得以闭环。

Q4：为什么规范要设计订阅过期自动清理的机制（如A.4.5和A.4.6所示）？ A4：订阅过期自动清理是一种非常重要的系统“自愈”和“保洁”机制。在长期运行的网络中，可能会因为各种原因（如客户端异常退出、网络问题等）产生大量无人认领的、过期的订阅。这些“僵尸订阅”不仅会占用UDR的存储资源，还会在每次相关数据变更时触发无谓的通知检查，消耗处理资源。通过在触发通知时检查订阅有效期，并主动清理过期项，可以保证订阅系统的健康和高效，防止资源泄漏。

Q5：通过这些通知实例，我们可以总结出FE和UDR在事件驱动模型中的核心职责分别是什么吗？ A5：可以。

  • UDR的核心职责：作为事件的感知者和分发调度中心。它负责：1）在数据变更时，检测是否存在相关的订阅或策略；2）根据发起更新的FE的能力，智能决策是让FE自主通知还是需要自己介入委托；3）在需要委托时，选择合适的“专家”FE并下发指令。
  • FE的核心职责：作为事件的执行者和协议网关。它负责：1）在“自主通知”模式下，主动完成通知的发送；2）在“委托通知”模式下，接收并执行来自UDR的通知指令；3）将内部统一的Ud通知，“翻译”成外部实体（如S-CSCF、AS）能够理解的具体协议消息（如Cx-Deregister、Sh-Notif）。

关系图谱