JP4791401B2 - 移動通信システム及び移動通信プログラム - Google Patents

Description

本発明は、Ｍｏｂｉｌｅ ＩＰネットワーク上に設置されるホームエージェントと呼ばれる位置管理を行うノードにおいてパケット転送処理能力を向上させることができる移動通信システム及び移動通信プログラムに関する。

ＴＣＰ／ＩＰを利用して通信を行う環境において、異なるネットワークに移動した場合でも、セッションを継続するための方式としてＭｏｂｉｌｅ ＩＰが規格化されている（非特許文献１）。Ｍｏｂｉｌｅ ＩＰネットワークとは通常のＩＰネットワーク上に、移動端末の位置管理およびパケット転送を行うモビリティエージェントを配置したものである。

移動端末がＨｏｍｅ Ｎｅｔｗｏｒｋを離れてＦｏｒｅｉｇｎ Ｎｅｔｗｏｒｋ（以下、ＦＡと称する）に移動したときには、位置登録のためにＲｅｇｉｓｔｒａｔｉｏｎ Ｒｅｑｕｅｓｔ（ＲＲＱ）メッセージをＦＡ経由でホームエージェント（以下、ＨＡと称する）に転送する。その際、ＨＡおよびＦＡは移動端末（以下、ＭＮと称する）に関する情報をｂｉｎｄｉｎｇ ｌｉｓｔ（ＢＬ）およびｖｉｓｉｔｏｒ ｌｉｓｔ（ＶＬ）として各々の記憶装置内に格納する。この際ＨＡは、Ｈｏｍｅ ＮｅｔｗｏｒｋにＧｒａｔｕｉｔｏｕｓ ＡＲＰをブロードキャストし、Ｈｏｍｅ Ｎｅｔｗｏｒｋ内のノードのＡＲＰテーブルからそのＭＮのエントリを削除する。ＨＡはＲＲＱメッセージを受信したあと、Ｒｅｇｉｓｔｒａｔｉｏｎ Ｒｅｐｌｙ（ＲＲＰ）メッセージをＦＡ経由でＭＮに転送することにより位置登録が行われる。

ＭＮがＨｏｍｅ Ｎｅｔｗｏｒｋを離れているときに通信相手の端末（以下、ＣＮと称する）がＭＮ宛に送信したデータは、Ｈｏｍｅ Ｎｅｔｗｏｒｋ内のＨＡが代理ＡＲＰを利用して代わりに受信し、Ｆｏｒｅｉｇｎ Ｎｅｔｗｏｒｋ上のＦＡにデータをカプセル化して転送する。ＦＡは受信したカプセル化パケットからＭＮ宛のデータを取り出し、ＭＮに転送することによりＭＮ宛のデータ転送が行われる。

一方、ユーザノードはあらかじめ固定的なＩＰアドレスを持っていなくても、ＤＨＣＰサーバからＩＰアドレス割り当てを受けることにより、ＩＰアドレスおよびＤＮＳサーバなどの情報を取得し、通信を開始することができる。ＤＨＣＰサーバは、ネットワーク管理者が定めたＩＰアドレス空間を管理しており、その中から空いているＩＰアドレスを払い出す。通常はＤＨＣＰサーバが配置されているネットワークセグメント内のＩＰアドレス空間を管理しているが、ＤＨＣＰリレーを使って離れたネットワークに配置されたＤＨＣＰサーバへメッセージを転送すれば、離れたネットワークに関するＩＰアドレス割り当ても可能である（非特許文献２）。
http://www.ietf.org/rfc/rfc3344.txt http://www.ietf.org/rfc/rfc2131.txt

ユーザがネットワーク間を移動しても通信を継続することができるという特徴はモビリティ（移動透過性）と呼ばれ、モビリティを提供する仕組みとしてよく用いられるものに、Ｍｏｂｉｌｅ ＩＰやＭｏｂｉｌｅ ＩＰｖ６などがある。これらの方式では、ホームネットワークという概念があり、移動ユーザはそれぞれホームネットワークに所属しているホームＩＰアドレスを持っており、移動先のネットワークにおいてもそのホームＩＰアドレスを使い続けるのが一般的である。

しかしながら、ホームネットワークにユーザがいない場合、ホームネットワーク内に設置されたホームエージェント（ＨＡ）は、移動ユーザ宛のパケットを代理受信して、この移動ユーザ対して転送しなければならないため、ＨＡに大きな負荷が掛かり、ＨＡに障害が発生した場合は移動ユーザのすべてに波及してしまうという問題がある。

本発明は、このような事情に鑑みてなされたもので、移動通信ネットワーク全体をモビリティに対応させることによって、ネットワーク全体の処理効率を向上させることができる移動通信システム及び移動通信プログラムを提供することを目的とする。

本発明は、ＩＰネットワーク上においてパケット転送を行う移動通信システムであって、パケット送信元である第１の端末を収容する第１のカレントエッジルータと、前記パケットの受信元である第２の端末が取得したＩＰアドレスを収容するホームエッジルータとの間に第１のトンネルを確立する第１のトンネル確立手段と、前記第２の端末が送信するパケットの送信元ＩＰアドレスに基づいて、前記第２の端末が移動して第２のカレントエッジルータにより収容されていることが検知された場合に、前記第２のカレントエッジルータと前記ホームエッジルータとの間のトンネルを確立する要求をルータ間で通信することで、前記第２のカレントエッジルータと、前記ホームエッジルータとの間に第２のトンネルを確立する第２のトンネル確立手段と、前記第１のトンネルと前記第２のトンネルとが確立しており、前記第１及び第２のトンネルを経由して、前記第１の端末から前記第２の端末へパケットを転送している場合に、各端末が収容されるルータを特定するトンネル情報及び端末間で通信を行っている２つの端末を特定するコネクション情報に基づいて、前記第１のトンネルを、前記第１のカレントエッジルータと、前記第２のカレントエッジルータとの間に確立し直す第３のトンネル確立手段と、を備えたことを特徴とする。

本発明は、前記第３のトンネル確立手段により前記第１のトンネルを確立し直した後に、前記第２の端末が送信するパケットの送信元ＩＰアドレスに基づいて、前記第２の端末が移動してその移動後のカレントエッジルータにより収容されていることが検知された場合に、各端末が収容されるルータを特定するトンネル情報に基づいて、前記第２の端末の移動前のカレントエッジルータと、前記第２の端末の移動後のカレントエッジルータとの間に、第３のトンネルを確立する第４のトンネル確立手段をさらに備えたことを特徴とする。

本発明は、ＩＰネットワーク上においてパケット転送を行う移動通信システムにおける移動通信プログラムであって、パケット送信元である第１の端末を収容する第１のカレントエッジルータと、前記パケットの受信元である第２の端末が取得したＩＰアドレスを収容するホームエッジルータとの間に第１のトンネルを確立する第１のトンネル確立処理と、前記第２の端末が送信するパケットの送信元ＩＰアドレスに基づいて、前記第２の端末が移動して第２のカレントエッジルータにより収容されていることが検知された場合に、前記第２のカレントエッジルータと前記ホームエッジルータとの間のトンネルを確立する要求をルータ間で通信することで、前記第２のカレントエッジルータと、前記ホームエッジルータとの間に第２のトンネルを確立する第２のトンネル確立処理と、前記第１のトンネルと前記第２のトンネルとが確立しており、前記第１及び第２のトンネルを経由して、前記第１の端末から前記第２の端末へパケットを転送している場合に、各端末が収容されるルータを特定するトンネル情報及び端末間で通信を行っている２つの端末を特定するコネクション情報に基づいて、前記第１のトンネルを、前記第１のカレントエッジルータと、前記第２のカレントエッジルータとの間に確立し直す第３のトンネル確立処理と、をコンピュータに行わせることを特徴とする。

本発明によれば、端末が特別な処理を行うことなくネットワーク間を移動してもモビリティを維持しながらネットワークの資源を効率良く使用することができるという効果が得られる。

以下、本発明の一実施形態による移動通信システムを図面を参照して説明する。図１は同実施形態における移動通信システム全体の構成を示す図である。この図において、符号１１は、ホームＩＰアドレスは持っていないが、自己を識別するために、移動に関わらず不変のＦＱＤＮ（Fully Qualified Domain Name；完全修飾ドメイン名）を持つ移動端末（以下、ＭＮと称する）である。符号２１、２２、２３は、ユーザが直接接続するネットワークである各アクセス網のアクセスルータにそれぞれ配置され、そのネットワーク内でのＩＰアドレス割り当てを担当するＤＨＣＰサーバである。符号３１、３２、３３は、コアネットワークの端に配置され、各アクセス網を収容するエッジルータである。符号３４〜３７は、コアネットワーク内に配置されるコアルータである。符号４は、ホスト名とＩＰアドレスとの相互変換を行うＤＮＳサーバである。ここでは、ＭＮ全てがあるひとつのドメイン名（例えばｍｏｂｉｌｅｎｏｄｅ．ｎｅｔ）に属しており、各ＭＮは「ホスト名．ドメイン名」というＦＱＤＮ（完全修飾ドメイン名）を持つものとする。すなわち、そこに問い合わせればＭＮに関するホスト名からＩＰアドレスへの変換ができることになる。

＜基本的な仕組み＞
次に、図２を参照して、エッジルータ３１、３２、３３においてＭＮ１１の状況を管理することにより、ＭＮ１１のネットワーク間移動前後のＩＰアドレス変化を抑制してモビリティを提供するための基本的な仕組みを説明する。ここでは、説明を簡単にするために、エッジルータＡ、Ｂ、Ｃと通信相手の移動端末（以下、ＣＮと称する）１２、ＭＮ１１およびＤＮＳサーバ４とからなる構成を用いて、ＭＮ１１がルータＢ配下からルータＣ配下へと移動する動作を説明する。なお、エッジルータ間のトンネルとしてＩＰ−ｉｎ−ＩＰカプセル化を利用するものとして説明するが、これに限定するものではなく、他のトンネリング技術（例えばＧＲＥカプセル化、ＭＰＬＳなど）であってもよい。

まず、初期状態としてエッジルータが全くＭＮ１１の状況を把握していない状態から通信を開始したものとする。ＣＮ１２は、ＭＮ１１と通信するためにＤＮＳサーバ４に対して、ＭＮ１１のＩＰアドレスを問い合わせ、ＭＮ１１のＩＰアドレスを取得する（図２（１））。続いて、ユーザＣＮ１２は得られたＩＰアドレスを宛先としてパケットを送信する（図２（２））。このパケットを受信したルータＡは宛先を収容しているエッジルータ（ここではルータＢ）までのトンネルを確立する（図２（３））。ここで、すでにトンネルが確立されていれば、トンネルを確立する必要はない。

次に、ＩＰカプセル化したパケットをコアネットワーク内に送信するとルータＢまで到達する（図２（４））。ルータＢはＩＰカプセル化されたパケットのカプセル化を解除し、このパケットをＭＮ１１へ送信する（図２（５））。そして、ＭＮ１１がルータＢからルータＣへと移動する（図２（６））と、ＭＮ１１から何らかのパケットが送出されることによって、ルータＣはＭＮ１１が移動してきたことを検知する。その際そのパケットの送信元ＩＰアドレスを参照することによってＭＮ１１のＩＰアドレスを知ることができる（図２（７））。移動元のＩＰアドレスが分かればそのエッジルータ（ルータＢ）に対してユーザ情報の問い合わせとトンネル確立を要求する。この結果、ユーザ情報が返答され、同時にルータＢ−Ｃ間のトンネルが確立する（図２（８））。このユーザ情報にはルータＡとの間にトンネルを張っていたことが含まれているため、ルータＡ−Ｂ間にで張られたトンネルをルータＡ−Ｃ間へ張替える(図２（９））。そして、ＣＮ１２がＭＮ１１（ルータＢ配下のＩＰアドレス）へパケットを送信する（図２（１０））と、ルータＡはルータＣとのトンネルを確立しているので、ＩＰカプセル化してパケットを転送する（図２（１１））。ルータＣは、このＩＰカプセル化パケットのカプセル化を解除して、パケットをＭＮ１１へ転送する（図２（１２））。これにより、ＭＮ１１がルータＢからルータＣへ移動した後も同一ＩＰアドレスを使用してパケットを送受信し続けることができる。

なお、図２（８）において確立されるトンネル以外は双方向のトンネルであるため、ＭＮ１１からＣＮ１２へパケットを送信するのに新たなトンネルを確立する必要はない。また、図２（８）において確立されるトンネルは、移動直後にルータＢへ到達したパケットを救済するとともに、新たな移動端末が新たに通信を開始する際に名前解決を行うが、この時点のＭＮ１１のＩＰアドレスはルータＢ配下のＩＰアドレスであるため、全く別の移動端末が新たにＭＮ１１との通信を開始しようとした場合のための救済措置である。したがって、図２（８）において確立されるトンネルは一方向（ルータＢからルータＣへのトンネル）でよい。

ここで、エッジルータの種類について説明しておく。ホームエッジルータ（Ｈｏｍｅ Ｅｄｇｅ Ｒｏｕｔｅｒ：以下、ＨＲと称する）は、ＭＮ１１が取得したＩＰアドレスのネットワークＩＰアドレスを収容するルータであり、ライフタイムは長い（無限）、またはＤＨＣＰと連携してＲｅｌｅａｓｅのタイミングで削除する。トランジエントエッジルータ（Ｔｒａｎｓｉｅｎｔ Ｅｄｇｅ Ｒｏｕｔｅｒ：以下、ＴＲと称する）は、ＭＮ１１が移動していくときの移動元ルータでライフタイムは短い。カレントエッジルータ（Ｃｕｒｒｅｎｔ Ｅｄｇｅ Ｒｏｕｔｅｒ：以下、ＣＲと称する）は、ＭＮ１１が現時点で存在しているネットワークのルータである。図２に示す例では、（１２）の時点で、ルータＡはＣＮ１２のＨＲかつＣＲ、ルータＢはＭＮ１１のＨＲ、ルータＣはＭＮ１１のＣＲとなる。この例ではＴＲは存在しないが、ＭＮ１１がさらにルータＤなどに移動すればルータＣがＴＲとなる。

次に、トンネルエンドポイントについて説明する。ＣＮトンネルは、相手のＣＲと自分のＣＲ間の双方向のトンネルである。Ｈｏｍｅトンネルは、ＨＲからＣＲへの一方向のトンネルである。Ｔｒａｎｓｉｅｎｔトンネルは、ＴＲからＣＲへの一方向のトンネルであり、ＣＲへトンネルを張り替える間の一時的なトンネルであるため、ライフタイムは短い。

次に、エッジルータが管理する情報について説明する。トンネル情報テーブルは、ＭＮ１１の現在位置（ＭＮ１１のＩＰアドレスと収容ルータのＩＰアドレスのマッピング）に関するエントリを保持する。ただし、収容ルータのＩＰアドレスが通信相手のＨＲである場合には、ルータ自身のＩＰアドレスではなく、ＭＮ自身のＩＰアドレスとなる。コネクション情報テーブルは、当該ルータにおいて、どの移動端末間において通信が行われているかを示す情報（２つの移動端末のＩＰアドレス）を保持する。これらのテーブルエントリにはライフタイムを持たせることで、無駄なエントリがリソースを圧迫することを防ぐことも可能である。また、例えばトンネル情報テーブルでは、トンネル種別情報を持たせることにより、ＩＰカプセル化、ＭＰＬＳなど様々なトンネル手法を使い分けることも可能である。

次に、シグナリングについて説明する。図２に示す動作ではトンネル制御用のシグナリングを明記していないが、実際には各種トンネルを、確立、張り替え、削除するためにシグナリングが必要である。全く新規のコネクションを検出した際に、ＣＮトンネルを新たに確立するために、トンネル新規確立要求（Ｔｕｎｎｅｌ Ｃｒｅａｔｅ Ｒｅｑｕｅｓｔ）とトンネル新規確立応答（Ｔｕｎｎｅｌ Ｃｒｅａｔｅ Ａｃｋ）を送受信する。ＭＮ１１が移動した際に、Ｈｏｍｅトンネルの変更およびＴｒａｎｓｉｔトンネルの設定を行うために、トンネル転送要求（Ｔｕｎｎｅｌ Ｆｏｒｗａｒｄ Ｒｅｑｕｅｓｔ）と、トンネル転送応答（Ｔｕｎｎｅｌ Ｆｏｒｗａｒｄ Ａｃｋ）を送受信する。このとき、移動前のルータ（すなわちＴＲ）またはＨＲからトンネル情報を転送してもらう。ＭＮ１１が移動した際に、通信相手とのＣＮトンネルを更新するために、トンネル張替要求（Ｔｕｎｎｅｌ Ｃｈａｎｇｅ Ｒｅｑｕｅｓｔ）と、トンネル張替応答（Ｔｕｎｎｅｌ Ｃｈａｎｇｅ Ａｃｋ）を送受信する。指定したトンネルを削除するために、トンネル削除要求（Ｔｕｎｎｅｌ Ｒｅｖｏｃａｔｉｏｎ Ｒｅｑｕｅｓｔ）とトンネル削除応答（Ｔｕｎｎｅｌ Ｒｅｖｏｃａｔｉｏｎ Ａｃｋ）を送受信する。トンネル削除の例としては、あるＭＮ（またはＣＮ）に関するすべてのトンネルを削除する方法と、特定のＭＮ−ＣＮ間のトンネルのみを削除する方法がある。

なお、トンネル転送応答（Ｔｕｎｎｅｌ Ｆｏｒｗａｒｄ Ａｃｋ）以外の応答シグナルは信頼性向上のために規定されているため省略することが可能であるが、トンネル転送応答（Ｔｕｎｎｅｌ Ｆｏｒｗａｒｄ Ａｃｋ）だけは、信頼性向上以外の役割も担っているため省略することはできない。

＜詳細なシーケンス＞
次に、図６〜図１９を参照して、ＭＮ１１が移動した場合のシグナリングおよびデータ配送動作について説明する。初めに、図６〜図８を参照して、ＭＮ１１とＣＮ１２との間で初期の通信を行う動作を説明する。ここでは、ルータＡ（ＩＰアドレス：ＩＰ＿Ａ）がＣＮ１２のＨＲ、ルータＢ（ＩＰアドレス：ＩＰ＿Ｂ）がＭＮ１１のＨＲであり、それぞれルータＡ、ルータＢ配下のＩＰアドレスを持っているものとする（図６）。エッジルータがアクセス網からパケットを受信した場合、このパケットが新しいコネクションであるか否かを確認する（図７（１）〜（２））。この確認にはコネクション情報テーブルを参照し、コネクション情報テーブルに該当エントリが無ければトンネル確立処理を開始し、一方、コネクション情報に該当エントリがあれば、さらにトンネル情報を参照し、カプセル化を行い、パケットを転送する。

ルータＡは、初期状態ではコネクション情報、トンネル情報とも空である。このため、ヒットするエントリが無く、トンネル確立処理が開始される。このとき、まず各テーブルにエントリが登録される（図７（２））。また、シグナルを受け取った相手ルータＢも同様にエントリを登録する（図７（４））。なお、この段階では、ルータＡはルータＢのＩＰアドレスを知らないため、図７（３）に示すシグナリングの宛先は、ＭＮ１１の宛先であり、それを受けたルータＢは当該シグナルに関しては、ＭＮ１１に転送せずにルータＢ自身が処理しなければならない。

ルータＡ内で作成されるトンネル情報エントリは、ＩＰｍｎ宛パケットをＩＰｍｎでカプセル化し、ＩＰｃｎ宛のパケットは自ルータ配下にＣＮが存在しているため、カプセル化を行わずに転送すべきであること示す情報となる。なお、図７においてはルータＡのトンネル情報は、ＩＰｍｎ→ＩＰｍｎとなっているが、（５）に示すＡｃｋを利用すればこれを、ＩＰｍｎ→ＩＰ＿Ｂに書き換えることも可能である。以下の説明においてはこの書き換えは行わないものとする。続いて、ルータＡは、トンネル情報を参照して、パケットをカプセル化し（図８（６））、ルータＢへカプセル化パケットを転送する（図８（７））。これを受けたルータＢは、トンネル情報を参照して、カプセル化を解除して（図８（８））、ＭＮ１１へパケットを転送する（図８（９））。

次に、ＭＮ１１が移動した場合に通信を行う動作を説明する。まず移動を検知すると、移動先のルータＣはＩＰｍｎというノードが移動してきたことを知ることができる。この移動検知の方法については後述する。しかし、この時点ではルータＣはＭＮ１１に関する情報を持っていないが、ＩＰｍｎというＩＰアドレスが、ルータＣが管理しているネットワークＩＰアドレスではないことが検知できる。そこで図９（２）に示すシグナリングによって、ＩＰｍｎのＨＲにトンネル情報を問い合わせる。このシグナリングの宛先はＩＰｍｎであり、それを受信したルータＡはＭＮ１１へそれを転送せず、ルータＡ自身が処理しなければならない。このシグナルを受け取ることによって、ルータＡはＭＮ１１がルータＣ配下へ移動したことを知ることができるため、図９（３）のように該当するトンネル情報を更新することができる。これにより、ルータＢ→ルータＣの一方向のトンネル（Ｈｏｍｅトンネル）が作成される。

その後、図１０（４）に示すように応答シグナルを返すが、そこにはルータＢが保持していたＭＮ１１に関するコネクション情報およびトンネル情報をすべて含まれる。図１０（５）に示すように、受信した応答パケットからコネクション情報およびトンネル情報を取得し、自身に設定する。図１１はこの直後にＣＮ１２からのパケット送信が発生する場合を示しているが、何も発生しなければ図１２に示す処理が起こる。図１１に示すように、ルータＡから一度ルータＢにパケットが転送されるが、トンネル情報エントリが更新されているため、さらにルータＣへパケットが転送され、ＭＮ１１の移動先にパケットが到達する。ルータＣがトンネル情報、コネクション情報を取得すれば、図１１に示す処理のようにパケット転送は継続されるが、ルータＢへの経路が冗長である。そこで、図１２に示すように、トンネル（ＣＮトンネル）の張替えを行う。これにより、図１３に示すように、経路が最適化される。なお、このＴＦＣｎｇシグナルは、ＭＮ１１と通信を行っている全コネクションに関して送信されなければならない。

図１４及び図１５は、ＭＮ１１がＨＲを離れてしまった際に、新たなＣＮ２・１３がＭＮ１１へパケットを発送する場合の動作を示している。ＣＮ２・１３はＩＰｍｎ（ルータＢ配下のＩＰアドレス）あてにパケットを送信するため、図１４（２）に示すように、一度ルータＥとルータＢの間でトンネルを張ろうとする。しかし、現在ＭＮ１１はルータＣに移動しているため、作成すべきＣＮトンネルはルータＥとルータＣ間であるため、図１５（５）に示すように、受信したシグナル（Ｔｕｎｎｅｌ Ｃｒｅａｔｅ Ｒｅｑｕｅｓｔ）をルータＣへ転送するとともに、ルータＥへトンネルを張り替えるよう指示する（ＴＦＣｎｇ）。なお、この際に（４）で、ルータＢ（ＭＮ１１のＨＲ）はＣＮ２・１３とＭＮ１１に関するトンネル情報、コネクション情報を保持することができる。なお、図１５においては省略しているＴｕｎｎｅｌ Ｃｒｅａｔｅ Ａｃｋをもし送信する場合には、ルータＣからルータＥへ送信される。

次に、ＭＮ１１がさらに移動した場合に通信を行う動作を説明する。なお、以下の説明においては、ＴＦＣｎｇＡｃｋシグナルは省略して説明する。図１６〜図１９は、ルータＣに移動したＭＮ１１がさらにルータＤに移動した状況を示している。この場合も、前述した図９に示す動作と似ている動作を行う。異なる点は、ルータＢが図１６（２）で受信したシグナルにトンネル情報が書き換えられるタイミング（図１７（４））である。この判断は、元のトンネル情報がＩＰ＿Ｃ宛であるのに対し、ＴＦｃｎｇがＩＰ＿Ｄから送られてきたことで判別する。これは図１６（３）に示すようにルータＢからルータＣへのＴＦＣｎｇシグナルが移動前のルータＣへ先に送られる。このＴＦＣｎｇシグナルによって、ルータＣはＴＲになり、ルータＣからルータＤへのトンネルは短命なＴｒａｎｓｉｅｎｔトンネルとなる。

短命である理由は、図１８（７）に示すように送られるＴＦＣｎｇシグナルが全関連ＣＮ群に送られれば、すべてのＣＮトンネルが新しい移動先であるルータＤに向くので、このトンネル自身が全く不要になるからである。これは、移動処理が不完全な状態で、ルータＣにトンネルされてくるパケットを救済するための措置である。このため、図１９に示すように、ルータＣは一定時間経過後にＭＮ１１に関する全エントリを削除する。なお、図示していないが、ＴＦＣｎｇシグナルがすべて完了した時点で、明示的にＴｕｎｎｅｌ Ｆｏｒｗａｒｄ ＲｅｖｏｃａｔｉｏｎメッセージをルータＤからルータＣへ送付することで、ライフタイムによる満了を待たずにエントリを削除してもよい。ただし、ＣＮ１２がルータＣ配下にいる場合には、完全に当該ＭＮ１１に関する情報を消してしまってはならない。Ｔｒａｎｓｉｅｎｔトンネルは、該当するＣＮ−ＭＮペア（すなわちＣＮ１２がルータＣ配下にいないもの）に関してだけのトンネルであり、そうでないものについては、ＣＮ１２トンネルが張られる。

＜アクセス網側のＬａｙｅｒ２処理＞
次に、アクセス網側のＬａｙｅｒ２処理について説明する。エッジルータは通常ＡＲＰ（Ａｄｄｒｅｓｓ Ｒｅｓｏｌｕｔｉｏｎ Ｐｒｏｔｏｃｏｌ）によって、ＩＰアドレスとＭＡＣアドレス（Ｌａｙｅｒ２ＩＰアドレス）のマッピングを行い、アクセス網内のノードへ最終的にパケットを転送する。本発明においても同様の方法を用いるが、従来の処理とは異なる対応が必要である。同様に、移動したＭＮ１１も新たな手順が必要となる。

ＭＮ１１はネットワークを移動した際に、自身のＡＲＰテーブル（ＩＰアドレスとＭＡＣアドレスの対応テーブル）を一旦すべて削除する。実際にはネットワーク間移動になっていなかったとしても再度ＡＲＰが実行されるだけなので問題はない。ネットワーク間移動だった場合は、デフォルトＧＷの設定や移動前に同一ネットワークだったノードとの通信を継続するために、ＡＲＰテーブルの削除が不可欠である。なぜなら、移動先では同一ネットワーク内（移動先のネットワーク）のノードとの通信以外は、すべて移動先エッジルータ（すなわちＣＲ）を経由させなければならないからである。これは、後述する代理ＡＲＰによって実現する。

ＭＮ１１がＨＲにいるというのは、ＭＮ１１のＩＰアドレスが現在所属しているネットワークのネットワークＩＰアドレスであることを示している。すなわち、いわゆる不正のないＩＰアドレスである。ここで不正があるＩＰアドレスとは、例えば１９２．１６８．０．０／２４のネットワークであるにもかかわらず、ＭＮ１１のＩＰアドレスが１９２．１６８．１．１であるような場合である。いわゆる正常な状態であれば、エッジルータが行うＡＲＰ処理も通常通りである。

一方、ＩＰアドレスがＩＰｍｎ、ＭＡＣアドレスＭＡＣｍｎであるＭＮ１１が他のルータ配下へ移動してしまった場合、エッジルータのＡＲＰ処理が通常とは異なる。まず、当該ＭＮ１１のＨＲは、図９（２）、（３）のようにＴＦＲｅｑシグナルを受け取り、トンネル情報エントリを書き換えた際には、当該ＭＮ１１のために代理ＡＲＰを設定する。すなわち、ＨＲのアクセス網でＭＮ１１（ＩＰｍｎ）に関するＡＲＰリクエストが出た場合に、ＨＲが代理でＨＲ自身のＭＡＣアドレスを応答する。また、代理ＡＲＰの設定と同時に、すでにＨＲのアクセス網内にいる他のノードに対しても、それらのＡＲＰテーブルを書き換えるために、ＨＲがＧｒａｔｕｉｔｏｕｓ ＡＲＰをブロードキャストする。このブロードキャストは何度か行うのが好ましい。これによって、アクセス網内すべてのノードが、当該ＭＮ１１への通信をしようとしたときに、このＨＲにパケットを送るようになり、それによって当該ＭＮ１１へパケットを転送できるようになる。なお、この処理は、Ｍｏｂｉｌｅ ＩＰにおけるＨＡの処理と同様である。

ＭＮ１１の移動先であるＣＲでは、当該ＭＮ１１に関するＡＲＰエントリをｐｅｒｍａｎｅｎｔに登録する。すなわち、ＡＲＰプロトコルによる解決ではなく、直接ＡＲＰテーブルにエントリを追加する。これは、図１３（ｅ）でＭＮ１１にパケットを転送するために不可欠である。ＭＮ１１の移動元エッジルータは多くの場合ＴＲである。ＴＲとならないのは図９に示すようにＨＲから始めて移動した場合だけである。ＭＮ１１の移動元エッジルータでは、図１７（４）で当該ＭＮ１１に関するトンネル情報を書き換えたと同時に、当該エッジルータはアクセス網にＧｒａｔｕｉｔｏｕｓ ＡＲＰをブロードキャストする。このブロードキャストは何度か行うのが好ましい。Ｇｒａｔｕｉｔｏｕｓ ＡＲＰの目的（内容）は、当該アクセス網内のノードが保持する当該ＭＮ１１に関するＡＲＰエントリを、ＭＮ１１宛ではなくＴＲ宛になるようにするためである。これによって、通信相手が当該移動元エッジルータ配下にいた場合でも、ＭＮ１１宛パケットは移動元エッジルータへ送られ、ＴｒａｎｓｉｅｎｔトンネルまたはＣＮ１２トンネルを通って、移動先へパケットが到達するようになる。

また、エッジルータは、アクセス網でブロードキャストされたあらゆるＡＲＰリクエストに対して、自身のＭＡＣアドレスを応答する。ただし、自ネットワークに属するＩＰアドレスに関するＡＲＰリクエストには応答する必要はなく、ターゲットが自分自身のときのみ自分自身のＭＡＣを応答する。これによって、他から移動してきたＭＮ１１が誰かと通信しようとした際に発せられるＡＲＰリクエストを救済できる。なお、移動してきたＭＮ１１がＡＲＰを送信するのは、ＭＮ１１が当該ＭＮ１１のＨＲ配下のノードと通信しようとするときである。

＜ネットワーク間を移動したことを検知する移動検知＞
次に、ユーザ端末の移動検知とエッジルータが新たなユーザが移動してきたことを検知する移動検知について説明する。初めに、ユーザ端末の移動検知について説明する。本発明においては、ＭＮ１１自身が別のネットワークに移動したか否かを検出する必要はない。ただし、何らかの移動が起こったことは検知し、ルータへそれを伝える必要がある。具体的には、ＭＮ１１はネットワークインタフェースを監視し、状態に変化があると何らかのパケットをブロードキャストする。ここで、状態の変化とはインタフェースのＵＰ状態から一度ＤＯＷＮ状態になり再びＵＰ状態に戻るようなことである。もしＭＮ１１が有線ＬＡＮに接続しているとすれば、あるネットワークに接続しているＬＡＮケーブル（この時点ではインタフェースはＵＰしている）を一度引き抜いて（ここでインタフェースはＤＯＷＮする）別のネットワークに繋ぎ替える（ここで再度インタフェースがＵＰする）ことで移動できる。

一方、無線ＬＡＮを使う場合には、ＭＮ１１があるアクセスポイントに接続していて、その受信強度が弱くなった際に他のアクセスポイントを検索し、より好条件のアクセスポイントに接続を切り替える。ただし無線ＬＡＮの場合、接続切替の瞬間にインタフェースのＵＰ→ＤＯＷＮ→ＵＰという状態変化が起こる場合と、インタフェースはＵＰしたままでも接続が切り替わったという信号がＯＳ内部に通知される場合がある。例えば接続先のアクセスポイントのＭＡＣアドレスが変化する、そもそも異なるＳＳＩＤのアクセスポイントに接続する等が起こる。

このように、インタフェースレベルで何らかの変化が起こったことを検出し、それに伴ってパケットをブロードキャストし、さらにはそれまで持っていたＡＲＰテーブルを削除する。なお、インタフェースレベルでの変化があったからといって、必ずしもネットワーク間移動が起こったとは言い切れない。例えば、有線ＬＡＮでもケーブルを単に抜いて挿しただけの場合や、無線ＬＡＮアクセスポイントのローミングでもネットワークを跨がない場合が多々ある。ブロードキャストするパケットには、そのＭＮ１１のＩＰアドレスが含まれていればよい。例えばＡＲＰリクエストのように送信元ＩＰアドレスがデータに含まれているパケットや、ＩＰヘッダの送信元ＩＰアドレスがＭＮ１１の元のＩＰアドレスになっていればよい。すなわち、ＭＮ１１自身はインタフェースの状態変化を検出した時点では、ネットワーク間移動が起こっているか否かを知ることは困難なため、単に何らかのパケットを送出すれば、そこにはＭＮ１１の移動前のＩＰアドレス情報が付加されていると考えられる。公知のパソコンＯＳでは、上記のようなインタフェースの状態変化が起こった場合、それまで知っていたデフォルトゲートウェイに対してｐｉｎｇを送信するようになっている。このとき、ｐｉｎｇの送信元ＩＰアドレスはそれまで使用していたＩＰアドレスである。本発明においてもこれをそのまま利用するものとして、以下を説明する。ただし、このタイミングでＡＲＰテーブル削除を同時に行うようにする必要がある。

次に、エッジルータの移動検知について説明する。本発明では、新たなＭＮ１１が移動してきた際に、エッジルータ（ＨＲやＣＲとなるエッジルータ）が前述のようなシグナリングを行ってトンネルの設定などを行わなければならない。そのため、エッジルータは新たなＭＮ１１が移動してきたか否かをいち早く検出する必要がある。その検出に、上述のＭＮ１１から送信されるｐｉｎｇパケットを利用する。Ｐｉｎｇパケットを受信した際には、その送信元ＩＰアドレスがそのアクセス網とは異なるネットワークＩＰアドレスに属するものだった場合に、自身が保持するトンネル情報を調べる。トンネル情報に当該ｐｉｎｇパケットの送信元ＩＰアドレスに関する情報が無ければ、新たにそのアクセス網にやってきたＭＮ１１ということになるため、シグナリングを開始する。もしすでに該当するトンネル情報があれば、トンネルは確立済みであるため、特にシグナリング処理は必要ない。なお、移動検知に用いるパケットをｐｉｎｇに限定する必要はない。ただし、後述するＤＨＣＰなどのシグナリングでは送信元ＩＰアドレスが０．０．０．０になるようなパターンもありうるため、このようなパケットに対しては上記の処理が行われてはならないようにする必要がある。

＜ＩＰアドレス取得＞
以上の説明においては、ＭＮ１１はどこかのネットワークに所属していて固定的なＩＰアドレスを持っていることを仮定して説明してきた。しかし、実際にはＤＨＣＰ（Dynamic Host Configuration Protocol）を用いて動的にＩＰアドレスを取得することが多いため以下の説明においては、ＤＨＣＰを利用する場合について説明する。ここで想定するネットワークは図１に示すように、各アクセス網にそれぞれのＩＰアドレス空間を管理するＤＨＣＰサーバ２１、２２、２３が配置される環境である。

初めに、ホームエッジルータ（ＨＲ）配下でのＩＰアドレス取得動作を説明する。ＭＮ１１が新たにＩＰアドレスを取得すると、そのネットワークのエッジルータがＨＲとなる。以後このネットワークをホームネットワークと呼ぶ。新たなＩＰアドレスを取得したところがホームネットワークなので、あらゆるネットワークがホームネットワークとなりうる。ＤＨＣＰによるＩＰアドレス取得手順は、図３に示すように従来手法と全く同様である。図３において、ＤＨＣＰ Ｄｉｓｃｏｖｅｒ、ＤＨＣＰ ＲｅｑｕｅｓｔがＤＨＣＰサーバ２１とＨＲ３１に到達しているが、これはこれらのパケットがブロードキャストされるためである。ＤＨＣＰシーケンスによってＭＮ１１はこのホームネットワークのＩＰアドレスを取得することができる。

次に、ＭＮ１１が移動した場合の動作を説明する。前述のように、ＭＮ１１のインタフェース状態が変化すると、ｐｉｎｇをそれまで知っていたデフォルトゲートウェイに送信する。従来手法では、そのｐｉｎｇに応答が無ければネットワーク間移動が起こったと判断し、ＤＨＣＰシーケンスが開始される。ＭＮ１１が実際に異なるエッジルータ配下へ移動していた場合、ＭＮ１１から送信されるｐｉｎｇパケットは以下のように処理する。

まず、ＭＮ１１はＡＲＰテーブルを削除し、ｐｉｎｇ送信に向けてＡＲＰによるＭＡＣアドレス解決を行う（ＣＲのＭＡＣアドレスを得る）。そして、ＭＮ１１がｐｉｎｇをデフォルトゲートウェイ（ＨＲ）へ送信する。ＣＲ（移動先エッジルータ）は、このｐｉｎｇを代理受信する。そして、エッジルータ間で前述した移動処理（トンネル確立）が行われ、ＰｉｎｇがＣＲからＨＲへ転送される。これを受けて、ＨＲがｐｉｎｇ応答を返すことにより、ＨＲ→ＣＲ→ＭＮ１１へｐｉｎｇ応答が送信される。これにより、ＭＮ１１がｐｉｎｇ応答を受け取ることになるため、ＭＮ１１はネットワーク間を移動していないと認識することができる。

次に、ＩＰアドレスの更新について説明する。ＤＨＣＰによるＩＰアドレス割り当ては、それぞれのＩＰアドレスに対して割り当てる期間が決められており、その期間が満了するとＭＮ１１はそのＩＰアドレスを削除しなければならず、またＤＨＣＰサーバはそのＩＰアドレスを別のノードに割り当てることが可能となる。そのため、当該ＭＮ１１がそのＩＰアドレスをさらに使い続けたい場合には、ＩＰアドレスを割り当てたＤＨＣＰサーバに対してＤＨＣＰ ｒｅｑｕｅｓｔパケットを送信することにより更新手続きを行う。

ＤＨＣＰサーバは割り当て済みＩＰアドレスを持ったＭＮ１１からＤＨＣＰ ｒｅｑｕｅｓｔを受け取ると、割り当て期間を延長する。前述の通り割り当てを行ったＤＨＣＰサーバはこのＤＨＣＰ ｒｅｑｕｅｓｔを受けとらなければならないが、ＭＮ１１がホームネットワークを離れている場合、従来手法ではＭＮ１１が送信したＤＨＣＰ ｒｅｑｕｅｓｔを移動先ネットワークのＤＨＣＰサーバが受け取ってしまい、そのため、異なるＩＰアドレス割り当てが起こってしまう。従来の手法は、一度目に送られたＤＨＣＰ Ｒｅｑｕｅｓｔに対してＤＨＣＰサーバがＤＨＣＰ Ｎａｋを返答するため、ＭＮ１１はＩＰアドレスを破棄して新たなＩＰアドレスを取得する。なお、ＤＨＣＰ ＲｅｑｕｅｓｔにはＭＮ１１のＭＡＣアドレス情報とＲｅｑｕｅｓｔｅｄ ＩＰというフィールド（そのノードが使いたいＩＰアドレスが書かれている））が含まれており、ＤＨＣＰサーバはこの情報を参照することによって、すでに割り当て済みのＩＰアドレスの更新であるかを判断できる。ただしこの場合には、ＤＨＣＰサーバが管理していないＩＰアドレス（元々ホームネットワークのＤＨＣＰサーバによってＭＮ１１に割り当てられていたＩＰアドレス）がＲｅｑｕｅｓｔｅｄ ＩＰフィールドに書かれているため、それを拒絶してしまう。

次に、図４、図５を参照して、本発明による手法によるＤＨＣＰサーバの動作を説明する。ここでは、図５に示すように、ＭＮ１１のホームネットワークをＮｅｔ Ａ、移動先をＮｅｔ Ｂとし、それぞれのネットワークにＤＨＣＰ＿Ａ、ＤＨＣＰ＿Ｂが配置されており、Ｎｅｔ ＡのエッジルータがＨＲ、Ｎｅｔ ＢのエッジルータがＣＲであるとした場合のＤＨＣＰ Ｒｅｑｕｅｓｔを受信したＤＨＣＰサーバの動作を説明する。

まず、ＭＮ１１がＤＨＣＰ Ｒｅｑｕｅｓｔをブロードキャストし、ＤＨＣＰ＿Ｂが受信する（図４（１））。これを受けて、ＤＨＣＰ＿ＢがＣＲへ問い合わせを行う（図４（２））。ＣＲは、ＤＨＣＰ＿Ｂへ応答を返す（図４（３））。ＤＨＣＰ＿ＢはＤＨＣＰ＿ＡへＤＨＣＰ Ｒｅｑｕｅｓｔを転送する（図４（４））。これを受けて、ＤＨＣＰ＿ＡはＩＰアドレス割り当ての期間を延長する（図４（５））。続いて、ＤＨＣＰ＿ＡはＤＨＣＰ＿ＢへＤＨＣＰ Ａｃｋを転送し（図４（６））、ＤＨＣＰ＿ＢはＭＮ１１へＤＨＣＰ Ａｃｋを返す（図４（７））。

図４に示す手順（２）、（３）において、ＤＨＣＰサーバからエッジルータへの問い合わせ処理がある。手順（２）ではまず、ＤＨＣＰ ＲｅｑｕｅｓｔパケットのＲｅｑｕｅｓｔｅｄ ＩＰフィールドを参照し、ＤＨＣＰサーバが管理しているＩＰアドレスに関する要求であるか否かを判断する。もしＤＨＣＰ＿Ｂが管理するＩＰアドレス外であった場合、ＤＨＣＰ ＲｅｑｕｅｓｔのＲｅｑｕｅｓｔｅｄ ＩＰフィールドおよびＭＡＣアドレス情報をエッジルータへ送り、そのＭＮ１１に関するトンネルが存在しているかを確認する（手順（３））。すなわち、どこか別のネットワークから移動してきたＭＮ１１によるＤＨＣＰ Ｒｅｑｕｅｓｔであるか否かを確認する。移動してきたＭＮ１１であった場合、前述のように、ＭＮ１１から送信されたｐｉｎｇによるエッジルータの移動検知、トンネル張替え処理が発生する。本発明では、エッジルータ間でやり取りされる情報、すなわちＭＮ１１のトンネルに関する情報に対して、ＭＮ１１のＩＰアドレス、ＭＮ１１のＭＡＣアドレス、ＤＨＣＰサーバＩＰアドレス（ＭＮ１１へＩＰアドレスを割り当てたＤＨＣＰサーバのＩＰアドレス）を新たに加えておく必要がある。

これらの情報は、トンネル管理テーブルに含めてもよいし、別の管理テーブル（ＭＮ１１管理テーブル）として管理してもよい。重要なのは、ＭＮ１１のＩＰアドレスとＭＡＣアドレスによってエントリを検索できることである。また、この情報は元々ＨＲが作成するが、ＤＨＣＰサーバＩＰアドレスは、そのＨＲがあらかじめ知っているものとする。したがって、ＭＮ１１がはじめてＣＮ１２と通信をした際などにＭＮ１１の情報として上記の情報が生成され、その際に当該ＨＲが知っているＤＨＣＰサーバＩＰアドレスを登録する。

図４に示す手順（２）の問い合わせでＭＮ１１の情報を検索した結果、ＣＲがそのＭＮ１１を収容していれば、手順（３）の返答ではＤＨＣＰサーバＩＰアドレス（ここではＤＨＣＰ＿ＡのＩＰアドレス）を返答する。もしＭＮ１１の情報が存在しなければ、「該当なし」を応答する。手順（４）以降ではＤＨＣＰ＿ＢがＤＨＣＰリレーサーバとして動作し、上記で得られたＤＨＣＰ＿ＡへＤＨＣＰシグナリングパケットの転送を行う。なお、転送の方法自体は従来のＤＨＣＰリレーと同じ方式である。また、手順（３）で「該当なし」が返ってきた場合、ＤＨＣＰ＿ＢサーバはそのＭＮ１１に対して新たにＩＰアドレス割り当てを行う。その際にはＤＨＣＰ＿ＢはＤＨＣＰ ＮａｋをＭＮ１１に返答し、図４と同様のシーケンスとなる。なお、手順（２）でＲｅｑｕｅｓｔｅｄ ＩＰがＤＨＣＰ＿Ｂの管理ＩＰアドレス内のものであった場合、エッジルータへの問い合わせは不要で、通常のＤＨＣＰ処理となる。

ここではＤＨＣＰ Ｒｅｑｕｅｓｔに関してのみ説明しているが、ＭＮ１１からＤＨＣＰ Ｄｉｓｃｏｖｅｒが送信される場合もある。ＤＨＣＰ ＤｉｓｃｏｖｅｒにＲｅｑｕｅｓｔｅｄ ＩＰフィールドが含まれる場合とそうでない場合があり、Ｒｅｑｕｅｓｔｅｄ ＩＰフィールドが含まれており、しかもＤＨＣＰ＿Ｂの管理ＩＰアドレス外であった場合には、手順（２）や（３）と同じ処理を行う。ただし、ＤＨＣＰ Ｄｉｓｃｏｖｅｒから開始された場合には、ＤＨＣＰ Ｏｆｆｅｒ受信後にＭＮ１１は再度ＤＨＣＰ ＲｅｑｕｅｓｔをＤＨＣＰ＿Ｂへ送信するが、そのＤＨＣＰ Ｒｅｑｕｅｓｔは手順（２）、（３）のようなＣＲへの問い合わせを省略する。これは、ＤＨＣＰパケットにはトランザクションＩＤと呼ばれるＩＤが含まれており、一連のＤＨＣＰシーケンスは同じＩＤを持っているため、リレーの設定もトランザクション内であればＤＨＣＰサーバが記憶させておくことで可能である。

次に、ＩＰアドレスの解放について説明する。ＭＮ１１は、インタフェースを無効にする、コンピュータの電源を切るなどによってＩＰアドレスが不要になった場合に、割り当てられたＩＰアドレスの解放を行う。すなわち、ＤＨＣＰサーバにＩＰアドレスが不要になったことを通知することで、そのＩＰアドレスを他のノードが使用できるようにする。ＩＰアドレス解放は、ＤＨＣＰ ＲｅｌｅａｓｅをＤＨＣＰサーバに送ることによって行う。ＭＮ１１はＩＰアドレスを割り当てたＤＨＣＰサーバを知っているため、直接ホームネットワークのＤＨＣＰサーバへＤＨＣＰ Ｒｅｌｅａｓｅを送信すればよい。（前述のＤＨＣＰ ＲｅｑｕｅｓｔやＤＨＣＰ Ｄｉｓｃｏｖｅｒは、２５５．２５５．２５５．２５５という宛先にブロードキャストされていたが、ＤＨＣＰ Ｒｅｌｅａｓｅはユニキャストされる。）したがって、前述のようなＤＨＣＰリレーサーバのような動作は不要である。

ＩＰアドレスが不要になるということは、それまで使われていたトンネルも不要になるということと同義であるため、ＩＰアドレス解放と同時に、エッジルータが余分なメモリを消費せずに済むために当該ＭＮ１１に関するトンネルやコネクション情報もすべて解放されることが望ましい。この機能を実現するための動作を、図５を参照して説明する。図５において、ＭＮ１１はＮｅｔ ＡでＩＰアドレスを取得し、Ｎｅｔ Ｂに移動した後、ＩＰアドレスを解放するものとする。

まず、ＭＮ１１がＤＨＣＰ ＲｅｌｅａｓｅをＤＨＣＰ＿Ａに送信する（図５（１））。これを受けて、ＤＨＣＰ＿Ａはアドレスを解放するとともに、ＨＲに対してリリース通知を行う（図５（２））。ＨＲはトンネル情報（Ｈｏｍｅトンネル）を元にＣＲへトンネル削除要求（Ｔｕｎｎｅｌ Ｒｅｖｏｃａｔｉｏｎ Ｒｅｑｕｅｓｔ）を送信する（図５（３））。ＣＲはトンネル削除要求を受信すると、Ｈｏｍｅトンネルを削除するとともにさらに他のＣＮ１２トンネルへもトンネル削除要求し、当該ＭＮ１１に関する全トンネルを削除する（図４（４））。なお、ＭＮ１１がホームネットワークにいる場合にはＨＲとＣＲは同一であるため、ＣＲへのトンネル削除要求送信は存在せず、ＨＲが直接ＣＮ１２トンネルを削除する。

＜高速な移動処理＞
以上の説明においては、エッジルータがＭＮ１１移動に伴ってトンネルの張替えを行い、ＭＮ１１は最初のｐｉｎｇパケット以外何も移動に関する処理を行わなかった。そのため、移動後のエッジルータ（ＣＲ）が移動前のエッジルータへの問い合わせ等を行わなければ、それまで使われていた当該ＭＮ１１に関するＣＮ１２トンネルをそのＣＲへ移行することができず、トンネル張替えに至るまでの期間はパケット転送ができずＭＮ１１がパケットを受信できなくなる可能性がある。例えば、図１６において、ＭＮ１１がルータＤに移動した場合、トンネル切替のためのシグナリングＴＦＲｅｑは一度ＨＲへ送信された後にルータＣへＴＦＣｎｇが送られる。そのため、図１６（３）、図１７（４）においてルータＣのトンネル情報が書き換わるまでは、ルータＡからルータＣへ送られてきたＭＮ１１宛パケットは、ルータＣはまだそのアクセス網内にＭＮ１１が存在することになっているため、ＭＮ１１に届くことなくルータＣのアクセス網内に消えてしまう。ここでは、このようなルータＣ（ＴＲ）におけるパケットロスを軽減することを可能とする方式について説明する。

この方式を簡単に説明すると、図１６において、ＨＲを起点として移動前のエッジルータ（ＴＲ）のトンネルを切り替えていたところを、移動後のエッジルータ（ＣＲ）を起点として、すなわちＣＲからＴＦＲｅｑを出すことによって、タイムラグを小さくするというものである。そのためには、ＣＲがあらかじめどのエッジルータから移動してきたのかという情報を知っていなければならない。これを以下のように実現する。

エッジルータは、ＭＮ１１に関する情報をあらかじめＭＮ１１に通知しておく。ＭＮ１１に関する情報とは、当該ＭＮ１１に関連する「トンネル情報テーブル」「コネクション情報テーブル」「ＭＮ１１情報テーブル」である。ＭＮ１１情報テーブルは、ＭＮ１１のＩＰアドレス、ＭＮ１１のＭＡＣアドレスとＤＨＣＰサーバＩＰアドレスの情報である。これらの情報を総称して、ここではネットワーク情報と呼ぶ。エッジルータはこれらの情報に変化がある毎に、当該ＭＮ１１にそのネットワーク情報を送付し、当該ＭＮ１１はその情報を保持しておく。なお、「これらの情報に変化がある」とは、例えば新たなＣＮ１２と通信を開始すれば、コネクション情報やトンネル情報が新設されることによって発生する変化のことである。

以上の説明においては、ＭＮ１１はインタフェースの状態に変化があったときにデフォルトゲートウェイに対してまずｐｉｎｇを送信すると説明したが、ここでは、このｐｉｎｇの代わりにＭＮ１１がネットワーク情報をブロードキャスト（またはマルチキャスト）する。ＭＮ１１が送出したネットワーク情報はエッジルータが受信し、中身を確認しそれが新たなＭＮ１１によるものであるか否かを判断する。例えば未知のＭＮ１１情報が入っていれば、新ＭＮ１１が移動してきたことがわかる。なお、新規のＭＮ１１のものでなければ、エッジルータは特に何もしない。新たなＭＮ１１が移動してきた場合には、エッジルータ（ＣＲ）は以下のような処理を行う。

まず、移動前のエッジルータ（ＴＲ）へＴＦＣｎｇを送信して、Ｔｒａｎｓｉｅｎｔトンネルを更新する。そして、通信相手のＣＲへＴＦＣｎｇを送信してＣＮトンネルを更新し、ＨＲへＴＦＲｅｑを送信することによりＨｏｍｅトンネルを最後に更新する。ＴＲＲｅｑを受信したＨＲはＴＲへＴＦＣｎｇを送信しなくてよい。

このように、移動後のエッジルータ（ＣＲ）はＭＮ１１移動直後に通信相手となるＣＮ１２のＣＲや当該ＭＮ１１のＴＲを知ることができるため、まず初めにＣＮトンネルやＴＲトンネルを更新することができる。まずＴｒａｎｓｉｅｎｔトンネルから更新する理由は、トンネルの本数がＴｒａｎｓｉｅｎｔトンネルは１本しかなく、すぐに処理が終了するためである。一方ＣＮトンネルはコネクションの数だけ存在するため、時間がかかってしまう可能性があり、その分パケットロスの発生を許してしまう可能性がある。図２０〜図２３に処理動作を示す。なお、ＨＲからのＴＦＡｃｋは記載を省略している。また、ネットワーク情報はＨＲでもＣＲでも、情報に変化があればＭＮ１１宛にユニキャストされるものである。また、暗号化によってＭＮ１１はその内容を知ることができなくなり安全性が高まると考えられるため、送られるネットワーク情報はエッジルータ間だけで共有されている暗号鍵で暗号化されるのが好ましい。

このように、端末が特別な処理を行うことなくネットワーク間を移動してもモビリティを維持することができる。また、移動先においても割り当てられたＩＰアドレスを正しく使い続けることができるとともに、ＩＰアドレスを解放する際にトンネルも削除するため、無駄な資源消費を防止することができる。また、移動に伴うトンネルの確立し直し時において、パケットロスを低減することができる。

本発明の一実施形態におけるネットワーク構成を示す図である。 図１に示すネットワーク構成における基本動作を示す図である。 ＤＨＣＰの動作を示すシーケンス図である。 ＤＨＣＰの動作を示すシーケンス図である。 ネットワーク構成を示す図である。 本発明による移動通信システムの動作を示す説明図である。 本発明による移動通信システムの動作を示す説明図である。 本発明による移動通信システムの動作を示す説明図である。 本発明による移動通信システムの動作を示す説明図である。 本発明による移動通信システムの動作を示す説明図である。 本発明による移動通信システムの動作を示す説明図である。 本発明による移動通信システムの動作を示す説明図である。 本発明による移動通信システムの動作を示す説明図である。 本発明による移動通信システムの動作を示す説明図である。 本発明による移動通信システムの動作を示す説明図である。 本発明による移動通信システムの動作を示す説明図である。 本発明による移動通信システムの動作を示す説明図である。 本発明による移動通信システムの動作を示す説明図である。 本発明による移動通信システムの動作を示す説明図である。 本発明による移動通信システムの動作を示す説明図である。 本発明による移動通信システムの動作を示す説明図である。 本発明による移動通信システムの動作を示す説明図である。 本発明による移動通信システムの動作を示す説明図である。

符号の説明

１１・・・ＭＮ、１２・・・ＣＮ、１３・・・ＣＮ２、２１、２２、２３・・・ＤＨＣＰサーバ、３１〜３７・・・ルータ、４・・・ＤＮＳサーバ

Claims (3)

1. ＩＰネットワーク上においてパケット転送を行う移動通信システムであって、
   パケット送信元である第１の端末を収容する第１のカレントエッジルータと、前記パケットの受信元である第２の端末が取得したＩＰアドレスを収容するホームエッジルータとの間に第１のトンネルを確立する第１のトンネル確立手段と、
   前記第２の端末が送信するパケットの送信元ＩＰアドレスに基づいて、前記第２の端末が移動して第２のカレントエッジルータにより収容されていることが検知された場合に、前記第２のカレントエッジルータと前記ホームエッジルータとの間のトンネルを確立する要求をルータ間で通信することで、前記第２のカレントエッジルータと、前記ホームエッジルータとの間に第２のトンネルを確立する第２のトンネル確立手段と、
   前記第１のトンネルと前記第２のトンネルとが確立しており、前記第１及び第２のトンネルを経由して、前記第１の端末から前記第２の端末へパケットを転送している場合に、各端末が収容されるルータを特定するトンネル情報及び端末間で通信を行っている２つの端末を特定するコネクション情報に基づいて、前記第１のトンネルを、前記第１のカレントエッジルータと、前記第２のカレントエッジルータとの間に確立し直す第３のトンネル確立手段と、
   を備えたことを特徴とする移動通信システム。
2. 前記第３のトンネル確立手段により前記第１のトンネルを確立し直した後に、前記第２の端末が送信するパケットの送信元ＩＰアドレスに基づいて、前記第２の端末が移動してその移動後のカレントエッジルータにより収容されていることが検知された場合に、各端末が収容されるルータを特定するトンネル情報に基づいて、前記第２の端末の移動前のカレントエッジルータと、前記第２の端末の移動後のカレントエッジルータとの間に、第３のトンネルを確立する第４のトンネル確立手段をさらに備えたことを特徴とする請求項１に記載の移動通信システム。
3. ＩＰネットワーク上においてパケット転送を行う移動通信システムにおける移動通信プログラムであって、
   パケット送信元である第１の端末を収容する第１のカレントエッジルータと、前記パケットの受信元である第２の端末が取得したＩＰアドレスを収容するホームエッジルータとの間に第１のトンネルを確立する第１のトンネル確立処理と、
   前記第２の端末が送信するパケットの送信元ＩＰアドレスに基づいて、前記第２の端末が移動して第２のカレントエッジルータにより収容されていることが検知された場合に、前記第２のカレントエッジルータと前記ホームエッジルータとの間のトンネルを確立する要求をルータ間で通信することで、前記第２のカレントエッジルータと、前記ホームエッジルータとの間に第２のトンネルを確立する第２のトンネル確立処理と、
   前記第１のトンネルと前記第２のトンネルとが確立しており、前記第１及び第２のトンネルを経由して、前記第１の端末から前記第２の端末へパケットを転送している場合に、各端末が収容されるルータを特定するトンネル情報及び端末間で通信を行っている２つの端末を特定するコネクション情報に基づいて、前記第１のトンネルを、前記第１のカレントエッジルータと、前記第２のカレントエッジルータとの間に確立し直す第３のトンネル確立処理と、
   をコンピュータに行わせることを特徴とする移動通信プログラム。

Images