(57)【特許請求の範囲】
【請求項１】
送信元の通信装置と、送信先の通信装置と、中間の通信装置とを少なくとも有し、前記中間の通信装置は、前記送信元の通信装置が属する第１経路構築プロトコルで通信経路を構築する第１サブネットワークと、前記送信先の通信装置が属する前記第１経路構築プロトコルとは異なる第２経路構築プロトコルで通信経路を構築する第２サブネットワークと、を相互に接続する機能を有するネットワークシステムにおいて、
前記中間の通信装置は、
前記送信先の通信装置を宛先とするパケットを前記送信元の通信装置から受信した場合には、前記送信先の通信装置との間で前記第２経路構築プロトコルに対応する経路探索パケットを送信して経路を確立する経路確立手段と、
前記経路確立手段によって前記第２経路構築プロトコルに対応する経路応答パケットが受信されて経路が確立された場合に、前記送信元の通信装置に対して、前記送信先の通信装置に代わって前記第１経路構築プロトコルに対応する経路応答パケットを送信することで代理応答する代理応答手段と、を有し、
前記代理応答手段は、前記経路確立手段によって経路が確立されるまで、前記第１経路構築プロトコルに対応する経路応答パケットの送信を保留する、
ことを特徴とするネットワークシステム。
【請求項２】
前記第１経路構築プロトコルは、ＡＯＤＶ（Ad hoc On-Demand Distance Vector）およびＤＳＲ（Dynamic Source Routing）のいずれか一方であり、前記第２経路構築プロトコルは、ＡＯＤＶおよびＤＳＲのいずれか他方であることを特徴とする請求項１に記載の通信装置。
【請求項３】
送信元の通信装置と、送信先の通信装置と、中間の通信装置とを少なくとも有し、前記中間の通信装置は、前記送信元の通信装置が属する第１経路構築プロトコルで通信経路を構築する第１サブネットワークと、前記送信先の通信装置が属する前記第１経路構築プロトコルとは異なる第２経路構築プロトコルで通信経路を構築する第２サブネットワークと、を相互に接続する機能を有するネットワークシステムに用いられる通信装置において、
前記中間の通信装置は、
前記送信先の通信装置を宛先とするパケットを前記送信元の通信装置から受信した場合には、前記送信先の通信装置との間で前記第２経路構築プロトコルに対応する経路探索パケットを送信して経路を確立する経路確立手段と、
前記経路確立手段によって前記第２経路構築プロトコルに対応する経路応答パケットが受信されて経路が確立された場合に、前記送信元の通信装置に対して、前記送信先の通信装置に代わって前記第１経路構築プロトコルに対応する経路応答パケットを送信することで代理応答する代理応答手段と、を有し、
前記代理応答手段は、前記経路確立手段によって経路が確立されるまで、前記第１経路構築プロトコルに対応する経路応答パケットの送信を保留する、
ことを特徴とする通信装置。
【請求項４】
送信元の通信装置と、送信先の通信装置と、中間の通信装置とを少なくとも有し、前記中間の通信装置は、前記送信元の通信装置が属する第１経路構築プロトコルで通信経路を構築する第１サブネットワークと、前記送信先の通信装置が属する前記第１経路構築プロトコルとは異なる第２経路構築プロトコルで通信経路を構築する第２サブネットワークと、を相互に接続する機能を有するネットワークシステムの通信方法において、
前記中間の通信装置が前記送信先の通信装置を宛先とするパケットを前記送信元の通信装置から受信した場合には、前記送信先の通信装置との間で前記第２経路構築プロトコルに対応する経路探索パケットを送信して経路を確立する経路確立ステップと、
前記経路確立ステップにおいて前記第２経路構築プロトコルに対応する経路応答パケットが受信されて経路が確立された場合に、前記送信元の通信装置に対して、前記送信先の通信装置に代わって前記第１経路構築プロトコルに対応する経路応答パケットを送信することで代理応答する代理応答ステップと、を有し、
前記代理応答ステップは、前記経路確立ステップにおいて経路が確立されるまで、前記第１経路構築プロトコルに対応する経路応答パケットの送信を保留する、
ことを特徴とする通信方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークシステム、通信装置、および、通信方法に関するものである。
【背景技術】
【０００２】
特許文献１には、ＡＯＤＶ（Ad hoc On-Demand Distance Vector）プロトコルを用いて、送信元ノードから中間ノードを経由して送信先ノードまでの通信経路を探索し、経路上の通信帯域を予約する第１のステップと、通信ルート上で互いに隣接する中間ノード同士を結ぶリンクルート上の通信帯域幅の情報を中間ノードに格納する第２のステップと、経路上の送信先ノードから送信元ノードに向かってルート応答を行う際に、経路の利用できる通信帯域幅の情報を収集して、送信元ノードに伝達する第３のステップと、を備える技術が開示されている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】再表０３／０６１２２０号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
ところで、特許文献１に示すようなオンデマンド方式のプロトコルを用いて経路探索を行うことができないノードや、経路探索方法が異なるネットワークと接続するＬ３ＳＷ（Layer 3 Switch）やルータ装置（以下、中間の通信装置）は、自分のＩＰアドレス以外の宛先に対する経路探索やＡＲＰ（Address Resolution Protocol）  Ｒｅｑｕｅｓｔに対して、代理で応答することで通信パケットを受け取り、別のネットワークに対して経路探索を実行し、経路を確立することで通信の中継を行う。しかし、このような代理応答を実行するノードが、通信パケットを受信した時点で、送信先のノードが属するネットワークにおける経路が確立されていない場合、送信先のノードへの経路の確立に時間がかかる場合がある。そのため、代理応答を実行するノードには、通信パケットをバッファオーバーフローさせないために、十分な容量のメモリを搭載しておく必要があるという問題点があった。
【０００５】
また、中間の通信装置から送信先の通信装置への通信が不可能だった場合には、送信先への経路をみつけることのできない通信パケットが中間の通信装置に送信されてしまい、その通信パケットは無駄になる。
【０００６】
そこで、本発明は、メモリに必要なバッファの容量を少なくするとともに、不要な通信の発生を抑制することが可能なネットワークシステム、通信装置、および、通信方法を提供することを目的としている。
【課題を解決するための手段】
【０００７】
上記課題を解決するために、本発明は、送信元の通信装置と、送信先の通信装置と、中間の通信装置とを少なくとも有し、前記中間の通信装置は、前記送信元の通信装置が属する第１経路構築プロトコルで通信経路を構築する第１サブネットワークと、前記送信先の通信装置が属する前記第１経路構築プロトコルとは異なる第２経路構築プロトコルで通信経路を構築する第２サブネットワークと、を相互に接続する機能を有するネットワークシステムにおいて、前記中間の通信装置は、前記送信先の通信装置を宛先とするパケットを前記送信元の通信装置から受信した場合には、前記送信先の通信装置との間で前記第２経路構築プロトコルに対応する経路探索パケットを送信して経路を確立する経路確立手段と、前記経路確立手段によって前記第２経路構築プロトコルに対応する経路応答パケットが受信されて経路が確立された場合に、前記送信元の通信装置に対して、前記送信先の通信装置に代わって前記第１経路構築プロトコルに対応する経路応答パケットを送信することで代理応答する代理応答手段と、を有し、前記代理応答手段は、前記経路確立手段によって経路が確立されるまで、前記第１経路構築プロトコルに対応する経路応答パケットの送信を保留する、ことを特徴とする。
このような構成によれば、メモリに必要なバッファの容量を少なくするとともに、不要な通信の発生を抑制することが可能になる。
【０００８】
また、本発明は、前記第１経路構築プロトコルは、ＡＯＤＶ（Ad hoc On-Demand Distance Vector）およびＤＳＲ（Dynamic Source Routing）のいずれか一方であり、前記第２経路構築プロトコルは、ＡＯＤＶおよびＤＳＲのいずれか他方であることを特徴とする。
【０００９】
また、本発明は、送信元の通信装置と、送信先の通信装置と、中間の通信装置とを少なくとも有し、前記中間の通信装置は、前記送信元の通信装置が属する第１経路構築プロトコルで通信経路を構築する第１サブネットワークと、前記送信先の通信装置が属する前記第１経路構築プロトコルとは異なる第２経路構築プロトコルで通信経路を構築する第２サブネットワークと、を相互に接続する機能を有するネットワークシステムに用いられる通信装置において、前記中間の通信装置は、前記送信先の通信装置を宛先とするパケットを前記送信元の通信装置から受信した場合には、前記送信先の通信装置との間で前記第２経路構築プロトコルに対応する経路探索パケットを送信して経路を確立する経路確立手段と、前記経路確立手段によって前記第２経路構築プロトコルに対応する経路応答パケットが受信されて経路が確立された場合に、前記送信元の通信装置に対して、前記送信先の通信装置に代わって前記第１経路構築プロトコルに対応する経路応答パケットを送信することで代理応答する代理応答手段と、を有し、前記代理応答手段は、前記経路確立手段によって経路が確立されるまで、前記第１経路構築プロトコルに対応する経路応答パケットの送信を保留する、ことを特徴とする。
【００１０】
また、本発明は、送信元の通信装置と、送信先の通信装置と、中間の通信装置とを少なくとも有し、前記中間の通信装置は、前記送信元の通信装置が属する第１経路構築プロトコルで通信経路を構築する第１サブネットワークと、前記送信先の通信装置が属する前記第１経路構築プロトコルとは異なる第２経路構築プロトコルで通信経路を構築する第２サブネットワークと、を相互に接続する機能を有するネットワークシステムの通信方法において、前記中間の通信装置が前記送信先の通信装置を宛先とするパケットを前記送信元の通信装置から受信した場合には、前記送信先の通信装置との間で前記第２経路構築プロトコルに対応する経路探索パケットを送信して経路を確立する経路確立ステップと、前記経路確立ステップにおいて前記第２経路構築プロトコルに対応する経路応答パケットが受信されて経路が確立された場合に、前記送信元の通信装置に対して、前記送信先の通信装置に代わって前記第１経路構築プロトコルに対応する経路応答パケットを送信することで代理応答する代理応答ステップと、を有し、前記代理応答ステップは、前記経路確立ステップにおいて経路が確立されるまで、前記第１経路構築プロトコルに対応する経路応答パケットの送信を保留する、ことを特徴とする。
【発明の効果】
【００１５】
本発明によれば、メモリに必要なバッファの容量を少なくするとともに、不要な通信の発生を抑制することが可能なネットワークシステム、通信装置、および、通信方法を提供することができる。
【図面の簡単な説明】
【００１６】
【図１】本発明の第１実施形態に係るネットワークシステムの構成例を示す図である。
【図２】図１に示す通信装置の詳細な構成例を示す図である。
【図３】図１に示す第１実施形態の動作を説明するための図である。
【図４】従来例の動作を説明するための図である。
【図５】図１に示す第１実施形態の動作を説明するためのフローチャートである。
【図６】図１に示す第１実施形態の動作を説明するためのフローチャートである。
【図７】本発明の第２実施形態に係るネットワークシステムの構成例を示す図である。
【図８】図７に示す第２実施形態の動作を説明するための図である。
【図９】図７に示す第２実施形態の動作を説明するためのフローチャートである。
【図１０】図７に示す第２実施形態の動作を説明するためのフローチャートである。
【図１１】本発明の第３実施形態に係るネットワークシステムの構成例を示す図である。
【図１２】図１１に示す第３実施形態の動作を説明するための図である。
【図１３】図１１に示す第３実施形態の動作を説明するためのフローチャートである。
【発明を実施するための形態】
【００１７】
次に、本発明の実施形態について説明する。
【００１８】
（Ａ）本発明の第１実施形態の構成の説明
図１は、本発明の第１実施形態に係るネットワークシステムの構成の一例を示す図である。図１に示すように、本発明の第１実施形態に係るネットワークシステムは、ネットワークのノードでとして機能する通信装置１０〜６０によって構成される。
【００１９】
図１の例では、ハッチングを施していない通信装置１０はＡＯＤＶによる経路構築能力を有さず、ハッチングを施している通信装置２０〜６０はＡＯＤＶによる経路構築能力を有している。すなわち、通信装置１０と通信装置３０〜６０とは、独立したサブネットワークにそれぞれ属しており、通信装置２０はこれら独立した２つのサブネットワークを接続する機能を有している。また、通信装置２０〜６０は、オンデマンド方式のプロトコルによる経路構築を行う。
【００２０】
図２は、図１に示す通信装置２０の構成例を示す図である。なお、通信装置１０〜６０は同様の構成とされているので、以下では、通信装置２０を例に挙げて説明する。
【００２１】
図２に示すように、通信装置２０は、パケット中継処理部２１、制御部２２、記憶部２３、および、受信部２４−１〜２４−ｎ、および、送信部２５−１〜２５−ｎを有している。
【００２２】
ここで、パケット中継処理部２１は、制御部２２の制御に応じて、受信部２４−１〜２４−ｎによって受信されたパケットを、そのヘッダに格納されている情報に応じて、対応する送信部２５−１〜２５−ｎから送出する。制御部２２は、記憶部２３に記憶されている経路情報２３ａに応じて、受信したパケットのヘッダを書き換え、パケット中継処理部２１を介して送信する。
【００２３】
記憶部２３は、半導体メモリによって構成され、パケットを転送するための情報である経路情報２３ａを有するとともに、後述するパケット転送に関する処理を実行するためのプログラムやデータを格納している。受信部２４−１〜２４−ｎは、他の通信装置からパケットを受信する。また、送信部２５−１〜２５−ｎは、他の通信装置に対してパケットを送信する。
【００２４】
（Ｂ）本発明の第１実施形態の動作の説明
つぎに、本発明の第１実施形態の動作について説明する。図３は図１に示す第１実施形態の動作を説明するための図である。なお、以下では、まず、図４を参照して従来例の動作を説明し、その後に図３を参照して第１実施形態の動作について説明する。
【００２５】
図４は従来例の動作を説明する図である。ＡＯＤＶプロトコルによる経路構築機能を有しない通信装置１０が、通信装置６０と経路を構築しようとする場合、通信装置１０は、通信装置２０に対して、送信先の通信装置６０のＩＰアドレスを含むＡＲＰ  Ｒｅｑｕｅｓｔパケットを送信する（１）。このようなＡＲＰ  Ｒｅｑｕｅｓｔパケットを受信した通信装置２０は、自己のＭＡＣ（Media Access Control）アドレスを含むＡＲＰ  Ｒｅｐｌｙパケットを通信装置１０に対して送信することで代理応答する（２）。ＡＲＰ  Ｒｅｐｌｙパケットを受信した通信装置１０は、通信装置２０に対してＵＤＰ（User Datagram Protocol）によってデータの送信を開始する（３）。一方、通信装置２０は、通信装置１０から受信したＡＲＰ  Ｒｅｑｕｅｓｔパケットに含まれているＩＰアドレスに対する経路構築をＰｒｏｘｙ  ＡＲＰによって実行する。より詳細には、通信装置２０は、ＡＯＤＶ  Ｒｏｕｔｅ  Ｒｅｑｕｅｓｔパケットを通信装置６０に対して送信する（４）。ＡＯＤＶ  Ｒｏｕｔｅ  Ｒｅｑｕｅｓｔパケットを受信した通信装置６０は、ＡＯＤＶ  Ｒｏｕｔｅ  Ｒｅｐｌｙパケットを通信装置２０に対して送信する（５）。ＡＯＤＶ  Ｒｏｕｔｅ  Ｒｅｐｌｙパケットを受信した通信装置２０は、通信装置１０から受信したデータパケットを、以上の動作によって確立した経路を介して通信装置６０に対して送信する。
【００２６】
ところで、図４に示す従来例では、通信装置１０が通信装置２０からＡＲＰ  Ｒｅｐｌｙパケットを受信すると、その直後から通信装置１０が通信装置２０に対してＵＤＰによってデータパケットの送信を開始する。通信装置２０が通信装置６０に対してＡＯＤＶ  Ｒｏｕｔｅ  Ｒｅｑｕｅｓｔパケットを送信して経路を確立するまでにはある程度の時間を要することから、通信装置２０がその間に通信装置１０から受信するデータパケットは、例えば、記憶部２３に設けたバッファに格納する必要がある。このようなバッファは、経路確立までに要する最大の時間と、最大の通信速度に基づいて余裕を持って設定する必要があることから、かなり大きな容量のバッファを準備する必要があった。
【００２７】
これに対して、第１実施形態では、図３に示すように、通信装置２０が通信装置１０からＡＲＰ  Ｒｅｑｕｅｓｔパケットを受信すると（１）、すぐにＡＲＰ  Ｒｅｐｌｙパケットを送信せずに、送信先である通信装置６０との間での経路確立を先に実行する。すなわち、通信装置２０は、通信装置６０に対してＡＯＤＶ  Ｒｏｕｔｅ  Ｒｅｑｕｅｓｔパケットを送信する（２）。このようなＡＯＤＶ  Ｒｏｕｔｅ  Ｒｅｑｕｅｓｔパケットを受信した通信装置６０は、ＡＯＤＶ  Ｒｏｕｔｅ  Ｒｅｐｌｙパケットを通信装置２０に対して送信する（３）。
【００２８】
ＡＯＤＶ  Ｒｏｕｔｅ  Ｒｅｐｌｙパケットを受信した通信装置２０は、通信装置６０との間で経路を確立する。このようにして経路の確立に成功すると、通信装置２０は、通信装置１０に対してＡＲＰ  Ｒｅｐｌｙパケットを送信することで通信装置６０に代わって代理応答する（４）。通信装置１０は、通信装置２０からＡＲＰ  Ｒｅｐｌｙパケットを受信すると、ＵＤＰによるデータパケットの送信を開始する（５）。
【００２９】
以上に説明したように、第１実施形態では、通信装置２０は、送信元の通信装置１０からＡＲＰ  Ｒｅｑｕｅｓｔパケットを受信した場合には、送信先の通信装置６０との間の経路を確立した後に、通信装置１０に対してＡＲＰ  Ｒｅｐｌｙパケットを送信して代理応答するようにした。これにより、図４に示す従来のように、通信装置６０との間で経路を確立する前に通信装置１０からデータパケットが送信されることを防止できるので、例えば、記憶部２３に確保するバッファの容量を減らすことができる。
【００３０】
また、通信装置２０のバッファの容量を減らすために、例えば、通信装置１０が通信開始しから所定の期間は、通信速度を遅くするといった、特別な構成が不要になるので、通信装置１０として一般的な構成の汎用品を用いることができる。
【００３１】
つぎに、図５および図６を参照して、図１に示す第１実施形態において実行される処理について説明する。図５は、図１に示す通信装置１０において実行される処理の一例を説明するフローチャートである。図５に示すフローチャートが開始されると、以下のステップが実行される。
【００３２】
ステップＳ１０では、通信装置１０の図示しない制御部１２は、送信先ノードのＩＰアドレスを特定する。例えば、制御部１２は、送信先ノードである通信装置６０のＩＰアドレスを特定する。
【００３３】
ステップＳ１１では、通信装置１０の図示しない制御部１２は、ＡＯＤＶノード（ＡＯＤＶプロトコルによる経路構築機能を有するノード）に対してＡＲＰ  Ｒｅｑｕｅｓｔパケットを送信する。例えば、通信装置１０は、送信先ノードである通信装置６０のＩＰアドレスをＭＡＣアドレス探索対象とするＡＲＰ  Ｒｅｑｕｅｓｔパケットを通信装置２０に対して送信する。もしくは通信装置１０は、デスティネーションＩＰアドレス（dest IP）を通信装置６０のＩＰアドレスとするＡＲＰ  Ｒｅｑｕｅｓｔパケットを通信装置２０に対して送信する。
【００３４】
ステップＳ１２では、通信装置１０の図示しない制御部１２は、ＡＯＤＶノードからＡＲＰ  Ｒｅｐｌｙパケットを受信したか否かを判定し、ＡＲＰ  Ｒｅｐｌｙパケットを受信したと判定した場合（ステップＳ１２：Ｙ）にはステップＳ１３に進み、それ以外の場合（ステップＳ１２：Ｎ）には同様の処理を繰り返す。例えば、ＡＯＤＶノードである通信装置２０からＡＲＰ  Ｒｅｐｌｙパケットを受信した場合にはＹと判定してステップＳ１３に進む。
【００３５】
ステップＳ１３では、通信装置１０の図示しない制御部１２は、ＡＯＤＶノードに対してデータパケットの送信を開始する。例えば、ＡＯＤＶノードである通信装置２０に対してデータパケットをＵＤＰによって送信する。
【００３６】
つぎに、図６は、図１に示す通信装置２０において実行される処理の一例を説明するフローチャートである。図６に示すフローチャートが開始されると、以下のステップが実行される。
【００３７】
ステップＳ３０では、通信装置２０の制御部２２は、ＡＲＰ  Ｒｅｑｕｅｓｔパケットを受信したか否かを判定し、受信したと判定した場合（ステップＳ３０：Ｙ）にはステップＳ３０に進み、それ以外の場合（ステップＳ３０：Ｎ）には処理を終了する。例えば、通信装置１０からＡＲＰ  Ｒｅｑｕｅｓｔパケットを受信した場合にはＹと判定してステップＳ３０に進む。
【００３８】
ステップＳ３１では、通信装置２０の制御部２２は、ＡＲＰ  ＲｅｑｕｅｓｔパケットからデスティネーションＩＰアドレス（dest IP）を取得する。例えば、送信先が通信装置６０であるＡＲＰ  Ｒｅｑｕｅｓｔパケットの場合にはデスティネーションＩＰアドレスとして通信装置６０のＩＰアドレスが取得される。
【００３９】
ステップＳ３２では、通信装置２０の制御部２２は、ステップＳ３１で取得したデスティネーションＩＰアドレスを宛先とするＲＲＥＱ（Route Request）パケットを生成する。例えば、送信先が通信装置６０である場合には、通信装置６０を宛先とするＡＯＤＶ  Ｒｏｕｔｅ  Ｒｅｑｕｅｓｔパケットが生成される。
【００４０】
ステップＳ３３では、通信装置２０の制御部２２は、ステップＳ３２で生成したＲＲＥＱパケットを、他の通信装置に対してブロードキャストする。例えば、図１の例では、ＡＯＤＶ  Ｒｏｕｔｅ  Ｒｅｑｕｅｓｔパケットは、通信装置３０，４０，５０を介して通信装置６０に伝送される。通信装置６０は、ＡＯＤＶ  Ｒｏｕｔｅ  Ｒｅｑｕｅｓｔパケットを受信し、ＩＰアドレスを参照して当該パケットが自己宛であることを認識すると、ＡＯＤＶ  ＲＲＥＰ（Route Reply）パケットを、通信装置５０，４０，３０を介して通信装置２０に送信する。
【００４１】
ステップＳ３４では、通信装置２０の制御部２２は、ＲＲＥＰパケットを受信したか否かを判定し、受信したと判定した場合（ステップＳ３４：Ｙ）にはステップＳ３５に進み、それ以外の場合（ステップＳ３４：Ｎ）には同様の処理を繰り返す。例えば、通信装置６０からＡＯＤＶ  Ｒｏｕｔｅ  Ｒｅｐｌｙパケットを受信した場合にはＹと判定してステップＳ３５に進む。
【００４２】
ステップＳ３５では、通信装置２０の制御部２２は、自己のＭＡＣアドレスを含むＡＲＰ  Ｒｅｐｌｙパケットを生成する。例えば、送信先が通信装置６０である場合には、ステップＳ３１で取得した通信装置６０のＩＰアドレスと自己のＭＡＣアドレスとを含むＡＲＰ  Ｒｅｐｌｙパケットを生成する。
【００４３】
ステップＳ３６では、通信装置２０の制御部２２は、ステップＳ３５で生成したＡＲＰ  Ｒｅｐｌｙパケットを送信することで代理応答する。例えば、通信装置１０が送信元である場合には、通信装置１０に対してＡＲＰ  Ｒｅｐｌｙパケットを送信することで通信装置６０に代わって代理応答する。これにより、送信元の通信装置１０では、ステップＳ１２においてＹと判定し、ステップＳ１２に進んで、データパケットの送信を開始する。
【００４４】
ステップＳ３７では、通信装置２０の制御部２２は、送信元ノードと送信先ノードとの間での通信を仲介する。例えば、送信元ノードが通信装置１０であり、送信先ノードが通信装置６０である場合には、通信装置２０はこれらの間での通信の仲介を実行する。これにより、通信装置１０から通信装置６０に向けてデータパケットが送信される。
【００４５】
以上に説明したように、図５および図６に示すフローチャートによれば、図３を参照して前述した動作を実現できる。
【００４６】
（Ｃ）本発明の第２実施形態の構成の説明
図７は、本発明の第２実施形態に係るネットワークシステムの構成の一例を示す図である。図７に示すように、本発明の第２実施形態に係るネットワークシステムは、ネットワークのノードでとして機能する通信装置１０〜６０によって構成される。なお、通信装置２０は、図２と同様の構成とされ、また、通信装置１０，３０〜６０は通信装置２０と同様の構成とされている。
【００４７】
図７の例では、ハッチングを施していない通信装置６０はＡＯＤＶによる経路構築能力を有さず、ハッチングを施している通信装置１０〜５０はＡＯＤＶによる経路構築能力を有している。すなわち、通信装置１０，３０，４０，５０と通信装置６０とは、独立したサブネットワークにそれぞれ属しており、通信装置２０はこれら独立した２つのサブネットワークを接続する機能を有している。また、通信装置１０〜５０は、オンデマンド方式のプロトコルによる経路構築を行う。
【００４８】
（Ｄ）本発明の第２実施形態の動作の説明
つぎに、図８を参照して、図７に示す第２実施形態の動作について説明する。なお、以下では、通信装置１０が送信元ノードであり、通信装置６０が送信先ノードであり、通信装置２０が代理応答する中間ノードとして動作する場合を例に挙げて説明する。また、以下では、従来例の動作について簡単に説明した後、第２実施形態の動作について説明する。
【００４９】
従来例において、送信元の通信装置１０から送信先の通信装置６０に対してデータパケットを送信する場合、通信装置１０は、通信装置６０のＩＰアドレスを宛先とするＡＯＤＶ  Ｒｏｕｔｅ  Ｒｅｑｕｅｓｔパケットをブロードキャストする。このようなＡＯＤＶ  Ｒｏｕｔｅ  Ｒｅｑｕｅｓｔパケットを通信装置２０が受信すると、ＩＰアドレスが自己宛ではなく、配下の通信装置６０宛であることから、代理応答を実行する。すなわち、送信元の通信装置１０に対してＡＯＤＶ  Ｒｏｕｔｅ  Ｒｅｐｌｙパケットを送信する。この結果、ＡＯＤＶ  Ｒｏｕｔｅ  Ｒｅｐｌｙパケットを受信した通信装置１０は、通信装置６０に向けてデータパケットの送信を開始する。一方、通信装置２０は、通信装置６０に対してＡＲＰ  Ｒｅｑｕｅｓｔパケットを送信し、その結果として、通信装置６０からＡＲＰ  Ｒｅｐｌｙパケットを受信する。ＡＲＰ  Ｒｅｐｌｙパケットを受信した通信装置２０は、通信装置１０から受信してバッファに格納しているデータパケットを通信装置６０に送信する。このため、従来例では、通信装置２０と通信装置６０の間で経路が確立される前に通信装置１０からデータパケットが送信されるので、通信装置２０は最悪のケースを想定してバッファの容量を準備しなければならなかった。
【００５０】
つぎに、図８を参照して、第２実施形態の動作について説明する。第２実施形態では、送信元である通信装置１０が送信先である通信装置６０に対してＡＯＤＶ  Ｒｏｕｔｅ  Ｒｅｑｕｅｓｔパケットをブロードキャストすると、図８に示す経路を伝送された同パケットは通信装置２０によって受信される（１）。通信装置２０は、ＩＰアドレスが自己宛ではなく、配下の通信装置６０宛であることから、まず、通信装置６０がＡＲＰテーブルに登録されているか否かを判定し、登録されていない場合には通信装置６０に対してＡＲＰ  Ｒｅｑｕｅｓｔパケットを送信する（２）。そして、通信装置６０からＡＲＰ  Ｒｅｐｌｙパケットを受信した場合（３）には、通信装置６０をＡＲＰテーブルに登録した後に、送信元である通信装置１０に対してＡＯＤＶ  Ｒｏｕｔｅ  Ｒｅｐｌｙパケットを送信する（４）。また、通信装置６０がＡＲＰテーブルに登録されている場合には、経路は確立済みと判断して、ＡＲＰ  Ｒｅｑｕｅｓｔパケットは送信せずに、送信元である通信装置１０に対してＡＯＤＶ  Ｒｏｕｔｅ  Ｒｅｐｌｙパケットを送信する。
【００５１】
通信装置１０がＡＯＤＶ  Ｒｏｕｔｅ  Ｒｅｐｌｙパケットを受信すると、通信装置１０と通信装置２０の間の経路が確立されるので、通信装置１０は通信装置２０に対してデータパケットの送信を開始する（５）。
【００５２】
以上の動作によれば、代理応答する中間ノードである通信装置２０は、通信装置６０との間の経路が確立してからＡＯＤＶ  Ｒｏｕｔｅ  Ｒｅｐｌｙパケットを送信するので、通信装置６０との間の経路が確立する前からデータパケットが送信されることを防止できる。このため、通信装置２０が備えるべきバッファの容量を減らすことができる。
【００５３】
つぎに、図９および図１０を参照して、第２実施形態において実行される処理について説明する。
【００５４】
図９は、図７に示す中間ノードである通信装置２０において実行される処理の一例を示すフローチャートである。このフローチャートの処理が開始されると、以下のステップが実行される。
【００５５】
ステップＳ５０では、通信装置２０の制御部２２は、ＡＯＤＶのＲＲＥＱ（Ｒｏｕｔｅ  Ｒｅｑｕｅｓｔ）パケットを受信したか否かを判定し、受信したと判定した場合（ステップＳ５０：Ｙ）にはステップＳ５１に進み、それ以外の場合（ステップＳ５０：Ｎ）には処理を終了する。例えば、通信装置１０からＡＯＤＶ  Ｒｏｕｔｅ  Ｒｅｑｕｅｓｔパケットを受信した場合にはステップＳ５１に進む。
【００５６】
ステップＳ５１では、通信装置２０の制御部２２は、ステップＳ５０で受信したＲＲＥＱパケットの宛先が代理応答する対象のノードか否かを判定し、宛先が代理対象ノードである場合（ステップＳ５１：Ｙ）にはステップＳ５２に進み、それ以外の場合（ステップＳ５１：Ｎ）にはステップＳ５３に進む。例えば、代理対象ノードである通信装置６０がＡＯＤＶ  Ｒｏｕｔｅ  Ｒｅｑｕｅｓｔパケットの宛先である場合にはＹと判定してステップＳ５２に進む。
【００５７】
ステップＳ５２では、通信装置２０の制御部２２は、送信先である代理対象ノードがＡＲＰテーブルに登録済みか否かを判定し、登録済みと判定した場合（ステップＳ５２：Ｙ）にはステップＳ５７に進み、それ以外の場合にはステップＳ５４に進む。例えば、図７の例では、代理対象ノードである通信装置６０がＡＲＰテーブルに登録されている場合にはＹと判定してステップＳ５７に進み、登録されていない場合にはＮと判定してステップＳ５４に進む。
【００５８】
ステップＳ５３では、通信装置２０の制御部２２は、宛先が自己宛である場合には、ＡＯＤＶ  ＲＲＥＰパケットを送信元に向けて送信する。なお、宛先が自己宛でなく、また、代理対象ノード宛でもない場合には、他の通信装置に対してＡＯＤＶ  ＲＲＥＱパケットをブロードキャストする。
【００５９】
ステップＳ５４では、通信装置２０の制御部２２は、代理対象ノードに対してＡＲＰ  Ｒｅｑｕｅｓｔパケットを送信する。例えば、通信装置２０は、代理対象ノードである通信装置６０に対してＡＲＰ  Ｒｅｑｕｅｓｔパケットを送信する。
【００６０】
ステップＳ５５では、通信装置２０の制御部２２は、代理対象ノードからＡＲＰ  Ｒｅｐｌｙパケットを受信する。例えば、通信装置２０は、代理対象ノードである通信装置６０からＡＲＰ  Ｒｅｐｌｙパケットを受信する。
【００６１】
ステップＳ５６では、通信装置２０の制御部２２は、ステップＳ５５で受信したＡＲＰ  Ｒｅｐｌｙパケットを参照して代理対象ノードに関する情報をＡＲＰテーブルに登録する。例えば、代理対象ノードである通信装置６０のＩＰアドレスとＭＡＣアドレスを対応付けてＡＲＰテーブルに登録する。
【００６２】
ステップＳ５７では、通信装置２０の制御部２２は、ＲＲＥＰパケットをＲＲＥＱパケットの送信元に向けて送信する。これにより、送信元と送信先のノード間で経路が確立される。例えば、通信装置２０は、ＡＯＤＶ  Ｒｏｕｔｅ  Ｒｅｑｕｅｓｔパケットの送信元である通信装置１０に対してＡＯＤＶ  Ｒｏｕｔｅ  Ｒｅｐｌｙパケットを送信する。この結果、通信装置１０と通信装置２０の間でＡＯＤＶプロトコルに基づく経路が確立される。
【００６３】
ステップＳ５８では、通信装置２０の制御部２２は、送信元ノードと送信先ノードの間の通信を仲介する。例えば、中間ノードである通信装置２０は、送信元ノードである通信装置１０から送信されるデータパケットを受信して、送信先ノードである通信装置６０に転送する仲介処理を実行する。
【００６４】
つぎに、図１０を参照して、図７に示す送信先ノードである通信装置６０において実行される処理について説明する。図１０に示すフローチャートの処理が開始されると、以下のステップが実行される。
【００６５】
ステップＳ７０では、通信装置６０の図示しない制御部６２は、ＡＲＰ  Ｒｅｑｕｅｓｔパケットを受信したか否かを判定し、受信したと判定した場合（ステップＳ７０：Ｙ）にはステップＳ７１に進み、それ以外の場合（ステップＳ７０：Ｎ）には処理を終了する。例えば、通信装置２０からＡＲＰ  Ｒｅｑｕｅｓｔパケットを受信した場合にはＹと判定してステップＳ７１に進む。
【００６６】
ステップＳ７１では、通信装置６０の図示しない制御部６２は、ＡＲＰ  Ｒｅｑｕｅｓｔパケットの送信元に対してＡＲＰ  Ｒｅｐｌｙパケットを送信する。例えば、通信装置２０がＡＲＰ  Ｒｅｑｕｅｓｔパケットの送信元である場合には、通信装置２０に対してＡＲＰ  Ｒｅｐｌｙパケットを送信する。この結果、通信装置２０では、ステップＳ５５，Ｓ５６の処理によって、通信装置６０に関する情報をＡＲＰテーブルに登録する。
【００６７】
ステップＳ７２では、通信装置６０の図示しない制御部６２は、ＡＯＤＶノードを介して送信元ノードから送信されるデータパケットを受信する。例えば、送信先ノードである通信装置６０は、ＡＯＤＶノードである通信装置２０を介して送信元ノードである通信装置１０から送信されるデータパケットを受信する。
【００６８】
以上の処理によれば、図８を参照して前述した動作を実現することができる。
【００６９】
（Ｅ）本発明の第３実施形態の構成の説明
図１１は、本発明の第３実施形態に係るネットワークシステムの構成の一例を示す図である。図１１に示すように、本発明の第３実施形態に係るネットワークシステムは、ネットワークのノードでとして機能する通信装置１０〜７０によって構成される。なお、通信装置２０は、図２と同様の構成とされ、また、通信装置１０，３０〜７０は通信装置２０と同様の構成とされている。
【００７０】
図１１の例では、通信装置１０，３０，４０はＡＯＤＶによる経路構築能力を有し、通信装置５０〜７０はＤＳＲ（Dynamic Source Routing）による経路構築能力を有している。また、２つのサブネットワークを接続する接点位置に位置する通信装置２０は、ＡＯＤＶおよびＤＳＲの双方の経路構築能力を有している。すなわち、通信装置１０，３０，４０と通信装置５０〜６０とは、独立したサブネットワークにそれぞれ属しており、通信装置２０はこれら独立した２つのサブネットワークを接続する機能を有している。また、図１１の例では、通信装置１０，３０，４０によるサブネットワークと、通信装置５０〜６０によるサブネットワークの双方がオンデマンド方式のプロトコルによる経路構築を行う。
【００７１】
（Ｆ）本発明の第３実施形態の動作の説明
つぎに、図１２を参照して、図１１に示す第３実施形態の動作について説明する。なお、以下では、通信装置１０が送信元ノードであり、通信装置６０が送信先ノードであり、通信装置２０が中間ノードとして動作する場合を例に挙げて説明する。また、以下では、従来例の動作について簡単に説明した後、第３実施形態の動作について説明する。
【００７２】
従来例において、送信元の通信装置１０から送信先の通信装置６０に対してデータパケットを送信する場合、通信装置１０は、通信装置６０のＩＰアドレスを宛先とするＡＯＤＶ  Ｒｏｕｔｅ  Ｒｅｑｕｅｓｔパケットをブロードキャストする。このようなＡＯＤＶ  Ｒｏｕｔｅ  Ｒｅｑｕｅｓｔパケットを通信装置２０が受信すると、ＩＰアドレスが自己宛ではなく、ＤＳＲに基づくネットワークに接続される通信装置６０であることから、代理応答を実行する。すなわち、送信元の通信装置１０に対してＡＯＤＶ  Ｒｏｕｔｅ  Ｒｅｐｌｙパケットを送信する。この結果、ＡＯＤＶ  Ｒｏｕｔｅ  Ｒｅｐｌｙパケットを受信した通信装置１０は、通信装置２０に向けてデータパケットの送信を開始する。その後、通信装置２０は、通信装置６０との間でＤＳＲに基づく経路確立処理を実行する。通信装置６０との間でＤＳＲに基づく経路の確立に成功した通信装置２０は、通信装置１０から受信してバッファに格納しているデータパケットを通信装置６０に送信する。このため、従来例では、通信装置２０と通信装置６０の間でＤＳＲに基づく経路が確立される前に通信装置１０からデータパケットが送信されるので、通信装置２０は最悪のケースを想定してバッファの容量を準備しなければならなかった。
【００７３】
つぎに、図１２を参照して、第３実施形態の動作について説明する。第３実施形態では、送信元である通信装置１０が送信先である通信装置６０に対してＡＯＤＶ  Ｒｏｕｔｅ  Ｒｅｑｕｅｓｔパケットをブロードキャストすると、図１２に示す経路を伝送された同パケットについては通信装置２０によって受信される（１）。通信装置２０は、ＩＰアドレスが自己宛ではなく、配下の通信装置６０宛である場合、まず、通信装置６０がルートテーブルに登録されているか否かを判定し、登録されていない場合には通信装置６０に対してＤＳＲ  Ｒｏｕｔｅ  Ｒｅｑｕｅｓｔパケットを送信する（２）。そして、通信装置６０からＤＳＲ  Ｒｏｕｔｅ  Ｒｅｐｌｙパケットを受信した場合（３）には、通信装置６０をルートテーブルに登録した後に、送信元である通信装置１０に対してＡＯＤＶ  Ｒｏｕｔｅ  Ｒｅｐｌｙパケットを送信する（４）。また、通信装置６０がルートテーブルに登録されている場合には、経路は確立済みと判定してＤＳＲ  Ｒｏｕｔｅ  Ｒｅｑｕｅｓｔパケットは送信せずに、送信元である通信装置１０に対してＡＯＤＶ  Ｒｏｕｔｅ  Ｒｅｐｌｙパケットを送信する。
【００７４】
通信装置１０がＡＯＤＶ  Ｒｏｕｔｅ  Ｒｅｐｌｙパケットを受信すると、通信装置１０と通信装置２０の間でＡＯＤＶに基づく経路が確立されるので、通信装置１０は通信装置２０に対してＵＤＰによるデータパケットの送信を開始する（５）。
【００７５】
以上の動作によれば、代理応答する中間ノードである通信装置２０は、通信装置６０との間でＤＳＲに基づく経路が確立してからＡＯＤＶ  Ｒｏｕｔｅ  Ｒｅｐｌｙパケットを送信するので、通信装置６０との間の経路が確立する前からデータパケットが送信されることを防止できる。このため、通信装置２０が備えるべきバッファの容量を減らすことができる。
【００７６】
つぎに、図１３を参照して、第３実施形態において実行される処理について説明する。図１３は、図１１に示す通信装置２０において実行される処理の一例を説明するためのフローチャートである。このフローチャートの処理が開始されると、以下のステップが実行される。
【００７７】
ステップＳ９０では、通信装置２０の制御部２２は、ＡＯＤＶ  ＲＲＥＱ（Ｒｏｕｔｅ  Ｒｅｑｕｅｓｔ）パケットを受信したか否かを判定し、受信したと判定した場合（ステップＳ９０：Ｙ）にはステップＳ９１に進み、それ以外の場合（ステップＳ９０：Ｎ）には処理を終了する。例えば、通信装置１０からＡＯＤＶ  Ｒｏｕｔｅ  Ｒｅｑｕｅｓｔパケットを受信した場合にはステップＳ９１に進む。
【００７８】
ステップＳ９１では、通信装置２０の制御部２２は、ステップＳ９０で受信したＡＯＤＶ  ＲＲＥＱパケットの送信先が代理対象ノードか否かを判定し、送信先が代理対象ノードである場合（ステップＳ９１：Ｙ）にはステップＳ９２に進み、それ以外の場合（ステップＳ９１：Ｎ）にはステップＳ９３に進む。例えば、代理対象ノードである通信装置６０がＡＯＤＶ  Ｒｏｕｔｅ  Ｒｅｑｕｅｓｔパケットの宛先である場合にはＹと判定してステップＳ９２に進む。
【００７９】
ステップＳ９２では、通信装置２０の制御部２２は、送信先である代理対象ノードがルートテーブルに登録されているか否かを判定し、登録されていると判定した場合（ステップＳ９２：Ｙ）にはステップＳ９７に進み、それ以外の場合にはステップＳ９４に進む。例えば、図１１の例では、代理対象ノードである通信装置６０がルートテーブルに登録されている場合にはＹと判定してステップＳ９６に進み、登録されていない場合にはＮと判定してステップＳ９４に進む。
【００８０】
ステップＳ９３では、通信装置２０の制御部２２は、宛先が自己宛である場合には、ＡＯＤＶ  ＲＲＥＰパケットを送信元に向けて送信する。なお、宛先が自己宛でなく、また、代理対象ノード宛でもない場合には、他の通信装置に対してＡＯＤＶ  ＲＲＥＱパケットを転送する。
【００８１】
ステップＳ９４では、通信装置２０の制御部２２は、代理対象ノードに対してＤＳＲ  ＲＲＥＱ（Ｒｏｕｔｅ  Ｒｅｑｕｅｓｔ）パケットを送信して経路構築を実行する。例えば、通信装置２０は、代理対象ノードである通信装置６０に対してＤＳＲ  Ｒｏｕｔｅ  Ｒｅｑｕｅｓｔパケットを送信する。
【００８２】
ステップＳ９５では、通信装置２０の制御部２２は、代理対象ノードからＤＳＲ  ＲＲＥＰ（Ｒｏｕｔｅ  Ｒｅｐｌｙ）パケットを受信する。例えば、通信装置２０は、代理対象ノードである通信装置６０からＤＳＲ  Ｒｏｕｔｅ  Ｒｅｐｌｙパケットを受信する。
【００８３】
ステップＳ９６では、通信装置２０の制御部２２は、ステップＳ９５で受信したＤＳＲ  ＲＲＥＰパケットを参照して、代理対象ノードに関する情報をルートテーブルに登録する。例えば、通信装置２０は、代理対象ノードである通信装置６０のＩＰアドレスとＭＡＣを対応付けてルートテーブルに登録する。この結果、通信装置２０と通信装置６０の間でＤＳＲプロトコルによる経路が確立される。
【００８４】
ステップＳ９７では、通信装置２０の制御部２２は、ＡＯＤＶ  ＲＲＥＰパケットをＲＲＥＱパケットの送信元に向けて送信する。これにより、送信元と送信先のノード間で経路が確立される。例えば、通信装置２０は、ＡＯＤＶ  Ｒｏｕｔｅ  Ｒｅｑｕｅｓｔパケットの送信元である通信装置１０に対してＡＯＤＶ  Ｒｏｕｔｅ  Ｒｅｐｌｙパケットを送信する。この結果、通信装置１０と通信装置２０の間でＡＯＤＶプロトコルに基づく経路が確立される。
【００８５】
ステップＳ９８では、通信装置２０の制御部２２は、送信元ノードと送信先ノードの間の通信を仲介する。例えば、中間ノードである通信装置２０は、送信元ノードである通信装置１０から送信されるデータパケットを受信して、送信先ノードである通信装置６０に転送する仲介処理を実行する。
【００８６】
以上の処理によれば、図１２を参照して前述した動作を実現することができる。
【００８７】
（Ｇ）変形実施形態の説明
以上の実施形態は一例であって、本発明が上述したような場合のみに限定されるものでないことはいうまでもない。例えば、以上の第１〜第３実施形態では、通信装置１０〜７０は、有線接続される場合を例に挙げて説明したが、これらが無線接続される構成としてもよい。なお、その場合には、図２に示す構成は、受信部２４−１〜２４−ｎおよび送信部２５−１〜２５−ｎの代わりに、電波による送受信部を設けるようにすればよい。
【００８８】
また、以上の第１〜第３実施形態では、図面を簡略化するために通信装置の一部を示すようにしたが、実際には図示した以外の通信装置が存在するようにしてもよい。
【００８９】
また、第２実施形態では、図９に示すフローチャートにおいて、代理対象ノードがＡＲＰテーブルに登録されていない場合にのみ、代理対象ノードに対してＡＲＰ  Ｒｅｑｕｅｓｔを送信するようにしたが、登録されている場合にもＡＲＰ  Ｒｅｑｕｅｓｔを送信するようにしてもよい。そのような構成によれば、登録はされていても、登録内容が正しくない場合に対応することができる。同様に、第３実施形態においても、送信先がルートテーブルに登録されている場合であっても、ＤＳＲ経路構築処理を実行するようにしてもよい。そのような構成によれば、ルートテーブルに登録はされていても、登録内容が正しくない場合に対応することができる。
【００９０】
また、図１２に示す第３実施形態では、ＡＯＤＶとＤＳＲの組み合わせとしたが、これら以外の組み合わせのネットワークに本発明を適用するようにしてもよい。
【００９１】
また、本発明を適用可能なサブネットワークは、Ｌ（Layer）３ネットワークには限定されない。例えば、Ｌ２ネットワークをサブネットワークとして使用することも可能である。すなわち、サブネットワークとして、Ｌ３ネットワーク同士の組み合わせのみならず、Ｌ３ネットワークとＬ２ネットワークの組み合わせに対して、本発明を適用することも可能である。
【符号の説明】
【００９２】
１０〜７０  通信装置
２１  パケット中継処理部
２２  制御部
２３  記憶部
２３ａ  経路情報
２４−１〜２４−ｎ  受信部
２５−１〜２５−ｎ  送信部
【図１】
0006754200.tif 000002
【図２】
0006754200.tif 000003
【図３】
0006754200.tif 000004
【図４】
0006754200.tif 000005
【図５】
0006754200.tif 000006
【図６】
0006754200.tif 000007
【図７】
0006754200.tif 000008
【図８】
0006754200.tif 000009
【図９】
0006754200.tif 000010
【図１０】
0006754200.tif 000011
【図１１】
0006754200.tif 000012
【図１２】
0006754200.tif 000013
【図１３】
0006754200.tif 000014