JP2008146632A

JP2008146632A - キーキャッシング、ＱｏＳおよびメディア独立事前認証のマルチキャスト拡張

Info

Publication number: JP2008146632A
Application number: JP2007273266A
Authority: JP
Inventors: Ashutosh Dutta; アシュトシュ・ダッタ; Victor Fajardo; ビクター・ファジャード; Yoshihiro Oba; 義洋大場; Kenichi Yanai; 謙一谷内
Original assignee: Toshiba Corp; Telcordia Technologies Inc
Current assignee: Toshiba Corp; Iconectiv LLC
Priority date: 2006-10-21
Filing date: 2007-10-22
Publication date: 2008-06-26

Abstract

【課題】キーキャッシング、ＱｏＳおよびメディア独立事前認証のマルチキャスト拡張
【解決手段】本出願は、特に、既存のモビリティ管理プロトコルおよびモビリティ最適化機構に関する問題に対処する可能性を有する新しいハンドオーバ最適化機構である、メディア独立事前認証（ＭＰＡ）フレームワークに対する、キーキャッシング、ＱｏＳおよびマルチキャストの拡張と改善するものである。ＭＰＡは、任意のリンク層を介して、任意のモビリティ管理プロトコルと共に動作する、モバイル支援のセキュアなハンドオーバ最適化方式である。
【選択図】図４

Description

背景説明：
本出願は、以下の米国特許出願、すなわち「メディア独立事前認証のフレームワーク（A Framework of Media Independent Pre-Authentication）」という名称の、２００６年２月２日に出願した、米国出願第１１／３０７３６２号明細書、「メディア独立事前認証のフレームワーク（ＰＡＮＡのサポート）（Framework of Media Independent Pre-Authentication （Support for PANA)）」という名称の、２００６年３月９日に出願した、米国出願第１１／３０８１７５号明細書、「メディア独立事前認証改善のフレームワーク：切換えの失敗およびスイッチバックの考慮を含む）（Framework of Media-independent Pre-Authentication Improvements: including Considerations for Failed Switching and Switchback）」という名称の、２００６年４月１４日に出願した、米国出願第１１／２７９８５６号明細書の内容全体を参照として組み込むものである。

ネットワーク及びインターネット（登録商標）プロトコル：
多様なコンピュータネットワークがあり、インターネットは最も有名である。インターネットは、コンピュータネットワークの世界規模のネットワークである。今日、インターネットは、何百万人ものユーザが利用可能な、公衆の自律的ネットワークである。インターネットは、ＴＣＰ／ＩＰ（すなわち、伝送制御プロトコル／インターネットプロトコル）と呼ばれる１組の通信プロトコルを使って各ホストを接続する。インターネットは、インターネットバックボーンとして呼ばれる通信インフラストラクチャを有する。インターネットバックボーンへのアクセスは大部分企業及び個人へのアクセスを再販するインターネットサービスプロバイダ（ＩＳＰ）によって制御される。

ＩＰ（インターネットプロトコル）に関して、これは、ネットワーク上である装置（電話機、ＰＤＡ［携帯情報端末］、コンピュータなど）から別の装置にデータを送るためのプロトコルである。今日、ＩＰｖ４、ＩＰｖ６などを含めて、様々なＩＰのバージョンがある。ネットワーク上の各ホスト装置は、独自の一意の識別子である少なくとも１つのＩＰアドレスを有する。

ＩＰはコネクションレス型プロトコルである。通信時の端点間接続は連続的ではない。ユーザがデータ又はメッセージを送信し、又は受信するとき、データ又はメッセージは、パケットと呼ばれる構成要素に分割される。各パケットは、独立のデータ単位として扱われる。

インターネットなどのネットワークを介した各点間の伝送を標準化するために、ＯＳＩ（開放型システム間相互接続）モデルが確立された。ＯＳＩモデルは、ネットワーク中の２点間の通信プロセスを７つの階層に分け、各層（レイヤ）は独自の機能セットを付加する。各装置は、送信側端点では各層を通る下方への流れがあり、受信側端点では各層を通る上方への流れがあるようにメッセージを処理する。７つの機能層を提供するプログラミング及び／又はハードウェアは、通常、デバイスオペレーティングシステム、アプリケーションソフトウェア、ＴＣＰ／ＩＰ及び／又は他のトランスポート及びネットワークプロトコル、ならびに他のソフトウェア及びハードウェアの組み合わせである。

通常、上位４層は、メッセージがユーザから、又はユーザへ渡されるときに使用され、下位３層は、メッセージが装置（ＩＰホスト装置など）を通過するときに使用される。ＩＰホストは、サーバ、ルータ、ワークステーションなど、ＩＰパケットを送受信することのできるネットワーク上の任意の装置である。他の何らかのホストに向けられているメッセージは、各上位層には渡されず、この他のホストに転送される。ＯＳＩモデルの各層を以下に列記する。第７層（すなわち、アプリケーション層）は、例えば、通信相手が識別され、サービス品質が識別され、ユーザ認証及びプライバシが考慮され、データ構文に対する制約条件が識別される層である。第６層（すなわち、プレゼンテーション層）は、例えば、着信及び発信データをあるプレゼンテーション形式から別の形式に変換する層である。第５層（すなわち、セッション層）は、例えば、アプリケーション間の会話、交換及びダイアログをセットアップし、調整し、終了させる層である。第４層（すなわち、トランスポート層）は、例えば、エンドツーエンド制御及び誤りチェックなどを管理する層である。第３層（すなわち、ネットワーク層）は、例えば、経路指定や転送などを処理する層である。第２層（すなわち、データリンク層）は、例えば、物理レベルでの同期を提供し、ビットスタッフィングを行い、伝送プロトコルの知識及び管理などを提供する層である。米国電気電子技術者協会（ＩＥＥＥ）では、データリンク層を、物理層との間のデータ転送を制御するＭＡＣ（媒体アクセス制御）層と、ネットワーク層とのインターフェースを取り、コマンドを解釈し、誤り回復を行うＬＬＣ（論理リンク制御）層という、２つのさらなる副層（サブレイヤ）に細分する。第１層（すなわち、物理層）は、例えば、物理レベルにおいてネットワークを介してビットストリームを伝達する層である。ＩＥＥＥでは、物理層を、ＰＬＣＰ（物理層収束手順）副層とＰＭＤ（物理媒体依存）副層とに細分する。

無線ネットワーク：
無線ネットワークは、例えば、セルラ及び無線電話機、ＰＣ（パーソナルコンピュータ）、ラップトップコンピュータ、装着型コンピュータ、コードレス電話機、ポケットベル、ヘッドセット、プリンタ、ＰＤＡなど、多種多様なモバイル機器を組み込むことができる。例えば、モバイル機器は、音声及び／又はデータの高速無線伝送を確保するデジタルシステムを含むことができる。典型的なモバイル機器は、次の構成要素の一部又は全部、即ちトランシーバ（すなわち、例えば、送信機、受信機及び、必要に応じて、他の機能が統合されたシングルチップ送受信機などを含む、送信機及び受信機）、アンテナ、プロセッサ、１つ又は複数の音声変換器（例えば、音声通信用機器でのスピーカやマイクロホンなど）、電磁データ記憶（データ処理が提供される機器の場合などでの、ＲＯＭ、ＲＡＭ、デジタルデータ記憶など）、メモリ、フラッシュメモリ、フルチップセット又は集積回路、インターフェース（ＵＳＢ、ＣＯＤＥＣ、ＵＡＲＴ、ＰＣＭなど）及び／又は同種のものを含む。

モバイルユーザが無線接続を介してローカルエリアネットワーク（ＬＡＮ）に接続することのできる無線ＬＡＮ（ＷＬＡＮ）が、無線通信に用いられ得る。無線通信には、例えば、光、赤外線、電波、マイクロ波などの電磁波を介して伝搬する通信などが含まれ得る。現在、ブルートゥース（登録商標）、ＩＥＥＥ８０２．１１、ＨｏｍｅＲＦなど、様々なＷＬＡＮ標準が存在する。

一例として、ブルートゥース製品は、モバイルコンピュータ、モバイル電話機、携帯式ハンドヘルド機器、携帯情報端末（ＰＤＡ）、及び他のモバイル機器の間のリンク、ならびにインターネットへの接続を提供するのに使用できる。ブルートゥースは、モバイル機器が、短距離無線接続を使って、相互に、また非モバイル機器と、どのようにして容易に相互接続し合うことができるかを詳述するコンピュータ及び電気通信業界仕様である。ブルートゥースは、ある機器と別の機器との間でデータを同期させ、整合させ続けることを必要とする、様々なモバイル機器の普及から生じるエンドユーザ問題に対処して、異なるベンダからの装置を相互にシームレスに動作させるデジタル無線プロトコルを作成する。ブルートゥース機器は、共通の命名概念に従って命名できる。例えば、ブルートゥース機器は、ブルートゥース機器名（ＢＤＮ）又は一意のブルートゥース機器アドレス（ＢＤＡ）に関連付けられた名前を持ち得る。また、ブルートゥース機器は、インターネットプロトコル（ＩＰ）ネットワークに参加することもできる。ブルートゥース機器がＩＰネットワーク上で機能する場合、この機器は、ＩＰアドレス及びＩＰ（ネットワーク）名を備え得る。よって、ＩＰネットワークに参加するように構成されたブルートゥース機器は、ＢＤＮ、ＢＤＡ、ＩＰアドレス及びＩＰ名などを含むことができる。「ＩＰ名」という用語は、インターフェースのＩＰアドレスに対応する名前を指す。

ＩＥＥＥ標準であるＩＥＥＥ８０２．１１は、無線ＬＡＮ及び機器の技術の仕様を定める。８０２．１１を使えば、各単一基地局がいくつかの機器をサポートする無線ネットワークが実現できる。いくつかの例では、機器に無線ハードウェアが事前装備されていることもあり、ユーザが、アンテナを含み得る、カードなどの別個のハードウェアをインストールすることもできる。例えば、８０２．１１で使用される機器は、通常、機器がアクセスポイント（ＡＰ）であるか、移動局（ＳＴＡ）であるか、ブリッジであるか、ＰＣＭＣＩＡカードであるか、それとも別の機器であるか否かを問わず、無線トランシーバ、アンテナ、及びネットワークにおける各点間のパケットの流れを制御するＭＡＣ（媒体アクセス制御）層という３つの注目すべき要素を含む。

更に、いくつかの無線ネットワークでは、複数インターフェース機器（ＭＩＤ）が利用できる。ＭＩＤは、ブルートゥースインターフェースと８０２．１１インターフェースなど、２つの独立のネットワークインターフェースを含むことができ、よって、ＭＩＤが２つの別個のネットワーク上に参加すると同時に、ブルートゥース機器ともインターフェースすることが可能になる。ＭＩＤは、ＩＰアドレス、及びＩＰアドレスに関連付けられた共通ＩＰ（ネットワーク）名を持つことができる。

無線ネットワーク機器には、それだけに限らないが、ブルートゥース機器、複数インターフェース機器（ＭＩＤ）、８０２．１１ｘ機器（８０２．１１ａ、８０２．１１ｂ、８０２．１１ｇ機器などを含む、ＩＥＥＥ８０２．１１機器）、ＨｏｍｅＲＦ（家庭内無線周波数）機器、Ｗｉ−Ｆｉ（Wireless Fidelity）機器、ＧＰＲＳ（汎用パケット無線システム）機器、３Ｇセルラ機器、２．５Ｇセルラ機器、ＧＳＭ（移動通信用グローバルシステム）機器、ＥＤＧＥ（Enhanced Data for GSM Evolution）機器、ＴＤＭＡ型（時分割多重接続）機器、又はＣＤＭＡ２０００を含むＣＤＭＡ型（符号分割多重接続）機器が含めることができる。各ネットワーク機器は、それだけに限らないが、ＩＰアドレス、ブルートゥース機器アドレス、ブルートゥース共通名、ブルートゥースＩＰアドレス、ブルートゥースＩＰ共通名、８０２．１１ＩＰアドレス、８０２．１１ＩＰ共通名、ＩＥＥＥＭＡＣアドレスを含む、様々な種類のアドレスを含むことができる。

また、無線ネットワークは、例えば、モバイルＩＰ（インターネットプロトコル）システム、ＰＣＳシステム、及び他のモバイルネットワークシステムにおいて見られる方法及びプロトコルも関与できる。モバイルＩＰでは、これに、インターネット技術標準化委員会（ＩＥＴＦ）によって作成された標準通信プロトコルが関与する。モバイルＩＰでは、モバイル機器ユーザは、これらの一旦割り当てられたＩＰアドレスを維持しつつ、各ネットワークにまたがって移動することができる。コメント要求（ＲＦＣ）３３４４を参照されたい。（注：ＲＦＣはインターネット技術標準化委員会（ＩＥＴＦ）の公式文書である。）モバイルＩＰは、インターネットプロトコル（ＩＰ）を拡張し、モバイル機器のホームネットワーク外部に接続するときに、モバイル機器にインターネットトラフィックを転送する手段を付加する。モバイルＩＰは、各モバイルノードに、これのホームネットワーク上のホームアドレスと、ネットワーク及びこれのサブネット内の機器の現在位置を識別する気付アドレス（ＣｏＡ）を割り当てる。機器が異なるネットワークに移動すると、機器は、新しい気付アドレスを受け取る。ホームネットワーク上のモビリティエージェントは、各ホームアドレスを、これの気付アドレスと関連付けることができる。モバイルノードは、インターネット制御メッセージプロトコル（ＩＣＭＰ）などを使って、これの気付アドレスを変更する都度ホームエージェントにバインディング更新を送ることができる。

（例えば、モバイルＩＰ外部などの）基本的なＩＰ経路指定において、経路指定機構は、各ネットワークノードが、常に、インターネットなどへの一定の接続点を有し、かつ各ノードのＩＰアドレスが、これが接続されているネットワークリンクを識別するという仮定を利用する。本明細書において、「ノード」という用語は、例えば、データ伝送のための再配信点や端点などを含むことができ、他のノードへの通信を認識し、処理し、及び／又は転送することのできる接続点を含む。例えば、インターネットルータは、機器のネットワークを識別するＩＰアドレスなどを調べることができる。次いで、ネットワークレベルにおいて、ルータは、特定のサブネットを識別するビットセットを調べることができる。次いで、サブネットレベルにおいて、ルータは、特定の機器を識別するビットセットを調べることができる。典型的なモバイルＩＰ通信の場合、ユーザが、例えば、インターネットなどからモバイル機器を切断し、これを新しいサブネットで再接続しようとする場合、機器は、新しいＩＰアドレス、適正なネットマスク及びデフォルトのルータを用いて再構成する必要がある。そうでなければ、経路指定プロトコルは、パケットを適正に配信することができないはずである。

メディア独立ハンドオーバサービス：
「ローカルおよびメトロポリタンエリアネットワークのためのＩＥＥＥ規格草案：メディア独立ハンドオーバサービス（Draft IEEE Standard for Local and Metropolitan Area Networks: Media Independent Handover Services）」という名称の、２００６年９月、Ｉ．Ｅ．Ｅ．Ｅ．Ｐ８０２．２１／Ｄ．０１．０９では、特に、８０２システムとセルラシステムの間のハンドオーバを最適化する８０２メディアアクセス独立機構を規定している。Ｉ．Ｅ．Ｅ．Ｅ．８０２．２１規格は、異種混交８０２システム間のハンドオーバの最適化を可能にし、８０２システムとセルラシステムの間のハンドオーバを円滑化し得る、拡張可能なメディアアクセス独立機構を定義している。背景参照と教育のため、以下に、上記Ｉ．Ｅ．Ｅ．Ｅ．８０２．２１の各部分を転載する。

ＩＥＥＥ８０２．２１（メディア独立ハンドオーバ）規格の意図は、異種混交メディア間のハンドオーバを最適化するために、上位層にリンク層インテリジェンスと他の関連するネットワーク情報を提供する仕様を策定することである。これは、３ＧＰＰ、３ＧＰＰ２およびＩＥＥＥ８０２規格ファミリの有線と無線両方のメディアによって規定されるリンクを含む。本明細書では、特に明記しない限り、「メディア」とは、通信の感覚的態様（オーディオ、ビデオなど）ではなく、電気通信システムにアクセスする方法／モード（ケーブル、電波、衛星など）を指すことに留意されたい。例えば、「ローカルおよびメトロポリタンエリアネットワークのためのＩＥＥＥ規格草案：メディア独立ハンドオーバサービス（Draft IEEE Standard for Local and Metropolitan Area Networks: Media Independent Handover Services）」という名称の、２００６年９月、Ｉ．Ｅ．Ｅ．Ｅ．Ｐ８０２．２１／Ｄ．０１．０９の１．１を参照されたい。この文書の内容全体は、前述の仮出願のパートＣに全文が組み込まれていることをもって、本明細書において、本特許出願に、これの一部として組み込まれるものである。同文書を参照されたい。

例示的アーキテクチャ：
図５に、クライアント機器の通信先である無線アクセスポイントを含むいくつかの例示的、非限定的実装形態において用いられ得る、いくつかの例示的アーキテクチャ構成要素を示す。これに関して、図５には、全体として２１で示す無線ローカルエリアネットワーク（ＷＬＡＮ）に接続された例示的有線ネットワーク２０が示されている。ＷＬＡＮ２１は、アクセスポイント（ＡＰ）２２と、いくつかのユーザ局２３、２４を含む。例えば、有線ネットワーク２０は、インターネットまたは企業データ処理ネットワークを含み得る。例えば、アクセスポイント２２は無線ルータとすることができ、ユーザ局２３、２４は、携帯型コンピュータ、個人用デスクトップコンピュータ、ＰＤＡ、携帯型ＩＰ上の音声電話機および／または他の機器などとすることができる。アクセスポイント２２は、有線ネットワーク２１にリンクされたネットワークインターフェース２５と、ユーザ局２３、２４と通信を行う無線トランシーバを有する。例えば、無線トランシーバ２６は、ユーザ局２３、２５との無線またはマイクロ波周波数通信のためのアンテナ２７を含み得る。また、アクセスポイント２２は、プロセッサ２８、プログラムメモリ２９、およびランダムアクセスメモリ３１も有する。ユーザ局２３は、アクセスポイント局２２との通信のためのアンテナ３６を含む無線トランシーバ３５を有する。同様に、ユーザ局２４も、アクセスポイント２２との通信のための無線トランシーバ３８とアンテナ３９を有する。例として、いくつかの実施形態では、かかるアクセスポイント（ＡＰ）内でオーセンティケータを用いることもでき、かつ／あるいは、移動ノードまたはユーザ局内でサプリカントまたはピアを用いることもできる。

図６に、例えば、アクセスポイント、ユーザ局、移動ノード、実施形態によっては別のノードなどといった機器によって実行されるべき、コンピュータ化プロセスステップを実施するのに使用され得る例示的コンピュータまたは制御ユニットを示す。いくつかの実施形態では、コンピュータまたは制御ユニットは、中央演算処理装置（ＣＰＵ）３２２を含み、ＣＰＵ３２２は、バス３２６を介して（１台または複数の）入力／出力（入出力）デバイス３２４一式とやりとりすることができる。入出力デバイス３２４には、例えば、キーボード、モニタ、および／または他の機器が含まれ得る。ＣＰＵ３２２は、バス３２６を介してコンピュータ可読媒体（例えば、従来の揮発性または不揮発性データ記憶装置など）３２８（以下「メモリ３２８」という）とやりとりすることができる。ＣＰＵ３２２、入出力デバイス３２４、バス３２６、およびメモリ３２８の間の対話は、当分野で既知のようなものとすることができる。メモリ３２８は、例えば、データ３３０などを含み得る。また、メモリ３２８は、ソフトウェア３３８も格納し得る。ソフトウェア３３８は、プロセスステップを実施するいくつかのモジュール３４０を含み得る。これらのモジュールを実施するのには従来のプログラミング技術が使用され得る。また、メモリ３２８は、上記および／または他の（１つまたは複数の）データファイルも格納し得る。いくつかの実施形態では、本明細書で述べる様々な方法が、コンピュータシステムと共に使用するためのコンピュータプログラム製品によって実施され得る。この実装形態には、例えば、コンピュータ可読媒体（ディスケット、ＣＤ−ＲＯＭ、ＲＯＭなど）に記録され、またはモデムなどのインターフェース装置を介してコンピュータシステムに送信可能な一連のコンピュータ命令などが含まれ得る。通信媒体は、実質的に有形のもの（通信回線など）とすることもでき、かつ／または実質的に無形のもの（マイクロ波、光、赤外線などを使った無線媒体など）とすることもできる。コンピュータ命令は、様々なプログラミング言語で書くことができ、かつ／または、半導体デバイス（チップや回路など）、磁気デバイス、光デバイス、および／または他のメモリデバイスといった（１つまたは複数の）メモリデバイスに格納することもできる。様々な実施形態において、送信には、任意の適切な通信技術を使用し得る。

参考文献：
以下の各参考文献の全文を、参照として本明細書に組み込む。

１． Bradner, S., "The Internet Standards Process − Revision 3", BCP 9, RFC 2026, October 1996 (Referred to herein as [RFC2026]).
２． Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 3978, March 2005(Referred to herein as [RFC3978]).
３． Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002 (Referred to herein as [RFC3344]).
４． Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004 (Referred to herein as [RFC3748]).
５． Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004 (Referred to herein as [RFC3775]).
６． Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997 (Referred to herein as [RFC2205]).
７ Malki, K., "Low Latency Handoffs in Mobile IPv4", draft-ietf-mobileip-lowlatency-handoffs-v4-11 (work in progress), October 2005 (Referred to herein as [I-D.ietf-mobileip-lowlatency-handoffs-v4]).
８． Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068, July 2005 (Referred to herein as [RFC4068]).
９． Liebsch, M., "Candidate Access Router Discovery", draft-ietf-seamoby-card-protocol-08 (work in progress), September 2004 (Referred to herein as [I-D.ietf-seamoby-card-protocol]).
１０． Loughney, J., "Context Transfer Protocol", draft-ietf-seamoby-ctp-11 (work in progress), August 2004 (Referred to herein as [I-D.ietf-seamoby-ctp]).
１１． Aboba, B., "Extensible Authentication Protocol (EAP) Key Management Framework", draft-ietf-eap-keying-14 (work in progress), June 2006 (Referred to herein as [I-D.ietf-eap-keying]).
１２． Forsberg, D., "Protocol for Carrying Authentication for Network Access (PANA)", draft-ietf-pana-pana-12 (work in progress), August 2006 (Referred to herein as [I-D.ietf-pana-pana]).
１３． ITU-T, "General Characteristics of International Telephone Connections and International Telephone Circuits: One-Way Transmission Time", ITU-T Recommendation G.114 1998 (Referred to herein as [RG98]).
１４． ITU-T, "The E-Model, a computational model for use in transmission planning", ITU-T Recommendation G.107 1998 (Referred to herein as [ITU98]).
１５． ETSI, "Telecommunications and Internet Protocol Harmonization Over Networks (TIPHON) Release 3: End-to-end Quality of Service in TIPHON systems; Part 1: General aspects of Quality of Service.", ETSI TR 101 329-6 V2.1.1 (Referred to herein as [ETSI]).
１６． Kivinen, T. and H. Tschofenig, "Design of the MOBIKE Protocol", draft-ietf-mobike-design-08 (work in progress), March 2006 (Referred to herein as [I-D.ietf-mobike-design]).
１７． Moskowitz, R., "Host Identity Protocol", draft-ietf-hip-base-06 (work in progress), June 2006 (Referred to herein as [I-D.ietf-hip-base]).
１８． Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Delay Metric for IPPM", RFC 2679, September 1999 (Referred to herein as [RFC2679]).
１９． Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Packet Loss Metric for IPPM", RFC 2680, September 1999 (Referred to herein as [RFC2680]).
２０． Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay Metric for IPPM", RFC 2681, September 1999 (Referred to herein as [RFC2681]).
２１． Simpson, W., "IP in IP Tunneling", RFC 1853, October 1995 (Referred to herein as [RFC1853]).
２２． Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, January 2001 (Referred to herein as [RFC3046]).
２３． Kim, P., Volz, B., and S. Park, "Rapid Commit Option for DHCPv4", draft-ietf-dhc-rapid-commit-opt-05 (work in progress), June 2004 (Referred to herein as [I-D.ietf-dhc-rapid-commit-opt]).
２４． Ohba, Y., "Media-Independent Pre-Authentication (MPA) Implementation Results", draft-ohba-mobopts-mpa-implementation-02 (work in progress), March 2006 (Referred to herein as [I-D.ohba-mobopts-mpa-implementation]).
２５． Wakikawa, R., "Multiple Care-of Addresses Registration", draft-wakikawa-mobileip-multiplecoa-05 (work in progress), March 2006 (Referred to herein as [I-D.wakikawa-mobileip-multiplecoa]).
２６． Manner, J., "NSLP for Quality-of-Service Signaling", draft-ietf-nsis-qos-nslp-11 (work in progress), June 2006 (Referred to herein as [I-D.ietf-nsis-qos-nslp]).
２７． Schulzrinne, H. and E. Wedlund, "Application Layer Mobility Using SIP", ACM MC2R (Referred to herein as [SIPMM]).
２８． Cambell, A., Gomez, J., Kim, S., Valko, A., and C. Wan, "Design, Implementation, and Evaluation of Cellular IP", IEEE Personal communication August 2000 (Referred to herein as [CELLIP]).
２９． Ramjee, R., Porta, T., Thuel, S., Varadhan, K., and S. Wang, "HAWAII: A Domain-based Approach for Supporting Mobility in Wide-area Wireless networks", International Conference on Network Protocols ICNP'99 (Referred to herein as [HAWAII]).
３０． Das, S., Dutta, A., Misra, A., and S. Das, "IDMP: An Intra-Domain Mobility Management Protocol for Next Generation Wireless Networks", IEEE Wireless Communication Magazine October 2000 (Referred to herein as [IDMP]).
３１． Calhoun, P., Montenegro, G., Perkins, C., and E. Gustafsson, "Mobile IPv4 Regional Registration", draft-ietf-mobileip-reg-tunnel-09 (work in progress), July 2004 (Referred to herein as [I-D.ietf-mobileip-reg-tunnel]).
３２． Yokota, H., Idoue, A., and T. Hasegawa, "Link Layer Assisted Mobile IP Fast Handoff Method over Wireless LAN Networks", Proceedings of ACM Mobicom 2002 (Referred to herein as [YOKOTA]).
３３． Shin, S., "Reducing MAC Layer Handoff Latency in IEEE 802.11 Wireless LANs", MOBIWAC Workshop (Referred to herein as [MACD]).
３４． Dutta, A., Zhang, T., Madhani, S., Taniuchi, K., Ohba, Y., and H. Schulzrinne, "Secured Universal Mobility", WMASH 2004 (Referred to herein as [SUM]).
３５． Dutta, A., Madhani, S., and H. Schulzrinne, "Fast handoff Schemes for Application Layer Mobility Management", PIMRC 2004 (Referred to herein as [SIPFAST]).
３６． Gwon, Y., Fu, G., and R. Jain, "Fast Handoffs in Wireless LAN Networks using Mobile initiated Tunneling Handoff Protocol for IPv4 (MITHv4)", Wireless Communications and Networking 2003, January 2005 (Referred to herein as [MITH]).
３７． "Draft IEEE Standard for Local and Metropolitan Area Networks: Media Independent Handover Services, IEEE P802.21/D00.01," A contribution to IEEE 802.21 WG , July 2005 (Referred to herein as [802.21]).
３８． "IEEE Wireless LAN Edition A compilation based on IEEE Std 802.11-1999(R2003)", Institute of Electrical and Electronics Engineers September 2003 (Referred to herein as [802.11]).
３９． Dutta, A., "GPS-IP based fast-handoff for Mobiles", NYMAN 2003 (Referred to herein as [GPSIP]).
４０． Vatn, J. and G. Maguire, "The effect of using co-located care-of-address on macro handover latency", 14th Nordic Teletraffic Seminar 1998 (Referred to herein as [MAGUIRE]).
４１． Mghazli, Y. and J. Bournelle, "MPA using IKEv2 and MOBIKE", draft-yacine-preauth-ipsec-00 IETF (Referred to herein as [mpa-mobike]).

本発明の好ましい実施形態は、上記他の背景技術を改善するものである。

本出願は、２００６年１０月２１日に出願された、発明者Ａ．Ｄｕｔｔａらの米国仮出願第６０／８６２４４８号の優先権を主張するものであり、この開示全体が参照として本明細書に組み込まれる。

いくつかの実施形態によれば、複数のターゲットネットワークとのメディア独立事前認証のための移動ノードの認証状態の管理の方法は、複数の隣接するネットワークの認証エージェントにおいて状態を一定の期間にわたって維持することと、移動ノードが隣接するネットワーク間を行ったり来たりするときに、認証エージェント内の維持される状態を用いることとを含む。

いくつかの実施形態によれば、複数のターゲットネットワークとのメディア独立事前認証のための移動ノードの認証状態の管理の方法は、現在のネットワーク内の認証エージェントによって認証され、許可されている移動ノードが、ターゲットネットワークへのハンドオーバを行うとき、移動ノードが現在のネットワークに戻るときに、新しいセキュリティアソシエーションを作成するための認証信号交換全部を行わなくて済むように、移動ノードと認証エージェントの間で確立されているセキュリティアソシエーション（ＭＰＡ−ＳＡ）を、現在のネットワークからの移動後、一定の期間にわたって保持することを含む。いくつかの例では、この方法は、認証エージェントが、現在のネットワークからの移動後に、移動ノードの完全に許可された状態を無許可の状態に変更し、移動ノードが現在のネットワークに戻り、ＭＰＡ−ＳＡと関連付けられた鍵の所有の証拠を提供するときに、無許可の状態を許可された状態に変更することをさらに含む。いくつかの例では、この方法は、移動ノードが、認証エージェントにおいてＭＰＡ−ＳＡが保持されている間、ハンドオーバにより移動ノードのＩＰアドレスが変化するときに認証エージェントを更新することを含む。

いくつかの実施形態によれば、複数のターゲットネットワークとのメディア独立事前認証のための移動ノードの認証状態の管理のシステムは、現在のネットワーク内の認証エージェントによって認証され、許可されている移動ノードがターゲットネットワークへのハンドオーバを行うとき、移動ノードが、現在のネットワークに戻るときに、新しいセキュリティアソシエーションを作成するための認証信号交換全部を行わなくて済むように、移動ノードと認証エージェントの間で確立されているセキュリティアソシエーション（ＭＰＡ−ＳＡ）が、現在のネットワークからの移動後、一定の期間にわたって保持されるように構成されている装置を含む。いくつかの例では、このシステムは、ＭＰＡ−ＳＡと関連付けられた鍵をキャッシュする手段を含む。いくつかの例では、このシステムは、候補ターゲットネットワーク内の認証エージェントに対して事前認証され、ＭＰＡ−ＳＡを確立した後、現在のネットワーク内に留まり続ける間も、候補ターゲットネットワークと異なるネットワークにハンドオーバした後でさえも、このＭＰＡ−ＳＡを保持し続けるように構成されている移動ノードを含む。

いくつかの実施形態によれば、移動ノードの現在のネットワークからターゲットネットワークへのハンドオーバ前の、移動ノードのためのサービス品質（ＱｏＳ）リソースの事前割振りの方法は、事前認証を用いて、アプリケーショントラヒックを搬送する事前対応型ハンドオーバトンネルのためにセキュリティアソシエーションをブートストラップすることを含む。いくつかの例では、ＱｏＳリソースは、事前対応型ハンドオーバトンネル上でプロトコルを実行するエンドツーエンド方式で割り振られ、事前認証は、事前対応型ハンドオーバトンネルがＱｏＳ信号交換を保護するためにセキュリティアソシエーションをブートストラップするのに使用される。いくつかの例では、事前対応型ハンドオーバトンネル上で実行されるプロトコルは、ＮＳＬＰまたはＲＳＶＰを含む。いくつかの例では、この方法は、ハンドオーバの前と後に、通信相手ノードとターゲットアクセスルータの間でＱｏＳリソースを継続して使用することをさらに含む。いくつかの例では、この方法は、ハンドオーバ前に事前割振りのＱｏＳリソースを使用するときに、ハンドオーバの前と後のターゲットネットワーク内のターゲットアクセスルータと移動ノードの間の経路の相違のために、ターゲットアクセスルータと移動ノードの間でＱｏＳリソースの重複事前割振りを用いることを含む。いくつかの例では、この方法は、ハンドオーバ後にターゲットアクセスルータと移動ノードの間の経路に使用されるＱｏＳリソースが、プロトコルを経路外信号交換で動作するように拡張することによって、またはメディア特有のＱｏＳ信号交換によって事前に割り振られることを含む。

いくつかの実施形態によれば、移動ノードの、現在のネットワークからターゲットネットワークへのハンドオーバの前の、移動ノードのサービス品質（ＱｏＳ）リソースの事前割振りのために構成されるシステムは、事前認証を用いて、アプリケーショントラヒックを搬送する事前対応型ハンドオーバトンネルのためにセキュリティアソシエーションをブートストラップするように構成されている装置を含む。

いくつかの実施形態によれば、移動ノードの移動先となり得る複数の隣接するターゲットネットワークと複数のトンネルを確立することを含む、ネットワーク間での移動ノードのハンドオーバに関連してスケーラビィティとリソース割振りを拡張する方法は、移動ノードが現在のネットワーク内にある間に、移動ノードと複数の隣接するターゲットネットワーク内の認証エージェントの間で複数の事前認証を行うことと、移動ノードが現在のネットワーク内にある間、移動ノードのレイヤ２移動より前に、複数の対応付け更新を行うこととを含む。いくつかの例では、移動ノードは、現在のネットワーク内にある間に、複数の候補ターゲットネットワークに関連する事前認証と事前構成と対応付け更新をそれぞれ完了する。いくつかの例では、移動ノードは、隣接するネットワークの複数のＩＰアドレスを、一定の期間にわたってキャッシュに格納するように構成されている。いくつかの例では、この方法は、複数の隣接するターゲットネットワーク内のターゲットルータと一時トンネルを確立することをさらに含む。いくつかの例では、この方法は、複数の対応付け更新を行うことでは、移動ノードが、通信相手ノード（ＣＮ）に、隣接するネットワークから獲得される複数のＩＰアドレスを有する対応付け更新を送信することと、通信相手ノードが、一時トンネルを使って移動ノードに、複数の一時ストリームを送ることをさらに含む。いくつかの例では、この方法は、移動ノードから送られる複数のコンタクトアドレスを有する対応付け更新を実行し、複数のメディアストリームが、一時トンネルを使用して通信相手ノード（ＣＮ）から生じることと、移動ノードのハンドオーバ後に移動ノードから、移動ノードが移動しなかった他の隣接するネットワークへのメディア送信を停止するように、移動ノードが移動した先に設定された新しい単一のコンタクトアドレスを有する別の対応付け更新を送信することとをさらに含む。いくつかの例では、この方法は、ターゲットアクセスルータで、またはホームエージェントでバッファリングを適用することと、移動ノードが特定のターゲットネットワークに移動した後で、移動ノードに一時データを転送することとをさらに含む。いくつかの例では、この方法は、上記転送することが、移動ノードにより、モバイルＩＰ登録の一部として、または別個のバッファリングプロトコルとしてトリガされることをさらに含む。

いくつかの実施形態によれば、ＩＰマルチキャストグループに加入している移動ノードが現在のネットワークから新しいネットワークに移動するときに、この移動ノードのマルチキャスト通信中断を最小限にする方法は、メディア独立事前認証（ＭＰＡ）を、事前対応型マルチキャストモビリティサポートを提供し、参加待ち時間を低減するように用いることを含む。いくつかの例では、マルチキャストモビリティは、ホームサブスクリプションベースの手法を伴い、参加待ち時間は、事前にマルチキャストツリーに参加することによって低減される。いくつかの例では、次のアクセスルータ（ＮＡＲ）が、移動ノードが新しいネットワークに移動しようとしているときに、マルチキャストプロキシとして振る舞うように構成されている。いくつかの例では、ＭＰＡプロセスの事前構成段階において、移動ノードは、移動ノードが事前認証された後で、加入している（１つまたは複数の）マルチキャストグループに関する情報を渡す。いくつかの例では、この方法は、新しいネットワーク内の構成サーバと対話することによって現在のネットワーク内で移動ノードを事前構成するためのプロトコルとしてＰＡＮＡを使用することと、移動ノードに、これの加入グループ情報をＰＡＮＡ認証エージェントに渡させることとをさらに含む。

いくつかの例では、この方法は、ＰＡＮＡ認証エージェントに、次のアクセスルータ（ＮＡＲ）とやりとりして、上流ルータに参加するためのマルチキャストをトリガさせることをさらに含む。いくつかの例では、この方法は、移動ノードと次のアクセスルータの間のトンネルセットアッププロセスの間に、次のアクセスルータが、移動ノードに代わってマルチキャストグループに参加することをさらに含む。いくつかの例では、移動ノードは、現在のネットワークから移動する前に、現在のネットワーク内で作成されるトンネルを使って、次のアクセスルータ（ＮＡＲ）に直接マルチキャスト参加要求を送る。いくつかの例では、この方法は、次のアクセスルータが、要求がどのインターフェースからもたらされたか識別することができ、このインターフェースに加入ホストがあると想定するように、マルチキャスト参加要求の送信元アドレスが移動ノードのトンネル終点アドレスの送信元アドレスに設定されることを含む。いくつかの例では、この方法は、次のアクセスルータを、マルチキャストルータとして構成させることをさらに含む。いくつかの例では、移動ノードは、現在のネットワーク内にあるときには、依然として、移動ノードの現在構成されているＩＰアドレス上で前のアクセスルータ（ＰＡＲ）を介してマルチキャストトラヒックを受け取るが、移動ノードが新しいネットワークに移動し、トンネルを削除すると、最小限の参加待ち時間で、同じグループマルチキャストアドレス上でこのマルチキャストトラヒックを受け取り始める。いくつかの例では、移動ノードは、前もってアドレスを獲得し、これのインターフェースを構成するのに時間を費やさない。いくつかの例では、マルチキャストモビリティはリモートサブスクリプションベースの手法を伴い、メディア独立事前認証は、マルチキャストサービスのためのモビリティサポートを提供し、データが、移動ノードと次のアクセスルータの間の一時ＭＰＡトンネルを介して、前のネットワーク内のモバイルに配信される。いくつかの例では、モバイルが新しいネットワークに移動する際に、モバイルＩＰ（ＭＩＰ）トンネルが、新しいネットワーク内のマルチキャストトラヒックの配信を処理する。

様々な実施形態の上記および／または他の態様、特徴および／または利点は、以下の説明を、添付の図と併せて考察すれば、さらに理解されるであろう。様々な実施形態は、該当する場合には、異なる態様、特徴および／または利点を含み、または除外することができる。加えて、様々な実施形態は、該当する場合には、他の実施形態の１つまたは複数の態様または特徴を組み合わせることもできる。個々の実施形態の態様、特徴および／または利点の記述は、他の実施形態または特許請求の範囲を限定するものと解釈すべきではない。

本発明の好ましい実施形態を、限定としてではなく例として、添付の図に示す。

本発明は、多くの異なる形で実施され得るが、本明細書では、本開示は、発明の原理の例を提供するものとみなされるべきであり、かかる例は、本発明を、本明細書で説明し、かつ／または図示する好ましい実施形態だけに限定するためのものではないという了解の下で、いくつかの例示的実施形態について説明する。

１．概論
セルラと無線ＬＡＮを含む無線技術が普及するにつれて、無線ＬＡＮからＣＤＭＡやＧＰＲＳへなど、異なる種類のアクセスネットワークにまたがる端末ハンドオーバをサポートすることが、明確な課題とみなされるようになっている。他方、同種のアクセスネットワーク間の端末ハンドオーバをサポートすることは、特に、ハンドオーバがＩＰサブネットまたは管理ドメインにまたがるときには、より一層困難である。これらの課題に対処するには、リンク層技術に依存しない端末モビリティを、不合理な複雑さを伴わずに、最適化されたセキュアなやり方で提供することが重要である。本明細書では、シームレスなハンドオーバを、低待ち時間、低損失で提供する端末モビリティについて論じる。シームレスなハンドオーバは、セクション１．１で説明するように、性能要件を特徴とする。

端末モビリティの基本部分は、移動端末のロケータと識別子の間の対応付けを維持するモビリティ管理プロトコルによって達成され、この対応付けをモビリティ対応付けという。移動ノードのロケータは、移動端末に移動が生じるときに、動的に変化し得る。ロケータの変化を引き起こす移動は、物理的にのみならず論理的にも起こり得る。モビリティ管理プロトコルは、任意の層において定義され得る。本明細書の以下の部分において、「モビリティ管理プロトコル」という用語は、ネットワーク層以上で動作するモビリティ管理プロトコルをいう。

異なる層におけるいくつかのモビリティ管理プロトコルがある。モバイルＩＰ［ＲＦＣ３３４４］とモバイルＩＰｖ６［ＲＦＣ３７７５］は、ネットワーク層で動作するモビリティ管理プロトコルである。ＩＥＴＦでは、ネットワーク層より上位の各層におけるモビリティ管理プロトコルを定義するいくつかの作業が進行中である。例えば、ＭＯＢＩＫＥ（ＩＫＥｖ２モビリティおよびマルチホーミング）［Ｉ−Ｄ．ｉｅｔｆ−ｍｏｂｉｋｅ−ｄｅｓｉｇｎ］は、ＩＫＥｖ２終点のＩＰアドレスの変更を扱うことを可能にするＩＫＥｖ２の拡張である。ＨＩＰ（ホスト識別プロトコル）［Ｉ−Ｄ．ｉｅｔｆ−ｈｉｐ−ｂａｓｅ］は、ネットワーク層にとってもトランスポート層にとって透過的なやり方で端末モビリティを提供する、ネットワーク層とトランスポート層の間の新しいプロトコル層を定義する。また、ＳＩＰモビリティは、ＳＩＰユーザエージェントのモビリティ対応付け［ＳＩＰＭＭ］を維持するためのＳＩＰの拡張である。

モビリティ管理プロトコルはモビリティ対応付けを維持するが、これらのプロトコルをただ現在の形として使用するだけでは、シームレスなハンドオーバを提供するのに十分ではない。シームレスなハンドオーバを実現するには、移動端末の在圏ネットワークにおいて、モビリティ対応付けを更新する間に送信される未処理のパケットの損失を防ぐように動作する別の最適化機構が必要である。かかる機構を、モビリティ最適化機構という。例えば、モバイルＩＰｖ４とモバイルＩＰｖ６については、それぞれ、モビリティ最適化機構［Ｉ−Ｄ．ｉｅｔｆ−ｍｏｂｉｌｅｉｐ−ｌｏｗｌａｔｅｎｃｙｈａｎｄｏｆｆｓ−ｖ４］と［ＲＦＣ４０６８］が定義され、隣接するアクセスルータが、移動端末に関する情報を伝達し、搬送することを可能にしている。モビリティ最適化機構の「補助機能」とみなされるプロトコルがある。ＣＡＲＤ（候補アクセスルータ探索機構）プロトコル［Ｉ−Ｄ．ｉｅｔｆ−ｓｅａｍｏｂｙ−ｃａｒｄ−ｐｒｏｔｏｃｏｌ］は、隣接するアクセスルータを探索するように設計されている。ＣＴＰ（コンテキスト転送プロトコル）［Ｉ−Ｄ．ｉｅｔｆ−ｓｅａｍｏｂｙ−ｃｔｐ］は、アクセスルータ間で、移動端末に提供されるサービスと関連付けられている状態、またはコンテキストを搬送するように設計されている。

既存のモビリティ最適化機構にはいくつかの問題がある。第１に、既存のモビリティ最適化機構は、特定のモビリティ管理プロトコルと緊密に結びついている。例えば、モバイルＩＰｖ４またはモバイルＩＰｖ６用に設計されているモビリティ最適化機構をＭＯＢＩＫＥに使用することは不可能である。強く求められているのは、どのようなモビリティ管理プロトコルとも動作する単一の、統一されたモビリティ最適化機構である。第２に、管理ドメイン間の事前に確立されたセキュリティアソシエーションを想定せずに、管理ドメインにまたがるハンドオーバを容易にサポートする既存のモビリティ最適化機構がない。モビリティ最適化機構は、移動ノードと各管理ドメインの間の信頼関係のみに基づくセキュアなやり方で、管理ドメインにまたがって動作すべきである。第３に、モビリティ最適化機構は、複数インターフェースを介した複数同時接続が期待され得る複数インターフェース端末のみならず、単一インターフェース端末もサポートする必要がある。

このセクションでは、特に、これらすべての問題に対処する可能性を有する新しいハンドオーバ最適化機構である、メディア独立事前認証（ＭＰＡ）のフレームワークについて説明する。ＭＰＡは、任意のリンク層を介して、モバイルＩＰｖ４、モバイルＩＰｖ６、ＭＯＢＩＫＥ、ＨＩＰ、ＳＩＰモビリティなどを含む任意のモビリティ管理プロトコルと共に動作するモバイル支援のセキュアなハンドオーバ最適化方式である。ＭＰＡでは、ＩＥＥＥ８０２．１１ｉ事前認証の概念が、上位層で機能するように、移動端末の移動先となり得るネットワークからのＩＰアドレスの早期獲得と、移動端末がまだ現在のネットワークに接続されている間の移動先のネットワークへの事前対応型ハンドオーバとを行う追加機構を用いて拡張される。本明細書はＭＰＡのフレームワークを中心に扱うため、ＭＰＡのための実際のプロトコルセットを選択し、詳細な動作を定義することは、今後の作業に委ねられる。文献［Ｉ−Ｄ．ｏｈｂａ−ｍｏｂｏｐｔｓ−ｍｐａ−ｉｍｐｌｅｍｅｎｔａｔｉｏｎ］は、ＭＰＡ機能を実現する既存のプロトコル間の用法と対話を記述する１つの方法を提供するものである。

１．１．性能要件
対話型ＶｏＩＰおよびストリーミングトラヒックで望ましいサービス品質を提供するためには、エンドツーエンド遅延、ジッタおよびパケット損失の値を、ある一定の閾値レベルに制限する必要がある。ＩＴＵ−ＴとＩＴＵ−Ｅの規格が、これらのパラメータの許容可能な値を定義している。例えば、一方向遅延では、ＩＴＵ−ＴＧ．１１４が、大部分の用途での上限として１５０ミリ秒を推奨し、一般に許容可能な遅延として４００ミリ秒を推奨している。テレビ会議での一方向遅延許容度は、２００から３００ミリ秒の範囲である。また、一定の閾値の後で順序のずれたパケットが受け取られる場合にも、このパケットは失われたとみなされる。参考文献［ＲＦＣ２６７９］、［ＲＦＣ２６８０］および２６８１［ＲＦＣ２６８１］には、遅延とジッタのいくつの測定技法が記載されている。

エンドツーエンド遅延は、ネットワーク遅延、オペレーティングシステム（ＯＳ）遅延、ＣＯＤＥＣ遅延、アプリケーション遅延などいくつかの構成要素からなる。ネットワーク遅延は、中間ルータにおける送信遅延、伝搬遅延、待ち行列遅延からなる。オペレーティングシステム関連の遅延は、送信側と受信側のオペレーティングシステムのスケジューリング挙動からなる。ＣＯＤＥＣ遅延は、一般に、送信側と受信側におけるパケット化と逆パケット化によって生じる。

アプリケーション遅延は、主に、ネットワーク内の遅延変動の補償に役立つプレイアウト遅延に起因する。エンドツーエンド遅延およびジッタ値は、受信側におけるプレイアウトバッファの適正な値を使って調整され得る。対話型ＶｏＩＰトラヒックの場合、エンドツーエンド遅延は、ジッタ値に影響を及ぼし、考慮すべき重要問題である。モバイルの頻繁なハンドオーバ時には、一時トラヒックがモバイルに到達することができず、これもまたジッタの一因となる。

エンドシステムが、プレイアウトバッファを有する場合、このジッタは、プレイアウトバッファ遅延に包含されるが、そうでない場合、これは、対話型トラヒックの遅延に追加される。パケット損失は、通常、輻輳、経路指定不安定性、リンク障害、無線リンクなどの損失の大きいリンクなどにより引き起こされる。モバイルのハンドオーバ時に、モバイルは、これのネットワークへの接続の変化により、パケット損失を被る。よって、ストリーミングトラヒックでも、ＶｏＩＰ対話型トラヒックでも、パケット損失は、リアルタイムアプリケーションのサービス品質の一因となる。

失われるパケットの数は、ハンドオーバ時の遅延と、モバイルが受信するトラヒックの速度に比例する。損失パケットは、ＴＣＰトラヒックの場合には、再送信のために輻輳の原因となるが、ＲＴＰ／ＵＤＰベースであるストリーミングトラヒックの場合には、輻輳を増大させない。よって、あらゆるモビリティ管理方式において、パケット損失と、ハンドオーバ遅延の影響を低減することが不可欠である。セクション２では、ハンドオーバ遅延を低減しようと試みているいくつかの高速ハンドオーバ方式について説明する。

ＥＴＳＩＴＲ１０１［ＥＴＳＩ］によれば、通常の音声会話は、最大２％までのパケット損失を許容し得る。モバイルで会話中に頻繁にハンドオフが行われる場合、各ハンドオフは、ハンドオフの期間についてパケット損失の原因となる。よって、会話時の最大損失が、許容可能なレベルまで低減される必要がある。ストリーミングアプリケーションでは、パケット損失の明確な閾値はないが、パケット損失は、特定のアプリケーションにより良いサービス品質を提供するためにできる限り低減される必要がある。

２．高速ハンドオーバに関する既存の研究
モバイルＩＰ［ＲＦＣ３３４４］、モバイルＩＰｖ６［ＲＦＣ３７７５］、ＳＩＰ−Ｍｏｂｉｌｉｔｙ［ＳＩＰＭＭ］といった基本のモビリティ管理プロトコルは、ＴＣＰおよびＲＴＰトラヒックの継続を可能にする解決策を提供するが、これらは、モバイルのサブネット間およびドメイン間での頻繁な移動時のハンドオーバ待ち時間を低減するように最適化されていない。一般に、これらのモビリティ管理プロトコルは、モバイルのモビリティ対応付けを更新するために、レイヤ２、レイヤ３、アプリケーション層などいくつかの層で被るハンドオーバ遅延の悪影響を受ける。

目下、モバイルの、セル、サブネット、ドメイン間の移動時のハンドオーバ遅延とパケット損失を低減しようとするモビリティ管理方式に適用できるいくつかの最適化技法がある。少数のマイクロモビリティ管理方式［ＣＥＬＬＩＰ］、［ＨＡＷＡＩＩ］、および［ＩＤＭＰ］、［Ｉ−Ｄ．ｉｅｔｆ−ｍｏｂｉｌｅｉｐ−ｒｅｇ−ｔｕｎｎｅｌ］などの、ドメイン内の信号更新を制限することにより高速ハンドオーバを実現するドメイン内モビリティ管理方式がある。ＩＰｖ４およびＩＰｖ６ネットワークのための高速モバイルＩＰプロトコル［Ｉ−Ｄ．ｉｅｔｆ−ｍｏｂｉｌｅｉｐ−ｌｏｗｌａｔｅｎｃｙｈａｎｄｏｆｆｓ−ｖ４］、［ＲＦＣ４０６８］は、リンク層トリガによって提供されるモビリティ情報を利用する高速ハンドオーバ技法を提供する。

Ｙｏｋｏｔａらは、アクセスポイントと専用ＭＡＣブリッジを一緒に使って、ＭＩＰｖ４仕様を変更せずに高速ハンドオーバを実現することを提案している。［ＭＡＣＤ］方式は、キャッシュベースのアルゴリズムを提供することによって、ＭＡＣ層ハンドオフによる遅延を低減する。

いくつかのモビリティ管理方式は、デュアルインターフェースを使って、メイクビフォアブレークシナリオを提供する［ＳＵＭ］。メイクビフォアブレークの状況では、通信は、普通、第２のインターフェースが接続される過程にあるときに、１つのインターフェースを用いて続行される。ＩＥＥＥ８０２．２１作業グループは、これらのシナリオを詳細に論じている［８０２．２１］。単一のインターフェースを使って高速ハンドオーバを提供するには、複数のインターフェースを備えるクライアントの場合よりも慎重な設計技法を必要とする。［ＳＩＰＦＡＳＴ］は、一時トラヒックが、アプリケーション層転送方式を使って、旧いサブネットから新しいサブネットへ転送される、ＳＩＰベースのモビリティ管理のための最適化されたハンドオーバ方式を提供する。［ＭＩＴＨ］は、旧い移動先エージェントと新しい移動先エージェントの間のモバイル開始トンネリングを使用する、単一インターフェースの場合での高速ハンドオーバ方式を提供する。［ＭＩＴＨ］は、ＭＩＴ前とＭＩＴ後など、２種類のハンドオーバ方式を定義する。提案のＭＰＡ方式は、本質的に、モバイルが、実際に新しいネットワークに移動する前に、移動先エージェントとやりとりするＭＩＴＨの予測方式とよく似ている。しかしながら、本明細書で説明する提案のＭＰＡ方式は、ＭＩＰ型のモビリティプロトコルだけに限定されるものではなく、この方式に加えて、ドメイン間の移動も処理し、事前対応型ハンドオーバに加えて事前認証も行う。よって、提案の方式は、遅延全体を、ほぼリンク層ハンドオーバ遅延近くまで低減する。

３．用語
モビリティ対応付け：
移動端末のロケータと識別子の間の対応付け。

モビリティ管理プロトコル（ＭＭＰ）：
ネットワーク層以上で、移動端末のロケータと識別子の間の対応付けを維持するように動作するプロトコル。

対応付け更新：
モビリティ対応付けを更新する手順。

メディア独立事前認証移動ノード（ＭＮ）：
任意のリンク層を介して、任意のモビリティ管理プロトコルと共に動作するモバイル支援のセキュアなハンドオーバ最適化方式であるメディア独立事前認証（ＭＰＡ）の移動端末。ＭＰＡ移動ノードは、ＩＰノードである。本明細書では、修飾句の付かない「移動ノード」または「ＭＮ」という用語は、「ＭＰＡ移動ノード」を指す。ＭＰＡ移動ノードは、普通、モビリティ管理プロトコルの移動ノードの機能も有する。

候補ターゲットネットワーク（ＣＴＮ）：
近い将来にモバイルの移動先となり得るネットワーク。

ターゲットネットワーク（ＴＮ）：
モバイルが移動することに決定しているネットワーク。ターゲットネットワークは、１つまたは複数の候補ターゲットネットワークから選択される。

事前対応型ハンドオーバトンネル（ＰＨＴ）：
ＭＰＡ移動ノードと候補ターゲットネットワークのアクセスルータの間で確立される双方向ＩＰトンネル。

本明細書で、修飾句の付かない「トンネル」という用語は、「事前対応型ハンドオーバトンネル」を指す。

接続点（ＰｏＡ）：
ＭＰＡ移動ノードのネットワークへのリンク層接続点として機能するリンク層装置（スイッチ、アクセスポイントまたは基地局など）。

気付アドレス（ＣｏＡ）：
モビリティ管理プロトコルによってＭＰＡモバイルのロケータとして使用されるＩＰアドレス。

４．ＭＰＡフレームワーク
４．１．概要
メディア独立事前認証（ＭＰＡ）は、任意のリンク層を介して、任意のモビリティ管理プロトコルと共に動作する、モバイル支援のセキュアなハンドオーバ最適化方式である。ＭＰＡでは、移動ノードは、ＣＴＮのＩＰアドレスおよび他の構成パラメータをセキュアに獲得することができるだけでなく、獲得されるＩＰアドレスを使って、実際にＣＴＮに接続する前にＩＰパケットを送受信することもできる。これは、移動ノードが、リンク層におけるハンドオーバを行う前に、任意のモビリティ管理プロトコルの対応付け更新を完了し、新しいＣｏＡを使用することを可能にする。

この機能は、現在のネットワークに接続することはできるが、まだ、ＣＴＮには接続されていない移動ノードが、（ｉ）後続のプロトコル信号交換を保護するためにＣＴＮとのセキュリティアソシエーションを確立し、次いで、（ｉｉ）ＣＴＮからＩＰアドレスおよび他のパラメータを獲得する構成プロトコルをセキュアに実行すると共に、移動ノードとＣＴＮのアクセスルータの間のＰＨＴを確立するトンネル管理プロトコルを実行し、次いで、（ｉｉｉ）獲得したＩＰアドレスをトンネル内部アドレスとして使用するＰＨＴを介して、ＭＭＰの対応付け更新のための信号メッセージと対応付け更新の完了後に送信されるデータパケットを含む、ＩＰパケットを送受信し、最後に、（ｉｖ）ＣＴＮがターゲットネットワークになるときにＣＴＮに接続する直前に、ＰＨＴを削除または無効化し、次いで、削除され、または無効化されたトンネルの内部アドレスを、移動ノードがこれの物理インターフェースを介してターゲットネットワークに接続された直後に、これのインターフェースに再割り当てすることができるようにすることによって提供される。ターゲットネットワークに接続する前にトンネルを削除し、または無効化する代わりに、ターゲットネットワークに接続された直後にトンネルが削除され、無効化されてもよい。

特に、第３の手順は、モバイルが、リンク層ハンドオーバを開始する前に、上位層ハンドオーバを完了することを可能にする。

これは、モバイルが、まだ、トンネル外での対応付け更新の完了前に送信されるデータパケットを送受信することができる間に、トンネルを介した対応付け更新の完了後に送信されるデータパケットを送受信することを意味する。

上記のＭＰＡの４つの基本手順において、第１の手順を「事前認証」といい、第２の手順を「事前構成」といい、第３と第４の手順の組み合わせを、「セキュアな事前対応型ハンドオーバ」という。事前認証を介して確立されるセキュリティアソシエーションを「ＭＰＡ−ＳＡ」という。

４．２．機能要素
ＭＰＡフレームワークでは、移動ノードとやりとりするために、各ＣＴＮに機能要素、すなわち、認証エージェント（ＡＡ）、構成エージェント（ＣＡ）およびアクセスルータ（ＡＲ）が常駐することが期待されている。これらの要素の一部または全部が、単一のネットワーク装置に、または別々のネットワーク装置に配置され得る。認証エージェントは、事前認証の役割を果たす。ＭＰＡ−ＳＡを確立するために、移動ノードと認証エージェントの間で認証プロトコルが実行される。認証プロトコルは、移動ノードと認証エージェントの間で鍵を導出することのできる必要があり、相互認証を提供することのできる必要がある。認証プロトコルは、ＲＡＤＩＵＳやＤｉａｍｅｔｅｒといったＡＡＡプロトコルと対話して、ＡＡＡインフラストラクチャ内の適切な認証サーバに認証資格情報を搬送することのできる必要がある。導出鍵は、さらに、事前構成とセキュアな事前対応型ハンドオーバに使用されるメッセージ交換を保護するのに使用される鍵を導出するのに使用される。また、リンク層および／またはネットワーク層の暗号をブートストラップするのに使用される他の鍵も、ＭＰＡ−ＳＡから導出され得る。ＥＡＰ［ＲＦＣ３７４８］を搬送し得るプロトコルが、ＭＰＡの認証プロトコルとして適するはずである。

構成エージェントは、事前構成の一部、すなわち、移動ノードにＩＰアドレスおよび他の構成パラメータをセキュアに配信するための構成プロトコルをセキュアに実行する役割を果たす。構成プロトコルの信号メッセージは、ＭＰＡ−ＳＡに対応する鍵から導出される鍵を使って保護される必要がある。アクセスルータは、事前構成の他の部分、すなわち、移動ノードへの事前対応型ハンドオーバトンネルを確立するためのトンネル管理プロトコルをセキュアに実行する役割を果たす。

構成プロトコルの信号メッセージは、ＭＰＡ−ＳＡに対応する鍵から導出される鍵を使って保護される必要がある。事前対応型ハンドオーバトンネルを介して送信されるＩＰパケットは、ＭＰＡ−ＳＡに対応する鍵から導出される鍵を使って保護される必要がある。

４．３．基本の通信フロー
移動ノードは、すでに、ｏＰｏＡ（旧い接続点）などの接続点に接続されており、ｏＣｏＡ（旧い気付アドレス）などの気付アドレスが割り当てられているものと仮定する。ＭＰＡの通信フローは以下の通りである。この通信フロー全体を通じて、データパケット損失は、ステップ５の切換え手順の間の期間を除いては発生しないはずであり、この期間中のパケット損失を最小限にするのはリンク層ハンドオーバの役割である。

ステップ１（事前認証段階）：移動ノードは、何らかの探索プロセスによってＣＴＮを発見し、何らかの手段によって、ＣＴＮ内のＩＰアドレス、認証エージェント、構成エージェントおよびアクセスルータを獲得する。移動ノードは、認証エージェントと事前認証を行う。事前認証に成功した場合、移動ノードと認証エージェントの間でＭＰＡ−ＳＡが作成される。ＭＰＡ−ＳＡから２つの鍵、すなわち、ＭＮ−ＣＡ鍵とＭＮ−ＡＲ鍵が導出され、これらを使って、後続の、構成プロトコルとトンネル管理プロトコルの信号メッセージが、それぞれ保護される。次いで、ＭＮ−ＣＡ鍵とＭＮ−ＡＲ鍵は、それぞれ、構成エージェントとアクセスルータにセキュアに配信される。

ステップ２（事前構成段階）：移動ノードは、これの接続点が、ｏＰｏＡから新しい接続点、例えばｎＰｏＡ（新しい接続点）に変化する可能性が高いことに気付く。次いで、移動ノードは、構成エージェントと、構成プロトコルを使って、ＣＴＮから、ｎＣｏＡ（新しい気付アドレス）などのＩＰアドレスと他の構成パラメータを獲得し、アクセスルータと、トンネル管理プロトコルを使って事前対応型ハンドオーバトンネルを確立する事前構成を行う。トンネル管理プロトコルでは、移動ノードは、ｏＣｏＡとｎＣｏＡを、それぞれ、トンネル外部アドレスとトンネル内部アドレスとして登録する。事前構成プロトコルの信号メッセージは、ＭＮ−ＣＡ鍵とＭＮ−ＡＲ鍵を使って保護される。構成とアクセスルータが同じ装置内に位置するとき、２つのプロトコルは、ＩＫＥｖ２のような単一のプロトコルに統合され得る。トンネル確立の完了後、移動ノードは、ステップ４の終了までに、ｏＣｏＡとｎＣｏＡの両方を使って通信することができる。

ステップ３（セキュアな事前対応型ハンドオーバの主段階）：移動ノードは、何らかの手段によって新しい接続点に切り換わることに決定する。移動ノードは、新しい接続点に切り換わる前に、セキュアな事前対応型ハンドオーバを開始して、モビリティ管理プロトコルの対応付け更新を実行し、トンネルを介して後続のデータトラヒックを送信する（主段階）。場合によっては、移動ノードは、複数のｎＣｏＡアドレスをキャッシュし、ＣＨまたはＨＡとの同時の対応付けを行うこともある。

ステップ４（セキュアな事前対応型ハンドオーバの切換え前段階）：移動ノードは、対応付け更新を完了し、新しい接続点に切り換われる状態になる。モバイルは、トンネル管理プロトコルを実行して、事前対応型ハンドオーバトンネルを削除し、または無効化し、トンネルの削除または無効化の後で、ｎＣｏＡをキャッシュし得る。移動ノードが、いつ、新しい接続点に切り換われる状態になるかの決定は、ハンドオーバポリシによって決まる。

ステップ５（切換え）：このステップでは、リンク層ハンドオーバが行われると期待される。

ステップ６（セキュアな事前対応型ハンドオーバの切換え後段階）：移動ノードは、切換え手順を実行する。切換え手順が正常に完了すると、移動ノードは、直ちに、キャッシュしたｎＣｏＡを復元し、これを新しい接続点に接続された物理インターフェースに割り当てる。ステップ４で事前対応型ハンドオーバトンネルが削除されず、または無効化されなかった場合には、トンネルも削除され、または無効化される。この後、事前対応型ハンドオーバトンネルを使用せずに、ｎＣｏＡを使ったデータパケットの直接送信が可能になる。ＭＰＡのコールフローの一例が、図１と図２に示されている。

５．詳細な問題
高速なサブネットおよびドメインのハンドオーバを行うモバイルに最適化されたハンドオーバを提供するためには、いくつかの問題を検討する必要がある。これらの問題には、隣接するネットワーク要素の探索、一定のポリシに基づいた接続すべき適切なネットワークの選択、レイヤ２接続点の変更、ＤＨＣＰまたはＰＰＰサーバからのＩＰアドレスの獲得、ＩＰアドレスの一意性の確認、認証エージェントとの事前認証、通信相手のホストへの対応付け更新の送信と新しい接続点への宛先変更されたストリーミングトラヒックの獲得、ピンポン効果、複数のネットワークに移動し、複数のターゲットネットワークと関連する可能性が含まれる。以下の各段落では、これらの問題を詳細に記述し、これらの問題を、ＭＰＡベースのセキュアな事前対応型ハンドオーバの場合にどのようにして最適化しているか説明する。

５．１．探索
アクセスポイント、アクセスルータ、認証サーバなどの隣接するネットワーク要素の探索は、モバイルのネットワーク間高速移動時のハンドオーバプロセスを早めるのに役立つ。所望の座標、能力およびパラメータのセットを用いてネットワーク近隣を探索することによって、モバイルは、前のネットワークにある間に、事前認証、事前対応型ＩＰアドレス獲得、事前対応型アドレス解決、対応付け更新など、多くの処理を行うことができる。

モバイルが隣接するネットワークを探索するこのできるいくつかのやり方がある。候補アクセスルータ探索プロトコル［Ｉ−Ｄ．ｉｅｔｆｓｅａｍｏｂｙ−ｃａｒｄ−ｐｒｏｔｏｃｏｌ］は、隣接するネットワーク内の候補アクセスルータを探索するのに役立つ。あるネットワークドメインが与えられると、ＳＬＰとＤＮＳは、特定のドメイン内の所与のサービスセットでのネットワーク構成要素のアドレスを提供するのを支援する。場合によっては、ネットワーク層と上位層のパラメータの多くが、モバイルが隣接するネットワークの近傍に接近するときに、リンク層を介して、ビーコンなどの管理フレームを介して送信され得る。ＩＥＥＥ８０２．１１ｕは、リンク層に含まれる情報を使った近隣探索などの問題を検討している。しかしながら、リンク層管理フレームが何らかのリンク層セキュリティ機構によって暗号化されている場合、移動ノードは、アクセスポイントへのリンク層接続を確立する前に、必要な情報を獲得できないこともある。加えて、このことは、帯域幅が制約された無線媒体の負荷を増大させ得る。かかる場合には、上位層プロトコルが、隣接する要素に関連する情報を獲得することが望ましい。隣接するネットワークに関するこの情報を、モビリティサーバから獲得するのに役立つ、［８０２．２１］など若干の提案が行われている。モバイルの移動が差し迫っているとき、モバイルは、探索プロセスを開始して特定のサーバに問い合わせし、アクセスポイントのＩＰアドレス、アクセスポイントの特性、隣接するネットワークのルータ、ＳＩＰサーバまたは認証サーバなど、必要なパラメータを獲得する。複数のネットワークがある場合には、モバイルは、必要なパラメータを複数の隣接するネットワークから獲得し、これらをキャッシュに保持し得る。ある時点において、モバイルは、多くの有望なネットワークの中からいくつかのＣＴＮを探し出し、事前認証プロセスを開始してＣＴＮ内の必要なエンティティとやりとりする。このシナリオのさらなる詳細をセクション５．２．に示す。

５．２．複数ＣＴＮ環境における事前認証
場合によっては、モバイルは、特定のネットワークをターゲットネットワークとすることに決定しても、実際には、モバイルの制御できない要因のせいで、結局このターゲットネットワーク以外の隣接するネットワークに移動することもある。よって、いくつかの有望な候補ターゲットネットワークと事前認証を行い、これらのネットワーク内のそれぞれのアクセスルータと期限付きのトンネルを確立することが有益となり得る。よって、ターゲットネットワークとして選択された以外の候補ターゲットネットワークに移動するモバイルの場合、モバイルが、この候補ターゲットネットワークと事前認証を行わなかった場合には生じたはずの、認証とＩＰアドレス獲得の遅延に起因するパケット損失を被らないことになる。いくつかの候補ターゲットネットワークと事前認証を行い、ＩＰアドレスを確保しておくことによって、モバイルが、別の目的で使用できたはずのリソースを引き当てているようにも見える。しかし、これは、限られた期間にわたってのみ生じるため、大きな問題にはならないはずである。モバイルは、事前認証手順を使ってＩＰアドレスを事前に獲得し、候補ターゲットネットワークのアクセスルータと期限付きのトンネルをセットアップする。また、ＭＮは、将来の移動のためにｎＣｏＡの一部または全部を保持してもよい。モバイルは、これらのアドレスの１つを対応付け更新アドレスとして選択し、これをＣＮ（通信相手ノード）またはＨＡ（ホームエージェン）に送ることができ、よって、前のネットワーク内にある間に、ターゲットネットワークを介してトンネルを使用したトラヒックを受信することになる。しかし、いくつかの例では、モバイルは、最終的にターゲットネットワーク以外のネットワークに移動することもある。よって、モバイルが新しいネットワークに移動する際に、モバイルは、新しいＩＰアドレスを割り当て、対応付け更新を再送信するプロセスを経る必要があるため、トラヒックに中断が生じる。この問題を処理するための２つの解決策を提案することができる。モバイルは、同時のモビリティ対応付けを利用し、通信相手のホストまたはＨＡに複数の対応付け更新を送信することができる。よって、通信相手のホストまたはＨＡは、特定の期間にわたって仮想インターフェースに割り当てられる複数のＩＰアドレスにトラヒックを転送する。この対応付け更新は、モバイルが新しいネットワークに移動した後、ＣＨにおいてリフレッシュされ、よって、他の候補ネットワークへのフローが停止する。参照文献［Ｉ−Ｄ．ｗａｋｉｋａｗａ−ｍｏｂｉｌｅｉｐｍｕｌｔｉｐｌｅｃｏａ］は、複数の気付アドレスを有するモビリティ対応付けの別のシナリオを論じている。同時対応付けが特定のモビリティ方式でサポートされていない場合には、前のターゲットネットワークからのトラヒックの転送が、新しい対応付け更新が新しいネットワークからもたらされるまで一時トラヒックを処理するのに役立つ。

５．３．事前対応型ＩＰアドレス獲得
一般に、モビリティ管理プロトコルは、移動先エージェントと連動して、またはコロケートアドレスモードで動作する。ＭＰＡ手法は、コロケートアドレスモードも移動先エージェントアドレスモードも使用することができる。ここでは、コロケートアドレスモードで使用されるアドレス割り当てコンポーネントについて論じる。移動ノードがＩＰアドレスを獲得し、モバイル自体を構成することのできるいくつかのやり方がある。最も一般的には、モバイルは、ネットワーク内のサーバやルータといった構成要素なしで、モバイル自体を静的に構成することができる。ＩＥＴＦＺｅｒｏｃｏｎｆ作業グループは、モバイルがアドホックで構成され、１６９．２５４．ｘ．ｘなど指定される範囲から一意のアドレスを選択する自動ＩＰアドレス指定（Ａｕｔｏ−ＩＰ）機構を定義している。ＬＡＮ環境では、モバイルは、ＤＨＣＰサーバからＩＰアドレスを獲得することができる。ＩＰｖ６ネットワークの場合には、モバイルは、ステートレス自動構成またはＤＨＣＰｖ６を使ってＩＰアドレスを獲得する選択肢を有する。広域ネットワーク環境では、モバイルは、ＰＰＰを使って、ＮＡＳとやりとりすることによってＩＰアドレスを獲得する。

これらのプロセスは、それぞれ、ＩＰアドレス獲得プロセスとクライアントおよびサーバのオペレーティングシステム種類に応じて、ほぼ数百ミリ秒から数秒程度の時間を要する。ＩＰアドレス獲得は、ハンドオーバプロセスの一部であるため、ハンドオーバ遅延を増大させ、よって、この時間をできるだけ低減することが望ましい。ＩＰアドレス獲得時間に起因するハンドオーバ時間を低減しようと試みる、ＤＨＣＰ高速コミット［Ｉ−Ｄ．ｉｅｔｆ−ｄｈｃ−ｒａｐｉｄ−ｃｏｍｍｉｔ−ｏｐｔ］、ＧＰＳ座標ベースのＩＰアドレス［ＧＰＳＩＰ］といった少数の最適化技法が利用できる。しかしながら、これらすべての場合において、モバイルは、モバイルが新しいサブネットに移動した後にもＩＰアドレスを獲得し、移動ノードとＤＨＣＰサーバの間の信号ハンドシェークのために若干の遅延を被る。

以下の段落では、移動ノードが、ＣＴＮから事前にＩＰアドレスを獲得し得るいくつかの方法と、関連付けられるトンネルセットアップ手順について説明する。これらは、大きく、ＰＡＮＡ支援事前対応型ＩＰアドレス獲得、ＩＫＥ支援事前対応型ＩＰアドレス獲得、ＤＨＣＰのみを使った事前対応型ＩＰアドレス獲得、およびステートレス自動構成といった４つのカテゴリに定義することができる。

５．３．１．ＰＡＮＡ支援事前対応型ＩＰアドレス獲得
ＰＡＮＡ支援事前対応型ＩＰアドレス獲得の場合、移動ノードは、ＣＴＮから事前にＩＰアドレスを獲得する。移動ノードは、ＰＡＮＡ［Ｉ−Ｄ．ｉｅｔｆ−ｐａｎａ−ｐａｎａ］メッセージを利用して、ＣＴＮ内のアクセスルータにおいてＰＡＮＡ認証エージェントと同じ場所に位置するＤＨＣＰリレーエージェント上でアドレス獲得プロセスをトリガする。移動ノードからＰＡＮＡメッセージを受け取ると、ＤＨＣＰリレーエージェントは、正規のＤＨＣＰメッセージ交換を行って、ＣＴＮ内のＤＨＣＰサーバからＩＰアドレスを獲得する。このアドレスは、ＰＡＮＡメッセージに同梱され、クライアントに配信される。ステートレス自動構成を用いるＭＩＰｖ６の場合、新しいターゲットネットワークからのルータ告知が、ＰＡＮＡメッセージの一部としてクライアントに渡される。モバイルは、このプレフィックスとモバイルのＭＡＣアドレスを使って、モバイルが新しいネットワークで構築するはずの一意のＩＰｖ６アドレスを構築する。ステートフルモードのモバイルＩＰｖ６は、ＤＨＣＰｖ４と同様に動作する。

５．３．２．ＩＫＥｖ２支援事前対応型ＩＰアドレス獲得
ＩＫＥｖ２支援事前対応型ＩＰアドレス獲得は、ＩＰｓｅｃゲートウェイとＤＨＣＰリレーエージェントが、ＣＴＮ内の各アクセスルータ内に存在するときに動作する。この場合、ＣＴＮ内のＩＰｓｅｃゲートウェイとＤＨＣＰリレーエージェントは、移動ノードがＣＴＮ内のＤＨＣＰサーバからＩＰアドレスを獲得するのを支援する。事前認証段階に確立されるＭＮ−ＡＲ鍵が、移動ノードとアクセスルータの間でＩＫＥｖ２を実行するのに必要とされるＩＫＥｖ２事前共用秘密鍵として使用される。ＣＴＮからのＩＰアドレスは、標準のＩＫＥｖ２手順の一部として獲得され、コロケートＤＨＣＰリレーエージェントを使って、標準ＤＨＣＰを使用するターゲットネットワーク内のＤＨＣＰサーバからＩＰアドレスが獲得される。獲得されるＩＰアドレスは、ＩＫＥｖ２構成ペイロード交換でクライアントに返送される。この場合、ＩＫＥｖ２は、事前対応型ハンドオーバトンネルのトンネル管理プロトコルとしても使用される（セクション５、６参照）。代替として、ＶＰＮ−ＧＷが、ＶＰＮ−ＧＷ自体で、これのＩＰアドレスプールからＩＰアドレスを分配することもできる。

５．３．３．ＤＨＣＰのみを使った事前対応型ＩＰアドレス獲得
別の代替方法として、移動ノードとＣＴＮ内のＤＨＣＰリレーまたはＤＨＣＰサーバの間の直接ＤＨＣＰ通信を可能にすることにより、ＰＡＮＡやＩＫＥｖ２ベースの手法に頼らずに、ＤＨＣＰを使ってＣＴＮからＩＰアドレスを事前に獲得することもできる。この場合、移動ノードは、現在の物理インターフェースと関連付けられたアドレスを、要求の送信元アドレスとして使用しながら、ＣＴＮ内のＤＨＣＰリレーエージェントまたはＤＨＣＰサーバに、アドレスを要求するユニキャストＤＨＣＰメッセージを送信する。

メッセージがＤＨＣＰリレーエージェントに送られるとき、ＤＨＣＰリレーエージェントは、移動ノードとＤＨＣＰサーバの間でＤＨＣＰメッセージをやりとりさせる。ＤＨＣＰリレーエージェントがない場合に、モバイルは、ターゲットネットワーク内のＤＨＣＰサーバと直接やりとりすることもできる。リレーエージェントまたはＤＨＣＰサーバが、移動ノードの送信元アドレスを使って直接応答を返送することができるように、クライアントのユニキャストＤＩＳＣＯＶＥＲメッセージのブロードキャストオプションは０に設定される必要がある。この機構は、ステートフル構成を使用するＩＰｖ６ノードでも動作する。

悪意のあるノードが、ＤＨＣＰサーバからＩＰアドレスを獲得するのを防ぐために、ＤＨＣＰ認証が使用される必要があり、またはアクセスルータが、事前認証されていない移動ノードからリモートＤＨＣＰサーバに送られるユニキャストＤＨＣＰメッセージを阻止するフィルタをインストールする必要がある。ＤＨＣＰ認証が使用されるときには、ＤＨＣＰ認証鍵が、移動ノードと候補ターゲットネットワーク内の認証エージェントの間で確立されるＭＰＡ−ＳＡから導出され得る。

事前に獲得されるＩＰアドレスは、モバイルが新しいネットワークに移動するまで、移動ノードの物理インターフェースに割り当てられない。このようにターゲットネットワークから事前に獲得されるＩＰアドレスは、物理インターフェースではなく、クライアントの仮想インターフェースに割り当てられる必要がある。よって、移動ノードとＣＴＮ内のＤＨＣＰリレーまたはＤＨＣＰサーバの間の直接ＤＨＣＰ通信による、かかる事前に獲得されるＩＰアドレスは、物理インターフェースに割り当てられる他のアドレスとこのアドレスを区別するのに使用される追加情報と共に搬送され得る。

モバイルが新しいネットワークに入ると、移動ノードは、物理インターフェースを介して新しいネットワークにＤＨＣＰを実行し、ＤＨＣＰＩＮＦＯＲＭなどを使って、ＳＩＰサーバ、ＤＮＳサーバなどといった他の構成パラメータを取得することができる。これは、モバイルと通信相手ホストの間の進行中の通信に影響を及ぼすべきではない。また、移動ノードは、物理インターフェースを介して新しいネットワークにＤＨＣＰを実行し、新しいネットワークに入る前に事前に獲得されたアドレスのリースを延長することができる。

５．３．４．ステートレス自動構成を使った事前対応型ＩＰアドレス獲得
ＩＰｖ６の場合、ネットワークアドレス構成は、ＤＨＣＰｖ６またはステートレス自動構成を使って行われる。新しいＩＰアドレスを事前に獲得するために、確立されたトンネルを介して次のホップルータのルータ告知を送ることができ、モバイルのプレフィックスとＭＡＣアドレスに基づいて新しいＩＰｖ６アドレスが生成される。

新しいネットワークからＣＯＡを生成すれば、ＩＰアドレスを獲得し、重複アドレス検出を行うのに必要とされる時間が回避される。

セキュアな事前対応型ハンドオーバの前と後で、移動ノードのＤＨＣＰ対応付けを維持し、分配されるＩＰアドレスを追跡するために、事前対応型ＩＰアドレス獲得のためのＤＨＣＰと、移動ノードがターゲットネットワークに入った後で行われるＤＨＣＰの両方で、移動ノードに同じＤＨＣＰクライアント識別子が使用される必要がある。ＤＨＣＰクライアント識別子は、移動ノードのＭＡＣアドレスまたは他の何らかの識別子とすることができる。ステートレス自動構成の場合、モバイルは、新しいネットワークにおけるルータ告知のプレフィックスをチェックし、これと、新しく割り当てられるＩＰアドレスのプレフィックスを照合する。これらが同じであることが判明した場合、ＭＣは、ＩＰアドレス獲得段階を再度行わない。

５．４．アドレス解決問題
５．４．１．事前対応型重複アドレス検出
ＤＨＣＰサーバは、ＩＰアドレスを分配するとき、この同じアドレスが、この特定の期間にわたって別のクライアントに与えられないように、ＤＨＣＰサーバのリース表を更新する。同時に、クライアントも、必要なときに更新できるように、リース表をローカルで保持する。ネットワークがＤＨＣＰ対応と非ＤＨＣＰ対応両方のクライアントからなる場合には、ＬＡＮの別のクライアントが、ＤＨＣＰアドレスプールからのＩＰアドレスを用いて構成されている可能性もある。かかるシナリオでは、サーバは、ＩＰアドレスを割り当てる前に、ＡＲＰ（アドレス解決プロトコル）またはＩＰｖ６近隣探索に基づく重複アドレス検出を行う。この検出手順は、最大４秒から１５秒を要し［ＭＡＧＵＩＲＥ］、よって、より大きいハンドオーバ遅延の原因となる。事前対応型ＩＰアドレス獲得プロセスの場合には、この検出は前もって行われ、よって、ハンドオーバ遅延には全く影響しない。重複アドレス検出を前もって行うことによって、ハンドオーバ遅延要因が低減される。

５．４．２．事前対応型アドレス解決更新
事前構成のプロセスの間、移動ノードがターゲットネットワークに接続した後で、ターゲットネットワーク内のノードとやりとりするのに必要なアドレス解決マッピングも知らせることができ、これらのノードは、アクセスルータ、認証エージェント、構成エージェントおよび通信相手ノードとすることができる。かかる事前対応型アドレス解決を行ういくつかの可能な方法がある。

・情報サービス機構［８０２．２１］を使って、各ノードのＭＡＣアドレスを解決する。これは、情報サービスのサーバが、事前対応型アドレス解決のデータベースを構築することができるように、ターゲットネットワーク内の各ノードが、情報サービスに関与していることを必要とし得る。

・事前認証に使用される認証プロトコルまたは事前構成に使用される構成プロトコルを、事前対応型アドレス解決をサポートするように拡張する。例えば、ＰＡＮＡが事前認証の認証プロトコルとして使用される場合には、ＰＡＮＡメッセージが、事前対応型アドレス解決に使用されるＡＶＰを搬送する。この場合、ターゲットネットワーク内のＰＡＮＡ認証エージェントは、移動ノードに代わってアドレス解決を行う。

・また、ＤＮＳを利用して、ターゲットネットワーク内のネットワーク要素の特定のＩＰアドレスと関連付けられた特定のインターフェースのＭＡＣアドレスをマップすることもできる。ターゲットネットワーク内のノードのＭＡＣアドレスを事前に解決するために、新しいＤＮＳリソースレコード（ＲＲ）を定義してもよい。しかし、ＭＡＣアドレスは、ドメイン名に直接ではなく、ＩＰアドレスにバインドされたリソースであるため、この手法には独自の限界がある。

移動ノードは、ターゲットネットワークに接続するとき、必ずしもターゲットネットワーク内のノードのアドレス解決問い合わせを行わずに、事前に獲得したアドレス解決マッピングをインストールする。

他方、ターゲットネットワーク内にあって、移動ノードとやりとりしている各ノードもまた、移動ノードがターゲットネットワークに接続し次第、移動ノードのために各ノードのアドレス解決を更新する必要がある。また、前述の事前対応型アドレス解決方法は、これらのノードが、移動ノードがターゲットネットワークに接続する前に、移動ノードのＭＡＣアドレスを事前に解決するのにも使用され得る。しかしながらこれは、これらのノードが、事前に解決されるアドレス解決マッピングを用いる前に、移動ノードのターゲットネットワークへの接続を検出する必要があるため、有用ではない。より良い手法は、接続検出とアドレス解決マッピング更新の統合であろう。これは、アドレス解決を無償で行うこと［ＲＦＣ３３４４］、［ＲＦＣ３７７５］に基づくものであり、この場合、移動ノードは、ターゲットネットワーク内の各ノードが、移動ノードのアドレス解決マッピングを迅速に更新することができるように、ＩＰｖ４の場合にはＡＲＰ要求またはＡＲＰ応答を、ＩＰｖ６の場合には近隣告知を、移動ノードが新しいネットワークに接続した直後に送る。

５．５．ＦＡ−ＣｏＡとの事前認証
対応付けプロトコルとしてＭＩＰｖ４を使用するＩＭＳ／ＭＭＤ（ＩＰマルチメディアサブシステム／マルチメディアドメイン）アーキテクチャの場合などのような、開発シナリオの多くでは、モバイルのＩＰアドレスは、モバイルがある在圏ネットワークから別の在圏ネットワークに移動する際に変化しない。典型的な例が、モバイルがＭＩＰｖ４を使用し、ＦＡ気付アドレスを使用して、アウトバウンドＳＩＰプロキシと対話するときである。かかる状況では、モバイルのインターフェース上にはホームアドレス（ＨｏＡ）だけしかない。ＭＰＡ機構は、これの現在の形では、モバイルが、前述のＭＰＡ事前対応型トンネルの外部アドレスとしてＨｏＡを使用する場合、経路指定ループを生じる。

このシナリオでは、モバイルが、まだ、ｐＦＡと共にある間に、ＨｏＡを外部アドレスとして使ってｎＦＡと事前対応型トンネルをセットアップし、ｎＦＡの気付アドレスを有する対応付け更新を送信する場合、モバイルに向けられた任意のパケットは、まず、ｎＦＡに経路指定され、次いで、関連付けられたトンネルのために、ＨＡに返送され、結果として経路指定ループを生じることになる。

この経路指定問題を処理するために、例えば、順方向事前対応型トンネルと逆方向事前対応型トンネルなど、２つのトンネルを作成する異なるやり方を提案する。順方向事前対応型トンネルは、ｎＦＡからＭＮへのトラヒックをトンネル化するのに役立ち、モバイルからのパケットは、逆方向事前対応型トンネルを介して進む。ｐＦＡのＣｏＡを、順方向事前対応型トンネルのＭＮの外部アドレスとして使用し、モバイルｎＨｏＡを、逆方向事前対応型トンネルの外部アドレスとして使用することを提案する。ＨｏＡに向けられたトラヒックは、ｎＦＡに到着すると、ｎＦＡでセットアップされるホストベースの経路指定を使い、事前対応型トンネルを介して、ｐＦＡに経路指定される。図３に、この経路指定ループを処理するのに必要とされる非対称事前対応型トンネルのシナリオを示す。

５．６．トンネル管理
ＣＴＮ内のＤＨＣＰサーバから、ＩＰアドレスが事前に獲得された後で、移動ノードとＣＴＮ内のアクセスルータの間の事前対応型ハンドオーバトンネルが確立される。移動ノードは、獲得したＩＰアドレスをトンネル内部アドレスとして使用する。

事前対応型ハンドオーバトンネルは、トンネル管理プロトコルを使って確立される。ＩＫＥｖ２が事前対応型ＩＰアドレス獲得に使用されるとき、ＩＫＥｖ２は、トンネル管理プロトコルとしても使用される。

代替として、ＰＡＮＡが事前対応型ＩＰアドレス獲得に使用されるときには、ＰＡＮＡが、セキュアなトンネル管理プロトコルとして使用され得る。

移動ノードと候補ターゲットネットワーク内のアクセスルータの間で事前対応型ハンドオーバトンネルが確立された後で、アクセスルータは、移動ノードの新しいアドレスに向けられたパケットを取り込むことができるように、移動ノードに代わってプロキシアドレス解決も行う必要がある。

モバイルは、前のネットワークにある間に、通信相手ノードとやりとりすることができる必要があるため、対応付け更新と、通信相手ノードから移動ノードへのデータの一部または全部が、事前対応型ハンドオーバトンネルを介して移動ノードに返送される必要がある。これらの対応付け更新手順の詳細は、セクション５．６で説明する。

移動ノードがターゲットネットワークに接続した後で、トラヒックが移動ノードに宛先指定されるように、事前対応型ハンドオーバトンネルは、削除され、または無効化される必要がある。このために、トンネルを確立するのに使用されるトンネル管理プロトコルが使用される。代替として、ＰＡＮＡが認証プロトコルとして使用されるときには、アクセスルータにおけるトンネル削除または無効化は、モバイルがターゲットネットワークに移動し次第、ＰＡＮＡ更新機構によってトリガされ得る。リンク層トリガは、移動ノードが、実際にターゲットネットワークに接続されていることを保証し、トンネルを削除し、または無効化するトリガとしても使用され得る。

５．７．対応付け更新
異なるモビリティ管理方式について数種類の対応付け更新機構がある。モバイルＩＰｖ４とモバイルＩＰｖ６の場合、モバイルは、経路最適化が使用されない場合には、ホームエージェントだけと対応付け更新を行う。そうでない場合、モバイルは、ホームエージェント（ＨＡ）とも通信相手のノード（ＣＮ）とも対応付け更新を行う。ＳＩＰベースの端末モビリティの場合、モバイルは、Ｒｅ−ＩＮＶＩＴＥを使って通信相手ノードに対応付け更新を、レジストラにＲＥＧＩＳＴＥＲメッセージを送る。モバイルと通信相手ノードの間の距離に基づいて、対応付け更新は、ハンドオーバ遅延の原因となり得る。ＳＩＰ−高速ハンドオーバ［ＳＩＰＦＡＳＴ］は、対応付け更新によるハンドオーバ遅延を低減するいくつかのやり方を提供する。ＳＩＰベースのモビリティ管理を使ったセキュアな事前対応型ハンドオーバの場合には、対応付け更新が前のネットワーク内で行われるため、対応付け更新による遅延が完全に除外される。よって、この方式は、通信相手ノードが、通信を行う移動ノードから離れすぎているときに、より魅力的に思われる。同様に、モバイルＩＰｖ６の場合には、モバイルは、ターゲットネットワークからの新しく獲得されるＣｏＡを、対応付け更新としてＨＡとＣＮに送る。

また、ＭＮとＨＡの間と、ＭＮとＣＮの間のすべての信号メッセージも、このセットアップされるトンネルを介して渡される。これらのメッセージには、対応付け更新（ＢＵ）、対応付け確認（ＢＡ）、および関連付けられる、ＨｏｍｅＴｅｓｔＩｎｉｔ（ＨｏＴＩ）、ＨｏｍｅＴｅｓｔ（ＨｏＴ）、Ｃａｒｅ−ｏｆＴｅｓｔＩｎｉｔ（ＣｏＴＩ）、Ｃａｒｅ−ｏｆＴｅｓｔ（ＣＯＴ）などの関連する往復経路確認メッセージが含まれる。

事前対応型ハンドオーバトンネルは、ＩＰｓｅｃトンネルとして実現される場合、トンネル終点間のこれらの信号メッセージも保護し、往復経路確認テストをより安全にする。また、任意の後続データも、モバイルが前のネットワーク内にある限り、トンネル化される。添付の文献［Ｉ−Ｄ．ｏｈｂａｍｏｂｏｐｔｓ−ｍｐａ−ｉｍｐｌｅｍｅｎｔａｔｉｏｎ］では、対応付け更新と往復経路確認のための信号交換が、保護されたトンネルを介してどのように送られるかについて詳細を論じている。

５．８．パケット損失防止
５．８．１．単一インターフェースのＭＰＡにおけるパケット損失防止
単一インターフェースのＭＰＡでは、リンク層ハンドオーバ時に、移動ノードがターゲットネットワークに接続する前に、旧い接続点において移動ノードに向けられる若干の一時パケットが生じ得る。これらの一時パケットは、失われることがある。旧い接続点のアクセスルータにおいて汎用バッファを使用すれば、パケット損失を無くすことができる。ＭＮから知らされるインテリジェントバッファリング技法が、ハンドオーバ時に一時トラヒックを暫定的に保持することができ、次いで、ＭＮがターゲットネットワークに到達可能になると、これらのパケットは、ＭＮに転送され得る。

代替の方法が、バイキャストを使用するものである。しかしながら、リンク層ハンドオーバがシームレスに行われない場合に、バイキャストではパケット損失が無くならない。他方、バッファリングは、パケット遅延を低減しない。パケット遅延は、ストリーミングアプリケーションでは、受信側のプレイアウトバッファによって補償され得るが、プレイアウトバッファは、大きな遅延ジッタを許容することのできない対話型ＶｏＩＰアプリケーションではあまり役に立たない。よって、いずれにしても、リンク層ハンドオーバを最適化することはやはり重要である。

５．８．２．複数インターフェースのＭＰＡにおけるパケット損失防止
複数インターフェースハンドオーバシナリオにおけるＭＰＡ使用は、現在のアクティブインターフェースによる使用のための第２のインターフェースを作成することを伴う。

この作成には、事前認証と、第２のインターフェースが最終的なアクティブインターフェースとなるはずのターゲットネットワークにおける準備が関与する。一例が、ＣＤＭＡネットワークにおける事前認証がＷｉＦｉインターフェースを介して行われ得る、ＷｉＦｉからＣＤＭＡネットワークへの技術間ハンドオーバであろう。ハンドオーバは、ＣＤＭＡインターフェースがＭＮのアクティブインターフェースになるときに行われる。かかるシナリオでは、両方のインターフェースがアクティブである間にハンドオーバが行われた場合、一般に、旧いインターフェースに向けられた一時パケットも依然としてＭＮに到達するため、パケット損失が生じない。しかしながら、現在のアクティブインターフェースの急な切断を使って、作成されたインターフェースへのハンドオーバが開始される場合、切断されたインターフェース向けの一時パケットは、ＭＮが作成されたインターフェースで到達可能になろうとしている間に失われるであろう。かかる場合には、パケットが、単に、切断より前に現在のアクティブネットワーク内のアクセスルータにおいてコピーされるだけの、特化した形のバッファリングを使って、パケット損失を無くすことができる。急な切断が行われない場合、コピーされたパケットは、作成されたインターフェースがアクティブな到達可能インターフェースとなった後で、ＭＮに転送され得る。このコピー／転送機構は、複数インターフェースのハンドオーバだけに限られるものではない。

また、単一インターフェースシナリオでも、汎用バッファリングの代わりに、コピー／転送を用いることができるが、これの使用は、急な切断のシナリオでは、ほとんど自明である。このプロセスの目立った副次的作用が、新しいアクティブインターフェースにおける転送時のパケットの重複の可能性である。この影響を最小限に抑えるいくつかの手法が用いられ得る。ＴＣＰなどの上位層プロトコルを利用して重複を検出し、除去するのが最も一般的なやり方である。また、専用の重複除去処理機構も使用され得る。一般に、パケット重複は、ＭＮによってローカルで処理され得る周知の問題である。また、現在のアクティブインターフェースの切断イベントの冗長な検出も、ハンドオーバプロセスの長さに悪影響を及ぼし得る。よって、かかるシナリオでは、インターフェース切断を検出する最適化された方式を使用することが必要になる。

５．８．３．到達可能性テスト
前述の技法に加えて、ＭＮは、旧い接続点から切り換わる前に、新しい接続点への到達可能性を確認することもできる。これは、新しい接続点とリンク層管理フレームを交換することによって行われ得る。この到達可能性チェックは、できるだけ迅速に行われるべきである。この到達可能性チェック時のパケット損失を防ぐために、到達可能性チェック時に、ＭＮと旧い接続点の間のリンクを介したパケットの送信を中断して、リンクの両端においてパケットがバッファリングされる必要がある。このバッファリングをどのようにして行うべきかは、当業者には理解されるはずである。このバッファリング方式を使用する結果の一部は、添付の実施文献で説明されている。

５．９．切換えの失敗およびスイッチバックについての考慮
ピンポン効果は、ハンドオーバシナリオ時の見られる一般的な問題の１つである。ピンポン効果は、モバイルがセルまたは決定点の境界線に位置しており、ハンドオーバ手順が頻繁に実行されるときに生じる。この結果、コールドロップ確率がより高まり、接続品質がより低下し、信号トラヒックおよびリソース浪費が増大する。これらはすべて、モビリティ最適化に影響を及ぼす。ハンドオフアルゴリズムは、ネットワーク間のハンドオフを行うための決定要因である。従来から、これらのアルゴリズムは、閾値を用い、様々なメトリックの値を比較してハンドオフを決定する。これらのメトリックには、信号強度、経路損失、搬送波対インターフェース比（ＣＩＲ）、信号対インターフェース比（ＳＩＲ）、ビット誤り率（ＢＥＲ）、電力バジェットなどが含まれる。ピンポン効果を回避するために、決定アルゴリズムによって、ヒステレシスマージン、ドゥエルタイマ、平均ウィンドウなど、いくつかの追加パラメータが用いられる。高速移動車両では、移動ノードと接続点の間の距離、モバイルの速度、モバイルの位置、トラヒックおよび帯域幅の特性など他のパラメータも、ピンポン効果を低減するために考慮される。最近では、仮説検証、動的プログラミング、パターン認識手法などの技法に基づく、異種混交ネットワーク環境におけるピンポン効果を低減するのに役立つ他のハンドオフアルゴリズムもある。ピンポン効果を低減する洗練されたハンドオフアルゴリズムを考案することは重要であるが、これらの影響から回復する方法を考案することも重要である。ＭＰＡフレームワークの場合には、ピンポン効果の結果として、モバイルが、現在のネットワークとターゲットネットワークの間、および候補ターゲットネットワーク間を行ったりすることになる。ＭＰＡは、これの現在の形では、ピンポン状況からもたらされる、多数のトンネルセットアップ、多数の対応付け更新、関連するハンドオフ待ち時間のために影響を被る。ピンポン効果は、ハンドオフ率に関連するため、遅延とパケット損失の原因にもなり得る。発明者らは、ピンポンの確率を低減するのに役立ついくつかのアルゴリズムを提案すると共に、ピンポン効果からもたらされるパケット損失から回復するためのＭＰＡフレームワークのいくつかの方法を提案する。

ＭＰＡフレームワークは、ＧＰＳを使って、モバイルの隣接するネットワーク内のＡＰに対する地理位置を利用することができる。ネットワーク間の変動を回避するために、ユーザの位置と、前のハンドオーバ試行からのキャッシュデータの間の相関を使って、位置ベースのインテリジェントアルゴリズムを導出することができる。

場合によっては、位置だけが、ハンドオフ決定の唯一の指標になるとは限らないこともある。例えば、マンハッタン型のネットワークでは、モバイルは、ＡＰの近くにあっても、良好な接続を行うのに十分なＳＮＲ（信号対雑音比）を持たないこともある。よって、モビリティパターン、呼のドゥエルタイムおよび経路識別の知識が、ピンポン問題を回避するのに大いに役立つ。

ピンポン効果を回避できる適切なハンドオフアルゴリズムがない場合、ピンポン効果を緩和するための適切な回復機構を導入することが必要になる。現在のネットワークにおいて確立されたコンテキストを一定の期間にわたって保持し、モバイルが、このコンテキストが最後に使用されたネットワークに戻るときに、このコンテキストが迅速に回復されるようにすることが必要である。これらのコンテキストには、セキュリティアソシエーション、使用されたＩＰアドレス、確立されたトンネルなどが含まれ得る。また、所定の期間にわたって、前のネットワークと新しいネットワークの両方にデータをバイキャストすることも、モバイルが、ネットワーク間を行ったり来たりする場合に、損失パケットを管理するのに役立つ。

モバイルは、ピンポン状況に関して安定した状態にあるかどうか判定することができる必要がある。

ＭＰＡフレームワークが、ＩＫＥｖ２とＭＯＢＩＫＥの組み合わせを利用するとき、ピンポン効果はさらに低減され得る［ＭＰＡ−ＭＯＢＩＫＥ］。

５．１０．認証状態管理
複数のターゲットネットワークとの事前認証の場合には、隣接するネットワークのそれぞれの認証エージェントにおいて、この状態をある期間にわたって維持することが必要である。よって、モバイルが隣接するネットワーク間を行ったり来たりする場合には、すでに維持されている認証状態が役立ち得る。以下で、複数セキュリティアソシエーション状態管理に関して若干の特徴を示す。

候補ターゲットネットワーク内の認証エージェントに事前認証されており、ＭＰＡ−ＳＡを有するＭＮは、現在のネットワーク内に留まり続ける間、または候補ターゲットネットワークとは異なるネットワークにハンドオーバした後でさえも、ＭＰＡ−ＳＡを保持し続ける必要がある。

現在のネットワーク内の認証エージェントによって認証され、許可されているＭＮは、ターゲットネットワークへのハンドオーバを行うとき、このＭＮがピンポン効果により前のネットワークに戻る場合に、ＳＡを最初から作成するために認証信号交換全部を行わなくても済むように、ＭＮと認証エージェントの間で確立されているＳＡを一定の期間にわたって保持ようとする。ＭＮの他のネットワークへのハンドオーバ後に認証エージェントで保持されるかかるＳＡは、ＭＰＡ−ＳＡであるとみなされる。この場合、認証エージェントは、ＭＮの完全に許可された状態を、無許可の状態に変更する必要がある。無許可の状態は、ＭＮがこのネットワークに戻り、ＭＰＡ−ＳＡに関連付けられた鍵の所有の証拠を提供するときに限って、完全に許可された状態に変更され得る。

ＭＰＡ−ＳＡが認証エージェントにおいて保持されている間、ＭＮは、ＭＮのＩＰアドレスがハンドオーバにより変化するときに、認証エージェントを更新し続けることが必要になる。

５．１１．ＱｏＳリソースの事前割振り
事前構成段階には、移動ノードによって、ハンドオーバ後のみならず、ハンドオーバ前にも使用され得るＱｏＳリソースを事前割振りすることも可能である。事前割振りＱｏＳリソースは、ハンドオーバ前に使用されるとき、事前対応型ハンドオーバトンネルを介して搬送されるアプリケーショントラヒックに使用される。

ＱｏＳリソースがエンドツーエンドで事前割振りされることも可能である。この事前対応型ＱｏＳ予約を行う１つの方法は、事前対応型ハンドオーバトンネルがＱｏＳ信号交換を保護するためにセキュリティアソシエーションをブートストラップするのに使用され得る事前対応型ハンドオーバトンネル上でＮＳＩＳ信号層プロトコル（ＮＳＬＰ）［Ｉ−Ｄ．ｉｅｔｆ−ｎｓｉｓ−ｑｏｓ−ｎｓｌｐ］またはリソース予約プロトコル（ＲＳＶＰ）［ＲＦＣ２２０５］を実行するものである。この場合、ＱｏＳリソースは、通信相手ノードとターゲットアクセスルータの間の経路上で事前割振りされ、ハンドオーバの前と後で継続して使用され得る。他方、ハンドオーバ前に事前割振りＱｏＳリソースを使用するときには、ハンドオーバの前と後で、ターゲットアクセスルータと移動ノードの間の経路が異なるため、ターゲットアクセスルータと移動ノードの間のＱｏＳリソースの重複した事前割振りが必要になるはずである。

ハンドオーバ後にターゲットアクセスルータと移動ノードの間の経路に使用されるべきＱｏＳリソースは、ＮＳＬＰを経路外信号交換で動作するように拡張することによって（注：この経路は、ハンドオーバ前に経路外とみなされ得る）、またはメディア特有のＱｏＳ信号交換によって事前割振りされ得る。

５．１２．スケーラビィティとリソース割振り
複数のＣＴＮの場合、隣接するターゲットネットワークと複数のトンネルを確立すると、若干の追加利益がもたらされる。しかし、これは、いくつかのスケーラビィティリソース利用問題の一因にもなる。複数の候補ターゲットネットワークとの事前認証プロセスは、いくつかのやり方で行われ得る。

ごく基本的な方式は、モバイルの隣接するネットワーク内の複数の認証エージェントとの認証を行うことを伴うが、実際の事前構成と対応付け更新は、特定のネットワークへのレイヤ２移動が完了した後にはじめて行われる。前もって事前認証を行わせることによって、モバイルは、新しいネットワークに移動した後で、それ以上の認証を行わなくてすむ。

構成と対応付け更新は、実際には、モバイルが新しいネットワーク移動した後で行われ、よって、遅延の一因となり得る。

同様に、事前認証に加えて、モバイルは、前のネットワークにある間に事前構成を完了することもできるが、モバイルが移動した後まで対応付け更新を延期することができる。このように、モバイルは、前もって隣接するネットワークから複数のＩＰアドレスを獲得し、これらのＩＰアドレスを、一定の期間にわたってキャッシュに格納することができる。隣接するネットワークからのＩＰアドレスをキャッシュすることができることにより、モバイルは、ハンドオーバ後に、ＩＰアドレス獲得のために余分な時間を費やす必要がない。前述の場合と同様に、この場合も、モバイルは、事前構成されたトンネルをセットアップする必要がない。事前認証プロセスと事前構成プロセスの一部は、モバイルが新しいネットワークに移動する前に処理されるが、対応付け更新は、実際には、モバイルが移動した後に行われる。

第３の種類の複数事前認証には、モバイルが前にネットワークにある間に、認証、構成および対応付け更新などの３つのステップすべてが関与する。しかし、この特定のプロセスは、リソース量の大部分を利用する。以下に、このプロセスの間に使用されるリソースのいくつかを示す。

１）隣接するネットワーク内での事前認証のための追加信号交換。

２）隣接するネットワークのＩＰアドレスを、ある一定の期間にわたってモバイルキャッシュに保持すること。これは、これらのＩＰアドレスを格納するためのモバイルにおける追加処理を必要とする。加えて、隣接するルータからの一時ＩＰアドレスも使い果たす。

３）隣接するネットワーク内のターゲットルータとモバイルと追加の一時トンネルをセットアップすることに伴う追加コストが生じる。

４）隣接するネットワークから獲得される複数のＩＰアドレスを有する対応付け更新の場合、複数の一時ストリームが、これらの一時トンネルを使って、ＣＮとモバイルの間で流れる。

事前認証と事前構成だけが、前もって複数のネットワークと行われるとき、モバイルは、ＣＮに１つの対応付け更新を送る。この場合、レイヤ２ハンドオフ後に、いつ対応付け更新を送るべきか知ることが重要である。

複数のコンタクトアドレスを有する対応付け更新が送られる場合には、一時トンネルを使って、ＣＮから複数のメディアストリームが生じる。しかし、この場合には、ハンドオーバ後に、モバイルが移動した先の新しいアドレス（ただ１つのアドレス）に設定されたコンタクトアドレス別の対応付け更新を送る必要がある。このように、モバイルは、モバイルが移動しなかった他の隣接するネットワークへのメディア送信を停止する。

以下は、モバイルが特定のネットワークだけに移動するが、前のネットワーク内で複数の対応付け更新を送るときの、複数の対応付けストリームを処理する、この特定の場合を例示するものである。ＭＮは、ＣＨに、３つの隣接するネットワークから獲得された、ｃ１、ｃ２、ｃ３など複数のコンタクトアドレスを有する対応付け更新を送る。これは、ＣＮが、事前に確立されたトンネルを介して、モバイルに複数の一時ストリームを送ることを可能にする。モバイルは、実際にネットワークに移動した後で、ＣＮに、モバイルが移動した先のネットワーク内のモバイルの気付アドレスを有する別の対応付け更新を送る。複数のストリームに伴う問題の一部は、余分の帯域幅を短期間の間に消費することである。

代替として、ターゲットアクセスルータまたはホームエージェントにおいてバッファリング手法を適用することもできる。一時データは、モバイルが移動した後でモバイルに転送され得る。データの転送は、モバイルにより、モバイルＩＰ登録の一部として、または別個のバッファリングプロトコルとしてトリガされ得る。

５．１３．リンク層のセキュリティとモビリティ
事前認証段階に、移動ノードとＣＴＮの認証エージェントの間で確立されるＭＰＡ−ＳＡを使用すると、以下のように、移動ノードが現在のネットワーク内にある間にＣＴＮにおけるリンク層セキュリティをブートストラップすることが可能である。参考のために、図４に、いくつかの例による、リンク層セキュリティのブートストラップの例を示す。

（１）認証エージェントと移動ノードは、正常な事前認証の結果として確立されるＭＰＡ−ＳＡを使ってＰＭＫ（マスタ鍵ペア）［Ｉ−Ｄ．ｉｅｔｆ−ｅａｐ−ｋｅｙｉｎｇ］を導出する。ＭＰＡ−ＳＡを確立する事前認証時には、ＥＡＰとＡＡＡプロトコルの実行が関与し得る。ＰＭＫから、移動ノードのための別個のＴＳＫ（一時セッション鍵）［Ｉ−Ｄ．ｉｅｔｆ−ｅａｐ−ｋｅｙｉｎｇ］がＣＴＮの各接続点ごとに、直接的または間接的に導出される。

（２）認証エージェントは、ＰＭＫから導出される、接続点へのセキュアアソシエーションに使用される鍵をインストールする。導出鍵は、ＴＳＫとすることもでき、ＴＳＫを導出するための中間鍵とすることもできる。

（３）移動ノードは、ＣＴＮをターゲットネットワークとして選択し、（次に移動ノードの新しいネットワークとなる）ターゲットネットワーク内の接続点に切り換わった後で、移動ノードと接続点の間でリンク層パケットを保護するのに使用されるＰＴＫ（一時鍵ペア）とＧＴＫ（グループ一時鍵）［Ｉ−Ｄ．ｉｅｔｆ−ｅａｐ−ｋｅｙｉｎｇ］を確立するために、ＰＭＫを使って、ＩＥＥＥ８０２．１１ｉ４方向ハンドシェーク［８０２．１１ｉ］などのセキュアアソシエーションプロトコルを実行する。ここでは、ＥＡＰ認証の追加実行は不要である。

（４）移動ノードが新しいネットワークでローミングする間、移動ノードは、ただ、これの接続点とセキュアアソシエーションプロトコルを実行しさえすればよく、ＥＡＰ認証の追加実行も不要である。８０２．１１ｒなどのリンク層ハンドオーバ最適化機構とＭＰＡとの統合は、このように実現され得る。

移動ノードは、ＴＳＫを導出するために、ＣＴＮ内の接続点のリンク層識別情報を知る必要がある。事前認証のための認証プロトコルにＰＡＮＡが使用される場合、これは、ＰＡＡ［Ｉ−Ｄ．ｉｅｔｆ−ｐａｎａ−ｐａｎａ］から送られるＰＡＮＡ−Ｂｉｎｄ−Ｒｅｑｕｅｓｔメッセージで、それぞれが別個のアクセスポイントのＢＳＳＩＤを含むデバイス識別ＡＶＰを搬送することによって可能である。

５．１４．初期ネットワーク接続における認証
移動ノードが最初にネットワークに接続するときには、ネットワークアクセス認証が、ＭＰＡの使用のいかんを問わずに行われるはずである。ハンドオーバ最適化にＭＰＡが使用されるときに、ネットワークアクセス認証に使用されるプロトコルは、ＩＥＥＥ８０２．１Ｘなどのリンク層ネットワークアクセス認証プロトコル、またはＰＡＮＡなどの上位層ネットワークアクセス認証プロトコルとすることができる。

５．１５．マルチキャストモビリティ
グループベースの通信は常に受信側主導である。特定のモバイルは、１つまたは複数のＩＰマルチキャストグループに加入することができる。モバイルが新しいネットワークに移動すると、マルチキャスト通信は、関連する参加待ち時間のために中断される。この中断は、モバイルの移動時の参加待ち時間を低減することによって最小化され得る。マルチキャストモビリティは、ホームサブスクリプションベース、またはリモートサブスクリプションベースとすることができる。ホームサブスクリプションベース手法では、モバイルに代わって参加する、ホームネットワーク内のマルチキャストルータがある。しかし、すべてのデータおよび制御信号は、ホームエージェントと移動先エージェントまたはモバイルの間でトンネル化される。ホームサブスクリプションベースの手法は、ＭＩＰｖ４またはＭＩＰｖ６以外のモビリティプロトコルには適さない。というのは、この手法がホームネットワークのマルチキャストルータとトンネルに依存するからである。他方、リモートサブスクリプションベースの手法は、前述の手法とは異なり、ホームエージェントの負担を増やさず、移動が行われる都度、リモートネットワーク内の第１のホップルータとやりとりする。ＭＰＡは、両手法での事前対応型マルチキャストモビリティサポートを提供するのに役立ち得る。まず、ＭＰＡの場合のリモートサブスクリプションベースの手法について説明する。

ＭＰＡの場合に、事前にマルチキャストツリーに参加することによって、参加待ち時間を低減する２つの方法がある。ＭＰＡシナリオでは、モバイルが新しいネットワークに移動しようとしているときに、次のアクセスルータ（ＮＡＲ）が、マルチキャストプロキシとして振る舞うことができる。モバイルが事前認証された後のＭＰＡプロセスの事前構成段階の間に、モバイルは、現在加入しているマルチキャストグループに関する情報を渡すことができる。一例として、次のネットワーク内の構成サーバと対話することによって現在のネットワーク内でモバイルを事前構成するためのプロトコルとしてＰＡＮＡが使用される場合、モバイルは、ＰＵＲメッセージの一部として、ＰＡＡ（ＰＡＮＡ認証エージェント）に現在加入しているグループの情報を渡すこともできる。ＰＡＡは、さらに、ＮＡＲとやりとりして、上流ルータへのマルチキャスト参加をトリガすることができる。よって、モバイルとＮＡＲの間のトンネルセットアッププロセスの間に、ＮＡＲも、モバイルに代わってマルチキャストグループに参加する。代替として、モバイルは、モバイルが移動する前でさえも、現在のネットワーク内で作成されるトンネルを使って、ＮＡＲに直接マルチキャスト参加要求を送ることもできる。この場合、マルチキャスト参加要求の送信元アドレスは、ＮＡＲが、この要求がどのインターフェースからもたらされたか理解し、このインターフェースに加入ホストがあると想定するように、モバイルのトンネル終点アドレスの送信元アドレスに設定される。どちらの場合にも、ＮＡＲは、マルチキャストルータとしても構成されているものと仮定する。モバイルは、現在のネットワーク内にあるとき、依然として、これの現在構成されているＩＰアドレス上で、前のアクセスネットワーク（ＰＡＲ）を介して、マルチキャストトラヒックを受け取ることができる。しかし、モバイルは、新しいネットワークに移動し、トンネルを削除し次第、同じグループマルチキャストアドレス上でマルチキャストトラヒックを、ほとんどゼロ参加待ち時間で受信し始める。モバイルは、前もってすでにアドレスを獲得しているため、これのインターフェースを構成するのに時間を費やす必要もない。ホームサブスクリプションベースの手法の場合には、ＭＰＡは、マルチキャストサービスのモビリティサポートを、ＭＩＰｖ４とＭＩＰｖ６の両方にユニキャストサービスを提供するように提供することができる。データは、モバイルと次のアクセスルータの間の一時ＭＰＡトンネルを介して、前のネットワーク内のモバイルに配信される。

このトンネルは、普通、トンネル内のトンネルである。モバイルが新しいネットワークに移動する際には、通常のＭＩＰトンネルが、新しいネットワーク内でのマルチキャストトラヒックの配信を処理する。この機構は、マルチキャストストリームの高速配信を可能にする。というのは、ホームエージェントが、すでに、新しいネットワークに向けられたマルチキャストトラヒックを送信し始めているからである。

５．１６．ＩＰ層セキュリティおよびモビリティ
ＩＰ層セキュリティは、通常、ＩＰｓｅｃによって、モバイルと、第１のホップルータまたはＳＩＰプロキシなど他の任意のネットワーク要素の間で維持される。このＩＰｓｅｃＳＡは、トンネルモードでも、ＥＳＰモードでもセットアップされ得る。しかしながら、モバイルが移動し、新しいネットワークにおいてルータのＩＰアドレスとアウトバウンドプロキシが変化する際に、モバイルのＩＰアドレスは、使用されるモビリティプロトコルによって、変化することも変化しないこともある。これは、モバイルと所望のネットワークエンティティの間の新しいセキュリティアソシエーションの再確立を保証する。３ＧＰＰ／３ＧＰＰ２ＩＭＳ／ＭＭＤ環境の場合など、場合によっては、モバイルとアウトバウンドプロキシの間で確立されたＩＰｓｅｃＳＡがない限り、データトラヒックは、通過することを許されない。これは、当然ながら、モバイルの移動時に、既存のリアルタイム通信に不合理な遅延を追加する。このシナリオでは、鍵交換が、ＡＫＡ（認証と鍵共有）と呼ばれる鍵交換手順に従うＳＩＰ登録の一部として行われる。

ＭＰＡは、新しいアウトバウンドプロキシによる事前認証の一部としてこのセキュリティアソシエーションをブートストラップするのに使用され得る。移動より前に、モバイルが、ターゲットネットワーク内の新しいアウトバウンドプロキシを介して事前登録を行うことができ、事前認証手順を完了する場合、モバイルと新しいアウトバウンドプロキシの間の新しいＳＡ状態が、新しいネットワークへの移動より前に確立され得る。また、類似の手法は、ＡＫＡ以外の鍵交換機構が使用され、またはセキュリティアソシエーションが確立される必要のある相手のネットワーク要素がアウトバウンドプロキシと異なる場合にも適用され得る。

前もってセキュリティアソシエーションを確立させることによって、モバイルは、移動後に新しいセキュリティアソシエーションをセットアップするためのどのような交換にも関与しなくてよい。これ以外の鍵交換は、期限を更新するためだけに限定される。また、これは、リアルタイム通信の遅延も低減する。

５．１７．ＭＰＡの他の高速ハンドオフ司法への適用可能性
ＭＰＡと関連付けられる技法と、ＦＭＩＰｖ６の事前対応部分など、他の関連する高速ハンドオフ機構の間にはいくつかの類似点がある。これらのハンドオフ技法両方の実験結果は、これらの結果がレイヤ２遅延によって制限されることを示している。しかしながら、これらがＩＥＥＥ８０２．２１ネットワーク探索機構によって強化される場合には、レイヤ２ハンドオフ遅延も最適化され得る。

これは、添付の草案［Ｉ−Ｄ．ｏｈｂａｍｏｂｏｐｔｓ−ＭＰＡ−ｉｍｐｉｅｍｅｎｔａｔｉｏｎ］に記載されている。他方、ＭＰＡのいくつかの特徴は、ＦＭＩＰｖ６［ＲＦＣ４０６８］の機能を拡張するのにも使用され得る。特に、ＭＰＡのレイヤ２とレイヤ３両方での事前認証機能と、ステートフル事前構成機能は、ＦＭＩＰｖ６にも使用され得る。

６．セキュリティ考慮事項
本明細書は、移動ノードと、移動ノードが将来の移動先とし得る１つまたは複数の候補ターゲットネットワークの間でハンドオーバ関連の信号交換を行うことに基づく、セキュアなハンドオーバ最適化機構のフレームワークを説明するものである。このフレームワークには、ＣＴＮからのリソースの獲得と、移動ノードが物理的にこれらのＣＴＮの１つに接続する前の、ＣＴＮから現在のネットワーク内の移動ノードへのデータパケット宛先変更を伴う。

候補ターゲットネットワークからのリソースの獲得は、無許可の移動ノードがリソースを獲得するのを防ぐために、適切な認証および許可手順を伴わなければならない。このためには、ＭＰＡフレームワークが、移動ノードと候補ターゲットネットワークの間で事前認証を行うことが重要である。正常な事前認証の結果として生成されるＭＮ−ＣＡ鍵とＭＮ−ＡＲ鍵は、移動ノードと、ＣＴＮ内のＭＰＡ機能要素の間で交換される後続のハンドオーバ信号パケットとデータパケットを保護することができる。

また、ＭＰＡフレームワークは、ハンドオーバが複数の管理ドメインにまたがって行われるときのセキュリティ問題にも対処する。ＭＰＡではハンドオーバ信号交換を、移動ノードと、候補ターゲットネットワーク内のルータまたはモビリティエージェントの間の直接通信に基づいて行わせることが可能である。これにより、セキュリティと認証に関して限界があることが分かっているコンテキスト転送プロトコルが不要になる。［Ｉ−Ｄ．ｉｅｔｆ−ｅａｐ−ｋｅｙｉｎｇ］。このために、ＭＰＡフレームワークは、管理ドメインまたはアクセスルータの間の信頼関係を必要とせず、これが、このフレームワークを、モバイル環境におけるセキュリティを損なうことなく、インターネットでより配置しやすいものにしている。

本発明の広い範囲
本明細書では、本発明の例示的実施形態を説明しているが、本発明は、本明細書で説明した様々な好ましい実施形態だけに限定されず、本開示に基づけば当分野の技術者によって理解されるはずの、等価の要素、改変、省略、（様々な実施形態にまたがる態様などの）組合せ、適合及び／又は変更を有するありとあらゆる実施形態を含むものである。特許請求の範囲における限定は、特許請求の範囲で用いられる言葉に基づいて幅広く解釈されるべきであり、本明細書において、又は本出願の出願中において記述される例だけに限定されず、これらの例は、非排他的であると解釈されるべきである。例えば、本開示において、「好ましくは」という用語は、非排他的であり、「それだけに限らないが、好ましくは」を意味する。本開示において、かつ本出願の出願中において、手段プラス機能又はステッププラス機能限定は、特定のクレーム限定について、この限定において、ａ）「〜の手段」又は「〜のステップ」が明記されている、ｂ）対応する機能が明記されている、及びｃ）構造、材料又はこの構造をサポートする動作が記載されていないという条件すべてが存在する場合に限り用いられる。本開示において、かつ本出願の出願中において、「本発明」又は「発明」という用語は、本開示内の１つ又は複数の態様を指すものとして使用され得る。本発明又は発明という言葉は、誤って重要度の識別と解釈されるべきではなく、誤ってすべての態様又は実施形態にわたって適用されるものと解釈されるべきではなく（すなわち、本発明はいくつかの態様及び実施形態を有すると理解されるべきであり）、また、誤って本出願又は特許請求の範囲を限定するものと解釈されるべきではない。本開示において、かつ本出願の出願中において、「実施形態」という用語は、任意の態様、特徴、プロセス又はステップ、これらの任意の組合せ、及び／又はこれらの任意の部分などを記述するのに使用され得る。いくつかの例では、様々な実施形態が重なり合う特徴を含み得る。本開示では、「例えば」を意味する「ｅ．ｇ．」、「特に」を意味する「ｉ．ａ．」という省略用語が用いられ得る。

メディア独立事前認証（ＭＰＡ）の例示的コールフローを示す図である。メディア独立事前認証（ＭＰＡ）の例示的コールフローを示す図である。用いられ得る非対称事前対応型トンネルの例示的シナリオを示す図である。いくつかの例によるリンク層セキュリティのブートストラップの例を示す図である。いくつかの例によるシステムアーキテクチャの例示的構成要素を示す例示的アーキテクチャ図である。アクセスポイント、ユーザ局、実施形態によっては送信元ノードや宛先ノードなどといった装置によって実行されるべき、コンピュータ化プロセスステップを実施するのに使用され得る例示的コンピュータまたは制御ユニットによる特徴を示す図である。

Claims

複数のターゲットネットワークとのメディア独立事前認証のための移動ノードの認証状態の管理方法であって、
複数の隣接するネットワークの認証エージェントにおいて一定期間の間状態を維持することと、
前記移動ノードが前記隣接するネットワーク間を行ったり来たりするときに、前記認証エージェント内の前記維持されている状態を用いることと、
を含む方法。
複数のターゲットネットワークとのメディア独立事前認証のための移動ノードの認証状態の管理方法であって、
現在のネットワーク内の認証エージェントによって認証され、許可されている移動ノードが、ターゲットネットワークへのハンドオーバを行うときに、前記移動ノードが前記現在のネットワークに戻るときに、新しいセキュリティアソシエーションを作成するための認証信号交換の全てを行わなくても済むように、前記移動ノードと前記認証エージェントの間で確立されているセキュリティアソシエーション（ＭＰＡ−ＳＡ）を、前記移動ノードが前記現在のネットワークからの移動後一定期間の間保持することを含む方法。
前記認証エージェントが前記現在のネットワークからの移動後に、前記移動ノードの完全に許可された状態を無許可の状態に変更することと、
前記移動ノードが前記現在のネットワークに戻り、前記ＭＰＡ−ＳＡと関連付けられた鍵の所有の証拠を提供するときに、前記無許可の状態を許可された状態に変更することと、
をさらに含む請求項２記載の方法。
認証エージェントにおいてＭＰＡ−ＳＡが保持されている間、前記移動ノードは、ハンドオーバにより該移動ノードのＩＰアドレスが変化するときに前記認証エージェントを更新する請求項３記載の方法。
複数のターゲットネットワークとのメディア独立事前認証のための移動ノードの認証状態の管理システムであって、
現在のネットワーク内の認証エージェントによって認証され、許可されている移動ノードが、ターゲットネットワークへのハンドオーバを行うとき、前記移動ノードが前記現在のネットワークに戻るときに、新しいセキュリティアソシエーションを作成するための認証信号交換の全てを行わなくても済むように、前記移動ノードと前記認証エージェントの間で確立されているセキュリティアソシエーション（ＭＰＡ−ＳＡ）を、前記移動ノードが前記現在のネットワークから移動後一定期間の間保持する装置を含むシステム。
前記ＭＰＡ−ＳＡと関連付けられた鍵をキャッシュする手段をさらに含む請求項５記載のシステム。
候補ターゲットネットワーク内の認証エージェントに対して事前認証され、ＭＰＡ−ＳＡを確立した後、前記現在のネットワーク内に留まる間、及び前記候補ターゲットネットワークとは異なるネットワークにハンドオーバした後も、前記ＭＰＡ−ＳＡを保持する移動ノードを含む請求項６記載のシステム。
移動ノードが現在のネットワークからターゲットネットワークへハンドオーバする前に、前記移動ノードのためのサービス品質（ＱｏＳ）リソースを事前割振りする方法であって、事前認証を用いて、アプリケーショントラヒックを搬送する事前対応型ハンドオーバトンネルのためにセキュリティアソシエーションをブートストラップすることを含む方法。
前記ＱｏＳリソースは、前記事前対応型ハンドオーバトンネル上でプロトコルを実行するエンドツーエンドで割り振られ、前記事前認証は、前記事前対応型ハンドオーバトンネルがＱｏＳ信号交換を保護するために前記セキュリティアソシエーションをブートストラップするのに使用される請求項８記載の方法。
前記事前対応型ハンドオーバトンネル上で実行される前記プロトコルは、ＮＳＬＰまたはＲＳＶＰを含む請求項９記載の方法。
ハンドオーバの前と後に、通信相手ノードとターゲットアクセスルータとの間でＱｏＳリソースを継続して使用することをさらに含む請求項８記載の方法。
ハンドオーバ前に事前割振りされたＱｏＳリソースを使用するときに、ハンドオーバの前と後の前記ターゲットネットワーク内のターゲットアクセスルータと前記移動ノードとの間の経路の相違のために、前記ターゲットアクセスルータと前記移動ノードとの間にＱｏＳリソースの重複事前割り振りを用いることをさらに含む請求項８に記載の方法。
ハンドオーバ後に前記ターゲットアクセスルータと前記移動ノードとの間の経路に使用されるＱｏＳリソースは、プロトコルを経路外信号交換で動作するように拡張することによって、またはメディア特有のＱｏＳ信号交換によって事前に割り振られる請求項１２記載の方法。
移動ノードが現在のネットワークからターゲットネットワークへハンドオーバする前に、前記移動ノードにサービス品質（ＱｏＳ）リソースを事前割振りするシステムであって、
アプリケーショントラヒックを搬送する事前対応型ハンドオーバトンネルのためにセキュリティアソシエーションをブートストラップするために、事前認証を用いる装置を含むシステム。
移動ノードの移動先となり得る複数の隣接するターゲットネットワークと複数のトンネルを確立することを含む、ネットワーク間での前記移動ノードのハンドオーバに関連してスケーラビィティとリソース割振りを拡張する方法であって、
前記移動ノードが現在のネットワーク内にある間に、前記移動ノードと複数の隣接するターゲットネットワーク内の認証エージェントの間で複数の事前認証を行うことと、
前記移動ノードが前記現在のネットワーク内にある間、前記移動ノードのレイヤ２移動より前に、複数の対応付け更新を行うことと、
を含む方法。
前記移動ノードは、前記現在のネットワーク内にある間に、複数の候補ターゲットネットワークに関連する事前認証と事前構成と対応付け更新をそれぞれ完了する請求項１５記載の方法。
前記移動ノードは、隣接するネットワークの複数のＩＰアドレスを、一定の期間キャッシュに格納する請求項１６記載の方法。
前記複数の隣接するターゲットネットワーク内のターゲットルータと一時トンネルを確立することをさらに含む請求項１７記載の方法。
前記複数の対応付け更新を行うことは、
前記移動ノードが、通信相手ノード（ＣＮ）に、前記隣接するネットワークから獲得される複数のＩＰアドレスを有する対応付け更新を送信することと、
前記通信相手ノードが、前記一時トンネルを使って前記移動ノードに、複数の一時ストリームを送ることと、
をさらに含む請求項１８記載の方法。
移動ノードから送られる複数のコンタクトアドレスを有する対応付け更新を実行し、複数のメディアストリームが、一時トンネルを使用して前記通信相手ノード（ＣＮ）から生じることと、
前記移動ノードのハンドオーバ後に、該移動ノードが移動しなかった他の隣接するネットワークへのメディア送信を停止するように、該移動ノードから、該移動ノードが移動した先に設定された新しい単一のコンタクトアドレスを有する別の対応付け更新を送信することと、
を含む請求項１５記載の方法。
ターゲットアクセスルータで、またはホームエージェントでバッファリングを適用することと、
前記移動ノードが特定のターゲットネットワークに移動した後に、前記移動ノードに一時データを転送することと、
を含む請求項１５記載の方法。
前記転送することは、モバイルＩＰ登録の一部として、または別個のバッファリングプロトコルとして、前記移動ノードによりトリガされる請求項２１記載の方法。
ＩＰマルチキャストグループに加入している移動ノードが現在のネットワークから新しいネットワークに移動するときに、前記移動ノードのマルチキャスト通信中断を最小限にする方法であって、
事前対応型マルチキャストモビリティサポートを提供し、参加待ち時間を低減するように、メディア独立事前認証（ＭＰＡ）を用いること
を含む方法。
前記マルチキャストモビリティは、ホームサブスクリプションベースの手法を伴い、前記参加待ち時間は、事前にマルチキャストツリーに参加することによって低減される請求項２３記載の方法。
前記移動ノードが前記新しいネットワークに移動しようとしているときに、次のアクセスルータ（ＮＡＲ）はマルチキャストプロキシとして振る舞う請求項２４記載の方法。
前記ＭＰＡプロセスの事前構成段階において、前記移動ノードは、事前認証された後に、加入している前記（１または複数の）マルチキャストグループに関する情報を渡す請求項２５記載の方法。
前記新しいネットワーク内の構成サーバと対話することによって、前記現在のネットワーク内で前記移動ノードを事前構成するためのプロトコルとしてＰＡＮＡを使用することと、
前記移動ノードに、前記移動ノードの加入グループ情報を、ＰＡＮＡ認証エージェントに渡させることと、
をさらに含む請求項２６記載の方法。
前記ＰＡＮＡ認証エージェントに次のアクセスルータ（ＮＡＲ）と通信させて、上流ルータに参加するためのマルチキャストをトリガすることをさらに含む請求項２７に記載の方法。
前記移動ノードと前記次のアクセスルータとの間のトンネルセットアッププロセスの間に、前記次のアクセスルータが、前記移動ノードに代わって前記マルチキャストグループに参加する請求項２５記載の方法。
前記移動ノードが前記現在のネットワークから移動する前に、前記移動ノードは、前記現在のネットワーク内で作成されるトンネルを使って、前記次のアクセスルータ（ＮＡＲ）に直接マルチキャスト参加要求を送る請求項２５記載の方法。
前記次のアクセスルータが、前記マルチキャスト参加要求がどのインターフェースからもたらされたか識別することができ、前記インターフェースに加入ホストがあると想定するように、
前記マルチキャスト参加要求の送信元アドレスが前記移動ノードのトンネル終点アドレスの送信元アドレスに設定される請求項３０記載の方法。
前記次のアクセスルータをマルチキャストルータとして構成させることをさらに含む請求項２５記載の方法。
前記移動ノードは、現在のネットワーク内にあるときには、依然として、前記移動ノードの現在構成されているＩＰアドレス上で前のアクセスルータ（ＰＡＲ）を介してマルチキャストトラヒックを受信するが、前記移動ノードが前記新しいネットワークに移動し、前記トンネルを削除すると、最小限の参加待ち時間で、同じグループマルチキャストアドレス上で前記マルチキャストトラヒックの受信を開始する請求項２５記載の方法。
前記移動ノードは、前もってアドレスを獲得し、前記移動ノードのインターフェースを構成するのに時間を費やさない請求項３３記載の方法。
前記マルチキャストモビリティはリモートサブスクリプションベースの手法を伴い、前記メディア独立事前認証は、マルチキャストサービスのためのモビリティサポートを提供し、データが、前記移動ノードと前記次のアクセスルータの間の一時ＭＰＡトンネルを介して、前のネットワーク内の前記モバイルに配信される請求項２３記載の方法。
前記モバイルが新しいネットワークに移動する際に、モバイルＩＰ（ＭＩＰ）トンネルが、前記新しいネットワーク内の前記マルチキャストトラヒックの配信を処理する請求項３５記載の方法。