订座与让座：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的网络：每来一个网页请求，基站都得为它预留一段「万一塞车也够用」的资源。而网页、点播这类弹性流量的真实速率像心跳一样起伏，预留量只能按峰值算——结果就是资源利用率暴跌，大量承诺好的资源在一分钟里有大半时间是空转的。反过来，弹性业务本身有缓冲垫：视频播完前十秒，后十秒晚到几十毫秒，观众毫无知觉。

所以设计者做了一个经济学决策：只给「迟不得」的业务买保险，其余一律站票。语音通话里丢一句话就是事故，而缓冲区里的视频晚到一秒没人投诉——保障是稀缺品，必须留给真正需要它的人。

三、合同三要素：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流从出生到干活，要过三道关：

flowchart TD
    A["应用要一条保底车道<br/>视频通话起步"] --> B["核心网开出合同参数<br/>5QI GFBR MFBR ARP"]
    B --> C["第一关 准入评估<br/>基站沿途查库存"]
    C -->|有富余| D["预留成功<br/>沿途记下这笔账"]
    C -->|没富余| E["拒绝 或 按ARP抢占让路"]
    D --> F["第二关 监管<br/>超过MFBR的包直接丢"]
    F --> G["第三关 调度<br/>GFBR以内必须兑现"]
    G --> H["空口资源块 按时送达"]

这里要划一条容易混淆的界线：准入与调度是两本账。准入是「签合同时的静态算术」——把所有GFBR加总，确认小区养得起；调度是「开台后的动态排班」——每个传输时刻决定哪些包占用哪些资源块。准入通过的承诺，靠调度器日复一日兑现；而调度器在兑现完所有GFBR义务之后，剩下的资源才轮到非GBR流量见缝插针。本文讲的资源预留机制，管的是合同怎么签、怎么审计；调度器怎么排班，是另一门手艺，标准允许多种实现，具体行为以各厂家官方文档为准。

五、让座规则：ARP的三件套

资源不够时谁下机？这套规则写在ARP参数里。别被它朴素的名字骗了，ARP其实是三个字段的组合：

这套设计的精妙之处在于把「权力」和「义务」拆开了。光有一个优先级数字是不够的：如果优先级高就自动能抢人，那特权用户平时也横行无忌，公平性崩塌；如果只标优先级不标「愿不愿意被抢」，被抢的一方毫无话语权。三件套把问题拆成了三个独立决策：你的座次是多少（排队用）、你能不能动手（抢占用）、你愿不愿意挨（被抢用）。

抢占发生的完整决策流程如下：

flowchart TD
    A["新业务申请资源"] --> B{"空口还有富余吗"}
    B -->|有| C["直接准入"]
    B -->|没有| D{"我带抢占能力吗"}
    D -->|没有| E["排队等待或拒绝"]
    D -->|有| F{"在网业务里有<br/>低优先级且可被抢的吗"}
    F -->|有| G["请它下机 腾出资源"]
    F -->|没有| E
    G --> H["新业务准入成功"]

有三个细节值得咀嚼：

第一，抢占只发生在准入评估那一刻。 网络不会周期性地巡逻查岗，把「不该在」的用户踢出去；只有新业务来敲门、库存不够时，才触发一次让座评估。这让抢占成为可预期的事件，而不是悬在所有业务头上的随机闪电。

第二，被抢占是硬释放，不是降速。 一条GBR流被抢占，意味着这条流被直接拆掉——正在进行的通话会掉话。正因如此，现网的普遍做法相当保守：绝大多数业务不配抢占能力，重要业务同时把「被抢占敏感」设为否，把让座当成保底手段而非常规操作，多数时候宁可让新请求排队或拒绝。

第三，ARP不管日常速率。 这是最常见的误解来源。ARP优先级再高，也只意味着「进得来、留得住」；你平时跑多快，由调度器按业务的QoS优先级与权重安排。把「谁进谁留」和「进来后怎么排班」拆成两套体系，正是为了兼顾关键时刻的确定性与日常的公平效率——一份参数管两件事，往往两件都管不好。

六、一次视频通话的完整旅程

把这些机制放进一次真实的视频通话里看：

sequenceDiagram
    participant U as 手机
    participant G as 基站
    participant C as 核心网
    U->>C: 发起视频通话
    C->>C: 查签约与策略<br/>决定开一条GBR流
    C->>G: 下发QoS参数<br/>5QI GFBR MFBR ARP
    G->>G: 准入检查<br/>空口有富余吗
    alt 有富余
        G->>U: 专用信道建好了 开讲
        U->>G: 视频包流<br/>不超过MFBR
        Note over U,G: 超速的包在监管处被丢
    else 没富余
        G->>C: 准入失败<br/>或申请按ARP抢占
        C->>C: 评估低优先级在网业务
    end

注意一个反直觉的点：合同的金额是核心网定的，但合同能不能成立，是基站说了算。核心网可以签发任意漂亮的参数，可空口库存只有基站自己清楚，所以准入的最终裁决权在无线侧。这种「决策权下沉到最了解资源的地方」的设计，是分布式系统里反复出现的模式——承诺必须由掌握真实库存的人拍板。

至于具体用哪个套餐（5QI），标准已经把常见业务固化成了一张速查表，工程师看到参数值就能反推出业务类型：

这张表的分界线非常清晰：所有「人跟人实时对话」的业务都在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 — 工程视角的5G QoS流、GBR参数与流程图解，本文参数语义的交叉印证来源之一
2. Wikipedia: Quality of service — QoS通用机制、准入控制与拥塞管理的背景框架
3. Wikipedia: Token bucket — 令牌桶监管算法的原理，对应MFBR监管的实现思路
4. Wikipedia: 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 等场景全覆盖。