わふうの人が書いてます。

iOSアプリケーション開発、BLEのファームウェアとハードウェア試作のフリーランスエンジニア。

Bluetooth Low Energy リンクレイヤの解説

ここまでで、クラシックBTと比較したBLEの違いと特徴、そしてBLEの物理層を述べました。
ここでは、規格書をなぞる解説ではなく、iOSのアプリ開発とiOSと連携するBLEデバイス開発に役立てるための知識を提供する視点で、BLEのリンクレイヤを解説します。

リンクレイヤは、あるデバイスとあるデバイス間で、どうやって無線通信をするかを決めます。
リンクレイヤが定義するのは、パケット、アドバタイジングそしてデータチャネルです。
これらを使って、リンクレイヤは:

  • 他のデバイスの発見、
  • データのブロードキャスト、
  • 接続の確立と維持、
  • 接続を通したデータ通信、

を提供します。

BLEのトポロジー

BLEのネットワークは、1つのマスターに複数のスレーブが接続する、スター型のネットワークです。
1つのリンクレイヤが、同時にマスターかつスレーブになることはできません。

BLEのネットワークは、クラシックBluetoothのピコネットとは、違います。
クラシックBluetoothのピコネットは、
同期したクロック同じ周波数ホッピングの順番で、
同じ物理チャネルで通信するデバイス群です。1つのピコネットの複数あるスレーブは、1つだけあるマスターにクロックを同期して通信をします。
あるデバイスは複数のピコネットに同時に参加出来ます。
(Blluetooth specification Version 4.0 [Vol 1] 4.1.2 LE Topology)

LEのトポロジーを示します。デバイスAは、
デバイスBおよびCと接続しています。このときデバイスAは、master role(以下、マスター)、デバイスBとCがslave role(以下、スレーブ)を果たしています。
デバイスBとCは、全く何も同期しておらず、ただデバイスAとそれぞれが接続して通信をします。

BLEには、接続していなくても、アドバタイジングを使って情報をやり取りする仕組みがあります。
アドバタイジング・チャネルにアドバタイジング・パケットを創出するものをadvertiser、
アドバタイジング・チャネルをモニタして、アドバタイジング・パケットを受信するものをscannerといいます。
上図のデバイスDおよびEのように、すでに接続しているデバイスAおよびCは、マスター/スレーブどちらになっているかにかかわらず、
advertiserにもscannerにもなれます。またデバイスH, I, Jのように、アドバタイズメント・パケットだけで構築するネットワークもあります。

接続時、マスターが、スレーブとの接続と通信タイミングを制御します。
より多くのメモリと電池を必要とする機能をマスターに寄せて、スレーブに求めるメモリと電池の要求量を小さくする、非対称に役割をふることで、
スレーブの消費電力と製造コストがより小さくなります。

BLEのトポロジーでは、リンクレイヤが同時にマスターかつスレーブにはなれません。
クラシックBluetoothでは、同時にマスターかつスレーブとなりピコネット間をつなぐものをscatterと呼びます。BLEにscatterをサポートしません。

しかし、マスターからスレーブに役割を切り替えることができます。
Bluetooth Low Energyの半導体で、内蔵マイコンがリンクレイヤを制御しているものは、ファームウェアでスレーブかつマスターどちれにもなれるものがあります。

リンクレイヤのステート・マシーン

BLEのトポロジーを、振る舞いだけでみていると複雑なので、その振る舞いのもとになっているリンクレイヤのステート・マシーンという基本概念を説明します。
ステート・マシーンは、状態とその遷移でふるまいを表すモデルです。

リンクレイヤは5つの状態があります。

  • Standby
    • 初期状態です。電波の送受信をしません。
  • Advertising
    • アドバタイズメント・チャネルでの、アドバタイズメント・パケットの送受信をします。
  • Scanning
    • スキャニングは、アドバタイジング・チャネルの電波を受信します。
    • スキャンには、パッシブスキャンとアクティブスキャンの2つがあります。
    • パッシブスキャンは、アドバタイジング・パケットを受信するだけです。
    • アクティブスキャンは、デバイスにSCAN_REQを送信して、アドバタイジング・パケットに収まりきらなかった情報をさらに取得します。
  • Initiating
    • 特定のデバイスからのアドバタイズメント・パケットの受信と、そのパケットへの応答をします。
  • Connection
    • 接続した状態です。

コネクション状態では、

  • Master role
  • Slave role

の2つの役割があります。Initiating stateからConnecting stateに遷移したものがMaster role、
Advertising stateからConnection stateに遷移したものがSlave roleです。

接続するまでのステート間の遷移は、
マスターは standby -> Initiating -> Connection、
スレーブは Standby -> Advertising -> Connection、
となります。

ここまでの説明だけなら、1つのリンクレイヤをステートマシーンで制御するだけだと理解しやすいのですが、BLEは複数のステートマシーンが持てます。
それぞれのステートマシーンがそれぞれ動作することで、例えば、あるステートマシーンがConnectionしているときに、別のステートマシンでAdvertisingをすることができます。

ですが、いくつかのステートマシーンの状態の組み合わせは禁止されています。
これは、同時にマスターかつスレーブにならないための、ルールです。接続状態にならなければよいので、すでにスレーブとして接続状態にあっても、接続状態にならないアドバタイズメント・パケットは送信できます。

その組み合わせずとその説明は以下のものです:

  • Connectionステートにあるとき、同時にMaster roleとSlave roleにすべきではない。
  • Slave roleでConnectionステートにあるリンクレイヤは、1つのコネクションだけをもつべきである。
  • Master roleでConnectionステートにあるリンクレイヤは、複数のコネクションを持ってもよい。
  • すでにリンクレイヤがSlave roleでConnectionステートにあるなら、リンクレイヤはInitiatingステートで動作すべきではない。
  • リンクレイヤがConnectionステートもしくはInitiatingステートで動作しているなら、リンクレイヤはSlave roleで接続状態に入ることになるアドバタイズメントをするAdvertisingステートで動作すべきではない。

パケット

リンクレイヤのパケットフォーマットを示します:

最も短いパケットで80ビット(送信時間 80マイクロ秒)、最も長いもので376ビット(送信時間 367マイクロ秒)です。

ビットオーダー

BLEのリンクレイヤのパケットおよびパケットのフィールドProtocol Data Unit(PDU)のフィールドは、リトルエンディアンです。

  • 表記b0は、最下位ビット(Least Significant Bit,LSB)を表します。
  • 最下位ビットから送信されます。

0x3(011b)を送信するときは、110bと送信されます(1が最初、0が最後)。

また8ビットを1オクテットとします。CRCとMICを除き、それぞれのフィールドは最下位オクテットから送信されます。
0x1234(2進数0001_0010_0011_0100)を送信するときは、0010_1100_0100_1000b、と送信されます。

プリアンブル

プリアンブルは、0x55(01010101b)もしくは0xAA(10101010b)の0/1が繰り返すパターンで、信号のゲイン調整やデータを復調するための同期に使われます。
0x55と0xAAのどちらを使うかは、続くデバイス・アドレスと並べた時に’1’や’0’が連続しないほうを、選びます。

デバイス・アドレス

32ビットのパケットアドレス:

  • アドバタイジング・アクセス・アドレス
  • データ・アクセス・アドレス

アクセスアドレスは、個々のデバイスが通信時に使うランダムなアドレス値です。アドバタイズメント・パケットでは、固定値0x8E89BED6が使われます。

10001110100010011011111011010110b (0x8E89BED6)

アドバタイズメント。先頭アドレス固定。4んービットの一致検出。
3チャネル。20ミリ秒から1.んー秒。時間は長く。重なると悲惨、0~10ミリ秒ランダムにずらす。

アドバタイジング・チャネル PDUヘッダー

PDUタイプは、アドバタイズメント・チャネルPDUのタイプを指定します。
TxAddとRxAddは、PDUタイプごとに定義されるフィールドです。PDUタイプがこれを定義していないときは、将来使うための予約済フィールドとします。
Lengthはペイロードの長さをオクテットで表し、6から37までの値を取ります。

接続に係るPDUタプは次の4つです:

  • ADV_IND
    • 接続可能、ダイレクトではない
  • ADV_NONCONN_IND
    • 接続しない、ダイレクトではない
  • ADV_SCAN_IND
    • スキャン可能、直接ではない
  • ADV_DIRECT_IND
    • 接続可能、直接

このうち、ADV_DIRECT_IND は、AppleのBluetoothアクセサリ設計指針で使うべきではないと、書かれています。

アドバタイジング・データがパケットのペイロードに収まらないとき(31バイトより大きい時)、マスターはスレーブにスキャンを要求して、さらに情報を取得出来ます。そのためのPDUタイプがSCAN_REQ(スキャン・リクエスト)とSCAN_REP(スキャン・リクエストへのリプライ)です。また接続要求がCONNECT_REQです。

  • SCAN_REQ
  • SCAN_RSP
  • CONNECT_REQ

アドバタイジング・データ

ADV_IND、ADV_SCAN_IND、ADV_NONCONN_INDのペイロードの構成は:

AdvAはアドバタイザーのアドレスを、AdvDataはアドバタイジング・データを表します。
TxAddの値は、アドレス値AdvAが、パブリック(TxAdd = 0)か、ランダム(TxAdd = 1)かを示します。

([Vol 6] 2.3.1)

アドバタイジング・データとスキャン・データのフォーマット

アドバタイジングとスキャン・データは、31オクテットを、いくつかのLength、Dataフィールドと、31バイトになるように0で埋めたものです。
このDataフィールドはAD TypeとAD dataで構成されます。AD Typeの実際の値は、https://www.bluetooth.org/Technical/AssignedNumbers/generic_access_profile.htm にあります。

31バイトのアドバタイジング・データでではアドバタイジングしたい情報が収まらない場合があります。その時に使うのがスキャンです。
アドバタイザは、受信したSCAN_REQに対して付加情報をSCAN_REPで返信します。このスキャンデータは、スタティック、であるべきです。
アドバタイジング・パケットは常に受信するものなので、そのデータが変化しても、マスターはそれをいちいち解釈するでしょう。しかしスキャンデータは、マスターが常に読み取ろうとするとは限りません。変化する情報を入れていた場合に、振る舞いが予測できなくなります。

iPhoneアクセサリでは、Bluetoothアクセサリに送信されたアドバタイジング・データは、 Bluetooth 4.0 仕様, Volume 3, Part C, Section 11 に記述されているように、 次の情報の少なくとも1つを含むべきです:

  • Flags
  • TX Power Level
  • Local Name
  • Services

アドバタイジング・データには次のタイプがあります:

  • Local Name
    • デバイス名です。完全もしくは短縮名です(section 3.2.2)。完全/短縮は、AD Typeで判別出来ます。
    • もしも短縮名ならば、device name characteristicを読み出せば、完全なデバイス名が取れます。
  • Flags
    • フラグビットをbooleanで含みます。LE physical channelで使われるフラグは:
    • Limited Discoverable mode
    • General Discoverable mode
    • VR/EDR Not Supported
    • Simultaneous LE and BR/EDR to Same Device Capable (Controller)
    • Simultaneous LE and BR/EDR to Same Device Capable (Host)
  • TX Power Level
    • 送信電力です。
  • Service UUIDs
    • サービスのUUID(16-bit, 128-bit)です。
  • Manufacturer Specific Data
  • Security Manager Out of Band
  • Security Manager TK Value
  • Slave Connection Interval Range
  • Service Solicitation
  • Service Data

LLコネクションパラメータ

ウィンドウサイズ、スレーブレイテンシ、スキャンインターバル、タイムアウト、をマスターからスレーブに設定する。
スキャンインターバルが決められているが、スレーブは、意図的に、データを送信しないでいい。タイムアウトするまでに、返答すれば接続は保たれる。

これは低レイテンシと低消費電力を両立するための工夫。例えばキーボードを考えれば、通信の遅延時間を20ミリ秒にしたいとする。
しかしキーボードが押されるイベントは、20ミリ秒よりもはるかに低い頻度でしか起こらない。
もしもスレーブが、20ミリ秒ごとに”データはない”という送信をすれば、その電波を出すために電力を消費する。

そこでインターバルがきても、データがないならば電波を出さないことで、低消費電力が得られる。
しかし20ミリ秒ごとにインターバルがあるので、送信すべきデータが来たならば直ちに次のインターバルでデータを送信できる。

データPDU

データPDUのフォーマット。暗号化するときはMICがはいる。
暗号化だけではなくて、CRCよりも強力なエラー検出が必要なときにも使える。

データの長さは、0~27。MICがあってもなくても、データ長はMICがある場合の最大値の27にしてある。
iOSでwrite~でデータを書き込むときに、最大27バイトで頭打ちになるのは、おそらくLL2CAPを通さずこのレイアを直接叩いているからかも。

BLEデバイスのバッテリー

BLEはもともと超低消費電力かつ低コストを目標に作られた規格です。BLEの、電池への配慮を見てみます。

BLEデバイスの開発話をしていると、ときには極端に小さくしたいなど、
デバイスの大きさや形状の要望も出てくるでしょう。この時に、
回路面積は半導体素子を並べて実装可能な配置での基板面積から見積もれるでしょう。そして電池の選定です。それには、回路と電池の両方の知識が必要です。

電池の選定で肝心なのは、
連続稼働時間に必要な電池容量と、ピーク電流がとれるか、の2つです。

電池の大きさは、容量と面積の2つがあります。容量が小さくなれば、当然、
電源容量が小さくなりBLEデバイスの連続稼働時間が小さくなります。そして面積が小さくなりすぎると、BLEデバイスが無線通信をするために必要な、ピーク電流、が取れなくなり回路の正常動作に影響を与えます。

連続稼働時間の目安は、1mAhで1日から2日、と覚えておきます。

BLEによく使われるのが、CR2032という電池です。
この電池の特性を見てみます。

カタログが、
http://industrial.panasonic.com/www-cgi/jvcr13pz.cgi?J+BA+4+AAA4003+CR2032+8+JP
にあります。

型番の先頭2文字は、電池の種類と形状を表します。Cは、二酸化マンガンリチウム電池(3.0 V)、形状は円形です。電池の電圧は電極材料で一意に決まります。現在の半導体製造プロセスで作られる回路の動作電圧は、1.8 ~3.3Vです。この二酸化マンガンリチウム電池の3.0Vという電圧は、その範囲にちょうどあてはまり、使い勝手がよいのです。

CR2032の容量は220mAhです。負極にリチウムを使い、容積の割に電源容量が大きいので、BLEデバイスの連続動作時間をより長くするのに、適しています。この電源容量は、大きな電流を短時間流すことを繰り返したり、動作温度が高い/低いなど、使い方と利用環境で大きく変化するので、注意します。

CR2032は、電卓やPCのバックアップ電源に使われていて、スーパーやコンビニで買える、入手性が高い電池です。入手性の高さは、BLEデバイスの使い勝手のよさにつながります。

BLEの“超低消費電力”は、電波の送受信を短時間で終わらせて、後の時間はスリープ状態で電力を使わない、間欠動作で実現しています。平均すれば“超低消費電力”、なのです。

CR2032は、標準負荷が0.2mAですが、ピーク電流は20mAほど取れます。
電波の送受信では、半導体メーカによりますがだいたい~15mAの電流が短い時間(数ミリ秒程度)流れます。標準負荷は小さいですが、ピーク電流がとれるので、BLE回路に適します。

ちなみに、CR2032は、連続して電流を流そうとしても、内部抵抗が高くなり、最大電流が電池側で制限されます。フィジカル・コンピューティングでLEDの足でボタン電池をはさんで光らせるバッジをみかけますが、電流制限抵抗がなくてもLEDが連続点灯するのは、この電池の電流制限の特性のおかげです。

電池で電気回路を年単位で連続動作させるには、電気回路自体が“超低消費電力”であることと、電池の自己放電特性が優れている、2つが必要です。自己放電は、電池メーカごとの性能、そして温度に大きく影響されます。二酸化マンガンリチウム電池の自己放電率は、目安として、1%/年以下です。

BLEの物理層

Bluetooth Low Energy(以下、BLE)の物理層の話をします。物理層とは、無線通信であればどんな電波を出して、相互に情報をやり取りするのかを決める層です。

BLEのハードウェアを使うiOSアプリケーションを開発するから、物理的なことは知らなくてもいいのではと思われるかもしれません。
しかしBLEは無線通信を使うために、例えば:

  • WiFiが周囲にあっても通信ができるのか
  • iOSデバイスと同時に何台までBLEデバイスは接続できるのか
  • 展示会場でデモンストレーションをするときに周囲に多数のBLEデバイスがある場合でも、接続するのか

という、この状況でも動くのかという、振る舞いの質問を利用者からされます。その質問に答えるには、物理層の基本知識は必要です。

自分が開発する部分がアプリケーションだけであっても、
ハードウェアと連携するアプリケーションは、
利用者からみれば、
そのハードウェアとアプリケーション、2つをあわせて1つの製品になります。

確実に動かすための知識として、物理層を理解してください。

まとめ

電波の混信/干渉

BLEは2.4GHzのISM帯を使います。
この無線帯域はWiFiや電子レンジなど多くの機器が利用しています。
BLEは、周波数帯域を40個のチャンネルに分割して、干渉や混信するチャンネルを避ける適応周波数ホッピングという仕組みを使います。

同時何台まで接続できるか

規格では、制約はありません。実装依存です。
60台くらいは大丈夫っぽい?

接続距離は

規格は送信電力の最小と最大を規定しています。
それぞれの場合の通信距離は、見通しで、最大のとき50m程度、最小のとき2.5m程度、です。

仕様はどこにある

BLEの規格は、Bluetooth SIGから公開されています。
https://www.bluetooth.org/Technical/Specifications/adopted.htm
のCore Version 4.0 Vol.6 がBLEの物理層からの規格を述べています。

2.4GHzISM帯を使います

BLEは2400MHzから2483.5MHzまでを使います。クラシックBTと同じ周波数範囲を使います。
BLEは、この周波数帯を2MHz幅 40個のチャンネルに分割して利用します。チャンネルごとの中間周波数fcは:

fc = 2402 + 2*k MHz, K=0,1 … 39

となります。例えばfcが2402MHzのチャンネルは、2401MHzから2403MHzまでの周波数を使います。

チャンネルは、周波数帯域を有効に使うための工夫です。例えば、
たくさんのBLEデバイスがあっても、それぞれが違うチャンネルを通信に使えば混信しません。

BLEは、40のチャンネルのうち、3つをアドバタイズメント・チャンネルに、のこる37つをデータ・チャンネルに割り当てます。

アドバタイズメント・チャンネルは、BLEデバイスの発見と接続に使うチャンネルです。
BLEデバイスは、デバイスを発見するためのアドバタイズメント・パケットを、3つのアドバタイズメント・チャネルそれぞれで送信しています。
iOSデバイス(セントラル)は、デバイスを発見するとき(スキャンするとき)、この3つのアドバタイズメントを受信して、デバイスを発見します。
BLEデバイスを発見すれば、データ通信に必要な接続処理をおこない、データ通信は、37つのデータ・チャネルを次々に切り替えながら、通信を続けます。

データ・チャンネルは、文字通り、データ通信につかうチャンネルです。
BLEは、適応周波数ホッピング方式をとっています。これは一定時間ごとにデータ通信につかうチャンネルを、ランダムな計算式で、
切り替えていく方式です。2.4GHz帯は、BLEだけではなくWiFiや電子レンジなど、様々な電波が飛び交っています。上図のように、もしもあるデータ・チャンネルが運悪くWiFiとぶつかり通信ができなくても、次の通信の機会でそのWiFiと重なっていないデータ・チャンネルに切り替われば、データ通信が継続出来ます。

BLEの適応周波数ホッピングの“適応”は、どのデータ・チャネルを使うかを、指定できる機能を指しています。例えば、WiFi チャネル1が使われているとわかっているならば、そこと重なるチャンネルは、そもそも使わないようにできれば、通信ができない状態を避けられます。

デバイスが発見できることは、とても重要です。
アドバタイズメント・チャネルは、上図の、37, 38, および39チャネルです。
2.4GMHzのWiFiの1, 6, 11チャネルと重ならならないチャンネルから、周波数帯域の下端/上端/真ん中の、なるべく周波数が離れたチャンネルを、
アドバタイズメント・チャンネルに割り当てています。

到達距離は見通し50mくらいです

BLEの送信電力は、最小 0.01mW (-20dBm) ~ 最大 10mW (+10dBm)です。一般のBLEの半導体の受信感度(0.1% ビットエラー)は-90dBmです。

伝送ロスは:

pass loss = 40 + 25 log (d)

ここで d は伝送距離(m)です。

これから、通信距離は見通しで最大50m程度です。

アドバンス: 変調方式は低消費電力で低コストの工夫があります

BLEの変調方式は、低消費電力かつ低コストで製造できるよう工夫されています。

クラシックBTは:

  • GFSK
    • BT=0.5
  • 変調指数 0.28 ~ 0.35
  • シンボルタイミング+- 20ppm

BLEは:

  • GFSK
    • BT=0.5
  • 変調指数 0.45 ~ 0.55
  • シンボルタイミング+- 50ppm

です。

変調指数が0.5の周波数変調を、ミニマムシフトキーイング(MSK: Minimum Shift Keying)といいます。BLEは、シンボル・レート1Mbps、1シンボル1ビットです。
ですから、ベースの変調周波数は、500kHzです。これから周波数遷移幅は250kHzになります。

この条件の時、1シンボルの期間で、搬送波に比べて変調波の位相が+-π/2ずれます。周波数変調ですが、連続に位相が遷移するので、I/Q復調器が使えます。

またシンボルタイミングは、クラシックBTの+-20ppmに比べ+-50ppmと緩くなっています。これは1パケットの最大ビット長を短くするなどで、得られています。
これらは、クラシックBTほど安定度が高い回路また精度がよい水晶でなくとも実現できる、低コスト化につながります。

BLE モジュールリスト

モジュールは、通信機能を1つの小さい基板にまとめたもので、
製品の基本回路部分に無線通信機能を追加するときによく使われます。

高周波を送受信する回路は、特性を確保するために回路基板設計に特別の配慮がいること、また電波法や通信規格の認証が必要になります。そこで、それらをモジュールに盛り込み、そのモジュールを製品基板に搭載することで、それらの厄介な部分にかかわらず、製品が設計できるメリットが得られます。

ここでは、どのようにモジュールを選ぶかを、実際のモジュールのリストとともに解説します。次に、モジュールを使わず自社で設計するメリットはどこにあるのかを述べます。

まとめ

  • iPhone 4以前の機種
    • Bluetooth2.0 (クラシックBluetooth)
    • MFi を取得して、クラシックBluetooth SPPで開発。
    • 電池交換、もしくは充電電池内蔵が必要。連続動作時間は1週間程度。
  • iPhone 4S以降の機種(Bluetooth4)
    • MFi取得でSPP、またはBLEで開発。
    • BLEならば、コイン型電池で1年程度の連続動作。
  • Android
    • Bluetooth2,3とBluetooth4を搭載したものが混在。
    • クラシック Bluetooth SPPで開発
  • WindowsPhone8
    • Androidと同様。

ます。携帯端末として、iPhone/iPadのiOS、Android、Windows Phone8を考えます。それぞれの端末は:

  • iPhone/iPad
    • iPhone 4以前の機種: Bluetooth2.0 (クラシックBluetooth) → MFi を取得して、SPPで開発。
    • iPhone 4S以降の機種: Bluetooth4 (クラシックBluetooth + Low Energy) → MFi取得でSPP、またはBLEで開発。
  • Android → SPPで開発。
    • Bluetooth2,3とBluetooth4を搭載したものが混在。
    • Bluetooth Low Energyのプロトコルスタックは、ハードウェア・メーカが独自に提供している状態で、Googleから公式のLow Energyのプロトコルスタックは出ていない。
  • WindowsPhone8 → SPPで開発。機種がBluetooth4ならばBLEが使える。
    • Android同様、クラシックBluetoothとBluetooth4が混在。
      Bluetoothを搭載したAndroid に対応

Bluetoothのモジュールには、デュアルモードとシングルモード、の2種類があります:

  • デュアルモード: 超低消費電力ではないが、Bluetooth機器全てとつながる
    • クラシックBluetoothとLow Energyを両方搭載したもの。両方に接続できる。
    • Bluetooth対応機器全てと繋がるが、電池の交換もしくは充電が必要になる。
  • シングルモード: 超低消費電力。Bluetooth 4対応機器とつながる。
    • Bluetooth Low Energyのみを搭載したもの。クラシックBluetoothとは接続できない。
    • コイン型電池で1年単位の動作。

BLEを選ぶべきか

機器をつなぐ無線通信規格は

  • WiFi
  • クラシックBluetooth
  • Bluetooth Low Energy

などがあります。このほかに、ANT、ZigBeeなどのセンサーネットワーク向けに開発された規格もあります。このうちANTは、iPhone向けにドック接続のトランシーバが提供されていますから、ANT接続を求められることがあるかもしれません。

BLEを使う場面

モジュールの話に入る前に、そもそも論として、BLEを選ぶべきかどうかをみてみます。BLEを選ぶメリットは:

  1. iOSデバイス(iPhone4S以降)と接続できる (MFiプログラムが必須ではない)
  2. コイン型電池で1年以上の連続接続

です。

もしもiPhone4以前の機種と接続することを求められたら、MFiプログラムを取得して認証チップの提供の元、クラシックBluetooth シリアルポートプロファイル(以下、SPP)で、通信部分を実装します。

また、Android/WindowsPhone8との接続も求められた場合も、クラシックBluetooth SPPで接続します。Android/WindowsPhone8は、最新機種のいくつかはBluetooth4を搭載していますが、まだ多くの機種はBluetooth2もしくは3を搭載しています。接続機種を、Bluetooth4を搭載したものに限定できる場合は、BLEのみの提供も可能ですが、機種が限定できずOSの種類で接続先を指定される場合は、クラシックBluetoothを採用する他ありません。

クラシックBluetoothを採用した時点で、“電池で1年の連続動作”は得られません。1週間程度で電池がなくなるので、おそらく充電電池を採用する必要があるでしょう。これは、電源周りの設計や、電池の扱いなどの製造での管理など、様々なコストをかさ上げします。

もしも、クラシックBluetoothも使えるように、かつBLEの利点をすべて満たせと要求されたならば、その案件からは裸足で逃げ出すべきです。

シングル・モードとデュアル・モード

Bluetoothモジュールには、Low Energyのみを搭載したシングル・モードと、クラシックBluetoothとLow Energy両方を搭載したデュアル・モードのものの、2種類があります。それぞれ、用いる半導体自体が別のものです。

接続対象が、iPhone4S以降のiOSデバイスのみでよいなら、シングル・モードでよいでしょう。Android/WindowsPhone8との接続も必要ならば、デュアル・モードを選択します。

もしも、キーホルダーのような、デバイス自体が小さいことが必要な場合は、BLEだけなら、コイン型電池を使い安価に製造ができます。もしもクラシックBluetoothも求められると、充電電池を使わざるを得ず、またユーザに充電の手間をかけさせるので、そもそも論として、製品として売れるのか?という疑問が生じます。

ラジコンのような、モータのように電力消費量が大きなものが場合は、そもそも通信の超低消費電力は必要ありません。それならば、クラシックBluetoothとBLEが両方使えるデュアルモードのBluetoothモジュールを採用しても、電源周りのコストをあげることはありません。

モジュールの価格は、目安としてシングルモードで10ドル程度、デュアルモードで10~15ドル程度です。
デュアルモードは数ドルコストが高くなりがちです。

BLEを選択する場面

まとめると:

  • iOSデバイスと接続する場合
    • MFiプログラムに参加するほど企業が大きくない、弁護士コストが大きい場合
  • 電池が、商品の価格とユーザの使い勝手を大きく決める場面
    • 1次電池で充電不要で安価に、かつ電源スイッチ不要で、電池切れ=製品寿命

です。

1から設計するか、モジュールを利用するか

半導体を購入して1から設計する場合でも、モジュールを利用する場合でも、結果としてできあってくる電気回路は、基板がわかれているか否かの配置が異なるだけで、回路としては同じものになります。

モジュールは設計や許認可のコストが含まれています。目安として製造台数が1万台を超えるあたりから、自社で開発するコストメリットがでてきます。

1から設計した場合は、回路の設計自由度が得られます。モジュールは小さいとはいえ、2cm x 1cm 程度の大きさがあります。極端に小さいものが必要な場合など、任意の配置の回路基板を設計したいならば、1から設計します。

また、電波を発信するものは、他の機器の無線通信を妨害しないように、各国が定める電波法のもとで、技術適合の認証を受けなくてはなりません。その費用は、目安として:

  • 日本 TELEC 80万円
  • 欧米 CE 220万円
  • 米国 FCC 170万円

です。さらに、製品にBluetoothのロゴを使うならば、Bluetooth対応製品として認証および製品登録が必要です。その費用は:

  • Bluetooth SIG 参加 年会費 1万ドル (90万円)
  • 認証テスト 5万円?

です。BLEの認証テストの費用は、クラシックBluetoothに比べれば、とても安価で済みます。ですが、SIGの企業会員の年会費が必要になります。

モジュールを利用した場合は、この電波法の許認可およびBluetoothの製品登録にかかる時間と費用を省略できます。また、モジュールは、半導体メーカが開発する開発環境をより使いやすく、より簡便になるように、モジュール提供会社が工夫をしています。それらを使うと、1から設計する場合よりも、短い時間で設計を終えることができます。

モジュールは少数多品種の製品を製造するときに、特に大きなコストのメリットが得られます。コストだけでみたときの、数量による分岐点を考えてみます。

仮に、1から設計した時の製造費用を5ドル、モジュール単価を10ドルとすれば、価格差は5ドルです。日本国内だけで販売する場合は、認証などの費用が180万円かかります。さらに欧米でも販売するならば、それは540万円になります。これから、目安として、4000個および1万個が、モジュール採用の分岐点になります。

核になるのは半導体

様々なモジュールが各社から出ていますが、
BLEに限らず、BluetoothやWiFiなど、無線通信を実現する核になるのは半導体です。
BLEの半導体を一般に広く販売しているのは、以下の2社です。この2社の半導体の製品ラインナップを見ておけば、どのような無線通信機能を実現できるか、を押さえられます:

2013年1月時点での組み合わせは:

  • シングルモード(BLEのみ)
  • デュアルモード(クラシックBluetooth+LE)
  • ANT+デュアルモードBluetooth
  • WiFi+ANT+デュアルモードBluetooth

です。BLE+ANTという組み合わせは、ありません。

Bluetooth Low EnergyとANTそれぞれの半導体のリストは以下のものになります:

Bluetooth Low Energy:

  • NordicSemiconductor社
    • nRF51822
      • ARM Cortex-M0を内蔵したSoC。
    • nRF8001/8002
      • 8001はradio。8002は8001にFSMを実装しkeyfobに特化したもの。
  • TexusInstruments社
    • CC2564 (デュアルモード)
    • CC2540/41/41S
      • いずれも8051互換のマイコン内蔵したSoc。
      • 41は40からUSBインタフェースを省略したもの。
      • 41Sは、41をradioにしたもの。外部マイコンからの利用に特化。ファーム書き換えはできないが、ペリフェラルの設定を起動時に外部から読み込むため、外部マイコンから設定を変更することはできる、みたい。

ついでにANT:

-NordicSemiconductor社

- nRF51422
- nRF24AP2-1CH/-8CH
  • TexusInstruments社
    • CC2570/CC2571

半導体は、高周波通信と通信制御だけを聴許するradioと呼ぶ石と、
無線通信のための高周波回路と、通信を制御するためのプロセッサまで入ったもの、に分類できます。
また、BLEでは、後者のものは、内臓マイコンにユーザのプログラムも実行できるようになっています。このようなシステム全体が1つのチップに収めたものを、システム・オン・チップ(System On Chip、以下SoC)と呼びます。

ゼロから開発する場合はSoCワンチップにして実装面積とコストを最小にできます。また自社で扱いやすいマイコンがあったり既存製品に搭載したマイコンを使いたいならば、SoCには通信の基本部分だけを処理させて、外部のマイコンに上位の通信処理を置く構成も、とれます。

これらはSoCのなかのファームウェアで実現しているので、いずれの場合でも、モジュールを利用できます。

モジュールの選定

  • 各国の電波法の技術適合認証を取得しているか
  • 米国の再輸出規制(EAR)対象か
  • モジュールの単価、大きさ、内蔵アンテナの位置やコネクタの位置
  • 開発環境
  • 供給の安定さ

Bluegiga

  • スクリプト言語の開発環境がある。
    • モジュール内部のSoCのマイコンでユーザのプログラムを動かせられる。
  • 開発キットは3.6万円程度
  • モジュール単価は~10ドル前後

Apple Bluetooth Accessory Design Guideline , Bluetooth Low Energy部分の日本語訳

これは、Apple社のBluetooth Accessory Design Guidelines for Apple Products (R6)
https://developer.apple.com/hardwaredrivers/BluetoothDesignGuidelines.pdfのうち、Bluetooth Low Eneryに関連する部分を日本語訳したものです。17ページ目から20ページ目までを訳しています。

Bluetooth Low Energy

Bluetooth4.0仕様は、バッテリーリソースが限られたアクセサリをターゲットにした新しい無線通信技術、Bluetooth Low Energyを含みます。
もしBluetooth LEがサポートされていれば、アクセサリーはこの章のガイドラインに従うべきです。

Role

Bluetoothアクセサリーは、Bluetooth4.0仕様 Volume3, Part C, Section 2.2.2.3 に定義されているPeripheral role 、
もしくはSection 2.2.2.1に定義されているBroadcaster roleの、いずれかを実装すべきです。

Advertising Channels

Bluetoothアクセサリーは、アドバタイズのイベントの都度、すべての3つのアドバタイジング・チャネル(37, 38, および39)でアドバタイズすべきです。
Bluetooth 4.0 仕様, Volume 6, Part B, Section 4.4.2.1 を参照。

Advertising PDU

Bluetoothアクセサリーは、次のうちいずれか1つのアドバタイジングPDUを使うべきです:

  • ADV_IND
  • ADV_NOCONN_IND
  • ADV_SCAN_IND

ADV_DIRECT_IND は使うべきではありません。
Bluetooth 4.0 仕様, Volume 6, Part B, Section 2.3.1 を参照。

Advertising Data

Bluetoothアクセサリに送信されたアドバタイジング・データは、
Bluetooth 4.0 仕様, Volume 3, Part C, Section 11 に記述されているように、
次の情報の少なくとも1つを含むべきです:

  • Flags
  • TX Power Level
  • Local Name
  • Services

例えば、もしも電力消費量を低減する必要がある、あるいはすべてのアドバタイズメント・データがアドバタイジングPDUに収まりきらなかったならば、
アクセサリは、Local Name およびTX Power levelデータをSCAN_RSP PDUに置くかもしれません。
Apple製品は、その状態によっては、常にアクティブスキャンをするとは限らないことに、注意してください。

Primary servicesは常にアドバタイジングPDUでアドバタイズされるべきです。
Secondary servicesはアドバタイズされるべきではありません。
アクセサリの主たる利用方法で重要ではないサービスは、もしもアドバタイジングPDUの領域が限られているならば、無視されるかもしれません。

アドバタイジング・データおよびSCAN_RSP PDUのスキャン・レスポンス・データは、
Bluetooth 4.0 仕様, Volume 3, Part C, Section 18 のフォーマットガイドラインに従うべきです:
長さフィールドの次に、AD TypeおよびAD Dataが続きます。

Advertising Interval

Bluetoothアクセサリのアドバタイジング間隔は、
それがアクセサリの発見にかかる時間と接続パフォーマンスに影響するため、
注意深く考慮されるべきです。
電源がバッテリーのアクセサリでは、そのバッテリーリソースもまた考慮すべきでしょう。

Apple製品に発見されるには、Bluetoothアクセサリは、まず最初に、すくなくとも30秒は推奨される20ミリ秒のアドバタイジング間隔を使うべきです。
もしもアクセサリが最初の30秒以内に発見されなければ、アクセサリはバッテリー電力を節約することを選択して、アドバタイジング間隔を長くするかもしれません。
Apple製品が発見する確率を上げるために、Appleはより以下のより長い間隔のいずれかを使うことを推奨します。

  • 645 ミリ秒
  • 768 ミリ秒
  • 961 ミリ秒
  • 1065 ミリ秒
  • 1294 ミリ秒

注意: より長いアドバタイジング間隔は、通常、より長い発見時間と接続時間をもたらします。

Connection Parameters

Bluetoothアクセサリは、LE接続に使われた接続パラメータに責任があります。
アクセサリーは、
適切な時間にL2CAPコネクション・パラメータ・アップデート・リクエストを送信して、
その利用方法にとて適切な接続パラメータを要求すべきです。
詳細は、Bluetooth 4.0 仕様, Volume 3, Part A, Section 4.20 を参照してください。

もしも次の全てのルールに従っていない場合は、その接続パラメータ要求は却下されるかもしれません:

  • IntervalMax *(Slve Latency +1) <= 2 秒
  • Interval Min >= 20 ミリ秒
  • Interval Min + 20ミリ 秒 <= Interval Max
  • Slave Latency <= 4
  • connSupervisionTimeout <= 6 秒
  • Interval Max (Slave Latency +1) 3 < connSupervisionTimeout

Apple製品は、Peripheral Preferred Connection Parameters characteristic のパラメータを読んだり、利用したりしません。
Bluetooth 4.0 仕様, Volume 3, Part C, Section 12.5 を参照。

Privacy

Bluetoothアクセサリーは、すべての状況で、Resolvable Private Addressを解決できるべきです。
プライバシーへの懸念のため、Apple製品は
Bluetooth 4.0 仕様, Volume 3, Part C, Section 10.8
に定義されたランダムデバイスアドレスを使うでしょう。

Permissions

Bluetoothアクセサリーは、serviceとcharacteristicsを発見するために、
ペアリング、認証、または暗号化といった特別な許可を求めるべきではありません。
characteristicの値 または descriptorの値にアクセスするときに限り、それは特別な許可を求めるかもしれません。
Bluetooth 4.0 仕様, Volume 3, Part G, Section 8.1, 5節を参照。

Pairing

Bluetoothアクセサリーはペアリングを要求すべきではありません。
セキュリティの理由で、アクセサリーがCentralとbonded relationship を必要とするならば、
適切であるように、
PeripheralはATTリクエストをInsufficient Authenticaion error codeで却下するでしょう。
Bluetooth 4.0 仕様, Volume 3, Part F, Section 4 を参照。

結果として、Apple製品は必要なセキュリティ手順を進めるでしょう。

ペアリングは、Apple製品次第で、ユーザの認証を要求するでしょう。

Services

Generic Access Profile Service

BluetoothアクセサリーはDevice Name characteristic、
Bluetooth 4.0 仕様, Volume 3, Part C, Section 12.1、
を実装すべきです。Device Name Characteristicは書き込み可能であるべきです。

Generic Attribute Profile Service

Bluetoothアクセサリーは、もしもそのアクセサリーが製品寿命の間にサービスを変更する能力がある場合に限り、Service Changed Characteristicを実装すべきです。

Apple製品は、
アクセサリーから前回読み込み(キャッシュされている)情報に頼ることができるかを決めるために、
Service Changed characteristicsを使います。
Bluetooth 4.0 仕様, Volume 3, Part G, Section 7.1 を参照してください。

Device Information Service

Bluetoothアクセサリーは、Device Information Serviceを実装すべきです。このサービスのサービスUUIDは、
アドバタイジング・データでアドバタイズされるべきではありません。
次のcharacteristicsがサポートされるべきです:

  • Manufacturer Name String
  • Model Number String
  • Firmware Revision String
  • Software Revision String

GATT Server

iOS6では、
iOSデバイスがBluetoothアクセサリーとして使えるように、
アプリケーションがGATTサーバにserviceやcharacteristicsを提供するかもしれません。
この章の推奨は、そのような場合のアクセサリーに適用します。

iOSデバイスは、
データベースの内容は任意の時点で変更できるので、
GAP Service Changed characteristicsを実装します。
したがって、Bluetoothアクセサリーは、
このcharacteristicsの
Characteristic Value Indication
をサポートして、indicationを受信したときは、そのデータベースの対応するキャッシュを無効にします。
Bluetooth 4.0 仕様, Volume 3, Part G, Section 7.1 を参照してください。

Bluetoothアクセサリーは、ATT/GATTリクエストとコマンドの利用を最小に、そして必要な物だけを送信すべきです。
例えば、
アクセサリが特定のサービスを探している時に、
GATT Discover All Services は使ってはなりません。
より少ない送信時間は、より少ない電力消費と等価であり、したがって、アクセサリーとApple製品の両方にとって、よりよいパフォーマンスをもたらします。

Bluetoothアクセサリーは、いかなるエラーも扱えるように十分に頑強であるべきです。
もしも、あるサービスをもつアプリケーションがフォアグラウンドになく、かつ、バックグラウンドで実行されるように明記されていないならば、
ペアリングとCharacteristicの値の読み込み/書き込みは、失敗するかもしれません。

もしも ATT Prepare Write Request が使われたら、
全てのキューイングされた属性は同じ
GATT Service に含まれます。

CBUUIDクラスリファレンス 日本語訳

定数

CB_EXTERN NSString * const CBUUIDCharacteristicExtendedPropertiesString;

extended properties descriptorのUUIDの文字列表現です。
このデスクリプタに対応する値は、NSNumber オブジェクトです。

CB_EXTERN NSString * const CBUUIDCharacteristicUserDescriptionString;

user description descriptorのUUIDの文字列表現です。
このデスクリプタに対応する値は、NSString オブジェクトです。

CB_EXTERN NSString * const CBUUIDClientCharacteristicConfigurationString;

client configuration descriptor
のUUIDの文字列表現です。
このデスクリプタに対応する値は、NSNumber オブジェクトです。

CB_EXTERN NSString * const CBUUIDServerCharacteristicConfigurationString;

server configuration descriptor
のUUIDの文字列表現です。
このデスクリプタに対応する値は、NSNumber オブジェクトです。

CB_EXTERN NSString * const CBUUIDCharacteristicFormatString;

presentation format descriptor
のUUIDの文字列表現です。
このデスクリプタに対応する値は、NSData オブジェクトです。

CB_EXTERN NSString * const CBUUIDCharacteristicAggregateFormatString;

server configuration descriptor
のUUIDの文字列表現です。

CB_EXTERN NSString * const CBUUIDGenericAccessProfileString;

GAP
のUUIDの文字列表現です。

CB_EXTERN NSString * const CBUUIDGenericAttributeProfileString;

GATT
のUUIDの文字列表現です。

CB_EXTERN NSString * const CBUUIDDeviceNameString;

GAP device name
のUUIDの文字列表現です。

CB_EXTERN NSString * const CBUUIDAppearanceString;

GAP appearance UUID
のUUIDの文字列表現です。

CB_EXTERN NSString * const CBUUIDPeripheralPrivacyFlagString;

GAP privacy flag UUID
の文字列表現です。

CB_EXTERN NSString * const CBUUIDReconnectionAddressString;

GAP reconnection address UUID
の文字列表現です。

CB_EXTERN NSString * const CBUUIDPeripheralPreferredConnectionParametersString;

GAP preferred connection parameter UUID
の文字列表現です。

CB_EXTERN NSString * const CBUUIDServiceChangedString;

GATT service changed UUID
の文字列表現です。

CBUUID クラス

16-bitまたは128-bitのBluetooth UUIDを表すクラスです。
16-bit UUIDは、いうまでもなく、Bluetooth Base UUIDで事前に満たされています。
(訳者注:Bluetooth Low EnergyのUUIDは、128-bitが基本です。しかし、Bluetooth SIGが定義したものは16-bitの短縮形UUIDが使えます。この16-bitのUUIDは、Bluetooth Base UUIDという128-bit のUUIDの先頭の末尾16-bitを使うことで、実現しています。)

プロパティ

@property(nonatomic, readonly) NSData *data;

NSDataとしてのUUID

/*!

  • @method UUIDWithString:
    *
  • @discussion
  • Creates a CBUUID with a 16-bit or 128-bit UUID string representation.
  • The expected format for 128-bit UUIDs is a string punctuated by hyphens, for example 68753A44-4D6F-1226-9C60-0050E4C00067.
    /

メソッド

+ (CBUUID )UUIDWithString:(NSString )theString;

16-bitもしくは128-bitのUUID文字列表記からCBUUIDを作ります。
128-bit UUIDはハイフンで区切られた文字列フォーマットを期待します。例: 68753A44-4D6F-1226-9C60-0050E4C00067 。
(訳者注:16-bitのUUIDは、4桁の16進表記文字列で与えます。先頭に0xをつける必要は、ありません。)

+ (CBUUID )UUIDWithData:(NSData )theData;

16-bitもしくは128-bitのデータコンテナからCBUUIDを作ります。

+ (CBUUID *)UUIDWithCFUUID:(CFUUIDRef)theUUID;

CFUUIDRef からCBUUIDを作ります。

CBServiceクラスリファレンス 日本語訳

これはCBServiceクラスのドキュメントを、CoreBluetoothを理解するために必要最小限の部分について、日本語訳したものです。

CBServiceクラスは、ペリフェラルのサービスまたはサービスのincluded serviceを表します。

プロパティ

@property(readonly, nonatomic) CBPeripheral *peripheral;

このサービスが属するペリフェラルへのポインタ。

@property(readonly, nonatomic) CBUUID *UUID;

サービスのBluetooth UUID

@property(readonly, nonatomic) BOOL isPrimary;

サービスのタイプ(primary または secondary)

@property(retain, readonly) NSArray *includedServices;

このサービスでこれまでに発見されたincluded serviceのリスト。

@property(retain, readonly) NSArray *characteristics;

このサービスでこれまでに発見されたcharacteristicのリスト。

CBMutableServiceクラス

CBPeripheralManagerを通してローカルデータベースに追加できる、ローカルサービスもしくはincluded serviceを作るのに使います。
一旦サービスが公開されたならば、キャッシュされて、それ以降は変更できません。
このクラスはCBServiceのすべてのプロパティに書き込み属性を追加します。

iOS6以降で有効です。

@property(retain, readwrite, nonatomic) CBUUID *UUID;

@property(readwrite, nonatomic) BOOL isPrimary;

@property(retain, readwrite) NSArray *includedServices;

@property(retain, readwrite) NSArray *characteristics;

- (id)initWithType:(CBUUID *)UUID primary:(BOOL)isPrimary;

サービスタイプとUUIDで初期化されたサービスを返します。

  • UUID
    • サービスのBluetooth UUID
  • isPrimary
    • サービスのタイプ(primary または secondary)

CBPeripheralManager クラス リファレンス 日本語訳

これはCBPeripheralManagerクラスのリファレンスを、CoreBluetoothを理解するために必要最小限の部分を日本語訳したものです。

CBPeripheralManagerクラスは、peripheral roleへの入り口です。
コマンドは、その状態がCBPeripheralManagerStatePoweredOn のときにだけ、発行されるべきです。
2つ以上のCBPeripheralManagerを同時に使うことはサポートされませんし、そうした場合には不定の振る舞いをするでしょう。

CBperipheralManagerクラスは、iOS6以降で利用できます

プロパティ

@property(assign, nonatomic) id delegate;

Peripheralイベントを受信するデリゲート。

@property(readonly) CBPeripheralManagerState state;

Peripheralの現在の状態。初期値はCBPeripheralManagerStateUnknown。
値更新は、required なデリゲートのメソッド
peripheralManagerDidUpdateState:
に提供されます。

@property(readonly) BOOL isAdvertising;

Peripheralが、今データをアドバタイズしているか、いなかを示します。

インスタンス・メソッド

- (id)initWithDelegate:(id)delegate queue:(dispatch_queue_t)queue;

イニシャライザです。Peripheral roleのイベントは、指定されたキューで処理されます。
もしもキューがnilならば、メインキューが使われるでしょう。

  • delegate
    • Peripheral roleイベントを受け取るデリゲート。
  • queue
    • イベントを処理するdispatch queue。

- (void)startAdvertising:(NSDictionary *)advertisementData;

アドバタイズメントを開始します。サポートされているアドバタイズメント・データ・タイプは、CBAdvertisementDataLocalNameKey と CBAdvertisementDataServiceUUIDsKey です。

アプリケーションがフォアグランドのときは、
初期のアドバタイズメント・データを、28バイトまで、
サポートされているアドバタイズメント・データ・タイプの任意の組み合わせに使えます。
もしこの領域を使い切ると、scan responseの10バイトを追加の領域として、ローカルネームに対してのみ、使えます。

このサイズは、新しいデータタイプそれぞれに必要な2バイトのヘッダ情報を含まないことに、注意してください。

割り当て領域に収まらなかったサービスUUIDsは、特別な”オーバフロー”領域に追加されます。したがって、それらのサービスUUIDは、
iOSデバイスが、それらを明示的にスキャンしたときにだけ、発見されます。

アプリケーションがバックグラウンドにあるときは、ローカルネームは使われず、すべてのサービスUUIDsは“オーバフロー”エリアに置かれます。

see peripheralManagerDidStartAdvertising:error:

seealso CBAdvertisementData.h

- (void)stopAdvertising;

アドバタイズを停止します。

- (void)setDesiredConnectionLatency:(CBPeripheralManagerConnectionLatency)latency forCentral:(CBCentral *)central;

すでにあるセントラルとの接続の、コネクション・レイテンシを希望する値に設定します。
コネクション・レイテンシの変更は保証されず、したがって結果として得られる遅延は、指定したものとは違うかもしれません。
もしも望むレイテンシが設定されないなら、接続が確立した時にセントラルが選んだレイテンシが使われます。
一般に、レイテンシを変更する必要はありません。

see CBPeripheralManagerConnectionLatency

- (void)addService:(CBMutableService *)service;

サービスと、それに関連付けられたcharacteristic(s)をローカルデータベースに公開します。もしもサービスがincluded serviceを含むなら、
まずincluded serviceが最初に公開されねばなりません。

  • service
    • GATTサービス

see peripheralManager:didAddService:error:

- (void)removeService:(CBMutableService *)service;

ローカルデータベースから、公開されたサービスを削除します。もしもサービスがincluded serviceを含むならば、まず最初にincluded serviceが削除されねばなりません。

- (void)removeAllServices;

ローカルデータベースから、すべての公開されているサービスを削除します。

- (void)respondToRequest:(CBATTRequest *)request withResult:(CBATTError)result;

peripheralManager:didReceiveReadRequest: もしくは peripheralManager:didReceiveWriteRequests: のデリゲートのメソッドで受信したリクエストに応答するのに使います。

  • request
    • セントラルから受信されたオリジナルのリクエスト
  • result
    • request を満たそうとした結果

see peripheralManager:didReceiveReadRequest:

see peripheralManager:didReceiveWriteRequests:

- (BOOL)updateValue:(NSData )value forCharacteristic:(CBMutableCharacteristic )characteristic onSubscribedCentrals:(NSArray *)centrals;

1つもしくはそれ以上のセントラルに、更新されたcharacteristicの値を、notificationもしくはindicationで送信します。

返り値は、アップデートが送信されたならばYES、送信キューが満杯ならばNO。
もしNOが返ってきたら、スペースが有効になった時に1度、デリゲートの peripheralManagerIsReadyToUpdateSubscribers: メソッドが呼ばれる。したがって、もしも望むならば、アップデートを再送信する。

  • value
    • notification/indicationで送信される値
  • characteristic
    • 値が変化したcharacteristic。
  • centrals
    • アップデートを受け取るCBCentralオブジェクトのリスト。characteristic を購読していないセントラルは無視されることに注意する。もしもnilならば、characteristicが購読するセントラルすべてが更新される。
      see peripheralManager:central:didSubscribeToCharacteristic:

see peripheralManager:central:didUnsubscribeFromCharacteristic:

see peripheralManagerIsReadyToUpdateSubscribers:

列挙型

CBPeripheralManagerState

CBperipheralManagerの現在の状態を表します。

  • CBPeripheralManagerStateUnknown
    • 不明な状態。すぐに更新されます。
  • CBPeripheralManagerStateResetting
    • システムサービス都の接続が、一時的に失われました。すぐにアップデートされます。
  • CBPeripheralManagerStateUnsupported
    • そのプラットフォームはBluetooth Low Energy Peripheral/Server roleをサポートしません。
  • CBPeripheralManagerStateUnauthorized
    • アプリケーションはBluetooth Low Energy Peripheral/Server roleを使う権限がありません。
  • CBPeripheralManagerStatePoweredOff
    • Bluetoothは現在電源がオフです。
  • CBPeripheralManagerStatePoweredOn
    • Bluetoothは現在電源がオンで、利用できます。

CBPeripheralManagerConnectionLatency

Peripheral-central接続の遅延時間は、メッセージがどれほどの頻度で交換できるか、を制御します。

  • CBPeripheralManagerConnectionLatencyLow
    • バッテリーの持ち時間よりも、素早い通信を優先します。
  • CBPeripheralManagerConnectionLatencyMedium
    • 通信の頻度とバッテリーの持ち時間とのバランスを取ります。
  • CBPeripheralManagerConnectionLatencyHigh
    • 素早い通信よりも、バッテリーの持ち時間を伸ばすことを優先します。

CBDescriptorクラスリファレンス 日本語訳

プロパティ

@property(readonly, nonatomic) CBCharacteristic *characteristic;

属するcharacteristicのポインタです。

/*!

  • @property UUID
    *
  • @discussion
  • The Bluetooth UUID of the descriptor.
    /

    @property(readonly, nonatomic) CBUUID *UUID;

    DescriptorのBluetooth UUIDです。

@property(retain, readonly) id value;

Descriptorのあちあです。様々なデスクリプタに対応するvalue typeの詳細は、CBUUIDクラスで定義されています。

CBMutableDescriptorクラス

iOS6以降で有効です。

- (id)initWithType:(CBUUID *)UUID value:(id)value;

サービスタイプとvalueで初期化されたdescriptorを返します。一旦親であるserviceが公開されたならば、valueは要求されて、ダイナミックに更新することはできません。

  • UUID
    • DescriptorのBluetooth UUID
  • value
    • Descriptorの値

CBATTRequestクラスリファレンス 日本語訳

iOS6以降で有効です。
CBATTRequestクラスは、セントラルからの読み出し/書き込み要求を表します。

プロパティ

@property(readonly, retain, nonatomic) CBCentral *central;

リクエストを発生させたセントラルです。

@property(readonly, retain, nonatomic) CBCharacteristic *characteristic;

値を読み書きするcharacteristicです。

/*!

  • @property offset
    *
  • @discussion The zero-based index of the first byte for the read or write.
    /

    @property(readonly, nonatomic) NSUInteger offset;

    0から始まる、読み書きする最初のバイト位置です。

@property(readwrite, copy) NSData *value;

読み書きするデータです。
読み出し要求では、value はnilで、respondToRequest:withResult: に返信する前に設定されるべきです。
書き込み要求では、valueは書き込まれるべき値を含んでいます。