深度解析 3GPP TS 23.335：4 User Data Convergence architecture (用户数据融合架构总览)
本文技术原理深度参考了3GPP TS 23.335 V18.0.0 (2024-03) Release 18规范中，关于“4 User Data Convergence architecture”的核心章节。本文旨在为读者，尤其是网络架构师和核心网工程师，提供一个关于用户数据融合（UDC）架构的、系统性的全景视图，揭示其设计哲学、核心组件以及它们之间的协作方式。
欢迎回到我们的3GPP规范深度解析系列。在之前的文章中，我们通过附录中的具体实例，生动地体验了UDC架构下数据操作的“如何做”。今天，我们将回溯到规范的正文，从一个更高、更宏观的视角，来系统地学习UDC架构的“是什么”和“为什么”。
我们将再次请出我们的老朋友，资深核心网架构师王工。这一次，他将为一批新入职的工程师（包括充满好奇心的小林）举办一场关于UDC架构的专题培训。王工的目标是，通过对第4章的逐节剖析，为这些未来的网络专家们，在心中构建起一座清晰、坚实且逻辑严谨的UDC架构大厦。
“大家好，”王工打开了他的演示文稿，“今天，我们不谈具体的信令流程，我们来谈谈架构，谈谈设计思想。在我们深入了解UDC的内部运作之前，我们必须先理解它的蓝图。小林，你先说说，在你看来，没有UDC的传统网络，最大的痛点是什么？”
小林想了想，回答道：“王工，我觉得是数据孤岛。HLR、HSS、各种应用服务器，每个系统都有一份自己的用户数据，管理起来既复杂又容易出错。”
“说得非常到位！”王工赞许地点点头，“UDC的诞生，正是为了彻底推翻这些数据孤岛。现在，让我们一起看看，它是如何做到的。”
1. UDC的宏伟蓝图：系统架构与核心思想 (4.1 UDC System architecture)
王工的第一张幻灯片，展示了UDC架构的核心理念。
UDC is the logical representation of the layered architecture that separates the user data from the application logic, so that user data is stored in a logically unique repository allowing access from entities handling an application logic, hereby named Application Front Ends.
“‘分层’与‘分离’，这是理解UDC的第一个关键词，”王工强调道，“UDC的本质，就是将传统网元中紧密耦合的数据存储和业务逻辑，进行彻底的解耦。数据归数据，逻辑归逻辑。”
他接着展示了规范中的两幅关键图景，Figure 4.1-1 和 Figure 4.1-2，这两幅图是理解UDC宏观架构的基石。
图景一：UDC参考架构 (Figure 4.1-1: UDC reference architecture)
王工指着这幅简洁的架构图解释道：“大家看，这幅图就是UDC世界的‘地图’。它非常清晰地定义了三个核心角色和它们之间的关系。”
- 用户数据存储库 (UDR)：位于架构的最底层，是整个系统的基石。王工将其比作“国家中央数据档案馆”，它是所有用户数据的唯一、权威的存放地。
- 应用前端 (Application Front End, FE)：位于架构的中间层，是处理具体业务的“专家工作室”。无论是处理移动性管理的HLR/HSS逻辑，还是提供特定业务的应用服务器逻辑，它们都以FE的形式存在。这些工作室只负责“思考”和“处理”，但自己不保留任何“档案材料”。
- Ud参考点：这是连接UDR和FE的“高速信息公路”，是FE访问UDR中数据的唯一通道。
“记住这个模型，”王工说，“逻辑在上，数据在下，通过统一的Ud接口进行交互。这就是UDC分层思想的直观体现。”
图景二：新旧世界的对比 (Figure 4.1-2: Comparison Non-UDC Network to UDC Network)
“为了让大家更深刻地理解这场变革，我们来看看‘旧世界’和‘新世界’的对比。”王工切换到第二幅图。
Figure 4.1-2 shows how the UDC reference architecture is related to the overall network architecture by comparing a Non-UDC Network with an UDC Network. In the non-UDC Network, the figure shows NEs with their own database storing persistent user data… in both cases, when UDC architecture is applied, the persistent user data are moved to the UDR and concerned NEs are becoming Application-FEs (NE-FEs).
- 左侧的“旧世界” (Non-UDC Network)：王工指着图中错综复杂的连线和分散的数据库图标，“看，这就是小林刚才说的‘数据孤岛’。每个NE（网络元素）都带着自己的小数据库，数据同步和管理就像一团乱麻。OSS系统要分别对接不同的NE来进行数据开通，效率低下。”
- 右侧的“新世界” (UDC Network)：王工的激光笔移到图的右侧，“现在，一切都变得井然有序。所有的‘小数据库’都被一个庞大而统一的UDR取代。原来的NE都‘瘦身’成了无状态的NE-FE。OSS系统现在只需要对接一个统一的开通接口（Provisioning Interface），就能管理所有用户数据。网络接口（Network Interface）本身并没有改变，这意味着对外部网络的兼容性极好。”
“从‘各自为政’到‘中央集权’，这就是UDC在架构层面带来的最根本的变革。”王工总结道。
2. 架构下的核心角色：功能实体深度剖析 (4.2 Functional Entities)
“理解了宏观蓝图，我们现在来深入认识一下这张蓝图上的核心‘演员’们。”王工进入了培训的第二部分。
2.1 应用前端 (FE): 网络的“无状态”大脑 (4.2.1)
Functional entities, such as the HLR/HSS/AUC, Application Servers… when the UDC architecture is applied, keep the application logic, but they do not locally store user data permanently. These data-less functional entities are collectively known in the UDC architecture as Application Front Ends.
“‘无状态’（Stateless）或‘无数据’（Data-less），是FE最核心的标签，”王工解释道，“大家可以把FE想象成一个技艺高超的厨师。他拥有所有的菜谱（业务逻辑）和烹饪技巧（处理能力），但是他自己的厨房里，不存放任何食材（用户数据）。”
“当客人点菜时（一个业务请求到达），厨师会从一个中央食材仓库（UDR）按需领取所有需要的食材，在自己的工作台（本地内存）上进行烹饪。菜品完成后（业务响应发出），他会把工作台清理得干干净净，不留下任何食材的痕迹。这样，他随时可以接待下一位客人，烹饪一道完全不同的菜肴。”
“这种模式的好处是显而易见的，”王工补充道，“我们可以雇佣一大群拥有相同菜谱的厨师（FE集群），任何一位客人可以由任何一位空闲的厨师来服务。即使有一位厨师生病了（FE故障），也完全不影响餐厅的运营。这就是无状态带来的极致弹性和高可用性。”
2.2 开通前端 (PFE): 数据的“大管家” (4.2.2)
A Provisioning Front End is an Application Front End for the purpose of provisioning the UDR. A Provisioning Front End provides means to create, delete, modify and retrieve user data.
“如果说普通的FE是处理实时业务的‘厨师’，那么开通前端（PFE）就是管理中央食材仓库的‘大管家’，”王工继续他的比喻，“它的主要工作，就是和外界的供应商（OSS/BSS系统）打交道，负责新食材的入库（创建用户）、过期食材的清理（删除用户）以及食材信息的变更（修改业务）。”
The UDC may support the following provisioning possibilities… Provisioning from self care systems interfacing subscribers… Provisioning via Applications servers…
王工还提到了PFE的两种常见形式：一种是面向运营商内部的、与OSS/BSS对接的大型管理系统；另一种则可能面向最终用户，例如用户通过手机营业厅App自助办理业务，这个App的后台系统，实际上也扮演了一个PFE的角色。
2.3 用户数据存储库 (UDR): 唯一的数据真理之源 (4.2.3)
“现在，我们来认识我们架构中最重要的角色——UDR。它是整个UDC世界的‘定海神针’。”
The User Data Repository (UDR) is a functional entity that acts as a single logical repository that stores converged user data… UDR facilitates the share and the provisioning of user-related data throughout services of 3GPP system.
“请大家特别注意‘single logical repository’这个词，”王工强调，“‘Logical’意味着，在物理上，UDR可以是一个由多台服务器组成的、地理上分布式的、具备高度冗余和灾备能力的复杂集群。但对于所有的FE来说，它们看到的UDR只有一个，它就是一个逻辑上统一的、唯一的‘数据真理之源’（Single Source of Truth）。”
接着，王工详细剖析了UDR的“内心世界”——它存储什么，不存储什么。
UDR的“收藏清单”：
- Permanent subscriber data: this is subscription data and relates to the necessary information the system ought to know to perform the service… This kind of user data has a lifetime as long as the user is permitted to use the service…
- Temporary subscriber data: this is data which may be changed as a result of normal operation of the system or traffic conditions (e.g. transparent data stored by Application Servers for service execution, SGSN number, user status, etc.).
- 永久性数据：王工解释说，这就像一个人的“户口本”信息，例如用户的IMSI、MSISDN、签约的基础套餐包、鉴权密钥等。这些信息在用户的整个生命周期内都相对稳定。
- 临时性数据：这更像一个人的“动态状态卡”，例如用户当前的SGSN/MME地址、在线/离线状态、由AS存储的业务执行过程中的临时数据等。这些数据会随着网络运行而频繁变化。
UDR的“拒绝收藏清单”：
It shall not be required that the UDR stores the following types of data:
- User-content data: content defined by the user and that may be quite large in size (e.g. Photos, videos, SMS, voice mail).
- User data that concerns event data records… for user profiling…
- User traffic data: …call-related or session-related dynamic data (e.g. MSRN, P-TMSI)…
“UDR是有原则的，不是所有数据都往里放，”王工解释了拒绝收藏的原因：
- 用户内容数据：如照片、短信、语音留言等。这些数据体量巨大，存储和访问模式与信令数据完全不同，UDR不适合管理它们。
- 事件数据记录（EDR）：如用户的上网行为、通话详单等，主要用于计费和大数据分析，属于不同的数据范畴。
- 用户流量数据：如为一次呼叫临时分配的MSRN，或在一次附着中临时使用的P-TMSI。这些数据生命周期极短，且通常只被单个NE使用，没有在FE间共享的必要，因此不应存入UDR，以免造成不必要的读写开销。
最后，王工强调了UDR的“安全职责”：
Application FEs should only be able to access the user data after proper authentication and authorization… The UDR shall take care of the authorization of the access to the user data.
“UDR不仅仅是个仓库，它还是个带门禁的、戒备森严的‘金库’。它必须对每一个试图访问它的FE进行严格的身份认证和权限检查，确保只有合规的FE才能在授权范围内访问特定的数据。”
3. Ud参考点: 架构的“神经总线” (4.3 Reference point Ud)
“认识了各位‘演员’，我们再来看看连接它们的‘舞台’——Ud接口。”
This reference point shall allow the different FEs to create, read, modify and delete user data stored in the UDR using the harmonized access interface.
“‘Harmonized access interface’（统一的访问接口）是这里的关键词，”王工说，“无论FE是HLR-FE、HSS-FE还是AS-FE，无论它想操作的是CS签约数据还是IMS业务数据，它们都使用同一种‘语言’，通过Ud接口与UDR对话。这种统一性，极大地简化了FE的开发和UDR的设计。”
Reference point Ud shall support transactions. Operations and transactions carried out over Ud shall support the ACID (Atomicity, Consistency, Isolation, and Durability) characteristics.
“更重要的是，这条‘神经总线’是极其可靠的。它支持ACID事务。小林，你能解释一下ACID吗？”
小林回答道：“王工，我知道。ACID就像一次银行转账。原子性（Atomicity）意味着转账要么完全成功，要么完全失败，不会出现钱扣了但对方没收到的情况。一致性（Consistency）保证了转账前后，银行的总账是平的。隔离性（Isolation）确保了我的转账过程不会被其他并发转账干扰。持久性（Durability）则表示一旦转账成功，这个结果就是永久的，即使银行系统重启也不会丢失。”
“非常棒的比喻！”王工赞许道，“Ud接口的ACID特性，保证了在UDC架构下，所有的数据操作都是安全、可靠、一致的。”
4. 解密“无状态”：FE会话与UDR会话 (4.4 & 4.5)
“最后，我们来解开FE‘无状态’这个听起来有点抽象的概念。规范通过定义‘FE-Session’，为我们揭示了其具体的工作机制。”
4.1 FE会话 (Front-End Session): “阅后即焚”的工作模式
An FE-Session starts either with the receipt of a request message… or with receipt of a notification message on the Ud interface… Before an FE-Session starts, the FE does not have any user data stored. During an FE-Session the FE … may read user data from the UDR and store them temporarily locally; After completion of an FE-Session, the FE does not have any user data stored… it shall delete all temporarily locally stored user data when the FE-Session is completed.
王工用一个生动的流程来总结FE会话的生命周期：
- 开始：一个外部请求（如MAP Update Location）或一个内部通知（Ud-Notify）到达FE，FE会话启动。
- “空空如也”：会话开始前，FE的内存里关于任何用户的数据都是空的。
- 按需取数：在会话期间，FE根据业务逻辑需要，向UDR查询所需数据，并临时缓存在本地内存中。
- 处理业务：FE利用这些临时数据，完成信令交互、逻辑判断等所有工作。
- 结束与清除：当业务响应发出，会话完成时，FE必须执行一个关键动作——删除所有在本次会话中临时存储的用户数据。
- 回归“无状态”：会话结束后，FE的内存再次变得“空空如也”，准备好处理下一个完全无关的请求。
“这个‘阅后即焚’的工作模式，就是FE实现无状态的秘诀，”王工总结道。
4.2 UDR会话 (UDR Session): “金库”的严谨操作
When receiving a read-request the UDR shall check whether the requesting FE is allowed to read the requested data… When receiving a write-request the UDR shall check whether the requesting FE is allowed to write the requested data… otherwise the UDR shall… perform the write-request and return a successful response…
“UDR会话，则是从‘金库’管理员的视角来看待一次交互，”王工说，“它的流程非常严谨：收到请求 → 检查权限 → 执行操作 → 返回结果。每一步都离不开安全和授权的检查，确保了中央数据的绝对安全。”
培训的最后，王工总结道：“今天我们一起搭建了UDC架构的完整骨架。我们看到了它如何通过分层、分离、统一和无状态这四大法宝，解决了传统网络的顽疾。在接下来的培训中，我们将为这个骨架填充血肉，看看具体的数据操作流程是如何在这套优美的架构上运行的。”
FAQ 环节
Q1：UDC架构最核心的设计思想是什么？它与传统网络架构最根本的区别在哪里？ A1：UDC最核心的设计思想是**“数据与应用逻辑的分离”**。最根本的区别在于，传统架构中，数据和处理逻辑紧密耦合在同一个网元实体中（如HLR、HSS），形成了“数据孤岛”；而在UDC架构中，数据被集中到逻辑上统一的UDR中，而应用逻辑则由无状态的FE来处理，两者通过标准的Ud接口解耦。
Q2：有人说UDR就是一个超大的数据库，这种说法准确吗？ A2：不完全准确。虽然UDR的核心功能是数据存储，但它远不止一个数据库。它是一个具备高级功能的数据服务实体，包括：1）统一的数据模型和视图管理；2）严格的访问控制，对每个FE的请求进行认证和授权；3）支持ACID事务，保证数据操作的可靠性和一致性；4）具备事件驱动能力，可以处理订阅和发送通知。因此，称其为“用户数据服务中心”可能更为贴切。
Q3：FE（应用前端）的“无状态”（Stateless）特性是如何实现的？这样做最大的好处是什么？ A3：“无状态”是通过FE会话（FE-Session）机制实现的。在一个FE会话的生命周期中，FE只在处理请求的期间，将所需的用户数据临时从UDR读取到本地内存。一旦会话结束（请求处理完毕），FE必须清除所有这些临时数据。这样做最大的好处是实现了计算资源和存储资源的分离与池化，带来了极高的弹性和可靠性。任何一个FE都可以处理任何用户的请求，可以轻松实现负载均衡，并且单个FE的故障不会影响整体服务，因为请求可以立即由集群中的其他FE接管。
Q4：为什么UDR不存储用户的短信、照片、语音邮件等内容数据？ A4：主要是因为这些用户内容数据与UDC所管理的信令与签约数据在多个维度上存在巨大差异：
- 数据体量：内容数据通常非常大（MB甚至GB级别），而签约数据很小（KB级别）。
- 访问模式：内容数据的访问频率、读写模式与信令数据完全不同。
- 共享需求：签约数据需要在多个核心网FE之间共享，而内容数据通常只被特定的应用（如短信中心、彩信中心）访问。 将这两种截然不同的数据放在同一个存储系统中，会造成架构臃肿和性能瓶颈。因此，UDC专注于管理对网络运行至关重要的、共享的、小颗粒度的签约和状态数据。
Q5：Ud接口的“统一”（Harmonized）和“支持ACID事务”这两个特性，分别有什么重要意义？ A5：
- 统一（Harmonized）的意义在于简化和标准化。它意味着无论上层业务多么五花八门，到了数据访问层，都使用同一种语言（协议）和同一种方式与UDR交互。这大大降低了新业务FE的开发难度，也使得UDR可以稳定地提供标准服务，而不必为每个新业务进行定制。
- 支持ACID事务的意义在于可靠和一致。它保证了对UDR的所有数据操作，都像银行交易一样严谨，不会出现数据损坏、丢失或不一致的情况，尤其是在高并发和异常情况下。这是电信级服务（Carrier-Grade）可靠性的基本要求。