51学通信

深度解析 3GPP TS 23.335：Annex A.3 订阅流程实例 (IMS应用服务器订阅)

19分钟阅读

深度解析 3GPP TS 23.335：Annex A.3 订阅流程实例 (IMS应用服务器订阅)

本文技术原理深度参考了3GPP TS 23.335 V18.0.0 (2024-03) Release 18规范中，关于“Annex A (informative): Information flows”中的 A.3 章节，旨在通过一个完整的IMS应用服务器订阅场景，将我们在第5.7章学习的订阅理论，落地为工程师可以触摸和理解的具体信令交互。

在前面的章节中，我们已经深入探讨了UDC（用户数据融合）架构下的查询与更新流程。我们看到，无论是传统的CS呼叫还是现代的IMS业务变更，UDC都能以其“数据与逻辑分离”的核心思想，优雅地支撑起复杂的网络功能。然而，UDC架构真正的魅力和前瞻性，体现在其强大的“事件驱动”能力上，而这种能力的基石，正是我们此前理论学习过的“通知订阅”机制。

理论的学习让我们知道了“是什么”和“为什么”，而实例的解析则将告诉我们“如何做”。今天，我们将聚焦于附录A的第三部分，通过一个极为常见的场景——第三方应用服务器（AS）订阅用户数据变化，来实战化地演练整个订阅流程。

我们的主角，依然是那位走在技术前沿的用户张伟，以及他钟爱的**“智行伴侶”App**。我们将亲历张伟开通这项服务时，后台系统是如何通过一次“双重订阅”的精妙操作，为未来的实时通知埋下伏笔的。

1. 订阅实例的舞台：外部实体与UDC的握手 (A.3.1 General)

规范在A.3.1章节为我们设定了本次实例的舞台背景，明确了其核心议题。

When an UDC-external entity subscribes/un-subscribes to notifications of specific events which occurs on specific user data stored in the UDR, the application front-end should perform a subscription procedure towards the UDR.

这段话的关键词是“UDC-external entity”（UDC外部实体）。在我们的故事中，“智行伴侣”App的AS就是一个典型的外部实体。它本身不属于UDC系统的一部分，但它的业务却高度依赖于UDC系统中的用户数据。当这个外部实体需要感知UDR中数据的变化时，它不能直接与UDR对话，而是必须通过一个“中间人”——应用前端（application front-end），在我们的场景中，这个角色由HSS-FE扮演。

因此，整个订阅流程将呈现出一种“接力赛”的形式：AS向HSS-FE发起第一棒订阅，HSS-FE再转身向UDR发起第二棒订阅。HSS-FE在此过程中，扮演了协议转换、安全代理和逻辑中介的关键角色。

2. “双重订阅”全解析：当AS请求“盯梢”用户数据 (A.3.2)

场景设定：张伟对“智行伴侣”App的位置提醒功能非常满意，现在他看到了一个新的付费功能：“家庭成员网络状态提醒”——当家庭成员（假设已获得授权）的IMS网络注册状态发生变化时（例如上线、下线），App会发出通知。张伟决定为自己和家人开通此项服务。

这个操作将在“智行伴侣”AS、HSS-FE和UDR之间，触发一场教科书式的订阅信息流。让我们跟随规范中的“Figure A.3.2-1 Subscription over Sh with Ud subscription from HSS-FE”，一步步拆解这场“接力赛”。

2.1 第一棒：AS向HSS-FE发起订阅 (Sh-Subs-Notif)

  1. AS sends the Sh-Subs-Notif request to the HSS-FE to subscribe or un-subscribe to the notifications of changes on the Repository Data with the related Public User Identity, the Service Indication, the Application Server Identity, the Expiry Time (not for un-subscribing) and other information.

张伟在App上点击“开通”后，“智行伴侣”AS立即通过Diameter Sh接口，向HSS（即一个可用的HSS-FE）发送了一条Sh-Subs-Notif（订阅通知）请求。这标志着订阅流程的第一棒正式启动。

这个Sh请求消息中，包含了AS的全部诉求：

  • Public User Identity：张伟的IMS公共标识，明确了订阅对象。
  • Service Indication：一个关键字段，精确地告诉HSS-FE，AS关心的是哪一类数据。在这里，它会指定为与用户IMS注册状态相关的数据（例如，RepositoryData/IMS-Registration-Status）。
  • Application Server Identity：AS自己的身份标识，即as.zhixingbanlv.com。
  • Expiry Time：订阅的有效期。例如，这项服务是按月付费的，AS可以设置一个一个月的有效期，到期后需要续订。

对于AS而言，它只是在与一个标准的HSS进行交互，它并不知道，也不需要知道HSS的背后已经UDC化了。

2.2 准备工作：HSS-FE的预查询

HSS-FE收到了AS的订阅请求，它并没有立刻充当一个“无脑”的传话筒，直接将请求转发给UDR。相反，它执行了一个看似额外但至关重要的准备步骤。

  1. Upon reception of the Sh-Subs-Notif request, the HSS-FE checks the AS-permission list to see whether the AS is allowed to contact the HSS. If so, the HSS-FE sends the Query Request to the UDR to fetch the user data needed to process the Sh-Subs-Notify request from the UDR.
  2. After applying the access control, the UDR responds to the HSS-FE with the requested data.

这个准备工作分为两步：

  1. 权限初审：HSS-FE首先检查自身的配置，确认as.zhixingbanlv.com这个AS是否在“白名单”上，是否被允许向自己发起订阅请求。这是第一道安全屏障。
  2. 向UDR预查询：权限通过后，HSS-FE向UDR发起了一次Ud查询。这次查询的目的，是获取处理这个订阅请求所需的上下文信息。例如，HSS-FE可能需要查询：
    • 张伟是否签约了IMS基础服务？如果他连IMS都不能用，那么订阅他的IMS注册状态就毫无意义。
    • 张伟的签约数据中，是否允许第三方应用订阅他的网络状态？这涉及到用户的隐私策略。
    • 与Service Indication相关的数据当前是否存在或处于何种状态？

这个预查询的步骤，充分体现了FE作为智能逻辑处理单元的角色。它不是简单地传递信息，而是在此基础上进行预处理和校验，确保即将向UDR发起的订阅是有效和合规的。

2.3 第二棒：HSS-FE向UDR发起订阅 (Ud Subscription Request)

在完成了所有准备工作，并从UDR获取了必要的上下文信息之后，HSS-FE现在准备好跑出订阅流程的第二棒——向UDR发起一个内部的、基于Ud接口的订阅请求。

  1. The FE sends a Subscription Request to the UDR. The Subscription Request message includes: The Application type of the FE

这是整个流程的核心转换点。HSS-FE将外部的、基于Diameter Sh协议的、面向IMS业务的请求，“翻译”成了一个内部的、统一的、面向数据操作的Ud订阅请求。让我们详细对比一下这个Ud请求的字段，是如何精确承载来自Sh请求的信息的。

  • FE Identifier / Application type：填入HSS-FE或其集群标识，表明订阅来源。
  • Public User Identity：直接从Sh请求中继承张伟的用户标识。
  • Subscription Type：设置为subscribe。
  • Subscription-to-Notifications information:
    • Identification of the requested data：将Sh请求中的Service Indication（RepositoryData/IMS-Registration-Status）直接映射过来。
    • The notification condition：通常设置为change on user data，因为AS关心的是状态的任何变化。
    • The original entity identity：这是至关重要的一步！HSS-FE将Sh请求中的Application Server Identity（as.zhixingbanlv.com）填入此字段。这个动作，为未来的通知能够准确回溯到源头AS，埋下了关键的伏笔。
    • The expiry time：同样从Sh请求中继承，并可能由HSS-FE根据自身策略进行调整。

通过这次精妙的“翻译”，HSS-FE将AS的业务诉求，转化为了UDR能够理解和执行的数据层面的订阅指令。

2.4 终点冲刺：UDR存储订阅并逐级确认

  1. The UDR checks whether the subscription/un-subscription is allowed. If it is permitted, the UDR shall store/delete the Subscription-to-Notification information. The UDR responds with the Success Indication.

UDR收到了HSS-FE的订阅请求，它会执行自己的、更深层次的访问控制检查。例如，校验HSS-FE这个应用类型，是否有权限订阅用户的IMS注册状态数据。

校验通过后，UDR会在其内部的“订阅者列表”中，为张伟的IMS注册状态数据，添加一条新的订阅记录。这条记录将牢牢绑定通知目标（HSS-FE集群）和原始实体（as.zhixingbanlv.com）。

随后，UDR向HSS-FE返回一个成功的响应，标志着第二棒冲线。

  1. Upon reception the Subscription Response, the HSS-FE sends the Sh-Subs-Notif Resp to the AS with the value of the requested data and with the result code set to DIAMETER_SUCCESS.

HSS-FE收到UDR的确认后，终于可以给它的“客户”——“智行伴侣”AS一个明确的答复了。它构造一条Sh-Subs-Notif Resp响应消息，通过Sh接口发回给AS，其中包含了成功的结果码，甚至可能还附带了该数据项的当前值。

至此，整个“双重订阅”的接力赛圆满结束。“智行伴侶”AS收到了成功的确认，张伟的手机App上显示：“家庭成员网络状态提醒服务已成功开通！”

3. 实例背后的架构之美

这个看似简单的订阅流程实例，实际上深刻地揭示了UDC架构分层、解耦和代理的设计哲学。

  1. 清晰的边界与职责：AS、HSS-FE、UDR三者各司其职，边界清晰。AS负责业务逻辑，不关心底层数据如何存储；UDR负责数据存储和事件触发，不关心上层业务是什么；HSS-FE则充当了两者之间的桥梁，负责协议转换、安全校验和策略执行。
  2. 外部接口的稳定性：AS只需要与标准的HSS Sh接口交互，完全无需为了后端的UDC化改造而进行任何适配。这保证了第三方应用的兼容性和生态的稳定。
  3. 内部接口的统一性：无论外部是Sh接口、MAP接口还是其他什么协议，到了HSS-FE这一层，所有对数据的订阅需求，都被统一收敛到了Ud接口的Subscription Request上。这大大简化了UDR的设计，使其可以专注于提供标准化的数据服务。
  4. 安全性的层层过滤：我们看到，订阅请求至少经过了HSS-FE和UDR两层安全检查。HSS-FE负责应用层面的权限控制（哪个AS可以访问我），UDR负责数据层面的权限控制（哪个FE可以订阅哪个数据），构建了纵深防御的安全体系。

FAQ 环节

Q1：为什么应用服务器（AS）不直接向UDR发起订阅请求，而需要HSS-FE作为“中间人”？ A1：这种设计是出于架构分层、安全和管理的考虑：

  1. 安全屏障：HSS-FE充当了外部网络和核心数据存储之间的安全网关。如果允许成千上万的第三方AS直接访问UDR，将带来巨大的安全风险和管理噩梦。通过HSS-FE进行代理，可以将访问控制点集中收敛。
  2. 协议转换：外部AS通常使用标准的、面向业务的协议（如Diameter Sh），而UDR使用的是内部统一的、面向数据操作的Ud接口。HSS-FE负责完成这两种协议之间的“翻译”。
  3. 策略控制：运营商可以在HSS-FE上实施复杂的策略，例如对来自不同AS的请求进行速率限制、优先级调度，或者根据用户签约信息决定是否允许订阅，这些都不是一个纯粹的数据存储层（UDR）应该承担的职责。

Q2：在步骤2中，HSS-FE向UDR发起“预查询”的目的是什么？这是一个必须的步骤吗？ A2：预查询的主要目的是为了获取处理订阅请求所需的上下文信息，并进行业务逻辑校验。例如，校验用户是否有资格使用该服务、用户的隐私设置是否允许此次订阅等。这使得HSS-FE不仅仅是一个简单的请求转发器，而是一个智能的业务逻辑执行点。虽然在某些极简场景下可以省略，但在大多数复杂的电信业务中，这是一个确保订阅有效性和合规性的重要步骤，可以避免向UDR写入大量无效或不合规的订阅数据。

Q3：当张伟决定关闭“家庭成员网络状态提醒”服务时，会发生什么？ A3：会发生一个与订阅流程完全相反的“取消订阅”流程。

  1. “智行伴侣”AS会向HSS-FE发送一条Sh-Subs-Notif请求，但这次请求中的订阅类型是“取消订阅”（unsubscribe）。
  2. HSS-FE收到后，同样会向UDR发起一个Ud接口的Subscription Request，其中的Subscription Type字段也设置为unsubscribe。
  3. UDR收到后，会找到之前建立的那条订阅记录，并将其删除。
  4. 最后，UDR和HSS-FE会逐级返回成功的响应。这样，当张伟的IMS注册状态再次变化时，UDR就不会再产生任何通知了。

Q4：如果HSS-FE在向UDR发起订阅后、但在收到UDR响应前宕机了，会发生什么情况？ A4：这会造成一个不一致的状态。AS可能因为没有收到HSS-FE的响应而认为订阅失败（或超时），但UDR可能已经成功创建了订阅。这需要上层应用（AS）具备重试机制。当AS重试订阅时，新的请求可能会被路由到另一个健康的HSS-FE，这个新的HSS-FE会再次向UDR发起订阅。UDR的实现需要具备幂等性，即对于完全相同的订阅请求，重复执行和执行一次的效果应该是一样的（例如，覆盖旧的订阅或直接返回成功），从而避免产生重复的订阅记录。

Q5：这个订阅流程本身会触发任何“通知”吗？ A5：不会。订阅流程本身是对“元数据”（即订阅关系数据）的创建、修改或删除，它并不会触发针对用户业务数据（如张伟的位置、注册状态）的通知。通知只会在被订阅的那些用户业务数据本身发生增、删、改操作时，才会被U-DR触发。订阅流程是“设置捕兽夹”的动作，而通知流程是“野兽踩到捕兽夹”后发出的警报。

关系图谱