《5G核心网原理与实践》实践篇 · UDM 网元功能
作者：爱卫生
在本系列第26篇和第27篇中，我们分别从两个视角解析了AMF如何获取和使用用户的切片信息——第26篇是AMF通过独立的/nssai资源精准查询，第27篇是AMF从/am-data中提取嵌入的nssai字段。两种方式的共同点是：AMF关注的是"这个用户签约了哪些切片"这一宏观问题。
但到了PDU会话建立阶段，问题变得更加具体和精细——SMF不仅要知道用户签约了哪些切片，更要知道"在某个特定切片下，用户能建立什么样的数据会话"。这就是本篇要剖析的核心内容：SMF通过Nudm_SDM_Get获取会话管理签约数据（SM-Data）时，其中的切片信息是如何组织的，以及它与AMF侧的切片信息有什么本质区别。
让我们用一个实际的例子来说明为什么SMF需要更精细的切片信息：
用户签约了3个切片：
- SST=1/SD=000001（eMBB-默认互联网）
- SST=1/SD=000002（eMBB-高速宽带）
- SST=4/SD=000003（行业专网）
AMF的视角（第26/27篇）：
"这个用户签约了3个切片，我帮他做切片选择就行了"
SMF的视角（本篇）：
"用户要在 SST=1/SD=000001 这个切片下建立 internet 这个DNN的会话，
那这个切片+DNN组合下，用户可以用什么PDU会话类型？什么QoS？什么速率？"
可以看到，SMF关注的是"切片 + DNN"组合级别的精细配置，而不仅仅是切片列表。这也解释了为什么SMF在获取SM-Data时需要携带dnn和s-nssai查询参数——它要精确定位到某个切片下某个DNN的完整配置。
本篇将详细验证：当SMF通过Nudm_SDM_Get携带DNN和S-NSSAI查询参数获取SM-Data时，UDM正确返回包含切片信息的会话管理数据，且与用户签约数据一致。
sequenceDiagram
participant UE
participant AMF
participant SMF
participant UDM
Note over UE, UDM: PDU会话建立流程
UE->>AMF: PDU Session Establishment Request<br/>携带DNN和S-NSSAI
AMF->>SMF: Nsmf_PDUSession_CreateSMContext Request<br/>包含DNN和S-NSSAI信息
rect rgb(230, 245, 255)
Note over SMF, UDM: SMF获取SM-Data（含切片信息）
SMF->>UDM: GET /nudm-sdm/v1/{supi}/sm-data<br/>?dnn=internet&s-nssai=sst:1,sd:000001
Note right of SMF: 注意查询参数：<br/>dnn: 目标数据网络名称<br/>s-nssai: 目标切片标识
UDM-->>SMF: 200 OK + SM-Data<br/>含singleNssai + dnnConfigurations<br/>切片+DNN组合的完整配置
end
Note over SMF: SMF基于SM-Data进行：<br/>1. 验证S-NSSAI/DNN授权<br/>2. 确定PDU会话类型和SSC模式<br/>3. 获取QoS和速率配置<br/>4. 建立PDU会话
flowchart TD
UDM_DATA["UDM签约数据库<br/>用户Subscription Data"] --> AM_SIDE["AMF侧切片信息<br/>（第26/27篇）"]
UDM_DATA --> SM_SIDE["SMF侧切片信息<br/>（本篇）"]
AM_SIDE --> AM_NSSAI["数据路径: /am-data<br/>nssai字段"]
AM_SIDE --> AM_CONTENT["内容: singleNssais + defaultSingleNssais<br/>含义: 用户签约了哪些切片"]
AM_SIDE --> AM_PURPOSE["用途: 切片选择<br/>确定Allowed NSSAI"]
SM_SIDE --> SM_DATA["数据路径: /sm-data<br/>查询参数: dnn + s-nssai"]
SM_SIDE --> SM_CONTENT["内容: singleNssai + dnnConfigurations<br/>含义: 在某切片下某DNN的完整配置"]
SM_SIDE --> SM_PURPOSE["用途: 会话管理<br/>确定PDU会话参数"]
style UDM_DATA fill:#e3f2fd,stroke:#1565c0,stroke-width:2px
style AM_SIDE fill:#e8f5e9,stroke:#2e7d32,stroke-width:2px
style SM_SIDE fill:#fff3e0,stroke:#e65100,stroke-width:2px
验证在PDU会话建立过程中，SMF通过Nudm_SDM_Get携带DNN和S-NSSAI查询参数从UDM获取会话管理签约数据时，UDM正确返回包含切片信息（singleNssai）和切片关联的DNN配置（dnnConfigurations）的SM-Data，且返回数据与用户签约数据一致。
SA网络中各网元系统及操作维护台运行正常。
终端和网络连接正常。
UE在UDM开户，签约5G业务，且已配置完整的会话管理签约数据（包括S-NSSAI、DNN配置、QoS参数等）。
服务化接口的信令监控、分析工具准备就绪。
用户已在5GC完成注册，AMF已确定Allowed NSSAI。
在UDM中为测试用户配置会话管理签约数据，确保包含：
singleNssai：用户签约的特定S-NSSAI（包含SST和SD）；
dnnConfigurations：在目标S-NSSAI下的DNN配置（含PDU Session Types、SSC Modes、QoS Profile、Session AMBR等）。
UE发起PDU会话建立请求，指定DNN和S-NSSAI。
SMF通过Nudm_SDM_Get从UDM获取SM-Data，请求中携带dnn和s-nssai查询参数。
Frame: 1002（SMF发送GET请求，携带dnn和s-nssai参数）
Frame: 1008（UDM返回200 OK + SM-Data）
验证UDM返回的SM-Data中切片信息与签约数据一致。
SMF通过Nudm_SDM_Get的GET请求正确携带dnn和s-nssai查询参数，URI格式符合3GPP规范。
UDM正确返回200 OK，响应中包含singleNssai（与请求的S-NSSAI一致）和dnnConfigurations（包含指定DNN的完整配置），切片信息与UDM签约数据一致。
在本测试中，核心关注点是SMF通过Nudm_SDM_Get服务从UDM获取会话管理签约数据时，请求中的S-NSSAI查询参数如何精确匹配到对应的切片配置，以及响应中切片信息与DNN配置的关联关系。
与第26/27篇最大的区别在于：AMF获取的是"切片列表"（知道用户有哪些切片），SMF获取的是"切片下的会话配置"（知道在某个切片下能建立什么样的会话）。这种从宏观到微观的递进，正是5GC切片管理体系的核心设计思路。
（注：为保护网络安全，以下log中的SUPI/IMSI标识、网元IP等敏感信息已做严格脱敏处理）
当SMF收到AMF通过Nsmf_PDUSession_CreateSMContext发来的会话创建请求后，需要向UDM查询该用户在特定切片和DNN下的会话管理配置。SMF使用HTTP GET方法，在URI中通过查询参数精确指定DNN和S-NSSAI。
sequenceDiagram
participant SMF
participant UDM
Note over SMF, UDM: Nudm_SDM_Get - 获取SM-Data（含切片信息）
SMF->>UDM: GET /nudm-sdm/v1/imsi-460XX00000XXXX/sm-data<br/>?dnn=internet<br/>&s-nssai=sst:1,sd:000001
Note right of SMF: 请求查询参数：<br/>dnn=internet（目标DNN）<br/>s-nssai=sst:1,sd:000001（目标切片）<br/>这两个参数精确定位到<br/>某个切片下某DNN的配置
UDM-->>SMF: 200 OK
Note left of UDM: 响应体含SM-Data：<br/>singleNssai（匹配请求的切片）<br/>dnnConfigurations（DNN的完整配置）<br/>含PDU类型/SSC模式/QoS/AMBR等
信令抓包解析：
# 1. SMF -> UDM（获取会话管理签约数据，携带DNN和S-NSSAI查询参数）
Frame: 1002
HEADERS: GET /nudm-sdm/v1/imsi-460XX00000XXXX/sm-data
?dnn=internet
&s-nssai=%7B%22sst%22%3A1%2C%22sd%22%3A%22000001%22%7D
# URL解码后的查询参数：
# dnn=internet
# s-nssai={"sst":1,"sd":"000001"}
# 说明：
# - dnn参数：SMF指定要查询的数据网络名称 = "internet"
# - s-nssai参数：SMF指定目标切片 = SST:1 + SD:000001（eMBB默认互联网切片）
# - 两个参数组合，精确锁定"eMBB默认切片下的internet DNN配置"
# 2. UDM -> SMF（返回SM-Data，含切片信息和DNN配置）
Frame: 1008
HEADERS[3]: 200 OK
JavaScript Object Notation: application/json
Object
# ===== 切片标识 =====
Member Key: singleNssai
Object
Member Key: sst
Number value: 1
# SST=1, eMBB切片类型
Member Key: sd
String value: "000001"
# SD=000001, eMBB默认互联网切片实例
# 注意：singleNssai（单数形式）不是数组
# 它表示当前SM-Data对应的特定切片
# 与AM-Data中的singleNssais（复数数组）不同！
# ===== DNN配置集合 =====
Member Key: dnnConfigurations
Object
# --- internet DNN配置 ---
Member Key: internet
Object
# --- PDU会话类型 ---
Member Key: pduSessionTypes
Object
Member Key: defaultSessionType
String value: "IPV4"
# 默认PDU会话类型: IPv4
Member Key: allowedSessionTypes
Array
String value: "IPV4"
String value: "IPV6"
String value: "IPV4V6"
# 允许的会话类型: IPv4, IPv6, IPv4v6双栈
# --- SSC连续性模式 ---
Member Key: sscModes
Object
Member Key: defaultSscMode
String value: "SSC_MODE_1"
# 默认SSC模式: 永远保持（IP地址不变）
Member Key: allowedSscModes
Array
String value: "SSC_MODE_1"
String value: "SSC_MODE_2"
String value: "SSC_MODE_3"
# 允许所有三种SSC模式
# --- 5GS QoS配置文件 ---
Member Key: "5gQosProfile"
Object
Member Key: "5qi"
Number value: 9
# 5QI=9, Non-GBR默认数据业务
Member Key: arp
Object
Member Key: priorityLevel
Number value: 8
# ARP优先级: 8（中等偏高）
Member Key: preemptCap
String value: "NOT_PREEMPT"
# 不允许抢占低优先级资源
Member Key: preemptVuln
String value: "PREEMPTABLE"
# 可被更高优先级会话抢占
Member Key: priorityLevel
Number value: 15
# 数据业务优先级: 15
# --- 会话级AMBR ---
Member Key: sessionAmbr
Object
Member Key: uplink
String value: "1000000000"
# 上行AMBR: 1 Gbps
Member Key: downlink
String value: "2000000000"
# 下行AMBR: 2 Gbps
# --- 静态IP地址 ---
Member Key: staticIpAddress
Array
Object
Member Key: ipv4Addr
String value: "10.XX.XX.XX"
# 静态分配的IPv4地址（已脱敏）
# ===== 计费特性 =====
Member Key: chargingCharacteristics
String value: "XXXXXX"
# 运营商自定义计费特性编码
这是一个容易混淆的重要区别，值得单独拿出来讲清楚：
| 维度 | AM-Data中的singleNssais | SM-Data中的singleNssai |
|---|---|---|
| 形式 | 复数（数组） | 单数（对象） |
|---|---|---|
| 含义 | 用户签约的所有S-NSSAI列表 | 当前SM-Data对应的特定S-NSSAI |
| 数量 | 可能包含多个S-NSSAI | 只有1个S-NSSAI |
| 获取方式 | AMF通过/am-data或/nssai获取 |
SMF通过/sm-data获取，由查询参数s-nssai确定 |
| 用途 | AMF进行切片选择 | SMF确认当前会话对应的切片 |
为什么设计成单数？ 因为SMF在获取SM-Data时，已经通过s-nssai查询参数明确指定了目标切片。UDM返回的SM-Data就是这个特定切片下的配置数据，所以singleNssai只需要标识"当前数据对应的切片是哪一个"，不需要列出所有切片。
flowchart TD
AMF_SIDE["AMF侧"] --> AMF_NSSAIS["singleNssais (复数数组)<br/>[S-NSSAI 1, S-NSSAI 2, S-NSSAI 3]<br/>所有签约切片"]
SMF_SIDE["SMF侧"] --> SMF_NSSAI["singleNssai (单数对象)<br/>{sst:1, sd:'000001'}<br/>当前切片"]
AMF_NSSAIS --> NOTE1["AMF知道: 用户签约了哪些切片<br/>用于切片选择"]
SMF_NSSAI --> NOTE2["SMF知道: 当前数据属于哪个切片<br/>用于会话参数确定"]
style AMF_SIDE fill:#e8f5e9,stroke:#2e7d32,stroke-width:2px
style SMF_SIDE fill:#fff3e0,stroke:#e65100,stroke-width:2px
协议参考：根据3GPP TS 29.503 第5.2.2.2.2节，
SessionManagementSubscriptionData中的singleNssai字段类型为Snssai（单数对象），表示该SM-Data记录对应的S-NSSAI。而AccessAndMobilitySubscriptionData中的nssai字段类型为Nssai，包含singleNssais（复数数组）和defaultSingleNssais。
dnnConfigurations是SM-Data中最重要的数据结构——它以DNN名称为key，包含在该切片下每个DNN的完整会话配置。
本例中，用户在SST=1/SD=000001切片下配置了"internet"DNN：
切片: SST=1, SD=000001 (eMBB默认互联网切片)
└── DNN: internet
├── pduSessionTypes: 默认IPV4, 允许IPV4/IPV6/IPV4V6
├── sscModes: 默认SSC_MODE_1, 允许全部三种模式
├── 5gQosProfile: 5QI=9, ARP优先级=8
├── sessionAmbr: 上行1Gbps, 下行2Gbps
└── staticIpAddress: 10.XX.XX.XX
关键理解：切片与DNN是多对多的关系
一个用户可以在同一个切片下配置多个DNN（如internet、ims、专网DNN），也可以在不同的切片下配置相同的DNN。dnnConfigurations中的每个DNN配置都是在当前S-NSSAI上下文中的配置：
flowchart TD
SLICE1["切片 SST=1/SD=000001<br/>eMBB默认互联网"] --> DNN_INET1["internet DNN配置<br/>5QI=9, AMBR=1G/2G"]
SLICE1 --> DNN_IMS1["ims DNN配置<br/>5QI=5, AMBR=..."]
SLICE2["切片 SST=1/SD=000002<br/>eMBB高速宽带"] --> DNN_INET2["internet DNN配置<br/>5QI=8, AMBR=5G/10G"]
SLICE2 --> DNN_SPECIAL["special DNN配置<br/>5QI=7, AMBR=..."]
SLICE3["切片 SST=4/SD=000003<br/>行业专网"] --> DNN_ENTER["enterprise DNN配置<br/>5QI=6, AMBR=..."]
style SLICE1 fill:#e8f5e9,stroke:#2e7d32,stroke-width:2px
style SLICE2 fill:#e8f5e9,stroke:#2e7d32,stroke-width:2px
style SLICE3 fill:#fff3e0,stroke:#e65100,stroke-width:2px
注意：SMF每次请求SM-Data时，通过
s-nssai参数指定一个切片，UDM只返回该切片下的DNN配置。如果SMF需要查询另一个切片的配置，需要发起新的GET请求并携带不同的s-nssai参数。
SMF在发起SM-Data查询时，URL中的查询参数起到了精确过滤的作用：
| 查询参数 | 本例取值 | 作用 | 是否必选 |
|---|---|---|---|
dnn |
internet | 指定要查询的DNN名称，过滤DNN配置 | 可选 |
|---|---|---|---|
s-nssai |
{"sst":1,"sd":"000001"} | 指定目标切片，定位SM-Data记录 | 可选 |
plmn-id |
（本例未携带） | 漫游场景下区分H-PLMN数据 | 可选 |
查询参数的过滤逻辑：
SMF请求: GET /sm-data?dnn=internet&s-nssai={"sst":1,"sd":"000001"}
UDM处理逻辑：
1. 根据{supi}在UDR中查找该用户的所有SM-Data记录
2. 根据"s-nssai"参数筛选：只返回SST=1/SD=000001的SM-Data
3. 根据"dnn"参数筛选：在dnnConfigurations中只返回"internet"的配置
4. 组装响应：singleNssai + 过滤后的dnnConfigurations
flowchart TD
REQUEST["SMF请求<br/>dnn=internet<br/>s-nssai=sst:1,sd:000001"] --> UDM_FILTER["UDM数据过滤"]
UDM_FILTER --> FILTER1["Step 1: 匹配S-NSSAI<br/>找到SST=1/SD=000001的SM-Data记录"]
FILTER1 --> FILTER2["Step 2: 匹配DNN<br/>在dnnConfigurations中<br/>筛选出internet配置"]
FILTER2 --> RESPONSE["返回精确匹配的SM-Data：<br/>singleNssai={sst:1,sd:000001}<br/>dnnConfigurations={internet:{...}}"]
style REQUEST fill:#e3f2fd,stroke:#1565c0,stroke-width:2px
style RESPONSE fill:#c8e6c9,stroke:#2e7d32,stroke-width:2px
协议参考：根据3GPP TS 29.503 第5.2.2.2节，
Nudm_SDM_Get的Resource URI为GET /nudm-sdm/v1/{supi}/sm-data，查询参数dnn、s-nssai、plmn-id均为可选。当SMF同时携带dnn和s-nssai时，UDM返回该切片下该DNN的精确配置；如果不携带，则返回用户在该PLMN下所有可用的SM-Data。
经过第26篇、第27篇和本篇（第28篇）的系统分析，我们现在可以对5GC中切片信息在不同网元、不同数据集中的呈现方式做一个全面的横向对比：
flowchart TD
OVERALL["5GC切片信息全景图"] --> ART26["第26篇<br/>AMF独立查询NSSAI<br/>GET /nssai"]
OVERALL --> ART27["第27篇<br/>AMF从AM-Data获取NSSAI<br/>GET /am-data中的nssai字段"]
OVERALL --> ART28["第28篇<br/>SMF从SM-Data获取切片信息<br/>GET /sm-data携带s-nssai参数"]
ART26 --> DATA26["返回数据：<br/>Nssai对象<br/>singleNssais数组<br/>defaultSingleNssais数组"]
ART27 --> DATA27["返回数据：<br/>AmData中的nssai子字段<br/>内容与第26篇完全一致"]
ART28 --> DATA28["返回数据：<br/>singleNssai（单数对象）<br/>dnnConfigurations（DNN配置）<br/>切片+DNN的精细配置"]
style OVERALL fill:#e3f2fd,stroke:#1565c0,stroke-width:2px
style ART26 fill:#e8f5e9,stroke:#2e7d32,stroke-width:2px
style ART27 fill:#e8f5e9,stroke:#2e7d32,stroke-width:2px
style ART28 fill:#fff3e0,stroke:#e65100,stroke-width:2px
三篇文章的完整对比表：
| 对比维度 | 第26篇（AMF独立查询） | 第27篇（AMF从AM-Data获取） | 第28篇（SMF从SM-Data获取） |
|---|---|---|---|
| 请求网元 | AMF | AMF | SMF |
|---|---|---|---|
| URI路径 | /nudm-sdm/v1/{supi}/nssai |
/nudm-sdm/v1/{supi}/am-data |
/nudm-sdm/v1/{supi}/sm-data |
| 查询参数 | 无 | 无 | dnn, s-nssai |
| 切片字段名 | singleNssais（复数） |
nssai.singleNssais（复数） |
singleNssai（单数） |
| 切片数据形式 | 数组（所有签约切片） | 数组（所有签约切片） | 单个对象（请求的特定切片） |
| 默认切片 | defaultSingleNssais |
nssai.defaultSingleNssais |
不涉及（SMF不需要默认切片） |
| DNN配置 | 不涉及 | 不涉及 | dnnConfigurations（核心内容） |
| 获取时机 | 注册流程 | 注册流程 | PDU会话建立流程 |
| 数据粒度 | 切片列表级 | 切片列表级（AM-Data的一部分） | 切片+DNN组合级（最精细） |
| 核心用途 | 切片选择 | 切片选择（+其他AM策略） | 会话参数确定 |
| 3GPP参考 | TS 29.503 5.2.2 | TS 29.503 5.2.2 | TS 29.503 5.2.2.2 |
从宏观到微观的递进关系：
第26/27篇（AMF侧）： "用户签约了哪些切片？" → 切片列表（宏观）
↓ AMF选择切片后，将S-NSSAI传递给SMF
第28篇（SMF侧）： "在这个切片下，用户能建立什么样的会话？" → 精细配置（微观）
这个递进关系揭示了5GC切片管理体系的一个核心设计思路：AMF负责切片的"准入控制"，SMF负责切片的"服务交付"。两者各司其职，共同完成从切片选择到会话建立的完整链路。
将SM-Data中的切片信息放到PDU会话建立的完整流程中，SMF的处理逻辑如下：
flowchart TD
START["SMF收到PDU会话创建请求<br/>携带DNN=internet, S-NSSAI=sst:1/sd:000001"] --> GET_SM["SMF向UDM查询SM-Data<br/>携带dnn和s-nssai参数"]
GET_SM -->|"200 OK"| PARSE["SMF解析SM-Data"]
GET_SM -->|"失败"| FAIL1["会话建立失败"]
PARSE --> CHECK1["Step 1: 检查singleNssai<br/>确认S-NSSAI=sst:1/sd:000001<br/>与请求中的切片一致"]
CHECK1 --> CHECK2["Step 2: 检查dnnConfigurations<br/>确认internet DNN存在于配置中"]
CHECK2 -->|"DNN存在"| CHECK3["Step 3: 提取PDU会话参数<br/>pduSessionTypes, sscModes"]
CHECK2 -->|"DNN不存在"| FAIL2["会话建立失败:<br/>DNN未签约"]
CHECK3 --> CHECK4["Step 4: 提取QoS参数<br/>5QI=9, ARP=8"]
CHECK4 --> CHECK5["Step 5: 提取速率参数<br/>Session AMBR=1G/2G"]
CHECK5 --> CHECK6["Step 6: 确定IP地址<br/>staticIpAddress=10.XX.XX.XX"]
CHECK6 --> ESTABLISH["SMF建立PDU会话<br/>分配UPF, 配置QoS, 分配IP"]
style ESTABLISH fill:#c8e6c9,stroke:#2e7d32,stroke-width:3px
style FAIL1 fill:#ffcdd2,stroke:#c62828
style FAIL2 fill:#ffcdd2,stroke:#c62828
SM-Data中切片信息的使用场景：
| SM-Data字段 | 使用阶段 | 使用方式 |
|---|---|---|
singleNssai |
S-NSSAI验证 | 确认请求的切片与SM-Data记录中的切片一致 |
|---|---|---|
dnnConfigurations.internet |
DNN授权 | 确认用户有权在该切片下建立internet DNN的会话 |
pduSessionTypes |
会话类型确定 | 确定PDU会话的类型（IPv4/IPv6/IPv4v6） |
sscModes |
连续性模式确定 | 确定会话的SSC连续性模式 |
5gQosProfile |
QoS配置 | 为PDU会话设置默认QoS参数（5QI、ARP） |
sessionAmbr |
速率控制 | 设置PDU会话的聚合最大比特速率 |
staticIpAddress |
IP地址分配 | 为PDU会话分配静态IP地址（如有配置） |
chargingCharacteristics |
计费策略 | 确定该会话的计费方式 |
在实际工程调试中，网络工程师可以通过curl直接查询UDM的SM-Data接口，携带DNN和S-NSSAI参数，精确获取特定切片下的DNN配置。
# 查询特定切片下的特定DNN配置（URL编码后）
curl -i -X GET "http://10.XX.XX.XX:31381/nudm-sdm/v1/imsi-460XX00000XXXX/sm-data?dnn=internet&s-nssai=%7B%22sst%22%3A1%2C%22sd%22%3A%22000001%22%7D"
# URL解码后的等效查询：
# GET /nudm-sdm/v1/imsi-460XX00000XXXX/sm-data
# ?dnn=internet
# &s-nssai={"sst":1,"sd":"000001"}
UDM返回的完整JSON响应（已脱敏）：
{
"singleNssai": {
"sst": 1,
"sd": "000001"
},
"dnnConfigurations": {
"internet": {
"pduSessionTypes": {
"defaultSessionType": "IPV4",
"allowedSessionTypes": ["IPV4", "IPV6", "IPV4V6"]
},
"sscModes": {
"defaultSscMode": "SSC_MODE_1",
"allowedSscModes": ["SSC_MODE_1", "SSC_MODE_2", "SSC_MODE_3"]
},
"5gQosProfile": {
"5qi": 9,
"arp": {
"priorityLevel": 8,
"preemptCap": "NOT_PREEMPT",
"preemptVuln": "PREEMPTABLE"
},
"priorityLevel": 15
},
"sessionAmbr": {
"uplink": "1000000000",
"downlink": "2000000000"
},
"staticIpAddress": [
{
"ipv4Addr": "10.XX.XX.XX"
}
]
}
},
"chargingCharacteristics": "XXXXXX"
}
使用jq工具提取关键信息：
# 提取singleNssai（确认切片）
curl -s "http://10.XX.XX.XX:31381/nudm-sdm/v1/imsi-460XX00000XXXX/sm-data?dnn=internet&s-nssai=%7B%22sst%22%3A1%2C%22sd%22%3A%22000001%22%7D" | jq '.singleNssai'
# 输出: { "sst": 1, "sd": "000001" }
# 提取internet DNN的5QI
curl -s ... | jq '.dnnConfigurations.internet["5gQosProfile"]["5qi"]'
# 输出: 9
# 提取Session AMBR
curl -s ... | jq '.dnnConfigurations.internet.sessionAmbr'
# 输出: { "uplink": "1000000000", "downlink": "2000000000" }
# 提取允许的PDU会话类型
curl -s ... | jq '.dnnConfigurations.internet.pduSessionTypes.allowedSessionTypes'
# 输出: ["IPV4", "IPV6", "IPV4V6"]
工程调试中的典型场景：
切片+DNN组合验证：用户投诉在某个切片下无法建立特定DNN的会话，通过curl检查SM-Data中是否存在对应的dnnConfigurations；
QoS配置核查：用户反馈速率不达标，检查sessionAmbr和5QI配置是否符合套餐要求；
跨切片配置比对：同一个DNN在不同切片下的QoS和速率可能不同，通过修改s-nssai参数逐一查询比对；
SSC模式验证：行业用户要求特定的会话连续性保障，检查sscModes配置是否正确。
为了完整理解5GC中切片信息的流转过程，我们梳理从UE请求到SMF获取SM-Data的完整链路：
flowchart TD
STEP1["Step 1: UE发送Registration Request<br/>携带Requested NSSAI或不携带"] --> STEP2["Step 2: AMF从UDM获取AM-Data<br/>提取nssai字段<br/>得到singleNssais和defaultSingleNssais"]
STEP2 --> STEP3["Step 3: AMF执行切片选择<br/>生成Allowed NSSAI"]
STEP3 --> STEP4["Step 4: AMF在Registration Accept中<br/>将Allowed NSSAI下发给UE"]
STEP4 --> STEP5["Step 5: UE发送PDU Session Request<br/>携带DNN和S-NSSAI（来自Allowed NSSAI）"]
STEP5 --> STEP6["Step 6: AMF通过Nsmf_PDUSession_CreateSMContext<br/>将DNN和S-NSSAI传递给SMF"]
STEP6 --> STEP7["Step 7: SMF从UDM获取SM-Data<br/>携带dnn和s-nssai查询参数<br/>获取切片+DNN的精细配置"]
STEP7 --> STEP8["Step 8: SMF基于SM-Data建立PDU会话<br/>完成切片的服务交付"]
style STEP2 fill:#e8f5e9,stroke:#2e7d32,stroke-width:2px
style STEP7 fill:#fff3e0,stroke:#e65100,stroke-width:2px
style STEP8 fill:#c8e6c9,stroke:#2e7d32,stroke-width:3px
关键传递节点：
| 传递节点 | 传递的信息 | 来源 | 目的 |
|---|---|---|---|
| UE → AMF | Requested NSSAI | UE的USIM/配置 | 告知AMF用户想使用哪个切片 |
| UDM → AMF | singleNssais + defaultSingleNssais | UDR中的签约数据 | AMF进行切片授权 |
| AMF → UE | Allowed NSSAI | AMF切片选择结果 | 告知UE可以使用哪些切片 |
| UE → AMF → SMF | DNN + S-NSSAI | UE请求 + Allowed NSSAI | 指定要建立什么类型的会话 |
| UDM → SMF | singleNssai + dnnConfigurations | UDR中的SM签约数据 | SMF确定会话参数 |
协议参考：根据3GPP TS 23.502第4.3.2节（PDU Session Establishment），SMF在收到AMF的会话创建请求后，需要通过Nudm_SDM_Get获取会话管理签约数据。请求中的
s-nssai参数来源于AMF传递的Allowed NSSAI中的具体S-NSSAI，dnn参数来源于UE请求或AMF的默认DNN配置。
| 验证项 | 结果 | 说明 |
|---|---|---|
| SMF正确携带查询参数 | OK | Frame 1002中GET请求携带dnn=internet和s-nssai参数，格式符合3GPP规范 |
| UDM正确返回200 OK | OK | Frame 1008返回200 OK，响应包含完整的SM-Data |
| singleNssai数据正确 | OK | 返回singleNssai={sst:1, sd:000001}，与请求中的s-nssai参数一致 |
| dnnConfigurations数据完整 | OK | 包含internet DNN的完整配置：PDU类型、SSC模式、QoS、Session AMBR |
| 切片信息与签约数据一致 | OK | singleNssai与UDM中配置的签约S-NSSAI完全一致 |
| 信令流程符合3GPP规范 | OK | 请求/响应与TS 29.503第5.2.2.2节完全吻合 |
本测试用例完美通过！SMF在PDU会话建立流程中通过Nudm_SDM_Get携带DNN和S-NSSAI查询参数获取会话管理签约数据，UDM正确返回了包含singleNssai（特定切片标识）和dnnConfigurations（切片下的DNN完整配置）的SM-Data，所有字段值与UDM中的用户签约配置完全一致。
关键收获总结：
SMF获取的是"切片+DNN"组合级精细配置——不同于AMF的切片列表，SMF通过携带s-nssai和dnn查询参数，精确获取特定切片下特定DNN的完整会话配置；
singleNssai（单数）vs singleNssais（复数）——SM-Data中是单个S-NSSAI对象，AM-Data中是S-NSSAI数组，两者形式不同但都表示用户的切片签约信息；
dnnConfigurations是切片信息在SM侧的核心载体——它将切片信息与DNN配置关联起来，SMF据此确定PDU会话的全部参数（类型、QoS、速率、SSC模式等）；
从AMF到SMF的切片信息传递链路：AMF先从AM-Data确定"用户可以使用哪些切片"，SMF再从SM-Data确定"在这些切片下能建立什么样的会话"，形成从宏观授权到微观交付的完整链路。
关于作者：爱卫生，专注通信教育18年，《5G核心网原理与实践》等4本专业书籍作者。更多5GC/IMS深度内容，欢迎关注公众号「51学通信」或加入知识星球（200+小时视频、3000+精华文章）。
本文为《5G核心网原理与实践》实践篇之UDM系列。系列持续更新中，扫码关注「51学通信」获取最新内容。