"データを送信するための方法であって、第1の基地局において、データを備えるIPインターネットプロトコルパケットを受信するステップであって、前記IPパケットは、第1のWTRUワイヤレス送信/受信ユニットに関連する受信するステップと、前記第1の基地局において、前記データの一部分が、前記WTRUに送信されるように少なくとも1つの協調するネットワーク要素に送信されるべきことを決定するステップと、前記第1の基地局から、前記データの前記一部分を前記少なくとも1つの協調するネットワーク要素に送信するステップと、前記第1の基地局から、前記データの残りの部分を前記WTRUに送信するステップとを備えることを特徴とする方法。前記少なくとも1つの協調するネットワーク要素に送信されるべき前記データの前記一部分を決定するステップは、前記第1の基地局上に構成されたPDCPパケットデータコンバージェンスプロトコルエンティティによって実行されることを特徴とする請求項1に記載の方法。前記少なくとも1つの協調するネットワーク要素に送信されるべき前記データの前記一部分を決定するステップは、前記第1の基地局上に構成されたRLC無線リンク制御エンティティによって実行されることを特徴とする請求項1に記載の方法。前記少なくとも1つの協調するネットワーク要素に送信されるべき前記データの前記一部分を決定するステップは、前記第1の基地局上に構成されたMAC媒体アクセス制御エンティティによって実行されることを特徴とする請求項1に記載の方法。前記少なくとも1つの協調するネットワーク要素は、基地局、RRHリモートラジオヘッド、およびセクタアンテナのうち少なくとも1つを備えることを特徴とする請求項1に記載の方法。前記第1の基地局は、対話型の手順、および関連する制御情報を使用して、前記少なくとも1つの協調するネットワーク要素に送信されるべき前記データの前記一部分を決定することを特徴とする請求項1に記載の方法。前記データの前記残りの部分は、第1のコンポーネントキャリアを使用して前記第1の基地局から前記WTRUに送信され、かつ前記データの前記一部分は、第2のコンポーネントキャリアを使用して前記少なくとも1つの協調するネットワーク要素から前記WTRUに送信されることを特徴とする請求項1に記載の方法。データを送信するように構成されたWTRUワイヤレス送信/受信ユニットであって、無線アクセスネットワークに送信するためのデータを生成し、かつ前記データの第1の部分が、第1の基地局に送信されるべきであり、かつ前記データの第2の部分が、少なくとも1つの協調する基地局に送信されるべきであることを決定するように構成されたプロセッサと、前記データの前記第1の部分を前記第1の基地局に送信し、かつ前記データの前記第2の部分を前記少なくとも1つの協調する基地局に送信するように構成されたトランシーバとを備えることを特徴とするWTRU。前記プロセッサは、前記データの前記第1の部分が第1のコンポーネントキャリア上で送信されるべきであり、かつ前記データの前記第2の部分が第2のコンポーネントキャリア上で送信されるべきであることを決定するようにさらに構成されることを特徴とする請求項8に記載のWTRU。前記プロセッサは、バッファステータスを判定するようにさらに構成され、前記トランシーバは、前記バッファステータスを前記第1の基地局、および前記少なくとも1つの協調する基地局に送信するようにさらに構成されることを特徴とする請求項8に記載のWTRU。前記プロセッサは、前記データの前記第1の部分が前記第1の基地局に送信されるべきであり、かつ前記データの前記第2の部分が、PDCPパケットデータコンバージェンスプロトコルエンティティを使用して前記少なくとも1つの協調する基地局に送信されるべきであることを決定するように構成されることを特徴とする請求項8に記載のWTRU。前記プロセッサは、前記データの前記第1の部分が前記第1の基地局に送信されるべきであり、かつ前記データの前記第2の部分が、RLC無線リンク制御エンティティを使用して前記少なくとも1つの協調する基地局に送信されるべきであることを決定するように構成されることを特徴とする請求項8に記載のWTRU。前記プロセッサは、前記データの前記第1の部分が前記第1の基地局に送信されるべきであり、かつ前記データの前記第2の部分が、MAC媒体アクセス制御エンティティを使用して前記少なくとも1つの協調する基地局に送信されるべきであることを決定するように構成されることを特徴とする請求項8に記載のWTRU。前記トランシーバは、前記第1の基地局から第2のデータを受信するように、かつ前記少なくとも1つの協調する基地局から第3のデータを受信するようにさらに構成され、前記プロセッサは、前記第2のデータと前記第3のデータをマージするようにさらに構成されることを特徴とする請求項8に記載のWTRU。前記プロセッサは、バッファを使用して、前記第2のデータと前記第3のデータをマージするようにさらに構成されることを特徴とする請求項14に記載のWTRU。前記プロセッサは、前記第2のデータと前記第3のデータを並べ替えることを特徴とする請求項14に記載のWTRU。データを送信するための方法であって、ゲートウェイノードにおいて、データを備えるIPインターネットプロトコルパケットを受信するステップであって、前記IPパケットは、第1のWTRUワイヤレス送信/受信ユニットに関連する受信するステップと、前記ゲートウェイノードにおいて、前記データの第1の部分が、前記WTRUに送信されるように第1の基地局に送信されるべきであり、かつ前記データの第2の部分が、前記WTRUに送信されるように少なくとも1つの協調する基地局に送信されるべきであることを決定するステップと、前記ゲートウェイノードから、前記データの前記第1の部分を前記第1の基地局に送信し、かつ前記データの前記第2の部分を前記少なくとも1つの協調する基地局に送信するステップとを備えることを特徴とする方法。前記ゲートウェイノードにおいて、前記データの前記第1の部分の前記第1の基地局への前記送信、および前記データの前記第2の部分の前記少なくとも1つの協調する基地局への前記送信を許すインジケータを受信するステップをさらに備えることを特徴とする請求項17に記載の方法。前記データの前記第1の部分、および前記データの前記第2の部分は、GTPGPRSトンネリングプロトコルトンネルを使用して送信されることを特徴とする請求項17に記載の方法。前記第1の基地局は、一次基地局であることを特徴とする請求項17に記載の方法。図1Aは、開示される1つまたは複数の実施形態が実施され得る例示的な通信システム100の図である。通信システム100は、音声、データ、ビデオ、メッセージング、ブロードキャストなどのコンテンツを複数のワイヤレスユーザに供給する多元接続システムであり得る。通信システム100は、複数のワイヤレスユーザが、ワイヤレス帯域幅を含むシステムリソースの共有を介して、そのようなコンテンツにアクセスすることを可能にすることができる。例えば、通信システム100は、CDMA符号分割多元接続、TDMA時分割多元接続、FDMA周波数分割多元接続、OFDMA直交FDMA、SC-FDMAシングルキャリアFDMAなどの1つまたは複数のチャネルアクセス方法を使用することが可能である。図1Aに示されるとおり、通信システム100は、WTRUワイヤレス送信/受信ユニット102a、102b、102c、102dと、RAN無線アクセスネットワーク104と、コアネットワーク106と、PSTN公衆交換電話網108と、インターネット110と、その他のネットワーク112とを含むことが可能であり、ただし、開示される実施形態は、任意の数のWTRU、基地局、ネットワーク、および/またはネットワーク要素を企図することが認識されよう。WTRU102a、102b、102c、102dのそれぞれは、ワイヤレス環境において動作するように、かつ/または通信するように構成された任意のタイプのデバイスであり得る。例として、WTRU102a、102b、102c、102dは、ワイヤレス信号を送信するように、かつ/または受信するように構成されることが可能であり、さらにUEユーザ機器、移動局、固定加入者ユニットまたはモバイル加入者ユニット、ポケットベル、セルラ電話機、PDA携帯情報端末、スマートフォン、ラップトップ、ネットブック、パーソナルコンピュータ、ワイヤレスセンサ、家庭用電子機器などを含み得る。また、通信システム100は、基地局114aと、基地局114bとを含むことも可能である。基地局114a、114bのそれぞれは、コアネットワーク106、インターネット110、および/またはネットワーク112などの1つまたは複数の通信ネットワークへのアクセスを円滑にするように、WTRU102a、102b、102c、102dの少なくとも1つとワイヤレスでインターフェースをとるように構成された任意のタイプのデバイスであり得る。例として、基地局114a、114bは、BTS基地局トランシーバ、ノード-B、eノードB、ホームノードB、ホームeノードB、サイトコントローラ、APアクセスポイント、ワイヤレスルータなどであり得る。基地局114a、114bはそれぞれ単一の要素として示されるが、基地局114a、114bは、任意の数の互いに接続された基地局および/またはネットワーク要素を含み得ることが認識されよう。基地局114aは、他の基地局、および/またはBSC基地局コントローラ、RNC無線ネットワークコントローラ、中継ノードなどのネットワーク要素図示せずも含み得るRAN104の一部であることが可能である。基地局114aおよび/または基地局114bは、セル図示せずと呼ばれ得る特定の地理的区域内でワイヤレス信号を送信するように、かつ/または受信するように構成され得る。セルは、セルセクタにさらに分割され得る。例えば、基地局114aに関連するセルは、3つのセクタに分割され得る。このため、一実施形態では、基地局114aは、3つの、すなわち、セルの各セクタにつき1つのトランシーバを含み得る。別の実施形態では、基地局114aは、MIMO多入力多出力技術を使用することが可能であり、したがって、セルの各セクタにつき複数のトランシーバを利用することが可能である。基地局114a、114bは、任意の適切なワイヤレス通信リンク例えば、RF無線周波数、マイクロ波、IR赤外線、UV紫外線、可視光などであることが可能な無線インターフェース116を介して、WTRU102a、102b、102c、102dの1つまたは複数と通信することが可能である。無線インターフェース116は、任意の適切なRAT無線アクセス技術を使用して確立され得る。より具体的には、前述したとおり、通信システム100は、多元接続システムであることが可能であり、さらにCDMA、TDMA、FDMA、OFDMA、SC-FDMAなどの1つまたは複数のチャネルアクセススキームを使用することが可能である。例えば、RAN104における基地局114a、およびWTRU102a、102b、102cは、WCDMA広帯域CDMAを使用して無線インターフェース116を確立することが可能なUTRAUMTSユニバーサルモバイルテレコミュニケーションズシステム地上無線アクセスなどの無線技術を実施することが可能である。WCDMAは、HSPA高速パケットアクセスおよび/またはHSPA発展型HSPAなどの通信プロトコルを含み得る。HSPAは、HSDPA高速ダウンリンクパケットアクセスおよび/またはHSUPA高速アップリンクパケットアクセスを含み得る。別の実施形態では、基地局114a、およびWTRU102a、102b、102cは、LTEロングタームエボリューションおよび/またはLTE-ALTEアドバンストを使用して無線インターフェース116を確立することが可能なE-UTRA発展型UMTS地上無線アクセスなどの無線技術を実施することが可能である。他の実施形態では、基地局114a、およびWTRU102a、102b、102cは、IEEE802.16すなわち、WiMAXワールドワイドインターオペラビリティフォーマイクロウェイブアクセス、CDMA2000、CDMA20001X、CDMA2000EV-DO、IS-2000暫定標準2000、IS-95暫定標準95、IS-856暫定標準856、GSMグローバルシステムフォーモバイルコミュニケーションズ、EDGEエンハンストデータレートフォーGSMエボリューション、GERANGSMEDGEなどの無線技術を実施することが可能である。図1Aの基地局114bは、例えば、ワイヤレスルータ、ホームノードB、ホームeノードB、またはアクセスポイントであることが可能であり、さらに事業所、自宅、車両、キャンパスなどの局所化された区域内でワイヤレス接続を円滑にするための任意の適切なRATを利用することが可能である。一実施形態では、基地局114b、およびWTRU102c、102dは、IEEE802.11などの無線技術を実施して、WLANワイヤレスローカルエリアネットワークを確立することが可能である。別の実施形態では、基地局114b、およびWTRU102c、102dは、IEEE802.15などの無線技術を実施して、WPANワイヤレスパーソナルエリアネットワークを確立することが可能である。さらに別の実施形態では、基地局114b、およびWTRU102c、102dは、セルラベースのRAT例えば、WCDMA、CDMA2000、GSM、LTE、LTE-Aなどを利用して、ピコセルまたはフェムトセルを確立することが可能である。図1Aに示されるとおり、基地局114bは、インターネット110に対する直接接続を有し得る。このため、基地局114bは、コアネットワーク106を介してインターネット110にアクセスすることを要求されない可能性がある。RAN104は、WTRU102a、102b、102c、102dの1つまたは複数に音声、データ、アプリケーション、および/またはVoIPボイスオーバーインターネットプロトコルサービスを提供するように構成された任意のタイプのネットワークであり得るコアネットワーク106と通信状態にあることが可能である。例えば、コアネットワーク106は、呼制御、料金請求サービス、モバイルロケーションベースのサービス、プリペイド通話、インターネット接続、ビデオ配信などを提供することが可能であり、かつ/またはユーザ認証などの高レベルセキュリティ機能を実行することが可能である。図1Aに示されないものの、RAN104および/またはコアネットワーク106は、RAN104と同一のRAT、または異なるRATを使用する他のRANと直接または間接の通信状態にあることが可能であることが認識されよう。例えば、E-UTRA無線技術を利用していることが可能なRAN104に接続されていることに加えて、コアネットワーク106は、GSM無線技術を使用する別のRAN図示せずと通信状態にあることも可能である。コアネットワーク106は、WTRU102a、102b、102c、102dが、PSTN108、インターネット110、および/または他のネットワーク112にアクセスするゲートウェイの役割をすることも可能である。PSTN108は、POTS通常の従来の電話サービスを提供する回線交換電話網を含み得る。インターネット110は、TCP/IPインターネットプロトコルスイートにおけるTCP伝送制御プロトコル、UDPユーザデータグラムプロトコル、およびIPインターネットプロトコルなどの共通の通信プロトコルを使用する、互いに接続されたコンピュータネットワークおよびコンピュータデバイスの地球規模のシステムを含み得る。ネットワーク112は、他のサービスプロバイダによって所有される、かつ/または運用される有線通信ネットワークまたはワイヤレス通信ネットワークを含み得る。例えば、ネットワーク112は、RAN104と同一のRATを使用することも、異なるRATを使用することも可能な1つまたは複数のRANに接続された別のコアネットワークを含み得る。通信システム100におけるWTRU102a、102b、102c、102dのいくつか、またはすべてが、マルチモード能力を含むことが可能であり、すなわち、WTRU102a、102b、102c、102dは、異なる複数のワイヤレスリンクを介して異なる複数のワイヤレスネットワークと通信するための複数のトランシーバを含むことが可能である。例えば、図1Aに示されるWTRU102cは、セルラベースの無線技術を使用することが可能な基地局114aと通信するとともに、IEEE802無線技術を使用することが可能な基地局114bと通信するように構成されることが可能である。図1Bは、例示的なWTRU102のシステム図である。図1Bに示されるとおり、WTRU102は、プロセッサ118と、トランシーバ120と、送信/受信要素122と、スピーカ/マイクロフォン124と、キーパッド126と、ディスプレイ/タッチパッド128と、非リムーバブルメモリ130と、リムーバブルメモリ132と、電源134と、GPS全地球測位システムチップセット136と、他の周辺装置138とを含み得る。WTRU102は、或る実施形態に合致したままで、以上の要素の任意の部分的組合せを含み得ることが認識されよう。プロセッサ118は、汎用プロセッサ、専用プロセッサ、従来のプロセッサ、DSPデジタルシグナルプロセッサ、複数のマイクロプロセッサ、DSPコアに関連する1つまたは複数のマイクロプロセッサ、コントローラ、マイクロコントローラ、ASIC特定用途向け集積回路、FPGAフィールドプログラマブルゲートアレイ回路、他の任意のタイプのIC集積回路、状態マシンなどであり得る。プロセッサ118は、信号符号化、データ処理、電力制御、入出力処理、および/またはWTRU102がワイヤレス環境において動作することを可能にする他の任意の機能を実行することが可能である。プロセッサ118は、送信/受信要素122に結合され得るトランシーバ120に結合され得る。図1Bは、プロセッサ118とトランシーバ120を別々の構成要素として示しているが、プロセッサ118とトランシーバ120は、電子パッケージまたはチップに一緒に組み込まれてもよいことが認識されよう。送信/受信要素122は、無線インターフェース116を介して基地局例えば、基地局114aに信号を送信するように、または基地局例えば、基地局114aから信号を受信するように構成され得る。例えば、一実施形態では、送信/受信要素122は、RF信号を送信するように、かつ/または受信するように構成されたアンテナであり得る。別の実施形態では、送信/受信要素122は、例えば、IR信号、UV信号、または可視光信号を送信するように、かつ/または受信するように構成されたエミッタ/検出器であり得る。さらに別の実施形態において、送信/受信要素122は、RF信号と光信号の両方を送受信するように構成され得る。送信/受信要素122は、ワイヤレス信号の任意の組合せを送信するように、かつ/または受信するように構成され得ることが認識されよう。さらに、送信/受信要素122は、図1Bに単一の要素として示されているが、WTRU102は、任意の数の送信/受信要素122を含み得る。より具体的には、WTRU102は、MIMO技術を使用することが可能である。このため、一実施形態では、WTRU102は、無線インターフェース116を介してワイヤレス信号を送受信するための2つ以上の送信/受信要素122例えば、複数のアンテナを含み得る。トランシーバ120は、送信/受信要素122によって送信されるべき信号を変調するように、かつ送信/受信要素122によって受信された信号を復調するように構成され得る。前述したとおり、WTRU102は、マルチモード能力を有することが可能である。このため、トランシーバ120は、WTRU102が、例えば、UTRAやIEEE802.11などの複数のRATを介して通信することを可能にするための複数のトランシーバを含み得る。WTRU102のプロセッサ118は、スピーカ/マイクロフォン124、キーパッド126、および/またはディスプレイ/タッチパッド128例えば、LCD液晶ディスプレイディスプレイユニットまたはOLED有機発光ダイオードディスプレイユニットに結合されることが可能であり、かつスピーカ/マイクロフォン124、キーパッド126、および/またはディスプレイ/タッチパッド128からユーザ入力データを受け取ることが可能である。また、プロセッサ118は、スピーカ/マイクロフォン124、キーパッド126、および/またはディスプレイ/タッチパッド128にユーザデータを出力することも可能である。さらに、プロセッサ118は、非リムーバブルメモリ130、および/またはリムーバブルメモリ132などの任意のタイプの適切なメモリからの情報にアクセスすること、およびそのようなメモリの中にデータを格納することが可能である。非リムーバブルメモリ130には、RAMランダムアクセスメモリ、ROM読み取り専用メモリ、ハードディスク、または他の任意のタイプのメモリストレージデバイスが含まれ得る。リムーバブルメモリ132には、SIM加入者IDモジュールカード、メモリスティック、SDセキュアデジタルメモリカードなどが含まれ得る。他の実施形態において、プロセッサ118は、サーバまたはホームコンピュータ図示せずなどの、WTRU102から物理的に遠隔に配置されたメモリからの情報にアクセスすること、およびそのようなメモリの中にデータを格納することが可能である。プロセッサ118は、電源134から電力を受け取ることが可能であり、さらにWTRU102内のその他の構成要素に対して電力を配電するように、かつ/または制御するように構成されることが可能である。電源134は、WTRU102に電力を供給するための任意の適切なデバイスであり得る。例えば、電源134には、1つまたは複数の乾電池例えば、NiCdニッケルカドミウム、NiZnニッケル亜鉛、NiMHニッケル水素、Li-ionリチウムイオンなど、太陽電池、燃料電池などが含まれ得る。プロセッサ118は、WTRU102の現在のロケーションに関するロケーション情報例えば、緯度と経度を提供するように構成され得るGPSチップセット136に結合されることも可能である。GPSチップセット136からの情報に加えて、またはそのような情報の代わりに、WTRU102は、基地局例えば、基地局114a、114bから無線インターフェース116を介してロケーション情報を受信すること、および/または近くの2つ以上の基地局から受信されている信号のタイミングに基づいて、WTRUのロケーションを特定してもよい。WTRU102は、或る実施形態と合致したままで、任意の適切なロケーション特定方法によってロケーション情報を獲得し得ることが認識されよう。プロセッサ118は、さらなるフィーチャ、機能、および/または有線もしくはワイヤレスの接続をもたらす1つまたは複数のソフトウェアモジュールおよび/またはハードウェアモジュールを含み得る、他の周辺装置138にさらに結合されることが可能である。例えば、周辺装置138には、加速度計、電子コンパス、衛星トランシーバ、デジタルカメラ写真またはビデオのための、USBユニバーサルシリアルバスポート、振動デバイス、電話トランシーバ、ハンズフリーヘッドセット、Bluetooth登録商標モジュール、FM周波数変調無線ユニット、デジタル音楽プレーヤ、メディアプレーヤ、ビデオゲームプレーヤモジュール、インターネットブラウザなどが含まれ得る。図1Cは、或る実施形態によるRAN104およびコアネットワーク106のシステム図である。前述したとおり、RAN104は、E-UTRA無線技術を使用して、無線インターフェース116を介してWTRU102a、102b、102cと通信することが可能である。RAN104は、コアネットワーク106と通信状態にあることも可能である。RAN104は、eノードB140a、140b、140cを含み得るが、RAN104は、或る実施形態と合致したままで、任意の数のeノードBを含んでもよいことが認識されよう。eノードB140a、140b、140cはそれぞれ、無線インターフェース116を介してWTRU102a、102b、102cと通信するための1つまたは複数のトランシーバを含み得る。一実施形態では、eノードB140a、140b、140cは、MIMO技術を実施することが可能である。このため、例えば、eノードB140aは、複数のアンテナを使用して、WTRU102aにワイヤレス信号を送信すること、およびWTRU102aからワイヤレス信号を受信することが可能である。eノードB140a、140b、140cのそれぞれは、特定のセル図示せずに関連することが可能であり、さらに無線リソース管理決定、ハンドオーバ決定、アップリンクおよび/またはダウンリンクにおけるユーザのスケジューリングなどを扱うように構成され得る。図1Cに示されるとおり、eノードB140a、140b、140cは、X2インターフェースを介して互いに通信することが可能である。図1Cに示されるコアネットワーク106は、MME移動性管理ゲートウェイ142、サービングゲートウェイ144、およびPDNパケットデータネットワークゲートウェイ146を含むことが可能である。以上の要素のそれぞれはコアネットワーク106の一部として示されるが、これらの要素のうちのいずれの要素も、コアネットワーク事業者以外のエンティティによって所有され、かつ/または運用されることが可能であることが認識されよう。MME142は、S1インターフェースを介してRAN104におけるeノードB142a、142b、142cのそれぞれに接続されることが可能であり、さらに制御ノードの役割をすることが可能である。例えば、MME142は、WTRU102a、102b、102cのユーザを認証すること、ベアラ活性化/不活性化、WTRU102a、102b、102cの初期アタッチ中に特定のサービングゲートウェイを選択することなどを担うことが可能である。また、MME142は、RAN104と、GSMまたはWCDMAなどの他の無線技術を使用する他のRAN図示せずとの間で切り換えるための制御プレーン機能をもたらすことも可能である。サービングゲートウェイ144は、S1インターフェースを介してRAN104におけるeノードB140a、140b、140cのそれぞれに接続され得る。サービングゲートウェイ144は、一般に、WTRU102a、102b、102cに/から、ユーザデータパケットをルーティングすること、および転送することが可能である。また、サービングゲートウェイ144は、eノードB間ハンドオーバ中にユーザプレーンをアンカすること、ダウンリンクデータがWTRU102a、102b、102cに利用可能である際にページングをトリガすること、WTRU102a、102b、102cのコンテキストを管理すること、および格納することなどの、他の機能を実行することも可能である。また、サービングゲートウェイ144は、WTRU102a、102b、102cに、インターネット110などのパケット交換網へのアクセスを提供して、WTRU102a、102b、102cとIP対応のデバイスとの間の通信を円滑にすることが可能であるPDNゲートウェイ146に接続されることも可能である。コアネットワーク106は、他のネットワークとの通信を円滑にすることが可能である。例えば、コアネットワーク106は、WTRU102a、102b、102cに、PSTN108などの回線交換網へのアクセスを提供して、WTRU102a、102b、102cと従来の陸線通信デバイスとの間の通信を円滑にすることが可能である。例えば、コアネットワーク106は、コアネットワーク106とPSTN108との間のインターフェースの役割をするIPゲートウェイ例えば、IMSIPマルチメディアサブシステムサーバを含むことが可能であり、またはそのようなIPゲートウェイと通信することが可能である。さらに、コアネットワーク106は、WTRU102a、102b、102cに、他のサービスプロバイダによって所有され、かつ/または運用される他の有線ネットワークまたはワイヤレスネットワークを含み得るネットワーク112へのアクセスを提供することが可能である。LTEDLダウンリンク伝送スキームは、OFDMA無線インターフェースに基づくことが可能である。LTEULアップリンク方向に関して、DFT-S-OFDMADFT拡散OFDMAに基づくSCシングルキャリア伝送が使用され得る。R8LTEDL方向で、UEは、eノードBによって、LTE伝送帯域幅全体にわたる任意の位置でUEのデータを受信するように割り当てられることが可能である例えば、OFDMAスキームが使用され得る。LTEDLは、スペクトルの中心に使用されないDCオフセットサブキャリアを有し得る。R8LTEUL方向で、R8LTEシステムは、DTF-S-OFDMA伝送またはSC-FDMA伝送に基づくことが可能である。UEは、DL方向で、LTE伝送帯域幅全体の周波数領域にわたる任意の位置でUEの信号を受信することが可能である一方で、UL方向では、UEは、FDMA周波数分割多元接続構成において、割り当てられたサブキャリアの、限られたまたは限られた場合のみ、ただし或る実施形態では隣接した、セット上で、送信することが可能である。この構成は、SCシングルキャリアFDMAと呼ばれ得る。或る実施形態では、ULにおける全体的なOFDM信号帯域幅またはOFDMシステム帯域幅が、1から100まで番号が付けられた有用なサブキャリアから成る場合、所与の第1のUEが、サブキャリア1~12上でUEの信号を送信するように割り当てられ、所与の第2のUEが、サブキャリア13~24上で送信するように割り当てられることが可能である、といった具合である。eノードBは、1つまたは複数のUEから伝送帯域幅全体にわたって複合UL信号を同時に受信することが可能であるが、各UEは、利用可能な伝送帯域幅のサブセットの中に送信することまたはそのように送信することだけが可能である。したがって、ULにおけるDFT-S-OFDMは、UEに割り当てられた時間周波数リソースが、周波数の連続するサブキャリアのセットから成らなければならないというさらなる制約を伴う、従来の形態のOFDM伝送と見なされることが可能である。ULにおいて、DCサブキャリアは全く存在しなくてよい。1つの動作モードで、周波数ホッピングが、UEによってUL伝送に適用されることが可能である。LTE-Aは、CAキャリア集約フィーチャ、および柔軟性のある帯域幅構成フィーチャをサポートすることが可能である。このことは、DL伝送帯域幅およびUL伝送帯域幅が20MHzを超えることを許し得る例えば、R8LTEの場合と同様に。例えば、40MHzから100MHzまでの伝送帯域幅がサポートされ得る。LTER10において、CCコンポーネントキャリアは、このスペクトル集約フィーチャを可能にすることができる。或る実施形態では、各CCにつき20MHzの最大帯域幅を有する100MHzまでの集約されたスペクトルが、したがって、少なくとも5つのCCが、構成され得る。LTE-Aにおいて、異なるCCは、異なるカバレッジcoverageを有し得る。複数のCCを利用する或る実施形態において、マルチキャリア干渉を防止するため、または軽減するために、異なるセルが、異なるセットのCCを使用することが可能である。そのようなセルは、図2に示されるとおり、異なる範囲を有することが可能であり、さらに1より大きい有効周波数再利用パターンを有することが可能である。複数のCCを使用するキャリア集約は、RRCCONNECTED状態にあるUEに関係があることが可能である。アイドルなUEは、単一のULキャリアペアおよびDLキャリアペアを介して例えば、FDD周波数分割複信を使用してネットワークにアクセスすることが可能である。LTE-A実施形態において、1つのサービングeノードBにおけるキャリア集約がサポートされ得る。この構成は、CAセルハンドオーバオプションを、ハンドオーバの後、またはハンドオーバの前のターゲット候補CCの割当てに縮小することが可能である。ハンドオーバの後にターゲット候補を割り当てることは、ユーザプレーン遅延を増加させる可能性があり、したがって、ハンドオーバ前の割当てが、より良好なパフォーマンスをもたらす可能性があり、さらにターゲットeノードBとソースeノードBとの間で測定情報交換のためのX2インターフェースメッセージを追加することを要求する可能性がある。UEがセルエッジに位置している場合、セルエッジにおけるパフォーマンスは、他のセルからの干渉によって制限され得るため、一様なユーザ体験例えば、スループット、QoSなどを提供することは、困難であり得る。或る実施形態では、UEが所与の時点で或るCCの良好なカバレッジエリアcoveragearea内に入っている場合、CCが、このセルエッジ問題を軽減するのに使用され得る。或る実施形態では、図3に示されるとおり、セルエッジまでの距離を変化させるように各CCの送信電力を変えるように隣接するeノードBセルサイトを協調させることによって、異なるセルエッジに関して重なり合うCCが作成され得る。図3で、UE350は、位置310にあることが可能であり、さらにeノードB361とCC320を介して通信していること371aが可能であり、さらにeノードB361とCC330を介して通信していること372aが可能である。UE350が、eノードB362に対してCC330が使用され得るが、CC320がeノードB361のセル境界内に留まる新たな位置311に移動すると、UE350は、eノードB361とCC320を介して依然として通信すること371bが可能であるが、この時点で、eノードB362とCC330を介して通信すること372bが可能である。このことは、ネットワークが1という周波数再利用率を保ちながら、UE350が、異なるロケーションにおいて異なるCCにハンドオーバすることによって、セル中心近くに留まることを可能にし得る。このシナリオにおいて、すべてのCC上でUEをそれぞれがサポートすることができる完全な能力の基地局関連するRRHラジオヘッドを有する基地局、および有さない基地局を含むは、UEが異なるサイトからそれぞれが送信され得るCCのセット上で受信することができる場合に、使用され得る。eノードB361およびeノードB362は、eノードBと呼ばれるが、これらのネットワーク要素は、本明細書で説明される機能を実行することができる他の任意のタイプのデバイスおよび/またはネットワーク要素であり得ることに留意されたい。例えば、eノードB361および/またはeノードB362は、RRHリモートラジオヘッド:remoteradiohead、セクタアンテナ、任意のタイプの基地局、またはこれらもしくは他の任意のネットワーク要素の任意の組合せであり得る。任意のそのようなデバイスまたはネットワーク要素が、基地局、eノードB、ゲートウェイ、ノード、または他の任意のネットワーク要素によって実行されるものとして本明細書で説明される機能のいずれを実行するようにも構成されることが可能であり、さらにすべてのそのような実施形態が、本開示の範囲に含まれるものとして企図される。一部のLTER10実施において、キャリア集約のための複数のCCのサポートが、1つのサービングeノードBに制限され得る。このことは、UEが、異なる複数のeノードBに対して1つのCCを使用してデータ接続を維持することを妨げ得る。UEが、図3に示されるとおり、異なる2つのeノードB上のCCに関してカバレッジの重なり合いが存在するロケーションに移動するシナリオにおいて、ネットワークRRM無線リソース管理エンティティが、異なるサイトからの複数のCCを使用することによってデータスループット増加を十分に利用する代わりに、別のセルサイトにハンドオーバすべきかどうかを判定することが可能である。各CC上で利用可能な帯域幅を十分に利用するために、対応するデータストリームが、関連するeノードBにルーティングされること、および関連するeノードBからルーティングされることが可能である。各データストリームは、送信および受信をサポートするのに使用される、関連するリソース帯域幅およびバッファを有する。各CCに関する集約帯域幅は、ネットワークの計画者によって知られ得るが、CC上でUEに利用可能な瞬間的な帯域幅は、通常、eノードBスケジューラの動的決定である。各CCにどれだけのデータを送るべきかの決定は、協調する各サイトのリソース要件に直接の影響を与える可能性がある。或る実施形態では、協調するeノードBは、例えば、そのeノードBの利用可能なリソースに関する情報を、データ分割を実行すべきかどうか、およびデータ分割をどのように実行するべきかを判定することが可能であり、かつ完全な例えば、分割比または分割されないデータフローを受信するように構成されることが可能な、サービングeノードBにフィードバックすることが可能である。或る実施形態では、eノードBからUEへのSAEサービスアーキテクチャエボリューションベアラのデータスループットは、RAN無線アクセスネットワークにおける複数のサイトに対するデータストリームの分割を協調させることによって、増加され得る。データ分割は、PDCP層パケットデータコンバージェンスプロトコル、RLC無線リンク制御層、MAC媒体アクセス制御層を含め、RANスタックの任意の層において、または任意の組合せにおいて、または本明細書で開示される任意の手段を使用して、実施され得る。また、データ分割は、ユーザプレーンにおいて行われることも可能である。そのようなデータ分割を実行するためのシステムおよび方法は、本明細書で、より詳細に開示される。アップリンクデータおよびダウンリンクデータは、RANにおける複数のeノードBおよび他のサイト例えば、RRHにわたって分割され得る。DLデータ分割に関して、eノードBは、入ってくるデータストリームを、協調するCCの数に対応するN個のストリームに分割することが可能である。データ分割は、協調するCCによって報告される帯域幅利用可能性、バッファリングするエンティティによって報告されるバッファステータス、および/またはベアラQoS要件からのデータレートに基づくことが可能である。また、eノードBは、負荷に左右される機構などの、どのようにデータを分割すべきかを決定する対話型の手順をサポートすることも可能である。この機構は、瞬間的なバッファステータス、バッファステータスの別の目安例えば、平均、および/またはピアeノードB上の既存のエンティティの帯域幅に基づくアルゴリズムを使用することが可能である。フロー制御機構は、協調するCCのうちの任意のCC上の回復不能な伝送誤りを回復するために、まだ確認応答されていないデータをバッファリングすること、および/またはデータ分割エンティティから受け取られたデータをバッファリングして、そのデータを、帯域幅利用可能性に基づいて送信することができることが可能である。DLデータ分割において、eノードBは、SAEベアラを解体することなしに、協調するCCを動的に追加する、または除去する能力をサポートすることも可能である。また、eノードBは、現在のバッファステータスに関する定期的な測定レポート、および/またはイベントによってトリガされる測定レポートを供給するために、ならびに帯域幅利用に関する定期的な測定レポート、および/またはイベントによってトリガされる測定レポートを供給するために、伝送パスの負荷監視をサポートすることも可能である。DLデータ分割において、UEは、受信されたデータをバッファリングし、さらに異なるリンクから受信されたデータの並べ替えを実行して、そのデータが、そのデータが送られた順序で上位の層に供給されることを確実にすることが可能である。この機能は、そのエンティティより上の層が、一般に、そのような並べ替えを実行する能力を有さない例えば、動作の通常の過程でそのような並べ替えを実行する能力を有さないなどの場合に使用され得る。また、UEは、順次のデリバリをサポートすることも可能であり、かつデータストリーム分割に対応するデータパスをセットアップするように、影響を受ける層を構成することが可能である。DLデータ分割において、X2インターフェース例えば、トンネリングが、いくつかの機能をサポートすることが可能である。X2APX2アプリケーションプロトコルが、データ分割エンティティの構成および制御をもたらすことが可能であり、かつ測定レポートおよび/または帯域幅監視レポートをもたらすこと、ならびにエンティティのセットアップ、変更、および/または解放の構成をもたらすことを担うことが可能である。X2データトランスポートプロトコルまたはX2データトンネリングプロトコルは、サービングeノードBと協調するeノードBとの間にデータ分割エンティティを接続して、接続されたeノードBの間でデータの送信および/もしくは受信をもたらすこと、ならびに/または接続された2つのエンティティの間でデータ制御メッセージ例えば、リセットメッセージ、バッファステータス、帯域幅監視レポートなどを転送することが可能である。また、X2データトランスポートプロトコルまたはX2データトンネリングプロトコルは、X2APを介して、またはトンネリングプロトコルを介する帯域内シグナリングを通じて、フロー制御交換をサポートすることも可能である。ULデータ分割において、UEは、入ってくるデータストリームを、協調するCCの数に対応するN個のストリームに分割することが可能である。データ分割は、協調するCCによってスケジュールされる帯域幅利用可能性、バッファリングエンティティから報告されるバッファステータス、および/またはベアラQoS要件からのデータレートに基づくことが可能である。UEは、瞬間的なバッファステータスもしくは他の目安のバッファステータス、および/またはeノードBによってスケジュールされたUL帯域幅に基づくアルゴリズムを使用する負荷に左右されるフロー制御機構をサポートすることが可能である。フロー制御機構は、協調するCCのうちの任意のCC上の回復不能な伝送誤りを回復するために、まだ確認応答されていないデータをバッファリングすること、および/またはデータ分割エンティティから受け取られたデータをバッファリングして、そのデータを、帯域幅利用可能性に基づいて送信することができることが可能である。ULデータ分割において、UEは、SAEベアラを解体することなしに、協調するCCを動的に追加する、または除去する構成をサポートすることも可能である。UEは、現在のバッファステータスに関する定期的な測定レポート、および/もしくはイベントによってトリガされる測定レポートをデータ分割エンティティに供給するために、ならびに/または帯域幅利用に関する定期的な測定レポート、および/もしくはイベントによってトリガされる測定レポートを供給するために、伝送パスの負荷監視をサポートすることも可能である。ULデータ分割において、eノードBは、UEに対する帯域幅をスケジュールし協調するeノードBの同期を伴って、または伴わずに、かつ受信されたデータをバッファリングし、さらに、異なるリンクから受信されたデータの並べ替えを実行して、そのデータが、そのデータが送られた順序で上位の層に供給されることを確実にするように構成され得る。この並べ替え機能は、そのエンティティより上の層が、一般に、そのような並べ替えを実行する能力を有さない例えば、動作の通常の過程でそのような並べ替えを実行する能力を有さないなどの場合に使用され得る。また、eノードBは、順次のデリバリをサポートすること、およびデータストリーム分割に対応するデータパスをセットアップするように、影響を受ける層を構成することをサポートすることも可能である。ULデータ分割において、X2インターフェース例えば、トンネリングが、いくつかの機能をサポートすることが可能である。X2アプリケーションプロトコルは、構成をもたらすことが可能であり、データ分割エンティティを制御することが可能であり、かつ測定レポートおよび/もしくは帯域幅レポートを送ること、ならびに/またはエンティティのセットアップ、変更、および/もしくは解放の構成をもたらすことを担うことが可能である。トンネリングプロトコルは、サービングeノードBと協調するeノードBとの間にデータ分割エンティティを接続して、接続されたeノードBの間でデータの伝送をもたらすこと、および/または接続された2つのエンティティの間でデータ制御メッセージ例えば、リセットメッセージ、測定レポートなどを転送することが可能である。或る実施形態において、データ分割は、PDCP層において実行され得る。ソースeノードBにおいてインターワーキング機能PDCPIWFが使用されて、協調するeノードBにおけるPDCPIWFに圧縮されたIPパケットPDCPPDUが転送されてから、送信バッファリングのためにRLC層に転送されることが可能である。PDCPIWFは、1つのSAEベアラ当り複数の無線ベアラのサポートを提供することが可能である。図4は、PDCP層においてデータ分割を実行するデータ分割実施形態において使用され得る例示的なDLデータフローおよびシステム構成を示す。UE401は、UE401がeノードB410およびeノードB420の両方と通信することを許すロケーションにあることが可能である。IPパケット405は、eノードB410において受信されることが可能であり、さらにIPパケット405の宛先としてUE401を有することが可能である。IPパケット405は、無線ベアラ403aおよび403bを含み得るSAEベアラ402を介してeノードB410に送信され得る。PDCPIWF450は、eノードB間トンネル440を部分的に用いて、eノードB410とeノードB420との間でデータを分割することを円滑にすることが可能である。IPヘッダ圧縮が、ヘッダ圧縮モジュール411aおよび411bにおいて実行されて、ラジオインターフェースを介して送信される必要があるビットの数を減らすことが可能である。任意のモード例えば、Uモード単方向モード、Oモード双方向楽観モード、およびRモード双方向高信頼モードで堅牢なヘッダ圧縮が使用され得る。OモードおよびRモードは、誤り回復のためにフィードバックチャネルを利用することが可能である。圧縮は前のフレーム情報を使用するため、ヘッダ圧縮モジュール411aおよび411bによって実行されるヘッダ圧縮処理が実行されてから、フィードバック処理を伴うデータ分割が、1つのエンティティにおいて例えば、1つだけのエンティティにおいて実行されることが可能である。送信されるデータの暗号化および完全性保護が、暗号化モジュール412aおよび412bにおいて実行され得る。eノードB間トンネル440が、PDCPPDUの一部分を、分割されたデータストリームサブフローとして、協調するeノードB420に伝送するが、複数のHFNハイパーフレーム番号およびPDCPSNシーケンス番号をシグナリングするとともに、保持しなければならないことを回避するように、暗号化の後に伝送することが可能である。データは、PDCPeノードB間マルチプレクサ413において分割されることが可能であり、eノードB420のために分割されたデータが、eノードB間トンネル440を介してeノードB420に送信されることが可能である。eノードB410から送信されるべきデータは、RLCバッファ414aおよび414bに供給され、MACマルチプレクサ415によってMAC層において多重化され、PHY変調-符号化モジュール417によって物理層において変調され、符号化されて、さらにCC471を介してUE401に最終的に送信されることが可能である。eノードB420から送信されるべきデータは、RLCバッファ424aおよび424bに供給され、MACマルチプレクサ425によってMAC層において多重化され、PHY変調-符号化モジュール427によって物理層において変調され、符号化されて、さらにCC472を介してUE401に最終的に送信されることが可能である。eノードB410およびeノードB420は、UE401からチャネルステータスデータ419および429例えば、ダウンリンクチャネル品質情報を受信し、さらにRLCバッファからデータを受け取り、MACマルチプレクサおよびPHY変調-符号化モジュールを用いてデータの送信を協調させるMACスケジューラ416および426をそれぞれ有することが可能である。移動端末装置のために構成された1つの無線ベアラ当り1つのPDCPエンティティが存在し得る。データ分割をサポートするのに、スケジューラ例えば、受け取られたPDCPパケットの、活性のサイトへの単純なラウンドロビン配布、または宛先eノードB420からのバッファステータスフィードバックまたは送信レートフィードバックを用いた何らかの分割アルゴリズムに基づくが、別のCCを介して送信するために別のサイト例えば、eノードB420にPDCPPDU例えば、IPパケット405の一部分を含むを転送するのに使用され得る。この構成は、1つの無線ベアラ当りセットアップされる2つ以上の或る実施形態では、一緒に送信するサイトの数に依存するデータストリーム例えば、PDCP/RLC/MACをもたらす例えば、参加するCC当り1つ、さらにUEに関してN個、ただし、Nは、参加するCCの総数。PDCP/RLCインターフェース上に存在するスケジューラが、RLC層におけるさらなる処理のために、メインサービングサイトおよび協調サイトを含む異なる複数のサイトへのデータ転送のスケジューリングを担うことが可能である。PDCPIWF450において、協調するCCにおける輻輳した、または限られたPHY物理層帯域幅がバッファオーバフローを生じた場合にデータが失われるのを回避するのに、フロー機構が使用され得る。フロー機構は、協調するCCに関するデータバッファステータス例えば、RLCバッファ占有率、および/または瞬間的な帯域幅情報、もしくは帯域幅の他の何らかの目安の情報をもたらす、トンネリングプロトコルを介したフィードバックであり得る。図5に示されるPDCP層における対応するULデータ分割は、DLの場合と同一のモジュールレイアウトを利用するが、データパス方向を逆にする。図4に示されるとおり実行される機能のいずれに関しても、逆の機能が、図5における同一のモジュールおよび/またはエンティティによって実行されることが可能であり、またはそのような逆の機能が、異なるモジュールもしくはエンティティによって実行されることが可能であることに留意されたい。例えば、eノードB410および420のMACマルチプレクサが、UL信号に関する逆多重化を実行することも可能である。DLとULはともに、参加するCCごとに1つのPDCPエンティティを用いて構成され得る。図5では、データマージャが、PDCPeノードB間マルチプレクサ413のマージャエンティティによってeノードB410において実行され得る。或る実施形態において、物理層HARQACK/NACKが、送信側セルとは独立に扱われることが可能である。図5で、UE401から送信されるべきデータが、PDCPIWFデータ分割図示せずによって、UE401上に構成されたRLCバッファ434aおよび434bに供給され、MACマルチプレクサ435によってMAC層において多重化され、PHY変調-符号化モジュール437によって物理層において変調され、符号化され、分割されて、最終的に、CC473を介してeノードB410に、およびCC474を介してeノードB420に送信されることが可能である。この場合も、eノードB410およびeノードB420は、UE401からチャネルステータスデータ419および429例えば、アップリンクチャネル品質情報を受信するMACスケジューラ416および426をそれぞれ有することが可能である。受信側図4のUE401、または図5のeノードBで、データ分割を再マージするデータマージャが実行されることが可能であり、さらに、RLC-順次デリバリのために接続が構成される実施形態において、個別のRLCエンティティが部分的にPDCPデータストリームを受信している可能性があるので、RLCエンティティの代わりにマージャエンティティが、このタスクを実行することが可能である。データマージャは、Iu無線インターフェース上の様々な伝送パス遅延に起因して順序の乱れたデリバリを格納するのに使用され得るバッファに対するアクセスを有することが可能である。図4で、データマージャが、マージャエンティティ407によってUE401において実行され得る。PDCP層におけるデータ分割は、PDCPに限られた変更を要求して、確立されたシステムアーキテクチャに小さな影響しか与えないことが可能である。また、この構成は、構成変更を最小限に抑え、かつ別々のルート/サイト例えば、eノードB、RRH、ノードBなどからの独立したPDCPPDUデリバリを許すことも可能である。データ分割を使用しないまたはデータ分割を制限する実施において、HOハンドオーバの前の準備中に、またはHO中に、シームレスなハンドオーバが、データ複製を使用してRANによって保証されることが可能である。ソースeノードBとターゲットeノードBとの間のデータルートデータストリームを転送するトンネリングが、UEがHOを命令される前に確立されることが可能である。HOが成功した後、ソースeノードBが、PDCPSNPDCPパケット伝送ステータスをターゲットeノードBに転送して、失われるパケットがないように送信ステータスを同期させることが可能である。データ分割実施形態において、対応するHO手順は、いくつかの仕方で実行され得る。HOコマンドは、複数のCCを扱うように変更され得ることに留意されたい。サービングCCおよび/または協調するCCの間でハンドオーバが行われる或る実施形態において、従来のハンドオーバに類似するハンドオーバが、実行され得る。CC協調構成は、協調構造を維持するように更新される必要がある可能性があり、さらに、ハンドオーバ先が、必要とされるサービス品質をサポートすることができない場合、協調構造は、再編成される必要があり得る。シームレスなデータ伝送が、PDCPSN同期を用いて保証され得る。ハンドオーバが協調するCCの間で行われる或る実施形態において、ソースの協調するeノードBとターゲットの協調するeノードBとの間でトンネリングが確立され得る、従来のハンドオーバ手順のサブセットが、実行されることが可能である。データ転送は、新たなトンネリングプロトコルによって、またはeノードB間の既存のGPRSトンネリングプロトコルを再使用することによって或る実施形態では、いくらかの変更を伴って扱われ得る。さらなる変更が、ハンドオーバ準備情報例えば、X2シグナリングおよびハンドオーバコマンド例えば、無線を介するRRCピアメッセージに対して実行されて、サービングCCが変わっていないことが示され得る。X2インターフェースが、eノードB間RESOURCE例えば、セル容量STATUSREQUESTおよびeノードB間RESOURCEUPDATEをサポートすることが可能である。セル容量は、UL/DLのGBR保証されたビットレート/非GBR/合計のPRB物理リソースブロック使用量のパーセンテージ、およびUL/DLS1TNLトランスポートネットワーク層負荷例えば、低/中/高/過負荷の点で、またはRLC送信バッファの中で待っていることが可能なPDCPPDUの数を示し得る新たなIEを介して、与えられることが可能である。協調するCC上の利用可能な帯域幅を推定する目的で、このことは、PDCPレベルのデータ分割に関して、かつ分割スケジューラアルゴリズムを最適化するのに十分であり得る。CC間においてサイト間で協調するデータ分割を確立するために、X2インターフェースが、いくつかの仕方で扱われることが可能である。初期確立は、部分的ハンドオーバとして扱われることが可能であり、その場合、ハンドオーバ準備情報メッセージが使用され得る。或る実施形態では、この目的で新たなX2シグナリングプロトコルを作成することは必要ない可能性がある。或る実施形態では、ソースeノードBが、協調的な伝送をサポートするリソース例えば、PDCP/RLC/MACを割り当てるようターゲットeノードBに要求する新たなX2シグナリングメッセージが、作成され得る。そのようなメッセージは、何らかの最低限のデータレートおよびQoSをサポートするのに十分な情報を伝送することが可能である。図4および図5に示されるアーキテクチャおよび構成は、PDCP層以外においてデータ分割を実行する実施形態を含め、本明細書で開示される任意の実施形態で使用され得ることに留意されたい。或る実施形態では、データ分割は、RLC層において実行され得る。そのような実施形態において、AM確認応答モードモードベアラが構成され得るが、本明細書で説明される開示は、他のモードのベアラで実施されてもよい。データ分割は、より上位の層から受け取られたデータの単一のストリームをデータの複数のストリームに分割することによって実現され得る。分割されたデータの各ストリームは、本明細書でフローと呼ばれ得る。各フローは、3GPP標準文書において現在定義される、RLCエンティティと同様であり得る。各フローは、シーケンス番号を有するSDUサービスデータ単位としてデバイス例えば、eノードBに入力されることが可能であり、さらにSDUのストリームとしてデバイスから出力されることが可能である。デバイス内で、SDUは、PDUプロトコルデータ単位に細分されることが可能であり、さらにピアノード上で再組立てされることが可能である。送信側エンティティ上で、RLC層において実行されるさらなる機能には、データを1つまたは複数のフローに分割することを担うデータ分割エンティティが含まれ得る。送信側の各フローは、RLCの現行のバージョンと機能的に均等である。データ分割エンティティは、データ分割エンティティがより上位の層から受け取るすべてのSDUが、それらのSDUのいくつかがCC上でeノードBに送られる場合でも、バッファリングされることを確実にして、例えば、無線に伝送障害が存在する場合、またはCCのうちの1つとUEとの間に他の何らかの問題が存在する場合、データが再送され得るようにすることが可能である。受信側エンティティ上で、フローは、フローエンティティがSDUを並べ替えることを扱わない可能性があることを除いて、現行のRLC機能と同様である。この機能は、データマージエンティティによって実行され得る。データマージエンティティは、1つまたは複数のフローから入力を受信することが可能であり、さらにSDUをバッファリングし、並べ替えてから、それらのSDUをより上位の層に送ることが可能である。図6は、RLC層においてULデータ分割を実行する方法600を示す。ブロック605で、UE上のRLCエンティティは、PDCPからSDUを受信することが可能である。ブロック610で、データ分割が構成されるかどうかについての判定が行われる。データ分割が構成されずに、ブロック615で、RLCが、バッファ情報でMAC層を更新し、さらにMACからのデータ要求を待つことが可能である。データ分割が構成される場合、ブロック620で、データは、UE上に存在するデータ分割エンティティに供給され得る。ブロック625で、データ分割エンティティが、そのデータを複数のフローに分割することが可能であるただし、各フローはそれ自体、RLCAMエンティティのように振舞うことが可能である。データがどのように分割されるべきかの決定は、MACからの入力に基づく各CC上で利用可能な帯域幅、および各フロー上の現在のバッファステータスを含め、複数の要因に基づくことが可能である。データが、各CCに関するフローに分割されると、ブロック630で、MACに関するバッファ占有率情報が更新されることが可能であり、さらにMACエンティティが、無線で送信するためのデータのスケジューリングを決定することが可能である。MACスケジューラが、複数のフローの概念に対処するように変更され得る。ブロック635で、MACスケジューラエンティティが、各フローからデータを選択し、さらに、選択されたデータを、Iu無線インターフェースを介して宛先eノードBに送信するためにPHYに転送することが可能である。eノードBにおいて各フロー上でデータを受信すると、ブロック640で、適切な制御メッセージが、そのデータに確認応答するために、または再送を要求するために、同一のフロー上でUEとeノードBとの間で交換される。PDUが組み立てられてSDUにされると、すべてのフローは、所与のUEに関するEPC拡張パケットコアネットワークに対する接続を有する一次eノードBに送信され得ることに留意されたい。これらのフローは独立に振舞うので、任意のRLC制御情報再送要求、リセットなどが、所与のフローを扱っている適切なエンティティによって扱われることが可能である。正しいエンティティが制御情報を扱っているため、再送要求を扱う際の待ち時間が短縮され得る。他のRLCエンティティからのフローを受け取る一次eノードB上のRLCエンティティが、データをマージ機能またはマージエンティティに供給する。マージエンティティは、受け取られたデータをマージすること、およびそのデータが、PDCPに供給される前に、順序どおりになっていることを確実にすることを担う。図7は、RLC層データ分割が実行される或る実施形態に従って使用され得る例示的なデータフローおよびアーキテクチャを示す。UE730が、PDCP層739においてデータを受け取り、そのデータをRLC層737に供給することが可能である。RLC層737で、データ分割エンティティ736が、データを、MAC735に供給されるフロー731と732に分割する。データ分割エンティティ736は、データを別々のフローに分割すると、RLCSDUを追跡することが可能である。MAC735が、異なるCCを介してデータの別々の部分をフロー731および732としてeノードB710およびeノードB720に送信することが可能なPHY734に供給することが可能である。eノードB720が、PHY724でデータを受信して、そのデータをMAC725に供給することが可能であり、MAC725は、フロー732のデータをRLC727に供給する。次に、RLC727が、フローデータを、トンネル740を介してeノードB710に供給することが可能である。eノードB710で、データフロー731が、PHY714において受信されることが可能であり、PHY714は、データフロー731をMAC715に供給することが可能であり、MAC715は、フロー731のデータをRLC717に供給する。次に、RLC717のデータマージエンティティ718が、そのデータフローをマージして、適切に順序付けられたSDUにして、さらに、もたらされたデータをPDCP719に供給することが可能であり、PDCP719は、そのデータをIPパケットとしてネットワークに送信することが可能である。データマージエンティティ718が、RLCSDUを追跡することが可能である。X2シグナリング750が、eノードB710とeノードB720との間で制御情報を交換するのに使用され得る。図8は、RLC層においてDLデータ分割を実行する方法800を示す。ブロック805で、所与のUEに関するEPCとのコンテキストを有するeノードBエンティティ上のRLCエンティティが、そのUEを宛先とするデータを受信する。CCが全く関与しない通常のモードにおいて、このことは、そのチャネルに関する合計バッファ占有率の変化をもたらし得る。ブロック810で、eノードB上のRLCエンティティが、データ分割が構成されるかどうかを決定することが可能である。構成される場合、ブロック820で、RLCエンティティが、データ分割エンティティを調べて、そのSDUがピアeノードBに送信されるべきか、またはそのSDUがローカル送信に利用可能であるかを判定することが可能である。データ分割が構成されない場合、受け取られたデータを処理することが、ブロック815で通常どおりに進められることが可能である。ブロック820で、データ分割エンティティが、ピアエンティティにおいて利用可能な帯域幅、ピアエンティティの現在のバッファステータスなどを含み得る様々な要因に基づいて、そのデータがピアRLCに送られるべきか否かを判定することが可能である。X2インターフェース上の瞬間的なバッファステータスが利用できない可能性があるので、データ分割を決定するアルゴリズムは、想定されるデータレート、または前回に報告された測定、および前回に報告された測定以来の時間に基づく予測に基づいて、分割を決定することが可能である。データがローカルフロー上ですなわち、eノードBから宛先UEに直接に送られるべき場合、バッファ占有率情報は、ブロック825で更新されるようにMACに供給されることが可能であり、さらにブロック830で、RLCは、データが要求されると、MAC層にデータを送信することが可能である。データは、ブロック835でUEに送信され得る。データが異なるeノードBに送られるべき場合、データは、ブロック840で、eノードB-eノードBトンネルを介してピアeノードBに送られることが可能である。ピアeノードB上の受信側RLCは、上位の層からデータを受け取ったとした場合と同様に振舞うことが可能である。違いは、RLC伝送ステータスフィードバック例えば、RLCバッファステータス、およびSDUについての情報は送信されないが、協調するRLCエンティティによってソースeノードB上のRLCデータ分割エンティティに転送されることである。このことは、データ分割エンティティが、障害の生じたパケットを別の利用可能なCCを介して送信すること、およびシームレスなハンドオーバのために最新のバッファステータスを維持することを可能にすることができる。各CC上のRLCエンティティは、そのRLCエンティティがMAC層に供給するバッファ占有率情報を更新することが可能である。MACエンティティは、データ利用可能性、および帯域幅利用可能性に基づいてデータ伝送をスケジュールすることが可能である。UE側で、MACからデータを受信すると、再組立て機能が、各フローに関して独立に、現行のRLC標準のとおりに実行されることが可能である。送信されなければならないRLC制御情報が存在する場合、UE側のMACが、そのデータが送信されるべきフローについて通知を受けることが可能である。SDUが形成されると、SDUは、SDUを並べ替えることを担うデータマージ機能がそのように構成されている場合データマージ機能に供給される。SDUは、RLCからPDCP層に送り出される前に順序付けられていることが可能である。並べ替えることは、SDUに追加されたシーケンス番号に基づいて、またはPDCPによって供給されるシーケンス番号に基づいて、行われ得る。図9は、RLC層データ分割が実行される或る実施形態に従って使用され得る例示的なデータフローおよびアーキテクチャを示す。eノードB910が、PDCP層919においてIPパケット990を受信して、そのデータをRLC層917に供給することが可能である。RLC層917で、データ分割エンティティ918が、そのデータをフロー931と932に分割することが可能である。データ分割エンティティ918は、フロー932がピアeノードBに送信されるべきであるのに対して、フロー931がローカルですなわち、UE930に直接に送信されるべきことを判定することが可能である。データ分割エンティティ918は、フロー931をMAC915に供給することが可能である例えば、バッファ占有率情報を更新した後、要求が行われると。データ分割エンティティ918は、データ分割エンティティ918がデータを別々のフローに分割すると、RLCSDUを追跡することが可能である。MAC915は、フロー931に関するデータをPHY914に供給することが可能であり、PHY914は、フロー931を、第1のCCを介してUE930に送信することが可能である。eノードBフロー910が、フロー932を、トンネル940を介してeノードB920に供給することが可能である。RLC層927が、フロー932をMAC925に供給することが可能である例えば、バッファ占有率情報を更新した後、要求が行われると。MAC925は、フロー932に関するデータをPHY924に供給することが可能であり、PHY924は、フロー932を、第2のCCを介してUE930に送信することが可能である。X2シグナリング950が、eノードB910とeノードB920との間で制御情報を交換するのに使用され得る。UE930で、データフロー931および932が、データフロー931および932をMAC935に供給することが可能なPHY934によって受け取られることが可能であり、MAC935は、フロー931および932のデータをRLC937に供給する。次に、RLC937のデータマージエンティティ936が、それらのデータフローをマージして、適切に順序付けられたSDUにし、さらに、もたらされるデータをPDCP939に供給し、PDCP939は、そのデータをIPパケットとしてネットワークに送信することが可能である。データマージエンティティ938は、RLCSDUを追跡することが可能である。RLC層データ分割実施形態に関して、ハンドオーバ動作は、PDCP層データ分割に関して開示された手段を含め、本明細書で開示される任意の手段または方法を使用して実行され得る。或る実施形態において、データ分割が、MAC層において実行され得る。送信バッファリングを提供することが可能な、協調するeノードB上に構成されたMACIWFにRLCパケット例えば、PDUを転送するMACIWFが、ソースeノードB上に構成され得る。MAC層データ分割は、本明細書で説明されるとおり、HSPA高速パケットアクセス構成、ならびにLTE構成およびLTE-A構成に適用されることが可能であることに留意されたい。HSPA構成において、LTE-AにおけるサービングeノードBは、HSPAにおけるサービングRNC無線ネットワークコントローラと均等であることが可能であり、さらにLTE-Aにおける協調するeノードBは、HSPAにおけるノードBまたはRNCと均等であることが可能である。図10は、MAC層データ分割が実行される或る実施形態に従って使用され得る例示的なDLデータフローおよびアーキテクチャを示す。eノードB1010は、PDCP符号化を実行し、さらにRLCバッファ層1017aおよび1017bにデータを供給することが可能なPDCP1019aおよび1019bにおいて、IPパケット1090を受け取ることが可能である。RLCバッファ1017aおよび1017bは、MAC1015にデータを供給することが可能であり、MAC1015は、適切なデータ分割を決定することが可能であり、かつデータを少なくとも2つの部分に分割する多重化エンティティ1019を含み得る。多重化エンティティ1019は、ピアeノードBに関する利用可能な帯域幅を考慮に入れることが可能であり、かつデータ多重化を実行する際にRLCPDUを転送することが可能である。ピアeノードBを使用して送られるように決定されたデータは、転送するエンティティ1018によって、eノードB間トンネル1040を介してeノードB1020に供給されることが可能である。ローカルですなわち、eノードB1010からUE1030に直接に送信されるように決定されたデータは、任意のHARQハイブリッドARQ機能を実行することが可能であり、かつ第1のCCを使用してUE1030に送信する1061ためにPHY1014にデータを転送することが可能なHARQ1016に供給されることが可能である。eノードB1020は、UE1030のためのデータを、eノードB間トンネル1040を介してeノードB1010から受信すると、eノードB間バッファ1028においてそのようなデータをバッファリングすることが可能である。バッファ1028は、多重化エンティティ1029による多重化、およびHARQエンティティ1026によって実行されるHARQ機能のために、MAC1025にデータを供給することが可能である。このデータは、第2のCCを使用してUE1030に送信される1062ようにPHY1024に供給されることが可能である。サービングeノードB1010上のMACスケジューラ1012が、協調するeノードB1020からの報告された例えば、推定された、または所定の保証される、もしくは平均の伝送などのサポーティングデータレートを、ペイロード選択アルゴリズムにおける基準として使用して、RLCPDUが送信のために協調するサイト間CCに転送されることを要求することが可能である。協調するeノードB1020におけるMACスケジューラ1022が、eノードB1020上でサポートされ得る例えば、推定された、所定の、または計算された保証される、もしくは平均の伝送などのデータレートを、定期的にサービングeノードB1010に報告して、その2つのeノードB間に接続が存在する間にサポートレートを更新することが可能である。この制御情報、および他の制御情報が、X2シグナリングインターフェース1050を介してeノードB間で交換され得る。或る実施形態において、セル無線リソースステータスごとのX2インターフェースは要求され得るが、DL/ULのGBR/非GBR/合計PRBを提供する無線リソースステータスの更新は、オプションであり得る。また、PRBステータスは、そのような情報が利用可能である場合、スケジューリング入力の代替として使用されることも可能である。また、協調するeノードB1020におけるMACスケジューラ1022が、協調するCCのための標準のペイロード選択を、eノードB間バッファ1028において利用可能なRLCPDUバッファを使用して固定サイズのPDUとして実行すること、または利用可能な無線リソースに合わせて多重化1029によってサイズ変更することも可能である。RLCPDUサイズ選択は、報告されたサポーティングデータレート、または保証されたレートに対処するようにサービングeノードBMACスケジューラ1012によって実行され得る。eノードB1010上のMACeノードB間データ転送エンティティ1018は、処理のためにPHYに、および/またはトンネル1040を介してeノードB1020に、MACデータを送ることが可能な受動的中継ユニットであり得る。協調するeノードB1020におけるMACeノードB間バッファ1028は、X2インターフェース上のデータトンネリングに起因することがあり得る可変の待ち時間に対処する、協調するeノードB1020上の一時的パーキングエリアの役割をすることが可能である。サイト間トンネル1040は、サービングeノードB1010から協調するeノードB1020にRLCPDUを転送するデータパイプであり得る。協調するeノードBごとに1つのトンネルが存在し得る。図10、およびMAC層データ分割に関連して本明細書で説明される構成およびデータフローは、システムアーキテクチャに小さい影響しか与えずに、MAC層に限定された変更だけで実施され得る。そのような変更は、最小限であることが可能であり、さらに、CoMPCoordinatedMultipointTransmission:調整されたマルチポイント伝送手順をサポートするのに要求される変更と同一である、または小さな違いしか有さないことが可能な構成変更であることが可能である。或る実施形態では、CoMP手順のいくつかは、いくらかの変更を加えて再利用されることが可能である。或る実施形態では、参加サイトに関する無線インターフェースリソース予約が、X2インターフェース遅延を低減するのに使用され得る。RLCSDUまたは順次のデリバリは、すべての関係のあるRLCPDUが正しく受信されてからでないと、RLCがRLCPDUを上位の層に送ることができないことを要求することが可能である。RLCPDUは、それぞれが他方とは異なる待ち時間を有し得る、異なる2つの物理層インターフェースを介して送信され得ることに留意されたい。したがって、受信側RLCエンティティが、さらなる入力データをバッファリングする要件が存在し得る。協調するCCは、上位層再送タイマ限度内でRLCPDUを送信する必要がある可能性がある。図10に関して説明されたのと同一のデバイスおよびエンティティを使用する、対応するULMAC層データ分割のデータフローおよびアーキテクチャが、図11に示される。図11に示される機能は、既存のLTEシグナリング構造および/またはLTE-Aシグナリング構造とほとんど、または完全に適合することが可能であるが、複数のCCに関する構成の拡張、およびネットワークからの対応するスケジューリングを含むことも可能である。正常に受信されたMACPDUを、サービングeノードB上のRLCに転送する、対応するネットワーク要件は、CoMP手順を導入するのに必要とされるものと同一であり得る。図11で、データが、UE1030上のRLCバッファ1037aおよび1037bにおいて受信されることが可能であり、かつデータ分割を決定して、別々のCC1063および1064上でeノードB1010および1020にそれぞれ送信するためにPHY1034にデータを供給することが可能なMAC多重化エンティティ1039に供給されることが可能である。優先度処理データが、MAC多重化エンティティ1039によって使用され得る。そのようなデータは、優先度処理エンティティ1032とMACスケジューラ1012および1022との間で交換され得る。UE1030からデータを直接に受信すると、eノードB1010のPHY1014は、そのデータをMAC1015に供給することが可能であり、MAC1015は、HARQ機能を実行し、かつデータを多重化エンティティ1019に供給することが可能である。多重化エンティティ1019は、そのデータと、トンネル1040を介してeノードB1020から受信されたデータを逆多重化することが可能である。UE1030からデータを直接に受信すると、eノードB1020のPHY1024は、データをMAC1025に供給することが可能であり、MAC1025は、HARQ機能を実行し、かつデータを多重化エンティティ1029に供給することが可能であり、多重化エンティティ1029は、そのデータを逆多重化して、そのデータを、トンネル1040を介してeノードB1010に供給することが可能である。逆多重化の後、データは、RLCバッファ1017aおよび1017b、PDCP復号器1019aおよび1019bに供給されることが可能であり、さらにその後、IPパケット1091としてネットワークに送信されることが可能である。バッファステータス1073および1074が、UE1030によってMACスケジューラ1012および1022にそれぞれ供給されることが可能である。MAC層データ分割実施形態において、LTER8によってサポートされる基本的なハンドオーバフィーチャが、協調構造を再編成すること、および/または保持することをサポートする構成、およびX2シグナリングインターフェース上の部分的ハンドオーバのサポートの追加で、本明細書で説明されるハンドオーバをサポートすることが可能である。サービングCC、または協調するCCの部分的ハンドオーバは、eノードB間のさらなるデータパスの確立を使用することが可能である。パス確立中、またはパス再確立中に失われたMACパケットは、RLCレベルの再送RLCは常にサービングCC上にあり、移動していない可能性があるので、協調するCCハンドオーバに関して、またはPDCP再送PDCP送信ステータスはターゲットセルに転送されるので、サービングハンドオーバに関してで自律的に処理され得るので、データコピーの必要は全くない可能性がある。X2ハンドオーバシグナルインターフェースが、RRC層によって定義されたハンドオーバ準備情報をカプセル化することが可能である。したがって、部分的ハンドオーバを通信することのシグナリング問題は、ハンドオーバ準備情報の中で協調構造のコンテキストを供給するようにRRCハンドオーバメッセージを変更することで、対処され得る。或る実施形態では、ユーザプレーンデータ分割が、例示的なシステムにおいて実施されることが可能である。PDCP層、RLC層、MAC層、またはサービングゲートウェイデータ分割において、または上記、および/もしくは本明細書で開示される他の任意の手段のうちの任意の手段の任意の組合せを使用するシステムにおいて、効率的なデータ分割決定のために、サービングeノードBが、利用可能なリソース、および遠隔のeノードBからのローカルスケジューリング情報を考慮に入れる必要がある可能性がある。RANデータ分割実施形態において、専用のインターワーキング機能が、X2リンクによってもたらされる遅延を軽減するようにダウンリンクフレームをバッファリングするのに使用され得る。サービングeノードBは、X2遅延を考慮に入れることが可能であり、RANデータ分割の代わりにS-GWサービングゲートウェイデータ分割を開始することによって、X2待ち時間を低減することが可能である。データ分割が使用されるべきことを決定すると、サービングeノードBは、データを分割することを始めるようサービングゲートウェイに命令する制御信号を、サービングゲートウェイに送信することが可能である。或る実施形態では、X2インターフェース上のユーザプレーン負荷が、サービングゲートウェイにおいてデータ分割が行われることを許すフレームワークを構築すること、およびキャリア固有のハンドオーバを許すようにLTER8ハンドオーバを拡張することによって、低減され得る。そのような実施形態を実施するために、サービングeノードBが、サービングゲートウェイにキャリア固有のハンドオーバ決定を通知することを許し、さらにサービングゲートウェイが、UEトラフィックをキャリア固有の仕方で分割することを可能にするメッセージシーケンスが、使用され得る。キャリア固有のハンドオーバを実施する実施形態において、eノードB-MMEメッセージングは、影響を受けるRAB無線アクセスベアラのリストのハンドオーバの通知をサポートし、かつMMEがキャリア固有のPATH_SWITCH_REQUESTメッセージをサポートすることを要求するように、拡張され得る。例えば、UE350が位置311にある場合に2つのeノードBに接続され得る、図3に示される或る実施形態では、適切なRRCシグナリングが、分割されたRRC接続をサポートするのに必要とされ得る。一部の実施形態では、UEに関して活性状態への遷移が完了すると、またはターゲットeノードBにおいて、ハンドオーバ準備中にハンドオーバリソース割当てが完了した後、eノードBUEコンテキストが確立されることが可能である。eノードBUEコンテキストは、1つの活性のUEに関連するeノードBにおける情報のブロックであり得る。この情報のブロックは、活性のUEに向けたE-UTRANサービスを維持するのに要求される必要な情報を含み得る。UE状態情報、セキュリティ情報、UE能力情報、およびUEに関連する論理S1接続のIDが、eノードBUEコンテキストの中に含められることが可能である。或る実施形態では、ユーザプレーンデータ分割が、図12に示されるサービングゲートウェイにおいて実行され得る。IPパケット405が、PDNパケットデータネットワークゲートウェイ1210において受信され、かつサービングゲートウェイ1220に送信されることが可能である。サービングゲートウェイ1220が、そのデータを分割し、さらにそのデータの一部分を、S1ベアラ1251を介してeノードB1230に送信し、さらにそのデータのその他の部分を、S1ベアラ1252を介してeノードB1240に送信することが可能である。次に、eノードB1230および1240が、そのデータを、無線ベアラを介してUE1270に送信することが可能である。確認応答されていないPDCPSDU1261および1262が、eノードB間で転送されて、ロスレスlosslessハンドオーバを許すことが可能である。サービングゲートウェイにおける個々のCCに関連するベアラのデータ分割が、eノードBからの入力、および/またはサービングゲートウェイ上で実行される負荷分散アルゴリズムに基づいて可能にされ得る。単一のコンポーネントキャリアが、HARQエンティティに関連することが可能である。複数の論理チャネルが、異なるコンポーネントキャリアにトランスペアレントにマップされることが可能である。CCが1つのeノードBソースから別のeノードBターゲットにハンドオーバされる際、ソースeノードBは、サービングゲートウェイに関連するMMEに直接に、またはターゲットeノードBを介して、コンポーネントキャリア上で伝送されていた無線ベアラを通知することが可能である。このことは、ソースeノードBから、サービングゲートウェイに関連するMMEに送信されるべきメッセージを作成することによって、またはパススイッチ要求メッセージを拡張することによって、達成することが可能である。新たなGTPGPRSトンネリングプロトコルトンネルエンドポイントに向けてのダウンリンクGTPの切換えを要求するパス切換えメッセージが、eノードBとMMEとの間で交換されることが可能である。パス切換えメッセージは、ソースeノードBからターゲットeノードBに切り換えられる必要があるすべてのE-RABEUTRANRABのリストであることが可能なダウンリンクリストIE情報要素の中の切り換えられるべきE-RABを伝送することが可能である。PATHSWICHREQUESTメッセージ内のダウンリンクリストIEの中で切り換えられるべきE-RABが、UEコンテキストの中にそれまでに含まれていたすべてのE-RABを含まない可能性がある場合、MMEは、含まれていないE-RABを、eノードBによって暗黙に解放されたものと考えることが可能である。キャリア固有のハンドオーバをサポートするのに、パススイッチ要求または代替のメッセージが、切り換えられる必要があるRABのリストを伝送することが可能である。しかし、MMEおよびサービングゲートウェイは、残りのトラフィックを、それまでと同様にソースeノードBに転送することを続けることが可能である。eノードBは、S-GWサービングゲートウェイにおけるデータの分割をどのように要求するかを決定することが可能である。或る実施形態では、eノードBは、RABレベルにおけるデータ分割を要求することが可能であり、その場合、パス切換えメッセージは、分割される必要があるすべてのRABのリストを含み得る。eノードBがRABレベルでデータを分割することを望まない場合、eノードBは、新たなeノードBにリダイレクトされるべきトラフィックのパーセンテージを有するインジケータを送ることが可能である。或る実施形態では、保つべきRABリストが、より古い機器との潜在的な適合性問題または解釈問題を回避するのに使用され得る。また、サービングeノードBは、ルーティングアルゴリズムを実施して、MMEが利用できない可能性があるAS情報に基づいて、最適なRAB/RBマッピングを決定することも可能である。MME/S-GWが、eノードBによって示唆されるとおりのデータ分割ルーティング、または代替のデータ分割ルーティングを採用することを決定する場合に、ルーティング示唆をもたらすオプションのIEが、PATHSWITCHREQUESTの中に含められてもよい。データ分割ルーティングを決める決定に対するいくつかの潜在的な能動的な入力には、RB/RAB分割割当て特定のeノードBMACアドレスに対するRAB/RBのマッピング、データ分割のパーセンテージ、およびその他の入力が含まれ得る。無線ベアラからの部分的データが、コンポーネントキャリア上で送られることが可能であり、さらにこのことが、サービングゲートウェイに、同様の構成をミラーリングするようにトラフィックを分割するオプションを許す特別なインジケータによって示されることが可能である。この特別なインジケータは、1回限りのイベントであること、またはチャネル品質測定に基づいて分割比を変更する、サービングeノードBからS-GW/MMEへの定期的通知であることが可能である。MME/S-GWが、eノードBによって与えられるステータス入力に基づいてデータフロー分割決定を行うのに使用される何らかのルーティングインテリジェンスを実施することが可能である。そのような入力には、利用可能なeノードB例えば、PDCPバッファ、平均伝送待ち時間例えば、UE上の、または特定のRAB/RBごとの、サポート可能なトラフィック負荷分散例えば、eノードBごとの負荷、およびその他が含まれ得る。S-GWから送られるパケットは、GTPトンネルにおいてカプセル化されたIPトラフィックであることが可能であり、さらに、単一のE-RABIDに関して、1つはソースeノードBに終端し、もう1つはターゲットeノードBに終端する2つのGTPトンネルの作成を要求することが可能であることに留意されたい。このことは、無線ベアラマッピングに1対1RABを規定する一部の実施とは異なり得る。或る実施形態では、UEは、セキュリティ情報およびNAS情報を提供する1つの特別なセルを有するネットワークに対する1つのRRC接続を有することが可能である。図3を再び参照すると、起動時に、位置311にあるUE350が、eノードB361に対するRRC接続、ならびにCC320およびCC330Bという確立されたコンポーネントキャリアセットに関連する。このため、UE350は、eノードB361におけるサービングセルまたは特別なセルに関連することが可能であり、かつサービングセルハンドオーバが行われるまで、eノードB361からセキュリティ情報およびNAS移動性情報を獲得することが可能である。CC330がサービングセルである協調的なコンポーネントキャリア展開において移動性をサポートするために、UE350が位置311に移動することが、RRC接続再構成を使用してシグナリングされるRRC接続ハンドオーバを生じさせることが可能であり、かつ新たなセキュリティパラメータを考慮に入れるようにMAC/RLC層のリセットを生じさせることが可能である。CC330がサービングセルではない或る実施形態において、UE350は、UE350が位置310から位置311に移動する際に、eノードB361に対するUE350のRRC接続を維持することが可能である。セキュリティ手順は、後段で説明されるとおり、ハンドオーバのためのさらなる機構を必要とする可能性がある。UEに関する活性状態への遷移が完了すると、またはターゲットeノードBにおいてハンドオーバ準備中のハンドオーバリソース割当ての完了の後、eノードBUEコンテキストが確立され得る。或る実施形態では、ハンドオーバ手順は、ソースeノードBから送られた{KeNB,NCC}ペアから導き出された、暗号化および暗号化アルゴリズムのための新規の鍵を生成するよう、ターゲットeノードBおよびUEをトリガすることが可能である。ターゲットeノードBは、このタプルを使用して新規のKeNBを生成することが可能である。KUPenc鍵KeNBから導き出されたが、特定の暗号化アルゴリズムを用いたユーザプレーントラフィックの保護のために使用され得る。図3のUE350が、例えば、位置310から位置311に移動するに際に、ソースeノードB361とのRRC接続を維持する或る実施形態において、ターゲットeノードB362において実行されているPDCPエンティティは、ソースeノードB361と同一の鍵を使用し続ける必要がある可能性がある。このことは、UEが、異なる複数のeノードBからPDCPエンティティを同時に受信することを許す可能性がある。これらの鍵は、ソースeノードBからターゲットeノードBへのハンドオーバのハンドオーバ準備段階におけるハンドオーバコマンドで交換されることが可能である。或る実施形態では、この情報は、S-GWからの初期コンテキストセットアップ中に伝えられることが可能である。或る実施形態では、電力ヘッドルーム、バッファステータスレポート、およびチャネル品質レポートを含むアップリンクレポートが、ターゲットeノードBにおいて利用できる可能性があり、さらにX2-APを介してソースeノードBからターゲットeノードBに転送されることが可能であり、またはUEが、それらのレポートを2つのeノードBに別々に送ることが可能である。後方互換性をもたらすために、UEは、サービングセルに関するレポートをサービングeノードBに送ることが可能である。しかし、このことは、ターゲットeノードBにおけるスケジューラに関する入力の利用可能性に遅延を生じさせる可能性があり、このことは、一部の実施で、最適でないスケジューリング決定をもたらし得る。キャリア集約を用いるLTE-Aにおいてハンドオーバを適切にサポートするために、キャリア固有のRSRPおよび/またはRSRQを含め、キャリアごとのUE測定、および集約されたダウンリンクキャリアを介する報告が定義される必要がある可能性がある。LTER8機構は、測定がサービングセルに基づくことが可能であるため、周波数内測定をサポートしない可能性がある。例えば、eノードBが、3つのキャリアF1、F2、およびF3を所有することが可能であり、さらにF1およびF2を使用していることが可能であり、さらにF1がサービングセルであることが可能である。F3の信号品質がF2より良好である場合、UEがこの状況を報告することができるように、この状況を扱う測定スキームを有することが望ましい可能性がある。一部の実施において、非サービングセルからの測定を含む、キャリア固有の測定が、所望される可能性がある。特徴および要素は、特定の組合せによって上記で説明されるものの、各特徴または各要素は、単独で使用されることも、その他の特徴および要素との任意の組合せで使用されることも可能であることが、当業者には認識されよう。さらに、本明細書で説明される方法は、コンピュータまたはプロセッサによって実行されるようにコンピュータ可読媒体に組み込まれたコンピュータプログラム、ソフトウェア、またはファームウェアにおいて実施され得る。コンピュータ可読媒体の例には、電子信号有線接続またはワイヤレス接続を介して伝送されるおよびコンピュータ可読記憶媒体が含まれる。コンピュータ可読記憶媒体の例には、ROM読み取り専用メモリ、RAMランダムアクセスメモリ、レジスタ、キャッシュメモリ、半導体メモリデバイス、内部ハードディスクやリムーバブルディスクなどの磁気媒体、光磁気媒体、ならびにCD-ROMディスクおよびDVDデジタルバーサタイルディスクなどの光媒体が含まれるが、これらに限定されない。ソフトウェアに関連するプロセッサが、WTRU、UE、端末装置、基地局、RNC、または任意のホストコンピュータにおいて使用するための無線周波数トランシーバを実施するのに使用され得る。"