JP5072536B2 - 移動アドホックネットワークシステム - Google Patents

Description

この発明は、移動アドホックネットワークによって通信を行うシステムに関するものであり、特にトラフィックの優先度に応じたルーティング制御を行うシステムに関する。

近年、移動ノードの小型化・高機能化により、固定インフラを介さずに移動ノード同士が無線により直接通信を行う移動アドホックネットワーク（ＭＡＮＥＴ：Ｍｏｂｉｌｅ Ａｄ−ｈｏｃ Ｎｅｔｗｏｒｋ）が発展してきた。災害現場のような、固定通信インフラが利用できない環境においても、アドホックネットワークは配置可能である。アドホックネットワークでは、移動ノードのみでネットワークを構成するため、リソースに制限が生じる。災害現場での使用を想定すると、重要なメッセージを他のメッセージよりも速く確実に到達させることが重要である。そのため、制限されたリソースを有効に使用するサービス品質（ＱｏＳ：Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ）ルーティングが関心を集めている。

特許文献１に記載のアドホックネットワークにおいては、要求するサービス品質を、利用可能な帯域幅、誤り率、エンドエンド間の遅延、遅延の変動、ホップカウント、期待される耐久性、優先度を少なくともひとつ含むＱｏＳパラメータとして指定する。指定されたパラメータはそれぞれランク付けされてもよい。各移動ノードが保持しているノードやリンクのＱｏＳメトリックはＱｏＳパラメータに対応している。ＱｏＳパラメータに基づき、ソースノードと目的ノードの間のルート発見時に、ＱｏＳメトリックに対してＱｏＳパラメータのランクに応じた重み係数を乗じ、更に、重み係数を乗じたＱｏＳメトリックの総和を選択可能なルートのそれぞれに対して生成することで、要求するサービス品質を満たすルートを選択している。
特開２００４−５６７８７号公報

上述の特許文献１のＱｏＳパラメータによるルート選択では、利用可能な複数の経路から優先度を含むＱｏＳパラメータを考慮してサービス品質を満たすルートを選択している。しかしながら、上述の特許文献１ではアドホックネットワーク内に複数のトラフィックが存在する場合に、他のトラフィックとのリンクもしくはノードの競合に対する優先度によるトラフィック制御は行われていない。

本発明は、上記に鑑みてなされたものであって、アドホックネットワーク内で優先度が示された複数のトラフィックが混在し、優先度の異なるトラフィックの競合が発生した場合に、高優先トラフィックへより最適なルートを提供するとともに低優先トラフィックを再度ルーティングさせる技術を提供することを目的とする。

この発明の通信装置は、
ソースノードから中間ノードを介して目的ノードに到る通信経路を動的に設定可能な移動アドホックネットワークシステムにおける前記中間ノードとなる通信装置において、
自己である前記通信装置を前記中間ノードとする通信経路であって既に設定されている通信経路に要求される要求品質と優先度とを記憶する記憶部と、
前記移動アドホックネットワークシステムを構成する他のノードから自己である前記通信装置を前記中間ノードとする新たな通信経路の設定のリクエストであって新たな前記通信経路に要求される要求品質と優先度とを含むリクエストを受信する中間側通信部と、
前記中間側通信部が受信した前記リクエストの示す新たな前記通信経路の前記要求品質と前記記憶部が記憶している既に設定された前記通信経路に要求される前記要求品質との双方を自己である前記通信装置の資源によって満たすことが可能かを判定し、満たすことができないと判定すると、既に設定されている前記通信経路の前記優先度と前記リクエストの示す新たな前記通信経路の前記優先度とのうち、前記優先度の高いほうの前記通信経路に自己である前記通信装置の前記資源を割り当てる中間側処理部と
を備えたことを特徴とする。

この発明により、移動アドホックネットワーク内で優先度が示された複数のトラフィックが混在し、優先度の異なるトラフィックの競合が発生した場合に、競合を制御することが可能となる。

実施の形態１．
図１は、実施の形態１における移動ノード１０１のハードウェア構成図である。図１において、移動ノード１０１は、プログラムを実行するＣＰＵ８１０（中央処理装置、処理装置、演算装置、マイクロプロセッサ、マイクロコンピュータ、プロセッサともいう）を備えている。ＣＰＵ８１０は、バス８１１を介してＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）８１２、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）８１３、通信部８１４、フラッシュメモリ８２０と接続され、これらのハードウェアデバイスを制御する。フラッシュメモリ８２０の代わりに、磁気ディスク装置を用いても良い。

ＲＡＭ８１３は、揮発性メモリの一例である。ＲＯＭ８１２、フラッシュメモリ８２０等の記憶媒体は、不揮発性メモリの一例である。これらは、記憶装置あるいは記憶部、格納部の一例である。通信部８１４は、入力部、入力装置の一例である。また、通信部８１４は、出力部、出力装置の一例である。

フラッシュメモリ８２０には、オペレーティングシステム８２１（ＯＳ）、プログラム群８２３、ファイル群８２４が記憶されている。プログラム群８２３のプログラムは、ＣＰＵ８１０、オペレーティングシステム８２１により実行される。

上記プログラム群８２３には、以下に述べる実施の形態の移動ノードの説明において「〜部」として説明する機能を実行するプログラムが記憶されている。プログラムは、ＣＰＵ８１０により読み出され実行される。

ファイル群８２４には、以下に述べる実施の形態の説明において、「〜の判定結果」、「〜の算出結果」、「〜の抽出結果」、「〜の生成結果」、「〜の処理結果」として説明する情報や、データや信号値や変数値やパラメータなどが、「〜ファイル」や「〜データベース」の各項目として記憶されている。「〜ファイル」や「〜データベース」は、ディスクやメモリなどの記録媒体に記憶される。ディスクやメモリなどの記憶媒体に記憶された情報やデータや信号値や変数値やパラメータは、読み書き回路を介してＣＰＵ８１０によりメインメモリやキャッシュメモリに読み出され、抽出・検索・参照・比較・演算・計算・処理・出力・表示などのＣＰＵの動作に用いられる。抽出・検索・参照・比較・演算・計算・処理・出力・表示のＣＰＵの動作の間、情報やデータや信号値や変数値やパラメータは、メインメモリやキャッシュメモリやバッファメモリに一時的に記憶される。

また、以下に述べる実施の形態の説明においては、データや信号値は、ＲＡＭ８１３のメモリ、フラッシュメモリ等の記録媒体に記録される。

また、以下に述べる移動ノードの説明において「〜部」として説明するものは、「〜回路」、「〜装置」、「〜機器」、「手段」であってもよく、また、「〜ステップ」、「〜手順」、「〜処理」であってもよい。すなわち、「〜部」として説明するものは、ＲＯＭ８１２に記憶されたファームウェアで実現されていても構わない。或いは、ソフトウェアのみ、或いは、素子・デバイス・基板・配線などのハードウェアのみ、或いは、ソフトウェアとハードウェアとの組み合わせ、さらには、ファームウェアとの組み合わせで実施されても構わない。ファームウェアとソフトウェアは、プログラムとして、ＲＯＭ８１２やフラッシュメモリ８２０の記録媒体に記憶される。プログラムはＣＰＵ８１０により読み出され、ＣＰＵ８１０により実行される。すなわち、プログラムは、以下に述べる「〜部」としてコンピュータを機能させるものである。あるいは、以下に述べる「〜部」の手順や方法をコンピュータに実行させるものである。

次に、図２〜図１５を参照して、複数のトラフィックが混在する移動アドホックネットワークシステム１０００において、ＱｏＳパラメータを考慮したサービス品質を満たすルートの発見・確定時に、複数のトラフィックによるリンクもしくはノードの競合が発生した場合に、低優先トラフィックを再度ルーティングさせる方法について説明する。

図２の移動アドホックネットワークシステム１０００は、移動ノード１０１〜１１２を含む（以下では、移動ノードをノードと言う場合がある）。それぞれの移動ノードは、無線通信リンクにより相互に接続可能である。

図２に示すように、移動ノード１０１をソースノード、ノード１０６，１０７を中間ノード、ノード１１２を目的ノードとするトラフィック２０１ａが存在しているものとする。

以下の実施の形態１は、トラフィック２０１ａが存在している場合に、新たなトラフィック２０２が形成される際、中間ノード１０６、１０７について競合するトラフィック制御に関するものである。

図３は、移動ノード１０１の構成を示すブロック図である。他の移動ノード１０２〜１１２の構成は、移動ノード１０１の構成と同様である。図３を参照して移動ノード１０１を説明する。移動ノード１０１は、無線通信部１１（通信部）、サービス品質ルート要求ＲＲＥＱＱ処理部１２、サービス品質ルート応答ＲＲＥＰＱ処理部１３、サービス品質ルート確定ＣＯＮＦＱ処理部１４、サービス品質エラーＲＥＲＲＱ処理部１５、制御部１６、及びメモリ部１７（記憶部）を備える。ＲＲＥＱＱ処理部１２〜制御部１６は、処理部を構成する。
（１）ここで「ＲＲＥＱＱ」とは、サービス品質ルート要求を示す。
（２）サービス品質ルート応答である「ＲＲＥＰＱ」とは、「ＲＲＥＱＱ」に対する目的ノードからの応答である。
（３）サービス品質ルート確定である「ＣＯＮＦＱ」とは、「ＲＲＥＰＱ」を受信したソースノードが目的ノードに送信する情報である。
（４）サービス品質エラーを示すメッセージである「ＲＥＲＲＱ」とは、中継するべきトラフィックを既存のトラフィックから既存のトラフィックよりも優先度の高い新規なトラフィックに切り替えた中間ノードが、既存のトラフィックのソースノードに向けて送信するエラーメッセージである。
（５）これら、「ＲＲＥＱＱ」、「ＲＲＥＰＱ」、「ＣＯＮＦＱ」、「ＲＥＲＲＱ」は、先行技術として示した特開２００４−５６７８７号公報の場合と同様である。

図２の移動アドホックネットワークシステム１０００は、ソースノードから中間ノードを介して目的ノードに到る通信経路を動的に設定可能である。図３のメモリ部１７は、自己である移動ノードを中間ノードとする通信経路であって既に設定されている通信経路に要求される要求品質と優先度などを記憶している。また、無線通信部１１は、移動アドホックネットワークシステム１０００を構成する他の移動ノードから自己である移動ノードを中間ノードとする新たな通信経路の設定のリクエストであって新たな通信経路に要求される要求品質と優先度とを含むリクエストである「ＲＲＥＱＱ」を受信する。また、ＲＲＥＱＱ処理部１２〜制御部１６から構成される処理部は、無線通信部１１が受信した「ＲＲＥＱＱ」の示す新たな通信経路の要求品質とメモリ部１７が記憶している既に設定された通信経路に要求される要求品質との双方を自己である移動ノードの資源によって満たすことが可能かを判定し、満たすことができないと判定すると、既に設定されている通信経路の優先度と「ＲＲＥＱＱ」の示す新たな通信経路の優先度とのうち、優先度の高いほうの通信経路に自己である移動ノードの資源を割り当てる。そして、この処理部は、「ＲＲＥＱＱ」の示す新たな通信経路に自己である移動ノードの資源を割り当てた場合には、既に設定されている通信経路を介することによりそのソースノードに伝達可能なメッセージであってエラーの発生を通知するエラーメッセージである「ＲＥＲＲＱ」を生成する。無線通信部１１は、処理部が生成した「ＲＥＲＲＱ」を設定されている通信経路のソースノードに向けて送出する。

無線通信部１１は、無線通信により移動アドホックネットワークシステム１０００における他のノードとデータ通信を行う。

ＲＲＥＱＱ処理部１２は、ノードが「ＲＲＥＱＱ」を受信した場合の処理を行うとともに、ソースノードの場合には、「ＲＲＥＱＱ」を生成する。ＲＲＥＱＱ処理部１２による「ＲＲＥＱＱ」の受信処理は図６に示す。

ＲＲＥＰＱ処理部１３は、ノードが「ＲＲＥＰＱ」を受信した場合の処理を行うとともに、目的ノードの場合には、「ＲＲＥＰＱ」を生成する。ＲＲＥＰＱ処理部１３による「ＲＲＥＰＱ」の受信処理は図８に示す。

ＣＯＮＦＱ処理部１４は、ノードが「ＣＯＮＦＱ」を受信した場合の処理を行うとともに、ソースノードの場合には、「ＣＯＮＦＱ」を生成する。ＣＯＮＦＱ処理部１４による「ＣＯＮＦＱ」の受信処理は図１０に示す。

ＲＥＲＲＱ処理部１５は、ノードが「ＲＥＲＲＱ」を受信した場合の処理を行うとともに、該当するノードの場合、「ＲＥＲＲＱ」を生成する。ＲＥＲＲＱ処理部１５による「ＲＥＲＲＱ」の受信処理は図１１に示す。

メモリ部１７は、ノードが受信したルーティングメッセージを記憶しておく。また、制御部１６は、移動ノードは無線通信部１１、ＲＲＥＱＱ処理部１２、ＲＲＥＰＱ処理部１３、ＣＯＮＦＱ処理部１４、ＲＥＲＲＱ処理部１５、メモリ部１７の制御を行う。

（システムの動作概要）
図４は、移動アドホックネットワークシステム１０００の動作概要を示すフローチャートである。図４及び前述の図２を参照して、移動アドホックネットワークシステム１０００の動作概要を説明する。図４は、移動アドホックネットワークシステム１０００において、図２に示すように新規にノード１０９をソースノードとし、ノード１０４を目的ノードとするトラフィック２０２を送信する手続きを行う処理フローである。

ソースノード１０９は、ＱｏＳパラメータに基づいて目的ノード１０４へのサービス品質を満たすルートを発見するために、サービス品質ルート要求である「ＲＲＥＱＱ」を近隣ノードへブロードキャスト送信する（ステップＳ１０２）。
「ＲＲＥＱＱ」は、「ＱｏＳパラメータ」（要求品質、優先度を含む）、「ソースノードのアドレス」、「目的ノードのアドレス」などを含む。
「ＲＲＥＱＱ」は、自己である移動ノードを中間ノードとする新たな通信経路の設定のリクエストであって新たな通信経路に要求される要求品質と優先度とを含むリクエストである。
また「ＱｏＳパラメータ」には、利用可能な帯域、誤り率、伝送遅延、遅延揺らぎ、耐久性などの要求品質のいずれか一つ以上を設定することが出来る。また「ＱｏＳパラメータ」は、トラフィック転送の優先度を含むことができる。優先度を指定しない場合は、優先度なしとしてトラフィックを扱う。トラフィックにはトラフィックフローを識別するためのフローＩＤを含んでいる。

自己の無線通信部１１から「ＲＲＥＱＱ」を受信したノードは、ＲＲＥＱＱ処理部１２にてＲＲＥＱＱ転送受信処理（ステップＳ１０３）を行なう。「ＲＲＥＱＱ」を受信した目的ノード１０４は、「ＲＲＥＱＱ」への応答として、ＲＲＥＰＱ処理部１３により「ＲＲＥＰＱ」を生成して返信する（ステップＳ１０４）。「ＲＲＥＰＱ」を受信したノードは、ＲＲＥＰＱ処理部１３にて「ＲＲＥＰＱ転送受信処理（ステップＳ１０５）を行う。「ＲＲＥＰＱ」を受信したソースノード１０９は、「ＣＯＮＦＱ」を生成して送信する。「ＣＯＮＦＱ」を受信したノードは、ＣＯＮＦＱ処理部１４にてＣＯＮＦＱ転送受信処理を行う（Ｓ１０６）。

（「ＲＲＥＱＱ」の伝播）
図５は、ソースノード１０９が生成した「ＲＲＥＱＱ」が伝搬する様子を示した図である。図６は「ＲＲＥＱＱ」を受信したノードのフロー処理（Ｓ１０３の詳細）を示す。図５の伝播は、図６のフローチャートに基づく。

図６に示すように、ソースノード１０９が生成しブロードキャストした「ＲＲＥＱＱ」を自己の無線通信部１１により受信したノード（Ｓ２０２）は、ＲＲＥＱＱ処理部１２により自ノードが目的ノードか否かを判断する（ステップＳ２０３）。自ノード宛の「ＲＲＥＱＱ」で無ければ（Ｓ２０３のＮＯ）、ＲＲＥＱＱ処理部１２は、自ノード全体の資源でＱｏＳをサポート可能か判断する（ステップＳ２０４）。ここで「資源」とは、要求品質に対応するノードの「能力」を意味し、例えば、帯域資源、ＣＰＵ資源、ストレージ資源などを含む。自己の全ての資源を割り当ててもサポート不可能と判断した場合（図５では、移動ノード１０５、１１０、１０２が該当した場合を示している）は（Ｓ２０４のＮＯ）、ＲＲＥＱＱ処理部１２は、図５のように「ＲＲＥＱＱ」を転送せず破棄する（ステップＳ２０９）。ＱｏＳをサポート可能なノードは（Ｓ２０４のＹｅｓ）、ＲＲＥＱＱ処理部１２が、既存トラフィックの有無を判定する（ステップＳ２０５）。ＱｏＳをサポート可能で既存トラフィックのないノード（ノード１０３が該当するものとする）は（Ｓ２０５のＮＯ）、ＲＲＥＱＱ処理部１２が無線通信部１１を介して「ＲＲＥＱＱ」を転送し、自己であるノードの資源を仮予約する（ステップＳ２０８）。移動ノード１０６，１０７のようにノードが既存トラフィックを転送／受信している場合は（Ｓ２０５のＹＥＳ）、ＲＲＥＱＱ処理部１２が既存トラフィックと新規トラフィックとの優先度を比較する（ステップＳ２０６）。新規トラフィックが既存トラフィックより優先度が高ければ、ＲＲＥＱＱ処理部１２は無線通信部１１を介して隣接ノードへ「ＲＲＥＱＱ」を転送し、ノードの資源を仮予約する（ステップＳ２０８）。既存トラフィックより新規トラフィックの優先度が低いか同じである場合、ＲＲＥＱＱ処理部１２は既存のトラフィックと新規トラフィックを同時にサポート可能か判断する（ステップＳ２０７）。同時にサポート可能ならば、ＲＲＥＱＱ処理部１２は無線通信部１１を介して「ＲＲＥＱＱ」を隣接ノードへ転送し、自己の資源を仮予約する（ステップＳ２０８）。複数のトラフィックを同時にサポート不可能な場合は、ＲＲＥＱＱ処理部１２は「ＲＲＥＱＱ」を転送せずに破棄する（ステップＳ２０９）。目的ノード１０４は「ＲＲＥＱＱ」を受信すると、ＲＲＥＰＱ処理部１３が利用可能な全てのルートに対してサービス品質ルート応答である「ＲＲＥＰＱ」を生成して無線通信部１１を介して返信し、ＱｏＳを満たす可能性のあるルートを報告する（ステップＳ２１０）。

（「ＲＲＥＰＱ」の伝播）
図７は、目的ノード１０４が生成した「ＲＲＥＰＱ」が伝搬する様子を示した図である。図８は「ＲＲＥＰＱ」を受信したノードのフロー処理を示す。図７の伝播は、図８のフローチャートに基づく。図７に示すように「ＲＲＥＰＱ」は「ＲＲＥＱＱ」の経路を戻る。

図８を参照して説明する。無線通信部１１を介して「ＲＲＥＰＱ」を受信したノードでは（Ｓ３０２）、ＲＲＥＰＱ処理部１３が、受信した「ＲＲＥＰＱ」が自ノード宛のメッセージか判断する（ステップＳ３０３）。図７の場合、中間ノードのノード１０３，１０７，１０６は、自ノード宛の「ＲＲＥＰＱ」ではないため、それぞれのノードのＲＲＥＰＱ処理部１３が、ソースノード１０９に向けて「ＲＲＥＰＱ」を転送する（Ｓ３０３のＮＯ→Ｓ３０６）。「ＲＲＥＰＱ」を受信したソースノード１０９では、ＣＯＮＦＱ処理部１４が、ＱｏＳを満たす単一もしくは複数のルートから最適なルートを選択（ステップＳ３０４）するとともに、サービス品質ルート確定を示す情報である「ＣＯＮＦＱ」を生成し、生成した「ＣＯＮＦＱ」を選択したルートに沿って無線通信部１１を介して目的ノード１０４へ送信する（ステップＳ３０５）。

（「ＣＯＮＦＱ」の伝播）
図９は、ソースノード１０９が生成した「ＣＯＮＦＱ」が伝搬する様子を示した図である。図１０は「ＣＯＮＦＱ」を受信したノードのフロー処理を示す。図９の伝播は、図１０のフローチャートに基づく。図９に示すように「ＣＯＮＦＱ」は、ソースノードのＣＯＮＦＱ処理部１４が選択した経路を伝播する。

図９に示すように、無線通信部１１を介して「ＣＯＮＦＱ」を受信した移動ノード１０６，１０７，１０４は、ＣＯＮＦＱ処理部１４により、既存トラフィックと新規トラフィックとを同時にサポート可能か判断する（ステップＳ４０３）。同時にサポート可能もしくは単一トラフィックならば、ＣＯＮＦＱ処理部１４は新規トラフィックにノードの資源を割り当て、中間ノードであれば「ＣＯＮＦＱ」を次ノードへ転送する（ステップＳ４０５）。同時にサポート不可能ならば、ＣＯＮＦＱ処理部１４は、高優先トラフィックに資源を割り当て、「ＣＯＮＦＱ」を次ノードへ転送する（ステップＳ４０６）とともに、ＲＥＲＲＱ処理部１５は、低優先トラフィックのソースノード１０１へ、ルート利用不可能を示すルートエラーメッセージである「ＲＥＲＲＱ」を無線通信部１１を介して低優先トラフィックのルートに沿って送信する（ステップＳ４０７）。

図１１に「ＲＥＲＲＱ」を受信したノードの処理フローを示す。図９を参照して説明する。「ＲＥＲＲＱ」を受信したノードは、ＲＥＲＲＱ処理部１５により、自ノード宛の「ＲＥＲＲＱ」か判断する（ステップＳ５０３）。図９において自ノード宛てではないと判定した場合（Ｓ５０３のＮＯ）、「ＲＥＲＲＱ」を受信した中間ノード１０６（ノード１０７から受信）は、ＲＥＲＲＱ処理部１５により、同一の「ＲＥＲＲＱ」を既に受信しているか判断する（ステップＳ５０４）。初めて受信する「ＲＥＲＲＱ」ならば、ＲＥＲＲＱ処理部１５は、トラフィックのために確保していたノードの資源を解放し、ソースノード１０１に向けて「ＲＥＲＲＱ」を転送する（ステップＳ５０６）。既に転送／送信していた場合は、ＲＥＲＲＱ処理部１５は、「ＲＥＲＲＱ」を転送せず破棄してもよい（ステップＳ５０７）。これにより、ソースノード１０１が重複して「ＲＥＲＲＱ」を受信しないようにしている。「ＲＥＲＲＱ」を受信したソースノード１０１は、用意しておいた代替ルートを使用するか、「ＲＲＥＱＱ」を送信することで再度ルーティングを行い、高優先トラフィックとリンクもしくはノードの競合が発生しないルートを発見の手続きを行う（ステップＳ５０５）。

上記手順により、既存トラフィック２０１ａよりも高優先なトラフィック２０２を送信するルートを確保する。

図１２は、ノード１０１が再度ルーティングのために送信（Ｓ５０５）した「ＲＲＥＱＱ」の伝播の様子を示す。この「ＲＲＥＱＱ」は、ノード１０１のＲＲＥＱＱ処理部が生成する。ＲＲＥＱＱ」を受信したノードは、図６のフローに従い処理される。図１２では、ノード１０２，１０５，１１０，１１１が、ＱｏＳをサポート可能と判断して「ＲＲＥＱＱ」を転送しており、ノード１０３はサポート不可能であると判断し破棄する。ノード１０６，１０７では、受信した「ＲＲＥＱＱ」はトラフィック２０２より優先度が低く、また、ＱｏＳを同時にサポート不可能と判断され破棄されたものである。「ＲＲＥＱＱ」を受信した目的ノード１１２は、ソースノード１０１に対して「ＲＲＥＰＱ」を返信し、選択可能なルートを報告する。

図１３に再度ルーティングに対する「ＲＲＥＰＱ」の伝搬を示す。「ＲＲＥＰＱ」を受信した中間ノード１１１，１１０，１０５は、図８の処理に従い、ソースノード１０１に向けて「ＲＲＥＰＱ」を転送する。「ＲＲＥＰＱ」を受信したソースノード１０１は、ＱｏＳを満たす単一もしくは複数のルートから最適なルートを選択（ステップＳ３０４）し、サービス品質ルート確定の情報である「ＣＯＮＦＱ」を選択したルートに沿って目的ノード１０４へ送信する（ステップＳ３０５）。

図１４に再度ルーティングに対する「ＣＯＮＦＱ」の伝搬を示す。「ＣＯＮＦＱ」を受信した移動ノード１０５，１１０，１１１，１１２は、既存トラフィックがないため、トラフィック１のために資源を割り当て「ＣＯＮＦＱ」を転送する。

上記手順により、図１５に示すように、トラフィック２０２より低優先度であるトラフィック２０１ｂを再度ルーティングし、トラフィック２０２と競合の発生しないルートを確保する。

各トラフィックの中間ノード１０５，１０６，１０７，１１０，１１１と目的ノード１０４，１１２は、常にノードが各サービス品質をサポート可能か否か検出してよい（図４のステップＳ１０７）。トラフィック転送中もしくは受信中にサービス品質をサポート不可能になったと判断すると、トラフィックのソースノードにルートエラー「ＲＥＲＲＱ」を送信する（図４のステップＳ１０９）。更に転送もしくは受信中のトラフィックが継続しているか否か検出しても良い（図４ステップＳ１０８）。一定期間トラフィックを転送しなければトラフィックが終了したと判断し、そのトラフィックに割り当てていた資源を解放する（図４のステップＳ１１１）。

この移動アドホックネットワークシステムでは、Ｄｙｎａｍｉｃ Ｓｏｕｒｃｅ Ｒｏｕｔｉｎｇ（ＤＳＲ）もしくはＡｄ−Ｈｏｃ Ｏｎ−Ｄｅｍａｎｄ Ｄｉｓｔａｎｃｅ Ｖｅｃｔｏｒ（ＡＯＤＶ）のようなリアクティブのルーティングプロトコル、または、Ｚｏｎｅ Ｒｏｕｔｉｎｇ Ｐｒｏｔｏｃｏｌ（ＺＲＰ）のようなハイブリッドのプロアクティブ／リアクティブのプロトコルにも適応可能である。

以上の実施の形態１では通信装置としての移動ノードを説明したが、移動ノードの各構成要素の動作を処理ととらえることにより、移動ノード（通信装置）の動作（処理）をコンピュータに実行させる通信プログラムとして把握することも可能である。

上記の手順により、移動アドホックネットワークシステムにおいて優先度が示された複数のトラフィックが混在し、優先度の異なる他のトラフィックとのリンクもしくはノードの競合が発生した場合には、低優先トラフィックを再度ルーティングさせることで競合を回避し、高優先トラフィックへより最適なルートを提供することができる。

以上の実施の形態１では、ソースノードと目的ノードの間に複数の中間ノードを持つ移動アドホックネットワークにおける複数のＱｏＳ（サービス品質）パラメータに基づいてソースノードと目的ノードの間で通信を行うシステムにおいて、既にいくつかの通信経路が設定されている状態から、新規の通信経路を設定する場合に、各ノードと各リンクにおけるＱｏＳ保証の可否を示すＱｏＳメトリックと比較する機能を備え、優先トラフィックと非優先トラフィックを順位付ける手段を備えたノードを説明した。

以上の実施の形態１では、既に設定されている通信経路が、非優先トラフィックかつＱｏＳが保証できないときになったとき、非優先トラフィックのソースノードに対し、トラフィック送信の中断を指示するメッセージを送信する手段を備えたノードを説明した。

以上の実施の形態１では、新規の通信経路が優先トラフィックになったとき、あるいは、非優先トラフィックが優先トラフィックのＱｏＳ保証に影響を与えないときのみ、隣接ノードに通信経路を要求するメッセージを転送する手段を備えたノードを説明した。

以上の実施の形態１では、新規の通信経路が優先トラフィックになったとき、あるいは、非優先トラフィックが優先トラフィックのＱｏＳ保証に影響を与えないときのみ、次のノードに通信経路を確定するメッセージを転送する手段を備えたノードを説明した。

実施の形態２．
図１６〜図２３を参照して、実施の形態２を説明する。

実施の形態１は、アドホックネットワーク内で優先度が示された複数のトラフィックが混在し、優先度の異なる他のトラフィックとのリンクもしくはノードの競合が発生した場合に、低優先トラフィックを再度ルーティングさせることで競合を回避し、高優先トラフィックへより最適なルートを提供する方法である。

実施の形態１のトラフィックの競合回避方法では、低優先トラフィックの再ルーティングに関して、高優先トラフィックにより回避可能なルートを確立することができない可能性がある。その結果、低優先トラフィックのソースノードが再ルート要求メッセージを頻発しネットワークを圧迫することも生じうる。

そこで、実施の形態２は、複数のトラフィックが混在する移動アドホックネットワークシステム１０００において、ＱｏＳパラメータを考慮したサービス品質を満たすルートの発見・確定時に、複数のトラフィックによるリンクもしくはノードの競合が発生し、低優先トラフィックの再度のルーティングを試みるが、高優先トラフィックにより競合回避のルートが発見できない場合に、アプリケーションに応じて、低優先トラフィックの転送を一時中断もしくは終了させ、高優先トラフィックが終了したときに直ちに、トラフィック送信を再開する方法について説明する。

実施の形態１〜実施の形態３の動的ルーティングの決定方法は、例えばＤＳＲ（Ｄｙｎａｍｉｃ Ｓｏｕｒｃｅ Ｒｏｕｔｉｎｇ）を元にする。また、実施の形態１でも説明したように、「ＲＲＥＱＱ」は、「ＱｏＳパラメータ」（要求品質、優先度を含む）、「ソースノードのアドレス」、「目的ノードのアドレス」などを含む。また、ＲＲＥＱＱを中継した中間ノードは、自身がＲＲＥＱＱを中継した履歴を記録していく。よって、ＲＲＥＱＱを受信した目的ノードは、受信したＲＲＥＱＱが中継されたルートを知ることができる。目的ノードが生成し送信するＲＲＥＰＱは、「ＲＲＥＱＱ」に含まれていた優先度を含んで生成される。また、目的ノードは、「ＲＲＥＱＱ」に含まれるルート履歴に基づき、ＲＲＥＰＱに自身である目的ノードからソースノードに到るルートを指定して返信する。

図１６の移動アドホックネットワークシステム１０００は、移動ノード１０１〜１１０を含む。それぞれの移動ノードは、無線通信リンクにより相互に接続可能である。

図１６に示すように、移動ノード１０１をソースノード、ノード１０５，１０６を中間ノード、ノード１１０を目的ノードとする低優先のトラフィック２０１が存在しているもとする。

以下の実施の形態２は、トラフィック２０１が存在しており、新たなトラフィック２０２が形成され、中間ノード１０５、１０６についての競合を回避するために、低優先トラフィックのトラフィック２０１の再ルーティングに関するものである。

図１６の移動アドホックネットワークシステム１０００は、ソースノードから中間ノードを介して目的ノードに到る通信経路を動的に設定可能である。図３のメモリ部１７は、自己である移動ノードを中間ノードとする通信経路をトラフィックリストとして記憶している。トラフィックリストの記憶は、例えば、通信経路が確立した後の通信開始時に行なわれる。あるいはＣＯＮＦＱの受信時でも構わない。また、メモリ部１７は、既に設定されている通信経路に要求される要求品質と優先度などを記憶している。

無線通信部１１は、無線通信により移動アドホックネットワークシステム１０００における他のノードとデータ通信を行う。

ＲＲＥＱＱ処理部１２は、ノードが「ＲＲＥＱＱ」を受信した場合の処理を行うとともに、ソースノードの場合には、「ＲＲＥＱＱ」を生成する。ＲＲＥＱＱ処理部１２による「ＲＲＥＱＱ」の受信処理は図１９および図２６に示す。

ＲＲＥＰＱ処理部１３は、ノードが「ＲＲＥＰＱ」を受信した場合の処理を行うとともに、目的ノードの場合には、「ＲＲＥＰＱ」を生成する。ＲＲＥＰＱ処理部１３による「ＲＲＥＰＱ」の受信処理は図２１に示す。また、実施の形態３に示すように、ＲＲＥＰＱ処理部１３は、「ＲＲＥＰＱ」のＯｖｅｒｌｏａｄ処理（傍受処理）を行なう。これは図２８の説明で後述する。

ＣＯＮＦＱ処理部１４は、ノードが「ＣＯＮＦＱ」を受信した場合の処理を行うとともに、ソースノードの場合には、「ＣＯＮＦＱ」を生成する。ＣＯＮＦＱ処理部１４による「ＣＯＮＦＱ」の受信処理は図３０に示す。

ＲＥＲＲＱ処理部１５は、ノードが「ＲＥＲＲＱ」を受信した場合の処理を行うとともに、該当するノードの場合、「ＲＥＲＲＱ」を生成する。ＲＥＲＲＱ処理部１５による「ＲＥＲＲＱ」の受信処理は図２３に示す。

メモリ部１７は、ノードが受信したルーティングメッセージを記憶しておく。また、制御部１６は、無線通信部１１、ＲＲＥＱＱ処理部１２、ＲＲＥＰＱ処理部１３、ＣＯＮＦＱ処理部１４、ＲＥＲＲＱ処理部１５、メモリ部１７の制御を行う。

（システムのリルーティングの動作概要）
図１７は、移動アドホックネットワークシステム１０００の動作概要を示すフローチャートである。図１７及び前述の図１６を参照して、移動アドホックネットワークシステム１０００の動作概要を説明する。図１７は、移動アドホックネットワークシステム１０００において、図１６に示すように新規にノード１０１をソースノードとし、ノード１１０を目的ノードとするトラフィック２０１を再度ルーティングする手続きを行う処理フローである。即ち、図１６において、低優先度のトラフィック２０１が形成されていたところに、後から高優先度のトラフィック２０２が形成されたため、トラフィック２０１が消滅したため、ソースノード１０１は、目的ノード１１０へのリルート処理を行なう場合である。

ソースノード１０１のＲＲＥＱＱ処理部１２は、ＱｏＳパラメータに基づいて目的ノード１１０へのサービス品質を満たすルートを再び発見するために、サービス品質ルート要求である「ＲＲＥＱＱ」に競合回避のルーティングであることを示す、Ｒ（Ｒｅｒｏｕｔｅ）フラグを付加し、近隣ノードへブロードキャスト送信する（ステップＳ１０２ｂ）。
「ＲＲＥＱＱ」は、「ＱｏＳパラメータ」（要求品質、優先度を含む）、「ソースノードのアドレス」、「目的ノードのアドレス」などを含む。

図１７に示すように、自己の無線通信部１１から「ＲＲＥＱＱ」を受信したノードは、ＲＲＥＱＱ処理部１２にてＲＲＥＱＱ転送受信処理（ステップＳ１０３ｂ）を行なう。「ＲＲＥＱＱ」を受信した目的ノード１１０は、「ＲＲＥＱＱ」への応答として、ＲＲＥＰＱ処理部１３により「ＲＲＥＰＱ」を生成して返信する（ステップＳ１０４ｂ）。「ＲＲＥＰＱ」を受信したノードは、ＲＲＥＰＱ処理部１３にて「ＲＲＥＰＱ転送受信処理（ステップＳ１０５ｂ）を行う。「ＲＲＥＰＱ」を受信したソースノード１０１は、「ＣＯＮＦＱ」を生成して送信する。「ＣＯＮＦＱ」を受信したノードは、ＣＯＮＦＱ処理部１４にてＣＯＮＦＱ転送受信処理を行う（Ｓ１０６ｂ）。

（Ｒフラグ付き「ＲＲＥＱＱ」の伝搬）
図１８は、ソースノード１０１が生成したＲフラグ（Ｒｅｒｏｕｔｅフラグ）付き「ＲＲＥＱＱ」が伝搬する様子を示した図である。Ｒフラグは、リルート処理を示すフラグである。図１９はＲフラグ付き「ＲＲＥＱＱ」を受信したノードの処理（Ｓ１０３ｂの詳細）を示す。図１８の伝搬は、図１９のフローチャートに基づく。

図１９に示すように、ソースノード１０１が生成しブロードキャストしたＲフラグ付き「ＲＲＥＱＱ」を自己の無線通信部１１により受信したノード（Ｓ２０２ｂ）は、ＲＲＥＱＱ処理部１２により自ノードが目的ノードか否かを判定する（ステップＳ２０３ｂ）。自ノード宛ての「ＲＲＥＱＱ」でなければ（Ｓ２０３ｂのＮＯ）、ＲＲＥＱＱ処理部１２は、自ノード全体の資源でＱｏＳをサポート可能か判断する（ステップＳ２０４ｂ）。ここで「資源」とは、要求品質に対応するノードの「能力」を意味し、例えば、帯域資源、ＣＰＵ資源、ストレージ資源などを含む。自己の全ての資源を割り当ててもサポート不可能と判断した場合は（Ｓ２０４ｂのＮＯ）、ＲＲＥＱＱ処理部１２は、「ＲＲＥＱＱ」を転送せず破棄する（ステップＳ２１１ｂ）。ＱｏＳをサポート可能なノードは（Ｓ２０４ｂのＹｅｓ）、ＲＲＥＱＱ処理部１２が、既存トラフィックの有無を判定する（ステップＳ２０５ｂ）。ＱｏＳをサポート可能で既存トラフィックの無いノード（ノード１０２，１０３が該当するものとする）は（Ｓ２０５ｂのＮＯ）、ＲＲＥＱＱ処理部１２が無線通信部１１を介して「ＲＲＥＱＱ」を転送し、自己であるノードの資源を仮予約する（ステップＳ２０８ｂ）。移動ノード１０５，１０６のようにノードが既存トラフィックを転送／受信している場合は（Ｓ２０５ｂのＹＥＳ）、ＲＲＥＱＱ処理部１２が既存トラフィックと再ルートトラフィックとの優先度を比較する（ステップＳ２０６ｂ）。再ルートトラフィックが既存トラフィックより優先度が高ければ、ＲＲＥＱＱ処理部１２は無線通信部１１を介して隣接ノードへ「ＲＲＥＱＱ」を転送し、ノードの資源を仮予約する（ステップＳ２０８ｂ）。既存トラフィックより再ルートトラフィックの優先度が低いか同じである場合、ＲＲＥＱＱ処理部１２は既存のトラフィックと再ルートトラフィックを同時にサポート可能か判断する（ステップＳ２０７ｂ）。同時にサポート可能ならば、ＲＲＥＱＱ処理部１２は無線通信部１１を介して「ＲＲＥＱＱ」を隣接ノードへ転送し、自己の資源を仮予約する（ステップＳ２０８ｂ）。複数のトラフィックを同時にサポート不可能な場合は、ＲＲＥＱＱ処理部１２は「ＲＲＥＱＱ」にＲフラグがあるか否かを確認する（ステップ２０９ｂ）。Ｒフラグ付き「ＲＲＥＱＱ」の場合は（ステップＳ２０９ｂのＹＥＳ）、ＲＲＥＱＱ処理部１２は無線通信部１１を介して「ＲＲＥＱＱ」を近隣ノードに転送する。Ｒフラグ付き「ＲＲＥＱＱ」でない場合は（ステップＳ２０９ｂのＮＯ）、ＲＲＥＱＱ処理部１２は「ＲＲＥＱＱ」を転送せず破棄する（ステップＳ２１１ｂ）。

目的ノード１１０は「ＲＲＥＱＱ」を受信すると、ＲＲＥＰＱ処理部１３が利用可能な全てのルートに対してサービス品質ルート応答である「ＲＲＥＰＱ」を生成する（ステップＳ２１２ｂ）し、「ＲＲＥＱＱ」にＲフラグがあるか判断する（ステップＳ２１３ｂ）。「ＲＲＥＱＱ」にＲフラグがある場合は（ステップＳ２１３ｂのＹＥＳ）、「ＲＲＥＰＱ」にＲフラグをセット（対応フラグ付きリプライ）する（ステップＳ２１４ｂ）。目的ノード１１０は、「ＲＲＥＰＱ」を生成すると、ＲＲＥＰＱ処理部１３が利用可能な全てのルートに対して無線通信部１１を介して返信し、ルートを報告する（ステップＳ２１５ｂ）。

（「ＲＲＥＰＱ」の伝搬）
図２０は目的ノード１１０が生成した「ＲＲＥＰＱ」が伝搬する様子を示した図である。図２１は「ＲＲＥＰＱ」を受信したノードのフロー処理を示す。図２０の伝播は、図２１のフローチャートに基づく。

図２１を参照して説明する。無線通信部１１を介して「ＲＲＥＰＱ」を受信したノードでは（Ｓ３０２ｂ）、ＲＲＥＰＱ処理部１３が、受信した「ＲＲＥＰＱ」が自ノード宛のメッセージか判断する（ステップＳ３０３ｂ）。自ノード宛のメッセージではない場合は（ステップＳ３０３ｂのＮＯ）、「ＲＲＥＰＱ」にＲフラグがセットされているか否かを判断する（ステップＳ３０４ｂ）。「ＲＲＥＰＱ」にＲフラグがセットされていない場合は（ステップＳ３０４ｂのＮＯ）、それぞれのノードのＲＲＥＰＱ処理部１３が、ソースノード１０１に向けて「ＲＲＥＰＱ」を転送する（ステップＳ３０７ｂ）。「ＲＲＥＰＱ」にＲフラグがセットされている場合は（ステップＳ３０４ｂのＹＥＳ）、自ノードが高優先トラフィックを転送しているか判断する（ステップＳ３０５ｂ）。これは「ＲＲＥＰＱ」は優先度を含んでおり、また、ノードは自己が転送しているトラフィックの情報をトラフィックリスト（優先度を含む）としてメモリ部１７に記憶しており、判断可能である。自ノードが高優先トラフィックを送信していない場合は（ステップＳ３０５ｂのＮＯ）、それぞれのノードのＲＲＥＰＱ処理部１３が、ソースノード１０１に向けて「ＲＲＥＰＱ」を転送する（ステップＳ３０７ｂ）。自ノードが高優先トラフィックを送信している場合は（ステップＳ３０５ｂのＹＥＳ）、ＲＲＥＰＱ処理部１３が「ＲＲＥＰＱ」にＷ（Ｗａｉｔ）フラグ（待機フラグ）をセットし（ステップＳ３０６ｂ）、ソースノード１０１に向けて「ＲＲＥＰＱ」を転送する（ステップＳ３０７ｂ）。

「ＲＲＥＰＱ」を受信したソースノード１０１では、ＲＲＥＰＱ処理部１３が、「ＲＲＥＰＱ」にＷフラグがセットされている否かを判断する（ステップＳ３０８ｂ）。「ＲＲＥＰＱ」にＷフラグがセットされていない場合は（ステップＳ３０８ｂのＮＯ）、ＣＯＮＦＱ処理部１４が、ＱｏＳを満たす単一もしくは複数のルートから最適なルートを選択（ステップＳ３１０ｂ）するとともに、サービス品質ルート確定を示す情報である「ＣＯＮＦＱ」を生成し、生成した「ＣＯＮＦＱ」を選択したルートに沿って無線通信部１１を介して目的ノード１０４へ送信する（ステップＳ３１１ｂ）。

「ＲＲＥＰＱ」にＷフラグがセットされている場合は（ステップＳ３０８ｂのＹＥＳ）、ソースノードのＲＲＥＰＱ処理部１３は、競合を回避するルートを発見できなかったと判断し、自ノードトラフィック転送を中断し、ＲＥＲＲＱ受信待ち状態にする、もしくはトラフィックの転送を終了する（ステップＳ３０９ｂ）。

上記の手順により、トラフィック２０１の再ルーティングの一時停止もしくは中断することで、トラフィック２０１の一時停止もしくは中断を行う。

各トラフィックの中間ノード１０５，１０６と目的ノード１０４は、常にノードが各サービス品質をサポート可能か否か検出してよい（図１７のステップＳ１０７ｂ）。トラフィック転送中もしくは受信中にサービス品質をサポート不可能になったと判断すると、トラフィックのソースノードにルートエラー「ＲＥＲＲＱ」を送信する（図１７のステップＳ１０９ｂ）。更に転送もしくは受信中のトラフィックが継続しているか否か検出しても良い（図１７ステップＳ１０８ｂ）。一定期間トラフィックを転送しなければトラフィックが終了したと判断し、そのトラフィックに割り当てていた資源を解放する（図１７のステップＳ１１１ｂ）。

また、それまでトラフィックに割り当てていた資源を解放したノードは、競合を回避するための「ＲＥＲＲＱ」を転送したことがあり、競合トラフィックの再ルーティングメッセージに対する「ＲＲＥＰＱ」にＷフラグをセットして送信したことがあるか否かを判断し（図１７のステップＳ１１２ｂ）、該当するノードであると判断すると図２２に示すように中間ノード１０５はソースノード１０１に資源を解放したことを「ＲＥＲＲＱ」（再開指示信号）で送信して、再度ルーティングを行うように通知する（図１７のステップＳ１０９ｂ）。

図２２は、ノード１０５がノード１０１に対して再度ルーティングを行うように送信したトラフィック再開のための「ＲＥＲＲＱ」の伝搬の様子を示す。図２２の伝搬は、図２３に示すフローに従う。

図２３に「ＲＥＲＲＱ」を受信したノードの処理フローを示す。「ＲＥＲＲＱ」を受信したノードは、ＲＥＲＲＱ処理部１５により、自ノード宛の「ＲＥＲＲＱ」か判断する（ステップＳ５０３ｂ）。自ノード宛てではないと判定した場合（Ｓ５０３ｂのＮＯ）、「ＲＥＲＲＱ」を受信した中間ノードは、ＲＥＲＲＱ処理部１５により、同一の「ＲＥＲＲＱ」を既に受信しているか判断する（ステップＳ５０４ｂ）。初めて受信する「ＲＥＲＲＱ」ならば、ＲＥＲＲＱ処理部１５は、トラフィックのために確保していたノードの資源を解放し、ソースノード１０１に向けて「ＲＥＲＲＱ」を転送する（ステップＳ５０６ｂ）。既に転送／送信していた場合は、ＲＥＲＲＱ処理部１５は、「ＲＥＲＲＱ」を転送せず破棄してもよい（ステップＳ５０７ｂ）。これにより、ソースノード１０１が重複して「ＲＥＲＲＱ」を受信しないようにしている。「ＲＥＲＲＱ」を受信したソースノード１０１は、用意しておいた代替ルートを使用するか、「ＲＲＥＱＱ」を送信することで再度ルーティングを行い、高優先トラフィックとリンクもしくはノードの競合が発生しないルートを発見の手続きを行う（ステップＳ５０５ｂ）。

上記の手順により、トラフィック２０１のルーティングを再開することで、トラフィック２０１の送信再開を行う。

上記の手順により、移動アドホックネットワークシステムにおいて優先度が示された複数のトラフィックが混在し、優先度の異なる他のトラフィックとのリンクもしくはノードの競合が発生し、低優先トラフィックの再度ルーティングを試みるが、高優先トラフィックにより競合回避のルートが発見できない場合に、低優先トラフィックの転送を一時中断もしくは終了させ、高優先トラフィックが終了した場合は直ちに低優先トラフィックの送信を再開することができる。

実施の形態３．
次に、図２４〜図３１を用いて実施の形態３を説明する。以上の実施の形態２では、トラフィック競合を回避するための再ルーティングがトラフィックを回避するルートを発見できない場合に一時停止もしくは中断および一時停止からの送信再開をするようにしたものであるが、この実施の形態３では、災害時の人命に関わるような緊急性の高いメッセージ送信するといった場合に、ノードもしくはリンクの競合の有無に関わらず、既存のトラフィックの転送を停止させることで、迅速にルートを確立する実施形態を示す。

図２４の移動アドホックネットワークシステム１００１は、移動ノード３０１〜３２０を含む。それぞれの移動ノードは、無線通信リンクにより相互に接続可能である。

図２４に示すように、移動ノード３０１をソースノード、ノード３０７，３１３，３１４を中間ノード、ノード３２０を目的ノードとする低優先のトラフィック２０３と移動ノード３０３をソースノード、ノード３０４を中間ノード、ノード３０５を目的ノードとする低優先のトラフィック２０４が存在しているものとする。新たに移動ノード３１７をソースノード、ノード３１０を目的ノードとするトラフィックが発生する。

以下の実施の形態３は、トラフィック２０３、トラフィック２０４が存在している場合に、新たなトラフィック２０５を送信するためのルーティングにおいて、トラフィック２０５を迅速に目的ノード３１０までのルートを確立するための制御に関するものである。

（Ｅフラグ付き「ＲＲＥＱＱ」の伝搬）
図２５は、緊急メッセージを送信する移動ノード３１７が「ＲＲＥＱＱ」に緊急性の高いトラフィックにＥ（Ｅｍｅｒｇｅｎｃｙ）フラグ（緊急フラグ）を付加し伝搬させた様子を示した図である。図２６は、Ｅフラグ付き「ＲＲＥＱＱ」を受信したフロー処理を示す。図２５の伝搬は、図２６のフローチャートに基づく。

図２５、図２６を参照して説明する。図２５に示すように、ソースノード３１７が生成しブロードキャストしたＥフラグ付き「ＲＲＥＱＱ」を自己の無線通信部１１により受信したノード（Ｓ６０２ｂ）は、ＲＲＥＱＱ処理部１２により自ノードが目的ノードか否かを判定する（ステップＳ６０３ｂ）。自ノード宛ての「ＲＲＥＱＱ」でなければ（６０３ｂのＮＯ）、ＲＲＥＱＱ処理部１２は、自ノード全体の資源でＱｏＳをサポート可能か判断する（ステップＳ６０４ｂ）。ここで「資源」とは、要求品質に対応するノードの「能力」を意味し、例えば、帯域資源、ＣＰＵ資源、ストレージ資源などを含む。図２５のノード３１８の様に自己の全ての資源を割り当ててもサポート不可能と判断した場合は（Ｓ６０４ｂのＮＯ）、ＲＲＥＱＱ処理部１２は、「ＲＲＥＱＱ」を転送せず破棄する（ステップＳ６１１ｂ）。ＱｏＳをサポート可能なノードは（Ｓ６０４ｂのＹｅｓ）、ＲＲＥＱＱ処理部１２が、既存トラフィックの有無を判定する（ステップＳ６０５ｂ）。ＱｏＳをサポート可能で既存トラフィックの無いＱｏＳをサポート可能で既存トラフィックのないノード（ノード１０３が該当するものとする）は（Ｓ６０５ｂのＮＯ）、ＲＲＥＱＱ処理部１２が無線通信部１１を介して「ＲＲＥＱＱ」を転送（ブロードキャスト）し、自己であるノードの資源を仮予約する（ステップＳ６０８ｂ）。移動ノード３０１，３０３，３０４，３０７，３１３，３１４のようにノードが既存トラフィックを送信、転送している場合は（Ｓ６０５ｂのＹＥＳ）、ＲＲＥＱＱ処理部１２が「ＲＲＥＱＱ」にＥフラグがセットしてあるか否かを判断する（ステップＳ６０６ｂ）。「ＲＲＥＱＱ」にＥフラグがセットしてある場合は（Ｓ６０６ｂのＹＥＳ）、既存トラフィックの送信を停止し（ステップＳ６０７ｂ）、ＲＲＥＱＱ処理部１２は無線通信部１１を介して「ＲＲＥＱＱ」を隣接ノードへ転送し、自己の資源を仮予約する（ステップＳ６１２ｂ）。「ＲＲＥＱＱ」にＥフラグがセットされていない場合は（ステップＳ６０６ｂのＮＯ）、図１９の「Ｓ２０６ｂのＮＯ」以降と同様である。すなわち、ＲＲＥＱＱ処理部１２が既存トラフィックと新規トラフィックとの優先度を比較する（ステップＳ６０８ｂ）。新規トラフィックが既存トラフィックより優先度が高ければ、ＲＲＥＱＱ処理部１２は無線通信部１１を介して隣接ノードへ「ＲＲＥＱＱ」を転送し、ノードの資源を仮予約する（ステップＳ６１２ｂ）。既存トラフィックより新規トラフィックの優先度が低いか同じである場合、ＲＲＥＱＱ処理部１２は既存のトラフィックと新規トラフィックを同時にサポート可能か判断する（ステップＳ６０９ｂ）。同時にサポート可能ならば、ＲＲＥＱＱ処理部１２は無線通信部１１を介して「ＲＲＥＱＱ」を隣接ノードへ転送し、自己の資源を仮予約する（ステップＳ６１２ｂ）。複数のトラフィックを同時にサポート不可能な場合は、ＲＲＥＱＱ処理部１２は「ＲＲＥＱＱ」にＲフラグがあるか否かを確認する（ステップＳ６１０ｂ）。Ｒフラグ付き「ＲＲＥＱＱ」の場合は（ステップＳ６１０ｂのＹＥＳ）、ＲＲＥＱＱ処理部１２は無線通信部１１を介して「ＲＲＥＱＱ」を近隣ノードに転送する。Ｒフラグ付き「ＲＲＥＱＱ」でない場合は（ステップＳ６１０ｂのＮＯ）、ＲＲＥＱＱ処理部１２は「ＲＲＥＱＱ」を転送せず破棄する（ステップＳ６１３ｂ）。

目的ノード１１０は「ＲＲＥＱＱ」を受信すると（ステップＳ６０３ｂのＹＥＳ）、ＲＲＥＰＱ処理部１３が利用可能な全てのルートに対してサービス品質ルート応答である「ＲＲＥＰＱ」を生成する（ステップＳ６１４ｂ）し、「ＲＲＥＱＱ」にＲフラグがあるか判断する（ステップＳ６１５ｂ）。「ＲＲＥＱＱ」にＲフラグがある場合は（ステップＳ６１５ｂのＹＥＳ）、「ＲＲＥＰＱ」にＲフラグをセットする（ステップＳ６１６ｂ）。目的ノード１１０は、「ＲＲＥＰＱ」を生成すると、ＲＲＥＰＱ処理部１３が利用可能な全てのルートに対して無線通信部１１を介して返信し、ルートを報告する（ステップＳ６１７ｂ）。

図２７は、Ｅフラグがセットされた「ＲＲＥＱＱ」を受信した目的ノード３１０が生成した「ＲＲＥＰＱ」（緊急フラグ対応リプライ）が、目的ノード３１０から、「ＲＲＥＰＱ」に返信経路として示されるノード３０９，３１３もしくはノード３１４，３１３を経由して、ソースノード３１７へ送信される様子と、それぞれのノードが送信した「ＲＲＥＰＱ」は指定したノード以外でも隣接ノードであればｏｖｅｒｌｏａｄ（傍受）可能であることを示した図である。図２８は、「ＲＲＥＰＱ」をｏｖｅｒｌｏａｄしたノードの処理を示す。ここで「ｏｖｅｒｌｏａｄ（傍受）」とは、「ＲＲＥＰＱ」に返信経路として示されていないノードが、「ＲＲＥＰＱ」を受信し、所定の処理を実行することを意味する。ノードは、そのようにプログラミングされている。

（「ＲＲＥＰＱ」の伝搬）
図２７に示すように、無線通信部１１を介して「ＲＲＥＰＱ」を受信した移動ノード３０９，３１４，３１３，３１７は、ＲＲＥＰＱ処理部１３により、図２１に示すフローに従い処理を行う。

（「ＲＲＥＰＱ」のｏｖｅｒｌｏａｄ）
図２７に示すように、ノード３０９の隣接ノードであるノード３０３，３０４，３０５，３０８，３１０，３１４は、ノード３０９が次ノード３１３へ送信した「ＲＲＥＰＱ」を、無線通信部１１を介してｏｖｅｒｌｏａｄする（ステップＳ７０２ｂ）。「ＲＲＥＰＱ」をｏｖｅｒｌｏａｄしたノードはＲＲＥＰＱ処理部１３により、Ｅフラグ付き「ＲＲＥＱＱ」によりトラフィックを停止したか否かを判断する（ステップＳ７０３ｂ）。なお、ノードは、Ｅフラグ付き「ＲＲＥＱＱ」によりトラフィックを停止した場合には、そのことを記憶する。ノード３０３のようにトラフィックを停止していた場合は（ステップＳ７０３ｂのＹＥＳ）、「ＲＲＥＰＱ」に示されるルートと停止したトラフィック２０４ａのルートを比較しノード・ルートの競合が発生しないか判断する（ステップＳ７０４ｂ）。競合が発生する場合は（ステップＳ７０４ｂのＹＥＳ）、何もせず終了する（ステップＳ７０６ｂ）。競合が発生しない場合は（ステップＳ７０４ｂのＮＯ）、ノード３０３で停止したトラフィック２０４の送信を再開する（ステップＳ７０５ｂ）。

図２９は、緊急性の高いトラフィックに対する「ＣＯＮＦＱ」の伝搬を示す。図３０は、緊急性の高いトラフィックに対する「ＣＯＮＦＱ」を受信したノードの処理を示す。

図２９に示すように、中間ノード３１３，３１４，３１０は無線通信部１１を介して「ＣＯＮＦＱ」を受信（ステップＳ４０２ｂ）したノードは、ＣＯＮＦＱ処理部１４により、既存トラフィックリストの存在を確認する（ステップＳ４０３ｂ）。既存トラフィックリストが存在する場合は（ステップＳ４０２ｂのＹＥＳ）、ＱｏＳを同時にサポート可能か判断する（ステップＳ４０４ｂ）。ＱｏＳを同時にサポートできないと判断した場合は（ステップＳ４０４ｂのＮＯ）、ＣＯＮＦＱ処理部１４は、既存トラフィックリストと「ＣＯＮＦＱ」の示すルートを比較し競合が発生する最初のノードか否か判断する（ステップＳ４０８ｂ）。これにより、同一の「ＲＥＲＲＱ」を複数ノードから送信することを防止している。トラフィックの競合が発生する最初のノードである場合は（ステップＳ４０８ｂのＹＥＳ）、ＲＥＲＲＱ処理部１５は、ルート利用不可能を示すルートエラーメッセージである「ＲＥＲＲＱ」を無線通信部１１を介して低優先トラフィックのルートに沿って送信する（ステップＳ４０９ｂ）。トラフィックの競合が発生する最初のノードでない場合（ステップＳ４０８ｂのＮＯ）、もしくは「ＲＥＥＲＱ」を送信した場合は（ステップＳ４０９ｂ）、高優先トラフィックに資源を割り当て、「ＣＯＮＦＱ」を次ノードへ転送する（ステップＳ４１０ｂ）。ＲＥＲＲＱ処理部１５は、低優先トラフィックのソースノード３０１へ送信する。ＣＯＮＦＱ処理部１４は低優先トラフィックを既存トラフィックリストから消去する（ステップＳ４１１ｂ）。既存トラフィックリストが存在しない場合（ステップＳ４０３ｂのＮＯ）、もしくは、ＱｏＳを同時にサポート可能な場合は（ステップＳ４０４ｂのＹＥＳ）、ＣＯＮＦＱ処理部１４は新規トラフィックにノードの資源を割り当て、中間ノードであれば「ＣＯＮＦＱ」を次ノードへ転送し（ステップＳ４０６ｂ）、ＣＯＮＦＱ処理部１４が「ＣＯＮＦＱ」が示すルートを既存トラフィックリストに追加する（ステップＳ４０７ｂ）。

「ＲＥＲＲＱ」を受信したノード３０７は図２３の処理に従い、ソースノード３０１に向けて「ＲＥＲＲＱ」を転送する。「ＲＥＲＲＱ」を受信したソースノード３０１は、代替ルートを選択もしくは、図３１に示すように、再度ルーティングを行うために「ＲＲＥＱＱ」をブロードキャストする。

上記の手順により、災害時の人命に関わるような緊急性の高いメッセージ送信するといった場合に、ノードもしくはリンクの競合の有無に関わらず、既存のトラフィックの転送を停止させることで、迅速にルートを確立する。

以上の実施の形態では、ソースノードと目的ノードの間に複数の中間ノードを持つ移動アドホックネットワークにおいて、複数のＱｏＳ（サービス品質）パラメータに基づいてソースノードと目的ノードの間で、優先トラフィックのＱｏＳを保証するために、非優先トラフィックの送信経路を変更するシステムにおいて、新規の通信経路が優先トラフィックになり、非優先トラフィックが再び送信経路を発見するために、再び送信経路を要求する旨を記した要求メッセージを転送する方法を説明した。

以上の実施の形態では、再び送信経路を発見するために送信した要求メッセージが、優先トラフィックの送信経路により、目的ノードまでＱｏＳを保証する通信経路を発見できなかったことをソースノードに伝達する方法を説明した。

以上の実施の形態では、再び送信経路を発見するために送信した要求メッセージが、優先トラフィックの送信経路により、目的ノードまでＱｏＳを保証する通信経路を発見できなかったため、非優先トラフィックの送信を中断・停止する方法を説明した。

以上の実施の形態では、非優先トラフィックを停止する原因となった優先トラフィックの送信が終了したとき、非優先トラフィックの送信を再開する方法を説明した。

以上の実施の形態では、トラフィックの新規通信経路を発見するときに、既存のトラフィックの有無に関わらず、目的ノードまでの通信経路を発見する方法を説明した。

以上の実施の形態では、各トラフィックの送信経路を記憶しておくことで、ＱｏＳの保証に影響を与える最初のノードであることを判断したときのみ、ソースノードに送信経路の変更を要求する方法を説明した。

実施の形態１における移動ノードのハードウェア構成図。 実施の形態１におけるトラフィック２０１ａを示す図。 実施の形態１における移動ノードのブロック図。 実施の形態１における移動アドホックネットワークシステムの動作概要を示すフローチャート。 実施の形態１におけるサービス品質ルート要求ＲＲＥＱＱの経路を示す図。 実施の形態１におけるＲＲＥＱＱを受信した移動ノードの処理を示すフローチャート。 実施の形態１におけるサービス品質ルート要求ＲＲＥＰＱの経路を示す図。 実施の形態１におけるサービス品質ルート要求ＲＲＥＰＱを受信した移動ノードの処理を示すフローチャート。 実施の形態１におけるサービス品質ルート要求ＣＯＮＦＱの経路を示す図。 実施の形態１におけるサービス品質ルート要求ＣＯＮＦＱを受信した移動ノードの処理を示すフローチャート。 実施の形態１における再ルーティングのＲＲＥＱＱを示す図。 実施の形態１におけるサービス品質エラーを受信した移動ノードの処理を示すフローチャート。 実施の形態１における再ルーティングのＲＲＥＰＱを示す図。 実施の形態１における再ルーティングのＣＯＮＦＱを示す図。 実施の形態１における再ルーティング経路を示す図。 実施の形態２におけるトラフィックを示す図。 実施の形態２における移動アドホックネットワークシステムの動作概要を示すフローチャート。 実施の形態２におけるＲフラグ付きのＲＲＥＱＱの伝播を示す図。 実施の形態２におけるＲＲＥＱＱの受信／転送処理を示すフローチャート。 実施の形態２におけるＲＲＥＰＱの伝搬を示す図。 実施の形態２におけるＲＲＥＰＱの受信／転送処理を示すフローチャート。 実施の形態２におけるＲＥＥＲＱの伝搬を示す図。 実施の形態２におけるＲＥＥＲＱの受信／転送処理を示すフローチャート。 実施の形態３におけるトラフィックを示す図。 実施の形態３におけるＥフラグ付きのＲＲＥＱＱの伝播を示す図。 実施の形態３におけるＲＲＥＱＱの受信／転送処理を示すフローチャート。 実施の形態３におけるＲＲＥＰＱの伝搬を示す図。 実施の形態３におけるＲＲＥＰＱの受信／転送処理を示すフローチャート。 実施の形態３におけるＣＯＮＦＱの経路を示す図。 実施の形態３におけるＣＯＮＦＱの受信／転送処理を示すフローチャート。 実施の形態３におけるＲＥＥＲＱの伝搬を示す図。

符号の説明

１０１ 移動ノード、１１ 無線通信部、１２ ＲＲＥＱＱ処理部、１３ ＲＲＥＰＱ処理部、１４ ＣＯＮＦＱ処理部、１５ ＲＥＲＲＱ処理部、１６ 制御部、１７ メモリ部、２０１ａ，２０１ｂ，２０２ トラフィック、８１０ ＣＰＵ、８１１ バス、８１２ ＲＯＭ、８１３ ＲＡＭ、８１４ 通信部、８２０ フラッシュメモリ、８２１ ＯＳ、８２３ プログラム群、８２４ ファイル群、１０００ 移動アドホックネットワークシステム。

Claims (4)

1. 通信装置であるソースノードから通信装置である中間ノードを介して通信装置である目的ノードに到る通信経路を動的に設定可能な移動アドホックネットワークシステムにおいて、
   通信装置である前記中間ノードは、
   自己である前記通信装置を前記中間ノードとする通信経路であって既に設定されている通信経路に要求される要求品質と優先度とを記憶する記憶部と、
   前記移動アドホックネットワークシステムを構成する他のノードから自己である前記通信装置を前記中間ノードとする新たな通信経路の設定のリクエストであって新たな前記通信経路に要求される要求品質と優先度とを含むリクエストを受信する中間側通信部と、
   前記中間側通信部が受信した前記リクエストの示す新たな前記通信経路の前記要求品質と前記記憶部が記憶している既に設定された前記通信経路に要求される前記要求品質との双方を自己である前記通信装置の資源によって満たすことが可能かを判定し、満たすことができないと判定すると、既に設定されている前記通信経路の前記優先度と前記リクエストの示す新たな前記通信経路の前記優先度とのうち、前記優先度の高いほうの前記通信経路に自己である前記通信装置の前記資源を割り当て、前記リクエストの示す新たな前記通信経路に自己である前記通信装置の前記資源を割り当てた場合には、既に設定されている前記通信経路を介することによりそのソースノードに伝達可能なメッセージであってエラーの発生を通知するエラーメッセージを生成する中間側処理部と
   を備えるとともに、
   前記中間側通信部は、
   前記中間側処理部が生成した前記エラーメッセージを既に設定されている前記通信経路のソースノードに向けて送出し、
   既に設定されている前記通信経路の前記ソースノードは、
   前記エラーメッセージを受信するソース側通信部と、
   前記ソース側通信部が前記エラーメッセージを受信すると、既に設定されている前記通信経路の目的ノードへの新たな通信経路を確立する処理を開始するソース側処理部と
   を備え、
   前記ソースノードは、
   新たな通信経路を確立する前記処理として、前記新たな通信経路の前記優先度と前記品質とを含むとともに前記新たな通信経路の確立処理であるリルート処理を示すフラグを付加したリルートフラグ付きリクエストを生成し、生成された前記リルートフラグ付きリクエストをブロードキャストし、
   前記中間ノードは、
   ブロードキャストされた前記リルートフラグ付きリクエストを受信すると、自己の資源で前記リルートフラグ付きリクエストに含まれる前記品質を満たすことができるかどうかを判定し、満たすことができると判定すると、受信された前記リルートフラグ付きリクエストに自身の中継履歴を付加してブロードキャストし、
   前記目的ノードは、
   前記中間ノードによってブロードキャストされた前記リルートフラグ付きリクエストを受信すると、受信された前記リルートフラグ付きリクエストに対応するリプライであって、前記リルートフラグ付きリクエストに含まれる前記優先度を含むとともに前記リルートフラグに対応するフラグを付加した対応フラグ付きリプライを生成し、生成された前記対応フラグ付きリプライに前記リルートフラグ付きリクエストが伝達された前記ソースノードから自身までの経路を前記対応フラグ付きリプライの送信経路として指定する経路指定を含めて前記対応フラグ付きリプライを送信し、
   前記中間ノードは、
   前記対応フラグ付きリプライを受信すると、前記対応フラグ付きリプライに含まれる優先度よりも優先度の高いトラフィックを自身が転送しているかどうかを判定し、転送していると判定すると、受信された前記対応フラグ付きリプライに待機を示す待機フラグを付加して送信し、
   前記ソースノードは、
   前記待機フラグが付加された前記対応フラグ付きリプライを受信する
   ことを特徴とする移動アドホックネットワークシステム。
2. 前記ソースノードは、
   前記待機フラグが付加された前記対応フラグ付きリプライを受信すると、前記新たな通信経路を確立する前記処理を中止することを特徴とする請求項１記載の移動アドホックネットワークシステム。
3. 前記中間ノードは、
   既存トラフィックに自身の資源を割り当てていた場合に、割り当てていた自身の資源を解放すると、前記待機フラグをセットして前記対応フラグ付きリプライを送信したことがあるかどうかを判定し、送信したことがあると判定すると、前記新たな通信経路を確立する前記処理の再開を前記ソースノードに指示する再開指示信号を生成し、生成された前記再開指示信号を前記ソースノード宛てに送信し、
   前記ソースノードは、
   前記中間ノードから前記再開指示信号を受信すると、新たな通信経路を確立する前記処理を再開することを特徴とする請求項２記載の移動アドホックネットワークシステム。
4. 前記ソースノードは、
   新たな通信経路に要求される品質を含むとともに緊急を示す緊急フラグを付加した緊急フラグ付きリクエストを生成し、生成された前記緊急フラグ付きリクエストをブロードキャストし、
   前記中間ノードは、
   前記緊急フラグ付きリクエストを受信すると、自己の資源で前記緊急フラグ付きリクエストに含まれる前記品質を満たすことができるかどうかを判定し、満たすことができると判定すると、自身が中継している既存トラフィックがあるかどうかを判定し、あると判定すると、既存トラフィックの中継を中止するとともに、受信された前記緊急フラグ付きリクエストに自身の中継履歴を付加してブロードキャストし、
   前記目的ノードは、
   前記中間ノードによりブロードキャストされた前記緊急フラグ付きリクエストを受信すると、受信された前記緊急フラグ付きリクエストに対応する緊急フラグ対応リプライを生成し、生成された前記緊急フラグ対応リプライに前記緊急フラグ付きリクエストが伝達された前記ソースノードから自身までの経路を前記緊急フラグ対応リプライの送信経路として指定する経路指定を含めて送信し、
   前記中間ノードは、
   前記緊急フラグ対応リプライを受信すると、前記緊急フラグ付きリクエストを受信した時に前記既存トラフィックの中継を中止したかどうかを判定し、中止したと判定すると、前記緊急フラグ対応リプライに含まれる経路指定に自身が含まれるかどうかを判定し、自身が含まれていないと判定すると、前記緊急フラグ付きリクエストを受信した時に中止した前記既存トラフィックの中継を再開することを特徴とする請求項１記載の移動アドホックネットワークシステム。

Images