JP2018148430A - データ配信システム、通信装置、通信制御方法、およびプログラム - Google Patents

Abstract

【課題】異常の発生時に、迅速に代替経路に切り替えること。
【解決手段】実施形態のデータ配信システムは、複数の通信装置を含む。また、データ配信システムは、木構造の論理ネットワークを用いてデータ配信を行う。複数の通信装置の少なくとも一部は、監視部と、接続切替部とを持つ。監視部は、木構造の論理ネットワークにおける一つ上位の通信装置であって、自装置にデータを送信する通信装置の稼働状態を確認する。接続切替部は、前記監視部により前記一つ上位の通信装置の稼働状態が確認されない場合、前記木構造の論理ネットワークにおいて二つ以上上位の通信装置であって前記一つ上位の通信装置を介さずに自装置にデータを送信可能な通信装置に対して、自装置にデータを送信するよう要求する。
【選択図】図１２

Description

本発明の実施形態は、データ配信システム、通信装置、通信制御方法、およびプログラムに関する。

情報配信主から端末装置に情報を配信するデータ配信システムが実用化されている。データ配信システムにおいて、通信障害が発生した場合でも情報配信を停止しないように、配信経路にある通信装置を冗長化することが考えられている。しかしながら、近年のＩｏＴ（Internet of Things）技術の世界では、ネットワークの規模が大きくなることが想定されるため、これに適用する際に、通信機器を冗長化すると、コストが膨大となってしまう。また、従来の技術では、データ配信における上流側からの監視を行っていたため、最下流までの通信経路を上流側で全て把握していない場合には、代替可能な通信経路を特定できない場合があった。

特開２０１４−１８３５０１号公報

本発明が解決しようとする課題は、異常の発生時に、迅速に代替経路に切り替えることができるデータ配信システム、通信装置、通信制御方法、およびプログラムを提供することである。

実施形態のデータ配信システムは、複数の通信装置を含む。また、データ配信システムは、木構造の論理ネットワークを用いてデータ配信を行う。複数の通信装置の少なくとも一部は、監視部と、接続切替部とを持つ。監視部は、木構造の論理ネットワークにおける一つ上位の通信装置であって、自装置にデータを送信する通信装置の稼働状態を確認する。接続切替部は、前記監視部により前記一つ上位の通信装置の稼働状態が確認されない場合、前記木構造の論理ネットワークにおいて二つ以上上位の通信装置であって前記一つ上位の通信装置を介さずに自装置にデータを送信可能な通信装置に対して、自装置にデータを送信するよう要求する。

実施形態のデータ配信システムが形成する木構造の論理ネットワークを示す図。 データ配信システムが形成する物理ネットワークの一例を示す図。 ルートブローカＲＢの構成図。 機器管理テーブル１２に登録されるデータの内容の一例を示す図。 トピック管理テーブル２３に登録されるデータの内容の一例を示す図。 サブブローカＳＢの構成図。 クライアントＣＬの構成図。 ブローカ間で機器登録処理が行われる様子を示す図。 クライアントとブローカの間で機器登録処理が行われる様子を示す図。 ある形態のデータ配信ネットワークにおいて、各通信装置の機器管理テーブル１２に設定される情報の一例を示す図。 図１０と同じ形態のデータ配信ネットワークにおいて、あるイベントがクライアントＣＬに配信される様子を示す図。 図１０と同じ形態のデータ配信ネットワークにおいて、ある通信装置に異常が発生したときに代替送信が行われる様子を示す図。 通信継続機能部４０により実行される第１の処理の流れの一例を示すフローチャート図。 異常が発生した通信装置が復帰する様子を示す図。 実施形態のデータ配信システムを信号機の制御システムに適用した例を示す図。

以下、実施形態のデータ配信システム、通信装置、通信制御方法、およびプログラムを、図面を参照して説明する。以下の説明において、「自装置」と記載した場合、その主体が属する通信装置を意味するものとする。

［ネットワーク、定義］
図１は、実施形態のデータ配信システムが形成する木構造の論理ネットワークを示す図である。データ配信システムには、少なくとも以下の三種類の通信装置が含まれる。

（１）ルートブローカ：パブリッシャから配信依頼を受け、データを配信する装置。パブ−サブ型データの配信システムにおけるパブリッシャ機能とブローカ機能を有する。
（２）サブブローカ（中継装置）：上位のブローカ（ルートブローカまたはサブブローカ）から配信されたデータを、下位のブローカまたはデバイスに送信する装置。パブ−サブ型のデータ配信システムにおけるブローカ機能を有する。
（３）クライアント（受信装置）：上位のブローカ（同上）から配信されたデータを受け取り、必要に応じてユーザに視聴させる装置。パブ−サブ型のデータ配信システムにおけるサブスクライバ機能を有する。

パブ−サブ型のデータ配信システムとは、あるクライアントが登録された場合、そのクライアント宛のデータが生成されると、自動的にクライアントにデータを配信するシステムである。

ルートブローカからクライアントへは、木構造の論理ネットワークによってデータが配信される。木構造の論理ネットワークとは、各通信装置において動作するソフトウェアが認識する各通信装置の論理アドレス（以下、ＵＲＩという）が、ルートブローカからクライアントに向けて分岐する木構造を形成しているネットワークをいう。図中、［0001］などと表記されているのは、各通信装置のＵＲＩを示している。ＵＲＩは、例えばグローバルＩＰアドレスとローカルＩＰアドレスの関係のように、上位桁が上位の通信装置を表す構造となっている。以下の説明において、単に「0001」などと表記した場合、そのＵＲＩを有する通信装置を指すものとする。

このネットワークにおいて、上位の通信装置は、必ずしもクライアントまでの全ての通信装置のＵＲＩを把握している必要はなく、自装置がデータを送信する一つ下位の通信装置のＵＲＩを把握していればデータ配信を行うことができる。そのために、各階層の通信装置は、自装置がデータを送信する下位の通信装置のＵＲＩを把握している。

特許請求の範囲における「通信装置」は、少なくとも（２）サブブローカを含み、更に（３）クライアントを含んでもよい。

本実施形態のデータ配信システムを構成する物理ネットワークは、以下の条件を満たす必要がある。
（Ａ）各通信装置は、自装置がデータを送信する下位の通信装置と接続されている。
（Ｂ）各通信装置（ルートブローカと、ルートブローカに直接接続されたサブブローカを除く）は、二つ以上上位の通信装置と、自装置にデータを送信する一つ上位の通信装置を介さずに接続されている。

上記（Ａ）、（Ｂ）を満たす物理ネットワークとして、例えば図２に示すネットワークが考えられる。図２は、データ配信システムが形成する物理ネットワークの一例を示す図である。なお、図２に示す構成は、上位と下位の関係にある通信装置同士を接続した構成であるが、これに限らず、データ配信システムには、同位の関係にある通信装置同士を接続した部分があってもよい。また、データ配信システムの中に、特に信頼性の高い通信装置が存在する場合、その通信装置がデータを送信する下位の通信装置は、（Ｂ）の条件を満たさなくてもよい。

以下の説明では、データ配信システムが配信するデータを「イベント」、イベントの宛先判断に用いられるイベントのラベル情報を「トピック」と称する。

［ルートブローカ］
図３は、ルートブローカＲＢの構成図である。ルートブローカＲＢは、例えば、機器管理部１０と、ブローカ機能部２０と、通信継続機能部４０とを備える。なお、以下に説明する機器管理テーブル１２、トピック管理テーブル２３、イベントプール２５、配信先リスト２７、および接続リスト４３は、ＨＤＤ（Hard Disk Drive）やフラッシュメモリ、ＲＡＭ（Random Access Memory）などの記憶媒体に格納されデータである。また、それ以外の構成は、例えば、ＣＰＵ（Central Processing Unit）などのプロセッサがプログラムを実行することにより実現されてもよいし、ＬＳＩ（Large Scale Integration）やＡＳＩＣ（Application Specific Integrated Circuit）、ＦＰＧＡ（Field-Programmable Gate Array）などのハードウェアにより実現されてもよい。

機器管理部１０は、例えば、機器登録・削除部１１と、機器管理テーブル１２とを備える。機器登録・削除部１１は、下位の通信装置からの要求に応じて、下位の通信装置のＵＲＩ（Uniform Resource Identifier）を取得し、機器管理テーブル１２に登録する。ＵＲＩは、ルートブローカＲＢによって設定される。図４は、機器管理テーブル１２に登録されるデータの内容の一例を示す図である。機器管理テーブル１２は、例えば、下位の通信装置のＵＲＩである機器ＵＲＩと、ＩＰアドレスと、イベントの配信を受ける状態であるか否かを示す稼働状態と、ブローカであるかクライアントであるかを示すタイプとが、互いに対応付けられたデータである。稼働状態は、例えば１である場合に受信中を示し、０である場合に受信停止中を示すものとする。

図３に戻り、ブローカ機能部２０は、例えば、イベント受信部２１と、トピック登録部２２と、トピック管理テーブル２３と、トピック配信先登録部２４と、イベントプール２５と、配信先決定部２６と、配信先リスト２７と、イベント配信部２８とを備える。

イベント受信部２１は、上位の装置から、トピックとイベントの組み合わせデータを受信する。トピック登録部２２は、イベント受信部２１が受信した組み合わせデータからトピックを抽出し、トピック管理テーブル２３に登録する。

図５は、トピック管理テーブル２３に登録されるデータの内容の一例を示す図である。図示するように、トピック管理テーブル２３は、トピックに対して配信先ＵＲＩが対応付けられたデータである。トピックは、「/Japan/Tokyo/Temperature（東京の天気）」のように、配信されるイベントの内容を表す場合もあるし、配信先のＵＲＩを表す場合もある。図５における「＃」は、それ以前のＵＲＩを満たす全てのＵＲＩに送信するという意味である。また、トピックには、「send all（接続されている全ての下位の通信装置に送信）」のようなものが含まれてもよい。

トピックに対応する配信先ＵＲＩは、トピック配信先登録部２４によって登録される。トピック配信先登録部２４は、予め受信されている下位の通信装置からの要求と、トピックの内容とに基づいて、配信先ＵＲＩをトピック管理テーブル２３に登録する。例えば、「/Japan/Tokyo/Temperature」に関しては、予めその内容のイベントを受信する旨を通知している配信先（図５の例では「0001/0002」）をトピック管理テーブル２３に登録する。また、「0001/0001/#」に関しては、その条件を満たす配信先を機器管理テーブル１２から取得し、取得した配信先のＵＲＩをトピック管理テーブル２３に登録する。

また、イベント受信部２１は、上位の装置から受信した組み合わせデータを、イベントプール２５に格納する。イベントプール２５には、何世代か前までの組み合わせデータが保管される。これによって、通信障害時に再配信が要求された場合に、スムーズに応答することができる。

配信先決定部２６は、イベント受信部２１からの指示に基づいて、トピック管理テーブル２３に登録されたトピックに基づいて、イベントの配信先（例えばＩＰアドレス）を決定し、配信先リスト２７に登録する。イベント配信部２８は、配信先リスト２７に基づいて、イベントを下位の通信装置に配信する。

ルートブローカＲＢの通信継続機能部４０は、例えば、下位ノード応答部４１と、接続切替部４２（Ｒ）と、接続リスト４３とを備える。下位ノード応答部４１は、下位の通信装置の上位ノード監視部４４（後述）からの確認信号に応答する。この応答は、pingに応答するような機械的なものではなく、ルートブローカＲＢのソフトウェアが正常に機能していることを示すものであると好適である。例えば、下位ノード応答部４１は、確認信号に対して予め定められた演算を行った結果を下位の通信装置に返信する。接続切替部４２（Ｒ）は、下位の通信装置からの要求に応じて、イベントの配信先を変更する。接続リスト４３は、イベントの配信先として接続されている下位の通信装置のリストである。

［サブブローカ］
図６は、サブブローカＳＢの構成図である。図６において、ルートブローカＲＢと共通する構成については同じ符号を付している。サブブローカＳＢの通信継続機能部４０は、例えば、上位ノード監視部４４と、上位ノードリスト４５とを更に備える。上位ノード監視部４４は、前述した確認信号を、自装置にイベント配信する上位の通信装置に送信する。そして、上位の通信装置から適切な応答が無かった場合、すなわち自装置にイベントを送信する通信装置の稼働状態が確認されない場合、その旨を示す通知を接続切替部４２（Ｓ）に出力する。サブブローカＳＢの接続切替部４２（Ｓ）は、ルートブローカＲＢの接続切替部４２（Ｒ）と同様の機能を有する他、上記の通知がなされた場合、上位ノードリスト４５を参照し、論理ネットワークにおける２つ以上上位の通信装置であって、可動状態が確認されなかった通信装置を介さずに自装置にデータを送信可能な通信装置に対して、自装置にデータを送信するよう要求する機能を有する。上位ノードリスト４５の内容については後述する。

また、サブブローカＳＢは、上位ブローカ通知部５０を更に備える。上位ブローカ通知部５０は、例えば、機器登録・削除要請部５１と、受信トピック登録要請部５２とを備える。機器登録・削除要請部５１は、上位の通信装置の機器登録・削除部１１に対して、自装置のＵＲＩの登録または削除を要請する。受信トピック登録要請部５２は、特定のトピックの送信を上位の通信装置のトピック配信先登録部２４に依頼する。

［クライアント］
図７は、クライアントＣＬの構成図である。図７において、サブブローカＳＢと共通する構成については同じ符号を付している。クライアントＣＬの接続切替部４２（Ｃ）は、上位ノード監視部４４からの通知がなされた場合、上位ノードリスト４５を参照し、論理ネットワークにおける２つ以上上位の通信装置であって、可動状態が確認されなかった通信装置を介さずに自装置にデータを送信可能な通信装置に対して、自装置にデータを送信するよう要求する。

クライアントＣＬは、更に、イベント受信・通知部６０を備える。イベント受信・通知部６０は、イベント受信部６１と、イベント通知部６２とを備える。イベント受信部６１は、上位の通信装置からイベントを受信する。イベント通知部６２は、イベント受信部６１により受信されたイベントに関してエンドユーザに通知する。

［処理の流れ］
以下、データ配信システムにおける代表的な処理について説明する。

（１.機器登録、配信）
図８は、ブローカ間で機器登録処理が行われる様子を示す図である。図８および図９では、データ配信システムが、ルートブローカＲＢ−サブブローカＳＢ−クライアントＣＬの３階層であるものとして説明する。また、図８は、サブブローカＳＢとルートブローカＲＢの間の機器登録処理を示しているが、サブブローカＳＢ間でも同様の処理が行われる。

まず、サブブローカＳＢの機器登録・削除要請部５１から、ルートブローカＲＢの機器登録・削除部１１に対して、登録要請がなされる。ルートブローカＲＢの機器登録・削除部１１は、機器管理テーブル１２に、サブブローカＳＢの機器ＵＲＩ［０００１／０００１］などを登録する。ここでは、通信が成立したばかりであるので、稼働状態は１に設定される。

ルートブローカＲＢの機器登録・削除部１１は、登録した旨の応答を返信する。サブブローカＳＢの上位ノード監視部４４は、確認信号をルートブローカＲＢの下位ノード応答部４１に送信する。確認信号に対してルートブローカＲＢの下位ノード応答部４１が適切に応答すると、サブブローカＳＢの上位ノード監視部４４は、ルートブローカＲＢの機器ＵＲＩ［０００１］などを上位ノードリスト４５に登録する。

上位ノードリスト４５には、ルートブローカＲＢから自装置にイベントを伝送する経路上の全ての通信装置の情報が登録される。上位ノードリスト４５は、例えば、機器ＵＲＩ、ＩＰアドレス、稼働状態、接続フラグなどの情報が互いに対応付けられた情報である。機器ＵＲＩやＩＰアドレスは、機器登録・削除要請部５１から上位ノード監視部４４に提供される。稼働状態とは、該当する上位の通信装置が稼働状態であるか否かを示す情報である。稼働状態には、確認信号に適切に応答した場合に１が、そうでない場合に０が設定される。また、接続フラグとは、自装置に直接、イベントを送信する通信装置であるか否かを示す情報である。接続フラグには、自装置に直接イベントを送信する通信装置である場合に１が、そうでない場合に０が設定される。図８の例では、［0001］は、稼働状態にあるため稼働状態が１に設定され、［0001/0001］に対して直接、イベントを送信する通信装置であるため接続フラグが１に設定される。

図９は、クライアントとブローカの間で機器登録処理が行われる様子を示す図である。まず、クライアントＣＬの機器登録・削除要請部５１から、サブブローカＳＢの機器登録・削除部１１に対して、登録要請がなされる。サブブローカＳＢの機器登録・削除部１１は、機器管理テーブル１２に、クライアントＣＬの機器ＵＲＩ［0001/0001/0001］などを登録する。ここでは、通信が成立したばかりであるので、稼働状態は１に設定される。

サブブローカＳＢの機器登録・削除部１１は、登録した旨の応答を返信する。クライアントＣＬの上位ノード監視部４４は、確認信号をサブブローカＳＢの下位ノード応答部４１に送信する。確認信号に対してサブブローカＳＢの下位ノード応答部４１が適切に応答すると、クライアントＣＬの上位ノード監視部４４は、ルートブローカＲＢの機器ＵＲＩ［０００１］、サブブローカＳＢの機器ＵＲＩ［0001/0001］などを上位ノードリスト４５に登録する。ここで、クライアントＣＬは、ルートブローカＲＢの機器ＵＲＩを直接知り得る訳では無いため、例えば、サブブローカＳＢの機器登録・削除部１１または下位ノード応答部４１が、自装置の上位ノードリスト４５に保持している情報を、クライアントＣＬに提供する。この点はサブブローカＲＢ間の機器登録処理においても同様である。

図９の例では、クライアントＣＬの上位ノードリスト４５においては、ルートブローカＲＢの機器ＵＲＩ［0001］に対して稼働状態が１、接続フラグが０に設定される。また、サブブローカＳＢの機器ＵＲＩ［0001/0001］に対して稼働状態が１、接続フラグが１に設定される。

図１０は、ある形態のデータ配信ネットワークにおいて、各通信装置の機器管理テーブル１２に設定される情報の一例を示す図である。図示するクライアントＣＬのうち［0001/0001/0002］が受信を停止している。停止している原因には種々のものが考えられるが、クライアントＣＬの利用者が手動操作でクライアントＣＬを停止させた、或いはクライアントＣＬに故障等が生じたなどがあり得る。前者の場合はクライアントＣＬから上位の通信装置に通知がなされることで認識され、後者の場合はクライアントＣＬからのイベント受領通知（例えばＡＣＫ）が受信されないことで認識される。上位の通信装置は、受信を停止しているクライアントＣＬに対して、機器管理テーブル１２の稼働状態を０に設定し、イベントの送信を停止する。

図１１は、図１０と同じ形態のデータ配信ネットワークにおいて、あるイベントがクライアントＣＬに配信される様子を示す図である。図１１では、［0001/0002/0002/0001］で表されるトピックに対応付けられたイベントが配信されるものとする。

この場合、ルートブローカＲＢのトピック管理テーブル２３における［0001/0002/#］が、このトピックに該当する。ルートブローカＲＢのイベント配信部２８は、トピック管理テーブル２３において［0001/0002/#］に対応付けられている配信先ＵＲＩの示す［0001/0002］にイベントを送信する。

［0001/0002］が保持するトピック管理テーブル２３では、［0001/0002/0002/#］がトピックに該当する。［0001/0002］のイベント配信部２８は、トピック管理テーブル２３において［0001/0002/0002/#］に対応付けられている配信先ＵＲＩの示す［0001/0002/0002］にイベントを送信する。

［0001/0002/0002］が保持するトピック管理テーブル２３では、［0001/0002/0002/0001］がトピックに該当する。［0001/0002/0002］のイベント配信部２８は、トピック管理テーブル２３において［0001/0002/0002/0001］に対応付けられている配信先ＵＲＩの示す［0001/0002/0002/0001］にイベントを送信する。このようにして、特定のクライアントＣＬにイベントが届けられる。

（２.代替配信）
図１２は、図１０と同じ形態のデータ配信ネットワークにおいて、ある通信装置に異常が発生したときに代替送信が行われる様子を示す図である。図では、［0001/0002/0002］に異常が発生している。この場合、［0001/0002/0002/0001］は、前述したように、上位ノード監視部４４の機能によって、上記のサブブローカＳＢが稼働状態でないことを検知する。［0001/0002/0002/0001］の接続切替部４２（Ｃ）は、自装置の上位ノードリスト４５を参照し、［0001/0002/0002］の一つ上位の、［0001/0002］に代替送信を依頼する。この場合のクライアントＣＬの上位ノードリスト４５は図示の通りであり、［0001/0002/0002］の稼働状態と接続フラグが０に変更されると共に、［0001/0002］の接続フラグが１に変更される。このとき、［0001/0002/0002/0001］の上位ノード監視部は、［0001/0002/0002］に対する確認信号の送信を停止すると共に、［0001/0002］に対する確認信号の送信を開始する。なお、［0001/0002］から代替送信の依頼に対する適切な応答が無かった場合、［0001/0002/0002/0001］の接続切替部４２（Ｃ）は、更に上位の［0001］に代替送信を依頼する。

一方、代替送信を受諾した［0001/0002］では、図示するように接続リスト４３が変更される。接続リスト４３は、例えば、機器ＵＲＩと、ＩＰアドレスと、代替元親ノードと、稼働状態と、離脱フラグとが、互いに対応付けられたデータである。代替元親ノードとは、代替送信の元となった通信装置（異常が生じた通信装置）のＵＲＩである。離脱フラグとは、データ配信ネットワークから離脱した状態であるか否かを示す情報である。このような設定の下、［0001/0002］は、［0001/0002/0002/0001］宛のイベントを、［0001/0002/0002］を介さずに［0001/0002/0002/0001］に送信する。

接続リスト４３は、不揮発性記憶装置に格納される。これによって、異常が生じた通信装置が復旧するときに、不揮発性記憶装置に格納された接続リスト４３を読み出すことで、復旧通知（後述）を速やかに行うことができる。

図１３は、通信継続機能部４０により実行される第１の処理の流れの一例を示すフローチャートである。本フローチャートの処理は、例えば、所定周期で繰り返し実行される。まず、上位ノード監視部４４が、自装置にイベントを送信する上位の通信装置が稼働状態であるか否かを判定する（ステップＳ１００）。上位ノード監視部４４は、例えば、確認信号に対して一定時間、適切な応答が無い場合に、稼働状態でないと判定する。自装置にイベントを送信する上位の通信装置が稼働状態であると判定された場合、本フローチャートの１ルーチンが終了する。

自装置にイベントを送信する上位の通信装置が稼働状態でないと判定された場合、通信切替部４２（ＳまたはＣ）が、稼働状態でないと判定された通信装置よりも一つ上位の通信装置に対して代替送信依頼を送信する（ステップＳ１０２）。次に、通信切替部４２（ＳまたはＣ）は、代替送信依頼に対する応答があったか否かを判定する（ステップＳ１０４）。代替送信依頼に対する応答が無かった場合、通信切替部４２（ＳまたはＣ）は、ステップＳ１０２に戻り、更に上位の通信装置に対して代替送信依頼を送信する。

代替送信依頼に対する応答があった場合、通信切替部４２（ＳまたはＣ）は、上位ノードリスト４５を更新し（ステップＳ１０６）、確認信号の送信先を切り替える（ステップＳ１０８）。こうして代替送信によるイベント配信を受けることができる。なお、上位ノードリスト４５が更新されることで、サブブローカＳＢまたはクライアントＣＬが新たな配信要求等を送信する際に、上位ノードリスト４５における接続フラグが１に設定されている通信装置が、配信要求等の送信先として扱われる。

図１４は、異常が発生した通信装置が復帰する様子を示す図である。［0001/0002/0002］は、異常状態から復帰すると、復帰通知を下位の［0001/0002/0002/0001］に送信する。これを受けて［0001/0002/0002/0001］の接続切替部４２（Ｃ）は、代替送信の停止依頼を［0001/0002］に送信する。更に、［0001/0002/0002］は、接続リスト４３の送信要求を［0001/0002］に送信する。［0001/0002］は、その時点で自装置が保持している接続リスト４３を［0001/0002/0002］に返信する。

イベント送信を行っていた［0001/0002］は、代替送信の停止依頼を受けて、接続リスト４３を元の状態に戻す。［0001/0002/0002］では、稼働フラグまたは離脱フラグが１になっている下位の通信装置が存在するか否か検索し、存在する場合、自装置が保持する接続リスト４３においても稼働フラグまたは離脱フラグを同様に１に変更する。これによって、受信を停止している下位の装置に対するイベント送信を停止することができ、不要な通信を抑制することができる。

［適用例］
図１５は、実施形態のデータ配信システムを信号機の制御システムに適用した例を示す図である。図示するように、信号機ＳＭの制御信号は、ルートブローカＲＢによって一階層以上のサブブローカＳＢを介してクライアントＣＬに配信され、クライアントＣＬによって信号機ＳＭが制御されるようにしてよい。この場合、信号機ＳＭの制御部をクライアントＣＬとしてもよい。これによって、緊急車両の通過時に一部の信号群を一括して赤点灯に変更するような制御を容易に行うことができる。また、災害時などにおいて、一部の通信装置で障害が発生しても、代替送信によって確実にデータを配信することができる。

以上の説明では、異常が発生した通信装置は、代替送信に関与しないものとした。これに限らず、例えば、「ブローカとしてのソフトウェアは正常に動作しないが、ＵＲＩを見て転送する機能は故障せずに残っている」場合、その通信装置は、代替送信の中継を行ってもよい。

以上説明した少なくともひとつの実施形態によれば、複数の通信装置を含み、木構造の論理ネットワークを用いてデータ配信を行うデータ配信システムにおいて、複数の通信装置の少なくとも一部は、木構造の論理ネットワークにおける一つ上位の通信装置であって、自装置にデータを送信する通信装置の稼働状態を確認する上位ノード監視部４４と、上位ノード監視部４４により一つ上位の通信装置の稼働状態が確認されない場合、木構造の論理ネットワークにおいて二つ以上上位の通信装置であって一つ上位の通信装置を介さずに自装置にデータを送信可能な通信装置に対して、自装置にデータを送信するよう要求する接続切替部４２と、を持つことにより、異常の発生時に、迅速に代替経路に切り替えることができる。

本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれると同様に、特許請求の範囲に記載された発明とその均等の範囲に含まれるものである。

１…データ配信システム、４０…通信継続機能部、４１…下位ノード応答部、４２…接続切替部、４３…接続リスト、４４…上位ノード監視部、４５…上位ノードリスト、ＲＢ…ルートブローカ、ＳＢ…サブブローカ、ＣＬ…クライアント

Claims (8)

1. 複数の通信装置を含み、木構造の論理ネットワークを用いてデータ配信を行うデータ配信システムであって、
   前記複数の通信装置の少なくとも一部は、
   前記木構造の論理ネットワークにおける一つ上位の通信装置であって、自装置にデータを送信する通信装置の稼働状態を確認する監視部と、
   前記監視部により前記一つ上位の通信装置の稼働状態が確認されない場合、前記木構造の論理ネットワークにおいて二つ以上上位の通信装置であって前記一つ上位の通信装置を介さずに自装置にデータを送信可能な通信装置に対して、自装置にデータを送信するよう要求する接続切替部と、を備える、
   データ配信システム。
2. 前記複数の通信装置の少なくとも一部は、
   上位の通信装置のリストである第１のリストを保持し、
   前記接続切替部は、前記監視部により前記一つ上位の通信装置の稼働状態が確認されない場合、前記第１のリストを参照して、前記木構造の論理ネットワークにおいて二つ以上上位の通信装置を特定する、
   請求項１記載のデータ配信システム。
3. 前記監視部は、前記木構造の論理ネットワークにおける一つ上位の通信装置であって、自装置にデータを送信する通信装置の稼働状態を定期的に確認する、
   請求項１または２記載のデータ配信システム。
4. 前記複数の通信装置の少なくとも一部は、
   下位の通信ノードの稼働状態を示すリストである第２のリストを保持し、
   前記木構造の論理ネットワークにおいて二つ以上下位の通信装置からの要求に応じて、前記二つ以上下位の通信装置にデータを送信している間、前記二つ以上下位の通信装置の状態に応じて前記第２のリストを更新し、
   前記木構造の論理ネットワークにおいて一つ下位の通信装置が稼働状態に復帰した場合、前記第２のリストを、前記木構造の論理ネットワークにおいて一つ下位の通信装置に送信する、
   請求項１から３のうちいずれか１項記載のデータ配信システム。
5. 前記複数の通信装置のうち、
   前記木構造の論理ネットワークにおける最上位の通信装置にパブリッシャ機能とブローカ機能を、
   前記木構造の論理ネットワークにおける中間位の通信装置にブローカ機能を、
   前記木構造の論理ネットワークにおける最下位の通信装置にサブスクライバ機能を備える、
   請求項１から４のうちいずれか１項記載のデータ配信システム。
6. 木構造の論理ネットワークにおける一つ上位の通信装置であって、自装置にデータを送信する通信装置の稼働状態を確認する監視部と、
   前記監視部により前記一つ上位の通信装置の稼働状態が確認されない場合、前記木構造の論理ネットワークにおいて二つ以上上位の通信装置であって前記一つ上位の通信装置を介さずに自装置にデータを送信可能な通信装置に対して、自装置にデータを送信するよう要求する接続切替部と、
   を備える通信装置。
7. 複数の通信装置を含み、木構造の論理ネットワークを用いてデータ配信を行うデータ配信システムにおける通信装置が、
   前記木構造の論理ネットワークにおける一つ上位の通信装置であって、自装置にデータを送信する通信装置の稼働状態を確認し、
   前記一つ上位の通信装置の稼働状態が確認されない場合、前記木構造の論理ネットワークにおいて二つ以上上位の通信装置であって前記一つ上位の通信装置を介さずに自装置にデータを送信可能な通信装置に対して、自装置にデータを送信するよう要求する、
   通信制御方法。
8. 複数の通信装置を含み、木構造の論理ネットワークを用いてデータ配信を行うデータ配信システムにおける通信装置に、
   木構造の論理ネットワークにおける一つ上位の通信装置であって、自装置にデータを送信する通信装置の稼働状態を確認させ、
   前記一つ上位の通信装置の稼働状態が確認されない場合、前記木構造の論理ネットワークにおいて二つ以上上位の通信装置であって前記一つ上位の通信装置を介さずに自装置にデータを送信可能な通信装置に対して、自装置にデータを送信するよう要求させる、
   プログラム。

Images