分享一個BWP配置異常的問題

這個問題是一個lab測試，主要測試目的是驗證UE是否能正常支持BWP的切換功能。但是在ims和internet PDU session建立起來后，TE側(cè)下發(fā)了一條RRCReconfiguration，UE就以reestablishmentCause=reconfigurationFailure 發(fā)起了RRC Reestablishment Req，毫無疑問肯定是這條RRCReconfiguration的問題。進一步看log，有以下trace打?。?/p>

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個數(shù)有關(guān)系，應(yīng)該是這條RRCReconfiguration帶的配置超過了UE支持的能力。為搞清楚這個問題，先看下協(xié)議中有關(guān)BWP個數(shù)的描述。

UE 最多可以配置4個UL/DL BWP，但是DL/UL 分別只能激活一個。如果UE 有配置SUL的話，可以對SUL額外配置最多4個BWP，但也是只能激活其中一個。為什么再次指出來這段描述？主要原因是有人說按照這段描述，UE應(yīng)該可以支持最多4個BWP，這份log才有3個，不應(yīng)該有錯，但是他忽略了協(xié)議上描述的是最大能力，具體UE的情況，要根據(jù)相關(guān)能力IE的上報，具體問題具體分析，就像協(xié)議上有那么多內(nèi)容的描述，不可能任何一臺UE都支持，UE要通過capability的上報，告知網(wǎng)絡(luò)具體情況，網(wǎng)絡(luò)知道了UE具體能力情況后，才能保證之后的配置不出問題；但是lab問題就另說了，TE上啥奇葩問題都有。

再看UE注冊小區(qū)信息及UE能力的上報。

通過SIB1我們知道UE注冊在N41上的某個小區(qū)，在UeCapabilityInformation中，看到上報的是bwp-SameNumerology=upto2,繼續(xù)看下這個具體是什么意思。

通過38.306中的描述，bwp-SameNumerology代表的是通過DCI或BWP-InactivityTimer進行BWP切換時，UE支持的相同SCS的最大的BWP個數(shù)。如果這里的描述還不夠清楚，可以打開38.822，這里會有 UE上報的相關(guān)IE及UE對應(yīng)支持能力的描述，如下

對于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的帶寬應(yīng)該包括CORESET#0(如果存在CORESET#0)和PCell/PSCell的SSB（如果有配置的話），以及UE specific 的RRC configured BWP的帶寬要包括SCell的SSB (如果 SCell 上有 SSB的話)。其他的相關(guān)能力，就列在這，方便后續(xù)查看。

UE支持的BWP個數(shù)比較清楚了，即“每個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 根據(jù)上圖的描述，intitial BWP 的BWP-id=0，其他BWP 的BWP-Id取值范圍對應(yīng)1～4，也就是最多可以有5個BWP，那這里是不是與描述的最多可以配置4個BWP 相互矛盾呢？接著看38.331 B.2 Description of BWP configuration options的例子。

如上圖，由于common的配置是小區(qū)級別的配置，一般只配置的DCI 1_0/0_0的初級功能，不支持DCI based的BWP 切換，因此對于First option中的情況，只能基于RRC reconfiguration的方式進行BWP 切換，例如從BWP#0切換到BWP#1 只能通過RRC reconfiguration實現(xiàn)，因為BWP#0不支持基于DCI的切換。這里還有一點要注意，上圖中的BWP id對應(yīng) 0～4，根據(jù)規(guī)定UE是只能配置4個BWP，那這里的BWP 0～4似乎是與規(guī)定不符合的，那這5個BWP有什么區(qū)別？我們知道這里的BWP#0不是RRC configured BWP，BWP 1~4因為在BWP-Downlink和BWP-Uplink中會有common和dedicated 配置，所以BWP 1～4是RRC configured BWP，而38.822中的相關(guān)能力的描述，針對的也是RRC configured BWP，假設(shè)UE支持配置4個RRC configured BWP的話(例如bwp-SameNumerology/bwp-DiffNumerology=upto4)，那這里的BWP 0～4也與UE能力相符，沒有任何異常；這個也就是BWP-id 0～4 可以同時存在的例子或者證據(jù)。

和上面那個圖不同，這個圖只有BWP 0~3，除了BWP#0外，只能配置最多另外3個BWP(Max 3 BWPs)，主要原因是因為這里BWP#0是RRC-configured BWP，進而BWP 0~3都是RRC-configured BWP，進一步說明了協(xié)議上規(guī)定的最多可以配置最多4個BWPs 對應(yīng)的是RRC-configured BWP。由于RRC-configured BWP既有BWP-common 配置也有BWP-dedicated 配置，且BWP-dedicated中已經(jīng)有配置高級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是小區(qū)級別的配置，只會配置DCI0_0/1_0，pdcch-Config是UE specfic 配置，才會配置DCI format DCI 0_1/0_2/1_1/1_2。

相關(guān)概念基本理清楚了，回到最初的問題，UE上報bwp-SameNumerology=upto2，代表UE最多可以支持2個SCS 相同的RRC configured BWPs。

打開發(fā)生異常的RRCReconfiguration，發(fā)現(xiàn)這條給UE配置了兩個RRC configured BWP 即BWP 1 和BWP2，似乎沒錯，UE支持2個RRC configured BWP的配置，但是還有一個BWP 0沒有檢查，查看整份log，發(fā)現(xiàn)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 發(fā)起了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)，這里應(yīng)該也不會出錯。

如上圖是三個BWP信息的總結(jié)，這里忽略了RRC configured BWP的帶寬是否包含CORESET#0和PCell/PSCell的SSB的檢查，一是畫這個圖太麻煩(懶)，二是在打印這條trace 時，UE肯定進行了相關(guān)檢查，UE log都確定了，所以就把這步省略了。