凌晨的地铁车厢里，一万个人同时刷短视频。基站的无线资源就那么点，物理层资源块每一毫秒都在被瓜分。如果网络对所有人一视同仁、完全公平，结果不是"大家都慢一点"，而是灾难性的：刷视频的人只是多等半秒，正在通话的人却可能直接掉字、断句，远程操控的机器可能瞬移。QoS的本质不是让网络更快，而是在拥堵时明确规定：先保谁、后保谁、谁可以让路、让路的代价是什么。
这篇文章用一套贯穿始终的类比，讲清5G QoS的核心机制：5QI、GBR与非GBR、ARP、以及反射QoS。类比是——一家餐厅：菜单编号（5QI）、包间预订（GBR）、大堂拼桌（非GBR）、经理的插队规则（ARP）、熟客免报菜名（反射QoS）。
最朴素的想法是轮着来：每个用户轮流发一个包，绝对公平。这在轻负载时没问题，但一旦负载超过容量，"绝对公平"意味着语音包和下载包待遇完全一样。语音对时延极度敏感——超过150毫秒，通话双方就开始互相抢话；而视频下载对时延几乎无感，缓存里多几秒内容就行。
所以调度器必须"看包下菜碟"。但问题来了：调度器怎么知道一个包属于通话还是下载？如果每次建业务都要把"时延要求100毫秒、丢容忍1%、速率保底2兆"这些参数从头传一遍，信令开销巨大，而且不同设备厂商对参数的理解还可能有偏差。于是就有了第一个关键设计——用一个数字代表一整套服务特性。
5QI（5G QoS Identifier）就是一个标量数字。核心网在建立业务时只需告诉基站"这是5QI=1"，基站去查标准化的对照表，就知道这条流的全部特性：资源类型、优先级、时延预算、丢包率容忍。就像餐厅报"7号餐"，后厨立刻知道火候、出餐时间、摆盘标准，不需要每次重新描述菜谱。
标准化5QI的典型取值如下：
| 5QI | 资源类型 | 优先级 | 时延预算PDB | 丢包率容忍PER | 典型业务 |
|---|---|---|---|---|---|
| 1 | GBR | 20 | 100 ms | 10⁻² | VoNR语音 |
| 2 | GBR | 40 | 150 ms | 10⁻³ | 视频通话 |
| 3 | GBR | 30 | 50 ms | 10⁻³ | 实时对战游戏 |
| 4 | GBR | 50 | 300 ms | 10⁻⁶ | 点播视频缓冲 |
| 5 | 非GBR | 10 | 100 ms | 10⁻⁶ | IMS信令 |
| 7 | 非GBR | 70 | 100 ms | 10⁻³ | 互动直播 |
| 9 | 非GBR | 90 | 300 ms | 10⁻⁶ | 普通上网（默认） |
注意两件事：优先级数值越小越优先；另有一类"时延关键GBR"，PDB压到十几毫秒量级，专门服务工业实时控制这类硬实时场景。
丢包率容忍PER的定义很直白：
$$PER = \frac{\text{超时或丢弃的包}}{\text{总包数}} \le 10^{-2}$$
语音的PER是10⁻²，意思是每100个包允许丢1个——即使是GBR语音，也从来不是"零丢包金牌"，这是一个常见误解。容错率定得宽，是为了让编码器能做丢包隐藏（丢了就靠前后帧插值补），把宝贵的重传资源省下来。
为什么用"索引"而不是传参数？三个原因：一是省信令，一个字节搞定一整套QoS描述；二是保证互通一致性，漫游时两国的设备对"7号餐"的理解完全一致，因为菜单是标准化的；三是保留灵活性——标准编号之外还允许运营商预定义一组自己的编号，行业专网里给特定设备定制"私房菜"就是这么做的。
5G的数据通道是三层嵌套的。手机开机后与网络建立一条PDU会话（相当于你在餐厅占了个座、开了台），所有流量都从这条会话走。会话内部再按业务拆成一条条QoS流——语音一条流、上网一条流、信令一条流，每条流有独立编号QFI，有独立的5QI。最后每条QoS流映射到一条或多条无线承载（DRB）上，才是空口真正调度的对象。
flowchart TD
APP1["语音包"] -->|"UE打上QFI=1"| F1["QoS流1<br/>5QI=1 GBR"]
APP2["网页包"] -->|"UE打上QFI=9"| F2["QoS流2<br/>5QI=9 非GBR"]
F1 -->|"SDAP映射"| D1["DRB-1<br/>语音专用"]
F2 -->|"SDAP映射"| D2["DRB-2<br/>与相邻用户共享"]
D1 --> S["gNB调度器<br/>按5QI优先级排队"]
D2 --> S
S --> P["物理层资源块<br/>每毫秒分蛋糕"]
为什么4G不这样、5G要改成这样？4G的粒度是"承载"（Bearer），一条专用承载的建立要UE、基站、核心网来回多轮信令，业务变化快时根本跟不上。5G把"分类"和"传输"解耦：分类在流级随需而变，传输在承载级保持稳定。流是逻辑身份证，承载是物理座位，两层各自演化，灵活性和稳定性都拿到了。
每条QoS流建起来之前，先要回答资源类型问题，这决定了它的命运。
GBR（保证比特率）流是包间客人：预订时就锁定保底速率（GFBR），调度器必须先满足它；同时也设了封顶（MFBR），防止包间客人把三个人的饭量吃到十人份。资源不够时怎么办？要么拒绝，要么按ARP规则抢别人的——这是下一节。
非GBR流是大堂客人：不预订、不承诺、先到先得。它没有流级的保底和封顶，只受两道"总闸"约束：会话级AMBR（这条PDU会话的总速率上限，由UE和UPF执行）和UE级AMBR（这个用户所有会话加起来的上限，由基站执行）。
| 维度 | GBR流 | 非GBR流 |
|---|---|---|
| 资源预留 | 接纳时锁定保底速率 | 不预留，尽力而为 |
| 流级速率参数 | GFBR保底 + MFBR封顶 | 无，受会话/UE级AMBR总闸约束 |
| 接纳控制 | 资源不够可拒绝或抢占 | 基本随到随收 |
| 超量部分 | 超过MFBR的包可被丢弃 | 排队竞争，慢但不拒 |
| 典型业务 | 语音、视频通话、远程驾驶 | 上网、视频、下载 |
接纳控制的判断逻辑如下：
flowchart TD
A["VoNR通话请求"] --> B["核心网选定<br/>5QI=1 GBR 保底速率"]
B --> C{"gNB剩余容量<br/>够付保底速率吗"}
C -->|"够"| D["接纳成功<br/>资源写入调度器"]
C -->|"不够"| E{"ARP允许<br/>抢占别人吗"}
E -->|"允许"| F["顶掉低优先级流<br/>腾出资源"]
E -->|"不允许"| G["拒绝GBR<br/>或降级尽力而为"]
D --> H["通话有保底<br/>弱覆盖也稳"]
F --> H
接纳的数学约束很简单：所有GBR流的保底之和不能超过小区可用容量——
$$\sum_{i=1}^{n} GFBR_i \le C_{可用}$$
超过这条线，基站就必须开始"拒客"或"抢座"。这就是为什么高负荷小区里，网管上会看到GBR接纳失败计数器——不是故障，是设计的自我保护。
ARP（分配与保持优先级）经常和5QI优先级混淆，其实它们管的是两个完全不同的时刻。5QI优先级是"吃饭时"的调度顺序——每个包排队时看它；ARP是"进门时"的座次规则——资源不够、接纳冲突时才看它。
ARP分15级，1最高，配两个开关：
抢占主要发生在GBR资源不足的场景：一条高优先级GBR流到来，可以顶掉低优先级、易损性为"可被抢"的流。被抢的流不是无声消失，会触发释放或重建流程，对应用层表现为一次卡顿或重连——这是设计好的代价交换，不是异常。
PDB（时延预算）听起来是"端到端100毫秒"，但基站真正能花的没那么多。标准允许把PDB切两段：一段留给核心网传输段（常见配置按20毫秒左右的量级预留，具体组网可调），剩下的才是空口调度可支配的预算：
$$PDB_{空口} = PDB_{5QI} - PDB_{核心网段}$$
对5QI=1的语音，空口实际预算约80毫秒。调度器据此安排重传次数、目标BLER和混合重传策略：预算紧的流少重传、高优先投递；预算宽的流可以更激进地用低误码率换容量。同一套资源，不同5QI的流拿到的是完全不同的"花钱策略"。
每个时隙，调度器的分蛋糕顺序是：
flowchart TD
T["一个时隙开始"] --> P1["第一遍<br/>GBR流按保底速率<br/>优先投递"]
P1 --> C{"还有剩余<br/>资源块吗"}
C -->|"有"| P2["第二遍<br/>非GBR按优先级<br/>竞争剩余资源"]
C -->|"没有"| W["非GBR排队等待<br/>下个时隙再来"]
P2 --> A["会话总闸AMBR检查<br/>超套餐就收口"]
理解了这个顺序，很多现网现象就通了：满负荷小区里语音依然清晰（第一遍保住了保底），而下载速度崩了（第二遍没分到）；轻负荷小区两者都快（第一遍根本吃不完）。
4G给一条业务配置QoS，必须走显式信令：核心网下发、基站转发、UE确认，一来一回。对变化快的业务，这个开销太重。5G想了个聪明的办法——让UE自己学。
sequenceDiagram
participant F as UPF
participant G as gNB
participant U as UE
F->>G: 下行业务包带QFI=9<br/>和RQI标记
G->>U: 空口转发<br/>SDAP头带RQI
Note over U: 记住该业务五元组<br/>对应QFI=9
U->>G: 上行同业务包<br/>自己打QFI=9
G->>F: 按同一规则转发<br/>全程无专用信令
网络在下行的包上做记号（RQI），UE看到记号，就把"这个五元组的业务对应QFI=9"记在小本本上，之后上行同类业务自己贴同样的标签。就像熟客常点7号餐，服务员看一眼就直接上，客人不用每次开口。网络任何时候都可以用显式信令覆盖UE自己推的规则——学习只是默认，指令永远更高。
对比4G，这是粒度上的质变：QoS规则的生效从"建一条承载"变成"看一个包"，信令成本几乎归零，业务可以随起随灭。
一句话分工：切片决定你进哪个包间区，5QI决定区里谁先坐。切片（S-NSSAI选定）解决的是资源池的隔离——政企专网用专属切片，和公众用户物理逻辑上分开；而进到同一个资源池内部，谁先谁后、谁有保底，就全靠QoS流和5QI这套机制。两者是正交的两层设计，切片管"分组隔离"，QoS管"组内排序"，不要混为一谈。
排障第一刀：测速不足先查AMBR。 "办了500M套餐只跑出300M"，空口没问题的大多数情况，是核心网按套餐给会话下发了Session-AMBR总闸。先查会话建立信令里的AMBR值，再去看空口。
语音投诉看QFI是不是真GBR。 VoNR的语音流应当是5QI=1的GBR。若接纳失败被降级成尽力而为，通话表面还在继续，但弱覆盖区先崩、MOS先跌。查网管的GBR接纳失败计数和QFI参数，能提前发现这类"隐形降级"。
分清三个"优先级"。 调度排队看5QI优先级，进门抢占看ARP，用户之间的总量约束看AMBR。三者混着看是新手最常见的调试陷阱——把ARP当调度优先级调，怎么调都不见效。
常见误解清单： - "GBR流不丢包"——错，语音PER是10⁻²，GBR保的是速率下限和时延预算，不是零丢包。 - "优先级数值大的是高优先级"——错，数值越小越优先，5QI=1的20比5QI=9的90优先得多。 - "AMBR是每条流的限速"——错，AMBR是会话级或UE级的聚合总闸，单条非GBR流没有自己的流级限速。 - "反射QoS学错了就一直错下去"——错，显式信令随时可以覆盖它，排查上下行不对称时先确认UE是否收到了RQI标记、网络侧策略是否一致。
Q: 5QI和4G的QCI有什么区别？ A: 思想一脉相承（都是"编号查表"），但5G的粒度和灵活性大幅提升：参数集增加了最大突发量MDBV和平均窗口（对GBR尤其重要）；配置方式除了显式信令，新增了反射QoS；承载粒度从较粗的EPS承载变为更细的QoS流，业务随需分类，不再依赖建承载。
Q: GBR保证的到底是带宽还是时延？ A: 两者都管，但机制不同。速率上有GFBR保底、MFBR封顶，靠接纳控制和资源预留兑现；时延和丢包是5QI特性表里的PDB和PER，靠调度策略兑现。所以严格说，GBR是"速率承诺"，5QI是"体验配方"，合起来才是完整的体验保障。
Q: ARP优先级和5QI优先级到底谁说了算？ A: 不同时刻谁都说得算。平时发包调度，只看5QI优先级；只有接纳决策和资源冲突（抢占）时才看ARP。可以理解为5QI优先级是"日常排队规则"，ARP是"紧急状态下的座次特权"。
Q: 为什么我的手机聊天软件信令总是秒到，数据却时快时慢？ A: 信令走的是5QI=5（优先级10，全场最高），数据走的是5QI=9（优先级90）。设计者明确要让"能恢复一切的信令"永远最快到达——哪怕在拥塞时，消息发得出去、页面刷不出来，正是这套机制在工作。
Q: 一条流能从非GBR升级成GBR吗？ A: 能。QoS流的参数可以在会话存续期间修改，典型场景是语音业务从聊天状态进入通话状态，网络重新发起QoS流建立并走接纳控制。这正体现了5G流级设计的好处：改的是"流的属性"，不是"传输通道"本身。
本文由「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 等场景全覆盖。