(57)【要約】【課題】移動端末は，移動先で新たにルータ広告を受信するまで移動検知および新しいＣｏＡ生成を行う契機がなく，ホームエージェントに対しても位置登録を行えないため，移動に伴うパケットロスが多いという問題があった。【解決手段】本発明は，アクセスルータ装置に近隣アクセスルータ装置のネットワーク情報を自動収集する手段と，ルータ広告内に隣接するアクセスルータ装置の情報を少なくとも１つ以上含めて送信する手段を具備する。また，移動端末は次の移動先となりえるアクセスルータ装置を選択し，ＨＡに対して事前に位置登録を行う手段を要することを最も主要な特徴とする。【選択図】図６
2006080930.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークを介して第一及び第二の端末に接続された、サーバ及び複数のパケット転送装置を備えた通信システムであって、
上記サーバは、
自サーバが管理する端末の移動先でのアドレスとホーム網でのアドレスの対応を記憶したメモリを有し、
上記複数のパケット転送装置のうち少なくとも一のパケット転送装置は、
上記複数のパケット転送装置のうち少なくとも一の他のパケット転送装置が接続するネットワークの情報と、自パケット転送装置が接続するネットワークの情報を上記第一の端末に対して送信する送信部を有し、
上記第一の端末は、
上記一のパケット転送装置が接続するネットワークの情報、および上記他のパケット転送装置が接続するネットワークの情報のそれぞれから生成した２つの気付アドレスを上記サーバまたは上記第二の端末に送信する送信部を有し、
上記２つの気付アドレスを受信した上記サーバまたは上記第二の端末は、
上記受信した２つの気付アドレスに対して複製した同内容のパケットを送信する送信部を有することを特徴とする通信システム。
【請求項２】
上記一のパケット転送装置が上記第一の端末に対して送信するネットワークの情報はルータ広告であることを特徴とする請求項１記載の通信システム。
【請求項３】
上記第一の端末はMobileIPのモバイルノードであり、上記サーバは該第一の端末のホームエージェントであることを特徴とする請求項１記載の通信システム。
【請求項４】
上記第一の端末は、
自端末が移動中であるか否かの情報を上記サーバまたは上記第二の端末に送信する送信部を有し、
上記情報を受信した上記サーバまたは上記第二の端末は、
上記端末が移動中である場合には、上記２つの気付アドレス宛てに複製した同内容のパケットを送信する送信部を有することを特徴とする請求項１記載の通信システム。
【請求項５】
ネットワークを介して端末及び複数のパケット転送装置に接続されたサーバであって、
自サーバが管理する端末の移動先でのアドレスとホーム網でのアドレスの対応を記憶したメモリと、
上記端末から、上記複数のパケット転送装置のうち少なくとも二つのパケット転送装置が接続するネットワークの情報から生成された２つの気付アドレスを受信する受信部と、
上記受信した２つの気付アドレスに対して複製した同内容のパケットを送信する送信部を有するサーバ。
【請求項６】
上記端末はMobileIPのモバイルノードであり、上記サーバは該端末のホームエージェントであることを特徴とする請求項４記載のサーバ。
【請求項７】
ネットワークを介して端末及び他のルータに接続されたルータであって、
自ルータが上記端末から接続可能なルータであることを示すアクセスルータ識別子、自ルータのネットワークプレフィックス、および自ルータの物理的位置情報を、上記他のルータと交換することを特徴とするルータ。
【請求項８】
上記物理的位置情報は経度、緯度および高度であることを特徴とする請求項６記載のルータ。
【請求項９】
上記他のルータから、該他のルータのネットワークプレフィックスおよび物理的位置情報とを受信する受信部と、
上記自ルータのネットワークプレフィックスおよび物理的位置情報と、上記他のルータのネットワークプレフィックスおよび物理的位置情報とを、ルータ広告に含めて上記端末に送信する送信部とを有する請求項６記載のルータ。
【請求項１０】
ネットワークを介して、自端末の移動先でのアドレスとホーム網でのアドレスの対応を保持するサーバと、複数のルータに接続された移動体端末であって、
上記複数のルータのうち少なくとも２つのルータの物理的位置情報およびネットワークプレフィックスを含むルータ広告を受信する受信部と、
自端末の物理的位置情報および移動方向に基づいて選択された上記複数のルータのうちの２つのルータのネットワークプレフィックスから生成された２つの気付アドレスを上記サーバに送信する送信部とを有する移動体端末。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は，移動体通信において，移動端末の移動に伴うパケットロスを防止する方式に関する。特に移動端末がMobile IPプロトコルを用いて移動通信を行う際の移動検知方法とそれを実現するために用いられるアクセスルータのルータ広告配信方法に関する。
【背景技術】
【０００２】
近年移動体通信網のＩＰ（Internet Protocol）化の検討が活発化している。
ＩＥＴＦ(Internet Engineering Task Force)は，Ｍｏｂｉｌｅ ＩＰｖ６仕様の標準化を進めている。Ｍｏｂｉｌｅ ＩＰｖ６の網構成要素は，移動ノード（Mobile Node，以下ＭＮで表す），ホームエージェント（Home Agent，以下ＨＡで表す），通信相手ノード（Correspondent Node，以下ＣＮで表す）とアクセスルータ（Access Router，以下ＡＲで表す）である。
【０００３】
Ｍｏｂｉｌｅ ＩＰｖ６の基本的動作を以下で説明する。ＭＮ１には，移動しても変わることのない一意のＩＰアドレス（ホームアドレス，以下ＨｏＡで表す）が付与される。そのため，ＭＮ上で起動されるアプリケーションは移動しても中断することなく動作が可能である。ＨｏＡと同じネットワークプレフィックスを持つ網をホーム網と呼ぶ。ＭＮがホーム網以外の網（在圏網）に移動すると，在圏網において在圏網の通信プロトコルに従うＩＰアドレスを取得する。このＩＰアドレスを気付アドレス（Care of Address，以下ＣｏＡで表す）と呼ぶ。
【０００４】
ＭＮは，在圏網上に設置されるＡＲから定期的に送信されるルータ広告（Router Advertisement：ＲＡ）を受信する。この際，ＨｏＡと異なるネットワークプレフィックスを検出することで移動を検知し，ＣｏＡを生成する。移動を検知したＭＮは，ホーム網へ送信されるＭＮ宛のパケットの転送を要求する位置登録要求メッセージ（Binding Update：ＢＵ）をＨＡに送信する。位置登録要求メッセージを受信したＨＡはＭＮのホームアドレスと気付アドレスの対応関係（Binding Cache）を作成する。その後，ＨＡは位置登録応答メッセージ（Binding Ack：ＢＡ）をＭＮに送信し，在圏網に移動しているＭＮ宛のパケットを代理受信するためのパケット捕捉メッセージ（Gratuitous Neighbor Advertisement：Ｇ−ＮＡ）をブロードキャストしてＭＮのプロキシとして動作する。ＣＮはＭＮの通信相手ノードである。ＣＮはＭＮのＨｏＡ宛にパケットを送信する。ＨＡは上記ＭＮのＨｏＡ宛パケットを代理受信する。ＨＡはBinding Cacheを検索し，ＭＮのＨｏＡに対応するＣｏＡを取得する。ＨＡは受信したオリジナルパケットに該当ＣｏＡ宛のＩＰヘッダを付加（カプセル化）して送信する。ＭＮはＣｏＡ宛のカプセル化ヘッダを除去（デカプセル化）し，オリジナルパケットであるＣＮがＭＮのＨｏＡ宛に送信したパケットを受信することができる。
【０００５】
しかし，上記の従来技術では，ＭＮは移動先の在圏網に設置されるＡＲからのルータ広告を受信するまで，移動端末は移動の判別ができない。また，それに伴って新しいＣｏＡの生成および位置登録メッセージ交換も完了しないため，この間ＣＮからのパケットを受信不可能であった。
【０００６】
【非特許文献１】D. Johnson他，「Mobility Support in ＩＰv6」IETF 2003年，http://www.ietf.org/internet-drafts/draft-ietf-MobileIP-IPv6-24.txt
【発明の開示】
【発明が解決しようとする課題】
【０００７】
上記従来技術のハンドオーバに対する課題を説明する。図１に示すように
Ｍｏｂｉｌｅ  ＩＰｖ６におけるハンドオーバ完了に必要な時間１０は，無線リンクセットアップ１１とＲＡを受信してＣｏＡを生成するまでの時間１２と位置登録が完了するまでの時間１３に大別できる。ハンドオーバを効率化するためには，ＣｏＡ生成１２時間と位置登録完了時間１３を短縮することが有効である。
【０００８】
しかし，従来技術では在圏網に設置されるアクセスルータが送信するルータ広告内には，アクセスルータ自身のネットワーク情報しか含まれていないため，移動端末は移動先で新たにルータ広告を受信するまで移動検知および新しいＣｏＡ生成を行う契機がなく，ホームエージェントに対しても位置登録を行えず，ハンドオーバ時間の短縮が困難となっていた。これに伴って，従来技術では移動端末の移動に伴うパケットロスが多いという問題があった。上記問題を解決するためには，移動端末が現在接続中のアクセスルータから次に接続するアクセスルータのネットワーク情報を取得可能とし，移動前に位置登録を完了する必要がある。
【課題を解決するための手段】
【０００９】
本発明は，アクセスルータに近隣アクセスルータのネットワークプレフィックス等の情報を自動収集する手段と，ルータ広告メッセージ内に隣接するアクセスルータの情報を少なくとも１つ以上含めて送信する手段を具備する。また，移動端末は受信したルータ広告から次の移動先となりえるアクセスルータを選択して事前に位置登録を行う手段を要することを最も主要な特徴とする。
【発明の効果】
【００１０】
本発明の移動端末は移動先のネットワーク情報を移動前に取得することが可能となる。これによって，事前に位置登録を行うことが可能になるため，移動後のパケットロスを防止できるという利点がある。
また，アクセスルータは自動で近隣アクセスルータの情報を収集するため，管理者のアクセスルータ増減設に伴う設定等の管理を簡素化できる利点がある。
【発明を実施するための最良の形態】
【００１１】
本発明の実施の形態について図面を用いて説明する。本発明では２つの実施形態がある。形態の差異は，移動端末のネットワーク接続方法であり，それぞれ図２ａ，図２ｂにネットワーク構成図を示す。
【実施例１】
【００１２】
実施例１のネットワーク構成を示す図２ａにおいて，各装置が接続されるネットワークは全てＩＰネットワークで構成する。ＭＮ１のホーム網５ａには，ＭＮ１宛のパケットの転送処理を行うＨＡ３と，ＭＮ１の通信相手となるＣＮ４を接続する。ＭＮ１が移動先で接続する無線ネットワークである在圏網５ｃ，５ｄ，５ｅ）とホーム網５ａの間には，パケット中継網５ｂがある。ルータ６はホーム網５ａとパケット中継網５ｂの境界に設置し，アクセスルータ（２ａ，２ｂ，２ｃ）は，パケット中継網５ｂとＭＮ１が移動先で接続する在圏網（５ｃ，５ｄ，５ｅ）の境界に設置する。ＭＮ１は，ＡＲ（２ａ，２ｂ，２ｃ）に接続されるアクセスポイント（以降ＡＰと呼ぶ）を経由して在圏網にＩＰ接続する。
【００１３】
実施例２のネットワーク構成を示す図２ｂにおいて，各ネットワークに接続する装置は，実施例１と同様である。実施例２では，ＭＮ１は移動先で接続する在圏網（５ｆ，５ｇ，５ｈ）からＡＲ（２ａ，２ｂ，２ｃ）に接続されるＡＰを経由してＡＲ（２ａ，２ｂ，２ｃ）にＰＰＰ(Point to Point  Protocol)を用いて接続した後，該接続上でＩＰ接続を行う。
【００１４】
以降は，本発明において実施の形態に関わらない部分に関して説明する。
図３ａは，本発明におけるＡＲ２のハードウェア構成を示した図である。ＡＲ２は，少なくとも６つのハードウェアブロックで構成される。以下に各ハードウェアブロックについて説明する。
・ＩＰパケットを送受信する少なくとも２つ以上のＩＰインタフェース（２０６ａ，２０６ｂ）。
・ＩＰインタフェースを集約するスイッチ２０５。
・本発明のソフトウェアや本装置の動作を決定する設定ファイル等の情報を格納するハードディスク２００。
・本発明のソフトウェアを実行に際して一時的に利用する領域であるメモリ２０３。
・本装置の制御を司るＣＰＵ２０１。
・本装置に周辺機器を接続する際に利用する拡張インタフェース２０７。
【００１５】
上記ハードウェアブロックは，全てバス２０４で接続される。また，本発明では拡張インタフェース２０７に，ＡＲ２の物理的な位置情報を収集することを目的に，ＧＰＳ受信機２０８を接続する。ただし，本ＧＰＳ受信機は，ＡＲ２に内蔵する形態でも構わない。また，ＧＰＳ受信機以外の手段で物理的位置情報を収集して良い。
【００１６】
図３ｂは，本発明におけるＡＲ２のソフトウェア構成を示した図である。ＩＰパケットがＡＲ２に着信した場合，受信したＩＰパケットをパケット入出力処理２１９にて抽出する。パケット入出力処理２１９は，ＩＰパケットの宛先アドレスを検証し，自宛てである場合はパケット振り分け処理２１６を行う。そうでない場合は，パケット転送処理２１７を行う。パケット振り分け処理２１６は，ＩＰパケットのデータ部を検証し，次に行う処理を選択して適切な処理を行う。パケット転送処理２１７は，Routingテーブル２１８を参照し，次のＩＰパケット転送先を決定し，パケット入出力処理２１９を経由してＩＰパケットの転送を行う。
【００１７】
レイヤ２接続管理処理２１１は，第２の実施形態で必要な処理であり，主にＰＰＰの終端処理や接続管理を司る。経路情報処理２１２は，ネットワークに接続されるルータ間で図７に例を示すＲＩＰｎｇを代表とするルーティングプロトコルを用いて経路情報を交換する際に利用する。ルータ広告処理２１３は，ＡＲ２から送信する図８に例を示すルータ広告メッセージの配信制御を司る。位置情報管理処理２１４は，ＡＲ２の経度や緯度，高度といった物理的位置情報の収集や管理を司る。本発明では，経路情報処理２１２とルータ広告処理２１３と位置情報管理処理２１４に特徴があり，図１０ａに例を示すルータ情報管理テーブル２１５に各処理で取得した情報を格納する。またＡＲ２は，ルータ情報管理テーブル２１５を参照することでＩＰパケットに格納する情報の操作やＡＲ２が実施する処理内容の決定を行う。
【００１８】
図４ａは，本発明における移動端末であるＭＮ１のハードウェア構成を示した図である。以下に各ハードウェアブロックについて説明する。
・ＩＰパケットを送受信する少なくとも１つ以上のＩＰインタフェース１０６。
・ＩＰパケットを送受信する少なくとも１つ以上の無線インタフェース１０７。
・ＩＰインタフェースを集約するスイッチ1０５。
・本発明のソフトウェアや本装置の動作を決定する設定ファイル等の情報を格納するハードディスク１００。
・本発明のソフトウェアを実行に際して一時的に利用する領域であるメモリ１０３。
・本装置の制御を司るＣＰＵ１０１。
・本装置に周辺機器を接続する際に利用する拡張インタフェース１０８。
【００１９】
上記ハードウェアブロックは，全てバス１０４で接続される。また，本発明では拡張インタフェース１０８に，ＭＮ１の物理的な位置情報を収集することを目的に，ＧＰＳ受信機１０９を接続する。ただし，本ＧＰＳ受信機は，ＭＮ１に内蔵する構成でも構わない。また，ＧＰＳ受信機以外の手段で物理的位置情報を収集して良い。また，ハードディスク１００に格納する情報をメモリ１０３に格納する形態により，ハードディスク１００を具備しない構成でもかまわない。
【００２０】
図４ｂは，本発明におけるＭＮ１のソフトウェア構成を示した図である。ＩＰパケットがＭＮ１に着信した場合，受信したＩＰパケットをパケット入出力処理１２１にて抽出する。パケット入出力処理１２１は，ＩＰパケットの宛先アドレスを検証し，自宛てである場合はパケット振り分け処理１１８を行う。そうでない場合は，パケット転送処理１１９を行う。パケット振り分け処理１１８は，ＩＰパケットのデータ部を検証し，次に行う処理を選択して適切な処理を行う。パケット転送処理１１９は，Routingテーブル１２０を参照し，次のＩＰパケット転送先を決定し，パケット入出力処理１２１を経由してＩＰパケットの転送を行う。Ｌ２接続管理処理１１１は，第２の実施形態においてＡＲ２にＰＰＰ接続を行うために必要となる。位置情報管理処理１１２は，ＭＮ１の経度や緯度，高度といった物理的位置情報の収集や管理を司り，取得した情報を図１０ａに例を示すルータ情報管理テーブル１１６や図１０ｂに例を示す端末情報管理テーブル１１５に格納する。ルータ広告処理１１３は，ＡＲ２から送信される図８に例を示すルータ広告メッセージの受信とＭＮ１の移動検知制御を司り，取得した情報をルータ情報管理テーブル１１６および端末情報管理テーブル１１５に格納する。Ｍｏｂｉｌｅ ＩＰ処理１１４は，図９に例を示すMobile IPv６位置登録要求メッセージを用いた位置登録処理やＩＰカプセル化転送を司り，Mobile IPに関連するＨｏＡやＣｏＡ等の情報を図１１ａに例を示すBinding Update管理テーブルにて管理する。
【００２１】
図５ａは，本発明におけるＨＡ３およびＣＮ４のハードウェア構成を示した図である。ＨＡ３およびＣＮ４は，少なくとも６つのハードウェアブロックで構成される。以下に各ハードウェアブロックについて説明する。
・ＩＰパケットを送受信する少なくとも２つ以上のＩＰインタフェース（３０６ａ，３０６ｂ）。
・ＩＰインタフェースを集約するスイッチ３０５。
・本発明のソフトウェアや本装置の動作を決定する設定ファイル等の情報を格納するハードディスク３００。
・本発明のソフトウェアを実行に際して一時的に利用する領域であるメモリ３０３。
・本装置の制御を司るＣＰＵ３０１。
・本装置に周辺機器を接続する際に利用する拡張インタフェース３０８。
【００２２】
上記ハードウェアブロックは，全てバス３０４で接続される。また，本発明では拡張インタフェース２０８に，ＨＡ３およびＣＮ４の物理的な位置情報を収集することを目的に，ＧＰＳ受信機３０９を接続する。ただし，本ＧＰＳ受信機は，ＨＡ３およびＣＮ４に内蔵する形態でも構わない。また，ＧＰＳ受信機以外の手段で物理的位置情報を収集して良い。
【００２３】
図５ｂは，本発明におけるＨＡ３およびＣＮ４のソフトウェア構成を示した図である。ＩＰパケットがＨＡ３およびＣＮ４に着信した場合，受信したＩＰパケットをパケット入出力処理３１７にて抽出する。パケット入出力処理３１７は，ＩＰパケットの宛先アドレスを検証し，自宛てである場合はパケット振り分け処理３１４を行う。そうでない場合は，パケット転送処理３１５を行う。パケット振り分け処理３１４は，ＩＰパケットのデータ部を検証し，次に行う処理を選択して適切な処理を行う。パケット転送処理３１５は，Routingテーブル３１６を参照し，次のＩＰパケット転送先を決定し，パケット入出力処理３１７を経由してＩＰパケットの転送を行う。Ｍｏｂｉｌｅ ＩＰ処理３１２は，図９に例を示すMobile IPv6位置登録要求メッセージを用いた位置登録の受信処理やＩＰカプセル化転送を司り，Mobile IPに関連するＨｏＡやＣｏＡ等の情報を図１１ｂに例を示すBinding Cache管理テーブルにて管理する。
【００２４】
以下より本発明における移動体通信の動作手順を詳細に説明する。代表例として図２ａにおけるＭＮ１がＡＲ−２（２ｂ）配下の在圏網５ｄからＡＲ−３（２ｃ）配下の在圏網５ｅに移動しながら，ホーム網５ａに設置されるＣＮ４と通信を行う動作手順を図６に示す。
図中ＭＮ１とＡＲ（２ａ，２ｂ，２ｃ）は，自身の経路情報と物理的位置情報を保持する手段を具備する。
【００２５】
ここで図１０ａを例にして経路情報を格納するルータ情報管理テーブル（１１６，２１５）を説明する。ルータ情報管理テーブル（１１６，２１５）は，ネットワークプレフィックス８０１とそのプレフィックス長８０２と，ゲートウェイアドレス８０３を格納する。これらの情報によってＩＰパケットの送信または転送を行う際に，ＩＰパケットに含まれる宛先アドレスに対してどのゲートウェイに送信するかを決定する。また，近隣フラグ８０４は，ネットワークプレフィックス８０１がＡＲ２またはＭＮ1自身が所属するネットワークであるかを判定するフラグである。本フラグが「０」の場合は，ＡＲ２またはＭＮ1自身が所属するネットワークの情報であることを示し，「１」の場合は，ルーティングプロトコルや手動設定で得たネットワークの情報であると判定する。ＡＲフラグ８０５は，ネットワークプレフィックス８０１のネットワークがＭＮ１に対してＡＲとして通知可能であるかを判定するフラグである。
【００２６】
本フラグが「０」の場合は，ネットワークプレフィックス８０１は中継網５ｂもしくはホーム網５ａに所属するネットワーク情報であることを示し，「１」の場合は，ＭＮ１の在圏網（５ｃ，５ｄ，５ｅ）に所属するネットワークの情報であることを示す。経度８０６，緯度８０７，高度８０８は，ネットワークプレフィックス８０１に所属するＡＲ２の物理的な位置情報を示し，ホップ数８０９は，ネットワークプレフィックス８０１がいくつのルータを経由して到達可能であるかを示す数値である。参照フラグ８１０は，ルータ情報管理テーブル（１１６，２１５）を参照して動作の制御を決定する際に，重複して参照することを防止するために利用される。以上８０１から８１０を１つのレコード８００とし複数レコードを格納する。
【００２７】
次に，図１０ｂを例に用いて，物理的位置情報を格納する端末情報管理テーブル１１５を説明する。端末情報管理テーブル１１５は，ＭＮ１のホームアドレス８２１と現在使用中のＣｏＡリスト８２２と在圏網で接続中のＡＲ２のネットワークプレフィックス８２３とＭＮ１が存在する現在の物理的位置情報である経度８２４，緯度８２５，高度８２６を１つのレコード８２０として格納している。なお，ＣｏＡリスト８２２は，ＩＰパケット送信時に使用するＣｏＡの優先度順にリスト構造８２７となっている。
【００２８】
図６に戻り，移動体通信の動作手順の説明を続ける。図中ＭＮ１はまずＡＲ−１（２ａ）に接続する。第２の形態で接続する場合は，無線リンクのセットアップ後，ＰＰＰセッションのセットアップを行う（Ｓ２０）。第１の形態の場合は，直接ＡＲ−１（２ａ）にＩＰ接続を行う。
【００２９】
ＡＲ（２ａ，２ｂ，２ｃ）は，ＲＩＰｎｇを代表とするルーティングプロトコルを用いて，それぞれＡＲ２が保持している経路情報を交換する（Ｓ３０）。本発明では，図７に例を示すＲＩＰｎｇメッセージフォーマットにより経路情報を送信する（Ｆ４）。図７に示すＲＩＰｎｇメッセージフォーマットは，ＩＥＴＦ  ＲＦＣ２０８０「ＲＩＰｎｇ ｆｏｒ ＩＰｖ６」に規定されるフォーマットのルートテーブルエントリ領域５１５内にＡＲ２の物理的位置情報領域５１６を追加する。物理的位置情報領域５１６には，ＩＰｖ６プレフィックス５０２に属するＡＲ２の経度５０６，緯度５０７，高度５０８とＡＲフラグ５１０およびホップ数５１１が含まれる。
【００３０】
ここで，図７と図１２を例に用いてＡＲ２（２ｂ，２ｃ）が行っているＲＩＰｎｇメッセージの送信処理（Ｆ４）に関して説明する。まず図７に示すＲＩＰｎｇメッセージフォーマットの生成を行う（６００）。次に，ルータ情報管理テーブル２１５を参照し，１レコード毎の抽出を行う（６０１）。レコードの抽出ができた場合（６０２），ルートテーブルエントリ領域５１５の追加を行った後（６０３），レコード内のネットワークプレフィックス８０１やＡＲフラグ８０５や経度８０６，緯度８０７等を抽出して（６０４）ルートテーブルエントリ領域５１５の該当領域への書き込みを行う（６０５）。その後，再度ルータ情報管理テーブル２１５から１レコード毎の抽出（６０１）を繰り返すことでＡＲ２（２ｂ，２ｃ）が保持している経路情報がＲＩＰｎｇメッセージフォーマットに展開される。ルータ情報管理テーブル２１５から抽出するレコードが無くなった時点でＲＩＰｎｇメッセージが完成し，ＡＲ２（２ｂ，２ｃ）は，近隣のＡＲ２（２ａ）に対して生成したＲＩＰｎｇメッセージを送信する（６０６）。
【００３１】
次に図６に戻り，ＡＲ２（２ａ）においてＡＲ２（２ｂ，２ｃ）が送信したＲＩＰｎｇメッセージ（Ｓ３０）の受信処理（Ｆ５）に関して図７と図１３を例に用いて説明する。まず図７に示すＲＩＰｎｇメッセージの受信後（６１０），該ルートテーブルエントリ領域５１５の存在確認を行う（６１１）。ルートテーブルエントリ領域５１５が存在する場合，該エントリのＩＰｖ６プレフィックス５０２等の各項目を抽出する（６１３）。次に，ルータ情報管理テーブル２１５を参照し（６１４），抽出した項目に一致するレコードが存在するかを確認する（６１５）。この時，一致するレコードが存在する場合は，ルータ情報管理テーブル２１５の更新を行った後（６１６），次のルートテーブルエントリ領域５１５の存在確認を行う。一致するレコードが存在しない場合は，新規にルータ情報管理テーブル２１５へ追加で書き込みを行い（６１７），同時にパケット転送時に必要な経路情報として，図３ｂに示すパケット転送処理２１７のルーティングテーブル２１８に追加書込みを行う（６１８）。以降，ＲＩＰｎｇメッセージに含まれるルートテーブルエントリ領域５１５を全て抽出することで，近隣のＡＲ２（２ｂ，２ｃ）が保持している経路情報をＡＲ２（２ａ）のルータ情報管理テーブル２１５に展開することができる。
【００３２】
以上のようにＡＲ２（２ａ，２ｂ，２ｃ）は，ルーティングプロトコルを用いて各々が保持する経路情報と物理的位置情報を自動的に収集可能となる。
図６に戻り，移動体通信の動作手順の説明を続ける。通常ＡＲ−１（２ａ）は，ＭＮ１が接続する在圏網（５ｃ，５ｄ，５ｅ）に対して，ＡＲ２自身が在圏網（５ｃ，５ｄ，５ｅ）に接続するネットワークインタフェースからルータ広告を送信する（Ｓ３１）。これによって，在圏網（５ｃ，５ｄ，５ｅ）に移動してきたＭＮ１は，移動検知と在圏網（５ｃ，５ｄ，５ｅ）で有効なＣｏＡの生成が可能となる。本発明では，図８に示すようなルータ広告をＡＲ２（２ａ）から送信することを特徴とする。図８に示すルータ広告メッセージは，ＩＥＴＦ「Ｍｏｂｉｌｉｔｙ Ｓｕｐｐｏｒｔ  ｉｎ ＩＰｖ６」に規定されるフォーマットのPrefix Information Option領域５３０にＡＲ２の物理的位置情報領域５４０を追加する。
【００３３】
また，Prefix Information Option領域５３０に含まれるPrefix５３２は，ＡＲ２自身が所属するネットワーク情報であるか，近隣のネットワーク情報であるかを示すＮビット５３１を追加する。物理的位置情報領域５４０には，Prefix５３２に接続しているＡＲ２の物理的位置情報として，経度５４１，緯度５４２と高度５４３を含む。なお，Prefix Information Option領域５３０は，ルータ広告メッセージ内に複数格納することが可能である。しかし，ＩＰパケットの最大長の範囲内にルータ広告メッセージを収容必要があるため，本発明では，Prefix Information Option領域５３０の格納数に制限を設ける。制限値の設定方法は，ＩＰパケットの最大長に達しない限り追加する方法や保守者の静的な設定で制限を設ける方法もある。ＭＮ１のハンドオーバの効率化を考慮する場合，少なくともＡＲ２（２ａ）が最も隣接するＡＲ２（２ｂ，２ｃ）とＡＲ２（２ａ）自身のネットワーク情報の３つを送信することが望ましい。
【００３４】
ここで，図１４を用いてＡＲ−１（２ａ）が送信するルータ広告メッセージの送信処理（Ｆ６）に関して説明する。まず図８に示すルータ広告メッセージフォーマットの生成を行う６２０。次に，図１０ａに示すルータ情報管理テーブル２１５を参照し（６２１），近隣フラグ８０４が「０」であるレコードを抽出した後，Prefix Information Option領域５３０の各領域に展開する（６２２）。この時，Ｎビット５３１を「０」に設定し，ＡＲ２（２ａ）自身が所属するネットワーク情報であることを明示する。次に，ルータ情報管理テーブル２１５に格納される隣接ＡＲ２（２ｂ，２ｃ）のネットワーク情報をPrefix Information Option領域５３０に格納する。本処理は，ルータ情報管理テーブル２１５から１レコード毎に抽出し最終レコードまで抽出する（６２３）。さらに，レコードが存在する場合，まず近隣フラグ８０４が「１」かつＡＲフラグ８０５が「１」であるかを確認する（６２６）。
【００３５】
本条件に一致しない場合は，ＭＮ１に対して有効なネットワーク情報でないと判定し，次のレコード抽出に移行する。条件に一致した場合，ルータ情報管理テーブル２１５のレコードから経度８０６，緯度８０７，高度８０８を抽出し，既に格納済みであるPrefix Information Option領域５３０の経度５４１，緯度５４２，高度５４３と比較する（６２７）。この時，何れのPrefix Information Option領域５３０の情報より遠方にある場合は，Prefix Information Option領域５３０の格納数制限を確認し（６２９），限界の場合は次のレコード抽出に移行する。格納可能である場合は，新規にPrefix Information Option領域５３０の追加書き込みを行う。一方，格納済みの位置情報より近隣であると判定した場合（６２８），Prefix Information Option領域５３０の格納数制限を確認し（６３１），格納可能である場合は，新規にPrefix Information Option領域５３０の追加書き込みを行う（６３３）。限界の場合は，最も遠方であるレコードと入れ替えて書き込みを行う（６３２）。以上の動作を繰り返すことでＡＲ２（２ａ）が送信するルータ広告メッセージが最適に作成できる。ルータ情報管理テーブル２１５の全てレコードを確認した後，作成したルータ広告メッセージを送信する（６２４）。
【００３６】
以上の結果，ＡＲ２は，自身が送信するルータ広告内に最も近隣のＡＲが接続する在圏網側のネットワーク情報を選択してＭＮ１に送信することが可能になる。
次に図６に戻り，ＭＮ１においてＡＲ２（２ａ）が送信したルータ広告メッセージ（Ｓ３１）の受信処理（Ｆ７）に関して図１５と図１６を例に用いて説明する。まずＭＮ１は，図８に示すルータ広告を受信する（６４０）。次に受信したルータ広告メッセージ内に，Prefix Information Option領域５３０が存在するかを確認する（６４１）。存在する場合，Prefix Information Option領域５３０に含まれる情報を抽出する（６４２）。次に，ルータ情報管理テーブル１１６を参照し，抽出した情報と比較していく（６４３）。
まず，Prefix Information Option領域５３０内のＮビット５３１が「０」であるかを判定する（６４４）。この時，Ｎビット５３１が「０」である場合，該Prefix Information Option領域５３０に格納されたネットワーク情報は，現在ＭＮ１が移動してきた在圏網５ｄの情報であることが特定できる。Ｎビット５３１が「０」である場合，ルータ情報管理テーブル１１６内で近隣フラグ８０４が「０」であるレコードの検索を行い，該レコードのネットワークプレフィックス８０１とプレフィックス長８０２と，Prefix Information Option領域５３０内から抽出したネットワークプレフィックス５３２とプレフィックス長が一致するかを判定する（６４５）。
【００３７】
一致する場合は，前回受信したルータ広告と変更が無く，ＭＮ１は移動を行っていないと判定できる。この後は，該ルータ情報管理テーブル１１６のレコードの参照フラグ８１０に参照したことを記録するため「１」を格納し（６５１），引き続きPrefix Information Option領域５３０の抽出を行う。ネットワーク情報が一致しない場合は，ＭＮ１が移動して前回と異なる在圏網に移動したことを特定できる。このため，移動検知を行ったことをフラグに格納（６４６）した後，近隣フラグ８０４が「０」であったレコードの近隣フラグ８０４を「１」に変更する（６４７）。次に，ルータ情報管理テーブル１１６内で近隣フラグ８０４が「１」であるレコード内で，Prefix Information Option領域５３０内から抽出したネットワークプレフィックス５３２とプレフィックス長が一致するかの判定を行い（６４９），一致するレコードが存在した場合は，該レコードの近隣フラグ８０４を「０」に変更し（６４８），一致するレコードが存在しない場合は，新規にルータ情報管理テーブル１１６へ追加を行う（６５０）。その後，追加または近隣フラグ８０４を「０」に変更したレコードの参照フラグ８１０に，参照したことを記録するため「１」を格納し（６５１），引き続きPrefix Information Option領域５３０の抽出を行う。
【００３８】
一方，Prefix Information Option領域５３０内のＮビット５３１が「０」であるかを判定した際（６４４）に，Ｎビット５３１が「１」である場合，該Prefix Information Option領域５３０に格納されたネットワーク情報は，次の移動先の候補となる在圏網５ｃまたは在圏網５ｅのネットワーク情報であることが特定できる。この場合，ルータ情報管理テーブル１１６内の近隣フラグ８０４が「１」であるレコード内で，Prefix Information Option領域５３０内から抽出したネットワークプレフィックス５３２とプレフィックス長が一致するかの判定を行い（６４９），一致するレコードが存在した場合は，該レコードの情報を最新の情報に更新し（６４８），一致するレコードが存在しない場合は，新規にルータ情報管理テーブル１１６へ追加を行う（６５０）。その後，追加または更新したレコードの参照フラグ８１０に，参照したことを記録するため「１」を格納し（６５１），引き続きPrefix Information Option領域５３０の抽出を行う。
【００３９】
この後，抽出できるPrefix Information Option領域５３０が存在しないと判定した場合（６４１），前述した，移動検知フラグが立っているかを確認する（６５２）。移動検知をしなかった場合，ルータ情報管理テーブル１１６内の参照フラグ８１０が「０」であるレコードを検索する（６５３）。該当するレコードは，ルータ広告メッセージ内に存在しなかった情報であるため，ルータ情報管理テーブル１１６から削除する（６５４）。また，削除したレコードのネットワークプレフィックス８０１に一致するＣｏＡは，使用する必要がなくなるため，ネットワークインタフェース（１０６，１０７）から削除し，同時に図１０ｂに示す端末情報管理テーブル１１５内の使用ＣｏＡリストからも削除する（６５６）。
【００４０】
移動検知フラグが立っているかを判定した際（６５２），移動検知をしていると判定した場合，図１６に示すＭＮ１の移動検知処理が実行される（６５７）。ＭＮ１の移動検知処理はＣｏＡ生成とホーム網５ａに設置されるＨＡ３および経路最適化実施中のＣＮ４への位置登録である。以下より具体的な処理内容を説明する。まず再度ルータ情報管理テーブル１１６内のレコードを参照する（６６０）。１レコード毎に抽出し（６６２），該レコードのネットワークプレフィックス８０１とプレフィックス長８０２を元にＣｏＡを生成する（６６３）。次に，生成したＣｏＡが，既にＭＮ１のネットワークインタフェース（１０６，１０７）に設定されているかの確認行う（６６４）。未設定である場合は，生成したＣｏＡをネットワークインタフェース（１０６，１０７）に設定する（６６５）。
【００４１】
次に，抽出したレコード内の近隣フラグ８０４が「１」であるかを確認する。近隣フラグ８０４が「０」である場合，該レコードは，現在ＭＮ１が移動してきた在圏網５ｄの情報であることが特定できるため，該レコード情報で生成したＣｏＡは，最優先で使用される。よって，該レコードから抽出または生成した情報は，図１０ｂに示す端末情報管理テーブル１１５の使用ＣｏＡリスト８２２の優先度１番目（８２７ａ）と接続中ＡＲネットワークプレフィックス８２３に展開される（６６７，６６８）。一方，抽出したレコード内の近隣フラグ８０４が「１」である場合，該レコードから生成したＣｏＡは，次の移動先の候補となる在圏網５ｃまたは在圏網５ｅで有効なＩＰアドレスであり，端末情報管理テーブル１１５の使用ＣｏＡリスト８２２には，優先度を判定して格納していく。本処理では，まず端末情報管理テーブル１１５の経度８２４，緯度８２５，高度８２６からＭＮ１の物理的位置情報を抽出し，端末の移動方向を確認する（６６９）。
【００４２】
次に，抽出した物理的位置情報と登録済みのＣｏＡが使用可能なＡＲ２の物理的位置情報を比較し（６７０），ＭＮ１の物理的位置情報に近い順にソートして生成したＣｏＡ格納する（６７１）。
ルータ情報管理テーブル１１６内の全てのレコード抽出からＣｏＡを生成し情報を格納した後，ＭＮ１は，ＨＡ３および経路最適化中のＣＮ４に対して位置登録要求メッセージを送信する（６７３）。本処理では，まずＩＰｖ６パケットフォーマットのＩＰｖ６ヘッダの直後に図９に例を示すMobile IPv6 Binding Updateメッセージを付加したパケットの送信により行われる。本特許では，IETF  「Mobility Support in IPv6」に規定されるMobile IPv6 Binding Updateメッセージフォーマットに対して，Mobility Options領域５６０に次期ＣｏＡに関する情報を格納する領域を新たに追加することに特徴がある。Binding Updateメッセージの生成時，優先度の一番高いＣｏＡ（８２７ａ）を現在使用中ＣｏＡとしてＩＰｖ６ヘッダの送信元アドレスに格納する。宛先アドレスはＨＡ３またはＣＮ４のＩＰアドレスである。
【００４３】
次に，ＩＰｖ６パケットフォーマットの拡張ヘッダ領域は，図９のＩＰｖ６宛先ヘッダ５５０が格納され，本ヘッダ内のホームアドレスオプション領域に図１０ｂに示すＭＮ１のホームアドレス８２１が格納される。IPv6 Mobilityヘッダ領域５５５には，位置登録要求であることを示すＭＨタイプ５５６や通知したＣｏＡの有効期間であるLifetime５５７が格納される。Mobility Options領域５６０には，端末情報管理テーブル１１５のＣｏＡリストから優先度が2番目のＣｏＡ（８２７ｂ）を次期ＣｏＡとして格納する。また，Mobility Options領域５６０内のＳビット５６２は，ＨＡ３またはＣＮ４がＭＮ１宛のＩＰパケットを転送する際，現在のＣｏＡと次期ＣｏＡの両方に対してＩＰカプセル化転送を要求するために使用する。ＭＮ１は，自身が移動中であるか否かの判定を行い（６７２），移動中であると判断した場合は，Ｓビット５６２に「１」をセットする。また，在圏網に留まって通信を行っている際には，Ｓビット５６２に「０」をセットすることで，ＨＡ３またはＣＮ４から送信する複製ＩＰパケットを抑制することが可能となる。
【００４４】
以上のようにＭＮ１は，図１１ａに例を示すBinding Update管理テーブル１１７を参照し（６７３），Binding Updateの送信先となるＨＡ３または経路最適化実施中のＣＮ４に対して位置登録要求メッセージの生成および送信を行った後（６７４）， Binding Update管理テーブル１１７に位置登録の状況を格納する（６７５）。Binding Update管理テーブル１１７には，位置登録の送信先ＩＰアドレス８３１と位置登録要求メッセージに格納したＭＮ１のホームアドレス８３２，現在ＣｏＡ８３３，次期ＣｏＡ８３５やＣｏＡの有効期間８３５やＳビットを含む制御フラグ８３６等が格納される。
【００４５】
Binding Update管理テーブル１１７の更新後，ルータ情報管理テーブル１１６内の参照フラグ８１０が「０」であるレコードを検索する（６７６）。該当するレコードは，ルータ広告メッセージ内に存在しなかった情報であるため，ルータ情報管理テーブル１１６から削除する（６７７）。また，削除したレコードのネットワークプレフィックス８０１に一致するＣｏＡは，使用する必要がなくなるため，ネットワークインタフェース（１０６，１０７）から削除し，同時に図１０ｂに示す端末情報管理テーブル１１５内の使用ＣｏＡリストからも削除する（６７８）。
【００４６】
以上の結果，ＭＮ１はＡＲ２から送信されるルータ広告（Ｓ３１）の受信を契機に移動検知を行うと共に，次期に移動する在圏網で使用するＣｏＡを生成し，ＨＡ３およびＣＮ４に対して双方のＣｏＡを含んだ位置登録要求メッセージを送信（Ｓ３２）するが可能となる。これによってＭＮ１は，移動を繰り返しおこなってもパケットロスをすることなく通信を継続できる。
【００４７】
次に図６に戻り，ＨＡ３および経路最適化を行うＣＮ４においてＭＮ１が送信した位置登録要求メッセージの受信処理（Ｆ８）に関して図１７を例に用いて説明する。ＨＡ３またはＣＮ４は，図９に示す位置登録要求メッセージを受信する（６８０）。受信後，ＩＰｖ６ヘッダ領域の送信元アドレスからＭＮ１の現在使用中ＣｏＡを抽出する（６８１）。次に，図９に示すＩＰｖ６宛先ヘッダ領域５５０からＭＮ１のＨｏＡを抽出する（６８２）。その他Liftime５５７等の情報を抽出した後（６８３），Mobility Options領域５６０に次期ＣｏＡオプションが存在するかを確認する（６８４）。存在する場合は，次期ＣｏＡ５６３や制御フラグであるＳビット５６２を抽出する（６８５）。次に抽出した情報を図１１ｂに示すBinding Cache管理テーブル３１３に格納していく（６８６）。本発明では，Binding Cache管理テーブル３１３にＭＮ１の次期ＣｏＡを登録可能であることに特徴がある。格納する際，まず抽出したＨｏＡに一致するレコードがBinding Cache管理テーブル３１３に存在するかを確認する（６８７）。存在する場合は，該レコードの現在ＣｏＡ８４２や次期ＣｏＡ８４３やLifetime８４４等の更新を行う（６８８）。一致するレコードが存在しない場合は，新規にBinding Cache管理テーブル３１３に登録し（６８９），ＭＮ１に対して位置登録応答メッセージを送信する（Ｓ３３）。
【００４８】
位置登録要求を受諾したＨＡ３はＭＮ１宛のパケットを代理受信し，ＭＮ１に転送を行うため，ホーム網５ａに対して，ＭＮ１のＨｏＡアドレス宛のＭＡＣアドレスをＨＡ３のＭＡＣアドレスに偽装する不要ＮＡメッセージを送信する（Ｓ３４）。以降，ＭＮ１宛のＩＰパケットは，ＨＡ３で代理受信することが可能となる（Ｓ３５）。以下よりＨＡ３が行うＭＮ１へのＩＰパケット転送処理に関して図１８を例に示し説明する（Ｆ９）。ＨＡ３は，ＣＮ４がＭＮ１のＨｏＡ宛に送信したＩＰパケットを代理受信する（７００）。次に受信したＩＰパケットの送信先アドレスであるＨｏＡを抽出し（７０１），図１１ｂに示すBinding Cache管理テーブル３１３を参照（７０２）してＨｏＡに一致するＨｏＡが存在するかを確認する（７０３）。存在しない場合は，ＨＡ４では，受信したＩＰパケットを破棄して終了する（７０４）。一致するＨｏＡが存在した場合，ＨＡ３はＭＮ１にＩＰパケットのカプセル化転送を行う。
【００４９】
本処理は，まずBinding Cache管理テーブル３１３からＭＮ１の現在ＣｏＡ８４２を抽出する（７０５）。ＩＰカプセル化転送のため，新規にＩＰヘッダ領域の送信元アドレスにＨＡ３自身のＩＰアドレスを格納し，宛先アドレス領域４０２に抽出したＭＮ１の現在ＣｏＡを格納して，ＩＰヘッダを生成する。生成したＩＰヘッダに受信したＩＰパケットを付与することでカプセル化パケットが完成する（７０６）。生成したカプセル化パケットをＭＮ１に転送する（７０７）。次にＨＡ３は，Binding Cache管理テーブル３１３からＭＮ１の次期ＣｏＡ８４３が登録されているかを確認する（７０８）。登録されていない場合は，ＭＮ１へのパケット転送処理を終了する。次期ＣｏＡ８４３が登録されていた場合，さらに制御フラグ８４５内のＳビットに「１」がセットされているかを確認する（７０９）。Ｓビットに「１」がセットされている場合，ＭＮ１が次期ＣｏＡに対してもカプセル化転送を要求していることが特定され，カプセル化転送に必要な時期ＣｏＡ８４３を抽出する（７１０）。前述したカプセル化処理と同様にＩＰヘッダを新規に作成し，受信したＩＰパケットを付与してカプセル化パケットを生成する（７１１）。この時，新規に生成したＩＰヘッダ領域内の宛先アドレス領域４０２には，抽出した次期ＣｏＡ８４３が格納される。最後に作成したカプセル化パケットをＭＮ１に転送し（７１２），処理を終了する。
【００５０】
以上のように，ＨＡ３はＭＮ１宛のパケットを受信した場合，ＭＮ１が登録した現在ＣｏＡおよび次期ＣｏＡにカプセル化転送を行う（Ｓ３６，Ｓ３７）。これによりＭＮ１は，移動先の在圏網５ｅに移動した直後からＩＰパケットを受信可能となる。
次に，ＭＮ１がＨＡ３からのカプセル化パケット（Ｓ３６，Ｓ３７）を受信した場合，通常，ＭＮ１はＣＮ４に現在使用中のＣｏＡの通知を行い，以降ＭＮ１とＣＮ４間で通信を行う際には，ＨＡ３経由でなく，直接通信が可能となる経路最適化処理を実施する。本特許において，ＭＮ１はＨＡ３に送信する位置登録メッセージと同様にＣＮ４に送信する位置登録メッセージ内に次期ＣｏＡを含むことを特徴とする。この経路最適化処理に関して図１９を用いて説明する。ＭＮ１は，受信したカプセル化パケットのデカプセル化を行う（７２０）。
【００５１】
次にBinding Update管理テーブル１１７の参照を行い（７２１），オリジナルパケットの送信元アドレスに一致するレコードが存在するかを確認する（７２２）。存在する場合，既にＣＮ４に対して経路最適化処理が行われていることと判断し本処理を終了する。一致するレコードが存在しない場合，ＭＮ１はＣＮ４に現在使用中のＣｏＡを通知するため，経路最適化処理を実施する。まず，位置登録メッセージ送信前にIETF「Mobility Support in IPv6」に規定されるReturn Routability通信を実施する（７２３，Ｓ４３）。Return Routability完了後，ＭＮ１はＨＡ３への位置登録メッセージ送信処理と同様に，端末情報管理テーブル１１５を参照し（７２４），現在ＣｏＡと次期ＣｏＡを抽出し（７２５），移動判定を行い（７２６），位置登録メッセージ生成に必要な情報を抽出する。位置登録メッセージ生成後，ＣＮ４に対して送信し（７２７，Ｓ４４），Binding Update管理テーブル１１７を更新後（７２８），経路最適化処理を終了する。
【００５２】
ＣＮ４は，ＨＡ３と同様にＭＮ１からの位置登録メッセージの受信処理を行う（Ｆ８）。経路最適化処理以降，ＣＮ４はＭＮ１へのパケット送信を行う際，ＭＮ１の現在ＣｏＡと時期ＣｏＡに対して直接パケット送信を行う（Ｓ４６）。ＣＮ４がＭＮ１宛にＩＰパケットを送信する際の処理（Ｆ１１）に関して，図２０を例に説明する。ＣＮ４が送信するＩＰパケットは，まず図５ｂに示すアプリケーション３１１で生成される。アプリケーション１１１が生成したオリジナルパケットのＩＰヘッダの送信先アドレスには，ＭＮ１のＨｏＡが格納され，送信元アドレスにはＣＮ４のＩＰアドレスが格納される。本パケットはMobile IP処理３１２へ転送しＩＰパケットの変換処理を行う。Mobile IP処理３１２は，送信ＩＰパケットの宛先アドレスを抽出する（７３０）。
【００５３】
次に，図１１ｂに示すBinding Cache管理テーブル３１３を参照（７３１）して宛先アドレスに一致するＭＮ１のＨｏＡが存在するかを確認する（７３２）。存在しない場合は，送信ＩＰパケットをそのまま送信する。その後，本パケットは，ＨＡ経由でＭＮ１に転送される（７３３）。一致するＨｏＡが存在した場合，ＭＮ１とＣＮ４間で経路最適化が実施されていると判断し，Binding Cache管理テーブル３１３からＭＮ１の現在ＣｏＡ８４２を抽出する（７３４）。抽出した現在ＣｏＡはＩＰヘッダに格納されている送信先アドレス（＝ＨｏＡ）に書き換えを行い，元の送信先アドレスであるＨｏＡは，経路制御拡張ヘッダに格納する（７３５）。このように，ＣＮ４では，自身が送信するＩＰパケット変換を行って新たに送信ＩＰパケットを生成し，ＭＮ１に送信する（７３６）。
【００５４】
次にＣＮ４は，Binding Cache管理テーブル３１３からＭＮ１の次期ＣｏＡ８４３が登録されているかを確認する（７３７）。登録されていない場合は，ＭＮ１へのパケット転送処理を終了する。次期ＣｏＡ８４３が登録されていた場合，さらに制御フラグ８４５内のＳビットに「１」がセットされているかを確認する（７３８）。Ｓビットに「１」がセットされている場合，ＭＮ１が次期ＣｏＡに対してもＩＰパケット送信を要求していることが特定され，ＩＰパケットに必要な時期ＣｏＡ８４３を抽出する（７３９）。前述したＩＰパケット変換処理と同様にＩＰパケットを変換後（７４０）。ＩＰパケットをＭＮ１に転送し（７４１），処理を終了する。
以上の結果，ＭＮ１とＣＮ４間の経路最適化通信においてもＭＮ１の移動に伴うパケットロス軽減することが可能となる。
【００５５】
次に図６に戻り，ＭＮ１はＡＲ−１（２ａ）からＡＲ−２（２ｂ）配下に移動した際，ＡＲ−２（２ｂ）が送信するルータ広告を受信する（Ｓ３８）。ＭＮ１は，上述した移動検知処理や位置登録要求を行う（Ｓ３９，Ｆ７）。ＨＡ３も上述した位置登録受信処理（Ｆ８）を行った後，ＭＮ１へのパケット転送に備える（Ｓ４０）。
【００５６】
次に，ＭＮ１が在圏網からＣＮ４宛にＩＰパケットを送信する際の処理（Ｆ１２）に関して，図２１を例に説明する。ＭＮ１が送信するＩＰパケットは，まず図４ｂに示すアプリケーション１１０で生成される。本パケットはMobile IP処理１１４に転送されＩＰカプセル化を行う。Mobile IP処理１１４は，アプリケーション１１０が生成したオリジナルパケットを入力する（７５０）。このオリジナルパケットのＩＰヘッダの送信元アドレスには，ＭＮ１のＨｏＡが格納され，送信先アドレスにはＣＮ４のＩＰアドレスが格納される。次に，上記オリジナルパケットの送信先アドレスを抽出する（７５１）。図１１ａに示すBinding Update管理テーブル１１７を参照し（７５２），抽出した送信先アドレスに一致するＢＵ送信先アドレス８３１が存在するかを確認する（７５３）。存在しない場合は，送信元アドレスに一致するＨｏＡ８３２が存在するかを確認し（７５４），存在しない場合は，オリジナルパケットの破棄を行い（７５５），パケット送信処理を終了する。送信元アドレスに一致するＨｏＡ８３２が存在する場合は，ＨＡ４経由での送信と判定する。送信先アドレスに一致するＢＵ送信先アドレス８３１が存在する場合，ＣＮ４と経路最適化が実施されていることを判定し，ＣＮ４への送信フラグを立てる（７５６）。
【００５７】
次に，現在ＣｏＡ８３３と次期ＣｏＡ８３４を抽出し，（７５７）。その内，図１０ｂに示す端末情報管理テーブル１２４の使用ＣｏＡリストを参照して（７５８），優先度の高いＣｏＡを選択する（７５９）。次にＭＮ１は，オリジナルパケットへの変換処理を実施するため，ＣＮ４への送信フラグが立っているかを確認する（７６０）。ここで，フラグが立っていない場合は，ＨＡ３経由での送信処理となるため，前述したカプセル化処理と同様にＩＰヘッダを新規に作成し，オリジナルＩＰパケットに付与してカプセル化パケットを生成する（７６１）。この時，新規に生成したＩＰヘッダの送信元アドレスには選択したＣｏＡが格納され，宛先アドレスにはＨＡ３のＩＰアドレスが格納される。最後に生成したカプセル化パケットを送信する（７６３）。一方，ＣＮ４への送信フラグが立っている場合は，ＣＮ４への経路最適化送信のため，ＩＰヘッダの変換処理と宛先拡張ヘッダの付与を行う（７６２）。本処理は選択したＣｏＡをＩＰヘッダに格納されている送信元アドレス（＝ＨｏＡ）に書き換え，元の送信元アドレスであるＨｏＡは，宛先拡張ヘッダに格納する。その後，変換されたＩＰパケットを直接ＣＮ４へ送信し（７６３）終了する。
【産業上の利用可能性】
【００５８】
以上の実施の形態から明らかなように，移動端末は，移動直後からパケットの受信が可能となるため，パケット転送遅延やパケットロスの影響を受けやすいリアルタイム通信を円滑に行う用途にも適用できる。また，移動端末が接続しているネットワークの近隣にアクセスルータが存在するかを確認可能となるため，移動端末の利用者は常に通信可能な移動先を選択して移動計画を立てる用途にも適用できる。さらに移動体通信ネットワークの提供者は，アクセスルータの設置状況を容易に把握可能となるため，移動体通信網の構成検討を行う用途にも適用できる。
【図面の簡単な説明】
【００５９】
【図１】従来技術であるIETF標準のMobileIPv6のハンドオーバ実施時間の内訳を示した説明図である。
【図２−Ａ】本発明を適用するネットワーク構成を示した説明図である。（実施例１）
【図２−Ｂ】本発明を適用するネットワーク構成を示した説明図である。（実施例２）
【図３−Ａ】アクセスルータ装置のソフトウェア構成を示した説明図である。
【図３−Ｂ】アクセスルータ装置のソフトウェア構成を示した説明図である。
【図４−Ａ】移動端末装置のハード構成を示した説明図である。
【図４−Ｂ】移動端末装置のソフトウェア構成を示した説明図である。
【図５−Ａ】ホームエージェントおよび通信相手端末のハード構成を示した説明図である。
【図５−Ｂ】ホームエージェントおよび通信相手端末のソフトウェア構成を示した説明図である。
【図６】本発明のハンドオーバ方式のシーケンスを示した説明図である。
【図７】ＲＩＰｎｇメッセージフォーマットを示した説明図である。
【図８】ＩＰv6ルータ広告メッセージフォーマットを示した説明図である。
【図９】MobileIPv6位置登録要求メッセージフォーマットを示した説明図である。
【図１０−Ａ】ルータ情報管理テーブルの構成を示した説明図である。
【図１０−Ｂ】端末情報管理テーブルの構成を示した説明図である。
【図１１−Ａ】Binding Update管理テーブルの構成を示した説明図である。
【図１１−Ｂ】Binding Cache管理テーブルの構成を示した説明図である。
【図１２】アクセスルータ装置におけるＲＩＰｎｇメッセージ送信時の処理フローを示した説明図である。
【図１３】アクセスルータ装置におけるＲＩＰｎｇメッセージ受信時の処理フローを示した説明図である。
【図１４】アクセスルータ装置におけるルータ広告送信時の処理フローを示した説明図である。
【図１５】移動端末におけるルータ広告受信時の処理フローを示した説明図である。
【図１６】移動端末におけるルータ広告受信後の移動検知処理フローを示した説明図である。
【図１７】ホームエージェントおよび通信相手端末におけるBinding Updateメッセージ受信時の処理フローを示した説明図である。
【図１８】ホームエージェントにおけるパケット転送時の処理フローを示した説明図である。
【図１９】移動端末におけるカプセル化パケット受信の処理フローを示した説明図である。
【図２０】通信相手端末における経路最適化後のパケット送信時処理フローを示した説明図である。
【図２１】移動端末におけるパケット送信時の処理フローを示した説明図である。
【符号の説明】
【００６０】
１  移動端末(Mobile  Node：ＭＮ) ，
２  アクセスルータ（Access Router：ＡＲ）
３  ホームエージェント（Home Agent：ＨＡ）
４  通信相手端末（Coresponding Node：ＣＮ）
５  ネットワーク。
【図１】
2006080930.tif 000003
【図２−Ａ】
2006080930.tif 000004
【図２−Ｂ】
2006080930.tif 000005
【図３−Ａ】
2006080930.tif 000006
【図３−Ｂ】
2006080930.tif 000007
【図４−Ａ】
2006080930.tif 000008
【図４−Ｂ】
2006080930.tif 000009
【図５−Ａ】
2006080930.tif 000010
【図５−Ｂ】
2006080930.tif 000011
【図６】
2006080930.tif 000012
【図７】
2006080930.tif 000013
【図８】
2006080930.tif 000014
【図９】
2006080930.tif 000015
【図１０−Ａ】
2006080930.tif 000016
【図１０−Ｂ】
2006080930.tif 000017
【図１１−Ａ】
2006080930.tif 000018
【図１１−Ｂ】
2006080930.tif 000019
【図１２】
2006080930.tif 000020
【図１３】
2006080930.tif 000021
【図１４】
2006080930.tif 000022
【図１５】
2006080930.tif 000023
【図１６】
2006080930.tif 000024
【図１７】
2006080930.tif 000025
【図１８】
2006080930.tif 000026
【図１９】
2006080930.tif 000027
【図２０】
2006080930.tif 000028
【図２１】
2006080930.tif 000029