凌晨的地铁车厢里，一万个人同时刷短视频。基站的无线资源就那么点，物理层资源块每一毫秒都在被瓜分。如果网络对所有人一视同仁、完全公平，结果不是"大家都慢一点"，而是灾难性的：刷视频的人只是多等半秒，正在通话的人却可能直接掉字、断句，远程操控的机器可能瞬移。**QoS的本质不是让网络更快，而是在拥堵时明确规定：先保谁、后保谁、谁可以让路、让路的代价是什么。** 这篇文章用一套贯穿始终的类比，讲清5G QoS的核心机制：5QI、GBR与非GBR、ARP、以及反射QoS。类比是——**一家餐厅**：菜单编号（5QI）、包间预订（GBR）、大堂拼桌（非GBR）、经理的插队规则（ARP）、熟客免报菜名（反射QoS）。 ### 一、先回答"为什么"：公平调度为什么不够 最朴素的想法是轮着来：每个用户轮流发一个包，绝对公平。这在轻负载时没问题，但一旦负载超过容量，"绝对公平"意味着语音包和下载包待遇完全一样。语音对时延极度敏感——超过150毫秒，通话双方就开始互相抢话；而视频下载对时延几乎无感，缓存里多几秒内容就行。 所以调度器必须"看包下菜碟"。但问题来了：调度器怎么知道一个包属于通话还是下载？如果每次建业务都要把"时延要求100毫秒、丢容忍1%、速率保底2兆"这些参数从头传一遍，信令开销巨大，而且不同设备厂商对参数的理解还可能有偏差。于是就有了第一个关键设计——**用一个数字代表一整套服务特性**。 ### 二、5QI：一个数字背后的一整张菜单 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）**上，才是空口真正调度的对象。 ```mermaid flowchart TD APP1["语音包"] -->|"UE打上QFI=1"| F1["QoS流1
5QI=1 GBR"] APP2["网页包"] -->|"UE打上QFI=9"| F2["QoS流2
5QI=9 非GBR"] F1 -->|"SDAP映射"| D1["DRB-1
语音专用"] F2 -->|"SDAP映射"| D2["DRB-2
与相邻用户共享"] D1 --> S["gNB调度器
按5QI优先级排队"] D2 --> S S --> P["物理层资源块
每毫秒分蛋糕"] ``` 为什么4G不这样、5G要改成这样？4G的粒度是"承载"（Bearer），一条专用承载的建立要UE、基站、核心网来回多轮信令，业务变化快时根本跟不上。5G把"分类"和"传输"解耦：分类在流级随需而变，传输在承载级保持稳定。**流是逻辑身份证，承载是物理座位**，两层各自演化，灵活性和稳定性都拿到了。 ### 四、GBR与非GBR：包间和大堂 每条QoS流建起来之前，先要回答资源类型问题，这决定了它的命运。 **GBR（保证比特率）流**是包间客人：预订时就锁定保底速率（GFBR），调度器必须先满足它；同时也设了封顶（MFBR），防止包间客人把三个人的饭量吃到十人份。资源不够时怎么办？要么拒绝，要么按ARP规则抢别人的——这是下一节。 **非GBR流**是大堂客人：不预订、不承诺、先到先得。它没有流级的保底和封顶，只受两道"总闸"约束：会话级AMBR（这条PDU会话的总速率上限，由UE和UPF执行）和UE级AMBR（这个用户所有会话加起来的上限，由基站执行）。 | 维度 | GBR流 | 非GBR流 | |---|---|---| | 资源预留 | 接纳时锁定保底速率 | 不预留，尽力而为 | | 流级速率参数 | GFBR保底 + MFBR封顶 | 无，受会话/UE级AMBR总闸约束 | | 接纳控制 | 资源不够可拒绝或抢占 | 基本随到随收 | | 超量部分 | 超过MFBR的包可被丢弃 | 排队竞争，慢但不拒 | | 典型业务 | 语音、视频通话、远程驾驶 | 上网、视频、下载 | 接纳控制的判断逻辑如下： ```mermaid flowchart TD A["VoNR通话请求"] --> B["核心网选定
5QI=1 GBR 保底速率"] B --> C{"gNB剩余容量
够付保底速率吗"} C -->|"够"| D["接纳成功
资源写入调度器"] C -->|"不够"| E{"ARP允许
抢占别人吗"} E -->|"允许"| F["顶掉低优先级流
腾出资源"] E -->|"不允许"| G["拒绝GBR
或降级尽力而为"] D --> H["通话有保底
弱覆盖也稳"] F --> H ``` 接纳的数学约束很简单：所有GBR流的保底之和不能超过小区可用容量—— $$\sum_{i=1}^{n} GFBR_i \le C_{可用}$$ 超过这条线，基站就必须开始"拒客"或"抢座"。这就是为什么高负荷小区里，网管上会看到GBR接纳失败计数器——不是故障，是设计的自我保护。 ### 五、ARP：抢占的门票 ARP（分配与保持优先级）经常和5QI优先级混淆，其实它们管的是两个完全不同的时刻。**5QI优先级是"吃饭时"的调度顺序**——每个包排队时看它；**ARP是"进门时"的座次规则**——资源不够、接纳冲突时才看它。 ARP分15级，1最高，配两个开关： - **抢占能力**：我能不能把别人赶下桌。VoNR语音设为"能"，保证紧急呼叫和高价值语音永远进得来。 - **易损性**：我能不能被别人赶下桌。语音设为"不能"，一旦接纳就坐稳了。 抢占主要发生在GBR资源不足的场景：一条高优先级GBR流到来，可以顶掉低优先级、易损性为"可被抢"的流。被抢的流不是无声消失，会触发释放或重建流程，对应用层表现为一次卡顿或重连——这是设计好的代价交换，不是异常。 ### 六、调度器视角：时延预算怎么花 PDB（时延预算）听起来是"端到端100毫秒"，但基站真正能花的没那么多。标准允许把PDB切两段：一段留给核心网传输段（常见配置按20毫秒左右的量级预留，具体组网可调），剩下的才是空口调度可支配的预算： $$PDB_{空口} = PDB_{5QI} - PDB_{核心网段}$$ 对5QI=1的语音，空口实际预算约80毫秒。调度器据此安排重传次数、目标BLER和混合重传策略：预算紧的流少重传、高优先投递；预算宽的流可以更激进地用低误码率换容量。**同一套资源，不同5QI的流拿到的是完全不同的"花钱策略"。** 每个时隙，调度器的分蛋糕顺序是： ```mermaid flowchart TD T["一个时隙开始"] --> P1["第一遍
GBR流按保底速率
优先投递"] P1 --> C{"还有剩余
资源块吗"} C -->|"有"| P2["第二遍
非GBR按优先级
竞争剩余资源"] C -->|"没有"| W["非GBR排队等待
下个时隙再来"] P2 --> A["会话总闸AMBR检查
超套餐就收口"] ``` 理解了这个顺序，很多现网现象就通了：满负荷小区里语音依然清晰（第一遍保住了保底），而下载速度崩了（第二遍没分到）；轻负荷小区两者都快（第一遍根本吃不完）。 ### 七、反射QoS：熟客不用报菜名 4G给一条业务配置QoS，必须走显式信令：核心网下发、基站转发、UE确认，一来一回。对变化快的业务，这个开销太重。5G想了个聪明的办法——**让UE自己学**。 ```mermaid sequenceDiagram participant F as UPF participant G as gNB participant U as UE F->>G: 下行业务包带QFI=9
和RQI标记 G->>U: 空口转发
SDAP头带RQI Note over U: 记住该业务五元组
对应QFI=9 U->>G: 上行同业务包
自己打QFI=9 G->>F: 按同一规则转发
全程无专用信令 ``` 网络在下行的包上做记号（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流级设计的好处：改的是"流的属性"，不是"传输通道"本身。 ## 参考来源 1. [Quality of service - Wikipedia](https://en.wikipedia.org/wiki/Quality_of_service) — QoS通用概念、调度算法与电信网络区分服务思想的权威概述 2. [5G - Wikipedia](https://en.wikipedia.org/wiki/5G) — 5G网络架构与QoS框架的背景知识 3. [Network slicing - Wikipedia](https://en.wikipedia.org/wiki/Network_slicing) — 切片隔离机制与QoS机制的正交关系 4. [ShareTechnote](https://www.sharetechnote.com/) — 通信工程师常用的5G技术笔记站，含QoS Flow、SDAP映射等专题章节 5. [3GPP官网](https://www.3gpp.org/) — 标准组织官方文档库，可公开检索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 等场景全覆盖。