Bluetoothのはなし(1)
Bluetooth は 1994 年にスウェーデンのエリクソン社によって開発された短距離無線通信規格で、2.4GHz 帯、1MHz 帯域幅の GFSK 変調、79 チャンネルの周波数ホッピング拡散を用いています...というような解説はネット上の其処此処に転がっていますが、そこから先の情報はあまり見かけません。Bluetooth でスマートフォンにヘッドセットやキーボードをつなげることは判っていても、その中身がいったいどんな原理で動いているのかはあまり知られていないと思います。今回は Bluetooth の中身について紹介したいと思います。
マスター・スレイブ通信
Bluetooth は WiFi のようなアクセスポイントを持ちません。Bluetooth の通信は「ピコネット(piconet)」という単位で行われ、ピコネットは１台の「マスター」と、最大同時７台までの「スレーブ」によって構成されま す。例えばスマートフォンにキーボードをつなげる場合、スマートフォンがマスター、キーボードがスレーブとして動作しています。PC 同士の通信であっても、必ずどちらか一方がマスターでもう一方がスレーブです。
通信の主導権は常 にマスターが持ち、マスター→スレーブ方向のパケットは任意のタイミングで送ることができますが、スレーブ→マスター方向のパケットは「スレーブ何番、送 信せよ」という指令(POLL)がマスターから送られなければ送信することができません。この通信トポロジーは USB における「ホスト」と「デバイス」に似ています。
なお、Bluetooth においてはマスターとして動作しているノードが同時に他ピコネットのスレーブとして動作することも許しており、この動作を「スキャッターネット (Scatternet)」と呼んでいます。スキャッターネットは一見するとメッシュネットワークのように見えますが、接続状態の管理・制御機構もピコネット間のパケット伝達機構も無いため、メッシュとしては動作しません(※註)。あくまで「マスター機能とスレーブ機能が同時に動く(例えばスマー トフォンがマスターとしてヘッドセットに音楽データを流しながら、同時に PC に対してはスレーブとして接続してファイル同期を行う)」だけの機能です。
(※註)研究レベルではスキャッターネットを用いた Bluetooth メッシュが実装されたこともあるようですが、距離性能も速度性能もパッとしなかったようです。
リンク層プロトコル
WiFi は見かけ上「無線化されたイーサネット」であり、46～1500 バイトの可変長データに 48bit の送信元・送信先 MAC アドレスを持ったパケットを自在に交換できます。通常はこの上で TCP/IP プロトコルを動作させて使用します。
一方、Bluetooth における「パケット」の概念はイーサネットとは全く異なります。まず通信は 625 μ秒を単位とする「スロット」時間に同期して行われ、パケットの長さは必ず 625 μ秒の整数倍(奇数倍)に揃えられます。各ノードは 48bit の MAC アドレスを持ってはいますが、ピコネットの確立後は 3bit の「論理アドレス(Logical Transport Address)」がスレーブを識別する ID になります。Bluetooth の「同時最大７台」という制約はここから来ており、これが８ではなく７なのはアドレス 000 がブロードキャスト用に予約されているためです。
Bluetooth のパケットには主に「ACL(Asynchronous Connection Less)」と「SCO(Synchronous Connection Oriented)」の２種があります。ACL は一般のデータ転送に使われるパケットで、SCO は予約済み帯域・短レイテンシの音声転送に特化したパケットです(USB のアイソクロナスに近い)。
これらはリンク上でも異なるパケットタイプを与えられて区別されます。ACL パケットには FEC(エラー自己訂正)機能のついた「DM」パケットと FEC のない「DH」パケットがあり、一方 SCO にも FEC 無し・再送つきの「EV」パケット(Bluetooth 1.2 以降のみ) と FEC 付き・再送なしの「HV」パケットがあります。これに加えて上記に述べた「データ長に応じてスロット時間の整数倍」という区別があり、１スロットの FEC つき ACL パケットは「DM1」、３スロットの FEC なし SCO パケットは「HV3」のようにして記述されます。
Bluetooth 2.0 以降で拡張された高速モード(EDR:Enhanced Data Rate)では、GFSK に代わって QPSK や 8-PSK 変調を用いることで、同じタイムスロット内に２倍・３倍のデータ長を詰めこむパケットタイプが追加されました。これらは 2-DH1 (２倍レート、FEC 無しの１スロット ACL パケット)とか 3-DH5(３倍レート、FEC 無しの５スロット ACL パケット)のように表記されます。ややこしいですね。
これらのパケットタイプ種別と使い分けについてはエンドユーザーはもちろん、プログラマーも殆ど気にする必要はありません。Bluetooth においては L2CAP (Logical Link Control and Adaptive Protocol)という層がプログラマーから見た API になり、ソケットの確立やデータの送受信は L2CAP に対して行えば、通信状況と設定状態に応じて適切なパケットタイプを自動的に選択してくれる仕組みになっています。
トランスポート層プロトコル
Bluetooth の L2CAP は TCP/IP で言うところの IP のようでもあり UDP のようでもあり、一部 TCP 的な機能も持つという、ちょっと説明しにくい階層です。とりあえず、Bluetooth 上でパケットを送受信する際の API は L2CAP だと考えてください。L2CAP にはパケットの分割・再構成機能があるため、上位層からは DH や DM のパケット長制限を直接気にする必要がありません。また TCP/IP で言うところのポート番号のようなもの(PSM; Protocol/Service Multiplexer と呼ぶ 15bit の情報)も備えており、これによって複数のデータセッションを扱うことができます。
L2CAP はもともとパケット受信確認/再送を行わない UDP 的なパケット送信用 API として作られましたが、Bluetooth 1.2 以降では再送機能を追加して TCP 的な使い方もできるよう拡張されました。この再送つき L2CAP は登場当時 eL2CAP とも呼ばれましたが、今ではこの名前はあまり使われず、拡張機能の有無に関わらず「L2CAP」と呼ぶのが慣例になっているようです。
L2CAP の上位には「RFCOMM」というプロトコルも実装されています。もともと仮想シリアルポート用に開発されたものですが、パケット受信確認・再送を備えていたため、シリアルポートに限らず TCP 的な用途で使われていました。しかし、L2CAP に再送機能が実装された以降は次第に使われなくなっているようです。RFCOMM にもポート番号に相当する概念として「チャネル」がありますが、チャネル番号は 5bit しかなく 1～30 までしか使用できません。
Bluetooth のトランスポート層として(L2CAP の上で) TCP/IP を動かすことも可能ではあり、BNEP; Bluetooth Network Encapsulation Protocol) と呼ばれています(※註)。Bluetooth が低迷していた 2002 年頃には「BNEP こそ Bluetooth 普及のブレイクスルー！」とか騒がれたこともありましたが、はっきり言ってほとんど使われていません。TCP/IP を使うなら WiFi のほうがよほど速くて安定していますし、逆に TCP を使うと「アドレス設定不要」「ディスカバリ」「プロファイル」など Bluetooth の特長が色褪せてしまうため、わざわざ Bluetooth 上で TCP を使うメリットが感じられないためです。
BNEP と似て非なるものに、携帯電話を無線モデムがわりに使う DUP; Dial Up Profile というプロファイルもありますが、いまどきの移動データサービス(3.5G, 4G, LTE など)のダウンリンク速度は Bluetooth EDR の 3Mbps よりずっと速いため能力的に不足なうえ、大抵の携帯やモバイルルータには WiFi のアクセスポイント機能が入っているので、これもあまり使われていません。
(※註)昔は LAP; LAN Access Profile という仕様もありましたが、もう使われていません。
ペアリング
WiFi の暗号通信、WEP や WPA-PSK ではアクセスポイントとノードのそれぞれにパスワードを設定しますが、Bluetooth ではユーザーがパスワードを打ち込むことはありません。暗号通信確立時、マスターとスレーブの間では乱数で生成された 128 ビットの共有秘密情報(リンクキー)が交換され、以降の通信はこのリンクキーから生成されたセッション・キーで暗号化されます。このリンクキー交換・マスタースレーブ関係の確立手順を「ペアリング(Pairing)」と呼びます。
リンクキーの交換 は公開鍵暗号で暗号化されますが、公開鍵暗号じたいの正当性検証は人間の介入を必要とし(※註)、このために幾つかの確認手順が備えられています。Bluetooth 2.1 以前の仕様では４桁の確認コードを用いる「PIN 方式」だけでしたが、Bluetooth 2.1 以降では Secure Simple Paring (SSP) という仕様が拡張され、
- 確認なし(Just Works)
- ６桁の認証コードを表示しての一致確認 (Numeric Comparison)
- ６桁の認証コードを打ち込むことによる確認 (Passkey Entry)
- Bluetooth 以外の通信 (USB や NFC) による確認 (Out-Of-Band, OOB)
の ４方式が追加されました。確認方式が複数用意されたのは、例えばマウスのように入力も表示機能も持たないデバイス(Just Works)、プリンターのように表示能力だけを持つデバイス(Numeric Comparison)、キーボードのように入力機能だけを持つデバイス(Passkey Entry)といったように、ホスト・デバイスの能力に応じて適切な認証方式が使えるように配慮されたからです。しかし装置の組み合わせによって認証方式 が変わるのは少々混乱の元ですし、４桁の PIN 認証しか持っていない古い装置もまだ残っていたりするので、Bluetooth を使う上でまず「何で毎回やり方が変わるの？！」と首を傾げるのがこのペアリング操作だと思います。
(※註) WiFi におけるエンタープライズセキュリティ(EAP)では、「証明書つき公開鍵」を使うことで人間の介入の必要性を無くしています。しかし証明書の生成や登録の操作が煩雑で専門知識を必要とするため、ネットワーク管理の専門家がついている企業ネットワーク以外では滅多に使われません。
プロファイル
WiFi の上ではメールや WEB やファイル交換プロトコルが動作しますが、これらのプロトコル仕様は決して WiFi 特有のものではなく、イーサネットや ADSL でも同じように使うことのできる「インターネット(TCP/IP)」の標準仕様です。一方 Bluetooth の場合、ヘッドセットやキーボードやプリンターをつなぐプロトコルに至るまで、Bluetooth SIG の定めた標準仕様に従って動作します。これを「プロファイル」と呼んでいます。
プロファイルはメーカーや機種の違いに関わらず、同じ機能であれば 同じように使えることを目的として定められた仕組みです。これはある面では大成功しており、例えば携帯電話と Bluetooth ヘッドセットの組み合わせが「相性」で動作しない問題はほとんど起きません。しかし何十種類か定義されているプロファイルのなかで、ヘッドセットのように 多用されているのは十指に満たないほどです。１機能＝１プロファイルに対応させようとしたのは良かったのですが、携帯ヘッドセットのように機能と製品が綺 麗に１対１に対応する例はむしろ少なく、例えばプリンターに至っては使用想定の違いにより SPP(仮想シリアルポート), HCRP(仮想パラレルポート), BIP(静止画転送), BPP(標準プリンタ) と４つもの「印刷系」プロファイルが乱立することになってしまいました。
またプロファイルの制定には長い時間と労力(そして金額)がかかるため、 例えば「Bluetooth 腕時計」とか「Bluetooth 万歩計」のような製品を思いついたとしても、その為だけに「腕時計プロファイル」や「万歩計プロファイル」を制定するわけにはなかなかゆきません。従来こ ういった用途への応用は「シリアルポート(SPP)」という扱いにしていましたが、当然ながらシリアルポートは「データ通信」以上の仕様を何も規定しない ため、本来の目的である相互運用性としてはあまり役に立ってはいませんでした。
最新仕様の Bluetooth 4.0 では、新たにアトリビュート(GATT; General Attribute Profile)という概念が導入されました。これは TCP/IP 上の SNMP に似たもので、「型」と「名前」を持つ「アトリビュート」に対して「読み「書き」を行うことで通信を実現するものです。たとえば万歩計なら「歩数」を数え る「整数型」のアトリビュートを実装すれば良いし、腕時計なら「現在時刻」を示す「時刻型」のアトリビュートを実装すれば良い、という具合に。アトリ ビュートの「名前」は 128bit の UUID で定義され、どの UUID が何を意味するかについては Bluetooth SIG の「Assgined Numbers」で管理されます。
この仕組みによって、同じ「GATT プロファイル」の枠内で様々なデバイスに相互運用性を持たせて定義することが可能になり、特に医療系機器への Bluetooth 普及の鍵として期待されています。しかし従来の Bluetooth 仕様とはかなり異なる概念だけに、特にホスト側の実装はなかなか進んでいないようです。
サービスディスカバリ
Bluetooth の特長のひとつは、デバイス・サービス検索機能がプロトコル仕様に含まれていることです。これに対して TCP/IP の世界にはメーカー独自仕様を含めると軽く百種類以上もの検索プロトコルがありますが、一般的に相互運用性をもって使えるプロトコルは正直に言って１つも ないというのが情けない現状です。
Bluetooth の検索はまず「問い合わせ(Inquiry)」という手順で、周辺にあるデバイスの一覧を得ることから始まります。この時点で判るのは MAC アドレスだけ(※註)なので、次に「呼び出し(Page)」という手順でマスター・スレーブ関係を確立し、「サービス検索(SDP; Service Discovery Protocol)」という手順で情報を交換して製品名や製品の機能(プロファイル)を取得します。
(※註)Bluetooth 2.1 以降では Inquiry 返答に詳しい製品情報を乗せる EIR (Extended Inquiry Response) という仕様が追加されましたが、あまり広くは使われていない様子です。
多 くの Bluetooth 製品(ヘッドセットやキーボード)は「通常の運用モード」と「ペアリングモード」を持っており、ペアリングモードの時のみ検索に応答する仕様になっていま す。大抵の場合、ボタンを１０秒など押し続けると LED が点滅をはじめ、この状態で PC や携帯からデバイス検索をかけると「VoiceLink VLC-102 が見つかりました」のように表示され、それを選択してペアリング手順をかけると LED 点滅が消えて通常運用モードとなって検索に応答しなくなります。「通常運用で検索に応答しない」のはセキュリティ上、運用中のデバイスを無作為に検索して 割り込みやデータ盗聴をかけるハッキング行為を防ぐ意図があるためです。
まとめ
以上、駆け足で Bluetooth の技術的特徴を述べてみました。註と略語だらけになってしまいましたが、それだけ Bluetooth というのはとっつきにくい仕様だと思います。20 年近い歴史のなかで何度も仕様追加と改定を行ってきたことも判りにくさに輪をかけており、しかもネット上に転がっている Bluetooth の解説は新旧ごた混ぜなので鵜呑みにするとえらい遠回りを強いられることがあります(このブログだっていつ時代遅れになるか判りません ;-)。
次回は Bluetooth の最新仕様、Bluetooth 4.0 (LE) について踏み込んでみたいと思います。