(57)【要約】【課題】  データ出力装置から出力されたデータをデータ処理装置に中継送信する際に、より確実に通信の輻輳を低減する。【解決手段】  本発明は、データ出力装置と、データ処理装置と、データ出力装置とデータ処理装置との間の通信を中継する中継装置とを備える通信システムに関する。そして、中継装置は、データ出力装置から出力されたデータを受信する手段と、受信したデータを、外部装置を宛先として送信する手段と、送信したデータを受信した外部装置からの確認応答信号を受信する手段と、確認応答信号の受信状況に基づいて、当該中継装置から外部装置までの通信経路上の輻輳の有無を検出する手段と、通信経路上で輻輳有ると検出された場合、通信経路上の輻輳が軽減するように、データ送信手段の動作を制御する手段とを有することを特徴とする。【選択図】      図１
2018019266.tif 000002
【特許請求の範囲】
【請求項１】
中継装置において、
データ出力装置から出力されたデータを受信するデータ受信手段と、
前記データ受信手段が受信したデータを、外部装置を宛先として送信するデータ送信手段と、
前記データ送信手段が送信したデータを受信した前記外部装置からの確認応答信号を受信する確認応答信号受信手段と、
前記確認応答信号受信手段による確認応答信号の受信状況に基づいて、当該中継装置から前記外部装置までの通信経路上の輻輳の有無を検出する検出手段と、
前記検出手段で前記通信経路上で輻輳が有ると検出された場合、前記通信経路上の輻輳が軽減するように、前記データ送信手段の動作を制御する輻輳制御手段と
を有することを特徴とする中継装置。
【請求項２】
前記輻輳制御手段は、前記検出手段により前記通信経路上で輻輳が有ると検出された場合、前記データ送信手段を制御して、前記データ受信手段が受信したデータを前記外部装置に送信させる前に圧縮する圧縮処理を実行させることを特徴とする請求項１に記載の中継装置。
【請求項３】
前記輻輳制御手段は、前記検出手段により前記通信経路上で輻輳が有ると検出された後、前記検出手段により前記通信経路上で輻輳が無いと検出された場合、前記データ送信手段に、前記圧縮処理を終了させることを特徴とする請求項２に記載の中継装置。
【請求項４】
前記輻輳制御手段は、前記検出手段により前記通信経路上で輻輳が有ると検出された場合、前記データ送信手段を制御して、前記データ受信手段が受信したデータを前記外部装置に送信させる際のタイミングを所定の遅延時間分遅延させる遅延処理を実行させることを特徴とする請求項１に記載の中継装置。
【請求項５】
前記輻輳制御手段は、前記検出手段により前記通信経路上で輻輳が有ると検出された後、前記検出手段により前記通信経路上で輻輳が無いと検出された場合、前記データ送信手段に、前記遅延処理を終了させることを特徴とする請求項４に記載の中継装置。
【請求項６】
前記検出手段は、前記データ送信手段が前記外部装置にデータ送信してから、所定のタイムアウト時間が経過するまでの間に、前記確認応答信号受信手段により、当該データ送信に応答する確認応答信号が受信されない場合、前記通信経路上で輻輳が有ると検知することを特徴とする請求項１〜５のいずれかに記載の中継装置。
【請求項７】
データを出力するデータ出力装置と、前記データ出力装置が出力したデータを収集して処理するデータ処理装置と、前記データ出力装置から出力されたデータを前記データ処理装置に送信する中継装置とを備える通信システムにおいて、前記中継装置として請求項１〜６のいずれかに記載の中継装置を適用したことを特徴とする通信システム。
【請求項８】
データ出力装置が出力したデータを収集して処理するデータ処理装置と、前記データ出力装置から出力されたデータを前記データ処理装置に送信する中継装置とを備える通信システムにおいて、前記中継装置として請求項１〜６のいずれかに記載の中継装置を適用したことを特徴とする通信システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信装置及び通信システムに関し、例えば、環境センサ等のデータ（例えば、センサデータ）出力を行うデバイス(以下、「データ出力装置」とも呼ぶ)と、デバイスから出力されたデータを収集して処理するサーバ（以下、「データ処理装置」とも呼ぶ）と、デバイスとサーバとの間の通信を中継するゲートウェイ（以下、「中継装置」とも呼ぶ）とを備える通信システムに適用し得る。
【背景技術】
【０００２】
近年、ネットワーク上ではＩｏＴ（Ｉｎｔｅｒｎｅｔ  ｏｆ  Ｔｈｉｎｇｓ、ＩｏＴ）／Ｍ２Ｍ（Ｍａｃｈｉｎｅ  ｔｏ  Ｍａｃｈｉｎｅ）によるトラフィック量が増加している。特に、多数のデバイスからのデータを収集して処理するサーバ周辺では、通信の輻輳が発生する場合がある。
【０００３】
従来、大量のデータを受信するサーバ周辺における輻輳制御方式として、特許文献１の記載技術がある。特許文献１では、データ受信を行うサーバ周辺のエッジルータ等の中継ノードで輻輳制御を行う方式について記載されている。特許文献１に記載されたシステムでは、サーバ側でネットワークを監視して輻輳が発生しているか否かを判定し、輻輳が発生している場合にサーバが所定の中継ノードに対して輻輳制御の通知を行い、当該中継ノードがサーバからの通知に基づいて輻輳制御を行う。また、当該中継ノードでは、上述の中継ノードパケットシェーピング（中継するトラヒックを平滑化して送出する方式）やＦＥＣ（Ｆｏｒｗａｒｄ  Ｅｒｒｏｒ  Ｃｏｒｒｅｃｔｉｏｎ；前方誤り訂正）制御（輻輳してパケットロスが生じた場合に誤り訂正によりデータ回復を行う方式）等の方式で輻輳制御を行う。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００６−３０４０２８号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、特許文献１の輻輳制御方式では、パケットシェーピングやＦＥＣ制御等の対症療法的な解決方法しか提示されていないため、輻輳の状態によっては、サーバ側でリアルタイムな情報収集が途切れる恐れがある。例えば、センサ（例えば、環境センサ）が出力するセンサデータをサーバで収集するシステムであった場合、データ収集が途切れると、収集したセンサデータに基づくリアルタイムな分析結果が異常となってしまう恐れがある。したがって、サーバでデータ収集するトラヒックは可能な限り途切れないことが望ましい。
【０００６】
また、特許文献１の輻輳制御方式では、サーバ側でネットワークの状態を監視することが前提となっているため、サーバ側でネットワークを監視できない状態になったり、そもそもサーバ側でネットワークを監視できない構成であった場合（例えば、通信キャリアの中継ノードにユーザ側からアクセスできない構成の場合）には、輻輳制御が不可能になるという問題があった。
【０００７】
そのため、データ出力装置（例えば、センサ等のデバイス）から出力されたデータをデータ処理装置に中継送信する際に、より確実に通信の輻輳を低減することが望まれている。
【課題を解決するための手段】
【０００８】
第１の本発明は、中継装置において、（１）データ出力装置から出力されたデータを受信するデータ受信手段と、（２）前記データ受信手段が受信したデータを、外部装置を宛先として送信するデータ送信手段と、（３）前記データ送信手段が送信したデータを受信した前記外部装置からの確認応答信号を受信する確認応答信号受信手段と、（４）前記確認応答信号受信手段による確認応答信号の受信状況に基づいて、当該中継装置から前記外部装置までの通信経路上の輻輳の有無を検出する検出手段と、（５）前記検出手段で前記通信経路上で輻輳有ると検出された場合、前記通信経路上の輻輳が軽減するように、前記データ送信手段の動作を制御する輻輳制御手段とを有することを特徴とする。
【０００９】
第２の本発明は、データを出力するデータ出力装置と、前記データ出力装置が出力したデータを収集して処理するデータ処理装置と、前記データ出力装置から出力されたデータを前記データ処理装置に送信する中継装置とを備える通信システムにおいて、前記中継装置として第１の本発明の中継装置を適用したことを特徴とする。
【００１０】
第３の本発明は、データ出力装置が出力したデータを収集して処理するデータ処理装置と、前記データ出力装置から出力されたデータを前記データ処理装置に送信する中継装置とを備える通信システムにおいて、前記中継装置として第１の本発明の中継装置を適用したことを特徴とする。
【発明の効果】
【００１１】
本発明によれば、データ出力装置から出力されたデータをデータ処理装置に中継送信する際に、より確実に通信の輻輳を低減することができる。
【図面の簡単な説明】
【００１２】
【図１】第１の実施形態に係る通信システムの動作について示したシーケンス図である。
【図２】第１の実施形態に係る通信システムの全体構成について示したブロック図である。
【図３】第１の実施形態に係るゲートウェイ（ＧＷ）のハードウェア構成について示したブロック図である。
【図４】第１の実施形態に係るサーバのハードウェア構成について示したブロック図である。
【図５】第１の実施形態に係るＧＷとサーバの通信におけるソフトウェア的なアーキテクチャ（プラットフォーム）の構成について示した説明図である。
【図６】第１の実施形態に係るＧＷを構成するアプレット（ＧＷ−ＡＰＬ）の機能的構成について示したブロック図である。
【図７】第１の実施形態に係るサーバを構成するアプレット（ＳＶ−ＡＰＬ）の機能的構成について示したブロック図である。
【図８】第１の実施形態に係るゲートウェイ（ＧＷ）が設定データを取得する動作について示したシーケンス図である。
【図９】第２の実施形態に係る通信システムの動作について示したシーケンス図である。
【発明を実施するための形態】
【００１３】
（Ａ）第１の実施形態
以下、本発明による中継装置及び通信システムの第１の実施形態を、図面を参照しながら詳述する。
【００１４】
（Ａ−１）第１の実施形態の構成
図２は、この実施形態の通信システム１の全体構成を示すブロック図である。
【００１５】
第１の実施形態の通信システム１は、Ｍ個のＧＷ２０（２０−１〜２０−Ｍ）と、サーバ３０とが配置されている。そして、それぞれのＧＷ２０の配下には、データ出力装置としてのＧＷ２０が１又は複数接続されている。図２では、各ＧＷ２０には、それぞれＮ個のセンサ１０（１０−１〜１０−Ｎ）が接続されているものとして図示しているが、各ＧＷ２０に接続されるセンサ１０の数は限定されないものである。また、図２において通信システム１には、センサ１０も含まれる構成として図示しているが、本発明の通信システムにはセンサ１０を含まない構成（ＧＷ２０とサーバ３０のみのシステムを販売）として実現する場合（例えば、ＧＷ２０とサーバ３０のみで通信システムを構築した後に、ユーザがＧＷ２０にセンサ１０を接続する場合）や、場合等も含まれるものとする。
【００１６】
各ＧＷ２０及びサーバ３０は、ネットワークＮに接続しており相互に通信することが可能な構成となっているものとする。この実施形態では、ネットワークＮは、ＴＣＰ／ＩＰ等により通信可能なＩＰネットワークであるものとして説明する。
【００１７】
各センサ１０は、例えば、温度、湿度、ひずみ、加速度等を検知する種々のセンサ（いわゆるセンサネットワークを構成するセンサ）を適用することができる。センサ１０は、所定のタイミングで検知結果のデータ（以下、「センサデータ」と呼ぶ）を上位のＧＷ２０に出力（供給）する。各センサ１０がセンサデータを出力するタイミングは限定されないものであるが、この実施形態では、例えば、一定間隔（例えば、５秒間隔）で検知及びセンサデータの出力処理を行うものとする。センサ１０とＧＷ２０との間の接続方式については限定されないものである。この実施形態では、センサ１０とＧＷ２０との間は、例えば、ＲＳ２３２、ＲＳ４８５、ＲＳ４２２、ＵＳＢ等のシリーズのシリアルインタフェースを適用することができる。また、センサ１０とＧＷ２０との間は、シリアルインタフェースに限らず、パラレルインタフェース（例えば、ＩＥＥＥ  １２８４等のインタフェース）や無線インタフェース（例えば、９２０ＭＨｚ帯無線通信やＢｌｕｅＴｏｏｔｈ（登録商標）等）を適用することができる。
【００１８】
サーバ３０は、ネットワークＮを介してＧＷ２０と通信し、各センサ１０からのセンサデータを受信して処理する装置である。この実施形態では、サーバ３０がセンサデータを受信（収集）し上位側（例えば、センサデータに基づく監視処理や統計的な処理等を行うアプリケーション）に引き渡すまでの構成を中心に説明する。
【００１９】
図２に示すように、この実施形態の例では、サーバ３０は、エッジルータＲを経由してネットワークＮに接続する構成となっているものとする。すなわち、この実施形態では、各ＧＷ２０から送出されたセンサデータのパケットは、エッジルータＲを経由してサーバ３０に供給されることになるものとする。したがって、通信システム１では、エッジルータＲとサーバ３０との間の通信路Ｃがボトルネックとなる可能性がある。例えば、エッジルータＲが通信キャリアの設備であり、通信路Ｃが高速とはいえないディジタル専用回線（例えば、１Ｍｂｐｓ以下のディジタル専用回線）であった場合、通信路Ｃがボトルネックとなり、サーバ３０に流れ込むセンサデータの量によってはエッジルータＲにセンサデータのパケットが滞留して輻輳状態になり得る。その場合、エッジルータＲでセンサデータのパケットが長期間滞留したり廃棄されたりすることになる。なお、サーバ３０と各ＧＷ２０との間のネットワーク構成については、図２の構成に限定されないものである。すなわち、サーバ３０と各ＧＷ２０との間で輻輳が発生する可能性のある経路は、図２の例に限らず種々のパターンが考えられる。
【００２０】
次に、ＧＷ２０（２０−１〜２０−Ｍ）の内部のハードウェア構成について、図３を用いて説明する。この実施形態では、各ＧＷ２０は全て同じ構成であるものとして説明するが、接続するセンサ１０の数等により基本的な構成を装置毎に変更するようにしてもよい。
【００２１】
図３に示すように、ＧＷ２０は、制御部２１、デバイス側ＩＦ部２２、及びネットワーク側ＩＦ部２３を有している。
【００２２】
制御部２１は、ＧＷ２０内の各構成要素を制御する機能を担っている。制御部２１は、例えば、図示しないプロセッサ及びメモリ等を有するコンピュータにプログラム（実施形態に係る、通信処理プログラムを含む）をインストールすることにより構成することができる。なお、制御部２１については、一部又は全部について専用の半導体チップ（例えば、ＡＳＩＣ：Ａｐｐｌｉｃａｔｉｏｎ  Ｓｐｅｃｉｆｉｃ  Ｉｎｔｅｇｒａｔｅｄ  Ｃｉｒｃｕｉｔ）を用いて構成するようにしてもよい。この実施形態の制御部２１は、ソフトウェア的には、後述するＪＡＶＡ（登録商標）仮想マシン（以下、「ＪＶＭ」とも表す）上のアプレットを用いて構成されているものとする。
【００２３】
デバイス側ＩＦ部２２は、配下のセンサ１０（１０−１〜１０−Ｎ）と接続するためのインタフェースを備えている。デバイス側インタフェース（以下、「ＩＦ」と呼ぶ）部２２は、各センサ１０（１０−１〜１０−Ｎ）と接続するためＩＦ部２４（２４−１〜２４−Ｎ）を備えている。図３に示すデバイス側ＩＦ部２２では、各ＩＦ部２４と各センサ１０とは１対１（ポイントツーポイント）で接続された構成として図示しているが、マルチ接続の構成（ＩＦ部２４から分岐したシリアルインタフェースを複数のセンサ１０に接続する構成）としてもよいことは当然である。
【００２４】
デバイス側ＩＦ部２２では、各ＩＦ部２４は固定的に備える構成としてもよいが、脱着可能な図示しないインタフェースカード（脱着可能なモジュール型デバイス）を用いて、種々の組み合わせのインタフェースを適用可能とするようにしてもよい。また、デバイス側ＩＦ部２２が備えるＩＦ部２４の数は、配下に接続するセンサ１０の数に応じて変動することもあり得る。
【００２５】
ネットワーク側ＩＦ部２３は、ネットワークＮに接続するためのインタフェースである。ネットワーク側ＩＦ部２３に適用されるインタフェースは、有線・無線に限定されず種々のインタフェースを適用することができる。ネットワーク側ＩＦ部２３としては、例えば、種々の有線／無線ＬＡＮインタフェースや、専用線用インタフェース（例えば、ディジタル専用回線に接続するためのインタフェース）や、携帯電話網に接続するための無線インタフェース（例えば、ＬＴＥ（Ｌｏｎｇ  Ｔｅｒｍ  Ｅｖｏｌｕｔｉｏｎ）等のネットワークインタフェース）を適用するようにしてもよい。
【００２６】
次に、サーバ３０のハードウェア構成について図４を用いて説明する。
【００２７】
図４に示すように、サーバ３０は、制御部３１及びネットワークＩＦ３２を有している。
【００２８】
サーバ３０は、ハードウェア的には、ＰＣやワークステーション等のコンピュータ上にプログラムをインストールすることにより構築することができる。
【００２９】
制御部３１は、例えば、図示しないプロセッサ及びメモリ等を有するコンピュータにプログラム（センサデータを受信して処理するプログラム）をインストールすることにより構成することができる。この実施形態の制御部３１は、ソフトウェア的には、後述するＪＶＭ（ＪＡＶＡ仮想マシン）上のアプレットを用いて構成されているものとする。
【００３０】
次に、ＧＷ２０とサーバ３０の通信におけるソフトウェア的なアーキテクチャ（プラットフォーム）の構成について図５を用いて説明する。
【００３１】
図５に示すように、ＧＷ２０及びサーバ３０では、いずれもＪＶＭ上のアプレットを用いてセンサデータの送受信処理を行う構成となっているものとする。ただし、ＧＷ２０及びサーバ３０において、センサデータの送受信処理を行うソフトウェア（プログラム）の具体的な構成（採用するプラットフォームや、分散処理の構成等）については限定されないものである。
【００３２】
ＧＷ２０の制御部２１上では、図５に示すように、ＪＶＭ２００上で、ＧＷ向けのアプレット（以下、「ＧＷ−ＡＰＬ」と呼ぶ）２０１が動作する構成となっているものとする。また、ＧＷ２０の制御部２１上では、ＪＶＭ２００（ＧＷ−ＡＰＬ２０１）をＴＣＰ／ＩＰの通信に対応させるドライバとしてのＴＣＰ／ＩＰ処理部２０２も動作しているものとする。
【００３３】
また、図５示すように、サーバ３０の制御部３１上においても、ＪＶＭ３００上で、サーバ３０向けのアプレット（以下、「ＳＶ−ＡＰＬ」と呼ぶ）３０１が動作する構成となっているものとする。また、サーバ３０の制御部３１上では、ＪＶＭ３００（ＳＶ−ＡＰＬ３０１）をＴＣＰ／ＩＰの通信に対応させるドライバとしてのＴＣＰ／ＩＰ処理部３０２も動作しているものとする。
【００３４】
この実施形態では、図５に示すように、ＧＷ−ＡＰＬ２０１及びＳＶ−ＡＰＬ３０１のレイヤでは、ＭＱＴＴ（ＭＱ  Ｔｅｌｅｍｅｔｒｙ  Ｔｒａｎｓｐｏｒｔ）パケットを用いて、センサデータの送受信処理を行うものとする。なお、ＭＱＴＴに替わって、ＨＴＴＰ（Ｈｙｐｅｒｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）やＣｏＡＰ（Ｃｏｎｓｔｒａｉｎｅｄ  Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）等の他のＩｏＴ関連プロトコルが使用されても構わない。
【００３５】
そして、ＴＣＰ／ＩＰ処理部２０２、３０２は、ＧＷ−ＡＰＬ２０１とＳＶ−ＡＰＬ３０１との間のＭＱＴＴパケットをＩＰパケットにカプセリングして、ＧＷ２０とサーバ３０との間の通信経路を形成しているものとする。このとき、ＴＣＰ／ＩＰ処理部２０２、３０２間のＩＰ通信については、ＩＰＳｅｃ（Ｓｅｃｕｒｉｔｙ  Ａｒｃｈｉｔｅｃｔｕｒｅ  ｆｏｒ  Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）等の手順により暗号化処理が施されていることが、セキュリティ上は望ましい。
【００３６】
図５に示す通り、ＪＶＭ２００（ＧＷ−ＡＰＬ２０１）は、センサ１０から出力されたセンサデータを取得する構成となっている。図５においては図示していないが、ＪＶＭ２００（ＧＷ−ＡＰＬ２０１）では、必要に応じて、デバイス側ＩＦ部２２（ＩＦ部２４）を介してセンサ１０からセンサデータを取得するドライバ（例えば、当該ＩＦ部２４に対応するシリアルインタフェースのドライバ）がインストールされているものとする。
【００３７】
次に、図５を用いて、ＧＷ−ＡＰＬ２０１とＳＶ−ＡＰＬ３０１との間のセンサデータに関する通信経路について説明する。
【００３８】
まず、ＧＷ２０のＧＷ−ＡＰＬ２０１がセンサ１０からセンサデータを取得し、サーバ３０のＳＶ−ＡＰＬ３０１に送信する際の経路について説明する。
【００３９】
ＧＷ−ＡＰＬ２０１は、サーバ３０（ＳＶ−ＡＰＬ３０１）を宛先とし、ペイロードにセンサデータ（後述する付加情報を含む）を設定したＭＱＴＴパケットを生成して、ＴＣＰ／ＩＰ処理部３０２に供給する。そして、ＴＣＰ／ＩＰ処理部２０２は、供給されたＭＱＴＴパケットをＩＰパケットにカプセリングしてネットワークＮ上に送出する。そして、ＧＷ２０のＴＣＰ／ＩＰ処理部２０２から送出されたセンサデータのＩＰパケットは、エッジルータＲ及び通信路Ｃを経由してサーバ３０のＴＣＰ／ＩＰ処理部３０２に到達する。ＴＣＰ／ＩＰ処理部３０２は、受信したセンサデータのＩＰパケットからセンサデータのＭＱＴＴパケットを抽出してＪＶＭ３００（ＳＶ−ＡＰＬ３０１）に供給する。そして、ＳＶ−ＡＰＬ３０１は、供給されたＭＱＴＴパケットからセンサデータ（後述する付加情報を含む）を取得する。
【００４０】
次に、サーバ３０のＳＶ−ＡＰＬ３０１がセンサ１０からセンサデータを受信したことのＡＣＫ（確認応答信号）のパケットを、ＧＷ２０のＧＷ−ＡＰＬ２０１に送信する際の経路について説明する。
【００４１】
ＳＶ−ＡＰＬ３０１は、センサデータを受信すると、センサデータの送信元（送信元のＧＷ２０のＧＷ−ＡＰＬ２０１）を宛先として、当該センサデータを受信したことを応答するＡＣＫ（確認応答）のＭＱＴＴパケットを生成し、ＴＣＰ／ＩＰ処理部３０２に供給する。そして、ＴＣＰ／ＩＰ処理部３０２は、供給されたＭＱＴＴパケットをＩＰパケットにカプセリングしてネットワークＮ側に送出する。そして、サーバ３０のＴＣＰ／ＩＰ処理部３０２から送出されたセンサデータのＩＰパケットは、通信路Ｃ及びエッジルータＲを経由してネットワークＮ上に送出され、ＧＷ２０のＴＣＰ／ＩＰ処理部２０２に到達する。ＴＣＰ／ＩＰ処理部２０２は、受信したＡＣＫのＩＰパケットからＡＣＫのＭＱＴＴパケットを抽出してＪＶＭ２００（ＧＷ−ＡＰＬ２０１）に供給する。そして、ＧＷ−ＡＰＬ２０１は、供給されたＭＱＴＴパケットからＡＣＫ（ＡＣＫのメッセージ）を取得する。
【００４２】
次に、ＧＷ−ＡＰＬ２０１内部の機能的構成について図６を用いて説明する。
【００４３】
ＧＷ−ＡＰＬ２０１はＪＶＭ２００上のアプレットであるが、機能的な構成（ソフトウェア／プログラムの機能的な構成）については図６のように示すことができる。
【００４４】
図６に示すように、ＧＷ−ＡＰＬ２０１は、制御処理部４１、通信処理部４２、センサデータ受信部４３、センサデータパケット生成部４４、及びデータ記憶部４５を有している。
【００４５】
制御処理部４１は、ＧＷ−ＡＰＬ２０１の全体動作を制御する機能（メインルーチンの機能）を担っている。
【００４６】
通信処理部４２は、ＴＣＰ／ＩＰ処理部２０２とＭＱＴＴパケットを送受信するインタフェースの機能を担っている。通信処理部４２は、センサデータパケット生成部４４から供給されたセンサデータのＭＱＴＴパケットをＴＣＰ／ＩＰ処理部３０２に供給する。また、通信処理部４２は、ＴＣＰ／ＩＰ処理部３０２から受信したＡＣＫのＭＱＴＴパケットを、制御処理部４１に供給する。
【００４７】
センサデータ受信部４３は、デバイス側ＩＦ部２２（ＩＦ部２４）に接続されたセンサ１０から出力されたセンサデータを受信する機能を担っている。センサデータ受信部４３は、例えば、センサ１０からシリアルインタフェースとしてのＩＦ部２４を介して、一連のデータフレーム（シリアル信号の１つのデータ送信単位）が出力されると、当該データフレームをセンサデータとして取得し、センサデータパケット生成部４４に供給する。
【００４８】
センサデータパケット生成部４４は、センサデータ受信部４３から供給されたセンサデータ（後述する付加情報を含む）をペイロードに設定したＭＱＴＴパケット（サーバ３０のＳＶ−ＡＰＬ３０１を宛先とするＭＱＴＴパケット）を生成して、通信処理部４２に供給する。この実施形態では、センサデータパケット生成部４４は、センサデータに付加情報を付加したデータをセンサデータパケットにセットするものとする。付加情報には当該センサデータの供給元のセンサ１０の識別子（以下、「センサＩＤ」と呼ぶ）と、当該センサデータの観測時間（例えば、センサデータ受信部４３が当該センサデータを受信した時刻）とが含まれるものとする。通信システム１では、各センサ１０についてユニークとなるセンサＩＤが割り振られているものとする。なお、センサデータの付加情報の項目は上述の例に限定されない。また、サーバ３０側で特に必要がなければ、ＧＷ２０が送信するセンサデータに付加情報を付加する必要はない。
【００４９】
制御処理部４１は、ＡＣＫパケットの受信状況に応じてサーバ３０までの間の通信経路上の輻輳状態（以下、「通信輻輳状態」と呼ぶ）を判断し、その判断結果に応じて、センサデータパケット生成部４４を制御する。この実施形態の制御処理部４１は、センサデータパケットを送信してからＡＣＫパケットを受信するまでの応答時間に基づいて輻輳状態（輻輳の有無）を判断するものとする。
【００５０】
制御処理部４１は、通信処理部４２がセンサデータ（付加情報を含む）のＭＱＴＴパケットを送信してから、当該センサデータの送信に対して応答するＡＣＫのＭＱＴＴパケットが供給されるまでの時間を、所定のタイムアウト時間Ｔを限度としてタイマ計測（計時）する。具体的には、制御処理部４１は、センサデータのＭＱＴＴパケットを送信した時点でタイマをセットし、タイムアウト時間Ｔ以内にＡＣＫパケットを受信しなかった場合タイムアウトを検知する。タイムアウト時間Ｔに設定する時間は限定されないものであるが、例えば、３０秒程度の値を設定するようにしてもよい。
【００５１】
制御処理部４１は、通信輻輳状態であると判断した場合、センサデータパケット生成部４４を制御し、輻輳（サーバ３０までの通信経路上の輻輳）を制御（軽減）する処理（以下、「輻輳制御処理」と呼ぶ）を開始させる。具体的には、制御処理部４１は、輻輳制御処理として、センサデータを所定の方式で圧縮処理してからＭＱＴＴパケットに設定するようにセンサデータパケット生成部４４を制御する処理を行う。また、制御処理部４１は、通信輻輳状態から通常の状態（通信輻輳状態でない状態）に復帰したことを確認すると、輻輳制御処理を終了する制御（センサデータの圧縮処理を解除する制御）を行う。センサデータパケット生成部４４で用いられる圧縮方式は限定されないものであり種々のデータ圧縮方式（例えば、ＺＩＰやｒａｒ等）を適用することができる。
【００５２】
データ記憶部４５は、制御処理部４１が行う制御処理で用いられる種々の設定データ等が記憶されている領域である。第１の実施形態において、データ記憶部４５には、センサデータを送信からＡＣＫを受信するまでのタイムアウト時間Ｔ等が格納されている。データ記憶部４５には、予めタイムアウト時間Ｔを設定しておくようにしてもよいし、所定のタイミング（例えば、起動時や所定の期間ごとのタイミング）で、サーバ３０等の外部装置から取得するようにしてもよい。
【００５３】
次に、ＳＶ−ＡＰＬ３０１内部の機能的構成について図７を用いて説明する。
【００５４】
ＳＶ−ＡＰＬ３０１はＪＶＭ３００上のアプレットであるが、機能的な構成（ソフトウェア／プログラムの機能的な構成）については図７のように示すことができる。
【００５５】
図７に示すように、ＳＶ−ＡＰＬ３０１は、制御処理部５１、通信処理部５２、センサデータ抽出部５３、センサデータ処理部５４、及びデータ記憶部５５を有している。
【００５６】
制御処理部５１は、ＳＶ−ＡＰＬ３０１の全体動作を制御する機能（メインルーチンの機能）を担っている。また、制御処理部５１は、オペレータの操作（例えば、ＧＵＩ画面やコマンドラインを用いた操作）に応じて、各ＧＷ２０に対する設定制御処理（例えば、タイムアウト時間Ｔ等の設定データの設定処理）に対応するようにしてもよい。
【００５７】
通信処理部５２は、ＴＣＰ／ＩＰ処理部３０２との間でＭＱＴＴパケットを送受信するインタフェースの機能を担っている。通信処理部５２は、ＴＣＰ／ＩＰ処理部３０２から受信したセンサデータのＭＱＴＴパケットを、センサデータ抽出部５３に供給する。また、通信処理部５２は、センサデータのＭＱＴＴパケットを受信すると、制御処理部５１の制御に基づき、当該受信に応答するＡＣＫのＭＱＴＴパケットを生成して、センサデータのＭＱＴＴパケットの送信元に送信（返答）する処理を行う。
【００５８】
センサデータ抽出部５３は、通信処理部５２から供給されたセンサデータのＭＱＴＴパケットからセンサデータ（当該センサデータに付加された付加情報を含む）を抽出して、センサデータ処理部５４に供給するものである。センサデータ抽出部５３は、受信したＭＱＴＴパケットのペイロードが圧縮されている場合には、圧縮データを解凍（復元）してセンサデータを取得する。センサデータ抽出部５３では、ＧＷ２０側で用いられた圧縮方式に対応する解凍（復元）処理を行う。
【００５９】
センサデータ処理部５４は、供給されたセンサデータについて所定の処理を行う。センサデータ処理部５４がセンサデータを処理する内容については限定されないものである。センサデータ処理部５４は、例えば、センサデータをリアルタイムに監視する処理（例えば、グラフの出力する処理や、異常等の検知結果を出力する処理）を行ったり、図示しない上位アプリケーション（例えば、リアルタイムにセンサデータを監視するアプリケーション）や上位装置に供給する処理を行うようにしてもよい。センサデータの処理（例えば、監視方式）の具体的な内容については、種々のセンサデータを処理するアプリケーションと同様の処理を適用することができるため、ここでは詳しい説明を省略する。
【００６０】
データ記憶部５５は、制御処理部５１が行う制御処理で用いられる種々の設定データ等が記憶されている領域である。
【００６１】
（Ａ−２）第１の実施形態の動作
次に、以上のような構成を有する第１の実施形態の通信システム１の動作を説明する。
【００６２】
まず、ＧＷ２０において、タイムアウト時間Ｔ等の設定データ（パラメータ）を、サーバ３０から取得するとした場合の動作の例について図８を用いて説明する。
【００６３】
図８（ａ）では、ＧＷ２０が起動時にサーバ３０から設定データをダウンロードする例について示したシーケンス図である。
【００６４】
図８では、まず、ＧＷ２０（ＧＷ−ＡＰＬ２０１）は起動すると（Ｓ１１１）、サーバ３０（ＴＣＰ／ＩＰ処理部２０２）と通信（例えば、センサデータと同じ経路で通信して設定データを要求する（Ｓ１１２）。
【００６５】
次に、サーバ３０（ＳＶ−ＡＰＬ３０１）は、ＧＷ２０からの設定データの要求を受付けると最新の設定データ（必要に応じて各ＧＷ２０の固有データ）を返答する（Ｓ１１３）。
【００６６】
そして、ＧＷ２０（ＧＷ−ＡＰＬ２０１）は、サーバ３０（ＳＶ−ＡＰＬ３０１）から受信した設定データを記憶（データ記憶部４５に記憶）する（Ｓ１１４）。
【００６７】
図８（ｂ）では、サーバ３０（ＳＶ−ＡＰＬ３０１）が、オペレータの操作に応じてＧＷ２０（ＧＷ−ＡＰＬ２０１）に設定データを設定する例について説明する。
【００６８】
図８（ｂ）では、まず、サーバ３０（ＳＶ−ＡＰＬ３０１）がオペレータの操作（例えば、ＧＵＩ操作やコマンドラインによる操作）に応じて、指定されたＧＷ２０に対する設定データの入力を受付けて（Ｓ１２１）、指定されたＧＷ２０に送信する（Ｓ１２２）。なお、このとき、サーバ３０（ＳＶ−ＡＰＬ３０１）は、同時に複数のＧＷ２０の設定を受付けるようにしてもよい。
【００６９】
そして、設定データを受信したＧＷ２０（ＧＷ−ＡＰＬ２０１）は、受信した設定データを記憶（データ記憶部４５に記憶）する（Ｓ１２３）。
【００７０】
次に、通信システム１の全体の動作の例について図１のシーケンス図を用いて説明する。
【００７１】
図１のシーケンス図では、例として、ＧＷ２０−１がセンサ１０−１、１０−２から取得したセンサデータを、サーバ３０に送信する例について示している。
【００７２】
図１に示すとおり、ここでは、まず、センサ１０−１がＧＷ２０−１にセンサデータを送信したものとする（Ｓ２０１）。
【００７３】
センサ１０−１からセンサデータが供給されると、ＧＷ２０−１（ＧＷ−ＡＰＬ２０１及びＴＣＰ／ＩＰ処理部３０２）は、当該センサデータをセットしたパケット（ＭＱＴＴパケットをＩＰでカプセリングしたパケット）を生成して、サーバ３０に送信する（Ｓ２０２）。この時点では、ＧＷ２０−１（ＧＷ−ＡＰＬ２０１）は、輻輳制御処理を開始しておらず、圧縮（ＭＱＴＴのペイロードを圧縮）していないセンサデータを送信したものとする。
【００７４】
次に、サーバ３０（ＳＶ−ＡＰＬ３０１及びＴＣＰ／ＩＰ処理部３０２）は、ＧＷ２０−１からのセンサデータのパケットを受信すると、当該パケット（ＭＱＴＴパケットをＩＰでカプセリングしたパケット）からセンサデータを抽出して、ＡＣＫパケットを返信する（Ｓ２０３）。そして、ここでは、ＧＷ２０−１（ＧＷ−ＡＰＬ２０１）で、センサデータパケットを送信（ステップＳ２０２で送信）してからタイムアウト時間Ｔ以内にＡＣＬパケットが受信されたものとする。
【００７５】
そして、その後、センサ１０−２がＧＷ２０−１にセンサデータを送信したものとする（Ｓ２０４）。
【００７６】
センサ１０−２からセンサデータが供給されると、ＧＷ２０−１は、当該センサデータをセットしたパケットを生成して、サーバ３０に送信する（Ｓ２０５）。この時点では、ＧＷ２０−１（ＧＷ−ＡＰＬ２０１）は、輻輳制御処理を開始していないため、圧縮していないセンサデータを送信する。
【００７７】
そして、その後、サーバ３０（ＳＶ−ＡＰＬ３０１及びＴＣＰ／ＩＰ処理部３０２）は、ＧＷ２０−１からのセンサデータのパケットを受信してＡＣＫパケットを返答する処理を行ったものとする（Ｓ２０６）。しかしながら、ここでは、ＧＷ２０−１とＧＷ２０−１との間の通信経路上の輻輳（例えば、エッジルータＲとサーバ３０との間の通信路Ｃがボトルネックになったことに起因するエッジルータＲ上の輻輳）により、タイムアウト時間Ｔが経過するまでの間に、ＧＷ２０−１（ＧＷ−ＡＰＬ２０１）に当該ＡＣＫパケットは到達しなかったものとする。
【００７８】
そうすると、ＧＷ２０−１（ＧＷ−ＡＰＬ２０１）において、タイムアウトが発生し、通信輻輳状態が検知され、輻輳制御処理が開始されることになる（Ｓ２０７）。ＧＷ２０−１（ＧＷ−ＡＰＬ２０１）は、輻輳制御処理が継続している間は、センサデータのパケットを生成する際に、センサデータを圧縮してＭＱＴＴパケットのペイロードに挿入することになる。
【００７９】
そして、その後、センサ１０−１がＧＷ２０−１にセンサデータを送信したものとする（Ｓ２０８）。
【００８０】
センサ１０−１からセンサデータが供給されると、ＧＷ２０−１は、当該センサデータをセットしたパケットを生成して、サーバ３０に送信する（Ｓ２０９）。この時点では、ＧＷ２０−１（ＧＷ−ＡＰＬ２０１）は、輻輳制御処理を開始（継続）しているため、センサデータを圧縮してＭＱＴＴのペイロードに挿入したパケットが送信されることになる。
【００８１】
そして、この時点においても未だ、ＧＷ２０−１とＧＷ２０−１との間の通信経路上の輻輳が解消されておらず、タイムアウト時間Ｔが経過するまでの間に、ＧＷ２０−１（ＧＷ−ＡＰＬ２０１）に当該ＡＣＫパケットは到達しなかったものとする（Ｓ２１０））。したがって、この時点でもＧＷ２０−１（ＧＷ−ＡＰＬ２０１）は、輻輳制御処理を解除せずに継続することになる。
【００８２】
例えば、エッジルータＲとサーバ３０との間の通信路Ｃがボトルネックになったことに起因するエッジルータＲ上の輻輳が発生した場合を想定する。そして、各ＧＷ２０−１〜２０−Ｍが輻輳制御処理を開始して、センサデータを圧縮して送信するため、通信路Ｃ上のトラヒックは徐々に低減してゆき、通信輻輳状態が解消した状態（タイムアウト時間Ｔ以内にＡＣＫパケットがＧＷ２０に到達できる状態）となると、各ＧＷ２０（ＧＷ−ＡＰＬ２０１）は、輻輳制御処理を終了（センサデータの圧縮処理を解除）することになる。
【００８３】
ここでは、ステップＳ２１０の後のタイミングで、通信路Ｃ上のトラヒックは徐々に低減して、通信輻輳状態が解消した状態となったものとする。
【００８４】
そして、通信輻輳状態が解消した後、センサ１０−２からセンサデータがＧＷ２０−１（ＧＷ−ＡＰＬ２０１）に供給されたものとする（Ｓ２１１）。
【００８５】
センサ１０−２からセンサデータが供給されると、ＧＷ２０−１は、当該センサデータをセットしたパケットを生成して、サーバ３０に送信する（Ｓ２１２）。この時点では、通信輻輳状態が解消していたとしても、ＧＷ２０−１（ＧＷ−ＡＰＬ２０１）は、未だ輻輳制御処理を継続している状態である。したがって、この時点では、ＧＷ２０−１（ＧＷ−ＡＰＬ２０１）は、センサデータを圧縮してＭＱＴＴのペイロードに挿入したパケットを送信することになる。
【００８６】
そして、サーバ３０（ＳＶ−ＡＰＬ３０１及びＴＣＰ／ＩＰ処理部３０２）は、ＧＷ２０−１からのセンサデータのパケットを受信すると、当該パケットからセンサデータを抽出して、ＡＣＫパケットを返信する（Ｓ２１３）。上述の通り、この時点では、通信輻輳状態が解消しているため、ＧＷ２０−１（ＧＷ−ＡＰＬ２０１）でタイムアウト時間Ｔ以内にＡＣＫパケットが受信されたものとする。
【００８７】
そうすると、ＧＷ２０−１（ＧＷ−ＡＰＬ２０１）では、通信輻輳状態の解消が検知され、輻輳制御処理が終了（圧縮処理を終了）することになる（Ｓ２１４）。以後、ＧＷ２０−１（ＧＷ−ＡＰＬ２０１）は、輻輳制御処理が再開するまでの間は、センサデータのパケットを生成する際に、センサデータを圧縮せずにＭＱＴＴパケットのペイロードに挿入することになる。
【００８８】
そして、その後、センサ１０−１からセンサデータがＧＷ２０−１（ＧＷ−ＡＰＬ２０１）に供給されたものとする（Ｓ２１５）。
【００８９】
センサ１０−１からセンサデータが供給されると、ＧＷ２０−１は、当該センサデータをセットしたパケットを生成して、サーバ３０に送信する（Ｓ２１６）。この時点では、ＧＷ２０−１（ＧＷ−ＡＰＬ２０１）は、輻輳制御処理を開始していないため、圧縮していないセンサデータを送信する。
【００９０】
そして、サーバ３０（ＳＶ−ＡＰＬ３０１及びＴＣＰ／ＩＰ処理部３０２）は、ＧＷ２０−１からのセンサデータのパケットを受信すると、当該パケットからセンサデータを抽出して、ＡＣＫパケットを返信する（Ｓ２１７）。
【００９１】
（Ａ−３）第１の実施形態の効果
第１の実施形態によれば、以下のような効果を奏することができる。
【００９２】
第１の実施形態の通信システム１では、ＧＷ２０が、ＡＣＫパケットの受信状況に基づいてサーバ３０との間の通信輻輳状態の有無を検出し、通信輻輳状態を検出した場合には、輻輳制御処理として送信するセンサデータ（付加情報を含む）の圧縮を行う。これにより、第１の実施形態では、ネットワークＮの構成（各ＧＷ２０からサーバ３０までの通信経路の構成）に依存せずに輻輳制御が可能となる。
【００９３】
（Ｂ）第２の実施形態
以下、本発明による中継装置及び通信システムの第２の実施形態を、図面を参照しながら詳述する。
【００９４】
（Ｂ−１）第２の実施形態の構成
第２の実施形態の通信システム１の構成についても、上述の図２〜図７を用いて示すことができる。以下では、第２の実施形態の通信システム１の構成について第１の実施形態の差異のみを説明する。
【００９５】
第１の実施形態のＧＷ２０を構成する制御処理部４１は、通信輻輳状態（サーバ３０までの通信経路上で輻輳が発生している状態）と判断した場合、輻輳制御処理として、センサデータパケット生成部４４を制御し、センサーデータ（付加情報を含む）を圧縮して送信させる処理を行う。これに対して、第２の実施形態の制御処理部４１は、通信輻輳状態と判断した場合、輻輳制御処理として、各ＧＷ２０に設定された遅延時間αだけ時間をずらして（タイミングを遅らせて）センサデータのパケットを送出させるようにセンサデータパケット生成部４４を制御する処理を行う。すなわち、第２の実施形態のＧＷ２０では、設定データ（データ記憶部４５に記憶する設定データ）として、タイムアウト時間Ｔに加えて、遅延時間αを記憶しているものとする。
【００９６】
そして、第２の実施形態のセンサデータパケット生成部４４は、生成したセンサデータパケットについて、制御処理部４１の制御に従った遅延時間αだけ保留してから送信（通信処理部４２に供給）する処理を行う。
【００９７】
また、この実施形態では、ＧＷ２０−１〜２０−Ｍに対して、それぞれ遅延時間α１〜αＭが設定されているものとして説明する。遅延時間α１〜αＭは全て異なる時間（各ＧＷ２０について固有の時間）としてもよいし、通信システム１上のＧＷ２０を複数のグループに分けて各グループに固有の時間としてもよい。
【００９８】
これにより、第２の実施形態では、通信輻輳状態となった場合でも、各にＧＷ２０−１〜２０−Ｍに固有の遅延時間α１〜αＭを設定することにより、ＧＷ２０−１〜２０−Ｍからセンサデータパケットを送出させるタイミングを分散させ、通信輻輳状態を制御（軽減）することができる。
【００９９】
（Ｂ−２）第２の実施形態の動作
次に、以上のような構成を有する第２の実施形態の通信システム１の動作を説明する。
【０１００】
図９は、第２の実施形態の通信システム１の全体の動作の例について示したシーケンス図である。図９では、上述の図１と同一の動作には同一のステップ番号（符号）を付している。
【０１０１】
図９では、ステップＳ２０９、Ｓ２１２が、ステップＳ２０９Ａ、Ｓ２１２Ａに置き換わっている点で上述の図１と異なっている。
【０１０２】
以下では、第２の実施形態の動作について、第１の実施形態との差異を説明する。
【０１０３】
上述の通り、第２の実施形態では、輻輳制御処理の内容だけが異なっているため、以下では第２の実施形態における輻輳制御処理を中心に説明する。
【０１０４】
図９では、ＧＷ２０−１（ＧＷ−ＡＰＬ２０１）において、ステップＳ２０７で輻輳制御処理を開始してから、ステップＳ２１４で輻輳制御処理が終了するまでの間、輻輳制御処理として、センサデータパケットを送信する際に、ＧＷ２０−１に設定された遅延時間α１だけ遅延させる制御が行われる。具体的には、図９では、ＧＷ２０（ＧＷ−ＡＰＬ２０１）で輻輳制御処理が継続している期間、ステップＳ２０９Ａ、Ｓ２１２Ａでセンサデータパケットを送信する際に、送信タイミングを遅延時間α１だけ遅延させる制御が行われる。
【０１０５】
（Ｂ−３）第２の実施形態の効果
第２の実施形態によれば、以下のような効果を奏することができる。
【０１０６】
第２の実施形態の通信システム１では、ＧＷ２０が、ＡＣＫパケットの受信状況に基づいてサーバ３０との間の通信輻輳状態の有無を検出し、通信輻輳状態を検出した場合には、各ＧＷ２０が、センサデータのパケットを送信するタイミングを、固有の遅延時間α分だけ遅延させる処理を行う。これにより、第２の実施形態の通信システム１では、各ＧＷ２０で通信輻輳状態が検出された場合、各ＧＷ２０によるセンサデータのパケット送信のタイミングを分散させて、通信輻輳状態を軽減させることができる。これにより、第２の実施形態では、第１の実施形態と同様にネットワークＮの構成（各ＧＷ２０からサーバ３０までの通信経路の構成）に依存せずに輻輳制御が可能となる。
【０１０７】
（Ｃ）他の実施形態
本発明は、上記の実施形態に限定されるものではなく、以下に例示するような変形実施形態も挙げることができる。
【０１０８】
（Ｃ−１）第２の実施形態において、各ＧＷ２０で通信輻輳状態が検出された場合、各ＧＷ２０に、センサデータのパケット送信タイミングを分散（遅延）させるだけでなく、第１の実施形態と同様にセンサデータの圧縮処理を実行させるようにしてもよい。
【０１０９】
（Ｃ−２）上記の各実施形態において、ＧＷ２０（ＧＷ−ＡＰＬ２０１）は、センサデータのパケットを送出してからタイムアウト時間Ｔを経過するまでの間にＡＣＫパケットが受信できない場合（タイムアウトが発生した場合）、通信輻輳状態と判断するが、一度のセンサパケットだけでなく複数のセンサパケットで連続してタイムアウトが発生した場合に輻輳状態を判断するようにしてもよい。例えば、ＧＷ２０（ＧＷ−ＡＰＬ２０１）は、５回連続してタイムアウトが発生した場合（５回連続してセンサデータのパケットを送信しても１度もタイムアウト時間Ｔ以内にＡＣＫパケットを受信できない場合）に、通信輻輳状態を判断するようにしてもよい。
【０１１０】
（Ｃ−３）上記の各実施形態の通信システムでは、データを出力するデータ出力装置としてセンサを適用する例について説明したが、本発明の通信システムにおけるデータ出力装置は、センサに限定されず、種々のデータ出力を行う端末を適用することができる。例えば、本発明の通信システムにおいて、ＩｏＴに対応した家電製品（例えば、種々のイベントデータを出力する冷蔵庫、エアコン、給湯器等）をデータ出力装置として適用するようにしてもよい。
【符号の説明】
【０１１１】
１…通信システム、１０、１０−１〜１０−Ｎ…センサ、２０、２０−１〜２０−Ｍ…ＧＷ、２１…制御部、２２…デバイス側ＩＦ部、２３…ネットワーク側ＩＦ部、２４、２４−１〜２４−Ｎ…ＩＦ部、２００…ＪＶＭ、２０１…ＧＷ−ＡＰＬ、２０２…ＴＣＰ／ＩＰ処理部、３０…サーバ、３１…制御部、３２…ネットワークＩＦ、３００…ＪＶＭ、３０１…ＳＶ−ＡＰＬ、３０２…ＴＣＰ／ＩＰ処理部、４１…制御処理部、４２…通信処理部、４３…センサデータ受信部、４４…センサデータパケット生成部、４５…データ記憶部、５１…制御処理部、５２…通信処理部、５３…センサデータ抽出部、５４…センサデータ処理部、５５…データ記憶部、Ｎ…ネットワーク、Ｒ…エッジルータ、Ｃ…通信路。
【図１】
2018019266.tif 000003
【図２】
2018019266.tif 000004
【図３】
2018019266.tif 000005
【図４】
2018019266.tif 000006
【図５】
2018019266.tif 000007
【図６】
2018019266.tif 000008
【図７】
2018019266.tif 000009
【図８】
2018019266.tif 000010
【図９】
2018019266.tif 000011