JP4794261B2 - ＲａｄｉｏＬｉｎｋＰｒｏｔｏｃｏｌ用のアクティブ・セッション・モビリティ・ソリューション - Google Patents

Description

本発明はモバイル通信システムに関し、より詳細には、高度に動的なインターネット・プロトコルベースのネットワーキング環境内でマルチメディア・アプリケーションをサポートするシステムにおけるモビリティ管理技術に関する。

コンピュータ・データ・ネットワーク内でのモバイル通信サービスの実施に対して、特に無線インターフェースを介してさまざまな接続ポイントにおいてデータ・ネットワークに日常的に接続するモバイル無線ノードへ通信コンテンツを回送する機能に対して、相当な注目が向けられてきた。これらには、携帯電話、携帯情報端末（ＰＤＡ）、ラップトップ・コンピュータ、および他のモバイル無線通信機器が含まれる。

データ・ネットワーク内でのモバイル無線通信サービスを容易にするには、モバイル無線ノードが、新たなネットワーク・アドレスを再び割り当てることなく自分のリンク層のネットワーク接続ポイントを変更できることが（常に可能とは限らないが）望ましい。モバイル機器全般用の現在のデータ・ネットワーク通信規格（たとえば、ＩＥＴＦ（Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ）によって推奨されている「Ｍｏｂｉｌｅ ＩＰ」規格や、ＥＴＳＩ（Ｅｕｒｏｐｅａｎ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ Ｓｔａｎｄａｒｄｓ Ｉｎｓｔｉｔｕｔｅ）によって提案されているＧＰＲＳ（Ｇｅｎｅｒａｌ Ｐａｃｋｅｔ Ｒａｄｉｏ Ｓｅｒｖｉｃｅ）規格）によれば、望ましいネットワーク・アドレスの透過性を提供する１つの方法は、「モビリティ・エージェント」を採用することである。これは、モバイル・ノードがネットワーク内を移動している際にモバイル・ノードのために通信コンテンツを回送するネットワーク・ルーティング・ノードである。たとえばＩＥＴＦのＭｏｂｉｌｅ ＩＰ規格によれば、モバイル・ノードのモビリティ・エージェントは、「ホーム・エージェント」ルーティング・ノードで構成することができ、また「フォーリン・エージェント」ルーティング・ノードを含むこともできる。ホーム・エージェントは、モバイル・ノードのサブネットワーク内のルーティング・ノードであり、モバイル・ノードの「ホーム・アドレス」によって示されるリンク上のネットワーク・インターフェースを維持する。この「ホーム・アドレス」は、モバイル・ノードに割り当てられて長い時間にわたってそのまま維持されることを意図するネットワーク・アドレスである。モバイル・ノードが自分のホーム・サブネットワークを離れている場合、ホーム・エージェントは、そのモバイル・ノードのホーム・アドレス宛ての通信コンテンツを傍受し、そのモバイル・ノードがフォーリン・サブネットワーク上に登録した際にそのモバイル・ノードに割り当てられた「気付」アドレスへ配信するためにその通信コンテンツをトンネルさせる。この気付アドレスは、フォーリン・サブネットワーク内のフォーリン・エージェント・ルーティング・ノードのアドレスとすることができる。

フォーリン・サブネットワークに登録したモバイル・ノードとの通信を希望する通信相手のノードは、その通信コンテンツをモバイル・ノードのホーム・アドレスに宛てることができる。その通信コンテンツは、透過的にモバイル・ノードの気付アドレスへトンネルされ、フォーリン・サブネットワーク上のモバイル・ノードへ配信される。通常のルーティングは、モバイル・ノードからの返信コンテンツを通信相手のノードへ送信するために使用することができる。

モバイル・ノードの通信をサポートするために使用されるいくつかのリンクレベル・プロトコルは、Ｐｏｉｎｔ−ｔｏ−Ｐｏｉｎｔ ｐｒｏｔｏｃｏｌおよびＲａｄｉｏ Ｌｉｎｋ Ｐｒｏｔｏｃｏｌを含む。ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）およびＰＰＰ（Ｐｏｉｎｔ−ｔｏ−Ｐｏｉｎｔ ｐｒｏｔｏｃｏｌ）など、非モバイル・アプリケーションで典型的に利用されるプロトコルは、３ＧＰＰ２（Ｔｈｉｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ ２）によって規定されているＲＬＰ（Ｒａｄｉｏ Ｌｉｎｋ Ｐｒｏｔｏｃｏｌ）などのより低位のモバイル・プロトコルの最上層に位置している。より詳細には、モバイル・ノードがインターネット上のゲートウェイに接続する際、通常はモバイル・ノードとゲートウェイ・デバイスの間でＰＰＰ（Ｐｏｉｎｔ−ｔｏ−Ｐｏｉｎｔ ｐｒｏｔｏｃｏｌ）セッションが確立される。当技術分野で知られているように、ＰＰＰは、シリアル通信リンクを介してネットワーク層のデータグラムをカプセル化するために使用される。ＰＰＰに関してより多くの情報を得るには、ＩＥＴＦ（Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ）のＲＦＣ（Ｒｅｑｕｅｓｔ ｆｏｒ Ｃｏｍｍｅｎｔｓ）、ＲＦＣ−１６６１、ＲＦＣ−１６６２、およびＲＦＣ−１６６３を参照されたい。これらについては、参照によってその全体を本明細書に組み込む。ゲートウェイ、またはトンネル・イニシエータは通常、トンネル・エンドポイント・サーバへのトンネル接続の確立を開始する。たとえばモバイル・ノードがフォーリン・エージェントに接続される場合、通常はＬ２ＴＰ（Ｌａｙｅｒ ２ Ｔｕｎｎｅｌｉｎｇ Ｐｒｏｔｏｃｏｌ）のトンネルなどのコネクション型のポイントツーポイント通信リンクが、フォーリン・エージェントとホーム・エージェントの間で確立され、モバイル・ノードとの間でデータの転送が可能となる。Ｌ２ＴＰ（Ｌａｙｅｒ Ｔｗｏ Ｔｕｎｎｅｌｉｎｇ Ｐｒｏｔｏｃｏｌ）、ＲＦＣ（Ｒｅｑｕｅｓｔ ｆｏｒ Ｃｏｍｍｅｎｔ）２６６１、Ａ．Ｖａｌｅｎｃｉａ他、１９９９年６月を参照されたい。これについては、参照によってその全体を本明細書に組み込む。

無線環境では、ＲＬＰ（Ｒａｄｉｏ Ｌｉｎｋ Ｐｒｏｔｏｃｏｌ）によって、使用されている特定の無線伝送メディア用に高度に最適化された信頼性の高いエンドツーエンドの伝送が一般的に提供される。ＲＬＰプロトコルの例は、（ＣＤＭＡ用の）ＴＩＡ／ＥＩＡ ＩＳ−７０７および（ＴＤＭＡ用の）ＩＳ−１３５において見受けられる。ＲＬＰは、信頼性の高いリンク・プロトコルであり、コントロール・パケットまたは新しいデータ・パケットおよび再送されたデータ・パケットが失われた場合、それらをリンクのソースから宛先へ再送することができる。このスキームによって、送信者は、応答のないパケットまたは否定的に応答されたパケットを、より高層のプロトコルによるエンドツーエンドの再送に依存するのではなく、そのリンク層において機先を制して再送することができる。このスキームは、エンドツーエンドの再送およびトランスポート層のタイムアウトを防止するため、パフォーマンスを効率よく改善することができる。上述のルーティング・メカニズムは、無線インターフェースを介してフォーリン・サブネットワークに接続されたモバイル無線ノード用に使用することもできる。しかしモバイル無線ノードがデータ・ネットワークを介した通信中に活発に移動しており、１つの無線基地局から別の無線基地局への通信のハンドオフが必要となる場合に、問題が生じる可能性がある。この場合、古い基地局は１つのフォーリン・エージェントにリンクされており、新しい基地局は別のフォーリン・エージェントにリンクされていることがある。そして通信のハンドオフは、通信をトンネルさせるエンドポイントが古い気付アドレスから新しい気付アドレスへ移ることを要求する。

このためにギャップが生じ、通信コンテンツのタイムリーな配信が阻害される場合があり、これによって特に音声通話用の通信品質が低下する可能性がある。このようなギャップは、ハンドオフの厳密な時間を確定する上でデータ・ネットワークが無線インターフェースとうまく連携できないために生じる。ハンドオフの時点と、ホーム・エージェントが通信コンテンツを新しい気付アドレスへ回送し始める時点の間で、遅延が生じる可能性がある。
ＩＥＴＦ（Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ）のＲＦＣ（Ｒｅｑｕｅｓｔ ｆｏｒ Ｃｏｍｍｅｎｔｓ）、ＲＦＣ−１６６１、ＲＦＣ−１６６２、およびＲＦＣ−１６６３ Ｌ２ＴＰ（Ｌａｙｅｒ Ｔｗｏ Ｔｕｎｎｅｌｉｎｇ Ｐｒｏｔｏｃｏｌ）、ＲＦＣ（Ｒｅｑｕｅｓｔ ｆｏｒ Ｃｏｍｍｅｎｔ）２６６１、Ａ．Ｖａｌｅｎｃｉａ他、１９９９年６月 本願の譲受人に譲渡された「Ａ ｗｉｒｅｌｅｓｓ ｃｏｍｍｕｎｉｃａｔｉｏｎｓ ｓｙｓｔｅｍ ｅｍｐｌｏｙｉｎｇ ａ ｎｅｔｗｏｒｋ ａｃｔｉｖｅ ｓｅｔ ｆｏｒｍｅｄ ｆｒｏｍ ｂａｓｅ ｓｔａｔｉｏｎｓ ｏｐｅｒａｂｌｅ ａｓ ｐｒｉｍａｒｙ ａｎｄ ｓｅｃｏｎｄａｒｙ ａｇｅｎｔｓ」という名称の米国特許出願

したがって、通信コンテンツを失うことなく通信のハンドオフを改善したサービスをモバイル無線ノードに提供するデータ・ネットワーク通信システムに対するニーズがある。ハンドオフ中に通信コンテンツをシームレスに回送することによって、もしあるとしても無線インターフェースによって生じるもの以外に顕著な通信コンテンツの喪失や遅延をモバイル無線ノードが経験することのないシステムおよび方法が必要とされている。

本発明は、Ｒａｄｉｏ Ｌｉｎｋ Ｐｒｏｔｏｃｏｌなどの信頼性の高いプロトコル用のシームレスなアクティブ・セッション移行ソリューションを提供することによって、従来技術のさまざまな欠陥に対処する。

本発明の一実施形態では、無線ＩＰネットワーク内のソースからターゲットへＲａｄｉｏ Ｌｉｎｋ Ｐｒｏｔｏｃｏｌのアクティブ・セッションをシームレスに移行するための方法は、Ｒａｄｉｏ Ｌｉｎｋ Ｐｒｏｔｏｃｏｌを少なくともフォワードリンク状態とリバースリンク状態に分離する工程と、移行の第１ステージで少なくともフォワードリンク状態をソースからターゲットへ移行する工程と、移行の第２ステージで少なくともリバースリンク状態をソースからターゲットへ移行する工程とを含む。

本発明の代替実施形態では、分離されたＲａｄｉｏ Ｌｉｎｋ Ｐｒｏｔｏｃｏｌの移行の第１ステージは、Ｒａｄｉｏ Ｌｉｎｋ Ｐｒｏｔｏｃｏｌのフォワードリンク状態がソースからターゲットへ間もなく移行されることを示す信号をソースへ、およびターゲットへ送信する工程と、その信号がソースによって受信されると、ソースによってセグメント化されたフォワードリンク・データをターゲットへトンネルさせる工程であって、そのセグメント化されたデータがターゲットによってアクセス端末へ伝達される工程と、ターゲットがＲａｄｉｏ Ｌｉｎｋ Ｐｒｏｔｏｃｏｌのフォワードリンク状態の移行をソースから受け取る準備が整ったことを示す肯定応答をターゲットからソースへ送信する工程と、その肯定応答がソースによって受信されると、事前にセグメント化されたフォワードリンク・データをソースからターゲットへトンネルさせて、ターゲットによってセグメント化し、ターゲットによってアクセス端末へ伝達する工程とを含む。

本発明の代替実施形態では、分離されたＲａｄｉｏ Ｌｉｎｋ Ｐｒｏｔｏｃｏｌの移行の第２ステージは、フレーム選択がターゲットによって実行されることを示す信号をソースから少なくともターゲットへ送信する工程と、次に予想されるリバースリンク・オクテットのシーケンス番号をソースからターゲットへ送信する工程と、次に予想されるリバースリンク・オクテットのシーケンス番号よりも小さいシーケンス番号を有するリバースリンク・オクテットをソースへ転送して、ソースによってセグメント化し、ホーム・エージェントへ伝達する工程と、次に予想されるリバースリンク・オクテットのシーケンス番号よりも大きいかまたは等しいシーケンス番号を有するリバースリンク・オクテットをターゲットへ転送して、ターゲットによってセグメント化し、ホーム・エージェントへ伝達する工程とを含む。

本発明の教示は、以降の詳細な説明を添付の図面と併せて考察することによって、容易に理解することができる。
理解を容易にするために、複数の図に共通する同一の要素を指す上では、可能な限り同一の参照番号を使用している。

本発明は、ＲＬＰ（Ｒａｄｉｏ Ｌｉｎｋ Ｐｒｏｔｏｃｏｌ）などの信頼性の高いプロトコル用のシームレスなアクティブ・セッション・モビリティ・ソリューションを提供できる点が有利である。本明細書では、本願の譲受人に譲渡された「Ａ ｗｉｒｅｌｅｓｓ ｃｏｍｍｕｎｉｃａｔｉｏｎｓ ｓｙｓｔｅｍ ｅｍｐｌｏｙｉｎｇ ａ ｎｅｔｗｏｒｋ ａｃｔｉｖｅ ｓｅｔ ｆｏｒｍｅｄ ｆｒｏｍ ｂａｓｅ ｓｔａｔｉｏｎｓ ｏｐｅｒａｂｌｅ ａｓ ｐｒｉｍａｒｙ ａｎｄ ｓｅｃｏｎｄａｒｙ ａｇｅｎｔｓ」という名称の特許出願に記載されている基地局ルータ（ＢＳＲ）に基づくフラットなネットワーク・アーキテクチャ内で使用されているＲＬＰプロトコルとの関連から、本発明のさまざまな実施形態について説明するが、本発明の具体的な実施形態は、本発明の範囲を限定するものとして扱うべきではない。本発明のアクティブ・セッション・モビリティ・ソリューションは、ＲＬＰを実装する従来のＣＤＭＡ階層型ネットワークや、ＲＬＣ（ｒａｄｉｏ ｌｉｎｋ ｃｏｎｔｒｏｌ）プロトコルを実装するＧＰＲＳ（Ｇｅｎｅｒａｌ Ｐａｃｋｅｔ Ｒａｄｉｏ Ｓｅｒｖｉｃｅ）モデルに基づくＵＭＴＳネットワークなど、信頼性の高いプロトコルを実装するほぼすべてのネットワークにおいて実施できる点が有利であることを当業者なら理解するであろうし、また本発明の教示からも分かるであろう。

本発明のさまざまな実施形態の実装に関連するさまざまなＭｏｂｉｌｅ ＩＰプロトコルの説明を補助するために、本発明者は、本明細書において従来の階層型ＣＤＭＡ無線ＩＰネットワークを示している。図１は、従来のＣＤＭＡ階層型無線ＩＰネットワークのハイ・レベル・ブロック図を示している。図１の階層型ＣＤＭＡネットワーク１００は、アクセス端末（ＡＴ）１１０、基地局（ＢＴＳ）１１５、ＲＡＮルータ１２０、無線ネットワーク・コントローラ（ＲＮＣ）１２５、ＰＤＳＮ１３０、ＩＰネットワーク１４０、およびインターネット・サービス・プロバイダ（ＩＳＰ）１４５を含む。図１のＣＤＭＡネットワーク１００は、ＲＡＤＩＵＳ ＡＡＡ（Ａｕｔｈｅｎｔｉｃａｔｉｏｎ， Ａｕｔｈｏｒｉｚａｔｉｏｎ， ａｎｄ Ａｃｃｏｕｎｔｉｎｇ）サーバ１３５をさらに示しているが、このＡＡＡサーバ１３５は、ＣＤＭＡネットワーク１００の完全な表示を提供するために示されているにすぎない。ＡＡＡサーバ１３５の機能は、本発明の概念にとって補助的なものであるため、本明細書では、ＡＡＡサーバ１３５については説明しない。

図１の階層型ＣＤＭＡネットワーク１００では、ＢＴＳ１１５は、無線インターフェースを介してＡＴ１１０へインターフェースで接続する機能を実行する。これは、無線インターフェースを実装するのに必要なデジタル信号処理を実行し、バックエンド・サーバおよびルータと通信するためのハードウェアおよびソフトウェアを含む。ＨＣＳ１１５はまた、信号を無線で送信し、ＲＦ信号をＡＴ１１０から受信するのに必要なＲＦコンポーネントを含む。

ＲＡＮルータ１２０は、複数のＢＴＳからの帰路インターフェースが終了できるＣＤＭＡネットワーク１００内の共通のポイントを提供する。この機能は、無線インターフェースから受信した情報をセッション用のコントロール・ポイントへ回送できるために必要であり、このポイントで、フレーム選択を実行することができる。ＲＡＮルータ１２０によって、グローバルなインターネットにおいてＢＴＳとＩＳＰ１４５の間でデータを回送することもできる。

ＲＮＣ１２５は、それぞれのセッションごとに信号伝達およびトラフィック処理の制御を提供する。これらの機能は、セッションの確立および解除、フレーム選択、ならびにＲＬＰ（Ｒａｄｉｏ Ｌｉｎｋ Ｐｒｏｔｏｃｏｌ）の処理を含む。前述のように、ＲＬＰは、たとえばＡＴ１１０とＲＮＣ１２５の間の信頼性の高いリンク・プロトコルであり、コントロール・パケットまたは新しいデータ・パケットおよび再送されたデータ・パケットが失われた場合、それらをリンクのソースから宛先へ再送することができる。このスキームによって、送信者は、応答のないパケットまたは否定的に応答されたパケットを、より高層のプロトコルによるエンドツーエンドの再送に依存するのではなく、そのリンク層において機先を制して再送することができる。このスキームは、エンドツーエンドの再送およびトランスポート層のタイムアウトを防止するため、パフォーマンスを効率よく改善することができる。ＲＮＣ１２５は、ＰＤＳＮ１３０への標準的なインターフェース用の処理を提供し、ＰＤＳＮ１３０へインターフェースで接続するための機能をＲＮＣに与える。ＲＮＣ１２５は、無線ネットワークのすべてのモビリティ管理機能を終了し、無線ネットワークと、最終的にＩＳＰ１４５と通信するＩＰネットワーク１４０の間の分界点である。

ＰＤＳＮ１３０は、ＰＰＰ（Ｐｏｉｎｔ−ｔｏ−Ｐｏｉｎｔ ｐｒｏｔｏｃｏｌ）を終了し、および／またはＬ２ＴＰのインターネット・アクセスが使用されている場合はＬＮＳ（Ｌａｙｅｒ ２ Ｔｕｎｎｅｌ Ｐｒｏｔｏｃｏｌ Ｎｅｔｗｏｒｋ Ｓｅｒｖｅｒ）へのトンネルを作成する。ＰＤＳＮ１３０はサービング・ネットワーク内に常駐し、ＡＴ１１０がサービス・セッションを開始する際にサービング・ネットワークによって割り当てられる。ＰＤＳＮ１３０は、常駐しているＰＰＰリンク・プロトコルをＡＴ１１０と共に終了する。ＰＤＳＮ１３０は、ネットワーク１００内でフォーリン・エージェント（ＦＡ）として機能する。ＰＤＳＮ１３０はリンク層の情報を維持し、外部のパケット・データ・ネットワークへ、またはホーム・エージェント（ＨＡ）へトンネルさせる場合はＨＡへパケットを回送する。ＰＤＳＮ１３０はまた、バックボーンＩＰネットワーク１４０へのインターフェースを維持する。

ＰＤＳＮ１３０は、ＰＤＳＮ１３０とのアクティブ・セッションを有するすべてのＡＴ用にサービング・リストおよび一意のリンク層識別子を維持する。ＰＤＳＮ１３０は、この一意のリンク層識別子を使用して、ＰＤＳＮ１３０に接続されているそれぞれのＡＴを参照し、ＡＴのＩＰアドレスと、ＨＡアドレスおよびリンク識別子との関連付けを維持する。ＡＴ１１０が休止状態の場合でさえ、ＰＤＳＮ１３０においてリンク層の関連付けが維持される。ＡＴ１１０が、別のＲＮＣ１２５によるサービスを受ける場所に移動すると、ＰＤＳＮ１３０は新しいサービングＲＮＣと対話して、ＡＴ１１０がアクティブ・セッションを有していたＲＮＣからのハンドオフを容易にする。

上記の図１のＣＤＭＡネットワーク１００の階層型アーキテクチャとは対照的に、本願の譲受人に譲渡された「Ａ ｗｉｒｅｌｅｓｓ ｃｏｍｍｕｎｉｃａｔｉｏｎｓ ｓｙｓｔｅｍ ｅｍｐｌｏｙｉｎｇ ａ ｎｅｔｗｏｒｋ ａｃｔｉｖｅ ｓｅｔ ｆｏｒｍｅｄ ｆｒｏｍ ｂａｓｅ ｓｔａｔｉｏｎｓ ｏｐｅｒａｂｌｅ ａｓ ｐｒｉｍａｒｙ ａｎｄ ｓｅｃｏｎｄａｒｙ ａｇｅｎｔｓ」という名称の特許出願では、フラットなネットワーク・アーキテクチャが提案されており、これは、ＲＮＣおよびＰＤＳＮの機能をセル・サイトの装備と共に、インターネットへ直接接続する１つのネットワーク要素に組み込む。したがってこの概念は、従来の階層型ネットワークを展開すること、および既に展開されているネットワークに新しい無線アクセス・ポイント（セル・サイト）を追加することに伴うコストおよび複雑さを軽減できる可能性を有している。こうしたフラットなネットワークでは、集中化されたＲＮＣの機能および集中化されたＰＤＳＮの機能がセル・サイトの装備に組み込まれるため、従来のネットワーク・アーキテクチャに比べて展開コストが軽減される。またＰＤＳＮおよびＲＮＣにおけるパケット待機の遅延が除去されるため、無線ユーザが経験する遅延を軽減できる可能性もある。こうしたフラットなアーキテクチャは、ＢＳＲ（Ｂａｓｅ−Ｓｔａｔｉｏｎ−Ｒｏｕｔｅｒ）タイプのネットワーク・アーキテクチャと呼ばれる。

たとえば図２は、本発明の一実施形態を適用できる新奇なＢＳＲ（Ｂａｓｅ−Ｓｔａｔｉｏｎ−Ｒｏｕｔｅｒ）タイプのネットワーク・アーキテクチャのハイ・レベル・ブロック図を示している。このようなＢａｓｅ−Ｓｔａｔｉｏｎ−Ｒｏｕｔｅｒタイプのネットワーク・アーキテクチャは、本願の譲受人に譲渡された「Ａ ｗｉｒｅｌｅｓｓ ｃｏｍｍｕｎｉｃａｔｉｏｎｓ ｓｙｓｔｅｍ ｅｍｐｌｏｙｉｎｇ ａ ｎｅｔｗｏｒｋ ａｃｔｉｖｅ ｓｅｔ ｆｏｒｍｅｄ ｆｒｏｍ ｂａｓｅ ｓｔａｔｉｏｎｓ ｏｐｅｒａｂｌｅ ａｓ ｐｒｉｍａｒｙ ａｎｄ ｓｅｃｏｎｄａｒｙ ａｇｅｎｔｓ」という名称の米国特許出願に記載されており、これについては、その全体を参照によって本明細書に組み込む。図２のＢＳＲネットワーク２００は、具体例としてアクセス端末（ＡＴ）２１０（本明細書ではモバイルとも呼ぶ）、複数の基地局ルータ（ＢＳＲ）（たとえば３つのＢＳＲ）２２０_１〜２２０_３、コア・ネットワーク２３０、ホーム・エージェント（ＨＡ）２４０、およびＩＰインターネット２５０を含む。図２のＢＳＲネットワーク２００では、従来のＩＰネットワークとは異なり、通信許可の制御、ＣＤＭＡコード・ツリーの管理、およびページング制御などの無線ネットワーク制御機能は、それぞれの基地局ルータ２２０_１〜２２０_３内に含まれる。より詳細には、単一の無線ネットワーク・コントローラ（ＲＮＣ）が、制御対象の基地局のセットのすべてのモバイルに対してリソース管理を行う従来のＩＰネットワーク・アーキテクチャとは異なり、基地局ルータ２２０_１〜２２０_３のうちの別々の基地局ルータは、別々のモバイル用の第１エージェント（ＰＡ）として機能することができる。図２のＢＳＲネットワーク２００では、コア・ネットワーク２３０は、ＢＳＲ２２０_１〜２２０_３の間でデータ・パケットの効率的かつタイムリーな配信を保証するように機能する。コア・ネットワーク２３０はまた、ＨＡ２４０に向けたＢＳＲ２２０_１〜２２０_３からのリバース・リンク・データをＩＰインターネット２５０に伝達するように動作し、ＩＰインターネット２５０は、そのデータをＨＡ２４０へ転送する。フォワード・リンク方向では、コア・ネットワーク２３０は、ＩＰインターネット２５０を介してＨＡ２４０から受信したモバイル２１０に向けたデータをＢＳＲ２２０_１〜２２０_３に伝達するように機能する。

図２のＢＳＲネットワーク２００では、モバイル２１０は、モバイル２１０のネットワーク・アクティブ・セット（ＮＡＳ）を含む３つのＢＳＲ２２０_１〜２２０_３と通信状態にある。変わりゆく無線状況に基づいて、モバイル２１０は、そのＮＡＳ内の任意のＢＳＲからデータを受信することを選択することができる。切り替えは、迅速なタイム・スケールで発生する場合がある。ＮＡＳ内では、ＢＳＲ２２０_１〜２２０_３の１つは、第１エージェント（ＰＡ）として機能し、その一方で他のＢＳＲは、第２エージェント（ＳＡ）として機能することができる。ＰＡは、モビリティおよび無線リソースの管理にとって要として機能し、従来の階層型ネットワーク・アーキテクチャにおけるＲＮＣと同様の機能を果たす。上述の新奇なＢＳＲネットワーク・アーキテクチャによって、ＩＰネットワーク内で必要とされるコンポーネントの数が大幅に削減され、したがってＩＰネットワークに関連するコストも大幅に削減されるが、このようなＢＳＲネットワーク・アーキテクチャでは、ネットワーク全域にわたってアクセス端末が移動することによって、基地局ルータ間でより多くのハンドオフが存在し、そのようなものとして、効率のよいＲＬＰ用のアクティブ・セッション・モビリティ・ソリューションに対するニーズが存在する。すなわちＢＳＲアーキテクチャでは、それぞれのＢＳＲは、基地局、ＲＮＣ、およびＰＤＳＮとして機能する。ＡＴは、ＢＳＲノード間を移動すれば、事実上、ＲＮＣ間を移動することになる。したがってＡＴの通信状態は、アクティブな状態で移動することができる。段階的な状態移動アプローチを選択して、新しいＢＳＲへのシームレスなハンドオフを可能にすることができ、ＢＳＲ間のインターフェースを使用して、移動中にＢＳＲ間で情報をトンネル、制御、およびやり取りする。

従来のＣＤＭＡシステムと同様に、図２のＢＳＲネットワーク２００では、ＢＳＲ２２０_１〜２２０_３のアクティブ・セットの付近で電源を入れるモバイルは、ＢＳＲ２２０_１〜２２０_３のそれぞれからパイロット信号を受信し、最も強い信号の発信元である基地局と通信するためのアクセス・チャネルを使用して、セッションを開始する。前述のように、最も強い信号を有する選択されたＢＳＲ（まずはたとえばＢＳＲ２２０_１）は、第１エージェント（ＰＡ）、およびそのようなものとしてモバイル２１０用のアクセス・ポイントとして機能する。図２のＢＳＲネットワーク２００では、ＢＳＲ２２０_１はソースＢＳＲとみなされ、通常は従来の階層型ネットワーク・アーキテクチャの基地局内に維持されている無線基地局のＭＡＣプロトコル、通常は従来の階層型ネットワーク・アーキテクチャのＲＮＣ内に維持されているＲＬＰプロトコル、ならびに通常は従来の階層型ネットワーク・アーキテクチャのデータ・ノード（ＰＤＳＮ）にサービスを提供するパケット内に維持されているＰＰＰ（ｐｏｉｎｔ−ｔｏ−ｐｏｉｎｔ）プロトコルを最初に終了する。

図３は、ＢＳＲ２２０_１がモバイル２１０用のＰＡ（ソースＢＳＲ）として機能している初期状態における図２のＢＳＲネットワーク２００のハイ・レベル機能図を示している。図３のＢＳＲ２２０_１は、具体例としてＭＡＣ／スケジューラ機能ブロック（ＭＡＣ／ＳＣＨ_１）、ＲＬＰ機能ブロック（ＲＬＰ_１）、ＰＰＰ機能ブロック（ＰＰＰ_１）、およびＦＡ機能ブロック（ＦＡ_１）を含む。同様に、図３のＢＳＲ２２０_２は、具体例としてＭＡＣ／スケジューラ機能ブロック（ＭＡＣ／ＳＣＨ_２）、ＲＬＰ機能ブロック（ＲＬＰ_２）、ＰＰＰ機能ブロック（ＰＰＰ_２）、およびＦＡ機能ブロック（ＦＡ_２）を含む。

本発明のさまざまな実施形態によれば、ＲＬＰなどの信頼性の高いプロトコルは、フォワードリンクＲＬＰ（Ｆ−ＲＬＰ）コンポーネントとリバースリンクＲＬＰ（Ｒ−ＲＬＰ）コンポーネントに分離される。本明細書に記載されている本発明の実施形態では、Ｆ−ＲＬＰは、ＨＡ２４０からモバイル２１０へのデータ・フローの方向とみなされ、Ｒ−ＲＬＰは、モバイル２１０からＨＡ２４０へのデータ・フローの方向とみなされる。少なくとも図３のＲＬＰ用のシームレスなアクティブ・セッション・モビリティ・ソリューションの実施形態では、ＢＳＲ移行戦略の構成要素は、ＢＳＲ（はじめはソースＢＳＲ２２０_１）にサービスを提供する際にＦ−ＲＬＰとＭＡＣ／スケジューラを同じ場所に配置したまま維持して、スケジューリングの効率性を活用し、ＦＡ、およびそのようなものとしてＰＰＰエンドポイントの余分な移動を伴う時間のかかるＭｏｂｉｌｅ ＩＰ登録を回避し、データフローの中断を最小限にとどめ、その間中、トンネリングを介した帰路の利用を低いレベルに抑えることである。

すなわち最初は、フォワードリンク・データおよびリバースリンク・データのすべての処理は、同一のＢＳＲ２２０_１上に配置される。時間のかかるホーム・エージェントへのＭｏｂｉｌｅ ＩＰ登録を回避するために、ＢＳＲの移動は、ＲＬＰの個々のＢＳＲコンポーネント（たとえばＦ−ＲＬＰとＲ−ＲＬＰ）を別々のステージで移動することによって実現される。ＲＬＰのコンポーネントがターゲットＢＳＲへ移行するにつれて、処理は複数のＢＳＲ間で分割され、データのトンネリングを実行しなければならない。モビリティは、当然のこととして期待される条件であるため、トンネリングは、コンポーネントが新しいＢＳＲへ移行する際に実行されていなければならない。余分な帰路の利用を最小限にとどめるために、トンネリングは最小限に抑えなければならない。

Ｒ−ＲＬＰに関しては、フレーム・セレクタの位置は、帰路の利用に影響を与えない。フレーム・セレクタがどのＢＳＲに常駐していようとも、アクティブ・セット内の他のＢＳＲはすべて、フレーム・セレクタを有するＢＳＲ（はじめはソースＢＳＲ２２０_１）へ自分のリバースリンク・フレームをトンネルさせなければならない。Ｆ−ＲＬＰ方向におけるスケジューリングの効率性を維持するには、ＲＬＰをＭＡＣ／スケジューラと同じ位置に配置したまま維持すると、最大の利点が得られる。モバイル２１０は、新しいサービングＢＳＲ（すなわちＢＳＲ２２０_２）を選択すると、その新しいＢＳＲのＭＡＣ／スケジューラ（すなわちＭＡＣ／ＳＣＨ_２）を通じてデータを提供される。フレーム・セレクタとＦ−ＲＬＰが共にＢＳＲ２２０_２へ移動すると、Ｒ−ＲＬＰのデータをＢＳＲ２２０_１のＰＰＰおよびＦＡへ返信するためのトンネルが必要となる。このデータフローは、（ＰＰＰからＲＬＰへトンネルされる）Ｆ−ＲＬＰのデータフローと（ＭＡＣからフレーム・セレクタへトンネルされる）Ｒ−ＲＬＰのデータフローに加えてのものである。そのようなものとして、これは好ましい方法ではない。別々に移動するフォワード・リンクおよびリバースリンクのＲＬＰコンポーネントについては、頻繁な発生が予想されるＦ−ＲＬＰの移動は、モバイル２１０がサービングＭＡＣ／スケジューラと共に新しいＢＳＲへ移動するのに伴って発生する。これは、Ｆ−ＲＬＰとＭＡＣ／スケジューラを同じ位置に配置することによって、スケジューリングの効率性の達成を可能にする。Ｒ−ＲＬＰがＰＰＰおよびＦＡと共に移動する頻度は低く、したがって、費用のかさむＭｏｂｉｌｅ−ＩＰ登録およびＰＰＰの再ネゴシエーションは少なくなる。

たとえば図４は、モバイル２１０がＢＳＲ２２０_２からＢＳＲ２２０_１（ソースＢＳＲ）よりも強い信号を受信し始め、ＢＳＲ２２０_２（ターゲットＢＳＲ）からのそのデータを受信することを選択したときの状態における図２のＢＳＲネットワーク２００のハイ・レベル機能図を示している。すなわち図４は、ＢＳＲ２２０_１からＢＳＲ２２０_２へのハンドオフ中のＢＳＲ２２０_１〜２２０_２を示している。図４の本発明の実施形態では、Ｆ−ＲＬＰは、新しいＢＳＲ２２０_２がサービングＢＳＲになると（すなわちデータ転送速度制御チャネル（ＤＲＣ）などのハンドオフ通知が、それを指し示すと）、すぐに新しいサービングＢＳＲ２２０_２へ移動する。これは、モバイル２１０からの要求に応じてＭＡＣ層のデータを拒否しないという目標に沿ったものである。

本発明の一実施形態によるＲＬＰの移行は、Ｆ−ＲＬＰの移行によって開始する。はじめに移行の前には、Ｆ−ＲＬＰはソースＢＳＲ２２０_１上に存在する。ソースＢＳＲ２２０_１は、ＰＰＰ（ＰＰＰ_１）から着信する新しいデータ・オクテット、データ内の行方不明のオクテット用に処理される否定応答メッセージ（ＮＡＫ）、およびモバイル２１０へ無線で送信するためにＭＡＣ／スケジューラ（ＭＡＣ／ＳＣＨ_１）へ送信されているＲＬＰフレームなどのフォワードリンク・トラフィックのタスクをすべて処理している。ソースＢＳＲ２２０_１とターゲットＢＳＲ２２０_２の間でハンドオフが発生することを示す第１の兆候は、データ・ソース制御チャネル（ＤＳＣ）やＤＲＣなどの信号を介してハンドオフ要求を示す通知をモバイルから受信することである。ＤＳＣを受信すると、ソースＢＳＲ２２０_１およびターゲットＢＳＲ２２０_２は、モバイル２１０がターゲットＢＳＲ２２０_２によるサービスの提供を望んでいることに気づく。

早期ハンドオフ通知（すなわち、これはＤＳＣインジケータの形態をとることができる）を活用する本発明の一実施形態では、ソースＢＳＲ２２０_１およびターゲットＢＳＲ２２０_２は、ソースＦ−ＲＬＰ（ＲＬＰ_１）へのすべての着信オクテットを複製し、複製したオクテットをターゲットＲＬＰ（ＲＬＰ_２）へトンネルさせ、この際、トンネル内の第１パケットの開始シーケンス番号を共にトンネルさせて、ターゲットＢＳＲ２２０_２のバッファ内に保存することによって、Ｆ−ＲＬＰの移動に備える。ソースＦ−ＲＬＰ（ＲＬＰ_１）はまた、そのバッファに保存されたオクテットのコピーをターゲットＲＬＰ（ＲＬＰ_２）へ送信し、これによって、Ｆ−ＲＬＰがターゲットＲＬＰ（ＲＬＰ_２）へ移行されると、ターゲットＲＬＰ（ＲＬＰ_２）は、いかなるオクテットを失うこともなく、また順番の異なるオクテットを送信することもなく、そのデータをモバイル２１０へ送信することができる。ターゲットＲＬＰ（ＲＬＰ_２）は、移行のプレサービング・ステージにあるとみなされる。さらに本発明のさまざまな実施形態では、複製されたオクテットのコピー、開始シーケンス番号、およびバッファに保存されたオクテットのコピーをターゲットＲＬＰ（ＲＬＰ_２）へトンネルさせると共に、ソースＦ−ＲＬＰ（ＲＬＰ_１）はまた、モバイル２１０への情報の流れが行き詰るのを防止するために、ターゲットＲＬＰ（ＲＬＰ_２）にも並行してＲＬＰの状態の移行を伝える。

早期ハンドオフ通知（たとえばＤＳＣ）の送信後、ハンドオフ通知（すなわちデータ転送速度制御チャネル（ＤＲＣ）など）が、アクティブ・セット内のすべてのＢＳＲに伝達される。ＤＲＣは、新しいサービングＢＳＲがターゲットＢＳＲ２２０_２であることを示す。あるいはＤＲＣの表示がすべてのＢＳＲに伝達されるのではなく、新しいサービングＢＳＲがターゲットＢＳＲ２２０_２であることを示す表示が、早期ハンドオフ通知（たとえばＤＳＣ）の終了によって影響を受ける場合もある。そのようなものとして、ＤＲＣ、あるいは早期通知（たとえばＤＳＣ）の終了は、新しいサービングＢＳＲがターゲットＢＳＲ２２０_２であることを示す。ターゲットＢＳＲ２２０_２がサービングＢＳＲになると、ソースＢＳＲ２２０_１は、最終バイトのシーケンス番号Ｖ（Ｓ_Ｌ）をターゲットＢＳＲ２２０_２へ送信する。この最終バイトのシーケンス番号Ｖ（Ｓ_Ｌ）は、ソースＢＳＲ２２０_１によってセグメント化された最後のオクテットを示す。Ｆ−ＲＬＰの処理（データのセグメント化）は、最終バイトのシーケンス番号Ｖ（Ｓ_Ｌ）を有するオクテットの後のオクテットが発生すると、ターゲットＢＳＲ２２０_２において開始する。あるいはターゲットＢＳＲ２２０_２はコピーを受信し、ソースＢＳＲ２２０_１のバッファによって受信されてその中に保持されているオクテットのすべてのステータスを知らされるため、Ｆ−ＲＬＰの処理は、ハンドオフ通知が受信されるか、または早期ハンドオフ通知が終了すると、すぐにターゲットＢＳＲ２２０_２内で開始する場合もある。

オクテットのコピーを転送することに加えて、ソースＢＳＲのＲＬＰ（ＲＬＰ_１）は、バッファに保存されたすべてのＮＡＫをターゲットＢＳＲ２２０_２のＲＬＰ（ＲＬＰ_２）へ転送する。そのようなものとして、失われたオクテットを再送するために作成されたすべてのＮＡＫに対して、ターゲットＢＳＲ２２０_２によってサービスを提供することができる。したがってソースＲＬＰ（ＲＬＰ_１）は、サービスを提供する立場ではなくなり、モバイル２１０は、ターゲットＲＬＰ（ＲＬＰ_２）からフォワードリンク・データを提供される。そのようなものとして、今度はフォワードリンク方向では、ＨＡ２４０はフォワードリンク・データをソースＢＳＲ２２０_１のＦＡ（ＦＡ_１）へ送信する。次いでソースＦＡ（ＦＡ_１）は、そのフォワードリンク・データをソースＢＳＲ２２０_１のＰＰＰ（ＰＰＰ_１）へ送信し、ソースＢＳＲ２２０_１のＰＰＰ（ＰＰＰ_１）は、そのフォワードリンク・データをターゲットＢＳＲ２２０_２のＰＰＰ（ＰＰＰ_２）へトンネルさせる。そしてターゲットＰＰＰ（ＰＰＰ_２）は、そのフォワードリンク・データをターゲットＢＳＲ２２０_２のＲＬＰ（Ｆ−ＲＬＰ）へ伝達し、ターゲットＢＳＲ２２０_２のＲＬＰ（Ｆ−ＲＬＰ）は、そのフォワードリンク・データをターゲットＢＳＲ２２０_２のＭＡＣスケジューラ（ＭＡＣ／ＳＣＨ_２）へ送信し、ターゲットＢＳＲ２２０_２のＭＡＣスケジューラ（ＭＡＣ／ＳＣＨ_２）は、最終的にそのフォワードリンク・データをモバイル２１０へ無線で伝達する。

早期通知のない本発明の一実施形態では、ソースＢＳＲ２２０_１のＲＬＰ（ＲＬＰ_１）は、ターゲットへのハンドオーバを示すＤＲＣを受信すると、セグメント化されたデータをターゲットＢＳＲ２２０_２のＲＬＰ（ＲＬＰ_２）へトンネルさせることを開始する。さらにソースＢＳＲ２２０_１は、ＤＲＣを受信したときに、セグメント化されているオクテットのシーケンス番号Ｖ（Ｓ）を記録する。ソースＢＳＲ２２０_１は将来のシーケンス番号Ｖ（Ｓ＋ｘ）を確定して、両方のシーケンス番号をターゲットＢＳＲ２２０_２へ送信し、将来のシーケンス番号Ｖ（Ｓ＋ｘ）を有するオクテットを受信する前にＦ−ＲＬＰの移行を完了する意思を表示する。ターゲットＢＳＲ２２０_２は両方のシーケンス番号を受信し、データが到着するごとにそのシーケンス番号を更新する。将来のシーケンス番号Ｖ（Ｓ＋ｘ）が発生する前に割り当てを受け入れる肯定応答がターゲットＢＳＲ２２０_２から受信されない場合、データのセグメント化がソースＢＳＲのＲＬＰ（ＲＬＰ_１）内で継続し、セグメント化されたオクテットが、ソースＢＳＲ２２０_１のＲＬＰ（ＲＬＰ_１）からターゲットＢＳＲ２２０_２のＲＬＰ（ＲＬＰ_２）へ転送される。次いでソースＢＳＲ２２０_１は、第２の将来のシーケンス番号Ｖ（Ｓ＋ｎｘ）を選択し、この第２の将来のシーケンス番号Ｖ（Ｓ＋ｎｘ）をターゲットＢＳＲ２２０_２へ転送する。このプロセスは、ターゲットＢＳＲ２２０_２が、ソースＢＳＲ２２０_１によって確定されたシーケンス番号の前の割り当てを受け入れる肯定応答をソースＢＳＲ２２０_１へ送信するまで継続する。すなわちターゲットＢＳＲ２２０_２による肯定応答を受けて、たとえば第１の繰り返しではＶ（Ｓ＋ｘ）よりも小さいか、または等しいシーケンス番号を有するオクテットをソースＢＳＲ２２０_１においてセグメント化し続け、ターゲットＢＳＲ２２０_２へ転送するが、Ｖ（Ｓ＋ｘ）よりも大きいシーケンス番号（たとえばＶ（Ｓ＋ｘ＋１））を有するセグメント化されていないオクテット（すなわちＰＰＰオクテット）は、ソースＢＳＲ２２０_１のＰＰＰ（ＰＰＰ_１）からターゲットＢＳＲ２２０_２のＰＰＰ（ＰＰＰ_２）へトンネルさせて、ターゲットＢＳＲ２２０_２のＲＬＰ（ＲＬＰ_２）によってセグメント化する。次いでそのセグメント化されたオクテットは、ターゲットＢＳＲ２２０_２によってモバイル２１０へ伝達される。

この実施形態では、ターゲットＢＳＲ２２０_２のターゲットＦ−ＲＬＰ（ＲＬＰ_２）は、新しいオクテットを提供しているため、ソースＢＳＲ２２０_１から伝達されたシーケンス番号Ｖ（Ｓ＋ｘ）よりも大きいシーケンス番号を有するオクテット用のＮＡＫを処理する。モバイル２１０、したがってＲ−ＲＬＰは、Ｆ−ＲＬＰの移行の状態に気づいており、行方不明のオクテットがどこに保存されるかに応じて、何らかのＮＡＫをソースＦ−ＲＬＰ（ＲＬＰ_１）またはターゲットＦ−ＲＬＰ（ＲＬＰ_２）のいずれかに転送し、これは、行方不明のオクテットのシーケンス番号によって確定することができる。ソースＲＬＰ（ＲＬＰ_１）は、移行のポストサービング・ステージにあるとみなされ、ＮＡＫを受信できるＶ（Ｓ＋ｘ）よりも小さいか、または等しいシーケンス番号を有するすべてのオクテットのバッファを維持する。任意選択でソースＢＳＲ２２０_１のＦ−ＲＬＰ（ＲＬＰ_１）は、ソースＢＳＲ２２０_１のＦ−ＲＬＰのインスタンスが削除される前にソースＢＳＲ２２０_１のＦ−ＲＬＰ（ＲＬＰ_１）がＮＡＫを待つ時間量を確立するためのタイマを含むことができる。

図５は、本発明の一実施形態によるＦ−ＲＬＰ用のアクティブ・セッション・モビリティのための方法のハイ・レベル・ブロック図を示している。方法５００は、工程５０２において開始し、モバイルは、別のソース（すなわちターゲットＢＳＲ）からデータを受信したいと決定する。次いで方法５００は、工程５０４へ進む。

工程５０４では、早期移行通知（すなわちＤＳＣ表示）が、アクティブ・セット内のすべてのソース（すなわちＢＳＲ）へ送信される。次いで方法５００は、工程５０６へ進む。

工程５０６では、サービング・ソース（たとえば図４のＢＳＲ２２０_１）は、ＲＬＰをフォワードリンクＲＬＰ（Ｆ−ＲＬＰ）とリバースリンクＲＬＰ（Ｒ−ＲＬＰ）に分離し、ターゲットへのＦ−ＲＬＰの移行に備える。より具体的には、工程５０６において、ソースのＲＬＰは、フォワードリンク・データおよびそのバッファの複製コピーをターゲットのＲＬＰへトンネルさせることを開始する。しかし今度は、データはターゲットのＲＬＰによって処理されない。次いで方法５００は、工程５０８へ進む。

工程５０８では、ハンドオフ通知（たとえばＤＲＣ）が、アクティブ・セット内のすべてのソース（すなわちＢＳＲ）へ送信される。ＤＲＣは、ターゲットを新しいサービング・ソース（たとえば図４のＢＳＲ２２０_２）として規定する。次いで方法５００は、工程５１０へ進む。

工程５１０では、ソースのＲＬＰへのデータ・フローは中断されるが、ソースのＲＬＰによって処理された残りのデータは、引き続きターゲットのＲＬＰへトンネルされる。さらに、古いソースは、古いソースによって処理された最終オクテットのシーケンス番号を規定する最終バイトのオクテットのシーケンス番号をターゲットへ送信する。しかしソースは、最終バイトのオクテットのシーケンス番号よりも小さいか、または等しいシーケンス番号を有するバイト用のＮＡＫを処理するための再送バッファを維持する。次いでこの方法は、工程５１２へ進む。

本発明の代替実施形態では、工程５１０において、ＮＡＫまたはタイムアウトを待つ古いソースの再送バッファのコンテンツがある場合、古いソースのＲＬＰによって処理された残りのデータをトンネルさせることと並行して、そのコンテンツをターゲットへ転送することができる。この場合、古いソースは、受信したＮＡＫを単にターゲットへ転送し、そしてターゲットが再送を開始する。次いで方法５００は、工程５１２へ進む。

工程５１２では、ターゲットは、最終バイトのオクテットのシーケンス番号を受信し、最終バイトのオクテットのシーケンス番号よりも大きいシーケンス番号を有するオクテットの処理を開始する。そして方法５００は終了する。

図６は、Ｆ−ＲＬＰをソースＢＳＲ２２０_１からターゲットＢＳＲ２２０_２へ移した後の（たとえば方法５００が完了した後の）図２のＢＳＲネットワーク２００のハイ・レベル機能図を示している。図６に示されているように、フォワードリンク方向では、ＨＡ２４０はフォワードリンク・データをソースＢＳＲ２２０_１のＦＡ（ＦＡ_１）へ送信する。次いでソースＦＡ（ＦＡ_１）は、そのフォワードリンク・データをソースＢＳＲ２２０_１のＰＰＰ（ＰＰＰ_１）へ送信し、ソースＢＳＲ２２０_１のＰＰＰ（ＰＰＰ_１）は、そのフォワードリンク・データをターゲットＢＳＲ２２０_２のＰＰＰ（ＰＰＰ_２）へトンネルさせる。そしてターゲットＰＰＰ（ＰＰＰ_２）は、そのフォワードリンク・データをターゲットＢＳＲ２２０_２のＲＬＰ（Ｆ−ＲＬＰ）へ伝達し、ターゲットＢＳＲ２２０_２のＲＬＰ（Ｆ−ＲＬＰ）は、そのフォワードリンク・データをターゲットＢＳＲ２２０_２のＭＡＣスケジューラ（ＭＡＣ／ＳＣＨ_２）へ送信し、ターゲットＢＳＲ２２０_２のＭＡＣスケジューラ（ＭＡＣ／ＳＣＨ_２）は、最終的にそのフォワードリンク・データをモバイル２１０へ無線で伝達する。

リバースリンク方向では、モバイル２１０は、リバースリンク・データをアクティブ・セット内のすべてのＢＳＲ（たとえば図６のＢＳＲ２２０_１〜２２０_２）へ送信する。ＢＳＲ２２０_１〜２２０_２のＭＡＣスケジューラ（ＭＡＣ／ＳＣＨ_１〜ＭＡＣ／ＳＣＨ_２）のそれぞれは、受信したデータを、フレーム選択を実行するサービングＢＳＲ（たとえばソースＢＳＲ２２０_１）のＲＬＰ（たとえばＲ−ＲＬＰ）へ伝達する。ターゲットＭＡＣスケジューラ（ＭＡＣ／ＳＣＨ_２）はまた、正しいリバースリンクＭＡＣフレームをターゲットＢＳＲ２２０_２のＲＬＰ（Ｆ−ＲＬＰ）へ伝達する。このような実施態様では、モバイルによって何らかのＮＡＫが送信される場合、ターゲットＦ−ＲＬＰはＮＡＫがソースから転送されるのを待つ必要がないため、再送時間が節減される。そのようなものとして、フレーム・セレクタは、ターゲットが既に正しいリバースリンク・フレームを受信しているため、迂回されている。ソースＢＳＲ２２０_１のＲＬＰ（Ｒ−ＲＬＰ）は、受信したデータをソースＢＳＲ２２０_１のＰＰＰ（ＰＰＰ_１）へ伝達し、ソースＢＳＲ２２０_１のＰＰＰ（ＰＰＰ_１）は、そのデータをソースＢＳＲ２２０_１のＦＡ（ＦＡ_１）へ伝達し、ソースＢＳＲ２２０_１のＦＡ（ＦＡ_１）は、そのデータをイントラネット２３０へ、およびそのままＨＡ２４０まで伝達する。図６に示されているように、ソースＢＳＲ２２０_１のＲＬＰ（Ｒ−ＲＬＰ）と、ターゲットＢＳＲ２２０_２のＲＬＰ（Ｆ−ＲＬＰ）の間に、ＮＡＫおよび行方不明のオクテットなどの情報およびデータ、ならびに肯定応答が受信される前のセグメント化されたデータを転送するための通信パスが存在することに留意すべきである。

Ｆ−ＲＬＰがソースＢＳＲ２２０_１からターゲットＢＳＲ２２０_２へ移行した後に、Ｒ−ＲＬＰをソースＢＳＲ２２０_１からターゲットＢＳＲ２２０_２へ移行することもできる。Ｒ−ＲＬＰがターゲットＢＳＲ２２０_２へ移行する前は、ソースＢＳＲ２２０_１でのＲ−ＲＬＰは、サービング・ステージで動作している。すなわちモバイル２１０からのリバースリンク・オクテットは、アクティブ・セット内のＢＳＲ２２０_１〜２２０_２のそれぞれにおいて受信されるが、フレーム選択は、引き続きソースＢＳＲ２２０_１において行われる。フレーム選択が完了した後、ＮＡＫは、前述のように適切なサービングＦ−ＲＬＰへ転送され、データは、ソースＢＳＲ２２０_１内のサービング・リバースＰＰＰ（ＰＰＰ_１）へ送信される。

Ｒ−ＲＬＰをソースＢＳＲ２２０_１からターゲットＢＳＲ２２０_２へ移行することが決定されると、ソースＢＳＲ２２０_１は、ターゲットＢＳＲ２２０_２によって受信される予定の次に予想されるリバース・シーケンス番号Ｖ（Ｒ）をターゲットＢＳＲ２２０_２に知らせる。ソースＢＳＲ２２０_１はまた、今ターゲットＢＳＲ２２０_２内でフレーム選択が行われていることをアクティブ・セット内の他のすべてのＢＳＲに知らせる。すなわち本発明のこの実施形態では、Ｒ−ＲＬＰが移動すると、フレーム選択もほぼ同時にターゲットＢＳＲへ移動する。

ソースＢＳＲ２２０_１内のＲ−ＲＬＰが、サービスを提供する立場ではなくなる場合、シーケンス番号Ｖ（Ｒ）において、ソースＢＳＲ２２０_１はポストサービング・ステージに入り、その並べ直しバッファを維持し、Ｖ（Ｒ）の前のシーケンス番号を有するすべてのオクテットを引き続き受信する。より新しいオクテット（Ｖ（Ｒ）よりも大きいシーケンス番号を有するオクテット）はすべて、自分自身の並べ直しバッファを維持するターゲットＢＳＲ２２０_２のＲ−ＲＬＰへ向けられる。しかしターゲットＢＳＲ２２０_２が、そのオクテットのすべてが配信されたか、または受信するのを待つ待機時間が切れたかを示す表示をソースＢＳＲ２２０_１のＲ−ＲＬＰから受信するまで、ターゲットＢＳＲ２２０_２からＨＡ２４０へのオクテットの配信は発生しない点に留意すべきである。

ターゲットＢＳＲ２２０_２のＲ−ＲＬＰは、ソースＢＳＲ２２０_１の並べ直しバッファのＲ−ＲＬＰ内に維持されている最終シーケンス番号Ｖ（Ｒ−１）に対する認識を維持し、これによって、「古い」オクテット（Ｖ（Ｒ）よりも小さいシーケンス番号を有するオクテット）はすべて、ターゲットＢＳＲ２２０_２のＲ−ＲＬＰによってソースＢＳＲ２２０_１のＲ−ＲＬＰへ転送することができる。それぞれのＲ−ＲＬＰは、その個々の並べ直しバッファを維持し、次のオクテットをネットワークへ配信することを表すシーケンス番号を更新する。ターゲットＢＳＲのＲ−ＲＬＰも、Ｆ−ＲＬＰのステータスに対する認識を維持し、前述のＦ−ＲＬＰの要件に従ってＮＡＫを転送する。さらに、シーケンス番号Ｖ（Ｒ−１）を有するオクテットがソースＢＳＲ２２０_１のＰＰＰ（ＰＰＰ_１）へ伝達されると、ソースＢＳＲ２２０_１はターゲットＢＳＲ２２０_２に通知を行い、ソースＢＳＲ２２０_１のＰＰＰ（ＰＰＰ_１）は、シーケンス番号Ｖ（Ｒ）以降はアップリンク・データ・ソースがターゲットＢＳＲ２２０_２になることを予期する。

図７は、本発明の一実施形態によるＲ−ＲＬＰ用のアクティブ・セッション・モビリティのための方法のハイ・レベル・ブロック図を示している。方法７００は、Ｒ−ＲＬＰをソースからターゲットへ移行することが決定されたとき、工程７０２において開始する。次いで方法７００は、工程７０４へ進む。

工程７０４では、ソースは、今ターゲット内でフレーム選択が行われていることをアクティブ・セット内の他のすべてのソース（すなわちＢＳＲ）に知らせ、シーケンスＶ（Ｒ）内で次に予想されるオクテットをターゲットに知らせる。次いで方法７００は、工程７０６へ進む。

工程７０６では、ソース（すなわちソースＢＳＲ２２０_１）は、その並べ直しバッファを引き続き維持し、Ｖ（Ｒ）の前のシーケンス番号を有するすべてのオクテットを引き続き受信する。次いで方法７００は、工程７０８へ進む。

工程７０８では、ターゲット（すなわちＢＳＲ２２０_２）は、自分自身の並べ直しバッファを維持し、より新しいオクテット（Ｖ（Ｒ）よりも大きいシーケンス番号を有するオクテット）はすべて、ターゲットのＲＬＰへ向けられる。次いで方法７００は、工程７１０へ進む。

工程７１０では、すべてのデータがソースによって配信された場合、またはソースにおける並べ直しによってデータを待つ待機時間が切れた場合、ソースは、ソースのＲ−ＲＬＰが完了し、ソースのＲ−ＲＬＰが削除されていることをターゲットに知らせる。すなわち、たとえばターゲットＢＳＲ２２０_２が、そのオクテットのすべてが配信されたか、または受信するのを待つ待機時間が切れたかを示す表示をソースＢＳＲ２２０_１のＲ−ＲＬＰから受信するまで、ターゲットＢＳＲ２２０_２からネットワークへのオクテットの配信は発生しない。次いで方法７００は、工程７１２へ進む。

工程７１２では、ターゲットは、ソースがネットワークへのデータの送信を完了したことを示す表示を受信し、自分の並べ直しバッファ内のデータをネットワークへ伝達し始める。そして方法７００は終了する。

図８は、Ｆ−ＲＬＰおよびＲ−ＲＬＰをソースＢＳＲ２２０_１からターゲットＢＳＲ２２０_２へ移行した後の図２のＢＳＲネットワーク２００のハイ・レベル機能図を示している。図８に示されているように、リバースリンク方向では、モバイル２１０からのＲ−ＲＬＰデータをアクティブ・セット内のＢＳＲ２２０_１〜２２０_３のすべてへ送信する。ＢＳＲ２２０_１〜２２０_３のＭａｃスケジューラ（ＭＡＣ／ＳＣＨ_１〜ＭＡＣ／ＳＣＨ_３）のそれぞれは、受信したデータを、フレーム選択を実行するサービングＢＳＲ（たとえばＢＳＲ２２０_２）のＲＬＰ（たとえばＲＬＰ_３）へ伝達する。ターゲットＢＳＲ２２０_２のＲＬＰ（ＲＬＰ_３）は、受信したデータをターゲットＢＳＲ２２０_２のＰＰＰ（ＰＰＰ_２）へ伝達し、ターゲットＢＳＲ２２０_２のＰＰＰ（ＰＰＰ_２）は、そのデータをソースＢＳＲ２２０_１のＰＰＰ（ＰＰＰ_１）へトンネルさせる。ソースＢＳＲ２２０_１のＰＰＰ（ＰＰＰ_１）は、そのデータをソースＢＳＲ２２０_１のＦＡ（ＦＡ_１）へ伝達し、ソースＢＳＲ２２０_１のＦＡ（ＦＡ_１）は、そのデータをイントラネット２３０へ、およびそのままＨＡ２４０まで伝達する。

フォワードリンク方向では、データ・フローは実質的に逆になっている。より具体的には、ＨＡ２４０からのデータは、ソースＢＳＲ２２０_１のＦＡ（ＦＡ_１）へされる。ＦＡ（ＦＡ_１）は、そのデータをＰＰＰ_１へ伝達し、ＰＰＰ１は、そのデータをターゲットＢＳＲ２２０_２のＰＰＰ（ＰＰＰ_２）へトンネルさせる。ターゲットＢＳＲ２２０_２のＰＰＰ（ＰＰＰ_２）は、そのデータをターゲットＢＳＲ２２０_２のＲＬＰ（ＲＬＰ_２）へ伝達し、ターゲットＢＳＲ２２０_２のＲＬＰ（ＲＬＰ_２）は、そのデータをターゲットＢＳＲ２２０_２のＭＡＣスケジューラ（ＭＡＣ／ＳＣＨ_２）へ伝達し、ターゲットＢＳＲ２２０_２のＭＡＣスケジューラ（ＭＡＣ／ＳＣＨ_２）は、そのデータをモバイル２１０へ無線で伝達する。

ここまでは、本発明によるアクティブ・セッションＲＬＰモビリティ・ソリューションのさまざまな実施形態について、２つの規定された状態をソースからターゲットへ移行するための２つのステージのＲＬＰ移行プロセスを実施して移行される２つのＲＬＰ移行状態を有するものとして説明したが、本発明の代替実施形態は、Ｆ−ＲＬＰおよびＲ−ＲＬＰという２つのＲＬＰ移行状態を、少なくとも前述の移行のための方法を実施する単一のステージで移行する工程を含むことができる点に留意すべきである。

前述のように、本発明によるＲＬＰモビリティ・ソリューションの実施形態を実装するネットワークでは、モバイルは、比較的短時間に複数のハンドオフを要求することができる。そのようなものとして、本発明のＲＬＰモビリティ・ソリューションのさまざまな実施形態は、Ｒ−ＲＬＰをソースからターゲットへ、たとえばソースＢＳＲからターゲットＢＳＲへいつ移行するかを決定するためのタイマを任意選択で含むことができる。より具体的には、Ｆ−ＲＬＰをソースＢＳＲからターゲットＢＳＲへ移行した後、ソースＢＳＲはタイマを開始することができ、このタイマが切れてからでないと、ソースＢＳＲ内のＲ−ＲＬＰをターゲットＢＳＲへ移行することはできない。すなわちモバイルが（より強い信号をターゲットＢＳＲから受信しているために）ターゲットＢＳＲからデータを受信したいと決定すると、ソースＢＳＲ内のＦ−ＲＬＰはターゲットＢＳＲへ移行される。しかしＦ−ＲＬＰをソースＢＳＲからターゲットＢＳＲへ移行した直後に、モバイルは、元のソースＢＳＲからさらに強い信号を受信する状態へ戻ったり、次のＢＳＲと出くわして、そこからさらに強い信号を受信したりする場合がある。そのようなものとして、Ｒ−ＲＬＰの移行を制御するためのタイマを実装するＲＬＰモビリティ・ソリューションの実施形態では、モバイルがソースＢＳＲからさらに強い信号を再び得るか、または次なる第２のターゲットＢＳＲからさらに強い信号を得るのに十分な時間、Ｒ−ＲＬＰをソースＢＳＲ内に維持することができる。前者の場合、Ｒ−ＲＬＰはソースＢＳＲ内に残り、Ｆ−ＲＬＰはソースＢＳＲへ戻ることができる。後者の場合、Ｆ−ＲＬＰはターゲットＢＳＲから次なる第２のターゲットＢＳＲへ移行し、タイマが切れると、Ｒ−ＲＬＰはソースＢＳＲから直接次なる第２のターゲットＢＳＲへ移行する。したがって、Ｒ−ＲＬＰが第１のターゲットＢＳＲへ移行する必要はない。そのようなものとして、本発明によるＲＬＰモビリティ・ソリューションのさまざまな実施形態において実装される任意選択のタイマは、Ｒ−ＲＬＰが移行しなければならない回数を減らすように機能することができる。

同様に、Ｆ−ＲＬＰをソースからターゲットへ、たとえばソースＢＳＲからターゲットＢＳＲへいつ移行するかを制御するためのタイマを任意選択で実装することができる。より具体的には、前述のように、モバイルは、短時間にアクティブ・セットの複数のデータ・ソース間を移動することができ、さまざまなアクティブ・セット間を行きつ戻りつすることさえできる。そのようなものとして、モバイルは、（ソースからの信号よりも強い信号をターゲットから受信しているために）ターゲットからデータを受信したいと決定することがある。その直後に、モバイルは、元のソースからさらに強い信号を受信する状態へ戻ったり、次のターゲットと出くわして、そこからさらに強い信号を受信したりする場合がある。そのようなものとして、Ｆ−ＲＬＰの移行を制御するためのタイマを実装するＲＬＰモビリティ・ソリューションの実施形態では、モバイルがソースからさらに強い信号を再び得るか、または次なる第２のターゲットからさらに強い信号を得るのに十分な時間、Ｆ−ＲＬＰをソースＢＳＲ内に維持することができる。前者の場合、Ｆ−ＲＬＰは、タイマが切れるまでソース内に残り、その間、モバイルは再びソースからデータを受信することを決定することができる。後者の場合、Ｆ−ＲＬＰは、やはりタイマが切れるまでソース内に残り、タイマが切れてはじめて、Ｆ−ＲＬＰは、モバイルが最も強い信号を受信しているターゲットへ移行される。そのようなものとして、本発明によるＲＬＰモビリティ・ソリューションのさまざまな実施形態において実装される任意選択のタイマは、Ｆ−ＲＬＰが移行しなければならない回数を減らすように機能することができる。

上記の開示から示されているように、Ｆ−ＲＬＰおよびＲ−ＲＬＰは、ソースからターゲットへ、および次なるターゲットへ、同時に、または個々に、およびさまざまな繰り返しの間に移行することができる。より具体的には、Ｆ−ＲＬＰとＲ−ＲＬＰは、上述のようにソースから第１のターゲットへ、続いて第２のターゲットへと移行することができ、あるいはＦ−ＲＬＰは、第１のターゲットへ、次いで第２のターゲットへと移行し、その後Ｒ−ＲＬＰが、第１のターゲットを経由して第２のターゲットへ、または直接第２のターゲットへ移行することもできる。すなわち本発明のさまざまな実施形態によれば、本明細書で規定されているＲＬＰのコンポーネント、すなわちＦ−ＲＬＰおよびＲ−ＲＬＰは、ソースとターゲットの間を同時に、個々に、またはそれらの任意の組合せで移行することができる。

ＢＳＲネットワーク・アーキテクチャとの関連から、本発明のアクティブ・セッションＲＬＰ移行ソリューションのさまざまな実施形態を示したが、本発明のアクティブ・セッションＲＬＰ移行ソリューションの概念は、ＲＬＰ（Ｒａｄｉｏ Ｌｉｎｋ Ｐｒｏｔｏｃｏｌ）などの信頼性の高いプロトコルを実装するほぼすべてのネットワークに適用できることを当業者なら理解するであろうし、また本発明の教示からも分かるであろう。より具体的には、たとえば本発明のアクティブ・セッションＲＬＰ移行ソリューションの概念を図１の従来のＣＤＭＡ階層型無線ＩＰネットワーク１００に適用して、たとえばアクセス端末１１０のモビリティによってさまざまなＲＮＣ１２５間でＲＬＰセッションを活発に移行することができる。

上述の内容は、本発明のさまざまな実施形態を対象としているが、本発明の基本的な範囲から逸脱することなく、本発明の他の実施形態およびさらなる実施形態を考案することができる。そのようなものとして、本発明の適切な範囲は、添付の特許請求の範囲に従って画定される。

従来のＣＤＭＡ階層型無線ＩＰネットワークを示すハイ・レベル・ブロック図である。 本発明の一実施形態を適用できるＢＳＲ（Ｂａｓｅ−Ｓｔａｔｉｏｎ−Ｒｏｕｔｅｒ）タイプのネットワーク・アーキテクチャを示すハイ・レベル・ブロック図である。 第１のＢＳＲがモバイル用のソースＢＳＲとして機能している初期状態における図１のＢＳＲネットワークを示すハイ・レベル機能図である。 モバイルが第２のＢＳＲ（ターゲットＢＳＲ）からより強い信号を受信し始め、ターゲットＢＳＲからのそのデータを受信することを選択したときの状態における図１のＢＳＲネットワークを示すハイ・レベル機能図である。 本発明の一実施形態によるＦ−ＲＬＰ（ｆｏｒｗａｒｄ−ｌｉｎｋ Ｒａｄｉｏ Ｌｉｎｋ Ｐｒｏｔｏｃｏｌ）用のアクティブ・セッション・モビリティのための方法を示すハイ・レベル・ブロック図である。 Ｆ−ＲＬＰをソースＢＳＲからターゲットＢＳＲへ移行した後の図１のＢＳＲネットワークを示すハイ・レベル機能図である。 本発明の一実施形態によるＲ−ＲＬＰ用のアクティブ・セッション・モビリティのための方法を示すハイ・レベル・ブロック図である。 Ｆ−ＲＬＰおよびＲ−ＲＬＰをソースＢＳＲからターゲットＢＳＲへ移行した後の図１のＢＳＲネットワークを示すハイ・レベル機能図である。

Claims (10)

1. 無線ＩＰネットワーク内のソースからターゲットへ信頼できるプロトコルのアクティブ・セッションをシームレスに移行するための方法であって、
   前記信頼できるプロトコルを少なくともフォワードリンク状態とリバースリンク状態に分離する工程と、
   少なくとも前記フォワードリンク状態および前記リバースリンク状態を前記ソースから前記ターゲットへ移行する工程とを含む方法。
2. 少なくとも前記フォワードリンク状態が、移行の第１ステージで前記ソースから前記ターゲットへ移行され、少なくとも前記リバースリンク状態が、移行の第２ステージで前記ソースから前記ターゲットへ移行される、請求項１に記載の方法。
3. 移行の前記第１ステージが、
   前記信頼できるプロトコルの前記フォワードリンク状態が前記ソースから前記ターゲットへ間もなく移行されることを示す信号を前記ソースへ、および前記ターゲットへ送信する工程と、
   前記信号が前記ソースによって受信されると、前記ソースによってセグメント化されたフォワードリンク・データおよび前記ソースによってセグメント化された前記フォワードリンク・データの状態情報を前記ターゲットへトンネルさせる工程と、
   前記ターゲットが前記信頼できるプロトコルの前記フォワードリンク状態の前記移行を前記ソースから受け取る準備が整ったことを示す肯定応答を前記ターゲットから前記ソースへ送信する工程と、
   前記肯定応答が前記ソースによって受信されると、事前にセグメント化されたフォワードリンク・データを前記ソースから前記ターゲットへトンネルさせる工程とを含む、請求項２に記載の方法。
4. 前記ソースによって前記ターゲットへトンネルされた前記事前にセグメント化されたフォワードリンク・データが、前記ターゲットによって第２のターゲットへトンネルされる、請求項３に記載の方法。
5. 移行の前記第１ステージが、
   前記信頼できるプロトコルの前記フォワードリンク状態が前記ソースから前記ターゲットへ移行される可能性を示す早期表示信号を前記ソースへ、および前記ターゲットへ送信する工程と、
   前記早期表示信号が受信されると、前記ソースによって受信されたデータのコピーを前記ターゲットへトンネルさせる工程と、
   前記信頼できるプロトコルの前記フォワードリンク状態が前記ソースから前記ターゲットへ間もなく移行されることを示す移行信号を前記ソースへ、および前記ターゲットへ送信する工程と、
   前記移行信号が受信されると、事前にセグメント化されたフォワードリンク・データを前記ソースから前記ターゲットへトンネルさせる工程とを含む、請求項２に記載の方法。
6. 前記ソースが、前記移行信号を受信すると、シーケンス番号を前記ターゲットへ伝達し、前記シーケンス番号が、前記フォワードリンク・データのオクテットのシーケンス内の１つのオクテットを規定し、それによって前記ターゲットにおいてフォワードリンク・データのセグメント化が開始する、請求項５に記載の方法。
7. 移行の前記第２ステージが、
   フレーム選択が、リバースリンク・データの次に予想されるリバースリンク・オクテットで開始して前記ターゲットにおいて実行されることを示す信号を前記ソースから少なくとも前記ターゲットへ伝達する工程と、
   リバースリンク・データの前記次に予想されるリバースリンク・オクテットのシーケンス番号を前記ソースから前記ターゲットへ伝達する工程と、
   前記次に予想されるリバースリンク・オクテットの前記シーケンス番号よりも小さいシーケンス番号を有する前記リバースリンク・データのリバースリンク・オクテットを前記ソースへ転送して、前記ソースによってセグメント化し、ホーム・エージェントへ伝達する工程と、
   前記次に予想されるリバースリンク・オクテットの前記シーケンス番号よりも大きいかまたは等しいシーケンス番号を有するリバースリンク・オクテットを前記ターゲットへ転送して、前記ターゲットによってバッファに保存する工程とを含む、請求項２に記載の方法。
8. 前記次に予想されるリバースリンク・オクテットの前記シーケンス番号の１つ前のシーケンス番号を有するリバースリンク・オクテットが、前記ソースによっていつ処理されて、前記ソースによって前記ホーム・エージェントへいつ伝達されたかを前記ソースが前記ターゲットに知らせ、これによって前記ターゲットが、バッファに保存されて新たに受信されたオクテットを処理する工程と、前記バッファに保存されて新たに受信されたオクテットを前記ホーム・エージェントへ伝達する工程とを開始することができる、請求項７に記載の方法。
9. ソースからターゲットへ信頼できるプロトコル・セッションのアクティブ・セッションをシームレスに移行するための方法であって、
   前記信頼できるプロトコル・セッションを少なくとも第１の状態と第２の状態に分離する工程と、
   前記信頼できるプロトコル・セッションの少なくとも前記第１の状態が前記ソースから前記ターゲットへ間もなく移行されることを示す信号を前記ソースへ、および前記ターゲットへ伝達する工程と、
   前記信号が前記ソースによって受信されると、前記ソースによってセグメント化されたＩＰデータを前記ターゲットへ転送する工程と、
   前記ターゲットが前記信頼できるプロトコル・セッションの前記第１の状態の前記移行を前記ソースから受け取る準備が整ったことを示す信号を前記ターゲットから前記ソースへ伝達する工程と、
   前記ターゲットからの前記信号が前記ソースによって受信されると、事前にセグメント化されたＩＰデータを前記ソースから前記ターゲットへ転送する工程とを含む方法。
10. フレーム選択が、ＩＰデータの次に予想されるオクテットで開始して前記ターゲットにおいて実行されることを示し、前記第２の状態が前記ターゲットへ移行するのをトリガする信号を前記ソースから少なくとも前記ターゲットへ伝達する工程と、
    ＩＰデータの前記次に予想されるオクテットのシーケンス番号を前記ソースから前記ターゲットへ伝達する工程と、
    前記次に予想されるオクテットの前記シーケンス番号よりも小さいシーケンス番号を有する前記ＩＰデータのオクテットを前記ソースへ転送する工程と、
    前記次に予想されるオクテットの前記シーケンス番号よりも大きいかまたは等しいシーケンス番号を有するオクテットを前記ターゲットへ転送して、前記ターゲットによってバッファに保存する工程とをさらに含む、請求項９に記載の方法。

Images