JP6047794B2 - 中継装置、中継システム及び中継方法 - Google Patents

Description

本発明は、ネットワークにおけるデータ送信方法の技術に関する。

従来、センサネットワーク内に設置されている複数のセンサ機器（以下、「ノード」という。）が収集したセンサデータを、ネットワークを中継してクラウド上のサーバに送信することによって、サーバに様々な場所におけるセンサデータを集約させている。集約された各地のセンサデータを利用することで、新しいサービスの提供や業務の効率化が可能になる。しかし、複数のノードがネットワークを経由してサーバにセンサデータを送信する場合、データサイズの小さいパケットが定期的にサーバに送信される。そのため、センサデータを受信するサーバの処理負荷や、ネットワークにおけるパケットの処理負荷が大きくなってしまう。
このような問題に対して、サーバやネットワークの負荷を軽減させる技術が複数提案されている。例えば、ノードからサーバへの送信間隔を制御することにより、サーバ側の処理負荷を軽減する技術が提案されている（例えば、特許文献１参照）。また、子ノードのデータを親ノードで集約してサーバに送信することにより、ネットワークの負荷を軽減する技術が提案されている（例えば、特許文献２参照）。

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

しかしながら、特許文献１の技術では、パケットの送信間隔を変更することによりサーバ側の処理負荷を軽減することはできるが、ネットワークの負荷を軽減することができない。また、特許文献２の技術では、サーバ側の処理負荷やネットワークにおける負荷を軽減することはできるが、ノードがパケットを集約する必要があるため、ノードの処理が複雑化してしまう。そのため、ノードの処理負荷が大きくなってしまうという問題が生じてしまう。このように、従来の技術では、ノードからサーバに対してセンサデータを送信する際に、ネットワークあるいはノードの負荷を軽減できないという問題があった。

上記事情に鑑み、本発明は、センサネットワークにおけるデータ送信の際に生じる負荷を軽減する技術の提供を目的としている。

本発明の一態様は、ノードから送信された蓄積情報が付与されたパケットを送信先ごとに蓄積して記憶するデータベースと、前記データベースに記憶されている蓄積された前記パケットをサーバに送信する間隔を管理するタイマー管理部と、前記間隔で蓄積された前記パケットをサーバに送信する通信部と、を備える中継装置である。

本発明の一態様は、上記の中継装置であって、前記パケットのサイズ情報を取得する取得部と、自装置と前記サーバとの接続時に取得される前記パケットを送信可能な最大のサイズ情報と、前記パケットのサイズ情報とに基づいて、前記データベースに蓄積される前記パケットの集約可能数を算出する集約数算出部と、を更に備え、前記通信部は、前記集約可能数に基づいて、蓄積された前記パケットをサーバに送信する。

本発明の一態様は、複数のノードと、前記ノードから送信されるパケットをサーバに中継する中継装置とを備えたシステムであって、前記ノードは、周囲の空間情報を表すデータを収集するセンサと、前記センサによって収集された前記データを含むパケットを前記中継装置に送信する通信部と、を備え、前記中継装置は、ノードから送信された蓄積情報が付与されたパケットを送信先ごとに蓄積して記憶するデータベースと、前記データベースに記憶されている蓄積された前記パケットをサーバに送信する間隔を管理するタイマー管理部と、前記間隔で蓄積された前記パケットをサーバに送信する通信部と、を備える中継システムである。

本発明の一態様は、ノードから送信された蓄積情報が付与されたパケットを送信先ごとに蓄積してデータベースに記憶する記憶ステップと、前記データベースに記憶されている蓄積された前記パケットをサーバに送信する間隔を管理するタイマー管理ステップと、前記間隔で蓄積された前記パケットをサーバに送信する通信ステップと、を有する中継方法である。

本発明により、センサネットワークにおけるデータ送信の際に生じる負荷を軽減することが可能となる。

本実施形態における中継システムのシステム構成を示す図である。 ＧＷ機器２０の機能構成を表す概略ブロック図である。 リクエストメッセージを蓄積する方法の具体例を表す図である。 バッファリングオプションが記述されていないリクエストメッセージの具体例を示す図である。 本実施形態における送信間隔算出処理の流れの具体例を示すフローチャートである。 本実施形態におけるセンサデータ送信処理の流れの具体例を示すフローチャートである。 本実施形態におけるセンサデータ送信処理の動作の具体例を示すシーケンス図である。

以下、本発明の一実施形態を、図面を参照しながら説明する。
図１は、本実施形態における中継システムのシステム構成を示す図である。本実施形態の中継システムは、複数のノード１０−１〜１０−３、ＧＷ（Gate Way）機器２０、サーバ３０及びネットワーク５０を備える。なお、以下の説明では、ノード１０−１〜１０−３について特に区別しない場合には、ノード１０と記載する。

ノード１０は、センサ付きの無線端末であり、自装置の周囲の空間情報を収集する。空間情報とは、ノード１０に付与されているセンサが検知する情報であり、例えば自装置の周囲の温度や湿度などの情報である。また、ノード１０は、収集した空間情報（センサデータ）を周期的にＧＷ機器２０に送信する。ノード１０は、様々な場所に配置されることによって、センサネットワーク４０を形成する。
ＧＷ機器２０は、ノード１０とネットワーク５０との間で通信の中継を行う中継装置である。ＧＷ機器２０は、ノード１０から送信されたセンサデータを、ネットワーク５０を介してサーバ３０に送信する。

サーバ３０は、情報処理装置を用いて構成され、ＧＷ機器２０から送信されたセンサデータを収集する。
センサネットワーク４０は、複数のノード１０によって形成される。
ネットワーク５０は、どのように構成されたネットワークでもよい。例えば、ネットワーク５０はインターネットを用いて構成されてもよい。

図２は、ＧＷ機器２０の機能構成を表す概略ブロック図である。ＧＷ機器２０は、バスで接続されたＣＰＵ（Central Processing Unit）やメモリや補助記憶装置などを備え、中継プログラムを実行する。中継プログラムの実行によって、ＧＷ機器２０は、通信部２０１、制御部２０２、取得部２０３、集約数算出部２０４、受信間隔算出部２０５、送信間隔算出部２０６、解析部２０７、タイマー管理部２０８、データベース２０９、生成部２１０を備える装置として機能する。なお、ＧＷ機器２０の各機能の全て又は一部は、ＡＳＩＣ（Application Specific Integrated Circuit）やＰＬＤ（Programmable Logic Device）やＦＰＧＡ（Field Programmable Gate Array）等のハードウェアを用いて実現されても良い。また、中継プログラムは、コンピュータ読み取り可能な記録媒体に記録されても良い。コンピュータ読み取り可能な記録媒体とは、例えばフレキシブルディスク、光磁気ディスク、ＲＯＭ、ＣＤ−ＲＯＭ等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置である。また、中継プログラムは、電気通信回線を介して送受信されても良い。

通信部２０１は、ノード１０との間で無線通信を行う。また、通信部２０１は、サーバ３０との間で通信を行う。例えば、通信部２０１は、ノード１０からセンサデータが格納されているリクエストメッセージを受信し、サーバ３０に送信する。また、通信部２０１は、サーバ３０から送信されたレスポンスメッセージを受信し、ノード１０に送信する。また、通信部２０１は、サーバ３０との間で接続を確立する際に、ＭＳＳ（Maximum Segment Size）の値を取得する。ＭＳＳは、一度の通信においてパケットを送信可能な最大のサイズを表す。
制御部２０２は、ＧＷ機器２０の各機能部を制御する。

取得部２０３は、一定期間（例えば、３０分、１時間など）の間、ノード１０からサーバ３０に対して周期的に送信されるセンサデータのパケットを収集する。例えば、取得部２０３は、ＷｉｒｅＳｈａｒｋ（登録商標）によってノード１０からサーバ３０に対して送信されるセンサデータのパケットを収集する。その後、取得部２０３は、収集したパケットからヘッダーサイズ及びボディサイズの各値を取得する。ボディサイズ（サイズ情報）とは、パケットのペイロードに格納されているセンサデータのサイズを表す。
集約数算出部２０４は、ＭＳＳの値と取得されたヘッダーサイズ及びボディサイズの各値とを用いて、集約可能数を算出する。集約可能数とは、自装置（ＧＷ機器２０）からサーバ３０に対して送信される一つのパケットに集約できるセンサデータの数を表す。

受信間隔算出部２０５は、取得部２０３によって周期的に収集されるセンサデータのパケットに基づいて、センサデータの受信間隔を算出する。例えば、受信間隔算出部２０５は、収集されたセンサデータのパケットの受信時刻と、当該パケットの収集後に収集されたセンサデータのパケットの受信時刻との差分に基づいて、センサデータの受信間隔を算出する。
送信間隔算出部２０６は、集約数算出部２０４によって算出された集約可能数と、受信間隔算出部２０５によって算出された受信間隔とに基づいて、自装置（ＧＷ機器２０）からサーバ３０に対してセンサデータを送信する送信間隔を算出する。例えば、送信間隔算出部２０６は、集約可能数の値と受信間隔の値とを乗算した値を送信間隔として算出する。送信間隔算出部２０６は、算出した送信間隔をタイマー管理部２０８に通知する。

解析部２０７は、ノード１０から送信されたリクエストメッセージを解析する。具体的には、まず、解析部２０７は、通信部２０１が受信したリクエストメッセージからリクエストメソッド、リクエストＵＲＬ（Uniform Resource Locator）、リクエストＵＲＩ（Uniform Resource Identifier）及びリクエストボディの各値を取得する。リクエストメソッドとは、リクエストメッセージを受信したリソースに対して要求する処理を表す。リクエストＵＲＬとは、リクエストメッセージを送信する宛先を識別する識別子を表す。リクエストＵＲＩとは、リクエストを適用するリソースを指定する識別子を表す。リクエストボディとは、サーバ３０に対して送信されるデータ（センサデータ）を表す。

次に、解析部２０７は、リクエストメッセージのヘッダ部分にバッファリングオプション情報（以下、単にバッファリングオプションという。）が記述されているか否かを判定する。バッファリングオプション（蓄積情報）とは、リクエストメッセージに格納されているセンサデータをまとめて送信するか否かを表す情報である。
バッファリングオプションが記述されている場合、解析部２０７は取得したセンサデータをデータベース２０９に蓄積する。この際、解析部２０７は、取得したセンサデータに対応するリクエストＵＲＬをインデックスとして、センサデータをデータベース２０９に蓄積する。
一方、バッファリングオプションが記述されていない場合、解析部２０７は取得したセンサデータをサーバ３０に送信するためのリクエストメッセージの生成を生成部２１０に指示する。

また、解析部２０７は、サーバ３０から送信されたレスポンスメッセージを解析する。解析部２０７は、送信されたレスポンスメッセージからステータスコード及びレスポンスボディの各値を取得する。レスポンスボディとは、サーバ３０から送信される応答データを表す。その後、解析部２０７は、生成部２１０にレスポンスメッセージの生成を指示する。

タイマー管理部２０８は、解析部２０７が解析した結果に基づいてタイマーの管理を行う。例えば、タイマー管理部２０８は、解析部２０７によってリクエストメッセージにバッファリングオプションが記述されていると判定された場合に、リクエストメッセージのリクエストＵＲＬ毎に送信間隔算出部２０６から通知された送信間隔のカウントダウンを開始する。

データベース２０９は、磁気ハードディスク装置や半導体記憶装置などの記憶装置を用いて構成される。データベース２０９は、リクエストＵＲＬ毎にセンサデータを記憶している。
生成部２１０は、取得されたリクエストメソッドとリクエストＵＲＩとリクエストボディとを用いて第一のリクエストメッセージを生成する。具体的には、生成部２１０は、ヘッダにリクエストメソッドとリクエストＵＲＩとを格納し、ボディ部分にリクエストボディを格納することによって第一のリクエストメッセージを生成する。第一のリクエストメッセージは、ノード１０から送信された一つのセンサデータが格納されたリクエストメッセージである。

また、生成部２１０は、取得されたステータスコードとレスポンスボディとを用いてレスポンスメッセージを生成する。具体的には、生成部２１０は、ヘッダにステータスコードを格納し、ボディ部分にレスポンスボディを格納することによってレスポンスメッセージを生成する。
また、生成部２１０は、タイマー管理部２０８からタイマーの満了が通知されると、データベース２０９に記録されているセンサデータを用いて第二のリクエストメッセージを生成する。第二のリクエストメッセージは、複数のセンサデータが格納されたリクエストメッセージである。具体的には、まず、生成部２１０は、データベース２０９からタイマー満了が通知されたリクエストＵＲＬに対応するセンサデータを取得する。次に、生成部２１０は、取得したセンサデータを用いてリクエストボディを生成する。その後、生成部２１０は、リクエストメソッドとリクエストＵＲＩと生成されたリクエストボディとを用いて第二のリクエストメッセージを生成する。

図３は、リクエストメッセージを蓄積する方法の具体例を表す図である。図３（Ａ）は、ノード１０から送信されたリクエストメッセージを表す図である。図３（Ａ）の“ａ”は、リクエストラインとメッセージヘッダで構成されるヘッダ部分を表し、図３（Ａ）の“ｂ”は、リクエストメッセージのボディ部分を表す。図３（Ａ）のヘッダ部分“ａ”には、リクエストメソッド、リクエストＵＲＬ、リクエストＵＲＩ、ＨＴＴＰ（Hypertext Transfer Protocol）のバージョン、送信元のアドレス、ボディ部分のサイズ、バッファリングオプション、接続状態などの各情報が記述されている。図３（Ａ）に示す例では、ヘッダ部分“ａ”にバッファリングオプション「Ｂｕｆｆｅｒｉｎｇ：ｏｎ」が記述されている。バッファリングオプションは、ノード１０がセンサデータの蓄積が必要であると判断した場合に付与される。ノード１０は、蓄積が必要であるか否かを判断するためのテーブルを予め記憶しており、センサデータを取得する度にテーブルを確認することによって、リクエストメッセージにバッファリングオプションを記述する必要があるか否かを判断する。例えば、テーブルには、センサデータを蓄積する必要がある送信先やユーザＩＤなどが記憶されている。また、取得したセンサデータが管理プロトコルのようなＰＩＮ（Personal identification number）を送信するのみのデータである場合には、ノード１０は蓄積する必要が無いと判断し、バッファリングオプションを記述しない。解析部２０７は、受信されたリクエストメッセージにバッファリングオプションが記述されている場合には、ヘッダ部分“ａ”に記述されているリクエストＵＲＬをインデックスとしてデータベース２０９にセンサデータを蓄積する。また、図３（Ａ）のボディ部分“ｂ”には、ノード１０によって収集されたセンサデータが記述されている。

図３（Ｂ）は、図３（Ａ）のリクエストメッセージから一定時間（例えば、１０分、１時間など）経過後にノード１０から送信されたリクエストメッセージを表す図である。図３（Ｂ）に示すリクエストメッセージのヘッダ部分にもバッファリングオプション「Ｂｕｆｆｅｒｉｎｇ：ｏｎ」が記述されている。即ち、図３（Ｂ）に示すリクエストメッセージもリクエストＵＲＬをインデックスとしてデータベース２０９にセンサデータが蓄積される。図３（Ｃ）は、図３（Ａ）のリクエストメッセージのセンサデータと図３（Ｂ）のリクエストメッセージのセンサデータとが蓄積された第二のリクエストメッセージを表す図である。

次に、図３を用いてリクエストメッセージのセンサデータを追加する方法について説明する。図３（Ａ）のリクエストメッセージのセンサデータがデータベース２０９に蓄積された後に、図３（Ｂ）のリクエストメッセージが受信されると、解析部２０７はヘッダ部分に記述されているリクエストＵＲＬを取得する。次に、解析部２０７は、取得したリクエストＵＲＬをインデックスとしてデータベース２０９を検索する。解析部２０７は、検索されたリクエストＵＲＬのセンサデータの後に取得したリクエストメッセージのセンサデータを追加する。
以上で、リクエストメッセージのセンサデータを追加する方法についての説明を終了する。

図４は、バッファリングオプションが記述されていないリクエストメッセージの具体例を示す図である。
図４に示すリクエストメッセージでは、リクエストメッセージのヘッダ部分“ｃ”にバッファリングオプション「Ｂｕｆｆｅｒｉｎｇ：ｏｎ」が記述されていない。したがって、図４に示すリクエストメッセージのセンサデータは、データベース２０９に蓄積されない。この場合、図４に示すクエストメッセージは、サーバ３０に送信される。

図５は、本実施形態における送信間隔算出処理の流れの具体例を示すフローチャートである。
まず、ＧＷ機器２０の通信部２０１は、Ｓｙｎパケットをサーバ３０に送信する（ステップＳ１０１）。この際、通信部２０１は、自装置（ＧＷ機器２０）とサーバ３０との通信に使用されるＭＳＳの値をＳｙｎパケットに格納する。次に、通信部２０１は、サーバ３０からＳｙｎ／Ａｃｋパケットを受信する（ステップＳ１０２）。この際、通信部２０１は、受信したＳｙｎ／Ａｃｋパケットに格納されているＭＳＳの値を取得する。そして、通信部２０１は、サーバ３０に対してＡｃｋパケットを送信する（ステップＳ１０３）。ステップＳ１０１〜ステップＳ１０３の処理を行うことによってＧＷ機器２０とサーバ３０との接続が確立される。

その後、通信部２０１は、サーバ３０との通信に使用されるＭＳＳの値を取得する（ステップＳ１０４）。具体的には、通信部２０１は、サーバ３０に送信したＭＳＳの値と受信したＭＳＳの値とを比較して、小さい方のＭＳＳをサーバ３０との通信に使用するＭＳＳの値として取得する。
次に、取得部２０３は、一定期間の間、ノード１０からサーバ３０に対して送信されているセンサデータのパケットを収集する（ステップＳ１０５）。取得部２０３は、収集したパケットからヘッダーサイズ及びボディサイズの各値を取得する（ステップＳ１０６）。具体的には、取得部２０３は、取得したパケットのＨＴＴＰヘッダのサイズとペイロードに格納されているセンサデータのサイズを取得する。

集約数算出部２０４は、ＭＳＳの値とヘッダーサイズ及びボディサイズの各値とを用いてセンサデータの集約可能数を算出する（ステップＳ１０７）。受信間隔算出部２０５は、取得部２０３によって一定期間の間、収集されたパケットの受信時刻の差分に基づいて、センサデータのパケットの受信間隔を算出する（ステップＳ１０８）。その後、送信間隔算出部２０６は、算出された受信間隔の値と集約可能数の値とを用いて送信間隔を算出する（ステップＳ１０９）。例えば、送信間隔算出部２０６は、受信間隔の値と集約可能数の値とを乗算することによって送信間隔を算出する。そして、送信間隔算出部２０６は、算出した送信間隔の値をタイマー管理部２０８に通知する。その後、送信間隔算出処理が終了する。

図６は、本実施形態におけるセンサデータ送信処理の流れの具体例を示すフローチャートである。
ＧＷ機器２０の通信部２０１は、ノード１０から周期的に送信されるリクエストメッセージを受信する（ステップＳ２０１）。解析部２０７は、受信されたリクエストメッセージを解析する（ステップＳ２０２）。具体的には、解析部２０７は、受信されたリクエストメッセージに格納されているリクエストメソッド、リクエストＵＲＬ、リクエストＵＲＩ及びセンサデータの各値を取得する。その後、解析部２０７は、ヘッダ部分にバッファリングオプションが記述されているか否かを判定する（ステップＳ２０３）。バッファリングオプションが記述されている場合（ステップＳ２０３−ＹＥＳ）、解析部２０７は取得したリクエストＵＲＬをインデックスとしてデータベース２０９を検索する。そして、解析部２０７は、検索されたリクエストＵＲＬのセンサデータの後に、ステップＳ２０３の処理で取得したセンサデータをデータベース２０９に蓄積する（ステップＳ２０４）。

一方、バッファリングオプションが記述されていない場合（ステップＳ２０３−ＮＯ）、生成部２１０は受信されたリクエストメッセージに基づいて、サーバ３０に送信する第一のリクエストメッセージを生成する（ステップＳ２０５）。具体的には、生成部２１０は、リクエストメッセージのヘッダ部分にリクエストメソッド及びリクエストメソッドＵＲＩを格納し、ボディ部分にリクエストボディを格納することによって第一のリクエストメッセージを生成する。そして、通信部２０１は、生成された第一のリクエストメッセージをサーバ３０に送信する（ステップＳ２１４）。
また、ステップＳ２０４の処理後に、生成部２１０は、センサデータを蓄積したことを示す情報を含むレスポンスメッセージを生成する（ステップＳ２０６）。通信部２０１は、生成されたレスポンスメッセージをノード１０に送信する（ステップＳ２０７）。

次に、タイマー管理部２０８は、ステップＳ２０１の処理で受信したリクエストメッセージのリクエストＵＲＬに対応するタイマーが起動しているか否かを判定する（ステップＳ２０８）。タイマーが起動している場合（ステップＳ２０８−ＹＥＳ）、タイマー管理部２０８はステップＳ２０１の処理で受信したリクエストメッセージのリクエストＵＲＬに対応するタイマーが満了であるか否かを判定する（ステップＳ２０９）。一方、ステップＳ２０８の処理において、タイマーが起動していない場合（ステップＳ２０８−ＮＯ）、タイマー管理部２０８は送信間隔算出部２０６によって算出された値を自装置に設定し、タイマーを開始する（ステップＳ２１０）。そして、ステップＳ２０１以降の処理が繰り返し実行される。

タイマーが満了である場合（ステップＳ２０９−ＹＥＳ）、タイマー管理部２０８はタイマー満了を生成部２１０に通知する（ステップＳ２１１）。一方、ステップＳ２０９の処理において、タイマーが満了ではない場合（ステップＳ２０９−ＮＯ）、ステップＳ２０１以降の処理が繰り返し実行される。
次に、生成部２１０は、タイマー満了が通知されると、データベース２０９を参照し、ステップＳ２０１の処理で受信したリクエストメッセージのリクエストメソッド、リクエストＵＲＩに対応するセンサデータを用いてリクエストボディを生成する。（ステップＳ２１２）。生成部２１０は、リクエストメソッドとリクエストＵＲＩと生成されたリクエストボディとを用いて第二のリクエストメッセージを生成する（ステップＳ２１３）。具体的には、ヘッダ部分にリクエストメソッド及びリクエストＵＲＩを格納し、ボディ部分にリクエストボディを格納することによって第二のリクエストメッセージを生成する。その後、通信部２０１は、生成された第二のリクエストメッセージをサーバ３０に送信する（ステップＳ２１４）。

図７は、本実施形態におけるセンサデータ送信処理の動作の具体例を示すシーケンス図である。
ノード１０は、センサデータを含むリクエストメッセージをＧＷ機器２０に送信する（ステップＳ３０１）。ＧＷ機器２０の通信部２０１は、ノード１０から送信されたリクエストメッセージを受信する。その後、解析部２０７は、受信されたリクエストメッセージを解析する（ステップＳ３０２）。リクエストメッセージにバッファリングオプションが記述されている場合、解析部２０７はリクエストメッセージに格納されているセンサデータをデータベース２０９に蓄積する（ステップＳ３０３）。一方、リクエストメッセージにバッファリングオプションが記述されていない場合、生成部２１０は受信されたリクエストメッセージに基づいて、第一のリクエストメッセージを生成する。その後、通信部２０１は、生成された第一のリクエストメッセージをサーバ３０に送信する。

また、生成部２１０は、リクエストに対する結果を表すステータスコードとレスポンスボディとを用いてレスポンスメッセージを生成する（ステップＳ３０４）。通信部２０１は、生成されたレスポンスメッセージをノード１０に送信する（ステップＳ３０５）。その後、タイマー管理部２０８は、送信間隔算出部２０６によって算出された送信間隔をタイマーに設定し、タイマーのカウントダウンを開始する（ステップＳ３０６）。
ノード１０は、センサデータを含むリクエストメッセージをＧＷ機器２０に送信する（ステップＳ３０７）。ＧＷ機器２０の通信部２０１は、ノード１０から送信されたリクエストメッセージを受信する。その後、解析部２０７は、受信されたリクエストメッセージを解析する（ステップＳ３０８）。

リクエストメッセージにバッファリングオプションが記述されている場合、解析部２０７はステップＳ３０７の処理で送信されたリクエストメッセージに格納されているセンサデータを、データベース２０９に蓄積する（ステップＳ３０９）。また、生成部２１０は、リクエストに対する結果を表すステータスコードとレスポンスボディとを用いてレスポンスメッセージを生成する（ステップＳ３１０）。通信部２０１は、生成されたレスポンスメッセージをノード１０に送信する（ステップＳ３１１）。

ステップＳ３０７の処理で送信されたリクエストメッセージのリクエストＵＲＬに対応するタイマーが満了すると、タイマー管理部２０８は、タイマー満了を生成部２１０に通知する。生成部２１０は、タイマー管理部２０８からタイマー満了が通知されると、データベース２０９を参照し、ステップＳ３０７の処理で送信されたリクエストメッセージのリクエストＵＲＬに対応するセンサデータを用いてリクエストボディを生成する（ステップＳ３１２）。その後、生成部２１０は、リクエストメソッド、リクエストＵＲＩ及びリクエストボディを用いて第二のリクエストメッセージを生成する（ステップＳ３１３）。具体的には、生成部２１０は、ヘッダ部分にリクエストメソッド及びリクエストＵＲＩを格納し、ボディ部分にリクエストボディを格納することによって第二のリクエストメッセージを生成する。通信部２０１は、生成された第二のリクエストメッセージをサーバ３０に送信する（ステップＳ３１４）。

サーバ３０は、ＧＷ機器２０から送信された第二のリクエストメッセージを受信する。次に、サーバ３０は、受信した第二のリクエストメッセージに格納されているセンサデータをデータベースに記録する。そして、サーバ３０は、レスポンスメッセージを生成する。その後、サーバ３０は、生成したレスポンスメッセージをＧＷ機器２０に送信する（ステップＳ３１５）。
ＧＷ機器２０の通信部２０１は、サーバ３０から送信されたレスポンスメッセージを受信する。解析部２０７は、送信されたレスポンスメッセージを解析する（ステップＳ３１６）。生成部２１０は、レスポンスメッセージを生成する（ステップＳ３１７）。通信部２０１は、生成されたレスポンスメッセージをノード１０に送信する（ステップＳ３１８）。

以上のように構成されたＧＷ機器２０によれば、複数のセンサデータがリクエストメッセージに付与されているリクエストＵＲＬに基づいて蓄積される。したがって、ノード１０からセンサデータが送信される度に、センサデータの送信が行われないため、サーバ３０に対してアクセス数が減少する。また、複数のセンサデータが一つのデータとして送信されるため、通信量も軽減することができ、サーバ３０の処理負荷も軽減することができる。また、ＧＷ機器２０は、フラグメンテーションが生じない最大のサイズで蓄積されたセンサデータをサーバ３０に送信する。そのため、センサネットワークにおけるデータ送信の際に生じる負荷を軽減することが可能となる。

＜変形例＞
本実施例では、中継システムに存在するノード１０の数は、三台であるが、ノード１０の数が四台以上であっても良いし、ノード１０の数が二台以下であっても良い。
また、本実施例では、中継システムに存在するＧＷ機器２０の数は、一台であるが、ＧＷ機器２０の数は複数台で構成されても良い。
また、ＧＷ機器２０がサーバ３０に対して蓄積しているセンサデータを送信するタイミングは、上述のタイミングに限定される必要はない。例えば、ＧＷ機器２０は、データベース２０９に蓄積されているセンサデータの数が、集約可能数を超過した場合にサーバ３０にセンサデータを送信しても良い。また、ユーザによって送信間隔が設定されても良い。
また、本実施例では、センサデータをサーバ３０に送信する中継装置としてＧＷ機器２０が使用されているが、これに限定される必要はなく、プロキシ機能を備えた中継装置であればどのような装置であっても良い。
バッファリングオプションは、リクエストメッセージのボディ部分に記述されても良い。

以上、この発明の実施形態について図面を参照して詳述してきたが、具体的な構成はこの実施形態に限られるものではなく、この発明の要旨を逸脱しない範囲の設計等も含まれる。

１０（１０−１〜１０−３）…ノード， ２０…ＧＷ機器， ３０…サーバ， ４０…センサネットワーク， ５０…ネットワーク， ２０１…通信部， ２０２…制御部， ２０３…取得部， ２０４…集約数算出部， ２０５…受信間隔算出部， ２０６…送信間隔算出部， ２０７…解析部， ２０８…タイマー管理部， ２０９…データベース， ２１０…生成部

Claims (4)

1. ノードから送信されたパケットに対して、蓄積する対象のデータであることを示す蓄積情報が付与されているか否か判定する解析部と、
   前記解析部によって前記蓄積情報が付与されていると判定されたパケットを送信先ごとに蓄積して記憶するデータベースと、
   前記データベースに記憶されている蓄積された前記パケットをサーバに送信する間隔を管理するタイマー管理部と、
   前記解析部によって前記蓄積情報が付与されていないと判定されたパケットをサーバに送信し、前記解析部によって前記蓄積情報が付与されていると判定されたパケットを前記間隔でサーバに送信する通信部と、
   を備える中継装置。
2. 前記パケットのサイズ情報を取得する取得部と、
   自装置と前記サーバとの接続時に取得される前記パケットを送信可能な最大のサイズ情報と、前記パケットのサイズ情報とに基づいて、前記データベースに蓄積される前記パケットの集約可能数を算出する集約数算出部と、
   を更に備え、
   前記通信部は、前記集約可能数に基づいて、蓄積された前記パケットをサーバに送信する請求項１に記載の中継装置。
3. 複数のノードと、前記ノードから送信されるパケットをサーバに中継する中継装置とを備えたシステムであって、
   前記ノードは、
   周囲の空間情報を表すデータを収集するセンサと、
   前記センサによって収集された前記データを含むパケットを前記中継装置に送信する通信部と、
   を備え、
   前記中継装置は、
   前記ノードから送信されたパケットに対して、蓄積する対象のデータであることを示す蓄積情報が付与されているか否か判定する解析部と、
   前記解析部によって前記蓄積情報が付与されていると判定されたパケットを送信先ごとに蓄積して記憶するデータベースと、
   前記データベースに記憶されている蓄積された前記パケットをサーバに送信する間隔を管理するタイマー管理部と、
   前記解析部によって前記蓄積情報が付与されていないと判定されたパケットをサーバに送信し、前記解析部によって前記蓄積情報が付与されていると判定されたパケットを前記間隔でサーバに送信する通信部と、
   を備える中継システム。
4. ノードから送信されたパケットに対して、蓄積する対象のデータであることを示す蓄積情報が付与されているか否か判定する解析ステップと、
   前記解析ステップにおいて前記蓄積情報が付与されていると判定されたパケットを送信先ごとに蓄積してデータベースに記憶する記憶ステップと、
   前記データベースに記憶されている蓄積された前記パケットをサーバに送信する間隔を管理するタイマー管理ステップと、
   前記解析ステップにおいて前記蓄積情報が付与されていないと判定されたパケットをサーバに送信し、前記解析ステップにおいて前記蓄積情報が付与されていると判定されたパケットを前記間隔でサーバに送信する通信ステップと、
   を有する中継方法。

Images