你在购物车里下过两种单：一种是标着“次日达”的水果，另一种是不限时效的打印纸。前者贵，因为快递公司为你预留了舱位——哪怕当天货舱紧张，也要把别人的货往后挪，先把你的水果送出去；后者便宜，货舱挤就等一天，丢了再补寄一单。
通信网络里跑的数据包，和这两种包裹一模一样。微信语音里的一句“喂”，晚到半秒你就觉得对方卡了；而后台偷偷更新的系统补丁，晚到十分钟你毫无察觉。如果网络对每个包都一视同仁地“先进先出”，那么语音就会和补丁挤在同一个队伍里互相拖累——这就是QoS（Quality of Service，服务质量）要解决的问题。
QoS 不是让网络跑得更快，而是让网络对不同流的包给出不同的承诺：有的流承诺“按时送到，丢了算我的”，有的流只承诺“尽力送到，堵了别怪我”。本文讲清楚 5G 里这套“待遇体系”的三个核心零件：5QI（套餐编号）、GBR/Non-GBR（保底与共享两种资源哲学）、ARP（插队规则），以及一条数据包从应用到空口、待遇是如何被一步步确定和执行的。
先建立一个直觉：应用的丢包耐受和时延耐受是两种独立的性格。
这就有了一个天然的“服务分级”需求。但分级不能是运营商拍脑袋：你在这家网络给“语音”定的待遇，换个网络（漫游、切换到另一张网）必须还能对上号。于是需要一个全球通用的待遇字典——这就是 5QI 的由来。
4G 时代的做法是按承载（bearer）服务：每个用户建一条条 EPS 承载，每条承载绑一个 QCI（QoS 等级标识），同一条承载里的所有包享受同等待遇，在核心网到基站之间各自占一条独立的 GTP 隧道。这就像火车包厢：一节车厢一个速度，想让两种不同待遇的包并行，就得再挂一节车厢——每次都要跑一遍信令流程，笨重。
5G 把粒度细化到了QoS 流（QoS Flow）：每个流有自己的编号 QFI（QoS Flow Identifier），包在隧道里传输时不再是“整节车厢一个待遇”，而是每件行李贴一张标签。到了基站，多条待遇兼容的流还可以合并进同一条空口承载（DRB）里传输。
flowchart TD
A["应用开口要待遇<br/>我要打电话"] --> B["核心网会话管理<br/>翻译成套餐"]
B --> C["5QI=1<br/>时延预算100ms"]
B --> D["ARP<br/>可抢人 不可被抢"]
C --> E["UPF 给每个包贴标签<br/>QFI=1"]
D --> E
E --> F["基站调度器<br/>按套餐排队"]
F --> G["语音包优先出队<br/>普通包让路"]
G --> H["对端按时收到<br/>通话连续"]
为什么这样设计？ 因为 5G 面对的业务谱系比 4G 宽得多：从毫秒级的工业控制到“不在乎延迟只要带宽大”的下载，如果每种待遇都要单独建承载、跑信令，控制面的开销会爆炸。改成“流 + 标签”后：
5QI 本质上是一个索引号。网络不给每个业务逐项传送“时延多少、丢包多少、优先级几”这一大串参数，而是只传一个编号，收号的一方去查标准化的套餐表，就知道这套待遇的全部参数：资源类型、优先级、包时延预算（PDB）、误包率（PER）等。
下表是现网最常见的几个标准化套餐（数值为业界通行的标准化参数表内容，本次成稿时检索工具受限，建议以文末来源交叉核对）：
| 5QI | 资源类型 | 优先级 | 时延预算 PDB | 误包率 PER | 典型业务 |
|---|---|---|---|---|---|
| 1 | GBR | 20 | 100 ms | 10⁻² | 5G 语音通话 |
| 2 | GBR | 40 | 150 ms | 10⁻³ | 视频通话 |
| 3 | GBR | 30 | 50 ms | 10⁻³ | 实时游戏、工业控制 |
| 5 | Non-GBR | 10 | 100 ms | 10⁻⁶ | 语音信令 |
| 7 | Non-GBR | 70 | 100 ms | 10⁻³ | 直播、互动视频 |
| 8 | Non-GBR | 80 | 300 ms | 10⁻⁶ | 普通移动数据 |
| 9 | Non-GBR | 90 | 300 ms | 10⁻⁶ | 默认上网流 |
| 82 | 延迟关键 GBR | 19 | 10 ms | 10⁻⁴ | 车联网协同感知 |
读这张表有几个门道：
优先级数字越小，待遇越高。 注意 5QI 5（信令）的优先级是 10，比语音的 20 还靠前——这不是设计失误。信令是网络的“神经系统”，一旦信令被业务流量憋死，连释放资源自救都做不到。所以管理平面永远比用户平面金贵，这是全网设计的铁律。
PDB 是预算，不是军令状。 包时延预算的准确含义是：在这个时间预算内到达，就视为“没迟到”。它是给调度器、重传机制（HARQ）等各个环节分摊时延开支的总账本，而不是承诺每个包都 100 毫秒必达。5QI 82 的 PDB 只有 10 毫秒，意味着整条链路几乎不为它留排队余地，调度器要像救护车一样随到随发。
PER 表达的是丢包的“容忍度”。 10⁻² 意味着一百个包丢一个可接受——语音丢一点听不出来；10⁻⁶ 则是百万分之一的量级——文件传输丢不得。你会看到语音（5QI 1）的 PER 反而比上网（5QI 9）宽松两个数量级，这正是“性格不同，待遇不同”的量化体现。
为什么用索引而不是传全套参数？ 三个理由：省信令（一个字节代替一串参数）、保一致（全网对同一个编号的理解完全相同，漫游也不跑偏）、留余地（运营商还可以自定义动态 5QI，自行填写全套参数，用于特殊业务，但出了自家网络别人未必认得）。
5QI 表里最关键的一列是资源类型，它把所有流分成两种哲学：
GBR（Guaranteed Bit Rate，保底速率）是预约制餐厅。 你要开一条语音流，网络先做准入控制：看看小区还剩多少保障容量，够就接纳并预留资源——哪怕你暂时不说话，这份资源也给你占着；不够就拒绝，或者按规则挤掉别人。GBR 流还带两个速率值：GFBR 是保底速率（承诺给到），MFBR 是封顶速率（超了也不多给）。
Non-GBR 是大排档。 不审批、直接进，大家共享一个资源池，忙时互相挤。它的唯一约束是 AMBR（聚合最大比特率）这道总闸：session-AMBR 管一条 PDU 会话的总量，UE-AMBR 管这个用户所有会话加起来的总量，由基站执行限速。
为什么 GBR 要先审批？ 用排队论一个最简单的直觉公式看就明白了。把基站看成一个服务窗口，包到达率为 $\lambda$，服务率为 $\mu$，平均等待时间大致满足：
$$W = \frac{1}{\mu - \lambda}$$
这个公式最凶险的地方在分母：当负载 $\lambda$ 逼近容量 $\mu$ 时，等待时间不是线性变差，而是爆炸式恶化。也就是说，一个小区在 80% 负载时语音还挺好，再加几个大流量用户冲到 95%，时延直接失控。所以对时延敏感、要“担责”的 GBR 流，必须在进门之前算账：
$$\sum_{i \in \text{已接纳}} GFBR_i \;+\; GFBR_{\text{新流}} \;\le\; C_{\text{小区保障容量}}$$
算得过来才接纳——宁可拒绝，不可失信。这就是 GBR 准入控制的全部逻辑。
flowchart TD
A["新业务申请保底带宽"] --> B{"是 GBR 流吗"}
B -->|否| C["直接接纳<br/>进共享池排队"]
B -->|是| D["基站查剩余保障容量"]
D --> E{"够分吗"}
E -->|够| F["接纳并预留资源"]
E -->|不够| G["按 ARP 找牺牲者"]
G --> H{"抢得到吗"}
H -->|能| I["释放低优先级流<br/>接纳新流"]
H -->|不能| J["拒绝申请<br/>业务降级运行"]
两种哲学的责任边界也完全不同：GBR 流在预算内发生拥塞性丢包，责任在网络（你收了承诺）；Non-GBR 流被挤压、被丢弃，网络无责（从来没承诺过）。这一点直接决定了丢包重传策略和用户体验归因。
很多人把 5QI 优先级和 ARP 优先级搞混，其实它们管的是两个不同时刻的事：
| 维度 | 5QI 优先级 | ARP 优先级 |
|---|---|---|
| 管什么 | 已经接纳的包，谁先被调度 | 新流能不能进来，拥塞时谁被踢 |
| 起作用时机 | 每个调度时刻（毫秒级连续生效） | 建立准入与资源冲突的瞬间 |
| 取值范围 | 1～127，数字越小越优先 | 1～15，数字越小越优先 |
| 类比 | 餐厅里上菜的先后顺序 | 订座时谁有资格挤掉谁的座位 |
ARP（分配与保持优先级）除了一个 1～15 的优先级数字，还有两个开关，合起来构成一张“社交关系表”：
四个开关组合出四种人格：又能抢人又不可被抢的是救护车（紧急语音、公共安全业务）；不能抢人但可能被抢的是普通乘客（一般视频通话）；双开关全关的是佛系流。这套机制完美对应医院分诊台——急诊永远有路，但代价是有人要让出诊室。
sequenceDiagram
participant U as 新业务
participant C as 核心网
participant G as 基站
participant L as 低优先级流
U->>C: 申请语音保障带宽
C->>G: 下发套餐与抢占能力
G->>G: 盘点空口剩余资源
G->>L: 资源不足 释放你的预留
L-->>G: 预留让出 转入不保障状态
G-->>C: 准入成功
C-->>U: 通话建立
注意一个细节：被抢占的流不是被“删除”，而是降级——GBR 预留被收回，业务本身往往还能以 Non-GBR 的方式继续跑，只是从此没有保障。就像被请出包厢的客人还可以去大排档，只是不再有人保证上菜时间。
前面讲的是“待遇单怎么开”，现在看“待遇怎么执行”。关键在标记与映射两级机制：
还有一个省信令的巧思值得一讲：反射式 QoS（Reflective QoS）。上下行待遇通常是对称的，如果每条上行流都要网络专门下发一条 QoS 规则，信令会很啰嗦。于是网络在下行包上打一个 RQI 指示，终端看到后照着下行待遇反推出上行规则——“下行怎么被对待，上行就照着办”，像跟读一样省掉了专门的通知流程。
最后理清 QoS 与切片的关系，一句话：切片是包间，QoS 是座位。 切片在你建立连接之前就选定了，决定你进哪个包间（哪一组网络功能、哪一套隔离资源）；进去之后，包间里依然按 5QI 分座位等级。一张切片里可以并存多种 5QI；一条 QoS 流只属于一条 PDU 会话，也就只属于一个切片。两者是正交的两级服务机制，谁也不能替代谁：
flowchart TD
subgraph SA["切片A：车联网包间"]
PA["PDU会话1"] --> F1["5QI=82 关键流"]
PA --> F2["5QI=9 普通流"]
F1 --> D1["DRB1 专用通道"]
F2 --> D2["DRB2 普通通道"]
end
subgraph SB["切片B：手机上网包间"]
PB["PDU会话2"] --> F3["5QI=8 普通流"]
PB --> F4["5QI=9 默认流"]
F3 --> D3["DRB3 套餐相同可合并"]
F4 --> D3
end
看信令时：终端建立 PDU 会话的信令里，核心网会携带 QoS 参数——默认流的 5QI（常见 9 或 8）、session-AMBR、以及会话级 ARP。开通“专属保障”类业务时，你会在会话修改流程里看到新增一条 GBR 流，带 GFBR/MFBR 数值和高优先级 ARP——所谓“网络切片保障产品”，落地时往往就是这几行参数。
调语音质量时：MOS 分差，第一步不是看无线覆盖，而是确认通话走的到底是不是 5QI 1。如果 GBR 准入失败，业务可能已静默降级到 Non-GBR 流——信令上看“建立成功了”，体验上却是时延抖动和丢包。GBR 降级是静默的，这是最常见的坑。
查拥塞投诉时：晚高峰某小区游戏用户集体掉线或卡顿，先看该小区的 GBR 接纳失败计数器和抢占计数器。如果语音流量把保障容量占满，后来的延迟关键业务被拒；如果某批终端的 ARP 配置过高，又会反过来频繁抢占别人。ARP 是策略，策略错了就是系统性事故。
三个经典误区：
Q: 5QI 和 4G 的 QCI 是什么关系？ A: 一脉相承的“套餐编号”思想，5QI 是它的 5G 版本。主要变化有三点：作用对象从“承载”细化到“QoS 流”；资源类型在 GBR/Non-GBR 之外新增了“延迟关键 GBR”（5QI 80 以上那一段，PDB 压到 10～20 毫秒量级）；配套机制从“一承载一隧道”改为“流标签 + DRB 灵活映射”。
Q: GBR 流没有数据传输时，资源是不是白占着？ A: 是的，预留不释放，这正是它的代价。GBR 的本质是“占座”，不是“按需使用”。所以现网对 GBR 的审批很克制：语音通话、关键物联这类真正需要承诺的业务才开，普通上网流量一律 Non-GBR。
Q: ARP 的 1 和 15，哪个优先级高？抢占开关该怎么理解？ A: 1 最高、15 最低，两个开关独立配置。“能抢人 + 不可被抢”是最高待遇（紧急业务典型配置），“不能抢人 + 可被抢”是默认待遇。调试时记住一句：谁的抢占能力配高了，谁就可能在拥塞时踩别人一脚——测试卡误配高 ARP 抢掉生产语音，是现网真实发生过的经典事故类型。
Q: 一条 QoS 流和一条 DRB 是一一对应吗？ A: 不是。规则是“一条 QoS 流只能映射到一条 DRB，但多条待遇兼容的 QoS 流可以合并进同一条 DRB”。所谓待遇兼容，指的是 5QI 的转发处理特征（优先级、时延预算、误包率）一致或足够接近，合并后调度器仍能一视同仁。
Q: session-AMBR 和 UE-AMBR 冲突时听谁的？ A: 两者不是同一个维度的闸门：session-AMBR 管单条 PDU 会话的速率上限，UE-AMBR 管这个用户所有会话的总上限，由基站统一执行。用户开三条会话，每条各自受 session-AMBR 限制，三条加起来还不得超过 UE-AMBR——像家里每个水龙头有自己的流量，全家总表还有一道总闸。
本文由「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 等场景全覆盖。