NR PDCCH(二) SearchSpace

这篇开始介绍SearchSpace。CORESET 描述的是PDCCH 盲检资源的频域特性，SearchSpace 代表的是时域特性，具体的说就是有关时域周期和偏移、每周期内持续监测的时隙数和每个时隙内的监测的具体起始符号等，这些其实就是指示了CORESET的时域位置，两者结合构成确定的时频域资源用于PDCCH data (DCI)接收。

同样的Searchspace0是在MIB 提前配置的，与CORESET0 结合，用于RMSI 的接收。MIB 中pdcch-ConfigSIB1 高四位 代表controlResourceSetZero，高四位索引查38.213table 13-1～13-10，可获得CORESET 0的复用样式、频域资源占用符号数量、RB数量和RB偏移；低四位 代表searchSpaceZero，使用低4位索引查38.213 table 13-11到13-15，可获得CORESET 0的SFN、时隙索引和起始符号等。具体可以看小区搜索部分。

根据38.213 10.1章节描述 ，搜索空间分为两种：CSS(Common Search Space)和USS(UE-specific Search Space)。CSS如common 是用于Common场景,如接收SI ,RA过程，收paging等;USS适用于特定UE接收场景，一般是在进入connected mode后，网络才会配置的USS。

这里是38.213中的描述

Type0-PDCCH CSS :由MIB中的pdcch-configSIB1 配置（SA），或PDCCH Config Common中的searchspaceSIB1 配置（NSA），CRC 扰码为SI-RNTI。

Type0A-PDCCH CSS :由PDCCH Config Common 中的searchSpaceOtherSystemInformation 配置，CRC 扰码为SI-RNTI；

Type2-PDCCH CSS: 由PDCCH Config Common 中的配pagingSearchSpace置，CRC扰码为P-RNTI；

Type1-PDCCH CSS 由PDCCH Config Common中的ra-SearchSpace配置，CRC扰码为RA-RNTI或TC-RNTI或MsgB-RNTI;

Type3-PDCCH CSS  由PDCCH Config(Dedicated）中的searchSpaceType= common配置，CRC扰码为INT-RNIT  or SFI-RNTI or TPC-PUSCH-RNTI or TPC-PUCCH-RNTI  or TPC-SRS-RNTI and only for the primary cell,C-RNTI or CS-RNTI

PDCCH 信道Common配置

1 controlResourceSetZero  searchSpaceZero 分别对应CORESET 0 和SearchSpace 0的配置。

具体含义和MIB 中的pdcch-ConfigSIB1 类似（NSA 下需要在此配置，SA下仅在MIB 中配置即可）

2 可以配置额外的CORESET （1-11），不配置时，默认为CORESET 0（SSB 关联）

3 可以配置1-4个搜索空间：searchSpaceSIB1/searchSpaceOtherSystemInformation/pagingSearchSpace/ra-SearchSpace ,都是可选配置，当不配置时，都默认使用SearchSpace 0。

下面看下search space 配置结构

{

                                  searchSpaceId 7,

                                  controlResourceSetId 0, //关联的CORESET id 

                               monitoringSlotPeriodicityAndOffset sl1 : NULL,// period是1个slot 表示监听周期是 1 个时隙，偏移时隙为null,表示不存在偏移场景

                                  monitoringSymbolsWithinSlot '11000000 000000'B,// 代表一个时隙中的14个symbol 这里代表要监听这个时隙的第1 和第2个symbol

                                  nrofCandidates

                                  {

                                    aggregationLevel1 n0,

                                    aggregationLevel2 n0,

                                    aggregationLevel4 n2,// 指定一种Aggregation Level 和对应的PDCCH Candidate数量

                                    aggregationLevel8 n0,

                                    aggregationLevel16 n0

                                  },

                                  searchSpaceType common :

                                    {

                                      dci-Format0-0-AndFormat1-0

SearchSpaceId:范围0-39，0表示PBCH或ServingCellConfigCommon配置的RMSI搜索空间。每个BWP内搜索空间个数限定在10个（含初始搜索空间）

ControlResourceSetId:0表示初始CORESET

monitoringSlotPeriodicityAndOffset : 表示监听周期和偏移时隙，如果配置的是 sl8:7 则代表监听周期是8个slot，要监听的是第8个slot（0～7，所以 7 代表第8个slot）

monitoringSymbolsWithinSlot: 监听时隙的周期和offset配置；共14位,以位图形式表示时隙中中要监听的符号 ；置1的bit就代表要监听的符号。

NR 中的不同搜索空间需要高层参数配置，每个搜索空间关联一个CORESET ID确定具体的一块时频域资源。

当UE想要找到PDCCH时，高层参数指示的search space中会指示对应的时域周期和偏移、每周期内持续监测的时隙数和每个时隙内的监测的具体起始符号，这些其实就是指示了CORESET的时域位置；然后按照该search space和对应的CORESET中包含的信息，进一步确定具体的时频域资源，UE从这些资源中盲检PDCCH 即可。

举个例子

SIB1中配置的searchspace 1/8,最后指定了SIB1 OSI paging RA等的searchspace，总结的说SIB1 对应的是searchspace0(在MIB中配置)，OSI 对应的是searchspace8（log中是与CORESET0配对使用），paging 和ra 对应的都是searchspace1（和CORESET0 配对使用）。

假如CORESET时域长度为2个符号, Monitoring Symbols Within Slot为“10001000100000",表示UE需要在时隙的符号0/1,4/5,8/9监听PDCCH。

PDCCH 搜索空间开始时隙号满足条件：

UE在满足(nf x N_frame_slot + n_u_s,f - Os)mod Ks = 0的时隙开始连续监听Ts个时隙。监听的时隙数在CORESET和searchspace已经确定。

其中nf是frame number; n_u_s,f是slot number;

Op,s是monitoringSlotPeriodicityAndOffset 中的Offset值

Ks是monitoringSlotPeriodicityAndOffset中peridicity。

search space index 只能是1～39 ，加上search space 0，则最多只能40 个 search space

在PDCCH 盲检时需要用正确的RNTI进行解扰和CRC校验，才能确认DCI是不是发送给UE的，也不能同一时刻用所有的RNTI 去监听PDCCH，不然，对UE来说也是负担。为了提升效率，38.202预定义了多种Reception Type，对于某个Reception Type，UE使用对应RNTI监听PDCCH即可，由于Reception TypeA对应的是PBCH，所以不需要RNTI。UE 在不同的过程根据表中的组合，用对应的RNTI 监听PDCCH 即可。如果UE 目前在进行RA过程，就用D0组合；如果此时在connected mode，也就不需要用RA-RNTI/T-C-RNTI 监听。38.202 也定义了在不同状态下适用的Reception Type 组合，UE需要根据不同的状态用正确的RNTI 去监听PDCCH信道。

38.321介绍了不同的RNTI 的定义和作用

38.202 定义了DL 接收类型，物理信道，RNTI和传输信道的组合关系。

38.202 定义了不同状态下的下行接收类型组合。

另外，UE解调PDCCH，是需要下行参考信号进行信道估计。在NR中，就需要PDCCH的DMRS来辅助完成PDCCH 的decode。

PDCCH DMRS

38.211

PDCCH DMRS 是伪随机序列需要赋初值  因而要有scrambling 配下来，这里的初值对应的是Nid；当RRC 层有配置pdcch-DMRS-ScramblingID时，Nid=pdcch-DMRS-ScramblingID,否则Nid=N_cell_ID。

提到DMRS，那 DMRS 的具体工作原理是什么？简单说DMRS是用于解调的，对UE来说，配置DMRS参数确定了后（例如上面的Nid 确定后），那DMRS就是一个确知信号，DMRS设计思想是插入到各种信道的时频资源里面去，跟着信道一起发送，UE用DMRS做信道估计，最后就会得到表征信道特征的估计矩阵，然后根据信道特征矩阵，去对应的位置解析承载的内容。

用数学表达式来说PDCCH DMRS 的作用就是    X(t)*h(t)=Y(t)

其中X(t)代表DMRS，是已知的，Y(t)是UE接收到的信号，然后UE就可以解析出来h(t)，就是信道特征矩阵；

之后用于PDCCH 信道的解析，如Z(t)*h(t)=Y(t),Y(t)是UE接收到的信号，h(t)已知，那么就可以得到Z(t), Z(t)就是PDCCH 信道承载的data DCI 。这就是DMRS 的具体原理。

PDCCH DMRS 会映射到时频域资源上，如上述公式中的k=nN_RB_sc+4k'+1 ，k'=0,1,2;k就代表的PDCCH DMRS频域子载波的位置，起点是CORESET 对应的下边界的RB 对应的subcarrier0位置，k的取值为{1,5,9,13.....}

l是时域符号位置，也就是PDCCH 的时域位置；总结来说PDCCH DMRS 是穿插在PDCCH 频域subcarrier 中的。 

PDCCH DMRS 是单端口 port=2000。

RRC 层会配置precoderGranularity:PDCCH 在频域上的预编码粒度。sameAsREG-bundle表示一个REG Bundle内采用相同预编码， allContiguousRBs 表示CORESET频域上所有REG采用相同预编码。

因此当高层配置的precoderGranularity 为sameAsREG-bundle时，PDCCH DMRS要穿插在PDCCH的REG资源范围内，以REG为基本单位decode；

当高层配置的precoderGranularity 为allContiguousRBs 时， PDCCH DMRS则可以穿插在CORESET内连续RB范围内的所有REG上。

如果网络端没有配置CSI-RS，那UE 会认为PDCCH DMRS 与SSB是QCL，也就是QCL-Type A: {多普勒频移，多普勒扩展，平均时延，时延扩展}的4个方面相似，还会应用相同的空域Rx参数。

PDCCH DMRS 的位置图示如下

微信公众号同步更新。

公众号：modem协议笔记