JP4561585B2 - 無線通信装置及び無線通信方法、並びにコンピュータ・プログラム - Google Patents

Description

本発明は、複数の無線局間で相互に通信を行なう無線通信装置及び無線通信方法、並びにコンピュータ・プログラムに係り、特に、制御局となる装置を特に配置せずにアドホック（Ａｄ−ｈｏｃ）通信により無線ネットワークが構築される無線通信装置及び無線通信方法、並びにコンピュータ・プログラムに関する。

さらに詳しくは、本発明は、アドホック・ネットワーク（メッシュ・ネットワーク、若しくはマルチホップ・ネットワーク）においてオンデマンド方式のルーティング・プロトコルによりパケット転送制御を行なう無線通信装置及び無線通信方法、並びにコンピュータ・プログラムに係り、特に、オンデマンド方式のルーティング・プロトコルを用いた経路検索中におけるパケット転送制御を柔軟に行なう無線通信装置及び無線通信方法、並びにコンピュータ・プログラムに関する。

有線方式による機器間のケーブル配線からユーザを解放する通信システムとして、無線ネットワークが注目されている。無線ネットワークによれば、オフィスなどの作業空間で、通信端末を比較的容易に移動させることができる。

無線ネットワークを構築する際、エリア内に「アクセス・ポイント」又は「コーディネータ」と呼ばれる制御局装置を１台設けて、この制御局の統括的な制御下でネットワークを形成する方法が一般的であるが、送信側と受信側の通信装置間で非同期通信を行なう場合には、必ずアクセス・ポイントを介した無線通信が必要になるため、伝送路の利用効率が半減してしまう。

これに対し、無線ネットワークを構成する他の方法として、特定のアクセス・ポイントを利用せずに、端末同士が自律分散して相互に接続して無線通信を行なう「アドホック（Ａｄ−ｈｏｃ）通信」が考案されている。最近では、電子機器の小型化や高性能化が進み、簡単に持ち運び利用することが可能となったことから、必要になったその場で端末同士を接続して通信を可能とする環境が求められており、アドホック通信が適当であると思料される。

また、無線ネットワークでは、通信相手となる端末局が互いの電波が届く範囲に収容されているとは限らず、マルチホップ通信により多数の端末を相互に接続することが行なわれる。ところが、アドホック・ネットワークは、従来の固定的なネットワークとは異なり、トポロジの変化が頻繁に起こることから、経路制御方式すなわちルーティング・プロトコルを確立する必要がある。

現在提案されているアドホック・ネットワークのルーティング・プロトコルは、オンデマンド方式とテーブル駆動方式という２つのカテゴリに大別される。また、これらを統合したハイブリッド方式も提案されている。

テーブル駆動方式及びハイブリッド方式は、常時経路情報を端末同士で交換して最新のルーティング・テーブルを管理する方式であり、比較的障害には強いものの、経路情報を送受信することによるオーバーヘッドの大きさが問題である。例えば、バッテリ駆動のモバイル機器がアドホック・ネットワークに接続されている場合、経路情報を常時送受信する処理は電力の浪費となり好ましくない。また、電力消費を抑えるために経路テーブルを更新する周期を長くすると、突然の傷害に対処できず、同方式としての意味がなくなる。

一方、オンデマンド方式は、通信する直前に経路発見要求を送信して経路を作成する方式である。オンデマンド方式のルーティング・プロトコルはＩＥＴＦ（Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ）のＭＡＮＥＴ（Ｍｏｂｉｌｅ Ａｄｈｏｃ ＮＥｔｗｏｒｋ Ｗｏｒｋｉｎｇ Ｇｒｏｕｐ）などから提案されており、代表的なものとしてＡＯＤＶ（Ａｄｈｏｃ Ｏｎ−ｄｅｍａｎｄ Ｄｉｓｔａｎｃｅ Ｖｅｃｔｏｒ）、ＤＳＲ（Ｄｙｎａｍｉｃ Ｓｏｕｒｃｅ Ｒｏｕｔｉｎｇ）、ＴＯＲＡ（Ｔｅｍｐｏｒａｌｌｙ Ｏｒｄｅｒｄ Ｒｏｕｔｉｎｇ Ａｌｇｏｒｉｔｈｍ）などが挙げられる（例えば、非特許文献１を参照のこと）。但し、いずれの方式も本質的な相違はなく、データ・パケット送信要求（経路作成要求）があったときに経路を作り始め、経路ができると通信を開始する（すなわち、データ・パケットの送信を始める）という手順である。

周知のように、通信制御は複数レイヤのプロトコル・スタックで構成されている。上述した経路制御は、従来はＩＰ層などのネットワーク層のみで実装されていた。ネットワーク層は、プロトコル・スタックの第３層（Ｌ３）に相当し、オペレーティング・システムに組み込まれることが多く、このため改変が容易でない。

これに対し、最近では、ネットワーク・システムの複雑化により、さまざまなレイヤでのルーティング・プロトコルの実装が試みられている。例えば、下位すなわち第２層（Ｌ２）のデータリンク層で経路制御を行なう技術が検討され始めている。この場合、ハードウェアで経路制御を行なうことにより処理が高速化することや、上位層に非依存で、オペレーティング・システムの変更なしに実装することができることなどの利点がある。

しかしながら、比較的システム・リソースに余裕があるネットワーク層とは異なり、下位層では厳しいリソースの制約の基でプロトコルを実装されることが多く、十分な領域のバッファを持てない、あるいはバッファそのものを持つことが困難な場合があるため、上位層と同様の方法で経路制御を実装できないことがある。

アドホック・ネットワークの経路制御方式のうちオンデマンド方式は、データ・パケットの送信要求が発生した時点で経路を作成するため、テーブル駆動方式に比べて経路の管理コストが少ない、実装が容易であるという利点がある。しかしながら、宛先までの経路が存在しないデータ・パケットを送信しようとした場合、パケットをバッファリングして経路の発見を待つ必要がある。このとき、経路の発見までに時間がかかってしまうと、バッファの量が足りなくなってしまうので、できるだけ多くのバッファを用意しておく必要がある。バッファが足りなくなると、重要なパケットでも単純に廃棄されてしまうという問題がある。

従来のように上位層（Ｌ３）すなわちネットワーク層で経路制御を行なう場合には、通常はパーソナル・コンピュータなど通信インターフェースを搭載するホスト機器側で実装される。このような場合、カーネルのメモリ領域をバッファとして使用することができる。このため、個々のパケットから見ると十分な領域を簡単に確保し、経路検索中にパケットをバッファにキューイングすることができるので（例えば、非特許文献２を参照のこと）、バッファ不足やパケットの廃棄という問題は生じにくい。

これに対し、ラベリングによる経路制御のように、下位層（Ｌ２）すなわちデータリンク層で経路制御を行なう場合には、ホスト機器ではなくネットワーク・インターフェース・カード（ＮＩＣ）などのハードウェアで実装される。このため、カード上にメモリ・リソースが十分に存在しないことが多く、一時的にパケットを貯めておくバッファさえ確保できないことがあることから、経路探索中にバッファ不足やパケットの廃棄が生じ易い。

Ｃｈａｒｌｅｓ，Ｅ．Ｐｅｒｋｉｎｓ外著"Ａｄ ｈｏｃ Ｏｎ−ｄｅｍａｎｄ Ｄｉｓｔａｎｃｅ Ｖｅｃｔｏｒ Ｒｏｕｔｉｎｇ"（ＩＥＴＦ Ｆｅｂ．１７，２００３ ｐ．２３−２５）＜ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｉｎｔｅｒｎｅｔ−ｄｒａｆｔｓ／ｄｒａｆｔ−ｉｅｔｆ−ｍａｎｅｔ−ａｏｄｖ−１３．ｔｘｔ＞ Ｖｉｋａｓ Ｋａｗａｄｉａ外著"Ｓｙｓｔｅｍ Ｓｅｒｖｉｃｅｓ ｆｏｒ Ａｄ−Ｈｏｃ Ｒｏｕｔｉｎｇ： Ａｒｃｈｉｔｅｃｔｕｒｅ,Ｉｍｐｌｅｍｅｎｔａｔｉｏｎ ａｎｄ Ｅｘｐｅｒｉｅｎｃｅｓ"（ＭｏｂｉＳｙｓ ２００３： Ｔｈｅ Ｆｉｒｓｔ ＩｎｔｅｒｎａｔｉｏｎａｌＣｏｎｆｅｒｅｎｃｅ ｏｎ Ｍｏｂｉｌｅ Ｓｙｓｔｅｍｓ，Ａｐｐｌｉｃａｔｉｏｎｓ，ａｎｄ Ｓｅｒｖｉｃｅｓ）

本発明の目的は、アドホック・ネットワーク（メッシュ・ネットワーク、若しくはマルチホップ・ネットワーク）においてオンデマンド方式のルーティング・プロトコルによりパケット転送制御を好適に行なうことができる、優れた無線通信装置及び無線通信方法、並びにコンピュータ・プログラムを提供することにある。

本発明のさらなる目的は、オンデマンド方式のルーティング・プロトコルを用いた経路検索中におけるパケット転送制御を柔軟に行なうことができる、優れた無線通信装置及び無線通信方法、並びにコンピュータ・プログラムを提供することにある。

本発明のさらなる目的は、オンデマンド方式のルーティング・プロトコルを通信プロトコルの下位層（Ｌ２）にて好適に実装することができる、優れた無線通信装置及び無線通信方法、並びにコンピュータ・プログラムを提供することにある。

本発明のさらなる目的は、オンデマンド方式のルーティング・プロトコルを通信プロトコルの下位層（Ｌ２）で実装した際に、経路検索中におけるパケット転送制御を柔軟に行なうことができる、優れた無線通信装置及び無線通信方法、並びにコンピュータ・プログラムを提供することにある。

本発明は、上記課題を参酌してなされたものであり、その第１の側面は、マルチホップ通信環境下でパケット伝送を行なう無線通信装置であって、
送信パケットを生成するパケット生成手段と、
送信パケットの宛先までの経路を探索する経路探索手段と、
前記経路探索手段により発見された送信パケットの宛先までの経路を記述する経路テーブルと、
前記経路探索手段による経路探索中における送信パケットの処理方法を宛先毎に設定するパケット処理方法設定手段と、
前記パケット処理方法設定手段により宛先に対して設定された処理方法に従って送信パケットの転送制御を行なうパケット転送制御手段と、
を具備することを特徴とする無線通信装置である。

本発明は、アドホック・ネットワークにおけるルーティング・プロトコルの実装方法に関するものであり、より具体的には、アドホック・ネットワークにおけるオンデマンド方式のルーティング・プロトコルを下位層Ｌ２で実装することを想定している。

下位層でルーティング・プロトコルを実装することにより、ハードウェアで経路制御を行なうことにより処理が高速化することや、上位層に非依存で、オペレーティング・システムの変更なしに実装することができることなどの利点がある。しかしながら、下位層は資源が限られたハードウェアで実装されることが多く、十分な領域のバッファを持てないという問題がある。

オンデマンド方式のルーティング・プロトコルでは、宛先までの経路が存在しないデータ・パケットを送信しようとした場合、経路の発見までに時間がかかってしまうと、パケットをバッファリングして経路の発見を待つ必要がある。このとき、バッファが足りなくなると、重要なパケットでも単純に廃棄されてしまう。

ここで、データ送信要求元であるアプリケーションが生成するデータ・パケットの中には、再送の仕組みを持たないため宛先まで確実に届ける必要があるパケットもあれば、上位層で再送の仕組みを持つためエラーで届かなくても影響のないパケットもある。したがって、経路探索中のバッファ不足によりパケットを廃棄しても、必ず問題になるとは限らない。本発明者らは、経路発見までに送信を待機しなければならないときに、データ・パケットを送り込む上位層アプリケーション自体がパケットの処理方法を柔軟に設定できることが重要である、と思料する。

そこで、本発明に係る無線通信装置では、オンデマンド型のルーティング・プロトコルを用いた経路検索において、データ・パケットの処理方法（保持、一部保持、または廃棄など）を上位層から設定することで、不必要なバッファをシステムに持たせることなく、パケットの転送制御を実現するようにした。本発明に係る経路制御は、従来のオンデマンド方式のルーティング・プロトコルに改良を加えることにより実現することができる。

前記パケット生成手段は、送信パケット自身に経路探索中における送信パケットの処理方法を設定し、前記パケット処理方法設定手段は、前記パケット生成手段からの指示に従って、経路探索中における送信パケットの処理方法を設定する。すなわち、上位層アプリケーションとしてのパケット生成手段は、経路検索中のデータ・パケットの処理方法を、経路テーブル若しくはデータ・パケット自身に設定することで、上位層から柔軟にパケットの転送機構を制御することができるようになる。

前記パケット処理方法設定手段は、前記経路テーブルの対応する宛先のエントリに送信パケットの処理方法を記述する。データ・パケット自身に設定された処理方法は、経路検索前に経路テーブルの対応するエントリに記述しておく。

そして、前記経路探索手段は、ある宛先に対する経路の探索を開始する際に、前記経路テーブルの対応するエントリに探索中フラグを設定し、前記パケット転送制御手段は、探索中フラグが設定されている宛先に向けた送信パケットに対しては該宛先のエントリに記述されたパケットの処理方法を実施する。すなわち、ある宛先に対する経路の検索に入る際に、経路テーブルの該当する宛先のエントリにフラグを設定し、以降はフラグが立っている宛先に向けて送信されるデータ・パケットに対しては該当テーブル・エントリに記述されている処理を適用する。

また、前記経路探索手段は、経路発見後は、経路テーブル中の該当するエントリの探索中フラグを解除する。すなわち、経路を発見した後は、該当するエントリのフラグを解除し、通常のパケット送信処理に戻す。

前記パケット処理方法設定手段は、経路探索中における送信パケットを廃棄するように設定することができる。上位層で再送の仕組みを持つためエラーで届かなくても影響のない場合には、このように送信パケットの廃棄を設定することができる。

あるいは、再送の仕組みを持たないため宛先まで確実に届ける必要があるパケットなどであれば、前記パケット処理方法設定手段は、上位層としてのパケット生成手段からの指示などに応じて、経路探索中における送信パケットをバッファにキューイングするように設定するようにしてもよい。

このように本発明の第１の側面によれば、経路検索中のデータ・パケットの処理方法を上位層から柔軟に設定できるようになり、必要であれば宛先が経路検索中であるすべてのパケットを破棄することも可能である。

また、本発明の第２の側面は、パケット伝送を行なう無線通信装置であって、
送信パケットを生成するパケット生成手段と、
パケット伝送に伴って、送信パケットの宛先に対してオンデマンドで所定の処理を実行するオンデマンド処理手段と、
前記オンデマンド処理手段によるオンデマンド処理中における送信パケットの処理方法を宛先毎に設定するパケット処理方法設定手段と、
前記パケット処理方法設定手段により宛先に対して設定された処理方法に従ってパケットの転送制御を行なうパケット転送制御手段と、
を具備することを特徴とする無線通信装置である。

本発明は、経路設定以外にもオンデマンド方式により所定の処理が起動するプロトコルに対して適用することが可能である。例えば、セキュアな通信のための暗号鍵の設定は同様にオンデマンド型の手順で行なわれており、鍵設定のための処理が起動中に本発明を適用することができる。例えば、鍵設定処理時のパケットの処理方法として廃棄と指定しておくことにより、本発明の第１の側面と同様に、同じ宛先に対して暗号鍵の設定する際にパケットを廃棄してバッファリングを不要にすることができる。また逆に、再送の仕組みを持たないため宛先まで確実に届ける必要があるパケットの場合には、鍵設定が完了して送信可能となるまではバッファリングをするなど、上位アプリケーションがパケットの処理方法を柔軟に設定することができる。

また、本発明の第３の側面は、マルチホップ通信環境下で経路テーブルに従ってパケット伝送を行なうための処理をコンピュータ・システム上で実行するようにコンピュータ可読形式で記述されたコンピュータ・プログラムであって、前記コンピュータ・システムに対し、
送信パケットを生成するパケット生成手順と、
送信パケットの宛先までの経路を探索し、発見された経路を前記経路テーブルに記述する経路探索手順と、
送信パケットの宛先までの経路を探索中であるかに応じてパケットの転送制御を行なうパケット転送制御手順と、
を実行させることを特徴とするコンピュータ・プログラムである。

また、本発明の第４の側面は、パケット伝送を行なうための処理をコンピュータ・システム上で実行するようにコンピュータ可読形式で記述されたコンピュータ・プログラムであって、前記コンピュータ・システムに対し、
送信パケットを生成するパケット生成手順と、
パケット伝送に伴って、送信パケットの宛先に対してオンデマンドで所定の処理を実行するオンデマンド処理手順と、
送信パケットの宛先とオンデマンド処理中であるかに応じてパケットの転送制御を行なうパケット転送制御手順と、
を実行させることを特徴とするコンピュータ・プログラムである。

本発明の第３乃至第４の各側面に係るコンピュータ・プログラムは、コンピュータ・システム上で所定の処理を実現するようにコンピュータ可読形式で記述されたコンピュータ・プログラムを定義したものである。換言すれば、本発明の第３乃至第４の各側面に係るコンピュータ・プログラムをコンピュータ・システムにインストールすることによって、コンピュータ・システム上では協働的作用が発揮され、本発明の第１乃至第２の各側面に係る無線通信装置のそれぞれと同様の作用効果を得ることができる。

本発明によれば、アドホック・ネットワーク（メッシュ・ネットワーク、若しくはマルチホップ・ネットワーク）においてオンデマンド方式のルーティング・プロトコルによりパケット転送制御を好適に行なうことができる、優れた無線通信装置及び無線通信方法、並びにコンピュータ・プログラムを提供することができる。

また、本発明によれば、オンデマンド方式のルーティング・プロトコルを用いた経路検索中におけるパケット転送制御を柔軟に行なうことができる、優れた無線通信装置及び無線通信方法、並びにコンピュータ・プログラムを提供することができる。

本発明によれば、システムの構成やプロトコルの種類に依存せずに、アドホック・ネットワークの経路制御プロトコルを実装することが可能になる。即時性を求めるオンデマンド型の経路制御プロトコルでも、メモリ・リソースの乏しいシステムに実装することができる。逆に、システム・リソースが十分に存在する場合でも適切にバッファを利用して、効率の良い経路制御プロトコルを実装することができる。システムの構成が異なる場合であっても、転送制御機構の振る舞いをパケット毎に柔軟に制御し、プロトコルの実装が可能になる。

データリンク層でアドホック・ネットワークの経路制御プロトコルを実装する場合、メモリ・リソースが十分に存在せず、一時的にパケットを貯めておくバッファさえ確保できないことがある。これに対し、本発明によれば、経路検索中の宛先不明パケットの処理方法（例えば、廃棄するか、保持するか、一部保持するか）を柔軟に上位層から指定できるので、リソースの利用状況を判断しながらパケット送信時に処理方法を判断することができる。

本発明は、経路テーブルに対するフィールド追加と、パケット送信時のアルゴリズムの変更だけで実現することができ、システムの大幅な変更は必要なく、経路制御プロトコルの種類に依存しない。

また、本発明は、経路設定以外にもオンデマンド方式により所定の処理が起動するプロトコルに対して適用することが可能である。例えば、セキュアな通信のための暗号鍵の設定は同様にオンデマンド型のプロトコルで行なわれており、鍵設定のためのオンデマンド型プロトコル動作中に本発明を適用することができる。

本発明のさらに他の目的、特徴や利点は、後述する本発明の実施形態や添付する図面に基づくより詳細な説明によって明らかになるであろう。

以下、図面を参照しながら本発明の実施形態について詳解する。

図１には、本発明を適用することができる無線アドホック・ネットワークの構成例を示している。図１（ａ）では、端末Ｓ（２０１）乃至端末Ｅ（２０６）の６つの端末が無線アドホック通信システムのネットワークを構成している。また、各端末の周囲の点線は、各端末２０１乃至２０６の通信範囲２１１乃至２１６をそれぞれ表している。

例えば、端末Ｓ（２０１）の通信範囲２１１には、端末Ａ（２０２）及び端末Ｂ（２０３）が含まれる。また、端末Ａ（２０２）の通信範囲２１２には、端末Ｓ（２０１）、端末Ｂ（２０３）及び端末Ｃ（２０４）が含まれる。また、端末Ｂ（２０３）の通信範囲２１３には、端末Ｓ（２０１）、端末Ａ（２０２）及び端末Ｅ（２０６）が含まれる。また、端末Ｃ（２０４）の通信範囲２１４には、端末Ａ（２０２）、端末Ｄ（２０５）及び端末Ｅ（２０６）が含まれる。また、端末Ｄ（２０５）の通信範囲２１５には、端末Ｃ（２０４）及び端末Ｅ（２０６）が含まれる。また、端末Ｅ（２０６）の通信範囲２１６には、端末Ｂ（２０３）、端末Ｃ（２０４）及び端末Ｄ（２０５）が含まれる。

図１（ｂ）には、このような端末間の関係を模式的に表している。同図では、互いに通信範囲２１１乃至２１６内にある端末同士のみが直線により結ばれ、直接結ばれていない端末は通信範囲外にある。このように、無線ネットワークでは、通信相手となる端末局が互いの電波が届く範囲に収容されているとは限らないので、通信範囲外の端末間で通信を行なう場合には、マルチホップ通信により多数の端末を相互に接続することが行なわれる。とりわけ、アドホック・ネットワークではトポロジの変化が頻繁に起こることから、経路制御方式すなわちルーティング・プロトコルを確立する必要がある。

図２には、図１に示した無線アドホック・ネットワークにおいて経路を設定するための手順を図解している。ある端末間で経路が設定されていない場合に、最初に経路を設定するための手順は従来技術を用いることができる。例えば、上述のＡＯＤＶプロトコルでは、発信端末から宛先端末に対して経路要求メッセージを送信し、宛先端末から発信端末に対して経路返答メッセージを送信することにより、経路を設定している。

図２（ａ）では、端末Ｓ（２０１）から端末Ｄ（２０５）に対して経路要求を行なう際のパケットの流れを示している。端末Ｓは、端末Ｄにデータを送信する際に、まだ端末Ｄへの経路が設定されていなければ、経路発見プロセスに入る。まず、端末Ｓは、経路要求メッセージ（ＲｏｕｔｅＲＥＱｕｅｓｔ ｍｅｓｓａｇｅ：ＲＲＥＱ）をブロードキャストする。この経路要求メッセージを受信した端末Ａ（２０２）及び端末Ｂ（２０３）は、その経路要求メッセージの送信元である端末Ｓへの逆向きの経路（ＲｅｖｅｒｓｅＰａｔｈ）を設定する。ここで言う逆向きの経路とは、経路要求メッセージの送信元までデータを送信したいという要求が生じた場合に、その経路要求メッセージを送信してきた近隣端末を次の転送先とする経路を意味する。

経路要求メッセージを受信した端末Ａ及び端末Ｂは、宛先が自端末でないことから、その経路要求メッセージをさらにブロードキャストする。これにより、端末Ｃ（２０４）及び端末Ｅ（２０６）に経路要求メッセージが伝わる。一方、端末Ａのブローキャストした経路要求メッセージは、端末Ｓや端末Ｂにおいても受信されるが、経路要求メッセージに付された要求識別子が一致するため、端末Ｓや端末Ｂにおいて破棄される。同様にして、端末Ｂのブローキャストした経路要求メッセージは、端末Ｓや端末Ａにおいて破棄される。このように、要求識別子は２重受け取りチェックのために使用される。

経路要求メッセージを受信した端末Ｃ及び端末Ｅは、端末Ｓへの逆向きの経路を設定した後、その経路要求メッセージをさらにブロードキャストする。これにより、端末Ｄ（２０５）に経路要求メッセージが到達する。端末Ｄは、端末Ｃ及び端末Ｅの両者から経路要求メッセージを受信するが、後から受信した経路要求メッセージを破棄する。

図２（ｂ）には、端末Ｄから端末Ｓに対して経路返答を行なう際のパケットの流れを示している。端末Ｄは、端末Ｓへの逆向きの経路を設定した後、送信元である端末Ｓに対して経路返答メッセージ（ＲｏｕｔｅＲＥＰｌｙ ｍｅｓｓａｇｅ：ＲＲＥＰ）をユニキャストで送信する。例えば、端末Ｄが端末Ｃからの経路要求メッセージに返答する場合には、端末Ｄは端末Ｃを次の送信先としてユニキャストによる送信を行なう。

経路返答メッセージを受信した端末Ｃは、経路返答メッセージの送信元である端末Ｄへの逆向きの経路を設定する。そして、端末Ｃはその経路返答メッセージを端末Ａに転送する。同様に、経路返答メッセージを受信した端末Ａは、経路返答メッセージの送信元である端末Ｄへの逆向きの経路を設定して、その経路返答メッセージを端末Ｓに転送する。

経路返答メッセージを受信した端末Ｓは、経路返答メッセージの送信元である端末Ｄへの逆向きの経路を設定する。そして、宛先である端末Ｄに対応する経路エントリに経路の設定内容を記述して、経路テーブルに登録する。これにより、経路発見プロセスは完了する。

但し、本実施形態では、オンデマンド方式の経路制御プロトコルを適用しており、上述した経路設定手順は、ある宛先に送ろうとした最初のデータ・パケットが送信される前に起動する。すなわち、経路テーブルにはない宛先に対してデータ・パケットを送信しようとしたときに経路が作成され、通常は一度経路が作成されると一定期間保持される。

オンデマンド方式の経路制御は、データ・パケットの送信要求が発生した時点で経路を作成するため、テーブル駆動方式に比べて経路の管理コストが少ない、実装が容易であるという利点がある。しかしながら、宛先までの経路が存在しないデータ・パケットを送信しようとした場合、経路の発見を待つ間に宛先不明パケットをバッファリングしなければならないという問題がある。この問題は、ハードウェア・リソースが厳しく制約される下位層（Ｌ２）すなわちデータリンク層で経路制御を行なう場合に顕著となる。

データ送信要求元であるアプリケーションが生成するデータ・パケットの中には、再送の仕組みを持たないため宛先まで確実に届ける必要があるパケットもあれば、上位層で再送の仕組みを持つためエラーで届かなくても影響のないパケットもある。したがって、経路探索中のバッファ不足によりパケットを廃棄しても、必ず問題になるとは限らない。経路発見までに送信を待機しなければならないときに、データ・パケットを送り込む上位層アプリケーション自体がパケットの処理方法を柔軟に設定できることが重要である。

そこで、本実施形態では、オンデマンドの経路探索中におけるデータ・パケットの処理方法を上位層から設定することで、不必要なバッファをシステムに持たせることなく、パケットの転送制御を実現するようにした。これは、経路探索中にバッファ不足により宛先不明のパケットを廃棄しても必ずしも問題になるとは限らないという理由に基づく。すなわち、送信パケットを生成する上位層アプリケーションは、経路検索中の宛先不明パケットの処理方法（例えば、廃棄するか、保持するか、一部保持するか）を柔軟に指定できるので、リソースの利用状況を判断しながらパケット送信時に処理方法を判断することができる。

図３には、本発明に係るルーティング・プロトコルを実現した無線通信装置の内部構成を示している。図示の無線通信装置１００は、通信処理部１１０と、制御部１２０と、表示部１３０と、操作部１４０と、主メモリ１５０を備え、これらの間をバス１８０が接続する構成となっている。

通信処理部１１０は、データリンク層以下の通信プロトコル処理を行なう。具体的には、通信処理部１１０にはアンテナ１０５が接続されており、アンテナ１０５を介して受信した信号からデータリンク層のフレームを構成するとともに、データリンク層のフレームをアンテナ１０５から送信する。

また、本実施形態では、通信処理部１１０がオンデマンド型のルーティング・プロトコルを用いた経路検索処理を行なう。このため、自端末に接続する経路に関する情報を保持する経路テーブル６１０と、他の端末に送信されるデータを保持するデータ・バッファ６２０とを含んだメモリ６００を備えている。

制御部１２０は、オペレーティング・システムが提供する実行環境下でアプリケーション・プログラムを実行して、無線通信装置１００全体を制御する。例えば、制御部１２０上で通信アプリケーションを実行して、ネットワーク層以上の通信プロトコル処理を行なう。本実施形態では、通信処理部１１０により構成されたフレームを参照して、経路探索中の宛先不明パケットの処理方法の指定や、その他の所定の処理を行なう。制御部１２０は、プログラムをロードしたり、システム状態を一時保存するために主メモリ１５０を使用する。

表示部１３０は、所定の情報を表示するデバイスであり、例えば、液晶ディスプレイなどが用いられる。また、操作部１４０は、無線端末１００に対して外部から操作指示を行なうためのデバイスであり、例えば、キーボードやボタン・スイッチなどが用いられる。

図４には、本実施形態に係る無線通信装置１００の通信処理部１１０内のメモリ６００に保持される経路テーブル６１０の構成例を示している。経路テーブル６１０には、宛先毎に経路エントリが用意される。図示の例では、１つの経路エントリには、宛先アドレスと、転送先アドレスと、宛先ホップ数と、生存時間と、探索中フラグと、探索中処理方法が保持される。経路テーブル６１０では、１つの宛先アドレスに対して、必ず転送先アドレスを１つ持つ。経路テーブル６１０に宛先アドレスが存在しない場合は、その宛先までの経路がないことを示している。

宛先アドレスには、その経路の最終的な宛先端末のアドレスが記載される。ここで言うアドレスとは、端末を一意に識別できるものであればよく、例えば、ＭＡＣ（ＭｅｄｉａＡｃｃｅｓｓ Ｃｏｎｔｒｏｌ）アドレスやＩＰ（ＩｎｔｅｒｎｅｔＰｒｏｔｏｃｏｌ）アドレスなどを用いることができる。また、転送先アドレスは、対応する宛先アドレスに到達するために次に転送すべき端末すなわちホップ先のアドレスを示す。

宛先ホップ数は、対応する宛先アドレスに到達するために必要なリンクの数のことである。例えば、図１（ｂ）に示した例では、端末Ｃから端末Ｓに到達するためには途中に端末Ａを介して、合計２つのリンクを経る必要があるので、この場合のホップ数は「２」となる。また、生存時間は、当該パケットのいわば有効期限を表すパラメータである。パケットの生存期間を制限することにより、無線ネットワーク上をパケットが徒にホッピングし続け、帯域を浪費するのを防止することができる。

探索中処理方法は、当該経路エントリに係る経路探索中における同じ宛先の端末へのデータ・パケットの処理方法のことであり、例えば、廃棄するか、保持するか、一部保持するかを指定することができる。

通信処理部１１０がオンデマンドで経路を探索している最中に、同じ宛先の端末へのデータ・パケットが上位層から送り込まれると、宛先すなわち次の転送先が不明のため経路が発見されるまでパケットを保持するためには不必要なバッファを通信処理部１１０で用意しなければならない。そこで、本実施形態では、上位層アプリケーションすなわち制御部１２０が探索中処理方法を指定することで、バッファ不足を解決するようにしている。送信パケットを生成する上位層アプリケーションは、宛先不明のパケットを廃棄すると問題になるかどうかを把握できるので、リソースの利用状況を判断しながら、経路探索中の宛先不明パケットについて廃棄する、あるいは一部だけキューイングするといった処理方法を柔軟に指定することができる。

探索中フラグは、当該経路エントリの経路を現在探索中であるかどうかを示すフラグであり、このフラグが立てることは探索中処理方法を適用すべきことの指示に相当する。

オンデマンドで経路探索を行なう通信処理部１１０は、ある宛先に対する経路の探索を開始する際に、該当する経路エントリに探索中フラグを設定し、また、経路発見後は探索中フラグを解除する。そして、上位層アプリケーションすなわち制御部１２０から送信パケットが渡されたとき、通信処理部１１０は、経路テーブル６１０を参照し、該当する経路エントリに探索中フラグが設定されているときには、探索中処理方法フィールドで指定されている処理方法を当該送信パケットに適用する。また、経路発見後は、該当エントリの探索フラグは解除されているので、通常のパケット送信処理に戻すことができる。

上位層アプリケーションは、データ・パケットを送信しようとするとき、例えばデータ・パケットの特性やユーザの要求に応じて、経路探索中のデータ・パケットの処理方法を設定することにより、上位層から柔軟にパケットの転送機構を制御することができる。また、パケット毎に処理方法を設定することが可能である。例えば、パケットを生成する上位層アプリケーションがデータ・パケットを送信する前に、データ・パケットのヘッダ部のあらかじめ確保された領域にパケットの処理方法を書き込む。この場合、通信処理部１１０は、経路検索前に経路テーブルの該当エントリに記載する。あるいは、すべてのデータ・パケットに対して同じ処理方法を指定する場合には、上位層アプリケーションは経路テーブルに直接記述するようにしてもよい。

図５には、探索中処理方法を設定するデータ・パケット（ＩＰパケット）の構成例を示している。図示のように、データ・パケットは、宛先アドレスや発信アドレス、転送先アドレス、その他の図示しない制御情報を含んだヘッダ部と、送信情報の本体を搬送するためのペイロード部で構成される。図示の例では、前者のヘッダ部内に、探索中処理方法を指定するための処理方法記述部が設けられている。通信処理部１１０は、上位層アプリケーションすなわち制御部１２０から渡された送信データ・パケットのヘッダ部を解釈して、処理方法記述部に記載されている探索中処理方法を該当する経路エントリに書き込むようにする。

下表に示すように、宛先不明パケットの処理方法を状況に応じて選択することで、経路制御プロトコルを効率的に使って、スループットなどのネットワーク・パフォーマンスを最大限にできる、といった効果を期待することができる。

経路検索中の具体的なパケット処理方法としては、例えば、以下のような方法が挙げられる。

［ａ］経路検索中であれば、すべて廃棄する。
［ｂ］経路検索中であれば、すべてキューイングする（経路が見つかったときに送信を再開する）。
［ｃ］経路検索中であれば、一定時間だけパケットをキューイングする。
［ｄ］経路検索中であれば、一定個数のパケットをキューイングする。
［ｅ］その他。

パケットを生成する上位層アプリケーションでは、これらのうちいずれかの方法をデータ・パケットのヘッダ部の処理方法記述部に記載する。そして、通信処理部１１０にパケットを渡して送信要求する。

通信処理部１１０では、データリンク層以下における通信動作を制御する。図６には、上位層アプリケーションからの送信要求が発生した際に、通信処理部１００において、パケットの宛先までの経路発見の有無に応じてデータ・パケットの送信動作を制御するための処理手順をフローチャートの形式で示している。

上位層アプリケーションからのデータ送信要求に応じて（ステップＳ１）、データ・パケットの送信処理を行なう際には、まず、パケットの宛先となる端末の情報が自身の経路テーブル６１０に既に存在しているかどうかをチェックする（ステップＳ２）。すなわち、データ・パケットの宛先アドレスをキーにして経路テーブル６１０内の経路エントリを検索する。

ここで、経路テーブル６１０を検索したが、パケットの宛先となる端末の情報がまだエントリされていない場合には（ステップＳ２のＮｏ）、通信処理部１１０はオンデマンド型の経路探索処理を起動する。具体的には、経路テーブル６１０内に当該パケットの宛先に関する経路エントリを新規作成し（ステップＳ３）、この経路エントリの探索中フラグを立てるとともに（ステップＳ４）、経路探索中に同じ宛先に対するパケット送信要求が起きたときの処理方法を探索中処理方法フィールドで指定してから（ステップＳ５）、経路探索処理を開始する（ステップＳ６）。

経路探索処理は、図２を参照しながら既に説明したように、ＡＯＤＶなど既存の経路探索プロトコルを適用することができる。通信処理部１１０は、経路が見つかるまでは、経路探索プロトコルの規定に従って経路要求メッセージを再送処理し、経路探索処理を試みる。

そして、送信要求されているパケットの宛先までの経路を発見することができたならば（ステップＳ７のＹｅｓ）、通信処理部１１０は、転送先アドレスなど経路発見した内容を該当する経路エントリに記載するとともに、探索中フラグを落として（ステップＳ８）、経路探索処理から抜ける。経路発見後は、探索フラグは解除され、通常のパケット送信処理に戻すことができるので、バッファ６２０にキューイングされているパケット（但し、キューイングされている場合）並びに以降の送信要求パケットに対し、データ送信処理を実行することができる（ステップＳ１０）。

一方、経路テーブル６１０内を検索してヒットした場合には（ステップＳ２のＹｅｓ）、続いて、ヒットした経路エントリで探索中フラグが設定されているかどうかをさらにチェックする（ステップＳ９）。

ここで、探索中フラグが設定されない場合には（ステップＳ９のＮｏ）、その宛先について経路発見が済み、該当する経路エントリには有効な転送先アドレスが記載されていることになるので、転送先アドレスをパケットの次ホップとして設定し、データ送信処理を行なう（ステップＳ１０）。

また、探索中フラグが設定されている場合には（ステップ９のＹｅｓ）、当該経路エントリの経路を現在探索中であるから、ステップＳ１１に進んで、当該経路エントリの探索中処理方法フィールドで指定されている処理方法を当該送信パケットに適用する。

パケットの基本的な処理方法は、上述した［ａ］〜［ｄ］の４パターンからなり、その他これらの組み合わせで処理を行なうこともできる。

［ａ］すべてのパケットを廃棄
探索中フラグが設定され、該当する宛先への経路探索が行なわれている間は、通信処理部１１０は、同じ宛先に送信しようとしているデータ・パケットをすべて廃棄する。経路探索に時間がかかると、廃棄されるパケットの数が単調に増えていく可能性がある。一般的に経路ができていない初期段階で送られるパケットは、通信開始前ネゴシエーションのためのパケットであることが多く、廃棄やパケットロスが生じても問題にならないこともある。また、ネゴシエーションにおいて重要なパケットの場合は、上位で再送機構を持つため、廃棄しても問題にならないこともある。バッファ６２０をまったく持たないようなシステムで経路制御を実装するためには、この処理方法が最も有効である。

［ｂ］すべてのパケットをキューイング
探索中フラグが立っていて、経路探索が行なわれている間は、同じ宛先に送信しようとしているデータ・パケットをバッファ６２０にすべてキューイングしておく。経路探索に時間がかかるとバッファ６２０にキューイングされるパケット数が単調に増えていく可能性があるが（同上）、極めて十分な容量のバッファを備えている場合や、非常に重要なパケットを送信しようとしている場合には、有効な手段となる。また、経路の発見をトリガとして、バッファ６２０にキューイングされているデータ・パケットは、先頭から順次送信が行なわれることになる。この場合、経路発見時でも探索中フラグは落とさずに、キューイングされているパケットをすべて送出した時点で探索中フラグを落とす。

［ｃ］一定時間だけパケットをキューイング
上記［ｂ］の変形例として、一定時間だけパケットをキューイングし、それ以降のパケットはすべて廃棄する。経路探索に入る時点で通信処理部１１０は、内部のタイマをセットしておき、処理方法をキューイングに設定する。そして、タイマによりタイムアウトすると、該当経路エントリ中の処理方法を廃棄に設定し直す。

［ｄ］一定個数だけパケットをキューイング
また、上記［ｂ］のさらに他の変形例として、一定個数だけパケットをキューイングし、それ以降のパケットはすべて廃棄する。経路探索に入る時点で、通信処理部１１０は内部のカウンタをセットしておき、処理方法をキューイングに設定する。カウントが閾値を超えると、処理方法を廃棄に設定し直して、カウンタをリセットする。

図７には、［ｂ］〜［ｄ］のように経路探索中のパケットをキューイングする処理方法が指定されている場合に、通信処理部１１０が経路探索中の宛先に対するデータ・パケットを処理する手順をフローチャートの形式で示している。

通信処理部１１０は、上位アプリケーションすなわち制御部１２０からのデータ・パケットの送信要求を待機しており（ステップＳ２１）、このとき、データ送信要求を受け取ると（ステップＳ２２）、まず、そのデータ・パケットの宛先に対する経路エントリを経路テーブル６１０で検索し、探索中フラグが設定されているかどうかをチェックする（ステップＳ２３）。

ここで、宛先の経路エントリで探索中フラグが設定されていなければ（ステップＳ２３のＮｏ）、データ送信処理をそのまま実行する（ステップＳ２４）。

一方、宛先の経路エントリで探索中フラグが設定されている場合には（ステップＳ２３のＹｅｓ）、キューイングを始めてからの累計パケット数を記録する（ステップＳ２５）。そして、累計パケット数が一定数を超えたかどうかをチェックする（ステップＳ２６）。

累計パケット数が一定数をまだ超えていない場合には（ステップＳ２６のＮｏ）、パケットをバッファ６１０にキューイングして（ステップＳ２７）、ステップＳ２１に戻り、上位層アプリケーションから次のデータ・パケット送信要求を待機する。

また、累計パケット数が一定数を超えてしまったときには（ステップＳ２６のＹｅｓ）、ステップＳ２２で送信要求されたパケットを廃棄する（ステップＳ２８）。

図７に示した処理手順では、上記［ｄ］に従い、一定個数までパケットをキューイングするようにしているが、勿論、このルールに代えて、あるいは組み合わせて、一定時間だけパケットをキューイングし、キューイングしてから一定時間が経過したパケットを逐次バッファ６１０から廃棄するようにしてもよい。あるいは、バッファ６１０内のキューが溢れたときにパケットを廃棄するようにしてもよい。

本実施形態に係る経路制御は、従来のオンデマンド方式のルーティング・プロトコルに改良を加えることで実現できる。オンデマンド方式のルーティング・プロトコルはＩＥＴＦのＭＡＮＥＴＷＧなどから提案されており、ＡＯＤＶ、ＤＳＲやＴＯＲＡなどが挙げられるが、いずれの方式も本質的な違いはなく、これらのいずれかのルーティング・プロトコルであっても本発明を適用するものとする。

また、本発明は、経路設定以外にもオンデマンド方式により所定の処理が起動するプロトコルに対して適用することが可能である。例えば、セキュアな通信のための暗号鍵の設定若しくは交換手順は、経路設定の場合と同様にデータ送信時にオンデマンド型のプロトコルで行なわれるのが一般的であり、鍵設定のためのオンデマンド型処理手順を起動中におけるパケット転送制御に本発明を適用することができる。

データ・パケットの送信要求が発生した通信装置は、データ送信先となる通信装置との間で暗号鍵をまだ設定していない（すなわち鍵テーブルに鍵がまだ登録されていない）場合、当該通信相手と相互認証並びに暗号鍵の設定処理が完了するまでの間はアプリケーションが生成したデータ・パケットを送信することはできない。

データ送信要求元であるアプリケーションが生成するデータ・パケットの中には、再送の仕組みを持たないため宛先まで確実に届ける必要があるパケットもあれば、上位層で再送の仕組みを持つためエラーで届かなくても影響のないパケットもある。したがって、鍵設定中のバッファ不足によりパケットを廃棄しても、必ず問題になるとは限らない。鍵設定が完了するまでの間は送信を待機しなければならないときに、データ・パケットを送り込む上位層アプリケーション自体がパケットの処理方法を柔軟に設定できることが重要である。

そこで、本実施形態では、鍵設定中の通信相手に対するデータ・パケットの処理方法を上位層から設定することで、不必要なバッファをシステムに持たせることなく、パケットの送信制御を実現するようにした。これは、鍵設定中にバッファ不足により宛先不明のパケットを廃棄しても必ずしも問題になるとは限らないという理由に基づく。すなわち、送信パケットを生成する上位層アプリケーションは、鍵設定中のパケットの処理方法（例えば、廃棄するか、保持するか、一部保持するか）を柔軟に指定できるので、リソースの利用状況を判断しながらパケット送信時に処理方法を判断することができる。

鍵設定を始めとする、パケット送信時にオンデマンドで処理を起動する無線通信装置の構成は、図３に示したものとほぼ同様なので、ここでは説明を省略する。例えば、制御部１２０が、オペレーティング・システムが提供する実行環境下で、鍵設定などのオンデマンド処理手順を規定したアプリケーション・プログラムを実行して、無線通信装置１００全体を制御することを想定する。

図８には、本実施形態に係る無線通信装置１００の例えば主メモリ１５０に保持される鍵テーブル６３０の構成例を示している。鍵テーブル６３０には、宛先毎に鍵エントリが用意される。図示の例では、１つの鍵エントリには、宛先アドレスと、暗号鍵と、設定中フラグと、設定中処理方法が保持される。鍵テーブル６３０では、１つの宛先アドレスに対して、必ず暗号鍵を１つ持つ。鍵テーブル６３０に宛先アドレスが存在しない場合は、その宛先との間でまだ暗号鍵を設定していないことを示している。

宛先アドレスは、端末を一意に識別できるものであればよく、例えば、ＭＡＣアドレスやＩＰアドレスなどを用いることができる。

暗号鍵は、対応する宛先アドレスにデータ・パケットを送信する際に、そのペイロード中のデータを暗号化処理する際に使用する暗号鍵であり、暗号方式は特に限定されない。

設定中処理方法は、当該鍵エントリに係る暗号鍵の設定処理中における同じ宛先の端末へのデータ・パケットに対する処理方法のことであり、例えば、廃棄するか、保持するか、一部保持するかを指定することができる。

通信処理部１１０がデータ・パケットの送信に先立って宛先と鍵設定処理を行なっている最中に、同じ宛先の端末へのデータ・パケットが上位層から送り込まれると、当該宛先との暗号鍵が設定されるまでパケットを保持するためには不必要なバッファを通信処理部１１０若しくは主メモリ１５０で用意しなければならない。そこで、本実施形態では、上位層アプリケーションすなわち制御部１２０が探索中処理方法を指定することで、バッファ不足を解決するようにしている。送信パケットを生成する上位層アプリケーションは、鍵設定中の通信相手に対する送信パケットを廃棄すると問題になるかどうかを把握できるので、リソースの利用状況を判断しながら、鍵設定中の宛先へのパケットについて廃棄する、あるいは一部だけキューイングするといった処理方法を柔軟に指定することができる。

設定中フラグは、当該鍵エントリの宛先端末との間で現在暗号鍵の設定処理中であるかどうかを示すフラグであり、このフラグが立てることは設定中処理方法を適用すべきことの指示に相当する。

データ・パケットの送信に先立って鍵設定処理を行なう制御部１２０（若しくは通信処理部１１０）は、ある宛先に対する暗号鍵の設定処理を開始する際に、該当する鍵エントリに設定中フラグを設定し、また、暗号鍵の設定終了後は設定中フラグを解除する。そして、上位層アプリケーションすなわち制御部１２０から送信パケットが渡されたとき、制御部１２０（若しくは通信処理部１１０）は、鍵テーブル６３０を参照し、該当する鍵エントリに設定中フラグが設定されているときには、設定中処理方法フィールドで指定されている処理方法を当該送信パケットに適用する。また、暗号鍵を設定した後は、該当エントリの設定フラグは解除されているので、通常のパケット送信処理に戻すことができる。

上位層アプリケーションは、データ・パケットを送信しようとするとき、例えばデータ・パケットの特性やユーザの要求に応じて、暗号鍵設定中のデータ・パケットの処理方法を設定することにより、上位層から柔軟にパケットの転送機構を制御することができる。また、パケット毎に処理方法を設定することが可能である。

暗号鍵設定中のパケットの処理は、制御部１２０ではなく通信制御部１１０が実施することもできる。この場合、鍵テーブル６３０は、主メモリ１５０ではなく、通信制御部１１０内のメモリ６００上に置かれる。例えば、パケットを生成する上位層アプリケーションがデータ・パケットを送信する前に、データ・パケットのヘッダ部のあらかじめ確保された領域にパケットの処理方法を書き込む。この場合、通信処理部１１０は、暗号鍵の設定前に鍵テーブルの該当エントリに記載する。あるいは、すべてのデータ・パケットに対して同じ処理方法を指定する場合には、上位層アプリケーションは鍵テーブルに直接記述するようにしてもよい。

データ・パケット（ＩＰパケット）のデータ構造については図５を参照しながら既に説明したが、ヘッダ部内の処理方法記述部には経路探索中ではなく暗号鍵設定中の処理方法を記述することも可能である。通信処理部１１０は、上位層アプリケーションすなわち制御部１２０から渡された送信データ・パケットのヘッダ部を解釈して、処理方法記述部に記載されている設定中処理方法を該当する鍵エントリに書き込むようにする。

暗号鍵が設定中となっている宛先へのパケットの処理方法を状況に応じて選択することで、使用する再送制御プロトコルなどを考慮しながら、スループットなどのネットワーク・パフォーマンスを最大限にできる、といった効果を期待することができる。暗号鍵設定中の具体的なパケット処理方法としては、例えば、以下のような方法が挙げられる。

［ａ］暗号鍵設定中であれば、すべて廃棄する。
［ｂ］暗号鍵設定中であれば、すべてキューイングする（暗号鍵が設定されたときに送信を再開する）。
［ｃ］暗号鍵設定中であれば、一定時間だけパケットをキューイングする。
［ｄ］暗号鍵設定中であれば、一定個数のパケットをキューイングする。
［ｅ］その他。

図９には、上位層アプリケーションからの送信要求が発生した際に、制御部１２０若しくは通信処理部１００において、パケットの宛先との暗号鍵の設定の有無に応じてデータ・パケットの送信動作を制御するための処理手順をフローチャートの形式で示している。但し、データ・パケットの送信時には、送信先までの経路が既に探索済みであるとする。

上位層アプリケーションからのデータ送信要求に応じて（ステップＳ３１）、データ・パケットの送信処理を行なう際には、まず、パケットの宛先となる端末の情報が自身の鍵テーブル６３０に既に存在しているかどうかをチェックする（ステップＳ３２）。すなわち、データ・パケットの宛先アドレスをキーにして鍵テーブル６１０内の鍵エントリを検索する。

ここで、鍵テーブル６３０を検索したが、パケットの宛先となる端末の情報がまだエントリされていない場合には（ステップＳ３２のＮｏ）、暗号鍵の設定処理を起動する。具体的には、鍵テーブル６３０内に当該パケットの宛先に関する鍵エントリを新規作成し（ステップＳ３３）、この鍵エントリの設定中フラグを立てるとともに（ステップＳ３４）、暗号鍵設定中に同じ宛先に対するパケット送信要求が起きたときの処理方法を設定中処理方法フィールドで指定してから（ステップＳ３５）、暗号鍵の設定処理を開始する（ステップＳ３６）。暗号鍵の設定処理は、通常、端末同士の相互認証処理を伴う。但し、本発明の要旨は、相互認証処理や暗号鍵設定処理の手順に限定されないので、ここでは詳細な説明を省略する。

そして、送信要求されているパケットの宛先と暗号鍵を設定することができたならば（ステップＳ３７のＹｅｓ）、通信処理部１１０は、設定した暗号鍵を該当する鍵エントリに記載するとともに、設定中フラグを落として（ステップＳ３８）、経路探索処理から抜ける。暗号鍵設定後は、設定中フラグは解除され、通常のパケット送信処理に戻すことができるので、バッファ６２０にキューイングされているパケット（但し、キューイングされている場合）並びに以降の送信要求パケットに対し、データ送信処理を実行することができる（ステップＳ４０）。

一方、鍵テーブル６３０内を検索してヒットした場合には（ステップＳ３２のＹｅｓ）、続いて、ヒットした鍵エントリで設定中フラグが設定されているかどうかをさらにチェックする（ステップＳ３９）。

ここで、探索中フラグが設定されない場合には（ステップＳ３９のＮｏ）、その宛先とは既に暗号鍵が設定されており、該当する鍵エントリには有効な暗号鍵が記載されていることになるので、この暗号鍵を用いて送信パケットのペイロード部を暗号化処理し、データ送信処理を行なう（ステップＳ４０）。

また、設定中フラグが設定されている場合には（ステップＳ３９のＹｅｓ）、当該鍵エントリの暗号鍵を現在設定中であるから、ステップＳ４１に進んで、当該鍵エントリの設定中処理方法フィールドで指定されている処理方法を当該送信パケットに適用する。

パケットの基本的な処理方法は、上述した［ａ］〜［ｄ］の４パターンからなり、その他これらの組み合わせで処理を行なうこともできる。

［ａ］すべてのパケットを廃棄
設定中フラグが設定され、該当する宛先との暗号鍵設定処理が行なわれている間は、制御部１２０若しくは通信処理部１１０は、同じ宛先に送信しようとしているデータ・パケットをすべて廃棄する。暗号鍵の設定に時間がかかると、廃棄されるパケットの数が単調に増えていく可能性がある。ネゴシエーションにおいて重要なパケットの場合は、上位で再送機構を持つため、廃棄しても問題にならないこともある。バッファ６２０をまったく持たないようなシステムで暗号鍵設定を実装するためには、この処理方法が最も有効である。

［ｂ］すべてのパケットをキューイング
設定中フラグが立っていて、暗号鍵設定が行なわれている間は、同じ宛先に送信しようとしているデータ・パケットをバッファ６２０にすべてキューイングしておく。暗号鍵の設定に時間がかかるとバッファ６２０にキューイングされるパケット数が単調に増えていく可能性があるが（同上）、極めて十分な容量のバッファを備えている場合や、非常に重要なパケットを送信しようとしている場合には、有効な手段となる。また、暗号鍵の設定完了をトリガとして、バッファ６２０にキューイングされているデータ・パケットは、先頭から順次送信が行なわれることになる。この場合、暗号鍵設定時でも設定中フラグは落とさずに、キューイングされているパケットをすべて送出した時点で設定中フラグを落とす。

［ｃ］一定時間だけパケットをキューイング
上記［ｂ］の変形例として、一定時間だけパケットをキューイングし、それ以降のパケットはすべて廃棄する。暗号鍵の設定処理に入る時点で制御部１２０若しくは通信処理部１１０は、内部のタイマをセットしておき、処理方法をキューイングに設定する。そして、タイマによりタイムアウトすると、該当鍵エントリ中の処理方法を廃棄に設定し直す。

［ｄ］一定個数だけパケットをキューイング
また、上記［ｂ］のさらに他の変形例として、一定個数だけパケットをキューイングし、それ以降のパケットはすべて廃棄する。暗号鍵の設定処理に入る時点で、制御部１２０若しくは通信処理部１１０は内部のカウンタをセットしておき、処理方法をキューイングに設定する。カウントが閾値を超えると、処理方法を廃棄に設定し直して、カウンタをリセットする。

以上、特定の実施形態を参照しながら、本発明について詳解してきた。しかしながら、本発明の要旨を逸脱しない範囲で当業者が該実施形態の修正や代用を成し得ることは自明である。

本明細書では、アドホック・ネットワークにおいてオンデマンド方式のルーティング・プロトコルを実装する場合を例にとって説明してきたが、本発明の要旨はこれに限定されるものではない。

例えば、アドホック以外の形態のネットワークや、オンデマンド方式以外のルーティング・プロトコルを採用する無線ネットワークにおいても、パケットをマルチホップ転送する際に、経路検索によりパケット送信を待機する必要があるときに、同様に本発明を適用することができる。あるいは、データ・パケットの暗号処理に用いる暗号鍵の設定など、パケット送信をトリガにして起動する経路制御以外のオンデマンド型プロトコルに対しても同様に本発明を適用することができる。

要するに、例示という形態で本発明を開示してきたのであり、本明細書の記載内容を限定的に解釈するべきではない。本発明の要旨を判断するためには、特許請求の範囲を参酌すべきである。

図１は、本発明を適用することができる無線アドホック・ネットワークの構成例を示した図である。 図２は、図１に示した無線アドホック・ネットワークにおいて経路を設定するための手順を説明するための図である。 図３は、本発明に係るルーティング・プロトコルを実現した無線通信装置の内部構成を示した図である。 図４は、無線通信装置１００の通信処理部１１０内のメモリ６００に保持される経路テーブル６１０の構成例を示した図である。 図５は、探索中処理方法を設定するデータ・パケット（ＩＰパケット）の構成例を示した図である。 図６は、パケットの宛先までの経路発見の有無に応じてデータ・パケットの送信動作を制御するための処理手順を示したフローチャートである。 図７は、経路探索中のパケットをキューイングする処理方法が指定されている場合の、経路探索中の宛先に対するデータ・パケットを処理する手順を示したフローチャートである。 図８は、鍵テーブル６３０の構成例を示した図である。 図９は、パケットの宛先との暗号鍵の設定の有無に応じてデータ・パケットの送信動作を制御するための処理手順を示したフローチャートである。

符号の説明

１１０…通信処理部
１２０…制御部
１３０…表示部
１４０…操作部
１５０…主メモリ
１８０…バス
６００…メモリ
６１０…経路テーブル
６２０…データ・バッファ
６３０…鍵テーブル

Claims (20)

1. マルチホップ通信環境下でパケット伝送を行なう無線通信装置であって、
   送信パケットを生成するパケット生成手段と、
   送信パケットの宛先までの経路を探索する経路探索手段と、
   前記経路探索手段により発見された送信パケットの宛先までの経路を記述する経路テーブルと、
   前記経路探索手段による経路探索中における送信パケットの処理方法を宛先毎に設定するパケット処理方法設定手段と、
   前記パケット処理方法設定手段により宛先に対して設定された処理方法に従って送信パケットの転送制御を行なうパケット転送制御手段と、
   を具備することを特徴とする無線通信装置。
2. 端末同士が自律分散して相互に接続するアドホック・ネットワークにおいてパケット伝送を行なう、
   ことを特徴とする請求項１に記載の無線通信装置。
3. 前記経路探索手段は、パケットの送信要求が発生した時点で経路を作成する、
   ことを特徴とする請求項１に記載の無線通信装置。
4. 前記経路探索手段は、データリンク層により実装される、
   ことを特徴とする請求項１に記載の無線通信装置。
5. 前記パケット処理方法設定手段は、前記パケット生成手段からの指示に従って、経路探索中における送信パケットの処理方法を設定する、
   ことを特徴とする請求項１に記載の無線通信装置。
6. 前記パケット生成手段は、送信パケットの宛先への経路探索中における送信パケットの処理方法を設定する、
   ことを特徴とする請求項５に記載の無線通信装置。
7. 前記パケット処理方法設定手段は、前記経路テーブルの対応する宛先のエントリに送信パケットの処理方法を記述する、
   ことを特徴とする請求項５に記載の無線通信装置。
8. 前記経路探索手段は、ある宛先に対する経路の探索を開始する際に、前記経路テーブルの対応するエントリに探索中フラグを設定し、
   前記パケット転送制御手段は、探索中フラグが設定されている宛先に向けた送信パケットに対しては該宛先のエントリに記述されたパケットの処理方法を実施する、
   ことを特徴とする請求項７に記載の無線通信装置。
9. 前記経路探索手段は、経路発見後は、前記経路テーブル中の該当するエントリの探索中フラグを解除し、前記パケット転送制御手段は通常のパケット転送処理に戻る、
   ことを特徴とする請求項８に記載の無線通信装置。
10. 前記パケット処理方法設定手段は、宛先が経路探索中である送信パケットを廃棄するように設定する、
    ことを特徴とする請求項１に記載の無線通信装置。
11. 送信パケットを一時的に保持するバッファをさらに備え、
    前記パケット処理方法設定手段は、宛先が経路探索中における送信パケットを前記バッファにキューイングするように設定する、
    ことを特徴とする請求項１０に記載の無線通信装置。
12. パケット伝送を行なう無線通信装置であって、
    送信パケットを生成するパケット生成手段と、
    パケット伝送に伴って、送信パケットの宛先に対してオンデマンドで所定の処理を実行するオンデマンド処理手段と、
    前記オンデマンド処理手段によるオンデマンド処理中における送信パケットの処理方法を宛先毎に設定するパケット処理方法設定手段と、
    前記パケット処理方法設定手段により宛先に対して設定された処理方法に従ってパケットの転送制御を行なうパケット転送制御手段と、
    を具備することを特徴とする無線通信装置。
13. 前記オンデマンド処理手段は、パケットを送信する宛先となる端末と鍵設定を行なう、
    ことを特徴とする請求項１２に記載の無線通信装置。
14. 前記パケット処理方法設定手段は、前記パケット生成手段からの指示に従って、前記オンデマンド処理手段によるオンデマンド処理中における送信パケットの処理方法を設定する、
    ことを特徴とする請求項１２に記載の無線通信装置。
15. 前記パケット生成手段は、前記オンデマンド処理手段が送信パケットの宛先とオンデマンド処理を行なっている間における送信パケットの処理方法を設定する、
    ことを特徴とする請求項１４に記載の無線通信装置。
16. 前記オンデマンド処理手段による宛先とのオンデマンド処理結果を記述する処理結果テーブルをさらに備え、
    前記パケット処理方法設定手段は、前記処理結果テーブルの対応する宛先のエントリにオンデマンド処理中における送信パケットの処理方法を記述する、
    ことを特徴とする請求項１４に記載の無線通信装置。
17. 前記オンデマンド処理手段は、ある宛先とのオンデマンド処理を開始する際に、前記処理結果テーブルの対応するエントリにオンデマンド処理中フラグを設定し、
    前記パケット転送制御手段は、オンデマンド処理中フラグが設定されている宛先に向けた送信パケットに対しては該宛先の処理結果テーブル・エントリに記述されたパケットの処理方法を実施する、
    ことを特徴とする請求項１６に記載の無線通信装置。
18. 前記オンデマンド処理手段は、オンデマンド処理が完了した後は、前記処理結果テーブル中の該当するエントリのオンデマンド処理中フラグを解除し、前記パケット転送制御手段は通常のパケット転送処理に戻る、
    ことを特徴とする請求項１７に記載の無線通信装置。
19. 前記パケット処理方法設定手段は、宛先がオンデマンド処理中である送信パケットを廃棄するように設定する、
    ことを特徴とする請求項１２に記載の無線通信装置。
20. 送信パケットを一時的に保持するバッファをさらに備え、
    前記パケット処理方法設定手段は、宛先がオンデマンド処理中における送信パケットを前記バッファにキューイングするように設定する、
    ことを特徴とする請求項１９に記載の無線通信装置。

Images