51学通信

深度解析 3GPP TS 28.552：5.6 UDM Measurements (5G用户的“数字灵魂”档案库)

17分钟阅读

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

深度解析 3GPP TS 28.552：5.6 UDM Measurements (5G用户的“数字灵魂”档案库)

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

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

“王哥，客服部门转来一个奇怪的投诉，”小林皱着眉头说，“用户张女士在手机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.6节。“‘Performance measurements for UDM’，这一节就是对我们这位核心‘档案管理员’的绩效考核。它监控着UDM对外提供数据查询（Getting）、**数据订阅（Subscription）和对内进行数据维护（Provisioning）**的全过程。今天，我们就来学习如何通过这些测量，确保每一个用户的‘数字灵魂’——他的签约数据和身份信息——都能被网络准确、高效地管理。”

1. “档案库”的规模：用户注册数测量 (5.6.1 - 5.6.4)

UDM/UDR是全网用户数据的汇聚中心，因此，首先需要了解其承载的用户规模和压力。

5.6.1 Mean number of registered subscribers through UDM (RM.RegisteredSubUDMNbrMean) 5.6.2 Maximum number of registered subscribers through UDM (RM.RegisteredSubUDMNbrMax) 5.6.3 Mean number of unregistered subscribers through UDM (RM.UnregisteredSubUDMNbrMean) 5.6.4 Maximum number of unregistered subscribers through UDM (RM.UnregisteredSubUDMNbrMax)

  • 深度解析: 这组测量RM.Registered... (Registration Management) 从UDM的视角，统计了网络中的用户状态。
    • Registered subscribers: 指的是当前在某个AMF上成功注册的UE。UDM通过AMF的注册/去注册通知来维护这个状态。Mean和Max分别统计其平均数和峰值数，反映了UDM需要处理的活跃用户规模。
    • Unregistered subscribers: 指的是在UDM中有签约数据，但当前未在任何AMF注册的UE（如关机、长期离网）。这个指标反映了UDM管理的总用户档案规模。 这组数据是UDM容量规划和资源评估的基础。

2. “查档”服务效率：Subscriber Data Management - Subscription Data Getting (5.6.8.1)

当一个NF（如AMF或SMF）需要获取用户的签约数据时，它会向UDM发起一个Get请求。这是UDM最核心的对外服务之一。

5.6.8.1.1 Number of subscription data getting requests (SDM.GetReq.Type) c) Receipt of an Nudm_SDM_Get request by the UDM from a consumer NF… each message increments the relevant subcounter per subscriber data type by 1.

5.6.8.1.2 Number of successful subscription data gettings (SDM.GetSucc.Type) 5.6.8.1.3 Number of failed subscription data gettings (SDM.GetFail.Cause)

  • 深度解析: SDM.Get... (Subscriber Data Management) 监控了数据查询的全过程。

    • Req (请求数): 统计UDM收到了多少次Get请求。
    • Succ (成功数): UDM成功从UDR获取数据并返回给请求方的次数。
    • Fail.Cause (失败数及原因): 查询失败的次数，按Cause细分。
    • 关键过滤维度 (Type): subscriber data type，即查询的数据类型。例如，AMF可能查询“接入和移动性签约数据”，SMF可能查询“会话管理签约数据”，AUSF可能查询“鉴权签约数据”。按Type细分，可以评估UDM对不同NF的服务性能。

  • 场景化诊断：SMF拿不到新套餐信息 在张女士的案例中，SMF在为她建立PDU会话时，向UDM发起了Get(Type=SessionManagementSubscriptionData)请求。

    • 正常情况: UDM应该返回包含了“5G畅玩”套餐（如更高的QoS Profile和速率限制）的最新签约数据。
    • 问题排查: 小林查看UDM的日志和测量数据。如果SDM.GetSucc计数正常，但返回的数据内容是“旧”的，则说明UDM自身从UDR获取的数据就是旧的，问题指向了UDR的数据同步或后台数据配置。如果SDM.GetFail计数增加，则说明UDM在查询过程中就遇到了错误。

3. “档案更新”的实时通知：SDM Subscription & Notification (5.6.8.2 & 5.6.8.3)

为了避免每次需要数据时都去查询，NF（如AMF、SMF）可以向UDM订阅某个用户数据的变更通知。当后台系统修改了用户数据后，UDM（或UDR）会主动将更新推送给所有订阅者。

5.6.8.2 SDM subscription (SDM订阅)

  • SDM.SubscribeReq.Type
  • SDM.SubscribeSucc.Type
  • SDM.SubscribeFail.Cause

5.6.8.3 Subscription data notification (订阅数据通知)

  • SDM.SubDataNotif.Type

  • 深度解析:

    • SDM.Subscribe...: 监控NF向UDM发起订阅请求的成功/失败情况。订阅的成功，是后续能收到通知的前提。
    • SDM.SubDataNotif.Type: 这是一个关键的测量项，它统计UDM主动向外发送了多少次数据变更的Notification消息。

  • 场景化诊断：缺失的“变更通知” 在张女士的案例中，最可能的原因是通知流程出了问题。

    1. 当张女士的“5G畅玩”套餐在BSS/OSS系统生效后，数据被写入UDR。
    2. UDR应该检测到数据变更，并通知UDM。
    3. UDM应该向之前已经订阅了张女士会话数据的SMF，发送一次Nudm_SDM_Notification。
    4. SMF收到通知后，更新其本地缓存的张女士签约数据。下次张女士上网时，SMF就会按照新的QoS策略来建立会话。

    小林查看SDM.SubDataNotif的日志，发现在张女士套餐变更后的很长一段时间里，UDM并没有向服务于她的SMF发送任何Notification消息。 洞察： 问题被进一步聚焦到UDM/UDR的内部变更检测和通知触发机制上。SDM.SubDataNotif这个计数器的“不作为”，成为了本次故障诊断的核心证据。它说明“档案管理员”虽然知道了档案更新，但忘记或没能成功地将更新通知单“派发”出去。

4. “档案录入”的后台操作：Parameter Provisioning (5.6.9)

除了对外提供服务，UDM还负责接收来自外部系统（如NEF、AF）的**数据配置（Provisioning）**请求，并将其写入UDR。这相当于“档案室”接收外部单位送来的新档案。

5.6.9.1 Parameter creations (参数创建) 5.6.9.2 Parameter update (参数更新) 5.6.9.3 Parameter deletion (参数删除) 5.6.9.4 Parameter getting (参数获取)

  • 深度解析: PPV... (Parameter Provisioning) 这一整套测量，监控的是UDM作为数据写入方时的性能。它涵盖了由外部NF（通常是NEF，作为外部AF的入口）对UDR中的数据进行Create, Update, Delete, Get的全过程。
  • 场景化应用： 例如，一个企业客户通过自服务门户，为其员工动态调整“车联网切片”的访问权限。这个操作会通过AF → NEF → UDM的路径，最终修改存储在UDR中的企业签约数据。PPV.UpdateSucc和PPV.UpdateFail的测量，就直接关系到这个企业自服务功能的可靠性。

结论：UDM测量——5G网络数据生命周期的“金标准”

通过对“套餐升级”失败案例的层层剖析，我们看到，UDM作为5G数据的“大管家”，其性能的稳定可靠，是整个核心网逻辑自洽、策略一致的基础。5.6节的测量体系，为我们提供了一套完整的“数据生命周期管理”的审计工具。

  1. 用户规模 (RegisteredSub)：提供了UDM的容量基线和负载画像。
  2. 数据查询 (SDM.Get)：衡量了UDM最核心的**“读”服务性能**，是保障所有NF获取数据及时性的关键。
  3. 数据订阅与通知 (SDM.Subscribe/Notif)：衡量了UDM**“主动推送”服务**的可靠性，是保障SBA架构下数据实时同步的“生命线”。
  4. 数据配置 (PPV)：衡量了UDM的**“写”服务性能**，确保了来自外部和后台的数据能够被准确、可靠地录入到网络中。

这一整套测量，确保了每个用户的“数字灵魂”在创建、查询、修改、同步和删除的每一个环节，都有据可查、有迹可循。它不仅是诊断复杂信令问题的利器，更是实现5G网络自动化、智能化、可编程的数据基石。

FAQ 环节

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

Q2：Subscriber Data Management (SDM) 和 Parameter Provisioning (PPV) 有什么区别？ A2：它们的主要区别在于数据的“消费者”和“生产者”。SDM（用户数据管理）的场景，通常是核心网内部的NF（如AMF, SMF）作为“消费者”，向UDM请求获取它们履行自身职责所必需的用户数据。而PPV（参数配置）的场景，通常是外部的功能实体（如通过NEF代理的AF）作为“生产者”或“管理者”，向UDM请求写入、修改或删除应用层相关的用户数据或策略数据。前者是“为了网络运行而读”，后者是“为了业务使能而写”。

Q3：一个SMF在本地缓存了用户数据后，如果UDM宕机了，PDU会话还能正常工作吗？ A3：对于已经建立的PDU会话，可以继续正常工作。因为SMF和UPF已经根据从UDM获取的策略，建立好了N4会话和数据转发路径。但是，如果UDM宕机：1）新的PDU会话将无法建立，因为新的SMF实例无法获取用户的签约数据。2）所有策略变更都将无法执行，例如，PCF无法通过UDM下发新的QoS或计费策略。3）用户数据的变更将无法同步，如此文中的“套餐升级”将无法通知到SMF。因此，UDM的高可用性对于网络的动态管理和新业务受理至关重要。

Q4：为什么需要测量Unregistered subscribers（未注册用户数）？这个指标有什么用？ A4：这个指标主要用于UDM/UDR自身的容量规划和数据库管理。Registered subscribers反映的是UDM需要频繁处理的“热数据”的规模，而Total subscribers = Registered + Unregistered则反映了UDR中存储的“全量数据”的规模。了解总用户数，对于数据库的存储容量、备份策略、许可证（License）管理都至关重要。例如，运营商可以根据总用户数的增长趋势，来规划UDR数据库的扩容计划。

Q5：这些UDM的测量项，能帮助我定位漫游问题吗？ A5：能提供关键的线索。在漫游场景下，拜访地网络的V-SMF或AMF需要通过归属地网络的H-UDM来获取用户数据。

  • 如果SDM.GetFail.cause在H-UDM侧有大量增长，且失败原因是权限类的，可能说明归属地网络没有为该漫游伙伴正确配置访问策略。
  • 如果SDM.GetFail.cause是超时类的，则问题可能出在归属地网络和拜访地网络之间的国际信令链路上（IPX）。
  • 如本文案例所示，如果是DATA_NOT_FOUND，则说明归属地UDR的数据本身就存在问题。 通过分析UDM的测量数据，可以将复杂的国际漫游问题，分解为“数据问题”、“策略问题”或“链路问题”。

关系图谱