简介一份专门围绕5G核心网端到端网络切片专题的PPT课件内容覆盖网络切片概念、差异化业务需求与切片管理三大模块适合5G网络工程师、通信专业学生及相关技术人员系统学习。课件开篇梳理NGMN、5G-PPP等电信标准组织提出的开放网络架构框架明确网络切片应对移动宽带、海量物联网和任务关键性物联网三类典型场景随后讲解无线侧协议栈功能模块分离订制裁剪、核心网切片灵活定制等关键实现思路呈现出满足差异化业务的端到端闭环方案并给出切片管理的基本逻辑。压缩包内共1个pptx文件大小4.12MB页面结构紧凑、知识条理清晰可用于自学整理、课程展示或内部技术分享。目前已有1045人学习下载对希望快速建立5G网络切片整体认知、厘清切片技术脉络的读者有较好参考价值。1. 5G 端到端网络切片到底在切什么先想清楚「给谁切、在哪切、怎么验证」打开标题里这份「5G核心网关键技术-5G端到端网络切片.pptx」时别急着翻页找结论。真正值钱的不是 PPT 里的架构图而是你照着它把切片在现网或实训环境里跑通的过程。网络切片并不是把物理网线剪断而是同一个 5G 无线接入网、传输网和核心网上隔离出多张互相独立的逻辑网络每张网有自己的 AMF、SMF、UPF 和无线资源调度策略。最容易被低估的「端到端」三个字才是难点所在RAN、传输、核心网三段都在切而三段的协同全靠 S-NSSAI 这一个标识符牵着走。这篇笔记适合三类人——刚接手 5G 核心网调测的工程师、给政企客户做专网方案的售前/交付人员、以及搭 5G 实训室的讲师目标是看完能动手配出一套可验证的双切片环境而不是只记住概念。2. 把端到端切开看RAN、传输、核心网三段各自切什么、怎么协同2.1 RAN 侧S-NSSAI 如何映射到 QoS Flow 和 DRB无线侧是最容易被误读的一段。很多人以为「RAN 切片」就是给不同业务分配不同带宽实际上 RAN 做的是两件事一是把核心网下发的 S-NSSAISlice/Service Type Slice Differentiator识别出来二是把用户面的 QoS Flow 映射到无线承载DRB上再对不同类型的承载执行不同的调度优先级和资源预留策略。从协议栈角度看UE 在注册请求里带上 Requested NSSAIgNB 把这个信息透传给 AMFAMF 返回 Allowed NSSAI 后gNB 才能在后续的 RRC 重配置里给这个切片建立对应的 DRB。也就是说RAN 只负责「按切片标识做承载映射和调度」而「这个切片允不允许、对应哪个核心网实例」是核心网的决定权。这也是为什么很多实训环境里UE 明明配了 S-NSSAI 却始终不是一个切片——因为 gNB 收到的 S-NSSAI 是透传的它本身不校验真正的校验点在 AMF 和 NSSF。常见做法是给 eMBB、URLLC、mMTC 三类业务分别定义 SST1、2、3再通过 SD 区分同一种服务类型下的不同客户。SST1 的对象性大带宽业务调度策略偏向 RB 数拉满SST2 的对象性低时延业务调度策略偏向短周期调度和更高的优先级SST3 的面向海量连接允许更长的非活动定时器。你自己规划时SST 尽量沿用 3GPP 约定值SD 留给私有区分否则容易在对接其他厂家设备时出现识别冲突。2.2 传输侧FlexE、SR-TE 与 VLAN 怎么承载切片的带宽隔离传输侧切的是「管道」。核心网网元之间的 N2/N3/N4/N6 接口流量都走承载网同一个物理链路里如果只有 VLAN 隔离只能做到逻辑分隔带宽还是共享的——这就是「逻辑切片」和「硬切片」的差别。真正要保障互不抢占第一步是引入灵活以太网FlexE把物理口切成多个子接口每个子接口对应一个切片第二步是在承载网上用 SR-TE 或 FlexE 通道分别规划路径让不同切片的业务走不同转发路径。实训环境里一般不会上 FlexE 设备最常见的操作是「用 VLAN QoS 队列模拟」。核心网规划 IP 的时候把每张切片的 N3/N4 接口地址段分开gNB 到 UPF 的用户面流量打上不同 VLAN TAG然后在交换机上做优先级队列映射。这里有个容易翻车的点VLAN 划分解决的是二层逻辑隔离但如果接入交换机的端口缓存是共用的某个切片的突发流量仍可能把另一个切片的时延抬高。所以传输侧做完隔离后必须做打流验证不能只看配置界面里「已隔离」三个字。2.3 核心网侧AMF、NSSF、SMF、UPF 在一张图里的分工核心网侧才是端到端切片的主战场。AMF 是入口UE 注册时把 Requested NSSAI 带给 AMFAMF 不能自己拍板这个切片能不能用而是把请求送给 NSSF 做切片选择NSSF 根据 AMF 的 TATracking Area、签约数据、切片可用性返回 Allowed NSSAI。这段交互在 5G 协议栈里属于 NAS 层的注册流程但执行逻辑在 NSSF所以很多人查了一遍 AMF 配置也找不到问题最后发现是 NSSF 的策略没写好。SMF 和 UPF 是用户面切片的执行者。SMF 负责根据 S-NSSAI DNN 选择 UPF并把 QoS 策略下发到 UPF。UPF 则是真正转发用户数据的网元每张切片可以对应一个独立 UPF 实例也可以是同一 UPF 上的不同逻辑接口。实际部署时「切片 DNN」的组合决定了 PDU 会话落在哪个 UPF。下表是我在规划时常用的对应关系切片标识典型业务核心网实例UPF 部署位置传输保障手段SST1, SD01eMBB 大带宽独立 SMF/UPF地市边缘FlexE SR-TESST2, SD01URLLC 低时延独立 SMF/UPF园区本地专用队列SST3, SD01mMTC 海量连接共用 SMF独立 UPF省级中心VLAN 隔离这里要强调的是「端到端」三个字的代价RAN 侧的 DRB 映射、传输侧的 FlexE/队列、核心网侧的 NSSF 决策和 UPF 选择任何一段没对齐最终呈现出来的就是「核心网说切片建成了业务侧却感觉完全没变化」。所以后面第三、四、五章里我会把配置、踩坑和验证按这个三段链路展开。3. 从零配置一个 5GC 双切片环境S-NSSAI、AMF/NSSF 与 PDU 会话的最小可跑配置3.1 先定 S-NSSAI 规划SST/SD 的取值习惯动手前先定两张表否则后面改配置会改到怀疑人生。第一张是切片与业务映射表第二张是切片与核心网网元的路由表。实训环境我一般用两个切片起步eMBB 用{SST1, SD0x010001}URLLC 用{SST2, SD0x010001}。SST1/2 都是 3GPP 标准值SD 取 0x010001 作为两个切片公共的私有标识这样后续接 UE 模拟器时不用在终端侧做太多定制。规划时还要同步做的事情是核心网 IP 规划。常见做法是把 AMF 的 N2 地址、SMF 的 N4 地址、UPF 的 N3/N4 地址分别预留独立网段并且让「切片 1 的 UPF 地址」和「切片 2 的 UPF 地址」从不同子网取。原因很简单双切片调试时你需要在 UPF 侧通过 IP/TEID 快速判断某个 PDU 会话到底被分流到了哪个切片。如果两个切片的 UPF 地址段重叠或过于接近抓包定位会很痛苦。3.2 AMF 与 NSSF 配置默认切片与请求切片的取舍在开源核心网里做双切片最省事的路径是 Free5GC UERANSIM或者 OAI 5G 核心网 gNB/UE 模拟器。OAI 5G 协议栈覆盖更全但编译时间更长Free5GC 上手快切片配置逻辑清晰适合先跑通再深挖。下面是 Free5GC AMF 配置的关键片段按常见版本整理字段含义以你用的版本实际为准先看 AMF 侧的amfcfg.yamlplmnList: - mcc: 505 mnc: 01 tac: 000001 nssai: - sst: 01 sd: 010001 dnnList: - internet - eMBB - sst: 02 sd: 010001 dnnList: - urllc001这段配置的用意有两层一是告诉 AMF在这个 PLMN 和 TAC 下可以对外提供两个切片二是把切片和 DNN 绑定后续 SMF 做 PDU 会话选路时需要同时匹配 S-NSSAI 和 DNN。注意sst字段在不同版本里可能是整数也可能是十六进制字符串你配置时务必先翻一下自己那份版本的 schema否则 AMF 启动时不会报错但 NSSF 选择时永远匹配不上。接着是 NSSF 的nssfcfg.yaml它管的是「哪些切片在这个 Tracking Area 里可用」nssfConfig: - nfId: nssf-1 amfList: - amf-1 taiList: - plmnId: mcc: 505 mnc: 01 tac: 000001 sliceInfo: - sst: 01 sd: 010001 - sst: 02 sd: 010001这里最关键的是taiList如果 UE 注册时所在的 TAI 不在 NSSF 的列表里NSSF 会返回「切片不可用」AMF 就只能给 UE 分配默认切片。很多人配置了双切片但 UE 拿不到 URLLC十有八九是这里少了taiList或者 PLMN 拼写错误。NSSF 的作用是「门卫」AMF 是「前台」前台再热情门卫不放行也没用。3.3 SMF/UPF 多实例与 PDU 会话建立过程双切片要真正生效SMF 和 UPF 也得能区分会话。第一种做法是每张切片一个独立 SMF/UPF 实例隔离最彻底第二种是同一 SMF 配两个 UPF靠 S-NSSAI DNN 做分流选择。实训环境我推荐第二种省资源且排错路径短。先在 SMF 配置里定义两个 UPFupfList: - name: upf-embb host: 192.168.30.101 n4Port: 8805 dnnList: - name: eMBB sNssaiList: - sst: 01 sd: 010001 - name: upf-urllc host: 192.168.30.102 n4Port: 8805 dnnList: - name: urllc001 sNssaiList: - sst: 02 sd: 010001这样 SMF 收到 PDU 会话建立请求后会根据请求里的 S-NSSAI 和 DNN把 N4 会话建立到对应的 UPF。如果两个切片都用同一个 DNN 名SMF 就只能靠 S-NSSAI 区分如果 DNN 也不同混淆概率会大幅下降。这就是为什么我在 3.1 节里强调要把internet、eMBB、urllc001这种命名空间提前划分好。PDU 会话建立的核心流程是UE 发起 PDU Session Establishment Request携带 S-NSSAI 和 DNN→ AMF 基于注册时的 Allowed NSSAI 校验请求 → AMF 把请求转给 SMF → SMF 查 UPF 列表创建 N4 会话 → SMF 回 N1N2 Message Transfer 到 AMF → AMF 向 gNB 下发 N2 PDU Session Request 建立数据面。整个链路里任何一环的 S-NSSAI 不匹配都会导致会话建立失败。3.4 用 UE 模拟器触发注册与建会话最小启动命令UERANSIM 里改两个文件的参数就能让 UE 请求指定切片。gnb侧配置主要是 PLMN 和 TAC 要和 AMF 一致ue侧配置关键是requestedNssai# gnb.yaml 关键段 plmn: mcc: 505 mnc: 01 tac: 1 amfConfigs: - address: 192.168.20.2 port: 38412 # ue.yaml 关键段 supi: imsi-505010000000001 requestedNssai: - sst: 1 sd: 0x010001启动顺序有讲究我一般会按「核心网各网元 → gNB → UE」来。核心网里 AMF 要先起来并完成 NRF 注册SMF/UPF 才能被找到gNB 起来后要和 AMF 建立 N2 连接UE 再向 gNB 发起 RRC 和 NAS 注册。用 UERANSIM 的话播放命令通常是# 终端1启动核心网各网元按各自项目脚本 ./free5gc-amf ./free5gc-smf ./free5gc-upf # 终端2启动 gNB ./nr-gnb -c gnb.yaml # 终端3启动 UE ./nr-ue -c ue.yaml跑起来后重点看两个日志UERANSIM UE 侧出现的Registration complete表示注册成功PDU Session Establishment表示建会话成功核心网 AMF 侧出现[NAS] Registration request和S-NSSAI相关打印说明请求真的到了 5GC。如果注册成功但会话失败不要急着改核心网先回看 3.2 里的 DNN 是否配了因为 UERANSIM 默认 DNN 是internet而 URLLC 切片绑的 DNN 是urllc001不匹配时 SMF 会直接报错。4. 端到端切片落地避坑从注册到建会话的 5 个真实翻车点4.1 现象UE 一直留在默认切片自定义切片永远不生效现象就是注册流程走完了Allowed NSSAI 里只有默认切片你配置的 URLLC 像不存在一样。先别怀疑核心网代码按顺序查三处第一AMF 的plmnList.tac和 gNB 配置的tac是否完全一致TAC 不一致时 AMF 会认为该区域不支持这个切片第二NSSF 的taiList里有没有覆盖当前 TAC覆盖范围写错一个字都会让 NSSF 返回不可用第三签约数据里给 UE 订的subscribedNssai是否包含目标切片很多实训环境直接修改 UE 的 requestedNssai 就以为能绕过去但核心网侧签约数据没配AMF 会按「未签约切片」拒绝。原因层面注册流程的决策链路是UE 请求 → AMF 查 NSSF 得可用切片 → 再对照签约数据 → 算交集成 Allowed NSSAI。任何一段不匹配AMF 都不会把切片下发。解决方法是先抓 NAS 层信令从 Registration Request 里读实际请求的 S-NSSAI再从 Registration Accept 里读 Allowed NSSAI两份对比后缺哪段补哪段。不要凭印象改配置这条经验我踩了不下三次。4.2 现象PDU 会话建立失败SMF 日志报「no UPF found」或「DNN not supported」这个现象最迷惑人因为 AMF 和 gNB 都显示正常核心网日志也看不到明显异常最后发现是 SMF 的upfList里某个切片只绑了一个 DNN而 UE 发起 PDU 会话请求时携带的是另一个 DNN。比如你的 URLLC 切片绑的是urllc001但 UE 侧默认请求internetSMF 遍历 UPF 列表时发现没有 UPF 同时匹配「SST2 DNNinternet」直接拒绝。原因本质是 PDU 会话建立和切片绑定是两套评判标准同时生效只要一个不满足就失败。解决时建议先把 UERANSIM 的 UE 配置里apn有的版本叫dnn显式改成目标 DNN然后在 SMF 日志里搜 DNN 关键字确认收到的值。如果你不想让 UE 配置太绕也可以把两个切片的 UPF 都同时绑internet和专用 DNN但这样做会让后续的 UPF 选择变得不可控生产环境不建议。4.3 现象RAN 侧不识别切片gNB 报「Unsupported S-NSSAI」现象是 UE 注册成功但 RRC 重配置里没有为目标切片建立 DRBgNB 日志直接打 Unsupported S-NSSAI。很多工程师第一反应是去改核心网实际上 gNB 根本不解析切片的合法性它只是把 S-NSSAI 和 TAC 关联起来判断「这个区域是否支持」。如果你的 gNB 配置里只有默认 TAC 下的公共切片集合而 UE 在另一个 TAC 下发起 URLLC 请求gNB 就会报不支持。原因在 RAN 侧的切片可用性列表没有和核心网对齐。解决方法是把 gNB 的tac、plmn与 AMF/NSSF 完全对齐并确认 gNB 侧是否配置了切片到调度策略的映射。RAN 真正能做的隔离是「给不同切片配置不同 5QI 的调度权重」所以建议同时给 URLLC 切片在 gNB 侧绑定一个低时延的 5QI比如 5QI82/83而不是让所有切片共享默认 5QI。4.4 现象核心网和 UE 模拟器信令不一致SST 值一个显示 1 一个显示 01这个坑小但极其常见。不同开源版本对 S-NSSAI 的编码处理并不统一有的配置文件里sst: 1表示十进制 1有的sst: 01表示十六进制 0x01还有的在信令抓包里显示为SST1, SD0x010001。如果你 AMF 配的是sst: 01UE 侧配的是sst: 1两者可能都能被解析但 NSSF 在做精确匹配时会出现「看着一样实际不同」的诡异问题。解决方法是统一约定配置文件全部写成同一个进制风格核心网与 UE 模拟器保持一致抓包确认时不看字符串看 Wireshark 里解码后的实际数值。另一个相关坑是 SD 字段如果 SD 为全 0有的协议栈实现认为「没有 SD」有的则认为「SD0x000000」两者在底层判等时结果不同。规避方式就是别用全 0 SD给它一个明确的非零值。4.5 现象两个切片都建好了但业务流量互相抢占URLLC 时延并不低这个现象说明你只做了「逻辑切片」没做「资源切片」。核心网侧切片建好只代表两张网络拓扑是分开的但如果 RAN 侧调度权重一样、传输侧 VLAN 优先级没配、UPF 的处理资源共享URLLC 切片的低时延根本保障不了。最典型的情况是用 iperf 给 eMBB 切片灌满带宽再 ping URLLC 切片的地址时延从 2ms 涨到 20ms。原因涉及三层RAN 调度默认还是 QCI 对应的公平调度传输交换机队列默认按普通 IP 优先级核心网侧 CPU/网卡没有做 CPU 绑核和中断分离。解决思路是逐步收拢先在 RAN 给 URLLC 配 5QI82 并调高调度优先级然后在传输交换机上给这两个 VLAN 分别打严格优先级队列最后在 UPF 侧给 URLLC 所在的进程做网卡多队列绑定。到这一步能做到什么程度取决于设备能力和预算评估方案时要向客户把「逻辑隔离可以做到认证、业务、计费全分离但物理隔离才算硬切片」这个边界讲明白。5. 切片做没做成怎么验证从信令抓包到业务时延的一整套检查清单5.1 注册流程里抓 NSSAI信令面的关键信息在哪看验证切片的第一步永远是看信令而不是看业务。拿 tcpdump 在 AMF 和 gNB 之间的 N2 口抓包或者直接在 UE 模拟器日志里看 NAS 消息。注册请求和响应里的三个字段你要盯住Registration Request 里的 Requested NSSAIRegistration Accept 里的 Allowed NSSAI以及如果有额外条件时的 Configured NSSAI。Allowed NSSAI 是最终裁决它的内容直接决定后续 PDU 会话能不能带这个切片。用 tshark 过滤 NGAP 层的 S-NSSAI 字段时命令大致是这样tshark -r register.pcap -Y ngap -T fields \ -e ngap.messageType \ -e ngap.s_NSSAI.sST \ -e ngap.s_NSSAI.sD \ -e ngap.allowed_NSSAI不同 Wireshark 版本对 NGAP 字段的命名可能不同但思路一致先解出每条 NGAP 消息里带的 S-NSSAI再人工核对请求和接受的对应关系。如果请求里是 SST2、SD0x010001接受里变成 SST2、SD0x000000说明核心网把 SD 丢掉了或转换出错这时候要去查 NSSF 的 sliceInfo 配置而不是查 gNB。5.2 UPF 流表与会话建立验证确认 PDU 会话落在了正确的切片上信令面没问题不代表数据面没问题。PDU 会话建立成功后UPF 上会多一条 N4 会话对应的转发规则。在 Free5GC 里可以用free5gc-upf配套的 CLI 查询OAI 5G 里则直接看spgwu日志中的 F-TEID 与 PDR/FAR 信息。验证要点有三个看 UL F-TEID 和 DL F-TEID 是否与 gNB 侧一致看 S-NSSAI 是否被正确关联到了这条转发规则看 QoS 参数比如 MBR/GBR是不是你规划的值。如果两个切片分别跑在两个 UPF 上验证就更清楚了互相对端发一个 PDU ping然后在两个 UPF 的日志里分别看有没有流量经过。如果发现两个切片的流量都走同一个 UPF但你配置了两个 UPF多半是 SMF 的upfList绑定关系没生效或者是 AMF 选 SMF 时用的 discover 条件没写 S-NSSAI。5.3 业务面打流验证ping、iperf 与峰值速率的粗略换算业务面验证的常规组合是「ping 测时延抖动 iperf 测吞吐」。ping 要统计的不是平均时延而是最大时延和抖动这两个值对 URLLC 切片才是决定性的。iperf 测试建议区分上行和下行因为 RAN 侧上下行调度器行为不同gNB 给上行分配的 RB 数往往受 UE 能力限制。用 iperf3 打流时一个常用的命令组合是# UPF 侧作为服务端 iperf3 -s -p 5201 # UE 侧作为客户端测上行吞吐10 秒并发 4 流 iperf3 -c 192.168.30.101 -p 5201 -u -b 100M -t 10 -P 4打流的同时在传输侧交换机或 UPF 网卡上抓包确认不同切片的流量确实打在期望的 VLAN/队列上。顺带提一下「5G 峰值速率计算公式」在方案里的正确用法峰值速率Mbps约等于有效带宽MHz乘以频谱效率bps/Hz再乘以一个小于 1 的开关损耗系数实际计算要考虑调制阶数、层数、PDCP/RLC 开销等因素所以别拿理论峰值去向客户承诺。做切片带宽规划时我会先把单用户需求峰值、99% 保障速率和缓存型业务平均速率分开列出来再按「峰值速率换算带宽需求 预留 20% 弹性」来定每张切片的 FlexE 子接口带宽。5.4 双切片对比验证同一终端在两个切片间的切换路径实训环境里最有说服力的一套验证流程是用 UERANSIM 启动两个 UE 实例一个请求 SST1一个请求 SST2让它们同时在同一个 gNB 下完成注册和 PDU 会话建立然后做三轮测试。第一轮先对两个切片分别 ping 对端确认时延基线第二轮用 iperf 灌满 eMBB 切片再测 URLLC 切片的 ping 抖动观察是否从个位数毫秒级恶化到数十毫秒第三轮把传输交换机的队列优先级改掉对比 URLLC 切片的恶化程度。这个过程能一次性暴露 RAN 调度、传输队列、核心网分流三段里的短板。验证完成后把每轮的时延、抖动、吞吐记成一张对账单比任何 PPT 都更能说服客户这个切片方案是「端到端」可用的。顺便说一句如果发现改完 RAN 调度参数后 URLLC 时延没有改善先复查 5QI 有没有真正下达到 gNB很多开源 gNB 对核心网下发的 QoS 参数只解析不执行这个黑匣子只能靠打流数据去戳穿。6. 一个进阶技巧单机跑双切片实训时我坚持的验证习惯实训和现网最大的差别是资源有限。我经常需要在一台物理服务器上把 5GC、gNB、UE 全部跑完还要模拟出双切片隔离的效果。常见做法是一套核心网跑两个 UE 模拟器每张 SIM 卡也就是 UERANSIM 的配置文件请求不同 S-NSSAI核心网里配两个 SMF/UPF 上下文表面上已经「双切片」了。但我会额外加一个动作在两个 UE 的 PDU 会话都建立成功后强制修改其中一个切片对应的 UPF 网卡上的流量限速然后观察另一个切片是否受影响。这个动作能快速检验你是不是只做了「名词切片」没做「资源切片」。还有一个从失败里沉淀下来的习惯改完任何配置后第一步永远不是重新启动 UE 让注册流程走一遍然后盯着看霞 — 而是先翻 UE 侧日志里的 Registration Request确认它实际带出去的 S-NSSAI 和我预期一致。因为很多时候你以为改的是 UE 配置实际上改的是核心网另一份配置文件UE 侧依旧带着旧参数在跑。注册请求里带错切片后面所有信令和业务验证都是空转只会把时间浪费在一堆无关日志里。记住这一点你的切片调试效率会提升非常明显。希望我的这些踩坑和验证习惯能帮你在自己的 5G 端到端网络切片方案里少走几次弯路。本文还有配套的精品资源点击获取
