# 一份待遇，三处保管：QoS落地原理 ## 引子：承诺凭什么兑现 酒店前台对客人说：“您是行政楼层贵宾，每天早上七点，靠窗位给您留着。”这句承诺很动听，但真正让承诺兑现的，是它被拆成了三张单子：房务部拿到“这位客人靠窗位要留”，餐饮部拿到“七点档口优先出餐”，门口礼宾拿到“这车牌的车直接放行”。任何一张单子没送到对应岗位，客人第二天早上就得站大厅里吃闭门羹。 移动网络里的服务质量承诺也是一样。策略网元拍板“这条视频通话流要保底速率、低时延”，只是一句话。要让这句话落地，网络里至少有三个岗位——无线基站、手机、核心网锚点——各自需要一份**专门写给自己看**的备忘。这中间的设计学问，就是本文的主角：一份QoS信息为什么要拆成三份、各自发给谁、手机又是怎么在几乎零信令的情况下学会自我管理的。 先把最核心的三个词摆上桌：**QoS Flow（QoS流）**、**QFI（QoS流标识）**、**三份文件**。理解了它们，你在现网抓任何一段QoS相关的信令都不会迷路。 ## 一、先看清货物：QoS流与QFI 5G把QoS的最小单位从“承载”变成了“流”。同一条PDU会话里可以同时跑网页、视频、语音，网络按业务把数据包归成若干条QoS流，每条流一个编号，就是QFI。**凡是贴着同一个QFI的包，全网所有节点给予完全相同的转发待遇**——同样的调度优先级、同样的队列、同样的丢包策略。 这个设计有个精妙之处：QFI本身只是一串编号，不含任何参数。它像登机牌上的舱位代码"Y"——牌子上不印“优先登机、免费改签、额外行李额”这些细则，地服、贵宾室、登机口各自拿这个代码去自己的系统里查待遇。5G里这张“查询表”就是5QI定义的标准化套餐：编号1对应会话语音，编号9对应普通互联网业务，等等。信令里只传一个小整数，全网设备查同一张表，这就是为什么QoS信令可以做得极轻。 但“待遇说明书”本身还不够。一条流要真正跑起来，要回答两个完全不同的问题： - **这个包属于哪条流？**（分类问题） - **这条流享受什么待遇？**（执行问题） 分类靠的是“包过滤器”——五元组、协议号、端口段这些特征。执行靠的是5QI背后的参数集。有意思的是，**分类和执行恰恰落在不同的设备手里**，而且下行和上行的分类者还不一样。这就是“三份文件”的由来。 ## 二、一份拆三份：每家只拿自己用得上的 会话建立时，会话管理功能（SMF）是那个“拆单的运营经理”：它从策略网元拿到完整业务策略后，拆出三份文件，发往三个岗位。 ```mermaid flowchart TD S["SMF：拆解完整待遇方案"] --> A["发往无线侧"] S --> U["发往手机"] S --> P["发往锚点UPF"] A --> A1["QoS Profile
待遇说明书"] U --> U1["QoS Rule
分拣手册"] P --> P1["PDR
识别卡"] A1 --> A2["基站据此调度与准入"] U1 --> U2["手机据此给上行包分类"] P1 --> P2["锚点据此识别与计费"] ``` 三份文件的分工，可以用一张表看全： | 岗位 | 拿到的文件 | 里面写了什么 | 用来干什么 | |------|-----------|-------------|-----------| | 无线基站 | QoS Profile | 5QI、优先级ARP、GBR流的保底与封顶速率、时延预算 | 决定空口调度、准入判决、队列管理 | | 手机 | QoS Rule | QFI + 包过滤器 + 规则优先级 | 把上行IP包分拣到对应QoS流并贴QFI | | 锚点UPF | PDR | 包过滤器 + QFI + 转发与计费参数 | 识别下行包归属、封装QFI、出话单 | **为什么不干脆发一份完整文件给所有人？**三个理由： 1. **信息局部性**：基站只关心“怎么调度、要不要预留”，它不需要知道计费规则；手机只关心“我的哪个应用包贴哪个标”，它不需要知道全网策略。发无关信息纯属浪费空口和信令。 2. **安全与权限**：终端是落在用户手里的设备，QoS Profile里涉及网络内部的资源策略，没有必要也不应该让终端掌握全貌。 3. **解耦演进**：基站侧待遇与终端侧分类规则可以独立修改。运营商改一个计费策略，不需要惊动无线侧；调整一条流的过滤器，不需要重配基站调度器。 **下行和上行的分类者不一样**，这是理解全篇的钥匙。下行方向，所有包都从外部网络涌向锚点UPF，UPF拿着PDR逐包检查特征、贴上QFI再送出去——网络对自己发出的每一包都一清二楚。上行方向，包的源头是手机里的各个应用，分类工作只能由手机完成，所以分拣手册（QoS Rule）必须送到手机手里。手机里同样有一张过滤器表，逐条匹配、按优先级取先命中者，给包贴上QFI。 到了空口和隧道上，还有两个“贴标员”：无线侧的SDAP子层负责QoS流与无线承载之间的映射和QFI的搬运；N3接口上QFI放在隧道封装的扩展头里，跟着包走。于是完整链路是：**IP包 → （手机按QoS Rule分类）→ QoS流 →（SDAP映射）→ 无线承载 → （隧道封装带QFI）→ UPF → （UPF按PDR核对识别）→ 外部网络**。QFI像一条缝纫线，把这条链上每个环节缝在同一待遇之下。 ## 三、一次会话建立，三份文件怎么送达 把时间轴拉回到手机刚要上网的那一刻： ```mermaid 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）**。设计思路极其朴素——既然下行的分类是网络做的，那上行对称方向的分类规则，手机能不能“抄”下来？ ```mermaid flowchart TD D["下行包抵达手机
带QFI与反射指示"] --> L["手机抄下面单
学出对称上行规则"] L --> T["规则挂上老化定时器"] T --> U["上行同类包
自己贴同款QFI"] U --> R["基站按同一待遇调度"] K["后续下行包继续带指示"] -->|续命| T X["迟迟没有新下行包"] -->|超时作废| T ``` 机制上有三样东西配合： - **RQI（反射QoS指示）**：锚点UPF在需要反射的流的每个下行包上打这个标记，基站台把它转告手机——“这个包，值得抄”。 - **RQA（反射QoS属性）**：SMF提前通过N2告诉无线侧“这条流上有流量会用反射”，让基站有个心理准备。 - **老化定时器**：手机每学出一条上行规则，就给它挂一个定时器；每当再收到匹配的带指示下行包，定时器清零重来；一旦迟迟没有新下行包，定时器到点，学来的规则自动作废。流死了，规则跟着退场，不留垃圾。 类比成海关与货代：回程的货代懒得等总部传真报关细则，直接把去程包裹上的面单抄一份，反向照贴——只要去程源源不断，回程就永远贴不错。 两种方式可以**在同一条会话里共存**：手机在建会话时会向网络申报自己是否支持反射，支持则网络可以按流选择用哪种方式。两种方式的取舍如下： | 维度 | 显式下发 | 反射式 | |------|---------|--------| | 规则来源 | SMF用NAS信令逐条下发 | 手机抄下行包自行生成 | | 信令开销 | 每条流一次会话修改 | 几乎为零，随数据包自带 | | 生效方式 | 信令到达即生效 | 收到首个带指示的下行包即生效 | | 适用场景 | 语音等关键流、默认规则 | 海量短命小流、网页杂流 | | 规则退场 | 网络显式删除 | 定时器超时自动作废 | 还有一个容易被忽略的边界：**默认规则永远走显式下发，不参与反射**。这是刻意设计——兜底的规则必须是网络完全掌控、随时可验证的，不能依赖“手机抄作业”这种自学习机制，否则一旦终端实现有偏差，连最后的保险丝都不可靠了。 ## 五、GBR与Non-GBR：预订包间与大排档 三份文件解决的是“待遇怎么传达到位”，而待遇本身分两个世界：**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问题就有了一个强大心法：**同一份策略，从三个视角分别验证，对不上的地方就是事故现场**。 - **手机视角**：抓NAS信令，看PDU会话建立接受消息里的Authorized QoS Rules——手机到底收到了哪些分拣手册、默认规则是否在、优先级数值是否正确。 - **基站视角**：抓N2信令，看会话资源建立请求里的QoS Profile——5QI、ARP、GBR参数有没有到位，有没有被中间网元吞掉字段。 - **锚点视角**：看N4接口的会话上报——PDR装了哪些过滤器，与策略源头下发的是否一致。 三个视角都正常之后，再看数据面：抓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是全链路接力，最弱一环决定实际体验。排查时按“手机、基站、锚点、承载网”四段分别核对配置。 ## 参考来源 1. [NR QoS - ShareTechnote](https://www.sharetechnote.com/html/5G/5G_QoS.html) — 以真实信令日志逐行拆解QoS建立全流程，含默认规则、PDR、SDAP配置实例 2. [5G Quality of Service - Devopedia](https://www.devopedia.org/5g-quality-of-service) — 权威技术百科词条，系统梳理SMF向UE、基站、UPF三方向分发QoS信息与反射QoS机制 3. [5G NR QoS Architecture, QoS Attribute and QoS Flow - Techplayon](https://www.techplayon.com/5g-nr-qos-architecture-qos-attribute-and-qos-flow/) — 工程师社区对QoS架构、参数集与4G/5G 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 等场景全覆盖。