《5G核心网原理与实践》实践篇 · NSSF 网元功能
作者：爱卫生
在上一篇（第6篇）中，我们分析了PDU会话建立时标准切片选择的完整流程——UE根据PCF下发的NSSP策略选择S-NSSAI，AMF基于DNN+S-NSSAI通过NRF发现SMF。但现实网络中并非所有终端都支持标准的网络切片功能。
本篇聚焦于一个特殊但非常重要的场景：终端不支持标准网络切片，但通过DNN（Data Network Name）与切片的配置映射关系，依然能够正确匹配到对应的网络切片。
简单来说，这类终端在发送PDU Session Establishment Request时不会携带S-NSSAI信元。它们只知道要访问的DNN（如"internet"、"apn9"等），但不知道这个DNN对应哪个网络切片。在这种场景下，AMF需要充当"翻译官"的角色——根据本地配置的DNN到S-NSSAI的映射关系，将UE请求的DNN"翻译"成对应的S-NSSAI，然后再进行SMF发现和选择。
"DNN配置一致"指的是：UE在URSP规则中获得的DNN，与AMF本地配置的DNN-to-S-NSSAI映射表中的DNN完全匹配。也就是说，AMF能够根据UE请求的DNN明确地找到对应的S-NSSAI，不存在歧义。
举个例子：
| UE请求的DNN | AMF配置的映射 | 匹配结果 |
|---|---|---|
| apn9 | apn9 -> S-NSSAI(9,1) | 一致，可以确定切片 |
| internet | internet -> S-NSSAI(1,XXXXXXX) | 一致，可以确定切片 |
本篇的核心流程链路如下：
PCF向UE下发URSP策略（含NSSP），其中包含应用与DNN的映射（不含S-NSSAI，因为UE不支持标准切片）；
UE根据应用匹配URSP规则，确定DNN，在PDU Session Establishment Request中只携带DNN，不携带S-NSSAI；
AMF收到请求后，根据DNN在本地映射配置中查找对应的S-NSSAI；
AMF使用DNN+S-NSSAI通过NRF发现合适的SMF；
SMF建立PDU会话，完成会话建立。
sequenceDiagram
participant UE
participant RAN as RAN
participant AMF
participant NRF
participant SMF
participant UDM
participant PCF
Note over UE, PCF: PCF下发URSP策略(含DNN,不含S-NSSAI)
PCF->>AMF: URSP策略下发
AMF->>UE: Registration Accept + URSP(含NSSP/DNN映射)
Note over UE, SMF: UE发起PDU会话(仅携带DNN)
UE->>UE: 根据应用匹配URSP, 确定DNN
UE->>RAN: PDU Session Establishment Request(仅DNN, 无S-NSSAI)
RAN->>AMF: N2 PDU Session Request(仅DNN)
Note over AMF, AMF: AMF本地DNN-S-NSSAI映射查找
AMF->>AMF: 根据DNN查本地映射表, 确定S-NSSAI
AMF->>NRF: Nnrf_NFDiscovery_Request(DNN+SNSSAI)
NRF-->>AMF: Nnrf_NFDiscovery_Response(SMF信息)
AMF->>SMF: Nsmf_PDUSession_CreateSMContext(DNN+S-NSSAI)
SMF->>UDM: Nudm_SDM_Get(获取签约数据)
UDM-->>SMF: 200 OK(签约S-NSSAI/DNN)
SMF-->>AMF: Nsmf_PDUSession_CreateSMContext Response
SMF->>AMF: Namf_Communication_N1N2MessageTransfer(S-NSSAI)
AMF-->>UE: PDU Session Establishment Accept
flowchart LR
subgraph AMF的DNN到切片映射
A["UE请求DNN=apn9"] --> B["AMF查找本地映射表"]
B --> C["找到: apn9 -> S-NSSAI(9,1)"]
C --> D["使用DNN+SNSSAI发现SMF"]
end
style D fill:#c8e6c9,stroke:#2e7d32,stroke-width:2px
验证当终端不支持标准网络切片时，AMF能够通过DNN与S-NSSAI的本地配置映射关系，正确地为PDU会话选择网络切片并完成会话建立。
终端、RAN、AMF、UDM、NSSF等网元均支持切片选择功能。
环境已配置好相关切片信息，UE在UDM成功签约了切片数据。
UE不支持标准网络切片，PDU Session Request中不携带S-NSSAI。
PCF上配置了DNN以及S-NSSAI的对应数据，并能通过URSP策略下发给UE。
AMF上配置了DNN到S-NSSAI的映射关系，且该映射与PCF下发的URSP中DNN配置一致。
UE已成功在5G网络注册，网络侧已将Allowed NSSAI以及Configured NSSAI信息下发给UE。
UE已在注册过程中成功获取来自PCF下发的URSP策略。
UE发起PDU会话建立请求（仅携带DNN，不携带S-NSSAI）。
检查消息跟踪，验证PDU Session Establishment Request中是否仅携带DNN。
检查AMF的本地DNN-S-NSSAI映射查找日志。
检查AMF向NRF发送的NFDiscovery请求是否携带DNN和SNSSAI参数。
在AMF和SMF上查看UE的上下文信息。
UE在PDU Session Establishment Request消息中携带DNN（如"apn9"），不携带S-NSSAI。
AMF根据DNN在本地映射表中成功找到对应的S-NSSAI。
AMF向NRF发送的Nnrf_NFDiscovery_Request消息同时携带DNN和SNSSAI参数。
SMF成功从UDM获取签约数据，验证DNN和S-NSSAI均在签约范围内。
PDU会话建立成功，数据传输正常。
本测试的核心亮点在于AMF的DNN-to-S-NSSAI映射查找机制。当UE无法自己确定切片时，AMF如何根据DNN来"推断"出正确的S-NSSAI，这是理解非标准切片终端工作原理的关键。
（注：为保护网络安全，以下log中的SUPI/IMSI标识、网元IP及实例ID等敏感信息已做严格脱敏处理）
由于终端不支持标准切片，PCF在下发URSP策略时，Route Selection Descriptor中只包含DNN信息，不包含S-NSSAI。终端收到后也只能根据DNN来发起PDU会话。
# PCF通过AMF向UE下发的URSP策略
# (在注册流程中的AMPolicyAssociation或UESessionManagement中)
URSP (UE Route Selection Policy):
Rule 1:
Traffic Descriptor:
App ID: com.example.app1
Route Selection Descriptor:
DNN: apn9
# 仅指定DNN，不包含S-NSSAI
SSC Mode: SSC_MODE_1
PDU Session Type: IPv4
Rule 2:
Traffic Descriptor:
App ID: com.example.app2
Route Selection Descriptor:
DNN: internet
# 仅指定DNN，不包含S-NSSAI
SSC Mode: SSC_MODE_2
PDU Session Type: IPv4
URSP关键字段解读：
| 字段 | 含义 | 说明 |
|---|---|---|
| Traffic Descriptor | 流量描述符 | 匹配条件，如App ID |
| Route Selection Descriptor | 路由选择描述符 | 匹配后的动作，此处只有DNN没有S-NSSAI |
| DNN | 数据网络名称 | 唯一的切片关联标识 |
协议参考：根据3GPP TS 23.501 第5.15节，URSP中的Route Selection Descriptor可以包含S-NSSAI，也可以不包含。当不包含时，表示该终端不具备标准切片能力，由网络侧根据DNN或其他信息来确定切片。
UE根据URSP规则匹配到应用后，在PDU Session Establishment Request中只携带DNN，不携带S-NSSAI信元。这是"终端不支持标准切片"的典型特征。
# UE -> (R)AN -> AMF（PDU会话建立请求——仅DNN）
Frame: 853
NAS-5GS PDU Session Establishment Request
PDU session ID: 1
PTI: 0
DNN: apn9
# 数据网络名称，UE根据URSP策略选择
# 注意: 没有S-NSSAI信元！
PDU session type: IPv4
SSC mode: SSC_MODE_1
与标准切片终端的关键区别：
| 对比项 | 标准切片终端 | 非标准切片终端（本篇） |
|---|---|---|
| PDU Session Request中的S-NSSAI | 携带 | 不携带 |
|---|---|---|
| 切片选择决策方 | UE（基于NSSP） | AMF（基于DNN映射） |
| 切片信息来源 | Allowed NSSAI列表 | AMF本地DNN-S-NSSAI映射 |
dnn=apn9 |
UE请求 | 终端直接携带 |
snssai=(9,1) |
AMF映射 | AMF通过本地DNN映射表得到 |
tai |
UE位置 | 限定SMF服务范围 |
协议参考：根据3GPP TS 29.531 第5.3.2节，NRF支持基于DNN和S-NSSAI的联合查询。AMF在进行NFDiscovery时必须同时携带这两个参数，以确保返回的SMF能够服务该特定的DNN+S-NSSAI组合。
NRF返回SMF信息后，AMF将DNN和映射得到的S-NSSAI一起传递给SMF。
# AMF -> SMF（创建SM上下文请求）
Frame: 868
HEADERS: POST /nsmf-pdusession/v1/sm-contexts
JavaScript Object Notation: application/json
Object
Member Key: dnn
String value: "apn9"
# UE请求的DNN
Member Key: snssai
Object
Member Key: sst
Number value: 9
# AMF通过DNN映射得到的SST
Member Key: sd
String value: "1"
# AMF通过DNN映射得到的SD
Member Key: supi
String value: "imsi-460XX00000XXXX"
Member Key: pduSessionId
Number value: 1
Member Key: requestType
String value: "INITIAL_REQUEST"
# SMF -> UDM（获取签约数据）
Frame: 875
HEADERS: GET /nudm-sdm/v1/imsi-460XX00000XXXX/sm-data
?dnn=apn9
&s-nssai=%7B%22sst%22%3A9%2C%22sd%22%3A%221%22%7D
# UDM -> SMF（返回签约数据——确认DNN和S-NSSAI均已签约）
Frame: 879
HEADERS: 200 OK
JavaScript Object Notation: application/json
Object
Member Key: singleNssai
Object
Member Key: sst
Number value: 9
Member Key: sd
String value: "1"
# 确认签约的S-NSSAI(9,1)
Member Key: dnnConfigurations
Object
Member Key: apn9
Object
# DNN=apn9的签约配置
Member Key: pduSessionTypes
Object
Member Key: defaultSessionType
String value: "IPV4"
Member Key: 5gQosProfile
...
SMF验证签约数据的关键逻辑：
flowchart TD
A["SMF收到CreateSMContext(DNN=apn9, S-NSSAI=9/1)"] --> B["向UDM获取签约数据"]
B --> C["验证S-NSSAI(9,1)是否在签约列表中"]
C -->|"已签约"| D["验证DNN=apn9是否在该S-NSSAI下授权"]
D -->|"已授权"| E["签约验证通过, 继续会话建立"]
C -->|"未签约"| F["拒绝: S-NSSAI未签约"]
D -->|"未授权"| G["拒绝: DNN在该切片下未授权"]
style E fill:#c8e6c9,stroke:#2e7d32,stroke-width:2px
style F fill:#ffcdd2,stroke:#c62828
style G fill:#ffcdd2,stroke:#c62828
SMF完成会话建立后，通过AMF向UE返回PDU Session Establishment Accept消息。注意，尽管UE最初没有携带S-NSSAI，SMF仍然会在N2信息中包含S-NSSAI，告知RAN侧该会话使用的切片。
# SMF -> AMF（N1N2消息传递）
Frame: 895
HEADERS: POST /namf-comm/v1/ue-contexts/imsi-460XX00000XXXX/n1-n2-messages
JavaScript Object Notation: application/json
Object
Member Key: n2InfoContainer
Object
Member Key: smInfo
Object
Member Key: snssai
Object
Member Key: sst
Number value: 9
Member Key: sd
String value: "1"
# SMF确认PDU会话使用的S-NSSAI
Member Key: dnn
String value: "apn9"
协议参考：根据3GPP TS 23.501 第5.15.9节，即使UE不支持标准切片功能，网络侧（AMF）也可以基于运营商策略为UE的PDU会话确定合适的S-NSSAI。这种通过DNN间接确定切片的机制，是5GC为兼容非标准切片终端而设计的重要功能。
本篇场景的核心前提是DNN配置一致性——即AMF的DNN-to-S-NSSAI映射表中有UE请求的DNN对应的条目。下面总结这种一致性需要满足的条件：
一致性检查清单：
| 检查项 | 要求 | 失败后果 |
|---|---|---|
| PCF的URSP中DNN | 与AMF映射表DNN一致 | UE发送了AMF不认识的DNN |
| AMF映射表中的S-NSSAI | 在UE签约数据中 | 会话建立时SMF验证失败 |
| AMF映射表中的S-NSSAI | 在AMF支持的切片范围内 | AMF自身无法处理 |
| NRF中SMF注册信息 | 支持该DNN+S-NSSAI组合 | NRF发现不到合适的SMF |
flowchart TD
A["UE发起PDU Session(DNN=apn9, 无S-NSSAI)"] --> B["AMF查找DNN映射表"]
B -->|"apn9存在于映射表中"| C["确定S-NSSAI(9,1)"]
B -->|"apn9不存在于映射表中"| D["进入配置不一致场景(第8篇)"]
C --> E["检查S-NSSAI(9,1)在AMF支持列表中"]
E -->|"支持"| F["NRF发现SMF"]
E -->|"不支持"| G["查询NSSF或拒绝"]
style F fill:#c8e6c9,stroke:#2e7d32,stroke-width:2px
style D fill:#fff3e0,stroke:#e65100,stroke-width:2px
style G fill:#ffcdd2,stroke:#c62828
为什么会出现"不支持标准切片"的终端？
在实际网络部署中，以下几类终端可能不具备标准切片能力：
早期5G终端：5G商用初期的部分手机/模组，固件不支持3GPP R15定义的切片选择功能；
行业定制终端：某些垂直行业（如工业物联网）的定制终端，仅通过DNN/APN标识业务类型；
漫游终端：漫游场景下UE可能无法获取VPLMN的切片信息，只能依赖DNN；
LTE接入的终端：通过EPS Fallback或N26接口接入的终端，切片信息从PDN/APN映射而来。
| 验证项 | 结果 | 说明 |
|---|---|---|
| UE发起PDU会话（仅DNN） | OK | UE在PDU Session Request中仅携带DNN=apn9，不携带S-NSSAI |
| AMF DNN映射查找 | OK | AMF根据本地映射表成功将DNN=apn9映射到S-NSSAI(9,1) |
| AMF通过NRF发现SMF | OK | 使用DNN+映射后的S-NSSAI成功发现SMF |
| SMF签约数据验证 | OK | SMF确认DNN=apn9和S-NSSAI(9,1)均在UE签约范围内 |
| PDU会话建立成功 | OK | 会话建立完成，数据传输正常 |
| DNN配置一致性 | OK | AMF映射表与PCF URSP中DNN配置完全一致 |
本测试用例验证了"终端不支持标准切片但DNN配置一致"场景下的PDU会话建立流程。核心机制是AMF通过本地DNN-to-S-NSSAI映射表为非标准切片终端提供切片选择能力。当PCF下发的URSP中DNN与AMF映射表中的DNN一致时，整个流程可以顺利完成，与标准切片终端的用户体验完全相同。
关于作者：爱卫生，从事通信教学18年，出版过《5G核心网原理与实践》等4本专业书籍。学5G核心网、IMS，来51学通信就对了！知识星球：200+小时视频、3000+精华文章、1年答疑群。公众号/知识星球：51学通信，微信：gprshome201101