5G核心网学习平台
网络切片 实践篇 #08

5GC实践篇之切片篇第17篇:并发接入多个同类型网络切片

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

5GC实践篇之切片篇第17篇:并发接入多个同类型网络切片

作者:爱卫生


1 测试背景与用例简介

5G网络切片的核心价值之一,在于允许一个终端同时接入多个不同的网络切片,为不同的业务提供差异化的网络服务。比如,一部工业终端可能同时需要eMBB切片来传输高清视频监控画面,又需要URLLC切片来承载低时延的控制指令。

本篇测试验证的是:UE在已注册的Allowed NSSAI包含多个S-NSSAI的情况下,如何并发地建立多个PDU Session,分别接入不同的网络切片?整个过程中,NSSP(Network Slice Selection Policy)如何指导UE选择正确的S-NSSAI?AMF、NRF、SMF各网元如何协同完成多切片的并发会话管理?

测试场景描述

本测试的具体场景是:

  • UE已成功注册到5G网络

  • Allowed NSSAI包含两个S-NSSAI:S-NSSAI(2,1)S-NSSAI(9,1)

  • UE已从PCF获取到NSSP策略信息

  • UE需要分别使用两个切片建立独立的PDU Session:

  • PDU Session 1:DNN=apn2,S-NSSAI=(2,1)

  • PDU Session 2:DNN=Internet9,S-NSSAI=(9,1)

为什么需要并发接入多切片?

在实际部署中,并发多切片接入的场景越来越普遍:

行业场景 切片1用途 切片2用途
工业制造 eMBB视频回传 URLLC设备控制
智慧医疗 eMBB影像传输 URLLC远程手术
自动驾驶 eMBB高清地图 URLLC车联网
智慧电网 eMBB数据采集 URLLC继电保护

2 协议规范与关键技术

2.1 NSSP(Network Slice Selection Policy)

NSSP是URSP(UE Route Selection Policy)的重要组成部分,定义在3GPP TS 23.501第5.15.7节。它由PCF通过AMF下发给UE,用于指导UE在发起业务时选择合适的S-NSSAI。

NSSP规则结构:


URSP Rule:

  Rule Priority: 1

  Traffic Descriptor:

    - DNN: apn2

    - IP Descriptor: any

  Route Selection Descriptor:

    - S-NSSAI: (2,1)

    - DNN: apn2

    - SSC Mode: 1

URSP Rule:

  Rule Priority: 2

  Traffic Descriptor:

    - DNN: Internet9

  Route Selection Descriptor:

    - S-NSSAI: (9,1)

    - DNN: Internet9

    - SSC Mode: 1

UE在发起PDU Session建立前,会根据应用层提供的DNN等信息匹配NSSP规则,确定应该使用哪个S-NSSAI。

2.2 PDU Session建立中的切片选择

PDU Session建立流程中涉及切片选择的关键环节:


flowchart TD

    A[UE准备发起业务] --> B[查询NSSP规则]

    B --> C[匹配到S-NSSAI]

    C --> D{S-NSSAI在Allowed NSSAI中}

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

    D -->|否| F[不能发起PDU Session建立]

    E --> G[AMF收到请求]

    G --> H{UE是否携带S-NSSAI}

    H -->|是| I[使用UE指定的S-NSSAI]

    H -->|否| J[基于签约或本地策略选择Default S-NSSAI]

    I --> K[向NRF发现对应SMF]

    J --> K

2.3 NRF切片感知的SMF发现

AMF在为PDU Session选择SMF时,需要通过NRF进行切片感知的服务发现。NRF根据请求中的S-NSSAI和DNN返回支持该切片的SMF实例列表。

这一机制定义在3GPP TS 29.510第6.2.6节(Nnrf_NFDiscovery)。

2.4 关键协议参考

协议文档 相关章节 内容
TS 23.501 5.15.7 URSP与NSSP策略框架
TS 23.501 5.15.9 NSSAI管理
TS 23.502 4.3.2 PDU Session建立流程
TS 24.501 5.6.1 PDU Session建立NAS信令
TS 29.510 6.2.6 NRF NF Discovery
TS 29.502 5.1 SMF服务接口
TS 38.413 8.7 NGAP切片相关

3 消息流程与详细解读

3.1 前提条件:注册流程中的NSSP下发

在PDU Session建立之前,UE必须先完成注册流程,并在注册过程中获取NSSP信息。


sequenceDiagram

    participant UE as UE

    participant RAN as gNB

    participant AMF as AMF

    participant PCF as PCF

    UE->>RAN: Registration Request

    RAN->>AMF: Registration Request

    AMF->>PCF: Npcf_UEPolicyControl_Get(NSSP请求)

    PCF-->>AMF: Npcf_UEPolicyControl_Response(NSSP策略)

    AMF->>RAN: Registration Accept(Allowed NSSAI, NSSP)

    RAN->>UE: Registration Accept(Allowed NSSAI, NSSP)

    Note over UE: UE保存NSSP策略<br/>Allowed NSSAI=(2,1)+(9,1)

注册完成后,UE本地保存了:

  • Allowed NSSAI:S-NSSAI(2,1) 和 S-NSSAI(9,1)

  • NSSP策略:包含DNN到S-NSSAI的映射规则

3.2 PDU Session 1建立(切片S-NSSAI 2,1)

步骤1:UE发起PDU Session建立请求

UE根据NSSP规则,确定DNN=apn2对应S-NSSAI(2,1),首先检查该S-NSSAI是否在Allowed NSSAI中。确认存在后,发起PDU Session Establishment Request:


UL NAS Transport

  -- PDU Session ID: 1

  -- Request Type: Initial Request

  -- DNN: apn2

  -- S-NSSAI:

    -- SST: 2

    -- SD: 1

  -- PDU Session Establishment Request (SM容器)

    -- PDUSessionType: IPv4

    -- SSC Mode: 1

步骤2:AMF通过NRF发现SMF

AMF收到PDU Session建立请求后,根据S-NSSAI和DNN向NRF查询可用的SMF:


Nnrf_NFDiscovery_Request

  -- target-nf-type: SMF

  -- requester-nf-type: AMF

  -- snssai:

    -- sst: 2

    -- sd: 1

  -- dnn: apn2

  -- tintai: TAC=xxxxx

NRF响应:


Nnrf_NFDiscovery_Response (200 OK)

  -- NFProfile:

    -- NF Instance ID: smf-001

    -- NF Type: SMF

    -- IP: 10.x.x.x

    -- Supported S-NSSAI List:

      -- SST:2, SD:1

    -- DNN List: apn2, internet

步骤3:AMF向SMF发送创建SM Context请求


Nsmf_PDUSession_CreateSMContext Request

  -- PDU Session ID: 1

  -- DNN: apn2

  -- S-NSSAI:

    -- SST: 2

    -- SD: 1

  -- SUPI: imsi-4608800000XXXXXX

  -- AMF ID: amf-001

  -- Request Type: Initial Request

步骤4:SMF获取UE签约数据

SMF向UDM获取该UE的会话管理签约数据:


Nudm_SDM_Get(Request: SM Data)

  -- SUPI: imsi-4608800000XXXXXX

  -- S-NSSAI: SST:2, SD:1

Nudm_SDM_Get Response (200 OK)

  -- Subscribed Default S-NSSAI: SST:2, SD:1

  -- Subscribed S-NSSAI List:

    -- SST:2, SD:1 (apn2)

    -- SST:9, SD:1 (Internet9)

  -- DNN Configuration for apn2:

    -- PDUSessionType: IPv4

    -- SSCMode: 1,2,3

    -- 5QI: 80

步骤5:SMF响应创建SM Context


Nsmf_PDUSession_CreateSMContext Response (200 OK)

  -- PDU Session ID: 1

  -- Cause: REQUEST_ACCEPTED

步骤6:SMF通过AMF转发NAS消息给UE


Namf_Communication_N1N2MessageTransfer

  -- N2 SM Info (PDU Session Resource Setup)

  -- N1 SM Container: PDU Session Establishment Accept

    -- PDU Session ID: 1

    -- PDU Address: 172.x.x.x

    -- DNN: apn2

    -- S-NSSAI: SST:2, SD:1

    -- QoS Rules

AMF将N1 NAS消息透传给UE,同时通过NGAP向gNB发送PDU Session Resource Setup Request。

3.3 PDU Session 2建立(切片S-NSSAI 9,1)

在第一个PDU Session建立成功后(或并发地),UE使用DNN=Internet9和S-NSSAI(9,1)发起第二个PDU Session的建立。

流程与PDU Session 1类似,关键差异在于:


UL NAS transport

  -- PDU Session ID: 2

  -- Request Type: Initial Request

  -- DNN: Internet9

  -- S-NSSAI:

    -- SST: 9

    -- SD: 1

NRF发现SMF的请求:


Nnrf_NFDiscovery_Request

  -- snssai:

    -- sst: 9

    -- sd: 1

  -- dnn: Internet9

根据实际网络配置,S-NSSAI(9,1)对应的SMF可能与S-NSSAI(2,1)的SMF相同(同一SMF支持多切片),也可能不同(切片专属SMF)。本测试中两个PDU Session可能由不同的SMF/UPF服务,充分体现了5G切片的端到端资源隔离能力。

3.4 完整并发流程时序


sequenceDiagram

    participant UE as UE

    participant RAN as gNB

    participant AMF as AMF

    participant NRF as NRF

    participant SMF1 as SMF(SST:2)

    participant SMF2 as SMF(SST:9)

    participant UDM as UDM

    Note over UE: Allowed NSSAI: (2,1) + (9,1)

    rect rgb(230,240,255)

    Note over UE,SMF1: PDU Session 1: DNN=apn2, S-NSSAI=(2,1)

    UE->>RAN: UL NAS Transport(PDU Session ID=1, DNN=apn2, S-NSSAI=(2,1))

    RAN->>AMF: UL NAS Transport

    AMF->>NRF: Nnrf_NFDiscovery(S-NSSAI=(2,1), DNN=apn2)

    NRF-->>AMF: SMF Profile(SMF1)

    AMF->>SMF1: Nsmf_PDUSession_CreateSMContext(DNN=apn2, S-NSSAI=(2,1))

    SMF1->>UDM: Nudm_SDM_Get(SM签约数据)

    UDM-->>SMF1: 签约S-NSSAI列表

    SMF1-->>AMF: CreateSMContext Response(200 OK)

    SMF1->>AMF: Namf_Communication_N1N2MessageTransfer(PDU Session Accept)

    AMF->>RAN: PDU Session Resource Setup + NAS透传

    RAN->>UE: NAS: PDU Session Establishment Accept(IP=172.x.x.x)

    end

    rect rgb(255,240,230)

    Note over UE,SMF2: PDU Session 2: DNN=Internet9, S-NSSAI=(9,1)

    UE->>RAN: UL NAS Transport(PDU Session ID=2, DNN=Internet9, S-NSSAI=(9,1))

    RAN->>AMF: UL NAS Transport

    AMF->>NRF: Nnrf_NFDiscovery(S-NSSAI=(9,1), DNN=Internet9)

    NRF-->>AMF: SMF Profile(SMF2)

    AMF->>SMF2: Nsmf_PDUSession_CreateSMContext(DNN=Internet9, S-NSSAI=(9,1))

    SMF2->>UDM: Nudm_SDM_Get(SM签约数据)

    UDM-->>SMF2: 签约S-NSSAI列表

    SMF2-->>AMF: CreateSMContext Response(200 OK)

    SMF2->>AMF: Namf_Communication_N1N2MessageTransfer(PDU Session Accept)

    AMF->>RAN: PDU Session Resource Setup + NAS透传

    RAN->>UE: NAS: PDU Session Establishment Accept(IP=10.x.x.x)

    end

    Note over UE: 两个PDU Session建立成功<br/>分别使用不同切片

4 关键信令参数分析

4.1 UE侧的S-NSSAI选择逻辑

UE在发送PDU Session Establishment Request时,对S-NSSAI的处理逻辑如下:


UE NSSP匹配逻辑:

1. 应用层请求DNN=apn2

2. 查询NSSP规则 → 匹配到S-NSSAI=(2,1)

3. 检查S-NSSAI=(2,1)是否在Allowed NSSAI中

4. Allowed NSSAI = {(2,1), (9,1)} → 匹配成功

5. 携带DNN=apn2, S-NSSAI=(2,1)发起PDU Session建立


UE NSSP匹配逻辑:

1. 应用层请求DNN=Internet9

2. 查询NSSP规则 → 匹配到S-NSSAI=(9,1)

3. 检查S-NSSAI=(9,1)是否在Allowed NSSAI中

4. Allowed NSSAI = {(2,1), (9,1)} → 匹配成功

5. 携带DNN=Internet9, S-NSSAI=(9,1)发起PDU Session建立

关键规则:如果UE已经获取到NSSP信息,UE会根据NSSP策略选择S-NSSAI,同时判断该S-NSSAI是否在Allowed NSSAI中。如果不在Allowed NSSAI中,UE不能发起PDU Session建立。

4.2 AMF侧的S-NSSAI处理

AMF收到PDU Session Establishment Request后的处理逻辑:

UE是否携带S-NSSAI AMF行为
携带了S-NSSAI 使用UE请求的S-NSSAI
未携带S-NSSAI 基于签约数据或本地配置策略选择Default S-NSSAI

本测试中UE均携带了S-NSSAI,AMF直接使用UE指定的值。

4.3 NRF发现请求中的切片参数

两个PDU Session的NRF发现请求对比:

参数 PDU Session 1 PDU Session 2
target-nf-type SMF SMF
S-NSSAI SST:2, SD:1 SST:9, SD:1
DNN apn2 Internet9
返回的SMF SMF-001 SMF-002(或SMF-001)

4.4 UDM签约数据验证

SMF从UDM获取的签约数据中,关键验证项:


SM签约数据:

  GPSI: 86138000XXXXXX

  Default S-NSSAI: SST:2, SD:1

  Subscribed S-NSSAI List:

    - {SST:2, SD:1, DNN:[apn2]}

    - {SST:9, SD:1, DNN:[Internet9]}

SMF需要验证UE请求的S-NSSAI确实在该UE的签约数据中,否则将拒绝PDU Session建立。

4.5 两个PDU Session的对比

属性 PDU Session 1 PDU Session 2
PDU Session ID 1 2
DNN apn2 Internet9
S-NSSAI SST:2, SD:1 SST:9, SD:1
IP地址 172.x.x.x 10.x.x.x
SMF SMF-001 SMF-002
UPF UPF-001 UPF-002
QoS 取决于切片配置 取决于切片配置

5 测试验证与数据解读

5.1 测试步骤与检查点

检查点1:NSSP策略已下发

伴随UE注册流程,PCF已经把NSSP信息通过AMF下发给UE。可通过以下方式验证:

  • 检查Registration Accept中是否包含UE Policy容器

  • 检查AMF日志中Npcf_UEPolicyControl的交互记录

检查点2:UE正确使用NSSP选择S-NSSAI

验证UE在PDU Session Establishment消息中携带的S-NSSAI与NSSP规则一致:

  • DNN=apn2 → S-NSSAI=(2,1)

  • DNN=Internet9 → S-NSSAI=(9,1)

检查点3:AMF正确发现切片对应的SMF

验证AMF向NRF发送的发现请求中携带了正确的S-NSSAI和DNN,NRF返回了支持该切片的SMF实例。

检查点4:SMF正确获取并验证签约数据

SMF从UDM获取的签约数据中确认:

  • UE签约了请求的S-NSSAI

  • DNN在签约的DNN列表中

  • 请求参数与签约配置一致

检查点5:两个PDU Session独立建立成功

验证两个PDU Session均成功建立,分别使用不同的S-NSSAI,数传正常。

5.2 测试结果

验证项 结果
UE两个PDU Session建立成功 通过
PDU Session 1: S-NSSAI=(2,1), DNN=apn2 通过
PDU Session 2: S-NSSAI=(9,1), DNN=Internet9 通过
两个切片的数传均正常 通过
AMF正确进行NRF发现 通过
SMF正确获取签约数据 通过
消息跟踪符合协议流程 通过

5.3 关键日志参考

AMF日志(PDU Session 1建立):


[AMF] Received UL NAS Transport from UE imsi-4608800000XXXXXX

  PDU Session ID: 1, DNN: apn2, S-NSSAI: SST=2 SD=1

[AMF] NRF Discovery: S-NSSAI=(2,1), DNN=apn2

[AMF] Selected SMF: smf-001

[AMF] Nsmf_PDUSession_CreateSMContext sent to smf-001

[AMF] CreateSMContext Response received: 200 OK

[AMF] N1N2 Message Transfer received from smf-001

[AMF] Forwarding NAS to UE via NGAP

SMF日志(PDU Session 1建立):


[SMF-001] CreateSMContext Request received

  SUPI: imsi-4608800000XXXXXX, PDU Session ID: 1

  DNN: apn2, S-NSSAI: SST=2 SD=1

[SMF-001] Fetching SM subscription data from UDM

[SMF-001] Subscription verified: S-NSSAI=(2,1) is subscribed

[SMF-001] PDU Session created: IP=172.x.x.x

6 小结与思考

6.1 核心要点总结

本篇验证了5G网络切片的并发多切片接入能力,核心流程要点:

  1. NSSP策略驱动:UE根据PCF下发的NSSP规则,为不同DNN选择对应的S-NSSAI

  2. Allowed NSSAI验证:UE在发起PDU Session前必须确认S-NSSAI在Allowed NSSAI中

  3. NRF切片感知发现:AMF通过NRF的S-NSSAI+DNN参数精确发现支持特定切片的SMF

  4. 签约数据校验:SMF从UDM获取签约数据,验证UE请求的S-NSSAI确实已签约

  5. 端到端隔离:两个PDU Session可以使用不同的SMF/UPF,实现切片级资源隔离

6.2 同类型切片的含义

本篇标题中的"同类型网络切片"指的是:两个S-NSSAI虽然在SST和SD值上不同((2,1)和(9,1)),但它们都是标准切片类型,使用相同的PDU Session建立流程。它们之间的差异体现在:

  • 不同的SMF实例:可以部署切片专属的SMF

  • 不同的UPF实例:数据面完全隔离

  • 不同的QoS策略:通过不同的5QI/DSCP实现差异化

  • 不同的计费规则:独立的计费域

6.3 与单切片接入的对比

维度 单切片接入 多切片并发接入
PDU Session数 1 N
SMF 1个 1~N个
UPF 1个 1~N个
NSSP策略 简单 多规则匹配
UE复杂度 需要管理多会话
AMF负载 需维护多个SM Context

6.4 实际部署考量

  1. SMF部署策略:运营商可以选择"通用SMF"(一个SMF服务所有切片)或"专属SMF"(每个切片部署独立SMF),需要根据切片隔离等级决定

  2. UPF选择:SMF在为PDU Session选择UPF时,需要考虑UPF支持的S-NSSAI列表,确保数据面切片隔离

  3. NSSP策略更新:如果PCF更新了NSSP规则,已建立的PDU Session不受影响,新业务将使用更新后的策略

  4. 异常处理:如果某个切片的PDU Session建立失败,不影响其他切片的PDU Session正常工作


扫码关注「51学通信」,每天学一点5G核心网。知识星球会员享200+小时视频课程+3000+精华文章+1年专属答疑群,公众号回复"会员"了解详情。

← 返回 网络切片 实践篇