某车企和某运营商签了一份切片服务协议。合同写得很漂亮：端到端时延不超过 20ms，丢包率不高于万分之一，保障带宽 100Mbps，可用性不低于 99.99%，数据不出园区专网。
然后工程师打开网管配置界面，能填的框是这样的：
工程师要做的第一件事，是把"20ms"翻译成"5QI=？"。
这份翻译工作，就是切片落地的全部难点所在。合同语言是连续的——时延、带宽、可靠性都是任意实数；网络语言是离散的——5QI 是一格一格的台阶，ARP 优先级只有 15 档，GBR 是整数千比特。中间这段落差，就是运营商售前、网优、核心网三拨人反复对齐的那件事。
本文按"翻译器"的视角，把这件事从头拆一遍：SLA 怎么拆 → 怎么选机制 → 怎么选参数 → 怎么验证 → 怎么排障。
签切片合同前，第一件事不是看 5QI 是什么，而是把客户那份自然语言拆成可兑现的原子承诺。经验上一份工业/车联网类合同，最终都会落到下面这六类：
| 合同里的承诺 | 客户真实在意的 | 网络用什么兑现 | 参数最终落在哪 |
|---|---|---|---|
| 保障带宽 100Mbps | 视频回传不卡、产线不掉帧 | 资源预留（GBR） | 核心网 QoS Flow、无线侧承载 |
| 峰值 200Mbps | 突发上报时别溢出 | 上限（MBR）+ 突发整形 | 承载与调度侧 |
| 端到端时延 ≤20ms | 控制指令要在节拍内到 | 5QI 的时延预算 + 高调度优先级 + 低负载小区 | 无线侧 DRB + 核心网 |
| 抖动 ≤±5ms | 周期数据要匀速到达 | 时延预算 + 调度权重 + 承载整形 | 承载网 |
| 丢包率 ≤0.1% | 关键帧不能丢 | 5QI 的错误率指标 + 纠错重传 + 冗余会话 | 无线空口 |
| 数据不出园区 | 合规隔离 | 独立核心网实例 + 切片专属二次认证 | 核心网 |
| 专属覆盖 | 别的地方也能用 | 专用频谱（而非共享） | 无线网 |
| 可用性 99.99% | 不能宕 | 网络冗余、保护倒换 | 全网 |
注意最后两行——"覆盖"和"隔离"根本不在 5QI 这个参数体系里。这正是很多方案失败的原因：所有人盯着 5QI/ARP/GBR 三个框，忘了时延和带宽之外，隔离是靠架构分层兑现的，而不是靠某一个参数。
先记住这条分界线：
5QI 决定"这条流本身应该被怎么对待"；架构分层决定"这条流能看到什么、能碰到谁"。
客户说的是"端到端 20ms"。而端到端时延从来不是一个参数，是一串：
$$ T_{e2e} = T_{radio} + T_{transport} + T_{core} + T_{app} $$
工程上通常只承诺前四项，且应用和终端的处理时间要单独扣除——如果客户没说明自己的处理时延，这20ms 从一开始就是笔糊涂账。
无线资源不是被"用掉"的，是被"占满"的。当小区负载 $\rho$ 接近 1 时，排队时延不是线性增长，而是发散：
$$ T_q \approx \frac{\rho}{1-\rho}\cdot\frac{1}{\mu-\lambda} $$
其中 $\lambda$ 是到达率、$\mu$ 是服务率（每个时隙能服务多少比特）。直观解释：负载 50% 时排队要等一会儿，负载 90% 时要等很久，负载 99% 时——实际上就是等不到。
这条式子的工程含义非常重要：同一个 5QI、同一个 ARP，在空载小区和满载小区里兑现出来的是两个东西。时延承诺本质上是一句附带负载条件的承诺。翻译的时候如果不写清"在多大负载下兑现"，验收时必然扯皮。
5QI 的时延预算是一个上界档位，不是连续可调的旋钮。客户要 20ms，网络能提供的档位可能只有 50ms 那一级；翻译时要么向上取整（客户体验变差但能签），要么往下走（需要专用频谱、更空的扇区、更低的接入密度来腾出余量）。
向上取整是常态，向下取整要拿钱和容量来换。 这就是"翻译"这一步在商务上和技术上同时吃紧的原因。
还有一个常被忽略的方向：带宽。保障带宽最终要落到无线侧的资源上，粗略地：
$$ N_{PRB} \approx \frac{R_{GBR} + R_{overhead}}{R_{PRB}} $$
其中 $R_{overhead}$ 是协议头、调度、反馈等开销。合同上写"100Mbps 保障"，落到小区里可能是 110~120Mbps 的资源占用——签约时按合同值报容量，验收时按实际占用算账，中间就是这次的差价。
面对一份 SLA，最容易被跳过的一步就是这层。参数选得再对，机制选错了照样兑现不了。
机制层面一共三个可切开的维度：
flowchart TD
A["客户SLA合同"] --> B["SLA属性拆解"]
B --> C["频谱层：专用还是共享"]
B --> D["承载层：硬隔离还是软标签"]
B --> E["核心层：独立实例还是共享"]
C --> F["切片配置基线"]
D --> F
E --> F
F --> G["参数集：5QI/ARP/GBR"]
G --> H["端到端验证"]
共享频谱切片，所有租户在同一批载波上分时隙分资源——成本低，峰值受小区总容量约束。专用频谱切片，租户独享一段载波——容量可预测、干扰可控制，但频谱是稀缺资源，通常按小区整段划出。
判断依据很直接：SLA 里有没有"覆盖不受人影响"这条。有，就往专用走；没有，共享即可。
承载网把基站发出来的包送到核心网。做法有两类：
这就是为什么"5G 好，但端到端时延没达标"的问题往往出在承载网——无线侧把包发出来了，承载上却和一堆别的业务挤在同一个队列里。QoS 参数是端到端契约，任何一跳不认这个契约，契约就作废。
完全独立的核心网实例（专属 AMF/SMF/UPF），隔离最彻底，但成本高、运维复杂。共享核心网 + 切片逻辑隔离，成本低，但合规敏感的客户通常要求叠加切片专属的二次认证，让租户身份在核心网里再验证一次。
判断依据是数据边界要求：数据不出园区、跨租户不可见这类硬要求，只能靠独立实例或专用接入来兑现，靠参数是兑现不了的。
这是最容易搞混的地方，用汽车配置做类比：
三者缺一不可：车型对了但通行等级低，照样堵；通行等级再高但运力只有 50Mbps，也跑不起来。
5QI 背后是一组特性：资源类型（是否保证型/非保证型/时延敏感型）、时延预算、错误率上限、是否周期性流量、优先级、是否允许抢占。取值空间是 1~255，其中 1~63 是标准定义档位，64 以上留给运营商自定义。
常用档位大致长这样（以标准表格为准，不同厂家产品文档里会有实现差异）：
| 5QI | 典型业务 | 时延预算量级 | 错误率量级 | 备注 |
|---|---|---|---|---|
| 1 | 交互语音 | 约 100ms | 约 0.5% | ARP 优先级最高档 |
| 2 | 交互视频 | 约 150ms | 约 0.5% | 视频通话主用 |
| 3 | 实时交互类 | 约 50ms | 约 2% | 游戏、操控类 |
| 8 | 传统视频类 | 约 150ms | 约 1% | 兼容老业务 |
| 9 | 尽力而为（默认档） | 较宽松 | 较宽松 | 不强调保障的默认业务 |
| 51 / 52 | IMS 语音 / 视频 | 与 1 / 2 同量级 | 同量级 | 为 IMS 单独定义 |
关键理解：5QI 里的时延预算不是"保证时延"，是"允许排队多久"的上限。 它约束的是排队，不约束无线传输本身的物理时延，也不约束承载网和核心网的处理时延。这三个加起来才接近客户口中的"端到端时延"。
ARP 解决的是"同时来了，谁先走"。它有三个字段：
两个标志是独立的，这是实战里最常填错的地方：
| 场景 | 优先级 | 可抢占 | 可被抢占 | 原因 |
|---|---|---|---|---|
| 语音 | 高 | 否 | 是 | 语音一旦被中断，体验不可接受，宁可拒绝新呼叫也不打断在通话 |
| 视频专网 | 中高 | 是 | 是 | 允许抢占别人，但自己也让得出去 |
| 批量下载 | 低 | 否 | 是 | 只能捡剩下的余量 |
"高优先级 + 可抢占"是最容易造成事故的组合：它会不断打断低优先级业务，导致后者饥饿，看起来像"某些业务莫名其妙卡死"。
GBR 是保证比特率——在资源允许的前提下，这条流至少能拿到这个速率。典型用法是把 GBR 设成客户买的基础保障速率，MBR 设成可短时冲高的上限。
需要注意适用边界：GBR 只对非时延敏感型的资源类型有意义。你不能同时要求"保证 500Mbps"和"时延必须小于 10ms"，除非小区有专用资源——否则资源预留的规模会把排队时延彻底破坏掉。这是一对天然矛盾的两个承诺，翻译时必须二选一或加钱扩容。
把上面这些串成一个可执行的动作序列：
flowchart TD
A["读合同，拆出六类属性"] --> B["做时延预算减法"]
B --> C["确定隔离与频谱机制"]
C --> D{"小区资源够承诺吗"}
D -->|不够| E["改机制或扩容后重算"]
D -->|够| F["选时延预算不超预算的5QI"]
F --> G["定GBR与MBR"]
G --> H["定ARP优先级与抢占标志"]
H --> I["下发到无线、核心网、承载"]
I --> J["端到端实测验收"]
参数定完，不代表完成。同一份 QoS 承诺，必须在无线侧、核心网、承载网三处同时落地，缺任何一处，承诺就是空的。
flowchart TD
A["PCF下发PCC规则"] --> B["SMF建立QoS Flow"]
B --> C["核心网下发QFI映射与QER"]
C --> D["UPF按QFI标记转发"]
D --> E["承载网按标记排队调度"]
B --> F["AMF下发无线侧承载配置"]
F --> G["映射到DRB与调度优先级"]
G --> H["空口按优先级和预算调度"]
三处的分工：
有一条工程上极重要的因果链：核心网里的 QoS 流编号在离开核心网、进入承载网之后，就变成了承载侧的分类标记。承载网不认识 QoS 流，它只认识标记。所以"5G 侧配得好好的，端到端还是慢"的排查终点，永远落在承载侧是否正确识别并尊重了这个标记。
参数下发成功 ≠ 承诺达成。这一步被跳过，是切片项目验收翻车最集中的地方。
单跳达标不等于端到端达标。验收要测的是业务真实的往返路径（含终端处理、核心网、承载、无线），拆成四段分别测量，然后对账：
| 测量段 | 典型手段 | 常见异常 |
|---|---|---|
| 终端到接入 | 空口抓包 + 时间戳 | 终端省电/休眠导致唤醒延迟 |
| 接入到核心网 | 承载侧逐段时延 | 标记未被识别，进了普通队列 |
| 核心网内部 | 用户面时间戳 | 负载高时排队时延抬头 |
| 核心网到应用 | 应用侧时延统计 | 应用自身处理慢，被误算成网络问题 |
平均值是验收报告里最会骗人的数字。 一个业务 95% 的包 10ms 到达、5% 的包 500ms 到达，平均值 35ms 看着还行，但实时控制早就崩了。看 P99/P999。
启用抢占后，被抢占的流会经历一次"中途刹车再起步"，其时延劣化约等于被抢那段数据在原速率下传输完所需的时间：
$$ \Delta T \approx \frac{L_{preempted}}{R_{victim}} $$
所以启用抢占必须配套一条"受害者劣化上限"承诺，否则你只是在把一个业务的体验问题，换成了另一个业务的体验问题。
排障时最有用的动作是把合同条款直接翻译成一条检查链。以"时延超标"为例：
这四步对应的是"参数是否下发 → 是否映射 → 是否被逐跳尊重 → 物理资源是否够"，顺序不能乱——绝大多数排障时间浪费在第 4 步之前，先把参数链路走通。
坑一：只查无线侧。 无线调度看着正常，承载侧把包塞进了大流量的队列里。无线侧指标永远查不出承载的问题，因为包出无线那一刻还没被排队。
坑二：把"准入失败"当成"网络故障"。 GBR 承诺值填得比小区实际能力高时，新会话在准入阶段就被拒绝，表现为"用户上不了网/业务建不起来"，但网络本身完全正常。这是配置问题，不是故障。
坑三：优先级填太高。 优先级 15 的业务如果很多，会互相抢占并饿死低优先业务。整体表现是"某些业务时好时坏、说不清规律"，极难定位——因为它不像故障那样有明确边界。
参数越"满"，越难扩容。 一个填满 5QI、ARP、GBR 全部字段的合同，意味着每个租户都要独立预留资源。随着租户数上升，整体资源利用率会持续下降，最终所有租户的体验一起变差。
成熟的做法是分级合同：基础档保证基本可用性，尊享档才给高优先级和独占预留。把所有客户都当尊享客户切，网络很快就会用尽弹性。
Q: 5QI 值越大越好吗？ A: 不是。5QI 不是"服务质量等级分数"，而是一组业务特性的编号，编号大小本身没有优劣。真正决定待遇的是它背后的时延预算、错误率指标，以及配套的 ARP 优先级和 GBR。选高编号但业务不匹配的档位，只会拿到更严的资源约束和更低的准入通过率。
Q: ARP 优先级和 5QI 里的优先级有什么区别？ A: 两者管的是不同的层。5QI 描述"这类业务天生是什么样"（时延预算、错误率），ARP 描述"在小区拥塞时谁先走、能不能抢别人"。前者是业务画像，后者是调度策略。一个 5QI 配得再对，ARP 优先级填错了，一样会被别的流挤住。
Q: GBR 和 MBR 有什么区别？ A: GBR 是保证比特率——网络必须为这条流预留出这个速率的容量，是可以写进合同的硬承诺。MBR 是上限——这条流最多能跑多快，超过就按限速处理。GBR 决定了准入的门槛，MBR 决定了短时突发的天花板。
Q: 客户要"端到端 20ms"，能不能就按 20ms 配一个 5QI？ A: 不能这么直接配。5QI 的时延预算约束的是排队，不是端到端总时延。正确做法是先把 20ms 做预算分解：终端处理 + 无线 + 承载 + 核心网，逐段确认可行性，余量留够后，再选时延预算档位不超预算、且小区资源支撑得住的 5QI，同时把"在多大负载下兑现"写进验收条件。
Q: 启用抢占会不会把在用的业务搞断？ A: 会影响，但可控。被抢占的流不会断——数据还在，只是要等被抢占的流先走完，这就是延迟劣化的来源。所以启用抢占必须同时定义三件事：允许抢占哪些档位的流、受害者最差能劣化多少、被抢占流重新获得服务的最长时间上界。这三条不写清楚，启用抢占就是把体验问题在业务之间搬来搬去。
切片落地的真正难点，从来不在参数本身。5QI、ARP、GBR 都只是"档位选择"，真正吃经验的是三件事：
第一，先做减法再做选择。 合同的连续承诺必须先拆成"哪部分归无线、哪部分归承载、哪部分归核心网、哪部分根本不归网络"，否则参数会配错地方。
第二，先定机制，再填参数。 隔离靠架构分层、覆盖靠频谱、时延靠负载余量——这三件事没有一件是靠 5QI 兑现的。把所有赌注押在参数上，是切片项目最常见的失败姿势。
第三，翻译一定有损，必须把损耗写进合同。 向上取整的时延档位、超出合同值的资源占用、抢占带来的受害者劣化——这些不是可以事后讨价还价的细节，而是必须在签字前就写清楚的东西。
对工程侧来说，最后一句最实用：任何一条 QoS 承诺，最终都要能被还原成"哪一跳、哪个队列、哪个计数器"。 还原不出来，就说明它还是纸面上的承诺；还原得出来，验收和排障才有抓手。
本文由「51学通信」技术团队出品。51学通信由通信行业18年老兵爱卫生（微信ID: gprshome201101）维护，聚焦5G/6G核心网、3GPP标准解读、通信前沿技术深度分析。 出版作品有《5G核心网原理与实践》《IMS原理与实践》等4本通信专业书籍。知识星球「51学通信」提供深度技术答疑和行业洞察。
[!tip] 51学通信知识星球 星主：爱卫生（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 星球定位：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 当前规模：5200 篇主题 / 990 个回答，198 元/年。 加入福利：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 AI 加持：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。