(57)【要約】【課題】  必ずしも端末から基地局への一方向的・一律的な集約だけでなく、広域的ネットワーク内の部分的な集約実行と集約の非実行の区別を実現でき、また、ネットワーク上での集約動作を制御する。【解決手段】  本発明は、複数のメッセージのうち、どのメッセージとどのメッセージを集約して転送または送信できるのかを決定し、決定したメッセージを集約対象メッセージ記憶手段に格納する集約対象特定手段と、集約対象メッセージ記憶手段の複数のメッセージを単一の集約メッセージに集約する集約手段と、当該通信ノードがメッセージを受信する際に、集約メッセージに含まれる個別のメッセージを復元し、復元した個別メッセージを送信先に転送又は送信する復元手段と、を有する。【選択図】  図２
2014150449.tif 000002
【特許請求の範囲】
【請求項１】
多数の通信端末が小さなサイズのデータパケットやデータフレームを大量に送受信するネットワークシステムにおいて、メッセージを送信または転送する通信ノードであって、
メッセージを受信する受信手段と、
複数のメッセージのうち、どのメッセージとどのメッセージを集約して転送または送信できるのかを決定し、決定したメッセージを集約対象メッセージ記憶手段に格納する集約対象特定手段と、
前記集約対象メッセージ記憶手段の複数のメッセージを単一の集約メッセージに集約する集約手段と、
当該通信ノードがメッセージを受信する際に、前記集約メッセージに含まれる個別のメッセージを復元する復元手段と、
前記集約メッセージまたは復元した個別メッセージを、転送または送信する送信手段と、
を有することを特徴とする通信ノード。
【請求項２】
前記集約対象特定手段は、
メッセージ記憶手段からメッセージを読み出して、該メッセージが、転送が必要でかつ、集約可能なメッセージであり、該メッセージの転送先が復元手段を有する場合には、該メッセージを前記集約対象メッセージ記憶手段の転送先の集約対象メッセージ群に格納し、前記集約手段を起動する手段を含む
請求項１記載の通信ノード。
【請求項３】
前記集約対象特定手段は、
メッセージを送信するイベントが発生し、該メッセージが集約可能で、次ホップの送信先が復元機能をサポートする場合に、該メッセージを集約対象メッセージ記憶手段の送信先の集約対象メッセージ群に格納する手段を含む
請求項１記載の通信ノード。
【請求項４】
多数の通信端末が小さなサイズのデータパケットやデータフレームを大量に送受信するネットワークシステムであって、
複数の端末と、
受信したメッセージを転送または送信するノードと、
前記端末、または、前記ノードとの間でメッセージを送受信する終端ノードと、
を有し、
前記ノードは、
メッセージを受信する受信手段と、
複数のメッセージのうち、どのメッセージとどのメッセージを集約して転送または送信できるのかを決定し、決定したメッセージを集約対象メッセージ記憶手段に格納する集約対象特定手段と、
前記集約対象メッセージ記憶手段の複数のメッセージを単一の集約メッセージに集約する集約手段と、
当該通信ノードがメッセージを受信する際に、前記集約メッセージに含まれる個別のメッセージを復元する復元手段と、
前記集約メッセージまたは前記復元した個別メッセージを転送または送信する送信手段と、
を有することを特徴とするネットワークシステム。
【請求項５】
前記集約対象特定手段は、
メッセージ記憶手段からメッセージを読み出して、該メッセージが、転送が必要でかつ、集約可能なメッセージであり、該メッセージの転送先が復元手段を有する場合には、該メッセージを前記集約対象メッセージ記憶手段の転送先の集約対象メッセージ群に格納し、前記集約手段を起動する手段を含む
請求項４記載のネットワークシステム。
【請求項６】
前記集約対象特定手段は、
メッセージを送信するイベントが発生し、該メッセージが集約可能で、次ホップの送信先が復元機能をサポートする場合に、該メッセージを集約対象メッセージ記憶手段の送信先の集約対象メッセージ群に格納する手段を含む
請求項４記載のネットワークシステム。
【請求項７】
前記送信手段は、
複数の集約メッセージを１つの集約メッセージに集約して、転送または送信する多段集約手段を含む
請求項４記載のネットワークシステム。
【請求項８】
多数の通信端末が小さなサイズのデータパケットやデータフレームを大量に送受信するネットワークシステムにおいて、メッセージを送信または転送する通信方法であって、
前記通信ノードは、受信手段、集約特定手段、集約手段、復元手段、集約対象メッセージ記憶手段、送信手段を有する通信ノードにおいて、
前記受信手段が、メッセージを受信する受信ステップと、
前記集約対象特定手段が、複数のメッセージのうち、どのメッセージとどのメッセージを集約して転送または送信できるのかを決定し、決定したメッセージを集約対象メッセージ記憶手段に格納する集約対象特定ステップと、
前記集約手段が、前記集約対象メッセージ記憶手段の複数のメッセージを単一の集約メッセージに集約する集約ステップと、
前記復元手段が、当該通信ノードがメッセージを受信する際に、前記集約メッセージに含まれる個別のメッセージを復元する復元ステップと、
前記送信手段が、前記集約メッセージまたは復元した個別メッセージを、転送または送信する送信ステップと、
を行うことを特徴とする通信方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信ノード及びネットワークシステム及び通信方法に係り、特に、多数の通信端末が小さなサイズのデータパケット、データフレームを大量に送受するネットワークシステムにおいて、ネットワーク機器の処理負荷上昇、消費電力増大、ネットワーク帯域利用の非効率化を防止するための通信ノード及びネットワークシステム及び通信方法に関する。
【背景技術】
【０００２】
パーソナルコンピュータや携帯電話など、人間が操作することを前提とした通信端末だけではなく、温度や放射線などの環境情報を収集するセンサ、電力などのモニタリングに用いられるメータ、機器の各部位の作動制御に用いられるアクチュエータなどの機器をも通信ネットワークに接続させて、必ずしも人間の介在を必要としない通信を行うことで、より多様かつ高度な通信サービスを実現することができるようになると期待される。
【０００３】
これらのセンサ、アクチュエータといった機器は、多くの制約条件を有する。例えば、バッテリ駆動で動作するものが多いため、通信にあたっては高い省電力性が求められる。また、搭載可能なメモリ量が限られるため、通信処理には高い軽量性が求められる。例えば、パーソナルコンピュータや携帯電話等の従来の通信機器を使用した通信サービスを実現する技術として広く普及しているHTTP(Hypertext Transfer Protocol)（例えば、非特許文献１）は、そのまま用いると送受信されるメッセージサイズが大きくなり、通信時に大きな電力を消費するなどの問題がある。
【０００４】
このような制約条件の厳しい機器を用いたデータ通信を可能とするための技術として、例えばCoAP(Constrained Application Protocol)のような軽量な通信プロトコル技術がある（例えば、非特許文献２参照）。CoAPは、データの取得、更新、削除などを要求するリクエストを送信するクライアント、クライアントからの要求に応答するサーバ、及びCoAPメッセージの中継を行うプロキシサーバを利用して、データの送受信、機器の制御などを行う。
【０００５】
CoAPのようなプロトコル技術の改良点の一つとして、通信時の消費電力を削減するために、通信時に送受信されるメッセージサイズが可能な限り小さくなるように設計されている点がある。これにより、センサ、メータ、アクチュエータといった制約条件の厳しい機器は、通信にかかる処理を短縮することができ、電力消費を抑えることができる。
【０００６】
しかしながら、このような機器が極めて大量に存在し、ネットワークを介して互いに接続する場合、ネットワーク上にはこのような小さなサイズのパケット／フレームが極めて大量に流通することとなる。一般的に、通信ネットワークを構成するノードにおける転送処理は、小さなサイズのパケット／フレームの転送が多くなるほど機器の付加が増大するため、消費電力が増大したりパケットロスが増加するなどの問題が発生しやすくなる。また、実際に伝達したいデータそのものに比べて、ネットワーク処理にしか用いられないヘッダ情報等のオーバヘッドが大きくなり、ネットワーク帯域の利用が非効率化する。
【０００７】
この問題に対する技術として、センサネットワークにおけるデータ集約技術がある（非特許文献３）。このデータ集約技術においては、複数のセンサ端末が、単一の終端基地局に向かってマルチホップのツリーネットワークを構成する。複数のセンサから複数のセンシングデータを受信した中間センサが、それらを次ホップのセンサに転送する際に、単にそれらを個別に転送するのではなく、それらの複数データの和や平均等の演算処理を行った上で、その結果を新たな一つのデータとして次ホップに転送する。これをツリーネットワークの端点から終端基地局まで同様に実施することで、全てのセンサ端末からのセンシングデータを個別に転送する場合に比べ、転送するデータ量を削減し、ネットワーク帯域、センサ端末における転送処理に要する電力消費を削減することができる。
【先行技術文献】
【非特許文献】
【０００８】
【非特許文献１】Hypertext Transfer Protocol - HTTP/1.1, IETF RFC 2616.
【非特許文献２】Constrained Application Protocol(CoAP). IETF  http://www.ietf.org/id/draft-ietf-core-coap-13.txt
【非特許文献３】Secure Hop-by-Hop Aggregation of End-to-End concealed Data in Wireless Sensor Network, Esam Mlaih, et al., 2008.
【発明の概要】
【発明が解決しようとする課題】
【０００９】
しかしながら、上記従来技術のようなセンサネットワーク上でのデータ集約技術は、温度データ、電力データなどの決まった種類のセンシングデータを一元的に集約するという、用途が限定された局所的なネットワーク上に適用することを前提としている。そのため、多種多様なセンサ類、メータ類を大量に収容し、多様な通信パターン経路による多様なデータの送受信を実現する広域的なネットワーク上には適用しづらいという課題がある。
【００１０】
具体的には、端点のセンサ端末から終端基地局まで一方向的に一律的に集約が行われるため、広域ネットワークある部分において集約を行いたいが、ある部分においては集約を行わない、という区別ができない。
【００１１】
また、センサネットワーク等の局所的ネットワークでは、センサ類がセンシングしたデータを送信する送信先は、常に同じ終端基地局であることが専らである。従って、そのネットワークを構成するセンサ類等のノードは、最終的に集約したデータを受信する基地局がそれを正しく処理できると分かっているため、常に複数のデータを集約して送信する単純な処理を行えばよい。ところが、より広域的なネットワークでは、あるセンサ端末が送信するデータが最終的に到達するノードないしは、その経路上にあるノード、またそれらのノードの能力は、常に一定、一つとは限らない。そのため、単純に一律にデータの集約を行うと、最終的な到達点、あるいはその経路上のどこかで、その集約されたデータを正しく処理できなかったり、そもそもデータが正しく届けられなかったりすることがあり、意図した通信が達成できなくなる可能性がある。
【００１２】
本発明は、上記の点に鑑みなされたもので、必ずしも端末から基地局への一方向的・一律的な集約だけでなく、広域的ネットワーク内の部分的な集約実行と集約の非実行の区別を実現できる通信ノード及びネットワークシステム及び通信方法を提供することを目的とする。
【００１３】
また、メッセージの特性、そのメッセージに含まれるデータを利用するアプリケーションの要求条件などに応じて、ネットワーク上での集約動作を制御することが可能な通信ノード及びネットワークシステム及び通信方法を提供することを目的とする。
【課題を解決するための手段】
【００１４】
上記の課題を解決するため、本発明（請求項１）は、多数の通信端末が小さなサイズのデータパケットやデータフレームを大量に送受信するネットワークシステムにおいて、メッセージを送信または転送する通信ノードであって、
メッセージを受信する受信手段と、
複数のメッセージのうち、どのメッセージとどのメッセージを集約して転送または送信できるのかを決定し、決定したメッセージを集約対象メッセージ記憶手段に格納する集約対象特定手段と、
前記集約対象メッセージ記憶手段の複数のメッセージを単一の集約メッセージに集約する集約手段と、
当該通信ノードがメッセージを受信する際に、前記集約メッセージに含まれる個別のメッセージを復元する復元手段と、
前記集約メッセージまたは復元した個別メッセージを、転送または送信する送信手段と、
を有する。
【００１５】
また、本発明（請求項２）は、前記集約対象特定手段において、
メッセージ記憶手段からメッセージを読み出して、該メッセージが、転送が必要でかつ、集約可能なメッセージであり、該メッセージの転送先が復元手段を有する場合には、該メッセージを前記集約対象メッセージ記憶手段の転送先の集約対象メッセージ群に格納し、前記集約手段を起動する手段を含む。
【００１６】
また、本発明（請求項３）は、前記集約対象特定手段において、
メッセージを送信するイベントが発生し、該メッセージが集約可能で、次ホップの送信先が復元機能をサポートする場合に、該メッセージを集約対象メッセージ記憶手段の送信先の集約対象メッセージ群に格納する手段を含む。
【発明の効果】
【００１７】
上述のように本発明によれば、限られた種類・数の端末と基地局が接続して限られた用途の通信を行う局所的なセンサネットワーク等の内部だけでなく、多種多様な端末、終端ノードを直接ないしは間接的に大量に接続した広域ネットワークにおいても、小さなパケット／フレームの大量の送受信によるネットワーク機器のパケット転送処理負荷軽減、ネットワーク帯域利用非効率化の防止、ネットワーク機器の消費電力の削減が可能になる。
【図面の簡単な説明】
【００１８】
【図１】本発明の一実施の形態におけるシステム構成例である。
【図２】本発明の一実施の形態における通信ルータの構成例である。
【図３】本発明の一実施の形態におけるメッセージ集約の概要動作のフローチャートである。
【図４】本発明の一実施の形態における受信メッセージのメッセージ記憶部への格納処理のフローチャートである。
【図５】本発明の一実施の形態における集約対象メッセージ群の特定処理のフローチャートである。
【図６】本発明の一実施の形態における受信時の集約候補メッセージ群決定シーケンス例である。
【図７】本発明の一実施の形態における送信時の集約対象メッセージ群の特定処理のフローチャートである。
【図８】本発明の一実施の形態におけるメッセージ集約処理のフローチャートである。
【図９】本発明の一実施の形態における集約メッセージのパケットフォーマット例である。
【図１０】本発明の一実施の形態における復元機能サポート可否の確認のシーケンス例である。
【図１１】本発明の一実施の形態における復元機能サポート可否の確認（メッセージ例）である。
【図１２】本発明の一実施の形態におけるメッセージ集約、復元機能、集約禁止を表現する情報の記述例（CoAP Aggregateオプション例）である。
【図１３】本発明の一実施の形態におけるメッセージ復元処理のフローチャートである。
【図１４】本発明の一実施の形態におけるメッセージ集約・復元シーケンス例（その１）である。
【図１５】本発明の一実施の形態におけるメッセージ集約・復元シーケンス例（その２）である。
【図１６】本発明の一実施の形態におけるメッセージ集約・復元シーケンス例（その３）である。
【図１７】本発明の一実施の形態におけるメッセージ集約・復元シーケンス例（その４）である。
【図１８】本発明の一実施の形態における集約タイマの制御のシーケンスチャートである。
【図１９】本発明の一実施の形態におけるメッセージ復元処理後の転送処理のシーケンスチャートである。
【発明を実施するための形態】
【００１９】
以下、図面と共に本発明の実施の形態を説明する。
【００２０】
図１は、本発明の一実施の形態におけるシステム構成を示す。
【００２１】
同図に示すシステムは、端末１０と終端ノード２０が、中間ノード１００を介してメッセージを送受信し、データの授受や制御を行う。端末１０と終端ノード２０の間に介在する中間ノード１００の数は任意である。また、中間ノードがなく端末１０と終端ノード２０が直接メッセージの送受信を行う場合もある。ある中間ノード１００に接続する端末１０、終端ノード２０の数はそれぞれ任意とする。また、ある端末１０、終端ノード２０、中間ノード１００が複数の中間ノード１００に接続していてもよい。ここでいう「接続」とは、各ノードを具備する機器を物理的に直接接続する場合だけでなく、ネットワークを介して間接的に接続する場合も含む。
【００２２】
本発明の端末１０、中間ノード１００、終端ノード２０は、以降で述べるメッセージの集約及び復元を行うことが可能である。
【００２３】
図２は、本発明の一実施の形態における通信ノードの構成例を示す。
【００２４】
同図に示すノード１００は、受信部１１０、集約対象特定部１２０、復元部１３０、集約処理部１４０、集約タイマ１５０、送信部１６０、メッセージ記憶部１０１、集約対象メッセージ記憶部１０２を有する。この他に図示しないが、途中の計算結果等を一時的に格納するメモリを備えていてもよい。
【００２５】
図３は、本発明の一実施の形態におけるメッセージ集約の全体的な処理のフローチャートである。
【００２６】
メッセージの集約は、大きく以下の流れで処理される。
【００２７】
ステップ１）  ノード１００の受信部１１０において、端末１０からメッセージを受信し、メッセージ記憶部１０１に格納すると、初めに、集約対象特定部１２０は、集約対象メッセージ群を決定し、集約対象メッセージ記憶部１０２に格納する。具体的には、集約対象特定部１２０は、受信した複数のメッセージのうち、どのメッセージとどのメッセージを集約して転送することができるのか、あるいは、送信しようとしている複数のメッセージのうち、どのメッセージとどのメッセージを集約して送信できるのか、を決定する。
【００２８】
ステップ２）  次に、集約処理部１４０において、集約対象特定部１２０で決定し、集約対象メッセージ記憶部１０２に格納された集約対象メッセージ群に対して集約処理を実行する。具体的には、集約処理部１４０において、複数のメッセージを連結し、一つのパケット／フレームにする。
【００２９】
ステップ３）  最後に、送信部１６０を介して複数のメッセージが集約されたパケット／フレームを送信または転送する。
【００３０】
次に、ノードにおいて、メッセージを受信した際にメッセージをメッセージ記憶部１０１に格納する手順について説明する。
【００３１】
図４は、本発明の一実施の形態における受信メッセージのメッセージ記憶部への格納処理のフローチャートである。
【００３２】
ノード１００は、動作を開始すると、集約タイマ１５０を起動する(ステップ１０１)。受信部１１０は、タイマ起動中にメッセージを受信し（ステップ１０２）、受信したメッセージに対して、自信が集約メッセージの復元機能をサポートしている場合は、復元部１３０においてメッセージの復元処理を行う（ステップ１０３）。なお、メッセージの復元処理については後述する。
【００３３】
復元部１３０は、復元されたメッセージ群を、メッセージ記憶部１０１に格納する（ステップ１０４）。一度復元したメッセージを再び後の集約処理のためのメッセージ記憶部１０１に格納する理由は、集約されたメッセージを受信したノードが、更にそれを、別のメッセージと集約する多段集約を可能にするためである。集約タイマ１５０が完了するまでの間にメッセージの受信（ステップ１０２）、復元（ステップ１０３）、メッセージ記憶部１０１への格納（ステップ１０４）の手順を繰り返し（ステップ１０５、No）、集約タイマ１５０が完了したら（ステップ１０５、Yes）、集約タイマ１５０をリセットし（ステップ１０６）、メッセージ記憶部１０１に格納されたメッセージ群に対して、集約対象メッセージを特定する処理（図５）を行う集約対象特定部１２０を起動し、集約タイマ１５０を再起動して（ステップ１０１）、再び次のメッセージ受信を待機する（ステップ１０２）。
【００３４】
次に、ノード１００における図３のステップ１の集約対象メッセージの特定処理について説明する。
【００３５】
図５は、本発明の一実施の形態における集約対象メッセージ群の特定処理のフローチャートである。
【００３６】
処理が開始されると、集約対象特定部１２０は、メッセージ記憶部１０１からメッセージを一つ取り出す（ステップ２０１）。当該メッセージの最終宛先が自分自身ではなく転送が必要なものかどうかの判定を行う（ステップ２０２）。転送が必要なく自分自身が最終宛先であるメッセージは（ステップ２０２、No）、通常の受信処理を起動する（ステップ２０７）。転送が必要な場合は（ステップ２０２、Yes）、そのメッセージが集約禁止かどうかの確認を行う（ステップ２０３）。具体的には、メッセージ中に禁止フラグ（禁止の場合１、禁止でない場合０）を参照する。集約禁止の場合（ステップ２０３、No）、送信部１６０における通常の転送処理を起動する（ステップ２０４）。集約禁止でない場合（ステップ２０３、Yes）、転送先ノードが集約メッセージの復元機能をサポートするかどうかの確認を行う（復元機能の確認方法については後述する）（ステップ２０５）。サポートしない場合は（ステップ２０５,No）、そのメッセージに対して通常の転送処理を起動する（ステップ２０４）。サポートする場合は（ステップ２０５、Yes）、そのメッセージを、集約対象メッセージ記憶部１０２のそのメッセージの転送先毎の集約対象メッセージ群に追加する（ステップ２０６）。その転送先の集約対象メッセージ群が集約対象メッセージ記憶部１０２に存在しない場合は、その転送先の集約対象メッセージ群を構成する最初のメッセージとなる。
【００３７】
その後、メッセージ記憶部１０１が空になっているかどうかを確認する（ステップ２０８）。空になっている場合は（ステップ２０８,Yes）、集約対象メッセージ記憶部１０２の転送先毎にリストアップされた１つ以上の集約対象メッセージ群に対して、それぞれ集約処理部１４０を起動（集約処理については後述する）して終了する（ステップ２０９）。メッセージ記憶部１０１が空でない場合は（ステップ２０８、No）、次のメッセージを一つ取り出してステップ２０２以降の処理を行う。
【００３８】
次に、図５に示したメッセージ受信時の集約対象特定部１２０における集約候補メッセージ群決定処理について説明する。
【００３９】
図６は、本発明の一実施の形態における受信時の集約候補メッセージ群決定シーケンス例である。
【００４０】
端末Ａ，Ｂ，Ｃ，Ｄと中間ノードからなるシステムにおいて、図６では、メッセージＡ〜Ｃが同一集約タイマ起動中に受信され、かつ転送先が同一であるため、同一転送タイミングでの集約の候補となる。なお、転送先による復元処理機能のサポート可否の確認手順等は省略している。メッセージＤは転送先がメッセージＡ〜Ｃと同じであるか否かによらず、受信時の集約タイマが異なるため、メッセージＡ〜Ｃと同じタイミングでの集約候補とはならない。
【００４１】
次に、メッセージ送信時の集約対象メッセージ群の特定処理について説明する。
【００４２】
メッセージの送信時とは、受信したメッセージの転送ではなく、当該ノードからのメッセージの自発的な送信、ないしは、受信したメッセージに対する応答メッセージの送信を指す。以下にその手順を示す。
【００４３】
図７は、本発明の一実施の形態における送信時の集約対象メッセージ群の特定処理のフローチャートである。
【００４４】
動作を開始したノードにおいて、集約対象特定部１２０は、集約タイマ１５０を起動する（ステップ３０１）。メッセージの送信イベントが発生すると（ステップ３０２）、そのメッセージが集約禁止かどうかの確認を行う（ステップ３０３）。集約禁止の場合（ステップ３０３、No）、通常の送信処理を行う（ステップ３０５）。集約禁止でない場合（ステップ３０３、Yes）、そのメッセージの送信先（メッセージの最終宛先と次ホップの送信先が異なる場合は、次ホップの送信先）が、集約メッセージの復元機能をサポートするかどうかの確認を行う（復元機能については後述する）（ステップ３０４）。サポートする場合は（ステップ３０４、Yes）、集約対象メッセージ記憶部１０２のそのメッセージの送信先毎の集約対象メッセージ群に追加する（ステップ３０６）。集約対象メッセージ記憶部１０２にその送信先の集約対象メッセージ群が存在しない場合は、その送信先の集約対象メッセージ群を構成する最初のメッセージとなる。サポートしない場合は（ステップ３０４、No）、そのメッセージに対して、送信部１６０の通常の送信処理を起動する（ステップ３０５）。
【００４５】
集約タイマ１５０が完了するまで上記の手順を繰り返す（ステップ３０７）。集約タイマ１５０が完了すると（ステップ３０７,Yes）、集約対象メッセージ記憶部１０２の送信先毎の集約対象メッセージ群に対して、それぞれ集約処理部１４０を起動する（ステップ３０８）。集約処理については後述する。集約処理部１４０を起動した後、集約対象メッセージ記憶部１０２の集約候補メッセージ群の一覧を全てクリアし（ステップ３０９）、集約タイマ１５０をリセットし（ステップ３１０）、集約タイマ１５０を再起動してステップ３０１に戻る。
【００４６】
図３のステップ２の集約処理部１４０における集約処理について詳細に説明する。
【００４７】
ステップ１で決定された転送先または送信先毎の集約対象メッセージ群に対する集約処理は以下の通りである。
【００４８】
図８は、本発明の一実施の形態におけるメッセージ集約処理のフローチャートである。
【００４９】
まず、集約処理部１４０は、メッセージの集約順序を決定する（ステップ４０１）。例えば、集約対象メッセージの受信順を転送時の集約順序とする。なお、本発明では、その他の順序決定ロジックを排除するものではない。
【００５０】
次に、集約対象メッセージの個数をnとした場合に、各メッセージに対して集約順序１〜nを順に割り当て、ｋ＝１として以下の処理を行う（ステップ４０２）。
【００５１】
集約対象メッセージ記憶部１０２からメッセージkとメッセージｋ＋１の２つのメッセージを読み出し（ステップ４０３）、両者の集約メッセージのパケットサイズＳを求める。具体的には、メッセージkの直後にメッセージk+1が連結されていることを示す情報をメッセージｋに付加し、さらにその直後にメッセージk+1を読み出し（ステップ４０４）、当該メッセージk+1を単純に連結した集約メッセージMをデータに持つパケットまたはフレームのサイズをＳとする（ステップ４０５）。このサイズが、転送先または送信先までのパケットまたはフレーム転送経路上の最大サイズ（Path MTU）、あるいは、予め設定される転送時または送信時の最大サイズを越えるかどうか判定する（ステップ４０６）。越えない場合は（ステップ４０６、No）、ｋがｎ−１に等しいかどうかを確認する（ステップ４０７）。等しい場合（ステップ４０７、Yes）、集約メッセージMを単一のパケットまたはフレームとして送信する送信部１６０の送信処理を起動して（ステップ４０８）、終了する。等しくない場合（ステップ４０７、No）、ｋを１増加させ（ステップ４０９）、集約メッセージMでメッセージkを上書きして（ステップ４１０）、ステップ４０４に移行する。
【００５２】
サイズＳが最大サイズを越える場合は（ステップ４０６、Yes）、メッセージk(次にメッセージk+1が連結されていることを示す情報を含まない)をメッセージk+1と集約することを中止し、メッセージkの通常の送信処理を行う送信部１６０を起動する（ステップ４１１）。次に、メッセージkがｎ−１に等しいかどうかを確認する（ステップ４１２）。等しい場合（ステップ４１２、Yes）、メッセージk+1についても同様に通常の送信処理を行う送信部１６０を起動して（ステップ４１３）、終了する。等しくない場合（ステップ４１２、No）、kを1増加させ（ステップ４１４）、ステップ４０４に移行する。
【００５３】
上記のメッセージ集約処理で集約される集約メッセージのパケットフォーマットの例を図９に示す。
【００５４】
同図に示すフォーマットは、ネットワークプロトコルにIP(Internet Protocol)、トランスポートプロトコルにUDP(User Datagram Protocol)を用い、メッセージ集約処理をCoAPレイヤにおいて実施する場合のパケットフォーマットの例である。同図のCoAPメッセージ１には、CoAPヘッダ１、CoAPペイロード１が含まれ、CoAPヘッダ１中に、次のCoAPメッセージが直後に連結されていることを示すヘッダとヘッダ値を設定する。具体的な例は図１２で後述する。CoAPヘッダ２も同様である。CoAPメッセージnのCoAPヘッダnには、当該CoAPメッセージnが集約及び連結された最後のCoAPメッセージであるので、連結を示すヘッダを設定しないか、連結された最後のメッセージであることを示すヘッダ値を設定する。具体的な例は図１２で後述する。
【００５５】
なお、本発明は、IP、UDP、CoAP以外の通信プロトコル技術を用いる例も排除しない。また、IP、CoAP、UDPを用いる場合における具体的なメッセージフォーマットを図９の例に限定するものではない。
【００５６】
次に、図５のステップ２０５の復元機能サポート可否の確認を行う動作について説明する。
【００５７】
図１０は、本発明の一実施の形態における復元機能サポート可否の確認のシーケンス例である。本発明におけるノード（端末、中間ノード、終端ノードのいずれか）は、メッセージの転送先または送信先に対して集約メッセージを転送または送信してよいかどうかを判断するために、転送先ノードまたは送信先ノードが集約メッセージから個々のメッセージを復元して処理を継続する（復元機能）ことができるかどうかを確認する。この確認は、同図（A）に示すように、集約メッセージを転送、または、送信しようとするノードが、転送先ノードまたは送信先ノードに問い合わせのメッセージを送信して、そのメッセージに対する応答によって復元機能をサポートするかどうかを識別することによって実現できる。
【００５８】
また、同図（B）のように、集約メッセージを転送または送信しようとするノードが、特に、復元機能の問い合わせや確認を行わずに、転送先ノードまたは送信先ノードからの復元機能のサポート可否の通知を受け、その結果を元に識別することによっても実現できる。
【００５９】
さらに、このサポート可否の確認は、集約メッセージを転送または送信しようとする都度実行することも可能であるし、過去に確認した結果、あるいは通知を受けた結果に有効期間を定め、有効期間内の情報を記憶している場合には確認を省略することも可能である。また、確認にノード間の通信を利用せず、ノード内の記憶領域あるいはノードからアクセス可能なデータベースに予め格納されるノード毎の復元機能サポート可否情報を読み出すことによってもよい。
【００６０】
上記の図１０の復元機能サポート可否の確認について、図１１を用いて具体的に説明する。この復元機能サポート可否の確認のための問い合わせ及び通知は、本発明において集約及び復元の対象となるメッセージと同じ通信プロトコルで実現されてもよいし、別の通信プロトコルによって実現されてもよい。
【００６１】
例えば、CoAPメッセージの集約・復元を実施する場合に、復元機能サポート可否の確認を行う際の問い合わせ・応答メッセージの例を図１１（A）に、通知メッセージの例を図１１（B）に示す。なお、CoAP以外の通信プロトコル技術を用いる、または、CoAPを用いる場合における具体的なメッセージフォーマットを図１０の例に限定するものではない。
【００６２】
図１１（A）において、ノードAからノードBへの問い合わせメッセージ（GET/.well-known/core/cap/aggregate）は、相手の復元機能サポート可否問い合わせに用いるアドレスへのGETリクエストである。これに対して、ノードBは、サポートする場合には、2.06応答にペイロードtrueを含めて返信する。サポートしない場合は、4.04応答でエラーを返却する。
【００６３】
図１１（B）において、ノードBからノードAへは、何らかのメッセージ（通知のためだけでなく、他の目的のメッセージでもよい）にAggregateプションを設定し、オプション値を"３"に設定して分割機能をサポートすることを表示する。これに対し、ノードAは応答メッセージを返す。
【００６４】
なお、図１１の例では、テキスト形式で表現しているが、実際にはCoAPを用いる場合はバイナリフォーマットとなる。
【００６５】
図１１（B）のCoAP Aggregateオプションの例を図１２に示す。図１２においては、メッセージの集約、復元機能、集約禁止を表現する情報は、全ての独立の設定情報として実現可能である。図１２（A）は、Aggregateオプションの例であり、そのフォーマットは、オプション名、オプション番号、フォーマット、長さ（バイト）、デフォルト値を含む。同図（B）は、Aggregateオプション値の例を示す。
【００６６】
本発明においては、メッセージが集約されており、あるメッセージの直後に次のメッセージが連結されていること、あるいは、そのメッセージが最後のメッセージであり、直後に連結されているメッセージが存在しないことを示す情報をメッセージ内に含める（図１２(B)のオプション値"０"）。また、集約されたメッセージを個々のメッセージに復元して処理することができる復元機能をサポートするかどうかを、メッセージ内にオプションとして設定して通知することもできる（図１２（B）のオプション値"３"）。
【００６７】
さらに、あるメッセージの送信時または転送時に、そのメッセージを受信した他のノードに対して、そのメッセージを他のメッセージと集約することを禁止するための情報を設定することができる（図１２（B）のオプション値"２）"。
【００６８】
上記の例は本発明の例の一つであり、CoAP以外の通信プロトコル技術を用いる例も排除するものではない。また、CoAPを用いる場合における具体的なメッセージフォーマットを図１２の例に限定するものではない。
【００６９】
次に、図４のステップ１０３のメッセージ復元処理について説明する。
【００７０】
図１３は、本発明の一実施の形態におけるメッセージ復元処理のフローチャートである。
【００７１】
本発明において、メッセージを受信したノードが復元部１３０においてメッセージ内に集約されている各個別メッセージを復元し、処理を継続する手順は以下の通りである。
【００７２】
メッセージカウントk=1とする（ステップ５０１）。
【００７３】
受信したメッセージMに含まれる結合されたメッセージ群のうち、最初のメッセージkに示されているメッセージkの長さを読み取り（ステップ５０２）、その長さをもとにメッセージM全体からメッセージkを読み取り（ステップ５０３）、メモリに格納する（ステップ５０４）。メッセージkの中に、次に結合されたメッセージk+1が続いていることを示す情報が含まれていれば（ステップ５０５、Yes）、ｋに１を加え（ステップ５０６）、ステップ５０１に戻る。含まれていなければ処理を終了する。
【００７４】
以下に、メッセージ集約及びメッセージ復元のシーケンスを示す。
【００７５】
図１４は、本発明の一実施の形態におけるメッセージ集約・復元シーケンス例（その１）である。同図に示すシーケンスは、二つの端末A,端末BからそれぞれメッセージA、メッセージBが送信されると、中間ノードは、二つのメッセージの集約処理を行い、メッセージαを生成し、終端ノードに送信する。終端ノードは、受信したメッセージα（メッセージA+B）の復元処理を行い、応答メッセージα'(メッセージA'+B')を中間ノードに送信する。中間ノードでは、応答メッセージα'の復元処理を行い、応答メッセージA'、B'をそれぞれ端末A、Bに返却する。
【００７６】
図１５は、本発明の一実施の形態におけるメッセージ集約・復元シーケンス例（その２）である。同図では、メッセージ集約・復元のシーケンスの例であり、部分集約及び禁止フラグがある場合の例を示す。中間ノードでは、端末A,B,C,Dから受信した４つのメッセージを近接して受信するが、メッセージCには集約禁止フラグがあるため集約できず、メッセージDは転送先がメッセージA,Bと異なるため、集約できない。
【００７７】
図１６は、本発明の一実施の形態におけるメッセージ集約・復元シーケンス例（その３）である。同図では、多段集約の例を示す。中間ノード１が、集約して転送した集約メッセージαを、中間ノード２が別に受信したメッセージC、メッセージDと再度集約して、集約メッセージβを生成する。
【００７８】
図１７は、本発明の一実施の形態におけるメッセージ集約・復元シーケンス例（その４）である。同図では、複数回に分割された集約を示している。中間ノード１と中間ノード２の間の伝送可能最大IPデータサイズが小さいため、中間ノード１は４つのメッセージの集約を２回に分けて、集約メッセージα（メッセージA+B）と集約メッセージβ（メッセージC+D）を中間ノード２に転送する。中間ノード２は、集約メッセージを多段集約したメッセージγ（メッセージA+B+C+D）を終端ノードAに転送する。
【００７９】
次に、集約タイマ１５０の制御について説明する。
【００８０】
本発明において、通信ノードが集約体操となり得るメッセージ群の特定に利用する集約タイマの値は、ノードに静的に設定される固定値であってもよく、また、ネットワークトポロジ、自ノードまたは他ノードの状態、ネットワーク上のトラフィック、バッテリ残量等のパラメータに応じて、動的に決定されてもよい。それらのパラメータは、各ノードが自立的に交換し合う方法によってもよく、それらのパラメータの収集及び管理を行い、各ノードのタイマ制御を集中的に行う管理ノードを用いる方法によってもよい。図１８では、管理ノードによる集中制御のシーケンス例を示している。ノードA,B,Cからパラメータの通知があると、管理ノードは、各ノードの最適タイマの値を計算し、それぞれのノードにタイマ値を通知する。これにより、各ノードでは、タイマ値の変更を行うことができる。
【００８１】
次に、メッセージ復元処理後の転送処理について説明する。
【００８２】
図１９は、本発明の一実施の形態におけるメッセージ復元処理後の転送処理のシーケンスチャートである。
【００８３】
本発明において、あるノードが集約メッセージを受信し、復元処理を実施した後に、他ノードへの転送処理を行う際に、復元が完了した個別のメッセージ毎に単純に転送処理を起動するだけでなく、あるメッセージは直ちに転送処理を起動して転送するが、あるメッセージは、一定時間転送せずに保留する、などの転送タイミングの調整を行うことも可能である。
【００８４】
これは、例えば、あるノードが大量の転送先ノードから一斉に応答メッセージが返送され、処理しきれなくなる状態が発生する恐れがある場合などに、転送のタイミングを調整することによって、応答メッセージの到達間隔を平滑化する、等の目的で行うことができる。図１９では、復元処理後に、転送タイミングを決定し、メッセージA,Bは先に、メッセージC,Dは転送待機後に転送するよう調整している。
【００８５】
なお、上記の図２に示すノードの構成要素の各動作をプログラムとして構築し、通信ノード装置として利用されるコンピュータにインストールして実行させる、または、ネットワークを介して流通させることが可能である。
【００８６】
本発明は、上記の実施の形態に限定されることなく、特許請求の範囲内において、種々変更・応用が可能である。
【符号の説明】
【００８７】
１０  端末
２０  終端ノード
１００  中間ノード
１０１  メッセージ記憶部
１０２  集約対象メッセージ記憶部
１１０  受信部
１２０  集約対象特定部
１３０  復元部
１４０  集約処理部
１５０  集約タイマ
１６０  送信部
【図１】
2014150449.tif 000003
【図２】
2014150449.tif 000004
【図３】
2014150449.tif 000005
【図４】
2014150449.tif 000006
【図５】
2014150449.tif 000007
【図６】
2014150449.tif 000008
【図７】
2014150449.tif 000009
【図８】
2014150449.tif 000010
【図９】
2014150449.tif 000011
【図１０】
2014150449.tif 000012
【図１１】
2014150449.tif 000013
【図１２】
2014150449.tif 000014
【図１３】
2014150449.tif 000015
【図１４】
2014150449.tif 000016
【図１５】
2014150449.tif 000017
【図１６】
2014150449.tif 000018
【図１７】
2014150449.tif 000019
【図１８】
2014150449.tif 000020
【図１９】
2014150449.tif 000021