「AWS IoT Coreを用いたMQTT通信IoTデバイス開発」

MQTTは以下の図のように3つの要素によって構成されます。

図1. MQTTの構成

• Subscriber（サブスクライバー=購読者）
  メッセージの受信者です。
  SubscriberはBroker（後述）に接続し、任意の「トピック」を「サブスクライブ」します。 このトピックとサブスクライブの詳細は後述しますが、これによってPublisher（後述）がBrokerに向けてトピックとデータを送信したときに、 自身がサブスクライブしたトピックのデータのみをBrokerから受信し、それ以外は受信しないということを実現できます。 現実世界における、雑誌などの出版社（パブリッシャー）と購読者（サブスクライバー）と同じ関係性と言えます。
  
  
• Publisher（パブリッシャー=出版者）
  メッセージの送信者です。
  PublisherはBroker（後述）に接続し、「トピック」とデータをひとつのメッセージとして送信します。 先述の通り、Publisherが送信したトピックをSubscriberがサブスクライブしている場合、Subscriberはデータを受信することができます。
  なお、PublisherとSubscriberはそれぞれ異なる機器である必要はなく、Publisher / Subscriberの両方の役割をひとつの機器に対して持たせることが可能です。 「2. どういったシステムに利用できるか」で例として挙げた通信端末の場合、機器のデータ通知はPublisherとして行い、指令を受け取ることはSubscriberとして行う形になります。
  
  
• Broker（ブローカー）
  Publisher – Subscriber間のデータ送受信を仲介します。
  BrokerはPublisher、Subscriberからの接続を受け入れ、Publisherからトピックとデータを受信し、そのトピックをサブスクライブしているSubscriberに対してデータを送信します。
  細かい機能としては他にもあるのですが、Brokerが行うべきことは上記の通りとてもシンプルです。 加えて、PublisherやSubscriberはデータを送信する前の処理（例えばセンサーから値を収集したりなど）やデータを受信した後の処理を自ら実装する必要がありますが、 Brokerに関しては単にデータの受け渡しをすればいいだけで独自の処理を入れ込む必要がありません。 そのためBrokerは新規に開発するのではなく、すでにあるBrokerを使用するほうが効率的です。 すでにあるBrokerの中にはクラウドサービスとして展開されているものもあり、そのうちのひとつがAWS IoT Coreに含まれています。

さて先述した「トピック」を「サブスクライブ」するということについてですが、これが具体的にどのようなものであるかを説明します。

まず、トピックとは文字列です。 ではどのような文字列かというと、次のようなスラッシュ”/”区切りの文字列となっています。 勘の良い方ならもうわかるかもしれませんが、トピックは階層構造を表す文字列であり、この階層構造を利用してメッセージを受信する範囲を調整することができます。
例えば、A（Publisher）が「/tokyo/shinjuku/yotsuya」や「tokyo/shinjuku/ichigaya」といったトピックを送信するとします。 ここで、B（Subscriber）が「yotsuya」に関するデータのみ受信したい場合は 「tokyo/shinjuku/yotsuya」をサブスクライブすればいいことになります。
では、Bが「tokyo/shinjuku」より下の階層のすべてのデータを受信したい場合はどうすればいいでしょうか。 これに関しては、ワイルドカードを使用することで実現可能です。 ワイルドカードとして使用できる文字には2種類あり、階層の数にこだわらず「tokyo/shinjuku」より下の階層のすべてのデータを受信したい場合は「tokyo/shinjuku/#」でサブスクライブします。 1階層下のすべてのデータを受信したい場合は「tokyo/shinjuku/+」とします。
なお、サブスクライブできるトピックの数はひとつだけではなく、複数のトピックをサブスクライブ可能です。

ところで、「PublisherやSubscriberはどのようにして相手が取り扱うトピックを知ることができるのか」といったことを疑問に思う方がいるかもしれません。この問題の解決方法としては、事前の取り決めによって送受信するトピックを決めておく、ということになります。これはプロトコル上の取り決めというよりも運用上の話ですが、もしMQTT通信で連携する機器同士の開発者が異なる場合、何のトピックを送信するかといったことを事前に決めておきしっかりと管理する必要があります。

MQTTには再送の仕組みがあります。再送機能を有効にするには、メッセージを送信する際にQOS(Quality of Service)というパラメータを指定する必要があります。基本的にQOSによる再送の仕組みはメッセージを受信した後のパケット応答によって実現されますが、この応答の義務が発生するのはPublisher→Brokerのメッセージ送信だけでなくBroker→Subscriberのメッセージ送信でも同様です。そのため、以降のQOSの説明ではPublisherやSubscriberといった役割の表記ではなく「送信者」と「受信者」で表現します。
QOSは3段階あり、それぞれ次のように定められています。

• QOS 0 (Publish once at most)
  送信者は受信者に最高で1回メッセージを送信します。再送機能はありません。
  送信者はメッセージを送信したあと、受信者からの応答を待機しないためメッセージの伝送効率が最も高くなります。 しかし、送信者は受信者へメッセージが届いたか否かをチェックしないため、メッセージが届いていない場合でも何もしません。
  
  
  
  図2. QOS : 0
  
  
• QOS 1 (Publish once at least)
  送信者は受信者に最低で1回メッセージを送信します。
  送信者はメッセージを送信したあと、受信者からの「PUBACK」パケットを待機します。もし指定されたPUBACKを受信しなかった場合は再送が行われます。
  なお、受信者がメッセージを受信したにもかかわらず送信者がPUBACKを受信できなかった場合、メッセージが再送されてしまいますので、受信者は重複したメッセージを受信する可能性があります。
  
  
  
  図3. QOS : 1
  
  
• QOS 2 (Publish only once)
  送信者は受信者に必ず1回だけメッセージを送信します。
  送信者はメッセージを送信したあと、受信者からの「PUBREC」パケットを待機します。 このPUBRECは受信者がメッセージを受信したことを示します。 その後、送信者は受信者に対して「PUBREL」パケットを送信し、送信済みとなったメッセージを破棄したことを通知します。 受信者は「PUBREL」パケットを受信したあと、送信者に向けて「PUBCOMP」パケットを通知することでメッセージの完了を通知します。
  
  
  
  図4. QOS : 2

MQTTでは、Publisher/SubscriberとBrokerの接続が途切れてしまった場合の挙動についても策定されています。 MQTTでは接続断後の再接続時に、前回のセッションを再使用するか、あるいは使用せず新たにセッションを開始するかの設定があります。

ここで、セッションとはPublisher/SubscriberとBrokerの接続開始から終了までを指します。 セッションを再使用するとは、接続開始から終了までの状態を引き継ぐということであり、 例えばBrokerがPUBACKを受信していないQOS=1のメッセージを再度送信することや、すでにあるトピックをサブスクライブしていた場合はそれらをサブスクライブした状態でセッションを再開することが可能です。 これによって、状況にもよりますが切断状態中に受信できなかったメッセージを受信することが可能です。
Brokerは複数のセッションを「クライアントID」というパラメータを使用して管理しています。 クライアントIDはBrokerに接続する時点でBrokerに通知し、再接続する際にもBrokerに通知します。 セッションを再使用する設定にしている場合、Brokerは同じクライアントIDの接続があった場合にセッションを再使用します。

MQTTは一般的に信頼性の高い通信プロトコルと言われますが、その理由は上記のQOSやセッションといったプロトコル的な要因以外にBrokerの存在も大きいと言えます。 Publisher/Subscriberが直接通信する場合、通信相手側で通信トラブルが頻発する可能性がありますが、 Brokerを外部サービスによって調達すれば24時間管理された非常に信頼性の高い通信相手との通信の成否のみを気にすればよくなるからです。