Wireless・のおと
サイレックスの無線LAN 開発者が語る、無線技術についてや製品開発の秘話、技術者向け情報、新しく興味深い話題、サイレックスが提供するサービスや現状などの話題などを配信していきます。
Bluetoothのはなし(3)
Bluetooth +HS は Bluetooth 3.0 で新たに追加された「超高速モード」です。今回はこの +HS についての話を幾つかご紹介したいと思います。
Bluetooth +HS とは
Bluetooth 3.0 の規格制定が始まったのは 2005 年頃だったと記憶しています。論点の一つは高速化でした。Bluetooth 2.0 で高速モード EDR (3Mbps) が導入されましたが、「従来の３倍！」と言ってみても所詮 WiFi 802.11b (11Mbps) の 1/3 以下であり、しかも当時 WiFi は 802.11g (54Mbps) が普及期を迎え、いわゆる「draft 11n」の 100Mbps 対応製品まで出荷されつつありました。
Bluetooth が高速化を目指した理由は WiFi 陣営の性能向上に対する危機感だけでなく、当時躍進著しかった携帯音楽プレイヤーへの適応を目論んだ節が伺われます。携帯音楽プレイヤーの記憶容量はGバイトの単位に達しつつあり、動画再生を可能とした機種も出現しつつありました。桁違いの情報量を扱う新世代の携帯情報機器に対応するには BDR の 1Mbps はもちろん EDR の 3Mbps でも全然不足で、桁違いの高速化が必要だと考えられたようです。
この課題に対して Bluetooth SIG 内部でどんな議論が展開されたのか詳しく知りませんが、彼等は独自の高速無線技術を新たに開発するのではなく既存の(他規格の)高速無線技術を流用し、その上に Bluetooth のスタックを「乗っける」かたちで高速化することを決定しました。それが +HS (High Speed) 仕様です。
なお前回も説明しましたが「Bluetooth 3.0」と「+HS」は同じものではなく、3.0 仕様でも +HS を持っていない製品もありますし、Bluetooth 4.0 に +HS を実装することも可能だということを理解しておいてください。世間的には「Bluetooth 3.0 = +HS」「Bluetooth 4.0 = LE」として扱われている場合も少なくありませんが、用語の定義は別なのです。(実にわかりにくいと私も思います)
AMP/PAL の仕組み
+HS は Bluetooth 仕様書のなかで「AMP」あるいは「PAL」とも呼ばれています。AMP というのは「Alternate MAC/PHY」の略で、Bluetooth に本来備わっている BDR や EDR の無線機能を使わず、別規格の無線を借りて(あるいは「乗っ取って」)使うという意味で、大雑把に言うとこの「乗っ取られる」別無線のハードウェアを指しています。PAL は Protocol Adaptation Layer の略で、Bluetooth ドライバと AMP のドライバをつなぐ中間層のことを指しています。
現状の Bluetooth 3.0+HS では、AMP として 802.11 無線 LAN (WiFi) を想定しています。「想定している」というのも妙に遠回しな言い方ですが、実は Bluetooth 3.0+HS 仕様はもともと UWB(MB-OFDM UWB) を使って高速化することが計画されていました。その時に UWB の MAC/PHY 層と Bluetooth を結合するために考えられた仕組みが PAL なのですが、肝心の MBOFDM-UWB が商業的に失敗したため、PAL の仕組みは(ほぼ)そのまま AMP 層を WiFi に「差し換えて」対応した、という経緯があります。しかし見捨てられた格好になった UWB 陣営としては、「ブルートゥースよ、お前もか」と言いたかったかも知れません。
Bluetooth over 802.11
さて WiFi を AMP として使うときに最大の障害となるのは、ピコネット方式の Bluetooth とハブ型(アクセスポイント＋ステーション)の WiFi ではネットワークトポロジーの概念が全く異なることです。例えば Bluetooth+WiFi つきパソコンと Bluetooth+WiFi つき携帯電話とがあったとして、PC-携帯間で Bluetooth 回線を接続することができても、WiFi 通信ができる保証はありません。両者は違う AP にアップリンクしているかも知れませんし、たとえ同じ AP にアップリンクしていたとしても、AP 側でステーション間通信(Intra-BSS)が禁止設定されていればステーション同士の通信はできません。
BT機器間でWiFi直接通信できる(かもしれない)パターン
BT機器間でWiFi直接通信できない(であろう)パターン
そこで Bluetooth 3.0+HS の AMP では、PAL が介入して WiFi を「乗っ取る」時、一時的に既存のネットワークから WiFi を切り離し、Bluetooth ノード同士として通信させる方法を採用しました。この「一時的な WiFi ネットワーク」は AdHoc モードではなく、アクセスポイントとステーションの超小規模版...いわゆる SoftAP に近いものです。ノード間の接続手順はインフラモードと同じビーコン検出→アソシエーション要求→アソシエーション応答(いわゆる 4-way handshake) ですし、使われるセキュリティモデルも 802.11i(WPA2) と同じ RSN(AES-CCMP) です。
WiFi の通信速度は 11Mbps (11b) または 54Mbps (11a/11g) ですが、Bluetooth 3.0+HS の通信速度は公称 24Mbps とされており、仕様書にも接続速度は「最大 30000Kbps を超えないものと仮定する」という記述が見られます。この数字が何処からどういう理由で定義されたものか私にはわかりません。
また AMP の仕様書を読む限り、3.0+HS の AMP は「SoftAP」と異なり１対１の接続に限定しているように見受けられます(既にAP として動作しているノードに追加接続する手順が見当たらない)。また AP 役を務めるのは常に接続要求を出した側(イニシエイター)と定義されていますが、AMP におけるイニシエイター／レスポンダーの関係と Bluetooth ピコネットのマスター／スレーブがどういう関係にあるのか(あるいは無関係なのか)も仕様書からはうまく読み取れません。
何だかいきなり「わからない」ことだらけの解説になってしまいましたが...私自身、Bluetooth 3.0+HS の実働状況を見たことが一度もないのです。そもそも、実際に Bluetooth を使っていて「遅くて困った」経験すらありません。なぜなら現在のところ、Bluetooth の主用途は高帯域を必要としないオーディオ転送(HSP/HFP/A2DP)とキーボード・マウス接続(HIDP)にほぼ限られているからです(※註)。そして Bluetooth +HS の立場を更に微妙にしているのは、WiFi-Direct という競合規格の存在です。
(※註)Bluetooth は遅いから大量データ転送には使わない、使わないから高速化への欲求も出てこないというニワトリタマゴの状態になっているのかも知れません。
WiFi Direct vs Bluetooth +HS
WiFi はアクセスポイントと子機をつないで使うのが一般的で、子機同士をつなぐ「アドホックモード」は 802.11b の普及初期には使われていたものの、その後は高速化やセキュリティ強化の仕様改良からも取り残され、「使わない・使えない」機能になっていました。WiFi Direct は WiFi において子機同士のアドホックな通信を再び実現しようという規格です。ただしいわゆるアドホックモードの拡張や発展型ではなく、端末同士がネゴシエーションしてアクセスポイント役(グループオーナー、GO)を決め、GO の決めた SSID と秘密鍵(PSK)を WPS (WiFi Protected Setup) 手順で交換することによって「アクセスポイント不要」かつ「設定いらず」の無線通信を実現する、というものです。
Bluetooth +HS と WiFi-Direct のアプローチはかなり異なりますが、必要となる道具立てや結果的に実現される機能はほぼ同じであることから、機能的には競合することになります。
WiFi Direct(以下、WFD) の利点はファイル共有やメディアストリーミングなど、大帯域を必要とするアプリケーションには既に対応する IP プロトコルが存在することから、既存の IP ベースのソフトウェアがそのまま動作するところにあります。ただし、この利点はそのまま欠点にもなっています。何故なら WFD では通信相手を検出・特定するプロトコルを規定しておらず、「UPnP, Bonjour, WSD, LDAP などを使う」としていますが、「これだけは最低限実装せよ」という規定が存在しない(※註)ことは異機種・異メーカー間での相互運用に困難をきたすことになり得るからです。
(※註)厳密にいえば MAC 層でのディスカバリプロトコルは規定されていますが、IP 層から上のディスカバリは実装依存になっているということです。
また、WFD にはレガシイ WiFi デバイスも接続できることになっていますが、WPS に対応していないレガシイデバイスを接続するためには、GO が持っている SSID と PSK を「何らかの方法」で読み出してレガシイ機器側に設定してやる必要があります。しかしどの機器が GO になるかは ネゴシエーションの結果次第によって変わってしまうため、一度設定したレガシイ機器が二度目には接続できなくなってしまう(毎回 GO を特定して SSID/PSK を再設定しなければならない)可能性もあります。このため、わざわざ WFD の規格に違反しても「常に GO として動く」オプションを設けた製品などもあるようです。
一方の Bluetooth+HS の場合、近隣ノードやサービスの検出には Bluetooth 層での Inquiry / Page / SDP のサービス検索手順があるので、WFD のように「一体何がつながり、誰がどんな機能を持っているのか判らない」という事態は原則として起こりません。Bluetooth での接続相手認識は MAC アドレス(BD_ADDR) で行われるため、IP アドレスさえも使いません。
つまり +HS には「Bluetooth 規格で実装済みのプロファイル」を使い、「通信相手同士が +HS 仕様に対応している」かぎり、ほぼ自動的に高速化の恩恵を受けられるという利点があります。しかし上でも述べたように、そもそも「Bluetooth で実現済みのプロファイル」には高帯域を必要とするようなアプリケーションがあまり無く、ファイル転送(FTP)やビデオストリーミング(VDP)のようなプロファイルは存在しても、それに相当する機能は IP ベースのプロトコルのほうが多用されているという現実があります(※註)。
(※註)BNEP というプロファイルを動作させることで、Bluetooth 上で IP を使うことも可能です。ただし BNEP には外部へのルーティング機能を持つ NAP モードと閉じたネットワークを実現する Group Ad-Hoc Mode があるとか、AP 役の NAP / GN とクライアント役の PANU で動作が分かれるとかの煩わしいところがあり、正直言って広くは使われていません。また BT+HS 上で IP を動作させることは、ますます WFD と似て非なるものを作ることにもなります。
まとめ
前回「有望かつ実用的な技術」と書いた Bluetooth LE に比べて、Bluetooth +HS については懐疑的な見解が並ぶ記事になってしまいました。+HS についてはどうも、存在しない問題に対する解決手段...「A solution looking for a problem to solve」と思えて仕方ないのです。もともと 2005 年当時に想定された「携帯音楽プレイヤーやデジタルカメラのデータ転送」という用途はながらく有線 USB によって満たされており(Wireless USB がそれを無線化しようとして失敗した話は既に紹介しました)、最近になって Eye-Fi や iTunes WiFi 同期など WiFi 無線 LAN を応用したシステムが登場してきました。「無線による高速データ転送」という需要が存在するとしても、少なくとも市場の大部分は Bluetooth +HS のほうを向いていません。今後もずっとそんな状態が続くとは断言できませんが、今のところ潮目が変わる兆候のようなものは感じられません。
ならば Bluetooth +HS ではなく WiFi-Direct が良いのかと聞かれれば、既に記したように私はあまり楽観的な見通しを持ってはいません。昨今、スマートフォンやスマートパッドの急速な普及と PC 黄金時代の陰りが見えてたことから「いよいよスマート家電の時代」と評する人も少なくなく、スマート家電時代に適した新しい接続技術として WiFi-Direct を掲げる人も多いのですが、私はPC 時代の終わり＝スマート家電時代の始まりという図式にも、スマート家電＝新しい無線規格が必要という図式にも必然性がある訳ではないと考えています。スマートフォンやスマートパッドが「薄く軽くなった PC」として情報ハブであり続け、既存の PC 向けインフラである WiFi アクセスポイント＋ステーションが(多少の不便さを伴いながらも)そのままスライドして家電ネットワークに適用されてしまうかも知れません。また、有線 USB での「(PC 介入を必要としない)機器同士の接続」をうたって何年も前に登場した USB On-The-Go が市場で成功していないことも、WiFi-Direct に対する不安材料のひとつです。
次回の題はまだ未定ですが、特に思いつかなければ Linux 上における Bluetooth 実装系である「BlueZ」の話を取り上げようかと思います。
Bluetooth 3.0 の規格制定が始まったのは 2005 年頃だったと記憶しています。論点の一つは高速化でした。Bluetooth 2.0 で高速モード EDR (3Mbps) が導入されましたが、「従来の３倍！」と言ってみても所詮 WiFi 802.11b (11Mbps) の 1/3 以下であり、しかも当時 WiFi は 802.11g (54Mbps) が普及期を迎え、いわゆる「draft 11n」の 100Mbps 対応製品まで出荷されつつありました。
Bluetooth が高速化を目指した理由は WiFi 陣営の性能向上に対する危機感だけでなく、当時躍進著しかった携帯音楽プレイヤーへの適応を目論んだ節が伺われます。携帯音楽プレイヤーの記憶容量はGバイトの単位に達しつつあり、動画再生を可能とした機種も出現しつつありました。桁違いの情報量を扱う新世代の携帯情報機器に対応するには BDR の 1Mbps はもちろん EDR の 3Mbps でも全然不足で、桁違いの高速化が必要だと考えられたようです。
この課題に対して Bluetooth SIG 内部でどんな議論が展開されたのか詳しく知りませんが、彼等は独自の高速無線技術を新たに開発するのではなく既存の(他規格の)高速無線技術を流用し、その上に Bluetooth のスタックを「乗っける」かたちで高速化することを決定しました。それが +HS (High Speed) 仕様です。
なお前回も説明しましたが「Bluetooth 3.0」と「+HS」は同じものではなく、3.0 仕様でも +HS を持っていない製品もありますし、Bluetooth 4.0 に +HS を実装することも可能だということを理解しておいてください。世間的には「Bluetooth 3.0 = +HS」「Bluetooth 4.0 = LE」として扱われている場合も少なくありませんが、用語の定義は別なのです。(実にわかりにくいと私も思います)
AMP/PAL の仕組み
+HS は Bluetooth 仕様書のなかで「AMP」あるいは「PAL」とも呼ばれています。AMP というのは「Alternate MAC/PHY」の略で、Bluetooth に本来備わっている BDR や EDR の無線機能を使わず、別規格の無線を借りて(あるいは「乗っ取って」)使うという意味で、大雑把に言うとこの「乗っ取られる」別無線のハードウェアを指しています。PAL は Protocol Adaptation Layer の略で、Bluetooth ドライバと AMP のドライバをつなぐ中間層のことを指しています。
現状の Bluetooth 3.0+HS では、AMP として 802.11 無線 LAN (WiFi) を想定しています。「想定している」というのも妙に遠回しな言い方ですが、実は Bluetooth 3.0+HS 仕様はもともと UWB(MB-OFDM UWB) を使って高速化することが計画されていました。その時に UWB の MAC/PHY 層と Bluetooth を結合するために考えられた仕組みが PAL なのですが、肝心の MBOFDM-UWB が商業的に失敗したため、PAL の仕組みは(ほぼ)そのまま AMP 層を WiFi に「差し換えて」対応した、という経緯があります。しかし見捨てられた格好になった UWB 陣営としては、「ブルートゥースよ、お前もか」と言いたかったかも知れません。
Bluetooth 3.0+HS のアーキテクチャ(Bluetooth over 802.11
さて WiFi を AMP として使うときに最大の障害となるのは、ピコネット方式の Bluetooth とハブ型(アクセスポイント＋ステーション)の WiFi ではネットワークトポロジーの概念が全く異なることです。例えば Bluetooth+WiFi つきパソコンと Bluetooth+WiFi つき携帯電話とがあったとして、PC-携帯間で Bluetooth 回線を接続することができても、WiFi 通信ができる保証はありません。両者は違う AP にアップリンクしているかも知れませんし、たとえ同じ AP にアップリンクしていたとしても、AP 側でステーション間通信(Intra-BSS)が禁止設定されていればステーション同士の通信はできません。
BT機器間でWiFi直接通信できる(かもしれない)パターンBT機器間でWiFi直接通信できない(であろう)パターンそこで Bluetooth 3.0+HS の AMP では、PAL が介入して WiFi を「乗っ取る」時、一時的に既存のネットワークから WiFi を切り離し、Bluetooth ノード同士として通信させる方法を採用しました。この「一時的な WiFi ネットワーク」は AdHoc モードではなく、アクセスポイントとステーションの超小規模版...いわゆる SoftAP に近いものです。ノード間の接続手順はインフラモードと同じビーコン検出→アソシエーション要求→アソシエーション応答(いわゆる 4-way handshake) ですし、使われるセキュリティモデルも 802.11i(WPA2) と同じ RSN(AES-CCMP) です。
WiFi の通信速度は 11Mbps (11b) または 54Mbps (11a/11g) ですが、Bluetooth 3.0+HS の通信速度は公称 24Mbps とされており、仕様書にも接続速度は「最大 30000Kbps を超えないものと仮定する」という記述が見られます。この数字が何処からどういう理由で定義されたものか私にはわかりません。
また AMP の仕様書を読む限り、3.0+HS の AMP は「SoftAP」と異なり１対１の接続に限定しているように見受けられます(既にAP として動作しているノードに追加接続する手順が見当たらない)。また AP 役を務めるのは常に接続要求を出した側(イニシエイター)と定義されていますが、AMP におけるイニシエイター／レスポンダーの関係と Bluetooth ピコネットのマスター／スレーブがどういう関係にあるのか(あるいは無関係なのか)も仕様書からはうまく読み取れません。
何だかいきなり「わからない」ことだらけの解説になってしまいましたが...私自身、Bluetooth 3.0+HS の実働状況を見たことが一度もないのです。そもそも、実際に Bluetooth を使っていて「遅くて困った」経験すらありません。なぜなら現在のところ、Bluetooth の主用途は高帯域を必要としないオーディオ転送(HSP/HFP/A2DP)とキーボード・マウス接続(HIDP)にほぼ限られているからです(※註)。そして Bluetooth +HS の立場を更に微妙にしているのは、WiFi-Direct という競合規格の存在です。
(※註)Bluetooth は遅いから大量データ転送には使わない、使わないから高速化への欲求も出てこないというニワトリタマゴの状態になっているのかも知れません。
WiFi Direct vs Bluetooth +HS
WiFi はアクセスポイントと子機をつないで使うのが一般的で、子機同士をつなぐ「アドホックモード」は 802.11b の普及初期には使われていたものの、その後は高速化やセキュリティ強化の仕様改良からも取り残され、「使わない・使えない」機能になっていました。WiFi Direct は WiFi において子機同士のアドホックな通信を再び実現しようという規格です。ただしいわゆるアドホックモードの拡張や発展型ではなく、端末同士がネゴシエーションしてアクセスポイント役(グループオーナー、GO)を決め、GO の決めた SSID と秘密鍵(PSK)を WPS (WiFi Protected Setup) 手順で交換することによって「アクセスポイント不要」かつ「設定いらず」の無線通信を実現する、というものです。
Bluetooth +HS と WiFi-Direct のアプローチはかなり異なりますが、必要となる道具立てや結果的に実現される機能はほぼ同じであることから、機能的には競合することになります。
WiFi Direct(以下、WFD) の利点はファイル共有やメディアストリーミングなど、大帯域を必要とするアプリケーションには既に対応する IP プロトコルが存在することから、既存の IP ベースのソフトウェアがそのまま動作するところにあります。ただし、この利点はそのまま欠点にもなっています。何故なら WFD では通信相手を検出・特定するプロトコルを規定しておらず、「UPnP, Bonjour, WSD, LDAP などを使う」としていますが、「これだけは最低限実装せよ」という規定が存在しない(※註)ことは異機種・異メーカー間での相互運用に困難をきたすことになり得るからです。
(※註)厳密にいえば MAC 層でのディスカバリプロトコルは規定されていますが、IP 層から上のディスカバリは実装依存になっているということです。
また、WFD にはレガシイ WiFi デバイスも接続できることになっていますが、WPS に対応していないレガシイデバイスを接続するためには、GO が持っている SSID と PSK を「何らかの方法」で読み出してレガシイ機器側に設定してやる必要があります。しかしどの機器が GO になるかは ネゴシエーションの結果次第によって変わってしまうため、一度設定したレガシイ機器が二度目には接続できなくなってしまう(毎回 GO を特定して SSID/PSK を再設定しなければならない)可能性もあります。このため、わざわざ WFD の規格に違反しても「常に GO として動く」オプションを設けた製品などもあるようです。
一方の Bluetooth+HS の場合、近隣ノードやサービスの検出には Bluetooth 層での Inquiry / Page / SDP のサービス検索手順があるので、WFD のように「一体何がつながり、誰がどんな機能を持っているのか判らない」という事態は原則として起こりません。Bluetooth での接続相手認識は MAC アドレス(BD_ADDR) で行われるため、IP アドレスさえも使いません。
つまり +HS には「Bluetooth 規格で実装済みのプロファイル」を使い、「通信相手同士が +HS 仕様に対応している」かぎり、ほぼ自動的に高速化の恩恵を受けられるという利点があります。しかし上でも述べたように、そもそも「Bluetooth で実現済みのプロファイル」には高帯域を必要とするようなアプリケーションがあまり無く、ファイル転送(FTP)やビデオストリーミング(VDP)のようなプロファイルは存在しても、それに相当する機能は IP ベースのプロトコルのほうが多用されているという現実があります(※註)。
(※註)BNEP というプロファイルを動作させることで、Bluetooth 上で IP を使うことも可能です。ただし BNEP には外部へのルーティング機能を持つ NAP モードと閉じたネットワークを実現する Group Ad-Hoc Mode があるとか、AP 役の NAP / GN とクライアント役の PANU で動作が分かれるとかの煩わしいところがあり、正直言って広くは使われていません。また BT+HS 上で IP を動作させることは、ますます WFD と似て非なるものを作ることにもなります。
まとめ
前回「有望かつ実用的な技術」と書いた Bluetooth LE に比べて、Bluetooth +HS については懐疑的な見解が並ぶ記事になってしまいました。+HS についてはどうも、存在しない問題に対する解決手段...「A solution looking for a problem to solve」と思えて仕方ないのです。もともと 2005 年当時に想定された「携帯音楽プレイヤーやデジタルカメラのデータ転送」という用途はながらく有線 USB によって満たされており(Wireless USB がそれを無線化しようとして失敗した話は既に紹介しました)、最近になって Eye-Fi や iTunes WiFi 同期など WiFi 無線 LAN を応用したシステムが登場してきました。「無線による高速データ転送」という需要が存在するとしても、少なくとも市場の大部分は Bluetooth +HS のほうを向いていません。今後もずっとそんな状態が続くとは断言できませんが、今のところ潮目が変わる兆候のようなものは感じられません。
ならば Bluetooth +HS ではなく WiFi-Direct が良いのかと聞かれれば、既に記したように私はあまり楽観的な見通しを持ってはいません。昨今、スマートフォンやスマートパッドの急速な普及と PC 黄金時代の陰りが見えてたことから「いよいよスマート家電の時代」と評する人も少なくなく、スマート家電時代に適した新しい接続技術として WiFi-Direct を掲げる人も多いのですが、私はPC 時代の終わり＝スマート家電時代の始まりという図式にも、スマート家電＝新しい無線規格が必要という図式にも必然性がある訳ではないと考えています。スマートフォンやスマートパッドが「薄く軽くなった PC」として情報ハブであり続け、既存の PC 向けインフラである WiFi アクセスポイント＋ステーションが(多少の不便さを伴いながらも)そのままスライドして家電ネットワークに適用されてしまうかも知れません。また、有線 USB での「(PC 介入を必要としない)機器同士の接続」をうたって何年も前に登場した USB On-The-Go が市場で成功していないことも、WiFi-Direct に対する不安材料のひとつです。
次回の題はまだ未定ですが、特に思いつかなければ Linux 上における Bluetooth 実装系である「BlueZ」の話を取り上げようかと思います。
