NR PDCCH盲检预算分配与CCE博弈：从搜索空间三层配置到控制信道容量极限

一、为什么PDCCH盲检是5G系统设计的第一道关卡

在5G NR系统中，物理下行控制信道（PDCCH）承载所有调度决策——上行授权、下行分配、时隙格式指示、功率控制命令等。与LTE PDCCH固定占据子帧前1-3个符号、全带宽映射不同，NR引入了CORESET + Search Space的二级解耦架构（TS 38.213 Section 10），实现了控制信道资源在时频域的灵活配置。

这种灵活性带来的代价是盲检复杂度的爆炸性增长：UE不知道gNB用哪个CCE聚合等级、哪个候选位置、哪种DCI格式发送了控制信息，必须在每个PDCCH监听时机（monitoring occasion）内遍历大量候选集。规范为此设定了盲检预算上限（BD budget）和CCE信道估计预算上限（CCE limit），形成UE能力与网络配置之间的硬约束博弈。

对运营商而言，PDCCH配置直接决定了： - 单小区最大可调度UE数（受CCE总数限制） - 边缘用户的控制信道覆盖（聚合等级选择） - 终端功耗（监听密度与盲检次数） - 控制信道阻塞概率（PDCCH blocking probability）

二、三层配置架构：CORESET→SearchSpace→DCI Format

2.1 第一层：CORESET（TS 38.211 Section 7.3.2.2）

CORESET定义PDCCH的物理资源容器，由RRC参数ControlResourceSet配置：

CCE总量计算：

N_CCE = (frequencyDomainResources中的RB组数 × 6) × duration / 6

例如：48个RB × 2符号 = 96个REG = 16个CCE。

graph TB
    subgraph CORESET["CORESET时频资源"]
        direction TB
        F1["频域: 45-bit bitmap → 最多275 RB"]
        T1["时域: 1~3 OFDM符号"]
        MAP["CCE-to-REG映射"]
    end

    subgraph CCE计算
        NREG["N_REG = N_RB × duration"]
        NCCE["N_CCE = N_REG / 6"]
    end

    subgraph 映射模式
        NI["Non-Interleaved<br/>L=6, 连续映射<br/>适用于波束赋形"]
        IL["Interleaved<br/>L=2/3/6, 块交织<br/>获取频率分集"]
    end

    CORESET --> NREG --> NCCE
    MAP --> NI
    MAP --> IL

    style CORESET fill:#e1f5fe
    style CCE计算 fill:#fff3e0
    style 映射模式 fill:#e8f5e9

交织映射的核心公式（TS 38.211 Section 7.3.2.2）：

交织器将REG bundle索引写入R×C矩阵（行写入），再按列读出并施加循环移位：

$$j = (r \cdot C + c + n_{shift}) \mod N_{bundle}$$

其中R为interleaverSize，C = ⌈N_bundle/R⌉，n_shift为shiftIndex。交织映射使同一PDCCH的REG分散在频域不同位置，获得频率分集增益，但增加了解码复杂度。

2.2 第二层：Search Space（TS 38.213 Section 10.1）

Search Space定义UE何时、何地、如何监听PDCCH，由RRC参数SearchSpace配置：

六种CSS类型及其用途：

2.3 第三层：DCI Format与RNTI

在同一个搜索空间中，UE需要对多种DCI格式×多个RNTI×多个候选位置进行交叉盲检。TS 38.213 Section 10.1规定了UE需监听的DCI size集合——UE通过RRC配置得知每种搜索空间关联的DCI格式，但实际使用的size可能因fallback而变化。

DCI size对齐规则（TS 38.212 Section 7.3.1）：规范限制UE需盲检的不同DCI size数量最多为4个（其中Cell-specific最多3个 + UL共同1个），这迫使网络在不同DCI format之间进行字段填充（padding）以对齐size，是调度器设计的重要约束。

三、盲检预算分配：UE能力的硬天花板

3.1 两种预算约束（TS 38.213 Table 10.1-2 / 10.1-3）

每个时隙内，UE的PDCCH盲检受两个预算约束：

表1：每时隙盲检上限（M_{BD,max}^{μ,slot}）

表2：每时隙CCE信道估计上限（C_{CCE,max}^{μ,slot}）

关键洞察：随着SCS增大（频段升高），预算反而减小。这意味着毫米波频段（120kHz SCS）的控制信道调度容量更紧张，运营商需要更精细地规划搜索空间配置。

3.2 预算分配优先级机制（TS 38.213 Section 10.1）

当UE配置了多个搜索空间集合时，预算按严格优先级分配：

优先级从高到低：
Type0-PDCCH CSS > Type0A-PDCCH CSS > Type1-PDCCH CSS > Type2-PDCCH CSS
> Type3-PDCCH CSS > USS（searchSpaceId小的优先）

分配算法流程：

flowchart TD
    A[开始预算分配] --> B[按优先级排序所有SS Set]
    B --> C[取下一个SS Set s]
    C --> D{s是CSS?}
    D -->|是| E[从总预算中扣除CSS需求]
    D -->|否| F{剩余预算是否充足?}
    F -->|充足| G[按配置分配全额候选数]
    F -->|不足| H[按比例缩减候选数]
    H --> I[最终分配 = min 配置值, 剩余预算/聚合等级]
    E --> C
    G --> C
    I --> C

    style A fill:#e1f5fe
    style H fill:#ffebee
    style G fill:#e8f5e9

这意味着：USS（承载用户专用调度）总是最后分配预算。当小区负载高、公共搜索空间配置多时，边缘用户的USS预算可能被大幅压缩，直接影响调度机会。

3.3 PDCCH候选位置的确定

对于USS，聚合等级L的第m个候选的CCE起始索引为（TS 38.213 Section 10.1）：

$$n_{CCE} = L \cdot \left{ \left( Y_{p,n_s} + \lfloor \frac{m \cdot N_{CCE,p}}{L \cdot M_{s,max}^{(L)}} \rfloor \right) \mod \lfloor N_{CCE,p}/L \rfloor \right}$$

其中： - Y_{p,n_s}：伪随机哈希值，每时隙变化（USS），CSS中Y=0 - N_{CCE,p}：CORESET p的CCE总数 - M_{s,max}^{(L)}：搜索空间s在聚合等级L的配置候选数 - m = 0, 1, ..., M_{s,max}^{(L)} - 1

Y值的随机化确保不同UE的候选位置错开，减少PDCCH碰撞概率。这就是为什么在相同CORESET中，两个UE不太可能持续碰撞——哈希值随slot index变化。

四、完整信令流程：从RRC配置到盲检执行

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

    Note over gNB: 1. 网络规划阶段
    SCH->>SCH: 计算CORESET容量<br/>N_CCE = RB×符号/6
    SCH->>SCH: 规划搜索空间周期<br/>平衡开销与延迟

    Note over gNB,UE: 2. RRC配置阶段
    gNB->>UE: RRC Reconfiguration<br/>PDCCH-Config{<br/>  ControlResourceSetToAddModList,<br/>  SearchSpacesToAddModList<br/>}

    Note over UE: 3. UE解析配置
    UE->>UE: 提取CORESET参数<br/>计算N_CCE
    UE->>UE: 提取SS参数<br/>确定监听时机
    UE->>UE: 计算盲检预算分配<br/>CSS优先 > USS

    loop 每个PDCCH监听时机
        Note over UE: 4. 盲检执行
        UE->>UE: 计算候选CCE位置<br/>(哈希函数)

        loop 每个SS×AL×候选
            UE->>UE: 信道估计<br/>Polar解码
            UE->>UE: CRC校验<br/>RNTI匹配
        end

        UE->>UE: 提取DCI内容<br/>解析调度信息

        opt 找到有效DCI
            UE->>UE: 按DCI执行<br/>PDSCH/PUSCH收发
        end
    end

    Note over SCH: 5. 调度器优化反馈
    SCH->>SCH: 监控PDCCH阻塞率
    SCH->>SCH: 动态调整AL/候选数

五、运营商CCE预算博弈：四个实战维度

5.1 维度一：CORESET大小与PDSCH资源竞争

CORESET占用的时频资源直接挤占PDSCH。以100MHz带宽、30kHz SCS为例：

运营商策略：中国电信/联通共建共享网络倾向于配置较大的CORESET（96RB×2符号），以支撑高用户密度；而偏远覆盖场景则用小CORESET（24RB×1符号），牺牲容量换取PDSCH吞吐。

5.2 维度二：搜索空间周期与调度延迟

eMBB场景通常配置周期1或2以保证低延迟；mMTC场景可配置周期10或20以延长终端待机。

5.3 维度三：聚合等级与覆盖博弈

实际部署策略： - 中心用户：AL=1~2，最大化CCE复用 - 中距用户：AL=4，兼顾覆盖与容量 - 边缘用户：AL=8~16，牺牲容量保证可靠性

5.4 维度四：PDCCH阻塞概率分析

当多个UE的PDCCH候选位置重叠时，发生CCE碰撞，导致PDCCH阻塞。阻塞概率近似为：

$$P_{block} \approx 1 - \left(1 - \frac{\sum_{i=1}^{K} L_i}{N_{CCE}}\right)^{K-1}$$

其中K为同时调度UE数，L_i为第i个UE的聚合等级。

graph LR
    subgraph 阻塞概率计算
        A["16 CCE CORESET<br/>48RB×2符号"] --> B["AL=4: 4候选/UE"]
        B --> C["K=3 UE → P_block≈38%"]

        A2["48 CCE CORESET<br/>96RB×2符号"] --> B2["AL=4: 12候选/UE"]
        B2 --> C2["K=10 UE → P_block≈45%"]
    end

    subgraph 优化手段
        D["交织映射 → 分散碰撞"]
        E["哈希随机化 → 均匀分布"]
        F["动态AL选择 → 按需分配"]
    end

    C --> D
    C --> E
    C2 --> F

    style 阻塞概率计算 fill:#e1f5fe
    style 优化手段 fill:#e8f5e9

关键数据（来源：IEEE Access论文"Blocking Probability Analysis for 5G NR PDCCH"）： - 48 CCE CORESET，AL=4，10 UE时阻塞率约45% - 增加CORESET到96 CCE可将阻塞率降至~15% - 使用交织映射比非交织降低~20%阻塞率

六、CORESET 0的特殊机制（TS 38.213 Section 10.1）

CORESET 0是UE接入网络后第一个搜索的CORESET，通过MIB中的pdcch-ConfigSIB1（4-bit）联合查表（Table 13-1至13-10）确定：

MIB → pdcch-ConfigSIB1 (4 bits)
  ├─ 高4位 (0~15) → CORESET 0 配置表索引
  │   → 决定: RB数量, 符号数, 偏移
  └─ 低4位 (0~15) → SearchSpace 0 配置表索引
      → 决定: 监听周期, 时隙偏移, 符号位置

CORESET 0的CCE数量直接决定了初始接入阶段的最大可调度UE数。在FR1（Sub-3GHz）典型配置下，CORESET 0提供24~96个RB，对应4~32个CCE。若SIB1采用AL=8，则仅能调度4个UE——这就是为什么初始接入阶段通常采用AL=4（8候选）而非AL=8（4候选）。

SSB与CORESET 0的复用模式（TS 38.213 Section 10.1）决定了Type0-PDCCH CSS的监听时机：

七、实战排错：抓包识别与常见故障

7.1 抓包识别PDCCH流程

在QXDM/Qualcomm日志中识别PDCCH配置的关键步骤：

1. 定位RRC Reconfiguration → 查找PDCCH-Config IE
2. 提取CORESET配置 → 计算N_CCE
3. 提取SearchSpace周期 → 确认监听时机
4. 查看PDCCH候选集分配 → 对比盲检预算上限
5. 分析PDCCH解调结果 → 检查CRC是否通过

7.2 常见故障模式

3GPP Release 18引入了多项PDCCH监听增强（TS 38.213 V18.x Section 10.1），主要方向：

1. Multi-slot PDCCH monitoring span（R17引入，R18增强）： - 允许将多个slot组成一个monitoring span - BD/CCE预算按span而非per-slot计算 - 显著降低稀疏监听场景的UE功耗

2. Search space set group switching： - 通过DCI format 2_0动态激活/去激活搜索空间集合组 - 非活跃期可关闭部分USS监听 - 典型增益：待机功耗降低20~30%

3. Enhanced PDCCH blind decoding for RedCap UE（R18）： - Reduced Capability UE使用更低的BD/CCE预算 - 降低终端基带复杂度要求

stateDiagram-v2
    [*] --> CSS_Monitoring: 初始接入
    CSS_Monitoring --> USS_Active: RRC Connected
    USS_Active --> USS_Active: 每slot监听<br/>周期=1~2

    USS_Active --> SSG_Switch: DCI 2_0触发
    SSG_Switch --> GroupA_Active: 高活动组<br/>完整监听
    SSG_Switch --> GroupB_Active: 低活动组<br/>缩减监听

    GroupA_Active --> SSG_Switch: DCI 2_0
    GroupB_Active --> SSG_Switch: DCI 2_0
    GroupB_Active --> DRX_Sleep: 进入DRX

    DRX_Sleep --> USS_Active: On Duration
    USS_Active --> [*]: RRC Release

常见问题

Q1: PDCCH盲检和PDSCH解调有什么关系？ A: PDCCH是"钥匙"，PDSCH是"房间"。UE必须先盲检PDCCH获取DCI，才能知道PDSCH在哪个时频资源、用哪个MCS。PDCCH解调失败意味着UE完全不知道有数据要接收。这就是为什么PDCCH的可靠性要求高于PDSCH——DCI漏检比数据漏检后果更严重。

Q2: 为什么CSS只支持AL={4,8,16}而USS支持AL={1,2,4,8,16}？ A: CSS承载系统级控制信息（SI、寻呼、RAR），这些信息需要高可靠性发送，因此限制了低聚合等级。USS承载用户专用调度，中心用户信道条件好，可以用AL=1节省CCE资源，最大化系统调度容量。

Q3: CORESET 0为什么不能配置太大？ A: CORESET 0由MIB中4-bit索引决定（Table 13-1~13-10），取值受限。更重要的是，CORESET 0与SSB共享时频资源，过大CORESET 0会减少SSB发送机会，影响小区覆盖和初始接入成功率。这是一个覆盖与容量的经典博弈。

Q4: 如何判断现网PDCCH是否成为瓶颈？ A: 三个关键指标：(1) PDCCH CCE利用率持续超过80%；(2) 调度请求（SR）被拒绝率上升；(3) 下行BLER正常但吞吐量偏低（可能DCI漏检导致PDSCH未解码）。通过网管PM计数器pmPdcchCceUsage和pmDciMissedRate可以量化。

Q5: 交织映射和非交织映射如何选择？ A: 宏站覆盖场景优先选择交织映射——频率分集增益在高干扰环境下价值更大。室分或mmWave波束赋形场景优先选择非交织映射——信道质量稳定，连续映射有利于预编码增益，且降低UE解码复杂度。

参考来源

1. 3GPP TS 38.213 V18.5.0 — Section 10: PDCCH monitoring procedures, blind decoding budget tables
2. 3GPP TS 38.211 V18.5.0 — Section 7.3.2.2: CCE-to-REG mapping
3. 3GPP TS 38.331 V18.5.0 — SearchSpace IE, ControlResourceSet IE, PDCCH-Config IE
4. Blocking Probability Analysis for 5G NR PDCCH — IEEE Access, PDCCH阻塞概率建模与仿真
5. 5G NR PDCCH资源容量优化探讨 — 邮电设计技术2023年3月，运营商视角的CCE容量规划
6. 5G NR PDCCH: Design and Performance — IEEE会议论文，PDCCH物理层设计分析

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