5GC实践篇之UDM篇第17篇：PDU会话建立中的UDM交互

从UDM获取用户的签约数据（确认用户是否有权使用该DNN/S-NSSAI组合）；
向UDM订阅签约数据的变更通知（以便后续用户套餐变化时能及时感知）。

这三步操作分别对应UDM的三个核心SBI服务：Nudm_UECM_Registration、Nudm_SDM_Get和Nudm_SDM_Subscribe。

本篇正是验证在PDU会话建立过程中，SMF与UDM之间的这三组信令交互是否正确、完整。

详细消息流程图


sequenceDiagram

    participant UE

    participant RAN as (R)AN

    participant AMF

    participant SMF

    participant UDM

    participant PCF

    participant UPF

    Note over UE, UPF: UE已注册，发起PDU会话建立

    UE->>RAN: PDU Session Establishment Request

    RAN->>AMF: N2 Message (PDU Session Request)

    AMF->>SMF: Nsmf_PDUSession_CreateSMContext Request

    rect rgb(230, 245, 255)

        Note over SMF, UDM: UDM交互三部曲

        SMF->>UDM: ① Nudm_UECM_Registration (PUT)<br/>注册SMF会话信息

        UDM-->>SMF: 204 No Content (注册成功)

        SMF->>UDM: ② Nudm_SDM_Get (GET)<br/>获取签约数据

        UDM-->>SMF: 200 OK (含S-NSSAI/DNN签约)

        SMF->>UDM: ③ Nudm_SDM_Subscribe (POST)<br/>订阅SM-Data变更通知

        UDM-->>SMF: 201 Created (含subscriptionId)

    end

    SMF->>PCF: SM Policy Association Establishment

    SMF->>UPF: N4 Session Establishment Request

    UPF-->>SMF: N4 Session Establishment Response

    SMF-->>AMF: Nsmf_PDUSession_CreateSMContext Response

    AMF->>RAN: N2 PDU Session Resource Setup Request

    RAN->>UE: PDU Session Establishment Accept


flowchart LR

    subgraph SMF向UDM的三个服务调用

        A["① Nudm_UECM_Registration<br/>PUT /registrations/smf-registrations/{pduSessionId}<br/>→ 204 No Content"] -->

        B["② Nudm_SDM_Get<br/>GET /sm-data?dnn=...&s-nssai=...<br/>→ 200 OK + 签约数据"] -->

        C["③ Nudm_SDM_Subscribe<br/>POST /sdm-subscriptions<br/>→ 201 Created + subscriptionId"]

    end

    style A fill:#e3f2fd,stroke:#1565c0,stroke-width:2px

    style B fill:#e8f5e9,stroke:#2e7d32,stroke-width:2px

    style C fill:#fff3e0,stroke:#e65100,stroke-width:2px

测试目的

验证UDM能够正确支持PDU会话建立流程，包括SMF的UECM注册、签约数据获取和SDM数据订阅三项交互。

测试前置条件

SA网络中各网元系统及操作维护台运行正常。
终端和网络连接正常。
UE在UDM开户，签约5G业务。
服务化接口的信令监控、分析的工具准备就绪。
用户已在5GC完成注册。

测试步骤

UE发起会话建立请求，要求建立PDU会话。
Frame: 853-862
检查流程涉及接口的服务消息和参数信息。

测试结果验证（预期）

SMF使用UDM的Nudm_UECM_Registration服务发起注册，携带smfInstanceId、pduSessionId、dnn等关键信元，UDM响应注册成功。
SMF使用UDM的Nudm_SDM_Get服务获取签约数据，UDM响应消息包含UE的签约数据，包括签约S-NSSAI、DNN等信息。
SMF使用UDM的Nudm_SDM_Subscribe服务订阅SM-Data数据。UDM返回订阅成功，携带订阅ID。
PDU会话建立成功。

2 PDU会话建立中UDM信令深度解析

在本测试中，SMF与UDM的交互是整个PDU会话建立过程中最关键的"数据准备"阶段。SMF必须按顺序完成"注册身份→获取数据→订阅变更"三个步骤，缺一不可。

（注：为保护网络安全，以下log中的SUPI/IMSI标识、网元IP及实例ID等敏感信息已做严格脱敏处理）

2.1 SMF向UDM注册会话信息（Nudm_UECM_Registration）

这是SMF与UDM的第一次握手。当AMF通过Nsmf_PDUSession_CreateSMContext请求将PDU会话管理权交给SMF后，SMF的第一件事就是"到UDM处报到"——告诉UDM："我来管理这个用户的这个PDU会话了，请记录下我的信息。"

SMF使用HTTP PUT方法调用Nudm_UECM_Registration服务，将自身的实例ID、会话ID和DNN等信息写入UDM。这一步的目的是让UDM在后续需要查找某个用户的会话管理网元时，能够精确定位到SMF。


sequenceDiagram

    participant SMF

    participant UDM

    Note over SMF, UDM: Nudm_UECM_Registration

    SMF->>UDM: PUT /nudm-uecm/v1/imsi-460XX00000XXXX<br/>/registrations/smf-registrations/1

    Note right of SMF: 请求体携带：<br/>smfInstanceId<br/>pduSessionId: 1<br/>dnn: internet<br/>plmnId: {mcc:"460",mnc:"XX"}

    UDM-->>SMF: 204 No Content

    Note left of UDM: UDM存储SMF注册信息<br/>关联SUPI+pduSessionId

信令抓包解析：


# 1. SMF -> UDM（发起SMF会话注册 PUT请求）

Frame: 978 & 988 & 990

HEADERS[11]: PUT /nudm-uecm/v1/imsi-460XX00000XXXX/registrations/smf-registrations/1

JavaScript Object Notation: application/json

  Object

    Member Key: smfInstanceId

      String value: XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX

      # SMF的NF Instance ID，用于唯一标识该SMF实例

    Member Key: pduSessionId

      Number value: 1

      # PDU会话ID，UE侧分配的会话标识

    Member Key: dnn

      String value: internet

      # 数据网络名称，即APN的5G版本

    Member Key: plmnId

      Object

        Member Key: mcc

          String value: "460"

        Member Key: mnc

          String value: "XX"

# 2. UDM -> SMF（注册成功响应）

HEADERS[3]: 204 No Content

# 204表示UDM已成功接收并存储了SMF的注册信息

关键信元解读：

信元	含义	说明

`smfInstanceId`	SMF实例ID	UUID格式，NF发现中注册的唯一标识
`pduSessionId`	PDU会话标识	取值1~15，UE在会话建立请求中分配
`dnn`	数据网络名称	标识UE要访问的外部数据网络（如internet、ims）
`plmnId`	PLMN标识	包含MCC和MNC，标识归属网络
`sst`	1	切片类型为eMBB
`defaultSessionType`	IPV4	默认PDU会话类型
`defaultSscMode`	SSC_MODE_1	SSC模式1（IP地址保持不变）
`5qi`	9	默认QoS为"尽力而为"
`arp.priorityLevel`	8	ARP优先级（1~15，数字越小优先级越高）
`sessionAmbr`	1G/2G	会话级上下行速率上限
`callbackReference`	回调URI	UDM在数据变更时通知SMF的地址
`monitoredResourceUris`	监控资源URI	指定需要监控的签约数据路径
`implicitUnsubscribe`	隐式退订	NF实例失效时自动清理订阅
`subscriptionId`	订阅ID	UDM分配的唯一订阅标识

协议参考：根据3GPP TS 29.503 第5.2.3节，Nudm_SDM_Subscribe的请求体包含SdmSubscription数据结构。UDM收到订阅请求后，会通过UDR建立数据变更监控。当运营商通过BOSS系统修改用户套餐数据时，UDR会产生变更通知传递给UDM，UDM再通过callbackReference回调SMF，实现签约数据变更的实时推送。

2.4 【硬核附加】三步交互的底层逻辑与异常场景

将上述三步放在一起来看，SMF与UDM的交互形成了一个精密的"注册→查询→监听"流水线：


flowchart TD

    A["SMF收到AMF的CreateSMContext请求"] --> B["① Nudm_UECM_Registration: 注册SMF会话信息"]

    B -->|"204 成功"| C["② Nudm_SDM_Get: 获取签约数据"]

    B -->|"失败"| FAIL1["会话建立失败: 无法注册SMF"]

    C -->|"200 OK"| D["验证签约数据: 用户是否授权该DNN和S-NSSAI"]

    C -->|"失败"| FAIL2["会话建立失败: 用户无签约"]

    D -->|"授权通过"| E["③ Nudm_SDM_Subscribe: 订阅数据变更"]

    D -->|"未授权"| FAIL3["会话建立失败: DNN或S-NSSAI未签约"]

    E -->|"201 Created"| F["三步完成，继续后续PCF和UPF交互，PDU会话建立成功"]

    E -->|"失败"| FAIL4["会话可能继续但丢失变更通知能力"]

    style F fill:#c8e6c9,stroke:#2e7d32,stroke-width:3px

    style FAIL1 fill:#ffcdd2,stroke:#c62828

    style FAIL2 fill:#ffcdd2,stroke:#c62828

    style FAIL3 fill:#ffcdd2,stroke:#c62828

    style FAIL4 fill:#fff9c4,stroke:#f57f17

三个值得注意的工程细节：

1) 步骤顺序不可颠倒

这三步必须严格按"注册→获取→订阅"的顺序执行。原因很简单：SMF必须先在UDM中注册自己的身份（步骤①），才能合法地获取签约数据（步骤②）；而订阅变更通知（步骤③）的前提是已经知道需要监控哪些数据资源。在3GPP规范中，SMF的实现逻辑通常是将这三步串行执行，后一步依赖前一步的成功。

2) 同一用户可有多条SMF注册记录

与AMF注册（一个用户只有一个AMF）不同，SMF注册允许"一对多"——同一个用户可以建立多个PDU会话，每个PDU会话由不同的SMF管理（也可以是同一个SMF）。UDM通过pduSessionId来区分同一用户的不同会话注册记录。当需要触发会话释放时，UDM可以通过smfInstanceId精确定位到目标SMF。

3) 订阅的隐式退订机制

SMF在订阅时设置了implicitUnsubscribe: true，这意味着当SMF这个NF实例从NRF中注销（如SMF宕机、重启）时，UDM会自动清除该订阅关系，无需SMF显式发送DELETE请求。这是5GC服务化架构中一种优雅的资源自清理机制，可以有效防止"僵尸订阅"占用UDM资源。

3 测试结论

验证项	结果	说明
PDU会话建立成功	OK	UE成功建立PDU会话
SMF向UDM注册会话信息	OK	Nudm_UECM_Registration交互正确
SMF获取签约数据	OK	Nudm_SDM_Get返回正确的S-NSSAI/DNN签约
SMF订阅数据变更	OK	Nudm_SDM_Subscribe成功获取subscriptionId
消息流程和参数正确	OK	三步交互时序与协议规范一致

本测试用例完美通过！SMF在PDU会话建立过程中，通过Nudm_UECM_Registration、Nudm_SDM_Get和Nudm_SDM_Subscribe三个SBI服务与UDM完成了"身份注册→数据获取→变更订阅"的完整交互链路，信令流程与3GPP TS 29.503规范完全吻合。

关于作者：爱卫生，从事通信教学18年，出版过《5G核心网原理与实践》等4本专业书籍。学5G核心网、IMS，来51学通信就对了！知识星球：200+小时视频、3000+精华文章、1年答疑群。公众号/知识星球：51学通信，微信：gprshome201101

5GC实践篇之UDM篇第17篇：PDU会话建立中的UDM交互

5GC实践篇之UDM篇第17篇：PDU会话建立中的UDM交互

1 测试背景与用例简介

详细消息流程图

测试目的

测试前置条件

测试步骤

测试结果验证（预期）

2 PDU会话建立中UDM信令深度解析

2.1 SMF向UDM注册会话信息（Nudm_UECM_Registration）

2.4 【硬核附加】三步交互的底层逻辑与异常场景

3 测试结论

查看完整内容