[4G&5G专题-38]：物理层-下行公共控制信道PDCCH与其承载的内容下行控制信息格式DCI

目录

第1章 下行公共控制信道PDCCH简介

1.1 下行公共控制信道PDCCH概述

1.2 下行公共控制信道PDCCH在物理层信道中的位置

1.3 下行公共控制信道PDCCH与下行广播信道PBCH的区别

第2章 下行控制信息格式DCI

2.1 DCI的作用

2.2 DCI与MIB, SIB的比较

2.3 DCI的种类

2.4 DCI1_0控制的内容

第3章 LTE下行控制信道的时频资源

3.1  下行控制信道在LTE时频资源矩阵中的位置

3.2 LTE中物理控制信道的资源分配单元

第4章 5G NR下行公共控制信道PDCCH

4.1 PDCCH时频资源的大小与组成

4.2 PDCCH时频资源与CORESET

4.3 搜索空间Search Space

4.4 CORESET与Search Space比较

4.5 PDCCH信道的类型

第5章 PDCCH编码过程

---

第1章 下行公共控制信道PDCCH简介

1.1 下行公共控制信道PDCCH概述

PDCCH： Physical Downlink Common Control Channel， 下行公共控制信道

物理层公共控制信道主要肩负了物理层控制消息的交互传输，是基站与终端高效交互控制信息的重要手段。

5G NR的公共物理控制信道分为两大类：上行与下行。

在上行公共物理控制方面，NR和LTE系统中一样，只有PUCCH（Physical Uplink Control Channel）信道。

在下行公共物理控制方面，NR与LTE相比，得以大大简化，只保留了下行公共控制信道PDCCH（Physical Downlink Control Channel）信道，其他控制信道，如PHICH, PCFICH并没有保留下来。

这里有一个关键词：“公共”，其英文为public或common，在通信领域，为“common”。

“公共 ”是相对于“私有”而言的，其英文为private或dedicated，在通信领域，为“dedicated”。

公共控制到是指对小区中的所有终端进行控制，而“专有”控制信道是指对特定的单一终端进行控制。

 

1.2 下行公共控制信道PDCCH在物理层信道中的位置

下行公共控制信道PDCCH是用来承载DCI信息。

上行公共控制信道PUCCH是用来承载UCI信息。

下行公共控制信道的内容，来源于基站MAC层的DCI ( Downlink Control Information）, 下行控制信息指示。

终端只有正确的解码到了DCI信息，才能正确的接收PDSCH中的数据或发送PUSCH中的数据。

因此了解DCI有助于理解PDCCH信道中的控制信息。

PDCCH信道也包含解调参考信号（DMRS），DMRS信号将在后续的章节中单独探讨，本文的重点在DCI和PDCCH信道本身。

 

1.3 下行公共控制信道PDCCH与下行广播信道PBCH的区别

（1）相同点

• 都是用于基站给终端发送信号、消息，
• 都是下行
• 信道为所有终端共享

（2）不同点：体现在广播和控制的区别上

• 下行控制信道PDCCH用于控制，下行广播信道PBCH用于广播小区信息。
• 控制信道：必须有终端实体的存在，基站才会发送下行控制信道的消息；广播信道：不管是否有终端实体存在，基站都会广播消息。
• 控制信道：体现在实时性。广播信道：体现在广而告之性。

 

第2章 下行控制信息格式DCI

2.1 DCI的作用

物理帧结构是时域 (Time Domain)、频域(Frequency Domain)和调制方式（modulation scheme）等各种信息的组合，且完全有基站控制。

这里可能会有疑问：”接收方终端怎么知道发送方基站，在什么时隙slot、在哪些子载波上？以什么调制方式发送了用户数据的呢？

也就是说接收方终端，即使捕获到了OFDM符号，那怎么解码呢？

这时候就用到了，通过PDCCH承载的 DCI (Downlink Control information Indicator)。

DCI的作用是：用于基站，通过空口，对各种各种终端进行远程调度。

2.2 DCI与MIB, SIB的比较

以LTE为例，介绍DCI与MIB, SIB区别。

（1）MIB： Master information block, 通过PBCH物理信道承载。

• 10ms系统帧号
• 5ms的系统半帧号
• 波束赋形中波束的标识
• SIB的位置索引

 

（2）SIB：System information block，通过PDSCH物理信道承载。

SIB类型有很多种，SIB具体包括SIB1、SIB2、SIB3、SIB4、SIB5、SIB6、SIB7、SIB8、SIB9、SIB10、SIB11、SIB12、SIB13等。

涉及到与物理小区相关的几乎所有信息。

 

（3）DCI：Downlink Control information Indicator，通过PDCCH物理信道承载。

DCI与RRC层无关,主要作用仅仅在物理层, 它关注的是：如何通过10ms的系统帧的时频资源，为终端和基站的RRC层传输控制信息和业务信息 ，因此它解决是，如何让终端知道10ms帧的传输模式问题。

如何让终端知道自身专有的控制信道所需要的时频资源在哪里的问题。

 

2.3 DCI的种类

根据其控制信息的不同，把DCI分成不同的种类，比如，有针对下行RB资源进行分配的DCI，有针对上行RB资源进行分配的DCI，有针对上行功率控制进行调整的DCI，有特别针对下行双流空分复用的DCI。

协议对这些DCI进行了分类，用不同的DCI格式进行区分， 不同的DCI格式，其内容是不相同的。

在R15 38.212中，将DCI分类以下8种格式：

R16版本中，将DCI类型扩充至15种格式，具体如下表：

其中：

• DCI 0_0和DCI 0_1主要负责上行PUSCH的调度
• DCI 1_0和1_1主要负责下行PDSCH的调度
• DCI 2_0负责向一个组的UE通知slot格式
• DCI 2_1负责向一个组的UE通知不可用的PRB和OFDM符号
• DCI 2_2负责PUCCH和PUSCH信道的发射功率控制（Transmit Power Control，TPC）指令传输。
• DCI 2_3负责一个或者多个UE的一组SRS的TPC指令

 

下面以DCI 1_0为例，剖解DCI的内容

 

2.4 DCI1_0控制的内容

 DCI 1_0主要负责接入时的PDSCH调度，诸如SIB1、OSI、Msg2、Msg4等业务。

（1）DCI formats指示

此字段指示DCI信息为上行还是下行调度信息，占用1bit，0表示上行，1表示下行，因此对于DCI 1-0来说固定为1。

（2）PDSCH的频域资源指示
此字段指示PDSCH的频域资源，占用的比特数由下式确定

其中N_DL_BWP_RB为当前激活BWP的RB数，针对DCI 1-0，频域资源调度方式只能为type1（连续RB调度），因此，可根据PDSCH占用的rb_start和rb_num来计算RIV值，并将RIV值映射至此字段。

具体RIV值的计算可参见博文PDSCH频域资源调度

（3）时域资源指示
此字段指示PDSCH的时域资源，占用4bit，表示时域资源表格SLIV值的查表索引。

具体SLIV值的计算以及查表方法参见博文PDSCH时域资源调度

（4）VRB到PRB的映射指示
此字段指示PDSCH从VRB到PRB的映射方式，占用1bit，值0表示非交织，1表示交织

 

（5）调制和编码方式指示
此字段指示PDSCH的调制和编码方式，占用5bit，表示PDSCH不同调制方式、目标码率和频谱效率的查表索引。具体参见协议38.214.5.1，相关内容也会在后续博文中介绍。

（6）新数据指示
 此字段占用1bit，表示当前传输为新传数据还是重传数据

（7）冗余版本
 此字段指示冗余版本，占用2bit，值表示具体的含义由下表决定

（8）HARQ进程号指示，占用4bit

（9）下行链路分配指示
 此字段占用2bit，表示UE在HARQ反馈窗口内有多少个子帧包含下行传输，具体可详见协议38.213.9.1.3

（10）调度PUCCH的TPC指示
此字段表示PUCCH的发端功率控制指示，具体指示的值如下表所示，具体可参见协议38.213.7.2.1

（11）PDSCH到HARQ的反馈定时指示器

此字段用于反馈PDSCH应答定时的指示信息。
 

第3章 LTE下行控制信道的时频资源

3.1  下行控制信道在LTE时频资源矩阵中的位置

LTE下行控制信道包括：

• 物理控制格式指示信道（PCFICH：Physical Control Format Indication Channel），通过PCFICH，可以指示PDCCH的格式。
• 物理HARQ（混合自动重传）指示信道（PHICH：Physical HARQ Indication Channel）
• 物理下行控制信道（PDCCH：Physical Downlink Control Channel）。

上述3个信道共同完成下行物理信道的控制。

 

LTE物理下行控制信道与共享信道在一个子帧中通过时分复用，如上图所示:

• 横轴是时间，为一个子帧，分为两个时隙，每个时隙7个OFDM符号，总计14个符号，
• 纵轴是频率， 控制信道的频域：带宽为1.4MHz，6个RB。
• 控制信道的时域：符号0和符号1用于LTE下行控制信道，其他符号用于下行共享信道的传输。

 

3.2 LTE中物理控制信道的资源分配单元

由于PDCCH的传输带宽内可以同时包含多个PDCCH，为了更有效地配置 PDCCH和其他下行控制信道的时频资源，LTE定义了两个专用的控制信道资源单位：（1）RE组(RE Group，REG)和（2）控制信道单元(Control Channel Element，CCE)。

（1）RE (Resource Element)

1个频域子载波，一个时域符号时长。

（2）RB（Resource Block）

12个频域子载波，一个时域符号时长。

（3）REG (RE Group)

若干个RE组成一个REG。

1个REG由位于同一OFDM符号上的4个或6个相邻的RE组成，但其中可用的RE数目只有4个，6个RE组成的REG中包含了两个参考信号，而参考信号RS所占用的RE是不能被控制信道的REG使用的。

协议（36.211）中还特别规定，对于只有一个小区专用参考信号的情况，从REG中RE映射的角度，要假定存在两个天线端口，所以存在一个REG中包含4个或6个RE两种情况。

定义REG这样的资源单位，主要是为了有效地支持 PCFICH、PHICH等数据率很小的控制信道的资源分配，也就是说，PCFICH，PHICH的资源分配是以REG为单位的；而不是RB为单位。

（4）CCE(Control Channel Element)

一个CCE由9个REG构成。

而定义相对较大的CCE，是为了用于数据量相对较大的PDCCH的资源分配。PDCCH DCI在一个或多个连续的CCE上传输，也就是说PDCCH 的资源分配是以CCE为单位的；而不是RB为单位

 LTE中支持4种不同类型的PDCCH信道类型，不同的类型，占用的CCE的个数不同。

PDCCH format	Number of CCEs	Number of resource-element groups （REG）	Number of bits for PDCCH
0	1	9	72
1	2	18	144
2	4	36	288
3	8	72	576

在LTE中，PDCCH的频域和时域位置是固定的。

 

第4章 5G NR下行公共控制信道PDCCH

4.1 PDCCH时频资源的大小与组成

1 REG = 1 OFDM symbol * 12 subcarrier = 12 RE = 1 RB.

1 CCE = 6 REG = 72 RE.

对于一个PDCCH而言，其由一个或多个CCEs组成，而所分配的CCE数量根据聚合等级的不同而不同。

Supported PDCCH aggregation levels.

4.2 PDCCH时频资源与CORESET

在5G中取消了4G中指示PDCCH格式的物理控制格式指示信道（PCFICH：Physical Control Format Indication Channel），同时也取消了物理HARQ（混合自动重传）指示信道（PHICH：Physical HARQ Indication Channel）。

只留下了PDCCH信道，没有了PCFICH，就需要新的方式来组织PDCCH的时频资源. 5G NR中引入了CORESET的概念。

CORESET(Control/CO Resource/RE Set)是控制资源的集合.

 

CORESET是一组物理资源的集合，包括NR下行链路资源网格上的特定区域和一组用于携带PDCCH/DCI的参数。

它相当于LTE的PDCCH区域（子帧中的第1、2、3、4 OFDM符号）。但在LTE-PDCCH区域，PDCCH总是在整个信道带宽上传播，而NR的CORESET区域则局限于频域的特定区域。如下图所示：

CBW: 小区带宽，Cell Bandwidth

BWP: 部分带宽，Partial Bandwidth

在5G NR中：

一个REG由一个RB（12个频域RE）和一个时域OFDM符号组成。

一个REG Bundles由多个REG组成，

一个CCE由多个REGs组成，CCE中的REG bundle数量是不同的。

聚合级别，指示（Aggregation Level ）了为PDCCH分配了多少CCE, 如下图所示：

CORESET由频域中的多个RB（即12 REs的倍数）和时域中的“1或2或3”OFDM符号组成。

如下的参数确定了一个CORESET中包含的时域和频域的资源数。

普通的CORESET，这些CORESET由RRC配置.

但有一种特殊类型的CORESET称为CORESET0，此CORESET是用于SIB1的调度，它并不是有RRC层配置的。

 

CoreSet的3种样例：

4.3 搜索空间Search Space

5G NR系统中，由于系统的带宽较大，以及终端大带宽解调能力的差异性，为了提高资源利用率，降低盲检复杂度，PDCCH不再像LTE一样占据整个频域带宽；而是只占用一部分频域带宽，称为BWP，每个BWP都有自己独立的PDCCH信道。

此外，为了增加系统灵活性，适配不同的场景，PDCCH在时域的起始位置也可配。

因此，在5G NR中，UE需要预先完全获取或所搜到PDCCH的时域和频域的资源配置信息，才能够进一步对PDCCH信道的内容进行解调。

目前协议设计方案是：

将PDCCH的频域资源信息和时域占用的OFDM符号数等信息封装在CORESET中，

将PDCCH起始OFDM符号以及监听周期、关联的CORESET等信息封装在搜索空间中。

5G NR中的搜索空间分为两种类型：

• 公共搜索空间（CSS，Common Search Space），CSS主要是在接入时和小区切换时使用。
• UE特定搜索空间（USS，UE Specific Search Space），USS则是在接入后使用。

 

4.4 CORESET与Search Space比较

（1）CORESET

CORESET是5G NR新引入的一个概念。

CORESET（control-resource set）是控制信息的时域和频域资源的集合，包含物理资源（Resource Grid）的集合，还包括一些参数集合（比如DCI）。

在频域上，CORESET的参考点是BWP，而LTE的控制区域在频域上是整个信道（CBW）；

在时域上，LTE由PCFICH控制，而NR由RRC参数ControlResourceSet.duration控制。

最大有3个时域OFDM符号放在一个CORESET中：正在上传…重新上传取消

5G NR系统将PDCCH频域上占据的频段&时域上占用的OFDM符号数等信息封装在CORESET中；

 

（2）Search Space

搜索空间是LTE就有的概念，5G NR沿用了此概念。

5G NR系统将PDCCH 起始OFDM符号编号以及PDCCH监测周期等信息封装在Search Space中。

可以认为，搜索空间（Search Space）是CORESET的一个区域，通过搜索空间包含的信息，就可以获得CORESET中包含的信息。

有两大类搜索空间，分别为CSS（Common Search Space）和USS（UE specific Search Space）。

 

即通过SearchSpce，确定CORESET；通过CORESET，确定出PDCCH可能所在的位置以及其包含的DCI信息，如下图所示：

PDCCH主要用来承载上行调度信息和下行调度信息。承载在PDCCH上的控制信息称为DCI（Downlink control information）。

由于DCI的功能较多，为么方便区分，协议把DCI分了不同的类型。

 

注意：一个CORESET和一个SearchSpace组合起来后才能确定PDCCH的配置。

一个CORESET可以和多个SearchSpace绑定。

但一个SearchSpace却只能和一个CORESET绑定。

 

4.5 PDCCH信道的类型

Common PDCCH： 下行公共控制信道，处于初始的BWP空间，通过MIB和RRC配置给基站。UE通过公共所搜空间CSS搜索该信道。

Group Common PDCCH：成组的下行公共控制信道，处于初始的BWP空间。UE通过公共所搜空间CSS搜索该信道。

UE-Specific PDCCH：下行用户特有的控制信道，用于基于用户级的下行控制信道与功率控制，通过L3 RRC信令配置。UE通过用户特有的搜空间USS搜索该信道。

 

第5章 PDCCH编码过程

这个过程就是物理层编码、调制的过程。

需要留意的是，最左边的输入是DCI n，这表明：

（1）PDCCH的输入是DCI, PDCCH的作用是承载DCI

（2）一般来说，在一个子帧内，可以包含一个或多个UE上的资源分配和其他的控制信息，即包含多个PDCCH。

（3）接收时，UE需要首先解调PDCCH中的DCI，然后才能够在相应的资源位置上解调属于UE自己的PDSCH（包括广播消息，寻呼，UE的数据等）

 

---

参考博文：

https://blog.csdn.net/u010658002/article/details/107130050

https://blog.csdn.net/u010658002/article/details/107596231

https://blog.csdn.net/weixin_41967965/article/details/82943849

http://blog.sina.com.cn/s/blog_12d8ac1b40101gqkj.html

https://blog.csdn.net/dxpqxb/article/details/104062886

https://blog.csdn.net/jxwxg/article/details/80638989/