PDCCH monitoring capability

前段时间看search space set group (SSSG) switching相关内容时,注意到R17和R16的描述由于PDCCH monitoring capability的变化,内容有些不一样。于是就顺带看了下R16 R17PDCCH monitoring capability的内容。R16和R17分别对PDCCH monitoring进行了增强,R16 考虑到URLLC 的mini-slot调度,URLLC场景,一个时隙内可能存在多次调度,按照R15按照每个slot去定义盲检能力就不太合适,因而对于scs=15 kHz和30 kHz提出了per span的mini-slot PDCCH monitoring机制;R17将5G NR的频段范围从52.6GHz扩展到了71GHz,增加了FR2-2频段,FR2-2可以支持scs 120/480/960khz,进而numerologies就多了u=5,6的情况,但是较高的SCS 值(例如 480kHz 和 960kHz)会造成slot的长度变得更短, 如果UE在每个时隙都检测PDCCH,则PDCCH监听就会过于频繁,不仅会增加UE的功耗,还会增加UE检测的复杂度,影响UE的能力,此外,如果继续之前按照每个时隙的非重叠CCE和PDCCH候选选集的最大盲检数量的规定,调度的灵活性将受到影响并且 PDCCH负载会过重可能导致阻塞,因而R17 针对scs 480/960khz,提出了Multi-slot PDCCH monitoring机制(per slot group)。

截至到R17,目前有3种PDCCH monitoring,分别是R15 PDCCH monitoring capability(per slot),R16 PDCCH monitoring capability(per span),R17 PDCCH monitoring capability(per slot group),具体用哪种,需要结合场景及UE的能力去确定,具体到RRC IE,就是由monitoringCapabilityConfig带下来UE具体要用的PDCCH monitoring capability。

224d3289d9274b6bb44554652c0ce778.png

根据38.213 第10章的描述,在实际配置中,monitoringCapabilityConfig可以指示UE的PDCCH monitoring能力,分为r15monitoringcapabilty(per slot),r16monitoringcapabilty(per span)以及r17monitoringcapabilty(per slot group),然后根据对应的规定进行PDCCH monitoring;其中r17monitoringcapabilty只能用于scs=480和960 khz的场景,正好对应上面u=5和6的情况。

4737a3e06d824761a3ea1dbf44b42563.png

 monitoringCapabilityConfig RRC层配置结构如上。

这里就主要看下span和slot group是怎么回事。

R16 Mini-slot PDCCH monitoring

看下mini-slot PDCCH monitoring 中span描述。

283afaab1b5244e7baa8129d011812f9.png

扫描二维码关注公众号,回复: 15540483 查看本文章

 R16 考虑到URLLC 的mini-slot调度,针对u=0和1的scs提出了span的概念,span对应的是一个slot中UE需要进行PDCCH监听的连续符号数。每个PDCCH monitoring occasion都处于span的范围内。如果UE要根据组合(X,Y)去监听PDCCH,UE就要根据组合(X,Y)的划分,去支持一个时隙中对应符号数的PDCCH监测时机,其中两个连续span的第一个符号之间的最小时间间隔为X个符号,也包括跨时隙的场景;span从PDCCH监测时机的第一个符号开始,到PDCCH监测时机结束的最后一个符号结束,其中一个span对应的符号数最多是Y个。UE要监听的符号网络配置下来后,根据支持的组合情况再结合规定,去确定span。Rel-16定义的span-based PDCCH monitoring支持(2,2) (4,3) (7,3)的组合,即只支持X≤7 符号的场景。 

根据上面的规定,span是一个时隙内需要进行PDCCH monitoring的连续的符号数,(2,2)代表的含义就是两个连续span的第一个符号之间的最小时间间隔为2个符号且每个span对应的符号数最多是2个;(4,3)代表的含义就是两个连续span的第一个符号之间的最小时间间隔为4个符号且每个span对应的符号数最多是4个;(7,3)代表的含义就是两个连续span的第一个符号之间的最小时间间隔为7个符号且每个span对应的符号数最多是4个。

d25179d1e5f04f14941f73da368aaa73.png

 如果UE支持多个(X,Y)组合,此时search space set的配置显示2个连续PDCCH monitoring spans的间隔>=不止一个(X,Y)组合中的X,UE要根据满足条件的(X,Y)组合,依次进行PDCCH 监听,但是不能超过38.213中针对per span的最大盲检PDCCH候选集个数及最大非重叠的CCE个数。一般情况下,UE在active DL BWP上的每个时隙中要用相同的组合(X,Y)去进行PDCCH监听。

a2763b44230d4397aac5552e90ef1ea4.png

 相关的能力上报如上pdcch-Monitoring-r16,可以通过pdsch-ProcessingType1-r16或者pdsch-ProcessingType2-r16分别上报支持的span能力,period7span3代表组合(7,3), period4span3代表组合(4,3),period2span2代表组合(2,2)。

a98affd1d76e42a28d800de1609f6ae3.png

 如上图是2个时隙内的符号分布图,其中绿色部分是需要进行PDCCH监听的符号,结合上面的规定,如果采用组合(7,3)的 per span的监听的话,对于第一个slot内的14个符号,对应2个spans,两个span的第一个符号的时间间隔为7个符号,每个span对应的符号数是3个symbols。从这个例子可以看出,相比于R15,R16考虑的URLLC 场景会出现一个时隙内多次调度的情况,这时候就需要根据span的划分,去进行PDCCH monitoring。

0f29361584144738827570958ace4f03.png

 除此之外,通过pdcch-MonitoringMixed-r16可以指示UE在不同serving cell上支持 Rel-15 monitoring 能力和 pdcch-Monitoring-r16的能力。

R17 Multi-slot PDCCH monitoring

ce9990c6fde0442cbafdaf0232b9793d.png

 对于SCS μ=5或μ=6,UE可以根据一个或多个组合(Xs,Ys)进行PDCCH监听,其中Xs和Ys是连续的时隙数。Xs个slot 组成一个slot group,Xs个slots是连续且不重叠的,而Ys 个slot 要位于 Xs个slot内。第一组的Xs slots从一个子帧的起始位置开始。两组连续的Ys slots的由 Xs slots隔开。

如果UE根据组合(Xs,Ys)在小区上监听PDCCH,则UE可以在Ys的任意时隙中对Type1-PDCCH CSS set、Type3-PDCCH CSS set和USS set进行PDCCH监听;UE可以在Xs slots的任意时隙中去监听SIB1中提供的Type0/0A/2-PDCCH CSS set和Type1-PDCCH CSS set的PDCCH。

UE根据Xs时隙内的所有search space set确定用于组合(Xs,Ys)的最大候选PDCCH数量和非重叠CCE数量,其限制规定参照38.213 Table 10.1-2B和10.1-3B,如下。

b5836004388d4e55bbce8c03c3584a92.png

 具体支持哪几个组合需要通过几个IE上报,例如enhancedPDCCH-monitoringSCS-960kHz-r17和enhancedPDCCH-monitoringSCS-480kHz-r17,如下

cc4b1d56cafd4682b91d5f53bde54f02.png

 其中enhancedPDCCH-monitoringSCS-480kHz-r17 代表对于scss 480kHz,(Xs,Ys)=(4,2)的场景,UE是否支持在(slot group Xs=4)Ys=2对应的每个时隙的前3个OFDM 符号中对dedicated RRC 配置的type 1 CSS、type 3 CSS 和 UE-SS 进行multi-slot PDCCH 监听,从这段描述可以看出scs 480kHz只支持(Xs,Ys)=(4,2)的情况,且配置时Ys对应的时隙的前3个OFDM符号要用于PDCCH 监听。

enhancedPDCCH-monitoringSCS-960kHz-r17 指示UE是否支持对960kHz的(Xs, Ys) = {(4,1), (4,2), (8,4)}中的一个或多个组合进行多时隙PDCCH监听:

对于(Xs, Ys) = {(4,2), (8,4)},Ys对应的每个时隙的前3个OFDM符号要用于dedicated RRC 配置的type 1 CSS、type 3 CSS 和 UE-SS的PDCCH 监听;

对于(Xs,Ys)=(4,1),Ys对应的时隙要支持(X,Y)=(7,3)的per span PDCCH监听,即mini-slot的PDCCH 监听方式。

RRC层能力上报如上图右侧。

结合上面能力的描述,对于(Xs, Ys) = {(4,2), (8,4)},Ys个 slots中每个时隙内用于PDCCH 监听的符号位置对应的是前3个符号;而(Xs, Ys)=(4,1) 还需要monitoringSymbolsWithinSlot指示Ys对应的每个时隙内用于PDCCH监听的符号位置。

还有另外两个IE dl-FR2-2-SCS-480kHz-r17和dl-FR2-2-SCS-960kHz-r17支持Multi-slot PDCCH monitoring的能力具体描述如下,也是multi-slot和mini-slot两者结合的方式。

baa7b182718949cbb737448bad3b91de.png

 dl-FR2-2-SCS-480kHz-r17 支持(Xs,Ys)=(4,1)的multi-slot PDCCH monitoring,在Ys=1对应的slot,最多支持2个spans,span pattern可以是(4,3)和(7,3)等等规定。

748ba61b87954421b9ec01e253838d30.png

 dl-FR2-2-SCS-960kHz-r17 支持(Xs,Ys)=(8,1)的multi-slot PDCCH monitoring,在Ys=1对应的slot,最多支持2个spans,span pattern只能是(7,3)等等规定。

fe5337684be84f358f03f3004b7d0d9d.png

对于multi-slot PDCCH monitoring,monitoringSlotsWithinSlotGroup可以提供每个slot group的长度以及具体要监听的slot;可能还需要monitoringSymbolsWithinSlot指示每个slot内以per span形式进行监听的符号。

monitoringSlotsWithinSlotGroup由上图中的SearchSpaceExt-v1700配置,但是上图没有配置monitoringSymbolsWithinSlot,这时候根据下面的描述需要通过searchSpaceLinkingId将searchspace链接到另一个searchspace,进而通过另一个searchspace获取monitoringSymbolsWithinSlot。

3fc604dd4f474986a16935ccbf622fe0.png

 更具体地,monitoringSlotsWithinSlotGroup是一个bitmap,用于指示slot group中需要进行PDCCH monitoring的slot;slot group的大小与monitoringSlotsWithinSlotGroup的大小相同,slot group size 对应4(slotGroupLength4-r17)和8(slotGroupLength8-r17 );对于在dedicated RRC 信令中通过ra-SearchSpace提供的Type1-PDCCH CSS set,或对于 Type3-PDCCH CSS set和USS set,PDCCH monitoring的slot数量只能是连续时隙,并且对于UE支持的某个组合(Xs,Ys),连续时隙的个数不大于Ys;对于SIB1中ra-searchspace提供的Type1-PDCCH CSS set,PDCCH monitoring的slot数只能是slot group中某一个时隙;对于Type0-PDCCH CSS set/Type0A-PDCCH CSS set/Type2-PDCCH CSS set,PDCCH monitoring的slot可以不是连续的时隙,并且对应slot数量不能超过slot group的size。

monitoringSymbolsWithinSlot对应的就是一个时隙中用于PDCCH监听的符号数;searchSpaceLinkingId用于将某个searchspace set 关联到另一个search space。

几个相关的参数规定如下。

48ddb9d31fda477a80cb644dfad3bf0b.png

798bfbb338c54929a9dc0d678cbbb62e.png 

19542d5611bf4c47b39aa0e00982a0d9.png

 另外在进行Type0-PDCCH CSS sets的监听时,由于SS/PBCH block and CORESET multiplexing pattern 1 CORESET 0和SSB是时分复用关系,对于scs 480khz/960khz,也不再是原来的连续监听2个时隙的规定,而是在两个不同的时隙进行监听,480khz对应slot n0和n0+4;960khz对应slot n0和n0+8。

最后举个例子,假如配置的参数如下:

monitoringSlotPeriodicityAndOffset sl16 : NULL

monitoringSlotsWithinSlotGroup slotGroupLength4-r17 1100

duration-r17 2

slotGroupLength4-r17 1100 代表slot group 包含4个slot,L=4,其中从左至右的前两个用于multi-slot 场景的PDCCH 监听,对应(Xs,Ys)=(4,2)的情况;during-r17用于SCS 480 kHz和SCS 960 kHz的场景,配置的duration限制为slot group 长度L slots的整数倍且小于periodicity, 如果不存在duration-r17,则UE假定时隙中的持续时间等于L。最大有效持续时间是periodicity-L,这里2代表要监听2个slot group。

对于SCS 480 kHz和SCS 960 kHz,配置的monitoringSlotPeriodicityAndOffset要为L slots的整数倍,即对于给定的周期,偏移取值范围是 {0, L, 2*L, …, L*FLOOR(1/L*(periodicity-1))} 。其他参数就不看了,具体multi-slot PDCCH 监听的时隙和时隙内的符号图示如下。

9a90878cf6c74596ac87bf03b7b0d125.png

猜你喜欢

转载自blog.csdn.net/asd199086/article/details/131093640