JP6525102B2 - 通信システム、エッジサーバ、方法およびプログラム - Google Patents

Description

本発明は、パブリッシュ／サブスクライブモデルに基づく通信技術に関する。

装置間でメッセージを送受信する際に用いられるパブリッシュ／サブスクライブモデルが知られている。パブリッシュ／サブスクライブモデルでは、サブスクライバは、受信したいトピックをブローカに登録しておく。パブリッシャは、メッセージにトピックを表す情報を含めてブローカに送信する。そして、ブローカは、受信したメッセージに含まれる情報が表すトピックを登録しているサブスクライバに、メッセージを配信する。以降、パブリッシャがブローカを介してメッセージを送信することを、パブリッシュするとも記載する。また、サブスクライバがブローカからメッセージを受信することを、サブスクライブするとも記載する。

例えば、パブリッシュ／サブスクライブモデルを用いた技術の一例が、特許文献１に記載されている。特許文献１に記載された関連技術では、不揮発性ストレージの容量が少ないデバイス上で動作するアプリケーションが、出力するログデータのサイズが閾値に達する度に、そのログデータをブローカにパブリッシュすることを繰り返す。そして、ブローカは、そのログデータに関連するトピックを登録しているサブスクライバに、ログデータを転送する。サブスクライバは、該当するログデータをサブスクライブして分析する。

このようなパブリッシュ／サブスクライブモデルは、ＩｏＴ（Internet of Things）の分野で採用されることが多い。ＩｏＴでは、小型化かつ軽量化されたデバイスやセンサによって管理装置に向けてデータが送信されるため、低電力で軽量な通信を行う必要がある。低電力で軽量な通信には、パブリッシュ／サブスクライブモデルが適しているからである。そのようなパブリッシュ／サブスクライブモデルに基づくプロトコルには、送受信するメッセージのＱｏＳ（Quality of Service）として送達保証レベルが設定可能なものがある。一例としては、ＭＱＴＴ（Message Queue Telemetry Transport）が良く知られている。ＭＱＴＴでは、送達保証レベルとして、０（最大１回）、１（最低１回）、２（正確に１回）の３段階が用意されている。

ところで、ＩｏＴを大規模なシステムで活用する場合、多数のデバイスに搭載されるセンサが大量に存在する状況になる。これらのデバイスに搭載されるセンサは、クラウド上の管理装置により一元的に管理される。このとき、管理装置およびデバイス間の通信に、パブリッシュ／サブスクライブモデルが採用されるとする。この場合、クラウド上に配置されるブローカだけでは、多数のデバイスとの間でのメッセージの処理性能に限界がある。このため、クラウド上の管理装置とデバイスとの間を中継するエッジサーバおよびブローカが中間層に配置される。クラウド層のブローカは、管理装置およびエッジサーバ間の通信を制御し、中間層のブローカは、エッジサーバおよびデバイス間の通信を制御する。つまり、ＩｏＴにおけるパブリッシュ／サブスクライブモデルでは、ブローカが多段に接続される構成となる。

このようにブローカを多段に構成する技術の一例が、特許文献２に記載されている。特許文献２に記載された関連技術では、サービスを提供するプロバイダと、サービスをリクエストするリクエスタとの間で、ブローカおよびプロバイダが多段に構成されツリー構造をなす。リクエスタは、プロバイダからサービスの提供を受けるために、ブローカに対してリクエストメッセージを送信する。ブローカは、受信したリクエストメッセージを、ツリー構造において下位に接続される他のブローカまたはプロバイダに転送する。また、プロバイダは、受信したリクエストメッセージに応じた処理において他のサービスを呼び出す必要がある場合、リクエストメッセージを、下位に接続される他のブローカに送信する。

特表２００９−５１９５０９号公報 特開２００６−７２７８５号公報

ここで、上述したようなＩｏＴでは、デバイスが移動するケースも多い。したがって、上述のようなブローカが多段に構成されるシステムでは、デバイスが通信可能な中間層のブローカは、そのデバイスの移動により変わり得る。しかしながら、上述した関連技術は、デバイスが移動する場合に対応できないという課題がある。

この課題について詳しく説明する。パブリッシュ／サブスクライブモデルに基づく通信システムにおいてブローカが多段に構成される場合、管理装置からデバイスへの送達保証レベルが保証されないという問題が生じる。具体的には、管理装置およびエッジサーバ間、ならびに、エッジサーバおよびデバイス間でそれぞれ行われるパブリッシュ／サブスクライブモデルに基づく通信において、送達保証レベルが設定されるとする。この場合、それぞれの通信は、設定された送達保証レベルに基づいて処理がなされても、管理装置およびデバイス間では、それぞれの通信で個々に設定された送達保証レベルと同レベルが保証されない。

この問題点をさらに詳しく説明するために、具体例を用いて説明する。ここで、クラウド層の管理装置は、中間層のエッジサーバを経由し、デバイスを管理しているとする。中間層のエッジサーバは、デバイスが存在し得るエリア毎に設置されている。また、管理装置およびエッジサーバ間では、クラウド層のブローカを介してパブリッシュ／サブスクライブモデルに基づく通信が行われる。また、エッジサーバおよびデバイス間では、そのエッジサーバが存在するエリアに設けられた中間層のブローカを介して、パブリッシュ／サブスクライブモデルに基づく通信が行われる。

このとき、管理装置が、エリアＡにあるデバイスＡに対して管理操作を行うためにメッセージｍ１を送信することを考える。管理装置は、クラウド層のブローカに対して送達保証レベル１（最低１回送信）で、デバイスＡ宛てのトピックを指定したメッセージｍ１をパブリッシュする。次に、中間層にあるエリアＡのエッジサーバは、自エリアに存在するデバイスＡ宛てのトピックのメッセージｍ１を、クラウド層のブローカからサブスクライブする。このとき、管理装置およびエリアＡのエッジサーバ間では、送達保証レベル１が保証される。

次に、エリアＡのエッジサーバは、エリアＡの中間層のブローカに対して、送達保証レベル１でデバイスＡ宛てのトピックを指定したメッセージｍ１をパブリッシュする。しかしながら、この時点で、デバイスＡがエリアＡからエリアＢに移動していたとする。この場合、デバイスＡは、エリアＢの中間層のブローカからサブスクライブを行うことになる。

そのため、デバイスＡがエリアＢからエリアＡに戻らない限り、エリアＡの中間層のブローカからのサブスクライブは行われず、メッセージｍ１は、デバイスＡに配信されないことになる。

このように管理装置、エッジサーバ、およびデバイスがそれぞれ正常に動作しており、それぞれの間の通信で送達保証レベルが１に設定されているにもかかわらず、メッセージが正しく配信されない「メッセージがロストする」という状態が発生する。

また、この場合、エリアＡの中間層のブローカは、サブスクライブによってデバイスＡへの配信が完了するまでの間、メッセージｍ１を保存することになる。ここで、デバイスＡによるサブスクライブが行われない場合であっても、デバイスＡの電源が切れている場合等のように、移動以外の理由も考えられる。したがって、ブローカは、配信されないメッセージｍ１を、配信が完了するまでまたは一定期間以上となるまで保存する必要があり、中間層の保存領域を圧迫するという問題も発生する。

また、上述のケースで、デバイスＡが再びエリアＡに戻ってきたとする。この場合、当初の管理装置からのメッセージｍ１は、デバイスＡに対して配信される。しかしながら、他のエリアにおいて、デバイスＡが管理装置からの最新のメッセージｍ２を受信している可能性がある。この場合、エリアＡに戻ることにより配信される過去のメッセージｍ１により、最新の設定が過去の設定で上書きされ、動作不正を起こす問題が発生し得る。

ここで、特許文献１に記載された関連技術において、デバイスとログデータを分析する装置との間で、多段に構成されるブローカを用いてパブリッシュ／サブスクライブモデルに基づく通信が行われるとする。また、デバイスが移動する可能性があるとする。しかしながら、この関連技術は、移動可能なデバイスから分析装置に対してログデータを送信するものであり、移動可能なデバイスに対してメッセージを配信するケースでの上述の課題に対応できない。

また、特許文献２に記載された関連技術では、ブローカの下位に接続されるプロバイダまたは他のブローカは、固定的に接続されていることが前提である。したがって、この関連技術は、移動可能なデバイスに対してメッセージを配信するケースでの上述の課題に対応できない。

本発明は、上述の課題を解決するためになされたものである。すなわち、本発明は、多段に構成されるブローカを介してパブリッシュ／サブスクライブモデルに基づく通信を行うシステムにおいて、移動可能なデバイスに対するメッセージの配信をより確実に行う技術を提供することを目的とする。

上記目的を達成するために、本発明のエッジサーバは、自装置を含む複数のエッジサーバおよび管理装置の間をパブリッシュ／サブスクライブ通信により接続する第１ブローカから、前記管理装置によって送信される自装置が配信を担当中のデバイス宛のメッセージ、または、他のエッジサーバによって自装置に再配信を依頼されたデバイス宛のメッセージを受信し、受信したメッセージを前記デバイスに配信するため、自装置および前記デバイスの間をパブリッシュ／サブスクライブ通信により接続する第２ブローカに対して送信するメッセージ送受信手段と、前記第２ブローカから、前記デバイスへの前記メッセージの配信失敗を通知されると、前記デバイスへの前記メッセージの再配信の依頼先となる他のエッジサーバを決定する依頼先決定手段と、前記依頼先となる他のエッジサーバに対して前記デバイスへの前記メッセージの再配信を依頼するため、前記メッセージを前記第１ブローカに送信する再配信依頼手段と、を備える。

また、本発明の第２ブローカは、上述の前記第２ブローカであって、前記エッジサーバから受信した前記メッセージを前記デバイスに配信するメッセージ配信手段と、前記デバイスに対する前記メッセージの配信失敗を検出して前記エッジサーバに通知する配信状況管理手段と、を備える。

また、本発明の第１ブローカは、上述の前記第１ブローカであって、前記エッジサーバから前記他のエッジサーバに対して前記再配信を依頼された前記メッセージを、前記他のエッジサーバに配信するメッセージ配信手段を備える。

また、本発明の通信システムは、上述のエッジサーバと、上述の第２ブローカと、上述の第１ブローカと、前記管理装置と、前記デバイスと、を含む。

また、本発明の方法は、自装置を含む複数のエッジサーバおよび管理装置の間をパブリッシュ／サブスクライブ通信により接続する第１ブローカから、前記管理装置によって送信される自装置が配信を担当中のデバイス宛のメッセージ、または、他のエッジサーバによって自装置に再配信を依頼されたデバイス宛のメッセージを受信し、受信したメッセージを前記デバイスに配信するため、自装置および前記デバイスの間をパブリッシュ／サブスクライブ通信により接続する第２ブローカに対して送信し、前記第２ブローカから、前記デバイスへの前記メッセージの配信失敗を通知されると、前記デバイスへの前記メッセージの再配信の依頼先となる他のエッジサーバを決定し、前記依頼先となる他のエッジサーバに対して前記デバイスへの前記メッセージの再配信を依頼するため、前記メッセージを前記第１ブローカに送信する。

また、本発明の記憶媒体は、自装置を含む複数のエッジサーバおよび管理装置の間をパブリッシュ／サブスクライブ通信により接続する第１ブローカから、前記管理装置によって送信される自装置が配信を担当中のデバイス宛のメッセージ、または、他のエッジサーバによって自装置に再配信を依頼されたデバイス宛のメッセージを受信し、受信したメッセージを前記デバイスに配信するため、自装置および前記デバイスの間をパブリッシュ／サブスクライブ通信により接続する第２ブローカに対して送信するステップと、前記第２ブローカから、前記デバイスへの前記メッセージの配信失敗を通知されると、前記デバイスへの前記メッセージの再配信の依頼先となる他のエッジサーバを決定するステップと、前記依頼先となる他のエッジサーバに対して前記デバイスへの前記メッセージの再配信を依頼するため、前記メッセージを前記第１ブローカに送信するステップと、をコンピュータ装置に実行させるプログラムを記憶している。

本発明は、多段に構成されるブローカを介してパブリッシュ／サブスクライブモデルに基づく通信を行うシステムにおいて、移動可能なデバイスに対するメッセージの配信をより確実に行う技術を提供することができる。

本発明の第１の実施の形態としての通信システムの構成を示すブロック図である。 本発明の第１の実施の形態としての通信システムのハードウェア構成の一例を示す図である。 本発明の第１の実施の形態としての通信システムの機能ブロック構成を示す図である。 本発明の第１の実施の形態としての通信システムの動作を説明するフローチャートである。 本発明の第２の実施の形態としての通信システムの機能ブロック構成を示す図である。 本発明の第２の実施の形態におけるエリアマップ情報の一例を示す図である。 本発明の第２の実施の形態における重複制御情報の一例を示す図である。 本発明の第２の実施の形態におけるメッセージ管理テーブルの一例を示す図である。 本発明の第２の実施の形態におけるトピック管理テーブルの一例を示す図である。 本発明の第２の実施の形態における配信状況テーブルの一例を示す図である。 本発明の第２の実施の形態としての通信システムの動作の概略を説明するフローチャートである。 本発明の第２の実施の形態において第２ブローカが配信失敗を検出した際の動作を説明するフローチャートである。 本発明の第２の実施の形態においてエッジサーバが再配信の依頼先を決定する動作を説明するフローチャートである。 本発明の第２の実施の形態においてエッジサーバの監視モードにおける動作を説明するフローチャートである。 本発明の第２の実施の形態においてエッジサーバから管理装置に再配信を依頼する動作を説明するフローチャートである。 本発明の第２の実施の形態において再配信を依頼されたエッジサーバおよび第２ブローカの動作を説明するフローチャートである。 本発明の第２の実施の形態における具体例の動作を説明する模式図である。 図１７に続く具体例の動作を説明する模式図である。 図１８に続く具体例の動作を説明する模式図である。 図１９に続く具体例の動作を説明する模式図である。 図２０に続く具体例の動作を説明する模式図である。 本発明の第３の実施の形態としての通信システムの機能ブロック構成を示す図である。 本発明の第３の実施の形態におけるロケーション情報の一例を示す図である。 本発明の第４の実施の形態としての通信システムの機能ブロック構成を示す図である。

以下、本発明の実施の形態について、図面を参照して詳細に説明する。

（第１の実施の形態）
本発明の第１の実施の形態としての通信システム１の機能ブロック構成を図１に示す。図１において、通信システム１は、管理装置１００と、デバイス２００と、エッジサーバ３００と、第１ブローカ４００と、第２ブローカ５００とを備える。管理装置１００および第１ブローカ４００は、ネットワークを介して通信可能に接続される。また、第１ブローカ４００およびエッジサーバ３００は、ネットワークを介して通信可能に接続される。また、エッジサーバ３００および第２ブローカ５００は、ネットワークを介して通信可能に接続される。また、第２ブローカ５００およびデバイス２００は、ネットワークを介して通信可能に接続される。なお、各装置間を接続するネットワークは、インターネット、ＬＡＮ（Local Area Network）、公衆回線網、無線通信網またはこれらの組合せ等によって構成される。なお、デバイス２００は、移動体であるため、第２ブローカ５００およびデバイス２００を接続するネットワークは、典型的には、無線通信網を含む。このため、図１では、第２ブローカ５００およびデバイス２００が、無線通信網により接続される例が示されている。ただし、第２ブローカ５００およびデバイス２００を接続するネットワークは、無線通信網に限定されない。

デバイス２００は、管理の対象となる移動体である。また、管理装置１００は、１つ以上のデバイス２００を管理する装置である。また、エッジサーバ３００は、管理装置１００およびデバイス２００間の通信を中継する装置である。通信システム１には、複数のエッジサーバ３００が設けられる。例えば、エッジサーバ３００は、デバイス２００の移動が想定される空間的な範囲が分割された各エリアについて、該エリアに存在するデバイス２００との通信を担当するよう、設けられていてもよい。なお、その場合、１つのエリアについて設けられるエッジサーバ３００の数は、１つであってもよいし、複数であってもよい。第１ブローカ４００は、管理装置１００およびエッジサーバ３００間、ならびに、複数のエッジサーバ３００間を、パブリッシュ／サブスクライブモデルに基づく通信により接続する装置である。以降、パブリッシュ／サブスクライブモデルに基づく通信を、パブリッシュ／サブスクライブ通信とも記載する。第２ブローカ５００は、エッジサーバ３００およびデバイス２００間をパブリッシュ／サブスクライブ通信により接続する装置である。例えば、第２ブローカ５００は、前述の各エリアについて、該エリアに存在するデバイス２００と該エリアを担当するエッジサーバ３００との間を接続するよう、設けられていてもよい。

なお、図１には、１つずつの管理装置１００および第１ブローカ４００が示されているが、通信システム１における管理装置１００および第１ブローカ４００の数は、限定されない。また、図１には、３つずつのエッジサーバ３００および第２ブローカ５００が示されているが、通信システム１におけるエッジサーバ３００および第２ブローカ５００の数は限定されない。また、図１には、６つのデバイス２００が示されているが、通信システム１におけるデバイス２００の数は限定されない。

ここで、通信システム１を構成する各装置は、図２に示すようなハードウェア要素によって構成可能である。

図２において、管理装置１００は、ＣＰＵ（Central Processing Unit）１００１、メモリ１００２、および、ネットワークインタフェース１００５を含む。メモリ１００２は、ＲＡＭ（Random Access Memory）、ＲＯＭ（Read Only Memory）、補助記憶装置（ハードディスクやフラッシュメモリ等）等によって構成される。ネットワークインタフェース１００５は、第１ブローカ４００との通信が可能なネットワークに接続するインタフェースである。管理装置１００の機能は、メモリ１００２に記憶されたコンピュータ・プログラムを実行するとともにネットワークインタフェース１００５を制御するＣＰＵ１００１によって実現される。

また、デバイス２００は、ＣＰＵ２００１、メモリ２００２、および、ネットワークインタフェース２００５を含む。メモリ２００２は、ＲＡＭ、ＲＯＭ、補助記憶装置等によって構成される。ネットワークインタフェース２００５は、第２ブローカ５００との通信が可能なネットワークに接続するインタフェースである。デバイス２００の機能は、メモリ２００２に記憶されたコンピュータ・プログラムを実行するとともにネットワークインタフェース２００５を制御するＣＰＵ２００１によって実現される。

また、エッジサーバ３００は、ＣＰＵ３００１、メモリ３００２、および、ネットワークインタフェース３００５を含む。メモリ３００２は、ＲＡＭ、ＲＯＭ、補助記憶装置等によって構成される。ネットワークインタフェース３００５は、第１ブローカ４００および第２ブローカ５００との通信がそれぞれ可能なネットワークに接続する各インタフェースからなる。エッジサーバ３００における後述の各機能ブロックは、メモリ３００２に記憶されたコンピュータ・プログラムを実行するとともにネットワークインタフェース３００５を制御するＣＰＵ３００１によって構成される。

また、第１ブローカ４００は、ＣＰＵ４００１、メモリ４００２、および、ネットワークインタフェース４００５を含む。メモリ４００２は、ＲＡＭ、ＲＯＭ、補助記憶装置等によって構成される。ネットワークインタフェース４００５は、管理装置１００およびエッジサーバ３００との通信がそれぞれ可能なネットワークに接続する各インタフェースからなる。第１ブローカ４００における後述の各機能ブロックは、メモリ４００２に記憶されたコンピュータ・プログラムを実行するとともにネットワークインタフェース４００５を制御するＣＰＵ４００１によって構成される。

また、第２ブローカ５００は、ＣＰＵ５００１、メモリ５００２、および、ネットワークインタフェース５００５を含む。メモリ５００２は、ＲＡＭ、ＲＯＭ、補助記憶装置等によって構成される。ネットワークインタフェース５００５は、エッジサーバ３００およびデバイス２００との通信がそれぞれ可能なネットワークに接続する各インタフェースからなる。第２ブローカ５００における後述の各機能ブロックは、メモリ５００２に記憶されたコンピュータ・プログラムを実行するとともにネットワークインタフェース５００５を制御するＣＰＵ５００１によって構成される。

なお、通信システム１を構成する各装置およびその各機能ブロックのハードウェア構成は、上述の構成に限定されない。

次に、各装置の機能ブロック構成について、図３を参照して詳細に説明する。図３において、管理装置１００は、前述のように、移動可能なデバイス２００を管理する装置である。また、第１ブローカ４００は、メッセージ配信部４０１を有する。また、エッジサーバ３００は、メッセージ送受信部３０１と、依頼先決定部３０２と、再配信依頼部３０３とを有する。また、第２ブローカ５００は、メッセージ配信部５０１と、配信状況管理部５０２とを有する。デバイス２００は、移動可能な装置である。

まず、管理装置１００の機能について説明する。

管理装置１００は、デバイス２００宛のメッセージを、第１ブローカ４００に送信する。具体的には、管理装置１００は、第１ブローカ４００におけるトピックへ、メッセージをパブリッシュすればよい。トピックとしては、例えば、そのメッセージの宛先となるデバイス２００に関連するトピックが適用される。また、宛先となるデバイス２００への配信を担当するエッジサーバ３００が特定可能である場合、トピックとしては、宛先となるデバイス２００および配信を担当するエッジサーバ３００に関連するトピックが適用される。

なお、メッセージは、例えば、デバイス２００の制御、管理または運用に関する情報を含む。具体例としては、メッセージは、デバイス２００に搭載されるカメラについてその向きやズームイン、ズームアウト等を制御する情報を含んでいてもよい。また、メッセージは、デバイス２００上のファームウェアを更新するための情報や、デバイス２００上にインストールされるアプリを配信するための情報を含んでいてもよい。また、メッセージは、デバイス２００の起動または停止を制御する情報を含んでいてもよい。また、メッセージは、デバイス２００から送信されるセンサ情報の送信間隔を設定する情報を含んでいてもよい。また、メッセージは、デバイス２００を携帯する利用者向けの情報を含んでいてもよい。ただし、メッセージに含まれる情報は、これらに限定されない。

次に、第１ブローカ４００の各機能ブロックについて説明する。

メッセージ配信部４０１は、管理装置１００からデバイス２００宛のメッセージを受信すると、そのデバイス２００への配信を担当するエッジサーバ３００に対してそのメッセージを配信する。具体的には、メッセージ配信部４０１は、デバイス２００に関連するトピックに対して、その配信を担当中のエッジサーバ３００をサブスクライバとして記憶している。サブスクライバとは、そのトピックのサブスクライブを登録している装置をいう。そして、メッセージ配信部４０１は、メッセージを受信すると、そのトピックのサブスクライバとして記憶しているエッジサーバ３００に対して、そのメッセージを配信する。

また、メッセージ配信部４０１は、あるエッジサーバ３００から、他のエッジサーバ３００に対して再配信を依頼するメッセージを受信すると、依頼先のエッジサーバ３００に対してそのメッセージを配信する。例えば、第１ブローカ４００には、再配信用トピックが設定されていてもよい。再配信用トピックとは、エッジサーバ３００間で再配信の依頼に伴う各種の情報を送受信するためのトピックである。再配信用トピックは、情報の送信側のエッジサーバ３００と、受信側のエッジサーバ３００と、再配信先のデバイス２００との組合せ毎に設定されてもよい。その場合、メッセージ配信部４０１は、再配信用トピックについて、情報の受信側のエッジサーバ３００をサブスクライバとして記憶しておく。そして、メッセージ配信部４０１は、再配信用トピックへ送信側からのメッセージを受信すると、その再配信用トピックのサブスクライバとして記憶しているエッジサーバ３００に対して、そのメッセージを配信すればよい。

次に、エッジサーバ３００の各機能ブロックについて説明する。

メッセージ送受信部３０１は、第１ブローカ４００から、管理装置１００によるデバイス２００宛のメッセージを受信する。受信の対象となるメッセージは、自装置が配信を担当中のデバイス２００宛のメッセージ、および、他のエッジサーバ３００によって自装置に再配信を依頼されたデバイス２００宛のメッセージである。

ここで、メッセージ送受信部３０１は、自装置が配信を担当中のデバイス２００に関連するトピックのサブスクライブを、第１ブローカ４００に登録しておく。つまり、登録により、第１ブローカ４００において自装置が、配信を担当中のデバイス２００に関連するトピックのサブスクライバとして記憶される。

なお、配信を担当中のデバイス２００とは、例えば、自装置が配信を担当するエリアに存在するデバイス２００である。例えば、エッジサーバ３００は、自装置が担当するエリアに存在するデバイス２００を定期的に検出し、検出したデバイス２００を、配信を担当中のデバイス２００として、関連するトピックのサブスクライブを第１ブローカ４００に登録してもよい。具体的には、エッジサーバ３００は、担当するエリア内において、無線通信網を介して登録を要求する情報を定期的に送信し、要求に応じる情報を返信したデバイス２００を、配信を担当中のデバイス２００としてもよい。あるいは、後述の第２ブローカ５００が、そのような定期的な検出を行ってもよい。その場合、メッセージ送受信部３０１は、第２ブローカ５００に問い合わせることにより、自装置が配信を担当中のデバイス２００を表す情報を取得してもよい。

また、メッセージ送受信部３０１は、第１ブローカ４００から受信したデバイス２００宛のメッセージを、そのデバイス２００に対して配信するよう、第２ブローカ５００に送信する。具体的には、メッセージ送受信部３０１は、第２ブローカ５００におけるトピックへ、管理装置１００から受信したメッセージをパブリッシュすればよい。トピックとしては、例えば、宛先となるデバイス２００に関連するトピックが適用される。

依頼先決定部３０２は、第２ブローカ５００から、デバイス２００へのメッセージの配信失敗を通知されると、デバイス２００へのメッセージの再配信の依頼先となる他のエッジサーバ３００を決定する。具体的には、依頼先決定部３０２は、依頼先となるエッジサーバ３００の候補の中から、依頼先のエッジサーバ３００を決定してもよい。例えば、依頼先決定部３０２は、あらかじめ自装置の周辺に存在するエッジサーバ３００を特定する情報を記憶しておき、それらのエッジサーバ３００を候補としてもよい。

再配信依頼部３０３は、依頼先決定部３０２によって決定された他のエッジサーバ３００に対して、配信失敗が通知されたデバイス２００へのメッセージの再配信を、第１ブローカ４００を介して依頼する。具体的には、再配信依頼部３０３は、前述した再配信用トピックへ、該当するメッセージをパブリッシュすればよい。

次に、第２ブローカ５００の各機能ブロックについて説明する。

メッセージ配信部５０１は、エッジサーバ３００からデバイス２００宛のメッセージを受信すると、そのデバイス２００に対してそのメッセージを配信する。具体的には、メッセージ配信部５０１は、トピックへメッセージを受信すると、そのトピックのサブスクライバとして記憶しているデバイス２００に対して、そのメッセージを配信する。

配信状況管理部５０２は、デバイス２００に対するメッセージの配信失敗を検出して、エッジサーバ３００に通知する。具体的には、配信状況管理部５０２は、メッセージを受信したトピックのサブスクライバとして記憶しているデバイス２００との通信が不可能でメッセージが配信できない場合、まず、そのメッセージのそのデバイス２００への再送処理を試みてもよい。再送処理は、例えば、所定間隔毎に実行されてもよい。そして、配信状況管理部５０２は、所定の条件に応じて、配信に失敗したと判断してもよい。所定の条件とは、例えば、再送回数が閾値に達したことであってもよいし、最初の配信処理からの経過時間が閾値に達したことであってもよいが、これらに限らない。

次に、デバイス２００の機能について説明する。

デバイス２００は、前述のように、管理の対象となる移動体である。例えば、デバイス２００は、生産ラインにおいて生産中の製品と共に移動する物体に搭載されたものであってもよい。あるいは、デバイス２００は、例えば、人によって携帯される装置であってもよい。ただし、これらは一例であり、デバイス２００として適用可能な移動体を限定するものではない。デバイス２００は、管理装置１００からのメッセージを、第１ブローカ４００、エッジサーバ３００、第２ブローカ５００を介して、パブリッシュ／サブスクライブ通信により受信する。具体的には、デバイス２００は、接続した第２ブローカ５００に対して、自装置に関連するトピックのサブスクライブを登録する。これにより、デバイス２００は、その第２ブローカ５００に接続している限り、その第２ブローカ５００の該当するトピックへパブリッシュされるメッセージを受信する。

例えば、デバイス２００には、センサが搭載されていてもよい。そして、デバイス２００は、自装置に搭載されているセンサに関するトピックのサブスクライブを、第２ブローカ５００に登録してもよい。

以上のように構成された通信システム１の動作について、図４を参照して詳細に説明する。なお、以下の動作の説明では、メッセージには、パブリッシュ／サブスクライブ通信における送達保証レベルとして、送信先に届くことが保証されるレベル（例えば、ＭＱＴＴであれば、１または２）が設定されているものとする。送達保証レベルとして、送信先に届くことが保証されないレベル（ＭＱＴＴであれば、０）が設定されたメッセージについての動作は、以下のステップＳ４で終了するため、説明を省略する。

まず、管理装置１００は、デバイス２００宛のメッセージを、第１ブローカ４００に送信する。具体的には、管理装置１００は、デバイス２００宛のメッセージを、第１ブローカ４００におけるそのデバイス２００に関連するトピックへパブリッシュする。そして、第１ブローカ４００のメッセージ配信部４０１は、デバイス２００宛のメッセージを受信する（ステップＳ１）。

次に、メッセージ配信部４０１は、受信したデバイス２００宛のメッセージを、そのデバイス２００への配信を担当中のエッジサーバ３００に配信する。具体的には、メッセージ配信部４０１は、デバイス２００宛のメッセージを受信したトピックのサブスクライバとして記憶しているエッジサーバ３００に対して、そのメッセージを配信する（ステップＳ２）。

次に、エッジサーバ３００のメッセージ送受信部３０１は、自装置が配信を担当中のデバイス２００宛のメッセージを、第１ブローカ４００から受信する。そして、メッセージ送受信部３０１は、受信したデバイス２００宛のメッセージを、第２ブローカ５００に送信する。具体的には、メッセージ送受信部３０１は、デバイス２００宛のメッセージを、第２ブローカ５００におけるそのデバイス２００に関連するトピックへパブリッシュする（ステップＳ３）。

次に、第２ブローカ５００のメッセージ配信部５０１は、デバイス２００宛のメッセージを受信する。そして、メッセージ配信部５０１は、受信したデバイス２００宛のメッセージを、そのデバイス２００に配信する。具体的には、メッセージ配信部５０１は、デバイス２００宛のメッセージを受信したトピックのサブスクライバとして記憶しているデバイス２００に対して、そのメッセージを配信する（ステップＳ４）。

ここで、配信が成功した場合（ステップＳ５でＹｅｓ）、通信システム１は、動作を終了する。

一方、配信が成功しなかった場合（ステップＳ５でＮｏ）、メッセージ配信部５０１は、再送を試みる（ステップＳ６）。例えば、前述のように、メッセージ配信部５０１は、所定期間経過する毎に、再送を試みてもよい。

次に、配信状況管理部５０２は、配信に失敗したか否かを検出する（ステップＳ７）。

例えば、前述のように、配信状況管理部５０２は、ステップＳ６での再送を試みた回数または最初に配信を行ってからの経過時間等に基づいて、配信に失敗したか否かを判断してもよい。

ここで、配信の失敗が検出されなければ（ステップＳ７でＮｏ）、すなわち、メッセージは、再送によりデバイス２００に配信されたことになる。この場合、通信システム１は、動作を終了する。

一方、配信の失敗が検出された場合（ステップＳ７でＹｅｓ）、配信状況管理部５０２は、このメッセージの送信元のエッジサーバ３００に対して、配信失敗を通知する（ステップＳ８）。

次に、エッジサーバ３００において、配信失敗が通知された場合（ステップＳ９でＹｅｓ）、依頼先決定部３０２は、配信に失敗したデバイス２００宛のメッセージについて、再配信の依頼先となる他のエッジサーバ３００を決定する（ステップＳ１０）。

例えば、前述のように、依頼先決定部３０２は、自装置の周辺に位置する他のエッジサーバ３００を候補として、それらの中から依頼先を決定してもよい。

次に、再配信依頼部３０３は、決定した依頼先のエッジサーバ３００に対して再配信を依頼するデバイス２００宛のメッセージを、第１ブローカ４００に送信する（ステップＳ１１）。

具体的には、前述のように、再配信依頼部３０３は、第１ブローカ４００における再配信用トピックへ、該当するメッセージをパブリッシュすればよい。再配信用トピックとしては、自装置と、依頼先のエッジサーバ３００と、再配信先のデバイス２００との組合せに応じた再配信用トピックが適用される。

次に、第１ブローカ４００のメッセージ配信部４０１は、再配信が依頼されたメッセージを受信する。そして、メッセージ配信部４０１は、再配信の依頼先のエッジサーバ３００に対して、依頼されたメッセージを配信する（ステップＳ１２）。

具体的には、前述のように、メッセージ配信部４０１は、メッセージを受信した再配信用トピックのサブスクライバとして記憶しているエッジサーバ３００に対して、依頼されたメッセージを配信すればよい。

そして、通信システム１は、依頼されたメッセージが依頼先のエッジサーバ３００によって受信されると、ステップＳ３からの動作を実行すればよい。

以上で、通信システム１の動作の説明を終了する。

次に、本発明の第１の実施の形態の効果について述べる。

本発明の第１の実施の形態としての通信システムは、多段に構成されるブローカを介したパブリッシュ／サブスクライブ通信において、移動可能なデバイスに対するメッセージの配信をより確実に行うことができる。

その理由について説明する。本実施の形態では、管理装置がデバイス宛のメッセージを第１ブローカに送信すると、第１ブローカのメッセージ配信部が、該当するデバイスの配信を担当中のエッジサーバにメッセージを配信する。そして、メッセージ送受信部が、受信したメッセージをデバイスに配信するため第２ブローカに送信する。そして、第２ブローカのメッセージ配信部が、該当するデバイスに対して、メッセージを配信する。そして、第２ブローカの配信状況管理部が、配信失敗を検出した場合、エッジサーバに対して、配信失敗を通知する。そして、配信失敗を通知されたエッジサーバでは、依頼先決定部が、配信に失敗したメッセージのデバイスへの再配信の依頼先となる他のエッジサーバを決定する。そして、再配信依頼部が、決定した他のエッジサーバに対して、再配信を依頼するメッセージを第１ブローカに送信する。そして、第１ブローカのメッセージ配信部は、再配信が依頼されたメッセージを受信すると、依頼先である他のエッジサーバに対して、該当するメッセージを配信する。そして、再配信が依頼されたメッセージを受信した他のエッジサーバは、そのメッセージを該当するデバイスへ配信するため第２ブローカに送信するからである。

これにより、本実施の形態は、管理装置から、デバイスに届くことが保証される送達保証レベルで送信されたメッセージが、そのデバイスへの配信を担当中のエッジサーバに配信されたにも関わらず、デバイスの移動によりロストするという事態を抑止できる。

（第２の実施の形態）
次に、本発明の第２の実施の形態について図面を参照して詳細に説明する。なお、本実施の形態の説明において参照する各図面において、本発明の第１の実施の形態と同一の構成および同様に動作するステップには同一の符号を付して本実施の形態における詳細な説明を省略する。

まず、本実施の形態としての通信システム２の機能ブロック構成を図５に示す。通信システム２は、本発明の第１の実施の形態としての通知システム１に対して次の点が異なる。すなわち、通信システム２は、エッジサーバ３００に替えてエッジサーバ３１０と、第１ブローカ４００に替えて第１ブローカ４１０と、第２ブローカ５００に替えて第２ブローカ５１０とを備える。さらに、通信システム２は、エリアマップ管理装置６１０を備える。なお、エリアマップ管理装置６１０およびエッジサーバ３１０は、ネットワークを介して通信可能に接続される。

ここで、通信システム２を構成する各装置は、図２を参照して説明した本発明の第１の実施の形態と同様のハードウェア要素によって構成可能である。また、エリアマップ管理装置６１０は、ＣＰＵ、メモリ、および、ネットワークインタフェースを含む装置によって構成可能である。ただし、通信システム２を構成する各装置のハードウェア構成は、上述の構成に限定されない。

まず、エリアマップ管理装置６１０について説明する。エリアマップ管理装置６１０は、エッジサーバ３１０間の位置関係を表すエリアマップ情報を記憶している。例えば、エリアマップ情報は、エッジサーバ３１０を識別する情報に対して、その周辺に位置するエッジサーバ３１０を識別する情報を関連付けた情報であってもよい。ただし、本実施の形態では、エッジサーバ３１０は、エリア毎に配信を担当しているとする。この場合、エリアマップ管理装置６１０は、あるエッジサーバ３１０を識別する情報に対して、そのエッジサーバ３１０と同一のエリアでの配信を担当する他のエッジサーバ３１０の識別情報を関連付けて記憶しないことが望ましい。

エリアマップ情報の一例を図６に示す。図６では、例えば、「Ａｒｅａ＃１：ＣＳＥ＃１」は、１つ目のエリアの配信を担当する１つ目のエッジサーバ３１０を表している。この例では、エッジサーバ３１０「Ａｒｅａ＃１：ＣＳＥ＃１」の周辺に位置するエッジサーバ３１０として、「Ａｒｅａ＃５：ＣＳＥ＃１０」、「Ａｒｅａ＃５：ＣＳＥ＃７」および「Ａｒｅａ＃８：ＣＳＥ＃２０」が記憶されている。なお、図６に示すエリアマップ情報は一例であり、エリアマップ情報の内容および形式は限定されない。

次に、エッジサーバ３１０の各機能ブロックについて説明する。

図５において、エッジサーバ３１０は、メッセージ送受信部３１１と、依頼先決定部３１２と、再配信依頼部３１３とを有する。

メッセージ送受信部３１１は、本発明の第１の実施の形態におけるメッセージ送受信部３０１と略同様に構成される。加えて、メッセージ送受信部３１１は、他のエッジサーバ３１０から再配信を依頼されたメッセージのデバイス２００への再配信が完了すると、他のエッジサーバ３１０に対して、再配信完了を通知する。なお、該当するメッセージの該当するデバイス２００への再配信が完了したことは、第２ブローカ５１０から通知される。第２ブローカ５１０から通知された再配信完了のさらなる通知先となる他のエッジサーバ３１０は、再配信が完了したメッセージについて自装置と同様に再配信が依頼されていた他のエッジサーバ３１０である。

なお、メッセージ送受信部３１１は、そのような他のエッジサーバ３１０に対する再配信完了の通知を、第１ブローカ４１０における再配信用トピックへパブリッシュすることにより実現してもよい。

依頼先決定部３１２は、第２ブローカ５１０から、デバイス２００へのメッセージの配信失敗を通知されると、デバイス２００へのメッセージの再配信の依頼先となる他のエッジサーバ３１０を、次のようにして決定する。

具体的には、依頼先決定部３１２は、エリアマップ管理装置６１０に記憶されたエリアマップ情報を参照することにより、自装置の周辺に位置する他のエッジサーバ３１０を、依頼先の候補として抽出する。なお、依頼先の候補としては、自装置が担当するエリアとは異なるエリアを担当するエッジサーバ３１０が抽出されることが望ましい。そして、依頼先決定部３１２は、抽出した候補に基づいて、依頼先のエッジサーバ３１０を決定する。

詳細には、依頼先決定部３１２は、依頼先の候補として抽出した各エッジサーバ３１０に対して、配信失敗を通知されたデバイス２００への接続履歴があるか否かを問い合わせる。接続履歴とは、例えば、配信を担当するエリア内でそのデバイス２００からの接続が検出された記録の履歴である。そして、依頼先決定部３１２は、問い合わせ結果に基づいて、それらの候補の中から、該当するデバイス２００の移動先の可能性があるエリアで配信を担当するエッジサーバ３１０を推定する。以降、移動先の可能性があるエリアで配信を担当するエッジサーバ３１０を、移動先サーバとも記載する。

そして、依頼先決定部３１２は、移動先サーバに関する情報に基づいて、新たな依頼先の候補を抽出する。具体的には、依頼先決定部３１２は、エリアマップ管理装置６１０に記憶されたエリアマップ情報を参照することにより、移動先サーバの周辺に位置する他のエッジサーバ３１０を、新たな依頼先の候補として抽出する。なお、新たな依頼先の候補としては、移動先サーバが担当するエリアとは異なるエリアを担当するエッジサーバ３１０が抽出されることが望ましい。そして、依頼先決定部３１２は、新たな候補である各エッジサーバ３１０に対して、配信失敗が通知されたデバイス２００への接続履歴があるか否かを問い合わせ、問い合わせ結果に基づいて、さらに新たな移動先サーバを推定することを繰り返す。

そして、依頼先決定部３１２は、繰り返し処理において所定条件が満たされた時点での移動先サーバに基づいて、依頼先のエッジサーバ３１０を決定する。例えば、所定条件とは、各繰り返し処理で推定される移動先サーバが所定回数以上連続して同一となることであってもよい。以降、所定条件が満たされた時点での移動先サーバであるエッジサーバ３１０を、移動先マスタサーバとも記載する。そして、依頼先決定部３１２は、移動先マスタサーバと、移動先マスタサーバの周辺に位置するエッジサーバ３１０とを、依頼先として決定する。なお、移動先マスタサーバの周辺に位置するエッジサーバ３１０は、エリアマップ管理装置６１０を参照することにより特定可能である。このとき、移動先マスタサーバの周辺に位置するエッジサーバ３１０としては、移動先マスタサーバが担当するエリアとは異なるエリアを担当するエッジサーバ３１０が特定されることが望ましい。

また、依頼先決定部３１２は、接続履歴の問い合わせを他のエッジサーバ３１０から受信した場合に、該当するデバイス２００への接続履歴があれば、その接続履歴に関する情報を返信する。本実施の形態では、依頼先決定部３１２は、自装置が配信を担当するエリアの第２ブローカ５１０に保持されるトピック管理テーブルを参照することにより、該当するデバイス２００に関する接続履歴を取得する。トピック管理テーブルについては後述する。また、接続履歴には、該当するデバイス２００の接続が検出された接続時刻が含まれているとする。そこで、依頼先決定部３１２は、他のエッジサーバ３１０からの接続履歴の問い合わせに対して、トピック管理テーブルから取得されるそのデバイス２００の接続時刻のうち、最も新しい接続時刻を、問い合わせ結果として返信する。

また、依頼先決定部３１２は、接続履歴の問い合わせを他のエッジサーバ３１０から受信すると、以降、監視モードとして動作してもよい。監視モードにおいて、依頼先決定部３１２は、問い合わせのあったデバイス２００の接続を新たに検出する度に、その接続時刻を、問い合わせ元のエッジサーバ３１０に返信する。なお、この場合、依頼先決定部３１２は、第１ブローカ４１０から監視モードの解除指示を表す情報を受信するまで、監視モードとして動作する。

なお、依頼先決定部３１２は、他のエッジサーバ３１０の依頼先決定部３１２との間での接続履歴の問い合わせおよび問い合せ結果の送受信を、第１ブローカ４１０における再配信用トピックへのパブリッシュおよびサブスクライブにより実現する。

再配信依頼部３１３は、第２ブローカ５１０から配信失敗が通知されると、配信失敗が検出されたデバイス２００宛のメッセージについて一括して、その再配信を依頼先のエッジサーバ３１０に依頼する。具体的には、再配信依頼部３１３は、第２ブローカ５１０から、該当するデバイス２００宛にまだ配信が完了していないメッセージを一括して取得する。そして、再配信依頼部３１３は、第１ブローカ４１０における再配信用トピックへ、一括して取得した各メッセージをパブリッシュすればよい。

また、再配信依頼部３１３は、再配信の依頼が完了すると、依頼が完了したことを、第２ブローカ５１０に通知する。

次に、第１ブローカ４１０の各機能ブロックについて説明する。

図５において、第１ブローカ４１０は、メッセージ配信部４１１と、重複制御部４１２とを有する。

メッセージ配信部４１１は、あるエッジサーバ３１０から再配信を依頼されたメッセージを、依頼先の各エッジサーバ３１０に配信する。また、メッセージ配信部４１１は、あるエッジサーバ３１０から送信されるあるデバイス２００への接続履歴の問い合わせを、依頼先の候補となる各エッジサーバ３１０のうち、後述の重複制御部４１２により抽出されたエッジサーバ３１０に対して配信する。また、メッセージ配信部４１１は、依頼先の候補となる各エッジサーバ３１０から返信される問い合わせ結果を、問い合わせ元のエッジサーバ３１０に対して配信する。また、メッセージ配信部４１１は、依頼先のエッジサーバ３１０から送信される再配信完了の通知を、同一のメッセージに関して再配信が依頼されていた各エッジサーバ３１０に対して配信する。なお、メッセージ配信部４１１は、これらの情報の送受信を、再配信用トピックを介して行う。

また、メッセージ配信部４１１は、再配信が依頼されたメッセージを受信すると、そのメッセージの宛先であるデバイス２００について前述の監視モードとなっているエッジサーバ３１０に対して、監視モードの解除を表す情報を配信する。これは、再配信が依頼されたメッセージについては、既に再配信の依頼先が決定されており、再配信の依頼先を決定するための監視モードは不要となるからである。具体的には、メッセージ配信部４１１は、再配信が依頼されたメッセージを受信すると、そのメッセージの宛先であるデバイス２００に関する問い合わせがそれまでにパブリッシュされた再配信用トピックへ、解除を指示するメッセージをパブリッシュすればよい。

重複制御部４１２は、エッジサーバ３１０から他のエッジサーバ３１０への接続履歴の問い合わせを、同一のエッジサーバ３１０に対して重複して送信しないよう制御する。具体的には、重複制御部４１２は、エッジサーバ３１０から接続履歴の問い合わせを受信すると、その問い合わせ先のエッジサーバ３１０の中から、同一の問い合わせを過去に送信していないエッジサーバ３１０を抽出し、メッセージ配信部４１１に通知する。

例えば、重複制御部４１２は、図７に示すような重複制御情報を保持していてもよい。図７の例では、重複制御情報は、配信に失敗しているメッセージを識別するリクエストＩＤに対して、そのメッセージの宛先であるデバイス２００の接続履歴を問い合わせ済のエッジサーバ３１０を識別する情報を関連付けたものである。重複制御部４１２は、接続履歴の問い合わせ先のエッジサーバ３１０の中から、重複制御情報に記録された問い合わせ済のエッジサーバ３１０を除外することにより、同一の問い合わせを過去に送信していないエッジサーバ３１０を抽出すればよい。

次に、第２ブローカ５１０の各機能ブロックについて説明する。

図５において、第２ブローカ５１０は、メッセージ配信部５１１と、配信状況管理部５１２と、グルーピング部５１３とを有する。

メッセージ配信部５１１は、本発明の第１の実施の形態におけるメッセージ配信部５０１と略同様に構成される。ただし、本実施の形態では、メッセージ配信部５１１は、メッセージ管理テーブルと、トピック管理テーブルと、配信状況テーブルとを用いて機能する例について説明する。

メッセージ管理テーブルは、自装置におけるトピックに受信したメッセージの内容を管理するテーブルである。メッセージ管理テーブルの一例を図８に示す。

図８において、リクエストＩＤは、メッセージを識別する情報である。図８の例では、例えば、リクエストＩＤ「０００１」のメッセージは、送達保証レベル（ＱｏＳ）としてＭＱＴＴに基づく１が設定されている。また、メッセージ管理テーブルは、各メッセージのコンテンツを含んでいる。メッセージ配信部５１１は、トピックにメッセージを受信すると、このメッセージ管理テーブルに、受信したメッセージに関する情報を保存する。メッセージ管理テーブルのメッセージは、そのメッセージの配信が完了するか、そのメッセージの再配信が他のエッジサーバ３１０に依頼されるまで、保存される。

トピック管理テーブルは、自装置に設定されているトピックおよびそのサブスクライバを関連付けた情報である。また、トピック管理テーブルは、そのサブスクライバが登録された時刻を含む。サブスクライバが登録された時刻は、サブスクライバが接続した時刻と同等であるとみなされるため、以降、サブスクライバが登録された時刻を、接続時刻とも記載する。トピック管理テーブルの一例を図９に示す。

図９において、例えば、トピック「／ｍ２ｍ／ｒｅｑ／Ａｒｅａ＃１：ＣＳＥ＃１／Ｄｅｖ＃１」は、「Ａｒｅａ＃１：ＣＳＥ＃１」で識別されるエッジサーバ３１０から「Ｄｅｖ＃１」で識別されるデバイス２００宛に配信されるメッセージ用のトピックである。また、図９では、このトピックのサブスクライバとして、「Ｄｅｖ＃１」で識別されるデバイス２００が関連付けられている。また、「Ｄｅｖ＃１」で識別されるデバイス２００がこのトピックのサブスクライバとして登録された接続時刻は、「２０１６／０１／１５ １０：０５」となっている。メッセージ配信部５１１は、「Ｄｅｖ＃１」で識別されるデバイス２００の接続を検出した際に、このトピック、そのサブスクライバおよび接続時刻を、トピック管理テーブルに保存してもよい。また、メッセージ配信部５１１は、エッジサーバ３１０からの接続履歴の問い合わせに応じて、トピック管理テーブルにおいて、該当するデバイス２００の接続時刻を検索して返信する。

配信状況テーブルは、自装置のトピックへ受信したメッセージの配信状況を記憶するテーブルである。配信状況テーブルの一例を図１０に示す。

図１０において、例えば、１行目は、リクエストＩＤ「０００１」のメッセージについて、トピックが「／ｍ２ｍ／ｒｅｑ／Ａｒｅａ＃１：ＣＳＥ＃１／Ｄｅｖ＃１」であり、「Ｄｅｖ＃１」のデバイス２００に対して、配信が完了したことを表している。例えば、メッセージ配信部５１１は、メッセージの配信または再送を実行する度に、配信状況テーブルを更新してもよい。

図８〜図１０に示した各種の情報は、第２ブローカ５１０における他の各機能ブロックによっても利用される。

グルーピング部５１３は、自装置から配信されるメッセージのうち、指定されたデバイス２００に対して配信されるメッセージを一括して抽出する。具体的には、グルーピング部５１３は、例えば、上述のトピック管理テーブルおよびメッセージ管理テーブルを参照してもよい。その場合、グルーピング部５１３は、トピック管理テーブルにおいて、指定されたデバイス２００がサブスクライバとして記憶されているトピックを抽出する。そして、グルーピング部５１３は、上述のメッセージ管理テーブルから、抽出したトピックのメッセージを一括して抽出すればよい。

配信状況管理部５１２は、本発明の第１の実施の形態における配信状況管理部５０２と略同様に構成される。加えて、配信状況管理部５１２は、メッセージのデバイス２００への配信の失敗を検出すると、そのデバイス２００に対して配信されるメッセージを、グルーピング部５１３を用いて抽出する。そして、配信状況管理部５１２は、抽出したメッセージについて、そのデバイス２００への再送を停止するようメッセージ配信部５１１を制御する。

また、配信状況管理部５１２は、配信の失敗が検出されたメッセージの宛先となっているデバイス２００についてグルーピング部５１３を用いて抽出したメッセージを、エッジサーバ３１０の再配信依頼部３１３からの問い合わせに応じて返信する。

また、配信状況管理部５１２は、エッジサーバ３１０の再配信依頼部３１３によって他のエッジサーバ３１０に対して再配信の依頼が完了したメッセージを、上述のメッセージ管理テーブルから削除する。なお、配信状況管理部５１２は、エッジサーバ３１０の再配信依頼部３１３から、依頼の完了を通知されることにより、該当するメッセージの削除を行う。

以上のように構成された通信システム２の動作について、図面を参照して説明する。

まず、通信システム２の動作の概略を図１１に示す。なお、以下の動作の説明では、本発明の第１の実施の形態における動作の説明と同様に、メッセージには、パブリッシュ／サブスクライブ通信における送達保証レベルとして、送信先に届くことが保証されるレベルが設定されているものとする。送達保証レベルとして、送信先に届くことが保証されないレベルが設定されたメッセージの場合の動作については、図１１のステップＳ４で動作が終了するため、説明を省略する。

まず、通信システム２は、ステップＳ１〜ステップＳ９まで、本発明の第１の実施の形態と同様に動作する。これにより、管理装置１００によってデバイス２００宛に送信されたメッセージは、第２ブローカ５１０によってデバイス２００に対して配信され、配信に失敗した場合、配信失敗がエッジサーバ３１０に通知される。

また、第２ブローカ５１０の配信状況管理部５１２は、ステップＳ８で配信の失敗を通知すると、次に、配信失敗時の処理を実行する（ステップＳ１１１）。このステップの詳細については後述する。

次に、配信状況管理部５１２は、配信が成功したメッセージ、または、配信に失敗して他のエッジサーバ３１０への再配信の依頼が完了したメッセージを、メッセージ管理テーブルから削除する（ステップＳ１１２）。なお、再配信の依頼の完了は、後述のステップＳ１２２において通知される。

また、配信失敗を通知されたエッジサーバ３１０では、依頼先決定部３１２は、該当するメッセージのデバイス２００への再配信の依頼先を決定する処理を実行する（ステップＳ１２１）。このステップの詳細については後述する。

次に、再配信依頼部３１３は、決定した依頼先のエッジサーバ３１０に対して再配信を依頼するメッセージを、第１ブローカ４１０に送信する（ステップＳ１２２）。このステップの詳細については後述する。

次に、第１ブローカ４１０のメッセージ配信部４１１は、再配信が依頼されたメッセージを、依頼先のエッジサーバ３１０に対して配信する（ステップＳ１３１）。このステップの詳細については後述する。

以上で、通信システム２の動作の概略の説明を終了する。

次に、ステップＳ１１１において、第２ブローカ５１０が配信失敗時に実行する処理の詳細を、図１２に示す。

図１２では、まず、第２ブローカ５１０の配信状況管理部５１２は、グルーピング部５１３を用いて、自装置から配信されるメッセージのうち、配信に失敗したメッセージの宛先であるデバイス２００に配信されるメッセージを一括して抽出する（ステップＡ１１）。

次に、配信状況管理部５１２は、一括して抽出されたメッセージへの配信を停止するよう、メッセージ配信部５１１を制御する（ステップＡ１２）。

次に、配信状況管理部５１２は、一括して抽出されたメッセージを、配信に失敗したメッセージの配信元であるエッジサーバ３１０に対して送信する（ステップＡ１３）。なお、このステップは、エッジサーバ３１０からの要求（後述の図１５におけるステップＣ１１）に応じて実行されてもよい。

以上で、第２ブローカ５１０は、配信失敗時の動作を終了する。

次に、ステップＳ１２１において、エッジサーバ３１０が依頼先を決定する処理の詳細を、図１３に示す。依頼先を決定する処理では、エッジサーバ３１０は、他のエッジサーバ３１０との間で、第１ブローカ４１０を介して情報を送受信することにより、依頼先を決定する。

図１３では、まず、エッジサーバ３１０の依頼先決定部３１２は、自装置を移動先サーバとする（ステップＢ１１）。

次に、依頼先決定部３１２は、エリアマップ管理装置６１０を参照することにより、移動先サーバの周辺に位置する他のエッジサーバ３１０を、依頼先の候補として取得する（ステップＢ１２）。

次に、依頼先決定部３１２は、依頼先の候補の各エッジサーバ３１０に対して、配信に失敗したメッセージの宛先であるデバイス２００の接続履歴を問い合わせるメッセージを、第１ブローカ４１０に送信する（ステップＢ１３）。前述のように、依頼先決定部３１２は、第１ブローカ４１０における再配信用トピックに、問い合わせのメッセージをパブリッシュすればよい。

次に、第１ブローカ４１０のメッセージ配信部４１１は、問い合わせのメッセージを受信する。そして、重複制御部４１２は、問い合わせ先となる各エッジサーバ３１０のうち、過去に同一の問い合わせのメッセージを配信していないエッジサーバ３１０を抽出する（ステップＢ１４）。

ここで、問い合わせのメッセージには、配信に失敗したメッセージを識別するリクエストＩＤが含まれている。また、重複制御部４１２は、前述の重複制御情報を記憶している。そこで、重複制御部４１２は、問い合わせのメッセージを受信した再配信用トピックのサブスクライバとして記憶しているエッジサーバ３１０のうち、重複制御情報において該当するリクエストＩＤに関連付けられた情報が示すエッジサーバ３１０を除外すればよい。

次に、第１ブローカ４１０のメッセージ配信部４１１は、ステップＢ１４で抽出した各エッジサーバ３１０に対して、問い合わせのメッセージを配信する（ステップＢ１５）。

次に、重複制御部４１２は、問い合わせのメッセージの配信に応じて、重複制御情報を更新する（ステップＢ１６）。

具体的には、重複制御部４１２は、配信に失敗したメッセージを識別するリクエストＩＤに関連付けた重複制御情報において、問い合わせのメッセージを配信したエッジサーバ３１０の識別情報を追加して関連付ければよい。なお、重複制御部４１２は、該当するリクエストＩＤの重複制御情報がまだなければ、新規に作成すればよい。

次に、依頼先の候補となる他のエッジサーバ３１０において、依頼先決定部３１２は、問い合わせのメッセージを受信する。そして、依頼先決定部３１２は、該当するデバイス２００への接続履歴を検索する（ステップＢ１７）。

具体的には、依頼先決定部３１２は、自装置が配信を担当するエリアの第２ブローカ５１０にトピック管理テーブルの内容を問い合わせることにより、その接続履歴を検索すればよい。

ここで、接続履歴がある場合（ステップＢ１８でＹｅｓ）、依頼先決定部３１２は、問い合わせ結果として接続時刻を含む情報を、第１ブローカ４１０に送信する（ステップＢ１９）。前述のように、依頼先決定部３１２は、第１ブローカ４１０の再配信用トピックへ、問い合わせ結果のメッセージをパブリッシュすればよい。

次に、他のエッジサーバ３１０において、依頼先決定部３１２は、監視モードとして動作する（ステップＢ２０）。監視モードの詳細については、後述する。

次に、第１ブローカ４１０のメッセージ配信部４１１は、受信した問い合わせ結果を、問い合わせ元のエッジサーバ３１０に配信する（ステップＢ２１）。

次に、問い合わせ元のエッジサーバ３１０において、依頼先決定部３１２は、依頼先の候補となる各エッジサーバ３１０から受信した問い合わせ結果に基づいて、新たな移動先サーバを推定する（ステップＢ２２）。例えば、依頼先決定部３１２は、最新の接続時刻を含む問い合わせ結果が得られたエッジサーバ３１０を、新たな移動先サーバとして推定してもよい。

次に、依頼先決定部３１２は、移動先サーバの更新が停止したか否かを判断する（ステップＢ２３）。例えば、依頼先決定部３１２は、ステップＢ２２で推定された移動先サーバが、所定回数以上更新されなかった場合に、更新が停止したと判断してもよい。

ここで、移動先サーバの更新が停止していない場合、依頼先決定部３１２は、ステップＢ１２からの処理を繰り返す。

一方、移動先サーバの更新が停止した場合について説明する。この場合、依頼先決定部３１２は、この時点での移動先サーバを、移動先マスタサーバとする。そして、依頼先決定部３１２は、エリアマップ管理装置６１０を参照することにより、移動先マスタサーバの周辺に位置する他のエッジサーバ３１０を取得する（ステップＢ２４）。

そして、依頼先決定部３１２は、移動先マスタサーバと、その周辺に位置する他のエッジサーバ３１０とを、再配信の依頼先のエッジサーバ３１０として決定する（ステップＢ２５）。

以上で、エッジサーバ３１０は、再配信の依頼先を決定する動作を終了する。

次に、ステップＢ２０におけるエッジサーバ３１０の監視モードとしての動作を、図１４を参照して説明する。

図１４では、まず、依頼先決定部３１２は、問い合わせの対象であるデバイス２００の接続を検出したか否かを判断する（ステップＢ２０１）。

前述のように、依頼先決定部３１２は、第２ブローカ５１０にトピック管理テーブルの内容を問い合わせることにより、接続を検出したか否かを判断すればよい。

ここで、デバイス２００の接続を検出した場合、依頼先決定部３１２は、その接続時刻を含む問い合わせ結果を、第１ブローカ４１０に送信する（ステップＢ２０２）。

前述のように、依頼先決定部３１２は、第１ブローカ４１０の再配信用トピックに、問い合わせ結果のメッセージをパブリッシュすればよい。

次に、依頼先決定部３１２は、監視モードが解除されたか否かを判断する（ステップＢ２０３）。

なお、ステップＢ２０１で、デバイス２００の接続が検出されない場合にも、依頼先決定部３１２は、このステップを実行する。

ここで、監視モードが解除されていなければ、依頼先決定部３１２は、ステップＢ２０１からの動作を繰り返す。一方、監視モードが解除されていれば、エッジサーバ３１０は、監視モードの動作を終了する。

以上で、エッジサーバ３１０における監視モードの動作の説明を終了する。

次に、ステップＳ１２２およびステップＳ１３１において、エッジサーバ３１０および第１ブローカ４１０が、配信に失敗したメッセージの再配信を依頼し配信する動作の詳細を、図１５に示す。

図１５では、まず、エッジサーバ３１０の再配信依頼部３１３は、配信に失敗したメッセージと同一の宛先であるデバイス２００宛のメッセージを、第２ブローカ５１０から取得する（ステップＣ１１）。なお、再配信依頼部３１３は、第２ブローカ５１０に対して、前述した図１２のステップＡ１３の実行を要求することにより、このステップを実行してもよい。

次に、再配信依頼部３１３は、依頼先として決定された他の各エッジサーバ３１０に対して、ステップＣ１１で受信したメッセージのそれぞれを、その再配信を依頼するため第１ブローカ４１０に送信する（ステップＣ１２）。

前述のように、再配信依頼部３１３は、第１ブローカ４１０における再配信用トピックへ、該当するメッセージのそれぞれをパブリッシュすればよい。

次に、再配信依頼部３１３は、再配信の依頼が完了したことを、第２ブローカ５１０に対して通知する（ステップＣ１３）。

次に、第１ブローカ４１０の重複制御部４１２は、受信されたメッセージに関する重複制御情報を削除する（ステップＣ１４）。これは、これらのメッセージの宛先のデバイス２００については、接続履歴の問い合わせの重複制御を行う必要がなくなるからである。

次に、メッセージ配信部４１１は、このメッセージの宛先のデバイス２００について接続履歴の問い合わせを配信済みの各エッジサーバ３１０に対して、監視モードの解除を通知する（ステップＣ１５）。

例えば、メッセージ配信部４１１は、自装置における再配信用トピックへ解除指示のメッセージをパブリッシュすることにより、該当する各エッジサーバ３１０に対して監視モードの解除を通知してもよい。

監視モードの解除を通知されたエッジサーバ３１０では、図１４のＢ２０３でＹｅｓとなり、監視モードが終了する。

次に、メッセージ配信部４１１は、再配信が依頼されたメッセージを、その依頼先となる各エッジサーバ３１０に配信する（ステップＣ１６）。

以上で、図１１のステップＳ１２２およびステップＳ１３１における動作の詳細な説明を終了する。

次に、図１１のステップＳ１３１の動作に続いて、通信システム２がメッセージを再配信する動作の詳細を図１６に示す。

図１６では、まず、再配信が依頼されたエッジサーバ３１０において、メッセージ送受信部３１１は、再配信が依頼されたメッセージを、第２ブローカ５１０に送信する（ステップＤ１１）。

具体的には、メッセージ送受信部３１１は、第２ブローカ５１０におけるデバイス２００に関連するトピックへ、再配信が依頼されたメッセージをパブリッシュすればよい。

次に、第２ブローカ５１０のメッセージ配信部５１１は、再配信が依頼されたメッセージを、デバイス２００に配信する（ステップＤ１２）。

ここで、配信が成功しなかった場合（ステップＳ５でＮｏ）、第２ブローカ５１０は、図１１を参照して説明したステップＳ６〜Ｓ７を実行する。これにより、第２ブローカ５１０は、メッセージの再送を行い、配信に失敗したか否かを判断する。

ステップＳ７において、配信に失敗したと判断した場合、通信システム２は、図１１に示したステップＳ８以降と同様に動作する。ただし、配信の失敗を通知された依頼元のエッジサーバ３１０は、自装置が、移動先マスタサーバであった場合に、ステップＳ９以降を実行するようにする。もし、配信の失敗を通知された依頼元のエッジサーバ３１０が、移動先マスタサーバの周辺のエッジサーバ３１０であった場合、ステップＳ９以降を実行せずに、動作を終了してもよい。

一方、ステップＳ５で再配信が成功したと判断した場合、または、ステップＳ７で配信に失敗していない（すなわち、再送により再配信に成功した）と判断した場合、メッセージ配信部５１１は、次のように動作する。この場合、メッセージ配信部５１１は、配信元のエッジサーバ３１０に対して、再配信完了を通知する（ステップＤ１３）。

そして、メッセージ配信部５１１は、再配信を完了したメッセージを、メッセージ管理テーブルから削除する（ステップＤ１４）。

次に、エッジサーバ３１０において、第２ブローカ５１０から再配信完了の通知を受けた場合（ステップＤ１５でＹｅｓ）、再配信依頼部３１３は、他のエッジサーバ３１０に対して、再配信完了を通知する（ステップＤ１６）。

ここで、再配信完了の通知先となる他のエッジサーバ３１０は、自装置と共に、該当するメッセージの再配信を依頼されたエッジサーバ３１０である。例えば、再配信完了の通知を第２ブローカ５１０から受けたエッジサーバ３１０において、再配信依頼部３１３は、自装置と共に再配信の依頼先となった移動先マスタサーバを特定する。なお、自装置が移動先マスタサーバである場合もある。そして、再配信依頼部３１３は、移動先マスタサーバおよびその周辺に位置するエッジサーバ３１０のうち自装置以外を表す情報を、エリアマップ管理装置６１０を参照して取得する。取得された情報の示すエッジサーバ３１０は、自装置と共に同一のメッセージについて再配信を依頼されたエッジサーバ３１０である。そして、再配信依頼部３１３は、これらのエッジサーバ３１０に対して、再配信完了を通知すればよい。

なお、エッジサーバ３１０間での再配信完了の通知は、第１ブローカ４１０における再配信用トピックを介して行われる。

一方、エッジサーバ３１０において、他のエッジサーバ３１０から再配信完了の通知を受けた場合（ステップＤ１５でＮｏ、Ｄ１７でＹｅｓ）について説明する。この場合、再配信依頼部３１３は、再配信が依頼されていたメッセージの配信のとりやめを、第２ブローカ５１０に通知する（ステップＤ１８）。

そして、第２ブローカ５１０において、メッセージ配信部５１１は、該当するメッセージを削除して、配信をとりやめる（ステップＤ１４）。

以上で、通信システム２は、メッセージを再配信する動作を終了する。

次に、通信システム２の動作の具体例を、図１７〜図２１を用いて説明する。

図１７〜図２１において、デバイス２００が移動し得る空間的な範囲は、Ｎ個のエリア１〜エリアＮに分割されている。Ｎは正の整数である。また、エリアｉ（ｉ＝１〜Ｎ）には、そのエリア内に存在するデバイス２００への配信を担当するエッジサーバ３１０が少なくとも１つ設けられている。なお、エリアによっては、複数のエッジサーバ３１０が設けられている場合もある。また、エリアｉには、そのエリアのエッジサーバ３１０からそのエリア内に存在するデバイス２００に向けて配信されるメッセージを中継する第２ブローカ５１０が少なくとも１つ設けられている。なお、エリアによっては、複数の第２ブローカ５１０が設けられている場合もある。

また、図１７〜図２１において、１つの管理装置１００が、デバイス２００を管理している。また、管理装置１００および各エリアのエッジサーバ３１０の間を接続するため、１つの第１ブローカ４１０が設けられている。

また、この具体例において、デバイス２００上には、各種のセンサが搭載されている。デバイス２００は、自装置に搭載されたセンサに関連するトピックのメッセージを受信するよう構成される。つまり、デバイス２００は、自装置が存在するエリアの第２ブローカ５１０に接続し、自装置および自装置に搭載されたセンサに関連するトピックのサブスクライブを登録する。

このような具体例において、管理装置１００が、あるデバイス２００に対してそのデバイス２００上のあるセンサを管理するためのメッセージを配信することを想定する。配信対象のデバイス２００を、デバイス２００Ａと呼ぶことにする。デバイス２００Ａは、当初、エリア１に存在しているものとする。対象のセンサを、センサａと呼ぶことにする。また、該当するメッセージを、メッセージｍ１と呼ぶことにする。

（１）まず、図１７において、管理装置１００は、デバイス２００Ａに対してセンサａを管理するためのメッセージｍ１を、第１ブローカ４１０を介して、エリア１のエッジサーバ３１０に対して配信する（図１１のステップＳ１〜Ｓ２）。

なお、ここでは、管理装置１００は、デバイス２００Ａが存在するエリアがエリア１であることを表す情報を、外部から取得したものとする。また、通信プロトコルとしてＭＱＴＴが採用されており、メッセージｍ１は、送達保証レベルとして１が設定されて送信されたものとする。

（２）ここで、エリア１のエッジサーバ３１０は、自装置が担当するエリア１でデバイス２００Ａの接続を検出していたため、デバイス２００Ａに関連するトピックのサブスクライブを第１ブローカ４１０に登録してあるものとする。そこで、エリア１のエッジサーバ３２０は、メッセージｍ１を受信する。

（３）次に、デバイス２００Ａが移動し、エリアＡに存在しなくなったとする。ところが、エリア１のエッジサーバ３１０は、この段階では、エリアＡにデバイス２００Ａが存在しないことを検出していない。

（４）そこで、エリア１のエッジサーバ３１０は、メッセージｍ１をデバイス２００Ａに配信するため、第２ブローカ５１０に送信する（ステップＳ３）。ここで、メッセージｍ１は、送達保証レベルとして１が設定されて送信される。

（５）次に、第２ブローカ５１０において、メッセージ配信部５１１は、メッセージｍ１を受信し、メッセージ管理テーブルに保存する。そして、メッセージ配信部５１１は、メッセージｍ１のデバイス２００Ａへの配信を行う（ステップＳ４）。ところが、エリアＡにデバイス２００Ａが存在しないため、メッセージ配信部５１１は、メッセージｍ１のデバイス２００Ａへの再送を試みる（Ｓ５でＮｏ、Ｓ６）。

（６）次に、デバイス２００Ａは、他のエリアを通過しながら移動し、エリアＮで移動を停止する。そして、デバイス２００Ａは、エリアＮの第２ブローカ５１０に、自装置上のセンサに関連するトピックのサブスクライブを登録したものとする。

（７）次に、図１８において、管理装置１００は、デバイス２００Ａ上の他のセンサｂおよびセンサｃをそれぞれ管理するためのメッセージｍ２およびｍ３を、さらに配信する。この時点でも、管理装置１００は、デバイス２００Ａがエリア１に存在しているという情報を取得しているものとする。そこで、管理装置１００は、メッセージｍ２およびｍ３を、第１ブローカ４１０を介して、エリア１のエッジサーバ３１０に向けて配信する（図１１のステップＳ１〜Ｓ２）。ここで、メッセージｍ２およびｍ３は、それぞれ送達保証レベルとして１が設定されて送信される。

（８）メッセージｍ２およびｍ３についても、それぞれ上述した（２）〜（４）と同様に各機能ブロックが動作し、エリア１の第２ブローカ５１０では、メッセージ管理テーブルに、メッセージｍ２およびｍ３が追加されていく。そして、エリア１の第２ブローカ５１０の配信状況管理部５１２は、メッセージｍ１について、再送回数等に基づいて、配信に失敗したと判断する（ステップＳ７でＹｅｓ）。

（９）そこで、配信状況管理部５１２は、エリア１のエッジサーバ３１０に配信失敗を通知する（ステップＳ８）。

（１０）また、エリア１の第２ブローカ５１０の配信状況管理部５１２は、グルーピング部５１３を用いて、配信の失敗を検出したデバイス２００Ａ宛のメッセージｍ１〜ｍ３を一括して抽出する（ステップＳ１１１、図１２のステップＡ１１）。

（１１）そして、エリア１の第２ブローカ５１０の配信状況管理部５１２は、抽出したメッセージｍ１〜ｍ３の配信処理を停止するよう、メッセージ配信部５１１を制御する（ステップＡ１２）。

（１２）次に、図１９において、配信失敗が通知されたエリア１のエッジサーバ３１０の依頼先決定部３１２は、エリアマップ管理装置６１０に問い合わせを行う。これにより、依頼先決定部３１２は、依頼先の候補となる他のエッジサーバ３１０を特定する（図１１のステップＳ１２１、図１３のステップＢ１２）。

（１３）次に、エリア１のエッジサーバ３１０の依頼先決定部３１２は、依頼先の候補となる他のエッジサーバ３１０に対して、デバイス２００Ａの接続履歴の問い合わせる（ステップＢ１３）。このとき、問い合わせの送受信は、第１ブローカ４１０の再配信用トピックを介して行われる。

（１４）次に、第１ブローカ４１０の重複制御部４１２は、重複制御情報を参照し、対象のメッセージｍ１の宛先であるデバイス２００Ａに関して接続履歴を問い合わせ済みのエッジサーバ３１０を、問い合わせ先から除外する（ステップＢ１４）。そして、メッセージ配信部４１１は、問い合わせのメッセージを、問い合わせ先へ配信する（ステップＢ１５）。そして、重複制御部４１２は、重複制御情報に、対象のメッセージｍ１の宛先であるデバイス２００Ａに関する問い合わせ先を追加して記録する（ステップＢ１６）。

（１５）次に、図２０において、問い合わせを受け取った他のエリアのエッジサーバ３１０の依頼先決定部３１２は、デバイス２００Ａの接続履歴を、第２ブローカ５１０のトピック管理テーブルから取得する（ステップＢ１７）。そして、他のエリアのエッジサーバ３１０の依頼先決定部３１２は、該当するデバイス２００Ａの接続履歴が得られれば、接続時刻を問い合わせ結果として返信する。接続時刻の返信は、第１ブローカ４１０の再配信用トピックを介して行われる（ステップＢ１８でＹｅｓ、Ｂ１９）。

（１６）また、問い合わせのメッセージを受け取った他のエリアのエッジサーバ３１０の依頼先決定部３１２は、監視モードとなり、所定間隔でデバイス２００Ａの接続履歴をチェックする。そして、他のエリアのエッジサーバ３１０の依頼先決定部３１２は、新たにデバイス２００Ａの接続履歴が得られた場合は、その接続時刻を問い合わせ結果として返信する（ステップＢ２０、Ｂ２１）。

（１７）次に、問い合わせ結果を受信したエリア１のエッジサーバ３１０の依頼先決定部３１２は、問い合わせ結果に基づいて、依頼先の候補の中から移動先サーバを推定する。例えば、移動先サーバとして、エリア３のエッジサーバ３１０が推定されたとする（ステップＢ２２）。

（１８）エリア１のエッジサーバ３１０の依頼先決定部３１２は、移動先サーバであるエリア３のエッジサーバ３１０に基づき新たな依頼先の候補となる他のエッジサーバ３１０を、エリアマップ管理装置６１０に問い合わせることにより特定する。そして、（１３）からの動作が繰り返される（ステップＢ１２〜Ｂ２２）。

そして、繰り返された（１７）において、移動先サーバとして、エリアＮのエッジサーバ３１０が推定されることが所定回数連続して続いたとする（ステップＢ２３でＹｅｓ）。

（１９）そこで、エリア１のエッジサーバ３１０における依頼先決定部３１２は、エリアＮのエッジサーバ３１０を移動先マスタサーバとする。そして、依頼先決定部３１２は、エリアＮのエッジサーバ３１０と、その周辺のエッジサーバ３１０とを、再配信の依頼先として決定する。周辺のエッジサーバ３１０は、エリアＮ−２およびエリアＮ−１のエッジサーバ３１０であったとする（ステップＢ２４、Ｂ２５）。

（２０）次に、図２１において、エリア１のエッジサーバ３１０の再配信依頼部３１３は、再配信を依頼するため、第２ブローカ５１０から、デバイス２００Ａ宛のメッセージｍ１〜ｍ３を一括して取得する（図１１のステップＳ１２２、図１５のステップＣ１１）。

（２１）次に、エリア１のエッジサーバ３１０における再配信依頼部３１３は、依頼先として決定したエリアＮ、Ｎ−１、Ｎ−２の各エッジサーバ３１０に対して、一括して取得したメッセージｍ１〜ｍ３のそれぞれの再配信を依頼する（ステップＣ１２）。再配信の依頼は、第１ブローカ４１０における再配信用トピックを介して行われる。そして、再配信依頼部３１３は、再配信の依頼の完了を、第２ブローカ５１０に通知する（ステップＣ１３）。

（２２）再配信の依頼の完了を通知された第２ブローカ５１０では、配信状況管理部５１２が、メッセージｍ１〜ｍ３をメッセージ管理テーブルから削除する（図１１のステップＳ１１２）。

（２３）また、再配信が依頼されたメッセージを受信した第１ブローカ４１０のメッセージ配信部４１１は、メッセージｍ１に関連する重複制御情報を削除する（図１１のステップＳ１３１、図１５のステップＣ１４）。

（２４）また、第１ブローカ４１０のメッセージ配信部４１１は、メッセージｍ１の宛先であるデバイス２００Ａの接続履歴をそれまでに問い合わせていた各エッジサーバ３１０に対して、監視モードの解除を指示する情報を配信する（ステップＣ１５）。

（２５）また、第１ブローカ４１０のメッセージ配信部４１１は、エリアＮ、Ｎ−１、Ｎ−２の各エッジサーバ３１０に対して、依頼されたメッセージｍ１〜ｍ３をそれぞれ配信する（ステップＣ１６）。

（２６）そして、エリアＮ、Ｎ−１、Ｎ−２の各エッジサーバ３１０のメッセージ送受信部３１１は、メッセージｍ１〜ｍ３のそれぞれを、各エリアの第２ブローカ５１０を介してデバイス２００Ａに配信する（図１６のステップＤ１１、Ｄ１２）。

（２７）そして、エリアＮにおいて、メッセージｍ１〜ｍ３のデバイス２００Ａへの配信が成功する。そこで、エリアＮのエッジサーバ３１０は、第２ブローカ５１０から再配信完了の通知を受ける（ステップＤ１３、Ｄ１５でＹｅｓ）。そして、エリアＮのエッジサーバ３１０において再配信依頼部３１３は、自装置と同様にメッセージｍ１〜ｍ３の再配信を依頼されていた他のエリアＮ−１、Ｎ−２の各エッジサーバ３１０に対して、再配信完了を通知する（ステップＤ１６）。

（２８）そして、エリアＮ−１、Ｎ−２の各エッジサーバ３１０において再配信依頼部３１３は、それぞれのエリアの第２ブローカ５１０に対して、メッセージｍ１〜ｍ３の配信のとりやめを通知する（ステップＤ１７でＹｅｓ、Ｄ１８）。

（２９）また、エリアＮにおける第２ブローカ５１０では、配信状況管理部５１２は、メッセージｍ１〜ｍ３の配信が完了したため、これらのメッセージをメッセージ管理テーブルから削除する。また、エリアＮ−２、Ｎ−１における第２ブローカ５１０では、配信状況管理部５１２は、メッセージｍ１〜ｍ３の配信がとりやめになったため、メッセージ管理テーブルから、これらのメッセージを削除する（ステップＤ１４）。

以上で、具体例の説明を終了する。

次に、本発明の第２の実施の形態の効果について述べる。

本発明の第２の実施の形態としての通信システムは、多段に構成されるブローカを介したパブリッシュ／サブスクライブ通信において、移動可能なデバイスに対するメッセージの配信をさらに確実に行うことができる。

その理由について説明する。本実施の形態は、本発明の第１の実施の形態と同様に構成されることに加えて、次の構成を備える。すなわち、エッジサーバの依頼先決定部が、エリアマップ情報を参照することにより、自装置の周辺に位置するエッジサーバを、依頼先の候補として抽出する。そして、依頼先決定部が、依頼先の候補となる他のエッジサーバに対して、該当するデバイスへの接続履歴があるか否かを問い合わせ、問い合わせ結果に基づいて、それらの候補の中から移動先サーバを推定する。そして、依頼先決定部が、移動先サーバの周辺に位置するエッジサーバを新たな依頼先の候補として抽出する。そして、依頼先決定部が、依頼先の候補となる他のエッジサーバに対して、上述した問い合わせを行い、問い合わせ結果に基づいて、それらの候補の中から移動先サーバを推定することを繰り返す。そして、依頼先決定部が、所定条件が満たされた時点で推定されている移動先サーバである移動先マスタサーバと、移動先マスタサーバの周辺のエッジサーバとを、再配信の依頼先として決定するからである。

このように、本実施の形態は、エッジサーバが配信を担当するエリア内に存在したはずのデバイスが移動した場合に、移動したデバイスへの配信が可能な他のエッジサーバを、エリアマップ情報に基づく繰り返し処理により精度よく推定する。その結果、本実施の形態は、管理装置から、デバイスに届くことが保証される送達保証レベルで送信されたメッセージを、移動したデバイスにもより確実に配信することができる。

また、本実施の形態は、第２ブローカにおいて保存するメッセージ量を抑制することができる。

その理由について説明する。本実施の形態では、第２ブローカの配信状況管理部が、配信に失敗したと判断したメッセージの再配信が他のエッジサーバに依頼されると、そのメッセージをメモリから削除するからである。

また、本実施の形態は、第２ブローカの負荷を軽減することができる。

その理由について説明する。本実施の形態では、第２ブローカのグルーピング部が、配信に失敗したメッセージと同一の宛先となるデバイス宛のメッセージを一括して抽出する。そして、配信状況管理部が、抽出されたメッセージの配信を停止するからである。これにより、本実施の形態は、デバイスに対するメッセージの配信がデバイスの移動により失敗する場合、そのデバイスに対する第２ブローカからのメッセージの配信を一括して停止することができる。その結果、第２ブローカの負荷が軽減される。

また、本実施の形態は、第１ブローカを介したエッジサーバ間の通信量を抑制することができる。

その理由について説明する。本実施の形態では、エッジサーバの依頼先決定部が、配信に失敗したメッセージの再配信の依頼先を決定するために、接続履歴の問い合わせ先となる候補を、エリアマップ情報を参照することにより絞り込むからである。これにより、問い合わせ対象となる他のエッジサーバの数を抑制することができる。さらに、第１ブローカの重複制御部が、配信に失敗したメッセージの再配信の依頼先を決定するために、エッジサーバ間で送受信される接続履歴の問い合わせのメッセージを、既に送信済のエッジサーバに対して重複して送信しないよう制御するからである。

（第３の実施の形態）
次に、本発明の第３の実施の形態について図面を参照して詳細に説明する。なお、本実施の形態の説明において参照する各図面において、本発明の第２の実施の形態と同一の構成および同様に動作するステップには同一の符号を付して本実施の形態における詳細な説明を省略する。

まず、本実施の形態としての通信システム３の機能ブロック構成を図２２に示す。図２２において、通信システム３は、本発明の第２の実施の形態としての通知システム２に対して次の点が異なる。すなわち、通信システム３は、エッジサーバ３１０に替えてエッジサーバ３２０と、エリアマップ管理装置６１０に替えてロケーション管理装置６２０とを備える。なお、ロケーション管理装置６２０およびエッジサーバ３２０は、ネットワークを介して通信可能に接続される。

ここで、通信システム３を構成する各装置は、図２を参照して説明した本発明の第１の実施の形態と同様のハードウェア要素によって構成可能である。また、ロケーション管理装置６２０は、ＣＰＵ、メモリ、および、ネットワークインタフェースを含む装置によって構成可能である。ただし、通信システム３を構成する各装置のハードウェア構成は、上述の構成に限定されない。

まず、ロケーション管理装置６２０について説明する。ロケーション管理装置６２０は、エッジサーバ３２０の空間的な位置を表すロケーション情報を記憶している。例えば、ロケーション情報の一例を図２３に示す。図２３では、ロケーション情報は、エッジサーバ３２０を識別するＩＤに対して、その位置情報を関連付けた情報である。なお、図２３に示すロケーション情報は一例であり、ロケーション情報の内容および形式は限定されない。

また、ロケーション管理装置６２０は、基準となるエッジサーバ３２０の識別情報を受信すると、そのエッジサーバ３２０の位置からの距離に基づき抽出した他のエッジサーバ３２０の識別情報を返却する。例えば、ロケーション管理装置６２０は、該当するエッジサーバ３２０の位置からの距離が短い順に所定個数までの他のエッジサーバ３２０を抽出してもよい。あるいは、ロケーション管理装置６２０は、該当するエッジサーバ３２０の位置からの距離が閾値以内の他のエッジサーバ３２０を抽出してもよい。なお、ロケーション情報に基づく他のエッジサーバ３２０の抽出基準は、これらに限らない。

次に、エッジサーバ３２０の機能ブロックについて説明する。

図２２において、エッジサーバ３２０は、本発明の第２の実施の形態におけるエッジサーバ３１０に対して、依頼先決定部３１２に替えて依頼先決定部３２２を有する点が異なる。

依頼先決定部３２２は、本発明の第２の実施の形態における依頼先決定部３１２と略同様に構成される。ただし、依頼先の候補の抽出処理の詳細が異なるよう構成される。

具体的には、依頼先決定部３２２は、配信に失敗したメッセージの宛先となるデバイス２００の接続履歴の問い合わせ先の候補を、ロケーション管理装置６２０に問い合わせることにより取得する。つまり、依頼先決定部３２２は、移動先サーバを推定する繰り返し処理において、自装置または移動先サーバの識別情報をロケーション管理装置６２０に送信する。そして、依頼先決定部３２２は、ロケーション管理装置６２０から返却された識別情報が示す他のエッジサーバ３２０を、移動先の候補とすればよい。

以上のように構成された通信システム３の動作について説明する。

通信システム３の動作は、図１１〜図１６を参照して説明した通信システム２の動作と略同様である。ただし、図１３におけるステップＢ１２およびＢ２４の動作の詳細が異なる。

ステップＢ１２において、依頼先決定部３２２は、ロケーション管理装置６２０に対して、移動先サーバの識別情報を送信する。そして、依頼先決定部３２２は、ロケーション管理装置６２０から返信された識別情報が示す他のエッジサーバ３２０を、依頼先の候補として取得する。

また、ステップＢ２４において、依頼先決定部３２２は、ロケーション管理装置６２０に対して、移動先マスタサーバの識別情報を送信する。そして、依頼先決定部３２２は、ロケーション管理装置６２０から返信された識別情報の示す他のエッジサーバ３２０を特定する。

以上で、通信システム３の動作の説明を終了する。

次に、本発明の第３の実施の形態の効果について述べる。

本発明の第３の実施の形態の効果は、本発明の第２の実施の形態の効果と略同様である。

ただし、その理由が若干異なる。本発明の第３の実施の形態では、エッジサーバの依頼先決定部が、エッジサーバの空間的な位置を示すロケーション情報に基づいて、配信に失敗したメッセージの再配信の依頼先の候補を決定するからである。

このため、本実施の形態は、デバイスの移動により配信に失敗したメッセージの再配信が可能なエッジサーバを、ロケーション情報に基づいてより精度よく推定し、メッセージの再配信をより確実に実行することができる。

また、本実施の形態は、配信に失敗したメッセージの再配信の依頼先を決定するために他のエッジサーバに対して行う接続履歴の問い合わせ先を、ロケーション情報に基づいて絞り込むため、エッジサーバ間の通信量を抑制することができる。

（第４の実施の形態）
次に、本発明の第４の実施の形態について図面を参照して詳細に説明する。なお、本実施の形態の説明において参照する各図面において、本発明の第２の実施の形態と同一の構成および同様に動作するステップには同一の符号を付して本実施の形態における詳細な説明を省略する。

まず、本実施の形態としての通信システム４の機能ブロック構成を図２４に示す。図２４において、通信システム４は、本発明の第２の実施の形態としての通知システム２に対して次の点が異なる。すなわち、通信システム４は、エッジサーバ３１０に替えてエッジサーバ３３０と、エリアマップ管理装置６１０に替えて移動先予測装置６３０とを備え、さらに、デバイス情報蓄積装置６４０を備える。なお、移動先予測装置６３０およびエッジサーバ３３０は、ネットワークを介して通信可能に接続される。また、移動先予測装置６３０およびデバイス情報蓄積装置６４０は、ネットワークを介して通信可能に接続される。

ここで、通信システム４を構成する各装置は、図２を参照して説明した本発明の第１の実施の形態と同様のハードウェア要素によって構成可能である。また、移動先予測装置６３０およびデバイス情報蓄積装置６４０は、それぞれ、ＣＰＵ、メモリ、および、ネットワークインタフェースを含む装置によって構成可能である。ただし、通信システム４を構成する各装置のハードウェア構成は、上述の構成に限定されない。

まず、デバイス情報蓄積装置６４０について説明する。デバイス情報蓄積装置６４０は、通信システム４においてデバイス２００から得られる各種の情報を蓄積している。例えば、デバイス２００に各種のセンサが搭載されている場合、それらのセンサから取得される情報が、デバイス２００の識別情報、センサの識別情報および時刻情報等に関連付けられて、デバイス情報蓄積装置６４０に蓄積されていく。

例えば、デバイス情報は、生産ラインにおける製品としてのデバイス２００に搭載された各種のセンサから得られる温度、湿度、製品の重量等の値であってもよい。また、デバイス情報は、利用者に装着されるウェアラブル機器としてのデバイス２００に搭載された各種のセンサから得られる利用者の体温、体内水分量、運動量等の値であってもよい。

次に、移動先予測装置６３０について説明する。移動先予測装置６３０は、指定されたデバイス２００に関してデバイス情報蓄積装置６４０に蓄積されたデバイス情報に基づいて、そのデバイス２００の移動先での配信を担当するエッジサーバ３３０を予測する。

例えば、移動先予測装置６３０は、各エッジサーバ３３０に関するロケーション情報と、各デバイス２００の特徴を表す情報とを記憶しておいてもよい。この場合、移動先予測装置６３０は、デバイス情報蓄積装置６４０から得られる該当デバイス２００に関するデバイス情報と、そのデバイス２００の特徴を表す情報とから、そのデバイス２００の移動先の位置を予測してもよい。そして、移動先予測装置６３０は、予測したデバイス２００の位置およびエッジサーバ３３０のロケーション情報に基づいて、移動先で配信を担当するエッジサーバ３３０を予測してもよい。

具体例として、例えば、移動先予測装置６３０は、デバイス２００から得られる製品の重量に基づいて、生産ラインにおいてその製品が運ばれるエリアを予測してもよい。また、例えば、移動先予測装置６３０は、デバイス２００としてのウェアラブル機器から得られる体温および体内水分量と、その時点での天候情報とに基づいて、ウェアラブル機器を装着した利用者が自動販売機のエリアに移動することを予測してもよい。その他、移動先予測装置６３０は、蓄積されるデバイス情報に基づいてデバイス２００の移動先を予測する各種の公知の技術を適用してもよい。

次に、エッジサーバ３３０の機能ブロックについて説明する。

図２４において、エッジサーバ３３０は、本発明の第２の実施の形態におけるエッジサーバ３１０に対して、依頼先決定部３１２に替えて依頼先決定部３３２を有する点が異なる。

依頼先決定部３３２は、本発明の第２の実施の形態における依頼先決定部３１２と略同様に構成される。ただし、依頼先の候補の抽出処理の詳細が異なるよう構成される。

具体的には、依頼先決定部３３２は、配信に失敗したメッセージの宛先となるデバイス２００の接続履歴の問い合わせ先の候補を、移動先予測装置６３０に問い合わせることにより取得する。つまり、依頼先決定部３３２は、移動先サーバを推定する繰り返し処理において、自装置または移動先サーバの識別情報を移動先予測装置６３０に送信することにより、返却された識別情報が示す他のエッジサーバ３３０を、移動先の候補とすればよい。

以上のように構成された通信システム４の動作について説明する。

通信システム４の動作は、図１１〜図１６を参照して説明した通信システム２の動作と略同様である。ただし、図１３におけるステップＢ１２およびＢ２４の動作の詳細が異なる。

ステップＢ１２において、依頼先決定部３３２は、移動先予測装置６３０に対して、移動先サーバの識別情報を送信する。そして、依頼先決定部３３２は、移動先予測装置６３０から返信された識別情報が示す他のエッジサーバ３３０を、依頼先の候補として取得する。

また、ステップＢ２４において、依頼先決定部３３２は、移動先予測装置６３０に対して、移動先マスタサーバの識別情報を送信する。そして、依頼先決定部３３２は、移動先予測装置６３０から返信された識別情報の示す他のエッジサーバ３３０を特定する。

以上で、通信システム４の動作の説明を終了する。

次に、本発明の第４の実施の形態の効果について述べる。

本発明の第４の実施の形態の効果は、本発明の第２の実施の形態の効果と略同様である。

ただし、その理由が若干異なる。本発明の第４の実施の形態では、エッジサーバの依頼先決定部が、デバイス情報に基づくデバイスの移動先の予測処理結果に基づいて、配信に失敗したメッセージの再配信の依頼先の候補を決定するからである。

このため、本実施の形態は、デバイスの移動により配信に失敗したメッセージの再配信が可能なエッジサーバを、デバイスの移動先の予測処理結果に基づいてより精度よく推定し、メッセージの再配信をより確実に実行することができる。

また、本実施の形態は、配信に失敗したメッセージの再配信の依頼先を決定するために他のエッジサーバに対して行う接続履歴の問い合わせ先を、デバイスの移動先の予測処理結果に基づいて絞り込むため、エッジサーバ間の通信量を抑制できる。

なお、本実施の形態において、通信システムは、デバイス情報蓄積装置を備える代わりに、外部からデバイス情報を取得するよう構成されてもよい。その場合、移動先予測装置は、外部から取得されるデバイス情報に基づいて、デバイスの移動先を予測すればよい。

また、本実施の形態において、移動先予測装置は、デバイス情報に限らず、通信システムにおいて蓄積可能または取得可能なその他の情報に基づいて、その移動先を予測してもよい。その場合、通信システムは、デバイス情報蓄積装置に替えてそれらの情報を蓄積する装置を備えるか、または、外部からそれらの情報を取得すればよい。

また、上述した本発明の第２から第４の実施の形態において、エッジサーバの依頼先決定部が、エリアマップ情報、ロケーション情報、または、移動先予測処理に基づいて、再配信の依頼先の候補となる他のエッジサーバを抽出する例について説明した。これに限らず、依頼先決定部は、その他の情報に基づいて、再配信の依頼先の候補となる他のエッジサーバを抽出してもよい。

また、上述した本発明の第２から第４の実施の形態において、第１ブローカの重複制御部が、図７に一例を示した重複制御情報を用いる例について説明した。ただし、重複制御情報の内容および形式は、限定されない。重複制御情報は、問い合わせのメッセージを同一のエッジサーバに重複して送信することを防止するための情報であればよい。

また、上述した本発明の第２から第４の実施の形態において、第２ブローカが、図８〜図１０に一例を示したメッセージ管理テーブル、トピック管理テーブル、および、配信状況テーブルを記憶する例について説明した。ただし、第２ブローカの各機能ブロックがメッセージの配信および配信状況の管理のために記憶される情報の内容および形式は、限定されない。

また、上述した本発明の各実施の形態において、パブリッシュ／サブスクライブ通信が、ＭＱＴＴに基づいて行われる例について説明した。これに限らず、本発明は、その他のプロトコルに基づきパブリッシュ／サブスクライブ通信を行う通信システムにも適用可能である。

また、上述した本発明の各実施の形態において、管理装置およびエッジサーバの間を、第１ブローカが直接接続する構成について説明した。これに限らず、管理装置および第１ブローカの間、または、第１ブローカおよびエッジサーバの間は、さらに多段のブローカを介して接続されていてもよい。また、エッジサーバおよびデバイスの間を、第２ブローカが直接接続する構成について説明した。これに限らず、エッジサーバおよび第２ブローカの間、または、第２ブローカおよびデバイスの間は、さらに多段のブローカを介して接続されていてもよい。

また、上述した本発明の各実施の形態において、通信システムを構成する各装置の各機能ブロックが、メモリに記憶されたコンピュータ・プログラムを実行するＣＰＵによって実現される例を中心に説明した。これに限らず、各機能ブロックの一部、全部、または、それらの組み合わせが専用のハードウェアにより実現されていてもよい。

また、上述した本発明の各実施の形態において、各装置の各機能ブロックは、複数の装置に分散されて実現されてもよい。

また、上述した本発明の各実施の形態において、各フローチャートを参照して説明した各装置の動作を、本発明のコンピュータ・プログラムとしてコンピュータ装置の記憶装置（記憶媒体）に格納しておく。そして、係るコンピュータ・プログラムを当該ＣＰＵが読み出して実行するようにしてもよい。そして、このような場合において、本発明は、係るコンピュータ・プログラムのコードあるいは記憶媒体によって構成される。

また、上述した各実施の形態は、適宜組み合わせて実施されることが可能である。

また、本発明は、上述した各実施の形態に限定されず、様々な態様で実施されることが可能である。

また、上述した各実施の形態の一部又は全部は、以下の付記のようにも記載されうるが、以下には限られない。
（付記１）
自装置を含む複数のエッジサーバおよび管理装置の間をパブリッシュ／サブスクライブ通信により接続する第１ブローカから、前記管理装置によって送信される自装置が配信を担当中のデバイス宛のメッセージ、または、他のエッジサーバによって自装置に再配信を依頼されたデバイス宛のメッセージを受信し、受信したメッセージを前記デバイスに配信するため、自装置および前記デバイスの間をパブリッシュ／サブスクライブ通信により接続する第２ブローカに対して送信するメッセージ送受信部と、
前記第２ブローカから、前記デバイスへの前記メッセージの配信失敗を通知されると、前記デバイスへの前記メッセージの再配信の依頼先となる他のエッジサーバを決定する依頼先決定部と、
前記依頼先となる他のエッジサーバに対して前記デバイスへの前記メッセージの再配信を依頼するため、前記メッセージを前記第１ブローカに送信する再配信依頼部と、
を備えたエッジサーバ。
（付記２）
前記依頼先決定部は、前記依頼先の候補となる他のエッジサーバに対して、前記デバイスへの接続履歴があるか否かを前記第１ブローカを介して問い合わせ、問い合わせ結果に基づいて、前記依頼先のエッジサーバを決定することを特徴とする付記１に記載のエッジサーバ。
（付記３）
前記依頼先決定部は、前記エッジサーバ間の位置関係を表すエリアマップ情報を参照することにより、自装置の周辺に位置するエッジサーバを前記依頼先の候補として抽出し、前記候補に基づいて前記依頼先のエッジサーバを決定することを特徴とする付記１または付記２に記載のエッジサーバ。
（付記４）
前記依頼先決定部は、前記エッジサーバの位置情報を表すロケーション情報を参照することにより、自装置との距離に基づき前記依頼先の候補を抽出し、前記候補に基づいて前記依頼先のエッジサーバを決定することを特徴とする付記１または付記２に記載のエッジサーバ。
（付記５）
前記依頼先決定部は、前記デバイスから取得される情報に基づいて前記デバイスの移動先を予測し、予測した移動先の情報に基づいて前記依頼先の候補を抽出し、前記候補に基づいて前記依頼先のエッジサーバを決定することを特徴とする付記１または付記２に記載のエッジサーバ。
（付記６）
前記依頼先決定部は、前記依頼先の候補の中から、前記デバイスへの配信を前記デバイスの移動先で担当する移動先のエッジサーバを推定し、前記移動先のエッジサーバに基づき新たな依頼先の候補を抽出して該候補の中から次の移動先のエッジサーバを推定することを繰り返し、所定条件が満たされた時点で推定している移動先のエッジサーバに基づいて、前記依頼先のエッジサーバを決定することを特徴とする付記２から付記５のいずれか１つに記載のエッジサーバ。
（付記７）
前記再配信依頼部は、前記第２ブローカにおいて前記配信失敗が検出されたメッセージの宛先となっているデバイス宛のメッセージについて一括して、その再配信を前記依頼先に依頼することを特徴とする付記１から付記６のいずれか１つに記載のエッジサーバ。
（付記８）
付記１から付記７のいずれか１つにおける前記第２ブローカであって、
前記エッジサーバから受信した前記メッセージを前記デバイスに配信するメッセージ配信部と、
前記デバイスに対する前記メッセージの配信失敗を検出して前記エッジサーバに通知する配信状況管理部と、
を備えた第２ブローカ。
（付記９）
前記配信失敗が検出されたメッセージの宛先となっているデバイスに対して配信するメッセージを一括して抽出するグルーピング部をさらに備え、
前記配信状況管理部は、前記グルーピング部によって抽出されたメッセージについてその配信を停止することを特徴とする付記８に記載の第２ブローカ。
（付記１０）
前記配信状況管理部は、前記依頼先に再配信が依頼されたメッセージをメモリから削除することを特徴とする付記８または付記９に記載の第２ブローカ。
（付記１１）
付記１から付記７のいずれか１つにおける前記第１ブローカであって、
前記エッジサーバから前記他のエッジサーバに対して前記再配信を依頼された前記メッセージを、前記他のエッジサーバに配信するメッセージ配信部を備えた第１ブローカ。
（付記１２）
付記２に記載のエッジサーバからの前記問い合わせを、同一の他のエッジサーバに対して重複して送信しないよう制御する重複制御部をさらに備えたことを特徴とする付記１１に記載の第１ブローカ。
（付記１３）
付記１から付記７のいずれか１つに記載のエッジサーバと、
付記８から付記１０のいずれか１つに記載の第２ブローカと、
付記１１または付記１２に記載の第１ブローカと、
前記管理装置と、
前記デバイスと、
を含む通信システム。
（付記１４）
自装置を含む複数のエッジサーバおよび管理装置の間をパブリッシュ／サブスクライブ通信により接続する第１ブローカから、前記管理装置によって送信される自装置が配信を担当中のデバイス宛のメッセージ、または、他のエッジサーバによって自装置に再配信を依頼されたデバイス宛のメッセージを受信し、
受信したメッセージを前記デバイスに配信するため、自装置および前記デバイスの間をパブリッシュ／サブスクライブ通信により接続する第２ブローカに対して送信し、
前記第２ブローカから、前記デバイスへの前記メッセージの配信失敗を通知されると、前記デバイスへの前記メッセージの再配信の依頼先となる他のエッジサーバを決定し、
前記依頼先となる他のエッジサーバに対して前記デバイスへの前記メッセージの再配信を依頼するため、前記メッセージを前記第１ブローカに送信する方法。
（付記１５）
自装置を含む複数のエッジサーバおよび管理装置の間をパブリッシュ／サブスクライブ通信により接続する第１ブローカから、前記管理装置によって送信される自装置が配信を担当中のデバイス宛のメッセージ、または、他のエッジサーバによって自装置に再配信を依頼されたデバイス宛のメッセージを受信し、受信したメッセージを前記デバイスに配信するため、自装置および前記デバイスの間をパブリッシュ／サブスクライブ通信により接続する第２ブローカに対して送信するステップと、
前記第２ブローカから、前記デバイスへの前記メッセージの配信失敗を通知されると、前記デバイスへの前記メッセージの再配信の依頼先となる他のエッジサーバを決定するステップと、
前記依頼先となる他のエッジサーバに対して前記デバイスへの前記メッセージの再配信を依頼するため、前記メッセージを前記第１ブローカに送信するステップと、
をコンピュータ装置に実行させるプログラム。

以上、上述した実施形態を模範的な例として本発明を説明した。しかしながら、本発明は、上述した実施形態には限定されない。即ち、本発明は、本発明のスコープ内において、当業者が理解し得る様々な態様を適用することができる。

この出願は、２０１６年２月１８日に出願された日本出願特願２０１６−０２８５５１を基礎とする優先権を主張し、その開示の全てをここに取り込む。

本発明は、例えば、工場における生産管理システムに適用可能である。その場合、本発明のデバイスは、生産ライン上で移動するコンテナに搭載されてもよい。また、本発明の管理装置は、デバイス上のセンサから得られる生産ラインの稼働率や環境、成果物の状態を表す情報に基づいて生産内容を制御してもよい。このような生産管理システムにおいて、本発明は、管理装置からの各種のメッセージを、コンテナに搭載したデバイスに確実に配信することができる。

また、本発明は、例えば、農作物管理システムに適用可能である。その場合、本発明のデバイスは、収穫物の運搬に用いられる籠に搭載されてもよい。または、本発明のデバイスは、収穫物そのものにタグとして付けられてもよい。また、本発明のデバイスは、農場の上空を移動するドローンに搭載されてもよい。また、本発明の管理装置は、デバイス上のセンサから得られる農作物の状態や農場の状態に基づいて、農作物を管理してもよい。このような農作物管理システムにおいて、本発明は、管理装置からの各種のメッセージを、籠や農作物に付帯されたデバイスまたはドローンに搭載されたデバイスに、確実に配信することができる。

また、本発明は、例えば、アミューズメントパークにおけるサービス提供システムに適用可能である。その場合、本発明のデバイスは、利用者に携帯されるウェアラブルのチケットや携帯機器として適用されてもよい。また、本発明の管理装置は、利用者に対して、デバイスを用いてサービスに関する情報を提供してもよい。このようなサービス提供システムにおいて、本発明は、移動する利用者に対して、デバイスから得られる情報に基づいて、お勧め情報等のメッセージを確実に配信することができる。

また、本発明は、例えば、スポーツジムにおけるヘルスケアシステムに適用可能である。その場合、本発明のデバイスは、会員によって身に着けられたセンサ機器に適用されてもよい。また、本発明の管理装置は、利用者に対して、デバイスを用いてヘルスケアに関する情報を提供してもよい。このようなヘルスケアシステムにおいて、本発明は、移動する利用者に対して、デバイスから得られる会員の身体情報、利用メニュー、運動量、健康状態(心拍数、体温、水分量)などに基づいて、お勧めのメニューや健康管理情報を、確実に配信することができる。

なお、本発明は、上述した産業上の利用可能性に限らず、管理装置から移動可能なデバイスに対して、より確実にメッセージを配信することが要求される各種の通信システムに適用可能である。

１、２、３、４ 通信システム
１００ 管理装置
２００、２００Ａ デバイス
３００、３１０、３２０、３３０ エッジサーバ
３０１、３１１ メッセージ送受信部
３０２、３１２、３２２、３３２ 依頼先決定部
３０３、３１３ 再配信依頼部
４００、４１０ 第１ブローカ
４０１、４１１ メッセージ配信部
４１２ 重複制御部
５００、５１０ 第２ブローカ
５０１、５１１ メッセージ配信部
５０２、５１２ 配信状況管理部
５１３ グルーピング部
６１０ エリアマップ管理装置
６２０ ロケーション管理装置
６３０ 移動先予測装置
６４０ デバイス情報蓄積装置
１００１、２００１、３００１、４００１、５００１ ＣＰＵ
１００２、２００２、３００２、４００２、５００２ メモリ
１００５、２００５、３００５、４００５、５００５ ネットワークインタフェース

Claims (10)

1. 自装置を含む複数のエッジサーバおよび管理装置の間をパブリッシュ／サブスクライブ通信により接続する第１ブローカから、前記管理装置によって送信される自装置が配信を担当中のデバイス宛のメッセージ、または、他のエッジサーバによって自装置に再配信を依頼されたデバイス宛のメッセージを受信し、受信したメッセージを前記デバイスに配信するため、自装置および前記デバイスの間をパブリッシュ／サブスクライブ通信により接続する第２ブローカに対して送信するメッセージ送受信手段と、
   前記第２ブローカから、前記デバイスへの前記メッセージの配信失敗を通知されると、前記デバイスへの前記メッセージの再配信の依頼先となる他のエッジサーバを決定する依頼先決定手段と、
   前記依頼先となる他のエッジサーバに対して前記デバイスへの前記メッセージの再配信を依頼するため、前記メッセージを前記第１ブローカに送信する再配信依頼手段と、
   を備えたエッジサーバ。
2. 前記依頼先決定手段は、前記依頼先の候補となる他のエッジサーバに対して、前記デバイスへの接続履歴があるか否かを前記第１ブローカを介して問い合わせ、問い合わせ結果に基づいて、前記依頼先のエッジサーバを決定することを特徴とする請求項１に記載のエッジサーバ。
3. 前記依頼先決定手段は、前記エッジサーバ間の位置関係を表すエリアマップ情報を参照することにより、自装置の周辺に位置するエッジサーバを前記依頼先の候補として抽出し、前記候補に基づいて前記依頼先のエッジサーバを決定することを特徴とする請求項１または請求項２に記載のエッジサーバ。
4. 前記依頼先決定手段は、前記エッジサーバの位置情報を表すロケーション情報を参照することにより、自装置との距離に基づき前記依頼先の候補を抽出し、前記候補に基づいて前記依頼先のエッジサーバを決定することを特徴とする請求項１または請求項２に記載のエッジサーバ。
5. 前記依頼先決定手段は、前記デバイスから取得される情報に基づいて前記デバイスの移動先を予測し、予測した移動先の情報に基づいて前記依頼先の候補を抽出し、前記候補に基づいて前記依頼先のエッジサーバを決定することを特徴とする請求項１または請求項２に記載のエッジサーバ。
6. 前記依頼先決定手段は、前記依頼先の候補の中から、前記デバイスへの配信を前記デバイスの移動先で担当する移動先のエッジサーバを推定し、前記移動先のエッジサーバに基づき新たな依頼先の候補を抽出して該候補の中から次の移動先のエッジサーバを推定することを繰り返し、所定条件が満たされた時点で推定している移動先のエッジサーバに基づいて、前記依頼先のエッジサーバを決定することを特徴とする請求項２から請求項５のいずれか１項に記載のエッジサーバ。
7. 前記再配信依頼手段は、前記第２ブローカにおいて前記配信失敗が検出されたメッセージの宛先となっているデバイス宛のメッセージについて一括して、その再配信を前記依頼先に依頼することを特徴とする請求項１から請求項６のいずれか１項に記載のエッジサーバ。
8. 請求項１から請求項７のいずれか１項に記載のエッジサーバと、
   前記管理装置と、
   前記デバイスと、
   を含む通信システム。
9. 自装置を含む複数のエッジサーバおよび管理装置の間をパブリッシュ／サブスクライブ通信により接続する第１ブローカから、前記管理装置によって送信される自装置が配信を担当中のデバイス宛のメッセージ、または、他のエッジサーバによって自装置に再配信を依頼されたデバイス宛のメッセージを受信し、
   受信したメッセージを前記デバイスに配信するため、自装置および前記デバイスの間をパブリッシュ／サブスクライブ通信により接続する第２ブローカに対して送信し、
   前記第２ブローカから、前記デバイスへの前記メッセージの配信失敗を通知されると、前記デバイスへの前記メッセージの再配信の依頼先となる他のエッジサーバを決定し、
   前記依頼先となる他のエッジサーバに対して前記デバイスへの前記メッセージの再配信を依頼するため、前記メッセージを前記第１ブローカに送信する方法。
10. 自装置を含む複数のエッジサーバおよび管理装置の間をパブリッシュ／サブスクライブ通信により接続する第１ブローカから、前記管理装置によって送信される自装置が配信を担当中のデバイス宛のメッセージ、または、他のエッジサーバによって自装置に再配信を依頼されたデバイス宛のメッセージを受信し、受信したメッセージを前記デバイスに配信するため、自装置および前記デバイスの間をパブリッシュ／サブスクライブ通信により接続する第２ブローカに対して送信するステップと、
    前記第２ブローカから、前記デバイスへの前記メッセージの配信失敗を通知されると、前記デバイスへの前記メッセージの再配信の依頼先となる他のエッジサーバを決定するステップと、
    前記依頼先となる他のエッジサーバに対して前記デバイスへの前記メッセージの再配信を依頼するため、前記メッセージを前記第１ブローカに送信するステップと、
    をコンピュータ装置に実行させるプログラム。

Images