# 图解5G QoS：5QI与GBR的分配机制 ## 一、为什么需要QoS：共享管道的根本矛盾 想象一条双向四车道的高速公路，所有车辆混行：救护车、公交车、快递车、私家车挤在一起。如果完全“先到先走”，一旦车流变大，救护车会被堵在中间——它的任务就会失败。 蜂窝网络本质上是这样一个共享系统：一个小区的频谱资源被所有用户瓜分，基站调度器（Scheduler）每1毫秒都要做一个决定——**下一个时隙把资源分给谁**。如果调度器只有一条原则“谁信号好给谁”，那么网页和视频会跑得飞快，而一通语音电话可能断断续续、一个工业机器人的控制指令可能迟到100毫秒——尽管它们的“业务重要性”完全不同。 QoS（Quality of Service，服务质量）就是给这个共享系统引入的**分诊机制**。它的目标不是“让所有人都更快”，而是**让不同需求的数据流得到不同等级的对待**：语音要低时延低丢包，视频直播要稳定带宽，微信聊天则“能用就行”。理解QoS，本质上是理解三个问题： 1. 网络怎么**描述**一条流的需求？（→ 5QI） 2. 网络怎么**承诺**资源？（→ GBR / Non-GBR） 3. 资源不够时**谁让路**？（→ ARP与调度） --- ## 二、从EPS承载到QoS流：5G为什么推翻了4G的模型 ### 2.1 4G的困境：每个流一条“专用管道” 4G LTE里，一条业务流要获得QoS保障，必须建立一条**EPS承载（EPS Bearer）**。承载是端到端的“管道”：UE到PDN网关之间为这条流专门建立一条隧道，标上一个承载ID（EBI）。这套模型的问题在于： - 承载ID是8比特，全网最多**256条承载**，对物联网和工业场景远远不够； - 每建一条承载，UE、基站、核心网三方都要走一遍NAS/RRC/承载修改信令，**信令开销大、建立时延高**； - 基站只能通过承载ID识别流，灵活性差——想给某个流临时换个调度权重？对不起，先改承载。 ### 2.2 5G的解法：把QoS标记从“管道”搬到“包”上 5G做了一个漂亮的重构：**不再为每条流建端到端管道，而是把QoS身份印在每个数据包上**。这个身份就是**QFI（QoS Flow Identifier，QoS流标识）**。 ```mermaid flowchart TB subgraph Legacy["4G模型：管道式"] A1[业务流1] --> B1[EPS Bearer 1
端到端专用隧道] A2[业务流2] --> B2[EPS Bearer 2
端到端专用隧道] A3[业务流3] --> B3[EPS Bearer 3
端到端专用隧道] B1 --> C1[每条承载一次
端到端信令] end subgraph NR["5G模型：贴标签式"] D1[业务流1] --> E[汇聚到
一条PDU会话] D2[业务流2] --> E D3[业务流3] --> E E --> F1[包1: QFI=1] E --> F2[包2: QFI=7] E --> F3[包3: QFI=9] F1 --> G[同一条无线承载
QoS靠包头标签识别] end ``` 对比一下两种设计的差异： | 维度 | 4G EPS承载 | 5G QoS流 | |---|---|---| | QoS载体 | 端到端隧道（承载ID） | 每个包头携带QFI | | 数量上限 | 承载ID 8比特，≤256条 | 理论无上限（一个PDU会话内） | | 新增一条流 | NAS+RRC+核心网全套信令 | 多数情况**无需信令**（反射式QoS） | | 识别位置 | 靠隧道/GTP-U TEID | 靠SDAP层打的QFI标签 | | 流→无线承载 | 1条承载≈1条DRB | 多条QoS流可复用1条DRB | 这个设计的精髓是：**控制面只负责“定义QoS规则”，数据面用标签自证身份**。基站收到一个带QFI=1的包，立刻知道它是语音、该走哪条调度队列，不需要为它单独建隧道。 --- ## 三、5QI：一套“预配方”编号系统 ### 3.1 为什么不直接下发参数？ 描述一条流的QoS，理论上需要一长串参数：时延预算多少？丢包率容忍多少？要不要保障带宽？调度优先级多少？如果每个用户每条流都要核心网下发这十几个参数，控制面会被参数配置淹没。 5G的做法和“餐厅点菜”一样聪明：**把最常见的QoS组合编上号**。你说“5QI=1”，网络所有人都明白——这是对话语音，100毫秒时延预算，1%丢包容忍。这就是**标准化5QI**：一个标量值，展开成一组完整的QoS特征，全网设备（基站、UPF、UE）内置同一张对照表，**不需要任何参数传递**。 一个5QI值对应的“配方”包括： | 配方成分 | 含义 | 通俗理解 | |---|---|---| | 资源类型 | GBR / Non-GBR / 延迟关键GBR | 要不要承诺带宽 | | PDB（包时延预算） | 包从UE到UPF的时延上限 | “这单最迟多久送达” | | PER（包错误率） | 允许的丢包/错包比例 | “丢几件算正常损耗” | | 默认优先级 | 数值越小越优先 | “插队资格” | | 平均窗口 | 统计保障速率的时间窗 | “考核周期多长” | | MDBV（最大数据突发量） | 一次允许的最大突发字节数 | 仅延迟关键类有，“一次最多打包多大件” | ### 3.2 常用标准化5QI速查 | 5QI | 资源类型 | 典型业务 | PDB | PER | 默认优先级 | |---|---|---|---|---|---| | 1 | GBR | 会话语音（VoNR） | 100 ms | 10⁻² | 20 | | 2 | GBR | 视频通话（实时） | 150 ms | 10⁻³ | 40 | | 3 | GBR | 实时游戏、V2X | 50 ms | 10⁻³ | 30 | | 5 | Non-GBR | IMS信令 | 100 ms | 10⁻⁶ | 10 | | 6 | Non-GBR | 视频缓冲播放 | 300 ms | 10⁻⁶ | 60 | | 7 | Non-GBR | 语音/直播流媒体 | 100 ms | 10⁻³ | 70 | | 8 | Non-GBR | 普通上网 | 300 ms | 10⁻⁶ | 80 | | 9 | Non-GBR | 默认承载流 | 300 ms | 10⁻⁶ | 90 | 读这张表有两个“反直觉”的点值得注意： - **语音的丢包容忍（10⁻²）反而是最宽松的**——因为语音编解码器对丢包有鲁棒性，丢1%的包听不出来；而它对**时延**极度敏感（超过150毫秒人耳就能感到对话“撞车”）。PDB和PER的组合是为业务特性量身定制的，不是“越严越好”。 - **IMS信令（5QI=5）虽然不需要保障带宽，但优先级（10）高于所有GBR业务**——因为信令不通，业务根本建立不起来。优先级和资源保障是两个独立维度，这是很多初学者混淆的地方。 除了标准化5QI，运营商还可以使用**动态5QI**（编号256起）：由策略控制功能（PCF）逐参数下发完整的QoS特征集，用于定制化切片或专网场景。 --- ## 四、GBR与Non-GBR：承诺式与尽力而为 ### 4.1 两种“商业模式” GBR与Non-GBR的区别，可以用**餐厅订座**来类比： - **Non-GBR（不保障比特速率）**：就像去大排档——有座就坐，没座站着等，餐厅不向你承诺任何东西。网络对这种流的态度是“尽力而为”：带宽富余你就快，拥塞你就慢，**网络不为你的速率负责**。 - **GBR（保障比特速率）**：就像订了包间——餐厅承诺在你用餐时段内这个空间归你用。网络通过**接纳控制（Admission Control）**承诺：只要你的会话不结束，调度器会努力保证你获得不低于**GFBR（保障流比特速率）**的带宽。代价是：**小区资源紧张时，网络可以拒绝你接入**。 GBR流有三个核心参数： - **GFBR**：网络承诺的最低速率； - **MFBR**：承诺之上允许冲刺的最高速率（超过MFBR的流量可能被限速丢弃）； - **平均窗口（Averaging Window）**：速率按多长的时间窗来统计，默认2000毫秒。也就是说“保障速率”不是每个时隙都精确保证，而是**在窗口内平均达到GFBR即算达标**。 $$ R_{avg} = \frac{1}{T_{AW}} \int_{t-T_{AW}}^{t} r(\tau)\, d\tau \ge GFBR $$ 其中 $T_{AW}$ 为平均窗口。这个设计非常务实：无线信道是波动的，调度器做不到每毫秒都精确给足速率，但**在一个窗口内保证总量**既可验证又可执行。 而Non-GBR流约束它的不是GFBR，而是**两个天花板**： - **Session-AMBR**：单条PDU会话的聚合最大速率，由UPF执行限速； - **UE-AMBR**：一个终端所有会话加起来的总限速，由RAN执行。 ### 4.2 GBR vs Non-GBR 全景对比 | 维度 | GBR流 | Non-GBR流 | |---|---|---| | 网络承诺 | 窗口内平均速率≥GFBR | 无承诺，仅限速上限 | | 接纳控制 | 必须经过，**可能被拒绝** | 基本不设卡 | | 资源预留 | 调度器把GFBR纳入规划 | 不预留，共享剩余资源 | | 典型5QI | 1（语音）、2（视频通话）、3（游戏） | 5、7、8、9 | | 频谱利用率 | 低（保障即可能闲置） | 高（吃满剩余资源） | | 拥塞时的表现 | 有保障或被通知"无法再保障" | 速率随拥塞下降 | | 配套参数 | GFBR/MFBR/平均窗口 | Session-AMBR/UE-AMBR | ### 4.3 接纳控制：GBR流的“入会审查” 当核心网（SMF）要求基站建立一条GBR流时，基站必须先做接纳判决：本小区已承诺的GBR总量加上新请求，是否超过小区的承载能力？这引出了ARP的登场。 ```mermaid flowchart TD A[核心网请求建立GBR流
携带5QI/GFBR/ARP] --> B{小区剩余可保障
容量足够?} B -->|足够| C[接纳成功
纳入调度保障计划] B -->|不足| D{该流的ARP抢占能力
Preshemption Capability?} D -->|是| E{能否找到可被抢占的
低优先级GBR流?} E -->|是| F[抢占: 释放低优先级流
新流接纳成功] E -->|否| G[拒绝接纳
上层可降级或回退] D -->|否| G C --> H[QFI写入调度器
按GFBR+PDB保障] ``` 这里的巧妙之处在于：**GBR接纳不通过的流不是被“杀掉”，而是可以被降级为Non-GBR继续跑**。比如VoNR呼叫建立时，如果小区挤满了，语音流可能以Non-GBR方式接通——通话质量无法100%保障，但至少能打通。这正是“尽力服务”与“硬性拒绝”之间的工程折中。 --- ## 五、ARP：资源不够时，谁让路 ARP（Allocation and Retention Priority，分配与保持优先级）是最容易被误解的参数之一。它只在**接纳控制和资源争夺**这两个瞬间起作用，**不参与每毫秒的包调度**。 ARP由三部分组成： 1. **优先级（Priority Level, PL）**：取值1～15，**1最高**； 2. **抢占能力（Pre-emption Capability）**：资源不够时，我**能不能抢别人的**？(yes/no) 3. **抢占脆弱性（Pre-emption Vulnerability）**：别人来抢时，我**会不会被踢**？(yes/no) 用急诊室类比最贴切：救护车伤员（PL=1、能抢占）可以要求普通候诊病人让出诊室；而一个标了“脆弱”的普通病人（Vulnerability=yes）就是那个被让出诊室的人。这套机制解决的是一个残酷但必要的问题——**当消防车和救护车同时要过路口，路口只能放行一辆**。 于是每条GBR流实际上带着一张“战斗属性卡”，四种组合各有含义： | 抢占能力 | 抢占脆弱性 | 行为画像 | |---|---|---| | Yes | Yes | 贵宾：能抢别人，也可能被更高优先级抢 | | Yes | No | 霸主：能抢别人，且豁免被抢（如公共安全专网） | | No | Yes | 老实人：不抢别人，可能被牺牲 | | No | No | 普通座：不抢人也不被人抢，先到先得 | --- ## 六、调度器如何兑现承诺：从PDB到出包顺序 接纳控制只是“签了合同”，真正兑现承诺的是基站的**每毫秒调度**。调度的核心逻辑可以概括为一句话：**谁快“逾期”，谁先走**。 每个包带着它的5QI出生，从进入基站缓冲区那一刻起就有了**截止时间**： $$ t_{deadline} = t_{arrival} + PDB $$ $$ t_{slack} = t_{deadline} - t_{now} $$ 调度器按 $t_{slack}$（剩余裕量）给包排序：裕量越小的包越紧急，优先分配资源。同时，GBR流还有一条附加约束——调度器要盯着平均速率公式，**确保每条GBR流在窗口结束前把GFBR的“配额”送完**。这本质上是一种“最早截止时间优先（EDF）”与“保障速率配额”的混合策略。 ```mermaid flowchart TD subgraph buffer["基站调度缓冲区（某1ms时刻）"] P1[包A: 5QI1语音
剩余裕量 8ms]:::urgent P2[包B: 5QI3游戏
剩余裕量 15ms] P3[包C: 5QI9网页
剩余裕量 290ms]:::low P4[包D: 5QI9网页
剩余裕量 299ms]:::low end buffer --> S{{调度器:
按剩余裕量升序+
GBR配额检查}} S --> OUT[时隙资源优先给包A
其次包B
包C/D尽力而为] classDef urgent fill:#ffcccc classDef low fill:#e8f4e8 ``` 对于**延迟关键GBR**（如5QI 82/83/84，工业控制与高级V2X，PDB低至10毫秒），调度逻辑更严格：网络不但要保障速率，还要监控**LDR（迟延丢包率，超过PDB的包占比）**不能超过配方里的PER，并且用MDBV约束突发——一次突发太大，再强的调度器也来不及在10毫秒内送完。这套参数组合说明：**URLLC类业务的QoS不是“更快”，而是“可预测”**。 --- ## 七、反射式QoS：为什么多数流建立时一点信令都没有 5G还有一个精妙设计：**QoS规则的下达方式有两种**。 1. **显式配置（Configured）**：核心网通过NAS消息把QoS规则发给UE，明确“QFI=7的上行流要这样打标签”。可靠但费信令。 2. **反射式（Reflective）**：UE收到下行包时，看到SDAP包头里的QFI和**RQI（反射QoS指示）**，就自己“照抄”——下行的包用什么QFI、走什么过滤规则，上行的同类包就用同样的规则。**UE从下行流量中反射学习上行规则**，全程零信令。 为什么这样设计？设想一个工业现场有500个传感器流，如果每条流建立都要NAS信令，控制面信令风暴不可避免。反射式QoS把规则的创建变成了**数据面的自然副产品**——这是“控制面轻量化”哲学的又一个体现。 --- ## 八、端到端全景：一个QoS流的一生 把所有角色放在一起看完整闭环： ```mermaid sequenceDiagram participant App as 应用/AF participant PCF as 策略控制 PCF participant SMF as 会话管理 SMF participant RAN as 基站 gNB participant UE as 终端 UE App->>PCF: 业务需要QoS保障（如VoNR呼叫） PCF->>SMF: 下发PCC规则（含5QI/GBR参数/ARP） SMF->>RAN: N2消息：建立QoS流
（QoS Profile：5QI、GFBR/MFBR、ARP） RAN->>RAN: 接纳控制判决（GBR容量/ARP抢占） alt 接纳成功 RAN->>UE: RRC配置DRB（多条流可复用一条DRB） UE->>RAN: 上行包打QFI标签（反射或配置） RAN->>RAN: 调度器按PDB裕量+GFBR配额调度 else 接纳失败且通知控制开启 RAN->>SMF: 通知"无法再保障GFBR" SMF->>PCF: 策略调整（降级/备选QoS） end ``` 注意图中的**通知控制（Notification Control）**：对开启了该功能的GBR流，当无线信道恶化、基站发现**再也无法保证GFBR**时，必须主动上报核心网，让应用层知情决策——比如视频会议APP可以主动降分辨率，而不是让用户对着一卡一卡的画面猜原因。这是“承诺制”必须配套的“违约告知”机制。 --- ## 九、切片与QoS流：大小两个粒度 一句话厘清两者关系：**切片是“专店”，QoS流是“店内贵宾卡”**。一个网络切片（由S-NSSAI标识）在切片层面提供资源隔离与专属容量——类似餐厅单独辟出一个包场；而切片内部，每条业务流仍靠5QI/GBR/ARP这套机制细粒度排队。切片解决“**这家店和那家店互不干扰**”，QoS流解决“**这家店内谁先上菜**”。两者叠加，才构成5G“一网千面”的完整故事：粗粒度用切片做物理/逻辑隔离，细粒度用QoS流做调度编排。 --- ## 十、现网实战：这些知识在哪里派上用场 **1. 抓包看什么。** 用Wireshark解析N2接口的NGAP消息（如PDU Session Resource Setup Request），能看到QoS Flow Level参数的原始下发：5QI、GFBR/MFBR上下行值、ARP三元组、是否开启通知控制。空口侧，SDAP头中的QFI字段在Uu口抓包中直接可见。排障第一步永远是：**核心网下发的参数和基站实际执行的是否一致**。 **2. “信号满格但网速慢”的常见根因。** 用户投诉速率差，无线环境良好——先查AMBR。如果UDM中该用户签约的UE-AMBR是100 Mbps，那么无论基站多空闲、载波聚合多强大，**RAN侧会把这个用户整体压在100 Mbps以内**。此时最优MCS、最好的波束都救不了——这是策略问题，不是覆盖问题。 **3. VoNR建立失败或回落。** 语音5QI=1是GBR流，接纳可能被拒。如果小区GBR容量规划过紧，或ARP抢占配置不当（如语音流的抢占能力配了No），会出现呼叫建立失败或静默回落到Non-GBR。排障时对比“下发ARP”与“小区接纳日志”即可定位。 **4. 调度异常排查。** 如果某URLLC流时延抖动大，检查三件事：5QI的PDB是否被自定义动态5QI覆盖、延迟关键类的MDBV是否与应用实际突发量匹配（突发超过MDBV，超出部分不享受保障）、以及该流是否意外落入了Non-GBR的DRB。 **5. 常见误解清单。** - 误解一：“GBR就是独占预留了一块带宽。” 实际是**调度目标+接纳承诺**，资源仍是统计复用的，GBR流不发数据时资源可以让给别人用。 - 误解二：“ARP优先级影响每毫秒的调度顺序。” 不，ARP只在接纳/抢占瞬间生效，日常调度看的是5QI优先级和PDB裕量。 - 误解三：“GBR流一定比Non-GBR流优先级高。” 5QI=5的IMS信令（Non-GBR、优先级10）在调度上通常优先于5QI=9（Non-GBR、优先级90），资源类型和优先级是两个正交维度。 - 误解四：“QFI就是4G的EBI换了名字。” 机制完全不同：EBI绑定端到端隧道，QFI只是包标签，生命周期随包走。 --- ## 常见问题 **Q1: GBR和Non-GBR的本质区别到底是什么？** A: 一句话——**网络敢不敢承诺**。GBR流经过接纳控制后，网络承诺在平均窗口内保证不低于GFBR的速率，做不到要么抢占资源、要么主动通知“违约”；Non-GBR流没有任何速率承诺，只有AMBR这个限速天花板，拥塞时它承担所有损失。前者牺牲资源利用率换取确定性，后者恰恰相反。 **Q2: 5QI和ARP有什么区别？它们都是“优先级”吗？** A: 不是一回事。5QI回答“**这是一条什么样的流**”——时延预算、丢包容忍、资源类型，是流的“体检报告”；ARP回答“**这条流有多重要、能不能抢别人**”——只在接纳控制和资源抢占时生效。一条5QI=1的语音流可以配ARP=10（很低的重要性），也可以配ARP=1（公共安全级），两者独立配置、各管各的。 **Q3: GFBR、MFBR、AMBR这几个速率参数如何区分？** A: 记住两组：GBR流用**GFBR（保底）/MFBR（封顶）**，是调度器逐窗口考核的执行参数；Non-GBR流用**Session-AMBR（会话封顶）/UE-AMBR（终端总封顶）**，是纯限速参数、由UPF和RAN分别执行。GFBR是“承诺”，AMBR是“天花板”——语义方向完全相反。 **Q4: 为什么5G要废掉4G的EPS承载模型，改用QoS流？** A: 规模与信令效率。4G承载ID只有8比特上限（256条），且每条流都要端到端信令；5G把QoS身份变成包头里的QFI标签，配合反射式QoS，新增一条流大多数时候**零信令**，流数量不再受限，多条流还能复用同一条无线承载。本质是把QoS从“管道属性”重构为“包属性”，控制面与数据面解耦。 **Q5: 切片和QoS流是什么关系？有了切片还需要QoS吗？** A: 需要，两者粒度不同。切片提供**切片间**的资源隔离和专属容量（专店包场），切片内部的每条业务流仍要靠5QI/GBR/ARP做**切片内**的排队调度（店内贵宾卡）。没有切片，QoS流也能独立工作（公共网络上的VoNR就是例子）；没有QoS，切片内部就退化成一个大号的尽力而为管道。 --- ## 参考来源 2. [5G QoS - ShareTechnote](https://www.sharetechnote.com/html/5G/5G_QoS.html) — 5G QoS流、QFI、5QI参数与信令流程的工程师向图文详解，配大量抓包示例 3. [5G QoS Flow - ShareTechnote](https://www.sharetechnote.com/html/5G/5G_QoS_Flow.html) — QoS Flow与DRB映射、反射式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 等场景全覆盖。