通信イメージ

MQTTとは

MQTT(Message Queue Telemetry Transport)は、1999年にIBM社とEurotech社のメンバーにより考案されたプロトコルです。2014年にはOASISによって正式な標準規格とされました。

このプロトコルの特長は、HTTPと比べ軽量、低消費電力、非同期な双方向通信を可能にしていることです。

ネットワークに接続されたモノ同士で通信するM2M(Machine-to-Machine)や、モノがインターネットと繋がって通信するIoT(Internet of Things)にも適しています。

出典:MQTT.org「MQTT」

MQTTのプロトコルをRTOSで活用してみる

弊社のプロトコルスタックμNet3に含まれるMQTT クライアントのサンプルプログラムの一部を変更して、 AWS IoT へ接続するための手順と変更前後のサンプルプログラムソースを無料で公開しています。

MQTTの通信構成

通信イメージ

publish/subscribe型モデル

MQTTはpublish/subscribe型のメッセージングモデルを採用しています。

publish/subscribモデルでは、メッセージの送信側をpublisher(パブリッシャー)、メッセージの受信側をsubscriber(サブスクライバー)と呼び、brokerと呼ばれるMQTTサーバーが間に入ってメッセージを扱います。publisherとsubscriberは直接繋がらないのが特長です。

この通信では、クライアント(publisher/subscriber)はEメールのようなアドレスを持ちません。メッセージはクライアントに直接送られるわけではなく、「topic」を通じてMQTTサーバーを中継してやりとりされます。topicとは、メッセージの宛先を指定でき、「/」(スラッシュ)を使って階層構造を示したものです。

topic例(各エリアの湿度情報が欲しい場合にサーバーに登録する際の表示例)

field/tokyo/area1/humid
field/osaka/area2/humid
field/+/area1/humid (「+」の部分は、どんな文字列も対象とするワイルドカード記号)

出典:IBM「IBM Watson IoT Platform – Message Gateway 2.0.0」ワイルドカード

publish/subscribe メッセージングモデルの流れは下記です。

subscriberが、欲しいメッセージのtopicをMQTT Brokerに知らせます。そしてpublisherから情報が送信された際、MQTT brokerがtopicに基づいてメッセージを仕分け、subscriberに配信します。

また、MQTT brokerは基本的にメッセージを保有しません。よって、subscriberから欲しいメッセージの要求が無い場合、publisherから送られたメッセージはMQTT brokerから削除されます。加えて、subscriberから欲しいメッセージの要求が無いtopicのメッセージもMQTT brokerから削除されます。

別の特長として、publisherとsubscriberは立場を入れ替えることも可能です。publisherはsubscriberに、subscriberはpublisherになることができます。

出典:Steve’s internet Guide「How MQTT Works -Beginners Guide」
株式会社グルーヴノーツ「MAGELLAN Dev Center. 」MQTT の仕様

MQTTとHTTPの比較

MQTT HTTP
同期有無 非同期 同期
送受信の対象 多対多 1対1
データ量 軽い(小さい) 重い(大きい)
通信基盤が不安定なとき 再接続時に再度送受信できる 送受信できない

MQTTは通信のオーバーヘッドが小さく、トラフィックがHTTPと比べて約10分の1程度なため、実質的な処理能力も約10倍です。また、最小のヘッダサイズは2byteと軽量なためバッテリー消費も10分の1以下に抑えることもできます。

通信方法も異なります。
HTTPは同期プロトコルのため、クライアントがリクエストを送信し、サーバーがそれに応答する1対1の通信をおこないます。一方、MQTTは非同期プロトコルで双方向やグループでの通信が可能です。ネットワークが不安定な場合でも再度送受信でき、必ずしもsubscriberがリアルタイムで待機する必要もありません。

そのため、M2MやIoTでは、HTTPではなくMQTTが適しているといえます。

出典:かもめエンジニアリング株式会社「MQTTとは」
株式会社AMG Solution「IoT開発未経験者向け! IoTで注目を浴びるプロトコル、MQTTとは?」

MQTTを利用するメリット

MQTTは、データ量を抑えた多数のメッセージ通信に適しています。特に、センサー遠隔監視では、機器は正常に動作していることを知らせるために定期的に短いデータを送信し、外部から監視が可能です。この軽量でシンプルなデータ通信は、主にIoT分野で活用されており、Google、Microsoft、AWSなど、大手クラウドベンダーもMQTTをサポートしております。

メリット1:不安定なネットワークや、性能が低いデバイスでも有効

通信が切れることを想定した機能に有効で、モバイルネットワークやWi-Fiなどのネットワークが不安定で通信接続ができない場合、そのタイミングではデータは送受信されませんが、再接続時にデータの送受信が可能です。

メリット2:狭い帯域幅でも利用しやすい

軽量なメッセージプロトコルのため、狭い帯域幅でも利用できます。

メリット3:通信量やCPU負荷、電力消費量を大幅に削減

MQTTはヘッダーが最小2byteと軽量です。特にデータ量の少ないメッセージを頻繁に送受信する際に、CPU負荷や消費電力を抑えることができます。

出典:Steve’s internet Guide「How MQTT Works -Beginners Guide」
株式会社アドバネット「MQTT入門ガイド」

MQTTの実用例

MQTTは自動車、製造、テレコミュニケーション、油田、ガスなどの幅広い産業で使用されています。

油田パイプラインイメージ

実用例1:油田パイプライン監視

油田パイプラインセンサーは、衛星に接続するためにMQTTが使われています。このセンサーは通信速度やデータ容量に厳しい条件がありませんが、衛星が通信範囲外になる可能性があるため、通信が失敗しても柔軟に対応できるプロトコルが必要でした。そこで、安定した接続基盤を提供するHTTPではなく、MQTTが採用されました。

出典:Adafruit「MQTT」

実用例2:Facebook Messenger

Facebook MessengerもMQTTを使っています。これは双方向通信(グループでの通信)、通信データ量が少なく、使用頻度が高いといった特徴を持つメッセージアプリケーションに適しています。

実用例3:屋外の自動水やりシステム

畑の温度や湿度などをセンサーで読み取り、自動で水やりをさせることが可能です。

畑のセンサーで温度と湿度を計測し、publisherとしてデータをクラウド上のbrokerに送ります。一方、判定装置はsubscriberとして温度と湿度をbrokerに要求します。そして受信したデータが温度や湿度の閾値を超えている場合、設定している指示(水やり)を実行します。

また、実際にどの程度給水がおこなわれたのかを記録するための給水機の稼働記録、作物の育成状況を確認するための撮影データ保存などでもMQTTでの通信が活用できます。

MQTTのプロトコルをRTOSで活用してみる

弊社のプロトコルスタックμNet3に含まれるMQTT クライアントのサンプルプログラ ムの一部を変更して、 AWS IoT の MQTT Broker へ接続、簡単なデータを Publish または Subscribe するための手順を無料で公開しています。 変更前後 の サンプル プログラムソースも参考資料として提供します。