深度解析 3GPP TS 23.335：5.1-5.6 UDC核心数据操作流程
本文技术原理深度参考了3GPP TS 23.335 V18.0.0 (2024-03) Release 18规范中，关于“5 User Data convergence information flows”的核心章节，旨在为读者提供一个关于用户数据融合（UDC）架构下，数据查询、创建、更新与删除等基础操作的全景视图。
欢迎来到我们的3GPP规范深度解析系列。今天，我们将深入探讨一个在现代通信网络中至关重要的概念——用户数据融合（User Data Convergence, UDC）。在传统的网络架构中，用户数据像一座座孤岛，散落在HLR、HSS、Application Server等不同的网元中，管理复杂且效率低下。UDC架构的出现，旨在通过构建一个统一的用户数据存储库（UDR），将应用逻辑与数据存储彻底分离，从而实现数据的集中管理和高效共享。
本文将聚焦于TS 23.335规范的第五章，通过一个贯穿全文的场景，为您生动地揭示UDC架构下最核心的四大数据操作流程。
我们的主角：
- 李工：一位经验丰富的运营商核心网工程师，负责维护和管理公司新上线的UDC系统。
- 张伟：一位新入网的用户，他将在李工的操作和网络的自动化流程中，体验UDC架构带来的高效服务。
准备好了吗？让我们跟随李工的脚步，一同揭开UDC数据操作的神秘面纱。
1. UDC信息流基础：概述与要求 (章节 5.1 & 5.2)
在进入具体的操作流程之前，我们必须先理解UDC信息流的总体框架和基本要求。规范的5.1和5.2章节虽然简短，却为后续所有流程奠定了基础。根据指令要求，我们将这两节的内容在此进行简述和融合。
5.1 General (概述) 章节为我们描绘了一幅宏观的交互图景。
This clause documents the main procedures on the Ud reference point that are used by the different Front Ends. These procedures are described using text description as well as information flow diagrams. The procedures described in this document are meant to provide a high level description and are not intended to be exhaustive.
简而言之，UDC的核心在于前端（Front End, FE）和用户数据存储库（User Data Repository, UDR）之间的Ud接口。FE可以是处理具体业务逻辑的任何网元，如HSS-FE、HLR-FE或某个应用的AS-FE。当UDC架构被应用后，这些FE自身不再永久存储用户数据，它们变得“无状态”（stateless）。每当需要处理业务时，FE会通过Ud接口向UDR请求所需的用户数据，处理完毕后，本地的临时数据即被销毁。
规范中的“Figure 5.1-1: General UDC Information Flow”清晰地展示了这一过程：一个外部请求（来自UE、其他网元或OSS）触发FE，FE向UDR读取数据，执行应用逻辑（期间可能与外部实体通信，也可能再次访问UDR），最后删除本地临时数据。这个通用模型是理解后续所有具体流程的关键。
5.2 Requirements (要求) 章节则从能力上定义了UDR和FE必须遵守的规则。
- It shall be possible for an authorized Front End to read relevant user data stored in the UDR.
- It shall be possible for an authorized Front End to modify (i.e. create, update, and delete) relevant user data stored in the UDR.
- The UDR shall support notifications to the related Front Ends about changes of user data which they have subscribed to.
- The UDR shall support controlled access. Accordingly, UDR shall authenticate and authorize Application Front Ends.
这几点要求构成了UDC安全和高效运作的基石：
- 授权读写：FE对UDR的数据操作不是无限制的，必须经过授权。
- 订阅通知：UDR具备主动通知能力，当数据发生变化时，可以通知已订阅此变化的FE。
- 访问控制：UDR是数据访问的“守门人”，它必须能够认证和授权每一个FE的请求。授权依据包括请求者身份（FE Identity）、应用类型、用户归属网络、请求的数据类型（读/写）等。
好了，基础知识铺垫完毕。现在，让我们进入实战场景。李工接到业务部门的工单，需要为新用户张伟办理入网手续。
2. 为新用户创建档案：创建数据流程 (章节 5.4)
张伟的入网意味着需要在UDR中为他创建一套完整的用户档案，包括身份信息、签约业务、鉴权数据等。这时，李工所使用的运维支撑系统（OSS）就是一个典型的“开通前端”（Provisioning FE）。
2.1 创建流程的核心思想
Create data procedure is used by a FE to insert a new user data record into the UDR, e.g. when a provisioning FE creates an account for a new user, or creates a new service profile for an existing user.
这个流程非常直观：一个FE（如李工的OSS系统）向UDR发起请求，要求为特定用户插入一条或多条新的数据记录。
让我们参照规范中的“Figure 5.4-1 Create Data flow”，一步步看李工是如何操作的。
2.2 详解创建数据信息流
步骤 1: FE 发起创建数据请求 (Create Data Request)
李工在OSS界面上输入张伟的个人信息（IMSI、MSISDN等）和所选的套餐包，点击“开户”。OSS系统立即封装了一个创建数据请求，通过Ud接口发送给UDR。
When an application FE - during processing of its application logic - needs to insert new user data in the UDR, e.g. open a new user account in the database, it shall issue a Create Data Request message and send it over the Ud reference point to the UDR. The message shall contain:
- the FE Identifier or the FE Cluster Identifier
- the user identity
- the identification of data to be inserted.
- the new data value.
这个请求消息中包含了几个关键信息：
- FE标识：
Provisioning-FE-01，表明是李工所在的开通系统发起的。 - 用户标识：
IMSI: 460012345678900，明确操作对象是张伟。 - 待插入数据标识：例如
SubscriptionData/Services/VoLTE，指明要添加的是VoLTE业务的签约数据。 - 新数据值：
{status: "ACTIVE", QoS: "premium"}，包含了该业务的具体配置。
步骤 2: UDR 执行访问控制 (Perform Access Control)
UDR收到请求后，第一件事就是“查验证件”。
The UDR shall perform access control to check whether the FE/application type is allowed to create the requested data. If it is not, an unsuccessful response shall be returned to the FE and steps 3 and 4 shall be skipped.
UDR会检查：Provisioning-FE-01这个FE是否有权限为用户创建SubscriptionData。这是保障数据安全至关重要的一步。假设权限校验通过，流程继续。
步骤 3: UDR 插入新数据记录 (Insert a new user data record)
验证通过后，UDR会在其数据库中为张伟（由IMSI标识）创建新的数据条目。
If the access control check is successful, the UDR shall insert the user data with the new data value.
至此，张伟的用户档案在UDR中正式建立。
步骤 4: UDR 执行通知流程 (Perform notification procedure process)
数据创建成功后，可能会触发一个重要的后续动作——通知。
If the notification triggering conditions are met, the UDR shall perform notification procedure. This procedure may run before, after or in parallel of sending Create data answer (see step 5). See clause 5.8.
比如，HSS-FE可能预先订阅了“新用户创建”这一事件。那么当张伟的档案创建成功后，UDR就会主动通知HSS-FE，告知其新用户的到来。这个精妙的机制我们将在后续文章中详细拆解。
步骤 5: UDR 返回创建确认 (Create Data Acknowledge)
最后，UDR向李工的OSS系统返回一个成功的响应消息，告知操作已完成。
The UDR shall return a Create data answer to the FE. The FE then shall continue processing its application logic.
李工的屏幕上弹出了“用户张伟开户成功”的提示。至此，一个完整的数据创建流程结束。
3. 实时响应业务：查询数据流程 (章节 5.3)
几天后，张伟首次开机，他的手机发起了附着（Attach）请求。网络中的MME（在UDC架构下可视为一个FE）需要获取张伟的签约信息和鉴权数据，以决定是否允许他接入网络。这就触发了数据查询流程。
3.1 查询流程的核心思想
The Query data procedure is used by an FE to retrieve data from the UDR.
当任何FE需要用户信息来完成其业务逻辑时，它就会向UDR发起一次数据查询。这是一个在网络日常运行中发生频率最高的操作。
我们跟随张伟的附着请求，并参考“Figure 5.3-1: Query data procedure”来理解这个过程。
3.2 详解查询数据信息流
步骤 1: FE 发起查询数据请求 (Query data request)
MME-FE接收到张伟的附着请求后，立刻向UDR发起查询。
When an application FE - during processing of its application logic - needs to retrieve user data from the UDR it shall issue a Query data request message and send it over the Ud reference point to the UDR. The message shall contain:
- the FE Identifier or the FE Cluster Identifier
- the user identity
- the requested data
请求消息的关键内容如下：
- FE标识：
MME-FE-Cluster-A，表明是MME集群发起的。 - 用户标识：
IMSI: 460012345678900。 - 请求的数据：
SubscriptionData/AM-Data(接入和移动性管理数据) 和AuthenticationData(鉴权数据)。MME明确告诉UDR它需要哪些信息。
步骤 2: UDR 执行访问控制 (Perform access control)
UDR再次担当起“守门人”的角色。
The UDR shall perform access control to check whether the FE/application type is allowed to read the requested data. If it is not, an unsuccessful response shall be returned to the FE and steps 3 and 4 shall be skipped.
UDR会校验，MME-FE-Cluster-A是否有权限读取用户的AM-Data和AuthenticationData。例如，一个AS-FE（应用服务器前端）可能就无权访问这些核心网络数据。
步骤 3: UDR 获取并格式化数据 (Fetch data value and format it)
权限校验通过后，UDR从数据库中检索出张伟的相应数据。这里有一个非常重要的概念——“数据视图”（Data View）。
If the access control check is successful, the UDR shall fetch the value of the requested data and format it according to the requesting FE’s data view.
同一个数据，对于不同的FE，其展现形式可能不同。UDR会根据MME-FE的“视图”要求，将数据格式化为它最容易理解和处理的结构，然后准备返回。这体现了UDC架构的灵活性。
步骤 4: UDR 返回查询结果 (Query data answer)
UDR将格式化好的数据封装在应答消息中，返回给MME-FE。
The UDR shall return a Query data answer message to the FE. The FE then shall continue processing its application logic with the retrieved data.
MME-FE拿到了所需的数据，便可以继续完成后续的附着和鉴权流程，最终让张伟成功接入了网络。
4. 动态适应变化：更新数据流程 (章节 5.6)
张伟乘高铁出差，手机从一个服务区移动到另一个服务区，需要执行位置更新（Location Update）。这时，网络需要更新UDR中记录的张伟的当前位置信息（例如，他所附着的VLR地址）。这个过程由更新数据流程来完成。
4.1 更新流程的核心思想
The Update data procedure is used by an application FE to modify user data in the UDR.
与创建类似，更新流程用于修改UDR中已存在的用户数据。这可以是用户位置的变化、业务状态的变更（如停机/复机），或是用户通过自服务门户修改了某项业务配置。
我们参照“Figure 5.6-1: Update data procedure”来分析这个流程。
4.2 详解更新数据信息流
步骤 1: FE 发起更新数据请求 (Update data request)
当张伟的手机进入新的位置区，对应的HLR-FE（或HSS-FE）需要更新他在UDR中的位置信息。
When an application FE - during processing of its application logic - needs to update user data in the UDR it shall issue an Update data request message… The message shall contain:
- the FE Identifier or the FE Cluster Identifier
- the user identity
- the identification of the data of which the value is to be updated.
- the new data value The message may contain:
- the update condition, if supported by the UDR
请求消息包含：
- FE标识：
HLR-FE-02。 - 用户标识：
IMSI: 460012345678900。 - 待更新数据标识：
LocationData/VLR-Number。 - 新数据值：新的VLR地址，例如
+86139xxxxxxx。 - 更新条件（可选）：这是一个强大的功能。FE可以设置一个条件，比如“仅当当前的VLR地址是旧地址
+86138yyyyyyy时才更新”。这可以防止因消息乱序等问题导致的数据不一致，确保操作的原子性。
步骤 2 & 3: UDR 执行访问控制与条件检查
The UDR shall perform access control… If it is not, an unsuccessful response shall be returned… If the message contains the update condition, the UDR shall check if the condition is satisfied. If it is not, an unsuccessful response shall be returned…
UDR首先检查HLR-FE-02是否有权限修改用户的位置数据。然后，如果请求中带有更新条件，UDR会严格检查该条件是否满足。只有两项检查都通过，流程才能继续。
步骤 4: UDR 更新数据并启动通知
If the access control check is successful and the update condition is satisfied, the UDR shall update the requested data with the new data value. If the notification triggering conditions are met, the UDR shall perform the Notification Procedure.
检查通过后，UDR将数据库中张伟的VLR地址更新为新值。与创建流程类似，此操作也可能触发对其他已订阅此数据变化的FE（例如，一个依赖用户位置的第三方应用AS-FE）的通知。
步骤 5: UDR 返回更新确认
The UDR shall return an Update data answer message to the FE. The FE then shall continue processing its application logic.
UDR向HLR-FE返回成功响应，位置更新流程顺利完成。网络知道了张伟的最新位置，可以正确地为他提供后续服务（如接听电话）。
5. 服务生命周期终结：删除数据流程 (章节 5.5)
一段时间后，张伟决定不再使用某项增值业务，他通过手机营业厅App提交了退订申请。这个操作最终会触发删除数据流程，将该业务的配置信息从他的UDR档案中移除。
5.1 删除流程的核心思想
Delete Data procedure is used by a FE to delete user data stored in the UDR, e.g. when a provisioning FE deletes a service profile for an existing user, or removes the account of a user.
删除流程用于从UDR中移除特定的数据项，小到一个业务参数，大到整个用户账户。
我们最后一次请出流程图，“Figure 5.5-1 Delete Data flow”，来走完这最后一程。
5.2 详解删除数据信息流
步骤 1: FE 发起删除数据请求 (Delete data request)
处理退订请求的应用服务器（AS-FE）或开通系统（Provisioning FE）向UDR发起删除请求。
When an application FE … needs to delete user data from the UDR, e.g. delete user service profile, it shall issue a Delete Data Request message… The message shall contain:
- the FE Identifier or the FE Cluster Identifier
- the user identity
- the identification of data to be deleted. The message may contain:
- the delete condition, if supported by the UDR
请求消息包含：
- FE标识：
AS-FE-VideoPlus。 - 用户标识：
IMSI: 460012345678900。 - 待删除数据标识：
ServiceData/VideoPlusProfile。 - 删除条件（可选）：与更新类似，可以设置条件，如“仅当该业务状态为‘SUSPENDED’时才可删除”，以符合业务逻辑。
步骤 2 & 3 & 4: UDR 执行控制、检查与删除
The UDR shall perform access control… If the message contains the delete condition, the UDR shall check if the delete condition is satisfied… If the access control check is successful and the delete condition is satisfied, the UDR shall delete the requested user data.
UDR依次执行严格的权限检查和条件检查。一切无误后，它会从张伟的用户档案中找到VideoPlusProfile这条记录，并将其彻底删除。
步骤 5 & 6: UDR 执行通知并返回确认
If the notification triggering conditions are met, the UDR shall perform notification procedure… The UDR shall return a Delete data answer to the FE.
数据的删除同样可能触发通知。最后，UDR向发起请求的FE返回成功响应，告知业务退订已在数据层面完成。张伟的手机营业厅App也收到了“业务已成功退订”的推送。
FAQ 环节
Q1：UDC 架构的核心思想是什么？它解决了什么问题？ A1：UDC的核心思想是“数据与应用分离”。它将传统网元中耦合在一起的用户数据和业务处理逻辑分离开，数据集中存储在统一的UDR中，而业务逻辑则由无状态的FE处理。这种架构主要解决了传统网络中用户数据存储分散、数据不一致、新业务上线慢、网络运维复杂等问题，极大地提升了网络的灵活性、可扩展性和运维效率。
Q2：FE (前端) 是无状态的吗？它在处理业务时如何获取和处理用户数据？ A2：是的，在理想的UDC架构中，FE是“无状态”的，意味着它自身不永久保存任何用户的签约或状态数据。当一个业务请求到达FE时，FE会启动一个FE-Session（会话）。在会话期间，它通过Ud接口向UDR查询所需的用户数据，并将这些数据临时缓存在本地内存中用于处理业务逻辑。业务处理完成后（FE-Session结束），这些临时数据必须被清除。这种机制使得任何一个同类型的FE都可以处理任何用户的请求，为负载均衡和容灾提供了极大的便利。
Q3：UDR 如何保证只有授权的 FE 才能访问数据？ A3：UDR通过一套严格的访问控制机制来保证数据安全。当FE向UDR发起请求时，UDR会基于多个维度进行鉴权和授权判断，这些维度主要包括：
- FE的身份：通过FE Identifier或FE Cluster Identifier来识别请求者。
- 应用类型：判断FE处理的业务类型（如HLR、HSS、AS等）。
- 用户归属网络：例如用户的PLMN ID。
- 请求的数据：FE请求访问的是哪个具体的数据片段。
- 请求类型：是读取（query）、创建（create）、更新（update）还是删除（delete）。 只有当请求的所有维度都符合预先配置的策略时，UDR才会允许该操作。
Q4：在更新或删除数据时，“条件(condition)”参数有什么作用？请举例说明。 A4： “条件”参数是一个可选但非常强大的功能，它用于实现“条件性操作”，确保操作的原子性和数据一致性，防止因并发或消息时序问题导致的数据错误。例如，在更新用户位置场景中，一个HLR-FE可以发起一个请求：“将用户的VLR地址更新为B，条件是当前VLR地址必须是A”。如果此时因为另一个并发流程，用户的VLR地址已经被更新为C，那么这个带条件的更新请求就会失败，从而避免了用一个过时的信息覆盖一个更新的信息。
Q5：为什么在创建、更新或删除数据后，UDR 还要执行一个“通知流程”？这个流程的意义是什么？ A5：通知流程（Notification Procedure）是UDC实现数据同步和多业务协同的关键机制。其意义在于，当一个FE修改了UDR中的某项数据后，UDR可以主动将这一变更通知给其他所有关心这项数据的FE。例如，当运维人员（通过Provisioning FE）修改了用户的VoLTE业务开关状态，UDR可以主动通知HSS-FE，HSS-FE再通知IMS网络，从而实时地让用户的业务生效或失效。这避免了各个系统间需要复杂的点对点接口进行同步，实现了以数据为中心的、高效的发布/订阅模式。