5GNR PDCCH网优学习笔记

NRPDCCH（一）这个系列介绍NR的PDCCH（PhysicalDownlinkControlChannel），即物理下行控制信道。从高层角度看，UE需要的是PDSCH（PhysicalDownlinkSharedChannel，物理下行共享信道）和PUSCH（PhysicalUplinkSharedChannel，物理上行共享信道），无论控制面（ControlPlane），还是用户面（Userplane），数据都通过PDSCH或PUSCH传送。问题是，资源是有限的，如果基站不进行控制，UE就会乱成一锅粥，这时PDCCH的作用的就体现出来了——向UE传送“控制”信息。更具体的，基站通过PDCCH向UE发送DCI（DownlinkControlInformation，下行控制信息）。如果DCI指示PDSCH信息，称为DLAssignment（下行分配），UE在指示资源接收下行数据；如果DCI指示PUSCH信息，称为ULGrant（上行授权），UE在指示资源发送上行数据。

实际上，不止DCCH（DedicatedControlChannel）和DTCH（DedicatedTrafficChannel），CCCH（CommonControlChannel）、BCCH（BroadcastControlChannel）和PCCH（PagingControlChannel）也会（间接）映射到PDSCH和PUSCH。可见，PDCCH不仅和用户数据相关，还和系统信息（SIB）、寻呼（Paging）、随机接入（RandomAccess）、RRC连接建立（RRCSetup）等过程相关，是非常重要的物理信道。

根据不同的用途，DCI分为多种格式（DCIFormat）。在LTE中，DCIformat包括12种：指示PUSCH传输的0和4，和指示PDSCH传输的1、1A、1B、1C、1D、2、2A、2B、2C和2D。在NR中，DCIformat包括8种：0_0和0_1调度PUSCH资源；1_0和1_1调度PDSCH资源；2_0指示时隙格式（SlotFormat）；2_1指示资源抢占（Pre-emption）；2_2和2_3指示上行物理信道（PUCCH和PUSCH）或上行物理信号（SRS，SoundingReferenceSignal）的发送功率控制（TPC，TransmitPowerControl）。这里有个小问题，在同一小区中，所有UE都可以接收DCI，如何识别DCI是不是发送给自己呢？这时，基站需要用不同的RNTI（RadioNetworkTemporaryIdentifier）对DCI进行加扰（Scrambling）。以DCIformat1_0为例，如果基站用C-RNTI加扰，是向“一个”特定用户发送的，如果基站用RA-RNTI（MSG2）、TC-RNTI（MSG4）、SI-RNTI（SIB）或P-RNTI（寻呼），则是向“一组”特定用户发送的。

不同DCI格式的payload不同。以SI-RNTI加扰的DCIformat1_0为例，包括：FrequencyDomainResourceAssignment（频域资源分配指示，长度和下行BWP大小相关）、TimeDomainResourceAssignment（时域资源分配指示，4位）、VRBtoPRBmapping（VRB到PRB映射是否交织，1位）、ModulationandCodingScheme（调制与编码策略，5位）、RedundancyVersion（HARQ冗余版本，2位）、SystemInformationIndicator（用于SIB1还是OtherSI，1位）。UE从FrequencyDomainResourceAssignment和TimeDomainResourceAssignment获知PDSCH的时频资源（对于SIB1，可参考《NR的小区搜索（四）》），从VRBtoPRBmapping、ModulationandCodingScheme、RedundancyVersion获知如何对PDSCH进行处理（合并、解调、映射…），获得PDSCH传送的数据。

那么，DCI如何通过PDCCH传送呢——根据3GPPTS38.211和TS38.212描述，在NR中，包括7个步骤：1、InformationElementMultiplexing（字段串接）；2、CRCAttachment（CyclicRedundancyCheck，循环校验）；3、ChannelCoding（信道编码，Polar码）；4、RateMatching（速率匹配）；5、Scrambling（加扰）；6、Modulation（调制，QPSK）；7、ResourceElementMapping（RE映射）。重点看一下和RNTI相关的第2步和第5步，即循环校验和加扰。假设第2步的输入为“a0，a1，a2，…，aA-1”，长度为A。基站在前面添加24位“1”，通过gCRC24算法，生成24位循环校验码“p0，p1，p2，…，pA-1”，再添加到原始输入“a0，a1，a2，…，aA-1”后面。由此，得到长度为A+L（L为24）的中间输出“b0，b1，b2，…，bA+L-1”，基站保留前面A+L–16（A+8）位不变，用长度为16位的RNTI对最后16位进行“异或”运算，得到最终输出“c0，c1，c2，…，cA+L-1”，完成循环校验码的添加。加扰的关键在于“扰码”（ScramblingCode）。c(n)由多项式x1和x2生成，初始序列cinit由n_RNTI（高16位）和n_ID（低16位）构成。对于USS（UserSearchingSpace，用户搜索空间），如果CORESET（ControlResourceSet）配置PDCCH-DMRS-Scrambling-ID，n_RNTI等于C-RNTI，n_ID等于PDCCH-DMRS-Scrambling-ID——否则（包括CSS，CommonSearchingSpace，公共搜索空间），n_RNTI等于0，n_ID等于n_cell_ID。CORESET、USS和CSS等概念后面再说。

基站将DCI“加载”到PDCCH，反过来，UE从PDCCH“卸载”DCI。相对于基站，UE的处理过程要复杂一些。UE不确定基站会发送哪种DCIformat，也不确定基站会用哪种RNTI加扰（比如DCIformat1_0就有多种可能），UE甚至不确定基站有没有给自己发送DCI（在特定时间内，基站不一定给特定UE调度），会在哪个PDCCH发送。UE只能在黑暗中“摸索”前进，这就是PDCCH的“盲检”（BlindDetection）。UE用正确的RNTI进行解扰和CRC校验，才能确认DCI是不是发送给自己的。问题是，这么多种RNTI，UE应该用哪种呢？都试一遍也是个方法，但效率不高。因此，3GPPTS38.202预定义了17种“ReceptionType”（接收类型）：A、B、C0、C1、D0、D1、D2、E、F0、F1、G、H、J0、J1、J2和K，对于特定“ReceptionType”，UE使用对应RNTI监听（Monitoring）PDCCH——但A除外，A对应PBCH，不需要RNTI。

如果UE处于RRCIDLE或RRCINACITIVE状态，监听PCell就可以了——DC（DualConnectivity，双连接）或CA（CarrierAggregation，载波聚合）只存在于RRCCONNECTED状态，RRCIDLE或RRCINACITIVE没有PSCell和SCell。UE在PCell监听A+(Band/orC1and/orD0)+F0组合：A用于接收MIB（PBCH），B用于接收SIB（SI-RNTI），C1用于接收寻呼（P-RNTI），D0和F0用于接收随机接入的MSG4（C-RNTI）和MSG2（TemporaryC-RNTI）。如果UE处于RRCCONNECTED状态，在PCell、PSCell（DC模式）、SCell（CA激活）监听各种组合。比如说，G用于接收时隙格式（SFI-RNTI），J0、J1和J2用于接收TPC（TPC-PUSCH-RNTI、TPC-PUCCH-RNTI、TPC-SRS-RNTI）。对于某些流程，UE在不同阶段有不同期望，对监听类型也有影响。举个例子，如果UE没有发送MSG1（RandomAccessPreamble），就没必要用RA-RNTI监听了，因为UE没有期望接收MSG2（RandomAccessResponse）。另外，UE解调PDCCH，需要下行参考信号进行信道估计。在LTE中，UE使用CRS（CellSpecificReferenceSignal，小区特定参考信号）。在NR中，CRS被取消，单独设置了PDCCH的DMRS（DemodulationReferenceSignal）。DMRS序列的生成方式如图所示，如果高层配置PDCCH-DMRS-Scrambling-ID，N_ID等于PDCCH-DMRS-Scrambling-ID，否则，N_ID等于N_cell_ID。DMRS序列按上图映射到RE（ResourceElement）。在频域上，DMRS分布在各个RB（nxN_RB_SC）的第2、6、10（对应4k'+1，由0开始计数）个SC。参考点（k=0）定义如下：对于PBCH定义的CORESET，或PDCCHConfigCommon定义的CORESET0，参考点为CORESET频率最低的RB的第一个SC（subcarrier0），否则，参考点为CRB0的第一个SC。

最后，为了降低UE处理的复杂度，基站还会减少DCI大小（size）的可能选项。基站先确定某些DCIforma的大小，以这些DCIformat为参考，对其他DCIformat进行补位（Padding）或截短（Truncation），这个过程称为“DCI对齐”（DCISizeAlignment）。根据3GPPTS38.212描述，DCI对齐包括5个步骤。

Step0：根据章节.1描述，确定CSS的DCIformat0_0的大小，N_UL,BWP_RB由初始上行BWP确定；根据章节.1描述，确定CSS的DCIformat1_0的大小，N_DL,BWP_RB由CORESET0或初始上行BWP确定。如果在同一小区中，CSS配置DCIformat0_0和DCIformat1_0，DCIformat0_0大小向DCIformat1_0对齐——如果DCIformat0_0信息位（informationbit）少于DCIformat1_0，在DCIformat0_0后面补零（padding），如果DCIformat0_0信息位多于DCIformat1_0，缩短DCIformat0_0的FrequencyDomainResourceAssignment前面数位（truncation）。

Step1：根据章节.1描述，确定USS的DCIformat0_0的大小，N_UL,BWP_RB由激活上行BWP确定；根据章节.1描述，确定USS的DCIformat1_0的大小，N_DL,BWP_RB由激活下行BWP确定。如果DCIformat0_0和DCIformat1_0大小不同，后配置者向先配置者对齐。如果ServingCellConfig配置了SupplementaryUplink，且PUSCH在SUL和non-SUL发送，SUL和non-SUL对应的DCIformat0_0大小可能不同，较小者向较大者对齐。Step2：如果ServingCellConfig配置了SupplementaryUplink，且PUSCH在SUL和non-SUL发送，SUL和non-SUL的DCIformat0_1大小可能不同，较小者向较大者对齐。如果某个USS的DCIformat0_1和另一USS的DCIformat0_0（或1_0）大小相等，DCIformat0_1后面补1个零；如果某个USS的DCIformat1_1和另一USS的DCIformat1_0（或0_0）大小相等，DCIformat1_1后面补1个零（主动制造差异）。

Step3：经过步骤0、1、2后，如果以下两个条件都得到满足，则DCI对齐到此为止——条件1，UE在同一小区监听的DCI大小不超过4种；条件2，UE在同一小区使用C-RNTI监听的DCI大小不超过3种。如果至少有一个条件不满足，基站执行Step4。

Step4：删除Step2增补的0（undoStep2），根据章节.1描述，确定USS的DCIformat1_0的大小，N_DL,BWP_RB由初始下行BWP确定。根据章节.1描述，确定USS的DCIformat0_0的大小，N_UL,BWP_RB由初始上行BWP确定——用“初始BWP”替代“激活BWP”可减少可能选项。接着，DCIformat0_0大小向DCIformat1_0对齐，处理方式和CSS相同。

另外，DCIformat2_2和2_3（TPC，指示上行发送功率）大小和CSS的DCIformat1_0（或0_0，0_0会向1_0对齐）对齐（这部分没有包含在上述5个步骤中，见DCIformat2_2和2_3描述的最后一段）。DCIformat2_0（SF，时隙格式）最大为128位，DCIformat2_1（Pre-emption，资源抢占）最大为126位。

由此，经过基站的一番努力后，发送给（某个）UE的配置不应出现以下情况（否则UE会疯）：1、在同一小区内，监听的DCI大小超过4种；2，在同一小区内，使用C-RNTI监听的DCI大小超过3种；3、某一USS的DCIformat0_0和另一USS的DCIformat0_1大小相等；4、某一USS的DCIformat1_0和另一USS的DCIformat1_1大小相等。下图是某个UE配置的示例（引用自孙老师的文章）。这个系列是《NR下行物理信道（PDCCH）简析V2.0》（作者孙老师，发表于“春天工作室”公众号，推荐各位读者关注）的学习心得，提供给和我一样的小白参考。部分示图引用自孙老师的文章，为了风格的一致性，我重新绘制并做了修改（也可能引入了一些错误）。学习过程中得到多位专家的指导，在此表示感谢。（PS：文章没心情琢磨，其实只是想发封面照片而已...）NRPDCCH（二）原这一篇谈PDCCH的物理资源。基站通过PDCCH向UE发送DCI，那么，“1个DCI”对应的“1个PDCCH”具体占用多少资源呢？为了更好的描述PDCCH，3GPP定义了一系列单位，包括RE（ResourceElement）、REG（REGroup）、REGBundle和CCE（ControlChannelElement）——CCE是控制信道资源分配的最小单位，“1个PDCCH”由1个CCE或多个CCE构成。

从基站的角度看，向特定UE发送“1个DCI”，只需要“1个PDCCH”。从UE的角度看，却不确定“这个PDCCH”具体在哪儿（UE甚至不确定是否有自己的DCI，调度全看基站心情）。基站只会向UE指示一个“搜索范围”，如果UE搜到了（CRC校验成功），恭喜您中奖了，如果UE没搜到，明儿请早吧——不过早来也没用，哈哈。

在LTE中，下行子帧的前1~3符号为ControlRegion（控制区域）。除去PCFICH（PhysicalControlFormatIndicatorChannel，指示控制区域的时域长度）、PHICH（PhysicalHybridARQIndicatorChannel，对PUSCH传输数据返回HARQ响应）和RS（ReferenceSignal，参考信号），剩下的就是用于PDCCH的资源。控制区域横跨系统带宽（不需要定义PDCCH资源的频域长度），大小远超过“1个PDCCH”，但UE搜索范围还是相对确定的。在NR中，没有所谓的ControlRegion，PDCCH资源的位置变得非常灵活——对UE来说，这不是件好事。为了让UE在“茫茫RE海”中找到PDCCH资源，协议定义了两个概念：CORESET（ControlResourceSet，控制资源集）和SearchSpace（搜索空间，LTE也有搜索空间）。CORESET描述PDCCH资源的频域位置、频域长度和时域长度，SearchSpace描述PDCCH资源的时域分布。从某种意义来说，CORESET可理解为LTE的ControlRegion（剔除PCIFCH、PHICH和RS）。

这里的重点是，无论是LTE还是NR，PDCCH搜索范围（ControlRegion或CORESET）都远大于“1个PDCCH”，这个范围的资源如何划分为（一个一个的）PDCCH呢——我们从“小”往“大”看。RE是“时频平面”上最小的资源单位，1个RE在时域上对应1个symbol（符号），在频域上对应1个SC（Subcarrier，子载波）。在LTE中，1个REG由连续4个可用的RE（跳过RS）构成，1个CCE由9个REG构成。在NR中，1个REG由12个RE构成，1个REG在时域上对应1个symbol，在频域上对应1个RB（ResourceBlock）。在CORESET内，REG按照“先时域，后频域”顺序从0开始编号。1个CCE由6个REG构成，但REG编号不一定是连续的，因为CCE不直接映射到REG，而是通过REGBundle间接映射，CCE和REGBundle之间的映射可能会“交织”（interleaving），这会打乱CCE包含的REG。1个REGBundle由L个REG构成——对于交织（interleaved）映射，L由高层参数REGBundleSize确定；对于非交织（non-interleaved）映射，L固定为6。对于交织映射，如果CORESET的时域长度为1，L取值为{2,6}，如果CORESET的时域长度为2或3，L取值为{N_CORESET_symbol,6}——即{2,6}或{3,6}。由此，REGBundlei（i由0开始编号）包含的REG编号为{iL,iL+1,…,iL+L–1}，REGBundle和REG的对应关系示意如下。在REGBundle基础上，可以定义CCE。无论是否交织（interleaved），CCEj（j由0开始编号）包含的REGBundle编号为{f(6j/L),f(6j/L)+1,…,f(6j/L)+6/L–1}。如果L=2，6/L–1=2，CCE包含3个REGBundle；如果L=3，6/L–1=1，CCE包含2个REGBundle；如果L=6，6/L–1=0，CCE包含1个REGBundle。可见，无论L等于多少，CCE都包含6个REG（2x3=3x2=6x1）。对于非交织映射（non-interleaved），L=6，f(j)=j。由于6/L–1=0，CCEj只包含1个REGBundle，就是REGBundlej。如上图所示，CCE0对应REGBundle0，包含REG0~5；CCE1对应REGBundle1，包含REG6~11。简单而美好。

对于交织映射（interleaved），L由上层参数REGBundleSize确定，f(j)=(rC+c+n_shift)mod(N_CORESET_REG/L)。f(j)即交织函数。通过f(j)转换，CCE包含的REGBundle编号会发生变化，而不是像非交织那样顺序对应，目的是获得干扰随机化和分集增益。N_CORESET_REG表示CORESET包含的REG数量，N_CORESET_REG/L表示CORESET包含的REGBundle数量。可见，f(j)的自变量和因变量的取值范围都为0~N_CORESET_REG/L–1，f(j)的作用是将REGBundlej替换为REGBundlef(j)。R为交织行数，由高层参数InterleaverSize确定，取值可为{2,3,6}。C=N_CORESET_REG/(LxR)。n_shift为偏移REGBundle数，由高层参数shiftindex（取值可为{0,1,...,274}）确定，，如果高层参数没有配置，则取值为N_cell_ID。如果将R理解为“Rows”（行），C理解为“Column”（列），在忽略n_shift的情况下，由j=cR+r，f(j)=rC+c，交织函数的作用有点像“行列转置”（但不完全是，R和C通常不等）。

通过一个例子来观察交织函数的作用。如图所示，N_CORESET_REG=48，L=2，R=6，n_shift=1。C=48/(2x6)=4。由j=cR+r，24（48/2）个REGBundle按照第一个图排列，第一行为0、1、2、3、4、5，第二行为6、7、8、9、10、11，以此类推。如果不考虑n_shift，由f(j)=rC+c，24个REGBundle按照第二个图排列，第一列为0、1、2、3，第二列为4、5、6、7，以此类推。由L=2，1个CCE包含3（6/L–1=2）个REGBundle。交织前，CCE0包含REGBundle编号为0、1、2，交织后，CCE0包含REGBundle编号为0、4、8。如果把n_shift也考虑进去，交织后，CCE0包含REGBundle编号为1、5、9，可理解为在第二个图的基础上偏移n_shift个REGBundle后，再开始数REGBundle。

把这个过程简化一下，还可以这样理解交织函数。由N_CORESET_REG、L和R计算出C后，将REGBundle按照“每行C列”的方式排列，从REGBundle0开始偏移n_shift个REGBundle，再按照“列”的方向读出6/L个REGBundle，就是CCE0包含的REGBundle，后面的CCE顺序读出。简单的说，就是“行进列出”。沿用上面的例子。C=4，24个REGBundle按照每行4列的方式排列，然后从编号为n_shift的REGBundle开始，按照“列”的方向读出L=3个REGBundle，就是CCE0包含的REGBundle，即1、5、9，结果和上面一样。CCE1包含的REGBundle为13、17、21，CCE2包含的REGBundle为2、6、10，以此类推。

注意，如果N_CORESET_REG不能被LxR整除，即C不为整数，这种配置是没意义的，交织无法进行。比如说，如果N_CORESET_REG=24，L=6，R=3，则C=24/(6x3)=4/3——基站不会这么做，UE当然也不会见到。

由1个CCE总是包含6个REG，L=6时1个CCE只包含1个REGBundle（6/L–1=0）——CCE已经是“石头一块”，不能再细分了，如果和“非交织”（确切的说，忽略交织）的CCE对比，交织函数只打乱CCE顺序，不会影响CCE包含的REGBundle。如果L=2或3，交织函数会对CCE和REGBundle的顺序同时产生影响。

来看一个例子，如果N_CORESET_symbol=2，N_CORESET_REG=24，n_shift=0。由N_CORESET_symbol=2，L取值只能为2（N_CORESET_symbol）或6。当L=2时，R取值可为2、3、6，2x2、2x3、2x6都可以整除24（N_CORESET_REG），当L=6时，R取值只能为2，6x2可以整除24，而6x3和6x6不可以整除24。由N_CORESET_REG=24，CORESET可划分为4个CCE，即CCE0（蓝色）、CCE1（红色）、CCE2（灰色）和CCE3（绿色）。由图可见，当L=6时，CCE1包含REGBundle2，而CCE2包含REGBundle1，两个CCE包含的REGBundle是对调的。当L=2时，R取值为2、3、6，各个CCE包含的REGBundle呈现不同的分布图样，比L=6复杂一点。

CCE是控制信道资源分配的最小单位，1个PDCCH至少包含1个CCE。在某些场景中，比如说，UE所在的无线环境不够好，基站可由多个连续的CCE构成1个PDCCH，提高数据传输的成功率。在LTE中，可由连续的1、2、4、8个CCE构成1个PDCCH，对应PDCCHformat0、1、2、3。在NR中，可由连续的1、2、4、8、16个CCE构成1个PDCCH。1个PDCCH包含的CCE数量，称为AggregationLevel（聚合等级）。AggregationLevel越高，PDCCH冗余信息位越多，传输可靠性越高，但PDCCH的数量越少。反过来，AggregationLevel越低，PDCCH的数量越多，但传输可靠性越低。鱼与熊掌，不可兼得啊。NRPDCCH（三）这一篇谈CORESET（ControlResourceSet）。从某种意义来说，CORESET等同于LTE的ControlRegion（剔除PCFICH、PHICH和RS后），是“一组”用于PDCCH的物理资源。3GPP引入CORESET的原因，一方面，是提高PDCCH的搜索效率。NR的带宽（最大400MHz）远大于LTE（最大20MHz），如果像LTE那样，在整个带宽内搜索PDCCH，效率实在太低（UE：累死宝宝了）。另一方面，是提高系统的灵活性。NR可以配置多个CORESET，各个CORESET的频域大小（N_CORESET_RB）和时域长度（N_CORESET_symbol）可以不同。更本质的差异，是LTE的ControlRegion是小区级配置（PCFICH），而NR的（部分）CORESET可视为用户级配置（RRC），更符合NR的设计理念——“一切即可配置”。

先看一下信元。

不太严格的，CORESET可视为“时频平面”上的一个“方块”——FrequencyDomainResource用于描述频域占用的RB，duration用于描述时域的长度（因而NR不需要PCFICH）。CCEREGMappingType表示CCE到REG的映射类型，可以为交织（interleaved）或非交织（non-interleaved）。对于交织映射，REGBundleSize表示REGBundle包含REG数量（L），InterleaverSize指示交织行数（R），ShiftIndex指示偏移REGBundle数量（n_shift）。对于非交织映射，L固定为6，其他参数不相关，也无需配置。这部分参数意义可参考《NRPDCCH（二）》。Pre-CoderGranularity表示PDCCH在频域上的预编码粒度——SameasREGBundle表示REGBundle内频域上采用相同的预编码；AllContiguousRBs表示CORESET频域上所有REG采用相同的预编码。TCIPresentinDCI表示DCI是否指示TCI（TransmissionConfigurationIndicator），TCIStatesPDCCHtoAddList和TCIstatesPDCCHtoReleaseList指示PDCCH的DMRS和下行RS（SSB或CSI-RS）的QCL（QuasiCo-Location）关系。PDCCHDMRSScramblingID是DMRS序列和扰码的输入参数（仅适用于USS），这部分可参考《NRPDCCH（一）》。

重点看CORESET的时域和频域。在LTE中，ControlRegion的时域长度由PCFICH确定，PDCCH资源固定分布在下行子帧的前1~3个符号（或1~4个符号，取决于系统带宽大小）。在NR中，CORESET的时域长度（duration，对应物理层参数N_CORESET_symbol）可为1~3个符号，但只有高层参数DMRSTypeAPosition为3时duration才可为3。CORESET在时隙中的起始位置（firstsymbol）也是可配置的，这部分在SearchSpace（搜索空间）再说。

在LTE中，ControlRegion横跨系统带宽，不用单独为PDCCH资源定义频域参数。在NR中，CORESET占用的频域资源是可配置的，不过有一些限制：1、CORESET必须包含在BWP内；2、CORESET的频域资源必须是6RB（PRB）的整数倍数；3、CORESET起始位置的CRB索引必须是6的整数倍数。以下图为例，BWP起始位置为CRB4，则CORESET起始位置的CRB索引必须不低于4，且为6的整数倍数，示例中为6（可以为12、18…只要在BWP范围内）。FrequencyDomainResource以位图（bitmap）方式表示CORESET的频域资源，共45位，每位对应1组RB，每组包含6RB。FrequencyDomainResource最高位对应频率最低的1组RB。注意，RB分组不（一定）从PRB0开始，第1个RB组的第1个RB的CRB索引应为6x[N_start_BWP/6]（向上取整）。BWP以外的RB组，对应的位均置为0。以上图为例，BWP起始位置（N_start_BWP）为CRB4，6x[N_start_BWP/6]=6。第1个RB组包含CRB6~11（或PRB2~7），第2个RB组包含CRB12~17（或PRB8~13），以此类推。FrequencyDomainResource取值为“11101000…000”（共45位），表示CORESET由第1、2、3、5个RB组构成，共24个RB。

NR可以配置多个CORESET。基站通过RRC或SIB1告知UE最大CORESET数量（MaxNumberofCORESET）。每个CORESET对应一个CORESETID，取值范围为1~MaxNumberofCORESET–1。在同一小区的所有BWP中，CORESETID是唯一的。在1个BWP中，基站可以给UE配置多于1个CORESET（不计入CORESET0），前提是UE支持MultipleCORESET。在FR2中，UE必须上报是否支持MultipleCORESET，在FR1中，UE可以选择是否上报。你可能已经发现，通过RRC配置的CORESET，ID取值不能为0。CORESET0和别的CORESET都不一样，在RRC连接建立前，CORESET0就已经存在——在小区搜索中，UE通过CORESET0接收SIB1的调度信息。这意味着，CORESET0不是（也无法）通过RRC配置（但在NSA中，CORESET0也是通过RRC配置的），必须预先定义参数。根据3GPPTS38.211的章节，CORESET0采用交织映射，L（REGBundleSize）=6，R（InterleaverSize）=2，n_shift（shiftindex）=N_cell_ID（PCI）。

最关键的问题，是UE无法通过FrequencyDomainResource和Duration获知CORESET0的频域信息（占用RB）和时域长度（符号数量）。UE需要由MIB包含的PDCCHConfigSIB1查询预先定义表格（3GPPTS38.213表格13-1到13-10），在SSB（SynchronizationSignalBlock）基础上推算CORESET0的时频资源。这个过程在《NR的小区搜索（三）》有详细的描述，这里简单回顾一下。

SSB和CORESET0复用样式（MultiplexingPattern）分为三种——Pattern1为时分复用（CORESET0频域范围包含SSB），Pattern2和Pattern3为频分复用（CORESET0和SSB在同一系统帧）。Pattern2和Pattern3差异在于，在时域上，Pattern2的CORESET0比SSB位置略微靠前。CORESET0和SSB的关系由MIB提供，包括subCarrierSpacingCommon、ssbSubcarrierOffset和PDCCHConfigSIB1。PDCCHConfigSIB1由8位组成，将高4位和低4位拆开，可获得两个索引（Index），取值范围均为0~15。用高4位索引查询3GPPTS38.213表格13-1到13-10，可获得CORESET0的复用样式、符号数量（时域长度）、RB数量（频域长度）和RB偏移（频域偏移），用低4位索引查询3GPPTS38.213表格13-11到13-15，可获得CORESET0（确切的说，Type0CSS）的SFN、时隙索引和起始符号等。由上可知，UE使用高4位索引查询3GPPTS38.213表格13-1到13-10，可以获得FrequencyDomainResource和Duration对应的信息。和其他CORESET不同，CORESET0的频域信息用偏移（offset）和长度（N_CORESET_RB）描述，而不是位图（FrequencyDomainResource）方式，因而CORESET0必须占用连续的频域资源。UE根据SSB/RMSISCS和MinimumChannelBandwidth（最小信道带宽）选择表格。举两个例子，如果SSBSCS为15kHz，RMSISCS为30kHz，最小信道带宽为40MHz，UE应该查询表格13-6；如果SSBSCS为120kHz，RMSISCS为120kHz，UE应该查询表格13-8。在频域上，从SSB找CORESET0，方法和找PointA相似（可参考《NR的小区搜索（二）》），只要将offsetToPointA替换为表格（13-1到13-10）最后一列的offset。offset的单位为RB（RMSISCS），指向低频方向——如果offset为正数，CORESET0起始位置低于SSB，如果offset为负数，CORESET0起始位置高于SSB。

以Pattern2为例。SSBSCS为240kHz，RMSISCS为120kHz，对应表格13-10。如果index=6和index=7，CORESET0频域长度为48RB，时域长度为1个符号。如果index=7，频域偏移为49，SSB起始位置减去kssbxSCS，再减去49RB，就是CORESET0起始位置。49RB正好是CORESET0频域长度加1RB，确保CORESET0和SSB不会overlap——由于SSBSCS和RMSISCS不同，为了不影响OFDM子载波的正交性，加1RB作为保护间隔（GAP）。如果index=6，频域偏移为-41或-42。负数意味着反方向的偏移，SSB起始位置减去kssbxSCS，再“加”上频域偏移，就是CORESET0起始位置。如果kssb=0，频域偏移为-41，正好是SSB频域长度加1RB，刚好越过SSB和GAP。如果kssb>0，频域偏移为-42，因为减去kssbxSCS后，参考位置向下移动了一点，频域偏移多（负）1RB。Pattern2的CORESET0和SSB是频分复用关系，在频域不能存在overlap。

由此，无论是CORESET0还是RRC配置的其他CORESET，UE都知道CORESET的频域资源和时域长度，也知道如何交织构成CCE。不过，UE依然不知道CCE的AggregationLevel，也不知道CORESET多长时间会出现一次，每次持续多少个时隙，以及在时隙中的起始位置。这些信息UE都要从SearchSpace配置获得，下一篇再谈。NRPDCCH（四）这一篇谈SearchSpace。搜索空间是NR沿用自LTE的概念（稍有扩展）。为什么要定义搜索空间？一方面，PDCCH物理资源是共享资源，可能大于（单个）UE需求，如果对ControlRegion或CORESET遍历一遍，效率太低；另一方面，如果对DCIformat、RNTI、AggregationLevel（聚合等级）一无所知，UE需要尝试所有可能组合，效率更低。搜索空间的作用，就是缩小搜索范围，好比开卷考试，老师（基站）提前宣布答案都在偶数页，你（UE）就可以少花一半功夫。根据DCI的接收对象（或内容），搜索空间分为两种：CSS（CommonSearchSpace，公共搜索空间）和USS（UE-specificSearchSpace）。CSS适用于所有（或一组）UE接收场景，比如SIB（SI-RNTI）、Paging（P-RNTI）、RACH的MSG2（RA-RNTI）或TPC（TPC-PUCCH-RNTI、TPC-PUSCH-RNTI、TPC-SRS-RNTI）等；USS适用于特定UE接收场景，比如特定UE的调度（C-RNTI）、RACH的MSG4（C-RNTI或TC-RNTI）或半静态调度（SPSC-RNTI）等。

UE确定物理资源（ControlRegion或CORESET）大小和位置，就可以根据各种AggregationLevel构成PDCCH（详见《NRPDCCH（二）》），组成一个PDCCH“集合”。CSS和USS都是这个集合的“子集”。不同搜索空间的物理资源（CCE）可能存在“交集”，但不影响UE从PDCCH接收DCI，UE可以“旁若无人”，各收各的——实际上，基站也不会在已分配CCE资源发送其他DCI。UE优先搜索CSS，如果在交集“盲检”成功，搜索USS时可以跳过。NRPDCCH（五）这一篇谈PDCCH的配置和UE的处理。总的来说，PDCCH配置可分为小区级和UE级，基站通过PDCCHConfigCommon发送小区级配置，只包含CSS，通过PDCCHConfig发送UE级配置，包含CSS和USS。对于SA场景，UE直接从SIB1（NR空中接口）获得PDCCHConfigCommon，对于NSA场景（EN-DC），UE从MN/SNCombinedRRCMessage（E-UTRA空中接口）包含的NRRRC获得，具体路径为ServingCellConfigCommon->DownlinkConfigCommon->InitialDownlinkBWP->PDCCHConfigCommon。在SA场景中，UE从CORESET0获得SIB1的调度信息，从而完成初始接入，CORESET0和SearchSpace0不是通过RRC配置，而是使用MIB包含的PDCCHConfigSIB1查询3GPPTS38.213预定义的表格获知，具体可参考《NR的小区搜索（三）》。在NSA场景中，5G基站通过4G基站向UE转发配置，包含CORESET0和SearchSpace0配置信息——ControlResourceSetZero和SearchSpaceZero分别对应PDCCHConfigSIB1的前四位和后四位，作用相似。在PDCCHConfigCommon中，除了CORESET0，基站可以配置其他CORESET，CORESETID可为1~11，如果没有配置，UE默认使用（和接收SSB关联的）CORESET0。相似的，除了SearchSpace0，基站可以配置1~4个SearchSpace，分别为SearchSpaceSIB1（接收SIB1）、SearchSpaceOtherSystemInformation（接收其他SI）、PagingSearchSpace（寻呼）和RASearchSpace（随机接入）——不过，这些SearchSpace都是可选的，如果没有配置，UE默认使用（和接收SSB关联的）SearchSpace0。在SA场景中，CORESET0和SearchSpace0不是（也无法）通过PDCCHConfigCommon配置，PDCCHConfigCommon甚至可以不配，此时UE默认使用CORESET0和SearchSpace0。

CSS还可以分为Type0、Type0A、Type1、Type2和Type3。Type0CSS就是SearchSpace0，对应CORESET0，UE使用SI-RNTI“盲检”调度SIB1的PDCCH。在SA场景中，Type0CSS由MIB的PDCCHConfigSIB1配置；在NSA场景中，Type0CSS由PDCCHConfigCommon的SearchSpaceSIB1配置——如果基站没有配置，UE依然可以由MIB的PDCCHConfigSIB1获得，可谓“双保险”。Type0ACSS由PDCCHConfigCommon的SearchSpaceOtherSystemInformation配置，UE使用SI-RNTI“盲检”调度otherS