<!-- title: 5G QoS体系：数据包的优先级护照 -->

# 5G QoS体系：数据包的优先级护照

## 从生活场景理解QoS

想象你站在机场安检口。头等舱旅客走快速通道，5分钟通过；经济舱旅客排长队，30分钟才能登机。航空公司不会让所有旅客挤同一条队列——因为不同旅客对时间的敏感度完全不同。

移动网络面对的是同样的问题。视频通话的数据包延迟超过150ms，你就会感到明显的卡顿；而一条微信消息晚到500ms，你根本察觉不到。如果把所有数据包塞进同一条"队列"平等对待，实时业务体验会灾难性下降。

**QoS（Quality of Service，服务质量）** 就是移动网络中的"安检分流系统"——它给每个数据包贴上优先级标签，让紧急的先走，不急的排队，确保不同业务在共享的无线资源上各得其所。

## 一、4G与5G QoS的核心差异

### 4G时代的"管道"模型

在4G LTE中，QoS的基本单位是**EPS承载（Bearer）**。每个承载是一段从手机到PGW的"专用管道"，所有经过同一承载的数据包享受相同的QoS待遇。4G定义了从1到9的标准化QCI（QoS Class Identifier），每个QCI对应一组预定义的参数。

问题在于：**每建立一个承载，就需要一整套信令交互**。如果你想同时看视频、打电话、下文件，理论上需要建立3条专用承载。这在4G时代勉强够用，但当5G要同时支持上百种业务时，承载模型的扩展性就显得捉襟见肘。

### 5G的"流"模型革命

5G彻底抛弃了承载模型，引入了全新的两层QoS架构：

| 维度 | 4G EPS承载 | 5G QoS流 |
|------|-----------|---------|
| QoS基本单位 | EPS Bearer | QoS Flow |
| 粒度 | 粗（每业务一条承载） | 细（每条流独立参数） |
| 信令开销 | 高（需建专用承载） | 低（默认会话内动态添加流） |
| 可扩展性 | 有限（最多约11条） | 灵活（理论上无上限） |
| 核心控制节点 | MME | SMF |

```mermaid
graph TB
    subgraph "4G QoS架构"
        UE4["UE"] --> eNB["eNodeB"]
        eNB --> SGW["S-GW"]
        SGW --> PGW["P-GW"]
        PGW -. "建立专用承载" .-> MME4["MME"]
        MME4 -. "承载建立信令" .-> eNB
    end

    subgraph "5G QoS架构"
        UE5["UE"] --> gNB["gNodeB"]
        gNB --> UPF["UPF"]
        UPF -. "PFCP会话修改" .-> SMF5["SMF"]
        SMF5 -. "QoS流建立/修改" .-> PCF["PCF"]
        PCF --> UDM["UDM"]
    end

    style MME4 fill:#ff9999
    style SMF5 fill:#99ccff
    style PCF fill:#99ff99
```

5G的核心创新是**将QoS控制从"建管道"变成"贴标签"**。SMF（Session Management Function）可以随时在已有的PDU会话中创建新的QoS Flow，无需重建整个会话，信令开销大幅降低。

## 二、5QI：5G的QoS身份证

### 5QI的本质

**5QI（5G QoS Identifier）** 是一个标量索引值，指向一组预定义的QoS参数。你可以把它理解为"机票舱位代码"——F代表头等舱，Y代表经济舱，每个代码背后对应不同的服务标准。

5QI最核心的三个参数：

| 参数 | 含义 | 类比 |
|------|------|------|
| **Resource Type** | 资源类型：GBR / Delay-critical GBR / Non-GBR | 有座票 / 紧急有座票 / 站票 |
| **Default Priority Level** | 优先级（1-127，越小越高） | 登机顺序 |
| **Packet Delay Budget** | 包延迟预算（ms） | 最晚到达时间 |
| **Packet Error Rate** | 丢包率要求 | 行李丢失容忍度 |
| **Default Max Data Burst Volume** | 最大数据突发量（仅Delay-critical GBR） | 行李超重限制 |

### 标准化5QI一览

5G定义了30多个标准化5QI值，以下是最常用的几类：

| 5QI | 资源类型 | 优先级 | 延迟预算 | 丢包率 | 典型业务 |
|-----|---------|--------|---------|--------|---------|
| 1 | GBR | 20 | 100ms | 10⁻² | VoLTE语音 |
| 2 | GBR | 40 | 150ms | 10⁻³ | 视频通话 |
| 4 | Non-GBR | 70 | 300ms | 10⁻⁶ | 非会话视频 |
| 7 | Non-GBR | 70 | 100ms | 10⁻³ | 语音/视频/IM |
| 9 | Non-GBR | 90 | 300ms | 10⁻⁶ | 默认互联网 |
| 80 | Non-GBR | 68 | 10ms | 10⁻⁶ | 低延迟云游戏 |
| 84 | Delay-critical GBR | 3 | 10ms | 10⁻⁵ | 工业自动化 |
| 85 | Delay-critical GBR | 5 | 5ms | 10⁻⁵ | 电力争控 |

### 三种资源类型的本质区别

```mermaid
graph LR
    subgraph "GBR - 保证比特速率"
        G1["专用资源预留"] --> G2["无论网络多拥塞<br/>速率不低于保证值"]
        G2 --> G3["例子：VoLTE语音<br/>需要64kbps保证"]
    end

    subgraph "Non-GBR - 尽力而为"
        N1["不预留固定资源"] --> N2["网络空闲时高速<br/>拥塞时降速"]
        N2 --> N3["例子：网页浏览<br/>能快则快，慢点也行"]
    end

    subgraph "Delay-critical GBR<br/>5G新增"
        D1["严格延迟+速率保证"] --> D2["必须在N毫秒内送达<br/>超时即丢弃"]
        D2 --> D3["例子：工业控制<br/>5ms内必须到达"]
    end

    style D1 fill:#ff9966
    style G1 fill:#66ccff
    style N1 fill:#99ff99
```

**为什么5G要新增Delay-critical GBR类型？** 因为4G的GBR只保证速率，不保证极端低延迟。工业控制场景要求"5ms内必须收到，否则停机"，这在4G的QoS框架中无法表达。5G通过引入Delay-critical GBR + 最大数据突发量（MDBV）的组合，实现了对确定性通信的支持。

## 三、QoS Flow的生命周期

### 从数据包到QoS Flow的映射

整个QoS体系运作的核心问题：**一个IP数据包到达UPF时，如何决定它属于哪条QoS Flow？**

答案是一套**包检测规则（PDR, Packet Detection Rule）**。SMF在建立QoS Flow时，会同时下发PDR给UPF，规则中包含：

- **SDF过滤器**：基于五元组（源/目的IP、源/目的端口、协议号）匹配
- **应用ID**：基于深层包检测（DPI）识别应用
- **以太网过滤器**：基于MAC地址、VLAN标签匹配

```mermaid
flowchart TD
    A["上行数据包到达UE<br/>或下行数据包到达UPF"] --> B{"匹配PDR规则"}
    B -->|"五元组匹配"| C["确定QFI值"]
    B -->|"应用ID匹配"| C
    B -->|"无匹配规则"| D["使用默认QoS Flow<br/>QFI=9 互联网流量"]
    C --> E["标记QFI标签"]
    E --> F{"资源类型判断"}
    F -->|"GBR Flow"| G["检查令牌桶<br/>确保速率不超过GFBR"]
    F -->|"Non-GBR Flow"| H["按优先级排队<br/>尽力转发"]
    F -->|"Delay-critical GBR"| I["检查延迟预算<br/>超时则丢弃并告警"]
    G --> J["空口调度传输"]
    H --> J
    I --> J

    style D fill:#ffcc99
    style G fill:#66ccff
    style I fill:#ff9966
```

### QFI：数据包的"舱位标签"

**QFI（QoS Flow Identifier）** 是封装在每个数据包头的标识符，取值范围0-63。当数据包在UE和UPF之间传输时，QFI嵌在GTP-U隧道头或反射QoS指示中，沿途每个节点看到QFI就知道该怎么处理这个包。

关键设计原则：**QFI只在核心网和空口有意义，在互联网侧不可见**。这意味着运营商的QoS策略不会泄露给外部网络。

## 四、ARP与优先级抢占

### ARP的三维控制

如果说5QI决定了一个数据包"享受什么待遇"，那么**ARP（Allocation and Retention Priority）** 决定了"在资源不够时，谁先被牺牲"。

ARP包含三个维度：

| ARP参数 | 含义 | 取值 |
|---------|------|------|
| **Priority** | 抢占优先级 | 1-15（越小越高） |
| **Pre-emption Capability** | 能否抢占别人 | Yes / No |
| **Pre-emption Vulnerability** | 能否被别人抢占 | Yes / No |

### 抢占场景举例

```mermaid
sequenceDiagram
    participant VIP as VIP语音用户<br/>(ARP=1, Cap=Yes)
    participant ORD as 普通数据用户<br/>(ARP=10, Vul=Yes)
    participant NW as 网络调度器
    
    Note over NW: 小区满负荷运行
    
    VIP->>NW: 发起VoNR通话请求
    NW->>NW: 检查：无线资源不足
    NW->>NW: VIP的ARP=1可抢占<br/>ORD的ARP=10可被抢占
    NW->>ORD: 强制降低ORD速率<br/>释放部分资源
    NW->>VIP: 分配GBR资源<br/>保证通话质量
    
    Note over NW: VIP通话结束后<br/>ORD恢复原有速率
```

**实战中的陷阱：** 很多工程师误以为5QI的优先级就是抢占优先级。实际上，5QI Priority决定的是**日常调度顺序**（谁先发），而ARP Priority决定的是**生死存亡**（资源不够时谁被踢）。两者完全独立，必须配合使用。

## 五、GFBR与MFBR：速率保证的双边界

### 保证速率与最大速率

5G引入了比4G更精细的速率控制参数：

$$GFBR \leq 实际速率 \leq MFBR$$

- **GFBR（Guaranteed Flow Bit Rate）**：保证的流比特速率——网络承诺的最低速率
- **MFBR（Maximum Flow Bit Rate）**：最大的流比特速率——网络允许的最高速率

为什么需要上限？想象你开了一个GBR的VoLTE语音流（GFBR=64kbps）。如果没有MFBR，手机可能因为信号好而把速率冲到1Mbps，白白浪费无线资源。MFBR=128kbps就能把语音流的速率牢牢限制在合理范围内。

### 会话级AMBR

除了每条Flow的速率限制，5G还有**Session-AMBR**——一个PDU会话内所有Non-GBR Flow的总速率上限。这是运营商控制单用户"胃口"的关键手段：

| AMBR类型 | 作用域 | 谁设置 |
|----------|--------|--------|
| UE-AMBR | 终端所有PDU会话 | UDM签约数据 |
| Session-AMBR | 单个PDU会话 | SMF/PCF |

**工程意义：** 你在运营商APP上买的"500Mbps套餐"，对应的就是Session-AMBR。但这只约束Non-GBR流量——如果你同时在打VoLTE电话（GBR流量），语音的64kbps不受500Mbps上限影响。

## 六、网络切片与QoS的协同

### 切片：逻辑上的"虚拟运营商"

网络切片和QoS是两个不同维度的概念，但经常被混淆：

| 维度 | 网络切片 | QoS |
|------|---------|-----|
| 分割对象 | 网络资源（计算、存储、带宽） | 数据流优先级 |
| 粒度 | 一组用户/业务共享一个切片 | 每条数据流独立QoS参数 |
| 目标 | 逻辑隔离 | 差异化服务 |
| 类比 | 一栋楼隔成多个独立办公室 | 同一办公室内的优先级排序 |

**切片是"楼层"，QoS是"楼层内的VIP通道"。** 一个eMBB切片内，视频流是5QI=2（高优先级），而后台下载是5QI=9（低优先级）。两者共享切片资源，但通过不同5QI享受不同待遇。

### S-NSSAI：切片选择标签

每个切片用**S-NSSAI**标识，包含：
- **SST（Slice/Service Type）**：切片类型（1=eMBB, 2=URLLC, 3=MIoT）
- **SD（Slice Differentiator）**：切片区分符（同一类型下的不同实例）

当终端发起PDU会话时，会携带S-NSSAI，AMF据此选择对应的SMF和UPF，将流量引导到正确的切片资源池。

## 七、端到端QoS的实际路径

```mermaid
flowchart TD
    subgraph "终端侧"
        UE["UE"] --> AS_RULE["AS层规则<br/>QFI→逻辑信道映射"]
    end

    subgraph "无线侧"
        MAC["gNodeB MAC调度"] --> PHY["物理层资源分配"]
        PHY --> RATE["速率匹配<br/>基于GFBR/MFBR"]
    end

    subgraph "核心网侧"
        UPF_NODE["UPF"] --> PDR_MATCH["PDR匹配<br/>包检测+QFI标记"]
        PDR_MATCH --> GTP["GTP-U隧道<br/>QFI封装在头中"]
    end

    AS_RULE --> MAC
    RATE --> UPF_NODE
    GTP --> DN["数据网络<br/>(Internet/IMS)"]

    style UE fill:#e6f3ff
    style MAC fill:#fff3e6
    style UPF_NODE fill:#e6ffe6
```

**端到端QoS的关键节点：**

1. **UPF下行方向**：数据包到达UPF → PDR匹配 → 标记QFI → 通过GTP-U隧道发给gNB
2. **gNB空口调度**：根据QFI对应的5QI参数（优先级、延迟预算）决定调度顺序
3. **UE上行方向**：UE根据SMF下发的QoS规则，将上行数据映射到对应QoS Flow

每个环节都可能成为瓶颈。工程师排查QoS问题时，需要逐段检查：**UPF的PDR配置是否正确 → gNB的调度策略是否生效 → UE的QoS规则是否下发**。

## 八、反射QoS：5G的智能简化

### 什么是反射QoS？

传统方式下，SMF需要通过信令向UE下发QoS规则（告诉UE"哪些上行流量走哪条Flow"）。5G引入了一种更简洁的机制——**反射QoS（Reflective QoS）**：

**核心思想：** UE观察下行数据包的QFI标记，自动学习"这种流量应该走这条Flow"，然后对上行流量使用相同的映射规则。

```mermaid
sequenceDiagram
    participant SMF
    participant UPF
    participant gNB
    participant UE
    
    SMF->>UPF: 安装PDR规则<br/>启用反射QoS指示(RQI)
    UPF->>gNB: 下行数据包<br/>QFI=1, RQI=1
    gNB->>UE: 转发数据包<br/>携带RQI标记
    UE->>UE: 学习：这类上行流量<br/>应映射到QFI=1
    UE->>gNB: 上行数据包<br/>自动标记QFI=1
    Note over UE: 无需SMF显式<br/>下发上行QoS规则
```

**好处是什么？** 省信令。传统方式中，每条上行QoS规则都需要NAS信令从SMF传到UE。反射QoS让UE自己"看中学"，大大减少了控制面负载。据统计，在典型网络中约70%的上行QoS Flow使用反射QoS，仅30%使用显式信令规则。

## 九、PCF策略控制：QoS的大脑

PCF（Policy Control Function）是5G QoS体系的策略决策中心。它根据用户签约数据、业务特征、网络状态，动态生成PCC规则下发给SMF执行。

**PCF的核心输入：**
- **UDM签约数据**：用户套餐中的5QI、ARP、AMBR等
- **AF请求**：应用服务器（如IMS）请求特定QoS
- **网络状态**：当前负载、切片资源使用情况

**PCF的核心输出：**
- **PCC Rule**：包含5QI、ARP、GFBR、MFBR、计费键等
- **QoS Monitoring**：实时监控GBR流的延迟和丢包

当IMS服务器发起VoNR通话时，流程是：IMS的AF向PCF发请求 → PCF生成PCC规则（5QI=1, GBR, Priority=20）→ PCF下发给SMF → SMF创建新QoS Flow并通过N4接口配置UPF → 整条链路为语音通话保驾护航。

## 十、工程调试实战

### 常见QoS问题排查

| 现象 | 可能原因 | 排查方法 |
|------|---------|---------|
| 语音通话质量差 | QoS Flow未建立或5QI错误 | 检查SMF日志：是否创建了5QI=1的GBR Flow |
| 游戏延迟高 | 数据走了默认Non-GBR Flow | 检查UPF的PDR规则：游戏流量是否匹配到低延迟5QI |
| 切片内速率不达标 | Session-AMBR设置过低 | 查询UDM签约数据和SMF会话参数 |
| 视频卡顿但语音正常 | 视频流的GFBR未保证 | 检查gNB调度统计：GBR Flow的资源分配率 |
| 上行速率异常 | 反射QoS学习失败 | 检查UE日志：是否收到RQI标记，是否生成上行规则 |

### 抓包验证QFI

在核心网抓包时，可以通过解析GTP-U头来验证QFI：

```
GTP-U Header:
  Flags: 0x34
  Message Type: T-PDU (0xff)
  Tunnel Endpoint Identifier: 0x12345678
  Extension Header:
    QoS Flow Identifier (QFI): 1  ← 这里就是QFI
    Reflective QoS Indicator (RQI): 1
```

如果看到VoLTE语音包的QFI不是1，或者视频包的QFI走了默认Flow，那就是QoS映射出了问题。

## 常见问题

**Q: 5QI和QFI是什么关系？**
A: 5QI是QoS参数的"索引编号"，指向一组预定义的延迟、丢包率等参数。QFI是数据包头中的"标签值"，用于标识这个包属于哪条QoS Flow。一条QoS Flow有一个QFI，同时关联一个5QI。简单说：5QI描述"怎么对待"，QFI描述"你是谁"。

**Q: 为什么不把所有流量都设为GBR保证最高质量？**
A: GBR需要预留固定无线资源。如果100个用户都申请GBR=10Mbps，基站需要预留1Gbps——这在无线环境中是不可能的。无线资源是共享的稀缺资源，GBR必须严格按需分配。Non-GBR流量的"尽力而为"不是偷工减料，而是网络效率最大化的必然选择。

**Q: 切片和QoS可以完全替代对方吗？**
A: 不能。切片提供资源隔离（防干扰），QoS提供优先级调度（保体验）。一个URLLC切片内仍然需要5QI=84来保证工业控制包的极低延迟。两者是正交的维度，缺一不可。

**Q: 反射QoS在什么场景下不适用？**
A: 反射QoS要求UE先收到下行包才能学习上行映射。对于纯上行业务（如传感器上报），没有下行触发，反射QoS无法工作，此时必须使用显式信令下发QoS规则。

**Q: ARP抢占在实际网络中常用吗？**
A: 运营商通常非常谨慎地使用抢占功能。在中国三大运营商的网络中，ARP抢占主要用于紧急呼叫（优先级最高）和VIP用户保障。普通用户之间一般不会互相抢占，而是通过调度权重差异化来间接实现优先级。

## 参考来源

1. [3GPP TS 23.501 - System Architecture for the 5G System](https://www.3gpp.org/DynaReport/23501.htm) — 5QI标准化参数定义的权威来源
2. [5G QoS Explained - ShareTechnote](https://www.sharetechnote.com/html/5G/5G_QoS.html) — 通俗易懂的5G QoS架构图解
3. [Qualcomm - 5G Quality of Service](https://www.qualcomm.com/content/dam/qcomm-martech/dm-assets/documents/5G_QoS_Whitepaper.pdf) — 端到端QoS机制的工程实现视角
4. [IEEE Communications Magazine - QoS in 5G Networks](https://ieeexplore.ieee.org/xpl/RecentIssue.jsp?punumber=35) — 学术界对5G QoS架构的分析
5. [华为5G核心网技术白皮书](https://www.huawei.com/cn/) — QoS Flow与切片协同的工程实践

---
> 本文由「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)