分享一个BWP配置异常的问题

这个问题是一个lab测试，主要测试目的是验证UE是否能正常支持BWP的切换功能。但是在ims和internet PDU session建立起来后，TE侧下发了一条RRCReconfiguration，UE就以reestablishmentCause=reconfigurationFailure 发起了RRC Reestablishment Req，毫无疑问肯定是这条RRCReconfiguration的问题。进一步看log，有以下trace打印：

19:16:34.149506 RRC/HighFreq/High/NR5GRRC[ nr5g_rrc_llcdb.c 28157] LLCDB BWP Validation: Validating BWP config

19:16:34.149506 RRC/HighFreq/High/NR5GRRC[ nr5g_rrc_llcdb.c 28172] LLCDB BWP Validation: bwp-SameNumerology (0)

19:16:34.149507 RRC/HighFreq/High/NR5GRRC[ nr5g_rrc_llcdb.c 28183] LLCDB BWP Validation: MAX BWP (2) from CAP

19:16:34.149507 RRC/HighFreq/High/NR5GRRC[ nr5g_rrc_llcdb.c 28190] LLCDB BWP Validation: UL BWP number (3)

19:16:34.149508 RRC/HighFreq/High/NR5GRRC[ nr5g_rrc_llcdb.c 28222] LLCDB BWP Validation: Dedicated UL BWP number (3)

19:16:34.149509 RRC/HighFreq/Error/NR5GRRC[ nr5g_rrc_llcdb.c 28230] LLCDB: RRC OTA Validation failed. cc_idx (0) Number of Ded UL BWPs (3) > cap supported max bwp-SameNumerology (2)

从上面的log打印看，这个问题是与配置的BWP个数有关系，应该是这条RRCReconfiguration带的配置超过了UE支持的能力。为搞清楚这个问题，先看下协议中有关BWP个数的描述。

UE 最多可以配置4个UL/DL BWP，但是DL/UL 分别只能激活一个。如果UE 有配置SUL的话，可以对SUL额外配置最多4个BWP，但也是只能激活其中一个。为什么再次指出来这段描述？主要原因是有人说按照这段描述，UE应该可以支持最多4个BWP，这份log才有3个，不应该有错，但是他忽略了协议上描述的是最大能力，具体UE的情况，要根据相关能力IE的上报，具体问题具体分析，就像协议上有那么多内容的描述，不可能任何一台UE都支持，UE要通过capability的上报，告知网络具体情况，网络知道了UE具体能力情况后，才能保证之后的配置不出问题；但是lab问题就另说了，TE上啥奇葩问题都有。

再看UE注册小区信息及UE能力的上报。

通过SIB1我们知道UE注册在N41上的某个小区，在UeCapabilityInformation中，看到上报的是bwp-SameNumerology=upto2,继续看下这个具体是什么意思。

通过38.306中的描述，bwp-SameNumerology代表的是通过DCI或BWP-InactivityTimer进行BWP切换时，UE支持的相同SCS的最大的BWP个数。如果这里的描述还不够清楚，可以打开38.822，这里会有 UE上报的相关IE及UE对应支持能力的描述，如下

对于UE上报bwp-SameNumerology=upto2时，UE支持能力情况如下：每个carrier最多支持2 个UE specific RRC configured DL/UL BWPs；可以通过DCI和BWP-InactivityTimer主动切换BWP；每个carrier的所有UE specific 的RRC configured BWP 具有相同SCS；UE specific 的RRC configured BWP的带宽应该包括CORESET#0(如果存在CORESET#0)和PCell/PSCell的SSB（如果有配置的话），以及UE specific 的RRC configured BWP的带宽要包括SCell的SSB (如果 SCell 上有 SSB的话)。其他的相关能力，就列在这，方便后续查看。

UE支持的BWP个数比较清楚了，即“每个carrier最多支持2 个UE specific RRC configured DL/UL BWPs”，但是这里又涉及RRC configured BWP的概念，之前的BWP的笔记中有简单描述，这里再梳理一遍。

针对BWP #0 也就是initial BWP，有两种可能的配置方法：

First option:只配置 BWP-DownlinkCommon and BWP-UplinkCommon in ServingCellConfigCommon,不配置 dedicated configurations in BWP-DownlinkDedicated or BWP-UplinkDedicated in ServingCellConfig， 这种不是RRC-configured BWP。

Second option：既有common配置 也有dedicated 配置的BWP 叫做RRC-configured BWP。

BWP-id 根据上图的描述，intitial BWP 的BWP-id=0，其他BWP 的BWP-Id取值范围对应1～4，也就是最多可以有5个BWP，那这里是不是与描述的最多可以配置4个BWP 相互矛盾呢？接着看38.331 B.2 Description of BWP configuration options的例子。

如上图，由于common的配置是小区级别的配置，一般只配置的DCI 1_0/0_0的初级功能，不支持DCI based的BWP 切换，因此对于First option中的情况，只能基于RRC reconfiguration的方式进行BWP 切换，例如从BWP#0切换到BWP#1 只能通过RRC reconfiguration实现，因为BWP#0不支持基于DCI的切换。这里还有一点要注意，上图中的BWP id对应 0～4，根据规定UE是只能配置4个BWP，那这里的BWP 0～4似乎是与规定不符合的，那这5个BWP有什么区别？我们知道这里的BWP#0不是RRC configured BWP，BWP 1~4因为在BWP-Downlink和BWP-Uplink中会有common和dedicated 配置，所以BWP 1～4是RRC configured BWP，而38.822中的相关能力的描述，针对的也是RRC configured BWP，假设UE支持配置4个RRC configured BWP的话(例如bwp-SameNumerology/bwp-DiffNumerology=upto4)，那这里的BWP 0～4也与UE能力相符，没有任何异常；这个也就是BWP-id 0～4 可以同时存在的例子或者证据。

和上面那个图不同，这个图只有BWP 0~3，除了BWP#0外，只能配置最多另外3个BWP(Max 3 BWPs)，主要原因是因为这里BWP#0是RRC-configured BWP，进而BWP 0~3都是RRC-configured BWP，进一步说明了协议上规定的最多可以配置最多4个BWPs 对应的是RRC-configured BWP。由于RRC-configured BWP既有BWP-common 配置也有BWP-dedicated 配置，且BWP-dedicated中已经有配置高级DCI ，所以可以进行基于DCI 进行BWP 切换。

再看下DCI field bandwidth part indicator的情况。

在进行DCI based BWP 切换时，需要通过DCI field bandwidth part indicator，而DCI 0_0/1_0 是初级DCI并没有bandwidth part indicator。所以如果手机支持DCI based BWP切换就需要配置DCI 0_1/0_2/1_1/1_2，才可能进行；如上图是DCI field bandwidth part indicator包含情况及DCI format的配置情况，pdcch-configCommon是小区级别的配置，只会配置DCI0_0/1_0，pdcch-Config是UE specfic 配置，才会配置DCI format DCI 0_1/0_2/1_1/1_2。

相关概念基本理清楚了，回到最初的问题，UE上报bwp-SameNumerology=upto2，代表UE最多可以支持2个SCS 相同的RRC configured BWPs。

打开发生异常的RRCReconfiguration，发现这条给UE配置了两个RRC configured BWP 即BWP 1 和BWP2，似乎没错，UE支持2个RRC configured BWP的配置，但是还有一个BWP 0没有检查，查看整份log，发现SIB1 中BWP 0只有 common配置，但是TE在RRC setup中给UE配置了bwp dedicated 配置，也就是说这时候BWP 0也是一个RRC configured BWP，一直到异常的RRCReconfiguration，BWP 0始终有common和dedicated 配置，所以最后log trace 会有"Number of Ded UL BWPs (3) > cap supported max bwp-SameNumerology (2) "超能力的打印，进而UE 以reestablishmentCause=reconfigurationFailure 发起了RRC Reestablishment Req。如果TE有在配置BWP 1 和BWP 2的RRCReconfiguration中，将BWP 0 的dedicated 配置 release掉的话，BWP 0就不是RRC configured BWP，那这时候就只有2个RRC configured BWPs(BWP 1 和BWP 2)，这里应该也不会出错。

如上图是三个BWP信息的总结，这里忽略了RRC configured BWP的带宽是否包含CORESET#0和PCell/PSCell的SSB的检查，一是画这个图太麻烦(懒)，二是在打印这条trace 时，UE肯定进行了相关检查，UE log都确定了，所以就把这步省略了。