5G QoS控制原理详解：从QoS Flow到5QI参数体系

先说个最直观的场景：你拿着手机在人山人海的演唱会现场，边拍视频边往朋友圈传；旁边有人开着远程驾驶的无人车在园区里跑；同一栋楼里还有一台机械臂正在按毫米级精度做装配。这三个业务对网络的要求是完全不同的——视频要带宽大、上传快；远程驾驶要时延低、抖动小；机械臂要可靠性极高、几乎不允许丢包。如果5G网络对它们都一视同仁地"平摊带宽"、"排队转发"，那结果就是谁都干不了自己的事。

5G之所以能用同一套空口和核心网承载这么五花八门的业务，靠的不是蛮力堆带宽，而是QoS（Quality of Service，服务质量）控制。QoS不是5G才有的概念，4G时代就有，但5G的QoS控制模型跟4G比几乎是推倒重来的。很多刚接触核心网的朋友，看书上那些QoS Flow、5QI、GBR、AMBR的术语容易一头雾水；真正做网络优化和协议开发的同事，如果一开始没把"为什么这么设计"搞清楚，后面处理起端到端业务保障问题也会费不少劲。

这篇文章我就把5G QoS控制原理的基础框架一次性讲透，内容对应的是一套系列专题的第一篇，所以会重点放在底层的模型设计、参数体系和业务映射逻辑上，不涉及太深的调度算法和性能调优。适合刚要入门5G核心网、做接入网协议开发、或者从事网络优化但总被QoS参数绕晕的同行参考。

1. 从4G到5G：QoS模型为什么被推倒重来

要理解5G的QoS控制，首先得明白4G那套做法的问题在哪。4G的QoS是建立在EPS承载（Evolved Packet System Bearer）基础上的，所谓承载，你可以理解成"管道"——从UE到核心网网关，一根管道对应一套QoS参数，所有走这根管道的业务都享受同样的转发待遇。

4G时代，一个UE建立PDN连接后，默认会有一条默认承载，提供上网的基础服务；当业务需要更高的服务质量时，网络再通过专用承载来提供额外的管道。这套体系在4G初期是够用的，但到了4G后期和5G时代，逐渐暴露出了几个明显的短板。

第一个短板是粒度太粗。一个承载通常对应一组业务流，但同一组业务流内部的业务差异可能非常大。比如一个视频会议应用，音频流和视频流对时延和丢包的敏感度完全不同，如果把它们塞进同一个承载里，就只能按最苛刻的标准来配置QoS参数，造成资源的浪费。

第二个短板是建立太慢。专用承载的建立需要核心网多个网元之间走完整的信令交互，从PCRF下发策略到PGW创建承载，再到MME通知基站和UE，整个过程相对笨重。对那种突发性的、短时的高QoS需求（比如突然要传一个大文件），这套模型的响应速度显然跟不上。

第三个短板，也是根本性的问题：承载是端到端的"硬管道"，每段链路（空口、S1接口、核心网内部）都要为这个承载维护一套独立的配置，而各段之间的映射关系固定且僵硬。这种设计缺乏灵活性，尤其不适用于未来那种大量小流量、高动态变化的移动互联网业务。

到了5G阶段，标准制定者意识到，不能再沿用承载这套思路了。5G把QoS的控制粒度从"承载"直接细化到了"流"（Flow）级别——也就是我们常说的QoS Flow。一个PDU会话里可以同时存在多个QoS Flow，每个Flow有自己独立的QoS参数。这样，音频一个Flow，视频一个Flow，后台下载一个Flow，互不干扰，各取所需。

同时，5G引入了二级映射模型：QoS Flow在接入网侧再映射到DRB（Data Radio Bearer，数据无线承载）上。一个QoS Flow可以映射到一个DRB，多个QoS Flow也可以复用同一个DRB，具体怎么映射由基站根据无线资源状况来决定。

注意，这个"二级映射"的设计是理解5G QoS的关键。它把"业务的QoS需求"和"无线资源的调度策略"解耦了——核心网只管定义业务需要什么QoS，至于空口上怎么调度这些QoS流，由RAN灵活处理，给了网络更大的弹性。

4G的模型就像是铁路运输，每一列火车跑固定的线路，多个QoS等级就铺多条轨；5G的模型则更像是快递分拣中心，包裹进来先分拣到不同传送带，再根据目的和优先级灵活装车，一套分拣系统适应所有业务。从"承载"到"流"的这一变，是整个5G QoS模型的灵魂。

2. 核心三要素：QoS Flow、5QI与包过滤器的配合

5G QoS控制中打交道最多的，就是这么几个概念：QoS Flow、QFI、5QI、包过滤器（Packet Filter，也叫SDF Template）。它们之间的配合关系搞清楚，基本上就掌握了这套模型的一半。

2.1 QoS Flow：5G里"服务质量"的最小分配单位

QoS Flow是5G系统里承载QoS参数的最小单位，一个PDU会话（PDU Session）内可以建立多个QoS Flow，每个Flow用一个QFI（QoS Flow Identifier，QoS流标识符）来唯一标识。QFI在PDU会话内是唯一的，取值范围是0到63，也就是说一个会话里最多能有64个QoS Flow。

QoS Flow的方向是双向的，上行和下行共用同一个QFI。从UE角度看，一个QoS Flow就是一组上行包过滤器加一组下行包过滤器的集合，再加上一套QoS参数。某种意义上看，QoS Flow是"服务数据流"（SDF）在5G系统里的承载体——SDF是应用层业务流经包过滤器筛选后在网络侧的体现，每个SDF映射到一个QoS Flow上。

这里要提醒一下：QoS Flow是"用户面"的概念，它解决的是"数据包在传输过程中怎么被识别、怎么被对待"的问题；它在信令面上的存在感其实很强，但真正每时每刻跑的流量，都挂在这个Flow上。可以说，QoS Flow就是5G QoS的一张"身份证"。

2.2 5QI：一套标准化的QoS画像

搞清楚了QoS Flow，下一个问题就是：每个Flow应该享受什么样的服务待遇？答案就在QoS参数里。5G定义了一套标准化QoS特性索引，那就是5QI（5G QoS Identifier，5G QoS标识符）。每个5QI的值都对应一组标准化的QoS特性，包括资源类型、默认优先级、分组延迟预算（PDB）、分组错误率（PER）、平均窗口、最大数据突发量等等。

网络上有个比喻我觉得很贴切：5QI就是一个"示例代码"，它定义了某种类型业务应该长什么样。比如5QI=1对应语音通话（GBR类型，PDB 100ms，PER 10^-2）；5QI=9对应视频直播或网页浏览（Non-GBR，PDB 300ms，PER 10^-6）。网元之间传递时，只需要传一个5QI值，接收方就知道服务的QoS画像长什么样，不需要逐项传递所有参数，非常节省信令开销。

5QI里最需要重点区分的是三个资源类型：

• GBR（Guaranteed Bit Rate）：保证比特率。这种Flow有固定的带宽承诺，网络必须确保给到这个速率，哪怕拥塞也要优先保证。语音、实时视频、游戏控制类业务都属于GBR。
• Non-GBR：不保证比特率。这种Flow尽最大努力转发，没有带宽承诺。网页浏览、邮件、文件传输都属此类。
• Delay Critical GBR（时延关键GBR）：这是5G新增的类型，专门为URLLC等超低时延场景设计。它不仅有带宽保证，而且对时延的要求极端苛刻（PDB可以低到5-10ms级别），空口调度上会有特殊处理。

我可以直接把5Q标准里几个常用的值列出来，这样大家看表说话更直观：

上表里有些值是"标准化"的，也就是说所有厂商、所有网络都必须遵守同一套"默认画像"。标准也允许自定义5QI（Non-standardized 5QI），专网、企业网里经常这么干，用标准范围外的值配合自定义的QoS特性来适配特殊业务。

2.3 包过滤器：把"字节流"变成"可管控的业务流"

有了Flow和5QI，还需要回答一个问题：一个数据包进来之后，系统凭什么决定它属于哪个QoS Flow？答案就是包过滤器。每个QoS Flow会关联一组上行的包过滤器和一组下行的包过滤器，过滤器的匹配条件可以基于IP五元组、源/目的端口、协议号、DSCP值、甚至应用标识等字段。

下行的包过滤器一般由SMF根据策略服务器的策略下发给UPF，UPF在转发下行数据时用过滤器把流量分类到对应的QoS Flow，然后打上QFI标记再发给基站和UE。上行的包过滤器则会下发给UE，UE在自己发出数据时做匹配，决定数据走哪个QoS Flow。

在实际抓包时，你会发现每个QoS Flow定义的实际上就是一套"数据包分类规则"，而不是物理上的什么实体资源。这也是5G QoS和4G承载理念差异最大的地方——数据包的"归队"靠的是识别和标记，而不是靠固定管道。

打个比方，如果把网络的数据转发比作商场的客流疏导：QoS Flow是不同等级的"会员通道"，5QI是通道的服务标准，包过滤器就是"安检口"——每个进入商场的顾客（数据包）先被识别，根据你有没有会员卡、买的是什么东西，被引导到对应的通道里。这个类比在脑子里有了，后面看信令流程会轻松很多。

3. 参数体系逐项拆解：QB、AMBR、ARP这些到底在限制什么

上一章把5QI讲清楚了，但5G QoS参数表里远不止5QI一个字段。如果做策略控制或接入网侧调度，接下来这组参数你就躲不开了：ARP、GBR、MBR、AMBR。它们分别管着QoS资源分配和速率约束的不同环节。

3.1 ARP：决定"抢资源"时的排队顺序

ARP（Allocation and Retention Priority，分配与保留优先级）是一个极其关键又容易被忽略的参数。它包含三部分：优先级等级（Priority Level，1-15，数值越小优先级越高）、抢占能力指示（Pre-emption Capability）和抢占脆弱性指示（Pre-emption Vulnerability）。

ARP的作用主要体现在资源紧张时。当网络资源不足，需要新建一个QoS Flow时，如果新Flow的ARP优先级高于已有Flow，且具备抢占能力，而已有Flow的ARP设置成"允许被抢占"，那么网络就可以把已有Flow的资源抢过来给新Flow用。反过来，如果ARP优先级低，即使业务本身很重要，在资源紧张时也可能直接建立失败，或者被高优先级业务抢占掉。

这个机制大家照着"急诊分诊"的逻辑理解就行：病人来了先看生命体征决定救治顺序，不能因为你先挂号就保证你先做手术。在专网场景下，控制类业务（比如远程驾驶的控制信令）通常ARP设为很高且有抢占能力，其他业务设为低优先级且允许被抢占，确保关键时刻控制指令永远能发出去。

3.2 GBR与MBR：带宽的"下限合同"与"上限上限"

GBR刚才提过，对应的是"保证比特率"，它本质上是网络和业务之间的一份合同——网络承诺至少给到这个速率，让应用的体验有地板。但GBR只对上行的"链路层数据速率"做保障，5G里还有个配套参数叫GFBR（Guaranteed Flow Bit Rate，保证流比特率）。

和GBR配对出现的是MBR（Maximum Bit Rate，最大流比特率）/MFBR（Maximum Flow Bit Rate，最大流比特率），它规定了这个QoS Flow能用的带宽上限，防止某个土匪业务把资源全占光。

这里有个细节值得注意：GFBR和MFBR有上行和下行两个方向，是QoS Flow级别的速率约束；而AMBR（Aggregate Maximum Bit Rate，聚合最大比特率）则是更高一级的速率约束，管的是多个Flow加在一起的总量。

AMBR又分成两类：

• Session-AMBR：一个PDU会话内所有Non-GBR QoS Flow共享的总带宽上限。
• UE-AMBR：一个UE所有PDU会话的所有Non-GBR Flow共享的总带宽上限。

看到这里你应该明白了：GBR/MBR是"单条流"的带宽约束，而AMBR是"一群流"的聚合约束。4G时代那个承载对应的AMBR概念，到5G里分成了Session级和UE级两档，限制的颗粒度更加精细。

回忆一下日常生活的例子：银行卡单笔限额相当于MBR，每日总消费限额相当于AMBR，而信用卡的签约额度上限相当于GBR的"最低还款保障"——我只要刷到额度内，银行保证你消费体验。

3.3 UE级和Session级AMBR在实际配置里的踩坑点

我在实际配置网络策略时发现，很多刚入行的同事常常在AMBR上犯错。典型的问题是：在SMF侧为某个PDU会话配置了Session-AMBR，但忘了在AMF/PCF侧配合设置UE-AMBR，或者把两者设反了。

Session-AMBR设在SMF上，作用于单个PDU会话；UE-AMBR则是由接入网侧执行的，一个UE所有会话的所有Non-GBR Flow加总速率不能超过UE-AMBR。执行位置不同，但两者必须协调一致。如果某个终端建了三个PDU会话，每个Session-AMBR都是1G，但UE-AMBR只有1.2G，那么这几个会话同时跑到各满速的时候，UE-AMBR就会成为瓶颈，一部分流量会被速率限制丢弃或延后转发。

排查这类问题时，我建议直接在核心网的用户面节点上抓一下Downlink/Uplink的PDR规则，看里面的Ambr参数是否满足业务规划。别只看会话上下文里的MAX-AMBR字段，还要看用户级上下文里的UE Aggregate Maximum Bit Rate字段，很多线上限速异常就是这么排查出来的。

4. QoS Flow的生命周期：从建立到释放的信令路径

原理讲了一堆，是时候把信令流程串起来了。一个QoS Flow从生到死的全过程，体现了5G控制面和用户面的协同方式。

以最常见的网络侧发起的QoS Flow建立为例，完整链路大概是这样的：

4.1 第一步：业务触发与策略决策

首先，某个应用产生了业务需求，或者核心网检测到某类新业务流到达。如果网络开启了基于流特征的业务识别，SMF会从PCF（策略控制功能）那里获取或更新PCC规则（策略与计费控制规则）。PCC规则里就包含了QoS规则、包过滤器、计费策略等信息。

这里有个前提：SMF和PCF之间的接口（N7）需要建立策略关联（Policy Association），这个关联通常在PDU会话建立时就完成了。所以PDU会话建立和QoS Flow建立往往是连在一起的——先有会话，后定流，有时候一步到位。

4.2 第二步：SMF决策并下发QoS规则

SMF收到PCF的决策后，会为这个QoS Flow分配一个QFI，并生成对应的QoS规则（QoS Rule）。QoS规则里包含了该Flow用到的包过滤器集、5QI、ARP等参数。

紧接着SMF要干两件事：

• 通过N4接口把QoS规则对应的包检测规则（PDR）和转发执行规则（FAR/QER）下发到UPF。UPF之间进行用户面策略同步，让数据面知道"什么样的包应该打上什么标记，走什么隧道"。
• 通过N1/N2接口，把NAS消息（包含QoS规则）经由AMF转发给UE和基站。这一步是将QoS Flow的信息同时告知"收发两端"。

4.3 第三步：RAN侧的DRB配置与空口资源建立

基站的MME侧（或者说gNB侧的相应功能模块）收到QoS Flow信息后，需要在空口侧做映射决策。gNB决定是否要为这个QoS Flow新建一个DRB，还是复用到已有DRB。无论哪种情况，gNB都会通过RRC重配置消息把DRB和QoS Flow的映射关系通知UE。

这个映射决策是gNB的自由裁量权，核心网不能强行指定。gNB会根据无线信道质量、系统负载、业务需求来决定。这就是前面说的"二级映射"的灵活性所在。

空口配置完成后，用户面数据就可以在UE和UPF之间流转了。QoS Flow在这个传输过程中，会以一个"包头里的QFI"的形式存在，基站和UPF都认识这个标记。

4.4 第四步：QoS Flow的修改与释放

业务需求变化时（比如视频通话从标清切到高清），PCF或SMF可以修改QoS规则参数，通常修改的是MBR、ARP或过滤规则。最常见的是SMF发起PDU会话修改流程，通过NAS消息更新UE侧的QoS规则。

释放的时候更简单：会话释放会连带释放所有QoS Flow，单个Flow也可以单独被释放。需要说明的是，Non-GBR的QoS Flow，尤其是默认QoS Flow（Default QoS Flow），通常和PDU会话共存亡；而GBR Flow则是按需创建、按需释放的。

4.5 一个QoS Flow建立流程的信令节点梳理

为了帮助做协议开发的朋友快速定位，我整理了一下要点：

我在做核心网信令分析时，最常用的抓包点是N4接口和RRC层。N4上能直接看到SMF给UPF下发了哪些PDR；RRC重配置里能看到UE和基站的DRB建立结果。两边对照，QoS Flow是否正常建立基本一目了然。

5. 反射式QoS与边缘计算：两个让5G QoS"活了"的机制

到这里，5G QoS的核心模型你已经掌握了大半。但真正让这套模型在实际网络里好用的，还有两个进阶机制——反射式QoS和UL CL/BP边缘分流。它们不是QoS参数，而是"QoS控制的运行方式"，直接决定了5G网络能不能应对动态变化的应用生态。

5.1 反射式QoS：蹭下行包的"顺风车"

传统QoS规则都是由核心网显式下发的，称之为"显式QoS规则"。问题在于，有些应用场景业务流创建得非常频繁、变化的非常快（比如车联网里新开一条媒体流），如果每次都等核心网显式下发规则，时延和信令开销都不小。

反射式QoS（Reflective QoS）提的方案很有意思：UE不做上行分类，而是从收下来的下行数据包里"偷"QoS规则。具体来说，在下行方向的PDCP层和SDAP层里，可以让UE观察收到的QoS Flow的QFI，然后记住"这个QFI对应什么样的包特征"；此后UE发上行业务时，自动套用刚才学到的映射关系，把对应的上行包分类到同一个QFI上。

一句话总结就是：下行告诉UE"这一类数据应该走这条路"，UE照葫芦画瓢，把上行的同类数据也走这条路。不需要核心网再单独发一条上行QoS规则，省掉了上行专用的NAS信令。

不过反射式QoS也有它的问题，它依赖下行流的"引导"，如果上行业务形态和下行业务形态差别过大，或者下行包太稀疏，UE学不到规则，那这条QoS Flow就建不起来，或者只能靠普通过滤器匹配。所以目前很多网络基线配置里，反射式QoS还是作为一个可选能力来用，不是每个运营商的默认配置。

5.2 UL CL / BP：边缘节点上的QoS分流

第二个"活"机制是UL CL（Uplink Classifier，上行分类器）和BP（Branching Point，分支点）。这两个功能部署在UPF侧，目的是让特定业务流在靠近UE的边缘UPF就被分流出去，不需要把流量绕远路送回中心UPF。

如果说QoS Flow解决的是"流量被怎么对待"，UL CL/BP解决的是"流量被送到哪去"——它们合在一起，边缘计算业务才能跑得通。你看一个工厂里的机械臂控制业务，控制面流量必须低时延到达本地MEC平台，而同时这个PDU会话里可能还有一段需要走大网的监控视频流。UL CL根据包过滤器决定：控制流量走本地边缘UPF，视频流量走中心UPF，两条路同时存在于同一个PDU会话里。

5G在PDU会话内引入多路"锚点"和"分支"，让QoS控制的对象不再局限于"从UE到核心网一条线"，而是变成"在不同分支上各走各的QoS Flow"。这个能力对工业互联网、智慧园区、云游戏边缘渲染这类场景至关重要。做这类项目时，要特别注意UPF PDR规则的优先级配置，因为UL CL的分流判断依赖包过滤器得优先级顺序，同一份流量如果匹配了多条规则，谁先谁后直接决定走边缘还是走中心。

5.3 两条机制的实际落地顺序

在我接触过的项目里，反射式QoS往往是5G专网集成时最先被测试的能力之一，实际调测发现终端侧对反射式QoS的支持参差不齐，某些品牌模组就算开了开关也不一定真的用。这时候排查思路一般是先关闭反射式QoS回退到显式下发，再逐步打开对比信令差异。而UL CL则几乎每个边缘项目都会涉及，它与UPF的版本关系和策略配置息息相关，如果遇到"边缘分流没生效"，优先检查UL CL UPF侧的N9接口是否正常，以及中心UPF的FAR是否配置了正确的转发目标。

6. 实际网络里最容易混淆的几组概念与排查经验

最后这部分，我把自己踩过的一些坑和带新人时常发现的问题集中说一遍。这些点教科书上不会写那么细，但实际测试或运维时几乎都会碰到。

6.1 QFI和5QI别搞混

第一个常见的认知错误是把QFI和5QI混为一谈。QFI是QoS Flow的标识符，是一个"实例编号"；5QI是QoS特性的"标准索引"，描述这个Flow应该提供什么样的QoS待遇。类比来说，5QI是菜谱（规定菜该怎么做），QFI是桌号（规定这盘菜端到哪一桌）。同一个5QI可以被不同QoS Flow使用（比如两路视频通话都用5QI=1），但它们各自有独立的QFI。

排查时如果发现"QoS Flow建了但业务不对"，第一件事就是确认UE侧拿到的QoS规则里，5QI是否和预期的业务画像一致。很多信令分析工具上，QFI显示为一个很小的数字，5QI是大数字，一眼就能区分。

6.2 GBR的"保证"和端到端资源预留不是一回事

第二个容易混淆的点：GBR类QoS Flow的"保证比特率"并不等于基站就给它预留了这么多物理资源。在5G的默认调度机制下，gNB可以通过调度器保证GBR流的速率，但这种保证更多是"长期统计意义上的保证"，而不是每毫秒都占用固定的时频资源。这点在URLLC场景尤其敏感：GBR参数设定得再高，如果空口的调制编码方式（MCS）选择不合适、重传机制不到位，低时延指标依然无法达成。

所以做端到端保障时，不能只看核心网给没给到GBR，还要看gNB的调度策略和PDB设置。核心网侧的5QI给的是PDB整体预算，但PDB在整个传输链路中怎么分配——空口占多少、承载网占多少——是需要RAN侧单独规划的。两个环节协调不好，性能测试一定不达标。

6.3 AMBR限速定位的思路

如果你发现"某个业务速率上不去"，疑似被限速，按这个思路查：

1. 先确认这个QoS Flow是GBR还是Non-GBR。GBR受限可以从SMF的QoS会话上下文中查看GFBR/MFBR值；Non-GBR则要去PDU会话上下文里查Session-AMBR，终端侧上下文还有UE-AMBR。
2. 拿到AMBR之后，判断是哪个执行点在做限速。UPF侧的QER（QoS执行规则）里带AMBR参数，gNB侧也在执行UE-AMBR。两边都查一遍，对比实际限速阈值，通常就能定位。
3. 如果都查不出问题，注意一下是否有多会话叠加。UE建立了多个PDU会话，而策略服务器只在一个会话里配置了AMBR，另一个会话用默认值，也会造成奇怪的表现。

这个流程基本能覆盖绝大多数"限速异常"问题，我把它们当成排查SOP来用了。

6.4 5G QoS参数的参考配置建议

最后给一份实际项目里常用的QoS配置参考（非标准值，仅作为经验建议）：

如果你是在配置一个混合业务专网，我建议把业务分为"控制面冗余型"（ARP最高+抢占）、“实时数据型”（GBR+中等ARP）、“背景流量型”（Non-GBR+低ARP）三档，网络资源的博弈逻辑一下子就清晰了。不要把所有业务都配成GBR，否则资源利用率会非常难看。

7. 从原理到实战：留给下一篇的尾巴

这篇文章搭完了5G QoS控制的地基——从4G承载模型的局限讲到5G的QoS Flow模型，从5QI参数体系讲到QoS Flow的生命周期，再深入反射式QoS和UL CL/BP两类重要机制。你现在应该能看懂核心网信令里QoS相关的每个字段，也能根据业务需求大致推断配什么样的QoS参数了。

就我个人在实际项目里的体会来说，5G QoS这玩意，最忌讳的就是"只背术语不建立体系"。你单独问一个"5QI是什么"很多人能答上来，但把它放到一个PDU会话建立流程里，问"这个Flow为什么建不起来"或者"这个业务为什么时延高了"，能完整定位的人就不多了。本文的思路就是先建立"QoS Flow是核心、5QI是画像、过滤器是出入口、AMBR是总量闸门"的框架，再往里填信令细节，这样后面遇到再复杂的排障，至少不会一头雾水。

下一篇专题里，我会接着往下讲5G QoS在无线接入网侧的落地细节——SDAP层的QoS Flow到DRB映射算法、logical channel的优先级配置、调度器的QoS感知设计，以及URLLC场景下怎么做空口时延预算分配。这些内容算是把"核心网说好了算"和"基站怎么落地"之间最后那段链路补上。等这些都聊完，你手里那套5G核心网要跑起业务来，才算是真正的"心里有数"。