順方向リンク及び逆方向リンクのサービングアクセスポイントの変更
【課題】ハンドオフプロセスの間に通信条件の良い順方向リンク及び逆方向リンクを各々自由に選択可能とする方法を提供する。
【解決手段】モバイル局が複数の基地局を介してメインネットワークにアクセスする通信システムにおいて、モバイル局は、順方向リンク（ＦＬ）サービング局として、いずれの基地局も自由に選択することができる。さらに、モバイル局はまた、逆方向リンク（ＲＬ）サービング局として、別の基地局あるいは同じ基地局を自由に選択することができる。モバイル局は、複数の基地局に対応する複数のルートをそのメモリにおいて保存し、各ルートは、特定の基地局に専属的に(dedicatedly)割り当てられる。ＦＬサービング局あるいはＲＬサービング局のいずれかとして１つの基地局から別のへのハンドオフの間に、関与した基地局のそれぞれのルートにおいて、交換されたデータパケットは処理される。
【解決手段】モバイル局が複数の基地局を介してメインネットワークにアクセスする通信システムにおいて、モバイル局は、順方向リンク（ＦＬ）サービング局として、いずれの基地局も自由に選択することができる。さらに、モバイル局はまた、逆方向リンク（ＲＬ）サービング局として、別の基地局あるいは同じ基地局を自由に選択することができる。モバイル局は、複数の基地局に対応する複数のルートをそのメモリにおいて保存し、各ルートは、特定の基地局に専属的に(dedicatedly)割り当てられる。ＦＬサービング局あるいはＲＬサービング局のいずれかとして１つの基地局から別のへのハンドオフの間に、関与した基地局のそれぞれのルートにおいて、交換されたデータパケットは処理される。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般に、通信に関し、より具体的には、無線通信システムにおけるサービングアクセスポイントの切り替え(switching of serving access points)に関する。
【背景技術】
【０００２】
テレコミュニケーションにおいて、特に無線通信においては、通信環境は、静的なものではなく、むしろ動的なものである。モバイル通信の設定においては、いくつかのモバイル通信エンティティ(mobile communication entities)は、一般にはモバイル局と呼ばれており、異なるときに、異なる通信条件の下、異なる位置へと移動することができる。
【０００３】
無線ネットワークにおいては、モバイル局は、一般には基地局と呼ばれる、あるインフラストラクチャ通信エンティティ(infrastructure communication entities)、を介してメインネットワークにアクセスする。データが基地局からモバイル局へと流れる通信接続は、順方向リンク(forward link)（ＦＬ）と呼ばれる。同様に、データがモバイル局から基地局へと流れる通信接続は、逆方向リンク(reverse link)（ＲＬ）と呼ばれる。通信条件(communication conditions)は、ＦＬとＲＬの両方にとって、必ずしも同じだとは限らない。例えば、モバイル局は、高い混雑ＲＬトラフィック(a highly congestive RL traffic)を有しているが比較的オープンなＦＬフロー(a relatively open FL flow)を有している、サービング基地局と通信していてもよい。よりよいＲＬは他の基地局から利用可能であるがＦＬ及びＲＬの両方のために基地局と一緒にとどまるモバイル局については、通信リソースの最良の使用ではない可能性がある。
【０００４】
さらに、メインネットワークにアクセスする１つの基地局から別の基地局へと変わるモバイル局については、ＦＬ変更あるいはＲＬ変更であろうと、変更の間に変更の後で交換されたデータパケットが、無傷(intact)のままであることは好ましい。ボイスオーバーＩＰ(Voice over IP)（ＶｏＩＰ）呼び出しにおいて交換されたデータパケットのような時間センシティブなデータパケット(time-sensitive data packets)に特に当てはまる。弾性のデータパケットあるいはベストエフォートデータパケット(elastic or best-effort data packets)とは異なり、伝送の間の、誤りのあるいは逃した時間センシティブパケットは、必ずしも再送信されない。したがって、基地局の変更の間の時間センシティブデータパケットの妨害(disruption)は、サービスの品質に影響を与える可能性がある。
【０００５】
したがって、利用可能な通信リソースを適切に且つ効率的に使用し、さらにハンドオフプロセス(handoff process)の間にデータ整合性(data integrity)を維持するために、モバイル局は、ＦＬ及びＲＬの割り当てについていずれのサービング通信エンティティ(serving communication entities)を自由に選択する必要がある。
【発明の概要】
【０００６】
（米国特許法第１１９条の下の優先権主張）
本願は、２００７年４月２５日に出願された仮出願第６０／９１３，９１１号、および、２００７年６月１２日に出願された仮出願第６０／９４３，４３４号の優先権をそれぞれ主張しており、すべては、ここでの譲受人に譲渡されており、また、ここにおいて参照することにより、明示的に組み込まれる。
【０００７】
モバイル局が複数の基地局を介してメインネットワークにアクセスしている通信システムにおいて、モバイル局は、順方向リンク(forward link)（ＦＬ）サービング局としていずれの基地局も自由に選択することができる。さらに、モバイル局はまた、逆方向リンク(reverse link)（ＲＬ）サービング局として、別の基地局あるいは同じ基地局を自由に選択することができる。モバイル局は、そのメモリに、複数の基地局に対応する複数のルート(a plurality of routes)を保存し、各ルートは、特定の基地局に専属的に(dedicatedly)割り当てられている。ＦＬサービング局あるいはＲＬサービング局のいずれかとして、１つの基地局から別の基地局へのハンドオフの間に、交換されたデータパケットは、関与した基地局のそれぞれのルートにおいて、処理される。さらに、ルートはまた、部分的に転送されたデータパケット(partially transferred data packets)を処理することに依存しており、その結果、ハンドオフプロセスの間にトランスパレントでシームレスなデータの転送(transparent and seamless transfer of data)を可能にする。
【０００８】
これらの及び他の特徴および利点は、詳細な説明から、同様の参照番号は同様の部分を指す添付図面と一緒に使用して、当業者にとって明らかであろう。
【図面の簡単な説明】
【０００９】
【図１】図１は、本発明の例示的な実施形態にしたがって配置された(arranged)様々な通信のエンティティの関係を図示している、簡略化された概略図である。
【図２】図２は、例示的な実施形態にしたがって動作している順方向リンクサービング局のハンドオフの間の、異なる通信エンティティの中のメッセージ及びデータフローを示す、呼び出しフロー図である。
【図３】図３は、異なる通信エンティティが異なるＩＰデータパケットのトンネリング(tunneling)の責任を負う、ＩＰデータパケットのフローの図を概略的に示す。
【図４】図４は、例示的な実施形態にしたがって動作している逆方向リンクサービング局のハンドオフの間の、異なる通信エンティティの中のメッセージ及びデータフローを示す、呼び出しフロー図である。
【図５】図５は、順方向リンクサービング局が誤って割り当てられるが整流(rectification)で訂正されるハンドオフの間の、異なる通信エンティティの中のメッセージ及びデータフローを示す、呼び出しフロー図である。
【図６】図６は、例示的な実施形態にしたがってハンドオフプロセスを実行するための装置のハードウェアインプリメンテーションの部分の概略図である。
【発明を実施するための形態】
【００１０】
以下の説明は、当業者が本発明を作り使用することを可能にするために提示されている。詳細は、説明の目的のために次の説明で記載されている。本発明はこれらの具体的な詳細の使用なしに実行されることができるということを当業者が認識するであろうということが、理解されるべきである。他の例においては、既知のストラクチャ及びプロセスは、不必要な詳細で本発明の説明を不明瞭にしないために、詳述されない。したがって、本発明は、示された実施形態によって限定されるようには意図されていないが、ここに開示された原則及び特徴に一貫した最も広い範囲が与えられることになっている。
【００１１】
さらに、以下の説明では、簡略と明瞭性という理由から、電気通信工業会(Telecommunication Industry Association)（ＴＩＡ）による第３世代パートナーシッププロジェクト２(3rd Generation Partnership Project 2)（３ＧＰＰ２）の下で公表されたような、ウルトラモバイルブロードバンド(Ultra Mobile Broadband)（ＵＭＢ）に関連づけられた用語が使用されている。本発明はまた、例えば符号分割多元接続（ＣＤＭＡ）、時分割多元接続（ＴＤＭＡ）、周波数分割多元接続（ＦＤＭＡ）、直交周波数多元接続（ＯＦＤＭＡ）などに関連した技術及び関連の標準のような、他の技術に対して適用可能であるということは強調されるべきである。異なる技術に関連づけられた用語は、異なっていてもよい。例えば、熟考された技術次第で、いくつかだけを挙げると、モバイル局は、ときに、モバイル端末、ユーザ機器、加入者ユニット等と呼ばれることができる。同様に、基地局は、ときに、アクセスポイント、ノードＢ等と呼ばれることができる。異なる用語が、適用可能なときに、異なる用語に適用するということは、ここでは留意すべきである。
【００１２】
本発明の例示的な実施形態にしたがって配置された様々な通信エンティティの関係を概略的に示す、図１を参照する。
【００１３】
図１においては、全体的な通信システムは、参照番号３０によって一般に示される。通信システム３０では、複数の発展した基地局(evolved Base Stations)（ｅＢＳｓ）にリンクしたアクセスゲートウェイ(Access Gateway)（ＡＧＷ）３２があり、３つの発展した基地局は、ｅＢＳ３４、ｅＢＳ３６、及びｅＢＳ３８として示されている。ｅＢＳｓ３４、ｅＢＳ３６、及びｅＢＳ３８は、同じアクセスネットワーク（ＡＮ）において、あるいは異なるＡＮｓにおいて、インストールされることができる。この例において、ｅＢＳｓ３４、３６、及び３８は、それぞれ、ＡＮｓ４０、４２、及び４４の一部分である。ＡＮｓ４０、４２、及び４４のそれぞれは、１つまたは複数のｅＢＳｓ、及び他のエンティティを含んでもよい。明瞭さと簡潔さのために、各ＡＮは、図１においては、１つのｅＢＳのみ示されている。したがって、図１において示されるような実施形態では、ｅＢＳ３４は、サービスエリア４６内のユーザに、無線アクセスを提供する。同様に、ｅＢＳｓ３６及び３８は、サービスエリア４８及び５０内で、それぞれ無線アクセスを提供する。
【００１４】
ＡＧＷ３２は、中枢ネットワーク(a backbone network)５２に対してリンクを有しており、それは例えばインターネットであってもよい。あるいは、別の例として、中枢ネットワーク５２は、例えば閉鎖されたネットワークにおけるイントラネットであってもよい。
【００１５】
システム３０内で展開されたアクセス端末（ＡＴ）５４がある、と仮定する。ユーザによって操作されたＡＴ５４（示されていない）は、ＡＮ４０、ＡＮ４２、及びＡＮ４４を含んでいる、様々な無線ネットワークの中で移動させることができる。ＡＴ５４は、システム３０における様々な通信エンティティを介して、中枢ネットワーク３８にアクセスすることができる。
【００１６】
ＡＴ５４がｅＢＳ３４と最初に通信する、と仮定する。ＡＴ５４は、図１の参照番号５６によって図示される論理データ経路によって示されているように、中枢ネットワーク５２からのデータがＡＧＷ３２及びｅＢＳ３４を介してＡＴ５４へと流れることができるように、ｅＢＳ３４を用いて順方向リンク（ＦＬ）を確立することを最初に必要とする。ＡＴ５４は、ｅＢＳ３４からＦＬデータパケットを直接受信するので、ｅＢＳ３４は、ＡＴ５４のための順方向リンクサービングｅＢＳ(Forward-Link Serving eBS)(ＦＬＳＥ)とも呼ばれる。
【００１７】
多少同様な方法で、ＡＴ５４はまた、図１の論理データ経路５８によって示されているように、ＡＴ５４からのデータがｅＢＳ３４とＡＧＷ３２を介して中枢ネットワークへと流れることができるように、ｅＢＳ３４を用いて逆方向リンク（ＲＬ）を確立することを必要とする。ＡＴ５４がｅＢＳ３４に対して直接ＲＬデータパケットを送信するので、ｅＢＳ３４はまた、ＡＴ５４のための逆方向リンクサービングｅＢＳ(Reverse-Link Serving eBS)（ＲＬＳＥ）と呼ばれる。
【００１８】
図１に示されているように、ＡＴ５４は、それぞれ、ＦＬとＲＬとして、論理データ経路５６及び５８を介して、ｅＢＳ３４を用いてデータを交換する。この例において、ｅＢＳ３４は、ＡＴ５４のためのＦＬＳＥ及びＲＬＳＥの両方としての２重の役割を想定する(assumes)。
【００１９】
さらに、この例において、ｅＢＳ３４はまた、ＡＴ５４のためのデータアタッチメントポイント(Data Attachment Point)（ＤＡＰ）としてサービス提供する。ｅＢＳ３４がＡＴ５４のためのＦＬＳＥとなるとき、ＤＡＰ割り当てプロセスを開始することができる。この目的を達成するために、ｅＢＳ３４は、ＡＧＷ３２に対して、登録リクエストメッセージを送信する。その後で、ＡＧＷ３２は、インターネットエンジニアリングタスクフォース(Internet Engineering Task Force)（ＩＥＴＦ）によって発行されるプロキシモバイルＩＰ（ＰＭＩＰ）プロトコルの下で示されているプロシージャにしたがって、ｅＢＳ３４を用いて、バインディングアップデート(binding update)を実行する。本質的には、ＤＡＰ３４は、ＡＴ５４についてデータアンカリング関数(data anchoring function)を実行する。結果として、ＡＴ５４のためのＦＬＳＥ及びＲＬＳＥとしての役割を想定することに加えて、その場合においては、ｅＢＳ３４はまた、ＡＴ５４のためのＤＡＰの義務を果たす(serves the duty)。別の方法に置き換えると、この例においては、ｅＢＳ３４は、ＡＴ５４のために、ＦＬＳＥ、ＲＬＳＥ、及びＤＡＰ、の３つの役割を果たす。
【００２０】
本発明の例示的な実施形態にしたがって、ｅＢＳ５４のようなシステム３０における通信エンティティは、ＡＴ５４のような、また、前に叙述されているような、任意のＡＴについて、同時に、すべて３つの役割を想定する必要はない。
【００２１】
図１に戻って参照する。ＡＴ５４がｅＢＳ３６によって提供されるサービスエリア４８に移動する、と仮定する。ｅＢＳ３６からのより強い信号及び近接(With closer proximity and stronger signals from the eBS 36)で、ＡＴ５４は、ｅＢＳ３４からｅＢＳ３６へと、ＦＬＳＥとＲＬＳＥの両方をハンドオフすることを決定する。ハンドオフプロセスは、後でより詳細に説明されるであろう。
【００２２】
ハンドオフが成功した、と仮定する。ハンドオフの後、ＦＬの場合には、図１で示された論理データ経路６０によって示される列挙された順序で、中枢ネットワーク５２からのデータパケットは、ＡＧＷ３２、ｅＢＳ３４、及びｅＢＳ３６を介して、ＡＴ５４へと流れる。同様に、ＲＬの場合には、図１で示される論理データ経路６２によって示される列挙された順序で、ＡＴ５４からのデータパケットは、ｅＢＳ３６、ｅＢＳ３４、及びＡＧＷ３２を介して、中枢ネットワーク５２へと流れる。この場合には、ｅＢＳ３６は、ＡＴ５４のためのＦＬＳＥ及びＲＬＳＥとしての２つの役割を想定する。それにもかかわらず、ｅＢＳ３４は、ＡＴ５４のためのＤＡＰとしてまだ作用する。
【００２３】
ＡＴ３４はｅＢＳ３４によってサービス提供されるサービスエリア４６から離れてローミングされるにもかかわらず、ｅＢＳ３４は、ＡＴ５４のためのＤＡＰを残す。その理由は、無線設定において、ＡＴ５４の動き(mobility)によって、ｅＢＳ３４がＡＴ５４のためのＦＬＳＥあるいはＲＬＳＥに再びなることができるということが可能であるからである。例えば、ＡＴ５４は、ｅＢＳ３４及びｅＢＳ３６によってそれぞれ提供されるサービスエリア４６及び４８の境界上にあってもよい。したがって、ＡＴ５４は、一時的にｅＢＳ３６とのみ通信することができる。しかしながら、ＡＴ５４とｅＢＳ３６との間の通信が一時的でない場合、曲がりくねった論理パス(meandering logical data paths)６０及び６２を介してデータパケットをルーティングすることは、少なくともバックホール使用の観点から、通信のリソースの効率的な使用でないかもしれない。さらに、データパケットレイテンシ(data packet latency)もまた、強い影響を与えられる(impacted)。代わりに、ＤＡＰは、ｅＢＳ３４からｅＢＳ３６へと好ましくは切り替えられる。ＤＡＰスイッチについての基準は、特に(among other things)、ＡＴ５４がｅＢＳ３６によって提供されるサービスエリア４８において十分に長くとどまったということであってもよい。ＤＡＰのスイッチの基本的なプロシージャは、電気通信工業会（ＴＩＡ）の下でまとめられた、第３世代パートナーシッププロジェクト２（３ＧＰＰ２）によって発行された、出版物３ＧＰＰ２ Ａ.Ｓ００２０で見つけられることができる。この場合においては、ＤＡＰ変更についての１つまたは複数の基準は満たされてはおらず、ｅＢＳ３４はＡＴ５４のためのＤＡＰとして残る、と仮定する。
【００２４】
続けて図１を参照する。ＡＴ５４は、他のサービスエリアの領域(other coverage territories)に対してローミングすることを続ける、と仮定する。ある時点で、ＡＴ５４は、ｅＢＳ３８によって提供されるサービスエリア５０に達する(reaches)。さらに、何らかの理由で、ＡＴ５４は、強いＦＬだが比較的に低いＲＬをｅＢＳ３８から検知する、と仮定する。「リンクアンバランス(link imbalance)」と呼ばれるそのようなシナリオは、ＲＬに関連づけられた周波数帯域の過度な周波数干渉によってもたらされることができる。干渉は、例えば基地局とのアクティブな通信における、多すぎるＡＴｓ（示されてはいない）によって、もたらされることができる。ＦＬトラフィックは、ｅＢＳｓが異なる周波数帯域を使用し、さらに地理的に離れて遠いので、あまり影響されないかもしれない。別の例として、ｅＢＳ５４が他のＡＴｓ（示されていない）からＲＬ接続でオーバーロードされるが、ＦＬトラフィックはまだ比較的スパース(sparse)である、と仮定する。そのようなシナリオの下では、ＡＴ５４は、ｅＢＳ３６からｅＢＳ３８へとＦＬＳＥを切り替えるために決定することができるが、ＡＴ５４のためのＲＬＳＥとしてｅＢＳ３６を維持する。
【００２５】
ＲＬの場合、ＡＴ５４からのデータパケットは、前に説明されるように、論理データ経路６２を介して、中枢ネットワーク５２へと流れる。しかしながら、ＦＬの場合には、列挙された順序で、図１で示されるデータ経路６４によって示されるように、中枢ネットワーク５２からのデータパケットは、ＡＧＷ３２、ｅＢＳ３４、及びｅＢＳ３８を介してＡＴ５４へと流れる。この場合、３つの異なる通信エンティティは、３つの異なる役割を想定する。具体的に、ＡＴ５４に関しては、ｅＢＳ３４はＤＡＰとして作用し、ｅＢＳ３６はＲＬＳＥとして義務を実行し、そして、ｅＢＳ３８は、ＦＬＳＥとしての役割を引き受ける。
【００２６】
無線通信における信頼性(reliability)のために、またさらに、通信リソースの効率的な使用のために、ＡＴ５４が、特定の役割を実行する特定の通信エンティティを自由に選択することが好ましい。下記でさらに説明される例示的な実施形態は、上述の必要性に取り組む。
【００２７】
例示的な実施形態にしたがって、ＡＴ５４は、そのメモリにおいてルートセット(Route Set)（ＲＳ）４１を有する。ＲＳ４１は、ＡＴ５４を備えた無線インタフェースのルートを有する、例えばｅＢＳ３６及びｅＢＳ３８のような、１セットの通信エンティティの情報を含んでおり、それによって、ＲＳ４１における各エンティティは、ＡＴ５４で、リンク層パケットとインターネットプロトコル（ＩＰ）パケットの両方、逆もまた同じ、をトンネリングする(tunnel)ことができる。さらに、ＡＴ５４は、ｅＢＳがＲＳに加わる(joins)あるいは離れる(leaves)ときにはいつでも、ＲＳ４１を更新する。
【００２８】
特定の通信エンティティは、ＡＴ５４のＲＳ４１において、特定のルートを有する。例えば、図１で示されているように、ＡＴ５４は、ｅＢＳ３４についてリザーブされた(reserved)ＲＳ４１においてルート３４Ｒを有する。同様に、ＡＴ５４は、ｅＢＳ３６のためにリザーブされたＲＳ４１において、ルート３６Ｒを有する。ＡＴ５４は、ｅＢＳ３８のためにリザーブされたＲＳ４１において、ルート３８Ｒを有する。
【００２９】
ルートは、本質的には、ＡＴと、ＡＴが通信セッション中に通信する通信エンティティと、に特有の１セットのプロトコル及びパラメータである。そのようなプロトコルおよびパラメータは、例えば、ヘッダ圧縮のプロトコル及び構成、無線リンクプロトコル(Radio Link Protocol)（ＲＬＰ）の構成及びシーケンス番号、暗号化アルゴリズム及びネゴシエートされたセキュリティー鍵(negotiated security keys)、等を含む。
【００３０】
ＡＴ５４のＲＳ４１においては、ルート３４Ｒ、３６Ｒ、及び３８Ｒのそれぞれは、同じプロトコル及び構成を含む必要はない。代わりに、ルート３４Ｒ、３６Ｒ、及び３８Ｒは、互いに、論理的に別々であることができる。すなわち、ルート３４Ｒ、３６Ｒ、及び３８Ｒは、それぞれの通信エンティティ３４、３６、及び３８に、または、それぞれの通信エンティティ３４、３６、及び３８から、トンネリングされたデータパケットを処理するために別々に使用される。例によって、図１で、ＡＴ５４がＦＬＳＥとしてｅＢＳ３８に依存するとき、ルート３８Ｒは、プロトコルとパラメータを保存し、特に(among other things)、論理データ経路６４の無線リンク部分に関連づけられたデータパケットシーケンス番号を保存しており、そしてそれは、ＦＬの無線リンク部分であり、ｅＢＳ３８は、ＡＴ５４に対してデータを送信する。
【００３１】
前に言及されるように、ルート３４Ｒ、３６Ｒ、及び３８Ｒのようなルートは、ＡＴ５４のメモリに保存されることができる。さらに、特定の通信エンティティに関連づけられた各それぞれのルートは、その通信エンティティにおいて保存されることができる。例えば、図１で示されているように、ルート３８Ｒは、ｅＢＳ３８に保存される。ルートを搬送しているメモリ回路を含んでいる、ＡＴ５４のための且つこの点の他の通信エンティティのための、ハードウェアインプリメンテーションは、後でさらに説明されるであろう。
【００３２】
アクセスポイントの変更については、ＡＴ５４は、関連性のあるエンティティ(relevant entities)と異なるメッセージを交換する必要がある。説明の目的のために、図２は、図１で示されているように論理データ経路６４を介してＦＬＳＥとしてｅＢＳ３８を確立することにおける、他の通信エンティティを備えたＡＴ５４のための呼び出しフローを示す。
【００３３】
図１に関連して図２の参照がなされる。説明しやすくするために、ｅＢＳ３８は、ターゲットＦＬＳＥ(target FLSE)と呼ばれる。同様に、ｅＢＳ３６はソースＦＬＳＥと呼ばれる。ｅＢＳ３４は、この場合においては、ＤＡＰとして作用する。
【００３４】
ＡＴ５４は、ＦＬＳＥとしてｅＢＳ３６に最初に依存する。したがって、ＡＴ５４は、図２において、それぞれ、論理データ経路６６及び６８によって示されているように、ＤＡＰ、この場合ではｅＢＳ３４である、から、ソースＦＬＳＥ、この場合ではｅＢＳ３６である、を介してインターネットプロトコル（ＩＰ）データパケットを受信する。
【００３５】
前に述べたように、ＡＴ５４がサービスエリア５０の近接(vicinity)に接近して移動し、ｅＢＳ３８から強いＦＬ信号を検出する、と仮定する。ＡＴ５４は、ターゲットＦＬＳＥとしてｅＢＳ３８を選択することを決定する。すなわち、ＡＴ５４は、ｅＢＳ３６からｅＢＳ３８へと、ＦＬＳＥをハンドオフすることを決定する。そのようなハンドオフについての基準は、１セットの通信条件に基づくことができ、例えば、ｅＢＳ３８を備えたよりよいリンク条件、ｅＢＳ３６とｅＢＳ３８のロードの比較、ｅＢＳ３６とｅＢＳ３８に関しての使用の持続時間、等がある。
【００３６】
ＡＴ５４は、図２で示されるメッセージ経路７０によって示されているように、ｅＢＳ３８にメッセージ、あるいはチャネル品質インジケータ（ＣＱＩ）のような物理層信号を送信することによって、ｅＢＳ３８をターゲットＦＬＳＥとして選択する。
【００３７】
メッセージを受信すると、ターゲットＦＬＳＥ３８は、ＡＴ５４のＲＳにおけるすべての他のeＢＳsに、ｅＢＳ３８がＡＴ５４のためのＦＬＳＥとしての役割を引き受けたということを通知する。ターゲットＦＬＳＥ３８による通知(notification)は、同時にあるいは連続して(simultaneously or sequentially)、他のエンティティに送信されることができる。例えば、ソースＦＬＳＥ３６に対する通知は、図２で示されているように、メッセージ経路７２を介した、ＩＰＴ（ＩＰトンネル）−通知メッセージ(an IPT (IP Tunnel)-Notification message)である。ソースＦＬＳＥ３６は、図２で示されるように、メッセージ経路７４を介して、ＩＰＴ−通知ＡｃｋメッセージをターゲットＦＬＳＥ３８に送信することによって、ＩＰＴ−通知メッセージの受信を承認する(acknowledges)。
【００３８】
別の例として、ターゲットＦＬＳＥ３８はまた、図２で示されるように、メッセージ経路７６を介して、ＩＰＴ-通知メッセージをＤＡＰ３４に送信する。同様に、ＤＡＰ３４は、図２で示されているように、メッセージ経路７８を介して、ＩＰＴ-通知ＡｃｋメッセージをソースＦＬＳＥ３８に送信することによって、ＩＰＴ−通知メッセージの受信を承認する。
【００３９】
ソースＦＬＳＥ３６の場合、ＩＰ−通知メッセージ、すなわちメッセージ経路７２を介して送信されたメッセージ、を受信すると、ソースＦＬＳＥ３６は、ＤＡＰ３４からの受信されたＩＰパケットを、ＡＴ５４ではなくてターゲットＦＬＳＥ３８へと、転送するあるいはトンネリングする必要がある。
【００４０】
この実施形態にしたがって、ソースＦＬＳＥ３６は、ターゲットＦＬＳＥ３８に対して、ＩＰパケットフレームによって定義されるような、ディスクリートＩＰパケット(discrete IP packets)をトンネリングする必要がない。代わりに、ソースＦＬＳＥ３６が、ターゲットＦＬＳＥ３８に対して、部分ＩＰパケットをトンネリングすることができる。より具体的には、時間が経過するときのソースＦＬＳＥ３６へのＩＰデータパケットフローの図を概略的に示す図３が参照される。図３に、５つのＩＰパケットフレームによって示されるように、５つのＩＰパケット、すなわちＩＰパケット＃１−＃５が示されている。時間ｔａにおいて、ソースＦＬＳＥ３６は、メッセージ経路７２を介してのようにＩＰＴ−通知メッセージを受信する、と仮定する（図２）。時間ｔａの前に受信される全体のＩＰパケット＃１及び＃２の場合、ソースＦＬＳＥ３６は、ＡＴ５４について予定されたリンク層ヘッダでこれらのＩＰパケットをカプセル化し、ＡＴ５４にＩＰパケットを送信する。異なることばで表すように(Phrased differently)、ソースＦＬＳＥ３６は、論理データ経路６０の無線リンク部分を通してリンク層トンネルを介してＡＴ５４にＩＰパケット＃１-２を送信する（図１）。
【００４１】
ＡＴ５４については、先に言及したように、ルート、具体的にはルート３６Ｒ（図１）、を有しており、それは、ｅＢＳ３６から受信されたリンク層トンネルパケットの処理のためにリザーブされている。
【００４２】
ＩＰパケット＃３の部分的な部分に関しては、図３の参照番号５１によって識別され、そしてそれは、時間ｔａの前にソースＦＬＳＥ３６によって受信されており、ソースＦＬＳＥ３６は、全体的なＩＰパケット＃１及び＃２について同様な方法で、ＡＴ５４に、部分ＩＰパケット＃３ ５１を送信する。すなわち、ソースＦＬＳＥ３６は、部分ＩＰパケット＃３ ５１を区分化し、そして、図１で示されているように、論理データ経路６０の無線リンク部分を通してのＡＴ５４への送信のために、区分化された部分をリンク層フレームにフィットさせる(fits)（図２で、論理データ経路６８によって表示される）。再び、ＡＴ５４は、全体的なＩＰパケット＃１および＃２について同様な方法で、部分ＩＰパケット＃３ ５１を受信し、処理する。
【００４３】
ＩＰパケット＃３の部分的な部分に関しては、参照番号５５によって識別され、そしてそれは、時間ｔａの後でソースＦＬＳＥ３６によって受信されており、ソースＦＬＳＥ３６は、ソースＦＬＳＥ３６のルート３６Ｒを使用して部分パケット５５を処理し（例、ＲＬＰヘッダを暗号化し、及び／または、加え）、そのあとで、この部分ＩＰパケット＃３ ５５を図１の論理データ経路８０のバックホール部分を通して、ターゲットＦＬＳＥ３８に送信する（図２では、論理データ経路８２によって表されている）。
【００４４】
部分ＩＰパケット＃３ ５５を受信すると、ターゲットＦＬＳＥ３８は、ターゲットＦＬＳＥ３８のルート３８Ｒを使用して、部分ＩＰパケット５５（例、ルート３６Ｒによって加えられたＲＬＰヘッダを含んでいる）をさらに処理し、そして、図１の論理データ経路８０の無線リンク部分を介して、ＡＴ５４に対して、部分ＩＰパケット＃３ ５５をその後で送信する（図２において、論理データ経路８４によって表されている）。
【００４５】
部分ＩＰパケット＃３ ５５については、ＡＴ５４は、ＡＴ５４のルート３８Ｒを使用して部分パケット５５を最初に処理する。その後で、ＡＴ５４は、ＡＴ５４のルート３６Ｒを使用して、部分パケット５５を処理する。異なる表現で言うと、ＡＴ５４は、ＡＴ５４がソースＦＬＳＥ３６から論理的に部分パケット５５を受信するかのように、ターゲットＦＬＳＥ３８を介して、ソースＦＬＳＥ３６から、トンネリングされた部分ＩＰパケット＃３ ５５を受信する。したがって、部分ＩＰパケット＃３ ５１及び５５がルート３６Ｒで処理されるｔａの前に及び後で受信されるので、全体的なＩＰパケット＃３の再構成(reconstruction)は実現可能(feasible)である。上記で説明されるように部分データパケットが組み合わせられることを可能にし、結果として起こる利益は、各データパケットのセグメントがたった一度だけ送信されるので、オーバーザエアリソース(over-the-air resources)がより効率的に使用されることができることである。さらに、正常状態データパケット配信(in-order data packet delivery)を備えたシームレスハンドオフは、達成されることができる。
【００４６】
部分データパケットがこの実施形態において上記で説明されるように組み合わされ、処理される間に、フルデータパケットは、必要であれば同様に組み合わせられ処理されることができるということに注意すべきである。
【００４７】
代替として、さらなる信頼性の目的のために、ソースＦＬＳＥ３６は、論理経路６０及び８０の両方を介してＩＰパケット＃３を送信することができる（図１）。ＡＴ５４のルート３６Ｒは、ＩＰパケット＃３のある部分の複製コピー(duplicate copies)を受信することができる。しかしながら、ＡＴ５４は、当技術分野において知られているように、ＲＬＰにおける複製検出メカニズムを介して、複製部分を廃棄することができる。
【００４８】
ソースＦＬＳＥ３６にいずれの残りのＩＰデータパケットがある場合には、ソースＦＬＳＥ３６は、ターゲットＦＬＳＥ３８に残りのパケットを送信し、ターゲットＦＬＳＥ３８のルート３８Ｒを使用してパケットを代わりに処理し、そのあとで、図１で示されているように論理データ経路８０を介して（図２では、上記で図示された論理データ経路は、それぞれ、参照番号８６と８８によって識別されている）、ＡＴ５４に、処理されたパケットを送信する。データパケットを受信すると、ＡＴ５４は、ＡＴ５４において保存されたルート３８Ｒを使用してパケットを処理する。
【００４９】
ＤＡＰ３４に関して、時間ｔｂのときに（図３）、ＤＡＰ３４は、メッセージ経路７６（図２）を介して、ＩＰＴ−通知メッセージを受信する。時間ｔｂの前に受信される全体のＩＰパケット＃１−＃３については、ＤＡＰ３４は、ソースＦＬＳＥ３６に、ＩＰパケット＃１−＃３をトンネリングし、そしてそれは、上記で説明されたのと同様な方法において受信されたＩＰパケットを代わりに取り扱う。しかしながら、ＩＰパケット＃４については、ソースＦＬＳＥ３６はいずれの部分的に受信されたＩＰパケットを適切に扱うであろうということをＤＡＰ３４が認識しているので、ＤＡＰ３４は、ソースＦＬＳＥ３６に全体のパケットをトンネリングする。すなわち、ＩＰパケット＃１−＃４については、ＤＡＰ３４は、図１で示されているように論理データ経路６０を通してソースＦＬＳＥ３６を介して（図２では、上記で図示された論理データ経路は、それぞれ、参照番号６８と６６によって識別されている）ＡＴ５４にデータパケットを送信する。
【００５０】
時間ｔｂの後で受信されたいずれのＩＰパケット、例えば図３で示されているＩＰパケット＃５、について、ＤＡＰ３４は、前に述べたように図１で示される論理データ経路６４を介して（図２では、論理データ経路は、それぞれ参照番号９０と９２によって識別される）パケットを代わりに取り扱う、ターゲットＦＬＳＥ３８にパケットをトンネリングする。パケットを受信すると、ＡＴ５４は、前にも述べた、ルート３８Ｒ（図１）においてパケットを処理する。
【００５１】
図３に関連して、図２に戻って参照する。より簡単に述べると、ソースＦＬＳＥ３６の場合、図１で示される論理データ経路６０によって示されているように、時間ｔｂの前に、ＤＡＰ３４から受信されたフルあるいは部分のＩＰパケットはＡＴ５４にトンネリングされる。しかしながら、ソースＦＬＳＥ３６については、時間ｔａの後のＤＡＰ３４から受信されたフルあるいは部分のＩＰパケットは、図１で示される論理データ経路８０のバックホール部分によって示されるように、ターゲットＦＬＳＥ３８にトンネリングされる。ターゲットＦＬＳＥ３８は、そのあとで、図１で示され、それぞれ論理データ経路８０及び６４の無線リンク部分によって示されているように、ＡＴ５４に対して、受信された部分及びフルＩＰパケットをトンネリングする。
【００５２】
同様に、ＤＡＰ３４については、時間ｔｂの前にあるいは時間ｔｂの間に、受信されたフルＩＰパケットは、図１で示される論理データ経路６０のバックホール部分によって示されるように、ソースＦＬＳＥ３６に対して送信される。しかしながら、時間ｔｂの後で受信されるフルＩＰパケットは、図１で示される論理データ経路６４のバックホール部分によって示されているように、ターゲットＦＬＳＥ３８に対してトンネリングされる。後で、ターゲットＦＬＳＥ３８は、図１で示された論理データ経路６４の無線リンク部分によって示されるように、ＡＴ５４に、受信されたフルＩＰパケットをトンネリングする。
【００５３】
もはやサービングＦＬＳＥではないという、ソースＦＬＳＥ３６への通知が続く。この目的を達成するために、ＤＡＰ３４は、図２で示されるメッセージ経路９４を介して、ＡＴ５４のためのサービングＦＬＳＥとしての義務の遂行に対し(discharge of the duty)、ＦＬＳＥ３６に通知して、ソースＦＬＳＥ３６に、ＩＰＴ−通知メッセージを送る。
【００５４】
ソースＦＬＳＥ３６は、図２で示されるメッセージ経路９６を介して、ＩＰＴ−通知Ａｃｋメッセージで応答する。
【００５５】
経路９４と９６を介してメッセージを交換することによって、上述の通知は、以下、「ネガティブの通知(negative notification)」と呼ばれる。ネガティブの通知は、ＦＬＳＥあるいはＲＬＳＥが正しく割り当てられる、さらなるセーフガード(an additional safeguard)として役立つ。不整合性があるイベントにおいて、正しいメカニズムは、訂正(rectification)のためにインストールされることができ、そして後でさらに説明されるであろう。
【００５６】
上記で、ＡＴ５４がサービングＦＬＳＥとしてｅＢＳ３８を選択することを説明している。ＡＴ５４は、ＲＬ条件は、現在のサービングＲＬＳＥのそれ、この場合はｅＢＳ３６である、により好都合であるということを決定し、ｅＢＳ３６からｅＢＳ３８へとサービングＦＬＳＥを切り替えるという点において利点があまりないようである、ということを仮定する。そのようなシナリオの下では、ＡＴ５４は、ｅＢＳ３６からｅＢＳ３８へＲＬＳＥのハンドオフを始めることができる。
【００５７】
ＲＬＳＥのハンドオフがＦＬＳＥについての対応するハンドオフとは異なる、ある態様がある。ＦＬＳＥハンドオフの間に、あるいは、一般にＦＬデータフローの間、ＡＴが随意にいずれの通信エンティティとも通信することができるので、ＤＡＰは、ＡＴ５４が次第に通信することを決定する通信エンティティに適切なＦＬデータフローを指図するために、データアンカリングエンティティ(data anchoring entity)として必要とされる。しかしながら、対応するＲＬＳＥハンドオフの間に、あるいは、一般にＲＬデータフローの間、ＤＡＰにとって、データアンカリングエンティティとしての必要性はないかもしれない。その理由は、ＡＴからＲＬデータフローを受信しているいずれの通信エンティティは、まっすぐに、ＡＧＷに受信されたデータを送信することができるからである。実際、このアプローチは、バックホール使用をさらに合理化する(streamlines)ので、好まれる。
【００５８】
例として図１に戻って参照する。前に説明されるように、それぞれ論理データ経路６０及び６４からの、ソースｅＢＳ３６からターゲットｅＢＳ３８までのＦＬＳＥハンドオフの間に、アンカリングエンティティとして作用しているＤＡＰ、この場合ではｅＢＳ３４、が必要とされる。その理由は、ハンドオフの完了の前に、どのｅＢＳをＡＴ５４がターゲットＦＬＳＥとして結局選択するのかをまだ決めていない可能性があるからである。ＤＡＰ３４の関数は、ハンドオフの間に及びハンドオフの後で、ＡＴ５４によって、選択されたターゲットＦＬＳＥに対して、ＦＬデータトラフィックを、適切に命令することである。ＦＬＳＥハンドオフを容易にするために、ＡＴ５４、ＡＧＷ３２、ｅＢＳ３４、ｅＢＳ３６、及びｅＢＳ３８を含んでいるすべての通信エンティティは、それらの中のどのエンティティがＡＴ５４のための現在のＦＬＳＥであるかという跡をつける(keep track)必要があるということもまた上述する必要がある。
【００５９】
ＲＬＳＥハンドオフに関して、ＡＴ５４がソースｅＢＳ３６からターゲットｅＢＳ３８までのＲＬデータフローをハンドオフすることを決定する、と仮定する。ＡＴ５４は、図１に示されるように、論理データ経路６２から論理データ経路８３へと、ＲＬを切り替えることを選択することができたであろう。具体的には、論理データ経路８３を介してＲＬデータフローを送信することは、ＤＡＰとしてｅＢＳ３４に依存する。しかしながら、この例において、通信リソースをより効率的に使用するために、ＡＴ５４は、図１で示されるように、また、代替として、論理データ経路８５を介して、ＡＧＷ３２に対して、ターゲットｅＢＳ３８を通してＲＬデータパケットを直接に送信する。この場合においては、いくつかの通信エンティティ、例えばｅＢＳ３４、ｅＢＳ３６、及びｅＢＳ３８は、どのエンティティがＡＴのための現在のＲＬＳＥであるかという跡をつける必要はない。その理由は、通信システム３０内にあり、ＲＬデータパケットの行先(destination)は、確認されたＡＧＷ３２である。すなわち、ＲＬデータパケットの行先は、不確かなターゲットではない。
【００６０】
ターゲットＲＬＳＥ３８へのソースＲＬＳＥ３６のハンドオフのためのプロセスは、前に説明されたＦＬＳＥカウンターパート(FLSE counterpart)について説明されたものと本質的には同様であるが、上記で強調されるような差異を備えている。さらに、ＡＴ５４は、ターゲットＲＬＳＥ３８に、メッセージ、あるいは、図４で示されるメッセージ経路９７によって識別されるようなパイロット品質インジケータ(Pilot Quality Indicator)（ＰＱＩ）のような物理層信号、を送信することによって、ＲＬＳＥ変更をリクエストする。簡潔さと明瞭さのために、ＲＬＳＥハンドオフプロセスは、さらに詳述されていない。代わりに、論理データ経路６２−８５（図１）の、ソースＲＬＳＥ３６からターゲットＲＬＳＥ３８までのＲＬＳＥハンドオフが図４で図示されている。
【００６１】
上記で説明されたＦＬＳＥ及びＲＬＳＥのハンドオフプロセスにおいて、これまで通信条件を変更することにより、メッセージング信号(messaging signals)は、必ずしも、時間どおりに到着するとは限らない。結果として、意図されたＦＬＳＥあるいはＲＬＳＥは、誤って割り当てられることができるということは、可能である。図５は、誤ったＦＬＳＥ割り当ての例を図示する。この実施形態において、救済プロシージャ(remedial procedures)は、間違った割り当てを訂正する(rectify)ために、設けられている。
【００６２】
図５を参照する。ＡＴ５４が、ＤＡＰとしてｅＢＳ３４を、また、ＦＬＳＥとしてｅＢＳ３６を、最初に割り当てる、と仮定する。そのため、図５で示されているように、それぞれ、データ経路１００及び１０２を介して、ＤＡＰ３４は、ＡＴ５４にＩＰパケットを代わりにトンネリングするｅＢＳ３６に対して、ＩＰパケットを転送する。
【００６３】
ＡＴ５４がｅＢＳ３８を備えたよりよいＦＬがあるということを決定するということを仮定する。様々なあらかじめ定義された通信条件を重みづけて、ＡＴ５４は、ｅＢＳ３６からｅＢＳ３８へとＦＬＳＥを変更することを決定する。ＡＴ５４は、図５に示されているように、メッセージ経路１０４を介して、リクエストメッセージをｅＢＳ３８に送る。
【００６４】
メッセージ経路１０４を介してメッセージを受信すると、図５で示されたメッセージパス１０６を介してｅＢＳ３６に送信されたＩＰＴ−通知メッセージによって類型化されるように、ｅＢＳ３８がＡＴ５４のためのＦＬＳＥとして役割を引き受けたということをＡＴ５４のＲＳのすべてのｅＢＳｓに、ｅＢＳ３８は、通知する。ｅＢＳ３６は、メッセージ経路１０８を介して、ＩＰＴ−通知Ａｃｋメッセージで応答する。
【００６５】
理想的には、ｅＢＳ３８は、同様の通知メッセージ、すなわち、図５で示されたメッセージパス１２０を介して送信されたメッセージ、を遅延なしに、ＤＡＰ３４に送信すべきであった。しかしながら、この例においては、そのようなメッセージの入手可能性が遅延される、すなわち、ｅＢＳ３８によって時期尚早に(untimely)送信されるか、あるいは、ＤＡＰ３４によって遅れて(belatedly)受信される、と仮定する。遅延の理由は、ｅＢＳ３８の回路あるいはＤＡＰ３４によって引き起こされる可能性がある。遅延は、ｅＢＳ３８とＤＡＰ３４との間の好ましくない通信条件によって引き起こされる可能性がある。
【００６６】
いずれのイベントにおいても、メッセージ経路１２０を介してタイムリーに送信されるべきだったＩＰＴ−通知メッセージを送信する前に、この例におけるｅＢＳ３８は、図５で示されるようにメッセージ経路１１０を介してリクエストメッセージを送信することによって、ＦＬＳＥとしてｅＢＳ３６を再び選択する。
【００６７】
再び、ｅＢＳ３６は、図５で示された、メッセージパス１１２を介してｅＢＳ３８に送信されたＩＰＴ−通知メッセージ、によって類型化されるように、ｅＢＳ３６は、ＡＴ５４のためのＦＬＳＥとしての役割を引き受けたということをＡＴ５４のＲＳのすべてのｅＢＳｓに通知する。ｅＢＳ３８は、メッセージ経路１１４を介して、ＩＰＴ−通知Ａｃｋメッセージで応答する。
【００６８】
一例において、図５で示されるように、ＤＡＰ３４に対してメッセージ経路１１６を介してＩＰＴ−通知メッセージをタイムリーに送信し、ＤＡＰ３４からメッセージ経路１１８を介してＩＰＴ−通知Ａｃｋメッセージをタイムリーに受信する、と仮定する。前に述べたように、例示的な実施形態にしたがって、ＤＡＰ３４はまた、他のｅＢＳｓに対しさらなるセーフガードとして、それらがＦＬＳＥではないということをネガティブの通知でフォローする(follows up with)。
【００６９】
しかしながら、この時点で、早くに到達すべきだったメッセージ経路１２０を介してＩＰＴ−通知メッセージが、どういうわけか到達し、ＤＡＰ３４によって受信される、と仮定する。ＤＡＰ３４は、図５で示されるメッセージ経路１２２によって示されるように、ＩＰＴ−通知Ａｃｋメッセージで応答する。それにもかかわらず、意図されたＦＬＳＥ３６によってメッセージ経路１１６を介してより早く送信された、ＩＰＴ−通知メッセージの受信の結果として起こるネガティブの通知はまた、他のｅＢＳｓに対して、ＤＡＰ３４によって送信される。そのようなネガティブの通知は、例えば図５で示されているように、メッセージ経路１２４を介して、ｅＢＳ３８に送信される。ここで、ｅＢＳ３８は、早くから、ＦＬＳＥとしての役割を引き受けたということをＡＴ５４のＲＳにおける他のエンティティに対し通知メッセージを送信するので、不整合性(inconsistence)を検出すべきである。しかしながら、メッセージ経路１２４を介して受信されたメッセージは、ｅＢＳ３８はＡＴ５４のためのＦＬＳＥではないという整合性のないポジション(inconsistent position)をｅＢＳ３８に通知する。イベントは、さらなる照会(inquiry)及び起こりうる修正(eventual rectification)のために、アクションをトリガすることができる。この実施形態においては、救済アクション(remedial actions)は、下記で説明されるように、ｅＢＳ３６、すなわち、最初に意図されたＦＬＳＥ、によって行われる。
【００７０】
図５を続けて参照する。メッセージ経路１２０を介したＩＰＴ−通知メッセージの受信の結果として、ＤＡＰ３４はまた、ｅＢＳ３８の他にＡＴ５４のＲＳの他のｅＢＳｓに対して、それらがＡＴ５４のためのＦＬＳＥではないというネガティブの通知メッセージを送信する。そのようなメッセージのうちの１つは、図６で示されるｅＢＳ３６に対して、メッセージ経路１２８を介して送信されたメッセージである。ｅＢＳ３６は、図５で示されたメッセージ経路１３０を介して、ＩＰＴ−通知Ａｃｋメッセージで応答する。
【００７１】
ここで、早くからｅＢＳ３６がＦＬＳＥとして役割を果たすＡＴ５４のＲＳにおける他のエンティティに対して通知メッセージを送信しているので、ｅＢＳ３６はまた、不整合性を検出すべきである。それにもかかわらず、メッセージ経路１２８を介して受信されたメッセージは、ｅＢＳ３６に、ｅＢＳ３６はＡＴ５４のためのＦＬＳＥではないという整合性のないポジションを、通知する。イベントは、正しい測定のために、動いているｅＢＳ３６を設定する。例えば、この実施形態において、ｅＢＳ３６は、自発的に、前に図２で示され説明されるようにＦＬＳＥスイッチプロセス１３２を再開することができる。
【００７２】
図６は、上記で説明されるようなハンドオフプロセスを実行するための装置のハードウェアインプリメンテーションの一部を示す。回路装置は、参照番号２９０によって示され、また、ＡＴあるいはいずれの通信エンティティ、例えばｅＢＳまたはＡＧＷ、においてインプリメントされることができる。
【００７３】
装置２９０は、いくつかの回路を一緒にリンクさせる中央データバス２９２を備える。回路は、ＣＰＵ（中央処理装置）、あるいは、コントローラ２９４、受信回路２９６、送信回路２９８、及びメモリユニット３００を含む。
【００７４】
装置２９０が無線装置の一部である場合、受信回路２９６と送信回路２９８は、図面には示されてはいないがＲＦ（無線周波数）回路に接続されることができる。受信回路２９６は、データバス２９２に送信する前に、受信信号を処理し、バッファする。他方で、送信回路２９８は、デバイス２９０から送信する前にデータバス２９２からデータを処理し、バッファする。ＣＰＵ／コントローラ２９４は、データバス２９２のデータ管理の関数、さらに一般的なデータ処理の関数を実行し、メモリユニット３００の命令コンテンツ(instructional contents)を実行することを含む。
【００７５】
代替として、図６で示されるように別々に配列される(separately disposed)代わりに、送信回路２９８及び受信回路２９６は、ＣＰＵ／コントローラ２９４の一部分であることができる。
【００７６】
メモリユニット３００は、参照番号３０２によって一般に示された１セットのモジュールおよび／またはインストラクションを含む。この実施形態においては、モジュール／インストラクションは、特に(among other things)、ＦＬＳＥハンドオフ関数３０８とＲＬＳＥハンドオフ関数３１０を含む。ハンドオフ関数３０８及び３１０は、図１−５で示され、説明されるプロセスステップを実行するための、コンピュータインストラクションあるいはコードを含む。エンティティ特有の具体的なインストラクションは、ハンドオフ関数３０８および３１０で、選択的にインプリメントされることができる。例えば、装置２９０がＡＴの一部分である場合、特に(among other things)、図２、４、及び５において示され説明されるＡＴに関連したメッセージの準備及び処理と共に、図１−５で示され説明されるプロセスステップを実行するためのインストラクションは、ハンドオフ関数３０８及び３１０でコード化されることができる。同様に、装置２９０が通信エンティティ、例えばｅＢｓ、の一部である場合には、その通信エンティティ特有のプロセスステップ及びメッセージの準備は、ハンドオフ関数３０８及び３１０でコード化されることができる。
【００７７】
さらに、図１で示され説明される、ルート３４Ｒ、３６Ｒ、及び、３８Ｒのような複数のルートはまた、メモリユニット３００に含まれることができる。ルートは、図６の参照番号３９８によって集約的に示されている。代替として、ルート３９８は、ユニット３００の他に、１つまたは複数の他のメモリユニットに保存されることができる。上記で配置されるような同様な方法で、選択ルートは、インプリメンテーションにおいて特定のエンティティについてインストールされることができる。例えば、ＡＴ５４について、図１で示され、説明されるように、３４Ｒ、３６Ｒ及び３８ＲのようなＲＳにあるすべてのルートを含むことが必要とする一方で、例えばｅＢＳ３６については、ルート３６Ｒだけがメモリユニット３００でインストールされる必要がある。
【００７８】
この実施形態においては、メモリユニット３００は、ＲＡＭ（ランダムアクセスメモリ）回路である。ハンドオフ関数３０８及び３１０のような例示的な関数は、ソフトウェアのルーチン、モジュール、および／または、データセット、である。メモリユニット３００は、揮発性あるいは不揮発性のタイプのいずれかになりえる別のメモリ回路（示されていない）と結び付けられることができる。代替として、メモリユニット３００は、例えばＥＥＰＲＯＭ（電子的消去可能プログラマブル読み取り専用メモリ）、ＥＰＲＯＭ（電子的プログラマブル読み取り専用メモリ）、ＲＯＭ（読み取り専用メモリ）、ＡＳＩＣ（特定用途向け集積回路）、磁気ディスク、光ディスク、及び当技術分野においてよく知られた他のもの、ような他の回路タイプから成ることができる。
【００７９】
説明される発明のプロセス(inventive processes)はまた、当技術分野で知られたいずれのコンピュータ可読メディア上で実行されるコンピュータ可読インストラクションとしてコード化されることができるということは、さらに注目すべきである。この明細書及び添付された特許請求項において、用語「コンピュータ可読メディア(computer-readable medium)」は、実行のために、例えば、図６の図面で示され説明されたＣＰＵ／コントローラ２９４のようないずれのプロセッサにインストラクションを提供することに関与するいずれのメディアを指す。そのようなメディアは、ストレージタイプであってもよく、例えば、図６のメモリユニット３００の説明において、また前に説明されたような、揮発性あるいは非揮発性のストレージメディアの形態をとることができる。そのようなメディアはまた、送信タイプであることができ、同軸ケーブル、銅線、光ケーブル(optical cable)、そして、マシンあるいはコンピュータによって読み取り可能な信号を搬送することができる聴覚波、電磁波、あるいは光学波、を搬送している無線インタフェース、を含むことができる。コンピュータ可読メディアは、装置２９０とは別のコンピュータプロダクトの一部であることができる。
【００８０】
最後に、本発明の範囲内での他の変更は、可能である。上記で説明される他に、実施形態に関連して、いずれの他の論理ブロック、回路、及びアルゴリズムステップも、ハードウェア、ソフトウェア、ファームウェイア、あるいはそれらの組み合わせでインプリメントされることができる。形式と及び詳細におけるこれら及び他の変更は、本発明の範囲及び精神から逸脱することなく行われることができるということが、当業者によって理解されるであろう。
【技術分野】
【０００１】
本発明は、一般に、通信に関し、より具体的には、無線通信システムにおけるサービングアクセスポイントの切り替え(switching of serving access points)に関する。
【背景技術】
【０００２】
テレコミュニケーションにおいて、特に無線通信においては、通信環境は、静的なものではなく、むしろ動的なものである。モバイル通信の設定においては、いくつかのモバイル通信エンティティ(mobile communication entities)は、一般にはモバイル局と呼ばれており、異なるときに、異なる通信条件の下、異なる位置へと移動することができる。
【０００３】
無線ネットワークにおいては、モバイル局は、一般には基地局と呼ばれる、あるインフラストラクチャ通信エンティティ(infrastructure communication entities)、を介してメインネットワークにアクセスする。データが基地局からモバイル局へと流れる通信接続は、順方向リンク(forward link)（ＦＬ）と呼ばれる。同様に、データがモバイル局から基地局へと流れる通信接続は、逆方向リンク(reverse link)（ＲＬ）と呼ばれる。通信条件(communication conditions)は、ＦＬとＲＬの両方にとって、必ずしも同じだとは限らない。例えば、モバイル局は、高い混雑ＲＬトラフィック(a highly congestive RL traffic)を有しているが比較的オープンなＦＬフロー(a relatively open FL flow)を有している、サービング基地局と通信していてもよい。よりよいＲＬは他の基地局から利用可能であるがＦＬ及びＲＬの両方のために基地局と一緒にとどまるモバイル局については、通信リソースの最良の使用ではない可能性がある。
【０００４】
さらに、メインネットワークにアクセスする１つの基地局から別の基地局へと変わるモバイル局については、ＦＬ変更あるいはＲＬ変更であろうと、変更の間に変更の後で交換されたデータパケットが、無傷(intact)のままであることは好ましい。ボイスオーバーＩＰ(Voice over IP)（ＶｏＩＰ）呼び出しにおいて交換されたデータパケットのような時間センシティブなデータパケット(time-sensitive data packets)に特に当てはまる。弾性のデータパケットあるいはベストエフォートデータパケット(elastic or best-effort data packets)とは異なり、伝送の間の、誤りのあるいは逃した時間センシティブパケットは、必ずしも再送信されない。したがって、基地局の変更の間の時間センシティブデータパケットの妨害(disruption)は、サービスの品質に影響を与える可能性がある。
【０００５】
したがって、利用可能な通信リソースを適切に且つ効率的に使用し、さらにハンドオフプロセス(handoff process)の間にデータ整合性(data integrity)を維持するために、モバイル局は、ＦＬ及びＲＬの割り当てについていずれのサービング通信エンティティ(serving communication entities)を自由に選択する必要がある。
【発明の概要】
【０００６】
（米国特許法第１１９条の下の優先権主張）
本願は、２００７年４月２５日に出願された仮出願第６０／９１３，９１１号、および、２００７年６月１２日に出願された仮出願第６０／９４３，４３４号の優先権をそれぞれ主張しており、すべては、ここでの譲受人に譲渡されており、また、ここにおいて参照することにより、明示的に組み込まれる。
【０００７】
モバイル局が複数の基地局を介してメインネットワークにアクセスしている通信システムにおいて、モバイル局は、順方向リンク(forward link)（ＦＬ）サービング局としていずれの基地局も自由に選択することができる。さらに、モバイル局はまた、逆方向リンク(reverse link)（ＲＬ）サービング局として、別の基地局あるいは同じ基地局を自由に選択することができる。モバイル局は、そのメモリに、複数の基地局に対応する複数のルート(a plurality of routes)を保存し、各ルートは、特定の基地局に専属的に(dedicatedly)割り当てられている。ＦＬサービング局あるいはＲＬサービング局のいずれかとして、１つの基地局から別の基地局へのハンドオフの間に、交換されたデータパケットは、関与した基地局のそれぞれのルートにおいて、処理される。さらに、ルートはまた、部分的に転送されたデータパケット(partially transferred data packets)を処理することに依存しており、その結果、ハンドオフプロセスの間にトランスパレントでシームレスなデータの転送(transparent and seamless transfer of data)を可能にする。
【０００８】
これらの及び他の特徴および利点は、詳細な説明から、同様の参照番号は同様の部分を指す添付図面と一緒に使用して、当業者にとって明らかであろう。
【図面の簡単な説明】
【０００９】
【図１】図１は、本発明の例示的な実施形態にしたがって配置された(arranged)様々な通信のエンティティの関係を図示している、簡略化された概略図である。
【図２】図２は、例示的な実施形態にしたがって動作している順方向リンクサービング局のハンドオフの間の、異なる通信エンティティの中のメッセージ及びデータフローを示す、呼び出しフロー図である。
【図３】図３は、異なる通信エンティティが異なるＩＰデータパケットのトンネリング(tunneling)の責任を負う、ＩＰデータパケットのフローの図を概略的に示す。
【図４】図４は、例示的な実施形態にしたがって動作している逆方向リンクサービング局のハンドオフの間の、異なる通信エンティティの中のメッセージ及びデータフローを示す、呼び出しフロー図である。
【図５】図５は、順方向リンクサービング局が誤って割り当てられるが整流(rectification)で訂正されるハンドオフの間の、異なる通信エンティティの中のメッセージ及びデータフローを示す、呼び出しフロー図である。
【図６】図６は、例示的な実施形態にしたがってハンドオフプロセスを実行するための装置のハードウェアインプリメンテーションの部分の概略図である。
【発明を実施するための形態】
【００１０】
以下の説明は、当業者が本発明を作り使用することを可能にするために提示されている。詳細は、説明の目的のために次の説明で記載されている。本発明はこれらの具体的な詳細の使用なしに実行されることができるということを当業者が認識するであろうということが、理解されるべきである。他の例においては、既知のストラクチャ及びプロセスは、不必要な詳細で本発明の説明を不明瞭にしないために、詳述されない。したがって、本発明は、示された実施形態によって限定されるようには意図されていないが、ここに開示された原則及び特徴に一貫した最も広い範囲が与えられることになっている。
【００１１】
さらに、以下の説明では、簡略と明瞭性という理由から、電気通信工業会(Telecommunication Industry Association)（ＴＩＡ）による第３世代パートナーシッププロジェクト２(3rd Generation Partnership Project 2)（３ＧＰＰ２）の下で公表されたような、ウルトラモバイルブロードバンド(Ultra Mobile Broadband)（ＵＭＢ）に関連づけられた用語が使用されている。本発明はまた、例えば符号分割多元接続（ＣＤＭＡ）、時分割多元接続（ＴＤＭＡ）、周波数分割多元接続（ＦＤＭＡ）、直交周波数多元接続（ＯＦＤＭＡ）などに関連した技術及び関連の標準のような、他の技術に対して適用可能であるということは強調されるべきである。異なる技術に関連づけられた用語は、異なっていてもよい。例えば、熟考された技術次第で、いくつかだけを挙げると、モバイル局は、ときに、モバイル端末、ユーザ機器、加入者ユニット等と呼ばれることができる。同様に、基地局は、ときに、アクセスポイント、ノードＢ等と呼ばれることができる。異なる用語が、適用可能なときに、異なる用語に適用するということは、ここでは留意すべきである。
【００１２】
本発明の例示的な実施形態にしたがって配置された様々な通信エンティティの関係を概略的に示す、図１を参照する。
【００１３】
図１においては、全体的な通信システムは、参照番号３０によって一般に示される。通信システム３０では、複数の発展した基地局(evolved Base Stations)（ｅＢＳｓ）にリンクしたアクセスゲートウェイ(Access Gateway)（ＡＧＷ）３２があり、３つの発展した基地局は、ｅＢＳ３４、ｅＢＳ３６、及びｅＢＳ３８として示されている。ｅＢＳｓ３４、ｅＢＳ３６、及びｅＢＳ３８は、同じアクセスネットワーク（ＡＮ）において、あるいは異なるＡＮｓにおいて、インストールされることができる。この例において、ｅＢＳｓ３４、３６、及び３８は、それぞれ、ＡＮｓ４０、４２、及び４４の一部分である。ＡＮｓ４０、４２、及び４４のそれぞれは、１つまたは複数のｅＢＳｓ、及び他のエンティティを含んでもよい。明瞭さと簡潔さのために、各ＡＮは、図１においては、１つのｅＢＳのみ示されている。したがって、図１において示されるような実施形態では、ｅＢＳ３４は、サービスエリア４６内のユーザに、無線アクセスを提供する。同様に、ｅＢＳｓ３６及び３８は、サービスエリア４８及び５０内で、それぞれ無線アクセスを提供する。
【００１４】
ＡＧＷ３２は、中枢ネットワーク(a backbone network)５２に対してリンクを有しており、それは例えばインターネットであってもよい。あるいは、別の例として、中枢ネットワーク５２は、例えば閉鎖されたネットワークにおけるイントラネットであってもよい。
【００１５】
システム３０内で展開されたアクセス端末（ＡＴ）５４がある、と仮定する。ユーザによって操作されたＡＴ５４（示されていない）は、ＡＮ４０、ＡＮ４２、及びＡＮ４４を含んでいる、様々な無線ネットワークの中で移動させることができる。ＡＴ５４は、システム３０における様々な通信エンティティを介して、中枢ネットワーク３８にアクセスすることができる。
【００１６】
ＡＴ５４がｅＢＳ３４と最初に通信する、と仮定する。ＡＴ５４は、図１の参照番号５６によって図示される論理データ経路によって示されているように、中枢ネットワーク５２からのデータがＡＧＷ３２及びｅＢＳ３４を介してＡＴ５４へと流れることができるように、ｅＢＳ３４を用いて順方向リンク（ＦＬ）を確立することを最初に必要とする。ＡＴ５４は、ｅＢＳ３４からＦＬデータパケットを直接受信するので、ｅＢＳ３４は、ＡＴ５４のための順方向リンクサービングｅＢＳ(Forward-Link Serving eBS)(ＦＬＳＥ)とも呼ばれる。
【００１７】
多少同様な方法で、ＡＴ５４はまた、図１の論理データ経路５８によって示されているように、ＡＴ５４からのデータがｅＢＳ３４とＡＧＷ３２を介して中枢ネットワークへと流れることができるように、ｅＢＳ３４を用いて逆方向リンク（ＲＬ）を確立することを必要とする。ＡＴ５４がｅＢＳ３４に対して直接ＲＬデータパケットを送信するので、ｅＢＳ３４はまた、ＡＴ５４のための逆方向リンクサービングｅＢＳ(Reverse-Link Serving eBS)（ＲＬＳＥ）と呼ばれる。
【００１８】
図１に示されているように、ＡＴ５４は、それぞれ、ＦＬとＲＬとして、論理データ経路５６及び５８を介して、ｅＢＳ３４を用いてデータを交換する。この例において、ｅＢＳ３４は、ＡＴ５４のためのＦＬＳＥ及びＲＬＳＥの両方としての２重の役割を想定する(assumes)。
【００１９】
さらに、この例において、ｅＢＳ３４はまた、ＡＴ５４のためのデータアタッチメントポイント(Data Attachment Point)（ＤＡＰ）としてサービス提供する。ｅＢＳ３４がＡＴ５４のためのＦＬＳＥとなるとき、ＤＡＰ割り当てプロセスを開始することができる。この目的を達成するために、ｅＢＳ３４は、ＡＧＷ３２に対して、登録リクエストメッセージを送信する。その後で、ＡＧＷ３２は、インターネットエンジニアリングタスクフォース(Internet Engineering Task Force)（ＩＥＴＦ）によって発行されるプロキシモバイルＩＰ（ＰＭＩＰ）プロトコルの下で示されているプロシージャにしたがって、ｅＢＳ３４を用いて、バインディングアップデート(binding update)を実行する。本質的には、ＤＡＰ３４は、ＡＴ５４についてデータアンカリング関数(data anchoring function)を実行する。結果として、ＡＴ５４のためのＦＬＳＥ及びＲＬＳＥとしての役割を想定することに加えて、その場合においては、ｅＢＳ３４はまた、ＡＴ５４のためのＤＡＰの義務を果たす(serves the duty)。別の方法に置き換えると、この例においては、ｅＢＳ３４は、ＡＴ５４のために、ＦＬＳＥ、ＲＬＳＥ、及びＤＡＰ、の３つの役割を果たす。
【００２０】
本発明の例示的な実施形態にしたがって、ｅＢＳ５４のようなシステム３０における通信エンティティは、ＡＴ５４のような、また、前に叙述されているような、任意のＡＴについて、同時に、すべて３つの役割を想定する必要はない。
【００２１】
図１に戻って参照する。ＡＴ５４がｅＢＳ３６によって提供されるサービスエリア４８に移動する、と仮定する。ｅＢＳ３６からのより強い信号及び近接(With closer proximity and stronger signals from the eBS 36)で、ＡＴ５４は、ｅＢＳ３４からｅＢＳ３６へと、ＦＬＳＥとＲＬＳＥの両方をハンドオフすることを決定する。ハンドオフプロセスは、後でより詳細に説明されるであろう。
【００２２】
ハンドオフが成功した、と仮定する。ハンドオフの後、ＦＬの場合には、図１で示された論理データ経路６０によって示される列挙された順序で、中枢ネットワーク５２からのデータパケットは、ＡＧＷ３２、ｅＢＳ３４、及びｅＢＳ３６を介して、ＡＴ５４へと流れる。同様に、ＲＬの場合には、図１で示される論理データ経路６２によって示される列挙された順序で、ＡＴ５４からのデータパケットは、ｅＢＳ３６、ｅＢＳ３４、及びＡＧＷ３２を介して、中枢ネットワーク５２へと流れる。この場合には、ｅＢＳ３６は、ＡＴ５４のためのＦＬＳＥ及びＲＬＳＥとしての２つの役割を想定する。それにもかかわらず、ｅＢＳ３４は、ＡＴ５４のためのＤＡＰとしてまだ作用する。
【００２３】
ＡＴ３４はｅＢＳ３４によってサービス提供されるサービスエリア４６から離れてローミングされるにもかかわらず、ｅＢＳ３４は、ＡＴ５４のためのＤＡＰを残す。その理由は、無線設定において、ＡＴ５４の動き(mobility)によって、ｅＢＳ３４がＡＴ５４のためのＦＬＳＥあるいはＲＬＳＥに再びなることができるということが可能であるからである。例えば、ＡＴ５４は、ｅＢＳ３４及びｅＢＳ３６によってそれぞれ提供されるサービスエリア４６及び４８の境界上にあってもよい。したがって、ＡＴ５４は、一時的にｅＢＳ３６とのみ通信することができる。しかしながら、ＡＴ５４とｅＢＳ３６との間の通信が一時的でない場合、曲がりくねった論理パス(meandering logical data paths)６０及び６２を介してデータパケットをルーティングすることは、少なくともバックホール使用の観点から、通信のリソースの効率的な使用でないかもしれない。さらに、データパケットレイテンシ(data packet latency)もまた、強い影響を与えられる(impacted)。代わりに、ＤＡＰは、ｅＢＳ３４からｅＢＳ３６へと好ましくは切り替えられる。ＤＡＰスイッチについての基準は、特に(among other things)、ＡＴ５４がｅＢＳ３６によって提供されるサービスエリア４８において十分に長くとどまったということであってもよい。ＤＡＰのスイッチの基本的なプロシージャは、電気通信工業会（ＴＩＡ）の下でまとめられた、第３世代パートナーシッププロジェクト２（３ＧＰＰ２）によって発行された、出版物３ＧＰＰ２ Ａ.Ｓ００２０で見つけられることができる。この場合においては、ＤＡＰ変更についての１つまたは複数の基準は満たされてはおらず、ｅＢＳ３４はＡＴ５４のためのＤＡＰとして残る、と仮定する。
【００２４】
続けて図１を参照する。ＡＴ５４は、他のサービスエリアの領域(other coverage territories)に対してローミングすることを続ける、と仮定する。ある時点で、ＡＴ５４は、ｅＢＳ３８によって提供されるサービスエリア５０に達する(reaches)。さらに、何らかの理由で、ＡＴ５４は、強いＦＬだが比較的に低いＲＬをｅＢＳ３８から検知する、と仮定する。「リンクアンバランス(link imbalance)」と呼ばれるそのようなシナリオは、ＲＬに関連づけられた周波数帯域の過度な周波数干渉によってもたらされることができる。干渉は、例えば基地局とのアクティブな通信における、多すぎるＡＴｓ（示されてはいない）によって、もたらされることができる。ＦＬトラフィックは、ｅＢＳｓが異なる周波数帯域を使用し、さらに地理的に離れて遠いので、あまり影響されないかもしれない。別の例として、ｅＢＳ５４が他のＡＴｓ（示されていない）からＲＬ接続でオーバーロードされるが、ＦＬトラフィックはまだ比較的スパース(sparse)である、と仮定する。そのようなシナリオの下では、ＡＴ５４は、ｅＢＳ３６からｅＢＳ３８へとＦＬＳＥを切り替えるために決定することができるが、ＡＴ５４のためのＲＬＳＥとしてｅＢＳ３６を維持する。
【００２５】
ＲＬの場合、ＡＴ５４からのデータパケットは、前に説明されるように、論理データ経路６２を介して、中枢ネットワーク５２へと流れる。しかしながら、ＦＬの場合には、列挙された順序で、図１で示されるデータ経路６４によって示されるように、中枢ネットワーク５２からのデータパケットは、ＡＧＷ３２、ｅＢＳ３４、及びｅＢＳ３８を介してＡＴ５４へと流れる。この場合、３つの異なる通信エンティティは、３つの異なる役割を想定する。具体的に、ＡＴ５４に関しては、ｅＢＳ３４はＤＡＰとして作用し、ｅＢＳ３６はＲＬＳＥとして義務を実行し、そして、ｅＢＳ３８は、ＦＬＳＥとしての役割を引き受ける。
【００２６】
無線通信における信頼性(reliability)のために、またさらに、通信リソースの効率的な使用のために、ＡＴ５４が、特定の役割を実行する特定の通信エンティティを自由に選択することが好ましい。下記でさらに説明される例示的な実施形態は、上述の必要性に取り組む。
【００２７】
例示的な実施形態にしたがって、ＡＴ５４は、そのメモリにおいてルートセット(Route Set)（ＲＳ）４１を有する。ＲＳ４１は、ＡＴ５４を備えた無線インタフェースのルートを有する、例えばｅＢＳ３６及びｅＢＳ３８のような、１セットの通信エンティティの情報を含んでおり、それによって、ＲＳ４１における各エンティティは、ＡＴ５４で、リンク層パケットとインターネットプロトコル（ＩＰ）パケットの両方、逆もまた同じ、をトンネリングする(tunnel)ことができる。さらに、ＡＴ５４は、ｅＢＳがＲＳに加わる(joins)あるいは離れる(leaves)ときにはいつでも、ＲＳ４１を更新する。
【００２８】
特定の通信エンティティは、ＡＴ５４のＲＳ４１において、特定のルートを有する。例えば、図１で示されているように、ＡＴ５４は、ｅＢＳ３４についてリザーブされた(reserved)ＲＳ４１においてルート３４Ｒを有する。同様に、ＡＴ５４は、ｅＢＳ３６のためにリザーブされたＲＳ４１において、ルート３６Ｒを有する。ＡＴ５４は、ｅＢＳ３８のためにリザーブされたＲＳ４１において、ルート３８Ｒを有する。
【００２９】
ルートは、本質的には、ＡＴと、ＡＴが通信セッション中に通信する通信エンティティと、に特有の１セットのプロトコル及びパラメータである。そのようなプロトコルおよびパラメータは、例えば、ヘッダ圧縮のプロトコル及び構成、無線リンクプロトコル(Radio Link Protocol)（ＲＬＰ）の構成及びシーケンス番号、暗号化アルゴリズム及びネゴシエートされたセキュリティー鍵(negotiated security keys)、等を含む。
【００３０】
ＡＴ５４のＲＳ４１においては、ルート３４Ｒ、３６Ｒ、及び３８Ｒのそれぞれは、同じプロトコル及び構成を含む必要はない。代わりに、ルート３４Ｒ、３６Ｒ、及び３８Ｒは、互いに、論理的に別々であることができる。すなわち、ルート３４Ｒ、３６Ｒ、及び３８Ｒは、それぞれの通信エンティティ３４、３６、及び３８に、または、それぞれの通信エンティティ３４、３６、及び３８から、トンネリングされたデータパケットを処理するために別々に使用される。例によって、図１で、ＡＴ５４がＦＬＳＥとしてｅＢＳ３８に依存するとき、ルート３８Ｒは、プロトコルとパラメータを保存し、特に(among other things)、論理データ経路６４の無線リンク部分に関連づけられたデータパケットシーケンス番号を保存しており、そしてそれは、ＦＬの無線リンク部分であり、ｅＢＳ３８は、ＡＴ５４に対してデータを送信する。
【００３１】
前に言及されるように、ルート３４Ｒ、３６Ｒ、及び３８Ｒのようなルートは、ＡＴ５４のメモリに保存されることができる。さらに、特定の通信エンティティに関連づけられた各それぞれのルートは、その通信エンティティにおいて保存されることができる。例えば、図１で示されているように、ルート３８Ｒは、ｅＢＳ３８に保存される。ルートを搬送しているメモリ回路を含んでいる、ＡＴ５４のための且つこの点の他の通信エンティティのための、ハードウェアインプリメンテーションは、後でさらに説明されるであろう。
【００３２】
アクセスポイントの変更については、ＡＴ５４は、関連性のあるエンティティ(relevant entities)と異なるメッセージを交換する必要がある。説明の目的のために、図２は、図１で示されているように論理データ経路６４を介してＦＬＳＥとしてｅＢＳ３８を確立することにおける、他の通信エンティティを備えたＡＴ５４のための呼び出しフローを示す。
【００３３】
図１に関連して図２の参照がなされる。説明しやすくするために、ｅＢＳ３８は、ターゲットＦＬＳＥ(target FLSE)と呼ばれる。同様に、ｅＢＳ３６はソースＦＬＳＥと呼ばれる。ｅＢＳ３４は、この場合においては、ＤＡＰとして作用する。
【００３４】
ＡＴ５４は、ＦＬＳＥとしてｅＢＳ３６に最初に依存する。したがって、ＡＴ５４は、図２において、それぞれ、論理データ経路６６及び６８によって示されているように、ＤＡＰ、この場合ではｅＢＳ３４である、から、ソースＦＬＳＥ、この場合ではｅＢＳ３６である、を介してインターネットプロトコル（ＩＰ）データパケットを受信する。
【００３５】
前に述べたように、ＡＴ５４がサービスエリア５０の近接(vicinity)に接近して移動し、ｅＢＳ３８から強いＦＬ信号を検出する、と仮定する。ＡＴ５４は、ターゲットＦＬＳＥとしてｅＢＳ３８を選択することを決定する。すなわち、ＡＴ５４は、ｅＢＳ３６からｅＢＳ３８へと、ＦＬＳＥをハンドオフすることを決定する。そのようなハンドオフについての基準は、１セットの通信条件に基づくことができ、例えば、ｅＢＳ３８を備えたよりよいリンク条件、ｅＢＳ３６とｅＢＳ３８のロードの比較、ｅＢＳ３６とｅＢＳ３８に関しての使用の持続時間、等がある。
【００３６】
ＡＴ５４は、図２で示されるメッセージ経路７０によって示されているように、ｅＢＳ３８にメッセージ、あるいはチャネル品質インジケータ（ＣＱＩ）のような物理層信号を送信することによって、ｅＢＳ３８をターゲットＦＬＳＥとして選択する。
【００３７】
メッセージを受信すると、ターゲットＦＬＳＥ３８は、ＡＴ５４のＲＳにおけるすべての他のeＢＳsに、ｅＢＳ３８がＡＴ５４のためのＦＬＳＥとしての役割を引き受けたということを通知する。ターゲットＦＬＳＥ３８による通知(notification)は、同時にあるいは連続して(simultaneously or sequentially)、他のエンティティに送信されることができる。例えば、ソースＦＬＳＥ３６に対する通知は、図２で示されているように、メッセージ経路７２を介した、ＩＰＴ（ＩＰトンネル）−通知メッセージ(an IPT (IP Tunnel)-Notification message)である。ソースＦＬＳＥ３６は、図２で示されるように、メッセージ経路７４を介して、ＩＰＴ−通知ＡｃｋメッセージをターゲットＦＬＳＥ３８に送信することによって、ＩＰＴ−通知メッセージの受信を承認する(acknowledges)。
【００３８】
別の例として、ターゲットＦＬＳＥ３８はまた、図２で示されるように、メッセージ経路７６を介して、ＩＰＴ-通知メッセージをＤＡＰ３４に送信する。同様に、ＤＡＰ３４は、図２で示されているように、メッセージ経路７８を介して、ＩＰＴ-通知ＡｃｋメッセージをソースＦＬＳＥ３８に送信することによって、ＩＰＴ−通知メッセージの受信を承認する。
【００３９】
ソースＦＬＳＥ３６の場合、ＩＰ−通知メッセージ、すなわちメッセージ経路７２を介して送信されたメッセージ、を受信すると、ソースＦＬＳＥ３６は、ＤＡＰ３４からの受信されたＩＰパケットを、ＡＴ５４ではなくてターゲットＦＬＳＥ３８へと、転送するあるいはトンネリングする必要がある。
【００４０】
この実施形態にしたがって、ソースＦＬＳＥ３６は、ターゲットＦＬＳＥ３８に対して、ＩＰパケットフレームによって定義されるような、ディスクリートＩＰパケット(discrete IP packets)をトンネリングする必要がない。代わりに、ソースＦＬＳＥ３６が、ターゲットＦＬＳＥ３８に対して、部分ＩＰパケットをトンネリングすることができる。より具体的には、時間が経過するときのソースＦＬＳＥ３６へのＩＰデータパケットフローの図を概略的に示す図３が参照される。図３に、５つのＩＰパケットフレームによって示されるように、５つのＩＰパケット、すなわちＩＰパケット＃１−＃５が示されている。時間ｔａにおいて、ソースＦＬＳＥ３６は、メッセージ経路７２を介してのようにＩＰＴ−通知メッセージを受信する、と仮定する（図２）。時間ｔａの前に受信される全体のＩＰパケット＃１及び＃２の場合、ソースＦＬＳＥ３６は、ＡＴ５４について予定されたリンク層ヘッダでこれらのＩＰパケットをカプセル化し、ＡＴ５４にＩＰパケットを送信する。異なることばで表すように(Phrased differently)、ソースＦＬＳＥ３６は、論理データ経路６０の無線リンク部分を通してリンク層トンネルを介してＡＴ５４にＩＰパケット＃１-２を送信する（図１）。
【００４１】
ＡＴ５４については、先に言及したように、ルート、具体的にはルート３６Ｒ（図１）、を有しており、それは、ｅＢＳ３６から受信されたリンク層トンネルパケットの処理のためにリザーブされている。
【００４２】
ＩＰパケット＃３の部分的な部分に関しては、図３の参照番号５１によって識別され、そしてそれは、時間ｔａの前にソースＦＬＳＥ３６によって受信されており、ソースＦＬＳＥ３６は、全体的なＩＰパケット＃１及び＃２について同様な方法で、ＡＴ５４に、部分ＩＰパケット＃３ ５１を送信する。すなわち、ソースＦＬＳＥ３６は、部分ＩＰパケット＃３ ５１を区分化し、そして、図１で示されているように、論理データ経路６０の無線リンク部分を通してのＡＴ５４への送信のために、区分化された部分をリンク層フレームにフィットさせる(fits)（図２で、論理データ経路６８によって表示される）。再び、ＡＴ５４は、全体的なＩＰパケット＃１および＃２について同様な方法で、部分ＩＰパケット＃３ ５１を受信し、処理する。
【００４３】
ＩＰパケット＃３の部分的な部分に関しては、参照番号５５によって識別され、そしてそれは、時間ｔａの後でソースＦＬＳＥ３６によって受信されており、ソースＦＬＳＥ３６は、ソースＦＬＳＥ３６のルート３６Ｒを使用して部分パケット５５を処理し（例、ＲＬＰヘッダを暗号化し、及び／または、加え）、そのあとで、この部分ＩＰパケット＃３ ５５を図１の論理データ経路８０のバックホール部分を通して、ターゲットＦＬＳＥ３８に送信する（図２では、論理データ経路８２によって表されている）。
【００４４】
部分ＩＰパケット＃３ ５５を受信すると、ターゲットＦＬＳＥ３８は、ターゲットＦＬＳＥ３８のルート３８Ｒを使用して、部分ＩＰパケット５５（例、ルート３６Ｒによって加えられたＲＬＰヘッダを含んでいる）をさらに処理し、そして、図１の論理データ経路８０の無線リンク部分を介して、ＡＴ５４に対して、部分ＩＰパケット＃３ ５５をその後で送信する（図２において、論理データ経路８４によって表されている）。
【００４５】
部分ＩＰパケット＃３ ５５については、ＡＴ５４は、ＡＴ５４のルート３８Ｒを使用して部分パケット５５を最初に処理する。その後で、ＡＴ５４は、ＡＴ５４のルート３６Ｒを使用して、部分パケット５５を処理する。異なる表現で言うと、ＡＴ５４は、ＡＴ５４がソースＦＬＳＥ３６から論理的に部分パケット５５を受信するかのように、ターゲットＦＬＳＥ３８を介して、ソースＦＬＳＥ３６から、トンネリングされた部分ＩＰパケット＃３ ５５を受信する。したがって、部分ＩＰパケット＃３ ５１及び５５がルート３６Ｒで処理されるｔａの前に及び後で受信されるので、全体的なＩＰパケット＃３の再構成(reconstruction)は実現可能(feasible)である。上記で説明されるように部分データパケットが組み合わせられることを可能にし、結果として起こる利益は、各データパケットのセグメントがたった一度だけ送信されるので、オーバーザエアリソース(over-the-air resources)がより効率的に使用されることができることである。さらに、正常状態データパケット配信(in-order data packet delivery)を備えたシームレスハンドオフは、達成されることができる。
【００４６】
部分データパケットがこの実施形態において上記で説明されるように組み合わされ、処理される間に、フルデータパケットは、必要であれば同様に組み合わせられ処理されることができるということに注意すべきである。
【００４７】
代替として、さらなる信頼性の目的のために、ソースＦＬＳＥ３６は、論理経路６０及び８０の両方を介してＩＰパケット＃３を送信することができる（図１）。ＡＴ５４のルート３６Ｒは、ＩＰパケット＃３のある部分の複製コピー(duplicate copies)を受信することができる。しかしながら、ＡＴ５４は、当技術分野において知られているように、ＲＬＰにおける複製検出メカニズムを介して、複製部分を廃棄することができる。
【００４８】
ソースＦＬＳＥ３６にいずれの残りのＩＰデータパケットがある場合には、ソースＦＬＳＥ３６は、ターゲットＦＬＳＥ３８に残りのパケットを送信し、ターゲットＦＬＳＥ３８のルート３８Ｒを使用してパケットを代わりに処理し、そのあとで、図１で示されているように論理データ経路８０を介して（図２では、上記で図示された論理データ経路は、それぞれ、参照番号８６と８８によって識別されている）、ＡＴ５４に、処理されたパケットを送信する。データパケットを受信すると、ＡＴ５４は、ＡＴ５４において保存されたルート３８Ｒを使用してパケットを処理する。
【００４９】
ＤＡＰ３４に関して、時間ｔｂのときに（図３）、ＤＡＰ３４は、メッセージ経路７６（図２）を介して、ＩＰＴ−通知メッセージを受信する。時間ｔｂの前に受信される全体のＩＰパケット＃１−＃３については、ＤＡＰ３４は、ソースＦＬＳＥ３６に、ＩＰパケット＃１−＃３をトンネリングし、そしてそれは、上記で説明されたのと同様な方法において受信されたＩＰパケットを代わりに取り扱う。しかしながら、ＩＰパケット＃４については、ソースＦＬＳＥ３６はいずれの部分的に受信されたＩＰパケットを適切に扱うであろうということをＤＡＰ３４が認識しているので、ＤＡＰ３４は、ソースＦＬＳＥ３６に全体のパケットをトンネリングする。すなわち、ＩＰパケット＃１−＃４については、ＤＡＰ３４は、図１で示されているように論理データ経路６０を通してソースＦＬＳＥ３６を介して（図２では、上記で図示された論理データ経路は、それぞれ、参照番号６８と６６によって識別されている）ＡＴ５４にデータパケットを送信する。
【００５０】
時間ｔｂの後で受信されたいずれのＩＰパケット、例えば図３で示されているＩＰパケット＃５、について、ＤＡＰ３４は、前に述べたように図１で示される論理データ経路６４を介して（図２では、論理データ経路は、それぞれ参照番号９０と９２によって識別される）パケットを代わりに取り扱う、ターゲットＦＬＳＥ３８にパケットをトンネリングする。パケットを受信すると、ＡＴ５４は、前にも述べた、ルート３８Ｒ（図１）においてパケットを処理する。
【００５１】
図３に関連して、図２に戻って参照する。より簡単に述べると、ソースＦＬＳＥ３６の場合、図１で示される論理データ経路６０によって示されているように、時間ｔｂの前に、ＤＡＰ３４から受信されたフルあるいは部分のＩＰパケットはＡＴ５４にトンネリングされる。しかしながら、ソースＦＬＳＥ３６については、時間ｔａの後のＤＡＰ３４から受信されたフルあるいは部分のＩＰパケットは、図１で示される論理データ経路８０のバックホール部分によって示されるように、ターゲットＦＬＳＥ３８にトンネリングされる。ターゲットＦＬＳＥ３８は、そのあとで、図１で示され、それぞれ論理データ経路８０及び６４の無線リンク部分によって示されているように、ＡＴ５４に対して、受信された部分及びフルＩＰパケットをトンネリングする。
【００５２】
同様に、ＤＡＰ３４については、時間ｔｂの前にあるいは時間ｔｂの間に、受信されたフルＩＰパケットは、図１で示される論理データ経路６０のバックホール部分によって示されるように、ソースＦＬＳＥ３６に対して送信される。しかしながら、時間ｔｂの後で受信されるフルＩＰパケットは、図１で示される論理データ経路６４のバックホール部分によって示されているように、ターゲットＦＬＳＥ３８に対してトンネリングされる。後で、ターゲットＦＬＳＥ３８は、図１で示された論理データ経路６４の無線リンク部分によって示されるように、ＡＴ５４に、受信されたフルＩＰパケットをトンネリングする。
【００５３】
もはやサービングＦＬＳＥではないという、ソースＦＬＳＥ３６への通知が続く。この目的を達成するために、ＤＡＰ３４は、図２で示されるメッセージ経路９４を介して、ＡＴ５４のためのサービングＦＬＳＥとしての義務の遂行に対し(discharge of the duty)、ＦＬＳＥ３６に通知して、ソースＦＬＳＥ３６に、ＩＰＴ−通知メッセージを送る。
【００５４】
ソースＦＬＳＥ３６は、図２で示されるメッセージ経路９６を介して、ＩＰＴ−通知Ａｃｋメッセージで応答する。
【００５５】
経路９４と９６を介してメッセージを交換することによって、上述の通知は、以下、「ネガティブの通知(negative notification)」と呼ばれる。ネガティブの通知は、ＦＬＳＥあるいはＲＬＳＥが正しく割り当てられる、さらなるセーフガード(an additional safeguard)として役立つ。不整合性があるイベントにおいて、正しいメカニズムは、訂正(rectification)のためにインストールされることができ、そして後でさらに説明されるであろう。
【００５６】
上記で、ＡＴ５４がサービングＦＬＳＥとしてｅＢＳ３８を選択することを説明している。ＡＴ５４は、ＲＬ条件は、現在のサービングＲＬＳＥのそれ、この場合はｅＢＳ３６である、により好都合であるということを決定し、ｅＢＳ３６からｅＢＳ３８へとサービングＦＬＳＥを切り替えるという点において利点があまりないようである、ということを仮定する。そのようなシナリオの下では、ＡＴ５４は、ｅＢＳ３６からｅＢＳ３８へＲＬＳＥのハンドオフを始めることができる。
【００５７】
ＲＬＳＥのハンドオフがＦＬＳＥについての対応するハンドオフとは異なる、ある態様がある。ＦＬＳＥハンドオフの間に、あるいは、一般にＦＬデータフローの間、ＡＴが随意にいずれの通信エンティティとも通信することができるので、ＤＡＰは、ＡＴ５４が次第に通信することを決定する通信エンティティに適切なＦＬデータフローを指図するために、データアンカリングエンティティ(data anchoring entity)として必要とされる。しかしながら、対応するＲＬＳＥハンドオフの間に、あるいは、一般にＲＬデータフローの間、ＤＡＰにとって、データアンカリングエンティティとしての必要性はないかもしれない。その理由は、ＡＴからＲＬデータフローを受信しているいずれの通信エンティティは、まっすぐに、ＡＧＷに受信されたデータを送信することができるからである。実際、このアプローチは、バックホール使用をさらに合理化する(streamlines)ので、好まれる。
【００５８】
例として図１に戻って参照する。前に説明されるように、それぞれ論理データ経路６０及び６４からの、ソースｅＢＳ３６からターゲットｅＢＳ３８までのＦＬＳＥハンドオフの間に、アンカリングエンティティとして作用しているＤＡＰ、この場合ではｅＢＳ３４、が必要とされる。その理由は、ハンドオフの完了の前に、どのｅＢＳをＡＴ５４がターゲットＦＬＳＥとして結局選択するのかをまだ決めていない可能性があるからである。ＤＡＰ３４の関数は、ハンドオフの間に及びハンドオフの後で、ＡＴ５４によって、選択されたターゲットＦＬＳＥに対して、ＦＬデータトラフィックを、適切に命令することである。ＦＬＳＥハンドオフを容易にするために、ＡＴ５４、ＡＧＷ３２、ｅＢＳ３４、ｅＢＳ３６、及びｅＢＳ３８を含んでいるすべての通信エンティティは、それらの中のどのエンティティがＡＴ５４のための現在のＦＬＳＥであるかという跡をつける(keep track)必要があるということもまた上述する必要がある。
【００５９】
ＲＬＳＥハンドオフに関して、ＡＴ５４がソースｅＢＳ３６からターゲットｅＢＳ３８までのＲＬデータフローをハンドオフすることを決定する、と仮定する。ＡＴ５４は、図１に示されるように、論理データ経路６２から論理データ経路８３へと、ＲＬを切り替えることを選択することができたであろう。具体的には、論理データ経路８３を介してＲＬデータフローを送信することは、ＤＡＰとしてｅＢＳ３４に依存する。しかしながら、この例において、通信リソースをより効率的に使用するために、ＡＴ５４は、図１で示されるように、また、代替として、論理データ経路８５を介して、ＡＧＷ３２に対して、ターゲットｅＢＳ３８を通してＲＬデータパケットを直接に送信する。この場合においては、いくつかの通信エンティティ、例えばｅＢＳ３４、ｅＢＳ３６、及びｅＢＳ３８は、どのエンティティがＡＴのための現在のＲＬＳＥであるかという跡をつける必要はない。その理由は、通信システム３０内にあり、ＲＬデータパケットの行先(destination)は、確認されたＡＧＷ３２である。すなわち、ＲＬデータパケットの行先は、不確かなターゲットではない。
【００６０】
ターゲットＲＬＳＥ３８へのソースＲＬＳＥ３６のハンドオフのためのプロセスは、前に説明されたＦＬＳＥカウンターパート(FLSE counterpart)について説明されたものと本質的には同様であるが、上記で強調されるような差異を備えている。さらに、ＡＴ５４は、ターゲットＲＬＳＥ３８に、メッセージ、あるいは、図４で示されるメッセージ経路９７によって識別されるようなパイロット品質インジケータ(Pilot Quality Indicator)（ＰＱＩ）のような物理層信号、を送信することによって、ＲＬＳＥ変更をリクエストする。簡潔さと明瞭さのために、ＲＬＳＥハンドオフプロセスは、さらに詳述されていない。代わりに、論理データ経路６２−８５（図１）の、ソースＲＬＳＥ３６からターゲットＲＬＳＥ３８までのＲＬＳＥハンドオフが図４で図示されている。
【００６１】
上記で説明されたＦＬＳＥ及びＲＬＳＥのハンドオフプロセスにおいて、これまで通信条件を変更することにより、メッセージング信号(messaging signals)は、必ずしも、時間どおりに到着するとは限らない。結果として、意図されたＦＬＳＥあるいはＲＬＳＥは、誤って割り当てられることができるということは、可能である。図５は、誤ったＦＬＳＥ割り当ての例を図示する。この実施形態において、救済プロシージャ(remedial procedures)は、間違った割り当てを訂正する(rectify)ために、設けられている。
【００６２】
図５を参照する。ＡＴ５４が、ＤＡＰとしてｅＢＳ３４を、また、ＦＬＳＥとしてｅＢＳ３６を、最初に割り当てる、と仮定する。そのため、図５で示されているように、それぞれ、データ経路１００及び１０２を介して、ＤＡＰ３４は、ＡＴ５４にＩＰパケットを代わりにトンネリングするｅＢＳ３６に対して、ＩＰパケットを転送する。
【００６３】
ＡＴ５４がｅＢＳ３８を備えたよりよいＦＬがあるということを決定するということを仮定する。様々なあらかじめ定義された通信条件を重みづけて、ＡＴ５４は、ｅＢＳ３６からｅＢＳ３８へとＦＬＳＥを変更することを決定する。ＡＴ５４は、図５に示されているように、メッセージ経路１０４を介して、リクエストメッセージをｅＢＳ３８に送る。
【００６４】
メッセージ経路１０４を介してメッセージを受信すると、図５で示されたメッセージパス１０６を介してｅＢＳ３６に送信されたＩＰＴ−通知メッセージによって類型化されるように、ｅＢＳ３８がＡＴ５４のためのＦＬＳＥとして役割を引き受けたということをＡＴ５４のＲＳのすべてのｅＢＳｓに、ｅＢＳ３８は、通知する。ｅＢＳ３６は、メッセージ経路１０８を介して、ＩＰＴ−通知Ａｃｋメッセージで応答する。
【００６５】
理想的には、ｅＢＳ３８は、同様の通知メッセージ、すなわち、図５で示されたメッセージパス１２０を介して送信されたメッセージ、を遅延なしに、ＤＡＰ３４に送信すべきであった。しかしながら、この例においては、そのようなメッセージの入手可能性が遅延される、すなわち、ｅＢＳ３８によって時期尚早に(untimely)送信されるか、あるいは、ＤＡＰ３４によって遅れて(belatedly)受信される、と仮定する。遅延の理由は、ｅＢＳ３８の回路あるいはＤＡＰ３４によって引き起こされる可能性がある。遅延は、ｅＢＳ３８とＤＡＰ３４との間の好ましくない通信条件によって引き起こされる可能性がある。
【００６６】
いずれのイベントにおいても、メッセージ経路１２０を介してタイムリーに送信されるべきだったＩＰＴ−通知メッセージを送信する前に、この例におけるｅＢＳ３８は、図５で示されるようにメッセージ経路１１０を介してリクエストメッセージを送信することによって、ＦＬＳＥとしてｅＢＳ３６を再び選択する。
【００６７】
再び、ｅＢＳ３６は、図５で示された、メッセージパス１１２を介してｅＢＳ３８に送信されたＩＰＴ−通知メッセージ、によって類型化されるように、ｅＢＳ３６は、ＡＴ５４のためのＦＬＳＥとしての役割を引き受けたということをＡＴ５４のＲＳのすべてのｅＢＳｓに通知する。ｅＢＳ３８は、メッセージ経路１１４を介して、ＩＰＴ−通知Ａｃｋメッセージで応答する。
【００６８】
一例において、図５で示されるように、ＤＡＰ３４に対してメッセージ経路１１６を介してＩＰＴ−通知メッセージをタイムリーに送信し、ＤＡＰ３４からメッセージ経路１１８を介してＩＰＴ−通知Ａｃｋメッセージをタイムリーに受信する、と仮定する。前に述べたように、例示的な実施形態にしたがって、ＤＡＰ３４はまた、他のｅＢＳｓに対しさらなるセーフガードとして、それらがＦＬＳＥではないということをネガティブの通知でフォローする(follows up with)。
【００６９】
しかしながら、この時点で、早くに到達すべきだったメッセージ経路１２０を介してＩＰＴ−通知メッセージが、どういうわけか到達し、ＤＡＰ３４によって受信される、と仮定する。ＤＡＰ３４は、図５で示されるメッセージ経路１２２によって示されるように、ＩＰＴ−通知Ａｃｋメッセージで応答する。それにもかかわらず、意図されたＦＬＳＥ３６によってメッセージ経路１１６を介してより早く送信された、ＩＰＴ−通知メッセージの受信の結果として起こるネガティブの通知はまた、他のｅＢＳｓに対して、ＤＡＰ３４によって送信される。そのようなネガティブの通知は、例えば図５で示されているように、メッセージ経路１２４を介して、ｅＢＳ３８に送信される。ここで、ｅＢＳ３８は、早くから、ＦＬＳＥとしての役割を引き受けたということをＡＴ５４のＲＳにおける他のエンティティに対し通知メッセージを送信するので、不整合性(inconsistence)を検出すべきである。しかしながら、メッセージ経路１２４を介して受信されたメッセージは、ｅＢＳ３８はＡＴ５４のためのＦＬＳＥではないという整合性のないポジション(inconsistent position)をｅＢＳ３８に通知する。イベントは、さらなる照会(inquiry)及び起こりうる修正(eventual rectification)のために、アクションをトリガすることができる。この実施形態においては、救済アクション(remedial actions)は、下記で説明されるように、ｅＢＳ３６、すなわち、最初に意図されたＦＬＳＥ、によって行われる。
【００７０】
図５を続けて参照する。メッセージ経路１２０を介したＩＰＴ−通知メッセージの受信の結果として、ＤＡＰ３４はまた、ｅＢＳ３８の他にＡＴ５４のＲＳの他のｅＢＳｓに対して、それらがＡＴ５４のためのＦＬＳＥではないというネガティブの通知メッセージを送信する。そのようなメッセージのうちの１つは、図６で示されるｅＢＳ３６に対して、メッセージ経路１２８を介して送信されたメッセージである。ｅＢＳ３６は、図５で示されたメッセージ経路１３０を介して、ＩＰＴ−通知Ａｃｋメッセージで応答する。
【００７１】
ここで、早くからｅＢＳ３６がＦＬＳＥとして役割を果たすＡＴ５４のＲＳにおける他のエンティティに対して通知メッセージを送信しているので、ｅＢＳ３６はまた、不整合性を検出すべきである。それにもかかわらず、メッセージ経路１２８を介して受信されたメッセージは、ｅＢＳ３６に、ｅＢＳ３６はＡＴ５４のためのＦＬＳＥではないという整合性のないポジションを、通知する。イベントは、正しい測定のために、動いているｅＢＳ３６を設定する。例えば、この実施形態において、ｅＢＳ３６は、自発的に、前に図２で示され説明されるようにＦＬＳＥスイッチプロセス１３２を再開することができる。
【００７２】
図６は、上記で説明されるようなハンドオフプロセスを実行するための装置のハードウェアインプリメンテーションの一部を示す。回路装置は、参照番号２９０によって示され、また、ＡＴあるいはいずれの通信エンティティ、例えばｅＢＳまたはＡＧＷ、においてインプリメントされることができる。
【００７３】
装置２９０は、いくつかの回路を一緒にリンクさせる中央データバス２９２を備える。回路は、ＣＰＵ（中央処理装置）、あるいは、コントローラ２９４、受信回路２９６、送信回路２９８、及びメモリユニット３００を含む。
【００７４】
装置２９０が無線装置の一部である場合、受信回路２９６と送信回路２９８は、図面には示されてはいないがＲＦ（無線周波数）回路に接続されることができる。受信回路２９６は、データバス２９２に送信する前に、受信信号を処理し、バッファする。他方で、送信回路２９８は、デバイス２９０から送信する前にデータバス２９２からデータを処理し、バッファする。ＣＰＵ／コントローラ２９４は、データバス２９２のデータ管理の関数、さらに一般的なデータ処理の関数を実行し、メモリユニット３００の命令コンテンツ(instructional contents)を実行することを含む。
【００７５】
代替として、図６で示されるように別々に配列される(separately disposed)代わりに、送信回路２９８及び受信回路２９６は、ＣＰＵ／コントローラ２９４の一部分であることができる。
【００７６】
メモリユニット３００は、参照番号３０２によって一般に示された１セットのモジュールおよび／またはインストラクションを含む。この実施形態においては、モジュール／インストラクションは、特に(among other things)、ＦＬＳＥハンドオフ関数３０８とＲＬＳＥハンドオフ関数３１０を含む。ハンドオフ関数３０８及び３１０は、図１−５で示され、説明されるプロセスステップを実行するための、コンピュータインストラクションあるいはコードを含む。エンティティ特有の具体的なインストラクションは、ハンドオフ関数３０８および３１０で、選択的にインプリメントされることができる。例えば、装置２９０がＡＴの一部分である場合、特に(among other things)、図２、４、及び５において示され説明されるＡＴに関連したメッセージの準備及び処理と共に、図１−５で示され説明されるプロセスステップを実行するためのインストラクションは、ハンドオフ関数３０８及び３１０でコード化されることができる。同様に、装置２９０が通信エンティティ、例えばｅＢｓ、の一部である場合には、その通信エンティティ特有のプロセスステップ及びメッセージの準備は、ハンドオフ関数３０８及び３１０でコード化されることができる。
【００７７】
さらに、図１で示され説明される、ルート３４Ｒ、３６Ｒ、及び、３８Ｒのような複数のルートはまた、メモリユニット３００に含まれることができる。ルートは、図６の参照番号３９８によって集約的に示されている。代替として、ルート３９８は、ユニット３００の他に、１つまたは複数の他のメモリユニットに保存されることができる。上記で配置されるような同様な方法で、選択ルートは、インプリメンテーションにおいて特定のエンティティについてインストールされることができる。例えば、ＡＴ５４について、図１で示され、説明されるように、３４Ｒ、３６Ｒ及び３８ＲのようなＲＳにあるすべてのルートを含むことが必要とする一方で、例えばｅＢＳ３６については、ルート３６Ｒだけがメモリユニット３００でインストールされる必要がある。
【００７８】
この実施形態においては、メモリユニット３００は、ＲＡＭ（ランダムアクセスメモリ）回路である。ハンドオフ関数３０８及び３１０のような例示的な関数は、ソフトウェアのルーチン、モジュール、および／または、データセット、である。メモリユニット３００は、揮発性あるいは不揮発性のタイプのいずれかになりえる別のメモリ回路（示されていない）と結び付けられることができる。代替として、メモリユニット３００は、例えばＥＥＰＲＯＭ（電子的消去可能プログラマブル読み取り専用メモリ）、ＥＰＲＯＭ（電子的プログラマブル読み取り専用メモリ）、ＲＯＭ（読み取り専用メモリ）、ＡＳＩＣ（特定用途向け集積回路）、磁気ディスク、光ディスク、及び当技術分野においてよく知られた他のもの、ような他の回路タイプから成ることができる。
【００７９】
説明される発明のプロセス(inventive processes)はまた、当技術分野で知られたいずれのコンピュータ可読メディア上で実行されるコンピュータ可読インストラクションとしてコード化されることができるということは、さらに注目すべきである。この明細書及び添付された特許請求項において、用語「コンピュータ可読メディア(computer-readable medium)」は、実行のために、例えば、図６の図面で示され説明されたＣＰＵ／コントローラ２９４のようないずれのプロセッサにインストラクションを提供することに関与するいずれのメディアを指す。そのようなメディアは、ストレージタイプであってもよく、例えば、図６のメモリユニット３００の説明において、また前に説明されたような、揮発性あるいは非揮発性のストレージメディアの形態をとることができる。そのようなメディアはまた、送信タイプであることができ、同軸ケーブル、銅線、光ケーブル(optical cable)、そして、マシンあるいはコンピュータによって読み取り可能な信号を搬送することができる聴覚波、電磁波、あるいは光学波、を搬送している無線インタフェース、を含むことができる。コンピュータ可読メディアは、装置２９０とは別のコンピュータプロダクトの一部であることができる。
【００８０】
最後に、本発明の範囲内での他の変更は、可能である。上記で説明される他に、実施形態に関連して、いずれの他の論理ブロック、回路、及びアルゴリズムステップも、ハードウェア、ソフトウェア、ファームウェイア、あるいはそれらの組み合わせでインプリメントされることができる。形式と及び詳細におけるこれら及び他の変更は、本発明の範囲及び精神から逸脱することなく行われることができるということが、当業者によって理解されるであろう。
【特許請求の範囲】
【請求項１】
１セットの通信条件のアセスメントを提供することと、
前記アセスメントに基づいて、第１の通信エンティティに対して順方向通信リンクを割り付けることと、
前記アセスメントに基づいて、第２の通信エンティティに対して逆方向通信リンクを割り付けることと、
を備えている通信の方法。
【請求項２】
前記第１の通信エンティティ及び前記第２の通信エンティティとの通信のために、第１のルート及び第２のルートをそれぞれ提供することと、
前記第１の通信エンティティ及び前記第２の通信エンティティのどれがサービング通信エンティティとして割り当てられているかに関わらず、前記第１の通信エンティティ及び前記第２の通信エンティティとそれぞれ関係している前記第１のルート及び前記第２のルートを維持することと、
をさらに備えている請求項１に記載の方法。
【請求項３】
無線通信システムにおいて動作可能なアクセス端末による方法であって、
前記アクセス端末において複数のルートを提供することと、
第１のルートとして第１の通信エンティティと通信するための前記ルートのうちの１つを割り付けることと、
第２のルートとして第２の通信エンティティと通信するための前記ルートのうちの別のものを割り付けることと、
前記第１の通信エンティティ及び前記第２の通信エンティティのどれがサービング通信エンティティとして割り当てられているかに関わらず、前記第１の通信エンティティ及び前記第２の通信エンティティとそれぞれ関係している前記第１のルート及び前記第２のルートを維持することと、
を備えている方法。
【請求項４】
前記サービング通信エンティティとして前記第２の通信エンティティを選択することと、
前記第１のルートを使用して前記データパケットを処理する前に、前記第２のルートを使用して部分ＩＰ（インターネットプロトコル）データパケットを処理することと、
をさらに備えている請求項３に記載の方法。
【請求項５】
順方向リンクのサービング通信エンティティとして前記第１の通信エンティティを選択することと、
逆方向リンクのサービング通信エンティティとして前記第２の通信エンティティを選択することと、
をさらに備えている請求項３に記載の方法。
【請求項６】
前記サービング通信エンティティが順方向リンク通信エンティティあるいは逆方向リンクのサービング通信エンティティであるかどうかに関わらず、前記第１の通信エンティティ及び前記第２の通信エンティティとそれぞれ関係している前記第１のルート及び前記第２のルートを維持することと、をさらに備えている請求項３に記載の方法。
【請求項７】
前記アクセス端末と前記第１の通信エンティティとの間の第１の通信セッションに関連づけられた前記第１のルートパラメータに含めることと、前記アクセス端末と第２の通信エンティティとの間の第２の通信セッションに関連づけられた前記第２のルートパラメータに含めることと、をさらに備えている請求項３に記載の方法。
【請求項８】
前記サービング通信エンティティとして前記第１の通信エンティティを最初に選択することと；
前記サービング通信エンティティとして前記第２の通信エンティティをそのあとで選択することと、なお、前記第１の通信エンティティは、前記サービング通信エンティティとして誤って割り当てられている；
前記第１の通信エンティティ及び前記第２の通信エンティティとのうちの１つによって最初にもたらされた救済アクションから前記サービング通信エンティティとして前記第２の通信エンティティを再び選択することと；
をさらに備えている請求項３に記載の方法。
【請求項９】
通信システムにおいて動作可能な通信エンティティによる方法であって、
前記通信システムにおけるアクセス端末のために、順方向リンクのサービング通信エンティティと逆方向リンクのサービング通信エンティティとの両方としてサービス提供することと、
前記別の通信エンティティへの前記順方向リンク通信エンティティと前記逆方向通信エンティティとのうちの１つのハンドオフのために、別の通信エンティティから通知を受信することと、
前記順方向リンクの通信エンティティと前記逆方向リンクの通信エンティティの他のものとして、前記アクセス端末を継続的にサービス提供することと、
を備えている方法。
【請求項１０】
前記通知は、前記別の通信エンティティへの前記順方向リンクの通信エンティティのハンドオフのためのリクエストであって、前記方法は、
前記アクセス端末でＩＰ（インターネットプロトコル）データパケットを処理するためのルートを維持することと、
前記別の通信エンティティに対してフルＩＰデータパケットを送信することと、
前記ルートを使用して前記アクセス端末に対して、前記別の通信エンティティを介して、部分ＩＰデータパケットをトンネリングすることと、
をさらに備えている、請求項９に記載の方法。
【請求項１１】
通信のための装置であって、
１セットの通信条件のアセスメントを提供するための手段と、
前記アセスメントに基づいて、第１の通信エンティティに対して順方向通信リンクを割り付けるための手段と、
前記アセスメントに基づいて、第２の通信エンティティに対して逆方向通信リンクを割り付けるための手段と、
を備えている装置。
【請求項１２】
それぞれ前記第１の通信エンティティ及び前記第２の通信エンティティとの通信のために、第１のルート及び第２のルートをそれぞれ提供するための手段と、
前記第１の通信エンティティ及び前記第２の通信エンティティのどれがサービング通信エンティティとして割り当てられているかに関わらず、前記第１の通信エンティティ及び前記第２の通信エンティティとそれぞれ関係している前記第１のルート及び前記第２のルートを維持するための手段と、
をさらに備えている請求項１１に記載の装置。
【請求項１３】
通信システムにおいて動作可能なアクセス端末は、
前記アクセス端末において複数のルートを提供するための手段と、
第１のルートとして第１の通信エンティティと通信するための前記ルートのうちの１つを割り付けるための手段と、
第２のルートとして第２の通信エンティティと通信するための前記ルートのうちの別のものを割り付けるための手段と、
前記第１の通信エンティティ及び前記第２の通信エンティティのどれがサービング通信エンティティとして割り当てられているかに関わらず、前記第１の通信エンティティ及び前記第２の通信エンティティとそれぞれ関係している前記第１のルート及び前記第２のルートを維持するための手段と、
を備えているアクセス端末。
【請求項１４】
前記サービング通信エンティティとして前記第２の通信エンティティを選択するための手段と、
前記第１のルートを使用して前記データパケットを処理する前に、前記第２のルートを使用して部分ＩＰ（インターネットプロトコル）データパケットを処理するための手段と、
をさらに備えている請求項１３に記載のアクセス端末。
【請求項１５】
順方向リンクのサービング通信エンティティとして前記第１の通信エンティティを選択するための手段と、
逆方向リンクのサービング通信エンティティとして前記第２の通信エンティティを選択するための手段と、
をさらに備えている請求項１３に記載のアクセス端末。
【請求項１６】
前記サービング通信エンティティが順方向リンク通信エンティティあるいは逆方向リンクのサービング通信エンティティであるかどうかに関わらず、前記第１の通信エンティティ及び前記第２の通信エンティティとそれぞれ関係している前記第１のルート及び前記第２のルートを維持するための手段と、をさらに備えている請求項１３に記載のアクセス端末。
【請求項１７】
前記アクセス端末と前記第１の通信エンティティとの間の第１の通信セッションに関連づけられた前記第１のルートパラメータに含めるための手段と、前記アクセス端末と第２の通信エンティティとの間の第２の通信セッションに関連づけられた前記第２のルートパラメータに含めるための手段と、をさらに備えている請求項１３に記載のアクセス端末。
【請求項１８】
前記サービング通信エンティティとして前記第１の通信エンティティを最初に選択するための手段と；
前記サービング通信エンティティとして前記第２の通信エンティティをそのあとで選択するための手段と、なお、前記第１の通信エンティティは、前記サービング通信エンティティとして誤って割り当てられている；
前記サービング通信エンティティとして前記第１の通信エンティティを再び選択するための手段と；
をさらに備えている請求項１３に記載のアクセス端末。
【請求項１９】
通信システムにおいて動作可能な通信エンティティは、
前記通信システムにおけるアクセス端末のために、順方向リンクのサービング通信エンティティと逆方向リンクのサービング通信エンティティとの両方としてサービス提供するための手段と、
前記別の通信エンティティへの前記順方向リンク通信エンティティと前記逆方向通信エンティティとのうちの１つのハンドオフのために、別の通信エンティティから通知を受信するための手段と、
前記順方向リンクの通信エンティティと前記逆方向リンクの通信エンティティの他のものとして、前記アクセス端末を継続的にサービス提供するための手段と、
を備えている通信エンティティ。
【請求項２０】
前記通知は、前記別の通信エンティティへの前記順方向リンクの通信エンティティのハンドオフのためのリクエストであって、前記通信エンティティは、
前記アクセス端末でＩＰ（インターネットプロトコル）データパケットを処理するためのルートを維持するための手段と、
前記別の通信エンティティに対してフルＩＰデータパケットを送信するための手段と、
前記ルートを使用して前記アクセス端末に対して、前記別の通信エンティティを介して、部分ＩＰデータパケットをトンネリングするための手段と、
をさらに備えている、請求項１９に記載の通信エンティティ。
【請求項２１】
プロセッサと、
１セットの通信条件のアセスメントを提供し、前記アセスメントに基づいて第１の通信エンティティに順方向通信リンクを割り付けるように、また、前記アセスメントに基づいて第２の通信エンティティに逆方向通信リンクを割り付けるように、構成された前記プロセッサに結合された回路と、
を備えている通信のための装置。
【請求項２２】
前記プロセッサに結合された前記回路は、それぞれ前記第１の通信エンティティ及び前記第２の通信エンティティとの通信のために第１のルート及び第２のルートをそれぞれ提供し、前記第１の通信エンティティ及び前記第２の通信エンティティのどれがサービング通信エンティティとして割り当てられているかに関わらず、前記第１の通信エンティティ及び前記第２の通信エンティティとそれぞれ関係している前記第１のルート及び前記第２のルートを維持するように、さらに構成されている請求項２１に記載の装置。
【請求項２３】
通信システムにおいて動作可能なアクセス端末は、
プロセッサと、
前記アクセス端末における複数のルートを提供し、第１のルートとして第１の通信エンティティと通信するために前記ルートのうちの１つを割り付け、第２のルートとして第２の通信エンティティと通信するために前記ルートのうちの別のものを割り付け、そして、前記第１の通信エンティティ及び前記第２の通信エンティティのどれがサービング通信エンティティとして割り当てられているかに関わらず、前記第１の通信エンティティ及び前記第２の通信エンティティとそれぞれ関係している前記第１のルート及び前記第２のルートを維持するように、構成された前記プロセッサに結合された回路と、
を備えているアクセス端末。
【請求項２４】
前記プロセッサに結合された前記回路は、前記サービング通信エンティティとして前記第２の通信エンティティを選択し、そして、前記第１のルートを使用して前記データパケットを処理する前に、前記第２のルートを使用して部分ＩＰ（インターネットプロトコル）データパケットを処理するようにさらに構成されている、請求項２３に記載のアクセス端末。
【請求項２５】
前記プロセッサに結合された前記回路は、順方向リンクのサービング通信エンティティとして前記第１の通信エンティティを選択し、逆方向リンクのサービング通信エンティティとして前記第２の通信エンティティを選択するようにさらに構成されている、請求項２３に記載のアクセス端末。
【請求項２６】
前記プロセッサに結合された前記回路は、前記サービング通信エンティティが順方向リンクのサービング通信エンティティあるいは逆方向リンクのサービング通信エンティティであるかどうかに関わらず、前記第１の通信エンティティ及び前記第２の通信エンティティとそれぞれ関係している前記第１のルート及び前記第２のルートを維持するようにさらに構成されている、請求項２３に記載のアクセス端末。
【請求項２７】
前記プロセッサに結合された前記回路は、前記アクセス端末と前記第１の通信エンティティとの間の第１の通信セッションに関連づけられた前記第１のルートパラメータに含め、前記アクセス端末と第２の通信エンティティとの間の第２の通信セッションに関連づけられた前記第２のルートパラメータに含むようにさらに構成されている、請求項２３に記載のアクセス端末。
【請求項２８】
前記プロセッサに結合された前記回路は、前記サービング通信エンティティとして前記第１の通信エンティティを最初に選択し、前記サービング通信エンティティとして前記第２の通信エンティティをそのあとで選択し、もし前記第１の通信エンティティが前記サービング通信エンティティとして誤って割り当てられている場合には、前記サービング通信エンティティとして前記第２の通信エンティティを再び選択するようにさらに構成されている、請求項２３に記載のアクセス端末。
【請求項２９】
通信システムにおいて動作可能な通信エンティティは、
プロセッサと、
前記通信システムにおけるアクセス端末のために、順方向リンクのサービング通信エンティティと逆方向リンクのサービング通信エンティティとの両方としてサービス提供し、前記別の通信エンティティへの前記順方向リンク通信エンティティと前記逆方向通信エンティティとのうちの１つのハンドオフのために、別の通信エンティティから通知を受信し、前記順方向リンクの通信エンティティと前記逆方向リンクの通信エンティティの他のものとして、前記アクセス端末を継続的にサービス提供するように構成された前記プロセッサに結合された回路と、
を備えている通信エンティティ。
【請求項３０】
前記通知は、前記別の通信エンティティへの前記順方向リンクの通信エンティティのハンドオフのためのリクエストであり、前記回路に結合された前記プロセッサは、前記アクセス端末でＩＰ（インターネットプロトコル）データパケットを処理するためのルートを維持し、前記別の通信エンティティに対してフルＩＰデータパケットを送信し、前記ルートを使用して前記アクセス端末に対して、前記別の通信エンティティを介して、部分ＩＰデータパケットをトンネリングするようにさらに構成されている、請求項２９に記載の通信エンティティ。
【請求項３１】
１セットの通信条件のアセスメントを提供し、
前記アセスメントに基づいて、第１の通信エンティティに対して順方向通信リンクを割り付け、
前記アセスメントに基づいて、第２の通信エンティティに対して逆方向通信リンクを割り付けるための物理的に具現化されたコンピュータ可読コード、
を備えているコンピュータ可読メディア、
を含んでいるコンピュータプロダクト。
【請求項３２】
前記コンピュータ可読メディアは、
前記第１の通信エンティティ及び前記第２の通信エンティティそれぞれとの通信のために、第１のルート及び第２のルートをそれぞれ提供し、
前記第１の通信エンティティ及び前記第２の通信エンティティのどれがサービング通信エンティティとして割り当てられているかに関わらず、前記第１の通信エンティティ及び前記第２の通信エンティティにそれぞれ関係している前記第１のルート及び前記第２のルートを維持するためのコンピュータ可読コード、
をさらに備えている、
請求項３１に記載のコンピュータプロダクト。
【請求項３３】
前記アクセス端末において複数のルートを提供し、
第１のルートとして第１の通信エンティティと通信するために前記ルートのうちの１つを割り付け、
第２のルートとして第２の通信エンティティと通信するために前記ルートのうちの別のものを割り付け、
前記第１の通信エンティティ及び前記第２の通信エンティティのどれがサービング通信エンティティとして割り当てられているかに関わらず、前記第１の通信エンティティ及び前記第２の通信エンティティをそれぞれ関係している前記第１のルート及び前記第２のルートを維持するための物理的に具現化されたコンピュータ可読コード、
を備えているコンピュータ可読メディア、
を含んでいるコンピュータプロダクト。
【請求項３４】
前記コンピュータ可読メディアは、
前記サービング通信エンティティとして前記第２の通信エンティティを選択し、
前記第１のルートを使用して前記データパケットを処理する前に、前記第２のルートを使用して部分ＩＰ（インターネットプロトコル）データパケットを処理するためのコンピュータ可読コード、
をさらに備えている、
請求項３３に記載のコンピュータプロダクト。
【請求項３５】
前記コンピュータ可読メディアは、
順方向リンクのサービング通信エンティティとして前記第１の通信エンティティを選択し、
逆方向リンクのサービング通信エンティティとして前記第２の通信エンティティを選択するためのコンピュータ可読コード、
をさらに備えている、
請求項３３に記載のコンピュータプロダクト。
【請求項３６】
前記コンピュータ可読メディアは、前記サービング通信エンティティが順方向リンクのサービング通信エンティティあるいは逆方向リンクのサービング通信エンティティであるかどうかに関わらず、前記第１の通信エンティティ及び前記第２の通信エンティティとそれぞれ関係している前記第１のルート及び前記第２のルートを維持するためのコンピュータ可読コードをさらに備えている、請求項３３に記載のコンピュータプロダクト。
【請求項３７】
前記コンピュータ可読メディアは、前記アクセス端末と前記第１の通信エンティティとの間の第１の通信セッションに関連づけられた前記第１のルートに含み、前記アクセス端末と第２の通信エンティティとの間の第２の通信セッションに関連づけられた前記第２のルートパラメータに含めるためのコンピュータ可読コード、をさらに備えている、請求項３３に記載のコンピュータプロダクト。
【請求項３８】
前記コンピュータ可読メディアは、
前記サービング通信エンティティとして前記第１の通信エンティティを最初に選択し；
前記サービング通信エンティティとして前記第２の通信エンティティをそのあとで選択し、なお、前記第１の通信エンティティは、前記サービング通信エンティティとして誤って割り当てられている；
前記第１の通信エンティティ及び前記第２の通信エンティティのうちの１つによって最初にもたらされた救済アクションから前記サービング通信エンティティとして前記第２の通信エンティティを再び選択するためのコンピュータ可読コード；
をさらに備えている、
請求項３３に記載のコンピュータプロダクト。
【請求項３９】
前記通信システムにおけるアクセス端末のために、順方向リンクのサービング通信エンティティと逆方向リンクのサービング通信エンティティの両方としてサービス提供し、
前記別の通信エンティティへの前記順方向リンク通信エンティティと逆方向リンク通信エンティティのうちの１つのハンドオフのために別の通信エンティティから通知を受信し、
前記順方向リンク通信エンティティと逆方向通信エンティティのうちの他のものとして、前記アクセス端末を継続的にサービス提供するための物理的に具現化されたコンピュータ可読コード、
を備えているコンピュータ可読メディア、
を含んでいるコンピュータプロダクト。
【請求項４０】
前記通知は前記別の通信エンティティへの前記順方向リンク通信エンティティのハンドオフのためのリクエストであり、前記コンピュータ可読メディアは、
前記アクセス端末でＩＰ（インターネットプロトコル）データパケットを処理するためのルートを維持し、
前記別の通信エンティティに対してフルＩＰデータパケットを送信し、
前記ルートを使用して、前記アクセス端末に、前記別の通信エンティティを介して、部分ＩＰデータパケットをトンネリングするためのコンピュータ可読コード、
をさらに備えている、
請求項３９に記載のコンピュータプロダクト。
【請求項１】
１セットの通信条件のアセスメントを提供することと、
前記アセスメントに基づいて、第１の通信エンティティに対して順方向通信リンクを割り付けることと、
前記アセスメントに基づいて、第２の通信エンティティに対して逆方向通信リンクを割り付けることと、
を備えている通信の方法。
【請求項２】
前記第１の通信エンティティ及び前記第２の通信エンティティとの通信のために、第１のルート及び第２のルートをそれぞれ提供することと、
前記第１の通信エンティティ及び前記第２の通信エンティティのどれがサービング通信エンティティとして割り当てられているかに関わらず、前記第１の通信エンティティ及び前記第２の通信エンティティとそれぞれ関係している前記第１のルート及び前記第２のルートを維持することと、
をさらに備えている請求項１に記載の方法。
【請求項３】
無線通信システムにおいて動作可能なアクセス端末による方法であって、
前記アクセス端末において複数のルートを提供することと、
第１のルートとして第１の通信エンティティと通信するための前記ルートのうちの１つを割り付けることと、
第２のルートとして第２の通信エンティティと通信するための前記ルートのうちの別のものを割り付けることと、
前記第１の通信エンティティ及び前記第２の通信エンティティのどれがサービング通信エンティティとして割り当てられているかに関わらず、前記第１の通信エンティティ及び前記第２の通信エンティティとそれぞれ関係している前記第１のルート及び前記第２のルートを維持することと、
を備えている方法。
【請求項４】
前記サービング通信エンティティとして前記第２の通信エンティティを選択することと、
前記第１のルートを使用して前記データパケットを処理する前に、前記第２のルートを使用して部分ＩＰ（インターネットプロトコル）データパケットを処理することと、
をさらに備えている請求項３に記載の方法。
【請求項５】
順方向リンクのサービング通信エンティティとして前記第１の通信エンティティを選択することと、
逆方向リンクのサービング通信エンティティとして前記第２の通信エンティティを選択することと、
をさらに備えている請求項３に記載の方法。
【請求項６】
前記サービング通信エンティティが順方向リンク通信エンティティあるいは逆方向リンクのサービング通信エンティティであるかどうかに関わらず、前記第１の通信エンティティ及び前記第２の通信エンティティとそれぞれ関係している前記第１のルート及び前記第２のルートを維持することと、をさらに備えている請求項３に記載の方法。
【請求項７】
前記アクセス端末と前記第１の通信エンティティとの間の第１の通信セッションに関連づけられた前記第１のルートパラメータに含めることと、前記アクセス端末と第２の通信エンティティとの間の第２の通信セッションに関連づけられた前記第２のルートパラメータに含めることと、をさらに備えている請求項３に記載の方法。
【請求項８】
前記サービング通信エンティティとして前記第１の通信エンティティを最初に選択することと；
前記サービング通信エンティティとして前記第２の通信エンティティをそのあとで選択することと、なお、前記第１の通信エンティティは、前記サービング通信エンティティとして誤って割り当てられている；
前記第１の通信エンティティ及び前記第２の通信エンティティとのうちの１つによって最初にもたらされた救済アクションから前記サービング通信エンティティとして前記第２の通信エンティティを再び選択することと；
をさらに備えている請求項３に記載の方法。
【請求項９】
通信システムにおいて動作可能な通信エンティティによる方法であって、
前記通信システムにおけるアクセス端末のために、順方向リンクのサービング通信エンティティと逆方向リンクのサービング通信エンティティとの両方としてサービス提供することと、
前記別の通信エンティティへの前記順方向リンク通信エンティティと前記逆方向通信エンティティとのうちの１つのハンドオフのために、別の通信エンティティから通知を受信することと、
前記順方向リンクの通信エンティティと前記逆方向リンクの通信エンティティの他のものとして、前記アクセス端末を継続的にサービス提供することと、
を備えている方法。
【請求項１０】
前記通知は、前記別の通信エンティティへの前記順方向リンクの通信エンティティのハンドオフのためのリクエストであって、前記方法は、
前記アクセス端末でＩＰ（インターネットプロトコル）データパケットを処理するためのルートを維持することと、
前記別の通信エンティティに対してフルＩＰデータパケットを送信することと、
前記ルートを使用して前記アクセス端末に対して、前記別の通信エンティティを介して、部分ＩＰデータパケットをトンネリングすることと、
をさらに備えている、請求項９に記載の方法。
【請求項１１】
通信のための装置であって、
１セットの通信条件のアセスメントを提供するための手段と、
前記アセスメントに基づいて、第１の通信エンティティに対して順方向通信リンクを割り付けるための手段と、
前記アセスメントに基づいて、第２の通信エンティティに対して逆方向通信リンクを割り付けるための手段と、
を備えている装置。
【請求項１２】
それぞれ前記第１の通信エンティティ及び前記第２の通信エンティティとの通信のために、第１のルート及び第２のルートをそれぞれ提供するための手段と、
前記第１の通信エンティティ及び前記第２の通信エンティティのどれがサービング通信エンティティとして割り当てられているかに関わらず、前記第１の通信エンティティ及び前記第２の通信エンティティとそれぞれ関係している前記第１のルート及び前記第２のルートを維持するための手段と、
をさらに備えている請求項１１に記載の装置。
【請求項１３】
通信システムにおいて動作可能なアクセス端末は、
前記アクセス端末において複数のルートを提供するための手段と、
第１のルートとして第１の通信エンティティと通信するための前記ルートのうちの１つを割り付けるための手段と、
第２のルートとして第２の通信エンティティと通信するための前記ルートのうちの別のものを割り付けるための手段と、
前記第１の通信エンティティ及び前記第２の通信エンティティのどれがサービング通信エンティティとして割り当てられているかに関わらず、前記第１の通信エンティティ及び前記第２の通信エンティティとそれぞれ関係している前記第１のルート及び前記第２のルートを維持するための手段と、
を備えているアクセス端末。
【請求項１４】
前記サービング通信エンティティとして前記第２の通信エンティティを選択するための手段と、
前記第１のルートを使用して前記データパケットを処理する前に、前記第２のルートを使用して部分ＩＰ（インターネットプロトコル）データパケットを処理するための手段と、
をさらに備えている請求項１３に記載のアクセス端末。
【請求項１５】
順方向リンクのサービング通信エンティティとして前記第１の通信エンティティを選択するための手段と、
逆方向リンクのサービング通信エンティティとして前記第２の通信エンティティを選択するための手段と、
をさらに備えている請求項１３に記載のアクセス端末。
【請求項１６】
前記サービング通信エンティティが順方向リンク通信エンティティあるいは逆方向リンクのサービング通信エンティティであるかどうかに関わらず、前記第１の通信エンティティ及び前記第２の通信エンティティとそれぞれ関係している前記第１のルート及び前記第２のルートを維持するための手段と、をさらに備えている請求項１３に記載のアクセス端末。
【請求項１７】
前記アクセス端末と前記第１の通信エンティティとの間の第１の通信セッションに関連づけられた前記第１のルートパラメータに含めるための手段と、前記アクセス端末と第２の通信エンティティとの間の第２の通信セッションに関連づけられた前記第２のルートパラメータに含めるための手段と、をさらに備えている請求項１３に記載のアクセス端末。
【請求項１８】
前記サービング通信エンティティとして前記第１の通信エンティティを最初に選択するための手段と；
前記サービング通信エンティティとして前記第２の通信エンティティをそのあとで選択するための手段と、なお、前記第１の通信エンティティは、前記サービング通信エンティティとして誤って割り当てられている；
前記サービング通信エンティティとして前記第１の通信エンティティを再び選択するための手段と；
をさらに備えている請求項１３に記載のアクセス端末。
【請求項１９】
通信システムにおいて動作可能な通信エンティティは、
前記通信システムにおけるアクセス端末のために、順方向リンクのサービング通信エンティティと逆方向リンクのサービング通信エンティティとの両方としてサービス提供するための手段と、
前記別の通信エンティティへの前記順方向リンク通信エンティティと前記逆方向通信エンティティとのうちの１つのハンドオフのために、別の通信エンティティから通知を受信するための手段と、
前記順方向リンクの通信エンティティと前記逆方向リンクの通信エンティティの他のものとして、前記アクセス端末を継続的にサービス提供するための手段と、
を備えている通信エンティティ。
【請求項２０】
前記通知は、前記別の通信エンティティへの前記順方向リンクの通信エンティティのハンドオフのためのリクエストであって、前記通信エンティティは、
前記アクセス端末でＩＰ（インターネットプロトコル）データパケットを処理するためのルートを維持するための手段と、
前記別の通信エンティティに対してフルＩＰデータパケットを送信するための手段と、
前記ルートを使用して前記アクセス端末に対して、前記別の通信エンティティを介して、部分ＩＰデータパケットをトンネリングするための手段と、
をさらに備えている、請求項１９に記載の通信エンティティ。
【請求項２１】
プロセッサと、
１セットの通信条件のアセスメントを提供し、前記アセスメントに基づいて第１の通信エンティティに順方向通信リンクを割り付けるように、また、前記アセスメントに基づいて第２の通信エンティティに逆方向通信リンクを割り付けるように、構成された前記プロセッサに結合された回路と、
を備えている通信のための装置。
【請求項２２】
前記プロセッサに結合された前記回路は、それぞれ前記第１の通信エンティティ及び前記第２の通信エンティティとの通信のために第１のルート及び第２のルートをそれぞれ提供し、前記第１の通信エンティティ及び前記第２の通信エンティティのどれがサービング通信エンティティとして割り当てられているかに関わらず、前記第１の通信エンティティ及び前記第２の通信エンティティとそれぞれ関係している前記第１のルート及び前記第２のルートを維持するように、さらに構成されている請求項２１に記載の装置。
【請求項２３】
通信システムにおいて動作可能なアクセス端末は、
プロセッサと、
前記アクセス端末における複数のルートを提供し、第１のルートとして第１の通信エンティティと通信するために前記ルートのうちの１つを割り付け、第２のルートとして第２の通信エンティティと通信するために前記ルートのうちの別のものを割り付け、そして、前記第１の通信エンティティ及び前記第２の通信エンティティのどれがサービング通信エンティティとして割り当てられているかに関わらず、前記第１の通信エンティティ及び前記第２の通信エンティティとそれぞれ関係している前記第１のルート及び前記第２のルートを維持するように、構成された前記プロセッサに結合された回路と、
を備えているアクセス端末。
【請求項２４】
前記プロセッサに結合された前記回路は、前記サービング通信エンティティとして前記第２の通信エンティティを選択し、そして、前記第１のルートを使用して前記データパケットを処理する前に、前記第２のルートを使用して部分ＩＰ（インターネットプロトコル）データパケットを処理するようにさらに構成されている、請求項２３に記載のアクセス端末。
【請求項２５】
前記プロセッサに結合された前記回路は、順方向リンクのサービング通信エンティティとして前記第１の通信エンティティを選択し、逆方向リンクのサービング通信エンティティとして前記第２の通信エンティティを選択するようにさらに構成されている、請求項２３に記載のアクセス端末。
【請求項２６】
前記プロセッサに結合された前記回路は、前記サービング通信エンティティが順方向リンクのサービング通信エンティティあるいは逆方向リンクのサービング通信エンティティであるかどうかに関わらず、前記第１の通信エンティティ及び前記第２の通信エンティティとそれぞれ関係している前記第１のルート及び前記第２のルートを維持するようにさらに構成されている、請求項２３に記載のアクセス端末。
【請求項２７】
前記プロセッサに結合された前記回路は、前記アクセス端末と前記第１の通信エンティティとの間の第１の通信セッションに関連づけられた前記第１のルートパラメータに含め、前記アクセス端末と第２の通信エンティティとの間の第２の通信セッションに関連づけられた前記第２のルートパラメータに含むようにさらに構成されている、請求項２３に記載のアクセス端末。
【請求項２８】
前記プロセッサに結合された前記回路は、前記サービング通信エンティティとして前記第１の通信エンティティを最初に選択し、前記サービング通信エンティティとして前記第２の通信エンティティをそのあとで選択し、もし前記第１の通信エンティティが前記サービング通信エンティティとして誤って割り当てられている場合には、前記サービング通信エンティティとして前記第２の通信エンティティを再び選択するようにさらに構成されている、請求項２３に記載のアクセス端末。
【請求項２９】
通信システムにおいて動作可能な通信エンティティは、
プロセッサと、
前記通信システムにおけるアクセス端末のために、順方向リンクのサービング通信エンティティと逆方向リンクのサービング通信エンティティとの両方としてサービス提供し、前記別の通信エンティティへの前記順方向リンク通信エンティティと前記逆方向通信エンティティとのうちの１つのハンドオフのために、別の通信エンティティから通知を受信し、前記順方向リンクの通信エンティティと前記逆方向リンクの通信エンティティの他のものとして、前記アクセス端末を継続的にサービス提供するように構成された前記プロセッサに結合された回路と、
を備えている通信エンティティ。
【請求項３０】
前記通知は、前記別の通信エンティティへの前記順方向リンクの通信エンティティのハンドオフのためのリクエストであり、前記回路に結合された前記プロセッサは、前記アクセス端末でＩＰ（インターネットプロトコル）データパケットを処理するためのルートを維持し、前記別の通信エンティティに対してフルＩＰデータパケットを送信し、前記ルートを使用して前記アクセス端末に対して、前記別の通信エンティティを介して、部分ＩＰデータパケットをトンネリングするようにさらに構成されている、請求項２９に記載の通信エンティティ。
【請求項３１】
１セットの通信条件のアセスメントを提供し、
前記アセスメントに基づいて、第１の通信エンティティに対して順方向通信リンクを割り付け、
前記アセスメントに基づいて、第２の通信エンティティに対して逆方向通信リンクを割り付けるための物理的に具現化されたコンピュータ可読コード、
を備えているコンピュータ可読メディア、
を含んでいるコンピュータプロダクト。
【請求項３２】
前記コンピュータ可読メディアは、
前記第１の通信エンティティ及び前記第２の通信エンティティそれぞれとの通信のために、第１のルート及び第２のルートをそれぞれ提供し、
前記第１の通信エンティティ及び前記第２の通信エンティティのどれがサービング通信エンティティとして割り当てられているかに関わらず、前記第１の通信エンティティ及び前記第２の通信エンティティにそれぞれ関係している前記第１のルート及び前記第２のルートを維持するためのコンピュータ可読コード、
をさらに備えている、
請求項３１に記載のコンピュータプロダクト。
【請求項３３】
前記アクセス端末において複数のルートを提供し、
第１のルートとして第１の通信エンティティと通信するために前記ルートのうちの１つを割り付け、
第２のルートとして第２の通信エンティティと通信するために前記ルートのうちの別のものを割り付け、
前記第１の通信エンティティ及び前記第２の通信エンティティのどれがサービング通信エンティティとして割り当てられているかに関わらず、前記第１の通信エンティティ及び前記第２の通信エンティティをそれぞれ関係している前記第１のルート及び前記第２のルートを維持するための物理的に具現化されたコンピュータ可読コード、
を備えているコンピュータ可読メディア、
を含んでいるコンピュータプロダクト。
【請求項３４】
前記コンピュータ可読メディアは、
前記サービング通信エンティティとして前記第２の通信エンティティを選択し、
前記第１のルートを使用して前記データパケットを処理する前に、前記第２のルートを使用して部分ＩＰ（インターネットプロトコル）データパケットを処理するためのコンピュータ可読コード、
をさらに備えている、
請求項３３に記載のコンピュータプロダクト。
【請求項３５】
前記コンピュータ可読メディアは、
順方向リンクのサービング通信エンティティとして前記第１の通信エンティティを選択し、
逆方向リンクのサービング通信エンティティとして前記第２の通信エンティティを選択するためのコンピュータ可読コード、
をさらに備えている、
請求項３３に記載のコンピュータプロダクト。
【請求項３６】
前記コンピュータ可読メディアは、前記サービング通信エンティティが順方向リンクのサービング通信エンティティあるいは逆方向リンクのサービング通信エンティティであるかどうかに関わらず、前記第１の通信エンティティ及び前記第２の通信エンティティとそれぞれ関係している前記第１のルート及び前記第２のルートを維持するためのコンピュータ可読コードをさらに備えている、請求項３３に記載のコンピュータプロダクト。
【請求項３７】
前記コンピュータ可読メディアは、前記アクセス端末と前記第１の通信エンティティとの間の第１の通信セッションに関連づけられた前記第１のルートに含み、前記アクセス端末と第２の通信エンティティとの間の第２の通信セッションに関連づけられた前記第２のルートパラメータに含めるためのコンピュータ可読コード、をさらに備えている、請求項３３に記載のコンピュータプロダクト。
【請求項３８】
前記コンピュータ可読メディアは、
前記サービング通信エンティティとして前記第１の通信エンティティを最初に選択し；
前記サービング通信エンティティとして前記第２の通信エンティティをそのあとで選択し、なお、前記第１の通信エンティティは、前記サービング通信エンティティとして誤って割り当てられている；
前記第１の通信エンティティ及び前記第２の通信エンティティのうちの１つによって最初にもたらされた救済アクションから前記サービング通信エンティティとして前記第２の通信エンティティを再び選択するためのコンピュータ可読コード；
をさらに備えている、
請求項３３に記載のコンピュータプロダクト。
【請求項３９】
前記通信システムにおけるアクセス端末のために、順方向リンクのサービング通信エンティティと逆方向リンクのサービング通信エンティティの両方としてサービス提供し、
前記別の通信エンティティへの前記順方向リンク通信エンティティと逆方向リンク通信エンティティのうちの１つのハンドオフのために別の通信エンティティから通知を受信し、
前記順方向リンク通信エンティティと逆方向通信エンティティのうちの他のものとして、前記アクセス端末を継続的にサービス提供するための物理的に具現化されたコンピュータ可読コード、
を備えているコンピュータ可読メディア、
を含んでいるコンピュータプロダクト。
【請求項４０】
前記通知は前記別の通信エンティティへの前記順方向リンク通信エンティティのハンドオフのためのリクエストであり、前記コンピュータ可読メディアは、
前記アクセス端末でＩＰ（インターネットプロトコル）データパケットを処理するためのルートを維持し、
前記別の通信エンティティに対してフルＩＰデータパケットを送信し、
前記ルートを使用して、前記アクセス端末に、前記別の通信エンティティを介して、部分ＩＰデータパケットをトンネリングするためのコンピュータ可読コード、
をさらに備えている、
請求項３９に記載のコンピュータプロダクト。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図２】
【図３】
【図４】
【図５】
【図６】
【公開番号】特開２０１２−１９９９５８（Ｐ２０１２−１９９９５８Ａ）
【公開日】平成２４年１０月１８日（２０１２．１０．１８）
【国際特許分類】
【外国語出願】
【出願番号】特願２０１２−１１１７５５（Ｐ２０１２−１１１７５５）
【出願日】平成２４年５月１５日（２０１２．５．１５）
【分割の表示】特願２０１０−５０６５３１（Ｐ２０１０−５０６５３１）の分割
【原出願日】平成２０年４月２５日（２００８．４．２５）
【出願人】（５９５０２０６４３）クゥアルコム・インコーポレイテッド (7,166)
【氏名又は名称原語表記】ＱＵＡＬＣＯＭＭ ＩＮＣＯＲＰＯＲＡＴＥＤ
【Ｆターム（参考）】
【公開日】平成２４年１０月１８日（２０１２．１０．１８）
【国際特許分類】
【出願番号】特願２０１２−１１１７５５（Ｐ２０１２−１１１７５５）
【出願日】平成２４年５月１５日（２０１２．５．１５）
【分割の表示】特願２０１０−５０６５３１（Ｐ２０１０−５０６５３１）の分割
【原出願日】平成２０年４月２５日（２００８．４．２５）
【出願人】（５９５０２０６４３）クゥアルコム・インコーポレイテッド (7,166)
【氏名又は名称原語表記】ＱＵＡＬＣＯＭＭ ＩＮＣＯＲＰＯＲＡＴＥＤ
【Ｆターム（参考）】
[ Back to top ]