简介一份聚焦5G网络切片技术的教学演示文稿依据移动全网规划与建设课程体系整理适合网络规划工程师、通信专业学生及5G技术爱好者系统学习。内容从传统电信网络的刚性、封闭、垂直分割等痛点切入梳理5G时代对灵活性、扩展性和资源效率的新需求随后详解eMBB、mMTC、uRLLC三大应用场景对网络的不同要求以及将物理网络分解为多个定制化逻辑切片的核心思路。实现层面重点讲解NFV、SDN、SBA等关键技术并逐一说明CSMF、NSMF、NSSMF、SLA、MANO、NFVI等管理与编排组件覆盖从切片设计到运营的整体流程。资源为单个pptx文件大小3.11MB幻灯片包含目录层级、无线/承载/核心网切片图示与思考题结构清晰便于课堂展示与自学复盘。已有103人学习适合作为5G切片技术入门与全网规划进阶的实用参考。1. 5G网络切片到底切什么一段业务一条硬管道一条物理5G网络里同时跑着数控机床的控制指令、无人车的调度数据和车间的视频监控三张网互不干扰——这正是5G网络切片技术落地后的样子也是移动全网规划与建设里最容易从“概念演示”变成“交付验收”的部分。切片不是用VLAN把IP网络划几段而是一条从终端、无线、承载到核心网全链路隔离的逻辑网络时延敏感的走低时延通道带宽密集的走大带宽通道相互之间不做资源竞争。适合谁看地市网络规划、专网方案设计、5G行业项目交付的工程师。网管平台上把S-NSSAI、DNN、URSP、UPF这一串参数打通之前你得先理解三域协同这件事。2. 切片背后的三域架构全网规划先画一张跨域总图2.1 端到端切片是一条三段拼装管道RAN、承载、核心网各切各的5G网络切片之所以容易让人误解是因为它不是一个“网元功能”而是一条跨域的组合管道。网管上看到的无线侧切片、承载侧切片、核心网切片其实是三个相对独立的工程域各自建好之后再用标识串起来才能形成端到端效果。任何一个域没打通用户体验都会掉回“普通公网”或者直接注册失败。RAN侧做的事情是在基站调度器上把空口资源切成资源池给不同切片分配不同的RB预留比例和调度优先级承载侧做的事情是在SPN或IP-RAN网络上为指定切片建专用隧道或FlexE硬管道避免传输拥塞互相干扰核心网侧做的事情是由AMF根据终端请求的S-NSSAI决定接受哪些切片SMF根据S-NSSAI和DNN选择对应的UPF用户在UPF上完成真正的数据转发。终端侧也有一层叫URSP它决定了手机里的哪个应用走哪条切片。我一般会先让团队把“三段切完再串”的图画出来再进入配置阶段。全网规划阶段我会专门维护一张跨域对标表切片A在三域分别叫什么标识、落在哪些网元、对应哪些策略。这张表就是后面所有工单的源头。实际项目里最常见的规划失误就是把切片当成核心网功能核心网侧配置了SMF就认为切片已经开通结果无线侧没绑5QI、承载侧没建隧道业务跑起来时延高得离谱。2.2 S-NSSAI、SD与DNN全网切片标识怎么起名才不后悔切片标识的规划是整个项目里最“后悔药”属性最强的环节。S-NSSAI由SST和SD两部分组成SST是标准化的切片类型行业规范里定义了eMBB、URLLC、mMTC等大类SD是24比特的自定义字段通常用十六进制表示留给你自己定义。这里有个实际经验SST严格按业务类型选同一类业务全网统一不要按客户去改SSTSD则按“业务子类-客户编码-地市编码”的规则来编码保证全网唯一、可解读、可批量替换。很多团队图省事SD直接编成“001”“002”后期排查时根本看不出这个切片是哪个客户、哪种业务只能挨个网元翻配置。我见过某次项目里两个地市给同一个客户规划了不同的SD结果终端漫游过去直接注册失败查了两天才定位到是标识不统一。DNN和S-NSSAI是多对多的关系一个切片可以挂多个DNN一个DNN也可以被多个切片使用但落地时我倾向一个客户一个DNN、一个切片组包含控制面和数据面两个PDU会话这样URSP分流规则简单核心网上SMF选路也容易排查。业务类型SSTSD示例DNN示例终端类型建议切片属性低时延控制2URLLC0x000001ctrl.factory控制终端开PDCP复制高调度优先级AGV调度2URLLC0x000002agv.factoryAGV车辆RB预留预调度视频监控1eMBB0x010001video.factory摄像头大带宽默认调度办公上网1eMBB0x010002office手机默认切片不预留这张表示意的是规划思路真正做全网规划时SD字段还要加入地市或区域维度避免跨地市漫游时标识冲突。命名规范一旦定下来后面所有网元配置、拨测验证、投诉定位都拿它当索引。2.3 带宽与时延预算全网规划先算账再开配切片规划不能上来就配参数得先算预算。端到端时延的构成是UE处理时延 空口时延 承载网时延 核心网处理时延 应用服务器处理时延。低时延业务比如运动控制通常要求端到端不超过10到20毫秒预算分配一般是这样空口留5毫秒以内承载网留2毫秒以内核心网处理留2毫秒以内剩下的留给UE和应用侧。如果UPF下沉到园区机房核心网处理这一段可以从几毫秒降到亚毫秒级整个时延预算会宽裕很多。带宽预算我一般这么算单小区切片可用容量 单用户保证速率 × 最大并发用户数 ÷ 资源预留比例。注意切片隔离不是“平均分配总带宽”而是“按峰值预算预留资源”。常见误算是拿“总带宽除以用户数”得出每用户速率这在普通公网可以在切片专网里不行因为同一切片内用户可能同时发起高负载业务峰值会互相踩踏。我习惯再留出20%到30%的冗余视频流这类突发业务冗余还要更多。带宽和时延预算确定后才算真正具备了开配的条件。很多项目交付后频繁投诉“时延不稳定”回头看基本都是预算阶段没有算并发率和冗余量资源池预留比例拍脑袋填的。3. 无线侧切片建设从小区级开关到URLLC参数组3.1 无线侧至少要打开的三层开关版本支持、切片组、5QI绑定无线侧切片建设不同设备商的实现有一些差异但底层逻辑是一致的让基站识别S-NSSAI把它映射到无线切片组再为切片组划分资源池和调度策略。第一步不是配参数而是确认设备版本和功能License是否支持无线切片。这个步骤最容易翻车——版本不支持时参数界面上可能都看不到相关菜单或者配置后不生效没有任何报错提示。确认支持后操作顺序很关键先在无线网管上创建切片组把S-NSSAI和资源池预留比例绑定再把5QI映射到对应切片组最后打开小区级切片开关。顺序反了会出现“切片组建好了但5QI绑定不上”的怪问题有些网管平台的前后依赖关系很强数据模型必须先建父对象再建子对象。操作步骤大致是这样导出并核对基站版本支持矩阵确认无线切片功能已授权创建无线切片组配置RB资源池预留比例、调度优先级把业务对应的5QI绑定到切片组并指定PDCP复制、预调度等增强参数打开小区级切片开关把指定小区加入切片组的覆盖范围通过终端工程模式或路测软件确认UE上报的S-NSSAI与小区切片组匹配。这里有个容易被忽略的细节切片组和物理小区是“多对多”关系一个小区的总预留比例不能超过100%多个切片组同时覆盖同一小区时必须把RB预留比例加起来看总量。我见过一个站点上同时开了低时延、视频、公网三个切片组预留比例加起来到了85%普通用户几乎没资源可用用户感知直接崩了。3.2 5QI要选对URLLC不是把QCI改成1就完事5QI是5G里标识QoS等级的编号很多4G时代过来的工程师习惯把它叫QCI概念类似但5G的5QI列表更细。语音、视频会话有对应的5QI普通eMBB数据也有默认的5QI而URLLC业务要用标准里定义的低时延高可靠那一组5QI。不是随便填一个数字也不是把QCI改成1就万事大吉不同5QI背后对应的是调度器里不同的优先级、时延预算和丢包率目标。实际选型时我一般这样分控制类指令用5QI 82这一档它面向高可靠低时延AGV这类移动设备的调度数据用5QI 83带宽需求稍高高精度同步类业务可以考虑5QI 84。普通视频监控和办公上网走默认的eMBB数据5QI就好不要硬塞进URLLC切片里。一个常见错误是把所有业务都映射到默认数据5QI然后指望靠切片标识来获得低时延——空口调度器根本不知道这个切片需要特殊调度效果自然出不来。除了5QI本身无线侧还有几个参数直接影响URLLC表现。PDCP复制开启后同一个数据包会在两个逻辑信道上双发时延和可靠性显著提升代价是空口资源占用翻倍只适合控制面小包。上行预调度则是基站提前给终端分配上行授权减少终端等调度的时延周期一般设在10毫秒到20毫秒之间对周期性上报的AGV和生产设备非常有效。MCS下限限制和HARQ最大重传次数也要按业务调低时延业务会限制MCS不能太低避免重传堆积。参数项低时延URLLC切片推荐大带宽eMBB切片推荐RB预留比例10%~20%20%~30%调度优先级高普通PDCP复制开启关闭上行预调度周期10ms~20ms关闭或按需MCS下限设下限防止低阶空口拖时延不设限保吞吐HARQ最大重传次数按需降低使用默认这组参数是通用经验值不同设备上参数名称会有些差别但逻辑通用。真正做项目时低时延切片的调度优先级和RB预留比例是要根据业务并发和带宽预算反推的不是越大越好。预留比例太大其他切片和普通用户受影响预留太小URLLC业务在峰值时还是会排队。3.3 批量生成无线切片参数模板一个可直接改用的脚本无线侧切片参数涉及的小区数量多时手动在网管上一个一个点太容易错。我习惯用脚本生成参数模板再批量导入网管这样既保证全网一致也方便后续版本升级时比对。下面是一个简化版模板生成脚本字段名可以根据自家设备网管的导入模板调整。# 无线切片参数模板生成脚本 # 用法python3 gen_ran_slice.py输出CSV格式供网管批量导入 slices [ {name: ctrl-factory, sst: 2, 5qi: 82, rb_reserve: 0.15, prio: 0, pdcp_dup: True, pre_sched_cycle: 10, mcs_min: 2}, {name: agv, sst: 2, 5qi: 83, rb_reserve: 0.10, prio: 1, pdcp_dup: False, pre_sched_cycle: 20, mcs_min: 4}, {name: video, sst: 1, 5qi: 8, rb_reserve: 0.25, prio: 2, pdcp_dup: False, pre_sched_cycle: 0, mcs_min: 0}, ] for s in slices: # 生成网管可导入的CSV行名称,SST,5QI,预留比例,优先级,PDCP复制,预调度周期,MCS下限 print(f{s[name]},{s[sst]},{s[5qi]},{s[rb_reserve]:.0%}, f{s[prio]},{on if s[pdcp_dup] else off}, f{s[pre_sched_cycle]},{s[mcs_min]})这段脚本的逻辑是把每个切片的无线参数先集中定义在一个列表里再按固定字段顺序输出避免在网管界面上逐个配置时的漏配和错配。优先级数字越小表示调度优先级越高这是多数设备商的默认约定预调度周期填0表示不开启预调度PDCP复制只有控制类切片开数据量大时会把空口资源吃掉一半以上不是闹着玩的。脚本里还留了MCS下限参数低时延切片建议设一个下限防止链路差时调度器把MCS降到很低导致单次传输时间过长、时延超标。实际使用时要特别注意RB预留的百分比值不仅要单个切片合理还要保证同一小区所有切片预留比例之和不超过60%左右否则普通用户体验无法保障。导入网管后一定要在小区级视图上抽查几个站点确认切片组是否真正生效而不是只看导入成功的提示。4. 核心网侧切片落地SMF/UPF选路与端到端开通4.1 是谁在做核心网切片AMF、SMF、NSSF与NSAC各管一段核心网侧切片涉及网元多很多人配置时容易搞混顺序。按我的理解它们的职责可以拆成四句话AMF负责在终端注册时读取它请求的NSSAI决定接受哪些切片并把允许列表返回给终端SMF负责根据S-NSSAI和DNN选择会话要走的UPF同时下发QoS策略UPF负责真正的用户面转发切片的路由、本地卸载、业务链都在这一层生效NSSF则是辅助AMF做选择当网络里有多个切片实例时帮它定位到正确的那一个。还有一个容易被忽略的网元叫NSAC负责控制每个切片的并发用户数上限防止切片超卖把资源池挤爆。规划阶段我一般会把核心网侧的配置梳理成一张“切片契约表”这张表和无线侧、承载侧的表放在一起形成前面说的跨域对标表。契约表里至少要有S-NSSAI、DNN、UPF位置、TAC、路由策略、最大并发UE数这几列。UPF位置这一列尤其重要它直接决定数据面是否在园区本地卸载影响时延和安全性。配置项说明某项目X实际值示例S-NSSAI标准切片标识SST2, SD0x000001DNN业务接入点名称ctrl.factoryUPF位置用户面下沉点园区机房TAC覆盖范围园区及周边区域路由策略数据是否出园区本地卸载禁止出园区NSAC上限切片最大并发用户数500这张表的价值在于它把网络规划的语言翻译成了核心网配置的语言。实际排查时只要发现注册或会话建立异常先拿这张表逐项比对而不是漫无目的地在网管上翻参数。4.2 从规划到开通端到端配置的七步标准动作与核对脚本核心网切片开通有固定的动作顺序顺序乱了会导致后续步骤无法完成或配置被覆盖。我一般按下面这个顺序走在UDM上给SIM卡签约对应的S-NSSAI和DNN同时确认默认切片和允许切片列表在AMF上配置NSSAI接受策略允许终端请求的切片注册在SMF上创建S-NSSAI和DNN的关联设置UPF选择策略在UPF上配置GTP-U接口、切片转发路由和本地卸载策略在承载网上为切片创建对应的FlexE或SR-TE通道绑定时延模板通过终端管理平台下发URSP策略让终端知道哪个应用走哪条切片插入SIM卡开机验证注册和业务往返时延。配置完成后我会跑一个三域对齐检查脚本。这个脚本本身不复杂核心逻辑是把三域网管导出的切片清单做集合比对找出只出现在部分域的切片标识。# 三域切片配置对齐检查 # 用法分别从无线网管、承载网管、核心网网管导出切片清单文件 # 文件格式每行一个S-NSSAI如 2-000001、1-010001 def load_ids(path): # 读取文件去掉空行和注释行返回切片ID集合 ids set() with open(path, r, encodingutf-8) as f: for line in f: line line.strip() if line and not line.startswith(#): ids.add(line) return ids ran_ids load_ids(ran_slices.txt) transport_ids load_ids(transport_slices.txt) core_ids load_ids(core_slices.txt) # 找出任何两域之间不一致的切片ID all_ids ran_ids | transport_ids | core_ids for sid in sorted(all_ids): domains [] if sid in ran_ids: domains.append(RAN) if sid in transport_ids: domains.append(承载) if sid in core_ids: domains.append(核心网) if len(domains) 3: print(f[未对齐] {sid} 仅存在于 {/.join(domains)})这个脚本的价值不在算法而在它强制你养成交比对账的习惯。切片ID不一致是端到端建连失败最常见的根因之一无线侧叫“2-000001”、核心网侧叫“2-0001”肉眼很难发现脚本一跑就出来了。终端侧的验证也有标准动作。SIM卡开通切片后通过AT指令查看PDU连接状态确认终端注册成功后上报的当前NSSAI里包含目标切片标识。路测软件或终端工程模式里能看到两个关键字段配置的NSSAI和允许的NSSAI。前者是终端里存的切片列表后者是网络真正允许这个终端使用的切片列表。如果允许列表里没有规划好的切片说明核心网侧注册流程就不通后面的拨测没有意义。4.3 UPF下沉、数据本地卸载与容灾让低时延切片的时延真正达标核心网侧切片做得好不好很大程度上取决于UPF的位置。对低时延业务UPF必须下沉到园区或地市边缘让用户面数据在本地完成转发如果UPF放在上级核心机房数据在园区和核心机房之间绕一圈时延预算立刻超标。数据不出园区还意味着生产数据不需要进入公共承载网这个特性在工业企业里比时延更受关注。实际项目中我见过把UPF下沉到园区后端到端时延从25毫秒降到8毫秒以内的案例。这个“下沉”动作不仅仅是把一台设备搬到机房还涉及承载网路由调整、防火墙策略开通、DNS和NTP等配套服务在本地部署。很多人只关注UPF本身忘了几条关键配套园区机房的供电和散热是否符合设备要求传输链路是否增加了与承载网调度策略绑定的切片隧道以及本地下沉UPF是否有远程运维通道。任何一个配套缺失都会让下沉效果大打折扣。容灾方面控制面信令仍然走核心网集中节点用户面走园区UPF这是常见组网。如果园区UPF故障切片级回落策略要考虑清楚是让终端切换到公网普通承载还是直接断网保安全。工业控制类业务通常选择断网因为网络不可用比网络时延不稳定更可预期。跨区切换时还要确保切片标识和DNN在相邻区域保持一致否则终端移动出园区后会话可能被重建业务中断。这类问题在规划阶段就要确认不要等交付后用户投诉才追着改。5. 5G切片建设最常见的5个掉坑点与排查手段5.1 拨测时延没有变化切片像没开现象终端和业务服务器都在园区切片配置完成后拨测时延和普通公网差不多甚至更差。原因最常见的有三种——终端URSP策略没有下发或没生效业务流量根本没进入目标切片无线侧小区切片开关没打开或者5QI没有正确绑定到切片组核心网AMF的NSSAI接受列表不包含请求的切片标识。解决按“终端URSP→RAN切片组→核心网NSSAI”顺序逐域排查。先查UE当前NSSAI里有没有目标切片再看基站侧切片组是否激活最后查AMF允许列表。拨测时用终端工程模式锁定小区避免终端在验证期间切换站点导致数据失真。5.2 终端注册被拒提示网络不允许现象新SIM卡插入5G终端后能搜到网络但注册失败或者注册成功但PDU会话建立时报错。原因UDM签约里的S-NSSAI和AMF配置不一致比如SST填错、SD位数不对、大小写格式不同另一种可能是NSAC限流切片并发用户数达到了上限。解决在UDM和AMF上逐字节核对S-NSSAI不要只看显示结果导出配置对比最可靠。检查NSAC的在线用户数和上限设置。终端侧通过AT指令查看PDU会话建立失败原因码核心网侧查N2口信令两头上报的拒绝原因能直接定位是签约问题还是容量问题。5.3 低时延切片里跑视频把自己卡死现象某工厂把控制类业务和视频监控都接入同一切片结果控制业务时延波动大视频也卡顿。原因URSP规则没有按应用或IP做分流视频流量全部灌进了URLLC切片。URLLC切片的RB预留比例通常只有10%到20%视频流一占资源控制面小包就得排队。解决URSP规则按目的IP或端口分流——控制指令和AGV调度走SST2切片视频走SST1的eMBB切片。同时给URLLC切片设置最小预留比例兜底并对视频业务做带宽限制防止突发流量挤占控制面资源。这个问题的根子是规划阶段的业务分类没做细URSP是补课不是根治。5.4 承载网忘配数据绕远路现象无线和核心网两侧切片都显示正常但业务时延不稳定丢包集中在转发节点。原因承载网没有为切片创建对应的FlexE硬管道或隧道数据走了普通业务通道在传输节点上和其他流量竞争转发路径也比规划路径长。解决在承载网上为每个切片创建独立业务通道绑定对应的时延和带宽模板。全网规划阶段就应该把承载网调度策略放进切片契约表不能只发无线和核心网的工单。承载侧配置缺失在网管上不大容易一眼看到需要从端到端角度逐跳检查数据转发路径。5.5 网络升级后切片全部失效配置像“幽灵”一样消失现象某次核心网或无线设备软件升级后原有切片业务注册率明显下降部分切片直接不可用但网管上配置看起来还在。原因升级过程中配置恢复不完整切片相关功能License在版本升级后失效或者新旧版本对切片功能的支持能力有差异。解决升级前把三域切片配置完整导出存档升级后逐域比对配置和License状态确认各网元设备版本处于支持切片的功能矩阵内。如果异常仍存在联系设备厂商用旧版本环境先应急回退。某次项目就是这样翻车的从那以后我把切片配置比对脚本写进了变更流程升级操作不再依靠人眼检查。6. 验证切片是否真正达标拨测脚本与KPI闭环6.1 一条稳定的拨测通道切片验证不能只在验收入场时跑一次要建立一条固定的拨测通道每次变更后都用同样的脚本跑形成前后对比。我一般用下面这个简化脚本记录时延和丢包#!/bin/bash # 切片拨测脚本连续ping目标并记录统计结果 # 用法: ./slice_probe.sh 目标IP 次数 间隔秒 target${1:-10.10.1.100} count${2:-100} interval${3:-0.2} # 连续小包探测记录时延统计 ping -c $count -i $interval -W 1 $target | tail -1Ping只能反映往返时延而且经过系统协议栈会有额外抖动。URLLC业务验收我习惯直接用UDP小包测试工具打流统计P99和P999分位时延平均值没有意义。所有拨测必须固定终端、固定服务器、固定路径换一个终端可能就因为URSP策略差异导致结果完全不同。6.2 切片KPI验收清单验证指标建议阈值说明注册成功率≥99%终端注册后允许NSSAI包含目标切片PDU会话建立成功率≥99%切片和DNN关联配置正确端到端时延P99低时延≤10~20ms按业务预算设定丢包率≤0.1%连续24小时统计隔离性验证大流量压测时低时延切片时延抖动10%用带宽型业务打满资源池稳定性连续24小时无断流跨切换、跨忙时这张表里最难达标的是隔离性验证。我习惯在验收时故意让视频切片跑满带宽再观察低时延切片的时延变化抖动超过10%说明无线侧预留或承载侧调度没有真正隔离。6.3 收尾技巧验证阶段我有三个固定动作第一把拨测通道固定下来所有变更前后先跑基线再对比杜绝“感觉变好了”的玄学判断第二三域都保留一份配置存档升级或割接后立刻比对而不是等用户投诉了才四处查日志第三验收前让所有业务终端同时挂在网上模拟真实并发只看单终端验收达标不算数。这几次项目做下来真正复杂的技术点其实不那么多大量问题都出在“配置串行对齐”上——无线等核心网、核心网等承载各干各的没人拉通。跑完这套闭环再谈交付心里才有底。希望帮到你。本文还有配套的精品资源点击获取