5G核心网学习平台
NSSF 实践篇 #13

5GC实践篇之NSSF篇第8篇：终端不支持标准切片与DNN配置不一致的场景

《5G核心网原理与实践》实践篇 · NSSF 网元功能

5GC实践篇之NSSF篇第8篇：终端不支持标准切片与DNN配置不一致的场景

作者：爱卫生

1 测试背景与用例简介

在上一篇（第7篇）中，我们讨论了终端不支持标准切片但DNN配置一致的场景——AMF能够通过本地DNN-to-S-NSSAI映射表将UE请求的DNN"翻译"成对应的S-NSSAI，整个PDU会话建立流程顺利完成。

但现实网络中还存在另一种情况：终端不支持标准切片，且UE请求的DNN在AMF的映射表中找不到对应的S-NSSAI。 这就是本篇要讨论的"DNN配置不一致"场景。

什么是"DNN配置不一致"？

"DNN配置不一致"指的是以下几种典型情况：

  1. PCF下发的URSP中的DNN，在AMF的DNN-to-S-NSSAI映射表中不存在对应条目；

  2. UE请求的DNN（如"apn2"或"Internet9"）与AMF映射表中配置的DNN名称不匹配；

  3. 运营商在不同网元上独立配置DNN映射关系，导致PCF和AMF的配置出现偏差。

这类问题在现网中并不罕见，特别是在多厂家组网、分域管理、配置变更频繁的网络环境中。

本场景的典型配置示例

配置项 取值 说明
UE签约切片 S-NSSAI(2,1) 和 S-NSSAI(9,1) 用户签约了两个切片
Allowed NSSAI (2,1) 和 (9,1) 注册时下发给UE
PCF URSP中DNN apn2, Internet9 PCF为不同应用分配的DNN
AMF DNN映射表 apn9 -> (9,1), internet -> (1,X) 注意: 没有apn2和Internet9
subscribed-snssais UE签约的S-NSSAI列表 从UDM获取
nf-id AMF实例ID 用于NSSF判断是否需要重定向
tai 跟踪区标识 用于区域化切片策略匹配
home-plmn-id 归属PLMN标识 区分漫游场景

协议参考：根据3GPP TS 29.531 第5.3.2节，NSSF的NSSelection服务支持在无Requested NSSAI的情况下，基于Subscribed S-NSSAI和default标记进行切片推荐。NSSF会综合考虑AMF的能力、切片配置策略和区域信息来给出推荐。

2.5 UE使用DNN=Internet9发起PDU会话——另一组不一致场景

接下来看第二个DNN——Internet9。这个DNN同样不在AMF的映射表中，但处理流程可能与apn2有所不同。


# UE -> (R)AN -> AMF（PDU会话建立请求——DNN=Internet9）

Frame: 1120

NAS-5GS PDU Session Establishment Request

  PDU session ID: 5

  PTI: 0

  DNN: Internet9

    # 另一个在AMF映射表中不存在的DNN

    # 注意大小写: "Internet9" vs "internet"

    # AMF映射表中是"internet"而非"Internet9"

  PDU session type: IPv4

  SSC mode: SSC_MODE_1

DNN大小写敏感性问题：

在实际网络中，DNN的大小写敏感性是一个常见的配置问题。不同厂家对DNN的处理策略可能不同：

厂家行为 示例 影响
大小写敏感 "Internet9" != "internet" 配置不一致导致映射失败
大小写不敏感 "Internet9" == "internet" 可以匹配成功
PCF不敏感, AMF敏感 PCF下发"Internet9", AMF要求"internet" 导致本篇描述的问题

2.6 回退策略的综合决策流程

综合来看，当DNN映射查找失败后，AMF的完整回退决策流程如下：


flowchart TD

    A["AMF收到PDU Session Request(仅DNN, 无S-NSSAI)"] --> B["查找DNN-S-NSSAI映射表"]

    B -->|"找到"| Z["正常流程: 使用映射的S-NSSAI"]

    B -->|"未找到"| C["回退策略1: 使用Default S-NSSAI"]

    C -->|"Default S-NSSAI存在且可用"| D["使用Default S-NSSAI发现SMF"]

    C -->|"Default S-NSSAI不存在"| E["回退策略2: 查询NSSF"]

    D --> F["NRF发现SMF"]

    F -->|"发现成功"| G["PDU会话建立成功"]

    F -->|"发现失败(无匹配SMF)"| E

    E -->|"NSSF返回有效切片"| H["使用NSSF推荐的S-NSSAI"]

    E -->|"NSSF无匹配策略"| I["回退策略3: AMF本地默认切片"]

    H --> F

    I -->|"本地默认切片存在"| F

    I -->|"本地默认切片不存在"| J["PDU Session Reject"]

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

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

    style J fill:#ffcdd2,stroke:#c62828,stroke-width:2px

协议参考：根据3GPP TS 23.501 第5.15.9.2节，当UE未提供S-NSSAI时，AMF应按以下优先级确定S-NSSAI：1）DNN映射；2）Default Subscribed S-NSSAI；3）NSSF查询；4）本地配置。如果所有回退策略均失败，AMF应拒绝PDU会话建立请求。

2.7 【硬核附加】第7篇与本篇的对比分析

将第7篇（DNN配置一致）和第8篇（DNN配置不一致）放在一起对比，可以清晰地看到DNN映射配置的重要性：

对比维度 第7篇（DNN一致） 第8篇（DNN不一致）
UE请求DNN apn9 apn2 / Internet9
AMF映射表 有apn9 -> (9,1) 无apn2和Internet9
切片确定方式 DNN直接映射 多层回退策略
SMF发现 直接成功 可能失败需回退
会话建立 一次成功 可能需要多次尝试
网络负载 正常 增加NSSF/NRF查询
用户体验 无感知 可能延迟或失败

运维建议：

  1. 定期同步PCF和AMF的DNN配置：在每次网络调整后，检查PCF的URSP策略中的DNN列表与AMF的DNN-to-S-NSSAI映射表是否一致；

  2. 统一DNN命名规范：在多厂家组网环境中，制定统一的DNN命名规范（包括大小写）；

  3. 监控回退策略触发频率：如果AMF频繁触发DNN映射回退策略，说明配置存在不一致，需要排查；

  4. 为关键DNN配置回退保障：在NSSF上为常见的DNN配置回退切片策略，作为最后一道保障。

3 测试结论

验证项 结果 说明
UE发起PDU会话(DNN=apn2) OK UE在PDU Session Request中携带DNN=apn2，不携带S-NSSAI
AMF DNN映射查找失败 OK AMF本地映射表中无DNN=apn2对应条目
AMF回退策略(Default S-NSSAI) OK AMF使用UE签约的Default S-NSSAI(2,1)作为回退
SMF发现与会话建立 OK/失败 取决于Default S-NSSAI是否支持该DNN
UE发起PDU会话(DNN=Internet9) OK 触发第二个不一致场景
NSSF回退查询 OK AMF向NSSF查询切片推荐
最终会话结果 视配置 成功建立或被正确拒绝

本测试用例验证了"终端不支持标准切片且DNN配置不一致"场景下的AMF回退处理机制。当DNN-to-S-NSSAI映射查找失败后，AMF通过Default S-NSSAI回退和NSSF查询回退等多层次策略来尝试确定S-NSSAI。这些回退机制是5GC在非理想配置下保持可用性的关键设计。

与第7篇的对比再次印证了一个重要结论：DNN配置一致性是保障非标准切片终端正常工作的基础。 运维人员应定期检查和同步PCF与AMF的DNN配置，从源头减少回退策略的触发。

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

← 返回 NSSF 实践篇