【BLEを使う】mbed HRM1017サンプルプログラムのプロトコル解析 その1
たくさんの鼻で立ってゆっくりと
ナゾベームは歩く
自分の子供たちをひき連れて
まだブレームの動物誌には載っていない
まだマイヤー大百科辞典には載っていない
そしてブロックハウス大百科辞典にも
「鼻行類」より引用
いままでの記事はこちらをご覧ください。
① Packet Snifferを使う
Packet SnifferはBLE通信のプロトコル解析をするためのアプリケーションです。Texas Instruments社のBLEチップCC2540搭載のUSBドングルを使います。
（後日解析ツールの使い方について記事を書く予定です。）
http://processors.wiki.ti.com/index.php/BLE_sniffer_guide
今回はこのPacket Snifferを使ってmbed-HRM1017をはじめようで紹介されている温度計データ取得のBLEプロトコルを解析してみたいと思います。
② Advertisingパケット
mbed HRM1017で【BLEを使う】mbed HRM1017 動作環境を整える - 叶鋼は午前1時に計算をするにおいて紹介したサンプルプログラムを動かすと、Packet SnifferはHRM1017が送信しているパケットを以下のように取得します。
mbed HRM1017が送信しているこのパケットは、adevertisingパケットと呼ばれるものです。
上の図において、mbed HRM1017はadevertisingパケットをひたすら周囲に飛ばして自分の存在をアピールしているわけです。
まずはこのadevertisingパケットの中身を解析してみます。
Adevertisingパケットの詳細については【BLEを使う】GAP（Generic Access Profile）概要 - 叶鋼は午前1時に計算をするをご覧ください。
・Time(us) & Channnel
周期的にmbed HRM1017がadvertisingパケットを送信しているのが分かります。
Packet Snifferの設定でChannel 0x25=37chの信号だけを拾っていますが、実際には37ch→38ch→39chの順番でadvertisingパケットが送信されています。
・Access Address
advertisingパケットを意味するアドレスは固定値で0x8E89BED6です。
・Adv PDU Header
Adv PDU Headerは2bytesの信号で以下の構造を持ちます。
Type 0となっているのはADV_INVの値0000を示しています。
ADV_INVは典型的なadvertisingで、mbed HRM1017は周囲にある不特定多数のCentralに自分の存在を宣伝して、それがどこかのCentralに検知されると、両者間でスキャンパケットの送受信を行った上で、mbed HRM1017はCentralからの接続要求に備えます。
TxAddが1なのでAdvA(advertiser’s address)はランダムになります。
PDU Lengthは続くpayload(AdvA + AdvData)の長さが19bytesであることを示しています。
RFUとあるのは予約bitで、常に0の値になります。
・AdvA(advertiser’s address)
AdvAはCentralがPeripheral BLEを特定するためのアドレスです。CentralとPeripheralの接続が一時的に遮断した場合には、このアドレスが一致するPeripheral BLEを探して再接続します。
ここではTxAddが1なので、AdvAは一定時間ごとに変更されるランダムな値を取ります。
・AdvData(advertiser’s data)
AdvDataは以下のような意味を持っています。
0x02：AD structure1の長さが2bytes
（以下2bytes）
0x01：AD structure1のtypeはFlags
0x04：FlagsはBR/EDR Not Supported。BLEのみをサポートしています。
0x05：AD structure1の長さが5bytes
（以下5bytes）
0x03：AD structure1のtypeは16bit-Service UUID。BLEが使用している機能を示します。
また2bytesに短縮されたUUIDを使用することも示しています。
0x09 0x18 0x0F 0x18：UUID data。2つの機能が確認できます。
0x1809：BLE_UUID_HEALTH_THERMOMETER_SERVICE
0x180F：BLE_UUID_BATTERY_SERVICE
この2bytseを正式な16bytesのUUIDに直すときは
0000xxxx-0000-1000-00805F9B34FB
のxxxxの部分に上記の2bytes UUIDを代入します。
0x03：AD structure3の長さが3bytes
（以下3bytes）
0x19：AD structure3のtypeはAppearance。BLEに接続されている外部装置を示します。
0x00 0x03：外部装置は0x300=768なのでGeneric Thermometer（温度計）となっています。
Appearanceのdataについては以下を参照ください。
ちなみにAdvData の上限は31bytesですが、上の例では19bytesしか使用していないので、使われなかった12bytesは0で埋められています。
③ スキャンパケット
ipadなどでNordicのnRF Toolboxを立ち上げると、ipadaがadvertisingパケットを検知して、スキャン要求とスキャン応答が行われます。
上の図におけるAdv PDU typeが3のADV_SCAN_REQ、スキャン要求と4のADV_SCAN_RSP、スキャン応答がそれです。
スキャン要求のpayloadはScanA(6bytes)とAdvA(6bytes)で構成されています。 ScanAはスキャンしているcentral側のアドレスで、RxAdd=1なのでランダムアドレスです。
AdvAはadvertisingパケットを送信しているperipheral側のアドレスで、先ほど確認したAdvAと同じアドレスです。
スキャン応答のpayloadはAdvA(6bytes)とスキャン応答データ(0～31bytes)で構成されています。
Advertisingパケットは31bytesしかないので、必要な情報が入りきらないことがあります。そのような場合にはスキャン応答のデータを使います。
今回はAdvertisingパケットの31bytes中19bytesで間に合ったので、スキャン応答のData部分、ScanRepDataは使う必要がなく、NONE（何も無し）になっています。
さて次回は、接続を確立するとどのようなパケットが取得できるかについて解説したいと思います。
