Wireless・のおと
サイレックスの無線LAN 開発者が語る、無線技術についてや製品開発の秘話、技術者向け情報、新しく興味深い話題、サイレックスが提供するサービスや現状などの話題などを配信していきます。
Bluetoothのはなし(2)
Bluetooth 4.0 は 2011 年 6 月に公開された、現時点における Bluetooth の最新仕様です。4.0 の特徴は「Low Energy(LE)」と「アトリビュート(ATT)」という仕様を取り入れたことですが、今回はこの２点に重点を置いて解説します。
ところで、前回の訂正です。前回 SCO パケットを『FEC つきの「EV」パケット』と『FEC の無い「HV」パケット』と解説しましたが、正しくは
HV = FEC あり(ただし HV3 を除く)、再送制御なし
EV = FEC なし、再送制御あり
でした(元記事は訂正済みです)。
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対応状況は読み取れない)
...ややこしいですね。この対応関係は 2.1(+EDR) までは比較的シンプルだったのですが、モードの増えた 3.0 以降でだんだん曖昧となり、「Bluetooth 3.0」を名乗っていても HS どころか EDR にも対応していない製品もあります。4.0 仕様のフルスペックになると PHY 層だけで４種類も(BDR, EDR, HS, LE)あり得るわけで、単に「Bluetooth 4.0 対応」とだけ書かれてもどの通信モードに対応しているのか判りません。だからといっていちいち全スペック並べて「Bluetooth 4.0LE+EDR+HS」と書くのもまどろっこしいです。
luetooth SIG でも、これが問題だと考えたのか「Bluetooth Smart」(LE 単機能デバイス)と「Bluetooth Smart Ready」(LE とレガシイ Bluetoothの両方に対応したデバイス」という用語を作って普及に努めています。尚、「レガシイ Bluetooth」というのは正式な用語ではありませんが、この記事中では 2.1 以前の BDR/EDR Bluetooth のことを便宜上そう呼ぶことにします。
PHY/MAC 層の違い
さて、Bluetooth LE はもともと、ノキア社が「Wibree」という開発コードで独自無線規格として開発していたものを Bluetooth SIG が採用したものです。この経緯が理由だと思いますが、レガシイ Bluetooth と LE の間には直接の互換性がありません。パケット長もアドレス長も CRC も暗号方式も違いますし、「周波数ホッピング」「ピコネット」「マスター・スレーブ」の概念も似て非なる実装になっています。
レガシイ 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 未満に短縮されたと言われています。
また、レガシイ Bluetooth では稼動中ずっと周波数が切り替わり続けます(※註)。このため Bluetooth チップには高精度なタイマーと高速の周波数切り替え回路の搭載が必須となり、チップ価格や消費電力を下げる障壁になっていました。Bluetooth LE ではマスター・スレーブがパケット交換を行う「コネクション」毎に、事前に交換された「Connection Interval」時間単位(1.25msec の整数倍)で周波数を切り替えるという「緩やかなホッピング」に変更されており、変調・周波数精度要求緩和などと合わせて価格・消費電力の低下が目論まれています。
(※註)ただし例外として、マルチスロットパケットの送受信中は複数スロットにわたって周波数が固定されます。
前回紹介したように、レガシイ Bluetooth には ACL(DM/DH) と SCO(HV/EV), マルチスロットや２倍・３倍速(EDR) など多種のパケットタイプが存在しますが、Bluetooth LE には１種類のパケット(データ長 2～39 バイト)しかありません。エラー自己訂正の FEC 機能も無くなり、その代わりエラー検出機能の CRC が 16bit から 24bit に強化されました。レガシイ Bluetooth の一大制約だった「１台のマスターに同時接続・通信可能なスレーブ数が最大７台」という 3bit のリンクアドレス長は 32bit に大幅拡張され、実用上無制限のスレーブが接続可能になっています。また暗号アルゴリズムは E3 から新しい AES-CCM になり、レガシイ Bluetooth には無かったデータ改竄防止機構(MIC)も追加されました。
細部仕様を列挙するのはこの辺でやめておきますが、このくらい「レガシイ Bluetooth」と「Bluetooth LE」は通信規格として違う、というところだけ気に留めておいてください。ただし上位層から見た場合、48bit MAC アドレス(ないし Bluetooth Device Name)を用いて通信相手を指定し、L2CAP を用いてデータを交換する API は同じになるように配慮されています。
アトリビュート
アトリビュートは Bluetooth 4.0 で新たに追加された仕様です。「Bluetooth LE」ではなく「Bluetooth 4.0」に適用される拡張仕様なので、アトリビュートは LE だけでなくレガシイ Bluetooth 上でも使用できることになっています。
アトリビュートは前回紹介したように、SNMP に似た「オブジェクト単位」の「GET/SET」を基本操作単位とする通信仕様です。アトリビュートの名前は 128bit の UUID で識別され(※註)、また「値」を持つアトリビュート(Characteristic と呼ぶ)には「型(Format)」情報も付加されます。１つの機能に関連するアトリビュートは「サービス」単位にまとめられ、この辺も SNMP の MIB に似ていると言えば似ています(まぁ、同じようなことをやろうとして似たようなものが出来るのは当たり前といえば当たり前ですが)。
(※註)ただし 128bit 全てを使って識別する必要は殆ど無いため、Bluetooth 共通の上位 112bit を省略した 16bit の短縮 UUID として扱われることが多いようです。また、プロトコル上での識別値は UUID とは別に与えられた 16bit の「ハンドル」で行われます。
アトリビュートの基本プロトコルを「ATT」と呼び、アトリビュートの組み合わせで特定の機能(サービス)を記述する体系を「GATT(Generic Attribute Profile)」と呼びます。GATT 以前の Bluetooth では、各プロファイル毎にほぼバラバラなデータ構造・パケットフォーマット・通信手順が決められていたわけですが、GATT によって「万歩計」「体温計」「血圧計」といった単機能のデバイスを共通の枠組みで扱えるようになった、という話は前回も紹介しました(※註)。2012 年 10 月時点で、約 20 種類のプロファイルが GATT 上に定義されています。
(※註)だったら何で最初からそうしなかったんだろう、Bluetooth 1.0 が設計された 1994 年には GATT と似たような SNMP が充分な実績をもって存在していたのに...とも思いますが、まぁ「大人の事情」のようなものがあったのでしょう。
繰り返しになりますが、アトリビュート(GATT プロファイル)は「Bluetooth LE」特有ではなくレガシイ Bluetooth にも実装できる仕様です。これは今後制定されるデバイス仕様をレガシイと LE 間で共通化すると同時に、まだ対応機器の少ない LE への移行をスムーズにしようという意図があるようです。
Bluetooth LE の現実と課題
このように、Bluetooth LE は単なる「Bluetooth の低消費電力版」ではなく、名前だけ同じで中身は別物と言って良い規格です。「Low Energy」の名が示すように低消費電力を最大のセールスポイントとしていますが、それにとどまらず実装の容易化、セキュリティの強化、同時接続台数の拡大など、過去 20 年ちかい Bluetooth の運用における反省を踏まえ、あえて互換性の多くを切り捨てることで新時代に対応しようとした規格と言えるでしょう。
では、この Bluetooth LE、実際どこまで普及しているのでしょうか？...少なくとも 2012 年 10 月現在において、LE 対応製品は両手の指に余るほどしか出ていないというのが現状です。
Bluetooth の次期仕様が省電力版を取り込むらしいという情報は、早くも 2009 年初頭にはネット上を飛び交っていました。気の早い記事では「対応製品は早ければ年内にも発売」と書かれていましたが、この手の予想は大抵外れるもので...それから毎年のように「早ければ年内」と言われつつ３年が経ちましたが、いまだ Bluetooth LE 対応製品はほとんど市場に出ていません。ただし新技術の市場リーダーともいえる Apple 社が LE 対応に熱心で、iPhone (4GS 以降), iPad (3G 以降) などの製品で LE に対応しているため、今年こそいよいよ「早ければ年内」には LE 対応のデバイスが次々に発売されるであろう、とも言われています。また Microsoft 社も Windows8 対応のロゴ認証条件に「Bluetooth 4.0 + LE 互換であること」を含めています。
まとめ
はたして Bluetooth LE は 2012 年(ないし 2013 年)に飛躍するでしょうか？個人的に、Bluetooth LE は有望かつ実用的な技術であり、何より Apple iPhone という強力なプラットホームに支持されていることから期待はできると思います(もっと端的に言えば、競合技術である Zigbee や ANT+ や Z-Wave よりも勝率は高い、と踏んでいます)。ただし、Bluetooth LE の未来も夢の薔薇色ではありません。レガシイ Bluetooth で不評だった適合ロゴ審査の費用・期間を改善すること、遅れている Windows や Linux での Bluetooth 4.0 対応 (GATT クライアント/アプリケーションの実装)を充実させること、複数の Bluetooth 仕様が併存する混乱を避けるための啓蒙活動をもっと展開してゆくこと、等々。こういった課題を果たさずに「Apple さんが味方に付いてるんだから勝ったも同然」と慢心していたならば、足元をすくわれて大コケする結果になるかも知れません。それはかつて「intel さんが味方に付いてるんだから」と、Wireless USB に運命を委ねて共倒れになった UWB が犯した過ちと同じ轍を踏むことになると思います。
さて次回は少し順序が逆になりますが、「超高速モード」Bluetooth 3.0+HS について説明したいと思います。
HV = FEC あり(ただし HV3 を除く)、再送制御なし
EV = FEC なし、再送制御あり
でした(元記事は訂正済みです)。
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対応状況は読み取れない)
...ややこしいですね。この対応関係は 2.1(+EDR) までは比較的シンプルだったのですが、モードの増えた 3.0 以降でだんだん曖昧となり、「Bluetooth 3.0」を名乗っていても HS どころか EDR にも対応していない製品もあります。4.0 仕様のフルスペックになると PHY 層だけで４種類も(BDR, EDR, HS, LE)あり得るわけで、単に「Bluetooth 4.0 対応」とだけ書かれてもどの通信モードに対応しているのか判りません。だからといっていちいち全スペック並べて「Bluetooth 4.0LE+EDR+HS」と書くのもまどろっこしいです。
luetooth SIG でも、これが問題だと考えたのか「Bluetooth Smart」(LE 単機能デバイス)と「Bluetooth Smart Ready」(LE とレガシイ Bluetoothの両方に対応したデバイス」という用語を作って普及に努めています。尚、「レガシイ Bluetooth」というのは正式な用語ではありませんが、この記事中では 2.1 以前の BDR/EDR Bluetooth のことを便宜上そう呼ぶことにします。
PHY/MAC 層の違い
さて、Bluetooth LE はもともと、ノキア社が「Wibree」という開発コードで独自無線規格として開発していたものを Bluetooth SIG が採用したものです。この経緯が理由だと思いますが、レガシイ Bluetooth と LE の間には直接の互換性がありません。パケット長もアドレス長も CRC も暗号方式も違いますし、「周波数ホッピング」「ピコネット」「マスター・スレーブ」の概念も似て非なる実装になっています。
レガシイ 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 未満に短縮されたと言われています。
また、レガシイ Bluetooth では稼動中ずっと周波数が切り替わり続けます(※註)。このため Bluetooth チップには高精度なタイマーと高速の周波数切り替え回路の搭載が必須となり、チップ価格や消費電力を下げる障壁になっていました。Bluetooth LE ではマスター・スレーブがパケット交換を行う「コネクション」毎に、事前に交換された「Connection Interval」時間単位(1.25msec の整数倍)で周波数を切り替えるという「緩やかなホッピング」に変更されており、変調・周波数精度要求緩和などと合わせて価格・消費電力の低下が目論まれています。
(※註)ただし例外として、マルチスロットパケットの送受信中は複数スロットにわたって周波数が固定されます。
前回紹介したように、レガシイ Bluetooth には ACL(DM/DH) と SCO(HV/EV), マルチスロットや２倍・３倍速(EDR) など多種のパケットタイプが存在しますが、Bluetooth LE には１種類のパケット(データ長 2～39 バイト)しかありません。エラー自己訂正の FEC 機能も無くなり、その代わりエラー検出機能の CRC が 16bit から 24bit に強化されました。レガシイ Bluetooth の一大制約だった「１台のマスターに同時接続・通信可能なスレーブ数が最大７台」という 3bit のリンクアドレス長は 32bit に大幅拡張され、実用上無制限のスレーブが接続可能になっています。また暗号アルゴリズムは E3 から新しい AES-CCM になり、レガシイ Bluetooth には無かったデータ改竄防止機構(MIC)も追加されました。
細部仕様を列挙するのはこの辺でやめておきますが、このくらい「レガシイ Bluetooth」と「Bluetooth LE」は通信規格として違う、というところだけ気に留めておいてください。ただし上位層から見た場合、48bit MAC アドレス(ないし Bluetooth Device Name)を用いて通信相手を指定し、L2CAP を用いてデータを交換する API は同じになるように配慮されています。
アトリビュート
アトリビュートは Bluetooth 4.0 で新たに追加された仕様です。「Bluetooth LE」ではなく「Bluetooth 4.0」に適用される拡張仕様なので、アトリビュートは LE だけでなくレガシイ Bluetooth 上でも使用できることになっています。
アトリビュートは前回紹介したように、SNMP に似た「オブジェクト単位」の「GET/SET」を基本操作単位とする通信仕様です。アトリビュートの名前は 128bit の UUID で識別され(※註)、また「値」を持つアトリビュート(Characteristic と呼ぶ)には「型(Format)」情報も付加されます。１つの機能に関連するアトリビュートは「サービス」単位にまとめられ、この辺も SNMP の MIB に似ていると言えば似ています(まぁ、同じようなことをやろうとして似たようなものが出来るのは当たり前といえば当たり前ですが)。
(※註)ただし 128bit 全てを使って識別する必要は殆ど無いため、Bluetooth 共通の上位 112bit を省略した 16bit の短縮 UUID として扱われることが多いようです。また、プロトコル上での識別値は UUID とは別に与えられた 16bit の「ハンドル」で行われます。
アトリビュートの基本プロトコルを「ATT」と呼び、アトリビュートの組み合わせで特定の機能(サービス)を記述する体系を「GATT(Generic Attribute Profile)」と呼びます。GATT 以前の Bluetooth では、各プロファイル毎にほぼバラバラなデータ構造・パケットフォーマット・通信手順が決められていたわけですが、GATT によって「万歩計」「体温計」「血圧計」といった単機能のデバイスを共通の枠組みで扱えるようになった、という話は前回も紹介しました(※註)。2012 年 10 月時点で、約 20 種類のプロファイルが GATT 上に定義されています。
(※註)だったら何で最初からそうしなかったんだろう、Bluetooth 1.0 が設計された 1994 年には GATT と似たような SNMP が充分な実績をもって存在していたのに...とも思いますが、まぁ「大人の事情」のようなものがあったのでしょう。
繰り返しになりますが、アトリビュート(GATT プロファイル)は「Bluetooth LE」特有ではなくレガシイ Bluetooth にも実装できる仕様です。これは今後制定されるデバイス仕様をレガシイと LE 間で共通化すると同時に、まだ対応機器の少ない LE への移行をスムーズにしようという意図があるようです。
Bluetooth LE の現実と課題
このように、Bluetooth LE は単なる「Bluetooth の低消費電力版」ではなく、名前だけ同じで中身は別物と言って良い規格です。「Low Energy」の名が示すように低消費電力を最大のセールスポイントとしていますが、それにとどまらず実装の容易化、セキュリティの強化、同時接続台数の拡大など、過去 20 年ちかい Bluetooth の運用における反省を踏まえ、あえて互換性の多くを切り捨てることで新時代に対応しようとした規格と言えるでしょう。
では、この Bluetooth LE、実際どこまで普及しているのでしょうか？...少なくとも 2012 年 10 月現在において、LE 対応製品は両手の指に余るほどしか出ていないというのが現状です。
Bluetooth の次期仕様が省電力版を取り込むらしいという情報は、早くも 2009 年初頭にはネット上を飛び交っていました。気の早い記事では「対応製品は早ければ年内にも発売」と書かれていましたが、この手の予想は大抵外れるもので...それから毎年のように「早ければ年内」と言われつつ３年が経ちましたが、いまだ Bluetooth LE 対応製品はほとんど市場に出ていません。ただし新技術の市場リーダーともいえる Apple 社が LE 対応に熱心で、iPhone (4GS 以降), iPad (3G 以降) などの製品で LE に対応しているため、今年こそいよいよ「早ければ年内」には LE 対応のデバイスが次々に発売されるであろう、とも言われています。また Microsoft 社も Windows8 対応のロゴ認証条件に「Bluetooth 4.0 + LE 互換であること」を含めています。
まとめ
はたして Bluetooth LE は 2012 年(ないし 2013 年)に飛躍するでしょうか？個人的に、Bluetooth LE は有望かつ実用的な技術であり、何より Apple iPhone という強力なプラットホームに支持されていることから期待はできると思います(もっと端的に言えば、競合技術である Zigbee や ANT+ や Z-Wave よりも勝率は高い、と踏んでいます)。ただし、Bluetooth LE の未来も夢の薔薇色ではありません。レガシイ Bluetooth で不評だった適合ロゴ審査の費用・期間を改善すること、遅れている Windows や Linux での Bluetooth 4.0 対応 (GATT クライアント/アプリケーションの実装)を充実させること、複数の Bluetooth 仕様が併存する混乱を避けるための啓蒙活動をもっと展開してゆくこと、等々。こういった課題を果たさずに「Apple さんが味方に付いてるんだから勝ったも同然」と慢心していたならば、足元をすくわれて大コケする結果になるかも知れません。それはかつて「intel さんが味方に付いてるんだから」と、Wireless USB に運命を委ねて共倒れになった UWB が犯した過ちと同じ轍を踏むことになると思います。
さて次回は少し順序が逆になりますが、「超高速モード」Bluetooth 3.0+HS について説明したいと思います。
