# 5G QoS原理图解：一张“服务合同”如何管住每一比特 ## 一、从一个日常困境说起：为什么网络需要“分诊台” 想象一家高峰期的三甲医院急诊科：心梗病人、骨折病人、感冒病人同时涌入，医生和床位是有限的。如果按“先来后到”处理，感冒病人可能排在心梗病人前面——这在医疗上是不可接受的。所以医院设置了**分诊台**：先评估每个病人的紧急程度，再决定谁先进抢救室、谁去普通诊室、谁在候诊区等。 移动网络面临完全相同的困境。一个基站下的所有用户**共享**同一块频谱资源：有人在打视频电话，有人在刷短视频，有人在后台下载更新包，还有工厂机械臂在等待一条10毫秒内必须到达的控制指令。如果不加区分地“先来先服务”，视频通话会卡顿、机械臂会失控，而纯粹因为一个用户在BT下载大文件，就把所有人的带宽吃光。 这就是QoS（Quality of Service，服务质量）存在的根本理由：**在共享的、有限的无线的资源上，让不同业务得到与其需求匹配的差异化对待**。某百科对QoS的经典定义是：网络对不同的应用、用户或数据流提供不同优先级，或对某个数据流保证特定性能水平的能力，其衡量维度包括丢包率、速率、时延、抖动等。 一个重要的背景认知：**“保障”的本质是“牺牲”**。网络的容量不会因为QoS而变多，QoS做的只是重新分配——把资源从“不在乎”的业务手里，挪给“很在乎”的业务。理解了这一点，后面所有机制（准入、抢占、限速）都会变得顺理成章。 ## 二、5G QoS的核心抽象：QoS Flow（服务质量流） ### 2.1 为什么4G的“承载”模型被抛弃了 4G LTE的QoS模型建立在“EPS承载”上：一条端到端承载从核心网一路贯通到无线侧，核心网承载、S1承载、无线承载**一一对应**，像一根焊死的管子。这个模型的问题是： - **粒度太粗**：一条承载只能有一个QoS等级，同一个网页里同时有文字、图片、视频，没法分开对待； - **耦合太紧**：核心网必须提前知道无线侧怎么建承载，每加一个业务等级都要全网重新走一遍信令，控制面负担重； - **扩展性差**：5G要同时兼容增强移动宽带、海量物联、高可靠低时延三大场景，等级组合爆炸式增长，一一对应的承载模型撑不住。 5G的做法是**把“QoS的定义”和“资源的分配”解耦**。核心网层面只定义一种轻量的逻辑概念——**QoS Flow（QoS流）**，它是PDU会话内QoS区分的最小粒度，每条流用一个编号 **QFI（QoS Flow Identifier）** 标识，相同QFI的的用户数据获得相同的转发处理。至于这些流在无线侧怎么跑，基站**自己决定**：可以一条QoS流独占一个无线承载（DRB），也可以把多条“胃口相近”的QoS流合并塞进同一个DRB。 这个解耦是5G QoS设计中最优雅的一笔，用一张图看全貌： ```mermaid flowchart TB DN["外部数据网络
(互联网 / IMS语音)"] --> UPF subgraph CORE["5G核心网用户面"] UPF["UPF
下行分类器: 按PDR规则给数据包打QFI标签"] end UPF --> QF1 & QF2 & QF9 subgraph SESSION["一个PDU会话内的三条QoS流(逻辑概念)"] QF1["QoS流1
QFI=1 语音 GBR"] QF2["QoS流2
QFI=2 视频通话 GBR"] QF9["QoS流9
QFI=9 普通上网 Non-GBR"] end QF1 -->|"独占"| DRB1 QF2 & QF9 -->|"合并复用"| DRB2 subgraph RAN["基站 gNB"] SDAP["SDAP子层
决定QoS流到DRB的映射"] DRB1["DRB1"] DRB2["DRB2"] end DRB1 --> UE["终端UE"] DRB2 --> UE ``` 注意图中的关键点：**QoS流是“逻辑管道”，DRB才是“物理车道”**。QoS流描述的是“这股数据需要什么待遇”，DRB描述的是“用什么无线资源配置去兑现”。两者之间由基站里一个叫SDAP的协议子层负责映射，映射关系可以是一对一，也可以是多对一。4G时代那种“核心网建一条承载、无线就必须建一条对应承载”的僵硬绑定，在5G里被彻底打散了。 ### 2.2 QFI是怎么“贴”到数据包上的 QoS流看不见摸不着，真正落到传输上，QFI标签必须随包传递。下上行方向的做法是对称但分工不同的： ```mermaid flowchart LR subgraph DL["下行方向(核心网说了算)"] A["互联网IP包"] --> B["UPF查PDR
(包检测规则)
按IP五元组/端口/协议匹配"] --> C["给包打上QFI标签
封装进GTP-U隧道头"] --> D["gNB的SDAP层
按QFI送入对应DRB"] end subgraph UL["上行方向(终端说了算)"] E["应用产生IP包"] --> F["UE查QoS规则
匹配包过滤器"] --> G["SDAP包头携带QFI
发往基站"] --> H["gNB校验QFI
重新封装送UPF"] end ``` - **下行**由UPF做分类判决。UPF里存着一套“包检测规则”（PDR），根据源/目的IP地址、端口号、协议类型等字段，把每个下行包归入某条QoS流，并把QFI写进封装头； - **上行**由终端（UE）自己判决。终端里存着网络下发的**QoS规则**——本质是一张“什么样的包走哪条流”的查询表。 那终端里的QoS规则从哪来？两个途径：一是网络通过信令明确下发；二是**反射式QoS（Reflective QoS）**——终端观察下行包的QFI标记，**照镜子一样**反推出“对面怎么给我分类的，我上行就照着办”，自己生成对称的上行规则。这个设计的动机是省信令：对于大量短命的应用流（比如一次网页加载产生的几十条流），逐条下发规则的信令开销远大于让终端自学。 还有一个保底设计：**每个PDU会话必须有一条“默认QoS规则”**，它匹配一切包（match-all）、优先级最低、对应一条Non-GBR流。这是为了回答一个致命问题——“如果一个包谁都匹配不上怎么办？”答案是有默认流兜底，永远无家可归的包是不存在的。 ## 三、5QI：一份标准化的“服务等级合同” ### 3.1 一个数字，一整套参数 每条QoS流的核心参数叫**5QI（5G QoS Identifier）**。它的设计哲学是“**用编号代替逐项协商**”：标准预先定义了一组常用的参数组合（叫“标准化5QI”），网络只要告诉基站“这条流是5QI=1”，基站就知道该按什么时延预算、丢包率、优先级去调度，不需要逐个参数传输信令。这大幅压缩了控制面开销，也让不同厂商设备之间对“什么是语音级服务”有了共同语言。 一个5QI背后捆绑的“QoS特性”包括： | 特性参数 | 含义 | 通俗理解 | |---|---|---| | 资源类型 | GBR / Non-GBR / 时延关键GBR | 包不包桌 | | 优先级 | 数字越小优先级越高 | 排队的位次 | | 包时延预算（PDB） | 允许的最大传输时延（含排队） | 限时送达承诺 | | 包误码率（PER） | 允许的最大丢包比例 | 允许摔坏几件货 | | 平均时间窗 | 评估速率的时间粒度（仅GBR类） | 按多长时间算平均 | | 最大数据突发量（MDBV） | 单次允许的最大突发字节数（仅时延关键GBR） | 一次最多塞多少件 | 下表摘录几个最常见的标准化5QI，可以直观看到不同业务的“待遇差”有多大： | 5QI | 典型业务 | 资源类型 | 默认优先级 | 时延预算PDB | 误码率PER | |---|---|---|---|---|---| | 1 | 会话式语音（VoNR） | GBR | 20 | 100 ms | 10⁻² | | 2 | 会话式视频 | GBR | 40 | 150 ms | 10⁻³ | | 3 | 实时游戏 | GBR | 40 | 50 ms | 10⁻³ | | 5 | IMS信令 | Non-GBR | 10 | 100 ms | 10⁻⁶ | | 7 | 视频/互动游戏流 | Non-GBR | 30 | 100 ms | 10⁻³ | | 8 | 默认互联网业务 | Non-GBR | 80 | 300 ms | 10⁻⁶ | | 9 | 默认互联网业务（最常用） | Non-GBR | 60 | 300 ms | 10⁻⁶ | | 82 | 离散自动化（工业） | 时延关键GBR | 19 | 10 ms | 10⁻⁴ | 读这张表有几个“为什么”值得咀嚼： - **为什么语音（5QI=1）的丢包容忍度（10⁻²）反而比上网（5QI=9的10⁻⁶）宽松一个数量级？** 因为人耳对偶发丢帧有很强的容错（丢失20ms的语音片段听不出来），但网页文件丢一个包就要触发重传甚至卡顿。QoS参数从来不是“越严越好”，而是**贴合业务的生理/协议特性**； - **为什么IMS信令（5QI=5）误码率要求最苛刻（10⁻⁶）？** 信令丢了会导致注册失败、呼叫建立失败等连锁故障，宁可慢一点也不能错； - **为什么优先级数字要设计成“越小越高”？** 纯粹是工程习惯（类似Linux的nice值反向），但它是新手最常见的记忆陷阱，后文还会强调。 除了标准化5QI，运营商也可以自定义“非标5QI”，此时完整的参数集要随信令逐项下发，灵活性更高但开销更大。 ## 四、GBR与Non-GBR：包桌与排队的资源分配哲学 ### 4.1 两种资源类型，两种命运 5G把QoS流的资源类型分成三类，这是整个QoS体系的分水岭： | 对比维度 | GBR（保证比特率） | Non-GBR（非保证比特率） | 时延关键GBR | |---|---|---|---| | 核心承诺 | 保底速率GFBR一定给到 | 不承诺速率，只排优先级 | 保底速率+极短时延 | | 速率上限 | MFBR封顶 | Session-AMBR / UE-AMBR封顶 | MFBR封顶+突发量MDBV约束 | | 建立时要准入检查吗 | **要**，资源不够就拒绝或抢占 | 不要，直接建 | 要，且更严格 | | 资源不够时 | 网络发通知（QNC），可能改参数或释放 | 靠调度优先级“软性”区分 | 立即上报，容忍度极低 | | 典型业务 | VoNR语音、视频通话 | 上网、下载、流媒体 | 工业控制、智能电网 | 用餐厅类比：**GBR是订座包桌**——进门时服务员先查有没有空位，有位才让你进，进了就保证你有桌子；**Non-GBR是排队叫号**——不查位子随便进，大家抢公共座位，抢不抢得到看运气和“VIP等级”（优先级）。 两个关键参数由此登场： - **GFBR（保证流比特率）**：运营商经评估后给出的“这条业务低于此速率就无法存活”的最低速率，网络承诺在平均时间窗内保证它； - **MFBR（最大流比特率）**：该流允许的最高速率，防止GBR流反过来吃掉别人。 ### 4.2 准入控制：GBR流的“查位子”机制 GBR流建立时，基站必须做**准入控制（Admission Control）**——这是GBR承诺的字面兑现手段。数学上是一个极简的不等式： $$\sum_{i \in \text{已建立GBR流}} GFBR_i + GFBR_{\text{新流}} \le C_{\text{admission}}$$ 其中 $C_{\text{admission}}$ 是基站根据当前负载、频谱效率估算出的“可保障容量”（注意它不是小区总容量，而是打了保守折扣、确保承诺能兑现的部分）。等式不成立时，新流被拒绝，或者——如果它的ARP优先级够高——**抢占**踢掉一条低优先级的已建流。 准入之后是运行期的兑现，基站的调度器像一个同时盯着多个计时器的空中管制员： ```mermaid flowchart TD A["新GBR流到达
申请资源"] --> B{"准入检查:
存量GFBR之和 + 新流GFBR
是否≤可保障容量?"} B -- "不够" --> C["拒绝建立
或按ARP规则抢占低优先级流"] B -- "够" --> D["接受该流, 预留资源"] D --> E["运行期逐周期调度"] E --> F{"该流本窗口内
GFBR还差多少?"} F -- "没达标" --> G["优先调度该流
先补足保底速率"] F -- "已达标" --> H["剩余资源分给Non-GBR
按优先级+公平性调度"] G --> I{"持续无法满足GFBR?"} I -- "是" --> J["向核心网发QoS通知
可能调整参数或释放流"] I -- "否" --> E H --> E ``` 这里藏着GBR模型最重要的“诚实条款”：**承诺是有条件的**。无线信道是波动的，用户可能开进电梯井、走到小区边缘。一旦基站发现自己确实兑现不了GFBR承诺，它不是硬撑着装没事，而是通过QoS通知机制上报核心网（前提是该流开启了通知控制QNC），让网络决定是降级、改参数还是释放。这就是“保证”的边界——**保证的是网络尽力维持的资源优先权，不是物理定律层面的绝对承诺**。 ### 4.3 AMBR：给贪吃龙的封口罩 Non-GBR流没有准入、没有保底，那怎么防止它把小区资源榨干？答案是两层**聚合最大比特率（AMBR）**限速： $$R_{\text{UE实际}} = \min\left(r_{\text{业务需求}},\ \text{Session-AMBR},\ \text{UE-AMBR}\right)$$ - **Session-AMBR**：单个PDU会话内所有Non-GBR流的总速率上限； - **UE-AMBR**：该终端所有会话加起来的总上限，由网络侧动态计算下发。 两个上限取最小值生效。这个设计的精妙之处在于**分层封顶**：会话级管住“单个应用别闹”，终端级管住“单个用户别闹”，剩下的资源天然留给了GBR流和别的用户。现实中运营商的“套餐限速”（比如达量降速到1Mbps）绝大多数就是通过调低AMBR实现的——这是QoS参数直接变成商业产品的例子。 ### 4.4 ARP：抢占机制，拥挤时的“谁下飞机” **ARP（分配与保持优先级）**是独立于5QI之外的一组参数，包含三个字段： 1. **优先级等级（1~15，1最高）**：决定资源竞争时的地位； 2. **抢占能力**：我能不能在资源不足时挤掉别人； 3. **被抢占脆弱性**：我能不能被别人挤掉。 为什么ARP不并入5QI？因为**业务特性（5QI）和运营策略（ARP）是两码事**。同样是5QI=1的语音，消防员的呼叫电话理应比普通用户的更难被挤掉——这个差异化无法从业务类型推出来，只能由运营商策略决定。所以标准把两者拆开：5QI描述“这个业务需要什么”，ARP描述“它配得到什么地位”。 抢占的运行图景类似航班超售后的处理：新来的头等舱旅客（高优先级+允许抢占）可以要求经济舱旅客（低优先级+可被抢占）下机；但一个标了“不可被抢占”的旅客，哪怕只有经济舱票，别人也不能动他。现网的最佳实践之一，就是给关键业务（应急通信、工业控制）配置“不可被抢占”标志。 ## 五、一次真实的QoS建立：信令时序全流程 把前面的概念串成一条时间线。下图是一次PDU会话建立时，QoS相关信息如何到达网络各节点（结合现网抓包常见的消息流简化绘制）： ```mermaid sequenceDiagram participant UE as UE终端 participant gNB as 基站gNB participant AMF as AMF(移动性管理) participant SMF as SMF(会话管理) participant UPF as UPF(用户面) UE->>AMF: 请求建立PDU会话 AMF->>SMF: 转交会话创建 SMF->>SMF: 向策略网关取授权参数
生成QFI、QoS规则、PDR SMF->>UPF: 下发PDR+转发规则(核心网侧分类依据) SMF->>gNB: 经AMF下发QoS档案(5QI/ARP/Session-AMBR) SMF->>UE: 经AMF下发QoS规则+默认规则+Session-AMBR gNB->>gNB: SDAP建立QFI到DRB映射
做GBR准入检查 gNB->>UE: RRC重配置: 建DRB并配置SDAP UE-->>gNB: 无线承载配置完成 gNB-->>AMF: 资源建立响应(含接受的QFI列表) Note over UE,UPF: 此后每个数据包按QFI标签
全链路获得一致的转发待遇 ``` 一个真实现网抓包的典型样貌（数值来自公开的仿真日志示例）：会话建立请求里携带下行5Gbps/上行2Gbps的会话AMBR，QoS流QFI=1引用标准化5QI=9，ARP优先级15、不触发抢占、不可被抢占；下发的默认QoS规则是“匹配一切包、规则优先级255、指向QFI=1”。所有本文讲过的概念——5QI、ARP三字段、AMBR、默认规则——在这短短几条消息里全部现身。 ## 六、QoS与网络切片：分层分工的两套体系 经常有工程师把切片和QoS流混为一谈，其实它们是**不同粒度、不同目的**的两层机制： - **网络切片（S-NSSAI标识）**是**资源与策略的隔离分区**，从传输网、核心网网元到无线资源做逻辑切分， slice与slice之间互不借用资源，服务于“给不同行业/客群开专用车道”的商业模式； - **QoS流**是**分区内部的等级细分**，一条切片内的不同业务流依然要靠5QI/GBR机制排出先后。 打个比方：切片是**滑雪场分隔出的高级道、中级道、初级道**（物理隔离，互不干扰）；QoS流是**同一条雪道上的索道优先权**（同一场地内，谁先上缆车）。两者正交：一个切片内有多种5QI的流，同一种5QI也可以出现在多个切片里。终端发起会话时同时携带S-NSSAI和QoS参数，先选道、再排序。 ## 七、现网实战：这些原理用在哪里，坑在哪里 ### 7.1 调试场景对照 - **VoNR语音质量排查**：先确认语音媒体流是否真的建立在5QI=1的GBR流上（看会话接受的QFI列表和QoS档案）。常见故障是呼叫回落到了Non-GBR流上“裸奔”，信令看着都通，但弱场下没有保底速率，MOS分断崖式下跌； - **“网速慢”工单定位**：第一步不是看信号，而是**查AMBR**。如果UE-AMBR被套餐策略压到了1Mbps，无线环境再好也是1Mbps。判断方法是实测速率是否稳定地卡在一个“太整齐”的数值上（如恰好1M/3M/5M），这是限速的典型指纹； - **切换后业务劣化**：切换到新小区时，GBR流要在目标小区**重新过一遍准入**。目标小区GBR资源紧张时，语音流可能被拒绝（导致掉话）或降级。分析切换失败时，要区分“无线链路失败”和“接纳失败”两种完全不同的根因； - **工业专网部署**：时延关键GBR（如5QI=82，10ms预算）对**抖动**极度敏感，部署时必须核算MDBV——突发量超过承诺值，超出部分不在保障范围内，很多“明明是GBR为什么还超时”的案例根因就是突发量超标。 ### 7.2 常见误解清单 1. **“优先级80比60高”** —— 恰恰相反，5QI默认优先级和ARP优先级都是**数字越小、等级越高**。5QI=8（优先级80）的实际调度地位低于5QI=9（优先级60）； 2. **“GBR=网速有保证”** —— GBR保证的是**GFBR这个保底线**，不是你想要的峰值速率。峰值照样受MFBR和AMBR双重封顶； 3. **“切片建好了业务自动有保障”** —— 切片只提供隔离分区，分区内的业务保障依然要靠逐条的QoS流参数正确配置。切片是必要条件，不是充分条件； 4. **“QoS参数全靠网络侧配置”** —— 上行分类取决于终端里的QoS规则，规则下发失败或反射式QoS推导出错，会出现“下行畅、上行卡”的单向劣化，这类问题从基站侧日志经常看不出来，要抓终端侧NAS信令； 5. **“误码率参数越严越好”** —— PER要求过严会逼调度器用更保守的编码冗余，反而拉低频谱效率。参数设计永远围绕业务真实特性，不是拍脑袋收紧。 ## 八、总结：QoS的本质是一套“诚实的承诺管理”体系 回头看5G QoS的全貌，每个机制都在回答同一个问题：**当资源不够时，网络依据什么、按什么顺序、兑现哪些承诺**—— - **QoS Flow/QFI** 回答“承诺对象是谁”：细粒度、可合并、核心网与无线网解耦； - **5QI** 回答“承诺内容是什么”：标准化的速率/时延/误码组合，一个数字讲清楚； - **GBR+准入控制** 回答“承诺如何兑现”：先查位子再入座，查不到就诚实拒绝； - **ARP** 回答“承诺发生冲突时谁让路”：抢占与被抢占，把运营策略与业务特性解耦； - **AMBR** 回答“无承诺者的天花板”：分层限速，保住有承诺者的资源； - **QNC通知** 回答“承诺兑现不了怎么办”：不硬撑，如实上报，让上层决策。 它不创造任何新容量，它只是把“稀缺”这件事变得**有规则、可预期、可运营**。理解了这一点，再去读任何QoS参数、任何信令字段，你看到的都不再是枯燥的表格，而是一整套关于“稀缺资源如何公平而高效地分配”的工程智慧。 ## 常见问题 **Q1：QFI和5QI到底有什么区别？老是分不清。** A：QFI是**流的编号**（名字），在一个PDU会话内唯一，作用是让每个数据包“报出自己属于哪条流”；5QI是**特性模板的编号**（等级），作用是一句话声明这条流需要什么待遇。一条会话里可以有多条QFI不同的流共用同一个5QI（比如两条都是5QI=9的流），但它们QFI不同、是两条独立的流。类比：QFI是“3号桌客人”，5QI是“他们订的是A套餐”。 **Q2：GBR流的GFBR兑现不了，用户会立刻掉话吗？** A：不会立刻。基站先通过QoS通知机制上报核心网（前提是流开启了通知控制），核心网可以改参数、降级为Non-GBR、或维持现状继续观察。掉话与否取决于后续决策，而非单次无法达标。所以日志里看到QoS通知不等于故障，它恰恰是体系在“诚实履约”。 **Q3：网络切片和GBR是不是一回事？有切片是不是就不需要GBR了？** A：不是一回事，也不能互相替代。切片是**资源隔离分区**（滑雪场的不同雪道），GBR是**分区内的资源保底**（雪道上的索道优先权）。切片内的业务照样需要5QI/GBR参数来区分等级；反过来，只有GBR没有切片，业务之间依然是共享资源的，做不到行业级的隔离与专用容量承诺。 **Q4：为什么优先级是数字越小越高？这反直觉的设计为什么不改？** A：这是延续自早期电信系统（以及类似Unix nice值）的历史惯例，5G标准化时为了与4G参数体系平滑互通沿用了下来。可以记一个统一口诀：**5QI默认优先级、ARP优先级、QoS规则优先级，全部“小数大权”**。调试时把这条写进checklist，能避免一大批方向性误判。 **Q5：套餐“达量限速”在技术上是怎么实现的？** A：绝大多数是通过调低该用户的UE-AMBR实现的。AMBR是Non-GBR流量的总闸门，由网络侧按签约数据计算下发，不需要逐条流限速。这也解释了为什么限速后“信号满格但还是慢”——因为瓶颈根本不在无线信道，而在策略层的速率封顶。 ## 参考来源 1. [NR QoS (Quality of Service) — ShareTechnote](https://www.sharetechnote.com/html/5G/5G_QoS.html) — QoS结构、QFI标记、PDR/QoS规则分类机制及完整现网信令日志实例，本文信令流程与抓包示例的主要来源 2. [5G Quality of Service — Devopedia](https://devopedia.org/5g-quality-of-service) — QoS Flow模型、5QI参数体系、GBR/Non-GBR分类、反射式QoS及4G/5G承载模型对比，标准化5QI参数值来源 --- > 本文由「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 等场景全覆盖。