JP2010512702A - モバイル・ノードの他ネットワーク領域へのハンドオーバ時のローカル・モビリティ・アンカーのリロケーションおよびルート最適化 - Google Patents

Abstract

本発明は、異なるネットワークに移動するが同じＩＰアドレスを維持するモバイル・ノードのモビリティを管理するための方法に関する。ＭＮの代わりにプロキシＭＩＰエージェントによってルート最適化を実行することが提案され、それによって、ネットワークベース・モビリティを可能にしながら、データ経路を短くする。通信相手ノードとのセッション・セットアップ時に、ホーム・ネットワーク内のＰＣＣシステムは、通信セッションに対してルート最適化が実行されることになるか否かを決定する。ＭＮが新しいネットワーク領域に接続した場合、ＰＭＩＰａは、ルート最適化に関する決定と、ＭＮおよびＣＮのアドレスとを含むルート最適化に関する関連情報を、ホーム・ネットワーク内のＰＣＣシステムに要求する。従って、ルート最適化は、ＭＩＰｖ６に従ってリターン・ルータビリティ手順を使用し、それによって、ＭＮのＩＰアドレスをホーム・アドレスとして、およびＰＭＩＰａのアドレスをＭＮの気付けアドレスとして適用することにより実行される。
【選択図】 図４

Description

本発明は、フォーリン・ネットワーク内のプロキシ・モバイルＩＰエージェントはモバイル・ノードに対するルート最適化を実行するが、モビリティおよびルート最適化は依然としてモバイル・ノードに対してトランスペアレントであるハンドオーバ手順に関する。さらに、本発明は、また、最適化されたルートをセットアップするために、ハンドオーバ手順に関与するローカル・モビリティ・アンカー並びにポリシー制御および課金システムにも関する。

通信システムは、インターネット・プロトコル（ＩＰ）ベース・ネットワークの方向にますます進化している。それらは、通常、多くの相互接続されたネットワークからなり、ネットワーク内では、音声およびデータが、いわゆるパケットと呼ばれる部片単位で端末間を伝送される。ＩＰパケットは、ルータによってコネクションレス方法で宛先にルーティングされる。従って、パケットはＩＰヘッダおよびペイロード情報を備え、それによってヘッダは、とりわけ、ソースおよび宛先ＩＰアドレスを備える。

スケーラビリティの都合上、ＩＰネットワークは階層型アドレス指定方式を使用する。従ってＩＰアドレスは、対応する端末を識別するだけでなく、さらにこの端末に関する位置情報も含む。ルーティング・プロトコルによって提供される追加の情報によって、ネットワーク内のルータは、特定の宛先に向かって次のルータを識別することができる。

端末は、電源がオンになると、アクセス・ネットワークのＩＰアドレス・プレフィクスに基づいてＩＰアドレスを構成する。端末がモバイル、いわゆるモバイル・ノード（ＭＮ）であり、異なるＩＰプレフィクス・アドレスを伴うサブネット間を移動する場合は、階層型アドレス指定方式により、そのＩＰアドレスをトポロジー的に正しいアドレスに変更しなければならない。しかし、ＴＣＰ接続などの高位層での接続は、通信ノードのＩＰアドレス（およびポート）で定義されるため、例えば、移動などによってノードのうちの１つがそのＩＰアドレスを変更すると、アクティブＩＰセッションへの接続は切断される。

ＭＩＰｖ６とも示されるモバイルＩＰｖ６（ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇで入手可能であり、参照により本明細書に組み込むものとする、Ｄ．Ｊｏｈｎｓｏｎ、Ｃ．Ｐｅｒｋｉｎｓ、Ｊ．Ａｒｋｋｏの、「Ｍｏｂｉｌｉｔｙ Ｓｕｐｐｏｒｔ ｉｎ ＩＰｖ６」、ＩＥＴＦ ＲＦＣ ３７７５、２００４年６月を参照のこと）は、モバイル・ノードが、高位層およびアプリケーションに対してトランスペアレントに、すなわち高位層接続を切断せずに、サブネット間を移動できるようにするＩＰベースのモビリティ・プロトコルである。すなわちモバイル・ノードは、ＩＰｖ６インターネット・ネットワーク内を動き回る間、連絡可能な状態を維持する。ＭＩＰｖ６の主な原理は、モバイル・ノードは、インターネット内のそのトポロジー的位置にかかわらず、そのホーム・アドレス（ＨｏＡ）によって常時識別される一方で、モバイル・ノードの気付けアドレス（ＣｏＡ）は、モバイル・ノードの現在のトポロジー的位置に関する情報を提供することである。

より詳細には、モバイル・ノードは、気付けアドレスおよびホーム・アドレスという２つのＩＰアドレスを有する。モバイル・ノードの高位層は、以下で通信相手ノード（ＣＮ）と呼ばれる通信パートナー（宛先端末）との通信に、ホーム・アドレスを使用する。このアドレスは変更されず、モバイル・ノードを識別する働きをする。トポロジー的に、これはモバイル・ノードのホーム・ネットワーク（ＨＮ）に属する。これに対して、気付けアドレスは、サブネットの変更を発生させるあらゆる動きで変更され、ルーティング・インフラストラクチャに対するロケータとして使用される。トポロジー的に、これはモバイル・ノードが現在訪問中のネットワークに属する。ホーム・リンク上に位置するホーム・エージェント（ＨＡ）セットのうちの１つが、モバイル・ノードの気付けアドレスのモバイル・ノードのホーム・アドレスへのマッピングを維持し、モバイル・ノードに関する着信トラフィックをその現在位置へリダイレクトする。単一のホーム・エージェントではなく、ホーム・エージェントのセットを配置する理由は、冗長性およびロード・バランシングによるものとすることができる。

モバイルＩＰｖ６は、現在、双方向トンネリング（図１）およびルート最適化（図２）という２つの動作モードを定義する。双方向トンネリングを使用する場合、通信相手ノード１０１によって送信され、モバイル・ノード１０２のホーム・アドレスにアドレス指定されるデータ・パケットは、ホーム・ネットワーク１１０内のホーム・エージェント１１１によって遮断され、フォーリン・ネットワーク１２０にアンカーされたモバイル・ノード１０２の気付けアドレスへとトンネリングされる。モバイル・ノード１０２によって送信されたデータ・パケットは、ホーム・エージェント１１１へと逆トンネリングされ、ここでパケットをカプセル化解除して、それらを通信相手ノード１０１に送信する。逆トンネリングとは、パケットがモバイル・ノードによって（「通常」トンネルを補足するために）モバイル・ノードから始まりホーム・エージェントで終わる追加の逆トンネルを介して、伝送されることを意味する。

ＭＩＰｖ６でのこの動作の場合、ホーム・エージェント１１１のみにモバイル・ノード１０２の気付けアドレスが通知される。従ってモバイル・ノードは、バインディング更新（ＢＵ）メッセージをホーム・エージェントに送信する。これらのメッセージは、ＩＰｓｅｃセキュリティ・アソシエーションを介して送信されるため、認証され、整合性が保護される。欠点は、モバイル・ノードがホーム・ネットワークから遠方にあり、通信相手ノードがモバイル・ノードの近くにある場合、通信経路が不必要に長く、その結果、非効率的なルーティングおよび大きなパケット遅延が生じることである。

ルート最適化モード（図２を参照）は、通信相手ノードとモバイル・ノードとの間の直接経路を使用することによって、双方向トンネリング・モードの非効率性を防止することができる。ルート最適化を使用する場合、モバイル・ノードはバインディング更新メッセージを通信相手ノードに送信し、これが次に、データ・パケットをモバイル・ノードに直接送信することができる（パケットは、タイプ２のルーティング・ヘッダを使用して、モバイル・ノードの気付けアドレスへの直接経路上をモバイル・ノードのホーム・アドレスに向けて送信される）。もちろん、通信相手ノードは、モバイルＩＰｖ６ルート最適化サポートを実施していなければならない。

より詳細には、ルート最適化を実行するために、モバイル・ノードおよび通信相手ノードは、バインディングの作成および管理に関するすべてのメッセージ通信において、モバイル・ノード、通信相手ノード、およびホーム・エージェントによって使用される拡張ヘッダであるモビリティ・ヘッダ・プロトコルの一部であるシグナリング・メッセージを交換する。ルート最適化に関して、モビリティ・ヘッダ・プロトコルでは４つのメッセージタイプが指定される。

図３は、ＭＩＰｖ６においてＲＯに対して実行されるシグナリング・フローを示す図である。通信相手ノードに送信されるバインディング更新の保護には、セキュリティ・アソシエーションの構成、又はモバイル・ノードと通信相手ノードとの間の認証インフラストラクチャの存在は必要でない。代わりに、リターン・ルータビリティ手順と呼ばれる方法を使用して、正しいモバイル・ノードがメッセージを送信していることが確認される。

リターン・ルータビリティ手順は、モバイル・ノードが、請求されたその気付けアドレス並びにそのホーム・アドレスで実際にアドレス指定可能であるという何らかの妥当な保証を、通信相手ノードが得られるようにするものである。この保証を伴う場合にのみ、通信相手ノードはモバイル・ノードからバインディング更新を受け入れることが可能であり、その後これにより、モバイル・ノードのデータ・トラフィックを請求されたその気付けアドレスに向けて送るように通信相手ノードに指示することになる。

これは、２つの請求されたアドレスに対してアドレス指定されたパケットが、モバイル・ノードにルーティングされるか否かをテストすることによって実行される。モバイル・ノードは、通信相手ノードがそれらのアドレスに送信する特定のデータ（「キー生成トークン」）を受信したという証明を与えることができる場合にのみ、このテストをパスすることができる。これらのデータは、モバイル・ノードによってバインディング管理キーに組み込まれる。通信相手ノードに対するバインディング更新メッセージの整合性および真正性は、バインディング管理キーを使用して保護される。

ＭＮは、２つのメッセージをそれぞれ異なるルートを介してＣＮに送信する。一方のメッセージ、すなわちホーム・テスト開始（ＨｏＴｉ）メッセージは、ＭＩＰ ＩＰ−ｉｎ−ＩＰトンネルを介してＨＡに送信され、次にこれがメッセージをＣＮに転送する。モバイル・ノードは、ホーム・キー生成トークンを獲得するために、ホーム・テスト開始メッセージを（ホーム・エージェントを介して）通信相手ノードに送信する。図３に示されるように、メッセージはＣＮが後で戻さなければならないホーム開始クッキーを含み、ＭＮのホーム・アドレスをＣＮに搬送する。他方のメッセージ、すなわち気付けテスト開始（ＣｏＴｉ）は、気付けキー生成トークンを取得するために、ＣＮへ直接送信される。ＣｏＴｉメッセージは、現在のＭＮの気付けアドレスに関してＣＮに通知し、気付け開始クッキーを含む。

ＨｏＴｉおよびＣｏＴｉメッセージを受信した後、ＣＮは異なるルートを介して２つのメッセージをＭＮに再度返送する。ホーム・テスト（ＨｏＴ）メッセージがＭＮのＨｏＡに、すなわちＨｏＴｉメッセージに応答してＨＡに送信される。次にＨＡは、ＭＩＰｖ６トンネルを介してこのメッセージをＭＮに転送する。従って、気付けテスト（ＣｏＴ）メッセージがＭＮに直接送信される。ＨｏＴおよびＣｏＴの両方のメッセージは、それぞれ、前のＨｏＴｉおよびＣｏＴｉメッセージから受信したホーム開始クッキーおよび気付け開始クッキーと共に、それぞれ「ホーム・キー生成トークン」および「気付けキー生成トークン」を含む。どちらのトークンもＣＮの現在アクティブな秘密キー、ノンス、およびホーム又は気付けアドレス（それぞれ）に基づく。

ＨｏＴおよびＣｏＴメッセージがＭＮに到達した後、ＭＮはキー生成トークンを使用し、ＨｏＴおよびＣｏＴメッセージと共に受信したトークンからバインディング管理キーを生成する。モバイル・ノードはバインディング管理キーを作成した後、検証可能なバインディング更新を通信相手ノードに供給することができる。バインディング更新メッセージを受信した後、ＣＮはそのバインディング・キャッシュをＭＮのＨｏＡおよびＣｏＡのバインディングで更新することができる。

ＭＩＰｖ６は、ＭＮのＨｏＡおよびＣｏＡのＣＮにおけるマッピングを可能にすることによって、ＣＮとＭＮとの間のルートを最適化することができるため、結果として両方のノードが直接通信可能となる。

既存のアクティブＩＰセッションを活動状態で維持するためのＭＩＰｖ６方法の代替の１つは、同じＩＰプレフィクスのセットを広告するようにサービス側アクセス・ルータ（ＡＲ）を構成することであり、その結果、ＭＮは古いＡＲで構成されたＩＰアドレスの使用を維持することができる。この方法は、ネットワークベース・モビリティ管理と呼ばれる。ＩＥＴＦの標準化の下でのネットワークベース・モビリティ機構の１つが、「ネットワークベース局所的モビリティ管理」（ＮｅｔＬＭＭ）である。ネットワークベース・モビリティの主な特徴の１つは、ＭＮがモビリティ・プロセスに関与しないため、無線インタフェースを介したシグナリングが不要なことである。上記ＭＩＰｖ６方法は、ＭＮがバインディング更新メッセージを送信することによってそのＣｏＡをＨＡ又はＣＮに伝えることから、ＭＮがモビリティ・プロセスに含まれるため、ホストベース・モビリティと呼ばれる。

ＮｅｔＬＭＭは、２つのプロトコル・エンティティ、すなわちモバイル・アクセス・ゲートウェイ（ＭＡＧ）およびローカル・モビリティ・アンカー（ＬＭＡ）と、それらの間のメッセージ・セットとを定義する。ＭＡＧは、モバイル・ノードがそれら自体を接続する特定のリンク層技術を終了するデバイスに埋め込まれたルータである。ＬＭＡは、複数のＭＡＧへの接続を終了し、ＮｅｔＬＭＭシステム内を移動するモバイル・ノードに対するモビリティ要求を処理するルータである。ＭＮへの／からのデータ・パケットは、ＬＭＡとＭＡＧとの間でトンネリングされる。ＭＮが古いＭＡＧから新しいＭＡＧへと移動する場合、ＬＭＡに場所の変更が通知され、新しい場所（新しいＭＡＧ）へのＭＮのデータ・パケットのトンネリングを開始する。

ＭＮが２つの別個のＮｅｔＬＭＭドメイン間を移動する場合、通常のモビリティ・ソリューションはＭＩＰｖ６となる。さらに、ネットワークベース機構によってＮｅｔＬＭＭ間モビリティ（又はローカル・モビリティ・アンカー間のモビリティ、すなわちＬＭＡ間モビリティ）を解決するための方法が存在する。こうした方法の１つが、ローミング・シナリオ、すなわち異なるオペレータ間のモビリティに対して、３ＧＰＰによって導入される。ＭＮが訪問先のオペレータのネットワークに移動した場合、ＭＮのデータ・トラフィックはホーム・オペレータのネットワークへと転送され、その後、ホーム・オペレータはそのトラフィックを訪問先オペレータのネットワークにルーティングする。ネットワークベース・モビリティを有する理由の１つは、ホーム・オペレータがＭＮのデータ・トラフィックのモビリティ、ポリシー、および課金の制御を希望するためである可能性がある。

図４は、ネットワーク・アーキテクチャ、およびＭＮがオペレータ１からオペレータ２へと移動する間のＣＮとＭＮとの間の通信データ・ルートの概要を示す。最初に、ＭＮ１０２はアクセス・ネットワーク１ １１０に登録し（ＮｅｔＬＭＭエリア１１０はＭＮに対するホーム・ネットワークでもある）、サービス側ＬＭＡ１ １１１を介してＣＮ１０１との通信を開始する。ＭＮはＡＮ２ １２０へ移動する場合、第１にネットワークに登録して、それ自体を認証する。登録プロセス中に、ＡＮ２は、ＭＮの識別を検証するためにＡＮ１に接触する。ＡＮ１とＡＮ２との間での情報交換中に、ＡＮ２はＭＮ１０２のＩＰプレフィクス（および／又はＩＰアドレス）を習得するため、ＭＡＧ３ １２２を介してＭＮ１０２に同じＩＰプレフィクスを広告することによって、ＭＮ１０２に対してネットワーク層モビリティを隠すことができる。すなわちＭＮ１０２は、自分が依然として同じＩＰサブネット上にいるものと考える。そのため、ＭＮ１０２の場所がＬＭＡ１およびＬＭＡ２に登録される必要がある。さらに、ＭＮのトラフィックの交換のために、ＬＭＡ１とＬＭＡ２の間、およびＬＭＡ２とＭＡＧ３との間のトンネルが、セットアップされなければならない。

ＭＮが、ＬＭＡ１でアンカーされた訪問先ネットワーク内で引き続きオリジナルＩＰアドレスを使用するため、外部からのトラフィックは、ハンドオーバ後、引き続きＬＭＡ１に到達する（四角内の語句はＮｅｔＬＭＭ用語に対応し、括弧内の語句は３ＧＰＰ ＳＡＥ用語に対応する）。

図４から明らかなように、ＭＮ１０２が他のアクセス・ネットワークに移動した後、特に、ＣＮ１０１とＭＮ１０２がトポロジー的に近くに位置する場合、ＣＮ１０１とＭＮ１０２との間のデータ・ルートは不必要に長い。この結果、非効率的なルーティング、および例えば、リアルタイム・サービスにとって重大な、長いデータ・パケット遅延が生じる。

Ｄ．Ｊｏｈｎｓｏｎ、Ｃ．Ｐｅｒｋｉｎｓ、Ｊ．Ａｒｋｋｏの、「Ｍｏｂｉｌｉｔｙ Ｓｕｐｐｏｒｔ ｉｎ ＩＰｖ６」

上記最新技術の問題に鑑み、本発明の１つの目的は、通信相手ノードとのシームレスな通信を維持しながら、モバイル・ノードのハンドオーバに関する改善された機構を提案することである。

この目的は、独立請求項の主題によって解決される。本発明の有利な実施形態は、従属請求項の主題である。

本発明に従って、モバイル・ノードのモビリティを管理するための方法が提供される。モバイル・ノードは、第１のネットワーク領域内の第１のローカル・モビリティ・アンカーを介して、第１のデータ・パケット・ルート上にある通信相手ノードとデータ・パケットを交換する。モバイル・ノードの接続が、第１のローカル・モビリティ・アンカーから第２のローカル・モビリティ・アンカーへと変更された後、通信相手ノードとモバイル・ノードとの間の第１のデータ・パケット・ルートに対してルート最適化を使用するか否かに関する情報、並びにデータ・パケットの交換に使用される通信相手ノードおよびモバイル・ノードのアドレスに関する情報が、第１のネットワーク領域内のポリシー制御エンティティに要求される。通信相手ノードとモバイル・ノードとの間の第１のデータ・パケット・ルートにルート最適化が使用されることになる場合、通信相手ノードは、第２のデータ・ルート上で第２のローカル・モビリティ・アンカーを介してモバイル・ノードとデータ・パケットを交換するように指示される。

本発明の有利な実施形態によれば、ルート最適化を使用するか否かに関する情報はフラグであり、これは設定又は未設定が容易である。

本発明の他の実施形態では、ルート最適化は、モバイル・ノードの代わりに第２のローカル・モビリティ・アンカーによって実行される。この点で、第２のローカル・モビリティ・アンカーのアドレスがモバイル・ノードの気付けアドレスとして使用され、モバイル・ノードのアドレスはモバイル・ノードのホーム・アドレスとして使用される。それ故、モバイル・ノードがルート最適化シグナリングに関与しないため、無線でのシグナリングは不要である。

本発明の他の実施形態によれば、第２のローカル・モビリティ・アンカーが情報を要求し、通信相手ノードに指示する。ルート最適化およびハンドオーバは、１つのみのエンティティによって有利に処理される。

本発明の他の実施形態では、第２のローカル・モビリティ・アンカーは第２のネットワーク領域内に配置される。さらに、第２のネットワーク領域内の第２のポリシー制御エンティティが情報を要求し、同じことを要求するように第２のローカル・モビリティ・アンカーによって指示される。第２のポリシー制御エンティティ内で要求された情報を受信すると、要求された情報は第２のローカル・モビリティ・アンカーに転送される。

本発明の有利な実施形態によれば、第１のネットワーク領域内のポリシー制御エンティティは、モバイル・ノードが通信相手ノードとデータ・パケットの交換を開始している最中又は交換を開始した後、第１のデータ・パケット・ルートに対してルート最適化を使用するか否かを決定する。ポリシー制御エンティティは決定を実行するために必要な情報を保持するため、この点で第１の要求情報は不要である。

本発明の他の実施形態は、モバイル・ノードのホーム・ネットワークである第１のネットワークと、モバイル・ノードのホーム・エージェントである第１のローカル・モビリティ・アンカーとに関する。

本発明の他の実施形態では、第２のローカル・モビリティ・アンカーは第２のデータ・パケット・ルート上で通信相手ノードからデータ・パケットを受信し、ここでデータ・パケットはモバイル・ノードのアドレスを備えるルーティング・ヘッダ・フィールドを含み、第２のローカル・モビリティ・アンカーは、モバイル・ノードのアドレスをデータ・パケットの宛先アドレスとしてルーティング・ヘッダ・フィールド内に含めること、およびルーティング・ヘッダ・フィールドを削除することによって、各データ・パケットのヘッダを変更（adapt）する。それ故、データ・パケットは、標準ルータによってモバイル・ノードにルーティング可能である。

本発明のより特定の実施形態では、第２のローカル・モビリティ・アンカーは第２のデータ・パケット・ルート上でモバイル・ノードからデータ・パケットを受信する。各データ・パケットについて、データ・パケットのヘッダは、第２のローカル・モビリティ・アンカーのアドレスをデータ・パケットのソース・アドレスとして含めること、およびモバイル・ノードのアドレスをデータ・パケットのオプション・フィールドに含めることによって構成される。従って、このように構成されたデータ・パケットは、ローカル・モビリティ・アンカーと通信相手ノードとの間で、標準ルーティング・プロトコルを介してルーティングすることができる。

本発明の異なる実施形態によれば、通信相手ノードが、第２のローカル・モビリティ・アンカーを介して第２のデータ・ルート上でモバイル・ノードとデータ・パケットを交換する間に、モバイル・ノードは第２のローカル・モビリティ・アンカーから第１のローカル・モビリティ・アンカーへと接続を変更する。その後、第１のローカル・モビリティ・アンカーへのモバイル・ノードの接続が確立された後、第２のローカル・モビリティ・アンカーは、所定の時間内に第２のデータ・パケット・ルート上で着信するデータ・パケットを第１のローカル・モビリティ・アンカーに転送するように、第１のローカル・モビリティ・アンカーによって指示される。さらに、通信相手ノードは、第１のローカル・モビリティ・アンカーを介して第１のデータ・パケット・ルート上でモバイル・ノードとデータ・パケットを交換するように指示される。これによってシームレスな通信が可能になる。

本発明の他の実施形態では、通信相手ノードが、第２のローカル・モビリティ・アンカーを介して第２のデータ・ルート上でモバイル・ノードとデータ・パケットを交換する間に、モバイル・ノードは、第２のローカル・モビリティ・アンカーから第３のネットワーク領域内の第３のローカル・モビリティ・アンカーへと接続を変更する。第３のローカル・モビリティ・アンカーへのモバイル・ノードの接続が確立された後、第２のローカル・モビリティ・アンカーは、所定の時間内に第２のデータ・パケット・ルート上で着信するデータ・パケットを第１のローカル・モビリティ・アンカーに転送するように、第１のローカル・モビリティ・アンカーによって指示される。

さらに、通信相手ノードは、第１のローカル・モビリティ・アンカーを介して第１のデータ・パケット・ルート上でモバイル・ノードとデータ・パケットを交換するように指示される。その後、通信相手ノードとモバイル・ノードとの間の第１のデータ・パケット・ルートに対してルート最適化を使用するか否かに関する情報、並びにデータ・パケットの交換に使用される通信相手ノードおよびモバイル・ノードのアドレスに関する情報が、第１のネットワーク領域内のポリシー制御エンティティに要求される。次に、通信相手ノードとモバイル・ノードとの間の第１のデータ・パケット・ルートにルート最適化が使用されることになる場合、通信相手ノードは、第３のデータ・ルート上で第３のローカル・モビリティ・アンカーを介してモバイル・ノードとデータ・パケットを交換するように指示される。第３のネットワーク領域に関するルート最適化により、通信相手ノードとモバイル・ノードとの間のより直接的なルートが可能になるため、データ遅延が減少する。

本発明の他の実施形態では、ＣＮからの第２のパケット・データ・ルート上で着信するデータ・パケットは、モバイル・ノードのアドレスを有するルーティング・ヘッダ・フィールドを含む。各データ・パケットについて、第２のローカル・モビリティ・アンカーは、データ・パケットを第１のローカル・モビリティ・アンカーに転送する前に、モバイル・ノードのアドレスをデータ・パケットの宛先アドレスとしてルーティング・ヘッダ・フィールドに含めること、およびルーティング・ヘッダ・フィールドを削除することによって、データ・パケットのヘッダを変更する。

本発明の他の有利な実施形態に従って、ルート最適化が第１のデータ・パケット・ルートに使用されることになる場合、通信相手ノードが第２のローカル・モビリティ・アンカーに接続されているか否かが決定される。通信相手ノードが第２のローカル・モビリティ・アンカーに接続されている場合、第２のローカル・モビリティ・アンカーを介して第２のデータ・ルート上でモバイル・ノードとデータ・パケットを交換するように通信相手ノードに指示するのではなく、第２のローカル・モビリティ・アンカーが、第２のローカル・モビリティ・アンカーを介して第２のデータ・ルート上でモバイル・ノードおよび通信相手ノードとデータ・パケットを交換するように指示される。通信相手ノードが第２のローカル・モビリティ・アンカーに接続されていない場合、通信相手ノードが第２のネットワーク領域内に位置しているか否かが判別される。

通信相手ノードに、第２のローカル・モビリティ・アンカーを介して第２のデータ・ルート上でモバイル・ノードとデータ・パケットを交換するように指示するステップは、通信相手ノードが第２のネットワーク領域内に位置していない場合に実行される。他方で、通信相手ノードが第２のネットワーク領域内に位置している場合、第２のネットワーク領域内で通信相手ノードが接続される第３のローカル・モビリティ・アンカーが決定される。その後、第３のローカル・モビリティ・アンカーが決定されると、第２のローカル・モビリティ・アンカーを介して第２のデータ・ルート上でモバイル・ノードとデータ・パケットを交換するように通信相手ノードに指示するのではなく、第２および第３のローカル・モビリティ・アンカーが、第２および第３のローカル・モビリティ・アンカーを介して第３のデータ・パケット・ルート上で、モバイル・ノードおよび通信相手ノードとデータ・パケットを交換するように指示される。

本発明に従って、第１のネットワーク領域内にポリシー制御エンティティが提案される。プロセッサは、モバイル・ノードと通信相手ノードとの間で交換されることになるデータ・パケットが存在する第１のデータ・パケット・ルートに対してルート最適化を使用するか否かを決定するように構成される。さらに、この決定は、通信相手ノードへのモバイル・ノードの接続を確立中、又は確立後に実行される。さらに、受信器は、ルート最適化のための決定に関する情報を要求するために、ネットワーク・エンティティから要求を受信するように構成される。ポリシー制御エンティティ内の送信器は、ルート最適化のための決定に関する情報をネットワーク・エンティティに送信するように構成される。

本発明の有利な実施形態によれば、ポリシー制御エンティティのプロセッサは、さらに第１のデータ・パケット・ルートに対する少なくとも１つのポリシールールを確立するように構成される。さらにプロセッサは、第１のデータ・パケット・ルートに対する少なくとも１つのポリシールールに、ルート最適化のための決定に関する情報を含めるように構成される。１つの利点は、ルート最適化に関する決定が、ポリシー制御エンティティの通常の決定と共に実行可能な点である。

本発明に従って、ルート最適化を実行するためのローカル・モビリティ・アンカーが提案される。具体的に言えば、モバイル・ノードは、第１のネットワーク領域内の第１のローカル・モビリティ・アンカーを介して、第１のデータ・パケット・ルート上で通信相手ノードとデータ・パケットを交換する。モバイル・ノードの接続は、第１のローカル・モビリティ・アンカーからローカル・モビリティ・アンカーに変更される。ローカル・モビリティ・アンカー内のプロセッサは、通信相手ノードとモバイル・ノードとの間の第１のデータ・パケット・ルートに対してルート最適化を使用するか否かに関する情報を要求するために、第１のネットワーク領域内のポリシー制御エンティティに関する要求メッセージを生成するように構成される。さらに、データ・パケットの交換に使用される通信相手ノードおよびモバイル・ノードのアドレスに関する情報も、それによって要求される。送信器は、モバイル・ノードの接続を第１のローカル・モビリティ・アンカーからローカル・モビリティ・アンカーに変更した後、第１のネットワーク領域内のポリシー制御エンティティに要求メッセージを送信するように構成される。受信器は、ルート最適化を使用するか否か、並びに通信相手ノードおよびモバイル・ノードのアドレスに関する要求された情報を受信するように構成される。さらにプロセッサは、通信相手ノードとモバイル・ノードとの間の第１のデータ・パケット・ルートにルート最適化が使用されることになる場合、ローカル・モビリティ・アンカーを介して第２のデータ・ルート上でモバイル・ノードとデータ・パケットを交換するために、通信相手ノードに対する命令通知を生成するように構成される。さらに、送信器は、通信相手ノードに対して命令通知を送信するようにも構成される。

本発明の有利な実施形態によれば、ルート最適化は、ローカル・モビリティ・アンカーのアドレスをモバイル・ノードの気付けアドレスとして使用すること、およびモバイル・ノードのアドレスをモバイル・ノードのホーム・アドレスとして使用することにより、モバイル・ノードの代わりにローカル・モビリティ・アンカーによって実行される。それ故、新しいプロトコル手順を実施するのではなく、標準のルーチンを再使用することができる。

本発明の他の実施形態では、さらに受信器は、第２のデータ・パケット・ルート上で通信相手ノードからデータ・パケットを受信するように構成され、ここでデータ・パケットは、モバイル・ノードのアドレスを有するルーティング・ヘッダ・フィールドを含む。また、プロセッサは、モバイル・ノードのアドレスを、受信したそれぞれのデータ・パケットの宛先アドレスとしてルーティング・ヘッダ・フィールドに含めること、およびルーティング・ヘッダ・フィールドを削除することによって、受信したそれぞれのデータ・パケットのヘッダを変更する。最後に、さらに送信器は、受信したそれぞれのデータ・パケットをモバイル・ノードに送信するように構成される。

他の態様は、本発明の有利な実施形態に関し、この場合さらに受信器が、第２のデータ・パケット・ルート上でモバイル・ノードからデータ・パケットを受信するように構成される。さらに、プロセッサは、ローカル・モビリティ・アンカーのアドレスをデータ・パケットのソース・アドレスとして含めること、およびモバイル・ノードのアドレスをデータ・パケットのオプション・フィールドに含めることによって、受信したそれぞれのデータ・パケットのヘッダを変更する。

以下に、本発明について添付の図面を参照しながらより詳細に説明する。図面内の類似部分又は対応する詳細部分には同じ参照番号が付けられている。

ＭＩＰｖ６による、モバイル・ノードと通信相手ノードとの間の通信に関する双方向トンネリングの使用例を示す図 ＭＩＰｖ６による、モバイル・ノードと通信相手ノードとの間の通信に関するルート最適化の使用例を示す図である。 標準のＭＩＰｖ６ルート最適化に関する信号図、並びに関連メッセージのパケット・フォーマットを示す図 異なるアクセス・ネットワーク間を移動するモバイル・ノードに関するネットワーク・アーキテクチャを示す図 ３ＧＰＰ標準による、ポリシー制御および課金システムのアーキテクチャを示す図 ベアラ、サービス・データ・フロー、およびパケット・データ・フローの間の関係を示す図 ２つのアクセス・ネットワークを備えるネットワーク・アーキテクチャと、本発明の一実施形態に従ったＣＮとＭＮとの間でのメッセージ交換を示す図 本発明の一実施形態による、ハンドオーバ手順を示す信号図 ＭＮとＣＮとの間でのデータ・パケットの交換中のＬＭＡ２、ＰＭＩＰａ、およびＭＡＧ３でのパケット・ヘッダ修正を示す図 ＭＮおよびＣＮが同じアクセス・ネットワーク内に位置し、さらに同じローカル・モビリティ・アンカーに接続されたネットワーク・アーキテクチャを示す図 ＭＮおよびＣＮが同じアクセス・ネットワーク内に位置するが、異なるローカル・モビリティ・アンカーによってサービスが提供されるネットワーク・アーキテクチャを示す図 本発明に従ってネットワーク領域２へのハンドオーバ手順が実行された後に、ＭＮがネットワーク領域２からネットワーク領域１に戻るネットワーク・アーキテクチャを示す図 本発明に従ってネットワーク領域２へのハンドオーバ手順が実行された後に、ＭＮがネットワーク領域３へ移動を続けるネットワーク・アーキテクチャを示す図

以下の段落では、本発明の種々の実施形態について説明する。単なる例示としての目的で、ほとんどの実施形態は、上記背景技術の項で説明したＮｅｔＬＭＭに従ったＮｅｔＬＭＭ通信システムに関して概説される。本発明は、例えば、上記ＮｅｔＬＭＭ通信システムなどのモバイル通信システムに関連して有利に使用することができるが、本発明は、この特定の例示的通信ネットワークでの使用に限定されるものでないことに留意されたい。

上記技術的背景の項での説明は、本明細書に記載されるほぼＮｅｔＬＭＭ特有の例示的実施形態をより良く理解することを意図するものであり、モバイル通信ネットワークにおけるプロセスおよび機能の説明された特定の実施態様に本発明を限定するものと理解されるべきではない。それにもかかわらず、本明細書で提案された改良点は、技術的背景の項で説明されたアーキテクチャ／システムにおいて容易に適用可能であり、本発明のいくつかの実施形態では、これらのアーキテクチャ／システムの標準的および改良された手順を使用することもできる。

定義
以下に、本明細書で頻繁に使用されるいくつかの用語について定義する。

モバイル・ノードとは、通信ネットワーク内の物理エンティティである。１つのノードがいくつかの機能エンティティを有することができる。機能エンティティとは、ノード又はネットワークの他の機能エンティティに対して所定の機能セットを実施および／又は提供するソフトウェア又はハードウェア・モジュールを言い表す。ノードは、ノードが通信する際に介することが可能な通信機構又はメディアにノードを接続する１つ又は複数のインタフェースを有することができる。同様に、ネットワーク・エンティティは、他の機能エンティティ又は通信相手ノードと通信する際に介することが可能な通信機構又はメディアに機能エンティティを接続する論理インタフェースを有することができる。

ローカル・モビリティ・アンカー（ＬＭＡ）とは、ホスト・ルートの集まりと、局所的モビリティ管理ドメイン（ネットワーク領域）内のモバイル・ノードに関する関連付けられた転送情報とを制御するルータである。これに関連付けられたＭＡＧと共に、ＬＭＡはＮＥＴＬＭＭプロトコルを使用して、局所的モビリティ管理ドメイン内のモバイル・ノード・モビリティを管理する。モバイル・ノードのデータ・トラフィックのルーティングは、モバイル・ノードが局所的モビリティ管理ドメイン内を動き回る際に、ＬＭＡでアンカーされる。

一般に、ポリシー制御は、ＱｏＳ制御および／又はゲーティング制御を含む。後者は、サービス・データ・フローに属するパケットを所望のエンドポイントへ通過させるためのブロック又は許可のプロセスである。それに対応して、一方で、ポリシー制御エンティティは、オペレータがＱｏＳポリシーベースのサービスを実行できるようにするものであり、すなわち、ゲートウェイとユーザ端末との間のデータ経路に沿ったリソースの保存および制御を意味する。他方で、ポリシー制御エンティティは、エンドポイント、すなわちゲートウェイにおけるデータ・パケットのフィルタリングルールを決定する。

一般に、各ネットワークは少なくとも１つ又は複数の番号、例えば、いわゆるプレフィクスによって、識別される。この番号により、ネットワークを介して、識別されたネットワークへとパケットをルーティングすることができる。さらにこのプレフィクス番号は、ネットワーク内のノードによって使用可能なアドレスに含まれる。例えば、ＩＰｖ６では、ネットワークの番号はＩＰｖ６プレフィクスであり、ネットワーク内のアドレスは、ＩＰｖ６プレフィクスおよびＩＰｖ６ホスト部分からなるＩＰｖ６アドレスである。異なるネットワーク、例えば、ホーム・ネットワークおよびフォーリン・ネットワークでは異なるアドレスが使用される。

モバイル・ノードのホーム・ネットワーク（すなわちホーム・リンク）は、通常、モバイル・ノードが、モバイル・ノードの所与のホーム・アドレスに関するその気付けアドレスを登録しているホーム・エージェントの位置によって識別される。ホーム・アドレスとは、モバイル・ノードの永続アドレスとして使用されるモバイル・ノードに割り当てられたアドレスである。このアドレスは、モバイル・ノードのホーム・ネットワークのプレフィクスを有する。気付けアドレスとは、フォーリン・ネットワークを訪問中のモバイル・ノードに関連付けられるアドレスである。気付けアドレスのプレフィクスは、通常、訪問先ネットワークのプレフィクスに等しい。モバイル・ノードは、１つ又は複数の気付けアドレスを同時に有することができる。

ホーム・エージェントとは、モバイル・ノードがその現在の気付けアドレスを登録する際に使用するモバイル・ノードのホーム・ネットワーク上にルーティング機能を提供するルータ又は機能エンティティである。モバイル・ノードがホームから遠隔にある間、ホーム・エージェントは、例えば、モバイル・ノードのホーム・アドレスを宛先とするホーム・リンク上のパケットを遮断し、それらをカプセル化して、モバイル・ノードの登録済み気付けアドレスのうちの１つ又はいくつかに対してそれらをトンネリングすることによって、モバイル・ノードにモビリティ・サービスを提供することができる。

本発明の一態様は、ＣＮとＭＮとの間のルーティングを最適化すること、および以前のアクセス・ネットワークのローカル・モビリティ・アンカーを介したルーティングを回避することである。しかし、新しいアクセス・ネットワーク内のＭＮはそのＩＰアドレスを変更しないため、ＭＮへのすべてのデータ・パケットは、引き続き以前のローカル・モビリティ・アンカーに到達する。さらに、ＭＮのＩＰアドレスが引き続き同じであるため、ＭＩＰｖ６ルート最適化（図２および図３を参照）を実行することができない。

従って、本発明の他の態様は、訪問先フォーリン・ネットワークのローカル・モビリティ・アンカーが、ＭＮの代わりにＭＩＰｖ６ルート最適化を開始することに関する。この点に関して、新しいアクセス・ネットワークのＬＭＡでプロキシＭＩＰエージェント（ＰＭＩＰａ）を実施することが提案され、ここで、対応するプロトコル・プロキシ・モバイルＩＰｖ６（ＰＭＩＰｖ６）はＭＩＰｖ６に基づくものであり、ＭＮにネットワークベースのモビリティ管理を提供する。ＰＭＩＰａはＬＭＡ内の機能であると想定される。ＰＭＩＰａ機能は、実際に、モバイル・ノードに代わって、ＢＵ、ＣｏＴｉ、ＨｏＴｉなどのモビリティ・ヘッダを含むＭＩＰｖ６メッセージの送信／受信の責務を負うことになる。それ故、ＰＭＩＰａは実際に、制御プレーン機能／エンティティである。ＰＭＩＰａは、データベースを更新すること、およびＬＭＡのデータ・プレーン内の他の機能／モジュールと対話することができる。例えば、ＰＭＩＰａが所与のＭＮに対してＣＮを使用してルート最適化を実行した場合、ＬＭＡ内のデータ・プレーン（例えば、ルータ機能）は、それに応じてデータ・パケット・ヘッダを修正し、データ・パケットを転送するように指示されることになる。

具体的に言えば、移動局がそのＰＭＩＰｖ６ネットワークに入り、アクセス認証を実行すると、ネットワークは、移動局が常にそのホーム・ネットワーク上にあることを確保し、さらに、いずれかのアドレス構成手順を使用する場合、常にそのホーム・アドレスを取得することを確保する。言い換えれば、具体的に移動局に対して割り当てられたホーム・アドレス／プレフィクスが存在し、そのプレフィクスは、そのＰＭＩＰドメイン内を進む場合はどこでも常にノードの後に続く。移動局の観点からすれば、ＰＭＩＰドメイン全体がホーム・リンクと見られる。

移動局が、プロキシ・モバイルＩＰエージェントを実行するアクセス・ルータ（ＡＲ）上のリンクに接続された場合、モバイル・ノードは、アクセス認証手順の一部としてその識別をネットワークに提示することになる。具体的に言えば、新しいＡＲでのＭＮのリンク層登録中の、認証、許可、およびアカウンティング（ＡＡＡ）に基づく認証成功の後、ＰＭＩＰａは、ＭＮのＩＰアドレス・プレフィクス（又はホームＩＰアドレス）およびホーム・エージェントを含む移動局のプロファイルを有することになる。プロキシ・モバイルＩＰエージェントは、移動局のホーム・リンクに対して指定されたパラメータを有するルータ広告を送信することによって、移動局がそのホーム・リンクにあることを確保するために十分な情報を有することになる。プロキシ・モバイルＩＰエージェントは、プロキシ・バインディング更新メッセージを移動局のホーム・エージェントに送信する。そのメッセージのソース・アドレスは、ＰＭＩＰａのＩＰｖ６アドレスとなる。要求を検証した後、このバインディング更新要求を受け入れると、ホーム・エージェントは、その独自のアドレスに固定されたトンネルのソース・アドレス、およびバインディング更新メッセージから取得されたプロキシ・モバイルＩＰエージェントの宛先アドレスで、トンネルをセットアップする。

ＰＭＩＰｖ６は、同じ問題をターゲットとしているため、ＮｅｔＬＭＭと比較することが可能であり、モビリティをＭＮのネットワーク層に対してトランスペアレントにすることができる。従って、ネットワーク間をローミングする間、通信相手ノードにシームレスな通信を提供するために、無線インタフェースを介するシグナリングは不要である。

すでに前述したように、新しいアクセス・ネットワークのＬＭＡで実施されるＰＭＩＰａは、ＭＮに関するＭＩＰｖ６に従ってルート最適化を実行することになる。しかし、ＲＯを実行するために、ＰＭＩＰエージェントはＣＮ、ＭＮのＨＡ、およびルート最適化が本当に実行されることになるか否かに関する情報を保持しなければならない。ＰＭＩＰａに上記情報が提供されない場合、通常、ＭＮに代わってＲＯを開始することはできない。

従って、本発明の他の一態様は、ＭＮが他のフォーリン・モビリティ・アンカーへのハンドオーバを実行する場合、ルート最適化プロセスを制御するためにホーム・ネットワーク内のポリシー制御システムを拡張することである。ポリシー制御システムは、ＰＭＩＰａがＭＮに対してＲＯを実行できるようにするために必要な情報を保持する。

この点において、本発明を適切に理解するために必要な範囲で、ポリシー制御システムについて説明する。Ｖｏｉｃｅ−ｏｖｅｒ−ＩＰ（ＶｏＩＰ）などのサービス・アプリケーションのセットアップのために、３ＧＰＰはＩＰマルチメディア・サブシステム（ＩＭＳ）アーキテクチャを標準化した。ＩＭＳの不可欠な要素は、トランスポート・ネットワークを介してリソースを許可および保持するために、マルチメディア・サービス・パラメータを適用する呼セッション制御機能（ＣＳＣＦ）である。ＣＳＣＦは、マルチメディア・サービスに必要なリソースを許可および保持するために、ポリシー制御および課金（ＰＣＣ）システムと対話する。

図５は、３ＧＰＰに従ったポリシー制御および課金システムのアーキテクチャを示す高水準概略図である。ＰＣＣ機能には、ポリシーおよび課金強化機能（ＰＣＥＦ）、ポリシーおよび課金ルール機能（ＰＣＲＦ）、アプリケーション機能（ＡＦ）、オンライン課金システム（ＯＣＳ）、オフライン課金システム（ＯＦＣＳ）、および加入プロファイル・レポジトリ（ＳＰＲ）の機能が含まれる。ＰＣＣアーキテクチャは、ポリシーおよび課金強化機能が、パケット・データ・ネットワーク（ＰＤＮ）へのＩＰアクセスを実施するゲートウェイ・ノード内の機能エンティティである（すなわち、ＧＰＲＳの場合はＧＧＳＮ、ＷＬＡＮの場合はＰＤＧ）、ＩＰ−ＣＡＮのアーキテクチャを拡張する。

具体的に言えば、アプリケーション機能（例えば、ＩＭＳのＣＳＣＦとすることができる）は、ベアラのネットワークベースのセットアップをトリガする。ＡＦはＰＣＲＦと通信して、トラフィック・ベアラ・セットアップに関する決定を行うためにＰＣＲＦが必要とする動的セッション情報を転送する。こうしたセッション情報は、ＩＰ５タプル・パラメータ（ソース・アドレス、宛先アドレス、ソース／宛先ポート、プロトコルＩＤ）を含むことができるマルチメディア・サービスのセッション記述プロトコル（ＳＤＰ）パラメータに基づくフロー・パラメータとすることができる。

ＰＣＲＦは、データ・プレーン内のパケット・フローを処理するためのルールを決定する。ＰＣＣルールは、サービス・データ・フローの検出を可能にし、ポリシーおよび課金制御に関するパラメータを提供する情報セットとして定義可能である。ＰＣＣルールを決定するために、ＰＣＲＦは以下の情報を使用する。
・ＡＦからのサービス情報（例えば、ＳＤＰ情報又は他の使用可能なアプリケーション情報）
・適切なＱｏＳ許可を計算するためのＳＰＲからの加入者情報（ＱｏＳクラス識別子ビットレート）
・ＰＣＥＦに要求されたＱｏＳ
・それ独自の事前定義情報

１つのサービス・データ・フローに対するＰＣＣルールに基づいて、ＰＣＲＦはフロー・フィルタ・パラメータを計算し、それらを、例えば、ゲートウェイ（例えば、ＮｅｔＬＭＭケースではＬＭＡ、ＧＰＲＳケースではＧＧＳＮ、およびＷＬＡＮケースではＰＤＧ）に配置することができるＰＣＥＦにシグナリングする。ＰＣＥＦは、サービス・データ・フロー検出、ユーザ・プレーン・トラフィック処理、制御プレーン・トリガ・セッション管理、ＱｏＳ処理、およびサービス・データ・フロー測定、並びにオンラインおよびオフラインの課金相互作用を提供する。

さらに、ＰＣＥＦは、サービス・データ・フロー・テンプレート（ＳＤＦＴ）を使用し、これは、正しいサービス・データ・フロー上にマッピングされる着信パケットに適用される。図６は、ベアラ、サービス・データ・フロー、およびパケット・データ・フローの間の関係を示し、ここではいくつかのパケット・データ・フローをサービス・データ・フローに集約することができる。さらに、いくつかのサービス・データ・フローは１つのベアラを介して伝送可能である。各ＰＣＣルールは、サービス・データ・フロー・テンプレートを含み、これがサービス・データ・フロー検出のためのデータを定義し、１方向のみ用（サービス・データ・フロー１のダウンリンク・トラフィック・フロー・フィルタ１）、又は両方向用（サービス・データ・フロー２のダウンリンク・トラフィック・フロー・フィルタ１およびアップリンク・トラフィック・フロー・フィルタ２又は３）の単方向サービス・データ・フロー・フィルタを含む。さらに、各ＰＣＣルールは、サービス・データ・フローごとに定義され、動的（ＰＣＲＦで生成される）および／又は事前定義（直接ＰＣＥＦに提供される）とすることができる。

ＰＣＣの課金面については、本発明に不可欠な関連性がないため、詳細には説明しない。

本発明の態様によれば、ポリシー制御エンティティは、サービス・データ・フローに対してルート最適化を使用するか否かの関連情報を保持する。ルート最適化に関する決定は、同じサービス・データ・フローに対する他のＰＣＣルールの設定と共に、モバイル・ノードと通信相手ノードとの間のセッション・セットアップでも実行される。

以下で、図面を参照しながら本発明について詳細に説明する。

図７は、本発明の一実施形態による、ネットワーク・アーキテクチャおよびメッセージ交換の一部を示す概略図である。図８は、本発明の一実施形態によるハンドオーバ手順に関する信号図である。

図７から明らかなように、ＭＮ１０２は、最初はＡＮ１ １１０に位置するものと想定され、この場合、ＡＮ１はＭＮに対するホーム・ネットワークであり、ＭＮがそのＣｏＡを登録したネットワークである。セッション・セットアップ中に、ＭＮ１０２がＡＮ１で電源オンになった場合、ＰＣＣシステム１１４は、通信に必要なリソースを確立するルーチン手順を実行する。これには、使用可能なベアラへのデータ・フローのマッピング又はＱｏＳのためのリソース保持などの、データ・プレーンにおいてパケット・フローを処理するためのＰＣＣルールの決定を含むことができる。

本発明の一実施形態によれば、さらにＰＣＣシステムは、様々な条件に基づいて、所与のデータ・パケット・フローに対してルート最適化が必要であるか否かを決定することができる。この条件の一部を以下に示す。
・アプリケーション機能が必要とする（ＡＦは、例えば、ＩＭＳのアプリケーション管理の一部とすることができるため、ＡＦはローミング中のＭＮに対するルート最適化を必要とする可能性がある）
・オペレータ・ポリシー
・加入情報（ＳＰＲからの）
・ＱｏＳパラメータ（エンドツーエンド伝送遅延）
・課金要件
・位置プライバシー（これは、ＣＮがＩＰアドレスに基づいてＭＮの地理的位置を解決することができる場合、ＭＮがそのトポロジー的位置、すなわちそのＩＰアドレスをＣＮから隠したいか否かを意味する）

例えば、ＰＣＲＦはＰＣＣルールを決定する場合、上記いくつかの条件の組み合わせに基づいて、ルート最適化を実行するか否かを決定することもできる。しかし、ＰＣＣシステムの他のエンティティにも必要な情報が提供され、任意の所与のパケット・データ・フローに対するＲＯに関して決定することが可能であった。この点において、ＰＣＲＦは、ＲＯが決定したか否かを示すためにＲＯフラグを使用することが可能であった。しかし、例えば、ビット値などのＲＯ決定を表示できる他の可能性も追求可能であった。従って、条件がＲＯを示唆する場合、ＲＯフラグは「真」に設定される。他方で、ＲＯが望ましくない場合、ＲＯフラグは「偽」に設定される可能性がある。

以下に、ＲＯに関する決定を実行可能な方法について、いくつかの例を示す。
・最小のエンドツーエンド遅延がサービスにとって必要であり、且つ、課金ルールによってトラフィックが決してホーム・モビリティ・アンカー（Ｈ−ＬＭＡ）を通過しないようにできる場合、ＰＣＲＦはＲＯフラグを「真」に決定することができる。
・課金ルールが、データ・パケット・フローがＨ−ＬＭＡを通過する必要があることを要求する場合、ＲＯフラグは設定されない（又は「偽」に設定される）。
・位置プライバシーが必要とされる場合、すなわちＭＮの新しい位置がＣＮに対して明らかにされてはならない場合、ＲＯフラグは設定されない（又は偽／負に設定される）。
・ＣＮがホーム・ネットワーク内に位置する場合、パケットは常にホーム・ネットワークを通過するため、ＲＯは不要であり、それ故、ＲＯフラグは設定されない（「偽」に設定される）。

上記の例は、条件の可能な組み合わせの中からの非常に制約された抽出に過ぎず、ＲＯに関する、又はＲＯに対する決定方法を制限するものと理解されるべきではない。

ルート最適化に関する決定はセッション確立中、すなわち、ＰＣＣルールにおけるデータ・パケット・フロー・パラメータのセットアップ中に実行される。ＲＯ決定が実行され、ＰＣＣルールにセットアップされると、通信セッションの期間中有効である。しかし、通信セッション中にＲＯ関連情報を動的に変更することも可能である。具体的に言えば、例えば、エンドツーエンド要求の変化によって初期の条件が変更される場合、ＰＣＣシステム（ＰＣＲＦ）にとって、ＲＯを依然として実行すべきか否かを決定すること、および必要であればＲＯフラグを適宜再設定することが可能である。

さらに、ＭＮがいくつかの異なるホームＩＰアドレスを構成し、別個のＣＮとの通信用に異なるＩＰアドレスを使用する可能性があるため、ＰＭＩＰａ１２３も、ＣＮのＩＰ宛先アドレスおよびＭＮのソースＩＰアドレスを知る必要がある。従って、ＰＭＩＰａに、最適化されることになる特定通信用のソース・アドレスと宛先アドレスのペア（ＳＡ−ＤＡ）を提供することが必要である。

また、ルート最適化が実行されない場合、ＳＡ−ＤＡペアは必要でないため、ＲＯフラグを保存するのみも可能である。従って、上記ケースでは、情報を要求したＰＭＩＰａに負のＲＯフラグのみを伝送することでも、それによってメッセージの長さが縮小されるため十分である。

ＳＡ−ＤＡペアと共にＲＯフラグを格納するポリシー制御システム１１４のエンティティを選択するためのいくつかのオプションがある。これは、ＰＣＲＦ、ＡＦ、又はＰＣＥＦのエンティティ内で実行することができる（図５を参照）。有利には、ＰＣＲＦは、通信のサービス・データ・フローに関するＰＣＣルールを決定し、ＲＯに関する決定も実行可能であるため、ＲＯ関連情報をＰＣＲＦに格納することができる。

さらに、ＰＣＥＦ、ＳＰＲなどの他のエンティティから情報を取り出し、この情報に基づいて、他のモビリティ・アンカーへのローミング後、ＭＮに対するルート最適化が必要となるか否かを適切に決定することも可能である。それにもかかわらず、ＲＯ関連情報（ＲＯフラグ＋ＳＡ−ＤＡペア）は、例えば、ＳＤＦＴの一部としてＰＣＥＦにも格納することができる（以下を参照）。ＡＦも、ＳＡ−ＤＡペアに関する情報を有し、ＲＯフラグを獲得するための手段を有することができるため、ＲＯ関連情報を格納する可能性がある。後者は、ＩＭＳ（又は具体的にはＡＦ）がＲＯフラグのセットアップについて決定する場合に可能である。

ＰＣＲＦは、各サービス・データ・フローに関するＰＣＣルールを保持する。ＲＯ関連情報は、例えば、ＰＣＣルールに組み込むことができる。ＰＣＣルールにＲＯ関連情報を格納する方法には、以下のようないくつかのオプションがある。
・ＲＯ関連情報を、特定のサービス・データ・フローに関するＰＣＣルールに、完全に新しいセクションとして格納することができる。この新しいセクション（例えば、「ＲＯ関連情報」と呼ばれる）は、（「サービス・データ・フロー・テンプレートと類似の」）サービス・データ・フロー内の各パケット・データ・フローに対応するいくつかのパラメータを有するための可能性を提供するものとする。
・ＲＯ関連情報を、サービス・データ・フローごとに複数のフローが使用可能な場合、パケット・データ・フローごとに別々に定義可能な新しいパラメータとして、ＰＣＣルールのポリシー制御セクションに格納することができる。
・ＲＯ関連情報を「サービス・データ・フロー・テンプレート」（ＳＤＦＴ）に格納することができる。上記のように、ＳＤＦＴは、各パケット・データ・フローについていくつかのトラフィック・フロー・フィルタを含むことができる。それ故、トラフィック・フロー・フィルタと同様に、ＲＯ情報は各パケット・データ・フローについて格納されるものとする。

ＳＤＦＴはＰＣＣルールの一部であるため、ＰＣＲＦに格納されるが、ＰＣＥＦにも格納されることに留意されたい。具体的に言えば、ＰＣＲＦおよびＰＣＥＦは図５に示されるようにＳＤＦＴパラメータを交換するため、結果として、両方のエンティティに同じパラメータが格納されることになる。

要約すると、図８から明らかなように、最初に、ＭＮ１０２はＡＮ１ １１０に接続して登録する。続いて、ＣＮとの接続を確立する。これには、ＰＣＣシステム１１４によるＰＣＣルールに関する決定も含まれる。上記のように、これにより、ＣＮ１０１への通信セッションに対してルート最適化を実行するか否かの決定がＰＣＣシステム１１４によって実行される。この決定は、ＰＣＲＦによって、又はＰＣＣシステム内の任意の他の可能エンティティによって実行可能であり、結果として生じるＲＯフラグおよびソース・アドレスと宛先アドレスとのペアからなるＲＯ関連情報は、任意の適切な位置にあるＰＣＣシステム内に保存される。ＭＮ１０２は、ホーム・リンクを介して、具体的にはＬＭＡ１ １１１およびＭＡＧ２ １１３を介して、ＣＮ１０１とデータ・パケットを交換する（ＭＡＧは、例示としての目的で図８では省略。図７を参照）。

最終的に、ＭＮ１０２はフォーリン・ネットワークＡＮ２ １２０へローミングし、ここで第一に、ハンドオーバ手順の一部としてネットワークに登録し、それ自体を認証する。登録プロセス中に、ＡＮ２はＡＮ１に接触してＭＮの識別を検証する。具体的に言えば、ＡＮ１とＡＮ２との間で情報交換を実行するオプションの１つは、ＡＮ２内のＭＡＧ又はＬＭＡに位置するＡＡＡクライアント（認証、許可、およびアカウンティング）が、ＡＮ２内のＡＡＡサーバと接触することを可能にするものである。ＡＮ２のＡＡＡサーバは、ＭＮに関する情報を持たない場合、ＡＮ１内のＡＡＡサーバと接触する。ＡＡＡインフラストラクチャは、ネットワークベースのモビリティに必要な情報を格納および管理するように構成されることが想定される。従って、ＡＮ２内のＡＡＡクライアントは、ＭＮのＩＰプレフィクス（および／又はＩＰアドレス）を習得する。従って、具体的に言えば、ＬＭＡ２ １２１およびＭＡＧ３ １２２は、ネットワーク層モビリティをＭＮから隠すことが可能であり、ここでＭＮは同じＩＰサブネット上にあると想定する。

従って、ＭＮの位置をＬＭＡ２およびＬＭＡ１に登録する必要があり、ハンドオーバ後、データ・パケットが交換できるように、ＬＭＡ２とＬＭＡ１との間、およびＬＭＡ２とＭＡＧ３との間のトンネルのセットアップを伴う。

ＲＯ関連情報をＰＭＩＰａ内で取得するにはいくつかの方法がある。可能な方法の１つは、ＰＭＩＰａがＡＮ１内のＰＣＣシステムに接触することである。２つのアクセス・ネットワーク間のトンネル確立を含む新しいアクセス・ネットワークへのハンドオーバが完了した後、ＰＭＩＰａは、ＡＮ１内のＰＣＣシステム１１４に、ＣＮとの通信セッションに関するＲＯ関連情報を要求する。ＰＭＩＰａ１２３は、トンネル・セットアップ又はハンドオーバ手順中の任意の他のシグナリング時のＬＭＡ１との通信交換中に、ＬＭＡ１からＰＣＲＦのアドレスを取得することができるか、又は別の方法としては、ネットワーク・オペレータによって事前に構成することができる。それ故、ＰＭＩＰエージェント１２３は、ＭＮのホーム・ネットワーク１１０内のＰＣＣシステムに直接接触することが可能である。これに応答して、ＰＣＲＦエンティティは、ＲＯ関連情報を、ＬＭＡ２ １２１内のＰＭＩＰａ１２３にトンネリングすることになる。

具体的に言えば、ＰＭＩＰａは、ＬＭＡ１とのトンネル・セットアップ手順中にＲＯ関連情報を取得する。ＰＭＩＰａはＨＡ（ＬＭＡ１）にプロキシＢＵメッセージを送信し、ＲＯ関連情報を含むプロキシＢＵ肯定応答メッセージ受信する。ＬＭＡ１は、プロキシＢＵメッセージを受信すると、ＰＣＲＦ／ＰＣＥＦからＲＯ関連情報を取り出すことができる。

ＲＯ関連情報を要求およびシグナリングするための他の代替実施形態が可能である。例えば、ＰＭＩＰａ１２３は、訪問先ネットワーク１２０内のＰＣＣシステムであるその独自のＰＣＲＦエンティティ（図示せず）に接触することができる。従って、ＡＮ２のＰＣＲＦエンティティは、ホーム・ネットワーク内のＰＣＲＦエンティティと接触して、ＲＯ関連情報を取得する。その後、フォーリン・ネットワーク１２０内のＰＣＲＦは要求された情報を受信し、同じくＰＭＩＰａ１２３に転送することができる。他の代替実施形態は、訪問先ネットワーク１２０でのＰＣＥＦ機能に関する。ＰＣＥＦ機能が使用可能な場合、ＰＭＩＰａ１２３は、ホーム・ネットワーク内のＰＣＲＦ機能にＲＯ関連情報を要求するように、同様に指示することができる。従って、情報を受信後、ＡＮ２内のＰＣＥＦ機能は、ルート最適化を実行するか否かをＰＭＩＰエージェントに強制する

さらに上記とは異なり、ホーム・ネットワーク内のＰＣＲＦエンティティは、ＡＮ１からＡＮ２へのＭＮ１０２のハンドオーバ手順中に、ＰＭＩＰエージェントのアドレスをＬＭＡ１から取得することができる。その結果、ＡＮ１内のＰＣＲＦエンティティも同様に、ＬＭＡ２のＰＭＩＰエージェントとのＲＯ関連情報交換を開始することができる。ＰＣＲＦがＲＯを実行すべきであると決定した場合、ＰＣＲＦエンティティからのＲＯ関連情報の伝送のみを開始することが可能な場合もある。

結果として、これでＰＭＩＰａ１２３は、ルート最適化を実行するために必要なＣＮおよびＭＮに関する情報を保持することになる。受信したＲＯフラグが「真」の場合、ＰＭＩＰａは、ＭＮに代わってＣＮで実際にＲＯを開始する。ＣＮは、ＭＮのＨｏＡのみを認識し、トランスポート・セッションはこのＨｏＡにバインディングされる。ルートを最適化するために、ＰＭＩＰａは新しいＣｏＡとＨｏＡのバインディングをＣＮ内で確立することが必要である。しかし、ＡＮモビリティはＭＮのネットワーク層に対してトランスペアレントであるため、ＭＮは新しいアドレスを持たない。ＭＮ自体が新しいアドレスを持たないことから、ＰＭＩＰａのアドレスをＭＮの新しいＣｏＡとして使用することができる。

本発明の実施形態によれば、ルートの最適化にＭＩＰｖ６のリターン・ルータビリティ手順が使用される。従って、リターン・ルータビリティ手順のＢＵメッセージは、ＭＮのオリジナル・アドレスに等しいＨｏＡと、新しいアドレスであるＣｏＡとを含まなければならない。この点において、ＰＭＩＰａは、ホーム・アドレスとしてＭＮのＩＰアドレスを使用し、さらにＭＮの気付けアドレスとして、例えばそれ独自のアドレスを使用する。他のオプションは、ＰＭＩＰａが、ＭＮに対するＣｏＡとして使用するために新しいＩＰアドレスを生成することが可能なものであり得る。

具体的に言えば、図８から明らかなように、ＰＭＩＰａは、ＭＮのＩＰアドレスをソース・アドレスとし、ＣＮのＩＰアドレスを宛先アドレスとするＨｏＴｉメッセージを生成する。通常の手順によれば、ＨｏＴｉメッセージはホーム開始クッキーも備える。ＨｏＴｉメッセージは、ＡＮ１のＬＭＡ１を介してＣＮに伝送される。さらに、ＰＭＩＰａは、ＣｏＴｉメッセージも生成し、ここでも同様に、ソース・アドレスはＰＭＩＰエージェントのＩＰアドレスであり、宛先アドレスはＣＮのＩＰアドレスである。ＣｏＴｉメッセージは、気付け開始クッキーを含み、ＣＮに直接伝送される。

その後、ＣＮはＨｏＴｉおよびＣｏＴｉの両方のメッセージを受信し、これに応答して、それぞれＨｏＴおよびＣｏＴメッセージを作成する。通常の手順に従って、ＨｏＴメッセージは、受信したＨｏＴｉメッセージのソースおよび宛先アドレスを交換し、すなわち、ＨｏＴメッセージのソース・アドレスはＣＮのＩＰアドレスであり、宛先アドレスはＭＮのＩＰアドレスである。さらに、ＨｏＴメッセージは、受信したホーム開始クッキーおよび生成されたホーム・キー生成トークンを含み、ＨｏＴに使用されるＭＮのホーム・アドレスがＬＭＡ１にアンカーされるため、ホーム・エージェントを介してＬＭＡ１からＣＮに伝送される。その後、ＨｏＴは、ホーム・エージェントによってＰＭＩＰａに転送され、ＰＭＩＰａはＲＯ中にＭＮに代わって動作し、上記メッセージをＭＮに転送しない。

ＣｏＴメッセージは、ソース・アドレスとしてＣＮのＩＰアドレスを含み、宛先アドレスとしてＰＭＩＰａのＩＰアドレスを含み、さらに、ＣｏＴｉメッセージによって受信した気付け開始クッキーと、作成された気付けキー生成トークンとを備える。ＰＭＩＰａのアドレスが宛先アドレスに使用されるため、ＣｏＴメッセージはＰＭＩＰａに直接伝送される。

ＰＭＩＰａは、ＨｏＴおよびＣｏＴメッセージを受信した後、それ独自のＩＰアドレスでＭＮのＩＰアドレスをマッピングするために、バインディング更新を生成することができる。ＢＵメッセージはＣＮに直接伝送され、ＣＮはそれに反応して、そのバインディング・キャッシュを更新する。従って、ＣＮは、ＭＮ向けのデータ・パケットを、実際にはＰＭＩＰａのＩＰアドレスであるＭＮのＣｏＡに直接送信する。次に、ＰＭＩＰａは、ＬＭＡ２を介してこのデータ・パケットをＭＮに転送する。

結果として、ＭＮのＩＰアドレスを実際に変更せずにネットワークベースのＭＮモビリティを可能にしながら、ＣＮがＡＮ１を介して迂回することなしにデータをＡＮ２に直接送信できるように、データ・パケットを交換するためのルータが最適化される。従って、ＭＮそれ自体は気付いていないが、ＭＮもホーム・リンクを使用することなく、ＣＮにデータ・パケットを直接送信する。

しかし、ＣＮとＰＭＩＰとの間で交換されるデータ・パケットも、それぞれルーティング・ヘッダ・オプション（Ｒ．Ｈ．Ｏ．）、ホーム・アドレス・オプション（Ｈ．Ａ．Ｏ．）を含み、これは標準的なＭＩＰ動作である。具体的に言えば、ＣＮによってＰＭＩＰａに送信されるデータ・パケットは、Ｒ．Ｈ．Ｏ．内にＭＮのＩＰアドレスを含むが、ＭＮから発信されるデータ・パケットはＰＭＩＰａに到達し、それ以降、Ｈ．Ａ．Ｏ．内にＭＮのＩＰアドレスを含まなければならない。ＰＭＩＰａは、データ・パケットがネットワーク内で正しく転送されるために、いくつかの方法でＩＰパケット・ヘッダを修正するための機能を実施する必要がある。

より詳細には、図９は、本発明の一実施形態による、ＭＮにはＲＯがなかったかのように見えるための、ハンドオーバ後のデータ・パケット交換に必要なデータ・パケット・ヘッダの修正を示す。ＣＮは、実際には、ＰＭＩＰａのＩＰアドレスであるＭＮのＣｏＡ向けのデータ・パケットを伝送する。さらに、データ・パケットは、ＭＮのＩＰアドレスを有するＲ．Ｈ．Ｏ．フィールドを備える。ＰＭＩＰａはデータ・パケットを受信し、ＰＭＩＰａのＩＰアドレスと、ＭＮのＩＰアドレスであるＲ．Ｈ．Ｏ．フィールド内のＩＰアドレスとを交換する必要があり、さらに、Ｒ．Ｈ．Ｏ．フィールドを削除する必要がある。その後、ＰＭＩＰａは、ＬＭＡ２からＭＡＧ３へのトンネリング（ソース・アドレス：ＬＭＡ２、宛先アドレス：ＭＡＧ３）を含む通常のルーティング手順を実行するＬＭＡ２にデータ・パケットを転送する。次にＭＡＧ３は、データ・パケットの第２の内部ヘッダに従って、このデータ・パケットをＭＮに転送する。

他方で、ＭＮから発信されたデータ・パケットは第１にＭＡＧ３に到達し、これがデータ・パケットをＬＭＡ２にトンネリングする（ソース・アドレス：ＭＡＧ３、宛先アドレス：ＬＭＡ２）。ＬＭＡ２は、各データ・パケットの宛先アドレスおよびソース・アドレスをチェックすることによって最適化されたルート上で、通信相手ノードに向けて送られたパケットを識別することができる。さらに、ＬＭＡ２は、以前にどの通信ルートが最適化されたかに関する情報を必要とする。従って、ＣＮ１０１に向けて送られたデータ・パケットの場合、ＬＭＡ２（ＬＭＡ２内のデータ・プレーンのルーティング機能）は、Ｈ．Ａ．Ｏ．フィールド内にＭＮのＩＰアドレスを含む。さらにＬＭＡ２（ＬＭＡ２内のデータ・プレーンのルーティング機能）は、ソース・アドレス・フィールド内のＭＮのＩＰアドレスを、それ独自のＩＰアドレスと交換し、データ・パケットをＣＮの方向へ転送する。この点において、ＰＭＩＰａとルーティング機能との間に同期化が存在する可能性がある。どちらも、ＭＮのＬＭＡ、ＭＡＧ、ＣＮでの実行済みＲＯなどに関して、同じデータベースをエントリと共有することができる。さらに、ＰＭＩＰａは、ＭＮが他のＭＡＧへ移動するごとに、あるいはルート最適化が実行されるか又は既存のルート最適化が削除された後に、このデータベースを更新することができる。

ＣＮ又はＭＮが通信を終了した場合、上記終了についてすべての関与エンティティに通知することが重要である。ＰＣＣシステム、より詳細には、ＡＦは、ルート最適化が実行されたＭＮとＣＮとの間のパケット・データ・フローの終了に気付く。残念なことに、フォーリン・ネットワークのＬＭＡ２内のＰＭＩＰａは、この終了について知ることができない。こうした終了が発生すると必ず、ホーム・ネットワーク内のＰＣＣシステムの任意のエンティティ（例えば、ＰＣＥＦ）が、ＭＮ−ＣＮパケット・データ・フローの終了についてＰＭＩＰａに通知する。その結果、ＰＭＩＰａは、ＭＮに関するＣＮのバインディング・キャッシュ・エントリを削除するために、ＣＮにＢＵメッセージを送信することができる。さらに、ＬＭＡ２内のデータ・プレーン機能は、ＭＮとの間でのデータ・パケット・ヘッダの修正に関する状態を有するため、ＰＭＩＰａはこれらの状態も削除する必要がある。従って、すべてのエンティティに通知され、通信セッションの終了は最終的に完了する。

図１０は、通信相手ノードが、モバイル・ノードの移動先であるＡＮ２に接続されたネットワーク・アーキテクチャを示す。すなわち、ハンドオーバ後、ＣＮはＭＮと同じフォーリン・ネットワークに位置する。この場合、本発明の以前の実施形態に従ったハンドオーバ手順をさらに改善することができる。具体的に言えば、ＣＮがＭＮと同じローカル・モビリティ・アンカーにアンカーされるか、又はＣＮがＡＮ２の他のローカル・モビリティ・アンカーにアンカーされるという２つのサブケースが可能である。

図１０は、ＣＮ１０１が、ＭＮ１０２と同じローカル・モビリティ・アンカー、すなわちＬＭＡ２ １２１に接続されたケースを示す。本発明の実施形態に従ってルートを最適化する以前は、データ・パケット・ルートは不必要に長い。データは、ＣＮ−ＭＡＧ４−ＬＭＡ２−ＬＭＡ１−ＬＭＡ２−ＭＡＧ３−ＭＮというように、ＭＮとＣＮの間で交換される（実線を参照のこと）。ルートを最適化するために、ＰＭＩＰａ１２３は第１に、ＡＮ１のＰＣＣシステムにＲＯ関連情報を要求する。ルート最適化はＭＮおよびＣＮの通信セッションに使用されることになるという想定の下で、ＰＭＩＰａは、正のＲＯフラグおよびＳＡ−ＤＡペアを伴うメッセージを受信する。さらに、以前の実施形態に従って実際のルート最適化を開始する前に、ＰＭＩＰａ１２３は第１に、ＣＮが同じＬＭＡによってサービスを提供されているか否かをチェックする。これは、ＣＮのＩＰアドレス・プレフィクスに基づいて実行することができる。アドレス・プレフィクスがＡＮ２によってサービスを提供されている場合、ＣＮがフォーリン・ネットワークにローミングしていた場合を除き、ＣＮはＡＮ２内に配置される確立が非常に高い。例えば、ＬＭＡ２は、それ自体でサービスを提供しているノードを伴うデータベースをチェックすることができる。このデータベース内にＣＮが存在する場合、これは、ＣＮがＬＭＡ２にアンカーされていることを意味する。

図１０に示されるように、ＣＮ１０１がＬＭＡ２にアンカーされている場合、ＰＭＩＰａは以前の実施形態に従ってルート最適化を開始せず、その代わりに、ＭＮおよびＣＮに対してホスト・ルートを設定する。すなわち、ＬＭＡ２に到達するパケットは、それぞれＭＮ又はＣＮへと下方に送信されるのみであり、ＬＭＡ１ １１１へはトンネリングされない（破線を参照のこと）。

他のケースでは、ＣＮはＬＭＡ２に接続されていないが異なるＬＭＡ、すなわちＬＭＡ３ １２５に接続されており、これは図１１に示されている。ルートを最適化しないと、ＣＮおよびＭＮのトポロジー的近接に対して、データ経路の長さは再度かなり長くなる。データ・パケットは、ＣＮ−ＭＡＧ４−ＬＭＡ３−ＬＭＡ１−ＬＭＡ２−ＭＡＧ３−ＭＮと、実線で示されるように交換されることになる。

ＡＮ１内のＰＣＣシステムに、ルートが最適化可能か否かの情報を要求した後、およびＣＮがＭＮと同じＬＭＡに位置しないという否定的な決定を受けた後、ＰＭＩＰａは、ＣＮが同じネットワーク領域内に位置するか否かを判別する。ＰＭＩＰａは、これをＲＯ関連情報と共に受信したＣＮのＩＰアドレスから、そのＩＰプレフィクスとＣＮのＩＰアドレスのそれとを比較することによって認識することができる。

ＣＮが同じネットワーク領域内に位置しない場合、図７および図８に従って、本発明の以前の実施形態を実行することができる。しかし、ＣＮがＡＮ２内にあるが、ＬＭＡ２によってサービスを提供されていない（以前に決定された）場合、ＰＭＩＰａは他のＬＭＡをポーリングして、ＣＮがアンカーされているＬＭＡ、すなわち図１１に示されるようなＬＭＡ３ １２５を発見することができる。ＭＮのＩＰアドレスを伴う単純な要求は、領域内の他のＬＭＡに伝送可能であり、その結果、他のＬＭＡが、上記ＩＰアドレスを伴うＭＮにサービスを提供しているか否かをチェックする。従って、ＬＭＡ３は肯定的に応答することになる。ＬＭＡ３の識別を習得すると、ＰＭＩＰａは、ＣＮとＭＮとの間でデータ・パケットを転送するように、ＬＭＡ２とＬＭＡ３との間にトンネルをセットアップする。このトンネルをセットアップした後、データ・パケットは、トンネルを介してＬＭＡ２とＬＭＡ３との間で双方向に直接転送される（破線を参照のこと）。従って、データ・パケット・ルートを短くするために、上記実施形態に従ったルート最適化は不要である。

上記段落では、モバイル・ノードのフォーリン・ネットワークへの１回のみの移動と、対応するルート最適化について考察してきた。以下では、モバイル・ノードが他のネットワーク領域へとさらに移動した後に、さらにルートを最適化する方法について示される。ここでも、２つのケースが区別されることになる。どちらのケースでも、ＡＮ１で登録されているＭＮがＡＮ２に移動し、２つの通信相手ノードと通信しているものと想定される。ＡＮ１およびＬＭＡ１を介して迂回することなく、ＣＮ１からＭＮへのルートを短くするために、本発明の一実施形態に従ったルート最適化が実行されている。しかし、ＣＮ２との通信セッションに対しては、ルート最適化が実行されていない。その結果、ＣＮ２ １０３はＬＭＡ１およびＬＭＡ２を介してＭＮ１０２と通信するが、データ・パケットはＣＮ１ １０１とＭＮ１０２との間で、ＬＭＡ２ １２１のみを介して直接交換される。

第１のケースでは、ＭＮ１０２が、ＡＮ１、すなわちモバイル・ノードのホーム・ネットワークに逆戻りするものと想定される。これは、２つのネットワーク領域ＡＮ１およびＡＮ２を備えたネットワーク・アーキテクチャを示す図１２に例示され、ＭＮはＡＮ２からＡＮ１へと逆戻りする。ＡＮ１へ移動する前のＣＮ１およびＣＮ２への通信経路は実線で示される。ＡＮ２からＡＮ１へ移動した後には、ホーム・エージェント（ＬＭＡ１）に変更が通知され、ＣＮ１からの着信データ・パケットはＭＮの新しいトポロジー的位置、すなわちＡＮ１へと転送されることになる（ＣＮ２とＭＡＧ２との間の破線を参照のこと）ため、通常、ＣＮ２との通信のみが依然として動作することになる。しかし、通常、ＣＮ２には変更が通知されず、ＬＭＡ２へのデータ・パケットの伝送は続行されることになるため、結果としてパケット損失が生じる。

本発明の他の実施形態によれば、ＭＮ１０２がＬＭＡ１のネットワークに接続された後、ＭＮの登録を抹消するために、ＬＭＡ１はメッセージ（１）をＬＭＡ２に送信する。ＬＭＡ１は、ＲＯがこのＭＮ上で実行されたか否かに関する情報を有することができる。別の方法としては、ＬＭＡ１は、そのネットワーク領域内のＰＣＣシステムにも必要な情報を要求することができる。この登録抹消手順はネットワークベース・モビリティ（例えば、ＮｅｔＬＭＭ）の一部であり、ここでモビリティ・アンカーは登録抹消メッセージを常に古いＡＲ又はＭＡＧに送信することが想定される。発明者らのケースでは、アンカーの階層が存在するため、ＬＭＡ１（上位アンカー）がＬＭＡ２（下位アンカー）内のＭＮを登録抹消するものと想定される。

有利なことには、このメッセージ（１）は、転送ルールと共にタイマ値をさらに含む。すなわちＬＭＡ２は、それによって、所定の期間、着信データ・パケットをＣＮ１ １０１からＬＭＡ１ １１１へと転送するように指示される。この期間が満了した後、ＬＭＡ２は、ＭＮに関するすべての情報およびエントリを削除する。しかし、ＬＭＡ２にとっては、図９に従って、ＭＮのＩＰアドレスを備えるＲ．Ｈ．Ｏ．を有するそれらのデータ・パケットを変更することが必要である。従って、ＬＭＡ２は、ＣＮ１から着信するヘッダ変更データ・パケットをＬＭＡ１へと転送し、さらにここで、データはＭＡＧ２ １１３およびＭＮ１０２へとルーティングされる。その後、ＬＭＡ２は、ＭＮのＩＰアドレスとＰＭＩＰａのＩＰアドレスとの間のバインディング・キャッシュ・エントリを削除するために、バインディング更新メッセージ（２）をＣＮ１０１へ送信する。ＭＩＰｖ６に従って、ＣＮ内のＨｏＡ−ＣｏＡバインディングを削除するためのＢＵが、以前にバインディングを確立した同じノードによって送信されなければならないこと、すなわち、ＢＵがＰＭＩＰａ（ＬＭＡ２）によって送信されなければならないことに留意されたい。リターン・ルータビリティの実行に関して、ＣＮ内のバインディング・キャッシュ・エントリＨｏＡ−ＣｏＡは、特定の存続期間にわたってのみ有効である。従って、ＰＭＩＰａは、存続期間が満了する前に、リターン・ルータビリティおよび近接するＢＵの送信を実行する必要がある。存続期間が満了しない限り、ＰＭＩＰａは、リターン・ルータビリティを実行することなく、ＣＮ内のバインディング・キャッシュ・エントリを削除するためにＢＵを送信することができる。存続期間が経過した後、ＣＮは自動的にバインディング・キャッシュ・エントリを削除することになる。結果としてＣＮ１は、ホーム・エージェントＬＭＡ１にアンカーされたＭＮのＩＰアドレスに、データを直接送信する。さらに、ＬＭＡ２は、ＭＡＧ３内のＭＮの状態を削除するために、メッセージ（３）をＭＡＧ３ １２２に送信することもできる。これら２つのメッセージ（２）、（３）を送信すると同時に、ＬＭＡ２は、ＬＭＡ１に肯定応答を戻すこともできる（図示せず）。

ＡＮ１への移動後、およびＣＮ１の場合のルート最適化後のデータ経路は、ＣＮ１およびＣＮ２それぞれについて破線で示されている。

図１３は、さらにＭＮが、ホーム・ネットワークとは異なる他のネットワーク領域ＡＮ３へ移動するケースを示す。以前のケースと同様に、ＭＮは２つの通信相手ノードＣＮ１およびＣＮ２と通信する。ＭＮが新しいネットワークＡＮ３およびＬＭＡ３に接続された後、ＬＭＡ３は、ＭＮのホーム・モビリティ・アンカー（ＬＭＡ１）に、ＡＮ３への移動を通知する（１）。従って、ここでＬＭＡ１は、ＭＮのホーム・アドレスに向けて送られたデータ・パケットを、ＡＮ３内のＭＮの新しい気付けアドレスに転送できるようになる。すなわち、ＣＮ２からの通信データは、ＬＭＡ１からＬＭＡ３へ、およびここからＭＡＧ４を介してＭＮへと転送される（破線を参照のこと）。しかし、ＣＮ１からのデータは再度ＬＭＡ２に到達し、これによってデータ・パケット損失が引き起こされる。これを避けるために、図１２に関する実施形態と同様に、ここでＬＭＡ１は、ＬＭＡ２内のＭＮを登録抹消するために、登録抹消メッセージ（２）をＬＭＡ２に送信する。有利なことに、上記メッセージは、ここでもＬＭＡ２に関する時間値およびルーティング指示を含むことができる。ルーティング指示は、受信した時間値によって定義された所定の期間にわたって、着信するトラフィックをＣＮ１からＬＭＡ１へと転送するように、ＬＭＡ２にプロンプトを出す。その後ＬＭＡ２は、ＭＮのアドレスとＰＭＩＰａとの間の関連するバインディング・キャッシュ・エントリを削除するために、ＢＵメッセージ（３）をＣＮ１へ送信するようにさらにトリガされる。さらに、ＬＭＡ２は、ＭＡＧ３内のＭＮに関するアクティブな状態を削除するために、状態削除メッセージ（３’）をＭＡＧ３へ送信することができる。その結果、ＣＮ１は、ＬＭＡ１へデータ・パケットを送信し、その後ＣＮ２のトラフィックと同様に、同じデータ・パケットをＭＮへとＬＭＡ３を介して転送する。

他方で、モバイル・ノードがＬＭＡ３に接続された後、本発明の一実施形態に従って、ＰＭＩＰａはルート最適化の実行を開始する。これは、例えば、ＣＮ１およびＣＮ２との通信セッションがそのルートに関して最適化されるべきか否かに関する情報を、ＡＮ３内のＰＭＩＰａ（又はＰＣＣシステム）がＡＮ１内のＰＣＣシステムに要求する（４）ことを含意する場合がある。ＰＣＣシステムは、ＬＭＡ１の機能として示されるが、ホーム・ネットワーク内の別個のエンティティとすることもできる。従って、ＰＭＩＰａは要求された情報（４’）を受信し、ＣＮ１とのデータ経路のみが最適化されることを認識する。これでＰＭＩＰａは、ＭＮに代わってルート最適化を実行するために必要な情報（ＲＯフラグ＋ＳＡ−ＤＡペア）を保持することになるため、ＰＭＩＰａはＣＮに向かって送られるＨｏＴｉおよびＣｏＴｉメッセージを生成する。図８で説明した実施形態によれば、ＨｏＴｉおよびＣｏＴｉメッセージは、ＰＭＩＰａによって、その独自のアドレスをＭＮのＣｏＡとして、およびＭＮのＩＰアドレスをＭＮのＨｏＡとして使用することで生成される。上記のように、この結果、ＣＮ１からＨｏＴおよびＣｏＴ応答（５）が生じ、最終的に、ＭＮのＩＰアドレスをＡＮ３内のＰＭＩＰａのＩＰアドレスにバインディングするように、ＡＮ３内のＰＭＩＰａからＣＮへのＢＵメッセージ（５）が生じる。従って、ここでＣＮ１は、ＬＭＡ１を介して迂回することなく、ＬＭＡ３を介してＭＮへとデータの直接送信を開始する（破線を参照のこと）。

本発明の他の実施形態は、ハードウェアおよびソフトウェアを使用した上記種々の実施形態の実施に関する。上記本発明の種々の実施形態は、例えば、汎用プロセッサ、デジタル信号プロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）、又は他のプログラム可能論理デバイスなどのコンピューティング・デバイス（プロセッサ）を使用して、実装又は実行可能であることを理解されたい。本発明の種々の実施形態は、これらのデバイスの組み合わせによっても実行又は具体化可能である。

さらに、本発明の種々の実施形態は、プロセッサによって実行されるソフトウェア・モジュールによって、又はハードウェア内で直接実施することができる。ソフトウェア・モジュールおよびハードウェア実装の組み合わせも可能である。ソフトウェア・モジュール又は命令は、例えば、ＲＡＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、フラッシュ・メモリ、レジスタ、ハードディスク、ＣＤ−ＲＯＭ、ＤＶＤなどの任意の種類のコンピュータ読み取り可能記憶媒体上に格納することができる。

Claims (22)

1. 第１のネットワーク領域（１１０）内の第１のローカル・モビリティ・アンカー（１１１）を介して、第１のデータ・パケット・ルート上にある通信相手ノード（１０１）とデータ・パケットを交換するモバイル・ノード（１０２）のモビリティを管理するための方法であって、
   前記モバイル・ノードの接続が、前記第１のローカル・モビリティ・アンカーから第２のローカル・モビリティ・アンカー（１２１）へと変更された後、前記通信相手ノードと前記モバイル・ノードとの間の前記第１のデータ・パケット・ルートに対してルート最適化を使用するか否かに関する情報、並びに前記データ・パケットの交換に使用される前記通信相手ノードおよび前記モバイル・ノードのアドレスに関する情報を、前記第１のネットワーク領域内のポリシー制御エンティティ（１１４）に要求するステップと、
   前記通信相手ノードと前記モバイル・ノードとの間の前記第１のデータ・パケット・ルートにルート最適化が使用されることになる場合、第２のデータ・ルート上で前記第２のローカル・モビリティ・アンカーを介して前記モバイル・ノードと前記データ・パケットを交換するように、前記通信相手ノードに指示するステップとを、
   有する方法。
2. ルート最適化を使用するか否かに関する前記情報がフラグである請求項１に記載の方法。
3. 前記ルート最適化が、前記第２のローカル・モビリティ・アンカーのアドレスを前記モバイル・ノードの気付けアドレスとして使用することによって、および前記モバイル・ノードのアドレスを前記モバイル・ノードのホーム・アドレスとして使用することによって、前記モバイル・ノードの代わりに前記第２のローカル・モビリティ・アンカーによって実行される請求項１又は２に記載の方法。
4. 情報を要求する前記ステップと、前記通信相手ノードに指示する前記ステップとが、前記第２のローカル・モビリティ・アンカーによって実行される請求項１から３のいずれか１つに記載の方法。
5. 前記第２のローカル・モビリティ・アンカーが、第２のネットワーク領域（１２０）内に配置され、情報を要求する前記ステップが、前記第２のネットワーク領域内の第２のポリシー制御エンティティによって実行され、
   前記第２のローカル・モビリティ・アンカーによって、前記第２のポリシー制御エンティティに、情報を要求する前記ステップを実行するように指示するステップと、
   前記第２のポリシー制御エンティティで前記要求された情報を受信すると、前記要求された情報を前記第２のローカル・モビリティ・アンカーに転送するステップとを、
   更に有する請求項１から３のいずれか１つに記載の方法。
6. 前記第１のネットワーク領域内の前記ポリシー制御エンティティが、前記モバイル・ノードが前記通信相手ノードと前記データ・パケットの交換を開始している最中又は交換を開始した後、前記第１のデータ・パケット・ルートに対してルート最適化を使用するか否かを決定する請求項１から５のいずれか１つに記載の方法。
7. 前記第１のネットワークが前記モバイル・ノードの前記ホーム・ネットワークであり、前記第１のローカル・モビリティ・アンカーが前記モバイル・ノードの前記ホーム・エージェントである請求項１から６のいずれか１つに記載の方法。
8. 前記第２のローカル・モビリティ・アンカーで、前記第２のデータ・パケット・ルート上で前記通信相手ノードからデータ・パケットを受信するステップであって、前記データ・パケットは前記モバイル・ノードのアドレスを備えるルーティング・ヘッダ・フィールドを含むステップと、
   各データ・パケットについて、前記モバイル・ノードの前記アドレスを前記データ・パケットの前記宛先アドレスとして前記ルーティング・ヘッダ・フィールド内に含めること、および前記ルーティング・ヘッダ・フィールドを削除することによって、前記データ・パケットのヘッダを変更するステップとを、
   有する請求項１から７のいずれか１つに記載の方法。
9. 前記第２のローカル・モビリティ・アンカーで、前記第２のデータ・パケット・ルート上で前記モバイル・ノードからデータ・パケットを受信するステップと、
   各データ・パケットについて、前記第２のローカル・モビリティ・アンカーのアドレスを前記データ・パケットの前記ソース・アドレスとして含めること、および前記モバイル・ノードの前記アドレスを前記データ・パケット・ヘッダのオプション・フィールドに含めることによって、前記データ・パケットのヘッダを変更するステップとを、
   有する請求項１から８のいずれか１つに記載の方法。
10. 前記通信相手ノードが、前記第２のローカル・モビリティ・アンカーを介して前記第２のデータ・ルート上で前記モバイル・ノードと前記データ・パケットを交換する間に、前記モバイル・ノードが前記第２のローカル・モビリティ・アンカーから前記第１のローカル・モビリティ・アンカーへと前記接続を変更し、
    前記第１のローカル・モビリティ・アンカーへの前記モバイル・ノードの接続が確立された後、所定の時間、前記第２のデータ・パケット・ルート上で着信するデータ・パケットを前記第１のローカル・モビリティ・アンカーに転送するように、前記第１のローカル・モビリティ・アンカーによって、前記第２のローカル・モビリティ・アンカーに指示するステップと、
    前記第１のローカル・モビリティ・アンカーを介して前記第１のデータ・パケット・ルート上で前記モバイル・ノードと前記データ・パケットを交換するように、前記通信相手ノードに指示するステップとを、
    更に有する請求項１から９のいずれか１つに記載の方法。
11. 前記通信相手ノードが、前記第２のローカル・モビリティ・アンカーを介して前記第２のデータ・ルート上で前記モバイル・ノードとデータ・パケットを交換する間に、前記モバイル・ノードが、前記第２のローカル・モビリティ・アンカーから第３のネットワーク領域内の第３のローカル・モビリティ・アンカーへと接続を変更し、
    前記第３のローカル・モビリティ・アンカーへの前記モバイル・ノードの接続が確立された後、所定の時間、前記第２のデータ・パケット・ルート上で着信するデータ・パケットを前記第１のローカル・モビリティ・アンカーに転送するように、前記第１のローカル・モビリティ・アンカーによって、前記第２のローカル・モビリティ・アンカーに指示し、前記第１のローカル・モビリティ・アンカーを介して前記第１のデータ・パケット・ルート上で前記モバイル・ノードと前記データ・パケットを交換するように、前記通信相手ノードに指示するステップと、
    前記通信相手ノードと前記モバイル・ノードとの間の前記第１のデータ・パケット・ルートに対してルート最適化を使用するか否かに関する情報、並びに前記データ・パケットの交換に使用される前記通信相手ノードおよび前記モバイル・ノードのアドレスに関する情報を、前記第１のネットワーク領域内の前記ポリシー制御エンティティに要求するステップと、
    前記通信相手ノードと前記モバイル・ノードとの間の前記第１のデータ・パケット・ルートにルート最適化が使用されることになる場合、第３のデータ・ルート上で前記第３のローカル・モビリティ・アンカーを介して前記モバイル・ノードと前記データ・パケットを交換するように、前記通信相手ノードに指示するステップとを、
    更に有する請求項１から１０のいずれか１つに記載の方法。
12. 前記ＣＮからの前記第２のパケット・データ・ルート上で着信する前記データ・パケットが、前記モバイル・ノードのアドレスを有するルーティング・ヘッダ・フィールドを含み、
    各データ・パケットについて、前記データ・パケットを前記第１のローカル・モビリティ・アンカーに転送する前に、前記モバイル・ノードの前記アドレスを前記データ・パケットの前記宛先アドレスとして前記ルーティング・ヘッダ・フィールドに含めること、および前記ルーティング・ヘッダ・フィールドを削除することによって、前記第２のローカル・モビリティ・アンカーによって前記データ・パケットのヘッダを変更するステップを更に有する請求項１０又は１１に記載の方法。
13. ルート最適化が前記第１のデータ・パケット・ルートに使用されることになる場合には、前記通信相手ノードが前記第２のローカル・モビリティ・アンカーに接続されているか否かを判別するステップと、
    前記通信相手ノードが前記第２のローカル・モビリティ・アンカーに接続されている場合には、前記第２のローカル・モビリティ・アンカーを介して前記第２のデータ・ルート上で前記モバイル・ノードと前記データ・パケットを交換するように前記通信相手ノードに指示するのではなく、前記第２のローカル・モビリティ・アンカーを介して前記第２のデータ・ルート上で前記モバイル・ノードおよび前記通信相手ノードと前記データ・パケットを交換するように、前記第２のローカル・モビリティ・アンカーに指示するステップと、
    前記通信相手ノードが前記第２のローカル・モビリティ・アンカーに接続されていない場合には、前記通信相手ノードが前記第２のネットワーク領域内に位置しているか否かを判別するステップと、
    前記第２のローカル・モビリティ・アンカーを介して第２のデータ・ルート上で前記モバイル・ノードと前記データ・パケットを交換するように前記通信相手ノードに指示する前記ステップが、前記通信相手ノードが前記第２のネットワーク領域内に位置していない場合に実行され、
    前記通信相手ノードが前記第２のネットワーク領域内に位置している場合には、前記第２のネットワーク領域内で前記通信相手ノードが接続されている第３のローカル・モビリティ・アンカーを決定するステップと、
    前記第３のローカル・モビリティ・アンカーを決定すると、前記第２のローカル・モビリティ・アンカーを介して第２のデータ・ルート上で前記モバイル・ノードと前記データ・パケットを交換するように前記通信相手ノードに指示するのではなく、前記第２および第３のローカル・モビリティ・アンカーを介して第３のデータ・パケット・ルート上で、前記モバイル・ノードおよび前記通信相手ノードと前記データ・パケットを交換するように、前記第２および第３のローカル・モビリティ・アンカーに指示するステップとを、
    更に有する請求項１から１０のいずれか１つに記載の方法。
14. 第１のネットワーク領域（１１０）内のポリシー制御エンティティ（１１４）であって、
    モバイル・ノード（１０２）と通信相手ノード（１０１）との間で交換されることになるデータ・パケットが存在する第１のデータ・パケット・ルートに対してルート最適化を使用するか否かを決定するように構成されたプロセッサであって、前記決定が、前記通信相手ノードへの前記モバイル・ノードの接続を確立中又は確立後に実行されるプロセッサと、
    ルート最適化のための前記決定に関する情報を要求するために、ネットワーク・エンティティから要求を受信するように構成された受信器と、
    ルート最適化のための前記決定に関する情報を前記ネットワーク・エンティティに送信するように構成された送信器とを、
    有するポリシー制御エンティティ。
15. 前記プロセッサが、前記第１のデータ・パケット・ルートに関する少なくとも１つのポリシールールを確立するように更に構成され、前記第１のデータ・パケット・ルートに関する前記少なくとも１つのポリシールールに、ルート最適化のための前記決定に関する情報を含めるように更に構成された請求項１４に記載のポリシー制御エンティティ。
16. 前記ポリシー制御エンティティが、請求項１から１３のいずれか１つに記載の方法のステップを実行するか又は関与するための手段を更に有する請求項１４又は１５に記載のポリシー制御エンティティ。
17. ルート最適化を実行するためのローカル・モビリティ・アンカー（１２１）であって、モバイル・ノード（１０２）が、第１のネットワーク領域（１１０）内の第１のローカル・モビリティ・アンカー（１１１）を介して、第１のデータ・パケット・ルート上で通信相手ノード（１０１）とデータ・パケットを交換し、前記モバイル・ノードの前記接続が、前記第１のローカル・モビリティ・アンカーから前記ローカル・モビリティ・アンカーに変更され、
    前記通信相手ノードと前記モバイル・ノードとの間の前記第１のデータ・パケット・ルートに対してルート最適化を使用するか否かに関する情報と、前記データ・パケットの交換に使用される前記通信相手ノードおよび前記モバイル・ノードのアドレスに関する情報とを要求するために、前記第１のネットワーク領域内のポリシー制御エンティティ（１１４）に対する要求メッセージを生成するように構成されたプロセッサと、
    前記モバイル・ノードの前記接続を前記第１のローカル・モビリティ・アンカーから前記ローカル・モビリティ・アンカーに変更した後、前記第１のネットワーク領域内の前記ポリシー制御エンティティに前記要求メッセージを送信するように構成された送信器と、
    ルート最適化を使用するか否か、並びに前記通信相手ノードおよび前記モバイル・ノードのアドレスに関する前記要求された情報を受信するように構成された受信器とを、
    有し、
    前記プロセッサが、前記通信相手ノードと前記モバイル・ノードとの間の前記第１のデータ・パケット・ルートにルート最適化が使用されることになる場合、前記ローカル・モビリティ・アンカーを介して第２のデータ・ルート上で前記モバイル・ノードと前記データ・パケットを交換するよう、前記通信相手ノードに対する命令通知を生成するように更に構成され、
    前記送信器が、前記通信相手ノードに対して前記命令通知を送信するように更に構成されるローカル・モビリティ・アンカー。
18. 前記ルート最適化が、前記ローカル・モビリティ・アンカーのアドレスを前記モバイル・ノードの気付けアドレスとして使用すること、および前記モバイル・ノードのアドレスを前記モバイル・ノードのホーム・アドレスとして使用することにより、前記モバイル・ノードの代わりに前記ローカル・モビリティ・アンカーによって実行される請求項１７に記載のローカル・モビリティ・アンカー。
19. 前記受信器が、前記第２のデータ・パケット・ルート上で前記通信相手ノードからデータ・パケットを受信するように更に構成され、前記データ・パケットが、前記モバイル・ノードのアドレスを有するにルーティング・ヘッダ・フィールドを含み、
    前記プロセッサが、前記モバイル・ノードの前記アドレスを、受信したそれぞれのデータ・パケットの前記宛先アドレスとして前記ルーティング・ヘッダ・フィールドに含めること、および前記ルーティング・ヘッダ・フィールドを削除することによって、受信したそれぞれのデータ・パケットのヘッダを変更するように更に構成され、
    前記送信器が、受信したそれぞれのデータ・パケットを前記モバイル・ノードに送信するように更に構成される請求項１７又は１８に記載のローカル・モビリティ・アンカー。
20. 前記受信器が、前記第２のデータ・パケット・ルート上で前記モバイル・ノードからデータ・パケットを受信するように更に構成され、
    前記プロセッサが、前記ローカル・モビリティ・アンカーのアドレスを前記データ・パケットの前記ソース・アドレスとして含めること、および前記モバイル・ノードの前記アドレスを前記データ・パケットのオプション・フィールドに含めることによって、受信したそれぞれのデータ・パケットのヘッダを変更するように更に構成される請求項１７から１９のいずれか１つに記載のローカル・モビリティ・アンカー。
21. 前記ローカル・モビリティ・アンカーが、請求項１から１３のいずれか１つに記載の方法のステップを実行又は関与するための手段を更に有する請求項１７から２０のいずれか１つに記載のローカル・モビリティ・アンカー。
22. 請求項１４から１６のいずれか１つに記載のポリシー制御エンティティおよび／又は請求項１７から２１に記載のローカル・モビリティ・アンカーを備える通信システム。