# 把合同翻译成参数：切片SLA如何落地 ## 引子：一张写着"20ms"的纸，和一个只能填"9"的框 某车企和某运营商签了一份切片服务协议。合同写得很漂亮：端到端时延不超过 20ms，丢包率不高于万分之一，保障带宽 100Mbps，可用性不低于 99.99%，数据不出园区专网。 然后工程师打开网管配置界面，能填的框是这样的： - 一个叫 **5QI** 的下拉框，值从 1 排到 255 - 一个叫 **ARP** 的配置块，里面是优先级号和两个开关 - 一个叫 **GBR** 的数字，单位 kbps - 一堆开关：专用频谱？独立核心网？传输网硬隔离？ 工程师要做的第一件事，是把"20ms"翻译成"5QI=？"。 这份翻译工作，就是切片落地的全部难点所在。合同语言是**连续**的——时延、带宽、可靠性都是任意实数；网络语言是**离散**的——5QI 是一格一格的台阶，ARP 优先级只有 15 档，GBR 是整数千比特。中间这段落差，就是运营商售前、网优、核心网三拨人反复对齐的那件事。 本文按"翻译器"的视角，把这件事从头拆一遍：**SLA 怎么拆 → 怎么选机制 → 怎么选参数 → 怎么验证 → 怎么排障**。 --- ## 一、先把合同拆开：SLA 其实卖的是六件事 签切片合同前，第一件事不是看 5QI 是什么，而是把客户那份自然语言拆成**可兑现的原子承诺**。经验上一份工业/车联网类合同，最终都会落到下面这六类： | 合同里的承诺 | 客户真实在意的 | 网络用什么兑现 | 参数最终落在哪 | |---|---|---|---| | 保障带宽 100Mbps | 视频回传不卡、产线不掉帧 | 资源预留（GBR） | 核心网 QoS Flow、无线侧承载 | | 峰值 200Mbps | 突发上报时别溢出 | 上限（MBR）+ 突发整形 | 承载与调度侧 | | 端到端时延 ≤20ms | 控制指令要在节拍内到 | 5QI 的时延预算 + 高调度优先级 + 低负载小区 | 无线侧 DRB + 核心网 | | 抖动 ≤±5ms | 周期数据要匀速到达 | 时延预算 + 调度权重 + 承载整形 | 承载网 | | 丢包率 ≤0.1% | 关键帧不能丢 | 5QI 的错误率指标 + 纠错重传 + 冗余会话 | 无线空口 | | 数据不出园区 | 合规隔离 | 独立核心网实例 + 切片专属二次认证 | 核心网 | | 专属覆盖 | 别的地方也能用 | 专用频谱（而非共享） | 无线网 | | 可用性 99.99% | 不能宕 | 网络冗余、保护倒换 | 全网 | 注意最后两行——**"覆盖"和"隔离"根本不在 5QI 这个参数体系里**。这正是很多方案失败的原因：所有人盯着 5QI/ARP/GBR 三个框，忘了时延和带宽之外，隔离是靠架构分层兑现的，而不是靠某一个参数。 先记住这条分界线： > **5QI 决定"这条流本身应该被怎么对待"；架构分层决定"这条流能看到什么、能碰到谁"。** --- ## 二、为什么必须翻译：连续与离散之间的那道坎 ### 2.1 时延预算必须先做减法 客户说的是"端到端 20ms"。而端到端时延从来不是一个参数，是一串： $$ T_{e2e} = T_{radio} + T_{transport} + T_{core} + T_{app} $$ - $T_{radio}$：无线接入段（调度等待 + 传输 + 重传） - $T_{transport}$：承载网转发段 - $T_{core}$：核心网用户面处理段 - $T_{app}$：应用与终端自身处理 工程上通常只承诺前四项，且应用和终端的处理时间要单独扣除——**如果客户没说明自己的处理时延，这20ms 从一开始就是笔糊涂账**。 ### 2.2 排队时延为什么是最凶的那一项 无线资源不是被"用掉"的，是被"占满"的。当小区负载 $\rho$ 接近 1 时，排队时延不是线性增长，而是发散： $$ T_q \approx \frac{\rho}{1-\rho}\cdot\frac{1}{\mu-\lambda} $$ 其中 $\lambda$ 是到达率、$\mu$ 是服务率（每个时隙能服务多少比特）。直观解释：负载 50% 时排队要等一会儿，负载 90% 时要等很久，负载 99% 时——**实际上就是等不到**。 这条式子的工程含义非常重要：**同一个 5QI、同一个 ARP，在空载小区和满载小区里兑现出来的是两个东西**。时延承诺本质上是一句附带负载条件的承诺。翻译的时候如果不写清"在多大负载下兑现"，验收时必然扯皮。 ### 2.3 离散化是有损的 5QI 的时延预算是**一个上界档位**，不是连续可调的旋钮。客户要 20ms，网络能提供的档位可能只有 50ms 那一级；翻译时要么向上取整（客户体验变差但能签），要么往下走（需要专用频谱、更空的扇区、更低的接入密度来腾出余量）。 **向上取整是常态，向下取整要拿钱和容量来换。** 这就是"翻译"这一步在商务上和技术上同时吃紧的原因。 还有一个常被忽略的方向：带宽。保障带宽最终要落到无线侧的资源上，粗略地： $$ N_{PRB} \approx \frac{R_{GBR} + R_{overhead}}{R_{PRB}} $$ 其中 $R_{overhead}$ 是协议头、调度、反馈等开销。**合同上写"100Mbps 保障"，落到小区里可能是 110~120Mbps 的资源占用**——签约时按合同值报容量，验收时按实际占用算账，中间就是这次的差价。 --- ## 三、翻译第一层：先选机制，再谈参数 面对一份 SLA，最容易被跳过的一步就是这层。参数选得再对，机制选错了照样兑现不了。 机制层面一共三个可切开的维度： ```mermaid 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["端到端验证"] ``` ### 3.1 频谱层：专用 vs 共享 共享频谱切片，所有租户在同一批载波上分时隙分资源——成本低，峰值受小区总容量约束。专用频谱切片，租户独享一段载波——容量可预测、干扰可控制，但频谱是稀缺资源，通常按小区整段划出。 判断依据很直接：**SLA 里有没有"覆盖不受人影响"这条**。有，就往专用走；没有，共享即可。 ### 3.2 承载层：硬切片 vs 软标签 承载网把基站发出来的包送到核心网。做法有两类： - **硬隔离**：给切片分配独立带宽或独立通道。带宽有物理保障，代价是资源利用率低、扩容慢。 - **软标签**：给包打上优先级/分类标记，共享通道里按标记排队调度。利用率高，但保障强度取决于全网每一跳都正确识别并尊重这个标记。 **这就是为什么"5G 好，但端到端时延没达标"的问题往往出在承载网**——无线侧把包发出来了，承载上却和一堆别的业务挤在同一个队列里。QoS 参数是端到端契约，任何一跳不认这个契约，契约就作废。 ### 3.3 核心层：独立实例 vs 共享 完全独立的核心网实例（专属 AMF/SMF/UPF），隔离最彻底，但成本高、运维复杂。共享核心网 + 切片逻辑隔离，成本低，但合规敏感的客户通常要求叠加切片专属的二次认证，让租户身份在核心网里再验证一次。 判断依据是**数据边界要求**：数据不出园区、跨租户不可见这类硬要求，只能靠独立实例或专用接入来兑现，靠参数是兑现不了的。 --- ## 四、翻译第二层：5QI、ARP、GBR 各自的分工 ### 4.1 一张表看清三者分工 这是最容易搞混的地方，用汽车配置做类比： - **5QI = 车的型号**（决定这车天生是跑车还是货车，账本里对应什么参数） - **ARP = 这辆车在车队里的通行等级**（决定它堵在路上时能不能先行、能不能被加塞） - **GBR = 你包下的运力**（决定你能稳定跑多少） 三者缺一不可：车型对了但通行等级低，照样堵；通行等级再高但运力只有 50Mbps，也跑不起来。 ### 4.2 5QI：一串业务特性，而不是一个分数 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 里的时延预算不是"保证时延"，是"允许排队多久"的上限。** 它约束的是排队，不约束无线传输本身的物理时延，也不约束承载网和核心网的处理时延。这三个加起来才接近客户口中的"端到端时延"。 ### 4.3 ARP：优先级 + 两个抢占开关 ARP 解决的是"同时来了，谁先走"。它有三个字段： - **优先级**：1~15，数字越大越优先。 - **可抢占标志**：我能不能主动把别人挤下去。 - **可被抢占标志**：我允不允许被别人挤下去。 两个标志是**独立的**，这是实战里最常填错的地方： | 场景 | 优先级 | 可抢占 | 可被抢占 | 原因 | |---|---|---|---|---| | 语音 | 高 | 否 | 是 | 语音一旦被中断，体验不可接受，宁可拒绝新呼叫也不打断在通话 | | 视频专网 | 中高 | 是 | 是 | 允许抢占别人，但自己也让得出去 | | 批量下载 | 低 | 否 | 是 | 只能捡剩下的余量 | **"高优先级 + 可抢占"是最容易造成事故的组合**：它会不断打断低优先级业务，导致后者饥饿，看起来像"某些业务莫名其妙卡死"。 ### 4.4 GBR：能写进合同的带宽承诺 GBR 是保证比特率——在资源允许的前提下，这条流至少能拿到这个速率。典型用法是把 GBR 设成客户买的基础保障速率，MBR 设成可短时冲高的上限。 需要注意适用边界：**GBR 只对非时延敏感型的资源类型有意义**。你不能同时要求"保证 500Mbps"和"时延必须小于 10ms"，除非小区有专用资源——否则资源预留的规模会把排队时延彻底破坏掉。这是一对天然矛盾的两个承诺，翻译时必须二选一或加钱扩容。 ### 4.5 翻译决策流程 把上面这些串成一个可执行的动作序列： ```mermaid 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 承诺，必须在**无线侧、核心网、承载网**三处同时落地，缺任何一处，承诺就是空的。 ```mermaid 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 流被映射到一个无线承载（DRB），落到调度器里的优先级和时延预算上。调度器决定"下一个时隙服务谁"。 - **核心网**：QoS 流有独立编号（QFI），用户面在转发时把这个编号带在报文头里，下游一看就知道"这是我该按什么档位处理"。 - **承载网**：核心网出来的包带上分类标记，承载沿途每一跳按标记调度。 有一条工程上极重要的因果链：**核心网里的 QoS 流编号在离开核心网、进入承载网之后，就变成了承载侧的分类标记**。承载网不认识 QoS 流，它只认识标记。所以"5G 侧配得好好的，端到端还是慢"的排查终点，永远落在承载侧是否正确识别并尊重了这个标记。 --- ## 六、验证：翻译完不等于兑现 参数下发成功 ≠ 承诺达成。这一步被跳过，是切片项目验收翻车最集中的地方。 ### 6.1 唯一裁判是端到端测量 单跳达标不等于端到端达标。验收要测的是**业务真实的往返路径**（含终端处理、核心网、承载、无线），拆成四段分别测量，然后对账： | 测量段 | 典型手段 | 常见异常 | |---|---|---| | 终端到接入 | 空口抓包 + 时间戳 | 终端省电/休眠导致唤醒延迟 | | 接入到核心网 | 承载侧逐段时延 | 标记未被识别，进了普通队列 | | 核心网内部 | 用户面时间戳 | 负载高时排队时延抬头 | | 核心网到应用 | 应用侧时延统计 | 应用自身处理慢，被误算成网络问题 | ### 6.2 三个必须写进验收报告的条件 1. **负载条件**：在多大小区负载下测的？满载复测结果如何？ 2. **丢包口径**：是丢包还是延迟到达？后者对实时业务等价于失败。 3. **观测周期**：瞬时达标不算达标，要看分位数（尤其是高分位），而不是平均值。 **平均值是验收报告里最会骗人的数字。** 一个业务 95% 的包 10ms 到达、5% 的包 500ms 到达，平均值 35ms 看着还行，但实时控制早就崩了。看 P99/P999。 ### 6.3 抢占后的账要单独算 启用抢占后，被抢占的流会经历一次"中途刹车再起步"，其时延劣化约等于被抢那段数据在原速率下传输完所需的时间： $$ \Delta T \approx \frac{L_{preempted}}{R_{victim}} $$ 所以**启用抢占必须配套一条"受害者劣化上限"承诺**，否则你只是在把一个业务的体验问题，换成了另一个业务的体验问题。 --- ## 七、现网连接：参数怎么查，问题怎么定位 ### 7.1 从合同倒推到抓包点 排障时最有用的动作是**把合同条款直接翻译成一条检查链**。以"时延超标"为例： 1. **确认流是否被正确识别**：核心网侧这条 PDU 会话里有没有建立 QoS 流？下发时的 5QI 和 ARP 是不是合同里那组值？ 2. **确认 QoS 流是否真的映射到了无线承载**：编号映射对不对？无线侧承载的优先级是不是那一档？ 3. **确认承载侧是否尊重了标记**：抓包看出去的包带的是什么分类标记，中间每一跳的队列有没有正确分流。 4. **确认小区负载**：查负载和排队时延指标，判断是不是"参数没错但小区满了"。 这四步对应的是"参数是否下发 → 是否映射 → 是否被逐跳尊重 → 物理资源是否够"，顺序不能乱——绝大多数排障时间浪费在第 4 步之前，先把参数链路走通。 ### 7.2 三个高频坑 **坑一：只查无线侧。** 无线调度看着正常，承载侧把包塞进了大流量的队列里。无线侧指标永远查不出承载的问题，因为包出无线那一刻还没被排队。 **坑二：把"准入失败"当成"网络故障"。** GBR 承诺值填得比小区实际能力高时，新会话在准入阶段就被拒绝，表现为"用户上不了网/业务建不起来"，但网络本身完全正常。这是配置问题，不是故障。 **坑三：优先级填太高。** 优先级 15 的业务如果很多，会互相抢占并饿死低优先业务。整体表现是"某些业务时好时坏、说不清规律"，极难定位——因为它不像故障那样有明确边界。 ### 7.3 一个反直觉的提醒 **参数越"满"，越难扩容。** 一个填满 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 承诺，最终都要能被还原成"哪一跳、哪个队列、哪个计数器"。** 还原不出来，就说明它还是纸面上的承诺；还原得出来，验收和排障才有抓手。 --- ## 参考来源 1. [Network slicing - Wikipedia](https://en.wikipedia.org/wiki/Network_slicing) — 网络切片的定义、隔离模型与端到端架构视角 2. [5G QoS - ShareTechnote](https://www.sharetechnote.com/html/5G/5G_QoS.html) — 5QI、ARP、GBR 等 QoS 属性的分层讲解与参数取值 3. [5G NR QoS Architecture, QoS Attribute and QoS Flow - Techplayon](https://www.techplayon.com/5g-nr-qos-architecture-qos-attribute-and-qos-flow/) — 承载级与流级两级 QoS 模型的对比演进 4. [Quality of service - Wikipedia](https://en.wikipedia.org/wiki/Quality_of_service) — 优先级标记、整形与监管、逐跳资源预留的通用原理 5. [UPF - 5GC Textbook](https://5gctextbook.com/en/nf/upf/) — 用户面如何接收并逐包执行策略规则的原理讲解 6. [Packet Forwarding Rules (PDR/FAR/QER/URR/BAR) - DeepWiki Open5GS](https://deepwiki.com/open5gs/open5gs/5.1.2-packet-forwarding-rules-(pdrfarqerurrbar)) — 开源核心网中规则体系的真实落地形态 --- > 本文由「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 等场景全覆盖。