首页 › deep-tech › 5G MAC调度原理图解

5G MAC调度原理:基站如何分配每一毫秒的时频资源

想象一个教室,50个学生都要向老师提问,但教室只有一根话筒。谁能先说话、说多久?这需要一个调度员来分配。5G基站里的MAC调度器,就是这个"话筒分配员"——每隔零点几毫秒就要做一次决策:哪个手机发数据、用哪块频率、传多少比特。

一、为什么需要调度?——无线资源的"争抢"本质

无线通信最根本的约束是:频率是共享介质。一个基站覆盖范围内的所有手机,共享同一段频谱。如果没有调度,就像会议室里所有人同时大喊,结果谁也听不清。

调度的核心矛盾可以用一个公式概括:

$$R_{\text{total}} = \sum_{i=1}^{N} R_i, \quad \text{但} \quad R_i \geq 0, \quad \sum \text{资源} \leq \text{总带宽}$$

基站调度器的任务就是:在有限的时频资源内,决定每个用户分到多少,使得系统总吞吐量、公平性、时延等指标达到最优平衡。

调度器在协议栈中的位置

graph TB
    subgraph "基站 gNB 协议栈"
        RRC["RRC层<br/>无线资源配置"]
        SDAP["SDAP层<br/>QoS流映射"]
        PDCP["PDCP层<br/>加密/头压缩"]
        RLC["RLC层<br/>分段/ARQ"]
        MAC["MAC层 ⭐<br/>调度器在这里<br/>复用/优先级处理"]
        PHY["物理层<br/>调制/编码/天线映射"]
    end

    subgraph "调度器输入"
        CSI["CSI报告<br/>(CQI/RI/PMI)"]
        BSR["BSR<br/>(缓冲区状态)"]
        PHR["PHR<br/>(功率余量)"]
        QoS["QoS参数<br/>(5QI/ARP)"]
    end

    subgraph "调度器输出"
        DCI["DCI<br/>(下行控制信息)"]
        DATA["PDSCH/PUSCH<br/>数据传输"]
    end

    CSI --> MAC
    BSR --> MAC
    PHR --> MAC
    QoS --> MAC
    RRC --> MAC
    SDAP --> PDCP --> RLC --> MAC --> PHY
    MAC --> DCI
    MAC --> DATA

    style MAC fill:#ff6b6b,stroke:#333,color:#fff

MAC调度器是整个无线接入网中最核心、最复杂的软件模块之一。它位于MAC层内部,向上接收RLC层传来的数据包,向下控制物理层的资源分配。

二、调度的基本单位——时频资源格子

在深入调度流程之前,必须理解5G调度的最小操作对象是什么。

资源块(RB)与资源块组(RBG)

概念 定义 用途
RE(资源粒子) 1个子载波 × 1个OFDM符号 最小物理单位
PRB(物理资源块) 12个子载波 × 1个时隙(14个符号) 调度的基本单位
RBG(资源块组) 连续的P个PRB(P取决于BWP大小) Type 0分配的颗粒度

类比:把5G的频率带宽想象成一块巨大的停车位场。PRB是一个个车位,RBG是一排车位。调度器就是停车管理员,决定哪辆车停在哪个车位。

资源分配的两种模式

5G NR定义了两种频域资源分配方式:

graph LR
    subgraph "Type 0: 位图方式"
        direction TB
        B0["RBG0 ☑"]
        B1["RBG1 ☐"]
        B2["RBG2 ☑"]
        B3["RBG3 ☑"]
        B4["RBG4 ☐"]
        B5["RBG5 ☑"]
    end

    subgraph "Type 1: RIV方式"
        direction TB
        R1["起点 = RB 3"]
        R2["长度 = 8个RB"]
        R3["RIV = f(起点, 长度)"]
        R4["→ 分配 RB3~RB10"]
    end

    T0["Type 0<br/>灵活但不连续"] --> B0
    T1["Type 1<br/>连续但不够灵活"] --> R1
分配类型 指示方式 特点 适用DCI格式
Type 0 位图(Bitmap) 可以分配不连续的频段,灵活度高,信令开销大 DCI 1_1, DCI 0_1
Type 1 RIV(资源指示值) 只分配连续频段,信令开销小,适合小数据包 DCI 1_0, DCI 0_0(以及1_1/0_1可选)

RIV编码公式:

$$\text{RIV} = \begin{cases} N_{RB}(L-1) + RB_{start}, & \text{if } L-1 \leq \lfloor N_{RB}/2 \rfloor \ N_{RB}(N_{RB}-L+1) + (N_{RB}-1-RB_{start}), & \text{otherwise} \end{cases}$$

其中 $RB_{start}$ 是起始RB索引,$L$ 是连续分配的RB数量,$N_{RB}$ 是BWP的总RB数。

为什么需要两种方式? Type 1用少量比特就能表示连续分配(适合手机屏幕小数据包),Type 0允许频率分集增益(把数据分散到不同频段,对抗频率选择性衰落)。

三、下行调度全流程

下行调度是基站主动向手机发送数据的过程。基站自己知道有多少数据要发给哪个手机,所以调度的主动权在基站手里。

sequenceDiagram
    participant UE as 手机 UE
    participant gNB as 基站 gNB

    Note over UE,gNB: Step 1: 手机上报信道状态
    UE->>gNB: CSI报告 (CQI/RI/PMI)
    Note right of gNB: CQI=12 表示信道好<br/>CQI=3 表示信道差

    Note over UE,gNB: Step 2: 基站调度器决策
    Note right of gNB: 调度器运行(每个时隙)<br/>评估所有待调度UE<br/>选择UE × 分配资源 × 选MCS

    Note over UE,gNB: Step 3: 发送DCI控制信令
    gNB->>UE: PDCCH: DCI 1_1<br/>(频域位置、MCS、HARQ进程号)
    Note left of UE: 解析DCI得知:<br/>数据在哪些RB上<br/>用哪个MCS解码

    Note over UE,gNB: Step 4: 发送数据
    gNB->>UE: PDSCH (实际数据)
    Note left of UE: 接收 → 解调 → 解码

    Note over UE,gNB: Step 5: 反馈确认
    UE->>gNB: PUCCH: ACK/NACK
    Note right of gNB: NACK → 触发HARQ重传

调度器的关键决策

基站在每个调度时机(通常每个时隙 = 14个OFDM符号)要做三个核心决策:

  1. 选谁(Which UE):在所有待调度手机中,优先调度哪个
  2. 分多少资源(How much):分配多少个PRB
  3. 用什么速率(What MCS):调制阶数和编码率

这三个决策紧密耦合,核心依据是CQI(信道质量指示)。手机通过测量下行参考信号,将信道质量映射为一个4bit的CQI值(0~15),报告给基站。

CQI索引 调制方式 码率 × 1024 效率(bit/s/Hz)
1 QPSK 78 0.1523
6 QPSK 490 0.9570
9 16QAM 614 1.5273
12 64QAM 614 2.2910
15 256QAM 948 4.7402

工程直觉:CQI值越高,说明手机所处信道越好,可以用更激进的调制方式(256QAM),每个符号携带更多比特,相当于"路好就开快车"。

四、上行调度全流程

上行调度比下行复杂,因为基站不知道手机有多少数据要发。手机必须先"举手"(发送调度请求),基站才会分配资源。

sequenceDiagram
    participant UE as 手机 UE
    participant gNB as 基站 gNB

    Note over UE: 应用产生新数据<br/>放入发送缓冲区

    Note over UE,gNB: Step 1: 调度请求(举手)
    UE->>gNB: SR (Scheduling Request)<br/>PUCCH上发送1bit
    Note right of gNB: "我有数据要发!"

    Note over UE,gNB: Step 2: 基站分配少量资源
    gNB->>UE: DCI 0_0 (上行授权)
    Note left of UE: 获得少量PUSCH资源<br/>够发BSR

    Note over UE,gNB: Step 3: 手机报告缓冲区状态
    UE->>gNB: BSR (Buffer Status Report)<br/>通过PUSCH发送
    Note right of gNB: "我有200KB数据要发<br/>逻辑信道组1"

    Note over UE,gNB: Step 4: 基站分配充足资源
    gNB->>UE: DCI 0_1 (大授权)
    Note right of gNB: 根据BSR+PHR<br/>分配合适大小的资源

    Note over UE,gNB: Step 5: 手机发送数据
    UE->>gNB: PUSCH (实际数据)

    Note over UE,gNB: Step 6: 基站反馈确认
    gNB->>UE: PHICH/DCI: ACK/NACK

SR、BSR、PHR——上行调度的三把钥匙

报告类型 全称 携带信息 触发条件
SR Scheduling Request 1 bit("我要资源") 有新数据到达缓冲区,且无PUSCH资源
BSR Buffer Status Report 各逻辑信道组的待发数据量 数据到达、周期触发、数据优先级变化
PHR Power Headroom Report 手机剩余发射功率余量 周期触发、路径损耗变化超过阈值

为什么上行需要"三步走"?

用一个生活中的例子来理解:你在饭店吃饭,想加菜(上行发数据)。

基站拿到这三个信息,才能做出最优的上行资源分配决策。如果不先发SR直接给大授权,可能浪费资源(手机其实没那么多数据);如果不知道PHR,可能分配过多RB导致手机功率不够用。

五、调度算法:公平与效率的博弈

调度算法是调度器的灵魂。不同的算法代表了不同的"哲学"。

三大经典算法对比

graph TB
    subgraph "Round Robin 轮询"
        RR1["用户A → 分配"]
        RR2["用户B → 分配"]
        RR3["用户C → 分配"]
        RR4["用户A → 分配"]
        RR5["...循环往复"]
        RR1 --> RR2 --> RR3 --> RR4 --> RR5
    end

    subgraph "Max C/I 最大载干比"
        MC1["扫描所有用户CQI"]
        MC2["选CQI最高的用户"]
        MC3["分配全部资源给他"]
        MC1 --> MC2 --> MC3
    end

    subgraph "Proportional Fair 比例公平"
        PF1["计算每个用户:<br/>瞬时速率/平均速率"]
        PF2["选比值最大的用户"]
        PF3["兼顾当前信道与历史公平"]
        PF1 --> PF2 --> PF3
    end
算法 核心逻辑 系统吞吐量 公平性 适用场景
轮询(RR) 严格轮流,不看信道 低 最高 mMTC海量连接
Max C/I 只给信道最好的用户 最高 最差 竞争式容量测试
比例公平(PF) $\arg\max_i \frac{R_i(t)}{\bar{R}_i(t)}$ 中高 较好 现网最常用

比例公平算法的核心公式:

$$\text{调度优先级}_i = \frac{R_i(t)}{\bar{R}_i(t)}$$

其中 $R_i(t)$ 是用户 $i$ 在当前时隙可达的瞬时速率(由CQI决定),$\bar{R}_i(t)$ 是用户 $i$ 过去一段时间的平均吞吐量。

通俗解释: - 近基站用户(信道好):$R_i(t)$ 大,但 $\bar{R}_i(t)$ 也大(经常被调度),所以比值不一定高 - 远基站用户(信道差):$R_i(t)$ 小,但 $\bar{R}_i(t)$ 也小(很少被调度),所以比值可能反而高 - 结果:既照顾了信道好的用户的高速需求,又不会饿死边缘用户

现网中的调度器远比教科书复杂

实际基站的调度器不是单一算法,而是一个多层决策引擎:

  1. QoS优先级过滤:先按5QI将业务分类,URLLC(低时延)业务优先于eMBB(大带宽)
  2. 频域分组调度:不同用户在不同频段的信道质量不同,做频域维度的精细匹配
  3. 空间复用调度:MU-MIMO场景下,选择信道正交性好的用户配对
  4. 干扰协调:考虑邻区干扰,避免把边缘用户调度到受干扰严重的频段

六、半持续调度(SPS)与配置授权(CG)

动态调度每个时隙都发DCI,信令开销大且有时延。对于周期性的业务(如语音包每20ms一个),5G提供了更高效的方案。

SPS(下行半持续调度)

sequenceDiagram
    participant gNB as 基站
    participant UE as 手机

    Note over gNB,UE: VoNR语音通话建立
    gNB->>UE: RRC配置SPS参数<br/>周期=20ms, MCS, 资源位置
    gNB->>UE: DCI激活SPS (CS-RNTI加扰)

    Note over gNB,UE: 之后每20ms自动分配,无需DCI
    loop 每20ms
        gNB->>UE: PDSCH (语音包)
        UE->>gNB: ACK/NACK
    end

    Note over gNB,UE: 通话结束
    gNB->>UE: DCI去激活SPS

CG(上行配置授权)

配置授权是上行版的SPS,分两种类型:

类型 配置方式 特点
Type 1 RRC直接配置全部参数 无需DCI激活,配置即可用
Type 2 RRC配置参数 + DCI激活/去激活 灵活启停

SPS/CG节省了多少信令? 假设VoNR通话5分钟,语音包周期20ms: - 动态调度:需要 $5 \times 60 / 0.02 = 15000$ 次DCI - SPS/CG:仅1次激活DCI + 1次去激活DCI = 2次

节省了99.99%的DCI信令开销,这就是为什么5G能高效支持语音业务。

七、DCI——调度器的"指挥棒"

DCI(下行控制信息)是调度器向手机传达调度决策的信令。不同的DCI格式服务于不同场景。

关键DCI格式一览

DCI格式 方向 类型 资源分配 特点
DCI 0_0 上行 回退 Type 1 兼容性好,字段最少
DCI 0_1 上行 非回退 Type 0/1 功能最全,支持MU-MIMO
DCI 1_0 下行 回退 Type 1 紧急调度、RRC连接态
DCI 1_1 下行 非回退 Type 0/1 支持BWP切换、CBG反馈
DCI 2_0 — Slot格式指示 — TDD slot格式通知
DCI 2_1 — 抢占指示 — URLLC抢占eMBB资源

回退DCI vs 非回退DCI:

为什么要区分回退(Fallback)和非回退?

类比:回退DCI是"手摇电话"——功能简单但永远能用;非回退DCI是"智能手机"——功能强大但需要先配好参数。

八、不同5G场景的调度策略差异

5G三大场景对调度器的需求截然不同:

场景 核心需求 调度策略 典型参数
eMBB(增强移动宽带) 高吞吐量 PF调度,大块频域分配 256QAM,100MHz带宽
URLLC(超低时延高可靠) 确定性时延 抢占调度,mini-slot 1~2符号,MCS偏保守
mMTC(海量连接) 大连接数 轮询/基于竞争,小数据包 重复传输提升覆盖

URLLC的"抢占"机制尤其值得关注:

gantt
    title URLLC抢占eMBB资源示意
    dateFormat X
    axisFormat %s

    section eMBB用户
    已分配的PDSCH资源    :e1, 0, 14
    被抢占部分           :crit, e2, 4, 6

    section URLLC用户
    等待调度             :u1, 0, 4
    紧急抢占传输         :active, u2, 4, 6

    section 信令
    DCI 2_1抢占指示      :s1, 4, 5

当URLLC数据包到达时,基站可以立即抢占已经分配给eMBB用户的资源,通过DCI 2_1通知被抢占的eMBB用户哪些符号被拿走了。这是5G实现毫秒级低时延的关键机制之一。

九、调度时序——K0、K1、K2的理解

5G调度的时序关系是很多工程师的"困惑点"。基站不会在同一时刻发DCI和数据,它们之间有时间偏移。

参数 含义 典型值
K0 DCI到PDSCH的时隙偏移 0(同隙)或1(跨隙)
K1 PDSCH到HARQ-ACK的时隙偏移 1~15(通常2~4)
K2 DCI(上行授权)到PUSCH的时隙偏移 1~32

$$T_{\text{DCI}} + K_0 = T_{\text{PDSCH}}$$

$$T_{\text{PDSCH}} + K_1 = T_{\text{ACK}}$$

为什么需要K值偏移?

工程洞察:K0=0意味着DCI和数据在同一个时隙内发送,时延最低但对手机处理能力要求最高。现网中FDD通常用K0=0,TDD因为上下行交替的限制,K0可能为1或更大。

十、实战连接——工程师何时会用到调度知识?

1. 排查吞吐量问题

当用户投诉"网速慢"时,调度相关的排查思路:

2. 分析VoNR语音质量

3. 常见调试陷阱

陷阱 正确理解
"CQI好就一定速率高" CQI好只说明可以用高MCS,但如果分配的PRB少、或者有更高优先级用户抢占,速率仍然可能低
"调度器总是公平的" 不同厂商调度器实现差异很大,参数配置(如PF权重、MCS偏移)影响巨大
"上行SR失败就是覆盖问题" SR在PUCCH上发送,也可能是PUCCH资源冲突或功率控制配置不当
"DCI 1_1一定比1_0好" 非回退DCI依赖RRC配置,如果配置异常,反而不如回退DCI可靠

十一、调度器的设计哲学

回顾全文,5G MAC调度器的设计体现了三个核心哲学:

1. 按需分配(On-Demand)

上行调度的SR→BSR→Grant三步走,就是为了避免"大炮打蚊子"——不盲目给资源,而是根据手机实际需求精确分配。

2. 适应信道(Channel-Aware)

通过CSI反馈,调度器总是优先把好频段分给在该频段上信道质量好的用户,实现"频率分集+多用户分集"的双重增益。

3. 业务感知(QoS-Aware)

不是所有数据生而平等。URLLC的10ms时延要求必须优先于eMBB的视频缓冲,5QI参数就是调度器识别业务优先级的标签。

常见问题

Q: 动态调度和半持续调度能同时使用吗? A: 可以。同一个手机可以同时配置SPS(用于语音)和动态调度(用于数据)。SPS资源是"预留"的,动态调度的资源在SPS之外的时频位置。如果某个SPS周期没有语音包,该资源可以通过速率匹配被其他用户使用。

Q: 调度器多久做一次调度决策? A: 理论上每个时隙(sub-6GHz约0.5ms,毫米波约0.125ms)做一次。但实际实现中,基站处理器可能在多个时隙间做批量调度,降低计算压力。mini-slot调度可以把粒度细化到2~7个OFDM符号。

Q: 为什么手机不直接告诉基站"我要多少RB"? A: 因为手机不知道基站侧的整体资源使用情况和干扰情况。如果每个手机都自己要资源,可能导致冲突。集中式调度(基站决定)可以做到全局最优。

Q: Max C/I算法会不会让小区边缘用户永远上不了网? A: 理论上会。这就是为什么现网几乎不使用纯Max C/I算法。但Max C/I的思想被融合在比例公平算法中——当某个用户长期得不到调度时,其平均吞吐量 $\bar{R}_i(t)$ 趋近于0,导致优先级项 $\frac{R_i(t)}{\bar{R}_i(t)}$ 趋向无穷大,最终"被迫"被调度到。

Q: 上行SR发送失败怎么办? A: SR是在PUCCH上发送的1bit信号。如果发送失败(基站没收到),手机会在下一个SR周期重试。如果连续失败超过SR传输计数器上限(sr-TransMax),手机会触发随机接入过程(发送Msg1)来重新获取上行同步和资源。

参考来源

  1. 5G NR调度机制详解 - CSDN博客 — 5G NR调度流程、帧结构与资源分配详解
  2. Inside 5G NR Scheduling Algorithms: From Round Robin to Proportional Fair — 调度算法对比分析
  3. Demystifying the 5G Scheduler: A Deep Dive into Resource Allocation — 5G调度器输入输出与资源分配机制
  4. 5G NR DCI Formats - 3GLTEInfo — DCI格式完整参考
  5. MAC Resource Allocation and Scheduling in 5G/6G — eMBB/URLLC/mMTC场景下的调度策略

本文由「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 等场景全覆盖。

51学通信知识星球海报-扫码加入