5G学习（五）：BWP和coreset的那点事儿

BWP的英文全程是Band Width Part，即一部分带宽，有时也用Bandwidth Adaptation（自适应带宽）来指代这个技术。

简述

BWP是5G新引入的概念，因为5G带宽较大（最大支持的带宽高达400M），若每一次收发工作带宽支持这么大的全频带带宽，这是不必要的，这将会对终端的射频性能提出很高的要求（大带宽意味着高采样率，高采样率也意味着高功耗），也难以实现芯片的集成化，成本会非常高。为了减少手机端的功耗，设置了BWP的概念。

技术原理

• 在5G中，UE的带宽可以动态的变化，每个UE可以设置属于自己的BWP,范围是整个带宽上的一个子集。
• BWP不仅在 每个BWP不仅仅频点和带宽不一样，其子载波间隔（SCS）、CP类型、SSB周期等都可以差异化配置，以适应不同的业务。
• 为DL/UL分别最多可以配置4个专有的BWP，但要注意的是，BWP的带框必须大于等于SSB，但是BWP中不一定包含SSB，对同一个UE来说，DL或UL同一时刻只能有一个BWP处于激活的状态，UE在这个BWP上进行数据的收发和PDCCH检索。

注：在连接态中最多可以配有4个BWP，加上INITIAL态的一个BWP，一个UE最多配有5个BWP。

• BWP1：UE由于业务量较大，gNB给UE配置了15KHz子载波间隔同时配置40MHz高带宽，可以在短时处理大量业务。

• BWP2：UE由于业务量较小，gNB给UE配置了15KHz子载波间隔并且配置10MHz带宽，满足UE基本通信即可；

• BWP3：gNB发现BWP1所在带宽内有大范围频率选择性衰落或者BWP1所在频率范围内资源较为紧缺，于是给UE配置了一个新的带宽。

优势

• 开发成本：UE不必支持全部带宽，只需要满足最低带宽要求即可，有利于低成本终端的开发，促进产业发展；
• 功耗：当UE业务量不大时，UE可以切换到低带宽运行，可以非常明显的降低功耗；
• 兼容：5G技术前向兼容，当5G添加新的技术时，可以直接将新技术在新的BWP上运行，保证了系统的前向兼容；
• 灵活：适应业务需要，为业务动态配置BWP

类型

一般可以分为三种类型：

• Initial BWP：这段BWP一般不会很大，均小于connected 态的BWP，它是在UE接入前进行信息接收，比如SIB和RA相关信息等，一般在Idle态使用。
• First Active BWP：UE第一个专有的BWP，UE可在这个BWP上进行数据的收发和PDCCH检索。
• Default BWP: UE专有BWP，是在RRCReconfiguration中配置给UE的，如果没有配置，则将Initial BWP认为是default BWP，并在bwp-inactivityTimer超时之后，UE仍没有被调度，则将UE切换到default BWP。
  

配置

我们应该知道小区首先根据numerology（参数集）确定其子载波间，然后由该子载波间隔确定的资源块（RB，resource blocks，频域占12个子载波）称为公共资源块，这些公共资源块确定整个载波的带宽（CRB carrier bandwidth）。
在协议中，我们定义了一个参数point A的参数，他指向了CRB起始RB为0的位置，所以，后续BWP中的所有位置都是由这个位置相对位移得来的，如下图：

上面所出现的Nstart就是各个不同BWP相对Point A起始的PRB。

小区调度某个终端的时候，只要在调度时间窗内往终端工作的BWP里面配置资源就可以了，而终端在某个工作时间段内，只要接收指定的BWP数据就行了。对于小区而言，它看到的是整个CRB带宽内不同BWP，它只工作在一个中心频率，即可完成对不同BWP的资源调度，而对于终端而言，它只需要在某个时间段工作在一个BWP（某个中心频率），通过不同时间段的BWP资源利用，来完成对整个小区CRB带宽的利用。当然，以上的这些都是仅仅工作其中某一个频带而已。

相对于终端，它对应的是整个频带，只是工作在不同的BWP中，而不同的BWP有可能子载波间隔是不一样的，而且对于同一个小区而言，它可能的公共子载波间隔与BWP内的子载波间隔是可能不一样的，那基站是如何将拥有不同子载波间隔的BWP进行切换的呢？

切换

通过DCI指示进行BWP切换

校验DCI format中参数Bandwidth part indicator field，若与当前BWP不一致，从而进行切换。但是，这个参数只有2比特信息，我们UE最多可以配置5个BWP，故区分下面两种情况。
1.initial BWP+3 BWP
以BWP-Id作为升序排列时候的位置索引
2.initial BWP+4 BWP

UE无法同过DCI切换到initial BWP，只能在连接态中的BWP配置中切换。如上图。

通过Timer超时来切换

这方法针对UE长时间不进行业务首发，这意味UE不再需要进行业务需求，故将UE切换到一个带宽比较小的BWP。

其中，参数bwp-InactivityTimer：用于计时UE多长时间没有数据收发，这里通过UE是否收到CDI来判断UE业务有没有业务，可以设置上限时间；参数defaultDownlinkBWP-Id：超时后UE要进入的BWP的ID。
可以注意到，只有defaultDownlinkBWP-Id，而没有defaultUplinkBWP-Id，是因为这里只有下行BWP切换，上行不需要进行切换。

基于RRC配置切换

这种方法主要用于RRC重配消息下发或者SCell激活之后，让UE进入到一个新的BWP。

上下行切换分别通过firstActiveDownlinkBWP-Id/firstActiveUplinkBWP-Id指示UE在RRC重配之后或者SCell激活后的切换，在重配后立马进行业务的收发，而没有处于initial BWP上。

切换时延

在时延方面，DCI和Timer的切换方法由上表得出，根据子载波间隔不同，延迟也各不相同，一般由延迟数值大的那个来决定。
比如从60Khz(u=2)切换到15Khz(u=0)，那么延迟取u=0的延迟1ms。
RRC切换的方法不仅考虑BWP时延，也应该考虑RRC的时延，相对较大。

coreset和SearchSpace

此部分配合SSB专题食用更佳。

引入coreset原因

在小区搜索SSB的检测后，为了检索SIB1信息，需要在PBCH中提取MIB信息里的pdcch-ConfigSIB1，里面8位比特信息指示了SIB1的调度信息可能的时频资源位置，UE根据这个时频资源位置，去盲检SIB1的DCI信息，这个DCI是承载在PDCCH信道上的。
不懂SSB的可以去看下我之前的文章请君移步

由之前学过的内容我们知道，PDCCH是下行控制信道，承载着PUSCH和PDSCH的控制信息DCI。在LTE中，PDCCH频域上占据全部带宽，时域上占据每个子帧的前1-3个符号，由资源的多少动态调度。在5G中，由于5G带宽增大，若是在5G中仍然占据全部频带，显然是不明智的，这时我们可以根据BWP的概念，由于这种改变，使得NR里面对于下行控制信息DCI的调度发生了改变，不再用专门的信道来指示PDCCH占用了几个OFDM符号，而转用一个称为CORESET的信道来指示PDCCH占用的时频资源，在每个BWP中设置coreset（其实coreset就是PDCCH，在LTE中并没有coreset的这个概念），在时域中也不是固定的，随着当前情况动态设置coreset的起始位置。

不同的CORESET定义有不同的 ID，其中CORESET0专门用来承载SIB1的DCI调度信息。而对于CORESET调度信息，又由RRC消息里面的ControlResourceSet消息携带，除了CORESET 0的调度信息。因为CORESET 0指示的控制信息里面，携带的是SIB1的调度信息，非常重要，默认了一个参数集来供UE进行盲检。

也就是说，在5G中，UE想要知道PDCCH在频域/时域上的位置，才能解码出PDCCH，NR系统将PDCCH时频符号数等信息放在了新的专有名词coreset中，将PDCCH起始OFDM符号编号以及PDCCH检测周期等信息放在搜索空间（search space）中。

PDCCH和DCI

通过CORESET和SearchSpce可以确定出PDCCH可能所在的位置。PDCCH即下行控制信道，主要用来承载上行调度信息和下行调度信息。承载在PDCCH上的控制信息称为DCI（Downlink control information），由于DCI的功能较多，为了方便区分，协议把DCI分为不同的类型。

coreset配置

下面RRC消息里的coreset消息的主要参数配置：

controlResourceSetId :即物理层里的’CORESET-ID’，CORESET 1由RRC配置，特殊的CORESET-0即为MIB里面定义的pdcch-ConfigSIB1（童鞋们，SSB中提到的），或者ServingCellConfigCommon里面指定的initialDownlinkBWP。 （Coreset 0是一段频域连续的位置，另外一种Coreset的配置方式是通过频域的bitmap方式进行指示。）

frequencyDomainResources：指示CORESET占用的频域带宽，总共有45bit，每一位指示6个RB资源，比特1表示分配给coreset的频域位置，总共可以指示270个RB资源，系统的最大带宽。这里采用了bitmap指示。(frequencyDomainResources=10000…从起始位置开始)

duration：指示CORESET在时域上占用的连续OFDM符号个数，取值为1，2，3。

cce-REG-MappingType：PDCCH所有的指示最终都是要映射到RB上的，但是若用RB表示的话并不方便，所以，我们采用一个更大的一个概念，REG表示多个RB，而CE对应6个REG，当我们在描述PDCCH时使用CCE单位。

下面我们举一个栗子：在下图图里面，frequencyDomainResources=10000…，即占用了第起始位置的6个RB，duration=2，即占用了2个OFDM符号时间，reg-BundleSize=6，即由6个REG组成一个CCE，聚合等级为1.

coreset 0 ??

这里，首先你应该要知道，RRC消息是承载到CCCH和DCCH上，最后下行映射到PDSCH上，那么根据上面的描述，这里出现了一个问题：当UE解完RRC消息后才能取得coreset资源，但是UE想要接收RRC消息又必须要知道coreset的资源，如此才能知道在具体的时频域资源去接收解调PDCCH，进而解调PDSCH信道。

很明显，这是一个头咬尾的问题，在协议当中引入coreset 0这个概念来进行解决。

在协议里将系统的初始接入的必要电镀资源（SIB1）封装在coreset 0里，而前面也说到了，coreset 0这个配置的具体调度参数是不需要RRC的，因为默认大家都知道，也就是说UE在解完SSB后，UE知道应该到哪个具体的时频域位置去盲检SIB1的调度信息。

引入search space原因

在上面的coreset的配置消息可以知道，coreset仅仅知道了PDCCH的频域位置和时域占据了几个OFDM的符号，但这并没有告知其具体的发送周期，以及具体OFDM符号的起始位置，故UE想要侦听DCI调度信息还是很麻烦。

所以在NR中，将PDCCH出现的周期和发送的OFDM符号位置定义在了search space中。

search space

看名字就知道了，负责搜索用的。一个CORESET和一个SearchSpace绑定起来后才能确定PDCCH的配置。一个CORESET可以和多个SearchSpace绑定，但一个SearchSpace却只能和一个CORESET绑定。
对于coreset 0，的SIB1调度信息DCI的搜索空间，由解出MIB中8位的pdcch-ConfigSIB1消息低4位确定。

search space配置

功能如上述表格，具体说明几个参数：

searchSpaceId：在每个BWP中最多配置10个搜索空间。

nrofCandidates：UE通过SearchSpace和CORESET将PDCCH的候选时频位置确定后，由于UE并不知道具体在哪个CCE上发送，所以UE进行盲检。这个参数就是为了指示PDCCH放置。

举例说明以下：假设monitoringSlotPeriodicityAndOffset设为sl10，即检测周期为10个slot,slot的偏移为5。duration设为1，即连续检测搜索空间的slot数是1，monitoringSymbolsWithinSlot设为10000001000000，当搜索空间关联的CORESET时域符号数为2，符号位置为0和7。那么在此配置下，UE会在每个检测周期的slot5的sym0、sym1和sym7、sym8检测候选PDCCH，如下图所示：

search space类型

Search space有很多类型，首先分为公共搜索空间（common search space：CSS）和UE特定搜索空间（UE Specific search space：USS），CSS主要是在接入时和小区切换时使用，而USS则是在接入后使用。具体作用如下表：

Type 0 PDCCH Common Search Space就是专门用来发送解码SIB消息的PDCCH。

总结：

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

参考

参考文章
参考文章
参考文章
参考文章
参考文章