好的,在完成了对第9章移动性管理的全面探索之后,我们现在将深入5G无线网络的心脏地带——第10章 调度(Scheduling)。如果说RRC是网络的“总导演”,制定宏观策略,那么MAC层的调度器就是“执行导演”,负责每一个毫秒级、每一个PRB(物理资源块)的精确实时分配。
深度解析 3GPP TS 38.300:10 Scheduling (调度)
本文技术原理深度参考了3GPP TS 38.300 V18.5.0 (2025-03) Release 18规范中,关于“Chapter 10 Scheduling”的核心章节,旨在为读者全面揭示5G MAC层调度器的基本运作原理、上下行调度的核心机制、支撑调度的测量信息,以及速率控制的实现方式。
前言:无线资源“大管家”的决策艺术
我们的主角小明,正在5G智慧校园的草坪上,和几位同学一起体验一场高清、多人的AR互动游戏。在他们周围,还有数百名学生正在刷短视频、进行视频通话、浏览网页。所有这些海量的、需求各异的数据流,都在争抢着同一个基站(gNB)有限的无线频谱资源。
是谁在这一片繁忙的“空中市场”中,扮演着“资源分配大管家”的角色?是谁在每一个瞬间,决定将下一个可用的资源块,是分配给小明那对时延要求极为苛刻的AR游戏数据,还是分配给旁边同学正在缓冲的高清视频?这个复杂而又瞬息万变的决策过程,就是调度(Scheduling)。
导师老王指着网络监控仪表盘上飞速滚动的调度日志说:“调度是无线接入网的灵魂。一个优秀的调度算法,可以在同样的硬件和频谱资源下,将系统容量和用户体验提升数倍。3GPP在38.300的第10章,并没有规定调度算法本身,因为这是厂商的核心竞争力。但是,它为所有调度器,制定了一套必须遵守的‘游戏规则’和‘工具箱’。”
今天,我们将深入这位“大管家”的办公室,看看他是如何利用这些规则和工具,来运筹帷幄,决胜于毫秒之间的。
1. 调度器的“仪表盘”:基本操作与决策依据 (10.1)
一个调度器要做出明智的决策,首先需要实时地掌握全面的信息。10.1节就定义了调度器操作的“仪表盘”——它的决策依据。
In order to utilise radio resources efficiently, MAC in gNB includes dynamic resource schedulers that allocate physical layer resources for the downlink and the uplink.
1.1 调度操作(Scheduler Operation)
- Taking into account the UE buffer status and the QoS requirements of each UE and associated radio bearers, schedulers assign resources between UEs;
- Schedulers may assign resources taking account the radio conditions at the UE identified through measurements made at the gNB and/or reported by the UE;
调度器在做决策时,主要看三个方面的信息:
-
“有多少货要送?”——缓冲区状态:UE会通过BSR(缓冲区状态报告),实时地告诉gNB自己每个逻辑信道组里有多少数据等待发送。这是上行调度的需求输入。对于下行,gNB可以直接看到来自核心网的数据队列。
-
“货物有多紧急?”——QoS要求:每个无线承载都关联着一个QoS等级。调度器必须优先为高优先级的业务(如VoNR语音、URLLC控制信令)分配资源,以满足其严苛的时延和可靠性要求。
-
“路况怎么样?”——无线信道条件:调度器通过UE上报的**CSI(信道状态信息)了解下行信道,通过测量SRS(探测参考信号)**了解上行信道。它会倾向于在用户信道质量好的“波峰”时刻为其分配资源,并选择合适的MCS,这种策略被称为“信道感知调度”或“机会调度”。
1.2 调度决策的“指挥棒”:信令 (Signalling of Scheduler Decisions)
- UEs identify the resources by receiving a scheduling (resource assignment) channel.
调度器的决策,最终通过物理层的控制信道(PDCCH)上的**DCI(下行控制信息)**来传达给UE。DCI就是调度器的“指挥棒”,明确地告诉UE:“在哪个时间、哪个频率、用哪种方式、传输哪个数据”。
1.3 调度的“眼睛”和“耳朵”:测量 (Measurements to Support Scheduler Operation)
- Uplink buffer status reports (…) are used to provide support for QoS-aware packet scheduling;
- Power headroom reports (…) are used to provide support for power aware packet scheduling.
为了让gNB的调度器“耳聪目明”,UE需要持续地提供两种关键的上行测量报告:
-
BSR (Buffer Status Report):我们已经知道,BSR是调度的“需求输入”。NR定义了多种BSR格式(短格式、长格式、截断格式等),以在信令开销和信息详尽度之间取得平衡。
-
PHR (Power Headroom Report):功率余量报告。PHR告诉gNB:“根据我当前的发射功率和最大允许发射功率,我还有多少‘余力’可以提升功率”。这是gNB进行“功率感知调度”的关键。如果一个UE的功率余量很小(已经接近最大功率发射),调度器可能会倾向于为其分配较少的资源块(带宽)或较低阶的MCS,以确保其能成功发送。
2. 下行调度:gNB的“分发艺术” (10.2)
下行调度由gNB完全主导,其核心机制是通过PDCCH动态分配资源。
In the downlink, the gNB can dynamically allocate resources to UEs via the C-RNTI on PDCCH(s).
2.1 动态调度与半静态调度
-
动态调度:这是最主要的方式。每一次PDSCH的传输,都由一个对应的PDCCH DCI来调度。
-
半静态调度 (SPS - Semi-Persistent Scheduling):对于像VoNR这样具有周期性、可预测流量的业务,如果每次都用PDCCH来调度,会造成很大的信令开销。SPS允许gNB通过RRC为UE配置一个周期性的下行资源。
RRC defines the periodicity of the configured downlink assignments while PDCCH addressed to CS-RNTI can either signal and activate the configured downlink assignment, or deactivate it;
配置完成后,gNB只需通过一条DCI(用CS-RNTI加扰)来“激活”这个周期性调度。一旦激活,UE就会在每个周期固定的位置,自动地去接收PDSCH,无需再监听PDCCH。当业务结束时,gNB再通过一条DCI来“去激活”它。
2.2 抢占(Pre-emption)
为了保障URLLC业务的极致低时延,NR引入了下行抢占机制。
The gNB may pre-empt an ongoing PDSCH transmission to one UE with a latency-critical transmission to another UE. The gNB can configure UEs to monitor interrupted transmission indications using INT-RNTI on a PDCCH.
场景代入:gNB正在为一个长时隙(如1ms)的eMBB用户(小明下载电影)发送一个大的PDSCH数据块。传输刚刚开始,突然一个URLLC用户(实验室的机器人)有紧急数据需要发送。
-
抢占:gNB调度器可以立即“抢占”掉正在为小明传输的PDSCH资源的一部分,转而用于发送机器人的高优先级数据。
-
中断通知:同时,gNB会发送一条用**INT-RNTI(Interruption-RNTI)**加扰的DCI。这条DCI会告诉小明:“你之前被调度的PDSCH资源中,从xx符号到yy符号的部分,已经被我占用了,这部分数据是无效的,你可以不用解码了。”
通过抢占机制,URLLC业务无需等待当前的长传输结束,可以“插队”进来,大大降低了传输时延。
3. 上行调度:UE的“申请与授权” (10.3)
上行调度比下行更复杂,因为它是一个“申请-授权”的过程。
In the uplink, the gNB can dynamically allocate resources to UEs via the C-RNTI on PDCCH(s).
3.1 动态授权与配置授权
-
动态授权 (Dynamic Grant):这是标准的流程。UE通过发送SR/BSR来“申请”资源,gNB根据申请,通过PDCCH下发UL Grant(上行授权)DCI来“授权”资源。
-
配置授权 (Configured Grant, CG):这是上行的SPS版本,对于URLLC和周期性业务至关重要。
In addition, with Configured Grants, the gNB can allocate uplink resources… Two types of configured uplink grants are defined:
-
Type 1 CG:gNB通过RRC信令,直接为UE配置一套周期性的上行资源。配置一旦生效,UE就可以在这些资源上自主地发送数据,无需任何PDCCH激活。这实现了零调度时延的上行传输,是URLLC的关键使能技术。
-
Type 2 CG:与下行SPS类似,RRC只配置周期,而激活和去激活由PDCCH(使用CS-RNTI)来动态控制。
-
3.2 上行取消(Cancellation)
与下行抢占相对应,上行引入了取消机制。
The gNB may cancel a PUSCH transmission… of a UE for another UE with a latency-critical transmission. The gNB can configure UEs to monitor cancelled transmission indications using CI-RNTI on a PDCCH.
场景代入:gNB已经为小明授权了一次PUSCH传输。但在小明准备发送之前,一个URLLC业务有紧急的上行需求。
-
取消:gNB可以决定取消之前给小明的这次授权。
-
取消通知:gNB会发送一条用**CI-RNTI(Cancellation-RNTI)**加扰的DCI。小明收到后,就会放弃这次已经准备好的PUSCH传输。
通过上行取消,gNB可以收回已分配但尚未使用的资源,并将其重新分配给更高优先级的业务。
4. “内部交通规则”:速率控制 (10.5)
4.1 下行速率控制 (10.5.1)
在下行,速率控制由gNB调度器直接执行。
In downlink, for GBR flows, the gNB guarantees the GFBR and ensures that the MFBR is not exceeded… for non-GBR flows, it ensures that the UE-AMBR is not exceeded…
gNB的调度器必须遵循从核心网获取的QoS承诺:
-
GBR流:保证其保证流比特率(GFBR),同时限制其不超过最大流比特率(MFBR)。
-
Non-GBR流:所有Non-GBR流共享一个UE-AMBR(UE总最大比特率),调度器需要确保该UE的总Non-GBR流量不超过这个上限。
-
UE-Slice-MBR:R16引入了切片级的速率上限,gNB还需要确保分配给某个切片的所有流的总速率不超过该限制。
4.2 上行速率控制 (10.5.2)
在上行,速率控制是UE和gNB协同完成的。
The UE has an uplink rate control function which manages the sharing of uplink resources between logical channels. RRC controls the uplink rate control function by giving each logical channel a priority, a prioritised bit rate (PBR), and a buffer size duration (BSD).
UE内部的**逻辑信道优先级(LCP)**机制,就是上行速率控制的核心。我们已在6.2节的FAQ中介绍过其基本流程:
-
优先满足PBR:UE的MAC实体在填充一个TB时,首先会按照从高到低的优先级,为每个逻辑信道分配资源,直到满足其优先比特率(PBR)。PBR可以看作是gNB为每个逻辑信道承诺的“最低保障速率”。
-
再分配剩余资源:如果还有剩余的UL Grant,再按照优先级,将资源分配给所有还有数据的逻辑信道。
gNB通过RRC配置每个逻辑信道的优先级和PBR,而UE则在每次获得UL Grant时,严格执行这个“两步走”的填充规则。通过这种方式,gNB间接地控制了UE上行不同业务之间的速率分配。
总结:一个复杂的多目标优化问题
通过对第10章的深入学习,我们揭开了5G MAC层调度器这位“大管家”的神秘面纱。我们发现,调度远非简单的资源分配,而是一个复杂、实时、多目标的优化问题。调度器需要在毫秒之间,做出艰难的权衡:
-
吞吐率 vs. 公平性:是优先服务信道好的用户以最大化小区吞吐率,还是兼顾边缘用户以保证公平性?
-
时延 vs. 效率:是优先为URLLC业务抢占资源以保证其低时延,还是保证eMBB用户的长传输以提升频谱效率?
-
需求 vs. 供给:如何根据成百上千个UE不断变化的BSR和CSI,精确地匹配有限的上下行资源?
3GPP为调度器提供了丰富的“工具箱”——动态调度、SPS/CG、抢占/取消、优先级机制(QoS, LCP, CAPC)——来应对这些挑战。而如何巧妙地运用这些工具,组合成一个高效的调度算法,正是不同设备厂商之间核心竞争力的体现。
FAQ
Q1:调度器是gNB的一部分吗?它具体位于哪个协议层?
A1:是的,调度器是gNB的核心功能模块,它位于MAC子层。MAC层负责执行调度决策(如逻辑信道复用),而调度器算法本身,则可以看作是MAC层的一个智能“大脑”,它收集来自RRC层(QoS配置)、物理层(CSI/SRS测量)以及UE MAC层(BSR/PHR)的各种输入,然后输出调度决策(DCI),指挥MAC层和物理层进行具体的资源分配和传输。
Q2:SPS(半静态调度)和CG(配置授权)有什么区别?
A2:SPS和CG分别是下行和上行的半持续调度机制,思想类似,但实现方式和应用场景略有不同。SPS用于下行,RRC配置周期后,需要PDCCH(使用CS-RNTI)来激活/去激活。而CG用于上行,它有两种类型:Type 2 CG与SPS类似,也需要PDCCH激活。而Type 1 CG则更为激进,它由RRC直接配置并激活,UE一旦配置成功,就可以在指定的周期性资源上自主发送,无需任何PDCCH指令。Type 1 CG实现了零调度时延的上行,是URLLC的关键技术。
Q3:下行抢占(Pre-emption)和上行取消(Cancellation)听起来很相似,为什么用两个不同的词?
A3:这两个词精确地描述了物理过程的不同。下行抢占发生在传输已经开始之后。gNB已经开始向UE-A发送一个长的PDSCH,中途为了给UE-B发送紧急数据,它“抢占”了UE-A后续本应使用的物理资源。对于UE-A来说,它的接收过程被“中断”了。而上行取消发生在传输开始之前。gNB已经通过UL Grant授权了UE-A在未来某个时刻进行PUSCH传输,但在这之前,gNB又决定将这个资源给UE-B,于是它发送取消指令,让UE-A“取消”这次已计划但未开始的传输。
Q4:UE的上行速率是由UE自己控制的,还是由gNB控制的?
A4:是由gNB间接但精确地控制的。UE不能随心所欲地发送数据。1)发送时机和总量:UE只有在收到gNB的UL Grant后才能发送,并且发送的数据总量不能超过Grant的大小。gNB通过控制UL Grant的发放频率和大小,从根本上控制了UE的总上行速率。2)不同业务的速率分配:对于一次给定的UL Grant,UE内部不同业务(逻辑信道)如何瓜分这次传输机会,则由gNB通过RRC配置的**LCP规则(优先级和PBR)**来决定。因此,虽然LCP的执行在UE侧,但规则的制定权在gNB。可以说,UE的上行速率,完全在gNB的“掌控”之中。
Q5:BSR和SR都是UE用来请求上行资源的,为什么需要两种机制?
A5:这是为了在信令开销和信息量之间取得平衡。SR(调度请求)非常“便宜”,它只是PUCCH上的一个1比特信号,开销极小。它的作用是快速地告诉gNB:“我饿了,需要吃饭”。但它没说自己有多饿。gNB收到SR后,通常会先给UE一点“开胃菜”(一个小UL Grant)。而BSR(缓冲区状态报告)则比较“昂贵”,它需要占用PUSCH资源来传输一个MAC CE,但它能提供非常详细的信息:“我不仅饿了,而且我的A/B/C三个盘子里分别有多少食物等待处理”。gNB看到BSR后,才能精确地为UE准备一顿大小合适的“正餐”(一个大的UL Grant)。SR用于快速触发,BSR用于精确定量,两者配合,实现了高效的上行请求。