JP4745344B2 - 媒体非依存事前認証改善策のフレームワーク - Google Patents

Description

本願は、例えば媒体非依存事前認証等のための方法を含む、事前認証のための方法に関する。

最も有名なインターネット（登録商標）とともに多様な種類のコンピュータネットワークがある。インターネットはコンピュータネットワークの世界的なネットワークである。今日、インターネットは何百万ものユーザが使用できる公開された自立したネットワークである。インターネットはＴＣＰ／ＩＰ（つまり伝送制御プロトコル／インターネットプロトコル）と呼ばれている一式の通信プロトコルを使用して、ホストを接続する。インターネットはインターネットバックボーンとして公知の通信インフラストラクチャを有する。インターネットバックボーンに対するアクセスは、主として企業及び個人のアクセスをリセールするインターネットサービスプロバイダ（ＩＳＰ）によって制御されている。

ＩＰ（インターネットプロトコル）に関して、これは、あるデバイス（例えば、電話、ＰＤＡ［パーソナルデジタルアシスタント］、コンピュータ等）からネットワーク上の別のデバイスにデータを送信できるプロトコルである。今日では、ＩＰｖ４、ＩＰｖ６等を含む種々のバージョンのＩＰがある。ネットワーク上の各ホストデバイスは、独自の一意の識別子である少なくとも１つのＩＰアドレスを有する。ＩＰはコネクションレスプロトコルである。通信中のエンドポイント間の接続は連続ではない。ユーザがデータ又はメッセージを送信又は受信すると、このデータ又はメッセージはパケットとして知られている構成要素に分割される。あらゆるパケットはデータの独立した単位として取り扱われる。

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

通常、メッセージがユーザから又はユーザに渡されるときには上部４つの層が使用され、メッセージがデバイス（例えばＩＰホストデバイス）を通過するときには下部の３つの層が使用される。ＩＰホストは、サーバ、ルータ、又はワークステーション等の、ＩＰパケットを送信及び受信できるネットワーク上の任意のデバイスである。なんらかの他のホストに向けられるメッセージは上位層まで渡されないが、他のホストに転送される。ＯＳＩモデルの層は以下に一覧表示される。第７層（つまり、アプリケーション層）は、例えば通信パートナーが特定され、サービスの質が特定され、ユーザ認証とプライバシーが考慮され、データ構文に対する制約が特定される等の層である。第６層（つまり、プレゼンテーション層）は、例えば入信データと発信データをあるプレゼンテーションフォーマットから別のプレゼンテーションフォーマットに変換する等の層である。第５層（つまり、セッション層）は、例えばアプリケーション間の会話、交換及びダイアログをセットアップし、調整し、終了する等の層である。第４層（つまり、トランスポート層）は、例えばエンドツーエンド制御及びエラーチェックを管理する等の層である。第３層（つまり、ネットワーク層）は、例えばルーティングと転送を処理する等の層である。第２層（つまり、データリンク層）は、例えば物理レベルに同期を提供し、ビットスタッフィングを行い、伝送プロトコルの知識と管理を提供する等の層である。電気電子技術者協会（ＩＥＥＥ）は、データリンク層を２つの追加の副層、つまり物理層への及び物理層からのデータ転送を制御するＭＡＣ（媒体アクセス制御）層と、ネットワーク層と接続し、コマンドを解釈し、エラー回復を実行するＬＬＣ（論理リンク制御）層に再分割する。第１層（つまり、物理層）は、物理レベルでネットワークを通してビットストリームを伝達する等の層である。ＩＥＥＥは、物理層をＰＬＣＰ（物理層収束手順）副層と、ＰＭＤ（物理媒体依存）副層に再分割する。

無線ネットワーク：
無線ネットワークは、例えばセルラー電話と無線電話、ＰＣ（パソコン）、ラップトップコンピュータ、ウェアラブルコンピュータ、コードレスフォン、ページャ、ヘッドホン、プリンタ、ＰＤＡ等の種々のタイプのモバイル機器を組み込むことができる。例えば、モバイル機器は、音声及び／又はデータの高速無線伝送を確保するためにデジタルシステムを含んでよい。典型的なモバイル機器は、以下の構成要素のいくつか又はすべてを含む。つまり、トランシーバ（つまり、例えば送信機、受信機、及び所望される場合他の機能が統合されたシングルチップトランシーバ等を含む送信機と受信機）、アンテナ、プロセッサ、１台又は複数台の音声トランスデューサ（例えば、音声通信用のデバイスにおいてのようなスピーカ又はマイク）、（例えば、ＲＯＭ、ＲＡＭ、データ処理が提供されるデバイスにおいてのようなデジタルデータ記憶装置等の）電磁データ記憶装置、メモリ、フラッシュメモリ、フルチップセット又は集積回路、（例えばＵＳＢ、ＣＯＤＥＣ、ＵＡＲＴ、ＰＣＭ等の）インタフェース、及び／又は類似物である。

携帯電話利用者が無線接続を通してローカルエリアネットワーク（ＬＡＮ）に接続できる無線ＬＡＮ（ＷＬＡＮ）は、無線通信のために利用されてよい。無線通信は、例えば、光、赤外線、無線、マイクロ波等の電磁波を介して伝搬する通信を含むことができる。ブルートゥース（登録商標）、ＩＥＥＥ８０２．１１、及びＨｏｍｅＲＦ等、現在存在する種々のＷＬＡＮ規格がある。

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

ＩＥＥ規格であるＩＥＥＥ８０２．１１は、無線ＬＡＮとデバイスのための技術を規定する。８０２．１１を使用して、複数のデバイスをサポートしているそれぞれ単一の基地局との無線ネットワーキングが達成されてよい。いくつかの例では、デバイスは無線ハードウェアを事前に装備して納品されてよい、又はユーザがアンテナを含んでよいカード等の別個のハードウェアをインストールしてよい。一例として、８０２．１１で使用されるデバイスは、通常、デバイスがアクセスポート（ＡＰ）であるのか、移動局（ＳＴＡ）であるのか、ブリッジであるのか、ＰＣＭＣＩＡカードであるのか、又は別のデバイス、つまり無線トランシーバ、アンテナ及びネットワーク内のポイントの間のパケットの流れを制御するＭＡＣ（媒体アクセス制御）層であるのかに関係なく３つの注目すべき要素を含む。

更に、いくつかの無線ネットワークではマルチプルインタフェースデバイス（ＭＩＤｓ）が活用されることがある。ＭＩＤはブルートゥースインタフェースと８０２．１１インタフェース等の２つの独立したネットワークインタフェースを含んでよく、このようにしてＭＩＤはブルートゥースデバイスと接続するだけではなく２つの別々のネットワークで参加することもできるようになる。ＭＩＤはＩＰアドレスと、このＩＰアドレスと関連付けられた共通ＩＰ（ネットワーク）名を有してよい。

無線ネットワークデバイスは、ブルートゥースデバイス、マルチプルインタフェースデバイス（ＭＩＤ）、８０２．１１ｘデバイス（例えば８０２．１１ａ、８０２．１１ｂ及び８０２．１１ｇのデバイスを含むＩＥＥＥ ８０２．１１デバイス）、ＨｏｍｅＲＦ（ホーム無線周波数）デバイス、Ｗｉ−Ｆｉ（ワイヤレスフィディリティー）デバイス、ＧＰＲＳ（ジェネラルパケットラジオサービス）デバイス、３Ｇセルラーデバイス、２．５Ｇセルラーデバイス、ＧＳＭ（グローバルシステムフォーモバイルコミュニケーションズ）デバイス、ＥＤＧＥ（Enhanced Data for GSM Evolution）デバイス、ＴＤＭＡタイプ（時分割多元接続）デバイス、又はＣＤＭＡ２０００を含むＣＤＭＡタイプ（符号分割多元接続）デバイスを含んでよいが、これらに限定されない。それぞれのネットワークデバイスは、ＩＰアドレス、ブルートゥースデバイスアドレス、ブルートゥース共通名、ブルートゥースＩＰアドレス、ブルートゥースＩＰ共通名、８０２．１１ＩＰアドレス、８０２．１１ＩＰ共通名、又はＩＥＥＥ ＭＡＣアドレスを含むが、これらに限定されない様々なタイプのアドレスを含んでよい。

無線ネットワークは、例えばモバイルＩＰ（インターネットプロトコル）システムにおいて、ＰＣＳシステムにおいて、及び他の携帯電話ネットワークシステムにおいて見られる方法及びプロトコルも含むことがある。モバイルＩＰに関して、これはインターネットエンジニアリングタスクフォース（ＩＥＴＦ）により作成された標準通信プロトコルを含む。モバイルＩＰを使用すると、モバイル機器ユーザは、一度割り当てられた自分のＩＰアドレスを維持しながらネットワーク全体で移動することができる。リクエストフォーコメント（ＲＦＣ）３３４４を参照されたい。注意：ＲＦＣはインターネットエンジニアリングタスクフォース（ＩＥＴＦ）の公式文書である。モバイルＩＰはインターネットプロトコル（ＩＰ）を強化し、自らのホームネットワークの外部で接続するときにインターネットトラフィックをモバイル機器に転送する手段を追加する。モバイルＩＰは、各モバイルノードに、そのホームネットワークでのホームアドレスと、ネットワーク及びそのサブネットの中でのデバイスの現在位置を特定する気付アドレス（ＣｏＡ）とを割り当てる。デバイスは別のネットワークに移動すると、それは新しい気付アドレスを受け取る。ホームネットワーク上のモビリティエージェントは各ホームアドレスをその気付アドレスと関連付けることができる。モバイルノードは、それがその気付アドレスを例えばインターネットコントロールメッセージプロトコル（ＩＣＭＰ）を使用して変更するたびにホームエージェントにバインディングアップデートを送信できる。

基本ＩＰルーティング（例えば、モバイルＩＰ外部）では、ルーティング機構は、各ネットワークノードが常に、例えばインターネットに対する一定の接続点を有し、それぞれのノードのＩＰアドレスが、それが接続されるネットワークリンクを特定するという仮定に依存している。本明細書では、用語「ノード」は、例えばデータ伝送のための再分布点又はエンドポイントを含むことがあり、他のノードへの通信を認識する、処理する、及び／又は転送することができる接続点を含む。例えば、インターネットルータは、デバイスのネットワークを特定する、例えばＩＰアドレス接頭辞等を見ることができる。次にルータは、ネットワークレベルで、特定のサブネットを特定するビットのセットを見ることができる。次にルータは、サブネットレベルで、特定のデバイスを特定するビットのセットを見ることができる。典型的なモバイルＩＰ通信を用いる場合、ユーザが例えばインターネットからモバイル機器を切断し、新しいサブネットでそれを再接続しようと試みる場合、デバイスは新しいＩＰアドレス、適切なネットマスク及びデフォルトルータで再構成されなければならない。それ以外の場合、ルーティングプロトコルはパケットを適切に配信できないであろう。

図４は、クライアントデバイスが通信する無線アクセスポイントを含む、いくつかの例示的且つ非限定的なインプリメンテーションで利用できるいくつかの例示的なアーキテクチャ構成要素を描いている。この点で、図４は、一般的に２１で示される無線ローカルエリアネットワーク（ＷＬＡＮ）に接続されている例示的な有線ネットワーク２０を示している。ＷＬＡＮ２１はアクセスポイント（ＡＰ）２２と、多くのユーザ局２３、２４を含む。例えば、有線ネットワーク２０は、インターネット又は企業データ処理ネットワークを含むことがある。例えば、アクセスポイント２２は、無線ルータである場合があり、ユーザ局２３、２４は例えば、ポータブルコンピュータ、デスクトップパソコン、ＰＤＡ、ポータブルボイスオーバＩＰ電話及び／又は他のデバイスである場合がある。アクセスポイント２２は有線ネットワーク２１にリンクされるネットワークインタフェース２５と、ユーザ局２３、２４と通信する無線トランシーバとを有する。例えば、無線トランシーバ２６は、ユーザ局２３、２５との無線通信又はマイクロ波振動数通信のためのアンテナ２７を含むことがある。アクセスポイント２２は、プロセッサ２８と、プログラムメモリ２９と、ランダムアクセスメモリ３１も有する。ユーザ局２３はアクセスポイント局２２との通信用のアンテナ３６を含む無線トランシーバ３５を有する。同様に、ユーザ局２４は、アクセスポイント２２への通信用の無線トランシーバ３８とアンテナ３９を有する。

本明細書に説明されている好ましい実施形態のいくつかでは、システム及び方法が様々な媒体のさらに高い層及びさらに低い層のコンテキストを積極的に確立するために説明されている。ここでは媒体は、例えばモバイル機器がアクセス可能な、使用可能なネットワーク（例えば、有線、認可された無線、無認可の無線等）を含む。例えば、Ｉ．Ｅ．Ｅ．Ｅ．８０２．２１を含む、Ｉ．Ｅ．Ｅ．Ｅ．８０２に説明されている媒体を参照されたい。媒体は、例えば無線ＬＡＮ（例えばＩ．Ｅ．Ｅ．Ｅ．８０２．１１）、Ｉ．Ｅ．Ｅ．Ｅ．８０２．１６、Ｉ．Ｅ．Ｅ．Ｅ．８０２．２０、ブルートゥース等を含んでよい。いくつかの例示的な例は、１）例えば、セルラーインタフェースと無線インタフェース付きの、無線インタフェースを同時に確立するよりむしろ初期にセルラーネットワーク上で情報（例えば、キー等）を取得することによってＷＩＦＩアクセスを得ようとする、セルラーネットワークから無線又はＷＩＦＩネットワークに切り替えるモバイル機器、２）モバイル機器が現在無線又はＷＩＦＩ接続性を有する場合、無線ＬＡＮが潜在的に迅速に停止してよい等、その場合一例として、モバイル機器がセルラーネットワークを介して積極的に事前認証を行うことができる場合を含む。いくつかの例示的な場合、単一ＩＥＥＥ８０２．ｘｘインタフェース付きのモバイルノードは複数のサブネットと複数の管理ドメインの間でローミングしてよい。複数のインタフェースを常時オンにしておくことは１つの選択肢であるが、モバイルノードは（例えば、節電するため等の）いくつかの例では使用されていないインタフェースを非活性化することを望む場合がある。加えて、ＭＰＡは、とりわけ、複数のインタフェースの使用だけではなくサブネット間のハンドオフ、ドメイン間のハンドオフ、技術間のハンドオフ等にも役立つ安全且つ途切れのないモビリティ最適化を実現できる。

ＰＡＮＡ：
参考のために、P.Jayaraman、「PANA Framework」、Internet-Draft、draft-ietf-pana-framework-01.txt、work in progress、２００４年７月からのＰＡＮＡに関する情報が本明細書の本項に組み込まれている。この点で、ＰＡＮＡは、ネットワークにアクセスを希望するノードとネットワーク側のサーバの間で実行するリンク層にとらわれないネットワークアクセス認証プロトコルである。ＰＡＮＡは新しいＥＡＰを定義する［B.Abobaら、「Extensible Authentication Protool(EAP)」、RFC3748、２００４年６月］、Aboba,B.、Blunk L.、Vollbrecht,J.、Carison,J.及びH.Levkowetz、Extensible Authentication Protocol(EAP)」、２００４年６月、プロトコルエンドポイント間でＩＰを使用する下位層を参照されたい。

このようなプロトコルと要件を定義するための動機は、Yegin,A．及びY.Ohba、Protocol for Carrying Authentication for Network Access(PANA)Requirements、draft-ietf-pana-requirements-08(work in progress）、２００４年に説明されている。プロトコルの詳細は、Forsberg、D.、Ohba,Y.、Patil,B.、Tschofenig,H.及びA.Yegin、Protocol for Carrying Authentication for Network Access(Forsberg,D.、Ohba,Y.、Patil,B.、Tschofenig,H.及びA.Yegin、Protocol for Carrying Authentication for Network Access(PANA)、draft-ietf-pana-pana-04(work in progress）、２００４年５月に文書化されている。Parthasarathy,M.、PANA Enabling IPsec Based Access Control、draft-ietf-pana-ipsec-03(work in progress）、２００４年５月は、ＰＡＮＡをベースにした認証に続くアクセス制御のためのＩＰｓｅｃの使用を説明する。ＩＰｓｅｃは、パケット単位のアクセス制御に使用できるが、それにも関わらずそれはこの機能性を達成する唯一の方法ではない。代替策は物理的セキュリティ及びリンク層暗号化を信頼することを含む。アクセス制御を施行しているエンティティからＰＡＮＡサーバを分離することは、オプションの配備の選択肢として想定されてきた。SNMP[Mghazli,Y.、Ohba,Y.及びJ.Bournelle、SNMPUsage for PAA-2-EP Interface、draft-ietf-pana-snmp-00(work in progress)、2004年４月が、別々のノードの間で関連した情報を伝搬するためのプロトコルとして選ばれた。
ＰＡＮＡ設計は、多様なタイプの配備にサポートを提供する。アクセスネットワークは、より下位の層のセキュリティの可用性、ＰＡＮＡエンティティの設置、クライアントＩＰ構成の選択、及び認証方法等に基づいて異なることがある。

ＰＡＮＡは根本的なセキュリティに関わりなく任意のアクセスネットワークで使用できる。例えば、ネットワークは物理的に保護される、つまりクライアント−ネットワークの認証が成功した後に暗号機構によって保護される可能性がある。

ＰＡＮＡクライアント、ＰＡＮＡ認証エージェント、認証サーバ、及び施行ポイントはこの設計では機能上のエンティティであった。ＰＡＮＡ認証エージェント及び施行ポイントは、アクセスネットワーク内の多様な要素に（例えば、アクセスポイント、アクセスルータ、専用ホスト等）対して設置できる。

ＩＰアドレス構成機構も変化する。静的構成、ＤＨＣＰ、ステートレスアドレス自動構成が選ぶために考えられる機構である。クライアントがパケット単位のセキュリティを可能にするためにＩＰｓｅｃトンネルを構成する場合、該トンネルの内部でＩＰアドレスを構成することに意味があるようになり、これらに対してＩＫＥ等の追加の選択肢が存在する。

ＰＡＮＡプロトコルはアクセスネットワークにおけるクライアントの認証と承認を容易にすることを目的としている。ＰＡＮＡはEAP[Aboba,B.、Blunk,L.、Vollbrecht,J.、Carlson,J.、及びH.Levkowetz、Extensible Authentication Protocol(EAP)、２００４年６月である。Aboba,B.、Blunk,L.、Vollbrecht,J.、Carlson,J.及びH.Levkowetz、Extensible Authentication Protocol(EAP)、RFC3748、２００４年６月、クライアントホストとアクセスネットワーク内のエージェントの間のＥＡＰの内部にカプセル化されるＥＡＰ認証方法を搬送する下位層を参照されたい。ＰＡＮＡはこの２つのエンティティの間で認証プロセスを可能にするが、それは全体的なＡＡＡ及びアクセス制御フレームワークの一部にすぎない。ＰＡＮＡを使用するＡＡＡとアクセス制御フレームワークは、後述されるように、及び図１（Ａ）〜図１（Ｃ）に概略で描かれている４つの機能エンティティを含む。

第１の機能エンティティはＰＡＮＡクライアント（ＰａＣ）であり、ＰＡＮＡプロトコルのクライアントインプリメンテーションである。このエンティティは、ネットワークアクセスを要求しているエンドホスト上に常駐する。エンドホストは、例えば、ラップトップコンピュータ、ＰＤＡ、携帯電話、デスクトップＰＣ、及び／又は有線インタフェース又は無線インタフェースを介してネットワークに接続される類似物を含むことがある。ＰａＣは、ネットワークアクセスを要求し、ＰＡＮＡプロトコルを使用して認証プロセスに従事することに関与する。

第２の機能エンティティはＰＡＮＡ認証エージェント（ＰＡＡ）であり、ＰＡＮＡプロトコルのサーバインプリメンテーションである。ＰＡＡはネットワークアクセスサービスについてそれらを認証し、承認するためにＰａＣと接続することを担当する。ＰＡＡはＰａＣの信用証明書及び権利を検証するために認証サーバに相談する。認証サーバがＰＡＡと同じホストに常駐する場合は、アプリケーションプログラムインタフェース（ＡＰＩ）がこの相互作用に十分である。それらが分離されると（パブリックアクセスネットワークではより一般的な場合）、プロトコルがこの２つの間で実行するために使用される。ＬＤＡＰプロトコル［Hodges,J.、及びR.Morgan、Lightweight Directory Access Protocol(v3):Technical Specification、２００２年９月を参照されたい。Hodges,J.及びR.Morgan、Lightweight Directory Access Protocol(v3):Technical Specification、RFC3377、２００２年９月を参照されたい。］、及びＲＡＤＩＵＳ［Rigney,C.、Willens,S.、Rubens,A.及びW.Simpson、Remote Authentication Dial In User Service(RADIUS)、２０００年６月。Rigney,C.、Willens,S.、Rubens,A.及びW.Simpson、Remote Authentication Dial In User Service(RADIUS)、RFC2865、２０００年６月を参照されたい］のようなＡＡＡプロトコル、及びDiameter[Calhoun,P.、Loughney,J.、Guttman,E.、Zorn,G.及びJ.Arkko、Diameter Base Protcol、２００３年９月、Calhoun,P.、Loughney,J.、Guttman,E、Zorn,G.及びJ.Arkko、Diameter Base Protocol、RFC3588、２００３年９月を参照されたい］が、この目的に一般的に使用されている。

ＰＡＡは、認証状態の作成及び削除に応じてアクセス制御状態（つまり、フィルタ）を更新することにも関与する。ＰＡＡは更新された状態をネットワーク内の施行ポイントに通信する。ＰＡＡとＥＰが同じホスト上に常駐している場合、ＡＰＩがこの通信にとって十分である。それ以外の場合、プロトコルはＰＡＡからＥＰに許可されたクライアント属性を搬送するために使用される。他のプロトコルを禁止していないが、現在のＳＮＭＰ［Mghazli,Y.、Ohba,Y.及びJ.Bournelle、SNMP Usage for PAA-2-EP Interface、draft-ietf-pana-snmp-00(work in progress）、２００４年４月］がこのタスクに提案されていた。

ＰＡＡは、通常、ローカルエリアネットワークの中のネットワークアクセスサーバ（ＮＡＳ）と呼ばれるノードに常駐する。ＰＡＡはＰａＣと同じＩＰサブネット上の任意のＩＰによって可能にされたノード上で動作できる。例えば、ＤＳＬネットワークのＢＡＳ（ブロードバンドアクセスサーバ）で、又は３ＧＰＰ２ネットワークのＰＤＳＮで等で動作できる。

第３の機能エンティティは、ネットワークアクセスサービスを要求しているＰａＣの信用証明書の検証を担当するサーバインプリメンテーションである、認証サーバ（ＡＳ）である。ＡＳはＰａＣの代わりにＰＡＡから要求を受け取り、認証パラメータ（例えば、許可された帯域幅、ＩＰ構成等）とともに検証の結果をもって応答する。ＡＳはＰＡＡと同じホストで、アクセスネットワーク上の専用ホストで、あるいはインターネット上のどこかのセントラルサーバで動作できる可能性がある。

第４の機能エンティティは、他者によるアクセスを妨げる一方で許可されたクライアントへのアクセスの許可を担当するアクセス制御インプリメンテーションである施行ポイント（ＥＰ）である。ＥＰはＰＡＡから許可されたクライアントの属性を学習する。ＥＰは、非暗号フィルタ又は暗号フィルタを使用して選択的にデータパケットを許可し、廃棄する。これらのフィルタはリンク層又はＩＰ層で適用されてよい。暗号アクセス制御を使用する場合、安全な関連プロトコルがＰａＣとＥＰの間で実行する必要がある。安全な関連プロトコルが完全性保護、データ発信元認証、再生保護及び任意に機密性保護を可能にするために必要なセキュリティ関連付け（security association）を確立した後、リンク又はネットワーク層保護（例えば、TKIP、IPsec ESP）が使用される。ＥＰは、許可されていないクライアントのネットワークへのアクセスを最小限に抑えるためにローカルエリアネットワーク内に戦略的に配置されなければならない。例えば、ＥＰは、有線ネットワーク内のクライアントに直接的に接続されているスイッチ上で動作できる。そのようにして、ＥＰは、それらが他のクライアントホストに到達する前に、又はローカルエリアネットワークを越える前に許可されていないパケットを削除できる。

エンティティのいくつかは、配備シナリオに応じて同一位置に配置されてよい。例えば、ＰＡＡとＥＰは、ＤＳＬネットワーク内の同じノード上にある可能性がある。その場合、ＰＡＡとＥＰの間では単一ＡＰＩで十分である。小企業の配備ではＰＡＡとＡＳは、この２つの間で実行されるプロトコルに対する必要性を排除する同じノード（例えば、アクセスルータ）の上で動作してよい。これらのエンティティを同一位置に配置するという決定、又はそれ以外の場合、及びネットワークトポロジーの中のそれらの正確な位置が配備の決定である。

安全な関連付けのためのＩＫＥ又は４通りのハンドシェイクプロトコルを使用すると、ＰＡＮＡを実行する前に任意の下位層セキュリティがない場合にだけ必要とされていた。（例えば、ＤＳＬ等の）物理的に保護されたネットワーク又はＰＡＮＡの前にリンク層ですでに暗号により保護されているネットワーク（例えば、ｃｄｍａ２０００）は安全な関連付け及びパケット単位の暗号化を必要としない。これらのネットワークはＰＡＮＡの認証と承認を、すでに使用できる下位層安全チャネルに結び付けることができる。

アクセスネットワーク上のＥＰが任意の許可されたＰａＣからの一般的なデータトラフィックを可能にするのに対し、それは許可されていないＰａＣのための限られたタイプのトラフィック（例えば、ＰＡＮＡ、ＤＨＣＰ、ルータ発見）だけを可能にする。これにより、新規に接続されたクライアントがＰＡＮＡに従事するための最小のアクセスサービスを有し、無制限のサービスに対して許可されることが確実になる。

ＰａＣはＰＡＮＡを実行する前にＩＰアドレスを構成する必要がある。ＰＡＮＡ認証が成功した後、配備シナリオに応じて、ＰａＣはそのＩＰアドレスを構成し直す、又は追加のＩＰアドレス（複数の場合がある）を構成する必要がある場合がある。追加のアドレス構成は、安全関連プロトコル実行の一部として実行されてよい。

最初に許可されていないＰａＣは、アクセスネットワーク上でＰＡＡを発見し、後にＰＡＮＡ上でのＥＡＰの交換が続くことによってＰＡＮＡ認証を開始する。ＰＡＡはこのプロセスの間にＡＳと相互に作用する。認証及び許可の結果をＡＳから受信すると、ＰＡＡはＰａＣにそのネットワークアクセス要求の結果について知らせる。

ＰａＣがネットワークにアクセスすることを許可されている場合、ＰＡＡはＳＮＭＰを使用することによりＥＰにＰａＣ特有の属性（例えば、ＩＰアドレス、暗号キー等）も送信する。ＥＰはＰａＣから及びＰａＣへのデータトラフィックが通過できるようにするためにそのフィルタを改変するためにこの情報を使用する。

ＰＡＮＡ認証後に暗号アクセス制御が可能にされる必要がある場合、安全関連プロトコルがＰａＣとＥＰの間で実行する。ＰａＣはＰＡＮＡ交換が成功した結果としてすでにこのプロセスに対して入力パラメータを持つ必要がある。同様に、ＥＰはＳＮＭＰを介してＰＡＡからそれらを取得するべきだった。安全な関連付けの交換により、ＰａＣとＥＰの間に必要とされるセキュリティ関連付けが生じ、暗号データトラフィック保護を可能にする。パケット単位の暗号データトラフィック保護が追加のパケット単位のオーバヘッドを導入するが、オーバヘッドはＰａＣとＥＰの間だけに存在し、ＥＰを超えて通信に影響を及ぼさないであろう。この意味で、ネットワークの端の可能な限り近くにＥＰを配置することが重要である。

最後に、データトラフィックが新規に許可されたＰａＣから及びＰａＣに流れ始めることができる。

本発明への導入
セルラー及び無線ＬＡＮを含む無線技術が一般的に使用されているので、例えば無線ＬＡＮからＣＤＭＡに、又はＧＰＲＳに等の異なるタイプのアクセスネットワーク全体で端末ハンドオーバをサポートすることは明確な課題として考えられている。他方、同じタイプのアクセスネットワーク間で端末ハンドオーバをサポートすることは、特にハンドオーバがＩＰサブネット又は管理ドメインに渡るときには依然としてより挑戦的である。それらの課題に取り組むために、理不尽な複雑さを生じさせずに最適化され且つ安全な様式でリンク層技術にとらわれない端末移動性(terminal mobility)を与えることが重要である。本明細書では、低遅延及び低損失のシームレスハンドオーバを提供する端末移動性を論じる。シームレスハンドオーバは、以下の性能要件と題される次項に説明されるような性能要件に関して特徴付けられる。

端末移動性の基本的な部分は、携帯端末のロケータと識別子の間のバインディングを維持する移動性管理プロトコルによって達成され、このバインディングは移動性バインディングと呼ばれる。モバイルノードのロケータは、携帯端末の移動があるときに動的に変化することがある。ロケータの変化を引き起こす該移動は物理的にだけではなく、論理的にも発生してよい。移動性管理プロトコルは任意の層で定められてよい。本明細書の残りでは、用語「移動性管理プロトコル」はネットワーク層又はさらに上位層で動作する移動性管理プロトコルを指す。

様々な層にいくつかの移動性管理プロトコルがある。モバイルＩＰ［ＲＦＣ３３４４］及びモバイルＩＰｖ６［ＲＦＣ３７７５］は、ネットワーク層で動作する移動性管理プロトコルである。ＩＥＴＦではネットワーク層より上位の層で移動性管理プロトコルを定義するためのいくつかの継続中の活動がある。例えば、ＭＯＢＩＫＥ（IKEv2 Mobility and Multihoming)[I-D.ietf-mobike-design］は、ＩＫＥｖ２エンドポイントのＩＰアドレスの変化に対応する能力を与えるＩＫＥｖ２の拡張である。ＨＰ（ホストアイデンティティプロトコル）［I-D.ietf-hip-base］は、ネットワーク層とトランスポート層の両方にとってトランスペアレントであるように端末移動性を与えるためにネットワーク層とトランスポート層の間に新しいプロトコル層を定義する。また、ＳＩＰ−モビリティは、ＳＩＰユーザエージェント［ＳＩＰＭＭ］の移動性バインディングを維持するためのＳＩＰに対する拡張である。

移動性管理プロトコルは移動性バインディングを維持するが、それらをそれらの現在の形式だけで使用することは、シームレスハンドオーバを実現するために十分ではない。移動性バインディングを更新しながら、送信された未決パケットの損失を妨ぐために携帯端末のアクセスしたネットワークで作用する追加の最適化機構が、シームレスハンドオーバを達成するために必要とされる。このような機構が移動性最適化機構と呼ばれる。例えば、移動性最適化機構［I-D.ietf-mobileip-lowlatency-handoffs-v4］及び［I-D.ietf-mipshop-fast-mipv6］が、隣接するアクセスルータが携帯端末についての情報を通信し、搬送できるようにすることによって、それぞれモバイルＩＰｖ４とモバイルＩＰｖ６に定義される。

移動性最適化機構の「ヘルパー」と見なされるプロトコルがある。ＣＡＲＤ（候補アクセスルータ発見機構）プロトコル［I-D.ietf-seamoby-card-protocol］が近接するアクセスルータを発見するように設計される。ＣＴＰ（コンテキスト転送プロトコル）［I-D.ietf-seamoby-ctp］は、アクセスルータの間で、携帯端末のために提供されるサービスに関連している状態、つまりコンテキストを搬送するように設計される。

既存の移動性最適化機構(mobility optimization mechanisms)にはいくつかの問題点がある。第１に、既存の移動性最適化機構は特定の移動性管理プロトコルと密に結合している。例えば、ＭＯＢＩＫＥ用に、モバイルＩＰｖ４又はモバイルＩＰｖ６のために設計された移動性最適化機構を使用することはできない。強く所望されていることは、任意の移動性管理プロトコルと連動する単一の統一された移動性最適化機構である。第２に、管理ドメインの間で事前に確立されたセキュリティ関連付けを想定することなく、管理ドメイン全体でハンドオーバを容易にサポートする既存の移動性最適化機構はない。移動性最適化機構は、モバイルノードと各管理ドメインの間の信頼関係だけに基づいて安全に管理ドメイン全体で作用するべきである。第３に移動性管理機構は、マルチインタフェースを通じた複数の同時接続性を予想できるマルチインタフェース端末だけではなく、単一インタフェース端末もサポートする必要がある。

本明細書は、それらすべての問題点に取り組む可能性がある新しいハンドオーバ最適化機構である媒体に依存しない事前認証（ＭＰＡ）のフレームワークを説明している。ＭＰＡは任意のリンク層の上で、モバイルＩＰｖ４、モバイルＩＰｖ６、ＭＯＢＩＫＥ、ＨＩＰ、ＳＩＰモビリティ等を含む任意の移動性管理プロトコルと連動するモバイル支援安全ハンドオーバ最適化方式である。ＭＰＡでは、ＩＥＥＥ ８０２．１１ｉ事前認証の概念がさらに上位の層で働くために拡張され、追加の機構が、携帯端末が依然として現在のネットワークに接続されている間のネットワークへの先を見越したハンドオーバだけではなく、携帯端末が移動するネットワークからのＩＰアドレスの早期獲得も実行する。本明細書はＭＰＡフレームワークに焦点を当てている。このようなフレームワークを利用する際に、ＭＰＡのために選ばれるプロトコルの実際のセット、及び詳細な動作は本明細書に基づいて当業者により実現できる。以下に識別されている文献［I-D.ohba-mobopts-mpa-implementation］は、使用及びＭＰＡ機能性を達成するための既存のプロトコル間での相互作用を説明する１つの方法を提供している。

性能要件
対話型ＶｏＩＰ及びストリーミングトラフィックに望ましいサービスの質を与えるために、エンドツーエンド遅延、ジッタ及びパケット損失の値を特定の閾値レベルに制限する必要がある。ＩＴＵ−Ｔ規格とＩＴＵ−Ｅ規格は、これらのパラメータの許容できる値を定めている。例えば、一方向遅延について、ＩＴＵ−Ｔ Ｇ．１１４はアプリケーションの大部分に対する上限として１５０ｍｓを、一般的に許容できない遅延として４００ｍｓを推奨している。ビデオ会議の一方向遅延公差は２００から３００ｍｓの範囲内にある。また、特定の閾値の後に順序が狂ったパケットが受信されると、それは損失と見なされる。以下に一覧表示される参考文献［ＲＦＣ２６７９］、［ＲＦＣ２６８０］及び［ＲＦＣ２６８１］は、遅延とジッタのための測定技法のいくつかを説明している。

エンドーツーエンド遅延は、通常、ネットワーク遅延、オペレーティングシステム（ＯＳ）遅延、ＣＯＤＥＣ遅延及びアプリケーション遅延等の複数の要素を含む。ネットワーク遅延は伝送遅延、伝搬遅延、及び中間ルータでの待ち行列遅延を含む。オペレーティングシステムに関連した遅延は送信機と受信機におけるオペレーティングシステムのスケジューリング動作からなる。ＣＯＤＥＣ遅延は、送信機端と受信機端で、一般的にはパケット化と逆パケット化（depacketization）のために引き起こされる。

アプリケーション遅延は主にネットワーク内の遅延変動を補償するのに役立つプレイアウト（ｐｌａｙｏｕｔ）遅延に起因している。エンドツーエンド遅延及びジッタの値は受信機端部でのプレイアウトバッファの適切な値を使用して調整できる。例えば、対話型ＶｏＩＰトラフィックの場合、エンドツーエンド遅延はジッタ値に影響を及ぼし、検討すべき重要な問題である。携帯電話の頻繁なハンドオーバの間、過渡的なトラフィックがこの携帯電話に到達することができず、これもジッタに貢献する。

エンドシステムがプレイアウトバッファを有する場合には、このジッタはプレイアウトバッファ遅延により包含されるが、それ以外の場合これは対話型トラフィックのための遅延を増加させる。パケット損失は、通常、輻輳、ルーティングの不安定性、リンク故障、無線リンク等の損失の多いリンクにより引き起こされる。携帯電話のハンドオーバの間、携帯電話はそのネットワークへの接続の変化のためにパケット損失にさらされる。したがって、ストリーミングトラフィックとＶｏＩＰ対話型トラフィックの両方について、パケット損失がリアルタイムアプリケーションのサービス品質の一因となる。

損失したパケットの数はハンドオーバの間の遅延及び携帯電話が受信するトラフィックの速度に比例する。損失パケットは再送のためにＴＣＰトラフィックの場合には輻輳の一因となるが、それはＲＴＰ／ＵＤＰベースであるストリーミングトラフィックの場合には輻輳を増加しない。したがって、任意の移動性管理方式でパケット損失とハンドオーバ遅延の影響を削減することが必須である。既存作業高速ハンドオーバと題される次項２では、ハンドオーバの削減を試みた高速ハンドオーバ方式のいくつかを説明する。

ＥＴＳＩ ＴＲ １０１、以下の参考文献［ＥＴＳＩ］に従って、通常の音声会話は最高２％のパケット損失に耐えることができる。携帯電話が会話の間に頻繁なハンドオフにさらされる場合、各ハンドオフがハンドオフ期間のパケット損失の一因となる。したがって、会話の間の最大損失を許容できるレベルに削減する必要がある。

ストリーミングアプリケーションの場合のパケット損失に明確な閾値はないが、それは特定のアプリケーションにさらに優れたサービスの品質を提供するために可能な限り多く削減する必要がある。

既存作業高速ハンドオーバ
例えばモバイルＩＰ（以下の参考文献［ＲＦＣ３３４４］を参照されたい）、モバイルＩＰｖ６（以下の参考文献［ＲＦＣ３７７５］を参照されたい）及びＳＩＰモビリティ（以下の参考文献［ＳＩＰＭＭ］を参照されたい）等の基本的な移動性管理プロトコルはＴＰＣとＲＴＰトラフィックに連続性を与えるための解決策を提供するが、これらはサブネットとドメイン間の携帯電話の頻繁な移動中ハンドオーバ待ち時間を削減するために最適化されていない。一般的には、これらの移動性管理プロトコルは第２層、第３層、及び携帯電話の移動性バインディングを更新するためのアプリケーション層等の複数の層で生じるハンドオーバ遅延に苦労する。

携帯電話のセル、サブネット及びドメイン間での移動中のハンドオーバ遅延及びパケット損失を削減しようと試みる現在の移動性管理方式に適用する複数の最適化技法があった。マイクロモビリティ管理方式（例えば、以下の参考文献［ＣＥＬＬＩＰ］及び参考文献［ＨＡＷＡＩＩ］を参照されたい）、及びドメインの中のシグナリング更新を制限することにより高速ハンドオーバを提供する（例えば以下の参考文献［IDMP］及び［I-D.ietf-mobileip-reg-tunnel］に見られるような）ドメイン内移動性管理方式はほとんどない。ＩＰｖ４ネットワークとＩＰｖ６ネットワーク（以下の参考文献［I-D.ietf-mobileip-lowlatency-handooffs-v4］及び［I-D.ietf-mipshop-fast-mipv6］を参照されたい）のための高速モバイルＩＰプロトコルは、リンク層トリガにより入手可能になる移動性情報を活用する高速ハンドオーバ技法を提供する。Ｙｏｋｏｔａら（以下の参考文献［ＹＯＫＯＴＡ］を参照されたい）は、ＭＩＰｖ４仕様を改変することなく高速ハンドオーバを提供するために、アクセスポイントと専用ＭＡＣブリッジの協働使用を提案している。ＭＡＣＤ方式（以下の参考文献［ＭＡＣＤ］を参照されたい）は、キャッシュをベースにしたアルゴリズムを提供することによりＭＡＣ層ハンドオフによる遅延を削減する。

移動性管理方式のいくつかは二重インタフェースを使用するため、メークビフォアブレークシナリオ（make-before-break scenario）を実現する（以下の参考文献［ＳＵＭ］を参照されたい）。メークビフォーブレーク状況では、二次インタフェースが接続される過程にあるときに、通信は通常１つのインタフェースと続行する。ＩＥＥＥ ８０２．２１作業部会はこれらのシナリオを詳細に検討している。

単一インタフェースを使用して高速ハンドオーバを提供することは、複数のインタフェースを用いるクライアントにとってよりさらに注意深い設計技法を必要とする。以下の参考文献［ＳＩＰＦＡＳＴ］は、ＳＩＰをベースにした移動性管理の最適化ハンドオーバ方式を提供し、過渡的なトラフィックはアプリケーション層転送方式を使用することにより古いサブネットから新しいサブネットに転送される。以下の参考文献［ＭＩＴＨ］は、旧外部エージェント（old foreign agent）と新外部エージェント（new foreign agent）間での携帯電話により開始されたトンネリングを使用する単一インタフェースケースのための高速ハンドオーバ方式を提供する。以下の参考文献［ＭＩＴＨ］は、Ｐｒｅ−ＭＩＴとＰｏｓｔ−ＭＩＴという２種類のハンドオーバ方式を定める。

提案ＭＰＡ方式はいくつかの点で一般的に、携帯電話が実際に新しいネットワークに移動する前に外部エージェントと通信するＭＩＴＨの予測方式に類似した性質である。しかしながら、とりわけ、本明細書に説明されている提案ＭＰＡ方式はＭＩＰタイプの移動性プロトコルだけに限定されない。更にこの方式はドメイン間の移動を処理し、先を見越したハンドオーバに加えて事前認証を実行する。したがって、提案されている方式は、とりわけリンク層ハンドオーバ遅延の近くまで全体的な遅延を削減できる。

用語
本明細書では、以下の用語が利用されている。

移動性バインディング：
携帯端末のロケータと識別子の間のバインディング。

移動性管理プロトコル（ＭＭＰ）：
携帯端末のロケータと識別子の間でバインディングを維持するためにネットワーク層又はさらに上位層で動作するプロトコル。

バインディング更新：
移動性バインディングを更新するための手順。

媒体に依存しない事前認証モバイルノード（ＭＮ）：
任意のリンク層にわたって、かつ任意の移動性管理プロトコルを用いて機能する、モバイル支援安全ハンドオーバ最適化方式である媒体に依存しない事前認証（ＭＰＡ）の携帯端末。ＭＰＡモバイルノードはＩＰノードである。本明細書では、用語「モバイルノード」つまり修飾子の付かない「ＭＮ」は「ＭＰＡモバイルノード」を指す。ＭＰＡモバイルノードは、通常移動性管理プロトコルのモバイルノードの機能性も有する。

候補ターゲットネットワーク（ＣＴＮ）：
携帯電話が近い将来に移動してよいネットワーク。

ターゲットネットワーク（ＴＮ）：
携帯電話が移動することを決定したネットワーク。ターゲットネットワークは１つ又は複数の候補ターゲットネットワークから選択される。

先行ハンドオーバトンネル（ＰＨＴ）：
ＭＡＰモバイルノードと候補ターゲットネットワークのアクセスルータの間に確立される双方向ＩＰトンネル。本明細書では、修飾子が付かない用語「トンネル」は「先行ハンドオーバトンネル」を指す。

接続ポイント（ＰｏＡ）：
ネットワークへのＭＰＡモバイルノード用のリンク層接続ポイントとして機能するリンク層デバイス（例えば、スイッチ、アクセスポイント又は基地局等）。

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

ＭＰＡフレームワーク
媒体非依存事前認証（Media-independent Pre-Authentication（ＭＰＡ））フレームワークの例示的且つ非限定的な態様は以下のサブセクションで説明される。

１．概観
媒体非依存事前認証（ＭＰＡ）は、任意のリンク層にわたり、任意の移動性管理プロトコルを用いて機能する、モバイル支援安全ハンドオーバ最適化方式である。ＭＰＡを用いると、モバイルノードはＩＰアドレスと、候補ターゲットネットワーク（ＣＴＮ）のための他の構成パラメータを安全に取得できるだけではなく、それが実際にＣＴＮに接続する前に取得されたＩＰアドレスを使用してＩＰパケットを送受できる。これにより、モバイルノードは任意の移動性管理プロトコルのバインディング更新を完了し、リンク層でハンドオーバを実行する前に新しいＣｏＡを使用できる。

この機能性は、現在のネットワークに対する接続性を有するが、まだＣＴＮに接続していないモバイルノードが（ｉ）以後のプロトコルシグナリングを保護するためにＣＴＮとセキュリティ関連付けを確立し、次に（ｉｉ）モバイルノードとＣＴＮのアクセスルータの間で先行ハンドオーバトンネル（ＰＨＴ）を確立するために実行トンネル管理プロトコルだけではなく、ＣＴＮからＩＰアドレスと他のパラメータも取得するために構成プロトコルを安全に実行し、次に（ｉｉｉ）移動性管理プロトコル（ＭＭＰ）のバインディング更新のためのシグナリングメッセージを含むＩＰパケットと、トンネル内部アドレスとして取得されたＩＰアドレスを使用してＰＨＴ上でバインディング更新の完了後に送信されるデータパケットを送受し、最後に（ｉｖ）それがターゲットネットワークになるときにＣＴＮに接続する直前にＰＨＴを削除する又は無効にし、次に、モバイルノードがインタフェースを通してターゲットネットワークに接続された直後に、削除された又は無効にされたトンネルの内部アドレスをその物理インタフェースに割り当てし直すことができるようにすることによって提供される。ターゲットネットワークに接続する前にトンネルを削除する、又は無効にする代わりに、トンネルがターゲットネットワークに接続した直後に削除される、又は無効にされてよい。

特に、第３の手順により、携帯電話はリンク層ハンドオーバを開始する前にさらに上位層のハンドオーバを完了できる。つまり、携帯電話は、それが依然としてトンネル外でのバインディング更新の完了前に送信されたデータパケットを送受できる一方、トンネルでのバインディング更新の完了後に送信されたデータパケットを送受できる。

ＭＰＡの前記４つの基本的な手順では、第１の手順が「事前認証」と呼ばれ、第２の手順は「事前構成」と呼ばれ、第３の手順と第４の手順の組み合わせが「安全先行ハンドオーバ」と呼ばれている。事前認証により確立されるセキュリティ関連付けは、「ＭＰＡ−ＳＡ」と呼ばれる。前記に示されたように、事前構成によって確立されたトンネルは「先行ハンドオーバトンネル」（ＰＨＴ）と呼ばれる。

２．機能要素
好ましい実施形態のＭＰＡフレームワークでは、以下の機能要素はモバイルノードと通信するために各ＣＴＮに常駐する。つまり、認証エージェント（ＡＡ）、構成エージェント（ＣＡ）及びアクセスルータ（ＡＲ）である。それらの要素のいくつか又はすべては、単一のネットワークデバイスに、若しくは別々のネットワークデバイスに設置できる。

認証エージェントは事前認証に関与する。認証プロトコルを、モバイルノードと認証エージェントの間で実行し、ＭＰＡ−ＳＡを確立する。認証プロトコルは、モバイルノードと認証ノードの間でキーを導出できる必要があり、相互認証を提供できなければならない。認証プロトコルは、ＡＡＡインフラストラクチャの中の適切な認証サーバに認証信用証明書を搬送するために、ＲＡＤＩＵＳとＤｉａｍｅｔｅｒ等のＡＡＡプロトコルと対話できなければならない。該導出されたキーは事前構成及び安全先行ハンドオーバに使用されるメッセージ交換を保護するために使用されるキーをさらに導出するために使用される。リンク層及び／又はネットワーク層暗号をブートスするために使用される他のキーもＭＰＡ−ＳＡから導出されてよい。ＥＡＰ（例えば、以下の参考文献［ＲＦＣ３７４８］を参照されたい）を搬送できるプロトコルはＭＰＡ用の認証プロトコルとして適切であろう。

構成エージェントは、事前構成の一部、すなわちＩＰアドレスと他の構成パラメータをモバイルノードに安全に配信するために構成プロトコルを安全に実行することに関与する。構成プロトコルのシグナリングメッセージは、ＭＰＡ−ＳＡに対応するキーから導出されるキーを使用して保護される必要がある。

アクセスルータは、事前構成の他の部分、つまりモバイルノードへの先行ハンドオーバトンネルを確立し、該先行ハンドオーバを該先行ハンドオーバトンネルを使用して保護するためにトンネル管理プロトコルを安全に実行することに関与するルータである。構成プロトコルのシグナリングメッセージは、ＭＰＡ−ＳＡに対応するキーから引き出されるキーを使用して保護される必要がある。先行ハンドオーバトンネル上で送信されるＩＰパケットは、ＭＰＡ−ＳＡに対応するキーから導出されるキーを使用して保護されなければならない。

３．基本通信の流れ
モバイルノードがすでに接続ポイント、例えばＰｏＡ（旧接続ポイント）に接続され、気付アドレス、例えばｏＣｏＡ（旧気付アドレス）を割り当てられていると仮定する。ＭＰＡの通信フローは後述されるとおりである。通信フロー全体で、データパケット損失はステップ５の切り替え手順中の期間以外では発生してはならず、この期間中にパケット損失を最小限に抑えることはリンク層ハンドオーバの責任である。

ステップ１（事前認証段階）：
モバイルノードはなんらかの発見プロセスを通してＣＴＮを見つけ、何らかの手段によりＣＴＮ内でＩＰアドレス、認証エージェント、構成エージェント及びアクセスルータを取得する。モバイルノードは認証エージェントと事前認証を実行する。事前認証が無事終了すると、モバイルノードと認証エージェントの間にＭＰＡ−ＳＡが作成される。２つのキーが、ＭＰＡ−ＳＡ、つまりそれぞれ構成プロトコルとトンネル管理プロトコルの以後のシグナリングメッセージを保護するために使用されるＭＮ−ＣＡキーとＭＮ−ＡＲキーから導出される。ＭＮ−ＣＡキーとＭＮ−ＡＲキーは、次にそれぞれ構成エージェントとアクセスルータに安全に配信される。

ステップ２（事前構成段階）：
モバイルノードは、その接続ポイントがｏＰｏＡから新しいもの、例えばｎＰｏＡ（新接続ポイント）に変化する可能性があることを理解している。次に、モバイルノードは事前構成を実行し、構成エージェントが構成プロトコルを使用して、ＩＰアドレス、例えばｎＣｏＡ（新気付アドレス）、及び他の構成パラメータをＣＴＮから取得し、アクセスルータがトンネル管理プロトコルを使用して、先行ハンドオーバトンネルを確立する。トンネル管理プロトコルでは、モバイルノードはｎＣｏＡとｎＣｏＡを、それぞれトンネル外部アドレスとトンネル内部アドレスとして登録する。事前構成プロトコルのシグナリングメッセージは、ＭＮ−ＣＡキーとＭＮ−ＡＲキーを使用して保護される。構成とアクセスルータが同じデバイスの中で同一位置に配置されると、２つのプロトコルがＩＫＥｖ２のような単一プロトコルに統合されてよい。トンネル確立の完了後、モバイルノードはステップ４の最後までにｏＣｏＡとｎＣｏＡの両方を使用して通信できる。

ステップ３（安全先行ハンドオーバ主要段階）：
モバイルノードは何らかの手段によって新しい接続ポイントに切り替わることを決定する。モバイルノードは、新しい接続点に切り替わる前に、移動性管理プロトコルのバインディング更新を実行し、以後のデータトラフィックをトンネル上で送信することによって安全先行ハンドオーバを開始する（主要段階）。場合によっては、それは複数のｎＣｏＡアドレスをキャッシュに格納し、コレスポンデントホスト（Correspondent Host（ＣＨ））又はホームエージェント（Home Agent（ＨＡ））と同時バインディングを実行する（例えば、モバイルＩＰｖ６仕様ＲＦＣ３７７５において、モバイルノードは、それが異種ネットワークにローミングするときに気付アドレス（ＣｏＡ）を割り当てられ、モバイルノードはバインディング更新プロセスを通してその新しいＣｏＡについてそのホームエージェント（ＨＡ）とコレスポンデントノード（ＣＮ）に知らせる）。

ステップ４（安全先行ハンドオーバ事前切り替え段階）：
モバイルノードはバインディング更新を完了し、新しい接続ポイントに切り替わる準備が完了している。携帯電話は先行ハンドオーバトンネルを削除する、又は無効にするためにトンネル管理プロトコルを実行し、トンネルの削除又は無効の後にｎＣｏＡをキャッシュに入れてよい。いつもモバイルノードが新しい接続ポイントに切り替わる準備ができているのかに関する決定はハンドオーバ方針に依存している。

ステップ５（切り替え）：
リンク層ハンドオーバがこのステップで発生すると予想される。

ステップ６（安全先行ハンドオーバ切り替え後段階）：
モバイルノードは切り替え手順を実行する。切り替え手順が無事完了すると、モバイルノードはキャッシュ化ｎＣｏＡ（cached nCoA）をただちに復元し、それを新しい接続ポイントに接続されている物理インタフェースに割り当てる。先行ハンドオーバトンネルがステップ４で削除又は無効にされなかった場合、トンネルも削除される、又は無効にされる。この後、先行ハンドオーバトンネルを使用せずに、ｎＣｏＡを使用するデータパケットを直接伝送することが可能である。

アクセスルータは、事前構成の他の部分、つまりモバイルノードへの先行ハンドオーバトンネルを確立し、該先行ハンドオーバトンネルを使用して先行ハンドオーバを保護するためにトンネル管理プロトコルを安全に実行することに関与するルータである。構成プロトコルのシグナリングメッセージはＭＰＡ−ＳＡに対応するキーから導出されるキーを使用して保護されなければならない。先行ハンドオーバトンネル上で送信されるＩＰパケットは、ＭＰＡ−ＳＡに対応するキーから導出されるキーを使用して保護されなければならない。

参考文献
本発明は、その参考文献の全体的な開示が参照してここに組み込まれる、とりわけ以下の参考文献に説明されるシステム及び方法に優る種々の利点及び改善を提供する。

１．Bradner,S.、「The Internet Standards Process-Revision 3」、BCP 9、RFC 2026、１９９６年１０月。［ＲＦＣ２０２６］として本明細書で参照。

２．Bradner,S.、「IETF Rights in Contributions」、BCP 78、RFC 3978、２００５年３月。［ＲＦＣ３９７８］として本明細書で参照。

３．Perkins,C.、「IP Mobility Support for IPv4」、RFC 3344、２００２年８月。［ＲＦＣ３３４４］として本明細書で参照。

４．Aboba,B.、Blunk,L.、Volbrecht,J.、Carlson,J.、及びH.Levkowetz、「Extensible Authentication Protocol(EAP)」、RFC 3748、２００４年６月。［ＲＦＣ３７４８］として本明細書で参照。

５．Johnson,D.、Perkins,C.、及びJ.Arkko、「Mobility Support in IPv6)」、RFC 3775、２００４年６月。［ＲＦＣ３７７５］として本明細書で参照。

６．Malki,K.、「Low latency Handoffs in Mobile IPv4」、draft-ietf-mobileip-lowlatency-handoffs-v4-09(work in progress)、２００４年６月。本明細書では[I-D.ietf-mobileip-lowlatency-handoffs-v4]として参照。

７．Koodli,R.、「Fast Handovers for Mobile IPv6」、draft-ietf-mipshop-fast-mipv6-03(work in progress)、２００４年１０月。本明細書では[I-D.ietf-mipshop-fast-mipv6]として参照。

８．Liebsch,M.、「Candidate Access Router Discovery」、draft-ietf-seamoby-card-protocol-08(work in progress)、２００４年９月。本明細書では［I-D.ietf-seamoby-card-protocol］として参照。

９．Loughney,J.、「Context Transfer Protocol」、draft-ietf-seamoby-ctp-11(work in progress)、２００４年８月。本明細書では［I-D.ietf-seamoby-ctp］として参照。

１０．Aboba,B.、「Extensible Authentication Protocol(EAP)Key Management Framework)」、draft-ietf-eap-keying-06(work in progress)、２００５年４月。本明細書では［I-D.ietf-eap-keying］として参照。

１１．Forsberg,D.、「Protocol for Carrying Authentication for Network Access(PANA)」、draft-ietf-pana-pana-08(work in progress)、２００５年５月。本明細書では［Ｉ−Ｄ．−ｐａｎａ−ｐａｎａ］として参照。

１２．ITU-T、「General Characteristics of International Telephone Connections and International Telephone Circuits:One-Way Transmission Time」、ITU-T Recommendation G.114、１９９８年。本明細書では［ＲＧ９８］として参照。

１３．ITU-T、「The E-Model,a computational model for use in transmission planning」、ITU-T Recommendation G.107、１９９８年。本明細書では［ＩＴＵ９８］として参照。

１４．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。本明細書では［ＥＴＳＩ］として参照。

１５．Kivinen,T.及びH.Tschofenig、「Design of the MOBIKE protocol」、draft-ietf-mobike-design-02(work in progress)、２００５年２月。本明細書では［I-D.ietf-mobike-design］として参照。

１６．Moskowitzh,R.、「Host Identity Protocol」、draft-ietf-hip-base-03(work in progress)、２００５年６月。本明細書では［I-D.ietf-hip-base］として参照。

１７．Almes,G.、Kalidindi,S.、及びM.Zekauskas、「A One-way Delay Metric for IPPM」、RFC 2679、１９９９年９月。本明細書では［ＲＦＣ２６７９］として参照。

１８．Almes,G.、Kalidindi,S.、及びM.Zekauskas、「A One-way Packet Loss Metric for IPPM」、RFC 2680、１９９９年９月。本明細書では［ＲＦＣ２６８０］として参照。

１９．Almes,G.、Kalidindi,S.、及びM.Zekauskas、「A Round-trip Delay Metric for IPPM」、RFC 2681、１９９９年９月。本明細書では［ＲＦＣ２６８１］として参照。

２０．Simpson,W.、「IP in IP Tunneling」、RFC 1853、１９９５年１０月。本明細書では［ＲＦＣ１８５３］として参照。

２１．Patrik,M.、「DHCP Relay Agent Information Option」、RFC ３０４６、２００１年１月。本明細書では［ＲＦＣ３０４６］として参照。

２２．Kim,P.,Volz,B.、及びS.Park、「Rapid Commit Option for DHCPv4」、draft-ietf-dhc-rapid-commit-opt-05(work in progress)、２００４年６月。本明細書では［I-D.ietf-dhc-rapid-commit-opt］として参照。

２３．Ohba,Y.、「Media-Independent Pre-Authentication(MPA)Implementation Results」、draft-ohba-mobopts-mpa-implementation-00(work in progress)、２００５年６月。本明細書では［I-D.ohba-mobopts-mpa-implementation］として参照。

２４．Schulzrine,H.、「Appliation Layer Mobility Using SIP」、MC2R。本明細書では［ＳＩＰＭＭ］として参照。

２５．Cambell,A.、Gomez,J.、Kim,S.、Valko,A.、及びC.Wan、「Design,Implementation,and Evaluation of Cellular IP」、IEEE Personal communication、２０００年８月。本明細書では［ＣＥＬＬＩＰ］として参照。

２６．Ramjee,R.、Porta,T.、Thuel,S.、Varadhan,K.、及びS.Wang、「HAWAII:A Domain-based Approach for Supporting Mobility in Wide-area Wireless networks」、International Conference on Network Protocols、ICNP‘99。本明細書では「ＨＡＷＡＩＩ」として参照。

２７．Das,S.、Dutta,A.、Misra,A.及びS.Das、「IDMP:An Intra-Domain Mobility Management Protocol for Next Generation Wireless Networks」、IEEE Wireless Communication Magazine、２０００年１０月。本明細書では「ＩＤＭＰ」として参照。

２８．Calhoun,P.、Montenegro,G.、Perkins,C.、及びE.Gustafsson、「Mobile IPv4 Regional Registration」、draft-ietf-mobileip-reg-tunnel-09(work in progress)、２００４年７月。本明細書では［I-D.ietf-mobileip-reg-tunnel］として参照。

２９．Yokota,H.、Idoue,A.、及びT.Hasegawa、「Link Layer Assisted Mobile IP Fast Handoff Method over WirelessLAN Networks」、Proceedings of ACM Mobicom。本明細書では［ＹＯＫＯＴＡ］として参照。

３０．Shin,S.、「Reducing MAC Layer Handoff Latency in IEEE 802.11 Wireless LANs」、MOBIWAC Workshop。本明細書では［ＭＡＣＤ］として参照。

３１．Dutta,A.、Zhang,T.、Madhani,S.、Taniuchi,K.、Ohba,Y.、及びH.Schulzrinne、「Secured Universal Mobility」、WMASH ２００４年。本明細書では［ＳＵＭ］として参照。

３２．Dutta,A.、Madhani,S.及びH.Schulzrinne、「Fast handoff Schemes for Application Layer Mobility Management」、PIMRC ２００４年。本明細書では［ＳＩＰＦＡＳＴ］として参照。

３３．Gwon,Y.、Fu,G.、及びR.Jain、「Fast Handoffs in Wireless LAN Networks using Mobile initiated Tunneling Handoff Protocol for IPv4(MITHv4)」、Wireless Communications and Networking ２００３、２００５年１月。本明細書では［ＭＩＴＨ］として参照。

３４．Anjum,F.、Das,S.、Dutta,A.、Fajardo,V.、Madhani,S.、Ohba,Y.、Taniuchi,K.、Yaqub,R.、及びT.Zhang、「A proposal for MIH function and Information Service」、ＩＥＥＥ ８０２．２１作業部会に対する寄稿。２００５年１月。本明細書では［ＮＥＴＤＩＳＣ］として参照。

３５．「IEEE Wireless LAN Edition A compilation based on IEEE Std 802.11-1999(R2003)」、電気電子技術者協会(Institute of Electrical and Electtoniccs Engineers)２００３年９月。本明細書では［８０２．１１］として参照。

３６．Dutta,A.、「GPS-IP based fast-handoff for Mobiles」、NYMAN2003。本明細書では［ＧＰＳＩＰ］として参照。

３７．Vatn,J.及びG.Maguire、「The effect of using co-located care-of-address on macro handover latency」、14th Nordic Teletraffic Seminar、１９９８年。本明細書では［ＭＡＧＵＩＲＥ］として参照。

本発明は、前記及び／又は他の背景技術及び／又はその中の課題を改良する。

媒体非依存事前認証フレームワークにおける、第１のネットワークと第２のネットワークの間でのモバイルノードの切り替え復帰に関するハンドオフ決定を制御する方法は、ａ）近接するネットワークにおけるアクセスポイントに関して位置決定を行うように構成される位置決定モジュールをモバイルノードに設けることと、ｂ）位置決定モジュールの出力に少なくとも部分的に基づいて、第１のネットワークと第２のネットワーク間での発振を回避するために位置をベースにしたアルゴリズムを使用することとを備える。

いくつかの例では、方法はさらに、位置をベースにしたアルゴリズムがモバイルノードの位置とこのモバイルノードの従前のハンドオーバ活動に関してキャッシュに入れられたデータ（キャッシュ化データ(cached data)）の間の相関関係に少なくとも部分的に基づくことをさらに含む。いくつかの例では、方法は、キャッシュに入れられたデータがモバイルノード上のデジタルデータ記憶装置の中に記憶されることをさらに含む。いくつかの例では、方法は、位置をベースにしたアルゴリズムが、該モバイルノードが第１のネットワークと第２のネットワークの他方に切り替わった過去の例に関するデータに基づいて第１のネットワークと第２のネットワークの他方に切り替えることに備えることを含むこと、をさらに含む。いくつかの例では、方法は、位置をベースにしたアルゴリズムが、該モバイルノードが第１のネットワークと第２のネットワークの他方に切り替わらなかった過去の例に関するデータに基づいて第１のネットワークと第２のネットワークの他方に切り替わらないことに備えることを含むこと、をさらに含む。いくつかの例では、方法は、位置決定モジュールがＧＰＳ受信機を含むことをさらに含む。いくつかの例では、方法は、第１のネットワークと第２のネットワークの間の発信を回避するために位置をベースにしたアルゴリズムを使用することをさらに含み、少なくとも一つの非位置決めインジケータ(non-location indicator)に少なくとも部分的に基づいたアルゴリズムを有することを含む。いくつかの例では、前記少なくとも１つの非位置決めインジケータは信号対雑音比のインジケータを含む。いくつかの例では、方法は、第１のネットワークが第１の媒体用であり、第２のネットワークが別の媒体用であることを含み、第１の媒体がセルラーで、該別の媒体は無線ＬＡＮであるか、又は第１の媒体が無線ＬＡＮで、該別の媒体がセルラーであるかのどちらかである。

他のいくつかの実施形態に従って、媒体に依存しない事前認証フレームワークにおいて第１のネットワークと第２のネットワークの間のモバイルノードの望ましくない切り替え復帰の影響を緩和する方法は、ａ）第１のネットワークに関連するコンテキストを、該コンテキストが、携帯電話が第１のネットワークに戻ると迅速に回復できるようにある期間維持することと、ｂ）該モバイルノードに第１のネットワークに戻るとコンテキストを使用させることとを含む。いくつかの例では、方法は、コンテキストがモバイルノード上のデジタルデータに記憶され、確立されたセキュリティ関連付け、ＩＰアドレス又はトンネルに関するデータを含むことをさらに含む。いくつかの例では、第１のネットワークは第１の媒体用であり、第２のネットワークは別の媒体用であり、第１の媒体がセルラーで、該別の媒体が無線ＬＡＮであるか、又は第１の媒体が無線ＬＡＮで、該別の媒体がセルラーであるかのどちらかである。

いくつかの他の実施形態に従って、媒体に依存しない事前認証フレームワークにおいて前のネットワークと新しいネットワークの間でのモバイルノードの望ましくない切り替え復帰の影響を緩和する方法は、モバイルノードが新しいネットワークから前のネットワークも戻る場合にパケットの損失を回避するために一時期前のネットワークと新しいネットワークの両方にデータパケットを送信することを含む。いくつかの例では、データパケットを送信する該ステップは、該データパケットをバイキャスティング（ｂｉｃａｓｔｉｎｇ）することを含む。いくつかの例では、前のネットワークは第１の媒体用であり、新しいネットワークは別のネットワーク用であり、第１の媒体がセルラーで、別の媒体が無線ＬＡＮであるか、あるいは第１の媒体が無線ＬＡＮで、別の媒体がセルラーであるかのどちらかである。

多様な実施形態の前記の及び／又は他の態様、特長及び／又は利点は、添付図面に関連して以下の説明を鑑みるとさらに理解されるであろう。多様な実施形態は、当てはまる場合、様々な態様、特長、及び／又は利点を含む、及び／又は除くことができる。加えて、多様な実施形態は、当てはまる場合、他の実施形態の１つ又は複数の態様又は特長を組み合わせることができる。特定の実施形態の態様、特長、及び／又は利点の説明は、他の実施形態又は請求項を制限するとして解釈されてはならない。

本発明の好ましい実施形態は、制限ではなく一例として添付図に示されている。

本発明は多くの異なる形式で具現化されてよいが、多くの例示的な実施形態は、本開示が本発明の原則の例を提供すると見なされるべきである旨、及びこのような例が、本明細書に説明されている、及び／又は本明細書に描かれている好ましい実施形態に本発明を制限することを目的としていない旨を理解した上で本明細書に説明されている。

詳細な説明
迅速なサブネットとドメインのハンドオーバを経験する携帯電話に最適化されたハンドオーバを提供するために、いくつかの問題点に取り組む。これらの問題点は近接ネットワーキング要素の発見、特定の方針に基づいて接続先の正しいネットワークを選ぶこと、第２層接続ポイントを変更すること、ＤＨＣＰサーバ又はＰＰＰサーバからＩＰアドレスを取得すること、該ＩＰアドレスの一意性を確認すること、例えば特定のドメインのＡＡＡサーバのような認証エージェントと事前認証すること、一致するホストにバインディング更新を送信し、新しい接続ポイントへのリダイレクトされたストリーミングトラフィックを取得することと、ピンポン減少、及び複数のネットワークに移動する蓋然性を含む。例えばＭＰＡをベースにした安全先行ハンドオーバの関連で、これらの問題点及びこれらに対処する又は最適化するための方法が後述される。

１．発見
アクセスポイント、アクセスルータ、認証サーバ等の近接するネットワーキング要素を発見すると、携帯電話がネットワーク間で急速に移動する際にハンドオーバプロセスを迅速に処理するのに役立つ。所望される座標のセットでネットワーク近隣を発見することにより、携帯電話の機能及びパラメータは事前認証、先行ＩＰアドレス獲得、先行アドレス解決、及びバインディング更新等の作業の多くを、前のネットワークの間に実行できる。

携帯電話が近接するネットワークを発見できるいくつかの方法がある。候補アクセスルータ発見プロトコル（前記参考文献［I-D.ietf-seamoby-card-protocol］を参照されたい）は、近接するネットワークにおいて候補アクセスルータを発見するのに役立つ。特定のネットワークドメインを考慮すると、サービスロケーションプロトコル（ＳＬＰ）とドメイン名サービス（ＤＮＳ）は、特定のドメインでのサービスの既定のセットにネットワーキング構成要素のアドレスを与えるのに役立つ。場合によっては、ネットワーク層と上位層のパラメータの多くが、携帯電話が近接するネットワークの近傍に近づくと、ビーコン等のリンク層管理フレーム上で送信されてよい。ＩＥＥＥ ８０２．１１ｕはリンク層に含まれる情報を使用して近隣を発見すること等の問題点を検討している。しかしながら、リンク層管理フレームがなんらかのリンク層セキュリティ機構により暗号化されている場合には、モバイルノードはアクセスポイントへのリンク層接続性を確立する前に必要な情報を得ることはできない可能性がある。さらに、これは帯域幅が制限された無線媒体に重荷を追加することがある。このような場合、近接する要素に関する情報を取得するためにさらに上位層のプロトコルが好まれる。近接するネットワークについてのこれらの情報をモビリティサーバから取得するのに役立つ、例えば前記参考文献［ＮＥＴＤＩＳＣ］においてのようななんらかの提案がある。形態電話の移動が差し迫っているときには、それは特定のサーバに問合せを行うことによって発見プロセスを開始し、アクセスポイントのＩＰアドレス、その特徴、ルータ、近接ネットワークのＳＩＰサーバ又は認証サーバ等の必要とされるパラメータを得る。ネットワークが複数の場合には、それは複数の近接ネットワークから必要とされるパラメータを取得し、これらをキャッシュに保存してもよい。ある時点で、携帯電話は多くの有望なネットワークの中から複数のＣＴＮを見出し、ＣＴＮにおいて必要とされるエンティティと通信することによって事前認証プロセスを開始する。このシナリオは、以下の第２項にさらに詳細に述べられている。

２．複数のＣＴＮ環境での事前認証
場合によっては、携帯電話がターゲットネットワークとなる特定のネットワークを決定しても、それは実際には、携帯電話の制御を超えている要因のためにターゲットネットワーク以外の近接するネットワークに移動して終わることがある。したがって、いくつかの有望な候補ターゲットネットワークと事前認証を実行し、それらのネットワークの中でそれぞれのターゲットルータと期限を定めたトンネルを確立することが役立つ場合がある。したがって、携帯電話が以前に決定されたとおりにターゲットネットワークに移動しない場合、それは、結局は別のターゲットネットワークに移動するため、事後認証及びＩＰアドレス獲得遅延のためのパケット損失を受けない。多くの候補ターゲットネットワークと事前認証し、ＩＰアドレスを確保することによって、携帯電話はそれ以外の場合使用できたであろうリソースを供給しているように見える。しかし、これは限られた期間に起こるため、それは大きな問題となってはならない。携帯電話は先行してＩＰアドレスを取得し、ターゲットアクセスルータと期限を定めたトンネルをセットアップするために事前認証手順を使用する。

通常のシナリオでは、携帯電話は仮想インタフェースに新しいＩＰアドレスを割り当てる。しかし、隣接ネットワークから複数のＩＰアドレスを取得する場合には、それは２つのことを行うことができる。それは携帯電話が移動することを決定したネットワークのＩＰアドレスとの１つの仮想インタフェースを作成できるか、又はそれは隣接ネットワークから取得されるそれぞれのＩＰアドレスを使用して複数の仮想インタフェースを作成できるかのいずれかである。携帯電話は、バインディング更新アドレスとしてこれらのアドレスの内の１つを選び、それを一致するホスト（ＣＨ）に送信してよく、このようにして前のネットワークにいる間にターゲットネットワークを介してトンネルを行うトラフィックを受信するだろう。しかし、いくつかの例では、携帯電話は、結局ターゲットネットワーク以外のネットワークに移動する可能性がある。したがって、携帯電話は新しいＩＰアドレスを割り当て、バインディング更新を再度送信するプロセスを経なければならないため、携帯電話が新しいネットワークに移動するとトラフィックに混乱が生じる。この問題を処理するために２つの解決策を提案できる。携帯電話は同時移動性バインディングを利用し、複数のバインディング更新を対応するホストに送信できる。したがって、対応するホストは特定の期間、仮想インタフェースに割り当てられた複数のＩＰアドレスにトラフィックを送信する。このバインディング更新は、携帯電話が新しいネットワークに移動し、したがって他の候補ネットワークへの流れを停止した後にＣＨで新しくされる。特定の移動性方式で同時バインディングがサポートされていない場合は、前のターゲットネットワークからのトラフィックの転送が、新しいバインディング更新が新しいネットワークから出るまで過渡的なトラフィックを処理するのに役立つであろう。

３．先行ＩＰアドレス獲得
一般的には、移動性管理プロトコルは外部エージェント（ＦＡ）と関連して、又は同位置アドレスモードで機能する。我々のＭＰＡ手法は同位置アドレスモード(co-located address mode)と外部エージェントアドレスモードの両方とも使用できる。ここでは、同位置アドレスモードで使用されるアドレス割り当て構成要素を説明する。モバイルノードがＩＰアドレスを取得し、それ自体を構成できるいくつかの方法がある。最も一般的には、携帯電話はネットワーク内のサーバ又はルータ等の任意の構成要素がない場合に静的にそれ自体を構成できる。ＩＥＴＦ Ｚｅｒｏｃｏｎｆ作業部会は、携帯電話が特別に構成され、１６９．２５４．ｘ．ｘ．のような指定された範囲から一意のアドレスを選ぶ自動ＩＰ機構を定める。ＬＡＮ環境では、携帯電話は動的ホスト構成プロトコル（ＤＨＣＰ）サーバからＩＰアドレスを取得できる。ＩＰｖ６ネットワークの場合、携帯電話は無国籍自動設定（stateless auto-configuration）又はＤＨＣＰｖ６を使用してＩＰアドレスを取得する選択肢を有する。広域ネットワーキング環境では、携帯電話はＰＰＰを使用して、ネットワークアクセスサーバ（ＮＡＳ）と通信することによってＩＰアドレスを取得する。

これらのプロセスはそれぞれ、ＩＰアドレス獲得プロセスのタイプと、クライアントとサーバのオペレーティングシステムに応じてほぼ数百ミリ秒から数秒を要する。

ＩＰアドレス獲得はハンドオーバプロセスの一部であるため、それはハンドオーバ遅延を増加し、したがってこのタイミングを可能な限り多く短縮することが望ましい。例えば、ＩＰアドレス獲得時間のためにハンドオーバ時間を短縮しようと試みる、使用可能なＤＨＣＰ高速コミット（例えば、前記参考文献［I.D.ietf-dhc-rapid-commit-opt]を参照されたい)及びＧＰＳ座標をベースにしたＩＰアドレス（例えば前記の参考文献［ＧＰＳＩＰ］を参照されたい）等の最適化された技法はほとんどない。しかしながら、これらすべての場合で、携帯電話は、モバイルノードとＤＨＣＰサーバの間のシグナリングハンドシェイクのために、新しいサブネットに移動し、遅れを被った後にＩＰアドレスを取得する。
下記パラグラフでは、モバイルノードがＣＴＮから先行してＩＰアドレスを取得することができる多くの方法及び関連付けられたトンネルセットアップ手順を説明する。これらはＰＡＮＡ支援先行ＩＰアドレス獲得、ＩＫＥ支援先行ＩＰアドレス獲得、ＤＨＣＰだけを使用する先行ＩＰアドレス獲得及びステートレス自動構成等の４つのカテゴリに幅広く定義できる。

３．１ ＰＡＮＡ支援先行ＩＰアドレス獲得
ＰＡＮＡ支援先行ＩＰアドレス獲得の場合、モバイルノードはＣＴＮから先行してＩＰアドレスを取得する。モバイルノードはＣＴＮ内のアクセスルータ内のＰＡＮＡ認証エージェントと同一位置に配置するＤＨＣＰ中継エージェントでアドレス獲得プロセスをトリガするためにＰＡＮＡメッセージを利用する。モバイルノードからＰＡＮＡメッセージを受信すると、ＤＨＣＰ中継エージェントはＣＴＮ内のＤＨＣＰサーバからＩＰアドレスを取得するために通常のＤＨＣＰメッセージ交換を実行する。このアドレスはＰＡＮＡメッセージの中でピギーバックされ、クライアントに配信される。ステータス自動構成のＭＩＰｖ６の場合は、新しいターゲットネットワークからのルータ広告がＰＡＮＡメッセージの一部としてクライアントに渡される。携帯電話は、それが新しいネットワークにおいて行うであろうように、一意のＩＰｖ６アドレスを構築するためにこの接頭語とＭＡＣアドレスを使用する。ステートフルモードのモバイルＩＰｖ６はＤＨＣＰｖ４と非常に類似して作用する。

３．２ ＩＫＥｖ２支援先行ＩＰアドレス獲得
ＩＫＥｖ２支援先行ＩＰアドレス獲得は、ＩＰｓｅｃゲートウェイとＤＨＣＰ中継エージェントがＣＴＮ内の各アクセスルータの中に常駐しているときに作用する。この場合、ＩＰｓｅｃゲートウェイとＣＴＮの中のＤＨＣＰ中継エージェントは、モバイルノードがＣＴＮ内のＤＨＣＰサーバからＩＰアドレスを獲得するのに役立つ。事前認証段階の間に確立されたＭＮ−ＡＲキーは、モバイルノードとアクセスルータの間でＩＫＥｖ２を実行するために必要とされるＩＫＥｖ２事前共用秘密として使用される。ＣＴＮからのＩＰアドレスは、標準的なＩＫＥｖ２手順として取得され、標準ＤＨＣＰを使用してターゲットネットワーク内のＤＨＣＰサーバからＩＰアドレスを取得するために同一位置に配置されたＤＨＣＰ中継エージェントを使用する。取得されたＩＰアドレスはＩＫＥｖ２構成ペイロード交換でクライアントに送り返される。この場合、ＩＫＥｖ２は先行ハンドオーバトンネル（以下の第５項を参照されたい）のためのトンネル管理プロトコルとしても使用される。

３．３ ＤＨＣＰを単独で使用する先行ＩＰアドレス獲得
別の代替策として、ＰＡＮＡをベースにした又はＩＫＥｖ２をベースにした手法に依存せずに、モバイルノードとＣＴＮの中のＤＨＣＰリレー又はＤＨＣＰサーバの間の直接的なＤＨＣＰ通信を可能にすることによって、ＣＴＮからＩＰアドレスを先行して取得するためにＤＨＣＰが使用されてよい。この場合、モバイルノードは、要求のソースアドレスとして現在の物理インタフェースと関連付けられたアドレスを使用する一方で、アドレスを要求しているＣＴＮ内のＤＨＣＰ中継エージェント又はＤＨＣＰサーバにユニキャストＤＨＣＰメッセージを送信する。

メッセージがＤＨＣＰ中継エージェントに送信されると、ＤＨＣＰ中継エージェントはＤＨＣＰメッセージをモバイルノードとＤＨＣＰサーバの間で往復で中継する。ＤＨＣＰ中継エージェントがない場合には、携帯電話はターゲットネットワーク内のＤＨＣＰサーバとじかに通信することもできる。クライアントのユニキャストＤＩＳＣＯＶＥＲ（発見）メッセージの中の放送オプションは、中継エージェント又はＤＨＣＰサーバがモバイルノードのソースアドレスを使用して携帯電話に直接応答を送り返すことができるように０に設定されなければならない。この仕組みは、ステートフル構成を使用するＩＰｖ６に対しても作用する。

悪意のあるノードがＤＨＣＰサーバからＩＰアドレスを取得するのを妨げるために、ＤＨＣＰ認証が使用されなければならない、又はアクセスルータが事前認証されていないモバイルノードからリモートＤＨＣＰサーバに送信されるユニキャストＤＨＣＰメッセージを遮断するためにフィルタをインストールしなければならない。ＤＨＣＰ認証を使用する場合、ＤＨＣＰ認証キーがモバイルノードと候補ターゲットネットワーク内の認証エージェントの間で確立されるＭＰＡ−ＳＡから導出されてよい。

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

３．４ ステートレス自動構成を使用する先行ＩＰアドレス獲得
ＩＰｖ６の場合、ネットワークアドレス構成はＤＨＣＰｖ６又はステートレス自動構成のどちらかを使用して行われる。新ＩＰアドレスを先行して取得するために、次のホップルータのルータ通知が確立されたトンネル上で送信することができ、新ＩＰ６アドレスは携帯電話の局番とＭＡＣアドレスに基づいて生成される。このアドレスはクライアントの仮想アドレスに割り当てられ、ホームエージェント又は一致するノードにバインディング更新として送信される。通常は詳しく調べられた（scoped）マルチキャストアドレスで送信されるこのルータ通知は、携帯電話のｏＣｏＡに容易にトンネルを行うことができる。これにより、ＩＰアドレスを取得し、二重アドレス検出を実行するために要する時間が回避されるだろう。

携帯電話が新ネットワークに入ると、モバイルノードは、例えばＤＨＣＰ ＩＮＦＯＲＭを使用することによりＳＩＰサーバ、ＤＮＳサーバ等の他の構成パラメータを取得するために物理インタフェース上で新ネットワークに対してＤＨＣＰを実行することができる。これは、携帯電話と一致するホスト間の継続中の通信に影響を及ぼしてはならない。また、モバイルノードは新しいネットワークに入る前に先行して取得されたアドレスの賃貸を延長するために、新ネットワークに対して物理インタフェース上でＤＨＣＰを実行できる。

モバイルノードのためのＤＨＣＰバインディングを維持し、安全先行ハンドオーバの前後に分配されたＩＰアドレスを追跡調査するために、先行ＩＰアドレス獲得のためのＤＨＣＰと、モバイルノードがターゲットネットワークに入った後に実行されたＤＨＣＰの両方について、同じＤＨＣＰクライアント識別子がモバイルノードに使用される必要がある。ＤＨＣＰクライアント識別子は、モバイルノードのＭＡＣアドレス又は他のなんらかの識別子であってよい。ステートレス自動構成の場合では、携帯電話は新しいネットワークでのルータ広告の接頭語を確かめ、それを新規に割り当てられたＩＰアドレスの局番と突き合せる。これらが同じであることが判明すると、携帯電話はＩＰアドレス獲得段階を再度経過しない。

４．アドレス解決問題
４．１ 先行二重アドレス検出
ＤＨＣＰサーバがＩＰアドレスを分配するとき、それはその賃貸表を更新し、その結果この同じアドレスはその特定の期間別のクライアントに与えられない。同時に、クライアントは、それが必要に応じて更新できるように賃貸表を局所的に保存する。ネットワークがＤＨＣＰでイネーブルされたクライアントとＤＨＣＰでイネーブルされていないクライアントの両方からなる場合は、ＬＡＮを使う別のクライアントがＤＨＣＰアドレスプールからのＩＰアドレスで構成されたかもしれない蓋然性がある。

このようなシナリオでは、サーバは、ＩＰアドレスを割り当てる前に、ＡＲＰ（アドレス解決プロトコル）又はＩＰｖ６近傍発見に基づいて二重アドレス検出を行う。検出手順は最高４秒から１５秒を要することがあり（例えば、下記の参考文献［ＭＡＧＵＩＲＥ］を参照されたい）、したがってさらに大きなハンドオーバ遅延の一因となる。先行ＩＰアドレス獲得プロセスの場合は、この検出は事前に行われるため、ハンドオーバ遅延にまったく影響を及ぼさない。二重アドレス検出を事前に行うことにより、ハンドオーバ遅延係数を削減する。

４．２ 先行アドレス解決更新
事前認証のプロセスの間、ターゲットネットワークに接続してからターゲットネットワーク内のノードと通信するためにモバイルノードにより必要とされるアドレス解決マッピングも公知であり、ノードはアクセスルータ、認証エージェント、構成エージェント及び一致するノードであってよい。このような先行アドレス解決を実行する多くの方法がある。

１．ノードのＭＡＣアドレスを解決するために情報サービス機構（例えば、前記参考文献［ＮＥＴＤＩＳＣ］を参照されたい）を使用する。これにより、ターゲットネットワークの中の各ノードが、情報サービスのサーバが先行アドレス解決のデータベースを構築できるように情報サービスに関与することが必要である可能性がある。

２．先行アドレス解決をサポートするために、事前認証のために使用される認証プロトコル又は事前構成に使用される構成プロトコルを拡張する。例えば、ＰＡＮＡが認証プロトコルとして事前認証に使用される場合、ＰＡＮＡメッセージは先行アドレス解決に使用されるＡＶＰを搬送してよい。この場合、ターゲットネットワーク内のＰＡＮＡ認証エージェントはモバイルノードの代わりにアドレス解決を実行してよい。

３．ターゲットネットワークのネットワーク要素の特定のＩＰアドレスと関連付けられた特定のインタフェースのＭＡＣアドレスをマッピングするためにＤＮＳを利用することもできる。ターゲットネットワークのノードのＭＡＣアドレスを先行して解決するために新しいＤＮＳリソースレコード（ＲＲ）を定義してよい。ただし、ＭＡＣアドレスはドメインネームに直接結び付けられるのではなく、ＩＰアドレスに結び付けられるリソースであるため、この手法には独自の制限がある。

モバイルノードがターゲットネットワークに接続すると、それはターゲットネットワーク内のノードに対するアドレス解決照会を必ずしも実行せずに先行して取得されたアドレス解決マッピングをインストールする。

他方、ターゲットネットワークに属し、モバイルノードと通信しているノードも、モバイルノードがターゲットネットワークに接続するとすぐにモバイルノードのためのそのアドレス解決マッピングを更新する必要がある。前記の先行アドレス解決方法は、モバイルノードがターゲットネットワークに接続する前にモバイルノードのＭＡＣアドレスを先行して解決するために、それらのノードに対して使用することもできる。しかしながら、それらのノードは先行して解決されたアドレス解決マッピングを採用する前にターゲットネットワークへのモバイルノードの接続を検出する必要があるため、これは役に立たない。さらに優れた手法は、接続検出及びアドレス解決マッピング更新の統合であろう。これは、ターゲットネットワーク内のノードがモバイルノードのアドレス解決マッピングを迅速に更新できるようにモバイルノードが新ネットワークに接続される直後に、モバイルノードが、ＩＰｖ４の場合にはアドレス解決プロトコル（ＡＲＰ）ＡＲＰ要求又はＡＲＰ応答を送り、又はＩＰｖ６の場合には近傍通知を送るアドレス解決（上記参考文献［ＲＦＣ３３４４］及び［ＲＦＣ３７７５］参照）を不当に実行することに基づいている。

５．トンネル管理
ＩＰアドレスがＣＴＮ内のＤＨＣＰサーバから先行して獲得された後、先行ハンドオーバトンネルがモバイルノードとＣＴＮ内のアクセスルータの間で確立される。モバイルノードはトンネル内部アドレスとして獲得されたＩＰアドレスを使用し、たぶん仮想インタフェースにそのアドレスを割り当てる。

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

また、ＰＡＮＡが先行ＩＰアドレス獲得に使用される場合、ＰＡＮＡは安全なトンネル管理プロトコルとして使用されてよい。

いったん先行ハンドオーバトンネルがモバイルノードと候補ターゲットネットワーク内のアクセスルータの間に確立されると、アクセスルータは、それがモバイルノードの新しいアドレスに宛てられるあらゆるパケットを捕捉できるようにモバイルノードの代わりにプロキシアドレス解決を実行する必要もある。

携帯電話は前のネットワークにいる間に一致するノードと通信できる必要があるため、バインディング更新と、一致するノードからモバイルノードへのデータのいくつかの部分又はすべての部分が先行ハンドオーバトンネル上でモバイルノードに送り返される必要がある。セッション開始プロトコル（ＳＩＰ）モビリティが移動性管理プロトコルに使用されると、連絡アドレスとしての新しいアドレスがＳＩＰ Ｒｅ−ＩＮＶＩＴＥを使用して一致するノードに報告される。いったん一致するノードのＳＩＰユーザエージェントが新しい連絡アドレスを取得すると、それはターゲットネットワークに実際に属する新しい連絡アドレスにＯＫを送信する。ターゲットネットワーク内のアクセスルータは、それが新しい連絡アドレスに向けられていたのでＯＫ信号を獲得し、それをその前のネットワークの携帯電話にトンネルを行う。最終的なＡＣＫメッセージは携帯電話から一致するノードに受信される。携帯電話から一致するノードへのデータは進入フィルタリング(ingress filtering)がない場合にはトンネルを行う必要がない場合もある。ＳＩＰ Ｒｅ−ＩＮＶＩＴＥシグナリングハンドシェイクの完了後、一致するノードからのデータが先行ハンドオーバトンネルを介して携帯電話に送信される。

モバイルノードがターゲットネットワークに接続した後にトラフィックがモバイルノードに向けられるためには、先行ハンドオーバトンネルが削除される又は無効にされる必要がある。トンネルを確立するために使用されるトンネル管理プロトコルは、この目的に使用される。

また、ＰＡＮＡが認証プロトコルとして使用される場合、アクセスルータでのトンネルの削除又は無効は、携帯電話がターゲットネットワークに移動するとすぐにＰＡＮＡ更新機構によってトリガできる。リンク層トリガは、モバイルノードが実際にターゲットネットワークに接続され、トンネルを削除する、又は無効にするためのトリガとして使用することもできることを確実にする。

６．バインディング更新
様々な移動性管理方式のためのいくつかの種類のバインディング管理機構がある。ＲＯのないモバイルＩＰｖ４等の場合には、バインディング更新はホームエージェント（ＨＡ）だけに送信され、モバイルＩＰｖ６の場合にはバインディング更新がホームエージェントと対応するホストの両方に送信される。ＳＩＰをベースにした端末モビリティの場合には、携帯電話はＲｅ−ＩＮＶＩＴＥを使用してバインディング更新を一致するノードに、ＲＥＧＩＳＴＥＲメッセージを登録機関に送信する。携帯電話と一致するノードの間の距離に基づき、バインディング更新はハンドオーバ遅延の一因となる場合がある。ＳＩＰ高速ハンドオーバ（例えば［ＳＩＰＦＡＳＴ］を参照されたい）は、バインディング更新に起因するハンドオーバ遅延を削減するいくつかの方法を提供する。ＳＩＰベースのモビリティ管理を使用する安全先行ハンドオーバの場合には、それは前のネットワークで起こるため、バインディング更新に起因する遅延を完全に排除する。したがって、本方式は、一致するノードが通信するモバイルノードから遠すぎるときにより魅力的に見える。

７．パケット損失の妨害
ＭＰＡの場合には、ＩＰアドレス獲得、保護された認証、及びバインディング更新のためのパケット損失を認めなかった。しかしながら、モバイルノードがターゲットネットワークに接続できる前にモバイルノードに向けられるリンク層ハンドオーバ中のいくつかの過渡的なパケットがある場合がある。それらの過渡的なパケットは損失することがある。

アクセスルータで過渡的なパケットをバイキャスティングする、又はバッファに入れることは、パケット損失を最小限に抑える又は排除するために使用できる。ただし、リンク層ハンドオーバがシームレスに実行されない場合には、バイキャスティングはパケット損失を排除しない。他方、バッファリングはパケット遅延を削減しない。パケット遅延はストリーミング用途の場合受信機側でプレイアウトバッファ（playout buffer）によって補償できるが、プレイアウトバッファは大きな遅延ジッタに耐えることのできない対話型のＶｏＩＰ用途ではあまり役に立たない。したがって、いずれにせよリンク層ハンドオーバを最適化することは依然として重要である。

さらに、ＭＮは古い接続ポイントから切り替わる前に新しい接続ポイントへの到達可能性を保証してもよい。これは、リンク層管理フレームを新しい接続ポイントと交換することによって行うことができる。この到着可能性チェックは可能な限り迅速に実行されなければならない。到着可能性チェックの間のパケット損失を妨ぐために、ＭＮと古い接続ポイントの間のリンク上でのパケットの伝送は、到着可能性チェックの間リンクの両端でパケットをバッファに入れることにより保留されなければならない。本明細書に基づいて理解されるように、このバッファリングは種々の方法で実行できる。

８．切り替えの失敗及び切り替え復帰のための考慮事項
ピンポン現象は、ハンドオーバシナリオの間に見られる共通の問題の１つである。このようなピンポン現象は、携帯電話がセル又は決定ポイントの境界線に位置し、ハンドオーバ手順が頻繁に実行されるときに生じる。

とりわけ、この結果、呼中止確率（call drop probability）の上昇、接続品質の低下、シグナリングトラフィックとリソースの無駄の増加が生じる。これらのすべてが移動性最適化に影響を及ぼす。ハンドオフアルゴリズムはネットワーク間でハンドオフを実行するための決定要因である。従来、これらのアルゴリズムはハンドオフに関して決定するために様々な測定基準の値を比較するために閾値を利用する。これらの測定基準は信号強度、経路損失、搬送波対干渉比（ＣＩＲ）、信号対干渉比（ＳＩＲ），ビット誤り率（ＢＥＲ）、電力予算等を含む。

ピンポン現象を回避するために、いくつかの追加のパラメータが、ヒステリシスマージン、ドウェルタイマー、及び平均化ウィンドウ等の決定アルゴリズムによって利用される。高い移動車両の場合、モバイルホスト（ＭＨ）と接続点間の距離、携帯電話の速度、携帯電話の位置、トラフィックと帯域幅特性等の他のパラメータもピンポン現象を削減するために考慮に入れられる。

さらに最近では、仮説検証、動的プログラミング等の技法及びパターン認識技法に基づいている異機種ネットワーク環境でのピンポン現象を削減するのに役立つ他のハンドオフアルゴリズムがある。ピンポン現象を削減するためにハンドオフアルゴリズムを実現することは重要であるが、この現象から回復するための方法を実現することも重要である。

ＭＰＡフレームワークの場合には、ピンポン現象は現在のネットワークとターゲットネットワークの間、及び候補ターゲットネットワーク間での携帯電話の前後運動を生じさせる。その現在の形式でのＭＰＡは、多数のトンネルセットアップ、バインディング更新の数、及び関連付けられたハンドオフ待ち時間のために影響を受ける。ピンポン現象はハンドオフ速度に関連しているため、それも遅延とパケット損失の一因となる可能性がある。

いくつかの実施形態において、ピンポンの確率を削減するのに役立てるために実行できる複数のアルゴリズムをここで説明する。さらに、ピンポン現象から生じるパケット損失からの回復を可能にするＭＰＡフレームワークのためのいくつかの方法もここで説明する。

いくつかの実施形態では、ＭＰＡフレームワークは、グローバルポジショニングシステム（ＧＰＳ）を使用して近接するネットワーク内のＡＰに関して携帯電話のジオロケーションを利用できる。この点で、例示的なＧＰＳシステムは地球を軌道に乗せ、ＧＰＳ受信機がその地理的な位置を正確に示すことができるようにする様々な衛星を含む。ネットワーク間の発振を回避するために、位置をベースにしたインテリジェントアルゴリズムはユーザの位置と、前のハンドオーバ試行からキャッシュに入れられたデータの相関関係を使用することにより導出できる。場合によっては、位置だけがハンドオフ決定のための唯一のインジケータではないことがある。例えば、マンハッタン（Manhattan）タイプのネットワークでは、携帯電話はＡＰに近いけれども、それは良好な接続を行うほど十分な信号対雑音比（ＳＮＲ）を有さないことがある。したがって、モビリティパターン及び経路特定がピンポン現象の回避に役立つことがある。

ピンポン現象を回避できる良好なハンドオフアルゴリズムがない場合には、ピンポンの影響を緩和するために優れた回復機構を適所に配置することが必要とされることがある。携帯電話が、コンテキストが前回試用されたネットワークに戻るときにそれが迅速に回復できるように、確立されたコンテキストをある期間現在のネットワークに保持しなければならない場合がある。これらのコンテキストはセキュリティ関連付け、使用ＩＰアドレス、確立されたトンネル等を含んでよい。また、所定の期間、データを前のネットワークと新しいネットワークの両方にバイキャスティングすると、携帯電話がネットワーク間で前後に移動する場合に損失したパケットを処理するのに役立つであろう。携帯電話は、それがピンポン状況に関して安定した状態にあるかどうかを判断できなければならない。

９．リンク層セキュリティ及び移動性
事前認証段階の間にモバイルノードとＣＴＮ内の認証エージェントの間で確立されたＭＰＡ−ＳＡを使用すると、モバイルノードが以下のように現在のネットワークにある間にＣＴＮ内のリンク層セキュリティをブートすることができる。

１．ＣＴＮ内の認証エージェントとモバイルノードは、事前認証が成功した結果確立されるＭＰＡ−ＳＡを使用してＰＭＫ（ペアワイズマスタキー）（前記参考資料［I-D.ietf-eap-keying］を参照されたい）を導出する。ＥＡＰとＡＡＡプロトコルの実行は、ＭＰＡ−ＳＡを確立するための事前認証の間に必要となる可能性がある。ＰＭＫからは、モバイルノードのための別々のＴＳＫ（過渡的セッションキー）（前記［I-D.ietf-eap-keying］を参照されたい）がＣＴＮの各接続点に直接的に又は間接的に導出される。

２．認証エージェントはＰＭＫから導出され、接続ポイントへの安全な関連付けのために使用されるキーをインストールしてよい。導出されたキーはＴＳＫ又はＴＳＫが導出される中間キーであってよい。

３．モバイルノードがターゲットネットワークとしてＣＴＮを選び、（ここでモバイルノードの新しいネットワークになる）ターゲットネットワーク内の接続ポイントに切り替わった後に、それは、モバイルノードと接続ポイント間のリンク層パケットを保護するために使用されるＰＴＫ（ペアワイズ過渡的キー）とＧＴＫ（グループ過渡的キー）（前記参考文献［Ｉ−Ｄ．ｉｅｔｆ−ｅａｐ−ｋｅｙｉｎｇ］を参照されたい）を確立するために、ＰＭＫを使用してＩＥＥＥ ８０２．１１ｉ４通りハンドシェイク［８０２．１１ｉ］等の安全関連プロトコルを実行する。ＥＡＰ認証の追加の実行はここで必要とされない。

４．モバイルノードが新しいネットワークの中でローミングしている間、モバイルノードは、その接続ポイントと安全関連プロトコルを実行しさえすればよく、ＥＡＰ認証の追加の実行は必要とされない。ＭＰＡの、８０２．１１ｒ等のリンク層ハンドオーバ最適化機構の統合は、このように達成できる。

モバイルノードはＴＳＫを導出するためにＣＴＮ内の接続ポイントのリンク層アイデンティティを知る必要がある場合がある。ＰＡＮＡが事前認証のための認証プロトコルとして使用される場合、これはＰＡＡ（前記参考文献［I-D.ietf-pana-pana］を参照されたい）から送信されるＰＡＮＡ−Ｂｉｎｄ−Ｒｅｑｕｅｓｔの中でＤｅｖｉｃｅ−Ｉｄ ＡＶＰを搬送することにより可能であり、それぞれの属性値組（ＡＶＰ）は異なったアクセスポイントの基本サービスセット識別子（ＢＳＳＩＤ）を含む。

図３を参照すると、図はいくつかの例示的な実施形態に従ってリンク層セキュリティをブートすることを図表で描いている。

１０．初期ネットワーク接続での認証
モバイルノードが最初にネットワークに接続すると、ネットワークアクセス認証はＭＰＡを使用するかどうかに関係なく発生するであろう。ＭＰＡがハンドオーバ最適化のために使用されるときにネットワークアクセス認証のために使用されるプロトコルは、ＩＥＥＥ ８０２．１Ｘ等のリンク層ネットワークアクセス認証プロトコル、又はＰＡＮＡ等のさらに上位層のネットワークアクセス認証プロトコルである場合がある。

１１．セキュリティの考慮事項
本明細書は、モバイルノードと、モバイルノードが将来移動する可能性のある１つ又は複数の候補ターゲットネットワーク間でハンドオーバに関連するシグナリングを実行することに基づいた安全ハンドオーバ最適化機構のフレームワークを説明している。このフレームワークは、モバイルノードが物理的にそれらのＣＴＮの内の１つに接続する前のＣＴＮから現在のネットワーク内のモバイルモードへのデータパケットリダイレクトだけではなく、ＣＴＮからのリソースの獲得も必要とする。

候補ターゲットネットワークからのリソースの獲得は、許可されていないモバイルノードがリソースを取得するのを防ぐために適切な認証手順及び許可手順を伴わなくてはならない。このため、ＭＰＡフレームワークがモバイルノードと候補ターゲットネットワークの間で事前認証を実行することが重要である。事前認証の結果として生成されたＭＮ−ＣＡキー及びＭＮ−ＡＲキーは、以後のハンドオーバシグナリングパケットと、モバイルノードとＣＴＮの中のＭＰＡ機能要素の間で交換されるデータパケットとを保護できる。

ＭＰＡフレームワークは、ハンドオーバが複数の管理ドメイン全体で実行されるときにもセキュリティ問題に取り組む。ＭＰＡを用いると、モバイルノードと、候補ターゲットネットワーク内のルータ又はモビリティエージェントの間の直接的な通信に基づいてハンドオーバシグナリングを実行できる。これにより、セキュリティ（前記参考文献［I-D.ietf-eap-keying］を参照されたい）に関して公知の制限が存在するコンテキスト転送プロトコルに対する必要性が排除される。このため、ＭＰＡフレームワークは管理ドメイン又はアクセスルータ間の信頼関係を必要とせず、モバイル環境でのセキュリティを傷つけずに、フレームワークをインターネットの中でさらに配備しやすくする。

本発明の幅広い範囲
本発明の例示的な実施形態を本明細書に説明してきたが、本開示に基づいて当業者により理解されるように、本発明は本明細書に説明されている多様な好ましい実施形態に限定されるのではなく、同等な要素、変型、省略、（例えば、多様な実施形態全体での態様の）組み合わせ、適応、及び／又は改変を有するあらゆるすべての実施形態を含む。（例えば、後に加えられるものを含む）請求項における制限は請求項で利用される言語に基づいて幅広く解釈されるべきであり、本明細書に、あるいは出願の手続き追行の間に説明される例に限定されず、その例は包括的と解釈されるべきである。例えば、本開示では、用語「好ましくは」包括的であり、「好ましいが、限定されない」を意味する。本開示では、及び本開示の手続き追行中、手段プラス機能（means-plus-function）又はステッププラス機能（step-plus-function）の制限は、特定の請求項の制限について、以下の条件のすべてがその制限内に存在する場合にだけ利用される。つまりａ）「のための手段」又は「のためのステップ」は、明示的に列挙され、ｂ）対応する機能は明示的に列挙され、及びｃ）その構造をサポートする構造、材料又は行為が列挙される。本開示において、及び本出願の手続き追行中、用語「本発明」又は「発明」は、本開示の中で１つ又は複数の態様に対する参照として使用されてよい。言語本発明又は発明は、臨界の識別として理解されてはならず、すべての態様又は実施形態全体で当てはまると不適切に解釈されてはならず（つまり、本発明は多数の態様と実施形態を有することが理解されるべきである）、出願つまり請求項の範囲を制限すると不適切に解釈されてはならない。本開示では、及び本願の手続き追行の間、用語「実施形態」は任意の態様、特徴、プロセス又はステップ、その組み合わせ、及び／又はその任意の部分等を説明するために使用できる。いくつかの例では、多様な実施形態は重複する特長を含むことがある。本開示では、以下の省略された用語、つまり「例えば」を意味する「ｅ．ｇ．」が利用されてよい。

いくつかの例示的な実施形態に従って基本的な通信の流れを描く流れ図であり、流れ図は図２で続行する。 図１に示される流れ図の続きの基本的な通信の流れを描く流れ図である。 いくつかの例示的な実施形態に従ってリンク層セキュリティをブートすることを描く図である。 本発明のいくつかの例示的な実施形態に従って、例示的なアクセスポイント及び例示的なクライアントデバイス又はユーザ局の典型的なサブコンポーネントを示すアーキテクチャ図である。

Claims (13)

1. 媒体非依存事前認証フレームワークにおいて第１のネットワークと第２のネットワーク間でのモバイルノードの切り替え復帰に関連するハンドオフ決定を制御する方法であって、
   ａ）隣接ネットワーク内のアクセスポイントに関して位置決定をするように構成される位置決定モジュールをモバイルノードに提供することと、
   ｂ）少なくとも前記位置決定モジュールの出力に基づいて、前記第１のネットワークと第２のネットワーク間の発振を回避するために、前記モバイルノードの事前ハンドオーバアクティビティに関して、少なくともモバイルノード位置とキャッシュ化データとの相関関係、モビリティパターン及び経路特定に部分的に基づいた位置をベースにしたアルゴリズムを使用することと、
   を有する、方法。
2. 前記事前ハンドオーバアクティビティは事前認証、事前構成、安全先行ハンドオーバの手順を含み、前記キャッシュ化データは少なくともアクセスポイントのＩＰアドレスを含む、請求項１に記載の方法。
3. 前記キャッシュ化データは、前記モバイルノード上のデジタルデータ記憶装置に記憶される、請求項２に記載の方法。
4. 前記位置ベースのアルゴリズムは、前記モバイルノードが前記第１のネットワークと前記第２のネットワークの他方に切り替わった過去事例に関連するデータに基づき前記第１のネットワークと前記第２のネットワークの前記他方への切換を規定することを含む、請求項２に記載の方法。
5. 前記位置ベースのアルゴリズムは、前記モバイルノードが前記第１のネットワークと前記第２のネットワークの他方に切り替わらなかった過去事例に関連するデータに基づき前記第１のネットワークと前記第２のネットワークの前記他方に切り替わらないことを規定することを含む、請求項２に記載の方法。
6. 前記位置決定モジュールはＧＰＳ受信機を含む、請求項１に記載の方法。
7. 前記少なくとも１つの非位置決めインジケータは信号対雑音比のインジケータを含む、請求項１に記載の方法。
8. 前記アルゴリズムは前記モバイルノード内でのプログラミングを介して実行される、請求項１に記載の方法。
9. 前記アルゴリズムは、前記モバイルノードにとって外部のプログラミングを介して少なくとも部分的に実行される、請求項１に記載の方法。
10. 前記モバイルノードと前記第２のネットワーク上の認証エージェントとの間にリンク層にとらわれないネットワークアクセス認証プロトコルを使用して事前認証を実行することをさらに含む、請求項１に記載の方法。
11. 複数の管理ドメイン全体で事前認証を実行することをさらに含む、請求項１に記載の方法。
12. 前記第１のネットワークは第１の媒体用であり、前記第２のネットワークは別の媒体用であり、前記第１の媒体がセルラーで、前記別の媒体が無線ＬＡＮであるか、または前記第１の媒体が無線ＬＡＮで、前記別の媒体がセルラーであるかのどちらかである、請求項１に記載の方法。
13. ネットワークアクセス認証プロトコルとしてＰＡＮＡをさらに利用する、請求項２に記載の方法。

Images