藍(lán)牙核心規(guī)格5.3發(fā)布后大家聊得最多的通常是連接子速率和LE音頻。但作為把低功耗藍(lán)牙LE真正塞進(jìn)量產(chǎn)產(chǎn)品的人我對5.3里最感興趣的反而是信道分類這套改進(jìn)。信道分類不是一個(gè)新概念BLE 4.0時(shí)代就有但5.3這一版把它的價(jià)值拉高了一個(gè)量級從“控制器內(nèi)部悄悄進(jìn)行的優(yōu)化”變成了“主機(jī)、鏈路層共同參與的動態(tài)機(jī)制”。簡單說這次增強(qiáng)解決的是真實(shí)房間里最常見的痛點(diǎn)——明明藍(lán)牙連接能建立數(shù)據(jù)卻總是重傳明明某個(gè)信道被Wi-Fi占得死死的藍(lán)牙設(shè)備卻還在里面撞得頭破血流。這篇文章不打算泛泛講藍(lán)牙5.3的新聞稿而是把LE信道分類單獨(dú)拎出來結(jié)合物理層機(jī)制、舊版局限、新版的改動方式以及工程落地注意事項(xiàng)一次講清楚。適合正在做BLE產(chǎn)品選型、協(xié)議棧遷移或者被現(xiàn)場干擾問題折磨的工程師參考。1. 為什么低功耗藍(lán)牙要先回答“哪些信道還能用”LE從誕生起就工作在2.4GHz ISM頻段這個(gè)頻段不長83MHz卻擠著Wi-Fi、Zigbee、Thread、私有2.4G協(xié)議甚至還有微波爐的泄漏輻射。BLE本身發(fā)射功率就低連手機(jī)外設(shè)都經(jīng)常在0dBm附近打轉(zhuǎn)硬拼信號強(qiáng)度肯定不現(xiàn)實(shí)所以藍(lán)牙采用的辦法是跳頻這次連接事件在這條信道上傳輸下個(gè)連接事件立刻換到另一條信道盡量躲開正在被強(qiáng)干擾占用的頻率。跳頻能玩得轉(zhuǎn)前提是“知道哪些信道還能用”。于是就有了兩個(gè)最基礎(chǔ)的概念信道分類和信道地圖。很多做應(yīng)用層的朋友容易把這兩個(gè)詞混在一起這里必須分開否則后續(xù)看協(xié)議棧日志、分析HCI trace會一頭霧水。1.1 40個(gè)物理信道里真正留給數(shù)據(jù)的只有37個(gè)先看物理層的家底。LE一共定義了40個(gè)2MHz帶寬的物理信道中心頻率從2402MHz開始每2MHz遞增一直延伸到2480MHz。這40個(gè)信道里索引37、38、39被固定用作廣播信道剩下索引0到36共37個(gè)信道才是連接、音頻流、周期廣播等場景真正承載數(shù)據(jù)的信道。信道地圖在HCI層面的表現(xiàn)就是5個(gè)字節(jié)、總共40個(gè)bit的位圖每個(gè)bit對應(yīng)一個(gè)信道。BLE設(shè)備在建立連接時(shí)雙方要針對這份信道地圖達(dá)成一致。某個(gè)信道如果被Wi-Fi長期占用、丟包率明顯升高鏈路層就會把對應(yīng)bit清零跳頻算法在后續(xù)的事件里不會再跳到這個(gè)信道上去。有一個(gè)細(xì)節(jié)經(jīng)常被忽略廣播信道不在信道地圖的管控范圍內(nèi)。也就是說不管你怎么做信道分類廣播階段的37/38/39三個(gè)信道是否被干擾都只能靠重發(fā)、增大發(fā)射功率這類手段硬扛。這也是為什么很多設(shè)備在廣播階段最脆弱而你很難通過信道分類去優(yōu)化廣播體驗(yàn)。1.2 信道分類和信道地圖不是一個(gè)概念信道分類描述的是“根據(jù)質(zhì)量評估這些信道應(yīng)該被使用的優(yōu)先程度”信道地圖則是“當(dāng)前時(shí)刻鏈路層實(shí)際用來跳頻的信道集合”。前者像一條規(guī)則后者是規(guī)則執(zhí)行后的結(jié)果。用一個(gè)對比表來區(qū)分會更直觀比較維度信道分類信道地圖語義每個(gè)信道在質(zhì)量評估中的狀態(tài)好/壞/待評估當(dāng)前跳頻實(shí)際使用的信道集合主要來源控制器射頻測量、主機(jī)輸入、歷史統(tǒng)計(jì)控制器基于分類、連接參數(shù)計(jì)算而來更新頻率較低按需評估和調(diào)整每個(gè)連接事件都會參與計(jì)算直接影響間接影響需要經(jīng)過決策后才落到地圖直接決定下一個(gè)連接事件的跳頻點(diǎn)不少BLE協(xié)議棧的API里同時(shí)存在“SetChannelClassification”和“UpdateChannelMap”這類接口。前者偏向“告訴底層我認(rèn)為哪些信道不可信”后者偏向“現(xiàn)在立刻不用這些信道”。上層排查問題時(shí)如果先把這兩個(gè)概念區(qū)分開再看日志會快很多。2. 5.3之前信道優(yōu)化基本是控制器“單機(jī)游戲”在BLE 5.2及以前信道分類的典型流程是這樣的連接建立之前主機(jī)可以通過HCI命令“LE Set Host Channel Classification”把自己的信道分類建議下發(fā)給控制器。控制器拿到建議后和它自己的信道分類來源包括射頻前端測量、歷史跳頻統(tǒng)計(jì)合并形成初始信道地圖再通過LL_CHANNEL_MAP_IND這類鏈路層控制PDU把地圖同步給對端設(shè)備。設(shè)計(jì)初衷聽著很合理但放到真實(shí)產(chǎn)品里就會暴露三個(gè)問題我把它們稱為三塊天花板。2.1 主機(jī)只在建鏈瞬間能“說上話”主機(jī)在連接建立時(shí)給出的信道分類之后基本就“凍住”了。連接過程中控制器會持續(xù)做質(zhì)量統(tǒng)計(jì)自己決定是否更新信道地圖但主機(jī)除了被動讀取控制器上報(bào)的RSSI、丟包統(tǒng)計(jì)幾乎沒有能力再次主動介入。這帶來的結(jié)果就是控制器成了唯一決策者而且它的決策依據(jù)只有本地度量。比如某個(gè)Combo模組里的Wi-Fi模塊已經(jīng)知道2.4GHz的某個(gè)帶寬即將被雷達(dá)信號占住主機(jī)明明可以通過共存接口把這個(gè)信息傳給藍(lán)牙控制器但舊版規(guī)范沒有給出一條順暢的路徑主機(jī)只能干瞪眼。2.2 控制器的統(tǒng)計(jì)收斂需要時(shí)間另一個(gè)反直覺的事實(shí)是BLE連接開局時(shí)信道地圖往往比較“大方”所有信道默認(rèn)可用。控制器要靠后續(xù)的數(shù)據(jù)包重傳率、誤比特率、RSSI慢慢識別出“黑信道”。也就是說如果主機(jī)事先知道某個(gè)頻點(diǎn)附近有強(qiáng)干擾卻沒辦法把這個(gè)經(jīng)驗(yàn)告訴控制器控制器就得先交一批錯誤包的“學(xué)費(fèi)”才能把壞信道從地圖里踢出去。在信道擁擠的寫字樓里這個(gè)收斂過程尤其痛苦。鏈路剛建立時(shí)數(shù)據(jù)流往往最密集偏偏信道地圖還處在“全信道可用”的樂觀狀態(tài)于是前幾百毫秒都在反復(fù)重傳。2.3 主從兩端信息不對稱BLE連接里主設(shè)備和從設(shè)備使用同一套跳頻地圖但兩個(gè)方向的受干擾情況其實(shí)未必相同。比如從設(shè)備所在的位置剛好收Wi-Fi干擾比較嚴(yán)重主設(shè)備那頭卻很干凈。老流程里從設(shè)備的測量結(jié)果要先通過上層HCI上報(bào)給主機(jī)主機(jī)再綜合決策、發(fā)起地圖更新鏈路長、時(shí)延也大。更麻煩的是如果主機(jī)和從設(shè)備對信道的判斷不一致就可能出現(xiàn)“主機(jī)以為正在用A信道從設(shè)備已經(jīng)偷偷躲到B信道”的錯位狀態(tài)。輕則丟包重則連接事件丟失。這三塊天花板疊加起來最終癥狀就是Wi-Fi密集環(huán)境下BLE連接能建起來但數(shù)據(jù)經(jīng)常重傳信道地圖更新時(shí)連接事件時(shí)序被打亂明明某些信道長期不可用地圖卻遲遲沒優(yōu)化。3. 藍(lán)牙5.3把信道分類改成了什么樣子藍(lán)牙5.3對LE信道分類的增強(qiáng)用一句話概括讓信道分類信息在鏈路層內(nèi)部更及時(shí)、更完整地流動并讓分類結(jié)果在連接生命周期內(nèi)持續(xù)生效。從規(guī)范層面看這次不是推倒重來而是把鏈路層的信道映射更新過程重新做了梳理。它保持了原有的物理信道劃分也不要求換射頻前端主要改動集中在主機(jī)、鏈路層的交互邏輯與事件時(shí)序上。3.1 分類信息可以雙向流動了舊模型中信道分類主要靠控制器本地測量主機(jī)給完初始建議后基本退出舞臺。5.3把鏈路層控制交互的角色放開使設(shè)備之間能夠交換更明確的信道分類信息。也就是說從設(shè)備發(fā)現(xiàn)自己接收方向的質(zhì)量變差時(shí)可以通過鏈路層直接反饋給對端主設(shè)備如果同時(shí)帶有Wi-Fi共存模塊也可以把“我要躲開這段頻率”的信息主動同步給從設(shè)備。這個(gè)改動最大的意義在于雙方基于同一份“壞信道名單”來更新各自的地圖而不是各猜各的。實(shí)際測試中主從兩端對信道地圖的認(rèn)知一致性比地圖本身“好不好”更能影響連接穩(wěn)定性。畢竟地圖不一致的后果不是多丟幾個(gè)包而是整個(gè)連接事件失步嚴(yán)重時(shí)直接觸發(fā)射頻鏈路超時(shí)。這里我不展開具體某個(gè)鏈路層控制PDU的二進(jìn)制細(xì)節(jié)。不同芯片廠商封裝的協(xié)議棧函數(shù)名、命令碼差異很大直接背PDU格式?jīng)]有性價(jià)比更重要的是先理解“分類是雙方互相通知”的機(jī)制。3.2 主機(jī)分類不再是“一次性建議”5.3著重加強(qiáng)了“主機(jī)分類可以在連接運(yùn)行過程中反復(fù)使用”這條路徑。即使連接已經(jīng)建立了很久主機(jī)依然可以根據(jù)外部信息隨時(shí)下發(fā)新的信道分類控制器實(shí)時(shí)調(diào)整信道地圖。這個(gè)變化對Combo模組尤其重要。舉例來說一顆同時(shí)負(fù)責(zé)Wi-Fi和BLE的芯片Wi-Fi側(cè)檢測到當(dāng)前正在某個(gè)信道做大數(shù)據(jù)傳輸或者檢測到需要避讓雷達(dá)信號就可以通過主機(jī)把對應(yīng)頻帶從BLE信道地圖里剔除完全不用等BLE控制器花幾秒時(shí)間去測誤包率。這種“跨協(xié)議棧的主動避讓”在舊版框架里實(shí)現(xiàn)起來要繞很多彎路5.3給了一條更順的主機(jī)介入通道。3.3 更新時(shí)機(jī)和連接子速率做了協(xié)同很多人沒有注意到5.3的信道分類增強(qiáng)是跟連接子速率Connection Subrating綁在一起設(shè)計(jì)的。連接子速率允許雙方約定“只在子速率事件里做數(shù)據(jù)交互”中間的事件可以不醒來從而省電。但如果信道地圖一直在變子速率事件又隔了很多個(gè)連接事件才出現(xiàn)一次雙方很容易因?yàn)榈貓D更新時(shí)機(jī)不一致在錯誤的事件里空等。5.3把信道地圖更新的生效窗口重新定義確保地圖更新被安排在下一個(gè)可用的連接事件里而不是隨意插入導(dǎo)致對端丟掉同步點(diǎn)。這個(gè)時(shí)序協(xié)同也是5.3版本在工程上比5.2更好用的原因之一——單看某個(gè)特性似乎都只是小改但組合起來連接穩(wěn)定性有質(zhì)的提升。4. 真實(shí)場景里哪些產(chǎn)品能吃上這波紅利說了半天機(jī)制落到產(chǎn)品層面到底哪些設(shè)備能感受到差異我挑三個(gè)最典型的場景講。4.1 密集Wi-Fi環(huán)境里的數(shù)據(jù)采集設(shè)備寫字樓、商場、工廠里2.4GHz的Wi-Fi AP數(shù)量常常多到數(shù)不清。BLE數(shù)據(jù)采集設(shè)備如果固定在某幾個(gè)信道傳輸幾乎必然撞上某個(gè)Wi-Fi的工作頻率。5.3信道分類允許設(shè)備在連接運(yùn)行期間持續(xù)修正地圖開局階段就可以根據(jù)主機(jī)提供的環(huán)境信息直接避開已知干擾頻段。我實(shí)際測過一款溫濕度傳感器在同一個(gè)房間里布置雙頻Wi-Fi路由器、把2.4GHz固定在某信道重負(fù)載灌包。舊版協(xié)議棧需要幾十秒才能穩(wěn)定下來期間上報(bào)數(shù)據(jù)頻繁重傳換成5.3協(xié)議棧后主機(jī)在連接時(shí)直接把被Wi-Fi占用的信道從分類里排除數(shù)據(jù)在頭幾個(gè)連接事件就進(jìn)入穩(wěn)定狀態(tài)。4.2 LE Audio和助聽器這類丟包敏感設(shè)備音頻流對時(shí)延和連續(xù)性極其敏感一次信道抖動就會讓人聽到“咔噠”聲。助聽器、耳機(jī)這類設(shè)備還面臨一個(gè)額外約束功耗要低不可能一直用高重傳率來換取穩(wěn)定。信道分類增強(qiáng)讓鏈路能夠更快發(fā)現(xiàn)壞信道、更快切換音頻數(shù)據(jù)的有效吞吐率在同等干擾下會比舊版高出不少。尤其要注意的是LE Audio是連接導(dǎo)向的等時(shí)鏈路對連接事件邊界要求很高。5.3把信道地圖更新的時(shí)序和連接事件對齊后等時(shí)鏈路中斷的概率明顯下降。4.3 Wi-Fi/BLE Combo模組手機(jī)、筆記本、智能音箱里大量使用Wi-Fi和BLE共存的Combo方案。以前共存避讓主要靠射頻前端算法比如在硬件上做時(shí)分復(fù)用、檢測Wi-Fi信號后臨時(shí)避讓。5.3給了一個(gè)更優(yōu)雅的方案Wi-Fi協(xié)議棧知道自己在做什么通過主機(jī)把“當(dāng)前這段時(shí)間我要用這些頻率”告訴BLE控制器BLE直接從信道地圖里讓路。這種主動式的共存避讓效果比被動檢測強(qiáng)很多尤其適合Wi-Fi帶寬需求大、BLE又要保持穩(wěn)定上報(bào)的物聯(lián)網(wǎng)網(wǎng)關(guān)設(shè)備。5. 工程落地怎么確認(rèn)你的設(shè)備真的用上了5.3信道分類規(guī)范寫得再好落到自己的產(chǎn)品上總得有一套驗(yàn)證方法。我見過不少項(xiàng)目芯片數(shù)據(jù)手冊寫著“支持藍(lán)牙5.3”但實(shí)際連信道分類的HCI處理邏輯都沒實(shí)現(xiàn)或者只做了個(gè)空殼。以下幾點(diǎn)是我強(qiáng)烈建議在開發(fā)階段就要查的。5.1 從認(rèn)證版本到協(xié)議棧開關(guān)第一件事是確認(rèn)整機(jī)認(rèn)證和協(xié)議棧版本。藍(lán)牙SIG的認(rèn)證聲明里會明確列出支持的核心規(guī)格版本如果只是“兼容”“支持BLE”這種模糊表述要警惕。第二件事是確認(rèn)主機(jī)的協(xié)議棧是否實(shí)現(xiàn)了5.3的信道映射更新相關(guān)接口。很多時(shí)候芯片的Controller硬件支持但Host層SDK沒跟上這時(shí)候只能跟芯片原廠要新版SDK自己改工作量很大。第三件事是檢查信道地圖相關(guān)HCI事件的使能開關(guān)。有些協(xié)議棧默認(rèn)把“LE Channel Map Change”事件關(guān)掉只上報(bào)連接參數(shù)更新導(dǎo)致上層完全感知不到地圖變化。開發(fā)調(diào)試階段建議把這類事件全部打開。5.2 一個(gè)可復(fù)現(xiàn)的干擾對照測試很多團(tuán)隊(duì)驗(yàn)收BLE抗干擾能力時(shí)只是拿現(xiàn)成環(huán)境測一下結(jié)論五花八門。這里分享一個(gè)我常用的可復(fù)現(xiàn)測試方法準(zhǔn)備一臺可設(shè)置固定頻點(diǎn)的2.4GHz干擾源我用的是雙頻Wi-Fi路由器加灌包工具把信道固定到6對應(yīng)約2437MHz。被測設(shè)備作為廣播從機(jī)與主設(shè)備建立連接設(shè)置連接間隔30ms。主設(shè)備持續(xù)向從設(shè)備發(fā)送20字節(jié)通知數(shù)據(jù)統(tǒng)計(jì)接收端的丟包率、重傳次數(shù)和誤碼率。在舊版協(xié)議棧和新版協(xié)議棧下各跑5分鐘對比結(jié)果。觀測指標(biāo)舊版協(xié)議棧無5.3增強(qiáng)5.3協(xié)議棧啟用信道分類連接建立后前1秒重傳率較高且波動大明顯降低穩(wěn)定期平均丟包率下降較慢需幾十秒收斂快速穩(wěn)定信道地圖更新次數(shù)少但集中在某個(gè)時(shí)間段分布均勻按需更新連接失步/超時(shí)次數(shù)偶發(fā)明顯減少需要注意的是如果測試結(jié)果中“信道地圖更新次數(shù)”是0那基本說明信道分類邏輯沒生效。正常情況下干擾信道固定存在鏈路層應(yīng)該能識別并做出調(diào)整。5.3 常見誤解信道分類不是“增加信道數(shù)量”有朋友會把信道分類等同于“把37個(gè)信道全部打開來降低碰撞概率”這是個(gè)方向性錯誤。信道分類的目的是精準(zhǔn)避讓壞信道不是盲目擴(kuò)大可選集合。尤其在BLE mesh或并發(fā)連接較多的場景保留太多可用信道反而會讓不同鏈路之間互相踩踏。正確做法是根據(jù)環(huán)境干擾、鏈路質(zhì)量、共存需求綜合決定地圖黑信道堅(jiān)決隔離好信道盡量充分利用。6. 落地時(shí)容易翻車的地方和我的實(shí)操體會最后聊幾個(gè)實(shí)際開發(fā)中經(jīng)常踩的坑也算是我個(gè)人的一些經(jīng)驗(yàn)總結(jié)。第一主機(jī)盲目下發(fā)分類會“幫倒忙”。5.3把主機(jī)介入做成持續(xù)能力之后有個(gè)新風(fēng)險(xiǎn)如果主機(jī)側(cè)的干擾信息來源不可靠比如Wi-Fi模塊上報(bào)的占用時(shí)段過于敏感BLE信道地圖就會被頻繁抖動。每次地圖更新都會帶來連接事件時(shí)序的微調(diào)頻繁更新反而增加失步風(fēng)險(xiǎn)。實(shí)際工程里我給主機(jī)側(cè)做了“遲滯窗口”只有同一信道被連續(xù)判定為差信道超過N次后才觸發(fā)分類更新避免地圖來回抖動。第二老SDK遷移時(shí)不要只換Controller固件。我之前接手過一個(gè)基于國產(chǎn)BLE SoC的項(xiàng)目芯片原本只支持到BLE 4.2后來換了支持5.3的Controller但Host協(xié)議棧還是舊的。編譯能過、連接也正?？尚诺婪诸愊嚓P(guān)的事件和HCI命令一直沒反應(yīng)。查了很久才發(fā)現(xiàn)Host層沒實(shí)現(xiàn)對應(yīng)的HCI OGF/OCF分發(fā)上層拿不到任何信道地圖變化通知。很多國內(nèi)芯片廠商的BLE協(xié)議棧是拿開源Zephyr、BlueZ改的換Controller后必須同步檢查Host層版本。第三做低功耗設(shè)計(jì)時(shí)信道分類更新和睡眠調(diào)度會打架。BLE設(shè)備為了省電通常會在兩個(gè)連接事件之間進(jìn)入深度睡眠。如果信道地圖更新時(shí)機(jī)沒有跟喚醒時(shí)間對齊設(shè)備可能為了接收地圖更新強(qiáng)制喚醒恰好破壞了原有的低功耗節(jié)奏。5.3把地圖更新和連接子速率事件做了對齊但前提是主機(jī)側(cè)配置對了子速率參數(shù)。我見過不止一個(gè)項(xiàng)目為了省電把子速率值設(shè)得過大結(jié)果信道地圖更新遲遲等不到合適的傳輸窗口抗干擾能力反而不如不做更新。從我個(gè)人這幾年的實(shí)測感受看藍(lán)牙5.3的LE信道分類增強(qiáng)不像連接子速率那樣能帶來立竿見影的功耗數(shù)字變化但它在真實(shí)無線環(huán)境里的長期價(jià)值很高。如果你手頭有產(chǎn)品正在被2.4GHz干擾問題折磨或者正在做Wi-Fi/BLE共存方案非常值得把信道分類的更新鏈路完整跟一遍從HCI日志到鏈路層事件全看一遍你會發(fā)現(xiàn)自己對BLE連接的認(rèn)知會上一個(gè)臺階。