Upload
recruit-technologies
View
10.654
Download
6
Embed Size (px)
DESCRIPTION
IoT関連の話題で登場するMQTTの概要や混乱しがちなポイント、O2O関連の話題で登場するBluetooth LEの概要、iBeaconでどう利用されているか、今後どう応用される可能性があるか等について、YAPC::Asia2014で発表を行った際の資料になります。 (9/2追記) QoSフロー図に一部誤りがあるのでは、というご指摘を受けたので、該当箇所を一旦削りました。
Citation preview
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を定期的にチェックして、 更新情報があれば
天気 予報
Dropbox更新情報
EventHub系ツール/サービス
RSS Gmail
Evernote
IFTTTの例
IFTTTTwitter
Gmailに送信するとか
天気 予報
Dropbox
更新情報
EventHub系ツール/サービス
RSS Gmail
Evernote
IFTTTの例
IFTTTTwitter
instagramに新しい写真がアップされたら
天気 予報
Dropbox
写真
EventHub系ツール/サービス
RSS Gmail
Evernote
IFTTTの例
IFTTTTwitter
Dropboxに保存するとか
天気 予報
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と合わせてウォッチしておくと良さそう
PerlでMQTT
• AnyEvent::MQTTというモジュールがある
• クライアントとしてのみ
• 探してみたけどサーバー実装はなさそう
• 他の言語のサーバー実装を用意しにくい場合は、sangoで試すといいかも
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などそれぞれの技術の相互作用による進化を考えると面白そう
ご清聴 ありがとうございました