0
  • 聊天消息
  • 系統(tǒng)消息
  • 評論與回復
登錄后你可以
  • 下載海量資料
  • 學習在線課程
  • 觀看技術視頻
  • 寫文章/發(fā)帖/加入社區(qū)
會員中心
創(chuàng)作中心

完善資料讓更多小伙伴認識你,還能領取20積分哦,立即完善>

3天內不再提示

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

冬至子 ? 來源:modem協(xié)議筆記 ? 作者:酒仁生 ? 2023-07-17 15:58 ? 次閱讀

這個問題是一個lab測試,主要測試目的是驗證UE是否能正常支持BWP的切換功能。但是在ims和internet PDU session建立起來后,TE側下發(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ù)有關系,應該是這條RRCReconfiguration帶的配置超過了UE支持的能力。為搞清楚這個問題,先看下協(xié)議中有關BWP個數(shù)的描述。

圖片

UE 最多可以配置4個UL/DL BWP,但是DL/UL 分別只能激活一個。如果UE 有配置SUL的話,可以對SUL額外配置最多4個BWP,但也是只能激活其中一個。為什么再次指出來這段描述?主要原因是有人說按照這段描述,UE應該可以支持最多4個BWP,這份log才有3個,不應該有錯,但是他忽略了協(xié)議上描述的是最大能力,具體UE的情況,要根據(jù)相關能力IE的上報,具體問題具體分析,就像協(xié)議上有那么多內容的描述,不可能任何一臺UE都支持,UE要通過capability的上報,告知網(wǎng)絡具體情況,網(wǎng)絡知道了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上報的相關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的話)。其他的相關能力,就列在這,方便后續(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取值范圍對應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對應 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中的相關能力的描述,針對的也是RRC configured BWP,假設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 對應的是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。

相關概念基本理清楚了,回到最初的問題,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),這里應該也不會出錯。

圖片

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

聲明:本文內容及配圖由入駐作者撰寫或者入駐合作網(wǎng)站授權轉載。文章觀點僅代表作者本人,不代表電子發(fā)燒友網(wǎng)立場。文章及其配圖僅供工程師學習之用,如有內容侵權或者其他違規(guī)問題,請聯(lián)系本站處理。 舉報投訴
  • RRC
    RRC
    +關注

    關注

    0

    文章

    28

    瀏覽量

    11095
  • SSB
    SSB
    +關注

    關注

    0

    文章

    35

    瀏覽量

    14227
  • SCS
    SCS
    +關注

    關注

    0

    文章

    19

    瀏覽量

    10511
  • DCI
    DCI
    +關注

    關注

    0

    文章

    38

    瀏覽量

    6798
收藏 人收藏

    評論

    相關推薦

    Labview的異常崩潰

    起因:昨天升級程序后產(chǎn)線突然反饋程序異常崩潰,排查到了神奇的BUG。Labview異常崩潰報告未知異常:0x0000000000.排查:
    發(fā)表于 03-17 18:05

    java異常處理設計和些建議

    程序設計在程序設計中,進行異常處理是非常關鍵和重要的部分。程序的異常處理框架的好壞直接影響到整個項目的代碼質量以及后期維護成本和難度。
    發(fā)表于 09-28 11:48 ?0次下載
    java<b class='flag-5'>異常</b>處理設計和<b class='flag-5'>一</b>些建議

    10Java編程中異常處理最佳實踐

    這里是我收集的10Java編程中進行異常處理的10最佳實踐。在Java編程中對于檢查異常有褒有貶,強制處理異常門語言的功能。在本文中,
    的頭像 發(fā)表于 05-03 17:49 ?1899次閱讀

    無線關鍵技術突破 華為發(fā)布帶內全雙工(BWP-FD)技術驗證

    ? 1. 無線關鍵技術突破!華為發(fā)布并完成任意帶內全雙工(BWP-FD)技術驗證? 2020年12月8日,華為發(fā)布項無線關鍵技術突破——基于任意帶內全雙工技術(Bandwidth Part
    的頭像 發(fā)表于 12-29 14:15 ?5000次閱讀

    TAC配置錯誤引起用戶流量計費異常案例

    TAC配置錯誤引起用戶流量計費異常案例(場效應管接電源模塊)-該文檔為TAC配置錯誤引起用戶流量計費異常案例資料,講解的還不錯,感興趣的可以下載看看…………………………
    發(fā)表于 07-26 12:01 ?8次下載
    TAC<b class='flag-5'>配置</b>錯誤引起用戶流量計費<b class='flag-5'>異常</b>案例

    如何捕獲長時間測試中信號的偶發(fā)異常

    在產(chǎn)品的研發(fā)中,如何捕獲長時間測試中信號的偶發(fā)異常,是工程師們經(jīng)常遇到的問題。本文將為大家提供種新的方式,僅需臺機器,工程師就可以對
    的頭像 發(fā)表于 01-02 09:11 ?1622次閱讀

    7常見的mcu功能異常情況總結

    針對類似嚴重異常情況的原因我在這里大致總結下,與大家分享。 1、時鐘問題。般表現(xiàn)在時鐘配置異常,比方配置超出芯片主頻工作范圍?!緦τ赟TM
    發(fā)表于 02-11 14:26 ?2次下載
    7<b class='flag-5'>個</b>常見的mcu功能<b class='flag-5'>異常</b>情況總結

    APM32F030X8_配置差異_APM32庫在main前時鐘配置出現(xiàn)異常

    APM32F030X8_配置差異_APM32庫在main前時鐘配置出現(xiàn)異常
    發(fā)表于 11-09 21:03 ?0次下載
    APM32F030X8_<b class='flag-5'>配置</b>差異_APM32庫在main前時鐘<b class='flag-5'>配置</b>出現(xiàn)<b class='flag-5'>異常</b>

    NCN26010 - 入門基本配置、通信和異常處理

    NCN26010 - 入門基本配置、通信和異常處理
    發(fā)表于 11-15 20:18 ?0次下載
    NCN26010 - 入門基本<b class='flag-5'>配置</b>、通信和<b class='flag-5'>異常</b>處理

    SSB配置異常引起的問題解析過程

    這篇是兩SSB配置異常導致的問題總結,第一個問題很簡單,但是由于第次看到這種log,看起來也比較蒙,另外也是沒想到還能有這么弱雞的問題;
    的頭像 發(fā)表于 07-17 16:01 ?1580次閱讀
    SSB<b class='flag-5'>配置</b><b class='flag-5'>異常</b>引起的問題解析過程

    ARM中斷異常處理的基本術語

    如果異常的優(yōu)先級高于當前執(zhí)行優(yōu)先級,則可以先發(fā)制人當前執(zhí)行。 當異常優(yōu)先于另一個異常時,這些
    的頭像 發(fā)表于 07-24 09:57 ?1603次閱讀
    ARM中斷<b class='flag-5'>異常</b>處理的基本術語

    5G網(wǎng)絡如何選擇BWP?

    5G網(wǎng)絡中每個終端(UE)可配置多個BWP(Bandwidth Part),低速率業(yè)務時選擇窄帶寬BWP,而在進行高速數(shù)據(jù)業(yè)務時調整為大帶寬的BWP。
    的頭像 發(fā)表于 09-03 12:25 ?2348次閱讀
    5G網(wǎng)絡如何選擇<b class='flag-5'>BWP</b>?

    地址未對齊引起的HardFault異常

    地址未對齊引起的 HardFault 異常
    的頭像 發(fā)表于 09-18 10:57 ?678次閱讀
    <b class='flag-5'>一</b><b class='flag-5'>個</b>地址未對齊引起的HardFault<b class='flag-5'>異常</b>

    程序中增加變量導致異常的分析

    大家在平常的編程過程應該會碰到各種奇葩的問題吧,反正我最近是碰到了次,再此跟大家分享下。事情的原因是我在程序中增加了變量,然后就會導致程序每次都會進入
    的頭像 發(fā)表于 01-22 09:56 ?494次閱讀
    程序中增加<b class='flag-5'>一</b><b class='flag-5'>個</b>變量導致<b class='flag-5'>異常</b>的分析

    SPI全雙工模式下數(shù)據(jù)接收異常原因

    前面給小伙伴講過串口發(fā)送和接收異常的可能原因,今天我們講下SPI全雙工模式下數(shù)據(jù)接收異常原因。
    的頭像 發(fā)表于 01-23 09:31 ?1230次閱讀
    SPI全雙工模式下數(shù)據(jù)接收<b class='flag-5'>異常</b>的<b class='flag-5'>一</b><b class='flag-5'>個</b>原因