5G MAC调度器决策链路解析：从CQI、HARQ到资源分配与优化

1. 调度器到底在管什么5G MAC层的“权力中心”聊5G无线接入技术前面几篇我们更多是站在物理层的视角看波形、看信道、看编码调制。到了调度这一篇整个视角要往上层移一步来到这里最复杂也最“现实”的模块。有人把MAC调度器比喻成十字路口的交通警察实际上它比交警权力大得多。交警只管通行顺序调度器决定的是每辆车在哪个车道、什么时间出发、用什么车速、油给多大、服务优先级是谁而且所有决策要在极短的时间内连续不断地做出来。在NR也就是5G系统里调度器位于MAC层承载的实体通常在基站侧被称为MAC Scheduler。它唯一的正式任务听起来很简单把时频资源分配给具体用户。具体到实现就是在每一个调度周期也就是通常说的TTITransmission Time Interval内决定哪些终端在哪些物理资源块上收发数据采用什么传输方案用什么调制编码等级调度的时长是多少要不要重传上行和下行各占多少。但这里我要先给一个非常重要、很多新人第一反应会搞反的结论调度器并不是只被信道质量一种因素驱动的。它的输入非常庞杂包括无线信道质量反馈、业务缓存量、逻辑信道优先级、时延约束、功率限制、HARQ状态、设备调度能力甚至终端支持的功能特性。所以调度本质上是一个带约束的多目标优化问题工程上谁也不会真的用通用优化算法去跑都是实时的启发式策略在兜底。对比4G的LTE调度5G调度的决策维度越来越多但调度周期反而可以更短。LTE的TTI是1ms一个子帧一个调度周期。NR在常规配下同样有一个符号级可变的调度能力Sub-6GHz和毫米波都有mini-slot的概念最少可以用2个OFDM符号就做一次调度。双连接、载波聚合、多个BWPBandwidth Part同时存在时一个调度器还要同时兼顾多套资源池。所以做5G协议栈也好做无线参数优化也好理解调度器的工作逻辑是很多后续问题排查的基础。这一篇我们不铺开讲代码实现重点走一遍“调度到底怎么做决策”“它依赖哪些反馈”“不同业务怎么差异化处理”“现网优化中有哪些坑”把调度这个模块从原理到落地串一遍。适合正在学5G技术的工程师、刚接入网优化岗位的同行也适合做协议测试的朋友在分析日志时快速找到头绪。2. 5G调度相比4G的核心变化mini-slot、动态帧结构与时间账本2.1 为什么NR要把TTI打散LTE时代我们习惯1ms TTI思考问题一个子帧分两个时隙每个时隙0.5ms调度基本以子帧为粒度。到了5G帧结构里一个时隙在30kHz子载波间隔下只有0.5ms15kHz下才是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反馈链路调度的第一步是问一个问题当前时刻这个用户在这段频带上能承受多高的编码效率答案主要来自终端上报的CQIChannel 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和缓存报告上行调度和下行调度有一个本质差异下行数据在基站侧基站知道自己要发多少上行数据在终端侧基站不知道终端缓存里有多少数据。这是上行调度机制设计的起点。终端有上行数据要发时第一步是发SRScheduling Request通过PUCCH上的专用资源告诉基站“我需要上行资源了”。基站收到SR后会先给终端分配一个相对较小的上行授权让终端能发BSRBuffer Status Report即上报自己不同逻辑信道群组里到底积压了多少数据。基站拿到BSR之后才真正判断要不要给这个终端分配更大的上行资源以及优先分配哪部分资源。这是很多新人理解上行调度时最容易绕晕的点。SR只是敲门砖BSR才是决定资源量级的“需求账单”。调度器通常并不完全相信BSR一次上报的结果因为从BSR生成到真正调度向数据发出终端缓存又可能发生变化。所以工程实现里针对上行还有流量过滤、缓存估算、预测补偿等算法。上行调度里还有个常被忽略的输入是功耗余量报告PHRPower Headroom Report。它告诉基站终端当前还剩多少发射功率余量。如果PHR显示已经到功率上限再提升MCS也没用调度器反而要降速或限制RB分配。这是“物理能力约束”纳入调度决策的一个具体体现。3.3 HARQ状态与重传调度优先级HARQ反馈是另一个调度器必须“敬畏”的输入。物理层有HARQ进程在管理每个数据包的ID、重传计数、软缓存合并。调度器要做的是决定一个新传的包还是重传的包优先占用资源。通常来说重传的优先级是高于新传的因为重传数据已经经历了无线传输和合并只差最后一步解码成功放弃重传意味着前面的传输全部浪费还拖累整个传输链路的时延和吞吐。很多调度器都会给重传预留“必传”的资源窗口压着新传的时间窗口。但这也不是完全绝对的策略。某些优化场景下如果重传的是低优先级业务而新传的是高优先级URLLC业务优先级可能反转过来先处理URLLC。这类冲突仲裁逻辑贯穿所有调度策略设计的始终也是不同厂商设备性能拉开差距的细节之一。4. 资源分配类型与DCI告诉终端“什么时候、哪里、怎么传”4.1 频域资源指示RBG位图与RB起始点长度指示调度决策做完必须通过下行控制信息DCI把“你该在哪个资源上传”这个指令发给终端。NR的频域资源分配分成两种类型这一点做物理层测试或者看日志的同行一定不陌生。Type 0用RBGResource Block Group位图来指示每一个bit对应一组资源块。它的好处是灵活性强可以支持不连续的频域资源分配代价是DCI里需要承载的bitmap长度跟着系统带宽走带宽越大开销越大。Type 1用起始RB位置加上资源块长度来指示允许调度器从任意一个RB开始连续分配指定数量的RB。它支持更细粒度分配但只能连续分配灵活性不如Type 0。调度器选哪个类型要根据业务对碎片化资源的需求来。大带宽的eMBB业务在多数场景用Type 0做整段资源块上的分配效率更高但小包业务用Type 1更节省DCI开销。终端不支持某个类型时调度器还必须回退。现场如果出现“DCI解析失败”“盲检不匹配”先检查资源分配类型和终端能力是否对得上这是我处理协议日志时第一优先排查的方向。4.2 时域资源指示与时隙偏移K0/K1NR还把“什么时候开始传”这个字段做成了时域资源分配表通过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 URLLCmini-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覆盖分布和上下行吞吐。改动之后对比这些维度看变化调的是不是对的参数一目了然。调度器不像天线或者功率你看不见摸不着但它是最能影响无线网络真实体验的一层值得花时间深挖。调试过程中不必追求算法多高深但至少要保证每一步决策都有据可循。