搜索空间以及终端接收控制信息的流程

96 阅读 0 评论 64 点赞

我是靠谱客的博主愤怒宝马，最近开发中收集的这篇文章主要介绍搜索空间以及终端接收控制信息的流程，觉得挺不错的，现在分享给大家，希望可以做个参考。

概述

我们知道，在LTE系统中，终端对于包含一个特定DCI的PDCCH的接收是通过盲检(Blind Detection)实现的。既然是盲检，那就说明对于PDCCH的接收是在一个指定范围内进行的，这个指定范围就是搜索空间(Search Space)，LTE中的搜索空间在时域上为每个下行子帧前N个OFDM符号(N $leqslant$ 3，由PCFICH指定)，频域上占满整个带宽(除去用于CRS以及PCFICH，PHICH占用的RE)。由于在LTE中PDCCH的时频域资源是以CCE为最小单位（1/2/4/8个CCE），所以终端可以使用这4种CCE聚合度在搜索空间内进行PDCCH的监听匹配。

与LTE中的搜索空间相似，NR中PDCCH也是使用盲检检索，同样也使用了搜索空间的概念。我们现介绍一下搜索空间的相关概念，再详细介绍在NR中的终端是如何盲检PDCCH的。

我们在博文“帧结构和物理资源(CCE，CORESET)”中已经介绍了CCE聚合度的概念，即在NR中，承载一个PDCCH的时频域资源也是以CCE为单位的。一个PDCCH可以使用1,2,4,8或者16个CCE来传输，这些用来传输PDCCH的CCE个数叫做CCE聚合度(CCE Aggregation Level)。通常来说，使用聚合度越大的CCE来传输PDCCH，其冗余bit数也越多，有助于增加终端解码PDCCH的正确率。因此，对于下行信道质量好的终端，发送给其的PDCCH可以使用较小的CCE聚合度，而对于下行信道质量较差的终端，就要使用较大的CCE聚合度来保证终端可以盲检到PDCCH并能正确解码。

类似于LTE中存在公共搜索空间和UE专有搜索空间两类搜索空间，NR中也存在这两类搜索空间，并且NR对公共搜索空间做了更加细致的划分：定义了一系列的公共搜索空间集合(search space set)。NR中的搜索空间总共有以下几类：

Type0-PDCCH 公共搜索空间集合(CSS set)：该搜索空间集合用于监听SIB1系统消息，对应在MCG(Master Cell Group)中的primary cell中用SI-RNTI加扰的DCI，在信令MIB中由IE: pdcch-ConfigSIB1配置或者在信令PDCCH-ConfigCommon中由IE：serachSpaceZero配置，或者在信令PDCCH-ConfigCommon中由IE：searchSpaceZero或者searchSpaceSIB1 配置。Type0-PDCCH CSS set支持的CCE聚合度和每个CCE聚合度中PDCCH candidates个数如Table 10.1-1所示。

Type0A-PDCCH CSS set：该搜索空间集合用于监听除了SIB1之外的系统消息，对应MCG(Master Cell Group)中的primary cell中用SI-RNTI加扰的DCI，在信令PDCCH-ConfigCommon中由IE：searchSpaceOtherSystemInformation 配置。如果基站没有给UE配置Type0A-PDCCH CSS set的CORESET，那么对应的CORESET就是Type0-PDCCH CSS set的CORESET。Type0A-PDCCH CSS set支持的CCE聚合度和每个CCE聚合度中PDCCH candidates个数如Table 10.1-1所示。

Type1-PDCCH CSS set：该搜索空间集合用于监听：1. 传统的4-step随机过程中的Msg3/4对应的下行PDCCH，对应在primary cell中用RA-RNTI或者TC-RNTI加扰的DCI；2. R16中新增的2-step随机接入过程中的MSGB对应的下行PDCCH，对应在primary cell中用MSGB-RNTI加扰的DCI。在信令PDCCH-ConfigCommon中由IE：ra-SearchSpace配置。如果基站没有给UE配置Type1-PDCCH CSS set的CORESET，那么对应的CORESET就是Type0-PDCCH CSS set的CORESET。

Type2-PDCCH CSS set：该搜索空间集合用于监听paging 消息，对应在MCG(Master Cell Group)中的primary cell中用P-RNTI加扰的DCI，在信令PDCCH-ConfigCommon中由IE：pagingSearchSpace 配置。如果基站没有给UE配置 Type2-PDCCH CSS set的CORESET，那么对应的CORESET就是Type0-PDCCH CSS set的CORESET。Type2-PDCCH CSS set支持的CCE聚合度和每个CCE聚合度中PDCCH candidates个数如Table 10.1-1所示。

Type2搜索空间集

Type3-PDCCH CSS set：该搜索空间集合用于监听上行功控 PDCCH，下行pre-emption PDCCH，slot format Indication PDCCH以及和下行数据传输相关的PDCCH，在信令PDCCH-Config中由IE：SearchSpace 配置，此时IE:SearchSpace = common，对应用INT-RNTI,SFI-RNTI, TPC-PUSCH-RNTI,TPC-PUCCH-RNTI或者TPC-SRS-RNTI加扰的DCI，并且对应在PCell上用C-RNTI，MSC-C-RNTI或者CS-RNTI加扰的DCI。
UE专有搜索空间(USS)：该搜索空间集合用于监听和下行数据传输相关的PDCCH，在信令PDCCH-Config中由IE：SearchSpace 配置，此时IE：searchSpaceType = ue-Specific，对应用C-RNTI,MCS-C-RNTI, SP-CSI-RNTI或者CS-RNTI加扰的DCI。

我们用下面的图做个搜索空间集的配置总结，顺便也解释下type3公共搜索空间集和UE专有搜索空间集：

上面我们说了搜索空间的类型，下面我们再看看一个搜索空间具体有哪些参数：

以上表格中SearchSpaceExt-r16为R16版本新增信令，SearchSpace为legacy的信令。无论哪种搜索空间的信令配置都有一个相关联的CORESET，这是因为某个特定DCI格式所对应的PDCCH是以某个特定的CCE聚合度承载在对应的CORESET上面的，CCE聚合度由信令SearchSpace/SearchSpaceExt-r16给出。

信令IE：freqMonitorLocations-r16用于共享频谱场景，为了让终端可以在多个RB set上监听PDCCH同时又不增加RRC信令的交互，NR引入了freqMonitorLocations-r16。同时在SearchSpaceExt-r16中也引入了信令IE：searchSpaceGroupIdList-r16，用来支持搜索空间组的切换功能，这个功能使得终端可以在两个搜索空间组之间动态控制PDCCH的监听。

我们在前面的博文“帧结构和物理资源(CCE，CORESET)”中说过一个CORESET是由多个CCE组成，而包含一个特定DCI格式的PDCCH其聚合度为1/2/4/8/16个CCE，并且在对应的CORESET上传输(对应关系由信令PDCCH-Config->controlResourceSetToAddModList指定)。在上面的表格我们可以知道，在一个搜索空间中通过信令IE：monitoringSymbolsWithinSlot给出了被监听的slot上该搜索空间指定的要监听的CORESET的起始OFDM符号，那么剩下需要做的就是盲检过程：终端怎样在该CORESET中监听并检测PDCCH。

我们再详细解释一下盲检的概念，PDCCH可以承载不同的DCI格式，而某一次PDCCH的传输对于终端而言是不知道该PDCCH到底承载的是哪个DCI格式，不同的DCI格式长度也可能不同，因此终端需要盲检PDCCH在指定搜索空间中指定的CORESET上的时频域位置，盲检还包括使用不同的DCI格式长度以及不同的CCE聚合度来检测终端期望收到的PDCCH。

为了减少盲检时间，在NR中，不同的DCI格式可能具有相同的长度，比如我们在博文“下行控制信息”中提到过，DCI format 0_0和DCI format 1_0就具有相同的长度。出于减少盲检时间的考虑，NR规定了一个终端最多只能监听四种不同的DCI长度：

用于回退的DCI格式(DCI format 0_0/1_0)
用于下行调度的DCI格式(DCI format 1_1/1_2)
用于上行调度的DCI格式(DCI format 0_1/0_2)
用作其他用途的DCI格式(DCI format 2_0/2_1/2_2/2_3/2_4/2_5/2_6)

终端也会利用本身所处的场景来缩小盲检的DCI格式范围。比如发起随机接入的终端，如果该终端已经发送了preamble，那么下一步该终端等待的就是RAR(Random Access Response)，其对应的RNTI为RA-RNTI，搜索空间为Type1公共搜索空间，对应的DCI格式只能是DCI format 1_0，此时终端就会使用DCI format 1_0的长度，聚合度1/2/4/8/16在指定的搜索空间中进行盲检。当终端尝试对一个候选PDCCH进行解码时，如果CRC解码正确并且其中的RNTI数值为自己期望的数值，则表示PDCCH盲检成功；否则终端继续进行盲检过程。

现在还有最后一个问题：对于同一个调度时刻(比如同一个slot)如果有多个终端等待上/下行调度，并且根据每个终端的信道质量的不同，其对应的PDCCH的CCE聚合度也不同，那么基站怎样确定每个终端的PDCCH在对应CORESET的时频域位置。

答案是采用一种公式给出每个终端的PDCCH在对应的CORESET上的CCE起始位置以及占用的CCE个数，并且这个公式一定要尽量将同一个CORESET上的不同终端的PDCCH位置散列化，也就是尽量避免冲突。NR在这个公式的描述上基本上延续了LTE时代的公式内容，我们下面具体看看：

对于在slot $n_{s,f}^{mu }$ 上的搜索空间集s中的候选PDCCH $m_{s,n_{ci}}$ ，其在CORESET p上的起始CCE位置为：

这里我们要说一下，对于以上公式中的跨载波调度功能，该功能在LTE的载波聚合功能中就已经存在，但是实际上商用的运营商并不多。所以在这里为了方便大家理解，我们可以将上式中的跨载波调度相关的参数移除，得到以下first CCE的计算公式：

我们再拓展一下，就可以得到终端在 slot $n_{s,f}^{mu }$ 上的搜索空间集s中的候选PDCCH $m_{s,n_{ci}}$ ，其在CORESET p上占用的CCE位置：

以上公式和LTE中终端PDCCH的起始CCE位置(我们通常叫做first CCE)的计算公式是基本相同的，但是NR对于PDCCH起始CCE位置的配置具有更大的灵活性和自主性，而LTE相对而言就差些。这是什么原因呢？其原因在于LTE中对于每种CCE聚合度以及每种聚合度下的PDCCH candidates个数是做了固定限制的，具体表现为如下的表格：

从以上表格我们可以看到，每种CCE聚合度对应的PDCCH candidates个数都已经固化，无法进行更改；公共搜索空间和UE专有搜索空间所有的PDCCH candidates总数为22，考虑到每个PDCCH candidates盲检的DCI格式除了本身特定场景下所对应的DCI格式外还需要监听回退格式的DCI，所以在最坏情况下，LTE中的每个终端需要盲检的PDCCH candidates个数为2 x 22 = 44；这个是无法改变的。

而我们之所以说NR对于PDCCH起始CCE位置的配置具有更大的灵活性和自主性，是因为基站可以通过信令(见下图)来配置需要监听的DCI格式和PDCCH candidates个数，这样可以有效缩短终端的盲检时间，尤其有益于URLLC场景下的终端业务。

从以上截图我们可以看出，基站可以为终端在每个下行BWP中配置多个搜索空间(最多配置10个)，这些搜索空间又可以分别配置不同的CORESET以及这些CORESET中可以传输的DCI格式，并为搜索空间中的DCI格式指定可以使用的CCE聚合度以及对应的PDCCH candidates个数。

下面我们举个例子来说明一下(非跨载波聚合场景)：

前置条件：

1. 在某个系统帧的子帧2上，C-RNTI为100的终端1和C-RNTI为200的终端2都需要监听自己的 PDCCH，这两个终端都配置了索引为0的搜索空间，搜索空间参数如下：

SearchSpace ::= SEQUENCE {

controlResourceSetId = 1

monitoringSymbolsWithinSlot = 10000000000000
nrofCandidates SEQUENCE {
aggregationLevel2 = n4
aggregationLevel4 = n4

}
searchSpaceType CHOICE {
ue-Specific SEQUENCE {
dci-Formats = formats0-1-And-1-1
}
}
}

2. 假设索引为1的CORESET的CCE总数为60，即 $n_{cce,1}=60$

3. 假设终端1和终端都需要在slot 2上监听DCI format 1_1，基站以CCE聚合度4传输终端1的PDCCH，以CCE聚合度2传输终端2的PDCCH。

根据以上前置条件，我们可以确定以下参数：

1. Ap = 39829;

2. 对于C-RNTI = 100, $y_{1,2}$ =34718;对于C-RNTI = 200, $y_{1,2}$ = 3899;

3. 对于CCE聚合度4， $m_{0}^{(4)} = 4$ , $m_{0}=0,1,2,3$ ; 对于CCE聚合度2， $m_{0}^{(2)} = 4$ ， $m_{0}=0,1,2,3$ ；

我们首先计算终端1的4个candidates的first CCE位置，可以得到如下结果：

candidate 0：first CCE：32， range：32~35

candidate 1：first CCE：44， range：44~47

candidate 2：first CCE: 0， range： 0~3

candidate 3：first CCE：16， range： 16~19

然后计算终端2的4个candidates的first CCE位置，得到如下结果：

candidate 0：first CCE：58， range：58~59

candidate 1：first CCE：12， range：12~13

candidate 2：first CCE: 28， range： 28~29

candidate 3：first CCE：42， range： 42~43

可以看到以上两个终端的first CCE的候选位置以及占用空间在索引为1的CORSET上没有重叠，这是最好的结果。

下面我们再在slot 2上面的CORESET上增加一个C-RNTI=300的终端3，其CCE聚合度为8，candidates个数仍然为4，我们得到如下结果：

candidate 0：first CCE：40， range：40~47

candidate 1：first CCE：48， range：48~55

candidate 2：first CCE: 8， range： 8~15

candidate 3：first CCE：24， range： 24~31

这个时候我们发现，引入了终端3的PDCCH传输以后，索引为1的CORESET上3个终端的某些候选PDCCH的位置出现了重叠区域，比如终端2的candidate 3和终端3的candidate 0在CCE 42~43上出现了重叠。此时就需要基站给每个终端的待调度的PDCCH分配CCE的时候进行综合考虑，避免出现不同终端的PDCCH对应的CCE位置出现重叠的现象。

一般来说，基站首先从CCE聚合度最高的PDCCH开始确定其first CCE位置及占用的CCE总数，当CCE聚合度最高的PDCCH的first CCE分配完毕后，再开始为CCE聚合度次高的PDCCH分配first CCE，依次类推。为什么先从CCE聚合度最高的PDCCH开始分配first CCE？我们设想一下，如果先从CCE聚合度最低或者较低的PDCCH开始分配first CCE，那么可能在最后给CCE聚合度最高的PDCCH分配first CCE的时候，CORESET上剩余可用的连续CCE个数无法满足CCE聚合度的要求(即剩余可用的连续CCE个数 < CCE聚合度)，导致CCE聚合度最高的PDCCH无法被调度。

这里我们给出上面例子中一种可能的各种终端的PDCCH的first CCE位置：

终端3：first CCE: 48, range: 48~55

终端1：first CCE: 44 ,range: 44~47

终端2：first CCE: 42, range: 42~43

从上例中我们可以看到，在一个CORESET中，可以监听的DCI格式、对应的CCE聚合度以及PDCCH candidates个数都是可以通过信令配置，这提供了极大的灵活性。设想一下，一个基站中有多个处于URLLC场景的终端，另有若干个做其他业务的终端，此处我们可以在该基站中定义2个DL BWP：一个用于URLLC场景(属于URLLC业务的终端全部在这个BWP上调度)，一个用于其他业务场景。对于用于URLLC场景的下行BWP，在其上的搜索空间和对应的CORESET中，DCI的CCE聚合度仅配置为16(这个是专门为URLLC设计的CCE聚合度)，那么做URLLC业务的终端只需要以一种CCE聚合度以及对应的PDCCH candidates个数进行PDCCH的盲检，这样无疑缩短了盲检时间。而对于另一个下行BWP，则可以按照上面的例子中的方式设计每种DCI的CCE聚合度和candidates个数，因为普通业务对于时延要求没有URLLC那么苛刻。