JP2013520096A - 複数のサイト間のデータ分割 - Google Patents

Abstract

ワイヤレス通信ネットワークにおいてデータを分割すること。ＵＥがセルエッジにある場合に帯域幅を向上させるために、データが、複数の基地局を使用してユーザ機器に送信されるように分割されることが可能であり、またはハンドオーバを向上させるためにユーザ機器によって、複数の基地局に送信されるように分割されることが可能である。データ分割は、ユーザ機器上、または基地局上のパケットデータコンバージェンスプロトコル層、無線リンク制御層、または媒体アクセス制御層において実行されることが可能である。データは、Ｘ２インターフェース負荷またはＸ２インターフェース遅延キャリア集約を低減するために、サービングゲートウェイなどのネットワークノードにおいて、代わりに分割されてもよい。

Description

本発明は、３ＧＰＰにおけるユーザ機器の動作に関する。

関連出願の相互参照
本出願は、参照によりともに本明細書に組み込まれている、２０１０年２月１２日に出願した米国特許仮出願第６１／３０３，７６９号明細書、および２０１０年２月１２日に出願した米国特許仮出願第６１／３０４，３７７号明細書の利益を主張するものである。

より高いデータレートおよびスペクトル効率をサポートするために、３ＧＰＰ（第３世代パートナーシッププロジェクト）ＬＴＥ（ロングタームエボリューション）システムが、３ＧＰＰ Ｒ８（リリース８）に導入されている（ＬＴＥリリース８は、本明細書でＬＴＥ Ｒ８またはＲ８−ＬＴＥと呼ばれ得る）。ＬＴＥにおいて、アップリンクの伝送は、ＳＣ−ＦＤＭＡ（シングルキャリア周波数分割多元接続）を使用して実行される。特に、ＬＴＥアップリンクで使用されるＳＣ−ＦＤＭＡは、ＤＦＴ−Ｓ−ＯＦＤＭ（離散フーリエ変換拡散直交周波数分割多重化）技術に基づく。本明細書で使用されるＳＣ−ＦＤＭＡという用語とＤＦＴ−Ｓ−ＯＦＤＭという用語は、互いに区別なく使用される。

ＬＴＥにおいて、あるいはＵＥ（ユーザ機器）と呼ばれるＷＴＲＵ（ワイヤレス送信／受信ユニット）は、ＦＤＭＡ（周波数分割多元接続）構成において、割り当てられたサブキャリアの限られた連続するセットを使用して、アップリンクで送信する。例えば、アップリンクにおける全体的なＯＦＤＭ（直交周波数分割多重化）信号帯域幅またはＯＦＤＭシステム帯域幅が、１から１００まで番号が付けられた有用なサブキャリアから成る場合、所与の第１のＷＴＲＵが、サブキャリア１〜１２上で送信するように割り当てられ、第２のＷＴＲＵが、サブキャリア１３〜２４上で送信するように割り当てられることが可能である、といった具合である。異なる複数のＷＴＲＵがそれぞれ、利用可能な伝送帯域幅のサブセットの中に送信することが可能であるのに対して、これらのＷＴＲＵにサービスを提供するｅノードＢ（発展型ノード−Ｂ）は、伝送帯域幅全体にわたって合成アップリンク信号を受信することが可能である。

ＬＴＥアドバンスト（本明細書でＬＴＥ−Ａ、ＬＴＥ Ｒ１０、またはＲ１０−ＬＴＥとも呼ばれるＬＴＥリリース１０（Ｒ１０）を含み、さらにリリース１１などの将来のリリースを含み得る）は、ＬＴＥネットワークおよび３Ｇネットワークに関する完全に準拠する４Ｇアップグレードパスを提供するＬＴＥ標準の拡張である。ＬＴＥ−Ａでは、キャリア集約がサポートされ、さらに、ＬＴＥの場合とは異なり、複数のキャリアが、アップリンク、ダウンリンク、またはアップリンクとダウンリンクの両方に割り当てられることが可能である。

ＬＴＥとＬＴＥ−Ａの両方において、ＵＥは、したがって、ユーザは、セルエッジにおいてサービス低下を経験する可能性がある。スループット、ＱｏＳ（サービス品質）、およびその他の要因は、ＵＥがセルのエッジにおいて動作させられる場合に、他のセルからの干渉によって影響を受ける可能性がある。当技術分野で必要とされているのは、セルのエッジにおけるＵＥ動作に関する問題に対処するＬＴＥ−Ａの能力を活用する方法およびシステムである。

ワイヤレス通信ネットワークにおいてデータを分割する方法およびシステムが、開示される。データは、ユーザ機器への送信のために複数の基地局を使用するように分割されることが可能であり、または複数の基地局に送信するためにユーザ機器によって分割されることが可能である。或る実施形態では、データ分割は、ＰＤＣＰ（パケットデータコンバージェンスプロトコル：Packet Data Convergence Protocol）層において実行され得る。或る実施形態では、データは、ＲＬＣ（無線リンク制御）層において分割され得る。或る実施形態では、データは、ＭＡＣ（媒体アクセス制御）層において分割され得る。これらの実施形態のそれぞれにおいて、データは、ユーザ機器上、および／または基地局上で分割され得る。或る実施形態では、データは、代わりに、サービングゲートウェイにおいてなど、ユーザプレーンで分割され得る。本開示の上記、およびさらなる態様が、後段でより詳細に説明される。

開示される実施形態の以下の詳細な説明は、添付の図面と併せて読まれると、よりよく理解される。説明のため、図面では、例示的な実施形態が示されているが、主題は、開示される特定の要素または装置に限定されない。

開示される１つまたは複数の実施形態が実施され得る例示的な通信システムを示すシステム図である。 図１Ａに示される通信システム内で使用され得る例示的なＷＴＲＵ（ワイヤレス送信／受信ユニット）を示すシステム図である。 図１Ａに示される通信システム内で使用され得る例示的な無線アクセスネットワーク、および例示的なコアネットワークを示すシステム図である。 限定的でない例示的なネットワークおよびコンポーネントキャリアの構成を示す図である。 限定的でない別の例示的なネットワークおよびコンポーネントキャリアの構成を示す図である。 限定的でない例示的なダウンリンクデータフローおよびシステムの構成を示す図である。 限定的でない例示的なアップリンクデータフローおよびシステムの構成を示す図である。 データを分割する限定的でない例示的な方法を示す図である。 限定的でない例示的なアップリンクデータフローおよびシステムの構成を示す図である。 データを分割する限定的でない例示的な方法を示す図である。 限定的でない例示的なダウンリンクデータフローおよびシステムの構成を示す図である。 限定的でない例示的なダウンリンクデータフローおよびシステムの構成を示す図である。 限定的でない例示的なアップリンクデータフローおよびシステムの構成を示す図である。 限定的でない例示的なダウンリンクデータフローおよびシステムの構成を示す図である。

図１Ａは、開示される１つまたは複数の実施形態が実施され得る例示的な通信システム１００の図である。通信システム１００は、音声、データ、ビデオ、メッセージング、ブロードキャストなどのコンテンツを複数のワイヤレスユーザに供給する多元接続システムであり得る。通信システム１００は、複数のワイヤレスユーザが、ワイヤレス帯域幅を含むシステムリソースの共有を介して、そのようなコンテンツにアクセスすることを可能にすることができる。例えば、通信システム１００は、ＣＤＭＡ（符号分割多元接続）、ＴＤＭＡ（時分割多元接続）、ＦＤＭＡ（周波数分割多元接続）、ＯＦＤＭＡ（直交ＦＤＭＡ）、ＳＣ−ＦＤＭＡ（シングルキャリアＦＤＭＡ）などの１つまたは複数のチャネルアクセス方法を使用することが可能である。

図１Ａに示されるとおり、通信システム１００は、ＷＴＲＵ（ワイヤレス送信／受信ユニット）１０２ａ、１０２ｂ、１０２ｃ、１０２ｄと、ＲＡＮ（無線アクセスネットワーク）１０４と、コアネットワーク１０６と、ＰＳＴＮ（公衆交換電話網）１０８と、インターネット１１０と、その他のネットワーク１１２とを含むことが可能であり、ただし、開示される実施形態は、任意の数のＷＴＲＵ、基地局、ネットワーク、および／またはネットワーク要素を企図することが認識されよう。ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄのそれぞれは、ワイヤレス環境において動作するように、かつ／または通信するように構成された任意のタイプのデバイスであり得る。例として、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄは、ワイヤレス信号を送信するように、かつ／または受信するように構成されることが可能であり、さらにＵＥ（ユーザ機器）、移動局、固定加入者ユニットまたはモバイル加入者ユニット、ポケットベル、セルラ電話機、ＰＤＡ（携帯情報端末）、スマートフォン、ラップトップ、ネットブック、パーソナルコンピュータ、ワイヤレスセンサ、家庭用電子機器などを含み得る。

また、通信システム１００は、基地局１１４ａと、基地局１１４ｂとを含むことも可能である。基地局１１４ａ、１１４ｂのそれぞれは、コアネットワーク１０６、インターネット１１０、および／またはネットワーク１１２などの１つまたは複数の通信ネットワークへのアクセスを円滑にするように、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄの少なくとも１つとワイヤレスでインターフェースをとるように構成された任意のタイプのデバイスであり得る。例として、基地局１１４ａ、１１４ｂは、ＢＴＳ（基地局トランシーバ）、ノード−Ｂ、ｅノードＢ、ホームノードＢ、ホームｅノードＢ、サイトコントローラ、ＡＰ（アクセスポイント）、ワイヤレスルータなどであり得る。基地局１１４ａ、１１４ｂはそれぞれ単一の要素として示されるが、基地局１１４ａ、１１４ｂは、任意の数の互いに接続された基地局および／またはネットワーク要素を含み得ることが認識されよう。

基地局１１４ａは、他の基地局、および／またはＢＳＣ（基地局コントローラ）、ＲＮＣ（無線ネットワークコントローラ）、中継ノードなどのネットワーク要素（図示せず）も含み得るＲＡＮ１０４の一部であることが可能である。基地局１１４ａおよび／または基地局１１４ｂは、セル（図示せず）と呼ばれ得る特定の地理的区域内でワイヤレス信号を送信するように、かつ／または受信するように構成され得る。セルは、セルセクタにさらに分割され得る。例えば、基地局１１４ａに関連するセルは、３つのセクタに分割され得る。このため、一実施形態では、基地局１１４ａは、３つの、すなわち、セルの各セクタにつき１つのトランシーバを含み得る。別の実施形態では、基地局１１４ａは、ＭＩＭＯ（多入力多出力）技術を使用することが可能であり、したがって、セルの各セクタにつき複数のトランシーバを利用することが可能である。

基地局１１４ａ、１１４ｂは、任意の適切なワイヤレス通信リンク（例えば、ＲＦ（無線周波数）、マイクロ波、ＩＲ（赤外線）、ＵＶ（紫外線）、可視光など）であることが可能な無線インターフェース１１６を介して、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄの１つまたは複数と通信することが可能である。無線インターフェース１１６は、任意の適切なＲＡＴ（無線アクセス技術）を使用して確立され得る。

より具体的には、前述したとおり、通信システム１００は、多元接続システムであることが可能であり、さらにＣＤＭＡ、ＴＤＭＡ、ＦＤＭＡ、ＯＦＤＭＡ、ＳＣ−ＦＤＭＡなどの１つまたは複数のチャネルアクセススキームを使用することが可能である。例えば、ＲＡＮ１０４における基地局１１４ａ、およびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、ＷＣＤＭＡ（広帯域ＣＤＭＡ）を使用して無線インターフェース１１６を確立することが可能なＵＴＲＡ（ＵＭＴＳ（ユニバーサルモバイルテレコミュニケーションズシステム）地上無線アクセス）などの無線技術を実施することが可能である。ＷＣＤＭＡは、ＨＳＰＡ（高速パケットアクセス）および／またはＨＳＰＡ＋（発展型ＨＳＰＡ）などの通信プロトコルを含み得る。ＨＳＰＡは、ＨＳＤＰＡ（高速ダウンリンクパケットアクセス）および／またはＨＳＵＰＡ（高速アップリンクパケットアクセス）を含み得る。

別の実施形態では、基地局１１４ａ、およびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、ＬＴＥ（ロングタームエボリューション）および／またはＬＴＥ−Ａ（ＬＴＥアドバンスト）を使用して無線インターフェース１１６を確立することが可能なＥ−ＵＴＲＡ（発展型ＵＭＴＳ地上無線アクセス）などの無線技術を実施することが可能である。

他の実施形態では、基地局１１４ａ、およびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、ＩＥＥＥ８０２．１６（すなわち、ＷｉＭＡＸ（ワールドワイドインターオペラビリティフォーマイクロウェイブアクセス））、ＣＤＭＡ２０００、ＣＤＭＡ２０００ １Ｘ、ＣＤＭＡ２０００ ＥＶ−ＤＯ、ＩＳ−２０００（暫定標準２０００）、ＩＳ−９５（暫定標準９５）、ＩＳ−８５６（暫定標準８５６）、ＧＳＭ（グローバルシステムフォーモバイルコミュニケーションズ）、ＥＤＧＥ（エンハンストデータレートフォーＧＳＭエボリューション）、ＧＥＲＡＮ（ＧＳＭ ＥＤＧＥ）などの無線技術を実施することが可能である。

図１Ａの基地局１１４ｂは、例えば、ワイヤレスルータ、ホームノードＢ、ホームｅノードＢ、またはアクセスポイントであることが可能であり、さらに事業所、自宅、車両、キャンパスなどの局所化された区域内でワイヤレス接続を円滑にするための任意の適切なＲＡＴを利用することが可能である。一実施形態では、基地局１１４ｂ、およびＷＴＲＵ１０２ｃ、１０２ｄは、ＩＥＥＥ８０２．１１などの無線技術を実施して、ＷＬＡＮ（ワイヤレスローカルエリアネットワーク）を確立することが可能である。別の実施形態では、基地局１１４ｂ、およびＷＴＲＵ１０２ｃ、１０２ｄは、ＩＥＥＥ８０２．１５などの無線技術を実施して、ＷＰＡＮ（ワイヤレスパーソナルエリアネットワーク）を確立することが可能である。さらに別の実施形態では、基地局１１４ｂ、およびＷＴＲＵ１０２ｃ、１０２ｄは、セルラベースのＲＡＴ（例えば、ＷＣＤＭＡ、ＣＤＭＡ２０００、ＧＳＭ、ＬＴＥ、ＬＴＥ−Ａなど）を利用して、ピコセルまたはフェムトセルを確立することが可能である。図１Ａに示されるとおり、基地局１１４ｂは、インターネット１１０に対する直接接続を有し得る。このため、基地局１１４ｂは、コアネットワーク１０６を介してインターネット１１０にアクセスすることを要求されない可能性がある。

ＲＡＮ１０４は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄの１つまたは複数に音声、データ、アプリケーション、および／またはＶｏＩＰ（ボイスオーバーインターネットプロトコル）サービスを提供するように構成された任意のタイプのネットワークであり得るコアネットワーク１０６と通信状態にあることが可能である。例えば、コアネットワーク１０６は、呼制御、料金請求サービス、モバイルロケーションベースのサービス、プリペイド通話、インターネット接続、ビデオ配信などを提供することが可能であり、かつ／またはユーザ認証などの高レベルセキュリティ機能を実行することが可能である。図１Ａに示されないものの、ＲＡＮ１０４および／またはコアネットワーク１０６は、ＲＡＮ１０４と同一のＲＡＴ、または異なるＲＡＴを使用する他のＲＡＮと直接または間接の通信状態にあることが可能であることが認識されよう。例えば、Ｅ−ＵＴＲＡ無線技術を利用していることが可能なＲＡＮ１０４に接続されていることに加えて、コアネットワーク１０６は、ＧＳＭ無線技術を使用する別のＲＡＮ（図示せず）と通信状態にあることも可能である。

コアネットワーク１０６は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄが、ＰＳＴＮ１０８、インターネット１１０、および／または他のネットワーク１１２にアクセスするゲートウェイの役割をすることも可能である。ＰＳＴＮ１０８は、ＰＯＴＳ（通常の従来の電話サービス）を提供する回線交換電話網を含み得る。インターネット１１０は、ＴＣＰ／ＩＰインターネットプロトコルスイートにおけるＴＣＰ（伝送制御プロトコル）、ＵＤＰ（ユーザデータグラムプロトコル）、およびＩＰ（インターネットプロトコル）などの共通の通信プロトコルを使用する、互いに接続されたコンピュータネットワークおよびコンピュータデバイスの地球規模のシステムを含み得る。ネットワーク１１２は、他のサービスプロバイダによって所有される、かつ／または運用される有線通信ネットワークまたはワイヤレス通信ネットワークを含み得る。例えば、ネットワーク１１２は、ＲＡＮ１０４と同一のＲＡＴを使用することも、異なるＲＡＴを使用することも可能な１つまたは複数のＲＡＮに接続された別のコアネットワークを含み得る。

通信システム１００におけるＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄのいくつか、またはすべてが、マルチモード能力を含むことが可能であり、すなわち、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄは、異なる複数のワイヤレスリンクを介して異なる複数のワイヤレスネットワークと通信するための複数のトランシーバを含むことが可能である。例えば、図１Ａに示されるＷＴＲＵ１０２ｃは、セルラベースの無線技術を使用することが可能な基地局１１４ａと通信するとともに、ＩＥＥＥ８０２無線技術を使用することが可能な基地局１１４ｂと通信するように構成されることが可能である。

図１Ｂは、例示的なＷＴＲＵ１０２のシステム図である。図１Ｂに示されるとおり、ＷＴＲＵ１０２は、プロセッサ１１８と、トランシーバ１２０と、送信／受信要素１２２と、スピーカ／マイクロフォン１２４と、キーパッド１２６と、ディスプレイ／タッチパッド１２８と、非リムーバブルメモリ１３０と、リムーバブルメモリ１３２と、電源１３４と、ＧＰＳ（全地球測位システム）チップセット１３６と、他の周辺装置１３８とを含み得る。ＷＴＲＵ１０２は、或る実施形態に合致したままで、以上の要素の任意の部分的組合せを含み得ることが認識されよう。

プロセッサ１１８は、汎用プロセッサ、専用プロセッサ、従来のプロセッサ、ＤＳＰ（デジタルシグナルプロセッサ）、複数のマイクロプロセッサ、ＤＳＰコアに関連する１つまたは複数のマイクロプロセッサ、コントローラ、マイクロコントローラ、ＡＳＩＣ（特定用途向け集積回路）、ＦＰＧＡ（フィールドプログラマブルゲートアレイ）回路、他の任意のタイプのＩＣ（集積回路）、状態マシンなどであり得る。プロセッサ１１８は、信号符号化、データ処理、電力制御、入出力処理、および／またはＷＴＲＵ１０２がワイヤレス環境において動作することを可能にする他の任意の機能を実行することが可能である。プロセッサ１１８は、送信／受信要素１２２に結合され得るトランシーバ１２０に結合され得る。図１Ｂは、プロセッサ１１８とトランシーバ１２０を別々の構成要素として示しているが、プロセッサ１１８とトランシーバ１２０は、電子パッケージまたはチップに一緒に組み込まれてもよいことが認識されよう。

送信／受信要素１２２は、無線インターフェース１１６を介して基地局（例えば、基地局１１４ａ）に信号を送信するように、または基地局（例えば、基地局１１４ａ）から信号を受信するように構成され得る。例えば、一実施形態では、送信／受信要素１２２は、ＲＦ信号を送信するように、かつ／または受信するように構成されたアンテナであり得る。別の実施形態では、送信／受信要素１２２は、例えば、ＩＲ信号、ＵＶ信号、または可視光信号を送信するように、かつ／または受信するように構成されたエミッタ／検出器であり得る。さらに別の実施形態において、送信／受信要素１２２は、ＲＦ信号と光信号の両方を送受信するように構成され得る。送信／受信要素１２２は、ワイヤレス信号の任意の組合せを送信するように、かつ／または受信するように構成され得ることが認識されよう。

さらに、送信／受信要素１２２は、図１Ｂに単一の要素として示されているが、ＷＴＲＵ１０２は、任意の数の送信／受信要素１２２を含み得る。より具体的には、ＷＴＲＵ１０２は、ＭＩＭＯ技術を使用することが可能である。このため、一実施形態では、ＷＴＲＵ１０２は、無線インターフェース１１６を介してワイヤレス信号を送受信するための２つ以上の送信／受信要素１２２（例えば、複数のアンテナ）を含み得る。

トランシーバ１２０は、送信／受信要素１２２によって送信されるべき信号を変調するように、かつ送信／受信要素１２２によって受信された信号を復調するように構成され得る。前述したとおり、ＷＴＲＵ１０２は、マルチモード能力を有することが可能である。このため、トランシーバ１２０は、ＷＴＲＵ１０２が、例えば、ＵＴＲＡやＩＥＥＥ８０２．１１などの複数のＲＡＴを介して通信することを可能にするための複数のトランシーバを含み得る。

ＷＴＲＵ１０２のプロセッサ１１８は、スピーカ／マイクロフォン１２４、キーパッド１２６、および／またはディスプレイ／タッチパッド１２８（例えば、ＬＣＤ（液晶ディスプレイ）ディスプレイユニットまたはＯＬＥＤ（有機発光ダイオード）ディスプレイユニット）に結合されることが可能であり、かつスピーカ／マイクロフォン１２４、キーパッド１２６、および／またはディスプレイ／タッチパッド１２８からユーザ入力データを受け取ることが可能である。また、プロセッサ１１８は、スピーカ／マイクロフォン１２４、キーパッド１２６、および／またはディスプレイ／タッチパッド１２８にユーザデータを出力することも可能である。さらに、プロセッサ１１８は、非リムーバブルメモリ１３０、および／またはリムーバブルメモリ１３２などの任意のタイプの適切なメモリからの情報にアクセスすること、およびそのようなメモリの中にデータを格納することが可能である。非リムーバブルメモリ１３０には、ＲＡＭ（ランダムアクセスメモリ）、ＲＯＭ（読み取り専用メモリ）、ハードディスク、または他の任意のタイプのメモリストレージデバイスが含まれ得る。リムーバブルメモリ１３２には、ＳＩＭ（加入者ＩＤモジュール）カード、メモリスティック、ＳＤ（セキュアデジタル）メモリカードなどが含まれ得る。他の実施形態において、プロセッサ１１８は、サーバまたはホームコンピュータ（図示せず）などの、ＷＴＲＵ１０２から物理的に遠隔に配置されたメモリからの情報にアクセスすること、およびそのようなメモリの中にデータを格納することが可能である。

プロセッサ１１８は、電源１３４から電力を受け取ることが可能であり、さらにＷＴＲＵ１０２内のその他の構成要素に対して電力を配電するように、かつ／または制御するように構成されることが可能である。電源１３４は、ＷＴＲＵ１０２に電力を供給するための任意の適切なデバイスであり得る。例えば、電源１３４には、１つまたは複数の乾電池（例えば、ＮｉＣｄ（ニッケルカドミウム）、ＮｉＺｎ（ニッケル亜鉛）、ＮｉＭＨ（ニッケル水素）、Ｌｉ−ｉｏｎ（リチウムイオン）など）、太陽電池、燃料電池などが含まれ得る。

プロセッサ１１８は、ＷＴＲＵ１０２の現在のロケーションに関するロケーション情報（例えば、緯度と経度）を提供するように構成され得るＧＰＳチップセット１３６に結合されることも可能である。ＧＰＳチップセット１３６からの情報に加えて、またはそのような情報の代わりに、ＷＴＲＵ１０２は、基地局（例えば、基地局１１４ａ、１１４ｂ）から無線インターフェース１１６を介してロケーション情報を受信すること、および／または近くの２つ以上の基地局から受信されている信号のタイミングに基づいて、ＷＴＲＵのロケーションを特定してもよい。ＷＴＲＵ１０２は、或る実施形態と合致したままで、任意の適切なロケーション特定方法によってロケーション情報を獲得し得ることが認識されよう。

プロセッサ１１８は、さらなるフィーチャ、機能、および／または有線もしくはワイヤレスの接続をもたらす１つまたは複数のソフトウェアモジュールおよび／またはハードウェアモジュールを含み得る、他の周辺装置１３８にさらに結合されることが可能である。例えば、周辺装置１３８には、加速度計、電子コンパス、衛星トランシーバ、デジタルカメラ（写真またはビデオのための）、ＵＳＢ（ユニバーサルシリアルバス）ポート、振動デバイス、電話トランシーバ、ハンズフリーヘッドセット、Ｂｌｕｅｔｏｏｔｈ（登録商標）モジュール、ＦＭ（周波数変調）無線ユニット、デジタル音楽プレーヤ、メディアプレーヤ、ビデオゲームプレーヤモジュール、インターネットブラウザなどが含まれ得る。

図１Ｃは、或る実施形態によるＲＡＮ１０４およびコアネットワーク１０６のシステム図である。前述したとおり、ＲＡＮ１０４は、Ｅ−ＵＴＲＡ無線技術を使用して、無線インターフェース１１６を介してＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信することが可能である。ＲＡＮ１０４は、コアネットワーク１０６と通信状態にあることも可能である。

ＲＡＮ１０４は、ｅノードＢ１４０ａ、１４０ｂ、１４０ｃを含み得るが、ＲＡＮ１０４は、或る実施形態と合致したままで、任意の数のｅノードＢを含んでもよいことが認識されよう。ｅノードＢ１４０ａ、１４０ｂ、１４０ｃはそれぞれ、無線インターフェース１１６を介してＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信するための１つまたは複数のトランシーバを含み得る。一実施形態では、ｅノードＢ１４０ａ、１４０ｂ、１４０ｃは、ＭＩＭＯ技術を実施することが可能である。このため、例えば、ｅノードＢ１４０ａは、複数のアンテナを使用して、ＷＴＲＵ１０２ａにワイヤレス信号を送信すること、およびＷＴＲＵ１０２ａからワイヤレス信号を受信することが可能である。

ｅノードＢ１４０ａ、１４０ｂ、１４０ｃのそれぞれは、特定のセル（図示せず）に関連することが可能であり、さらに無線リソース管理決定、ハンドオーバ決定、アップリンクおよび／またはダウンリンクにおけるユーザのスケジューリングなどを扱うように構成され得る。図１Ｃに示されるとおり、ｅノードＢ１４０ａ、１４０ｂ、１４０ｃは、Ｘ２インターフェースを介して互いに通信することが可能である。

図１Ｃに示されるコアネットワーク１０６は、ＭＭＥ（移動性管理ゲートウェイ）１４２、サービングゲートウェイ１４４、およびＰＤＮ（パケットデータネットワーク）ゲートウェイ１４６を含むことが可能である。以上の要素のそれぞれはコアネットワーク１０６の一部として示されるが、これらの要素のうちのいずれの要素も、コアネットワーク事業者以外のエンティティによって所有され、かつ／または運用されることが可能であることが認識されよう。

ＭＭＥ１４２は、Ｓ１インターフェースを介してＲＡＮ１０４におけるｅノードＢ１４２ａ、１４２ｂ、１４２ｃのそれぞれに接続されることが可能であり、さらに制御ノードの役割をすることが可能である。例えば、ＭＭＥ１４２は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのユーザを認証すること、ベアラ活性化／不活性化、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃの初期アタッチ中に特定のサービングゲートウェイを選択することなどを担うことが可能である。また、ＭＭＥ１４２は、ＲＡＮ１０４と、ＧＳＭまたはＷＣＤＭＡなどの他の無線技術を使用する他のＲＡＮ（図示せず）との間で切り換えるための制御プレーン機能をもたらすことも可能である。

サービングゲートウェイ１４４は、Ｓ１インターフェースを介してＲＡＮ１０４におけるｅノードＢ１４０ａ、１４０ｂ、１４０ｃのそれぞれに接続され得る。サービングゲートウェイ１４４は、一般に、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに／から、ユーザデータパケットをルーティングすること、および転送することが可能である。また、サービングゲートウェイ１４４は、ｅノードＢ間ハンドオーバ中にユーザプレーンをアンカすること、ダウンリンクデータがＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに利用可能である際にページングをトリガすること、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのコンテキストを管理すること、および格納することなどの、他の機能を実行することも可能である。

また、サービングゲートウェイ１４４は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに、インターネット１１０などのパケット交換網へのアクセスを提供して、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃとＩＰ対応のデバイスとの間の通信を円滑にすることが可能であるＰＤＮゲートウェイ１４６に接続されることも可能である。

コアネットワーク１０６は、他のネットワークとの通信を円滑にすることが可能である。例えば、コアネットワーク１０６は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに、ＰＳＴＮ１０８などの回線交換網へのアクセスを提供して、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと従来の陸線通信デバイスとの間の通信を円滑にすることが可能である。例えば、コアネットワーク１０６は、コアネットワーク１０６とＰＳＴＮ１０８との間のインターフェースの役割をするＩＰゲートウェイ（例えば、ＩＭＳ（ＩＰマルチメディアサブシステム）サーバ）を含むことが可能であり、またはそのようなＩＰゲートウェイと通信することが可能である。さらに、コアネットワーク１０６は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに、他のサービスプロバイダによって所有され、かつ／または運用される他の有線ネットワークまたはワイヤレスネットワークを含み得るネットワーク１１２へのアクセスを提供することが可能である。

ＬＴＥ ＤＬ（ダウンリンク）伝送スキームは、ＯＦＤＭＡ無線インターフェースに基づくことが可能である。ＬＴＥ ＵＬ（アップリンク）方向に関して、ＤＦＴ−Ｓ−ＯＦＤＭＡ（ＤＦＴ拡散ＯＦＤＭＡ）に基づくＳＣ（シングルキャリア）伝送が使用され得る。Ｒ８ ＬＴＥ ＤＬ方向で、ＵＥは、ｅノードＢによって、ＬＴＥ伝送帯域幅全体にわたる任意の位置でＵＥのデータを受信するように割り当てられることが可能である（例えば、ＯＦＤＭＡスキームが使用され得る）。ＬＴＥ ＤＬは、スペクトルの中心に使用されないＤＣオフセットサブキャリアを有し得る。Ｒ８ ＬＴＥ ＵＬ方向で、Ｒ８ ＬＴＥシステムは、ＤＴＦ−Ｓ−ＯＦＤＭＡ伝送またはＳＣ−ＦＤＭＡ伝送に基づくことが可能である。

ＵＥは、ＤＬ方向で、ＬＴＥ伝送帯域幅全体の周波数領域にわたる任意の位置でＵＥの信号を受信することが可能である一方で、ＵＬ方向では、ＵＥは、ＦＤＭＡ（周波数分割多元接続）構成において、割り当てられたサブキャリアの、限られた（または限られた場合のみ）、ただし或る実施形態では隣接した、セット上で、送信することが可能である。この構成は、ＳＣ（シングルキャリア）ＦＤＭＡと呼ばれ得る。或る実施形態では、ＵＬにおける全体的なＯＦＤＭ信号帯域幅またはＯＦＤＭシステム帯域幅が、１から１００まで番号が付けられた有用なサブキャリアから成る場合、所与の第１のＵＥが、サブキャリア１〜１２上でＵＥの信号を送信するように割り当てられ、所与の第２のＵＥが、サブキャリア１３〜２４上で送信するように割り当てられることが可能である、といった具合である。ｅノードＢは、１つまたは複数のＵＥから伝送帯域幅全体にわたって複合ＵＬ信号を同時に受信することが可能であるが、各ＵＥは、利用可能な伝送帯域幅のサブセットの中に送信すること（またはそのように送信することだけ）が可能である。したがって、ＵＬにおけるＤＦＴ−Ｓ−ＯＦＤＭは、ＵＥに割り当てられた時間周波数リソースが、周波数の連続するサブキャリアのセットから成らなければならないというさらなる制約を伴う、従来の形態のＯＦＤＭ伝送と見なされることが可能である。ＵＬにおいて、ＤＣサブキャリアは全く存在しなくてよい。１つの動作モードで、周波数ホッピングが、ＵＥによってＵＬ伝送に適用されることが可能である。

ＬＴＥ−Ａは、ＣＡ（キャリア集約）フィーチャ、および柔軟性のある帯域幅構成フィーチャをサポートすることが可能である。このことは、ＤＬ伝送帯域幅およびＵＬ伝送帯域幅が２０ＭＨｚを超えることを許し得る（例えば、Ｒ８ ＬＴＥの場合と同様に）。例えば、４０ＭＨｚから１００ＭＨｚまでの伝送帯域幅がサポートされ得る。ＬＴＥ Ｒ１０において、ＣＣ（コンポーネントキャリア）は、このスペクトル集約フィーチャを可能にすることができる。或る実施形態では、各ＣＣにつき２０ＭＨｚの最大帯域幅を有する１００ＭＨｚまでの集約されたスペクトルが、したがって、少なくとも５つのＣＣが、構成され得る。ＬＴＥ−Ａにおいて、異なるＣＣは、異なるカバレッジ（coverage）を有し得る。

複数のＣＣを利用する或る実施形態において、マルチキャリア干渉を防止するため、または軽減するために、異なるセルが、異なるセットのＣＣを使用することが可能である。そのようなセルは、図２に示されるとおり、異なる範囲を有することが可能であり、さらに１より大きい有効周波数再利用パターンを有することが可能である。

複数のＣＣを使用するキャリア集約は、ＲＲＣ ＣＯＮＮＥＣＴＥＤ状態にあるＵＥに関係があることが可能である。アイドルなＵＥは、単一のＵＬキャリアペアおよびＤＬキャリアペアを介して（例えば、ＦＤＤ（周波数分割複信）を使用して）ネットワークにアクセスすることが可能である。ＬＴＥ−Ａ実施形態において、１つのサービングｅノードＢにおけるキャリア集約がサポートされ得る。この構成は、ＣＡセルハンドオーバオプションを、ハンドオーバの後、またはハンドオーバの前のターゲット候補ＣＣの割当てに縮小することが可能である。ハンドオーバの後にターゲット候補を割り当てることは、ユーザプレーン遅延を増加させる可能性があり、したがって、ハンドオーバ前の割当てが、より良好なパフォーマンスをもたらす可能性があり、さらにターゲットｅノードＢとソースｅノードＢとの間で測定情報交換のためのＸ２インターフェースメッセージを追加することを要求する可能性がある。

ＵＥがセルエッジに位置している場合、セルエッジにおけるパフォーマンスは、他のセルからの干渉によって制限され得るため、一様なユーザ体験（例えば、スループット、ＱｏＳなど）を提供することは、困難であり得る。或る実施形態では、ＵＥが所与の時点で或るＣＣの良好なカバレッジエリア（coverage area）内に入っている場合、ＣＣが、このセルエッジ問題を軽減するのに使用され得る。或る実施形態では、図３に示されるとおり、セルエッジまでの距離を変化させるように各ＣＣの送信電力を変えるように隣接するｅノードＢ（セルサイト）を協調させることによって、異なるセルエッジに関して重なり合うＣＣが作成され得る。

図３で、ＵＥ３５０は、位置３１０にあることが可能であり、さらにｅノードＢ３６１とＣＣ３２０を介して通信していること（３７１ａ）が可能であり、さらにｅノードＢ３６１とＣＣ３３０を介して通信していること（３７２ａ）が可能である。ＵＥ３５０が、ｅノードＢ３６２に対してＣＣ３３０が使用され得るが、ＣＣ３２０がｅノードＢ３６１のセル境界内に留まる新たな位置３１１に移動すると、ＵＥ３５０は、ｅノードＢ３６１とＣＣ３２０を介して依然として通信すること（３７１ｂ）が可能であるが、この時点で、ｅノードＢ３６２とＣＣ３３０を介して通信すること（３７２ｂ）が可能である。このことは、ネットワークが１という周波数再利用率を保ちながら、ＵＥ３５０が、異なるロケーションにおいて異なるＣＣにハンドオーバすることによって、セル中心近くに留まることを可能にし得る。このシナリオにおいて、すべてのＣＣ上でＵＥをそれぞれがサポートすることができる完全な能力の基地局（関連するＲＲＨ（ラジオヘッド）を有する基地局、および有さない基地局を含む）は、ＵＥが異なるサイトからそれぞれが送信され得るＣＣのセット上で受信することができる場合に、使用され得る。

ｅノードＢ３６１およびｅノードＢ３６２は、ｅノードＢと呼ばれるが、これらのネットワーク要素は、本明細書で説明される機能を実行することができる他の任意のタイプのデバイスおよび／またはネットワーク要素であり得ることに留意されたい。例えば、ｅノードＢ３６１および／またはｅノードＢ３６２は、ＲＲＨ（リモートラジオヘッド：remote radio head）、セクタアンテナ、任意のタイプの基地局、またはこれらもしくは他の任意のネットワーク要素の任意の組合せであり得る。任意のそのようなデバイスまたはネットワーク要素が、基地局、ｅノードＢ、ゲートウェイ、ノード、または他の任意のネットワーク要素によって実行されるものとして本明細書で説明される機能のいずれを実行するようにも構成されることが可能であり、さらにすべてのそのような実施形態が、本開示の範囲に含まれるものとして企図される。

一部のＬＴＥ Ｒ１０実施において、キャリア集約のための複数のＣＣのサポートが、１つのサービングｅノードＢに制限され得る。このことは、ＵＥが、異なる複数のｅノードＢに対して１つのＣＣを使用してデータ接続を維持することを妨げ得る。ＵＥが、図３に示されるとおり、異なる２つのｅノードＢ上のＣＣに関してカバレッジの重なり合いが存在するロケーションに移動するシナリオにおいて、ネットワークＲＲＭ（無線リソース管理）エンティティが、異なるサイトからの複数のＣＣを使用することによってデータスループット増加を十分に利用する代わりに、別のセルサイトにハンドオーバすべきかどうかを判定することが可能である。各ＣＣ上で利用可能な帯域幅を十分に利用するために、対応するデータストリームが、関連するｅノードＢにルーティングされること、および関連するｅノードＢからルーティングされることが可能である。

各データストリームは、送信および受信をサポートするのに使用される、関連するリソース（帯域幅およびバッファ）を有する。各ＣＣに関する集約帯域幅は、ネットワークの計画者によって知られ得るが、ＣＣ上でＵＥに利用可能な瞬間的な帯域幅は、通常、ｅノードＢスケジューラの動的決定である。各ＣＣにどれだけのデータを送るべきかの決定は、協調する各サイトのリソース要件に直接の影響を与える可能性がある。或る実施形態では、協調するｅノードＢは、例えば、そのｅノードＢの利用可能なリソースに関する情報を、データ分割を実行すべきかどうか、およびデータ分割をどのように実行するべきかを判定することが可能であり、かつ完全な（例えば、分割比または分割されない）データフローを受信するように構成されることが可能な、サービングｅノードＢにフィードバックすることが可能である。

或る実施形態では、ｅノードＢからＵＥへのＳＡＥ（サービスアーキテクチャエボリューション）ベアラのデータスループットは、ＲＡＮ（無線アクセスネットワーク）における複数のサイトに対するデータストリームの分割を協調させることによって、増加され得る。データ分割は、ＰＤＣＰ層（パケットデータコンバージェンスプロトコル）、ＲＬＣ（無線リンク制御）層、ＭＡＣ（媒体アクセス制御）層を含め、ＲＡＮスタックの任意の層において、または任意の組合せにおいて、または本明細書で開示される任意の手段を使用して、実施され得る。また、データ分割は、ユーザプレーンにおいて行われることも可能である。そのようなデータ分割を実行するためのシステムおよび方法は、本明細書で、より詳細に開示される。

アップリンクデータおよびダウンリンクデータは、ＲＡＮにおける複数のｅノードＢおよび他のサイト（例えば、ＲＲＨ）にわたって分割され得る。ＤＬデータ分割に関して、ｅノードＢは、入ってくるデータストリームを、協調するＣＣの数に対応するＮ個のストリームに分割することが可能である。データ分割は、協調するＣＣによって報告される帯域幅利用可能性、バッファリングするエンティティによって報告されるバッファステータス、および／またはベアラＱｏＳ要件からのデータレートに基づくことが可能である。また、ｅノードＢは、負荷に左右される機構などの、どのようにデータを分割すべきかを決定する対話型の手順をサポートすることも可能である。この機構は、瞬間的なバッファステータス、バッファステータスの別の目安（例えば、平均）、および／またはピアｅノードＢ上の既存のエンティティの帯域幅に基づくアルゴリズムを使用することが可能である。フロー制御機構は、協調するＣＣのうちの任意のＣＣ上の回復不能な伝送誤りを回復するために、まだ確認応答されていないデータをバッファリングすること、および／またはデータ分割エンティティから受け取られたデータをバッファリングして、そのデータを、帯域幅利用可能性に基づいて送信することができることが可能である。

ＤＬデータ分割において、ｅノードＢは、ＳＡＥベアラを解体することなしに、協調するＣＣを動的に追加する、または除去する能力をサポートすることも可能である。また、ｅノードＢは、現在のバッファステータスに関する定期的な測定レポート、および／またはイベントによってトリガされる測定レポートを供給するために、ならびに帯域幅利用に関する定期的な測定レポート、および／またはイベントによってトリガされる測定レポートを供給するために、伝送パスの負荷監視をサポートすることも可能である。

ＤＬデータ分割において、ＵＥは、受信されたデータをバッファリングし、さらに異なるリンクから受信されたデータの並べ替えを実行して、そのデータが、そのデータが送られた順序で上位の層に供給されることを確実にすることが可能である。この機能は、そのエンティティより上の層が、一般に、そのような並べ替えを実行する能力を有さない（例えば、動作の通常の過程でそのような並べ替えを実行する能力を有さないなどの）場合に使用され得る。また、ＵＥは、順次のデリバリをサポートすることも可能であり、かつデータストリーム分割に対応するデータパスをセットアップするように、影響を受ける層を構成することが可能である。

ＤＬデータ分割において、Ｘ２インターフェース（例えば、トンネリング）が、いくつかの機能をサポートすることが可能である。Ｘ２ ＡＰ（Ｘ２アプリケーションプロトコル）が、データ分割エンティティの構成および制御をもたらすことが可能であり、かつ測定レポートおよび／または帯域幅監視レポートをもたらすこと、ならびにエンティティのセットアップ、変更、および／または解放の構成をもたらすことを担うことが可能である。Ｘ２データトランスポートプロトコルまたはＸ２データトンネリングプロトコルは、サービングｅノードＢと協調するｅノードＢとの間にデータ分割エンティティを接続して、接続されたｅノードＢの間でデータの送信および／もしくは受信をもたらすこと、ならびに／または接続された２つのエンティティの間でデータ制御メッセージ（例えば、リセットメッセージ、バッファステータス、帯域幅監視レポートなど）を転送することが可能である。また、Ｘ２データトランスポートプロトコルまたはＸ２データトンネリングプロトコルは、Ｘ２ ＡＰを介して、またはトンネリングプロトコルを介する帯域内シグナリングを通じて、フロー制御交換をサポートすることも可能である。

ＵＬデータ分割において、ＵＥは、入ってくるデータストリームを、協調するＣＣの数に対応するＮ個のストリームに分割することが可能である。データ分割は、協調するＣＣによってスケジュールされる帯域幅利用可能性、バッファリングエンティティから報告されるバッファステータス、および／またはベアラＱｏＳ要件からのデータレートに基づくことが可能である。ＵＥは、瞬間的なバッファステータスもしくは他の目安のバッファステータス、および／またはｅノードＢによってスケジュールされたＵＬ帯域幅に基づくアルゴリズムを使用する負荷に左右されるフロー制御機構をサポートすることが可能である。フロー制御機構は、協調するＣＣのうちの任意のＣＣ上の回復不能な伝送誤りを回復するために、まだ確認応答されていないデータをバッファリングすること、および／またはデータ分割エンティティから受け取られたデータをバッファリングして、そのデータを、帯域幅利用可能性に基づいて送信することができることが可能である。

ＵＬデータ分割において、ＵＥは、ＳＡＥベアラを解体することなしに、協調するＣＣを動的に追加する、または除去する構成をサポートすることも可能である。ＵＥは、現在のバッファステータスに関する定期的な測定レポート、および／もしくはイベントによってトリガされる測定レポートをデータ分割エンティティに供給するために、ならびに／または帯域幅利用に関する定期的な測定レポート、および／もしくはイベントによってトリガされる測定レポートを供給するために、伝送パスの負荷監視をサポートすることも可能である。

ＵＬデータ分割において、ｅノードＢは、ＵＥに対する帯域幅をスケジュールし（協調するｅノードＢの同期を伴って、または伴わずに）、かつ受信されたデータをバッファリングし、さらに、異なるリンクから受信されたデータの並べ替えを実行して、そのデータが、そのデータが送られた順序で上位の層に供給されることを確実にするように構成され得る。この並べ替え機能は、そのエンティティより上の層が、一般に、そのような並べ替えを実行する能力を有さない（例えば、動作の通常の過程でそのような並べ替えを実行する能力を有さないなどの）場合に使用され得る。また、ｅノードＢは、順次のデリバリをサポートすること、およびデータストリーム分割に対応するデータパスをセットアップするように、影響を受ける層を構成することをサポートすることも可能である。

ＵＬデータ分割において、Ｘ２インターフェース（例えば、トンネリング）が、いくつかの機能をサポートすることが可能である。Ｘ２アプリケーションプロトコルは、構成をもたらすことが可能であり、データ分割エンティティを制御することが可能であり、かつ測定レポートおよび／もしくは帯域幅レポートを送ること、ならびに／またはエンティティのセットアップ、変更、および／もしくは解放の構成をもたらすことを担うことが可能である。トンネリングプロトコルは、サービングｅノードＢと協調するｅノードＢとの間にデータ分割エンティティを接続して、接続されたｅノードＢの間でデータの伝送をもたらすこと、および／または接続された２つのエンティティの間でデータ制御メッセージ（例えば、リセットメッセージ、測定レポートなど）を転送することが可能である。

或る実施形態において、データ分割は、ＰＤＣＰ層において実行され得る。ソースｅノードＢにおいてインターワーキング機能（ＰＤＣＰ ＩＷＦ）が使用されて、協調するｅノードＢにおけるＰＤＣＰ ＩＷＦに圧縮されたＩＰパケット（ＰＤＣＰ ＰＤＵ）が転送されてから、送信バッファリングのためにＲＬＣ層に転送されることが可能である。ＰＤＣＰ ＩＷＦは、１つのＳＡＥベアラ当り複数の無線ベアラのサポートを提供することが可能である。

図４は、ＰＤＣＰ層においてデータ分割を実行するデータ分割実施形態において使用され得る例示的なＤＬデータフローおよびシステム構成を示す。ＵＥ４０１は、ＵＥ４０１がｅノードＢ４１０およびｅノードＢ４２０の両方と通信することを許すロケーションにあることが可能である。ＩＰパケット４０５は、ｅノードＢ４１０において受信されることが可能であり、さらにＩＰパケット４０５の宛先としてＵＥ４０１を有することが可能である。ＩＰパケット４０５は、無線ベアラ４０３ａおよび４０３ｂを含み得るＳＡＥベアラ４０２を介してｅノードＢ４１０に送信され得る。ＰＤＣＰ ＩＷＦ４５０は、ｅノードＢ間トンネル４４０を部分的に用いて、ｅノードＢ４１０とｅノードＢ４２０との間でデータを分割することを円滑にすることが可能である。

ＩＰヘッダ圧縮が、ヘッダ圧縮モジュール４１１ａおよび４１１ｂにおいて実行されて、ラジオインターフェースを介して送信される必要があるビットの数を減らすことが可能である。任意のモード（例えば、Ｕモード（単方向モード）、Ｏモード（双方向楽観モード）、およびＲモード（双方向高信頼モード））で堅牢なヘッダ圧縮が使用され得る。ＯモードおよびＲモードは、誤り回復のためにフィードバックチャネルを利用することが可能である。圧縮は前のフレーム情報を使用するため、ヘッダ圧縮モジュール４１１ａおよび４１１ｂによって実行されるヘッダ圧縮処理が実行されてから、フィードバック処理を伴うデータ分割が、１つのエンティティにおいて（例えば、１つだけのエンティティにおいて）実行されることが可能である。

送信されるデータの暗号化および完全性保護が、暗号化モジュール４１２ａおよび４１２ｂにおいて実行され得る。ｅノードＢ間トンネル４４０が、ＰＤＣＰ ＰＤＵの一部分を、分割されたデータストリームサブフローとして、協調するｅノードＢ４２０に伝送するが、複数のＨＦＮ（ハイパーフレーム番号）およびＰＤＣＰ ＳＮ（シーケンス番号）をシグナリングするとともに、保持しなければならないことを回避するように、暗号化の後に伝送することが可能である。

データは、ＰＤＣＰ ｅノードＢ間マルチプレクサ４１３において分割されることが可能であり、ｅノードＢ４２０のために分割されたデータが、ｅノードＢ間トンネル４４０を介してｅノードＢ４２０に送信されることが可能である。ｅノードＢ４１０から送信されるべきデータは、ＲＬＣバッファ４１４ａおよび４１４ｂに供給され、ＭＡＣマルチプレクサ４１５によってＭＡＣ層において多重化され、ＰＨＹ変調−符号化モジュール４１７によって物理層において変調され、符号化されて、さらにＣＣ４７１を介してＵＥ４０１に最終的に送信されることが可能である。ｅノードＢ４２０から送信されるべきデータは、ＲＬＣバッファ４２４ａおよび４２４ｂに供給され、ＭＡＣマルチプレクサ４２５によってＭＡＣ層において多重化され、ＰＨＹ変調−符号化モジュール４２７によって物理層において変調され、符号化されて、さらにＣＣ４７２を介してＵＥ４０１に最終的に送信されることが可能である。ｅノードＢ４１０およびｅノードＢ４２０は、ＵＥ４０１からチャネルステータスデータ４１９および４２９（例えば、ダウンリンクチャネル品質情報）を受信し、さらにＲＬＣバッファからデータを受け取り、ＭＡＣマルチプレクサおよびＰＨＹ変調−符号化モジュールを用いてデータの送信を協調させるＭＡＣスケジューラ４１６および４２６をそれぞれ有することが可能である。

移動端末装置のために構成された１つの無線ベアラ当り１つのＰＤＣＰエンティティが存在し得る。データ分割をサポートするのに、スケジューラ（例えば、受け取られたＰＤＣＰパケットの、活性のサイトへの単純なラウンドロビン配布、または宛先ｅノードＢ４２０からのバッファステータスフィードバックまたは送信レートフィードバックを用いた何らかの分割アルゴリズムに基づく）が、別のＣＣを介して送信するために別のサイト（例えば、ｅノードＢ４２０）にＰＤＣＰ ＰＤＵ（例えば、ＩＰパケット４０５の一部分を含む）を転送するのに使用され得る。この構成は、１つの無線ベアラ当りセットアップされる２つ以上の（或る実施形態では、一緒に送信するサイトの数に依存する）データストリーム（例えば、ＰＤＣＰ／ＲＬＣ／ＭＡＣ）をもたらす（例えば、参加するＣＣ当り１つ、さらにＵＥに関してＮ個、ただし、Ｎは、参加するＣＣの総数）。ＰＤＣＰ／ＲＬＣインターフェース上に存在するスケジューラが、ＲＬＣ層におけるさらなる処理のために、メインサービングサイトおよび協調サイトを含む異なる複数のサイトへのデータ転送のスケジューリングを担うことが可能である。

ＰＤＣＰ ＩＷＦ４５０において、協調するＣＣにおける輻輳した、または限られたＰＨＹ（物理層）帯域幅がバッファオーバフローを生じた場合にデータが失われるのを回避するのに、フロー機構が使用され得る。フロー機構は、協調するＣＣに関するデータバッファステータス（例えば、ＲＬＣバッファ占有率）、および／または瞬間的な帯域幅情報、もしくは帯域幅の他の何らかの目安の情報をもたらす、トンネリングプロトコルを介したフィードバックであり得る。

図５に示されるＰＤＣＰ層における対応するＵＬデータ分割は、ＤＬの場合と同一のモジュールレイアウトを利用するが、データパス方向を逆にする。図４に示されるとおり実行される機能のいずれに関しても、逆の機能が、図５における同一のモジュールおよび／またはエンティティによって実行されることが可能であり、またはそのような逆の機能が、異なるモジュールもしくはエンティティによって実行されることが可能であることに留意されたい。例えば、ｅノードＢ４１０および４２０のＭＡＣマルチプレクサが、ＵＬ信号に関する逆多重化を実行することも可能である。ＤＬとＵＬはともに、参加するＣＣごとに１つのＰＤＣＰエンティティを用いて構成され得る。図５では、データマージャが、ＰＤＣＰ ｅノードＢ間マルチプレクサ４１３のマージャエンティティによってｅノードＢ４１０において実行され得る。或る実施形態において、物理層ＨＡＲＱ ＡＣＫ／ＮＡＣＫが、送信側セルとは独立に扱われることが可能である。

図５で、ＵＥ４０１から送信されるべきデータが、ＰＤＣＰ ＩＷＦデータ分割（図示せず）によって、ＵＥ４０１上に構成されたＲＬＣバッファ４３４ａおよび４３４ｂに供給され、ＭＡＣマルチプレクサ４３５によってＭＡＣ層において多重化され、ＰＨＹ変調−符号化モジュール４３７によって物理層において変調され、符号化され、分割されて、最終的に、ＣＣ４７３を介してｅノードＢ４１０に、およびＣＣ４７４を介してｅノードＢ４２０に送信されることが可能である。この場合も、ｅノードＢ４１０およびｅノードＢ４２０は、ＵＥ４０１からチャネルステータスデータ４１９および４２９（例えば、アップリンクチャネル品質情報）を受信するＭＡＣスケジューラ４１６および４２６をそれぞれ有することが可能である。

受信側（図４のＵＥ４０１、または図５のｅノードＢ）で、データ分割を再マージするデータマージャが実行されることが可能であり、さらに、「ＲＬＣ−順次デリバリ」のために接続が構成される実施形態において、個別のＲＬＣエンティティが部分的にＰＤＣＰデータストリームを受信している可能性があるので、ＲＬＣエンティティの代わりにマージャエンティティが、このタスクを実行することが可能である。データマージャは、Ｉｕ（無線インターフェース）上の様々な伝送パス遅延に起因して順序の乱れたデリバリを格納するのに使用され得るバッファに対するアクセスを有することが可能である。図４で、データマージャが、マージャエンティティ４０７によってＵＥ４０１において実行され得る。ＰＤＣＰ層におけるデータ分割は、ＰＤＣＰに限られた変更を要求して、確立されたシステムアーキテクチャに小さな影響しか与えないことが可能である。また、この構成は、構成変更を最小限に抑え、かつ別々のルート／サイト（例えば、ｅノードＢ、ＲＲＨ、ノードＢなど）からの独立したＰＤＣＰ ＰＤＵデリバリを許すことも可能である。

データ分割を使用しない（またはデータ分割を制限する）実施において、ＨＯ（ハンドオーバ）の前の準備中に、またはＨＯ中に、シームレスなハンドオーバが、データ複製を使用してＲＡＮによって保証されることが可能である。ソースｅノードＢとターゲットｅノードＢとの間のデータルート（データストリームを転送するトンネリング）が、ＵＥがＨＯを命令される前に確立されることが可能である。ＨＯが成功した後、ソースｅノードＢが、ＰＤＣＰ ＳＮ（ＰＤＣＰパケット伝送ステータス）をターゲットｅノードＢに転送して、失われるパケットがないように送信ステータスを同期させることが可能である。

データ分割実施形態において、対応するＨＯ手順は、いくつかの仕方で実行され得る。ＨＯコマンドは、複数のＣＣを扱うように変更され得ることに留意されたい。サービングＣＣおよび／または協調するＣＣの間でハンドオーバが行われる或る実施形態において、従来のハンドオーバに類似するハンドオーバが、実行され得る。ＣＣ協調構成は、協調構造を維持するように更新される必要がある可能性があり、さらに、ハンドオーバ先が、必要とされるサービス品質をサポートすることができない場合、協調構造は、再編成される必要があり得る。シームレスなデータ伝送が、ＰＤＣＰ ＳＮ同期を用いて保証され得る。ハンドオーバが協調するＣＣの間で行われる或る実施形態において、ソースの協調するｅノードＢとターゲットの協調するｅノードＢとの間でトンネリングが確立され得る、従来のハンドオーバ手順のサブセットが、実行されることが可能である。データ転送は、新たなトンネリングプロトコルによって、またはｅノードＢ間の既存のＧＰＲＳトンネリングプロトコルを再使用することによって（或る実施形態では、いくらかの変更を伴って）扱われ得る。さらなる変更が、ハンドオーバ準備情報（例えば、Ｘ２シグナリング）およびハンドオーバコマンド（例えば、無線を介するＲＲＣピアメッセージ）に対して実行されて、サービングＣＣが変わっていないことが示され得る。

Ｘ２インターフェースが、ｅノードＢ間ＲＥＳＯＵＲＣＥ（例えば、セル容量）ＳＴＡＴＵＳ ＲＥＱＵＥＳＴおよびｅノードＢ間ＲＥＳＯＵＲＣＥ ＵＰＤＡＴＥをサポートすることが可能である。セル容量は、ＵＬ／ＤＬのＧＢＲ（保証されたビットレート）／非ＧＢＲ／合計のＰＲＢ（物理リソースブロック）使用量のパーセンテージ、およびＵＬ／ＤＬ Ｓ１ ＴＮＬ（トランスポートネットワーク層）負荷（例えば、低／中／高／過負荷）の点で、またはＲＬＣ送信バッファの中で待っていることが可能なＰＤＣＰ ＰＤＵの数を示し得る新たなＩＥを介して、与えられることが可能である。協調するＣＣ上の利用可能な帯域幅を推定する目的で、このことは、ＰＤＣＰレベルのデータ分割に関して、かつ分割スケジューラアルゴリズムを最適化するのに十分であり得る。

ＣＣ間においてサイト間で協調するデータ分割を確立するために、Ｘ２インターフェースが、いくつかの仕方で扱われることが可能である。初期確立は、部分的ハンドオーバとして扱われることが可能であり、その場合、ハンドオーバ準備情報メッセージが使用され得る。或る実施形態では、この目的で新たなＸ２シグナリングプロトコルを作成することは必要ない可能性がある。或る実施形態では、ソースｅノードＢが、協調的な伝送をサポートするリソース（例えば、ＰＤＣＰ／ＲＬＣ／ＭＡＣ）を割り当てるようターゲットｅノードＢに要求する新たなＸ２シグナリングメッセージが、作成され得る。そのようなメッセージは、何らかの最低限のデータレートおよびＱｏＳをサポートするのに十分な情報を伝送することが可能である。図４および図５に示されるアーキテクチャおよび構成は、ＰＤＣＰ層以外においてデータ分割を実行する実施形態を含め、本明細書で開示される任意の実施形態で使用され得ることに留意されたい。

或る実施形態では、データ分割は、ＲＬＣ層において実行され得る。そのような実施形態において、ＡＭ（確認応答モード）モードベアラが構成され得るが、本明細書で説明される開示は、他のモードのベアラで実施されてもよい。データ分割は、より上位の層から受け取られたデータの単一のストリームをデータの複数のストリームに分割することによって実現され得る。分割されたデータの各ストリームは、本明細書でフローと呼ばれ得る。各フローは、３ＧＰＰ標準文書において現在定義される、ＲＬＣエンティティと同様であり得る。各フローは、シーケンス番号を有するＳＤＵ（サービスデータ単位）としてデバイス（例えば、ｅノードＢ）に入力されることが可能であり、さらにＳＤＵのストリームとしてデバイスから出力されることが可能である。デバイス内で、ＳＤＵは、ＰＤＵ（プロトコルデータ単位）に細分されることが可能であり、さらにピアノード上で再組立てされることが可能である。

送信側エンティティ上で、ＲＬＣ層において実行されるさらなる機能には、データを１つまたは複数のフローに分割することを担うデータ分割エンティティが含まれ得る。送信側の各フローは、ＲＬＣの現行のバージョンと機能的に均等である。データ分割エンティティは、データ分割エンティティがより上位の層から受け取るすべてのＳＤＵが、それらのＳＤＵのいくつかがＣＣ上でｅノードＢに送られる場合でも、バッファリングされることを確実にして、例えば、無線に伝送障害が存在する場合、またはＣＣのうちの１つとＵＥとの間に他の何らかの問題が存在する場合、データが再送され得るようにすることが可能である。

受信側エンティティ上で、フローは、フローエンティティがＳＤＵを並べ替えることを扱わない可能性があることを除いて、現行のＲＬＣ機能と同様である。この機能は、データマージエンティティによって実行され得る。データマージエンティティは、１つまたは複数のフローから入力を受信することが可能であり、さらにＳＤＵをバッファリングし、並べ替えてから、それらのＳＤＵをより上位の層に送ることが可能である。

図６は、ＲＬＣ層においてＵＬデータ分割を実行する方法６００を示す。ブロック６０５で、ＵＥ上のＲＬＣエンティティは、ＰＤＣＰからＳＤＵを受信することが可能である。ブロック６１０で、データ分割が構成されるかどうかについての判定が行われる。データ分割が構成されずに、ブロック６１５で、ＲＬＣが、バッファ情報でＭＡＣ層を更新し、さらにＭＡＣからのデータ要求を待つことが可能である。データ分割が構成される場合、ブロック６２０で、データは、ＵＥ上に存在するデータ分割エンティティに供給され得る。ブロック６２５で、データ分割エンティティが、そのデータを複数のフローに分割することが可能である（ただし、各フローはそれ自体、ＲＬＣ ＡＭエンティティのように振舞うことが可能である）。データがどのように分割されるべきかの決定は、ＭＡＣからの入力に基づく各ＣＣ上で利用可能な帯域幅、および各フロー上の現在のバッファステータスを含め、複数の要因に基づくことが可能である。データが、各ＣＣに関するフローに分割されると、ブロック６３０で、ＭＡＣに関するバッファ占有率情報が更新されることが可能であり、さらにＭＡＣエンティティが、無線で送信するためのデータのスケジューリングを決定することが可能である。ＭＡＣスケジューラが、複数のフローの概念に対処するように変更され得る。

ブロック６３５で、ＭＡＣスケジューラエンティティが、各フローからデータを選択し、さらに、選択されたデータを、Ｉｕ（無線インターフェース）を介して宛先ｅノードＢに送信するためにＰＨＹに転送することが可能である。ｅノードＢにおいて各フロー上でデータを受信すると、ブロック６４０で、適切な制御メッセージが、そのデータに確認応答するために、または再送を要求するために、同一のフロー上でＵＥとｅノードＢとの間で交換される。ＰＤＵが組み立てられてＳＤＵにされると、すべてのフローは、所与のＵＥに関するＥＰＣ（拡張パケットコアネットワーク）に対する接続を有する一次ｅノードＢに送信され得ることに留意されたい。これらのフローは独立に振舞うので、任意のＲＬＣ制御情報（再送要求、リセットなど）が、所与のフローを扱っている適切なエンティティによって扱われることが可能である。正しいエンティティが制御情報を扱っているため、再送要求を扱う際の待ち時間が短縮され得る。

他のＲＬＣエンティティからのフローを受け取る一次ｅノードＢ上のＲＬＣエンティティが、データをマージ機能またはマージエンティティに供給する。マージエンティティは、受け取られたデータをマージすること、およびそのデータが、ＰＤＣＰに供給される前に、順序どおりになっていることを確実にすることを担う。

図７は、ＲＬＣ層データ分割が実行される或る実施形態に従って使用され得る例示的なデータフローおよびアーキテクチャを示す。ＵＥ７３０が、ＰＤＣＰ層７３９においてデータを受け取り、そのデータをＲＬＣ層７３７に供給することが可能である。ＲＬＣ層７３７で、データ分割エンティティ７３６が、データを、ＭＡＣ７３５に供給されるフロー７３１と７３２に分割する。データ分割エンティティ７３６は、データを別々のフローに分割すると、ＲＬＣ ＳＤＵを追跡することが可能である。ＭＡＣ７３５が、異なるＣＣを介してデータの別々の部分を（フロー７３１および７３２として）ｅノードＢ７１０およびｅノードＢ７２０に送信することが可能なＰＨＹ７３４に供給することが可能である。

ｅノードＢ７２０が、ＰＨＹ７２４でデータを受信して、そのデータをＭＡＣ７２５に供給することが可能であり、ＭＡＣ７２５は、フロー７３２のデータをＲＬＣ７２７に供給する。次に、ＲＬＣ７２７が、フローデータを、トンネル７４０を介してｅノードＢ７１０に供給することが可能である。ｅノードＢ７１０で、データフロー７３１が、ＰＨＹ７１４において受信されることが可能であり、ＰＨＹ７１４は、データフロー７３１をＭＡＣ７１５に供給することが可能であり、ＭＡＣ７１５は、フロー７３１のデータをＲＬＣ７１７に供給する。次に、ＲＬＣ７１７のデータマージエンティティ７１８が、そのデータフローをマージして、適切に順序付けられたＳＤＵにして、さらに、もたらされたデータをＰＤＣＰ７１９に供給することが可能であり、ＰＤＣＰ７１９は、そのデータをＩＰパケットとしてネットワークに送信することが可能である。データマージエンティティ７１８が、ＲＬＣ ＳＤＵを追跡することが可能である。Ｘ２シグナリング７５０が、ｅノードＢ７１０とｅノードＢ７２０との間で制御情報を交換するのに使用され得る。

図８は、ＲＬＣ層においてＤＬデータ分割を実行する方法８００を示す。ブロック８０５で、所与のＵＥに関するＥＰＣとのコンテキストを有するｅノードＢエンティティ上のＲＬＣエンティティが、そのＵＥを宛先とするデータを受信する。ＣＣが全く関与しない通常のモードにおいて、このことは、そのチャネルに関する合計バッファ占有率の変化をもたらし得る。ブロック８１０で、ｅノードＢ上のＲＬＣエンティティが、データ分割が構成されるかどうかを決定することが可能である。構成される場合、ブロック８２０で、ＲＬＣエンティティが、データ分割エンティティを調べて、そのＳＤＵがピアｅノードＢに送信されるべきか、またはそのＳＤＵがローカル送信に利用可能であるかを判定することが可能である。データ分割が構成されない場合、受け取られたデータを処理することが、ブロック８１５で通常どおりに進められることが可能である。

ブロック８２０で、データ分割エンティティが、ピアエンティティにおいて利用可能な帯域幅、ピアエンティティの現在のバッファステータスなどを含み得る様々な要因に基づいて、そのデータがピアＲＬＣに送られるべきか否かを判定することが可能である。Ｘ２インターフェース上の瞬間的なバッファステータスが利用できない可能性があるので、データ分割を決定するアルゴリズムは、想定されるデータレート、または前回に報告された測定、および前回に報告された測定以来の時間に基づく予測に基づいて、分割を決定することが可能である。

データがローカルフロー上で（すなわち、ｅノードＢから宛先ＵＥに直接に）送られるべき場合、バッファ占有率情報は、ブロック８２５で更新されるようにＭＡＣに供給されることが可能であり、さらにブロック８３０で、ＲＬＣは、データが要求されると、ＭＡＣ層にデータを送信することが可能である。データは、ブロック８３５でＵＥに送信され得る。

データが異なるｅノードＢに送られるべき場合、データは、ブロック８４０で、ｅノードＢ−ｅノードＢトンネルを介してピアｅノードＢに送られることが可能である。ピアｅノードＢ上の受信側ＲＬＣは、上位の層からデータを受け取ったとした場合と同様に振舞うことが可能である。違いは、ＲＬＣ伝送ステータスフィードバック（例えば、ＲＬＣバッファステータス、およびＳＤＵについての情報は送信されない）が、協調するＲＬＣエンティティによってソースｅノードＢ上のＲＬＣデータ分割エンティティに転送されることである。このことは、データ分割エンティティが、障害の生じたパケットを別の利用可能なＣＣを介して送信すること、およびシームレスなハンドオーバのために最新のバッファステータスを維持することを可能にすることができる。

各ＣＣ上のＲＬＣエンティティは、そのＲＬＣエンティティがＭＡＣ層に供給するバッファ占有率情報を更新することが可能である。ＭＡＣエンティティは、データ利用可能性、および帯域幅利用可能性に基づいてデータ伝送をスケジュールすることが可能である。ＵＥ側で、ＭＡＣからデータを受信すると、再組立て機能が、各フローに関して独立に、現行のＲＬＣ標準のとおりに実行されることが可能である。送信されなければならないＲＬＣ制御情報が存在する場合、ＵＥ側のＭＡＣが、そのデータが送信されるべきフローについて通知を受けることが可能である。ＳＤＵが形成されると、ＳＤＵは、ＳＤＵを並べ替えることを担う（データマージ機能がそのように構成されている場合）データマージ機能に供給される。ＳＤＵは、ＲＬＣからＰＤＣＰ層に送り出される前に順序付けられていることが可能である。並べ替えることは、ＳＤＵに追加されたシーケンス番号に基づいて、またはＰＤＣＰによって供給されるシーケンス番号に基づいて、行われ得る。

図９は、ＲＬＣ層データ分割が実行される或る実施形態に従って使用され得る例示的なデータフローおよびアーキテクチャを示す。ｅノードＢ９１０が、ＰＤＣＰ層９１９においてＩＰパケット９９０を受信して、そのデータをＲＬＣ層９１７に供給することが可能である。ＲＬＣ層９１７で、データ分割エンティティ９１８が、そのデータをフロー９３１と９３２に分割することが可能である。データ分割エンティティ９１８は、フロー９３２がピアｅノードＢに送信されるべきであるのに対して、フロー９３１がローカルで（すなわち、ＵＥ９３０に直接に）送信されるべきことを判定することが可能である。データ分割エンティティ９１８は、フロー９３１をＭＡＣ９１５に供給することが可能である（例えば、バッファ占有率情報を更新した後、要求が行われると）。データ分割エンティティ９１８は、データ分割エンティティ９１８がデータを別々のフローに分割すると、ＲＬＣ ＳＤＵを追跡することが可能である。ＭＡＣ９１５は、フロー９３１に関するデータをＰＨＹ９１４に供給することが可能であり、ＰＨＹ９１４は、フロー９３１を、第１のＣＣを介してＵＥ９３０に送信することが可能である。

ｅノードＢフロー９１０が、フロー９３２を、トンネル９４０を介してｅノードＢ９２０に供給することが可能である。ＲＬＣ層９２７が、フロー９３２をＭＡＣ９２５に供給することが可能である（例えば、バッファ占有率情報を更新した後、要求が行われると）。ＭＡＣ９２５は、フロー９３２に関するデータをＰＨＹ９２４に供給することが可能であり、ＰＨＹ９２４は、フロー９３２を、第２のＣＣを介してＵＥ９３０に送信することが可能である。Ｘ２シグナリング９５０が、ｅノードＢ９１０とｅノードＢ９２０との間で制御情報を交換するのに使用され得る。

ＵＥ９３０で、データフロー９３１および９３２が、データフロー９３１および９３２をＭＡＣ９３５に供給することが可能なＰＨＹ９３４によって受け取られることが可能であり、ＭＡＣ９３５は、フロー９３１および９３２のデータをＲＬＣ９３７に供給する。次に、ＲＬＣ９３７のデータマージエンティティ９３６が、それらのデータフローをマージして、適切に順序付けられたＳＤＵにし、さらに、もたらされるデータをＰＤＣＰ９３９に供給し、ＰＤＣＰ９３９は、そのデータをＩＰパケットとしてネットワークに送信することが可能である。データマージエンティティ９３８は、ＲＬＣ ＳＤＵを追跡することが可能である。

ＲＬＣ層データ分割実施形態に関して、ハンドオーバ動作は、ＰＤＣＰ層データ分割に関して開示された手段を含め、本明細書で開示される任意の手段または方法を使用して実行され得る。

或る実施形態において、データ分割が、ＭＡＣ層において実行され得る。送信バッファリングを提供することが可能な、協調するｅノードＢ上に構成されたＭＡＣ ＩＷＦにＲＬＣパケット（例えば、ＰＤＵ）を転送するＭＡＣ ＩＷＦが、ソースｅノードＢ上に構成され得る。ＭＡＣ層データ分割は、本明細書で説明されるとおり、ＨＳＰＡ（高速パケットアクセス）構成、ならびにＬＴＥ構成およびＬＴＥ−Ａ構成に適用されることが可能であることに留意されたい。ＨＳＰＡ構成において、ＬＴＥ−ＡにおけるサービングｅノードＢは、ＨＳＰＡにおけるサービングＲＮＣ（無線ネットワークコントローラ）と均等であることが可能であり、さらにＬＴＥ−Ａにおける協調するｅノードＢは、ＨＳＰＡにおけるノードＢまたはＲＮＣと均等であることが可能である。

図１０は、ＭＡＣ層データ分割が実行される或る実施形態に従って使用され得る例示的なＤＬデータフローおよびアーキテクチャを示す。ｅノードＢ１０１０は、ＰＤＣＰ符号化を実行し、さらにＲＬＣバッファ層１０１７ａおよび１０１７ｂにデータを供給することが可能なＰＤＣＰ１０１９ａおよび１０１９ｂにおいて、ＩＰパケット１０９０を受け取ることが可能である。ＲＬＣバッファ１０１７ａおよび１０１７ｂは、ＭＡＣ１０１５にデータを供給することが可能であり、ＭＡＣ１０１５は、適切なデータ分割を決定することが可能であり、かつデータを少なくとも２つの部分に分割する多重化エンティティ１０１９を含み得る。多重化エンティティ１０１９は、ピアｅノードＢに関する利用可能な帯域幅を考慮に入れることが可能であり、かつデータ多重化を実行する際にＲＬＣ ＰＤＵを転送することが可能である。ピアｅノードＢを使用して送られるように決定されたデータは、転送するエンティティ１０１８によって、ｅノードＢ間トンネル１０４０を介してｅノードＢ１０２０に供給されることが可能である。ローカルで（すなわち、ｅノードＢ１０１０からＵＥ１０３０に直接に）送信されるように決定されたデータは、任意のＨＡＲＱ（ハイブリッドＡＲＱ）機能を実行することが可能であり、かつ第１のＣＣを使用してＵＥ１０３０に送信する（１０６１）ためにＰＨＹ１０１４にデータを転送することが可能なＨＡＲＱ１０１６に供給されることが可能である。

ｅノードＢ１０２０は、ＵＥ１０３０のためのデータを、ｅノードＢ間トンネル１０４０を介してｅノードＢ１０１０から受信すると、ｅノードＢ間バッファ１０２８においてそのようなデータをバッファリングすることが可能である。バッファ１０２８は、多重化エンティティ１０２９による多重化、およびＨＡＲＱエンティティ１０２６によって実行されるＨＡＲＱ機能のために、ＭＡＣ１０２５にデータを供給することが可能である。このデータは、第２のＣＣを使用してＵＥ１０３０に送信される（１０６２）ようにＰＨＹ１０２４に供給されることが可能である。

サービングｅノードＢ１０１０上のＭＡＣスケジューラ１０１２が、協調するｅノードＢ１０２０からの報告された（例えば、推定された、または所定の保証される、もしくは平均の伝送などの）サポーティングデータレートを、ペイロード選択アルゴリズムにおける基準として使用して、ＲＬＣ ＰＤＵが送信のために協調するサイト間ＣＣに転送されることを要求することが可能である。

協調するｅノードＢ１０２０におけるＭＡＣスケジューラ１０２２が、ｅノードＢ１０２０上でサポートされ得る（例えば、推定された、所定の、または計算された保証される、もしくは平均の伝送などの）データレートを、定期的にサービングｅノードＢ１０１０に報告して、その２つのｅノードＢ間に接続が存在する間にサポートレートを更新することが可能である。この制御情報、および他の制御情報が、Ｘ２シグナリングインターフェース１０５０を介してｅノードＢ間で交換され得る。或る実施形態において、セル無線リソースステータスごとのＸ２インターフェースは要求され得るが、ＤＬ／ＵＬのＧＢＲ／非ＧＢＲ／合計ＰＲＢを提供する無線リソースステータスの更新は、オプションであり得る。また、ＰＲＢステータスは、そのような情報が利用可能である場合、スケジューリング入力の代替として使用されることも可能である。

また、協調するｅノードＢ１０２０におけるＭＡＣスケジューラ１０２２が、協調するＣＣのための標準のペイロード選択を、ｅノードＢ間バッファ１０２８において利用可能なＲＬＣ ＰＤＵバッファを使用して固定サイズのＰＤＵとして実行すること、または利用可能な無線リソースに合わせて多重化１０２９によってサイズ変更することも可能である。ＲＬＣ ＰＤＵサイズ選択は、報告されたサポーティングデータレート、または保証されたレートに対処するようにサービングｅノードＢ ＭＡＣスケジューラ１０１２によって実行され得る。

ｅノードＢ１０１０上のＭＡＣ ｅノードＢ間データ転送エンティティ１０１８は、処理のためにＰＨＹに、および／またはトンネル１０４０を介してｅノードＢ１０２０に、ＭＡＣデータを送ることが可能な受動的中継ユニットであり得る。

協調するｅノードＢ１０２０におけるＭＡＣ ｅノードＢ間バッファ１０２８は、Ｘ２インターフェース上のデータトンネリングに起因することがあり得る可変の待ち時間に対処する、協調するｅノードＢ１０２０上の一時的「パーキング」エリアの役割をすることが可能である。

サイト間トンネル１０４０は、サービングｅノードＢ１０１０から協調するｅノードＢ１０２０にＲＬＣ ＰＤＵを転送するデータパイプであり得る。協調するｅノードＢごとに１つのトンネルが存在し得る。

図１０、およびＭＡＣ層データ分割に関連して本明細書で説明される構成およびデータフローは、システムアーキテクチャに小さい影響しか与えずに、ＭＡＣ層に限定された変更だけで実施され得る。そのような変更は、最小限であることが可能であり、さらに、ＣｏＭＰ（Coordinated Multipoint Transmission：調整されたマルチポイント伝送）手順をサポートするのに要求される変更と同一である、または小さな違いしか有さないことが可能な構成変更であることが可能である。或る実施形態では、ＣｏＭＰ手順のいくつかは、いくらかの変更を加えて再利用されることが可能である。或る実施形態では、参加サイトに関する無線インターフェースリソース予約が、Ｘ２インターフェース遅延を低減するのに使用され得る。ＲＬＣ ＳＤＵまたは順次のデリバリは、すべての関係のあるＲＬＣ ＰＤＵが正しく受信されてからでないと、ＲＬＣがＲＬＣ ＰＤＵを上位の層に送ることができないことを要求することが可能である。ＲＬＣ ＰＤＵは、それぞれが他方とは異なる待ち時間を有し得る、異なる２つの物理層インターフェースを介して送信され得ることに留意されたい。したがって、受信側ＲＬＣエンティティが、さらなる入力データをバッファリングする要件が存在し得る。協調するＣＣは、上位層再送タイマ限度内でＲＬＣ ＰＤＵを送信する必要がある可能性がある。

図１０に関して説明されたのと同一のデバイスおよびエンティティを使用する、対応するＵＬ ＭＡＣ層データ分割のデータフローおよびアーキテクチャが、図１１に示される。図１１に示される機能は、既存のＬＴＥシグナリング構造および／またはＬＴＥ−Ａシグナリング構造とほとんど、または完全に適合することが可能であるが、複数のＣＣに関する構成の拡張、およびネットワークからの対応するスケジューリングを含むことも可能である。正常に受信されたＭＡＣ ＰＤＵを、サービングｅノードＢ上のＲＬＣに転送する、対応するネットワーク要件は、ＣｏＭＰ手順を導入するのに必要とされるものと同一であり得る。

図１１で、データが、ＵＥ１０３０上のＲＬＣバッファ１０３７ａおよび１０３７ｂにおいて受信されることが可能であり、かつデータ分割を決定して、別々のＣＣ１０６３および１０６４上でｅノードＢ１０１０および１０２０にそれぞれ送信するためにＰＨＹ１０３４にデータを供給することが可能なＭＡＣ多重化エンティティ１０３９に供給されることが可能である。優先度処理データが、ＭＡＣ多重化エンティティ１０３９によって使用され得る。そのようなデータは、優先度処理エンティティ１０３２とＭＡＣスケジューラ１０１２および１０２２との間で交換され得る。ＵＥ１０３０からデータを直接に受信すると、ｅノードＢ１０１０のＰＨＹ１０１４は、そのデータをＭＡＣ１０１５に供給することが可能であり、ＭＡＣ１０１５は、ＨＡＲＱ機能を実行し、かつデータを多重化エンティティ１０１９に供給することが可能である。多重化エンティティ１０１９は、そのデータと、トンネル１０４０を介してｅノードＢ１０２０から受信されたデータを逆多重化することが可能である。ＵＥ１０３０からデータを直接に受信すると、ｅノードＢ１０２０のＰＨＹ１０２４は、データをＭＡＣ１０２５に供給することが可能であり、ＭＡＣ１０２５は、ＨＡＲＱ機能を実行し、かつデータを多重化エンティティ１０２９に供給することが可能であり、多重化エンティティ１０２９は、そのデータを逆多重化して、そのデータを、トンネル１０４０を介してｅノードＢ１０１０に供給することが可能である。逆多重化の後、データは、ＲＬＣバッファ１０１７ａおよび１０１７ｂ、ＰＤＣＰ復号器１０１９ａおよび１０１９ｂに供給されることが可能であり、さらにその後、ＩＰパケット１０９１としてネットワークに送信されることが可能である。バッファステータス１０７３および１０７４が、ＵＥ１０３０によってＭＡＣスケジューラ１０１２および１０２２にそれぞれ供給されることが可能である。

ＭＡＣ層データ分割実施形態において、ＬＴＥ Ｒ８によってサポートされる基本的なハンドオーバフィーチャが、協調構造を再編成すること、および／または保持することをサポートする構成、およびＸ２シグナリングインターフェース上の部分的ハンドオーバのサポートの追加で、本明細書で説明されるハンドオーバをサポートすることが可能である。サービングＣＣ、または協調するＣＣの部分的ハンドオーバは、ｅノードＢ間のさらなるデータパスの確立を使用することが可能である。パス確立中、またはパス再確立中に失われたＭＡＣパケットは、ＲＬＣレベルの再送（ＲＬＣは常にサービングＣＣ上にあり、移動していない可能性があるので、協調するＣＣハンドオーバに関して）、またはＰＤＣＰ再送（ＰＤＣＰ送信ステータスはターゲットセルに転送されるので、サービングハンドオーバに関して）で自律的に処理され得るので、データコピーの必要は全くない可能性がある。Ｘ２ハンドオーバシグナルインターフェースが、ＲＲＣ層によって定義されたハンドオーバ準備情報をカプセル化することが可能である。したがって、部分的ハンドオーバを通信することのシグナリング問題は、ハンドオーバ準備情報の中で協調構造のコンテキストを供給するようにＲＲＣハンドオーバメッセージを変更することで、対処され得る。

或る実施形態では、ユーザプレーンデータ分割が、例示的なシステムにおいて実施されることが可能である。ＰＤＣＰ層、ＲＬＣ層、ＭＡＣ層、またはサービングゲートウェイデータ分割において、または上記、および／もしくは本明細書で開示される他の任意の手段のうちの任意の手段の任意の組合せを使用するシステムにおいて、効率的なデータ分割決定のために、サービングｅノードＢが、利用可能なリソース、および遠隔のｅノードＢからのローカルスケジューリング情報を考慮に入れる必要がある可能性がある。ＲＡＮデータ分割実施形態において、専用の「インターワーキング機能」が、Ｘ２リンクによってもたらされる遅延を軽減するようにダウンリンクフレームをバッファリングするのに使用され得る。サービングｅノードＢは、Ｘ２遅延を考慮に入れることが可能であり、ＲＡＮデータ分割の代わりにＳ−ＧＷ（サービングゲートウェイ）データ分割を開始することによって、Ｘ２待ち時間を低減することが可能である。データ分割が使用されるべきことを決定すると、サービングｅノードＢは、データを分割することを始めるようサービングゲートウェイに命令する制御信号を、サービングゲートウェイに送信することが可能である。

或る実施形態では、Ｘ２インターフェース上のユーザプレーン負荷が、サービングゲートウェイにおいてデータ分割が行われることを許すフレームワークを構築すること、およびキャリア固有のハンドオーバを許すようにＬＴＥ Ｒ８ハンドオーバを拡張することによって、低減され得る。そのような実施形態を実施するために、サービングｅノードＢが、サービングゲートウェイにキャリア固有のハンドオーバ決定を通知することを許し、さらにサービングゲートウェイが、ＵＥトラフィックをキャリア固有の仕方で分割することを可能にするメッセージシーケンスが、使用され得る。キャリア固有のハンドオーバを実施する実施形態において、ｅノードＢ−ＭＭＥメッセージングは、影響を受けるＲＡＢ（無線アクセスベアラ）のリストのハンドオーバの通知をサポートし、かつＭＭＥがキャリア固有のＰＡＴＨ＿ＳＷＩＴＣＨ＿ＲＥＱＵＥＳＴメッセージをサポートすることを要求するように、拡張され得る。

例えば、ＵＥ３５０が位置３１１にある場合に２つのｅノードＢに接続され得る、図３に示される或る実施形態では、適切なＲＲＣシグナリングが、分割されたＲＲＣ接続をサポートするのに必要とされ得る。一部の実施形態では、ＵＥに関して活性状態への遷移が完了すると、またはターゲットｅノードＢにおいて、ハンドオーバ準備中にハンドオーバリソース割当てが完了した後、ｅノードＢ ＵＥコンテキストが確立されることが可能である。ｅノードＢ ＵＥコンテキストは、１つの活性のＵＥに関連するｅノードＢにおける情報のブロックであり得る。この情報のブロックは、活性のＵＥに向けたＥ−ＵＴＲＡＮサービスを維持するのに要求される必要な情報を含み得る。ＵＥ状態情報、セキュリティ情報、ＵＥ能力情報、およびＵＥに関連する論理Ｓ１接続のＩＤが、ｅノードＢ ＵＥコンテキストの中に含められることが可能である。

或る実施形態では、ユーザプレーンデータ分割が、図１２に示されるサービングゲートウェイにおいて実行され得る。ＩＰパケット４０５が、ＰＤＮ（パケットデータネットワーク）ゲートウェイ１２１０において受信され、かつサービングゲートウェイ１２２０に送信されることが可能である。サービングゲートウェイ１２２０が、そのデータを分割し、さらにそのデータの一部分を、Ｓ１ベアラ１２５１を介してｅノードＢ１２３０に送信し、さらにそのデータのその他の部分を、Ｓ１ベアラ１２５２を介してｅノードＢ１２４０に送信することが可能である。次に、ｅノードＢ１２３０および１２４０が、そのデータを、無線ベアラを介してＵＥ１２７０に送信することが可能である。確認応答されていないＰＤＣＰ ＳＤＵ１２６１および１２６２が、ｅノードＢ間で転送されて、ロスレス（lossless）ハンドオーバを許すことが可能である。サービングゲートウェイにおける個々のＣＣに関連するベアラのデータ分割が、ｅノードＢからの入力、および／またはサービングゲートウェイ上で実行される負荷分散アルゴリズムに基づいて可能にされ得る。単一のコンポーネントキャリアが、ＨＡＲＱエンティティに関連することが可能である。複数の論理チャネルが、異なるコンポーネントキャリアにトランスペアレントにマップされることが可能である。

ＣＣが１つのｅノードＢ（ソース）から別のｅノードＢ（ターゲット）にハンドオーバされる際、ソースｅノードＢは、サービングゲートウェイに関連するＭＭＥに（直接に、またはターゲットｅノードＢを介して）、コンポーネントキャリア上で伝送されていた無線ベアラを通知することが可能である。このことは、ソースｅノードＢから、サービングゲートウェイに関連するＭＭＥに送信されるべきメッセージを作成することによって、またはパススイッチ要求メッセージを拡張することによって、達成することが可能である。

新たなＧＴＰ（ＧＰＲＳトンネリングプロトコル）トンネルエンドポイントに向けてのダウンリンクＧＴＰの切換えを要求するパス切換えメッセージが、ｅノードＢとＭＭＥとの間で交換されることが可能である。パス切換えメッセージは、ソースｅノードＢからターゲットｅノードＢに切り換えられる必要があるすべてのＥ−ＲＡＢ（ＥＵＴＲＡＮ ＲＡＢ）のリストであることが可能なダウンリンクリストＩＥ（情報要素）の中の切り換えられるべきＥ−ＲＡＢを伝送することが可能である。ＰＡＴＨ ＳＷＩＣＨ ＲＥＱＵＥＳＴメッセージ内のダウンリンクリストＩＥの中で切り換えられるべきＥ−ＲＡＢが、ＵＥコンテキストの中にそれまでに含まれていたすべてのＥ−ＲＡＢを含まない可能性がある場合、ＭＭＥは、含まれていないＥ−ＲＡＢを、ｅノードＢによって暗黙に解放されたものと考えることが可能である。

キャリア固有のハンドオーバをサポートするのに、パススイッチ要求（または代替のメッセージ）が、切り換えられる必要があるＲＡＢのリストを伝送することが可能である。しかし、ＭＭＥおよびサービングゲートウェイは、残りのトラフィックを、それまでと同様にソースｅノードＢに転送することを続けることが可能である。

ｅノードＢは、Ｓ−ＧＷ（サービングゲートウェイ）におけるデータの分割をどのように要求するかを決定することが可能である。或る実施形態では、ｅノードＢは、ＲＡＢレベルにおけるデータ分割を要求することが可能であり、その場合、パス切換えメッセージは、分割される必要があるすべてのＲＡＢのリストを含み得る。ｅノードＢがＲＡＢレベルでデータを分割することを望まない場合、ｅノードＢは、新たなｅノードＢにリダイレクトされるべきトラフィックのパーセンテージを有するインジケータを送ることが可能である。或る実施形態では、「保つべきＲＡＢ」リストが、より古い機器との潜在的な適合性問題または解釈問題を回避するのに使用され得る。また、サービングｅノードＢは、ルーティングアルゴリズムを実施して、ＭＭＥが利用できない可能性があるＡＳ情報に基づいて、最適なＲＡＢ／ＲＢマッピングを決定することも可能である。ＭＭＥ／Ｓ−ＧＷが、ｅノードＢによって示唆されるとおりのデータ分割ルーティング、または代替のデータ分割ルーティングを採用することを決定する場合に、ルーティング示唆をもたらすオプションのＩＥが、「ＰＡＴＨ ＳＷＩＴＣＨ ＲＥＱＵＥＳＴ」の中に含められてもよい。データ分割ルーティングを決める決定に対するいくつかの潜在的な能動的な入力には、ＲＢ／ＲＡＢ分割割当て（特定のｅノードＢ ＭＡＣアドレスに対するＲＡＢ／ＲＢのマッピング）、データ分割のパーセンテージ、およびその他の入力が含まれ得る。

無線ベアラからの部分的データが、コンポーネントキャリア上で送られることが可能であり、さらにこのことが、サービングゲートウェイに、同様の構成をミラーリングするようにトラフィックを分割するオプションを許す特別なインジケータによって示されることが可能である。この特別なインジケータは、１回限りのイベントであること、またはチャネル品質測定に基づいて分割比を変更する、サービングｅノードＢからＳ−ＧＷ／ＭＭＥへの定期的通知であることが可能である。

ＭＭＥ／Ｓ−ＧＷが、ｅノードＢによって与えられるステータス入力に基づいてデータフロー分割決定を行うのに使用される何らかのルーティングインテリジェンスを実施することが可能である。そのような入力には、利用可能なｅノードＢ（例えば、ＰＤＣＰ）バッファ、平均伝送待ち時間（例えば、ＵＥ上の、または特定のＲＡＢ／ＲＢごとの）、サポート可能なトラフィック負荷分散（例えば、ｅノードＢごとの％負荷）、およびその他が含まれ得る。

Ｓ−ＧＷから送られるパケットは、ＧＴＰトンネルにおいてカプセル化されたＩＰトラフィックであることが可能であり、さらに、単一のＥ−ＲＡＢ ＩＤに関して、１つはソースｅノードＢに終端し、もう１つはターゲットｅノードＢに終端する２つのＧＴＰトンネルの作成を要求することが可能であることに留意されたい。このことは、無線ベアラマッピングに１対１ＲＡＢを規定する一部の実施とは異なり得る。

或る実施形態では、ＵＥは、セキュリティ情報およびＮＡＳ情報を提供する１つの特別なセルを有するネットワークに対する１つのＲＲＣ接続を有することが可能である。図３を再び参照すると、起動時に、位置３１１にあるＵＥ３５０が、ｅノードＢ３６１に対するＲＲＣ接続、ならびにＣＣ３２０およびＣＣ３３０Ｂという確立されたコンポーネントキャリアセットに関連する。このため、ＵＥ３５０は、ｅノードＢ３６１におけるサービングセル（または特別なセル）に関連することが可能であり、かつサービングセルハンドオーバが行われるまで、ｅノードＢ３６１からセキュリティ情報およびＮＡＳ移動性情報を獲得することが可能である。

ＣＣ３３０がサービングセルである協調的なコンポーネントキャリア展開において移動性をサポートするために、ＵＥ３５０が位置３１１に移動することが、ＲＲＣ接続再構成を使用してシグナリングされるＲＲＣ接続ハンドオーバを生じさせることが可能であり、かつ新たなセキュリティパラメータを考慮に入れるようにＭＡＣ／ＲＬＣ層のリセットを生じさせることが可能である。ＣＣ３３０がサービングセルではない或る実施形態において、ＵＥ３５０は、ＵＥ３５０が位置３１０から位置３１１に移動する際に、ｅノードＢ３６１に対するＵＥ３５０のＲＲＣ接続を維持することが可能である。セキュリティ手順は、後段で説明されるとおり、ハンドオーバのためのさらなる機構を必要とする可能性がある。

ＵＥに関する活性状態への遷移が完了すると、またはターゲットｅノードＢにおいてハンドオーバ準備中のハンドオーバリソース割当ての完了の後、ｅノードＢ ＵＥコンテキストが確立され得る。或る実施形態では、ハンドオーバ手順は、ソースｅノードＢから送られた｛Ｋ_eＮＢ＊，ＮＣＣ｝ペアから導き出された、暗号化および暗号化アルゴリズムのための新規の鍵を生成するよう、ターゲットｅノードＢおよびＵＥをトリガすることが可能である。ターゲットｅノードＢは、このタプルを使用して新規のＫ_ｅＮＢを生成することが可能である。Ｋ_{ＵＰｅｎｃ}鍵（Ｋ_ｅＮＢから導き出された）が、特定の暗号化アルゴリズムを用いたユーザプレーントラフィックの保護のために使用され得る。

図３のＵＥ３５０が、例えば、位置３１０から位置３１１に移動するに際に、ソースｅノードＢ３６１とのＲＲＣ接続を維持する或る実施形態において、ターゲットｅノードＢ３６２において実行されているＰＤＣＰエンティティは、ソースｅノードＢ３６１と同一の鍵を使用し続ける必要がある可能性がある。このことは、ＵＥが、異なる複数のｅノードＢからＰＤＣＰエンティティを同時に受信することを許す可能性がある。これらの鍵は、ソースｅノードＢからターゲットｅノードＢへのハンドオーバのハンドオーバ準備段階におけるハンドオーバコマンドで交換されることが可能である。或る実施形態では、この情報は、Ｓ−ＧＷからの初期コンテキストセットアップ中に伝えられることが可能である。

或る実施形態では、電力ヘッドルーム、バッファステータスレポート、およびチャネル品質レポートを含むアップリンクレポートが、ターゲットｅノードＢにおいて利用できる可能性があり、さらにＸ２−ＡＰを介してソースｅノードＢからターゲットｅノードＢに転送されることが可能であり、またはＵＥが、それらのレポートを２つのｅノードＢに別々に送ることが可能である。後方互換性をもたらすために、ＵＥは、サービングセルに関するレポートを「サービングｅノードＢ」に送ることが可能である。しかし、このことは、ターゲットｅノードＢにおけるスケジューラに関する入力の利用可能性に遅延を生じさせる可能性があり、このことは、一部の実施で、最適でないスケジューリング決定をもたらし得る。

キャリア集約を用いるＬＴＥ−Ａにおいてハンドオーバを適切にサポートするために、キャリア固有のＲＳＲＰおよび／またはＲＳＲＱを含め、キャリアごとのＵＥ測定、および集約されたダウンリンクキャリアを介する報告が定義される必要がある可能性がある。ＬＴＥ Ｒ８機構は、測定がサービングセルに基づくことが可能であるため、周波数内測定をサポートしない可能性がある。例えば、ｅノードＢが、３つのキャリアＦ１、Ｆ２、およびＦ３を所有することが可能であり、さらにＦ１およびＦ２を使用していることが可能であり、さらにＦ１がサービングセルであることが可能である。Ｆ３の信号品質がＦ２より良好である場合、ＵＥがこの状況を報告することができるように、この状況を扱う測定スキームを有することが望ましい可能性がある。一部の実施において、非サービングセルからの測定を含む、キャリア固有の測定が、所望される可能性がある。

特徴および要素は、特定の組合せによって上記で説明されるものの、各特徴または各要素は、単独で使用されることも、その他の特徴および要素との任意の組合せで使用されることも可能であることが、当業者には認識されよう。さらに、本明細書で説明される方法は、コンピュータまたはプロセッサによって実行されるようにコンピュータ可読媒体に組み込まれたコンピュータプログラム、ソフトウェア、またはファームウェアにおいて実施され得る。コンピュータ可読媒体の例には、電子信号（有線接続またはワイヤレス接続を介して伝送される）およびコンピュータ可読記憶媒体が含まれる。コンピュータ可読記憶媒体の例には、ＲＯＭ（読み取り専用メモリ）、ＲＡＭ（ランダムアクセスメモリ）、レジスタ、キャッシュメモリ、半導体メモリデバイス、内部ハードディスクやリムーバブルディスクなどの磁気媒体、光磁気媒体、ならびにＣＤ−ＲＯＭディスクおよびＤＶＤ（デジタルバーサタイルディスク）などの光媒体が含まれるが、これらに限定されない。ソフトウェアに関連するプロセッサが、ＷＴＲＵ、ＵＥ、端末装置、基地局、ＲＮＣ、または任意のホストコンピュータにおいて使用するための無線周波数トランシーバを実施するのに使用され得る。

Claims (20)

1. データを送信するための方法であって、
   第１の基地局において、データを備えるＩＰ（インターネットプロトコル）パケットを受信するステップであって、前記ＩＰパケットは、第１のＷＴＲＵ（ワイヤレス送信／受信ユニット）に関連する受信するステップと、
   前記第１の基地局において、前記データの一部分が、前記ＷＴＲＵに送信されるように少なくとも１つの協調するネットワーク要素に送信されるべきことを決定するステップと、
   前記第１の基地局から、前記データの前記一部分を前記少なくとも１つの協調するネットワーク要素に送信するステップと、
   前記第１の基地局から、前記データの残りの部分を前記ＷＴＲＵに送信するステップと
   を備えることを特徴とする方法。
2. 前記少なくとも１つの協調するネットワーク要素に送信されるべき前記データの前記一部分を決定するステップは、前記第１の基地局上に構成されたＰＤＣＰ（パケットデータコンバージェンスプロトコル）エンティティによって実行されることを特徴とする請求項１に記載の方法。
3. 前記少なくとも１つの協調するネットワーク要素に送信されるべき前記データの前記一部分を決定するステップは、前記第１の基地局上に構成されたＲＬＣ（無線リンク制御）エンティティによって実行されることを特徴とする請求項１に記載の方法。
4. 前記少なくとも１つの協調するネットワーク要素に送信されるべき前記データの前記一部分を決定するステップは、前記第１の基地局上に構成されたＭＡＣ（媒体アクセス制御）エンティティによって実行されることを特徴とする請求項１に記載の方法。
5. 前記少なくとも１つの協調するネットワーク要素は、基地局、ＲＲＨ（リモートラジオヘッド）、およびセクタアンテナのうち少なくとも１つを備えることを特徴とする請求項１に記載の方法。
6. 前記第１の基地局は、対話型の手順、および関連する制御情報を使用して、前記少なくとも１つの協調するネットワーク要素に送信されるべき前記データの前記一部分を決定することを特徴とする請求項１に記載の方法。
7. 前記データの前記残りの部分は、第１のコンポーネントキャリアを使用して前記第１の基地局から前記ＷＴＲＵに送信され、かつ前記データの前記一部分は、第２のコンポーネントキャリアを使用して前記少なくとも１つの協調するネットワーク要素から前記ＷＴＲＵに送信されることを特徴とする請求項１に記載の方法。
8. データを送信するように構成されたＷＴＲＵ（ワイヤレス送信／受信ユニット）であって、
   無線アクセスネットワークに送信するためのデータを生成し、かつ
   前記データの第１の部分が、第１の基地局に送信されるべきであり、かつ前記データの第２の部分が、少なくとも１つの協調する基地局に送信されるべきであることを決定するように構成されたプロセッサと、
   前記データの前記第１の部分を前記第１の基地局に送信し、かつ前記データの前記第２の部分を前記少なくとも１つの協調する基地局に送信するように構成されたトランシーバと
   を備えることを特徴とするＷＴＲＵ。
9. 前記プロセッサは、前記データの前記第１の部分が第１のコンポーネントキャリア上で送信されるべきであり、かつ前記データの前記第２の部分が第２のコンポーネントキャリア上で送信されるべきであることを決定するようにさらに構成されることを特徴とする請求項８に記載のＷＴＲＵ。
10. 前記プロセッサは、バッファステータスを判定するようにさらに構成され、前記トランシーバは、前記バッファステータスを前記第１の基地局、および前記少なくとも１つの協調する基地局に送信するようにさらに構成されることを特徴とする請求項８に記載のＷＴＲＵ。
11. 前記プロセッサは、前記データの前記第１の部分が前記第１の基地局に送信されるべきであり、かつ前記データの前記第２の部分が、ＰＤＣＰ（パケットデータコンバージェンスプロトコル）エンティティを使用して前記少なくとも１つの協調する基地局に送信されるべきであることを決定するように構成されることを特徴とする請求項８に記載のＷＴＲＵ。
12. 前記プロセッサは、前記データの前記第１の部分が前記第１の基地局に送信されるべきであり、かつ前記データの前記第２の部分が、ＲＬＣ（無線リンク制御）エンティティを使用して前記少なくとも１つの協調する基地局に送信されるべきであることを決定するように構成されることを特徴とする請求項８に記載のＷＴＲＵ。
13. 前記プロセッサは、前記データの前記第１の部分が前記第１の基地局に送信されるべきであり、かつ前記データの前記第２の部分が、ＭＡＣ（媒体アクセス制御）エンティティを使用して前記少なくとも１つの協調する基地局に送信されるべきであることを決定するように構成されることを特徴とする請求項８に記載のＷＴＲＵ。
14. 前記トランシーバは、前記第１の基地局から第２のデータを受信するように、かつ前記少なくとも１つの協調する基地局から第３のデータを受信するようにさらに構成され、前記プロセッサは、前記第２のデータと前記第３のデータをマージするようにさらに構成されることを特徴とする請求項８に記載のＷＴＲＵ。
15. 前記プロセッサは、バッファを使用して、前記第２のデータと前記第３のデータをマージするようにさらに構成されることを特徴とする請求項１４に記載のＷＴＲＵ。
16. 前記プロセッサは、前記第２のデータと前記第３のデータを並べ替えることを特徴とする請求項１４に記載のＷＴＲＵ。
17. データを送信するための方法であって、
    ゲートウェイノードにおいて、データを備えるＩＰ（インターネットプロトコル）パケットを受信するステップであって、前記ＩＰパケットは、第１のＷＴＲＵ（ワイヤレス送信／受信ユニット）に関連する受信するステップと、
    前記ゲートウェイノードにおいて、前記データの第１の部分が、前記ＷＴＲＵに送信されるように第１の基地局に送信されるべきであり、かつ前記データの第２の部分が、前記ＷＴＲＵに送信されるように少なくとも１つの協調する基地局に送信されるべきであることを決定するステップと、
    前記ゲートウェイノードから、前記データの前記第１の部分を前記第１の基地局に送信し、かつ前記データの前記第２の部分を前記少なくとも１つの協調する基地局に送信するステップと
    を備えることを特徴とする方法。
18. 前記ゲートウェイノードにおいて、前記データの前記第１の部分の前記第１の基地局への前記送信、および前記データの前記第２の部分の前記少なくとも１つの協調する基地局への前記送信を許すインジケータを受信するステップをさらに備えることを特徴とする請求項１７に記載の方法。
19. 前記データの前記第１の部分、および前記データの前記第２の部分は、ＧＴＰ（ＧＰＲＳトンネリングプロトコル）トンネルを使用して送信されることを特徴とする請求項１７に記載の方法。
20. 前記第１の基地局は、一次基地局であることを特徴とする請求項１７に記載の方法。

Images