首页 › deep-tech › 图解5G QoS：5QI与GBR的分配机制

图解5G QoS：5QI与GBR的分配机制

一、为什么需要QoS：共享管道的根本矛盾

想象一条双向四车道的高速公路，所有车辆混行：救护车、公交车、快递车、私家车挤在一起。如果完全“先到先走”，一旦车流变大，救护车会被堵在中间——它的任务就会失败。

蜂窝网络本质上是这样一个共享系统：一个小区的频谱资源被所有用户瓜分，基站调度器（Scheduler）每1毫秒都要做一个决定——下一个时隙把资源分给谁。如果调度器只有一条原则“谁信号好给谁”，那么网页和视频会跑得飞快，而一通语音电话可能断断续续、一个工业机器人的控制指令可能迟到100毫秒——尽管它们的“业务重要性”完全不同。

QoS（Quality of Service，服务质量）就是给这个共享系统引入的分诊机制。它的目标不是“让所有人都更快”，而是让不同需求的数据流得到不同等级的对待：语音要低时延低丢包，视频直播要稳定带宽，微信聊天则“能用就行”。理解QoS，本质上是理解三个问题：

网络怎么描述一条流的需求？（→ 5QI）
网络怎么承诺资源？（→ GBR / Non-GBR）
资源不够时谁让路？（→ 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流标识）。

flowchart TB
    subgraph Legacy["4G模型：管道式"]
        A1[业务流1] --> B1[EPS Bearer 1<br/>端到端专用隧道]
        A2[业务流2] --> B2[EPS Bearer 2<br/>端到端专用隧道]
        A3[业务流3] --> B3[EPS Bearer 3<br/>端到端专用隧道]
        B1 --> C1[每条承载一次<br/>端到端信令]
    end
    subgraph NR["5G模型：贴标签式"]
        D1[业务流1] --> E[汇聚到<br/>一条PDU会话]
        D2[业务流2] --> E
        D3[业务流3] --> E
        E --> F1[包1: QFI=1]
        E --> F2[包2: QFI=7]
        E --> F3[包3: QFI=9]
        F1 --> G[同一条无线承载<br/>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的登场。

flowchart TD
    A[核心网请求建立GBR流<br/>携带5QI/GFBR/ARP] --> B{小区剩余可保障<br/>容量足够?}
    B -->|足够| C[接纳成功<br/>纳入调度保障计划]
    B -->|不足| D{该流的ARP抢占能力<br/>Preshemption Capability?}
    D -->|是| E{能否找到可被抢占的<br/>低优先级GBR流?}
    E -->|是| F[抢占: 释放低优先级流<br/>新流接纳成功]
    E -->|否| G[拒绝接纳<br/>上层可降级或回退]
    D -->|否| G
    C --> H[QFI写入调度器<br/>按GFBR+PDB保障]

这里的巧妙之处在于：GBR接纳不通过的流不是被“杀掉”，而是可以被降级为Non-GBR继续跑。比如VoNR呼叫建立时，如果小区挤满了，语音流可能以Non-GBR方式接通——通话质量无法100%保障，但至少能打通。这正是“尽力服务”与“硬性拒绝”之间的工程折中。

五、ARP：资源不够时，谁让路

ARP（Allocation and Retention Priority，分配与保持优先级）是最容易被误解的参数之一。它只在接纳控制和资源争夺这两个瞬间起作用，不参与每毫秒的包调度。

ARP由三部分组成：

优先级（Priority Level, PL）：取值1～15，1最高；
抢占能力（Pre-emption Capability）：资源不够时，我能不能抢别人的？(yes/no)
抢占脆弱性（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）”与“保障速率配额”的混合策略。

flowchart TD
    subgraph buffer["基站调度缓冲区（某1ms时刻）"]
        P1[包A: 5QI1语音<br/>剩余裕量 8ms]:::urgent
        P2[包B: 5QI3游戏<br/>剩余裕量 15ms]
        P3[包C: 5QI9网页<br/>剩余裕量 290ms]:::low
        P4[包D: 5QI9网页<br/>剩余裕量 299ms]:::low
    end
    buffer --> S{{调度器:<br/>按剩余裕量升序+<br/>GBR配额检查}}
    S --> OUT[时隙资源优先给包A<br/>其次包B<br/>包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规则的下达方式有两种。

显式配置（Configured）：核心网通过NAS消息把QoS规则发给UE，明确“QFI=7的上行流要这样打标签”。可靠但费信令。
反射式（Reflective）：UE收到下行包时，看到SDAP包头里的QFI和RQI（反射QoS指示），就自己“照抄”——下行的包用什么QFI、走什么过滤规则，上行的同类包就用同样的规则。UE从下行流量中反射学习上行规则，全程零信令。

为什么这样设计？设想一个工业现场有500个传感器流，如果每条流建立都要NAS信令，控制面信令风暴不可避免。反射式QoS把规则的创建变成了数据面的自然副产品——这是“控制面轻量化”哲学的又一个体现。

八、端到端全景：一个QoS流的一生

把所有角色放在一起看完整闭环：

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流<br/>（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，切片内部就退化成一个大号的尽力而为管道。

参考来源

5G QoS - ShareTechnote — 5G QoS流、QFI、5QI参数与信令流程的工程师向图文详解，配大量抓包示例
5G QoS Flow - ShareTechnote — 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 等场景全覆盖。

51学通信知识星球海报-扫码加入