アドホックネットワークにおけるルーティング方法
【課題】 スループットなどの通信品質の向上及び無線リソースの消費抑制が図られた、アドホックネットワークにおけるルーティング方法を提供すること。
【解決手段】 アドホックネットワークにおいて、ルートリクエストを送信又は転送するノードは、自局が外部の有線網（インターネット等）と通信接続している場合、該有線網における自局の識別子をルートリクエストに付加して送信又は転送する。ルートリクエストの宛先ノードは、受信したルートリクエストに２以上の上記有線網における識別子が含まれていた場合、これら２以上の識別子のうちルート上最も送信元ノードに近いノードを表す１つの識別子と最も宛先ノードに近いノードを表す１つの識別子とを用いて、これら２つの識別子が表すノード間は上記有線網を経由する経路を採用したルートリプライを作成する。
【解決手段】 アドホックネットワークにおいて、ルートリクエストを送信又は転送するノードは、自局が外部の有線網（インターネット等）と通信接続している場合、該有線網における自局の識別子をルートリクエストに付加して送信又は転送する。ルートリクエストの宛先ノードは、受信したルートリクエストに２以上の上記有線網における識別子が含まれていた場合、これら２以上の識別子のうちルート上最も送信元ノードに近いノードを表す１つの識別子と最も宛先ノードに近いノードを表す１つの識別子とを用いて、これら２つの識別子が表すノード間は上記有線網を経由する経路を採用したルートリプライを作成する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、概して、アドホックネットワークにおけるルーティング方法に係り、特に、スループットの向上及び無線リソースの消費抑制が図られたルーティング方法に関する。
【背景技術】
【０００２】
従来、基地局や固定局を使わずに、端末間でホッピング（中継）することにより、データ伝送を可能とするアドホックネットワーク（或いは、マルチホップ無線ネットワーク、又は、Ｍｏｂｉｌｅ Ａｄ−ｈｏｃ Ｎｅｔｗｏｒｋ；ＭＡＮＥＴ）が知られている。
【０００３】
アドホックネットワークでは、すべての端末によって自律的にネットワークが構築されるため、基地局等の設置が不要となり、柔軟性が高く、設置の容易なネットワーク構築が可能となる。
【０００４】
アドホックネットワークにおいて用いられるルーティングプロトコル（経路制御プロトコル）については、ＩＥＴＦ（Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ）のＭＡＮＥＴワーキンググループ（ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｈｔｍｌ．ｃｈａｒｔｅｒｓ／ｍａｎｅｔ−ｃｈａｒｔｅｒ．ｈｔｍｌ）から種々のものが提案・公開されており、標準化が進められている。
【０００５】
現在、提案・公開されているルーティングプロトコルは、大きく分けるとリアクティブ（Ｒｅａｃｔｉｖｅ）型、プロアクティブ（Ｐｒｏａｃｔｉｖｅ）型、及び、これらのハイブリッド（複合）型、に分けられる。
【０００６】
リアクティブ型のルーティングプロトコルは、実際にデータを送信する際に初めて起動し、周りにある通信可能な端末の電波を送受信して確かめてからルート構築を行うものであり、代表的なものとしては、「Ａｄｈｏｃ Ｏｎ Ｄｅｍａｎｄ Ｄｉｓｔａｎｃｅ Ｖｅｃｔｏｒ（ＡＯＤＶ）」（Ｅｘｐｅｒｉｍｅｎｔａｌ ＲＦＣ ３５６１）や、「Ｄｙｎａｍｉｃ Ｓｏｕｒｃｅ Ｒｏｕｔｉｎｇ（ＤＳＲ）」（Ｉｎｔｅｒｎｅｔ Ｄｒａｆｔ；有効期限２００５年１月１９日）などが挙げられる。
【０００７】
プロアクティブ型のルーティングプロトコルは、任意の時間間隔ごとにルーティング可能な端末を確かめており、常にルートが構築されていて通信可能状態となっているものであり、代表的なものとしては、「Ｏｐｔｉｍｉｚｅｄ Ｌｉｎｋ Ｓｔａｔｅ Ｒｏｕｔｉｎｇ（ＯＬＳＲ）」（Ｅｘｐｅｒｉｍｅｎｔａｌ ＲＦＣ ３６２６）や、「Ｔｏｐｏｌｏｇｙ Ｂｒｏａｄｃａｓｔ ｂａｓｅｄ ｏｎ Ｒｅｖｅｒｓｅ−Ｐａｔｈ Ｆｏｒｗａｒｄｉｎｇ（ＴＢＲＰＦ）」（Ｅｘｐｅｒｉｍｅｎｔａｌ ＲＦＣ ３６８４）などが挙げられる。
【０００８】
すなわち、リアクティブ型プロトコルではデータを送信する際にどの端末を通ってデータをリレーさせるのかが決定されるのに対し、プロアクティブ型プロトコルでは予め決定されているリレーの順番に従ってデータが送信される。前者は各端末における電池効率の点で有利であり、後者は通信タイムアウトや送信データロスが少ないという利点を有する。
【０００９】
また、このような標準化への取り組みとは別に、アドホックネットワークにおける独自のパケットルーティング方法も提案されている（例えば、特許文献１参照）。
【００１０】
さらに、アドホックネットワークとインターネットなどの有線インフラを組み合わせて利用する際のルーティング等に関する技術も提案されている（例えば、特許文献２〜４参照）。
【特許文献１】特開平１１−２３９１７６号公報
【特許文献２】特開２００２−３５４０１６号公報
【特許文献３】特開２００３−２３０１６７号公報
【特許文献４】特開２００４−２４８１８０号公報
【発明の開示】
【発明が解決しようとする課題】
【００１１】
周知の通り、アドホックネットワークでは、ホップ数が増えるほど、すなわち経由する端末（ノード）が増えるほど、通信品質は劣化する傾向となる。
【００１２】
本願発明者らは、アドホックネットワークにおいて、あるルートの中継局となっているアドホック通信端末の中に例えば無線ＬＡＮなどを利用して例えばインターネットなどの有線網に接続可能なものが２つ以上存在する場合、ルートの一部を有線網経由の経路に置き換えることによって、通信品質を大幅に改善できることに着目した。
【００１３】
この点、上述のＩＥＴＦ−ＭＡＮＥＴ−ＷＧにより提案・公開されている種々のルーティングプロトコル及び上記特許文献１記載のルーティング方法はいずれも、アドホックネットワーク内に閉じたルーティングを行うものであり、アドホックネットワークと同時にインターネットなどの有線網を利用することへ拡張されていない。
【００１４】
また、上記特許文献２記載の方法は、インターネットに接続されたノードがアドホックネットワーク内に入ったときにインターネット経由でルーティングしないようにするためのものであり、アドホックネットワークと同時にインターネットなどの有線網を利用するものではない。
【００１５】
また、上記特許文献３記載の方法は、アドホックネットワークを介してインターネットへ接続する通信において、インターネットへの接続先として関門（ゲートウェイ）となる端末を探索するものであるが、アドホック通信端末同士のルートの一部にインターネットを利用するものではない。また、この従来方法に従ってアドホック端末同士を接続した場合、必ずインターネットを経由した通信経路となり、端末同士が近接している場合であってもアドホック通信ができなくなってしまう。
【００１６】
さらに、上記特許文献４記載の方法は、複数の無線通信メディアの中から通信状況に応じていずれかを選択するものであるが、選択されるのはルート全体に利用される通信メディアであって、アドホックネットワークにおいてルートの一部をインターネットなどの有線網経由の経路に置き換えるものではない。
【００１７】
このように、従来提案されているアドホックネットワークにおけるルーティング方法では、アドホックネットワークにおいて、あるルートの中継局となっているアドホック通信端末の中に有線網と接続可能なものが２つ以上あったとしても、ルートの一部を有線網経由の経路で置き変えたルーティングを実現させることはできない。
【００１８】
仮に、例えばＩＥＴＦ−ＭＡＮＥＴ−ＷＧにおいて提案・公開されているルーティングプロトコルをそのまま用いて、有線網を経由したルートまで含めたルート探索を行おうとすれば、ブロードキャストされたルートリクエスト（ＲＲＥＱ）を受信した端末が有線網と接続している場合、ＲＲＥＱがアドホックネットワーク内だけでなく有線網内にもブロードキャストで転送されるといった構成になりかねない。そのような事態は、有線網の通信トラフィックに甚大な被害を与えかねず、実施不可能である。
【００１９】
本発明はこのような課題を解決するためのものであり、アドホックネットワークにおいて、アドホックネットワーク内に閉じたパケット伝送のみによって、アドホックネットワーク内に閉じたルートだけでなく、ルートの一部を有線網経由の経路で置き換えたルートをも探索可能とすることによって、従来方法に比してスループットを向上させ、無線リソースの消費を抑制することが可能なルーティング方法を提供することを主たる目的とする。
【課題を解決するための手段】
【００２０】
上記目的を達成するための本発明の第一の態様は、アドホックネットワーク（ＭＡＮＥＴ）におけるルーティング方法であって、ルートリクエスト（ＲＲＥＱ）を送信又は転送するノードは、自局が外部の有線網と通信接続している場合、該有線網における自局の識別子を上記ルートリクエストに付加して送信又は転送する、アドホックネットワークにおけるルーティング方法である。
【００２１】
この第一の態様において、上記外部の有線網とは例えばインターネットなどである。その場合、アドホック通信端末（ノード）が、例えば無線ＬＡＮ機能を備え、例えばホットスポット（ｈｏｔｓｐｏｔ）エリア内に在圏するとき、そのノードはアドホックネットワーク内に閉じたアドホック通信もインターネットを経由した通信も可能となる。
【００２２】
この第一の態様によれば、ルートリクエストを受信した宛先ノード（送信先ノード）は、経路中に有線網に接続しているノードが存在するか否か及び存在する場合何台存在するのかを知ることができる。
【００２３】
また、このルートリクエストの送信・転送は、アドホックネットワーク内に閉じて行われるものであり、ルートリクエストの宛先ノードは、上記有線網で何らパケット伝送を行うことなく、すなわち該有線網上の通信トラフィックに影響を与えることなく、該有線網を利用する場合の各ノードの識別子を取得することができる。
【００２４】
上記目的を達成するための本発明の第二の態様は、上記第一の態様において、上記ルートリクエストの宛先ノードは、受信したルートリクエストに２以上の上記有線網における識別子が含まれていた場合、これら２以上の識別子のうちルート上最も送信元ノードに近いノードを表す１つの識別子と最も宛先ノードに近いノードを表す１つの識別子とを用いて、これら２つの識別子が表すノード間は上記有線網を経由する経路を採用したルートリプライ（ＲＲＥＰ）を作成する、アドホックネットワークにおけるルーティング方法である。
【００２５】
この第二の態様によれば、アドホック通信経路の一部がアドホックネットワークにおける無線リンクよりも良好な通信品質が見込める有線網を経由した経路で置き換えられるため、アドホックネットワーク内のみを通る経路を採用した場合に比して通信品質が向上する。
【００２６】
上記目的を達成するための本発明の第三の態様は、上記第二の態様において、上記ルートリクエストの宛先ノードは、アドホックネットワーク内のみでルーティングした場合に上記２つの識別子が表すノード間に所定数（例えば２ホップ）以上のホップ数が存在する場合のみ、これら２つの識別子が表すノード間は上記有線網を経由する経路を採用したルートリプライを作成する、アドホックネットワークにおけるルーティング方法である。
【００２７】
この第三の態様によれば、近接した（例えばホップ数が１の距離にある）ノード間の無線リンクが有線網に置き換えられてしまうことが防止されるため、ホップ数削減の効果が十分に得られる場合のみ、有線網が利用されるようにすることができる。
【００２８】
上記目的を達成するための本発明の第四の態様は、上記第三の態様において、ルートリクエストの宛先ノードは、最初のルートリクエストを受信してから所定期間、他の経路を経由した同じ送信元ノードからのルートリクエストの受信を待機し、上記所定期間内に同じ送信元ノードから１以上のルートリクエストが受信された場合、上記最初のルートリクエスト及び前記所定期間中に受信されたルートリクエストのうち２以上の上記有線網における識別子が含まれているルートリクエストについてはこれら２つの識別子が表すノード間は上記有線網を経由するものとして、各ルートリクエストの経路のホップ数を比較し、最もホップ数が少ない経路を有するルートリクエストに対してルートリプライを作成する、アドホックネットワークにおけるルーティング方法である。
【００２９】
従来、最初に宛先ノードによって受信されたルートリクエスト以外の遅延して到着したルートリクエストは冗長な経路を通っているものと判断されて破棄されていたが、この第四の態様によれば、アドホックネットワーク内に閉じたルートでは最小ホップ数でなかったルートが上記第三の態様のように経路の一部を有線網でショートカットすることによって最小ホップ数のルートとなる可能性があることに鑑み、遅延して宛先ノードに到着したルートリクエストであってもＲＲＥＰ返信候補に取り上げることによって、有線網を利用して通信品質を向上させる機会を増やすことができる。
【００３０】
上記目的を達成するための本発明の第五の態様は、上記第四の態様において、ルートリクエストの宛先ノードは、２以上の上記有線網における識別子が含まれているルートリクエストが受信されたときに上記他の経路を経由した同じ送信元ノードからのルートリクエストの受信の待機を終了する、アドホックネットワークにおけるルーティング方法である。
【００３１】
この第五の態様によれば、経路の一部を有線網を経由する経路に置き換えることによるショートカットが可能なルートを示すルートリクエストが１つでも受信された段階で、当該ルートリクエストを選択することによってホップ数の削減が見込めると判断し、上記所定待機時間を速やかに終了させるため、ルートリプライをより迅速に作成することができる。
【００３２】
上記目的を達成するための本発明の第六の態様は、上記第四又は第五の態様において、受信したルートリクエストを転送するノードは、受信したルートリクエストに上記有線網における識別子が含まれている場合、その受信したルートリクエストが既に転送済みのルートリクエストであっても破棄せずに初めて受信したルートリクエストと同様に転送する、アドホックネットワークにおけるルーティング方法である。
【００３３】
従来、既に転送済みのルートリクエストを受信したノードはそのルートリクエストを破棄していたが、この第六の態様によれば、アドホックネットワーク内に閉じたルートでは最小ホップ数でなかったルートが上記第三の態様のように経路の一部を有線網でショートカットすることによって最小ホップ数のルートとなる可能性があることに鑑み、既に転送済みのルートリクエストであっても有線網における識別子を含み、有線網を利用したショートカットが実現される可能性があるルートリクエストについては破棄せずに再度転送することによって、有線網を利用して通信品質を向上させる機会を増やすことができる。
【００３４】
上記目的を達成するための本発明の第七の態様は、上記第四乃至第六の態様のいずれかにおいて、各ノードは、自局周辺の上記有線網と通信接続しているノードを探索し、存在する場合、ルートリクエストを送信又は転送する際に自局からその自局周辺の上記有線網と通信接続しているノードまでのホップ数を該ルートリクエストに付加する、ことを特徴とするアドホックネットワークにおけるルーティング方法である。
【００３５】
この第七の態様によれば、このようなルートリクエストを受信した宛先ノードは、ルートリクエストが転送されてきた経路中に有線網へ接続しているノードがない場合であっても、有線網へ接続可能なノードまでのホップ数を知ることができるため、有線網を経由した場合のホップ数を知ることができる。よって、アドホックネットワーク内では冗長なルートも含めて、有線網によるショートカットを利用した場合に最もホップ数が少なくなるルートを探索することができる。
【００３６】
なお、ここでは、ルーティング判定の指標としてホップ数を例に挙げたが、当業者には明らかなようにこれは一例に過ぎず、例えば通信帯域や遅延時間などの通信品質に関連する指標などの他の指標を用いてルーティングの判定を行うことも可能である。
【発明の効果】
【００３７】
本発明によれば、アドホックネットワークにおいて、経路の一部を積極的に有線網経由の経路に置き換えることによってホップ数の削減を図ることができるため、スループットなどの通信品質の向上及び無線リソースの消費抑制が図られたルーティング方法を提供することができる。
【発明を実施するための最良の形態】
【００３８】
以下、本発明を実施するための最良の形態について、添付図面を参照しながら実施例を挙げて説明する。なお、アドホックネットワークの基本概念については当業者には既知であるため、詳しい説明を省略する。
【実施例１】
【００３９】
まず、図１〜９を用いて、本発明の一実施例（実施例１）に係るルーティング方法について説明する。本実施例では、ルーティングプロトコルとしてＤＳＲが用いられることを前提し、図１に示すようなアドホック通信端末が点在する通信環境において、送信端末が受信端末へデータを送信するために経路探索（ルートディスカバリー）を実行する場合を考える。
【００４０】
また、本実施例において、各通信端末は、アドホック通信が可能であると共に、ホットスポットエリア内にいるときには無線ＬＡＮを利用してインターネットに接続する能力を有するものとする。図１に例示した通信環境では、端末Ｂ及びＣがホットスポット（ＨＳ）１内に位置し、端末Ｇ及びＪがホットスポット（ＨＳ）２内に位置し、端末Ｉ、Ｋ、及びＭがホットスポット（ＨＳ）３内に位置している。
【００４１】
本実施例は、これらインターネットに接続した端末を利用して、アドホックネットワーク内に閉じたルーティング処理によって、インターネットを経由する経路も考慮した経路探索を可能にする。
【００４２】
図２は、各アドホック通信端末の概略構成を示す。
【００４３】
端末２００は、無線機である送受信部２０１と、受信したパケットを転送するか否かを判断するパケット転送部２０２とを有する。
【００４４】
また、端末２００は、ルーティングのための経路表（ルーティングテーブル）２０３を有する。ルーティングテーブルは、各端末に記憶されており、宛先とその宛先へパケットを届けるために送り出す転送先の組（ペア）を表にした参照テーブルである。パケット転送部２０２は、自局宛でないパケットを受信したとき、ルーティングテーブル２０３を参照して、宛先に適したノードへ転送する。
【００４５】
また、端末２００は、ルートリクエスト（ＲＲＥＱ）及びルートリプライ（ＲＲＥＰ）を処理するルーティング用パケット処理部２０４と、各端末（ノード）の識別子（アドレス）を格納したアドレス格納部２０５とを有する。
【００４６】
本実施例は、現行のＤＳＲプロトコルを拡張するものであり、以下に特段の説明がない点については通常のＤＳＲプロトコルに準拠して処理される。
【００４７】
本実施例において追加・拡張された主たる点は、ルーティング用パケット処理部２０４の機能である。現行のＤＳＲプロトコルによれば、ルーティング用パケット処理部２０４は、ＲＲＥＱを中継する際、受信されたＲＲＥＱに自局のアドホックネットワーク内での識別子（ＭＡＮＥＴ内端末識別子）を追記してパケット転送部２０２へ渡し、パケット転送部２０２がこれを転送する。
【００４８】
本実施例において、ルーティング用パケット処理部２０４は、更に、無線ＬＡＮ通信機能を備え、ホットスポットのアクセスポイント（ＡＰ）が送出しているビーコンを検出し、自局がホットスポットエリア内に位置するか否かを判断する。そして、自局がホットスポットエリア内に位置すると判断した場合、上記ＭＡＮＥＴ内端末識別子に加えて、インターネット上における自局の識別子（グローバル通信用識別子）をＲＲＥＱに追記する。グローバル通信用識別子が追記されたＲＲＥＱは、通常のＲＲＥＱと同様、アドホックネットワーク内だけでフラッディングされ、インターネット上へは送出されない。
【００４９】
追記される情報を図３に示す。図３（ａ）は、端末がホットスポットエリア内に位置する場合に中継するＲＲＥＱに追記される自局情報であり、図３（ｂ）は、端末がホットスポットエリア内に位置しない場合に中継するＲＲＥＱに追記される自局情報である。
【００５０】
ここで、ＭＡＮＥＴ内端末識別子は、例えば、ＭＡＣアドレスやＩＰアドレスなどであり、グローバル通信用識別子は、例えば、ＩＰアドレスである。ＭＡＮＥＴ内端末識別子とグローバル通信用識別子とは、例えば、識別子（アドレス）の割り当て空間を別にする、或いは、専用のフラグ（１ビット）を設け、グローバル通信用識別子が追記された場合にはこのフラグを立てる、などにより区別することができる。
【００５１】
このように、本実施例に係る拡張によれば、経路探索時に、中継ノードがホットスポットエリア内にいれば、ＲＲＥＱに追記される情報が増えるが、これは経路探索時のみであり、ルート確立後のデータ送信では特段の追加的情報が付加されない。
【００５２】
ＲＲＥＱの中継に関して、その他の点は現行のＤＳＲに準拠する。すなわち、送信端末からブロードキャストされたＲＲＥＱは、周囲の端末によって受信される。各端末は、受信したＲＲＥＱの宛先が自局でなければ、上述のような自局情報を追記した上で、ＲＲＥＱをブロードキャストする。このような転送・中継が繰り返され、最終的に受信端末に到達する。
【００５３】
また、ある端末から転送されたＲＲＥＱが転送先ノードによる転送によって再度戻ってきて最初の端末により受信される場合が当然生じるが、「ＲＲＥＱに記述された経路情報に自局が含まれている場合、そのＲＲＥＱは破棄する」というＤＳＲプロトコルのルールによって、そのＲＲＥＱは処理済みとして破棄される。
【００５４】
図４は、図１に例示した通信環境において、ＲＲＥＱが送信端末から受信端末へ到達した際に経由した経路の一例を示している。
【００５５】
ＲＲＥＱがこのようなルートを通った場合、現行のＤＳＲプロトコルによれば、受信端末により受信されたＲＲＥＱには図５に示すような経路情報が記述されている。この経路情報から、このＲＲＥＱは、送信端末から、端末Ｂ、端末Ｃ、端末Ｆ、端末Ｉ、端末Ｋ、及び、端末Ｍを順に経由して受信端末に届いたことがわかる。
【００５６】
一方、本実施例によれば、上述のようにＤＳＲプロトコルが拡張されているため、受信端末により受信されたＲＲＥＱには図６に示すような経路情報が記述されていることになる。図示するように、ホットスポットエリア内に位置する端末Ｂ、端末Ｃ、端末Ｉ、端末Ｋ、及び端末Ｍに関しては、ＭＡＮＥＴ内端末識別子だけでなく、グローバル通信用識別子も記述されている。
【００５７】
ＲＲＥＱは様々な経路でそのＲＲＥＱの宛先ノードである受信端末に到達するが、受信端末は、最初に到達したＲＲＥＱが最もホップ数が少ない最短のルートを経由していると判断して、その最初に受信したＲＲＥＱに基づいてＲＲＥＰを作成し、送信端末にユニキャスト送信する。現行のＤＳＲプロトコルによれば、図５に示したようなＲＲＥＱを最初に受信した受信端末はこの経路を選択し、この経路情報を記述されたＲＲＥＰを作成して送信端末にユニキャストする。このＲＲＥＰは、図５のＲＲＥＱに記述された経路を逆にたどって転送されながら送信端末に到達する。
【００５８】
一方、本実施例に係るルーティング方法によれば、図６に示すようなＲＲＥＱを最初に受信した受信端末（＝ＲＲＥＱの宛先ノード）は、グローバル通信用識別子が記述された端末の中で最も送信端末に近いもの（ここでは端末Ｂ）と最も受信端末に近いもの（ここでは端末Ｍ）とをそれぞれ抽出し、それらのグローバル通信用識別子を利用してそれらノード間はインターネットを経由する経路を通るＲＲＥＰを作成する。
【００５９】
図６に示すＲＲＥＱの場合、受信端末で作成されるＲＲＥＰは図７のようになる。この図７に示すＲＲＥＰは、送信端末〜端末Ｂ間はアドホックネットワークを経由し、端末Ｂ〜端末Ｍ間はインターネットを経由し、更に、端末Ｍ〜受信端末間はアドホックネットワークを経由した経路が選択されたことを意味する。
【００６０】
この本実施例に係るＲＲＥＰも、現行プロトコルと同様、記述された経路を逆にたどって送信端末にユニキャストされる。したがって、端末Ｍから端末Ｂへの転送にはインターネットが利用される。このＲＲＥＰの転送はブロードキャストであるＲＲＥＱとは異なりユニキャストであるため、インターネットを経由しても負荷は問題とならない。
【００６１】
このように、本実施例によれば、インターネットはアドホックネットワークの無線リンクに比して十分に太く、通信品質が良いという洞察を前提として、アドホックネットワークにおいて探索・確立されるルートの一部をインターネットを経由したルートとすることができる。
【００６２】
また、インターネットを経由することにより、いくつかの中継ノードがショートカットされるため、ルート全体でのホップ数の削減も見込める。図８は、現行のＤＳＲプロトコルにより確立されるルートと本実施例により確立されるルートとを比較するものであり、図８（ａ）は図５に示したＲＲＥＱ及びＲＲＥＰ経路情報を示し、図８（ｂ）は図７に示したＲＲＥＰ経路情報を示す。図示するように、端末Ｂ〜端末Ｍ間をインターネットを経由したルートとすることによって、この場合、ホップ数が２ホップ短縮される。
【００６３】
以上のような本実施例に係るルーティング方法について、図９を用いてより詳細に説明する。図９は、本実施例において各端末において行われる受信したＲＲＥＱに対する処理の流れを示すフローチャートである。
【００６４】
まず、各端末はＲＲＥＱの受信を待機する（Ｓ９０１）。
【００６５】
ＲＲＥＱが受信されると（Ｓ９０１の「ＹＥＳ」）、受信したＲＲＥＱに記述された経路情報に自局の情報が含まれているか否かを判断する（Ｓ９０２）。含まれている場合（Ｓ９０２の「ＹＥＳ」）、処理済みのＲＲＥＱであるものと判断して、そのＲＲＥＱを破棄する（Ｓ９１２）。
【００６６】
受信したＲＲＥＱの経路情報に自局が含まれていない場合（Ｓ９０２の「ＮＯ」）、次いで、そのＲＲＥＱの宛先ノードが自局であるか否かが判断される（Ｓ９０３）。自局が宛先ノードでない場合、Ｓ９０４〜Ｓ９０７の転送処理が実行され、自局が宛先ノードの場合、Ｓ９０８〜Ｓ９１１のＲＲＥＰ作成・送信処理が実行される。
【００６７】
まず、自局が宛先ノードでない場合（Ｓ９０３の「ＮＯ」）、従来通り、ＲＲＥＱに自局のＭＡＮＥＴ内端末識別子を追記する（Ｓ９０４）。そして、更に、自局がホットスポットエリア内にいるか否か、換言すれば無線ＬＡＮを利用してインターネットに接続している状態であるか否か、について判断し（Ｓ９０５）、ホットスポット内にいる場合（Ｓ９０５の「ＹＥＳ」）、上述のように受信したＲＲＥＱに更に自局のグローバル通信用識別子も追記する（Ｓ９０６）。ホットスポット内にいない場合（Ｓ９０５の「ＮＯ」）、Ｓ９０６の処理はスキップされ、グローバル通信用識別子はＲＲＥＱに記述されない。
【００６８】
このように自局情報が追記されると、追記後のＲＲＥＱを周囲の端末へフラッディングする（Ｓ９０７）。これで１回の中継処理が終了し、Ｓ９０１へ戻る。
【００６９】
一方、自局が宛先ノードである場合（Ｓ９０３の「ＹＥＳ」）、受信したＲＲＥＱに基づいてＲＲＥＰを作成し、送信端末へ返信するために、まず、ＲＲＥＱが転送されてきたルートの一部をインターネット経由の経路で置き換えるか否かが判断される（Ｓ９０８）。
【００７０】
Ｓ９０８において、「Ｒｒｅｑ」は、受信されたＲＲＥＱ内に記述されていた経路を表し、「Ｈ（Ｒ）」は、ルートＲ上で最も送信端末寄りでホットスポット内にいる端末から最も受信端末寄りでホットスポット内にいる端末までの経路を抽出したものを表し、「Ｈｏｐ（Ｒ）」は、ルートＲのホップ数を表す。
【００７１】
なお、Ｈ（Ｒ）は、ルートＲ上にホットスポット内に位置する端末が２つ以上存在しない場合、空（＝０）とする。また、例えば、ルートＲ＝送信者→Ａ＊→Ｂ＊→Ｃ→Ｄ→Ｅ＊→Ｆ→受信者であった場合（「＊」はホットスポット内）、Ｈ（Ｒ）＝Ａ＊→Ｂ＊→Ｃ→Ｄ→Ｅ＊となる。
【００７２】
すなわち、Ｓ９０８においては、受信端末により受信されたＲＲＥＱに記述された経路のうち最も送信端末寄りでホットスポット内にいる端末から最も受信端末寄りでホットスポット内にいる端末までの経路のホップ数が所定の閾値以上であるか否かが判定されている。
【００７３】
ここでは、通信品質向上のためなるべくインターネットを経由したいが、しかしながら、端末〜ＡＰ間も無線通信の１ホップとカウントされるため、インターネットへのゲートウェイとなるホットスポットエリア内に在圏した２つの端末がアドホックネットワーク上で近接した位置関係にある場合（例えば、ホップ数＝１の距離にある場合など）にまでわざわざインターネットを経由させる必要はないとの洞察から、上記所定の閾値は例えば「２ホップ」などに設定される。
【００７４】
換言すれば、本実施例では、所定数以上のホップ数が削減される場合のみ、ルートの一部をインターネットを経由した経路に置き換える。
【００７５】
このようなＳ９０８における判定処理において、削減されるホップ数が所定の閾値以上であると判断された場合（Ｓ９０８の「ＹＥＳ」）、図６に示したＲＲＥＱから図７に示したＲＲＥＰを作るように、受信したＲＲＥＱからインターネットを経由した経路を採用したＲＲＥＰが作成される（Ｓ９０９）。一方、Ｓ９０８における判定処理において、削減されるホップ数が所定の閾値未満であると判断された場合（Ｓ９０８の「ＮＯ」）、図５に示すように、現行のＤＳＲプロトコルに従って受信されたＲＲＥＱに記述されたのと同じ経路情報が記述されたＲＲＥＰが作成される（Ｓ９１０）。
【００７６】
上述のＳ９０８についての説明から明らかなように、受信したＲＲＥＱに記述された経路情報に含まれる端末の中に含まれるホットスポット内にいる端末の数が２未満であってインターネットによるショートカットが物理的に実現できない場合にも、Ｓ９０８における判定は「ＮＯ」となり、従来通り、アドホックネットワークに閉じた経路を示すＲＲＥＰが作成される。
【００７７】
そして、このようにして作成されたＲＲＥＰは送信端末へ向けてユニキャストで返信される（Ｓ９１１）。これで１回の経路探索処理が終了し、Ｓ９０１へ戻る。
【００７８】
このように、本実施例によれば、アドホックネットワーク内でＲＲＥＱが転送されるというＭＡＮＥＴ内に閉じたルーティング処理でありながら、インターネットに接続している中継ノードは上述のようなグローバル通信用識別子もＲＲＥＱに付加して転送するという特徴を備えたことにより、インターネット上に経路要求を流さずにインターネットを経由したルートも考慮した経路探索が可能となる。
【００７９】
従来、アドホックネットワーク上での経路探索にはアドホックネットワーク上で経路要求する必要があり、インターネット上での経路探索にはインターネット上で経路要求する必要があったことと比較すれば、本実施例の有益性は明らかである。
【００８０】
なお、本実施例においては、ＲＲＥＱを受信した受信端末がインターネットを経由するＲＲＥＰを作成するか否かを判断する（図９のＳ９０８）際に、受信したＲＲＥＱに記述された経路となった端末の中で最も送信端末寄りのホットスポット内の端末と最も受信端末寄りのホットスポット内の端末とをインターネットへのゲートウェイとして利用するものとした。また、インターネットを経由することにより削減されるホップ数が所定の閾値以上であれば必ずインターネットを経由するルートが選択されるものとした。
【００８１】
この点、理論上は、最も送信端末寄りでないホットスポット内の端末を利用することも、最も受信端末寄りでないホットスポット内の端末を利用することも可能であり、さらに、削減されるホップ数が所定の閾値以上の場合であってもあえて現行通りアドホックネットワーク内に閉じたルーティングを行うことも可能である。
【００８２】
しかしながら、当業者には既知のように、アドホックネットワークではホップ数が増えるほど通信品質は劣化するため、できる限りアドホックネットワーク内での無線リンクを減らして、インターネットを経由したルートを通った方が通信品質は良好となる。
【００８３】
したがって、上記実施例のようにできる限りインターネットを経由させようとすることは、好ましい実施形態であると言える。
【実施例２】
【００８４】
次に、図１０〜１４を用いて、本発明の別の一実施例（実施例２）に係るルーティング方法について説明する。本実施例では、ルーティングプロトコルとしてＡＯＤＶが用いられることを前提し、上記実施例１と同様に図１に示すようなアドホック通信端末が点在する通信環境において、送信端末が受信端末へデータを送信するために経路探索（ルートディスカバリー）を実行する場合を考える。
【００８５】
また、本実施例においても、上記実施例１と同様に、各通信端末は、アドホック通信が可能であると共に、ホットスポットエリア内にいるときには無線ＬＡＮを利用してインターネットに接続する能力を有するものとする。端末の概略構成は図２に示したのと同様であり、重複する説明は省略する。
【００８６】
本実施例によっても、インターネットに接続した端末を利用して、アドホックネットワーク内に閉じたルーティング処理によって、インターネットを経由する経路も考慮した経路探索が可能となる。
【００８７】
このように、本実施例は、ルーティングプロトコルとしてＡＯＤＶを採用している点が異なる以外、基本的特徴は上記実施例１と同じであるため、重複する説明は省略する。したがって、以下の本実施例の説明は、主として、ＤＳＲとＡＯＤＶの違いにより生じる適用方法の違いについての説明である。
【００８８】
本実施例においても、ＲＲＥＱを受信した各通信端末は、自局がホットスポットエリア内に位置すると判断した場合、インターネット上における自局の識別子（グローバル通信用識別子）をＲＲＥＱに追記した上で転送する。本実施例においても、グローバル通信用識別子が追記されたＲＲＥＱは、通常のＲＲＥＱと同様、アドホックネットワーク内だけでフラッディングされ、インターネット上へは送出されない。
【００８９】
本実施例により拡張されたＡＯＤＶプロトコルにおけるＲＲＥＱのパケット構造を図１０に示す。図示すように、本実施例に係るＲＲＥＱは、上段部分が、フラグＨを除き、現行のＡＯＤＶプロトコルに準拠した構造であり、下段部分が拡張された追加部分となっている。
【００９０】
上段の「タイプ」フィールドは、メッセージの種類を示すためのものであり、ＲＲＥＱの場合は「１」が入る。「ホップ数」フィールドは、送信元ノードから何回転送されたかを表すフィールドであり、送信端末から送信されるときには０である。
【００９１】
本実施例の拡張により追加されたフラグＨは、経路中にホットスポットエリア内に位置する端末が存在し、ＲＲＥＱにその端末のグローバル通信用識別子が記述された場合に立てられる。
【００９２】
下段の追加部分には、ホットスポットエリア内に位置する端末によって追記されたグローバル通信用識別子と、送信端末からその端末までのホップ数とが記述される。ＡＯＤＶプロトコルでは、ソースルーティングであるＤＳＲプロトコルと異なり、ＲＲＥＱ内にすべての経路が記述されず、各端末は自局が保持するルーティングテーブルに従って転送を行う。したがって、ＲＲＥＱを中継する各端末はＲＲＥＱに自局のＭＡＮＥＴ内端末識別子は書き込まず、本実施例による拡張によりグローバル通信用識別子のみが追記される。
【００９３】
図１に例示した通信環境において図４に示したようなルートで本実施例に係るＲＲＥＱが転送された場合に受信端末が受信するＲＲＥＱを図１１に示す。図４の例では、経路上の端末Ｂ、端末Ｃ、端末Ｉ、端末Ｋ、及び端末Ｍがホットスポットエリア内に位置するため、ＲＲＥＱ下段に追加された拡張部分にこれら端末のグローバル通信用識別子及び送信端末からのホップ数が記述されている。ここで、ホップ数＝３の端末Ｆ（図４）は、ホットスポットエリア内に位置しないため、ＲＲＥＱ内に記述がない。
【００９４】
このように、本実施例に係る拡張によれば、経路探索時に、中継ノードがホットスポットエリア内にいれば、ＲＲＥＱに追記される情報が増えるが、これは経路探索時のみであり、ルート確立後のデータ送信では特段の追加的情報が付加されない。
【００９５】
ＲＲＥＱの中継に関して、その他の点は現行のＡＯＤＶプロトコルに準拠する。すなわち、送信端末からブロードキャストされたＲＲＥＱは、周囲の端末によって受信される。各端末は、受信したＲＲＥＱの宛先が自局でなければ、上述のような自局情報を追記した上で、ＲＲＥＱをブロードキャストする。このような転送・中継が繰り返され、最終的に受信端末に到達する。
【００９６】
このように、本実施例によれば、上述のようにＡＯＤＶプロトコルが拡張されているため、受信端末は、受信されたＲＲＥＱから、経路上の端末Ｂ、端末Ｃ、端末Ｉ、端末Ｋ、及び端末Ｍがホットスポットエリア内に位置することを知ることができると共に、それらのグローバル通信用識別子も取得することができる。
【００９７】
ＡＯＤＶプロトコルにおいても、ＲＲＥＱは様々な経路でそのＲＲＥＱの宛先ノードである受信端末に到達し、受信端末は、最初に到達したＲＲＥＱが最もホップ数が少ない最短のルートを経由していると判断して、その最初に受信したＲＲＥＱに基づいてルートリプライ（ＲＲＥＰ）を作成し、送信端末にユニキャスト送信する。
【００９８】
本実施例において、ＲＲＥＱの宛先ノードである受信端末は、最初に受信したＲＲＥＱの中に記述されたグローバル通信用識別子の数が１以下であった場合、経路の一部をインターネット経由にすることはできないと判断して、現行通り、アドホックネットワーク内に閉じたＲＲＥＰを作成し、送信端末へ返信する。
【００９９】
一方、受信したＲＲＥＱに２以上のグローバル通信用識別子が含まれていた場合、受信端末は、それら記述されているグローバル通信用識別子の中から、経路上最も送信端末寄りの端末のものと最も受信端末寄りのものとを抽出し、ＲＲＥＰに記述する。
【０１００】
本実施例に従って作成されたＲＲＥＰのフォーマット例を図１２に示す。上段の「タイプ」フィールドは、ＲＲＥＰの場合「２」が入る。「ホップ数」フィールドは、宛先ノードから何回転送されたかを表すフィールドであり、受信端末からユニキャスト送信される際には０である。
【０１０１】
下段の追加部分には、ＲＲＥＱに記述されていたグローバル通信用識別子の中から経路上最も宛先ノードに近いものが「グローバル通信用識別子１」フィールドに記述され、最も送信元ノードに近いものが「グローバル通信用識別子２」フィールドに記述される。
【０１０２】
図１１に例示したＲＲＥＱを受信した受信端末が返信するＲＲＥＰを図１３に示す。ここでは、「グローバル通信用識別子１」フィールドに端末Ｍのグローバル通信用識別子が記述され、「グローバル通信用識別子２」フィールドに端末Ｂのグローバル通信用識別子が記述される。
【０１０３】
このように作成された本実施例に係るＲＲＥＰは、現行プロトコルと同様、送信端末にユニキャストされる。ただし、本実施例においては、現行のＡＯＤＶプロトコルの拡張として、ＲＲＥＰを中継する各端末は、受信したＲＲＥＰの「グローバル通信用識別子１」フィールドに自局のグローバル通信用識別子が記述されていた場合、自局が保持するアドホックネットワーク用のルーティングテーブルには従わず、そのＲＲＥＰをインターネット経由で「グローバル通信用識別子２」フィールドに記述されたグローバル通信用識別子（アドレス）宛に送信する。そして、受信したＲＲＥＰに記述されたホップ数を１インクリメントした値と宛先ノードと関連付けて新たにルーティングテーブルに記憶する。これにより、その中継ノードは、その宛先ノードまで何ホップであるかを自局内のルーティングテーブルに記憶することができる。
【０１０４】
インターネット経由でＲＲＥＰを受信した端末は、現行通り、自局が保持するルーティングテーブルに従ってそのＲＲＥＰをアドホックネットワーク内で送信する。
【０１０５】
このようにして、ＲＲＥＰの返信には、上記実施例１と同様に、インターネットが利用される。このＲＲＥＰの転送はブロードキャストであるＲＲＥＱとは異なりユニキャストであるため、インターネットを経由しても負荷は問題とならない。
【０１０６】
このように、本実施例によっても、アドホックネットワークにおいて探索・確立されるルートの一部をインターネットを経由したルートとすることができ、図８に示したようなホップ数削減が見込まれる。
【０１０７】
以上のような本実施例に係るルーティング方法について、図１４を用いてより詳細に説明する。図１４は、本実施例において各端末において行われる受信したＲＲＥＱに対する処理の流れを示すフローチャートである。
【０１０８】
まず、各端末はＲＲＥＱの受信を待機する（Ｓ１４０１）。
【０１０９】
ＲＲＥＱが受信されると（Ｓ１４０１の「ＹＥＳ」）、例えば「ＲＲＥＱ ＩＤ」フィールドの記述から処理済みのＲＲＥＱであるか否かを判断する（Ｓ１４０２）。処理済みの場合（Ｓ１４０２の「ＹＥＳ」）、そのＲＲＥＱを破棄する（Ｓ１４１２）。
【０１１０】
受信したＲＲＥＱが処理済みではない場合（Ｓ１４０２の「ＮＯ」）、次いで、そのＲＲＥＱの宛先ノードが自局であるか否かが判断される（Ｓ１４０３）。自局が宛先ノードでない場合、Ｓ１４０４〜Ｓ１４０６の転送処理が実行され、自局が宛先ノードの場合、Ｓ１４０７〜Ｓ１４１１のＲＲＥＰ作成・送信処理が実行される。
【０１１１】
まず、自局が宛先ノードでない場合（Ｓ１４０３の「ＮＯ」）、自局がホットスポットエリア内にいるか否か、換言すれば無線ＬＡＮを利用してインターネットに接続している状態であるか否か、について判断し（Ｓ１４０４）、ホットスポット内にいる場合（Ｓ１４０４の「ＹＥＳ」）、上述のように受信したＲＲＥＱに自局のグローバル通信用識別子と送信端末からのホップ数とを追記する（Ｓ１４０５）。ホットスポット内にいない場合（Ｓ１４０４の「ＮＯ」）、Ｓ１４０５の処理はスキップされ、グローバル通信用識別子はＲＲＥＱに記述されない。
【０１１２】
次いで、ＲＲＥＱは周囲の端末へフラッディングされる（Ｓ１４０６）。これで１回の中継処理が終了し、Ｓ１４０１へ戻る。
【０１１３】
一方、自局が宛先ノードである場合（Ｓ１４０３の「ＹＥＳ」）、受信したＲＲＥＱに基づいてＲＲＥＰを作成し、送信端末へ返信するために、まず、ＲＲＥＱが転送されてきたルートの一部をインターネット経由の経路に置き換えることが可能な否かが判断される（Ｓ１４０７）。具体的には、受信されたＲＲＥＱにグローバル通信用識別子が２以上記述されているか否かが判断される。
【０１１４】
Ｓ１４０７において、「Ｒｈｏｔ」は、受信されたＲＲＥＱ内に記述されていたホットスポットエリア内にいるノードのリストを表し、「Ｎｕｍ（Ｒｈｏｔ）」は、リストＲｈｏｔ内に記述されているノードの数を表す。
【０１１５】
Ｓ１４０７において、受信されたＲＲＥＱにグローバル通信用識別子が２以上記述されているか否かが判断されると（Ｓ１４０７の「ＹＥＳ」）、次いで、ＲＲＥＱが転送されてきたルートの一部をインターネット経由の経路で置き換えるか否かが判断される（Ｓ１４０８）。
【０１１６】
Ｓ１４０８において、「Ｓｕｂ（Ｒｈｏｔ）」は、リストＲｈｏｔ内に記述されている端末のうち最も送信元ノード寄りのものと最も宛先ノード寄りのものとの間のアドホックネットワーク上でのホップ数を表す。これは、図１１から明らかなように、ＲＲＥＱ下段の拡張部分に記述されたホップ数の中で最も大きいものから最も小さいものを引いた差に等しいため、本実施例に係る拡張されたＡＯＤＶプロトコルによれば容易に算出される。
【０１１７】
こうして、Ｓ１４０８においては、受信端末により受信されたＲＲＥＱが経由した経路において最も送信端末寄りでホットスポット内にいる端末から最も受信端末寄りでホットスポット内にいる端末までの経路のホップ数が所定の閾値以上であるか否かが判定されている。
【０１１８】
ここでは、通信品質向上のためなるべくインターネットを経由したいが、しかしながら、端末〜アクセスポイント（ＡＰ）間も無線通信の１ホップとカウントされるため、インターネットへのゲートウェイとなるホットスポットエリア内に在圏した２つの端末がアドホックネットワーク上で近接した位置関係にある場合（例えば、ホップ数＝１の距離にある場合など）にまでわざわざインターネットを経由させる必要はないとの洞察から、上記所定の閾値は例えば「２ホップ」などに設定される。
【０１１９】
換言すれば、本実施例においても、上記実施例１と同様に、所定数以上のホップ数が削減される場合のみ、ルートの一部をインターネットを経由した経路に置き換える。
【０１２０】
このようなＳ１４０８における判定処理において、削減されるホップ数が所定の閾値以上であると判断された場合（Ｓ１４０８の「ＹＥＳ」）、図１１に示したＲＲＥＱから図１３に示したＲＲＥＰを作るように、受信したＲＲＥＱからインターネットを経由した経路を採用したＲＲＥＰが作成される（Ｓ１４０９）。一方、Ｓ１４０８における判定処理において、削減されるホップ数が所定の閾値未満であると判断された場合（Ｓ１４０８の「ＮＯ」）、「グローバル通信用識別子１」及び「グローバル通信用識別子２」の両フィールドが空のＲＲＥＰが作成される（Ｓ１４１０）。ただし、フラグＨにより、インターネットを経由しないルートであることが伝達される。
【０１２１】
当然、そもそも受信したＲＲＥＱに２以上のグローバル通信用識別子が記述されていない場合（Ｓ１４０７の「ＮＯ」）も、Ｓ１４１０においてアドホックネットワークに閉じた経路を示すＲＲＥＰが作成される。
【０１２２】
そして、このようにして作成されたＲＲＥＰは送信端末へ向けてユニキャストで返信される（Ｓ１４１１）。上述のように、フラグＨが立っている場合、この返信もインターネットを経由する。これで１回の経路探索処理が終了し、Ｓ１４０１へ戻る。
【０１２３】
このように、本実施例によれば、アドホックネットワーク内でＲＲＥＱが転送されるというＭＡＮＥＴ内に閉じたルーティング処理でありながら、インターネットに接続している中継ノードは上述のようなグローバル通信用識別子をＲＲＥＱに付加して転送するという特徴を備えたことにより、インターネット上に経路要求を流さずにインターネットを経由したルートも考慮した経路探索が可能となる。
【０１２４】
従来、アドホックネットワーク上での経路探索にはアドホックネットワーク上で経路要求する必要があり、インターネット上での経路探索にはインターネット上で経路要求する必要があったことと比較すれば、本実施例の有益性は明らかである。
【０１２５】
なお、本実施例においては、ＲＲＥＱを受信した受信端末がインターネットを経由するＲＲＥＰを作成するか否かを判断する（図１４のＳ１４０８）際に、受信したＲＲＥＱの転送経路となった端末の中で最も送信端末寄りのホットスポット内の端末と最も受信端末寄りのホットスポット内の端末とをインターネットへのゲートウェイとして利用するものとした。また、インターネットを経由することにより削減されるホップ数が所定の閾値以上であれば必ずインターネットを経由するルートが選択されるものとした。
【０１２６】
この点、理論上は、最も送信端末寄りでないホットスポット内の端末を利用することも、最も受信端末寄りでないホットスポット内の端末を利用することも可能であり、さらに、削減されるホップ数が所定の閾値以上の場合であってもあえて現行通りアドホックネットワーク内に閉じたルーティングを行うことも可能である。
【０１２７】
しかしながら、当業者には既知のように、アドホックネットワークではホップ数が増えるほど通信品質は劣化するため、できる限りアドホックネットワーク内での無線リンクを減らして、インターネットを経由したルートを通った方が通信品質は良好となる。
【０１２８】
したがって、上記実施例のようにできる限りインターネットを経由させようとすることは、好ましい実施形態であると言える。
【実施例３】
【０１２９】
次いで、図１５及び１６を用いて、本発明の更に別の一実施例（実施例３）について説明する。本実施例は、上述の実施例１及び２に共通する変形例であり、採用されるルーティングプロトコルはＤＳＲでもＡＯＤＶでもよい。
【０１３０】
上述の実施例１及び２では、グローバル通信用識別子がＲＲＥＱに付加される以外の点については現行のプロトコルと同様にＭＡＮＥＴ内でのルーティング処理を行い、それにより発見されたルート上においてインターネットによるショートカットが可能であるか否かを判断できるようにし、可能であればインターネットを経由したルートを採用する、という実施形態であった。
【０１３１】
本実施例は、これを更に一歩進めて、インターネットによるショートカットを利用可能なＭＡＮＥＴ内ルートを積極的に探索するものである。
【０１３２】
具体的には、上述の実施例１及び２では、現行のＤＳＲ及びＡＯＤＶと同様に、受信端末（ＲＲＥＱの宛先ノード）に最初に到着したＲＲＥＱだけＲＲＥＰ返信処理の対象となり、遅延して到着したＲＲＥＱは冗長な（すなわち、ホップ数が多い）経路を通って来たものと判断して破棄していたのに対し、本実施例では、ＭＡＮＥＴ内に閉じたルーティングではホップ数が多く、遅延を伴うルートであっても、上述の実施例１又は２に係るようなインターネットを利用したショートカットを利用すれば、ホップ数が削減され、最もホップ数が少ないルートが得られる可能性があることに鑑み、ＲＲＥＱの宛先ノードは、最初のＲＲＥＱ受信後、所定時間、同じ送信元ノードからの他のＲＲＥＱの受信を待機するものとする。
【０１３３】
そして、本実施例では、ＲＲＥＱ受信を上記所定時間待機したＲＲＥＱの宛先ノードは、最初に受信されたＲＲＥＱと該所定時間中に受信された遅延ＲＲＥＱとの中から、上述の実施例１及び２のようにインターネットを利用したショートカットを考慮して、最もホップ数が少ないルートを選択する。
【０１３４】
図１５及び１６に一例を挙げる。ここで、図１５に示すようにアドホック通信端末が点在する通信環境において、送信端末がＲＲＥＱを受信端末へ向けてフラッディングしたとき、ＲＲＥＱが２つの経路（ルート１、ルート２）で受信端末（宛先ノード）へ到達した場合を考える。また、いくつかの中継ノードはホットスポット（ＨＳ）１〜３のエリア内に在圏している。
【０１３５】
各ルートが経由する端末について図１６にまとめる。図１６（ａ）はルート１が経由する端末（ノード）を示し、図１６（ｂ）はルート２が経由する端末（ノード）を示す。図示するように、この例では、ルート２の方がホップ数が多い。したがって、通常であれば、ルート２を経由したＲＲＥＱの方がルート１を経由したものより遅く受信端末に到達するはずである。
【０１３６】
上述のように、現行のルーティングプロトコルでは、このような遅延して到達したＲＲＥＱは破棄されることになるが、本実施例では、上記所定時間内であればこのような遅延したＲＲＥＱもＲＲＥＰ作成の対象となる。
【０１３７】
上記所定時間内にルート２を経由したＲＲＥＱのみが受信されたものとすると、受信端末は、次に、最初に受信されたルート１（図１６（ａ））経由のＲＲＥＱと、ルート２（図１６（ｂ））経由のＲＲＥＱとを比較し、ホップ数が少ない方を選択する段階となる。
【０１３８】
ただし、本例では、ルート２上にはホットスポットエリア内に位置する中継ノードが２つ以上存在するため、受信端末は、上述の実施例１及び２のようなショートカットを利用することができる、と判断することができる。
【０１３９】
図１５に示す例では、ルート２上で、最も送信端末寄りのホットスポットエリア内に位置するノードは端末Ｂであり、最も受信端末寄りのホットスポットエリア内に位置するノードは端末Ｍであることから、図１６（ｂ）に示したルート２は、上述の実施例１及び２のような手法を利用して端末Ｂ〜端末Ｍ間をインターネットによるショートカットさせることにより、図１６（ｃ）に示すようなルート２’とすることができる。
【０１４０】
すると、図示するように、図１６（ｃ）に示すインターネットを利用したルート２’では、図１６（ｂ）に示すＭＡＮＥＴ内に閉じたルート２に比して、ホップ数を２ホップ削減することができることがわかる。
【０１４１】
したがって、本例において、受信端末は、ルート１（図１６（ａ））のホップ数と、ルート２’（図１６（ｃ））のホップ数とを比較して、ホップ数のより少ないルート２’をＲＲＥＰ経路に優先的に選択することができる
このように、本実施例では、受信端末（宛先ノード）が従来は破棄していた遅延したＲＲＥＱを含めて積極的にインターネットによるショートカットが可能なルートを探索することができるため、より少ないホップ数のルートを優先的に経路として使用することができる。
【０１４２】
なお、本実施例において、上記所定時間は、原則として任意に定めることができるが、経路探索に要する時間が過度に長くならないように、適度な時間長に設定されるべきである。
【０１４３】
例えば、最初に受信されたＲＲＥＱの経路のホップ数に基づいて、遅延した宛先ノードに到達したＲＲＥＱのＭＡＮＥＴ内に閉じたルートのホップ数が最初に受信されたＲＲＥＱ経路のホップ数の所定数分の１のホップ数以内であれば許容するようにしてもよく、或いは、最初に受信されたＲＲＥＱの経路のホップ数とは無関係に、予め設定された所定ホップ数までの遅延を許容してもよい。
【０１４４】
また、ホップ数ではなく遅延時間を基準とし、最初にＲＲＥＱから受信されてから所定時間だけ待機するようにしてもよい。または、受信端末は最初に受信されたＲＲＥＱが送信端末により送信されてから受信端末により受信されるまでに要した時間のプラス所定パーセントまでの時間が経過するまで待機するようにしてもよい。ただし、この場合、送信端末がＲＲＥＱ送信時にＲＲＥＱに送信時刻をタイムスタンプすることが必要となる。
【０１４５】
また、常に上記所定時間待機するものとせず、例えば、該所定期間の途中でグローバル通信用識別子を２つ以上含んだ（すなわち、インターネットによるショートカットが可能な経路を持つ）ＲＲＥＱが受信されたときには、その時点で遅延したＲＲＥＱの受信待機を中止するようにしてもよい。
【０１４６】
また、ここでは、受信端末は、最初にＲＲＥＱが受信されてから所定時間他のＲＲＥＱの受信を待機するものとし、受信された１以上のＲＲＥＱの中から最もホップ数が少ないルートをＲＲＥＰ返信対象に選択するものとしたが、ホップ数に代えて又は加えて、通信帯域や遅延時間などのパラメータを考慮してルートを選択してもよい。これは、例えば、ＰＩＮＧコマンドを利用してスループットやＲＴＴ（Ｒｏｕｎｄ Ｔｒｉｐ Ｔｉｍｅ）などを測定することにより得られる。
【０１４７】
さらに、本実施例の好ましい変形例として、インターネットによるショートカットが可能なルートをより積極的に探索するために、宛先ノードが遅延したＲＲＥＱを待機するだけでなく、各中継ノードがＲＲＥＱを転送する際に処理済みのＲＲＥＱであってもグローバル通信用識別子を含んだＲＲＥＱについては破棄せずに、最初に受信されたＲＲＥＱと同様に転送処理を行うようにしてもよい。これにより、インターネットによるショートカットが可能なルートを経由したＲＲＥＱが受信端末に到達する可能性を高めることができ、インターネット経由の経路の利用を促進することができる。
【０１４８】
以上、本発明の実施例１〜３について具体例を挙げながら説明した。しかしながら、ここに説明及び図示した実施例はあくまで例示に過ぎず、本発明はこれらに限定されるものではない。
【０１４９】
例えば、上記実施例１〜３では、アドホックネットワークの無線リンクよりも通信品質が良いと想定される有線網の一例としてインターネットを挙げたが、本発明はこれに限られず、インターネット以外の有線網を利用することも当然可能である。
【０１５０】
また、上記実施例１〜３では、各端末が有線網へ無線ＬＡＮを利用して有線網に接続するものとしたが、本発明はこれに限られず、例えばＤＳＲＣ（ｄｅｄｉｃａｔｅｄ ｓｈｏｒｔ ｒａｎｇｅ ｃｏｍｍｕｎｉｃａｔｉｏｎ；挟域通信）などの他の通信規格を利用することも当然可能である。
【０１５１】
また、上記実施例１〜３では、ＲＲＥＱパケット構成などをリアクティブ型のルーティングプロトコルであるＤＳＲ又はＡＯＤＶが用いられるものとして説明したが、本発明はこれらに限定されるものではなく、他のリアクティブ型プロトコルであっても、或いは、プロアクティブ型プロトコルであっても、利用することができる。
【０１５２】
プロアクティブ型のルーティングプロトコルが用いられる場合、各ノード区間の経路情報が常にやりとりされているため、各端末はホットスポットエリア内に位置する端末まで何ホップの距離にあるかを把握している。そこで、プロアクティブ型ルーティングプロトコルが用いられる場合には、上記実施例１〜３の変形例として、各端末が、自局がホットスポットエリア内に位置すれば上記実施例１〜３と同様に自局のグローバル通信用識別子をＲＲＥＱに追記すると共に、自局がホットスポットエリア内に位置しなければ自局が持つ周辺ノード情報から自局からも最も近いホットスポットエリア内に位置する端末に到達するまでのホップ数をＲＲＥＱに追記するようにしてもよい。これにより、インターネットによるショートカット可能なルートをより一層積極的に探索することができる。
【０１５３】
また、上記実施例１〜３では、一部の中継ノードがホットスポットエリア内に位置する場合について述べたが、上記説明を読んだ当業者には明らかなように、本発明はＲＲＥＱ送信元ノード及び／又はＲＲＥＱ宛先ノードがホットスポットエリア内に位置する場合にも等しく適用することが可能である。ただし、当業者には明らかなように、送信元ノードがホットスポットエリア内に位置する場合であっても、当然、ＲＲＥＱはＭＡＮＥＴ内のみにフラッディングされる。
【０１５４】
また、現行のルーティングプロトコルでは、ノードの移動や電源オフなどによりルートが切れた場合に再度経路探索が行われるようになっているが、本発明においては、いずれの実施例及び変形例においても、ルート切れの場合に加えて、更に、送信元ノード、ルートに選ばれた中継ノード、及び宛先ノードのいずれかがホットスポットエリア内に入ったとき及びホットスポットエリアから外へ出たときにも経路が再探索されることが好ましい。なぜなら、新たなインターネットを利用した経路により、ホップ数を更に削減して通信品質を向上させることが可能となる可能性があるためである。
【０１５５】
また、本発明の適用に合わせたインフラ側の工夫として、アドホックネットワークによってインターネットを利用したショートカットに頻繁に利用されるホットスポットエリア（のＡＰ）間をトンネリング（ｔｕｎｎｅｌｉｎｇ）やＶＰＮ（Ｖｉｒｔｕａｌ Ｐｒｉｖａｔｅ Ｎｅｔｗｏｒｋ；仮想閉域網）などの技術を利用して仮想上一体化しても有益的である。これにより、一方のホットスポットエリア内でブロードキャストされたＲＲＥＱは他方のホットスポットエリア内にもブロードキャストされたことになり、ＭＡＮＥＴ内端末識別子の処理のみで有線網を利用したショートカットが可能となる。
【０１５６】
さらに、上記実施例及び変形例においては、ルーティング判定の指標としてホップ数を例に挙げたが、当業者には明らかなようにこれは一例に過ぎず、例えば通信帯域や遅延時間などの通信品質に関連する指標などの他の指標を用いてルーティングの判定を行うことも可能である。
【産業上の利用可能性】
【０１５７】
本発明は、アドホックネットワークに利用できる。上述のように、用いられるルーティングプロトコルは問わない。
【０１５８】
また、アドホック通信端末の種類も問わない。ノードとなる端末は、携帯電話であってもよく、ＰＤＡ（Ｐｅｒｓｏｎａｌ Ｄｉｇｉｔａｌ Ａｓｓｉｓｔａｎｔ；携帯情報端末）であってもよく、又は、車両に搭載された通信装置であってもよい。
【０１５９】
複数の車両に搭載された通信装置により車車間通信としてアドホックネットワークが構築されている場合、特に本発明に係るルーティング方法を適用すると有益的である。
【０１６０】
車車間通信の場合、ノードとなる各車両は、ほぼ道路上のみに存在すると言えるため、ルートが探索しやすい。また、車両運転中は、数ｋｍ前方の交通状況・道路状況を知りたい、というニーズがあると考えられるため、一時的にアドホックネットワークを張って情報を収集する、といった使い方が考えられる。
【０１６１】
さらに、本発明を車車間通信に適用した場合の最大の利点の１つは、交差点をホットスポットにすることによって、任意の交差点まで有線網によってショートカットできる点である。これは、例えば交差点に設置された信号機や一時停止の標識などに付随して例えば無線ＬＡＮのビーコンを送出するＡＰを設置することによって、比較的容易に、多くのノードの滞在・通過が見込めるエリア（交差点近傍）を確実にホットスポットエリアとすることができ、本発明に係るルーティングを利用した通信品質向上の促進が見込まれる。
【図面の簡単な説明】
【０１６２】
【図１】アドホック通信端末が点在し、一部の端末がホットスポットエリア内にいる通信環境の一例を示す図である。
【図２】本発明の一実施例におけるアドホック通信端末の概略構成図である。
【図３】本発明の一実施例においてＲＲＥＱを中継するノードによってＲＲＥＱに追記される自局情報を示す図である。
【図４】図１の通信環境においてＲＲＥＱが送信端末から受信端末へ到達した際に経由した経路の一例を示す図である。
【図５】現行ＤＳＲプロトコルに準拠し、図４の経路において受信端末に到達したＲＲＥＱに記述された経路情報を示す図である。
【図６】本発明の一実施例により拡張されたＤＳＲプロトコルに準拠し、図４の経路において受信端末に到達したＲＲＥＱに記述された経路情報を示す図である。
【図７】本発明の一実施例により拡張されたＤＳＲプロトコルに準拠し、図６のＲＲＥＱに対して作成されたＲＲＥＰに記述された経路情報を示す図である。
【図８】図４の場合に、現行ＤＳＲプロトコルにより確立されるルートと、本発明の一実施例により拡張されたＤＳＲプロトコルにより確立されるルートとを比較する図である。
【図９】本発明の一実施例において各端末において行われる受信したＲＲＥＱに対する処理の流れを示すフローチャートである。
【図１０】本発明の別の一実施例により拡張されたＡＯＤＶプロトコルに準拠したＲＲＥＱのパケット構造を示す図である。
【図１１】本発明の別の一実施例により拡張されたＡＯＤＶプロトコルに準拠し、図４の経路において受信端末に到達したＲＲＥＱのパケット構造を示す図である。
【図１２】本発明の別の一実施例により拡張されたＡＯＤＶプロトコルに準拠したＲＲＥＰのパケット構造を示す図である。
【図１３】本発明の別の一実施例により拡張されたＡＯＤＶプロトコルに準拠し、図４の経路において受信端末により返信されるＲＲＥＰのパケット構造を示す図である。
【図１４】本発明の別の一実施例において各端末において行われる受信したＲＲＥＱに対する処理の流れを示すフローチャートである。
【図１５】ＲＲＥＱが送信端末から受信端末へ到達した際に経由した２つの経路の一例を示す図である。
【図１６】図１５の場合に、現行のルーティングプロトコルにより確立されるルートと、本発明の更に別の一実施例に係るルーティングプロトコルにより確立されるルートとを比較する図である。
【符号の説明】
【０１６３】
２００ アドホック通信端末
２０１ 送受信部
２０２ パケット転送部
２０３ ルーティングテーブル
２０４ ルーティング用パケット処理部
２０５ アドレス格納部
【技術分野】
【０００１】
本発明は、概して、アドホックネットワークにおけるルーティング方法に係り、特に、スループットの向上及び無線リソースの消費抑制が図られたルーティング方法に関する。
【背景技術】
【０００２】
従来、基地局や固定局を使わずに、端末間でホッピング（中継）することにより、データ伝送を可能とするアドホックネットワーク（或いは、マルチホップ無線ネットワーク、又は、Ｍｏｂｉｌｅ Ａｄ−ｈｏｃ Ｎｅｔｗｏｒｋ；ＭＡＮＥＴ）が知られている。
【０００３】
アドホックネットワークでは、すべての端末によって自律的にネットワークが構築されるため、基地局等の設置が不要となり、柔軟性が高く、設置の容易なネットワーク構築が可能となる。
【０００４】
アドホックネットワークにおいて用いられるルーティングプロトコル（経路制御プロトコル）については、ＩＥＴＦ（Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ）のＭＡＮＥＴワーキンググループ（ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｈｔｍｌ．ｃｈａｒｔｅｒｓ／ｍａｎｅｔ−ｃｈａｒｔｅｒ．ｈｔｍｌ）から種々のものが提案・公開されており、標準化が進められている。
【０００５】
現在、提案・公開されているルーティングプロトコルは、大きく分けるとリアクティブ（Ｒｅａｃｔｉｖｅ）型、プロアクティブ（Ｐｒｏａｃｔｉｖｅ）型、及び、これらのハイブリッド（複合）型、に分けられる。
【０００６】
リアクティブ型のルーティングプロトコルは、実際にデータを送信する際に初めて起動し、周りにある通信可能な端末の電波を送受信して確かめてからルート構築を行うものであり、代表的なものとしては、「Ａｄｈｏｃ Ｏｎ Ｄｅｍａｎｄ Ｄｉｓｔａｎｃｅ Ｖｅｃｔｏｒ（ＡＯＤＶ）」（Ｅｘｐｅｒｉｍｅｎｔａｌ ＲＦＣ ３５６１）や、「Ｄｙｎａｍｉｃ Ｓｏｕｒｃｅ Ｒｏｕｔｉｎｇ（ＤＳＲ）」（Ｉｎｔｅｒｎｅｔ Ｄｒａｆｔ；有効期限２００５年１月１９日）などが挙げられる。
【０００７】
プロアクティブ型のルーティングプロトコルは、任意の時間間隔ごとにルーティング可能な端末を確かめており、常にルートが構築されていて通信可能状態となっているものであり、代表的なものとしては、「Ｏｐｔｉｍｉｚｅｄ Ｌｉｎｋ Ｓｔａｔｅ Ｒｏｕｔｉｎｇ（ＯＬＳＲ）」（Ｅｘｐｅｒｉｍｅｎｔａｌ ＲＦＣ ３６２６）や、「Ｔｏｐｏｌｏｇｙ Ｂｒｏａｄｃａｓｔ ｂａｓｅｄ ｏｎ Ｒｅｖｅｒｓｅ−Ｐａｔｈ Ｆｏｒｗａｒｄｉｎｇ（ＴＢＲＰＦ）」（Ｅｘｐｅｒｉｍｅｎｔａｌ ＲＦＣ ３６８４）などが挙げられる。
【０００８】
すなわち、リアクティブ型プロトコルではデータを送信する際にどの端末を通ってデータをリレーさせるのかが決定されるのに対し、プロアクティブ型プロトコルでは予め決定されているリレーの順番に従ってデータが送信される。前者は各端末における電池効率の点で有利であり、後者は通信タイムアウトや送信データロスが少ないという利点を有する。
【０００９】
また、このような標準化への取り組みとは別に、アドホックネットワークにおける独自のパケットルーティング方法も提案されている（例えば、特許文献１参照）。
【００１０】
さらに、アドホックネットワークとインターネットなどの有線インフラを組み合わせて利用する際のルーティング等に関する技術も提案されている（例えば、特許文献２〜４参照）。
【特許文献１】特開平１１−２３９１７６号公報
【特許文献２】特開２００２−３５４０１６号公報
【特許文献３】特開２００３−２３０１６７号公報
【特許文献４】特開２００４−２４８１８０号公報
【発明の開示】
【発明が解決しようとする課題】
【００１１】
周知の通り、アドホックネットワークでは、ホップ数が増えるほど、すなわち経由する端末（ノード）が増えるほど、通信品質は劣化する傾向となる。
【００１２】
本願発明者らは、アドホックネットワークにおいて、あるルートの中継局となっているアドホック通信端末の中に例えば無線ＬＡＮなどを利用して例えばインターネットなどの有線網に接続可能なものが２つ以上存在する場合、ルートの一部を有線網経由の経路に置き換えることによって、通信品質を大幅に改善できることに着目した。
【００１３】
この点、上述のＩＥＴＦ−ＭＡＮＥＴ−ＷＧにより提案・公開されている種々のルーティングプロトコル及び上記特許文献１記載のルーティング方法はいずれも、アドホックネットワーク内に閉じたルーティングを行うものであり、アドホックネットワークと同時にインターネットなどの有線網を利用することへ拡張されていない。
【００１４】
また、上記特許文献２記載の方法は、インターネットに接続されたノードがアドホックネットワーク内に入ったときにインターネット経由でルーティングしないようにするためのものであり、アドホックネットワークと同時にインターネットなどの有線網を利用するものではない。
【００１５】
また、上記特許文献３記載の方法は、アドホックネットワークを介してインターネットへ接続する通信において、インターネットへの接続先として関門（ゲートウェイ）となる端末を探索するものであるが、アドホック通信端末同士のルートの一部にインターネットを利用するものではない。また、この従来方法に従ってアドホック端末同士を接続した場合、必ずインターネットを経由した通信経路となり、端末同士が近接している場合であってもアドホック通信ができなくなってしまう。
【００１６】
さらに、上記特許文献４記載の方法は、複数の無線通信メディアの中から通信状況に応じていずれかを選択するものであるが、選択されるのはルート全体に利用される通信メディアであって、アドホックネットワークにおいてルートの一部をインターネットなどの有線網経由の経路に置き換えるものではない。
【００１７】
このように、従来提案されているアドホックネットワークにおけるルーティング方法では、アドホックネットワークにおいて、あるルートの中継局となっているアドホック通信端末の中に有線網と接続可能なものが２つ以上あったとしても、ルートの一部を有線網経由の経路で置き変えたルーティングを実現させることはできない。
【００１８】
仮に、例えばＩＥＴＦ−ＭＡＮＥＴ−ＷＧにおいて提案・公開されているルーティングプロトコルをそのまま用いて、有線網を経由したルートまで含めたルート探索を行おうとすれば、ブロードキャストされたルートリクエスト（ＲＲＥＱ）を受信した端末が有線網と接続している場合、ＲＲＥＱがアドホックネットワーク内だけでなく有線網内にもブロードキャストで転送されるといった構成になりかねない。そのような事態は、有線網の通信トラフィックに甚大な被害を与えかねず、実施不可能である。
【００１９】
本発明はこのような課題を解決するためのものであり、アドホックネットワークにおいて、アドホックネットワーク内に閉じたパケット伝送のみによって、アドホックネットワーク内に閉じたルートだけでなく、ルートの一部を有線網経由の経路で置き換えたルートをも探索可能とすることによって、従来方法に比してスループットを向上させ、無線リソースの消費を抑制することが可能なルーティング方法を提供することを主たる目的とする。
【課題を解決するための手段】
【００２０】
上記目的を達成するための本発明の第一の態様は、アドホックネットワーク（ＭＡＮＥＴ）におけるルーティング方法であって、ルートリクエスト（ＲＲＥＱ）を送信又は転送するノードは、自局が外部の有線網と通信接続している場合、該有線網における自局の識別子を上記ルートリクエストに付加して送信又は転送する、アドホックネットワークにおけるルーティング方法である。
【００２１】
この第一の態様において、上記外部の有線網とは例えばインターネットなどである。その場合、アドホック通信端末（ノード）が、例えば無線ＬＡＮ機能を備え、例えばホットスポット（ｈｏｔｓｐｏｔ）エリア内に在圏するとき、そのノードはアドホックネットワーク内に閉じたアドホック通信もインターネットを経由した通信も可能となる。
【００２２】
この第一の態様によれば、ルートリクエストを受信した宛先ノード（送信先ノード）は、経路中に有線網に接続しているノードが存在するか否か及び存在する場合何台存在するのかを知ることができる。
【００２３】
また、このルートリクエストの送信・転送は、アドホックネットワーク内に閉じて行われるものであり、ルートリクエストの宛先ノードは、上記有線網で何らパケット伝送を行うことなく、すなわち該有線網上の通信トラフィックに影響を与えることなく、該有線網を利用する場合の各ノードの識別子を取得することができる。
【００２４】
上記目的を達成するための本発明の第二の態様は、上記第一の態様において、上記ルートリクエストの宛先ノードは、受信したルートリクエストに２以上の上記有線網における識別子が含まれていた場合、これら２以上の識別子のうちルート上最も送信元ノードに近いノードを表す１つの識別子と最も宛先ノードに近いノードを表す１つの識別子とを用いて、これら２つの識別子が表すノード間は上記有線網を経由する経路を採用したルートリプライ（ＲＲＥＰ）を作成する、アドホックネットワークにおけるルーティング方法である。
【００２５】
この第二の態様によれば、アドホック通信経路の一部がアドホックネットワークにおける無線リンクよりも良好な通信品質が見込める有線網を経由した経路で置き換えられるため、アドホックネットワーク内のみを通る経路を採用した場合に比して通信品質が向上する。
【００２６】
上記目的を達成するための本発明の第三の態様は、上記第二の態様において、上記ルートリクエストの宛先ノードは、アドホックネットワーク内のみでルーティングした場合に上記２つの識別子が表すノード間に所定数（例えば２ホップ）以上のホップ数が存在する場合のみ、これら２つの識別子が表すノード間は上記有線網を経由する経路を採用したルートリプライを作成する、アドホックネットワークにおけるルーティング方法である。
【００２７】
この第三の態様によれば、近接した（例えばホップ数が１の距離にある）ノード間の無線リンクが有線網に置き換えられてしまうことが防止されるため、ホップ数削減の効果が十分に得られる場合のみ、有線網が利用されるようにすることができる。
【００２８】
上記目的を達成するための本発明の第四の態様は、上記第三の態様において、ルートリクエストの宛先ノードは、最初のルートリクエストを受信してから所定期間、他の経路を経由した同じ送信元ノードからのルートリクエストの受信を待機し、上記所定期間内に同じ送信元ノードから１以上のルートリクエストが受信された場合、上記最初のルートリクエスト及び前記所定期間中に受信されたルートリクエストのうち２以上の上記有線網における識別子が含まれているルートリクエストについてはこれら２つの識別子が表すノード間は上記有線網を経由するものとして、各ルートリクエストの経路のホップ数を比較し、最もホップ数が少ない経路を有するルートリクエストに対してルートリプライを作成する、アドホックネットワークにおけるルーティング方法である。
【００２９】
従来、最初に宛先ノードによって受信されたルートリクエスト以外の遅延して到着したルートリクエストは冗長な経路を通っているものと判断されて破棄されていたが、この第四の態様によれば、アドホックネットワーク内に閉じたルートでは最小ホップ数でなかったルートが上記第三の態様のように経路の一部を有線網でショートカットすることによって最小ホップ数のルートとなる可能性があることに鑑み、遅延して宛先ノードに到着したルートリクエストであってもＲＲＥＰ返信候補に取り上げることによって、有線網を利用して通信品質を向上させる機会を増やすことができる。
【００３０】
上記目的を達成するための本発明の第五の態様は、上記第四の態様において、ルートリクエストの宛先ノードは、２以上の上記有線網における識別子が含まれているルートリクエストが受信されたときに上記他の経路を経由した同じ送信元ノードからのルートリクエストの受信の待機を終了する、アドホックネットワークにおけるルーティング方法である。
【００３１】
この第五の態様によれば、経路の一部を有線網を経由する経路に置き換えることによるショートカットが可能なルートを示すルートリクエストが１つでも受信された段階で、当該ルートリクエストを選択することによってホップ数の削減が見込めると判断し、上記所定待機時間を速やかに終了させるため、ルートリプライをより迅速に作成することができる。
【００３２】
上記目的を達成するための本発明の第六の態様は、上記第四又は第五の態様において、受信したルートリクエストを転送するノードは、受信したルートリクエストに上記有線網における識別子が含まれている場合、その受信したルートリクエストが既に転送済みのルートリクエストであっても破棄せずに初めて受信したルートリクエストと同様に転送する、アドホックネットワークにおけるルーティング方法である。
【００３３】
従来、既に転送済みのルートリクエストを受信したノードはそのルートリクエストを破棄していたが、この第六の態様によれば、アドホックネットワーク内に閉じたルートでは最小ホップ数でなかったルートが上記第三の態様のように経路の一部を有線網でショートカットすることによって最小ホップ数のルートとなる可能性があることに鑑み、既に転送済みのルートリクエストであっても有線網における識別子を含み、有線網を利用したショートカットが実現される可能性があるルートリクエストについては破棄せずに再度転送することによって、有線網を利用して通信品質を向上させる機会を増やすことができる。
【００３４】
上記目的を達成するための本発明の第七の態様は、上記第四乃至第六の態様のいずれかにおいて、各ノードは、自局周辺の上記有線網と通信接続しているノードを探索し、存在する場合、ルートリクエストを送信又は転送する際に自局からその自局周辺の上記有線網と通信接続しているノードまでのホップ数を該ルートリクエストに付加する、ことを特徴とするアドホックネットワークにおけるルーティング方法である。
【００３５】
この第七の態様によれば、このようなルートリクエストを受信した宛先ノードは、ルートリクエストが転送されてきた経路中に有線網へ接続しているノードがない場合であっても、有線網へ接続可能なノードまでのホップ数を知ることができるため、有線網を経由した場合のホップ数を知ることができる。よって、アドホックネットワーク内では冗長なルートも含めて、有線網によるショートカットを利用した場合に最もホップ数が少なくなるルートを探索することができる。
【００３６】
なお、ここでは、ルーティング判定の指標としてホップ数を例に挙げたが、当業者には明らかなようにこれは一例に過ぎず、例えば通信帯域や遅延時間などの通信品質に関連する指標などの他の指標を用いてルーティングの判定を行うことも可能である。
【発明の効果】
【００３７】
本発明によれば、アドホックネットワークにおいて、経路の一部を積極的に有線網経由の経路に置き換えることによってホップ数の削減を図ることができるため、スループットなどの通信品質の向上及び無線リソースの消費抑制が図られたルーティング方法を提供することができる。
【発明を実施するための最良の形態】
【００３８】
以下、本発明を実施するための最良の形態について、添付図面を参照しながら実施例を挙げて説明する。なお、アドホックネットワークの基本概念については当業者には既知であるため、詳しい説明を省略する。
【実施例１】
【００３９】
まず、図１〜９を用いて、本発明の一実施例（実施例１）に係るルーティング方法について説明する。本実施例では、ルーティングプロトコルとしてＤＳＲが用いられることを前提し、図１に示すようなアドホック通信端末が点在する通信環境において、送信端末が受信端末へデータを送信するために経路探索（ルートディスカバリー）を実行する場合を考える。
【００４０】
また、本実施例において、各通信端末は、アドホック通信が可能であると共に、ホットスポットエリア内にいるときには無線ＬＡＮを利用してインターネットに接続する能力を有するものとする。図１に例示した通信環境では、端末Ｂ及びＣがホットスポット（ＨＳ）１内に位置し、端末Ｇ及びＪがホットスポット（ＨＳ）２内に位置し、端末Ｉ、Ｋ、及びＭがホットスポット（ＨＳ）３内に位置している。
【００４１】
本実施例は、これらインターネットに接続した端末を利用して、アドホックネットワーク内に閉じたルーティング処理によって、インターネットを経由する経路も考慮した経路探索を可能にする。
【００４２】
図２は、各アドホック通信端末の概略構成を示す。
【００４３】
端末２００は、無線機である送受信部２０１と、受信したパケットを転送するか否かを判断するパケット転送部２０２とを有する。
【００４４】
また、端末２００は、ルーティングのための経路表（ルーティングテーブル）２０３を有する。ルーティングテーブルは、各端末に記憶されており、宛先とその宛先へパケットを届けるために送り出す転送先の組（ペア）を表にした参照テーブルである。パケット転送部２０２は、自局宛でないパケットを受信したとき、ルーティングテーブル２０３を参照して、宛先に適したノードへ転送する。
【００４５】
また、端末２００は、ルートリクエスト（ＲＲＥＱ）及びルートリプライ（ＲＲＥＰ）を処理するルーティング用パケット処理部２０４と、各端末（ノード）の識別子（アドレス）を格納したアドレス格納部２０５とを有する。
【００４６】
本実施例は、現行のＤＳＲプロトコルを拡張するものであり、以下に特段の説明がない点については通常のＤＳＲプロトコルに準拠して処理される。
【００４７】
本実施例において追加・拡張された主たる点は、ルーティング用パケット処理部２０４の機能である。現行のＤＳＲプロトコルによれば、ルーティング用パケット処理部２０４は、ＲＲＥＱを中継する際、受信されたＲＲＥＱに自局のアドホックネットワーク内での識別子（ＭＡＮＥＴ内端末識別子）を追記してパケット転送部２０２へ渡し、パケット転送部２０２がこれを転送する。
【００４８】
本実施例において、ルーティング用パケット処理部２０４は、更に、無線ＬＡＮ通信機能を備え、ホットスポットのアクセスポイント（ＡＰ）が送出しているビーコンを検出し、自局がホットスポットエリア内に位置するか否かを判断する。そして、自局がホットスポットエリア内に位置すると判断した場合、上記ＭＡＮＥＴ内端末識別子に加えて、インターネット上における自局の識別子（グローバル通信用識別子）をＲＲＥＱに追記する。グローバル通信用識別子が追記されたＲＲＥＱは、通常のＲＲＥＱと同様、アドホックネットワーク内だけでフラッディングされ、インターネット上へは送出されない。
【００４９】
追記される情報を図３に示す。図３（ａ）は、端末がホットスポットエリア内に位置する場合に中継するＲＲＥＱに追記される自局情報であり、図３（ｂ）は、端末がホットスポットエリア内に位置しない場合に中継するＲＲＥＱに追記される自局情報である。
【００５０】
ここで、ＭＡＮＥＴ内端末識別子は、例えば、ＭＡＣアドレスやＩＰアドレスなどであり、グローバル通信用識別子は、例えば、ＩＰアドレスである。ＭＡＮＥＴ内端末識別子とグローバル通信用識別子とは、例えば、識別子（アドレス）の割り当て空間を別にする、或いは、専用のフラグ（１ビット）を設け、グローバル通信用識別子が追記された場合にはこのフラグを立てる、などにより区別することができる。
【００５１】
このように、本実施例に係る拡張によれば、経路探索時に、中継ノードがホットスポットエリア内にいれば、ＲＲＥＱに追記される情報が増えるが、これは経路探索時のみであり、ルート確立後のデータ送信では特段の追加的情報が付加されない。
【００５２】
ＲＲＥＱの中継に関して、その他の点は現行のＤＳＲに準拠する。すなわち、送信端末からブロードキャストされたＲＲＥＱは、周囲の端末によって受信される。各端末は、受信したＲＲＥＱの宛先が自局でなければ、上述のような自局情報を追記した上で、ＲＲＥＱをブロードキャストする。このような転送・中継が繰り返され、最終的に受信端末に到達する。
【００５３】
また、ある端末から転送されたＲＲＥＱが転送先ノードによる転送によって再度戻ってきて最初の端末により受信される場合が当然生じるが、「ＲＲＥＱに記述された経路情報に自局が含まれている場合、そのＲＲＥＱは破棄する」というＤＳＲプロトコルのルールによって、そのＲＲＥＱは処理済みとして破棄される。
【００５４】
図４は、図１に例示した通信環境において、ＲＲＥＱが送信端末から受信端末へ到達した際に経由した経路の一例を示している。
【００５５】
ＲＲＥＱがこのようなルートを通った場合、現行のＤＳＲプロトコルによれば、受信端末により受信されたＲＲＥＱには図５に示すような経路情報が記述されている。この経路情報から、このＲＲＥＱは、送信端末から、端末Ｂ、端末Ｃ、端末Ｆ、端末Ｉ、端末Ｋ、及び、端末Ｍを順に経由して受信端末に届いたことがわかる。
【００５６】
一方、本実施例によれば、上述のようにＤＳＲプロトコルが拡張されているため、受信端末により受信されたＲＲＥＱには図６に示すような経路情報が記述されていることになる。図示するように、ホットスポットエリア内に位置する端末Ｂ、端末Ｃ、端末Ｉ、端末Ｋ、及び端末Ｍに関しては、ＭＡＮＥＴ内端末識別子だけでなく、グローバル通信用識別子も記述されている。
【００５７】
ＲＲＥＱは様々な経路でそのＲＲＥＱの宛先ノードである受信端末に到達するが、受信端末は、最初に到達したＲＲＥＱが最もホップ数が少ない最短のルートを経由していると判断して、その最初に受信したＲＲＥＱに基づいてＲＲＥＰを作成し、送信端末にユニキャスト送信する。現行のＤＳＲプロトコルによれば、図５に示したようなＲＲＥＱを最初に受信した受信端末はこの経路を選択し、この経路情報を記述されたＲＲＥＰを作成して送信端末にユニキャストする。このＲＲＥＰは、図５のＲＲＥＱに記述された経路を逆にたどって転送されながら送信端末に到達する。
【００５８】
一方、本実施例に係るルーティング方法によれば、図６に示すようなＲＲＥＱを最初に受信した受信端末（＝ＲＲＥＱの宛先ノード）は、グローバル通信用識別子が記述された端末の中で最も送信端末に近いもの（ここでは端末Ｂ）と最も受信端末に近いもの（ここでは端末Ｍ）とをそれぞれ抽出し、それらのグローバル通信用識別子を利用してそれらノード間はインターネットを経由する経路を通るＲＲＥＰを作成する。
【００５９】
図６に示すＲＲＥＱの場合、受信端末で作成されるＲＲＥＰは図７のようになる。この図７に示すＲＲＥＰは、送信端末〜端末Ｂ間はアドホックネットワークを経由し、端末Ｂ〜端末Ｍ間はインターネットを経由し、更に、端末Ｍ〜受信端末間はアドホックネットワークを経由した経路が選択されたことを意味する。
【００６０】
この本実施例に係るＲＲＥＰも、現行プロトコルと同様、記述された経路を逆にたどって送信端末にユニキャストされる。したがって、端末Ｍから端末Ｂへの転送にはインターネットが利用される。このＲＲＥＰの転送はブロードキャストであるＲＲＥＱとは異なりユニキャストであるため、インターネットを経由しても負荷は問題とならない。
【００６１】
このように、本実施例によれば、インターネットはアドホックネットワークの無線リンクに比して十分に太く、通信品質が良いという洞察を前提として、アドホックネットワークにおいて探索・確立されるルートの一部をインターネットを経由したルートとすることができる。
【００６２】
また、インターネットを経由することにより、いくつかの中継ノードがショートカットされるため、ルート全体でのホップ数の削減も見込める。図８は、現行のＤＳＲプロトコルにより確立されるルートと本実施例により確立されるルートとを比較するものであり、図８（ａ）は図５に示したＲＲＥＱ及びＲＲＥＰ経路情報を示し、図８（ｂ）は図７に示したＲＲＥＰ経路情報を示す。図示するように、端末Ｂ〜端末Ｍ間をインターネットを経由したルートとすることによって、この場合、ホップ数が２ホップ短縮される。
【００６３】
以上のような本実施例に係るルーティング方法について、図９を用いてより詳細に説明する。図９は、本実施例において各端末において行われる受信したＲＲＥＱに対する処理の流れを示すフローチャートである。
【００６４】
まず、各端末はＲＲＥＱの受信を待機する（Ｓ９０１）。
【００６５】
ＲＲＥＱが受信されると（Ｓ９０１の「ＹＥＳ」）、受信したＲＲＥＱに記述された経路情報に自局の情報が含まれているか否かを判断する（Ｓ９０２）。含まれている場合（Ｓ９０２の「ＹＥＳ」）、処理済みのＲＲＥＱであるものと判断して、そのＲＲＥＱを破棄する（Ｓ９１２）。
【００６６】
受信したＲＲＥＱの経路情報に自局が含まれていない場合（Ｓ９０２の「ＮＯ」）、次いで、そのＲＲＥＱの宛先ノードが自局であるか否かが判断される（Ｓ９０３）。自局が宛先ノードでない場合、Ｓ９０４〜Ｓ９０７の転送処理が実行され、自局が宛先ノードの場合、Ｓ９０８〜Ｓ９１１のＲＲＥＰ作成・送信処理が実行される。
【００６７】
まず、自局が宛先ノードでない場合（Ｓ９０３の「ＮＯ」）、従来通り、ＲＲＥＱに自局のＭＡＮＥＴ内端末識別子を追記する（Ｓ９０４）。そして、更に、自局がホットスポットエリア内にいるか否か、換言すれば無線ＬＡＮを利用してインターネットに接続している状態であるか否か、について判断し（Ｓ９０５）、ホットスポット内にいる場合（Ｓ９０５の「ＹＥＳ」）、上述のように受信したＲＲＥＱに更に自局のグローバル通信用識別子も追記する（Ｓ９０６）。ホットスポット内にいない場合（Ｓ９０５の「ＮＯ」）、Ｓ９０６の処理はスキップされ、グローバル通信用識別子はＲＲＥＱに記述されない。
【００６８】
このように自局情報が追記されると、追記後のＲＲＥＱを周囲の端末へフラッディングする（Ｓ９０７）。これで１回の中継処理が終了し、Ｓ９０１へ戻る。
【００６９】
一方、自局が宛先ノードである場合（Ｓ９０３の「ＹＥＳ」）、受信したＲＲＥＱに基づいてＲＲＥＰを作成し、送信端末へ返信するために、まず、ＲＲＥＱが転送されてきたルートの一部をインターネット経由の経路で置き換えるか否かが判断される（Ｓ９０８）。
【００７０】
Ｓ９０８において、「Ｒｒｅｑ」は、受信されたＲＲＥＱ内に記述されていた経路を表し、「Ｈ（Ｒ）」は、ルートＲ上で最も送信端末寄りでホットスポット内にいる端末から最も受信端末寄りでホットスポット内にいる端末までの経路を抽出したものを表し、「Ｈｏｐ（Ｒ）」は、ルートＲのホップ数を表す。
【００７１】
なお、Ｈ（Ｒ）は、ルートＲ上にホットスポット内に位置する端末が２つ以上存在しない場合、空（＝０）とする。また、例えば、ルートＲ＝送信者→Ａ＊→Ｂ＊→Ｃ→Ｄ→Ｅ＊→Ｆ→受信者であった場合（「＊」はホットスポット内）、Ｈ（Ｒ）＝Ａ＊→Ｂ＊→Ｃ→Ｄ→Ｅ＊となる。
【００７２】
すなわち、Ｓ９０８においては、受信端末により受信されたＲＲＥＱに記述された経路のうち最も送信端末寄りでホットスポット内にいる端末から最も受信端末寄りでホットスポット内にいる端末までの経路のホップ数が所定の閾値以上であるか否かが判定されている。
【００７３】
ここでは、通信品質向上のためなるべくインターネットを経由したいが、しかしながら、端末〜ＡＰ間も無線通信の１ホップとカウントされるため、インターネットへのゲートウェイとなるホットスポットエリア内に在圏した２つの端末がアドホックネットワーク上で近接した位置関係にある場合（例えば、ホップ数＝１の距離にある場合など）にまでわざわざインターネットを経由させる必要はないとの洞察から、上記所定の閾値は例えば「２ホップ」などに設定される。
【００７４】
換言すれば、本実施例では、所定数以上のホップ数が削減される場合のみ、ルートの一部をインターネットを経由した経路に置き換える。
【００７５】
このようなＳ９０８における判定処理において、削減されるホップ数が所定の閾値以上であると判断された場合（Ｓ９０８の「ＹＥＳ」）、図６に示したＲＲＥＱから図７に示したＲＲＥＰを作るように、受信したＲＲＥＱからインターネットを経由した経路を採用したＲＲＥＰが作成される（Ｓ９０９）。一方、Ｓ９０８における判定処理において、削減されるホップ数が所定の閾値未満であると判断された場合（Ｓ９０８の「ＮＯ」）、図５に示すように、現行のＤＳＲプロトコルに従って受信されたＲＲＥＱに記述されたのと同じ経路情報が記述されたＲＲＥＰが作成される（Ｓ９１０）。
【００７６】
上述のＳ９０８についての説明から明らかなように、受信したＲＲＥＱに記述された経路情報に含まれる端末の中に含まれるホットスポット内にいる端末の数が２未満であってインターネットによるショートカットが物理的に実現できない場合にも、Ｓ９０８における判定は「ＮＯ」となり、従来通り、アドホックネットワークに閉じた経路を示すＲＲＥＰが作成される。
【００７７】
そして、このようにして作成されたＲＲＥＰは送信端末へ向けてユニキャストで返信される（Ｓ９１１）。これで１回の経路探索処理が終了し、Ｓ９０１へ戻る。
【００７８】
このように、本実施例によれば、アドホックネットワーク内でＲＲＥＱが転送されるというＭＡＮＥＴ内に閉じたルーティング処理でありながら、インターネットに接続している中継ノードは上述のようなグローバル通信用識別子もＲＲＥＱに付加して転送するという特徴を備えたことにより、インターネット上に経路要求を流さずにインターネットを経由したルートも考慮した経路探索が可能となる。
【００７９】
従来、アドホックネットワーク上での経路探索にはアドホックネットワーク上で経路要求する必要があり、インターネット上での経路探索にはインターネット上で経路要求する必要があったことと比較すれば、本実施例の有益性は明らかである。
【００８０】
なお、本実施例においては、ＲＲＥＱを受信した受信端末がインターネットを経由するＲＲＥＰを作成するか否かを判断する（図９のＳ９０８）際に、受信したＲＲＥＱに記述された経路となった端末の中で最も送信端末寄りのホットスポット内の端末と最も受信端末寄りのホットスポット内の端末とをインターネットへのゲートウェイとして利用するものとした。また、インターネットを経由することにより削減されるホップ数が所定の閾値以上であれば必ずインターネットを経由するルートが選択されるものとした。
【００８１】
この点、理論上は、最も送信端末寄りでないホットスポット内の端末を利用することも、最も受信端末寄りでないホットスポット内の端末を利用することも可能であり、さらに、削減されるホップ数が所定の閾値以上の場合であってもあえて現行通りアドホックネットワーク内に閉じたルーティングを行うことも可能である。
【００８２】
しかしながら、当業者には既知のように、アドホックネットワークではホップ数が増えるほど通信品質は劣化するため、できる限りアドホックネットワーク内での無線リンクを減らして、インターネットを経由したルートを通った方が通信品質は良好となる。
【００８３】
したがって、上記実施例のようにできる限りインターネットを経由させようとすることは、好ましい実施形態であると言える。
【実施例２】
【００８４】
次に、図１０〜１４を用いて、本発明の別の一実施例（実施例２）に係るルーティング方法について説明する。本実施例では、ルーティングプロトコルとしてＡＯＤＶが用いられることを前提し、上記実施例１と同様に図１に示すようなアドホック通信端末が点在する通信環境において、送信端末が受信端末へデータを送信するために経路探索（ルートディスカバリー）を実行する場合を考える。
【００８５】
また、本実施例においても、上記実施例１と同様に、各通信端末は、アドホック通信が可能であると共に、ホットスポットエリア内にいるときには無線ＬＡＮを利用してインターネットに接続する能力を有するものとする。端末の概略構成は図２に示したのと同様であり、重複する説明は省略する。
【００８６】
本実施例によっても、インターネットに接続した端末を利用して、アドホックネットワーク内に閉じたルーティング処理によって、インターネットを経由する経路も考慮した経路探索が可能となる。
【００８７】
このように、本実施例は、ルーティングプロトコルとしてＡＯＤＶを採用している点が異なる以外、基本的特徴は上記実施例１と同じであるため、重複する説明は省略する。したがって、以下の本実施例の説明は、主として、ＤＳＲとＡＯＤＶの違いにより生じる適用方法の違いについての説明である。
【００８８】
本実施例においても、ＲＲＥＱを受信した各通信端末は、自局がホットスポットエリア内に位置すると判断した場合、インターネット上における自局の識別子（グローバル通信用識別子）をＲＲＥＱに追記した上で転送する。本実施例においても、グローバル通信用識別子が追記されたＲＲＥＱは、通常のＲＲＥＱと同様、アドホックネットワーク内だけでフラッディングされ、インターネット上へは送出されない。
【００８９】
本実施例により拡張されたＡＯＤＶプロトコルにおけるＲＲＥＱのパケット構造を図１０に示す。図示すように、本実施例に係るＲＲＥＱは、上段部分が、フラグＨを除き、現行のＡＯＤＶプロトコルに準拠した構造であり、下段部分が拡張された追加部分となっている。
【００９０】
上段の「タイプ」フィールドは、メッセージの種類を示すためのものであり、ＲＲＥＱの場合は「１」が入る。「ホップ数」フィールドは、送信元ノードから何回転送されたかを表すフィールドであり、送信端末から送信されるときには０である。
【００９１】
本実施例の拡張により追加されたフラグＨは、経路中にホットスポットエリア内に位置する端末が存在し、ＲＲＥＱにその端末のグローバル通信用識別子が記述された場合に立てられる。
【００９２】
下段の追加部分には、ホットスポットエリア内に位置する端末によって追記されたグローバル通信用識別子と、送信端末からその端末までのホップ数とが記述される。ＡＯＤＶプロトコルでは、ソースルーティングであるＤＳＲプロトコルと異なり、ＲＲＥＱ内にすべての経路が記述されず、各端末は自局が保持するルーティングテーブルに従って転送を行う。したがって、ＲＲＥＱを中継する各端末はＲＲＥＱに自局のＭＡＮＥＴ内端末識別子は書き込まず、本実施例による拡張によりグローバル通信用識別子のみが追記される。
【００９３】
図１に例示した通信環境において図４に示したようなルートで本実施例に係るＲＲＥＱが転送された場合に受信端末が受信するＲＲＥＱを図１１に示す。図４の例では、経路上の端末Ｂ、端末Ｃ、端末Ｉ、端末Ｋ、及び端末Ｍがホットスポットエリア内に位置するため、ＲＲＥＱ下段に追加された拡張部分にこれら端末のグローバル通信用識別子及び送信端末からのホップ数が記述されている。ここで、ホップ数＝３の端末Ｆ（図４）は、ホットスポットエリア内に位置しないため、ＲＲＥＱ内に記述がない。
【００９４】
このように、本実施例に係る拡張によれば、経路探索時に、中継ノードがホットスポットエリア内にいれば、ＲＲＥＱに追記される情報が増えるが、これは経路探索時のみであり、ルート確立後のデータ送信では特段の追加的情報が付加されない。
【００９５】
ＲＲＥＱの中継に関して、その他の点は現行のＡＯＤＶプロトコルに準拠する。すなわち、送信端末からブロードキャストされたＲＲＥＱは、周囲の端末によって受信される。各端末は、受信したＲＲＥＱの宛先が自局でなければ、上述のような自局情報を追記した上で、ＲＲＥＱをブロードキャストする。このような転送・中継が繰り返され、最終的に受信端末に到達する。
【００９６】
このように、本実施例によれば、上述のようにＡＯＤＶプロトコルが拡張されているため、受信端末は、受信されたＲＲＥＱから、経路上の端末Ｂ、端末Ｃ、端末Ｉ、端末Ｋ、及び端末Ｍがホットスポットエリア内に位置することを知ることができると共に、それらのグローバル通信用識別子も取得することができる。
【００９７】
ＡＯＤＶプロトコルにおいても、ＲＲＥＱは様々な経路でそのＲＲＥＱの宛先ノードである受信端末に到達し、受信端末は、最初に到達したＲＲＥＱが最もホップ数が少ない最短のルートを経由していると判断して、その最初に受信したＲＲＥＱに基づいてルートリプライ（ＲＲＥＰ）を作成し、送信端末にユニキャスト送信する。
【００９８】
本実施例において、ＲＲＥＱの宛先ノードである受信端末は、最初に受信したＲＲＥＱの中に記述されたグローバル通信用識別子の数が１以下であった場合、経路の一部をインターネット経由にすることはできないと判断して、現行通り、アドホックネットワーク内に閉じたＲＲＥＰを作成し、送信端末へ返信する。
【００９９】
一方、受信したＲＲＥＱに２以上のグローバル通信用識別子が含まれていた場合、受信端末は、それら記述されているグローバル通信用識別子の中から、経路上最も送信端末寄りの端末のものと最も受信端末寄りのものとを抽出し、ＲＲＥＰに記述する。
【０１００】
本実施例に従って作成されたＲＲＥＰのフォーマット例を図１２に示す。上段の「タイプ」フィールドは、ＲＲＥＰの場合「２」が入る。「ホップ数」フィールドは、宛先ノードから何回転送されたかを表すフィールドであり、受信端末からユニキャスト送信される際には０である。
【０１０１】
下段の追加部分には、ＲＲＥＱに記述されていたグローバル通信用識別子の中から経路上最も宛先ノードに近いものが「グローバル通信用識別子１」フィールドに記述され、最も送信元ノードに近いものが「グローバル通信用識別子２」フィールドに記述される。
【０１０２】
図１１に例示したＲＲＥＱを受信した受信端末が返信するＲＲＥＰを図１３に示す。ここでは、「グローバル通信用識別子１」フィールドに端末Ｍのグローバル通信用識別子が記述され、「グローバル通信用識別子２」フィールドに端末Ｂのグローバル通信用識別子が記述される。
【０１０３】
このように作成された本実施例に係るＲＲＥＰは、現行プロトコルと同様、送信端末にユニキャストされる。ただし、本実施例においては、現行のＡＯＤＶプロトコルの拡張として、ＲＲＥＰを中継する各端末は、受信したＲＲＥＰの「グローバル通信用識別子１」フィールドに自局のグローバル通信用識別子が記述されていた場合、自局が保持するアドホックネットワーク用のルーティングテーブルには従わず、そのＲＲＥＰをインターネット経由で「グローバル通信用識別子２」フィールドに記述されたグローバル通信用識別子（アドレス）宛に送信する。そして、受信したＲＲＥＰに記述されたホップ数を１インクリメントした値と宛先ノードと関連付けて新たにルーティングテーブルに記憶する。これにより、その中継ノードは、その宛先ノードまで何ホップであるかを自局内のルーティングテーブルに記憶することができる。
【０１０４】
インターネット経由でＲＲＥＰを受信した端末は、現行通り、自局が保持するルーティングテーブルに従ってそのＲＲＥＰをアドホックネットワーク内で送信する。
【０１０５】
このようにして、ＲＲＥＰの返信には、上記実施例１と同様に、インターネットが利用される。このＲＲＥＰの転送はブロードキャストであるＲＲＥＱとは異なりユニキャストであるため、インターネットを経由しても負荷は問題とならない。
【０１０６】
このように、本実施例によっても、アドホックネットワークにおいて探索・確立されるルートの一部をインターネットを経由したルートとすることができ、図８に示したようなホップ数削減が見込まれる。
【０１０７】
以上のような本実施例に係るルーティング方法について、図１４を用いてより詳細に説明する。図１４は、本実施例において各端末において行われる受信したＲＲＥＱに対する処理の流れを示すフローチャートである。
【０１０８】
まず、各端末はＲＲＥＱの受信を待機する（Ｓ１４０１）。
【０１０９】
ＲＲＥＱが受信されると（Ｓ１４０１の「ＹＥＳ」）、例えば「ＲＲＥＱ ＩＤ」フィールドの記述から処理済みのＲＲＥＱであるか否かを判断する（Ｓ１４０２）。処理済みの場合（Ｓ１４０２の「ＹＥＳ」）、そのＲＲＥＱを破棄する（Ｓ１４１２）。
【０１１０】
受信したＲＲＥＱが処理済みではない場合（Ｓ１４０２の「ＮＯ」）、次いで、そのＲＲＥＱの宛先ノードが自局であるか否かが判断される（Ｓ１４０３）。自局が宛先ノードでない場合、Ｓ１４０４〜Ｓ１４０６の転送処理が実行され、自局が宛先ノードの場合、Ｓ１４０７〜Ｓ１４１１のＲＲＥＰ作成・送信処理が実行される。
【０１１１】
まず、自局が宛先ノードでない場合（Ｓ１４０３の「ＮＯ」）、自局がホットスポットエリア内にいるか否か、換言すれば無線ＬＡＮを利用してインターネットに接続している状態であるか否か、について判断し（Ｓ１４０４）、ホットスポット内にいる場合（Ｓ１４０４の「ＹＥＳ」）、上述のように受信したＲＲＥＱに自局のグローバル通信用識別子と送信端末からのホップ数とを追記する（Ｓ１４０５）。ホットスポット内にいない場合（Ｓ１４０４の「ＮＯ」）、Ｓ１４０５の処理はスキップされ、グローバル通信用識別子はＲＲＥＱに記述されない。
【０１１２】
次いで、ＲＲＥＱは周囲の端末へフラッディングされる（Ｓ１４０６）。これで１回の中継処理が終了し、Ｓ１４０１へ戻る。
【０１１３】
一方、自局が宛先ノードである場合（Ｓ１４０３の「ＹＥＳ」）、受信したＲＲＥＱに基づいてＲＲＥＰを作成し、送信端末へ返信するために、まず、ＲＲＥＱが転送されてきたルートの一部をインターネット経由の経路に置き換えることが可能な否かが判断される（Ｓ１４０７）。具体的には、受信されたＲＲＥＱにグローバル通信用識別子が２以上記述されているか否かが判断される。
【０１１４】
Ｓ１４０７において、「Ｒｈｏｔ」は、受信されたＲＲＥＱ内に記述されていたホットスポットエリア内にいるノードのリストを表し、「Ｎｕｍ（Ｒｈｏｔ）」は、リストＲｈｏｔ内に記述されているノードの数を表す。
【０１１５】
Ｓ１４０７において、受信されたＲＲＥＱにグローバル通信用識別子が２以上記述されているか否かが判断されると（Ｓ１４０７の「ＹＥＳ」）、次いで、ＲＲＥＱが転送されてきたルートの一部をインターネット経由の経路で置き換えるか否かが判断される（Ｓ１４０８）。
【０１１６】
Ｓ１４０８において、「Ｓｕｂ（Ｒｈｏｔ）」は、リストＲｈｏｔ内に記述されている端末のうち最も送信元ノード寄りのものと最も宛先ノード寄りのものとの間のアドホックネットワーク上でのホップ数を表す。これは、図１１から明らかなように、ＲＲＥＱ下段の拡張部分に記述されたホップ数の中で最も大きいものから最も小さいものを引いた差に等しいため、本実施例に係る拡張されたＡＯＤＶプロトコルによれば容易に算出される。
【０１１７】
こうして、Ｓ１４０８においては、受信端末により受信されたＲＲＥＱが経由した経路において最も送信端末寄りでホットスポット内にいる端末から最も受信端末寄りでホットスポット内にいる端末までの経路のホップ数が所定の閾値以上であるか否かが判定されている。
【０１１８】
ここでは、通信品質向上のためなるべくインターネットを経由したいが、しかしながら、端末〜アクセスポイント（ＡＰ）間も無線通信の１ホップとカウントされるため、インターネットへのゲートウェイとなるホットスポットエリア内に在圏した２つの端末がアドホックネットワーク上で近接した位置関係にある場合（例えば、ホップ数＝１の距離にある場合など）にまでわざわざインターネットを経由させる必要はないとの洞察から、上記所定の閾値は例えば「２ホップ」などに設定される。
【０１１９】
換言すれば、本実施例においても、上記実施例１と同様に、所定数以上のホップ数が削減される場合のみ、ルートの一部をインターネットを経由した経路に置き換える。
【０１２０】
このようなＳ１４０８における判定処理において、削減されるホップ数が所定の閾値以上であると判断された場合（Ｓ１４０８の「ＹＥＳ」）、図１１に示したＲＲＥＱから図１３に示したＲＲＥＰを作るように、受信したＲＲＥＱからインターネットを経由した経路を採用したＲＲＥＰが作成される（Ｓ１４０９）。一方、Ｓ１４０８における判定処理において、削減されるホップ数が所定の閾値未満であると判断された場合（Ｓ１４０８の「ＮＯ」）、「グローバル通信用識別子１」及び「グローバル通信用識別子２」の両フィールドが空のＲＲＥＰが作成される（Ｓ１４１０）。ただし、フラグＨにより、インターネットを経由しないルートであることが伝達される。
【０１２１】
当然、そもそも受信したＲＲＥＱに２以上のグローバル通信用識別子が記述されていない場合（Ｓ１４０７の「ＮＯ」）も、Ｓ１４１０においてアドホックネットワークに閉じた経路を示すＲＲＥＰが作成される。
【０１２２】
そして、このようにして作成されたＲＲＥＰは送信端末へ向けてユニキャストで返信される（Ｓ１４１１）。上述のように、フラグＨが立っている場合、この返信もインターネットを経由する。これで１回の経路探索処理が終了し、Ｓ１４０１へ戻る。
【０１２３】
このように、本実施例によれば、アドホックネットワーク内でＲＲＥＱが転送されるというＭＡＮＥＴ内に閉じたルーティング処理でありながら、インターネットに接続している中継ノードは上述のようなグローバル通信用識別子をＲＲＥＱに付加して転送するという特徴を備えたことにより、インターネット上に経路要求を流さずにインターネットを経由したルートも考慮した経路探索が可能となる。
【０１２４】
従来、アドホックネットワーク上での経路探索にはアドホックネットワーク上で経路要求する必要があり、インターネット上での経路探索にはインターネット上で経路要求する必要があったことと比較すれば、本実施例の有益性は明らかである。
【０１２５】
なお、本実施例においては、ＲＲＥＱを受信した受信端末がインターネットを経由するＲＲＥＰを作成するか否かを判断する（図１４のＳ１４０８）際に、受信したＲＲＥＱの転送経路となった端末の中で最も送信端末寄りのホットスポット内の端末と最も受信端末寄りのホットスポット内の端末とをインターネットへのゲートウェイとして利用するものとした。また、インターネットを経由することにより削減されるホップ数が所定の閾値以上であれば必ずインターネットを経由するルートが選択されるものとした。
【０１２６】
この点、理論上は、最も送信端末寄りでないホットスポット内の端末を利用することも、最も受信端末寄りでないホットスポット内の端末を利用することも可能であり、さらに、削減されるホップ数が所定の閾値以上の場合であってもあえて現行通りアドホックネットワーク内に閉じたルーティングを行うことも可能である。
【０１２７】
しかしながら、当業者には既知のように、アドホックネットワークではホップ数が増えるほど通信品質は劣化するため、できる限りアドホックネットワーク内での無線リンクを減らして、インターネットを経由したルートを通った方が通信品質は良好となる。
【０１２８】
したがって、上記実施例のようにできる限りインターネットを経由させようとすることは、好ましい実施形態であると言える。
【実施例３】
【０１２９】
次いで、図１５及び１６を用いて、本発明の更に別の一実施例（実施例３）について説明する。本実施例は、上述の実施例１及び２に共通する変形例であり、採用されるルーティングプロトコルはＤＳＲでもＡＯＤＶでもよい。
【０１３０】
上述の実施例１及び２では、グローバル通信用識別子がＲＲＥＱに付加される以外の点については現行のプロトコルと同様にＭＡＮＥＴ内でのルーティング処理を行い、それにより発見されたルート上においてインターネットによるショートカットが可能であるか否かを判断できるようにし、可能であればインターネットを経由したルートを採用する、という実施形態であった。
【０１３１】
本実施例は、これを更に一歩進めて、インターネットによるショートカットを利用可能なＭＡＮＥＴ内ルートを積極的に探索するものである。
【０１３２】
具体的には、上述の実施例１及び２では、現行のＤＳＲ及びＡＯＤＶと同様に、受信端末（ＲＲＥＱの宛先ノード）に最初に到着したＲＲＥＱだけＲＲＥＰ返信処理の対象となり、遅延して到着したＲＲＥＱは冗長な（すなわち、ホップ数が多い）経路を通って来たものと判断して破棄していたのに対し、本実施例では、ＭＡＮＥＴ内に閉じたルーティングではホップ数が多く、遅延を伴うルートであっても、上述の実施例１又は２に係るようなインターネットを利用したショートカットを利用すれば、ホップ数が削減され、最もホップ数が少ないルートが得られる可能性があることに鑑み、ＲＲＥＱの宛先ノードは、最初のＲＲＥＱ受信後、所定時間、同じ送信元ノードからの他のＲＲＥＱの受信を待機するものとする。
【０１３３】
そして、本実施例では、ＲＲＥＱ受信を上記所定時間待機したＲＲＥＱの宛先ノードは、最初に受信されたＲＲＥＱと該所定時間中に受信された遅延ＲＲＥＱとの中から、上述の実施例１及び２のようにインターネットを利用したショートカットを考慮して、最もホップ数が少ないルートを選択する。
【０１３４】
図１５及び１６に一例を挙げる。ここで、図１５に示すようにアドホック通信端末が点在する通信環境において、送信端末がＲＲＥＱを受信端末へ向けてフラッディングしたとき、ＲＲＥＱが２つの経路（ルート１、ルート２）で受信端末（宛先ノード）へ到達した場合を考える。また、いくつかの中継ノードはホットスポット（ＨＳ）１〜３のエリア内に在圏している。
【０１３５】
各ルートが経由する端末について図１６にまとめる。図１６（ａ）はルート１が経由する端末（ノード）を示し、図１６（ｂ）はルート２が経由する端末（ノード）を示す。図示するように、この例では、ルート２の方がホップ数が多い。したがって、通常であれば、ルート２を経由したＲＲＥＱの方がルート１を経由したものより遅く受信端末に到達するはずである。
【０１３６】
上述のように、現行のルーティングプロトコルでは、このような遅延して到達したＲＲＥＱは破棄されることになるが、本実施例では、上記所定時間内であればこのような遅延したＲＲＥＱもＲＲＥＰ作成の対象となる。
【０１３７】
上記所定時間内にルート２を経由したＲＲＥＱのみが受信されたものとすると、受信端末は、次に、最初に受信されたルート１（図１６（ａ））経由のＲＲＥＱと、ルート２（図１６（ｂ））経由のＲＲＥＱとを比較し、ホップ数が少ない方を選択する段階となる。
【０１３８】
ただし、本例では、ルート２上にはホットスポットエリア内に位置する中継ノードが２つ以上存在するため、受信端末は、上述の実施例１及び２のようなショートカットを利用することができる、と判断することができる。
【０１３９】
図１５に示す例では、ルート２上で、最も送信端末寄りのホットスポットエリア内に位置するノードは端末Ｂであり、最も受信端末寄りのホットスポットエリア内に位置するノードは端末Ｍであることから、図１６（ｂ）に示したルート２は、上述の実施例１及び２のような手法を利用して端末Ｂ〜端末Ｍ間をインターネットによるショートカットさせることにより、図１６（ｃ）に示すようなルート２’とすることができる。
【０１４０】
すると、図示するように、図１６（ｃ）に示すインターネットを利用したルート２’では、図１６（ｂ）に示すＭＡＮＥＴ内に閉じたルート２に比して、ホップ数を２ホップ削減することができることがわかる。
【０１４１】
したがって、本例において、受信端末は、ルート１（図１６（ａ））のホップ数と、ルート２’（図１６（ｃ））のホップ数とを比較して、ホップ数のより少ないルート２’をＲＲＥＰ経路に優先的に選択することができる
このように、本実施例では、受信端末（宛先ノード）が従来は破棄していた遅延したＲＲＥＱを含めて積極的にインターネットによるショートカットが可能なルートを探索することができるため、より少ないホップ数のルートを優先的に経路として使用することができる。
【０１４２】
なお、本実施例において、上記所定時間は、原則として任意に定めることができるが、経路探索に要する時間が過度に長くならないように、適度な時間長に設定されるべきである。
【０１４３】
例えば、最初に受信されたＲＲＥＱの経路のホップ数に基づいて、遅延した宛先ノードに到達したＲＲＥＱのＭＡＮＥＴ内に閉じたルートのホップ数が最初に受信されたＲＲＥＱ経路のホップ数の所定数分の１のホップ数以内であれば許容するようにしてもよく、或いは、最初に受信されたＲＲＥＱの経路のホップ数とは無関係に、予め設定された所定ホップ数までの遅延を許容してもよい。
【０１４４】
また、ホップ数ではなく遅延時間を基準とし、最初にＲＲＥＱから受信されてから所定時間だけ待機するようにしてもよい。または、受信端末は最初に受信されたＲＲＥＱが送信端末により送信されてから受信端末により受信されるまでに要した時間のプラス所定パーセントまでの時間が経過するまで待機するようにしてもよい。ただし、この場合、送信端末がＲＲＥＱ送信時にＲＲＥＱに送信時刻をタイムスタンプすることが必要となる。
【０１４５】
また、常に上記所定時間待機するものとせず、例えば、該所定期間の途中でグローバル通信用識別子を２つ以上含んだ（すなわち、インターネットによるショートカットが可能な経路を持つ）ＲＲＥＱが受信されたときには、その時点で遅延したＲＲＥＱの受信待機を中止するようにしてもよい。
【０１４６】
また、ここでは、受信端末は、最初にＲＲＥＱが受信されてから所定時間他のＲＲＥＱの受信を待機するものとし、受信された１以上のＲＲＥＱの中から最もホップ数が少ないルートをＲＲＥＰ返信対象に選択するものとしたが、ホップ数に代えて又は加えて、通信帯域や遅延時間などのパラメータを考慮してルートを選択してもよい。これは、例えば、ＰＩＮＧコマンドを利用してスループットやＲＴＴ（Ｒｏｕｎｄ Ｔｒｉｐ Ｔｉｍｅ）などを測定することにより得られる。
【０１４７】
さらに、本実施例の好ましい変形例として、インターネットによるショートカットが可能なルートをより積極的に探索するために、宛先ノードが遅延したＲＲＥＱを待機するだけでなく、各中継ノードがＲＲＥＱを転送する際に処理済みのＲＲＥＱであってもグローバル通信用識別子を含んだＲＲＥＱについては破棄せずに、最初に受信されたＲＲＥＱと同様に転送処理を行うようにしてもよい。これにより、インターネットによるショートカットが可能なルートを経由したＲＲＥＱが受信端末に到達する可能性を高めることができ、インターネット経由の経路の利用を促進することができる。
【０１４８】
以上、本発明の実施例１〜３について具体例を挙げながら説明した。しかしながら、ここに説明及び図示した実施例はあくまで例示に過ぎず、本発明はこれらに限定されるものではない。
【０１４９】
例えば、上記実施例１〜３では、アドホックネットワークの無線リンクよりも通信品質が良いと想定される有線網の一例としてインターネットを挙げたが、本発明はこれに限られず、インターネット以外の有線網を利用することも当然可能である。
【０１５０】
また、上記実施例１〜３では、各端末が有線網へ無線ＬＡＮを利用して有線網に接続するものとしたが、本発明はこれに限られず、例えばＤＳＲＣ（ｄｅｄｉｃａｔｅｄ ｓｈｏｒｔ ｒａｎｇｅ ｃｏｍｍｕｎｉｃａｔｉｏｎ；挟域通信）などの他の通信規格を利用することも当然可能である。
【０１５１】
また、上記実施例１〜３では、ＲＲＥＱパケット構成などをリアクティブ型のルーティングプロトコルであるＤＳＲ又はＡＯＤＶが用いられるものとして説明したが、本発明はこれらに限定されるものではなく、他のリアクティブ型プロトコルであっても、或いは、プロアクティブ型プロトコルであっても、利用することができる。
【０１５２】
プロアクティブ型のルーティングプロトコルが用いられる場合、各ノード区間の経路情報が常にやりとりされているため、各端末はホットスポットエリア内に位置する端末まで何ホップの距離にあるかを把握している。そこで、プロアクティブ型ルーティングプロトコルが用いられる場合には、上記実施例１〜３の変形例として、各端末が、自局がホットスポットエリア内に位置すれば上記実施例１〜３と同様に自局のグローバル通信用識別子をＲＲＥＱに追記すると共に、自局がホットスポットエリア内に位置しなければ自局が持つ周辺ノード情報から自局からも最も近いホットスポットエリア内に位置する端末に到達するまでのホップ数をＲＲＥＱに追記するようにしてもよい。これにより、インターネットによるショートカット可能なルートをより一層積極的に探索することができる。
【０１５３】
また、上記実施例１〜３では、一部の中継ノードがホットスポットエリア内に位置する場合について述べたが、上記説明を読んだ当業者には明らかなように、本発明はＲＲＥＱ送信元ノード及び／又はＲＲＥＱ宛先ノードがホットスポットエリア内に位置する場合にも等しく適用することが可能である。ただし、当業者には明らかなように、送信元ノードがホットスポットエリア内に位置する場合であっても、当然、ＲＲＥＱはＭＡＮＥＴ内のみにフラッディングされる。
【０１５４】
また、現行のルーティングプロトコルでは、ノードの移動や電源オフなどによりルートが切れた場合に再度経路探索が行われるようになっているが、本発明においては、いずれの実施例及び変形例においても、ルート切れの場合に加えて、更に、送信元ノード、ルートに選ばれた中継ノード、及び宛先ノードのいずれかがホットスポットエリア内に入ったとき及びホットスポットエリアから外へ出たときにも経路が再探索されることが好ましい。なぜなら、新たなインターネットを利用した経路により、ホップ数を更に削減して通信品質を向上させることが可能となる可能性があるためである。
【０１５５】
また、本発明の適用に合わせたインフラ側の工夫として、アドホックネットワークによってインターネットを利用したショートカットに頻繁に利用されるホットスポットエリア（のＡＰ）間をトンネリング（ｔｕｎｎｅｌｉｎｇ）やＶＰＮ（Ｖｉｒｔｕａｌ Ｐｒｉｖａｔｅ Ｎｅｔｗｏｒｋ；仮想閉域網）などの技術を利用して仮想上一体化しても有益的である。これにより、一方のホットスポットエリア内でブロードキャストされたＲＲＥＱは他方のホットスポットエリア内にもブロードキャストされたことになり、ＭＡＮＥＴ内端末識別子の処理のみで有線網を利用したショートカットが可能となる。
【０１５６】
さらに、上記実施例及び変形例においては、ルーティング判定の指標としてホップ数を例に挙げたが、当業者には明らかなようにこれは一例に過ぎず、例えば通信帯域や遅延時間などの通信品質に関連する指標などの他の指標を用いてルーティングの判定を行うことも可能である。
【産業上の利用可能性】
【０１５７】
本発明は、アドホックネットワークに利用できる。上述のように、用いられるルーティングプロトコルは問わない。
【０１５８】
また、アドホック通信端末の種類も問わない。ノードとなる端末は、携帯電話であってもよく、ＰＤＡ（Ｐｅｒｓｏｎａｌ Ｄｉｇｉｔａｌ Ａｓｓｉｓｔａｎｔ；携帯情報端末）であってもよく、又は、車両に搭載された通信装置であってもよい。
【０１５９】
複数の車両に搭載された通信装置により車車間通信としてアドホックネットワークが構築されている場合、特に本発明に係るルーティング方法を適用すると有益的である。
【０１６０】
車車間通信の場合、ノードとなる各車両は、ほぼ道路上のみに存在すると言えるため、ルートが探索しやすい。また、車両運転中は、数ｋｍ前方の交通状況・道路状況を知りたい、というニーズがあると考えられるため、一時的にアドホックネットワークを張って情報を収集する、といった使い方が考えられる。
【０１６１】
さらに、本発明を車車間通信に適用した場合の最大の利点の１つは、交差点をホットスポットにすることによって、任意の交差点まで有線網によってショートカットできる点である。これは、例えば交差点に設置された信号機や一時停止の標識などに付随して例えば無線ＬＡＮのビーコンを送出するＡＰを設置することによって、比較的容易に、多くのノードの滞在・通過が見込めるエリア（交差点近傍）を確実にホットスポットエリアとすることができ、本発明に係るルーティングを利用した通信品質向上の促進が見込まれる。
【図面の簡単な説明】
【０１６２】
【図１】アドホック通信端末が点在し、一部の端末がホットスポットエリア内にいる通信環境の一例を示す図である。
【図２】本発明の一実施例におけるアドホック通信端末の概略構成図である。
【図３】本発明の一実施例においてＲＲＥＱを中継するノードによってＲＲＥＱに追記される自局情報を示す図である。
【図４】図１の通信環境においてＲＲＥＱが送信端末から受信端末へ到達した際に経由した経路の一例を示す図である。
【図５】現行ＤＳＲプロトコルに準拠し、図４の経路において受信端末に到達したＲＲＥＱに記述された経路情報を示す図である。
【図６】本発明の一実施例により拡張されたＤＳＲプロトコルに準拠し、図４の経路において受信端末に到達したＲＲＥＱに記述された経路情報を示す図である。
【図７】本発明の一実施例により拡張されたＤＳＲプロトコルに準拠し、図６のＲＲＥＱに対して作成されたＲＲＥＰに記述された経路情報を示す図である。
【図８】図４の場合に、現行ＤＳＲプロトコルにより確立されるルートと、本発明の一実施例により拡張されたＤＳＲプロトコルにより確立されるルートとを比較する図である。
【図９】本発明の一実施例において各端末において行われる受信したＲＲＥＱに対する処理の流れを示すフローチャートである。
【図１０】本発明の別の一実施例により拡張されたＡＯＤＶプロトコルに準拠したＲＲＥＱのパケット構造を示す図である。
【図１１】本発明の別の一実施例により拡張されたＡＯＤＶプロトコルに準拠し、図４の経路において受信端末に到達したＲＲＥＱのパケット構造を示す図である。
【図１２】本発明の別の一実施例により拡張されたＡＯＤＶプロトコルに準拠したＲＲＥＰのパケット構造を示す図である。
【図１３】本発明の別の一実施例により拡張されたＡＯＤＶプロトコルに準拠し、図４の経路において受信端末により返信されるＲＲＥＰのパケット構造を示す図である。
【図１４】本発明の別の一実施例において各端末において行われる受信したＲＲＥＱに対する処理の流れを示すフローチャートである。
【図１５】ＲＲＥＱが送信端末から受信端末へ到達した際に経由した２つの経路の一例を示す図である。
【図１６】図１５の場合に、現行のルーティングプロトコルにより確立されるルートと、本発明の更に別の一実施例に係るルーティングプロトコルにより確立されるルートとを比較する図である。
【符号の説明】
【０１６３】
２００ アドホック通信端末
２０１ 送受信部
２０２ パケット転送部
２０３ ルーティングテーブル
２０４ ルーティング用パケット処理部
２０５ アドレス格納部
【特許請求の範囲】
【請求項１】
アドホックネットワークにおけるルーティング方法であって、
ルートリクエストを送信又は転送するノードは、自局が外部の有線網と通信接続している場合、該有線網における自局の識別子を前記ルートリクエストに付加して送信又は転送する、ことを特徴とするアドホックネットワークにおけるルーティング方法。
【請求項２】
請求項１記載のアドホックネットワークにおけるルーティング方法であって、
前記ルートリクエストの宛先ノードは、受信したルートリクエストに２以上の前記有線網における識別子が含まれていた場合、これら２以上の識別子のうちルート上最も送信元ノードに近いノードを表す１つの識別子と最も宛先ノードに近いノードを表す１つの識別子とを用いて、これら２つの識別子が表すノード間は前記有線網を経由する経路を採用したルートリプライを作成する、ことを特徴とするアドホックネットワークにおけるルーティング方法。
【請求項３】
請求項２記載のアドホックネットワークにおけるルーティング方法であって、
前記ルートリクエストの宛先ノードは、アドホックネットワーク内のみでルーティングした場合に前記２つの識別子が表すノード間に所定数以上のホップ数が存在する場合のみ、これら２つの識別子が表すノード間は前記有線網を経由する経路を採用したルートリプライを作成する、ことを特徴とするアドホックネットワークにおけるルーティング方法。
【請求項４】
請求項３記載のアドホックネットワークにおけるルーティング方法であって、
ルートリクエストの宛先ノードは、
最初のルートリクエストを受信してから所定期間、他の経路を経由した同じ送信元ノードからのルートリクエストの受信を待機し、
前記所定期間内に同じ送信元ノードから１以上のルートリクエストが受信された場合、前記最初のルートリクエスト及び前記所定期間中に受信されたルートリクエストのうち２以上の前記有線網における識別子が含まれているルートリクエストについてはこれら２つの識別子が表すノード間は前記有線網を経由するものとして、各ルートリクエストの経路のホップ数を比較し、最もホップ数が少ない経路を有するルートリクエストに対してルートリプライを作成する、ことを特徴とするアドホックネットワークにおけるルーティング方法。
【請求項５】
請求項４記載のアドホックネットワークにおけるルーティング方法であって、
ルートリクエストの宛先ノードは、
２以上の前記有線網における識別子が含まれているルートリクエストが受信されたときに前記他の経路を経由した同じ送信元ノードからのルートリクエストの受信の待機を終了する、ことを特徴とするアドホックネットワークにおけるルーティング方法。
【請求項６】
請求項４又は５記載のアドホックネットワークにおけるルーティング方法であって、
受信したルートリクエストを転送するノードは、受信したルートリクエストに前記有線網における識別子が含まれている場合、その受信したルートリクエストが既に転送済みのルートリクエストであっても破棄せずに初めて受信したルートリクエストと同様に転送する、ことを特徴とするアドホックネットワークにおけるルーティング方法。
【請求項７】
請求項４乃至６のいずれか一項記載のアドホックネットワークにおけるルーティング方法であって、
各ノードは、自局周辺の前記有線網と通信接続しているノードを探索し、存在する場合、ルートリクエストを送信又は転送する際に自局からその自局周辺の前記有線網と通信接続しているノードまでのホップ数を該ルートリクエストに付加する、ことを特徴とするアドホックネットワークにおけるルーティング方法。
【請求項１】
アドホックネットワークにおけるルーティング方法であって、
ルートリクエストを送信又は転送するノードは、自局が外部の有線網と通信接続している場合、該有線網における自局の識別子を前記ルートリクエストに付加して送信又は転送する、ことを特徴とするアドホックネットワークにおけるルーティング方法。
【請求項２】
請求項１記載のアドホックネットワークにおけるルーティング方法であって、
前記ルートリクエストの宛先ノードは、受信したルートリクエストに２以上の前記有線網における識別子が含まれていた場合、これら２以上の識別子のうちルート上最も送信元ノードに近いノードを表す１つの識別子と最も宛先ノードに近いノードを表す１つの識別子とを用いて、これら２つの識別子が表すノード間は前記有線網を経由する経路を採用したルートリプライを作成する、ことを特徴とするアドホックネットワークにおけるルーティング方法。
【請求項３】
請求項２記載のアドホックネットワークにおけるルーティング方法であって、
前記ルートリクエストの宛先ノードは、アドホックネットワーク内のみでルーティングした場合に前記２つの識別子が表すノード間に所定数以上のホップ数が存在する場合のみ、これら２つの識別子が表すノード間は前記有線網を経由する経路を採用したルートリプライを作成する、ことを特徴とするアドホックネットワークにおけるルーティング方法。
【請求項４】
請求項３記載のアドホックネットワークにおけるルーティング方法であって、
ルートリクエストの宛先ノードは、
最初のルートリクエストを受信してから所定期間、他の経路を経由した同じ送信元ノードからのルートリクエストの受信を待機し、
前記所定期間内に同じ送信元ノードから１以上のルートリクエストが受信された場合、前記最初のルートリクエスト及び前記所定期間中に受信されたルートリクエストのうち２以上の前記有線網における識別子が含まれているルートリクエストについてはこれら２つの識別子が表すノード間は前記有線網を経由するものとして、各ルートリクエストの経路のホップ数を比較し、最もホップ数が少ない経路を有するルートリクエストに対してルートリプライを作成する、ことを特徴とするアドホックネットワークにおけるルーティング方法。
【請求項５】
請求項４記載のアドホックネットワークにおけるルーティング方法であって、
ルートリクエストの宛先ノードは、
２以上の前記有線網における識別子が含まれているルートリクエストが受信されたときに前記他の経路を経由した同じ送信元ノードからのルートリクエストの受信の待機を終了する、ことを特徴とするアドホックネットワークにおけるルーティング方法。
【請求項６】
請求項４又は５記載のアドホックネットワークにおけるルーティング方法であって、
受信したルートリクエストを転送するノードは、受信したルートリクエストに前記有線網における識別子が含まれている場合、その受信したルートリクエストが既に転送済みのルートリクエストであっても破棄せずに初めて受信したルートリクエストと同様に転送する、ことを特徴とするアドホックネットワークにおけるルーティング方法。
【請求項７】
請求項４乃至６のいずれか一項記載のアドホックネットワークにおけるルーティング方法であって、
各ノードは、自局周辺の前記有線網と通信接続しているノードを探索し、存在する場合、ルートリクエストを送信又は転送する際に自局からその自局周辺の前記有線網と通信接続しているノードまでのホップ数を該ルートリクエストに付加する、ことを特徴とするアドホックネットワークにおけるルーティング方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【公開番号】特開２００６−２２９３３２（Ｐ２００６−２２９３３２Ａ）
【公開日】平成１８年８月３１日（２００６．８．３１）
【国際特許分類】
【出願番号】特願２００５−３７９５１（Ｐ２００５−３７９５１）
【出願日】平成１７年２月１５日（２００５．２．１５）
【出願人】（０００００３２０７）トヨタ自動車株式会社 (59,920)
【出願人】（５０２０８７４６０）株式会社トヨタＩＴ開発センター (232)
【Ｆターム（参考）】
【公開日】平成１８年８月３１日（２００６．８．３１）
【国際特許分類】
【出願日】平成１７年２月１５日（２００５．２．１５）
【出願人】（０００００３２０７）トヨタ自動車株式会社 (59,920)
【出願人】（５０２０８７４６０）株式会社トヨタＩＴ開発センター (232)
【Ｆターム（参考）】
[ Back to top ]