JP3899084B2

JP3899084B2 - アドホックネットワークにおいて動的にａｒｐキャッシュテーブルを更新する方法及びシステム

Info

Publication number: JP3899084B2
Application number: JP2004097010A
Authority: JP
Inventors: 相秀南; ▲ミン▼秀金; 炳人文
Original assignee: Samsung Electronics Co Ltd
Current assignee: Samsung Electronics Co Ltd
Priority date: 2003-07-10
Filing date: 2004-03-29
Publication date: 2007-03-28
Anticipated expiration: 2024-03-29
Also published as: CN1578244A; DE602004015372D1; KR100568229B1; JP2005033765A; CN100347996C; US20050007962A1; EP1496669B1; EP1496669A1; KR20050006977A; US7492772B2

Description

本発明は、アドホックネットワークにおいて、ＡＲＰキャッシュテーブルを効率良く更新する方法に関し、より詳しくは、ＩＰ(Internet Protocol)アドレスの衝突などによりアドホック(Ad-hoc)ネットワーク上に存在する端末のＩＰアドレスが変更される場合に、他の端末のＡＲＰ(Address Resolution Protocol；以下、ＡＲＰと称する)キャッシュテーブル(Cache Table)に登録されている情報を動的に更新する方法及びシステムに関する。

従来の技術においては、図１に示すように、アドホックネットワーク上の一つの端末１５０が自ら位置を移動したり、特定の条件によりアドホックネットワークから離れる場合には、ＵｎＡＲＰパケットをブロードキャスティング(Broadcasting)する。これにより、周辺の各端末(１１０乃至１４０)は、自分のＡＲＰキャッシュテーブルを調べ、前記端末１５０のＩＰキャッシュ値があれば、これを削除する。このような過程により、同じＩＰアドレスに異なるＭＡＣ(Media Access Control)アドレスを有するホストが存在することを防ぐことができる。

従来の技術では、一般の有線ネットワークのみを考慮しており、どのホストがネットワークから離れるかを感知することも実際には難しく、雛型のＲＦＣ(Request for Comments)のみが開示されている。このＲＦＣとは、ＩＥＴＦ(Internet Engineering Task Force)から発表されるインターネット技術に関する公式技術文書であり、プロトコルの研究及び標準に関する新しいアイデアを伝える基本的な方法を意味する。米国のサウスカリフォルニア大学の情報科学協会では、ＩＥＴＦから公開された検索可能な全てのＲＦＣの目録を提供しており、「http://www.rfc-editor.org/rfc.html」を参照すれば、ＡＲＰに関するより詳しい内容が分かる。例えば、ＲＦＣ８２６は、ＡＲＰ全体に関する内容を、ＲＦＣ１８６８は、ＵｎＡＲＰに関する内容をそれぞれ含んでいる。

アドホックネットワークにおいては、端末がネットワークから離れる場合のみならず、端末間のＩＰアドレスの衝突が発生する場合、ＩＰアドレスの衝突を回避するために、端末のＩＰアドレスを変更したりする。従って、前記ＵｎＡＲＰのみを使用することは、非効率的な方法となる。また、このような方法は、パケットの損失が生じた場合にもその解決方案が提示することができない。

ＭＡＮｅｔ(Mobile Ad-hoc Network)においては、インフラストラクチャー (Infrastructure)におけるアクセスポイント(AP；Access Point)のような機器を設けることなく、ネットワークを構築しており、有線網におけるＤＨＣＰ(Dynamic Host Configuration Protocol)のようなＩＰアドレスを割り当てるプロトコルを使用することができない。従って、端末そのものでＩＰアドレスを割り当てたり重複を検出したりする必要がある。しかし、ＭＡＮｅｔの特性上、ＩＰアドレスを自動に割り当てる過程で重複したＩＰアドレスが割り当てられることもある。このように、ＩＰアドレスの衝突によりＩＰアドレスが変更される場合、既存のホストのＡＲＰキャッシュテーブルが変更されないことによる問題が発生することもある。もちろん、ＡＲＰキャッシュテーブルは、一定期間が経過すれば、更新されるようになっているものの、その期間の間は、ＩＰアドレスの変更による誤ったＡＲＰキャッシュテーブルのために、正常な通信を行なうことができなくなる。前記更新期間は、標準として決まってはいないが、約２分から４時間程度になっている。前記更新方式は、各端末がブロードキャストにより周辺の端末に対してＩＰアドレスやＭＡＣアドレスを要求すると、前記周辺の各端末が、これに応じて、ユニキャスト応答として前記アドレス情報を転送する方式である。

この問題を解決するために、更新時間を減らす方法を用いると、それだけネットワーク資源の消費が増え、効率的でない。従って、ＩＰアドレスの変更がある場合には、動的にＡＲＰキャッシュテーブルを更新することにより正常な通信を可能とする方法が求められている。

アドホックネットワークにおいて、同じＩＰアドレスを使用する端末が二つ以上である場合、一つの端末を除いた他の端末は、自分のＩＰアドレスを、重複しない新しいＩＰアドレスに再び割り当てる必要がある。ＩＰアドレスの衝突によりＩＰアドレスが変更される場合にも、ＡＲＰキャッシュテーブルは更新されないことから、変化したネットワーク状況が反映されないこともあり、この場合、既存の端末とＩＰアドレスの変更された端末とは通信を行うことができなくなる。

本発明は、上記問題点に鑑みなされたものであり、ＩＰアドレスの衝突の際に、ＩＰアドレスの変更されない端末が不要ＡＲＰ(Gratuitous ＡＲＰ)を使用して既存の端末に自分のアドレス情報を知らせることにより、動的にＡＲＰキャッシュテーブルを更新することを目的とする。
また本発明は、新しいＡＲＰメッセージの選択ＵｎＡＲＰ(Selective ＵｎＡＲＰ)を提案し、これを使用して既存の端末のＡＲＰキャッシュテーブルから誤ったアドレス情報のみを選択的に削除することにより、動的にＡＲＰキャッシュテーブルを更新することを目的とする。

上記の目的を達成するため、本発明による方法は、プロトコルアドレスの重複を検出し、前記重複したアドレスを有する端末のうちの一部の端末のプロトコルアドレスを変更する第１ステップと、前記アドレスの変更された端末が、変更前のプロトコルアドレス情報及び自分のハードウェアアドレス情報を周辺の端末に転送する第２ステップと、前記各アドレス情報を受信した周辺の端末が前記受信した情報に基づいて、アドレス情報を有するテーブルを更新する第３ステップとを含むことを特徴とする。

また、本発明による方法は、プロトコルアドレスの重複を検出し、前記重複したアドレスを有する端末のうちの一部の端末のプロトコルアドレスを変更する第１ステップと、前記重複したプロトコルアドレスを有する端末のうち、アドレスが変更されない端末が、周辺の端末に自分のアドレス情報を転送する第２ステップと、前記情報を受信した周辺の端末が、前記受信した情報に基づいて、アドレス情報を有するテーブルを更新する第３ステップとを含むことを特徴とする。

また、本発明による方法は、プロトコルアドレスの重複を検出し、前記重複したアドレスを有する端末のうちの一部の端末のプロトコルアドレスを変更する第１ステップと、前記アドレスの変更された端末が、変更前のプロトコルアドレス情報及び自分のハードウェアアドレス情報を周辺の端末に転送する第２ステップと、前記各情報を受信した周辺の端末が前記受信した情報内容に基づいて、アドレス情報を有するテーブルを更新する第３ステップと、前記重複したプロトコルアドレスを有する端末のうち、アドレスが変更されない端末が、周辺の端末に自分のアドレス情報を転送する第４ステップと、前記第４ステップでのアドレス情報を受信した周辺の端末が前記受信した情報に基づいて、アドレス情報を有するテーブルを更新する第５ステップとを含むことを特徴とする。

上記の目的を達成するため、本発明によるアドホックネットワークシステムは、プロトコルアドレスの重複がある場合に、アドホックネットワークにおける自動アドレス割り当て機能を利用し、前記プロトコルアドレスが変更される第１の端末と、前記第１の端末と直接通信できる位置にある周辺の端末とから構成され、前記第１の端末は、変更前のプロトコルアドレス情報及び自分のハードウェアアドレス情報を周辺の端末に転送し、前記周辺の端末は、前記受信した内容に基づいて、アドレス情報を有するテーブルを更新することを特徴とする。

アドホックネットワークにおいては、ＩＰアドレスを端末そのものが割り当てるため、ＩＰアドレスの重複使用により衝突が発生することもある。しかし、従来の技術では、ＩＰアドレスの衝突によりＩＰアドレスが変更された場合、ＡＲＰキャッシュテーブルを変更しないため、パケットの転送が正常に行われないこともあった。これに反し、本発明によれば、不要ＡＲＰや選択ＵｎＡＲＰを使用してＡＲＰキャッシュテーブルを更新することにより、前記問題が発生したとき、ＡＲＰキャッシュテーブルから該当の内容を無条件に削除することでなく、条件に合う場合のみに削除及び更新を行うことになる。従って、ネットワーク資源をより効率良く使用することが可能となる。
また、本発明によれば、ＡＲＰキャッシュテーブルの不一致から生じるエラーを動的に訂正することになり、無線通信のように、パケットの損失の多い環境でもより安定して通信を行うことが可能となる。

以下、本発明の好ましい実施の形態を、添付図面に基づいて詳しく説明する。
図２は、既存のＡＲＰパケットの構成を示す図である。図示のように、基本的なＡＲＰのメッセージタイプをそのまま使用し、各端末は、アドホックネットワーク上で動作しており、ＩＰアドレス(Internet Protocol Address)のようなプロトコルアドレスの自動割り当て機能を有している。従って、ＩＰアドレスの重複を検出することが可能であり、後述する図３に示すように、ある端末から同じＩＰアドレスでアクセスが要求される場合に、ＩＰアドレスの重複を検出し、新しいＩＰアドレスを割り当てることができる。以下、本発明においては、プロトコルアドレスとしてＩＰアドレスを例にして説明するが、これに限定されるものでなく、無線通信のためのプロトコルであれば、何れを使用しても良い。

本発明では、正しくないＡＲＰキャッシュを正しく変更するために、既存の不要ＡＲＰを使用している。ここで、不要ＡＲＰパケットの構成を説明すると、ソースハードウェアアドレスには、不要ＡＲＰパケットを転送する端末のＭＡＣアドレスを書き込み、ソースプロトコルアドレスには、前記端末のＩＰアドレスを書き込む。また、宛先ハードウェアアドレスには、何も書き込まず、宛先プロトコルアドレスには、前記端末のＩＰアドレスをもう一度書き込むことになっている。宛先プロトコルアドレスに前記端末のＩＰアドレスを再び書き込むことは、相手を特定せず、ブロードキャスティングすることを意味する。従って、アドホックネットワークにおいては、前記不要ＡＲＰパケットが１ホップ(One Hop)内の全ての端末に転送される。

また、本発明においては、選択ＵｎＡＲＰパケットを追加し、各端末は、自分が伝達したパケットが再び自分に伝達され、ループを形成するかをチェックし、ループが形成される場合には、周辺の端末にＡＲＰキャッシュを正しく更新するようにしている。ここで、周辺の端末とは、送信端末から１ホップ内にある端末をいう。このような選択ＵｎＡＲＰのパケット構造については、以下の図５で詳しく説明する。

図３は、ＩＰアドレスが重複するアドホックネットワークの動作環境を示している。さらに、図３は、アドホックネットワークにおいて、ＩＰアドレスがそれぞれＡ、Ｂ、Ｃ、Ｄである各端末３１０、３２０、３３０、３４０がお互いに通信を行なう場合に、端末ａ３１０と同じＩＰアドレスＡを有する端末ｅ３５０が前記アドホックネットワークにアクセスした場合を例示する。先ず、端末ｅ３５０がアクセスする前のネットワークの構成は次の通りである。全ての端末は、１ホップ範囲内にあり、各端末は、直接他の端末にパケットを転送することができる。端末ｄ３４０や端末ｂ３２０は、端末ａ３１０とパケットを送受信したことがあり、前記端末aのＩＰアドレスＡやＭＡＣアドレスの「０ｘ７７７７」を格納していることを示している。

ここで、ＩＰアドレスがＡであり、ＭＡＣアドレスが「０ｘ１１１１」である端末ｅ３５０が既存のアドホックネットワークにアクセスしようとする場合を説明する。ネットワークにおいて、同じＩＰアドレスＡを有する端末が二つあるため、二つの端末のうちの一つの端末は、ＩＰアドレスを変更し、衝突を起こさないＩＰアドレスを割り当てる必要がある。もし、ＭＡＣアドレスが「０ｘ７７７７」である端末ａ３１０のＩＰアドレスをＡからＧに変更する場合には、従来のアルゴリズムでは、ＩＰアドレスのみを変更し、周辺の端末のＡＲＰキャッシュテーブルを更新することはなかった。従って、周辺の端末の端末b３２０や端末d３４０のＡＲＰキャッシュテーブルは、タイマーが満了(expired)するか、ＡＲＰ更新情報が転送されてこないと、テーブルが更新されない。従って、前記端末ｂ３２０または前記端末ｄ３４０は、誤ったＡＲＰ情報の＜ＩＰ：Ａ、ＭＡＣ：０ｘ７７７７＞というエントリーを保持することになる。

図４は、ＡＲＰキャッシュテーブルが更新されていない場合のパケットの転送を示す図である。同図において、端末ｂ３２０がＭＡＣアドレス「０ｘ１１１１」の端末ｅ３５０にパケットを転送しようとするとき、端末ｄ３４０を経る必要があり、端末ｂ３２０は、端末ｄ３４０にパケットを送る。このパケットを受信した端末d３４０のＡＲＰキャッシュテーブル３４１には、ＩＰアドレスがＡであるＭＡＣアドレスが「０ｘ７７７７」に格納されており、転送パケットのＭＡＣアドレスを「０ｘ７７７７」に設定してパケットを転送する。端末a３１０は、転送されるパケットが自分のＭＡＣアドレスとは同じであるが、ＩＰアドレスが異なるため、再びこのパケットをフォーワーディング(Forwarding)する。アドホックネットワーク環境では、１ホップ内での通信を基本としているが、１ホップを超えた範囲内でもパケットを転送できるようにしなければならない。従って、このように、受信したパケットが自分のものでない場合には、前記パケットを正しい端末にフォーワーディングすることにより、結局、１ホップを超えた他の端末にまでパケットを転送することが可能となる。しかし、前記のように、ＭＡＣアドレスは同じであるが、ＩＰアドレスが異なる場合、フォーワーディングする端末の情報がない場合には、このパケットを廃棄することもある。

一旦、端末ａ３１０も同様に、端末ｅ３５０にパケットをフォーワーディングしようとすると、端末d３４０を経る必要があり、端末ａ３１０は、端末d３４０に前記パケットを転送する。すると、端末ｄ３４０は、さらにＡＲＰキャッシュテーブル３４１によって端末a３１０に再転送するため、ピンポン(Ping-pong)のような現象が発生したりする。従って、パケットを端末e３５０に転送することは不可能であり、端末ｄ３４０は、パケットを転送することにより、ＡＲＰキャッシュテーブル３４１の満了タイマー(Expire Timer)を更新するため、持続的なメッセージ転送が不可能となることもある。

図５は、本発明に係る選択ＵｎＡＲＰパケットの構成を示す図である。基本的なパケットのフィールド形式は、図２に示す一般のＡＲＰと同様である。但し、既存のＵｎＡＲＰでは、ソース送信端末がハードウェアアドレスフィールド５６０に「NULL」値を書き込んでいるが、選択ＵｎＡＲＰでは、これとは異なり、送信端末そのもののハードウェアアドレス、即ち、ＭＡＣアドレスを書き込んでいる。また、既存のＵｎＡＲＰでは、送信端末がソースプロトコルアドレスフィールド５７０に送信端末そのもののプロトコルアドレスを書き込んでいるが、選択ＵｎＡＲＰでは、変更前に使用していたＩＰアドレスを書き込んでいる。

全体的なパケットのフィールド形式を説明すると、最初の１６ビットは、ハードウェアタイプフィールド５１０である。ここでは、イーサネット（登録商標）やパケットラジオネット(Packet Radio Net)のようなハードウェアタイプが書き込まれる。次の１６ビットは、ハードウェア上位のプロトコルタイプフィールド５２０であるが、ここでは、一般に、ＩＰアドレスを書き込むことになる。次の二つのフィール５３０及び５４０は、それぞれ前の二つのフィールド５１０、５２０のアドレスの大きさを示している。一般的なＡＲＰパケットにおいて、その次のメッセージタイプフィールドには、メッセージが要求メッセージ(Request)または応答メッセージ(Response)であるかを区別して書き込んでいる。しかし、ＵｎＡＲＰパケットや選択ＵｎＡＲＰパケットは、常に応答メッセージのみ存在するため、選択ＵｎＡＲＰのメッセージタイプフィールド５５０には、応答メッセージとして書き込まれる。

次のフィールドのソースハードウェアアドレス５６０には、自分のＭＡＣアドレスが書き込まれる。ソースプロトコルアドレスには、ピンポン現象が発生する場合に、誤って転送されたパケットのＩＰアドレス、即ち、変更前に使用していたＩＰアドレスが書き込まれる。例えば、図４に示すように、ＩＰアドレスの衝突により端末aのＩＰアドレスがＡからＧに変更される場合には、端末aは、選択ＵｎＡＲＰパケットのソースハードウェアアドレスに、自分のＭＡＣアドレス、即ち、「０ｘ７７７７」を書き込む。さらに、ソースプロトコルアドレスフィールドには、フィールドに変更前に使用していたＩＰアドレス、即ち、Ａを書き込む。

宛先ハードウェアアドレスフィールド５８０には、何の値も書き込まれない。また、宛先プロトコルアドレスフィールド５９０には、ブロードキャストアドレス値を書き込む。ここで、ブロードキャストアドレス値とは、ブロードキャスティングを示す特定の値であり、その値が書き込まれていると、宛先端末は特定されず、通信可能な全ての周辺の端末に対してパケットが送信されることを意味する。

前記選択ＵｎＡＲＰパケットを受信した周辺の端末は、自分のＡＲＰキャッシュテーブルエントリーから前記選択ＵｎＡＲＰパケットのソースプロトコルアドレスフィールド５７０に書き込まれたＩＰアドレスと同じＩＰアドレスを有するエントリーを検索する。もし、前記エントリーのＭＡＣアドレスが前記選択ＵｎＡＲＰパケットのソースハードウェアアドレスフィールド５６０の内容と同じである場合、当該エントリーを削除し、正しいエントリー値に更新する。もし、前記エントリーのＭＡＣアドレスが前記選択ＵｎＡＲＰパケットのソースハードウェアアドレスフィールド５６０の値と同じでない場合には、前記エントリーを削除せず、そのままにして置く。

例えば、図４に示すように、周辺の端末ｂ３２０、端末ｃ３３０、及び端末ｄ３４０は、端末ａの選択ＵｎＡＲＰパケットを受信することになるが、端末ｂ３２０及び端末ｄ３４０は、ＡＲＰキャッシュテーブルにＡに関するアドレスエントリーを有している。従って、前記端末ｂ３２０及び端末ｄ３４０は、前記選択ＵｎＡＲＰパケットのソースプロトコルアドレスフィールド５７０に書き込まれたＩＰアドレス、即ち、Ａと相応するエントリーの＜ＩＰ：Ａ、ＭＡＣ：０ｘ７７７７＞を検索する。さらに、前記選択ＵｎＡＲＰパケットのソースハードウェアアドレスフィールド５６０に書き込まれた値「０ｘ７７７７」と前記エントリーのＭＡＣアドレス値「０ｘ７７７７」とが同じ値であることを確認する。その後、前記エントリーを削除し、正しいエントリー＜ＩＰ：Ｇ、ＭＡＣ：０ｘ７７７７＞を追加する。

このような過程により、この選択ＵｎＡＲＰパケットを生成して転送することにより、周辺の誤ったＩＰアドレスやＭＡＣアドレスを有するＡＲＰキャッシュテーブルのみを更新することになる。従って、前記選択ＵｎＡＲＰパケットを用いて正しい値に更新されているＡＲＰキャッシュテーブルエントリーをむやみに削除することを防止すると共に、動的にＡＲＰキャッシュテーブルのエントリー値を正しく保持することができる。

図６は、本発明に係るＩＰアドレスが重複する場合に、ＡＲＰキャッシュテーブルを更新する方法を示すフローチャートである。
先ず、ＩＰアドレスの重複が検出されると(Ｓ６１０)、自動アドレス割り当て機能を利用し、前記ＩＰアドレスが重複した端末のうちの一部の端末に新しいＩＰアドレスを割り当てる。次に、前記重複したＩＰアドレスを有する端末が、ＩＰアドレスが変更される端末であるか、もしくは、変更されない端末であるかを判断する(Ｓ６２０)。判断の結果、ＩＰアドレスが変更されない端末は、周辺のＡＲＰキャッシュテーブルの更新のために、不要ＡＲＰを転送する(Ｓ６３１)。この不要ＡＲＰは、自分のＩＰアドレスやＭＡＣアドレスを周辺の端末にブロードキャストし、自分のＩＰアドレスやＭＡＣアドレスが格納されている周辺の端末のＡＲＰキャッシュテーブルの値を正しい値に修正する(Ｓ６３２)。即ち、図４に示すＩＰアドレスが変更されない端末e３５０は、自分の情報＜ＩＰ：Ａ、ＭＡＣ：０ｘ１１１１＞を周辺の端末に知らせ、１ホップ内の端末ｄ３４０のＡＲＰキャッシュテーブル３４１の値を＜ＩＰ：Ａ、ＭＡＣ：０ｘ１１１１＞に正しく変更する。従って、その後には、端末b３２０が端末e３５０にパケットを転送しようとする場合にも、これを中継する端末d３４０のＡＲＰキャッシュテーブルに正しいＭＡＣアドレス値が格納されているため、端末a３１０に誤って転送されることはなくなる。

次に、ＩＰアドレスの値が変更される端末が周辺の端末からパケットを受信する場合には、受信したパケットのＩＰアドレスが自分のＩＰアドレスと同じであるかを判断し(Ｓ６３０)、同じである場合には、正しいパケットが転送された場合であるから、問題とならない。前記判断の結果、お互いに異なる場合には、前記ＩＰアドレスを有する正しい端末に前記パケットを転送することになる。もし、前記正しい端末にパケットを転送するために、前記ＩＰアドレスが変更される端末が前記受信したパケットを、前記送信してきた周辺の端末に再び転送する必要がある場合、即ち、ピンポン現象が発生した場合には、本発明による選択ＵｎＡＲＰパケット転送過程を経ることになる。もし、前記判断の結果、前記ピンポン現象が発生しなければ、結局、正しい端末に前記パケットがフォーワーディングされる(Ｓ６５１)。

このような選択ＵｎＡＲＰパケット転送過程では、先ず、前記ＩＰアドレスが変更される端末は、選択ＵｎＡＲＰパケットのソースハードウェアアドレスフィールドには、自分のＭＡＣアドレスを書き込み、ソースプロトコルアドレスフィールドには、ＩＰアドレスの変更前に使用していたＩＰアドレスを書き込む。また、宛先ハードウェアアドレスフィールドには、何の値も書き込まない。さらに、宛先プロトコルアドレスには、ブロードキャストアドレスを書き込む(Ｓ６５０)。その後、前記フィールドを書き込んだ選択ＵｎＡＲＰパケットをブロードキャストで転送する(Ｓ６６０)。次に、前記選択ＵｎＡＲＰパケットを受信した周辺の端末は、自分のＡＲＰキャッシュテーブルのエントリーから前記選択ＵｎＡＲＰパケットのソースプロトコルアドレスフィールドに書き込まれたＩＰアドレスと同じＩＰアドレスを有するエントリーを検索する。さらに、前記エントリー内のＭＡＣアドレスが前記選択ＵｎＡＲＰパケットのソースハードウェアアドレスフィールドの値と同じであるかを判断する(Ｓ６７０)。判断の結果、同じである場合には、このエントリーを削除し、前記選択ＵｎＡＲＰパケットを転送した端末の正しいＩＰアドレス及びＭＡＣアドレスの値を有するエントリーを前記ＡＲＰキャッシュテーブルに追加する(Ｓ６８０)。もし、前記エントリーのＭＡＣアドレスが前記選択ＵｎＡＲＰパケットのソースハードウェアアドレスフィールドの値と同じでない場合には、前記エントリーを削除せず、そのままにして置く。

前記の図６の実施の形態においては、不要ＡＲＰ及び選択ＵｎＡＲＰを共に使用する場合を示しているが、両者は、必ずしも共に使用する必要はなく、それぞれ独立して使用することもできる。ＩＰアドレスの衝突が発生し、ＩＰアドレスの変更がある場合に、ＩＰアドレスの衝突を起こした端末のみが前記ＩＰアドレスの変更を認知するため、前記端末のうちの少なくとも一つは、周辺の端末に誤ったＩＰアドレスを修正することを要求する必要がある。従って、衝突の後、ＩＰアドレスの変更のある端末が不要ＡＲＰを転送することにより、または、ＩＰアドレスの変更のない端末が選択ＡＲＰを転送することにより、周辺の端末のＡＲＰキャッシュテーブルが正しい値を有するように動的に保持することができる。このように、両者のうち何れを用いても正しい転送を行うことができるが、無線通信は、有線通信に比べてパケットの損失など、予期せぬ問題が発生しやすいため、安定性を考慮し、両者共に使用することがより好ましい。

以上のように、上記実施の形態を参照して詳細に説明され図示されたが、本発明は、これに限定されるものでなく、このような本発明の基本的な技術的思想を逸脱しない範囲内で、当業界の通常の知識を有する者にとっては、他の多くの変更が可能であろう。また、本発明は、添付の特許請求の範囲により解釈されるべきであることは言うまでもない。

従来の技術によるＵｎＡＲＰ動作を示す図である。既存のＡＲＰパケットの構成を示す図である。ＩＰアドレスが重複するアドホックネットワークの動作環境を示す図である。ＡＲＰキャッシュテーブルが更新されていない場合のパケットの転送を示す図である。本発明に係る選択ＵｎＡＲＰパケットの構成を示す図である。本発明に係るＩＰアドレスが重複する場合に、ＡＲＰキャッシュテーブルを更新する方法を示すフローチャートである。

符号の説明

３１０端末ａ
３２０端末ｂ
３３０端末ｃ
３４０端末ｄ
３５０端末ｅ
３４１ＡＲＰキャッシュテーブル

Claims

プロトコルアドレスの重複を検出し、前記重複したアドレスを有する端末のうちの一部の端末のプロトコルアドレスを変更する第１ステップと、
前記アドレスの変更された端末が、変更前のプロトコルアドレス情報及び自分のハードウェアアドレス情報を周辺の端末に転送する第２ステップと、
前記各アドレス情報を受信した周辺の端末が前記受信した情報に基づいて、アドレス情報を有するテーブルを更新する第３ステップとを含み、
前記第２ステップは、
前記アドレスの変更された端末が、他の端末から受信したデータパケットを前記他の端末に再転送するときに行なわれることを特徴とするアドホックネットワークにおいて動的にアドレス情報テーブルを更新する方法。
前記第３ステップは、
前記各アドレス情報を受信した周辺の端末が、アドレス情報を有するテーブルから前記プロトコルアドレス情報と同じプロトコルアドレスを有するエントリーを検索するステップと、
前記エントリーのハードウェアアドレスが前記ハードウェアアドレス情報と同じである場合は、前記エントリーを削除するステップとをさらに含むことを特徴とする請求項１に記載のアドホックネットワークにおいて動的にアドレス情報テーブルを更新する方法。
前記第３ステップは、
前記エントリーを削除した後、前記情報を転送した端末の正しいプロトコルアドレス及びハードウェアアドレスを有するエントリーを前記アドレス情報テーブルに追加するステップをさらに含むことを特徴とする請求項１に記載のアドホックネットワークにおいて動的にアドレス情報テーブルを更新する方法。
前記プロトコルアドレス情報及びハードウェアアドレス情報は、選択ＵｎＡＲＰパケットを用いて転送し、
前記選択ＵｎＡＲＰパケットのソースハードウェアアドレスフィールドには前記転送する端末自分のＭＡＣアドレスが書き込まれ、ソースプロトコルアドレスフィールドには変更前のプロトコルアドレスが書き込まれ、宛先ハードウェアアドレスフィールドには何も書き込まれず、宛先プロトコルアドレスドウェアアドレスフィールドにはブロードキャストアドレスが書き込まれることを特徴とする請求項１乃至３の何れかに記載のアドホックネットワークにおいて動的にアドレス情報テーブルを更新する方法。
プロトコルアドレスの重複を検出し、前記重複したアドレスを有する端末のうちの一部の端末のプロトコルアドレスを変更する第１ステップと、
前記重複したプロトコルアドレスを有する端末のうち、アドレスが変更されない端末が、周辺の端末に自分のアドレス情報を転送する第２ステップと、
前記情報を受信した周辺の端末が、前記受信した情報に基づいて、アドレス情報を有するテーブルを更新する第３ステップとを含み、
前記アドレス情報は、不要ＡＲＰパケットを用いて転送し、
前記不要ＡＲＰパケットのソースハードウェアアドレスフィールドには前記転送する端末自分のＭＡＣアドレスが書き込まれ、ソースプロトコルアドレスフィールドには前記転送する端末自分のプロトコルアドレスが書き込まれ、宛先ハードウェアアドレスフィールドには何も書き込まれず、宛先プロトコルアドレスフィールドには前記転送する端末自分のプロトコルアドレスが書き込まれることを特徴とするアドホックネットワークにおいて動的にアドレス情報テーブルを更新する方法。
プロトコルアドレスの重複を検出し、前記重複したアドレスを有する端末のうちの一部の端末のプロトコルアドレスを変更する第１ステップと、
前記アドレスの変更された端末が、変更前のプロトコルアドレス情報及び自分のハードウェアアドレス情報を周辺の端末に転送する第２ステップと、
前記各情報を受信した周辺の端末が前記受信した情報内容に基づいて、アドレス情報を有するテーブルを更新する第３ステップと、
前記重複したプロトコルアドレスを有する端末のうち、アドレスが変更されない端末が、周辺の端末に自分のアドレス情報を転送する第４ステップと、
前記第４ステップでのアドレス情報を受信した周辺の端末が前記受信した情報に基づいて、アドレス情報を有するテーブルを更新する第５ステップとを含み、
前記第２ステップは、
前記アドレスの変更された端末が、他の端末から受信したデータパケットを前記他の端末に再転送するときに行なわれることを特徴とするアドホックネットワークにおいて動的にアドレス情報テーブルを更新する方法。
前記第３ステップは、
前記各アドレス情報を受信した周辺の端末が、アドレス情報を有するテーブルから前記プロトコルアドレス情報と同じプロトコルアドレスを有するエントリーを検索するステップと、
前記エントリーのハードウェアアドレスが前記ハードウェアアドレス情報と同じである場合には、前記エントリーを削除するステップとをさらに含むことを特徴とする請求項６に記載のアドホックネットワークにおいて動的にアドレス情報テーブルを更新する方法。
前記第３ステップは、
前記エントリーを削除した後、前記情報を転送した端末の正しいプロトコルアドレス及びハードウェアアドレスを有するエントリーを前記アドレス情報テーブルに追加するステップをさらに含むことを特徴とする請求項６に記載のアドホックネットワークにおいて動的にアドレス情報テーブルを更新する方法。
前記プロトコルアドレス情報及びハードウェア情報は、選択ＵｎＡＲＰパケットを用いて転送し、
前記選択ＵｎＡＲＰパケットのソースハードウェアアドレスフィールドには前記転送する端末自分のＭＡＣアドレスが書き込まれ、ソースプロトコルアドレスフィールドには変更前のプロトコルアドレスが書き込まれ、宛先ハードウェアアドレスフィールドには何も書き込まれず、宛先プロトコルアドレスフィールドにはブロードキャストアドレスが書き込まれることを特徴とする請求項６乃至８の何れかに記載のアドホックネットワークにおいて動的にアドレス情報テーブルを更新する方法。
前記アドレス情報は、不要ＡＲＰパケットを用いて転送し、
前記不要ＡＲＰパケットのソースハードウェアアドレスフィールドには前記転送する端末自分のＭＡＣアドレスが書き込まれ、ソースプロトコルアドレスフィールドには前記転送する端末自分のプロトコルアドレスが書き込まれ、宛先ハードウェアアドレスフィールドには何も書き込まれず、宛先プロトコルアドレスフィールドには前記転送する端末自分のプロトコルアドレスが書き込まれることを特徴とする請求項６に記載のアドホックネットワークにおいて動的にアドレス情報テーブルを更新する方法。
前記アドレス情報を有するテーブルは、各端末が有するＡＲＰキャッシュテーブルであることを特徴とする請求項１乃至３、請求項５乃至１０の何れかに記載のアドホックネットワークにおいて動的にアドレス情報テーブルを更新する方法。
プロトコルアドレスの重複がある場合に、アドホックネットワークにおける自動アドレス割り当て機能を利用し、前記プロトコルアドレスが変更される第１の端末と、
前記第１の端末と直接通信できる位置にある周辺の端末とを備え、
前記第１の端末は、変更前のプロトコルアドレス情報及び自分のハードウェアアドレス情報を周辺の端末に転送し、前記周辺の端末は、前記受信した内容に基づいて、アドレス情報を有するテーブルを更新し、
前記アドレスの変更された端末が、他の端末から受信したデータパケットを前記他の端末に再転送する場合に、前記各情報を周辺の端末に転送することを特徴とするアドホックネットワークにおいて動的にアドレス情報テーブルを更新するシステム。
前記各アドレス情報は、選択ＵｎＡＲＰパケットを用いて転送し、
前記選択ＵｎＡＲＰパケットのソースハードウェアアドレスフィールドには前記第１の端末のＭＡＣアドレスが書き込まれ、ソースプロトコルアドレスフィールドには変更前のプロトコルアドレスが書き込まれ、宛先ハードウェアアドレスフィールドには何も書き込まれず、宛先プロトコルアドレスフィールドにはブロードキャストアドレスが書き込まれることを特徴とする請求項１２に記載のアドホックネットワークにおいて動的にアドレス情報テーブルを更新するシステム。
前記プロトコルアドレスの重複がある場合にも、前記プロトコルアドレスが変更されない第２の端末をさらに備え、
前記第２の端末は、前記周辺の端末のうち、前記第２の端末と直接通信できる位置にある端末に、自分のアドレス情報を転送することを特徴とする請求項１２に記載のアドホックネットワークにおいて動的にアドレス情報テーブルを更新するシステム。
前記アドレス情報は、不要ＡＲＰパケットを用いて転送し、
前記不要ＡＲＰパケットのソースハードウェアアドレスフィールドには前記第２の端末のＭＡＣアドレスが書き込まれ、ソースプロトコルアドレスフィールドには前記第２の端末のプロトコルアドレスが書き込まれ、宛先ハードウェアアドレスフィールドには何も書き込まれず、宛先プロトコルアドレスフィールドには前記第２の端末のプロトコルアドレスが書き込まれることを特徴とする請求項１４に記載のアドホックネットワークにおいて動的にアドレス情報テーブルを更新するシステム。
前記アドレス情報を有するテーブルは、各端末が有するＡＲＰキャッシュテーブルであることを特徴とする請求項１２乃至１５の何れかに記載のアドホックネットワークにおいて動的にアドレス情報テーブルを更新するシステム。