Bluetoothのペアリングできない問題をプロトコルアナライザで解析！

皆さん、こんにちは。技術専門商社のコーンズテクノロジー株式会社です。メーカーエンジニアの無線化を支援するため、ムセンコネクトの無線化講座で解説記事を掲載させていただくことになりました。

今回はその第二弾として、皆さんがBluetooth機器を使用し始める前に行っているペアリングと、そのペアリングができない問題についての解説記事になります。

Bluetoothのペアリングとは？

Bluetooth通信における「ペアリング」とは、ずばり「①接続相手を登録」して「②秘密鍵を交換」することを意味します。それによってお互いにしかわからない暗号化されたやり取りを行うことができます。そのため、ペアリングを行うことによって安全にBluetooth通信を行うことが可能になります。また再接続する際には、お互いに機器を覚えているため効率よく接続を開始することができます。

さて、機器同士がペアリングするまでには一連の流れがあります。まず接続相手を探し、相手が見つかったら接続して、最後にペアリングを行います。そんなペアリングに至るまでの過程が、一番最初に接続性の問題が発生しやすい部分でもあります。前回のブログにて、Bluetooth機器同士がペアリングを行う際には細かいやり取りを行っていることに触れましたが、そんなやり取りを、実際にプロトコルアナライザを使用してどのように解析できるのか解説いたします。

Bluetoothペアリングの処理の流れ

ペアリングするまでの手順は以下の通りです。

Bluetooth BR/EDR（Bluetooth Classic）の場合

1. Inquiry（問い合わせ）：　周辺のBluetooth機器を探す
2. Page（呼び出し）：　どちらがセントラルかペリフェラルなのか等、機器同士の情報を確認する
3. Connection（接続）：　接続をする
4. Pairing（ペアリング）：　暗号キー（Link Key）を交換し、暗号化されたやり取りを開始する

Bluetooth LEの場合

1. Advertising / Scanning（通知 / スキャン）：　周辺のBluetooth機器を探す
2. Initiating（接続リクエスト）：　どちらがセントラルかペリフェラルなのか等、機器同士の情報を確認する
3. Connection（接続）：　接続をする
4. Pairing（ペアリング）：　暗号キー（Long Term Key）を交換し、暗号化されたやり取りを開始する

実は、ユーザーからみるとペアリングまでの手順はBR/EDRとLEでは同じに見えますが、①と②の手順や暗号キーは異なります。

上記手順に従って④のペアリングが実施されます。この手順③と④（暗号化されたやり取りを開始するまでのこと）をまとめて「Bluetooth接続」とか「ペアリング」と呼ぶ方がいますが、Bluetoothの定義上では接続は手順③、ペアリングは手順④のことを指し、独立した異なる処理となります。

今回はプロトコルアナライザを用いて、上記手順を3つのステップで解析していきます。

プロトコルアナライザを用いたBluetoothペアリングの解析

ステップ1　ペアリング手順の開始時点を確認！

今回はとあるBluetooth BR/EDRのイヤホンとスマートフォンをペアリングしてみた際のやり取りを例に、Teledyne社のプロトコルアナライザで測定したログを見ていきます。

皆さんがBluetooth機器同士を初めてペアリングする場合は、必ず機器をペアリングモードに設定してからペアリングを行っていると思いますが、このモードではもう片方の機器に見つけてもらえるようにBluetoothのパケットを送信しています 。こちらが先程のInquiry又は Advertising/Scanningの部分になります。

Teledyne社解析ソフトウェア Wireless Protocol Suite(以下、WPS)には、Message Sequence Chart(以下、MSC)と呼ばれるBluetooth機器間のやり取りをまとめているウィンドウがあります。MSC内のControl Summaryには機器同士がペアリングするまでに行われたやり取りがまとめてあります。ペアリング関連のトラブルが起きた際にはまずここを確認するのをオススメします。

まず、そのControl Summaryを見てみると、New Connectionと書かれているパケットがあり、ここからPagingが開始されているのを確認できます。

また、Coexistenceと呼ばれる解析画面ではやり取りが行われたパケットの周波数ホッピングの様子が確認でき、InquiryからPagingが開始されたタイミングで挙動が変わっているのがわかります。問題なくペアリングまでの手順が開始されたことが確認できましたので、次に仕様書通りにやり取りが行われているか順を追って確認していきましょう。

ステップ2　機器同士の情報交換を確認！

まず機器同士がペアリングを始める前には、お互いの情報確認から始めます。今回の場合はセントラル側であるスマートフォンから、ペリフェラル側であるイヤフォンのBluetoothバージョンや対応している機能、機器名等の確認を行います。お互いの情報交換が完了してから、得られた情報を元にペアリングを開始します。このように相手が何者なのかしっかり把握することは安全性においても重要ですよね。

ペアリングは、リンクマネージャー層と呼ばれるプロトコルレイヤで行われます。そのため、リンクマネジャープロトコル(以下、LMP)のやり取りを確認することでペアリングや暗号化等の設定について読み解けます。MSCは、Bluetooth通信を各レイヤ毎にやり取りを分けており、その中でもLMPを選択することで、ペアリングまでのやり取りがSIGの仕様書のようにシーケンス図で確認できます。また、この画面上ではFeature request、 response等、ここで何が起こっているのか、Teledyneが独自にコメントを追加しています。この補足コメントによって、よりやり取りの流れが分かりやすく解析できます。

では、実際に得られた機器情報を見ていきましょう。まずSummary画面内のLMPタブを選択すると、その中にはversion_req、 version_res 等のやり取りがありました。このやり取りによってセントラル（スマートフォン）とペリフェラル（イヤホン）それぞれの基本情報（Bluetoothバージョンなど）を交換しています。その後に送られるfeature_req, feature_resでは対応しているBluetooth機能をお互いに交換しています。

それらの詳細な情報はWPS内にあるDecode画面で確認できます。こちらでは現在選択されているパケットの詳細な情報を見ることができます。またBluetoothのスタック構造より下位のBasebandレイヤから上位のアプリケーションレイヤに向かって分けられて表示されているため、それぞれのレイヤでどのようなやり取りが発生しているのか効率よく解析できます。

ここでversion_reqの「LMP」を拡張表示しますと、機器の情報が確認でき、feature_reqの「Feature Set」では自分のデバイスがそれぞれの機能に対応・非対応なのか確認できます。ここでは無事に情報交換が出来ていることが確認できましたので、次に行う接続要求について見ていきましょう。

ステップ3　接続開始時点を確認！

ステップ2の情報交換において、機器同士のBluetoothバージョンと対応機能に問題がなければ、接続するための要求を出します。MSC内のControl Summaryで①セントラルからコネクション要求送信し、②ペリフェラルから要求に返答しているのがわかります。その間には通信に必要なパラメータの設定が行われているのも確認できます。こちらで問題が起きている場合はLMP_not_acceptedと表示されていたり、ペリフェラルからの応答がきていない場合も考えられます。

機器同士の接続が完了したら、ペアリングするために必要な認証処理や暗号化キー交換処理を行います。先程と同じようにMSC内のLMPタブを確認すると、①認証処理が行われ、認証処理が完了すると、②暗号化情報を交換し、③暗号化されたやり取りを開始したことがわかります。

なお、先程のパケットをSummary画面のLMP内で確認すると、Decode内に詳細なパケット情報を見ることができます。併せてBaseband情報を確認すると、中にDecrypted by Bluetooth Comprobe: Yes/Noと表記されています。こちらはやり取りが復号されているかを確認できる項目ですので、問題なく暗号化された情報がやり取りできているかの指標にできます。今回の例ではペアリングまで問題なくやり取りが行われておりましたので、引き続き初めてデータ通信が始まるパケットを見てみましょう。

今回のイヤホンの例では音楽データを送っていますが、プロファイルはA2DPが使用されています。Summary内の「A2DP」より音楽データが送られ始めていることが確認できます。送られ始めるとTimeline内でパケットの様子が変わっていたり、Coexistence内で周波数ホッピングが変わっているのも確認できます。Decode内では実際に送られたAudioデータも見れます。

ペアリングで発生する問題について

上記の例では問題なくペアリングできた場合になりますが、ここからはペアリングするまでの間に問題があった例を見ていきます。Bluetooth接続できないという問題だけではなく、ペアリングを終えるまでの時間が長いという問題もあります。そういった問題もプロトコルアナライザがあれば丸見えにすることができます。ここでは時間がかかる例と切断が発生してしまった例を解説します。

ペアリングするまでに時間がかかる例

それではまずペアリングするまでに時間がかかった時のやり取りを見てみましょう。問題の例を、先ほどの3つのステップに沿って辿っていきますと、LMPで暗号化された通信を行う前に余分な処理が発生してしまっているのが確認できました。ペリフェラルであるイヤホンが、セントラルになろうとロールスイッチを依頼していますが、この時点で失敗が発生していました(図①)。その処理が発生してしまっているため、タイムロスが起こっています。さらに、その直後に暗号化された通信を開始しましたが、再度イヤホン側から暗号化された通信を止める依頼を出しています。それに対しスマートフォン側も合意し、一度暗号化されたはずの通信が止まってしまっています。

その後、再度ロールスイッチが失敗した後に、すぐにイヤホン側より通信再開の依頼を出しています。このような余分なやり取りが発生したことにより、ペアリングまでに時間がかかっていたことが分かりました。

図2の例では、スマートフォン側から敢えてペアリングを拒否した場合を測定してみました。LMP内を確認しますと、スマートフォン側から暗号化が失敗したことを通知した後、ペアリングを拒否したスマートフォン側から切断処理が行われています。Ctrl Summary内でも同様の切断処理（LMP_detach）が確認できます。

まとめ

今回のブログでは、最初につまずきやすいペアリングまでに発生する問題を、プロトコルアナライザでどう解析できるのか、3つのステップに渡って紹介しました。ペアリングはほとんどのBluetooth機器を使用する上で必要な手順となりますので、ペアリングまでの接続性向上はBluetooth通信全体の品質向上にも繋がります。

今後もBluetoothのトラブル解析や課題解決に役立つ情報を紹介する予定です。乞うご期待ください。

製品 / 測定・解析サービスについて

Teledyne LeCroy Frontline社※製 BluetoothプロトコルアナライザはBluetooth接続トラブル解析に役立ちます。

また、弊社ではBluetooth測定・解析サービスもご用意しております。