(57)【要約】  ＰＭＩＰドメインを移動する移動端末が、様々なタイプのプレフィックスを受信して、構成するアドレスのタイプを選択し、ＰＭＩＰドメインに対してシグナリングの負荷をかけずに経路最適化が行われるようにする技術が開示される。その技術ではＭＮ３１０は、ホームドメインに接続する際に複数のプレフィックスを要求する。ＭＡＧ３２０は、ＡＡＡサーバ３４０にＭＮを認証させ、ＡＡＡサーバから複数のプレフィックスの通知指示を受信すると、例えばＲＡメッセージ３６４によって複数のプレフィックスを通知する。ＭＮは、通知された複数のプレフィックスから複数のアドレス（例えば、ＰＭＩＰドメインプレフィックスを含むＰＭＩＰアドレスや、オンリンクプレフィックスを含むグローバルアドレス）を構成して、ＭＡＧに通知する。ＭＡＧは、ＬＭＡ３３０に対して、これら複数のアドレスに係る複数のバインディングの登録を行う。
2009044539.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークベースのローカルモビリティ管理プロトコルが実装されているネットワークドメインを構成し、前記ネットワークドメインに接続されている移動端末の位置情報を管理する機能を有する位置管理ノードと、前記移動端末の位置情報の登録を代理して行う機能を有する代理登録ノードと、前記移動端末の認証を行う認証サーバとを有する通信システムにおける通信制御方法であって、
前記ネットワークドメインをホームドメインとする移動端末が、複数のプレフィックスを取得するプレフィックス取得ステップと、
前記移動端末が、前記複数のプレフィックスから複数のアドレスを取得するアドレス取得ステップと、
前記移動端末が、前記複数のアドレスを前記ネットワークドメインに通知するアドレス通知ステップと、
前記代理登録ノードが、前記移動端末から通知された前記複数のアドレスのそれぞれに係るバインディング情報を前記位置管理ノードに登録するバインディング登録ステップとを、
有する通信制御方法。
【請求項２】
前記移動端末が、前記ネットワークドメインに接続する際に複数のプレフィックスを要求するステップと、
前記代理登録ノードが、前記複数のプレフィックスの要求に基づいて、前記複数のプレフィックスが前記移動端末に通知されるよう処理するステップとを、
有する請求項１に記載の通信制御方法。
【請求項３】
前記プレフィックス取得ステップが、
前記移動端末が、前記ネットワークドメインに接続する際に、前記移動端末に前記ネットワークドメインへの接続を提供するアクセスルータに対して前記複数のプレフィックスを要求するステップと、
前記アクセスルータが、前記代理登録ノードに前記複数のプレフィックスの要求を渡し、前記代理登録ノードが、前記認証サーバに前記移動端末の認証を依頼するステップと、
前記認証サーバが、前記移動端末による前記ネットワークドメインへの接続資格を確認した後にドメインプレフィックスを前記移動端末に割り当て、前記ドメインプレフィックスを前記代理登録ノードに通知するとともに、前記複数のプレフィックスを前記移動端末に通知するよう前記代理登録ノードに指示するステップと、
前記代理登録ノードが、前記ドメインプレフィックスを前記アクセスルータを通じて前記移動端末に通知するとともに、前記認証サーバからの前記複数のプレフィックスの通知指示に基づいて前記アクセスルータにグローバルプレフィックスの通知を行わせるステップとを有し、
前記アドレス通知ステップが、前記移動端末が前記ドメインプレフィックスを含むホームアドレスと、前記グローバルプレフィックスを含むグローバルアドレスとを取得するステップを有し、
前記アドレス通知ステップが、前記移動端末が前記ホームアドレス及び前記グローバルアドレスを前記アクセスルータに通知し、前記アクセスルータが前記ホームアドレス及び前記グローバルアドレスを前記代理登録ノードに渡すステップを有し、
前記バインディング登録ステップが、前記代理登録ノードが前記ホームアドレス又は前記ドメインプレフィックスと前記代理登録ノード自身のアドレス又はプレフィックスとを関連付ける第１のバインディング情報、及び、前記ホームアドレスと前記グローバルアドレスとを関連付ける第２のバインディング情報を前記位置管理ノードに登録するステップを有する請求項１に記載の通信制御方法。
【請求項４】
前記移動端末が接続されるアクセスルータが前記代理登録ノードとしての機能を有さない場合、前記アクセスルータは、前記移動端末と前記代理登録ノードとの間において伝送される情報を中継するとともに、前記アクセスルータ独自のオンリンクプレフィックスを通知する請求項１に記載の通信制御方法。
【請求項５】
前記移動端末が複数の通信インタフェースを有しており、前記複数の通信インタフェースのうちの少なくとも１つが外部ネットワークドメインに接続されている場合に、前記アドレス通知ステップにおいて、前記移動端末が、前記外部ネットワークドメインが接続されている通信インタフェースに対応して設定されるアドレスを、前記ホームドメインに接続されている通信インタフェースから前記ホームドメインに通知するステップを有する請求項１に記載の通信制御方法。
【請求項６】
前記バインディング登録ステップにおいて、前記代理登録ノードが、前記外部ネットワークドメインが接続されている通信インタフェースに対応して設定される前記移動端末のアドレスに係るバインディング情報を前記位置管理ノードに登録するステップを有する請求項５に記載の通信制御方法。
【請求項７】
前記アドレス通知ステップにおいて、前記移動端末が、前記ホームドメインに接続されている通信インタフェースから前記ホームドメインに前記アドレスを通知する際に、前記アドレスをすぐに前記位置管理ノードに登録するよう要求するステップを有する請求項５に記載の通信制御方法。
【請求項８】
前記アドレス通知ステップにおいて、前記移動端末が、前記ホームドメインに接続されている通信インタフェースの存在を確認するステップを有する請求項５に記載の通信制御方法。
【請求項９】
前記アドレス通知ステップにおいて、前記移動端末が、前記ホームドメインに接続されている通信インタフェースから前記ホームドメインに前記アドレスを通知する際に、前記アドレスの通知時刻を表す時間情報を、前記アドレスに係るバインディング情報に付加して前記位置管理ノードに通知するよう要求するステップを有する請求項５に記載の通信制御方法。
【請求項１０】
ネットワークベースのローカルモビリティ管理プロトコルが実装されているネットワークドメインを構成し、前記ネットワークドメインに接続されている移動端末の位置情報を管理する機能を有する位置管理ノードと、前記移動端末の位置情報の登録を代理して行う機能を有する代理登録ノードと、前記移動端末の認証を行う認証サーバとを有する通信システムにおいて、代理登録ノードとして機能するネットワークノードであって、
複数のプレフィックスに基づいて前記ネットワークドメインをホームドメインとする前記移動端末によって構成された複数のアドレスを前記移動端末から受信する手段と、
前記移動端末から通知された前記複数のアドレスのそれぞれに係るバインディング情報を前記位置管理ノードに登録する手段とを、
有するネットワークノード。
【請求項１１】
前記移動端末からの前記複数のプレフィックスの要求を受ける手段と、
前記移動端末からの前記複数のプレフィックスの要求に基づいて、前記複数のプレフィックスが前記移動端末に通知されるよう処理する手段とを、
有する請求項１０に記載のネットワークノード。
【請求項１２】
前記移動端末からの前記複数のプレフィックスの要求を受けた場合、前記認証サーバに前記移動端末の認証を依頼し、前記認証に成功した場合には、前記認証サーバから前記移動端末に割り当てられたドメインプレフィックスを受信するとともに、前記複数のプレフィックスを前記移動端末に通知する指示を前記認証サーバから受ける手段を有する請求項１１に記載のネットワークノード。
【請求項１３】
前記移動端末に通知される前記複数のプレフィックスとして、前記ドメインプレフィックス、前記移動端末の接続ポイントのオンリンクプレフィックス、前記登録代理ノードのアドレス又はプレフィックスから選択する手段を有する請求項１０に記載のネットワークノード。
【請求項１４】
前記位置管理ノードに登録する前記移動端末の前記バインディング情報として、前記ホームアドレス又は前記ドメインプレフィックスと前記代理登録ノード自身のアドレス又はプレフィックスとを関連付ける第１のバインディング情報、及び、前記ホームアドレスと前記オンリンクアドレスとを関連付ける第２のバインディング情報を利用する手段を有する請求項１０に記載のネットワークノード。
【請求項１５】
前記移動端末から通知された前記複数のアドレスのそれぞれに係るバインディング情報を前記位置管理ノードに登録する際に、前記移動端末から通知された前記複数のアドレスのそれぞれに係るバインディング情報を含む１つの登録メッセージを生成し、前記位置管理ノードに送信する手段を有する請求項１０に記載のネットワークノード。
【請求項１６】
前記複数のアドレスのそれぞれに係るバインディング情報に対して、前記位置管理ノードにおける使用の優先度を設定する手段を有する請求項１０に記載のネットワークノード。
【請求項１７】
前記移動端末が複数の通信インタフェースを有しており、前記複数の通信インタフェースのうちの少なくとも１つが外部ネットワークドメインに接続されている場合に、前記外部ネットワークドメインが接続されている通信インタフェースに対応して設定されるアドレスの通知を前記移動端末から受ける手段を有する請求項１０に記載のネットワークノード。
【請求項１８】
前記アドレスの通知と共に前記アドレスに係るバインディング情報をすぐに前記位置管理ノードに登録するよう要求する情報を前記移動端末から受信する手段を有する請求項１７に記載のネットワークノード。
【請求項１９】
前記バインディング登録手段は、前記移動端末から通知された前記アドレスに係るバインディング情報に、前記アドレスの通知時刻を表す時間情報を付加して前記位置管理ノードに登録するよう構成されている請求項１７に記載のネットワークノード。
【請求項２０】
前記アドレスの通知時刻を表す時間情報を前記アドレスに係るバインディング情報に付加するよう要求する情報を前記移動端末から受信する手段を有する請求項１９に記載のネットワークノード。
【請求項２１】
ネットワークベースのローカルモビリティ管理プロトコルが実装されているネットワークドメインを構成し、前記ネットワークドメインに接続されている移動端末の位置情報を管理する機能を有する位置管理ノードと、前記移動端末の位置情報の登録を代理して行う機能を有する代理登録ノードと、前記移動端末の認証を行う認証サーバとを有する通信システムに接続可能であり、前記ネットワークドメインをホームドメインとする移動端末であって、
複数のプレフィックスを取得する手段と、
前記複数のプレフィックスから複数のアドレスを取得する手段と、
前記複数のアドレスを通知して、前記ネットワークドメイン内の前記移動管理ノードに前記複数のアドレスのそれぞれに係るバインディング情報を登録させる手段とを、
有する移動端末。
【請求項２２】
前記複数のプレフィックスを取得する手段が、
前記ネットワークドメインに接続する際に、複数のプレフィックスを要求する手段と、
前記複数のプレフィックスの要求に応じて通知される前記複数のプレフィックスを受信する手段とを、
有する請求項２１に記載の移動端末。
【請求項２３】
前記複数のプレフィックスの要求に応じて受信したドメインプレフィックス及びグローバルプレフィックスから、前記ドメインプレフィックスを含むホームアドレスと、前記グローバルプレフィックスを含むグローバルアドレスとを構成する手段を有する請求項２１に記載の移動端末。
【請求項２４】
前記ホームアドレス及び前記グローバルアドレスの両方を通知するためのメッセージを生成し、前記移動端末が接続しているアクセスルータに前記メッセージを送信する手段を有する請求項２１に記載の移動端末。
【請求項２５】
前記移動端末が前記ホームドメインに接続されている状態において、前記レガシのコレスポンデントノードや別のネットワークドメインに存在するコレスポンデントノードとの通信に、前記複数のプレフィックスのうちのドメインプレフィックスによって構成されたホームアドレスを使用することを決定する手段を有する請求項２１に記載の移動端末。
【請求項２６】
前記移動端末が前記ホームドメインに接続されている状態において、同一の前記ホームドメインに接続されているコレスポンデントノードとの通信に、前記複数のプレフィックスのうちのオンリンクプレフィックスによって構成されたオンリンクアドレスを使用することを決定する手段を有する請求項２１に記載の移動端末。
【請求項２７】
前記移動端末が前記ホームドメインに接続されている状態において、同一の前記ホームドメインに接続されているコレスポンデントノードとの通信に、前記複数のプレフィックスのうちの前記登録代理ノードのアドレス又はプレフィックスを使用することを決定する手段を有する請求項２１に記載の移動端末。
【請求項２８】
前記移動端末が前記ホームドメインとは異なる外部ドメインに接続されている状態において、前記外部ドメインとは異なるドメインに存在するコレスポンデントノードとの通信に、前記外部ドメインから通知された外部ドメインプレフィックスにより構成された外部ドメインプレフィックスアドレスを使用することを決定する請求項２１に記載の移動端末。
【請求項２９】
前記移動端末が前記ホームドメインとは異なる外部ドメインに接続されている状態において、前記外部ドメインに存在するコレスポンデントノードとの通信における経路最適化処理に、前記外部ドメインから通知された外部ドメインプレフィックスにより構成された外部ドメインプレフィックスアドレスを使用することを決定する請求項２１に記載の移動端末。
【請求項３０】
複数の通信インタフェースを有しており、
前記複数の通信インタフェースのうちの少なくとも１つが外部ネットワークドメインに接続されている場合に、前記アドレス通知手段が、前記外部ネットワークドメインが接続されている通信インタフェースに対応して設定されるアドレスを、前記ホームドメインに接続されている通信インタフェースから前記ホームドメインに通知するよう構成されている請求項２１に記載の移動端末。
【請求項３１】
前記アドレス通知手段が、前記ホームドメインに接続されている通信インタフェースから前記ホームドメインに前記アドレスを通知する際に、前記アドレスをすぐに前記位置管理ノードに登録する要求を行うよう構成されている請求項３０に記載の移動端末。
【請求項３２】
前記アドレス通知手段が、前記ホームドメインに接続されている通信インタフェースの存在を確認するよう構成されている請求項３０に記載の移動端末。
【請求項３３】
前記アドレス通知手段が、前記ホームドメインに接続されている通信インタフェースから前記ホームドメインに前記アドレスを通知する際に、前記アドレスの通知時刻を表す時間情報を、前記アドレスに係るバインディング情報に付加して前記位置管理ノードに通知する要求を行うよう構成されている請求項３０に記載の移動端末。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、インターネットプロトコル（ＩＰ：Internet Protocol）を利用した通信技術に係る通信制御方法及びネットワークノード並びに移動端末に関し、特に、ネットワークベースのローカルモビリティ管理ドメイン（Network based Local Mobility Management Domain）内で移動端末（以下、モバイルノードと呼ぶこともある）が接続ポイントを変更しながら通信を行うシステムにおける通信制御方法及びネットワークノード並びに移動端末に関する。
【背景技術】
【０００２】
現在、多数のデバイスが、ＩＰｖ６（インターネットプロトコルバージョン６）を利用して、相互に通信を行っている。モバイル機器にモビリティサポートを提供するために、ＩＥＴＦ（Internet Engineering Task Force）では、ＭＩＰｖ６（Mobility Support in IPv6：ＩＰｖ６におけるモビリティサポート）に係る技術が開発されている（下記の非特許文献１参照）。【０００３】
非特許文献１に記載されているモビリティサポートは、ホームエージェント（ＨＡ：Home Agent）として知られるエンティティを、ホームネットワークに導入することによって実践されている。モバイルノード（ＭＮ：Mobile Node）は、バインディングアップデート（ＢＵ：Binding Update）メッセージを使用して、ホームエージェントに気付アドレス（ＣｏＡ：Care-of Address）の登録を行う。このバインディングアップデートにより、ホームエージェントは、モバイルノードのホームアドレス（ＨｏＡ：Home Address）（ホームリンクにおいて取得されるアドレス）と気付アドレスとの間のバインディングを生成することが可能となる。ホームエージェントは、モバイルノードのホームアドレスあてのメッセージを受信（intercept）し、パケットのカプセル化（あるパケットを新たなパケットのペイロードとすることであり、パケットトンネリングとしても知られている）を用いて、そのパケットをモバイルノードの気付アドレスに転送する機能を担っている。【０００４】
さらに、ＭＩＰｖ６では、コレスポンデントノード（ＣＮ：Correspondent Node）と通信する際の経路最適化（ＲＯ：Route Optimization）の方法が規定されている。このＲＯメカニズムによって、ＭＮは自身の気付アドレスをＣＮに登録することが可能となり、ＭＮとＣＮは、ＭＮのホームエージェントを経由せずに、ＭＮの気付アドレスを使用して相互に通信を行うことが可能となる。また、ＣＮは、リターンルータビリティ（ＲＲ：Return Routability）テストによって、ＭＮの気付アドレスの有効性を把握することが可能である。リターンルータビリティテストはＭＮから開始され、このリターンルータビリティテストによって、ＭＮの気付アドレスがＭＮのホームアドレスと関連している（すなわち、気付アドレス及びホームアドレスが同一のＭＮによって用いられている）ことがＣＮに証明される。なお、このＲＯメカニズムはオプションのメカニズムであり、ＣＮにおいてＲＯメカニズムの機能がサポートされている場合にのみ有用である。【０００５】
ＭＩＰｖ６の問題の１つとして、ＭＮがネットワークへの接続ポイントを変更するたびに、ＨＡやＣＮ（いずれも複数存在し得る）に対してアップデートを行う必要があることが挙げられる。この問題によれば、例えばＭＮが高速で移動している場合には、そのＭＮの位置情報の変更に伴うシグナリングが短時間に大量に発生し、ネットワークに与える処理負荷が増加することになる。【０００６】
さらに、ネットワークへの接続ポイントの変更の際にＲＲテスト及びＢＵメッセージの送信が行われるので、ネットワークへの接続ポイントが変更されるたびにＣＮとの間でハンドオフ時間が発生するという問題もある。ハンドオフが完了するまでにかなりの時間がかかることから、ＣＮとの通信におけるフローや接続に関連しているセッションにおいて、ジッタやパケットロスが発生してしまうことになる。ＶｏＩＰ（Voice over IP：ボイスオーバＩＰ）、マルチメディアストリーミング及びビデオストリーミングにとってジッタの発生は不都合であり、重要なテキストデータ情報を伝送するフローにとってパケットロスの発生は不都合である。なお、重要なテキストデータ情報を取り扱うアプリケーションに関してＴＣＰ（Transmission Control Protocol：トランスポート制御プロトコル）が使用された場合であっても、パケットロスによるパケットの再送が行われるため、ＴＣＰのスループットが低下することになる。【０００７】
こうしたＭＩＰｖ６の課題を解決するため、端末ベースのローカルモビリティ管理プロトコル（terminal-based local mobility management protocol）が数多く提案されている。その中で最もよく知られているものの１つとして、ＨＭＩＰｖ６（Hierarchical Mobility Management Protocol version 6）が挙げられる。なお、現在このＨＭＩＰｖ６はＩＥＴＦ標準規格になっている。【０００８】
例えばＨＭＩＰｖ６を始めとする端末ベースのローカルモビリティ管理プロトコルは、ＭＮの移動によって発生するシグナリング負荷（シグナリングによる帯域消費やシグナリング処理量の増加）の低減やハンドオフ遅延の低減を目的としている。しかしながら、こうした端末ベースのローカルモビリティ管理プロトコルでは、ＭＮは、ローカルモビリティ管理ドメイン内における接続ポイントの変更に関してもＭＡＰ（Mobility Anchor Point：モビリティアンカポイント）にＢＵを送信する必要がある。したがって、ＭＮは接続ポイントを変更するたびに、無線アクセスネットワークを通じて何らかのシグナリングを送信する必要があり、こうしたローカルドメインにおける位置情報のアップデートを行うシグナリングを送信するために、ＭＮのバッテリ電力が余分に消費されるという問題がある。【０００９】
一方、ＩＥＴＦにおけるネットワークベースのローカルモビリティ管理（ＮＥＴＬＭＭ：Network-based local mobility management）ワーキンググループにおいて、端末ベースのローカルモビリティ管理プロトコルと同一の目的を実現するためのプロトコルに関する議論が行われている（例えば、下記の非特許文献２を参照）。ネットワークベースのローカルモビリティ管理プロトコルでは、端末ベースのローカルモビリティ管理シグナリングではなく、ネットワークベースのローカルモビリティ管理シグナリングが利用される。【００１０】
ＮＥＴＬＭＭワーキンググループで議論されているネットワークベースのローカルモビリティ管理プロトコルの１つとして、プロキシモバイルＩＰｖ６（ＰＭＩＰｖ６：Proxy Mobile IPv6）が挙げられる。このプロトコルはＮＥＴＬＭＭワーキンググループにおいて最も支持されており、ネットワークベースのローカルモビリティ管理サービスに関する標準プロトコルとして採用される可能性がある。【００１１】
ＰＭＩＰｖ６は、ＭＡＧ（Mobile Access Gateway：モバイルアクセスゲートウェイ）に備わっているプロキシモビリティエージェント（ＰＭＡ：Proxy Mobility Agent）の機能を用いて、ローカルドメインにおけるＭＩＰｖ６ベースのモビリティ管理を実現しようとする技術である。ＰＭＩＰｖ６は、主に、ＣＭＩＰｖ６（Client Mobile IPv6）スタックが実装されていないＩＰｖ６ホストに対して、ネットワークの局所的な場所におけるモビリティをサポートするために構築されたものである。なお、ＣＭＩＰは端末自身がモバイルＩＰの処理を行うものであり、ネットワーク側に存在する任意のプロキシノードが端末のモバイルＩＰの処理を代行するＰＭＩＰとは対極の概念である。【００１２】
ＰＭＩＰｖ６は、ローカルドメインにおける位置管理シグナリングがネットワークによって完全に処理されるので、ＣＭＩＰｖ６スタックが実装されているノードにとっても有用である。グローバルな移動では、ＭＮのアドレスが変わると、ＭＮはＣＭＩＰスタックを利用して、関連する位置アップデートシグナリング（例えば、ＭＩＰｖ６のＢＵシグナリング）をＨＡやＣＮに送信する必要がある。一方、ＭＮは、ＰＭＩＰｖ６ローカルドメイン内で移動を行った場合には、プレフィックスは変更されずに同一のプレフィックスであることを把握し、その結果、位置登録シグナリングを行わない。【００１３】
ＭＮがＰＭＩＰｖ６ドメインで使用するプレフィックスは、ローカルモビリティアンカ（ＬＭＡ：Local Mobility Anchor）によって管理されるネットワークから取得され、すなわち、ＬＭＡがこのプレフィックスの論理的なアンカポイントとなる。ローカルなＰＭＩＰｖ６ドメインでは、ＭＡＧがＭＮの代わりにＬＭＡへの位置登録シグナリングを行い、ＰＭＩＰｖ６ドメインにおけるＭＮのアドレス（ＰＭＩＰｖ６ドメインアドレス）又はＭＮに提供されたプレフィックスと、ＭＡＧ自身のイグレスインタフェースのアドレスとの関連付けが行われる。ＭＡＧは、ＭＮの接続を検出すると、基本的にＭＩＰｖ６のＢＵと同様の適切なプロキシシグナリングをＬＭＡに対して行う。【００１４】
ＭＮのホームエージェントとＬＭＡが同一の装置によって実現されている場合には、このＰＭＩＰｖ６ドメインはＭＮのホームドメインであり、ＭＮはシグナリングを行う必要がないので、本来のＰＭＩＰｖ６サービスを受けることができる。一方、ＭＮが外部（foreign）ＰＭＩＰｖ６ドメインに存在し、ＭＮに対して外部プレフィックスが提供される場合には、ＭＮは外部ＰＭＩＰｖ６ドメイン内で新たに取得したアドレスをＨＡやＣＮにアップデートする必要がある。なお、このプロトコルの動作範囲は特定の管理ドメイン内であるが、その動作範囲が、より大きな規模に渡って広がる可能性がある。例えば、多数のオペレータが協力することで、全世界に広がる規模を有するグローバルなＰＭＩＰｖ６ドメインが形成される可能性もある。【００１５】
ＭＮは、ＰＭＩＰｖ６ドメイン内に移動するとローカルプレフィックスを取得する。通常、ＡＡＡ（Authorization, Authentication and Accounting：認証、認可、課金）サーバにおいてＭＮの認証が行われた後に、ローカルプレフィックスがＭＮに提供される。ＭＮに提供されるローカルプレフィックスは、ＭＮごとに固有のプレフィックスであってもよく、ＬＭＡのアドレスのプレフィックスと同一である共有のプレフィックスであってもよい。ＭＮごとに固有のプレフィックスが提供される場合には、ステートフル又はステートレスのアドレス構成モードによって、アドレス構成が行われる。一方、共有のプレフィックスがＭＮに提供される場合には、ＰＭＩＰｖ６ドメインにおいてＭＮによって重複したアドレスが生成されてしまう問題を回避するため、ステートフルのアドレス構成がより望ましい。【００１６】
ＰＭＩＰｖ６の主要な欠点は、そのサービスがグローバルネットワークの局所的な場所で提供されるので、グローバルな移動（ＰＭＩＰｖ６ドメインを越える移動）を行おうとしているＭＮは、下記の特許文献３に記載されているように、ＰＭＩＰｖ６及びＭＩＰｖ６を同時に使用しなければならない点にある。さらに、ＰＭＩＰｖ６サービスはローカルドメインに制限されているため、異なるＰＭＩＰｖ６ドメイン同士が協力し合っていない場合には、ＩＰｖ６ホストに対して本当の意味でのグローバルモビリティを実現することができないという問題がある。【００１７】
また、ＰＭＩＰｖ６は、移動しているＩＰｖ６ホストの経路最適化に関する問題も有している。ＣＭＩＰノード（すなわち、ＭＩＰに係る動作を実行するＭＮ）は、アドレス変更時には常にＣＮとの間でＲＯを実行することが可能である。一方、ＲＯ機能を有さないＩＰｖ６ホストがＲＯを行うためには、ネットワーク上に存在する別のエンティティの援助を必要とする。下記の非特許文献４には、ＰＭＩＰｖ６ドメインのＩＰｖ６ホストに関して、ＲＯを実現する方法が開示されている。非特許文献４では、ＩＰｖ６ホストとそのＣＮとの間でＰＭＡによってＲＯが行われる。【００１８】
また、３ＧＰＰ（Third Generation Partnership Project：第３世代パートナーシッププロジェクト）では、ＷＬＡＮ（無線ローカルエリアネットワーク）、セルラネットワーク（３Ｇ）、ＷｉＭＡＸタイプの無線ワイドエリアネットワーク（ＷＷＡＮ）などの様々な無線アクセスネットワークとの通信機能を有するグローバルな異種ネットワーク通信装置に関する議論が行われている。特に、異種ネットワーク通信装置におけるシームレスなモビリティの実現や、リアルタイムビデオ、ＶｏＩＰ、重要データなどの高いＱｏＳ（Quality of Service：サービス品質）が求められている複数のアプリケーションサービスのサポートなどを目指した議論が行われている。【００１９】
下記の非特許文献５に開示されているように、ユーザ機器（ＵＥ：User Equipment）が様々なローカル管理ドメイン（様々なタイプのアクセスネットワーク及びコアネットワークによって特徴付けられる）内を効率良く移動できるようにするため、３ＧＰＰは適切なモビリティ管理メカニズムに順応できることが重要である。【００２０】
３ＧＰＰでは、アクセスネットワークは、レガシの３ＧＰＰアクセスネットワーク（ＧＰＲＳ：General Packet Radio System／ＵＭＴＳ：Universal Mobile Telecommunications System）、次世代３ＧＰＰアクセスネットワーク（evolved 3GPP access network）、信頼できる非３ＧＰＰアクセスネットワーク（trusted non-3GPP access network（trusted WiMAX access network））、Ｉ−ＷＬＡＮ（interworking WLAN：ｅ−ＰＤＧ（evolved Packet Data Gateway）と呼ばれる信頼できるゲートウェイ経由でＷＬＡＮからの信頼できないアクセスを可能とする）に分類することができる。【００２１】
非特許文献５には、３ＧＰＰにおいて、複数の異なるタイプのネットワークのローカルモビリティ管理に関して、ＰＭＩＰｖ６の使用が最も適切であると記載されている。その理由として、上述のようなＰＭＩＰｖ６特有の利点に加えて、ＭＩＰｖ６機能が実装されていない３ＧＰＰのレガシＵＥであっても、３ＧＰＰネットワークの局所的な場所においてネットワークベースのローカルモビリティ管理を実現できることが挙げられる。【００２２】
また、下記の特許文献１には、ＭＮに２つのプレフィックスを通知する方法が開示されている。ここでは、ＭＮに通知される一方のプレフィックスはローカルプレフィックスであり、ＡＲから通知されるプレフィックス、又はＡＲのアドレスに関連したプレフィックスである。もう一方のプレフィックスは、ＭＡ（Mobility Agent：モビリティエージェント）のアドレスである。なお、ＭＮがＭＡのアドレスを受信するローカルネットワークセグメントは、ローカルモビリティドメインと呼ばれる。【００２３】
ＭＮは、通知された２つのプレフィックスに基づいて２つの気付アドレスを構成する。ＭＮがＡＲに関連したプレフィックス及びＭＡプレフィックス（ＭＡのアドレスに関連したプレフィックス）から構成したアドレスは、それぞれローカルアドレス及びグローバルアドレスと呼ばれる。ＭＮは、ローカルドメイン内でサブネットワークを変更するたびにローカル気付アドレスを生成し、そのローカルアドレスをＭＮのグローバルアドレスと関連付けてＭＡに通知する。また、ＨＡ又はＣＮには、モビリティエージェントが変わった場合にのみ通知が行われる。ＨＡ又はＣＮに通知されるバインディングは、ＭＮのホームアドレスとＭＮのグローバルアドレスとのバインディングである。【００２４】
また、下記の非特許文献６に開示されているようなＩＥＴＦのＭＯＮＡＭＩ６（Mobile Nodes and Multiple Interfaces in IPv6）ワーキンググループでは、複数のインタフェース（マルチインタフェース）を有するモバイルノードに対して、マルチモードの利点を十分に発揮できるような機能が提供されている。マルチインタフェースノードは、インタフェースで取得した複数の気付アドレス（Care-of address）をホームエージェントに登録することができる。これによって、ホームエージェントは、モバイルノードが複数の経路を経由して到達可能であることを把握できるようになる。それまでのＭＩＰｖ６標準規格によれば、ホームエージェントには１つのプライマリ気付アドレスしか登録できなかったが、この非特許文献６では、複数の気付アドレス（ＭＣｏＡ：Multiple CoA）の登録を行うシグナリングにバインディング識別子（ＢＩＤ；Binding Identifier）オプションと呼ばれる追加オプションを設けることで、１つのホームアドレスに対して複数の気付アドレスを関連付ける旨が開示されている。なお、ここで、１つのホームアドレスに対し複数の気付アドレスを登録することをＭＣｏＡ登録と呼ぶ。【００２５】
また、下記の特許文献２には、階層的（ローカルモビリティ及びグローバルモビリティ）なモビリティ管理環境において、経路最適化及び位置プライバシー（位置の隠蔽）を実現する方法が開示されている。ローカルモビリティアンカの配下のローカルモビリティ管理セグメント内を移動するＭＮは、そのローカル気付アドレスをＬＭＡに登録するか、あるいは、プロキシ方法によってＡＲがＭＮのプロキシとして動作し、ＭＮのローカル気付アドレスをＬＭＡに登録する。このようなローカル登録が行われる場合には、ＬＭＡにはＭＮのＨＡアドレスが通知される。ＬＭＡは、バインディングアップデートによって、ＬＭＡのアドレスをＭＮの気付アドレスとしてＭＮのホームエージェントに通知する。これにより、ＣＮから送られてくるパケットはＨＡによって受信（intercept）され、ＬＭＡにトンネルされる。また、プロキシ登録モードが有効である場合には、ＬＭＡは、ＭＮ又はＡＲにパケットをトンネルする。【００２６】
また、特許文献２においては経路最適化の問題が取り扱われている。ここでは、ＣＮ側のゲートウェイ（ＣＮと接続しているゲートウェイ）がＨＡに対して、ＭＮの現在の気付アドレスに関する問い合わせを行うことが可能である。この問い合わせに対して、ＨＡからは、ＭＮの現在の気付アドレスとしてＬＭＡのアドレスが通知される。ＨＡからＬＭＡのアドレスが提供されると、経路最適化のためにＣＮ側のゲートウェイノードとＬＭＡとの間でトンネルが形成される。【００２７】
また、下記の特許文献３に開示されている技術では、クライアント又はＭＮがＡＲに対してサブネットワークが変更されたか否かを要求した場合には、たとえサブネットワークが変更された場合であっても、ＡＲはホームプレフィックスのみを通知するように構成されている。これにより、ＭＮはサブネットワークの変更に伴うアドレス生成を行わなくなり、セッションが中断されないようにすることが可能となる。【００２８】
また、今後、モバイルノードは、ＷＬＡＮインタフェース、３Ｇインタフェース、ＷｉＭＡＸインタフェースなどの異なるアクセスタイプのインタフェースを複数備える可能性がある。このように、複数の異なる種類のインターフェースタイプを備えることで、ＭＮにおいて、負荷共有や負荷バランス、コスト低減やＱｏＳ向上のための優先度設定、フォールトトレランス、信頼性などを始めとするマルチホーミングの利点が実現されるようになる。ＭＮが複数のインタフェースを備えており、すべてのインタフェースが外部ドメインに接続されている場合には、ＭＮは、通常すべての気付アドレスをＨＡに登録することによって、マルチホーミングのサポートが実現されるようになる。【００２９】
また、例えば非特許文献６には、ＭＮがバインディング識別子（ＢＩＤ：Binding Identifier）オプションを用いて複数の気付アドレス（ＣｏＡ）を登録する方法や、ＭＮが複数のインタフェースのバインディングに関するＨＡへのバルク登録（bulk registration）を単一のＢＵメッセージによって実行できるようにする方法が記載されている。【００３０】
例えば図１１Ａに図示されているような複数の異なる種類のインタフェースを備えたＭＮ２６０Ａに関連して、複数の位置登録シグナリングが行われる必要がある。ここで、図１１Ａにおいて、ＭＮ２６０Ａは、３ＧＰＰネットワークや３ＧＰＰオペレータに由来する１つ又は複数のホームアドレスを構成する３ＧＰＰ対応端末であると仮定する。さらに、ＭＮ２６０Ａは、２つのインタフェース（インタフェース１（ＩＦ１）及びインタフェース２（ＩＦ２））を備えていると仮定する。なお、ＭＮ２６０ＡのＩＦ１はホームＰＭＩＰドメイン２５０Ａ（ＭＡＧ２６５Ａ）に接続されており、ＭＮ２６０ＡのＩＦ２は別の外部ＰＭＩＰドメイン２５１Ａ（ＭＡＧ２６７Ａ）に接続されている。また、これらのホームＰＭＩＰドメイン２５０Ａ及び外部ＰＭＩＰドメイン２５１Ａがインターネット２５２Ａに接続されており、このインターネット２５２Ａに接続されているＣＮ２７５Ａが、ＭＮ２６０Ａとの間でパケット通信セッションを有していると仮定する。【００３１】
図１１Ａにおいて、ＭＮ２６０Ａに関するＭＩＰｖ６のホームエージェントは、ホームＰＭＩＰドメイン２５０Ａに位置するＬＭＡ／ＰＤＮ−ＧＷ（ＬＭＡ／ＰＤＮ−ＧＷ／ＨＡ）２７０Ａである。また、図１１Ａにおいて、ＭＮ２６０Ａのインタフェース１は、無線リンクを通じてＭＡＧ２６５Ａに接続されており、ＭＮ２６０Ａのインタフェース２は、無線リンクを通じてＭＡＧ２６７Ａに接続されている。なお、以下では、このようなシナリオに関して説明を行うが、当業者であれば、このシナリオに限定されずに様々なシナリオに対して解釈することが可能である。例えば、ＭＮ２６０ＡとＭＡＧ（ＭＡＧ２６５ＡやＭＡＧ２６７Ａ）とが接続するアクセス技術は、例えばＷＬＡＮ、ＷｉＭＡＸ、３Ｇなどを始めとする任意のアクセス技術を用いることが可能である。【００３２】
また、ＭＮ２６０Ａは、何らかのマルチホーミングがサポートされているとする。ＭＮ２６０Ａは、ホームドメイン２５０Ａ内に存在する場合には、例えば両方のインタフェースに同一のホームアドレスを設定してもよく、両方のインタフェースのそれぞれに異なるホームアドレスを設定してもよい。【００３３】
また、ここでは、このシナリオにおける主要な問題点を示すため、ＭＮ２６０ＡがＩＦ１及びＩＦ２両方のインタフェースに同一のホームアドレスを設定しており、ＩＦ１及びＩＦ２に関するアクセスルータの変更を同時に行うように移動すると仮定する。以下では、このような移動をインタフェースの同時移動と記載する。このような同時移動は、例えばＩＦ２がＷＬＡＮに接続されており、ＩＦ１がＷｉＭＡＸセルなどのような小さなセルに接続されている場合に起こり得る。ここで、こうした同時移動が起こった場合に、ＭＮ２６０ＡのＩＦ１がＭＡＧ２６５ＡやホームＰＭＩＰドメイン２５０Ａ内のその他のＭＡＧに接続すると仮定する。この接続の結果、ＭＡＧ２６５Ａ（あるいは、ＭＮ２６０ＡのＩＦ１が接続したホームＰＭＩＰドメイン２５０Ａ内のその他のＭＡＧ）は、ＭＡＧ２６５ＡのイグレスアドレスとＭＮ２６０Ａのホームプレフィックスとのバインディングを行うプロキシバインディングアップデート（ＰＢＵ：proxy binding update）２８０Ａを送信する。【００３４】
また、この同時移動によって、ＭＮ２６０Ａは、ＬＭＡ／ＰＤＮ−ＧＷ２７０Ａから割り当てられたＭＮごとにユニークなプレフィックスを用いてＩＦ２に関する新たな気付アドレスを構成する。そして、ＭＮ２６０Ａは、ＩＦ２からＣＭＩＰに関するＢＵを実行する。【００３５】
また、非特許文献６には、ＭＮがバルク登録を行うことによってＭＮのＣｏＡをＨＡに登録する最適な方法が開示されている。バルク登録では、複数のインタフェースのバインディングが１つのシグナリングメッセージによって送信される。ＭＮは、どのインタフェースがバルク登録を行うために理想的なインタフェースかを把握することができないため、バルク登録はＭＮのインタフェースのどちらにおいても実行可能である。なお、バルク登録を行うために理想的なインタフェースは、ＭＮが迅速なバルク登録を実行することができるインタフェースである。ＭＮのあるインタフェースがホームドメインに接続されており、別のインタフェースが外部ドメインに接続されている場合には、“Ｈ”フラグが付加されたＣＭＩＰに関するＢＵが外部ドメインに接続しているインタフェースから送信される。【００３６】
また、下記の特許文献４には、ＭＮがスリープモードであるか、あるいは到達不能な状態の場合に、プロキシサーバがＭＮのパケットを受信するために用いられる方法が開示されている。この方法を使用した場合、ＭＮは、ＨＡへの位置更新シグナリングの送信をＨＡにあえて実行しなくてもよく、スリープモードに移行してプロキシサーバからデータを取得することが可能である。【００３７】
また、下記の特許文献５には、ファストハンドオフを実行するとともに、遅延やパケットロスなどのハンドオフに関連する問題を解決するための方法が開示されている。ここでは、ＭＮに関する正しいバインディングやＭＮの位置などとは無関係に、ＭＮに関連するパケットは、常にあるノードのグループに送信されるようにすることによってファストハンドオフが実現される。ＭＮが新しいアクセスルータ（ＡＲ：Access Router）に接続する前に、その新しいアクセスルータはＭＮあてのパケットを受信することができる。ＭＮが新しいＡＲに接続しなかった場合には、パケットはそのＡＲで破棄されることになる。また、ＭＮが他のＡＲに接続した場合でも、そのパケットを受信することが可能となる。【００３８】
特許文献５に開示されている技術では、基本的にファストハンドオフを実現するため、ＭＮのデータパケットをあるＡＲのグループへマルチキャストする方法が行われる。すなわち、この方法では、ＭＮが接続されているか否かに関係なく、ＭＮのパケットは１つ以上の基地局ノードやアクセスルータに送信される。ＭＮの正確な位置を予測するのは困難なので、基地局ノードやプロキシのグループに対して、ＭＮに送信されるべきパケットが渡される。【００３９】
また、下記の特許文献６には、ＭＮが自身の気付アドレスとしてフォーリンエージェント（ＦＡ：Foreign Agent）に関連するプロキシ気付アドレス（プロキシ関連ＣｏＡ）を使用する方法について開示されている。このプロキシ関連ＣｏＡは、ＦＡから各ＭＮに対して提供される。このようなアドレス構成を行うことで、カプセル化及びデカプセル化が、ＭＮではなくフォーリンエージェントで実行されるようになる。【００４０】
さらに、ＦＡの機能がＡＲに実装される場合、ＭＮのＣｏＡとしてプロキシ関連ＣｏＡを使用する方法によれば、ＭＮにおけるトンネリングのカプセル化及びデカプセル化の処理負荷がなくなり、負荷が大きい無線リンクにおけるトンネリングが行われないようにすることが可能となる。
【特許文献１】米国特許公開２００４００２４９０１
【特許文献２】国際特許公開ＷＯ０６／０１２５１１
【特許文献３】国際特許公開ＷＯ０７／０５０６２４
【特許文献４】米国特許公開２００４００１３０９９
【特許文献５】国際特許公開ＷＯ０３／０９０４０８
【特許文献６】国際特許公開ＷＯ０２／０６５７３１
【非特許文献１】Johnson, D. B., Perkins, C. E., and Arkko, J., "Mobility Support in IPv6", Internet Engineering Task Force Request For Comments 3775, June 2004.
【非特許文献２】Gundavelli, S., et. al., "Proxy Mobile IPv6", Internet Engineering Task Force (IETF) Working Group Draft: draft-sgundave-mip6-proxymip6-02.txt, March 5, 2007.
【非特許文献３】Soliman, H., et. al., “Interactions between PMIPv6 and MIPv6: scenarios and related issues” Internet Engineering Task Force (IETF) Working Group Draft: draft-giaretta-netlmm-mip-interactions-00, April 24, 2007.
【非特許文献４】Qin, A., et. al., "PMIPv6 Route Optimization Protocol", Internet Engineering Task Force Working Group Draft: draft-qin-mipshop-pmipro-00.txt, February 25, 2007.
【非特許文献５】“3GPP System Architecture Evolution: Report on Technical Options and Conclusion”, 3GPP TR 23.882, V1.9.0, April 3, 2007.
【非特許文献６】Wakikawa, R., et. al., " Multiple Care-of Addresses Registration", Internet Engineering Task Force Working Group Draft: draft-ietf-monami6-multiplecoa-02.txt, March 5, 2007.
【００４１】
以下、図１を参照しながら、３ＧＰＰシステムにおけるＰＭＩＰｖ６プロトコルの概要やその問題点について説明する。なお、ＵＥは３ＧＰＰで使用される用語であり、ＭＮはＩＥＴＦで使用される用語であるが、本明細書では、上記のＵＥ及びＭＮの両方の移動ホスト（移動端末）をＭＮ（モバイルノード）と表記する。【００４２】
図１には、様々な公共モバイルネットワーク（ＰＬＭＮ：Public Land Mobile Network）によって構成されている次世代（evolved）３ＧＰＰシステムが図示されている。図１に図示されているアクセスネットワークは、信頼性の無いＷＬＡＮタイプのネットワークである。通常、ＰＬＭＮは、コアネットワーク及びアクセスネットワークに特徴を有しており、３ＧＰＰでは、ＰＭＩＰｖ６もこうしたＰＬＭＮに導入されることになる。ＰＬＭＮのアクセスネットワークが次世代（evolved）３ＧＰＰ又はレガシの３ＧＰＰタイプのアクセスネットワークであれば、ＰＬＭＮは同一のオペレータによって管理される可能性が高く、ルータは同一のルートプレフィックスによって構成されたアドレスを有する可能性が高い。しかしながら、ＭＮが信頼性の無いＷＬＡＮを介して３ＧＰＰコアネットワークにアクセスを行おうとする場合には、そのＷＬＡＮセグメントは、異なるオペレータによって管理されている可能性があり、したがって、アクセスネットワークはインターネットに直接接続される可能性がある。【００４３】
信頼性の無い３ＧＰＰアクセスやＷＬＡＮアクセスが行われたとき、アクセスネットワークがインターネットへ直接接続されていない場合や、データトラフィックのエンド受信者が３ＧＰＰコアネットワーク内に位置している場合に、３ＧＰＰコアネットワークを経由する必要があるトラフィックは、ｅＰＤＧと呼ばれる信頼性のあるゲートウェイを経由しなければならない。【００４４】
図１では、３ＧＰＰシステムにおけるＰＭＩＰｖ６プロトコルの問題を説明するために、１つのＰＬＭＮを１つのオペレータが管理しているとする。図１において、ＰＬＭＮ１は３ＧＰＰコアネットワーク１０１とＩ−ＷＬＡＮタイプのアクセスネットワーク（Ｉ−ＷＬＡＮアクセスネットワークと記載）１０３とを有している。【００４５】
３ＧＰＰコアネットワーク１０１は、ＬＭＡ／ＰＤＮ−ＧＷ５０及びローカルの３ＧＰＰ ＡＡＡサーバ６０を有している。なお、ここではＬＭＡがＰＤＮ−ＧＷ（Packet Data Network Gateway：パケットデータネットワークゲートウェイ）として機能するものとする。ローカルの３ＧＰＰ ＡＡＡサーバ６０は、移動中のＭＮの認証情報を有しており、ＭＮが３ＧＰＰコアネットワーク１０１のサービスやＰＭＩＰｖ６サービス（ＰＬＭＮにＰＭＩＰｖ６が導入されている場合）を受けることが可能か否かを認証する。【００４６】
また、ＰＬＭＮ１のＩ−ＷＬＡＮアクセスネットワーク１０３は、ｅＰＤＧ／ＭＡＧ４０、ＡＲ２０、ＡＲ２１を有している。なお、ここでは、ｅＰＤＧにＭＡＧの機能が備わっているとする。信頼性の無いＷＬＡＮのシナリオにおいては、ｅＰＤＧにＭＡＧの機能が備わっている必要がある。これは、ｅＰＤＧが、ＷＬＡＮに属するルータの中で、３ＧＰＰコアネットワークが信頼できる唯一のルータであることによる。また、ＰＬＭＮ１にはＰＭＩＰｖ６が導入されており、ＭＮ１０がこのネットワークに接続されているとする。また、このＰＬＭＮ１では、ＭＮ１０がＡＲ２０に接続されている。【００４７】
また、ＰＬＭＮ２も同様に、３ＧＰＰコアネットワーク１０２とＩ−ＷＬＡＮアクセスネットワーク１０４とを有しており、３ＧＰＰコアネットワーク１０２も同様に、ＬＭＡ／ＰＤＮ−ＧＷ５１及び３ＧＰＰ ＡＡＡサーバ６１を有している。また、Ｉ−ＷＬＡＮアクセスネットワーク１０４は、ｅＰＤＧ／ＭＡＧ／ＡＲ３０、３１を有している。なお、ここでは、ＡＲにｅＰＤＧやＭＡＧの機能が備わっているとする。また、このＰＬＭＮ２では、ＭＮ１１がｅＰＤＧ／ＭＡＧ／ＡＲ３０に接続されている。また、ＰＬＭＮ１、ＰＬＭＮ２（３ＧＰＰコアネットワーク１０１、１０２）はグローバル通信ネットワーク１００に接続されている。【００４８】
ＰＭＩＰｖ６が実装されているＰＬＭＮ１において、ＭＮ１０がＩ−ＷＬＡＮアクセスネットワーク１０３に接続する際に受信するプレフィックスは、ＡＲ２０のオンリンクプレフィックスである。これは、ＡＲ２０にはＭＡＧの機能（３ＧＰＰの信頼性のあるゲートウェイｅＰＤＧに実装されている必要がある）が実装されていないことにより生じる。この場合、ＭＮ１０は、このプレフィックスがローカルブレイクアウト（下記のように、ＭＮ１０のホームドメインを経由しないパケット伝送）や経路最適化（モバイルＩＰにおけるＣＮへのＣｏＡ登録）に適しているか否かを把握することができない。また、ＭＮ１０はこのプレフィックスの性質（このプレフィックスがオンリンクプレフィックスであること）を把握できたとしても、ＰＭＩＰｖ６ドメインプレフィックスを取得していないので、このＰＬＭＮ１においてＰＭＩＰサービスを受けることができないという問題がある。【００４９】
なお、ローカルブレイクアウトとは、外部（foreign）ドメインに接続している時にホームドメインまで戻る経路をとらず、ＣＮと通信することを指し、ＭＮがホームドメイン以外のオペレータのドメインへの接続状態にある場合、本来ならば、インターネット上のＣＮと通信する際にホームドメインに存在するＬＭＡ（ＰＤＮ？ＧＷなど）を経由しなければならないものを、接続している外部のドメインから（外部ドメインもまたＰＭＩＰドメインを構成していればそのドメインのＬＭＡを経由して）直接インターネット上のＣＮと通信する（breakout）ことを意味する。さらに、本明細書においては、ローカルブレイクアウトという用語をより広義に用い、ローカルブレイクアウトという表現には、ＭＮが接続しているドメインがホーム／外部であることを問わず、また、アクセスネットワークの種別を問わずに、（インターネットから）グローバルに到達可能なアドレスを使って、ホームドメインを経由しないでインターネット上のＣＮと通信することも含まれるものとする。【００５０】
一方、ＰＭＩＰｖ６が実装されているＰＬＭＮ２では、ＭＡＧ及びｅＰＤＧの機能はＡＲに実装されているので、ｅＰＤＧ／ＭＡＧ／ＡＲ３０が通知するプレフィックスはＰＭＩＰｖ６ドメインプレフィックスである。この場合においても、ＭＮ１１は、このプレフィックスがローカルブレイクアウトに適しているか否かを把握することができない。また、ＭＮ１１がこのプレフィックス（ＰＭＩＰｖ６ドメインプレフィックス）を使用した場合には、ＭＮ１１と同一ＰＭＩＰｖ６ドメイン（ＰＬＭＮ２）に接続されているＣＮとの間で行われる通信はＬＭＡ経由となり、ＭＮ１１とＣＮとの間でＲＯを実現することができない。【００５１】
以下、図２を参照しながら、ＰＭＩＰｖ６が実装されているＰＬＭＮ内をＭＮが移動した場合に生じる問題について説明する。図２において、ＭＮ２１０はＰＭＩＰｖ６ドメイン２００に接続されており、このＰＭＩＰｖ６ドメインがＭＮ２１０のホームドメインであるとする。したがって、この場合においても、ＬＭＡがＭＮ２１０のホームエージェント（ＨＡ）として機能する。また、３ＧＰＰでは、ＳＡＥ（Service Architecture Evolution）アンカがＭＩＰｖ６のホームエージェントとして機能することが可能であり、ＬＭＡ機能が実装されたルータとして機能することも可能である。すなわち、図２では、ＬＭＡ／ＨＡ／ＳＡＥアンカ２３０が、ＬＭＡ、ＭＮ２１０のＨＡ、ＳＡＥアンカのすべての機能を有している。【００５２】
ここで、ＭＮ２１０が、同一のＰＭＩＰｖ６ドメイン２００に接続されているＣＮ２１１と通信を行っているとする。また、ＣＮ２１１はＲＯ可能（RO enabled）であり、このＰＭＩＰｖ６ドメイン２００に加入しているとする。なお、ＲＯ可能とは、ＣＮ２１１がＣＭＩＰタイプのＲＯを実行できることを意味する。また、ＭＮ２１０は、さらにＣＮ２１３及びＣＮ２１２と通信を行っている。なお、ＣＮ２１３はインターネット（あるいは公共パケットデータネットワーク）２０１上に存在しているＲＯ可能なノードであり、ＣＮ２１２はＲＯ機能を有さないノードであるとする。【００５３】
さらに、ここでは、ＭＮ２１０が、同一のインタフェースに複数の異なるアドレスを構成することができるマルチホーミング可能なノードであるとする。ＭＮ２１０がこのＰＭＩＰｖ６ドメイン２００に移動して、アクセスルータであるＭＡＧ２２０に接続し、ＭＡＧ２２０のオンリンクプレフィックス及びＰＭＩＰｖ６ドメインプレフィックスの両方を受信した場合、ＭＮ２１０は２つのアドレスを構成する可能性がある。例えば、ＭＮ２１０はＣＮ２１１やＣＮ２１３などのＲＯ可能なＣＮと通信を行っているので、経路最適化を行うためにグローバルプレフィックス（オンリンクプレフィックス）の使用を望む可能性がある。一方、ＭＮ２１０はホームドメインに存在しているので、そのホームプレフィックスを使用してホームアドレスを構成することで、例えばＣＮ２１２などのレガシＣＮとの通信における最適化された経路の実現を望む可能性もある。【００５４】
このようなアドレス構成が行われると、ＭＮ２１０はホームエージェント（ＬＭＡ／ＨＡ／ＳＡＥアンカ２３０）にバインディングアップデートを行うことになる。このＢＵはＣＭＩＰタイプのＢＵである。また同様に、ＭＡＧ２０はＬＭＡ（ＬＭＡ／ＨＡ／ＳＡＥアンカ２３０）にプロキシバインディングアップデート（ＰＢＵ：proxy binding update）を送信し、ＭＮ２１０のホームアドレス（ＰＭＩＰｖ６ドメインアドレス）とＭＡＧ２０のイグレスインタフェースのアドレスとの関連付けが行われる。このＢＵはＰＭＩＰタイプのＢＵである。【００５５】
図２においては、ＭＮ２１０がＭＡＧ２２０に接続された際にＭＮ２１０からＬＭＡ／ＨＡ／ＳＡＥアンカ２３０に送信されるＢＵは、シグナル２４０によって示されている。一方、ＭＡＧ２２０からＬＭＡ／ＨＡ／ＳＡＥアンカ２３０に送信されるＰＢＵはシグナル２４１によって示されている。ＭＮ２１０がさらにＰＭＩＰｖ６ドメイン内を移動した場合（例えば、ＭＡＧ２２１やＭＡＧ２２２に接続した場合）においても同様に、２重のＢＵシグナリング（ＣＭＩＰのＢＵシグナリング及びＰＭＩＰのＰＢＵシグナリング）が発生することになる。こうしたＭＮ２１０の移動に関連するシグナリングは、図２において、ＢＵシグナリング（シグナル２４２、２４４）、ＰＢＵシグナリング（シグナル２４３、２４５）によって示されている。この結果、ＭＮ２１０の移動に伴って（特に、ＭＮ２１０が高速移動した場合に）ＰＭＩＰｖ６ドメイン２００内には、特定の目的の一連のシグナリング（ここではＢＵやＰＢＵにかかわるシグナリング）が高頻度で発生し、他の通信のリソースを消費してしまうことで、データパケットの遅延や帯域不足などが発生してしまう、シグナリングストーム（ＢＵストーム）と呼ばれる状況が引き起こされることになる。【００５６】
ＭＮ２１０がローカルブレイクアウト用のグローバルプレフィックスを把握している場合には、ＭＮ２１０は、ＣＮ２１１やＣＮ２１３との間でＲＯを実行することが可能である。この場合、経路最適化されたデータパスはそれぞれパス２４６、２４８のようになる。また、ＭＮ２１０は、ＣＮ２１２と通信を行う際には、ＰＭＩＰｖ６ドメインプレフィックスを使用する。ＭＮ２１０からＣＮ２１２へのデータパケットはＭＡＧ２２０に送信され、ＭＡＧ２２０からＬＭＡ２３０にトンネルされる。ＬＭＡ２３０は、パケットをデカプセル化し、デカプセル化されたパケットをＣＮ２１２に送信する。【００５７】
上述のように、従来の技術には２種類の問題が存在している。第１の問題は、ＰＭＩＰｖ６ドメイン内を移動しているＭＮは、ＡＲにＭＡＧやｅＰＤＧの機能が備わっていない場合にはＰＭＩＰｖ６ドメインプレフィックスを把握できない可能性があり、ＡＲにＭＡＧやｅＰＤＧの機能が備わっている場合にはオンリンクグローバルプレフィックスを把握できない点にある。すなわち、従来の技術においては、ＭＮは、様々な異なるタイプのＣＮと効率良く通信を行うために選択すべき様々なプレフィックス（複数のプレフィックス）を把握することができないという問題がある。また、第２の問題は、仮にＭＮが利用可能なプレフィックスから複数のタイプのアドレス（例えばＰＭＩＰタイプのアドレスとＣＭＩＰタイプのアドレス）を構成できたとしても、上述のように２重のＢＵシグナリング（ＢＵシグナリング及びＰＢＵシグナリング）によるＢＵストームが発生してしまうという点にある。【００５８】
また、上述の特許文献１においては、ローカルブレイクアウト用にどのアドレスを選択すべきかに関する問題について言及されていない。すなわち、特許文献１におけるＭＮは、ＣＮやＨＡと通信を行うために使用されるアドレス（グローバルアドレス）や、ＭＡへの位置登録に使用されるアドレス（ローカルアドレス）しか把握できず、複数のアドレス（又はプレフィックス）の中からどのアドレス（又はプレフィックス）を選択すると、通信の効率化（経路の最適化）が実現されるかに関する問題について言及されていない。さらに、特許文献１では、ローカルドメイン内における経路最適化の問題に関して言及されていない。モビリティは完全にＭＮによって処理されるため、上述のような２重のシグナリングが生じる問題（図２に示されている問題）は、この特許文献１に記載のシステムでは起こらない。【００５９】
また、上述の特許文献２においては、ＣＮ側のゲートウェイノードとＬＭＡとの間の経路最適化に関しては言及されているが、ＬＭＡの配下における経路最適化の問題に関しては取り扱われていない。また、特許文献２に開示されている技術では、ローカルモビリティ管理はＭＮ又はＡＲによって処理され、グローバルモビリティ管理はＬＭＡによって処理される。これは、図１及び図２に図示されているシナリオや、本発明が動作するシナリオとは大きく異なっている。また、特許文献２においては、ローカルブレイクアウト用にどのアドレスが使用されるべきかという問題についてまったく言及されていない。特許文献２に開示されている技術では、ＭＮが把握しているアドレスはローカルアドレスのみであり、また、経路最適化はＬＭＡ自身によって処理される。すなわち、特許文献２に開示されている技術は、ＭＮが様々なプレフィックスやアドレスの選択を行う際に発生する問題に関しては言及しておらず、図１及び図２によって示されている問題を解決しようとするものではない。【００６０】
また、上述の特許文献３に開示されている技術では、ホームプレフィックスのみがＭＮに提供されるので、ＭＮは経路最適化を行わない。したがって、経路最適化することによって効率的な通信が行えるＣＮとの間においても、通信経路の最適化が行われない。さらに、１つのプレフィックスしか提供されず、ＭＮは複数のプレフィックスの中からプレフィックスを選択する必要がないので、特許文献３に開示されている技術によって、図１に図示されているような正しいプレフィックスを選択するという問題を解決することはできない。【００６１】
また、非特許文献６に開示されている技術によれば、図１１Ａに示されているように、ＣＭＩＰに関するＢＵが伝送されるパス２８１Ａの距離が長くなってしまう。このＣＭＩＰに関するＢＵにおける長距離のパス２８１Ａでは、ＬＭＡ／ＰＤＮ−ＧＷ（ＬＭＡ／ＰＤＮ−ＧＷ）２７１ＡにおいてＩＦ２に関する位置更新を行うため、ＣＭＩＰタイプのＢＵパケットが外部ＰＭＩＰドメイン２５１Ａ、更にはインターネット２５２Ａを経由して伝送される必要がある。【００６２】
さらに、このＢＵパケットは、ＭＡＧ２６７ＡからＬＭＡ／ＰＤＮ−ＧＷ２７０Ａまでパケットのカプセル化が行われる必要があり、このカプセル化の処理によって、位置更新に関して更なる遅延が生じることになる。【００６３】
このように、非特許文献６に開示されている技術によれば、図１１Ａに示すシナリオにおいてはＩＦ２の気付アドレスの登録が長距離のパスを通じて行われ、より大量のネットワークリソースを使用することになるという問題（非特許文献６に関連する第１の問題）と、ＭＮ２６０Ａの両方のインタフェースに関する位置登録シグナリングが、図１１Ａのパス２８０Ａ及び２８１Ａで示されるように行われることになり、ネットワークにおけるシグナリングの負荷を低減するために最適化が行われる必要があるという問題（非特許文献６に関連する第２の問題）が存在する。なお、図１１Ａに開示されているシナリオでは、ＭＮ２６０Ａによってアップデート（パス２８１Ａ）が行われるとともに、固定エンティティ（ＭＡＧ２６５Ａ）によって位置情報に関する別のアップデート（パス２８０Ａ）が行われる。【００６４】
また、非特許文献６に開示されているバルク登録を利用する方法に関しては、ＭＮがすべてのシグナリングをコントロールしているわけではなく、図１１Ａに示すシナリオでは、ＭＮからバルク登録のシグナリングを送信することはできないという問題（非特許文献６に関連する第３の問題）がある。すなわち、図１１Ａにおいては、あるインタフェースの位置更新シグナリングはＭＮ２６０Ａによって行われるものの、別のインタフェースの位置更新シグナリングはＭＡＧ２６５Ａによって行われる。また、仮にＭＮがＩＦ２からバルク登録のシグナリングを行うとしても、インタフェースのバルク登録がＬＭＡ／ＰＤＮ−ＧＷ２７１Ａに届くまでに長時間かかってしまい、上述の問題を解決できない可能性がある。【００６５】
また、特許文献４に開示されている技術によれば、ＨＡへのシグナリングは低減することになるが、ＭＮは複数のインタフェース経由でプロキシサーバからデータを取得する必要があり、ＭＮからプロキシサーバに対して何らかのバインディング登録が行われる必要がある。なお、ＭＮが１つ又は複数のインタフェースに関してプロキシサーバに迅速かつ最適化された位置登録を実行可能とする方法が存在し得るが、本発明による技術とは異なる解決策を提供するものであり、本明細書では説明は行わない。【００６６】
次に、マルチインタフェースのＭＮがホームＰＭＩＰドメイン及び外部ＰＭＩＰドメイン内で移動する際に、ハンドオフ問題が生じるシナリオについて説明する。図１１Ｂにおいて、ＭＮ２６０Ｂは２つのインタフェース（ＩＦ１及びＩＦ２）を備えており、初期状態として、ＭＮ２６０Ｂが両方のインタフェースによってホームＰＭＩＰドメイン２５０Ｂに接続していると仮定する。さらに、ＭＮ２６０Ｂは、ＬＭＡ／ＰＤＮ−ＧＷ（ＬＭＡ／ＰＤＮ−ＧＷ／ＨＡ）２７０Ｂから１つ又は複数のホームプレフィックスを取得すると仮定する。初期状態では、ＭＮ２６０ＢのＩＦ２は、ＭＡＧ２６６Ｂに接続しており、ＭＮ２６０ＢのＩＦ１は、ホームＰＭＩＰドメイン２５０Ｂ内の別のＭＡＧ（図１１Ｂには不図示）に接続されている。【００６７】
ＭＮのＩＦ２がアクセスリンクによってＭＡＧ２６６Ｂに接続している場合には、ＭＡＧ２６６Ｂは、ホームプレフィックスとＭＡＧ２６６Ｂのイグレスアドレス（イグレスインタフェースのアドレス）とのバインディングを行うＰＢＵ２８０Ｂを送信する。このＰＢＵ２８０Ｂによる登録は、ＬＭＡ／ＰＤＮ−ＧＷ２７０Ｂにエントリを作成する。なお、この登録によるバインディングキャッシュのエントリは、図１１Ｄのバインディングキャッシュ２７１Ｄ内の最初のエントリによって表されている。【００６８】
また、ＩＦ１は移動してアクセスリンク経由でＭＡＧ２６５Ｂに接続した後にすぐホームＰＭＩＰドメイン２５０Ｂから離れて、アクセスリンク経由で外部ドメイン（アクセスドメイン）２５１Ｂに接続したと仮定する。さらに、ホームＰＭＩＰドメイン２５０Ｂ及び外部ドメイン２５１Ｂはインターネット２５２Ｂに接続されていると仮定する。なお、ホームＰＭＩＰドメイン２５０Ｂは、複数の異なるタイプのアクセスネットワークによって構成され得る。また、外部ドメイン２５１Ｂは、ＰＭＩＰに基づくアーキテクチャで構成されていてもよく、あるいは構成されていなくてもよい。【００６９】
ＭＮ２６０ＢのＩＦ１が移動してＡＲ２６７Ｂに接続した場合には、ＭＮ２６０Ｂは、ＩＦ１に関する気付アドレスを構成した後、ＬＭＡ／ＰＤＮ−ＧＷ２７０Ｂに対してＣＭＩＰのＢＵ（パス２８２Ｂを経由）を実行する。このパス２８２Ｂを経由するＢＵは、上述のＭＡＧ２６５ＢからのＰＢＵ２８１Ｂよりも早くＬＭＡ／ＰＤＮ−ＧＷ２７０Ｂに届くかもしれない。【００７０】
このような事象が起こった場合には、図１１Ｄのバインディングキャッシュ２７１Ｄ内の２番目のエントリに表されているようなＩＦ１に関するバインディングキャッシュ２７１Ｄ内のエントリが、ＬＭＡ／ＰＤＮ−ＧＷ２７０Ｂにおいて作成される。【００７１】
なお、インタフェース識別子によってインタフェースの識別が行われ、図１１Ｄに図示されているように、バインディングキャッシュエントリ２７１Ｄにインタフェース識別子（ＩＦ−ＩＤ／ＢＩＤ）のパラメータが含まれている。バインディングキャッシュでは、任意の各インタフェースに関して、ＰＭＩＰのＰＢＵ又はＣＭＩＰのＢＵに関するエントリが維持されている。【００７２】
パス２８２Ｂを経由するＣＭＩＰのＢＵよりも遅れて、ＰＢＵ２８１ＢがＭＡＧ２６５ＢからＬＭＡ／ＰＤＮ−ＧＷ２７０Ｂに届くと、このＰＢＵ２８１Ｂは、正しいＣＭＩＰのＢＵエントリ（図１１Ｄのバインディングキャッシュ２７１Ｄ内の２番目のエントリ）を上書きしてしまい、その結果、図１１Ｄのバインディングキャッシュ２７１Ｄ内の３番目のエントリが作成される。【００７３】
このような到着順を誤ったエントリの登録が起こったとき、ＬＭＡ／ＰＤＮ−ＧＷ２７０Ｂが同一プレフィックスをＭＮ２６０Ｂの両方のインタフェースに割り当てる場合には、ＭＮ２６０ＢのＩＦ１から正しいバインディングが届くまでＩＦ１経由のパケット到達可能性は実現されない。このような同一プレフィックスを割り当てるような場合においては、ＩＦ１を通じて送信されるパケットはなくなり、ＩＦ２を通じたパケット送信のみ可能となる。【００７４】
一方、ＬＭＡ／ＰＤＮ−ＧＷ２７０ＢがＭＮの各インタフェースに対してユニークなプレフィックスを与える場合には、ＭＮ２６０Ｂは、それぞれのプレフィックスを用いて異なるユニークなホームアドレスを構成している可能性がある。複数のプレフィックスを割り当てるような場合にＩＦ１に関する誤ったバインディングキャッシュエントリが発生したときには、ＩＦ１に関する正しいバインディングがＬＭＡ／ＰＤＮ−ＧＷ２７０Ｂに確立されるまでは、ＩＦ１に構成されたホームアドレスに届くべきデータパケットはＭＮ２６０Ｂに届かない。【００７５】
基本的に、別の正しいＣＭＩＰに関するＢＵがＬＭＡ／ＰＤＮ−ＧＷ２７０Ｂに到着するまで、ＩＦ１に関するハンドオフによるパケットロスやハンドオフ遅延が生じてしまう。こうしたパケットロスやハンドオフ遅延は、遅延にセンシティブなフローや重要な情報のデータフローのＱｏＳ品質を低下させることになる。【００７６】
また、特許文献５に開示されている技術によれば、図１１Ｂに示されている上述の問題を解決できるかもしれないが、データパケットのマルチキャストが使用されることから、多量のネットワークリソースを必要とし、ネットワークリソースを浪費してしまうことになる。【００７７】
また、信頼できないＷＬＡＮアクセス（non-trusted WLAN access）において、３ＧＰＰコアネットワークにアクセスするためには、パケットはｅＰＤＧと呼ばれる信頼できるゲートウェイ（trusted gateway）を経由して伝送される必要がある。しかしながら、ｅＰＤＧは、ルーティング階層においてより上位に配置されるＷＬＡＮアクセスドメイン内に存在するルータであり、このようなネットワーク構成の場合には、必ずしもＭＮの直接的なアクセスルータがｅＰＤＧとはならない。こうしたｅＰＤＧに係るネットワーク構成において、ＭＮが異なるタイプのプレフィックスを受信する場合には、ＣＮの場所（position）やネットワーク上の位置（location）に応じて、ＭＮは、ＣＮとの経路最適化のためのＣｏＡを構成する適切なプレフィックスを選ぶことが可能である。【００７８】
図１１Ｃにおいて、ＭＮ２０５Ｃは、信頼できないＷＬＡＮアクセスネットワーク（非信頼ＷＬＡＮ）２０３Ｃを通じて、ホームＰＭＩＰドメイン２０２Ｃに接続されており、２つのＣＮ（ＣＮ２１０Ｃ及びＣＮ２１１Ｃ）のそれぞれと通信を行っている。ＣＮ２１０Ｃは、ＷＬＡＮアクセスネットワーク２０３Ｃ内に位置するＡＲ２１７Ｃに接続されている。一方、ＣＮ２１１Ｃは、ＭＡＧ２２１Ｃに直接接続されており、信頼できるＷＬＡＮアクセスネットワーク（信頼ＷＬＡＮ）２００Ｃ内に位置している。ホームＰＭＩＰドメイン２０２Ｃは、インターネット２０１Ｃに直接接続されている。【００７９】
さらに、初期状態としてＭＮ２０５ＣがＡＲ２１５Ｃに接続されており、図１１Ｃの軌跡２０６のように移動すると仮定する。ＭＮ２０５Ｃは、あるＣＮ（不図示）と通信を行う際にホームアドレスを使用することを決定すると、まず、ｅＰＤＧ／ＭＡＧ２２０Ｃにデータパケットをトンネルする。ｅＰＤＧ／ＭＡＧ２２０Ｃにおいて、このデータパケットはデカプセル化され、さらに、ＭＮ２０５ＣのＨＡであるＬＭＡ／ＰＤＮ−ＧＷ（ＬＭＡ／ＰＤＮ−ＧＷ／ＨＡ）２３０Ｃにトンネルされる。【００８０】
このＰＭＩＰコアネットワーク（ホームＰＭＩＰドメイン２０２Ｃ）において、さらにＧＷ２３１Ｃが存在しており、このＧＷ２３１Ｃが、ＬＭＡ／ＰＤＮ−ＧＷ２３０Ｃと比べてルーティング階層の下位層に配置されていると仮定する。基本的に、このＧＷ２３１Ｃは何らかのポリシを実施し、３ＧＰＰコアネットワークにアクセスするＭＮへのＡＡＡサービス（例えば課金管理など）を実行することが可能である。さらに、ＧＷ２３１Ｃはインターネット２０１Ｃに接続されていると仮定する。ＭＮ２０５Ｃからのパケットは、ＧＷ２３１Ｃに設定されるポリシに従ってＧＷ２３１Ｃ経由でトンネルすることが可能である。【００８１】
このようなシナリオでは、ＭＮ２０５Ｃが２つのタイプのプレフィックスを受信してもよい。２つのタイプのプレフィックスのうちの１つは、例えば、ＡＲ２１５Ｃから提供される論理的に正しいオンリンクプレフィックスであり、もう１つは、ＭＮ２０５ＣがｅＰＤＧ／ＭＡＧ２２０Ｃとの間でトンネルを確立した場合にｅＰＤＧ／ＭＡＧ２２０Ｃから送信されるＰＭＩＰのホームプレフィックスである。図１１Ｃのシグナリング２４０Ｃは、ＡＲ２１５Ｃから受信した２つのプレフィックスを表している。これらの２つのプレフィックスは、ＭＮ２０５Ｃにおいて異なるタイミングで受信される。【００８２】
ＣＮがＰＭＩＰドメインのプレフィックスを使用して気付アドレスを構成しているのであれば、ＭＮ２０５Ｃは、ＣＮ２１０ＣやＣＮ２１１Ｃとの経路最適化シグナリング（例えばＲＲテストに係るシグナリング）を行う場合には、これら２つのＣＮがＭＮ２０５Ｃと同一のＰＭＩＰドメインに位置していると把握できる可能性がある。このような場合には、ＭＮ２０５Ｃは、ＡＲ２１５Ｃによって生成されたオンリンクプレフィックスを使用して、上述のＣＮ２１０ＣやＣＮ２１１Ｃとの間で経路最適化セッションを確立してもよい。【００８３】
このようにオンリンクプレフィックスを使用した場合の問題点は、アクセスドメイン（ＷＬＡＮアクセスネットワーク）２０３Ｃがかなり広大で多数のＡＲが存在している場合には、ＭＮ２０５Ｃは、ＷＬＡＮアクセスネットワーク２０３Ｃ内の異なるＡＲに接続するたびに、異なる気付アドレスを構成してＣＮとの間で経路最適化セッションを開始する必要があるかもしれないという点である。さらに、ＭＮ２０５Ｃがアクセスネットワーク２０３Ｃ内の各ＡＲの位置で気付アドレスを構成する場合には、ＭＮ２０５Ｃは、その気付アドレスをＨｏＡに関連付けるバインディングをＨＡ２３０Ｃへアップデートする必要があり、これによって、ＰＭＩＰコアネットワーク（ホームＰＭＩＰドメイン２０２Ｃ）内のシグナリング負荷は確実に増大してしまう。【００８４】
さらに、これらの位置登録シグナリングパケットはｅＰＤＧ／ＭＡＧ２２０Ｃへトンネルされ、さらに、デカプセル化された後にＬＭＡ／ＰＤＮ−ＧＷ（ＬＭＡ／ＰＤＮ−ＧＷ／ＨＡ）２３０Ｃへ発送される。ＭＮ２０５ＣがＡＲ２１５Ｃに接続されている場合には、位置登録シグナリングはパス２４１Ｃ及び２４３Ｃに示されているように伝送される。一方、ＭＮ２０５ＣがＡＲ２１６Ｃに接続されている場合には、位置登録シグナリングはパス２４２Ｃ及び２４４Ｃに示されているように伝送される。【００８５】
また、ｅＰＤＧ／ＭＡＧ２２０ＣがホームプレフィックスをＭＮ２０５Ｃに提供した場合には、ｅＰＤＧ／ＭＡＧ２２０Ｃが、ＬＭＡ／ＰＤＮ−ＧＷ／ＨＡ２３０ＣにおけるＰＭＩＰに関するバインディングのアップデートを行うことも可能である。なお、この場合については図１１Ｃには図示されていない。ここでの問題は、アクセスドメイン（ＷＬＡＮアクセスネットワーク）２０３Ｃに多数のＡＲが存在しているので、オンリンクプレフィックスが理想的な状態とはならず、別のプレフィックスを探す必要が生じてしまう場合があり得る。【００８６】
また、特許文献６に開示されている方法によれば、ＭＮからＡＲへの無線パスを経由するトンネリングの負荷は低減されるものの、図１１Ｃに示されている問題を解決することはできない。
【発明の開示】
【００８７】
本発明は、上記の問題を解決するため、移動端末がＰＭＩＰドメインを移動する際に、選択可能な様々なプレフィックスがアクセスルータから提供されるようにすることを目的とする。また、本発明は、移動端末が利用可能なプレフィックスから構成する必要があるアドレスのタイプを選択し、ＰＭＩＰドメインに対してシグナリングの負荷をかけずに、経路が最適化されるようにコレスポンデントノードとの通信を行えるようにすることを目的とする。
【００８８】
本発明の通信制御方法は、上記の目的を達成するため、ネットワークベースのローカルモビリティ管理プロトコルが実装されているネットワークドメインを構成し、前記ネットワークドメインに接続されている移動端末の位置情報を管理する機能を有する位置管理ノードと、前記移動端末の位置情報の登録を代理して行う機能を有する代理登録ノードと、前記移動端末の認証を行う認証サーバとを有する通信システムにおける通信制御方法であって、
前記ネットワークドメインをホームドメインとする移動端末が、複数のプレフィックスを取得するステップと、
前記移動端末が、前記複数のプレフィックスから複数のアドレスを取得するステップと、
前記移動端末が、前記複数のアドレスを前記ネットワークドメインに通知するステップと、
前記代理登録ノードが、前記移動端末から通知された前記複数のアドレスのそれぞれに係るバインディング情報を前記位置管理ノードに登録するステップとを、
有する。
この方法により、移動端末が複数のプレフィックスによって構成されるアドレスを使い分けることができるようになる。また、移動端末が利用可能な複数のプレフィックスから構成されるアドレスを使い分けることで、ＰＭＩＰドメインに対してシグナリングの負荷をかけずに、コレスポンデントノードとの通信に係る経路を最適化できるようになる。
【００８９】
さらに、本発明の通信制御方法は、上記の処理に加えて、前記移動端末が、前記ネットワークドメインに接続する際に複数のプレフィックスを要求するステップと、
前記代理登録ノードが、前記複数のプレフィックスの要求に基づいて、前記複数のプレフィックスが前記移動端末に通知されるよう処理するステップとを、
有する。
この方法により、移動端末がＰＭＩＰドメイン内を移動する際に、アクセスルータから移動端末に対して複数のプレフィックスが提供されるようになる。
【００９０】
さらに、本発明の通信制御方法は、上記の処理に加えて、  前記プレフィックス取得ステップが、
前記移動端末が、前記ネットワークドメインに接続する際に、前記移動端末に前記ネットワークドメインへの接続を提供するアクセスルータに対して前記複数のプレフィックスを要求するステップと、
前記アクセスルータが、前記代理登録ノードに前記複数のプレフィックスの要求を渡し、前記代理登録ノードが、前記認証サーバに前記移動端末の認証を依頼するステップと、
前記認証サーバが、前記移動端末による前記ネットワークドメインへの接続資格を確認した後にドメインプレフィックスを前記移動端末に割り当て、前記ドメインプレフィックスを前記代理登録ノードに通知するとともに、前記複数のプレフィックスを前記移動端末に通知するよう前記代理登録ノードに指示するステップと、
前記代理登録ノードが、前記ドメインプレフィックスを前記アクセスルータを通じて前記移動端末に通知するとともに、前記認証サーバからの前記複数のプレフィックスの通知指示に基づいて前記アクセスルータにグローバルプレフィックスの通知を行わせるステップとを有し、
前記アドレス通知ステップが、前記移動端末が前記ドメインプレフィックスを含むホームアドレスと、前記グローバルプレフィックスを含むグローバルアドレスとを取得するステップを有し、
前記アドレス通知ステップが、前記移動端末が前記ホームアドレス及び前記グローバルアドレスを前記アクセスルータに通知し、前記アクセスルータが前記ホームアドレス及び前記グローバルアドレスを前記代理登録ノードに渡すステップを有し、
前記バインディング登録ステップが、前記代理登録ノードが前記ホームアドレス又は前記ドメインプレフィックスと前記代理登録ノード自身のアドレス又はプレフィックスとを関連付ける第１のバインディング情報、及び、前記ホームアドレスと前記グローバルアドレスとを関連付ける第２のバインディング情報を前記位置管理ノードに登録するステップを有する。
この方法により、ＭＡＧ（及びｅＰＤＧ）がＡＲ上に実装されていない場合であっても、本発明の適用が可能となる。すなわち、移動端末がＰＭＩＰドメイン内を移動する際に、アクセスルータから移動端末に対して複数のプレフィックスが提供されるようになり、移動端末がこれら複数のプレフィックスによって構成されるアドレスを使い分けることができるようになる。また、移動端末が利用可能な複数のプレフィックスから構成されるアドレスを使い分けることで、ＰＭＩＰドメインに対してシグナリングの負荷をかけずに、コレスポンデントノードとの通信に係る経路を最適化できるようになる。
【００９１】
さらに、本発明の通信制御方法は、上記の処理に加えて、前記移動端末が接続されるアクセスルータが前記代理登録ノードとしての機能を有さない場合、前記アクセスルータは、前記移動端末と前記代理登録ノードとの間において伝送される情報を中継するとともに、前記アクセスルータ独自のオンリンクプレフィックスを通知する。
この方法により、ＭＡＧ（及びｅＰＤＧ）がＡＲ上に実装されていない場合には、ＡＲ独自のオンリンクプレフィックスが移動端末に通知されるようになる、なお、アクセスルータは、移動端末からの要求に応じてオンリンクプレフィックスの通知を行ってもよく、認証サーバ（ローカルサーバ）やＭＡＧからの指示に従って行ってもよく、あるいは、任意のタイミングで通知を行ってもよい。
【００９２】
さらに、本発明の通信制御方法は、上記の処理に加えて、前記移動端末が複数の通信インタフェースを有しており、前記複数の通信インタフェースのうちの少なくとも１つが外部ネットワークドメインに接続されている場合に、前記アドレス通知ステップにおいて、前記移動端末が、前記外部ネットワークドメインが接続されている通信インタフェースに対応して設定されるアドレスを、前記ホームドメインに接続されている通信インタフェースから前記ホームドメインに通知するステップを有する。
この方法により、外部ドメインに接続されている移動端末のバインディングアップデートを、ホームドメインに接続されているインタフェース経由で行うことが可能となる。
【００９３】
さらに、本発明の通信制御方法は、上記の処理に加えて、前記バインディング登録ステップにおいて、前記代理登録ノードが、前記外部ネットワークドメインが接続されている通信インタフェースに対応して設定される前記移動端末のアドレスに係るバインディング情報を前記位置管理ノードに登録するステップを有する。
この方法により、外部ドメインに接続されている移動端末のバインディングアップデートを、ホームドメインに接続されているインタフェース経由で行うことが可能となる。
【００９４】
さらに、本発明の通信制御方法は、上記の処理に加えて、前記アドレス通知ステップにおいて、前記移動端末が、前記ホームドメインに接続されている通信インタフェースから前記ホームドメインに前記アドレスを通知する際に、前記アドレスをすぐに前記位置管理ノードに登録するよう要求するステップを有する。
この方法により、外部ドメインに接続されている移動端末のバインディングアップデートがホームドメインに接続されているインタフェース経由で行われる際に、迅速な登録処理が実現可能となる。
【００９５】
さらに、本発明の通信制御方法は、上記の処理に加えて、前記アドレス通知ステップにおいて、前記移動端末が、前記ホームドメインに接続されている通信インタフェースの存在を確認するステップを有する。
この方法により、外部ドメインに接続されている移動端末のバインディングアップデートを、ホームドメインに接続されているインタフェース経由で行う際に、移動端末は、ホームドメインに接続されているインタフェースの存在を確認したうえでアドレス通知を行うことが可能となる。
【００９６】
さらに、本発明の通信制御方法は、上記の処理に加えて、前記アドレス通知ステップにおいて、前記移動端末が、前記ホームドメインに接続されている通信インタフェースから前記ホームドメインに前記アドレスを通知する際に、前記アドレスの通知時刻を表す時間情報を、前記アドレスに係るバインディング情報に付加して前記位置管理ノードに通知するよう要求するステップを有する。
この方法により、外部ドメインに接続されている移動端末のバインディングアップデートの送信順序を示す指標となる時間情報が、位置管理ノードに確実に通知されるようになる。
【００９７】
また、本発明のネットワークノードは、上記の目的を達成するため、ネットワークベースのローカルモビリティ管理プロトコルが実装されているネットワークドメインを構成し、前記ネットワークドメインに接続されている移動端末の位置情報を管理する機能を有する位置管理ノードと、前記移動端末の位置情報の登録を代理して行う機能を有する代理登録ノードと、前記移動端末の認証を行う認証サーバとを有する通信システムにおいて、代理登録ノードとして機能するネットワークノードであって、
複数のプレフィックスに基づいて前記ネットワークドメインをホームドメインとする前記移動端末によって構成された複数のアドレスを前記移動端末から受信する手段と、
前記移動端末から通知された前記複数のアドレスのそれぞれに係るバインディング情報を前記位置管理ノードに登録する手段とを、
有する。
この構成により、移動端末が複数のプレフィックスによって構成されるアドレスを使い分けることができるようになる。また、移動端末が利用可能な複数のプレフィックスから構成されるアドレスを使い分けることで、ＰＭＩＰドメインに対してシグナリングの負荷をかけずに、コレスポンデントノードとの通信に係る経路を最適化できるようになる。
【００９８】
さらに、本発明のネットワークノードは、上記の構成に加えて、前記移動端末からの前記複数のプレフィックスの要求を受ける手段と、
前記移動端末からの前記複数のプレフィックスの要求に基づいて、前記複数のプレフィックスが前記移動端末に通知されるよう処理する手段とを、
有する。
この構成により、移動端末がＰＭＩＰドメイン内を移動する際に、アクセスルータから移動端末に対して複数のプレフィックスが提供されるようになる。
【００９９】
さらに、本発明のネットワークノードは、上記の構成に加えて、前記移動端末からの前記複数のプレフィックスの要求を受けた場合、前記認証サーバに前記移動端末の認証を依頼し、前記認証に成功した場合には、前記認証サーバから前記移動端末に割り当てられたドメインプレフィックスを受信するとともに、前記複数のプレフィックスを前記移動端末に通知する指示を前記認証サーバから受ける手段を有する。
この構成により、複数のプレフィックスを移動端末に通知することが可能か否かの判断を認証サーバに行わせることが可能となる。
【０１００】
さらに、本発明のネットワークノードは、上記の構成に加えて、前記移動端末に通知される前記複数のプレフィックスとして、前記ドメインプレフィックス、前記移動端末の接続ポイントのオンリンクプレフィックス、前記登録代理ノードのアドレス又はプレフィックスから選択する手段を有する。
この構成により、ネットワークノードから移動端末に、様々な状況に応じた通信経路の最適化を実現するための複数のプレフィックスの通知が行われるようにすることが可能となる。
【０１０１】
さらに、本発明のネットワークノードは、上記の構成に加えて、前記位置管理ノードに登録する前記移動端末の前記バインディング情報として、前記ホームアドレス又は前記ドメインプレフィックスと前記代理登録ノード自身のアドレス又はプレフィックスとを関連付ける第１のバインディング情報、及び、前記ホームアドレスと前記オンリンクアドレスとを関連付ける第２のバインディング情報を利用する手段を有する。
この構成により、ＰＭＩＰバインディング情報及びＣＭＩＰバインディング情報の両方が登録可能となる。
【０１０２】
さらに、本発明のネットワークノードは、上記の構成に加えて、前記移動端末から通知された前記複数のアドレスのそれぞれに係るバインディング情報を前記位置管理ノードに登録する際に、前記移動端末から通知された前記複数のアドレスのそれぞれに係るバインディング情報を含む１つの登録メッセージを生成し、前記位置管理ノードに送信する手段を有する。
この構成により、１回の登録メッセージの送信によって、複数のバインディング情報（例えば、ＰＭＩＰバインディング情報及びＣＭＩＰバインディング情報）の登録を行うことが可能となる。
【０１０３】
さらに、本発明のネットワークノードは、上記の構成に加えて、前記複数のアドレスのそれぞれに係るバインディング情報に対して、前記位置管理ノードにおける使用の優先度を設定する手段を有する。
この構成により、位置管理ノードにおいて優先的に参照されるバインディング情報を指定できるようになる。
【０１０４】
さらに、本発明のネットワークノードは、上記の構成に加えて、前記移動端末が複数の通信インタフェースを有しており、前記複数の通信インタフェースのうちの少なくとも１つが外部ネットワークドメインに接続されている場合に、前記外部ネットワークドメインが接続されている通信インタフェースに対応して設定されるアドレスの通知を前記移動端末から受ける手段を有する。
この構成により、外部ドメインに接続されている移動端末のバインディングアップデートを、ホームドメインに接続されているインタフェース経由で行うことが可能となる。
【０１０５】
さらに、本発明のネットワークノードは、上記の構成に加えて、前記アドレスの通知と共に前記アドレスに係るバインディング情報をすぐに前記位置管理ノードに登録するよう要求する情報を前記移動端末から受信する手段を有する。
この構成により、外部ドメインに接続されている移動端末のバインディングアップデートがホームドメインに接続されているインタフェース経由で行われる際に、迅速な登録処理が実現可能となる。
【０１０６】
さらに、本発明のネットワークノードは、上記の構成に加えて、前記バインディング登録手段は、前記移動端末から通知された前記アドレスに係るバインディング情報に、前記アドレスの通知時刻を表す時間情報を付加して前記位置管理ノードに登録するよう構成されている。
この方法により、外部ドメインに接続されている移動端末のバインディングアップデートの送信順序を示す指標となる時間情報が、位置管理ノードに通知されるようになる。
【０１０７】
さらに、本発明のネットワークノードは、上記の構成に加えて、前記アドレスの通知時刻を表す時間情報を前記アドレスに係るバインディング情報に付加するよう要求する情報を前記移動端末から受信する手段を有する。
この方法により、外部ドメインに接続されている移動端末のバインディングアップデートの送信順序を示す指標となる時間情報が、位置管理ノードに通知されるようになる。
【０１０８】
また、本発明の移動端末は、上記の目的を達成するため、ネットワークベースのローカルモビリティ管理プロトコルが実装されているネットワークドメインを構成し、前記ネットワークドメインに接続されている移動端末の位置情報を管理する機能を有する位置管理ノードと、前記移動端末の位置情報の登録を代理して行う機能を有する代理登録ノードと、前記移動端末の認証を行う認証サーバとを有する通信システムに接続可能であり、前記ネットワークドメインをホームドメインとする移動端末であって、
複数のプレフィックスを取得する手段と、
前記複数のプレフィックスから複数のアドレスを取得する手段と、
前記複数のアドレスを通知して、前記ネットワークドメイン内の前記移動管理ノードに前記複数のアドレスのそれぞれに係るバインディング情報を登録させる手段とを、
有する。
この構成により、移動端末がこれら複数のプレフィックスによって構成されるアドレスを使い分けることができるようになる。また、移動端末が利用可能な複数のプレフィックスから構成されるアドレスを使い分けることで、ＰＭＩＰドメインに対してシグナリングの負荷をかけずに、コレスポンデントノードとの通信に係る経路を最適化できるようになる。
【０１０９】
さらに、本発明の移動端末は、上記の構成に加えて、前記複数のプレフィックスを取得する手段が、
前記ネットワークドメインに接続する際に、複数のプレフィックスを要求する手段と、
前記複数のプレフィックスの要求に応じて通知される前記複数のプレフィックスを受信する手段とを、
有する。
この構成により、移動端末がＰＭＩＰドメイン内を移動する際に、アクセスルータから移動端末に対して複数のプレフィックスが提供されるようになる。
【０１１０】
さらに、本発明の移動端末は、上記の構成に加えて、前記複数のプレフィックスの要求に応じて受信したドメインプレフィックス及びグローバルプレフィックスから、前記ドメインプレフィックスを含むホームアドレスと、前記グローバルプレフィックスを含むグローバルアドレスとを構成する手段を有する。
この構成により、移動端末は複数のアドレス（例えば、ＰＭＩＰに基づくアドレス及びＣＭＩＰに基づくアドレスの両方）を構成することが可能となる。
【０１１１】
さらに、本発明の移動端末は、上記の構成に加えて、前記ホームアドレス及び前記グローバルアドレスの両方を通知するためのメッセージを生成し、前記移動端末が接続しているアクセスルータに前記メッセージを送信する手段を有する。
この構成により、移動端末は、アクセスルータにメッセージを送信する処理を行うだけで、移動端末の複数のアドレスの登録が行われるようになる。
【０１１２】
さらに、本発明の移動端末は、上記の構成に加えて、前記移動端末が前記ホームドメインに接続されている状態において、前記レガシのコレスポンデントノードや別のネットワークドメインに存在するコレスポンデントノードとの通信に、前記複数のプレフィックスのうちのドメインプレフィックスによって構成されたホームアドレスを使用することを決定する手段を有する。
この構成により、移動端末がホームドメインに接続されている状態において、レガシのコレスポンデントノードや別のネットワークドメインに存在するコレスポンデントノードとの通信経路が最適化されるようになる。
【０１１３】
さらに、本発明の移動端末は、上記の構成に加えて、前記移動端末が前記ホームドメインに接続されている状態において、同一の前記ホームドメインに接続されているコレスポンデントノードとの通信に、前記複数のプレフィックスのうちのオンリンクプレフィックスによって構成されたオンリンクアドレスを使用することを決定する手段を有する。
この構成により、移動端末がホームドメインに接続されている状態において、同一のホームドメインに接続されているコレスポンデントノードとの通信経路が最適化されるようになる。
【０１１４】
さらに、本発明の移動端末は、上記の構成に加えて、前記移動端末が前記ホームドメインに接続されている状態において、同一の前記ホームドメインに接続されているコレスポンデントノードとの通信に、前記複数のプレフィックスのうちの前記登録代理ノードのアドレス又はプレフィックスを使用することを決定する手段を有する。
この構成により、移動端末がホームドメインに接続されている状態において、同一のホームドメインに接続されているコレスポンデントノードとの通信経路が最適化されるようになる。
【０１１５】
さらに、本発明の移動端末は、上記の構成に加えて、前記移動端末が前記ホームドメインとは異なる外部ドメインに接続されている状態において、前記外部ドメインとは異なるドメインに存在するコレスポンデントノードとの通信に、前記外部ドメインから通知された外部ドメインプレフィックスにより構成された外部ドメインプレフィックスアドレスを使用することを決定する。
この構成に加えて、移動端末がホームドメインとは異なる外部ドメインに接続されている状態において、外部ドメインとは異なるドメインに存在するコレスポンデントノードとの通信経路が最適化されるようになる。
【０１１６】
さらに、本発明の移動端末は、上記の構成に加えて、前記移動端末が前記ホームドメインとは異なる外部ドメインに接続されている状態において、前記外部ドメインに存在するコレスポンデントノードとの通信における経路最適化処理に、前記外部ドメインから通知された外部ドメインプレフィックスにより構成された外部ドメインプレフィックスアドレスを使用することを決定する。
この構成により、移動端末がホームドメインとは異なる外部ドメインに接続されている状態において、外部ドメインに存在するコレスポンデントノードとの通信経路が最適化されるようになる。
【０１１７】
さらに、本発明の移動端末は、上記の構成に加えて、複数の通信インタフェースを有しており、
前記複数の通信インタフェースのうちの少なくとも１つが外部ネットワークドメインに接続されている場合に、前記アドレス通知手段が、前記外部ネットワークドメインが接続されている通信インタフェースに対応して設定されるアドレスを、前記ホームドメインに接続されている通信インタフェースから前記ホームドメインに通知するよう構成されている。
この構成により、外部ドメインに接続されている移動端末のバインディングアップデートを、ホームドメインに接続されているインタフェース経由で行うことが可能となる。
【０１１８】
さらに、本発明の移動端末は、上記の構成に加えて、前記アドレス通知手段が、前記ホームドメインに接続されている通信インタフェースから前記ホームドメインに前記アドレスを通知する際に、前記アドレスをすぐに前記位置管理ノードに登録する要求を行うよう構成されている。
この構成により、外部ドメインに接続されている移動端末のバインディングアップデートがホームドメインに接続されているインタフェース経由で行われる際に、迅速な登録処理が実現可能となる。
【０１１９】
さらに、本発明の移動端末は、上記の構成に加えて、前記アドレス通知手段が、前記ホームドメインに接続されている通信インタフェースの存在を確認するよう構成されている。
この構成により、外部ドメインに接続されている移動端末のバインディングアップデートを、ホームドメインに接続されているインタフェース経由で行う際に、移動端末は、ホームドメインに接続されているインタフェースの存在を確認したうえでアドレス通知を行うことが可能となる。
【０１２０】
さらに、本発明の移動端末は、上記の構成に加えて、前記アドレス通知手段が、前記ホームドメインに接続されている通信インタフェースから前記ホームドメインに前記アドレスを通知する際に、前記アドレスの通知時刻を表す時間情報を、前記アドレスに係るバインディング情報に付加して前記位置管理ノードに通知する要求を行うよう構成されている。
この方法により、外部ドメインに接続されている移動端末のバインディングアップデートの送信順序を示す指標となる時間情報が、位置管理ノードに確実に通知されるようになる。
【０１２１】
本発明は、上記の構成を有しており、移動端末がＰＭＩＰドメイン内を移動する際に、アクセスルータから移動端末に対して複数のプレフィックスが提供されるようになり、移動端末がこれら複数のプレフィックスによって構成されるアドレスを使い分けることができるようになるという効果を有する。また、本発明は、上記の構成を有しており、移動端末が利用可能な複数のプレフィックスから構成されるアドレスを使い分けることで、ＰＭＩＰドメインに対してシグナリングの負荷をかけずに、コレスポンデントノードとの通信に係る経路を最適化できるという効果を有する。
【図面の簡単な説明】
【０１２２】
【図１】本発明の実施の形態及び従来の技術を説明するためのネットワーク構成の一例を示す図
【図２】従来の技術における課題を説明するためのネットワーク構成の第１の例を示す図
【図３】本発明の実施の形態における動作の一例を示すシーケンスチャート
【図４】本発明の実施の形態におけるＭＣｏＡ登録メッセージ（ＭＣｏＡ ＢＵメッセージ）の構造の一例を示す図
【図５】本発明の実施の形態におけるモバイルノードの好適な構成の一例を示す図
【図６】本発明の実施の形態におけるモバイルノードの好適な動作の一例を示すフローチャート
【図７】本発明の実施の形態において、グローバルプレフィックスにより構成されるグローバルアドレスが経路最適化に使用された場合のＭＮとＣＮとの間のデータパケット伝送経路の一例を模式的に示す図
【図８Ａ】本発明の実施の形態において、複数のインタフェースを有するＭＮに係るバインディングがバルク登録を利用してアップデートされる際の動作の一例を示すシーケンスチャート
【図８Ｂ】本発明の実施の形態において、複数のインタフェースを有するＭＮに係るバインディングがバルク登録を利用してアップデートされる際の動作の別の一例を示すシーケンスチャート
【図９Ａ】本発明の実施の形態を説明するためのネットワーク構成の別の一例を示す図
【図９Ｂ】本発明の実施の形態を説明するためのネットワーク構成の更に別の一例を示す図
【図１０】本発明の実施の形態を説明するためのバインディングキャッシュの一例を示す図
【図１１Ａ】従来の技術における課題を説明するためのネットワーク構成の第２の例を示す図
【図１１Ｂ】従来の技術における課題を説明するためのネットワーク構成の第３の例を示す図
【図１１Ｃ】従来の技術における課題を説明するためのネットワーク構成の第４の例を示す図
【図１１Ｄ】従来の技術における課題を説明するためのバインディングキャッシュの一例を示す図
【発明を実施するための最良の形態】
【０１２３】
以下、図面を参照しながら、本発明の実施の形態について説明する。以下では、本発明に係る２つの主要な手法が開示される。【０１２４】
本発明の第１の手法では、３ＧＰＰ公共モバイルネットワークに配置されているＰＭＩＰｖ６ドメイン内のＭＮが、複数の異なるタイプのＣＮとの間における通信に関して、各通信に係る経路の最適化を可能とする複数の異なるタイプのプレフィックスを把握できるようにする。【０１２５】
例えば、ＰＭＩＰｖ６ドメインがＭＮのホームドメインである場合（ＭＮがホームＰＭＩＰｖ６ドメインに存在する場合）には、ＭＮは、レガシのＣＮとの通信や、インターネットや別のＰＭＩＰｖ６ドメインに接続されているＲＯ可能なＣＮとの通信のために、ホームプレフィックスを必要とする。また、ＭＮは、ＭＮのホームＰＭＩＰｖ６ドメイン内のＲＯ可能なＣＮとの間でＲＯを実行するために、オンリンクのグローバルプレフィックスを必要とする。一方、ＭＮが外部（foreign）ＰＭＩｖ６ドメインに存在している場合には、ＭＮは、他のドメインに存在しているＲＯ可能なＣＮとＲＯを実行するために、ＰＭＩＰｖ６ドメインプレフィックスを必要とし、同一の外部ＰＭＩＰｖ６ドメインに存在するＣＮとＲＯを実行するために、オンリンクのプレフィックスを必要とする。さらに、ＣＮとの位置関係によっては、ＲＯを実行するために、別の（若しくは別の用途で使っている）プレフィックスを使用したほうがより最適なＲＯを実行できる場合もある。【０１２６】
ＭＮは、異なるタイプのプレフィックスが必要なことを把握すると、様々なプレフィックスを取得するために、ＡＲに対して問い合わせを行う。そのＡＲがＭＡＧとしての機能も有している場合には、ＡＲはＡＡＡサーバに対して問い合わせを行う。ＡＡＡサーバは、ＭＮがＰＭＩＰｖ６ドメインに加入していることに気付くと、ＡＲ（すなわちＭＡＧ）に対して、異なるタイプのプレフィックスを提供するとともに、ＭＮに対してこれらのプレフィックスに関する適切な情報を提供するように要求する。ＭＮは、様々なタイプのプレフィックスに関する情報を用いて様々なタイプのアドレスを構成し、適切なタイプのアドレスを用いて各タイプのＣＮと通信を行う。【０１２７】
また、本発明の第２の手法では、ＬＭＡ及びＨＡが共存している（ＬＭＡ及びＨＡが同一ノードによって実現されている）ホームＰＭＩＰｖ６ドメイン内に存在しているＭＮが、ローカルブレイクアウト用にオンリンク気付アドレスを構成することを決定し、ＭＡＧが単一の登録メッセージをＭＮのＬＭＡ／ＨＡに送信できるようにするために、ＡＲに対して、この気付アドレスをＭＡＧに渡すように要求する。このＭＡＧからＬＭＡ／ＨＡに送信される登録メッセージは、ＭＮのホームアドレス及び気付アドレスをＣＭＩＰバインディングとして関連付けるとともに、ＭＮのＨｏＡ及びＭＡＧのイグレスインタフェースのアドレスをＰＭＩＰバインディングとして関連付けるものである。また、この登録メッセージは、ＢＵモビリティヘッダ内に、ＭＮが同時にホームにも接続されていることを示すフラグを有していることが望ましい。【０１２８】
こうしたバインディングによって、ＭＮのホームアドレスあてのパケットは、ＰＭＩＰバインディングで明示されているアドレス（ＭＡＧのイグレスインタフェースのアドレス）経由で送信されるようになる。また、ＭＡＧは、何らかの負荷バランス効果を得ようとする場合には、ＬＭＡ／ＨＡに対して、ＣＭＩＰバインディングの属性に基づいてＭＮの気付アドレスに直接パケットを渡すように要求してもよい。【０１２９】
以下、図３を参照しながら、本発明に係る上述の手法について説明する。図３には、本発明の実施の形態における動作の一例を示すシーケンスチャートが図示されている。なお、ここでは、ＭＮが、ＭＮのホームドメインであるＰＭＩＰｖ６ドメインに接続されており、ＲＯ可能なＣＮと通信を行っている場合について説明する。なお、このＲＯ可能なＣＮは、ＭＮと同一のＰＭＩＰｖ６ドメインに加入しており、現在、ＭＮと同一のＰＭＩＰｖ６ドメイン内に存在しているとする。また、このＣＮのホームドメインは別のドメイン（ＭＮのホームＰＭＩＰｖ６ドメインとは異なるドメイン）であるとする。また、ＡＲにＭＡＧの機能が実装されているとする。【０１３０】
図３では、ＭＮ３１０がＭＡＧ３２０に直接接続されており、ＣＮ３６０がＭＡＧ３５０に直接接続されている。また、これらのすべてのノードは、ドメイン内のＬＭＡ３３０及びＭＡＧによってＰＭＩＰサービスが提供されているＰＭＩＰｖ６ドメインに存在している。また、ＰＭＩＰｖ６ドメイン内のＡＡＡサーバ３４０は、ＭＮに対するＰＭＩＰサービスの提供を認証する機能を有している。このドメインは、３ＧＰＰセルラドメインや３ＧＰＰ ＷＬＡＮタイプのドメインであってもよく、その他の任意の種類のドメインであってもよい。【０１３１】
ＭＮ３１０は、ＭＡＧ３２０に接続されているサブネットワークにレイヤ２接続（Ｌ２接続）を行い、例えばメッセージ３６１（Ｌ２接続＋プレフィックス要求）によって利用可能なプレフィックスを要求する。ＭＡＧ３２０は、メッセージ３６１から、ＭＮ３１０のネットワークアクセス識別子（ＮＡＩ：Network Access Identifier）を抽出する。なお、ＮＡＩは、メディアアクセス制御（ＭＡＣ：Media Access Control）識別子などのＭＮ３１０を特定できるような値であってもよい。ＭＡＧ３２０は、抽出されたＮＡＩをＡＡＡサーバ３４０に渡し、ＡＡＡサーバ３４０で認証が行われる。このＭＡＧ３２０からＡＡＡサーバ３４０への問い合わせはメッセージ３６２（ＮＡＩ認証＋ＭＮタイプ問い合わせ）によって示されている。【０１３２】
このメッセージ３６２を受信したＡＡＡサーバ３４０は、例えばＭＮ３１０にＣＭＩＰクライアントスタックがインストールされていることを把握し（例えば、あらかじめ構成されたステータス情報を参照）、ＭＡＧ３２０に応答を行う。この応答は、メッセージ３６３（ＮＡＩ認証＋ＭＮタイプ応答）によって示されている。なお、ＭＮ３１０が複数の異なるタイプのプレフィックスを必要としていることをＡＡＡサーバ３４０が把握する方法に関しては、本発明では特に限定されるものではない。例えば、ＭＮ３１０が最初にＰＭＩＰｖ６ドメインに接続する際に、複数の異なるタイプのプレフィックスをネットワーク側に要求し、この要求に応じてネットワーク側が複数の異なるタイプのプレフィックスを提供するとともに、ＡＡＡサーバ３４０において、このＭＮ３１０は複数の異なるタイプのプレフィックスを必要としている旨を示すステータス情報がＰＭＩＰキャッシュエントリ内に保持されるようにしてもよい。これにより、以降にＭＮ３１０がＰＭＩＰｖ６ドメインに接続する際に、ＡＡＡサーバ３４０はこのステータス情報を参照し、このＭＮ３１０に対して複数の異なるタイプのプレフィックスを提供できるようになる。なお、ステータス情報と共に、どのタイプのプレフィックスを必要としているかを示す情報が保持されてもよい。また、例えばＭＮ３１０がＰＭＩＰｖ６ドメインのサービスを受ける旨の契約が行われた際に、複数の異なるタイプのプレフィックスの提供サービスが行われるように定められ、ステータス情報としてＡＡＡサーバ３４０にあらかじめ設定されてもよい。【０１３３】
このメッセージ３６３は、様々な情報を有している。第１に、このメッセージ３６３によって、ＭＮ３１０に割り当てられるＰＭＩＰｖ６ドメインのプレフィックスが伝搬される。第２に、このメッセージ３６３によって、ＰＭＩＰｖ６サービスの提供が承認された旨を示す情報が伝搬される。第３に、このメッセージ３６３によって、ＭＡＧ３２０に対して、様々なタイプのプレフィックスをＭＮ３１０に提供するように指示される。【０１３４】
ＭＡＧ３２０は、このメッセージ３６３を処理すると、例えば、ステートレスのアドレス構成モードでは、ルータ通知（ＲＡ：Router Advertisement）メッセージ３６４（ＲＡ（複数プレフィックスオプション））を送出する。ここで、ＲＡメッセージ３６４には、複数の異なるタイプのプレフィックスがオプションとして付加される。ＲＡメッセージ３６４に付加されている様々なタイプのプレフィックスは、例えば、ＭＡＧ３２０のオンリンクプレフィックスであってもよく、ＭＡＧ３２０のイグレスインタフェースのアドレスのプレフィックスであってもよく、このＰＭＩＰｖ６ドメインのローカルプレフィックスであってもよい。また、各タイプのプレフィックスの説明（どのタイプのプレフィックスかを示す情報）もＲＡメッセージ３６４に含まれ、ＭＮ３１０が、各プレフィックスのタイプを容易に把握できるようにすることが望ましい。また、上述の動作では、ＭＮ３１０からのメッセージ３６１による複数のプレフィックスの要求に応じて、ＭＡＧ３２０が複数のプレフィックスを含むＲＡメッセージ３６４の送信を行っているが、例えば、ネットワーク側とＭＮ３１０側との事前の協定によって、ＭＮ３１０があらかじめ把握（記憶）している複数のプレフィックスを読み出すことで複数のプレフィックスを取得してもよく、また、ＭＮ３１０からの要求を受けずにネットワーク側から利用可能な複数のプレフィックスが能動的に通知されるようにしてもよい。【０１３５】
ここで、ＭＮ３１０が、通信相手であるＣＮ３６０の現在の気付アドレスを把握しているとする。ＣＮ３６０はＭＮ３１０のホームＰＭＩＰｖ６ドメインに接続されているので、ＣＮ３６０の気付アドレスのプレフィックスは、ＭＮ３１０のホームアドレスのプレフィックスと類似することになる。例えば、プレフィックスが共有されるモデルが用いられている場合には、ＭＮ３１０のホームアドレスのプレフィックスと、ＣＮ３６０の気付アドレスのプレフィックスとは同一となる。また、ＭＮごとに固有のプレフィックスが与えられるモデルが用いられている場合には、ＭＮ３１０のホームアドレスとＣＮ３６０の気付アドレスとは、ある共通のビット数まで同一となる。こうしたアドレスのプレフィックスの比較を行うことで、ＭＮ３１０は、ＣＮ３６０が現在同一のドメイン内に存在するため経路最適化において問題が生じる可能性があることを把握し、ＣＮ３６０との間でＲＲシグナリングを行う。【０１３６】
なお、どの場合においても、ＭＮ３１０はＭＡＧ３２０のオンリンクプレフィックスを使用して、ローカルブレイクアウト用の気付アドレスを構成することが可能である。このようなローカルブレイクアウト用の気付アドレスが構成されると、ＭＮ３１０は、ＩＣＭＰのＮＡメッセージ３６５（ＮＡ（オンリンク気付アドレス））などを用いて、ＬＭＡ３３０へのＭＣｏＡ登録（Multiple CoA BU：複数の気付アドレスのバインディングアップデート）を行うようにＭＡＧ３２０に要求する。なお、このローカルブレイクアウトのアドレスがＮＡメッセージ３６５によって伝搬される場合には、ＮＡメッセージ３６５は、ホームアドレス及び気付アドレスの両方の情報（ＣＭＩＰバインディング）を埋め込むことが可能となるような構成を持つこととなる。【０１３７】
なお、本発明におけるＭＣｏＡ登録は、従来の１つのホームアドレスに対して複数の気付アドレスを登録する方法を拡張し、ＰＢＵによるＰＭＩＰバインディングの内容と従来のＢＵによりなされていたＣＭＩＰバインディングの内容とを併せて登録できるようにする。このとき、後述のようにローカルブレイクアウト用の気付アドレスの登録をＭＡＧのＰＢＵと併せて（一括して）行うように要求すると効率が良い。【０１３８】
このＮＡメッセージ３６５を送信することによって、ＭＮ３１０はＭＡＧ３２０に対して、ＬＭＡ３３０へのＭＣｏＡ登録を行うように指示又は要求する。ＬＭＡ３３０によるＭＣｏＡ登録では、ＭＡＧ３２０のイグレスインタフェースのアドレスが伝送され、ＭＮ３１０のホームアドレスプレフィックスや、さらにはＭＮ３１０の気付アドレスに関する情報も伝送される。ＭＣｏＡ登録メッセージ３６６（ＭＣｏＡ ＢＵ（ＭＮのＨｏＡ、ＭＮのＣｏＡ））がＬＭＡ３３０に送信され、ＬＭＡ３３０はＭＣｏＡ登録メッセージ３６６を受信すると、ＣＭＩＰバインディング及びＰＭＩＰバインディングの両方を生成する。ＣＭＩＰバインディングは、ＭＮ３１０のホームアドレスと、ＭＮ３１０のオンリンク気付アドレス（グローバルの気付アドレス）とのバインディングであり、ＰＭＩＰバインディングはＭＮ３１０のホームアドレスと、ＭＡＧ３２０のイグレスインタフェースのアドレスとのバインディングである。【０１３９】
また、ＭＮ３１０は、ＮＡメッセージ３６５を送信すると、ＣＮ３６０との間でＲＯ処理を開始する。ＭＮ３１０はＨｏＴＩ（Home Test Init）メッセージ３６７（ＣＮへのＨｏＴＩ）を送信する。なお、このＨｏＴＩメッセージ３６７の送信元アドレスはＭＮ３１０のＨｏＡである。したがって、このＨｏＴＩメッセージ３６７は、ＭＮ３１０のホームエージェントでもあるＬＭＡ３３０にトンネルされる。このトンネルされるメッセージはＨｏＴＩメッセージ３６８（ＣＮへのＨｏＴＩ）によって示される。ＭＮ３１０のホームエージェントとして動作するＬＭＡ３３０は、このＨｏＴＩメッセージ３６８をデカプセル化し、ＣＮ３６０のアドレスを探索する。このＣＮ３６０のアドレスは、ＬＭＡ３３０のＰＭＩＰキャッシュエントリ内に見つかり、ＬＭＡ３３０は、このＣＮ３６０のアドレスを用いて、ＣＮ３６０に接続されているＭＡＧ３５０にＨｏＴＩメッセージ３６９（ＣＮへのＨｏＴＩ）をトンネルする。ＨｏＴＩメッセージ３６９は、ＭＡＧ３５０によってデカプセル化された後、ＨｏＴＩメッセージ３７０（ＣＮへのＨｏＴＩ）としてＣＮ３６０に伝送される。【０１４０】
また、ＭＮ３１０は、ＣＮ３６０に対してＣｏＴＩ（Care-of Test Init）メッセージ３７１（ＣＮへのＣｏＴＩ）も送信する。なお、ＣｏＴＩメッセージ３７１の送信元アドレスはＭＮ３１０の気付アドレスであり、この気付アドレスはオンリンクプレフィックスから作られる。また、あて先アドレスはＣＮ３６０の気付アドレス（ＬＭＡ３３０から取得されたプレフィックスと同一又は類似）である。したがって、このＣｏＴＩメッセージ３７１は、ＰＭＩＰの場合のようなトンネルは行われず、図３に示されているようにＬＭＡ３３０によって受信（intercept）される。このＣｏＴＩメッセージ３７１のあて先アドレスはＣＮ３６０の気付アドレスであり、このあて先アドレスに関するＰＭＩＰバインディングを有するＬＭＡ３３０は、このＣｏＴＩメッセージ３７１を受信（intercept）して、ＣｏＴＩメッセージ３７２（ＣＮへのＣｏＴＩ）に示されるようにＭＡＧ３５０にトンネルする。そして、最終的に、ＭＡＧ３５０がＣｏＴＩメッセージ３７２を完全にデカプセル化して、内部のＣｏＴＩメッセージ３７３（ＣＮへのＣｏＴＩ）がＣＮ３６０に伝送される。なお、ＭＮとＣＮとの間に外部ＰＭＩＰドメインが介在している場合は、ホームドメインのＬＭＡのプレフィックスやオンリンクプレフィックスにかかわらず、外部ＰＭＩＰドメインにより構成されるトンネルを介する場合がある。【０１４１】
ＨｏＴＩメッセージ３７０及びＣｏＴＩメッセージ３７３を受信した後、ＣＮ３６０は、図３に図示されているように、ＨｏＴメッセージ３７４（ＭＮへのＨｏＴ）及びＣｏＴメッセージ３７８（ＭＮへのＣｏＴ）を送信する。なお、当業者であれば、これらのメッセージの経路は容易に把握可能であり、ＨｏＴメッセージ３７４〜３７７やＣｏＴＩメッセージ３７８〜３８０については詳細な説明は省略する。ここでは、ＨｏＴメッセージ３７４はＨｏＴＩメッセージ３７０の送信元アドレスに送信され、ＣｏＴメッセージ３７８はＣｏＴＩメッセージ３７３の送信元アドレスに送信されることが重要である。さらに、ＣＮ３６０は、ＨｏＴメッセージ３７４及びＣｏＴメッセージ３７８の送信元アドレスとして、気付アドレス（ＰＭＩＰドメインのプレフィックスに由来）を使用する。ＲＲテストが完了すると、ＭＮ３１０はＣＮに対してＢＵメッセージ３８１（ＣＮへのＢＵ）を送信することによって、ＣＮ３６０にＣＭＩＰバインディングを登録することが可能となる。ＢＵメッセージ３８１は、ＬＭＡ３３０からＭＡＧ３３０にトンネルされ（ＢＵメッセージ３８２）、ＭＡＧ３３０でデカプセル化されてＣＮ３６０に転送される（ＢＵメッセージ３８３）。【０１４２】
また、ＣＮ３６０の現在の気付アドレスのプレフィックス（ＰＭＩＰドメインのプレフィックス）及びＭＮ３１０のホームアドレスプレフィックスに何らかの類似性があることにＣＮ３６０が気付いた場合や、何らかのヒント（同一ＰＭＩＰドメインに存在していることを示す情報）がＬＭＡ３３０やＭＮ３１０から与えられている場合には、ＣＮ３６０は、オンリンク気付アドレスを使用してＭＮ３１０とＲＲ及びＢＵを行うことが可能である。これは、図３の処理３８４（ＲＲ及びＣＮからＭＮへのＢＵ）によって示されている。なお、ここでは、ＭＡＧ３５０によって通知されるＲＡメッセージによって複数のプレフィックスの通知が可能であり、ＣＮ３６０がオンリンクプレフィックスを選択して気付アドレスを構成できるとする。こうして双方向ＲＲが完了すると、ＭＮ３１０及びＣＮ３６０は、図３のメッセージ３８５（ＭＮとＣＮとの間における双方向データフロー）に示されているように最適化経路を経由したデータ通信を行う。なお、図３に図示されているＣＮ３６０に関しても、そのＣＮ３６０のＨＡ機能が同一のＬＭＡ３３０に実装されていてもよい。【０１４３】
次に、ＭＡＧの機能がＡＲに実装されていない場合の本発明の動作について説明する。以下、上述の場合（図３に係る動作）との違いについて説明する。このシナリオは、図１のＰＬＭＮ１に記載されているように、ｅＰＤＧの機能がＡＲではなくゲートウェイ（ＧＷ）に存在している場合に起こり得る。【０１４４】
このシナリオにおいても、ＭＮ１０がホームＰＭＩＰｖ６ドメイン内を移動しており、ＭＮ１０がＡＲ２０に接続されて、３ＧＰＰ ＡＡＡサーバ６０におけるアクセス認証を取得し、ｅＰＤＧ／ＭＡＧ４０によってＰＭＩＰｖ６ドメインのプレフィックスが取得されるとする。したがって、図３に係る動作と同様の動作が実現されるためには、ＡＲ２０とｅＰＤＧ／ＭＡＧ４０との間に何らかのインタラクションが行われる必要がある。【０１４５】
ＭＮ１０は、上述のようにＡＲ２０に対して複数のタイプのプレフィックスを要求する可能性があり、この場合、ＡＲ２０はこのリクエスト情報をｅＰＤＧ／ＭＡＧ４０に渡す。ｅＰＤＧ／ＭＡＧ４０は認証を行って、ＭＮ１０に関連するＰＭＩＰｖ６ドメインのプレフィックスをＡＲ２０に渡し、さらに、様々なタイプのプレフィックスを通知するようにＡＲ２０に要求する。この場合、ｅＰＤＧ／ＭＡＧ４０は、どのＡＲからＮＡＩ情報を受けたかに関する情報や、特定のＬＭＡプレフィックス又はＬＭＡプレフィックスから構成されたアドレスがどのＡＲに提供されるかに関する情報を保持する必要がある。【０１４６】
複数の異なるタイプのプレフィックスを受信した後、ＡＲ２０に接続されているＭＮ１０は、オンリンク気付アドレスを構成して、同一のＰＭＩＰｖ６ドメイン内に存在するＣＮとの間でＲＯを行うことが可能である。また、ＭＮ１０が、インターネットの任意のポイントに接続されているレガシのＣＮと通信を行うためにＰＭＩＰｖ６ドメインプレフィックスの使用を望む場合には、ＭＮ１０は、ＭＮ１０のＨｏＡを使用してパケットを送信する。この場合には、パケットはＭＮからＡＲ２０を経由してｅＰＤＧ／ＭＡＧ４０にトンネルされ、ｅＰＤＧ／ＭＡＧ４０がこのパケットをデカプセル化して、さらにＬＭＡ５０にトンネルする必要がある。なお、このとき、ＡＲ２０からｅＰＤＧ／ＭＡＧ４０へのトンネリングが必要になったり、特定のＭＮ１０がどのＡＲ２０に接続されているかという状態をｅＰＤＧ／ＭＡＧ４０が保持する必要があったりするが、複数のｅＰＤＧ／ＭＡＧ４０を配置してｅＰＤＧ／ＭＡＧ４０とＡＲ２０とを１対１に対応させることで、こうした事項を解消することが可能である。【０１４７】
図３に係る動作では、ＭＡＧ／ＡＲが、ＭＮのホームエージェント（ＰＭＩＰｖ６ドメインのＬＭＡでもある）にＭＣｏＡ登録を行う場合について説明されている。こうしたＭＣｏＡ登録は、通常、負荷バランスを行うために有用である。また、図３において、ＣＮ３６０が異なるホームドメインを有しているとすると、ＣＮ３６０はＬＭＡ３３０に対して、上述のようなＢＵストームの問題の解消を目的としたＭＣｏＡ登録の要求を行う必要はない。しかしながら、ＬＭＡ３３０がＣＮ３６０に関する負荷バランスを行いたい場合に、ＣＮ３６０がＭＡＧ３５０に対して、ＬＭＡ３３０へのＭＣｏＡ登録を行うよう要求することも可能である。ＭＡＧ３５０がＭＣｏＡ登録を送信することで、ＣＮ３６０のＰＭＩＰｖ６ローカルドメインアドレスがＭＡＧ３５０のアドレスと関連付けられるとともに、ＣＮ３６０のオンリンクグローバルアドレスがＣＮ３６０のＰＭＩＰｖ６ローカルドメインアドレスと関連付けられることになる。なお、この場合には、ＬＭＡ３３０と、外部（foreign）ＰＭＩＰｖ６ドメイン内に存在しているＣＮ３６０との間において、相互にセキュリティアソシエーションが確立されることで、こうしたバインディングが設定される必要がある。【０１４８】
また、ＭＡＧ３２０のプレフィックスを用いて、ＣＮ３６０と通信を行うためのローカルブレイクアウト用のアドレスが構成されてもよい。ＭＮ３１０が、ＭＡＧ３２０のイグレスインタフェースのアドレスを使用してローカルブレイクアウト用のグローバルアドレスを構成した場合には、ＭＮ３１０はそのアドレスに関してＤＡＤを実行する必要がなくなるという利点がある。【０１４９】
また、ＭＮ３１０が、ＭＡＧ３２０のプレフィックスを使用して、ローカルブレイクアウト用のグローバルアドレスを構成した場合には、ＭＡＧ３２０が、ＭＮ３１０のアドレスに係るＤＡＤを実行する必要がある。なお、この場合には、ＭＡＧ３２０が接続されているサブネットワーク内でＤＡＤシグナリングストームが発生する可能性があり、ＭＡＧ３２０がこれらのアドレスに関して近隣探索プロキシシグナリング（ＮＤプロキシシグナリング）を実行する必要がある。また、ＭＡＧ３２０に接続されているＭＮすべてがローカルブレイクアウト用のアドレスを使用した場合には、ＭＡＧ３２０は、ＭＮに対して正しくパケットを発送するために、何らかの情報を保持するとともに、各ＭＮに接続されているＣＮに関するステータスを保持する必要があり、さらに、ＭＡＧ３２０は、データパケット発送前にデータパケットの送信元アドレスをチェックする必要がある。こうした動作を行うためには、ＭＡＧ３２０は高い処理能力や容量の大きなメモリを有する必要がある。【０１５０】
さらに、ＭＡＧ３２０に接続されているＭＮすべてがローカルブレイクアウト用のアドレスとしてＭＡＧアドレスを使用した場合には、ＭＮは、移動するたびに（ＭＡＧが変更されるたびに）ＣＮのリストをＭＡＧに渡さなければならない可能性がある。また、例えば多数のＭＮが１つのＣＮと通信を行っている場合のように、ＭＡＧ配下の多数のＭＮが共通のＣＮを有している場合には、ＭＡＧがデータパケットを発送するＭＮを特定することが困難になってしまう可能性がある。このような場合、ＭＡＧは、データパケットを正確に発送するために、ＭＮのホームアドレス情報を保持し、このホームアドレスの所有権を検証する処理を行う必要がある。【０１５１】
次に、図３に図示されているＭＡＧ３２０からＬＭＡ３３０に送信されるＭＣｏＡ登録メッセージのパケット構造について詳細に説明する。ＭＮが１つ又は複数のインタフェースに関連付けられた複数の気付アドレスを有する場合、ＭＮは、負荷バランスやフォールトトレランス、信頼性、優先度設定などの様々な設定を行うことを目的として、これらの気付アドレスをホームエージェントに登録しようとする。【０１５２】
例えば、ある１つのホームアドレスに対して１つの気付アドレスのバインディングが登録可能な登録メッセージをそれぞれ個別に複数回送信することによって、複数の気付アドレスの登録メッセージの送信が行われるようにしてもよく、また、複数の気付アドレス（ＭＣｏＡ）の登録メッセージがまとめて送信されることで、１回の登録によって、１つのホームアドレスと複数の気付アドレスとのバインディングが登録されるようにしてもよい。なお、後者の複数の気付アドレスの一括登録はバルク登録（bulk registration）と呼ばれる。【０１５３】
ＭＣｏＡ登録メッセージ（ＭＣｏＡ ＢＵメッセージ）においては、基本的にＢＩＤオプションが使用される。このＢＩＤオプションは、バインディングを特定する識別情報であり、これによって、ＨＡは、ある単一のホームアドレスに関する複数のバインディングを識別し、他のインタフェースから送られてくる登録によってバインディングの上書きが行われないようにすることが可能となる。さらに、ＢＩＤオプションによって、ＭＮの個々のインタフェースを識別できるようになる。【０１５４】
このＢＩＤオプションは、優先度フィールドを有している。この優先度フィールドは、複数の気付アドレスの中から特定の気付アドレスが使用されるようにするため、ＨＡにおける使用の優先度をＭＮが設定するためのものである。また、バルク登録では、１つの登録メッセージ内に複数のＢＩＤオプションが挿入されるので、各ＢＩＤオプションに気付アドレスフィールドが設けられる。一方、個別登録によるＭＣｏＡ登録では、登録メッセージの送信元アドレスによってその気付アドレスが伝送されるので、必ずしもＢＩＤオプションが気付アドレスフィールドを有する必要はない。【０１５５】
図３に図示されているＭＣｏＡ登録では、ＭＣｏＡ登録は１回の登録で行われており、バルク登録の使用が適切である。ここでは上述のように、ＰＭＩＰバインディング及びＣＭＩＰバインディングの両方が行われる。図４には、ＰＭＩＰバインディング及びＣＭＩＰバインディングの両方を行うためのＭＣｏＡ登録メッセージのパケット構造の一例が図示されている。このＭＣｏＡ登録メッセージは非特許文献２に記載されているようなＰＢＵメッセージであり、例えばＣＭＩＰバインディングが更に挿入可能となるようなフィールドが設定される必要がある。このＭＣｏＡ登録メッセージを受信したＨＡは、ＣＭＩＰバインディングパラメータを伝搬する追加オプションを参照して、ＰＭＩＰバインディング及びＣＭＩＰバインディングの両方を生成する。【０１５６】
図４には、バルク登録タイプのＭＣｏＡ登録メッセージ３９０が図示されている。このＭＣｏＡ登録メッセージ３９０は、ＭＡＧのイグレスインタフェースのアドレスを含む送信元アドレスフィールド３９１、ＬＭＡのアドレスを含むあて先アドレスフィールド３９２を有している。また、認証ヘッダ３９３には、ＭＡＧとＬＭＡとの間のセキュリティアソシエーションから生成された認証データが含まれている。【０１５７】
ＭＣｏＡ登録メッセージ３９０には更にモビリティヘッダ３９４が含まれている。このモビリティヘッダ３９４は、バインディングアップデートを行うためのものであり、非特許文献２に開示されているようなＰＭＩＰに関連した新しいタイプのものである。【０１５８】
このモビリティヘッダ３９４の中には、ＮＡＩオプション３９５が存在している。このＮＡＩオプション３９５は、ＬＭＡにおいてＰＭＩＰタイプのバインディングが生成されるためにＮＡＩを伝搬するものである。なお、ＰＭＩＰバインディングでは、ＰＭＩＰキャッシュがＭＮのホームアドレス値を有しておらず、ＮＡＩのみが使用されている場合もあり、ＮＡＩオプション３９５は、ＰＭＩＰバインディングにおいて必須のオプションであると言える。【０１５９】
また、モビリティヘッダ３９４の中には、ＭＮホームプレフィックスオプション３９６が含まれている。このＭＮホームプレフィックスオプション３９６は、ＭＮごとに個別のプレフィックスが提供される場合にＭＮ固有のホームプレフィックスを伝搬し、共有プレフィックスが提供される場合には、ＭＮのホームアドレス又は、共有プレフィックスの値を伝搬する。【０１６０】
また、ＭＣｏＡ登録メッセージ３９０における最後のオプションとして、ＢＩＤオプション３９７が存在する。このＢＩＤオプション３９７においては、気付アドレスフィールドにＭＮのオンリンク気付アドレスが挿入される。さらに、ＭＡＧがデカプセル化処理の負荷を軽減しようとするために気付アドレスのバインディング（すなわちＣＭＩＰバインディング）を高優先度に設定したくない場合には、例えばＢＩＤオプション３９７の優先度設定を“０”に設定することで、この気付アドレスのバインディング又はＣＭＩＰバインディングが使用されないようにしてもよい。【０１６１】
また、ＭＮがオンリンク気付アドレス用にＭＡＧのアドレスを使用する場合には、ＭＡＧからＬＭＡに対して、ＢＩＤオプションが挿入されない通常のＰＢＵメッセージが送信されてもよい。しかしながら、このＰＢＵメッセージには、ＭＮに関してＰＭＩＰバインディング及びＣＭＩＰバインディングの両方のタイプのバインディングが作成される必要があることをＨＡ／ＬＭＡに示すためのフラグが備わっていることが望ましい。なお、これを実現するため、ＭＡＧはホームフラグをオプションとして設定してもよく、また、このＰＢＵ（フラグが設定されていない場合であっても）を受信したＬＭＡが、ＭＮが同時にホームに接続されている状態であると推測してもよい。ＬＭＡは、このＭＣｏＡの登録を受信すると、ＭＮが同時にホームに接続されている状態にあるとして処理を行う。このＭＣｏＡの登録に係る処理では、ＰＭＩＰバインディングの登録と、ホームに同時に接続されている際にＣｏＡをＨｏＡに関連付けるＭＣｏＡのＣＭＩＰバインディングの登録が行われる。【０１６２】
次に、ＬＭＡの動作について説明する。データパケットがＭＮのアドレス（ＬＭＡのプレフィックスから構成されている）に伝送される場合には、ＬＭＡがこのパケットを受信（intercept）して、バインディングキャッシュをチェックする。ここで、ＭＮのＰＭＩＰｖ６ドメインのローカルアドレスに関連して、例えばＰＭＩＰバインディング及びＣＭＩＰバインディングなどの複数のバインディングが存在する場合には、通常、ＬＭＡはＰＭＩＰバインディングを使用してパケットのトンネルを行う。これは、上述のように、ＣＭＩＰバインディングの優先度が通常は低く設定されることによる。ＰＭＩＰバインディングを使用したトンネルにおいて、ＬＭＡは、通常、ＭＮが接続されているＭＡＧのアドレスにデータパケットをトンネルする。しかしながら、ＭＡＧは、デカプセル化処理の負荷を軽減するために、ＭＮのＰＭＩＰｖ６ドメインのプレフィックスのアドレスあてに届くパケットが、ＬＭＡからＭＮのオンリンクアドレスにトンネルされるようにしてもよい。【０１６３】
ＭＡＧがこのような動作を必要とする場合には、例えば上述のように、ＭＡＧは、ＭＣｏＡのＣＭＩＰバインディングに関する登録の優先度を高く設定することによって、ＬＭＡに対してこの動作を行うように要求することが可能である。このようなＢＵは、例えばＭＡＧがＣＭＩＰバインディングに係るＢＩＤオプションの優先度の値を“２５５”に設定することによって実現される。このような高優先度のＣＭＩＰバインディングが存在する場合には、ＬＭＡは、ＣＭＩＰバインディングを使用してデータパケットをＭＮに直接転送する。ＣＭＩＰバインディングを使用してトンネルを行うことで、パケットはＭＮのオンリンク気付アドレスにトンネルされるようになる。【０１６４】
次に、本発明の実施の形態におけるＭＮの構成について説明する。ＭＮはマルチホーミング機能を有し、複数のプレフィックスの処理を行って、１つのインタフェースに関連付ける複数の気付アドレスを構成することが可能である。図５には、本発明の実施の形態におけるＭＮの構成の一例が図示されている。ＭＮ４００は、本発明を実現するため、ＩＰｖ６に関連するプロトコルスタックを実装するために必要なすべてのソフトウェア、ハードウェア、ファームウェアを有している。なお、図５に図示されているＭＮ４００は、マルチホーミング機能を有している。【０１６５】
また、下位レイヤプロトコル（ネットワークインタフェース）４０１は、すべての物理層及びリンクレイヤプロトコルを有している。また、ＭＮ４００のルーティングレイヤプロトコル４０２は、ルーティングに関連したすべてのプロトコルを有している。また、上位レイヤプロトコル４０３はすべてのトランスポートレイヤプロトコル及びアプリケーションレイヤプロトコルを有している。【０１６６】
ルーティングレイヤプロトコル４０２及び上位レイヤプロトコル４０３は、インタフェース４０５を通じてメッセージの受け渡しを行う。また、下位レイヤモジュール４０１及びルーティングレイヤプロトコル４０２は、インタフェース４０４を通じてメッセージの受け渡しを行う。また、ルーティングレイヤプロトコル４０２は、ＩＰｖ６ルーティングモジュール４０８、ＭＩＰｖ６モビリティ管理モジュール４０９、プレフィックス選択モジュール４１０を有している。【０１６７】
プレフィックス選択モジュール４１０は、ＭＮが必要とする複数のプレフィックスを判断し、さらに、どのタイプのＣＮとの通信にどのプレフィックスを使用すべきかを決定する。なお、このプレフィックス選択モジュール４１０は、ＭＩＰｖ６モビリティ管理モジュール４０９とインタラクションする。複数の気付アドレスを構成する際には、ＭＩＰｖ６モビリティ管理モジュール４０９は近隣探索（Neighbor Discovery）機能に対して、ＭＮが構成したオンリンク気付アドレスを含む近隣通知ＩＣＭＰメッセージをＡＲに送信するように要求する。プレフィックス選択モジュール４１０は、インタフェース４０７を通じてＭＩＰｖ６モビリティ管理モジュール４０９４０９とインタラクションし、ＩＰｖ６ルーティングモジュール４０８は、インタフェース４０６を通じてＭＩＰｖ６モビリティ管理モジュール４０９とインタラクションする。また、インタフェース４０７を通じてプレフィックス情報が伝送され、ＭＩＰｖ６モビリティ管理モジュール４０９は、提供されたプレフィックスに関連する気付アドレスを構成することが可能である。【０１６８】
次に、図６に図示されているフローチャートを参照しながら、上述のプレフィックス選択モジュール４１０における動作の一例について説明する。ここでは、ＭＮが、ＰＭＩＰｖ６プロトコルが導入されているローカルモビリティ管理セグメントを移動しているとする。【０１６９】
図６において、ＭＮはあるドメイン内に移動すると、まずステップＳ５００において、そのドメインがホームドメイン（ホームＰＭＩＰｖ６ドメイン）か否かをチェックする。ＭＮがホームドメイン内に移動した場合には、ステップＳ５０１が実行される。【０１７０】
ＭＮは、ＣＮのリストを有しており、ステップＳ５０１においてそのリストの中からＣＮを１つ選択し、そのＣＮと通信を行うためには、どのタイプのアドレスを構成する必要があるかを判断する。ここでは、ＭＮはＣＮのタイプを分類しており、ステップＳ５０２において、ＣＮがレガシタイプか否かの判断（レガシＣＮかＲＯ可能ＣＮのいずれかであるかの判断）ができるものとする。【０１７１】
ステップＳ５０２において、そのＣＮがレガシタイプであると判断された場合には、ステップＳ５０３が実行される。ＭＮはホームドメインに存在しているので、レガシＣＮとの通信にはホームプレフィックスを使用して構成されたアドレスを使用することで、ルーティングパスはほぼ最適化される。すなわち、ステップＳ５０３において、ＭＮは、ホームプレフィックスを使用してＣＮ（レガシＣＮ）と通信を行うためのホームアドレスを構成する。【０１７２】
一方、ステップＳ５０２でＣＮがレガシタイプではないと判断された場合には、ステップＳ５０４において、ＭＮは、ＭＮに通知されているＣＮの現在のアドレス（気付アドレス）が、ＭＮのホームドメインに属するか否かの確認が行われる。【０１７３】
ステップＳ５０４を実行し、ＭＮに通知されているＣＮの現在のアドレス（気付アドレス）が、ＭＮのホームドメインに属していないことが確認された場合には、ステップＳ５０３において、ＭＮは、ＭＮのホームプレフィックスを使用してＣＮ（ＲＯ可能なＣＮ）との通信を行うためのホームアドレスを構成する。すなわち、ＣＮはＲＯ可能であっても別のドメイン（外部ドメイン）に存在している場合には、通常は、ホームアドレスを用いた通信によって、このＣＮとのＲＯが実現される。なお、ＬＭＡがデフォルトのルーティングパス上に存在しない場合もあり、この場合には、後述のように完全な状態のＲＯは実現されない可能性がある。また、この場合はＣＮがＲＯ可能なので、ＭＮはＣＮとの通信において、オンリンク気付アドレスによるＲＯ通信を行うように決定してもよい。【０１７４】
一方、ステップＳ５０４でＭＮに通知されているＣＮの現在のアドレス（気付アドレス）が、ＭＮのホームドメインに属していることが確認された場合には、ＭＮはステップＳ５０５を実行する。すなわち、ＣＮが同一ホームドメイン内に存在していることを把握した場合には、ステップＳ５０５において、ＭＮのプレフィックス選択モジュール４１０が、このＲＯ可能なＣＮとＲＯ通信を行うために、オンリンク気付アドレスを使用することを決定し、オンリンクプレフィックスを使用してオンリンク気付アドレスを生成し、適切なＮＡメッセージ（オンリンク気付アドレスを含む）をＡＲに送信するようＭＩＰｖ６モジュール４０９に要求する。なお、この場合のＮＡメッセージには、ホームアドレス及びオンリンク気付アドレスが含まれている。これによって、ＭＣｏＡのＢＵメッセージの送信がＭＮからＭＡＧに要求される。【０１７５】
また、ステップＳ５００において、ＭＮの移動先のドメインがホームドメインではない場合、ＭＮは外部ドメイン（foreign domain）に存在していることを意味する。この場合、ＭＮは、ステップＳ５０６において、ＣＮのアドレスのリストを参照して、ＣＮのアドレスのリストからＣＮを１つ選択する。そして、ＭＮは、ステップＳ５０７において、ＣＮのアドレスが、ＭＮが存在している外部ドメインと同一の外部ドメインに関連しているか否かを判断する。【０１７６】
ステップＳ５０７で、ＣＮのアドレスが、ＭＮが存在している外部ドメインと同一の外部ドメインに関連していると判断された場合、ステップＳ５０８において、ＭＮのプレフィックス選択モジュール４１０がオンリンク気付アドレスを使用することを決定し、オンリンクプレフィックスを使用してオンリンク気付アドレスを生成し、適切なＮＡメッセージ（オンリンク気付アドレスを含む）をＡＲに送信するようＭＩＰｖ６モジュール４０９に要求する。【０１７７】
一方、ステップＳ５０７で、ＣＮのアドレスが、ＭＮが存在している外部ドメインと同一の外部ドメインに関連していないと判断された場合（すなわち、ＭＮとＣＮが異なるドメインに位置している場合）には、ステップＳ５０９において、ＣＮがレガシタイプか否かの判断が行われる。【０１７８】
ステップＳ５０９でＣＮがレガシタイプであると判断された場合には、ステップＳ５１０が実行される。ＭＮが外部ドメインに存在する場合には、ＭＮとレガシＣＮとの通信において、ローカルブレイクアウトが実現されることで通信経路の効率化を図ることが可能である。これを実現するためには、例えば、ＭＮは、レガシＣＮとの通信に用いるホームアドレスとして、外部ＰＭＩＰｖ６ドメインで取得されるアドレスを使用すればよい。すなわち、ＭＮは、ステップＳ５１０において、外部ＰＭＩＰドメインのプレフィックスを使用してアドレスを構成し、このアドレスをホームアドレスとして、ＭＩＰｖ６モジュール４０９に対して適切なＮＡメッセージを送信するよう要求する。【０１７９】
一方、ステップＳ５０９でＣＮがレガシタイプではないと判断された場合には、ステップＳ５１１が実行される。ＣＮが別のＰＭＩＰｖ６ドメインに存在しているのであれば、ＭＮは外部ＰＭＩＰｖ６プレフィックスを使用して取得される気付アドレスを用いて、このＣＮとの間でＲＯを実行してもよい。すなわち、この場合には、アドレスを構成する際にＰＭＩＰｖ６ドメインプレフィックスが使用されるか否か、更にはＲＯを行うか否かが決定される。例えばステップＳ５１１において、ＭＮは、このＣＮとの通信を行うために、ＬＭＡのアドレスのプレフィックスを使用して気付アドレスを生成する。【０１８０】
次に、ローカルブレイクアウト用のプレフィックスが使用される場合やＭＮのオンリンクグローバルプレフィックスがＲＯに使用される場合のＭＮとＣＮとの間の通信におけるデータパケットの伝送経路について説明する。【０１８１】
図７において、ＭＮ６１０は、ホームドメインでもあるＰＭＩＰｖ６ドメイン６００に接続されている。ＭＮ６１０は、オンリンクプレフィックス（経路最適化のためにＭＡＧ６２０から通知される）からオンリンク気付アドレスの構成を行う。なお、基本的に、ＭＮ６１０は、ホームアドレス及びオンリンク気付アドレスの両方を構成する。【０１８２】
また、図７において、ＭＮ６１０はＣＮ６１１、６１２、６１３と通信を行っている。これらすべてのＣＮ６１１、６１２、６１３がＲＯ可能なＣＮであり、ＲＲメカニズムを用いて、ＭＮ６１０とＣＮ６１１、６１２、６１３のそれぞれとの間でＲＯパスが確立されているとする。さらに、ＭＮ６１０はＭＡＧ６２０に接続されており、ＣＮ６１１はＭＡＧ６２１に接続されており、ＣＮ６１２はＭＡＧ６２２に接続されているとする。すなわち、ＣＮ６１１及びＣＮ６１２は両方共、同一のＰＭＩＰｖ６ドメイン６００に接続されている。【０１８３】
また、ＬＭＡ／ＨＡ／ＳＡＥアンカ６３０は、ＰＭＩＰｖ６ドメイン６００内のすべてのＭＮに対してＰＭＩＰｖ６ドメインプレフィックスを割り当てる。また、ＭＡＧ６２０とＭＡＧ６２１は固定ルータ６７０を通じて接続されている。さらに、ＬＭＡ／ＨＡ／ＳＡＥアンカ６３０は、ＭＡＧ６２０とＭＡＧ６２２と間のデフォルトのルーティングパス上には位置していないとする。したがって、ＭＮ６１０からＣＮ６１１への通信経路は、ＭＡＧ６２０から固定ルータ（fixed router）６７０及びＭＡＧ６２１を経由するパス６５２となる。また、ＭＮ６１０からＣＮ６１２へのデータ通信経路は、ＢＲ（Border Router：ボーダルータ）６４０及びＢＲ６４１を経由するパス６５１である。また、ＭＮ６１０からＣＮ６１３へのデータ通信経路は、ＭＡＧ６２０からＢＲ６４０を経由するパス６５０である。【０１８４】
ここで、ＰＭＩＰｖ６ドメイン６００に接続されているＣＮが、ＰＭＩＰｖ６ドメインに加入していないＣＮであるとする。この場合、ＣＮはＰＭＩＰサービスを受けず、オンリンク気付アドレスを取得する。しかしながら、ＰＭＩＰサービスを受けていないにもかかわらず、ＭＮ６１０とＣＮ６１１及びＣＮ６１２とのデータ通信経路は、ＣＮ６１１及びＣＮ６１２が接続されているＭＡＧ６２１及びＭＡＧ６２２のそれぞれに応じたパス６５１及びパス６５２となる。【０１８５】
３ＧＰＰのＰＭＩＰｖ６ドメインでは、あるオペレータによってＷＬＡＮのような信頼性の無いアクセスネットワークが所有されている一方、３ＧＰＰのコアネットワーク（ＬＭＡはコアネットワーク内に存在すると仮定される）は別のオペレータによって所有されている場合が起こり得る。ＭＮが同一アクセスネットワーク上のＣＮとの間でローカルブレイクアウトを実行する場合、データはパス６５１を経由することになる。すなわち、トラフィックは、コアネットワークを通過する必要はなく、インターネットを通過することになる。なお、ＰＭＩＰｖ６ドメインのプレフィックスが使用されている場合のみ、トラフィックは、ＬＭＡが存在するコアネットワーク経由する必要がある。【０１８６】
また、ＰＭＩＰｖ６ドメインにおいて、ＭＮは、移動後にトンネリングを行わずにＣＮとの間で完全な経路最適化を実現したい場合もある。このような場合には、ＭＮはＭＡＧ／ＡＲと協同して、ＭＡＧ／ＡＲからオンリンクプレフィックスのみを要求する。さらに、ＭＮはＭＡＧ／ＡＲに対して、ＭＮがＰＭＩＰｖ６サービスを所望していない旨を通知する。なお、ここでは、ＭＮは、このドメインによって提供されるＰＭＩＰｖ６サービスを取得できる資格を有しているとする。このような場合には、ＭＮは、オンリンクプレフィックスを使用して気付アドレスを構成し、ＣＮとの間でＲＯを行う。ＭＮがＰＭＩＰｖ６サービスを所望しない場合、ＭＮが有する気付アドレスは、オンリンクプレフィックスから構成された気付アドレスのみとなり、ＭＮは、サブネットワークを変更するたびにホームエージェントにアップデートを行う必要がある。【０１８７】
また、以下では、本発明を実現する上述の実施の形態とは異なる実施の形態として、従来の技術（図１１Ａ）で説明されているような複数のバインディングの登録（マルチ登録）に関連する問題（例えば、ＰＢＵとＢＵの競合に関する問題）や、バインディングアップデートが経由する長距離のパスに関連する問題を解決する方法について説明する。【０１８８】
ここで説明する実施の形態における方法は、外部ドメインに接続されているインタフェース経由でそのインタフェースに関連するバインディングアップデートを送信する代わりに、外部ドメインに接続されているインタフェースに関連するＣＭＩＰのＢＵ登録のコンテンツ（内容）を、ホームドメインに接続されているＭＡＧへ（ホームに接続されているインタフェース経由で）渡すものである。このとき、ＭＡＧは、ＭＮの複数のインタフェースに係る到達可能状態を通知するＰＭＩＰ及びＣＭＩＰを組み合わせたバルク登録を送信するよう構成される。この方法を実行することによって、複数の位置更新シグナリングの伝送が回避され、ホームドメインに接続されたインタフェース経由で、より迅速なＣＭＩＰのＢＵ登録が実現される。【０１８９】
以下、この実施の形態における方法について、図８Ａを参照しながら説明する。図８Ａにおいて、ＭＮ７００は２つのインタフェースを有している。ＭＮ７００のインタフェース１（ＩＦ１）はＭＡＧ７０５を通じて外部ドメインに接続されている。ＭＮ７００は、ＭＡＧ７０５に接続する場合には、ＭＡＧ７０５からＲＡ７１１を受信した後に、ＲＡ７１１に含まれる外部プレフィックスからＩＦ１に関する気付アドレスを構成する。また、ＭＮ７００は、インタフェース２（ＩＦ２）を通じて、ホームＰＭＩＰドメインのＷＬＡＮアクセスネットワークのＭＡＧ７０６に接続する。なお、図８Ａでは、ＭＮ７００はホームＰＭＩＰドメインとＷＬＡＮに係るアクセス技術で接続しているが、任意のアクセス技術でＭＡＧと接続可能である。【０１９０】
ＭＮ７００は、ＩＦ２においては、まずＷＬＡＮアクセスネットワークのＭＡＧ７０６からビーコン信号（ＷＬＡＮビーコンシグナル）７１２を受信する。ＭＮ７００は、メッセージ（Ｌ２接続シグナル）７１３によってＬ２接続を行う場合、このメッセージ７１３と共にＩＦ１に関連するＣＭＩＰのＢＵの内容をＭＡＧ７０６へ渡すことが可能である。なお、ＭＮ７００は、メッセージ７１３にＩＦ１に関連するＣＭＩＰに関するＢＵのコンテンツを挿入してもよく、あるいは、メッセージ７１３とは異なる別のメッセージにＩＦ１に関連するＣＭＩＰに関するＢＵのコンテンツを挿入して送信してもよい。また、ＭＮ７００は、ＩＦ２がホームＰＭＩＰドメインに接続しているかもしれないという情報を把握したうえで、ＩＦ１に関連するＣＭＩＰのＢＵのコンテンツをＭＡＧ７０６へ渡すようにしてもよい。なお、ＭＮ７００は、ＩＦ２に関する最新のローミングプロファイル情報を保持し、保持されている情報に基づいてＩＦ２がホームＰＭＩＰドメインに接続しているか否かを判断してもよく、あるいは、ＩＦ２がホームＰＭＩＰドメインに接続されていると単に推定するだけでもよい。また、ＩＦ２が接続しているドメインから取得可能な情報を参照することで、ＩＦ２がホームＰＭＩＰドメインに接続しているか否かを判断してもよい。また、ＩＦ２を含むＭＮ７００のインタフェースのいずれもホームＰＭＩＰドメインに接続していないと判断された場合には、通常のＣＭＩＰに関するＢＵの送信を行うようにしてもよい。【０１９１】
ＭＮ７００からＭＡＧ７０６へメッセージ７１３によって提供されるＣＭＩＰに関するＢＵのコンテンツとしては、例えば、ＩＦ１の気付アドレス、ＩＦ１のホームアドレス、許可データ（authorization data）、ＣＭＩＰに関するＢＵのシーケンスナンバーのうちのいずれかの情報や、これらのうちの複数の情報などを挿入することが可能である。なお、許可データは、ＭＮ７００のＩＦ１のＨｏＡとＭＮ７００のＩＦ１の気付アドレスとを連結した情報を、ＭＮ７００のセキュリティキーを用いて暗号化することによって得られるものである。ＭＮ７００のセキュリティキーは、ＨＡ（ＬＭＡ／ＨＡ）７１０が任意のインターネット鍵交換プロトコルを使用して生成した鍵である。また、ＭＮ７００は、メッセージ７１３を通じて、ＩＦ１の識別子をＭＡＧ７０６へ渡す必要があるかもしれない。なお、ＩＦ１がＩＦ２のホームプレフィックスとは異なるホームプレフィックスを使用してホームアドレスを構成する場合には、ＩＦ１の識別子は、ＬＭＡ／ＨＡ７１０におけるバインディングを区別できるようにしておく必要はない。【０１９２】
ＭＡＧ７０６がＡＡＡサーバ（図８Ａには不図示）からＭＮ７００のホームプレフィックスを取得した場合、ＭＡＧ７０６は、このホームプレフィックスを含むＲＡ７１６を送出するととともに、ＭＮ７００の両方のインタフェースに関連するＣＭＩＰ及びＰＭＩＰのＢＵを組み合わせたバルク登録の情報を送信する。メッセージ（ＰＢＵ）７１４は、ＣＭＩＰに関するＢＵのコンテンツ（ＩＦ１に関するＢＵのコンテンツ）をＰＭＩＰのＰＢＵ（ＩＦ２に関するＰＢＵ）に組み合わせたメッセージを示しており、メッセージ（ＰＢＡ）７１５は、その応答メッセージを示している。なお、メッセージ７１４は、ＣＭＩＰに関するＢＵのコンテンツやＩＦ１のインタフェース識別子などを伝送するための新しいオプションを有することを除いて、通常のＰＭＩＰｖ６動作において用いられている通常のＰＢＵであることが望ましい。【０１９３】
また、ＭＮ７００は、メッセージ７１３と共にＣＭＩＰに関するＢＵのコンテンツを送信せずに、ＭＡＧ７０６からＲＡ７１６を受信した後に、ＣＭＩＰに関するＢＵのコンテンツを通知するための新しいＬ２メッセージ又はＬ３メッセージを送信してもよい。また、ＩＦ２がホームＰＭＩＰドメインに接続されていることをＭＮ７００が確信できない場合には、ＭＮ７００は、ＭＡＧ７０６からのＲＡ７１６の受信を待機し、ＲＡ７１６の受信によってＩＦ２がホームＰＭＩＰドメインに接続されていることを確認してからＣＭＩＰに関するＢＵのコンテンツを送信してもよい。なお、ＲＡ７１６の受信後にＣＭＩＰに関するＢＵのコンテンツを送信する場合のシグナリングに関しては、図８Ａには不図示である。また、ＭＮ７００がＲＡ７１６の受信後にＣＭＩＰに関するＢＵのコンテンツを送信する場合、ＭＡＧ７０６は、ＲＡ７１６の送信後にＭＮ７００からＣＭＩＰに関するＢＵのコンテンツを取得してから、ＰＢＵ７１４を送信する必要がある。したがって、この場合は基本的に、ＰＢＵ７１４の送信に若干の遅延が生じることになる。【０１９４】
ＩＦ１がバインディングをリフレッシュする必要がある場合、又は、ＩＦ１のハンドオフなどの理由によってＩＦ１に関する新しいバインディングを作成して新たなアドレス構成を得る必要がある場合には、ＩＦ２が依然としてＭＡＧ７０６に接続されていると仮定してＩＦ２からＭＡＧ７０６に対して関連情報（バインディングのリフレッシュに必要な情報）が渡される。この場合には、ＭＡＧ７０６は、リフレッシュＰＢＵを用いることによって、ＩＦ１のＣＭＩＰに関するＢＵのコンテンツをＬＭＡ／ＨＡ７１０へ送信することが可能である。なお、ＭＡＧ７０６からのバインディングのリフレッシュが後で行われる（すなわち、すぐには行われない）ように設定されている場合には、ＭＮ７００は、例えばＣＭＩＰに関するＢＵシグナリングの遅滞を防ぐよう明示するメッセージをＭＡＧ７０６へ送信することで、ＣＭＩＰに関するＢＵのコンテンツの迅速な送信をＭＡＧ７０６に促すようにしてもよい。以上のような実施の形態における方法を用いることで、複数のバインディングの登録（マルチ登録）に代わって、バルク登録が実現される。さらに、ＭＮ７００に関する複数の位置更新バインディングの登録には、ホームドメインを経由するパス（より短いルーティングパス）が利用される。【０１９５】
また、ホームＰＭＩＰドメインに接続されているＭＮのプレフィックスがＬＭＡから提供されたものである場合には、上述の動作と比べてシグナリングが若干異なる。以下、このような場合のシグナリングに関して、図８Ｂを参照しながら説明する。【０１９６】
図８Ｂにおいても、ＭＮ７１６は２つのインタフェースを有しており、ＩＦ１においてＭＡＧ７１７を経由して外部ドメインに接続されているとともに、ＩＦ２においてＭＡＧ７１８を経由してホームＰＭＩＰドメインに接続されている。なお、ここでは、ＭＮ７１６のＩＦ２がホームＰＭＩＰドメインに移動したばかりであると仮定する。【０１９７】
ＭＮ７１６は、ＩＦ１においてＭＡＧ７１７からＲＡ７２０を受信し、ＲＡ７１１に含まれる外部プレフィックスからＣｏＡを構成している。一方、ＭＮ７１６は、ＩＦ２においてビーコン信号（ＷＬＡＮビーコンシグナル）７２１をＭＡＧ７１８から受信する。そして、ＷＬＡＮビーコンシグナル７２１の受信後、ＭＮ７１６はメッセージ（Ｌ２接続シグナル）７２２によってＭＡＧ７１８とＬ２接続を行う。ＭＮ７１６のＬ２接続後、ＭＡＧ７１８は、ＭＮ７１６のＩＦ２に関するホームプレフィックスを取得するためにＰＢＵ７２３を行い、その後、ＡＡＡサーバ（不図示）においてＭＮ７１６の真正性を確認するためにＡＡＡの検証が行われる。【０１９８】
ＭＡＧ７１８は、ＬＭＡ／ＨＡ７１９からホームプレフィックスを含むＰＢＡ７２４を受信した後でのみ、ＲＡ７２５の送信が可能となる。ＭＡＧ７１８からＲＡ７２５を受信した後、ＭＮ７１６は、ＣＭＩＰに関するＢＵのコンテンツを含むメッセージ７２６を送信する。なお、メッセージ７２６は、Ｌ２メッセージであってもよく、Ｌ３メッセージであってもよい。【０１９９】
このシナリオ（ＬＭＡ／ＨＡ７１９がプレフィックスを提供するシナリオ）では、ＭＮ７１６からＣＭＩＰに関するＢＵのコンテンツを含むメッセージ７２６を受信したＭＡＧ７１８は、ＣＭＩＰに関するＢＵのバインディングを登録するために、第２のメッセージを送信する必要がある。図８Ｂには、この第２のメッセージ（ＰＢＵ７２７）と、その応答であるＰＢＡ７２８が図示されている。【０２００】
また、このシナリオでは、最初の接続の際に、複数のＰＢＵ／ＰＢＡ（ＰＢＵ７２３とＰＢＡ７２４とのペアや、ＰＢＵ７２７とＰＢＡ７２８とのペア）が送信される必要があるが、その後のホームＰＭＩＰドメインにおける接続では、コンテキストトランスファーを利用することでＰＢＵを二重に送信しないようにすることも可能である。例えば、ＭＮ７１６が移動を行って、ＩＦ２がホームＰＭＩＰドメイン内の別のＭＡＧ（新たなＭＡＧ）へ接続し、ＩＦ１のＣＭＩＰバインディングを再送する必要が生じた場合、ホームＰＭＩＰドメイン内の新たなＭＡＧ（ＩＦ２が新たに接続したＭＡＧ）は、ＩＦ２のホームプレフィックスに関する情報をコンテキストトランスファーのメカニズムを利用して取得してもよい。この場合、ＰＢＵ７２７のような新しいＰＢＵのみ送信されればよく、この後の接続においても、ＰＢＵ７２３やＰＢＡ７２４は送信される必要はない。【０２０１】
例えば、上述のような２重のＰＢＵ／ＰＢＡシグナリングが送信される可能性がある点を除けば、ホームドメインを経由してＣＭＩＰのＢＵの内容を送信するほうが、より迅速に行われる可能性がある。ＭＮが２つ以上のインタフェースを有する場合には、ＰＢＵ７１４やＰＢＵ７２７によって、１つ又は複数のインタフェースのＣＭＩＰに関するＢＵのコンテンツが送信可能である。【０２０２】
また、上述の実施の形態に係る方法は、ＰＭＩＰドメイン（ホームドメイン）のパスを経由して、外部ドメインに接続しているインタフェースに係るＣＭＩＰに関するＢＵを送信することで、迅速なＣＭＩＰのＢＵを実現することが可能である。しかしながら、例えば、ホームＰＭＩＰドメイン内に位置する情報サーバからホームＰＭＩＰドメインが輻輳状態である旨が通知された場合などには、ＣＭＩＰのＢＵは通常のパス（すなわち、ＩＦ１経由）で送信されたほうがよい場合もあり得る。【０２０３】
基本的にＣＭＩＰのＢＵのパスは、何らかの信頼あるネットワークエンティティからの情報に基づいて、ＭＮによって選択される。例えば図８Ａや図８Ｂにおいて、ホームＰＭＩＰドメインが輻輳している場合には、ＩＦ２が接続されているＭＡＧ（ＭＡＧ７０６やＭＡＧ７１８）が、ＰＭＩＰ及びＣＭＩＰのＢＵのバルク登録をＩＦ１経由で送信するようＭＮ７１６へ要求してもよい。【０２０４】
この場合、ＭＮがＰＭＩＰ及びＣＭＩＰのＢＵのバルク登録をＩＦ１経由で行えるようにするために、ＭＡＧは、タイムスタンプオプションを付加したＰＭＩＰのＢＵのコンテンツを提供する必要がある。【０２０５】
また、ＭＮのＩＦ２が直接ホームリンクに接続されている場合もあり得る。このような場合には、ＭＮは、例えばＬＭＡ／ＨＡへ近隣通知ＩＣＭＰメッセージを送信することによって、ＩＦ１におけるＣＭＩＰに関するＢＵのコンテンツをＬＭＡ／ＨＡへ提供することが可能である。【０２０６】
次に、図１１Ｂに図示されているような従来の技術におけるハンドオフの問題やパケットロスの問題を解決するための方法について説明する。図１１Ｂを用いて上述したように、ＩＦ１（ホームＰＭＩＰドメインから外部ドメインへ移動するインタフェース）でパケットロスが生じる主要な理由は、ＩＦ１が移動後に接続した場合に送信されるＣＭＩＰのＢＵよりも、ＩＦ１が移動前に接続していた状態で送信されるＰＭＩＰのＰＢＵが遅れてＨＡ（ＬＭＡ／ＰＤＮ−ＧＷ／ＨＡ２７０）に届くことにある。【０２０７】
以下では、このような問題を解決するために、ＩＦ１のＣＭＩＰのＢＵメッセージに、ＩＦ１に関連するＰＭＩＰのＰＢＵメッセージ（ＩＦ１の移動前に係るＰＢＵメッセージ）と同じようなタイムスタンプオプションを設ける方法について説明する。【０２０８】
この方法では、ＩＦ１に関連するＣＭＩＰのＢＵメッセージが、ホームＰＭＩＰドメインに接続されている、移動しないインタフェース（すなわちＩＦ２）を経由して送信される。これにより、移動しないインタフェースに接続されているＭＡＧによって、ＣＭＩＰのＢＵメッセージにタイムスタンプオプションが付加されるようになる。タイムスタンプオプションが付加されることにより、ＬＭＡ／ＨＡは、ＩＦ１に関する最も新しいバインディング状態をタイムスタンプ値から容易に識別することが可能となる。なお、例えばＭＡＧは、ＬＭＡ／ＨＡへ送信するメッセージに対して常に、又はその必要性を判断して、タイムスタンプオプションを付加してもよく、ＭＮがＭＡＧに対して明示的にタイムスタンプオプションの付加を要求してもよい。【０２０９】
さらに、この方法では、ＣＭＩＰのＢＵメッセージを、移動していないインタフェースに関連したＰＭＩＰのＰＢＵメッセージと結合することが可能であり、この結合によってシグナリングの更なる最適化が実現される。以下、図９Ａを参照しながら、この方法について説明する。【０２１０】
図９Ａにおいて、ＭＮ８０５は２つのインタフェースを有している。ＩＦ２は無線リンクを通じてホームＰＭＩＰドメイン８００に接続されており、ＭＡＧ８１１に直接接続されている。一方、ＭＮ８０５のＩＦ１は、無線リンクを通じてホームＰＭＩＰドメイン８００のＭＡＧ８１０に接続されている状態から、外部ドメイン８０１へ移動したとする。なお、ＩＦ１がＭＡＧ８１０に接続していた時間が短時間であるとする。また、ＡＲ８１２が外部ドメイン８０１に接続されており、ＭＮ８０５のＩＦ１は移動してＡＲ８１２に接続したとする。また、ホームＰＭＩＰドメイン８００と外部ドメイン８０１とがインターネット８０２に接続されているとする。【０２１１】
このように、ＩＦ１に関して迅速な移動（ＭＡＧ８１０への短時間の接続）が起こる場合、ＭＮ８０５は、ＩＦ１の移動前の接続に係るメッセージ（ＰＢＵ）８２５がＩＦ１の移動後のＣＭＩＰのＢＵより遅れて到着してしまう可能性があると予測するかもしれない。このような場合、登録メッセージの順序の誤りを防ぐため、ＭＮ８０５は、メッセージ８２６によって、ＩＦ１に関連したＣＭＩＰのＢＵメッセージを送信するようＭＡＧ８１１へ要求するとともに、さらに、ＭＡＧ８１１がこのメッセージを送信する際にタイムスタンプオプションを挿入するようＭＡＧ８１１へ要求することが可能である。このメッセージ（要求メッセージ）８２６は、ＩＦ１に関連したＣＭＩＰのＢＵのコンテンツを含んでいればよく、Ｌ２メッセージ又はＬ３メッセージのどちらであってもよい。【０２１２】
要求メッセージ８２６を受信すると、ＭＡＧ８１１は、メッセージ（登録メッセージ）８２７をＬＭＡ／ＨＡ８２０へ送信する。このメッセージ８２７は、ＭＮ８０５から提供されたＣＭＩＰに関するＢＵのコンテンツを運ぶためのオプションと、ＭＡＧ８１１によって挿入されたタイムスタンプオプションとが、通常のＰＭＩＰのＰＢＵメッセージに付加されたものである。なお、挿入されるタイムスタンプオプションは、ＭＡＧ８１１内で動作する時計から得られる時間情報を含んでいる。【０２１３】
図９Ｂには、ＬＭＡ／ＨＡ８２０のバインディングキャッシュ８３０が図示されている。図９Ｂにおいて、バインディングキャッシュ８３０の最初のエントリは、ＭＡＧ８１１へのＩＦ２の接続に関連して送信されたＰＢＵによって作成された登録を表している。また、バインディングキャッシュ８３０の２番目のエントリは、ＭＡＧ８１１から新たなメッセージ８２７を受信した際にＬＭＡ／ＨＡ８２０で作成された登録を表している。このメッセージ８２７は、ＩＦ１のＣＭＩＰに関するＢＵであり、上述のようにタイムスタンプ値が付加されている。なお、メッセージ８２７に関連してＬＭＡ／ＨＡ８２０で作成されたキャッシュは、ＣＭＩＰに関するＢＵの現在の時刻に従ったＣＭＩＰのＢＵのシーケンスナンバーを有している。【０２１４】
ここで、メッセージ８２７の後にＭＡＧ８１０からの送信されたメッセージ（ＰＢＵ８２５）がＬＭＡ／ＨＡ８２０に届いた場合、メッセージ８２５に存在するタイムスタンプ値はメッセージ８２７によって示される最新の時刻よりも前の時刻となり、メッセージ８２５は破棄されることになる。この結果、登録順序の誤りによるＩＦ１のパケットロスは起こらなくなる。【０２１５】
ＩＦ２を通じてＣＭＩＰのＢＵを送信する利点は、ＣＭＩＰのＢＵに時刻（タイムスタンプ値）を付加できることにある。一方、ＣＭＩＰに関するＢＵをＩＦ１から送信し、ＣＭＩＰのＢＵの時間情報をメッセージ８２７によってＩＦ２から送信した場合には、このメッセージ８２７がＣＭＩＰに関するＢＵやＰＢＵ８２５より遅れて到着してしまう可能性があり、メッセージ８２７の到着前にＣＭＩＰのＢＵがＰＢＵ８２５から得られる誤ったバインディングによって、即座に消去されてしまう可能性がある。【０２１６】
次に、図１１Ｃに示されているような従来技術に係る問題を解決する方法について説明する。図１１Ｃに図示されている従来技術では、３ＧＰＰドメイン内に存在する任意のＣＮとの経路最適化に関して、オンリンクプレフィックスを用いて気付アドレスを構成することがあまり有効ではない（オンリンクプレフィックスを用いて気付アドレスを構成した場合、ＡＲの接続を変更するたびに経路最適化セッションを実行しなければならない可能性がある）という問題がある。【０２１７】
以下、図１０を参照しながら、ＭＮがｅＰＤＧ内プレフィックス又はｅＰＤＧ外プレフィックスを用いて３ＧＰＰドメイン内に存在する任意のＣＮとの通信に用いるための気付アドレスを構成し、さらには、ｅＰＤＧ／ＭＡＧに対して、“Ｈ”フラグや任意のインタフェース識別パラメータを有するＰＭＩＰ及びＣＭＩＰのバルク登録の実行を要求する方法について説明する。【０２１８】
図１０において、ＭＮ９０５は非信頼ＷＬＡＮアクセスネットワーク９０２に移動し、ＣＮ９４０及びＣＮ９４１との間で経路最適化通信を行おうとしている。なお、この図１０の構成は、図１１Ｃの構成とほぼ同一であり、ここでは構成要素に関する説明を省略する。【０２１９】
ＭＮ９０５は、メッセージ９５０によって、異なるプレフィックスをＡＲ９１０から受信する。なお、ＭＮ９０５が、異なる位置に配置された各ＣＮと通信を行うための適切なプレフィックスをそれぞれ選択するために、プレフィックスの要求を行ってもよい。このプレフィックスは、ＡＲ９１０から提供されるオンリンクプレフィックスであってもよく、ＬＭＡ／ＰＤＮ−ＧＷ／ＨＡ９３０の配下を示すＰＭＩＰのローカルプレフィックスであってもよく、ｅＰＤＧインプレフィックス（ePDG in-prefix）やｅＰＤＧアウトプレフィックス（ePDG out-prefix）であってもよい。ｅＰＤＧアウトプレフィックスは、ｅＰＤＧ（ｅＰＤＧ／ＭＡＧ）９２０に関連付けられたプレフィックスやｅＰＤＧ９２０の配下のプレフィックスなどを表している。また、ｅＰＤＧインプレフィックスは、例えばＧＷ９３１の配下のプレフィックスなどを表している。なお、ｅＰＤＧインプレフィックス又はｅＰＤＧアウトプレフィックスは、ＭＮごとに提供されるプレフィックスであってもよく、あるいは、複数のＭＮに共通して提供されるプレフィックスであってもよい。【０２２０】
例えばＭＮ９０５がＣＮ９４０と通信を行う際には、ｅＰＤＧアウトプレフィックスを用いて最適な経路を実現し、位置登録シグナリングの低減を図ることが適切であることは当業者にとっては明白である。ＭＮ９０５とＣＮ９４０との間の経路最適化パスにおいて、ｅＰＤＧ９２０が経路最適化パス上に存在するとともにルーティング階層の最も遠くに位置しており、経路最適化や位置登録シグナリングの低減が実現される。さらに、ＭＮ９０５がＣＮ９４１と通信を行う際には、ＧＷ９３１の配下のｅＰＤＧインプレフィックスを用いて最適な経路や位置登録シグナリングの低減を実現することが適切である。ＭＮ９０５とＣＮ９４１との間の経路最適化パスにおいても同様に、ＧＷ９３１の折り返しによって経路最適化や位置登録シグナリングの低減が実現される。【０２２１】
また、ｅＰＤＧ９２０が、ＭＮ９０５及びＣＮ９４０の現在の位置を把握した後、ＭＮ９０５及びＣＮ９４０に対してｅＰＤＧアウトプレフィックスの使用を忠告してもよい。ＭＮ９０５及びＣＮ９４０からｅＰＤＧ９２０へのトンネルが存在しているので、ｅＰＤＧ９２０は、ＭＮ９０５及びＣＮ９４０の位置を把握し、これらのエンドノード（ＭＮ９０５及びＣＮ９４０）に対してアドバイスを行うことが可能となる。【０２２２】
一方、ｅＰＤＧアウトプレフィックスを使用する場合には、プレフィックスを使用して構成されたアドレスに関して、ｅＰＤＧ９２０によって重複アドレス検出（ＤＡＤ：duplicate address detection）が行われる必要があるかもしれない。これは、例えば、ｅＰＤＧ９２０におけるプレフィックス割り当てに関して、共有プレフィックスタイプのモデルが実施されている場合に起こり得る。ＭＮ９０５がＣＮ９４０との経路最適化のための気付アドレスをｅＰＤＧアウトプレフィックスを使用して構成する場合には、ＭＮ９０５は、気付アドレスを構成して、ＣＭＩＰのＢＵ及びＰＭＩＰのＰＢＵメッセージをＬＭＡ９３０へ送信するようｅＰＤＧ９２０に要求する。ＭＮ９０５は、基本的に、ＣＭＩＰに関するＢＵのコンテンツを作成して、メッセージ９５１によって示されるようなトンネル経由でｅＰＤＧ９２０へ渡す。【０２２３】
ｅＰＤＧ（ｅＰＤＧ／ＭＡＧ）９２０は、ＣＭＩＰに関するＢＵに加えて、ＬＭＡ９３０におけるＰＭＩＰのホームプレフィックスに関してＰＭＩＰのＰＢＵを実行する必要がある。したがって、ｅＰＤＧ９２０は、このようなＰＭＩＰのＰＢＵメッセージ及びＣＭＩＰのＢＵメッセージの両方を結合して送信することが可能である。ＣＭＩＰのＢＵメッセージ及びＰＭＩＰのＰＢＵメッセージの両方を伝送するメッセージは、メッセージ９５２によって示されているように、ｅＰＤＧ９２０からＬＭＡ９３０へ伝送される。ＰＭＩＰ及びＣＭＩＰが結合されたバインディングは、ＢＩＤ、インタフェースＩＤ、“Ｈ”フラグなどの手段によって識別可能である。【０２２４】
ＭＮ９０５がローカルアクセスドメイン（非信頼ＷＬＡＮアクセスネットワーク）９０２内に移動したとき、ＡＲが変更されてもパス９６０経由で経路最適化通信が実現可能な場合には、位置更新シグナリングが頻繁に行われる必要はない。これは、ＭＮ９０５が軌跡９０６で移動した場合であっても、依然として同一のアクセスルータ（ｅＰＤＧ／ＭＡＧ）９２０に接続されていることによる。【０２２５】
また、ＭＮ９０５及びＣＮ９４０がｅＰＤＧアウトプレフィックスを用いて構成された気付アドレスのＲＲシグナリングやバインディング登録を完了した場合には、データパケット伝送が開始される。このとき、データパケットがパス９６０を通じて伝送される場合には、パケットの送信元アドレスはｅＰＤＧアウトプレフィックスから得られるアドレスとなっている。このパケットはｅＰＤＧ９２０へトンネルされ、ｅＰＤＧ９２０でこのパケットのデカプセル化が行われる。デカプセル化後のパケットのあて先アドレスは、ｅＰＤＧ９２０のプレフィックスから得られるＣＮ９４０の気付アドレスである。ｅＰＤＧ９２０は、ＣＮ９４０あてのトンネルでパケットの再カプセル化を行う。なお、トンネリング処理の詳細に関しては図１０には明示されていないが、当業者であれば容易に理解可能である。【０２２６】
ＭＮ９０５がＣＮ９４１と通信を行っており、デフォルトのパスがＧＷ９３１経由である場合には、ｅＰＤＧインプレフィックスを使用して経路最適化を行うことが有効である。例えば、ＧＷ９３１が何らかのポリシを実施しており、ネットワークにおいて、ＭＮ９０５とＣＮ９４１との間でＧＷ９３１を経由するデフォルトの最短経路が実現されている可能性がある。さらに、ＧＷ９３１由来のプレフィックス（すなわち、ｅＰＤＧインプレフィックス）を使用して気付アドレスが構成されている場合には、ホームドメイン内を移動する間のＭＮ９０５のシグナリングの負荷が最適化され、さらに経路最適化が実現可能となる。ＭＮ９０５からＣＮ９４１へ送信されるデータパケットは、ＧＷ９３１のプレフィックスに由来する送信元アドレスを有している。このパケットは、ｅＰＤＧ９２０へトンネルされ、ｅＰＤＧ９２０は、このデータパケットをデカプセル化してＧＷ９３１にトンネルする。ＧＷ９３１は、パケットのデカプセル化を行って、さらに、ＭＡＧ９２１へのトンネルでカプセル化する。データパケットがＭＡＧ９２１に到達すると、ＭＡＧ９２１は、ポイントツーポイント回線リンクを通じてデータパケットを直接ＣＮ９４１へ渡す。なお、図１０には、ｅＰＤＧインプレフィックスを使用して気付アドレスを構成しているＭＮ９０５から、ＣＮ９４１へ伝送されるパケットの経路最適化パス９６１が図示されている。【０２２７】
なお、ルーティング階層がより高いルータから提供されたプレフィックスを用いており、そのルータが任意のＭＮとＣＮとの通信パスのデフォルトルータである場合には、そのルータ由来のプレフィックスを用いて気付アドレスを構成することが望ましい。これによって、頻繁な位置更新シグナリングが行われないようにして、経路最適化を実現することが可能となる。【０２２８】
また、ＣＮ９４０と通信を行う場合は、経路最適化パスはｅＰＤＧ９２０（ＭＮ９０５とＣＮ９４０との間の経路最適化パスにおいて、ルーティング階層の最も高い位置に配置されたルータ）を経由する。したがって、そのプレフィックスを使用して経路最適化を実現するとともに位置更新シグナリングの量を低減することが望ましい。また、ＣＮ９４１と通信を行う場合は、経路最適化パスはＧＷ９３１（ＭＮ９０５とＣＮ９４１との間の経路最適化パスにおいて、ルーティング階層の最も高い位置に配置されたルータ）を経由する。したがって、ＧＷ９３１由来のプレフィックスを使用して経路最適化を実現するとともに、位置更新シグナリングの量を低減することが望ましい。なお、これらは、プレフィックスを選択する際の基本的な考え方に基づくものであるが、ＭＮがこうした基本的な考え方に基づくプレフィックスの選択を行えるようにするために、どのプレフィックスを選んだらよいかに関して、ネットワークから通知される必要があるかもしれない。例えば、何らかのネットワークエンティティがＭＮやＣＮのパケットを監視し、その監視結果に応じてＭＮやＣＮに対してアドバイス（適切なプレフィックスの通知）を行えるようにしてもよい。【０２２９】
なお、本明細書では、本発明が最も実用的かつ好適な実施例となるように考慮されて図示及び説明されているが、当業者であれば、上述の各装置の構成要素に係る設計やパラメータの詳細において、発明の範囲から逸脱しない程度に様々な変更が行われてもよいことは明白である。【０２３０】
例えば、モバイルノードが２つのインタフェースを有しており、一方のインタフェースがホームＰＭＩＰｖ６ドメインに接続されており、他方のインタフェースが外部ＰＭＩＰｖ６ドメインに接続されている場合に対して、本発明を適用することが可能である。また、例えば、ＣＮが、ＭＮのホームＰＭＩＰｖ６ドメインに存在し、外部ＰＭＩＰｖ６ドメインに接続されているＭＮのインタフェースのホームアドレスと通信を行っているような場合であっても、本発明に係る技術を用いることで経路最適化が実現される。【０２３１】
さらに、上述の実施の形態では、ＵＥが移動前に接続しているドメインは、ホームＰＭＩＰｖ６ドメインであるが、例えば、ホームオペレータが管理していない外部ＰＭＩＰｖ６ドメインや別の３ＧＰＰドメインであってもよく、ＭＩＰｖ６を使用せずに接続しているアクセスネットワークなどであってもよい。また、ＷｉＭＡＸやＷＬＡＮなどの異なるアクセスネットワークであってもよく、ＦＭＣ（Fixed Mobile Convergence）などによって無線系と固定系が統合されたネットワークや、ＮＧＮ（Next Generation Network）などの高度に管理されるネットワーク構成に関わるネットワークでもよく、それらネットワークとの信頼関係が高くても低くてもよい。また、同様に、上述の実施の形態では、ＵＥが移動後に接続するドメインは外部ネットワークであるが、この外部ネットワークは、例えば、外部ＰＭＩＰｖ６ドメイン、非３ＧＰＰアクセスネットワークなど、ＵＥがＭＩＰｖ６を起動させるドメイン（ＵＥがＭＩＰｖ６を使用するドメインであればアクセス技術には限定されない）である。また、ＵＥがホームＰＭＩＰｖ６ドメインに接続したまま移動しないで、ローカルブレイクアウトなどを目的としてＭＩＰｖ６を起動する場合においても、本発明は適用可能である。【０２３２】
また、本明細書では、ＭＮのネットワークインタフェースが複数であることを前提に説明を行っている部分があるが、本発明を実施するうえでの論理的なインタフェースが複数あればよい。例えば、１つの無線部を複数の接続方式で共用し、ネットワークインタフェースの観点からはその変化が問題にならない程度の速度で切り替えたり、レイヤ２で論理的なリンクを維持したりすることにより、ネットワーク部からは複数のインタフェースを介してネットワークに接続している場合と同等に動作できるよう構成されていてもよい。【０２３３】
また、本発明の説明において、ネットワーク構成を説明に用いた図に示す簡単な構成を挙げて示したが、ローカルネットワークドメインの構成は、複数オペレータ間のローミング関係も含めて多岐にわたることが考えられる。例えば、ＭＡＧはモバイルノードの直接的なアクセスルータである構成や、ＭＡＧが異なるアクセスネットワーク（ローミングを含む）との境界ルータであり、モバイルノードは一旦その異なるアクセスネットワークに接続した後、そのアクセスネットワークを介して境界ルータであるＭＡＧに接続するという構成が考えられる。いずれの場合も、様々なパラメータや端末からＭＡＧへの到達手順、端末の通信手順などの設計部分が異なるが、本発明の動作に関しては同様に適用できることは明白である。【０２３４】
また、上述の実施の形態では、ローカルモビリティ管理の環境であることが仮定されているが、モバイルルータ（ＭＲ：Mobile Router)（及びその配下のノード）により構成されたモバイルネットワーク（Mobile Network)（若しくは階層化されたモバイルネットワーク）に本発明を適用することも可能である。【０２３５】
例えば、モバイルネットワークの構成方法の一つであるＮＥＭＯ（NEtwork MObility）は、ＭＲがＨＡ（Home Agent）に移動ネットワーク（及び端末）の移動登録を行うことにより移動端末に対するモビリティサポートを提供しているが、本明細書におけるＭＡＧがＭＲに対応する形で適用可能である。この場合、ＬＭＡはＭＲのＨＡに対応すると考えることができる。さらに、ＰＭＩＰを用いたネットワークを提供するネットワークオペレータがローミング関係などにより、ＰＭＩＰで構成しているＭＡＧ−ＬＭＡ間のトンネルを多段に用いるような場合は階層化されたモバイルネットワークに相当する。【０２３６】
さらに、オーバレイネットワークの環境に本発明を適用することも可能である。例えば、ＭＡＧによる移動端末に対するモビリティサポートをｐＨＡ（Proxy HA：プロキシＨＡ）に対応する形で適用可能である。この場合、モバイルノードの移動の起点（ある時点を基準とするものであったり（相対的）、ネットワークオペレータへの登録の状態（確定的）であったり、様々な場合があり得る）となるホームエージェント若しくはモバイルノードの接続先であるホームエージェントから登録情報を受信する他のホームエージェントはＬＭＡに対応すると考えることができる。【０２３７】
なお、上記の本発明の実施の形態の説明で用いた各機能ブロックは、典型的には集積回路であるＬＳＩ（Large Scale Integration）として実現される。これらは個別に１チップ化されてもよいし、一部又はすべてを含むように１チップ化されてもよい。なお、ここでは、ＬＳＩとしたが、集積度の違いにより、ＩＣ（Integrated Circuit）、システムＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。【０２３８】
また、集積回路化の手法はＬＳＩに限るものではなく、専用回路又は汎用プロセッサで実現してもよい。ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Field Programmable Gate Array）や、ＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサを利用してもよい。【０２３９】
さらには、半導体技術の進歩又は派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。例えば、バイオ技術の適応などが可能性としてあり得る。
【産業上の利用可能性】
【０２４０】
本発明のネットワークノード及び移動端末は、移動端末がＰＭＩＰドメインを移動する際に、選択可能な様々なプレフィックスがアクセスルータから提供されるようにするという効果や、移動端末が利用可能なプレフィックスから構成する必要があるアドレスのタイプを選択し、ＰＭＩＰドメインに対してシグナリングの負荷をかけずに、経路が最適化されるようにコレスポンデントノードとの通信を行えるようにするという効果を有しており、パケット交換型データ通信ネットワークのシステム（特に、ＰＭＩＰなどのネットワークベースのローカルモビリティ管理プロトコルが実装されているネットワークシステム）における通信技術分野に適用可能である。
【図１】
2009044539.tif 000003
【図２】
2009044539.tif 000004
【図３】
2009044539.tif 000005
【図４】
2009044539.tif 000006
【図５】
2009044539.tif 000007
【図６】
2009044539.tif 000008
【図７】
2009044539.tif 000009
【図８Ａ】
2009044539.tif 000010
【図８Ｂ】
2009044539.tif 000011
【図９Ａ】
2009044539.tif 000012
【図９Ｂ】
2009044539.tif 000013
【図１０】
2009044539.tif 000014
【図１１Ａ】
2009044539.tif 000015
【図１１Ｂ】
2009044539.tif 000016
【図１１Ｃ】
2009044539.tif 000017
【図１１Ｄ】
2009044539.tif 000018
【手続補正書】
【提出日】平成22年4月1日(2010.4.1)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
ネットワークベースのローカルモビリティ管理プロトコルが実装されているネットワークドメインを構成し、前記ネットワークドメインに接続されている移動端末の位置情報を管理する機能を有する位置管理ノードと、前記移動端末の位置情報の登録を代理して行う機能を有する代理登録ノードと、前記移動端末の認証を行う認証サーバとを有する通信システムにおける通信制御方法であって、
前記ネットワークドメインをホームドメインとする移動端末が、複数のプレフィックスを取得するプレフィックス取得ステップと、
前記移動端末が、前記複数のプレフィックスから複数のアドレスを取得するアドレス取得ステップと、
前記移動端末が、前記複数のアドレスを前記ネットワークドメインに通知するアドレス通知ステップと、
前記代理登録ノードが、前記移動端末から通知された前記複数のアドレスのそれぞれに係るバインディング情報を前記位置管理ノードに登録するバインディング登録ステップとを、
有する通信制御方法。
【請求項２】
前記移動端末が、前記ネットワークドメインに接続する際に複数のプレフィックスを要求するステップと、
前記代理登録ノードが、前記複数のプレフィックスの要求に基づいて、前記複数のプレフィックスが前記移動端末に通知されるよう処理するステップとを、
有する請求項１に記載の通信制御方法。
【請求項３】
前記プレフィックス取得ステップが、
前記移動端末が、前記ネットワークドメインに接続する際に、前記移動端末に前記ネットワークドメインへの接続を提供するアクセスルータに対して前記複数のプレフィックスを要求するステップと、
前記アクセスルータが、前記代理登録ノードに前記複数のプレフィックスの要求を渡し、前記代理登録ノードが、前記認証サーバに前記移動端末の認証を依頼するステップと、
前記認証サーバが、前記移動端末による前記ネットワークドメインへの接続資格を確認した後にドメインプレフィックスを前記移動端末に割り当て、前記ドメインプレフィックスを前記代理登録ノードに通知するとともに、前記複数のプレフィックスを前記移動端末に通知するよう前記代理登録ノードに指示するステップと、
前記代理登録ノードが、前記ドメインプレフィックスを前記アクセスルータを通じて前記移動端末に通知するとともに、前記認証サーバからの前記複数のプレフィックスの通知指示に基づいて前記アクセスルータにグローバルプレフィックスの通知を行わせるステップとを有し、
前記アドレス通知ステップが、前記移動端末が前記ドメインプレフィックスを含むホームアドレスと、前記グローバルプレフィックスを含むグローバルアドレスとを取得するステップを有し、
前記アドレス通知ステップが、前記移動端末が前記ホームアドレス及び前記グローバルアドレスを前記アクセスルータに通知し、前記アクセスルータが前記ホームアドレス及び前記グローバルアドレスを前記代理登録ノードに渡すステップを有し、
前記バインディング登録ステップが、前記代理登録ノードが前記ホームアドレス又は前記ドメインプレフィックスと前記代理登録ノード自身のアドレス又はプレフィックスとを関連付ける第１のバインディング情報、及び、前記ホームアドレスと前記グローバルアドレスとを関連付ける第２のバインディング情報を前記位置管理ノードに登録するステップを有する請求項１に記載の通信制御方法。
【請求項４】
前記移動端末が接続されるアクセスルータが前記代理登録ノードとしての機能を有さない場合、前記アクセスルータは、前記移動端末と前記代理登録ノードとの間において伝送される情報を中継するとともに、前記アクセスルータ独自のオンリンクプレフィックスを通知する請求項１に記載の通信制御方法。
【請求項５】
前記移動端末が複数の通信インタフェースを有しており、前記複数の通信インタフェースのうちの少なくとも１つが外部ネットワークドメインに接続されている場合に、前記アドレス通知ステップにおいて、前記移動端末が、前記外部ネットワークドメインが接続されている通信インタフェースに対応して設定されるアドレスを、前記ホームドメインに接続されている通信インタフェースから前記ホームドメインに通知するステップを有する請求項１に記載の通信制御方法。
【請求項６】
前記バインディング登録ステップにおいて、前記代理登録ノードが、前記外部ネットワークドメインが接続されている通信インタフェースに対応して設定される前記移動端末のアドレスに係るバインディング情報を前記位置管理ノードに登録するステップを有する請求項５に記載の通信制御方法。
【請求項７】
前記アドレス通知ステップにおいて、前記移動端末が、前記ホームドメインに接続されている通信インタフェースから前記ホームドメインに前記アドレスを通知する際に、前記アドレスをすぐに前記位置管理ノードに登録するよう要求するステップを有する請求項５に記載の通信制御方法。
【請求項８】
前記アドレス通知ステップにおいて、前記移動端末が、前記ホームドメインに接続されている通信インタフェースの存在を確認するステップを有する請求項５に記載の通信制御方法。
【請求項９】
前記アドレス通知ステップにおいて、前記移動端末が、前記ホームドメインに接続されている通信インタフェースから前記ホームドメインに前記アドレスを通知する際に、前記アドレスの通知時刻を表す時間情報を、前記アドレスに係るバインディング情報に付加して前記位置管理ノードに通知するよう要求するステップを有する請求項５に記載の通信制御方法。
【請求項１０】
ネットワークベースのローカルモビリティ管理プロトコルが実装されているネットワークドメインを構成し、前記ネットワークドメインに接続されている移動端末の位置情報を管理する機能を有する位置管理ノードと、前記移動端末の位置情報の登録を代理して行う機能を有する代理登録ノードと、前記移動端末の認証を行う認証サーバとを有する通信システムにおいて、代理登録ノードとして機能するネットワークノードであって、
複数のプレフィックスに基づいて前記ネットワークドメインをホームドメインとする前記移動端末によって構成された複数のアドレスを前記移動端末から受信する手段と、
前記移動端末から通知された前記複数のアドレスのそれぞれに係るバインディング情報を前記位置管理ノードに登録する手段とを、
有するネットワークノード。
【請求項１１】
前記移動端末からの前記複数のプレフィックスの要求を受ける手段と、
前記移動端末からの前記複数のプレフィックスの要求に基づいて、前記複数のプレフィックスが前記移動端末に通知されるよう処理する手段とを、
有する請求項１０に記載のネットワークノード。
【請求項１２】
前記移動端末からの前記複数のプレフィックスの要求を受けた場合、前記認証サーバに前記移動端末の認証を依頼し、前記認証に成功した場合には、前記認証サーバから前記移動端末に割り当てられたドメインプレフィックスを受信するとともに、前記複数のプレフィックスを前記移動端末に通知する指示を前記認証サーバから受ける手段を有する請求項１１に記載のネットワークノード。
【請求項１３】
前記移動端末に通知される前記複数のプレフィックスとして、前記ドメインプレフィックス、前記移動端末の接続ポイントのオンリンクプレフィックス、前記登録代理ノードのアドレス又はプレフィックスから選択する手段を有する請求項１０に記載のネットワークノード。
【請求項１４】
前記位置管理ノードに登録する前記移動端末の前記バインディング情報として、前記ホームアドレス又は前記ドメインプレフィックスと前記代理登録ノード自身のアドレス又はプレフィックスとを関連付ける第１のバインディング情報、及び、前記ホームアドレスと前記オンリンクアドレスとを関連付ける第２のバインディング情報を利用する手段を有する請求項１０に記載のネットワークノード。
【請求項１５】
前記移動端末から通知された前記複数のアドレスのそれぞれに係るバインディング情報を前記位置管理ノードに登録する際に、前記移動端末から通知された前記複数のアドレスのそれぞれに係るバインディング情報を含む１つの登録メッセージを生成し、前記位置管理ノードに送信する手段を有する請求項１０に記載のネットワークノード。
【請求項１６】
前記複数のアドレスのそれぞれに係るバインディング情報に対して、前記位置管理ノードにおける使用の優先度を設定する手段を有する請求項１０に記載のネットワークノード。
【請求項１７】
前記移動端末が複数の通信インタフェースを有しており、前記複数の通信インタフェースのうちの少なくとも１つが外部ネットワークドメインに接続されている場合に、前記外部ネットワークドメインが接続されている通信インタフェースに対応して設定されるアドレスの通知を前記移動端末から受ける手段を有する請求項１０に記載のネットワークノード。
【請求項１８】
前記アドレスの通知と共に前記アドレスに係るバインディング情報をすぐに前記位置管理ノードに登録するよう要求する情報を前記移動端末から受信する手段を有する請求項１７に記載のネットワークノード。
【請求項１９】
前記バインディング登録手段は、前記移動端末から通知された前記アドレスに係るバインディング情報に、前記アドレスの通知時刻を表す時間情報を付加して前記位置管理ノードに登録するよう構成されている請求項１７に記載のネットワークノード。
【請求項２０】
前記アドレスの通知時刻を表す時間情報を前記アドレスに係るバインディング情報に付加するよう要求する情報を前記移動端末から受信する手段を有する請求項１９に記載のネットワークノード。
【請求項２１】
ネットワークベースのローカルモビリティ管理プロトコルが実装されているネットワークドメインを構成し、前記ネットワークドメインに接続されている移動端末の位置情報を管理する機能を有する位置管理ノードと、前記移動端末の位置情報の登録を代理して行う機能を有する代理登録ノードと、前記移動端末の認証を行う認証サーバとを有する通信システムに接続可能であり、前記ネットワークドメインをホームドメインとする移動端末であって、
複数のプレフィックスを取得する手段と、
前記複数のプレフィックスから複数のアドレスを取得する手段と、
前記複数のアドレスを通知して、前記ネットワークドメイン内の前記移動管理ノードに前記複数のアドレスのそれぞれに係るバインディング情報を登録させる手段とを、
有する移動端末。
【請求項２２】
前記複数のプレフィックスを取得する手段が、
前記ネットワークドメインに接続する際に、複数のプレフィックスを要求する手段と、
前記複数のプレフィックスの要求に応じて通知される前記複数のプレフィックスを受信する手段とを、
有する請求項２１に記載の移動端末。
【請求項２３】
前記複数のプレフィックスの要求に応じて受信したドメインプレフィックス及びグローバルプレフィックスから、前記ドメインプレフィックスを含むホームアドレスと、前記グローバルプレフィックスを含むグローバルアドレスとを構成する手段を有する請求項２１に記載の移動端末。
【請求項２４】
前記ホームアドレス及び前記グローバルアドレスの両方を通知するためのメッセージを生成し、前記移動端末が接続しているアクセスルータに前記メッセージを送信する手段を有する請求項２１に記載の移動端末。
【請求項２５】
前記移動端末が前記ホームドメインに接続されている状態において、前記レガシのコレスポンデントノードや別のネットワークドメインに存在するコレスポンデントノードとの通信に、前記複数のプレフィックスのうちのドメインプレフィックスによって構成されたホームアドレスを使用することを決定する手段を有する請求項２１に記載の移動端末。
【請求項２６】
前記移動端末が前記ホームドメインに接続されている状態において、同一の前記ホームドメインに接続されているコレスポンデントノードとの通信に、前記複数のプレフィックスのうちのオンリンクプレフィックスによって構成されたオンリンクアドレスを使用することを決定する手段を有する請求項２１に記載の移動端末。
【請求項２７】
前記移動端末が前記ホームドメインに接続されている状態において、同一の前記ホームドメインに接続されているコレスポンデントノードとの通信に、前記複数のプレフィックスのうちの前記登録代理ノードのアドレス又はプレフィックスを使用することを決定する手段を有する請求項２１に記載の移動端末。
【請求項２８】
前記移動端末が前記ホームドメインとは異なる外部ドメインに接続されている状態において、前記外部ドメインとは異なるドメインに存在するコレスポンデントノードとの通信に、前記外部ドメインから通知された外部ドメインプレフィックスにより構成された外部ドメインプレフィックスアドレスを使用することを決定する請求項２１に記載の移動端末。
【請求項２９】
前記移動端末が前記ホームドメインとは異なる外部ドメインに接続されている状態において、前記外部ドメインに存在するコレスポンデントノードとの通信における経路最適化処理に、前記外部ドメインから通知された外部ドメインプレフィックスにより構成された外部ドメインプレフィックスアドレスを使用することを決定する請求項２１に記載の移動端末。
【請求項３０】
複数の通信インタフェースを有しており、
前記複数の通信インタフェースのうちの少なくとも１つが外部ネットワークドメインに接続されている場合に、前記アドレス通知手段が、前記外部ネットワークドメインが接続されている通信インタフェースに対応して設定されるアドレスを、前記ホームドメインに接続されている通信インタフェースから前記ホームドメインに通知するよう構成されている請求項２１に記載の移動端末。
【請求項３１】
前記アドレス通知手段が、前記ホームドメインに接続されている通信インタフェースから前記ホームドメインに前記アドレスを通知する際に、前記アドレスをすぐに前記位置管理ノードに登録する要求を行うよう構成されている請求項３０に記載の移動端末。
【請求項３２】
前記アドレス通知手段が、前記ホームドメインに接続されている通信インタフェースの存在を確認するよう構成されている請求項３０に記載の移動端末。
【請求項３３】
前記アドレス通知手段が、前記ホームドメインに接続されている通信インタフェースから前記ホームドメインに前記アドレスを通知する際に、前記アドレスの通知時刻を表す時間情報を、前記アドレスに係るバインディング情報に付加して前記位置管理ノードに通知する要求を行うよう構成されている請求項３０に記載の移動端末。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、インターネットプロトコル（ＩＰ：Internet Protocol）を利用した通信技術に係る通信制御方法及びネットワークノード並びに移動端末に関し、特に、ネットワークベースのローカルモビリティ管理ドメイン（Network based Local Mobility Management Domain）内で移動端末（以下、モバイルノードと呼ぶこともある）が接続ポイントを変更しながら通信を行うシステムにおける通信制御方法及びネットワークノード並びに移動端末に関する。
【背景技術】
【０００２】
現在、多数のデバイスが、ＩＰｖ６（インターネットプロトコルバージョン６）を利用して、相互に通信を行っている。モバイル機器にモビリティサポートを提供するために、ＩＥＴＦ（Internet Engineering Task Force）では、ＭＩＰｖ６（Mobility Support in IPv6：ＩＰｖ６におけるモビリティサポート）に係る技術が開発されている（下記の非特許文献１参照）。
【０００３】
非特許文献１に記載されているモビリティサポートは、ホームエージェント（ＨＡ：Home Agent）として知られるエンティティを、ホームネットワークに導入することによって実践されている。モバイルノード（ＭＮ：Mobile Node）は、バインディングアップデート（ＢＵ：Binding Update）メッセージを使用して、ホームエージェントに気付アドレス（ＣｏＡ：Care-of Address）の登録を行う。このバインディングアップデートにより、ホームエージェントは、モバイルノードのホームアドレス（ＨｏＡ：Home Address）（ホームリンクにおいて取得されるアドレス）と気付アドレスとの間のバインディングを生成することが可能となる。ホームエージェントは、モバイルノードのホームアドレスあてのメッセージを受信（intercept）し、パケットのカプセル化（あるパケットを新たなパケットのペイロードとすることであり、パケットトンネリングとしても知られている）を用いて、そのパケットをモバイルノードの気付アドレスに転送する機能を担っている。
【０００４】
さらに、ＭＩＰｖ６では、コレスポンデントノード（ＣＮ：Correspondent Node）と通信する際の経路最適化（ＲＯ：Route Optimization）の方法が規定されている。このＲＯメカニズムによって、ＭＮは自身の気付アドレスをＣＮに登録することが可能となり、ＭＮとＣＮは、ＭＮのホームエージェントを経由せずに、ＭＮの気付アドレスを使用して相互に通信を行うことが可能となる。また、ＣＮは、リターンルータビリティ（ＲＲ：Return Routability）テストによって、ＭＮの気付アドレスの有効性を把握することが可能である。リターンルータビリティテストはＭＮから開始され、このリターンルータビリティテストによって、ＭＮの気付アドレスがＭＮのホームアドレスと関連している（すなわち、気付アドレス及びホームアドレスが同一のＭＮによって用いられている）ことがＣＮに証明される。なお、このＲＯメカニズムはオプションのメカニズムであり、ＣＮにおいてＲＯメカニズムの機能がサポートされている場合にのみ有用である。
【０００５】
ＭＩＰｖ６の問題の１つとして、ＭＮがネットワークへの接続ポイントを変更するたびに、ＨＡやＣＮ（いずれも複数存在し得る）に対してアップデートを行う必要があることが挙げられる。この問題によれば、例えばＭＮが高速で移動している場合には、そのＭＮの位置情報の変更に伴うシグナリングが短時間に大量に発生し、ネットワークに与える処理負荷が増加することになる。
【０００６】
さらに、ネットワークへの接続ポイントの変更の際にＲＲテスト及びＢＵメッセージの送信が行われるので、ネットワークへの接続ポイントが変更されるたびにＣＮとの間でハンドオフ時間が発生するという問題もある。ハンドオフが完了するまでにかなりの時間がかかることから、ＣＮとの通信におけるフローや接続に関連しているセッションにおいて、ジッタやパケットロスが発生してしまうことになる。ＶｏＩＰ（Voice over IP：ボイスオーバＩＰ）、マルチメディアストリーミング及びビデオストリーミングにとってジッタの発生は不都合であり、重要なテキストデータ情報を伝送するフローにとってパケットロスの発生は不都合である。なお、重要なテキストデータ情報を取り扱うアプリケーションに関してＴＣＰ（Transmission Control Protocol：トランスポート制御プロトコル）が使用された場合であっても、パケットロスによるパケットの再送が行われるため、ＴＣＰのスループットが低下することになる。
【０００７】
こうしたＭＩＰｖ６の課題を解決するため、端末ベースのローカルモビリティ管理プロトコル（terminal-based local mobility management protocol）が数多く提案されている。その中で最もよく知られているものの１つとして、ＨＭＩＰｖ６（Hierarchical Mobility Management Protocol version 6）が挙げられる。なお、現在このＨＭＩＰｖ６はＩＥＴＦ標準規格になっている。
【０００８】
例えばＨＭＩＰｖ６を始めとする端末ベースのローカルモビリティ管理プロトコルは、ＭＮの移動によって発生するシグナリング負荷（シグナリングによる帯域消費やシグナリング処理量の増加）の低減やハンドオフ遅延の低減を目的としている。しかしながら、こうした端末ベースのローカルモビリティ管理プロトコルでは、ＭＮは、ローカルモビリティ管理ドメイン内における接続ポイントの変更に関してもＭＡＰ（Mobility Anchor Point：モビリティアンカポイント）にＢＵを送信する必要がある。したがって、ＭＮは接続ポイントを変更するたびに、無線アクセスネットワークを通じて何らかのシグナリングを送信する必要があり、こうしたローカルドメインにおける位置情報のアップデートを行うシグナリングを送信するために、ＭＮのバッテリ電力が余分に消費されるという問題がある。
【０００９】
一方、ＩＥＴＦにおけるネットワークベースのローカルモビリティ管理（ＮＥＴＬＭＭ：Network-based local mobility management）ワーキンググループにおいて、端末ベースのローカルモビリティ管理プロトコルと同一の目的を実現するためのプロトコルに関する議論が行われている（例えば、下記の非特許文献２を参照）。ネットワークベースのローカルモビリティ管理プロトコルでは、端末ベースのローカルモビリティ管理シグナリングではなく、ネットワークベースのローカルモビリティ管理シグナリングが利用される。
【００１０】
ＮＥＴＬＭＭワーキンググループで議論されているネットワークベースのローカルモビリティ管理プロトコルの１つとして、プロキシモバイルＩＰｖ６（ＰＭＩＰｖ６：Proxy Mobile IPv6）が挙げられる。このプロトコルはＮＥＴＬＭＭワーキンググループにおいて最も支持されており、ネットワークベースのローカルモビリティ管理サービスに関する標準プロトコルとして採用される可能性がある。
【００１１】
ＰＭＩＰｖ６は、ＭＡＧ（Mobile Access Gateway：モバイルアクセスゲートウェイ）に備わっているプロキシモビリティエージェント（ＰＭＡ：Proxy Mobility Agent）の機能を用いて、ローカルドメインにおけるＭＩＰｖ６ベースのモビリティ管理を実現しようとする技術である。ＰＭＩＰｖ６は、主に、ＣＭＩＰｖ６（Client Mobile IPv6）スタックが実装されていないＩＰｖ６ホストに対して、ネットワークの局所的な場所におけるモビリティをサポートするために構築されたものである。なお、ＣＭＩＰは端末自身がモバイルＩＰの処理を行うものであり、ネットワーク側に存在する任意のプロキシノードが端末のモバイルＩＰの処理を代行するＰＭＩＰとは対極の概念である。
【００１２】
ＰＭＩＰｖ６は、ローカルドメインにおける位置管理シグナリングがネットワークによって完全に処理されるので、ＣＭＩＰｖ６スタックが実装されているノードにとっても有用である。グローバルな移動では、ＭＮのアドレスが変わると、ＭＮはＣＭＩＰスタックを利用して、関連する位置アップデートシグナリング（例えば、ＭＩＰｖ６のＢＵシグナリング）をＨＡやＣＮに送信する必要がある。一方、ＭＮは、ＰＭＩＰｖ６ローカルドメイン内で移動を行った場合には、プレフィックスは変更されずに同一のプレフィックスであることを把握し、その結果、位置登録シグナリングを行わない。
【００１３】
ＭＮがＰＭＩＰｖ６ドメインで使用するプレフィックスは、ローカルモビリティアンカ（ＬＭＡ：Local Mobility Anchor）によって管理されるネットワークから取得され、すなわち、ＬＭＡがこのプレフィックスの論理的なアンカポイントとなる。ローカルなＰＭＩＰｖ６ドメインでは、ＭＡＧがＭＮの代わりにＬＭＡへの位置登録シグナリングを行い、ＰＭＩＰｖ６ドメインにおけるＭＮのアドレス（ＰＭＩＰｖ６ドメインアドレス）又はＭＮに提供されたプレフィックスと、ＭＡＧ自身のイグレスインタフェースのアドレスとの関連付けが行われる。ＭＡＧは、ＭＮの接続を検出すると、基本的にＭＩＰｖ６のＢＵと同様の適切なプロキシシグナリングをＬＭＡに対して行う。
【００１４】
ＭＮのホームエージェントとＬＭＡが同一の装置によって実現されている場合には、このＰＭＩＰｖ６ドメインはＭＮのホームドメインであり、ＭＮはシグナリングを行う必要がないので、本来のＰＭＩＰｖ６サービスを受けることができる。一方、ＭＮが外部（foreign）ＰＭＩＰｖ６ドメインに存在し、ＭＮに対して外部プレフィックスが提供される場合には、ＭＮは外部ＰＭＩＰｖ６ドメイン内で新たに取得したアドレスをＨＡやＣＮにアップデートする必要がある。なお、このプロトコルの動作範囲は特定の管理ドメイン内であるが、その動作範囲が、より大きな規模に渡って広がる可能性がある。例えば、多数のオペレータが協力することで、全世界に広がる規模を有するグローバルなＰＭＩＰｖ６ドメインが形成される可能性もある。
【００１５】
ＭＮは、ＰＭＩＰｖ６ドメイン内に移動するとローカルプレフィックスを取得する。通常、ＡＡＡ（Authorization, Authentication and Accounting：認証、認可、課金）サーバにおいてＭＮの認証が行われた後に、ローカルプレフィックスがＭＮに提供される。ＭＮに提供されるローカルプレフィックスは、ＭＮごとに固有のプレフィックスであってもよく、ＬＭＡのアドレスのプレフィックスと同一である共有のプレフィックスであってもよい。ＭＮごとに固有のプレフィックスが提供される場合には、ステートフル又はステートレスのアドレス構成モードによって、アドレス構成が行われる。一方、共有のプレフィックスがＭＮに提供される場合には、ＰＭＩＰｖ６ドメインにおいてＭＮによって重複したアドレスが生成されてしまう問題を回避するため、ステートフルのアドレス構成がより望ましい。
【００１６】
ＰＭＩＰｖ６の主要な欠点は、そのサービスがグローバルネットワークの局所的な場所で提供されるので、グローバルな移動（ＰＭＩＰｖ６ドメインを越える移動）を行おうとしているＭＮは、下記の特許文献３に記載されているように、ＰＭＩＰｖ６及びＭＩＰｖ６を同時に使用しなければならない点にある。さらに、ＰＭＩＰｖ６サービスはローカルドメインに制限されているため、異なるＰＭＩＰｖ６ドメイン同士が協力し合っていない場合には、ＩＰｖ６ホストに対して本当の意味でのグローバルモビリティを実現することができないという問題がある。
【００１７】
また、ＰＭＩＰｖ６は、移動しているＩＰｖ６ホストの経路最適化に関する問題も有している。ＣＭＩＰノード（すなわち、ＭＩＰに係る動作を実行するＭＮ）は、アドレス変更時には常にＣＮとの間でＲＯを実行することが可能である。一方、ＲＯ機能を有さないＩＰｖ６ホストがＲＯを行うためには、ネットワーク上に存在する別のエンティティの援助を必要とする。下記の非特許文献４には、ＰＭＩＰｖ６ドメインのＩＰｖ６ホストに関して、ＲＯを実現する方法が開示されている。非特許文献４では、ＩＰｖ６ホストとそのＣＮとの間でＰＭＡによってＲＯが行われる。
【００１８】
また、３ＧＰＰ（Third Generation Partnership Project：第３世代パートナーシッププロジェクト）では、ＷＬＡＮ（無線ローカルエリアネットワーク）、セルラネットワーク（３Ｇ）、ＷｉＭＡＸタイプの無線ワイドエリアネットワーク（ＷＷＡＮ）などの様々な無線アクセスネットワークとの通信機能を有するグローバルな異種ネットワーク通信装置に関する議論が行われている。特に、異種ネットワーク通信装置におけるシームレスなモビリティの実現や、リアルタイムビデオ、ＶｏＩＰ、重要データなどの高いＱｏＳ（Quality of Service：サービス品質）が求められている複数のアプリケーションサービスのサポートなどを目指した議論が行われている。
【００１９】
下記の非特許文献５に開示されているように、ユーザ機器（ＵＥ：User Equipment）が様々なローカル管理ドメイン（様々なタイプのアクセスネットワーク及びコアネットワークによって特徴付けられる）内を効率良く移動できるようにするため、３ＧＰＰは適切なモビリティ管理メカニズムに順応できることが重要である。
【００２０】
３ＧＰＰでは、アクセスネットワークは、レガシの３ＧＰＰアクセスネットワーク（ＧＰＲＳ：General Packet Radio System／ＵＭＴＳ：Universal Mobile Telecommunications System）、次世代３ＧＰＰアクセスネットワーク（evolved 3GPP access network）、信頼できる非３ＧＰＰアクセスネットワーク（trusted non-3GPP access network（trusted WiMAX access network））、Ｉ−ＷＬＡＮ（interworking WLAN：ｅ−ＰＤＧ（evolved Packet Data Gateway）と呼ばれる信頼できるゲートウェイ経由でＷＬＡＮからの信頼できないアクセスを可能とする）に分類することができる。
【００２１】
非特許文献５には、３ＧＰＰにおいて、複数の異なるタイプのネットワークのローカルモビリティ管理に関して、ＰＭＩＰｖ６の使用が最も適切であると記載されている。その理由として、上述のようなＰＭＩＰｖ６特有の利点に加えて、ＭＩＰｖ６機能が実装されていない３ＧＰＰのレガシＵＥであっても、３ＧＰＰネットワークの局所的な場所においてネットワークベースのローカルモビリティ管理を実現できることが挙げられる。
【００２２】
また、下記の特許文献１には、ＭＮに２つのプレフィックスを通知する方法が開示されている。ここでは、ＭＮに通知される一方のプレフィックスはローカルプレフィックスであり、ＡＲから通知されるプレフィックス、又はＡＲのアドレスに関連したプレフィックスである。もう一方のプレフィックスは、ＭＡ（Mobility Agent：モビリティエージェント）のアドレスである。なお、ＭＮがＭＡのアドレスを受信するローカルネットワークセグメントは、ローカルモビリティドメインと呼ばれる。
【００２３】
ＭＮは、通知された２つのプレフィックスに基づいて２つの気付アドレスを構成する。ＭＮがＡＲに関連したプレフィックス及びＭＡプレフィックス（ＭＡのアドレスに関連したプレフィックス）から構成したアドレスは、それぞれローカルアドレス及びグローバルアドレスと呼ばれる。ＭＮは、ローカルドメイン内でサブネットワークを変更するたびにローカル気付アドレスを生成し、そのローカルアドレスをＭＮのグローバルアドレスと関連付けてＭＡに通知する。また、ＨＡ又はＣＮには、モビリティエージェントが変わった場合にのみ通知が行われる。ＨＡ又はＣＮに通知されるバインディングは、ＭＮのホームアドレスとＭＮのグローバルアドレスとのバインディングである。
【００２４】
また、下記の非特許文献６に開示されているようなＩＥＴＦのＭＯＮＡＭＩ６（Mobile Nodes and Multiple Interfaces in IPv6）ワーキンググループでは、複数のインタフェース（マルチインタフェース）を有するモバイルノードに対して、マルチモードの利点を十分に発揮できるような機能が提供されている。マルチインタフェースノードは、インタフェースで取得した複数の気付アドレス（Care-of address）をホームエージェントに登録することができる。これによって、ホームエージェントは、モバイルノードが複数の経路を経由して到達可能であることを把握できるようになる。それまでのＭＩＰｖ６標準規格によれば、ホームエージェントには１つのプライマリ気付アドレスしか登録できなかったが、この非特許文献６では、複数の気付アドレス（ＭＣｏＡ：Multiple CoA）の登録を行うシグナリングにバインディング識別子（ＢＩＤ；Binding Identifier）オプションと呼ばれる追加オプションを設けることで、１つのホームアドレスに対して複数の気付アドレスを関連付ける旨が開示されている。なお、ここで、１つのホームアドレスに対し複数の気付アドレスを登録することをＭＣｏＡ登録と呼ぶ。
【００２５】
また、下記の特許文献２には、階層的（ローカルモビリティ及びグローバルモビリティ）なモビリティ管理環境において、経路最適化及び位置プライバシー（位置の隠蔽）を実現する方法が開示されている。ローカルモビリティアンカの配下のローカルモビリティ管理セグメント内を移動するＭＮは、そのローカル気付アドレスをＬＭＡに登録するか、あるいは、プロキシ方法によってＡＲがＭＮのプロキシとして動作し、ＭＮのローカル気付アドレスをＬＭＡに登録する。このようなローカル登録が行われる場合には、ＬＭＡにはＭＮのＨＡアドレスが通知される。ＬＭＡは、バインディングアップデートによって、ＬＭＡのアドレスをＭＮの気付アドレスとしてＭＮのホームエージェントに通知する。これにより、ＣＮから送られてくるパケットはＨＡによって受信（intercept）され、ＬＭＡにトンネルされる。また、プロキシ登録モードが有効である場合には、ＬＭＡは、ＭＮ又はＡＲにパケットをトンネルする。
【００２６】
また、特許文献２においては経路最適化の問題が取り扱われている。ここでは、ＣＮ側のゲートウェイ（ＣＮと接続しているゲートウェイ）がＨＡに対して、ＭＮの現在の気付アドレスに関する問い合わせを行うことが可能である。この問い合わせに対して、ＨＡからは、ＭＮの現在の気付アドレスとしてＬＭＡのアドレスが通知される。ＨＡからＬＭＡのアドレスが提供されると、経路最適化のためにＣＮ側のゲートウェイノードとＬＭＡとの間でトンネルが形成される。
【００２７】
また、下記の特許文献３に開示されている技術では、クライアント又はＭＮがＡＲに対してサブネットワークが変更されたか否かを要求した場合には、たとえサブネットワークが変更された場合であっても、ＡＲはホームプレフィックスのみを通知するように構成されている。これにより、ＭＮはサブネットワークの変更に伴うアドレス生成を行わなくなり、セッションが中断されないようにすることが可能となる。
【００２８】
また、今後、モバイルノードは、ＷＬＡＮインタフェース、３Ｇインタフェース、ＷｉＭＡＸインタフェースなどの異なるアクセスタイプのインタフェースを複数備える可能性がある。このように、複数の異なる種類のインターフェースタイプを備えることで、ＭＮにおいて、負荷共有や負荷バランス、コスト低減やＱｏＳ向上のための優先度設定、フォールトトレランス、信頼性などを始めとするマルチホーミングの利点が実現されるようになる。ＭＮが複数のインタフェースを備えており、すべてのインタフェースが外部ドメインに接続されている場合には、ＭＮは、通常すべての気付アドレスをＨＡに登録することによって、マルチホーミングのサポートが実現されるようになる。
【００２９】
また、例えば非特許文献６には、ＭＮがバインディング識別子（ＢＩＤ：Binding Identifier）オプションを用いて複数の気付アドレス（ＣｏＡ）を登録する方法や、ＭＮが複数のインタフェースのバインディングに関するＨＡへのバルク登録（bulk registration）を単一のＢＵメッセージによって実行できるようにする方法が記載されている。
【００３０】
例えば図１１Ａに図示されているような複数の異なる種類のインタフェースを備えたＭＮ２６０Ａに関連して、複数の位置登録シグナリングが行われる必要がある。ここで、図１１Ａにおいて、ＭＮ２６０Ａは、３ＧＰＰネットワークや３ＧＰＰオペレータに由来する１つ又は複数のホームアドレスを構成する３ＧＰＰ対応端末であると仮定する。さらに、ＭＮ２６０Ａは、２つのインタフェース（インタフェース１（ＩＦ１）及びインタフェース２（ＩＦ２））を備えていると仮定する。なお、ＭＮ２６０ＡのＩＦ１はホームＰＭＩＰドメイン２５０Ａ（ＭＡＧ２６５Ａ）に接続されており、ＭＮ２６０ＡのＩＦ２は別の外部ＰＭＩＰドメイン２５１Ａ（ＭＡＧ２６７Ａ）に接続されている。また、これらのホームＰＭＩＰドメイン２５０Ａ及び外部ＰＭＩＰドメイン２５１Ａがインターネット２５２Ａに接続されており、このインターネット２５２Ａに接続されているＣＮ２７５Ａが、ＭＮ２６０Ａとの間でパケット通信セッションを有していると仮定する。
【００３１】
図１１Ａにおいて、ＭＮ２６０Ａに関するＭＩＰｖ６のホームエージェントは、ホームＰＭＩＰドメイン２５０Ａに位置するＬＭＡ／ＰＤＮ−ＧＷ（ＬＭＡ／ＰＤＮ−ＧＷ／ＨＡ）２７０Ａである。また、図１１Ａにおいて、ＭＮ２６０Ａのインタフェース１は、無線リンクを通じてＭＡＧ２６５Ａに接続されており、ＭＮ２６０Ａのインタフェース２は、無線リンクを通じてＭＡＧ２６７Ａに接続されている。なお、以下では、このようなシナリオに関して説明を行うが、当業者であれば、このシナリオに限定されずに様々なシナリオに対して解釈することが可能である。例えば、ＭＮ２６０ＡとＭＡＧ（ＭＡＧ２６５ＡやＭＡＧ２６７Ａ）とが接続するアクセス技術は、例えばＷＬＡＮ、ＷｉＭＡＸ、３Ｇなどを始めとする任意のアクセス技術を用いることが可能である。
【００３２】
また、ＭＮ２６０Ａは、何らかのマルチホーミングがサポートされているとする。ＭＮ２６０Ａは、ホームドメイン２５０Ａ内に存在する場合には、例えば両方のインタフェースに同一のホームアドレスを設定してもよく、両方のインタフェースのそれぞれに異なるホームアドレスを設定してもよい。
【００３３】
また、ここでは、このシナリオにおける主要な問題点を示すため、ＭＮ２６０ＡがＩＦ１及びＩＦ２両方のインタフェースに同一のホームアドレスを設定しており、ＩＦ１及びＩＦ２に関するアクセスルータの変更を同時に行うように移動すると仮定する。以下では、このような移動をインタフェースの同時移動と記載する。このような同時移動は、例えばＩＦ２がＷＬＡＮに接続されており、ＩＦ１がＷｉＭＡＸセルなどのような小さなセルに接続されている場合に起こり得る。ここで、こうした同時移動が起こった場合に、ＭＮ２６０ＡのＩＦ１がＭＡＧ２６５ＡやホームＰＭＩＰドメイン２５０Ａ内のその他のＭＡＧに接続すると仮定する。この接続の結果、ＭＡＧ２６５Ａ（あるいは、ＭＮ２６０ＡのＩＦ１が接続したホームＰＭＩＰドメイン２５０Ａ内のその他のＭＡＧ）は、ＭＡＧ２６５ＡのイグレスアドレスとＭＮ２６０Ａのホームプレフィックスとのバインディングを行うプロキシバインディングアップデート（ＰＢＵ：proxy binding update）２８０Ａを送信する。
【００３４】
また、この同時移動によって、ＭＮ２６０Ａは、ＬＭＡ／ＰＤＮ−ＧＷ２７１Ａから割り当てられたＭＮごとにユニークなプレフィックスを用いてＩＦ２に関する新たな気付アドレスを構成する。そして、ＭＮ２６０Ａは、ＩＦ２からＣＭＩＰに関するＢＵを実行する。
【００３５】
また、非特許文献６には、ＭＮがバルク登録を行うことによってＭＮのＣｏＡをＨＡに登録する最適な方法が開示されている。バルク登録では、複数のインタフェースのバインディングが１つのシグナリングメッセージによって送信される。ＭＮは、どのインタフェースがバルク登録を行うために理想的なインタフェースかを把握することができないため、バルク登録はＭＮのインタフェースのどちらにおいても実行可能である。なお、バルク登録を行うために理想的なインタフェースは、ＭＮが迅速なバルク登録を実行することができるインタフェースである。ＭＮのあるインタフェースがホームドメインに接続されており、別のインタフェースが外部ドメインに接続されている場合には、“Ｈ”フラグが付加されたＣＭＩＰに関するＢＵが外部ドメインに接続しているインタフェースから送信される。
【００３６】
また、下記の特許文献４には、ＭＮがスリープモードであるか、あるいは到達不能な状態の場合に、プロキシサーバがＭＮのパケットを受信するために用いられる方法が開示されている。この方法を使用した場合、ＭＮは、ＨＡへの位置更新シグナリングの送信をＨＡにあえて実行しなくてもよく、スリープモードに移行してプロキシサーバからデータを取得することが可能である。
【００３７】
また、下記の特許文献５には、ファストハンドオフを実行するとともに、遅延やパケットロスなどのハンドオフに関連する問題を解決するための方法が開示されている。ここでは、ＭＮに関する正しいバインディングやＭＮの位置などとは無関係に、ＭＮに関連するパケットは、常にあるノードのグループに送信されるようにすることによってファストハンドオフが実現される。ＭＮが新しいアクセスルータ（ＡＲ：Access Router）に接続する前に、その新しいアクセスルータはＭＮあてのパケットを受信することができる。ＭＮが新しいＡＲに接続しなかった場合には、パケットはそのＡＲで破棄されることになる。また、ＭＮが他のＡＲに接続した場合でも、そのパケットを受信することが可能となる。
【００３８】
特許文献５に開示されている技術では、基本的にファストハンドオフを実現するため、ＭＮのデータパケットをあるＡＲのグループへマルチキャストする方法が行われる。すなわち、この方法では、ＭＮが接続されているか否かに関係なく、ＭＮのパケットは１つ以上の基地局ノードやアクセスルータに送信される。ＭＮの正確な位置を予測するのは困難なので、基地局ノードやプロキシのグループに対して、ＭＮに送信されるべきパケットが渡される。
【００３９】
また、下記の特許文献６には、ＭＮが自身の気付アドレスとしてフォーリンエージェント（ＦＡ：Foreign Agent）に関連するプロキシ気付アドレス（プロキシ関連ＣｏＡ）を使用する方法について開示されている。このプロキシ関連ＣｏＡは、ＦＡから各ＭＮに対して提供される。このようなアドレス構成を行うことで、カプセル化及びデカプセル化が、ＭＮではなくフォーリンエージェントで実行されるようになる。
【００４０】
さらに、ＦＡの機能がＡＲに実装される場合、ＭＮのＣｏＡとしてプロキシ関連ＣｏＡを使用する方法によれば、ＭＮにおけるトンネリングのカプセル化及びデカプセル化の処理負荷がなくなり、負荷が大きい無線リンクにおけるトンネリングが行われないようにすることが可能となる。
【特許文献１】米国特許公開２００４００２４９０１
【特許文献２】国際特許公開ＷＯ０６／０１２５１１
【特許文献３】国際特許公開ＷＯ０７／０５０６２４
【特許文献４】米国特許公開２００４００１３０９９
【特許文献５】国際特許公開ＷＯ０３／０９０４０８
【特許文献６】国際特許公開ＷＯ０２／０６５７３１
【非特許文献１】Johnson, D. B., Perkins, C. E., and Arkko, J., "Mobility Support in IPv6", Internet Engineering Task Force Request For Comments 3775, June 2004.
【非特許文献２】Gundavelli, S., et. al., "Proxy Mobile IPv6", Internet Engineering Task Force (IETF) Working Group Draft: draft-sgundave-mip6-proxymip6-02.txt, March 5, 2007.
【非特許文献３】Soliman, H., et. al., “Interactions between PMIPv6 and MIPv6: scenarios and related issues” Internet Engineering Task Force (IETF) Working Group Draft: draft-giaretta-netlmm-mip-interactions-00, April 24, 2007.
【非特許文献４】Qin, A., et. al., "PMIPv6 Route Optimization Protocol", Internet Engineering Task Force Working Group Draft: draft-qin-mipshop-pmipro-00.txt, February 25, 2007.
【非特許文献５】“3GPP System Architecture Evolution: Report on Technical Options and Conclusion”, 3GPP TR 23.882, V1.9.0, April 3, 2007.
【非特許文献６】Wakikawa, R., et. al., " Multiple Care-of Addresses Registration", Internet Engineering Task Force Working Group Draft: draft-ietf-monami6-multiplecoa-02.txt, March 5, 2007.
【発明の開示】
【発明が解決しようとする課題】
【００４１】
以下、図１を参照しながら、３ＧＰＰシステムにおけるＰＭＩＰｖ６プロトコルの概要やその問題点について説明する。なお、ＵＥは３ＧＰＰで使用される用語であり、ＭＮはＩＥＴＦで使用される用語であるが、本明細書では、上記のＵＥ及びＭＮの両方の移動ホスト（移動端末）をＭＮ（モバイルノード）と表記する。
【００４２】
図１には、様々な公共モバイルネットワーク（ＰＬＭＮ：Public Land Mobile Network）によって構成されている次世代（evolved）３ＧＰＰシステムが図示されている。図１に図示されているアクセスネットワークは、信頼性の無いＷＬＡＮタイプのネットワークである。通常、ＰＬＭＮは、コアネットワーク及びアクセスネットワークに特徴を有しており、３ＧＰＰでは、ＰＭＩＰｖ６もこうしたＰＬＭＮに導入されることになる。ＰＬＭＮのアクセスネットワークが次世代（evolved）３ＧＰＰ又はレガシの３ＧＰＰタイプのアクセスネットワークであれば、ＰＬＭＮは同一のオペレータによって管理される可能性が高く、ルータは同一のルートプレフィックスによって構成されたアドレスを有する可能性が高い。しかしながら、ＭＮが信頼性の無いＷＬＡＮを介して３ＧＰＰコアネットワークにアクセスを行おうとする場合には、そのＷＬＡＮセグメントは、異なるオペレータによって管理されている可能性があり、したがって、アクセスネットワークはインターネットに直接接続される可能性がある。
【００４３】
信頼性の無い３ＧＰＰアクセスやＷＬＡＮアクセスが行われたとき、アクセスネットワークがインターネットへ直接接続されていない場合や、データトラフィックのエンド受信者が３ＧＰＰコアネットワーク内に位置している場合に、３ＧＰＰコアネットワークを経由する必要があるトラフィックは、ｅＰＤＧと呼ばれる信頼性のあるゲートウェイを経由しなければならない。
【００４４】
図１では、３ＧＰＰシステムにおけるＰＭＩＰｖ６プロトコルの問題を説明するために、１つのＰＬＭＮを１つのオペレータが管理しているとする。図１において、ＰＬＭＮ１は３ＧＰＰコアネットワーク１０１とＩ−ＷＬＡＮタイプのアクセスネットワーク（Ｉ−ＷＬＡＮアクセスネットワークと記載）１０３とを有している。
【００４５】
３ＧＰＰコアネットワーク１０１は、ＬＭＡ／ＰＤＮ−ＧＷ５０及びローカルの３ＧＰＰ ＡＡＡサーバ６０を有している。なお、ここではＬＭＡがＰＤＮ−ＧＷ（Packet Data Network Gateway：パケットデータネットワークゲートウェイ）として機能するものとする。ローカルの３ＧＰＰ ＡＡＡサーバ６０は、移動中のＭＮの認証情報を有しており、ＭＮが３ＧＰＰコアネットワーク１０１のサービスやＰＭＩＰｖ６サービス（ＰＬＭＮにＰＭＩＰｖ６が導入されている場合）を受けることが可能か否かを認証する。
【００４６】
また、ＰＬＭＮ１のＩ−ＷＬＡＮアクセスネットワーク１０３は、ｅＰＤＧ／ＭＡＧ４０、ＡＲ２０、ＡＲ２１を有している。なお、ここでは、ｅＰＤＧにＭＡＧの機能が備わっているとする。信頼性の無いＷＬＡＮのシナリオにおいては、ｅＰＤＧにＭＡＧの機能が備わっている必要がある。これは、ｅＰＤＧが、ＷＬＡＮに属するルータの中で、３ＧＰＰコアネットワークが信頼できる唯一のルータであることによる。また、ＰＬＭＮ１にはＰＭＩＰｖ６が導入されており、ＭＮ１０がこのネットワークに接続されているとする。また、このＰＬＭＮ１では、ＭＮ１０がＡＲ２０に接続されている。
【００４７】
また、ＰＬＭＮ２も同様に、３ＧＰＰコアネットワーク１０２とＩ−ＷＬＡＮアクセスネットワーク１０４とを有しており、３ＧＰＰコアネットワーク１０２も同様に、ＬＭＡ／ＰＤＮ−ＧＷ５１及び３ＧＰＰ ＡＡＡサーバ６１を有している。また、Ｉ−ＷＬＡＮアクセスネットワーク１０４は、ｅＰＤＧ／ＭＡＧ／ＡＲ３０、３１を有している。なお、ここでは、ＡＲにｅＰＤＧやＭＡＧの機能が備わっているとする。また、このＰＬＭＮ２では、ＭＮ１１がｅＰＤＧ／ＭＡＧ／ＡＲ３０に接続されている。また、ＰＬＭＮ１、ＰＬＭＮ２（３ＧＰＰコアネットワーク１０１、１０２）はグローバル通信ネットワーク１００に接続されている。
【００４８】
ＰＭＩＰｖ６が実装されているＰＬＭＮ１において、ＭＮ１０がＩ−ＷＬＡＮアクセスネットワーク１０３に接続する際に受信するプレフィックスは、ＡＲ２０のオンリンクプレフィックスである。これは、ＡＲ２０にはＭＡＧの機能（３ＧＰＰの信頼性のあるゲートウェイｅＰＤＧに実装されている必要がある）が実装されていないことにより生じる。この場合、ＭＮ１０は、このプレフィックスがローカルブレイクアウト（下記のように、ＭＮ１０のホームドメインを経由しないパケット伝送）や経路最適化（モバイルＩＰにおけるＣＮへのＣｏＡ登録）に適しているか否かを把握することができない。また、ＭＮ１０はこのプレフィックスの性質（このプレフィックスがオンリンクプレフィックスであること）を把握できたとしても、ＰＭＩＰｖ６ドメインプレフィックスを取得していないので、このＰＬＭＮ１においてＰＭＩＰサービスを受けることができないという問題がある。
【００４９】
なお、ローカルブレイクアウトとは、外部（foreign）ドメインに接続している時にホームドメインまで戻る経路をとらず、ＣＮと通信することを指し、ＭＮがホームドメイン以外のオペレータのドメインへの接続状態にある場合、本来ならば、インターネット上のＣＮと通信する際にホームドメインに存在するＬＭＡ（ＰＤＮ？ＧＷなど）を経由しなければならないものを、接続している外部のドメインから（外部ドメインもまたＰＭＩＰドメインを構成していればそのドメインのＬＭＡを経由して）直接インターネット上のＣＮと通信する（breakout）ことを意味する。さらに、本明細書においては、ローカルブレイクアウトという用語をより広義に用い、ローカルブレイクアウトという表現には、ＭＮが接続しているドメインがホーム／外部であることを問わず、また、アクセスネットワークの種別を問わずに、（インターネットから）グローバルに到達可能なアドレスを使って、ホームドメインを経由しないでインターネット上のＣＮと通信することも含まれるものとする。
【００５０】
一方、ＰＭＩＰｖ６が実装されているＰＬＭＮ２では、ＭＡＧ及びｅＰＤＧの機能はＡＲに実装されているので、ｅＰＤＧ／ＭＡＧ／ＡＲ３０が通知するプレフィックスはＰＭＩＰｖ６ドメインプレフィックスである。この場合においても、ＭＮ１１は、このプレフィックスがローカルブレイクアウトに適しているか否かを把握することができない。また、ＭＮ１１がこのプレフィックス（ＰＭＩＰｖ６ドメインプレフィックス）を使用した場合には、ＭＮ１１と同一ＰＭＩＰｖ６ドメイン（ＰＬＭＮ２）に接続されているＣＮとの間で行われる通信はＬＭＡ経由となり、ＭＮ１１とＣＮとの間でＲＯを実現することができない。
【００５１】
以下、図２を参照しながら、ＰＭＩＰｖ６が実装されているＰＬＭＮ内をＭＮが移動した場合に生じる問題について説明する。図２において、ＭＮ２１０はＰＭＩＰｖ６ドメイン２００に接続されており、このＰＭＩＰｖ６ドメインがＭＮ２１０のホームドメインであるとする。したがって、この場合においても、ＬＭＡがＭＮ２１０のホームエージェント（ＨＡ）として機能する。また、３ＧＰＰでは、ＳＡＥ（Service Architecture Evolution）アンカがＭＩＰｖ６のホームエージェントとして機能することが可能であり、ＬＭＡ機能が実装されたルータとして機能することも可能である。すなわち、図２では、ＬＭＡ／ＨＡ／ＳＡＥアンカ２３０が、ＬＭＡ、ＭＮ２１０のＨＡ、ＳＡＥアンカのすべての機能を有している。
【００５２】
ここで、ＭＮ２１０が、同一のＰＭＩＰｖ６ドメイン２００に接続されているＣＮ２１１と通信を行っているとする。また、ＣＮ２１１はＲＯ可能（RO enabled）であり、このＰＭＩＰｖ６ドメイン２００に加入しているとする。なお、ＲＯ可能とは、ＣＮ２１１がＣＭＩＰタイプのＲＯを実行できることを意味する。また、ＭＮ２１０は、さらにＣＮ２１３及びＣＮ２１２と通信を行っている。なお、ＣＮ２１３はインターネット（あるいは公共パケットデータネットワーク）２０１上に存在しているＲＯ可能なノードであり、ＣＮ２１２はＲＯ機能を有さないノードであるとする。
【００５３】
さらに、ここでは、ＭＮ２１０が、同一のインタフェースに複数の異なるアドレスを構成することができるマルチホーミング可能なノードであるとする。ＭＮ２１０がこのＰＭＩＰｖ６ドメイン２００に移動して、アクセスルータであるＭＡＧ２２０に接続し、ＭＡＧ２２０のオンリンクプレフィックス及びＰＭＩＰｖ６ドメインプレフィックスの両方を受信した場合、ＭＮ２１０は２つのアドレスを構成する可能性がある。例えば、ＭＮ２１０はＣＮ２１１やＣＮ２１３などのＲＯ可能なＣＮと通信を行っているので、経路最適化を行うためにグローバルプレフィックス（オンリンクプレフィックス）の使用を望む可能性がある。一方、ＭＮ２１０はホームドメインに存在しているので、そのホームプレフィックスを使用してホームアドレスを構成することで、例えばＣＮ２１２などのレガシＣＮとの通信における最適化された経路の実現を望む可能性もある。
【００５４】
このようなアドレス構成が行われると、ＭＮ２１０はホームエージェント（ＬＭＡ／ＨＡ／ＳＡＥアンカ２３０）にバインディングアップデートを行うことになる。このＢＵはＣＭＩＰタイプのＢＵである。また同様に、ＭＡＧ２０はＬＭＡ（ＬＭＡ／ＨＡ／ＳＡＥアンカ２３０）にプロキシバインディングアップデート（ＰＢＵ：proxy binding update）を送信し、ＭＮ２１０のホームアドレス（ＰＭＩＰｖ６ドメインアドレス）とＭＡＧ２０のイグレスインタフェースのアドレスとの関連付けが行われる。このＢＵはＰＭＩＰタイプのＢＵである。
【００５５】
図２においては、ＭＮ２１０がＭＡＧ２２０に接続された際にＭＮ２１０からＬＭＡ／ＨＡ／ＳＡＥアンカ２３０に送信されるＢＵは、シグナル２４０によって示されている。一方、ＭＡＧ２２０からＬＭＡ／ＨＡ／ＳＡＥアンカ２３０に送信されるＰＢＵはシグナル２４１によって示されている。ＭＮ２１０がさらにＰＭＩＰｖ６ドメイン内を移動した場合（例えば、ＭＡＧ２２１やＭＡＧ２２２に接続した場合）においても同様に、２重のＢＵシグナリング（ＣＭＩＰのＢＵシグナリング及びＰＭＩＰのＰＢＵシグナリング）が発生することになる。こうしたＭＮ２１０の移動に関連するシグナリングは、図２において、ＢＵシグナリング（シグナル２４２、２４４）、ＰＢＵシグナリング（シグナル２４３、２４５）によって示されている。この結果、ＭＮ２１０の移動に伴って（特に、ＭＮ２１０が高速移動した場合に）ＰＭＩＰｖ６ドメイン２００内には、特定の目的の一連のシグナリング（ここではＢＵやＰＢＵにかかわるシグナリング）が高頻度で発生し、他の通信のリソースを消費してしまうことで、データパケットの遅延や帯域不足などが発生してしまう、シグナリングストーム（ＢＵストーム）と呼ばれる状況が引き起こされることになる。
【００５６】
ＭＮ２１０がローカルブレイクアウト用のグローバルプレフィックスを把握している場合には、ＭＮ２１０は、ＣＮ２１１やＣＮ２１３との間でＲＯを実行することが可能である。この場合、経路最適化されたデータパスはそれぞれパス２４６、２４８のようになる。また、ＭＮ２１０は、ＣＮ２１２と通信を行う際には、ＰＭＩＰｖ６ドメインプレフィックスを使用する。ＭＮ２１０からＣＮ２１２へのデータパケットはＭＡＧ２２０に送信され、ＭＡＧ２２０からＬＭＡ２３０にトンネルされる。ＬＭＡ２３０は、パケットをデカプセル化し、デカプセル化されたパケットをＣＮ２１２に送信する。
【００５７】
上述のように、従来の技術には２種類の問題が存在している。第１の問題は、ＰＭＩＰｖ６ドメイン内を移動しているＭＮは、ＡＲにＭＡＧやｅＰＤＧの機能が備わっていない場合にはＰＭＩＰｖ６ドメインプレフィックスを把握できない可能性があり、ＡＲにＭＡＧやｅＰＤＧの機能が備わっている場合にはオンリンクグローバルプレフィックスを把握できない点にある。すなわち、従来の技術においては、ＭＮは、様々な異なるタイプのＣＮと効率良く通信を行うために選択すべき様々なプレフィックス（複数のプレフィックス）を把握することができないという問題がある。また、第２の問題は、仮にＭＮが利用可能なプレフィックスから複数のタイプのアドレス（例えばＰＭＩＰタイプのアドレスとＣＭＩＰタイプのアドレス）を構成できたとしても、上述のように２重のＢＵシグナリング（ＢＵシグナリング及びＰＢＵシグナリング）によるＢＵストームが発生してしまうという点にある。
【００５８】
また、上述の特許文献１においては、ローカルブレイクアウト用にどのアドレスを選択すべきかに関する問題について言及されていない。すなわち、特許文献１におけるＭＮは、ＣＮやＨＡと通信を行うために使用されるアドレス（グローバルアドレス）や、ＭＡへの位置登録に使用されるアドレス（ローカルアドレス）しか把握できず、複数のアドレス（又はプレフィックス）の中からどのアドレス（又はプレフィックス）を選択すると、通信の効率化（経路の最適化）が実現されるかに関する問題について言及されていない。さらに、特許文献１では、ローカルドメイン内における経路最適化の問題に関して言及されていない。モビリティは完全にＭＮによって処理されるため、上述のような２重のシグナリングが生じる問題（図２に示されている問題）は、この特許文献１に記載のシステムでは起こらない。
【００５９】
また、上述の特許文献２においては、ＣＮ側のゲートウェイノードとＬＭＡとの間の経路最適化に関しては言及されているが、ＬＭＡの配下における経路最適化の問題に関しては取り扱われていない。また、特許文献２に開示されている技術では、ローカルモビリティ管理はＭＮ又はＡＲによって処理され、グローバルモビリティ管理はＬＭＡによって処理される。これは、図１及び図２に図示されているシナリオや、本発明が動作するシナリオとは大きく異なっている。また、特許文献２においては、ローカルブレイクアウト用にどのアドレスが使用されるべきかという問題についてまったく言及されていない。特許文献２に開示されている技術では、ＭＮが把握しているアドレスはローカルアドレスのみであり、また、経路最適化はＬＭＡ自身によって処理される。すなわち、特許文献２に開示されている技術は、ＭＮが様々なプレフィックスやアドレスの選択を行う際に発生する問題に関しては言及しておらず、図１及び図２によって示されている問題を解決しようとするものではない。
【００６０】
また、上述の特許文献３に開示されている技術では、ホームプレフィックスのみがＭＮに提供されるので、ＭＮは経路最適化を行わない。したがって、経路最適化することによって効率的な通信が行えるＣＮとの間においても、通信経路の最適化が行われない。さらに、１つのプレフィックスしか提供されず、ＭＮは複数のプレフィックスの中からプレフィックスを選択する必要がないので、特許文献３に開示されている技術によって、図１に図示されているような正しいプレフィックスを選択するという問題を解決することはできない。
【００６１】
また、非特許文献６に開示されている技術によれば、図１１Ａに示されているように、ＣＭＩＰに関するＢＵが伝送されるパス２８１Ａの距離が長くなってしまう。このＣＭＩＰに関するＢＵにおける長距離のパス２８１Ａでは、ＬＭＡ／ＰＤＮ−ＧＷ（ＬＭＡ／ＰＤＮ−ＧＷ）２７１ＡにおいてＩＦ２に関する位置更新を行うため、ＣＭＩＰタイプのＢＵパケットが外部ＰＭＩＰドメイン２５１Ａ、更にはインターネット２５２Ａを経由して伝送される必要がある。
【００６２】
さらに、このＢＵパケットは、ＭＡＧ２６７ＡからＬＭＡ／ＰＤＮ−ＧＷ２７１Ａまでパケットのカプセル化が行われる必要があり、このカプセル化の処理によって、位置更新に関して更なる遅延が生じることになる。
【００６３】
このように、非特許文献６に開示されている技術によれば、図１１Ａに示すシナリオにおいてはＩＦ２の気付アドレスの登録が長距離のパスを通じて行われ、より大量のネットワークリソースを使用することになるという問題（非特許文献６に関連する第１の問題）と、ＭＮ２６０Ａの両方のインタフェースに関する位置登録シグナリングが、図１１Ａのパス２８０Ａ及び２８１Ａで示されるように行われることになり、ネットワークにおけるシグナリングの負荷を低減するために最適化が行われる必要があるという問題（非特許文献６に関連する第２の問題）が存在する。なお、図１１Ａに開示されているシナリオでは、ＭＮ２６０Ａによってアップデート（パス２８１Ａ）が行われるとともに、固定エンティティ（ＭＡＧ２６５Ａ）によって位置情報に関する別のアップデート（パス２８０Ａ）が行われる。
【００６４】
また、非特許文献６に開示されているバルク登録を利用する方法に関しては、ＭＮがすべてのシグナリングをコントロールしているわけではなく、図１１Ａに示すシナリオでは、ＭＮからバルク登録のシグナリングを送信することはできないという問題（非特許文献６に関連する第３の問題）がある。すなわち、図１１Ａにおいては、あるインタフェースの位置更新シグナリングはＭＮ２６０Ａによって行われるものの、別のインタフェースの位置更新シグナリングはＭＡＧ２６５Ａによって行われる。また、仮にＭＮがＩＦ２からバルク登録のシグナリングを行うとしても、インタフェースのバルク登録がＬＭＡ／ＰＤＮ−ＧＷ２７０Ａに届くまでに長時間かかってしまい、上述の問題を解決できない可能性がある。
【００６５】
また、特許文献４に開示されている技術によれば、ＨＡへのシグナリングは低減することになるが、ＭＮは複数のインタフェース経由でプロキシサーバからデータを取得する必要があり、ＭＮからプロキシサーバに対して何らかのバインディング登録が行われる必要がある。なお、ＭＮが１つ又は複数のインタフェースに関してプロキシサーバに迅速かつ最適化された位置登録を実行可能とする方法が存在し得るが、本発明による技術とは異なる解決策を提供するものであり、本明細書では説明は行わない。
【００６６】
次に、マルチインタフェースのＭＮがホームＰＭＩＰドメイン及び外部ＰＭＩＰドメイン内で移動する際に、ハンドオフ問題が生じるシナリオについて説明する。図１１Ｂにおいて、ＭＮ２６０Ｂは２つのインタフェース（ＩＦ１及びＩＦ２）を備えており、初期状態として、ＭＮ２６０Ｂが両方のインタフェースによってホームＰＭＩＰドメイン２５０Ｂに接続していると仮定する。さらに、ＭＮ２６０Ｂは、ＬＭＡ／ＰＤＮ−ＧＷ（ＬＭＡ／ＰＤＮ−ＧＷ／ＨＡ）２７０Ｂから１つ又は複数のホームプレフィックスを取得すると仮定する。初期状態では、ＭＮ２６０ＢのＩＦ２は、ＭＡＧ２６６Ｂに接続しており、ＭＮ２６０ＢのＩＦ１は、ホームＰＭＩＰドメイン２５０Ｂ内の別のＭＡＧ（図１１Ｂには不図示）に接続されている。
【００６７】
ＭＮのＩＦ２がアクセスリンクによってＭＡＧ２６６Ｂに接続している場合には、ＭＡＧ２６６Ｂは、ホームプレフィックスとＭＡＧ２６６Ｂのイグレスアドレス（イグレスインタフェースのアドレス）とのバインディングを行うＰＢＵ２８０Ｂを送信する。このＰＢＵ２８０Ｂによる登録は、ＬＭＡ／ＰＤＮ−ＧＷ２７０Ｂにエントリを作成する。なお、この登録によるバインディングキャッシュのエントリは、図１１Ｄのバインディングキャッシュ２７１Ｄ内の最初のエントリによって表されている。
【００６８】
また、ＩＦ１は移動してアクセスリンク経由でＭＡＧ２６５Ｂに接続した後にすぐホームＰＭＩＰドメイン２５０Ｂから離れて、アクセスリンク経由で外部ドメイン（アクセスドメイン）２５１Ｂに接続したと仮定する。さらに、ホームＰＭＩＰドメイン２５０Ｂ及び外部ドメイン２５１Ｂはインターネット２５２Ｂに接続されていると仮定する。なお、ホームＰＭＩＰドメイン２５０Ｂは、複数の異なるタイプのアクセスネットワークによって構成され得る。また、外部ドメイン２５１Ｂは、ＰＭＩＰに基づくアーキテクチャで構成されていてもよく、あるいは構成されていなくてもよい。
【００６９】
ＭＮ２６０ＢのＩＦ１が移動してＡＲ２６７Ｂに接続した場合には、ＭＮ２６０Ｂは、ＩＦ１に関する気付アドレスを構成した後、ＬＭＡ／ＰＤＮ−ＧＷ２７０Ｂに対してＣＭＩＰのＢＵ（パス２８２Ｂを経由）を実行する。このパス２８２Ｂを経由するＢＵは、上述のＭＡＧ２６５ＢからのＰＢＵ２８１Ｂよりも早くＬＭＡ／ＰＤＮ−ＧＷ２７０Ｂに届くかもしれない。
【００７０】
このような事象が起こった場合には、図１１Ｄのバインディングキャッシュ２７１Ｄ内の２番目のエントリに表されているようなＩＦ１に関するバインディングキャッシュ２７１Ｄ内のエントリが、ＬＭＡ／ＰＤＮ−ＧＷ２７０Ｂにおいて作成される。
【００７１】
なお、インタフェース識別子によってインタフェースの識別が行われ、図１１Ｄに図示されているように、バインディングキャッシュエントリ２７１Ｄにインタフェース識別子（ＩＦ−ＩＤ／ＢＩＤ）のパラメータが含まれている。バインディングキャッシュでは、任意の各インタフェースに関して、ＰＭＩＰのＰＢＵ又はＣＭＩＰのＢＵに関するエントリが維持されている。
【００７２】
パス２８２Ｂを経由するＣＭＩＰのＢＵよりも遅れて、ＰＢＵ２８１ＢがＭＡＧ２６５ＢからＬＭＡ／ＰＤＮ−ＧＷ２７０Ｂに届くと、このＰＢＵ２８１Ｂは、正しいＣＭＩＰのＢＵエントリ（図１１Ｄのバインディングキャッシュ２７１Ｄ内の２番目のエントリ）を上書きしてしまい、その結果、図１１Ｄのバインディングキャッシュ２７１Ｄ内の３番目のエントリが作成される。
【００７３】
このような到着順を誤ったエントリの登録が起こったとき、ＬＭＡ／ＰＤＮ−ＧＷ２７０Ｂが同一プレフィックスをＭＮ２６０Ｂの両方のインタフェースに割り当てる場合には、ＭＮ２６０ＢのＩＦ１から正しいバインディングが届くまでＩＦ１経由のパケット到達可能性は実現されない。このような同一プレフィックスを割り当てるような場合においては、ＩＦ１を通じて送信されるパケットはなくなり、ＩＦ２を通じたパケット送信のみ可能となる。
【００７４】
一方、ＬＭＡ／ＰＤＮ−ＧＷ２７０ＢがＭＮの各インタフェースに対してユニークなプレフィックスを与える場合には、ＭＮ２６０Ｂは、それぞれのプレフィックスを用いて異なるユニークなホームアドレスを構成している可能性がある。複数のプレフィックスを割り当てるような場合にＩＦ１に関する誤ったバインディングキャッシュエントリが発生したときには、ＩＦ１に関する正しいバインディングがＬＭＡ／ＰＤＮ−ＧＷ２７０Ｂに確立されるまでは、ＩＦ１に構成されたホームアドレスに届くべきデータパケットはＭＮ２６０Ｂに届かない。
【００７５】
基本的に、別の正しいＣＭＩＰに関するＢＵがＬＭＡ／ＰＤＮ−ＧＷ２７０Ｂに到着するまで、ＩＦ１に関するハンドオフによるパケットロスやハンドオフ遅延が生じてしまう。こうしたパケットロスやハンドオフ遅延は、遅延にセンシティブなフローや重要な情報のデータフローのＱｏＳ品質を低下させることになる。
【００７６】
また、特許文献５に開示されている技術によれば、図１１Ｂに示されている上述の問題を解決できるかもしれないが、データパケットのマルチキャストが使用されることから、多量のネットワークリソースを必要とし、ネットワークリソースを浪費してしまうことになる。
【００７７】
また、信頼できないＷＬＡＮアクセス（non-trusted WLAN access）において、３ＧＰＰコアネットワークにアクセスするためには、パケットはｅＰＤＧと呼ばれる信頼できるゲートウェイ（trusted gateway）を経由して伝送される必要がある。しかしながら、ｅＰＤＧは、ルーティング階層においてより上位に配置されるＷＬＡＮアクセスドメイン内に存在するルータであり、このようなネットワーク構成の場合には、必ずしもＭＮの直接的なアクセスルータがｅＰＤＧとはならない。こうしたｅＰＤＧに係るネットワーク構成において、ＭＮが異なるタイプのプレフィックスを受信する場合には、ＣＮの場所（position）やネットワーク上の位置（location）に応じて、ＭＮは、ＣＮとの経路最適化のためのＣｏＡを構成する適切なプレフィックスを選ぶことが可能である。
【００７８】
図１１Ｃにおいて、ＭＮ２０５Ｃは、信頼できないＷＬＡＮアクセスネットワーク（非信頼ＷＬＡＮ）２０３Ｃを通じて、ホームＰＭＩＰドメイン２０２Ｃに接続されており、２つのＣＮ（ＣＮ２１０Ｃ及びＣＮ２１１Ｃ）のそれぞれと通信を行っている。ＣＮ２１０Ｃは、ＷＬＡＮアクセスネットワーク２０３Ｃ内に位置するＡＲ２１７Ｃに接続されている。一方、ＣＮ２１１Ｃは、ＭＡＧ２２１Ｃに直接接続されており、信頼できるＷＬＡＮアクセスネットワーク（信頼ＷＬＡＮ）２００Ｃ内に位置している。ホームＰＭＩＰドメイン２０２Ｃは、インターネット２０１Ｃに直接接続されている。
【００７９】
さらに、初期状態としてＭＮ２０５ＣがＡＲ２１５Ｃに接続されており、図１１Ｃの軌跡２０６のように移動すると仮定する。ＭＮ２０５Ｃは、あるＣＮ（不図示）と通信を行う際にホームアドレスを使用することを決定すると、まず、ｅＰＤＧ／ＭＡＧ２２０Ｃにデータパケットをトンネルする。ｅＰＤＧ／ＭＡＧ２２０Ｃにおいて、このデータパケットはデカプセル化され、さらに、ＭＮ２０５ＣのＨＡであるＬＭＡ／ＰＤＮ−ＧＷ（ＬＭＡ／ＰＤＮ−ＧＷ／ＨＡ）２３０Ｃにトンネルされる。
【００８０】
このＰＭＩＰコアネットワーク（ホームＰＭＩＰドメイン２０２Ｃ）において、さらにＧＷ２３１Ｃが存在しており、このＧＷ２３１Ｃが、ＬＭＡ／ＰＤＮ−ＧＷ２３０Ｃと比べてルーティング階層の下位層に配置されていると仮定する。基本的に、このＧＷ２３１Ｃは何らかのポリシを実施し、３ＧＰＰコアネットワークにアクセスするＭＮへのＡＡＡサービス（例えば課金管理など）を実行することが可能である。さらに、ＧＷ２３１Ｃはインターネット２０１Ｃに接続されていると仮定する。ＭＮ２０５Ｃからのパケットは、ＧＷ２３１Ｃに設定されるポリシに従ってＧＷ２３１Ｃ経由でトンネルすることが可能である。
【００８１】
このようなシナリオでは、ＭＮ２０５Ｃが２つのタイプのプレフィックスを受信してもよい。２つのタイプのプレフィックスのうちの１つは、例えば、ＡＲ２１５Ｃから提供される論理的に正しいオンリンクプレフィックスであり、もう１つは、ＭＮ２０５ＣがｅＰＤＧ／ＭＡＧ２２０Ｃとの間でトンネルを確立した場合にｅＰＤＧ／ＭＡＧ２２０Ｃから送信されるＰＭＩＰのホームプレフィックスである。図１１Ｃのシグナリング２４０Ｃは、ＡＲ２１５Ｃから受信した２つのプレフィックスを表している。これらの２つのプレフィックスは、ＭＮ２０５Ｃにおいて異なるタイミングで受信される。
【００８２】
ＣＮがＰＭＩＰドメインのプレフィックスを使用して気付アドレスを構成しているのであれば、ＭＮ２０５Ｃは、ＣＮ２１０ＣやＣＮ２１１Ｃとの経路最適化シグナリング（例えばＲＲテストに係るシグナリング）を行う場合には、これら２つのＣＮがＭＮ２０５Ｃと同一のＰＭＩＰドメインに位置していると把握できる可能性がある。このような場合には、ＭＮ２０５Ｃは、ＡＲ２１５Ｃによって生成されたオンリンクプレフィックスを使用して、上述のＣＮ２１０ＣやＣＮ２１１Ｃとの間で経路最適化セッションを確立してもよい。
【００８３】
このようにオンリンクプレフィックスを使用した場合の問題点は、アクセスドメイン（ＷＬＡＮアクセスネットワーク）２０３Ｃがかなり広大で多数のＡＲが存在している場合には、ＭＮ２０５Ｃは、ＷＬＡＮアクセスネットワーク２０３Ｃ内の異なるＡＲに接続するたびに、異なる気付アドレスを構成してＣＮとの間で経路最適化セッションを開始する必要があるかもしれないという点である。さらに、ＭＮ２０５Ｃがアクセスネットワーク２０３Ｃ内の各ＡＲの位置で気付アドレスを構成する場合には、ＭＮ２０５Ｃは、その気付アドレスをＨｏＡに関連付けるバインディングをＨＡ２３０Ｃへアップデートする必要があり、これによって、ＰＭＩＰコアネットワーク（ホームＰＭＩＰドメイン２０２Ｃ）内のシグナリング負荷は確実に増大してしまう。
【００８４】
さらに、これらの位置登録シグナリングパケットはｅＰＤＧ／ＭＡＧ２２０Ｃへトンネルされ、さらに、デカプセル化された後にＬＭＡ／ＰＤＮ−ＧＷ（ＬＭＡ／ＰＤＮ−ＧＷ／ＨＡ）２３０Ｃへ発送される。ＭＮ２０５ＣがＡＲ２１５Ｃに接続されている場合には、位置登録シグナリングはパス２４１Ｃ及び２４３Ｃに示されているように伝送される。一方、ＭＮ２０５ＣがＡＲ２１６Ｃに接続されている場合には、位置登録シグナリングはパス２４２Ｃ及び２４４Ｃに示されているように伝送される。
【００８５】
また、ｅＰＤＧ／ＭＡＧ２２０ＣがホームプレフィックスをＭＮ２０５Ｃに提供した場合には、ｅＰＤＧ／ＭＡＧ２２０Ｃが、ＬＭＡ／ＰＤＮ−ＧＷ／ＨＡ２３０ＣにおけるＰＭＩＰに関するバインディングのアップデートを行うことも可能である。なお、この場合については図１１Ｃには図示されていない。ここでの問題は、アクセスドメイン（ＷＬＡＮアクセスネットワーク）２０３Ｃに多数のＡＲが存在しているので、オンリンクプレフィックスが理想的な状態とはならず、別のプレフィックスを探す必要が生じてしまう場合があり得る。
【００８６】
また、特許文献６に開示されている方法によれば、ＭＮからＡＲへの無線パスを経由するトンネリングの負荷は低減されるものの、図１１Ｃに示されている問題を解決することはできない。
【課題を解決するための手段】
【００８７】
本発明は、上記の問題を解決するため、移動端末がＰＭＩＰドメインを移動する際に、選択可能な様々なプレフィックスがアクセスルータから提供されるようにすることを目的とする。また、本発明は、移動端末が利用可能なプレフィックスから構成する必要があるアドレスのタイプを選択し、ＰＭＩＰドメインに対してシグナリングの負荷をかけずに、経路が最適化されるようにコレスポンデントノードとの通信を行えるようにすることを目的とする。
【００８８】
本発明の通信制御方法は、上記の目的を達成するため、ネットワークベースのローカルモビリティ管理プロトコルが実装されているネットワークドメインを構成し、前記ネットワークドメインに接続されている移動端末の位置情報を管理する機能を有する位置管理ノードと、前記移動端末の位置情報の登録を代理して行う機能を有する代理登録ノードと、前記移動端末の認証を行う認証サーバとを有する通信システムにおける通信制御方法であって、
前記ネットワークドメインをホームドメインとする移動端末が、複数のプレフィックスを取得するステップと、
前記移動端末が、前記複数のプレフィックスから複数のアドレスを取得するステップと、
前記移動端末が、前記複数のアドレスを前記ネットワークドメインに通知するステップと、
前記代理登録ノードが、前記移動端末から通知された前記複数のアドレスのそれぞれに係るバインディング情報を前記位置管理ノードに登録するステップとを、
有する。
この方法により、移動端末が複数のプレフィックスによって構成されるアドレスを使い分けることができるようになる。また、移動端末が利用可能な複数のプレフィックスから構成されるアドレスを使い分けることで、ＰＭＩＰドメインに対してシグナリングの負荷をかけずに、コレスポンデントノードとの通信に係る経路を最適化できるようになる。
【００８９】
さらに、本発明の通信制御方法は、上記の処理に加えて、前記移動端末が、前記ネットワークドメインに接続する際に複数のプレフィックスを要求するステップと、
前記代理登録ノードが、前記複数のプレフィックスの要求に基づいて、前記複数のプレフィックスが前記移動端末に通知されるよう処理するステップとを、
有する。
この方法により、移動端末がＰＭＩＰドメイン内を移動する際に、アクセスルータから移動端末に対して複数のプレフィックスが提供されるようになる。
【００９０】
さらに、本発明の通信制御方法は、上記の処理に加えて、  前記プレフィックス取得ステップが、
前記移動端末が、前記ネットワークドメインに接続する際に、前記移動端末に前記ネットワークドメインへの接続を提供するアクセスルータに対して前記複数のプレフィックスを要求するステップと、
前記アクセスルータが、前記代理登録ノードに前記複数のプレフィックスの要求を渡し、前記代理登録ノードが、前記認証サーバに前記移動端末の認証を依頼するステップと、
前記認証サーバが、前記移動端末による前記ネットワークドメインへの接続資格を確認した後にドメインプレフィックスを前記移動端末に割り当て、前記ドメインプレフィックスを前記代理登録ノードに通知するとともに、前記複数のプレフィックスを前記移動端末に通知するよう前記代理登録ノードに指示するステップと、
前記代理登録ノードが、前記ドメインプレフィックスを前記アクセスルータを通じて前記移動端末に通知するとともに、前記認証サーバからの前記複数のプレフィックスの通知指示に基づいて前記アクセスルータにグローバルプレフィックスの通知を行わせるステップとを有し、
前記アドレス通知ステップが、前記移動端末が前記ドメインプレフィックスを含むホームアドレスと、前記グローバルプレフィックスを含むグローバルアドレスとを取得するステップを有し、
前記アドレス通知ステップが、前記移動端末が前記ホームアドレス及び前記グローバルアドレスを前記アクセスルータに通知し、前記アクセスルータが前記ホームアドレス及び前記グローバルアドレスを前記代理登録ノードに渡すステップを有し、
前記バインディング登録ステップが、前記代理登録ノードが前記ホームアドレス又は前記ドメインプレフィックスと前記代理登録ノード自身のアドレス又はプレフィックスとを関連付ける第１のバインディング情報、及び、前記ホームアドレスと前記グローバルアドレスとを関連付ける第２のバインディング情報を前記位置管理ノードに登録するステップを有する。
この方法により、ＭＡＧ（及びｅＰＤＧ）がＡＲ上に実装されていない場合であっても、本発明の適用が可能となる。すなわち、移動端末がＰＭＩＰドメイン内を移動する際に、アクセスルータから移動端末に対して複数のプレフィックスが提供されるようになり、移動端末がこれら複数のプレフィックスによって構成されるアドレスを使い分けることができるようになる。また、移動端末が利用可能な複数のプレフィックスから構成されるアドレスを使い分けることで、ＰＭＩＰドメインに対してシグナリングの負荷をかけずに、コレスポンデントノードとの通信に係る経路を最適化できるようになる。
【００９１】
さらに、本発明の通信制御方法は、上記の処理に加えて、前記移動端末が接続されるアクセスルータが前記代理登録ノードとしての機能を有さない場合、前記アクセスルータは、前記移動端末と前記代理登録ノードとの間において伝送される情報を中継するとともに、前記アクセスルータ独自のオンリンクプレフィックスを通知する。
この方法により、ＭＡＧ（及びｅＰＤＧ）がＡＲ上に実装されていない場合には、ＡＲ独自のオンリンクプレフィックスが移動端末に通知されるようになる、なお、アクセスルータは、移動端末からの要求に応じてオンリンクプレフィックスの通知を行ってもよく、認証サーバ（ローカルサーバ）やＭＡＧからの指示に従って行ってもよく、あるいは、任意のタイミングで通知を行ってもよい。
【００９２】
さらに、本発明の通信制御方法は、上記の処理に加えて、前記移動端末が複数の通信インタフェースを有しており、前記複数の通信インタフェースのうちの少なくとも１つが外部ネットワークドメインに接続されている場合に、前記アドレス通知ステップにおいて、前記移動端末が、前記外部ネットワークドメインが接続されている通信インタフェースに対応して設定されるアドレスを、前記ホームドメインに接続されている通信インタフェースから前記ホームドメインに通知するステップを有する。
この方法により、外部ドメインに接続されている移動端末のバインディングアップデートを、ホームドメインに接続されているインタフェース経由で行うことが可能となる。
【００９３】
さらに、本発明の通信制御方法は、上記の処理に加えて、前記バインディング登録ステップにおいて、前記代理登録ノードが、前記外部ネットワークドメインが接続されている通信インタフェースに対応して設定される前記移動端末のアドレスに係るバインディング情報を前記位置管理ノードに登録するステップを有する。
この方法により、外部ドメインに接続されている移動端末のバインディングアップデートを、ホームドメインに接続されているインタフェース経由で行うことが可能となる。
【００９４】
さらに、本発明の通信制御方法は、上記の処理に加えて、前記アドレス通知ステップにおいて、前記移動端末が、前記ホームドメインに接続されている通信インタフェースから前記ホームドメインに前記アドレスを通知する際に、前記アドレスをすぐに前記位置管理ノードに登録するよう要求するステップを有する。
この方法により、外部ドメインに接続されている移動端末のバインディングアップデートがホームドメインに接続されているインタフェース経由で行われる際に、迅速な登録処理が実現可能となる。
【００９５】
さらに、本発明の通信制御方法は、上記の処理に加えて、前記アドレス通知ステップにおいて、前記移動端末が、前記ホームドメインに接続されている通信インタフェースの存在を確認するステップを有する。
この方法により、外部ドメインに接続されている移動端末のバインディングアップデートを、ホームドメインに接続されているインタフェース経由で行う際に、移動端末は、ホームドメインに接続されているインタフェースの存在を確認したうえでアドレス通知を行うことが可能となる。
【００９６】
さらに、本発明の通信制御方法は、上記の処理に加えて、前記アドレス通知ステップにおいて、前記移動端末が、前記ホームドメインに接続されている通信インタフェースから前記ホームドメインに前記アドレスを通知する際に、前記アドレスの通知時刻を表す時間情報を、前記アドレスに係るバインディング情報に付加して前記位置管理ノードに通知するよう要求するステップを有する。
この方法により、外部ドメインに接続されている移動端末のバインディングアップデートの送信順序を示す指標となる時間情報が、位置管理ノードに確実に通知されるようになる。
【００９７】
また、本発明のネットワークノードは、上記の目的を達成するため、ネットワークベースのローカルモビリティ管理プロトコルが実装されているネットワークドメインを構成し、前記ネットワークドメインに接続されている移動端末の位置情報を管理する機能を有する位置管理ノードと、前記移動端末の位置情報の登録を代理して行う機能を有する代理登録ノードと、前記移動端末の認証を行う認証サーバとを有する通信システムにおいて、代理登録ノードとして機能するネットワークノードであって、
複数のプレフィックスに基づいて前記ネットワークドメインをホームドメインとする前記移動端末によって構成された複数のアドレスを前記移動端末から受信する手段と、
前記移動端末から通知された前記複数のアドレスのそれぞれに係るバインディング情報を前記位置管理ノードに登録する手段とを、
有する。
この構成により、移動端末が複数のプレフィックスによって構成されるアドレスを使い分けることができるようになる。また、移動端末が利用可能な複数のプレフィックスから構成されるアドレスを使い分けることで、ＰＭＩＰドメインに対してシグナリングの負荷をかけずに、コレスポンデントノードとの通信に係る経路を最適化できるようになる。
【００９８】
さらに、本発明のネットワークノードは、上記の構成に加えて、前記移動端末からの前記複数のプレフィックスの要求を受ける手段と、
前記移動端末からの前記複数のプレフィックスの要求に基づいて、前記複数のプレフィックスが前記移動端末に通知されるよう処理する手段とを、
有する。
この構成により、移動端末がＰＭＩＰドメイン内を移動する際に、アクセスルータから移動端末に対して複数のプレフィックスが提供されるようになる。
【００９９】
さらに、本発明のネットワークノードは、上記の構成に加えて、前記移動端末からの前記複数のプレフィックスの要求を受けた場合、前記認証サーバに前記移動端末の認証を依頼し、前記認証に成功した場合には、前記認証サーバから前記移動端末に割り当てられたドメインプレフィックスを受信するとともに、前記複数のプレフィックスを前記移動端末に通知する指示を前記認証サーバから受ける手段を有する。
この構成により、複数のプレフィックスを移動端末に通知することが可能か否かの判断を認証サーバに行わせることが可能となる。
【０１００】
さらに、本発明のネットワークノードは、上記の構成に加えて、前記移動端末に通知される前記複数のプレフィックスとして、前記ドメインプレフィックス、前記移動端末の接続ポイントのオンリンクプレフィックス、前記登録代理ノードのアドレス又はプレフィックスから選択する手段を有する。
この構成により、ネットワークノードから移動端末に、様々な状況に応じた通信経路の最適化を実現するための複数のプレフィックスの通知が行われるようにすることが可能となる。
【０１０１】
さらに、本発明のネットワークノードは、上記の構成に加えて、前記位置管理ノードに登録する前記移動端末の前記バインディング情報として、前記ホームアドレス又は前記ドメインプレフィックスと前記代理登録ノード自身のアドレス又はプレフィックスとを関連付ける第１のバインディング情報、及び、前記ホームアドレスと前記オンリンクアドレスとを関連付ける第２のバインディング情報を利用する手段を有する。
この構成により、ＰＭＩＰバインディング情報及びＣＭＩＰバインディング情報の両方が登録可能となる。
【０１０２】
さらに、本発明のネットワークノードは、上記の構成に加えて、前記移動端末から通知された前記複数のアドレスのそれぞれに係るバインディング情報を前記位置管理ノードに登録する際に、前記移動端末から通知された前記複数のアドレスのそれぞれに係るバインディング情報を含む１つの登録メッセージを生成し、前記位置管理ノードに送信する手段を有する。
この構成により、１回の登録メッセージの送信によって、複数のバインディング情報（例えば、ＰＭＩＰバインディング情報及びＣＭＩＰバインディング情報）の登録を行うことが可能となる。
【０１０３】
さらに、本発明のネットワークノードは、上記の構成に加えて、前記複数のアドレスのそれぞれに係るバインディング情報に対して、前記位置管理ノードにおける使用の優先度を設定する手段を有する。
この構成により、位置管理ノードにおいて優先的に参照されるバインディング情報を指定できるようになる。
【０１０４】
さらに、本発明のネットワークノードは、上記の構成に加えて、前記移動端末が複数の通信インタフェースを有しており、前記複数の通信インタフェースのうちの少なくとも１つが外部ネットワークドメインに接続されている場合に、前記外部ネットワークドメインが接続されている通信インタフェースに対応して設定されるアドレスの通知を前記移動端末から受ける手段を有する。
この構成により、外部ドメインに接続されている移動端末のバインディングアップデートを、ホームドメインに接続されているインタフェース経由で行うことが可能となる。
【０１０５】
さらに、本発明のネットワークノードは、上記の構成に加えて、前記アドレスの通知と共に前記アドレスに係るバインディング情報をすぐに前記位置管理ノードに登録するよう要求する情報を前記移動端末から受信する手段を有する。
この構成により、外部ドメインに接続されている移動端末のバインディングアップデートがホームドメインに接続されているインタフェース経由で行われる際に、迅速な登録処理が実現可能となる。
【０１０６】
さらに、本発明のネットワークノードは、上記の構成に加えて、前記バインディング登録手段は、前記移動端末から通知された前記アドレスに係るバインディング情報に、前記アドレスの通知時刻を表す時間情報を付加して前記位置管理ノードに登録するよう構成されている。
この方法により、外部ドメインに接続されている移動端末のバインディングアップデートの送信順序を示す指標となる時間情報が、位置管理ノードに通知されるようになる。
【０１０７】
さらに、本発明のネットワークノードは、上記の構成に加えて、前記アドレスの通知時刻を表す時間情報を前記アドレスに係るバインディング情報に付加するよう要求する情報を前記移動端末から受信する手段を有する。
この方法により、外部ドメインに接続されている移動端末のバインディングアップデートの送信順序を示す指標となる時間情報が、位置管理ノードに通知されるようになる。
【０１０８】
また、本発明の移動端末は、上記の目的を達成するため、ネットワークベースのローカルモビリティ管理プロトコルが実装されているネットワークドメインを構成し、前記ネットワークドメインに接続されている移動端末の位置情報を管理する機能を有する位置管理ノードと、前記移動端末の位置情報の登録を代理して行う機能を有する代理登録ノードと、前記移動端末の認証を行う認証サーバとを有する通信システムに接続可能であり、前記ネットワークドメインをホームドメインとする移動端末であって、
複数のプレフィックスを取得する手段と、
前記複数のプレフィックスから複数のアドレスを取得する手段と、
前記複数のアドレスを通知して、前記ネットワークドメイン内の前記移動管理ノードに前記複数のアドレスのそれぞれに係るバインディング情報を登録させる手段とを、
有する。
この構成により、移動端末がこれら複数のプレフィックスによって構成されるアドレスを使い分けることができるようになる。また、移動端末が利用可能な複数のプレフィックスから構成されるアドレスを使い分けることで、ＰＭＩＰドメインに対してシグナリングの負荷をかけずに、コレスポンデントノードとの通信に係る経路を最適化できるようになる。
【０１０９】
さらに、本発明の移動端末は、上記の構成に加えて、前記複数のプレフィックスを取得する手段が、
前記ネットワークドメインに接続する際に、複数のプレフィックスを要求する手段と、
前記複数のプレフィックスの要求に応じて通知される前記複数のプレフィックスを受信する手段とを、
有する。
この構成により、移動端末がＰＭＩＰドメイン内を移動する際に、アクセスルータから移動端末に対して複数のプレフィックスが提供されるようになる。
【０１１０】
さらに、本発明の移動端末は、上記の構成に加えて、前記複数のプレフィックスの要求に応じて受信したドメインプレフィックス及びグローバルプレフィックスから、前記ドメインプレフィックスを含むホームアドレスと、前記グローバルプレフィックスを含むグローバルアドレスとを構成する手段を有する。
この構成により、移動端末は複数のアドレス（例えば、ＰＭＩＰに基づくアドレス及びＣＭＩＰに基づくアドレスの両方）を構成することが可能となる。
【０１１１】
さらに、本発明の移動端末は、上記の構成に加えて、前記ホームアドレス及び前記グローバルアドレスの両方を通知するためのメッセージを生成し、前記移動端末が接続しているアクセスルータに前記メッセージを送信する手段を有する。
この構成により、移動端末は、アクセスルータにメッセージを送信する処理を行うだけで、移動端末の複数のアドレスの登録が行われるようになる。
【０１１２】
さらに、本発明の移動端末は、上記の構成に加えて、前記移動端末が前記ホームドメインに接続されている状態において、前記レガシのコレスポンデントノードや別のネットワークドメインに存在するコレスポンデントノードとの通信に、前記複数のプレフィックスのうちのドメインプレフィックスによって構成されたホームアドレスを使用することを決定する手段を有する。
この構成により、移動端末がホームドメインに接続されている状態において、レガシのコレスポンデントノードや別のネットワークドメインに存在するコレスポンデントノードとの通信経路が最適化されるようになる。
【０１１３】
さらに、本発明の移動端末は、上記の構成に加えて、前記移動端末が前記ホームドメインに接続されている状態において、同一の前記ホームドメインに接続されているコレスポンデントノードとの通信に、前記複数のプレフィックスのうちのオンリンクプレフィックスによって構成されたオンリンクアドレスを使用することを決定する手段を有する。
この構成により、移動端末がホームドメインに接続されている状態において、同一のホームドメインに接続されているコレスポンデントノードとの通信経路が最適化されるようになる。
【０１１４】
さらに、本発明の移動端末は、上記の構成に加えて、前記移動端末が前記ホームドメインに接続されている状態において、同一の前記ホームドメインに接続されているコレスポンデントノードとの通信に、前記複数のプレフィックスのうちの前記登録代理ノードのアドレス又はプレフィックスを使用することを決定する手段を有する。
この構成により、移動端末がホームドメインに接続されている状態において、同一のホームドメインに接続されているコレスポンデントノードとの通信経路が最適化されるようになる。
【０１１５】
さらに、本発明の移動端末は、上記の構成に加えて、前記移動端末が前記ホームドメインとは異なる外部ドメインに接続されている状態において、前記外部ドメインとは異なるドメインに存在するコレスポンデントノードとの通信に、前記外部ドメインから通知された外部ドメインプレフィックスにより構成された外部ドメインプレフィックスアドレスを使用することを決定する。
この構成に加えて、移動端末がホームドメインとは異なる外部ドメインに接続されている状態において、外部ドメインとは異なるドメインに存在するコレスポンデントノードとの通信経路が最適化されるようになる。
【０１１６】
さらに、本発明の移動端末は、上記の構成に加えて、前記移動端末が前記ホームドメインとは異なる外部ドメインに接続されている状態において、前記外部ドメインに存在するコレスポンデントノードとの通信における経路最適化処理に、前記外部ドメインから通知された外部ドメインプレフィックスにより構成された外部ドメインプレフィックスアドレスを使用することを決定する。
この構成により、移動端末がホームドメインとは異なる外部ドメインに接続されている状態において、外部ドメインに存在するコレスポンデントノードとの通信経路が最適化されるようになる。
【０１１７】
さらに、本発明の移動端末は、上記の構成に加えて、複数の通信インタフェースを有しており、
前記複数の通信インタフェースのうちの少なくとも１つが外部ネットワークドメインに接続されている場合に、前記アドレス通知手段が、前記外部ネットワークドメインが接続されている通信インタフェースに対応して設定されるアドレスを、前記ホームドメインに接続されている通信インタフェースから前記ホームドメインに通知するよう構成されている。
この構成により、外部ドメインに接続されている移動端末のバインディングアップデートを、ホームドメインに接続されているインタフェース経由で行うことが可能となる。
【０１１８】
さらに、本発明の移動端末は、上記の構成に加えて、前記アドレス通知手段が、前記ホームドメインに接続されている通信インタフェースから前記ホームドメインに前記アドレスを通知する際に、前記アドレスをすぐに前記位置管理ノードに登録する要求を行うよう構成されている。
この構成により、外部ドメインに接続されている移動端末のバインディングアップデートがホームドメインに接続されているインタフェース経由で行われる際に、迅速な登録処理が実現可能となる。
【０１１９】
さらに、本発明の移動端末は、上記の構成に加えて、前記アドレス通知手段が、前記ホームドメインに接続されている通信インタフェースの存在を確認するよう構成されている。
この構成により、外部ドメインに接続されている移動端末のバインディングアップデートを、ホームドメインに接続されているインタフェース経由で行う際に、移動端末は、ホームドメインに接続されているインタフェースの存在を確認したうえでアドレス通知を行うことが可能となる。
【０１２０】
さらに、本発明の移動端末は、上記の構成に加えて、前記アドレス通知手段が、前記ホームドメインに接続されている通信インタフェースから前記ホームドメインに前記アドレスを通知する際に、前記アドレスの通知時刻を表す時間情報を、前記アドレスに係るバインディング情報に付加して前記位置管理ノードに通知する要求を行うよう構成されている。
この方法により、外部ドメインに接続されている移動端末のバインディングアップデートの送信順序を示す指標となる時間情報が、位置管理ノードに確実に通知されるようになる。
【発明の効果】
【０１２１】
本発明は、上記の構成を有しており、移動端末がＰＭＩＰドメイン内を移動する際に、アクセスルータから移動端末に対して複数のプレフィックスが提供されるようになり、移動端末がこれら複数のプレフィックスによって構成されるアドレスを使い分けることができるようになるという効果を有する。また、本発明は、上記の構成を有しており、移動端末が利用可能な複数のプレフィックスから構成されるアドレスを使い分けることで、ＰＭＩＰドメインに対してシグナリングの負荷をかけずに、コレスポンデントノードとの通信に係る経路を最適化できるという効果を有する。
【発明を実施するための最良の形態】
【０１２２】
以下、図面を参照しながら、本発明の実施の形態について説明する。以下では、本発明に係る２つの主要な手法が開示される。
【０１２３】
本発明の第１の手法では、３ＧＰＰ公共モバイルネットワークに配置されているＰＭＩＰｖ６ドメイン内のＭＮが、複数の異なるタイプのＣＮとの間における通信に関して、各通信に係る経路の最適化を可能とする複数の異なるタイプのプレフィックスを把握できるようにする。
【０１２４】
例えば、ＰＭＩＰｖ６ドメインがＭＮのホームドメインである場合（ＭＮがホームＰＭＩＰｖ６ドメインに存在する場合）には、ＭＮは、レガシのＣＮとの通信や、インターネットや別のＰＭＩＰｖ６ドメインに接続されているＲＯ可能なＣＮとの通信のために、ホームプレフィックスを必要とする。また、ＭＮは、ＭＮのホームＰＭＩＰｖ６ドメイン内のＲＯ可能なＣＮとの間でＲＯを実行するために、オンリンクのグローバルプレフィックスを必要とする。一方、ＭＮが外部（foreign）ＰＭＩｖ６ドメインに存在している場合には、ＭＮは、他のドメインに存在しているＲＯ可能なＣＮとＲＯを実行するために、ＰＭＩＰｖ６ドメインプレフィックスを必要とし、同一の外部ＰＭＩＰｖ６ドメインに存在するＣＮとＲＯを実行するために、オンリンクのプレフィックスを必要とする。さらに、ＣＮとの位置関係によっては、ＲＯを実行するために、別の（若しくは別の用途で使っている）プレフィックスを使用したほうがより最適なＲＯを実行できる場合もある。
【０１２５】
ＭＮは、異なるタイプのプレフィックスが必要なことを把握すると、様々なプレフィックスを取得するために、ＡＲに対して問い合わせを行う。そのＡＲがＭＡＧとしての機能も有している場合には、ＡＲはＡＡＡサーバに対して問い合わせを行う。ＡＡＡサーバは、ＭＮがＰＭＩＰｖ６ドメインに加入していることに気付くと、ＡＲ（すなわちＭＡＧ）に対して、異なるタイプのプレフィックスを提供するとともに、ＭＮに対してこれらのプレフィックスに関する適切な情報を提供するように要求する。ＭＮは、様々なタイプのプレフィックスに関する情報を用いて様々なタイプのアドレスを構成し、適切なタイプのアドレスを用いて各タイプのＣＮと通信を行う。
【０１２６】
また、本発明の第２の手法では、ＬＭＡ及びＨＡが共存している（ＬＭＡ及びＨＡが同一ノードによって実現されている）ホームＰＭＩＰｖ６ドメイン内に存在しているＭＮが、ローカルブレイクアウト用にオンリンク気付アドレスを構成することを決定し、ＭＡＧが単一の登録メッセージをＭＮのＬＭＡ／ＨＡに送信できるようにするために、ＡＲに対して、この気付アドレスをＭＡＧに渡すように要求する。このＭＡＧからＬＭＡ／ＨＡに送信される登録メッセージは、ＭＮのホームアドレス及び気付アドレスをＣＭＩＰバインディングとして関連付けるとともに、ＭＮのＨｏＡ及びＭＡＧのイグレスインタフェースのアドレスをＰＭＩＰバインディングとして関連付けるものである。また、この登録メッセージは、ＢＵモビリティヘッダ内に、ＭＮが同時にホームにも接続されていることを示すフラグを有していることが望ましい。
【０１２７】
こうしたバインディングによって、ＭＮのホームアドレスあてのパケットは、ＰＭＩＰバインディングで明示されているアドレス（ＭＡＧのイグレスインタフェースのアドレス）経由で送信されるようになる。また、ＭＡＧは、何らかの負荷バランス効果を得ようとする場合には、ＬＭＡ／ＨＡに対して、ＣＭＩＰバインディングの属性に基づいてＭＮの気付アドレスに直接パケットを渡すように要求してもよい。
【０１２８】
以下、図３を参照しながら、本発明に係る上述の手法について説明する。図３には、本発明の実施の形態における動作の一例を示すシーケンスチャートが図示されている。なお、ここでは、ＭＮが、ＭＮのホームドメインであるＰＭＩＰｖ６ドメインに接続されており、ＲＯ可能なＣＮと通信を行っている場合について説明する。なお、このＲＯ可能なＣＮは、ＭＮと同一のＰＭＩＰｖ６ドメインに加入しており、現在、ＭＮと同一のＰＭＩＰｖ６ドメイン内に存在しているとする。また、このＣＮのホームドメインは別のドメイン（ＭＮのホームＰＭＩＰｖ６ドメインとは異なるドメイン）であるとする。また、ＡＲにＭＡＧの機能が実装されているとする。
【０１２９】
図３では、ＭＮ３１０がＭＡＧ３２０に直接接続されており、ＣＮ３６０がＭＡＧ３５０に直接接続されている。また、これらのすべてのノードは、ドメイン内のＬＭＡ３３０及びＭＡＧによってＰＭＩＰサービスが提供されているＰＭＩＰｖ６ドメインに存在している。また、ＰＭＩＰｖ６ドメイン内のＡＡＡサーバ３４０は、ＭＮに対するＰＭＩＰサービスの提供を認証する機能を有している。このドメインは、３ＧＰＰセルラドメインや３ＧＰＰ ＷＬＡＮタイプのドメインであってもよく、その他の任意の種類のドメインであってもよい。
【０１３０】
ＭＮ３１０は、ＭＡＧ３２０に接続されているサブネットワークにレイヤ２接続（Ｌ２接続）を行い、例えばメッセージ３６１（Ｌ２接続＋プレフィックス要求）によって利用可能なプレフィックスを要求する。ＭＡＧ３２０は、メッセージ３６１から、ＭＮ３１０のネットワークアクセス識別子（ＮＡＩ：Network Access Identifier）を抽出する。なお、ＮＡＩは、メディアアクセス制御（ＭＡＣ：Media Access Control）識別子などのＭＮ３１０を特定できるような値であってもよい。ＭＡＧ３２０は、抽出されたＮＡＩをＡＡＡサーバ３４０に渡し、ＡＡＡサーバ３４０で認証が行われる。このＭＡＧ３２０からＡＡＡサーバ３４０への問い合わせはメッセージ３６２（ＮＡＩ認証＋ＭＮタイプ問い合わせ）によって示されている。
【０１３１】
このメッセージ３６２を受信したＡＡＡサーバ３４０は、例えばＭＮ３１０にＣＭＩＰクライアントスタックがインストールされていることを把握し（例えば、あらかじめ構成されたステータス情報を参照）、ＭＡＧ３２０に応答を行う。この応答は、メッセージ３６３（ＮＡＩ認証＋ＭＮタイプ応答）によって示されている。なお、ＭＮ３１０が複数の異なるタイプのプレフィックスを必要としていることをＡＡＡサーバ３４０が把握する方法に関しては、本発明では特に限定されるものではない。例えば、ＭＮ３１０が最初にＰＭＩＰｖ６ドメインに接続する際に、複数の異なるタイプのプレフィックスをネットワーク側に要求し、この要求に応じてネットワーク側が複数の異なるタイプのプレフィックスを提供するとともに、ＡＡＡサーバ３４０において、このＭＮ３１０は複数の異なるタイプのプレフィックスを必要としている旨を示すステータス情報がＰＭＩＰキャッシュエントリ内に保持されるようにしてもよい。これにより、以降にＭＮ３１０がＰＭＩＰｖ６ドメインに接続する際に、ＡＡＡサーバ３４０はこのステータス情報を参照し、このＭＮ３１０に対して複数の異なるタイプのプレフィックスを提供できるようになる。なお、ステータス情報と共に、どのタイプのプレフィックスを必要としているかを示す情報が保持されてもよい。また、例えばＭＮ３１０がＰＭＩＰｖ６ドメインのサービスを受ける旨の契約が行われた際に、複数の異なるタイプのプレフィックスの提供サービスが行われるように定められ、ステータス情報としてＡＡＡサーバ３４０にあらかじめ設定されてもよい。
【０１３２】
このメッセージ３６３は、様々な情報を有している。第１に、このメッセージ３６３によって、ＭＮ３１０に割り当てられるＰＭＩＰｖ６ドメインのプレフィックスが伝搬される。第２に、このメッセージ３６３によって、ＰＭＩＰｖ６サービスの提供が承認された旨を示す情報が伝搬される。第３に、このメッセージ３６３によって、ＭＡＧ３２０に対して、様々なタイプのプレフィックスをＭＮ３１０に提供するように指示される。
【０１３３】
ＭＡＧ３２０は、このメッセージ３６３を処理すると、例えば、ステートレスのアドレス構成モードでは、ルータ通知（ＲＡ：Router Advertisement）メッセージ３６４（ＲＡ（複数プレフィックスオプション））を送出する。ここで、ＲＡメッセージ３６４には、複数の異なるタイプのプレフィックスがオプションとして付加される。ＲＡメッセージ３６４に付加されている様々なタイプのプレフィックスは、例えば、ＭＡＧ３２０のオンリンクプレフィックスであってもよく、ＭＡＧ３２０のイグレスインタフェースのアドレスのプレフィックスであってもよく、このＰＭＩＰｖ６ドメインのローカルプレフィックスであってもよい。また、各タイプのプレフィックスの説明（どのタイプのプレフィックスかを示す情報）もＲＡメッセージ３６４に含まれ、ＭＮ３１０が、各プレフィックスのタイプを容易に把握できるようにすることが望ましい。また、上述の動作では、ＭＮ３１０からのメッセージ３６１による複数のプレフィックスの要求に応じて、ＭＡＧ３２０が複数のプレフィックスを含むＲＡメッセージ３６４の送信を行っているが、例えば、ネットワーク側とＭＮ３１０側との事前の協定によって、ＭＮ３１０があらかじめ把握（記憶）している複数のプレフィックスを読み出すことで複数のプレフィックスを取得してもよく、また、ＭＮ３１０からの要求を受けずにネットワーク側から利用可能な複数のプレフィックスが能動的に通知されるようにしてもよい。
【０１３４】
ここで、ＭＮ３１０が、通信相手であるＣＮ３６０の現在の気付アドレスを把握しているとする。ＣＮ３６０はＭＮ３１０のホームＰＭＩＰｖ６ドメインに接続されているので、ＣＮ３６０の気付アドレスのプレフィックスは、ＭＮ３１０のホームアドレスのプレフィックスと類似することになる。例えば、プレフィックスが共有されるモデルが用いられている場合には、ＭＮ３１０のホームアドレスのプレフィックスと、ＣＮ３６０の気付アドレスのプレフィックスとは同一となる。また、ＭＮごとに固有のプレフィックスが与えられるモデルが用いられている場合には、ＭＮ３１０のホームアドレスとＣＮ３６０の気付アドレスとは、ある共通のビット数まで同一となる。こうしたアドレスのプレフィックスの比較を行うことで、ＭＮ３１０は、ＣＮ３６０が現在同一のドメイン内に存在するため経路最適化において問題が生じる可能性があることを把握し、ＣＮ３６０との間でＲＲシグナリングを行う。
【０１３５】
なお、どの場合においても、ＭＮ３１０はＭＡＧ３２０のオンリンクプレフィックスを使用して、ローカルブレイクアウト用の気付アドレスを構成することが可能である。このようなローカルブレイクアウト用の気付アドレスが構成されると、ＭＮ３１０は、ＩＣＭＰのＮＡメッセージ３６５（ＮＡ（オンリンク気付アドレス））などを用いて、ＬＭＡ３３０へのＭＣｏＡ登録（Multiple CoA BU：複数の気付アドレスのバインディングアップデート）を行うようにＭＡＧ３２０に要求する。なお、このローカルブレイクアウトのアドレスがＮＡメッセージ３６５によって伝搬される場合には、ＮＡメッセージ３６５は、ホームアドレス及び気付アドレスの両方の情報（ＣＭＩＰバインディング）を埋め込むことが可能となるような構成を持つこととなる。
【０１３６】
なお、本発明におけるＭＣｏＡ登録は、従来の１つのホームアドレスに対して複数の気付アドレスを登録する方法を拡張し、ＰＢＵによるＰＭＩＰバインディングの内容と従来のＢＵによりなされていたＣＭＩＰバインディングの内容とを併せて登録できるようにする。このとき、後述のようにローカルブレイクアウト用の気付アドレスの登録をＭＡＧのＰＢＵと併せて（一括して）行うように要求すると効率が良い。
【０１３７】
このＮＡメッセージ３６５を送信することによって、ＭＮ３１０はＭＡＧ３２０に対して、ＬＭＡ３３０へのＭＣｏＡ登録を行うように指示又は要求する。ＬＭＡ３３０によるＭＣｏＡ登録では、ＭＡＧ３２０のイグレスインタフェースのアドレスが伝送され、ＭＮ３１０のホームアドレスプレフィックスや、さらにはＭＮ３１０の気付アドレスに関する情報も伝送される。ＭＣｏＡ登録メッセージ３６６（ＭＣｏＡ ＢＵ（ＭＮのＨｏＡ、ＭＮのＣｏＡ））がＬＭＡ３３０に送信され、ＬＭＡ３３０はＭＣｏＡ登録メッセージ３６６を受信すると、ＣＭＩＰバインディング及びＰＭＩＰバインディングの両方を生成する。ＣＭＩＰバインディングは、ＭＮ３１０のホームアドレスと、ＭＮ３１０のオンリンク気付アドレス（グローバルの気付アドレス）とのバインディングであり、ＰＭＩＰバインディングはＭＮ３１０のホームアドレスと、ＭＡＧ３２０のイグレスインタフェースのアドレスとのバインディングである。
【０１３８】
また、ＭＮ３１０は、ＮＡメッセージ３６５を送信すると、ＣＮ３６０との間でＲＯ処理を開始する。ＭＮ３１０はＨｏＴＩ（Home Test Init）メッセージ３６７（ＣＮへのＨｏＴＩ）を送信する。なお、このＨｏＴＩメッセージ３６７の送信元アドレスはＭＮ３１０のＨｏＡである。したがって、このＨｏＴＩメッセージ３６７は、ＭＮ３１０のホームエージェントでもあるＬＭＡ３３０にトンネルされる。このトンネルされるメッセージはＨｏＴＩメッセージ３６８（ＣＮへのＨｏＴＩ）によって示される。ＭＮ３１０のホームエージェントとして動作するＬＭＡ３３０は、このＨｏＴＩメッセージ３６８をデカプセル化し、ＣＮ３６０のアドレスを探索する。このＣＮ３６０のアドレスは、ＬＭＡ３３０のＰＭＩＰキャッシュエントリ内に見つかり、ＬＭＡ３３０は、このＣＮ３６０のアドレスを用いて、ＣＮ３６０に接続されているＭＡＧ３５０にＨｏＴＩメッセージ３６９（ＣＮへのＨｏＴＩ）をトンネルする。ＨｏＴＩメッセージ３６９は、ＭＡＧ３５０によってデカプセル化された後、ＨｏＴＩメッセージ３７０（ＣＮへのＨｏＴＩ）としてＣＮ３６０に伝送される。
【０１３９】
また、ＭＮ３１０は、ＣＮ３６０に対してＣｏＴＩ（Care-of Test Init）メッセージ３７１（ＣＮへのＣｏＴＩ）も送信する。なお、ＣｏＴＩメッセージ３７１の送信元アドレスはＭＮ３１０の気付アドレスであり、この気付アドレスはオンリンクプレフィックスから作られる。また、あて先アドレスはＣＮ３６０の気付アドレス（ＬＭＡ３３０から取得されたプレフィックスと同一又は類似）である。したがって、このＣｏＴＩメッセージ３７１は、ＰＭＩＰの場合のようなトンネルは行われず、図３に示されているようにＬＭＡ３３０によって受信（intercept）される。このＣｏＴＩメッセージ３７１のあて先アドレスはＣＮ３６０の気付アドレスであり、このあて先アドレスに関するＰＭＩＰバインディングを有するＬＭＡ３３０は、このＣｏＴＩメッセージ３７１を受信（intercept）して、ＣｏＴＩメッセージ３７２（ＣＮへのＣｏＴＩ）に示されるようにＭＡＧ３５０にトンネルする。そして、最終的に、ＭＡＧ３５０がＣｏＴＩメッセージ３７２を完全にデカプセル化して、内部のＣｏＴＩメッセージ３７３（ＣＮへのＣｏＴＩ）がＣＮ３６０に伝送される。なお、ＭＮとＣＮとの間に外部ＰＭＩＰドメインが介在している場合は、ホームドメインのＬＭＡのプレフィックスやオンリンクプレフィックスにかかわらず、外部ＰＭＩＰドメインにより構成されるトンネルを介する場合がある。
【０１４０】
ＨｏＴＩメッセージ３７０及びＣｏＴＩメッセージ３７３を受信した後、ＣＮ３６０は、図３に図示されているように、ＨｏＴメッセージ３７４（ＭＮへのＨｏＴ）及びＣｏＴメッセージ３７８（ＭＮへのＣｏＴ）を送信する。なお、当業者であれば、これらのメッセージの経路は容易に把握可能であり、ＨｏＴメッセージ３７４〜３７７やＣｏＴＩメッセージ３７８〜３８０については詳細な説明は省略する。ここでは、ＨｏＴメッセージ３７４はＨｏＴＩメッセージ３７０の送信元アドレスに送信され、ＣｏＴメッセージ３７８はＣｏＴＩメッセージ３７３の送信元アドレスに送信されることが重要である。さらに、ＣＮ３６０は、ＨｏＴメッセージ３７４及びＣｏＴメッセージ３７８の送信元アドレスとして、気付アドレス（ＰＭＩＰドメインのプレフィックスに由来）を使用する。ＲＲテストが完了すると、ＭＮ３１０はＣＮに対してＢＵメッセージ３８１（ＣＮへのＢＵ）を送信することによって、ＣＮ３６０にＣＭＩＰバインディングを登録することが可能となる。ＢＵメッセージ３８１は、ＬＭＡ３３０からＭＡＧ３５０にトンネルされ（ＢＵメッセージ３８２）、ＭＡＧ３５０でデカプセル化されてＣＮ３６０に転送される（ＢＵメッセージ３８３）。
【０１４１】
また、ＣＮ３６０の現在の気付アドレスのプレフィックス（ＰＭＩＰドメインのプレフィックス）及びＭＮ３１０のホームアドレスプレフィックスに何らかの類似性があることにＣＮ３６０が気付いた場合や、何らかのヒント（同一ＰＭＩＰドメインに存在していることを示す情報）がＬＭＡ３３０やＭＮ３１０から与えられている場合には、ＣＮ３６０は、オンリンク気付アドレスを使用してＭＮ３１０とＲＲ及びＢＵを行うことが可能である。これは、図３の処理３８４（ＲＲ及びＣＮからＭＮへのＢＵ）によって示されている。なお、ここでは、ＭＡＧ３５０によって通知されるＲＡメッセージによって複数のプレフィックスの通知が可能であり、ＣＮ３６０がオンリンクプレフィックスを選択して気付アドレスを構成できるとする。こうして双方向ＲＲが完了すると、ＭＮ３１０及びＣＮ３６０は、図３のメッセージ３８５（ＭＮとＣＮとの間における双方向データフロー）に示されているように最適化経路を経由したデータ通信を行う。なお、図３に図示されているＣＮ３６０に関しても、そのＣＮ３６０のＨＡ機能が同一のＬＭＡ３３０に実装されていてもよい。
【０１４２】
次に、ＭＡＧの機能がＡＲに実装されていない場合の本発明の動作について説明する。以下、上述の場合（図３に係る動作）との違いについて説明する。このシナリオは、図１のＰＬＭＮ１に記載されているように、ｅＰＤＧの機能がＡＲではなくゲートウェイ（ＧＷ）に存在している場合に起こり得る。
【０１４３】
このシナリオにおいても、ＭＮ１０がホームＰＭＩＰｖ６ドメイン内を移動しており、ＭＮ１０がＡＲ２０に接続されて、３ＧＰＰ ＡＡＡサーバ６０におけるアクセス認証を取得し、ｅＰＤＧ／ＭＡＧ４０によってＰＭＩＰｖ６ドメインのプレフィックスが取得されるとする。したがって、図３に係る動作と同様の動作が実現されるためには、ＡＲ２０とｅＰＤＧ／ＭＡＧ４０との間に何らかのインタラクションが行われる必要がある。
【０１４４】
ＭＮ１０は、上述のようにＡＲ２０に対して複数のタイプのプレフィックスを要求する可能性があり、この場合、ＡＲ２０はこのリクエスト情報をｅＰＤＧ／ＭＡＧ４０に渡す。ｅＰＤＧ／ＭＡＧ４０は認証を行って、ＭＮ１０に関連するＰＭＩＰｖ６ドメインのプレフィックスをＡＲ２０に渡し、さらに、様々なタイプのプレフィックスを通知するようにＡＲ２０に要求する。この場合、ｅＰＤＧ／ＭＡＧ４０は、どのＡＲからＮＡＩ情報を受けたかに関する情報や、特定のＬＭＡプレフィックス又はＬＭＡプレフィックスから構成されたアドレスがどのＡＲに提供されるかに関する情報を保持する必要がある。
【０１４５】
複数の異なるタイプのプレフィックスを受信した後、ＡＲ２０に接続されているＭＮ１０は、オンリンク気付アドレスを構成して、同一のＰＭＩＰｖ６ドメイン内に存在するＣＮとの間でＲＯを行うことが可能である。また、ＭＮ１０が、インターネットの任意のポイントに接続されているレガシのＣＮと通信を行うためにＰＭＩＰｖ６ドメインプレフィックスの使用を望む場合には、ＭＮ１０は、ＭＮ１０のＨｏＡを使用してパケットを送信する。この場合には、パケットはＭＮからＡＲ２０を経由してｅＰＤＧ／ＭＡＧ４０にトンネルされ、ｅＰＤＧ／ＭＡＧ４０がこのパケットをデカプセル化して、さらにＬＭＡ５０にトンネルする必要がある。なお、このとき、ＡＲ２０からｅＰＤＧ／ＭＡＧ４０へのトンネリングが必要になったり、特定のＭＮ１０がどのＡＲ２０に接続されているかという状態をｅＰＤＧ／ＭＡＧ４０が保持する必要があったりするが、複数のｅＰＤＧ／ＭＡＧ４０を配置してｅＰＤＧ／ＭＡＧ４０とＡＲ２０とを１対１に対応させることで、こうした事項を解消することが可能である。
【０１４６】
図３に係る動作では、ＭＡＧ／ＡＲが、ＭＮのホームエージェント（ＰＭＩＰｖ６ドメインのＬＭＡでもある）にＭＣｏＡ登録を行う場合について説明されている。こうしたＭＣｏＡ登録は、通常、負荷バランスを行うために有用である。また、図３において、ＣＮ３６０が異なるホームドメインを有しているとすると、ＣＮ３６０はＬＭＡ３３０に対して、上述のようなＢＵストームの問題の解消を目的としたＭＣｏＡ登録の要求を行う必要はない。しかしながら、ＬＭＡ３３０がＣＮ３６０に関する負荷バランスを行いたい場合に、ＣＮ３６０がＭＡＧ３５０に対して、ＬＭＡ３３０へのＭＣｏＡ登録を行うよう要求することも可能である。ＭＡＧ３５０がＭＣｏＡ登録を送信することで、ＣＮ３６０のＰＭＩＰｖ６ローカルドメインアドレスがＭＡＧ３５０のアドレスと関連付けられるとともに、ＣＮ３６０のオンリンクグローバルアドレスがＣＮ３６０のＰＭＩＰｖ６ローカルドメインアドレスと関連付けられることになる。なお、この場合には、ＬＭＡ３３０と、外部（foreign）ＰＭＩＰｖ６ドメイン内に存在しているＣＮ３６０との間において、相互にセキュリティアソシエーションが確立されることで、こうしたバインディングが設定される必要がある。
【０１４７】
また、ＭＡＧ３２０のプレフィックスを用いて、ＣＮ３６０と通信を行うためのローカルブレイクアウト用のアドレスが構成されてもよい。ＭＮ３１０が、ＭＡＧ３２０のイグレスインタフェースのアドレスを使用してローカルブレイクアウト用のグローバルアドレスを構成した場合には、ＭＮ３１０はそのアドレスに関してＤＡＤを実行する必要がなくなるという利点がある。
【０１４８】
また、ＭＮ３１０が、ＭＡＧ３２０のプレフィックスを使用して、ローカルブレイクアウト用のグローバルアドレスを構成した場合には、ＭＡＧ３２０が、ＭＮ３１０のアドレスに係るＤＡＤを実行する必要がある。なお、この場合には、ＭＡＧ３２０が接続されているサブネットワーク内でＤＡＤシグナリングストームが発生する可能性があり、ＭＡＧ３２０がこれらのアドレスに関して近隣探索プロキシシグナリング（ＮＤプロキシシグナリング）を実行する必要がある。また、ＭＡＧ３２０に接続されているＭＮすべてがローカルブレイクアウト用のアドレスを使用した場合には、ＭＡＧ３２０は、ＭＮに対して正しくパケットを発送するために、何らかの情報を保持するとともに、各ＭＮに接続されているＣＮに関するステータスを保持する必要があり、さらに、ＭＡＧ３２０は、データパケット発送前にデータパケットの送信元アドレスをチェックする必要がある。こうした動作を行うためには、ＭＡＧ３２０は高い処理能力や容量の大きなメモリを有する必要がある。
【０１４９】
さらに、ＭＡＧ３２０に接続されているＭＮすべてがローカルブレイクアウト用のアドレスとしてＭＡＧアドレスを使用した場合には、ＭＮは、移動するたびに（ＭＡＧが変更されるたびに）ＣＮのリストをＭＡＧに渡さなければならない可能性がある。また、例えば多数のＭＮが１つのＣＮと通信を行っている場合のように、ＭＡＧ配下の多数のＭＮが共通のＣＮを有している場合には、ＭＡＧがデータパケットを発送するＭＮを特定することが困難になってしまう可能性がある。このような場合、ＭＡＧは、データパケットを正確に発送するために、ＭＮのホームアドレス情報を保持し、このホームアドレスの所有権を検証する処理を行う必要がある。
【０１５０】
次に、図３に図示されているＭＡＧ３２０からＬＭＡ３３０に送信されるＭＣｏＡ登録メッセージのパケット構造について詳細に説明する。ＭＮが１つ又は複数のインタフェースに関連付けられた複数の気付アドレスを有する場合、ＭＮは、負荷バランスやフォールトトレランス、信頼性、優先度設定などの様々な設定を行うことを目的として、これらの気付アドレスをホームエージェントに登録しようとする。
【０１５１】
例えば、ある１つのホームアドレスに対して１つの気付アドレスのバインディングが登録可能な登録メッセージをそれぞれ個別に複数回送信することによって、複数の気付アドレスの登録メッセージの送信が行われるようにしてもよく、また、複数の気付アドレス（ＭＣｏＡ）の登録メッセージがまとめて送信されることで、１回の登録によって、１つのホームアドレスと複数の気付アドレスとのバインディングが登録されるようにしてもよい。なお、後者の複数の気付アドレスの一括登録はバルク登録（bulk registration）と呼ばれる。
【０１５２】
ＭＣｏＡ登録メッセージ（ＭＣｏＡ ＢＵメッセージ）においては、基本的にＢＩＤオプションが使用される。このＢＩＤオプションは、バインディングを特定する識別情報であり、これによって、ＨＡは、ある単一のホームアドレスに関する複数のバインディングを識別し、他のインタフェースから送られてくる登録によってバインディングの上書きが行われないようにすることが可能となる。さらに、ＢＩＤオプションによって、ＭＮの個々のインタフェースを識別できるようになる。
【０１５３】
このＢＩＤオプションは、優先度フィールドを有している。この優先度フィールドは、複数の気付アドレスの中から特定の気付アドレスが使用されるようにするため、ＨＡにおける使用の優先度をＭＮが設定するためのものである。また、バルク登録では、１つの登録メッセージ内に複数のＢＩＤオプションが挿入されるので、各ＢＩＤオプションに気付アドレスフィールドが設けられる。一方、個別登録によるＭＣｏＡ登録では、登録メッセージの送信元アドレスによってその気付アドレスが伝送されるので、必ずしもＢＩＤオプションが気付アドレスフィールドを有する必要はない。
【０１５４】
図３に図示されているＭＣｏＡ登録では、ＭＣｏＡ登録は１回の登録で行われており、バルク登録の使用が適切である。ここでは上述のように、ＰＭＩＰバインディング及びＣＭＩＰバインディングの両方が行われる。図４には、ＰＭＩＰバインディング及びＣＭＩＰバインディングの両方を行うためのＭＣｏＡ登録メッセージのパケット構造の一例が図示されている。このＭＣｏＡ登録メッセージは非特許文献２に記載されているようなＰＢＵメッセージであり、例えばＣＭＩＰバインディングが更に挿入可能となるようなフィールドが設定される必要がある。このＭＣｏＡ登録メッセージを受信したＨＡは、ＣＭＩＰバインディングパラメータを伝搬する追加オプションを参照して、ＰＭＩＰバインディング及びＣＭＩＰバインディングの両方を生成する。
【０１５５】
図４には、バルク登録タイプのＭＣｏＡ登録メッセージ３９０が図示されている。このＭＣｏＡ登録メッセージ３９０は、ＭＡＧのイグレスインタフェースのアドレスを含む送信元アドレスフィールド３９１、ＬＭＡのアドレスを含むあて先アドレスフィールド３９２を有している。また、認証ヘッダ３９３には、ＭＡＧとＬＭＡとの間のセキュリティアソシエーションから生成された認証データが含まれている。
【０１５６】
ＭＣｏＡ登録メッセージ３９０には更にモビリティヘッダ３９４が含まれている。このモビリティヘッダ３９４は、バインディングアップデートを行うためのものであり、非特許文献２に開示されているようなＰＭＩＰに関連した新しいタイプのものである。
【０１５７】
このモビリティヘッダ３９４の中には、ＮＡＩオプション３９５が存在している。このＮＡＩオプション３９５は、ＬＭＡにおいてＰＭＩＰタイプのバインディングが生成されるためにＮＡＩを伝搬するものである。なお、ＰＭＩＰバインディングでは、ＰＭＩＰキャッシュがＭＮのホームアドレス値を有しておらず、ＮＡＩのみが使用されている場合もあり、ＮＡＩオプション３９５は、ＰＭＩＰバインディングにおいて必須のオプションであると言える。
【０１５８】
また、モビリティヘッダ３９４の中には、ＭＮホームプレフィックスオプション３９６が含まれている。このＭＮホームプレフィックスオプション３９６は、ＭＮごとに個別のプレフィックスが提供される場合にＭＮ固有のホームプレフィックスを伝搬し、共有プレフィックスが提供される場合には、ＭＮのホームアドレス又は、共有プレフィックスの値を伝搬する。
【０１５９】
また、ＭＣｏＡ登録メッセージ３９０における最後のオプションとして、ＢＩＤオプション３９７が存在する。このＢＩＤオプション３９７においては、気付アドレスフィールドにＭＮのオンリンク気付アドレスが挿入される。さらに、ＭＡＧがデカプセル化処理の負荷を軽減しようとするために気付アドレスのバインディング（すなわちＣＭＩＰバインディング）を高優先度に設定したくない場合には、例えばＢＩＤオプション３９７の優先度設定を“０”に設定することで、この気付アドレスのバインディング又はＣＭＩＰバインディングが使用されないようにしてもよい。
【０１６０】
また、ＭＮがオンリンク気付アドレス用にＭＡＧのアドレスを使用する場合には、ＭＡＧからＬＭＡに対して、ＢＩＤオプションが挿入されない通常のＰＢＵメッセージが送信されてもよい。しかしながら、このＰＢＵメッセージには、ＭＮに関してＰＭＩＰバインディング及びＣＭＩＰバインディングの両方のタイプのバインディングが作成される必要があることをＨＡ／ＬＭＡに示すためのフラグが備わっていることが望ましい。なお、これを実現するため、ＭＡＧはホームフラグをオプションとして設定してもよく、また、このＰＢＵ（フラグが設定されていない場合であっても）を受信したＬＭＡが、ＭＮが同時にホームに接続されている状態であると推測してもよい。ＬＭＡは、このＭＣｏＡの登録を受信すると、ＭＮが同時にホームに接続されている状態にあるとして処理を行う。このＭＣｏＡの登録に係る処理では、ＰＭＩＰバインディングの登録と、ホームに同時に接続されている際にＣｏＡをＨｏＡに関連付けるＭＣｏＡのＣＭＩＰバインディングの登録が行われる。
【０１６１】
次に、ＬＭＡの動作について説明する。データパケットがＭＮのアドレス（ＬＭＡのプレフィックスから構成されている）に伝送される場合には、ＬＭＡがこのパケットを受信（intercept）して、バインディングキャッシュをチェックする。ここで、ＭＮのＰＭＩＰｖ６ドメインのローカルアドレスに関連して、例えばＰＭＩＰバインディング及びＣＭＩＰバインディングなどの複数のバインディングが存在する場合には、通常、ＬＭＡはＰＭＩＰバインディングを使用してパケットのトンネルを行う。これは、上述のように、ＣＭＩＰバインディングの優先度が通常は低く設定されることによる。ＰＭＩＰバインディングを使用したトンネルにおいて、ＬＭＡは、通常、ＭＮが接続されているＭＡＧのアドレスにデータパケットをトンネルする。しかしながら、ＭＡＧは、デカプセル化処理の負荷を軽減するために、ＭＮのＰＭＩＰｖ６ドメインのプレフィックスのアドレスあてに届くパケットが、ＬＭＡからＭＮのオンリンクアドレスにトンネルされるようにしてもよい。
【０１６２】
ＭＡＧがこのような動作を必要とする場合には、例えば上述のように、ＭＡＧは、ＭＣｏＡのＣＭＩＰバインディングに関する登録の優先度を高く設定することによって、ＬＭＡに対してこの動作を行うように要求することが可能である。このようなＢＵは、例えばＭＡＧがＣＭＩＰバインディングに係るＢＩＤオプションの優先度の値を“２５５”に設定することによって実現される。このような高優先度のＣＭＩＰバインディングが存在する場合には、ＬＭＡは、ＣＭＩＰバインディングを使用してデータパケットをＭＮに直接転送する。ＣＭＩＰバインディングを使用してトンネルを行うことで、パケットはＭＮのオンリンク気付アドレスにトンネルされるようになる。
【０１６３】
次に、本発明の実施の形態におけるＭＮの構成について説明する。ＭＮはマルチホーミング機能を有し、複数のプレフィックスの処理を行って、１つのインタフェースに関連付ける複数の気付アドレスを構成することが可能である。図５には、本発明の実施の形態におけるＭＮの構成の一例が図示されている。ＭＮ４００は、本発明を実現するため、ＩＰｖ６に関連するプロトコルスタックを実装するために必要なすべてのソフトウェア、ハードウェア、ファームウェアを有している。なお、図５に図示されているＭＮ４００は、マルチホーミング機能を有している。
【０１６４】
また、下位レイヤプロトコル（ネットワークインタフェース）４０１は、すべての物理層及びリンクレイヤプロトコルを有している。また、ＭＮ４００のルーティングレイヤプロトコル４０２は、ルーティングに関連したすべてのプロトコルを有している。また、上位レイヤプロトコル４０３はすべてのトランスポートレイヤプロトコル及びアプリケーションレイヤプロトコルを有している。
【０１６５】
ルーティングレイヤプロトコル４０２及び上位レイヤプロトコル４０３は、インタフェース４０５を通じてメッセージの受け渡しを行う。また、下位レイヤモジュール４０１及びルーティングレイヤプロトコル４０２は、インタフェース４０４を通じてメッセージの受け渡しを行う。また、ルーティングレイヤプロトコル４０２は、ＩＰｖ６ルーティングモジュール４０８、ＭＩＰｖ６モビリティ管理モジュール４０９、プレフィックス選択モジュール４１０を有している。
【０１６６】
プレフィックス選択モジュール４１０は、ＭＮが必要とする複数のプレフィックスを判断し、さらに、どのタイプのＣＮとの通信にどのプレフィックスを使用すべきかを決定する。なお、このプレフィックス選択モジュール４１０は、ＭＩＰｖ６モビリティ管理モジュール４０９とインタラクションする。複数の気付アドレスを構成する際には、ＭＩＰｖ６モビリティ管理モジュール４０９は近隣探索（Neighbor Discovery）機能に対して、ＭＮが構成したオンリンク気付アドレスを含む近隣通知ＩＣＭＰメッセージをＡＲに送信するように要求する。プレフィックス選択モジュール４１０は、インタフェース４０７を通じてＭＩＰｖ６モビリティ管理モジュール４０９４０９とインタラクションし、ＩＰｖ６ルーティングモジュール４０８は、インタフェース４０６を通じてＭＩＰｖ６モビリティ管理モジュール４０９とインタラクションする。また、インタフェース４０７を通じてプレフィックス情報が伝送され、ＭＩＰｖ６モビリティ管理モジュール４０９は、提供されたプレフィックスに関連する気付アドレスを構成することが可能である。
【０１６７】
次に、図６に図示されているフローチャートを参照しながら、上述のプレフィックス選択モジュール４１０における動作の一例について説明する。ここでは、ＭＮが、ＰＭＩＰｖ６プロトコルが導入されているローカルモビリティ管理セグメントを移動しているとする。
【０１６８】
図６において、ＭＮはあるドメイン内に移動すると、まずステップＳ５００において、そのドメインがホームドメイン（ホームＰＭＩＰｖ６ドメイン）か否かをチェックする。ＭＮがホームドメイン内に移動した場合には、ステップＳ５０１が実行される。
【０１６９】
ＭＮは、ＣＮのリストを有しており、ステップＳ５０１においてそのリストの中からＣＮを１つ選択し、そのＣＮと通信を行うためには、どのタイプのアドレスを構成する必要があるかを判断する。ここでは、ＭＮはＣＮのタイプを分類しており、ステップＳ５０２において、ＣＮがレガシタイプか否かの判断（レガシＣＮかＲＯ可能ＣＮのいずれかであるかの判断）ができるものとする。
【０１７０】
ステップＳ５０２において、そのＣＮがレガシタイプであると判断された場合には、ステップＳ５０３が実行される。ＭＮはホームドメインに存在しているので、レガシＣＮとの通信にはホームプレフィックスを使用して構成されたアドレスを使用することで、ルーティングパスはほぼ最適化される。すなわち、ステップＳ５０３において、ＭＮは、ホームプレフィックスを使用してＣＮ（レガシＣＮ）と通信を行うためのホームアドレスを構成する。
【０１７１】
一方、ステップＳ５０２でＣＮがレガシタイプではないと判断された場合には、ステップＳ５０４において、ＭＮは、ＭＮに通知されているＣＮの現在のアドレス（気付アドレス）が、ＭＮのホームドメインに属するか否かの確認が行われる。
【０１７２】
ステップＳ５０４を実行し、ＭＮに通知されているＣＮの現在のアドレス（気付アドレス）が、ＭＮのホームドメインに属していないことが確認された場合には、ステップＳ５０３において、ＭＮは、ＭＮのホームプレフィックスを使用してＣＮ（ＲＯ可能なＣＮ）との通信を行うためのホームアドレスを構成する。すなわち、ＣＮはＲＯ可能であっても別のドメイン（外部ドメイン）に存在している場合には、通常は、ホームアドレスを用いた通信によって、このＣＮとのＲＯが実現される。なお、ＬＭＡがデフォルトのルーティングパス上に存在しない場合もあり、この場合には、後述のように完全な状態のＲＯは実現されない可能性がある。また、この場合はＣＮがＲＯ可能なので、ＭＮはＣＮとの通信において、オンリンク気付アドレスによるＲＯ通信を行うように決定してもよい。
【０１７３】
一方、ステップＳ５０４でＭＮに通知されているＣＮの現在のアドレス（気付アドレス）が、ＭＮのホームドメインに属していることが確認された場合には、ＭＮはステップＳ５０５を実行する。すなわち、ＣＮが同一ホームドメイン内に存在していることを把握した場合には、ステップＳ５０５において、ＭＮのプレフィックス選択モジュール４１０が、このＲＯ可能なＣＮとＲＯ通信を行うために、オンリンク気付アドレスを使用することを決定し、オンリンクプレフィックスを使用してオンリンク気付アドレスを生成し、適切なＮＡメッセージ（オンリンク気付アドレスを含む）をＡＲに送信するようＭＩＰｖ６モジュール４０９に要求する。なお、この場合のＮＡメッセージには、ホームアドレス及びオンリンク気付アドレスが含まれている。これによって、ＭＣｏＡのＢＵメッセージの送信がＭＮからＭＡＧに要求される。
【０１７４】
また、ステップＳ５００において、ＭＮの移動先のドメインがホームドメインではない場合、ＭＮは外部ドメイン（foreign domain）に存在していることを意味する。この場合、ＭＮは、ステップＳ５０６において、ＣＮのアドレスのリストを参照して、ＣＮのアドレスのリストからＣＮを１つ選択する。そして、ＭＮは、ステップＳ５０７において、ＣＮのアドレスが、ＭＮが存在している外部ドメインと同一の外部ドメインに関連しているか否かを判断する。
【０１７５】
ステップＳ５０７で、ＣＮのアドレスが、ＭＮが存在している外部ドメインと同一の外部ドメインに関連していると判断された場合、ステップＳ５０８において、ＭＮのプレフィックス選択モジュール４１０がオンリンク気付アドレスを使用することを決定し、オンリンクプレフィックスを使用してオンリンク気付アドレスを生成し、適切なＮＡメッセージ（オンリンク気付アドレスを含む）をＡＲに送信するようＭＩＰｖ６モジュール４０９に要求する。
【０１７６】
一方、ステップＳ５０７で、ＣＮのアドレスが、ＭＮが存在している外部ドメインと同一の外部ドメインに関連していないと判断された場合（すなわち、ＭＮとＣＮが異なるドメインに位置している場合）には、ステップＳ５０９において、ＣＮがレガシタイプか否かの判断が行われる。
【０１７７】
ステップＳ５０９でＣＮがレガシタイプであると判断された場合には、ステップＳ５１０が実行される。ＭＮが外部ドメインに存在する場合には、ＭＮとレガシＣＮとの通信において、ローカルブレイクアウトが実現されることで通信経路の効率化を図ることが可能である。これを実現するためには、例えば、ＭＮは、レガシＣＮとの通信に用いるホームアドレスとして、外部ＰＭＩＰｖ６ドメインで取得されるアドレスを使用すればよい。すなわち、ＭＮは、ステップＳ５１０において、外部ＰＭＩＰドメインのプレフィックスを使用してアドレスを構成し、このアドレスをホームアドレスとして、ＭＩＰｖ６モジュール４０９に対して適切なＮＡメッセージを送信するよう要求する。
【０１７８】
一方、ステップＳ５０９でＣＮがレガシタイプではないと判断された場合には、ステップＳ５１１が実行される。ＣＮが別のＰＭＩＰｖ６ドメインに存在しているのであれば、ＭＮは外部ＰＭＩＰｖ６プレフィックスを使用して取得される気付アドレスを用いて、このＣＮとの間でＲＯを実行してもよい。すなわち、この場合には、アドレスを構成する際にＰＭＩＰｖ６ドメインプレフィックスが使用されるか否か、更にはＲＯを行うか否かが決定される。例えばステップＳ５１１において、ＭＮは、このＣＮとの通信を行うために、ＬＭＡのアドレスのプレフィックスを使用して気付アドレスを生成する。
【０１７９】
次に、ローカルブレイクアウト用のプレフィックスが使用される場合やＭＮのオンリンクグローバルプレフィックスがＲＯに使用される場合のＭＮとＣＮとの間の通信におけるデータパケットの伝送経路について説明する。
【０１８０】
図７において、ＭＮ６１０は、ホームドメインでもあるＰＭＩＰｖ６ドメイン６００に接続されている。ＭＮ６１０は、オンリンクプレフィックス（経路最適化のためにＭＡＧ６２０から通知される）からオンリンク気付アドレスの構成を行う。なお、基本的に、ＭＮ６１０は、ホームアドレス及びオンリンク気付アドレスの両方を構成する。
【０１８１】
また、図７において、ＭＮ６１０はＣＮ６１１、６１２、６１３と通信を行っている。これらすべてのＣＮ６１１、６１２、６１３がＲＯ可能なＣＮであり、ＲＲメカニズムを用いて、ＭＮ６１０とＣＮ６１１、６１２、６１３のそれぞれとの間でＲＯパスが確立されているとする。さらに、ＭＮ６１０はＭＡＧ６２０に接続されており、ＣＮ６１１はＭＡＧ６２１に接続されており、ＣＮ６１２はＭＡＧ６２２に接続されているとする。すなわち、ＣＮ６１１及びＣＮ６１２は両方共、同一のＰＭＩＰｖ６ドメイン６００に接続されている。
【０１８２】
また、ＬＭＡ／ＨＡ／ＳＡＥアンカ６３０は、ＰＭＩＰｖ６ドメイン６００内のすべてのＭＮに対してＰＭＩＰｖ６ドメインプレフィックスを割り当てる。また、ＭＡＧ６２０とＭＡＧ６２１は固定ルータ６７０を通じて接続されている。さらに、ＬＭＡ／ＨＡ／ＳＡＥアンカ６３０は、ＭＡＧ６２０とＭＡＧ６２２と間のデフォルトのルーティングパス上には位置していないとする。したがって、ＭＮ６１０からＣＮ６１１への通信経路は、ＭＡＧ６２０から固定ルータ（fixed router）６７０及びＭＡＧ６２１を経由するパス６５２となる。また、ＭＮ６１０からＣＮ６１２へのデータ通信経路は、ＢＲ（Border Router：ボーダルータ）６４０及びＢＲ６４１を経由するパス６５１である。また、ＭＮ６１０からＣＮ６１３へのデータ通信経路は、ＭＡＧ６２０からＢＲ６４０を経由するパス６５０である。
【０１８３】
ここで、ＰＭＩＰｖ６ドメイン６００に接続されているＣＮが、ＰＭＩＰｖ６ドメインに加入していないＣＮであるとする。この場合、ＣＮはＰＭＩＰサービスを受けず、オンリンク気付アドレスを取得する。しかしながら、ＰＭＩＰサービスを受けていないにもかかわらず、ＭＮ６１０とＣＮ６１１及びＣＮ６１２とのデータ通信経路は、ＣＮ６１１及びＣＮ６１２が接続されているＭＡＧ６２１及びＭＡＧ６２２のそれぞれに応じたパス６５１及びパス６５２となる。
【０１８４】
３ＧＰＰのＰＭＩＰｖ６ドメインでは、あるオペレータによってＷＬＡＮのような信頼性の無いアクセスネットワークが所有されている一方、３ＧＰＰのコアネットワーク（ＬＭＡはコアネットワーク内に存在すると仮定される）は別のオペレータによって所有されている場合が起こり得る。ＭＮが同一アクセスネットワーク上のＣＮとの間でローカルブレイクアウトを実行する場合、データはパス６５１を経由することになる。すなわち、トラフィックは、コアネットワークを通過する必要はなく、インターネットを通過することになる。なお、ＰＭＩＰｖ６ドメインのプレフィックスが使用されている場合のみ、トラフィックは、ＬＭＡが存在するコアネットワーク経由する必要がある。
【０１８５】
また、ＰＭＩＰｖ６ドメインにおいて、ＭＮは、移動後にトンネリングを行わずにＣＮとの間で完全な経路最適化を実現したい場合もある。このような場合には、ＭＮはＭＡＧ／ＡＲと協同して、ＭＡＧ／ＡＲからオンリンクプレフィックスのみを要求する。さらに、ＭＮはＭＡＧ／ＡＲに対して、ＭＮがＰＭＩＰｖ６サービスを所望していない旨を通知する。なお、ここでは、ＭＮは、このドメインによって提供されるＰＭＩＰｖ６サービスを取得できる資格を有しているとする。このような場合には、ＭＮは、オンリンクプレフィックスを使用して気付アドレスを構成し、ＣＮとの間でＲＯを行う。ＭＮがＰＭＩＰｖ６サービスを所望しない場合、ＭＮが有する気付アドレスは、オンリンクプレフィックスから構成された気付アドレスのみとなり、ＭＮは、サブネットワークを変更するたびにホームエージェントにアップデートを行う必要がある。
【０１８６】
また、以下では、本発明を実現する上述の実施の形態とは異なる実施の形態として、従来の技術（図１１Ａ）で説明されているような複数のバインディングの登録（マルチ登録）に関連する問題（例えば、ＰＢＵとＢＵの競合に関する問題）や、バインディングアップデートが経由する長距離のパスに関連する問題を解決する方法について説明する。
【０１８７】
ここで説明する実施の形態における方法は、外部ドメインに接続されているインタフェース経由でそのインタフェースに関連するバインディングアップデートを送信する代わりに、外部ドメインに接続されているインタフェースに関連するＣＭＩＰのＢＵ登録のコンテンツ（内容）を、ホームドメインに接続されているＭＡＧへ（ホームに接続されているインタフェース経由で）渡すものである。このとき、ＭＡＧは、ＭＮの複数のインタフェースに係る到達可能状態を通知するＰＭＩＰ及びＣＭＩＰを組み合わせたバルク登録を送信するよう構成される。この方法を実行することによって、複数の位置更新シグナリングの伝送が回避され、ホームドメインに接続されたインタフェース経由で、より迅速なＣＭＩＰのＢＵ登録が実現される。
【０１８８】
以下、この実施の形態における方法について、図８Ａを参照しながら説明する。図８Ａにおいて、ＭＮ７００は２つのインタフェースを有している。ＭＮ７００のインタフェース１（ＩＦ１）はＭＡＧ７０５を通じて外部ドメインに接続されている。ＭＮ７００は、ＭＡＧ７０５に接続する場合には、ＭＡＧ７０５からＲＡ７１１を受信した後に、ＲＡ７１１に含まれる外部プレフィックスからＩＦ１に関する気付アドレスを構成する。また、ＭＮ７００は、インタフェース２（ＩＦ２）を通じて、ホームＰＭＩＰドメインのＷＬＡＮアクセスネットワークのＭＡＧ７０６に接続する。なお、図８Ａでは、ＭＮ７００はホームＰＭＩＰドメインとＷＬＡＮに係るアクセス技術で接続しているが、任意のアクセス技術でＭＡＧと接続可能である。
【０１８９】
ＭＮ７００は、ＩＦ２においては、まずＷＬＡＮアクセスネットワークのＭＡＧ７０６からビーコン信号（ＷＬＡＮビーコンシグナル）７１２を受信する。ＭＮ７００は、メッセージ（Ｌ２接続シグナル）７１３によってＬ２接続を行う場合、このメッセージ７１３と共にＩＦ１に関連するＣＭＩＰのＢＵの内容をＭＡＧ７０６へ渡すことが可能である。なお、ＭＮ７００は、メッセージ７１３にＩＦ１に関連するＣＭＩＰに関するＢＵのコンテンツを挿入してもよく、あるいは、メッセージ７１３とは異なる別のメッセージにＩＦ１に関連するＣＭＩＰに関するＢＵのコンテンツを挿入して送信してもよい。また、ＭＮ７００は、ＩＦ２がホームＰＭＩＰドメインに接続しているかもしれないという情報を把握したうえで、ＩＦ１に関連するＣＭＩＰのＢＵのコンテンツをＭＡＧ７０６へ渡すようにしてもよい。なお、ＭＮ７００は、ＩＦ２に関する最新のローミングプロファイル情報を保持し、保持されている情報に基づいてＩＦ２がホームＰＭＩＰドメインに接続しているか否かを判断してもよく、あるいは、ＩＦ２がホームＰＭＩＰドメインに接続されていると単に推定するだけでもよい。また、ＩＦ２が接続しているドメインから取得可能な情報を参照することで、ＩＦ２がホームＰＭＩＰドメインに接続しているか否かを判断してもよい。また、ＩＦ２を含むＭＮ７００のインタフェースのいずれもホームＰＭＩＰドメインに接続していないと判断された場合には、通常のＣＭＩＰに関するＢＵの送信を行うようにしてもよい。
【０１９０】
ＭＮ７００からＭＡＧ７０６へメッセージ７１３によって提供されるＣＭＩＰに関するＢＵのコンテンツとしては、例えば、ＩＦ１の気付アドレス、ＩＦ１のホームアドレス、許可データ（authorization data）、ＣＭＩＰに関するＢＵのシーケンスナンバーのうちのいずれかの情報や、これらのうちの複数の情報などを挿入することが可能である。なお、許可データは、ＭＮ７００のＩＦ１のＨｏＡとＭＮ７００のＩＦ１の気付アドレスとを連結した情報を、ＭＮ７００のセキュリティキーを用いて暗号化することによって得られるものである。ＭＮ７００のセキュリティキーは、ＨＡ（ＬＭＡ／ＨＡ）７１０が任意のインターネット鍵交換プロトコルを使用して生成した鍵である。また、ＭＮ７００は、メッセージ７１３を通じて、ＩＦ１の識別子をＭＡＧ７０６へ渡す必要があるかもしれない。なお、ＩＦ１がＩＦ２のホームプレフィックスとは異なるホームプレフィックスを使用してホームアドレスを構成する場合には、ＩＦ１の識別子は、ＬＭＡ／ＨＡ７１０におけるバインディングを区別できるようにしておく必要はない。
【０１９１】
ＭＡＧ７０６がＡＡＡサーバ（図８Ａには不図示）からＭＮ７００のホームプレフィックスを取得した場合、ＭＡＧ７０６は、このホームプレフィックスを含むＲＡ７１６を送出するととともに、ＭＮ７００の両方のインタフェースに関連するＣＭＩＰ及びＰＭＩＰのＢＵを組み合わせたバルク登録の情報を送信する。メッセージ（ＰＢＵ）７１４は、ＣＭＩＰに関するＢＵのコンテンツ（ＩＦ１に関するＢＵのコンテンツ）をＰＭＩＰのＰＢＵ（ＩＦ２に関するＰＢＵ）に組み合わせたメッセージを示しており、メッセージ（ＰＢＡ）７１５は、その応答メッセージを示している。なお、メッセージ７１４は、ＣＭＩＰに関するＢＵのコンテンツやＩＦ１のインタフェース識別子などを伝送するための新しいオプションを有することを除いて、通常のＰＭＩＰｖ６動作において用いられている通常のＰＢＵであることが望ましい。
【０１９２】
また、ＭＮ７００は、メッセージ７１３と共にＣＭＩＰに関するＢＵのコンテンツを送信せずに、ＭＡＧ７０６からＲＡ７１６を受信した後に、ＣＭＩＰに関するＢＵのコンテンツを通知するための新しいＬ２メッセージ又はＬ３メッセージを送信してもよい。また、ＩＦ２がホームＰＭＩＰドメインに接続されていることをＭＮ７００が確信できない場合には、ＭＮ７００は、ＭＡＧ７０６からのＲＡ７１６の受信を待機し、ＲＡ７１６の受信によってＩＦ２がホームＰＭＩＰドメインに接続されていることを確認してからＣＭＩＰに関するＢＵのコンテンツを送信してもよい。なお、ＲＡ７１６の受信後にＣＭＩＰに関するＢＵのコンテンツを送信する場合のシグナリングに関しては、図８Ａには不図示である。また、ＭＮ７００がＲＡ７１６の受信後にＣＭＩＰに関するＢＵのコンテンツを送信する場合、ＭＡＧ７０６は、ＲＡ７１６の送信後にＭＮ７００からＣＭＩＰに関するＢＵのコンテンツを取得してから、ＰＢＵ７１４を送信する必要がある。したがって、この場合は基本的に、ＰＢＵ７１４の送信に若干の遅延が生じることになる。
【０１９３】
ＩＦ１がバインディングをリフレッシュする必要がある場合、又は、ＩＦ１のハンドオフなどの理由によってＩＦ１に関する新しいバインディングを作成して新たなアドレス構成を得る必要がある場合には、ＩＦ２が依然としてＭＡＧ７０６に接続されていると仮定してＩＦ２からＭＡＧ７０６に対して関連情報（バインディングのリフレッシュに必要な情報）が渡される。この場合には、ＭＡＧ７０６は、リフレッシュＰＢＵを用いることによって、ＩＦ１のＣＭＩＰに関するＢＵのコンテンツをＬＭＡ／ＨＡ７１０へ送信することが可能である。なお、ＭＡＧ７０６からのバインディングのリフレッシュが後で行われる（すなわち、すぐには行われない）ように設定されている場合には、ＭＮ７００は、例えばＣＭＩＰに関するＢＵシグナリングの遅滞を防ぐよう明示するメッセージをＭＡＧ７０６へ送信することで、ＣＭＩＰに関するＢＵのコンテンツの迅速な送信をＭＡＧ７０６に促すようにしてもよい。以上のような実施の形態における方法を用いることで、複数のバインディングの登録（マルチ登録）に代わって、バルク登録が実現される。さらに、ＭＮ７００に関する複数の位置更新バインディングの登録には、ホームドメインを経由するパス（より短いルーティングパス）が利用される。
【０１９４】
また、ホームＰＭＩＰドメインに接続されているＭＮのプレフィックスがＬＭＡから提供されたものである場合には、上述の動作と比べてシグナリングが若干異なる。以下、このような場合のシグナリングに関して、図８Ｂを参照しながら説明する。
【０１９５】
図８Ｂにおいても、ＭＮ７１６は２つのインタフェースを有しており、ＩＦ１においてＭＡＧ７１７を経由して外部ドメインに接続されているとともに、ＩＦ２においてＭＡＧ７１８を経由してホームＰＭＩＰドメインに接続されている。なお、ここでは、ＭＮ７１６のＩＦ２がホームＰＭＩＰドメインに移動したばかりであると仮定する。
【０１９６】
ＭＮ７１６は、ＩＦ１においてＭＡＧ７１７からＲＡ７２０を受信し、ＲＡ７１１に含まれる外部プレフィックスからＣｏＡを構成している。一方、ＭＮ７１６は、ＩＦ２においてビーコン信号（ＷＬＡＮビーコンシグナル）７２１をＭＡＧ７１８から受信する。そして、ＷＬＡＮビーコンシグナル７２１の受信後、ＭＮ７１６はメッセージ（Ｌ２接続シグナル）７２２によってＭＡＧ７１８とＬ２接続を行う。ＭＮ７１６のＬ２接続後、ＭＡＧ７１８は、ＭＮ７１６のＩＦ２に関するホームプレフィックスを取得するためにＰＢＵ７２３を行い、その後、ＡＡＡサーバ（不図示）においてＭＮ７１６の真正性を確認するためにＡＡＡの検証が行われる。
【０１９７】
ＭＡＧ７１８は、ＬＭＡ／ＨＡ７１９からホームプレフィックスを含むＰＢＡ７２４を受信した後でのみ、ＲＡ７２５の送信が可能となる。ＭＡＧ７１８からＲＡ７２５を受信した後、ＭＮ７１６は、ＣＭＩＰに関するＢＵのコンテンツを含むメッセージ７２６を送信する。なお、メッセージ７２６は、Ｌ２メッセージであってもよく、Ｌ３メッセージであってもよい。
【０１９８】
このシナリオ（ＬＭＡ／ＨＡ７１９がプレフィックスを提供するシナリオ）では、ＭＮ７１６からＣＭＩＰに関するＢＵのコンテンツを含むメッセージ７２６を受信したＭＡＧ７１８は、ＣＭＩＰに関するＢＵのバインディングを登録するために、第２のメッセージを送信する必要がある。図８Ｂには、この第２のメッセージ（ＰＢＵ７２７）と、その応答であるＰＢＡ７２８が図示されている。
【０１９９】
また、このシナリオでは、最初の接続の際に、複数のＰＢＵ／ＰＢＡ（ＰＢＵ７２３とＰＢＡ７２４とのペアや、ＰＢＵ７２７とＰＢＡ７２８とのペア）が送信される必要があるが、その後のホームＰＭＩＰドメインにおける接続では、コンテキストトランスファーを利用することでＰＢＵを二重に送信しないようにすることも可能である。例えば、ＭＮ７１６が移動を行って、ＩＦ２がホームＰＭＩＰドメイン内の別のＭＡＧ（新たなＭＡＧ）へ接続し、ＩＦ１のＣＭＩＰバインディングを再送する必要が生じた場合、ホームＰＭＩＰドメイン内の新たなＭＡＧ（ＩＦ２が新たに接続したＭＡＧ）は、ＩＦ２のホームプレフィックスに関する情報をコンテキストトランスファーのメカニズムを利用して取得してもよい。この場合、ＰＢＵ７２７のような新しいＰＢＵのみ送信されればよく、この後の接続においても、ＰＢＵ７２３やＰＢＡ７２４は送信される必要はない。
【０２００】
例えば、上述のような２重のＰＢＵ／ＰＢＡシグナリングが送信される可能性がある点を除けば、ホームドメインを経由してＣＭＩＰのＢＵの内容を送信するほうが、より迅速に行われる可能性がある。ＭＮが２つ以上のインタフェースを有する場合には、ＰＢＵ７１４やＰＢＵ７２７によって、１つ又は複数のインタフェースのＣＭＩＰに関するＢＵのコンテンツが送信可能である。
【０２０１】
また、上述の実施の形態に係る方法は、ＰＭＩＰドメイン（ホームドメイン）のパスを経由して、外部ドメインに接続しているインタフェースに係るＣＭＩＰに関するＢＵを送信することで、迅速なＣＭＩＰのＢＵを実現することが可能である。しかしながら、例えば、ホームＰＭＩＰドメイン内に位置する情報サーバからホームＰＭＩＰドメインが輻輳状態である旨が通知された場合などには、ＣＭＩＰのＢＵは通常のパス（すなわち、ＩＦ１経由）で送信されたほうがよい場合もあり得る。
【０２０２】
基本的にＣＭＩＰのＢＵのパスは、何らかの信頼あるネットワークエンティティからの情報に基づいて、ＭＮによって選択される。例えば図８Ａや図８Ｂにおいて、ホームＰＭＩＰドメインが輻輳している場合には、ＩＦ２が接続されているＭＡＧ（ＭＡＧ７０６やＭＡＧ７１８）が、ＰＭＩＰ及びＣＭＩＰのＢＵのバルク登録をＩＦ１経由で送信するようＭＮ７１６へ要求してもよい。
【０２０３】
この場合、ＭＮがＰＭＩＰ及びＣＭＩＰのＢＵのバルク登録をＩＦ１経由で行えるようにするために、ＭＡＧは、タイムスタンプオプションを付加したＰＭＩＰのＢＵのコンテンツを提供する必要がある。
【０２０４】
また、ＭＮのＩＦ２が直接ホームリンクに接続されている場合もあり得る。このような場合には、ＭＮは、例えばＬＭＡ／ＨＡへ近隣通知ＩＣＭＰメッセージを送信することによって、ＩＦ１におけるＣＭＩＰに関するＢＵのコンテンツをＬＭＡ／ＨＡへ提供することが可能である。
【０２０５】
次に、図１１Ｂに図示されているような従来の技術におけるハンドオフの問題やパケットロスの問題を解決するための方法について説明する。図１１Ｂを用いて上述したように、ＩＦ１（ホームＰＭＩＰドメインから外部ドメインへ移動するインタフェース）でパケットロスが生じる主要な理由は、ＩＦ１が移動後に接続した場合に送信されるＣＭＩＰのＢＵよりも、ＩＦ１が移動前に接続していた状態で送信されるＰＭＩＰのＰＢＵが遅れてＨＡ（ＬＭＡ／ＰＤＮ−ＧＷ／ＨＡ２７０）に届くことにある。
【０２０６】
以下では、このような問題を解決するために、ＩＦ１のＣＭＩＰのＢＵメッセージに、ＩＦ１に関連するＰＭＩＰのＰＢＵメッセージ（ＩＦ１の移動前に係るＰＢＵメッセージ）と同じようなタイムスタンプオプションを設ける方法について説明する。
【０２０７】
この方法では、ＩＦ１に関連するＣＭＩＰのＢＵメッセージが、ホームＰＭＩＰドメインに接続されている、移動しないインタフェース（すなわちＩＦ２）を経由して送信される。これにより、移動しないインタフェースに接続されているＭＡＧによって、ＣＭＩＰのＢＵメッセージにタイムスタンプオプションが付加されるようになる。タイムスタンプオプションが付加されることにより、ＬＭＡ／ＨＡは、ＩＦ１に関する最も新しいバインディング状態をタイムスタンプ値から容易に識別することが可能となる。なお、例えばＭＡＧは、ＬＭＡ／ＨＡへ送信するメッセージに対して常に、又はその必要性を判断して、タイムスタンプオプションを付加してもよく、ＭＮがＭＡＧに対して明示的にタイムスタンプオプションの付加を要求してもよい。
【０２０８】
さらに、この方法では、ＣＭＩＰのＢＵメッセージを、移動していないインタフェースに関連したＰＭＩＰのＰＢＵメッセージと結合することが可能であり、この結合によってシグナリングの更なる最適化が実現される。以下、図９Ａを参照しながら、この方法について説明する。
【０２０９】
図９Ａにおいて、ＭＮ８０５は２つのインタフェースを有している。ＩＦ２は無線リンクを通じてホームＰＭＩＰドメイン８００に接続されており、ＭＡＧ８１１に直接接続されている。一方、ＭＮ８０５のＩＦ１は、無線リンクを通じてホームＰＭＩＰドメイン８００のＭＡＧ８１０に接続されている状態から、外部ドメイン８０１へ移動したとする。なお、ＩＦ１がＭＡＧ８１０に接続していた時間が短時間であるとする。また、ＡＲ８１２が外部ドメイン８０１に接続されており、ＭＮ８０５のＩＦ１は移動してＡＲ８１２に接続したとする。また、ホームＰＭＩＰドメイン８００と外部ドメイン８０１とがインターネット８０２に接続されているとする。
【０２１０】
このように、ＩＦ１に関して迅速な移動（ＭＡＧ８１０への短時間の接続）が起こる場合、ＭＮ８０５は、ＩＦ１の移動前の接続に係るメッセージ（ＰＢＵ）８２５がＩＦ１の移動後のＣＭＩＰのＢＵより遅れて到着してしまう可能性があると予測するかもしれない。このような場合、登録メッセージの順序の誤りを防ぐため、ＭＮ８０５は、メッセージ８２６によって、ＩＦ１に関連したＣＭＩＰのＢＵメッセージを送信するようＭＡＧ８１１へ要求するとともに、さらに、ＭＡＧ８１１がこのメッセージを送信する際にタイムスタンプオプションを挿入するようＭＡＧ８１１へ要求することが可能である。このメッセージ（要求メッセージ）８２６は、ＩＦ１に関連したＣＭＩＰのＢＵのコンテンツを含んでいればよく、Ｌ２メッセージ又はＬ３メッセージのどちらであってもよい。
【０２１１】
要求メッセージ８２６を受信すると、ＭＡＧ８１１は、メッセージ（登録メッセージ）８２７をＬＭＡ／ＨＡ８２０へ送信する。このメッセージ８２７は、ＭＮ８０５から提供されたＣＭＩＰに関するＢＵのコンテンツを運ぶためのオプションと、ＭＡＧ８１１によって挿入されたタイムスタンプオプションとが、通常のＰＭＩＰのＰＢＵメッセージに付加されたものである。なお、挿入されるタイムスタンプオプションは、ＭＡＧ８１１内で動作する時計から得られる時間情報を含んでいる。
【０２１２】
図９Ｂには、ＬＭＡ／ＨＡ８２０のバインディングキャッシュ８３０が図示されている。図９Ｂにおいて、バインディングキャッシュ８３０の最初のエントリは、ＭＡＧ８１１へのＩＦ２の接続に関連して送信されたＰＢＵによって作成された登録を表している。また、バインディングキャッシュ８３０の２番目のエントリは、ＭＡＧ８１１から新たなメッセージ８２７を受信した際にＬＭＡ／ＨＡ８２０で作成された登録を表している。このメッセージ８２７は、ＩＦ１のＣＭＩＰに関するＢＵであり、上述のようにタイムスタンプ値が付加されている。なお、メッセージ８２７に関連してＬＭＡ／ＨＡ８２０で作成されたキャッシュは、ＣＭＩＰに関するＢＵの現在の時刻に従ったＣＭＩＰのＢＵのシーケンスナンバーを有している。
【０２１３】
ここで、メッセージ８２７の後にＭＡＧ８１０からの送信されたメッセージ（ＰＢＵ８２５）がＬＭＡ／ＨＡ８２０に届いた場合、メッセージ８２５に存在するタイムスタンプ値はメッセージ８２７によって示される最新の時刻よりも前の時刻となり、メッセージ８２５は破棄されることになる。この結果、登録順序の誤りによるＩＦ１のパケットロスは起こらなくなる。
【０２１４】
ＩＦ２を通じてＣＭＩＰのＢＵを送信する利点は、ＣＭＩＰのＢＵに時刻（タイムスタンプ値）を付加できることにある。一方、ＣＭＩＰに関するＢＵをＩＦ１から送信し、ＣＭＩＰのＢＵの時間情報をメッセージ８２７によってＩＦ２から送信した場合には、このメッセージ８２７がＣＭＩＰに関するＢＵやＰＢＵ８２５より遅れて到着してしまう可能性があり、メッセージ８２７の到着前にＣＭＩＰのＢＵがＰＢＵ８２５から得られる誤ったバインディングによって、即座に消去されてしまう可能性がある。
【０２１５】
次に、図１１Ｃに示されているような従来技術に係る問題を解決する方法について説明する。図１１Ｃに図示されている従来技術では、３ＧＰＰドメイン内に存在する任意のＣＮとの経路最適化に関して、オンリンクプレフィックスを用いて気付アドレスを構成することがあまり有効ではない（オンリンクプレフィックスを用いて気付アドレスを構成した場合、ＡＲの接続を変更するたびに経路最適化セッションを実行しなければならない可能性がある）という問題がある。
【０２１６】
以下、図１０を参照しながら、ＭＮがｅＰＤＧ内プレフィックス又はｅＰＤＧ外プレフィックスを用いて３ＧＰＰドメイン内に存在する任意のＣＮとの通信に用いるための気付アドレスを構成し、さらには、ｅＰＤＧ／ＭＡＧに対して、“Ｈ”フラグや任意のインタフェース識別パラメータを有するＰＭＩＰ及びＣＭＩＰのバルク登録の実行を要求する方法について説明する。
【０２１７】
図１０において、ＭＮ９０５は非信頼ＷＬＡＮアクセスネットワーク９０２に移動し、ＣＮ９４０及びＣＮ９４１との間で経路最適化通信を行おうとしている。なお、この図１０の構成は、図１１Ｃの構成とほぼ同一であり、ここでは構成要素に関する説明を省略する。
【０２１８】
ＭＮ９０５は、メッセージ９５０によって、異なるプレフィックスをＡＲ９１０から受信する。なお、ＭＮ９０５が、異なる位置に配置された各ＣＮと通信を行うための適切なプレフィックスをそれぞれ選択するために、プレフィックスの要求を行ってもよい。このプレフィックスは、ＡＲ９１０から提供されるオンリンクプレフィックスであってもよく、ＬＭＡ／ＰＤＮ−ＧＷ／ＨＡ９３０の配下を示すＰＭＩＰのローカルプレフィックスであってもよく、ｅＰＤＧインプレフィックス（ePDG in-prefix）やｅＰＤＧアウトプレフィックス（ePDG out-prefix）であってもよい。ｅＰＤＧアウトプレフィックスは、ｅＰＤＧ（ｅＰＤＧ／ＭＡＧ）９２０に関連付けられたプレフィックスやｅＰＤＧ９２０の配下のプレフィックスなどを表している。また、ｅＰＤＧインプレフィックスは、例えばＧＷ９３１の配下のプレフィックスなどを表している。なお、ｅＰＤＧインプレフィックス又はｅＰＤＧアウトプレフィックスは、ＭＮごとに提供されるプレフィックスであってもよく、あるいは、複数のＭＮに共通して提供されるプレフィックスであってもよい。
【０２１９】
例えばＭＮ９０５がＣＮ９４０と通信を行う際には、ｅＰＤＧアウトプレフィックスを用いて最適な経路を実現し、位置登録シグナリングの低減を図ることが適切であることは当業者にとっては明白である。ＭＮ９０５とＣＮ９４０との間の経路最適化パスにおいて、ｅＰＤＧ９２０が経路最適化パス上に存在するとともにルーティング階層の最も遠くに位置しており、経路最適化や位置登録シグナリングの低減が実現される。さらに、ＭＮ９０５がＣＮ９４１と通信を行う際には、ＧＷ９３１の配下のｅＰＤＧインプレフィックスを用いて最適な経路や位置登録シグナリングの低減を実現することが適切である。ＭＮ９０５とＣＮ９４１との間の経路最適化パスにおいても同様に、ＧＷ９３１の折り返しによって経路最適化や位置登録シグナリングの低減が実現される。
【０２２０】
また、ｅＰＤＧ９２０が、ＭＮ９０５及びＣＮ９４０の現在の位置を把握した後、ＭＮ９０５及びＣＮ９４０に対してｅＰＤＧアウトプレフィックスの使用を忠告してもよい。ＭＮ９０５及びＣＮ９４０からｅＰＤＧ９２０へのトンネルが存在しているので、ｅＰＤＧ９２０は、ＭＮ９０５及びＣＮ９４０の位置を把握し、これらのエンドノード（ＭＮ９０５及びＣＮ９４０）に対してアドバイスを行うことが可能となる。
【０２２１】
一方、ｅＰＤＧアウトプレフィックスを使用する場合には、プレフィックスを使用して構成されたアドレスに関して、ｅＰＤＧ９２０によって重複アドレス検出（ＤＡＤ：duplicate address detection）が行われる必要があるかもしれない。これは、例えば、ｅＰＤＧ９２０におけるプレフィックス割り当てに関して、共有プレフィックスタイプのモデルが実施されている場合に起こり得る。ＭＮ９０５がＣＮ９４０との経路最適化のための気付アドレスをｅＰＤＧアウトプレフィックスを使用して構成する場合には、ＭＮ９０５は、気付アドレスを構成して、ＣＭＩＰのＢＵ及びＰＭＩＰのＰＢＵメッセージをＬＭＡ９３０へ送信するようｅＰＤＧ９２０に要求する。ＭＮ９０５は、基本的に、ＣＭＩＰに関するＢＵのコンテンツを作成して、メッセージ９５１によって示されるようなトンネル経由でｅＰＤＧ９２０へ渡す。
【０２２２】
ｅＰＤＧ（ｅＰＤＧ／ＭＡＧ）９２０は、ＣＭＩＰに関するＢＵに加えて、ＬＭＡ９３０におけるＰＭＩＰのホームプレフィックスに関してＰＭＩＰのＰＢＵを実行する必要がある。したがって、ｅＰＤＧ９２０は、このようなＰＭＩＰのＰＢＵメッセージ及びＣＭＩＰのＢＵメッセージの両方を結合して送信することが可能である。ＣＭＩＰのＢＵメッセージ及びＰＭＩＰのＰＢＵメッセージの両方を伝送するメッセージは、メッセージ９５２によって示されているように、ｅＰＤＧ９２０からＬＭＡ９３０へ伝送される。ＰＭＩＰ及びＣＭＩＰが結合されたバインディングは、ＢＩＤ、インタフェースＩＤ、“Ｈ”フラグなどの手段によって識別可能である。
【０２２３】
ＭＮ９０５がローカルアクセスドメイン（非信頼ＷＬＡＮアクセスネットワーク）９０２内に移動したとき、ＡＲが変更されてもパス９６０経由で経路最適化通信が実現可能な場合には、位置更新シグナリングが頻繁に行われる必要はない。これは、ＭＮ９０５が軌跡９０６で移動した場合であっても、依然として同一のアクセスルータ（ｅＰＤＧ／ＭＡＧ）９２０に接続されていることによる。
【０２２４】
また、ＭＮ９０５及びＣＮ９４０がｅＰＤＧアウトプレフィックスを用いて構成された気付アドレスのＲＲシグナリングやバインディング登録を完了した場合には、データパケット伝送が開始される。このとき、データパケットがパス９６０を通じて伝送される場合には、パケットの送信元アドレスはｅＰＤＧアウトプレフィックスから得られるアドレスとなっている。このパケットはｅＰＤＧ９２０へトンネルされ、ｅＰＤＧ９２０でこのパケットのデカプセル化が行われる。デカプセル化後のパケットのあて先アドレスは、ｅＰＤＧ９２０のプレフィックスから得られるＣＮ９４０の気付アドレスである。ｅＰＤＧ９２０は、ＣＮ９４０あてのトンネルでパケットの再カプセル化を行う。なお、トンネリング処理の詳細に関しては図１０には明示されていないが、当業者であれば容易に理解可能である。
【０２２５】
ＭＮ９０５がＣＮ９４１と通信を行っており、デフォルトのパスがＧＷ９３１経由である場合には、ｅＰＤＧインプレフィックスを使用して経路最適化を行うことが有効である。例えば、ＧＷ９３１が何らかのポリシを実施しており、ネットワークにおいて、ＭＮ９０５とＣＮ９４１との間でＧＷ９３１を経由するデフォルトの最短経路が実現されている可能性がある。さらに、ＧＷ９３１由来のプレフィックス（すなわち、ｅＰＤＧインプレフィックス）を使用して気付アドレスが構成されている場合には、ホームドメイン内を移動する間のＭＮ９０５のシグナリングの負荷が最適化され、さらに経路最適化が実現可能となる。ＭＮ９０５からＣＮ９４１へ送信されるデータパケットは、ＧＷ９３１のプレフィックスに由来する送信元アドレスを有している。このパケットは、ｅＰＤＧ９２０へトンネルされ、ｅＰＤＧ９２０は、このデータパケットをデカプセル化してＧＷ９３１にトンネルする。ＧＷ９３１は、パケットのデカプセル化を行って、さらに、ＭＡＧ９２１へのトンネルでカプセル化する。データパケットがＭＡＧ９２１に到達すると、ＭＡＧ９２１は、ポイントツーポイント回線リンクを通じてデータパケットを直接ＣＮ９４１へ渡す。なお、図１０には、ｅＰＤＧインプレフィックスを使用して気付アドレスを構成しているＭＮ９０５から、ＣＮ９４１へ伝送されるパケットの経路最適化パス９６１が図示されている。
【０２２６】
なお、ルーティング階層がより高いルータから提供されたプレフィックスを用いており、そのルータが任意のＭＮとＣＮとの通信パスのデフォルトルータである場合には、そのルータ由来のプレフィックスを用いて気付アドレスを構成することが望ましい。これによって、頻繁な位置更新シグナリングが行われないようにして、経路最適化を実現することが可能となる。
【０２２７】
また、ＣＮ９４０と通信を行う場合は、経路最適化パスはｅＰＤＧ９２０（ＭＮ９０５とＣＮ９４０との間の経路最適化パスにおいて、ルーティング階層の最も高い位置に配置されたルータ）を経由する。したがって、そのプレフィックスを使用して経路最適化を実現するとともに位置更新シグナリングの量を低減することが望ましい。また、ＣＮ９４１と通信を行う場合は、経路最適化パスはＧＷ９３１（ＭＮ９０５とＣＮ９４１との間の経路最適化パスにおいて、ルーティング階層の最も高い位置に配置されたルータ）を経由する。したがって、ＧＷ９３１由来のプレフィックスを使用して経路最適化を実現するとともに、位置更新シグナリングの量を低減することが望ましい。なお、これらは、プレフィックスを選択する際の基本的な考え方に基づくものであるが、ＭＮがこうした基本的な考え方に基づくプレフィックスの選択を行えるようにするために、どのプレフィックスを選んだらよいかに関して、ネットワークから通知される必要があるかもしれない。例えば、何らかのネットワークエンティティがＭＮやＣＮのパケットを監視し、その監視結果に応じてＭＮやＣＮに対してアドバイス（適切なプレフィックスの通知）を行えるようにしてもよい。
【０２２８】
なお、本明細書では、本発明が最も実用的かつ好適な実施例となるように考慮されて図示及び説明されているが、当業者であれば、上述の各装置の構成要素に係る設計やパラメータの詳細において、発明の範囲から逸脱しない程度に様々な変更が行われてもよいことは明白である。
【０２２９】
例えば、モバイルノードが２つのインタフェースを有しており、一方のインタフェースがホームＰＭＩＰｖ６ドメインに接続されており、他方のインタフェースが外部ＰＭＩＰｖ６ドメインに接続されている場合に対して、本発明を適用することが可能である。また、例えば、ＣＮが、ＭＮのホームＰＭＩＰｖ６ドメインに存在し、外部ＰＭＩＰｖ６ドメインに接続されているＭＮのインタフェースのホームアドレスと通信を行っているような場合であっても、本発明に係る技術を用いることで経路最適化が実現される。
【０２３０】
さらに、上述の実施の形態では、ＵＥが移動前に接続しているドメインは、ホームＰＭＩＰｖ６ドメインであるが、例えば、ホームオペレータが管理していない外部ＰＭＩＰｖ６ドメインや別の３ＧＰＰドメインであってもよく、ＭＩＰｖ６を使用せずに接続しているアクセスネットワークなどであってもよい。また、ＷｉＭＡＸやＷＬＡＮなどの異なるアクセスネットワークであってもよく、ＦＭＣ（Fixed Mobile Convergence）などによって無線系と固定系が統合されたネットワークや、ＮＧＮ（Next Generation Network）などの高度に管理されるネットワーク構成に関わるネットワークでもよく、それらネットワークとの信頼関係が高くても低くてもよい。また、同様に、上述の実施の形態では、ＵＥが移動後に接続するドメインは外部ネットワークであるが、この外部ネットワークは、例えば、外部ＰＭＩＰｖ６ドメイン、非３ＧＰＰアクセスネットワークなど、ＵＥがＭＩＰｖ６を起動させるドメイン（ＵＥがＭＩＰｖ６を使用するドメインであればアクセス技術には限定されない）である。また、ＵＥがホームＰＭＩＰｖ６ドメインに接続したまま移動しないで、ローカルブレイクアウトなどを目的としてＭＩＰｖ６を起動する場合においても、本発明は適用可能である。
【０２３１】
また、本明細書では、ＭＮのネットワークインタフェースが複数であることを前提に説明を行っている部分があるが、本発明を実施するうえでの論理的なインタフェースが複数あればよい。例えば、１つの無線部を複数の接続方式で共用し、ネットワークインタフェースの観点からはその変化が問題にならない程度の速度で切り替えたり、レイヤ２で論理的なリンクを維持したりすることにより、ネットワーク部からは複数のインタフェースを介してネットワークに接続している場合と同等に動作できるよう構成されていてもよい。
【０２３２】
また、本発明の説明において、ネットワーク構成を説明に用いた図に示す簡単な構成を挙げて示したが、ローカルネットワークドメインの構成は、複数オペレータ間のローミング関係も含めて多岐にわたることが考えられる。例えば、ＭＡＧはモバイルノードの直接的なアクセスルータである構成や、ＭＡＧが異なるアクセスネットワーク（ローミングを含む）との境界ルータであり、モバイルノードは一旦その異なるアクセスネットワークに接続した後、そのアクセスネットワークを介して境界ルータであるＭＡＧに接続するという構成が考えられる。いずれの場合も、様々なパラメータや端末からＭＡＧへの到達手順、端末の通信手順などの設計部分が異なるが、本発明の動作に関しては同様に適用できることは明白である。
【０２３３】
また、上述の実施の形態では、ローカルモビリティ管理の環境であることが仮定されているが、モバイルルータ（ＭＲ：Mobile Router)（及びその配下のノード）により構成されたモバイルネットワーク（Mobile Network)（若しくは階層化されたモバイルネットワーク）に本発明を適用することも可能である。
【０２３４】
例えば、モバイルネットワークの構成方法の一つであるＮＥＭＯ（NEtwork MObility）は、ＭＲがＨＡ（Home Agent）に移動ネットワーク（及び端末）の移動登録を行うことにより移動端末に対するモビリティサポートを提供しているが、本明細書におけるＭＡＧがＭＲに対応する形で適用可能である。この場合、ＬＭＡはＭＲのＨＡに対応すると考えることができる。さらに、ＰＭＩＰを用いたネットワークを提供するネットワークオペレータがローミング関係などにより、ＰＭＩＰで構成しているＭＡＧ−ＬＭＡ間のトンネルを多段に用いるような場合は階層化されたモバイルネットワークに相当する。
【０２３５】
さらに、オーバレイネットワークの環境に本発明を適用することも可能である。例えば、ＭＡＧによる移動端末に対するモビリティサポートをｐＨＡ（Proxy HA：プロキシＨＡ）に対応する形で適用可能である。この場合、モバイルノードの移動の起点（ある時点を基準とするものであったり（相対的）、ネットワークオペレータへの登録の状態（確定的）であったり、様々な場合があり得る）となるホームエージェント若しくはモバイルノードの接続先であるホームエージェントから登録情報を受信する他のホームエージェントはＬＭＡに対応すると考えることができる。
【０２３６】
なお、上記の本発明の実施の形態の説明で用いた各機能ブロックは、典型的には集積回路であるＬＳＩ（Large Scale Integration）として実現される。これらは個別に１チップ化されてもよいし、一部又はすべてを含むように１チップ化されてもよい。なお、ここでは、ＬＳＩとしたが、集積度の違いにより、ＩＣ（Integrated Circuit）、システムＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。
【０２３７】
また、集積回路化の手法はＬＳＩに限るものではなく、専用回路又は汎用プロセッサで実現してもよい。ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Field Programmable Gate Array）や、ＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサを利用してもよい。
【０２３８】
さらには、半導体技術の進歩又は派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。例えば、バイオ技術の適応などが可能性としてあり得る。
【産業上の利用可能性】
【０２３９】
本発明のネットワークノード及び移動端末は、移動端末がＰＭＩＰドメインを移動する際に、選択可能な様々なプレフィックスがアクセスルータから提供されるようにするという効果や、移動端末が利用可能なプレフィックスから構成する必要があるアドレスのタイプを選択し、ＰＭＩＰドメインに対してシグナリングの負荷をかけずに、経路が最適化されるようにコレスポンデントノードとの通信を行えるようにするという効果を有しており、パケット交換型データ通信ネットワークのシステム（特に、ＰＭＩＰなどのネットワークベースのローカルモビリティ管理プロトコルが実装されているネットワークシステム）における通信技術分野に適用可能である。
【図面の簡単な説明】
【０２４０】
【図１】本発明の実施の形態及び従来の技術を説明するためのネットワーク構成の一例を示す図
【図２】従来の技術における課題を説明するためのネットワーク構成の第１の例を示す図
【図３】本発明の実施の形態における動作の一例を示すシーケンスチャート
【図４】本発明の実施の形態におけるＭＣｏＡ登録メッセージ（ＭＣｏＡ ＢＵメッセージ）の構造の一例を示す図
【図５】本発明の実施の形態におけるモバイルノードの好適な構成の一例を示す図
【図６】本発明の実施の形態におけるモバイルノードの好適な動作の一例を示すフローチャート
【図７】本発明の実施の形態において、グローバルプレフィックスにより構成されるグローバルアドレスが経路最適化に使用された場合のＭＮとＣＮとの間のデータパケット伝送経路の一例を模式的に示す図
【図８Ａ】本発明の実施の形態において、複数のインタフェースを有するＭＮに係るバインディングがバルク登録を利用してアップデートされる際の動作の一例を示すシーケンスチャート
【図８Ｂ】本発明の実施の形態において、複数のインタフェースを有するＭＮに係るバインディングがバルク登録を利用してアップデートされる際の動作の別の一例を示すシーケンスチャート
【図９Ａ】本発明の実施の形態を説明するためのネットワーク構成の別の一例を示す図
【図９Ｂ】本発明の実施の形態を説明するためのネットワーク構成の更に別の一例を示す図
【図１０】本発明の実施の形態を説明するためのバインディングキャッシュの一例を示す図
【図１１Ａ】従来の技術における課題を説明するためのネットワーク構成の第２の例を示す図
【図１１Ｂ】従来の技術における課題を説明するためのネットワーク構成の第３の例を示す図
【図１１Ｃ】従来の技術における課題を説明するためのネットワーク構成の第４の例を示す図
【図１１Ｄ】従来の技術における課題を説明するためのバインディングキャッシュの一例を示す図
【手続補正３】
【補正対象書類名】図面
【補正対象項目名】全図
【補正方法】変更
【補正の内容】
【図１】
2009044539.tif 000019
【図２】
2009044539.tif 000020
【図３】
2009044539.tif 000021
【図４】
2009044539.tif 000022
【図５】
2009044539.tif 000023
【図６】
2009044539.tif 000024
【図７】
2009044539.tif 000025
【図８Ａ】
2009044539.tif 000026
【図８Ｂ】
2009044539.tif 000027
【図９Ａ】
2009044539.tif 000028
【図９Ｂ】
2009044539.tif 000029
【図１０】
2009044539.tif 000030
【図１１Ａ】
2009044539.tif 000031
【図１１Ｂ】
2009044539.tif 000032
【図１１Ｃ】
2009044539.tif 000033
【図１１Ｄ】
2009044539.tif 000034
【国際調査報告】
2009044539.tif 000035
2009044539.tif 000036
2009044539.tif 000037
2009044539.tif 000038