标题: 每 1 毫秒分一次蛋糕：调度器 作者: 爱卫生 封面: "[[封面1.png]]" 封面裁剪: false 原文地址: 打开评论: true 仅粉丝可评论: false 摘要: 手机信号满格，网页却转圈；测速能跑500Mbps，刷个页面反而卡住。很多工程师遇到这类投诉，第一反应是查覆盖、查干扰，但还有一层原因藏得更深：空口资源每时每刻都在被“重新分配”，而分蛋糕的那只手，就是基站的调度器。
手机信号满格，网页却转圈；测速能跑500Mbps，刷个页面反而卡住。很多工程师遇到这类投诉，第一反应是查覆盖、查干扰，但还有一层原因藏得更深：空口资源每时每刻都在被“重新分配”，而分蛋糕的那只手，就是基站的调度器。它每毫秒做一次决策，决定这一瞬间谁的データ上路、走哪段频谱、用什么格式。理解了调度器，你才算真正理解QoS不是几张参数表，而是一台每毫秒运转一次的分配机器。
先想清楚一个问题：为什么需要调度器？
因为空口是一张所有用户共享的桌子。一个小区的频谱资源就那么多，基站到手机之间的无线电波是广播性质的——基站同时朝八个方向发八路不同的数据，手机之间就会互相干扰，谁也收不清。所以LTE以后的空口设计思路是：把资源切成细小的格子，每一瞬间只让指定的用户占用指定的格子。
这个“格子”在物理上有两个维度：
于是空口变成了一张时间×频率的二维网格，调度器的全部工作，就是每个slot都要回答一遍：这张网格上的每一格，给谁用？
用食堂打饭类比：只有一个打饭窗口（基站），窗口前面挤着一百个学生（用户），阿姨手里的勺子每次只能盛一勺。调度器就是这位阿姨——只不过她每0.5毫秒就重新决定一次“下一勺给谁”，而且她还有一个别人没有的本事：她知道每个学生现在饿到什么程度、消化能力如何。
flowchart TD
A["核心网送来数据包"] --> B["gNB缓存队列"]
subgraph S["基站里的调度引擎"]
B --> C["MAC调度器"]
C -->|每0.5到1毫秒决策| D["物理层发送"]
end
D -->|PRB加调制格式| E["手机UE"]
调度器住在基站协议栈的MAC层，上承RLC的缓存队列，下接物理层的发送器。这个位置决定了它的两个特征：它只看得见毫秒级的当下（谁的数据在缓存里排队、谁的信道此刻好），而慢速级的规则（这个用户签约了什么速率、哪个业务该优先）是核心网通过QoS参数提前告诉它的。调度器 = 长期规则 + 瞬时信息的合成器。
一个常见误解是：调度器就是“按优先级排序”。实际上排序只是最后一步，调度器90%的功夫花在收集信息上。它每毫秒要综合下面这张表里的牌：
| 信息 | 来自哪里 | 回答什么问题 | 类比 |
|---|---|---|---|
| CQI 信道质量指示 | 手机周期性上报 | 这个人现在的信道能扛多大速率？ | 顾客自报饭量 |
| BSR 缓存状态报告 | 手机按需上报 | 上行还有多少数据等着发？ | 排队人数 |
| SR 调度请求 | 手机主动举手 | 有新人要加入吗？ | 举手喊“阿姨” |
| PHR 功率余量报告 | 手机定期上报 | 手机还剩多少发射功率余量？ | 顾客还剩多少体力 |
| HARQ 待重传队列 | 基站自己记录 | 上一轮谁没收到，要补发？ | 退回重炒的菜 |
| 下行缓存数据量 | 基站自己记录 | 下行要给每个人发多少？ | 备菜量 |
| QoS参数（优先级/GBR等） | 核心网会话建立时下发 | 谁有承诺、谁靠边站？ | 订过座名单 |
注意CQI那一行——它同时是自适应调制编码（AMC）的输入。这里要划清两个模块的分工，也是工程师容易混淆的一点：
两者共用CQI，但职责不同。信道好的人被优先选中（调度器的活），选中之后给他配高阶调制多塞比特（AMC的活）。
信息齐了，一次调度决策在基站内部是怎么走的？看这条流水线：
flowchart TD
A["新slot开始"] --> B["汇总全部输入信息"]
B --> C["HARQ重传最优先"]
C --> D["GBR承载按承诺保障"]
D --> E["剩余PRB按PF度量分给Non-GBR"]
E --> F["为每个中选用户选MCS"]
F --> G["PDCCH下发DCI点名"]
G --> H["数据在分配的PRB上收发"]
这条流水线里藏着QoS设计的精髓：资源被分成了两个性质完全不同的池子。
GBR承载（语音、视频通话这类有速率承诺的业务）相当于提前订了座。核心网在建承载时做过准入控制——基站算过账，确认“这个小区还养得起一张新订座”才放行。准入之后，调度器每个slot都要优先喂饱GBR流，把它们逼近承诺速率，剩下的PRB才拿来自由分配。
Non-GBR承载（网页、下载、普通视频）没有订座，全部挤在剩余资源里“抢座”，谁抢到看算法（下一节讲）。两者的待遇差异可以浓缩成一张表：
| 维度 | GBR承载 | Non-GBR承载 |
|---|---|---|
| 进入小区 | 需要准入控制，满了会被拒绝 | 随到随用 |
| 速率下限 | 有承诺速率，调度优先保障 | 无下限，纯尽力而为 |
| 速率上限 | 有峰值限制封顶 | 受会话级/终端级总闸封顶 |
| 拥塞时 | 最后被挤，尽量维持承诺 | 最先被压缩 |
| 限速执行位置 | 空口调度器逐毫秒执行 | 会话总闸多在核心网UPF执行，终端总闸由基站配合 |
| 典型业务 | VoNR语音、视频通话 | 网页、下载、流媒体 |
最后两行值得多说一句，因为它解释了一个经典的现网困惑：为什么有的限速在基站侧怎么调都不生效？因为速率控制是两级执行的。逐毫秒的“保与抢”发生在空口调度器，而“你这个会话总共不超过200Mbps”这类慢速总闸，大多在核心网UPF上执行——那是计费和签约层面的闸，跟空口挤不挤没关系。排障时先分清“限速来自哪一级”，能少走很多弯路。
还有一个细节体现工程智慧：GBR流内部也不是“优先级高者通吃”。高优先级流喂到承诺速率后，调度器会让位给其他GBR流——承诺的本质是“保证不低于”，不是“越多越好”。订座的人吃完了，座位自然让给下一批订座的。
下行好办——数据都在基站自己缓存里，调度器想看随时看。麻烦的是上行：数据在手机里，基站看不见。手机不能“想发就发”，一是上行功率金贵、多用户要集中管控，二是基站需要全局视野才能避免干扰。于是上行设计了一套轻巧的“举手—点名—报数—发糖”流程：
sequenceDiagram
participant U as 手机UE
participant G as 基站gNB
U->>G: SR举手：我有数据要发
G->>U: 小块授权：先给你一点
U->>G: BSR报数：缓存里还有X字节
G->>U: 大块授权：按你的量给足
U->>G: 数据真正发出
Note over U,G: 完整往返通常耗时数毫秒
这套流程里有三个精巧的设计，值得工程师记住：
第一，SR只有1比特。举手不需要说明要多少资源，只表达“我饿了”。这是一个信息效率的典范——最小的信令开销，触发最小的初始授权。手机在专用资源上发SR；如果连续举手超过上限次数还没被理睬（比如专用资源信号太弱），手机会退回到随机接入流程去“大声喊”，代价更大但保证不死锁。你在现网日志里看到上行数据前的异常随机接入，很多时候就是SR路径失效后的兜底动作。
第二，BSR按“频道组”打包上报。手机里可能同时活跃着十几条逻辑信道（语音的、信令的、上网的），逐条上报太浪费。于是标准把逻辑信道归并成最多8个逻辑信道组（LCG 0到7），BSR只报每个组里排队的总字节数，而且报的是量化后的档位而非精确值。多个来源的协议教程均确认了这一机制：ShareTechnote的BSR格式图里明确画着LCG0到LCG7的字段，ranbits的调度教程也指出“gNB用BSR决定下次给多少RB”。所以基站第二次发的授权才能“按量给足”。
第三，手机里还藏着一个镜像调度器。基站给了授权，手机内部也要决定：这点资源先发给谁？这就是逻辑信道优先级（LCP）机制——每条逻辑信道配一个优先发送速率（PBR）和一个令牌桶，令牌按PBR的速率持续进账：
$$B_j(t+\Delta) = \min\bigl(B_j(t) + \mathrm{PBR}_j \cdot \Delta,\; \mathrm{BSD}_j \times \mathrm{PBR}_j\bigr)$$
有授权时，先按优先级从高到低，把桶里有令牌的信道喂到令牌用完，剩余资源再按严格优先级分给其他信道。这个设计的妙处在于令牌桶给低优先级信道留了活路：哪怕小区里永远挤着高优先级业务，低优先级信道也能按PBR的节奏定期分到一口饭，不会彻底饿死。
flowchart TD
A["收到上行grant"] --> B{"高优先级桶里有令牌吗"}
B -->|有| C["先发它直到令牌耗尽"]
B -->|无或已耗尽| D["按优先级顺序用剩余资源"]
D --> E["低优先级靠令牌桶定期吃到饭"]
所以“调度”其实发生两处：基站的调度器分PRB，手机的LCP分grant。排障时看上行异常，两头都要看。
Non-GBR流量在剩余资源里怎么分？这才是调度算法真正的战场。三种经典思路，代表了三种价值观：
| 算法 | 规则 | 小区总吞吐 | 公平性 | 类比 |
|---|---|---|---|---|
| 轮询 RR | 挨个轮流，不看信道 | 低 | 绝对公平 | 排队打饭不看饭量 |
| 最大C/I | 谁信道好就全给谁 | 最高 | 边缘用户饿死 | 只招待最有胃口的人 |
| 比例公平 PF | 瞬时可得速率除以历史平均，商最大者得 | 接近最高 | 时间上趋近平等 | 谁最近没吃上就照顾谁 |
轮询和最大C/I是两个极端，而现实网络几乎都用比例公平（PF）——它诞生于3G时代的HDR（EVDO）系统，此后一直是蜂窝数据调度的默认哲学。PF的决策量非常简洁：
$$P_i(t) = \frac{r_i(t)}{\bar{R}_i(t)}$$
其中 $r_i(t)$ 是用户 $i$ 此刻信道能支撑的速率（由CQI推算），$\bar{R}_i(t)$ 是它过去一段时间的平均吞吐。每次传输后按滑动窗口更新：
$$\bar{R}_i \leftarrow \left(1-\frac{1}{T_c}\right)\bar{R}_i + \frac{1}{T_c}\,r_i$$
这个除法的直觉极妙：信道好（分子大）的人优先，但最近一直没被服务（分母小）的人补偿。站在信号好的用户，他信道好、分子大，容易中选——这利用了无线信道的随机涨落（“多用户分集”）；但每次中选后他的平均吞吐上涨、分子相对变小，别人就有机会顶上。某百科的条目给出了更一般的表达式 $P = T^\alpha / R^\beta$，并指出：$\alpha$ 越大越偏向“只伺候信道最好的”，$\beta$ 越大越偏向绝对平均，取 $\alpha \approx 1, \beta \approx 1$ 就是3G网络里实际使用的比例公平。条目还提到一个工程细节：平均窗口常数 $T_c$ 越大，总吞吐越高、短期公平性越差——这是现网参数优化时真实存在的旋钮。
打个比方：雨夜打车。最大C/I策略是“谁站在马路中间最好拦就只接谁”，效率最高但住巷子里的人永远打不到车；轮询是“严格排队，哪怕你绕路三公里也要拉”；PF是“谁最近一直没打到车、现在又恰好站在好拦的位置，就接谁”——总单量不亏，人人有车坐。
SR→grant→BSR这套动态调度很灵活，但它有两个成本：时延（一轮握手要好几个毫秒）和开销（每次点名都要占控制信道）。对于每20毫秒就要发一个语音包的VoNR、或者时延要求卷到亚毫秒的URLLC业务，每包都举手报到，既慢又贵。
解决方案是“包月专线”：半静态调度/预配置授权。网络通过信令一次性告诉手机：“以后每个周期，这个时间这个资源就是你的，不用再举手。”语音业务的包是周期性、大小可预估的，天然适合这种模式；URLLC更依赖它来把调度时延从流程中整个砍掉。代价是灵活性——资源被预占了，别人用不了。所以现网的经典搭配是：语音/URLLC走专线，普通数据走每毫秒的动态拍卖。
这也就解释了抓包时的一个现象：语音包的上行传输前看不到完整的SR/BSR握手，不是抓包漏了，是它根本不走那条路。
场景一：测速正常，网页转圈。测速是大流量长连接，吃满调度资源毫不含糊；网页是“请求—响应”的小包往返，每一次上行请求都要走一遍举手流程。如果SR资源紧张、或BSR触发的授权节奏偏慢，小包业务的首包时延会被显著拉长，而吞吐类业务毫无察觉。这时该看的是调度相关的时延统计，而不是盯着下行吞吐找问题。
场景二：语音MOS忽高忽低。先查语音承载是不是还“订着座”。承载降级成Non-GBR（比如承载修改异常、拥塞导致被挤），语音包立刻掉进PF的公开竞技场，和下载流量抢PRB，抖动和丢包随之而来。确认方法很直接：看该承载是否还带GBR属性、调度统计里它的速率是否贴着承诺值。
场景三：用户投诉“被限速”，但空口很空。大概率不是调度器的事。先查会话级总闸（UPF侧限速）和终端级总闸（签约AMBR），再看空口——顺序反了会白忙半天。空口资源占用率低而用户速率被卡死，基本可以断定闸在核心网。
场景四：某类业务高峰期集体劣化。查优先级配置有没有倒挂——如果把关键业务配了比视频更高的5QI优先级之外，还有大量业务被错误地配成了同档高优先级，“高优先级”等于没配，全员挤在第一梯队互相踩踏。优先级是相对概念，人人都 VIP 就没有人是 VIP。
最后纠正三个常见误解：
Q: 调度器和自适应调制编码（AMC）是什么关系？ A: 分工是“选人”与“选格式”。调度器决定这0.5毫秒把哪些PRB给哪个用户；AMC决定被选中的用户用什么调制阶数和码率。两者都以CQI为输入，但CQI给调度器的用途是“比较谁更值得”，给AMC的用途是“算这个人能扛多大码率”。
Q: 为什么上行不能像WiFi那样想发就发？ A: WiFi的CSMA/CA是分布式“抢话筒”——听到没人说话就抢，抢撞了退避重来。这套机制天然无法提供精细的QoS承诺，因为你永远不知道下一刻谁会抢到。蜂窝网的集中式调度虽然多了一次举手开销，但换来的是每毫秒的确定性分配——GBR、优先级、切片保障，全都建立在“基站说了算”之上。这是两种体制的根本分野。
Q: 手机内外的两个调度器（gNB调度器和LCP）会打架吗？ A: 不会，它们是上下游。gNB决定“给多少”，LCP决定“先发谁”。LCP通过PBR和令牌桶维持每条逻辑信道的最低节奏，剩余资源按严格优先级分配——它像是基站在手机里安插的“政策执行人”，保证资源到了手机端仍按QoS规则分流。
Q: 比例公平是不是绝对公平？ A: 不是。PF保证的是长期时间公平（每个用户的平均吞吐在时间轴上趋于平等），而不是每个瞬间的资源均分，也不是速率相等。小区边缘用户和小区中心用户的实际速率差距依然很大——PF只是保证边缘用户也能获得“属于他的那份时间”，不至于被饿死。
Q: 排障时如何快速判断问题出在调度层？ A: 记住三条证据链：看调度统计里各承载/各QoS等级实际分到的PRB比例（分不到=调度层受限）；看SR失败计数和随机接入原因（举手失败=上行信令路径问题）；看GBR承载速率是否贴近承诺值（贴不上=保障失效或覆盖问题）。三条分别对应“分蛋糕不公”“举不起手”“订了座没饭吃”三种典型病。
本文由「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 等场景全覆盖。
![[知识星球二维码.png]]