好的，我们继续进行系列的下一篇深度解读。

深度解析 3GPP TS 28.552：5.13 UDR Measurements (5G数据的“中央档案室”)

本文技术原理深度参考了3GPP TS 28.552 V18.10.0 (2025-03) Release 18规范中，关于“5.13 Performance measurements for UDR”的核心章节，旨在为读者提供一个关于5G网络统一数据存储功能的性能测量全景解析。

引言：一次跨国漫游引发的“身份迷失”

“王哥，出问题了！”小林指着一张全球网络拓扑图，神情凝重，“我们集团的CEO，李总，他现在正在欧洲参加世界移动通信大会。他刚刚发来紧急求助，说他的手机在漫游到当地合作运营商的网络后，无法建立任何数据业务，彻底‘失联’了。但当地运营商反馈说，李总的手机已经成功注册到了他们的网络上。”

老王立刻意识到问题的严重性。“注册成功，但无法建立业务。这通常意味着，虽然‘海关’（AMF）已经查验了李总的‘护照’（SIM卡信息），确认了他的身份，但当本地的‘业务大厅’（SMF）试图查询李总的‘详细档案’（签约了哪些数据业务、QoS权限如何）时，却失败了。”

“在5G网络中，所有用户的这些结构化数据——包括签约数据、策略数据、应用数据等等——都统一存放在一个被称为UDR (Unified Data Repository) 的网元里。它就像是整个5G网络的‘中央档案室’，”老王解释道，“而负责管理和对外提供这些档案查询服务的，是UDM (Unified Data Management)。当李总在海外漫游时，当地的SMF就需要跨越千山万水，通过UDM，来访问我们国内的UDR，调取他的签约档案。如果这个‘跨国调档’的过程出了问题，李总自然就无法使用任何数据业务。”

他将TS 28.552的屏幕切换到5.13节。“‘Performance measurements for UDR’，这一节就是我们为这个‘中央档案室’设计的‘绩效考核系统’。它监控着每一次‘查档’、‘建档’、‘改档’和‘销档’操作的效率和成功率。李总的这次‘身份迷失’，很可能就是UDR或UDM与海外运营商网络之间的数据交互出了问题。今天，我们就来学习如何通过这些测量，来保障5G全球化服务的数据基石。”

1. “档案”的查询与检索：Data set query (5.13.1.1)

当一个NF（如UDM, PCF, NEF）需要获取用户的某类数据时，它会向UDR发起一次数据查询请求。这是UDR最核心、最频繁的服务。

5.13.1.1.1 Number of data set query requests (DM.QueryReq) c) Receipt of an Nudr_DM_Query request by the UDR from an NF service consumer…

5.13.1.1.2 Number of successful data set queries (DM.QuerySucc) c) Transmission of an Nudr_DM_Query response by the UDR to an NF service consumer indicating a successful data set query…

5.13.1.1.3 Number of failed data set queries (DM.QueryFail.cause) c) …each message increments the relevant subcounter per failure cause by 1.

1.1 深度解析

这组测量DM.Query... (Data Management) 监控了数据查询的全过程。

• 测量对象: 外部NF向UDR发起的Query请求。这些请求查询的是一整“套”数据（data set），例如，某个用户的完整签约数据、某个UE的策略控制数据等。
• Req (请求数): UDR收到了多少次查询请求，反映了UDR的查询负载。
• Succ (成功数): UDR成功找到数据并返回响应的次数。
• Fail.cause (失败数及原因): UDR查询失败的次数。失败原因至关重要，可能包括DATA_NOT_FOUND（数据不存在）、ATTRIBUTE_NOT_FOUND（请求的特定属性不存在）或UDR内部数据库错误等。

数据查询成功率 = Succ / Req，是衡量UDR服务可用性的核心KPI。

1.2 场景化诊断：李总的“签约数据迷航”

为了诊断李总的问题，国内的运维团队立刻查看了UDR的性能数据。他们通过李总的SUPI（用户永久标识），过滤出了与他相关的查询日志和测量数据。

他们发现，在李总尝试建立数据业务的时间点，UDR的DM.QueryReq计数器有增长，请求方正是UDM。但紧接着，DM.QueryFail.cause_DataNotFound这个子计数器也同步增长了！

“王哥，找到了！”小林分析道，“UDM确实来查询李总的签约数据了，但是UDR回复说‘查无此人’（Data Not Found）！这怎么可能，他是我们的CEO啊！”

老王眉头一皱：“问题可能出在UDM和UDR之间的数据同步上。可能是因为李总刚换了新的5G套餐，数据从BSS/OSS系统同步到UDR时出现了延迟或错误。也可能是漫游场景下，海外运营商传过来的用户标识有问题，导致UDM用了错误的索引来查询。”

洞察： UDR的查询失败测量，特别是按cause码细分的失败统计，为复杂的核心网信令问题提供了精准的定界依据。一个简单的DATA_NOT_FOUND，就能将排查范围从复杂的国际漫游链路，迅速聚焦到数据本身的一致性和同步问题上。

2. “档案”的增删改：Data record creation/deletion/update (5.13.1.2 - 5.13.1.4)

UDR不仅要提供查询，还需要支持对数据的动态管理，即增、删、改。

5.13.1.2 Data record creation (数据记录创建)

• DM.CreateReq (请求数)
• DM.CreateSucc (成功数)
• DM.CreateFail.cause (失败数及原因)

5.13.1.3 Data record deletion (数据记录删除)

• DM.DeleteReq
• DM.DeleteSucc
• DM.DeleteFail.cause

5.13.1.4 Data record update (数据记录更新)

• DM.UpdateReq
• DM.UpdateSucc
• DM.UpdateFail.cause

2.1 深度解析

这三组测量，分别监控了对UDR中**单个数据记录（Data Record）**的创建、删除和更新操作。

• 创建 (Create): 当一个新用户开户，或一个应用首次为用户创建数据（如AF为用户创建应用相关数据）时，会触发Create操作。
• 删除 (Delete): 用户销户或删除应用数据时，触发Delete操作。
• 更新 (Update): 用户变更套餐、修改策略或应用数据更新时，触发Update操作。

这些测量项的逻辑与Query测量完全一致，都通过请求数、成功数和失败数（按原因细分），来全面评估UDR的数据写入和修改能力。

2.2 场景化应用：保障业务开通与变更的成功率

• 业务开通: 当大量用户在“双十一”期间抢购新套餐时，BSS/OSS系统会通过UDM向UDR发起大量的Create和Update请求。监控DM.CreateSucc和DM.UpdateSucc的成功率，可以实时评估后台系统的开通能力。如果失败率增高，就可能导致用户付费后业务却迟迟无法生效。
• 策略变更: PCF（策略控制功能）可能会根据网络拥塞情况，通过NEF，请求AF（应用功能）更新存储在UDR中的应用数据（如视频码率建议）。DM.UpdateSucc的成功率，决定了这种动态策略调整是否能被有效执行。

3. “档案”的订阅与通知：Data modification notification subscription (5.13.1.5)

在SBA架构下，NF之间更高效的交互方式是“订阅-通知”模型。一个NF（如UDM）可以向UDR订阅某个用户数据的变更事件。当该数据发生变化时，UDR会主动将变更信息通知给所有订阅者。

5.13.1.5.1 Number of data modification notification subscribing requests (DM.SubscribeReq) 5.13.1.5.2 Number of successful data modification notification subscribings (DM.SubscribeSucc) 5.13.1.5.3 Number of failed data modification notification subscribings (DM.SubscribeFail.cause)

3.1 深度解析与场景应用

这组测量DM.Subscribe...监控的是数据变更订阅流程的性能。

• Req (请求数): 统计UDR收到了多少次订阅请求。
• Succ (成功数): 统计成功建立的订阅关系数量。
• Fail.cause (失败数): 统计订阅失败的次数。

订阅成功率至关重要。例如，AMF会向UDM订阅用户移动性相关的签约数据变更。如果这个订阅失败了，当后台系统修改了用户的漫游权限时，AMF将无法及时收到通知，可能会继续允许或禁止用户的漫游，导致策略不一致。通过监控UDR的订阅成功率（UDM的订阅请求最终会触发UDR的内部操作），可以保障核心网各NF之间数据同步的实时性和准确性。

结论：UDR测量——5G数据一致性的“守护者”

通过对李总“身份迷失”事件的分析，我们认识到，UDR作为5G网络的“中央档案室”，其性能直接关系到整个网络的数据一致性和业务逻辑的正确性。5.13节的测量体系，为我们提供了一套完整的“档案管理绩效考核”工具。

1. 读操作监控 (Query): 评估了UDR最核心的数据查询服务的性能，其成功率和失败原因是核心网业务流程故障诊断的关键入口。
2. 写操作监控 (Create/Delete/Update): 评估了UDR的数据管理能力，保障了用户开户、销户、业务变更等后台流程的顺畅。
3. 订阅机制监控 (Subscribe): 评估了UDR主动通知能力的可靠性，是保证SBA架构下各NF间数据状态实时同步的基础。

这套测量体系，共同守护着5G网络最核心的资产——数据。确保每一份数据都能被准确地存储、快速地检索、可靠地同步，是UDR测量的核心使命，也是5G网络能够提供全球化、一致性服务的坚实基石。

---

FAQ 环节

Q1：UDR和UDM是什么关系？为什么有时候请求方是UDM，有时候又是其他NF？ A1：UDR（统一数据仓库）和UDM（统一数据管理）是紧密协作的两个网元。UDR是“数据库”，它负责数据的物理存储和底层的数据操作（增删改查）。UDM是“数据服务接口”和“业务逻辑处理单元”。其他NF（如AMF, SMF）通常不直接与UDR通信，而是向UDM请求数据。UDM再根据业务逻辑，将请求转化为对UDR的底层数据操作（如Query, Create）。但是，也存在一些NF（如PCF, NEF）被授权可以直接访问UDR。因此，UDR的测量项中，其“NF service consumer”可以是UDM，也可以是其他NF。

Q2：Data set query和Data record creation中的“set”和“record”有什么区别？ A2：可以把它们理解为“文件夹”和“文件”的区别。一个**Data set（数据集）通常指的是一类相关数据的集合，例如，一个用户的全部“Subscription Data”（签约数据集）。一次Query请求，可能就是为了获取这整个“文件夹”。而一个Data record（数据记录）**则是这个数据集中一个具体、独立的条目，例如“签约数据”这个文件夹里，有一份叫做“APN配置”的“文件”。Create/Delete/Update操作，通常是针对这样单个的“文件”进行的。

Q3：UDR的性能对用户体验有什么直接影响？ A3：有非常直接的影响，尤其是在业务的初始建立阶段。1）注册时延： UE初始注册时，AMF需要通过UDM从UDR获取鉴权数据和签约数据，UDR的查询时延直接计入总的注册时长。2）PDU会话建立时延： SMF在建立PDU会话时，需要从UDR获取该会话相关的签约信息（如允许的DNN、QoS Profile等），UDR的查询时延会直接影响数据连接的建立速度。3）业务变更失败： 如果用户在营业厅办理了套餐变更，但后台系统更新UDR失败（DM.UpdateFail），那么用户可能会发现新套餐迟迟无法生效。

Q4：为什么需要对UDR的failed操作按cause码进行细分？ A4：这对于故障的快速定界至关重要。例如，一次数据查询失败：

• 如果原因是 DATA_NOT_FOUND，说明UDR本身工作正常，问题出在数据同步或数据源，运维人员应该去检查数据是否存在、用户标识是否正确。
• 如果原因是 UDR_INTERNAL_ERROR 或数据库相关的错误，说明是UDR网元本身或其底层数据库出现了故障，需要UDR的维护专家介入。
• 如果原因是权限相关的错误，则说明是NF间的策略配置出了问题。 没有cause码，所有的失败都是一个笼统的“错误”，排查起来将毫无头绪。

Q5：这些UDR测量项，是否也适用于边缘计算（MEC）场景？ A5：是的。在MEC架构下，可能会出现**边缘UDR（Edge UDR）**的部署，用于存储与边缘应用相关的、需要被快速访问的数据（如UE的位置信息、边缘应用的签约策略等）。此时，本地的PCF、NEF等NF会频繁地查询这个边缘UDR。5.13节定义的这套测量体系，同样适用于对这个边缘UDR的性能进行监控，以保障边缘业务的低时延和高可靠性。