(57)【要約】【課題】計画ルートを優先的にデータ送信ルートとして選択可能とすることにより、アプリケーションの要請を満足し得るアドホックネットワークシステムを得る。【解決手段】各ノードごとにデバイスＩＤが設定されており、各エンドデバイス５１，５５ごとに定められた計画ルートが、ゲートウェイ５８に内蔵されている記憶部５８ｍに、計画ルート情報として記憶されている。エンドデバイス５１及びルータ５２，５３，５６，５７は、自己のデバイスＩＤをルートディスカバリ・パケットに付加して送信する。ゲートウェイ５８は、受信したルートディスカバリ・パケット６４〜６７と、エンドデバイス５１に関する計画ルート情報６１とを比較し、４つのルート候補の中から計画ルートを優先してデータ送信ルートとして選択する。返信パケット６８は、計画ルートのみを逆にたどってエンドデバイス５１まで送られる。【選択図】図１
2006197288.tif 000002
【特許請求の範囲】
【請求項１】
データ送信元ノードと、
データ送信先ノードと、
前記データ送信元ノードと前記データ送信先ノードとの間でデータを中継する複数のデータ中継ノードと
を備え、
前記データ送信先ノードは、前記データ送信元ノードから前記複数のデータ中継ノードのうちの特定のデータ中継ノードを介して前記データ送信先ノードに至るまでの、予め定められた計画ルートを記憶する記憶部を有しており、
前記データ送信元ノードは、ルート探索用パケットを前記複数のデータ中継ノードに送信する機能を有しており、
前記複数のデータ中継ノードの各々は、前記データ送信元ノード又は前段のデータ中継ノードから受信した前記ルート探索用パケットを、次段のデータ中継ノード又は前記データ送信先ノードに送信する機能を有しており、
前記データ送信先ノードは、前記複数のデータ中継ノードから複数のルート探索用パケットを受信し、前記複数のルート探索用パケットによって規定される複数のルート候補の中から、前記計画ルートを優先してデータ送信ルートとして選択する機能を有している、アドホックネットワークシステム。
【請求項２】
前記データ送信元ノード及び前記複数のデータ中継ノードの各々は、個別に設定された識別番号を記憶する記憶部をそれぞれ有している、請求項１に記載のアドホックネットワークシステム。
【請求項３】
前記計画ルートは、前記識別番号の組合せによって指定されており、
前記データ送信元ノードは、前記ルート探索用パケットに自身の前記識別番号を付加して送信する機能を有しており、
前記複数のデータ中継ノードの各々は、受信した前記ルート探索用パケットに自身の前記識別番号を付加して送信する機能を有しており、
前記データ送信先ノードは、受信した前記複数のルート探索用パケットの中に、ルート探索用パケットに付加されている前記識別番号の組合せが、前記計画ルートで指定されている前記識別番号の組合せに一致するものが存在する場合、前記計画ルートを前記データ送信ルートとして選択する機能を有している、請求項２に記載のアドホックネットワークシステム。
【請求項４】
前記計画ルートが前記データ送信ルートとして選択される場合、前記データ送信先ノードから前記計画ルートのみを介して前記データ送信元ノードに返信パケットが送信される、請求項３に記載のアドホックネットワークシステム。
【請求項５】
前記計画ルートは、前記アドホックネットワークシステムの設計時に、当該システムが対象としているアプリケーションの要請に応じて、前記データ送信元ノード、前記データ送信先ノード、及び前記複数のデータ中継ノードの、それぞれの配置場所に基づいて定められる、請求項１〜４のいずれか一つに記載のアドホックネットワークシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、アドホックネットワークシステムに関し、特に、当該システムにおけるルーティング方式に関する。
【背景技術】
【０００２】
アドホックネットワークシステムのルーティングプロトコルは、リアクティブプロトコルとプロアクティブプロトコルとに大別され、代表的なリアクティブプロトコルとしては、ＡＯＤＶ（Adhoc On-demand Distance Vector）やＤＳＲ（Dynamic Source Routing）が知られている。これらのルーティングプロトコルでは、エンドデバイスからゲートウェイへデータを送信するために用いるルート（以下「データ送信ルート」と称す）が、自動的に構築される。その際、全ルータの電池消費量を平準化する等のアプリケーションの要請により、複数存在するルート候補の中からどのルートをデータ送信ルートとして選択するか、優先順位をつけたい場合がある。
【０００３】
なお、下記特許文献１には、サービス品質（ＱｏＳ：Quality of Service）に関するパラメータに基づいてデータ送信ルートを決定する技術が開示されている。
【０００４】
【特許文献１】特開２００４−５６７８７号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
システム構築時には、アプリケーションの要請を反映したノード配置計画に基づき、各エンドデバイスからゲートウェイまでの理想ルート（以下「計画ルート」と称す）が想定され、それに応じて各ノードの配置場所が決定される。しかしながら、ＤＳＲやＡＯＤＶ等のルーティングプロトコルを用いた場合には、たとえノード配置計画に基づき各ノードを配置したとしても、実際の運用時には、アドホック性に起因して、計画ルートに属するルータが故障等していないにも拘わらず計画ルートがデータ送信ルートとして選択されないという状況が生じ得る。その結果、アプリケーションの要請を満足できないという問題が生じる。
【０００６】
本発明はかかる問題を解決するために成されたものであり、計画ルートを優先的にデータ送信ルートとして選択可能とすることにより、アプリケーションの要請を満足し得るアドホックネットワークシステムを得ることを目的とする。
【課題を解決するための手段】
【０００７】
本発明に係るアドホックネットワークシステムは、データ送信元ノードと、データ送信先ノードと、前記データ送信元ノードと前記データ送信先ノードとの間でデータを中継する複数のデータ中継ノードとを備え、前記データ送信先ノードは、前記データ送信元ノードから前記複数のデータ中継ノードのうちの特定のデータ中継ノードを介して前記データ送信先ノードに至るまでの、予め定められた計画ルートを記憶する記憶部を有しており、前記データ送信元ノードは、ルート探索用パケットを前記複数のデータ中継ノードに送信する機能を有しており、前記複数のデータ中継ノードの各々は、前記データ送信元ノード又は前段のデータ中継ノードから受信した前記ルート探索用パケットを、次段のデータ中継ノード又は前記データ送信先ノードに送信する機能を有しており、前記データ送信先ノードは、前記複数のデータ中継ノードから複数のルート探索用パケットを受信し、前記複数のルート探索用パケットによって規定される複数のルート候補の中から、前記計画ルートを優先してデータ送信ルートとして選択する機能を有している。
【発明の効果】
【０００８】
本発明に係るアドホックネットワークシステムによれば、計画ルートが優先的にデータ送信ルートとして選択されることにより、アプリケーションの要請を満足することができる。
【発明を実施するための最良の形態】
【０００９】
以下、本発明の実施の形態に係るアドホックネットワークシステムについて説明する。
【００１０】
本発明が対象として想定しているアプリケーションは、無線ネットワークを用いた、機器や設備等の状態監視や制御等である。図１は、本発明の実施の形態に係るアドホックネットワークシステムの一例を示す図である。データ送信元ノードとしてのエンドデバイス５１には、温度センサ５０が接続されている。同じくデータ送信元ノードとしてのエンドデバイス５５には、振動センサ５４が接続されている。データ送信先ノードとしてのゲートウェイ５８には、パーソナルコンピュータ５９が接続されている。パーソナルコンピュータ５９には、インターネット等の外部ネットワーク６０が接続されている。但し、パーソナルコンピュータ５９を用いるのではなく、ＰＨＳ（Personal Handyphone System）等の携帯電話機を用いて、ゲートウェイ５８と外部ネットワーク６０とが接続されていてもよい。
【００１１】
エンドデバイス５１，５５とゲートウェイ５８との間には、データ中継ノードとしての複数個（図１に示した例では４個）のルータ５２，５３，５６，５７が配置されている。図１において矢印で示した通り、ルータ５２，５３，５６，５７は、エンドデバイス５１，５５とゲートウェイ５８との間で、無線通信によってデータを中継する。
【００１２】
温度センサ５０は機器や室内等の温度を測定し、振動センサ５４は機器等の振動を測定する。温度センサ５０による温度の検出結果に関するデータ、及び振動センサ５４による振動の検出結果に関するデータは、複数のルータ５２，５３，５６，５７間をマルチホップ方式で通信されて、最終的にゲートウェイ５８に送られる。
【００１３】
ゲートウェイ５８は図示しない電源ケーブルを介して外部電源に接続されており、ゲートウェイ５８の動作に必要な電力は、この外部電源から供給される。一方、ルータ５２，５３，５６，５７は、乾電池やボタン電池等から電力供給を受けている。
【００１４】
産業向けアプリケーション、特に現場情報収集用のアプリケーションを設計する場合には、測定対象となる機器の配置場所は分かっている。そのため、温度センサ５０、振動センサ５４、及びエンドデバイス５１，５５を配置すべき場所は決まっている。また、ゲートウェイ５８を配置する場所も決まっていることが多い。そこで、問題となるのは、ルータ５２，５３，５６，５７をどこに配置すればよいかということである。
【００１５】
アドホックネットワークシステムの設計では、故障や電池切れ等によってルータ５２，５３，５６，５７のいずれかが動作不能状態に陥った場合でも、エンドデバイス５１，５５とゲートウェイ５８との接続が確保されるように、ルータ５２，５３，５６，５７の配置場所が定められる。また、全ルータ５２，５３，５６，５７の電池消費量を平準化すべく、特定のルータの負荷が過大とならないように、ルータ５２，５３，５６，５７の配置場所が定められる。つまり、本実施の形態に係るアドホックネットワークシステムの設計では、システムが対象としているアプリケーションの要請に応じて、エンドデバイスからどのルータを介してゲートウェイに至るかという計画ルートが、各ノードの配置場所に基づいて各エンドデバイスごとに予め定められている。例えば図１において太線の矢印で示した通り、エンドデバイス５１に関しては、エンドデバイス５１からルータ５２，５３をこの順に介してゲートウェイ５８に至るルートが、計画ルートとして定められている。
【００１６】
＜ルーティングの前提＞
本実施の形態に係るアドホックネットワークシステムを構築する場合、前提として、以下の作業を人間が行う。
【００１７】
まず、システム設計（以下「ノード配置計画」と称す）を行う。すなわち、エンドデバイス５１，５５及びゲートウェイ５８のそれぞれの配置場所を計画し、対象としているアプリケーションの要請に基づいて、ルータ５２，５３，５６，５７のそれぞれの配置場所を定める。その際、各ノードの配置場所に基づいて、各エンドデバイス５１，５５ごとに計画ルートも定める。
【００１８】
次に、識別番号としてのデバイスＩＤを、各ノードごとに設定する。デバイスＩＤは、ノード間で重複がないように、各ノードごとに個別の値が割り当てられる。図１に示した例では、エンドデバイス５１には「１００」、エンドデバイス５５には「２００」、ルータ５２には「１０」、ルータ５３には「１１」、ルータ５６には「２０」、ルータ５７には「２１」、ゲートウェイ５８には「０」のデバイスＩＤが、それぞれ設定されている。ここで、デバイスＩＤは、ノード配置前に各ノードごとに割り当てられた固有の識別番号であり、ルーティングプロトコルによって自動的に割り当てられるネットワークアドレス等とは異なる。
【００１９】
固有の番号であるデバイスＩＤを各ノードに付与することにより、以降のルーティングにおいて、デバイスＩＤによって各ノードを識別することが可能となる。
【００２０】
設定されたデバイスＩＤは、各ノードに内蔵されているメモリ等の記憶部に記憶される。例えば、エンドデバイス５１に設定されているデバイスＩＤ＝１００は、エンドデバイス５１に内蔵されている記憶部５１ｍに記憶され、ルータ５２に設定されているデバイスＩＤ＝１０は、ルータ５２に内蔵されている記憶部５２ｍに記憶され、ゲートウェイ５８に設定されているデバイスＩＤ＝０は、ゲートウェイ５８に内蔵されている記憶部５８ｍに記憶される。その他のノードについても同様である。
【００２１】
また、各エンドデバイス５１，５５ごとに定められた計画ルートを、デバイスＩＤの組合せによって指定し、ゲートウェイ５８に内蔵されている記憶部５８ｍに、計画ルート情報として記憶する。図２は、計画ルート情報６１を示す図である。上記の通り、エンドデバイス５１に関しては、エンドデバイス５１からルータ５２，５３をこの順に介してゲートウェイ５８に至るルートが、計画ルートとして定められている。従って、計画ルート情報６１の項目６１ａには、エンドデバイス５１のデバイスＩＤ＝１００と、ルータ５２のデバイスＩＤ＝１０と、ルータ５３のデバイスＩＤ＝１１と、ゲートウェイ５８のデバイスＩＤ＝０とを用いて、エンドデバイス５１に関する計画ルート（ＥＰ＝１００）が、「１００，１０，１１，０」と記述されている。なお、エンドデバイス５５に関しては、エンドデバイス５５からルータ５６，５７をこの順に介してゲートウェイ５８に至るルートが、計画ルートとして定められている。よって、計画ルート情報６１の項目６１ｂには、エンドデバイス５５に関する計画ルート（ＥＰ＝２００）が、「２００，２０，２１，０」と記述されている。
【００２２】
次に、図面やＣＡＤ等の配置図を参照することにより、ノード配置計画に基づいて、各ノードを、配置すべき場所にそれぞれ配置する。なお、ノードの誤配置を防止するため、デバイスＩＤを印字したラベルを各ノードに貼付するとともに、配置図にも各ノードのデバイスＩＤを付記しておき、両者のデバイスＩＤを確認しながら各ノードの配置を行うのが望ましい。
【００２３】
ノード配置直後は、アドホックネットワークの機能により、自動的にネットワークが形成される。この段階では、エンドデバイス５１，５５とゲートウェイ５８との間でどのようなルートが形成されているかは不確定である。
【００２４】
＜ルーティングの基本＞
本発明は、アドホックネットワークシステムにおけるルーティング方式に関するものであり、標準規格された各種のルーティングプロトコルや、メーカー独自のルーティングプロトコルに、本発明に係る機能を付加（あるいは一部を変更）するのみで実現できるものである。従って、本発明に係る機能以外のルーティング機能については、本発明に係る機能が付加されるルーティングプロトコルの機能がそのまま使用される。
【００２５】
リアクティブプロトコルでは、データ通信が必要になった場合に、ルートディスカバリが開始される。ここで、ルートディスカバリとは、データ送信元ノードがデータ送信先ノードまでのルートを検索する動作である。本実施の形態に係るアドホックネットワークシステムでは、データ送信元ノードはエンドデバイス５１，５５であり、データ送信先ノードはゲートウェイ５８である。
【００２６】
ルートディスカバリは、基本的には、そのアドホックネットワークが持つルーティングプロトコルに従って実行される。標準的なリアクティブプロトコルとしては、例えばＡＯＤＶやＤＳＲ等がある。これらのプロトコルにおけるルートディスカバリの基本は、以下の通りである。まず、エンドデバイスから送出されたルートディスカバリ・パケット（ルート探索用パケット）が、ルータによってマルチホップされてゲートウェイに送られる。ルートディスカバリ・パケットを受信したゲートウェイは、返信パケットを送出する。ゲートウェイから送出された返信パケットは、同じくルータによって、ルートディスカバリ・パケットが経由したルートを逆向きにマルチホップされてエンドデバイスに送られる。その結果、エンドデバイスは、ゲートウェイからそれぞれ別のルートを経由して送られてきた複数の返信パケットを受信する。エンドデバイスは、多くの場合、複数の返信パケットによって規定される複数のルート候補の中でホップ数が最も少ないルートを、ゲートウェイまでのデータ送信ルートとして選択する。
【００２７】
ところで、ＡＯＤＶやＤＳＲ等の規格では基本部分のみが規定されており、ＺｉｇＢｅｅ等へ実装するにあたっては、規格で規定されていない部分は独自に実装する必要がある。本発明では、ＡＯＤＶやＤＳＲ等の標準的なプロトコル（以下「ベースプロトコル」と称す）を基礎として、本発明に係る機能をベースプロトコルで規定されていない部分に付加することによって、所望の効果を得るものである。
【００２８】
＜本発明に係るルーティング機能＞
図３〜５は、本実施の形態に係るルーティング機能を説明するための図である。以下、図１〜５を参照しつつ、エンドデバイス５１とゲートウェイ５８との間のルーティングについて説明する。図１，３を参照して、データ通信が必要になった場合、エンドデバイス５１は、ベースプロトコルの機能に基づき、ルートディスカバリ・パケットを作成する。その後、本発明に係る機能に基づき、記憶部５１ｍに記憶されている自己のデバイスＩＤ＝１００をルートディスカバリ・パケットに付加して、ルートディスカバリ・パケット６２として送信する。図３に示したルートディスカバリ・パケット６２のうちの「ＸＸＸ」の部分は、ベースプロトコルが使用する内容である。
【００２９】
エンドデバイス５１が自己のデバイスＩＤをルートディスカバリ・パケットに付加することにより、ルートディスカバリ・パケット６２を受信した他のノードは、ルートディスカバリ・パケット６２の送信元がエンドデバイス５１であることを認識することができる。エンドデバイス５１によってルートディスカバリ・パケットに付加されたデバイスＩＤ＝１００は、後にゲートウェイ５８で行われる計画ルートの判定の際に参照されることとなる。
【００３０】
図１を参照して、ルートディスカバリ・パケット６２は、ルータ５２，５６によって受信される。図１，３を参照して、ルータ５２は、本発明に係る機能に基づき、記憶部５２ｍに記憶されている自己のデバイスＩＤ＝１０を、受信したルートディスカバリ・パケット６２に付加して、ルートディスカバリ・パケット６３として送信する。ルータ５６についても同様である。
【００３１】
ルータ５２が自己のデバイスＩＤをルートディスカバリ・パケット６２に付加することにより、ルートディスカバリ・パケット６３を受信した他のノードは、ルートディスカバリ・パケット６３がエンドデバイス５１からルータ５２を経由して送られてきたことを認識することができる。ルータ５２によってルートディスカバリ・パケット６２に付加されたデバイスＩＤ＝１０は、後にゲートウェイ５８で行われる計画ルートの判定の際に参照されることとなる。
【００３２】
図１を参照して、ルートディスカバリ・パケット６３は、ルータ５３，５７によって受信される。図１，３を参照して、ルータ５３は、本発明に係る機能に基づき、記憶部５３ｍに記憶されている自己のデバイスＩＤ＝１１を、受信したルートディスカバリ・パケット６３に付加して、ルートディスカバリ・パケット６４として送信する。ルータ５７についても同様である。
【００３３】
ルータ５３が自己のデバイスＩＤをルートディスカバリ・パケット６３に付加することにより、ルートディスカバリ・パケット６４を受信した他のノードは、ルートディスカバリ・パケット６４がエンドデバイス５１からルータ５２，５３を経由して送られてきたことを認識することができる。ルータ５３によってルートディスカバリ・パケット６３に付加されたデバイスＩＤ＝１０は、後にゲートウェイ５８で行われる計画ルートの判定の際に参照されることとなる。
【００３４】
図１を参照して、ルートディスカバリ・パケット６４は、ゲートウェイ５８によって受信される。図１，４を参照して、ゲートウェイ５８は、ルートディスカバリ・パケット６４のほかに、エンドデバイス５１からルータ５２，５７をこの順に介して送られてきたルートディスカバリ・パケット６５、エンドデバイス５１からルータ５６，５３をこの順に介して送られてきたルートディスカバリ・パケット６６、及びエンドデバイス５１からルータ５６，５７をこの順に介して送られてきたルートディスカバリ・パケット６７を受信する。つまり、本実施の形態の例では、４つのルートディスカバリ・パケット６４〜６７によって規定される４つのルート候補が存在する。
【００３５】
図２，４を参照して、次に、ゲートウェイ５８は、本発明に係る機能に基づき、受信したルートディスカバリ・パケット６４〜６７と、エンドデバイス５１に関する計画ルート情報６１（項目６１ａ）とを比較し、４つのルート候補の中から計画ルートを優先してデータ送信ルートとして選択する。具体的に、ゲートウェイ５８は、ルートディスカバリ・パケット６４〜６７に記述されているデバイスＩＤの組合せの中に、項目６１ａで指定されているデバイスＩＤの組合せ（但し、ゲートウェイ５８のデバイスＩＤ＝０を除く）に一致するものが存在するか否かを判定する。
【００３６】
正しくシステム設計がされており、計画ルートを構成するルータに故障や電池切れ等が発生していない場合には、ルートディスカバリ・パケットによって規定されるルート候補の中に、計画ルートが含まれているはずである。本実施の形態の例では、ルートディスカバリ・パケット６４に記述されているデバイスＩＤの組合せ（１００，１０，１１）が、項目６１ａで指定されているデバイスＩＤの組合せ（１００，１０，１１）に一致している。この場合、ゲートウェイ５８は、エンドデバイス５１に関する計画ルートを、データ送信ルートして選択する。これにより、ルートディスカバリ・パケット６５〜６７によって規定される他のルート候補よりも優先的に、計画ルートがデータ送信ルートとして選択されることになる。データ送信ルートの選択が、エンドデバイス５１ではなくゲートウェイ５８によって行われるため、電池駆動であるエンドデバイス５１の負荷を軽減でき、電力消費を抑制することができる。残りの３つのルート候補に対応するルートディスカバリ・パケット６５〜６７に対しては、ゲートウェイ５８は何らの処理も行わない。
【００３７】
一方、計画ルートを構成するルータに故障や電池切れ等が発生している場合や、遮蔽物によって電波障害が生じている場合には、ルートディスカバリ・パケットによって規定されるルート候補の中に、計画ルートが含まれていないはずである。従って、ルートディスカバリ・パケット６４〜６７に記述されているデバイスＩＤの組合せの中に、項目６１ａで指定されているデバイスＩＤの組合せ（但し、ゲートウェイ５８のデバイスＩＤ＝０を除く）に一致するものが存在しないこととなる。この場合、ゲートウェイ５８は、ベースプロトコルに基づきルーティングを続行する。例えば上記の通り、ゲートウェイ５８は返信パケットを送出し、エンドデバイス５１は、ゲートウェイ５８からルータ５２，５３，５６，５７を介して送られてきた複数の返信パケットによって規定される複数のルート候補の中で例えばホップ数が最も少ないルートを、データ送信ルートとして選択する。このように、計画ルートが通信不能の状態に陥っている場合には、ベースプロトコルの機能に基づいて計画ルートとは異なるルートがデータ送信ルートとして選択されるため、エンドデバイス５１とゲートウェイ５８との間で通信可能な状態は保たれる。
【００３８】
計画ルートがデータ送信ルートとして選択された場合の処理について、続けて説明する。図５を参照して、ゲートウェイ５８は、ベースプロトコルの機能に基づき、返信パケットを作成する。その後、本発明に係る機能に基づき、エンドデバイス５１に関する計画ルートを構成するデバイスＩＤの組合せ（１００，１０，１１，０）と、計画ルートが選択されたことを示す情報（ＯＰＴ）とを、返信パケットに付加して、返信パケット６８として送信する。返信パケット６８のうちの「ＹＹＹ」の部分は、ベースプロトコルが使用する内容である。
【００３９】
返信パケット６８は、計画ルートのみを逆にたどってエンドデバイス５１まで送られる。返信パケット６８には計画ルートを構成するデバイスＩＤの組合せ（１００，１０，１１，０）が記述されているため、各ルータはこれを参照することにより、返信パケット６８の次の送信先を特定する。例えば、ルータ５３は、受信した返信パケット６８に記述されているデバイスＩＤの組合せ（１００，１０，１１，０）を参照し、自己のデバイスＩＤ＝１１の前に記述されているデバイスＩＤが「１０」であることに基づいて、デバイスＩＤが「１０」であるルータ５２のみに返信パケット６８を送信する。このようにして、返信パケット６８は、ゲートウェイ５８からルータ５３，５２をこの順に介して、エンドデバイス５１に送られる。
【００４０】
計画ルートのみを逆にたどって返信パケット６８が送信されるため、計画ルートを構成しないルータ５６，５７は、返信パケット６８の送信処理には関与しない。従って、ルータ５６，５７の負荷を軽減できるため、電池駆動であるルータ５６，５７の電力消費を抑制することができる。
【００４１】
返信パケット６８を受信したエンドデバイス５１は、返信パケット６８に「ＯＰＴ」が含まれていることにより、返信パケット６８に記述されているルートが計画ルートであることを識別する。そして、エンドデバイス５１は、計画ルートをデータ送信ルートとして決定し、計画ルートを介してゲートウェイ５８にデータを送信する。
【００４２】
なお、過去のルート履歴を保存可能なキャッシュメモリをエンドデバイスに持たせ、データ送信ルートとしての計画ルートを、このキャッシュメモリに保存しておく構成としてもよい。この場合、次回以降はルートディスカバリを行うことなく、キャッシュメモリから読み出した計画ルートを介して、ゲートウェイと通信することが可能となる。
【００４３】
以下、上記の説明と一部重複するが、本実施の形態に係るアドホックネットワークシステムにおける処理を、各ノードごとに分けて説明する。
【００４４】
＜エンドデバイス５１，５５の処理＞
図６は、エンドデバイスにおける処理の流れを示すフローチャートである。まずステップＳＰ１０１においてエンドデバイスは、ルートディスカバリ・パケットを作成する。次にステップＳＰ１０２において、自己のデバイスＩＤをルートディスカバリ・パケットに付加して、図３に示したルートディスカバリ・パケット６２を作成する。次にステップＳＰ１０３において、ルートディスカバリ・パケット６２を送信する。
【００４５】
その後しばらく待ち、次にステップＳＰ１０４において、ゲートウェイ５８から送られてきた返信パケットを受信する。次にステップＳＰ１０５において、返信パケットの内容を確認し、返信パケットによって規定されるルートが計画ルートであるか否かを判定する。具体的には、返信パケットに「ＯＰＴ」が含まれている場合には、そのルートは計画ルートであると判定し、一方、「ＯＰＴ」が含まれていない場合には、そのルートは計画ルートではないと判定する。
【００４６】
返信パケットによって規定されるルートが計画ルートである場合、つまりステップＳＰ１０５における判定の結果が「ＹＥＳ」である場合は、次にステップＳＰ１０６において、計画ルートをデータ送信ルートとして決定する。
【００４７】
一方、そのルートが計画ルートではない場合、つまりステップＳＰ１０５における判定の結果が「ＮＯ」である場合は、次にステップＳＰ１０７において、予め定められた一定時間が経過したか否かを判定する。つまり、タイムアウトか否かの判定を行う。
【００４８】
タイムアウトではない場合、つまりステップＳＰ１０７における判定の結果が「ＮＯ」である場合は、次にステップＳＰ１０８において、他の返信パケットを受信する。タイムアウトであると判定されるまでの間、エンドデバイスは返信パケットの受信を行う。
【００４９】
タイムアウトである場合、つまりステップＳＰ１０７における判定の結果が「ＹＥＳ」である場合は、次にステップＳＰ１０９において、ベースプロトコルの機能に基づき、それまでに受信した複数の返信パケットに基づいてデータ送信ルートを選択する。例えば上記の通り、それまでに受信した複数の返信パケットによって規定される複数のルート候補の中でホップ数が最も少ないルートを、データ送信ルートとして選択する。
【００５０】
＜ルータ５２，５３，５６，５７の処理＞
図７は、ルータにおける処理の流れを示すフローチャートである。まずステップＳＰ２０１においてルータは、前段のルータ又はエンドデバイスから、ルートディスカバリ・パケットを受信する。次にステップＳＰ２０２において、受信したルートディスカバリ・パケットに自己のデバイスＩＤを付加する。次にステップＳＰ２０３において、デバイスＩＤを付加したルートディスカバリ・パケットを、次段のルータ又はゲートウェイ５８に送信する。
【００５１】
その後しばらく待ち、次にステップＳＰ２０４において、ゲートウェイ５８から送られてきた返信パケットを受信する。次にステップＳＰ２０５において、受信した返信パケットを、次段のルータ又はエンドデバイスに送信する。ステップＳＰ２０４で受信した返信パケットが図５に示した返信パケット６８である場合には、返信パケット６８に記述されているデバイスＩＤに基づいて、返信パケット６８の次の送信先を特定する。
【００５２】
なお、計画ルートがデータ送信ルートとして選択される場合には、計画ルートに属さないルータは返信パケットの送信処理に関与しないため、ステップＳＰ２０４，ＳＰ２０５を実行しない。
【００５３】
＜ゲートウェイ５８の処理＞
図８は、ゲートウェイにおける処理の流れを示すフローチャートである。まずステップＳＰ３０１においてゲートウェイは、エンドデバイス及びルータの各デバイスＩＤが付加されたルートディスカバリ・パケットを受信する。次にステップＳＰ３０２において、受信したルートディスカバリ・パケットと、図２に示した計画ルート情報６１とを比較することにより、受信したルートディスカバリ・パケットによって規定されるルートが、計画ルートであるか否かを判定する。
【００５４】
そのルートが計画ルートである場合、つまりステップＳＰ３０２における判定の結果が「ＹＥＳ」である場合は、ステップＳＰ３０３において返信パケットを作成した後、ステップＳＰ３０４において、計画ルートを構成するデバイスＩＤの組合せと、計画ルートを採用したことを示す情報（図５に示したＯＰＴ）とを、返信パケットに付加する。次にステップＳＰ３０５において、これらの情報が付加された返信パケットを送信する。
【００５５】
一方、ステップＳＰ３０１で受信したルートディスカバリ・パケットによって規定されるルートが計画ルートではない場合、つまりステップＳＰ３０２における判定の結果が「ＮＯ」である場合は、次にステップＳＰ３０６において、予め定められた一定時間が経過したか否かを判定する。つまり、タイムアウトか否かの判定を行う。
【００５６】
タイムアウトではない場合、つまりステップＳＰ３０６における判定の結果が「ＮＯ」である場合は、ステップＳＰ３０１において、他のルートディスカバリ・パケットを受信する。その後ステップＳＰ３０２において、受信した他のルートディスカバリ・パケットによって規定されるルートが、計画ルートであるか否かを判定する。計画ルートである又はタイムアウトであると判定されるまでの間、ゲートウェイはルートディスカバリ・パケットの受信を行う。
【００５７】
タイムアウトである場合、つまりステップＳＰ３０６における判定の結果が「ＹＥＳ」である場合は、次にステップＳＰ３０７において、ベースプロトコルの機能に基づき、受信した全てのルートディスカバリ・パケットに対する返信パケットを生成する。次にステップＳＰ３０５において、生成した返信パケットを送信する。
【００５８】
本実施の形態に係るアドホックネットワークシステムによると、計画ルートを構成するルータに故障や電池切れ等が発生していたり、電波障害が生じている等の特別の場合を除いて、計画ルートがデータ送信ルートとして選択される。計画ルートは、アプリケーションの要請を反映したノード配置計画に基づいて予め設定された理想ルートである。従って、計画ルートを優先的にデータ送信ルートとして選択することにより、ルータの電池消費量の平準化等のアプリケーションの要請を満足することができる。
【図面の簡単な説明】
【００５９】
【図１】本発明の実施の形態に係るアドホックネットワークシステムの一例を示す図である。
【図２】計画ルート情報を示す図である。
【図３】本発明の実施の形態に係るルーティング機能を説明するための図である。
【図４】本発明の実施の形態に係るルーティング機能を説明するための図である。
【図５】本発明の実施の形態に係るルーティング機能を説明するための図である。
【図６】エンドデバイスにおける処理の流れを示すフローチャートである。
【図７】ルータにおける処理の流れを示すフローチャートである。
【図８】ゲートウェイにおける処理の流れを示すフローチャートである。
【符号の説明】
【００６０】
５１，５５  エンドデバイス、５２，５３，５６，５７  ルータ、５８  ゲートウェイ、５１ｍ，５２ｍ，５３ｍ，５５ｍ，５６ｍ，５７ｍ，５８ｍ  記憶部、６１  計画ルート情報、６２〜６７  ルートディスカバリ・パケット、６８  返信パケット。
【図１】
2006197288.tif 000003
【図２】
2006197288.tif 000004
【図３】
2006197288.tif 000005
【図４】
2006197288.tif 000006
【図５】
2006197288.tif 000007
【図６】
2006197288.tif 000008
【図７】
2006197288.tif 000009
【図８】
2006197288.tif 000010