# 三个数字管传输，三个开关管准入：5QI与ARP参数原理 ## 一个拥塞小区里的对照实验 晚高峰，某居民区小区负载飙红。用户投诉：微信语音断断续续，但VoNR电话（运营商自己的高清通话）却一路清晰。两种语音的带宽需求几乎一样，编码速率甚至微信更低——为什么待遇天差地别？ 抓一份信令看答案：VoNR的话音流，网络给它贴的标签是 **5QI=1**；微信语音走的OT大管道，标签是 **5QI=9**。这串数字的差异，不是“网速快慢”的差异，而是“服务条款”的差异：一条写着“每秒给你保底多少、迟到多少算超时、丢几个包算合格、排队时你站第几排”；另一条只写着“大家共享，尽力而为”。 5G的QoS体系里其实有两套编号，分工完全不同： - **5QI**：三个数字管“怎么传”——调度优先级、时延预算、丢包上限； - **ARP**：一个数字加两个开关，管“能不能进来、必要时谁让路”。 理解了这两套编号各自“被谁消费”，QoS就不再是玄学，而是一张能查、能算、能排障的账本。 ## 为什么要编号：套餐哲学 先回答一个更根本的问题：为什么要发明编号，而不是每次建会话都把参数原样传一遍？ 假设每次建立语音会话，终端和核心网之间都要协商：“转发时延不超过100毫秒、丢包率低于百分之一、调度权重设为20、平均窗口100毫秒……”——信令又臭又长，而且不同设备商对每个字段的实现口径难免有偏差。漫游到国外，对方网络更不知道该按什么标准伺候你的电话。 编号就是**套餐化**：把一整套经过行业共识的服务参数打包，起个号。就像全世界任何一家麦当劳，你说“1号套餐”，端上来的都是一个味。**5QI=1在任何一家设备商建的网络里，语义完全相同**——这就是标准化5QI的使命：跨厂商、跨运营商、跨国漫游时的体验一致性。 ```mermaid flowchart TD A["业务签约与策略"] --> B{"参数能不能套标准餐"} B -->|能| C["选标准化5QI
只传一个编号"] B -->|不能| D["用动态5QI
编号大于等于128
参数随信令自带"] C --> E["全网语义统一
信令最省"] D --> F["参数自定义
但失去跨网一致性"] ``` 套餐化的附带好处是省信令：一个整数代替一串参数，在每条会话建立信令里都要重复携带的场景下，这个节省是乘以亿级用户数的。 ## 三个数字，各自被谁消费 先看一张速查表。这是最常用的几个标准化5QI（节选，完整表以标准文档为准）： | 5QI | 资源类型 | 典型业务 | 调度优先级 | 时延预算PDB | 丢包上限PELR | 平均窗口 | |---|---|---|---|---|---|---| | 1 | GBR | 语音通话 | 20 | 100ms | 10⁻² | 100ms | | 2 | GBR | 视频通话 | 40 | 150ms | 10⁻³ | 150ms | | 3 | GBR | 实时游戏 | 30 | 50ms | 10⁻² | 50ms | | 5 | 非GBR | IMS信令 | 10 | 100ms | 10⁻⁶ | — | | 7 | 非GBR | 直播/互动游戏 | 70 | 100ms | 10⁻³ | — | | 9 | 非GBR | 默认上网 | 90 | 300ms | 10⁻⁶ | — | | 82 | 时延关键GBR | 车联网V2X | 19 | 10ms | 10⁻⁴ | 2ms | 表里每一个数字都不是装饰——它们各自有明确的“消费者”。一张图看清去向： ```mermaid flowchart TD Q["一个5QI
三个关键数字"] --> P["调度优先级"] Q --> D["时延预算PDB"] Q --> L["丢包上限PELR"] P --> C1["空口调度器
决定排队先后"] D --> C2["调度打分与
抖动缓冲设计"] L --> C3["HARQ与RLC
重传预算"] ``` ### 数字一：优先级——排队号的号码 调度优先级回答一个问题：空口资源有限时，哪个流的包先上传输机会？规则很简单：**数字越小，越优先**。 表里有个反直觉的细节：IMS信令（5QI=5，优先级10）比语音（5QI=1，优先级20）排得还靠前。为什么？因为信令是业务的前提——SIP邀请都发不出去，何谈通话质量？控制面永远先行，这是全网铁律。看表时先看这一行，很多“业务参数”的设计直觉就通了。 还有一个容易混淆的点：标准化5QI自带默认优先级，但网络在信令里也可以显式携带优先级进行改写。所以现网信令里看到的优先级，未必等于表里的默认值——排查时以信令实值为准。 ### 数字二：PDB——一张倒计时的时间表 时延预算PDB回答的问题是：一个包从终端到互联网出口（或反方向），允许的最大累计时延是多少？而且不是“平均努力一下”，是**99%的包都必须达标**——这条硬约束才是它和“尽力而为”的本质区别。 PDB不是铁板一块，它有官方拆解： $$PDB_{总} = PDB_{核心网} + PDB_{接入网}$$ 以语音（5QI=1）为例： $$100ms = 20ms + 80ms$$ 这20ms的核心网预算里，藏着一个精巧的设计：**UE的抖动缓冲**。语音解码器不能来一个包播一个包——网络抖动会让播放忽快忽慢，所以终端要先攒一小段包再匀速播放。标准干脆把这段“攒包时间”正式编进预算，剩下的80ms才是留给空口调度的真预算。一张下行语音包的倒计时之旅是这样的： ```mermaid flowchart TD A["语音服务器发包"] --> B["UPF转发
核心网预算20ms"] B --> C["基站调度器
空口预算80ms"] C --> D["UE抖动缓冲
攒包匀速"] D --> E["解码器按时播出"] ``` 调度器怎么消费PDB？直觉化的理解是打分：每个排队的包都有一个“剩余预算”，离超时越近的包越该优先发射。可以把它想象成一个按紧迫度放大的权重： $$w \propto \frac{1}{T_{剩余}}$$ 这样“刚来的包”和“快超时的包”之间就形成动态平衡——既不让新包饿死，也不让老包超时。具体打分算法各厂家自有实现，标准允许多种实现，但给每个包发一张“倒计时表”这个思路是共通的。 GBR类流量还有一个第四参数：**平均窗口**。GBR承诺的保底速率（GFBR）是“平均值意义上的保底”，平均窗口就是求平均用的那把尺子： $$\frac{窗口内送达比特数}{平均窗口} \ge GFBR_{承诺}$$ 普通GBR的尺子默认就取PDB的时长；而时延关键GBR（V2X那一批）把尺子压到了2ms量级——意思是车联网的“保底”是每2毫秒就要兑现一次，不是每100毫秒结算一次。窗口越短，承诺越“硬”，调度器越需要提前把资源拍死，这也是时延关键GBR比普通GBR“贵”得多的原因。 ### 数字三：PELR——丢包预算决定重传策略 丢包上限PELR的写法是10⁻ⁿ，意思是每10ⁿ个包最多允许丢一个。表里两个极端很有代表性： - **语音只要10⁻²**：一万个包丢一百个照样能用。人耳对瞬间丢字有强大的脑补能力，丢了这一帧，下一帧补上就行； - **上网信令要10⁻⁶**：一百万个包只许丢一个。文件错一个字节，上层就得整体重来，代价远大于空口多传几次。 PELR到了空口会转化成HARQ与RLC的重传预算：丢包要求越苛刻，越要舍得花重传次数。而重传是有代价的——它吃的是同一个PDB。所以**PDB和PELR是一对跷跷板**：总预算有限，要准时就得容忍丢，要不丢就得接受迟到。语音选了“准时”，文件传输选了“不丢”，实时游戏（5QI=3，50ms+10⁻²）选了“又准时又容忍丢”——它靠预测和状态同步自愈，每帧都关键，但丢一帧还有下一帧。 ## 另一套号码：三个开关管准入 5QI管的是“进来之后怎么传”。但还有一个更前置的问题：**资源不够时，让不让你进来？让进来的话，挤掉谁？** 这就是ARP（分配与保留优先级）的领地。打个比方：停车场满员，救护车要进场，保安可以让一辆普通车挪位。挪不挪、该不该挪，看的是停车场管理规则，跟车的马力（5QI）无关——这就是两套编号的分工。 ARP由三个字段组成： 1. **ARP优先级**：1到15，1最高。注意，这也是数字小者优先——但它在**准入柜台**生效，不进空口调度器； 2. **抢占能力**：你能不能挤掉别人； 3. **抢占脆弱性**：你能不能被别人挤掉。 | 对比维度 | 5QI | ARP | |---|---|---| | 回答的问题 | 进来之后怎么传 | 凭什么进来、谁该让路 | | 核心字段 | 优先级、PDB、PELR（GBR再加平均窗口） | 优先级1-15、抢占能力、抢占脆弱性 | | 生效阶段 | 会话全程持续生效 | 建立与修改的瞬间 | | 空口调度器是否感知 | 直接消费 | 不感知 | | 生效位置 | 调度、缓冲、重传全链路 | 准入判决与抢占执行 | 资源不足时的完整决策逻辑是一棵决策树： ```mermaid flowchart TD A["终端请求建立会话"] --> B{"准入资源够吗"} B -->|够| C["准入通过
正常分配资源"] B -->|不够| D{"请求方带抢占能力吗"} D -->|不能| E["拒绝建立
附带回绝原因"] D -->|能| F["在网流里找
脆弱且优先级更低者"] F --> G["释放对方腾出资源"] G --> C ``` 这里藏着**全文最重要的一个澄清，也是最常见的误解**：ARP不是实时优先级。它只在会话建立或修改的那一瞬间起作用——准入通过之后，ARP就退场了，运行中的每一个包怎么排队、怎么重传，看的全是5QI那套参数。把ARP当成“拥塞时的实时插队器”，是调参时最常见的方向性错误。 被抢占的一方也不是默默断线。对语音流（5QI=1且ARP优先级落在最高那一档，即1到4）标准有专门安排：抢占导致的释放要走专门流程、给出明确原因值，终端据此提示用户“通话被网络释放，请重拨”，而不是让用户对着无声的话筒懵掉。说到底，5QI和ARP合起来才是一张完整的服务合同：**5QI决定进来后怎么伺候，ARP决定凭什么进来、必要时谁让路。** 至于GBR与非GBR在准入上的差别，一句话就够：GBR流准入时要查“保底带宽的账上还有没有富余”，真不够就得拒或抢；非GBR流本来就承诺不了带宽，通常不做资源预留直接放行。 ## 和切片是什么关系 一句话定位：切片是**管道级**的粗承诺——整条专线在接入网、传输网、核心网的隔离与资源保障；5QI是**水流级**的细承诺——同一条管道里，语音、信令、大文件各自怎么被对待。切片之内仍然要靠5QI区分三六九等，两者是包含关系，不是替代关系。切片的架构原理另文已详，此处不展开。 ## 现网怎么用：三处会见到它 **信令侧**：PDU会话建立与修改流程中，终端侧的QoS规则和N2接口的QoS描述里都能读到5QI与ARP三元组。抓N2/N3信令用Wireshark解开，QoS参数一目了然——这是验证“策略到底下发成功没有”的第一手证据。 **话统与告警侧**：准入拒绝、抢占释放都有专门的计数器。处理拥塞投诉时，先查这两个计数器：如果大量准入拒绝或抢占发生，问题在“门票规则”层面；如果准入正常但体验差，问题在“传输待遇”层面，再去查空口。一步分叉，省掉一半排障时间。 **调参侧**：给新业务定QoS，第一原则是**优先选标准化5QI**，只有确实没有合适套餐时才考虑动态5QI——编号意味着跨网一致性，动态参数意味着每次都要靠信令把参数带全，而且别人家网络不认识它。 ### 三个调试陷阱 1. **把ARP当实时优先级**：想调“拥塞时谁优先”，改ARP没用——它只在准入那一刻起效，运行中的排队顺序由5QI优先级决定。两个都要动，但要分清各管哪一段。 2. **记反“数字越小越优先”**：5QI优先级和ARP优先级都是小者胜出，很多人按“分数高者赢”的直觉把方向调反，结果高价值业务反而垫底。改完参数后，务必用信令实值复核。 3. **拿GBR当无限保险**：GBR保的是平均值口径下的速率底线，且以网络准入为前提。资源真不够时，网络的选择是拒绝准入或释放并通知，不是无限兜底。测得“GBR流也卡”，先查它有没有真正被准入，再查空口。 ## 常见问题 **Q: 5QI=8和5QI=9有什么区别？** A: 参数几乎完全一样——都是非GBR、300ms、10⁻⁶，仅优先级80与90之差，实际体验无感。两者的存在主要是历史惯性：分别继承自4G时代的两个默认承载编号，运营习惯不同选择了不同默认值。看到它们不必大惊小怪。 **Q: 优先级数字越小越优先，为什么这样“反人类”设计？** A: 这是行业惯例的延续——各类优先级字段普遍沿用“1号是最重要”的排序直觉（如跑道优先级、救援等级）。5QI优先级的取值空间比ARP大得多（标准化编号常用值在10到90之间），但它俩方向一致，记一个“小者优先”就够了，反倒是“高数值=高优先”的错误直觉最危险。 **Q: ARP优先级设成1，是不是拥塞时我的业务永远优先？** A: 不是。ARP=1只保证“准入时你是最后一个被拒的、第一个被让路的”，进网之后排队看的是5QI优先级。而且抢占是双向票据：想抢别人，你必须是“有抢占能力”；不想被抢，要配“无抢占脆弱性”——三个字段组合才算完整的攻防策略。 **Q: 为什么语音的抖动缓冲要算在核心网的20ms预算里？** A: 因为缓冲发生在接收端（UE），但它消耗的时延发生在空口之后、解码之前的环节，标准把它归入核心网段预算，是为了让接入网调度器拿到的那80ms是“纯空口预算”——调度器不用替解码器背缓冲的时间债，两边职责干净分离。 **Q: 动态5QI和标准化5QI到底怎么选？** A: 默认选标准化。它换来的是全网设备语义一致、信令最省、排障时人人看得懂。只有业务参数确实无套餐可套（比如某些行业专网的特殊时延档位），才用大于等于128的动态5QI自定义参数——代价是失去跨网一致性，且每个网元都要正确解析随信令携带的完整参数。 ## 参考来源 1. [ShareTechnote: 5G QoS](https://www.sharetechnote.com/html/5G/5G_QoS.html) — 5G QoS架构、5QI参数表与N2/NAS信令字段的工程速查手册 2. [Wikipedia: Quality of Service](https://en.wikipedia.org/wiki/Quality_of_service) — QoS通用概念、资源预留与优先级机制的背景知识 3. [Wikipedia: 5G](https://en.wikipedia.org/wiki/5G) — 5G网络架构与业务场景（eMBB/URLLC）的通识背景 --- > 本文由「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 等场景全覆盖。