首页 › core-network › 5G UDM五服务模型与注册信令全链路解析

5G UDM五服务模型与注册信令全链路解析

一、UDM在5GC架构中的定位与设计哲学

UDM(Unified Data Management,统一数据管理)是5G核心网中最关键的"数据中枢",承担着用户订阅数据管理、认证向量生成、UE上下文维护、事件通知和参数配置等核心职责。在TS 23.501 V18.x Section 5.2.3中,3GPP明确定义了UDM的功能边界——它并非一个简单的数据库,而是一个逻辑功能集合体,内部集成了ARPF(Authentication Repository Processing Function)认证存储处理功能,同时采用前后端分离架构与UDR(Unified Data Repository)协同工作。

这一设计哲学的根源可以追溯到TS 23.335定义的UDC(User Data Convergence)架构。在4G时代,用户数据散落在HSS、SPR、OCS等多个网元中,运营商面临"数据孤岛"的严重问题。5G通过UDM+UDR的前后端分离模型,将业务逻辑(UDM前端的五大服务接口)与数据存储(UDR后端的统一数据仓库)彻底解耦,实现了真正的"一份数据、多个视图"。

┌──────────────────────────────────────────────────────────┐
│                    5GC Service Mesh                       │
│  ┌─────┐  ┌─────┐  ┌─────┐  ┌─────┐  ┌─────┐  ┌─────┐ │
│  │ AMF │  │ SMF │  │ AUSF│  │ SMSF│  │ NEF │  │GMLC │ │
│  └──┬──┘  └──┬──┘  └──┬──┘  └──┬──┘  └──┬──┘  └──┬──┘ │
│     │        │        │        │        │        │      │
│     └────────┴────────┴────────┴────────┴────────┘      │
│                         │ Nudm (SBI)                      │
│  ┌──────────────────────┴──────────────────────────┐     │
│  │                    UDM Frontend                  │     │
│  │  ┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐  │     │
│  │  │ UECM │ │ SDM  │ │ UEAU │ │  PP  │ │  EE  │  │     │
│  │  └──┬───┘ └──┬───┘ └──┬───┘ └──┬───┘ └──┬───┘  │     │
│  │     └────────┴────────┴────────┴────────┘      │     │
│  └─────────────────────┬───────────────────────────┘     │
│                        │ Nudr (SBI)                       │
│  ┌─────────────────────┴───────────────────────────┐     │
│  │                    UDR Backend                   │     │
│  │  ┌──────────┐ ┌──────────┐ ┌──────────────────┐ │     │
│  │  │ 订阅数据  │ │ 策略数据  │ │ 应用/暴露数据    │ │     │
│  │  └──────────┘ └──────────┘ └──────────────────┘ │     │
│  └─────────────────────────────────────────────────┘     │
└──────────────────────────────────────────────────────────┘

二、UDM五大服务接口深度拆解

TS 29.503 V18.x定义了UDM对外暴露的五个Service-Based Interface,每个服务承载着不同维度的数据交互职责。这不是简单的CRUD封装——五个服务之间通过共享的SUPI索引和内部数据一致性机制,构成了一个精密的数据管理引擎。

2.1 Nudm_UECM — UE上下文管理服务

服务操作 HTTP方法 资源路径 消费者 核心IE
Registration PUT /nudm-uecm/v1/{supi}/registrations AMF/SMF guami, backupAmfInfo, ratType, initialRegistrationInd
Deregistration DELETE /nudm-uecm/v1/{supi}/registrations/{type} AMF/SMF deregReason, accessType
Get GET /nudm-uecm/v1/{supi}/registrations AMF/SMF/SMSF —
Update PATCH /nudm-uecm/v1/{supi}/registrations/{type} AMF pei, imsVoPs, backupAmfInfo
DeregistrationNotification POST (callback) {callbackReference} UDM→AMF deregReason

设计意图:UECM本质上是一个"服务NF注册簿"。当AMF完成注册后,它通过Nudm_UECM_Registration在UDM中记录自己是该UE的当前服务AMF。这个信息至关重要——当后续SMF需要为该UE建立PDU会话时,SMF首先查询UDM获取当前服务AMF的地址(即N11接口的对端)。同理,SMF也会在UDM中注册自己作为服务SMF。

关键IE backupAmfInfo(TS 29.503 Section 6.1.6.2.6)是一个容灾设计:AMF向UDM注册时携带备份AMF的GUAMI列表和优先级,当AMF故障时,UDM可以通过DeregistrationNotification通知备份AMF接管UE上下文。

2.2 Nudm_SDM — 订阅数据管理服务

服务操作 HTTP方法 资源路径 消费者 核心IE
Get GET /nudm-sdm/v2/{supi}/am-data AMF accessAndMobilitySubscriptionData
Subscribe POST /nudm-sdm/v2/{supi}/sdm-subscriptions AMF/SMF callbackReference, monitoredResourceUris
Unsubscribe DELETE /nudm-sdm/v2/{supi}/sdm-subscriptions/{subId} AMF/SMF —
Notification POST (callback) {callbackReference} UDM→NF changeType, notificationItems
Modify PATCH /nudm-sdm/v2/{supi}/{data-type} NEF 修改后的订阅数据片段

SDM服务是UDM五个服务中交互最频繁的接口。它采用拉取+推送混合模型:初次注册时NF通过Get拉取完整订阅数据,随后通过Subscribe订阅数据变更通知,后续数据变化时UDM主动推送Notification。

TS 29.503 Section 5.2.2.2定义了SDM_Get的五种数据检索端点:

数据类型端点 返回的数据结构 主要消费者
/am-data AccessAndMobilitySubscriptionData AMF
/sm-data SessionManagementSubscriptionData SMF
/sms-data SmsSubscriptionData SMSF
/nssai Nssai AMF
/ue-context-in-smf-data UeContextInSmfData AMF

2.3 Nudm_UEAU — UE认证服务

认证服务是TS 29.503 Section 5.4定义的,专用于AUSF与UDM之间的认证交互。它包含两个核心操作:

这一分离设计的精妙之处在于:认证向量的生成逻辑封装在UDM的ARPF子功能中,而认证执行的决策和协议交互则由AUSF完成。这种解耦使得同一套认证数据可以同时服务于3GPP接入和非3GPP接入的不同认证场景。

2.4 Nudm_PP — 参数配置服务

Nudm_PP(Parameter Provision)是TS 29.503 Section 5.6定义的服务,专供NEF(Network Exposure Function)通过UDM修改用户订阅数据。典型场景包括:

PP服务的关键设计是权限隔离:NEF只能修改被授权的数据字段,UDM在执行PP_Update前会验证NEF的权限范围。

2.5 Nudm_EE — 事件暴露服务

事件类型 触发条件 消费者
LOSS_OF_CONNECTIVITY UE不可达超过配置时长 NEF/AF
UE_REACHABILITY UE从CM-IDLE变为CM-CONNECTED NEF/AF
LOCATION_REPORT UE位置区变化 GMLC
CHANGE_OF_SUPI_IMEI_ASSOCIATION IMEI/SUPI关联变更 NEF
ROAMING_STATUS 漫游状态变更 NEF/AF
COMMUNICATION_FAILURE 通信失败事件 NEF

EE服务是TS 29.503 Section 5.5定义的事件通知机制。它的工作模式是:NF消费者首先通过Subscribe订阅特定事件,当UDM检测到事件触发条件满足时(通常需要AMF的配合),通过回调URL发送Notification。

三、注册流程中UDM全链路信令时序图

以下时序图展示了UE初始注册过程中,AMF与UDM之间完整的服务调用链(对应TS 23.502 Section 4.2.2.2 Registration Procedure中的步骤14-22):

sequenceDiagram
    participant UE
    participant RAN
    participant AMF as 新AMF
    participant UDM
    participant UDR
    participant AUSF
    participant Old_AMF as 旧AMF

    UE->>RAN: RRC Setup (含Registration Request)
    RAN->>AMF: NGAP Initial UE Message (NAS: Registration Request)

    Note over AMF: Step 14a: 如果old AMF存在<br/>先从old AMF获取UE上下文
    AMF->>Old_AMF: Namf_Communication_UEContextTransfer
    Old_AMF-->>AMF: UE Context (含SUPI, 订阅数据)

    Note over AMF: Step 14b: 鉴权流程
    AMF->>AUSF: Nudm_UEAuthentication_Get Request (SUCI)
    AUSF->>UDM: Nudm_UEAuthentication_Get Request (SUCI)
    UDM->>UDR: Nudr_Query (Authentication Subscription Data)
    UDR-->>UDM: AuthSubscription (K, OPC, algorithm)
    Note over UDM: ARPF生成认证向量
    UDM-->>AUSF: 5G-AKA: RAND, AUTN, HXRES*
    AUSF-->>AMF: RAND, AUTN, HXRES*
    AMF->>UE: NAS Authentication Request
    UE-->>AMF: NAS Authentication Response (RES*)
    AMF->>AUSF: Nudm_UEAuthentication_Result (RES*)
    AUSF->>UDM: Nudm_UEAuthentication_Result
    AUSF-->>AMF: Auth Success

    Note over AMF: Step 14c: UDM注册 (UECM)
    AMF->>UDM: PUT /nudm-uecm/v1/{supi}/registrations/amf-3gpp-access<br/>{guami, backupAmfInfo, ratType}
    UDM->>UDR: PUT /nudr-dr/v1/subscription-data/{supi}/context-data/amf-3gpp-access
    UDR-->>UDM: 201 Created
    Note over UDM: 检测到新AMF ≠ old AMF<br/>触发旧AMF去注册通知
    UDM-->>AMF: 201 Created
    UDM->>Old_AMF: Nudm_UECM_DeregistrationNotification<br/>{deregReason: "NEW_REGISTRATION_5G"}

    Note over AMF: Step 14d: 获取AM移动性订阅数据 (SDM_Get)
    AMF->>UDM: GET /nudm-sdm/v2/{supi}/am-data<br/>GET /nudm-sdm/v2/{supi}/nssai<br/>GET /nudm-sdm/v2/{supi}/ue-context-in-smf-data
    UDM->>UDR: GET /nudr-dr/v1/subscription-data/{supi}/am-data
    UDR-->>UDM: AccessAndMobilitySubscriptionData
    UDM-->>AMF: AmData + Nssai + SmfData

    Note over AMF: Step 14e: 订阅数据变更通知 (SDM_Subscribe)
    AMF->>UDM: POST /nudm-sdm/v2/{supi}/sdm-subscriptions<br/>{callbackReference, monitoredResourceUris}
    UDM->>UDR: POST /nudr-dr/v1/subscription-data/{supi}/context-data/sdm-subscriptions
    UDR-->>UDM: 201 Created
    UDM-->>AMF: 201 Created (subscriptionId)

    Note over AMF: Step 15-22: 后续注册流程
    AMF->>UE: NAS Registration Accept (5G-GUTI, TAI List, Allowed NSSAI)

3.1 关键信令步骤深度解析

Step 14c — UECM Registration详解

AMF向UDM发送PUT /nudm-uecm/v1/{supi}/registrations/amf-3gpp-access请求,请求体包含以下关键字段:

IE名称 类型 含义 运营影响
guami GuamiType AMF的全局唯一标识(MCC+MNC+AMF Region ID+AMF Set ID+AMF Pointer) UDM据此路由后续的DeregistrationNotification
backupAmfInfo BackupAmfInfo 备份AMF的GUAMI和优先级列表 决定AMF故障时的恢复时间
ratType RatType 当前接入类型(NR/E-UTRA等) 影响订阅数据的过滤逻辑
initialRegistrationInd boolean 是否为初始注册 true时UDM需触发旧AMF去注册
pei string 设备标识(IMEISV) 设备追踪和安全审计

UDM收到Registration后执行三重逻辑:

  1. 写UDR:将当前服务AMF信息持久化到UDR的/context-data/amf-3gpp-access资源
  2. 检测AMF变更:如果已注册的AMF GUAMI与本次请求不同,说明UE发生了AMF重选(Inter-AMF Mobility)
  3. 通知旧AMF:通过回调URL向旧AMF发送DeregistrationNotification,deregReason为NEW_REGISTRATION_5G

Step 14d — SDM Get三重拉取详解

AMF在一个事务内向UDM发送三个GET请求:

  1. GET /am-data:拉取AccessAndMobilitySubscriptionData,包含: - nssai:网络切片选择辅助信息 - gpsis:GPSI(通用公共订阅标识符)列表 - subscribedUeAmbr:UE级别的聚合最大比特率 - ratRestrictions:RAT限制列表 - forbiddenAreas:禁止区域列表 - serviceAreaRestriction:服务区域限制(允许/禁止的TA列表)

  2. GET /nssai:拉取Nssai,包含默认S-NSSAI和每个S-NSSAI关联的SD(Slice Differentiator)

  3. GET /ue-context-in-smf-data:拉取UeContextInSmfData,包含当前活跃的PDU会话信息(DNN, S-NSSAI, SMF实例ID)。这个数据在非初始注册场景(如移动性注册更新)中至关重要——AMF需要知道哪些PDU会话需要保持连续性。

Step 14e — SDM Subscribe推送订阅

AMF通过Subscribe操作向UDM注册一个回调URL,订阅以下资源的变更通知:

{
  "callbackReference": "https://amf-01.5gc.mnc.mcc.3gppnetwork.org/nudm-sdm-notification/v1/notify",
  "monitoredResourceUris": [
    "{apiRoot}/nudm-sdm/v2/{supi}/am-data",
    "{apiRoot}/nudm-sdm/v2/{supi}/nssai",
    "{apiRoot}/nudm-sdm/v2/{supi}/sm-data"
  ],
  "expiry": "2026-12-31T23:59:59Z",
  "supportedFeatures": "fffffff"
}

当用户的订阅数据在运营支撑系统(BSS)中被修改时,数据变更通过UDR→UDM→AMF/SMF的链条推送,确保核心网NF始终持有最新的订阅策略。

四、UDM-UDR前后端分离架构与数据一致性模型

graph TB
    subgraph "UDM Frontend(业务逻辑层)"
        A[Nudm_UECM<br/>UE上下文管理]
        B[Nudm_SDM<br/>订阅数据管理]
        C[Nudm_UEAU<br/>认证服务]
        D[Nudm_PP<br/>参数配置]
        E[Nudm_EE<br/>事件暴露]
        F[ARPF<br/>认证存储处理]
    end

    subgraph "UDR Backend(数据存储层)"
        G[Subscription Data<br/>订阅数据集]
        H[Policy Data<br/>策略数据集]
        I[Application Data<br/>应用数据集]
        J[Exposure Data<br/>暴露数据集]
    end

    A -->|Nudr_DataRepository| G
    B -->|Nudr_DataRepository| G
    C -->|Nudr_DataRepository| G
    F -->|Nudr_DataRepository| G
    D -->|Nudr_DataRepository| G
    D -->|Nudr_DataRepository| I
    E -->|Nudr_DataRepository| J

    K[PCF] -->|Nudr| H
    L[NEF] -->|Nudr| I

4.1 UDR数据存储模型(TS 29.505 Section A.2)

UDR的资源路径遵循RESTful层级结构(TS 29.504 Section 7.3):

/nudr-dr/v1/subscription-data/{supi}/
├── authentication-data/           # 认证订阅数据
│   └── authentication-subscription  {K, OPC, algorithm, sequenceNumber}
├── context-data/                  # UE上下文数据
│   ├── amf-3gpp-access           # 服务AMF信息
│   ├── amf-non-3gpp-access       # 非3GPP接入AMF
│   ├── smf-registrations/        # 服务SMF列表
│   │   └── {pduSessionId}        # 每个PDU会话的SMF注册
│   └── sdm-subscriptions/        # SDM订阅信息
├── provisioned-data/              # 签约数据
│   ├── am-data                   # AM移动性数据
│   ├── sm-data                   # SM会话数据
│   │   └── {dnn}                 # 每DNN的会话管理数据
│   ├── sms-data                  # SMS签约数据
│   ├── nssai                     # 切片信息
│   └── sms-mng-data              # SMS管理数据
└── operator-specific-data/        # 运营商自定义数据

4.2 UDM内部的数据一致性保障

UDM面临的核心挑战是:当多个NF并发访问同一SUPI的数据时,如何保证一致性?TS 29.503采用了以下机制:

乐观并发控制(ETag/If-Match):

SDM_Subscribe和SDM_Modify操作使用HTTP ETag机制。UDM在返回数据时携带ETag(数据版本的哈希值),消费者在后续修改请求中通过If-Match头携带该ETag。如果数据已被其他NF修改(ETag不匹配),UDR返回412 Precondition Failed,消费者需要重新拉取最新数据。

订阅通知风暴抑制:

当BSS批量修改用户数据时(如套餐变更),UDM需要向所有订阅了该SUPI数据的NF发送通知。TS 29.503 Section 5.2.2.5定义了changeType字段,通知消息中明确标识变更类型(ADD/CHANGE/DELETE),消费者NF只需处理相关变更而非重新拉取全量数据。

五、SDM数据变更通知完整时序链

sequenceDiagram
    participant BSS as 运营支撑系统
    participant UDR
    participant UDM
    participant AMF
    participant SMF
    participant NEF as NEF/AF

    BSS->>UDR: 修改用户订阅数据<br/>(如:套餐升级,增加DNN)
    UDR-->>UDM: Nudr_Notify (changeType: CHANGE)

    Note over UDM: 查找所有SDM订阅者
    UDM->>UDR: GET /context-data/sdm-subscriptions
    UDR-->>UDM: [{AMF回调URL}, {SMF回调URL}]

    par 通知AMF
        UDM->>AMF: POST {amfCallback}<br/>{changeType: CHANGE,<br/>notificationItems: [{resourceUri: "/am-data"}]}
        AMF->>UDM: GET /nudm-sdm/v2/{supi}/am-data
        UDM->>UDR: GET /provisioned-data/am-data
        UDR-->>UDM: UpdatedAmData
        UDM-->>AMF: AccessAndMobilitySubscriptionData (updated)
        AMF-->>UDM: 204 No Content (通知确认)
    and 通知SMF
        UDM->>SMF: POST {smfCallback}<br/>{changeType: CHANGE,<br/>notificationItems: [{resourceUri: "/sm-data"}]}
        SMF->>UDM: GET /nudm-sdm/v2/{supi}/sm-data
        UDM-->>SMF: SessionManagementSubscriptionData (updated)
        SMF-->>UDM: 204 No Content
    end

六、5G UDM vs 4G HSS:架构对比

维度 4G HSS 5G UDM+UDR
接口协议 Diameter (Cx/Dx/S6a) RESTful HTTP/2 + JSON
数据存储 内置数据库(紧耦合) 外置UDR(松耦合)
服务发现 DRA/DRA代理 NRF服务注册发现
认证方法 EPS-AKA(仅4G) 5G AKA + EAP-AKA'双轨
订阅模型 被动查询(无变更推送) 拉取+推送混合模型
用户标识 IMSI明文传输 SUCI加密(ECIES保护)
扩展性 单体扩展困难 前后端独立伸缩
数据一致性 最终一致 ETag+条件更新
切片支持 无原生支持 NSSAI端到端签约

关键演进点在于推送能力的引入。4G HSS只支持MME的Cx接口被动查询,当用户签约数据变更时,HSS只能通过Insert Subscriber Data命令主动推送,但缺乏标准化的订阅-通知机制。5G UDM通过SDM_Subscribe/Notification模型,建立了标准化的数据变更通知通道。

七、实战抓包识别与故障排查

7.1 抓包特征识别

流程阶段 HTTP方法 URL特征 过滤表达式
UECM注册 PUT /nudm-uecm/v1/imsi-*/registrations/amf-3gpp-access http.request.method == "PUT" && http.request.uri contains "uecm"
SDM获取AM数据 GET /nudm-sdm/v2/imsi-*/am-data http.request.method == "GET" && http.request.uri contains "am-data"
SDM订阅通知 POST 回调URL含sdm-notification http.request.uri contains "sdm-notification"
认证向量获取 GET /nudm-ueau/v1/suci-*/security-information http.request.uri contains "ueau"

7.2 常见故障场景

场景1:UECM Registration返回403 Forbidden

根因分析:AMF发送的GUAMI不在UDM配置的合法AMF列表中,或者AMF未通过NRF认证。排错路径:检查AMF的GUAMI配置→验证NRF注册信息→确认UDM的AMF白名单策略。

场景2:SDM_Get返回404 Not Found

根因分析:SUPI在UDR中不存在(用户未开户或数据同步延迟)。排错路径:检查BSS开户状态→验证UDR数据一致性→确认SUPI格式(imsi-前缀+15位数字)。

场景3:SDM Notification未触发

根因分析:AMF的Subscribe请求中的callbackReference不可达,或者monitoredResourceUris不包含被修改的资源。排错路径:验证回调URL的TLS连通性→检查SDM Subscription的monitoredResourceUris覆盖范围→确认UDM的通知重传机制。

场景4:UDM向旧AMF发送DeregistrationNotification超时

根因分析:旧AMF已故障或网络分区。UDM的实现需要考虑通知超时处理——TS 29.503 Section 5.3.2.3.2规定了UDM在通知失败时的重试策略,但具体重试次数和间隔由实现决定。运营商应配置合理的重传定时器(通常3次,间隔5-30秒)。

八、状态转换图:UDM中UE的生命周期

stateDiagram-v2
    [*] --> 未开户: SUPI不在UDR中

    未开户 --> 已开户: BSS开户<br/>(UDR写入订阅数据)

    已开户 --> 已注册_3GPP: UECM_Registration<br/>(3GPP接入)
    已开户 --> 已注册_N3GPP: UECM_Registration<br/>(非3GPP接入)

    已注册_3GPP --> 双注册: UECM_Registration<br/>(非3GPP接入)
    已注册_N3GPP --> 双注册: UECM_Registration<br/>(3GPP接入)

    已注册_3GPP --> 已注册_3GPP: AMF重选<br/>(新UECM_Registration)
    已注册_N3GPP --> 已注册_N3GPP: AMF重选

    已注册_3GPP --> 已开户: UECM_Deregistration<br/>(deregReason: 规范定义值)
    已注册_N3GPP --> 已开户: UECM_Deregistration
    双注册 --> 已注册_3GPP: UECM_Deregistration<br/>(非3GPP)
    双注册 --> 已注册_N3GPP: UECM_Deregistration<br/>(3GPP)

    已开户 --> [*]: 用户销户<br/>(UDR删除数据)

常见问题

Q1: UDM和UDR必须分开部署吗?能否合并? A: 3GPP规范允许UDM和UDR合并部署。在小规模网络(如企业专网)中,合并部署可减少网元数量和网络延迟。但在运营商规模网络中,分离部署是推荐架构——UDR可以使用独立的分布式数据库(如Cassandra集群),实现数据的高可用和水平扩展,而UDM可以无状态化部署,便于弹性伸缩。

Q2: AMF发送SDM_Get时是发送三个独立的GET还是一个? A: TS 29.503定义了多个独立的资源端点。AMF通常并行发送三个GET请求(/am-data、/nssai、/ue-context-in-smf-data),利用HTTP/2的多路复用能力减少延迟。部分厂商实现支持自定义的复合查询端点,在一次GET中返回多种数据,但这属于厂商扩展,非标准行为。

Q3: 当AMF故障时,UDM如何保证UE不丢失? A: UECM Registration中的backupAmfInfo字段记录了备份AMF信息。当UDM检测到服务AMF不可达(通常通过NRF的心跳机制或HTTP请求超时),UDM会向备份AMF发送通知。此外,UE自身也有周期性注册定时器(T3512),超时后UE会发起周期性注册更新,此时RAN会通过GUAMI路由将UE分配到新的AMF。

Q4: Nudm_EE事件暴露和AMF的Namf_EE有什么关系? A: 两者是不同层级的事件暴露。AMF的Namf_EE提供接入网级别的事件(如UE可达性变化),而UDM的Nudm_EE提供用户数据级别的事件(如SUPI-IMEI关联变化)。对于UE可达性事件,流程是:NF→UDM(EE_Subscribe)→AMF(Namf_EE_Subscribe)→AMF检测到事件→AMF→UDM→NF。UDM在这里扮演的是"事件代理"角色。

Q5: UDM如何处理同一SUPI的3GPP接入和非3GPP接入的并发注册? A: UDM为3GPP接入和非3GPP接入维护独立的UECM注册记录。资源路径分别是/registrations/amf-3gpp-access和/registrations/amf-non-3gpp-access。两种接入可以注册到不同的AMF,这为non-3GPP接入(如Wi-Fi通过N3IWF/TNGF接入)使用专用AMF提供了灵活性。

参考来源

  1. 3GPP TS 29.503 V18.x — Unified Data Management Services Stage 3,定义Nudm五大服务接口的完整协议规范
  2. 3GPP TS 29.504 V18.x — Unified Data Repository Services,定义Nudr_DataRepository服务
  3. 3GPP TS 29.505 V18.x — Usage of UDR Services for Subscription Data,订阅数据在UDR中的存储模型
  4. free5GC UDM Introduction — 开源5GC实现中的UDM功能分析,含代码级流程解读
  5. TelecomTrainer: UDM Registration Process — 注册过程中AMF与UDM交互的实战分析

本文由「51学通信」技术团队出品。51学通信由通信行业18年老兵爱卫生(微信ID: gprshome201101)维护,聚焦5G/6G核心网、3GPP标准解读、通信前沿技术深度分析。 出版作品有《5G核心网原理与实践》《IMS原理与实践》等4本通信专业书籍。知识星球「51学通信」提供深度技术答疑和行业洞察。

[!tip] 51学通信知识星球 星主:爱卫生(微信:gprshome201101)——公众号「51学通信」创办者,19 年通信行业运维与讲师经验,著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书(各大电商平台有售)。 星球定位:深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域,主打运维岗位与信令分析。 当前规模:5200 篇主题 / 990 个回答,198 元/年。 加入福利:加入星球后请加爱卫生微信,拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题,另有群内分享。 AI 加持:51学通信知识星球已作为 skill 接入 WorkBuddy,使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例,做总结、找文档和 PPT 等场景全覆盖。

51学通信知识星球海报-扫码加入