主題
BLE通信のスループットが各種通信パラメータに大きく左右されることは色んな記事で見聞きしていたが
実際にどれくらいのスループットが出るのかを検証している記事が見当たらなかったため、
Nordic社のnRF52840チップを使って、実力値を計測してみた。
BLE通信仕様について
本記事ではBLE通信仕様の紹介は省略するが、
記事作成にあたり参考にした文献を以下に示す。
BluetoothSIG規格通信仕様書
https://www.bluetooth.com/ja-jp/specifications/bluetooth-core-specification/
本サイトはBLEの基本的な通信の仕組みが体系的に説明されており、大変参考になった。
https://shizuk.sakura.ne.jp/bluetooth/ble/gatt_spec.html
Nordic社のSDKドキュメント
https://www.bluetooth.com/ja-jp/specifications/bluetooth-core-specification/
#ハードウェア
今回はadafruit社のFeather nRF52840 を2つ使用した。
nRF52840チップはBluetooth5.0規格に準拠したデバイスである。
https://learn.adafruit.com/introducing-the-adafruit-nrf52840-feather/pinouts
2つBLEデバイスを至近距離(10cm)に配置し、片方のデバイスをTester（Peripheral）、もう片方をResponder（Central）として利用する。
計測シーケンス
スループット計測のシーケンス概要を以下に示す。
今回はGATT通信のNotification方式を使い、1MB送信にかかる所要時間からスループットを計測する。
なお、NotificationはGATTサーバ(Tester)から一方的にデータを送信する方式のため、
GATTサーバはクライアントからの受信応答を待つことなく連続的にパケットを送信できる。
スループット計測ソフト
ありがたいことに、Nordic社のSDKにはスループット計測用のサンプルコードが含まれているので、今回はそれを流用した。
Experimental: ATT_MTU Throughput Example
https://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.sdk5.v13.0.0%2Fble_sdk_app_att_mtu.html
#サンプルコードの修正
今回流用するサンプルコードはnRF52840-DKの評価ボードのI/F操作を前提に実装されているため、FeatherとのI/Fの差を吸収するために、以下の対応を取った。
| I/F | nRF52840-DK | Feather nRF52840 |
|---|---|---|
| ロール切替(Tester) | Button3 | コンパイルスイッチ |
| ロール切替(Responder) | Button4 | コンパイルスイッチ |
| インジケータ(アイドル) | LED1 | Conn |
| インジケータ(接続確立） | LED2 | 無 |
| インジケータ(テスト実行中) | LED3 | D3 |
| インジケータ(テスト完了) | LED4 | 無 |
| CLI(パラメータ設定、テスト実行指令) | UART | ハードコーディング |
| CLI(ログ出力) | UART | J-Link RTTで代用 |
FeatherにはUSBDペリフェラルが備わっているため、UARTの部分はCDCで代用できるがはずだが今回は対応を見送った。
なお、NRF52840-DKを使えばサンプルコードを一切修正することなくテストできるので、
ターゲットボードをこれから調達する方はnRF52840-DKを購入することをお勧めする。
計測結果出力
計測結果の表示については、
ペリフェラル側（送信側）が出力するログをJ-Link RTT Viewerを使って表示した。
制御パラメータ一覧
スループット計測にあたり、サンプルコードで変更することが可能な制御パラメータと、その性質の概要を以下に示す。
なお、各パラメータの性質については私の理解が間違っているところもあると思いますので、ご指摘いただけると幸いです。
| パラメータ | 性質 |
|---|---|
| ATT_MTU | GATT層のパケット送信長。今回の計測では1MBを(ATT_MTU-3)で分割転送する形になるため、ATT_MTUが大きくなるほどオーバヘッドが減り、スループットの上昇が期待できる。 |
| Data length | L2CAP層のパケット送信長。ATT-MTUに合わせて大きくすると、GATT層パケットを分割をすることなく伝送できるのでスループットが上がる。 |
| Connection interval | コネクションイベントの発生周期。本パラメータをGAP event lengthとともに大きくすると、1コネクションイベントで送信できるパケット数が増えるため、スループットが上昇する。 |
| PHY data rate | 物理層の転送速度。4.2までは1Mbpsだったが、5.0より2Mbpsが選択可能になった。1→2Mbpsにすることで単純に2倍にはならないが、大幅なスループットの改善が見込まれる。 |
| Connection event extension | コネクションイベントに関するパラメータのようだが詳細不明のため、今回は常時ON(Default)とする。 |
| GAP event length | 1コネクションイベントにおける通信可能時間。本パラメータを増加させることで送信できるパケット数が増えるため、スループットが上がる。但し、本パラメータを大きくすると無線機の電源ON比率が上がるため、BLE本来の省電力の性質から遠ざかる。 |
| Scan Window/Interval | セントラルのスキャン時間/スキャン周期。比率が100％に近づくにつれて、ペリフェラルからのアドバタイジングを取りこぼす確率が減る。 本パラメータは接続確立前のパラメータなので、スループットに直接影響はないが、接続確立までにかかる時間は短くなるはず。 |
検証パターンと計測結果
各検証パターンについて10回計測を行い、その平均値と標準偏差、相対標準偏差(変動率)を算出した。
| Pattern | Throughput[Kbps] | MTU[byte] | DataLength[byte] | Connection Interva[ms] | PHY data rate[Mbps] | Connection event extension | GAP event Length[ms] | Scan window/interval |
|---|---|---|---|---|---|---|---|---|
| 1 | 189.83±2.19(±1.15%) | 23 | 27 | 7.5 | 1 | ON | 500.0 | 160/160(100%) |
| 2 | 193.08±0.29(±0.15%) | 23 | 27 | 7.5 | 1 | ON | 25.0 | 160/160(100%) |
| 3 | 222.80±2.63(±1.18%) | 23 | 27 | 25.0 | 1 | ON | 500.0 | 160/160(100%) |
| 4 | 218.74±5.00(±2.29%) | 23 | 27 | 25.0 | 1 | ON | 25.0 | 160/160(100%) |
| 5 | 216.64±12.20(±5.63%) | 23 | 27 | 500.0 | 1 | ON | 500.0 | 160/160(100%) |
| 6 | 276.48±12.38(±4.48%) | 247 | 27 | 500.0 | 1 | ON | 500.0 | 160/160(100%) |
| 7 | 748.89±10.31(±1.38%) | 247 | 251 | 500.0 | 1 | ON | 500.0 | 160/160(100%) |
| 8 | 262.24±0.04(±0.02%) | 247 | 251 | 7.5 | 1 | ON | 500.0 | 160/160(100%) |
| 9 | 1231.76±65.53(±5.16%) | 247 | 251 | 500.0 | 2 | ON | 500.0 | 160/160(100%) |
考察、疑問点
物理層を2Mbpsにするとパフォーマンスは大きく改善するが、その他のパラメータ調整は同じもしくはそれ以上に重要であることが分かった。
特に、DataLengthおよびConnectionIntervalをATT_MTUに合わせて限界まで引き上げる(No.7)はスループットが大きく改善した。
また、No.5,6,8の結果からも分かるように、ATT_MTU,DataLength,ConnectionIntervalを個別に大きくしたパターンではスループットは大幅に変わらないが、3つすべてのパラメータを大きくした場合に限り、スループットが劇的に改善される点は大変興味深い。
但し、No.7においては物理層のバス占有率（無線機が通信している時間）が約73％にまで達しているため、電量消費量はかなり高くなっていると考えられる。
ConnectionIntervalを大きくするとばらつきが大きくなる傾向にあり、
これは、パケットロスが発生したときの再開するためのインターバルが伸びることが原因だと考えられる。一方で、No.7はばらつきが小さくなっており、なぜそうなるのかが理解できない。
今回の計測結果になった裏付けが取るためにBLEパケット解析を実施する予定。
参考文献
[nRF52でBLEデバイスを開発する（１）Adafruit FeatherとSEGGER Embeded Studio]
https://qiita.com/jiro-aqua/items/63d3c04ba33eac57ebd0
[nRF52840 を Segger Embedded Studio 開発環境で First Try]
https://qiita.com/nanbuwks/items/dd20dc4619af1d994f2c
[IoTの要件を満たすBluetooth 4.1、4.2、および5対応Bluetooth Low Energy SoCおよびツール（第1部）]
https://www.digikey.jp/ja/articles/bluetooth-41-42-5-low-energy-socs-meet-iot-challenges-part-1
[L2CAPの変更点]
https://techweb.rohm.co.jp/iot/knowledge/iot02/s-iot02/04-s-iot02/2992
[[15分勉強会] Bluetooth 4.2 → 5 でなにが変わったか？]
https://www.slideshare.net/KeisukeSuzuki1/15-bluetooth-42-5
[Bluetooth Low Energy data throughput]
https://infocenter.nordicsemi.com/topic/sds_s140/SDS/s1xx/ble_data_throughput/ble_data_throughput.html
今回はスループットの調査文献が見当たらなかったので自分で調べてみることにしたのだが、Nordic社のSDKドキュメント内に本記事と同目的の記事があった・・・。
本リンクでは、GATT通信方式を変更したときのスループットの変動についても調査されているので、Notification以外のスループット値を知りたい方はこちらをご覧ください。