<!-- title: 5G无线资源调度原理全解 -->

# 5G无线资源调度原理全解：从MAC调度器到上下行资源分配

> **阅读提示**：本文面向有1-3年通信工程经验的工程师，系统讲解5G NR无线资源调度的核心原理。读完本文，你将理解：基站如何决定"谁在什么时候、用多少频率资源、发送什么数据"——这是整个移动通信系统中最核心的资源管理问题。

---

## 一、从一个生活类比说起

想象一个银行大厅，有10个柜台（频率资源）、8小时营业时间（时域资源），每天要服务200位客户（用户数据）。**大堂经理**就是调度器——他需要决定：

- **谁先服务**（用户优先级）
- **分配哪个柜台**（频域资源块）
- **服务多久**（时域长度）
- **用多快的速度办理**（调制编码方案MCS）

好的大堂经理不会只给VIP服务而让普通客户等到关门（纯最大速率），也不会让每个人严格排队导致柜台大量空闲（纯轮询）。**调度器要做的，就是在系统吞吐量和用户公平性之间找到最优平衡点。**

---

## 二、调度器在协议栈中的位置

5G NR的调度器位于 **gNB的MAC层**，是整个无线接入网最核心的决策引擎。

```mermaid
graph TB
    subgraph "UE协议栈"
        APP_U[应用层]
        SDP_U[SDAP层]
        PDCP_U[PDCP层]
        RLC_U[RLC层]
        MAC_U[MAC层]
        PHY_U[物理层]
        APP_U --> SDP_U --> PDCP_U --> RLC_U --> MAC_U --> PHY_U
    end

    subgraph "gNB协议栈"
        APP_G[应用层]
        SDP_G[SDAP层]
        PDCP_G[PDCP层]
        RLC_G[RLC层]
        MAC_G["MAC层<br/>🔴 调度器位于此处"]
        PHY_G[物理层]
        APP_G --> SDP_G --> PDCP_G --> RLC_G --> MAC_G --> PHY_G
    end

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

    subgraph "调度器输出"
        DCI["DCI<br/>(下行控制信息)"]
    end

    CSI --> MAC_G
    BSR --> MAC_G
    PHR --> MAC_G
    QoS --> MAC_G
    MAC_G --> DCI

    style MAC_G fill:#ff6b6b,stroke:#c0392b,color:#fff,stroke-width:3px
    style CSI fill:#74b9ff,stroke:#0984e3
    style BSR fill:#74b9ff,stroke:#0984e3
    style PHR fill:#74b9ff,stroke:#0984e3
    style QoS fill:#74b9ff,stroke:#0984e3
    style DCI fill:#55efc4,stroke:#00b894
```

**为什么调度器放在MAC层？** 因为MAC层既能"看到"上层（RLC/PDCP）有多少数据待发送（通过BSR），又能"看到"下层（物理层）的信道状态（通过CSI），是信息汇聚的最佳位置。

---

## 三、调度的基本单位：时频资源网格

### 3.1 频域单位

| 资源单位 | 定义 | 5G NR典型值 |
|----------|------|------------|
| **子载波（Subcarrier）** | 最小频域单位 | 15/30/60/120kHz |
| **PRB（物理资源块）** | 12个子载波 | 180kHz@15kHz SCS |
| **BWP（带宽部分）** | 一组连续PRB | 可配置，最大275个PRB |

### 3.2 时域单位

| 资源单位 | 定义 | 说明 |
|----------|------|------|
| **OFDM符号** | 最小时域单位 | Normal CP下每符号约33.3μs（15kHz SCS） |
| **Slot（时隙）** | 14个OFDM符号 | 1ms@15kHz，0.5ms@30kHz |
| **Mini-slot** | 2~13个符号 | URLLC场景，支持更短调度间隔 |

### 3.3 资源分配的基本思想

5G调度的本质就是在 **时-频-空三维空间** 中为每个UE分配资源：

$$\text{调度资源} = \underbrace{f(\text{PRB})}_{\text{频域}} \times \underbrace{t(\text{Symbol/Slot})}_{\text{时域}} \times \underbrace{s(\text{Layer/Beam})}_{\text{空域}}$$

```mermaid
graph LR
    subgraph "资源分配三维空间"
        F["频域<br/>PRB分配"]
        T["时域<br/>Slot/Mini-slot"]
        S["空域<br/>MIMO Layer"]
    end
    F --- T --- S

    subgraph "调度决策输入"
        CQI["信道质量CQI"]
        BUF["缓存数据量BSR"]
        PWR["功率余量PHR"]
        QCI["QoS需求5QI"]
    end

    CQI --> F
    CQI --> S
    BUF --> T
    PWR --> F
    QCI --> T

    style F fill:#a29bfe,stroke:#6c5ce7,color:#fff
    style T fill:#fd79a8,stroke:#e84393,color:#fff
    style S fill:#fdcb6e,stroke:#f39c12,color:#fff
```

---

## 四、下行调度全流程：从数据到空口

### 4.1 下行调度整体流程

```mermaid
sequenceDiagram
    participant Core as 核心网(UPF)
    participant gNB as gNB基站
    participant SCH as MAC调度器
    participant UE as 终端UE

    Core->>gNB: 下行业务数据(通过GTP隧道)
    gNB->>gNB: RLC分段+PDCP加密
    UE->>gNB: CSI报告(CQI/RI/PMI)通过PUCCH
    UE->>gNB: HARQ-ACK/NACK反馈

    Note over SCH: 调度器综合评估：<br/>1.各UE信道质量(CQI)<br/>2.待发送数据量<br/>3.QoS优先级(5QI)<br/>4.HARQ重传需求

    SCH->>SCH: 运行调度算法<br/>选择UE + 分配PRB + 确定MCS
    SCH->>UE: DCI(DCI 1_0/1_1)通过PDCCH
    Note over UE: DCI告知UE：<br/>- 哪些PRB有你的数据<br/>- 用的什么MCS<br/>- HARQ进程号
    SCH->>UE: PDSCH数据传输
    UE->>gNB: HARQ-ACK或NACK(PUCCH)

    Note over UE,gNB: 如NACK，调度器安排重传
```

### 4.2 下行DCI格式详解

下行调度通过 **PDCCH上的DCI（下行控制信息）** 通知UE。5G NR定义了多种DCI格式：

| DCI格式 | 用途 | 特点 |
|---------|------|------|
| **DCI 1_0** | 基础下行调度（fallback） | 固定大小，兼容性好，适用于所有场景 |
| **DCI 1_1** | 增强下行调度 | 支持BWP切换、CBG传输、灵活MCS表等 |
| **DCI 2_0** | Slot格式指示 | 告诉UE组哪些符号是DL/UL/Flexible |
| **DCI 2_1** | 抢占指示 | URLLC抢占eMBB资源时通知被抢占UE |
| **DCI 2_2** | TPC命令集 | 上行功控命令 |
| **DCI 2_3** | SRS TPC命令集 | SRS发送功率控制 |

**DCI 1_0 vs DCI 1_1 的选择逻辑**：当UE还未完成RRC完整配置时（如初始接入阶段），只能用DCI 1_0；完成配置后，调度器优先使用DCI 1_1以获得更灵活的资源分配能力。

### 4.3 下行资源分配类型

5G NR支持两种频域资源分配类型：

| 分配类型 | 分配粒度 | 比特开销 | 适用场景 |
|---------|---------|---------|---------|
| **Type 0** | 以RBG为单位（连续或非连续） | 较高（位图） | 大数据量传输，灵活性高 |
| **Type 1** | 连续PRB，用RIV编码 | 较低（连续分配编码） | 节省控制信令开销 |

**RIV（Resource Indication Value）** 的编码公式：

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

其中 $\text{RB}_{\text{start}}$ 是起始PRB索引，$L_{\text{RBs}}$ 是分配的PRB长度，$N_{\text{RB}}$ 是BWP的PRB总数。

**为什么设计两种分配类型？** Type 0用位图（Bitmap）可以分配不连续的RBG，适合频率选择性调度（把好信道质量的频段分配给UE）；Type 1只能分配连续PRB，但信令开销小，适合信道质量均匀的场景。

---

## 五、上行调度全流程：从敲门到数据发送

### 5.1 上行调度的特殊性

上行调度与下行有一个根本区别：**基站不知道UE什么时候有数据要发**。所以上行调度需要一套"敲门→说明来意→获得资源→发送数据"的流程。

```mermaid
sequenceDiagram
    participant UE as 终端UE
    participant gNB as gNB基站
    participant SCH as MAC调度器

    Note over UE: 上行数据到达缓冲区

    rect rgb(230, 240, 255)
        Note over UE,gNB: 阶段1：敲门（SR调度请求）
        UE->>gNB: SR(Scheduling Request)通过PUCCH
        Note over SCH: "我有数据要发，<br/>请给我少量上行资源"
        SCH->>UE: 小量UL Grant(DCI 0_0/0_1)
    end

    rect rgb(255, 240, 230)
        Note over UE,gNB: 阶段2：说明需求（BSR报告）
        UE->>gNB: BSR(Buffer Status Report)<br/>MAC CE通过PUSCH
        Note over SCH: "我有X字节数据待发，<br/>请给我足够的上行资源"
        SCH->>UE: 合适大小的UL Grant
    end

    rect rgb(230, 255, 230)
        Note over UE,gNB: 阶段3：正式发送数据
        UE->>gNB: 上行数据通过PUSCH
        gNB->>UE: HARQ-ACK/NACK
    end

    Note over UE,gNB: 同时UE还上报PHR（功率余量）<br/>帮助调度器判断UE能支持多少PRB
```

### 5.2 三种关键上行报告

#### （1）SR（Scheduling Request，调度请求）

| 特性 | 说明 |
|------|------|
| **承载信道** | PUCCH Format 1（专用SR资源） |
| **触发条件** | UE有新数据到达且无可用UL资源 |
| **内容** | 仅一个比特——"1"表示请求资源 |
| **配置** | RRC配置SR周期和偏移（如每2/5/10/20个Slot） |
| **失败处理** | SR发送次数超过sr-TransMax后，触发随机接入 |

> **调试陷阱**：如果UE频繁触发随机接入而非SR，检查 `sr-TransMax` 配置和PUCCH SR资源是否正常分配。

#### （2）BSR（Buffer Status Report，缓存状态报告）

BSR通过MAC CE告诉基站UE缓冲区中有多少数据待发送：

| BSR类型 | 触发条件 | 说明 |
|---------|---------|------|
| **Regular BSR** | 高优先级数据到达且无UL资源 | 最重要，必须上报 |
| **Periodic BSR** | 定时器 `periodicBSR-Timer` 到期 | 周期性更新缓冲区状态 |
| **Padding BSR** | UL Grant有剩余字节 | 不浪费已分配的资源 |

BSR按逻辑信道组（LCG）上报，5G NR支持最多8个LCG（LTE只有4个），粒度更细。

#### （3）PHR（Power Headroom Report，功率余量报告）

PHR告诉基站UE还有多少发射功率余量：

$$\text{PH} = P_{\text{CMAX}} - P_{\text{PUSCH}}$$

其中 $P_{\text{CMAX}}$ 是UE最大发射功率，$P_{\text{PUSCH}}$ 是当前PUSCH实际使用的功率。

> **为什么调度器需要PHR？** 如果UE功率余量不足，即使给它分配很多PRB，UE也没功率发——就像给了一辆油量不足的汽车一条8车道高速，跑不快。调度器根据PHR可以判断分配多少PRB是合理的。

### 5.3 上行DCI格式

| DCI格式 | 用途 | 特点 |
|---------|------|------|
| **DCI 0_0** | 基础上行调度（fallback） | 固定大小，简化版 |
| **DCI 0_1** | 增强上行调度 | 支持BWP、CBG、多MIMO层、SRS等 |

---

## 六、经典调度算法详解

### 6.1 三大经典算法

#### （1）轮询调度（Round Robin, RR）

$$\text{选择用户} = \text{按顺序轮转}$$

**类比**：银行大厅让所有客户按取号顺序依次服务，每人固定时间。

- ✅ 最公平
- ❌ 效率最低——信道差的用户和信道好的用户分配一样多的资源

#### （2）最大载干比调度（Max C/I）

$$\text{选择用户} = \arg\max_{k} \quad \text{CQI}_k(t)$$

**类比**：大堂经理只给信号满格的客户服务，信号差的等到天荒地老。

- ✅ 系统总吞吐量最大
- ❌ 极度不公平——小区边缘用户可能"饿死"

#### （3）比例公平调度（Proportional Fair, PF）

$$\text{选择用户} = \arg\max_{k} \quad \frac{R_k(t)}{\bar{R}_k(t)}$$

其中 $R_k(t)$ 是用户 $k$ 在时刻 $t$ 的瞬时可达速率，$\bar{R}_k(t)$ 是用户 $k$ 的历史平均吞吐量。

**类比**：大堂经理综合考虑"这个客户现在办业务快不快"和"这个客户最近被服务了多少"——如果你最近一直被服务，你的优先级就会降低；如果你很久没被服务，即使你业务办理得慢，也有机会。

- ✅ 兼顾效率和公平
- ✅ 工程中最常用的基础算法

### 6.2 三种算法对比

| 维度 | 轮询RR | 最大C/I | 比例公平PF |
|------|--------|---------|-----------|
| **系统吞吐量** | 低 | 最高 | 中高 |
| **用户公平性** | 最高 | 最低 | 较高 |
| **边缘用户体验** | 中 | 差 | 好 |
| **算法复杂度** | 低 | 低 | 中 |
| **5G现网使用** | 辅助 | 辅助 | ✅ 主力 |

### 6.3 5G增强型调度算法

5G NR引入了多种增强调度策略以适应eMBB/URLLC/mMTC差异化场景：

| 增强算法 | 核心思想 | 适用场景 |
|---------|---------|---------|
| **MLWDF** | 考虑队列时延加权的比例公平 | GBR业务、视频通话 |
| **EXP-PF** | 指数加权的时延优先 | 低时延业务 |
| **QoS感知调度** | 按5QI优先级分层调度 | 多业务混合 |
| **多用户配对** | MU-MIMO下选择正交性好的用户对 | Massive MIMO |

**MLWDF（Modified Largest Weighted Delay First）** 的度量值：

$$\text{Metric}_k = \alpha_k \cdot W_k(t) \cdot \frac{R_k(t)}{\bar{R}_k(t)}$$

其中 $W_k(t)$ 是用户 $k$ 的队头包等待时间，$\alpha_k$ 是QoS权重因子。这个公式在PF基础上加入了**时延惩罚**——等你太久的人优先级更高。

---

## 七、动态调度 vs 半静态调度

### 7.1 动态调度（Dynamic Scheduling）

这是默认的调度方式：每个Slot调度器都重新决策，通过DCI实时通知UE。

**优点**：灵活，能实时适应信道变化
**缺点**：每个TTI都需要PDCCH开销，UE需要持续盲检DCI

### 7.2 半持续调度/配置授权（SPS/Configured Grant）

对于周期性的业务（如VoIP语音包每20ms一个），没必要每次都走"SR→BSR→Grant"的完整流程。SPS/CG机制可以预分配周期性资源。

```mermaid
graph TB
    subgraph "下行SPS"
        RRC_DL["RRC配置SPS参数<br/>周期/MCS/NDI等"]
        ACT_DL["DCI 1_1激活SPS<br/>(CS-RNTI加扰)"]
        TX_DL["周期性PDSCH传输<br/>无需每次DCI"]
        DEACT_DL["DCI 1_1去激活SPS"]

        RRC_DL --> ACT_DL --> TX_DL
        TX_DL --> TX_DL
        TX_DL --> DEACT_DL
    end

    subgraph "上行Configured Grant Type 1"
        RRC_UL1["RRC直接配置所有参数<br/>周期/偏移/PRB/MCS等"]
        TX_UL1["UE在配置时刻直接发PUSCH<br/>无需DCI激活"]

        RRC_UL1 --> TX_UL1
        TX_UL1 --> TX_UL1
    end

    subgraph "上行Configured Grant Type 2"
        RRC_UL2["RRC配置基本参数"]
        ACT_UL2["DCI 0_0/0_1激活<br/>(CS-RNTI加扰)"]
        TX_UL2["UE在激活后的周期位置<br/>直接发PUSCH"]
        DEACT_UL2["DCI去激活"]

        RRC_UL2 --> ACT_UL2 --> TX_UL2
        TX_UL2 --> TX_UL2
        TX_UL2 --> DEACT_UL2
    end

    style RRC_DL fill:#dfe6e9,stroke:#636e72
    style ACT_DL fill:#55efc4,stroke:#00b894
    style TX_DL fill:#ffeaa7,stroke:#fdcb6e
    style RRC_UL1 fill:#dfe6e9,stroke:#636e72
    style TX_UL1 fill:#ffeaa7,stroke:#fdcb6e
    style RRC_UL2 fill:#dfe6e9,stroke:#636e72
    style ACT_UL2 fill:#55efc4,stroke:#00b894
    style TX_UL2 fill:#ffeaa7,stroke:#fdcb6e
```

### 7.3 SPS vs CG对比

| 维度 | 下行SPS | 上行CG Type 1 | 上行CG Type 2 |
|------|---------|-------------|-------------|
| **配置方式** | RRC + DCI激活 | 仅RRC配置 | RRC + DCI激活 |
| **是否需要DCI激活** | 是 | 否 | 是 |
| **灵活性** | 中 | 低（全预配置） | 中 |
| **适用场景** | VoNR、视频通话 | URLLC周期性小包 | URLLC/IIoT |
| **省电效果** | UE无需持续监听PDCCH | UE无需监听PDCCH | 激活后无需监听 |

### 7.4 SPS/CG的核心参数

| 参数 | 说明 | 典型值 |
|------|------|--------|
| **周期（Periodicity）** | 资源出现的间隔 | 10/20/32/40/64/80/160个Slot |
| **nrofHARQ-Processes** | SPS专用HARQ进程数 | 1~8 |
| **mcs-Table** | 调制编码表 | 64QAM表/256QAM表 |
| **rbg-Size** | RBG大小 | Configuration 1/2 |
| **harq-ProcID-Offset** | HARQ进程偏移 | 0~15 |

---

## 八、MCS选择与传输块大小计算

### 8.1 从CQI到MCS

UE上报的CQI（Channel Quality Indicator）是一个1~15的索引，代表UE建议的MCS级别。调度器参考CQI但不一定完全遵从——可能因QoS需求或负载情况调整。

| CQI索引 | 调制方式 | 码率×1024 | 频谱效率(bit/s/Hz) |
|---------|---------|----------|-------------------|
| 1 | QPSK | 78 | 0.1523 |
| 7 | 16QAM | 490 | 1.9141 |
| 10 | 64QAM | 802 | 3.3223 |
| 15 | 256QAM | 948 | 7.4063 |

### 8.2 传输块大小（TBS）计算

调度器确定了PRB数量和MCS后，需要计算一次能传多少数据：

$$\text{TBS} = N_{\text{PRB}} \times N_{\text{RE/PRB}} \times \text{效率} \times Q_m / \text{缩放因子}$$

其中：
- $N_{\text{RE/PRB}}$ = 每PRB的RE数（12子载波 × 可用OFDM符号数 - 开销）
- $Q_m$ = 调制阶数（QPSK=2, 16QAM=4, 64QAM=6, 256QAM=8）
- 效率 = 码率（由MCS表查得）

> **实战注意**：实际TBS计算还要减去DMRS、CSI-RS等参考信号开销，不同RRC配置的开销不同。调试时如果发现实际吞吐量与理论值差异大，首先检查DMRS配置（Additional DMRS会占用不少RE）。

---

## 九、调度与HARQ的协作

调度器与HARQ（混合自动重传请求）紧密协作，实现快速纠错：

```mermaid
sequenceDiagram
    participant SCH as 调度器
    participant UE as UE

    Note over SCH,UE: 新传
    SCH->>UE: DCI(NDI=1, 新数据指示)
    SCH->>UE: PDSCH数据
    UE->>SCH: HARQ-NACK

    Note over SCH,UE: 重传（同一HARQ进程）
    SCH->>UE: DCI(NDI=0, 重传)
    SCH->>UE: PDSCH冗余版本(RV=1或2或3)
    UE->>SCH: HARQ-ACK

    Note over SCH: 调度器优先级：<br/>1. 重传 > 新传<br/>2. GBR > Non-GBR<br/>3. 高5QI优先级 > 低5QI优先级
```

**关键原则：重传优先于新传**。因为HARQ有严格的时序要求（必须在特定时间内完成反馈和重传），否则整个HARQ进程会被挂起，浪费缓冲区资源。

5G NR支持最多16个下行HARQ进程（LTE只有8个），更大的进程数意味着可以同时有更多数据"在飞"，提高吞吐量。

---

## 十、5G调度的新特性：相比4G LTE的进化

| 维度 | 4G LTE | 5G NR | 工程意义 |
|------|--------|-------|---------|
| **调度粒度** | 固定1ms TTI | 灵活Slot/Mini-slot(2符号起) | URLLC时延可降到0.1ms |
| **带宽灵活性** | 固定系统带宽 | BWP动态切换 | UE省电，按需分配带宽 |
| **上行CG** | 仅SPS | CG Type 1 + Type 2 | URLLC零授权时延 |
| **HARQ进程** | 8个 | 16个 | 更高吞吐量 |
| **MCS表** | 固定两种 | 三种（含低SE高可靠表） | 适配URLLC高可靠性 |
| **CBG重传** | 不支持 | 支持码块组级重传 | 大包只重传出错的部分 |
| **抢占调度** | 不支持 | DCI 2_1抢占指示 | URLLC可打断eMBB |

---

## 十一、现网调试实战要点

### 11.1 调度相关关键计数器

| 计数器/指标 | 含义 | 异常判断 |
|------------|------|---------|
| **PRB利用率** | 已分配PRB/总PRB | >80%说明容量受限 |
| **CQI分布** | UE上报CQI的统计分布 | CQI<7占比高→覆盖问题 |
| **SR失败次数** | SR超时触发RA的次数 | 突增→PUCCH资源配置问题 |
| **BSR上报频率** | BSR MAC CE发送频次 | 过高→UL Grant不足 |
| **DCI漏检率** | UE未检测到DCI的比例 | 高→PDCCH覆盖或聚合等级问题 |
| **MCS分布** | 实际使用的MCS统计 | 集中在低阶→干扰或覆盖差 |

### 11.2 常见问题排查思路

**问题1：下行吞吐量低**
1. 检查CQI → 低CQI说明信道质量差（覆盖/干扰）
2. 检查MCS分布 → 如果CQI高但MCS低，检查MCS表配置
3. 检查PRB利用率 → 如果PRB利用率高但吞吐量低，可能是MCS太保守
4. 检查RI（Rank Indicator）→ 空分复用层数少则吞吐量受限

**问题2：上行吞吐量低**
1. 检查PHR → 功率不足导致无法使用高阶MCS或大量PRB
2. 检查BSR → 如果BSR大但Grant小，调度器可能受限
3. 检查SR → 如果SR频繁触发随机接入，检查PUCCH资源配置

**问题3：URLLC时延抖动大**
1. 检查是否启用了CG/SPS → 动态调度的SR-BSR-Grant流程引入额外时延
2. 检查Mini-slot是否配置 → 标准Slot调度粒度不够细
3. 检查HARQ反馈时序 → 是否使用了最短K1值

---

## 十二、调度与网络切片的关系

5G网络切片的端到端实现，在无线侧依赖调度器的 **QoS感知调度** 能力：

```mermaid
graph TB
    subgraph "核心网侧"
        SMF["SMF<br/>QoS Rule + QFI"]
        UPF["UPF<br/>按QFI标记报文"]
    end

    subgraph "无线侧调度"
        SDAP["SDAP层<br/>QFI→DRB映射"]
        QoS_Table["QoS参数表<br/>5QI→优先级/时延/误码率"]
        SCHED["调度器<br/>按QoS优先级分配资源"]
    end

    subgraph "三种典型切片场景"
        EMBB["eMBB切片<br/>最大吞吐量优先"]
        URLLC["URLLC切片<br/>最低时延优先"]
        MMTC["mMTC切片<br/>最大连接数优先"]
    end

    SMF --> SDAP
    UPF --> SDAP
    SDAP --> QoS_Table
    QoS_Table --> SCHED
    SCHED --> EMBB
    SCHED --> URLLC
    SCHED --> MMTC

    style SCHED fill:#ff6b6b,stroke:#c0392b,color:#fff,stroke-width:3px
    style EMBB fill:#74b9ff,stroke:#0984e3
    style URLLC fill:#55efc4,stroke:#00b894
    style MMTC fill:#fdcb6e,stroke:#f39c12
```

不同切片的调度策略差异：

| 切片类型 | 调度策略 | 关键参数 |
|---------|---------|---------|
| **eMBB** | 比例公平+高MCS | 大带宽BWP、256QAM |
| **URLLC** | 最短时延优先+CG | Mini-slot、低码率高可靠MCS表 |
| **mMTC** | 最大复用+窄带宽 | 小带宽BWP、低聚合等级 |

---

## 常见问题

**Q1: 动态调度和半持续调度可以同时使用吗？**
A: 可以。同一UE的不同业务可以分别使用动态调度和SPS/CG。例如VoNR语音用SPS，数据业务用动态调度。它们使用不同的RNTI区分——动态调度用C-RNTI，SPS/CG用CS-RNTI。

**Q2: 调度器是每个Slot运行一次吗？**
A: 基本是的。以30kHz SCS为例，每0.5ms一个Slot，调度器理论上每0.5ms做一次调度决策。但实际实现中，基站可能提前若干Slot预计算调度方案（ lookahead调度），以应对处理时延。Mini-slot调度可以在Slot内更频繁地触发。

**Q3: 上行SR失败后为什么会触发随机接入？**
A: SR通过PUCCH专用资源发送，如果SR发送达到最大次数（sr-TransMax）仍无响应，说明PUCCH可能存在严重干扰或配置错误。此时UE需要通过随机接入重新获取上行同步和资源，这是兜底机制。

**Q4: 为什么5G引入了Configured Grant Type 1和Type 2两种？**
A: Type 1完全由RRC配置，适合周期性确定的业务（如工业控制每2ms发一次数据），UE拿到配置就能发，零授权时延；Type 2需要DCI激活/去激活，适合非周期但需要快速响应的场景（如突发URLLC），灵活性和效率的折中。

**Q5: 比例公平调度中历史平均吞吐量怎么更新？**
A: 使用指数加权移动平均：

$$\bar{R}_k(t+1) = \begin{cases} (1 - \frac{1}{t_c}) \cdot \bar{R}_k(t) + \frac{1}{t_c} \cdot R_k(t), & \text{if UE } k \text{ 被调度} \\ (1 - \frac{1}{t_c}) \cdot \bar{R}_k(t), & \text{if UE } k \text{ 未被调度} \end{cases}$$

其中 $t_c$ 是滤波窗口长度（典型值100~1000个TTI）。窗口越小响应越快但越不稳定，窗口越大越平滑但跟踪信道变化慢。这个参数是设备厂商的核心优化参数之一。

---

## 参考来源

1. [ShareTechnote - 5G NR Scheduling](https://www.sharetechnote.com/html/5G/5G_Scheduling.html) — 最全面的5G调度技术教程，含DCI格式和资源分配详解
2. [MathWorks - Overview of NR Scheduler](https://www.mathworks.com/help/5g/ug/overview-nr-scheduler.html) — MATLAB对5G NR调度器的系统性概述
3. [Demystifying the 5G Scheduler - Medium](https://medium.com/@heba3abdeen/demystifying-the-5g-scheduler-a-deep-dive-into-resource-allocation-in-5g-1157fc8abb0e) — 深入讲解资源分配Type 0/Type 1及调度器输入输出
4. [nxgconnect - 5G NR MAC DL/UL Scheduling Algorithms](https://www.nxgconnect.com/post/5g-nr-mac-dl-ul-scheduling-algorithms) — 上下行调度算法技术解析
5. [ShareTechnote - 5G Configured Scheduling](https://www.sharetechnote.com/html/5G/5G_ConfiguredScheduling.html) — SPS和Configured Grant Type 1/Type 2详解

---

> 本文由「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学通信知识星球海报-扫码加入](https://wiki.500nian.com/images/zhixingqiu_qrcode.png)