YAPC::Asia2014 - O2O/IoT/Wearable時代におけるWeb以外のネットワーク技術入門

O2O/IoT/Wearable時代における Web以外のネットワーク技術入門

株式会社リクルートテクノロジーズ アドバンスドテクノロジーラボ 加藤 亮

YAPC::Asia 2014

TOPIC

• MQTTの紹介と関連技術との比較

• Bluetooth LE/iBeaconの概要と応用

MQTT

What’s MQTT

• PubSubプロトコル

• 省エネ

• QoS, Willなどのサポート

• ワイルドカードを使った柔軟なSUBSCRIPTION

• シンプルな仕様(ver3.1日本語仕様書43ページ)

EventHub系ツール/サービス

• Plagger (コマンドラインツール)

• Yahoo Pipes (Webサービス)

• IFTTT (スマホアプリ)

こういったサービスのサポート対象に機械が加わるのを イメージするとよいかも

EventHub系ツール/サービス

RSS Gmail

Evernote

IFTTTの例

IFTTTTwitter

RSSを定期的にチェックして、 更新情報があれば

天気 予報

instagram

Dropbox更新情報

EventHub系ツール/サービス

RSS Gmail

Evernote

IFTTTの例

IFTTTTwitter

Gmailに送信するとか

天気 予報

instagram

Dropbox

更新情報

EventHub系ツール/サービス

RSS Gmail

Evernote

IFTTTの例

IFTTTTwitter

instagramに新しい写真がアップされたら

天気 予報

instagram

Dropbox

写真

EventHub系ツール/サービス

RSS Gmail

Evernote

IFTTTの例

IFTTTTwitter

Dropboxに保存するとか

天気 予報

instagram

Dropbox

写真

PubSub

監視 カメラ 照明

エアコン

MQTTの例

MQTT Broker

1. Subscribe 特定のイベントの監視照明&エアコン -> Broker「誰かが入室したら教えてね」

PubSub

監視 カメラ 照明

エアコン

MQTTの例

MQTT Broker

2. Publish 特定のイベントの通達　 監視カメラ -> Broker「Aさんが入室したよ」

event: 入室 data: Aさん

PubSub

監視 カメラ 照明

エアコン

MQTTの例

MQTT Broker

3. SubscriberへのDispatch　

Broker -> 照明&エアコン「Aさんが入室したよ」

event: 入室 data: Aさん

Broker 「入室イベントを待ってたのは照明とエアコンだったよな…」

event: 入室 data: Aさん

PubSub

監視 カメラ 照明

エアコン

MQTTの例

MQTT Broker

4. Eventに対応したアクション　

エアコン「人が入ってきたので室温を調整しよう。Aさんの場合は27度」

event: 入室 data: Aさん

照明「人が入ってきたので明るくしよう」

event: 入室 data: Aさん

Action

Action

PubSub

監視 カメラ 照明

エアコン

MQTTの例

MQTT Broker

IFTTTなどのサービスはHubのほうがレシピに従い能動的に動く PubSubではクライアント側が能動的にPublish/Subscribe

M2M以外でもFacebookに買収されたBeluga(Group Messenger)が採用

必ずしも機械だけのためと考える必要はない

PubSubはグループチャットと相性がよい !Event(Topic) = チャットルーム EventのSubscribe=チャットルームへの参加 EventのPublish=チャットルームでの発言

MQTTを機械のためのグループチャットと考えると イメージしやすいかも

TOPIC

• TOPIC - スラッシュ区切りのtree構造の表現でイベントを監視

finance/stock/ibmfinance/stock/ibm/currentprice

finance/stock/ibm/closingprice

• 二種類のワイルドカード

finance/stock/+/currentprice

finance/stock/ibm/#そのレベルのみのワイルドカード

これより下のレベルを全て含めるワイルドカード

省エネ

• M2Mを前提 - 電池型(特にボタン電池)では非常に重要

• バイナリフォーマットのパケット&手続きの簡略化

• BTLE, HTTP2.0/SPDYなど現在のプロトコルのトレンド

• HTTP2.0の場合は省エネというより高速化のほうが焦点ではある

耐障害性 (QoS/Will)

QoS

• Quality of Service

• QoS0, QoS1,QoS2という三つのレベル

• 機械はある程度安定して動き、ネットワーク(特に無線)は不安定になる事が多い、という前提

• Publishされたメッセージが、Subscribeしたデバイスに確実に届くことをどこまで保証するか、重複を許容するかをQoSレベルで制御

Will

• セマンティックなLeave Message。遺書。

• コネクションのロスト自体をSubscribe可能なイベントとする

• WillなしでもTimeout/Pingなどと合わせ切断検知自体は出来る。

MQTT-SN

• SN = Sensor Network

• LAN内の全てのノードがサーバーに直接接続する必要はない

• Gatewayの利用

• センサー系の小型無線デバイスのためにさらに省エネな仕様

MQTT-SNMQTT Broker (Server)

MQTT-SN Gateway

MQTT-SN Client

MQTT-SN Client

MQTT-SN Client メッセージのやり取りをaggregateしたり

TOPICを2byteのIDに置き換えたりして効率化できる

MQTTの混乱ポイント

• PubSubプロトコルなのに何故かHTTPとの比較

• AMQP, XMPP, STOMP, Redis PubSubなどの他の技術との差異

HTTPとの比較

「MQTTはHTTPに比べて省エネである」 という文章がMQTTの紹介文によく出てくる

Long PollingやWebSocketとの比較記事など

そもそもRedisのPubSub機能やSTOMPなどの 技術と比較すべきでは?

そもそもプロトコルのレイヤーが違うのでは？ なぜHTTPと比較してるの？

おさらい HTTPを使ったPush技術

• Polling

• Long Polling

• Chunked Transfer Encoding/Server Sent Event

• WebSocket

Polling

Client(User A)

Server

HTTP Request

HTTP Response

新しい情報がないかサーバーに確認

Polling

Client(User A)

Server

30秒待つ

Polling

Client(User A)

Server

HTTP Request

HTTP Response

30秒の間に新しい更新が無かったか、 サーバーに確認

Polling

• 15-20年くらい前のCGIチャットとか

• 空白の期間ができ、リアルタイム性が劣る

• 30秒に1回を3秒に1回にすると10倍のサーバー負荷

Long Pollingチャットサービスの例

Client(User A)

Server

HTTP Request

Long Pollingチャットサービスの例

Client(User A)

Server

HTTP Request

レスポンスをすぐに返さない

HTTP Request

Long Pollingチャットサービスの例

Client(User A)

Server

HTTP Request

暫く待つ

Long Pollingチャットサービスの例

Client(User A)

Server

HTTP Request

ユーザーへのメッセージが届いたら

User Aへの メッセージ

Long Pollingチャットサービスの例

Client(User A)

Server

このタイミングで初めて そのメッセージをのせてHTTPレスポンスを返す あるいはタイムアウトで、空レスポンスを返す　

User Aへの メッセージ

HTTP Response

Long Pollingチャットサービスの例

Client(User A)

Server

HTTP Request

レスポンスを受け取ったらユーザーはすぐに もういちどリクエストを送る。 サーバーはすぐにレスポンスを返さずに 同様に暫く待つ。　

Long Polling

• レスポンスを受けてから、もう一度サーバーにリクエストを張りにいくまでに隙間は出来る。

• そこでサーバーがメッセージを受けた場合の対応を考える必要がある。

• Request/Responseのヘッダなど、無駄が多い

Server Sent Event

• HTML5

• 一度サーバーに引っ掛けておくと、イベントが発生するたびにサーバーからパケットが送られる。

• サーバー -> クライアントの一方向

• クライアントからのpingとタイムアウトによる切断検知が出来ないのでそこは注意

APNS/GCM & HTTP GET

M2Mの議論とは少しずれるが iOS/Androidのネイティブアプリであれば それぞれのPUSH通知サービスを利用できる

APNS/GCM & HTTP GET

Client(User A)

ServerApple/Google

TOKEN

通知用トークンを発行してもらい取得Apple: Device Token Google: Registration ID

APNS/GCM & HTTP GET

Client(User A)

ServerApple/Google

UserA:TOKEN

取得したトークンをサーバー上に保存

APNS/GCM & HTTP GET

Client(User A)

ServerApple/Google

User Aへの メッセージ

ユーザーAへのメッセージが届いたら

UserA:TOKEN

APNS/GCM & HTTP GET

Client(User A)

ServerApple/Google

User Aへの メッセージ通知

該当ユーザーのトークンを使って、 iTunes Connect/Google PlayのPUSHサービスに通知

TOKEN

APNS/GCM & HTTP GET

Client(User A)

ServerApple/Google

User Aへの メッセージ

通知iTunes Connect/Google Playが、

トークンにマッチするユーザーのデバイスにPUSH通知

APNS/GCM & HTTP GET

Client(User A)

Server

HTTP Request

Apple/Google

User Aへの メッセージ

通知を受けると、(通知からアプリを起動すると) アプリはサーバーに更新を確認

APNS/GCM & HTTP GET

Client(User A)

ServerApple/Google

User Aへの メッセージ

HTTP Response

更新情報があれば取得

APNS/GCM & HTTP GET

コストをかけて今までのStatelessなHTTPとは違う アーキテクチャのサービスを用意しなくても

ある程度ならリアルタイム性を実現できてしまう

HTTPによるM2Mネットワーク

HTTPによるM2Mネットワークこの分野でのMQTTの出現に至る経緯を追う

M2M(machine to machine)のネットワークを HTTP(REST)でやっていこうという議論

室温計

エアコンClient

HTTP GETで室温を取得

HTTP PUTで温度設定

HTTPによるM2Mネットワーク• AtompubのようなRESTfulアーキテクチャ

• ETag, If-Modified-Sinceなどを使ったキャッシングやトランザクション管理

室温計 Client

HTTP GETで室温を取得

Proxy

取得した結果をキャッシュ

HTTP GETで室温を取得

リアルタイムでデータの変更通知が必要な場合は Long Pollingとかmultipart/x-mixed-replaceとか

If-Modified-Since

テキストベースのHTTPは 省エネが要求されるM2Mにおいては厳しいし RESTful HTTPだけでは解決しない問題もある

MQTT CoAP

別のプロトコルの提案

クラサバPubSubモデルへHTTPをベースに

マシンネットワーク向け最適化

こういった経緯があり、MQTTの紹介でHTTPとの比較が出る プロトコルの性質自体は全然違うもの

CoAP/CoRE• Constrained Application Protocol (IETF)

• Constrained RESTful Environment

• HTTPフォーマットのバイナリ化とかUDP Multicastとか(TCPも可能)

• Proxy使ったHTTPとのInterOpも(HTTP MappingやCaching)

• Observeオプション

• BonjourのようなDNS-SD

• LANの外とリアルタイムな通信するためには工夫が必要

Bonjour (DNS-SD)

• Multicast DNS & DNS Service Discovery

• DNSのPTR/SRV/TEXTレコードを使う

• PTRレコードでサービス検索

• SRVレコードでサービスのホストを検索

• AレコードでIPを取得

• 必要であればTXTレコードでサービスのcapabilityとかstatusを取得

• 昔iTunesがセキュリティソフトに引っかかってたのはこいつが原因だったりする(dnssd.dll)

• Zero Configuration Network

CoAP VS MQTT

• CoAPはWebアーキテクチャとの親和性高い

• CoAPと比較するなら、正確にはMQTTというよりMQTT-SNかも

• 両方とも本来の用途であるマシンネットワークにおいて、商業施設や家電系のベンダー以外のエンジニアが遊ぶ隙間が現状そんなには無さそう

• MQTTだとマシンネットワーク以外での応用で遊ぶ余地はあるかも

• まだ標準化の途中なので要ウォッチ

• http://www.slideshare.net/KaoruMaeda/ietf90iot (レピダム前田さん)

CoAPでNAT Traversalどうしようみたいな

議論を見かけたので

(Signaling Channelどうすんだという話?)

WebRTCの流行もあるので

ついでにNAT Traversalについても

NAT Traversal (NAT越え)

• LANの外とP2P通信するためには、一般的にはどちらかが、あるいは2つのコネクションを使い両方がサーバーになる必要がある(厳密には、TCP Simultaneous Openなどを使えばクライアント同士で接続は可能ではある)

• ルータの外からLAN内のサーバーにアクセス出来るようにするには(IPマスカレード)ポートフォワーディングが必要

• ICEという標準化仕様があり、SIP, XMPP Jingle, WebRTC(Trickle ICE)のような音声、動画のP2P通信のために使われている

• UPnPなども

VoIPの例

Signaling Server

Peer A Peer B

Signaling Channel Signaling Channel

メッセンジャーなどで通信

VoIPの例

Signaling Server

Peer A Peer B

Signaling Channel Signaling Channel

RTP

Data Channel(Audio, Video)

音声や動画通信をP2Pで始めたい(サーバー経由はコスト高い)

VoIPの例

Signaling Server

Peer A Peer B

RTP

NATs NATs

PeerBのTransport Addressが 取得できない

PeerAのTransport Addressが 取得できない

現実はNATが存在し、簡単にはP2P通信を実現できない

ICE

Interactive Connectivity Establishment

Hole Punching

Local Host

NATs ローカルホストはNATを通して、 外のネットワーク上にあるサービスにアクセス

NATに穴をあける必要がある

Hole Punching

Local Host

NATs

192.168.0.1:10001

10.100.100.100:10002

NATはトランスポートアドレスをアロケートして、 ローカルホストとのマッピングを行う

Hole Punching

Local Host

NATs

192.168.0.1:10001

10.100.100.100:10002

このグローバルアドレスに パケットが来た場合

Hole Punching

Local Host

NATs

192.168.0.1:10001

10.100.100.100:10002

マップされたローカルホストに パケットを送信

Hole Punching

ルータによって振舞が変わる 必ずしもうまくはいかない

!Transport Address(IP&Port)をどうチェックに使うか

パケットを送ってきた相手に対して、こちらから送信したことがあるか などのチェックの仕方など

STUN

STUN Server

STUN Client

NATs

Server Reflexive Transport Address

Host Transport Address

外から見て自分のアドレスがどうなっているかを 確認するためのもの !STUNサーバーはリクエストを受け取ると 自分から見える相手のアドレスを返すだけ、という 非常にシンプルな機能のサーバー

ICE

Signaling Server

Peer A Peer B

NATs NATs

STUNサーバーを利用し、外から見える自分のアドレスを取得

STUN Server

ICE

Signaling Server

Peer A Peer B

NATs NATs

外から見えるアドレスやローカルのアドレスなど候補を集めて シグナリングチャンネルを通して相手と交換

PeerBと通信するための アドレス候補のリスト PeerAと通信するための

アドレス候補のリスト

ICE

Peer A Peer B

NATs NATs

取得した候補アドレスのペアを優先順位に従って順にチェック 通信できるアドレスのペアを探す

PeerBと通信するための アドレス候補のリスト PeerAと通信するための

アドレス候補のリスト

お互いがSTUN Server/Clientとなり、 相手にリクエストを投げる

4-way handshake

ICE

Peer A Peer B

NATs NATs

PeerBと通信するための アドレス候補のリスト PeerAと通信するための

アドレス候補のリスト

どうしてもつながらない場合もある

TURN

TURN Server

TURN Client

NATs

Remote Peer

Channel Binding

Client ReflexiveTransport Number Relayed Transport

XXX.XXX.XXX.XXX:10001 0x4001 YYY.YYY.YYY.YYY:10001

XXX.XXX.XXX.XXX:10001 0x4002 YYY.YYY.YYY.YYY:10002

XXX.XXX.XXX.XXX:10002 0x5001 YYY.YYY.YYY.YYY:10003

NATs

TODO: need peer reflexive address?

TURNでのチャンネルも準備して候補アドレスに含め、交換しておく

STUNの上にのってるリレーサーバー用のプロトコル

相手と通信するためのアドレスをマップして チャンネルのバインドを行っておく

ICE

Signaling Server

Peer A Peer B

NATs NATs

リレーサーバーを最後の手段として、そこを通して音声や動画を送信

TURN Server

興味のある人は、 より詳しくはWebRTC, XMPP Jingle, SIPなどの

関連ドキュメントを

Chromeでの実装: https://code.google.com/p/webrtc/

(旧libjingle)

• Gmailでチャットサポート(XMPP) • その上でビデオチャットサポート(Jingle拡張/libjingle) • WebRTCが登場しlibjingle上でWebRTC用の機能拡張 • webrtcプロジェクトに移行

経緯

MQTTと他の技術との差異 Message Queue? Messaging?

What’s MessageQueue

Client Worker

Queue

Messages

JobQueueの例

Client Worker

Worker

Workerひとつずつ順番にジョブを処理していく。 一つのジョブはどれか一つのワーカーによって処理される。

JobQueue以外でも

Publisher Subscriber

Subscriber

Subscriber

一つのメッセージがワーカー全員にコピーされて配られることもある。Fanout(Broadcast) 他にもいろいろ分散処理のための機能

Patterns

• Request/Response

• Producer/Consumer

• Publish/Subscribe

AMQP

AMQP

• Advanced Message Queuing Protocol

• エンタープライズに耐えうる分散システムのためのもの

• 実装としてはRabbitMQが有名、他にはActiveMQも

• RabbitMQはAMQP以外もいろいろサポート(MQTT, STOMPも)

AMQP• ExchangeとBindingでQueueへのルーティング制御(TOPIC/FANOUT/DIRECT)

• これらを備えたシステムをMessage Brokerと呼ぶ

Binding

Binding Queue 1

Queue 2

Queue 3

Queue 4

Exchange 1

Broker

AMQP• TCPのコネクション管理はコストが高い

•一つのTCPコネクション内で複数のチャンネルを使う

• Client内でスレッド毎に別のチャンネルを使える

Connection

Broker

Channel 1

Channel 2

Channel 2

Client

Thread 1

Thread 2

Thread 3

Acknowledgement

•メッセージをいつ、キューから削除するかを制御

•コンシューマがメッセージを受け取ったとき

•コンシューマがメッセージを受け取り、そのメッセージをストレージに保存したとき

•コンシューマがメッセージを受け取り、そのメッセージに関する処理が完了したとき

Journaling(実装)

• Queueへのメッセージのadd/removeをログファイルに記録しておくことが出来る

• Queueが落ちた場合、復帰後、ログのリプレイで落ちる前の再現が可能

•クライアントのメッセージ送信から、ロギングまでのインターバルは0にはならないので、100%安全ではない。重要なデータは、クライアント側でトランザクション管理が必要

AMQP VS MQTT

• MQTTのMQはIBMが提唱したしたときにMessage Queue関係のプロダクトラインから生まれた名残

• プロトコルを実装する際に必ずしもQueueが重要でなく、PubSubできればよい。

• なので分散処理のためのMessage Queue関係のプロダクトと真っ向から競合するものではない

• とはいえAMQPでPubSubも実現可能だし, RabbitMQ自体はMQTTも使えるようになっていたりする。

• AMQPは仕様がでかい core v1.0のPDFが124page -> シンプルにPubSubだけが欲しいなら無駄な複雑性

• AMQPは基本的にはバックエンドの分散処理のためのもの

XMPP

XMPP

• Extensible Messaging and Presence Protocol

• 1対1のテキストチャット

• フレンドリスト(roster)やプレゼンスの管理

• グループチャット(MUC)

• PubSubに関しても拡張がある XEP-0060

• そもそもフレンドリストやPresenceの管理をPubSubで行っている

XMPP昔Perl Oceanというのを作ったときに

XMPPプロトコルについては説明いっぱい書きました 日本語のまとまった解説ってなかなか無いので宜しければどうぞ

OceanについてはYAPC2012でlapisさんのセッションがありました。

MQTT VS XMPP

• 基本的には両者ともバックエンド向けのものではない

• MQTTは一応OAuthなど、他の認証の仕組みを使ってもよいとは書かれている。CONNECTパケットフォーマット仕様はusernameとpasswordが固定確保。XMPPではSASLの仕組みで認証方式を柔軟に選択できる仕様にはなっている

• 機能的にはXMPPはチャット関係の機能は片っ端から揃っており、MQTTで出来ることもだいたい可能(PubSub拡張など)

MQTT VS XMPP

• XMPPの仕様は大きくて複雑。RFC Core 211ページ & IM 114ページ。(MQTTは48ページ)。いろいろ出来る分、複雑で実装コストも高い

• 本当にプレゼンスは必要か?　PCの前で座り続けるユーザーのために作られた仕様。ポケットの中に常にデバイスがある時代には最適ではないのでは? ユーザーのプライバシー意識の問題も。テレビ電話が流行らなかったのと同じ問題があるかも。プレゼンスはサービス運用時のスケールも難しい。

• XMPPはレガシーで微妙な仕様がたくさん残っている(HTTP APIを使えば十分な機能をXMPP内で実装しなければいけない)。

Redis/STOMP

• シンプルなテキストベースのPubSub

• ただしRedisはプロトコルというより実装で、認証もエンドユーザー向けではない。基本バックエンドでの利用を想定されたもの。

• STOMPが一番MQTTに近いのでは

• 省エネ対策、QoS、Willなどはない

• 逆に言えばシンプリシティはSTOMPのほうがよい。重要なのは省エネ対策、QoS, Willが必須かどうか

Protocol比較まとめ• 同じような事が可能でも、もともと目指したところは違う。基本的に

はそのプロトコルがもともと目指したものが重要

• 分散処理 -> AMQP

• テキストチャットとプレゼンス共有 -> XMPP

• KeyValueストア -> Redis

• 商業施設や家庭内での機械のサービス自動化-> MQTT

• とはいえプロトコルはスタック、応用を考える事も重要

差異に混乱したときは原点に帰り、特徴を把握した上で応用を

MQTTを利用すべきか

• XMPPに比べるとシンプルとは言っても、MQTTはMQTTで実装上面倒な所は存在しそう。機械のための必須機能でも、他で応用するときにはその複雑性が邪魔になる可能性もある。WebSocket/Redisと独自プロトコルやあるいはSTOMPで簡単に実装できる要件で、特に省エネなどがクリティカルな話でなければ無理にMQTT使う必要はないというシーンもあるかと。

• 家電や商業施設などMQTTを使える環境が増えてきたときには実装やノウハウの使い回しがきく。そのままMQTTを実装した機械とやりとりを出来るようにするためのコストが低くなるかも。

• よい実装やサービスがそろってきて、複雑性のためのコストを過剰に払わなくてよくなり(フレームワークが複雑性を吸収してくれるとか、あるいは後で紹介するsangoのようなサービスを利用するとか)、省エネやマシンネットワークとの連動性などのメリットの方が大きいスポットであれば、適切なQoSを選択しつつ使い始めるのがよいのでは。特に省エネは重要なシーンは既に多い。

• CoAPと合わせてウォッチしておくと良さそう

ライブラリ

• http://mosquitto.org/

• http://www.eclipse.org/paho/

PerlでMQTT

• AnyEvent::MQTTというモジュールがある

• クライアントとしてのみ

• 探してみたけどサーバー実装はなさそう

• 他の言語のサーバー実装を用意しにくい場合は、sangoで試すといいかも

sangoでの利用例

8月29日から使えるようにhttps://sango.shiguredo.jp/

sangoでの利用例

登録するとこんな感じになるので 接続情報を使ってAnyEvent::MQTTから使ってみる

sangoでの利用例

subscriberを書いて起動しつつ

sangoでの利用例

publisher側も書いて実行

sangoでの利用例

HOGEHOGEというメッセージが ちゃんと届きました

Bluetooth LE

Bluetooth Classic

• 旧来のよく知られているBluetooth

• LEとの差別化のためにClassicと呼ばれる

• 2000年くらいから流行

• ユビキタスネットワーク -> 最近でいうところのIoT

• 高速化を追求

• 他の無線技術とあまり差別化できなくなってきていた

Bluetooth Low Energy (BTLE)

• LE = Low Energy (省エネ)

• Bluetooth 4.0から

• それまで(Bluetooth Classic)は高速化を追求

• 別物と考えるくらいで

• 4.0=LEではなく、4.0の中にLEの他にHS(HightSpeed)なども

Paring• 旧来のBluetoothでは基本的にデバイスのペアリング必要。2.1以上ではSecure Simple Paring

• Just Works

• Out of Band (NFCとか)

• Passkey Entry

• Numeric Comparison

• iBeaconなどに見られるようにLEではペアリングの無いユースケースがほとんど

• LEも似たようなモデルがあり、PassKeyEntryも一応存在するし、逆に、上に上げたように、ClassicにもJust Worksがあり、確認なしで使える仕様も存在はする。

• とはいえ、LE用のSDK/チップではJust Worksしか採用されてなかったりする

Bluetoothのネットワークトポロジピコネット

ClassicではMaster/Slaveという言い方をして、 Central/Peripheralとは言わない

Central

Peripheral

例: PC

例: キーボード マウス

Peripheral

例: 室温系

Peripheral

例: 体重系

ペリフェラルがサービスの主体になるデータを提供するケース (ペリフェラルがサーバー、セントラルがクライアント)

が多い

複数のデバイスとやりとりする中心になるのがセントラル

ペリフェラルにデータをWriteするケースもある　 サーモスタットの温度とか(設定系)

Bluetoothのネットワークトポロジスキャタネット

MasterSlave

例: PC

例: キーボード マウス

Slave

例: 室温系

Slave

例: 体重系Master

例: ヘッドホン

Slave

ヘッドホンなどは主体となるデータ(音声データ)の置き場はPC側になり、データの流れが逆になる

Masterは同時にSlaveとなり、他のピコネットに参加することができるClassicのみ。LEではペリフェラルは同時にセントラルとなることは出来ない

ネットワークへの参加

• Classic: Service Discoveryの仕様(今回は省略)

• LE: Advertising

Advertising Packet• サービスのUUID • LocalName • その他

ネットワークへの参加

Observer Broadcaster(Peripheral)(Central)

ペリフェラルは周期的にアドバタイジングパケットを発信 「こんなサービスを提供していますよ」という情報

Advertising Packet• サービスのUUID • LocalName • その他

ネットワークへの参加

Observer Broadcaster(Peripheral)(Central)

セントラルは周期的にスキャンを行い、 周囲からアドバタイジングパケットを探す。

Scan Request

ネットワークへの参加

Observer Broadcaster(Peripheral)(Central)

必要であれば、もう少し詳しい情報を相手に要求できる

Scan Response

ネットワークへの参加

Observer Broadcaster(Peripheral)(Central)

ペリフェラルは、Scan Requestを受け取った場合はScan Responseを返す。 アドバタイジングパケットに乗り切らない情報をここに載せることが出来る 最初のアドバタイジングパケットが大きすぎると省エネ的にも良くない。

Advertising Packet• サービスのUUID • LocalName • その他

接続要求

ネットワークへの参加

Central Peripheral

セントラルは受け取った情報から UUIDなどを見て、つなぎたいサービスかどうか判断。 !サービスを受けたい場合は接続要求を ペリフェラルに投げて接続を開始

接続が完了するとBroadcaster/Observerとしての役目は終わり、 Peripheral/Centralとなる

ポーリング

CentralとPeripheralのやりとり

Central Peripheral

接続が完了するとセントラルは定期的に、空パケットで ポーリングを行い接続を維持する。要はPing。

必要だったらポーリングのレスポンスにデータを載せたり。

CentralとPeripheralのやりとり

Central Peripheral

周波数チャンネル

混線によるノイズを避けるために 周波数ホッピングを行い、 チャンネルを切り替えながら通信する

ClassicでもLEでも周波数ホッピングは あるが、LEではホッピングの回数が 少なくなるよう工夫されている。

CentralとPeripheralのやりとり

Central Peripheral

前述のような接続維持を行いつつ、 セントラルは、接続先のペリフェラルが提供しているサービスを利用できる

サービス

Profile

Host

Controller

Profiles (Application)

HCI - Host Controller Interface

物理層

あらかじめ用意された アプリケーション仕様(Profile)

!ヘッドセット、キーボードなどの入力、オーディオなど

Bluetoothでの利用されるような機能は Profile仕様が最初から用意されている

• HSP(HeadSetProfile) • HIDP(HumanInterfaceDeviceProfile) • …

Profile

Host

あらかじめ用意されたものでなくて、自由にサービスを設計したいときは？

Classicの場合はSPP(Serial Port Profile)

LEの場合はGATT(General Attribute Profile)

GATT

Central

Peripheral

サービス

Peripheralが提供するサービスとはどんなもの？

室温計の例

現在の室温: 28度

READ

センサーから取得できる変動値サービスが提供する値を 読み取ることができる

GATT

Central

Peripheral

サービス

Peripheralが提供するサービスとはどんなもの？

サーモスタットの例

設定温度: 28度

WRITE

機械の内部のconfig値

スイッチ: offコントロールポイント

一つのサービスは 複数の値をもてる

サービスが提供する値に 書き込むことができる

GATT

Peripheral

サービス

設定温度: 28度機械の内部のconfig値

スイッチ: offコントロールポイント

characteristic

characteristic

Centralから読み書きさせることが出来る これらの値のことをcharacteristicと呼ぶ

一つのサービスは複数のcharacteristicを持てる

読み書き以外に、値が変化したときの通知依頼も

GATT

Peripheral

サービス

設定温度: 28度機械の内部のconfig値

スイッチ: offコントロールポイント

一つのPeripheralは複数のサービスを持つことが出来る

サービス

現在の室温: 28度センサーから取得できる変動値

Bluetooth LEのサービス利用手順まとめ

• Peripheralとして振る舞うデバイスがアドバタイズ

• Centralとして振る舞うデバイスがスキャンしてアドバタイジングパケットを発見

• CentralやPeripheralに接続して、目的のサービスを検索

• サービスの中から目的のCharacteristicを発見し、読み書き等

iOS/Androidでのsupport状況

• iOSは5.0からBTLEがSDK(CoreBluetooth)に、まずはセントラルのみ。6以降でペリフェラルとしても動作可能。なのでほぼ普及済と考えられる。

• Androidは4.3からBTLE(セントラル)搭載。Preview Lからペリフェラルとしても動作可能。Preview Lからはle用にパッケージが別になったので、4.3のときに使えたセントラル用のAPIも刷新されてる。

iOS/AndroidでのBluetooth Classic

• LEサポート前からClassicのほうは利用できた

• LEのようにGATTがないので、既存のプロファイルにない自由なサービスを使おうとするとSPP(serial port profile)を使う必要がある

• iOSではAppleからMFi (Made for iPhone)を取得する必要

iOS/Androidでのsupport状況

iOSではLEが簡単でClassic&SPPがMFiのため面倒 AndroidではSPPは簡単、LEは普及に時間かかりそう

iOSとAndroidで通信したい場合は悩ましい

iBeacon

• CoreLocation

• 屋内位置情報

• Ranging/Monitoring

位置情報サービス

GPS

iBeacon

比較的大きな領域での位置や移動 地図と組み合わせたサービス屋内での細かい位置情報や短距離移動

などに基づくサービス

iBeacon

Advertising Packet• サービスのUUID • LocalName • その他

Broadcaster(Peripheral)Broadcasterとしてのみ

振る舞うBTLEデバイス

パケットの送信距離が10m程度なのを利用して データ転送よりも近接検知に利用

用語の注意

• iBeaconが近接検知技術と言われるが

• NFCなどのスマートカード界隈では近接(proximity)は10cm以内、70cm以内だと近傍(vicinity)とか

iBeaconの近接 = BTLEのパケット送信可能距離

ICカードの近接 = カード/リーダで電磁誘導が発生する距離

iBeacon

Advertising Packet

ビーコン

Advertising Packet

電波が届く距離までビーコンに近寄ったことがわかる 電波強度(RSSI)からアバウトに距離の推測 ノイズの問題もあり正確には分からない。ビーコンの方位もわからない。

iBeacon

ビーコン

Advertising Packet

ビーコンが飛ばすパケットにはUUIDと二つの16bit整数値(major/minor)がある

UUIDを指定して監視しておいて、対応するアプリでアクションを実行したり、 PassKitでクーポンを表示したり。

UUIDmajor/minor

iBeacon

ビーコンA

二つの数値を利用して、どのビーコンに近接したかの判断

施設内での移動の検知

ビーコンB

Advertising Packet

UUIDmajor: 1 minor: 1

Advertising Packet

UUIDmajor: 1 minor: 2

iBeaconでのBTLEまとめ

• Bluetooth LE の Broadcasterである

• Peripheral/Central間で接続確立&データ転送はしない

• Advertising Packetの中に収まるデータしか使えない

•major/minorという16bit整数値二つ入れる

Bluetooth LEの利用の仕方自体はものすごくシンプル

iBeacon以外での BTLE(と他の技術の組み合わせによる)活用の

可能性と課題

High Contextな情報の取得&操作の エントリポイントとしてのBTLEデバイス

• ポケットからスマホを出し

• 店の名前などで検索する

歩いていたら気になった店があった

High Contextな情報の取得&操作の エントリポイントとしてのBTLEデバイス

歩いていたら気になった店があった

• 近寄ったときに店頭のデバイスからBTLE経由で情報取得済

• 気になったときにウェアラブルデバイスなどですぐ確認SEARCHless

ポケットからデバイスを出さなくもいいさらに大きい画面で詳細が見たくなるまでは

情報消費スタイル

2000年以前 BROADCAST

2000年 PULL

2010年 PUSH

テレビ、ラジオ、雑誌、みんなに届ける。消費者はチャンネル選択。

見たいものを見たいときに見る。Searchがキラーアプリケーション。

自分に関係する情報、自分が欲しい情報のアップデートが即座に手元に届く 自分だけでなく友人の情報も(Social)

情報消費スタイル

201X年 PICK今必要な情報はまわりに落ちている

ウェアラブルデバイスとの連動

Cloud

ウェアラブルによく見られるデータの流れ: 二つの方向

Cloudから(リモート通知)

体の中から(健康情報)

ウェアラブルデバイスとの連動

Cloud

現在欠けている三つ目の方向があるのでは

ウェアラブルデバイスとの連動

CloudHighContextな

情報に満たされた世界からの 情報取得=PICK

Machine Automation

Semantic Real World

MQTTなどで自動化された マシンネットワークへの介入操作

ここで主要な役割を果たすのが BTLEやNFC

ウェアラブルデバイスとの連動

現在だと、GoogleGlassでカメラを利用した 一部のアプリなどが該当するぐらい?

HighContextな 情報に満たされた世界からの

情報取得=PICK

Machine Automation

Semantic Real World

MQTTなどで自動化された マシンネットワークへの介入操作

エコシステムやインフラがまだ整ってない

ウェアラブルデバイスは インターネット普及前のパソコンのように

本領発揮できていないかも

このような将来のネットワークを考えてみると、実はiBeaconは、近接検知によるクーポン送信装置にとどまるものではなく、次世代のHTTP GET的な非常に重要なポジションを取りにきてるのかも

Personalization

　Webが単純なホームページから、 PersonalizeされたWebサービスへと

発展していったように

Security & Privacyの考慮もより必要になってくる

近接検知によって出すクーポンを ユーザーごとに変えたいとか

単純なデータの取得の次は パーソナライズが要求されはじめることが予測される

Personalization (例1)

ビーコンAdvertising Packet

UUIDmajor/minor

WebService B

ユーザーAの WebService Bでの アカウント情報

ビーコンに近づくと、そのUUIDに該当するアプリが起動 あらかじめ登録されていたURLにアクセス あるいはmajor/minor値を使いアクセス先のURLを変える

Personalization (例1)

ビーコンAdvertising Packet

UUIDmajor/minor

WebService B

ユーザーAの WebService Bでの アカウント情報

その際に、あらかじめスマホに保存された アカウント情報やOAuthのtokenなどで認証を行う。

アカウント情報

Personalization (例1)

ビーコンAdvertising Packet

UUIDmajor/minor

WebService B

ユーザーAの WebService Bでの アカウント情報

サーバーは認証によって特定したユーザーのために パーソナライズされたコンテンツ(クーポン等)を配信

パーソナライズされた コンテンツ

Personalization (例2)

Peripheral

Advertising Packet

ユーザーAの WebService Bでの アカウント情報

ビーコン(Broadcaster)ではなく、 PeripheralとCentralとして接続を確立し HTTPのRequest/Responseのようなやりとりを行う

1: 認証情報用のcharacteristicにwrite

3: このユーザ用のコンテンツが準備できたらnotify

4: コンテンツのcharacteristicをread

Web Service

ペリフェラルデバイスは裏でWebサービスと通信を行い Proxyのように振る舞う

2: writeされた認証情報を使って 裏でデータ取得

POSTの例

• ポケットからスマホを出し

• チェックインアプリを起動

• お店を検索

• 選択してからチェックイン

今食事しているお店でチェックインしたい

現在の行動フロー

これももっと改善できるのでは

Postの例 (1)

ビーコンAdvertising Packet

UUIDmajor/minor

WebService B

ユーザーAの WebService Bでの アカウント情報

ビーコンに近づくと、そのUUIDに該当するチェックインアプリが起動 あらかじめ登録された該当URLにPOSTを開始する あるいはmajor/minor値によってURLを変える

店情報など

Postの例 (1)

ビーコンAdvertising Packet

UUIDmajor/minor

WebService B

ユーザーAの WebService Bでの アカウント情報 店情報など

近接だけで勝手にポストするのは プライバシー上問題となるケースが多いと予想される。

ユーザーがトリガーを押す画面が必要に。 Wearableで操作できれば便利

チェックイン ボタン

Postの例 (1)

ビーコンAdvertising Packet

UUIDmajor/minor

WebService B

ユーザーAの WebService Bでの アカウント情報

チェックインボタンが押されたら、 デバイスに保存されていたアカウント情報と アドバタイジングパケットより取得したshop_idなどの 店情報を使ってWebService Bにポスト major/minor値をそのままshop_idにするのもあり

店情報など

アカウント 情報

shop_id

Postの例 (例2)

PeripheralAdvertising Packet

ユーザーAの WebService Bでの アカウント情報

1: 認証情報用のcharacteristicにwrite

Web Service

アカウント情報以外の投稿用パラメータはペリフェラル側でプリセットされていて ユーザーがわざわざ入力する必要はない

2: writeされた認証情報と プリセットされたパラメータをあわせて

ポスト

店情報preset parameters

POSTの例あらかじめスマホ上にあるアカウントなどの認証情報と、

ビーコンなどのデバイスが持つプリセットされたパラメータにより、 ユーザーのアクションのコストを削減

ただしPrivacy&Securityはよく考慮する必要がある。 GET(PUSH)でも大事だが、POSTは特に。

近接からの自動化じゃなくて、ユーザーにトリガーを預けるケースが多くなるのでは

とはいえ、Paypal Hereの顔パス認証のような オフラインならではのものも出てきている

という感じで、 食事していたら、店の情報が時計に表示されてる。 あとはチェックインボタンを押すだけ、というような

エクスペリエンスの提供が可能になるかも

POSTの例

どういう形でユーザーにトリガーを引いてもらうか

wearable上で画面を見せてアクションボタン

あるいはNFCでタッチ

目の前で本人が自分のデバイスでタッチするということが あるレベルの認証といえる(BTLEがあればNFCいらないということはない) ただし、クレジットカードと同じように 他人のデバイスを使うなどの悪用は考えられる。 あとBTLE間で転送されるデータの偽造の可能性なども考慮

まとめ

• BTLEは応用の余地がまだたくさんありそう

• MQTTはメリットとデメリットちゃんと把握した上でなら既に使える技術、今後も面白い用途が出てきそう

• BTLE/MQTT/Wearableなどそれぞれの技術の相互作用による進化を考えると面白そう

ご清聴 ありがとうございました