企业官网建设流程全解析

简介：来自中国联通软件开发部的《5G网络切片技术及应用展望》PPT，聚焦运营商与行业用户如何借助网络切片应对增强移动宽带（eMBB）、海量机器类通信（mMTC）、超可靠低时延通信（URLLC）等多场景差异化需求，适合通信工程师、5G产品经理及高校相关专业学生快速建立整体认知。压缩包内含1个PPT幻灯片文件，大小4.84MB，已有305人浏览学习。内容从“切片”概念与商业驱动力切入，系统梳理网络功能虚拟化（NFV）、软件定义网络（SDN）、RAN感知切片、端到端切片管理系统等关键技术，并展开无线、承载、核心网三层协同方案，以及UPF灵活下沉、终端基于Subscribed-NSSAI选择切片等实施细节；同时结合4K直播、游戏加速、远程控制、FWA家庭宽带等B2B/B2C/B2H案例，说明切片如何以商品化方式为租户提供差异化服务。整套内容知识密度高，既讲清楚“为什么切”，也给出“怎么切、怎么用”的贯通路径，对理解5G网络架构演进和实际切片部署具有直接参考价值。

1. 网络切片到底是什么：一份PPT先解释的“差异化SLA”

有一次给政企客户做5G园区专网方案，客户开口就是“我们要网络切片”。我打开对方发来的需求书，里面写的却是“给视频监控限速20Mbps，给办公网限速10Mbps”。这正是把网络切片理解成限速的典型误解。真正的网络切片不是限速，而是把同一张物理5G网络切成多张逻辑网络，每张逻辑网络各自承诺不同的时延、带宽、可靠性和连接密度——也就是差异化SLA。这份《5G网络切片技术及应用展望.pptx》切入的是5G关键技术里最常被拿来画大饼、却最考落地功夫的一环：先讲三大应用场景，再给端到端架构和切片标识，最后落到行业应用展望。适合三类人：想补切片全链路知识的无线或核心网工程师、需要快速产出切片方案的售前人员、以及做5G实训室或毕业设计需要一个能讲清原理底稿的学生。按我在园区专网项目里拆PPT的习惯，下面把切片从原理、配置到排错完整过一遍。

2. 三类切片、两个标识、一条链路：把切片原理压缩成能直接用的参数

2.1 三大场景的SLA差异：eMBB、URLLC、mMTC不是三个名词

网络切片之所以能成为5G区别于4G的标志性能力，是因为3GPP在一张物理网上定义了三种目标差异极大的业务场景。看这份PPT时，先不要急着背缩写字面意思，要盯着SLA参数看。eMBB解决“快”的问题，URLLC解决“准”的问题，mMTC解决“多”的问题。同一个基站下，视频流要的是吞吐，远程驾驶要的是时延，海量传感器要的是连接数，三个诉求挤在一起，只有物理隔离+独立调度才能同时满足。

我习惯把PPT里的场景描述压缩成一张可用的参数表，写方案时直接抄：

注意表格里的5QI不是随便填的。5QI一旦确定，就决定了时延预算、丢包率、优先级这几个QoS流级别参数。很多刚开始看切片的人会问：切片和QoS到底什么区别？QoS解决“同一管道里谁先走”，切片解决“给谁单独修一条管道”。所以切片一定会用到QoS参数，但光有QoS不叫切片。对照这张表和《5G协议栈详解》里RRC/NAS层对QoS Flow的描述，基本能看懂PTT那一页“三大场景”的含义。

2.2 S-NSSAI与URSP：切片是怎么被“认出来”的

切片要能被网络识别，关键靠S-NSSAI（Single Network Slice Selection Assistance Information）。这个标识由SST（Slice/Service Type，8位）和SD（Slice Differentiator，24位）两部分组成。SST前几个标准取值很多人已经熟悉：1代表eMBB，2代表URLLC，3代表mMTC，4代表V2X。SD则是运营商或专网自己定义的部分，用来区分同一个SST下的不同子切片。比如同样是URLLC（SST=2），工业控制用一个SD，电力差动保护用另一个SD，互不干扰。

光有S-NSSAI还不够，终端还必须知道“哪个App走哪个切片”。这个规则由URSP（UE Route Selection Policy）统一下发。URSP里最核心的是流量描述符和路由选择描述符：前者描述应用、域名、IP三元组等特征，后者指向对应的S-NSSAI、DNN、PDU会话类型。终端拿到URSP后，启动某个App时先匹配流量描述符，再按规则建立或复用对应切片下的PDU会话。看PPT时如果只看“注册请求携带NSSAI”这一句，很容易忽略一个关键事实：终端支持网络切片，不等于终端装了URSP规则。没有URSP，业务默认全走默认切片，其他切片建了也没流量。

2.3 端到端切片链路：RAN切片、传输切片与核心切片的职责边界

一份合格的切片PPT，一定会画一张端到端架构图。问题是大多数人只看图不细究每层做什么。我在现网里拆切片问题时的经验是：把链路切成三段看，哪段没做就是“假切片”。

RAN侧，切片落在频谱资源和调度策略上。具体手段包括：按切片划分PRB资源池、配置独立的准入控制策略、在MAC调度器里为不同切片设置调度优先级。在AAU/DU/CU架构里，AAU只管波束和射频，DU完成MAC调度，CU处理RRC连接和切片相关的无线承载配置。所以RAN侧切片配置不是写一个参数，而是DU和CU两层都要有动作。

传输侧，切片靠承载网的硬隔离或软隔离实现。常见做法是FlexE通道化隔离，给URLLC切片分配独立的FlexE时隙，或者用SPN/IPRAN的切片通道按优先级转发。这一层最容易被无线工程师忽略，但URLLC的时延抖动往往死在传输上。

核心网侧，切片体现为网络功能的选择链。终端注册时，AMF根据NSSAI选择是否允许接入；建立PDU会话时，SMF根据S-NSSAI和DNN选择对应的UPF；需要下沉时，UPF直接部署到园区MEC节点。这三层看下来，核心网只解决“会话建到哪”，传输只解决“报文怎么走”，RAN才解决“空口给多少资源”。三者缺一，切片体验都是纸面SLA。

3. 从PPT到现网：端到端切片配置步骤与峰值速率估算

3.1 需求拆解：把业务SLA转成切片参数的一页纸

拿到PPT里的应用展望，第一步不是开基站配置，而是把业务诉求翻译成切片参数。我一般用一个智慧工厂的例子给团队成员讲这个方法。假设厂区里有三类业务：AGV小车需要低时延远程控制、产线摄像头需要高清视频回传、上千个温湿度传感器需要偶发小包上报。三种业务的SLA完全不同，必须拆成三个切片：

这张表做完，后面所有配置都有依据。别小看这一步，很多项目翻车不是因为设备不支持切片，而是因为需求没拆透：把AGV控制需求和视频回传塞进同一个切片，导致URLLC切片里跑满了大流量，关键小包被挤在队列后面。

这里的带宽估算给一个通用式：切片带宽 = 单用户峰值速率 × 并发用户数 × 并发系数 ×（1 + 冗余10%-20%）。URLLC切片建议冗余给到30%，因为小包场景下带宽利用率低，FlexE时隙一旦给小，突发流量立刻变成时延尖峰。

3.2 RAN侧配置：基站侧到底要写哪些切片参数

RAN侧切片配置在各厂商设备上指令名不同，但概念完全一致。先看一遍《5G设备AAU/DU/CU安装指导书》里关于小区资源和调度策略的部分，再按下面顺序写参数。

第一步是规划切片列表。在CU上为每个切片分配S-NSSAI，并关联对应的QoS参数。第二步是配置小区级切片资源。这一步决定每个PRB资源池分给哪个切片，我习惯按“40%默认切片 + 30%URLLC + 30%eMBB”起步，再根据业务模型调整。第三步是配置调度策略，给URLLC切片里的GBR承载设置最高调度优先级，保证空口调度器优先处理。第四步是配置准入控制，防止eMBB流量挤占URLLC预留资源。

配完这些，RRC重配会通知终端哪些小区支持哪些切片。注意，RAN侧切片只在空口资源这一层做隔离，如果核心网没把会话选到对应UPF，那RAN侧写了也白写。反过来也一样，这是一条链，不是某一个网元的独立配置。

3.3 核心网与承载：UPF下沉和FlexE时隙如何配合

核心网侧的做法，我通常按三步走。第一步，确认NSSF规则：终端注册携带的NSSAI，能否被AMF接受并选择到正确的AMF。第二步，配置SMF选择策略：根据S-NSSAI + DNN选择对应UPF。对于园区场景，UPF下沉到MEC是标准动作，否则URLLC业务绕回省会核心机房，时延直接超标两倍。第三步，配置PCF策略：给不同切片下发不同的QoS策略和URSP规则，让终端侧知道App该走哪条路。

传输侧的核心是给URLLC切片一条确定性路径。FlexE是当前最常用的硬管道技术，本质是把物理口切成多个时隙，每个切片独享时隙，互不抢占。我在一个实际项目里的分配方式是：100G物理口，URLLC切片切20G时隙，eMBB切片切50G，mMTC和默认共用剩余30G。时隙分配别严格按照平均带宽算，URLLC要给突发余量，因为工业协议大多是周期性小包，瞬时队列一旦积压，时延就崩。

3.4 峰值速率估算：用公式把PPT里的指标换算成规划参数

PPT里eMBB峰值速率动不动写10Gbps，但做规划不能拿这个数直接用。我用一个工程估算式来做容量初算：

小区峰值吞吐(bps) ≈ PRB数 × 12 × 14 × 每秒时隙数 × 调制比特数 × 编码效率 × (1 - 控制开销) × MIMO层数

逐项说明：PRB数由带宽和子载波间隔决定，100MHz/30kHz对应273个PRB；每个PRB有12个子载波和14个符号；30kHz子载波间隔下每秒有2000个时隙；256QAM下调制比特数为8；LDPC编码效率约0.925；控制信道和导频开销约15%；MIMO层数按4层算。代入：

273 × 12 × 14 × 2000 × 8 × 0.925 × 0.85 × 4 ≈ 2.3Gbps

这个数就是单小区100MHz/4层MIMO/256QAM能拿到的实际下行峰值，和实验室外场测试结果基本对得上。如果把层数加到8层，带宽堆到200MHz，峰值才能到4-5Gbps级别。做切片容量规划时，用这个公式反推：URLLC切片只需20Mbps带宽，按峰值速率折算只占不到1%的PRB资源，但为了时延必须预留足够调度空隙。所以容量规划要看两个维度：一是资源够不够，二是调度优先级够不够。前者用公式，后者用排队模型，别混为一谈。

4. 五个切片翻车现场：现象、原因与排查顺序

4.1 终端不支持URSP：配好了切片却“测了个寂寞”

现象：核心网和RAN侧切片都配好了，终端注册也显示S-NSSAI被接受，但业务流量始终走默认切片，URLLC切片的SLA指标测出来和普通公网没有区别。

原因：终端虽然支持5G，但URSP策略没有下发或终端不识别。URSP是终端侧把App映射到切片的唯一机制，没有它，PDU会话建在哪个切片全靠终端默认行为。

解决：先确认终端能力，用测试终端查看URSP规则是否为空；再检查PCF是否配置了对应App的URSP规则并成功下发；最后看终端信令里有没有携带S-NSSAI。行业终端如CPE、工业网关通常有专门的URSP配置入口，消费级手机则要看系统版本是否支持。我的习惯是：现场常备两台不同厂商的测试终端，避免“一台终端型号不支持”误导排查方向。

4.2 只改核心网不配RAN：切片通了，但业务还是挤在一起

现象：核心网侧PDU会话已经按S-NSSAI选择到正确UPF，切换片生效，但实测时延抖动大，URLLC业务和eMBB流量在空口互相抢资源。

原因：这只是把“会话”切到了对应切片，但RAN侧没有为这个S-NSSAI配置PRB资源池和调度优先级。所有业务在同一个小区默认队列里排队，所谓切片只是核心网逻辑上的划分，空口并没有隔离。

解决：回RAN侧检查两处，一是小区级切片配置里有没有该S-NSSAI对应的PRB资源池，二是MAC调度策略是否区分了切片优先级。只写核心网不写RAN，是切片项目里最常见的“半套切片”。验证时不要只看PDU会话建立成功，还要看空口调度统计里各切片的PRB占用比例。

4.3 SST取值不一致：跨厂家的切片“不握手”

现象：归属和拜访网络都用同一套S-NSSAI，但终端在跨区注册时被拒绝，或切片无法建立。

原因：SST虽然是标准化的，但不同厂家对非标SST或SD的解析方式不一致，导致NSSAI映射失败。尤其是SD的取值，有的厂家按十六进制解析，有的按十进制透传，两边一比对就错位。

解决：跨厂家互通测试时，至少提前一周拉一个“S-NSSAI取值对照表”，把SST、SD、十六进制写法、十进制写法全部列出，双方逐字段核对。商用网络里SST的1-3尽量走标准定义，SD不要用容易产生歧义的全0值。我曾见过两端厂家因为SD字段大小端序理解不同，来回扯了三天，最后对表才发现问题。

4.4 FlexE时隙照搬带宽估算：URLLC时延达标但吞吐不足

现象：URLLC切片时延测试合格，但跑到突发流量时，吞吐急剧下降，甚至出现丢包。

原因：FlexE时隙是硬管道，带宽上限固定。如果只按平均带宽分配时隙，没有给周期性突发留余量，瞬时超过时隙能力的数据包就会在接口队列丢弃。工业控制报文虽然单包小，但往往是几十台设备在同一毫秒内同时上报，突发倍率可到3-5倍。

解决：FlexE时隙建议按“平均带宽×1.5-2”预留，URLLC切片甚至给到3倍余量。同时把时延敏感队列的调度优先级调到最高，让FlexE管道里的缓存倾向于吸收瞬时突发。时延预算里把传输抖动控制在空口时延的三分之一以内，否则端到端时延虽然均值达标，P99值不可控。

4.5 用QoS优先级代替切片：业务保障了却没有隔离

现象：某些业务体验确实得到了保障，但和普通公网业务混在同一个资源池，出现一个切片流量突发拖垮另一个切片的情况。

原因：把切片做成了“只调优先级”。QoS优先级在共享队列里只能保证“优先被调度”，不能保证“不被别人的流量影响”。当高优先级切片本身的流量已经耗尽资源，其他切片照样受损。

解决：切片的底线是资源隔离。RAN侧必须划PRB资源池，传输侧必须有FlexE时隙或等价通道，核心侧必须有独立UPF路径。我判断一个切片方案是否合格，只看一点：把某个切片流量打满，其他切片的时延和丢包指标是否几乎不变。如果变了，说明这只是QoS，不是切片。

这五个坑如果按出现频率排，终端URSP排第一，RAN侧缺失排第二，其余三个相对少但一出就是大事。现场排查顺序我的习惯是“终端→空口→承载→核心”，先确认终端有没有走对切片，再看空口有没有隔离，再看传输有没有硬管道，最后看核心选择链。

5. 验证切片的四板斧：终端、承载、核心与业务SLA怎么查

切片做没做对，不看配置页面有多漂亮，只看业务实测。我长期用的验证方法是“四板斧”，每一板对应一个故障层，全部过一遍才算切片生效。

第一板斧查终端：确认UE已收到URSP规则，且业务App匹配到了目标S-NSSAI。从终端侧订阅的NAS信令里能看到PDU会话是否携带正确的SST、SD值，很多商用终端内置调试菜单可以直接查看当前PDU会话的S-NSSAI信息。第二板斧查承载：Ping一个远端服务器，同时用iperf3打流，观察时延的均值、抖动和丢包率。如果Ping值极其稳定但iperf3吞吐只有几十Mbps，大概率是FlexE时隙给小了。第三板斧查核心：在SMF/UPF网管上看该S-NSSAI下建立的PDU会话数，并确认UPF路径是下沉到MEC节点而不是绕回中心机房。第四板斧查业务：用真实应用做端到端SLA拨测，例如智能车5G室外赛或室外5G远程驾驶无人车场景，就看两个指标——远程控制指令端到端时延和视频画面卡顿次数，连续测20分钟，记录P99值。

我的一个亲身教训是：去年做一个室外5G远程驾驶无人车演示项目，方案里切片配置齐全，核心网和RAN侧都下了功夫，却在正式演示前一晚发现车载终端根本不识别URSP里配的App切片规则，导致所有控制报文走默认通道，现场时延高到无法操控。后来临时更换行业CPE并在终端侧手动绑定S-NSSAI才救回场子。从那以后，我每次做切片方案都强制走一遍“终端→承载→核心→业务”这四步验证，不测P99就不允许出测试报告。这套方法同样适合你拿到这份《5G网络切片技术及应用展望.pptx》之后：第一次通读看原理，第二次直接照着第三、五章做一张自己项目的切片参数表和验证清单，两遍下来再写方案或讲原理，基本不会卡壳。希望帮到你。

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