藍牙m(xù)esh規(guī)范中定義了兩種承載器：廣播承載器和GATT承載器。因為目前市面上所有手機，都沒有包含完整的藍牙m(xù)esh協(xié)議棧，所以在APP中只能以代理的方式和設備建立連接才能通信，造成的結果是在APP端只有GATT承載器。廣播承載器的部分只能在節(jié)點與節(jié)點之間進行數(shù)據(jù)傳輸時用到，APP端目前都是配網器的角色。
Advertising bearer
在手機端是沒有這個承載器的，原因已經在之前的文章中說過了。對于廣播承載器，只貼一張圖
GATT bearer
GATT承載器能夠讓那些不支持廣播承載的設備也能加入藍牙m(xù)esh網絡。GATT承載器通過在兩個設備之間建立GATT連接并使用代理協(xié)議來發(fā)送和接收代理數(shù)據(jù)報。
就是用傳統(tǒng)的BLE4.0的操作方式，建立GATT服務端和客戶端，跟大多數(shù)BLE使用場景一樣，GATT服務端只能實例化一個藍牙m(xù)esh代理服務，就是一個服務端不能同時連接多個客戶端。配網器連接代理節(jié)點，節(jié)點將消息傳遞給其他節(jié)點。
手機是服務端，根據(jù)協(xié)議規(guī)定，手機同時只能連接一臺mesh設備。大家都知道手機可以連接多臺BLE4.0設備，為什么藍牙m(xù)esh協(xié)議規(guī)范要規(guī)定只能連接一臺設備？
當下有個配網需求，“一鍵配網”，指將搜索到的為配網設備，一鍵同時都加入網絡。能不能同一時間給多臺設備配網？
所謂的藍牙m(xù)esh代理服務，就是在客戶端按照下圖中的特征配置，與指定的特性進行通信。
這里要說明一點：藍牙m(xù)esh協(xié)議，實際上包括設備配網協(xié)議與配網后的7層網絡架構協(xié)議。配網數(shù)據(jù)的發(fā)送和節(jié)點的消息發(fā)送是兩種不同的協(xié)議層次。但是他們都會使用到承載層，所以可以看到設備在配網前后使用的代理特性是不一樣的，在APP界面上，搜索未配網設備和搜索已配網設備的頁面也是分開的，這樣做的好處，在代碼實現(xiàn)層面的結構更清晰。當然是可以做到把未配網設備和配網設備都放在同一個頁面，但不管是從消費者使用方便還是程序業(yè)務邏輯上講，都沒有任何好處。
承載層的具體職責
1.將來自網絡層的數(shù)據(jù)報，通過GATT連接發(fā)送出去
2.識別接收到的數(shù)據(jù)類型，識別類型后傳給網絡層進行下一步處理。
承載層一共支持4種消息類型：
- networkPdu = 0
- meshBeacon = 1
- proxyConfiguration = 2
- provisioningPdu = 3
因為藍牙m(xù)esh存在兩種不同的協(xié)議棧，在APP端程序中承載層暴露給網絡層調用的承載器是兩種：GattBearer和PBGattBearer。PBGattBearer是負責配網協(xié)議的承載器，僅支持provisioningPdu這種消息類型。GattBearer負責其他三種消息類型，networkPdu、meshBeacon、proxyConfiguration。這兩個承載器支撐起整個APP端藍牙m(xù)esh協(xié)議的數(shù)據(jù)傳輸。
承載層需要暴露給其他層調用的接口：
- 發(fā)送數(shù)據(jù)的接口
- 接收數(shù)據(jù)后往網絡層傳遞數(shù)據(jù)的接口
- 承載器的狀態(tài)查詢接口，指底層BLE是否已經建立連接
- 打開承載器接口，建立GATT連接
- 關閉承載器接口，關閉GATT連接
- 承載器打開成功后的回調接口
- 承載器操作異常的回調接口
- 承載器關閉成功后的回調接口
- 是否支持消息類型接口
- BLE設備信息回調接口，如設備UUID，name，RSSI
- 承載層內部的數(shù)據(jù)的分包與數(shù)據(jù)重組
思考：在之前的文章中提到過，手機端因為沒有完整的協(xié)議棧，只能使用GATT承載器。從節(jié)點拓撲圖上看，一個Friend節(jié)點可以對應多個低功耗節(jié)點，那么低功耗節(jié)點設備是否有完整的mesh協(xié)議棧，它是如何實現(xiàn)與mesh網絡進行通信的？
