5G核心网端到端切片配置实战：S-NSSAI、隔离与QoS详解

简介：5G核心网关键技术网络切片是面向5G差异化场景的核心内容。这份PPT课件系统讲解5G端到端网络切片，涵盖移动宽带、海量物联网与任务关键性物联网三大场景，重点阐述网络切片的概念、协议栈功能模块的分离订制与裁剪，以及核心网切片灵活定制的实现方式，并完整介绍网络切片的管理机制。内容适用于通信工程专业学生、5G网络规划工程师及技术培训人员学习参考。资源包为1个pptx文件，大小4.12MB，已获得1045人浏览学习。课件以图文形式组织，从背景需求到架构设计再到管理实践，层次分明。通过本课件，读者可以快速建立5G网络切片的整体认知，理解差异化业务对切片架构的驱动作用，掌握协议栈分段定制、核心网灵活部署等关键技术要点，为进一步研究5G核心网独立组网与行业应用打下基础。

1. 5G端到端网络切片：一张物理网真的能切成多个“专用网”吗

在5G的所有宣传语里，端到端网络切片是最容易被当成PPT概念的那一个。毕竟一张物理网络要同时跑手机上网、工业控制和视频监控，听起来像各给各的专用通道，底层却还是同一批基站和光纤。但真正把5G核心网的关键切片技术配置到位之后，它确实能在共享物理网络之上隔离出逻辑专用网络，时延、带宽、可靠性都能按需分配。这篇笔记不讲营销话术，把核心网切片关键技术拆开讲清：S-NSSAI和NSSAI怎么规划、AMF/SMF/UPF在切片里各管哪一段、端到端切片从RAN到传输再到核心网怎么打通，以及实施时的高频坑位。适合正在做5G核心网验证、准备切片商用落地或刚接手切片业务的工程师，读完能直接动手。

2. 切片的第一性原理：S-NSSAI、NSSAI与核心网网元怎么分工

2.1 S-NSSAI里的SST和SD到底在表达什么

所有切片操作的起点，是S-NSSAI（Single Network Slice Selection Assistance Information，单个网络切片选择辅助信息）。它由两个字段组成：SST是8位，SD是24位可选字段。SST决定切片类型，标准里定义了1到4这四个常用值，分别对应eMBB、URLLC、mMTC和V2X；运营商想自己定义类型，一般从128开始取值。SD字段则是为了在同一类型下区分不同业务，比如都是eMBB，一个给普通手机上网，一个给企业视频专线，就靠SD区分。

把常用取值整理成表格方便查：

配置S-NSSAI时最容易踩坑的是对SST和SD的理解偏差。SST决定切片“性格”，SD只是“编号”，网络侧做切片选择时要把SST加SD作为一个完整匹配键来用。很多早期设备实现只按SST匹配，导致两个SD不同的切片被路由到同一个实例，流量互相干扰。我的习惯是每个业务切片至少分配一个独立SD，并保证全网统一命名规范，别让SD的值在不同省网里含义不同，这个规划失误后面很难改。

S-NSSAI不会凭空出现。它要么预配置在USIM卡的签约数据里，要么在网络侧由UDM在注册流程中下发。终端发起注册时，携带的是“请求的NSSAI”（Requested NSSAI），网络结合签约数据、运营商策略和接入网支持能力处理后，回复“允许的NSSAI”（Allowed NSSAI）。终端只有在Allowed NSSAI里看到某个S-NSSAI，才有权利发起对应切片的PDU会话。也就是说，终端想用哪个切片，得先过网络这关，自己在手机上填一个S-NSSAI并不会让它生效。

2.2 从终端注册到切片选择：AMF、NSSF、SMF分别干了什么

终端发起注册请求后，AMF（接入与移动性管理功能）是第一个接触切片的网元。AMF收到Requested NSSAI后，先查UDM里的签约数据，看终端订阅了哪些S-NSSAI；如果AMF自己就能处理，就直接继续，否则需要调用NSSF（网络切片选择功能）做一次切片选择。NSSF根据请求的S-NSSAI、签约数据、AMF能力、运营商策略，返回一个目标AMF集合，并且可能附带允许的NSSAI。

会话建立阶段的主角换成SMF。终端发起PDU会话建立请求，消息里同时带上S-NSSAI和DNN；AMF根据这两个参数选定一个SMF。这个选择不是随机的，因为不同切片实例往往关联不同的SMF/UPF集合。SMF被选中后，再根据S-NSSAI、DNN、业务要求和用户位置，决定使用哪个UPF。到这里，一个切片相关的数据通路才算真正建立起来。

整条链路可以这么理解：AMF管“人在哪”，NSSF管“选哪套控制面”，SMF管“会话怎么建”，UPF管“数据往哪走”。四类网元缺一个，切片都跑不透。实操中，很多问题不出在配置本身，而是出在AMF加载的切片策略和NSSF里的选择规则不一致，导致同一个S-NSSAI在两个网元里落到了不同的实例上。排查这类问题的时候，我一般先拉通AMF、NSSF、SMF三份配置，对比S-NSSAI和DNN的映射表，再去做信令跟踪，这样比盲目看日志高效得多。

提示：注册阶段的Allowed NSSAI只代表“你有权用”，不代表“数据这条路一定通”。真正验证切片，要看PDU会话建立。

2.3 切片隔离的两个级别：共享网元与独立网元怎么选

切片之间靠什么真正隔离，决定了这套方案的可用性边界。最常见的做法分两类：一类是软隔离，所有切片共享AMF、SMF和UPF，只靠QoS参数和调度策略区分，部署成本低，验证阶段够用，但业务流量一忙就容易互相干扰；另一类是硬隔离，控制面或用户面网元按切片独立部署，比如URLLC用专属SMF和UPF，eMBB走共享网元，故障域和性能边界清晰，代价是资源利用率下降。多数商用网络取中间路径，控制面共享、用户面独立。

选型判断标准我一般看三条：业务时延要求、故障域要求、投资预算。URLLC类业务至少做到半隔离；只为展示切片概念的Demo，软隔离就足够了，没必要一开始就上独立网元。但要记住，软隔离不代表“随意”，QoS参数配不好，切片内互相拖累的情况照样会发生，这不是玄学，是调度器在物理资源有限时做出的实际选择。

3. 端到端切片的配置路径：从RAN到传输再到核心网

3.1 RAN侧切片配置：gNB怎么识别并调度不同切片

端到端切片的第一步，是让无线接入网“认识”切片。gNB通过SIB1广播本小区支持的S-NSSAI列表，终端在小区里发起业务时，网络会结合终端的Allowed NSSAI和小区支持列表，决定是否允许接入。如果小区没广播某个S-NSSAI，即使核心网配置得再好，终端在这个小区也建立不了对应切片会话，这是排查时最先要看的一层。

RAN侧真正难的不是识别，而是调度。同一个gNB下，普通eMBB用户和URLLC切片用户共享无线资源，如果不做区分，大流量用户会把资源吃满，URLLC时延立刻劣化。实际操作上，需要配置切片级别的RRM策略，常见做法是把URLLC切片设为更高的调度优先级，或者直接划拨一部分专用PRB给该切片，让URLLC流量走独立资源池。

配置顺序一般是：先给小区加上支持切片的列表，再创建切片对应的无线资源策略，最后配置业务与切片的映射关系。大多数商用gNB的配置页里都有这几个字段：S-NSSAI（SST+SD）、调度优先级、上下行最大速率、专用PRB比例。我见过不少人只配了“支持列表”就宣布切片通了，结果一发大流量就把整片区域打瘫，就是漏了调度策略这一步。RAN侧切片的验证也不能只看RRC连接能否建立，要看空口调度时URLLC用户是否真的拿到优先资源。

3.2 核心网侧切片实例化：从NSST到NSI的落地

核心网侧的切片实现，标准里用两层概念描述：NSST（网络切片模板）描述一个切片应该包含哪些网络功能、参数策略和拓扑信息；NSI（网络切片实例）则是这个模板的活体实例。实际部署时，不会每次从头搭一套新网元，而是在已有基础设施上编排出逻辑实例。常见流程是先创建切片模板（NSST），再根据模板创建切片实例（NSI），绑定DNN和用户面网元，配置切片级策略，最后激活。

下面是一个切片模板的示意配置，字段含义写在注释里：

slice_template: name: "eMBB-Standard-V1" # 模板名称，后续实例化时引用 s_nssai: # 切片标识 sst: 1 # 业务类型：eMBB sd: "000001" # 业务区分符：普通互联网 nf_components: # 网元组成 control_plane: amf: shared # 控制面AMF采用共享，降低部署成本 smf: dedicated # SMF独立，便于按切片控制会话策略 user_plane: upf: dedicated # 用户面UPF独立，保证数据面隔离 session_config: dnn_list: ["internet", "enterprise-01"] # 允许该切片绑定的DNN qos_default: 5qi: 9 # 默认QoS等级，可被会话级覆盖 arp_priority: 6 # 资源保持优先级，越小优先级越高

这个模板表达的是“半隔离”方案：AMF共享、SMF和UPF独立。如果你做的是纯软隔离，把smf和upf都改成shared即可。模板里的dnn_list很关键，它限定了这个切片能承载哪些数据网络。如果切片绑定了错误的DNN，终端会话会建立失败。

实例化NSI时，核心网编排器会照模板拉起逻辑网元，并完成配置分发。创建后通常是先“激活”再“商用”，激活动作会触发NF之间的接口连通性检查和routing table下发。这一步做完，核心网侧的切片才真正进入可用状态。要注意的是，不同厂商的编排器API差异很大，但逻辑都遵循“模板-实例-激活”三段式，按这个思路去读厂商文档会顺畅很多。

3.3 传输侧怎么配合：QoS Flow与FlexE/VLAN资源映射

RAN和核心网都配好了还不够，中间传输网也要为切片让路。常见两种方案：基于VLAN/VxLAN的软隔离，以及基于FlexE的硬隔离。软隔离适合对时延不敏感的业务，在传输设备上配置不同优先级队列；硬隔离则是物理通道级别的隔离，适合URLLC这类高价值场景。把核心网QoS Flow的优先级映射到传输隧道优先级，是端到端保障的关键一步。

配置时，需要建立一张“S-NSSAI-核心网QFI-传输隧道优先级”的映射表，而且这张表要在RAN、核心网、传输三边保持一致。很多团队做切片Demo时，RAN和核心网都调通了，最后一测时延不稳定，查下来是传输设备上走了默认队列，切片的优先级标签在中间被重置了。传输侧不像RAN和核心网那些网元有专门的切片管理机构，全靠转发策略来体现，这部分最容易变成黑匣子。

注意：端到端切片不是一个网元的功能，而是一条链路的协同。任何一段没有按S-NSSAI做策略映射，整条切片链路就名存实亡。

4. 切片生命周期与关键参数配置：从模板到落地

4.1 切片模板设计：SST/SD取值规范与命名习惯

在核心网开始创建切片之前，先要做的是规划SST和SD的取值方案，这决定了以后扩容的灵活性。一个稳妥的做法是：SST按业务大类固定，SD按“地区+业务子类”编排，比如0x010001代表华东eMBB普通业务，0x010002代表华东eMBB视频专线。地区和业务子类各占12位，给未来留足空间。

模板设计上，不要一开始就把所有NF都塞进一个模板。我的习惯是拆分轻量级模板：控制面共享模板、用户面独立模板、完整隔离模板各做一套。demo阶段用轻量级，商用阶段把用户面升级成独立UPF模板，改动最小。千万别把AMF池、SMF池、UPF拓扑全写死在一个模板里，后面调整任何一个网元都要整体重建，这是个明显的后悔药问题。

命名规范也最好统一。模板名用业务类型-子类-版本，实例名用模板名-序号或业务线-区域。我见过有团队直接用自己的名字或日期做实例名，到了运维排障阶段，连哪个切片对应哪条业务线都要猜，浪费大量时间。

4.2 QoS参数映射：5QI、ARP与GFBR/MFBR怎么配

QoS是切片的第二根支柱。5QI决定了数据包在空口和核心网处理时的调度优先级、时延和丢包目标。常用值整理如下：

表格里的优先级数字越小，在调度器里权重越高。GBR类型的5QI意味着网络需要为这个承载预留资源，配套的ARP（Allocation and Retention Priority）则决定资源紧张时谁能抢占谁。

配置时有几个教训值得记下。GBR业务一定要配套GFBR（保证速率）和MFBR（最大速率），只在GBR标志位打勾但GFBR不填，调度器会按默认值执行，效果和Non-GBR没有区别。MFBR不要设得过高，否则一个切片的高峰速率会吸干共享UPF的带宽，其他切片全部劣化。ARP的取值更敏感，把某个切片的ARP调到1（最高优先级）之后，一旦资源拥塞，它会抢掉普通用户的所有资源，导致普通业务完全不可用。

4.3 切片实例的创建、激活与去激活操作流程

创建一套切片实例，常见的做法是通过核心网编排器或统一网管界面操作，也可以用管理API脚本化。下面是一个通过API创建和激活切片实例的示意：

import requests import json # 第一步：创建切片实例（NSI） payload = { "template_id": "eMBB-Standard-V1", # 引用第3.2节的模板 "instance_name": "Slice-Demo-eMBB-01", # 实例名，建议含业务线和序号 "s_nssai": {"sst": 1, "sd": "000001"}, # S-NSSAI必须存在且已规划 "dnn_list": ["internet", "enterprise-01"], # 绑定DNN，数量不宜过多 "qos": {"5qi": 9, "arp_priority": 6} # 默认QoS，会话级可覆盖 } resp = requests.post("http://<编排器地址>/api/slicing/v1/ns-instances", json=payload, timeout=10) print(resp.status_code, resp.json()) # 第二步：激活实例 resp = requests.post( "http://<编排器地址>/api/slicing/v1/ns-instances/Slice-Demo-eMBB-01/activate", timeout=30 ) print(resp.status_code, resp.json())

这个脚本里，template_id决定了实例的网元拓扑和隔离级别；s_nssai是网络侧唯一匹配键，一旦创建后要改SD，几乎等于删除重建；qos里的5qi和arp_priority是实例默认值，终端会话建立时如果没带专门的QoS参数，就用这个默认档。

激活操作常常触发网元间的接口绑定和路由下发，耗时比创建长很多，所以超时时间要放宽。去激活则是反操作，我一般在业务割接或资源回收时才做，平时尽量不频繁开关，因为每次激活都会让已建立会话的用户短暂中断，这个影响比大部分人预想的大。

5. 5G切片实施避坑：4个高发问题排查记录

5.1 终端注册成功却用不上切片：NSSAI对不上

现象：终端5G注册成功，信令里能看到Allowed NSSAI，但发起业务时PDU会话建立失败，或者数据一直走默认承载，流量根本没进目标切片。

原因：最常见的是三层NSSAI对不上。第一层，USIM卡里预配置的NSSAI和UDM里的签约NSSAI不一致，终端请求了网络里不存在的切片；第二层，AMF或NSSF里配置的Allowed NSSAI不包含目标S-NSSAI，网络直接拒绝；第三层，RAN侧小区SIB1广播的支持切片列表里没有这个S-NSSAI，终端在小区里根本没有接入资格。

解决：按三层顺序排查。先看终端注册请求里的Requested NSSAI和UDM返回的Subscribed NSSAI是否匹配；再查AMF/NSSF的策略配置，确认Allowed NSSAI已下发给终端；最后查小区配置里是否把S-NSSAI加入了支持列表并已广播。我在现场处理过一个项目X的问题，三层都查了，最后发现是SD写错了一个字节——终端请求的是000001，UDM签约的是000002，肉眼几乎看不出来，只能靠信令逐字段比对。

5.2 两个切片互相抢资源：隔离设置不到位

现象：切片的业务跑得正常，但同一个小区或同一个UPF下，eMBB业务流量一上来，URLLC业务的时延从5ms直接飙到30ms，可用性跌破阈值。

原因：隔离级别不够或者QoS策略没生效。常见的是RAN侧没配切片级调度，URLLC和eMBB在同一个PRB池里竞争；或者核心网侧切片的UPF是共享的，但UPF上没有按切片做队列隔离，大流量业务把转发资源占满了。

解决：RAN侧给URLLC切片配置专用PRB或更高的调度优先级，字段一般在gNB的切片配置页里叫slice schedule weight或dedicated PRB ratio；核心网侧给URLLC切片拆分独立UPF实例，至少也要在UPF上按S-NSSAI绑定独立队列。配置完一定要打流量验证，让eMBB先满载再测URLLC时延，这才是真实场景。

5.3 切片内时延忽高忽低：UPF部署位置和路由绕行

现象：同一切片、同一终端的时延测试结果波动很大，时而10ms，时而50ms，且规律性不强。

原因：第一种是UPF部署位置离基站太远，数据要绕到核心网机房再回来，距离导致的时延波动是物理性的；第二种是传输网络的路由策略没配合，部分数据走了绕行链路；第三种是UPF负载不均衡，业务被分发到了处于高负载的实例上。

解决：先看UPF的实际位置和基站传输拓扑，确认数据面路径是不是最优；再检查ULCL（上行分类器）是否部署在RAN侧，能不能在本地就把业务分流到目标切片，避免全部上行到中心UPF。测试时最好固定一台终端、固定同一个小区，连续测多轮取分位数，不要只看平均值。

注意：时延问题别一上来就调QoS参数，先确认UPF的位置和路由路径，这两者是最常见的“假故障”来源。

5.4 切片扩容不生效：会话保持与重选机制

现象：新建了同类型切片实例以提升容量，但老用户始终不往新实例上跑，新实例负载很低，旧实例被打满。

原因：终端注册和会话建立后，控制面会保持当前的AMF/SMF绑定。新建的切片实例不会中断存量会话，也不会主动把老用户迁移过去；如果AMF缓存里的切片选择结果没有失效，新用户也可能被继续路由到旧实例。

解决：这是切片编排里最容易被忽视的环节。扩容不是“建好就行”，需要把新实例纳入NSSF的可用AMF集合或SMF集合，让新用户有机会被选上；存量用户要触发重新注册或重建PDU会话，才可能迁移到新实例。实操中，我会在流量低峰期对指定用户做一次去注册再注册，或者通过核心网OAM触发会话释放，验证新实例是否能承接业务。

6. 切片端到端验证：从能通到达标的测试清单

6.1 怎么证明切片真正端到端打通

最直接的方式是抓信令。用支持切片的测试终端配合信令分析工具，观察注册请求中的Requested NSSAI、注册接受中的Allowed NSSAI，以及PDU会话建立请求里的S-NSSAI和DNN。看到这三者都指向目标切片，再验证数据面：确认用户面IP地址落在目标UPF的网段里，并在UPF侧查看会话绑定记录。

如果没有专业终端，也可以用标准手机的工程模式查看当前使用的切片信息，部分系统支持显示S-NSSAI。不过工程模式看不到UPF归属，所以我还是建议至少准备一台能导出信令日志的测试终端，这是验证端到端切片的必要装备。

6.2 性能验收的三个维度与参数建议

切片不能只验证“能通”，还要验证“够用”。我习惯按三个维度验收，用一张表把工具和目标值固定下来：

一个必须养成的习惯是：满载验证。空载时每个切片都表现完美，一加负载就原形毕露。我在第一次做切片验收时，只看了空载时延，结果忙时被直接打脸。后来我把eMBB大流量打满，再测URLLC切片时延，两个切片的真实差距才浮现出来。希望这个习惯能帮到你，切片的性能边界，要从满载那一刻才开始算。

本文还有配套的精品资源，点击获取