# 订座与让座：GBR资源预留原理 ## 一通视频电话背后，有一份你看不见的合同 你按下视频通话键的瞬间，网络里发生了一件很「较真」的事：基站要翻开自己的账本，确认空口资源还有没有富余；核心网要签发一份写明速率、时延、优先级的参数清单；沿途每个节点都要在这笔账上签字画押。整个过程像极了航空公司处理一个订座请求——座位不够时，要么拒载，要么按会员等级请别人下机。 这份「合同」就是5G QoS里最核心的一组机制：**GBR（Guaranteed Bit Rate，保证比特率）资源预留**与**ARP（Allocation and Retention Priority，分配与保持优先级）抢占**。上一轮我们聊过5QI这张「套餐编码表」，也聊过调度器每天怎么排班。这一轮往下挖一层：**一份速率承诺是怎么签下来的、怎么监管执行的、资源紧张时谁必须让座**。这三个问题合起来，才是「服务质量」从纸面承诺变成空口现实的完整链条。 ## 一、为什么「保证」在无线里是个奢侈词 要理解GBR机制为什么长这样，得先接受一个残酷前提：**无线的「保证」天生比有线贵**。 光纤里预留一条管道，只要光路通了，这条管道的容量几乎是恒定的，承诺一万兆就是一万兆。而空口的容量是「呼吸」的：一个用户从基站近处走到角落，谱效率可能从每符号几个比特掉到零点几；一场雨、一辆大巴的遮挡、隔壁小区的话务高峰，都会让同一片资源块的「实际产量」剧烈波动。 所以在光网里，「预留」是个静态动作，签完合同基本不用管。而在空口里，「保证」必须拆成三道工序才成立： 1. **事前准入**——签合同的时刻就得拍板：这块地到底养不养得活你的承诺？养不活就别签，免得双方违约； 2. **事中监管**——合同保的是GFBR以内的流量，超出部分没买票，得有人逐包把没买票的流量拦下来，防止一颗老鼠屎坏一锅粥； 3. **事后让座**——万一真的不够了（比如用户移动到了差覆盖区，或突发大话务），必须有一套事先约定好的规则决定谁被挤掉，而不是现场吵架。 这三道工序分别对应三组参数：准入看**GFBR与ARP**，监管看**MFBR**，让座看**ARP的抢占三件套**。整章机制的设计逻辑，一句话就能概括：**把「保证」从一个形容词，变成一套可以签字、可以审计、可以执行的流程。** ## 二、两种车票：GBR与非GBR的根本分野 网络里的每一条QoS流，从建立那一刻起就被分成了两种车票： | 对比项 | GBR 保障流 | Non-GBR 非保障流 | |---|---|---| | 一句话承诺 | 低于GFBR就是网络违约 | 尽力而为，按优先级排队 | | 速率参数 | GFBR保底 + MFBR封顶 | 只有会话级汇总闸刀AMBR | | 准入方式 | 建立时逐节点查库存，不够就拒或抢 | 不按速率准入，来了就收 | | 拥塞时的表现 | GFBR以内优先兑现，用户基本无感 | 大家按优先级瓜分剩余资源 | | 资源成本 | 高，承诺必须留余量 | 低，见缝插针填空隙 | | 典型业务 | 语音通话、视频会议、实时对战游戏 | 网页浏览、视频点播、下载、后台同步 | 为什么不能全发「坐票」？设想一个把所有流量都做成GBR的网络：每来一个网页请求，基站都得为它预留一段「万一塞车也够用」的资源。而网页、点播这类弹性流量的真实速率像心跳一样起伏，预留量只能按峰值算——结果就是资源利用率暴跌，大量承诺好的资源在一分钟里有大半时间是空转的。反过来，弹性业务本身有缓冲垫：视频播完前十秒，后十秒晚到几十毫秒，观众毫无知觉。 所以设计者做了一个经济学决策：**只给「迟不得」的业务买保险，其余一律站票**。语音通话里丢一句话就是事故，而缓冲区里的视频晚到一秒没人投诉——保障是稀缺品，必须留给真正需要它的人。 ## 三、合同三要素：GFBR、MFBR、AMBR GBR流签约时会带上两个速率值，加上一个全局闸刀，三者各司其职： - **GFBR（保证流比特率）**：这是合同的核心条款——网络承诺，只要这条流的总速率不超过GFBR，就必须按时按量送达。低于这个值运行，责任在网络。注意它是**每条流**的承诺，不是每用户的。 - **MFBR（最大流比特率）**：单条流的封顶线。超过MFBR的包属于「没买坐票还想躺商务座」，监管模块有权直接丢弃。GFBR保下限，MFBR封上限，一硬一软夹住了这条流的行为边界。 - **AMBR（聚合最大比特率）**：这不是单流参数，而是一把汇总闸刀，管的是一个会话（或一组流）加起来的总上限。测速跑不满速，第一个该怀疑的就是它，而不是无线信号。 准入时的算账逻辑可以用一个不等式表达： $$\sum_{i \in \text{已准入}} GFBR_i \;+\; GFBR_{\text{新业务}} \;\le\; C_{\text{小区}} \times \eta_{\text{保守}}$$ 关键在那个 $\eta_{\text{保守}}$：基站记账时用的不是平均谱效率，而是保守的低分位估计。为什么？因为信道会恶化。如果按晴天算账，一场雨下来所有承诺集体违约——与其事后大面积翻车，不如事前少接几单。这就是准入控制「宁可拒新，不能断旧」的数学根源。 监管端则用经典的令牌桶思路执行MFBR： $$\text{允许突发量} \;\le\; MFBR \times T_{\text{桶深}}$$ 短时间的突发可以靠桶里积攒的令牌吸收，但长期平均速率一旦越过MFBR，超出的包就被丢弃。这个设计既保证了合同不被滥用，又不会把业务里正常的速率毛刺误杀。 ## 四、三道工序：一条GBR流的完整通关路 把上面所有机制串起来，一条GBR流从出生到干活，要过三道关： ```mermaid flowchart TD A["应用要一条保底车道
视频通话起步"] --> B["核心网开出合同参数
5QI GFBR MFBR ARP"] B --> C["第一关 准入评估
基站沿途查库存"] C -->|有富余| D["预留成功
沿途记下这笔账"] C -->|没富余| E["拒绝 或 按ARP抢占让路"] D --> F["第二关 监管
超过MFBR的包直接丢"] F --> G["第三关 调度
GFBR以内必须兑现"] G --> H["空口资源块 按时送达"] ``` 这里要划一条容易混淆的界线：**准入与调度是两本账**。准入是「签合同时的静态算术」——把所有GFBR加总，确认小区养得起；调度是「开台后的动态排班」——每个传输时刻决定哪些包占用哪些资源块。准入通过的承诺，靠调度器日复一日兑现；而调度器在兑现完所有GFBR义务之后，剩下的资源才轮到非GBR流量见缝插针。本文讲的资源预留机制，管的是合同怎么签、怎么审计；调度器怎么排班，是另一门手艺，标准允许多种实现，具体行为以各厂家官方文档为准。 ## 五、让座规则：ARP的三件套 资源不够时谁下机？这套规则写在ARP参数里。别被它朴素的名字骗了，ARP其实是三个字段的组合： | 字段 | 取值 | 含义 | 航班类比 | |---|---|---|---| | 优先级 | 1最高，15最低 | 排队与抢占时的座次 | 会员等级 | | 抢占能力 | 是 / 否 | 资源不够时能否挤掉别人 | 有没有权请人下机 | | 被抢占敏感 | 是 / 否 | 会不会被别人挤掉 | 是否接受被请下机 | 这套设计的精妙之处在于**把「权力」和「义务」拆开了**。光有一个优先级数字是不够的：如果优先级高就自动能抢人，那特权用户平时也横行无忌，公平性崩塌；如果只标优先级不标「愿不愿意被抢」，被抢的一方毫无话语权。三件套把问题拆成了三个独立决策：你的座次是多少（排队用）、你能不能动手（抢占用）、你愿不愿意挨（被抢用）。 抢占发生的完整决策流程如下： ```mermaid flowchart TD A["新业务申请资源"] --> B{"空口还有富余吗"} B -->|有| C["直接准入"] B -->|没有| D{"我带抢占能力吗"} D -->|没有| E["排队等待或拒绝"] D -->|有| F{"在网业务里有
低优先级且可被抢的吗"} F -->|有| G["请它下机 腾出资源"] F -->|没有| E G --> H["新业务准入成功"] ``` 有三个细节值得咀嚼： **第一，抢占只发生在准入评估那一刻。** 网络不会周期性地巡逻查岗，把「不该在」的用户踢出去；只有新业务来敲门、库存不够时，才触发一次让座评估。这让抢占成为可预期的事件，而不是悬在所有业务头上的随机闪电。 **第二，被抢占是硬释放，不是降速。** 一条GBR流被抢占，意味着这条流被直接拆掉——正在进行的通话会掉话。正因如此，现网的普遍做法相当保守：绝大多数业务不配抢占能力，重要业务同时把「被抢占敏感」设为否，把让座当成保底手段而非常规操作，多数时候宁可让新请求排队或拒绝。 **第三，ARP不管日常速率。** 这是最常见的误解来源。ARP优先级再高，也只意味着「进得来、留得住」；你平时跑多快，由调度器按业务的QoS优先级与权重安排。把「谁进谁留」和「进来后怎么排班」拆成两套体系，正是为了兼顾关键时刻的确定性与日常的公平效率——一份参数管两件事，往往两件都管不好。 ## 六、一次视频通话的完整旅程 把这些机制放进一次真实的视频通话里看： ```mermaid sequenceDiagram participant U as 手机 participant G as 基站 participant C as 核心网 U->>C: 发起视频通话 C->>C: 查签约与策略
决定开一条GBR流 C->>G: 下发QoS参数
5QI GFBR MFBR ARP G->>G: 准入检查
空口有富余吗 alt 有富余 G->>U: 专用信道建好了 开讲 U->>G: 视频包流
不超过MFBR Note over U,G: 超速的包在监管处被丢 else 没富余 G->>C: 准入失败
或申请按ARP抢占 C->>C: 评估低优先级在网业务 end ``` 注意一个反直觉的点：**合同的金额是核心网定的，但合同能不能成立，是基站说了算**。核心网可以签发任意漂亮的参数，可空口库存只有基站自己清楚，所以准入的最终裁决权在无线侧。这种「决策权下沉到最了解资源的地方」的设计，是分布式系统里反复出现的模式——承诺必须由掌握真实库存的人拍板。 至于具体用哪个套餐（5QI），标准已经把常见业务固化成了一张速查表，工程师看到参数值就能反推出业务类型： | 5QI | 类型 | 典型业务 | 时延预算（参考） | |---|---|---|---| | 1 | GBR | 会话语音 | 约100ms | | 2 | GBR | 会话视频 | 约150ms | | 3 | GBR | 实时游戏 | 约50ms | | 5 | Non-GBR | 信令类业务 | 约100ms | | 7 | Non-GBR | 视频流媒体 | 约100ms | | 9 | Non-GBR | 默认互联网业务 | 约300ms | 这张表的分界线非常清晰：所有「人跟人实时对话」的业务都在GBR区，所有「机器喂给人看」的业务都在非GBR区——前者的时延预算按人类对话的容忍度设定，后者的时延预算按缓冲区的消化能力设定。 ## 七、现网里你在哪会撞见这套机制 **场景一：语音掉话的经典根因。** 用户在移动中切换小区时，目标基站要对这条GBR语音流重新做一次准入；目标小区话务太满、准入失败，通话要么降级要么掉话。排查掉话问题时，「切换伴随准入拒绝」是一条必须检查的线索，对应的治理手段是负载均衡门限调整和GBR资源的精细化核算。 **场景二：「配了GBR怎么还卡」。** 遇到这种投诉，先按概率排查三件事：其一，是不是覆盖和干扰问题——合同再漂亮，路塌了车照样过不去，GBR只保证调度优先兑现，不保证信道质量；其二，核心网策略是不是真的把业务映射到了GBR流上，很多「语音卡顿」的最后结论是参数压根没下发对；其三，是不是撞上了AMBR这把汇总闸刀。 **场景三：大话务保障。** 演唱会、赛事现场，运营商会预先收紧准入门限：宁可拒绝新增的保障请求，也要保住已在网用户的体验。准入控制在极端场景下就是那道防洪闸。 **场景四：抢占是把双刃剑。** 为重要客户临时调高某类业务的抢占能力，看似快捷，实则可能挤掉普通用户的在网通话——所以抢占策略的变更必须像割接一样先评估再上线。 调试中最容易踩的三个坑： 1. **把GFBR当用户速率**。GFBR是每条流的承诺，一个用户同时开视频会议和语音，是两条GBR流各算各的账； 2. **把ARP当测速加速器**。改ARP优先级不会让你日常跑得更快，它只管准入和保持； 3. **测速不达标先怪无线**。先查AMBR签约限速，再查空口——顺序反了会白熬一宿。 ## 常见问题 **Q: GBR和非GBR的本质区别，能用一句话说清吗？** A: 能——GBR流带着一条「低于GFBR算网络违约」的硬条款，而非GBR流只有排队优先级。前者是签了合同的车位，后者是先到先得的站票。 **Q: GFBR、MFBR、AMBR三个速率总混，怎么记？** A: GFBR是保底线（低于它网络违约），MFBR是单流封顶线（超过它包被丢），AMBR是会话汇总闸刀（所有流加起来不许超）。一底一顶一总，各管一段。 **Q: ARP抢占会不会随时踢掉正在通话的用户？** A: 抢占确实会拆掉在用业务——这正是它的用途——但它只在「新业务准入、库存不够」的那一刻被触发，平时没有人巡逻查岗。也正因为被抢就是硬掉话，现网对开启抢占能力极其克制，多数业务宁可排队也不硬抢。 **Q: 为什么语音一定要GBR，看视频却不用？** A: 语音的每个包都「迟不得」，没有缓冲垫，丢了就是断句；点播视频前面有缓冲区，网络抖动会被缓冲吸收。保障资源贵而稀缺，只配给真正需要它的业务。 **Q: ARP优先级和调度优先级是一回事吗？** A: 不是。ARP只决定「能不能进网、被挤时留不留得住」；日常谁的数据先发、发多少，由调度器按业务的QoS优先级与权重决定。一个是门卫的座次表，一个是排班表。 ## 参考来源 1. [ShareTechnote: 5G QoS](https://www.sharetechnote.com/html/5G/5G_QoS.html) — 工程视角的5G QoS流、GBR参数与流程图解，本文参数语义的交叉印证来源之一 2. [Wikipedia: Quality of service](https://en.wikipedia.org/wiki/Quality_of_service) — QoS通用机制、准入控制与拥塞管理的背景框架 3. [Wikipedia: Token bucket](https://en.wikipedia.org/wiki/Token_bucket) — 令牌桶监管算法的原理，对应MFBR监管的实现思路 4. [Wikipedia: 5G](https://en.wikipedia.org/wiki/5G) — 5G网络架构与QoS框架的整体概述 --- > 本文由「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 等场景全覆盖。