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

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

深度解析 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网络统一数据存储功能的性能测量全景解析。

引言：一次失败的“套餐升级”

“王哥，客服部门转来一个奇怪的投诉，”小林皱着眉头说，“用户张女士在手机App上办理了‘5G畅玩’套餐升级，App显示办理成功，费用也扣了。但她反映，她的上网速率没有任何变化，还是和以前一样。后台数据显示，她的签约信息在BSS/OSS系统里已经更新了，但网络好像‘没看见’。”

老王听完，在核心网架构图上指向了UDM (Unified Data Management, 统一数据管理) 和 UDR (Unified Data Repository)。“小林，BSS/OSS系统是我们的‘业务受理前台’。用户在这里办理业务，就像是修改了一份纸质档案。这份档案必须被准确无误地录入到网络的‘中央数字档案室’——UDR中，并且需要通过‘档案管理员’——UDM——对外提供权威的查询服务，才能真正生效。”

“张女士的案例，问题很可能出在‘档案流转’的某个环节。要么是新档案没有成功录入（UDR问题），要么是‘档案管理员’UDM没有把最新的档案信息及时同步给需要它的‘业务部门’（如SMF）。SMF拿到的还是旧档案，自然就按旧的速率为她提供服务了。”

他将TS 28.552切换到5.13节。“‘Performance measurements for UDR’，这一节就是我们为这个‘中央档案室’设计的‘绩效考核系统’。它监控着每一次‘查档’、‘建档’、‘改档’和‘销档’操作的效率和成功率。今天，我们就来学习如何通过这些测量，确保每一个用户的‘数字灵魂’——他的签约数据和身份信息——都能被网络准确、高效地管理。”

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（用户永久标识），过滤出了与她相关的查询日志和测量数据。

他们发现，在张女士套餐升级后，SMF（通过UDM）来查询她的会话管理签约数据时，DM.QueryReq计数器有增长，DM.QuerySucc也成功计数。但通过信令追踪发现，UDR返回的数据包内容，依然是旧的“4G畅享”套餐信息！

“王哥，这下清楚了！”小林分析道，“问题不在于UDR的‘查询’服务本身，而在于UDR存储的数据内容没有被及时更新。UDM和SMF都拿到了‘档案’，但拿到的是一份‘过期档案’。”

洞察： UDR的查询测量，能够帮助我们判断服务本身是否可用。结合信令内容分析，则能进一步判断数据内容是否准确。这个案例将问题的矛头，从核心网的实时信令流程，指向了更上游的数据写入和同步流程。

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

现在，调查的焦点转向了“新档案”是如何被写入UDR的。BSS/OSS系统在完成套餐变更后，会通过Nudm接口，向UDR发起一次数据更新操作。

5.13.1.2 Data record creation (数据记录创建) 5.13.1.3 Data record deletion (数据记录删除) 5.13.1.4 Data record update (数据记录更新)

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

2.1 深度解析

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

• Update (更新): 这是张女士案例的核心。当BSS/OSS系统需要更新她的套餐信息时，会向UDR发起Update请求。
  • UpdateReq: UDR收到了多少次更新请求。
  • UpdateSucc: UDR成功将数据写入底层数据库，并返回成功的次数。
  • UpdateFail.cause: 数据更新失败的次数，按原因细分（如“记录不存在”、“无效的请求格式”等）。

2.2 场景化诊断：“更新失败”的铁证

小林调取了张女士套餐变更时间点的DM.Update...测量数据。结果一目了然：

• DM.UpdateReq 计数增加了1。
• 但 DM.UpdateSucc 计数没有变化。
• 相反，DM.UpdateFail.cause_RECORD_NOT_FOUND （假设的原因码）计数增加了1！

“王哥，真相大白！”小林几乎喊了出来，“BSS系统确实来更新数据了，但是UDR返回了‘记录不存在’的失败！很可能是因为BSS系统传递过来的用户标识（如GPSI）与UDR中存储的主键（SUPI）没有正确匹配上，导致UDR在自己的‘档案柜’里找不到张女士的这份档案，更新操作自然就失败了！”

洞察： UDR的数据写入/更新测量，是保障后台业务与核心网数据同步的关键。UpdateFail的计数和其cause码，为排查这类复杂的跨系统数据一致性问题，提供了最直接、最底层的证据。

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

这个测量项我们已在UDM章节有所了解，它监控的是NF向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)

• 深度解析: DM.Subscribe...监控的是订阅这个动作本身的成功率。一个成功的订阅，是后续UDR能够向订阅者（如UDM）主动推送数据变更通知的前提。如果DM.SubscribeSucc成功率低，那么即使后台数据成功更新到UDR，UDM也可能因为没有成功“挂号”，而收不到变更通知，从而导致其本地缓存的数据一直是旧的。

• 场景化补充: 在张女士的案例中，如果DM.UpdateSucc是成功的，但SMF拿到的仍然是旧数据，那么下一个排查点就是UDR到UDM，以及UDM到SMF的通知链条。DM.SubscribeSucc的成功率，就是这个链条的第一环。

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

通过对张女士“套餐升级”失败事件的层层递进式诊断，我们深刻体会到UDR作为5G网络“中央档案室”的极端重要性。它的性能，直接决定了整个网络的数据一致性和业务逻辑的正确性。

1. 读操作监控 (Query): 保证了网络在运行时，能够准确、快速地获取到决策所需的用户数据。
2. 写操作监控 (Create/Delete/Update): 保证了来自后台系统的数据变更能够被可靠地录入，是业务开通、变更、销户流程的基石。
3. 订阅机制监控 (Subscribe): 保证了数据变更能够被主动、实时地同步给所有相关方，是SBA架构动态协同的基础。

5.13节的这套测量体系，为UDR的数据**“存、取、改、同步”**全生命周期，提供了一套完整的性能和可靠性度量标准。它就像一位严谨的“档案管理员”，确保了每一个用户的“数字灵魂”，在庞杂的5G网络中，始终是唯一的、最新的、可信的。

---

FAQ 环节

Q1：UDR和UDM的功能到底如何区分？为什么测量项里有时是UDM，有时是UDR？ A1：UDR是纯粹的“数据库后端”，负责数据的物理存储和访问，它不直接暴露给大多数核心网NF。UDM是“数据服务前端”，它封装了对UDR的访问，并加入了业务逻辑，如用户身份鉴权、数据格式转换、向其他NF提供标准化的服务化接口（如Nudm_SDM_Get）等。TS 28.552中，5.6节定义的是对UDM这个“服务功能”的性能测量，而5.13节定义的则是对UDR这个“数据仓库”的性能测量。两者高度相关，但视角不同：UDM测量关注的是对外服务的质量，UDR测量关注的是底层数据操作的性能。

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的性能进行监控，以保障边缘业务的低时延和高可靠性。