JP2011172224A - 異種モバイルネットワークに接続するモバイルノード、通信システムおよび方法 - Google Patents

Abstract

【課題】異種モバイルネットワークにおけるシームレスなドメイン間ハンドオーバをサポートするためのコンテキスト転送方法を提供する。
【解決手段】モバイルノードは、複数のアクセスネットワークの少なくとも１つのアクセスネットワークにおけるアクセスポイントから、アクセスポイントのアイデンティティについての情報を含んでいるブロードキャストメッセージを受信し、単位時間あたりに受信したアクセスポイントごとのブロードキャストメッセージの数についての情報を取得する手段と、アクセスポイントから受信した前記ブロードキャストメッセージの数が所定の第１のしきい値を超えている場合、モバイルノードが接続している第１のアクセスネットワークに位置する第１のネットワークエンティティに対して、第２のアクセスネットワークに位置する第２のネットワークエンティティとＱｏＳ状態に関する通信を行うことを要求する手段とを備える。
【選択図】図８

Description

本発明は、異種モバイルネットワークに接続するモバイルノード、通信システムおよび方法に関する。より詳細には、本発明は、異種ネットワークにおけるシームレスなドメイン間ハンドオーバをサポートするためのコンテキスト転送に関する。

第４世代移動通信ネットワークの主たる特性は、無線技術およびネットワーク技術の異種性である。第４世代ネットワークは、さまざまなネットワークで構成される統合システムとみなすことができ、ネットワークのそれぞれは、インターネットプロトコル（ＩＰ）を共通のベースとしてエンドユーザに１つのネットワークとして提示される。１つの課題は、そのような異種環境において、ＶｏＩＰ（Voice over Internet Protocol）電話などインタラクティブなアプリケーションをサポートするためにシームレスなモビリティを提供することである。

相互に接続されているいくつかのネットワークから成る、ＩＰベースの異種ネットワークアーキテクチャを想定し、ネットワークそれぞれは、異なるネットワーク技術（例：ＤｉｆｆＳｅｒｖ ＱｏＳ（Differentiated Services Quality of Service）、ＩｎｔＳｅｒｖ ＱｏＳ（Integrated Services Quality of Service）など）、異なるアクセスネットワーク技術（例：無線ローカルエリアネットワーク（ＷＬＡＮ）、あるいはＵＭＴＳ無線アクセスネットワーク（ＵＴＲＡＮ））を使用することができ、管理する事業者が異なることがある。このネットワークアーキテクチャではモビリティがサポートされ、すなわち、上位層（例：転送制御プロトコル（ＴＣＰ））における接続が切断されることなく、モバイルノード（ＭＮ）がネットワーク間で移動することができる。このプロセスは「ハンドオーバ」と呼ばれ、例えば、レイヤ３におけるモバイルＩＰによって提供することができる。しかしながら、この目的にどのメカニズムを使用するかは、本発明には影響しない。

ハンドオーバプロセスは、新しいネットワークにおける認証および許可、無線リンクおよびＩＰセッションの再配置（relocation）、ネットワークにおけるＱｏＳ状態の確立など、さまざまなタスクを含んでいる。シームレスなハンドオーバをサポートするためには、ハンドオーバのパフォーマンスを高めなくてはならず、すなわち、ハンドオーバの遅延を低減させなくてはならない。これを目的として、コンテキスト転送を適用することができる。「コンテキスト転送」とは、ハンドオーバ後にモバイルノードが新しいネットワークエンティティにおいて状態をはじめから確立し直さなくてもよいように、モバイルノードに関連するコンテキストまたは状態（例：ＱｏＳに関しては、ヘッダ圧縮、ＡＡＡなど）を、１つのネットワークエンティティ（例：アクセスルータ（ＡＲ））から別のエンティティに転送することを意味する用語である。

ＩＥＴＦ（Internet Engineering Task Force）における「ｓｅａｍｏｂｙ」ワーキンググループによって、ＩＰネットワークにおけるアクセスルータ間での許可方式のコンテキスト転送を可能にするための、コンテキスト転送プロトコル（ＣＴＰ）と呼ばれるレイヤ３プロトコルが開発された（非特許文献１）。このプロトコルは、プロアクティブ型（proactive）または予測型のコンテキスト転送（すなわちハンドオーバが実行される前に、現在のアクセスルータから次のアクセスルータにコンテキストを転送する）と、リアクティブ型のコンテキスト転送（すなわちハンドオーバが行われた後に、前のアクセスルータから現在のアクセスルータにコンテキストを転送する）とをサポートする。コンテキスト転送は、モバイルノード、前のアクセスルータ、または次のアクセスルータによってトリガすることができる。コンテキスト転送プロトコルでは、さまざまなメッセージ、すなわち、コンテキスト転送要求（ＣＴ−Ｒｅｑ）、コンテキスト転送データ（ＣＴＤ）、コンテキスト転送データ応答（ＣＴＤＲ）、コンテキスト転送起動要求（ＣＴＡＲ）、コンテキスト転送起動肯定応答（ＣＴＡＡ）、コンテキスト転送取消し（ＣＴＣ）が定義されている。これらのメッセージは、モバイルノード、前のアクセスルータ、次のアクセスルータの間で交換される。コンテキスト転送プロトコルでは、モバイルノードとＡＲ１とが、許可を目的として鍵を共有することを前提としている。

図１は、コンテキスト転送プロトコルを使用してのプロアクティブ型のコンテキスト転送の場合のシグナリングの流れを示している。ＡＲ１ １０２およびＡＲ２ １０３は、異なるネットワーク１０４および１０５に属している。ステップ１０６において、ＭＮ １０１は、ＡＲ２ １０３（ターゲットＡＲ／ｎＡＲまたは次のＡＲ／ｎＡＲとも称する）のＩＰアドレスを、例えばＣＡＲＤプロトコル（後述する）のサポートによって決定した後、ステップ１０７において、ＣＴＡＲメッセージをＡＲ１ １０２（ソースＡＲ／ｐＡＲまたは前のＡＲ／ｎＡＲとも称する）に送り、このメッセージは、ＡＲ２のＩＰアドレスと、モバイルノードのＩＰアドレスと、肯定応答と要求とを一致させるためのシーケンス番号（ＳＮ）と、許可トークンと、転送するコンテキストのタイプとを含んでいる。許可トークンは、モバイルノードが、ハッシュ関数と、ＡＲ１と共有する鍵とを使用して計算する。ＡＲ１は、このトークンの有効性を検証し、成功した場合、ステップ１０８において、このコンテキストデータと、共有している鍵とを、ＣＴＤメッセージを使用してＡＲ２に転送する。ＡＲ２は、ステップ１０９において、ＣＴＤＲメッセージによって、受信に対する肯定応答を返すことができる。ハンドオーバの後、ステップ１１０において、モバイルノードはＣＴＡＲメッセージをＡＲ２に送り、ＡＲ２は、許可トークンの有効性をもう一度検証し、検証に成功した場合、そのコンテキストを組み込む。なお、このＣＴＡＲメッセージは、前のＡＲのＩＰアドレスと、モバイルノードが前のＡＲにアタッチされた時点におけるモバイルノードのＩＰアドレスとを含んでいる。最後に、ステップ１１１において、ＡＲ２は、コンテキスト転送のステータスについて、ＣＴＡＡメッセージを送ることによってモバイルノードに知らせることができる。

図２は、リアクティブ型のコンテキスト転送の場合におけるシグナリングの流れを示している。この手順は上に似ているが、こちらの手順では、モバイルノード／ＵＥ １０１が、最初にステップ２０１において、ＣＴＡＲメッセージをＡＲ２ １０３に送る。その後、ＡＲ２は、ステップ２０２において、ＣＴＲメッセージを使用して、ＡＲ１からのコンテキストを要求する。ステップ２０３において、ＡＲ２は、コンテキストデータと、共有している鍵とを、ＡＲ１ １０２から受信する。ＡＲ２は、さきの手順と同様に、ステップ２０４において、ＣＴＡＡメッセージをモバイルノード／ＵＥ １０１に送ることができ、ステップ２０５において、ＡＲ１に送るＣＴＤＲメッセージによって、受信に対する肯定応答を返すことができる。

コンテキスト転送プロトコルは、アクセスルータからアクセスルータにのみコンテキストを転送するように設計されている。異種ネットワークあるいはその他のソースエンティティ／ターゲットエンティティは考慮されていない。ドメイン間ハンドオーバの場合には、コンテキスト転送プロトコルによって対処されていない追加の問題として、例えば、ソースネットワークとターゲットネットワークにおいてコンテキストの表現形式が異なることや、コンテキスト転送経路を安全にするため、場合によっては多数のドメイン間セキュリティアソシエーション（ＳＡ）が必要であること、あるいはこれらのＳＡの自動的な確立といった問題が生じる。従って、異種ネットワークにおいてコンテキストを転送する方法が必要とされている。

Ｓｅａｍｏｂｙワーキンググループでは、別のプロトコルとして、ＣＡＲＤ（Candidate Access Router Discovery）プロトコルを開発した（非特許文献２)。ＣＡＲＤの主たるタスクは次の２つである。
・ モバイルノードが、対応する候補アクセスポイントのレイヤ２アドレスを（例えばこれらのアクセスポイントからビーコンを受信することによって）取得したとき、候補ＡＲのレイヤ３識別子（ＩＰアドレス）を求める。
・ モバイルノードがターゲットＡＲを決定することを支援する目的で、それら候補ＡＲの能力を発見する。

ＣＡＲＤプロトコルを使用することで、コンテキスト転送プロトコルを使用しての予測型コンテキスト転送の場合に、ターゲットＡＲの決定をサポートすることができる。受信されるビーコンからモバイルノードによって発見されるレイヤ２識別子から、中央集中型手法または分散型手法を使用して、近隣のアクセスルータのレイヤ３識別子を求めることができる。中央集中型手法を使用する場合、ＣＡＲＤサーバが、レイヤ２識別子から逆アドレス解決を実行する。分散型手法を使用する場合、ハンドオーバ中にモバイルノードから受信される情報を使用して、分散型アドレス解決用キャッシュ（distributed address resolution cache）を確立する。現在のアクセスルータは、候補アクセスルータのレイヤ３識別子を発見した後、関連する能力に関する情報をこれらの候補アクセスルータから要求して、その情報をモバイルノードに提供することができる。

ＩＥＥＥ８０２．１１ｆ（非特許文献３)では、新しいアクセスポイントに関する再認証および再アソシエーション時のレイヤ２ハンドオーバ遅延を低減させる目的で、レイヤ２コンテキスト転送方式（主としてセキュリティ関連コンテキストを対象とする）を定義している。従って、古いアクセスポイント（ＡＰ）と新しいアクセスポイントは、リアクティブ型のコンテキスト転送の場合にはＩＡＰＰ−ＭＯＶＥパケットを交換し、プロアクティブ型のコンテキスト転送の場合にはＩＡＰＰ−ＣＡＣＨＥパケットを交換する。プロアクティブ型のコンテキスト転送の場合、アクセスポイントは、再アソシエーション要求フレームまたはＩＡＰＰ−ＭＯＶＥ要求フレームにおいて受信した情報に基づいて、いわゆる近隣グラフ（neighbour graph）を構築して維持する。近隣グラフは、コンテキスト転送のための候補ＡＰを決定する目的で使用される。

８０２．１１は、アクセスポイントからアクセスポイントにのみコンテキストを転送するように設計されている。異種ネットワークあるいはその他のソースエンティティ／ターゲットエンティティは考慮されていない。従って、異種ネットワークにおいてコンテキストを転送する方法が必要とされている。

コンテキスト転送を実行することの全体的な目的は、ハンドオーバ遅延を低減させてシームレスなモビリティをサポートすることである。従って、コンテキスト転送は、できる限り高速とすべきである。この目標を達成するため、コンテキスト転送は、可能であればプロアクティブ型の方式において行うべきであり、コンテキスト転送の経路はできる限り短くすべきである。ハンドオーバを十分前に予測できない場合に備えて、リアクティブ型のコンテキスト転送もサポートすべきである。さらに、悪意のあるノードに対する保護を提供するため、転送はセキュアでなければならず（パケットごとの認証、整合性保護、機密性）、これにより、コンテキスト転送のソースエンティティとターゲットエンティティとの間のＩＰｓｅｃセキュリティアソシエーション（ＳＡ）が要求される。ＳＡは、通常、情報転送における認証および暗号化を伴う。これらの特徴のすべては、ドメイン内ハンドオーバの場合にはコンテキスト転送プロトコルによって提供される。

しかしながら、第４世代ネットワークなどの異種環境におけるドメイン間ハンドオーバの場合、追加の要件として、種類の異なる複数のソースエンティティ／ターゲットエンティティ（例：ＡＡＡサーバおよびアクセスルータ）が関与しうることを考慮しなければならない。さらに、ソースネットワークおよびターゲットネットワークがそれぞれ異なる無線技術やネットワーク技術（例：ＤｉｆｆＳｅｒｖ技術、ＩｎｔＳｅｒｖ Ｑｏｓ技術）を使用することがあり、これにより、追加の手段（例：ターゲットネットワークが認識する表現形式にコンテキストを変換する）が要求されることがある。さらには、ドメイン間のＳＡを管理するための手順（例：鍵の交換および配布）が必要となり、場合によっては手動での介入が必要となりうる。従って、ドメイン間ＳＡの数を最小にすべきである。

さらに、コンテキスト転送に管理ノードを使用するこれまでの手法では、コンテキスト転送の最良の経路を必ずしも使用せず、最適なパフォーマンスが達成されないことがある。

特許文献１には、非アクティブコンテキストを（管理ドメインごとに１つの）中央データベースに格納し、アクティブコンテキストを、アクセスルータに配置されているローカルコンテキストディレクトリに格納するシステムが開示されている。アクセスルータ間でコンテキストを転送するためのプロトコルも提示している。いわゆるメモリ転送エージェントを使用して、アクティブ特性コンテキスト、すなわちアクティブまたは「進行中の」マイクロフロー（microflow）のコンテキストのみを、１つのアクセスルータから別のアクセスルータに転送する。中央エンティティは、主接触データベース（ＭＣＤ）と、他のドメインとのインタフェースとしての外部メモリゲートウェイ（ＭＧＥ）と、ローカルＡＲとのインタフェースとしてのローカルメモリゲートウェイ（ＭＧＬ）とを備えている。アクセスルータは、そのアクセスルータに関連付けられるすべてのモバイルノードのアクティブコンテキストのリストを維持するローカルコンテキストディレクトリ（ＬＣＤ）と、異なるアクセスルータのローカルコンテキストディレクトリ間でコンテキストを転送する役割を果たすメモリ転送エージェント（ＭＴＡ）と、ターゲットＡＲとの接触を確立するコンテキスト転送エージェント（ＣＴＡ）とを含んでいる。新しいマイクロフローがアクティブになったとき、ＭＣＤから、現在のアクセスルータのローカルコンテキストディレクトリにＭＧＬを介してコンテキストを転送する。コンテキスト転送はモバイルノードによってトリガされ、モバイルノードはＩＣＭＰメッセージを現在のアクセスルータに送る。このメッセージには、ターゲットＡＲおよびそのプリファレンスレベルのリストが含まれている。その後、現在のアクセスルータは、モバイルノードのアクティブコンテキストをターゲットＡＲに転送するように要求する。ターゲットＡＲも、ＭＣＤからの追加のコンテキストを要求することができる。異なる管理ドメイン間のハンドオーバがトリガされる場合、アクセスルータ間のコンテキスト転送を通常どおりに行う以外に、両ドメインのＭＣＤ間で非アクティブコンテキストを転送する。

特許文献１では、コンテキスト転送プロトコルと同様に、アクセスルータ間のコンテキスト転送のみがサポートされるが、これに加えて、非アクティブコンテキストを主データベースに格納する。このため、例えば候補アクセスルータ発見を実行するための複雑さがアクセスルータからネットワーク内のポリシーサーバに移る。ドメイン間転送の場合におけるコンテキスト転送経路は、つねに、ＡＲ１→ポリシーサーバ１→ＡＲ２→ポリシーサーバ２である。従って、ポリシーサーバのそれぞれは、隣接するネットワークのエッジアクセスルータすべてとの（ドメイン間）ＳＡを必要とし、このことはスケーラビリティの問題につながることがある。さらには、コンテキストの変換がサポートされていないため、ソースネットワークおよびターゲットネットワークにおいてコンテキストの表現形式が異なることにより、コンテキスト転送が不完全なものになる。

特許文献２には、異なる管理ドメインおよびアクセスネットワークのアクセスルータ間で、（ネットワークに固有なコンテキストではなく）アプリケーションに固有なコンテキストをプロアクティブ式に転送する別のシステムが説明されている。アプリケーションに固有なコンテキストは、あらかじめモバイルノードによって作成される。新しいアクセスルータは、アプリケーションのコンテキストを評価し、必要であれば、対象のアプリケーションをサポートするネットワークエンティティを自身のドメイン内で発見する。例えば、モバイルノードはＷＬＡＮアクセスネットワークを通じてビデオストリームを受信する。モバイルノードは、セルラーネットワークにハンドオフする前に、ビデオストリームに関する情報（ビットレート、フォーマットなど）を含んでいるアプリケーション固有コンテキストを構築し、それを現在のアクセスルータに送る。アクセスルータは、そのコンテキストをセルラーネットワークの次のアクセスルータに転送し、転送されたアクセスルータは、プロキシサーバへのピンポントンネル（ping-pong tunnel）を発見して確立することができ、ビデオストリームを、より低いビットレートのストリームにトランスコードすることができる。

この特許文献２は、アプリケーションに固有な機能要件（例：新しいアタッチポイントにおいてアプリケーションプロキシを提供する）を登録および転送することを扱っている。

特許文献３には、適切な候補アクセスルータの発見を処理するシステムが提示されている。このシステムは、ＩＰセッションの維持を助ける、ネットワークノードの第１の能力セットを、モバイルノードにおけるアプリケーション固有コンテキストに基づいて検出する方法と、次のネットワークノード候補から能力情報を問い合わせて、そのノードが要件を満たすことができるかを判定する方法とを含んでいる。問合せは、モバイルノードまたは現在のアクセスルータによって行うことができる。

この特許文献３は、対応する候補アクセスルータを発見するメカニズムに焦点を当てており、ドメイン間でコンテキストを転送する方法は提供していない。

特許文献４に提示されている方法では、管理ドメインごとの中央エンティティであるポリシーサーバを利用する。このサーバは、可能なターゲットＡＲを選択する役割を果たす。最初のステップにおいて、すべてのアクセスルータがそれぞれの能力をポリシーサーバに報告する。モバイルノードは、別のアクセスルータに関する情報を受信すると、識別情報（例：アクセスポイントのレイヤ２識別子）を現在のアクセスルータに送り、現在のアクセスルータは、その情報を現在のドメインのポリシーサーバに転送する。ドメイン間ハンドオーバの場合、モバイルノードの識別子およびモバイルノードに関するその他の情報を、ターゲットドメインのポリシーサーバに送る。このサーバは、そのモバイルノードの処理を担当できるかを判定する。処理できる場合、このサーバは、モバイルノードの能力と、アクセスルータにおけるトラフィック負荷と、事業者によって定義されている規則とを考慮するアルゴリズムに従って、与えられた完全なトポロジ情報に基づき、候補ＡＲのリストを計算する。コンテキスト転送自体は、プロアクティブ方式またはリアクティブ方式で実行することができる。リアクティブ方式の場合、モバイルノードは、要求メッセージを新しいアクセスルータに送ることによって、コンテキスト転送をトリガする。次いで、コンテキストを前のアクセスルータから対応するポリシーサーバに転送し、ポリシーサーバは、静的なコンテキストを追加したり、他のネットワークエンティティからの動的なコンテキストを集めることができ、コンテキストを現在のアクセスルータに送る。プロアクティブ方式の場合、要求メッセージを現在のアクセスルータに送り、コンテキストを、現在のアクセスルータから、対応するポリシーサーバを通じて次のアクセスルータに転送する。いずれの方式の場合も、ターゲットＡＲは、コンテキストを自身のポリシーサーバにさらに転送し、そのポリシーサーバは、そのコンテキストを別のネットワークエンティティ（例：セキュリティゲートウェイ）に転送することができる。

特許文献５に説明されているシステムでは、ネットワークのコア部分にいわゆるコア状態管理ノード（ＣＳＭＮ）が配置されており、このノードは、アクセスルータ間でのシグナリングが必要ないように、コンテキストの格納、操作、および転送を行う。ＣＳＭＮは、ＡＡＡサーバと同じ場所に配置することができ、状態データ自体を格納するか、あるいは別のネットワークエンティティ内に存在する場合にはその場所を格納することができる。プロアクティブ型のコンテキスト転送とリアクティブ型のコンテキスト転送の両方がサポートされる。モバイルノードは、モバイルノードおよびターゲットＡＲの識別子と、領域間のハンドオーバの場合には領域ＩＤとを含んでいるメッセージを現在のアクセスルータに送ることによって、コンテキスト転送をトリガする。１つのＣＳＭＮの領域内のハンドオーバの場合、前のアクセスルータが状態をＣＳＭＮに転送し、ＣＳＭＮがその状態を格納する。次いで、次のアクセスルータがＣＳＭＮから状態を取得する。ハンドオーバが２つの領域間で行われる場合、コンテキスト転送には２つのＣＳＭＮが関与する。リアクティブ方式の場合、コンテキストを前のアクセスルータから対応するＣＳＭＮに転送し、ＣＳＭＮがそのコンテキストを格納する。次のアクセスルータは、前の領域の識別子を含んでいるトリガメッセージをモバイルノードから受信した後、ハンドオーバの後に自身のＣＳＭＮから状態を要求することができ、後者のＣＳＭＮは、前の領域のＣＳＭＮから状態を取得する。プロアクティブ方式の場合には、現在のアクセスルータからそのＣＳＭＮにコンテキストを転送し、ＣＳＭＮがそのコンテキストを格納し、ターゲットＣＳＭＮに転送する。ハンドオーバの後、ターゲットＡＲは、自身のＣＳＭＮからコンテキストを取得することができる。このコンテキスト転送プロトコルのメッセージのフォーマットは定義されていない。

この特許文献５においても、コンテキストの異なる表現形式と、異なるソースエンティティ／ターゲットエンティティはサポートされない。さらに、新しいネットワークにおけるアクセスルータは、たとえプロアクティブ型のコンテキスト転送の場合であっても、ハンドオーバの後、最初にＣＳＭＮからコンテキストを取得する。さらには、ドメイン間ハンドオーバおよびドメイン内ハンドオーバのいずれの場合にも、コンテキストはＣＳＭＮを通じてルーティングされる。これらの問題のため、ハンドオーバにおける追加のレイテンシが生じる。また、コンテキスト転送を実行するためのプロトコルが定義されていない。ＩＥＴＦ標準化において現在検討されているプロトコルは、提案されているアーキテクチャをサポートしないため、使用することができない。

特許文献６には、外部のサーバ要素（例：事業者のネットワークの外側のアプリケーションサーバ）において候補ＡＲの発見を実行するシステムおよび方法が提案されている。このサーバには、モバイルノードの処理を現在担当しているアクセスルータと、そのモバイルノードの範囲内にあるアクセスルータとを識別する情報を提供する。次いで、サーバは、１つ以上のターゲットＡＲを決定する。選択アルゴリズムに必要な能力情報は、事業者によってあらかじめ提供することができ、あるいは、モバイルノードから、またはアクセスルータに問い合わせることによって、動的に取得することができる。後者の２つの手法の場合、アプリケーションサーバとすべてのアクセスルータとの間の適切なＳＡが必要であり、なぜなら、サーバが事業者のネットワークの外側に位置しうるためである。候補アクセスルータの動的な発見は、次のように行われる。ハンドオーバの後、モバイルノードが、現在および前のアクセスルータ／アクセスポイントのレイヤ２識別子およびレイヤ３識別子をアプリケーションサーバに送る。従って、サーバは、レイヤ２−レイヤ３アドレスマッピングテーブルを確立して維持することができ、どのアクセスルータ／アクセスポイントが隣接しているかを認識する。別のモバイルノードが、識別子を含んでいるレイヤ２ビーコンを隣接するアクセスポイントから受信すると、そのモバイルノードはこの情報をアプリケーションサーバに送り、アプリケーションサーバは、以前に確立したアドレスマッピングテーブルを使用して、対応するアクセスルータのレイヤ３識別子をこの情報から導くことができる。候補ＡＲのレイヤ３識別子を認識した後、それらの能力に関する情報を、アプリケーションサーバによって、またはモバイルノードによって要求することができる。最後に、モバイルノードまたはアプリケーションサーバのいずれかにおいて、ターゲットルータを選択することができる。さらには、モバイルノードのアプリケーション固有コンテキストをアプリケーションサーバに登録する方法が説明されており、アプリケーションサーバは、例えばセキュリティゲートウェイ、ロケーションサーバ、またはプロキシの再配置を処理することができる。ドメイン間ハンドオーバの場合、古いドメインにおけるアプリケーションサーバは、新しいドメインにおける各ネットワークエンティティ（例：ロケーションサーバ）を発見する。

この特許文献６は、候補のアクセスルータの発見を扱っているのみである。この特許は、コンテキスト転送自体の解決策を提供していない。

いずれの提案も、現在ＩＥＴＦによって標準化されているコンテキスト転送プロトコルを使用しておらず、いずれの提案でも、ＳＡの効果的な自動確立／取消は行われない。

国際公開第０３／０５２９６２号パンフレット 国際公開第０３／０９１９００号パンフレット 国際公開第０２／０９２３１４号パンフレット 国際公開第０３／０４９３７７号パンフレット 国際公開第２００４／０７０９８９号パンフレット 国際公開第０３／０９２３１５号パンフレット

J. Loughney, M. Nakhjiri, C. Perkins、R. Koodli, "Context Transfer Protocol", IETF Internet Draft draft-ietf-seamoby-ctp-11.txt, August 2004 M. Liebsch, A. Singh, H. Chaskar, D. Funato, E. Shim, "Candidate Access Router Discovery", IETF Internet Draft draft-ietf-seamoby-card-protocol-08.txt, September 2004 "Trial-Use Recommended Practice for Multi-Vendor Access Point Interoperability via an Inter-Access Point Protocol Across Distribution Systems Supporting IEEE 802.11 Operation", IEEE Computer Society, IEEE Std 802.11F-2003, July 2003

本発明の目的は、異種ネットワークにおけるコンテキスト転送の方法および装置であって、異なる技術を使用しているアクセスネットワーク間でのコンテキスト転送をサポートし、必要なドメイン間セキュリティアソシエーションの数を最小にする方法および装置、を提供することである。

この目的は、他のドメインとの単一のインタフェースを提供するコンテキスト転送マネージャ（ＣＴＭ）をドメインごとに少なくとも１つ使用することによって、達成することができる。このコンテキスト転送マネージャは、コンテキストの変換、すなわち、ターゲットアクセスネットワークによって要求されるフォーマットおよび表現形式にコンテキスト情報を変換するようにされている。

本発明の１つの側面においては、複数のアクセスネットワークを備えている異種モバイルネットワークに接続するモバイルノードは、前記複数のアクセスネットワークの少なくとも１つのアクセスネットワークにおけるアクセスポイントから、前記アクセスポイントのアイデンティティについての情報を含んでいるブロードキャストメッセージを受信し、単位時間あたりに受信した前記アクセスポイントごとの前記ブロードキャストメッセージの数についての情報を取得する手段と、前記アクセスポイントから受信した前記ブロードキャストメッセージの数が所定の第１のしきい値を超えている場合、前記モバイルノードが接続している第１のアクセスネットワークに位置する第１のネットワークエンティティに対して、第２のアクセスネットワークに位置する第２のネットワークエンティティとＱｏＳ状態に関する通信を行うことを要求する手段と、を備えている。

本発明の別の側面においては、前記モバイルノードと、前記モバイルノードが接続している第１のアクセスネットワークに位置する第１のネットワークエンティティとを具備する通信システムは、
前記第１のネットワークエンティティは、前記モバイルノードに関連するコンテキスト情報を前記第１のアクセスネットワーク内の少なくとも一つのソースエンティティから収集し、前記収集したコンテキスト情報を第２のアクセスネットワークに位置する第２のネットワークエンティティに転送する。

本発明の別の側面においては、複数のアクセスネットワークを備えている異種モバイルネットワークに接続するための方法は、前記複数のアクセスネットワークの少なくとも１つのアクセスネットワークにおけるアクセスポイントから、前記アクセスポイントのアイデンティティについての情報を含んでいるブロードキャストメッセージを受信し、単位時間あたりに受信した前記アクセスポイントごとの前記ブロードキャストメッセージの数についての情報を取得するステップと、前記アクセスポイントから受信した前記ブロードキャストメッセージの数が所定の第１のしきい値を超えている場合、前記モバイルノードが接続している第１のアクセスネットワークに位置する第１のネットワークエンティティに対して、第２のアクセスネットワークに位置する第２のネットワークエンティティとＱｏＳ状態に関する通信を行うことを要求するステップと、を備えている。

本発明の別の側面においては、複数のアクセスネットワークを備えている異種モバイルネットワークのコンテキスト転送マネージャにおいて実行されるコンテキスト転送の方法は、ａ）モバイルノードに関連するコンテキスト情報を、第１のアクセスネットワークにおける少なくとも１つのソースエンティティから集めるステップと、ｂ）前記集めたコンテキスト情報を、第２のアクセスネットワークにおけるコンテキスト転送マネージャに送信するステップと、ｃ）モバイルノードに関連するコンテキスト情報を、前記第１のアクセスネットワークとは異なるアクセスネットワークにおけるコンテキスト転送マネージャから受信するステップと、ｄ）ステップｃ）において受信した前記コンテキスト情報を、前記第１のネットワークにおける少なくとも１つのターゲットエンティティに転送するステップと、ｅ）ステップｂ）の前、もしくはステップｃ）の後、またはその両方において、前記コンテキスト情報の少なくとも一部を、一方のアクセスネットワークにおいてサポートされているフォーマットから、他方のアクセスネットワークにおいてサポートされている別のフォーマットに変換するステップと、を含んでいる。

本発明の別の側面においては、コンピュータ可読ストレージメディアが命令を格納しており、異種モバイルネットワークにおける無線アクセスネットワークのコンテキストマネージャにおいてこの命令が実行されることにより、前記コンテキストマネージャが、第１の側面による方法を実行する。

本発明のさらに別の側面においては、異種モバイルネットワークにおけるアクセスネットワークのコンテキストマネージャは、モバイルノードに関連するコンテキスト情報を、第１のアクセスネットワークにおける少なくとも１つのソースエンティティから集める手段と、前記集めたコンテキスト情報を、第２のアクセスネットワークにおけるコンテキスト転送マネージャに送信する手段と、モバイルノードに関連するコンテキスト情報を、前記第１のアクセスネットワークとは異なるアクセスネットワークにおけるコンテキスト転送マネージャから受信する手段と、前記第１のアクセスネットワークとは異なる前記アクセスネットワークにおける前記コンテキスト転送マネージャから受信した前記コンテキスト情報を、前記第１のネットワークにおける少なくとも１つのターゲットエンティティに転送する手段と、前記コンテキスト情報の少なくとも一部を、一方のアクセスネットワークにおいてサポートされているフォーマットから、他方のアクセスネットワークにおいてサポートされている別のフォーマットに変換する手段と、を備えている。

本発明のさらに別の側面においては、複数のアクセスネットワークを備えている異種モバイルネットワークにおいて実行される方法であって、前記モバイルネットワークの２つの異なるアクセスネットワークに配置されている少なくとも２つのコンテキストマネージャにおいて実行される、第１の側面による方法のステップ群を含んでおり、さらに、ｆ）モバイルノードから、前記第１のアクセスネットワークの第１のアクセスルータにメッセージを送るステップであって、前記メッセージが、前記モバイルノードのアイデンティティに関する情報と、第２のアクセスルータのアイデンティティに関する情報と、転送するコンテキストのタイプに関する情報とを含んでいる、前記ステップと、ｇ）前記コンテキスト転送マネージャによってステップａ）およびステップｂ）が実行される前、かつ、前記第２のアクセスルータが属している他方のアクセスネットワークの前記コンテキスト転送マネージャにおいてステップｃ）およびステップｄ）が実行される前に、前記第１のネットワークにおける前記アクセスルータから前記コンテキスト転送マネージャに前記メッセージを転送するステップと、を含んでいる。

本発明のさらに別の側面においては、複数のアクセスネットワークを備えている異種モバイルネットワークにおいて実行される方法は、前記モバイルネットワークの２つの異なるアクセスネットワークに配置されている少なくとも２つのコンテキストマネージャにおいて実行される、第１の側面による方法のステップ群を含んでおり、さらに、モバイルノードから、前記第２のアクセスネットワークのアクセスルータにメッセージを送るステップであって、前記メッセージが、前記モバイルノードのアイデンティティに関する情報と、前記第１のアクセスネットワークにおけるアクセスルータのアイデンティティに関する情報と、転送するコンテキストのタイプに関する情報とを含んでいる、前記ステップと、前記第２のネットワークにおける前記アクセスルータから前記コンテキスト転送マネージャに前記メッセージを転送するステップと、前記モバイルノードの前記アイデンティティに関する情報と、転送するコンテキストのタイプに関する情報とを含んでいるメッセージを、前記第２のアクセスネットワークにおける前記コンテキスト転送マネージャから、前記第１のアクセスネットワークにおける前記コンテキストマネージャに送るステップであって、これに起因して、ステップａ）およびステップｂ）が前記第１のアクセスネットワークの前記コンテキスト転送マネージャによって実行され、ステップｃ）およびステップｄ）が、前記第２のアクセスネットワークの前記コンテキスト転送マネージャにおいて実行される、前記ステップと、を含んでいる。

本発明のさらに別の側面においては、異種モバイルネットワークは、少なくとも１つのモバイルノード（１０１）と、少なくとも２つのアクセスネットワーク（１０４，１０５）とを備えており、前記少なくとも２つのアクセスネットワークのそれぞれが、請求項１０による少なくとも１つのコンテキスト転送マネージャ（３０２，３０３）と、少なくとも１つのアクセスルータ（１０２，１０３）とを備えている。

専用の管理ノード（コンテキスト転送マネージャ：ＣＴＭ）を使用することは、多くの利点を有する。これらのノードは、コンテキスト転送を管理することができ、２つのドメイン／アクセスネットワーク間の単一のインタフェースを提供する。ドメイン間ハンドオーバの場合、これらのノードを通じてコンテキストをルーティングするならば、２つのドメイン間でコンテキストを転送するのに必要なドメイン間ＳＡは１つのみである。さらに、コンテキスト転送マネージャは、さらなるアクション、例えば、両方のドメインにおける表現形式が異なる場合にコンテキストを変換する、あるいは、追加のシグナリング（例：コンテキスト情報が属しているモバイルホストに関連するパケット送信のためのネットワークリソースを予約する、データトンネルを前もって確立する、あるいはエンドツーエンドＱｏＳ経路を前もって確立するためのシグナリング）をトリガするといったアクションを実行することができる。これにより、アクセスルータの負荷がいくつかが軽減され、ネットワークの管理が容易になり、事業者が自身のネットワークに関する情報を他の事業者に隠すうえで役立つ。

要約すれば、本発明の恩恵は以下のとおりである。
・ 異種ネットワークにおけるドメイン間のコンテキスト転送（コンテキストの変換と、複数のソースエンティティ／ターゲットエンティティを含む）をサポートする。
・ ドメイン間ＳＡの数が最小になる。
・ ＩＥＴＦによる現在の標準プロトコルであるコンテキスト転送プロトコルを使用する。
・ ハンドオーバのタイプ（ドメイン間／ドメイン内）に応じて、最適なコンテキスト転送経路を選択して使用する。
・ コンテキスト転送マネージャ間のＳＡを早期に確立する、早期に取り消す。

コンテキスト転送プロトコルを使用するプロアクティブ型のコンテキスト転送の場合のシグナリングの流れを示している。 コンテキスト転送プロトコルを使用するリアクティブ型のコンテキスト転送の場合のシグナリングの流れを示している。 アクセスルータ間での直接的なコンテキスト転送と、コンテキスト転送マネージャを通じてのコンテキスト転送を示している。 コンテキスト転送プロトコルおよびコンテキスト転送マネージャを使用するプロアクティブ型のドメイン間コンテキスト転送の場合のシグナリングの流れを示している。 コンテキスト転送プロトコルおよびコンテキスト転送マネージャを使用するリアクティブ型のドメイン間コンテキスト転送の場合のシグナリングの流れを示している。 プロアクティブ型のコンテキスト転送の場合の前のＡＲにおける手順のフローチャートを示している。 ＳＡを早期に確立および取り消すためのシグナリングの流れおよびビーコンカウント状態を示している。 コンテキスト転送マネージャ間のセキュリティアソシエーションを早期に確立および早期に取り消す方法のステップを含んだフローチャートを示している。 コンテキスト転送マネージャとして使用できるサーバの基本的な構造を示している。

添付の図面は、本発明の原理を説明することを目的として、本明細書に組み込まれており、本明細書の一部を形成している。これらの図面は、本発明を構築および使用する方法を図解および説明した例に、本発明を制限するものではないことを理解されたい。さらなる特徴および利点は、添付の図面に図解されている本発明の以下のさらに具体的な説明から明らかになるであろう。

以下では、本発明の例示的な実施形態について図面を参照しながら説明する。図面において、同一・相当の要素および構造は同一・相当の参照数字によって示してある。

以下では、一般性を失うことなく、コンテキスト転送プロトコルの例の場合について本発明を説明する。しかしながら、本発明は、例えば「モバイルＩＰｖ６の高速ハンドオーバ（Fast handovers for Mobile IPv6）」（Rajeev Koodliの「Fast Handovers for Mobile IPv6」（IETF Internet Draft draft-ietf-mipshop-fast-mipv6-03.txt, October 2004））など、アクセスルータからアクセスルータにコンテキストを伝え、かつ両方のアクセスルータ間のＳＡを必要とする任意のプロトコルに適用することができる。

上述したように、コンテキスト転送マネージャ（ＣＴＭ）アーキテクチャは、異種ネットワークにおいてドメイン間でコンテキストを転送する場合、特に、異なるアクセスルータ間で別のドメインへのハンドオーバが可能である場合に有利である。コンテキスト転送マネージャは、別のドメインとの単一のインタフェースを提供し、従って、ドメイン間ＳＡの数が最小になり、コンテキストの変換、（ＡＡＡサーバなど、さまざまなエンティティからの）コンテキストの収集、および集合化（aggregation）を処理することができる。

図３は、アクセスルータ間での直接的なコンテキスト転送と、コンテキスト転送マネージャを通じてのコンテキスト転送とを示している。アクセスネットワークＡＮ１ １０４は、ＡＲ１ １０２と、別のＡＲ ３０１とを備えている。ＡＮ２ １０５は、ＡＲ２ １０３と、さらなるＡＲ ３０１とを備えている。モバイルノード１０１は、ネットワークのそれぞれと通信することができる。いま、ＭＮ １０１は、ＡＲ１を通じてＡＮ１と通信している間に移動し、ＡＮ２のサービスエリアに入り、ＡＮ１のサービスエリアから出ようとしている。ハンドオーバが必要であり、ハンドオーバの間に、実行中のアプリケーションのコンテキストをＡＲ１からＡＲ２に転送しなければならない。

図３ａにおいては、コンテキストはＡＲ１からＡＲ２に直接的に転送される。ドメインＡＮ１およびＡＮ２の境界を超えてのアクセスルータ間のＳＡが要求される。それと同時に、さらなるモバイルノードのサービスに関連する、別のＡＲ ３０１同士の間のそのようなＳＡがさらに存在しうる。図３ｂにおいては、ドメインあたり１つのコンテキスト転送マネージャＣＴＭ ３０２，３０３が、このコンテキスト転送を処理する。従って、進行中のコンテキスト転送のすべてのインスタンスに対して、ＡＮ １０４とＡＮ １０５との間に必要なＳＡは１つのみである。

しかしながら、コンテキスト転送プロトコルでは、コンテキスト転送マネージャの使用がサポートされない。この場合、専用のコンテキスト転送管理（ＣＴＭ）エンティティを通じてコンテキスト（コンテキスト転送プロトコルの場合にはＣＴＤメッセージ）をルーティングするという課題は、ＩＰ層ルーティングを使用することによって解決することができる。この手法の欠点は、下層のルーティングインフラストラクチャが影響されることと、コンテキストの集合化が不可能であることである。さらには、この場合、コンテキスト転送マネージャが処理中のコンテキストを操作できるようにするため、ルータ警告オプションが必要となる。従って、アプリケーション層ルーティングを使用する。ソースＡＲ １０２は、ＣＴＡＲメッセージをソースＣＴＭ ３０２に転送し、ソースＣＴＭ ３０２が、ソースＡＲおよびさまざまなソースエンティティ（例：ＡＡＡ１（認証、許可、アカウンティングエンティティ１）３０４）からのコンテキストを要求する。コンテキストを操作した後、ＣＴＭ ３０２は、コンテキストを集合化ＣＴＤメッセージにおいて、アプリケーション層においてターゲットＣＴＭ ３０３に転送し、それによりターゲットＣＴＭ ３０３がそのコンテキストを操作することができる。最後に、ターゲットＣＴＭ ３０３は、コンテキストを各ターゲットエンティティ（例：ＡＡＡ２ ３０５、ＡＲ２ １０３）に転送する。ソースＣＴＭ ３０２は、受信したＣＴＡＲメッセージからターゲットＡＲのＩＰアドレスを認識する。ターゲットＣＴＭがコンテキストをターゲットＡＲに転送することができるように、ソースＣＴＭは、ターゲットＡＲのＩＰアドレスをターゲットＣＴＭ ３０３に提供することが要求される。このことは、ターゲットＡＲのＩＰアドレスを含んでいる新しいフィールドをＣＴＤメッセージに追加することによって達成される。

図４は、コンテキスト転送プロトコルおよびコンテキスト転送マネージャを使用してのプロアクティブ型のドメイン間コンテキスト転送の場合のシグナリングの流れを示している。ステップ４００において、ＣＴＭ１ ３０２およびＣＴＭ２ ３０３は、それぞれの能力についてと、それぞれのアクセスネットワークＡＮ１ １０４およびＡＮ２ １０５の能力についての情報を交換する。これらの情報には、サポートされるコンテキストフォーマットについての情報を含めることができる。

図１とは異なり、ＡＲ１ １０２は、ステップ４０３において受信したＣＴＡＲメッセージを、ステップ４０４において、ＣＴＭ１ ３０２に転送する。ＣＴＭ１ ３０２は、ステップ４０５において、すべてのソースエンティティ１０２，４０１からコンテキストを集め、ステップ４０５において、ＣＴＤメッセージをＣＴＭ２ ３０３に転送する。このとき、ＣＴＤメッセージは、追加のフィールドとして、ターゲットＡＲ １０３のＩＰアドレスを含んでいる。さらに、ＡＮ１およびＡＮ２が、それぞれの無線インタフェースに異なる技術を採用している、あるいはコアネットワークまたはアグリゲーションネットワーク（aggregation network）におけるパケット転送に異なる技術を採用している場合、ステップ４１２において、コンテキストの少なくとも一部を、ＡＮ１においてサポートされているフォーマットから、ＡＮ２においてサポートされている別のフォーマットに変換する。この変換は、ＣＴＤメッセージを送る前にＣＴＭ１において行う、または、ＣＴＤメッセージを受信した後にＣＴＭ２において行うことができる。ＣＴＭ２は、ステップ４０７において、コンテキストのタイプに基づいて自身が決定する対応するターゲットエンティティ１０３，４０２に、コンテキストを転送する。ステップ４０８において、ＣＴＭ２ ３０３は、ＣＴＤＲメッセージをＣＴＭ１ ３０２に送ることによって、ＣＴＤメッセージの受信に対して肯定応答を返すことができる。ハンドオーバの後、ステップ４０９において、モバイルノードはＣＴＡＲメッセージをＡＲ２に送る。ＡＲ２は、ステップ４１０において、そのメッセージをＣＴＭ２に転送し、ＣＴＭ２は、許可トークンの有効性をもう一度検証し、検証が成功した場合に、そのコンテキストを組み込むようにターゲットエンティティに知らせる。あるいは、ＣＴＭ２は、トークンの有効性を検証が成功したときにのみ、コンテキストをターゲットエンティティに送ることができる。この場合、ターゲットエンティティはコンテキストをただちに組み込むことができる。なお、このＣＴＡＲメッセージには、前のＡＲのＩＰアドレスと、モバイルノードが前のＡＲにアタッチされていた時点におけるモバイルノードのＩＰアドレスとが含まれる。最後に、ステップ４１１において、ＡＲ２は、コンテキスト転送のステータスについて、ＣＴＡＡメッセージを送ることによってモバイルノードに知らせることができる。

図５は、リアクティブ型のコンテキスト転送の場合の対応するシグナリングの流れを示している。この場合、ステップ５０１において、ＭＮ １０１からＣＴＡＲメッセージをＡＲ２ １０３に送り、ステップ５０２において、ＡＲ２ １０３は、そのメッセージをＣＴＭ２ ３０３に転送する。ステップ５０３において、ＣＴＭ２ ３０３は、ＣＴＭ１ ３０２からのコンテキスト転送をＣＴ−Ｒｅｑメッセージによって要求し、このＣＴ−Ｒｅｑメッセージは、ＭＮ １０１の前の（ＡＮ１に登録されている間の）ＩＰアドレスと、肯定応答と要求とを一致させるためのシーケンス番号（ＳＮ）と、許可トークンと、転送するコンテキストのタイプとを指定している。ステップ５０４において、ＣＴＭ１ ３０２は、すべてのソースエンティティ１０２，４０１からコンテキストを集め、ステップ５０５において、ＣＴＤメッセージをＣＴＭ２ ３０３に転送する。この場合には、ターゲットＡＲのＩＰアドレスの追加のフィールドはＣＴＤメッセージに必要なく、なぜなら、ターゲットＣＴＭはモバイルノードからＣＴＡＲメッセージを受信し、このメッセージにターゲットＡＲのＩＰアドレスが含まれているためである。ステップ５０６において、ＣＴＭ２は、コンテキストのタイプに基づいて自身が決定する対応するターゲットエンティティ１０３，４０２に、コンテキストを転送する。プロアクティブ型のステップと同様に、ステップ５０７において、ＣＴＭ２ ３０３は、ＣＴＤＲメッセージをＣＴＭ１ ３０２に送ることによって、ＣＴＤメッセージの受信に対する肯定応答を返すことができ、ステップ５０８において、コンテキスト転送のステータスについて、ＣＴＡＡメッセージを送ることによってＭＮ １０１に知らせることができる。

プロアクティブ型のコンテキスト転送の場合と同様に、ＣＴＤメッセージによってコンテキストを送る前にＣＴＭ１において、あるいは、ＣＴＤメッセージを受信した後にＣＴＭ２において、ステップ４１２において、コンテキストの少なくとも一部を、要求される別のフォーマットに変換することができる。

ここまで説明したプロセスでは、コンテキストを必ずＣＴＭを通じてルーティングする。このことは、ドメイン間ハンドオーバの場合に望ましいが、ドメイン内ハンドオーバの場合には必要なく、コンテキスト転送経路が長くなるため、結果としてパフォーマンスが低下する。これを防ぐため、ハンドオーバのタイプに応じてコンテキスト転送経路を選択する。

ドメイン内ハンドオーバとドメイン間ハンドオーバとを個別に扱うことによって、ハンドオーバのパフォーマンスが向上する。ドメイン間ハンドオーバの場合には、ドメイン間ＳＡの数を最小にし、コンテキストの変換などを可能にするため、コンテキスト転送マネージャを通じた経路を使用すべきである。ドメイン内ハンドオーバの場合には、代わりに、アクセスルータからアクセスルータへのコンテキスト転送経路を使用すべきであり、なぜなら、コンテキスト転送マネージャは必要なく、アクセスルータ間の直接的な経路の方が短いためである。どちらのタイプ（ドメイン内またはドメイン間）のハンドオーバが存在しているかを、ソースＡＲおよびソースＣＴＭが協働して判定する。ソースＡＲは、ターゲットＡＲへのＳＡが存在する場合、コンテキスト自体を転送することができる。ターゲットＡＲへのＳＡが存在しない場合、ソースＡＲは、ＣＴＡＲメッセージをソースＣＴＭに転送し、ソースＣＴＭは、ターゲットＡＲのＩＰアドレスが自身のドメインに含まれているかを単独で判定する。従って、コンテキスト転送マネージャが自身のドメインのすべてのアクセスルータのＩＰアドレスまたはアドレス空間を認識していることを前提とする。コンテキスト転送マネージャは、ターゲットＡＲが自身と同じドメイン内でない場合、ドメイン間ハンドオーバが存在するものと結論し、コンテキスト自体を転送する。ターゲットＡＲが同じドメイン内である場合、ドメイン内ハンドオーバであると想定する。この場合、コンテキスト転送マネージャは、ＣＴＡＲメッセージをソースＡＲに戻すことができ、ソースＡＲは、ターゲットＡＲへのＳＡを確立してコンテキストを転送することができる。提案するこの解決策では、コンテキスト転送プロトコルのメッセージフォーマットを修正する必要はないが、アクセスルータの状態マシンを修正する必要がある。

図６は、プロアクティブ型のコンテキスト転送の場合に前のＡＲにおいて行われる上記手順のフローチャートを示している。アクセスルータは、ステップ６０１においてＣＴＡＲメッセージを受信した後、ステップ６０２において、許可トークンの有効性を検証する。検証が失敗する場合、ステップ６０３において、アクセスルータは、エラーコードを含んでいるＣＴＡＡメッセージを送ることによってモバイルノードに知らせる。検証が成功する場合、ステップ６０４において、前のＡＲは、ターゲットＡＲへのＳＡが存在しているかを調べる。存在している場合（ケース１）、ドメイン内ハンドオーバであると想定し、ステップ６０５において、前のＡＲは、ＣＴＤメッセージを使用してコンテキストを転送することができる。ターゲットＡＲがＣＴＤＲメッセージ（オプション）によって受信に対する肯定応答を返すまで、ステップ６０５およびステップ６０６において転送を繰り返す。ここまで説明したプロセスは、修正されていないコンテキスト転送プロトコルのプロセスとまったく同じである。

ステップ６０４において、次のＡＲへのＳＡが存在しないことが検出される場合、通常ではコンテキスト転送を取り消す。本発明において提案する修正形態では、ステップ６０７において、前のＡＲが、ＣＴＡＲメッセージがモバイルノードから受信されたかコンテキスト転送マネージャから受信されたかを調べる。これは、例えば、ＣＴＡＲメッセージ内のＩＰソースアドレスまたは新しいフラグに基づいて判定することができる。ＣＴＡＲメッセージがコンテキスト転送マネージャから受信されていた場合、ドメイン内コンテキスト転送が必要であると想定し、この目的のため、ステップ６０９において、ソースｐＡＲからターゲットｎＡＲへのＳＡを確立する。

ＣＴＡＲメッセージがモバイルノードから受信されていた場合（ケース２）、前のＡＲは、ドメイン間ハンドオーバを想定し、ステップ６０８において、自身のコンテキスト転送マネージャにＣＴＡＲメッセージを転送する。コンテキスト転送マネージャは、自身のドメイン内のすべてのアクセスルータのＩＰアドレスまたはアドレス空間を認識しており、従って、ドメイン内ハンドオーバが存在するのかドメイン間ハンドオーバが存在するのかを判定することができる。後者の場合、コンテキスト転送マネージャは、コンテキスト転送自体を実行する。すなわち、コンテキスト転送マネージャは、ＣＴ−ｒｅｑメッセージを使用して前のＡＲおよびその他のエンティティからコンテキストを集め、集合化ＣＴＤメッセージをターゲットＣＴＭに送る。このＣＴＤメッセージには、ターゲットＡＲのＩＰアドレスの新しいフィールドが含まれている（図４のステップ４０６を参照）。このとき、ターゲットＣＴＭのアドレスは、例えば、ターゲットＡＲのＩＰアドレスから導くことによって、ソースＣＴＭに既知であるものと想定する。さらには、両方のコンテキスト転送マネージャ間にＳＡが存在するものと想定する（ＳＡを自動的に確立する方法については後述する）。ターゲットＣＴＭは、ＣＴＤメッセージを受信すると、ＣＴＤメッセージを使用して、個々のコンテキストを対応するターゲットエンティティに転送する。このとき、特定のタイプのコンテキストに対応するターゲットエンティティのＩＰアドレス（例：ＡＡＡコンテキストに対応するＡＡＡサーバのＩＰアドレス）は、例えば事前に設定することによって、あるいは例えばデータベースへの追加のシグナリングによって、ターゲットＣＴＭに既知であるものと想定する。

コンテキスト転送マネージャは、ドメイン内ハンドオーバが存在すると判定した場合、ＣＴＡＲメッセージを前のＡＲに戻すことができ、前のＡＲは、修正されていないコンテキスト転送プロトコルの場合のように、次のＡＲへのＳＡを確立し（ステップ６０９）、コンテキストを転送する（ステップ６０５）（ケース３）。以上に説明した解決策は、リアクティブ型の場合にも同様に適用することができる。

本発明は、コンテキスト転送マネージャの階層にも同様に適用することができる。ネットワークがマルチホーム化されている場合、特定の状況では、ソースネットワークとターゲットネットワークとの間の直接的な経路以外の経路（例えば、ソースネットワークとターゲットネットワークの両方が、低帯域幅で相互接続されている外部ネットワークである場合、ホームネットワークを通じての経路）の方が、トポロジ的に短いことがあり、あるいは容量（capacity）が大きいことがある。この場合、ソースネットワークのコンテキスト転送マネージャがコンテキストをホームネットワークを通じてターゲットＣＴＭにルーティングするならば、パフォーマンスが高まる。最適なパフォーマンスのため、ソースＣＴＭは、明示的なプローブメッセージを送ることによって、または該当するコンテキスト転送のメッセージを受動的に使用することによって、代替経路のコンテキスト転送の時間長を測定することができる。この情報を使用することにより、次のコンテキスト転送にとっての最良の経路を選択することができる。以下では、コンテキスト転送マネージャ間のＳＡを早期に確立する、および早期に取り消すメカニズムを提案する。レイヤ２識別子を含んでいるブロードキャストメッセージの受信数に基づいて、候補のコンテキスト転送マネージャを決定する。以下では、これらのメッセージを「ビーコン」と称する。基本的な考え方として、隣接するドメインのアクセスポイントからモバイルノードが受信するレイヤ２ビーコン中の情報を使用して、コンテキスト転送マネージャ間のＳＡの早期確立および早期取消しをトリガする。モバイルノードは、これらのビーコン自体をカウントするか、あるいは、ネットワークに定期的にメッセージを送り、ネットワークがモバイルノードの代わりにビーコンをカウントする。カウントは単位時間あたりとして行う、すなわち、カウントは本質的には割合であり、ビーコンが受信されなくなると低減する。ビーコンカウントの状態を、アクセスポイントのＭＡＣアドレスごとに維持する。モバイルノードの信号強度により、ハンドオーバが差し迫っていることが示され、しきい値Ａを超えた場合、対応するアクセスポイントに対してＣＡＲＤプロトコルを開始する。さらには、ＣＡＲＤ応答メッセージによって、対応するコンテキスト転送マネージャ間のＳＡの確立をトリガする。第２のしきい値Ｂを超えた場合、ソースＣＴＭは、ビーコンカウントがしきい値Ｂを超えたアクセスポイントに対応するＳＡを除き、すべてのＳＡを取り消す。取り消せるのは使用されていないＳＡのみであるため、コンテキスト転送マネージャは、特定のコンテキスト転送の進行に関する何らかの状態情報を維持する必要がある。提案するしきい値の比較を使用することにより、最も可能性の高いＳＡが残り、リソースが無駄にならない。さらには、ＳＡを確立することによる追加のハンドオーバレイテンシなしに、コンテキスト転送をただちに開始することができる。

図７は、このプロセスを示している。ステップ７０４において、ＭＮ １０１を、アクセスネットワーク１（ＡＮ１）１０４におけるＡＰ１ １０２に関連付ける。ステップ７０５において、ＭＮ １０１は、ＡＮ２ １０５におけるＡＰ２ １０３からと、ＡＮ３ ７０３におけるＡＰ３ ７０２から、ビーコンを受信する。カウントステップ７０６において、両方のアクセスポイントのビーコンカウントがしきい値Ａを超えたため、ステップ７０７において、ＣＴＭ１とＣＴＭ２との間と、ＣＴＭ１とＣＴＭ３との間とにＳＡを確立する。カウントステップ７０８において、ＡＰ２のビーコンカウントがしきい値Ｂを超えた後、ステップ７０９において、ＡＮ３へのＳＡを取り消す。その後、ステップ７１０においてＡＮ２へのコンテキスト転送を実行するとき、ＳＡはすでに存在しており、ステップ７１１において実際のハンドオーバを行うとき、ＡＮ２における各ネットワークエンティティにコンテキストがすでに組み込まれている。

なお、現在のＩＥＥＥ ８０２．１１仕様では、ＳＴＡが関連付けられている以外のアクセスポイントが異なるチャネル／周波数においてビーコンを送信する場合、これらのビーコンを受信することができない。しかしながら、それ以外の無線技術、あるいはＩＥＥＥ ８０２．１１の将来的な仕様では、このことがサポートされうる。また、アクセスポイントが異なる時間間隔でビーコンを送る場合、ビーコンカウントを比較するエンティティは、公平な比較を行う（例：正規化を使用する）ことができるように、特定のアクセスポイントに設定されている間隔を認識していなければならない。

図８のフローチャートは、上記方法のステップ群をさらに詳しく示している。ステップ７０４において、モバイルノード／ＵＥをＡＰ１に関連付ける。モバイルノード／ＵＥは、ＡＰ１に関連付けられている間、ステップ７０５において、他のアクセスポイント（またはアクセスルータ）からのビーコンを絶え間なく、または間欠的に受信する。

次の２つのステップについては、２つの代替ステップが存在する。最初の代替ステップにおいては、ステップ８０１において、モバイルノード／ＵＥが、受信したビーコンに関するメッセージをＡＰ１に送り、ＡＰ１は、それらのメッセージをＣＴＭ１に転送することができる。ステップ８０２において、ＡＰ１またはＣＴＭ１のいずれかが、ＡＰｉそれぞれについて、単位時間あたりに受信されたビーコンを個別にカウントする。このステップには、上述したように、異なるアクセスポイントのビーコン送信の割合に関する正規化を含めることができる。

もう１つの代替ステップにおいては、ステップ８０３において、モバイルノードがカウントを行い、ステップ８０４において、その結果をＡＰ１に送り、最初の代替ステップと同様に、ＡＰ１はその結果をＣＴＭ１に転送することができる。この場合にも、カウントステップには正規化演算を含めることができる。あるいは、アクセスポイントまたはコンテキスト転送マネージャにおいて正規化を行うことができる。

以降のステップは、ＡＰ１またはＣＴＭ１において実行することができる。しかしながら、Ｓ７０９およびステップ７０７以外のすべてのステップは、モバイルノードにおいて実行することもできる。その場合、モバイルノードは、ステップ８０１またはステップ８０４の代わりに、コンテキスト転送マネージャにステップ７０７もしくはステップ７０９、またはその両方を実行させるメッセージをコンテキスト転送マネージャに送る。

ステップ８０５において、ＡＰ１とは異なる特定のＡＰｉを選択する。ステップ８０６において、そのＡＰｉについて、（正規化された）単位時間あたりのビーコンカウントが所定の上限Ａを超えているかを調べる。超えていない場合、ステップ７０９において、ＡＰｉの無線アクセスドメインＡＮｉにおけるＣＴＭ１からＣＴＭｉへのセキュリティアソシエーション（ＳＡ）がもし存在するならば、そのＳＡが現在使用されておらず、かつ別のモバイルノードに対して使用されることが予測されない限りは、そのＳＡを取り消す。次いで、本方法はステップ８１０に進み、処理すべきさらなるアクセスポイントが存在しているかを調べる。存在している場合、ステップ８１１において、次のＡＰｉを選択し、そのＡＰｉに対して、ステップ８０６以降を繰り返す。ステップ８０５〜ステップ８１１のそのインスタンスにおいてすべてのアクセスポイントを処理したら、本方法はビーコンの受信（ステップ７０５）に戻る。

ステップ８０６をもう一度参照し、ＡＰｉの（正規化された）単位時間あたりのビーコンカウントが上限Ａを超える場合、ステップ８０８において、任意の他のＡＰｊの（正規化された）単位時間あたりのビーコンカウントが、上述した上限Ｂを超えるかを調べる。あるいは、このとき、Ｂの値とは異なる別の上限値Ｃを選択することができる。ステップ８０８の条件が満たされない場合、本方法は、さきのＡＰｉがハンドオーバの候補である可能性が高いと結論し、ステップ７０７において、ハンドオーバの場合におけるコンテキスト転送を処理するためのＳＡとして、ＡＮｉにおけるＣＴＭ１からＣＴＭｉへのＳＡがまだ存在していなければ、このＳＡを確立する。このようにして、ハンドオーバを完了するのに要する時間が短縮される。

ステップ８０８をもう一度参照し、（正規化された）単位時間あたりのビーコンカウントが上限Ｂ（またはＣそれぞれ）を超える少なくとも１つのＡＰｊが見つかった場合、別の強力なハンドオーバ候補が存在すると結論する。上限Ｂが、ＡＰｉの（正規化された）単位時間あたりのビーコンカウントとは無関係の固定値として定義されている場合には、ステップ８０９において、ＡＰｉの（正規化された）単位時間あたりのビーコンカウントも上限Ｂを超えているかを調べる。超えている場合、ＡＰｉおよびＡＰｊの両方が強力なハンドオーバ候補であると判定し、本方法はステップ７０７に進み、ＣＴＭ１からＣＴＭｉへのＳＡがまだ存在していなければ、このＳＡを確立する。ＡＰｉの（正規化された）単位時間あたりのビーコンカウントが上限Ｂを超えていない場合、ＡＰｊの方がＡＰｉよりもずっと強力なハンドオーバ候補であることと、次のハンドオーバにおいてＣＴＭ１からＣＴＭｉへの既存のＳＡは必要ないこととを結論する。従って、そのようなＳＡが存在するならば、そのＳＡが現在使用されておらず、かつ別のモバイルノードに対して使用されることが予測されない限りは、ステップ７０９において、そのＳＡを取り消す。このことは、シグナリングオーバヘッド（コンテキスト転送マネージャにおける処理電力を必要とし、ネットワークの負荷につながる）が低減するという利点を有する。

ステップ８０８が「ＹＥＳ」である場合をもう一度参照し、上限Ｂが、ＡＰｉの（正規化された）単位時間あたりのビーコンカウントよりも特定の値だけ大きい値として定義されている場合、チェックステップ８０９は不要であり、本方法は、ステップ７０９に直接進む。

いずれの場合も、本方法は、次いでステップ８１０に進み、上述したように、処理すべき別のＡＰｉが存在するかを調べる。

１つの代替形態においては、ステップ８０９における上限を、ステップ８０８における上限Ｂ（またはＣそれぞれ）とは異なる値Ｄとして選択することができる。それぞれ異なる上限Ｂ、Ｃ、Ｄを選択することにより、ハンドオーバの時間短縮とシグナリングオーバヘッドの低減との間の最適な妥協点が達成されるように、ＳＡの平均生存時間を調整することが可能となる。

アクセスポイントまたはアクセスルータＡＰｉへのハンドオーバの可能性に応じて、コンテキストを転送する、あるいはデータトンネルをプロアクティブに確立するなど、さらなるアクションをトリガするためのさらなるしきい値を定義することができる。

コンテキスト転送マネージャ３０２，３０３は、上述した機能を実行するロジックエンティティである。これらのマネージャは、物理的には、専用サーバ内、ネットワークノード（例：ゲートウェイ）内、またはその他のネットワークエンティティ（例：ＡＡＡサーバ３０４，３０５）内に配置することができる。

図９は、上述したコンテキスト転送マネージャ（ＣＴＭ）として使用できるサーバ９００の例示的な構造を示している。このサーバは、少なくとも１つのネットワークインタフェース９０２と、中央処理ユニット９０１と、不揮発性データストレージ９０３とを備えている。

ＣＰＵ ９０１は、プロセッサまたはコントローラと、作業メモリＲＡＭとを備えている。ＣＰＵ ９０１は、上に詳しく説明したコンテキスト転送マネージャのタスクを実行するように構成されている。上述した方法におけるコンテキスト転送マネージャのタスクは、ハードウェアロジックに実装する、またはＣＰＵのプロセッサまたはコントローラにおいて実行されるソフトウェアに実装することができる。混合型の実装形態も可能である。上述した方法のステップ群をサーバ９００に実行させる命令を含んでいるプログラムは、不揮発性メモリ９０３に格納しておくことができ、このメモリは、ハードディスク、光ディスク、磁気テープ、または不揮発性半導体メモリ（例：フラッシュメモリ）とすることができる。

サーバ９００は、図に示した以外のユニットとして、キーボードやディスプレイ、さらなるネットワークインタフェースなどをさらに備えていることができ、これらは、上述したコンテキスト転送マネージャのタスクにとって必須ではなく、従ってオプションである。サーバ９００は、ネットワークノードと同じ場所に配置する、または個別のエンティティ中に用意することができる。

Claims (6)

1. 複数のアクセスネットワークを備えている異種モバイルネットワークに接続するモバイルノードであって、
   前記複数のアクセスネットワークの少なくとも１つのアクセスネットワークにおけるアクセスポイントから、前記アクセスポイントのアイデンティティについての情報を含んでいるブロードキャストメッセージを受信し、単位時間あたりに受信した前記アクセスポイントごとの前記ブロードキャストメッセージの数についての情報を取得する手段と、
   前記アクセスポイントから受信した前記ブロードキャストメッセージの数が所定の第１のしきい値を超えている場合、前記モバイルノードが接続している第１のアクセスネットワークに位置する第１のネットワークエンティティに対して、第２のアクセスネットワークに位置する第２のネットワークエンティティとＱｏＳ状態に関する通信を行うことを要求する手段と、
   を備えているモバイルノード。
2. 請求項１に記載のモバイルノードと、前記モバイルノードが接続している第１のアクセスネットワークに位置する第１のネットワークエンティティとを具備する通信システムであって、
   前記第１のネットワークエンティティは、前記モバイルノードに関連するコンテキスト情報を前記第１のアクセスネットワーク内の少なくとも一つのソースエンティティから収集し、前記収集したコンテキスト情報を第２のアクセスネットワークに位置する第２のネットワークエンティティに転送する通信システム。
3. 前記第１のネットワークエンティティと前記第２のネットワークエンティティとの通信は、セキュリティアソシエーションの早期確立をトリガするために実行される請求項２に記載の通信システム。
4. 複数のアクセスネットワークを備えている異種モバイルネットワークに接続するための方法であって、
   前記複数のアクセスネットワークの少なくとも１つのアクセスネットワークにおけるアクセスポイントから、前記アクセスポイントのアイデンティティについての情報を含んでいるブロードキャストメッセージを受信し、単位時間あたりに受信した前記アクセスポイントごとの前記ブロードキャストメッセージの数についての情報を取得するステップと、
   前記アクセスポイントから受信した前記ブロードキャストメッセージの数が所定の第１のしきい値を超えている場合、前記モバイルノードが接続している第１のアクセスネットワークに位置する第１のネットワークエンティティに対して、第２のアクセスネットワークに位置する第２のネットワークエンティティとＱｏＳ状態に関する通信を行うことを要求するステップと、
   を備えている方法。
5. 前記第１のネットワークエンティティが、前記モバイルノードに関連するコンテキスト情報を前記第１のアクセスネットワーク内の少なくとも一つのソースエンティティから収集するステップと、
   前記収集したコンテキスト情報を前記第１のネットワークエンティティから前記第２のネットワークエンティティに転送するステップとを、
   さらに具備する請求項４に記載の方法。
6. 前記第１のネットワークエンティティと前記第２のネットワークエンティティとの前記通信は、セキュリティアソシエーションの早期確立をトリガするために実行される請求項４または請求項５に記載の方法。

Images