1. 為什么要在ORAN里談NB-IoT下行鏈路1.1 傳統(tǒng)基站和ORAN在NB-IoT上的本質(zhì)區(qū)別先說結(jié)論傳統(tǒng)一體化基站的NB-IoT功能是綁定在廠商私有協(xié)議棧里的。你想在一個現(xiàn)網(wǎng)LTE小區(qū)上疊加一個窄帶物聯(lián)網(wǎng)NB-IoT載波通常要聯(lián)系設備商開通license、升級版本、甚至更換基帶板。整個過程是黑盒操作運營商和集成商能改的參數(shù)極其有限出了問題也只能提交工單給原廠。而ORANOpen RAN把無線接入網(wǎng)拆成O-CU、O-DU、O-RU三個部分內(nèi)部接口和協(xié)議流程都是開放的基帶處理邏輯變成可加載的軟件模塊射頻單元變成可按標準對接的通用硬件。這讓在ORAN框架里啟用NB-IoT下行鏈路從一句口號變成了一個可執(zhí)行、可排查、可優(yōu)化的工作流。這個工作流的第一站就是下行鏈路。原因很直接NB-IoT終端上電后必須先從基站側(cè)獲得同步信號、系統(tǒng)信息和下行控制消息才能發(fā)起隨機接入、建立RRC連接、附著到核心網(wǎng)。如果下行鏈路沒打通終端連小區(qū)都搜不到后面的上行傳輸、業(yè)務數(shù)據(jù)、OTA升級全都是空談。在ORAN架構(gòu)里下行鏈路要經(jīng)過O-DU側(cè)的基帶信號處理、eCPRI前傳封裝、O-RU側(cè)的射頻發(fā)射三個環(huán)節(jié)任何一個環(huán)節(jié)配置失誤都會導致終端無法駐網(wǎng)。1.2 下行鏈路啟用具體指的是什么做一個不嚴謹?shù)美斫獾念惐劝袾B-IoT小區(qū)當成一棟樓的入戶水管下行鏈路就是水從水泵O-DU流到水龍頭O-RU天線口的整個過程。開啟下行鏈路不僅要讓水泵啟動還要確認管道接頭前傳接口沒有漏水水龍頭射頻前端真的能噴出水來最后住戶NB-IoT終端打開龍頭能接到水。落到具體技術(shù)上這件事包含四層工作第一層在O-DU軟件棧里使能NB-IoT小區(qū)配置頻點、帶寬、物理信道參數(shù)第二層把NB-IoT的OFDM基帶信號映射到正確的資源塊位置并生成eCPRI前傳IQ數(shù)據(jù)第三層在O-RU側(cè)完成數(shù)字上變頻、D/A轉(zhuǎn)換、功率放大和天線發(fā)射第四層通過O-CU和核心網(wǎng)完成小區(qū)激活流程讓終端能夠完成附著。這篇文章會圍繞這四層展開覆蓋原理、配置、驗證和常見問題。1.3 這個內(nèi)容適合誰看我想把讀者分成三類。第一類是正在做ORAN系統(tǒng)集成、無線協(xié)議開發(fā)或NB-IoT物理層調(diào)試的工程師你們需要的是一份能直接指導配置和排障的實操參考。第二類是運營商網(wǎng)絡規(guī)劃或行業(yè)項目負責人你們關(guān)心的是在現(xiàn)有ORAN站點上疊加NB-IoT需要投入多少成本、有哪些參數(shù)坑、能承載什么業(yè)務。第三類是物聯(lián)網(wǎng)平臺和應用開發(fā)者你們不一定要摳物理層細節(jié)但需要理解NB-IoT下行鏈路在真實網(wǎng)絡里的性能邊界避免把應用需求設計得超過網(wǎng)絡實際承載能力。2. 下行鏈路在ORAN框架下的整體設計思路2.1 為什么實際項目里要先調(diào)下行、再調(diào)上行我在多個ORAN集成項目里發(fā)現(xiàn)一個現(xiàn)象團隊拿到新站點很多工程師會先做上行的頻譜掃描因為上行信號一發(fā)射頻譜儀立刻能看到譜線有種立竿見影的快感。但從交付順序看下行鏈路必須先做通。NB-IoT終端的行為邏輯是先盲搜NPSS窄帶主同步信號建立時頻同步再解NSSS獲取幀邊界和小區(qū)ID然后讀NPBCH拿到MIB-NB最后才發(fā)起隨機接入。這一整套流程走通之前上行方向根本不會有終端信號。所以下行鏈路啟用的第一道關(guān)卡不是把功率打開就完了而是確保終端能從空口穩(wěn)定地讀到廣播消息。具體到ORAN環(huán)境里這要求O-DU配置的同步信號序列、廣播信道編碼和資源映射必須嚴格符合3GPP TS 36.211/36.212/36.213規(guī)范生成的IQ數(shù)據(jù)經(jīng)過前傳接口到達O-RU后不能有幅度異常、相位翻轉(zhuǎn)或天線端口映射錯位。2.2 從O-DU到O-RU的完整鏈路拆解我習慣把NB-IoT下行鏈路拆成六個節(jié)點來調(diào)試這樣定位問題時不至于手忙腳亂比特級處理傳輸塊經(jīng)過CRC附加、信道編碼R13用Turbo碼、速率匹配后變成下行編碼比特流。符號級處理編碼比特經(jīng)過加擾、QPSK/16QAM調(diào)制、層映射和預編碼生成OFDM符號。資源映射OFDM符號按協(xié)議規(guī)定的時頻位置填入子載波包括NPSS/NSSS/NPBCH/NPDCCH/NPDSCH等所有下行物理信號。OFDM基帶生成通過IFFT把頻域符號變換為時域IQ波形加入循環(huán)前綴形成1.92MHz采樣率的標準基帶流。前傳封裝O-DU把IQ樣本按eCPRI協(xié)議打包成數(shù)據(jù)流通過光纖發(fā)給O-RU。射頻發(fā)射O-RU完成數(shù)字上變頻、濾波、放大將信號通過天線發(fā)射出去。這六個節(jié)點里前三個屬于O-DU軟件棧第四個是數(shù)字信號處理核心第五個是ORAN特有環(huán)節(jié)第六個屬于O-RU硬件范圍。調(diào)試NB-IoT下行鏈路時你手里的工具鏈應該是協(xié)議分析儀抓前傳包、頻譜儀看天線口波形、終端日志看解調(diào)結(jié)果三者對照才能快速定位問題節(jié)點。2.3 為什么在ORAN場景下NB-IoT是優(yōu)于LoRa的選型很多做行業(yè)物聯(lián)網(wǎng)的朋友會問既然有LoRa和Sigfox這些低功耗廣域網(wǎng)技術(shù)為什么還要折騰ORAN加NB-IoT我的回答是LoRa和Sigfox需要獨立部署網(wǎng)關(guān)和基站設備對于已經(jīng)擁有LTE網(wǎng)絡的運營商或大企業(yè)園區(qū)這是個額外的硬件投資和運維負擔。而NB-IoT天然寄生在LTE生態(tài)里利用現(xiàn)網(wǎng)站點的供電、天饋、傳輸和核心網(wǎng)只需在軟件層面開通一個180kHz的窄帶載波就能提供服務。ORAN進一步放大了這個優(yōu)勢。傳統(tǒng)廠商的一體化基站里NB-IoT的軟件模塊和物理資源綁定得比較死擴容或調(diào)整參數(shù)都要走廠商流程。ORAN環(huán)境下O-DU軟件是模塊化的你可以像一個獨立的NB-IoT小區(qū)一樣配置它也可以動態(tài)調(diào)整它在LTE帶寬內(nèi)的資源位置這種靈活性在規(guī)模部署和后期優(yōu)化中非常實用。3. 下行鏈路啟用需要摸透的四個核心配置塊3.1 部署模式與頻點規(guī)劃配置NB-IoT下行鏈路第一步是確定部署模式。三種模式的區(qū)別要搞清楚部署模式位置說明關(guān)鍵約束Standalone獨立載波典型場景是重耕GSM頻段需保證與鄰頻系統(tǒng)間的保護間隔載波帶寬180kHzGuard-band位于LTE頻譜邊緣的保護帶內(nèi)保護帶寬度要足夠容納180kHz載波不能超出LTE總帶寬In-band位于LTE帶寬內(nèi)部占用一個PRBPRB位置不能與LTE同步信號、CRS、系統(tǒng)信息沖突實際項目中ORAN站點上用得最多的是In-band模式。原因很簡單很多運營商只是想在已經(jīng)運營的LTE宏站上疊加物聯(lián)網(wǎng)能力不希望額外申請頻譜。In-band模式配置時要特別驗證兩件事一是NB-IoT的PRB必須位于LTE的100kHz信道柵格上二是這個PRB不能被LTE的PSS/SSS、PBCH或SIB1占用。我見過一個項目把NB-IoT的PRB配在LTE的PSS附近結(jié)果兩個系統(tǒng)的同步信號互相干擾LTE用戶掉線率和NB-IoT接入失敗率同時飆升排查了整整兩天才定位到是資源沖突。3.2 物理信道與調(diào)制編碼配置NB-IoT下行鏈路的物理信道分為同步信號和業(yè)務信道兩大類每類信道的配置思路完全不同。同步和廣播信道包括NPSS、NSSS、NPBCH。這三個信道在協(xié)議里都有固定的時頻位置不需要做復雜參數(shù)規(guī)劃。NPSS固定位于每個子幀5的最后11個OFDM符號NSSS位于偶數(shù)號無線幀的子幀9NPBCH位于每個無線幀的子幀0攜帶MIB-NB。啟用時只需保證小區(qū)ID配置正確、O-DU軟件實現(xiàn)符合3GPP規(guī)范即可?？刂菩诺篮蛿?shù)據(jù)信道包括NPDCCH和NPDSCH這兩個才是配置的重點。NPDCCH承載下行控制信息DCI需要配置聚合等級和搜索空間。NPDSCH承載用戶數(shù)據(jù)和系統(tǒng)消息需要配置調(diào)制方式和傳輸塊大小。在低信噪比的深度覆蓋場景下這兩個信道都必須支持重復發(fā)送Repetition最大重復次數(shù)甚至可以達到2048次。重復次數(shù)開得越大覆蓋能力越強但空口資源消耗也越大。一個常見的調(diào)優(yōu)思路是近點用戶用小重復次數(shù)保證速率遠點用戶用大重復次數(shù)保證接入。調(diào)制編碼方面R13版本的NB-IoT下行只支持QPSKR14以后才支持16QAM。實際部署中絕大多數(shù)網(wǎng)絡還是以QPSK為主因為NB-IoT終端的設計目標是低成本、低功耗芯片對高階調(diào)制的支持會增加成本和功耗。設計業(yè)務時如果你指望NB-IoT跑視頻或大流量數(shù)據(jù)那從一開始就選錯了方向。3.3 功率配置與射頻校準功率配置是下行鏈路里最容易被低估的一項。NB-IoT信號只占180kHz帶寬同樣發(fā)射功率下的功率譜密度PSD遠高于20MHz帶寬的LTE信號。這意味著如果你用LTE小區(qū)的Pmax作為參考去設置NB-IoT小區(qū)的最大發(fā)射功率NB-IoT的PSD會比LTE高約20dB對鄰頻造成的干擾是災難性的。實際配置時我建議先計算NB-IoT小區(qū)允許的最大PSD然后反向推算最大發(fā)射功率。舉個例子如果LTE小區(qū)額定功率為40W約46dBm且占用20MHz帶寬它的PSD約為13dBm/180kHz46-73dB。NB-IoT要想不產(chǎn)生額外干擾其最大發(fā)射功率通常應該控制在20dBm左右13dBm/180kHz加上一些合理的覆蓋增強余量。當然這只是參考值具體要看運營商頻段隔離要求和你對覆蓋半徑的預期。O-RU側(cè)還有一個容易踩的坑通帶增益校準。因為NB-IoT載波很窄O-RU的射頻鏈路如果在校準時只測了寬帶LTE頻段的平坦度180kHz窄帶位置的增益可能偏離預期。建議在啟用NB-IoT后用頻譜儀實測天線口的參考信號功率與O-DU配置的目標功率做對比偏差超過1dB就要檢查O-RU的校準表。3.4 前傳接口與同步設置前傳接口是ORAN架構(gòu)特有的環(huán)節(jié)傳統(tǒng)基站沒有這個配置項。O-DU和O-RU之間通過eCPRI協(xié)議傳輸IQ數(shù)據(jù)對于NB-IoT小區(qū)需要確認三件事采樣率、IQ位寬和壓縮方式。采樣率方面一個180kHz的NB-IoT載波在1.92MHz采樣率下就能完整表示這也是ORAN標準里支持的采樣率檔位之一如果NB-IoT和LTE共享前傳帶寬采樣率可能要提高到7.68MHz或15.36MHz對應的前傳帶寬占用會翻倍。同步方面NB-IoT下行對O-DU和O-RU之間的時間頻率同步精度有明確要求。采用IEEE 1588v2G.8275.1協(xié)議做時間同步頻率精度應達到±1.5ppm以內(nèi)否則UE解調(diào)時會出現(xiàn)持續(xù)性頻偏。我在調(diào)試時習慣用一臺高精度頻譜儀直接看O-RU的發(fā)射載波頻率與理論中心頻點的偏差如果偏差超過100Hz優(yōu)先懷疑同步鏈路而不是NB-IoT基帶算法。4. 實操流程從配置到終端上線的完整步驟4.1 動手前的軟件棧與版本檢查不夸張地講ORAN環(huán)境里項目延期的最常見原因不是硬件問題而是軟件棧能力不匹配。真正開始配置NB-IoT之前我會先做一輪版本檢查O-DU軟件是否包含NB-IoT物理層功能模塊。開源協(xié)議棧里srsRAN較新版本對NB-IoT有一定支持商用協(xié)議棧通常通過license或功能開關(guān)控制確認前提是功能確實可用。O-RU固件是否支持待部署頻段。尤其要注意很多白盒O-RU只支持LTE/5G NR的常用頻段對NB-IoT常用的B1/B3/B5/B8/B20頻段支持情況不一。核心網(wǎng)側(cè)是否已配置好NB-IoT相關(guān)能力包括AMF/MME上的接入限制、TATracking Area配置、DRX參數(shù)等。這個階段花10分鐘做檢查能省掉后面兩天的排障時間。我用這個習慣排查出過多次功能沒買或頻段不支持的問題都是在還沒上站的情況下就提前暴露了風險。4.2 NB-IoT小區(qū)參數(shù)配置示例下面是一份我在實際項目中常用的O-DU配置片段做了脫敏處理。不同商用產(chǎn)品的字段名有差異但核心參數(shù)是通用的nb_iot: enable: true cell_id: 42 operation_mode: inband # 帶內(nèi)部署 earfcn: 2600 # 下行頻點由部署頻段決定 target_prb: 6 # 占用的LTE PRB位置需避開SSB/CRS downlink: npss_power_offset: 0 # 同步信號功率偏移通常為0 npbch_power_offset: 0 npdcch_power_offset: 3 # 控制信道相對功率3dB npdsch_power_offset: 3 # 數(shù)據(jù)信道相對功率3dB max_repetition: 2048 # 最大重復次數(shù) antenna_ports: 1 sampling_rate: 1920000 # 1.92MHz采樣率 plmn_id: 46000 # PLMN標識這里有兩個參數(shù)要特別提醒。第一是target_prb它不能只看LTE的PRB總數(shù)還要結(jié)合LTE的CRS端口數(shù)和SSB配置來綜合判斷。第二是plmn_idORAN架構(gòu)下O-DU和O-CU對PLMN的配置是分層設置的配置不匹配會導致終端搜到小區(qū)卻讀不出系統(tǒng)信息。有一個小技巧正式配置前先在實驗室用srsRAN或類似工具做一次離線仿真驗證你選的PRB位置與LTE參考信號的相對位置關(guān)系能極大減少上站后的試錯次數(shù)。4.3 空口信號驗證與終端附著測試配置寫完并不代表下行鏈路已經(jīng)啟用成功必須經(jīng)過實際驗證才敢確認。我的標準驗證流程分為四步第一步頻譜儀掃天線口。在O-RU天線口用頻譜儀觀察應該能看到一個帶寬約180kHz的窄帶信號尖峰中心頻率與你配置的earfcn一致。如果信號整體偏移了幾百赫茲查頻率同步如果信號功率遠低于預期查功率配置和O-RU校準。第二步信號分析儀解調(diào)同步信道。使用支持NB-IoT的信號分析工具如Keysight或RS的測試軟件抓取NPSS和NSSS的時頻位置驗證同步信號的發(fā)送周期和物理小區(qū)ID是否正確。第三步真實終端小區(qū)搜索。用NB-IoT模組比如移遠BC95或BC260Y做主掃測試觀察終端能否讀到PLMN、駐留到目標小區(qū)。這一步能同時驗證下行鏈路和系統(tǒng)信息廣播是否完整。第四步完整附著測試。終端發(fā)起Attach流程觀察核心網(wǎng)側(cè)是否收到附著請求MME/AMF是否返回注冊成功。這一步如果卡住問題多半不在無線鏈路而在核心網(wǎng)配置或鑒權(quán)參數(shù)。4.4 判斷下行鏈路質(zhì)量的標準我給項目做驗收時會盯三個量化指標。第一是RSRP參考信號接收功率建議在指定覆蓋點RSRP大于-110dBm第二是SINR信噪比建議大于-3dB這是NB-IoT解調(diào)NPDSCH的可接受底限第三是附著成功率在滿足前兩個指標的區(qū)域附著成功率應達到99%以上。如果RSRP達標但SINR很低要檢查是否受到同類頻段干擾或本小區(qū)過覆蓋。5. 實際應用場景與部署建議5.1 智能表計最成熟也最剛需的場景智能水表、電表和燃氣表是NB-IoT下行鏈路最典型的應用。這類設備的通信特點是下行消息極少、上行數(shù)據(jù)也極小、大部分時間處于休眠狀態(tài)、但要求極深的室內(nèi)覆蓋。很多水表電表安裝在樓道角落、地下室或金屬表箱內(nèi)傳統(tǒng)2G信號根本穿不透LoRa在城區(qū)也容易被建筑遮擋。NB-IoT的深度覆蓋能力單小區(qū)覆蓋半徑可達數(shù)公里且能穿透多堵墻體正好命中這個需求。在ORAN架構(gòu)下部署智能表計的額外優(yōu)勢是復用站點資源。一個城市的現(xiàn)有LTE宏站只要部分開通NB-IoT功能就能形成覆蓋全城的窄帶物聯(lián)網(wǎng)絡不需要像LoRa那樣單獨規(guī)劃網(wǎng)關(guān)布點。我參與過的某水務公司項目就是在現(xiàn)有ORAN宏站上疊加了NB-IoT小區(qū)終端直接接入運營商核心網(wǎng)后臺云平臺通過運營商網(wǎng)絡接口統(tǒng)一管理整體建設周期比單獨建設一張專用LPWAN網(wǎng)絡縮短了至少一半。5.2 智慧農(nóng)業(yè)與廣域環(huán)境監(jiān)測農(nóng)業(yè)場景和其他物聯(lián)網(wǎng)場景最大的區(qū)別是覆蓋范圍廣、站點分散、供電困難。土壤濕度傳感器、水位監(jiān)測器、氣象站分布在野外很多設備只能靠電池供電期望壽命5到10年。NB-IoT的低功耗特性配合PSM省電模式和eDRX擴展非連續(xù)接收機制可以讓終端大部分時間處于休眠狀態(tài)只在需要上報數(shù)據(jù)時短暫醒來。下行鏈路在這種場景里的主要作用是參數(shù)配置和下行業(yè)務指令。例如農(nóng)業(yè)云平臺需要調(diào)整某一站點的土壤濕度上報閾值可以通過NB-IoT下行鏈路給終端下發(fā)配置消息。ORAN網(wǎng)絡的優(yōu)勢在于農(nóng)業(yè)園區(qū)如果已經(jīng)有LTE覆蓋物聯(lián)網(wǎng)功能就能即時開通同時上行數(shù)據(jù)也能通過同一通道回傳到平臺網(wǎng)絡規(guī)劃簡單清晰。5.3 資產(chǎn)追蹤與智慧物流資產(chǎn)追蹤對移動性支持有要求。傳統(tǒng)的室內(nèi)定位方案需要專用基站LoRa雖然也能做廣域覆蓋但移動切換能力偏弱。NB-IoT繼承了LTE的移動性管理機制支持小區(qū)重選和切換在園區(qū)、港口、倉儲等有多個ORAN站點的區(qū)域標簽設備可以平滑移動并在不同小區(qū)間完成重選下行鏈路定期給標簽下發(fā)追蹤參數(shù)和喚醒指令實現(xiàn)低成本資產(chǎn)監(jiān)控。實際項目中需要注意資產(chǎn)標簽的小型化會限制電池容量下行鏈路的重復次數(shù)過高會顯著增加終端耗電。要平衡覆蓋增強和功耗可控這兩個目標建議在每個站點配置兩個小區(qū)場景模板一個用于常規(guī)覆蓋場景重復次數(shù)低、功耗低另一個用于惡劣覆蓋場景重復次數(shù)高、功耗高由平臺根據(jù)終端上報位置按需調(diào)整。5.4 智能停車與市政設施運維地磁車位檢測器、路燈控制器、垃圾桶滿溢傳感器這類市政設施特點是數(shù)量巨大、單體極簡、常被遮擋。一個中型城市可能要部署數(shù)萬個檢測器如果采用人工定期巡檢運維成本非常高昂。NB-IoT下行鏈路可以完成遠程批量配置和固件升級比如在凌晨低業(yè)務時段統(tǒng)一推送停車平臺算法更新幾分鐘內(nèi)完成全部終端升級。部署層面市政場景往往利用運營商現(xiàn)有ORAN宏站的覆蓋采用In-band模式疊加NB-IoT載波不需要新增站點。不過市政密集區(qū)域的無線環(huán)境復雜同一站點可能同時承載LTE、NB-IoT和未來5G NR的多系統(tǒng)信號要做好射頻隔離和天線端口規(guī)劃避免多系統(tǒng)間的互調(diào)干擾。6. 常見問題與排障速查6.1 下行有輸出信號但終端始終搜不到小區(qū)先別急著懷疑終端按這個順序排查。第一步查O-RU發(fā)射開關(guān)和射頻通道映射看發(fā)射通道是否處于使能狀態(tài)第二步用頻譜儀確認天線口信號的中心頻點是否與配置一致窄帶信號偏移幾百kHz是肉眼看不出來的但終端無法完成粗同步第三步抓eCPRI前傳包確認O-DU下發(fā)的IQ數(shù)據(jù)確實在正確的天線端口上被封裝和轉(zhuǎn)發(fā)。這三級排查能覆蓋90%的搜不到小區(qū)問題。6.2 終端顯示有信號但讀不到PLMN這個現(xiàn)象通常指向系統(tǒng)信息塊的內(nèi)容錯誤或調(diào)度異常。檢查O-CU下發(fā)的SIB1-NB確認PLMN ID、小區(qū)禁止狀態(tài)、TAC等字段是否正確。另一個常見原因是NB-IoT的SI調(diào)度周期和相鄰LTE小區(qū)的SIB1調(diào)度在時域上發(fā)生沖突導致終端無法正確解碼?，F(xiàn)象表現(xiàn)為終端在某個位置能偶爾讀到PLMN但很快又丟失。解決方法是調(diào)整NB-IoT系統(tǒng)信息的調(diào)度周期避開LTE高負載時段。6.3 附著請求持續(xù)被核心網(wǎng)拒絕核心網(wǎng)返回拒絕時先看拒絕原因值。如果返回cause #7非法終端查SIM卡簽約狀態(tài)和IMEI白名單如果返回cause #15無合適的小區(qū)通常是TA與核心網(wǎng)配置不一致或者在NB-IoT專用TA和普通LTE TA之間發(fā)生了混淆。ORAN架構(gòu)下還要特別確認O-DU通過NG/S1接口上報的PLMN列表與核心網(wǎng)配置完全一致任何一位不對都會直接影響附著流程。6.4 In-band模式下的LTE與NB-IoT互干擾這種干擾比較隱蔽。表象是LTE網(wǎng)絡某些低流量時段出現(xiàn)UE測量報告抬高或誤碼率升高同時NB-IoT附著成功率下降。根因通常是NB-IoT的PRB位置與LTE的高干擾敏感信道如PDCCH、PUCCH重疊或者NB-IoT發(fā)功率偏高導致覆蓋區(qū)內(nèi)LTE終端接收質(zhì)量受損。排查思路先在LTE側(cè)拉各PRB的干擾統(tǒng)計看干擾是否集中在NB-IoT所在PRB附近再降低NB-IoT功率偏移觀察干擾是否減弱。如果調(diào)整無效就要考慮把NB-IoT載波遷移到LTE低負載或邊緣PRB上。6.5 老終端無法在小區(qū)邊緣接入NB-IoT覆蓋分為CE Level 0/1/2三個等級不同等級對應不同的重復次數(shù)和MCS上限。老款終端往往只支持CE Level 0/1當你把下行鏈路的重復次數(shù)配置到CE Level 2的范圍后老終端的盲檢能力跟不上會出現(xiàn)近點正常、遠點差的割裂現(xiàn)象。建議在驗收時準備一批覆蓋不同CE等級和不同芯片方案的終端做一致性測試不要只用一個最新款模組代表所有用戶設備。這個經(jīng)驗我反復提因為確實太容易踩坑了。7. 實操心得與避坑建議7.1 前傳抓包是下行鏈路不可或缺的照妖鏡ORAN架構(gòu)里O-DU內(nèi)部處理的正確性很難從外部直接判斷eCPRI前傳接口是觀察O-DU輸出質(zhì)量的唯一窗口。我第一次排查NB-IoT下行信號異常時花了大半天檢查O-DU配置和O-RU功率后來才發(fā)現(xiàn)問題出在O-DU的IQ增益配置比預期低了6dB導致發(fā)射信號功率不足。如果沒有對前傳包的實時解析這個bug可能又要拖兩天才暴露。從那以后我團隊的所有ORAN項目都會準備一套前傳抓包工具作為配置變更前后的基線參照。7.2 功率譜密度折算不能憑感覺之前提到NB-IoT窄帶的PSD問題這里再強調(diào)一遍。在商用網(wǎng)絡中頻譜資源和干擾控制是非常敏感的。NB-IoT載波的最大發(fā)射功率并等于LTE小區(qū)功率除以PRB數(shù)量這么簡單還要考慮O-RU的非線性失真、濾波器滾降和鄰頻保護帶寬。我的建議是初始配置時保守一些把NPDSCH的功率偏移控制在3dB以內(nèi)通過路測數(shù)據(jù)反向優(yōu)化。先少給功率、再看終端表現(xiàn)比一開始就拉到最大然后被干擾投訴折磨要穩(wěn)妥得多。7.3 終端多樣性要納入驗收流程物聯(lián)網(wǎng)終端的成本敏感特性決定了芯片方案的碎片化。同一款BC95模組和另一款國產(chǎn)NB-IoT芯片模組在同樣下行配置下的解調(diào)能力可能差3到5個dB。項目驗收如果沒有覆蓋終端多樣性很容易出現(xiàn)測試都過了、規(guī)模上線后大量設備連不上的尷尬局面。我的做法是準備一套終端矩陣涵蓋主流芯片廠商的至少三款模組每款再按CE等級分檔測試把結(jié)果記錄在案。這是控制項目交付風險的最后一層保險。最后聊一個和文章主題關(guān)系不大但很實用的習慣配置任何NB-IoT小區(qū)前先把O-DU當前版本的所有配置參數(shù)導出存檔并在完成一組修改后記錄前后配置差異。ORAN系統(tǒng)的靈活性也意味著配置出錯的空間更大一個不顯眼的參數(shù)改動可能影響整條下行鏈路。養(yǎng)成配置即文檔的習慣你會少很多返工。