GoogleのEddystoneとはなんなのか

205件のシェア(すこし話題の記事)

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

GoogleからEddystoneなる発表がありました

米Googleから、2015年7月14日に、Eddystoneが発表されました。これは、Bluetooth Low Energy(BLE)を用いたビーコン向けの規格で、競合としてはApple社のiBeaconがあります。 iBeaconの競合だからと、2年前のエイプリルフールでふざけた規格を発表した私に、少し調査をしろという伝令が廻ってきたとか廻ってきてないとか、そんな状況なので少し調べた内容をまとめます。

EddystoneとiBeaconの違い

EddystoneがiBeaconと外枠で大きく違う点が2つほどあります。それは

  • iBeaconと違いオープン(Apache v2.0ライセンス)である
  • AndroidやiOSなど、BLEをサポートしているマルチプラットフォームで利用できる

iBeaconは良い意味でも悪い意味でも、iOSに仕様をブラックボックス化されており、iOS7以上で気軽に実装が出来てが非常に楽でした。 その反面、やりたいことをダイレクトに行えているのかがわからない(おそらく端末ごとのBLEパラメータの調整をOSレベルでしてるはず)という欠点もありました。 EddystoneはGitHubにてソースコードがまるごと公開されており、その気になれば色々細部に調整や拡張できそうな気がします。 トラブルが起きた際も追いかけやすい利点があります。

また、iOSはApple社が主導で動いていましたが、EddystoneはGoogle社が動いており、AndroidやiOSなどのクロスプラットフォームで利用できるのがウリです。 iBeaconもAndroidで利用できますが、Alt Beaconなどのライブラリを手配したりと、弊社小室が孤軍奮闘していた記録が沢山残っています

そもそもBLE Beaconとはなんなのだろうか

通常のBluetooth機器はマスター(親)とスレーブ(子)をペアリングして利用します。 身近なところでパソコンとキーボード・マウスや音楽プレーヤーとヘッドホンなど、親となるパソコン・音楽プレーヤーと異なるキーボードとマウスを、ヘッドホンをペアリングして利用しています。 このペアリングする動作の時に、周辺機器をスキャンする動作が発生するのですが、機器のリンクをするのに識別情報を送信する必要があります。 Bluetoothで通信を行うための0〜39チャンネルのうち、37〜39チャンネルをアドバタイジングチャンネルと呼び、スレーブからアドバタイジングパケットを送出します。 それを、マスターでスキャンして、ペアリングします。(この場合、マスターをスキャナとかイニシエータとか、スレーブをアドバタイザとか呼びますがそこまで重要ではない単語です)

BLE Beaconは、このアドバタイジングチャンネル内で、アドバタイジングパケットを利用しています。 そのため、ペアリングという概念がありません。 その代わり、チャンネルを専有することがなく、一定間隔で送信され、無線LAN等の2.4GHz帯を使用する通信と混線することが少ないという利点があります。 アドバタイジングパケットの中で、Beacon用にフォーマットを決めたのが、iBeaconやEddystoneとなります。

送出フレームタイプ

現在Eddystoneで公開されている送出フレームタイプが3パターンあります。 iBeaconでは1パターンのみでした。 ここではそれぞれのフレームタイプがどんなものかを説明します。

iBeaconのフレームタイプ

iBeaconで慣れ親しんだUUID/Major/Minor/Measured Powerを送るフレームタイプです。

Byte offset Field Description
0-1 Identifier Apple Conpany Identifier:0x004C
2 Data Type iBeacon:0x02
3 Data Length 0x15 (21byte)
4-19 UUID 固定ID
20-21 Major 0-65535で好きな数字を設定
22-23 Minor 0-65535で好きな数字を設定
24 Measured Power Measured Power at 1 m

詳しい内容等はiBeacon系の資料を調べていただければいいと思いますが、実際のデータ部分は4バイト目からの21バイトが固定長です。

Eddystone1 Eddystone-UID

iBeaconに最も近いフレームです。UUIDの代わりとなります。

Byte offset Field Description
0 Frame Type  0x00(UID)
1 TX Power Calibrated Tx Power at 0 m
2-11 Namespace ID 名前ID
12-17 Instance ID インスタンスID
18-19 RFU Reserved for future:0x00

Namespace IDが、iBeaconでのUUIDに該当する箇所に当たります。 Eddystoneでは、ドメイン名をSHA-1ハッシュ化した最初の10バイトを使用することを推奨しています。 弊社のClassmethodの場合は、「7C C6 68 68 AA 38 5F F7 6F 46」となります。 もしくは、iBeaconのUUID(version 4 UUID)の、5バイト目から6バイト分削除したものの利用を併せて推奨しています。(iBeaconのUUIDは16バイト) Instance IDはiBeaconのMajor/Minorと同様の使用方法です。

端末を特定したネイティブアプリでの動作を想定しています。

Eddystone2 Eddystone-URL

UrlBeaconの概念を取り入れた仕組みです。 Eddystone端末からURLの入ったフレームを送出します。

Byte offset Field Description
0 Frame Type 0x10(URL)
1 TX Power Calibrated Tx Power at 0 m
2 URL Scheme  URLのスキーマを指定できる。以下のフォーマット

Hex Expansion
0x00 http://www.
0x01 https://www.
0x02 http://
0x03 https://
3+ Encoded URL 上記URLスキーマーを除いたURL。最大17バイト。

2014年10月にGoogle社が発表した新プロジェクトで、「Physical Web」という規格があり、今回のEddystone-URLがまさにその実装と言った形です。特定のアプリに依らない、IoT機器との連動やブラウザだけで簡単に動作する、オープンなものを目指したものです。 ただし、送出できるパケット数は最大でも17バイトと決まっており、基本的にURL短縮サービスの利用を前提としています。

想定例 (Eddystone-URLの利用想定図 引用元:Google Developers Blog

Eddystone3 Eddystone-TLM

Eddystoneの状態を送出するフレームになります。

Byte offset Field Description
0 Frame Type 0x20(TLM)
1 Version TLMバージョン:0x00
2-3 VBATT バッテリー残量 1mV/bit
4-5 TEMP 温度
 6-9 ADV_CNT 起動、もしくは再起動してからのアドバタイジングパケット送出回数
10-13 SEC_CNT 起動、もしくは再起動してからの経過時間

バッテリーの状態や温度といったアラートをスキャナ側で把握することができる仕組みになっています。

最後に

iBeaconでちょっと欲しかった機能を拡張した形となったEddystoneですが、なによりURLの送出ができるようになったのが大きいです。 今まではネイティブアプリが必要であったものが、今後はアプリがなくてもChrome BrowserなどでURLを開くといったことができるようになります。 例えば、運行中のバスの情報を知りたい時、バス停に近づいただけで今の運行情報が確認できたり。 例えば、映画のポスターにEddystone-URL送出Beaconを設置して、その映画のトレーラー動画に直接リンクしたり、とか。 今後の使い方次第では夢が広がる気がします。 次のエントリーでは、実際にこれらのフレームを利用してAPIによるサンプルを動かしてみようと思います。

  • Mamoru Murayama

    「iBeaconはGitHubにてソースコードがまるごと公開されており・・・」 は 「Eddystoneは・・・」ですよね?

    • Takatoshi Ohmura

      大変すいませんでした。リンク先からも分かる通り、Eddystoneでした。
      ご指摘ありがとうございます。修正いたしました。

  • hiyokon

    iBeacon の major/minor は 0-65535 ではないでしょうか?