干這行的朋友都知道5G NR協(xié)議棧里有一個詞繞不過去就是BWPBandwidth Part帶寬部分。它看起來只是把一個大帶寬切成幾段但實際牽扯到終端省電、資源調度、尋呼監(jiān)聽、載波聚合、RedCap共存等方方面面。我見過不少人剛開始接觸BWP時覺得“不就是給手機分一段頻帶么”結果一深入信令流程和參數(shù)配置才發(fā)現(xiàn)BWP切換時機、定時器回退、與CA和休眠BWP的協(xié)同才是真正容易踩坑的地方。這篇文章就把BWP這件事從頭到尾拆開講清楚內容包括它的設計初衷、核心參數(shù)、切換機制、和相關特性的配合關系最后給出一套可以直接參考的配置思路和排障經(jīng)驗。適合正在做基站側協(xié)議、終端協(xié)議棧、網(wǎng)絡優(yōu)化或者剛入門5G想系統(tǒng)搞懂BWP的工程師。1. BWP到底是干什么的從5G大帶寬的煩惱說起1.1 大帶寬是把雙刃劍4G LTE時代單個載波帶寬最大20MHz終端基帶處理壓力并不算大。到了5G NRFR1頻段Sub-6GHz單載波最大可以到100MHzFR2頻段毫米波更是能到400MHz。帶寬變大確實帶來了更高的峰值速率但問題也隨之而來終端不可能永遠都用全帶寬工作。原因很直接。基帶側的FFT點數(shù)、ADC/DAC采樣率、數(shù)據(jù)緩存大小都跟信號帶寬強相關。帶寬從20MHz翻到100MHz如果所有處理都按照100MHz去設計終端的功耗和成本會成倍上漲。射頻前端也一樣濾波器、低噪聲放大器、功放都要覆蓋更寬的頻段范圍器件難度和耗電量都會明顯增加。放在手機這種對功耗和散熱極其敏感的產品上這個矛盾非常致命。大家可以簡單回憶一下家里同一臺路由器有2.4G和5G兩個頻段2.4G能連上而5G連不上往往是終端自身的能力限制或者頻段支持問題。NR里的BWP本質上也是在處理“網(wǎng)絡側帶寬很大但終端側不必也不應該始終吃滿這個大帶寬”的問題。網(wǎng)絡設計上也需要更細的頻域資源劃分方式。一個大載波上不可能只有一種業(yè)務有高吞吐的大寬帶業(yè)務也有低速率、時延不敏感的物聯(lián)網(wǎng)業(yè)務還有需要低時延高可靠的工業(yè)控制業(yè)務。如果所有終端都用一個100MHz的公共信道做調度控制信道的容量、干擾協(xié)調、資源分配的靈活性都會變成大麻煩。BWP就在這個背景下成了NR資源管理的基礎構件。1.2 BWP的定義與直觀理解用一句話概括BWP就是一個載波內的一段連續(xù)頻域資源由一組連續(xù)的PRB物理資源塊構成并且可以配置自己的子載波間隔numerology。一個NR小區(qū)最多可以給終端配置4個下行BWP和4個上行BWP但同一時刻每個終端只能有一個激活的下行BWP和一個激活的上行BWP。打個比方一條可以并行八輛車的馬路對于一輛普通小車來說沒有必要每次都占滿八條車道。BWP就是給這輛車劃出的一兩條車道讓它在這條車道上正常行駛只有當它確實需要超大吞吐時才切到更寬的車道上。這樣既保證了效率又降低了終端的工作負擔。這里要區(qū)分兩個概念“配置”和“激活”。配置了4個BWP并不意味著終端同時在用4個BWP工作。小區(qū)通過RRC信令把BWP的頻域位置、子載波間隔、PDCCH資源、PUCCH資源等參數(shù)告訴終端終端只是知道有這些BWP存在。等實際調度時網(wǎng)絡再通過DCI信令或者定時器機制讓終端在某個BWP上真正收發(fā)數(shù)據(jù)這個正在工作的BWP才是激活BWP。1.3 BWP能解決的四個實際問題第一終端省電。終端在一個小的BWP上工作時基帶處理帶寬變小ADC和FFT的處理量、數(shù)據(jù)搬運量都下降這直接換來更低的功耗。這是BWP最核心的作用。第二頻域資源按需分配。不同終端可以根據(jù)業(yè)務需求分到不同BWP上網(wǎng)絡側在頻域上的調度更加靈活也方便做干擾協(xié)調。第三降低終端實現(xiàn)成本。一個只支持20MHz帶寬能力的終端不需要為了接入NR網(wǎng)絡而支持整個100MHz載波。網(wǎng)絡把一部分BWP配置成小帶寬就能讓這類低成本終端正常接入和工作。第四支持異系統(tǒng)和異業(yè)務共存。比如NR和LTE在同一個頻段內共存時可以通過BWP避開LTE的占用區(qū)域。再比如RedCap這類輕量級5G終端只有20MHz帶寬能力和eMBB終端共享同一個大載波時也主要依靠BWP實現(xiàn)頻域隔離。后面我會單獨展開講。2. BWP的類型、參數(shù)與配置細節(jié)2.1 Initial BWP、Default BWP、Active BWPBWP在協(xié)議里分幾種角色理解這幾種角色是配置和排障的基礎。Initial BWP也叫初始BWP。終端剛接入小區(qū)時還沒有收到RRC重配置消息它要先通過PBCH里的MIB獲取CORESET#0的配置再通過SIB1獲取初始下行BWP和初始上行BWP的相關參數(shù)。終端在空閑態(tài)監(jiān)聽尋呼、發(fā)起隨機接入都發(fā)生在初始BWP上。需要特別注意的是初始下行BWP的頻域范圍和CORESET#0必須能對得上否則終端連系統(tǒng)消息都讀不完整。Default BWP也就是默認BWP。終端進入連接態(tài)之后如果長時間沒有調度活動網(wǎng)絡希望它能自動回退到一個小帶寬的BWP上去省電而不是一直守在大帶寬BWP上。這個回退目標就是Default BWP它由RRC配置里的bwp-Id指定。如果網(wǎng)絡沒有配置Default BWP則終端回退到Initial DL BWP。Active BWP即當前正在工作的BWP。下行和上行各有一個。網(wǎng)絡通過DCI里的BWP indicator字段切換激活的BWP或者通過BWP inactivity timer讓終端自動回退到默認BWP。這里有一個容易混淆的地方TDD模式下上下行共享同一個頻帶下行BWP和上行BWP是按BWP ID配對的即DL BWP#1和UL BWP#1在頻域上相同只是方向不同。FDD模式下下行BWP和上行BWP是獨立配置的頻域位置可以不同。這一點在配置時一定要先搞清楚很多現(xiàn)場配置錯誤都是因為把TDD的配對邏輯套到了FDD上。2.2 一個BWP的完整配置項我們可以把一個BWP的配置項拆成三塊看頻域位置、numerology、關聯(lián)資源。頻域位置由兩個關鍵參數(shù)決定。第一個是startPRB表示BWP在整個載波上的起始PRB位置。第二個是length表示BWP占用的PRB個數(shù)。這兩個參數(shù)都是以公共RBCRB為參考系的。要注意startPRB的參考點通常是Point A也就是載波的最低頻點對應的CRB0位置而不是絕對頻點。配置時如果Point A理解錯了整個BWP的位置都會偏。numerology方面核心是子載波間隔SCS和循環(huán)前綴CP類型。FR1里常見的SCS有15kHz、30kHz、60kHzFR2里常見的是60kHz、120kHz。一個BWP內只能有一種SCS但不同BWP之間可以配不同SCS。比如Initial BWP用15kHz或30kHz保證覆蓋而數(shù)據(jù)BWP用30kHz或60kHz來提升速率和降低時延。關聯(lián)資源這部分最容易出問題。一個下行BWP里至少要配置PDCCH相關的CORESET和搜索空間否則網(wǎng)絡沒法在這個BWP上調下行數(shù)據(jù)。PDSCH的速率匹配參數(shù)、CSI-RS資源、SPS配置等也都要落在對應BWP內。一個上行BWP里需要配置PUCCH資源、PUSCH配置、SRS資源等。如果激活到一個沒有PUCCH資源的BWP上終端連SR和CSI反饋都發(fā)不出去。2.3 Initial BWP、CORESET#0和SSB的關系Initial BWP和SSB、CORESET#0的關系是接入階段最關鍵的細節(jié)。SSB同步信號和PBCH塊是終端搜索小區(qū)時最先找到的參考信號終端通過SSB里的PBCH獲取MIBMIB里指示了CORESET#0的頻域位置、大小和子載波間隔。終端在CORESET#0上監(jiān)聽PDCCH讀取SIB1SIB1里再配置初始下行BWP和初始上行BWP。這里經(jīng)常出現(xiàn)的問題是SCS不一致。比如SSB的SCS是30kHz但CORESET#0和Initial BWP如果配置成15kHz終端可能能搜到小區(qū)卻無法正常解調SIB1或者接入后隨機接入流程異常。協(xié)議里CORESET#0的SCS和Initial BWP的SCS是有關聯(lián)約束的不是隨便配的。我在實際排障時遇到“終端能讀到MIB但SIB1一直失敗”的情況第一反應就是去看CORESET#0和Initial BWP的SCS、頻域位置是否對齊。另外Initial DL BWP如果通過SIB1里的initialDownlinkBWP字段顯式配置那么它的帶寬可能會比CORESET#0大。此時PDCCH的公共搜索空間可能只占Initial BWP的一部分但終端做數(shù)據(jù)接收時還是按整個Initial BWP來。這個差異在計算資源占用和速率時需要注意。3. BWP切換三種觸發(fā)方式與信令流程3.1 三種切換方式對比BWP從配置態(tài)變成激活態(tài)或者從一個激活BWP切到另一個激活BWP主要有三種觸發(fā)方式。第一種是RRC重配置觸發(fā)。網(wǎng)絡通過RRCReconfiguration消息里的bwp-Id字段顯式告訴終端切換到哪個BWP。這種方式適合慢速但可靠的場景比如在建立業(yè)務時直接指定工作BWP。第二種是DCI觸發(fā)也叫動態(tài)切換。調度PDCCH里如果有BWP indicator字段終端收到DCI后就知道下一個時隙的工作BWP是哪一個。第三種是定時器回退終端自己在激活BWP上維護一個bwp-InactivityTimer如果超時沒有收到調度就自動回退到Default BWP或Initial BWP。三種方式各有適用場景。RRC切換適合在業(yè)務建立階段一次性把終端放到正確的BWP上DCI切換適合在業(yè)務進行中根據(jù)負載和信道質量動態(tài)調整定時器回退則是純省電兜底機制主要防止終端一直掛在大帶寬BWP上空耗電。觸發(fā)方式信令開銷切換速度主要場景RRC重配置高慢業(yè)務建立、小區(qū)重配DCI動態(tài)切換低快動態(tài)負載均衡、波束切換Inactivity Timer無中無調度時自動省電3.2 DCI觸發(fā)的BWP切換細節(jié)DCI觸發(fā)切換靠的是DCI format 0_1和1_1里的BWP indicator字段。這個字段的比特數(shù)不是固定的取決于RRC給終端配置了幾個BWP。如果只配了1個BWP這個字段是0比特相當于沒這回事配了2個BWP就是1比特配了3到4個BWP就是2比特。終端在某個時隙收到帶BWP indicator的DCI后會在一定時間后切換到目標BWP。協(xié)議對BWP切換是給過時延要求的具體數(shù)值見TS 38.133UE可以通過bwp-SwitchingDelay能力字段上報更短的處理時延。默認情況下FR1下DCI觸發(fā)的BWP切換時延通常按2ms級別理解FR2會短一些。這個時延不是隨便定的因為終端切BWP不是只改一個參數(shù)射頻要調諧到新的頻段位置基帶的FFT、濾波、時頻同步都要重新配置AGC也要重新收斂。切換期間終端是不期望收發(fā)的網(wǎng)絡會把調度避開這個轉換時間窗口。我在抓信令時經(jīng)常見到一種情況BWP切換命令已經(jīng)下了但終端反饋時延比較大導到下一段調度出現(xiàn)了HARQ丟包。這種時候不要急著懷疑終端先看DCI切換時周圍的調度間隔夠不夠再看終端上報的bwp-SwitchingDelay能力值最后再判斷是不是射頻調諧問題。還有一個細節(jié)容易被忽略切換BWP時終端會清空該小區(qū)上所有HARQ進程的緩存。也就是說切換前如果還有沒傳完的重傳數(shù)據(jù)切換動作本身是不會幫你保留這些緩存內容的協(xié)議層就是按清空處理。設計調度策略時如果頻繁做BWP切換可能反而帶來重傳開銷這也是為什么不建議把inactivity timer配得太短。3.3 定時器回退與Default BWPbwp-InactivityTimer的作用是當下行激活BWP上持續(xù)一段時間沒有收到PDCCH調度時終端自動切回Default BWP。這個定時器是在每個下行BWP的配置里單獨下發(fā)的值域從2ms到2000ms不等。這個定時器到底配多長非常考驗優(yōu)化功底。配太短終端稍微空閑幾十毫秒就退回小BWP等下行數(shù)據(jù)一來又要通過DCI切回大BWP切換本身有開銷、有風險吞吐率會受影響。配太長終端在業(yè)務間隙一直守在大帶寬BWP上省電效果就差。實際項目中如果主要業(yè)務是持續(xù)性的大包下行比如視頻流timer可以放寬到100ms以上如果是網(wǎng)頁瀏覽、即時通信這類突發(fā)型業(yè)務timer配短一點反而能明顯提升終端待機續(xù)航。這里補充一個技術細節(jié)bwp-InactivityTimer是在下行BWP上維護的上行BWP沒有獨立的inactivity timer。終端在某個下行BWP上收到PDCCH調度時定時器會重置。而且下行BWP切換時對應的上行BWP也會跟著切到相同ID的BWP上。在TDD系統(tǒng)里這個邏輯很順在FDD系統(tǒng)里就要額外注意UL BWP和DL BWP的ID關聯(lián)并不一定是頻域對齊的。4. BWP與Paging、CA、RedCap等特性的協(xié)同4.1 尋呼消息在哪個BWP上監(jiān)聽很多人做業(yè)務排障時不會把BWP和尋呼聯(lián)系起來但“nr paging”這個場景恰恰和BWP關系很緊。終端在空閑態(tài)或者非活動態(tài)時并不知道當前小區(qū)里其它BWP的詳細配置它只能按照最小化的系統(tǒng)配置去監(jiān)聽尋呼。這個監(jiān)聽位置就落在初始下行BWP上具體來說是Initial BWP上與尋呼相關的公共搜索空間。網(wǎng)絡側在配置尋呼時會在SIB1或者專用信令里下發(fā)尋呼搜索空間的配置位置。空閑態(tài)終端的尋呼PDCCH是用P-RNTI加擾的終端只需要監(jiān)聽每幀里特定的尋呼時機PO和尋呼幀PF其它時間都可以睡這就是“非連續(xù)接收”的省電機制。而一旦進入連接態(tài)如果網(wǎng)絡配置了pagingSearchSpace終端也可能在激活BWP上監(jiān)聽尋呼。這個機制讓終端在連接態(tài)省去了頻繁回到初始BWP的流程但也對調度器提出了更高要求要保證尋呼時機和激活BWP上的SSB、CORESET配置能對得上。站在用戶角度看很多人會問“紅米手機4G和5G怎么自動切換”。手機狀態(tài)欄顯示的4G/5G切換背后涉及的機制遠不止BWP還包括小區(qū)重選、測量上報、切換信令、載波聚合的增刪等。但BWP在其中扮演了很重要的角色當終端在NR小區(qū)內因為信道或負載變化被切到另一個BWP時狀態(tài)欄的5G標識不會變化但實際的調度帶寬、吞吐率和功耗表現(xiàn)都會變。所以做網(wǎng)優(yōu)的人看到“5G信號滿格但速率波動大”這類投訴除了看RSRP很多時候要去看BWP切換的次數(shù)和定時器配置。4.2 載波聚合下的BWP與休眠BWP熱詞里有“nr ca的相關流程”。載波聚合CA下每個小區(qū)都有自己獨立的BWP配置。也就是說主小區(qū)PCell有4個下行BWP、4個上行BWP每個輔小區(qū)SCell也各自有自己的一套BWP。兩者并不沖突但協(xié)同起來復雜度很高。這里要區(qū)分兩個層級的激活/去激活一個是SCell本身的激活去激活另一個是SCell內部BWP的切換。SCell激活后終端并不一定馬上就在這個SCell上傳輸數(shù)據(jù)還要看這個SCell的激活BWP是哪一個。NR從Rel-16開始引入了休眠BWPdormant BWP的概念。一個SCell如果被切到休眠BWP終端不再監(jiān)聽這個SCell的PDCCH也不再接收PDSCH但可以繼續(xù)進行CSI測量維持鏈路狀態(tài)。需要快速使用這個SCell時網(wǎng)絡通過DCI format 1_1里的SCell dormancy指示字段讓終端把SCell從休眠BWP切回正常的激活BWP。這個機制在實際部署中大有用處。一個終端聚合了多個SCell如果所有SCell都保持滿活躍狀態(tài)就算只有少量數(shù)據(jù)終端也得一直監(jiān)聽所有小區(qū)功耗沒法看。有了休眠BWP網(wǎng)絡可以在數(shù)據(jù)量小時把大部分SCell推進休眠態(tài)保留PCell和一個主SCell做調度。等到數(shù)據(jù)量上來了再通過一條DCI快速喚醒其它SCell。這個動作比SCell去激活再激活要快得多也比全量釋放CA配置更平滑。在實際配置時休眠BWP的頻域帶寬往往配得很小只保留必要的CSI-RS和同步信號測量資源。核心點是休眠BWP上不配PDCCH否則終端還是要盲檢省電目的就達不到了。4.3 RedCap和輕量化終端的BWP共存熱詞里有一條“輕量級5G和其他物聯(lián)網(wǎng)連接技術的能力定位對比圖”。RedCap即NR Light輕量級5G是近兩年物聯(lián)網(wǎng)領域關注度比較高的方向。RedCap終端的能力受限FR1下最大只支持20MHz帶寬有些更低成本的終端還只支持半雙工FDD。如果讓RedCap終端接入一個100MHz的eMBB載波怎么辦答案還是BWP。網(wǎng)絡可以在100MHz載波內專門給RedCap終端配置一個或多個帶寬不超過20MHz的BWP并且通過系統(tǒng)消息下發(fā)RedCap專屬的初始BWP。RedCap終端在這個小BWP上完成系統(tǒng)消息讀取、隨機接入和后續(xù)數(shù)據(jù)傳輸而旁邊的eMBB終端繼續(xù)使用大帶寬BWP跑高速率業(yè)務兩者互不打擾。這個思路和LTE時代NB-IoT在LTE載波內做帶內部署非常相似。都是通過頻率資源的切片讓不同能力的終端共存于同一個大載波。區(qū)別在于NR的BWP粒度更細配置更靈活而且RedCap專屬初始BWP和普通eMBB的初始BWP可以在同一個SIB里下發(fā)接入流程本身也和普通NR終端高度一致。從網(wǎng)絡優(yōu)化角度看RedCap終端占用的BWP如果和eMBB的大帶寬BWP重疊要做好干擾協(xié)調和調度優(yōu)先級區(qū)分。我的建議是盡量把RedCap的BWP配置在載波邊緣并在PDCCH資源上做分開配置避免RedCap的公共控制信道占用eMBB的關鍵資源。4.4 BWP與波束管理、測量的關系BWP還和波束管理、RRM測量有千絲萬縷的聯(lián)系。在FR2毫米波場景下終端收發(fā)數(shù)據(jù)依賴波束。BWP切換時終端的工作頻率范圍變了TCI狀態(tài)傳輸配置指示狀態(tài)也可能需要更新因為新的BWP上可能關聯(lián)了不同的CSI-RS資源和波束方向。對網(wǎng)絡側來說測量資源配置也要跟著BWP走。比如CSI-RS資源是配置在某個BWP內的終端只有在這個BWP上工作才能對該資源做測量。如果調度器把終端切到一個沒有對應CSI-RS的BWP上鏈路自適應就會失去輸入MCS選擇只能靠兜底策略速率和誤碼率都會受影響。RRM測量也有類似約束。終端要做鄰區(qū)測量時通常需要測量SSB而SSB不一定和當前激活BWP在同一個頻域位置。終端需要利用測量gap去調整射頻、跳到SSB所在的頻段完成測量再跳回來。在配置BWP時如果SSB和BWP的位置切割得很碎可能會導致測量gap不夠用切換和重選都出現(xiàn)問題。5. 一個實際小區(qū)的BWP配置示例與優(yōu)化經(jīng)驗5.1 100MHz小區(qū)配置兩個BWP的實例下面用一個典型的FR1場景來演示BWP配置邏輯。假設一個TDD NR小區(qū)部署在n41或者n78/n79頻段總帶寬100MHz子載波間隔采用30kHz。100MHz在30kHz SCS下去掉保護帶后可以使用的PRB數(shù)是273個。Point A在載波最低頻處。網(wǎng)絡規(guī)劃時想做到兩點一是讓普通eMBB終端能用大帶寬跑高速率二是讓低成本終端和部分物聯(lián)網(wǎng)終端用20MHz小帶寬接入并工作。于是劃分兩個下行BWP參數(shù)DL BWP#1DL BWP#2角色Active/Default BWP大帶寬eMBB BWPstartPRB021lengthPRB數(shù)51252SCS30kHz30kHzCORESET配置專用CORESET配置專用CORESETbwp-InactivityTimer不適用100ms適用場景RedCap/低能力終端高速率eMBB終端這里DL BWP#1就是20MHz帶寬51個PRB在30kHz SCS下約等于20MHz給RedCap和普通低速終端共同使用。DL BWP#2從PRB 21開始一直到PRB 272覆蓋剩余約99MHz的頻域資源普通eMBB終端激活在這個BWP上工作。兩個BWP之間刻意留出一個PRB的間隙主要為了降低邊界處的鄰道干擾和實現(xiàn)復雜度。上行BWP的配置可以采取類似思路。但上行要注意PUCCH資源的規(guī)劃。如果UL BWP#1是給RedCap終端用的PUCCH資源要放在這個BWP的低頻段并預留足夠的PUCCH格式1/2資源給SR、CSI和HARQ反饋。UL BWP#2給eMBB終端PUCCH資源和高容量PUSCH資源要分開規(guī)劃。Initial BWP的配置則從SIB1下發(fā)建議頻率位置和DL/UL BWP#1保持一致或者完全覆蓋BWP#1的范圍這樣RedCap終端從初始接入到業(yè)務建立不需要做額外的BWP切換。5.2 配置BWP時容易踩的坑我先列幾個在現(xiàn)場反復遇到過的配置問題每一個都耽誤過不少排查時間。第一個坑是CORESET#0和Initial BWP的SCS不一致。有的同事為了提升SIB1的覆蓋把CORESET#0配成了15kHz但Initial BWP的數(shù)據(jù)調度SCS是30kHz結果終端接入后第一版SIB1能讀后續(xù)RRC消息經(jīng)常失敗。原因是公共搜索空間和專用搜索空間的時頻資源不在同一個“世界觀”里終端盲檢混亂。解決方法是盡量保持CORESET#0和Initial BWP的SCS一致或者按協(xié)議約束的組合去配置。第二個坑是bwp-InactivityTimer配太短。某次外場測試下行灌包速率總是周期性掉坑波形圖上每過幾百毫秒就出現(xiàn)一次低谷。排到最后發(fā)現(xiàn)是定時器配了10ms終端稍微空閑一個PDCCH周期就掉回Default BWP下一包數(shù)據(jù)又得切回大BWP一來一回就是大幾毫秒吞吐率自然上不去。最后把timer從10ms調到100ms問題立刻消失。第三個坑是激活的UL BWP沒有PUCCH資源。這種問題多出現(xiàn)在FDD站因為DL BWP和UL BWP獨立配置很容易出現(xiàn)“DL BWP切換成功了但對應ID的UL BWP上沒配PUCCH”的情況。終端需要反饋HARQ時發(fā)現(xiàn)沒有PUCCH可用只能走隨機接入流程去申請資源調度時延瞬間變大。配置時一定記得檢查每個可能被激活的UL BWP是否都配置了足夠的PUCCH資源。第四個坑是DCI大小沒對齊。NR為了避免終端盲檢太多DCI大小要求相同RNTI類型的DCI盡可能做size alignment。問題是不同BWP上因為資源指示字段的位數(shù)可能不同DCI大小天然會不一樣。如果不做padding對齊終端盲檢次數(shù)會上升PDCCH解調成功率直接下降。這在配置多BWP的小區(qū)時尤其容易忽略。第五個坑是PDSCH/PUSCH調度資源超出了激活BWP的范圍。調度器計算資源塊分配時如果用錯了參考點把RB分配到了BWP邊界之外終端會認為調度無效直接把整個調度丟棄。這類問題在動態(tài)BWP切換后更容易出現(xiàn)因為調度器內部有的模塊還停留在舊BWP的配置上。排查思路是核對DCI里的頻域資源分配字段是否基于當前激活BWP的PRB編號。5.3 優(yōu)化配置的個人心得從我個人經(jīng)驗看BWP配置沒有一套放之四海而皆準的模板但有幾條原則值得參考。第一明確業(yè)務模型再定BWP數(shù)量。如果小區(qū)主要跑eMBB大包業(yè)務兩個BWP就夠用了一個高速率大帶寬BWP一個低速率兜底/初始BWP。如果小區(qū)要同時承載RedCap終端、工業(yè)URLLC和普通手機業(yè)務BWP數(shù)量可以增加到3到4個但每個BWP的資源要分開規(guī)劃控制信道也要盡量隔離。第二Inactivity timer的調整要結合業(yè)務特征。持續(xù)性下載類業(yè)務timer放寬一些比如100ms到200ms突發(fā)型小包業(yè)務比如即時通信和心跳類timer可以降到20ms到50ms。要注意的是timer改變后要觀察BWP切換次數(shù)和用戶感知速率的變化不要只看省電效果。第三BWP切換和SCell休眠要聯(lián)合起來看。在CA場景下與其頻繁切換PCell上的BWP不如讓數(shù)據(jù)盡量集中在一個SCell上其余SCell進入休眠BWP。這樣既保證了吞吐又避免了主小區(qū)的控制信道壓力過大。我見過不少項目把SCell的BWP切換配得比休眠機制還活躍結果控制信令開銷和測量開銷都上去了反而得不償失。第四做信令跟蹤時要注意BWP相關的IE字段。看5G信令時重點觀察RRCReconfiguration里的BWP配置、DCI里的BWP indicator、UE上報的bwp-SwitchingDelay能力值基本就能判斷BWP側的一切問題。千萬不要只看RSRP和SINR那只能說明無線環(huán)境反映不了BWP分配和切換的效率。6. 常見問題與排查思路實錄6.1 終端能力上報和網(wǎng)絡配置不匹配遇到過不少情況網(wǎng)絡側明明配置了4個BWP但終端始終只在一個BWP上工作。抓信令一看終端上報的UE能力里帶寬能力或者支持的BWP數(shù)量組合和網(wǎng)絡配置不一致。協(xié)議里有一個“BWP組合”的概念終端上報支持的DL BWP和UL BWP組合后網(wǎng)絡配置不能超出這個組合范圍。排查方法很簡單讓終端把UE能力上報完整打出來重點看bandwidthClass和bwp-SwitchingDelay這兩項再和網(wǎng)管配置表一一對照。如果確實存在不匹配優(yōu)先調整網(wǎng)絡配置適配終端能力而不是反向操作。6.2 接入后無法從Initial BWP切到業(yè)務BWP終端接入一切正常但始終停留在Initial BWP上下行速率始終提不上去。這類問題通常出在DCI切換這個環(huán)節(jié)。可能的原因包括BWP indicator字段長度配置錯誤、目標BWP上沒有配置CORESET/搜索空間、或者切換時隙和目標BWP上的SSB時機沖突。建議在配置完成后先做一個靜態(tài)校驗把每個BWP的CORESET、搜索空間、PDCCH資源、PUCCH資源、CSI-RS資源逐項列出來確保任何一個BWP被激活時終端都有可用的下行控制信道和上行反饋信道。這個校驗做完大部分DCI切換問題都能提前暴露。6.3 用戶反饋5G速率低BWP和CA先查哪個速率類投訴是網(wǎng)優(yōu)最常遇到的。我的排查順序是先看終端當前激活BWP的帶寬和SCS確認是不是被回退到了小帶寬BWP再看有沒有配置CA以及SCell是否激活最后再看調度相關的MCS、RB數(shù)、誤碼率等。這里有一個很典型的錯誤排查方式一上來就去查CA、查調度RB數(shù)結果發(fā)現(xiàn)都是滿的但忘了看激活BWP本身只有20MHz帶寬。BWP帶寬直接決定了理論峰值速率上限這個不先排查清楚后面所有分析都會跑偏。6.4 關于避免BWP故障的幾點建議結合這幾年做BWP相關工作的經(jīng)驗我想給幾個比較實在的建議。一是配置前畫一張頻域規(guī)劃圖。把SSB、CORESET#0、Initial BWP、各數(shù)據(jù)BWP、PUCCH資源、CSI-RS資源全部畫在同一個頻域坐標系里標清楚各自的起止PRB和SCS。這張圖畫完90%以上的頻域沖突問題都能看出來。二是把BWP切換次數(shù)做成小區(qū)級關鍵指標。BWP切換本身不是壞事但如果切換過于頻繁就說明BWP劃分或者timer配置不合理。可以按小時粒度統(tǒng)計每用戶的BWP切換次數(shù)結合平均吞吐率和用戶體驗速率一起看很容易定位到配置問題。三是升級協(xié)議版本時重新核對BWP配置。NR協(xié)議每個大版本都有演進比如SCell休眠BWP是Rel-16引入的RedCap相關的BWP配置是Rel-17引入的。網(wǎng)絡升級后老配置未必能支持新特性新特性也可能和老配置沖突。每次版本升級后做一輪BWP配置一致性檢查能省去不少后續(xù)排障時間。BWP看著是個小概念但它牽動的面非常廣。從終端省電、調度效率、尋呼監(jiān)測到載波聚合、RedCap共存再到波束管理每個環(huán)節(jié)都有BWP的影子。我個人在實際操作中最深的體會是BWP相關的問題往往不是“某一個參數(shù)配錯”而是“多個參數(shù)之間的協(xié)同關系沒理清”。把頻域規(guī)劃圖先畫對再結合信令流程逐項核對大多數(shù)BWP問題都能在配置階段提前消滅而不是等到外場測試時被用戶投訴牽著走。