<!-- title: 一条流的待遇单：5QI与QoS原理 -->

# 一条流的待遇单：5QI与QoS原理

## 一、从快递时效说起：不是所有包裹都一个送法

你在购物车里下过两种单：一种是标着“次日达”的水果，另一种是不限时效的打印纸。前者贵，因为快递公司为你**预留了舱位**——哪怕当天货舱紧张，也要把别人的货往后挪，先把你的水果送出去；后者便宜，货舱挤就等一天，丢了再补寄一单。

通信网络里跑的数据包，和这两种包裹一模一样。微信语音里的一句“喂”，晚到半秒你就觉得对方卡了；而后台偷偷更新的系统补丁，晚到十分钟你毫无察觉。如果网络对每个包都一视同仁地“先进先出”，那么语音就会和补丁挤在同一个队伍里互相拖累——这就是**QoS（Quality of Service，服务质量）**要解决的问题。

QoS 不是让网络跑得更快，而是让网络**对不同流的包给出不同的承诺**：有的流承诺“按时送到，丢了算我的”，有的流只承诺“尽力送到，堵了别怪我”。本文讲清楚 5G 里这套“待遇体系”的三个核心零件：**5QI（套餐编号）、GBR/Non-GBR（保底与共享两种资源哲学）、ARP（插队规则）**，以及一条数据包从应用到空口、待遇是如何被一步步确定和执行的。

## 二、为什么需要 QoS：应用的性格不同

先建立一个直觉：**应用的丢包耐受和时延耐受是两种独立的性格**。

- 实时语音：丢一两个包，听感只是轻微毛刺；但延迟超过 200 毫秒，对话就开始“抢话”。它是**宁丢勿等**型。
- 文件下载：丢一个包，TCP 重传就是了，你感觉不到；但带宽被挤压，下载就慢。它是**宁等勿丢**型。
- 网页浏览、信令：介于两者之间，怕丢又没有那么急。

这就有了一个天然的“服务分级”需求。但分级不能是运营商拍脑袋：你在这家网络给“语音”定的待遇，换个网络（漫游、切换到另一张网）必须还能对上号。于是需要一个**全球通用的待遇字典**——这就是 5QI 的由来。

## 三、从 4G 的“包厢”到 5G 的“贴标签”

4G 时代的做法是**按承载（bearer）服务**：每个用户建一条条 EPS 承载，每条承载绑一个 QCI（QoS 等级标识），同一条承载里的所有包享受同等待遇，在核心网到基站之间各自占一条独立的 GTP 隧道。这就像火车包厢：**一节车厢一个速度**，想让两种不同待遇的包并行，就得再挂一节车厢——每次都要跑一遍信令流程，笨重。

5G 把粒度细化到了**QoS 流（QoS Flow）**：每个流有自己的编号 **QFI（QoS Flow Identifier）**，包在隧道里传输时不再是“整节车厢一个待遇”，而是**每件行李贴一张标签**。到了基站，多条待遇兼容的流还可以合并进同一条空口承载（DRB）里传输。

```mermaid
flowchart TD
    A["应用开口要待遇<br/>我要打电话"] --> B["核心网会话管理<br/>翻译成套餐"]
    B --> C["5QI=1<br/>时延预算100ms"]
    B --> D["ARP<br/>可抢人 不可被抢"]
    C --> E["UPF 给每个包贴标签<br/>QFI=1"]
    D --> E
    E --> F["基站调度器<br/>按套餐排队"]
    F --> G["语音包优先出队<br/>普通包让路"]
    G --> H["对端按时收到<br/>通话连续"]
```

**为什么这样设计？** 因为 5G 面对的业务谱系比 4G 宽得多：从毫秒级的工业控制到“不在乎延迟只要带宽大”的下载，如果每种待遇都要单独建承载、跑信令，控制面的开销会爆炸。改成“流 + 标签”后：

1. **建立会话时只需要一条默认流**，后续新待遇按需加流，信令轻了；
2. **空口侧自由度更高**——待遇相同的几条流可合并进一条 DRB，待遇差异大的才分开，基站不再被“一承载一隧道”绑死；
3. 空口协议栈为此新增了 **SDAP 层**，专门负责“QoS 流到 DRB”的映射，标签直接写在包头上，空口一眼就能识别。

## 四、5QI：一本全球通用的套餐手册

5QI 本质上是一个**索引号**。网络不给每个业务逐项传送“时延多少、丢包多少、优先级几”这一大串参数，而是只传一个编号，收号的一方去查**标准化的套餐表**，就知道这套待遇的全部参数：资源类型、优先级、包时延预算（PDB）、误包率（PER）等。

下表是现网最常见的几个标准化套餐（数值为业界通行的标准化参数表内容，本次成稿时检索工具受限，建议以文末来源交叉核对）：

| 5QI | 资源类型 | 优先级 | 时延预算 PDB | 误包率 PER | 典型业务 |
|---|---|---|---|---|---|
| 1 | GBR | 20 | 100 ms | 10⁻² | 5G 语音通话 |
| 2 | GBR | 40 | 150 ms | 10⁻³ | 视频通话 |
| 3 | GBR | 30 | 50 ms | 10⁻³ | 实时游戏、工业控制 |
| 5 | Non-GBR | 10 | 100 ms | 10⁻⁶ | 语音信令 |
| 7 | Non-GBR | 70 | 100 ms | 10⁻³ | 直播、互动视频 |
| 8 | Non-GBR | 80 | 300 ms | 10⁻⁶ | 普通移动数据 |
| 9 | Non-GBR | 90 | 300 ms | 10⁻⁶ | 默认上网流 |
| 82 | 延迟关键 GBR | 19 | 10 ms | 10⁻⁴ | 车联网协同感知 |

读这张表有几个门道：

**优先级数字越小，待遇越高。** 注意 5QI 5（信令）的优先级是 10，比语音的 20 还靠前——这不是设计失误。信令是网络的“神经系统”，一旦信令被业务流量憋死，连释放资源自救都做不到。所以**管理平面永远比用户平面金贵**，这是全网设计的铁律。

**PDB 是预算，不是军令状。** 包时延预算的准确含义是：在这个时间预算内到达，就视为“没迟到”。它是给调度器、重传机制（HARQ）等各个环节**分摊时延开支**的总账本，而不是承诺每个包都 100 毫秒必达。5QI 82 的 PDB 只有 10 毫秒，意味着整条链路几乎不为它留排队余地，调度器要像救护车一样随到随发。

**PER 表达的是丢包的“容忍度”。** 10⁻² 意味着一百个包丢一个可接受——语音丢一点听不出来；10⁻⁶ 则是百万分之一的量级——文件传输丢不得。你会看到语音（5QI 1）的 PER 反而比上网（5QI 9）宽松两个数量级，这正是“性格不同，待遇不同”的量化体现。

**为什么用索引而不是传全套参数？** 三个理由：省信令（一个字节代替一串参数）、保一致（全网对同一个编号的理解完全相同，漫游也不跑偏）、留余地（运营商还可以自定义动态 5QI，自行填写全套参数，用于特殊业务，但出了自家网络别人未必认得）。

## 五、GBR 与 Non-GBR：先审批还是先上车

5QI 表里最关键的一列是**资源类型**，它把所有流分成两种哲学：

**GBR（Guaranteed Bit Rate，保底速率）是预约制餐厅。** 你要开一条语音流，网络先做**准入控制**：看看小区还剩多少保障容量，够就接纳并**预留**资源——哪怕你暂时不说话，这份资源也给你占着；不够就拒绝，或者按规则挤掉别人。GBR 流还带两个速率值：GFBR 是保底速率（承诺给到），MFBR 是封顶速率（超了也不多给）。

**Non-GBR 是大排档。** 不审批、直接进，大家共享一个资源池，忙时互相挤。它的唯一约束是 AMBR（聚合最大比特率）这道总闸：session-AMBR 管一条 PDU 会话的总量，UE-AMBR 管这个用户所有会话加起来的总量，由基站执行限速。

**为什么 GBR 要先审批？** 用排队论一个最简单的直觉公式看就明白了。把基站看成一个服务窗口，包到达率为 $\lambda$，服务率为 $\mu$，平均等待时间大致满足：

$$W = \frac{1}{\mu - \lambda}$$

这个公式最凶险的地方在分母：当负载 $\lambda$ 逼近容量 $\mu$ 时，等待时间**不是线性变差，而是爆炸式恶化**。也就是说，一个小区在 80% 负载时语音还挺好，再加几个大流量用户冲到 95%，时延直接失控。所以对时延敏感、要“担责”的 GBR 流，必须在进门**之前**算账：

$$\sum_{i \in \text{已接纳}} GFBR_i \;+\; GFBR_{\text{新流}} \;\le\; C_{\text{小区保障容量}}$$

算得过来才接纳——**宁可拒绝，不可失信**。这就是 GBR 准入控制的全部逻辑。

```mermaid
flowchart TD
    A["新业务申请保底带宽"] --> B{"是 GBR 流吗"}
    B -->|否| C["直接接纳<br/>进共享池排队"]
    B -->|是| D["基站查剩余保障容量"]
    D --> E{"够分吗"}
    E -->|够| F["接纳并预留资源"]
    E -->|不够| G["按 ARP 找牺牲者"]
    G --> H{"抢得到吗"}
    H -->|能| I["释放低优先级流<br/>接纳新流"]
    H -->|不能| J["拒绝申请<br/>业务降级运行"]
```

两种哲学的责任边界也完全不同：GBR 流在预算内发生拥塞性丢包，**责任在网络**（你收了承诺）；Non-GBR 流被挤压、被丢弃，**网络无责**（从来没承诺过）。这一点直接决定了丢包重传策略和用户体验归因。

## 六、ARP：不动手调度时的“插队法”

很多人把 5QI 优先级和 ARP 优先级搞混，其实它们管的是**两个不同时刻**的事：

| 维度 | 5QI 优先级 | ARP 优先级 |
|---|---|---|
| 管什么 | 已经接纳的包，谁先被调度 | 新流能不能进来，拥塞时谁被踢 |
| 起作用时机 | 每个调度时刻（毫秒级连续生效） | 建立准入与资源冲突的瞬间 |
| 取值范围 | 1～127，数字越小越优先 | 1～15，数字越小越优先 |
| 类比 | 餐厅里上菜的先后顺序 | 订座时谁有资格挤掉谁的座位 |

ARP（分配与保持优先级）除了一个 1～15 的优先级数字，还有两个开关，合起来构成一张“社交关系表”：

- **抢占能力（能不能抢别人）**：资源不够时，我可以把优先级比我低的流踢出去，占用它的资源；
- **易被抢占（会不会被抢）**：当别人需要资源时，我是不是合法的牺牲品。

四个开关组合出四种人格：**又能抢人又不可被抢**的是救护车（紧急语音、公共安全业务）；**不能抢人但可能被抢**的是普通乘客（一般视频通话）；双开关全关的是佛系流。这套机制完美对应医院分诊台——急诊永远有路，但代价是有人要让出诊室。

```mermaid
sequenceDiagram
    participant U as 新业务
    participant C as 核心网
    participant G as 基站
    participant L as 低优先级流
    U->>C: 申请语音保障带宽
    C->>G: 下发套餐与抢占能力
    G->>G: 盘点空口剩余资源
    G->>L: 资源不足 释放你的预留
    L-->>G: 预留让出 转入不保障状态
    G-->>C: 准入成功
    C-->>U: 通话建立
```

注意一个细节：被抢占的流不是被“删除”，而是**降级**——GBR 预留被收回，业务本身往往还能以 Non-GBR 的方式继续跑，只是从此没有保障。就像被请出包厢的客人还可以去大排档，只是不再有人保证上菜时间。

## 七、一条包的完整旅程：待遇如何被标记和执行

前面讲的是“待遇单怎么开”，现在看“待遇怎么执行”。关键在**标记与映射**两级机制：

1. **核心网侧标记**：上行方向，终端按网络下发的 **QoS 规则**给每个包打上 QFI；下行方向，UPF 检测业务数据流（按 IP 五元组、应用标识等规则匹配），把属于某条 QoS 流的包都贴上同一个 QFI，通过 N3 接口送往基站。
2. **空口侧映射**：SDAP 层根据 QFI 把流分配到 DRB。待遇兼容的几条流可以走同一条 DRB；待遇差异大的（比如延迟关键 GBR 和默认流）必须分开，各走各的物理通道。
3. **调度执行**：基站的 MAC 调度器在每一毫秒里，按 5QI 的优先级、PDB、PER 安排各流的传输顺序和资源块数量——这就是“待遇”真正兑现的地方。

还有一个省信令的巧思值得一讲：**反射式 QoS（Reflective QoS）**。上下行待遇通常是对称的，如果每条上行流都要网络专门下发一条 QoS 规则，信令会很啰嗦。于是网络在下行包上打一个 RQI 指示，终端看到后**照着下行待遇反推出上行规则**——“下行怎么被对待，上行就照着办”，像跟读一样省掉了专门的通知流程。

最后理清 QoS 与切片的关系，一句话：**切片是包间，QoS 是座位。** 切片在你建立连接之前就选定了，决定你进哪个包间（哪一组网络功能、哪一套隔离资源）；进去之后，包间里依然按 5QI 分座位等级。一张切片里可以并存多种 5QI；一条 QoS 流只属于一条 PDU 会话，也就只属于一个切片。两者是正交的两级服务机制，谁也不能替代谁：

```mermaid
flowchart TD
    subgraph SA["切片A：车联网包间"]
        PA["PDU会话1"] --> F1["5QI=82 关键流"]
        PA --> F2["5QI=9 普通流"]
        F1 --> D1["DRB1 专用通道"]
        F2 --> D2["DRB2 普通通道"]
    end
    subgraph SB["切片B：手机上网包间"]
        PB["PDU会话2"] --> F3["5QI=8 普通流"]
        PB --> F4["5QI=9 默认流"]
        F3 --> D3["DRB3 套餐相同可合并"]
        F4 --> D3
    end
```

## 八、实战连接：这些知识在现网哪里用得上

**看信令时**：终端建立 PDU 会话的信令里，核心网会携带 QoS 参数——默认流的 5QI（常见 9 或 8）、session-AMBR、以及会话级 ARP。开通“专属保障”类业务时，你会在会话修改流程里看到新增一条 GBR 流，带 GFBR/MFBR 数值和高优先级 ARP——所谓“网络切片保障产品”，落地时往往就是这几行参数。

**调语音质量时**：MOS 分差，第一步不是看无线覆盖，而是确认通话走的到底是不是 5QI 1。如果 GBR 准入失败，业务可能已静默降级到 Non-GBR 流——信令上看“建立成功了”，体验上却是时延抖动和丢包。**GBR 降级是静默的，这是最常见的坑。**

**查拥塞投诉时**：晚高峰某小区游戏用户集体掉线或卡顿，先看该小区的 GBR 接纳失败计数器和抢占计数器。如果语音流量把保障容量占满，后来的延迟关键业务被拒；如果某批终端的 ARP 配置过高，又会反过来频繁抢占别人。ARP 是策略，策略错了就是系统性事故。

**三个经典误区**：

1. **“5QI 只是个标签，随便设”**——标准化 5QI 的语义全球一致，配错编号等于拿着别家的套餐手册点菜，对端按另一种待遇执行，出了问题极难排查。自定义需求应走动态 5QI，而不是篡改标准编号的含义。
2. **“GBR 保障越多越好”**——GBR 是预留即占用，小站保障容量就那么多，被几条 GBR 流占满后，后续所有语音准入全部失败。GBR 要省着用，是给“真金白银买了承诺”的业务留的。
3. **“PDB 是网络承诺的最大时延”**——PDB 是设计预算，指导调度和重传参数配置；实际时延还受负载、覆盖、切换影响。拿 PDB 当 SLA 逐包验收，一定会“验收失败”。

## 常见问题

**Q: 5QI 和 4G 的 QCI 是什么关系？**
A: 一脉相承的“套餐编号”思想，5QI 是它的 5G 版本。主要变化有三点：作用对象从“承载”细化到“QoS 流”；资源类型在 GBR/Non-GBR 之外新增了“延迟关键 GBR”（5QI 80 以上那一段，PDB 压到 10～20 毫秒量级）；配套机制从“一承载一隧道”改为“流标签 + DRB 灵活映射”。

**Q: GBR 流没有数据传输时，资源是不是白占着？**
A: 是的，预留不释放，这正是它的代价。GBR 的本质是“占座”，不是“按需使用”。所以现网对 GBR 的审批很克制：语音通话、关键物联这类真正需要承诺的业务才开，普通上网流量一律 Non-GBR。

**Q: ARP 的 1 和 15，哪个优先级高？抢占开关该怎么理解？**
A: 1 最高、15 最低，两个开关独立配置。“能抢人 + 不可被抢”是最高待遇（紧急业务典型配置），“不能抢人 + 可被抢”是默认待遇。调试时记住一句：谁的抢占能力配高了，谁就可能在拥塞时踩别人一脚——测试卡误配高 ARP 抢掉生产语音，是现网真实发生过的经典事故类型。

**Q: 一条 QoS 流和一条 DRB 是一一对应吗？**
A: 不是。规则是“一条 QoS 流只能映射到一条 DRB，但多条待遇兼容的 QoS 流可以合并进同一条 DRB”。所谓待遇兼容，指的是 5QI 的转发处理特征（优先级、时延预算、误包率）一致或足够接近，合并后调度器仍能一视同仁。

**Q: session-AMBR 和 UE-AMBR 冲突时听谁的？**
A: 两者不是同一个维度的闸门：session-AMBR 管单条 PDU 会话的速率上限，UE-AMBR 管这个用户所有会话的总上限，由基站统一执行。用户开三条会话，每条各自受 session-AMBR 限制，三条加起来还不得超过 UE-AMBR——像家里每个水龙头有自己的流量，全家总表还有一道总闸。

## 参考来源

1. [5QI - Wikipedia](https://en.wikipedia.org/wiki/5QI) — 标准化 5QI 参数表与 5G QoS 体系词条（成稿时抓取受限未能核对全文，数值请以此交叉验证）
2. [5G QoS - ShareTechnote](https://www.sharetechnote.com/html/5G/5G_QoS.html) — 通信工程师常用的 5G QoS 流、QFI、SDAP 图解参考
3. Erik Dahlman, Stefan Parkvall, Johan Sköld, *5G NR: The Next Generation Wireless Access Technology*（Academic Press）— QoS 框架与空口承载映射的系统性章节
4. 樊昌信等，《通信原理》（第7版），高等教育出版社 — 排队时延与系统容量的经典直觉来源

---
> 本文由「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学通信知识星球海报-扫码加入](https://wiki.500nian.com/images/zhixingqiu_qrcode.png)
