Bluetooth 4.0 や BLE に関して、「あれどこに書いてあったっけ」とならないように自分的お役立ち情報をここにまとめておきます。
Bluetoothのはなし(2)｜Wireless・のおと｜サイレックス・テクノロジー株式会社![]()
この記事はちょっと突っ込んだ情報をわかりやすく簡潔に書いてくれていて、とても参考になります。
[Bluetoothのバージョンについて]
まず明らかにしておきたいのは、「Bluetooth Low Energy(LE)」と「Bluetooth 4.0」という用語の定義は同じではない、ということです。「Bluetooth LE」は Bluetooth 4.0 で新たに追加された新しい通信方式ですが、「Bluetooth 4.0」は以前の Bluetooth バージョンの仕様全て(2.1 で追加された高速モードの EDR や、3.0 で追加された超高速モード HS も)を含んでいいます。つまり「Blueotooth X.X」という表記はプロトコル仕様であってハードウェア仕様を示すものではなく、ハードウェア拡張仕様についてはバージョンの後につく「EDR」とか「HS」とか「LE」によって示されるのです。例を挙げると
「Bluetooth 1.2」...1Mbps の Bluetooth (BDR)
「Bluetooth 2.1」...1Mbps の Bluetooth, SSP ペアリングなどの拡張仕様に対応
「Bluetooth 2.1+EDR」...上に加えて 2Mbps/3Mbps の EDR 高速モード対応
「Bluetooth 3.0+EDR」...上に加えて拡張省電力モード(EPC)などに対応
「Bluetooth 3.0+HS」...上に加えて WiFi 利用の超高速モード(HS)に対応
「Bluetooth 4.0+HS」...上に加えて GATT アトリビュートに対応
「Bluetooth 4.0LE」...GATT アトリビュートに対応、LE モードに対応(但し、この表記からBDR/EDR対応状況は読み取れない)
[BLEで接続時間が改善された理由]
レガシイ Bluetooth の場合、１対のマスター・スレーブが使用する通信周波数は 1MHz 幅 79 本のチャネルを 625 μ秒単位で出鱈目に(疑似乱数に沿って)飛びまわります。Bluetooth のホッピングは徹底しており、デバイス検索時の問い合わせ手順(Inquiry)すら周波数はホッピングします。これは、PAN(Personal Area Network)の一種である Bluetooth においては多くの機器が高い密度で密集すると考えられたため、スペクトラム拡散(Spread Spectrum)を用いて周波数衝突を避けようとした設計だと思われます。
しかしこの結果、レガシイ Bluetooth ではデバイス検索においてもマスター・スレーブ間のホッピングパターン同期手順が必要となり、ペアリングの成立していないデバイス検索には長くて数秒、ペアリングが成立しているデバイスの再接続にも最短で 0.1 秒程度の時間を要することになりました。これは携帯電話のヘッドセットのような用途には許容できる時間ですが、センサー・ネットワークのように「数秒に一度、十数バイト程度のデータ」を送信する用途においては消費電力や応答時間の点で不利になります。
Bluetooth LE ではチャネルの数を 79 から 40 に半減させて周波数精度の要求を下げ、40 本あるチャネルのうち 3 本を「Advertise Channel」として予約し、デバイス検出は常にこの 3 本の周波数を使うように仕様が単純化されました。このため、デバイスの検索〜接続〜通信に要する遅延時間は 10msec 未満に短縮されたと言われています。
[Connection Intervalの時間単位]
「Connection Interval」時間単位(1.25msec の整数倍)
[同時接続可能な台数]
レガシイ Bluetooth の一大制約だった「１台のマスターに同時接続・通信可能なスレーブ数が最大７台」という 3bit のリンクアドレス長は 32bit に大幅拡張され、実用上無制限のスレーブが接続可能になっています。
Bluetoothのはなし(5)｜Wireless・のおと｜サイレックス・テクノロジー株式会社![]()
上の記事と同じシリーズ。この回ではBluetoothを本気で使おうとすると必ず悩まされる「WiFiとBluetoothの干渉」問題について詳しくかつわかりやすく書かれています。
[WiFiとBluetoothの干渉]
WiFi(2.4GHz) と Bluetooth は同じ周波数帯域を使います。なので両者が同時に稼動すると干渉が発生することを避けられません。両者が同じ室内で稼動する程度であれば「ある程度」の干渉で済むのですが、携帯電話のように小型機器に WiFi と Bluetooth を実装するシステムでは深刻な影響が出ます。小型機器では実装面積が足りず WiFi と Bluetooth のアンテナが隣接することを避けがたい(場合によっては共用アンテナを使うこともある)ため、干渉の影響が桁違いに大きくなるためです。
[干渉による影響]
WiFi と Bluetooth の電波が衝突すると
- WiFi から見た場合：チャネル内に Bluetooth の電波が入ると、一部のサブキャリアが崩れる。
- Bluetooth から見た場合：ホッピング通信しているなかで WiFi チャネルと衝突したフレームが消える。
という影響が出ます。
WiFi と Bluetooth がぶつかると、WiFi はパケット損失を検出し送信レートを落とす(シンボル冗長度を上げ、変調精度を下げる)ため性能微減、Bluetooth は損失したパケットをタイムアウトで検出し再送する(このとき FH によって以前衝突したのとは違う周波数で再送される確率が高い)ので性能大減というような影響となって現われます。
[電波の強さ]
電波の強さも両者で異なっており、一般的な WiFi システムが送信出力 15dBm(30mW) 前後なのに対し、Bluetooth Class2 は 4dBm (2.5mW) 以下です。つまり一般的には、WiFi と Bluetooth がぶつかると Bluetooth が負けることが多いのです。
BLE - 通信の基礎 - エンジニアの備忘録![]()
[Connection Intervalの最小間隔]
Connection Intervalは、iOSに対応したBLE機器の場合、37.5msecが最小間隔になっており、それ以上の通信をおこなうことはありません。
そのため、Characteristicの読み書きには通常は 40msec ほどの時間が掛かると思ってプログラムを組む必要があります。各OSのBLE APIが非同期処理になっているのもこのような理由があるからと思います。
[送信データサイズ]
一回の通信でやりとりできるデータのサイズは 20バイトほどが基本単位になっているので、現在のBLE機器のCharacteristicのサイズも 20バイト以下になっているものが多いです。
BLE仕様では、より大きなCharacteristicのRead/Writeを可能にするプロトコルもありますが、それらをサポートしていないOSもあるので、当面は Characteristicは 20バイト程度以下と思ってよいと思います。
[Read/Writeの頻度について]
ひとつのRead/Writeをおこなった後に、その応答が返ってくる前に次のRead/Writeをおこなうことは、BLE仕様としては認められていないので、その点も注意が必要です。
大抵のOSはRead/Writeの要求をキューによりシリアライズしているようなので、特に意識する必要はなさそうですが、あまり大量のRead/Writeをおこなうと、キュー詰まりが起きて、レスポンスが悪くなることがあります。
効率よく通信をおこないたいのであれば、アプリケーションの実装側で Read/Writeの頻度やタイミングをうまく調整した方が良いでしょう。
[通信途絶によるコネクションクローズ後の再接続について]
BLE通信の Link Layerでは、GATTの通信の有無に関わらず、Connection Interval毎に常に通信をおこなっており、もし数秒間その通信が途絶えるとリンクが切れたと判断されて、コネクションがクローズします。
CentralまたはPeripheralのどちらかが明確にコネクションをクローズしたときはすぐに切断状態になりますが、上記の通信途絶によるクローズ直後は相手側がまだ切断を認識していないことがありますので、その場合、すぐには再接続ができないことになります。
本記事は随時更新していきます。