【サルでもわかるBLE入門】（13）Bluetooth LEの再送と信頼性

こんにちは。ムセンコネクト三浦です。

今回も「サルでもわかるBLE入門」と銘打ってお話していこうと思います。
BLE初心者の方でも理解をしてもらえるように、できるだけわかりやすく解説していきます。

電波環境が悪いと送信データが欠けてしまう？？

今回は『Bluetooth LEの再送と信頼性』についてのお話しです。

Bluetooth LE通信について良く聞かれる質問の一つに、「電波環境が悪いと、送信したデータが欠けてしまうことがあるんですか」という質問があります。

無線は有線と比べて信頼性が低い通信です。送信したパケットが相手に届かないことはよくある話です。
「あいうえお」と送ったデータが、相手には「あいう　お」と欠けて届くことがありそうに感じます。

でも、先に結論からお話すると、先程の質問への回答は「大丈夫です。Bluetooth LEでは送信したデータが欠けることはありません」という回答になります。

それでは、どのような仕組みがあるかを見ていきましょう。

今回お伝えする内容は、概ねBluetoothのICの中で自動的に行われる仕組みなので詳しく覚える必要はありません。
「へー、そういう仕組みがあるんだ」と流し読みするくらいで大丈夫です。

無線電波の干渉（衝突）

最初に無線電波の干渉（衝突）のお話をします。
実際には電波は目に見えないので、イメージとして掴んでおきましょう。

Bluetooth LEで利用される2.4GHz帯はISMバンドと呼ばれ、無線局の免許が無くても自由に利用できる周波数です。

コードレスホンや電子レンジ、無線LAN機器、Bluetooth機器などの色々な電子機器が2.4GHz帯の周波数を利用しているため、混雑していてそれぞれの電波が衝突しやすくなっています。

電波と電波が衝突すると、どちらの電波もダメージを負います。どのようなダメージを負うかはわかりません。
ダメージを負っても無事に相手に届くこともありますし、相手が内容を理解できなくなるような致命的なダメージを負うこともあります。

弱い電波の方が衝突したときにダメージを受けやすく、強くしっかりした出力の電波の方が衝突しても相手に届きやすくなります。

Bluetooth LEには周波数ホッピングという基本的な仕組みがあります。

Bluetooth LEでは周波数を高速に切り替えながら通信をするため、瞬間的に他の通信の電波とぶつかっても、連続して電波がぶつからないようになっています。

周波数ホッピングは以下の記事で詳しく紹介しています。

Bluetooth LEにはそもそも電波の衝突をできるだけ回避する仕組みがあるわけです。
次に、電波が衝突してダメージを受けた場合にどうなるか、もう少し具体的にイメージしましょう。

Bluetooth LEはデジタル信号ですので、データ内容は「0」と「1」で表現されます。

送信側が「00111100」というデータを送ったつもりが、電波の衝突によってダメージを受けるとデータ内容が崩れてしまい、相手は「10111100」として間違って受け取ってしまうかもしれません。

もしも、Bluetooth LE対応の心拍計が「心拍は60bpmです」と送ったデータが、「心拍は188bpmです」のように間違ったデータとして相手に届いてしまう状況があると、システムとして困ってしまいます。

そうならないようにBluetooth LEには、例え電波の衝突でデータ内容が壊れてしまったとしても、受け取った相手が壊れたデータを採用しないようにする仕組みが用意されています。

次の章ではその仕組みを紹介していきます。

誤り検出と再送

パケットフォーマット

まずはBluetooth LEのパケットフォーマットを確認しましょう。
Bluetooth LE接続した後、ペリフェラルとセントラルが1対1で通信する場合のパケットです。

信頼性と再送に関わるフィールドとしてCRCとNESN、SNについて説明していきます。

CRC（Cyclic Redundancy Check：巡回冗長検査）

Bluetooth LEのパケットには、必ずパケットの最後付近にCRC（Cyclic Redundancy Check）というフィールドが含まれています。CRCはデータの誤り検出に利用されるフィールドです。
電波の衝突等が原因で送信データが意図せず破損してしまった事を検出するための仕組みです。

送信側は電波を送信する際に、CRCアルゴリズムを用いてパケット内のビットデータを計算してCRC値を算出します。それにより得られた24ビットのCRC値をパケットに追加して送信します。
受信側がパケットを受信すると、送信側と同じ様にCRCアルゴリズムを用いてCRC値を再計算します。受信側が計算したCRC値と、パケットに含まれる（送信側が計算した）CRC値を比較します。
比較してCRC値が異なる場合、送信側が送ったパケットが、受信側に正しく届いていないと判断して、そのパケットを破棄します。

データが破損したときの処理イメージは以下のようになります。

このように、CRCの仕組みがあることで、データの内容が壊れたパケットを破棄することができ、意図しないデータが採用されることを防ぐことができます。

では、破棄されたパケットはどうなってしまうのでしょうか？　データが欠落してしまっても困ってしまいます。
Bluetooth LEではデータが相手に届かなかったときに再送する仕組みがあります。

SN、NESN

もう一度パケットフォーマットの図を見てみましょう。
SN (Sequence Number)と、NESN (Next Expected Sequence Number)という、それぞれ１ビットのフィールドがあります。

Bluetooth LE接続をした後、ペリフェラルとセントラルが1対1の通信をしているときに、相手にデータが届いているか確認し、もし届いていなかったら再送するための仕組みに利用されます。

SNは送信されたパケットの順序を示すために利用されます。受信側は相手から送られてきたSNをチェックすることで、パケットの受信順序が正しいか、欠落しているパケットがないか確認することができます。

NESNは、受信側が次に期待するSNを示す為に利用されます。送信側は受信側から送られてきたNESNを確認することで、受信側がどのパケットを期待しているか確認することができます。つまり、受信側がどのパケットまで正常に受信できたかを知ることができます。

正常にやりとりができている時

　Bluetooth LE接続が確立した後、最初はSN、NESNは0からスタートします。

1. デバイスAはSN=0でデータ「あいう」を送信します。
2. デバイスBはNESN=0を期待している状態で、SN=0を受信したのでデータ「あいう」を採用します。
3. デバイスBはNESNを+1して、NESN=1のパケットをデバイスAに送ります。
   つまり、次のパケット（SN=1のパケット）を要求します。
4. デバイスAはNESN=1のパケットを受信したことで、相手が正常に受信できたことを知ります。
   デバイスAはSNを+1して、SN=1で次のデータ「えおか」を送信します。
5. デバイスBはNESN=1を期待している状態で、SN=1を受信したのでデータ「えおか」を採用します。
6. デバイスBはNESNを+1して、NESN=0のパケットをデバイスAに送ります。
   つまり、次のパケット（SN=0のパケット）を要求します。　

　以降、同じ様に繰り返していきます。

送信されたデータを受信側が受信できなかった時

　次に、受信側（デバイスB）がデータを受信できなかった時の処理を見てみましょう。　

1. デバイスAはSN=0でデータ「あいう」を送信します。
2. デバイスBはNESN=0を期待している状態で、SN=0を受信したのでデータ「あいう」を採用します。
3. デバイスBはNESNを+1して、NESN=1のパケットをデバイスAに送ります。
   つまり、次のパケット（SN=1のパケット）を要求します。
4. デバイスAはNESN=1のパケットを受信したことで、相手が正常に受信できたことを知ります。
   デバイスAはSNを+1して、SN=1で次のデータ「えおか」を送信します。
   ところが、このパケットがCRCエラー等で、デバイスBに正常に届かなかったとします。
5. このとき、デバイスBは応答を返しません。
6. デバイスAは応答がないので再送が必要と判断して前回と同じ SN=1でデータ「えおか」を送信します。
7. デバイスBはNESN=1を期待している状態で、SN=1を受信したのでデータ「えおか」を採用します。

受信側の応答を送信側が受信できなかった時

　次に、送信側（デバイスA）が受信側の応答を受信できなかった時の処理を見てみましょう。

1. デバイスAはSN=0でデータ「あいう」を送信します。
2. デバイスBはNESN=0を期待している状態で、SN=0を受信したのでデータ「あいう」を採用します。
3. デバイスBはNESNを+1して、NESN=1のパケットをデバイスAに送ります。
   つまり、次のパケット（SN=1のパケット）を要求します。
4. デバイスAはNESN=1のパケットを受信したことで、相手が正常に受信できたことを知ります。
   デバイスAはSNを+1して、SN=1で次のデータ「えおか」を送信します。
5. デバイスBはNESN=1を期待している状態で、SN=1を受信したのでデータ「えおか」を採用します。
6. デバイスBはNESNを+1して、NESN=0のパケットをデバイスAに送ります。
   つまり、次のパケット（SN=0のパケット）を要求します。
   ところが、このパケットがCRCエラー等で、デバイスAに正常に届かなかったとします。
7. デバイスAは応答がないので再送が必要と判断して前回と同じ SN=1でデータ「えおか」を送信します。
8. デバイスBはNESN=0を期待している状態で、SN=1を受信したのでデータ「えおか」を破棄します。
   デバイスBが前回受信したデータと同じ内容を重複して受信するのを防ぎます。

データの信頼性

このような仕組みによって、Bluetooth LEのデータは相手に確実に届くようになっています。

とはいえ、電波状態が悪い環境では以下のような問題につながります。

• 再送の頻度が増えてスループットが低下してしまいます。
• パケットが相手に届かない（CRCエラーで破棄される）ことが連続すれば、いずれはスーパービジョンタイムアウトが発生し、Bluetooth LEの通信接続が切断されてしまいます。
• 継続的にサンプリングしたセンサ情報を相手に送るようなシステムの場合、パケットの再送が頻繁になると、データ詰まりを引き起こし、送信バッファがオーバーフローして結果的にデータが欠けることがありえます。

Bluetooth LEに限らず、無線を利用する場合はできるだけ電波環境が良いところで利用するようにしましょう。

今回はBluetoothLEの電波の信頼性と再送についてお話しました。
次回もBluetooth LEの技術要素について深堀りしてお話したいと思います。

無線化講座のサルでもわかるシリーズはこちら