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

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

on

  • 669 views

IoT関連の話題で登場するMQTTの概要や混乱しがちなポイント、O2O関連の話題で登場するBluetooth ...

IoT関連の話題で登場するMQTTの概要や混乱しがちなポイント、O2O関連の話題で登場するBluetooth LEの概要、iBeaconでどう利用されているか、今後どう応用される可能性があるか等について、YAPC::Asia2014で発表を行った際の資料になります。

Statistics

Views

Total Views
669
Views on SlideShare
309
Embed Views
360

Actions

Likes
4
Downloads
3
Comments
0

6 Embeds 360

http://atl.recruit-tech.co.jp 304
http://cptl.corp.yahoo.co.jp 36
https://twitter.com 9
https://bozuman.cybozu.com 8
http://s.deeeki.com 2
http://feedly.com 2

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

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

  • 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の例 Twitter IFTTT RSSを定期的にチェックして、 更新情報があれば 天気 予報 instagr am Dropbox 更新情報
  • EventHub系ツール/サービス RSS Gmail Evernote IFTTTの例 Twitter IFTTT Gmailに送信するとか 天気 予報 instagr am Dropbox 更新情報
  • EventHub系ツール/サービス RSS Gmail Evernote IFTTTの例 Twitter IFTTT instagramに新しい写真がアップされたら 天気 予報 instagr am Dropbox 写真
  • EventHub系ツール/サービス RSS Gmail Evernote IFTTTの例 Twitter IFTTT Dropboxに保存するとか 天気 予報 instagr am Dropbox 写真
  • PubSub 監視 カメラ照明 エアコン MQTTの例 MQTT Broker 1. Subscribe 特定のイベントの監視 照明&エアコン -> Broker「誰かが入室したら教えてね」
  • PubSub 監視 カメラ照明 エアコン MQTTの例 MQTT Broker event: 入室 data: Aさん 2. Publish 特定のイベントの通達　 監視カメラ -> Broker「Aさんが入室したよ」
  • PubSub 監視 カメラ照明 エアコン MQTTの例 MQTT Broker event: 入室 data: Aさん event: 入室 data: Aさん 3. SubscriberへのDispatch　 Broker 「入室イベントを待ってたのは照明とエアコンだったよな…」 Broker -> 照明&エアコン「Aさんが入室したよ」
  • PubSub Action 監視 カメラ照明 エアコン MQTTの例 MQTT Broker event: 入室 data: Aさん event: 入室 data: Aさん 4. Eventに対応したアクション　 照明「人が入ってきたので明るくしよう」 Action エアコン「人が入ってきたので室温を調整しよう。Aさんの場合は27度」
  • 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/ibm finance/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 0 - At most one クライアントがメッセージをPUBLISHすると Publisher MQTT Broker Subscriber
  • QoS 0 - At most one Publisher MQTT Broker Subscriber そのメッセージをSubscriberに配信 特殊なことはしない
  • QoS 1 - At least one クライアントがメッセージを保存してからPUBLISH message idを使って管理 Publisher MQTT Broker Subscriber Storage
  • QoS 1 - At least one サーバーもメッセージを保存しつつSubscriberに配信 Publisher MQTT Broker Subscriber Storage Storage
  • QoS 1 - At least one 配信が出来たら、サーバーはメッセージを消して、PUBLISH元のPUBACKを送信 Publisher MQTT Broker Subscriber Storage Storage PUBACK
  • QoS 1 - At least one PUBACKを確認できたら、　PUBLISHERは保存していたメッセージを消す Publisher MQTT Broker Subscriber Storage Storage
  • QoS 1 - At least one 一定時間たってもPUBACKがこなければ、再びPUBLISH Publisher MQTT Broker Subscriber Storage Storage 確実に届くまでPUBLISH。 Subscriberが受け取るメッセージに重複の可能性はある。
  • QoS 2 - Exactly Once クライアントがメッセージを保存してからPUBLISH message idを使って管理 Publisher MQTT Broker Subscriber Storage
  • QoS 2 - Exactly once サーバーもメッセージを保存しつつSubscriberに配信 Publisher MQTT Broker Subscriber Storage Storage PUBREC 実際は二種類の手法があるが省略
  • QoS 2 - Exactly once Subscriberはメッセージを受け取るとPUBRECを返す Publisher MQTT Broker Subscriber Storage Storage PUBREL
  • QoS 2 - Exactly once サーバーはPUBRECを確認してからメッセージを削除、PUBLISHERにPUBCOMP送信 Publisher MQTT Broker Subscriber Storage Storage PUBCOMP
  • QoS 2 - Exactly once PUBLISHERはPUBCOMP確認してから、メッセージを削除 Publisher MQTT Broker Subscriber Storage Storage
  • Will • セマンティックなLeave Message。遺書。 • コネクションのロスト自体をSubscribe可能なイベントとする • WillなしでもTimeout/Pingなどと合わせ切断検知自体は出来る。
  • MQTT-SN • SN = Sensor Network • LAN内の全てのノードがサーバーに直接接続する必要はない • Gatewayの利用 • センサー系の小型無線デバイスのためにさらに省エネな仕様
  • MQTT-SN MQTT 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 チャットサービスの例 HTTP Response Client(User A) Server このタイミングで初めて そのメッセージをのせてHTTPレスポンスを返す あるいはタイムアウトで、空レスポンスを返す　 User Aへの メッセージ
  • 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 Apple/Google Server 通知用トークンを発行してもらい取得 TOKEN Client(User A) Apple: Device Token Google: Registration ID
  • APNS/GCM & HTTP GET Apple/Google Server Client(User A) UserA:TOKEN 取得したトークンをサーバー上に保存
  • APNS/GCM & HTTP GET Apple/Google Server Client(User A) User Aへの メッセージ UserA:TOKEN ユーザーAへのメッセージが届いたら
  • APNS/GCM & HTTP GET TOKEN Apple/Google Server Client(User A) User Aへの 通知メッセージ 該当ユーザーのトークンを使って、 iTunes Connect/Google PlayのPUSHサービスに通知
  • APNS/GCM & HTTP GET Apple/Google Server Client(User A) 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 Apple/Google Server HTTP Response 更新情報があれば取得 User Aへの メッセージ Client(User A)
  • APNS/GCM & HTTP GET コストをかけて今までのStatelessなHTTPとは違う アーキテクチャのサービスを用意しなくても ある程度ならリアルタイム性を実現できてしまう
  • HTTPによるM2Mネットワーク
  • HTTPによるM2Mネットワーク この分野でのMQTTの出現に至る経緯を追う M2M(machine to machine)のネットワークを HTTP(REST)でやっていこうという議論 室温計 エアコン HTTP GETで室温を取得 Client HTTP PUTで温度設定
  • HTTPによるM2Mネットワーク • AtompubのようなRESTfulアーキテクチャ • ETag, If-Modified-Sinceなどを使ったキャッシングやトランザクショ ン管理 HTTP GETで室温を取得 HTTP GETで室温を取得 Proxy If-Modified-Since 室温計Client 取得した結果をキャッシュ リアルタイムでデータの変更通知が必要な場合は Long Pollingとかmultipart/x-mixed-replaceとか
  • テキストベースのHTTPは 省エネが要求されるM2Mにおいては厳しいし RESTful HTTPだけでは解決しない問題もある 別のプロトコルの提案 クラサバPubSubモデルへ HTTPをベースに マシンネットワーク向け最適化 MQTT CoAP こういった経緯があり、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 Signaling Channel Signaling Channel Peer A Peer B
  • VoIPの例 音声や動画通信をP2Pで始めたい(サーバー経由はコスト高い) Signaling Server Signaling Channel Signaling Channel RTP Peer A Peer B Data Channel(Audio, Video)
  • VoIPの例 現実はNATが存在し、簡単にはP2P通信を実現できない Signaling Server RTP PeerBのTransport Addressが PeerAのTransport Addressが 取得できない NATs NATs 取得できない Peer A Peer B
  • ICE Interactive Connectivity Establishment
  • Hole Punching NATに穴をあける必要がある NATs ローカルホストはNATを通して、 Local Host 外のネットワーク上にあるサービスにアクセス
  • Hole Punching NATs Local Host 10.100.100.100:10002 192.168.0.1:10001 NATはトランスポートアドレスをアロケートして、 ローカルホストとのマッピングを行う
  • Hole Punching NATs Local Host 10.100.100.100:10002 192.168.0.1:10001 このグローバルアドレスに パケットが来た場合
  • Hole Punching NATs Local Host 10.100.100.100:10002 192.168.0.1:10001 マップされたローカルホストに パケットを送信
  • Hole Punching ! Transport Address(IP&Port)をどうチェックに使うか パケットを送ってきた相手に対して、こちらから送信したことがあるか などのチェックの仕方など ルータによって振舞が変わる 必ずしもうまくはいかない
  • STUN STUN Server NATs STUN Client 外から見て自分のアドレスがどうなっているかを 確認するためのもの ! STUNサーバーはリクエストを受け取ると 自分から見える相手のアドレスを返すだけ、という 非常にシンプルな機能のサーバー Server Reflexive Transport Address Host Transport Address
  • ICE STUNサーバーを利用し、外から見える自分のアドレスを取得 Signaling Server NATs NATs STUN Server Peer A Peer B
  • ICE 外から見えるアドレスやローカルのアドレスなど候補を集めて シグナリングチャンネルを通して相手と交換 Signaling Server PeerBと通信するための アドレス候補のリストPeerAと通信するための アドレス候補のリスト NATs NATs Peer A Peer B
  • ICE 取得した候補アドレスのペアを優先順位に従って順にチェック 通信できるアドレスのペアを探す お互いがSTUN Server/Clientとなり、 相手にリクエストを投げる 4-way handshake PeerBと通信するための アドレス候補のリストPeerAと通信するための アドレス候補のリスト NATs NATs Peer A Peer B
  • ICE どうしてもつながらない場合もある PeerBと通信するための アドレス候補のリストPeerAと通信するための アドレス候補のリスト NATs NATs Peer A Peer B
  • TURN STUNの上にのってるリレーサーバー用のプロトコル TURNでのチャンネルも準備して候補アドレスに含め、交換しておく TURN Server NATs TURN Client Remote Peer 相手と通信するためのアドレスをマップして チャンネルのバインドを行っておく Channel Binding NATs 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 TODO: need peer reflexive address?
  • ICE リレーサーバーを最後の手段として、そこを通して音声や動画を送信 Signaling Server TURN Server NATs NATs Peer A Peer B
  • 興味のある人は、 より詳しくは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 Messages Queue Client Worker
  • JobQueueの例 Worker Worker ひとつずつ順番にジョブを処理していく。 一つのジョブはどれか一つのワーカーによって処理される。 Client Worker
  • JobQueue以外でも Subscriber Subscriber 一つのメッセージがワーカー全員にコピーされて 配られることもある。Fanout(Broadcast) 他にもいろいろ分散処理のための機能 Publisher Subscriber
  • 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 Queue 1 Binding 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のネットワークトポロジ スキャタネット ヘッドホンなどは主体となるデータ(音声データ)の置き場はPC側になり、データの流れが逆になる Master Slave 例: PC 例: キーボード マウス Slave 例: 室温系 Slave 例: 体重系 Master 例: ヘッドホン Slave Masterは同時にSlaveとなり、他のピコネットに参加することができる Classicのみ。LEではペリフェラルは同時にセントラルとなることは出来ない
  • ネットワークへの参加 • Classic: Service Discoveryの仕様(今回は省略) • LE: Advertising
  • ネットワークへの参加 Advertising Packet • サービスのUUID • LocalName • その他 Observer Broadcaster (Central) (Peripheral) ペリフェラルは周期的にアドバタイジングパケットを発信 「こんなサービスを提供していますよ」という情報
  • ネットワークへの参加 Advertising Packet • サービスのUUID • LocalName • その他 Observer Broadcaster (Central) (Peripheral) セントラルは周期的にスキャンを行い、 周囲からアドバタイジングパケットを探す。
  • ネットワークへの参加 必要であれば、もう少し詳しい情報を相手に要求できる Observer Broadcaster Scan Request (Central) (Peripheral)
  • ネットワークへの参加 ペリフェラルは、Scan Requestを受け取った場合はScan Responseを返す。 アドバタイジングパケットに乗り切らない情報をここに載せることが出来る 最初のアドバタイジングパケットが大きすぎると省エネ的にも良くない。 Observer Broadcaster Scan Response (Central) (Peripheral)
  • Advertising Packet • サービスのUUID • LocalName • その他 ネットワークへの参加 セントラルは受け取った情報から UUIDなどを見て、つなぎたいサービスかどうか判断。 ! サービスを受けたい場合は接続要求を ペリフェラルに投げて接続を開始 接続要求 Central Peripheral 接続が完了するとBroadcaster/Observerとしての役目は終わり、 Peripheral/Centralとなる
  • CentralとPeripheralのやりとり 接続が完了するとセントラルは定期的に、空パケットで ポーリングを行い接続を維持する。要はPing。 必要だったらポーリングのレスポンスにデータを載せたり。 ポーリング Central Peripheral
  • CentralとPeripheralのやりとり 周波数チャンネル 混線によるノイズを避けるために 周波数ホッピングを行い、 チャンネルを切り替えながら通信する Central Peripheral ClassicでもLEでも周波数ホッピングは あるが、LEではホッピングの回数が 少なくなるよう工夫されている。
  • CentralとPeripheralのやりとり 前述のような接続維持を行いつつ、 セントラルは、接続先のペリフェラルが提供しているサービスを利用できる Central Peripheral サービス
  • Profile Profiles (Application) Host HCI - Host Controller Interface Controller 物理層 • HSP(HeadSetProfile) • HIDP(HumanInterfaceDeviceProfile) • … あらかじめ用意された アプリケーション仕様(Profile) ! ヘッドセット、キーボードなどの入力、オーディオなど Bluetoothでの利用されるような機能は Profile仕様が最初から用意されている
  • 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 コントロールポイント Centralから読み書きさせることが出来る これらの値のことをcharacteristicと呼ぶ 読み書き以外に、値が変化したときの通知依頼も 一つのサービスは複数のcharacteristicを持てる characteristic characteristic
  • GATT 一つのPeripheralは複数のサービスを持つことが出来る Peripheral サービス 設定温度: 28度 機械の内部のconfig値 スイッチ: off コントロールポイント サービス 現在の室温: 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 Broadcasterとしてのみ (Peripheral) 振る舞うBTLEデバイス パケットの送信距離が10m程度なのを利用して データ転送よりも近接検知に利用
  • 用語の注意 • iBeaconが近接検知技術と言われるが • NFCなどのスマートカード界隈では近接(proximity)は10cm以内、 70cm以内だと近傍(vicinity)とか iBeaconの近接 = BTLEのパケット送信可能距離 ICカードの近接 = カード/リーダで電磁誘導が発生する距離
  • iBeacon Advertising Packet ビーコン Advertising Packet 電波が届く距離までビーコンに近寄ったことがわかる 電波強度(RSSI)からアバウトに距離の推測 ノイズの問題もあり正確には分からない。ビーコンの方位もわからない。
  • iBeacon ビーコン Advertising Packet UUID major/minor ビーコンが飛ばすパケットにはUUIDと二つの16bit整数値(major/minor)がある UUIDを指定して監視しておいて、対応するアプリでアクションを実行したり、 PassKitでクーポンを表示したり。
  • iBeacon ビーコンA ビーコンB 二つの数値を利用して、どのビーコンに近接したかの判断 施設内での移動の検知 Advertising Packet UUID major: 1 minor: 1 Advertising Packet UUID major: 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 見たいものを見たいときに見る。Searchがキラーアプリケーション。 2010年 PUSH 自分に関係する情報、自分が欲しい情報のアップデートが即座に手元に届く 自分だけでなく友人の情報も(Social)
  • 情報消費スタイル 201X年 PICK 今必要な情報はまわりに落ちている
  • ウェアラブルデバイスとの連動 ウェアラブルによく見られるデータの流れ: 二つの方向 Cloud Cloudから(リモート通知) 体の中から(健康情報)
  • ウェアラブルデバイスとの連動 現在欠けている三つ目の方向があるのでは Cloud
  • ウェアラブルデバイスとの連動 Cloud Semantic Real World HighContextな 情報に満たされた世界からの 情報取得=PICK Machine Automation MQTTなどで自動化された マシンネットワークへの介入操作 ここで主要な役割を果たすのが BTLEやNFC
  • ウェアラブルデバイスとの連動 現在だと、GoogleGlassでカメラを利用した 一部のアプリなどが該当するぐらい? Semantic Real World HighContextな 情報に満たされた世界からの 情報取得=PICK Machine Automation MQTTなどで自動化された マシンネットワークへの介入操作 エコシステムやインフラがまだ整ってない ウェアラブルデバイスは インターネット普及前のパソコンのように 本領発揮できていないかも
  • このような将来のネットワークを考えてみると、実はiBeaconは、 近接検知によるクーポン送信装置にとどまるものではなく、次 世代のHTTP GET的な非常に重要なポジションを取りにきてる のかも
  • Personalization 　Webが単純なホームページから、 PersonalizeされたWebサービスへと 発展していったように 単純なデータの取得の次は パーソナライズが要求されはじめることが予測される 近接検知によって出すクーポンを ユーザーごとに変えたいとか Security & Privacyの考慮もより必要になってくる
  • Personalization (例1) ビーコン Advertising Packet UUID major/minor WebService B ユーザーAの WebService Bでの アカウント情報 ビーコンに近づくと、そのUUIDに該当するアプリが起動 あらかじめ登録されていたURLにアクセス あるいはmajor/minor値を使いアクセス先のURLを変える
  • Personalization (例1) ビーコン Advertising Packet UUID major/minor WebService B ユーザーAの WebService Bでの アカウント情報 その際に、あらかじめスマホに保存された アカウント情報やOAuthのtokenなどで認証を行う。 アカウント情報
  • Personalization (例1) ビーコン Advertising Packet UUID major/minor WebService B ユーザーAの WebService Bでの アカウント情報 サーバーは認証によって特定したユーザーのために パーソナライズされたコンテンツ(クーポン等)を配信 パーソナライズされた コンテンツ
  • Personalization (例2) Peripheral ビーコン(Broadcaster)ではなく、 PeripheralとCentralとして接続を確立し HTTPのRequest/Responseのようなやりとりを行う Advertising Packet ユーザーAの WebService Bでの アカウント情報 1: 認証情報用のcharacteristicにwrite 3: このユーザ用のコンテンツが準備できたらnotify 4: コンテンツのcharacteristicをread Web Service ペリフェラルデバイスは裏でWebサービスと通信を行い Proxyのように振る舞う2: writeされた認証情報を使って 裏でデータ取得
  • POSTの例 今食事しているお店でチェックインしたい 現在の行動フロー • ポケットからスマホを出し • チェックインアプリを起動 • お店を検索 • 選択してからチェックイン これももっと改善できるのでは
  • Postの例 (1) ビーコン Advertising Packet UUID major/minor WebService B ユーザーAの WebService Bでの アカウント情報 ビーコンに近づくと、そのUUIDに該当するチェックインアプリが起動 あらかじめ登録された該当URLにPOSTを開始する あるいはmajor/minor値によってURLを変える 店情報など
  • Postの例 (1) プライバシー上問題となるケースが多いと予想される。 ビーコン 近接だけで勝手にポストするのは ユーザーがトリガーを押す画面が必要に。 Wearableで操作できれば便利 Advertising Packet UUID major/minor WebService B チェックイン ボタン ユーザーAの WebService Bでの アカウント情報店情報など
  • Postの例 (1) ビーコン Advertising Packet UUID major/minor WebService B ユーザーAの WebService Bでの アカウント情報 チェックインボタンが押されたら、 デバイスに保存されていたアカウント情報と アドバタイジングパケットより取得したshop_idなどの 店情報を使ってWebService Bにポスト major/minor値をそのままshop_idにするのもあり 店情報など アカウント 情報 shop_id
  • Postの例 (例2) Peripheral Advertising 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などそれぞれの技術の相互作用によ る進化を考えると面白そう
  • ご清聴 ありがとうございました