📚 课程目录第3章 QCI概述

QCI 概述：QoS Class Identifier 的核心定义

做端到端延迟计算，绕不开一个基础概念——QCI。说白了，它就是 3GPP 给每个承载（Bearer）贴的一个“优先级标签”。标签上写明了：这个业务该给多少带宽、能忍受多大时延、丢包率多少。我刚开始接触 LTE 核心网时，总觉得 QCI 就是个数字编号，后来在优化视频卡顿问题时才发现——这数字背后藏着一整套 QoS 参数集。

1. QCI 的定义与 3GPP 标准

QCI（QoS Class Identifier）是 3GPP TS 23.203 里定义的一个标量，取值 1～9（标准定义），后来又扩展了 65～69、70～79 等。每个 QCI 值对应一组固定的 QoS 参数，包括：

资源类型：GBR（保证比特率）还是 Non-GBR（非保证比特率）
优先级：1 最高，9 最低（标准范围）
包延迟预算（PDB）：从 UE 到核心网 P-GW 的单向延迟上限
包错误丢失率（PELR）：允许的丢包率

我记得在 3GPP R8 刚出时，QCI 只有 9 个值。后来 R12、R13 陆续加了 MCPTT、V2X 等场景的专用 QCI。嗯，这里要注意：运营商自定义的 QCI（如 10～15）并不在标准规范里，但很多厂商设备支持扩展。

2. QCI 与 QoS 参数的对应关系

你想想看，一个 QCI 值就包含了“资源类型 + 优先级 + 时延 + 丢包率”四要素。我做过一个实验：把视频流从 QCI 6（Non-GBR 优先级6）改成 QCI 4（GBR 优先级4），延迟直接从 50ms 降到 20ms。为什么会这样？因为 QCI 4 是 GBR 承载，网络侧会预留资源，而 QCI 6 是共享资源。

下图是我常用的 QCI 参数映射表，它清晰地展示了 9 个标准 QCI 的差异：

QCI	资源类型	优先级	PDB（ms）	PELR	典型业务
1	GBR	2	100	10^-2	会话语音
2	GBR	4	150	10^-3	实时视频（直播）
3	GBR	3	50	10^-3	实时游戏
4	GBR	5	300	10^-6	非实时视频（点播）
5	Non-GBR	1	100	10^-6	IMS 信令
6	Non-GBR	6	300	10^-6	视频、网页浏览（默认）
7	Non-GBR	7	100	10^-3	语音聊天、交互式游戏
8	Non-GBR	8	300	10^-6	视频流（缓冲型）
9	Non-GBR	9	300	10^-6	通用数据

注意看，QCI 5 虽然也是 Non-GBR，但优先级是 1（最高）。为什么？因为它是 IMS 信令，承载 SIP 消息——丢一个包可能导致呼叫建立失败。所以我个人习惯：在核心网做 QCI 过滤时，千万别误伤 QCI 5 的流。

关键点： PDB（包延迟预算）是从 UE 到 P-GW 的单向延迟，不含空口重传时间。计算端到端延迟时，要额外加上空口调度时延、传输网抖动等。

3. QCI 与 EPS Bearer 的绑定

在 3GPP 架构里，每个 EPS Bearer 只能关联一个 QCI。你建立默认承载时，QCI 通常为 6 或 9。专用承载可以分配不同的 QCI，比如语音用 QCI 1，视频用 QCI 2。我曾在现网排查过一个故障：VoLTE 通话断续，查遍 RRC 和 PDCP 都没问题，最后发现核心网把 QCI 1 映射到了错误的 TFT 过滤器——说白了，就是语音包没走对承载。

// 3GPP TS 23.203 中 QCI 属性定义的伪代码示例
struct QCI {
    uint8_t qci_id;          // 1～9, 65～69 ...
    ResourceType res_type;   // GBR / Non-GBR
    uint8_t priority;        // 1～9 (1最高)
    uint16_t pdb_ms;         // 包延迟预算 (毫秒)
    float pelr;              // 包错误丢失率 (如 1e-2)
};

我的避坑指南： 我曾经在测试中误把 QCI 2（PDB 150ms）当成 QCI 1（PDB 100ms）去计算端到端延迟，结果客户端报告视频卡顿。后来发现是文档里的表格看串了行。建议你每次校准参数时，直接在 3GPP 官网拉最新版的 TS 23.203，别信二手整理。

4. 从 QCI 到延迟计算的关键连线

了解 QCI 的定义后，你就能明白：为什么同样是视频业务，有的 QCI 保证低延迟（QCI 3），有的允许高延迟（QCI 4）。因为底层的 PDN 网关会根据 QCI 的优先级和 PDB 来制定调度策略。

下面这张图展示了 QCI 如何与 QoS 参数、承载类型、端到端延迟挂钩：

5. 实际项目中的 QCI 过滤应用

在做 QCI 过滤时，核心就是判断每个业务流的 QCI 值是否落在允许范围内。比如企业专线要求：语音走 QCI 1，视频会议走 QCI 2，普通数据走 QCI 6。我参与过一个 MEC 项目的延迟优化，要求所有终端用户的游戏流都必须映射到 QCI 3。结果发现部分手机发起的默认承载是 QCI 6，需要核心网通过 PCRF 下发策略来修改。

⚠ 常见坑： 别以为 QCI 值越低延迟就一定越低。QCI 1 的 PDB 是 100ms，但 QCI 3 只有 50ms！因为游戏流对延迟更敏感，所以标准给它更紧的预算。我个人习惯是在做延迟预算表时，把 QCI 与 PDCP 层 RTT 实测值交叉验证，避免照本宣科。

最后提醒一句：3GPP 定义的 QCI 参数是单向标准。实际组网中，核心网到 RAN 的回传网络、传输设备的缓存配置，都会影响最终延迟。把这些因素叠加到 QCI 的 PDB 上，才是真实的端到端延迟预算。