特許第6754200号(P6754200)IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ 古河電気工業株式会社の特許一覧

特許6754200ネットワークシステム、通信装置、および、通信方法
<>
  • 特許6754200-ネットワークシステム、通信装置、および、通信方法 図000002
  • 特許6754200-ネットワークシステム、通信装置、および、通信方法 図000003
  • 特許6754200-ネットワークシステム、通信装置、および、通信方法 図000004
  • 特許6754200-ネットワークシステム、通信装置、および、通信方法 図000005
  • 特許6754200-ネットワークシステム、通信装置、および、通信方法 図000006
  • 特許6754200-ネットワークシステム、通信装置、および、通信方法 図000007
  • 特許6754200-ネットワークシステム、通信装置、および、通信方法 図000008
  • 特許6754200-ネットワークシステム、通信装置、および、通信方法 図000009
  • 特許6754200-ネットワークシステム、通信装置、および、通信方法 図000010
  • 特許6754200-ネットワークシステム、通信装置、および、通信方法 図000011
  • 特許6754200-ネットワークシステム、通信装置、および、通信方法 図000012
  • 特許6754200-ネットワークシステム、通信装置、および、通信方法 図000013
  • 特許6754200-ネットワークシステム、通信装置、および、通信方法 図000014
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】6754200
(24)【登録日】2020年8月25日
(45)【発行日】2020年9月9日
(54)【発明の名称】ネットワークシステム、通信装置、および、通信方法
(51)【国際特許分類】
   H04L 12/715 20130101AFI20200831BHJP
【FI】
   H04L12/715
【請求項の数】4
【全頁数】16
(21)【出願番号】特願2016-46354(P2016-46354)
(22)【出願日】2016年3月9日
(65)【公開番号】特開2017-163361(P2017-163361A)
(43)【公開日】2017年9月14日
【審査請求日】2017年6月12日
【審判番号】不服2019-3385(P2019-3385/J1)
【審判請求日】2019年3月11日
(73)【特許権者】
【識別番号】000005290
【氏名又は名称】古河電気工業株式会社
(74)【代理人】
【識別番号】100205659
【弁理士】
【氏名又は名称】齋藤 拓也
(74)【代理人】
【識別番号】100114292
【弁理士】
【氏名又は名称】来間 清志
(74)【代理人】
【識別番号】100130247
【弁理士】
【氏名又は名称】江村 美彦
(72)【発明者】
【氏名】力宗 真寛
(72)【発明者】
【氏名】熊谷 篤
(72)【発明者】
【氏名】辻 勇斗
(72)【発明者】
【氏名】三浦 昌之
【合議体】
【審判長】 稲葉 和生
【審判官】 岩田 玲彦
【審判官】 小田 浩
(56)【参考文献】
【文献】 福井 雅人 他、「異種無線ネットワーク相互通信方式の結合ポイント選定シミュレーション」、電子情報通信学会技術研究報告(信学技報)、第107巻、第378号、2007年12月6日、pp.61−66(IN2007−109)
【文献】 伊藤 将志 他、「シームレスハンドオーバを実現する無線メッシュネットワークの提案とシミュレーション評価」、マルチメディア,分散,協調とモバイル(DICOMO2007)シンポジウム 発表資料[オンライン]、2007年、[検索日2017.05.19],インターネット:<URL:http://www.wata−lab.meijo−u.ac.jp/file/convention/2007/200706−DICOMO−Masashi_Ito.pdf>
【文献】 加藤 佳之 他、「無線アクセスポイントリンク”WAPL”の提案と評価」、マルチメディア,分散,協調とモバイル(DICOMO2007)シンポジウム 発表資料[オンライン]、2007年、[検索日2018.11.27],インターネット:<URL:http://www.wata−lab.meijo−u.ac.jp/file/convention/2007/200706−DICOMO−Yoshiyuki_Kato.pdf>,<URL:http://www.dicomo.org/2007/program/1A_abst.html>
(58)【調査した分野】(Int.Cl.,DB名)
H04L 12/715
(57)【特許請求の範囲】
【請求項1】
送信元の通信装置と、送信先の通信装置と、中間の通信装置とを少なくとも有し、前記中間の通信装置は、前記送信元の通信装置が属する第1経路構築プロトコルで通信経路を構築する第1サブネットワークと、前記送信先の通信装置が属する前記第1経路構築プロトコルとは異なる第2経路構築プロトコルで通信経路を構築する第2サブネットワークと、を相互に接続する機能を有するネットワークシステムにおいて、
前記中間の通信装置は、
前記送信先の通信装置を宛先とするパケットを前記送信元の通信装置から受信した場合には、前記送信先の通信装置との間で前記第2経路構築プロトコルに対応する経路探索パケットを送信して経路を確立する経路確立手段と、
前記経路確立手段によって前記第2経路構築プロトコルに対応する経路応答パケットが受信されて経路が確立された場合に、前記送信元の通信装置に対して、前記送信先の通信装置に代わって前記第1経路構築プロトコルに対応する経路応答パケットを送信することで代理応答する代理応答手段と、を有
前記代理応答手段は、前記経路確立手段によって経路が確立されるまで、前記第1経路構築プロトコルに対応する経路応答パケットの送信を保留する、
ことを特徴とするネットワークシステム。
【請求項2】
前記第1経路構築プロトコルは、AODV(Ad hoc On-Demand Distance Vector)およびDSR(Dynamic Source Routing)のいずれか一方であり、前記第2経路構築プロトコルは、AODVおよびDSRのいずれか他方であることを特徴とする請求項1に記載の通信装置。
【請求項3】
送信元の通信装置と、送信先の通信装置と、中間の通信装置とを少なくとも有し、前記中間の通信装置は、前記送信元の通信装置が属する第1経路構築プロトコルで通信経路を構築する第1サブネットワークと、前記送信先の通信装置が属する前記第1経路構築プロトコルとは異なる第2経路構築プロトコルで通信経路を構築する第2サブネットワークと、を相互に接続する機能を有するネットワークシステムに用いられる通信装置において、
前記中間の通信装置は、
前記送信先の通信装置を宛先とするパケットを前記送信元の通信装置から受信した場合には、前記送信先の通信装置との間で前記第2経路構築プロトコルに対応する経路探索パケットを送信して経路を確立する経路確立手段と、
前記経路確立手段によって前記第2経路構築プロトコルに対応する経路応答パケットが受信されて経路が確立された場合に、前記送信元の通信装置に対して、前記送信先の通信装置に代わって前記第1経路構築プロトコルに対応する経路応答パケットを送信することで代理応答する代理応答手段と、を有
前記代理応答手段は、前記経路確立手段によって経路が確立されるまで、前記第1経路構築プロトコルに対応する経路応答パケットの送信を保留する、
ことを特徴とする通信装置。
【請求項4】
送信元の通信装置と、送信先の通信装置と、中間の通信装置とを少なくとも有し、前記中間の通信装置は、前記送信元の通信装置が属する第1経路構築プロトコルで通信経路を構築する第1サブネットワークと、前記送信先の通信装置が属する前記第1経路構築プロトコルとは異なる第2経路構築プロトコルで通信経路を構築する第2サブネットワークと、を相互に接続する機能を有するネットワークシステムの通信方法において、
前記中間の通信装置が前記送信先の通信装置を宛先とするパケットを前記送信元の通信装置から受信した場合には、前記送信先の通信装置との間で前記第2経路構築プロトコルに対応する経路探索パケットを送信して経路を確立する経路確立ステップと、
前記経路確立ステップにおいて前記第2経路構築プロトコルに対応する経路応答パケットが受信されて経路が確立された場合に、前記送信元の通信装置に対して、前記送信先の通信装置に代わって前記第1経路構築プロトコルに対応する経路応答パケットを送信することで代理応答する代理応答ステップと、を有
前記代理応答ステップは、前記経路確立ステップにおいて経路が確立されるまで、前記第1経路構築プロトコルに対応する経路応答パケットの送信を保留する、
ことを特徴とする通信方法。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、ネットワークシステム、通信装置、および、通信方法に関するものである。
【背景技術】
【0002】
特許文献1には、AODV(Ad hoc On-Demand Distance Vector)プロトコルを用いて、送信元ノードから中間ノードを経由して送信先ノードまでの通信経路を探索し、経路上の通信帯域を予約する第1のステップと、通信ルート上で互いに隣接する中間ノード同士を結ぶリンクルート上の通信帯域幅の情報を中間ノードに格納する第2のステップと、経路上の送信先ノードから送信元ノードに向かってルート応答を行う際に、経路の利用できる通信帯域幅の情報を収集して、送信元ノードに伝達する第3のステップと、を備える技術が開示されている。
【先行技術文献】
【特許文献】
【0003】
【特許文献1】再表03/061220号公報
【発明の概要】
【発明が解決しようとする課題】
【0004】
ところで、特許文献1に示すようなオンデマンド方式のプロトコルを用いて経路探索を行うことができないノードや、経路探索方法が異なるネットワークと接続するL3SW(Layer 3 Switch)やルータ装置(以下、中間の通信装置)は、自分のIPアドレス以外の宛先に対する経路探索やARP(Address Resolution Protocol) Requestに対して、代理で応答することで通信パケットを受け取り、別のネットワークに対して経路探索を実行し、経路を確立することで通信の中継を行う。しかし、このような代理応答を実行するノードが、通信パケットを受信した時点で、送信先のノードが属するネットワークにおける経路が確立されていない場合、送信先のノードへの経路の確立に時間がかかる場合がある。そのため、代理応答を実行するノードには、通信パケットをバッファオーバーフローさせないために、十分な容量のメモリを搭載しておく必要があるという問題点があった。
【0005】
また、中間の通信装置から送信先の通信装置への通信が不可能だった場合には、送信先への経路をみつけることのできない通信パケットが中間の通信装置に送信されてしまい、その通信パケットは無駄になる。
【0006】
そこで、本発明は、メモリに必要なバッファの容量を少なくするとともに、不要な通信の発生を抑制することが可能なネットワークシステム、通信装置、および、通信方法を提供することを目的としている。
【課題を解決するための手段】
【0007】
上記課題を解決するために、本発明は、送信元の通信装置と、送信先の通信装置と、中間の通信装置とを少なくとも有し、前記中間の通信装置は、前記送信元の通信装置が属する第1経路構築プロトコルで通信経路を構築する第1サブネットワークと、前記送信先の通信装置が属する前記第1経路構築プロトコルとは異なる第2経路構築プロトコルで通信経路を構築する第2サブネットワークと、を相互に接続する機能を有するネットワークシステムにおいて、前記中間の通信装置は、前記送信先の通信装置を宛先とするパケットを前記送信元の通信装置から受信した場合には、前記送信先の通信装置との間で前記第2経路構築プロトコルに対応する経路探索パケットを送信して経路を確立する経路確立手段と、前記経路確立手段によって前記第2経路構築プロトコルに対応する経路応答パケットが受信されて経路が確立された場合に、前記送信元の通信装置に対して、前記送信先の通信装置に代わって前記第1経路構築プロトコルに対応する経路応答パケットを送信することで代理応答する代理応答手段と、を有前記代理応答手段は、前記経路確立手段によって経路が確立されるまで、前記第1経路構築プロトコルに対応する経路応答パケットの送信を保留する、ことを特徴とする。
このような構成によれば、メモリに必要なバッファの容量を少なくするとともに、不要な通信の発生を抑制することが可能になる。
【0008】
また、本発明は、前記第1経路構築プロトコルは、AODV(Ad hoc On-Demand Distance Vector)およびDSR(Dynamic Source Routing)のいずれか一方であり、前記第2経路構築プロトコルは、AODVおよびDSRのいずれか他方であることを特徴とする。
【0009】
また、本発明は、送信元の通信装置と、送信先の通信装置と、中間の通信装置とを少なくとも有し、前記中間の通信装置は、前記送信元の通信装置が属する第1経路構築プロトコルで通信経路を構築する第1サブネットワークと、前記送信先の通信装置が属する前記第1経路構築プロトコルとは異なる第2経路構築プロトコルで通信経路を構築する第2サブネットワークと、を相互に接続する機能を有するネットワークシステムに用いられる通信装置において、前記中間の通信装置は、前記送信先の通信装置を宛先とするパケットを前記送信元の通信装置から受信した場合には、前記送信先の通信装置との間で前記第2経路構築プロトコルに対応する経路探索パケットを送信して経路を確立する経路確立手段と、前記経路確立手段によって前記第2経路構築プロトコルに対応する経路応答パケットが受信されて経路が確立された場合に、前記送信元の通信装置に対して、前記送信先の通信装置に代わって前記第1経路構築プロトコルに対応する経路応答パケットを送信することで代理応答する代理応答手段と、を有前記代理応答手段は、前記経路確立手段によって経路が確立されるまで、前記第1経路構築プロトコルに対応する経路応答パケットの送信を保留する、ことを特徴とする。
【0010】
また、本発明は、送信元の通信装置と、送信先の通信装置と、中間の通信装置とを少なくとも有し、前記中間の通信装置は、前記送信元の通信装置が属する第1経路構築プロトコルで通信経路を構築する第1サブネットワークと、前記送信先の通信装置が属する前記第1経路構築プロトコルとは異なる第2経路構築プロトコルで通信経路を構築する第2サブネットワークと、を相互に接続する機能を有するネットワークシステムの通信方法において、前記中間の通信装置が前記送信先の通信装置を宛先とするパケットを前記送信元の通信装置から受信した場合には、前記送信先の通信装置との間で前記第2経路構築プロトコルに対応する経路探索パケットを送信して経路を確立する経路確立ステップと、前記経路確立ステップにおいて前記第2経路構築プロトコルに対応する経路応答パケットが受信されて経路が確立された場合に、前記送信元の通信装置に対して、前記送信先の通信装置に代わって前記第1経路構築プロトコルに対応する経路応答パケットを送信することで代理応答する代理応答ステップと、を有前記代理応答ステップは、前記経路確立ステップにおいて経路が確立されるまで、前記第1経路構築プロトコルに対応する経路応答パケットの送信を保留する、ことを特徴とする。
【発明の効果】
【0015】
本発明によれば、メモリに必要なバッファの容量を少なくするとともに、不要な通信の発生を抑制することが可能なネットワークシステム、通信装置、および、通信方法を提供することができる。
【図面の簡単な説明】
【0016】
図1】本発明の第1実施形態に係るネットワークシステムの構成例を示す図である。
図2図1に示す通信装置の詳細な構成例を示す図である。
図3図1に示す第1実施形態の動作を説明するための図である。
図4】従来例の動作を説明するための図である。
図5図1に示す第1実施形態の動作を説明するためのフローチャートである。
図6図1に示す第1実施形態の動作を説明するためのフローチャートである。
図7】本発明の第2実施形態に係るネットワークシステムの構成例を示す図である。
図8図7に示す第2実施形態の動作を説明するための図である。
図9図7に示す第2実施形態の動作を説明するためのフローチャートである。
図10図7に示す第2実施形態の動作を説明するためのフローチャートである。
図11】本発明の第3実施形態に係るネットワークシステムの構成例を示す図である。
図12図11に示す第3実施形態の動作を説明するための図である。
図13図11に示す第3実施形態の動作を説明するためのフローチャートである。
【発明を実施するための形態】
【0017】
次に、本発明の実施形態について説明する。
【0018】
(A)本発明の第1実施形態の構成の説明
図1は、本発明の第1実施形態に係るネットワークシステムの構成の一例を示す図である。図1に示すように、本発明の第1実施形態に係るネットワークシステムは、ネットワークのノードでとして機能する通信装置10〜60によって構成される。
【0019】
図1の例では、ハッチングを施していない通信装置10はAODVによる経路構築能力を有さず、ハッチングを施している通信装置20〜60はAODVによる経路構築能力を有している。すなわち、通信装置10と通信装置30〜60とは、独立したサブネットワークにそれぞれ属しており、通信装置20はこれら独立した2つのサブネットワークを接続する機能を有している。また、通信装置20〜60は、オンデマンド方式のプロトコルによる経路構築を行う。
【0020】
図2は、図1に示す通信装置20の構成例を示す図である。なお、通信装置10〜60は同様の構成とされているので、以下では、通信装置20を例に挙げて説明する。
【0021】
図2に示すように、通信装置20は、パケット中継処理部21、制御部22、記憶部23、および、受信部24−1〜24−n、および、送信部25−1〜25−nを有している。
【0022】
ここで、パケット中継処理部21は、制御部22の制御に応じて、受信部24−1〜24−nによって受信されたパケットを、そのヘッダに格納されている情報に応じて、対応する送信部25−1〜25−nから送出する。制御部22は、記憶部23に記憶されている経路情報23aに応じて、受信したパケットのヘッダを書き換え、パケット中継処理部21を介して送信する。
【0023】
記憶部23は、半導体メモリによって構成され、パケットを転送するための情報である経路情報23aを有するとともに、後述するパケット転送に関する処理を実行するためのプログラムやデータを格納している。受信部24−1〜24−nは、他の通信装置からパケットを受信する。また、送信部25−1〜25−nは、他の通信装置に対してパケットを送信する。
【0024】
(B)本発明の第1実施形態の動作の説明
つぎに、本発明の第1実施形態の動作について説明する。図3図1に示す第1実施形態の動作を説明するための図である。なお、以下では、まず、図4を参照して従来例の動作を説明し、その後に図3を参照して第1実施形態の動作について説明する。
【0025】
図4は従来例の動作を説明する図である。AODVプロトコルによる経路構築機能を有しない通信装置10が、通信装置60と経路を構築しようとする場合、通信装置10は、通信装置20に対して、送信先の通信装置60のIPアドレスを含むARP Requestパケットを送信する(1)。このようなARP Requestパケットを受信した通信装置20は、自己のMAC(Media Access Control)アドレスを含むARP Replyパケットを通信装置10に対して送信することで代理応答する(2)。ARP Replyパケットを受信した通信装置10は、通信装置20に対してUDP(User Datagram Protocol)によってデータの送信を開始する(3)。一方、通信装置20は、通信装置10から受信したARP Requestパケットに含まれているIPアドレスに対する経路構築をProxy ARPによって実行する。より詳細には、通信装置20は、AODV Route Requestパケットを通信装置60に対して送信する(4)。AODV Route Requestパケットを受信した通信装置60は、AODV Route Replyパケットを通信装置20に対して送信する(5)。AODV Route Replyパケットを受信した通信装置20は、通信装置10から受信したデータパケットを、以上の動作によって確立した経路を介して通信装置60に対して送信する。
【0026】
ところで、図4に示す従来例では、通信装置10が通信装置20からARP Replyパケットを受信すると、その直後から通信装置10が通信装置20に対してUDPによってデータパケットの送信を開始する。通信装置20が通信装置60に対してAODV Route Requestパケットを送信して経路を確立するまでにはある程度の時間を要することから、通信装置20がその間に通信装置10から受信するデータパケットは、例えば、記憶部23に設けたバッファに格納する必要がある。このようなバッファは、経路確立までに要する最大の時間と、最大の通信速度に基づいて余裕を持って設定する必要があることから、かなり大きな容量のバッファを準備する必要があった。
【0027】
これに対して、第1実施形態では、図3に示すように、通信装置20が通信装置10からARP Requestパケットを受信すると(1)、すぐにARP Replyパケットを送信せずに、送信先である通信装置60との間での経路確立を先に実行する。すなわち、通信装置20は、通信装置60に対してAODV Route Requestパケットを送信する(2)。このようなAODV Route Requestパケットを受信した通信装置60は、AODV Route Replyパケットを通信装置20に対して送信する(3)。
【0028】
AODV Route Replyパケットを受信した通信装置20は、通信装置60との間で経路を確立する。このようにして経路の確立に成功すると、通信装置20は、通信装置10に対してARP Replyパケットを送信することで通信装置60に代わって代理応答する(4)。通信装置10は、通信装置20からARP Replyパケットを受信すると、UDPによるデータパケットの送信を開始する(5)。
【0029】
以上に説明したように、第1実施形態では、通信装置20は、送信元の通信装置10からARP Requestパケットを受信した場合には、送信先の通信装置60との間の経路を確立した後に、通信装置10に対してARP Replyパケットを送信して代理応答するようにした。これにより、図4に示す従来のように、通信装置60との間で経路を確立する前に通信装置10からデータパケットが送信されることを防止できるので、例えば、記憶部23に確保するバッファの容量を減らすことができる。
【0030】
また、通信装置20のバッファの容量を減らすために、例えば、通信装置10が通信開始しから所定の期間は、通信速度を遅くするといった、特別な構成が不要になるので、通信装置10として一般的な構成の汎用品を用いることができる。
【0031】
つぎに、図5および図6を参照して、図1に示す第1実施形態において実行される処理について説明する。図5は、図1に示す通信装置10において実行される処理の一例を説明するフローチャートである。図5に示すフローチャートが開始されると、以下のステップが実行される。
【0032】
ステップS10では、通信装置10の図示しない制御部12は、送信先ノードのIPアドレスを特定する。例えば、制御部12は、送信先ノードである通信装置60のIPアドレスを特定する。
【0033】
ステップS11では、通信装置10の図示しない制御部12は、AODVノード(AODVプロトコルによる経路構築機能を有するノード)に対してARP Requestパケットを送信する。例えば、通信装置10は、送信先ノードである通信装置60のIPアドレスをMACアドレス探索対象とするARP Requestパケットを通信装置20に対して送信する。もしくは通信装置10は、デスティネーションIPアドレス(dest IP)を通信装置60のIPアドレスとするARP Requestパケットを通信装置20に対して送信する。
【0034】
ステップS12では、通信装置10の図示しない制御部12は、AODVノードからARP Replyパケットを受信したか否かを判定し、ARP Replyパケットを受信したと判定した場合(ステップS12:Y)にはステップS13に進み、それ以外の場合(ステップS12:N)には同様の処理を繰り返す。例えば、AODVノードである通信装置20からARP Replyパケットを受信した場合にはYと判定してステップS13に進む。
【0035】
ステップS13では、通信装置10の図示しない制御部12は、AODVノードに対してデータパケットの送信を開始する。例えば、AODVノードである通信装置20に対してデータパケットをUDPによって送信する。
【0036】
つぎに、図6は、図1に示す通信装置20において実行される処理の一例を説明するフローチャートである。図6に示すフローチャートが開始されると、以下のステップが実行される。
【0037】
ステップS30では、通信装置20の制御部22は、ARP Requestパケットを受信したか否かを判定し、受信したと判定した場合(ステップS30:Y)にはステップS30に進み、それ以外の場合(ステップS30:N)には処理を終了する。例えば、通信装置10からARP Requestパケットを受信した場合にはYと判定してステップS30に進む。
【0038】
ステップS31では、通信装置20の制御部22は、ARP RequestパケットからデスティネーションIPアドレス(dest IP)を取得する。例えば、送信先が通信装置60であるARP Requestパケットの場合にはデスティネーションIPアドレスとして通信装置60のIPアドレスが取得される。
【0039】
ステップS32では、通信装置20の制御部22は、ステップS31で取得したデスティネーションIPアドレスを宛先とするRREQ(Route Request)パケットを生成する。例えば、送信先が通信装置60である場合には、通信装置60を宛先とするAODV Route Requestパケットが生成される。
【0040】
ステップS33では、通信装置20の制御部22は、ステップS32で生成したRREQパケットを、他の通信装置に対してブロードキャストする。例えば、図1の例では、AODV Route Requestパケットは、通信装置30,40,50を介して通信装置60に伝送される。通信装置60は、AODV Route Requestパケットを受信し、IPアドレスを参照して当該パケットが自己宛であることを認識すると、AODV RREP(Route Reply)パケットを、通信装置50,40,30を介して通信装置20に送信する。
【0041】
ステップS34では、通信装置20の制御部22は、RREPパケットを受信したか否かを判定し、受信したと判定した場合(ステップS34:Y)にはステップS35に進み、それ以外の場合(ステップS34:N)には同様の処理を繰り返す。例えば、通信装置60からAODV Route Replyパケットを受信した場合にはYと判定してステップS35に進む。
【0042】
ステップS35では、通信装置20の制御部22は、自己のMACアドレスを含むARP Replyパケットを生成する。例えば、送信先が通信装置60である場合には、ステップS31で取得した通信装置60のIPアドレスと自己のMACアドレスとを含むARP Replyパケットを生成する。
【0043】
ステップS36では、通信装置20の制御部22は、ステップS35で生成したARP Replyパケットを送信することで代理応答する。例えば、通信装置10が送信元である場合には、通信装置10に対してARP Replyパケットを送信することで通信装置60に代わって代理応答する。これにより、送信元の通信装置10では、ステップS12においてYと判定し、ステップS12に進んで、データパケットの送信を開始する。
【0044】
ステップS37では、通信装置20の制御部22は、送信元ノードと送信先ノードとの間での通信を仲介する。例えば、送信元ノードが通信装置10であり、送信先ノードが通信装置60である場合には、通信装置20はこれらの間での通信の仲介を実行する。これにより、通信装置10から通信装置60に向けてデータパケットが送信される。
【0045】
以上に説明したように、図5および図6に示すフローチャートによれば、図3を参照して前述した動作を実現できる。
【0046】
(C)本発明の第2実施形態の構成の説明
図7は、本発明の第2実施形態に係るネットワークシステムの構成の一例を示す図である。図7に示すように、本発明の第2実施形態に係るネットワークシステムは、ネットワークのノードでとして機能する通信装置10〜60によって構成される。なお、通信装置20は、図2と同様の構成とされ、また、通信装置10,30〜60は通信装置20と同様の構成とされている。
【0047】
図7の例では、ハッチングを施していない通信装置60はAODVによる経路構築能力を有さず、ハッチングを施している通信装置10〜50はAODVによる経路構築能力を有している。すなわち、通信装置10,30,40,50と通信装置60とは、独立したサブネットワークにそれぞれ属しており、通信装置20はこれら独立した2つのサブネットワークを接続する機能を有している。また、通信装置10〜50は、オンデマンド方式のプロトコルによる経路構築を行う。
【0048】
(D)本発明の第2実施形態の動作の説明
つぎに、図8を参照して、図7に示す第2実施形態の動作について説明する。なお、以下では、通信装置10が送信元ノードであり、通信装置60が送信先ノードであり、通信装置20が代理応答する中間ノードとして動作する場合を例に挙げて説明する。また、以下では、従来例の動作について簡単に説明した後、第2実施形態の動作について説明する。
【0049】
従来例において、送信元の通信装置10から送信先の通信装置60に対してデータパケットを送信する場合、通信装置10は、通信装置60のIPアドレスを宛先とするAODV Route Requestパケットをブロードキャストする。このようなAODV Route Requestパケットを通信装置20が受信すると、IPアドレスが自己宛ではなく、配下の通信装置60宛であることから、代理応答を実行する。すなわち、送信元の通信装置10に対してAODV Route Replyパケットを送信する。この結果、AODV Route Replyパケットを受信した通信装置10は、通信装置60に向けてデータパケットの送信を開始する。一方、通信装置20は、通信装置60に対してARP Requestパケットを送信し、その結果として、通信装置60からARP Replyパケットを受信する。ARP Replyパケットを受信した通信装置20は、通信装置10から受信してバッファに格納しているデータパケットを通信装置60に送信する。このため、従来例では、通信装置20と通信装置60の間で経路が確立される前に通信装置10からデータパケットが送信されるので、通信装置20は最悪のケースを想定してバッファの容量を準備しなければならなかった。
【0050】
つぎに、図8を参照して、第2実施形態の動作について説明する。第2実施形態では、送信元である通信装置10が送信先である通信装置60に対してAODV Route Requestパケットをブロードキャストすると、図8に示す経路を伝送された同パケットは通信装置20によって受信される(1)。通信装置20は、IPアドレスが自己宛ではなく、配下の通信装置60宛であることから、まず、通信装置60がARPテーブルに登録されているか否かを判定し、登録されていない場合には通信装置60に対してARP Requestパケットを送信する(2)。そして、通信装置60からARP Replyパケットを受信した場合(3)には、通信装置60をARPテーブルに登録した後に、送信元である通信装置10に対してAODV Route Replyパケットを送信する(4)。また、通信装置60がARPテーブルに登録されている場合には、経路は確立済みと判断して、ARP Requestパケットは送信せずに、送信元である通信装置10に対してAODV Route Replyパケットを送信する。
【0051】
通信装置10がAODV Route Replyパケットを受信すると、通信装置10と通信装置20の間の経路が確立されるので、通信装置10は通信装置20に対してデータパケットの送信を開始する(5)。
【0052】
以上の動作によれば、代理応答する中間ノードである通信装置20は、通信装置60との間の経路が確立してからAODV Route Replyパケットを送信するので、通信装置60との間の経路が確立する前からデータパケットが送信されることを防止できる。このため、通信装置20が備えるべきバッファの容量を減らすことができる。
【0053】
つぎに、図9および図10を参照して、第2実施形態において実行される処理について説明する。
【0054】
図9は、図7に示す中間ノードである通信装置20において実行される処理の一例を示すフローチャートである。このフローチャートの処理が開始されると、以下のステップが実行される。
【0055】
ステップS50では、通信装置20の制御部22は、AODVのRREQ(Route Request)パケットを受信したか否かを判定し、受信したと判定した場合(ステップS50:Y)にはステップS51に進み、それ以外の場合(ステップS50:N)には処理を終了する。例えば、通信装置10からAODV Route Requestパケットを受信した場合にはステップS51に進む。
【0056】
ステップS51では、通信装置20の制御部22は、ステップS50で受信したRREQパケットの宛先が代理応答する対象のノードか否かを判定し、宛先が代理対象ノードである場合(ステップS51:Y)にはステップS52に進み、それ以外の場合(ステップS51:N)にはステップS53に進む。例えば、代理対象ノードである通信装置60がAODV Route Requestパケットの宛先である場合にはYと判定してステップS52に進む。
【0057】
ステップS52では、通信装置20の制御部22は、送信先である代理対象ノードがARPテーブルに登録済みか否かを判定し、登録済みと判定した場合(ステップS52:Y)にはステップS57に進み、それ以外の場合にはステップS54に進む。例えば、図7の例では、代理対象ノードである通信装置60がARPテーブルに登録されている場合にはYと判定してステップS57に進み、登録されていない場合にはNと判定してステップS54に進む。
【0058】
ステップS53では、通信装置20の制御部22は、宛先が自己宛である場合には、AODV RREPパケットを送信元に向けて送信する。なお、宛先が自己宛でなく、また、代理対象ノード宛でもない場合には、他の通信装置に対してAODV RREQパケットをブロードキャストする。
【0059】
ステップS54では、通信装置20の制御部22は、代理対象ノードに対してARP Requestパケットを送信する。例えば、通信装置20は、代理対象ノードである通信装置60に対してARP Requestパケットを送信する。
【0060】
ステップS55では、通信装置20の制御部22は、代理対象ノードからARP Replyパケットを受信する。例えば、通信装置20は、代理対象ノードである通信装置60からARP Replyパケットを受信する。
【0061】
ステップS56では、通信装置20の制御部22は、ステップS55で受信したARP Replyパケットを参照して代理対象ノードに関する情報をARPテーブルに登録する。例えば、代理対象ノードである通信装置60のIPアドレスとMACアドレスを対応付けてARPテーブルに登録する。
【0062】
ステップS57では、通信装置20の制御部22は、RREPパケットをRREQパケットの送信元に向けて送信する。これにより、送信元と送信先のノード間で経路が確立される。例えば、通信装置20は、AODV Route Requestパケットの送信元である通信装置10に対してAODV Route Replyパケットを送信する。この結果、通信装置10と通信装置20の間でAODVプロトコルに基づく経路が確立される。
【0063】
ステップS58では、通信装置20の制御部22は、送信元ノードと送信先ノードの間の通信を仲介する。例えば、中間ノードである通信装置20は、送信元ノードである通信装置10から送信されるデータパケットを受信して、送信先ノードである通信装置60に転送する仲介処理を実行する。
【0064】
つぎに、図10を参照して、図7に示す送信先ノードである通信装置60において実行される処理について説明する。図10に示すフローチャートの処理が開始されると、以下のステップが実行される。
【0065】
ステップS70では、通信装置60の図示しない制御部62は、ARP Requestパケットを受信したか否かを判定し、受信したと判定した場合(ステップS70:Y)にはステップS71に進み、それ以外の場合(ステップS70:N)には処理を終了する。例えば、通信装置20からARP Requestパケットを受信した場合にはYと判定してステップS71に進む。
【0066】
ステップS71では、通信装置60の図示しない制御部62は、ARP Requestパケットの送信元に対してARP Replyパケットを送信する。例えば、通信装置20がARP Requestパケットの送信元である場合には、通信装置20に対してARP Replyパケットを送信する。この結果、通信装置20では、ステップS55,S56の処理によって、通信装置60に関する情報をARPテーブルに登録する。
【0067】
ステップS72では、通信装置60の図示しない制御部62は、AODVノードを介して送信元ノードから送信されるデータパケットを受信する。例えば、送信先ノードである通信装置60は、AODVノードである通信装置20を介して送信元ノードである通信装置10から送信されるデータパケットを受信する。
【0068】
以上の処理によれば、図8を参照して前述した動作を実現することができる。
【0069】
(E)本発明の第3実施形態の構成の説明
図11は、本発明の第3実施形態に係るネットワークシステムの構成の一例を示す図である。図11に示すように、本発明の第3実施形態に係るネットワークシステムは、ネットワークのノードでとして機能する通信装置10〜70によって構成される。なお、通信装置20は、図2と同様の構成とされ、また、通信装置10,30〜70は通信装置20と同様の構成とされている。
【0070】
図11の例では、通信装置10,30,40はAODVによる経路構築能力を有し、通信装置50〜70はDSR(Dynamic Source Routing)による経路構築能力を有している。また、2つのサブネットワークを接続する接点位置に位置する通信装置20は、AODVおよびDSRの双方の経路構築能力を有している。すなわち、通信装置10,30,40と通信装置50〜60とは、独立したサブネットワークにそれぞれ属しており、通信装置20はこれら独立した2つのサブネットワークを接続する機能を有している。また、図11の例では、通信装置10,30,40によるサブネットワークと、通信装置50〜60によるサブネットワークの双方がオンデマンド方式のプロトコルによる経路構築を行う。
【0071】
(F)本発明の第3実施形態の動作の説明
つぎに、図12を参照して、図11に示す第3実施形態の動作について説明する。なお、以下では、通信装置10が送信元ノードであり、通信装置60が送信先ノードであり、通信装置20が中間ノードとして動作する場合を例に挙げて説明する。また、以下では、従来例の動作について簡単に説明した後、第3実施形態の動作について説明する。
【0072】
従来例において、送信元の通信装置10から送信先の通信装置60に対してデータパケットを送信する場合、通信装置10は、通信装置60のIPアドレスを宛先とするAODV Route Requestパケットをブロードキャストする。このようなAODV Route Requestパケットを通信装置20が受信すると、IPアドレスが自己宛ではなく、DSRに基づくネットワークに接続される通信装置60であることから、代理応答を実行する。すなわち、送信元の通信装置10に対してAODV Route Replyパケットを送信する。この結果、AODV Route Replyパケットを受信した通信装置10は、通信装置20に向けてデータパケットの送信を開始する。その後、通信装置20は、通信装置60との間でDSRに基づく経路確立処理を実行する。通信装置60との間でDSRに基づく経路の確立に成功した通信装置20は、通信装置10から受信してバッファに格納しているデータパケットを通信装置60に送信する。このため、従来例では、通信装置20と通信装置60の間でDSRに基づく経路が確立される前に通信装置10からデータパケットが送信されるので、通信装置20は最悪のケースを想定してバッファの容量を準備しなければならなかった。
【0073】
つぎに、図12を参照して、第3実施形態の動作について説明する。第3実施形態では、送信元である通信装置10が送信先である通信装置60に対してAODV Route Requestパケットをブロードキャストすると、図12に示す経路を伝送された同パケットについては通信装置20によって受信される(1)。通信装置20は、IPアドレスが自己宛ではなく、配下の通信装置60宛である場合、まず、通信装置60がルートテーブルに登録されているか否かを判定し、登録されていない場合には通信装置60に対してDSR Route Requestパケットを送信する(2)。そして、通信装置60からDSR Route Replyパケットを受信した場合(3)には、通信装置60をルートテーブルに登録した後に、送信元である通信装置10に対してAODV Route Replyパケットを送信する(4)。また、通信装置60がルートテーブルに登録されている場合には、経路は確立済みと判定してDSR Route Requestパケットは送信せずに、送信元である通信装置10に対してAODV Route Replyパケットを送信する。
【0074】
通信装置10がAODV Route Replyパケットを受信すると、通信装置10と通信装置20の間でAODVに基づく経路が確立されるので、通信装置10は通信装置20に対してUDPによるデータパケットの送信を開始する(5)。
【0075】
以上の動作によれば、代理応答する中間ノードである通信装置20は、通信装置60との間でDSRに基づく経路が確立してからAODV Route Replyパケットを送信するので、通信装置60との間の経路が確立する前からデータパケットが送信されることを防止できる。このため、通信装置20が備えるべきバッファの容量を減らすことができる。
【0076】
つぎに、図13を参照して、第3実施形態において実行される処理について説明する。図13は、図11に示す通信装置20において実行される処理の一例を説明するためのフローチャートである。このフローチャートの処理が開始されると、以下のステップが実行される。
【0077】
ステップS90では、通信装置20の制御部22は、AODV RREQ(Route Request)パケットを受信したか否かを判定し、受信したと判定した場合(ステップS90:Y)にはステップS91に進み、それ以外の場合(ステップS90:N)には処理を終了する。例えば、通信装置10からAODV Route Requestパケットを受信した場合にはステップS91に進む。
【0078】
ステップS91では、通信装置20の制御部22は、ステップS90で受信したAODV RREQパケットの送信先が代理対象ノードか否かを判定し、送信先が代理対象ノードである場合(ステップS91:Y)にはステップS92に進み、それ以外の場合(ステップS91:N)にはステップS93に進む。例えば、代理対象ノードである通信装置60がAODV Route Requestパケットの宛先である場合にはYと判定してステップS92に進む。
【0079】
ステップS92では、通信装置20の制御部22は、送信先である代理対象ノードがルートテーブルに登録されているか否かを判定し、登録されていると判定した場合(ステップS92:Y)にはステップS97に進み、それ以外の場合にはステップS94に進む。例えば、図11の例では、代理対象ノードである通信装置60がルートテーブルに登録されている場合にはYと判定してステップS96に進み、登録されていない場合にはNと判定してステップS94に進む。
【0080】
ステップS93では、通信装置20の制御部22は、宛先が自己宛である場合には、AODV RREPパケットを送信元に向けて送信する。なお、宛先が自己宛でなく、また、代理対象ノード宛でもない場合には、他の通信装置に対してAODV RREQパケットを転送する。
【0081】
ステップS94では、通信装置20の制御部22は、代理対象ノードに対してDSR RREQ(Route Request)パケットを送信して経路構築を実行する。例えば、通信装置20は、代理対象ノードである通信装置60に対してDSR Route Requestパケットを送信する。
【0082】
ステップS95では、通信装置20の制御部22は、代理対象ノードからDSR RREP(Route Reply)パケットを受信する。例えば、通信装置20は、代理対象ノードである通信装置60からDSR Route Replyパケットを受信する。
【0083】
ステップS96では、通信装置20の制御部22は、ステップS95で受信したDSR RREPパケットを参照して、代理対象ノードに関する情報をルートテーブルに登録する。例えば、通信装置20は、代理対象ノードである通信装置60のIPアドレスとMACを対応付けてルートテーブルに登録する。この結果、通信装置20と通信装置60の間でDSRプロトコルによる経路が確立される。
【0084】
ステップS97では、通信装置20の制御部22は、AODV RREPパケットをRREQパケットの送信元に向けて送信する。これにより、送信元と送信先のノード間で経路が確立される。例えば、通信装置20は、AODV Route Requestパケットの送信元である通信装置10に対してAODV Route Replyパケットを送信する。この結果、通信装置10と通信装置20の間でAODVプロトコルに基づく経路が確立される。
【0085】
ステップS98では、通信装置20の制御部22は、送信元ノードと送信先ノードの間の通信を仲介する。例えば、中間ノードである通信装置20は、送信元ノードである通信装置10から送信されるデータパケットを受信して、送信先ノードである通信装置60に転送する仲介処理を実行する。
【0086】
以上の処理によれば、図12を参照して前述した動作を実現することができる。
【0087】
(G)変形実施形態の説明
以上の実施形態は一例であって、本発明が上述したような場合のみに限定されるものでないことはいうまでもない。例えば、以上の第1〜第3実施形態では、通信装置10〜70は、有線接続される場合を例に挙げて説明したが、これらが無線接続される構成としてもよい。なお、その場合には、図2に示す構成は、受信部24−1〜24−nおよび送信部25−1〜25−nの代わりに、電波による送受信部を設けるようにすればよい。
【0088】
また、以上の第1〜第3実施形態では、図面を簡略化するために通信装置の一部を示すようにしたが、実際には図示した以外の通信装置が存在するようにしてもよい。
【0089】
また、第2実施形態では、図9に示すフローチャートにおいて、代理対象ノードがARPテーブルに登録されていない場合にのみ、代理対象ノードに対してARP Requestを送信するようにしたが、登録されている場合にもARP Requestを送信するようにしてもよい。そのような構成によれば、登録はされていても、登録内容が正しくない場合に対応することができる。同様に、第3実施形態においても、送信先がルートテーブルに登録されている場合であっても、DSR経路構築処理を実行するようにしてもよい。そのような構成によれば、ルートテーブルに登録はされていても、登録内容が正しくない場合に対応することができる。
【0090】
また、図12に示す第3実施形態では、AODVとDSRの組み合わせとしたが、これら以外の組み合わせのネットワークに本発明を適用するようにしてもよい。
【0091】
また、本発明を適用可能なサブネットワークは、L(Layer)3ネットワークには限定されない。例えば、L2ネットワークをサブネットワークとして使用することも可能である。すなわち、サブネットワークとして、L3ネットワーク同士の組み合わせのみならず、L3ネットワークとL2ネットワークの組み合わせに対して、本発明を適用することも可能である。
【符号の説明】
【0092】
10〜70 通信装置
21 パケット中継処理部
22 制御部
23 記憶部
23a 経路情報
24−1〜24−n 受信部
25−1〜25−n 送信部
図1
図2
図3
図4
図5
図6
図7
図8
図9
図10
図11
図12
図13