<!-- title: 5G搜索空间：控制信道的寻宝地图 -->

# 5G搜索空间：控制信道的寻宝地图

## 一个类比：藏在格子里的信封

想象一座巨大的图书馆，里面有成千上万个格子。管理员每天往某些格子里放入信封——有的信封写着"你的快递到了"（下行调度），有的写着"你可以发货了"（上行授权）。问题是：你不知道信封放在哪个格子，也不知道信封有多大。

你唯一的策略是：**按照一张事先约定的"寻宝地图"，逐一打开可能的位置，检查有没有属于自己的信封。**

这就是5G NR中PDCCH（物理下行控制信道）搜索空间与盲检的核心逻辑。手机（UE）每时每刻都在做这件事——在基站划定的一片时频区域内，按照预定义的规则，逐个尝试解码控制信令，直到找到属于自己的调度指令。

## 为什么5G需要"搜索"控制信道？

在4G LTE中，控制信道占据了整个系统带宽的前1~3个OFDM符号，位置固定、结构简单。UE只需要在这一小块区域里找就行。

5G NR的设计哲学完全不同——**控制信道不再固定在某个位置，而是可以在频带上灵活放置**。这个改变带来了三大好处：

| 对比维度 | 4G LTE PDCCH | 5G NR PDCCH |
|:---:|:---:|:---:|
| 频域位置 | 占满整个系统带宽 | 只占用配置的频域区域（CORESET） |
| 时域长度 | 固定1~3个符号 | 灵活配置1~3个符号 |
| 控制区域大小 | 随系统带宽线性增长 | 与业务量匹配，按需分配 |
| 支持BWP | 不支持 | 每个BWP独立配置 |

灵活的代价是：**UE不知道基站把控制信息放在了哪里，必须自己去找。**

这就是搜索空间（Search Space）存在的意义——它是一份"寻宝地图"，告诉UE在什么时间、什么频率范围、用什么大小的"信封"去寻找控制信息。

## 三层架构：CORESET → CCE → 搜索空间

5G控制信道的资源组织分为三层，理解这个层级关系是一切的基础：

```mermaid
graph TB
    subgraph "第一层：CORESET（控制资源集合）"
        A["频域：最多6×18=108个PRB<br/>时域：1~3个OFDM符号"]
    end
    subgraph "第二层：CCE（控制信道元素）"
        B["1 CCE = 6 REG<br/>1 REG = 1 PRB × 1 符号 = 12 RE"]
    end
    subgraph "第三层：搜索空间（Search Space）"
        C["定义监听时机<br/>定义每个聚合等级的候选数"]
    end
    A -->|"包含若干CCE"| B
    B -->|"组成PDCCH候选"| C

    style A fill:#e1f5fe
    style B fill:#fff3e0
    style C fill:#e8f5e9
```

### 第一层：CORESET——寻宝的岛屿

CORESET（Control Resource Set，控制资源集合）是5G NR控制信道在时频域上的"地盘"。你可以把它理解为一个**长方形的时频资源块**：

- **频域维度**：以6个PRB（物理资源块）为最小粒度，用一段位图（bitmap）来指示哪些6-PRB块被占用。频域最大跨度为6×18=108个PRB。
- **时域维度**：持续1、2或3个OFDM符号，由参数`duration`配置。

一个关键特性：**每个BWP（带宽部分）最多只能配置3个CORESET**。这个限制保证了UE的处理复杂度可控。

> **为什么是3个？** 因为5G NR需要在不同场景下使用不同的CORESET——比如初始接入用CORESET#0（由MIB配置），连接态用UE专用的CORESET，某些公共消息用第三个CORESET。3个刚好覆盖主要需求。

### 第二层：CCE与REG——地图的网格

CORESET被进一步划分为更小的单元：

$$1 \text{ REG} = 1 \text{ PRB} \times 1 \text{ OFDM符号} = 12 \text{ 个RE（每层）}$$

$$1 \text{ CCE} = 6 \text{ 个REG}$$

也就是说，一个CCE包含 $6 \times 12 = 72$ 个RE。这是PDCCH资源分配的基本单位。

一个CORESET里有多少个CCE，取决于CORESET的大小：

$$N_{\text{CCE}} = \frac{N_{\text{RB}}^{\text{CORESET}} \times N_{\text{symb}}^{\text{CORESET}}}{6}$$

例如，一个频域占48个PRB、时域占2个符号的CORESET，共有 $48 \times 2 / 6 = 16$ 个CCE。

### 第三层：搜索空间——寻宝路线图

搜索空间定义了UE在CORESET中**如何寻找PDCCH**。它包含三个关键信息：

1. **什么时候找**（监听时机：周期、偏移、持续时隙数）
2. **在哪个CORESET找**（关联的CORESET ID）
3. **找多大的信封**（每个聚合等级的候选PDCCH数量）

## 聚合等级：信封有五种尺寸

基站发送一条DCI（下行控制信息）时，需要根据信道质量选择合适的"信封大小"——也就是**聚合等级（Aggregation Level，AL）**：

| 聚合等级 | CCE数量 | 总RE数 | 适用场景 |
|:---:|:---:|:---:|:---|
| AL=1 | 1 CCE | 72 RE | 信道极好、DCI负载小 |
| AL=2 | 2 CCE | 144 RE | 信道良好 |
| AL=4 | 4 CCE | 288 RE | 信道一般（最常用） |
| AL=8 | 8 CCE | 576 RE | 信道较差或DCI负载大 |
| AL=16 | 16 CCE | 1152 RE | 信道很差（增强覆盖） |

**设计哲学**：聚合等级越高，编码冗余越多，抗干扰能力越强，但消耗的时频资源也越多。这就像写信——信号好时用简洁的电报就够了，信号差时就得用大字报反复抄写。

> **实战提示**：现网中AL=4是最常见的配置。如果你在路测软件中看到UE频繁使用AL=8或AL=16，说明该区域覆盖或干扰状况不佳，需要重点关注。

## 搜索空间的六种类型

5G NR定义了多种搜索空间类型，每种服务于不同的控制信令需求：

```mermaid
graph LR
    subgraph "公共搜索空间 CSS"
        T0["Type 0<br/>SI-RNTI<br/>系统信息"]
        T0A["Type 0A<br/>SI-RNTI<br/>其他系统消息"]
        T1["Type 1<br/>RA-RNTI<br/>随机接入响应"]
        T2["Type 2<br/>P-RNTI<br/>寻呼消息"]
        T3["Type 3<br/>INT-RNTI等<br/>组信令/时隙格式"]
    end
    subgraph "UE专用搜索空间 USS"
        USS["DCI 0_0/0_1<br/>DCI 1_0/1_1<br/>UE专用调度"]
    end

    T0 --- |"MIB/SIB1配置"| CORESET0["CORESET #0"]
    T0A --- |"SIB1配置"| CORESET0
    T1 --- |"SIB1配置"| CORESET0
    T2 --- |"SIB1配置"| CORESET0
    T3 --- |"RRC配置"| CORESETx["任意CORESET"]
    USS --- |"RRC配置"| CORESETx

    style T0 fill:#bbdefb
    style T0A fill:#bbdefb
    style T1 fill:#c8e6c9
    style T2 fill:#fff9c4
    style T3 fill:#ffe0b2
    style USS fill:#f8bbd0
```

### Type 0：开机的第一步

手机开机后首先要找的就是Type 0搜索空间。它用于接收SIB1（最小系统信息），通过MIB中的参数配置CORESET#0和搜索空间#0。**这是整个5G控制面流程的起点。**

### Type 1：敲门后的回应

手机发送随机接入前导码后，在Type 1搜索空间中等待基站的随机接入响应（RAR）。使用RA-RNTI加扰。

### Type 2：被呼叫的入口

当核心网需要寻呼UE时，基站在Type 2搜索空间中发送寻呼消息的调度信息。使用P-RNTI加扰。

### Type 3：公共事务通知

Type 3搜索空间承载组信令通知、时隙格式切换指示等公共控制信息。它可以使用任意CORESET，不限于CORESET#0。

### UE专用搜索空间（USS）：个人的调度信箱

进入连接态后，UE最主要使用的就是USS。基站为每个UE单独配置，用于承载该UE的上下行调度授权（DCI Format 0_1/1_1等），使用C-RNTI加扰。

## 盲检流程：一步步寻找属于自己的信封

理解了CORESET、CCE和搜索空间，现在来看UE真正"寻宝"的过程：

```mermaid
flowchart TD
    A["UE收到时隙边界"] --> B{"当前时隙是否为<br/>监听时机？"}
    B -->|否| A
    B -->|是| C["确定关联的CORESET<br/>获取CCE总数N_CCE"]
    C --> D["遍历每个聚合等级<br/>AL = 1, 2, 4, 8, 16"]
    D --> E["根据哈希公式计算<br/>该AL下的PDCCH候选位置"]
    E --> F["对每个候选位置：<br/>① 解交织（如需）<br/>② 用RNTI解扰<br/>③ Polar码解码<br/>④ CRC校验"]
    F --> G{"CRC校验通过？"}
    G -->|是| H["✓ 成功获取DCI<br/>解析调度信息"]
    G -->|否| I{"还有未检查的<br/>候选位置？"}
    I -->|是| F
    I -->|否| D
    D -->|"所有AL遍历完"| J["本时隙监听结束<br/>等待下一个监听时机"]

    style A fill:#e3f2fd
    style H fill:#c8e6c9
    style J fill:#fff3e0
```

### 步骤详解

**第1步：判断监听时机**

UE根据搜索空间配置的`monitoringSlotPeriodicityAndOffset`（监听周期和偏移）判断当前时隙是否需要监听PDCCH。如果不需要，直接跳过，节省电量。

例如，周期=4、偏移=1，表示每4个时隙中的第2个时隙需要监听。

**第2步：计算候选PDCCH位置**

这是最核心的数学步骤。对于聚合等级 $L$，第 $m$ 个PDCCH候选的起始CCE索引由以下公式决定：

$$n_{\text{CCE}} = L \cdot \left\lfloor \frac{Y_k + m \cdot \lfloor N_{\text{CCE}} / L \rfloor}{M_{L}^{\max}} \right\rfloor \mod \lfloor N_{\text{CCE}} / L \rfloor$$

其中：
- $Y_k$：UE特定参数，CSS中为0，USS中由C-RNTI和时隙号推导（这就是"跳频"效果，让不同UE的候选位置错开）
- $m$：候选编号，从0到 $M_{L}^{\max} - 1$
- $N_{\text{CCE}}$：CORESET中的CCE总数
- $M_{L}^{\max}$：该聚合等级下的候选数

> **为什么要有 $Y_k$？** 如果所有UE的候选位置都从相同的CCE开始，多UE时会严重碰撞。$Y_k$ 基于C-RNTI计算，让每个UE的"寻宝路线"不同，大幅降低冲突概率。

**第3步：尝试解码**

对于每个候选位置，UE用预期的RNTI（如C-RNTI、SI-RNTI等）尝试解扰和解码。如果CRC校验通过，说明这个候选位置确实有属于自己的DCI。

## 盲检次数限制：不能让UE太累

盲检是一个计算密集的过程。如果让UE在每个时隙都无限制地搜索，电池很快就会耗尽。因此协议严格规定了盲检上限：

| 子载波间隔 | 每时隙最大盲检次数 | 每时隙最大CCE数 |
|:---:|:---:|:---:|
| 15 kHz | 44 | 56 |
| 30 kHz | 36 | 56 |
| 60 kHz | 24 | 48 |
| 120 kHz | 16 | 32 |

> **为什么子载波间隔越大，限制越严？** 因为SCS越大，一个子帧内的时隙越多。如果每个时隙都允许很多次盲检，总处理量会翻倍。协议通过降低单时隙限制来控制总负荷。

当网络为UE配置了多个搜索空间时，各搜索空间的候选数之和不能超过上述限制。如果超了，UE会按照优先级规则丢弃部分低优先级的候选。

## CCE-to-REG映射：交织 vs 非交织

找到了PDCCH候选的CCE位置后，还需要知道CCE内部如何映射到实际的时频资源（REG）。这里有两种映射方式：

**非交织映射**：CCE内的6个REG在频域上连续排列。实现简单，波束赋形增益集中，但如果遇到窄带干扰，所有REG都会受影响。

**交织映射**：通过一个交织器将REG打散到更宽的频带上。利用频率分集增益抵抗窄带干扰，但实现更复杂。

$$\text{交织深度} = L_{\text{interleaver}} \in \{2, 3, 6\}$$

| 映射方式 | 优势 | 劣势 | 典型场景 |
|:---:|:---:|:---:|:---:|
| 非交织 | 波束赋形增益集中 | 频率分集差 | 波束赋形场景（mmWave） |
| 交织 | 频率分集抗干扰 | 实现复杂 | 公共搜索空间、Sub-6G |

> **设计哲学**：公共控制信息（CSS）面向所有UE，不能假设UE有专用波束，因此多用交织映射获取分集增益。UE专用搜索空间（USS）在mmWave场景下可以配合波束赋形使用非交织映射，获得更高的波束增益。

## 实战连接：工程师调试指南

### 1. 路测中看什么？

在路测工具（如TEMS、鼎利等）中，关注以下指标：
- **PDCCH BLER**：盲检成功率。正常应该>95%，如果低于90%说明控制信道质量差。
- **聚合等级分布**：如果AL=8/16占比过高，说明覆盖不足或干扰严重。
- **CCE利用率**：反映小区控制信道资源是否紧张。

### 2. 常见调优参数

| 参数 | 含义 | 调优建议 |
|:---:|:---:|:---|
| CORESET频域大小 | 控制区域占多少PRB | 用户多时适当增大，避免CCE拥塞 |
| 搜索空间周期 | 多少时隙监听一次 | 周期大=省电但延迟高；周期小=响应快但功耗高 |
| 每AL候选数 | 每种信封大小的候选数量 | 候选多=命中率提高，但盲检负担加重 |
| duration | CORESET时域符号数 | 1个符号效率高，3个符号容量大 |

### 3. 常见调试陷阱

**陷阱一：混淆CORESET和搜索空间。** CORESET定义"在哪儿找"，搜索空间定义"怎么找"。两者是独立的配置对象，通过`controlResourceSetId`关联。

**陷阱二：忽略盲检限制。** 配置搜索空间时，所有搜索空间的候选数之和不能超过盲检上限。超出后UE会丢弃部分候选，导致漏检。

**陷阱三：认为CSS只用于空闲态。** 实际上Type 3 CSS在连接态也会使用，用于接收时隙格式指示、中断通知等组信令。

## 与4G LTE的对比：灵活性的代价

| 维度 | 4G LTE | 5G NR |
|:---:|:---:|:---:|
| 控制区域 | 固定在前N个符号，占满全带宽 | CORESET灵活配置位置和大小 |
| CCE映射 | 唯一的交织方式 | 交织/非交织可选 |
| 搜索空间类型 | 公共+UE专用（2种） | Type0/0A/1/2/3 + USS（6种） |
| 最大盲检次数/子帧 | 44次（固定） | 按SCS动态调整 |
| 波束赋形支持 | 有限 | 完整支持（非交织映射+TCI状态） |

5G的设计用更高的配置复杂度换取了灵活性和前向兼容性。LTE的控制信道设计像一张固定时刻表——简单但死板；NR的设计像出租车调度——灵活但需要更智能的匹配机制。

## 常见问题

**Q：搜索空间和CORESET是什么关系？谁包含谁？**

A：它们是独立的配置对象，通过ID关联。CORESET定义"在哪个时频区域找"（搜索范围），搜索空间定义"什么时间找、找多少个、找多大的"（搜索策略）。一个CORESET可以被多个搜索空间关联，一个搜索空间只关联一个CORESET。

**Q：UE在空闲态和连接态分别监听哪些搜索空间？**

A：空闲态主要监听Type 0（系统信息）、Type 1（随机接入响应）和Type 2（寻呼）。连接态主要监听USS（个人调度）和Type 3（组信令通知）。连接态下UE仍需要监听与随机接入相关的搜索空间（用于切换等场景）。

**Q：为什么公共搜索空间用交织映射，而UE专用可以用非交织？**

A：公共搜索空间面向所有UE，不能假设每个UE都有专属波束，因此需要通过交织获得频率分集来提高可靠性。UE专用搜索空间在mmWave场景下可以配合波束赋形使用非交织映射，把CCE集中在一个波束方向上，获得更高的波束赋形增益。

**Q：聚合等级由谁决定？UE还是基站？**

A：由基站决定。基站根据对UE信道质量的估计（CQI报告等）选择合适的聚合等级。信道好时用低AL节省资源，信道差时用高AL增强可靠性。UE在盲检时需要覆盖所有可能的AL。

**Q：盲检会不会导致UE功耗过高？**

A：协议通过三层机制控制功耗：（1）搜索空间周期配置，UE不需要每个时隙都监听；（2）DRX机制，在非激活时段关闭接收机；（3）盲检次数上限，限制单时隙的处理量。实际网络中，连接态UE的PDCCH监听功耗约占总功耗的10%~15%。

## 参考来源

1. [3GLTEInfo - 5G NR PDCCH Reference](https://www.3glteinfo.com/5g/protocols/phy/pdcch/) — 完整的PDCCH协议参数参考
2. [ShareTechnote - 5G Search Space](https://www.sharetechnote.com/html/5G/5G_SearchSpace.html) — 搜索空间类型详解与示例
3. [MathWorks - Downlink Control Processing](https://www.mathworks.com/help/5g/ug/downlink-control-processing-and-procedures.html) — 盲检仿真教程与公式推导
4. [sqimway - PDCCH CCE Index](https://www.sqimway.com/nr_cce.php) — CCE索引计算可视化工具
5. [RF Wireless World - 5G NR Search Space Types](https://www.rfwireless-world.com/articles/5g-nr-ue-search-space-types) — Type0/0A/1/2/3分类对比

---
> 本文由「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)