JP5102836B2 - ネットワークノード及び移動端末 - Google Patents

Description

本発明は、インターネットプロトコル（ＩＰ：Internet Protocol）を利用した通信技術に係るネットワークノード及び移動端末に関し、特に、ネットワークベースのローカルモビリティ管理ドメイン（Network based Local Mobility Management Domain）内で移動端末（以下、モバイルノードと呼ぶこともある）が接続ポイントを変更しながら通信を行うシステムにおけるネットワークノード及び移動端末に関する。

現在、多数のデバイスが、ＩＰネットワークを使用して、相互に通信を行っている。モバイル機器にモビリティサポートを提供するために、ＩＥＴＦ（Internet Engineering Task Force）では、ＩＰｖ６におけるモビリティサポートの拡張やネットワークモビリティサポートの技術が開発されている（下記の非特許文献１、２参照）。モバイルＩＰでは、各モバイルノードは、永続的なホームドメインを持っている。モバイルノードが、自身のホームネットワークに接続している場合、モバイルノードには、ホームアドレス（ＨｏＡ：Home Address）としてプライマリグローバルアドレスが割り当てられる。一方、モバイルノードがホームネットワークから離れている場合、すなわち、他のフォーリンネットワークに接続している場合には、通常、モバイルノードには、気付アドレス（ＣｏＡ：Care-of Address）として一時的なグローバルアドレスが割り当てられる。モビリティサポートの考えは、モバイルノードが他のフォーリンネットワークに接続している場合でも、自身のホームアドレスで、そのモバイルノードまで到達可能となるようにするものである。

このような考えは、非特許文献１において、ホームエージェント（ＨＡ：Home Agent）として知られるエンティティを、ホームネットワークに導入することによって実践されている。モバイルノードは、バインディングアップデート（ＢＵ：Binding Update）メッセージを使用して、ホームエージェントへの気付アドレスの登録を行う。これにより、ホームエージェントは、モバイルノードのホームアドレスと気付アドレスとの間のバインディングを生成することが可能となる。ホームエージェントは、モバイルノードのホームアドレスに向けられたメッセージを受信（intercept）し、パケットのカプセル化（あるパケットを新たなパケットのペイロードとすることであり、パケットトンネリングとしても知られている）を用いて、そのパケットをモバイルノードの気付アドレスに転送する機能を担っている。

上述の技術によってモビリティに関する問題は解決されるものの、システム構成に起因する別の問題が生じる可能性がある。例えば、モバイルノードはホームエージェントにＢＵメッセージを送信する必要があるが、モバイルノードが高速で移動している場合には、生成されるＢＵメッセージの数が多くなる。さらに、モバイルノードからホームエージェントまでの距離が離れてしまう可能性がある。その結果、ＢＵメッセージがホームエージェントに到達するまでに時間がかかってしまい、ホームエージェントがモバイルノードの気付アドレス（アップデートされた気付アドレス）に対してパケットの転送を開始するまでの間に、モバイルノードは別の位置に移動してしまう可能性がある。例えば上述のような問題が生じることから、非特許文献２や下記の特許文献１には、ネットワークベースのローカルモビリティ管理を用いる技術が提案されている。これにより、モバイルノードは、ローカルネットワークドメイン内で接続ポイントを変更する場合には、同じアドレスを使用し続けることが可能となり、モバイルノードのホームエージェントに対して頻繁にＢＵメッセージを送信する必要がなくなる。

以下、図１を参照しながら、従来のネットワークベースのローカルモビリティ管理が行われているシステムについて説明する。なお、図１において、ＭＮ１３０は、インターネットなどのグローバル通信ネットワーク１００にアクセスするためにローカルネットワークドメイン１０２に接続しながら移動しており、例えば、グローバル通信ネットワーク１００に接続されているコレスポンデントノード（ＣＮ：correspondent node）１４０と通信を行うことが可能である。

ローカルネットワークドメイン１０２は、ＬＭＡ（ローカルモビリティアンカ：Local Mobility Anchor）１１０、複数のＭＡＧ（Mobility Access Gateway）１２０、１２２、１２４、ＡＡＡサーバとして機能するＬＳ（ローカルサーバ：Local Server）１１２を有し、ネットワークベースのローカルモビリティ管理サービスを提供することが可能である。

ＭＡＧ１２０、１２２、１２４は、ＭＮ１３０が接続を行うアクセスルータとして機能する。ＭＮ１３０はＭＡＧ１２０、１２２、１２４に接続するたびに、ＭＡＧ１２０、１２２、１２４は、まずＬＳ１１２を利用して証明情報（credential）の検証を行い、そのＭＮ１３０に対してローカルネットワークドメイン１０２のサービスを使用する認可が与えられているかを確認する。また、ＬＳ１１２は、ＭＡＧ１２０、１２２、１２４に対して、ＭＮ１３０に割り当てられるべきアドレスのプレフィックスに関する通知も行う。これにより、ＭＡＧ１２０、１２２、１２４は、ＭＮ１３０に同一のプレフィックスを通知することが可能となる。なお、本明細書では、このプレフィックス（ネットワークベースのローカルモビリティ管理を行うローカルネットワークドメイン１０２からＭＮ１３０に通知されるプレフィックス）を、ホームネットワークプレフィックスと呼ぶことにする。

同時にＭＡＧ１２０、１２２、１２４は、ＭＮ１３０に割り当てられているプレフィックス又はアドレスあてに送信されるパケットが適切なＭＡＧ（ＭＮ１３０が現在接続されているＭＡＧ）にトンネルされるように、ＬＭＡ１１０の更新を行う必要がある。この更新は、ＭＡＧ１２０、１２２、１２４がＰＢＵメッセージ（プロキシバインディングメッセージ：Proxy Binding message）をＬＭＡ１１０に送信することで、ＬＭＡ１１０がＭＮ１３０によって使用されるアドレスをＭＡＧ１２０、１２２、１２４と関連付けることにより行われる。

この技術は、プロキシモバイルＩＰ（ＰＭＩＰ：Proxy Mobile IP）と呼ばれるものである。ここでは、ＭＡＧ１２０、１２２、１２４がＭＮ１３０に代わってＢＵメッセージの送信を行い、ＬＭＡ１１０がローカルネットワークドメイン１０２において、ＭＮ１３０のホームエージェントとして機能する。このように、ＭＮ１３０が現在どのＭＡＧ１２０、１２２、１２４に接続されているかにかかわらず、ＭＮ１３０は、常に同一のホームネットワークプレフィックスを使用し、アドレスを変更する必要がない。したがって、ＭＮ１３０は、ホームエージェントに対して頻繁にＢＵメッセージを送信する必要がなくなる。

実際、ＭＮ１３０が異なるネットワークドメインに移った場合におけるアドレス到達可能性を保つ必要がない場合や、ＭＮ１３０が同一のローカルネットワークドメイン１０２内のみを移動する場合には、ＭＮ１３０は、グローバルなホームエージェントを有する必要がなく、ＢＵメッセージを送信する必要もない。

しかしながら、複数インタフェース（multiple interfaces）を有するモバイルノードにおいては、こうした単純なネットワークベースのローカルモビリティ管理の方式が、有効に動作しない可能性がある。

ここで、図１に示すＭＮ１３０が２つのインタフェースを備え、２つのＭＡＧ（ＭＡＧ１２０、１２２）と同時に接続可能であるとする。この場合、従来のＰＭＩＰでは、各ＭＡＧ１２０、１２２がＰＢＵメッセージをＬＭＡ１１０に送信することになる。一方、ＬＭＡ１１０は、ＭＮ１３０がＭＡＧ１２０からＭＡＧ１２２に接続ポイントを変更する状況と、ＭＮ１３０がＭＡＧ１２０、１２２に同時に接続している状況とを区別することができない。したがって、あるＭＮ１３０に関連したＰＢＵメッセージを受信したＬＭＡ１１０は、このＰＢＵメッセージによる更新が、あるインタフェースの接続ポイントの変更に起因するものであるのか、あるいは、あるインタフェースの接続が維持されたまま、別のインタフェースによって行われた同時接続に起因するものであるのかを明確に区別することができないという問題が生じる。

上記の問題を解決することが可能な方法の１つとして、各バインディングに割り当てられるＢＩＤ（バインディング識別子：Binding Identifier）を使用する方法が挙げられる。

例えば、ＭＮ１３０がＭＡＧ１２０に接続された場合、ＭＡＧ１２０からＬＭＡ１１０に送信されるＰＢＵメッセージには特定のＢＩＤ値（例えば『１』）が記載される。ここで、ＭＮ１３０がＭＡＧ１２０からＭＡＧ１２２に接続ポイントを変更すると、ＭＡＧ１２２からＬＭＡ１１０に送信されるＰＢＵメッセージには、上述のＭＡＧ１２０からＬＭＡ１１０に送信されたＰＢＵメッセージに含まれるＢＩＤ値と同一のＢＩＤ値『１』が記載される。この結果、接続ポイントの変更に伴って、ＭＡＧ１２０に関連するバインディングは、ＭＡＧ１２２に関連付けられるように更新される。

一方、ＭＮ１３０がＭＡＧ１２０との接続を維持したまま、別のインタフェースを用いてＭＡＧ１２２に接続する場合には、ＭＡＧ１２２からＬＭＡ１１０に送信されるＰＢＵメッセージには、上述のＭＡＧ１２０からＬＭＡ１１０に送信されたＰＢＵメッセージに含まれるＢＩＤ値とは異なるＢＩＤ値（例えば『２』）が記載される。この結果、ＭＡＧ１２０に関連するバインディングは保持されるとともに、ＭＡＧ１２２に関連付けられるバインディングも保持されるようになる。

また、上記の問題を解決することが可能な別の方法として、ＭＮ１３０が接続を切断したことを各ＭＡＧ１２０、１２２、１２４が検出する方法が挙げられる。ＭＮ１３０との接続の切断が検出されると、接続の切断を検出したＭＡＧ１２０、１２２、１２４は、登録取り消しＰＢＵメッセージを送信することで、ＬＭＡ１１０から自身のバインディングを取り除くことが可能となる。その結果、接続ポイントの変更に伴うバインディングの更新が行われる場合には、接続ポイントの変更前のバインディングが確実に消去されるようになる。

さらに、上記の問題を解決することが可能な別の方法として、例えば、下記の特許文献２や特許文献３に開示されているような、アクセスルータがネットワークエンティティに対してモバイルノードのコンテキストを格納できるようにする方法を用いて、ＭＡＧ１２０、１２２、１２４が、ＭＮ１３０に関するコンテキスト転送（コンテキストトランスファー）を実施する方法も考えられる。すなわち、この技術を用いた場合、ＭＮ１３０がローカルネットワークドメイン１０２に接続されると、そのＭＮ１３０のコンテキストが所定のネットワークエンティティ（コンテキスト格納用ノード）に保持され、その後にＭＮ１３０によって接続されたアクセスルータ（ここではＭＡＧ）は、コンテキスト格納用ノードからそのＭＮ１３０のコンテキストを検索するだけでよい。こうしたコンテキストに、適切なＢＩＤ値やシーケンスナンバーを導出するために必要となる情報が含まれていれば、ＭＡＧ１２０、１２２、１２４は、ＭＮ１３０が接続ポイントを変更したのか、別のインタフェースによって同時接続を行ったのかを区別することができるようになる。また、下記の特許文献５においても、モビリティアンカポイントを経由してコンテキストトランスファーが実行される方法が開示されている。
国際公開公報ＷＯ０３／１０７６００ 国際公開公報ＷＯ０６／０３２００３ 国際公開公報ＷＯ０６／０１７６８６ 国際公開公報ＷＯ０５／０３２１９３ 米国特許公開公報２００７／０２５４６６１ 国際公開公報ＷＯ０７／１１４６２３ 米国特許公報７０４６６４７ 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., "Proxy Mobile IPv6", Internet Engineering Task Force Draft: draft-ietf-netlmm-proxymip6-00.txt, April 2007.

しかしながら、上述のＢＩＤを使用する方法では、ＭＡＧ１２０、１２２、１２４は、ＬＳ１１２に問い合わせを行うことによって、使用すべき正しいＢＩＤ値を取得する必要がある。また、この問い合わせを受けたＬＳ１１２は、各ＭＮ１３０の接続が有効か否かのテスト（このテストに関しても何らかのシグナリングが発生）を行ってＢＩＤの有効性を確認したうえで、あるインタフェースに係る接続ポイントの変更（すなわち、あるインタフェースのハンドオーバ）が行われているのか、あるいは別のインタフェースによる同時接続なのかを判断し、その判断結果に応じた適切なＢＩＤ値を決定する必要がある。このような処理によって、ローカルネットワークドメイン１０２内に大量のシグナリングが発生したり、ＬＳ１１２が行うべき処理量が大きくなったりしてしまう可能性がある。そして、このようなＬＳ１１２に対する問い合わせが行われることによって、ＰＢＵメッセージがＬＭＡ１１０に送信される際に遅延が生じてしまう可能性がある。

また、上述のＭＮとの接続の切断をＭＡＧが検出する方法では、ルーティングの遅延により、登録取り消しＰＢＵメッセージ（以前に接続していたＭＡＧから送信されるメッセージ）が次のＰＢＵメッセージ（新たに接続したＭＡＧから送信されるメッセージ）よりもＬＭＡ１１０に遅れて到達してしまう可能性がある。例えば、ＭＮ１３０がＭＡＧ１２０からＭＡＧ１２２に接続を切り換えた場合には、ＭＡＧ１２０から送信された登録取り消しＰＢＵメッセージが、ＭＡＧ１２２から送信されたＰＢＵメッセージよりも遅れてＬＭＡ１１０に到達する可能性がある。この場合には、ＬＭＡ１１０に遅れて到達した登録取り消しＰＢＵメッセージによって、ＭＮ１３０のすべてのバインディングが削除されてしまい、ＭＮ１３０がグローバル通信ネットワーク１００に接続できない状態となってしまう可能性がある。

なお、ＰＢＵメッセージにシーケンスナンバーを使用することで、登録取り消しＰＢＵメッセージによってＭＮ１３０のすべてのバインディングが削除されてしまうという問題を解決できるかもしれない。しかしながら、この場合には、ＬＳ１１２が、各ＭＡＧ１２０、１２２、１２４で使用されるシーケンスナンバーを把握しなければならず、ＭＮ１３０が複数のＭＡＧ１２０、１２２、１２４に同時に接続されている場合には、すべてのＭＡＧ１２０、１２２、１２４で使用されるシーケンスナンバーが確実に同期するように管理しなければならない。こうした処理によって、ＬＳ１１２の処理負荷は更に大きくなってしまうことになり、より多くのシグナリングが発生してしまう可能性がある。

また、上述のコンテキストトランスファーを用いる方法においても、例えば上述のＢＩＤを使用する方法と同様に、コンテキスト格納用ノードに対する問い合わせのシグナリングが大量に発生したり、コンテキスト格納用ノードの処理負荷が増大したりするという問題が発生する。また、この場合もコンテキスト格納用ノードとの通信に時間が費やされることによって、ＭＮ１３０がＭＡＧ１２０、１２２、１２４に接続してからＰＢＵメッセージがＬＭＡ１１０に送信されるまでの間に遅延が生じてしまう可能性がある。

また、モバイルノードのインタフェースの接続を遅延させる別の問題として、認証が行われる必要がある点が挙げられる。この問題を解決するため、従来の技術においては、上記の特許文献６及び特許文献７に事前認証方法が開示されている。この事前認証方法では、ハンドオーバ後にモバイルノードが使用するアクセスキーを構成する処理が行われる。しかしながら、この技術では、次のＭＡＧへ詳細な情報が伝送されることになるため、上述の問題は依然として残ることになる。

上記の問題に鑑み、本発明は、ネットワークベースのローカルモビリティ管理が行われるネットワークにおいて、シグナリングの発生及びネットワークエンティティにおける処理負荷の増大を抑えるとともに遅延が発生しないようにしながら、複数のインタフェースを有するモバイルノード（移動端末）が、あるインタフェースに関する接続ポイントを変更した場合と、別のインタフェースを用いて同時接続を行った場合とを明確に区別できるようにすることを目的とする。

上記の目的を達成するため、本発明のネットワークノードは、移動端末の位置を管理する位置管理ノードを有し、前記移動端末に対してネットワークベースのローカルモビリティ管理サービスを提供するネットワークシステムにおいて、複数の無線通信インタフェースを有する前記移動端末が接続可能なゲートウェイとして機能するネットワークノードであって、
前記移動端末が前記ネットワークシステムへの接続を行うための接続サービスを提供する通信手段と、
前記移動端末による接続の際に前記移動端末から特定の情報を受信する情報受信手段と、
前記特定の情報に基づいて、前記移動端末による接続が、任意のインタフェースにおいて接続ポイントの変更が行われるハンドオーバによって生じたものであるか、新たに別のインタフェースを用いて接続が行われることによって生じたものであるかを判断する接続判断手段と、
前記位置管理ノードに対して前記移動端末の位置を更新するための更新情報を送信する際に、前記接続判断手段による判断結果を通知する接続判断結果通知手段とを、
有する。
この構成により、ネットワークベースのローカルモビリティ管理が行われるネットワークにおいて、シグナリングの発生及びネットワークエンティティにおける処理負荷の増大を抑えるとともに遅延が発生しないようにしながら、複数のインタフェースを有するモバイルノード（移動端末）が、あるインタフェースに関する接続ポイントを変更した場合と別のインタフェースを用いて同時接続を行った場合とを明確に区別することが可能となる。

さらに、本発明のネットワークノードは、上記の構成に加えて、前記接続判断手段において、前記移動端末による接続が新たに別のインタフェースを用いて接続が行われることによって生じたものであると判断された場合、前記移動端末による接続に対応した特定の情報を新たに生成し、前記移動端末に通知して格納させる情報生成・通知手段を有する。
この構成により、当該ネットワークシステムの任意のネットワークノードに最初に接続された時点で、移動端末に特定の情報が格納されるようにすることが可能となる。

さらに、本発明のネットワークノードは、上記の構成に加えて、前記特定の情報は、前記移動端末の複数のインタフェースのそれぞれに対応して存在する。
この構成により、移動端末の複数のインタフェースのそれぞれに対して異なる特定の情報が設定されるようになる。

さらに、本発明のネットワークノードは、上記の構成に加えて、前記特定の情報に、前記接続判断手段が前記特定の情報のみに基づいて他のネットワークノードに問い合わせを行うことなく前記判断を行えるような情報が含まれている。
この構成により、ネットワークノードは、他のネットワークノードに対して問い合わせを行う必要がなくなり、シグナリング量の低減やネットワークノードにおける処理負荷の軽減が実現される。

さらに、本発明のネットワークノードは、上記の構成に加えて、前記特定の情報に、前記移動端末のインタフェース識別子が含まれている。
この構成により、移動端末の複数のインタフェースのそれぞれに対して異なる特定の情報が設定されるようになる。

さらに、本発明のネットワークノードは、上記の構成に加えて、前記特定の情報に、前記移動端末の位置が更新される際に使用されたバインディング識別子が含まれている。
この構成により、移動端末に対して登録される複数のバインディングのそれぞれに対して異なる特定の情報が設定されるようになる。

さらに、本発明のネットワークノードは、上記の構成に加えて、前記特定の情報に、前記移動端末の位置が更新される際に使用されたシーケンスナンバーが含まれている。
この構成により、移動端末に関して行われる複数のバインディングアップデートのそれぞれに対して異なる特定の情報が設定されるようになる。

さらに、本発明のネットワークノードは、上記の構成に加えて、前記特定の情報に、前記移動端末が前記ハンドオーバ前に接続していたネットワークノードの識別情報が含まれている。
この構成により、特定の情報に基づいて、移動端末がハンドオーバ前に接続していたネットワークノードを把握することが可能となる。

さらに、本発明のネットワークノードは、上記の構成に加えて、前記識別情報によって特定される前記移動端末が前記ハンドオーバ前に接続していたネットワークノードに対して、前記接続判断手段における前記判断に必要となる情報を要求する情報要求手段を有する。
この構成により、移動端末がハンドオーバ前に接続していたネットワークノードに対してコンテキストトランスファー要求を行い、取得したコンテキストに基づく処理を行うことが可能となる。

さらに、本発明のネットワークノードは、上記の構成に加えて、前記特定の情報が、前記移動端末が接続を行う際に、レイヤ２メッセージ又はレイヤ３メッセージによって伝送されるように構成されている。
この構成により、特定の情報はレイヤ２又はレイヤ３を通じて伝送されるようになる。

さらに、本発明のネットワークノードは、上記の構成に加えて、前記特定の情報に、前記特定の情報の改ざんを検出するためのチェックサムが含まれている。
この構成により、特定の情報の不正な改ざんを防ぐことが可能となる。

さらに、本発明のネットワークノードは、上記の構成に加えて、前記特定の情報に有効期限を示す情報が含まれている。
この構成により、特定の情報を有効に使用することが可能な期間を把握できるようになる。

さらに、本発明のネットワークノードは、上記の構成に加えて、前記有効期限が過ぎた前記特定の情報又は前記有効期限が切れそうな前記特定の情報の更新を行い、前記移動端末に通知して格納させる情報更新・通知手段を有する。
この構成により、有効な特定の情報を移動端末に格納させることが可能となる。

さらに、本発明のネットワークノードは、上記の構成に加えて、前記特定の情報に基づいて、前記移動端末が、異なるオペレータによって管理されており、かつ、ローミング協定が結ばれているローカルモビリティドメイン間を移動しているか否かを判断するドメイン間接続変更判断手段を有する。
この構成により、移動端末がローカルモビリティドメイン間を移動する場合において、シグナリングの発生及びネットワークエンティティにおける処理負荷の増大を抑えるとともに遅延が発生しないようにすることが可能となる。

さらに、本発明のネットワークノードは、上記の構成に加えて、前記ドメイン間接続変更判断手段によって前記移動端末がローカルモビリティドメイン間を移動していると判断された場合に、前記移動端末が移動前に接続していたローカルモビリティドメインで保持されている情報を参照してアクセス認証を行うアクセス認証手段を有する。
この構成により、移動端末がローカルモビリティドメイン間を移動する場合において、移動前に接続していたローカルモビリティドメインにおける情報を利用することで、シグナリングの発生及びネットワークエンティティにおける処理負荷の増大を抑えるとともに遅延が発生しないようにすることが可能となる。

また、上記の目的を達成するため、本発明の移動端末は、ネットワークベースのローカルモビリティ管理サービスを提供するネットワークシステムに接続可能な移動端末であって、
前記ネットワークシステムのゲートウェイとして機能するネットワークノードに接続することが可能な複数の無線通信インタフェースと、
前記ゲートウェイに接続した場合に、前記移動端末による接続に対応した特定の情報を前記ゲートウェイから受信し、前記特定の情報を格納する情報管理手段と、
新たなゲートウェイに接続する場合に、前記情報管理手段に格納されている前記特定の情報を前記新たなゲートウェイに通知することで、前記新たなゲートウェイによって、前記移動端末による接続が、任意のインタフェースにおいて接続ポイントの変更が行われるハンドオーバによって生じたものであるか、新たに別のインタフェースを用いて接続が行われることによって生じたものであるかを判断できるようにする情報通知手段とを、
有する。
この構成により、ネットワークベースのローカルモビリティ管理が行われるネットワークにおいて、シグナリングの発生及びネットワークエンティティにおける処理負荷の増大を抑えるとともに遅延が発生しないようにしながら、複数のインタフェースを有するモバイルノード（移動端末）が、あるインタフェースに関する接続ポイントを変更した場合と、別のインタフェースを用いて同時接続を行った場合とを明確に区別することが可能となる。

さらに、本発明の移動端末は、上記の構成に加えて、前記特定の情報に、前記ネットワークノードが前記特定の情報にのみに基づいて他のネットワークノードに問い合わせを行うことなく前記判断を行えるような情報が含まれている。
この構成により、ネットワークノードは、他のネットワークノードに対して問い合わせを行う必要がなくなり、シグナリング量の低減やネットワークノードにおける処理負荷の軽減が実現される。

さらに、本発明の移動端末は、上記の構成に加えて、前記特定の情報は、前記ネットワークノードに接続する際に、レイヤ２メッセージ又はレイヤ３メッセージによって伝送されるように構成されている。
この構成により、特定の情報はレイヤ２又はレイヤ３を通じて伝送されるようになる。

さらに、本発明の移動端末は、上記の構成に加えて、前記特定の情報に有効期限を示す情報が含まれている。
この構成により、特定の情報を有効に使用することが可能な期間を把握できるようになる。

さらに、本発明の移動端末は、上記の構成に加えて、前記情報管理手段に格納されている前記特定の情報から、前記有効期限が過ぎた前記特定の情報を削除する情報削除手段を有する。
この構成により、有効期限を過ぎた特定の情報を削除することが可能となる。

さらに、本発明の移動端末は、上記の構成に加えて、前記有効期限が過ぎた前記特定の情報又は前記有効期限が切れそうな前記特定の情報の更新を前記ネットワークノードに要求する更新要求手段を有する。
この構成により、無効となった特定の情報（あるいは無効になりそうな特定の情報）を把握し、その更新を要求することが可能となる。

さらに、本発明の移動端末は、上記の構成に加えて、前記移動端末が、異なるオペレータによって管理されておりローミング協定が結ばれているローカルモビリティドメイン間を移動する。
この構成により、移動端末がローカルモビリティドメイン間を移動する場合において、シグナリングの発生及びネットワークエンティティにおける処理負荷の増大を抑えるとともに遅延が発生しないようにすることが可能となる。

本発明のネットワークノード及び移動端末は上記の構成を有しており、ネットワークベースのローカルモビリティ管理が行われるネットワークにおいて、シグナリングの発生及びネットワークエンティティにおける処理負荷の増大を抑えるとともに遅延が発生しないようにしながら、複数のインタフェースを有するモバイルノード（移動端末）が、あるインタフェースに関する接続ポイントを変更した場合と、別のインタフェースを用いて同時接続を行った場合とを明確に区別できるようにするという効果を有している。

以下、図面を参照しながら、本発明の実施の形態について説明する。

本明細書では、モバイルノードが現在接続されているＭＡＧから特定の情報（トークン）を受信して格納し、モバイルノードが新たな接続を行う際に、その特定の情報を次のＭＡＧに渡すことを可能にする方法及び装置が開示される。なお、本明細書に開示されているように、本発明に係る技術によって、ＭＡＧからＬＳ（ローカルサーバ）に送信されるシグナリングメッセージの数を低減させるとともに、ＭＡＧやＬＳにおける処理負荷を軽減させることが可能となる。

トークンは、例えばモバイルノードがネットワークベースのローカルモビリティ管理を行っているローカルネットワークドメインに最初に接続した場合に、ＭＡＧによって生成され、ＭＮに格納される。その後、ＭＮは、例えば別の接続ポイントに接続を切り換える場合（ハンドオーバを行う場合）に、単に次のＭＡＧに対してトークンを通知するだけで、ＭＡＧは、そのトークンを参照してこの接続がハンドオーバであることを把握することが可能となる。なお、このトークンには、モバイルノードに透過（transparent）なコンテンツが含まれ、すなわち、モバイルノードはこのトークンにどのような情報が含まれているのかを把握する必要はない。

以下、図２Ａを参照しながら、本発明に係るモバイルノードの好適な構成について説明する。図２Ａには、本発明の実施の形態におけるモバイルノードの好適な構成の一例が図示されている。図２Ａに図示されているモバイルノード２００は、１つ又は複数のネットワークインタフェース２１０−１〜２１０−ｎ、ルーティングモジュール２２０、アプリケーション２３０、トークンマネージャ２４０を有している。なお、ｎは正の整数であり、すなわちｎ個のネットワークインタフェースの存在を表している。また、以下では、任意のネットワークインタフェース２１０−１〜２１０−ｎを表す際に、ネットワークインタフェース２１０と記載することもある。

１つ又は複数のネットワークインタフェース２１０−１〜２１０−ｎは、モバイルノードが任意の通信媒体を介して別のノードと通信を行う際に必要なあらゆるハードウェア及びソフトウェアを包含する機能ブロックである。関連する技術分野で周知の用語を使用すると、ネットワークインタフェース２１０によって、レイヤ１（物理層）及びレイヤ２（データリンク層）の通信コンポーネント、ファームウェア、ドライバ、通信プロトコルなどが表される。なお、モバイルノード２００は、１つ又は複数のネットワークインタフェース２１０を有していてもよい。

また、ルーティングモジュール２２０は、アプリケーション２３０における適切なプログラムへのパケット出力方法や、適切なネットワークインタフェース２１０へのパケットの発送方法（モバイルノード２００外部へのパケット送信方法）を決定する処理を行う。なお、関連する技術分野で周知の用語を使用すると、ルーティングモジュール２２０によって、ＩＰｖ４（ＩＰバージョン４）やＩＰｖ６（ＩＰバージョン６）などのレイヤ３（ネットワーク層）の通信プロトコルの実装が表される。

シグナル／データパス２５０−１〜２５０−ｎによって、ルーティングモジュール２２０は、適切なネットワークインタフェース２１０−１〜２１０−ｎとの間でパケットの送受信を行うことが可能である。また同様に、シグナル／データパス２５２によって、ルーティングモジュール２２０は、アプリケーション２３０の適切なプログラムとの間でパケットの送受信を行うことが可能である。

また、アプリケーション２３０は、通信プロトコルのスタックにおけるネットワーク層の上位に存在するすべてのプロトコル及びプログラムを包含する機能ブロックである。このアプリケーション２３０には、例えばＴＣＰ（トランスポート制御プロトコル：Transmission Control Protocol）、ＳＣＴＰ（ストリーム制御トランスポートプロトコル：Stream Control Transport Protocol）、ＵＤＰ（ユーザデータグラムプロトコル：User Datagram Protocol）などのトランスポートレイヤプロトコル又はセッションレイヤプロトコルや、他のノードとの通信に必要となるプログラム及びソフトウェアなどが含まれている。なお、上述のように、シグナルパス２５２によって、ルーティングモジュール２２０とアプリケーション２３０との間でパケットが伝送される。

また、トークンマネージャ２４０は、ＭＡＧから提供されたトークンを格納・管理する機能を有している。トークンをレイヤ２で受信した場合には、受信したトークンは、ネットワークインタフェース２１０からシグナルパス２５６を通じてトークンマネージャ２４０に格納されるように構成されている。一方、トークンをレイヤ３で受信した場合には、受信したトークンは、ルーティングモジュール２２０からシグナルパス２５４を通じて、トークンマネージャ２４０に格納されるように構成されている。また、ネットワークインタフェース２１０及びルーティングモジュール２２０はそれぞれ、シグナルパス２５６及びシグナルパス２５４を通じて、トークンマネージャ２４０に格納されているトークンを読み出し、モバイルノード２００外部に送信することが可能である。

次に、図３を参照しながら、本発明に係るモバイルノードの好適な動作について説明する。図３には、本発明の実施の形態におけるモバイルノードの好適な動作の一例が図示されている。

まず、ステップＳ３１０において、モバイルノードは新たなレイヤ２接続を検出する。この新たなレイヤ２接続は、例えば、ＩＥＥＥ８０２．１１システムにおいては新たなアクセスポイントに接続しようとしているインタフェースによって検出可能であり、また、３Ｇ／４Ｇセルラ方式においては無線チャンネルが新たな通信基地局との接続を確立することで検出される。

次にステップＳ３２０において、モバイルノードは、トークンマネージャ２４０にトークンが格納されているか否かをチェックする。トークンマネージャ２４０にトークンが格納されている場合には、ステップＳ３３０において、モバイルノードはトークンをＭＡＧに送信するとともに、ＲＡ（ルータアドバタイズメント：Route Advertisement）メッセージを能動的に要請するか、あるいは受動的に待機する。一方、トークンマネージャ２４０にトークンが格納されていない場合には、ステップＳ３４０において、モバイルノードは、単にＲＡメッセージを能動的に要請するか、あるいは受動的に待機する。なお、ステップＳ３４０において、モバイルノードは、トークンマネージャ２４０にトークンが存在しないことを示す情報をＭＡＧに通知してもよい。

上述のように、モバイルノード２００のトークンマネージャ２４０に格納されたトークンの内容はモバイルノード２００にとっては透過（transparent）である。例えば、本発明の実施の形態で用いられるトークンの好適な例としては、例えば、モバイルノードを一意に識別する情報が用いられてもよく、複数のインタフェースのそれぞれを一意に識別する情報が、各インタフェースに対応して管理、格納されてもよい。具体的には、モバイルノードが参照するホームネットワークプレフィックス、ＭＡＧに接続されるモバイルノードのインタフェース識別子、バインディングを特定するバインディング識別子（ＢＩＤ：Binding Identifier）や、ハンドオーバ前に接続されていたＭＡＧの識別情報など、様々な情報を用いることが可能である。

また、図２Ｂには、本発明の実施の形態におけるＭＡＧに実装されている機能の一例が模式的に図示されている。図２Ｂに図示されているＭＡＧ２５０は、ネットワークベースのローカルモビリティ管理プロトコル（例えばＰＭＩＰ）の機能を実現するＰＭＩＰモジュール２６０に加えて、接続判断部２７０、接続判断結果通知部２８０を有している。

ＭＡＧ２５０の接続判断部２７０は、モバイルノードから通知されたトークンに基づいて、モバイルノードがハンドオーバを行っているのか、あるいは新たなインタフェースを用いた同時接続を行おうとしているのかを判断する機能を有している。この接続判断部２７０における判断は、例えばモバイルノードが接続に使用しているインタフェースを識別するインタフェース識別子と、トークンによって特定されるインタフェース識別子（トークンに含まれるインタフェース識別子）との比較によって行われる。これらの２つの情報が同一の場合には、モバイルノードは、接続ポイントの切り換えを行っている（すなわち、モバイルノードのインタフェースがハンドオーバを行っている）と判断される。一方、これらの２つの情報が異なる場合（あるいはトークンが通知されなかった場合や、トークンが存在しないことを示す情報が含まれている場合）には、モバイルノードは、これまでローカルネットワークドメインに接続されていなかったインタフェースを用いて新たな接続ポイントに接続を行おうとしていると判断される。

また、ＭＡＧ２５０の接続判断結果通知部２８０は、接続判断部２７０において決定された判断結果（すなわち、モバイルノードによる接続がハンドオーバによるものか、あるいは同時接続か）をＬＭＡに通知するための機能を有している。接続判断部２７０においてハンドオーバと判断された場合には、接続判断結果通知部２８０は、ハンドオーバによる更新が行われることを示すために、ＬＭＡに送信するＰＢＵメッセージ内にハンドオーバ前に使用されていたＢＩＤと同一のＢＩＤを挿入するように制御する。一方、同時接続の場合には、接続判断結果通知部２８０は、ＰＢＵメッセージをＬＭＡに送信する際に新たなＢＩＤを生成（又は取得）する。なお、同時接続の場合には、ＭＡＧは、従来の動作に従ってＬＳ（ローカルサーバ）に問い合わせを行うことによって、使用すべき正しいＢＩＤ値を取得してもよい。

また、トークン生成部２９０は、接続判断部２７０において同時接続の場合に、取得した新たなＢＩＤやその他の情報を用いてトークンを生成し、このトークンをモバイルノードに送信して、モバイルノードのトークンマネージャに格納させる機能を有している。

以上の機能によって、特にモバイルノードがハンドオーバを行う場合に、ＢＩＤの有効性のテストなどの処理が省略可能となり、シグナリングの低減やＬＳにおける処理負荷の軽減などが実現される。また、ＬＭＡは、ローカルサーバに更なるメッセージを送信することなく、ハンドオフのバインディングと同時接続のバインディングとを区別することが可能となる。

なお、接続の判断に関しては、ＭＡＧにおいてはモバイルノードから得られたトークンを分析することなく、ＬＭＡに対してのＰＢＵメッセージと共にトークンをそのまま転送し、ＬＭＡにおいて、接続の判断を行うことも可能である。つまり、ＭＡＧはトークンの転送機能のみを持ち、ＬＭＡが接続判断部２７０の機能を持つ構成とすることで、判断結果をＭＡＧが通知する必要がなくなり、ＬＭＡが直接使用すべき正しいＢＩＤを取得することができる。この方法によっても機能の分担が変更されるという差異があるものの、得られる効果が同等であることは明らかである。

次に、図４Ａ及び図４Ｂを参照しながら、本発明の実施の形態における具体的な例（第１の動作例）について説明する。図４Ａには、本発明の実施の形態において、モバイルノードがハンドオーバを行う場合の第１の動作例を示すシーケンスチャートが図示されており、図４Ｂには、本発明の実施の形態において、モバイルノードが同時接続を行う場合の第１の動作例を示すシーケンスチャートが図示されている。

なお、図４Ａ及び図４Ｂ共に、図１に図示されているネットワーク構成に基づく動作の一例が図示されており、図４Ａには、ＭＮ１３０がＭＡＧ１２０からＭＡＧ１２２にハンドオーバを行った場合のメッセージシーケンス、図４Ｂには、ＭＮ１３０が最初にＭＡＧ１２０及びＭＡＧ１２２と同時接続している場合のメッセージシーケンスが図示されている。

図４Ａにおいて、ＭＮ１３０は最初に、ＭＡＧ１２０へのレイヤ２接続を開始する（ステップＳ４１０）。なお、ステップＳ４１０で送信されるレイヤ２接続メッセージ（Ｌ２−接続）としては、例えばＩＥＥＥ８０２．１１に関連したフレーム、セルラネットワークに関連した信号、拡張認証プロトコル（ＥＡＰ：Extensible Authentication Protocol）開始メッセージ、ポイントトゥポイントプロトコル（ＰＰＰ：Point-to-Point Protocol）セットアップメッセージなどを用いることが可能であるが、これらに限定されるものではない。

なお、ここでは、ステップＳ４１０の接続がローカルネットワークドメイン１０２への最初の接続であり、ＭＮ１３０にはまだトークンが格納されていないとする。したがって、ステップＳ４１２において、ＭＡＧ１２０は、ＭＮ１３０の証明情報の検証を行わせるために、ＬＳ１１２にリクエストメッセージ（リクエスト）を送信する。そして、ステップＳ４１４において、ＬＳ１１２はＭＮ１３０の証明情報の検証を行った後、ＭＡＧ１２０に応答メッセージ（レスポンス）を送信する。この応答メッセージには、ＭＮ１３０に通知されるホームネットワークプレフィックス、使用すべきＢＩＤ値（例えば『１』）、その他の関連情報が含まれている。

そして、ＭＡＧ１２０は、ステップＳ４１６においてＭＮ１３０によるレイヤ２接続に対する確認メッセージ（Ｌ２−Ａｃｋ＋トークン）を送信する。なお、ＭＡＧ１２０は、例えばＬＳ１１２からの応答メッセージに含まれているＭＮ１３０に通知されるホームネットワークプレフィックス、使用すべきＢＩＤ値、その他の関連情報などに基づいてトークンを生成し、ステップＳ４１６で送信される確認メッセージにトークンを挿入する。なお、ＭＮ１３０に通知されるホームネットワークプレフィックス、使用すべきＢＩＤ値、その他の関連情報などの情報をそのままトークンとして用いることも可能であり、また、例えば、使用すべきＢＩＤ値（ここでは『１』）とホームネットワークプレフィックスとを結合した情報をトークンとして用いることも可能である。

その後、ＭＡＧ１２０は、ステップＳ４１８において、ＲＡメッセージを用いてホームネットワークプレフィックスをＭＮ１３０に通知し、ステップＳ４２０において、ＬＭＡ１１０にＰＢＵメッセージ（ＢＩＤ＝１）を送信する。これによって、ＬＭＡ１１０において、ＭＮ１３０に通知されたプレフィックスにより構成されたＭＮ１３０のアドレスが、ＭＡＧ１２０と関連付けられて管理される。

ここで、ステップＳ４３０における任意の処理の後、ＭＮ１３０は移動してＭＡＧ１２２に接続を切り換えるとする。ＭＮ１３０は、接続切り換え前にＭＡＧ１２０から受信して格納されたトークンを保持しており、ステップＳ４３２において、ＭＡＧ１２２への接続の際にこのトークンを含むレイヤ２接続メッセージ（Ｌ２−接続＋トークン）を送信する。

ＭＡＧ１２２は、このトークンから抽出された情報に基づいて、例えば、使用されるインタフェースのインタフェース識別子と、トークンに格納されているインタフェース識別子とが同一であることから、このＭＮ１３０による接続がハンドオーバによって行われたものであると推測することが可能である。また、ＭＡＧ１２２は、トークンからホームネットワークプレフィックスを抽出することも可能である。これにより、ＭＡＧ１２２は、ＬＳ１１２との間でリクエスト／レスポンス処理を繰り返し行う必要がなくなる。ＭＡＧ１２２は、ＬＳ１１２への問い合わせを行うことなく、ステップＳ４３４において、レイヤ２接続に対する確認メッセージ（Ｌ２−Ａｃｋ＋トークン）を送信するだけでよい。

そして、ＭＡＧ１２２は、ステップＳ４３６において、ＲＡメッセージを用いてホームネットワークプレフィックスをＭＮ１３０に通知し、ステップＳ４３８において、ＬＭＡ１１０にＰＢＵメッセージ（ＢＩＤ＝１）を送信する。なお、ＭＮ１３０による接続がハンドオーバによって行われたものであるので、ステップＳ４３８で送信されるＰＢＵメッセージでは、ＭＡＧ１２２は、ＭＡＧ１２０で使用されたＢＩＤ値（ステップＳ４２０で送信されるＰＢＵメッセージに含まれるＢＩＤ値）と同一のＢＩＤ値（ここでは『１』）を使用する。したがって、ステップＳ４３８でＭＡＧ１２２から送信されるＰＢＵメッセージに係るバインディングによって、ステップＳ４２０でＭＡＧ１２０から送信されたＰＢＵメッセージによって生成されたバインディングは上書きされる。

なお、ステップＳ４３４における接続の確認処理において、ＭＡＧ１２２は、新たに更新したトークンをＭＮ１３０に送信することが望ましいが、ＭＮ１３０に格納されているトークンが更新されず、ＭＮ１３０は最初にローカルネットワークドメイン１０２に接続した段階で格納されたトークンを使用し続けることも可能である。この場合、トークン内の情報が初期のものから更新されないことになるため、随時更新されるような情報をトークン内に含めることができないが、一方で、トークンの生成処理が初回接続時のみで済むため、処理負荷の低減効果がある。

また、ここでは、ＭＡＧがトークンから抽出された情報に基づいて、ハンドオーバによる接続及び同時接続のいずれであるかの判断をＭＡＧが行っているが、上述のように、ＬＭＡに接続判断機能を設け、このＬＭＡが、ＭＡＧからそのまま転送されてきたトークンに基づいて、接続の判断を行ってもよい。この場合には、ＬＭＡにおける接続の判断によって、ＬＭＡ自身が適切なＢＩＤを把握できるようになる。

一方、図４Ｂにおいては、ＭＮ１３０は、ＭＡＧ１２０に接続した後にハンドオーバを行う代わりに、ＭＡＧ１２０との接続を維持したまま、ＭＡＧ１２２と同時接続を行う。なお、ＭＡＧ１２０への最初の接続に対応するメッセージシーケンス（ステップＳ４１０〜Ｓ４２０）は、図４Ａのものと同一であり、説明を省略する。

ここで、ＭＡＧ１２０に接続した後、ＭＮ１３０は第２のインタフェースを起動して、ＭＡＧ１２２への接続を開始する。これはステップＳ４４０におけるレイヤ２接続メッセージ（Ｌ２−接続＋トークン）によって示されている。このとき、ＭＮ１３０は、ステップＳ４４０で送信される接続メッセージにトークンを挿入してＭＡＧ１２２に送信する。

ＭＡＧ１２２は、このトークンから抽出された情報に基づいて、例えば、使用されるインタフェースのインタフェース識別子と、トークンに格納されているインタフェース識別子とが異なることから、このＭＮ１３０による接続が同時接続であると推測することが可能である。また、ＭＡＧ１２２は、トークンからホームネットワークプレフィックスを抽出することも可能である。これにより、ＭＡＧ１２２は、ＬＳ１１２との間でリクエスト／レスポンス処理を繰り返し行うことなく、ＭＮ１３０による接続が同時接続であることを把握できるようになる。なお、この場合にはＭＡＧ１２２は、従来の動作に従ってＬＳ１１２に問い合わせを行い、この接続に関連したＢＩＤ値（上記のＢＩＤ値『１』とは異なる値、例えば『２』）をＬＳ１１２から取得してもよい。

そして、ＭＡＧ１２２は、ステップＳ４４２において、レイヤ２接続に対する確認メッセージ（Ｌ２−Ａｃｋ＋トークン）を送信し、ステップＳ４４４において、ＲＡメッセージを用いてホームネットワークプレフィックスをＭＮ１３０に通知する。

また、ＭＡＧ１２２は、ステップＳ４４６において、ＬＭＡ１１０にＰＢＵメッセージ（ＢＩＤ＝２）を送信する。なお、ステップＳ４４６で送信されるＰＢＵメッセージは、ＢＩＤ値『１』で特定されるインタフェースとは異なるインタフェースを用いた接続に係るバインディングに関連するものであり、ＭＡＧ１２２は、ＭＡＧ１２０で使用されたＢＩＤ値（ステップＳ４２０で送信されるＰＢＵメッセージに含まれるＢＩＤ値『１』）とは異なるＢＩＤ値『２』を使用する。したがって、ステップＳ４４６でＭＡＧ１２２から送信されるＰＢＵメッセージに係るバインディングと、ステップＳ４２０でＭＡＧ１２０から送信されたＰＢＵメッセージによって生成されたバインディングとは明確に区別可能であり、相互に上書きが行われないようにすることが可能となる。

なお、ステップＳ４４２における接続の確認処理において、ＭＡＧ１２２は、新たに更新したトークンをＭＮ１３０に送信することが望ましいが、ＭＮ１３０に格納されているトークンが更新されず、ＭＮ１３０は最初にローカルネットワークドメイン１０２に接続した段階で格納されたトークンを使用し続けることも可能である。この場合、トークン内の情報が初期のものから更新されないことになるため、随時更新されるような情報をトークン内に含めることができないが、一方で、トークンの生成処理が初回接続時のみで済むため、処理負荷の低減効果がある。

また、ここでは、ＭＡＧがトークンから抽出された情報に基づいて、ハンドオーバによる接続及び同時接続のいずれであるかの判断をＭＡＧが行っているが、上述のように、ＬＭＡに接続判断機能を設け、このＬＭＡが、ＭＡＧからそのまま転送されてきたトークンに基づいて、接続の判断を行ってもよい。この場合には、ＬＭＡにおける接続の判断によって、ＬＭＡ自身が適切なＢＩＤを把握できるようになる。

したがって、上述の本発明の実施の形態における第１の動作例によれば、ＭＡＧは、モバイルノードによる接続がハンドオーバによるものであるか（例えば図４Ａ）、あるいは、同時接続によるものであるか（例えば図４Ｂ）を確実に区別できるようになり、レイヤ２シグナリングを利用してモバイルノードとの間でトークンの格納及び読み出しを行うことによって、適切なＰＢＵメッセージをＬＭＡに送信することが可能となる。なお、この動作によって、ＬＳとのメッセージ交換処理が軽減され、本発明の目的が実現される。

図４Ａ及び図４Ｂに図示されているシーケンスチャートでは、本発明の実施の形態における第１の動作例として、ＭＡＧとモバイルノードとの間でレイヤ２シグナリングを用いてトークンが伝送される場合が図示されている。一方、別の好適な実施例として、レイヤ３シグナリングを用いてトークンを伝送させることも可能である。

以下、図５Ａ及び図５Ｂを参照しながら、本発明の実施の形態における具体的な例（第２の動作例）について説明する。図５Ａには、本発明の実施の形態において、モバイルノードがハンドオーバを行う場合の第２の動作例を示すシーケンスチャートが図示されており、図５Ｂには、本発明の実施の形態において、モバイルノードが同時接続を行う場合の第２の動作例を示すシーケンスチャートが図示されている。

図５Ａにおいて、ＭＮ１３０は最初に、ＭＡＧ１２０へのレイヤ３接続を開始する（ステップＳ５１０）。なお、ステップＳ５１０で送信されるレイヤ３接続メッセージ（ＲＳ／ＤＨＣＰＲＥＱ）としては、例えば、ルータ要請（ＲＳ：Router Solicitation）メッセージや、ＤＨＣＰ（Dynamic Host Configuration Protocol）リクエストメッセージを利用して実現可能であるが、これらのメッセージに限定されるものではない。

なお、ここでは、ステップＳ５１０の接続がローカルネットワークドメイン１０２への最初の接続であり、ＭＮ１３０にはまだトークンが格納されていないとする。したがって、ステップＳ５１２において、ＭＡＧ１２０は、ＭＮ１３０の証明情報の検証を行わせるために、ＬＳ１１２にリクエストメッセージ（リクエスト）を送信する。そして、ステップＳ５１４において、ＬＳ１１２はＭＮ１３０の証明情報の検証を行った後、ＭＡＧ１２０に応答メッセージ（レスポンス）を送信する。この応答メッセージには、ＭＮ１３０に通知されるホームネットワークプレフィックス、使用すべきＢＩＤ値（例えば『１』）、その他の関連情報が含まれている。

そして、ＭＡＧ１２０は、ステップＳ５１６においてＭＮ１３０によるレイヤ３接続に対する確認メッセージ（ＲＡ／ＤＨＣＰＯＦＦＥＲ＋トークン）を送信する。なお、ＭＡＧ１２０は、例えば、ルータアドバタイズメント（ＲＡ：Router Advertisement）メッセージや、ＤＨＣＰアドレス提供応答メッセージを利用して実現可能であるが、これらのメッセージに限定されるものではない。なお、ＭＡＧ１２０は、例えばＬＳ１１２からの応答メッセージに含まれているＭＮ１３０に通知されるホームネットワークプレフィックス、使用すべきＢＩＤ値、その他の関連情報などに基づいてトークンを生成し、ステップＳ５１６で送信される確認メッセージにトークンを挿入する。

さらに、ＭＡＧ１２０は、ステップＳ５１８において、ＰＢＵメッセージをＬＭＡ１１０に送信する。これによって、ＬＭＡ１１０において、ＭＮ１３０のアドレス（ＤＨＣＰによって割り当てられているか、あるいはＭＮ１３０に通知されたプレフィックスから構成されている）が、ＭＡＧ１２０と関連付けられて管理される。

ここで、ステップＳ５３０における任意の処理の後、ＭＮ１３０は移動してＭＡＧ１２２に接続を切り換えるとする。ＭＮ１３０は、接続切り換え前にＭＡＧ１２０から受信して格納されたトークンを保持しており、ステップＳ５３２において、ＭＡＧ１２２への接続の際にこのトークンを含むＲＳメッセージ又はＤＨＣＰリクエストメッセージ（ＲＳ／ＤＨＣＰＲＥＱ＋トークン）を送信する。

ＭＡＧ１２２は、このトークンから抽出された情報に基づいて、例えば、使用されるインタフェースのインタフェース識別子と、トークンに格納されているインタフェース識別子とが同一であることから、このＭＮ１３０による接続がハンドオーバによって行われたものであると推測することが可能である。また、ＭＡＧ１２２は、トークンからホームネットワークプレフィックスを抽出することも可能である。これにより、ＭＡＧ１２２は、ＬＳ１１２との間でリクエスト／レスポンス処理を繰り返し行う必要がなくなる。ＭＡＧ１２２は、ＬＳ１１２への問い合わせを行うことなく、ステップＳ５３６において、レイヤ３接続に対してＲＡメッセージ又はＤＨＣＰレスポンスメッセージ（ＲＡ／ＤＨＣＰＯＦＦＥＲ＋トークン）を送信するだけでよい。

また、ＭＡＧ１２２は、ステップＳ５３４において、ＬＭＡ１１０にＰＢＵメッセージ（ＢＩＤ＝１）を送信する。なお、ＭＮ１３０による接続がハンドオーバによって行われたものであるので、ステップＳ５３４で送信されるＰＢＵメッセージでは、ＭＡＧ１２２は、ＭＡＧ１２０で使用されたＢＩＤ値（ステップＳ５１８で送信されるＰＢＵメッセージに含まれるＢＩＤ値）と同一のＢＩＤ値（ここでは『１』）を使用する。したがって、ステップＳ５３４でＭＡＧ１２２から送信されるＰＢＵメッセージに係るバインディングによって、ステップＳ５１８でＭＡＧ１２０から送信されたＰＢＵメッセージによって生成されたバインディングは上書きされる。

なお、ステップＳ５３６における接続の確認処理において、ＭＡＧ１２２は、新たに更新したトークンをＭＮ１３０に送信することが望ましいが、ＭＮ１３０に格納されているトークンが更新されず、ＭＮ１３０は最初にローカルネットワークドメイン１０２に接続した段階で格納されたトークンを使用し続けることも可能である。この場合、トークン内の情報が初期のものから更新されないことになるため、随時更新されるような情報をトークン内に含めることができないが、一方で、トークンの生成処理が初回接続時のみで済むため、処理負荷の低減効果がある。

また、ここでは、ＭＡＧがトークンから抽出された情報に基づいて、ハンドオーバによる接続及び同時接続のいずれであるかの判断をＭＡＧが行っているが、上述のように、ＬＭＡに接続判断機能を設け、このＬＭＡが、ＭＡＧからそのまま転送されてきたトークンに基づいて、接続の判断を行ってもよい。この場合には、ＬＭＡにおける接続の判断によって、ＬＭＡ自身が適切なＢＩＤを把握できるようになる。

一方、図５Ｂにおいては、ＭＮ１３０は、ＭＡＧ１２０に接続した後にハンドオーバを行う代わりに、ＭＡＧ１２０との接続を維持したまま、ＭＡＧ１２２と同時接続を行う。なお、ＭＡＧ１２０への最初の接続に対応するメッセージシーケンス（ステップＳ５１０〜Ｓ５１８）は、図５Ａのものと同一であり、説明を省略する。

ここで、ＭＡＧ１２０に接続した後、ＭＮ１３０は第２のインタフェースを起動して、ＭＡＧ１２２への接続を開始する。これはステップＳ５３２におけるＲＳメッセージ又はＤＨＣＰリクエストメッセージの送信（ＲＳ／ＤＨＣＰＯＦＦＥＲ＋トークン）によって示されている。このとき、ＭＮ１３０は、ステップＳ５３２で送信されるメッセージにトークンを挿入してＭＡＧ１２２に送信する。

ＭＡＧ１２２は、このトークンから抽出された情報に基づいて、例えば、使用されるインタフェースのインタフェース識別子と、トークンに格納されているインタフェース識別子とが異なることから、このＭＮ１３０による接続が同時接続であると推測することが可能である。また、ＭＡＧ１２２は、トークンからホームネットワークプレフィックスを抽出することも可能である。これにより、ＭＡＧ１２２は、ＬＳ１１２との間でリクエスト／レスポンス処理を繰り返し行うことなく、ＭＮ１３０による接続が同時接続であることを把握できるようになる。なお、この場合にはＭＡＧ１２２は、従来の動作に従ってＬＳ１１２に問い合わせを行い、この接続に関連したＢＩＤ値（上記のＢＩＤ値『１』とは異なる値、例えば『２』）をＬＳ１１２から取得してもよい。

また単に、ＭＡＧ１２２は、ステップＳ５４４において、ＲＡメッセージ又はＤＨＣＰレスポンスメッセージ（ＲＡ／ＤＨＣＰＯＦＦＥＲ＋トークン）を送信することでＭＮ１３０に応答を行う。また、ステップＳ５４２において、ＭＡＧ１２２は、ＬＭＡ１１０にＰＢＵメッセージ（ＢＩＤ＝２）を送信する。なお、ステップＳ５４２で送信されるＰＢＵメッセージは、ＢＩＤ値『１』で特定されるインタフェースとは異なるインタフェースを用いた接続に係るバインディングに関連するものであり、ＭＡＧ１２２は、ＭＡＧ１２０で使用されたＢＩＤ値（ステップＳ５１８で送信されるＰＢＵメッセージに含まれるＢＩＤ値『１』）とは異なるＢＩＤ値『２』を使用する。したがって、ステップＳ５４２でＭＡＧ１２２から送信されるＰＢＵメッセージに係るバインディングと、ステップＳ５１８でＭＡＧ１２０から送信されたＰＢＵメッセージによって生成されたバインディングとは明確に区別可能であり、相互に上書きが行われないようにすることが可能となる。

なお、ステップＳ５４４におけるレスポンスメッセージの送信の際には、ＭＡＧ１２２は、新たに更新したトークンをＭＮ１３０に送信することが望ましいが、ＭＮ１３０に格納されているトークンが更新されず、ＭＮ１３０は最初にローカルネットワークドメイン１０２に接続した段階で格納されたトークンを使用し続けることも可能である。この場合、トークン内の情報が初期のものから更新されないことになるため随時更新されるような情報をトークン内に含めることができないが、一方で、トークンの生成処理が初回接続時のみで済むため処理負荷の低減効果がある。

また、ここでは、ＭＡＧがトークンから抽出された情報に基づいて、ハンドオーバによる接続及び同時接続のいずれであるかの判断をＭＡＧが行っているが、上述のように、ＬＭＡに接続判断機能を設け、このＬＭＡが、ＭＡＧからそのまま転送されてきたトークンに基づいて、接続の判断を行ってもよい。この場合には、ＬＭＡにおける接続の判断によって、ＬＭＡ自身が適切なＢＩＤを把握できるようになる。

したがって、上述の本発明の実施の形態における第２の動作例によれば、ＭＡＧは、モバイルノードによる接続がハンドオーバによるものであるか（例えば図５Ａ）、あるいは、同時接続によるものであるか（例えば図５Ｂ）を確実に区別できるようになり、レイヤ３シグナリングを利用してモバイルノードとの間でトークンの格納及び読み出しを行うことによって、適切なＰＢＵメッセージをＬＭＡに送信することが可能となる。なお、この動作によって、ＬＳとのメッセージ交換処理が軽減され、本発明の目的が実現される。

図４Ａ及び図４Ｂに図示されているシーケンスチャートでは、本発明の実施の形態における第１の動作例として、ＭＡＧとモバイルノードとの間でレイヤ２シグナリングを用いてトークンが伝送される場合が図示されており、図５Ａ及び図５Ｂに図示されているシーケンスチャートでは、本発明の実施の形態における第２の動作例として、ＭＡＧとモバイルノードとの間でレイヤ３シグナリングを用いてトークンが伝送される場合が図示されている。これらの実施例では、トークンに必要十分なデータが含まれており、ＭＡＧ１２２がモバイルノードのバインディングに関連する必要な情報（使用すべきＢＩＤ値や、ハンドオフか同時接続かに関する情報）をトークンから導出できることが前提となっている。

なお、当業者であれば、これ以外の他の方法を利用してトークンを伝送できることが分かるであろう。例えば、ＩＥＥＥ８０２．２１のコマンド、情報サービス、イベントサービスなどを利用することで、トークンの格納、検索、アップデートを行うことが可能である。また、トークンは、ＥＡＰ、ダイアメータ（Diameter）、ラディウス（Radius）などのＡＡＡシグナリングを利用することで、アクセス認証段階において格納することも可能である。

一方、以下の本発明の実施の形態における第３の動作例では、トークンに必要十分なデータすべてが含まれておらず、単にモバイルノードが以前に接続していたＭＡＧを示す情報のみが含まれている場合について説明する。この場合においても、ＭＡＧは、ローカルサーバとの間で余分なメッセージ交換を行うことなく、トークンを使用してハンドオーバの場合と同時接続の場合とを区別することが可能となる。

なお、本発明の実施の形態における第３の動作例では、例えばＭＡＧの識別情報のみによってトークンを構成することで、トークンのサイズが小さくなるという利点がある。これは、モバイルノードの記憶容量があまり大きくない場合（あるいは余裕がない場合）や、トークンを伝送するために使用されるシグナリングフレームが、限られたサイズのトークンしか伝送できない場合などに有効である。

以下、図６Ａ及び図６Ｂを参照しながら、本発明の実施の形態における具体的な例（第３の動作例）について説明する。図６Ａには、本発明の実施の形態において、モバイルノードがハンドオーバを行う場合の第３の動作例を示すシーケンスチャートが図示されており、図６Ｂには、本発明の実施の形態において、モバイルノードが同時接続を行う場合の第３の動作例を示すシーケンスチャートが図示されている。

なお、図４Ａ、図４Ｂ、図５Ａ、図５Ｂを参照した説明によれば、本発明はＭＡＧとモバイルノードとの間におけるトークンの交換方法（例えば、レイヤ２又はレイヤ３のメッセージを使用する方法）とは関係なく使用可能であることが分かる。される。したがって、図６Ａ及び図６Ｂにおいては、レイヤ２のメッセージ及びレイヤ３のメッセージを区別せずに、Ｌ２／Ｌ３接続という表記やＬ２／Ｌ３ａｃｋメッセージという表記などを用いることにする。なお、ここでは、レイヤ２又はレイヤ３のどちらでトークンが伝送されるかについても区別されない。

図６Ａにおいて、ＭＮ１３０は最初に、ＭＡＧ１２０への接続（Ｌ２／Ｌ３接続）を開始する（ステップＳ６１０）。なお、ここでは、ステップＳ６１０の接続がローカルネットワークドメイン１０２への最初の接続であり、ＭＮ１３０にはまだトークンが格納されていないとする。したがって、ステップＳ６１２において、ＭＡＧ１２０は、ＭＮ１３０の証明情報の検証を行わせるために、ＬＳ１１２にリクエストメッセージ（リクエスト）を送信する。そして、ステップＳ６１４において、ＬＳ１１２はＭＮ１３０の証明情報の検証を行った後、ＭＡＧ１２０に応答メッセージ（レスポンス）を送信する。この応答メッセージには、ＭＮ１３０に通知されるホームネットワークプレフィックス、使用すべきＢＩＤ値（例えば『１』）、その他の関連情報が含まれている。

そして、ＭＡ１２０は、ステップＳ６１６においてＭＮ１３０による接続に対する確認メッセージ（Ｌ２／Ｌ３Ａｃｋ＋トークン）を送信する。なお、ＭＡＧ１２０は、例えばＭＡＧ１２０の識別情報に基づいてトークンを生成し、ステップＳ６１６で送信される確認メッセージにトークンを挿入する。この場合、トークンによって、ＭＡＧ１２０がＭＮ１３０のアクセスルータであることが特定可能となる。

さらに、ＭＡＧ１２０は、ステップＳ６１８において、ＰＢＵメッセージをＬＭＡ１１０に送信する。これによって、ＬＭＡ１１０において、ＭＮ１３０のアドレス（ＤＨＣＰによって割り当てられているか、あるいはＭＮ１３０に通知されたプレフィックスから構成されている）がＭＡＧ１２０に関連付けられる。

ここで、ステップＳ６３０における任意の処理の後、ＭＮ１３０は移動してＭＡＧ１２２に接続を切り換えるとする。ＭＮ１３０は、接続切り換え前にＭＡＧ１２０から受信して格納されたトークンを保持しており、ステップＳ６３２において、ＭＡＧ１２２への接続の際にこのトークンをＭＡＧ１２２へ送信する。

ＭＡＧ１２２は、このトークンから抽出された情報に基づいて、ＭＮ１３０がＭＡＧ１２０に接続されていた旨を把握することが可能である。そして、ステップＳ６３４において、ＭＡＧ１２２は、トークンから特定されたＭＡＧ１２０に対してコンテキストリクエストメッセージ（コンテキストリクエスト）を送信する。

このコンテキストリクエストメッセージによって、ＭＡＧ１２２からＭＡＧ１２０に対して、ＭＮ１３０がＭＡＧ１２０に接続した際に使用されていたＢＩＤ値やホームネットワークプレフィックス、インタフェース識別子などに関する情報を提供するように要求が行われる。そして、こうした情報は、ステップＳ６３６において、コンテキストメッセージ（コンテキスト）によってＭＡＧ１２０からＭＡＧ１２２に送信される。

ＭＡＧ１２２は、コンテキストメッセージに含まれている情報に基づいて、例えば、使用されるインタフェースのインタフェース識別子と、トークンに格納されているインタフェース識別子とが同一であることから、このＭＮ１３０による接続がハンドオーバによって行われたものであると推測することが可能である。したがって、ローカルネットワークドメイン１０２全体を管理するＬＳ１１２との間でリクエスト／レスポンス処理を繰り返す代わりに、ＭＡＧ１２２は、ＭＮ１３０がハンドオーバ前に接続されていたＭＡＧ１２０にコンテキストを要求し、コンテキストを取得することが可能となる。

そして、ＭＡＧ１２２は、ステップＳ６４０においてレスポンスメッセージ（Ｌ２／Ｌ３Ａｃｋ＋トークン）を送信することでＭＮ１３０の接続に対する応答を行い、ステップＳ６３８において、ＬＭＡ１１０にＰＢＵメッセージ（ＢＩＤ＝１）を送信する。

なお、ＭＮ１３０による接続がハンドオーバによって行われたものであるので、ステップＳ６３８で送信されるＰＢＵメッセージでは、ＭＡＧ１２２は、ＭＡＧ１２０で使用されたＢＩＤ値（ステップＳ６１８で送信されるＰＢＵメッセージに含まれるＢＩＤ値）と同一のＢＩＤ値（ここでは『１』）を使用する。したがって、ステップＳ６３８でＭＡＧ１２２から送信されるＰＢＵメッセージに係るバインディングによって、ステップＳ６１８でＭＡＧ１２０から送信されたＰＢＵメッセージによって生成されたバインディングは上書きされる。

なお、ステップＳ６４０における接続の確認処理において、ＭＡＧ１２２は、新たに更新したトークンをＭＮ１３０に送信することが望ましいが、ＭＮ１３０に格納されているトークンが更新されず、ＭＮ１３０は最初にローカルネットワークドメイン１０２に接続した段階で格納されたトークンを使用し続けることも可能である。この場合、トークン内の情報が初期のものから更新されないことになるため、随時更新されるような情報をトークン内に含めることができないが、一方で、トークンの生成処理が初回接続時のみで済むため、処理負荷の低減効果がある。さらに、この場合、コンテキストを要求する対象（コンテキストリクエストの送信先）は初期接続のＭＡＧ（ＭＡＧ１２０）固定となり、本実施の形態のコンテキストリクエスト及びレスポンスに関する動作例はこの変更に基づいて読み替える必要があるが、得られる効果が損なわれていないことは明白である。

また、ここでは、ＭＡＧがトークンから抽出された情報に基づいて、ハンドオーバによる接続及び同時接続のいずれであるかの判断をＭＡＧが行っているが、上述のように、ＬＭＡに接続判断機能を設け、このＬＭＡが、ＭＡＧからそのまま転送されてきたトークンに基づいて、接続の判断を行ってもよい。この場合には、ＬＭＡにおける接続の判断によって、ＬＭＡ自身が適切なＢＩＤを把握できるようになる。

一方、図６Ｂにおいては、ＭＮ１３０は、ＭＡＧ１２０に接続した後にハンドオーバを行う代わりに、ＭＡＧ１２０との接続を維持したまま、ＭＡＧ１２２と同時接続を行う。なお、ＭＡＧ１２０への最初の接続に対応するメッセージシーケンス（ステップＳ６１０〜Ｓ６１８）は、図６Ａのものと同一であり、説明を省略する。

ここで、ＭＡＧ１２０に接続した後、ＭＮ１３０は第２のインタフェースを起動して、ＭＡＧ１２２への接続を開始する。このとき、ＭＮ１３０は、接続切り換え前にＭＡＧ１２０によって格納されたトークンを保持しているので、ステップＳ６５２におけるメッセージ（Ｌ２／Ｌ３接続＋トークン）の送信によるＭＡＧ１２２への接続の際に、このトークンをＭＡＧ１２２に転送する。

ＭＡＧ１２２は、このトークンから抽出された情報に基づいて、ＭＮ１３０がＭＡＧ１２０に接続されていたことを特定する。その結果、ステップＳ６５４において、ＭＡＧ１２２はコンテキストリクエストメッセージ（コンテキストリクエスト）をＭＡＧ１２０に送信する。これによって、ＭＡＧ１２２からＭＡＧ１２０に対して、ＭＮ１３０がＭＡＧ１２０に接続した際に使用されていたＢＩＤ値やホームネットワークプレフィックス、インタフェース識別子などに関する情報を提供するように要求が行われる。そして、こうした情報は、ステップＳ６５６において、コンテキストメッセージ（コンテキスト）によってＭＡＧ１２０からＭＡＧ１２２に送られる。

ＭＡＧ１２２は、コンテキストメッセージに含まれている情報に基づいて、例えば、使用されるインタフェースのインタフェース識別子と、トークンに格納されているインタフェース識別子とが異なっていることから、このＭＮ１３０による接続が同時接続によって行われたものであると推測することが可能である。したがって、ローカルネットワークドメイン１０２全体を管理するＬＳ１１２との間でリクエスト／レスポンス処理を繰り返す代わりに、ＭＡＧ１２２は、ＭＮ１３０がハンドオーバ前に接続されていたＭＡＧ１２０にコンテキストを要求し、コンテキストを取得することが可能となる。

そして、ＭＡＧ１２２は、ステップＳ６６０においてレスポンスメッセージ（Ｌ２／Ｌ３Ａｃｋ＋トークン）を送信することでＭＮ１３０の接続に対する応答を行い、ステップＳ６５８において、ＬＭＡ１１０にＰＢＵメッセージ（ＢＩＤ＝２）を送信する。なお、ステップＳ６３８で送信されるＰＢＵメッセージは、ＢＩＤ値『１』で特定されるインタフェースとは異なるインタフェースを用いた接続に係るバインディングに関連するものであり、ＭＡＧ１２２は、ＭＡＧ１２０で使用されたＢＩＤ値（ステップＳ６１８で送信されるＰＢＵメッセージに含まれるＢＩＤ値『１』）とは異なるＢＩＤ値『２』を使用する。したがって、ステップＳ６３８でＭＡＧ１２２から送信されるＰＢＵメッセージに係るバインディングと、ステップＳ６１８でＭＡＧ１２０から送信されたＰＢＵメッセージによって生成されたバインディングとは明確に区別可能であり、相互に上書きが行われないようにすることが可能となる。

なお、ステップＳ６６０におけるレスポンスメッセージの送信の際には、ＭＡＧ１２２は、新たに更新したトークンをＭＮ１３０に送信することが望ましいが、ＭＮ１３０に格納されているトークンが更新されず、ＭＮ１３０は最初にローカルネットワークドメイン１０２に接続した段階で格納されたトークンを使用し続けることも可能である。この場合、トークン内の情報が初期のものから更新されないことになるため、随時更新されるような情報をトークン内に含めることができないが、一方で、トークンの生成処理が初回接続時のみで済むため、処理負荷の低減効果がある。さらに、この場合、コンテキストを要求する対象（コンテキストリクエストの送信先）は初期接続のＭＡＧ（ＭＡＧ１２０）固定となり、本実施の形態のコンテキストリクエスト及びレスポンスに関する動作例はこの変更に基づいて読み替える必要があるが、得られる効果が損なわれていないことは明白である。

また、ここでは、ＭＡＧがトークンから抽出された情報に基づいて、ハンドオーバによる接続及び同時接続のいずれであるかの判断をＭＡＧが行っているが、上述のように、ＬＭＡに接続判断機能を設け、このＬＭＡが、ＭＡＧからそのまま転送されてきたトークンに基づいて、接続の判断を行ってもよい。この場合には、ＬＭＡにおける接続の判断によって、ＬＭＡ自身が適切なＢＩＤを把握できるようになる。

したがって、上述の本発明の実施の形態における第２の動作例によれば、ＭＡＧは、モバイルノードによる接続がハンドオーバによるものであるか（例えば図５Ａ）、あるいは、同時接続によるものであるか（例えば図５Ｂ）を確実に区別できるようになり、モバイルノードとの間でトークンの格納及び読み出しを行うことによって、適切なＰＢＵメッセージをＬＭＡに送信することが可能となる。なお、この動作は、ローカルサーバとの間でメッセージ交換を行うことなく、モバイルノードがハンドオーバ前に接続されていたＭＡＧに対してコンテキストを要求することによって実現されるので、ＬＳの処理負荷が緩和されるとともに遅延が少なくなり、本発明の目的が実現される。

上述のように、トークンとして様々な種類の情報を利用することが可能である。最も簡単な例においては、トークンには、モバイルノードが現在接続されているＭＡＧの識別情報のみが含まれる。これによって、トークンを受信するＭＡＧが、そのトークンによって特定されるＭＡＧに対して、コンテキストトランスファーに関する問い合わせ（要求）を行うことが可能となる。トークンを受信したＭＡＧは、コンテキストトランスファーによって取得した情報に基づいて、モバイルノードが同時接続を行っているか、あるいはハンドオーバを行っているかを推測することが可能となる。

例えば、トークンによって特定されたＭＡＧは、このＭＡＧへの接続の際にモバイルノードが使用していたインタフェース識別子をコンテキストトランスファーによって転送することが可能である。トークンを受信したＭＡＧは、コンテキストトランスファーに含まれているインタフェース識別子と、トークンを受信したＭＡＧへの接続においてモバイルノードが使用するインタフェース識別子とを比較して、このモバイルノードによる接続がハンドオーバによるものか同時接続によるものかを区別することが可能となる。また、トークンを受信したＭＡＧは、コンテキストトランスファーによって取得した情報に基づいて、このモバイルノードに関するＰＢＵメッセージにおいて使用するＢＩＤ値を決定することも可能となる。

また、別の好適な態様として、例えば、使用されるインタフェース識別子、ＢＩＤ値、ＰＢＵメッセージに使用されるシーケンスナンバーなどの情報がトークンに含まれるようにしてもよい。これによって、トークンを受信するＭＡＧは、トークンを参照することで必要な情報を取得できるようになり、モバイルノードがハンドオーバ前に接続されていたＭＡＧからのコンテキスト転送を取得する必要がなくなる。

なお、トークンには異なる種類の内容が含まれる可能性があるので、例えば、トークンの構造として、タイプレングス値（ＴＬＶ：type-length-value）フォーマットを用いることが望ましい。この場合、トークンは複数の異なるブロックを有し、複数のブロックのそれぞれにはタイプフィールド、長さフィールド、値フィールドが含まれる。

タイプフィールドには、例えば、ハンドオーバ前のＭＡＧの識別情報、インタフェース識別子、ハンドオーバ前に使用されていたシーケンスナンバー、ハンドオーバ前に使用されていたＢＩＤ値など、値フィールドに挿入される情報の種類が示される。また、長さフィールドにはブロックのサイズ（ビット数又はオクテット数）が示される。また、値フィールドには実際の値（上述のような情報）が含まれる。この構造によって、トークンはフレキシブルかつ拡張可能なフォーマットとなり、各システムにおいて、トークン内に格納すべき最適な情報の種類を選択できるようになる。

なお、トークンはモバイルノード内に格納され、ＭＡＧによって使用されるので、悪意あるモバイルノードによるトークンの改ざんを避けるために何らかの予防措置が取られることが望ましい。例えば、暗号化によって生成されたチェックサムを用いて、ＭＡＧがトークンの完全性を保護することが望ましい。このトークンの保護は様々な方法によって実現可能である。

例えば、各ＭＡＧが１組の秘密鍵及び公開鍵を所有する方法によって、トークンを保護することが可能となる。ＭＡＧがトークンを生成する際には、ＭＡＧはそのトークン用にチェックサムの生成も行い、秘密鍵を用いてチェックサムを暗号化する。そして、この暗号化されたチェックサム（従来の技術における暗号化署名情報に相当）がトークンに挿入される。

一方、公開鍵は、同一のローカルネットワークドメインに存在するすべてのＭＡＧが把握可能である。トークンを生成したＭＡＧはトークンによって特定可能であり、他のＭＡＧはトークンを生成したＭＡＧの公開鍵を把握しているので、他のＭＡＧは、この署名を復号し、復号されたチェックサムと、トークンから独自に算出されたチェックサムとの比較を行う。トークンが第３者によって改変されていない場合には、これら２つのトークンは同一となり、このような検証が行われることによって、トークンの完全性が保たれる。

また、モバイルノードは格納されるトークンの内容を把握する必要がない場合は、トークンを生成したＭＡＧがトークン全体をその秘密鍵によって暗号化することも可能である。これにより、モバイルノードはトークンの内容を改ざんすることはもちろん、トークンの内容を参照する（復号する）ことさえも不可能となる。なお、通常、ネットワークベースのローカルモビリティ管理ドメインは、しっかりと管理されているネットワークなので、同一のローカルネットワークドメインに存在するすべてのＭＡＧは同一の暗復号鍵を容易に使用することが可能である。

また、第３者にトークンを盗まれ、その盗まれたトークンがローカルネットワークドメイン内の他のＭＡＧに提示されないようにするため、トークンが格納されるモバイルノードのネットワークアクセス識別子（ＮＡＩ：network access identifier）がトークンに含まれるようにしてもよい。これにより、トークンがＭＡＧに提示される際に、ＭＡＧはモバイルノードのネットワークアクセス識別子がトークンに記載されているものと一致するか否かをチェックすることが可能となる。ネットワークアクセス識別子が一致しない場合には、ＭＡＧは、単にそのトークンを破棄すればよく、この場合には、トークンが提示されなかった場合と同様の動作が行われる。

また、トークンが、例えばＰＢＵメッセージで使用されるシーケンスナンバーなどの情報を伝達するために使用される場合には、トークン自体に何らかの有効期限が記載され、その有効期限が満了した時点でトークンが無効となるようにすることが望ましい。これにより、期限が切れた古い情報に基づいてＭＡＧが動作を行ってしまうことを回避することが可能となる。

例えば、第１のＭＡＧはトークンを生成して、トークンに使用するシーケンスナンバーの最後の値を５００にしたとする。このトークンは第２のＭＡＧに渡され、シーケンスナンバーが５００であることが確認される。次に、第２のＭＡＧは、より大きなシーケンスナンバー（例えば、６００）を使用する。このシーケンスナンバーは、第１のＭＡＧが使用するシーケンスナンバーが超えることがない程度に十分大きいことが望ましい。しかしながら、このトークンが非常に長い時間モバイルノードによって格納された場合には、第２のＭＡＧがトークンを受信するまでの間に、シーケンスナンバー６００を超えた値を使用してしまう可能性がある。したがって、トークンに関連するライフタイム値により、第２のＭＡＧが、古い情報に基づいて動作を行わないようにすることが可能となる。

さらに、ライフタイムの満了を利用することで、悪意あるモバイルノードが、以前に格納したトークンを使用すること（従来の技術におけるリプレイアタック）ができないようにしてもよい。さらに、モバイルノードがトークンのライフタイム値を精査できるようにして、自身のメモリから期限切れのトークンを削除できるようにしたり、古いトークンの期限が満了しそうな場合又は既に満了してしまった場合に、ＭＡＧに対して古いトークンを上書きするための新たなトークンを要求できるようにしたりすることも可能である。なお、ＭＡＧは、モバイルノードから要求されなくても、古いトークンの期限が満了しそうな場合又は既に満了してしまった場合には、古いトークンを上書きするための新たなトークンを生成することが可能である。

また、図７には、本発明の実施の形態におけるモバイルノードに格納されるトークンに含まれる内容の一例が図示されている。ここで、ＭＮ１３０は、ＭＡＧ１２０とのＩＥＥＥ８０２．１１無線接続（第１の接続）と、ＭＡＧ１２２とのセルラ３ＧＰＰ接続（第２の接続）の２つの接続（同時接続）を有していると仮定する。図７には、このＭＮ１３０に係るトークンの一例が図示されている。

このトークンには１０個の異なるＴＬＶブロックが含まれている。

ブロック７１０には、タイプフィールド７１２（ＭＮ−ＩＤ）及び値フィールド７１６（ＭＮ１３０）に示されているように、ＭＮ１３０のネットワークアクセス識別子が格納されている。

また、ブロック７２０には、タイプフィールド７２２（インタフェースＩＤ）及び値フィールド７２６（ｅｔｈ０）に示されているように、ＭＮ１３０の第１のインタフェースの識別子が格納される。なお、ここでは、ＩＥＥＥ８０２．１１インタフェースを識別するインタフェース識別子（ｅｔｈ０）が格納される。

また、ブロック７３０は、タイプフィールド７３２（ＢＩＤ）及び値フィールド７３６（１）に示されているように、第１のインタフェースで使用されるバインディング識別子が格納される。なお、ここでは、ＢＩＤ値『１』が格納される。

また、ブロック７４０は、タイプフィールド７４２（ＭＡＧ−ＩＤ）及び値フィールド７４６（ＭＡＧ１２０）に示されているように、第１のインタフェースが接続されているＭＡＧ１２０の識別情報（ＭＡＧ１２０を識別する値）が格納される。

また、ブロック７５０は、タイプフィールド７５２（シーケンスナンバー）及び値フィールド（２７９１２）に示されているように、第１のインタフェースで使用されるシーケンスナンバーが格納される。なお、ここでは、シーケンスナンバー『２７９１２』が格納される。

また、ブロック７６０は、タイプフィールド７６２（インタフェースＩＤ）及び値フィールド（３ｇｐｐ１）７６６に示されているように、ＭＮ１３０の第２のインタフェースの識別子が格納される。なお、ここでは、セルラインタフェースを識別するインタフェース識別子（３ｇｐｐ１）が格納される。

また、ブロック７７０は、タイプフィールド７７２（ＢＩＤ）及び値フィールド７７６（２）に示されているように、第２のインタフェースで使用されるバインディング識別子が格納される。なお、ここでは、ＢＩＤ値『２』が格納される。

また、ブロック７８０は、タイプフィールド７８２及び値フィールド７８６に示されているように、第２のインタフェースが接続されているＭＡＧの識別情報（ＭＡＧ１２２を識別する情報）が格納される。

また、ブロック７９０は、タイプフィールド７９２（シーケンスナンバー）及び値フィールド７９６（２９０４２）に示されているように、第２のインタフェースで使用されるシーケンスナンバーが格納される。なお、ここでは、シーケンスナンバー『２９０４２』が格納される。

また、ブロック７１００は、タイプフィールド７１０２（チェックサム）及び値フィールド７１０６（０ｘｆｅ３２７ａｂ９２ｃｄ７８０ａ９１）で示されており、トークンに関する暗号化チェックサムが含まれる。

なお、図７に図示されている例のように、トークンは、同一モバイルノードの複数インタフェースに関する情報を保持することが可能である。ＭＡＧは、トークンを受信すると、モバイルノードが接続に使用していたインタフェースに関連する情報のみを抽出することが可能である。

図７に図示されている例を用いて、ＭＮ１３０がセルラインタフェースを用いてＭＡＧ１２４に接続される場合を仮定する。ＭＡＧ１２４は、トークンを受信すると、セルラインタフェース（すなわち、３ｇｐｐ１）に関連する情報（ブロック７６０、７７０、７８０、７９０）を抽出することが可能である。ＭＡＧ１２４は、こうして取得したトークンから、使用すべきＢＩＤ値（すなわち『２』）と、使用すべき最小シーケンスナンバー（すなわち『２９４０２』）を決定することが可能である。そして、ＭＡＧ１２４は、これらのブロック内の値を更新し、更新されたトークンをＭＮ１３０に戻して格納させる。

また、図７に図示されている例では、ローカルネットワークドメイン１０２全体において各モバイルノードあたりそれぞれ１つのトークンが用いられる場合が示されているが、これに限定されるものではない。例えば、モバイルノードのインタフェースごとに１つのトークンが格納されるようにすることも可能である。この場合、図７に図示されている例を用いると、ＭＮ１３０に格納される異なるトークンが２つ存在し得る。

第１のトークンは第１のインタフェース（すなわち『ｅｔｈ０』）に関連しており、第１のトークンには、ブロック７１０、７２０、７３０、７４０、７５０、７１００が含まれる。第２のトークンは第２のインタフェース(すなわち『３ｇｐｐ１』）に関連しており、第２のトークンには、ブロック７１０、７６０、７７０、７８０、７９０、７１００が含まれる。ＭＮ１３０が第２のインタフェースをＭＡＧ１２２からＭＡＧ１２４に切り換えた場合には、ＭＮ１３０は、第２のインタフェースに関するトークンをＭＡＧ１２４に渡すだけでよい。

なお、図７に図示されているトークンは一例に過ぎず、実際のシステムにおいては、トークンには、より多くの情報が含まれていてもよく、あるいは最低限の情報のみが含まれていてもよい。例えば、トークンのライフタイム値を格納するブロックや、モバイルノードに割り当てられたホームネットワークプレフィックスを格納する別のブロックが含まれていてもよい。また、例えば、シーケンスナンバーのブロック７５０、７９０が存在しなくてもよい。

また、例えば、モバイルノードに割り当てられたアドレスにトークン自体が埋め込まれるようにしてもよい。なお、ＩＰｖ６アドレスは１２８ビットであり、ネットワークプレフィックス部は通常６４ビットである。すなわち、モバイルノードを識別するために６４ビット（ホスト識別子部）が残されている。また、各モバイルノードに対してユニークなプレフィックスが使用される場合には、ホスト識別子部はホストの識別に使用される必要はない。この実施の形態によれば、ＭＡＧは、ホスト識別子部として使用可能なトークンを生成することが可能である。

アドレスに埋め込まれるこのようなトークンは、モバイルノードに関連する情報を圧縮した形式であってもよく、あるいは、次のＭＡＧがモバイルノードに関する実際のプロファイルを容易に取得できるようにするために用いられるインデックスとして使用されてもよい。例えば、モバイルノードのアドレスは、トークンを作成するＭＡＧを識別できるものであってもよい。これにより、続いて接続されるＭＡＧはこのＭＡＧ（トークンによって識別されるＭＡＧ）と通信を行って、モバイルノードのプロファイルを直接取得することが可能となる。これによって、他の形式のトークンを受け取れない可能性があるレガシノードと互換性を保つことができるという利点がある。

なお、特許文献４には、サービスネットワーク外部において一時的なトークンが生成され、モバイルノードがそのトークンを使用して、無線アクセスネットワークに認証されるようにする技術が開示されている。

一方、本発明では、ＬＳ１１２がモバイルノードのアクセスを認可した後に、ローカルネットワークドメイン１０２が、一時的な認証用の証明情報を生成することが可能である。この証明情報はＭＡＧに渡され、ＭＡＧは、モバイルノードに格納されているトークンに証明情報を組み入れることが可能である。その後、モバイルノードが同一ローカルネットワークドメイン１０２に存在する別のＭＡＧに接続した場合には、別のＭＡＧは、トークンに格納された一時的な証明情報をチェックすることによって、モバイルノードの真正性について検証を行うことが可能である。これにより、検証のために、モバイルノードの証明情報がローカルサーバ１１２に再度送信される必要はなくなる。

なお、本発明は、少なくとも下記の３つの態様において、特許文献４に開示されている技術とは大きく異なっている。

第１に、本発明における証明情報は、ローカルネットワークドメインで生成されるものであり、サービスネットワーク外部で生成されるものではない。
第２に、本発明では、証明情報は、ローカルサーバによって先に行われた認証成功の結果に基づいて生成されるものであり、任意に生成されるものではない。
第３に、特許文献４に開示されている技術は迅速な認証の実現や認証による遅延の防止を目的としているのに対し、本発明は、シグナリングの低減や、あるネットワークエンティティに集中し得る処理負荷の軽減などを目的としている。

また、上述の本発明の実施の形態では、ネットワークベースのローカルモビリティ管理プロトコルを実装している単一ローカルドメインネットワークにおいて本発明が用いられ、その結果、ＭＡＧ及びＬＭＡがＭＮのハンドオーバ又は同時接続を区別することが可能となる方法が開示されているが、別の効果を実現するための本発明に係る技術を適用することも可能である。

例えば、本発明に係る技術は、ＭＡＧが毎回（ＭＡＧが接続を変更するたびに）セントラルサーバを参照することなく、モバイルノードに関する情報を取得することが可能なメカニズムとして使用可能である。モバイルノードに割り当てられるホームネットワークプレフィックスなどのモバイルノードに関する情報はトークン内に格納され、モバイルノードは、その後に接続するＭＡＧにこのトークンを渡すことが可能である。これは特に、３Ｇセルラ無線通信ネットワークなどのように、大規模なネットワークベースのローカルモビリティ管理ドメインが配置される場合に有用である。

こうした大規模なネットワークでは、例えば何百万人もの加入者が存在する場合がある。モバイルノードのハンドオーバが起こるたびにＭＡＧがセントラルサーバに問い合わせを行った場合には、セントラルサーバの処理負荷は過剰となる。セントラルサーバは膨大なデータベースから関連データを検索する必要があり、その処理は更に遅くなる。

一方、本発明によれば、各ＭＡＧ同士が情報を交換するメカニズムが実現される。モバイルノードに格納されたトークンを使用することで、ＭＡＧは、何らかのブロードキャスト手段を使用して他のＭＡＧの探索を行う必要がなくなる。モバイルノードがローカルネットワークドメインの任意のＭＡＧに最初に接続する場合のみ、ＭＡＧはセントラルローカルサーバから情報を読み出す必要がある。その後、こうした情報は、モバイルノードに格納されているトークンを介して、ＭＡＧ間で交換（伝搬）される。

また、ＭＡＧ間におけるトークンの伝達を更に拡張して、あるローカルネットワークドメインから別のローカルネットワークドメインにトークンが渡されるようにすることも可能である。以下、図８を参照しながら、ローカルドメインネットワーク間でトークンが渡される一例について説明する。図８には、本発明の実施の形態において、ローカルドメインネットワーク間でトークンが渡される場合を説明するための通信システムの一例が図示されている。図８には、２つのローカルネットワークドメイン１０２、８０２が図示されている。ローカルネットワークドメイン１０２は、ＬＭＡ１１０、ＬＳ１１２、ＭＡＧ１２０、１２２、１２４により構成されている。また、ローカルネットワークドメイン８０２は、ＬＭＡ８１０、ＬＳ８１２、ＭＡＧ８２０、８２２により構成されている。２つのローカルネットワークネットワークドメイン１０２、８０２は、グローバル通信ネットワーク（例えば、インターネット）１００に接続されており、ＣＮ１４０はグローバル通信ネットワーク１００に接続してＭＮ１３０と通信を行っている。

この図８に示す通信システムにおいて、ＭＮ１３０がローカルネットワークドメイン１０２内から移動を開始して、ＭＡＧ１２０に接続したと仮定する。本発明の上述の実施の形態で説明したように、ＭＡＧ１２０はトークンを生成し、ＭＮ１３０に格納させる。さらに、ＭＡＧ１２０は、ＭＮ１３０へ割り当てられたアドレスに関して、ＬＭＡ１１０へプロキシバインディングアップデートを送信する。次に、ＭＮ１３０がローカルネットワークドメイン１０２を離れて、ローカルネットワークドメイン８０２内のＭＡＧ８２０へ接続すると、ＭＮ１３０は、ＭＡＧ８２０と接続している間にこのトークンをＭＡＧ８２０へ渡すことができるようになる。ＭＡＧ８２０は、このトークンを参照することで、ＭＮ１３０が別のローカルモビリティドメインから移動してきたことが判断できるようになる。なお、トークンには、このトークンを生成したＭＡＧが属するローカルモビリティドメイン（あるいは、そのローカルモビリティドメイン内の特定のエンティティ）を識別するための情報が挿入されていることが望ましい。この結果、２つの主要な効果が実現可能となる。

第１の主要な効果は、ローカルネットワークドメイン８０２がローカルネットワークドメイン１０２とローミング協定を有している場合に、ＭＮ１３０に格納されるトークンによってＭＮ１３０のアイデンティティ（すなわち、本当にＭＮ１３０であること）が証明できるようになることである。これにより、認証処理の簡素化を実現することが可能となる。例えば、トークンによってローカルネットワークドメイン１０２におけるＬＳ１１２が特定されるとする。その結果、ＭＡＧ８２０は、ローカルネットワークドメイン８０２のＬＳ８１２を中継することなく、ＬＳ１１２と直接通信してアクセス認証を行うことが可能となる。また、ローカルネットワークドメイン８０２のＬＳ８１２を中継する場合であっても、ローカルネットワークドメイン１０２におけるＬＳ１１２が特定されているため、アクセス認証に関する問い合わせ先がその問い合わせをＬＳ１１２へ即座に転送できるようになる。

第２の主要な効果は、２つのローカルネットワークドメイン１０２、８０２間のローミング協定で許されるのであれば、ＭＮ１３０に格納されるトークンによって、ローカルネットワークドメイン１０２のＬＭＡ１１０が識別可能となることである。これにより、ＭＡＧ８２０は、プロキシバインディングアップデートをＬＭＡ１１０へ送信することができるようになり、ＭＮ１３０は、ローカルネットワークドメイン１０２から取得したアドレスを使用し続けることが可能となる。この結果、ＣＮ１４０がＭＮ１３０へパケットを送信した場合には、ＬＭＡ１１０はこのパケットをＭＡＧ８２０へ転送し、ＭＡＧ８２０はＭＮ１３０へパケットを転送することが可能となる。また、ＰＭＩＰの多段化構成（ＬＭＡが別のＬＭＡに対してＭＡＧのように動作し、プロキシバインディングアップデートを送信することでＰＭＩＰによるトンネルが多段（チェイン）に設定される構成）を行う場合は、ＬＭＡ８１０は、プロキシバインディングアップデートを即座にＬＭＡ１１０へ送信することができるようになり、ＭＮ１３０は、ローカルネットワークドメイン１０２から取得したアドレスを使用し続けることが可能となる。この結果、ＣＮ１４０がＭＮ１３０へパケットを送信した場合には、ＬＭＡ１１０はこのパケットをＬＭＡ８１０経由でＭＡＧ８２０へ転送し、ＭＡＧ８２０はＭＮ１３０へパケットを転送することが可能となる。

これは、特に３Ｇシナリオに関連している。３Ｇシナリオでは、ＬＭＡ１１０がローカルネットワークドメイン（３ＧＰＰネットワーク）１０２のＰＤＮＧＷ（Packet Data Network Gateway）として機能し、ＭＡＧ８２０がローカルネットワークドメイン（３ＧＰＰネットワーク）８０２のｅＰＤＧ（evolved Packet Data Gateway）として機能する。３Ｇネットワークでは、適切な信頼関係が得られる場合には、外部ネットワークに属するｅＰＤＧはモバイルノードに関するシグナリングをホームＰＤＮＧＷと直接実行することが可能である。このような信頼関係を確認するために、モバイルノード内に格納されているトークンが使用されてもよい。なお、上述の３Ｇシナリオにおけるネットワーク構成は一例であり、例えば、ＭＡＧに相当するノードとして、端末との接続点に相当するゲートウェイ（Serving Gateway, Access Gateway, PDG: Packet Data Gatewayなど）や多段化構成においては中継点になるＰＤＮＧＷが考えられる。

また、ＭＡＧ８２０は、同一ローカルネットワークドメイン８０２内のＬＭＡ８１０へトークン情報を転送することが可能である。このとき、ＬＭＡ８１０は、トークンからＬＭＡ１１０を特定し、さらに、ＬＭＡ１１０からＭＮ１３０へ割り当てられたアドレスを検索する。なお、このアドレスは、トークン自体から取得可能であってもよく、あるいは、ＬＭＡ８１０がＬＭＡ１１０経由で取得してもよい。これにより、ＭＮ１３０に同一アドレスを割り当てることが可能となり、ＭＡＧ８２０は、このＭＮ１３０のアドレスをＭＡＧ８２０自身のアドレスと関連付けてＬＭＡ８１０へ登録する。そして、ＬＭＡ８１０はＬＭＡ１１０へバインディング情報を送信し、これにより、ＣＮ１４０がＭＮ１３０へパケットを送信した場合には、ＬＭＡ８１０が、このパケットをＭＡＧ８２０経由でＭＮ１３０へ転送することが可能となる。

上記の第１の主要な効果に係る方法は、ＬＭＡ１１０とＭＮ１３０との間においてパケット転送を行うノード数を低減させるという利点（すなわち、迅速なパケット配送を実現するという利点）を有している。一方、上記の第２の主要な効果に係る方法では、ＭＮ１３０がＭＡＧ８２０からＭＡＧ８２２へ接続ポイントを変更した場合にＬＭＡ１１０に通知が行われる必要がない。したがって、上記の第２の主要な効果に係る方法は、２つのローカルネットワークドメイン１０２、８０２間で、シグナリングパケットの伝送量を低減させるという利点を有している。

３Ｇシナリオでは、モバイルノードは、異なる目的に応じて異なるトークンを取得する必要があるかもしれない。例えば、ＭＮ１３０がローカルネットワークドメイン８０２へ移動する際、ＭＮ１３０は、ローカルネットワークドメイン８０２から新しいトークンを取得してもよい。一方、ＭＮ１３０は、ローカルネットワークドメイン１０２で取得した以前のトークンを保持し続けることを望んでもよい。ＭＮ１３０は、この以前のトークンを使用して、ＭＮ１３０がローカルネットワークドメイン１０２に接続されている間に確立された以前の接続を維持してもよい。なお、新しいトークンは、例えばローカルブレイクアウト（ホームネットワークを介さずに、移動先のネットワークから直接的にグローバル通信ネットワークなどへアクセスする方法の１つ）などのような別の目的で使用されてもよい。

上述のように、本発明は、ハンドオーバと複数の同時ハンドオーバとの違いを示すことに加えて、移動端末の移動をサポートするという別の目的で使用可能である。以下、２つの実施例Ａ、Ｂについて説明する。

まず、図９Ａに示されるネットワーク構成を参照しながら、実施例Ａについて説明する。図９Ａには、本発明の実施の形態において、移動端末の移動をサポートする実施例Ａを説明するための通信システムの一例が図示されている。図９Ａには、ＬＭＡ９１０、ＬＳ９１２、２つのＭＡＧ９２０、９２４を有するローカルモビリティドメイン９００が図示されている。

ＭＮ９３０は、ローカルエリアネットワーク９００内を移動し、アクセスネットワーク９０２を通じてＭＡＧ９２０へ接続するか、あるいは、アクセスネットワーク９０４を通じてＭＡＧ９２４へ接続する。なお、アクセスネットワーク９０２、９０４は、３Ｇセルラ、ＷｉＭＡＸ、無線ＬＡＮなどのアクセス技術に関して同一であってもよく、異なっていてもよい。

本発明の実施の形態における実施例Ａでは、事前認証が行われる。図９Ｂには、本発明の実施の形態において、移動端末の移動をサポートする実施例Ａを説明するためのシーケンスチャートが図示されている。図９Ｂにおいて、ＭＮ９３０は、まず、アクセスネットワーク９０２経由でＭＡＧ９２０へ接続する。これは、ステップＳ９５０におけるＬ２接続シグナリング（Ｌ２−接続）の送信によって示されている。ＭＡＧ９２０は、このＬ２接続シグナリングを受信すると、ステップＳ９５２において、認証リクエストによってＬＳ９１２へ問い合わせる。ＬＳ９１２はＭＮ９３０の信頼性を検証すると、認証レスポンス９３０で応答を行う。なお、ステップＳ９５４で送信される認証レスポンスには、ＭＡＧ９２０がＭＮ９３０とのセキュリティ関係を確立するための鍵が含まれていてもよい。そして、ステップＳ９５６において、ＭＡＧ９２０はＭＮ９３０の接続に対してトークンを含む確認メッセージ（Ｌ２−Ａｃｋ＋トークン）によって応答を行う。これにより、ＭＡＧ９２０は、ＭＮ９３０にトークンを格納させることが可能となる。以上の処理によって、レイヤ２接続は完了し、ＭＡＧ９２０は、ステップＳ９５８においてルータ通知メッセージをＭＮ９３０へ通知することが可能となる。

ステップＳ９６０においてある期間だけ経過した後、ＭＮ９３０は、第２のインタフェースを起動してアクセスネットワーク９０４経由でＭＡＧ９２４へ接続するか、あるいは、ＭＡＧ９２４へハンドオーバを行うかを決定するかもしれない。この動作は、ステップＳ９６２におけるＬ２接続シグナリング（Ｌ２−接続＋トークン）の送信によって示されている。なお、ＭＮ９３０は、事前に取得したトークンをＭＡＧ９２４へ転送することが可能である。このトークンによって、ＭＡＧ９２４は、ＬＳ９１２と認証リクエスト／レスポンス処理を行う必要なく、ＭＮ９３０との間で新たなセキュリティ関係を築くことができるようになる。ＭＡＧ９２４は、ステップＳ９６４においてシグナリングで接続を直接確認し、ステップＳ９６６においてＲＡ（ルータ通知：Router Advertisement）を通知することができるようになる。なお、ステップＳ９６４における通知（Ｌ２−接続＋トークン）によって、新たなトークン又は更新されたトークンがＭＮ９３０に格納されてもよい。

本発明の実施の形態における実施例Ｂでは、別のインタフェースを用いて認証が行われる。このような場合としては、例えば、アクセスネットワーク９０２経由で第１インタフェースがＭＡＧ９２０へ接続されており、アクセスネットワーク９０４経由で第２インタフェースがＭＡＧ９２４へ接続されている場合などのように、モバイルノードが２つのインタフェースを持っている場合が挙げられる。モバイルノードは、消費電力を節約するために第１インタフェースをスリープモードにしながら、第１インタフェースの接続対象であるアクセスネットワーク９０２の情報を検索したり、アクセスネットワーク９０２に関連するパラメータ（例えば、ページングのセットアップやフローフィルタコントロールなど）を構成したりする場合もあり得る。従来の技術を用いた場合には、モバイルノードは、第１インタフェースを起動し、その第１インタフェースを用いて構成や情報検索を実行する必要がある。

一方、本発明では、図９Ｃのメッセージシーケンスチャートに図示されているように、第１インタフェースを起動する必要はない。図９Ｃには、本発明の実施の形態において、移動端末が複数のインタフェースを有する場合における実施例Ｂを説明するためのシーケンスチャートが図示されている。

図９Ｃにおいて、第１インタフェースがまだアクティブな間（すなわち、第１インタフェースがＭＡＧ９２０と接続している間）、ステップＳ９８０において、ＭＡＧ９２０はトークンをＭＮ９３０に格納させる。このトークンは、ＭＮ９３０がＭＡＧ９２０に接続されている場合にＭＡＧ９２０によって生成されるトークンであってもよく、あるいは、第１インタフェースをスリープモードに移行するための準備としてＭＮ９３０がＭＡＧ９２０へリクエストしたトークンであってもよい。ＭＮ９３０は、第１インタフェースがスリープモードになる前に、ステップＳ９８２におけるシグナリングメッセージ（構成パラメータ）の送信に示されているように、第１インタフェースを使用して、情報を読み出したり、アクセスネットワーク９０２上におけるパラメータを構成したりすることが可能である。

ステップＳ９９０において第１インタフェースがスリープモードになった後は、ＭＮ９３０は、第２インタフェースを用いて、情報を読み出したり、アクセスネットワーク９０２上におけるパラメータを構成したりすることが可能である。これは、ステップＳ９９２においてＭＮ９３０からＭＡＧ９２４へ送信されるシグナリングメッセージ（構成パラメータ＋トークン）によって示されている。この動作が行われるようにするため、ＭＮ９３０は、ＭＡＧ９２０によって格納されたトークンを第２インタフェース経由でＭＡＧ９２４へ送信する。ＭＡＧ９２４は、このトークンによって、ＭＮ９３０がアクセスネットワーク９０２の情報の検索を行う権限を有しており、ＭＡＧ９２４に対して動作を行うよう指示していることを確認できるようになる。なお、この動作は、ステップＳ９９４におけるシグナリングメッセージ（構成パラメータ）の送信によって示されており、すなわち、ＭＡＧ９２４は、ＭＮ９３０の第２インタフェースから受信した情報に基づいて、ＭＡＧ９２０から情報を読み出したり、ＭＡＧ９２０に関するパラメータを構成したりすることが可能である。また、ＭＡＧ９２０が検証を行うことも可能である。この場合、ＭＡＧ９２４は、ステップＳ９９２においてＭＮ９３０から送信されたシグナリングメッセージによって動作リクエスト及びトークンを受信すると、ステップＳ９９４におけるシグナリングメッセージの送信によってトークンをＭＡＧ９２０へ転送する。

なお、上述の実施の形態では、トークンがＭＡＧによって生成される場合について説明したが、当業者であれば、本発明はこの場合に限定されないことが分かるであろう。トークンはローカルネットワークドメイン内の任意のエンティティ（例えば、ＬＭＡやローカルサーバ）によって生成され、ＭＡＧ経由でモバイルノードに渡されてもよい。また、３Ｇネットワークの場合には、モバイルノードが非信頼アクセスネットワーク（例えば無線ＬＡＮ）経由で接続するような特別な場合が生じる可能性がある。この場合には、モバイルノードは、ポイントツーポイントのカプセル化トンネルを使って、ｅＰＤＧに接続し、トークンがｅＰＤＧ経由でトンネルを通じてモバイルノードに渡されてもよい。また、トークンは、ＭＡＧ経由でモバイルノードに渡されなくてもよい。例えば、モバイルノードがローカルネットワークドメインに最初に接続した際に、トークンがＡＡＡサーバによって生成され、認証／認可処理の間にモバイルノードに渡されて格納されるようにすることも可能である。

また、ｅＰＤＧのシナリオでは、複数のインタフェースを使用するモバイルノードが同一のｅＰＤＧと１つ以上の接続を有する状況が起こり得る。例えば、ある接続が、無線ＬＡＮを経由するｅＰＤＧへのポイントツーポイントのトンネルであり、別の接続が、同一のｅＰＤＧによってコントロールされている別のアクセスネットワーク（非信頼状態のＷｉＭＡＸや異なる非信頼無線ＬＡＮなど）を経由する場合があり得る。このような場合には、生成されたトークンが再使用されてもよい（同一のｅＰＤＧが特定されるので)。また、２つのインタフェースのそれぞれに関連するプロファイルが、同一のトークンに関連付けられていてもよい。

また、上述の実施の形態では、接続時にＭＡＧがモバイルノードにトークンを格納する場合について説明したが、別の好適な実施の形態において、ＭＡＧは、モバイルノードからリクエストされた場合にトークンを生成し、モバイルノードに格納することも可能である。例えば、モバイルノードは、モバイルノードのインタフェースの１つにおいてハンドオーバが行われることが検出された場合に、トークンを要求するリクエストを行う。このとき、モバイルノードは、ハンドオーバ前に、インタフェースが現在接続されているＭＡＧに対して、モバイルノードが効率良くハンドオーバを行えるようにするためのトークンを生成するようリクエストする。

また、別の例として、モバイルノードは、別のインタフェースが同一のローカルネットワークドメインに接続されるように動作させてもよい。なお、モバイルノードは、例えばＩＥＥＥ８０２．２１情報サービスや事前に設定された情報などによって、同一のローカルネットワークドメインを把握することが可能である。モバイルノードは、この新たなインタフェースで使用するためのトークンの生成を依頼することが可能である。また、モバイルノードが現在接続しているローカルネットワークドメインが３ＧＰＰネットワークである場合には、モバイルノードはローカルブレイクアウトの目的で使用されるトークン（例えば、ＩＰマルチメディアサービスのために使用されるトークン）をリクエストしてもよい。

以上のように、トークンは様々な異なる目的のために生成可能である。したがって、モバイルノードは、１つのインタフェースに関連して複数のトークンを同時に格納してもよい。例えば、あるトークンは、ハンドオーバのために使用され、あるトークンはローカルブレイクアウトのために使用され、あるトークンは、ローカルブレイクアウトのアドレスを用いた経路最適化のために使用されてもよい。これらのトークンはすべて、図２Ａに図示されているトークンマネージャ２４０によって管理される。また、トークンマネージャ２４０は、これらのトークンをそれぞれインデックス化してもよい。これにより、様々な基準に基づいて適切なトークンが読み出されて、アクセスネットワークへ渡されるようになる。このような基準としては、例えば、トークンの目的（用途）、モバイルノードが通信している現在のピアアドレス、通信の現在のセッションタイプ（ＩＰマルチメディアサービスや通常のボイスコールなど）、その他の関連する設定などが挙げられる。

なお、本明細書では、本発明が最も実用的かつ好適な実施例となるように考慮されて図示及び説明されているが、当業者であれば、上述の各ノードの構成要素に係る設計やパラメータの詳細において、発明の範囲から逸脱しない程度に様々な変更が行われてもよいことは明白である。

例えば、本発明に係るモバイルノード（移動端末）は、ローカルドメインネットワーク内を移動するモバイルルータ及びモバイルホストの両方を含むものである。また、ＭＡＧがモバイル（移動可能）であってもよい。また、上記の例ではトークンにＴＬＶ構造が使用されているが、トークンは情報を格納するために任意のフォーマットを有することが可能であり、例えば事前に定義された構造（例えば、ＸＭＬ（eXtensible Mark-up Language）フォーマット）などを用いてもよい。

また、上述の実施の形態において、複数のインタフェースを用いて複数のＭＡＧに同時接続する場合に、第１のインタフェースと第２のインタフェースでそれぞれトークンを保持することも可能である。この場合は、第２のインタフェースの初期起動時の動作がトークンを持たない状態から開始する（第１のインタフェースでのトークンは持っているがこれを第２のインタフェースでは使用しないため）ことになり、それぞれのインタフェースごとに初期接続時のトークンを取得する。そして、以降は同一のローカルネットワークドメインに接続している限り、それぞれのインタフェースごとにトークンは維持／更新される。このときも、インタフェース識別子、ＢＩＤ値の差異により、モバイルノードの接続がハンドオーバによるものか、あるいは、同時接続によるものかを確実に区別できるという目的は達成され、モバイルノードの固有の識別子やＬＳなどからの情報により、それが同一のモバイルノードの接続であることが判定できる。

また、上述の実施の形態において、複数のインタフェースを用いて複数のＭＡＧに同時接続する場合に、第２のインタフェースが第１のインタフェースと同じＭＡＧに接続することも考えられる。この場合も、図面上の第２のＭＡＧが第１のＭＡＧと同じノードであると考えることで問題なく動作できることは明白である。また、本発明の説明において、ネットワーク構成を図１に示す簡単な構成を挙げて示したが、ローカルネットワークドメインの構成は、複数オペレータ間のローミング関係も含めて多岐にわたることが考えられる。例えば、ＭＡＧはモバイルノードのアクセスルータであるとして説明しているが、他にも、ＭＡＧが異なるアクセスネットワーク（ローミングを含む）との境界ルータであり、モバイルノードは一旦その異なるアクセスネットワークに接続した後、そのアクセスネットワークを介して境界ルータであるＭＡＧに接続するという構成も考えられる。この場合も、様々なパラメータやＭＡＧへの到達手順、ＭＡＧ、ＬＳ、ＬＭＡの通信手順が異なるが、本発明のトークンの授受に関しては同様に適用できることは明白である。

また、本明細書では、モバイルノードのネットワークインタフェースが複数であることを前提に説明を行っている部分があるが、本発明を実施するうえでの論理的なインタフェースが複数あればよい。例えば、１つの無線部を複数の接続方式で共用し、ネットワークインタフェースの観点からはその変化が問題にならない程度の速度で切り替えたり、レイヤ２で論理的なリンクを維持したりすることにより、ネットワーク部からは複数のインタフェースを介してネットワークに接続している場合と同等に動作できるよう構成されていてもよい。

また、モバイルノードは複数の通信デバイスから構成されるものであってもよく、例えばパーソナルコンピュータなどの電子計算機に外挿型あるいは組み込み型の３ＧＰＰ通信用デバイスモジュールや非３ＧＰＰ通信デバイスモジュールを装着する場合などがあり、こうした多様なモバイルノードにおいても本発明は同等の効果を有するものである。

また、本明細書では、モバイルノードが送受信部を介して基地局と無線通信を行うことを前提に説明を行っているが、モバイルノードが基地局相当のアクセスポイントと有線通信を行うものであってもよく、アクセスポイントへの接続において同等の効果を有するものである。

また、上記の本発明の実施の形態の説明で用いた各機能ブロックは、典型的には集積回路であるＬＳＩ（Large Scale Integration）として実現される。これらは個別に１チップ化されてもよいし、一部又はすべてを含むように１チップ化されてもよい。なお、ここでは、ＬＳＩとしたが、集積度の違いにより、ＩＣ（Integrated Circuit）、システムＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。

また、集積回路化の手法はＬＳＩに限るものではなく、専用回路又は汎用プロセッサで実現してもよい。ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Field Programmable Gate Array）や、ＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサを利用してもよい。

さらには、半導体技術の進歩又は派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。例えば、バイオ技術の適応などが可能性としてあり得る。

本発明のネットワークノード及び移動端末は、ネットワークベースのローカルモビリティ管理が行われるネットワークにおいて、シグナリングの発生及びネットワークエンティティにおける処理負荷の増大を抑えるとともに遅延が発生しないようにしながら、複数のインタフェースを有するモバイルノード（移動端末）が、あるインタフェースに関する接続ポイントを変更した場合と、別のインタフェースを用いて同時接続を行った場合とを明確に区別できるようにするという効果を有しており、パケット交換型データ通信ネットワークのシステム（特に、ネットワークベースのローカルモビリティ管理プロトコルが実装されているネットワークシステム）における通信技術分野に適用可能である。

本発明の実施の形態及び従来の技術におけるネットワークベースのローカルモビリティ管理システムを説明するためのネットワーク構成の一例を示す図 本発明の実施の形態におけるモバイルノードの好適な構成の一例を示す図 本発明の実施の形態におけるＭＡＧに実装されている機能の一例を模式的に示す図 本発明の実施の形態におけるモバイルノードの好適な動作の一例を示すフローチャート 本発明の実施の形態において、モバイルノードがハンドオーバを行う場合の第１の動作例を示すシーケンスチャート 本発明の実施の形態において、モバイルノードが同時接続を行う場合の第１の動作例を示すシーケンスチャート 本発明の実施の形態において、モバイルノードがハンドオーバを行う場合の第２の動作例を示すシーケンスチャート 本発明の実施の形態において、モバイルノードが同時接続を行う場合の第２の動作例を示すシーケンスチャート 本発明の実施の形態において、モバイルノードがハンドオーバを行う場合の第３の動作例を示すシーケンスチャート 本発明の実施の形態において、モバイルノードが同時接続を行う場合の第３の動作例を示すシーケンスチャート 本発明の実施の形態におけるモバイルノードに格納されるトークンに含まれる内容の一例を示す図 本発明の実施の形態において、ローカルドメインネットワーク間でトークンが渡される場合を説明するための通信システムの一例を示す図 本発明の実施の形態において、移動端末の移動をサポートする実施例Ａを説明するための通信システムの一例を示す図 本発明の実施の形態において、移動端末の移動をサポートする実施例Ａを説明するためのシーケンスチャート 本発明の実施の形態において、移動端末が複数のインタフェースを有する場合における実施例Ｂを説明するためのシーケンスチャート

Claims (22)

1. 移動端末の位置を管理する位置管理ノードを有し、前記移動端末に対してネットワークベースのローカルモビリティ管理サービスを提供するネットワークシステムにおいて、複数の無線通信インタフェースを有する前記移動端末が接続可能なゲートウェイとして機能するネットワークノードであって、
   前記移動端末が前記ネットワークシステムへの接続を行うための接続サービスを提供する通信手段と、
   前記移動端末による接続の際に前記移動端末から特定の情報を受信する情報受信手段と、
   前記特定の情報に基づいて、前記移動端末による接続が、任意のインタフェースにおいて接続ポイントの変更が行われるハンドオーバによって生じたものであるか、新たに別のインタフェースを用いて接続が行われることによって生じたものであるかを判断する接続判断手段と、
   前記位置管理ノードに対して前記移動端末の位置を更新するための更新情報を送信する際に、前記接続判断手段による判断結果を通知する接続判断結果通知手段とを、
   有するネットワークノード。
2. 前記接続判断手段において、前記移動端末による接続が新たに別のインタフェースを用いて接続が行われることによって生じたものであると判断された場合、前記移動端末による接続に対応した特定の情報を新たに生成し、前記移動端末に通知して格納させる情報生成・通知手段を有する請求項１に記載のネットワークノード。
3. 前記特定の情報は、前記移動端末の複数のインタフェースのそれぞれに対応して存在する請求項１に記載のネットワークノード。
4. 前記特定の情報に、前記接続判断手段が前記特定の情報にのみに基づいて他のネットワークノードに問い合わせを行うことなく前記判断を行えるような情報が含まれている請求項１に記載のネットワークノード。
5. 前記特定の情報に、前記移動端末のインタフェース識別子が含まれている請求項３に記載のネットワークノード。
6. 前記特定の情報に、前記移動端末の位置が更新される際に使用されたバインディング識別子が含まれている請求項３に記載のネットワークノード。
7. 前記特定の情報に、前記移動端末の位置が更新される際に使用されたシーケンスナンバーが含まれている請求項３に記載のネットワークノード。
8. 前記特定の情報に、前記移動端末が前記ハンドオーバ前に接続していたネットワークノードの識別情報が含まれている請求項１に記載のネットワークノード。
9. 前記識別情報によって特定される前記移動端末が前記ハンドオーバ前に接続していたネットワークノードに対して、前記接続判断手段における前記判断に必要となる情報を要求する情報要求手段を有する請求項８に記載のネットワークノード。
10. 前記特定の情報が、前記移動端末が接続を行う際に、レイヤ２メッセージ又はレイヤ３メッセージによって伝送されるように構成されている請求項１に記載のネットワークノード。
11. 前記特定の情報に、前記特定の情報の改ざんを検出するためのチェックサムが含まれている請求項１に記載のネットワークノード。
12. 前記特定の情報に、有効期限を示す情報が含まれている請求項１に記載のネットワークノード。
13. 前記有効期限が過ぎた前記特定の情報又は前記有効期限が切れそうな前記特定の情報の更新を行い、前記移動端末に通知して格納させる情報更新・通知手段を有する請求項１２に記載のネットワークノード。
14. 前記特定の情報に基づいて、前記移動端末が、異なるオペレータによって管理されており、かつ、ローミング協定が結ばれているローカルモビリティドメイン間を移動しているか否かを判断するドメイン間接続変更判断手段を有する請求項１に記載のネットワークノード。
15. 前記ドメイン間接続変更判断手段によって前記移動端末がローカルモビリティドメイン間を移動していると判断された場合に、前記移動端末が移動前に接続していたローカルモビリティドメインで保持されている情報を参照してアクセス認証を行うアクセス認証手段を有する請求項１４に記載のネットワークノード。
16. ネットワークベースのローカルモビリティ管理サービスを提供するネットワークシステムに接続可能な移動端末であって、
    前記ネットワークシステムのゲートウェイとして機能するネットワークノードに接続することが可能な複数の無線通信インタフェースと、
    前記ゲートウェイに接続した場合に、前記移動端末による接続に対応した特定の情報を前記ゲートウェイから受信し、前記特定の情報を格納する情報管理手段と、
    新たなゲートウェイに接続する場合に、前記情報管理手段に格納されている前記特定の情報を前記新たなゲートウェイに通知することで、前記新たなゲートウェイによって、前記移動端末による接続が、任意のインタフェースにおいて接続ポイントの変更が行われるハンドオーバによって生じたものであるか、新たに別のインタフェースを用いて接続が行われることによって生じたものであるかを判断できるようにする情報通知手段とを、
    有する移動端末。
17. 前記特定の情報に、前記ネットワークノードが前記特定の情報のみに基づいて他のネットワークノードに問い合わせを行うことなく前記判断を行えるような情報が含まれている請求項１６に記載の移動端末。
18. 前記特定の情報は、前記ネットワークノードに接続する際に、レイヤ２メッセージ又はレイヤ３メッセージによって伝送されるように構成されている請求項１６に記載の移動端末。
19. 前記特定の情報に有効期限を示す情報が含まれている請求項１６に記載の移動端末。
20. 前記情報管理手段に格納されている前記特定の情報から、前記有効期限が過ぎた前記特定の情報を削除する情報削除手段を有する請求項１９に記載の移動端末。
21. 前記有効期限が過ぎた前記特定の情報又は前記有効期限が切れそうな前記特定の情報の更新を前記ネットワークノードに要求する更新要求手段を有する請求項１９に記載の移動端末。
22. 前記移動端末が、異なるオペレータによって管理されておりローミング協定が結ばれているローカルモビリティドメイン間を移動する請求項１６に記載の移動端末。

Images