Castle on a Cloud

來自: https://www.novelbits.io/bluetooth-5-speed-maximum-throughput/ 我們一樣從 BLE 的封包封裝開始介紹 L2CAP 協定, 在之前的介紹中, 我們介紹了 LL (Link Layer) 層的通訊協定, 在 LL 層的 payload 中, 我們可以加入更上層的封包格式, 在 BLE 協定中, 其中一種上層協定稱為 L2CAP (Logical Link Control and Adaptation Protocol), L2CAP 中主要負責功能如下: 封包的分段 (Segmentation) 重組與拆解 重傳與資料流控制 (Flow Control) 封裝 (Encapsulation) 與排程 (Scheduling) QoS 機制的支援 相對於底層封包傳送以 PDU (Packet Data Unit) 為單位, L2CAP 上層應用可以以 SDU (Service Data Unit) 來傳送資料, 一個 SDU 的大小最大可以為 64 KB, L2CAP 協定會將一個 SDU 按照 PDU 的大小進行重新切分與重組, 並將一個 Service 虛擬成一個邏輯通道 (L2CAP Channel), 讓上層應用進行存取. 為了完成上述功能, L2CAP 由兩個部分組成: Channel Manager, Resource Manager, 如下圖所示:  Figure 1.1: L2CAP architectural blocks in "Logical Link Control and Adaptation Protocol Specification" 對於一個 L2CAP Channel 而言, 對應一個 Channel ID (CID), 一個 CID 對應於一個 P2P 的 BLE 連線, 基於一個 CID, L2CAP 提供 Flow Control 與重傳機制, 對於 L2CAP 底下的 PDU 而言, L2CAP 提供檢查 CRC 和重傳機制, 考慮到 LL 層本身的重傳機制, PDU 會在連線失敗之前不斷重傳, L2CAP 實際上的 Flow Control 機制為控制 PDU

在上一篇文章中, 介紹了 BLE 5.0 的新功能, 其中, 其中有一項是 2Mbps 的物理層傳輸速率, 然而, 我們真實量測的網速為在 MAC 層的網路速度, 我們在計算 BLE 5.0 真實的 throughput 時, 必須考慮其 MAC 層的機制, 才能找出真實傳送時的速度. (事實上, 還要計入個層封包的 header 冗餘, 才能反映真實速度) 在 BLE 5.0 中, 影響 throughput 的 MAC 層因素包括下列四點: 每一個 Connection Interval 中的封包數量上限 封包間隔時間 (Inter Frame Space, IFS) 的長度 (150 ns) 用以回應 ARQ 的空封包 MAC 層的 header 冗餘 首先, 我們先看 MAC 層的冗餘, BLE 封包格式如下: https://www.novelbits.io/bluetooth-5-speed-maximum-throughput/ 在 BLE 4.2 之後, payload 長度為 244 bytes, 在使用 2M PHY 時, 對應的 PDU 長度為 266 (2+4+257+3) bytes, 換句話說, 傳送一個封包中, 資料佔 244/266 的比例. 接下來, 我們要回答在一個 Connection Interval 內可以傳幾個封包, 這個問題來自於兩個限制: 第一, Connection Interval 必須高於所有封包 + IFS 的總時長 第二, 來自硬體 (BLE 晶片) 以及作業系統的限制, 當需要設計一個高速應用時, 要特別注意此來自於裝置與作業系統的限制, 並根據需求選擇適合的 Connection Interval 長度. 在接下來的討論中, 我們先忽視第二點限制, 來考慮所有封包所產生的總時間長度, 在 BLE 中, 下一個回傳的封包為傳送的封包的 ACK, 考慮到一個單向的 BLE 應用 (只有 master -> slave 的資料回報), 此時回傳的封包為一個空封包 (沒有 payload), 因此, 一次資料交換的流程為: IFS + data packet + IFS + empty packet, 如下圖所示: h

本篇文章來源為:  https://www.novelbits.io/bluetooth-5-advertisements/ BLE 5.0 號稱有三大改良: 網速從 1Mbps 提升至 2Mbps 傳輸範圍提升 4 倍 廣播封包的 throughput 提升 8 倍 不過, 這些改良並不是同時完成, 和 BLE 4.2 相比, BLE 5.0 提供了兩種新的 PHY 層格式, 分別是對應高傳輸率的 2Mpbs (LE 2M), 以及透過錯誤更正碼保護對應高傳輸範圍的 PHY 層協議 (LE coded), 其中, 三種 PHY 層的協定如下圖所示: 來自:  https://www.novelbits.io/bluetooth-5-advertisements/ 在上表中, 我們可以看到, 當使用 LE coded 來延伸傳輸距離時, 傳輸速率並沒有提升, 反而是下降, 另一方面, 在廣播封包 (advertising) 部分, 和 BLE 4.2 相比, 新增了一種新的 Adverting, 稱為: Extended Advertisements, 和舊有的 Adverting (Legacy Advertisements) 相比, 新的規格可以使用所有的頻帶 (不只是 36, 37, 38), 也因此, 可以提供較寬頻的廣播通訊, 此功能應該是應對於 BLE Mesh 的技術, 考慮到 BLE Mesh 是以 Advertising 封包傳送, 其有效 throughput 並不高, BLE 5.0 可以針對此部分進行提升, 其基本想法也是在 {36, 37, 38} 上發送起始的封包, 並在 {0-36} 將剩餘封包傳輸, 因此, 此類的 Advertising 封包傳送機制, 就非常類似於舊有 BLE 中的一般封包傳送, 只不過, 現在傳送的對象是一整群的定閱使用者.