アップルによるBluetoothアクセサリの設計ガイドラインに書かれていたこと
『Bluetooth Accessory Design Guideline for Apple Products』という、Appleによる公式ドキュメントがあります。Mac や iOS デバイス、iPod 等の Apple 製品の Bluetooth アクセサリの設計についてのガイドラインです。
本記事では、このドキュメントから iOS エンジニアも知っておいた方が良さそうな部分 を抜粋していきたいと思います。
※本記事は、Bluetooth Low Energy Advent Calendar 2014 - Qiita
アドバタイズ間隔
「アドバタイズ開始から少なくとも30秒間は、推奨アドバタイズ間隔である 20 ms を使用すべき」と明記されています。
To be discovered by the Apple product, the accessory should first use the recommended advertising interval
of 20 ms for at least 30 seconds.
で、この最初の30秒間で発見されなければ、バッテリー節約のため下記のより長いアドバタイズ間隔のいずれかを使用することを推奨する、と。
If it is not discovered within the initial 30 seconds, Apple recommends using
one of the following longer intervals to increase chances of discovery by the Apple product:
- 152.5 ms
- 211.25 ms
- 318.75 ms
- 417.5 ms
- 546.25 ms
- 760 ms
- 852.5 ms
- 1022.5 ms
- 1285 ms
ちなみに BLE の規格で定められているアドバタイズ間隔は、最小 20[ms] 〜 最大 10.24[s]の範囲で 0.625[ms]の整数倍 なので、Appleによる「最初の30秒間の推奨アドバタイズ間隔」はBLE規格上の最小間隔でもあります。
iOSエンジニアとしては、このあたりのアドバタイズ仕様を把握しておくと、セントラルとしてふるまうアプリにおいてスキャンをどう行うかの設計や、iBeacon の利用する際に役立つかもしれません。
Connection Parameters
以下の全てのルールに従っていないと、接続パラメータ要求は（iOSから）拒絶される可能性がある、と書かれています。
- Interval Max * (Slave Latency + 1) ≤ 2 seconds
- Interval Min ≥ 20 ms
- Interval Min + 20 ms ≤ Interval Max Slave Latency ≤ 4
- connSupervisionTimeout ≤ 6 seconds
- Interval Max * (Slave Latency + 1) * 3 < connSupervisionTimeout
If Bluetooth Low Energy HID is one of the connected services of an accessory, connection interval down to
11.25 ms may be accepted by the Apple product.
The Apple product will not read or use the parameters in the Peripheral Preferred Connection Parameters
characteristic
iOSエンジニアとしては、Connection Interval が「20 ms 以上」と明記されている部分は情報として非常に有用なのではないでしょうか。
こういう計算が考え方として正しいものなのか、ちょっと自信がない（他に考慮すべきことがあるかも）のですが、Connection Intervalが20msということは、1秒間に50回データの送受信が可能、ということなので、1パケット20byteとして、
20 * 50 = 1000 bytes / sec = 1k byte / sec = 8k bits / sec
というわけで、iOSとBLE接続するデバイスとの最大通信速度は約8kbps、ということがいえるのではないでしょうか。
他にも、connSlaveLatency（スレイブが送信するデータがなにもないときに、コネクション・イベントを無視出来る回数）や connSupervisionTimeout （接続が失われたと判断する、コネクション・イベントの失敗回数）の条件式も明示されているので、どういう条件で接続が失われるのか、を具体的に把握する指針となり、参考になります。
参考：http://reinforce-lab.github.io/blog/2013/08/13/blebook-ch2-ble-spec/
Service Changed Characteristic
そのアクセサリがサービスを変更する可能性のある場合（つまり、GATT を変更する可能性がある場合）は "Service Changed Characteristic" を実装しましょう、と書かれています。
The accessory shall implement the Service Changed characteristic only if the accessory has the ability to change
its services during its lifetime.
アップル製品は、前回読んだ（キャッシュした）情報に依るかどうかを "Service Changed Characteristic" を使って決めますよ、と。
The Apple product may use the Service Changed characteristic to determine if it can rely on previously read
(cached) information from the device.
これの話ですね。
Core Bluetooth でいうと、サービス変更時に CBPeripheralDelegate の `peripheral:didModifyServices:` が呼ばれる、という件ですが、そもそもアクセサリ側で "Service Changed Characteristic" が実装されている必要があります。（実装されてなければ iOS の Bluetooth 設定を off/on してキャッシュクリアする）
Siri
「カスタム Siri コマンドを有効にする」「Siri のアベイラビリティ情報を取得する」「Siri セッションの初期化」「Siri Eyes Free Mode」「Siriセッションを最適化する」などなど興味を惹かれるタイトルが並んでいますが、HFP プロファイルとかのクラシック Bluetooth の話で Core Bluetooth でどうこうできる範囲ではないのでスルー。
「6.5 Improving Voice Recognition」も iOS エンジニアがどうこうできる部分ではないが、S/N比の推奨は 20 dB 以上 とか書いてあって、Siri とか関係なく、良好な音声入力の基準値として今後 iOS で音声処理やる際の改善のヒントになりそうです。
関連
上原さんのブログにBLE部分を日本語訳したものがまとめられています。
