酒店前台对客人说：“您是行政楼层贵宾，每天早上七点，靠窗位给您留着。”这句承诺很动听，但真正让承诺兑现的，是它被拆成了三张单子：房务部拿到“这位客人靠窗位要留”，餐饮部拿到“七点档口优先出餐”，门口礼宾拿到“这车牌的车直接放行”。任何一张单子没送到对应岗位，客人第二天早上就得站大厅里吃闭门羹。
移动网络里的服务质量承诺也是一样。策略网元拍板“这条视频通话流要保底速率、低时延”，只是一句话。要让这句话落地，网络里至少有三个岗位——无线基站、手机、核心网锚点——各自需要一份专门写给自己看的备忘。这中间的设计学问，就是本文的主角：一份QoS信息为什么要拆成三份、各自发给谁、手机又是怎么在几乎零信令的情况下学会自我管理的。
先把最核心的三个词摆上桌：QoS Flow（QoS流）、QFI（QoS流标识）、三份文件。理解了它们，你在现网抓任何一段QoS相关的信令都不会迷路。
5G把QoS的最小单位从“承载”变成了“流”。同一条PDU会话里可以同时跑网页、视频、语音，网络按业务把数据包归成若干条QoS流，每条流一个编号，就是QFI。凡是贴着同一个QFI的包，全网所有节点给予完全相同的转发待遇——同样的调度优先级、同样的队列、同样的丢包策略。
这个设计有个精妙之处：QFI本身只是一串编号，不含任何参数。它像登机牌上的舱位代码"Y"——牌子上不印“优先登机、免费改签、额外行李额”这些细则，地服、贵宾室、登机口各自拿这个代码去自己的系统里查待遇。5G里这张“查询表”就是5QI定义的标准化套餐：编号1对应会话语音，编号9对应普通互联网业务，等等。信令里只传一个小整数，全网设备查同一张表，这就是为什么QoS信令可以做得极轻。
但“待遇说明书”本身还不够。一条流要真正跑起来，要回答两个完全不同的问题：
分类靠的是“包过滤器”——五元组、协议号、端口段这些特征。执行靠的是5QI背后的参数集。有意思的是，分类和执行恰恰落在不同的设备手里，而且下行和上行的分类者还不一样。这就是“三份文件”的由来。
会话建立时，会话管理功能（SMF）是那个“拆单的运营经理”：它从策略网元拿到完整业务策略后，拆出三份文件，发往三个岗位。
flowchart TD
S["SMF：拆解完整待遇方案"] --> A["发往无线侧"]
S --> U["发往手机"]
S --> P["发往锚点UPF"]
A --> A1["QoS Profile<br/>待遇说明书"]
U --> U1["QoS Rule<br/>分拣手册"]
P --> P1["PDR<br/>识别卡"]
A1 --> A2["基站据此调度与准入"]
U1 --> U2["手机据此给上行包分类"]
P1 --> P2["锚点据此识别与计费"]
三份文件的分工，可以用一张表看全：
| 岗位 | 拿到的文件 | 里面写了什么 | 用来干什么 |
|---|---|---|---|
| 无线基站 | QoS Profile | 5QI、优先级ARP、GBR流的保底与封顶速率、时延预算 | 决定空口调度、准入判决、队列管理 |
| 手机 | QoS Rule | QFI + 包过滤器 + 规则优先级 | 把上行IP包分拣到对应QoS流并贴QFI |
| 锚点UPF | PDR | 包过滤器 + QFI + 转发与计费参数 | 识别下行包归属、封装QFI、出话单 |
为什么不干脆发一份完整文件给所有人？三个理由：
下行和上行的分类者不一样，这是理解全篇的钥匙。下行方向，所有包都从外部网络涌向锚点UPF，UPF拿着PDR逐包检查特征、贴上QFI再送出去——网络对自己发出的每一包都一清二楚。上行方向，包的源头是手机里的各个应用，分类工作只能由手机完成，所以分拣手册（QoS Rule）必须送到手机手里。手机里同样有一张过滤器表，逐条匹配、按优先级取先命中者，给包贴上QFI。
到了空口和隧道上，还有两个“贴标员”：无线侧的SDAP子层负责QoS流与无线承载之间的映射和QFI的搬运；N3接口上QFI放在隧道封装的扩展头里，跟着包走。于是完整链路是：IP包 → （手机按QoS Rule分类）→ QoS流 →（SDAP映射）→ 无线承载 → （隧道封装带QFI）→ UPF → （UPF按PDR核对识别）→ 外部网络。QFI像一条缝纫线，把这条链上每个环节缝在同一待遇之下。
把时间轴拉回到手机刚要上网的那一刻：
sequenceDiagram
participant UE as 手机
participant gNB as 基站
participant AMF as AMF
participant SMF as SMF
participant UPF as UPF
UE->>AMF: 请求建立会话
AMF->>SMF: 转交创建请求
SMF->>UPF: 经N4下发PDR识别卡
SMF->>AMF: 会话接受与规则文件
AMF->>gNB: 经N2转发待遇说明书
gNB->>UE: 经NAS下发分拣手册
gNB->>UE: 配置无线承载与SDAP
Note over UE,gNB: 两级映射就绪
UE->>gNB: 上行包按规则贴QFI
gNB->>UPF: 隧道封装携带QFI
注意几个关键细节：
默认规则是一切的兜底。 每条PDU会话建立时，网络必须给手机下发一条默认QoS规则：它的过滤器是“全部匹配”，优先级数值最大（意味着最后被匹配、垫底执行），对应一条非GBR流。它保证一个朴素的底线——手机发出的任何包，哪怕不匹配任何精细规则，也一定有去处。真实开局日志里，这条默认规则长这样：规则类型标记为默认、过滤器为match-all、优先级255、QFI指向1，对应5QI=9这条最常见的互联网套餐，同时带着会话级总闸：下行聚合速率5Gbps、上行2Gbps。你的手机上绝大多数“没什么特殊待遇”的流量，走的就是这套默认配置。
无线侧拿到的东西比想象中少。 上面例子里的QoS Profile给基站的只有：5QI=9、优先级15、不抢占别人、也不可被抢占，加上两条聚合速率上限。基站拿这些去换算成调度权重、准入门限和队列参数——协议把5QI之后的具体行为留给各厂家实现，标准允许多种实现，具体行为以各厂家官方文档为准。
两级过滤，各管一段。 标准上把整个分类过程明确分成两级：NAS级（手机与核心网之间）完成“IP包 → QoS流”的归类，接入级（手机与基站之间）完成“QoS流 → 无线承载”的映射。多IP流可并成一条QoS流，多条QoS流也可复用在一个无线承载上——只要它们待遇相近。这种柔性映射是5G相对4G最大的架构进步：4G时代承载是端到端一一对应的刚性管道，5G把“逻辑待遇”与“物理管道”解耦了，基站可以按自己的资源状况自由组合。
现在只剩一个问题没解决：手机手里的分拣手册从哪来？
显式下发当然可以——每新增一条业务流，SMF就通过NAS信令给手机发一条QoS Rule。可靠、精确，但每条流一次会话修改信令。现代App的流量形态是什么样？一个网页动辄并发几十条连接，各种API、广告、心跳包来去匆匆。为每条存活几十秒的小流走一轮完整信令，就好比快递公司为了一个三块钱的小件专门派人来签一份收货协议——手续钱比货贵。
于是有了第二个方案：反射式QoS（Reflective QoS）。设计思路极其朴素——既然下行的分类是网络做的，那上行对称方向的分类规则，手机能不能“抄”下来？
flowchart TD
D["下行包抵达手机<br/>带QFI与反射指示"] --> L["手机抄下面单<br/>学出对称上行规则"]
L --> T["规则挂上老化定时器"]
T --> U["上行同类包<br/>自己贴同款QFI"]
U --> R["基站按同一待遇调度"]
K["后续下行包继续带指示"] -->|续命| T
X["迟迟没有新下行包"] -->|超时作废| T
机制上有三样东西配合：
类比成海关与货代：回程的货代懒得等总部传真报关细则，直接把去程包裹上的面单抄一份，反向照贴——只要去程源源不断，回程就永远贴不错。
两种方式可以在同一条会话里共存：手机在建会话时会向网络申报自己是否支持反射，支持则网络可以按流选择用哪种方式。两种方式的取舍如下：
| 维度 | 显式下发 | 反射式 |
|---|---|---|
| 规则来源 | SMF用NAS信令逐条下发 | 手机抄下行包自行生成 |
| 信令开销 | 每条流一次会话修改 | 几乎为零，随数据包自带 |
| 生效方式 | 信令到达即生效 | 收到首个带指示的下行包即生效 |
| 适用场景 | 语音等关键流、默认规则 | 海量短命小流、网页杂流 |
| 规则退场 | 网络显式删除 | 定时器超时自动作废 |
还有一个容易被忽略的边界：默认规则永远走显式下发，不参与反射。这是刻意设计——兜底的规则必须是网络完全掌控、随时可验证的，不能依赖“手机抄作业”这种自学习机制，否则一旦终端实现有偏差，连最后的保险丝都不可靠了。
三份文件解决的是“待遇怎么传达到位”，而待遇本身分两个世界：GBR（保底速率）与Non-GBR（非保底）。它们的差别本质上是资源配置哲学的差别。
GBR流像预订包间。 下单时三个数字最关键：保底速率（GFBR）、封顶速率（MFBR）、平均统计窗口。准入环节要逐流核账——这个基站小区、这段传输，剩余的资源装得下这份保底吗？装不下就拒绝，宁可让业务起不来，也不让已承诺的流被挤兑。核账通过后，调度器在每个统计窗口内必须兑现承诺，用公式说就是：
$$\frac{\text{窗口内实际送达的比特数}}{\text{平均窗口时长}} \ge GFBR$$
对时延敏感类GBR流（工业控制、触觉反馈那类），还有两个更苛刻的指标：时延预算（PDB）内要求98%的包必须送达，以及最大数据突发量（MDBV）——规定一个调度时机里允许一次塞进来的最大字节数，防止突发把精心排好的时刻表冲乱：
$$P(D \le PDB) \ge 98\%$$
但请注意一个最常见的误解：GBR保证的是底线，不是上限。封顶速率MFBR用令牌桶执行——桶以MFBR的速率积累令牌，包要出门必须先拿令牌：
$$B_{new} = \min\left(B_{max},\; B + MFBR \times \Delta t\right)$$
令牌不够，超速的部分照样被丢弃或降级。“保证速率”四个字只保护GFBR以内的那一段，超出部分与普通流量无异。
Non-GBR流像大排档。 不预订、不核账、来了就安排，资源紧张时全靠优先级论资排辈，受两级总闸约束：会话级聚合最大速率（Session-AMBR）管住这条会话的所有流，终端级聚合最大速率（UE-AMBR）管住这台手机的所有会话。它不做准入，也因此不需要“装不下怎么办”的复杂决策——大排档永远 welcoming，但上菜速度看运气。
ARP（分配与保留优先级）在这个体系里是“身份牌”：由优先级（1到15，数字越小越尊贵）、能否抢占别人、可否被别人抢占三个字段构成。GBR流准入时靠它排队伍，Non-GBR流在资源饥荒时靠它定生死。准入与抢占的详细机制是另一个大话题，此处只需记住：ARP是跨所有QoS流的统一排序坐标，无论GBR还是Non-GBR，最终都要站到同一杆秤前比高低。
| 维度 | GBR流 | Non-GBR流 |
|---|---|---|
| 资源预留 | 有，准入时逐流核账 | 无，先来先调度 |
| 保底速率 | GFBR，窗口内必须兑现 | 无保底，只看优先级 |
| 封顶机制 | MFBR令牌桶，超出即丢 | Session-AMBR与UE-AMBR两级总闸 |
| 准入控制 | 必须，装不下就拒绝 | 不设准入 |
| 典型业务 | 语音、视频会议、实时控制 | 网页、下载、后台同步 |
为什么这样设计？因为无线频谱是全网最稀缺的资源，预留是有代价的。把“承诺”做成昂贵的、要审计的商品（GBR），把“尽力”做成免费的海量兜底（Non-GBR），让每一份稀缺资源都花在真正需要承诺的业务上——这是整个QoS体系资源分配的经济学。
理解了“三份文件”，调试QoS问题就有了一个强大心法：同一份策略，从三个视角分别验证，对不上的地方就是事故现场。
三个视角都正常之后，再看数据面：抓GTP-U隧道包，确认扩展头里QFI是否在、值是否对。常见坑集中在几处：
坑一：优先级顺序配反了。 规则按优先级数值从小到大匹配，先命中先执行。有人把精细规则的优先级配成了比默认规则还大，结果所有包先被match-all的默认规则截胡，精细规则永远轮不上——表象就是“配了QoS跟没配一样”。
坑二：纯上行流用反射规则翻车。 反射规则的性命靠下行包“续命”。一个几乎只有上行流量的场景（大文件上传），下行没有匹配包回来续定时器，规则悄悄超时作废，上行流量突然掉回默认流，用户体验为“传着传着突然变龟速”。这种问题复现依赖流量模型，极难定位——你现在知道去查反射定时器了。
坑三：把默认待遇当成全session待遇。 默认规则match-all不等于“所有流量一个待遇”——精细规则优先级更高，会先被匹配走。反过来，看到抓包里流量都贴着默认QFI，先别急着骂核心网，八成是过滤器没写对。
坑四：隧道扩展头在中间环节丢失。 QFI放在N3隧道封装的扩展头里，个别老化的转接设备或互通点不透传扩展头，导致锚点收到的包QFI全空，统计、计费、反射机制集体失灵。跨厂商互通的链路上，这是值得优先排查的暗雷。
最后纠正两个流传甚广的误解：其一，5QI数字越大优先级越高——错，优先级是独立字段，且数值越小优先级越高，5QI只是查表索引；其二，GBR流绝不丢包——错，GFBR以内是承诺，超过MFBR的部分照丢不误。
Q: QoS Profile和QoS Rule都是SMF下发的，为什么不合并成一份文件发给三方？ A: 因为三个岗位的问题域完全不同：基站要的是调度与准入参数，手机要的是包分类规则，UPF要的是识别与计费依据。合并下发意味着三方都要解析并存储与自己无关的信息，浪费信令与内存，还把网络内部策略暴露给了用户手里的终端。拆分是信息局部性原则的典型应用——每个节点只知道自己必须知道的事。
Q: 4G的EPS承载和5G的QoS流，到底差在哪？ A: 4G的QoS锚定在端到端承载上，无线承载、核心网承载一一对应，改一条流的待遇要拆建整条管道，刚性且信令重。5G把“待遇”（QoS流+QFI）与“管道”（无线承载、隧道）解耦：多条流可复用一个承载，映射由基站按资源状况灵活决定。这是从“专线模型”到“标签模型”的跃迁。
Q: 反射式QoS和默认规则同时存在时，手机听谁的？ A: 不冲突。默认规则永远显式下发、垫底匹配（优先级数值最大）；反射学来的规则带着自己的优先级，匹配时数值小的先执行。只要反射规则的特征过滤器写得比match-all精确，它就永远先于默认规则命中。另外规范明确：默认流上不启用反射，兜底机制必须由网络全程掌控。
Q: 给业务配了GBR，为什么高峰期还是卡？ A: 三个常见原因：准入核账时承诺的GFBR本身低于业务真实需求；超出的突发流量撞上MFBR被令牌桶丢弃；或者GBR参数只在无线侧生效，传输网段没有对应保障——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 等场景全覆盖。