(57)【要約】【課題】  ユーザに対しシームレスモビリティを提供できる改良型のシームレスハンドオーバのメカニズムを提供する。【解決手段】  あるアプリケーションが動いており、データを受信するモバイルノードが第１のアクセスノードから第２のアクセスノードへシームレスなハンドオーバを実行する方法であって、前記モバイルノードのバッファが前記データを受信するステップと、前記バッファが新たなデータを受信しない間において、前記アプリケーションが前記バッファに記憶されているデータをハンドオーバ中に使うステップと、ハンドオーバ中に到着した紛失したパケットを要求するため、前記第２のアクセスノードのキャッシュが受信したデータを前記モバイルノードがハンドオーバ後に要求するステップとを含む方法。【選択図】  図１
2008054322.tif 000002
【特許請求の範囲】
【請求項１】
あるアプリケーションが動いており、データを受信するモバイルノードが第１のアクセスノードから第２のアクセスノードへシームレスなハンドオーバを実行する方法であって、
前記モバイルノードのバッファが前記データを受信するステップと、
前記バッファが新たなデータを受信しない間において、前記アプリケーションが前記バッファに記憶されている前記データをハンドオーバ中に用いるステップと、
ハンドオーバ中に到着した紛失したパケットを要求するため、前記第２のアクセスノードのキャッシュが受信したデータを前記モバイルノードがハンドオーバ後に要求するステップと
を含み、
前記要求するステップは、前記バッファが受信して記憶した最新のパケットのＩＤを含むフェッチ要求メッセージを送信するステップを含むものであり、
前記キャッシュからの前記紛失したパケットの送信が、前記バッファが受信した前記パケットの次のＩＤを有するパケットから始まる、方法。
【請求項２】
最も可能性のある次のアクセスノードの予測に基づいて、前記最も可能性のある次のアクセスノード内のリソースの予約を要求するためにリソースクエリを送信するステップと、
前記予約に関する情報を含むリソースクエリ応答を受信するステップと
をさらに含む請求項１に記載の方法。
【請求項３】
前記第２のアクセスノードが、マルチキャスト可能なドメイン内にあり、
前記第２のアクセスノード上で同じセッションが既に動いている場合、ハンドオーバを実行する前記モバイルノードが前記セッションに加入する、請求項１又は２に記載の方法。
【請求項４】
前記リソースクエリ応答は、利用可能なリソース及びマルチキャストグループアドレスに関する情報を含むものであり、
前記モバイルノードが使用する前記第２のアクセスノードのＩＰアドレス及びマルチキャストチャネルを含むあるハンドオーバベアラメッセージを前記モバイルノードへと送信するステップをさらに含む請求項２又は３に記載の方法。
【請求項５】
ハンドオーバが実行される次のアクセスノードの決定が、前記リソースクエリ応答に含まれている情報に基づくものである、請求項２から４のいずれか一項に記載の方法。
【請求項６】
あるアプリケーションが動いている間において、第１のアクセスノードから第２のアクセスノードへシームレスなハンドオーバを実行する、データを受信するモバイルノードであって、
前記第１のアクセスノードから前記データを受信するバッファと、
前記バッファが新たなデータを受信しない間において、前記アプリケーションが前記バッファに記憶されている前記データをハンドオーバ中に使うための消費モジュールと、
ハンドオーバ中に到着した紛失したパケットを要求するため、前記第２のアクセスノードのキャッシュが受信したデータをハンドオーバ後に要求する要求モジュールと
を備え、
前記要求モジュールは、前記バッファが受信して記憶した最新のパケットのＩＤを含むフェッチ要求メッセージを送信するものであり、
前記キャッシュからの前記紛失したパケットの送信は、前記バッファが受信した前記パケットの次のＩＤを有するパケットから始まるものである、モバイルノード。
【請求項７】
前記第２のノードが、マルチキャスト可能なドメイン内にあり、
前記第２のアクセスノード上で前記セッションが既に動いている場合、前記モバイルノードが前記セッションに加入する、請求項６に記載のモバイルノード。
【請求項８】
前記第１のアクセスノードは、利用可能なリソース及びマルチキャストグループアドレスに関する情報を含むリソースクエリ応答を前記第２のアクセスノードから受信するものであり、
前記モバイルノードが使用する前記第２のアクセスノードのＩＰアドレス及びマルチキャストチャネルを含むあるハンドオーバベアラメッセージを前記第１のアクセスノードから受信するモジュールをさらに備える請求項６又は７に記載のモバイルノード。
【請求項９】
第２のアクセスノードからデータを受信する、あるアプリケーションが動いているモバイルノードのシームレスなハンドオーバをサポートするモバイルネットワーク内のアクセスノードであって、
前記モバイルノードは前記アクセスノードへハンドオーバするものであり、
前記モバイルノードはバッファにより前記データを受信するものであり、
前記アプリケーションは、前記バッファが新たなデータを受信しない間において、前記バッファが記憶している前記データをハンドオーバ中に使うものであって、
前記モバイルノードへ送信されるデータをキャッシュするキャッシュと、
ハンドオーバ中に到着した紛失したパケットを前記キャッシュが要求するために、ハンドオーバ後に前記モバイルノードから要求を受信するモジュールと
を備えるアクセスノード。
【請求項１０】
前記要求は、前記バッファが受信して記憶している最新のパケットのＩＤを含むあるフェッチ要求メッセージを含むものであり、
前記キャッシュからの前記紛失したパケットの送信が、前記バッファが受信した前記パケットの次のＩＤを有するパケットから始まるように、前記紛失したパケットを特定して送信するキャッシュ管理モジュールをさらに備える請求項９に記載のアクセスノード。
【請求項１１】
前記モバイルノードがハンドオーバを実行する可能性が最も高い次のアクセスノードの予測に基づいて、前記可能性が最も高い次のアクセスノード内のリソースの予約を要求するためのあるリソースクエリを前記第２のアクセスノードから受信するモジュールと、
前記予約に関する情報を含むあるリソースクエリ応答を送信するモジュールと
をさらに備える請求項９又は１０に記載のアクセスノード。
【請求項１２】
前記アクセスノードがマルチキャスト可能なドメイン内にあり、
前記アクセスノード上で前記モバイルノードと同じセッションが既に動いている場合、ハンドオーバを実行する前記モバイルノードが前記セッションに加入する、請求項９から１１のいずれか一項に記載のアクセスノード。
【請求項１３】
前記リソースクエリ応答は、前記モバイルノードが使用する前記第２のアクセスノードのＩＰアドレス及びマルチキャストチャネルを含むあるハンドオーバベアラメッセージを前記第２のアクセスノードが前記モバイルノードへ送信できるようにするために、利用可能なリソース及びマルチキャストグループアドレスに関する情報を含むものである、請求項９から１２のいずれか一項に記載のアクセスノード。
【請求項１４】
請求項６から８のいずれか一項に記載のモバイルノードと、
第１のアクセスノードとして請求項９から１３のいずれか一項に記載のアクセスノードと、
第２のアクセスノードとして請求項９から１３のいずれか一項に記載のアクセスノードと
を備え、前記モバイルノードは前記第２のアクセスノードから前記第１のアクセスノードへハンドオーバを実行するものである、ハンドオーバシステム。
【請求項１５】
請求項１から５のいずれか一項に記載の方法を実行する手順と、
請求項６から８のいずれか一項に記載のモバイルノードとして動作する手順と、
請求項９から１３のいずれか一項に記載のアクセスノードとして動作する手順と
のうちのいずれか１つをコンピュータに実行させるプログラムコードを含むコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はシームレスなハンドオーバを実行する方法及び装置に関する。
【背景技術】
【０００２】
ワイヤレステクノロジーの目覚ましい発展とともに通信機器の携帯性が高まることにより、ユーザのシームレスなモビリティが必要となってきている。さらに、マルチユーザのリアルタイムサービスが同時に出現し、いくつもの受信機へ同時にコンテンツを配信するためのマルチキャスト通信の重要性が顕著なものとなっている。しかし、モバイル通信においては、元々異種の環境における送信機および受信機のシームレスなハンドオーバという未解決の問題がある。
【０００３】
マルチキャスト通信は、いくつもの受信機へ同時に情報を送信する場合にリソース活用の点でユニキャスト通信よりも効率的であるため、マルチユーザのリアルタイムサービスをサポートするための最適な技術である。さらに受信機のモビリティという点で、マルチキャストプロトコルは、受信機が移動するときにマルチキャストツリーの新たな分岐を構成することだけが必要となるので、よりいっそう重要なものとなる。それにもかかわらず、マルチキャストプロトコルは、シームレスなモビリティをサポートするために開発されなかったため、このタイプの通信を含むシームレスなハンドオーバを提供するためにモビリティの管理が必要である。このように、ＱｏＳサポートを含むマルチキャストにおけるモビリティの管理は、次世代モバイルネットワーク開発の成功のために興味深く、かつ、未解決のタスクである。したがって、ハンドオーバ中のロスを抑制し、ユーザが知覚するサービス低下を制限する解決策が必要である。
【０００４】
シームレスなモビリティの問題は、ユニキャスト通信又はマルチキャスト通信のいずれかを目的とするアプローチを含んだ幾つかの提案により扱われている。しかし、既存の解決策は、現在及び将来のネットワークにおいて現実になりつつあるが、両方のタイプの通信を同時にサポートしていない。さらに、従来の解決策の適用範囲は、マイクロモビリティのレベル又はマクロモビリティのレベルの何れかであり、グローバルでシームレスなモビリティを実現するためには複数のメカニズムの組み合わせが必要である。
【０００５】
シームレスなモビリティに関係する上述の未解決問題に加えて、この問題を扱う殆どの既存の解決策は、ハンドオーバ中のレイテンシ又はロスの何れかを低減して、ハンドオーバ中にサポートされるトラフィック性能のレベルを制限する。さらに、遅延と損失を同時に最小化することができるアプローチは、トンネルの構築に基づいているため、ネットワークに過度のシグナリングオーバーヘッドをもたらす。このアプローチがネットワークリソースの浪費をまねき、使用されるメカニズムの高度な複雑性と関連していることは明白である。
【０００６】
以下、モビリティの問題を対象とする従来技術のアプローチを詳細に説明する。
【０００７】
マクロモビリティの最も代表的な例は、モバイルＩＰ（ＭＩＰ）である（非特許文献１参照）。このアプローチでは、モバイルノードがフォーリンネットワーク（ＦＮ）として表されている別のネットワークへ移動するとき、そのモバイルノードは、ホームエージェント（ＨＡ）と呼ばれるホームネットワーク（ＨＮ）内のエンティティに対して、ケアオブアドレス（ＣｏＡ）と呼ばれる自己の新たなアドレスを通知する。このモバイルノードへアドレス指定されているパケットは、「ホームエージェント」によりホームネットワーク内でインターセプトされる。これらのパケットを配信するためにこのエンティティは、モバイルノード、またはフォーリンエージェント（ＦＡ）と呼ばれるＦＮ内のエンティティとのトンネルを確立する。同種のシステムと異種のシステムとの間でモビリティをサポートするモバイルＩＰの機能にもかかわらず、幾つかの欠点、すなわちホームエージェントとモバイルノードとが離れているときの深刻なレイテンシ及びハンドオーバ中のパケットロスがある。
【０００８】
階層的ＭＩＰ（非特許文献２参照）は、周知のマイクロモビリティプロトコルである。このアプローチでは、自己のドメイン内に位置しているモバイルノードに対し、ローカルホームエージェントとしての機能を果たす「モビリティアンカーポイント」（ＭＡＰ）が導入されている。この場合、２つのタイプのＣｏＡ、すなわち（外部から見え、モバイルノードがドメイン内に留まる間は変化しない）リージョナルＣｏＡと、（モバイルノードのローカルアドレスである）ローカルＣｏＡとが存在する。ＭＡＰが（アドレスＲＣｏＡを用いて）モバイルノード宛のパケットを受信する場合、ＭＡＰは、これらのパケットをカプセル開放し、それぞれのＬＣｏＡへとルーティングする。モバイルノードがドメイン内部で移動したとき、モバイルノードはＭＡＰへ新たなＬＣｏＡを通知し、ＲＣｏＡはそのまま変化しない。これに反して、モバイルノードが新しいドメインへ移動した場合、モバイルノードは新たなＲＣｏＡをＨＡに登録する。新しいドメインへのハンドオーバが起こるときに限りホームエージェント上のモバイルノードのロケーションを更新することにより、このスキームは遅延を低減する。しかし、このアプローチでは、パケットロスを阻止するための対策がない。
【０００９】
ＩＰｖ６の場合の高速ハンドオーバ（ＦＭＩＰ）（非特許文献３参照）は、マイクロモビリティプロトコルの別の例である。この解決策では、モバイルノードのアドレスは、モバイルノードがハンドオーバを開始する前に設定される。プロトコルは、ハンドオーバの開始、トンネルの確立及びパケットの転送という３つのフェーズに分けられる。まず、モバイルノードは、そのモバイルノードが新たなアクセスルータ（ＮＡＲ）への高速ハンドオーバを実行することを望む旨を表すルータ要請プロキシ（ＲｔＳｏｌＰｒ）メッセージであって、新たなアクセスルータのリンクレイヤアドレスを含むルータ要請プロキシ（ＲｔＳｏｌＰｒ）メッセージを以前のアクセスルータ（ＰＡＲ）へ送信する。代わりに、モバイルノードは、プロキシルータ通知（ＰｒＲｔＡｄｖ）メッセージをＰＡＲから受信する。このメッセージによって提供される情報を用いて、モバイルノードは、将来のＮＣｏＡを生成し、ＰＡＲに対しＰＣｏＡをＮＣｏＡと結び付ける許可を与えるためＦＢＵ（高速バインディングアップデート）メッセージを送信する。このようにして、到達したパケットは、ＰＡＲからモバイルノード（ＮＡＲ）の新たなロケーションへとトンネル化される。ここで、モバイルノードがＮＡＲに接続していない間は、この到達したパケットがバッファされる。このメッセージの受信後、ＰＡＲは、モバイルノードによって生成されたＮＣｏＡを許容できるかどうかを確認するため、ハンドオーバ開始（ＨＩ）メッセージをＮＡＲへ送信する。ＮＡＲは、ハンドオーバ承認メッセージ（ＨＡｃｋ）で応答する。その後、ＰＡＲは、高速バインディング承認メッセージ（ＦＢａｃｋ）をＭＮへ送信する。このメッセージの受信は、パケットが既にＭＮの将来のロケーションへ転送されていることを示唆する。新たなロケーションへ到着した後、モバイルノードは、ＮＡＲから自己へのパケットフローを開始するために高速近傍通知（ＦＮＡ）を送信する。モバイルノードの移動を予測し、ハンドオーバが起きる前にＮＣｏＡを構成することにより、Ｆ−ＭＩＰｖ６はパケット損失を最小限に抑えることができる。しかし、大量のシグナリングが交換され、このアプローチはトンネルの構築によってサポートされる。
【００１０】
ＦＭＩＰｖ６はパケット損失を最小限に抑え、ＨＭＩＰｖ６はハンドオーバ中の遅延を低減するにもかかわらず、これらは個別にシームレスでローカルなハンドオーバを実現できない。これらの提案を改良するための最も簡単な方法は両方を直接組み合わせることである。しかし、ＨＭＩＰｖ６アプローチでは、トンネルは（ＡＲではなく）ＭＡＰからモバイルノードへと進み、ＦＭＩＰｖ６では、トンネルがＰＡＲからＮＡＲへ構築されるので、直接的な組み合わせはオーバーヘッド及びネットワークの非効率的な使用をもたらす。２つの主要なスキームがより効率的にＨＭＩＰｖ６をＦＭＩＰｖ６と組み合わせることを試みている。Ｆ−ＨＭＩＰと呼ばれる第１のアプローチ（非特許文献４を参照のこと）は、（ＦＭＩＰｖ６の場合のように）ＰＡＲとＮＡＲとの間でトンネルを使用するのではなく、ＭＡＰとＮＡＲとの間でのトンネルの利用を提案している。このスキームは、ハンドオーバ中にトンネルの確立を使用するので、シグナリングオーバーヘッドを生成するという欠点がある。モバイルＩＰ（Ｓ−ＭＩＰ）のためのシームレスハンドオフアーキテクチャと呼ばれる第２のアプローチ（非特許文献５参照）は、各パケット（ｓ−パケット）のコピーをＭＡＰからＰＡＲ及びＮＡＲへと送信するために、同期型パケットサイマルキャスト（ＳＰＳ）と呼ばれる方法を使用する。それに加えて、パケットは、パケットの損失を回避するために、ＰＡＲからＮＡＲ（ｆ−パケット）にも転送される。このスキームは、（たとえば、ＮＡＲ内でｓ−パケットとｆ−パケットを分離するために）ネットワークリソースを浪費し、複雑度を増大させるという欠点がある。
【００１１】
マルチキャストは、（マルチキャストグループと呼ばれる）いくつもの受信機へ同時に情報を転送する最も適切な方法である。マルチキャスト通信では、ソースは、受信機の個数と同数のコピーを送信するのではなく、情報のたった１個のコピーを送信し、ネットワークが必要に応じてパケットを複製する。このようにして、リソースを効率的に使用できる。モビリティとマルチキャストの組み合わせによって生じる幾つかの問題を解決するため、マルチキャストに関するいくつもの提案が紹介されている。
【００１２】
ホームサブスクリプション又は双方向トンネリングと呼ばれる提案は、モバイルＩＰアーキテクチャに基づいている（非特許文献６参照）。モバイルノードがフォーリンネットワークにあって、あるマルチキャストグループへ加入することを望むとき、モバイルノードはホームエージェントとの双方向トンネルを確立する。このトンネルを通じて、モバイルノードは、メンバーシップレポートメッセージを送信し、マルチキャストデータを受信する。モバイルノードが新たなフォーリンネットワークへ移動するたびに、モバイルノードはＨＡを経由してマルチキャストデータを受信し続ける。換言すると、マルチキャストツリーは、モバイルノードが異なったネットワークへ移動するたびに再構築しなくてもよい。このようにして、マルチキャストはホームネットワーク内だけでサポートされなければならない。同様に、このアプローチは、モバイルノードがローカルホームネットワークマルチキャストグループへ加入することを許可する。しかし、このスキームは、ホームネットワーク内のトラフィックの増加の原因となり、マルチキャストパケットのルーティングは最適ではない。その上、幾つかのモバイルノードがＦＮ内の同じマルチキャストグループに加入している場合はパケットが重複する。
【００１３】
リモートサブスクリプションアプローチでは（非特許文献７参照）、モバイルノードは、マルチキャストグループに加入又は離脱するとき、静的なノードの通常の動きに従う。換言すると、モバイルノードが新たなネットワークへ移動するとき、モバイルノードはローカルマルチキャストルータを通じてマルチキャストグループに加入する。このアプローチは、最適なルーティングをもたらし、モバイルＩＰベースのアプローチに存在するパケットの重複を回避する。しかし、モバイルノードが新たなネットワークへ移動するたびに（かつ、同じグループの加入者がこのネットワーク内に存在しないとき）、マルチキャストツリーを再調整しなければならず、長い中断の原因となり、その結果パケット損失の原因となる。その上、マルチキャストが全てのＦＮによってサポートされているという仮定には誤りがある。
【００１４】
ハンドオーバ中に失われたパケットの問題を解決するために、あるマイクロモビリティプロトコルは、これらのパケットを一時的に記憶するように設計されている。一部のアプローチでは、パケットは元のアクセスルータに一時的に記憶され、ハンドオーバ後にモバイルノードと新たなアクセスノードとの間のＩＰ接続が確立されたとき、これら一時的に記憶されていたパケットが元のアクセスルータからモバイルノードへと送信される。これは、例えばモバイルＩＰｖ４における低レイテンシハンドオフ（ＬＬＨ）の事前登録と共に使用できる（非特許文献８参照）。その他のスキームは、新たなアクセスルータ内にパケットを一時的に記憶する。これは、ＦＭＩＰ及びＬＬＨの事後登録の場合である。しかし、これらのアプローチには、ハンドオーバ中に受信したアプリケーションのスターベイションを回避し、マルチユーザサービスの機能をサポートするアプローチはない。
【００１５】
上述したように、既存の解決策は、シームレスモビリティの問題を解決せず、重大な量のシグナリングオーバーヘッド及び複雑度を通信システムにもたらす。
【００１６】
【非特許文献１】Ｄ．  Ｊｏｈｎｓｏｎ  ａｎｄ  Ｃ．  Ｐｅｒｋｉｎｓ，“Ｍｏｂｉｌｉｔｙ  Ｓｕｐｐｏｒｔ  ｆｏｒ  ＩＰｖ６”，  ＲＦＣ  ３７７５，  Ｉｎｔｅｒｎｅｔ  Ｅｎｇｉｎｅｅｒｉｎｇ  Ｔａｓｋ  Ｆｏｒｃｅ，  Ｊｕｎｅ  ２００４
【非特許文献２】Ｈ．  Ｓｏｌｉｍａｎ，  Ｃ．  Ｃａｔｅｌｌｕｃｉａ，  Ｋ．  Ｍａｌｋｉ  ａｎｄ  Ｌ．  Ｂｅｌｌｉｅｒ，“Ｈｉｅｒａｒｃｈｉｃａｌ  Ｍｏｂｉｌｅ  ＩＰｖ６  ｍｏｂｉｌｉｔｙ  ｍａｎａｇｅｍｅｎｔ  （ＨＭＩＰｖ６）”，  ＲＦＣ  ４１４０，  Ｉｎｔｅｒｎｅｔ  Ｅｎｇｉｎｅｅｒｉｎｇ  Ｔａｓｋ  Ｆｏｒｃｅ，  Ａｕｇｕｓｔ  ２００５
【非特許文献３】Ｒ．  Ｋｏｏｄｌｉ，“Ｆａｓｔ  Ｈａｎｄｏｖｅｒｓ  ｆｏｒ  Ｍｏｂｉｌｅ  ＩＰｖ６”，  ＲＦＣ  ４０６８，  Ｉｎｔｅｒｎｅｔ  Ｅｎｇｉｎｅｅｒｉｎｇ  Ｔａｓｋ  Ｆｏｒｃｅ，  Ｊｕｌｙ  ２００５
【非特許文献４】Ｈ．  Ｊｕｎｇ，  Ｓ．  Ｋｏｈ，  Ｈ．  Ｓｏｌｉｍａｎ  ａｎｄ  Ｎ．  Ｔａｋａｍｉｙａ，“Ｆａｓｔ  Ｈａｎｄｏｖｅｒ  ｆｏｒ  Ｈｉｅｒａｒｃｈｉｃａｌ  ＭＩＰｖ６”，  Ｉｎｔｅｒｎｅｔ  Ｄｒａｆｔ，  Ｉｎｔｅｒｎｅｔ  Ｅｎｇｉｎｅｅｒｉｎｇ  Ｔａｓｋ  Ｆｏｒｃｅ，  Ｏｃｔｏｂｅｒ  ２００５
【非特許文献５】Ｒ．  Ｈｓｉｅｈ，  Ｚ．  Ｚｈｏｕ  ａｎｄ  Ａ．  Ｓｅｎｅｖｉｒａｔｎｅ，  “Ｓ−ＭＩＰ：  Ａ  Ｓｅａｍｌｅｓｓ  Ｈａｎｄｏｆｆ  Ａｒｃｈｉｔｅｃｔｕｒｅ  ｆｏｒ  Ｍｏｂｉｌｅ  ＩＰ”，  Ｐｒｏｃ．  ｏｆ  ｔｈｅ  Ｃｏｎｆｅｒｅｎｃｅ  ｏｎ  Ｃｏｍｐｕｔｅｒ  Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ  （ＩＥＥＥ  ＩＮＦＯＣＯＭ），  Ｓａｎ  Ｆｒａｎｃｉｓｃｏ，  ＵＳＡ  Ａｐｒｉｌ  ２００３
【非特許文献６】Ｄ．  Ｊｏｈｎｓｏｎ  ａｎｄ  Ｃ．  Ｐｅｒｋｉｎｓ，  “Ｍｏｂｉｌｉｔｙ  Ｓｕｐｐｏｒｔ  ｆｏｒ  ＩＰｖ６”，  ＲＦＣ  ３７７５，  Ｉｎｔｅｒｎｅｔ  Ｅｎｇｉｎｅｅｒｉｎｇ  Ｔａｓｋ  Ｆｏｒｃｅ，  Ｊｕｎｅ  ２００４
【非特許文献７】Ｃ．  Ｊａｎｎｅｔｅａｕ，  Ｙ．  Ｔｉａｎ，  Ｓ．  Ｃｓａｂａ，  Ｔ．  Ｌｏｈｍａｒ，  Ｈ．  Ｌａｃｈ，  ａｎｄ  Ｒ．  Ｔａｆａｚｏｌｌｉ，  “Ｃｏｍｐａｒｉｓｏｎ  ｏｆ  Ｔｈｒｅｅ  Ａｐｐｒｏａｃｈｅｓ  Ｔｏｗａｒｄｓ  Ｍｏｂｉｌｅ  Ｍｕｌｔｉｃａｓｔ”，  ｉｎ  Ｐｒｏｃｅｅｄｉｎｇｓ  ｏｆ  ｔｈｅ  ＩＳＴ  Ｍｏｂｉｌｅ  ＆  Ｗｉｒｅｌｅｓｓ  Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ  Ｓｕｍｍｉｔ，  Ａｖｅｉｒｏ，  Ｐｏｒｔｕｇａｌ，  Ｊｕｎｅ  ２００３
【非特許文献８】Ｋ．  Ｅｌ  Ｍａｌｋｉ，  “Ｌｏｗ  Ｌａｔｅｎｃｙ  Ｈａｎｄｏｆｆｓ  ｉｎ  Ｍｏｂｉｌｅ  ＩＰｖ４”，  Ｉｎｔｅｒｎｅｔ  Ｄｒａｆｔ，  Ｉｎｔｅｒｎｅｔ  Ｅｎｇｉｎｅｅｒｉｎｇ  Ｔａｓｋ  Ｆｏｒｃｅ，  Ｏｃｔｏｂｅｒ  ２００５
【発明の開示】
【発明が解決しようとする課題】
【００１７】
したがって、本発明の目的は、好ましくは、シングルユーザサービス及びマルチユーザサービスのユーザが様々なアクセスエージェントの間を移動するときに、ユーザに対しシームレスモビリティを提供できる改良型のシームレスハンドオーバのメカニズムを提供することにある。
【課題を解決するための手段】
【００１８】
一実施形態によれば、あるアプリケーションが動いており、データを受信するモバイルノードが第１のアクセスノードから第２のアクセスノードへシームレスなハンドオーバを実行する方法であって、前記モバイルノードのバッファが前記データを受信するステップと、前記バッファが新たなデータを受信しない間において、前記アプリケーションが前記バッファに記憶されている前記データをハンドオーバ中に用いるステップと、ハンドオーバ中に到着した紛失したパケットを要求するため、前記第２のアクセスノードのキャッシュが受信したデータを前記モバイルノードがハンドオーバ後に要求するステップとを含み、前記要求するステップは、前記バッファが受信して記憶した最新のパケットのＩＤを含むフェッチ要求メッセージを送信するステップを含むものであり、前記キャッシュからの前記紛失したパケットの送信が、前記バッファが受信した前記パケットの次のＩＤを有するパケットから始まる、方法が提供される。
【００１９】
これにより、パケットの損失が無く、かつ、遅延が無いシームレスなハンドオーバが可能となる。したがって、ハンドオーバメカニズムは、ハンドオーバにより送信が中断したポイントからアプリケーションが正確に再開することを可能にする。
【００２０】
一実施形態によれば、前記方法は、最も可能性のある次のアクセスノードの予測に基づいて、前記最も可能性のある次のアクセスノード内のリソースの予約を要求するためにリソースクエリを送信するステップと、前記予約に関する情報を含むリソースクエリ応答を受信するステップとをさらに含む。
【００２１】
予測メカニズムとの相互作用及びリソースの予約により、ハンドオーバするための新たなアクセスノードの準備が可能となる。
【００２２】
一実施形態によれば、前記第２のアクセスノードが、マルチキャストが可能なドメイン内にあり、前記第２のアクセスノード上で同じセッションが既に動いている場合、ハンドオーバを実行する前記モバイルノードが前記セッションに加入する。
【００２３】
これにより、メカニズムはマルチキャストをサポートし、効率を向上させ、ハンドオーバメカニズムによって生まれるオーバーヘッドを削減する。
【００２４】
一実施形態によれば、前記リソースクエリ応答は、利用可能なリソース及びマルチキャストグループアドレスに関する情報を含むものであり、前記方法は、前記モバイルノードが使用する前記第２のアクセスノードのＩＰアドレス及びマルチキャストチャネルを含むあるハンドオーバベアラメッセージを前記モバイルノードへと送信するステップをさらに含む。
【００２５】
これにより、モバイルノードが受信した情報に基づいて、該モバイルノードは新たな環境に向けて準備でき、マルチキャストセッションに直接加入できる。
【００２６】
一実施形態によれば、ハンドオーバが実行される次のアクセスノードの決定は、前記リソースクエリ応答に含まれている情報に基づく。
【００２７】
これにより、例えば利用可能なリソースに関して、そして、できれば進行中のマルチキャストセッションに関しても、効率的な方法でモバイルノードを新たなノードとして受け入れることに適している次のアクセスノードを選択することにより、ハンドオーバの決定自体を改良する。例えば、利用可能なリソースを有し、及び／又は、可能であれば既にマルチキャストセッションを動かしている次のアクセスノードは、他のアクセスノードよりも優先される。
【００２８】
一実施形態によれば、あるアプリケーションが動いている間において、第１のアクセスノードから第２のアクセスノードへシームレスなハンドオーバを実行する、データを受信するモバイルノードであって、前記第１のアクセスノードから前記データを受信するバッファと、前記バッファが新たなデータを受信しない間において、前記アプリケーションが前記バッファに記憶されている前記データをハンドオーバ中に使うための消費モジュールと、ハンドオーバ中に到着した紛失したパケットを要求するため、前記第２のアクセスノードのキャッシュが受信したデータをハンドオーバ後に要求する要求モジュールとを備え、前記要求モジュールは、前記バッファが受信して記憶した最新のパケットのＩＤを含むフェッチ要求メッセージを送信するものであり、前記キャッシュからの前記紛失したパケットの送信は、前記バッファが受信した前記パケットの次のＩＤを有するパケットから始まるものである、モバイルノードが提供される。
【００２９】
一実施形態によれば、前記第２のノードが、マルチキャスト可能なドメイン内にあり、前記第２のアクセスノード上で前記セッションが既に動いている場合、前記モバイルノードが前記セッションに加入する。
【００３０】
一実施形態によれば、前記第１のアクセスノードは、利用可能なリソース及びマルチキャストグループアドレスに関する情報を含むリソースクエリ応答を前記第２のアクセスノードから受信するものであり、前記モバイルノードは、前記モバイルノードが使用する前記第２のアクセスノードのＩＰアドレス及びマルチキャストチャネルを含むあるハンドオーバベアラメッセージを前記第１のアクセスノードから受信するモジュールをさらに備える。
【００３１】
一実施形態によれば、第２のアクセスノードからデータを受信する、あるアプリケーションが動いているモバイルノードのシームレスなハンドオーバをサポートするモバイルネットワーク内のアクセスノードであって、前記モバイルノードは前記アクセスノードへハンドオーバするものであり、前記モバイルノードはバッファにより前記データを受信するものであり、前記アプリケーションは、前記バッファが新たなデータを受信しない間において、前記バッファが記憶している前記データをハンドオーバ中に使うものであって、前記モバイルノードへ送信されるデータをキャッシュするキャッシュと、ハンドオーバ中に到着した紛失したパケットを前記キャッシュが要求するために、ハンドオーバ後に前記モバイルノードから要求を受信するモジュールとを備え、前記リクエストは、前記バッファが受信して記憶している最新のパケットのＩＤを含むあるフェッチ要求メッセージを含むものであり、前記キャッシュからの前記紛失したパケットの送信が、前記バッファが受信した前記パケットの次のＩＤを有するパケットから始まるように、前記紛失したパケットを特定して送信するキャッシュ管理モジュールをさらに備えるアクセスノードが提供される。
【００３２】
一実施形態によれば、前記アクセスノードは、前記モバイルノードがハンドオーバを実行する可能性が最も高い次のアクセスノードの予測に基づいて、前記可能性が最も高い次のアクセスノード内のリソースの予約を要求するためのあるリソースクエリを前記第２のアクセスノードから受信するモジュールと、前記予約に関する情報を含むあるリソースクエリ応答を送信するモジュールとをさらに備える。
【００３３】
一実施形態によれば、前記アクセスノードがマルチキャスト可能なドメイン内にあり、前記アクセスノード上で前記モバイルノードと同じセッションが既に動いている場合、ハンドオーバを実行する前記モバイルノードが前記セッションに加入する。
【００３４】
一実施形態によれば、前記リソースクエリ応答は、前記モバイルノードが使用する前記第２のアクセスノードのＩＰアドレス及びマルチキャストチャネルを含むあるハンドオーバベアラメッセージを前記第２のアクセスノードが前記モバイルノードへ送信できるようにするために、利用可能なリソース及びマルチキャストグループアドレスに関する情報を含む。
【００３５】
一実施形態によれば、本発明の一実施形態に基づくモバイルノードと、第１のアクセスノードとして本発明の一実施形態に基づくアクセスノードと、第２のアクセスノードとして本発明の一実施形態に基づくアクセスノードとを備え、前記モバイルノードは前記第２のアクセスノードから前記第１のアクセスノードへハンドオーバを実行するものである、ハンドオーバシステムが提供される。
【００３６】
本発明の実施形態によれば、本発明の一実施形態に基づく方法を実行する手順と、本発明の一実施形態に基づくモバイルノードとして動作する手順と、本発明の一実施形態に基づくアクセスノードとして動作する手順とのうちのいずれか１つをコンピュータに実行させるプログラムコードを含むコンピュータプログラムが提供される。
【発明を実施するための最良の形態】
【００３７】
典型的な実施形態を用いて本発明を説明する前に、まず以下の記載で使用する用語について簡単に説明する。
【００３８】
アクセスエージェント：本発明の実施形態に基づいてハンドオーバメカニズムを実行する機能を有するアクセスネットワークエレメント。
マクロモビリティ：様々なドメイン間のモバイルノードの移動。
マイクロモビリティ：同じドメイン内の異なるサブネット間の移動。
【００３９】
一実施形態によれば、キャッシングメカニズムとバッファリングメカニズムの組み合わせに基づいてユーザのシームレスモビリティを提供するアプローチが提供される。提案されるスキームは、パケットを記憶するためのキャッシュ及びバッファの機能を利用して、ユーザがパケットを損失することなく異なるロケーション間を移動できるようにする。提案されるメカニズムのベースは、モバイルノードに位置するバッファと、アクセスエージェントと呼ばれるアクセスネットワークエレメントに設置されたキャッシュとの組み合わせであり、これらが一体となってアクセスネットワークエレメント間のシームレスなハンドオーバを可能にする。
【００４０】
一実施形態によれば、シームレスな移動は、パケットを損失することなく異種のネットワーク間でのモバイルノードの移動をサポートする役割を担うバッファリングとキャッシングのメカニズムによってサポートされている。これは、最も可能性のある次のアクセスエージェントの予測を考慮して、ハンドオーバ中のパケット損失を一体となって回避するアクセスエージェント内のキャッシュとモバイル機器内のバッファとの組み合わせによって実現される。
【００４１】
一実施形態によれば、基本となるメカニズムは以下の通りである。キャッシュは、ネットワークに位置するアクセスエージェント内でパケットを記憶するために使用され、バッファは、モバイルノード内にパケットを記憶するために使用される。モバイルノードのバッファ内のデータは、パケット損失を回避してデータフローを保つためにハンドオーバ中に読み取られる。このようにしてバッファの占有は、ハンドオーバの間、バッファのサイズ、及びバッファからアプリケーションへとパケットを送信するために使用されるレートに依存するあるレベルまで減少する。ハンドオーバ後、モバイルノードは、ハンドオーバ中に到着したパケットをキャッシュからフェッチする。パケットが既にキャッシュ内に存在すれば（例えば、他の受信機がセル内に存在するならば）、ハンドオーバメカニズムは、ハンドオーバ中に受信できなかったパケットを即座に回復できる。もし存在しないならば、対象とするセッションに加入するために必要な措置を講じる必要がある。この場合、シームレスモビリティは、セッションが動作していない間にアプリケーションへ提供するためにバッファ上で利用可能なパケットの個数に依存する。
【００４２】
セッションが次のアクセスエージェントに既に存在していると仮定すると、殆どの状況において損失するパケットはなく、したがってフローが中断しないことが期待される。
【００４３】
図１は、モバイルノードが２個のアクセスエージェント間を移動するときに、ハンドオーバのバッファへの影響の例を示している。ここで、アクセスエージェントは、モバイルノードと同様に、上記のハンドオーバメカニズムを実行するために相互に作用するモジュールである。
【００４４】
ここで、使用されている用語には以下の意味がある。
Ｉはバッファの総容量を表す。
ｎは、バッファに入った最新のパケットの「タイムスタンプ」を表し、したがって（当然ながら、使われなかったならば）ハンドオーバ直後にバッファ内に存在する最新のパケットを表す。
ｋはハンドオーバ後にバッファ内に存在する「最も古い」パケットの「タイムスタンプ」を表す。
Ｌはキャッシュの総容量を表す。
Ｎはキャッシュに存在する最新のパケットの「タイムスタンプ」を表す。
【００４５】
図２は、ハンドオーバ後の新しいハンドオーバメカニズムの効果を示している。パケット回復のプロセスは、モバイルノードのバッファから新たなアクセスエージェントのキャッシュへと送信されてハンドオーバ前にバッファが受信した最新のパケットのＩＤと、バッファ（ｉ）内で依然として利用可能である容量とを含むメッセージ（図１のパートｉにおいて矢印で示されているフェッチ要求）によって開始される。キャッシュがフェッチ要求を受信すると、キャッシュは、モバイルノードへ送信されるパケット（すなわち、パケットｎからパケットＮ）を特定し（図２のパートｉｉ）、応答メッセージ（フェッチ応答）を送信する（図２のパートｉｉｉ）。その後、キャッシュは、バッファから受信した要求に応じて、モバイルノードのバッファ内で不足しているパケットを送信する。
【００４６】
ハンドオーバメカニズムの上記の動作は、ハンドオーバ中に受信されなかったパケットを受信するための十分な空き容量がモバイルノードのバッファに存在する状況を表している。しかし、キャッシュが、モバイルノード内のバッファが要求しているパケットの全てをアロケートできないことを検出すると、キャッシュはバッファに収まり切らないパケットを廃棄できる。
【００４７】
キャッシング及びバッファリングのハンドオーバメカニズムは以下のメッセージによってサポートされる。
・フェッチ要求：モバイルノードから新たなアクセスエージェントへ送信され、ハンドオーバ中に到着した不足のパケットを要求するメッセージである。このメッセージは、（ＩＧＭＰまたはＭＬＤメッセージと同様に）到着したマルチキャストパケットのフローもトリガできる。
・フェッチ応答：新たなアクセスエージェントからモバイルノードへ送信され、要求に関連する情報（たとえば、キャッシュから送信されるデータ量）を含む応答メッセージである。
【００４８】
一実施形態によれば、ハンドオーバメカニズムは、次の基地局内でのセッションの存在が予測により保証される付加的なメカニズムによって強化できる。すなわち、ＭＮの移動先となる可能性が最も高いセルが予測される。この予測に基づいて、必要なリソースがこれらのセル内で予約される。
【００４９】
この場合、ハンドオーバプロトコルのリソース要求メッセージは、利用可能なリソースに関する情報を取得するため、そして、マルチキャストドメインでは、マルチキャストグループアドレスといったマルチキャストに関連するデータを取得するため、最も可能性の高いアクセスエージェントへ送信される。この情報は、リソース応答メッセージを通して要求元のアクセスエージェントへ返信される。この情報を収集し、次のアクセスエージェントを選択した後、現在のアクセスエージェントは、ハンドオーバベアラメッセージを通して、将来のアクセスエージェントに関する情報、すなわち将来のアクセスエージェントのＩＰアドレス及び対応するマルチキャストチャネルをモバイルノードへ提供する。
【００５０】
このようにして、ハンドオーバ後に、モバイルノードは、ハンドオーバメカニズムと、（たとえば、３ＧＰＰにおけるＩＭＳのような、モバイルマルチメディアシステムに常駐している）セッション管理プロトコルとの相互作用によって、新たなロケーションで利用できる可能性が最も高いセッションを有することができる。この場合、モバイルノードが新たなアクセスエージェントに到着するときにセッション状態が既に組み込まれており、ハンドオーバ中に失われたパケットをフェッチするだけで足りるので、新しいハンドオーバメカニズムはハンドオーバ中のレイテンシも低減できる。
【００５１】
本実施形態のキャッシング及びバッファリングの強化されたハンドオーバメカニズムは、以下の付加的なメッセージによってサポートされる。
・リソースクエリ：ハンドオーバの対象となる可能性が最も高いアクセスエージェント内のリソースをクエリして予約するために送信されるメッセージである。
・リソース応答：要求元のアクセスエージェントへ送信され、要求された情報（すなわち、可能性のあるフォーリンネットワーク内の利用可能なリソース及びマルチキャストグループアドレス）を含むメッセージである。
・ハンドオーバベアラ：ハンドオーバの決定後、このメッセージは現在のアクセスエージェントからモバイルノードへ送信され、将来のアクセスエージェントに関係した情報、すなわち、その中で使用されるべき将来のアクセスエージェントのＩＰアドレス及び対応するマルチキャストチャネルを提供する。
【００５２】
一実施形態に基づく上記のハンドオーバメカニズムは、図３に概略的に示されているモバイルノードのシームレスモビリティを可能にする以下のインターフェース及びコンポーネントを含む。
【００５３】
−インターフェース
・移動を予測するモジュールと相互作用するためのインターフェース：基地局のロケーションと、ロケーション、移動方向及び速度といったモバイルノードの特性とに基づいて最も可能性のある次の基地局を検出する。
・キャッシュを含むアクセスエージェントと相互作用するためのインターフェース：これは、新しいハンドオーバプロトコルを構成するハンドオーバシグナリングメッセージを通じて実現される。このプロトコルは、マルチユーザセッションのコンテキストを元のアクセスエージェントから新たに予測されたアクセスエージェントへ転送し、新たに予測されたアクセスエージェントによって提供される機能及び接続性に関する情報を収集する。元のアクセスエージェントにおいては、アクセステクノロジーに関する情報とともにプローブされた情報が、（たとえば、セッションがより高い品質で、すなわち、より多数のフローを用いて到着し、モバイル機器と互換性のあるアクセステクノロジーを有する次のエージェントを選択することにより）ハンドオーバの決定をサポートする。
・セッションコントロールメカニズムと相互作用するためのインターフェース：ハンドオーバの決定が行われると、セッションコントロールメカニズムとの相互作用により、元のパス上で予約されたリソースを解放し、モバイルノードが使用する予定のない新たなパス上で予約されたリソースを解放するため、新たに予測されたアクセスエージェントへのセッションの転送が可能となる。
・マルチキャスト管理プロトコルとの相互作用するためのインターフェース：ハンドオーバ中に、モバイルノード内のハンドオーバメカニズムは、モバイルノードが元のアクセスポイント内のマルチキャストチャネルから離脱できるように、又は、新たなアクセスポイント内の正しいマルチキャストチャネルへ加入できるように、インターネットグループ管理プロトコル（ＩＧＭＰｖ３）又はマルチキャストリスナーディスカバリプロトコル（ＭＬＤｖ２）といったマルチキャスト管理プロトコルと相互作用する。
【００５４】
−コンポーネント
・キャッシュ：キャッシュはネットワーク内のエージェントにより転送されたパケットを記憶するために使用される。
・キャッシュ管理：キャッシュが容量に達すると、パケットを廃棄しなければならない。この状況では、到着した新たなパケットはキャッシュ内に記憶されている最も古いパケットと置き換えられる。
・バッファ：バッファはパケットを記憶するために使用される。バッファ内のデータはパケット損失を回避するためにハンドオーバ中に読み取られる。データが提供時よりも遅い速度でバッファから読み取られると、「バッファオーバーフロー」が起こる。逆の状況では、データが出るときより遅い速度でバッファに入ると、「バッファアンダーフロー」が発生する。
・バッファ管理：バッファ内に存在するパケットの個数及び特定を管理する役割を担う。これはバッファ内の利用可能な容量及び受信した最新のパケットを知るために必要である。
【００５５】
一実施形態に基づくハンドオーバシステムは、上記のコンポーネント及びインターフェースを使用する。このようなシステムは、キャッシュ及びキャッシュ管理をコンポーネントとして備えたアクセスエージェント内にハンドオーバモジュールを備えており、バッファ及びバッファ管理を含むモバイルノード内にハンドオーバモジュールを備えている。
【００５６】
アクセスエージェントと相互作用するインターフェース及び移動予測モジュールと相互作用するインターフェースは、アクセスエージェントのハンドオーバモジュール内にあり、セッションコントロールメカニズムと相互作用するインターフェース及びマルチキャスト管理プロトコルと相互作用するインターフェースはモバイルノード内に置くことができる。
【００５７】
上述のように、シームレスハンドオーバは、ユニキャスト通信又はマルチキャスト通信の何れかを使用するシングルユーザモバイルサービス及びマルチユーザモバイルサービスの展開に不可欠である。前述した実施形態により提案された新しいハンドオーバメカニズムは、異種のネットワーク内又は異種のネットワーク間においてハンドオーバ中のフローの中断を回避し、パケット損失を回避するキャッシング及びバッファリングのメカニズムを導入することにより、この問題を解決する。モバイルノード内にあるバッファは、ハンドオーバ中にデータ転送の継続を可能とするために使用される。アクセスエージェント内にあるキャッシュは、ハンドオーバ後にモバイルノードがハンドオーバ中に失われたパケットを回復するために使用される。強化されたメカニズムでは、バッファとキャッシュとを組み合わせた使用は、必要な状態の設定を保証するために最も可能性のある次のアクセスエージェントを予測する予測モジュールと関連している。
【００５８】
以下、ハンドオーバメカニズムのさらなる実施形態の動作を示す。
【００５９】
図４に示されているように、ハンドオーバが起こると（１）、モバイルノード内のアプリケーションはバッファ内に存在するパケットを通じて提供され続ける（２）。ハンドオーバが終了すると、モバイルノードは紛失したパケットをキャッシュからフェッチすることにより自己のバッファを更新する。これを実現するため、モバイルノードは、ハンドオーバ中に受信できなかったパケットを要求するフェッチ要求メッセージをキャッシュへ送信する（３）。メッセージを通して、バッファ内の利用可能な空き容量及び受信した最新のパケットのＩＤに関する情報が伝達される。
【００６０】
図５を参照すると、この場合、セッションがこのアクセスエージェントに既に存在することが仮定されている（４）。この仮定が正しくない場合、対象とするセッションに加入するために必要なステップの全てを続行する必要がある。フェッチ要求メッセージをキャッシュが受信すると、キャッシュから取り出してモバイルノードへ送信すべきデータ量は、紛失したパケットの個数、バッファ内の利用可能な空き容量、及びバッファ内で受信した最新のパケットのＩＤから計算される（５）。
【００６１】
その後、フェッチ応答メッセージが、送信される情報量をモバイルノードへ通知するためにモバイルノードへ送信される（６）。続いて、キャッシュは紛失したパケットをモバイルノードへ送信する。バッファの利用可能な空き容量が紛失したパケットを収容するために十分であるならば、プロセスは簡単である。しかし、バッファの利用可能な空き容量が、キャッシュに到着した新たなパケットの量よりも少ない場合、バッファ内に空きがない過剰なパケットを廃棄する必要がある。
【００６２】
以下、ハンドオーバメカニズムが、モバイルノードが移動する可能性が最も高いセル内に必要なリソースを予約するために予測メカニズムをサポートする実施形態について説明する。図６は、ユニキャストドメインからマルチキャストドメインへのハンドオーバがあり、モバイルノードがマルチユーザセッションの受信機であるときのハンドオーバメカニズムのオペレーションのシナリオを示している。現在のアクセスエージェント（ＡＡｇ）は、（例えば、リダクションメカニズムを参照することにより、又はリダクションメカニズムと協働して）現在のネットワークの外部にある基地局へのハンドオーバが実行されることを予測する。したがって、現在のアクセスエージェントは、将来のロケーションにおいてリソースを予約することが必要であるため、予測された基地局に関連付けられているアクセスエージェントとの接続を確立することを望む。リソースを予約するために、現在のアクセスエージェントは、予測されたアクセスエージェントのアドレスを発見しなければならない（図６のステップ１）。これは、同じネットワーク上の事前の構成によって、又は、様々なネットワーク間での取り決めに基づいて静的に行うことができる。代替的には、アドレスの発見はＤＮＳのようなサービスにクエリすることにより動的に行うこともできる。
【００６３】
次にリソースクエリメッセージは、新たなアクセスエージェントの候補へ送信される（図６のステップ２）。アクセスエージェントの各候補において、セッションに対してリソースを予約するためにセッションコントロール管理プロトコルがトリガされる（図６のステップ３）。セッションの識別表示はリソースクエリメッセージ内に存在する。
【００６４】
次に図７において、この情報が取得されると、予測されたアクセスエージェントは、リソース応答メッセージを生成し、要求を行ったアクセスエージェントに対してこのリソース応答メッセージを結果とともに送信する（図７のステップ５）。
【００６５】
Ｓ／Ｎ比及びアクセスエージェントの候補からの応答に基づいて、本実施例における現在のアクセスエージェントは、アクセスエージェントＥへハンドオーバすることに決定する（図７のステップ６）。この決定は、たとえば、Ｓ／Ｎ比及びリモートアクセスエージェントＤ及びＥからの応答に基づいている。ハンドオーバ（図７のステップ７）中に、パケットはキャッシュに到着し続け、バッファはアプリケーションに提供し続ける。モバイルノードが新たな基地局に到着したとき、アクセスエージェント内に位置するキャッシュから、その間に到着した新しいパケットを取得する必要がある（図７のステップ８）。モバイルノードは、キャッシュ内で利用できる損失したパケットをフェッチしてそのバッファを更新する。これを実現するため、フェッチ要求メッセージがアクセスエージェントＡＡｇへ送信される。このメッセージは、一実施形態では、（ＩＧＭＰ／ＭＬＤメッセージと同様に）到着中のマルチキャストパケットのフローのトリガも行う。
【００６６】
次に図８においては、フェッチ要求に対する新たなアクセスエージェントの応答について示されている。最初に、紛失したパケットの個数、及びバッファ内の利用可能な空き容量に依存して、キャシュから取り出されてモバイルノードへ送信されるべきデータ量が計算される。次に、フェッチ応答メッセージ及び紛失データがモバイルノードへ送信される（図８のステップ９）。
【図面の簡単な説明】
【００６７】
【図１】本発明の実施形態に基づくハンドオーバメカニズムを概略的に示す図である。
【図２】本発明の実施形態に基づくハンドオーバメカニズムのデータ転送を概略的に示す図である。
【図３】本発明の実施形態に基づくハンドオーバメカニズムを実行するため使用されるアクセスノード及びモバイルノードのコンポーネントを概略的に示す図である。
【図４】本発明のさらなる実施形態に基づくハンドオーバメカニズムを概略的に示す図である。
【図５】本発明のさらなる実施形態に基づくハンドオーバメカニズムを概略的に示す図である。
【図６】本発明のさらなる実施形態に基づくハンドオーバメカニズムを概略的に示す図である。
【図７】本発明のさらなる実施形態に基づくハンドオーバメカニズムを概略的に示す図である。
【図８】本発明のさらなる実施形態に基づくハンドオーバメカニズムを概略的に示す図である。
【図１】
2008054322.tif 000003
【図２】
2008054322.tif 000004
【図３】
2008054322.tif 000005
【図４】
2008054322.tif 000006
【図５】
2008054322.tif 000007
【図６】
2008054322.tif 000008
【図７】
2008054322.tif 000009
【図８】
2008054322.tif 000010
【外国語明細書】
2008054322.tif 000011
2008054322.tif 000012
2008054322.tif 000013
2008054322.tif 000014
2008054322.tif 000015
2008054322.tif 000016
2008054322.tif 000017
2008054322.tif 000018
2008054322.tif 000019
2008054322.tif 000020
2008054322.tif 000021
2008054322.tif 000022
2008054322.tif 000023
2008054322.tif 000024
2008054322.tif 000025
2008054322.tif 000026
2008054322.tif 000027
2008054322.tif 000028
2008054322.tif 000029
2008054322.tif 000030
2008054322.tif 000031
2008054322.tif 000032
2008054322.tif 000033
2008054322.tif 000034
2008054322.tif 000035
2008054322.tif 000036
2008054322.tif 000037
2008054322.tif 000038
2008054322.tif 000039
2008054322.tif 000040
2008054322.tif 000041
2008054322.tif 000042
2008054322.tif 000043