5G NR Search space和CORESET

PDCCH是下行控制信道,承载着PUSCH和PDSCH的控制信息DCI。在LTE中,PDCCH频域上占据全部带宽,时域上占据每个子帧的前1-3个符号,由资源的多少动态调度。在NR中,PDCCH若沿用LTE的方式,继续占据全部带宽,无疑是资源的浪费,而且会对UE提出很高的要求,不利于降低UE成本,所以NR中PDCCH会在BWP内,而且时域也不是占据固定的一些时隙,下面就讲述一下决定PDCCH时频资源的大概过程。主要涉及两个概念 search spaceCORESET
Search space有很多类型,首先分为common search space(CSS)和UE Specific search space(USS),具体如下:

  • Type0-PDCCH CSS set
  • Type0A-PDCCH CSS set
  • Type1-PDCCH CSS set
  • Type2-PDCCH CSS set
  • Type3-PDCCH CSS set
  • USS set

不同类型的CSS有不同的适用情形,比如Type1用于随机接入,具体的可以参考38213第10章。
不同类型的search space会有不同RNTI加扰的PDCCH。
UE在决定到底该去哪里寻找PDCCH时,高层会提供一个参数来指示search space。指示的来源在不同情况下有所不同:

  • PDCCH-configCommon在SIB1中,配置cell specific的common search space:
    5G NR Search space和CORESET_第1张图片
  • PDCCH-config配置UE specific的search space:
    5G NR Search space和CORESET_第2张图片
  • 还有MIB中的信息PDCCH-configSIB1是专门配置search space 0 和CORESET0的。CORESET0和search space 0 在38213第13章有详细介绍。

Search space中就会包含以下信息:
5G NR Search space和CORESET_第3张图片
这里只截取了与PDCCH时频位置相关的一部分参数,其他参数具体可以参考协议38331.这些参数的具体含义如下:

monitoringSlotPeriodicityAndOffset:
指示search space的周期和周期内的偏移,以时隙为单位,从图中可以看出有sl1、sl2等不同的可选项,sl表示slot的意思,比如sl40就表示search space的周期是40个时隙,后面对应的整数表示偏移,意思是在40个时隙中的哪个时隙开始是search space;
Duration:
上个参数指示了周期和偏移,这个参数指示了每个周期内search space持续的时隙个数;
monitoringSymbolsWithinSlot:
指示了在监测PDCCH的时隙中,具体从哪个符号开始监测,它是一个14位的bit串,每一个bit对应时隙中的一个OFDM符号,哪位值是1就表示从该符号开始监测PDCCH,对于扩展CP,由于一个时隙中只有12个符号,所以UE会忽略最后2bit,每个时隙中用于监测PDCCH的若干个符号其实就是所说的CORESET;
controlResourceSetId:
一个search space会与一个CORESET相对应,这个参数就指示了对应这个search space的CORESET。

一个search space只能对应唯一的CORESET。

CORESET中又会包含下列内容:
5G NR Search space和CORESET_第4张图片
其中与CORESET的时频资源有关的两个参数如下:
Duration:指示了CORESET持续的符号数;
frequencyDomainResources:指示了CORESET的频域资源。
其余关于交织方式、CCE-REG映射类型等参数不做介绍,大家可以自己参考38211和38213以及38331。从图中可以看到frequencyDomainResources是一个长为45的bit串,它指示频域资源的方式具体如下:
参数frequencyDomainResources 提供一个bitmap,bitmap中的每个bit和互不重叠的一组6个RB有一一映射关系,以BWP内RB的index升序排列。共45个bit,最高bit代表第一个RB组,以此类推。bit值为1表示这个RB group是CORESET的频域资源。BWP内第一个RB group的起始位置为6*roundup(N/6)所指示的CRB的位置,也就是说第一个RB group的起始位置并不是BWP的第一个RB,而是BWP内的第一个6的整数倍的CRB的位置。式中roundup表示向上取整,N表示BWP起始位置的CRB编号。具体的大家自己可以参考28213。

所以总结起来就是:

  1. 当UE想要找到PDCCH时,高层参数指示的search space中会指示search space的时域周期和偏移、每周期内持续监测的时隙数和每个时隙内的监测的具体起始符号,这些其实就是指示了CORESET的时域位置
  2. 然后按照该search space指示的与其对应的CORESET中包含的信息,进一步获取每个CORESET的资源大小

通过时域位置和资源大小,就可以确定下来一个CORESET0,从而UE可以从中盲检PDCCH。CORESET0也会将解码PDCCH的信息也一并告知UE,比如REG bundle的size等,这些在这里就不再细说,这篇主要讲UE如何找到去哪里检测PDCCH。

盲检PDCCH 的过程就是挨个对PDCCH candidate进行译码,如果CRC校验通过,则认为所译码的PDCCH就是UE要找的PDCCH。具体关于PDCCH相关的介绍可以看另一篇:https://blog.csdn.net/m0_45416816/article/details/99962825

你可能感兴趣的:(5G通信——物理层)