2015年12月10日 星期四

BLE Data Rate 專題討論 (1)

BLE data rate 討論超級多, 可見這問題其實都是 BLE users 非常關切的問題, 畢竟傳輸速度跟應用可是息息相關, 舉個例子假如我今天有一個資料模型是每秒會產生 30KB, 那我要去選擇使用的無線傳輸模式 (BT, WIFI, ZigBee, ... 做選擇), 這時候去評估 BLE 是否合適的時候, 發現 BLE 實際傳輸速度大概只到 4KB/s, 那表示我的資料假如跑 1 分鐘, 就得花  7.5 分鐘傳完, 然後再去評估這是否是使用者接受的, 假如無法接受, 那勢必不能用 BLE (以此類推...)

所以這篇就專程來探討 BLE 的速度, 我會把 BLE 速度分類成下面幾樣, 注意這邊講的速度都是 application data rate, 也就是使用者的"有用途的資料"的傳輸速度
  1. 理論速度
    • 根據 RF 能力以及 Protocol overhead 推算的理論速度 (BER, bit error rate = 0%)
    • 通常現實環境不可能這麼美好, 且晶片能力也可能有限制, 所以實際上不可能達到這個速度
  2. 裝置實際速度 (跟 BLE 晶片 & 環境有關)
    • 實際傳輸環境, 會有 2.4GHz 干擾 (例如跟 WiFi 等等的干擾), 另外距離遠的話訊號也會減弱, 所以免不了會掉資料, 自然就會影響實際速度
    • BLE 解決方案的廠商 (例如 CSR, TI, Nordic, Microchip, STMicro, ...) 各自會有自己的 Protocol Stack Implementation, 所以 Performance 做得好不好跟執行這個 Protocol Stack 的 MCU 強不強, 都會影響實際傳輸速度
      • 例如 TI & Nordic 能夠支援的 Connection Interval 以及每個 Connection Interval 可以送的最多 packets 數量不同, 所以可以達到的最高速也不同
      • 又例如支援的 TX power level 不同, 所以在同樣距離下的 BER 也不同, 自然速度也不同
  3. 系統實際速度 (跟 BLE 裝置以及和此裝置溝通的控制端有關, 例如手機, 平板, 電腦)
    • 系統要跑起來, 不可能只有一個裝置, 有送端就有收端, 送太快沒辦法收也是沒用的, 所以整個系統速度要考量收送兩邊
    • 例如 iOS 為例子他就限制他的 Connection Interval 是 30ms, 每個 Connection Interval 只能收 4 packets, 自然他的速度就被限制了, 這時儘管你裝置送的速度再快, 系統速度就被 iOS 限制了 (下面會討論這個議題)
首先先來看理論速度, 基本上網路資料非常多, 先看幾個整理過的資訊

http://www.anandtech.com/show/8770/bluetooth-42-core-specifications-finalized
























這個表上面為 Bluetooth Classic (EDR) 不同 packet type 可以到的速度, 這邊我們就不討論, 直接看最後兩項是 BLE 4.0/4.1 以及 BLE 4.2 的速度, 這邊為理論速度, 由表可以知道舊版本 (市面上 BLE Smart Single Mode Chip 頂多到 4.1) 的速度理論值為 260kpbs, 而到了 4.2 可以到達 650kbps


https://bluegiga.zendesk.com/entries/22400867--HOW-TO-Maximize-throughput-with-BLE-modules








這個 Summary 我覺得整理得很不錯, 這個表基本上就把這系列主題總結完了, 所以不想看細節的基本上參考這表把 link 存我的最愛, 就可以離開了其實...

那這篇後半段我們就來研究一下這理論速度怎麼來的, 首先是我個人對 Protocol Stack 的了解, 這種 Application Throughput 的算法其實就是 RF (Base band) 速度扣掉 Protocol Overhead 就可以算出來,  但考量 Protocol 有很多層都有不同的 packet type, 加上會有一些 control packets (例如 acknowledgement packets), 都會占用這 1Mb/s, 所以其實沒這麼好算, 必須對整個 Protocol 非常熟悉才有辦法算出來, 這部分未來有機會再開一篇算, 算完基本上也對整個 BLE Protocol Stack 每個 layer 都有更深的了解

那回到大家常常聽到的 BLE data rate 236.7kbps 這個數字的原因, 他的來源是下面這篇 Paper 所實驗的結果, 這篇 Paper 我非常推薦可以看一下, 有滿多基本的概念

Modeling the Maximum Throughput of Bluetooth Low Energy in an Error-Prone Link

這邊太多數學就不講, 只提重點, 首先是計算 Max Tput. 的公式:

這是最基本的公式, Max Tput. = EN (預期最大可以在每個 connection 內傳輸的 packet 數量) x L (user data size in packet) / connection interval (兩個 BLE connection 間的時間差)











這個公式後面幾個章節都會用到, 所以要搞懂, 下圖就可以表示 connection interval 的意思, BLE 是定期做 connection 並傳輸資料的, 而非一直保持連線, 每兩個 connection 的間隔就是 connection interval, 另外下圖還表示了 DATA 以及 ACK 和 IFS (Inter Frame Space) 的意思














關於 Connection Interval, SPEC 是有規定範圍的, 如下所示, 會介於 7.5ms ~ 4000ms 之間, 假如今天 BLE solution 有能力限制是每個 connection interval 最多只能傳 N 個 packets, 那這個 solution 的 Max Tput. 就可以用 Max (bps) = N * 20 / 7.5 * 1000 來算出, 20 為 packet size, 我稍微看了一下 SPEC 應該沒有規定 packet size 最大是 20, 但比較舊的 BLE solution 似乎最大的 size 就是 20 bytes, 因此這邊就用 20 bytes, 網路上很多文章也寫說 max user data size using notification 為 20 bytes, 我認為這不是 SPEC 的規定, 只是因為 BLE solution 的限制, 這部分後面討論

不過假如是理論的 Max Tput. 的話, 當然就是會在這個 connection 內能送多少就送多少, 所以這時候你的 connection interval 設定不管是大是小, 對於 Max Tput. 的影響就沒這麼大了, 重點還是在於每個 Connection 要極盡所能的打出 packets, 而量到的速度就是 Max Tput.

















因此回到公式, 我們已經知道 L = 20 了 (以本篇 Paper 定義來看的話), EN 怎麼推算? 首先我們定義 Nmax 表示在 connection interval 內可以有的最多的 round trip (data + ack = round trip), 而 P{i|k} 表示在有 k round trips 的 connection event 中, 有 i 個資料被 ACK 的機率, 所以 EN 就是這些全部各種情況機率的總和


















後面還帶入關於 BER 的 model 後, 最終 simulation 出來的結果如下圖所示












最終得到在沒有 BER 的情況下, 不管 connection interval 是多少, Max. Tput 就是約 236.7kbps, 也就是在 BLE 4.0/4.1 下面的理論 application data rate (一樣強調一下這是當 L = 20 的狀況, 但假如 L > 20 相信可以更快)

接下來關於 4.2 部分, 所謂 payload 上升將近 10 倍, 而 application data rate 上升約 2.5 倍的部分怎麼來的, 首先我們先了解所謂的 payload 變大是大在哪邊, 下面兩張圖是 4.1 和 4.2 針對 LL packets format 的表示, 可以看到所謂 payload 變大其實是 LL packets 的 payload 變大了, 由原本最多帶 39 bytes 變成帶 257 bytes



































那回到剛剛提到要探討關於 L = 20 的這個限制的部份, 也就是 LL 上層的 L2CAP 上面的 data size 可以大於 20 嗎? 我認為應該是沒問題的, 我翻了 4.0 ~ 4.2 SPEC 關於 ATT_MTU 部分如下, 是寫最小 23 bytes, 也就是 user data size 可以到 20 bytes (ATT_MTU - 3 SPEC 有寫就不貼了), 假如是使用預設的 ATT_MTU 的話














而下面又有提到關於 MTU Exchange 的部分, 看起來就是可以讓 ATT_MTU 更大, 而假如便大的話, Read/Write/Notification/Indication 的 data size 都可以更大才對, 所以 SPEC 並沒有限制所謂的 notification 一次 20 bytes, 但去看如 Nordic, TI 的第一代 BLE Chip, 的確都限制在 20 bytes per ATT packet, 我猜應該是因為這樣所以網路才會出現 SPEC 規定 20 bytes 的限制















最後再補充 SPEC 的一段關於 L2CAP SDU 中所帶的 MTU 的敘述, 也是說 MTU 最小是 23 bytes in BLE














Anyway 我這邊真的找不到 SPEC 針對 ATT Packet 的 Payload 最大是 20 bytes 的定義或原因, 假如有人有相關資訊請再提供給我

所以假設我沒錯, 則根據 SPEC ATT Payload 可以很大, L2CAP Payload 也可以很大, 但是 BLE 4.0/4.1 的時候, LL Packet Payload 最大也才 27 bytes, 所以其實 ATT Packet 變大沒什麼用, 底層還是得分很多次傳, 但到了 BLE 4.2, 連 LL layer 的 payload 一起變大後 (ATT, L2CAP, LL payload 都一起變大), 則速度肯定是可以提升的 (至少 protocol overhead 就少了很多了)

不過上面一些文章提到 BLE 4.2 理論速度可以提升 2.5 倍的部分, 我目前還找不到相關資料怎麼算出來的或是來源為何

(註: 這篇講的也有可能我對 BLE SPEC 有誤解而分析錯誤, 因此僅供參考, 建議自己看 SPEC 解讀, 也歡迎指正)

------------------------------------------------------
Copyright by Jackal Chen @ 2015
jackalchen737@gmail.com

相關系列文章:

7 則留言:

  1. 您好,
    我之前某一個案上也實作相關議題。
    也曾與台灣,香港 nordic FAE討論過,
    最後是美國那邊RD找出一個方式處理。

    提供一下意見討論。

    1.L2CAP 為23B ,那ATT layer不就應該會更小(20B)。
    2.而在IOS 上它的最小connect interval 為20ms ,但在HID 可以達到 7.5ms
    所以,可以利用這點來提高傳輸速度。大家可以去試試。
    (就是先配對上一個HIDkeyboard,再去連上你的裝置)。
    (但這個可能還是與的IOS裝置及系統版本有關,不一定有效。)

    回覆刪除
  2. 你說的沒錯, 這個議題我是打算在第三集講的, 這是因為 iSO development Guide 的限制, 他對一般 use 就是用 20-30ms connection interval, 限制是一個 connection interval 4 包. 而假如用 HID 可以縮短 connection interval, 一樣 4 包, 就可以加速了

    回覆刪除
  3. "Anyway 我這邊真的找不到 SPEC 針對 ATT Packet 的 Payload 最大是 20 bytes 的定義或原因, 假如有人有相關資訊請再提供給我"

    針對上面這點回應(參考core spec V4.2 Vol 3, Part F, 3.4.4.4 & 3.4.5.1)

    以最常用的characteristic讀寫來說
    read response PDU : 1 octet Attribute Opcode + 0 to (ATT_MTU-1) octets Attribute Value
    write request PDU : 1 octet Attribute Opcode + 2 octets Attribute Handle + 0 to (ATT_MTU-3) Attribute Value
    當MTU值在預設的23時,能安全地被讀寫的最大payload長度是20
    我想這是“Packet 的 Payload 最大是 20 bytes”這個(過度?)簡化說法的來源

    回覆刪除
  4. 對這個其實後面討論有提到, 但可是 MTU 並沒在 SPEC 被限制 23 只是預設 23, 假設我 MTU 設定提高, 速度就可以提高, 所以用這個 20 bytes 來算 speed upper limit 就有點怪了

    回覆刪除
  5. 雖然有點晚了不過還是提一下,在Spec 4.0 p.2208 DATA Channel PDU的header中,關於length的最大長度是5 bits,直接限制header後面所帶的payload不大於31 bytes,於是:

    LL Data payload = 31 - (MIC + CRC) = 27
    L2CAP payload = 27 - L2CAP header = 23
    ATT payload = 23 - ATT header = 20

    老實說這個限制很奇怪,所以不意外這個限制在4.2中被提升到了8 bits,這也是為什麼4.2的PDU的上限變成了257 (= 255 + LL header)。附帶一提Advertising packet的length則一直都是6 bits。

    回覆刪除
  6. 喔喔, 原來是因為這樣, 我還真的沒注意到這邊, 非常感謝補充這個資訊, 解開了我一直以來的疑惑

    回覆刪除