2024.02.29

【事例紹介・Bluetooth測定・解析サービス】Bluetooth接続不具合におけるOS別問題分析:株式会社ムセンコネクト様

WEBマガジン分析・計測

  • TOP>
  • 特集>
  • 【事例紹介・Bluetooth測定・解析サービス】Bluetooth接続不具合におけるOS別問題分析:株式会社ムセンコネクト様
コーンテクノロジー
この記事の監修者
コーンズテクノロジー編集部
コーンズテクノロジーでは先進的な製品・技術を日本産業界へ紹介する技術専門商社として、通信計測・自動車・防衛セキュリティ・電子機器装置・航空宇宙・産業機械といった技術分野のお役立ち情報を紹介しています。

はじめに

弊社のBluetooth測定・解析サービスはご存じでしょうか。ご興味をお持ちの方も多いと思います。そこで、株式会社ムセンコネクト様(以下、ムセンコネクト)でお取り扱いBluetoothモジュールに対して行った弊社のBluetooth測定・解析サービスの実例を通して、Bluetooth測定・解析サービスの内容をご紹介させていただきます。株式会社ムセンコネクト様(以下、ムセンコネクト)にサービスを体験いただくにあたり、あえて不具合がある状態のLINBLE(ムセンコネクト社製BLEモジュール)をお預かりして我々が測定・解析し、どこに問題があるのか、改善点としてどんなことが提案できるのか探りました。

※本不具合については既に修正されております

 

Bluetooth接続時の課題

LINBLEとスマホ/タブレット/パソコンとのBluetooth接続において、iOSとの接続は問題なく、Android/Windowsでの接続ができないという不具合がありました。Android/Windowsでも接続できるようにするにはどうすれば良いのか、問題分析と改善点の把握が必要でした。

 

Bluetooth測定・解析サービス内容

まず、事前の打合せにて不具合の現象をヒアリングした上で、目的や測定環境や測定項目などを明確にし、Bluetoothプロトコルアナライザを用いて実際の測定を行いました。その後、測定したデータの解析を行い、課題や改善策をレポートいたしました。以下が今回のサービス内容の実際の流れになります。

 

①目的の明確化

今回の目的として「LINBLE(ペリフェラル)と対向機(セントラル)の構成における挙動を測定し、対向機ごとの挙動の違いについて解析を行う」ことに定めました。

 

【図1:測定イメージ】

測定イメージ

 

②測定環境/被試験機材の検討

続いて、解析に必要となる測定環境、測定機材を検討しました。測定環境では、妨害波に対する検証や実際に発生している現場検証が必要かどうかが重要となります。今回は、事前ヒアリングにて接続できなくなるという現象は「最初の1回以降、2回目から通信ができなくなる」ということを確認しました。つまり、環境に関係なく該当の端末ではこの共通の挙動が発生していたと考えられます。よって不具合は妨害波の影響によるものとは考えにくいため、一般的なオフィス環境にて実施することとしました。測定機材としては、LINBLEと挙動の違いが見られたiPhone(iOS)/Android/Windowsの以下3端末を用意しました。

 

【図2:測定機材】

測定機材

 

③測定範囲/測定方法の確認

測定機材が決まりましたら、測定する範囲もお客様と明確にし、測定内容を詰めていきます。今回は図3の点線(赤色)のBluetooth部分が測定範囲になりました。

 

【図3:測定範囲】

測定範囲

 

④測定/解析ポイントの検討

今回は事前にLINBLEをお預かりし、測定/解析ポイントを検討しました。このようにヒアリングだけでは見えない部分についてを実際にデバイスを動作させながら確認していくこともあります。確認した結果、各対向機と新規接続(1回目)/再接続(2回目)のデータを取得し、Bluetoothがつながるまでのプロセス(図4)の比較解析を行うことにしました。特にGeneric Attribute Profile (GATT)におけるBluetoothプロトコルスタックが原因の可能性があると判断し、各レイヤの挙動を解析していきました。

 

【図4:Bluetoothがつながるまでのプロセス (LEの場合)】

Bluetoothがつながるまでのプロセス

 

【図5:Bluetooth GATT構成(階層イメージ図)】

Bluetooth-GATT構成

 

⑤Bluetooth通信データ測定・解析作業

⑤-1:iPhone(iOS)との接続

「最初の1回以降、2回目から通信ができなくなる」という観点で、iPhoneと新規接続(1回目)/再接続(2回目)のデータを取得し、比較解析を行いました。

⑤-1-1:Advertising/Scanningの確認

1回目/2回目共に、アドバタイズパケットの送信およびスキャンリクエストへの応答が問題なく行われていました。

 

【図6:iPhone(iOS)におけるAdvertising/Scanningのやり取り】

iPhoneiOSにおけるAdvertising・Scanningのやり取り

⑤-1-2:Initiatingの確認

1回目/2回目共に、CONNECT_INDパケットの内容に大きな変化は見られませんでした (Connection Interval:22.50ms)。

 

【図7:iPhone(iOS)におけるInitiatingのやり取り】

iPhoneiOSにおけるInitiatingのやり取り

⑤-1-3:Connectionの確認

1回目/2回目共に、データチャネルでの通信も正常に行われていた (Connection Interval:22.50ms)。

 

【図8:iPhone(iOS)におけるConnectionの遷移】

iPhoneiOSにおけるConnectionの遷移

⑤-1-4:Pairingの確認

ボンディング(暗号化キーを保存)が行われるため、1回目でSMP(Security Manager Protocol)でペアリングプロセスが実行され、2回目はSMPの処理が行われていませんが、特に問題なく暗号化も行われていました。

 

【図9:iPhone(iOS)におけるPairingのやり取り】

iPhoneiOSにおけるPairingのやり取り

⑤-1-5:Attribute Protocolの確認

1回目・2回目共にキーボード出力が開始された。

 

【図10:iPhone(iOS)におけるAttribute Protocolのやり取り(1/2)】

iPhoneiOSにおけるAttribute-Protocolのやり取り(1_2)

 

【図11:iPhone(iOS)におけるAttribute Protocolのやり取り(2/2)】

iPhoneiOSにおけるAttribute-Protocolのやり取り

⑤-1-6:iPhone(iOS)の解析結果まとめ

1回目/2回目共に、各項目とも特に大きな問題はみられず、キーボード出力も開始されていました。

 

【図12:iPhone(iOS)の解析結果まとめ】

iPhoneiOSの解析結果まとめ

⑤-2:Androidとの接続

iPhone同様、Androidでも「最初の1回以降、2回目から通信ができなくなる」という観点で、Androidと新規接続(1回目)/再接続(2回目)のデータを取得し、比較解析を行いました。

⑤-2-1:Advertising/Scanningの確認

1回目/2回目共に、アドバタイズパケットの送信およびスキャンリクエストへの応答が問題なく行われていました。

 

【図13:AndroidにおけるAdvertising/Scanningのやり取り】

AndroidにおけるAdvertising・Scanningのやり取り

⑤-2-2:Initiatingの確認

1回目/2回目共に、CONNECT_INDパケットの内容に大きな変化は見られませんでした(Connection Interval:45.00ms)。

 

【図14:AndroidにおけるInitiatingのやり取り】

AndroidにおけるInitiatingのやり取り

⑤-2-3:Connectionの確認

iPhoneとはConnection Intervalが異なりますが、1回目/2回目共にデータチャネルでの通信も正常に行われていました (Connection Interval:45.00ms)。

 

【図15:AndroidにおけるConnectionの遷移】

AndroidにおけるConnectionの遷移

 

⑤-2-4:Pairingの確認

ボンディング(暗号化キーを保存)が行われるため、1回目でSMP(Security Manager Protocol)でペアリングプロセスが実行され、2回目はSMPの処理が行われていないが、特に問題なく暗号化も行われていました。

 

【図16:AndroidにおけるPairingの遷移】

AndroidにおけるPairingの遷移

⑤-2-5:Attribute Protocolの確認

1回目は問題なくキーボード出力が開始されましたが、2回目はキーボード出力が開始されませんでした。

 

【図17:AndroidにおけるAttribute Protocolのやり取り(1/3)】

AndroidにおけるAttribute-Protocolのやり取り(1_3)

 

【図18:AndroidにおけるAttribute Protocolのやり取り(2/3)】

AndroidにおけるAttribute-Protocolのやり取り(2_3)

 

【図19:AndroidにおけるAttribute Protocolのやり取り(3/3)】

AndroidにおけるAttribute-Protocolのやり取り(3_3)

 

⑤-2-6:Androidの解析結果まとめ

1回目/2回目ともPairingの確認までは各項目とも特に大きな問題はみられませんでしたが、2回目はキーボード出力も開始されませんでした。今回、Attribute Protocolのやり取りにて不具合が発生していることが分かったため、詳細を見ていきます。そもそもキーボード出力はAttribute ProtocolのNotificationで送信されます。

 

【図20:Androidの解析結果まとめ】

Androidの解析結果まとめ

 

iPhoneの2回目の場合、NotificationはClient Characteristic Configurationで設定されていました。

 

【図21:Attribute Protocolの仕様】

Attribute-Protocolの仕様

 

【図22:iPhone再接続時のNotification解析結果】

iPhone再接続時のNotification解析結果

 

一方でAndroidの2回目の場合は、Client Characteristic ConfigurationはBattery Levelのみしか設定されていませんでした(HID Reportが設定されていません)。

 

【図23:Android再接続時のNotification解析結果】

Android再接続時のNotification解析結果

⑤-3:パソコン(Windows)との接続

スマートフォン同様、パソコン(Windows)でも「最初の1回以降、2回目から通信ができなくなる」という観点で、Androidと新規接続(1回目)/再接続(2回目)のデータを取得し、比較解析を行いました。

 

⑤-3-1:Advertising/Scanningの確認

1回目/2回目共に、アドバタイズパケットの送信およびスキャンリクエストへの応答が問題なく行われていました。

 

【図24:WindowsにおけるAdvertising/Scanningのやり取り】

WindowsにおけるAdvertising_Scanningのやり取り

⑤-3-2:Initiatingの確認

1回目/2回目で、CONNECT_INDパケットのConnection Intervalに変化がありました(1回目:60.00ms, 2回目:37.50ms)。

 

【図25:WindowsにおけるInitiatingのやり取り】

WindowsにおけるInitiatingのやり取り

⑤-3-3:Connectionの確認

Connection Intervalに変化がありましたが、1回目/2回目共に、データチャネルでの通信も正常に行われていました。

 

【図26:WindowsにおけるConnectionの遷移】

WindowsにおけるConnectionの遷移

⑤-3-4:Pairingの確認

ボンディング(暗号化キーを保存)が行われるため、1回目でSMP(Security Manager Protocol)でペアリングプロセスが実行され、2回目はSMPの処理が行われていないが、特に問題なく暗号化も行われています。

 

【図27:WindowsにおけるPairingの遷移】

WindowsにおけるPairingの遷移

⑤-3-5:Attribute Protocolの確認

1回目は問題なくキーボード出力が開始されましたが、2回目はキーボード出力が開始されませんでした。

 

【図28:WindowsにおけるAttribute Protocolのやり取り(1/3)】

AndroidにおけるAttribute-Protocolのやり取り(1_3)

 

【図29:WindowsにおけるAttribute Protocolのやり取り(2/3)】

AndroidにおけるAttribute-Protocolのやり取り(2_3)

 

【図30:WindowsにおけるAttribute Protocolのやり取り(3/3)】

AndroidにおけるAttribute-Protocolのやり取り(3_3)

⑤-3-6:Windowsの解析結果まとめ

1回目/2回目ともPairingの確認までは各項目とも特に大きな問題はみられませんでしたが、2回目はキーボード出力も開始されませんでした。

 

【図31:Windowsの解析結果まとめ】

Windowsの解析結果まとめ

 

またWindowsでは、2回目の接続時にClient Characteristic Configuration自体が設定されていませんでした。

 

【図32:attribute Protocol】

atributeProtocol

 

⑥問題分析と改善点の把握

今回の測定・解析ではBluetooth通信のAdvertising/Scanning・Initiating・Connection・Pairing・Attribute Protocolのそれぞれの処理の解析を行い、以下の結果が得られました。

  • Pairingまでの処理では特に大きな問題は見られなかった。
  • Attribute Protocolでは、キーボード出力はAttribute ProtocolのNotificationで送信されるが、そのNotificationはClient Characteristic Configurationで設定される。
  •  iPhoneの場合、1回目/2回目とも、 Client Characteristic ConfigurationでHID ReportのNotificationが送信されるように設定されていた。
  • AndroidやWindowsの場合、2回目で Client Characteristic ConfigurationでHID ReportのNotificationが送信されるように設定されていなかった。
  • Client Characteristic Configurationについて仕様では「切断や再接続においても保持されるもの」という記載がある。

 

【図33:Bluetooth Core Specificationの記述内容】 BluetoothCoreSpecofication

考えられる改善点:

今回の不具合はClient Characteristic Configurationの設定に問題があり、対向機の挙動に依存しない動作を目指す場合は、Client Characteristic Configurationについてペリフェラル側(今回はLINBLE)で保持する必要があると考えられます。

 

最後に

弊社では、今回のようにBluetooth通信上の課題を明らかにし、解決へ導くお手伝いをしております。お客様の課題に対し高い満足度を得られるよう一から丁寧にヒアリングを行い、ご納得いただいた上で測定・解析を行っていきます。ムセンコネクト様にも弊社が指摘した原因、またその原因特定に至るまでのアプローチの説明も満足できたと好評でした。ぜひBluetooth通信に関してお困りごとがございましたらまずは弊社までお気軽にご相談ください。

 

ムセンコネクト様に今回の体験を踏まえて「無線化講座」にて弊社Bluetooth測定・解析サービスを掲載していただきました。こちらも併せてご覧ください!

無線通信の測定・解析サービスってどんなもの?利用方法や気になる費用は?

 

弊社のBluetooth解析・測定サービスの詳細については以下よりご参照ください。

Bluetooth 解析・測定サービス_コーンズテクノロジー