WebエンジニアにとってのIoT ~Physical Webが拓く未来~

第2回 Physical Web技術解剖(1)-Inside UriBeacon

この記事を読むのに必要な時間:およそ 5.5 分

前回はPhysical Webの概要を説明させていただきました。早速この技術の上でどんな応用が可能なのか考えていきたいところではありますが,そのためにはまずその基盤となる技術を把握し,制約を知らなければなりません。

今回と次回に分け,一つ一つのパートを技術的に掘り下げていきたいと思います。

さて,まずは何と言ってもUriBeaconです。UriBeaconではBluetooth Low Energyを利用していますので,まずはそちらについて解説していきます。

Bluetooth Low Energy

Bluetoothの現状

UriBeaconではBluetooth Low Energyという無線通信技術を使って近接検知を行います。Bluetooth Low Energyは,⁠Bluetooth LE⁠⁠BTLE⁠⁠BLE⁠というように略されます。本稿では以降BLEと略すことにします。

Bluetoothを知らないという人は現在ではさすがにいないでしょう。ヘッドホンやキーボードなど,日常でBluetooth機器の恩恵に預かっている方もたくさんいるかと思います。

ですが,Bluetoothの登場から現在までの変遷についてまでは,あまり知られていないのではないでしょうか。

Bluetoothは1999年にバージョン1.0の仕様が発表され,2000年代前半から普及期に入りました。ユビキタスネットワークという言葉が流行っていたのを思いだす人もいるかもしれません。

Bluetoothは登場以降,バージョンを重ねながら通信の高速化などの進化を続けていましたが,Wi-Fiなどの他の無線通信技術とうまく差別化を計れずに伸び悩んでいた所がありました。

こういった中,それまでの高速化追求とは方針を別にした,省エネの方向にターゲットを向けた規格であるBLEを発表しBluetooth 4.0において統合されました注1)⁠

注1)
Bluetooth 4.0は,EDR(Enhanced Data Rate)⁠HS(HighSpeed)など,これまでのバージョンで追加されてきた規格も含んでいます。ここに新たに追加されたのがLEであり,4.0=LEではありません。

また,4.0の後にも進化は続いていて,2014年12月には4.2の規格が発表されIPv6との連携なども考えられています。

UriBeaconで利用されているのは,この省エネバージョンであるBLEの規格になります。

BLEの手続きの流れ

主題があまり逸れてしまわないように,ここではBLEの仕組みのうち,UriBeaconの動作の理解に必要な部分だけ簡単に解説していきます。

それ以上のBluetooth及びBLEの情報について,より詳しくは専門の文献を当たっていただければと思います。

アドバタイズ

BLEのフローはまずはアドバタイズという動作から始まります。BLEのサービスを提供するデバイスが,⁠自分はこんなサービスを提供していますよ」と言う情報を周囲に発信します。この情報を載せたパケットをアドバタイジングパケットと言います。サービスの識別にはUUIDを利用します。一般的にはアドバタイジングパケットService UUIDが載せられます。

図1 ビーコンはアドバタイジングパケットを放出し,それぞれのパケットにはServiceを識別するためのUUIDが載っている

図1 ビーコンはアドバタイジングパケットを放出し,それぞれのパケットにはServiceを識別するためのUUIDが載っている

1秒おき,あるいは0.5秒おきなど,設定されたインターバルに従い,このブロードキャスト処理を行います。もちろんインターバルが短いほど,相手に到達しやすくなるのですが,電力は消費しやすくなります。なので,トレードオフを考慮してインターバルを設定することになります。

ちなみに到達可能距離は10m程度と言われています。電力を弱めれば到達距離を短くすることも可能です。

スキャン

BLEのスキャナが起動しているデバイス(スマートフォン等)が,このように発信されているアドバタイジングパケットの到達範囲内に入ることでこのパケットを読み込み,解析します注2)⁠

注2)
1つのアドバタイジングパケットで必要な情報を載せきれない場合は,ScanRequest/ScanResponseというやり取りでもう一段情報をやりとりすることも可能です。

図2 スキャンすることでパケットを取得し,その中のService UUIDなどをチェックする

図2 スキャンすることでパケットを取得し,その中のService UUIDなどをチェックする

Service UUIDなどを見て識別を行い,このパケットの発信元が自分の求めるサービスを提供していると判断すると,接続処理を行います。

図3 UUIDを見て,目的のサービスだと判断したら接続

図3 UUIDを見て,目的のサービスだと判断したら接続

接続を行うことで,デバイスが提供するサービスを利用することが出来るようになります。このとき必要であればペアリングなどを行いますが,BLEではペアリングを必要としない用途で使われることも多いようです。

サービスとは何か

ではここで言う「サービス」とは何でしょうか注3)⁠

注3)
BLEではGATTプロファイルというプロファイルの上でサービスを定義していきます。こちらに関してもより詳しくは専門の文献を当たってください。

サービスにはcharacteristic(特性)と呼ばれる値がぶら下がっています。この値に対して読み書きしたり,値の変更をすることができます。

例えば,エアコンのコントローラであれば次のような例が考えられます。

図4 エアコンのコントローラというサービスがあり,4BC78330-337F-4D08-89B4-9A1028B56583というUUIDを割り当てている

図4 エアコンのコントローラというサービスがあり,4BC78330-337F-4D08-89B4-9A1028B56583というUUIDを割り当てている

エアコンのコントローラというサービスがあり,4BC78330-337F-4D08-89B4-9A1028B56583というUUIDを割り当てています。

このサービスは3つのcharacteristicを持っています。それぞれのcharacteristicUUIDをあてがわれています。

  • 現在の室温(9200B09-F42C-4408-8277-C084F31FA746)
  • 設定温度(47E26BA3-CF6E-4F2B-82F9-05A5C752287E)
  • スイッチ(A0370A52-E8DC-4478-BECF-420C3E373666)

BLEで利用するservicecharacteristicUUIDが,あまりヒューマンリーダブルではないために,パッと見たときに難しく感じるかもしれませんが,次のようにWebのサービスと比較してイメージするとわかりやすいかもしれません。

図5 REFTfulなWebサービスではドメインを指定して接続し,パスを指定してGET/POSTなどを行う

図5 REFTfulなWebサービスではドメインを指定して接続し,パスを指定してGET/POSTなどを行う

図6 BLEではService UUIDを指定して接続し,CharacteristicのUUIDを指定してread/writeなどを行う

図6 BLEではService UUIDを指定して接続し,CharacteristicのUUIDを指定してread/writeなどを行う

図注)
ただし,ステートレスな処理が基本となるHTTPと違い,BLEの場合は一度serviceに接続すると基本的にはその接続を維持したままでcharacteristic読み書きを行います。また、HTTPのパスのように階層構造は持つことができず,characteristicは必ずserviceに直接ぶら下がることになります。

基本的にはkey-valueペアのようなものだ,とわかってしまえば凄く単純な話です。

ただし,いわゆるデバイスのon/offを制御するスイッチのような役割を持つcharacteristicもよく使われます。このように,writeすることで動作を切り替えることが出来るコントロールポイントとしても振る舞えるという点は覚えておきましょう。

ちなみに上の例のエアコンのように,BLEでサービスを提供する側の役割をPeripheral(ペリフェラル)上の例のスマートフォンのようにサービスを享受する側の役割をCentral(セントラル)と呼びます。

著者プロフィール

加藤亮(かとうりょう)

ソフトウェアエンジニア。

比較的プロトコルとフロントエンド寄り。

2014年7月よりリクルートテクノロジーズアドバンスドテクノロジーラボ所属。

コメント

コメントの記入