《5G核心网原理与实践》实践篇 · UDM 网元功能
作者：爱卫生
在本系列第26篇中，我们详细分析了AMF通过独立的/nssai资源路径查询用户切片信息的场景。那是一种"按需精准查询"的方式——AMF只获取切片数据，不涉及其他签约信息。
但在5GC的实际运行中，更常见的方式是：AMF在注册流程中通过/am-data一次性获取用户的完整接入和移动性管理签约数据（AM-Data），而切片信息（NSSAI）作为AM-Data的一个重要组成部分被包含在内。这种方式下，AMF不需要额外发起独立的NSSAI查询——UDM在返回AM-Data时，已经将切片信息一并携带。
两种方式的区别可以用一个形象的比喻来理解：
第26篇（独立查询/nssai）：就像去医院只做"切片检查"这一个单项——目的明确、数据量少、速度快；
本篇（从/am-data中获取）：就像去做"全身体检"——一次性获取所有数据，NSSAI只是体检报告中的一个项目。
本篇的重点不是AM-Data的完整解析（那是第19篇的内容），而是聚焦于AM-Data中nssai字段的详细解析——它是如何嵌入在AM-Data中的，它与独立查询/nssai返回的数据有什么关系，以及AMF如何使用这些切片信息进行决策。
sequenceDiagram
participant UE
participant RAN as (R)AN
participant AMF
participant UDM
Note over UE, UDM: UE发起注册请求
UE->>RAN: Registration Request
RAN->>AMF: N2 Message (Registration Request)
rect rgb(230, 245, 255)
Note over AMF, UDM: AMF获取完整AM-Data（含NSSAI）
AMF->>UDM: Nudm_SDM_Get (GET)<br/>GET /nudm-sdm/v1/{supi}/am-data
Note right of AMF: 注意：URI是/am-data，不是/nssai
UDM-->>AMF: 200 OK + AmData<br/>含subscribedUeAmbr + nssai + rfspIndex等
Note left of UDM: nssai字段是AmData的一个子字段：<br/>nssai.singleNssais = 签约切片列表<br/>nssai.defaultSingleNssais = 默认切片列表
end
Note over AMF: AMF从AmData中提取nssai字段<br/>进行切片选择决策
AMF-->>RAN: N2 Registration Accept (含Allowed NSSAI)
RAN-->>UE: Registration Accept (含Allowed NSSAI)
flowchart TD
AMDATA["AmData<br/>接入和移动性管理签约数据"] --> AMBR["subscribedUeAmbr<br/>签约UE聚合速率"]
AMDATA --> NSSAI["nssai<br/>签约切片信息（本篇重点）"]
AMDATA --> RFSP["rfspIndex<br/>RFSP索引"]
AMDATA --> TIMER["subsRegTimer<br/>注册周期定时器"]
AMDATA --> OTHER["其他可选参数<br/>ratRestrictions等"]
NSSAI --> SINGLE["singleNssais<br/>签约S-NSSAI列表"]
NSSAI --> DEFAULT["defaultSingleNssais<br/>默认S-NSSAI列表"]
SINGLE --> S1["S-NSSAI 1: SST + SD"]
SINGLE --> S2["S-NSSAI 2: SST + SD"]
DEFAULT --> D1["默认S-NSSAI: SST + SD"]
style AMDATA fill:#e3f2fd,stroke:#1565c0,stroke-width:2px
style NSSAI fill:#e8f5e9,stroke:#2e7d32,stroke-width:3px
style SINGLE fill:#fff3e0,stroke:#e65100,stroke-width:1px
style DEFAULT fill:#fff3e0,stroke:#e65100,stroke-width:1px
验证在UE注册流程中，AMF通过Nudm_SDM_Get获取用户完整的接入和移动性管理签约数据（AM-Data）时，UDM返回的nssai字段包含正确的singleNssais（签约S-NSSAI列表）和defaultSingleNssais（默认S-NSSAI列表），且与用户在UDM中的切片签约数据完全一致。
SA网络中各网元系统及操作维护台运行正常。
终端和网络连接正常。
UE在UDM开户，签约5G业务，且已配置完整的AM-Data（包括nssai、subscribedUeAmbr等必选字段）。
服务化接口的信令监控、分析工具准备就绪。
在UDM中为测试用户配置完整的接入和移动性管理签约数据，特别注意nssai字段的配置：
singleNssais：配置至少一个签约S-NSSAI（含SST和可选SD）；
defaultSingleNssais：配置至少一个默认S-NSSAI。
UE发起注册请求，触发AMF通过Nudm_SDM_Get获取AM-Data。
Frame: 672（AMF发送GET /am-data请求）
Frame: 678（UDM返回200 OK + AmData，含nssai字段）
从AM-Data响应中提取nssai字段，验证切片数据与UDM配置一致。
AMF通过Nudm_SDM_Get的GET请求成功获取完整的AM-Data，请求URI为/am-data。
UDM返回200 OK，响应中包含nssai字段，nssai中的singleNssais和defaultSingleNssais与UDM签约数据一致。
在本测试中，AMF通过Nudm_SDM_Get服务向UDM请求完整的AM-Data，而切片信息作为AM-Data的一个嵌入字段被一并返回。与第26篇中独立的/nssai查询不同，这里是"全量数据中的切片部分"——数据来源相同，但获取方式和数据上下文不同。
（注：为保护网络安全，以下log中的SUPI/IMSI标识、网元IP等敏感信息已做严格脱敏处理）
AMF在UE注册流程中，向UDM发起Nudm_SDM_Get请求，资源路径为/am-data。UDM返回完整的AmData JSON对象，其中nssai字段包含了用户签约的全部切片信息。
sequenceDiagram
participant AMF
participant UDM
Note over AMF, UDM: Nudm_SDM_Get - 获取AM-Data（含NSSAI）
AMF->>UDM: GET /nudm-sdm/v1/imsi-460XX00000XXXX/am-data
Note right of AMF: HTTP GET请求<br/>资源路径: /am-data<br/>获取完整AM-Data
UDM-->>AMF: 200 OK
Note left of UDM: 响应体含完整AmData：<br/>subscribedUeAmbr<br/>nssai (本篇重点)<br/>rfspIndex<br/>subsRegTimer<br/>...其他字段
信令抓包解析：
# 1. AMF -> UDM（获取AM签约数据，含NSSAI）
Frame: 672
HEADERS[5]: GET /nudm-sdm/v1/imsi-460XX00000XXXX/am-data
# 请求方法: GET
# 服务名称: nudm-sdm（SDM服务）
# API版本: v1
# 目标用户: imsi-460XX00000XXXX（已脱敏）
# 资源类型: am-data（完整AM-Data，nssai是其中的一个子字段）
# 无请求体，所有定位信息通过URL路径完成
# 2. UDM -> AMF（返回AM-Data，含NSSAI切片信息）
Frame: 678
HEADERS[3]: 200 OK
JavaScript Object Notation: application/json
Object
# ===== 签约UE聚合最大比特速率 =====
Member Key: subscribedUeAmbr
Object
Member Key: uplink
String value: "123457000"
# 上行速率: 123.457 Mbps
Member Key: downlink
String value: "1235000000"
# 下行速率: 1.235 Gbps
# ===== 【本篇重点】签约网络切片标识 =====
Member Key: nssai
Object
# --- 签约切片列表 ---
Member Key: singleNssais
Array
Object
Member Key: sst
Number value: 1
# SST=1, eMBB（增强移动宽带）
Member Key: sd
String value: "000001"
# 切片区分符: SD=000001
Object
Member Key: sst
Number value: 1
# SST=1, eMBB
Member Key: sd
String value: "000002"
# 切片区分符: SD=000002
Object
Member Key: sst
Number value: 4
# SST=4, 运营商自定义类型
Member Key: sd
String value: "000003"
# 切片区分符: SD=000003
# 用户共签约3个S-NSSAI
# --- 默认切片列表 ---
Member Key: defaultSingleNssais
Array
Object
Member Key: sst
Number value: 1
# 默认切片类型: eMBB
Member Key: sd
String value: "000001"
# 默认切片: SST=1/SD=000001
# ===== 其他AM-Data字段 =====
Member Key: rfspIndex
Number value: 10
# RFSP索引: 10
Member Key: subsRegTimer
Number value: 36000
# 签约注册周期: 36000秒 = 10小时
Member Key: ueUsageType
Number value: 0
# UE使用类型: 0（普通用户）
# ... 其他可选字段（ratRestrictions, serviceAreaRestriction等）
从上面的信令可以看到，nssai是AM-Data JSON对象中的一个二级字段——它嵌套在AmData的顶层，与subscribedUeAmbr、rfspIndex、subsRegTimer等字段并列。
AM-Data的JSON层级结构（聚焦nssai）：
{
"subscribedUeAmbr": {
"uplink": "123457000",
"downlink": "1235000000"
},
"nssai": {
"singleNssais": [
{ "sst": 1, "sd": "000001" },
{ "sst": 1, "sd": "000002" },
{ "sst": 4, "sd": "000003" }
],
"defaultSingleNssais": [
{ "sst": 1, "sd": "000001" }
]
},
"rfspIndex": 10,
"subsRegTimer": 36000
}
nssai字段的数据路径：
AmData（顶层对象）
└── nssai（切片信息对象）
├── singleNssais[]（签约切片数组）
│ ├── [0]: { sst: 1, sd: "000001" }
│ ├── [1]: { sst: 1, sd: "000002" }
│ └── [2]: { sst: 4, sd: "000003" }
└── defaultSingleNssais[]（默认切片数组）
└── [0]: { sst: 1, sd: "000001" }
协议参考：根据3GPP TS 29.503 第5.2.2节，
AccessAndMobilitySubscriptionData（即AmData）中包含nssai字段，类型为Nssai。该字段与独立的/nssai资源返回的数据结构完全一致——都是Nssai类型，包含singleNssais和defaultSingleNssais两个数组。
本例中用户签约了3个S-NSSAI，下面逐一解读：
| 序号 | SST | SD | 切片含义 | 业务场景 |
|---|---|---|---|---|
| 1 | 1 | 000001 | eMBB切片实例1 | 普通互联网接入（默认数据业务） |
| 2 | 1 | 000002 | eMBB切片实例2 | 可能是高速宽带切片（如VIP用户专属） |
| 3 | 4 | 000003 | 运营商自定义切片 | 可能是行业专网/V2X/企业专用 |
重要说明：
序号1和序号2的SST值相同（都是1=eMBB），但SD不同（000001 vs 000002）。这说明运营商在同一eMBB类型下部署了多个切片实例，通过SD来区分；
序号3的SST=4，这是运营商自定义的切片类型，可能对应某种特定的行业应用或业务场景；
singleNssais中的切片没有优先级顺序——数组中的顺序不代表任何优先级关系，AMF会根据UE的请求来决定使用哪个切片。
本例中默认切片配置为SST=1/SD=000001：
| 字段 | 取值 | 含义 |
|---|---|---|
| sst | 1 | 默认切片类型为eMBB |
| sd | "000001" | 默认切片实例为第一个eMBB切片 |
默认切片的触发条件和使用逻辑：
flowchart TD
START["AMF从AmData中提取nssai字段"] --> EXTRACT["解析得到：<br/>singleNssais = 3个签约切片<br/>defaultSingleNssais = 1个默认切片"]
EXTRACT --> CHECK{"UE的Registration Request<br/>是否包含Requested NSSAI"}
CHECK -->|"包含Requested NSSAI"| COMPARE["AMF将Requested NSSAI<br/>与singleNssais比对"]
CHECK -->|"不包含Requested NSSAI"| USE_DEF["AMF使用defaultSingleNssais<br/>Allowed NSSAI = SST=1/SD=000001"]
COMPARE -->|"匹配成功"| ALLOW["Allowed NSSAI = 匹配的切片"]
COMPARE -->|"部分匹配"| ALLOW_PART["Allowed NSSAI = 匹配的部分"]
COMPARE -->|"全部不匹配"| USE_DEF2["使用defaultSingleNssais<br/>作为Allowed NSSAI"]
USE_DEF --> RESULT["Allowed NSSAI确定<br/>继续注册流程"]
ALLOW --> RESULT
ALLOW_PART --> RESULT
USE_DEF2 --> RESULT
style RESULT fill:#c8e6c9,stroke:#2e7d32,stroke-width:2px
关于默认切片的几个关键问题：
Q1：默认切片必须出现在singleNssais中吗？
是的。这是一个数据一致性约束——defaultSingleNssais中的每个S-NSSAI必须同时存在于singleNssais中。如果默认切片不在签约列表中，AMF将无法为UE提供有效的切片服务。在本例中，默认切片SST=1/SD=000001确实存在于singleNssais的第一项中。
Q2：可以配置多个默认切片吗？
可以。defaultSingleNssais是一个数组，理论上可以包含多个S-NSSAI。但在实际部署中，运营商通常只配置一个默认切片，以简化切片选择逻辑。当配置多个默认切片时，AMF会将所有默认切片都加入Allowed NSSAI。
Q3：如果UE和网络都不支持切片（如早期5G部署），怎么办？
在5GC中，NSSAI是条件必选的——如果运营商没有部署网络切片，可以不在AM-Data中配置nssai字段。此时AMF不会执行切片选择流程，UE使用默认的网络配置。
一个自然的疑问是：AM-Data中嵌入的nssai字段，与独立查询/nssai返回的数据是否一致？
答案是：完全一致。因为两者都来源于UDR（统一数据仓库）中同一份AccessAndMobilitySubscriptionData记录。
flowchart TD
UDR["UDR（统一数据仓库）<br/>AccessAndMobilitySubscriptionData"] --> AM_QUERY["路径1: GET /am-data<br/>返回完整AmData<br/>nssai是其中一个字段"]
UDR --> NSSAI_QUERY["路径2: GET /nssai<br/>仅返回Nssai数据<br/>独立响应"]
AM_QUERY --> COMPARE["nssai字段内容<br/>完全相同"]
NSSAI_QUERY --> COMPARE
COMPARE --> CONCLUSION["数据来源相同<br/>返回内容一致<br/>区别仅在获取粒度"]
style UDR fill:#e3f2fd,stroke:#1565c0,stroke-width:2px
style CONCLUSION fill:#c8e6c9,stroke:#2e7d32,stroke-width:2px
两种获取方式的选择建议：
| 场景 | 推荐方式 | 理由 |
|---|---|---|
| 初始注册 | 通过/am-data获取 |
一次性获取所有接入管理数据，效率最高 |
|---|---|---|
| Inter-AMF切换 | 可选/nssai独立查询 |
只需要快速确认切片信息，减少数据传输量 |
| 切片数据更新验证 | 可选/nssai独立查询 |
只验证切片信息，不涉及其他签约数据 |
| 故障排查 | 根据需要选择 | 如需验证完整签约数据，用/am-data；如只需确认切片，用/nssai |
将nssai字段放回到AMF处理AM-Data的完整流程中，可以看到切片信息在整个接入控制逻辑中的位置：
flowchart TD
START["AMF收到200 OK<br/>完整AmData"] --> PARSE["解析AmData JSON"]
PARSE --> STEP1["Step 1: 检查ratRestrictions<br/>UE当前RAT是否允许"]
STEP1 -->|"RAT被限制"| REJECT1["Registration Reject"]
STEP1 -->|"RAT允许"| STEP2["Step 2: 提取nssai字段<br/>获取singleNssais和defaultSingleNssais"]
STEP2 --> STEP3["Step 3: 执行切片选择<br/>比对Requested NSSAI与singleNssais"]
STEP3 --> STEP4["Step 4: 生成Allowed NSSAI"]
STEP4 --> STEP5["Step 5: 获取subscribedUeAmbr<br/>设置UE级速率上限"]
STEP5 --> STEP6["Step 6: 获取rfspIndex<br/>下发RAN频点策略"]
STEP6 --> STEP7["Step 7: 获取serviceAreaRestriction<br/>设置区域限制"]
STEP7 --> ACCEPT["Registration Accept<br/>包含Allowed NSSAI等全部配置"]
style ACCEPT fill:#c8e6c9,stroke:#2e7d32,stroke-width:3px
style REJECT1 fill:#ffcdd2,stroke:#c62828
style STEP2 fill:#e8f5e9,stroke:#2e7d32,stroke-width:2px
style STEP4 fill:#e8f5e9,stroke:#2e7d32,stroke-width:2px
AM-Data中各字段的处理顺序和依赖关系：
| 处理步骤 | AM-Data字段 | 依赖其他字段 | 说明 |
|---|---|---|---|
| 1 | ratRestrictions | 无 | 最先检查，决定是否允许接入 |
| 2 | nssai | 无 | 提取切片信息，为切片选择做准备 |
| 3 | - (使用nssai) | nssai | 执行切片选择，生成Allowed NSSAI |
| 4 | subscribedUeAmbr | 无（但与会话建立关联） | 设置UE级速率上限 |
| 5 | rfspIndex | 无 | 下发RAN频点选择策略 |
| 6 | serviceAreaRestriction | 无 | 设置UE的允许/禁止活动区域 |
| 7 | subsRegTimer | 无 | 设置UE的周期性注册更新间隔 |
可以看到，nssai字段在AM-Data的处理流程中处于第2步的位置——紧接在RAT接入检查之后，是AMF进行接入控制的核心环节之一。
在实际工程调试中，网络工程师可以通过curl直接查询UDM的AM-Data接口，然后从返回的JSON中提取nssai字段进行验证。
curl -i -X GET http://10.XX.XX.XX:31381/nudm-sdm/v1/imsi-460XX00000XXXX/am-data
UDM返回的完整JSON响应（聚焦nssai部分，已脱敏）：
{
"subscribedUeAmbr": {
"uplink": "123457000",
"downlink": "1235000000"
},
"nssai": {
"singleNssais": [
{
"sst": 1,
"sd": "000001"
},
{
"sst": 1,
"sd": "000002"
},
{
"sst": 4,
"sd": "000003"
}
],
"defaultSingleNssais": [
{
"sst": 1,
"sd": "000001"
}
]
},
"rfspIndex": 10,
"subsRegTimer": 36000,
"ueUsageType": 0
}
使用jq工具提取nssai字段：
# 仅提取nssai部分
curl -s http://10.XX.XX.XX:31381/nudm-sdm/v1/imsi-460XX00000XXXX/am-data | jq '.nssai'
# 输出结果：
# {
# "singleNssais": [
# { "sst": 1, "sd": "000001" },
# { "sst": 1, "sd": "000002" },
# { "sst": 4, "sd": "000003" }
# ],
# "defaultSingleNssais": [
# { "sst": 1, "sd": "000001" }
# ]
# }
# 统计签约切片数量
curl -s http://10.XX.XX.XX:31381/nudm-sdm/v1/imsi-460XX00000XXXX/am-data | jq '.nssai.singleNssais | length'
# 输出: 3
# 提取所有签约切片的SST值
curl -s http://10.XX.XX.XX:31381/nudm-sdm/v1/imsi-460XX00000XXXX/am-data | jq '.nssai.singleNssais[].sst'
# 输出: 1, 1, 4
# 验证默认切片是否在签约列表中
curl -s http://10.XX.XX.XX:31381/nudm-sdm/v1/imsi-460XX00000XXXX/am-data | \
jq '.nssai.defaultSingleNssais as $defaults | .nssai.singleNssais | map(select(.sst == $defaults[0].sst and .sd == $defaults[0].sd)) | length'
# 输出: 1（表示默认切片存在于签约列表中，配置正确）
工程调试中的典型使用场景：
切片配置验证：用户开通新切片业务后，通过curl + jq验证nssai字段是否已更新；
默认切片核查：检查defaultSingleNssais是否正确配置，且其值确实存在于singleNssais中；
批量用户切片审计：遍历多个用户的AM-Data，统计各切片的签约用户数；
故障定位：当用户投诉无法使用某切片时，先检查nssai字段是否包含该切片的S-NSSAI。
AMF从AM-Data中提取nssai字段后，将执行以下切片选择逻辑。这是5G注册流程中最关键的步骤之一：
场景1：UE未携带Requested NSSAI
这是最常见的场景——大多数普通5G手机用户在注册时不会指定特定切片，AMF将使用默认切片：
1. AMF解析AmData.nssai.defaultSingleNssais
2. 提取默认S-NSSAI: { sst: 1, sd: "000001" }
3. Allowed NSSAI = [ { sst: 1, sd: "000001" } ]
4. AMF在Registration Accept中携带Allowed NSSAI返回给UE
场景2：UE携带了Requested NSSAI
一些高级终端或行业终端可能会在注册请求中明确指定希望使用的切片：
1. UE在Registration Request中携带Requested NSSAI: [ { sst: 1, sd: "000002" } ]
2. AMF解析AmData.nssai.singleNssais: [ {1,"000001"}, {1,"000002"}, {4,"000003"} ]
3. AMF将Requested NSSAI与singleNssais逐项比对:
- { sst: 1, sd: "000002" } → 在singleNssais中找到匹配 → 通过
4. Allowed NSSAI = [ { sst: 1, sd: "000002" } ]
5. AMF在Registration Accept中携带Allowed NSSAI返回给UE
场景3：UE请求的切片不在签约列表中
1. UE在Registration Request中携带Requested NSSAI: [ { sst: 2, sd: "000001" } ]
2. AMF解析AmData.nssai.singleNssais: [ {1,"000001"}, {1,"000002"}, {4,"000003"} ]
3. AMF比对:
- { sst: 2, sd: "000001" } → 不在singleNssais中 → 不通过
4. 请求的切片全部不匹配，AMF回退到defaultSingleNssais
5. Allowed NSSAI = [ { sst: 1, sd: "000001" } ]（使用默认切片）
协议参考：根据3GPP TS 23.501第5.15节和TS 23.502第4.2.2.2节，AMF在注册流程中使用签约的NSSAI数据进行切片选择。当UE未提供Requested NSSAI时，AMF使用Default S-NSSAI（defaultSingleNssais）；当UE提供了Requested NSSAI时，AMF需验证其是否在签约列表中。NSSF（Network Slice Selection Function）可能在切片选择过程中被AMF调用，以确定目标NSI和候选NF实例。
| 验证项 | 结果 | 说明 |
|---|---|---|
| AMF成功获取AM-Data | OK | Nudm_SDM_Get请求URI为/am-data，Frame 672 |
| UDM正确返回AM-Data含nssai字段 | OK | Frame 678返回200 OK，AmData中包含完整的nssai对象 |
| singleNssais数据正确 | OK | 包含3个签约切片：SST=1/SD=000001、SST=1/SD=000002、SST=4/SD=000003 |
| defaultSingleNssais数据正确 | OK | 包含1个默认切片：SST=1/SD=000001，且存在于singleNssais中 |
| 签约数据与UDM配置一致 | OK | 所有切片信息与UDM中的签约数据完全一致 |
| 信令流程符合3GPP规范 | OK | 请求/响应与TS 29.503第5.2节和TS 23.502第4.2.2.2节完全吻合 |
本测试用例完美通过！AMF在注册流程中通过Nudm_SDM_Get获取完整AM-Data时，UDM正确返回了包含nssai字段的AmData。nssai中的singleNssais（3个签约切片）和defaultSingleNssais（1个默认切片）与UDM中的用户签约配置完全一致，信令交互流程与3GPP TS 29.503规范完全吻合。
关键收获总结：
nssai是AM-Data的嵌入式字段——它不是独立获取的，而是作为AM-Data的一部分一次性返回，AMF从AmData JSON中提取nssai子字段即可获得切片信息；
数据来源一致性——AM-Data中的nssai与独立查询/nssai返回的数据完全一致，都来源于UDR中的同一份签约记录；
默认切片的使用时机——当UE未在注册请求中携带Requested NSSAI时，AMF使用defaultSingleNssais为UE分配默认切片，确保基本网络服务的可达性；
切片选择是注册流程的关键环节——AMF在获取AM-Data后，先检查RAT限制，再提取nssai进行切片选择，最后设置速率/区域/频点策略，nssai在整个流程中处于核心位置。
关于作者：爱卫生，从事通信教学18年，出版过《5G核心网原理与实践》等4本专业书籍。学5G核心网、IMS，来51学通信就对了！知识星球：200+小时视频、3000+精华文章、1年答疑群。公众号/知识星球：51学通信，微信：gprshome201101