本测试的具体场景是:
-
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。可通过以下方式验证:
检查点2:UE正确使用NSSP选择S-NSSAI
验证UE在PDU Session Establishment消息中携带的S-NSSAI与NSSP规则一致:
检查点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网络切片的并发多切片接入能力,核心流程要点:
-
NSSP策略驱动:UE根据PCF下发的NSSP规则,为不同DNN选择对应的S-NSSAI
-
Allowed NSSAI验证:UE在发起PDU Session前必须确认S-NSSAI在Allowed NSSAI中
-
NRF切片感知发现:AMF通过NRF的S-NSSAI+DNN参数精确发现支持特定切片的SMF
-
签约数据校验:SMF从UDM获取签约数据,验证UE请求的S-NSSAI确实已签约
-
端到端隔离:两个PDU Session可以使用不同的SMF/UPF,实现切片级资源隔离
6.2 同类型切片的含义
本篇标题中的"同类型网络切片"指的是:两个S-NSSAI虽然在SST和SD值上不同((2,1)和(9,1)),但它们都是标准切片类型,使用相同的PDU Session建立流程。它们之间的差异体现在:
6.3 与单切片接入的对比
| 维度 |
单切片接入 |
多切片并发接入 |
| PDU Session数 |
1 |
N |
| SMF |
1个 |
1~N个 |
| UPF |
1个 |
1~N个 |
| NSSP策略 |
简单 |
多规则匹配 |
| UE复杂度 |
低 |
需要管理多会话 |
| AMF负载 |
低 |
需维护多个SM Context |
6.4 实际部署考量
-
SMF部署策略:运营商可以选择"通用SMF"(一个SMF服务所有切片)或"专属SMF"(每个切片部署独立SMF),需要根据切片隔离等级决定
-
UPF选择:SMF在为PDU Session选择UPF时,需要考虑UPF支持的S-NSSAI列表,确保数据面切片隔离
-
NSSP策略更新:如果PCF更新了NSSP规则,已建立的PDU Session不受影响,新业务将使用更新后的策略
-
异常处理:如果某个切片的PDU Session建立失败,不影响其他切片的PDU Session正常工作
扫码关注「51学通信」,每天学一点5G核心网。知识星球会员享200+小时视频课程+3000+精华文章+1年专属答疑群,公众号回复"会员"了解详情。