# 一条QoS规则的万里长征：从策略纸面到空口落地 ## 引子：菜单上写着，不等于厨房做到 你去餐厅点菜，菜单上印着“牛排，八分熟，二十分钟上桌”。这句话写在纸上很容易，真正难的是后厨：谁来记住这张单子？牛排几分熟怎么判断？如果两桌同时点了同一块肉，谁先出？出菜之后传菜员怎么知道这盘要快走？ 5G的QoS体系就是这家餐厅。应用在会话建立时说“我是语音，要低时延、有保底速率”，这相当于顾客点菜；网络答应下来，相当于菜单上把承诺写好。但**从“承诺”到“每一颗包真的被区别对待”，中间隔着整整一条流水线**。很多工程师能背出5QI的含义，却说不清一颗下行包从数据网络进来之后，到底经过了哪些关卡、在哪一站被限速、在哪一站被贴标签、在哪一站被塞进空口的某个队列。这篇文章就跟着这颗包，把整条流水线走一遍。 先看全景。整条链路分成控制面和用户面两条线：控制面负责“立规矩”，用户面负责“干活”。 ```mermaid flowchart TD AF["应用提出需求"] -->|策略请求| PCF["PCF 策略大脑"] PCF -->|策略决策| SMF["SMF 会话管家"] SMF -->|N4工单| UPF["UPF 转发执行"] SMF -->|NAS信令| UE["UE 终端"] SMF -->|NGAP信令| gNB["gNB 基站"] UPF -->|N3隧道带QFI| gNB gNB -->|DRB空口承载| UE ``` 策略从PCF出发，经过SMF翻译，兵分三路下发：一路给UPF（N4接口的“工单”），一路给基站（接入侧资源），一路给终端（NAS层的QoS规则）。三条线到齐，这颗包的“待遇”才算真正落地。下面一站一站细看。 ## 第一站：待遇的原始凭证——套餐编号与插队证 在讲流水线之前，得先弄清楚SMF手里拿到的是什么凭证。每条PDU会话建立时，必然带有一条**默认QoS流**，它是非GBR的，相当于餐厅的“团购套餐”：不承诺保底，但保证你永远有得吃。现网默认流最常见的取值是5QI=9——一个“标准化套餐编号”，网络里的每一台设备看到这个编号，就知道它对应约300毫秒的时延预算和10^-6的丢包预算，不需要在信令里逐项传递参数。 套餐编号解决“什么待遇”，还有一张凭证解决“排队时谁让谁”——**ARP（分配与保留优先级）**。它是一个1到15的数字，1最高，附带两个开关：能不能抢占别人、能不能被别人抢占。你可以把它理解成餐厅的“插队证”：平时不显山露水，一旦座位紧张（资源不足），它决定谁被请出去。紧急呼叫、专网切片里的关键业务，靠的就是这张证。 需要强调的是：5QI和ARP都只是**语义层面的描述**，是纸面上的承诺。纸面承诺不会自动变成现实——把它变成现实的，是接下来四站。 ## 第二站：SMF把承诺翻译成工单 SMF是整条流水线的总调度。它收到策略决策后，做的第一件事是**翻译**：把“给这个业务XX待遇”翻译成UPF能逐包执行的机器指令。 这里体现了5G核心网最重要的一个架构思想：**转发面和控制面分离**。策略的“大脑”在SMF，干活的“手”在UPF，两者之间靠N4接口上的一套规则体系通信。开源核心网Open5GS的文档把这个机制说得很直白：这些规则由控制面编程进用户面，定义包应当如何被**识别、转发、限质、计量和缓存**。 这套工单体系有四个核心零件： | 规则 | 全称 | 干什么 | 类比 | |---|---|---|---| | PDR | 包检测规则 | 按「五元组、UE地址、隧道端点」等条件匹配流量 | 安检口按登机牌分流 | | FAR | 转发动作规则 | 决定命中后怎么走：转发、封装、丢弃、缓存、复制 | 分流后走哪条安检通道 | | QER | QoS执行规则 | 对匹配流量做门控和限速 | 通道口的限流闸机 | | URR | 用量上报规则 | 计数、计时、按量触发上报给计费系统 | 通道口的流量计数器 | 其中PDR是入口。每条PDR带一个**匹配条件集合（PDI）**——可以是UE的IP地址、隧道的两端标识，也可以是一条应用级的业务流过滤器（比如“目标是某视频服务器443端口的那条TCP流”）。多个PDR可能同时看起来都匹配，所以每条PDR还有一个**优先级数值**，数值越小越先匹配，先命中先用。这套“条件+优先级”的结构，让UPF面对每秒百万级的包流时，只需要做一件极其简单的事：**逐包查表，命中即执行**。 为什么要把“识别”和“处理”拆成两张表（PDR管识别，FAR/QER/URR管处理）？因为同一种流量可能在不同时刻需要不同处理：白天正常转发，深夜策略要求缓存；或者一条流同时要限速又要计量。拆开后，改任何一个动作只需把新规则关联到已有PDR上，不用重写匹配条件。这是典型的**策略与执行解耦**——大脑改主意，手不用重新学。 ## 第三站：UPF流水线上的逐包审判 工单装进UPF之后，每一颗包的命运就在这条流水线上被决定。整个过程是纯数据面的操作，没有任何信令参与——这是它能扛住大流量的根本原因。 ```mermaid flowchart TD A["包从N3或N6到达"] --> B["PDR按优先级匹配"] B --> C{"命中规则吗"} C -->|未命中| D["走默认流处理"] C -->|命中| E["QER门控检查"] E -->|门是关的| F["静默丢弃"] E -->|门是开的| G["令牌桶限速"] G --> H["URR计数计量"] H --> I["FAR执行动作"] I --> J["封装转发"] I --> K["缓存或复制"] ``` 流水线上有两个环节值得停下来细看。 **第一个是门控（Gate）。** 每条QER带一个开/关状态，门关着时包被“静默丢弃”——注意不是报错，是悄无声息地扔掉。门控的用途是**暂时冻结**：比如用户欠费停机时，SMF不停会话、不删规则，只是把门关上；复机时把门打开，一切瞬间恢复。这种“保留现场、只关闸门”的设计，比反复建立/删除整个会话要轻量得多。 **第二个是限速。** UPF做限速不是用一个简单的计数器——那样的话，用户在整点那一秒可以瞬间灌进海量数据。实际用的是**令牌桶**算法：系统以固定速率往桶里放令牌，每个包发送前要先取走令牌，桶空了就只能等。 $$r \le \text{MBR，令牌生成速率}， \qquad b \approx \text{桶深，允许的最大突发}$$ 令牌桶的精妙之处在于它同时管住了两件事：**长期平均速率**被生成速率卡死，**短时突发**被桶深容忍。桶里攒下的令牌允许业务在空闲之后来一波脉冲（比如网页加载的一瞬间拉取几十个对象），这是“平均限速”体验远好于“瞬时卡死”的关键。视频类业务普遍表现出的“开头快、后头匀”，背后就是这只桶。 而URR在旁边默默记账：过了多少包、多少字节、持续多长时间，达到阈值就上报给计费系统。你话费单上“用了多少GB”，原始凭证就诞生在这一站。 ## 第四站：出了UPF，标记就是一切 包从UPF出来，进入传输网。这里有个残酷的现实：**传输网上的路由器不认识5G的任何概念**。它不知道什么是QoS流、什么是5QI，它只认识IP头。 怎么办？答案是DiffServ体系：在包的IP头上打一个6比特的DSCP标记，沿途路由器只看标记给待遇——标记写着“低时延”就走优先队列，写着“尽力而为”就排队。维基百科对这套机制的定位很清晰：DiffServ是“打标记”的路线上胜出的方案——早年IETF推过另一条路（IntServ），让每个应用逐跳预约资源，结果在骨干网上扛不住海量预约状态，最终被“边缘打标记、核心按标记排队”的轻量方案取代。 5G核心网沿用并内化了同样的哲学，而且拆得更彻底： - **3GPP域内**（UPF到基站），用隧道承载，QFI在隧道扩展头里跟着包走，“这是一条什么业务”的完整语义得以保留； - **传输网段**，靠UPF按QoS流映射出的DSCP标记，让每一跳路由器“见标记行事”。 为什么要分两段？因为两端的管理者不同。隧道内的QFI是运营商自己地盘里的私货，语义可以很丰富；一出地盘进入共享传输网，就必须换成公共语言（DSCP）。**语义在域内保全，待遇在域外靠标记近似**——这是端到端QoS在现实世界里能落地的唯一折中。 ## 第五站：最后三百米——QoS流如何拧上空口 包到了基站，迎接它的是整个体系里最精巧的一层映射。5G把4G的“承载”概念拆散了：4G时代从终端到核心网是一条端到端的专用管道，QoS和管道一一绑定，改个待遇要拆了重建整条管道；5G则分成松耦合的两级——**核心网只认QoS流，空口只认数据无线承载（DRB），两层之间靠基站的SDAP子层“拧”在一起**。 这个改动的价值在于：新增一条QoS流，如果基站判断现有DRB的待遇档次够用，**只需在新流和旧DRB之间画一条映射线**，空口不用新建任何东西；只有待遇差异大到必须单独伺候时（比如新来了一条GBR语音流），才新建DRB。管道数量被压到最少，信令开销和终端功耗都跟着降。 ```mermaid flowchart TD A["核心网发来QoS流"] --> B["基站SDAP层收货"] B --> C{"已有DRB待遇匹配吗"} C -->|匹配| D["映射到现有DRB"] C -->|需单独伺候| E["RRC新建专用DRB"] D --> F["空口同一队列调度"] E --> G["空口独立队列调度"] ``` 而这条映射线的维护，5G还藏了一个省信令的大招：**反射QoS**。传统做法里，终端的上行QoS规则必须由网络用专用信令一条条下发，规则多了既慢又繁琐。反射QoS反其道而行：网络在下行包上打一个“反射指示”（RQI）标记，终端收到后自己观察——这条下行包带着什么QFI、被映射到了哪个DRB——然后**照葫芦画瓢，把同样的映射规则自学到上行方向**。之后所有上行包自动按学来的规则处理，网络全程不再说话。 ```mermaid flowchart TD A["SMF开启反射模式"] --> B["下行包打RQI标记"] B --> C["终端收到带标记的包"] C --> D["读取头中QFI"] D --> E["自学上行映射规则"] E --> F["后续上行自行对号"] ``` 一行标记替代一轮信令，这就是“让数据面替控制面打工”。 映射完成后，最后一关是基站调度器。它是所有承诺的最终兑现者：GBR流的保底速率每秒都要兑现，调度器为其保留配额；非GBR流靠剩余资源尽力而为，但整体受会话级聚合上限（AMBR）封顶，防止单个用户吃光小区。资源紧张时，ARP的“插队证”开始生效——能抢占的流可以踢走“可被抢占”的流，保证关键业务永远有座。可以说，**前面四站所有纸面承诺，都要在这一毫秒一毫秒的调度裁决里还债**。 ## 现网连接：调试时这五站分别看什么 理解了流水线，很多“玄学问题”就有了定位坐标： - **用户“有网速但全丢包”**：先查UPF的QER门控。欠费、策略冻结、PCF下发gate关闭，症状都是静默丢弃——流量统计里有进无出，但会话看着一切正常。 - **“限速不准”**：检查是按流限速还是按会话聚合限速。AMBR是会话级总闸，单流QER是分闸，两道闸叠加后的实际速率是两者的交集，配错层级就会出现“单测速准、多任务跑不满”的怪象。 - **“某条QoS流像没生效”**：查PDR优先级。两条PDR条件重叠时，优先级数值小的先命中，流量被“劫持”到了宽泛规则上，专用规则永远轮不到。这是策略配置事故里最常见的坑。 - **“上行QoS没建起来但业务也通了”**：很可能走的就是反射QoS——先有下行业务，终端自学了上行规则。抓空口信令看不到上行规则下发，不代表规则不存在。 - **“传输段时延抖”**：核心网域内语义完好，不代表传输网给足了待遇。DSCP标记打了，中间路由器的队列配置接不接是另一回事——端到端QoS的最弱一环，永远在域与域的接缝上。 ## 常见问题 **Q: QoS流和4G的EPS承载到底差在哪？** A: 4G的承载是端到端强绑定的管道，QoS参数焊死在管道上，5G把两者拆开：QoS流只存在于语义层，空口的DRB只是它的“临时座位”，映射关系随时可调。好处是核心网改待遇不必惊动空口，管道数量大幅减少。 **Q: 5QI相同的两条流，会走完全相同的路径吗？** A: 不一定。5QI只定义待遇标准（时延预算、丢包预算等），路径由PDR匹配、映射关系和调度器共同决定。两条5QI=9的流可能一条走默认DRB、一条走专用DRB，传输段DSCP标记也可能不同。 **Q: 反射QoS和传统显式下发可以混用吗？** A: 可以，而且现网常见。核心网对某些流用信令显式下发规则，对另一些流打反射标记让终端自学。同一条PDU会话里两种方式可以并存，终端分别维护。 **Q: GBR流的保底速率是绝对保证吗？** A: 只在准入时承诺。建立时网络核算过资源够用才放行，之后调度器每秒兑现；但切换到新小区时新基站可能资源不足，此时按ARP裁决——要么拒绝切换，要么降级为非GBR继续走。移动性让“绝对保证”天然打折。 **Q: 为什么限速要用令牌桶而不是直接掐速率？** A: 直接掐速率会消灭一切突发，网页首屏、视频起播这类脉冲式需求会被误伤。令牌桶用桶深容忍合理突发，同时用放令牌的速率卡住长期平均值，兼顾了体验和控制。 ## 参考来源 1. [Quality of service - Wikipedia](https://en.wikipedia.org/wiki/Quality_of_service) — DiffServ/DSCP标记体系与IntServ逐跳预约的架构取舍 2. [5G NR QoS Architecture, QoS Attribute and QoS Flow - Techplayon](https://www.techplayon.com/5g-nr-qos-architecture-qos-attribute-and-qos-flow/) — 4G承载一比一映射与5G QoS流两级模型的对比 3. [SDAP: QoS Flow to DRB Mapping & Reflective QoS - CafeTele](https://www.cafetele.com/5g-protocols-book/chapter-4-sdap-qos-flow-to-drb-mapping.html) — SDAP单字节头、RQI/RDI指示与反射QoS的映射算法 4. [Packet Forwarding Rules (PDR/FAR/QER/URR/BAR) - DeepWiki Open5GS](https://deepwiki.com/open5gs/open5gs/5.1.2-packet-forwarding-rules-(pdrfarqerurrbar)) — 开源5G核心网中规则体系的真实实现 5. [UPF - 5GC Textbook](https://5gctextbook.com/en/nf/upf/) — UPF经N4接收规则、逐包执行转发的原理讲解 --- > 本文由「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 等场景全覆盖。