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

5GC实践篇之NSSF篇第6篇：PDU会话建立时的切片选择

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

5GC实践篇之NSSF篇第6篇：PDU会话建立时的切片选择

作者：爱卫生

1 测试背景与用例简介

在前面的系列文章中，我们重点聚焦了NSSF在注册流程中的切片选择机制——从初始AMF选择到重定向、从默认切片匹配到无匹配策略拒绝，覆盖了UE入网阶段NSSF的全部工作场景。从本篇开始，我们将视角转向5G核心网的另一个关键时刻：PDU会话建立时的切片选择。

很多读者可能会问：UE在注册时不是已经完成了切片选择吗？为什么在PDU会话建立时还要再做一次？

答案是：注册阶段的切片选择解决的是"UE能接入哪些切片"的问题，而PDU会话建立阶段解决的是"UE的这个具体业务会话应该走哪个切片"的问题。 这两者并不完全相同。

打个比方：注册时UE拿到了一张"准入许可证"（Allowed NSSAI），告诉你"这几个切片你有资格使用"。但当你要发起一个具体的业务（比如视频通话、网络游戏、IoT数据上报），你需要根据业务类型选择最合适的切片。这个选择过程就是PDU会话建立时的切片选择。

本篇的核心流程链路如下：

  1. UE在注册过程中从PCF获取URSP（UE Route Selection Policy）策略，其中包含NSSP（Network Slice Selection Policy）规则；

  2. UE根据应用类型匹配NSSP规则，确定该应用对应的DNN和S-NSSAI组合；

  3. UE判断所选S-NSSAI是否在Allowed NSSAI中，如果不在则不能发起PDU会话；

  4. UE在PDU Session Establishment Request中携带DNN和S-NSSAI；

  5. AMF根据DNN+S-NSSAI通过NRF发现合适的SMF；

  6. SMF建立PDU会话，完成切片内的数据传输通道建设。

详细消息流程图


sequenceDiagram

    participant UE

    participant RAN as RAN

    participant AMF

    participant NRF

    participant SMF

    participant UDM

    participant PCF

    Note over UE, PCF: 阶段一: 注册流程中PCF下发NSSP策略

    UE->>AMF: Registration Request

    AMF->>PCF: Npcf_UEPolicyControl_Get

    PCF-->>AMF: URSP(含NSSP规则)

    AMF-->>UE: Registration Accept + URSP

    Note over UE, PCF: 阶段二: PDU会话建立时的切片选择

    UE->>UE: 根据应用匹配NSSP, 选择DNN+S-NSSAI

    UE->>UE: 检查S-NSSAI是否在Allowed NSSAI中

    UE->>RAN: PDU Session Establishment Request(DNN+S-NSSAI)

    RAN->>AMF: N2 PDU Session Request(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 UE侧切片选择决策

        A["UE发起应用请求"] --> B["匹配URSP中的NSSP规则"]

        B --> C["确定DNN + S-NSSAI"]

        C --> D["校验S-NSSAI在Allowed NSSAI中"]

        D -->|"是"| E["PDU Session Request携带DNN+S-NSSAI"]

        D -->|"否"| F["禁止发起PDU会话"]

    end

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

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

测试目的

验证PDU会话建立过程中的切片选择处理是否正确，包括：UE根据NSSP策略选择S-NSSAI、AMF基于S-NSSAI发现SMF、SMF正确处理切片信息。

测试前置条件

  1. 终端、RAN、AMF、UDM、NSSF、NRF等网元均支持切片选择功能。

  2. 环境已配置好相关切片信息，UE在UDM成功签约了切片数据，PCF上配置了DNN以及S-NSSAI的对应数据。

  3. AMF上配置了支持的切片信息以及与GUAMI的对应关系。

  4. RAN支持在NG Setup流程与AMF交互AMF的切片以及GUAMI关系。

  5. UE已成功在5G网络注册，网络侧已将Allowed NSSAI以及Configured NSSAI信息下发给UE并保存在终端上。

  6. UE已在注册过程中成功获取来自PCF下发的URSP策略。

测试步骤

  1. UE发起PDU会话建立请求。

  2. 检查消息跟踪，验证PDU Session Establishment Request中是否携带正确的DNN和S-NSSAI。

  3. 检查AMF向NRF发送的NFDiscovery请求是否携带DNN和SNSSAI参数。

  4. 检查AMF向SMF发送的CreateSMContext请求中是否携带DNN和S-NSSAI。

  5. 在AMF和SMF上查看UE的上下文信息，确认切片信息正确。

测试结果验证（预期）

  1. UE在PDU Session Establishment Request消息中携带正确的DNN和S-NSSAI信息。

  2. AMF向NRF发送的Nnrf_NFDiscovery_Request消息携带DNN和SNSSAI参数，NRF响应200 OK并返回匹配的SMF信息。

  3. AMF向SMF发送的Nsmf_PDUSession_CreateSMContext Request消息中携带DNN和S-NSSAI信息。

  4. SMF成功向UDM获取签约数据，签约数据包含正确的S-NSSAI和DNN信息。

  5. PDU会话建立成功，数据传输正常。

2 信令深度解析

在本测试中，切片选择的核心逻辑分布在UE侧决策和网络侧SMF发现两个环节。下面我们逐条消息进行深度解析。

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

2.1 UE侧切片选择决策——NSSP规则匹配

PDU会话建立时的切片选择，起点不在网络侧，而是在UE终端内部。UE需要根据PCF下发的URSP策略中的NSSP规则来决定"我这次业务要用哪个切片"。

NSSP规则的核心逻辑如下：


flowchart TD

    A["UE上的应用发起数据连接请求"] --> B["UE查询本地URSP中的NSSP规则"]

    B --> C["规则匹配: 应用描述符 -> 路由选择描述符"]

    C --> D["路由选择描述符包含: DNN + S-NSSAI"]

    D --> E["UE检查该S-NSSAI是否在Allowed NSSAI中"]

    E -->|"在Allowed NSSAI中"| F["UE在PDU Session Request中携带该DNN + S-NSSAI"]

    E -->|"不在Allowed NSSAI中"| G["UE不能发起PDU会话建立"]

    E -->|"UE未携带S-NSSAI"| H["AMF基于签约数据或本地配置选择default S-NSSAI"]

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

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

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

URSP/NSSP关键字段解读：

URSP组件 含义 说明
Traffic Descriptor 流量描述符 匹配规则，如App ID、IP描述符、DNN等
Route Selection Descriptor 路由选择描述符 匹配后执行的动作，包含DNN、S-NSSAI、SSC模式等
NSSP 网络切片选择策略 URSP中的子策略，专门负责切片选择

协议参考：根据3GPP TS 23.501 第5.15节，URSP策略由PCF通过AMF下发给UE，其中NSSP规则定义了应用与网络切片的映射关系。UE在发起PDU会话时必须遵循这些规则。

2.2 PDU会话建立请求——携带DNN和S-NSSAI

当UE确定了要使用的DNN和S-NSSAI后，它会在PDU Session Establishment Request消息中携带这些信息。这是AMF进行后续SMF选择的直接依据。


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

Frame: 1256 & 1260

NAS-5GS PDU Session Establishment Request

  PDU session ID: 1

  PTI: 0

  DNN: internet

    # 数据网络名称，UE根据NSSP策略选择

  S-NSSAI:

    SST: 1

      # Slice/Service Type = 1 (eMBB)

    SD: XXXXXXX

      # Slice Differentiator，区分同一SST下的不同切片

  PDU session type: IPv4

  SSC mode: SSC_MODE_1

关键信元解读：

信元 取值 含义
DNN internet 数据网络名称，标识UE要访问的外部数据网络
S-NSSAI.SST 1 切片服务类型为eMBB
S-NSSAI.SD XXXXXXX 切片区分标识
PDU session ID 1 UE侧分配的会话标识
nf-type 目标NF类型 固定为SMF
dnn 数据网络名称 UE请求的DNN
snssai 网络切片标识 UE请求的S-NSSAI，AMF优先使用UE携带的值
tai 跟踪区标识 限定SMF的服务区域范围

协议参考：根据3GPP TS 29.531 第5.3.2节，NRF的NFDiscovery服务支持基于DNN和S-NSSAI的SMF发现。NRF会在已注册的SMF实例中筛选出同时支持指定DNN和S-NSSAI的实例返回给AMF。

2.4 AMF向SMF发起会话创建——传递切片信息

NRF返回了合适的SMF信息后，AMF将PDU会话管理权交给SMF，同时将DNN和S-NSSAI信息传递过去。


# AMF -> SMF（创建SM上下文请求）

Frame: 1278

HEADERS: POST /nsmf-pdusession/v1/sm-contexts

JavaScript Object Notation: application/json

  Object

    Member Key: dnn

      String value: "internet"

        # 数据网络名称

    Member Key: snssai

      Object

        Member Key: sst

          Number value: 1

        Member Key: sd

          String value: "XXXXXXX"

            # UE请求的S-NSSAI

    Member Key: serveNfId

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

        # AMF的NF Instance ID

    Member Key: supi

      String value: "imsi-460XX00000XXXX"

        # 用户永久标识（已脱敏）

    Member Key: pduSessionId

      Number value: 1

    Member Key: requestType

      String value: "INITIAL_REQUEST"

        # 初始PDU会话建立请求



# SMF -> UDM（获取签约数据）

Frame: 1285

HEADERS: GET /nudm-sdm/v1/imsi-460XX00000XXXX/sm-data

  ?dnn=internet

  &s-nssai=%7B%22sst%22%3A1%2C%22sd%22%3A%22XXXXXXX%22%7D

# UDM -> SMF（返回签约数据）

Frame: 1289

HEADERS: 200 OK

JavaScript Object Notation: application/json

  Object

    Member Key: singleNssai

      Object

        Member Key: sst

          Number value: 1

        Member Key: sd

          String value: "XXXXXXX"

            # 签约的S-NSSAI

    Member Key: dnnConfigurations

      Object

        Member Key: internet

          Object

            # DNN=internet的签约配置信息

            Member Key: pduSessionTypes

              ...

            Member Key: 5gQosProfile

              ...

SMF获取签约数据后的验证逻辑：


flowchart TD

    A["SMF收到CreateSMContext请求"] --> B["向UDM获取签约数据"]

    B -->|"200 OK"| C["验证签约数据"]

    B -->|"失败"| FAIL1["会话建立失败: 签约数据获取失败"]

    C --> D["检查UE是否签约该S-NSSAI"]

    D -->|"已签约"| E["检查UE是否签约该DNN"]

    D -->|"未签约"| FAIL2["会话建立失败: S-NSSAI未签约"]

    E -->|"已签约"| F["继续PDU会话建立流程"]

    E -->|"未签约"| FAIL3["会话建立失败: DNN未签约"]

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

    style FAIL1 fill:#ffcdd2,stroke:#c62828

    style FAIL2 fill:#ffcdd2,stroke:#c62828

    style FAIL3 fill:#ffcdd2,stroke:#c62828

2.5 SMF返回会话建立结果——N1N2消息传递

PDU会话建立完成后，SMF通过AMF将NAS消息透传给UE，其中包含S-NSSAI信息，确认该PDU会话所使用的切片。


# SMF -> AMF（N1N2消息传递）

Frame: 1310

HEADERS: POST /namf-comm/v1/ue-contexts/imsi-460XX00000XXXX/n1-n2-messages

JavaScript Object Notation: application/json

  Object

    Member Key: n1MessageContainer

      Object

        Member Key: n1MessageClass

          String value: "SM"

            # NAS SM消息

        Member Key: n1MessageContent

          # PDU Session Establishment Accept

          # 包含: PDU Session ID=1, DNN=internet, S-NSSAI=SST:1/SD:XXXXXXX

    Member Key: n2InfoContainer

      Object

        Member Key: n2InformationClass

          String value: "SM"

        Member Key: smInfo

          Object

            Member Key: snssai

              Object

                Member Key: sst

                  Number value: 1

                Member Key: sd

                  String value: "XXXXXXX"

                    # PDU会话使用的S-NSSAI

            Member Key: dnn

              String value: "internet"

协议参考：根据3GPP TS 23.501 第5.15.9节，SMF在PDU会话建立过程中需要验证UE请求的S-NSSAI是否在签约数据中，并且该DNN是否在该S-NSSAI下被授权使用。

2.6 【硬核附加】UE未携带S-NSSAI时的回退机制

在实际网络中，存在一种常见场景：UE的PDU Session Establishment Request消息中没有携带S-NSSAI。这可能是因为：

  • UE不支持标准的网络切片功能（将在第7、8篇详细讨论）；

  • UE的NSSP规则中没有为该应用指定S-NSSAI；

  • UE处于漫游场景，Allowed NSSAI受限。

此时AMF的处理逻辑如下：


flowchart TD

    A["AMF收到PDU Session Request"] --> B["检查是否携带S-NSSAI"]

    B -->|"UE携带了S-NSSAI"| C["使用UE请求的S-NSSAI"]

    B -->|"UE未携带S-NSSAI"| D["AMF从签约数据中获取Default S-NSSAI"]

    D --> E["使用Default S-NSSAI进行SMF发现"]

    E -->|"签约中存在Default S-NSSAI"| F["正常发现SMF并建立会话"]

    E -->|"签约中不存在Default S-NSSAI"| G["AMF基于本地配置策略选择S-NSSAI"]

    G -->|"本地配置存在"| F

    G -->|"本地配置也不存在"| H["会话建立失败"]

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

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

Default S-NSSAI的来源：

来源 说明
UDM签约数据 用户签约中标记为default的S-NSSAI，优先级最高
AMF本地配置 运营商在AMF上配置的默认切片策略
Configured NSSAI 网络侧在注册时下发给UE的配置NSSAI（当UE重新携带时使用）

3 测试结论

验证项 结果 说明
PDU会话建立成功 OK UE成功建立PDU会话，数据传输正常
UE根据NSSP选择S-NSSAI OK UE在PDU Session Request中正确携带DNN+S-NSSAI
AMF基于DNN+S-NSSAI发现SMF OK Nnrf_NFDiscovery_Request携带正确的DNN和SNSSAI参数
SMF获取签约数据验证 OK SMF成功从UDM获取签约的S-NSSAI和DNN信息
N1N2消息传递S-NSSAI OK SMF通过AMF将S-NSSAI信息传递给UE
UE未携带S-NSSAI的回退 OK AMF正确使用Default S-NSSAI（如果适用）

本测试用例验证了PDU会话建立时的完整切片选择流程。从UE侧的NSSP规则匹配，到网络侧的AMF SMF发现和选择，再到SMF的签约数据验证，每一个环节都紧密配合，确保了"正确的业务走正确的切片"。整个信令流程与3GPP TS 29.531和TS 23.501规范完全一致。

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

← 返回 NSSF 实践篇