深度解析 3GPP TS 23.335：5.7 Subscription to Notifications (通知订阅机制)
本文技术原理深度参考了3GPP TS 23.335 V18.0.0 (2024-03) Release 18规范中，关于“5.7 Subscription to Notifications”的核心章节，旨在为读者深度剖析UDC架构下，网络如何从被动的“拉取”模式转变为主动的“推送”模式，实现数据变化的实时感知。
在上一篇文章中，我们跟随工程师李工和新用户张伟的脚步，详细体验了UDC架构下数据的创建、查询、更新和删除（CRUD）这四大基本操作。这些操作构成了UDC数据管理的基石，它们大多遵循一种“拉取”（Pull）模式：即当FE（前端）需要数据时，主动向UDR（用户数据存储库）发起请求。
然而，在许多场景下，仅仅依赖“拉取”是低效的。比如，一个应用服务器（AS）需要实时获取用户的最新位置，难道要它每秒钟都去UDR查询一次吗？这无疑会造成巨大的信令风暴。为了解决这个问题，3GPP引入了一种更为优雅和高效的机制——通知订阅，一种典型的“推送”（Push）模式。
今天，我们将继续张伟的故事，探索UDC架构的这一核心能力。
我们的新主角：
- 张伟：我们的老朋友，一位乐于尝试新业务的5G用户。
- “智行伴侣”App：一款新潮的第三方应用，可以为用户提供基于位置的智能提醒服务（例如，当好友进入附近区域时发出提醒）。它的后台系统就是一个典型的应用服务器（AS）。
张伟对“智行伴侶”App很感兴趣，决定开通这项服务。他并不知道，这个简单的点击，将在运营商的核心网中启动一个精密的“通知订阅”流程。
1. 从“被动查询”到“主动通知”：订阅机制的核心
在UDC的世界里，如果说数据查询是“我问你答”，那么通知订阅就是“你若安好，便是晴天；你若变化，立刻告诉我”。FE不再需要盲目地轮询数据，而是可以向UDR“登记”自己感兴趣的数据，一旦这些数据发生风吹草动，UDR就会主动发出通知。
This procedure is used by FE to perform the subscription/un-subscription to notification to specific events which occurs on specific user data stored in the UDR. The events can be changes on existing user data, addition of user data, and so on.
规范开宗明义地指出了该流程的用途：FE用它来订阅（或取消订阅）UDR中特定用户数据的特定事件。这些“事件”涵盖了我们上一章讨论的所有数据操作：数据的创建（addition）、修改（changes）和删除。
这个机制的引入，让UDC架构从一个静态的数据库，演变成一个具备动态感知和事件驱动能力的、活的数据中心。这对于实现网络功能的自动化、智能化以及支持对实时性要求高的业务（如物联网、车联网、关键任务通信）至关重要。
2. 订阅流程全景解析：当张伟开通“智行伴侣”
现在，让我们聚焦于张伟在手机上点击“开通智行伴侣服务”的那一刻。这个动作会触发“智行伴侣”的AS向运营商网络（具体是HSS）发起一个业务开通请求。在UDC架构下，HSS-FE收到了这个请求后，它明白为了实现App的功能，自己必须实时获知张伟的位置变化。于是，HSS-FE决定代表AS，向UDR发起一个对张伟位置数据的通知订阅。
我们参考规范中的“Figure 5.7-1: Subscription procedure”，来一步步拆解这个信息流。
2.1 步骤 1: HSS-FE 发起订阅请求 (Subscription Request)
HSS-FE作为订阅的发起者，精心构造了一个Subscription Request消息，通过Ud接口发送给UDR。这是整个流程中最核心的一步，消息体中包含了订阅的所有关键要素。
When an FE wants to receive notifications of specific events on specific user data stored in the UDR, it shall construct a Subscription Request message and send it over the Ud reference point to the UDR. The message may consist of the following information:
让我们来详细解构这个请求消息的每一个字段，看看HSS-FE是如何精确表达它的意图的。
2.2.1 订阅发起者：FE Identifier or FE Cluster Identifier
- the FE Identifier or the FE Cluster Identifier
这个字段表明了是谁在发起订阅。在我们的场景中，可能是某个具体的HSS前端实体，如HSS-FE-03。如果运营商部署了多个HSS-FE组成集群进行负载均衡，这里也可以填入集群标识HSS-FE-Cluster-B。这让UDR知道订阅的来源。
2.2.2 订阅对象：User Identity
- User identity, e.g. IMSI, MSISDN, IMS public user identity or IMS private user identity. The User Identity may not be present indicating that the subscription is applicable to all users in the UDR.
这个字段指明了订阅是针对哪个用户的。HSS-FE会填入张伟的唯一标识，例如IMSI: 460012345678900。
规范还提到了一个特殊情况：如果这个字段不存在，则意味着这是一个“全局订阅”，即订阅适用于UDR中的所有用户。这种订阅通常用于一些全局性的管理或审计功能，例如，运维系统可能需要订阅所有用户的签约数据变更事件，以便进行记录。
2.2.3 订阅动作：Subscription Type
- Subscription Type
The Subscription Type indicates whether this request is to subscribe or to unsubscribe.
这是一个简单的枚举值，明确本次操作的目的是“订阅”还是“取消订阅”。当张伟未来决定关闭“智行伴侣”服务时，HSS-FE就会发起一个Subscription Type为unsubscribe的请求，来清理之前建立的订阅关系。这确保了订阅关系的完整生命周期管理。
2.2.4 通知目标：Notification Type
- Notification Type. It indicates whether this subscription request should result in a notification to any FE of the application type or cluster identifier, or in a notification to the FE requesting the notification.
这是理解UDC无状态和负载均衡特性的一个关键字段。它定义了当通知事件发生时，UDR应该将通知发送给谁。它有两个主要的选项：
- 通知给发起订阅的特定FE：UDR会记录下是
HSS-FE-03发起了这个订阅，未来有通知时，就只发给HSS-FE-03。 - 通知给该应用类型的任意一个FE：UDR只记录下这是一个来自
HSS-FE应用的订阅。未来有通知时，UDR可以从HSS-FE-Cluster-B集群中选择任何一个当前可用的FE（比如HSS-FE-04或HSS-FE-05）来发送通知。
第二种方式的优势巨大。它完美匹配了FE的无状态特性，极大地提高了系统的健壮性和可靠性。即使当初发起订阅的HSS-FE-03恰好宕机或正在升级，通知任务依然可以由集群中的其他健康成员完成，业务不会中断。
2.2.5 订阅内容：Subscription to Notifications information
这是一个复合结构，它精确定义了订阅的“具体内容”。
- Subscription to Notifications information, which consists of:
2.2.5.1 订阅的数据：Identification of the requested data
- Identification of the requested data
The Identification of the requested data indicates the data to which notifications are subscribed.
HSS-FE在这里明确指出，它关心的是张伟的哪一部分数据。在我们的场景中，它会指定为用户的位置信息，例如LocationData/CurrentLocation。如果“智行伴侣”App还关心用户的网络状态（比如从5G切换到4G），HSS-FE还可以同时订阅AccessData/RAT-Type。这体现了订阅的精确性。
2.2.5.2 触发条件：The notification condition(s)
- The notification condition(s)
The notification condition indicates the specific events on which the notification shall be triggered. It shall consist of the addition of the requested data, the deletion of the requested data or the changes of the requested data.
这个字段定义了什么样的数据操作会触发通知。HSS-FE可以选择以下一种或多种：
- addition: 当为张伟添加位置信息时（例如，首次注册）。
- deletion: 当删除张伟的位置信息时（例如，用户离网注销）。
- changes: 当张伟的位置信息发生变更时（最常见的场景，用户移动）。
在我们的例子中，HSS-FE会选择changes，因为“智行伴侣”最关心的就是位置的动态变化。
2.2.5.3 有效期：The expiry time
- The expiry time
If the subscription is not permanent, the expiry time indicates the point in time when the subscription to notifications expires.
订阅可以是永久的，也可以是临时的。如果HSS-FE没有设置这个字段，该订阅将一直有效，直到被明确地unsubscribe。
但在某些场景下，临时订阅非常有用。例如，某个网络诊断任务可能需要临时监控张伟的数据1小时，那么发起订阅的FE就可以设置expiry time为1小时后。到期后，UDR会自动清理这个订阅，无需FE再次发起取消订阅的请求，简化了管理。
2.2.5.4 真正的“幕后老板”：The original entity identity
- The original entity identity
If the subscription request is related to a UDC external entity (e.g. AS) subscription request, this item indicates the original entity which sent the subscription request message to the FE… The item shall contain the address or the name of the original entity.
这是整个订阅请求中最具智慧的设计之一。请记住，在我们的场景中，HSS-FE只是一个“中间人”，它代表“智行伴侣”的AS发起了订阅。那么当UDR未来发送通知时，它只会发给HSS-FE，但HSS-FE如何知道这个通知应该转发给哪个AS呢？
original entity identity字段就解决了这个问题。HSS-FE在向UDR发起订阅时，会把“智行伴侣”AS的地址（如as.zhixingbanlv.com）填入这个字段。UDR会将这个地址与订阅关系一同存储。未来当UDR向HSS-FE发送通知时，会把这个“原始实体身份”原样带回。HSS-FE看到这个地址，就知道：“哦，这个通知是关于as.zhixingbanlv.com当初关心的那个事的”，然后就能准确地将通知转发给正确的AS。
2.2 步骤 2: UDR 执行访问控制 (Perform access control)
UDR收到这个内容丰富的订阅请求后，并不会立即接受，而是先进行严格的权限审查。
When receiving a Subscription Request from a specific FE, the UDR shall perform access control to check whether the FE is allowed to perform the subscription to the UDR on the requested data. If not, an unsuccessful response shall be returned to the FE, and steps 3 and 4 are skipped.
UDR会检查：HSS-FE-Cluster-B这个应用集群，是否有权限订阅用户的LocationData/CurrentLocation数据？这是一个重要的安全关卡，防止了未经授权的应用或网元窥探用户的敏感信息。
2.3 步骤 3 & 4: UDR 存储订阅并返回响应
权限校验通过后，UDR便会将这个订阅关系持久化下来。
The UDR shall store the subscription to notifications information. The UDR shall return a successful response message to the FE.
UDR内部会维护一个“订阅者列表”，类似于：
- 用户:
IMSI: 460012345678900 - 数据:
LocationData/CurrentLocation - 事件:
changes - 通知目标:
HSS-FE-Cluster-B - 原始实体:
as.zhixingbanlv.com
存储成功后，UDR向HSS-FE返回一个成功的响应消息。至此，整个订阅流程完成。HSS-FE也向“智行伴侣”AS确认服务开通成功。张伟的手机App界面显示：“服务已激活”。
3. 规范的智慧：附注中的深意
规范的5.7章节最后附有两个重要的NOTE，它们揭示了在实际部署中需要考虑的复杂性和优化手段。
NOTE 1: Since Subscription to Notifications information cannot be shared among different FEs … careful consideration is to be taken into account when using subscriptions over Ud. For example, an application FE could subscribe to notifications about certain data changes without being aware that another FE was already subscribed for the purpose of performing the same operations…
这个附注指出了一个潜在的问题：FE之间是独立的，它们无法知道彼此的订阅情况。假设由于某种原因，另一个HSS-FE-08也代表同一个“智行伴侣”AS发起了完全相同的订阅请求。UDR会忠实地创建两条订阅记录。这可能导致未来一次数据变更会触发两次重复的通知，造成资源浪费。因此，规范提醒我们，应用设计时需要“仔细考虑”，避免产生不必要的冗余订阅。
NOTE 2: Applications that require subscribe/unsubscribe to notifications about many data changes on a per user basis and for common conditions (e.g. HLR/HSS) can make use of UDR pre-configured subscriptions in order to decrease the signalling over Ud.
这个附注则提供了一种重要的优化方案：“预配置订阅”。对于某些非常通用和频繁的订阅场景，例如HSS/HLR总是需要知道用户位置的变化，我们可以在UDR中直接进行预先配置，而无需每次都由HSS/HLR-FE通过信令发起订阅。当用户的某个数据（如VLR地址）被创建时，就自动激活一个隐含的订阅。这大大减少了Ud接口上的信令交互，提升了网络效率。
4. 联动未来：订阅机制的价值体现
到目前为止，“智行伴侣”的订阅关系已经在UDR中安静地建立。它的价值将在何时体现？
答案就在我们上一篇文章讨论的“更新数据流程”中。几天后，张伟乘坐高铁出差，他的位置发生了变化，触发了网络中的位置更新流程。一个HLR-FE向UDR发起了对张伟LocationData/CurrentLocation数据的Update data request。
当UDR成功更新该数据后，它的内部机制会被触发：检查是否有关于此数据变更的订阅。UDR会检索其“订阅者列表”，并成功匹配到我们刚刚建立的那条记录。
这一发现，将启动下一个关键流程——5.8 Notification of data modification (数据修改通知)。UDR会构造一个通知消息，发送给HSS-FE-Cluster-B中的某个可用FE。这个FE收到通知后，根据通知中携带的original entity identity——as.zhixingbanlv.com，将位置变更信息准确地推送给“智行伴侣”的AS。
最终，“智行伴侣”App收到了张伟的最新位置，并根据其业务逻辑，可能向张伟的好友发出了“张伟已到达XX市”的提醒。
至此，我们看到了订阅机制如何将看似孤立的数据更新操作，与外部应用的需求无缝地连接起来，形成一个完整、闭环、实时的业务流程。这正是UDC架构强大能力的完美体现。
FAQ 环节
Q1：相比于让应用服务器（AS）不断地去查询（轮询）用户数据，UDC的通知订阅机制好在哪里？ A1：通知订阅机制（Push模式）相比于轮询（Pull模式）有三大优势：
- 效率极高：只有在数据实际发生变化时才会产生信令交互，避免了轮询模式下大量无用的查询请求，极大地节省了网络资源和处理开销。
- 实时性强：数据一变更，通知几乎是立即触发和发送的，保证了应用能够以最低的延迟获取到最新的数据状态。轮询的实时性则受限于其查询频率。
- 架构解耦：应用服务器（数据消费者）和UDR（数据源）之间的耦合度更低。AS只需一次性声明其“兴趣”，而无需关心数据何时、如何变化，由UDR来负责事件的驱动。
Q2：订阅请求中的“Notification Type”字段和“Original Entity Identity”字段有什么区别和联系？ A2：“Notification Type”决定了UDR将通知发送给哪一类或哪一个FE（例如，发给任意一个HSS-FE）。它解决的是UDR到FE这一段的路由问题，并支持FE的负载均衡和容灾。而“Original Entity Identity”记录了这次订阅请求真正的业务发起方（例如，“智行伴侣”AS的地址）。当FE收到UDR的通知后，需要依靠这个字段来决定将通知信息继续转发给哪个外部应用。两者协同工作，确保了一条从UDR到最终应用的完整、准确的通知链路。
Q3：什么是“预配置订阅”（pre-configured subscription），它为什么能减少信令？
A3：“预配置订阅”是运营商在UDR中进行的一种静态配置，它定义了一些隐含的、自动的订阅规则。例如，可以配置“只要任何用户的VLR地址被创建或更新，就自动认为HSS应用对此有订阅需求”。这样一来，HSS-FE就不再需要为每一个用户、每一次会话都通过Ud接口发送Subscription Request信令来建立订阅关系，UDR会根据配置自动处理。这对于那些固定的、网络自身必需的监控需求，可以省去海量的动态订阅信令，从而提升网络整体效率。
Q4：如果一个FE宕机了，它之前建立的订阅会怎么样？ A4：这取决于订阅时“Notification Type”字段的设置。
- 如果设置为通知给特定的FE，而该FE恰好宕机，那么UDR发送的通知将会失败。UDR可能会尝试重发，或根据策略放弃。
- 如果设置为通知给该应用类型的任意一个FE（推荐方式），那么即使发起订阅的FE宕机，UDR依然可以选择集群中其他健康的FE来发送通知，保证了业务的连续性。至于FE宕机前建立的那些“有状态”的订阅（比如设置了expiry time），其恢复机制取决于具体的实现，但通常无状态的设计会避免这种强绑定。
Q5：一个FE可以同时对一个用户的多项数据发起订阅吗？
A5：可以。Subscription Request消息的设计是灵活的。FE可以在Subscription to Notifications information中包含多个Identification of the requested data条目，或者为不同的数据分别发起独立的订阅请求。例如，一个综合类应用可能同时关心用户的位置、网络接入类型（RAT-Type）、业务开通状态等多项数据，它可以通过一次或多次订阅，为这些数据变化都建立起通知关系。