1. 调度器到底在管什么：5G MAC层的“权力中心”
聊5G无线接入技术，前面几篇我们更多是站在物理层的视角，看波形、看信道、看编码调制。到了调度这一篇，整个视角要往上层移一步，来到这里最复杂也最“现实”的模块。有人把MAC调度器比喻成十字路口的交通警察，实际上它比交警权力大得多。交警只管通行顺序，调度器决定的是每辆车在哪个车道、什么时间出发、用什么车速、油给多大、服务优先级是谁，而且所有决策要在极短的时间内连续不断地做出来。
在NR也就是5G系统里，调度器位于MAC层，承载的实体通常在基站侧被称为MAC Scheduler。它唯一的正式任务听起来很简单：把时频资源分配给具体用户。具体到实现，就是在每一个调度周期也就是通常说的TTI（Transmission Time Interval）内，决定哪些终端在哪些物理资源块上收发数据，采用什么传输方案，用什么调制编码等级，调度的时长是多少，要不要重传，上行和下行各占多少。
但这里我要先给一个非常重要、很多新人第一反应会搞反的结论：调度器并不是只被信道质量一种因素驱动的。它的输入非常庞杂，包括无线信道质量反馈、业务缓存量、逻辑信道优先级、时延约束、功率限制、HARQ状态、设备调度能力甚至终端支持的功能特性。所以调度本质上是一个带约束的多目标优化问题，工程上谁也不会真的用通用优化算法去跑，都是实时的启发式策略在兜底。
对比4G的LTE调度，5G调度的决策维度越来越多，但调度周期反而可以更短。LTE的TTI是1ms，一个子帧一个调度周期。NR在常规配下同样有一个符号级可变的调度能力，Sub-6GHz和毫米波都有mini-slot的概念，最少可以用2个OFDM符号就做一次调度。双连接、载波聚合、多个BWP（Bandwidth Part）同时存在时，一个调度器还要同时兼顾多套资源池。所以做5G协议栈也好，做无线参数优化也好，理解调度器的工作逻辑，是很多后续问题排查的基础。
这一篇我们不铺开讲代码实现，重点走一遍“调度到底怎么做决策”“它依赖哪些反馈”“不同业务怎么差异化处理”“现网优化中有哪些坑”，把调度这个模块从原理到落地串一遍。适合正在学5G技术的工程师、刚接入网优化岗位的同行，也适合做协议测试的朋友在分析日志时快速找到头绪。
2. 5G调度相比4G的核心变化：mini-slot、动态帧结构与时间账本
2.1 为什么NR要把TTI打散
LTE时代我们习惯1ms TTI思考问题，一个子帧分两个时隙，每个时隙0.5ms，调度基本以子帧为粒度。到了5G，帧结构里一个时隙在30kHz子载波间隔下只有0.5ms，15kHz下才是1ms。同时NR引入了灵活帧结构，上下行符号可以动态调整，调度还要考虑符号级别。为什么这么做，背后有非常清晰的业务驱动力，那就是时延账本。
URLLC目标端到端时延要做到1ms量级，空口时延要控制在0.5ms到几毫秒之间。如果还是1ms一个调度周期，资源分配本身就是一个完整TTI的等待过程，再加上调度决策和HARQ反馈，空口时延根本压不下来。所以NR设计了mini-slot，调度粒度细到2符号、4符号或7符号，带宽资源粒度也做成更灵活的组合。
从实现角度看，minislot调度对基站的调度器算法复杂度提出了很大挑战。1ms之内可能连续出现多个调度时机，每个时机都要重新评估用户的信道状态、优先级和资源可用性。对做终端测试的同行来说，你会在DCI信令里频繁看到“时域资源分配”字段指向一个非从符号0开始的起始位置，这就是mini-slot调度的典型痕迹。
2.2 TDD帧结构对调度的影响，不止是上下行比例
5G主流现网是TDD模式，这给调度器带来的核心约束就是：某些符号上只能发下行、某些只能发上行，还有一部分是灵活符号。调度器要做的事情是在满足帧结构约束的前提下，把每个方向的数据分配出去。
TDD配比是6:4还是7:3还是特殊子帧带保护间隔，会直接影响上下行容量和时延特性，调度器必须感知每一帧的配比结构。更麻烦的是，NR还引入了动态TDD，也就是上下行方向可以随负载实时调整。这个时候调度器的复杂度会进一步上升：它不仅要考虑用户当前信道和缓存，还要预测未来几个时间窗口的上下行需求比例，否则可能出现下行疯狂堆积、上行没有传输机会，或者空口大量符号闲置。
现网中动态TDD用得不算广泛，主要还是因为跨基站干扰控制难、行业终端兼容性问题多。但理解这个机制很重要，因为静态TDD下调度器相对好做，而动态TDD环境下对调度策略的考验接近“实时资源交易市场”。
2.3 多BWP与载波聚合的调度扩展逻辑
在载波聚合场景下，调度器实际上管理的是多个分量载波上的并行资源。每个CC可以有不同的子载波间隔、不同的帧结构、不同的带宽。终端在多个CC之间可能有不同的能力差异，有些CC支持下行但上行能力受限。调度器要综合考虑每个CC的CQI，决定PDSCH/PUSCH分布，还要完成跨CC的调度指示配置。
BWP机制带来了另一种资源组合维度。大数据通常把BWP理解成带宽区块，但调度器视角里，它更像是一个“资源大小可变的调度单位”。终端可以配置多个BWP，但同一时刻只有一个激活，调度器分给用户的资源不能超过当前BWP的带宽范围。这些都是LTE没有的适配逻辑。
3. 一次完整调度决策的输入链路：CQI、BSR、SR与HARQ全参与
3.1 下行调度依赖的CQI反馈链路
调度的第一步是问一个问题：当前时刻，这个用户在这段频带上能承受多高的编码效率？答案主要来自终端上报的CQI，Channel Quality Indicator。
CQI不是直接告诉你这个用户信号好不好，而是告诉基站“建议按照某个调制编码方式来传”。CQI的取值范围是0到15，索引越高代表越高的频谱效率，比如从QPSK低码率一路到256QAM高码率。基站拿到CQI之后要映射到MCS上去选实际编码调制方式。
但行业里有经验的工程师都知道，CQI不等于实际传输质量。终端是按照过去的信道测量上报的，和当前真实信道有一个时间差。调度器通常不会盲目跟随CQI，而是要做一定的MCS调整，典型的手段包括外环链路自适应，也就是根据历史传输ACK/NACK结果做动态修正：连续ACK就让MCS往上升，出现NACK就快速降下来。所谓“内环”靠CQI，“外环”靠HARQ反馈，这套双环结构是调度决策最核心的稳定机制。
实际优化时你会发现，如果CQI上报周期太长或者触发门限不合理，外环就要长期兜底干活。一个现网经验是：CQI周期配置过长的场景下，突然出现大干扰时MCS回落反应慢半拍，BLER兜不住，用户感知先掉下去再被拉回来。所以调度优化的第一步往往是先检查CQI上报周期与业务场景是否匹配。
3.2 上行调度请求链：SR、BSR和缓存报告
上行调度和下行调度有一个本质差异：下行数据在基站侧，基站知道自己要发多少；上行数据在终端侧，基站不知道终端缓存里有多少数据。这是上行调度机制设计的起点。
终端有上行数据要发时，第一步是发SR，Scheduling Request，通过PUCCH上的专用资源告诉基站“我需要上行资源了”。基站收到SR后，会先给终端分配一个相对较小的上行授权，让终端能发BSR（Buffer Status Report），即上报自己不同逻辑信道群组里到底积压了多少数据。基站拿到BSR之后，才真正判断要不要给这个终端分配更大的上行资源，以及优先分配哪部分资源。
这是很多新人理解上行调度时最容易绕晕的点。SR只是敲门砖，BSR才是决定资源量级的“需求账单”。调度器通常并不完全相信BSR一次上报的结果，因为从BSR生成到真正调度向数据发出，终端缓存又可能发生变化。所以工程实现里针对上行还有流量过滤、缓存估算、预测补偿等算法。
上行调度里还有个常被忽略的输入是功耗余量报告PHR，Power Headroom Report。它告诉基站终端当前还剩多少发射功率余量。如果PHR显示已经到功率上限，再提升MCS也没用，调度器反而要降速或限制RB分配。这是“物理能力约束”纳入调度决策的一个具体体现。
3.3 HARQ状态与重传调度优先级
HARQ反馈是另一个调度器必须“敬畏”的输入。物理层有HARQ进程在管理每个数据包的ID、重传计数、软缓存合并。调度器要做的是决定一个新传的包还是重传的包优先占用资源。
通常来说，重传的优先级是高于新传的，因为重传数据已经经历了无线传输和合并，只差最后一步解码成功；放弃重传意味着前面的传输全部浪费，还拖累整个传输链路的时延和吞吐。很多调度器都会给重传预留“必传”的资源窗口，压着新传的时间窗口。
但这也不是完全绝对的策略。某些优化场景下，如果重传的是低优先级业务而新传的是高优先级URLLC，业务优先级可能反转过来，先处理URLLC。这类冲突仲裁逻辑，贯穿所有调度策略设计的始终，也是不同厂商设备性能拉开差距的细节之一。
4. 资源分配类型与DCI：告诉终端“什么时候、哪里、怎么传”
4.1 频域资源指示：RBG位图与RB起始点长度指示
调度决策做完，必须通过下行控制信息DCI把“你该在哪个资源上传”这个指令发给终端。NR的频域资源分配分成两种类型，这一点做物理层测试或者看日志的同行一定不陌生。
Type 0用RBG（Resource Block Group）位图来指示，每一个bit对应一组资源块。它的好处是灵活性强，可以支持不连续的频域资源分配；代价是DCI里需要承载的bitmap长度跟着系统带宽走，带宽越大开销越大。
Type 1用起始RB位置加上资源块长度来指示，允许调度器从任意一个RB开始连续分配指定数量的RB。它支持更细粒度分配，但只能连续分配，灵活性不如Type 0。
调度器选哪个类型，要根据业务对碎片化资源的需求来。大带宽的eMBB业务在多数场景用Type 0做整段资源块上的分配效率更高，但小包业务用Type 1更节省DCI开销。终端不支持某个类型时，调度器还必须回退。现场如果出现“DCI解析失败”“盲检不匹配”，先检查资源分配类型和终端能力是否对得上，这是我处理协议日志时第一优先排查的方向。
4.2 时域资源指示与时隙偏移K0/K1
NR还把“什么时候开始传”这个字段做成了时域资源分配表，通过DCI里的TDRA字段索引到某一行配置，这一行里包含起始符号位置、传输持续时长和K0或K1偏移量。
K0是PDSCH相对PDCCH所在的时隙延迟几个时隙开始传，K1是PDSCH到HARQ-ACK反馈之间的时隙数，K2是PUSCH相对PDCCH的时隙偏移。这些参数直接构成调度的时间轴。一个调度决策下去，终端什么时候收数据、什么时候反馈、什么时候发上行，全部由K系列参数确定。
对slot级调度来说，K0/K1/K2的设置要是和帧结构、HARQ定时冲突，就会造成反馈窗口错位。很多终端异常掉线、HARQ进程挂死的问题，最后定位都是K1配置与TDD帧结构不匹配。
4.3 调制阶数受限与MCS表选择
NR设计了多套MCS表，表1用于覆盖受限场景，主要针对URLLC的低阶调制需求，表2用于常规eMBB。UE在RRC配置时会声明自己支持哪张表，调度器根据信道质量来选择。
256QAM的高阶调制依赖信道质量好且信噪比高，如果信号本身不佳，调度器盲目抬MCS会导致频繁重传。MCS选择和外环调整联动时，还有一些保护逻辑，避免在高阶调制和降阶调制之间来回震荡。工程上我会特别关注调度器是否有迟滞窗口，没有迟滞的话，CQI稍微抖一下，MCS就跟着大幅跳变，空口吞吐反而会下降。
调度这件事做到这里已经能看到它的全貌：它不是一个单纯的“谁信号好就先给谁”的算法，而是把“信道、需求、能力、约束”四方面信息实时汇总后作出的资源分配行为。
5. 调度策略与多用户配对：从公平到体验的平衡术
5.1 三大经典调度算法的适用边界
再往下说，调度器内部跑的具体策略。常见的三个算法是最大载干比，轮询和比例公平。
最大载干比调度的核心是“谁信道好谁先吃资源”，在单用户视角下吞吐最优，但边缘用户很容易饿肚子，因为它的信道条件长期拼不过近点用户，公平性极差。这种算法通常只作为高容量场景的参考值，或者只在用高干扰抑制能力做补偿时使用。
轮询调度就是大家轮流来，时间上完全公平，完全无视信道差异。结果是整体频谱效率很低，因为好信道的用户没能发挥优势，但胜在实现简单，经常用来做功能测试的默认参照。
比例公平PF是目前的绝对主流。它把用户“当前可获得速率”和“历史平均速率”做比值，用这个比值作为优先级权重。信道好的用户因为当前速率高拿到高分，但信道不佳且很久没被调度的用户，历史平均速率会持续下降，比值就会被顶上来。PF天然形成了一种“在公平与吞吐之间做动态平衡”的效果。大多数厂商的默认调度策略，本质上都是PF及其各种加权变体的组合。
5.2 多用户MIMO配对：空间层复用，背后的配对约束
5G调度里还有一个LTE时代没有上升到“规模应用”的维度：多用户MIMO配对。简单说，就是在同一个时频资源上让多个用户同时复用不同的空间层，基站端用多根天线把各用户的数据分离开。
这极度考验调度器的配对算法。不是随便把两个用户凑一起就行，必须先判断他们的信道是否具备空间区分度。一般算法会基于SRS信道探测获得的上行信道估计来做配对判决，或者基于终端上报的PMI、RI等预编码信息。如果两个用户空间相关性太强，配对后互相干扰，不但没有实现双流复用增益，反而还不如分开调度。
实际配对还有DMRS端口正交性、功率分配、终端是否支持全相干传输、天线数等约束。做小区容量优化时，把配对成功率作为一个关键指标跟踪，比单纯看平均吞吐更有意义。如果配对成功率低于预期，先查终端能力分布和SRS资源配置，往往比调MCS更有效。
5.3 业务优先级与逻辑信道映射
除了“用户级”优先级，5G还有“业务级”优先级。MAC层在基站侧做QoS流到逻辑信道的映射，调度器最终分配资源是按逻辑信道优先级来的。URLLC业务放在高优先级逻辑信道，eMBB放在中等，后台下载可以放低优先级。
分配具体RB时，调度器会对高优先级逻辑信道优先满足其QoS需求，包括GBR速率、PDB时延预算，然后剩余资源才分给低优先级信道。这就引申出一个关键优化点：逻辑信道优先级参数LCP如果写得不对，哪怕调度策略本身很优秀，资源也会被不该占业务的流量拿走。
我在现网不止一次碰到：某VIP低速率业务时延总超标，查了环境、查了干扰都没问题，最后发现是它的LCP优先级低于一批视频缓冲流量，资源全被缓冲流量吃掉了。这个坑特别隐蔽，参数表上只是几个数字，背后的资源排序逻辑却影响巨大。
6. 不同业务模型的调度适配：eMBB、URLLC与切片间的资源博弈
6.1 eMBB：重吞吐，也要防“大包饿死小包”
eMBB业务以大流量大包为主，对调度器最友好的场景其实是“用户少、载荷大”的持续传输模型。因为调度开销可以摊薄，资源分配也相对持续稳定。
多用户场景下，eMBB之间也存在轻重缓急的博弈。有些业务是大文件下载型，无限缓存，一直可以积压；有些是流媒体，周期性到达。调度器必须给后者提供足够的调度机会窗口，否则会出现周期性业务持续等资源，而大包业务占满所有窗口的局面，也就是常说的“大包饿死小包”。
处理这种问题，自然会对周期性业务分配半持续调度，也就是SPS资源，并且给实时性敏感的eMBB流媒体配置合适的QCI优先级和调度权重，而不只是无脑按CQI排序。这个经验在现网短视频业务占比高的区域特别有用。
6.2 URLLC：mini-slot抢占与低时延保障
URLLC业务对调度器来说，挑战不在“多少资源”，而在“多快的资源反应速度”。当URLLC数据到达时，常规eMBB调度周期可能还赶不上时延要求。这时调度器会使用mini-slot进行“抢占式”调度，把URLLC数据放在eMBB正在传输的时频资源中打进去，同时在下行控制信息中用一个特殊指示通知被抢占的eMBB终端“这部分资源作废”。
这其实就是URLLC机制里说的抢占指示preemption indication，通过专门的控制信道资源告知被抢占的终端哪些RE不可靠。对调度器来说，这是处理混合业务时最精细的操作之一：既保障低时延业务，同时尽量减少对eMBB传输的损伤，合理设计抢占的RB范围和保护资源区间。
6.3 网络切片与跨优先级的资源隔离
网络切片这个主题放在调度章节里，核心要讨论的是切片间的资源分配机制。不同的切片可以与不同的QoS策略和资源配置绑定，比如分别配置保证资源量、最大资源量，或者设置切片级别的优先级。
调度器的角色在这里变成“跨切片的资源池分配器”。如果切片的资源分配是专用的，比如固定部分RB给URLLC切片，那调度器对这部分资源直接走专属策略，逻辑上就相当于是两个独立调度器。如果是共享的，那每个调度周期内切片间如何去抢共享资源，就需要跨切片优先级策略来管控。
实现层面通常有没有优先级权重的加权调度，把切片权重乘在用户优先级上，形成最终的调度序列。现网切片调度出问题，常见原因是终端的切片标识配置、RRC的QoS映射和基站侧切片调度权重不一致，导致明明该高优先级的切片流量没有获得相应资源。
7. 现场优化中关于调度的常见误区和实用经验
7.1 误区：调整MCS或者功率就能解决调度不公平问题
不少同学一遇到边缘用户速率低，第一反应是调功率或者调MCS，我一开始也这样处理过一阵。但多数情况下问题根源在调度策略本身。边缘用户CQI低是物理限制，调度器如果公平机制做得好，即使速率不高也不至于长期饿死；但调度器若偏向最大信噪比策略，调功率帮不了实质性问题。
先看调度配置、看公平性指标、看用户被调度的机会分布，这是排查速率类问题更正确的顺序。
7.2 调参方向：优先检查的四个调度参数位置
如果你要在现网或模拟平台做调度相关调优，我建议从下面四个方向排查，这些也是我在各类问题里最高频使用的排查入口：
一是优先级权重和逻辑信道映射，先确认关键业务的LCP是否正确。二是CQI上报周期和外环MCS调整步长，看链路自适应是否“反应迟钝”。三是HARQ重传优先级和反馈定时配置，检查是否有重传卡死。四是半持续调度的资源分配周期和资源预留，确认周期性小包业务是否走了SPS。
这四个方向分别对应业务优先级、链路自适应、重传管理、资源分配方式，是调度器功能的最主要构面。绕着它们调，不容易跑偏。
7.3 一个典型的实操案例：某小区下行吞吐波动问题
分享一个我早期做过的问题排查。某小区下行速率周期性波动，时快时慢，从物理层看CQI并没有明显变化，从干扰统计看底噪也很平稳。当时我盯着链路自适应和干扰查了两天没有突破，后来一位老工程师提醒去看HARQ重传分布，这才发现该小区存在大量的半持续重传占用了资源。
进一步查最终发现是覆盖边缘有一批终端周期性触发重传，重传优先级被设置得过高，导致正常新传持续被挤压，小区整体吞吐随之波动。修复思路不是调功控，而是调整了重传相关的调度优先级权重，并优化了这批边缘用户的链路自适应步长，波动问题才逐步缓解。
这类问题如果不把调度器当作一个整体来考虑，而是只盯着物理层参数找原因，通常很难定位。调度是一个汇聚了无线侧所有要素的中枢模块，排查任何性能类问题，如果调度链路没有检查过，就得保留一个问号。
7.4 关于调度优化，我个人的几个习惯做法
最后分享几个我保持了很多年、也认为确实有效的个人做法。每次做无线参数优化前，我会先把小区当前业务模型梳理一遍，确认用户数量级、业务类型占比、上下行流量比，没有这个前提，谈调度策略就是盲人摸象。
对于有实时性要求的行业终端，我会更关注SR周期和BSR上报的配置，保证“需求可见性”足够及时；对于大带宽业务，我会优先检查BWP配置和RBG类型是否与业务粒度匹配，避免大包业务在细小资源块的碎片分配里打转。
另外一个习惯是做任何调度策略改动前，都先留存基线统计，包括每用户平均调度次数、平均MCS、HARQ重传率、CQI覆盖分布和上下行吞吐。改动之后对比这些维度看变化，调的是不是对的参数一目了然。调度器不像天线或者功率，你看不见摸不着，但它是最能影响无线网络真实体验的一层，值得花时间深挖。调试过程中，不必追求算法多高深，但至少要保证每一步决策都有据可循。
