JP2019506055A - 無線送信／受信ユニット協調のための方法、システム、およびデバイス - Google Patents

Abstract

第１の共有段階および第２の協調的段階を含む２段階協調を使用してデータを送信するための方法が提供される。実施形態においては、第１のＷＴＲＵによって実行される協調的データ送信のための方法が開示される。この方法は、協調的セット識別情報を含む協調的セット構成情報を第１のＷＴＲＵによってｅＮＢから受信することを含む。共有段階において、第１のＷＴＲＵは、第１のデータ送信のためのリソース割り当てをｅＮＢから受信してもよい。共有段階の間に、第１のデータ送信は、受信されたリソース割り当てにおいて示されているリソースを使用して送信されてもよい。共有段階の間に第２のＷＴＲＵから第２のデータ送信が受信されてもよい。第２のデータ送信が第１のＷＴＲＵによって成功して受信されることを条件に、第３のデータ送信が、協調的段階の間に第２のＷＴＲＵと協調して送信されてもよい。

Description

本発明は、無線通信の分野に関する。

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

モバイル通信は、継続的な進化の中にあり、既に第５世代（５Ｇ）の時代の入口にいる。以前の世代と同様に、新たなシステムに関する要件を設定する際には、新たな使用事例が大いに寄与する。将来のネットワークは、地理的エリア全体にわたる均一なユーザ経験に重点を置いて設計されることがある。そのようなユーザ経験は、均一な達成可能なスループット、待ち時間、および／または信頼性によって示されることがある。

均一な経験の問題に関して、不十分なカバレッジエリア内の無線送信／受信ユニット（ＷＴＲＵ）は、繰り返し（repetition）を使用して、性能を改善することがある。しかしながら、繰り返しは、達成可能なスループットを劣化させ、全体的な待ち時間を増大させる。これは、繰り返しを行うＷＴＲＵが、その他の所での使用のために利用可能にされていた可能性があるさらなるリソースを使用しなければならない事実に少なくとも部分的に起因する。加えて、繰り返しを行うＷＴＲＵによって使用されるさらなるリソースは、貧弱なカバレッジエリア内でそのＷＴＲＵが成功して再送信することに再び失敗する高い可能性に起因して、最良の形では費やされない。

無線センサまたは大規模低コストマシンタイプ通信（ＬＣ−ＭＴＣ）デバイスなどの低電力ノードに関しては、そのデバイスのバッテリが、長く、例えば何年ももつことが望ましい。繰り返しは、バッテリを時期尚早に枯渇させて、ＬＣ−ＭＴＣデバイスを到達不能にさせることがあり、または送信を継続できなくさせることがある。さらに、将来のネットワークは、ＷＴＲＵの非常に高い密度を有することがある。例えば、センサネットワーク展開、ウェアラブル、または特定の機会において、例えば、満員のスタジアムのシナリオは、ＷＴＲＵの高密度のレイヤにつながることがある。その一方で、極端な郊外のシナリオが存在し、そこでは、基地局展開は最小となることがある、遠くに分散されることがある。郊外のシナリオは、モバイルオペレータにとって有益となることがある。なぜなら、低い展開コストがビジネス目標でとなる場合があるからである。

展開されているＷＴＲＵの高い密度を活用して、送信または受信経験の均一性を改善する方法は、有益となることがある。加えて、展開されているＷＴＲＵの高い密度の特有の特徴を利用することは、ＷＴＲＵの経験をより均一にすることを超える利点につながることがある。例えば、満員のスタジアムにおける大規模ブロードバンドの例においては、多くのＷＴＲＵへ送信されるデータが非常に類似していることがある。そのようなシナリオにおいては、複数のＷＴＲＵが接近して配置されることの利点を使用して、全体的な性能を改善することが望ましい場合がある。

上記を考慮すると、よりユーザ中心（user-centric）の展開が有益となることがある。そのようなユーザ中心の展開は、特別となることがあり、一実施形態においては、ＷＴＲＵにとってのトランスペアレントな方式での複数セル協調（multiple cells cooperating）として、または協調した複数のＷＴＲＵとして示されることがある。ＷＴＲＵ協調（WTRU cooperation）は、接近して配置されているＷＴＲＵのクラスタが、分散アンテナアレイとして機能することによって個々の性能を改善することを可能にすることがある。したがって、ＷＴＲＵ協調は、セルエッジＷＴＲＵ性能を改善すること、全体的なバッテリ枯渇を制限すること、そしてまた大規模ブロードバンド送信を改善することによって、ＷＴＲＵの密集したクラスタの利点を利用するのを支援することがある。同一データのさらに多くのコピーが存在することがある、ネットワーク内で共有されることがあるので、データ冗長性も改善されることがある。

有益なＷＴＲＵ協調を達成するために、本明細書において開示されている実施形態は、ＷＴＲＵの適切なセットがどのようにして協調することができるかを決定するための方法を提供する。さらに、適切な協調は、複数のＷＴＲＵが自身のデータを効率よく共有すること、例えば、発展型Ｎｏｄｅ Ｂ（ｅＮＢ）からの受信されたデータの共有、またはそれぞれのＷＴＲＵによってｅＮＢへ送信されることになるデータの共有を必要とすることがある。効率的な協調的ＷＴＲＵ送信を実施するための方法およびシステムも扱われる。

共有段階（sharing phase）および協調的段階（cooperative phase）を含む２段階協調を使用してデータを送信するための方法が提供される。この方法は、共有段階において、無線送信／受信ユニット（ＷＴＲＵ）の協調セット（cooperating set）の間でデータを共有することと、協調的段階において、ＷＴＲＵの協調セットによって宛先ノードへデータを協調的に送信することとを含む。

別の例においては、２段階協調を使用してデータを送信するための方法は、協調的段階において、ＷＴＲＵの協調セットによってソースノードからデータを協調的に受信することと、共有段階において、ＷＴＲＵの協調セットの間でデータを共有することとを含む。

第１の共有段階および第２の協調的段階を含む２段階協調を使用してデータを送信するための方法が提供される。実施形態においては、第１のＷＴＲＵによって実行される協調的データ送信のための方法が開示される。この方法は、第１の送信段階において、協調的送信のためにデータを第１のＷＴＲＵから少なくとも１つの第２のＷＴＲＵへ送信することと、協調的送信のためにデータを送信したことに応答して、第１のＷＴＲＵによって少なくとも第２のＷＴＲＵから、データの成功した復号または不成功の復号のいずれかの確認応答を受信することとを含む。確認応答が、第２のＷＴＲＵによるデータの成功した復号を示すことを条件に、第２の送信段階において、第２のＷＴＲＵと協調してデータをｅＮＢへ再送信することが提供される。

第１のＷＴＲＵによって実行される協調的データ送信のための方法が開示される。この方法は、協調的セット識別情報を含む協調的セット構成情報を第１のＷＴＲＵによってｅＮＢから受信することを含む。共有段階において、第１のＷＴＲＵは、第１のデータ送信のためのリソース割り当てをｅＮＢから受信してもよい。共有段階の間に、第１のデータ送信は、受信されたリソース割り当てにおいて示されているリソースを使用して送信されてもよい。共有段階の間に第２のＷＴＲＵから第２のデータ送信が受信されてもよい。第２のデータ送信が第１のＷＴＲＵによって成功して受信されることを条件に、第３のデータ送信が、協調的段階の間に第２のＷＴＲＵと協調して送信されてもよい。

例として添付の図面とともに与えられる以降の説明から、より詳細な理解を得ることができる。

例示的な通信システムの図である。 図１Ａにおいて示されている通信システム内で使用することができる例示的な無線送信／受信ユニット（ＷＴＲＵ）のシステム図である。 図１Ａにおいて示されている通信システム内で使用することができる例示的な無線アクセスネットワークおよび例示的なコアネットワークのシステム図である。 アップリンク方向における協調的送信の例を示す図である。 ダウンリンク方向における協調的受信の例を示す図である。 アップリンク協調的送信における２段階協調の共有段階の例を示す図である。 アップリンク協調的送信における２段階協調の協調的段階の例を示す図である。 協調セットのＷＴＲＵが、ソースｅＮＢからの協調的受信の後に、受信されたデータを時分割多重化（ＴＤＭ）方式で共有する例を示す図である。 協調セット内のＷＴＲＵが、ソースｅＮＢからの協調的受信の後に、受信されたデータを、共同再送信（joint retransmissions）を使用して共有するために協調する例を示す図である。 ＷＴＲＵのセットが単一のソースＷＴＲＵについてのデータを送信するために協調する例を示す図である。 ＷＴＲＵが共有送信段階の間にデータを共有する例を示す図である。 図７ＡのＷＴＲＵが共有データの受信を確認しているところを示す図である。 図７ＢのＷＴＲＵのサブセットが共有データをｅＮＢへ再送信しているところを示す図である。 図７ＣのＷＴＲＵが共同送信方法（joint transmission method）を使用して共有データをｅＮＢへ重複して再送信する例を示す図である。 複数領域協調的サブフレーム（multi-region cooperative subframe）の例を示す図である。

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

図１Ａにおいて示されているように、通信システム１００は、無線送信／受信ユニット（ＷＴＲＵ）１０２ａ、１０２ｂ、１０２ｃ、１０２ｄ、無線アクセスネットワーク（ＲＡＮ）１０４、コアネットワーク１０６、公衆交換電話網（ＰＳＴＮ）１０８、インターネット１１０、およびその他のネットワーク１１２を含んでもよいが、開示されている実施形態は、任意の数のＷＴＲＵ、基地局、ネットワーク、および／またはネットワーク要素を想定していることが理解されるであろう。ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄのそれぞれは、無線環境において動作および／または通信するように構成されている任意のタイプのデバイスであってもよい。例として、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄは、無線信号を送信および／または受信するように構成されてもよく、ユーザ機器（ＵＥ）、移動局、固定式または移動式のサブスクライバユニット、ページャ、セルラー電話、携帯情報端末（ＰＤＡ）、スマートフォン、ラップトップ、ネットブック、パーソナルコンピュータ、無線センサ、家庭用電化製品などを含んでもよい。

通信システム１００はまた、基地局１１４ａおよび基地局１１４ｂを含んでもよい。基地局１１４ａ、１１４ｂのそれぞれは、１つまたは複数の通信ネットワーク、例えば、コアネットワーク１０６、インターネット１１０、および／またはその他のネットワーク１１２へのアクセスを容易にするために、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄのうちの少なくとも１つと無線にインタフェース接続するように構成されている任意のタイプのデバイスであってもよい。例として、基地局１１４ａ、１１４ｂは、ベース送受信機ステーション（ＢＴＳ）、Ｎｏｄｅ−Ｂ、ｅＮｏｄｅ Ｂ、ホームＮｏｄｅ Ｂ、ホームｅＮｏｄｅ Ｂ、サイトコントローラ、アクセスポイント（ＡＰ）、無線ルータなどであってもよい。基地局１１４ａ、１１４ｂは、それぞれ単一の要素として示されているが、基地局１１４ａ、１１４ｂは、任意の数の相互接続された基地局および／またはネットワーク要素を含んでもよいことが理解されるであろう。

基地局１１４ａは、ＲＡＮ１０４の一部であってもよく、ＲＡＮ１０４はまた、その他の基地局および／またはネットワーク要素（図示せず）、例えば、基地局コントローラ（ＢＳＣ）、無線ネットワークコントローラ（ＲＮＣ）、中継ノードなどを含んでもよい。基地局１１４ａおよび／または基地局１１４ｂは、特定の地理的領域内で無線信号を送信および／または受信するように構成されてもよく、その地理的領域は、セル（図示せず）と呼ばれてもよい。セルは、セルセクタへとさらに分割されてもよい。例えば、基地局１１４ａに関連付けられているセルは、３つのセクタへと分割されてもよい。したがって一実施形態においては、基地局１１４ａは、３つの送受信機、すなわち、セルのそれぞれのセクタごとに１つの送受信機を含んでもよい。別の実施形態においては、基地局１１４ａは、多入力多出力（ＭＩＭＯ）技術を採用してもよく、したがって、セルのそれぞれのセクタごとに複数の送受信機を利用してもよい。

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

より具体的には、上述されているように、通信システム１００は、マルチプルアクセスシステムであってもよく、１つまたは複数のチャネルアクセススキーム、例えば、ＣＤＭＡ、ＴＤＭＡ、ＦＤＭＡ、ＯＦＤＭＡ、ＳＣ−ＦＤＭＡなどを採用してもよい。例えば、ＲＡＮ１０４内の基地局１１４ａ、およびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、ユニバーサルモバイルテレコミュニケーションズシステム（ＵＭＴＳ）テレストリアルラジオアクセス（ＵＴＲＡ）などの無線技術を実施してもよく、この無線技術は、ワイドバンドＣＤＭＡ（ＷＣＤＭＡ）を使用してエアインタフェース１１６を確立してもよい。ＷＣＤＭＡは、ハイスピードパケットアクセス（ＨＳＰＡ）および／またはエボルブドＨＳＰＡ（ＨＳＰＡ＋）などの通信プロトコルを含んでもよい。ＨＳＰＡは、ハイスピードダウンリンクパケットアクセス（ＨＳＤＰＡ）および／またはハイスピードアップリンクパケットアクセス（ＨＳＵＰＡ）を含んでもよい。

別の実施形態においては、基地局１１４ａおよびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、エボルブドＵＭＴＳテレストリアルラジオアクセス（Ｅ−ＵＴＲＡ）などの無線技術を実施してもよく、この無線技術は、ロングタームエボリューション（ＬＴＥ）および／またはＬＴＥアドバンスト（ＬＴＥ−Ａ）を使用してエアインタフェース１１６を確立してもよい。

その他の実施形態においては、基地局１１４ａおよびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、無線技術、例えば、ＩＥＥＥ ８０２．１６（すなわち、Ｗｏｒｌｄｗｉｄｅ Ｉｎｔｅｒｏｐｅｒａｂｉｌｉｔｙ ｆｏｒ Ｍｉｃｒｏｗａｖｅ Ａｃｃｅｓｓ（ＷｉＭＡＸ））、ＣＤＭＡ２０００、ＣＤＭＡ２０００ １Ｘ、ＣＤＭＡ２０００ ＥＶ−ＤＯ、Ｉｎｔｅｒｉｍ Ｓｔａｎｄａｒｄ ２０００（ＩＳ−２０００）、Ｉｎｔｅｒｉｍ Ｓｔａｎｄａｒｄ ９５（ＩＳ−９５）、Ｉｎｔｅｒｉｍ Ｓｔａｎｄａｒｄ ８５６（ＩＳ−８５６）、Ｇｌｏｂａｌ Ｓｙｓｔｅｍ ｆｏｒ Ｍｏｂｉｌｅ ｃｏｍｍｕｎｉｃａｔｉｏｎｓ（ＧＳＭ）、Ｅｎｈａｎｃｅｄ Ｄａｔａ ｒａｔｅｓ ｆｏｒ ＧＳＭ Ｅｖｏｌｕｔｉｏｎ（ＥＤＧＥ）、ＧＳＭ ＥＤＧＥ（ＧＥＲＡＮ）などを実施してもよい。

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

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

コアネットワーク１０６はまた、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄがＰＳＴＮ１０８、インターネット１１０、および／またはその他のネットワーク１１２にアクセスするためのゲートウェイとしての役割を果たしてもよい。ＰＳＴＮ１０８は、旧来型電話サービス（ＰＯＴＳ）を提供する回線交換電話ネットワークを含んでもよい。インターネット１１０は、一般的な通信プロトコル、例えば、トランスミッション制御プロトコル（ＴＣＰ）／インターネットプロトコル（ＩＰ）インターネットプロトコルスイートにおけるＴＣＰ、ユーザデータグラムプロトコル（ＵＤＰ）、およびＩＰを使用する相互接続されたコンピュータネットワークおよびデバイスからなるグローバルシステムを含んでもよい。ネットワーク１１２は、その他のサービスプロバイダによって所有および／または運営されている有線または無線の通信ネットワークを含んでもよい。例えば、ネットワーク１１２は、ＲＡＮ１０４と同一ＲＡＴまたは異なるＲＡＴを採用してもよい１つまたは複数のＲＡＮに接続されている別のコアネットワークを含んでもよい。

通信システム１００内のＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄのうちのいくつかまたは全ては、マルチモード機能を含んでもよく、すなわち、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄは、別々の無線リンクを介して別々の無線ネットワークと通信するために複数の送受信機を含んでもよい。例えば、図１Ａにおいて示されているＷＴＲＵ１０２ｃは、セルラーベースの無線技術を採用することができる基地局１１４ａと、およびＩＥＥＥ ８０２無線技術を採用することができる基地局１１４ｂと通信するように構成されてもよい。

図１Ｂは、例示的なＷＴＲＵ１０２のシステム図である。図１Ｂにおいて示されているように、ＷＴＲＵ１０２は、プロセッサ１１８、送受信機１２０、送信／受信要素１２２、スピーカ／マイクロフォン１２４、キーパッド１２６、ディスプレイ／タッチパッド１２８、取り外し不能メモリ１３０、取り外し可能メモリ１３２、電源１３４、グローバルポジショニングシステム（ＧＰＳ）チップセット１３６、およびその他の周辺機器１３８を含んでもよい。ＷＴＲＵ１０２は、実施形態との整合性を維持しながら、上述の要素の任意の下位組合せを含んでもよいことが理解されるであろう。

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

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

加えて、送信／受信要素１２２は、図１Ｂにおいては単一の要素として示されているが、ＷＴＲＵ１０２は、任意の数の送信／受信要素１２２を含んでもよい。より具体的には、ＷＴＲＵ１０２は、ＭＩＭＯ技術を採用してもよい。したがって、一実施形態においては、ＷＴＲＵ１０２は、エアインタフェース１１６を介して無線信号を送信および受信するために、複数の送信／受信要素１２２（例えば、複数のアンテナ）を含んでもよい。

送受信機１２０は、送信／受信要素１２２によって送信されることになる信号を変調するように、および送信／受信要素１２２によって受信される信号を復調するように構成されてもよい。上述されているように、ＷＴＲＵ１０２は、マルチモード機能を有してもよい。したがって送受信機１２０は、ＷＴＲＵ１０２が、例えばＵＴＲＡおよびＩＥＥＥ ８０２．１１などの複数のＲＡＴを介して通信することを可能にするために複数の送受信機を含んでもよい。

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

プロセッサ１１８は、電源１３４から電力を受信してもよく、ＷＴＲＵ１０２内のその他のコンポーネントへの電力を分配および／または制御するように構成されてもよい。電源１３４は、ＷＴＲＵ１０２に電力供給するための任意の適切なデバイスであってもよい。例えば、電源１３４は、１つまたは複数の乾電池（例えば、ニッケルカドミウム（ＮｉＣｄ）、ニッケル亜鉛（ＮｉＺｎ）、ニッケル水素（ＮｉＭＨ）、リチウムイオン（Ｌｉ−ｉｏｎ）など）、太陽電池、燃料電池などを含んでもよい。

プロセッサ１１８はまた、ＧＰＳチップセット１３６に結合されてもよく、ＧＰＳチップセット１３６は、ＷＴＲＵ１０２の現在の位置に関する位置情報（例えば、経度および緯度）を提供するように構成されてもよい。ＷＴＲＵ１０２は、ＧＰＳチップセット１３６からの情報に加えて、またはその情報の代わりに、基地局（例えば、基地局１１４ａ、１１４ｂ）からエアインタフェース１１６を介して位置情報を受信してもよく、および／または複数の近隣の基地局から受信されている信号のタイミングに基づいて自身の位置を決定してもよい。ＷＴＲＵ１０２は、実施形態との整合性を維持しながら、任意の適切な位置決定方法を通じて位置情報を取得してもよいことが理解されるであろう。

プロセッサ１１８は、その他の周辺機器１３８にさらに結合されてもよく、その他の周辺機器１３８は、さらなる特徴、機能、および／または有線接続もしくは無線接続を提供する１つまたは複数のソフトウェアモジュールおよび／またはハードウェアモジュールを含んでもよい。例えば、周辺機器１３８は、加速度計、ｅコンパス、衛星送受信機、デジタルカメラ（写真またはビデオ用）、ユニバーサルシリアルバス（ＵＳＢ）ポート、振動デバイス、テレビジョン送受信機、ハンドフリーヘッドセット、Ｂｌｕｅｔｏｏｔｈ（登録商標）モジュール、周波数変調（ＦＭ）ラジオユニット、デジタルミュージックプレーヤ、メディアプレーヤ、ビデオゲームプレーヤモジュール、インターネットブラウザなどを含んでもよい。

図１Ｃは、実施形態によるＲＡＮ１０４およびコアネットワーク１０６のシステム図である。上述されているように、ＲＡＮ１０４は、エアインタフェース１１６を介してＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信するためにＥ−ＵＴＲＡ無線技術を採用してもよい。ＲＡＮ１０４はまた、コアネットワーク１０６と通信状態にあってもよい。

ＲＡＮ１０４は、ｅＮｏｄｅ−Ｂ１４０ａ、１４０ｂ、１４０ｃを含んでもよいが、ＲＡＮ１０４は、実施形態との整合性を維持しながら、任意の数のｅＮｏｄｅ−Ｂを含んでもよいことが理解されるであろう。ｅＮｏｄｅ−Ｂ１４０ａ、１４０ｂ、１４０ｃはそれぞれ、エアインタフェース１１６を介してＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信するために１つまたは複数の送受信機を含んでもよい。一実施形態においては、ｅＮｏｄｅ−Ｂ１４０ａ、１４０ｂ、１４０ｃは、ＭＩＭＯ技術を実施してもよい。したがって、ｅＮｏｄｅ−Ｂ１４０ａは、例えば、ＷＴＲＵ１０２ａに無線信号を送信するために、およびＷＴＲＵ１０２ａから無線信号を受信するために、複数のアンテナを使用してもよい。

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

図１Ｃにおいて示されているコアネットワーク１０６は、モビリティ管理エンティティゲートウェイ（ＭＭＥ）１４２、サービングゲートウェイ１４４、およびパケットデータネットワーク（ＰＤＮ）ゲートウェイ１４６を含んでもよい。上述の要素のうちのそれぞれは、コアネットワーク１０６の一部として示されているが、これらの要素のうちのいずれかの要素が、コアネットワークオペレータ以外のエンティティによって所有および／または運営されてもよいことが理解されるであろう。

ＭＭＥ１４２は、Ｓ１インタフェースを介してＲＡＮ１０４内のｅＮｏｄｅ−Ｂ１４０ａ、１４０ｂ、１４０ｃのそれぞれに接続されてもよく、制御ノードとしての役割を果たしてもよい。例えば、ＭＭＥ１４２は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのユーザを認証すること、ベアラのアクティブ化／非アクティブ化、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃの最初の接続の間に特定のサービングゲートウェイを選択することなどを担当してもよい。ＭＭＥ１４２はまた、ＲＡＮ１０４と、ＧＳＭまたはＷＣＤＭＡなどのその他の無線技術を採用しているその他のＲＡＮ（図示せず）との間における切り替えるための制御プレーン機能を提供してもよい。

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

サービングゲートウェイ１４４はまた、ＰＤＮゲートウェイ１４６に接続されてもよく、ＰＤＮゲートウェイ１４６は、インターネット１１０などのパケット交換ネットワークへのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供して、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと、ＩＰ対応デバイスとの間における通信を容易にしてもよい。

コアネットワーク１０６は、その他のネットワークとの通信を容易にしてもよい。例えば、コアネットワーク１０６は、ＰＳＴＮ１０８などの回線交換ネットワークへのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供して、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと、従来の地上通信線通信デバイスとの間における通信を容易にしてもよい。例えば、コアネットワーク１０６は、コアネットワーク１０６とＰＳＴＮ１０８との間におけるインタフェースとしての役割を果たすＩＰゲートウェイ（例えば、ＩＰマルチメディアサブシステム（ＩＭＳ）サーバ）を含んでもよく、またはそうしたＩＰゲートウェイと通信してもよい。加えて、コアネットワーク１０６は、ネットワーク１１２へのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供してもよく、ネットワーク１１２は、その他のサービスプロバイダによって所有および／または運営されているその他の有線または無線のネットワークを含んでもよい。

その他のネットワーク１１２は、ＩＥＥＥ８０２．１１ベースのＷＬＡＮ１６０にさらに接続されてもよい。ＷＬＡＮ１６０は、アクセスルータ１６５を含んでもよい。アクセスルータは、ゲートウェイ機能を含んでもよい。アクセスルータ１６５は、複数のアクセスポイント（ＡＰ）１７０ａ、１７０ｂと通信状態にあってもよい。アクセスルータ１６５とＡＰ１７０ａ、１７０ｂとの間における通信は、有線イーサネット（ＩＥＥＥ８０２．３標準）、または任意のタイプの無線通信プロトコルを介してもよい。ＡＰ１７０ａは、エアインタフェースを介してＷＴＲＵ１０２ｄと無線通信状態にある。

５Ｇエアインタフェースは、改善されたブロードバンド性能（ＩＢＢ：improved broadband performance）、産業制御および通信（ＩＣＣ：industrial control and communications）ならびに車両用途、車車間（Ｖ２Ｖ：vehicle to vehicle）または車車間／路車間（Ｖ２Ｘ：vehicle to everything）、ならびに大規模マシンタイプ通信（ｍＭＴＣ：massive machine-type communications）に適用されてもよいことが予期される。したがって５Ｇエアインタフェースは、極度に短い送信待ち時間、極度に信頼できる送信、ナローバンド動作を含むマシンタイプ通信（ＭＴＣ）動作、およびスペクトルオペレーティングモード（ＳＯＭ）のためのサポートを提供してもよい。

極度に短い送信待ち時間をサポートするために、１ｍｓのラウンドトリップタイム（ＲＴＴ）と同一ぐらい短いエアインタフェース待ち時間が、１００ｕｓと２５０ｕｓ（未満）との間のどこかでＴＴＩのためのサポートを必要することがある。極度に短いアクセス待ち時間、例えば、最初のシステムアクセスから第１のユーザプレーンデータユニットの送信の完了までの時間のためのサポートも提供されてもよい。少なくとも産業制御（ＩＣ）およびＶ２Ｘは、１０ｍｓ未満のエンドツーエンド（ｅ２ｅ）待ち時間を必要とする。

極度に信頼できる送信に関するサポートするために、鍵となる１つの設計考慮事項は、レガシーＬＴＥシステムで可能であるものよりもはるかに良好な送信信頼性である。９９．９９９％すなわち100％に限りなく近い確率での送信成功およびサービス可用性が、そのようなシステムに関する目標である。別の考慮事項は、０〜５００ｋｍ／時の範囲でのスピードのためのモビリティに関するサポートである。少なくともＩＣおよびＶ２Ｘは、マイクロ未満のパケットロス率を必要とする。

ナローバンド動作を含むＭＴＣ動作をサポートするために、エアインタフェースは、ナローバンド動作（例えば、２００ＫＨｚ未満を使用する）、拡張されたバッテリ寿命（例えば、最大で１５年間の自律性）、および少量であり頻繁でないデータ送信のための最小の通信オーバーヘッド（例えば、数秒から数時間のアクセス待ち時間を有する１〜１００キロビット／秒（ｋｂｐｓ）の範囲の低いデータレート）を効率よくサポートすべきである。

特定のスペクトルオペレーティングモード（ＳＯＭ）をサポートするために、ＷＴＲＵは、１つまたは複数のＳＯＭに従って送信を実行するように構成されてもよい。例えば、ＳＯＭは、特定の送信タイムインターバル（ＴＴＩ）持続時間、特定の初期電力レベル、特定のハイブリッド自動再送要求（ＨＡＲＱ）処理タイプ、成功のＨＡＲＱ受信／送信に関する特定の上限、特定の送信モード、特定の物理チャネル（アップリンクまたはダウンリンク）、特定の波形タイプのうちの少なくとも１つに従って構成されている送信に、または特定のＲＡＴ、例えばレガシーＬＴＥに従った、もしくは５Ｇ送信方法に従った送信にさえ対応してもよい。ＳＯＭは、サービス品質（ＱｏＳ）レベルおよび／または関連した側面、例えば、最大／目標待ち時間、最大／目標ブロック誤り率（ＢＬＥＲ）または同様の基準に対応してもよい。ＳＯＭは、スペクトルエリアに、および／または特定の制御チャネル、もしくは探索空間、ダウンリンク制御情報（ＤＣＩ）タイプなどを含むその側面に対応してもよい。

レガシー無線システムおよび新たな無線システムにおけるＷＴＲＵ協調を可能にするための方法、デバイス、およびシステムが、本明細書において提供されている。複数のＷＴＲＵが、別のノード、例えば、ｅＮＢ、ＷＴＲＵなどへデータを送信するために協調してもよく、または別のノード、例えば、ｅＮＢ、ＷＴＲＵなどからデータを受信するために協調してもよい。

例えば、２段階協調を使用してデータを送信するための方法が、共有段階および協調的段階を含み、それによってこの方法は、共有段階において、少なくとも１つのソースノードによってＷＴＲＵの協調セットとデータを共有することと、協調的段階において、ＷＴＲＵの協調セットによって宛先ノードへデータを送信または再送信することとを含む。

別の例においては、２段階協調を使用してデータを送信するための方法が、共有段階および協調的段階を含み、それによってこの方法は、協調的段階において、ソースノードによってＷＴＲＵの協調セットへデータを送信することと、共有段階において、ＷＴＲＵの協調セットによって少なくとも１つの宛先ノードとデータを共有することとを含む。データは、アップリンク（ＵＬ）送信またはダウンリンク（ＤＬ）送信として送信されてもよい。

２段階協調を使用してデータを送信するための方法が、ＷＴＲＵの協調セットの少なくとも１つのＷＴＲＵによって少なくとも１つのソースノードから受信されたデータを少なくとも１つの宛先ノードへ送信または再送信し、それによって、ＷＴＲＵの協調的セットのＷＴＲＵが、データを宛先ノードへ送信するために協調することを含んでもよい。

第１の段階および第２の段階を含む２段階協調を使用してデータを送信するための方法が、ＷＴＲＵの協調セットの少なくとも１つのＷＴＲＵによって少なくとも１つのソースノードから受信されたデータを少なくとも１つの宛先ノードへ送信または再送信し、それによって、ＷＴＲＵの協調的セットのＷＴＲＵが、ソースノードからデータを受信するために協調することを含んでもよい。

これらの方法はまた、共有段階および協調的段階を含む２段階協調を使用してデータを送信および／または受信するように構成されているＷＴＲＵの協調的セットを確立することを含んでもよい。

データを送信するための方法が、共有段階および協調的段階を含む２段階協調プロトコルを使用してデータを送信および／または受信するように構成されているＷＴＲＵの協調的セットを確立することを含んでもよく、それによって、ＷＴＲＵの協調的セットの確立は、第１のＷＴＲＵによって、ＷＴＲＵの協調的セットについての要求をｅＮｏｄｅ−Ｂへ送信することと、第１のＷＴＲＵによって、ｅＮｏｄｅ−Ｂから協調セット構成を受信することと、第１のＷＴＲＵによって、協調セット構成に基づいてＷＴＲＵの協調的セットを形成することとを含む。データを送信するための方法が、共有段階および協調的段階を含む２段階協調を使用してデータを送信および／または受信するように構成されているＷＴＲＵの協調的セットを確立することを含んでもよく、それによって、ＷＴＲＵの協調的セットの確立は、第１のＷＴＲＵによって、ＷＴＲＵの協調的セットを形成ためのインジケーションを第２のＷＴＲＵへ直接送信することと、第１のＷＴＲＵによって、第２のＷＴＲＵが第１のＷＴＲＵとともにＷＴＲＵの協調的セットに参加する旨の第２のＷＴＲＵからの確認応答（ＡＣＫ）を受信することと、第１のＷＴＲＵによって、受信されたＡＣＫに基づいてＷＴＲＵの協調的セットを形成することとを含み、ＷＴＲＵの協調的セットは、第１のＷＴＲＵおよび第２のＷＴＲＵを含む。これらの方法は、第１のＷＴＲＵによって、ＷＴＲＵの確立された協調的セットをｅＮｏｄｅ−Ｂへ報告することを含んでもよい。これらの方法は、ＷＴＲＵの協調的セットによって、データの複数のサブセットを含むデータを受信し、それによって、ＷＴＲＵの協調的セットのそれぞれのＷＴＲＵが、データの複数のサブセットのうちの少なくとも１つのサブセットを受信することと、ＷＴＲＵの協調的セットによって、ＷＴＲＵの協調的セットのＷＴＲＵ間で複数のサブセットを共有し、それによって、ＷＴＲＵの協調的セットのそれぞれのＷＴＲＵが、データの全ての複数のサブセットを有することと、ＷＴＲＵの協調的セットによって、ＷＴＲＵの協調的セットの間で共有されたデータを宛先ノードへ協調的に送信し、それによって、ＷＴＲＵの協調的セットの少なくとも１つのＷＴＲＵが、データを宛先ノードへ送信することとを含んでもよい。

協調的送信は、ＷＴＲＵの協調的セットのどの１つまたは複数のＷＴＲＵがデータを宛先ノードへ送信するかをＷＴＲＵの協調的セットが決定することを含んでもよい。代わりに、協調的送信は、ＷＴＲＵの協調的セットのどの１つまたは複数のＷＴＲＵがデータを宛先ノードへ送信するかをＷＴＲＵの協調的セットの協調セットマスタＷＴＲＵが決定することを含んでもよい。

これらの方法は、ＷＴＲＵの協調的セットによって、データが受信されている旨の少なくとも１つのＡＣＫをソースノードへ送信することと、ソースノードによって、閾値数のＡＣＫを受信したことに基づいてデータを送信するのをやめることとを含んでもよい。

データを送信するための方法が、ＷＴＲＵの協調的セットによって、データの複数のサブセットを含むデータを受信し、それによって、ＷＴＲＵの協調的セットのそれぞれのＷＴＲＵが、データの複数のサブセットのうちの少なくとも１つのサブセットを受信することと、ＷＴＲＵの協調的セットのＷＴＲＵによって、データを協調的に送信する前にデータの複数のサブセットのうちの少なくとも１つのサブセットを閾値回数にわたってＷＴＲＵの協調的セットのその他のＷＴＲＵと共有することとを含んでもよい。

データを送信するための方法が、ＷＴＲＵの協調的セットによって、データの複数のサブセットを含むデータをソースノードから協調的に受信し、それによって、ＷＴＲＵの協調的セットの少なくとも１つのＷＴＲＵが、ソースノードからデータを受信することと、ＷＴＲＵの協調的セットによって、ＷＴＲＵの協調的セットのＷＴＲＵ間で複数のサブセットを共有することとを含んでもよい。ＷＴＲＵの協調的セットによるソースノードからのデータの協調的受信は、ＷＴＲＵの協調的セットのそれぞれのＷＴＲＵがデータの複数のサブセットのうちの少なくとも１つのサブセットを受信することを含んでもよい。ＷＴＲＵの協調的セットのＷＴＲＵ間での複数のサブセットの共有は、ＷＴＲＵの協調的セットのそれぞれのＷＴＲＵがデータの複数のサブセットを全て有するように共有することを含んでもよい。ＷＴＲＵの協調的セットのそれぞれのＷＴＲＵは、その受信されたデータを時分割多重化方式で、または同時方式でＷＴＲＵの協調的セットのその他のＷＴＲＵと共有してもよい。

データは、複数の領域を有する協調的サブフレーム構成を有してもよい。複数の領域は、制御情報のための第１の領域、データの共有のために使用されるチャネルの送信および／または受信のための第２の領域、共有されたデータのフィードバックを送信するために使用されるチャネルのための第３の領域、データの協調的送信または再送信のために使用されるチャネルのための第４の領域、ならびにデータの協調的送信または再送信のフィードバックを送信するために使用されるチャネルのための第５の領域のうちの少なくとも２つを含んでもよい。

制御情報は、物理レイヤ（ＰＨＹ）またはメディアアクセス制御（ＭＡＣ）（ＭＡＣ／ＰＨＹ）パラメータまたは能力に中継される情報、グループ情報、１つまたは複数のチャネル識別子、変調パラメータ、フィードバック情報、ビームフォーミングマトリックス情報、送信のためのリソースなどを含んでもよい。フィードバックは、データ受信のＡＣＫまたは否定ＡＣＫを含んでもよい。フィードバックは、ビットマップの形態であってもよく、それぞれのビットは、確認されているデータの部分を表す。

ＷＴＲＵの協調的セットの第１のＷＴＲＵが、サブフレームの第１のタイムスロットにおいてデータを共有し、同一サブフレームまたは異なるサブフレームのうちの少なくとも１つの第２のタイムスロットにおいてデータを協調的に送信してもよい。加えて、ＷＴＲＵの協調的セットの第２のＷＴＲＵが、サブフレームの第１のタイムスロットにおいてデータを共有し、同一サブフレームまたは異なるサブフレームのうちの少なくとも１つの第２のタイムスロットにおいてデータを協調的に送信してもよい。第２のＷＴＲＵの第１のタイムスロットは、第１のＷＴＲＵの第２のタイムスロットと重なり得、および／または第２のＷＴＲＵの第２のタイムスロットは、第１のＷＴＲＵの第１のタイムスロットと重なる。

複数のＷＴＲＵが、協調するＷＴＲＵのセットへと構成されてもよい。協調は、第１の段階、例えば、共有データの共有段階と、第２の段階、例えば、協調的方式でデータを（再）送信する協調的段階とを含む２段階の送信を使用して達成されてもよい。

協調セットＷＴＲＵは、改良されたＵＬグラントを介した、アップリンク（ＵＬ）送信に関するデータの共有、および／またはラウンドロビン再送信もしくは共同再送信を使用した、ダウンリンク（ＤＬ）データの共有を含めて、ｅＮＢで終端される送信およびＷＴＲＵで終端される送信の両方に関してデータを共有してもよい。

共有段階の間に、ＷＴＲＵは、１つまたは複数のソースＷＴＲＵからデータを成功して受信していることがあってもよい。ＷＴＲＵは、協調段階において送信するためのデータのセットを決定するように構成されてもよく、それは、そのＷＴＲＵ自身のデータのサブセット、およびその他のＷＴＲＵからの成功して受信されたデータのセットであってもよい。１つのオプションにおいては、ネットワークはまた、共有段階の間にソースＷＴＲＵからの送信を復号することを試み得る。ネットワークは、それがＡＣＫ／ＮＡＣＫフィードバックを介して正しく受信したデータのセットをＷＴＲＵに示してもよい。

ＷＴＲＵは、協調段階において送信するためのデータのセットを制御情報に基づいて、例えば、ｅＮＢから受信されたグラントまたはフィードバックを使用して選択するように構成されてもよい。一例においては、ＷＴＲＵは、ｅＮＢが第１の（共有）段階の間に正しく受信しなかったデータのみを送信するように構成されてもよい。別の例においては、ＷＴＲＵは、それが共有段階の間に正しく受信した全てのデータを、ｅＮＢが全てのデータを正しく受信したことをそれが示さない限り、送信するように構成されてもよい。別の例においては、ＷＴＲＵは、ｅＮＢが協調段階において要求しているデータのみを、明示的な制御シグナリングを介して、ＷＴＲＵがその要求されているデータを正しく復号している場合、送信するように構成されてもよい。一例においては、ｅＮＢは、協調セット内でデータが属するＷＴＲＵ（識別）ＩＤに基づいてデータにアドレスまたはインデックスを付け得る。

協調するＷＴＲＵのセットによるデータの協調的送信がさらに開示され、これは、分散空間時間ブロックコーディング、分散ビームフォーミング、および／もしくは分散ＭＩＭＯを使用すること、ならびに／または分散再送信を使用することを含み、これは、より動的な協調を可能にするためのファウンテンコード（Fountain codes）などの新たなコーディングスキームを含んでもよい。

協調的サブフレーム構造の設計も本明細書において提供されており、サブフレームは、共有および協調的（再）送信領域へと分割される。例えば、サブフレームは、領域へと分割されて、時間スロットを共有段階および協調的段階として使用することを含む２段階協調を可能にすることができる。

非直交の複数のアクセスを使用して、共有段階および協調的段階の両方の性能を強化する方法も本明細書において提供されている。協調的送信のためのプリコーディングを決定するための方法も本明細書において提供されている。開示されている特徴および方法の任意の組合せが１つまたは複数の実施形態において使用されてもよいことが理解されるであろう。

ソースとは、送信するためのデータを有するＷＴＲＵまたはｅＮＢなどのノードを指す。送信のためのデータの量を使用してバッファステータスが決定されてもよい。宛先とは、ソースによって送信されたデータの意図されている受信側であるＷＴＲＵ、ｅＮＢ、またはリレーなどのノードを指してもよい。データが別々のノードの複数のホップを通って進み得るケースに関しては、データ送信の意図されている最終的な受け手が最終的な宛先とみなされてもよい。

協調セットとは、１つまたは複数のソースからデータを受信してデータを１つまたは複数の宛先ノードへ協調的に再送信することができる１つまたは複数のノード、例えば、ＷＴＲＵ、ｅＮＢ、またはリレーのセットを指してもよい。マルチホップ送信のケースに関しては、協調セットは、１つもしくは複数のソースおよび／または１つもしくは複数のその他の協調セットからデータを受信し、データを１つもしくは複数の宛先および／または１つもしくは複数のその他の協調セットへ協調的に再送信してもよい。

２段階協調とは、共有段階および協調的段階という２つの段階から構成されている協調を達成するための方法を指してもよい。２段階協調という用語は、厳密に２つの段階に限定されるものと理解されるべきではないことに留意されたい。２段階協調は、少なくとも２つの段階を使用する協調を指す。

共有段階は、ＵＬ送信およびＤＬ送信のために適用されてもよい。ＵＬ送信に関しては、共有段階は、２段階協調の第１の段階であってもよく、１つまたは複数のソースノードのセットが、データを協調セットと共有する。ＤＬ送信に関しては、共有段階は、２段階協調の第２の段階であってもよく、協調セットが、受信されたデータを１つまたは複数の宛先ノードと共有するか、または再送信する。

協調的段階は、ＵＬ送信およびＤＬ送信のために適用されてもよい。ＵＬ送信に関しては、協調的送信段階は、２段階協調の第２の段階であってもよく、協調セットが、データを１つまたは複数の宛先へ再送信する。ＤＬ送信に関しては、協調的受信段階は、２段階協調の第１の段階であってもよく、１つまたは複数のソースノードが、データを協調セットへ送信する。

本明細書においては２段階協調が提供され、それによって、例えば、複数のＷＴＲＵが、データを別のノード、例えばｅＮＢへ送信するために協調し、またはデータを別のノード、例えばｅＮＢから受信するために協調する。

協調は、１つまたは複数のＷＴＲＵによる、１つまたは複数のソースＷＴＲＵから１つまたは複数のノード、例えば、ｅＮＢ、別のＷＴＲＵ、および／またはリレーへのデータの送信または再送信を含んでもよい。例えば、ＷＴＲＵは、自身のデータをｅＮＢへ送信するために、協調するＷＴＲＵのセットによって補助されてもよい。図２Ａおよび図２Ｂは、ＵＬおよびＤＬにおける協調的送信の例２００を示している。

図２Ａは、ＵＬにおける協調的送信の例を示している。第１のステージにおいて、ＷＴＲＵは、個々に２０２〜２０６でデータを互いに共有し、次いでそれらのＷＴＲＵは、共有されたデータを２０８〜２１２でノード、例えば、ｅＮＢ２１４、別のＷＴＲＵ、または中継ノードへ送信する。

協調はまた、協調するＷＴＲＵのセットによる、ノード、例えば、ｅＮＢ、別のＷＴＲＵ、リレーからのデータの受信、および協調的方式での宛先ＷＴＲＵへの再送信を含んでもよい。

図２Ｂは、ＤＬにおける協調的受信の例を示している。ＤＬ方向において、送信２１８〜２２２が、ノード、例えば、ｅＮＢ２１６、別のＷＴＲＵ、または中継ノードにおいて開始し、次いで１つまたは複数のＷＴＲＵへ２２４〜２２８で送信される。

協調は、ｅＮＢ、例えば、改良された物理ダウンリンク制御チャネル（（Ｅ）ＰＤＣＣＨ）、物理ダウンリンク共有チャネル（ＰＤＳＣＨ）、物理制御フォーマットインジケータチャネル（ＰＣＦＩＣＨ）、物理ハイブリッドＡＲＱインジケータチャネル（ＰＨＩＣＨ）、物理ランダムアクセスチャネル（ＰＲＡＣＨ）、物理アップリンク共有チャネル（ＰＵＳＣＨ）、物理アップリンク制御チャネル（ＰＵＣＣＨ）との間での、別のＷＴＲＵ（例えば、デバイスツーデバイス（Ｄ２Ｄ）チャネルを使用する）との間での、リレーとの間での任意の既存の物理チャネルの送信または受信のために使用されてもよい。代わりに、新たな物理レイヤチャネルが、協調情報の転送の専用にされてもよい。例えば、ダウンリンクにおいて、ＷＴＲＵは、新たな協調的ＰＤＳＣＨ（ＣＰＤＳＣＨ）上でデータを受信してもよい。ＣＰＤＳＣＨ上で送信されたデータは、ＷＴＲＵのセットによって復号可能であってもよく、実施形態においては新たな協調的サイドリンクを介して、適切な宛先ＷＴＲＵへ再送信されてもよい。別の例においては、ＵＬにおいて、ＷＴＲＵのセットが、一実施形態においては新たな協調的サイドリンクプロシージャを介して、データを共有してもよい。ＷＴＲＵのセットは次いで、新たな協調的ＰＵＳＣＨ（ＣＰＵＳＣＨ）を介してデータを最終的な宛先へ、例えばｅＮＢへ送信してもよい。

図３Ａおよび図３Ｂは、ＵＬ３００における２段階協調の例を示している。共有段階および協調的段階という２つの段階によって協調的送信が達成されてもよい。ＵＬにおいては、図３Ａにおいて示されている共有段階は、協調するＷＴＲＵセットとデータを３０８〜３１２を共有するソースＷＴＲＵ３０２〜３０６のセットから構成されている。この例においては、ソースＷＴＲＵのセットは、協調するＷＴＲＵセットに相当している。別の例においては、協調するＷＴＲＵセットは、ソースＷＴＲＵの上位集合であってもよい。データを共有することは、ソースＷＴＲＵデータを、協調セットの１つまたは複数のメンバがそれを復号することを可能にすることができる方式で送信することを含んでもよい。協調するＷＴＲＵセットは、それら自身がソースＷＴＲＵであってもよく、またはそうでなくてもよいＷＴＲＵから構成されてもよい。ＵＬにおいては、図３Ｂにおいて示されている協調的段階は、ＷＴＲＵ３０２〜３０６の協調セットが１つまたは複数の宛先ノード、例えばｅＮＢ３２０へ３１４〜３１８でデータを再送信する場合であってもよい。

ＤＬにおいては、２つの段階は、ＵＬに関して記述されている例に関連して逆にされているとみなされてもよい。協調的段階、例えば協調的受信段階は、ソースノード、例えばｅＮＢが、データを、ＷＴＲＵの協調セットが１つまたは複数の宛先ノード、例えば１つまたは複数の宛先ＷＴＲＵのために復号することが可能とすることができる方式で送信するときである。共有段階は、協調セットがデータを適切な１つまたは複数の宛先ノードへ再送信する期間から構成されてもよい。

マルチホップ送信に関しては、２つよりも多い段階があってもよい。例えば共有段階において、１つまたは複数のソースノードが１つまたは複数の協調セットへの送信する第１の段階があってもよい。次いでｎホップスキームに関しては、例えば１つまたは複数の協調的段階において、様々な協調セットの間に協調的受信および協調的再送信のｎ−２段階があってもよい。次いで、例えば共有段階において、１つまたは複数の協調セットが１つまたは複数の最終的な宛先ノードへの送信することができる最終的な段階があってもよい。

マルチホップ送信の別の例においては、第１の段階が協調的段階であってもよく、その後に１つまたは複数の共有段階が続いてもよく、その後に最終的な協調的段階が続いてもよい。

ＷＴＲＵのセットは、データの送信または受信を改善するために協調してもよい。効率よく協調するために、第１のＷＴＲＵは、それが協調することができる他のＷＴＲＵのセットを知る必要がある場合がある。様々な協調セット構成があってもよい。協調セットは、そのセットからの少なくとも１つのＷＴＲＵ（例えば、第１のＷＴＲＵ）が、協調セット内の少なくとも１つのＷＴＲＵ（例えば、第２のＷＴＲＵ）のためにデータを送信および／または受信するのを補助することができるＷＴＲＵから構成されてもよい。第２の例においては、協調セットは、そのセットからの少なくとも１つのＷＴＲＵ（例えば、第１のＷＴＲＵ）が、協調セット内にない少なくとも１つのＷＴＲＵ（例えば、第２のＷＴＲＵ）のためにデータを送信および／または受信するのを補助することができるＷＴＲＵから構成されてもよい。第２のＷＴＲＵは、協調セットによってサービス提供されているとみなされてもよい。第２の例は、マルチホップ送信としてさらに定義されてもよく、送信の意図されている最終的な宛先は、中間ノードの一部ではない。例えば、ＤＬ送信のためのソースノード、例えばｅＮＢから、協調するＷＴＲＵのセットへの送信と、次いで、協調するＷＴＲＵのセットから、ＤＬ送信のための最終的な宛先ノード、例えばＷＴＲＵへの第２の送信とを用いてマルチホップが達成されてもよい。協調セットは、協調セットマスタとして機能する１つのＷＴＲＵによってさらに特徴付けられてもよい。

ＷＴＲＵは、様々な目的で様々な協調セットのメンバであってもよく、および／または様々な協調セットによってサービス提供されてもよい。例えば、ＷＴＲＵは、送信の方向、送信のタイプ、送信の優先度レベル、および／または繰り返しレベルのうちの少なくとも１つに応じて、一意の協調セットのメンバであってもよく、または一意の協調セットによってサービス提供されてもよい。

送信方向、例えば、ＵＬ送信またはＤＬ送信に関して、その送信方向は、ネットワークによって終端される方向またはＷＴＲＵによって終端される方向に関して定義されてもよい。送信のタイプは、例えば、データ、ＨＡＲＱ Ａ／Ｎ、チャネル状態情報（ＣＳＩ）フィードバック、ＤＣＩ、ＵＣＩ、制御プレーン送信、またはデータプレーン送信であってもよい。送信の優先度レベルは、短い待ち時間および／または高い信頼性要件を有する送信が、より長い待ち時間および／またはより低い信頼性を有する送信よりも高くランク付けされることに関連してもよい。繰り返しレベルは、ＷＴＲＵが、貧弱なカバレッジを緩和するために送信を複数回にわたって繰り返してもよいケースに関して定義されてもよい。再送信レベルも、送信を完了するために必要とされる複数の繰り返しに基づいて定義されてもよい。

上の例として、ＷＴＲＵが、高い優先度を有するＵＬ送信のための第１の協調セットのメンバであってもよく、そのＷＴＲＵは、より低い優先度を有するＵＬ送信のための第２の協調セットのメンバであってもよい。さらに、そのＷＴＲＵは、全てのＤＬ送信のためのいずれの協調セットのメンバでもなくてもよく、またはいずれの協調セットによってもサービス提供されなくてもよい。優先度の決定は、ＷＴＲＵまたはｅＮＢまたはその他のネットワークデバイスによって行われてもよい。優先度は、トラフィックタイプまたはコンテンツに基づいてもよい。音声およびビデオトラフィックは、データまたはＥメールコンテンツよりも高い優先度を有してもよい。

本明細書においては、協調セット構成が提供される。ＷＴＲＵは、複数の協調セットのメンバであってもよく、または複数の協調セットによってサービス提供されてもよい。ＷＴＲＵは、少なくとも１つの協調セット、例えば、その他のメンバＷＴＲＵの識別（ＩＤ）でｅＮＢによって構成されてもよい。ＷＴＲＵは、それが協調セットを必要としていることをｅＮＢに示してもよく、例えば、要求してもよい。そのようなインジケーションは、明示的であってもよく、新たな測定タイプ、新たなＣＳＩフィードバックレポート、ＵＣＩレポート内の要素、ランダムアクセスプロシージャ内の、例えばｍｓｇ３送信内のインジケーション、または新たなＷＴＲＵプロービング信号タイプ送信のうちの少なくとも１つであってもよい。

協調セットを要求するためにＷＴＲＵによって使用されるインジケーションは、黙示的であってもよく、協調に対する必要性を示すために確保されているサブセットからのＰＲＡＣＨプリアンブルの選択、パワーヘッドルームレポート、またはスケジューリング要求と空のバッファとの組合せによって提供されてもよい。ｅＮＢは、例えば、協調セットについてのＷＴＲＵからのインジケーションおよび／または要求を受信すると、ＷＴＲＵへ協調セット構成情報を送信してもよい。協調セット構成情報は、協調セット（識別）ＩＤ、協調的セットマスタＷＴＲＵ（識別）ＩＤ、協調セット内のメンバノード（例えば、ＷＴＲＵ）のリスト、および／または協調的送信のためのリソースのうちの少なくとも１つを含んでもよい。例えば、リソースは、協調セット内のどのＷＴＲＵ上でデータを共有することができるかを含んでもよい。別の例においては、リソースは、協調セット内のどのＷＴＲＵ上でデータを協調的に送信することができるかを含んでもよい。これらのリソースは、半静的に構成されてもよく、協調するＷＴＲＵにとって永続的に利用可能であってもよい。リソースは、協調的受信のためのリソース、基準信号構成、協調セット特有の無線ネットワーク識別子（Ｃ−ＲＮＴＩ）値、協調的送信モード、および／または協調段階の間の基準タイミングを含んでもよい。協調的受信のためのリソースは、例えば、ＷＴＲＵが協調セットからの送信を受信することができるリソースを含んでもよい。これらのリソースは、半静的に構成されてもよく、協調するＷＴＲＵにとって永続的に利用可能であってもよい。基準信号構成。例えば、復調基準信号またはＷＴＲＵ特有の基準信号。基準信号は、協調的送信／受信段階および共有段階の一方または両方に関して構成されてもよい。協調的セット内の１つまたは複数のＷＴＲＵによって協調セット特有のＣ−ＲＮＴＩが採用されてもよい。本明細書においては、協調的送信モードの例が記述されている。協調段階に関する基準タイミング、および／または協調段階のスケジュールは、ＷＴＲＵが、共通の時間基準に関連してそれぞれの協調段階のタイミングおよび持続時間を決定するための情報、例えば、ＳＦＮまたは指定されたその他のソースを含む。

本明細書においては、例示的なＷＴＲＵ自律協調セット構成が提供されている。ＷＴＲＵのセットが、協調セットを自律的に形成してもよい。協調的送信または受信を使用することを望むＷＴＲＵは、Ｄ２Ｄのようなブロードキャストされる送信を介して、例えば、ディスカバリを介して、またはシグナリング通信メカニズムを介して、協調的送信もしくは受信に対する自身の必要性、または協調的送信もしくは受信を実行する自身の能力について示してもよい。ＷＴＲＵは、自身が共有および／または協調的送信および／または協調的受信のために使用することができるリソースを含めることによって、協調的送信を実行する自身の能力を示してもよい。これらのリソースは、半静的であってもよい。リソースは、協調段階に関連付けられているタイミングおよび／またはスケジュールを含んでもよい。ＷＴＲＵは、協調のための利用可能な電力、または協調のための利用可能なキャパシティのうちの１つまたは複数を含めることによって、協調的送信を実行する自身の能力をさらに示してもよい。キャパシティは、フレームあたりの物理リソースブロック（ＰＲＢ）および／またはサブフレームの点から定義されてもよい。ＷＴＲＵは、宛先への、例えば、ＵＬ送信に関しては宛先ｅＮＢへのパスロスまたはチャネル特性を含めることによって、協調的送信を実行する自身の能力をさらに示してもよい。加えて、ソースからの、例えば、ＤＬ送信に関してはソースｅＮＢからのパスロスまたはチャネル特性が考慮されてもよい。ＷＴＲＵは、ＷＴＲＵによって決定された協調的セット識別子であってもよい協調的セット識別子、もしくは協調的セットを開始するＷＴＲＵに関連付けられている識別子を含めることによって、協調的送信を実行する自身の能力を、および／または協調的セットマスタＷＴＲＵであるそのＷＴＲＵの能力をさらに示してもよい。

協調的送信を実行し、または協調セットを形成するための第１のＷＴＲＵからのインジケーションを受信したことに応答して、第２のＷＴＲＵは、自身も第１のＷＴＲＵとの協調に参加する旨を確認応答してもよい。このＡＣＫは、一実施形態においてはＤ２Ｄのようなブロードキャストされる送信を介して、オリジナルメッセージと同様の方式で送信されてもよい。別の実施形態においては、第２のＷＴＲＵは、Ｄ２Ｄのような直接送信リンク上での送信を介して第１のＷＴＲＵからのインジケーションに、例えばＡＣＫメッセージを介して、確認応答してもよい。１つのオプションにおいては、ＡＣＫは、協調的セット識別子を含んでもよい。

協調セットのメンバＷＴＲＵのうちの少なくとも１つは、協調セットのステータスをｅＮＢに示してもよい。そのようなインジケーションは、協調的送信を使用してもよく、または使用しなくてもよい。協調セットのステータスは、定期的にまたは不定期にｅＮＢに報告されてもよい。協調セットのステータスは、始めに新たな協調的ランダムアクセスプロシージャを介して示されてもよい。

協調セットのステータスは、協調セット（識別）ＩＤ、協調的セットマスタＷＴＲＵ（識別）ＩＤ、協調セットメンバノード、協調セット共有リソース、および／または協調セット協調モードのうちの少なくとも１つを含んでもよい。

協調セットのステータスを送信した後に、協調セット内のＷＴＲＵは、ｅＮＢによって制御される協調セット構成に関して上述されているのと同様の協調セット構成をｅＮＢから受信してもよい。

ＷＴＲＵ間でデータを共有するための方法が提供される。例えば、ＵＬ送信の共有のための方法、およびＤＬ送信を共有するための方法が提供される。

ＵＬ送信の共有のための方法が、以降で記述されている。協調セット内の、または協調セットによってサービス提供されているＷＴＲＵは、ＵＬデータを宛先ノード、例えばｅＮＢへ協調的に送信する前にそれらのデータを共有してもよい。共有されたデータは、ソースＷＴＲＵごとのデータからおそらくは独立しているとみなされてもよい。例えば、あらゆるソースＷＴＲＵは、協調セットＷＴＲＵとの間で共有される必要があるデータのセットを有してもよい。

ＷＴＲＵは、自身が自身のデータを送信してもよいリソースを動的に割り当てられてもよい。割り当て情報は、協調セット内の別のＷＴＲＵによって送信される共有グラント内にあってもよい。例えば、そのようなグラント送信は、協調セット内の協調的セットマスタＷＴＲＵによって集中化（centralized）および送信されてもよい。

別の例においては、共有リソース（すなわち、共有されるリソース）の分散スケジューリングが使用されてもよい。例えば、ＷＴＲＵは、自身がデータを共有することになるリソースを示す制御情報を、協調するＷＴＲＵへ動的にブロードキャストしてもよい。ブロードキャストされる送信は、事前に割り当てられたリソースを使用してもよい。そのようなリソースは、ＷＴＲＵ自律協調セット構成の間にＷＴＲＵによって自律的に決定または選択されていることがあってもよく、またはそれらは、ｅＮＢによって割り当てられていることがあってもよい。

リソースを１つまたは複数のＷＴＲＵに割り当てるために、改良されたＵＬ送信グラントが使用されてもよい。ＷＴＲＵは、自身が自身のデータを送信することができるリソースを動的に割り当てられてもよい。その割り当ては、ｅＮＢによって送信されるＵＬグラント内にあってもよい。ＵＬグラントは、協調セット内のその他のＷＴＲＵとの間でのデータの共有のために使用するためのリソース、すなわち、ＷＴＲＵが自身のデータを送信することができるＷＴＲＵ特有のリソース、その他のＷＴＲＵによって共有されているデータの受信のために使用するためのリソース、および／または宛先ｅＮＢへのデータの送信のために使用するためのリソースのうちの少なくとも１つを含んでもよい。

リソースは、リソースブロック割り当て、時間インジケーション（time indication）、例えば、サブフレーム、タイムスロット、協調段階情報など、スクランブリングＩＤ、復調基準信号構成、変調およびコーディングスキーム、プリコーディング情報およびレイヤの数および送信電力制御のうちの少なくとも１つを含んでもよい。

協調セットのＷＴＲＵ間でデータを共有するために使用されるＵＬグラントが、ＷＴＲＵのセット全体へ送信されてもよい。そのグラント内の情報は、ＷＴＲＵに応じて別々に解釈されてもよい。例えば、ＷＴＲＵは、データを時分割多重化（ＴＤＭ）方式で共有してもよい。そのようなケースにおいては、ＵＬグラントは、協調セット内のそれぞれの個々のＷＴＲＵが自身のデータをいつ共有することができるかに関する情報を含んでもよい。別の実施形態においては、協調セット内のあらゆるＷＴＲＵは、ＷＴＲＵ特有のタイミングオフセット、例えば、ＵＬグラントの受信とデータの共有との間における時間で事前に構成されてもよい。さらに、協調セット内の全てのＷＴＲＵは、共有されるデータの適切な受信を可能にするために、その他のＷＴＲＵのタイミングオフセットを認識してもよい。

ＷＴＲＵは、複数のＷＴＲＵによって共有されたデータを受信し、その後にそのデータを宛先ノードへ、例えばｅＮＢへ協調的に送信してもよい。復号および転送の実施形態においては、ＷＴＲＵは、ＡＣＫをソースＷＴＲＵへ送信してもよい。事前に決定された、かつ潜在的に構成可能な数のＡＣＫフレームまたはメッセージを受信すると、ＷＴＲＵは、十分な数のその他のＷＴＲＵが自身のデータを協調的に送信することができると決定してもよい。そのケースにおいては、ＷＴＲＵは、自身のデータを再共有しなくてよい。さらに、ＷＴＲＵが、自身のデータを成功して受信した協調するＷＴＲＵの数、または受信されたＡＣＫの数に応じて、そのデータを宛先へ再送信することを必要とされる場合には、そのＷＴＲＵは、協調的再送信の前に再共有する必要がない場合がある。その一方で、データの前回の共有時に、ＷＴＲＵが、十分に多くの数のＡＣＫを受信していない場合には、例えば、受信されたＡＣＫの数が、構成されている閾値よりも少ない場合には、ＷＴＲＵは、次の協調的再送信へ進む前に再び共有を実行する必要がある場合がある。

増幅および転送タイプの協調的方法に関しては、ＷＴＲＵは常に、いずれの協調的再送信の前にも、協調セットＷＴＲＵとの間で、構成可能な回数だけ自身のデータを再共有してもよい。そのような方法においては、協調するＷＴＲＵは、いずれかの後の協調的再送信の前に、トランスポートブロックのいずれかの全ての以前に共有された送信を組み合わせてもよい。

別の例においては、圧縮および転送が、協調セットＷＴＲＵによって使用されてもよい。そのようなケースにおいては、協調セットＷＴＲＵは、自身のデータ間における相関関係を利用してもよい。例えば、センサのセットが、送信するためのデータを相関付けていることがある。協調セットＷＴＲＵ間での、宛先へのデータの共有は、宛先におけるサイド情報でソースコーディングを使用することによって実行されてもよい。これは、共有リソースの最適な使用を可能にすることができる。

協調セット内の、または協調セットによってサービス提供されているＷＴＲＵは、ソースノード、例えばｅＮＢからの協調的受信の後にＤＬデータを共有してもよい。ＷＴＲＵは、ソースノード、例えばｅＮＢから受信されたデータを自身が共有してもよいリソースを動的に割り当てられ得る。割り当ては、協調セット内の別のＷＴＲＵによって送信される共有グラント内にあってもよい。例えば、そのようなグラント送信は、協調セット内の協調的セットマスタＷＴＲＵによって集中化および送信されてもよい。

別の実施形態においては、共有リソースの分散スケジューリングの方法が使用されてもよい。例えば、ＷＴＲＵは、自身がデータを共有することになるリソースを示す制御情報を、協調するＷＴＲＵへ動的にブロードキャストしてもよい。ブロードキャストされる送信は、事前に割り当てられたリソースを使用してもよい。そのようなリソースは、ＷＴＲＵ自律協調セット構成の間にＷＴＲＵによって自律的に決定または選択されていることがあり、またはそれらは、ｅＮＢによって割り当てられていることがある。

ＤＬリソースの受信するためのＷＴＲＵを構成するために、改良されたＤＬ割り当てが使用されてもよい。ＷＴＲＵは、自身が自身のデータを受信および共有することができるリソースを動的に割り当てられてもよい。その割り当ては、ｅＮＢによって送信されるＤＬ割り当て内にあってもよい。ＤＬ割り当ては、それがソースノード、例えばｅＮＢからのデータを受信することができるリソース、協調セット内のその他のＷＴＲＵとの間でのデータの共有のために使用するためのリソース、すなわち、ＷＴＲＵが、自身がソースから受信したものを共有することができるＷＴＲＵ特有のリソース、および／またはその他のＷＴＲＵによって共有されているデータの受信のために使用するためのリソースのうちの少なくとも１つを含んでもよい。

リソースは、リソースブロック割り当て、時間インジケーション、例えば、サブフレームのインジケーション、スクランブリングＩＤ、復調基準信号構成、変調およびコーディングスキーム、プリコーディング情報およびレイヤの数、ならびにデータの共有のための送信電力制御のうちの少なくとも１つを含んでもよい。

協調セットのＷＴＲＵ間でデータを共有するために使用されるＤＬ割り当てが、ＷＴＲＵのセット全体へ送信されてもよい。そのグラント内の情報は、ＷＴＲＵに応じて別々に解釈されてもよい。例えば、ＷＴＲＵは、受信されたデータをＴＤＭ方式で共有してもよい。そのようなケースにおいては、ＤＬ割り当ては、協調セット内のそれぞれの個々のＷＴＲＵが自身の受信されたデータをいつ共有することができるかに関する情報を含んでもよい。別の例においては、協調セット内のあらゆるＷＴＲＵは、ＷＴＲＵ特有のタイミングオフセット、例えば、ＤＬ割り当ての受信および／またはソースからのデータの送信とデータの共有との間における時間で事前に構成されてもよい。さらに、協調セット内の全てのＷＴＲＵは、共有されるデータの適切な受信を可能にするために、その他のＷＴＲＵのいずれのタイミングオフセットも認識してもよい。

ＤＬデータは、ＷＴＲＵによって共有されてもよい。復号および転送の協調的モードにおいては、協調するＷＴＲＵは、協調セット内のいくつかのまたは全てのＷＴＲＵのためにソースからデータを受信してもよい。成功して復号すると、協調セットＷＴＲＵは、自身が復号した全てのデータを、所定のもしくは事前に構成されたまたは動的に構成されるリソース内に含めて再送信してもよい。ＷＴＲＵ特有の共有リソースは、リソースブロック割り当て、時間インジケーション（例えば、サブフレーム）、スクランブリングＩＤ、復調基準信号構成、変調およびコーディングスキーム、プリコーディング情報およびレイヤの数、送信電力制御のうちの少なくとも１つから構成されてもよい。

成功して復号されたとみなされないいずれのデータも、ＷＴＲＵによって共有されなくてよい。例えば、図４は、ラウンドロビン送信を使用してソースｅＮＢからの協調的受信の後に協調的ＷＴＲＵ間で共有されるＤＬデータを示している。別の例においては、図５は、ソースｅＮＢからの協調的受信の後に共同再送信を使用して共有されるＤＬデータを示している。

図４において示されている第１の例においては、協調セット内のあらゆるＷＴＲＵが、自身の受信したデータをＴＤＭ方式で共有してもよい。例えば、図４において示されているように、第１の時間インスタンス（time instance）、例えばサブフレーム１ ４０２において、第１のＷＴＲＵ４０８が、全ての成功して復号されたデータを、全ての関連する宛先ＷＴＲＵ４１０〜４１２のために再送信してもよい。第２の時間インスタンス、例えばサブフレーム２ ４０４において、第２のＷＴＲＵ４１０は、全ての成功して復号されたデータを、全ての関連する宛先ＷＴＲＵ４０８および４１２などのために、協調セット内のその他の全てのＷＴＲＵのために再送信してもよい。サブフレーム３ ４０６において、例えば、第３のＷＴＲＵ４１２は、データを第１および第２のＷＴＲＵ４０８〜４１０へ再送信してもよい。この方法においては、それぞれのＷＴＲＵが、協調セット内の全てのＷＴＲＵから通信を受信している。

図５において示されている第２の例においては、協調セット内のＷＴＲＵは、受信されたデータ５００を共有するために協調してもよい。それぞれのソースＷＴＲＵごとに、特有の共有リソースがあってもよい。そのようなリソースにおいては、適切なソースＷＴＲＵのための送信を成功して復号した全ての協調セットＷＴＲＵが、共同送信を使用してデータを共有してもよい。例えば、協調セットＷＴＲＵのサブセットが、第１のＷＴＲＵのためのデータを成功して復号することができ、そのサブセットは次いで、第１の共有リソースにおいて、例えばサブフレーム１ ５０２において、共同方式でそのデータを共有してもよい。この方法においては、ＷＴＲＵ１ ５０８およびＷＴＲＵ２ ５１０が、同一サブフレーム１ ５０２の間にデータをＷＴＲＵ３ ５１２へ送信する。同様の送信が、サブフレーム２ ５０４およびサブフレーム３ ５０６において示されているように行われてもよい。サブフレーム２ ５０４において、ＷＴＲＵ２ ５１０およびＷＴＲＵ３ ５１２が、データをＷＴＲＵ１ ５０８へ送信する。サブフレーム３において、ＷＴＲＵ１ ５０８およびＷＴＲＵ３ ５１２が、データをＷＴＲＵ２ ５１０へ送信する。適切な宛先ＷＴＲＵがソースからの送信からのデータを成功して復号することができる場合には、それは、協調するＷＴＲＵによるデータのいずれの共有も回避してもよい。これは、全ての宛先ＷＴＲＵが、協調セットＷＴＲＵ間でのデータの共有の前にＨＡＲＱ Ａ／Ｎを最初に送信することを可能にすることによって、達成されてもよい。

協調するＷＴＲＵによって使用される共同送信は、分散ビームフォーミング、分散空間時間符号化、または分散多重化のうちの少なくとも１つを使用してもよい。協調的セット内の複数のＷＴＲＵの間における共同送信は、理想的なビームフォーミング重みの計算を必要とすることがある。これらのビームフォーミング重みは、協調的送信の前に複数のＷＴＲＵのそれぞれのＷＴＲＵとの間で共有される必要がある場合がある。共同送信の前に共有される必要がある場合があるその他の情報は、キャリアのインジケーション、キャリアアライメント（carrier alignment）、または１つもしくは複数のスマートアンテナの能力セットを含んでもよい。それぞれのＷＴＲＵが、スマートアンテナ構成を含む能力セットを共同送信の前に交換することが有益となることがある。これは、分散ビームフォーマに特に関連することがある。

別の例においては、増幅および転送の送信技術が、協調セットＷＴＲＵによって使用されてもよい。そのようなケースにおいては、全ての協調セットＷＴＲＵは、自身がソースから受信したソフト情報を共有してもよい。復号および転送の実施形態と同様に、受信されたデータの共有は、全ての協調セットＷＴＲＵにそれらの受信したソフト情報をブロードキャストさせることによって、または協調セットＷＴＲＵが、宛先ＷＴＲＵごとに共同でソフト情報を送信するために協調することによって、行われてもよい。さらに、協調セットＷＴＲＵは、ソースへの自身のリンクのためのチャネル推定値を共有してもよい。そのようなチャネル推定は、宛先ＷＴＲＵと協調セットＷＴＲＵとの間におけるリンクのチャネル推定とともに、ソースＷＴＲＵにおける復号を改善するために使用されてもよい。

増幅および転送の実施形態においては、ＷＴＲＵは、使用するための増幅係数で構成されてもよい。その構成は、共有送信グラント内に含まれてもよく、ＭＡＣ、無線リソース制御（ＲＲＣ）、またはＰＬＣＰレイヤメッセージにおいて受信されてもよい。別の実施形態においては、１つまたは複数の増幅係数が、半静的に構成されてもよい。別の実施形態においては、１つまたは複数の増幅係数は、特有の宛先ＷＴＲＵ要件に依存してもよく、好ましい値は、宛先ＷＴＲＵによって示されてもよい。別の例においては、ＷＴＲＵが、１つまたは複数の増幅係数を、一実施形態においては利用可能な送信電力に応じて自律的に決定してもよい。

別の例においては、圧縮および転送が、協調セットＷＴＲＵによって使用されてもよい。そのようなケースにおいては、協調セットＷＴＲＵは、自身の受信した信号間における相関関係を利用してもよい。協調セットＷＴＲＵ間での、宛先ＷＴＲＵへのデータの共有は、宛先におけるサイド情報でソースコーディングを使用することによって実行されてもよい。これは、共有リソースの最適な使用を可能にすることができる。圧縮は、ヘッダ圧縮、ペイロード圧縮、またはヘッダ圧縮およびペイロード圧縮の組合せを含んでもよい。例示的な圧縮アルゴリズムは、ビデオ／音声用途のためのロッシーアルゴリズムを含む。代わりに、圧縮アルゴリズムは、データ用途のためのロスレスアルゴリズムを含んでもよい。本明細書において開示されている実施形態によって採用することができるいくつかの例示的な圧縮アルゴリズムは、Ｌｅｍｐｅｌ−Ｚｉｖ、Ｚｉｐ、Ｇｉｆなどを含む。選択される圧縮アルゴリズムは、協調的セット内の１つまたは複数のＷＴＲＵによってネゴシエートされてもよい。

ソースノードは、空間多重化を使用して協調セットに送信してもよい。そのようなケースにおいては、送信レイヤの数は、いずれかの協調セットＷＴＲＵ上のアンテナの数の最小値として決定されてもよい。これは、あらゆる協調セットＷＴＲＵが、空間多重化されたチャネルの検知および復号を試みることができることを可能にすることができる。協調セットＷＴＲＵは次いで、自身が受信した、かつ潜在的に復号されている、適切な宛先ＷＴＲＵへの送信を共有するために、本明細書において提示されているいずれかの共有方法を使用してもよい。別の例においては、ソースノードは、少なくとも１つの協調セットＷＴＲＵのアンテナの数よりも多い複数の空間レイヤを使用してもよい。例えば、空間レイヤの数は、協調セット内の受信アンテナの総数に一致することがある。そのようなケースにおいては、復号は集中化されてもよく、それによって、全ての協調セットＷＴＲＵは、ソフト情報を中央復号ノードと共有してもよく、その後にそのノードは、次いでデータを復号し、意図されている宛先ＷＴＲＵと共有する。別の例においては、全てのソフト情報は、全ての宛先ＷＴＲＵとの間で共有されてもよい。次いでそれぞれの宛先ＷＴＲＵは、自身の意図されているデータを復号してもよい。別の例においては、分散復号が、協調セットＷＴＲＵによって採用されてもよい。そのようなケースにおいては、第１の協調セットＷＴＲＵが、復号を試みて、自身のソフト復号された情報を第２の協調セットＷＴＲＵへ転送してもよい。第２の協調セットＷＴＲＵは、第１のＷＴＲＵからのソフト情報を、自身の受信した送信とともに使用して、復号を試みてもよく、自身のソフト復号された情報を第３の協調セットＷＴＲＵへ転送してもよい、などである。少なくとも１つの宛先ＷＴＲＵのためのデータを成功して復号すると、協調セットＷＴＲＵは、復号されたデータを、意図されている宛先ＷＴＲＵと共有してもよい。

実施形態においては、全二重対応ＷＴＲＵは、共有されたデータの同時送信および受信が可能であってもよい。例えば、それぞれのソースＷＴＲＵは、自身が自身のデータを協調セットＷＴＲＵと共有することができるリソースのセットを与えられてもよい。リソースのセットは、シンボルのセット（すなわち、ＴＤＭを使用する）、サブキャリアのセット（すなわち、ＦＤＭを使用する）、またはそれら２つの組合せ（すなわち、ＦＤＭ＋ＴＤＭもしくはＣＤＭを使用する）であってもよい。全二重共有の能力は、共有段階の時間が低減されることを可能にすることができ、したがって、２段階協調に存在する全体的な待ち時間を低減させることができる。

非直交のアクセススキームが、共有段階において使用されてもよい。例えば、それぞれのソースＷＴＲＵは、自身のデータを共有するために疎コード多重アクセス（ＳＣＭＡ）コードブックを割り当てられ得る。進んだ受信機を使用する全二重協調セットＷＴＲＵは、その他のソースＷＴＲＵからの共有されたデータを復号する一方で、別々のＳＣＭＡリソースを使用して自身のデータを共有することが可能であってもよい。

ＷＴＲＵの協調セットは、様々な協調的送信モードを使用して、データを宛先へ、例えばｅＮＢへ送信してもよい。協調的送信モードは、構成可能であってもよく、一実施形態においては、例えば、改良されたＵＬグラント、もしくは協調的送信専用のグラントにおいて動的に行われてもよく、または別の実施形態においては、半静的に行われてもよい。協調的送信モードの例が以下で提供される。

分散空間時間ブロックコード（ＳＴＢＣ）送信が、協調的送信モードの例である。この送信モードにおいては、ダイバーシティ利得が最大化されてもよい。ＷＴＲＵの協調セットの間でデータを共有した後に、ＷＴＲＵは、自身のアンテナポートが全体的な送信システムのサブセットであるかのようにＳＴＢＣを構築してもよい。例えば、ＷＴＲＵｉがｎ_i個の送信アンテナポートを有する場合には、協調セットＳが、合計でｎ_T＝Σ_i∈Sｎ_i個の送信アンテナポートを有する。送信アンテナポートの総数ｎ_Tに応じて、ＳＴＢＣによって達成可能な最大レートは変動することがあることに留意されたい。達成可能な最大レートは、ｒ＝ｎ_T＋２／２ｎ_Tによって決定される。したがってＳＴＢＣの長さは、協調セットのサイズと、そのセット内でデータを送信するソースＷＴＲＵの数とに依存してもよい。例えば、２つのＷＴＲＵからなるセットが存在し、それぞれが１つの送信アンテナを有する（ｎ_T＝２である）場合には、最大レートは、ｒ＝１である。このケースにおいては、下記のように定義されているＡｌａｍｏｕｔｉコードが使用されてもよい。

ｃ₁は、第１のＷＴＲＵからのシンボルであり、ｃ₂は、第２のＷＴＲＵからのシンボルである。適切なコーディングのために、協調セット内の全てのＷＴＲＵは、その他の全てのＷＴＲＵに知られているインデックスを割り当てられてもよい。

ｎ_Tまたはｎ_iの別々の値に関して、特有のコーディング構造が定義されてもよい。ｎ_T＞２に関してはｒ＝１でなくてもよいので、特定のアンテナポートでの特定のシンボルの時間における繰り返しが必要とされる場合があることに留意されたい。例えばｎ_T＝３に関しては、ＳＴＢＣは、下記のように定義されてもよい。

いくつかのＳＴＢＣ構造においては、複数の送信アンテナに対する複数の送信される情報シンボルの１対１のマッピングがなくてもよい。したがって、複数のＷＴＲＵへのシンボルの均一な分散がなくてもよい。例えば、ｎ_T＝３に関するＳＴＢＣの場合には、４つの情報シンボル（ｃ₁，ｃ₂，ｃ₃，およびｃ₄）がある。それぞれが単一のアンテナを有する３つのＷＴＲＵが、分散されたｎ_T個の送信アンテナを形成していると想定される場合には、１つのＷＴＲＵが、２つの情報シンボルをその他のＷＴＲＵの単一の情報シンボルへ送信することを許可されてもよい。情報シンボルの数を均一にするために、協調セットＷＴＲＵへのそれぞれのｃ_iのマッピングは、サブキャリアごと、またはリソースブロック（ＲＢ）ごとであってもよい。例えば第１のサブキャリアにおいては、ｃ₁が、第１のＷＴＲＵに関するシンボルであり、ｃ₂が、第２のＷＴＲＵに関するシンボルであり、ｃ₃およびｃ₄が、第３のＷＴＲＵに関するシンボルである。第２のサブキャリアにおいては、ｃ₁が、第１のＷＴＲＵに関するシンボルであり、ｃ₂およびｃ₄が、第２のＷＴＲＵに関するシンボルであり、ｃ₃が、第３のＷＴＲＵに関するシンボルである。第３のサブキャリアにおいては、ｃ₁およびｃ₄が、第１のＷＴＲＵに関するシンボルであり、ｃ₂が、第２のＷＴＲＵに関するシンボルであり、ｃ₃が、第３のＷＴＲＵに関するシンボルである。ＳＴＢＣにおける、実施形態においては、サブキャリアごとの、またはＰＲＢごとの、またはサブフレームごとの、ＷＴＲＵへのシンボルのマッピングは、例えば、協調セットの形成時に、または協調的送信モードの構成時に、または協調セットの再構成時に、半静的に行われてもよい。別の例においては、ＷＴＲＵへのシンボルのマッピングは、動的に、例えばＵＬグラントの一部として行われてもよい。さらに、ＷＴＲＵ特有のアンテナポートへの分散アンテナポートのマッピングは、例えば、協調セットの形成時に、または協調的送信モードの構成時に、または協調セットの再構成時に半静的に行われてもよい。別の例においては、ＷＴＲＵ特有のアンテナポートへの分散アンテナポートのマッピングは、動的に、一実施形態においてはＵＬグラントの一部として行われてもよい。

準直交ＳＴＢＣが分散方式で使用されて、部分ダイバーシティ利得を提供する一方でフルレートを達成することができる。Ｑ−ＳＴＢＣはしたがって、ＷＴＲＵ特有のアンテナポート番号への情報シンボルのシンプルな１対１のマッピングを有してもよい。例えば、ｎ_T＝４に関するＱ−ＳＴＢＣは、４つの情報シンボルを使用してもよい。したがって、それぞれのＷＴＲＵは、アンテナポートごとに情報シンボルで指定されてもよい。

分散ビームフォーミングが、協調的送信モードの別の例である。このケースにおいては、全てのソースＷＴＲＵからのデータは、構成可能な数のレイヤ、例えば、１つまたは２つのレイヤに連結されてもよい。協調セットのあらゆるＷＴＲＵは、自身のアンテナポート上でレイヤの適切なプリコーディングを使用してもよい。分散プリコーディングが、動的に、一実施形態においては、協調的送信のためのＵＬグラントにおいて、ＷＴＲＵに示されてもよい。別の例においては、分散プリコーディングは、全ての協調セットＷＴＲＵに知られている事前に決定されたパターンで時間とともに変動することがある。

分散ＭＩＭＯが、協調的送信モードの別の例である。そのような方法においては、ソースＷＴＲＵのデータは、特有のレイヤにそれぞれ割り当てられてもよい。レイヤからアンテナポートへのマッピングは、ソースＷＴＲＵが協調段階において自身のＷＴＲＵ特有のアンテナポート上で自身のデータのうちのいずれも再送信しないことを確実にする方法で構成されてもよい。さらに、レイヤからアンテナポートへのマッピングは、時間とともに変動してもよく、構成可能な方式で変更されてもよい。この実施形態は、共有段階の間に送信されたデータを宛先が受信することができる場合には、宛先でのダイバーシティにおける増大を可能にすることができる。さらに、この実施形態は、最良のコーディングレートを提供してもよい。例えば、あらゆるソースＷＴＲＵが、送信するためのｘ個のシンボルを有している場合には、分散ＭＩＭＯは、そのＷＴＲＵのために合計で１６個のＯＦＤＭシンボル、例えば、共有段階において８つのＯＦＤＭシンボル、および協調段階において８つのＯＦＤＭシンボルを必要とする場合がある。代わりに、共有段階において、協調段階よりも不均一な数のＯＦＤＭシンボルが使用されてもよい。不均一な数のシンボルは、それぞれの段階に対して別々の変調およびコーディングレートが使用されることを可能にすることができる。さらなる冗長性を共有段階または協調段階のうちの一方に含めることが有益となることがある。

協調的送信モードの別の例は、分散再送信モードと呼ばれてもよい。ここでは、協調的ＷＴＲＵは、共有されたデータを復号し、そのデータを協調的送信のために再符号化してもよい。協調的送信のために使用される符号器は、共有された送信のために使用された符号器と同一であってもよい。代わりに、協調的送信のために使用される符号器は、共有された送信のために使用された符号器とは異なってもよい。例えば、協調的送信は、共有段階において使用された冗長性バージョンとは異なる冗長性バージョンを使用してもよい。

例においては、宛先ノード、例えばｅＮＢが、共有段階の間にソースＷＴＲＵからの送信を受信してもよい。宛先は次いで、自身がデータを成功して復号したかどうかを決定してもよい。宛先は、データが成功して復号された場合には、ＡＣＫをソースＷＴＲＵへ、および一実施形態においては、協調するＷＴＲＵへ送信してもよい。宛先は、自身がデータを成功して復号しなかった場合には、否定応答（ＮＡＣＫ）をソースＷＴＲＵへ、および一実施形態においては、協調するＷＴＲＵへ送信してもよい。協調するＷＴＲＵによってＮＡＣＫが受信された場合には、協調的段階が生じてもよい。さらに、協調的段階は、別々の冗長性バージョンの送信を可能にすることができる。

協調セットＷＴＲＵは、１つまたは複数のソースＷＴＲＵからの送信および／または再送信についてリッスンまたは監視し、そうした送信および／または再送信を復号することを試みてもよい。送信を成功して復号すると、一実施形態においては、累積された送信を使用することによって、協調セットＷＴＲＵは、将来の再送信の協調的送信に参加してもよい。例えば、第１の送信は、ソースＷＴＲＵからのものであってもよく、第１の再送信は、ソースＷＴＲＵ、ならびに第１の送信を成功して復号したいずれかの協調セットＷＴＲＵによるものであってもよく、次なる再送信は、ソースＷＴＲＵ、および第１の送信を成功して復号した協調セットＷＴＲＵ、および第１の再送信の後に成功して復号したその他のいずれかの協調セットＷＴＲＵによるものであってもよい、などである。これは、宛先がＡＣＫを送信するまで継続してもよい。

図６は、分散再送信の例を示しており、この場合、協調セットＷＴＲＵは、送信されたデータを自身が成功して復号した場合にのみ再送信に参加する。図６は、ＷＴＲＵ６０４〜６０８のセットが、単一のソースＷＴＲＵ６０４のためのデータを送信するために協調しているところを示している。宛先ｅＮＢ６０２がデータの成功した受信を確認応答するまで、再送信が行われる。このケースにおいては、協調するＷＴＲＵの別々のセットによって別々の冗長性バージョン（ＲＶ）が送信されてもよい。いずれの協調的送信も、本明細書において記述されているモードのうちのいずれかを使用してもよいことに留意されたい。第１の送信において、第１の冗長性バージョンＲＶ６１０が、ＷＴＲＵ６０４によってＷＴＲＵ６０６〜６０８およびｅＮＢ６０２へ送信される。ＮＡＣＫ６１２が受信された場合には、ＷＴＲＵ６０４は、第２の冗長性バージョンＲＶ６１４を送信してもよい。ＷＴＲＵ６０４は、ＷＴＲＵ６０６とともにＲＶ６１４を送信してもよく、この場合、この例においては、ＷＴＲＵ６０６は、ＷＴＲＵ６０４からの第１の送信を成功して受信し、ＷＴＲＵ６０８は、ＷＴＲＵ６０４からＷＴＲＵ６０８およびｅＮＢ６０２の両方への第１の送信を成功して受信しなかったことが想定される。このケースにおいては、ＷＴＲＵ６０８は、データを成功して受信するための別の機会を有する。ＲＶ２ ６１４に関してＮＡＣＫ６１６が受信された場合には、第３のＲＶ６１８が使用されてもよい。ＲＶ３ ６１８においては、ＷＴＲＵ６０６〜６０８はそれぞれ、ＷＴＲＵ６０４からのデータの送信を成功して受信しており、そのデータをｅＮＢ６０２へ同時に送信してもよい。ＲＶ３ ６１８によって示されている方法は、総送信電力の点でコストがかかる場合があるが、それは、ネットワークにおいて利用可能な最もロバストな送信をもたらす。

いずれの再送信機会に関しても、再送信は、単一の段階で達成されてもよい。例えば図６において、ＲＶ２に関して、送信するＷＴＲＵは、宛先ｅＮＢによって許可されたリソース上で送信してもよい。加えて、送信を受信するＷＴＲＵは、同一リソース上でリッスンしていてもよい。

別の例においては、再送信機会は、２段階アプローチを使用してもよい。そのようなケースにおいては、再送信は、第１の段階（ここでは、データを以前に成功して復号した協調セットＷＴＲＵが、一実施形態においてはソースＷＴＲＵとともに、共有リソース上で送信してもよい）と、第２の段階（ここでは、データを以前に成功して復号した全ての協調セットＷＴＲＵが、データを最も直近に成功して復号したあらゆる新たな協調セットＷＴＲＵとともに、ソースＷＴＲＵとともに、協調的送信リソース上で送信してもよい）とから構成されてもよい。

協調的再送信プロセスをさらに示す例が、図７において示されている。図７Ａは、ＷＴＲＵ７０２からのデータ送信を受信している３つのＷＴＲＵ７０４〜７０８を示している。ＷＴＲＵ７０４からのＮＡＣＫを受信すると、図７ＣにおいてＷＴＲＵ７０４とｅＮＢ７１０との間に矢印がないことによって示されているように、ｅＮＢ７１０への対応する協調的送信にＷＴＲＵ７０４がもはや参加しないことの決定が行われることがある。図７Ｃは、協調的送信を示しており、それによって、第５のＷＴＲＵ７１２が、協調的送信リソースを使用して協調的送信ステージの間にデータを受信する。最後に、図７Ｄは、ＷＴＲＵ７０２、７０６、７０８、および７１２がｅＮＢ７１０への再送信することを示している。ＷＴＲＵ７０４はステップＢにおいてＮＡＣＫを送信したので、ＷＴＲＵ７０４は送信グループから除外されていることに留意されたい。代わりに、ＷＴＲＵ７０４がステップＣにおいて送信を受信していた場合、ＷＴＲＵ７０４は、ステップＤにおいて示されている送信に参加している場合がある。ＷＴＲＵ７１２は図７Ｃにおいてデータを成功して復号したので、ＷＴＲＵ７１２は、図７Ｄにおいて示されているように成功して追加されている。

ファウンテンコード再送信が、協調的送信モードの分散再送信の別の例である。ここでは、ＷＴＲＵが、レートレスコーディング（rateless coding）を使用して、例えばファウンテンコードを使用して、自身のデータを送信してもよい。ＷＴＲＵは、自身のデータをコードブロックのセットへと符号化してもよく、それによって、（Ｎ個の合計の送信されたコードブロックからの）Ｋ個の正しく復号されたコードブロックのいずれかのセットの受信も、宛先ノードがデータ全体を適切に復号することを可能にすることができる。協調セットＷＴＲＵが、宛先ノードｅＮＢと比較された場合に、Ｋ個の正しく復号されたコードブロックを入手するために、より少ない合計の送信されたコードブロックＮを必要とする場合がある。そのようなシナリオにおいては、共有段階は、Ｎ₁個の送信されるコードブロックの送信から構成されてもよい。（Ｎ₁個の送信されたコードブロックからの）少なくともＫ個の正しく復号されたコードブロックを入手することができるいずれかの協調セットＷＴＲＵはしたがって、オリジナルのソースＷＴＲＵの送信を決定してもよい。そのような協調セットＷＴＲＵは次いで、宛先ノードへの共同送信を実行してもよい。共同送信は、Ｎ₂個のコードブロックのセットの送信であってもよい。Ｎ₂個のコードブロックは全て、全ての協調セットＷＴＲＵによって送信されてもよい。別の例においては、いくつかのまたはあらゆる協調セットＷＴＲＵが、一実施形態においてはソースＷＴＲＵとともに、Ｎ₂個のコードブロックのサブセットを送信してもよく、それによって、全ての送信されたコードブロックの結合が、Ｎ₂個のコードブロックのセットを形成する。

Ｎ₁およびＮ₂の値は、フィードバックに基づいて、またはリンクアダプテーションに基づいて決定されてもよい。例えば、最良の協調セットＷＴＲＵが、少なくともＫ個のコードブロックを正しく復号することができる確率が、特定の要件（例えば、１０回のうち９回）を達成することを保証することによって、Ｎ₁が決定されてもよい。最良の協調セットＷＴＲＵが、復号確率を達成するために最も低いＮ₁を必要としたものである場合、少なくともＳ個の協調セットＷＴＲＵが、特定の要件を達成する少なくともＫ個のコードブロックを正しく復号する確率を有することを保証することによって、Ｎ₁が決定されてもよい。全ての協調セットＷＴＲＵが、特定の要件を達成する少なくともＫ個のコードブロックを正しく復号する確率を有することを保証することによって、Ｎ₁が決定されてもよい。

例えば、宛先ノードがＮ₁＋Ｎ₂個の送信からＫ個のコードブロックを正しく復号することができる確率が特定の要件を達成するような適切なＨＡＲＱオペレーティングポイントを達成するようにＮ₂の値が決定されてもよい。

別の実施形態においては、ソースＷＴＲＵが、事前に決定されたリソース上でコードブロックを送信してもよい。いくつかのまたは全ての協調セットＷＴＲＵが、送信されたコードブロックを復号することを試みてもよい。Ｋ個のコードブロックを正しく復号すると、協調セットＷＴＲＵは、ソースＷＴＲＵ、およびＫ個のコードブロックを以前に正しく復号したその他のいずれかの協調するＷＴＲＵとの共同方式で次のコードブロックを送信することを開始してもよい。ソースＷＴＲＵおよび協調セットＷＴＲＵは、Ｎ個の合計コードブロックが送信されるまで、コードブロックを送信することを継続してもよく、Ｎの値は、適切なＨＡＲＱオペレーティングポイントを達成するように決定されてもよい。

協調的サブフレームが提供される。ＷＴＲＵ、例えば、協調セット内のＷＴＲＵが、協調的送信、または協調的共有、または協調的再送信の使用のための送信パラメータで構成されてもよい。そのようなパラメータは、サブフレーム構成、サブバンドもしくは帯域幅部分のセット、スペクトルオペレーティングコード（ＳＯＭ）、または協調的Ｃ−ＲＮＴＩのうちの少なくとも１つを含んでもよい。共有送信または協調的送信のための別々の値を有するＣ−ＲＮＴＩのセットがあってもよい。協調的Ｃ−ＲＮＴＩは、任意選択で協調的セット識別子に関連付けられてもよい。

それに応じて、サブフレーム構成が提供される。協調を使用するＷＴＲＵ、例えば、ソースＷＴＲＵ、宛先ＷＴＲＵ、または協調セットＷＴＲＵは、協調のためのサブフレーム構成で構成されてもよい。そのようなサブフレーム構成は、複数の領域から構成されてもよく、それぞれのサブフレーム領域は、サブフレーム内のシンボルのセットとして定義されてもよい。例えば、協調のためのサブフレーム構成は、制御情報のための第１の領域、データの共有のために使用されるチャネルの送信および／もしくは受信のための第２の領域、共有されたデータのフィードバックを送信するために使用されるチャネルのための第３の領域、データの協調的（再）送信のために使用されるチャネルのための第４の領域、またはデータの協調的（再）送信のフィードバックを送信するために使用されるチャネルのための第５の領域の任意の組合せを含んでもよい。

いくつかのサブフレーム領域は、協調的サブフレームの直接隣接したシンボルの上で機能してもよい。そうでない場合には、ガード期間、例えば、シンボルの一部が、隣接した領域を区切ってもよい。

図８は、複数領域協調的サブフレーム８００の例を示している。例示的なフレームは、制御領域８０２、共有データ送信／受信領域８０４、フィードバック領域８０６、協調的（再）送信領域８０８、および協調的（再）送信のフィードバック領域８１０を含む。例示的なサブフレーム構造は、合計時間長、および個々の領域８０２〜８１０に対応する時間長の両方の点で逸脱することがあることに留意されたい。サブフレームは、縮尺どおりに描かれてはいないが、データ共有および協調的（再）送信のために使用される時間長は、制御およびフィードバックに使用される時間よりも長い可能性が高い。データを共有するために使用されるチャネルの送信および／または受信のために使用されるシンボルのセットは、本明細書において説明されている共有方法のうちのいずれかを再利用してもよい。例えば、領域はＴＤＭ方式で区切られ、それぞれのソースＷＴＲＵが自身のデータを直交リソースにおいて共有することを可能にすることができる。別の例においては、ＷＴＲＵが全二重動作に対応できる場合には、領域は、ＦＤＭまたはＣＤＭ／ＴＤＭ＋ＦＤＭ（ＳＣＭＡなどの方法を含む）方式で区切られてもよい。そのような実施形態においては、それぞれのソースＷＴＲＵは、データの送信のためのサブキャリアおよびシンボルの１つのセット、または１つのＣＤＭコード、ならびにデータの受信のためのサブキャリアおよびシンボルのセット、またはＣＤＭコードのセットを割り当てられてもよい。

共有されたデータのフィードバックを送信するために使用されるシンボルのセットは、ＴＤＭ、ＦＤＭ、ＦＤＭ＋ＴＤＭ、ＣＤＭ、または非直交の複数のアクセス（例えば、ＳＣＭＡ）方式で区切られてもよい。それぞれのリソースは、ソースＷＴＲＵの送信に結び付けられてもよい。一実施形態においては、１つまたは複数の協調セットＷＴＲＵが、領域においてソースＷＴＲＵのリソースを使用して、成功した受信のＡＣＫを送信してもよい。そのような実施形態においては、リソース上で送信がないことを検知することによって、ＮＡＣＫが黙示的に決定されてもよい。ＷＴＲＵが、自身の共有された送信に割り当てられているこの領域内のリソースをリッスンして、その他のいずれかの協調セットＷＴＲＵが自身の共有されたデータを成功して復号したかどうかを決定してもよい。複数の協調セットＷＴＲＵが、ＷＴＲＵの共有されたデータを成功して復号した場合には、それらは全て、共同送信方法を使用して、または協調的方式でＡＣＫを送信してもよい。ソースＷＴＲＵによるＡＣＫの受信は、ソースＷＴＲＵに対して、自身のデータが協調的方式で再送信されることを示してもよい。

データの協調的（再）送信のために使用される領域に関して、ＷＴＲＵは、自身のデータのみを再送信してもよく、協調セットデータを協調的方式で送信してもよく、またはサイレントなままであってもよい。ＷＴＲＵが自身のデータのみを再送信する場合には、その再送信は、異なる冗長性バージョンを使用してもよい。ＷＴＲＵは、それが協調セットＷＴＲＵではなくソースＷＴＲＵのみである場合に、このオプションを選択してもよい。ＷＴＲＵは、それが協調セットＷＴＲＵであり、その他のいずれのソースＷＴＲＵの共有された送信も成功して復号していない場合に、このオプションを選択してもよい。ＷＴＲＵは、それが協調セットＷＴＲＵであり、自身の共有された送信をその他の協調セットＷＴＲＵが成功して復号していない場合に、このオプションを選択してもよい。

ＷＴＲＵは、そのＷＴＲＵが協調セットＷＴＲＵであり、少なくとも１つのその他のソースＷＴＲＵの共有された送信を成功して復号している場合に、協調セットデータを協調的方式で送信するオプションを選択してもよい。

ＷＴＲＵは、そのＷＴＲＵが、（再）送信するためのいずれのデータも有していない場合に、およびそれが、少なくとも１つのその他のソースＷＴＲＵの共有された送信を成功して復号することができない場合に、サイレントにするオプションを選択してもよい。

例えば、２段階協調方法は、ＴＤＭ方式で達成されてもよい。これは、全体的な送信に待ち時間を加えることがある。待ち時間を低減するために、２段階協調は、タイムスロットベースで実行されてもよい。ＷＴＲＵは、自身のデータをサブフレームの第１のタイムスロットにおいて共有してもよく、協調的送信は、一実施形態においては同一、サブフレームの第２のタイムスロットにおいて行われてもよい。

ＷＴＲＵは、そのＷＴＲＵがデータを協調セットＷＴＲＵと共有することができる特定のタイムスロットを示す共有リソースを許可されてもよい。共有グラントは、宛先ｅＮＢから送信されてもよい。さらに、共有グラントは、ソースＷＴＲＵがデータを共有することができるリソースを決定するために、協調セット内のいくつかのまたは全てのＷＴＲＵによって受信されてもよい。ソースＷＴＲＵがデータを共有することができるリソース（タイムスロットを含む）を協調セットＷＴＲＵに示す協調的ＵＬグラントがあってもよい。例においては、タイムスロット共有グラントおよびタイムスロット協調的グラントは、単一の改良されたＵＬグラントに組み合わされてもよい。

同時の共有および協調のための方法が提供される。例においては、協調的サブフレームの別々の領域は、完全に直交していなくてよい。それぞれの領域の長さは、全ての協調セットＷＴＲＵに関して固定されていることおよび／もしくは同一であることが可能であり、またはそれぞれの段階の長さは、それぞれのＷＴＲＵごとに異なることが可能であり、協調セットＷＴＲＵが、１つのソースＷＴＲＵの共有されたデータを復号しているかどうか、協調セットＷＴＲＵが、複数のソースＷＴＲＵの共有されたデータを復号しているかどうか、例えば、協調セットＷＴＲＵが、全てのソースＷＴＲＵのデータを復号しているかどうか、もしくは協調セットＷＴＲＵが、ソースＷＴＲＵの共有されたデータの所定のセットを復号しているかどうか、もしくは協調セットＷＴＲＵが、事前に決定された数のソースＷＴＲＵのデータを復号しているかどうか、ソースＷＴＲＵの共有されたデータが、少なくとも１つの協調セットＷＴＲＵによって復号されている場合に、ソースＷＴＲＵが共有段階を終了してもよいかどうか、より高いレイヤによって受信された構成のうちの少なくとも１つによって、もしくは測定の結果に基づいて決定されてもよい。例えば、ＷＴＲＵは、測定に基づいて、自身が特定の長さの時間にわたって、またはリソースの特定のセットにわたって自身のデータを共有する必要があることを決定してもよい。

一実施形態においては、別々の協調セットＷＴＲＵが協調的段階を開始する時間は、全ての協調セットＷＴＲＵに関して同一である必要はない。したがって、第１の協調セットＷＴＲＵの共有領域と、第２の協調セットＷＴＲＵの協調領域との間には、重なりがあってもよい。

この実施形態はまた、レガシーサブフレームの使用に適用可能であってもよい。例えば、いくつかの実施態様においては、共有段階は、複数のサブフレームにわたって持続してもよく、その後に、やはり複数のサブフレームにわたって持続してもよい協調的段階が続いてもよい。それぞれの段階の長さは、協調的サブフレームに関して本明細書において挙げられているのと同様の基準に基づいて固定されてもよく、または可変であってもよい。

同時の共有および協調は、共有（再）送信および協調的（再）送信のために、異なる複数のアクセスリソースを、一実施形態においては同一サブフレームで割り当てることによって達成されてもよい。そのような複数のアクセスリソースは、直交または非直交、例えばＳＣＭＡを使用することであってもよい。例えば、協調セットＷＴＲＵは、第１のＳＣＭＡコードワードまたは拡散シーケンスを使用して、自身のデータを共有してもよく、適切な時点で、それは、第２のＳＣＭＡコードワードまたは拡散シーケンスを使用して、自身がその他のソースＷＴＲＵから復号したデータを協調的に送信してもよい。ＷＴＲＵは、そのＷＴＲＵが協調的送信を開始したときに、例えば、一実施形態においては、第１のＳＣＭＡコードワードまたは拡散シーケンスを依然として使用することによって、データを引き続き共有してもよい。

協調的プリコーディングの方法が提供される。例えば、ＤＬ協調的受信フィードバックおよびＵＬ協調的送信プリコーディングが提供される。ＤＬ協調的受信フィードバックのケースにおいては、ＷＴＲＵ、例えば、協調セットＷＴＲＵではない宛先ＷＴＲＵが、非協調的受信仮説に基づいてＣＳＩをｅＮＢへフィードバックしてもよい。例えば、ＷＴＲＵは、様々なＣＳＩプロセスの定期的なおよび不定期のフィードバックレポートで構成されてもよい。構成されたＣＳＩプロセスのうちの１つまたは複数は、協調セットと宛先ＷＴＲＵとの間におけるリンクに関するＣＳＩフィードバックを可能にすることができる。そのような構成は、ＷＴＲＵにとってトランスペアレントであってもよい。協調セットＣＳＩプロセスは、協調セット基準信号の構成を必要とすることがある。

協調セットＷＴＲＵ、例えば、宛先ＷＴＲＵであってもよく、またはそうでなくてもよいＷＴＲＵが、協調的受信仮説に基づいてＣＳＩをｅＮＢへフィードバックしてもよい。そのようなフィードバックレポートは、いくつかのまたは全ての協調セットＷＴＲＵによって分散方式で決定されてもよい。例えば、それぞれのＷＴＲＵは、ｅＮＢによる送信パラメータの好ましいセット、例えば、ランク、チャネル品質インジケータ（ＣＱＩ）、プリコーダなどを決定してもよく、適切なフィードバックレポートをそれぞれフィードバックしてもよい。別の例においては、フィードバックレポートの決定は、集中化された方式で行われてもよい。例えば、協調セットＷＴＲＵは、構成された基準信号を含む信号上で取られた測定値を共有してもよい。１つまたは複数の中央ノード、例えば、１つまたは複数の協調するＷＴＲＵが、フィードバックレポートを算出してもよい。フィードバックレポートは、そのフィードバックレポートを算出した１つまたは複数のＷＴＲＵによって送信されてもよい。別の例においては、フィードバックレポートは、協調セット内の１つまたは複数のフィードバック報告ノードによって送信されてもよい。この実施形態に関しては、フィードバックレポートの共有は、それらのレポートをｅＮＢへフィードバックする前に必要とされることがある。

ＵＬ協調的送信プリコーディングのケースにおいて、ＵＬ協調セットが宛先ｅＮＢに知られている場合には、ＵＬ協調グラントは、使用すべき適切な協調的送信プリコーダを協調セットに示してもよい。その一方で、ｅＮＢがＷＴＲＵに関する協調セットを認識していない、または協調の使用すら認識していないケースに関しては、協調セットＷＴＲＵは、プリコーディングを選択してもよい。協調セットＷＴＲＵは、ソースＷＴＲＵのプリコーダ情報を使用してもよい。協調セット内のいずれのソースＷＴＲＵも、自身の送信のためのＵＬグラントを提供されてもよい。ＷＴＲＵは、自身の送信のためにプリコーダ情報を、おそらくは、スケジューリング期間内に行われる任意の協調的送信とともに使用してもよい。スケジューリング期間は、ＵＬグラントが受信される瞬間から、ＵＬグラントの協調的送信が実行される瞬間までの全てのサブフレームを含むタイム期間と解釈されてもよい。

例えば、ＷＴＲＵが、サブフレームｎにおいてＵＬグラントを受信し、サブフレームｎ＋ｋ₁において自身のデータを共有してもよく、協調セットは、サブフレームｎ＋ｋ₁＋ｋ₂において協調的に送信してもよい。協調セットＷＴＲＵが、サブフレームｎ＋ｋ₁＋ｋ₂における協調的送信のためにｎからｎ＋ｋ₁＋ｋ₂のウィンドウ内で自身のＵＬ送信のうちのいずれかのために入手されたプリコーダを使用してもよい。協調セットＷＴＲＵは、別々の協調的送信ごとに、可能なプリコーダのセットを循環（cycle through）してもよい。可能なプリコーダのセットは、一実施形態においてはｅＮＢによって、構成されてもよい。

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

Claims (20)

1. 第１の無線送信／受信ユニット（ＷＴＲＵ）によって実行される複数段階協調的データ送信のための方法であって、
   発展型Ｎｏｄｅ Ｂ（ｅＮＢ）から前記第１のＷＴＲＵによって、協調的セットＩＤを含む協調的セット構成情報を受信するステップと、
   前記ｅＮＢから前記第１のＷＴＲＵによって、共有段階において第１のデータ送信についてのリソース割り当てを受信するステップと、
   前記受信されたリソース割り当てに示されるリソースを使用して、前記共有段階の間に前記第１のデータ送信を送信するステップと、
   前記第１のＷＴＲＵによって、前記共有段階の間に少なくとも第２のＷＴＲＵから第２のデータ送信を受信するステップと、
   前記第２のデータ送信が前記第１のＷＴＲＵによって成功して受信されることを条件に、協調的送信段階の間に、前記第２のＷＴＲＵと協調して第３のデータ送信を送信するステップと
   を備えたことを特徴とする方法。
2. 前記第３のデータ送信は、前記ｅＮＢに送信されることを特徴とする請求項１に記載の方法。
3. 前記共有段階の間に、第４のデータ送信が第３のＷＴＲＵから前記第１のＷＴＲＵによって成功して受信されることを条件に、前記第３のＷＴＲＵと協調して前記第４のデータ送信の第４のデータを再送信するステップをさらに備えたことを特徴とする請求項１に記載の方法。
4. 前記ｅＮＢから前記第１のＷＴＲＵによって、前記第１のデータ送信に対応する確認応答または否定応答を含むフィードバック情報を受信するステップをさらに備えたことを特徴とする請求項１に記載の方法。
5. 前記第３のデータ送信は、
   前記第１のデータ送信に対応する第１のデータと、
   前記第２のデータ送信に対応する第２のデータと、を含み、
   前記第１のデータおよび第２のデータは、決定された時間インスタンスにおいて送信される
   ことを特徴とする請求項１に記載の方法。
6. 前記ｅＮＢから前記第１のＷＴＲＵによって、前記決定された時間インスタンスのインジケーションを有する制御メッセージを受信するステップをさらに備えたことを特徴とする請求項５に記載の方法。
7. 強調するセットマスタから前記第１のＷＴＲＵによって、前記決定された時間インスタンスのインジケーションを有する制御メッセージを受信するステップをさらに備えたことを特徴とする請求項５に記載の方法。
8. 前記受信された確認応答が前記第３のデータ送信の成功した受信を示すことを条件に、前記第１のデータを前記ｅＮＢに再送信しないステップをさらに備えたことを特徴とする請求項７に記載の方法。
9. 複数段階協調的データ送信のために構成された第１の無線送信／受信ユニット（ＷＴＲＵ）であって、
   発展型Ｎｏｄｅ Ｂ（ｅＮＢ）から前記第１のＷＴＲＵによって、協調的セットＩＤを含む協調的セット構成情報を受信するように構成された受信機と、
   前記ｅＮＢから前記第１のＷＴＲＵによって、共有段階において第１のデータ送信についてのリソース割り当てを受信するように構成された前記受信機と、
   前記受信されたリソース割り当てに示されるリソースを使用して、前記共有段階の間に前記第１のデータ送信を送信するように構成された送信機と、
   前記第１のＷＴＲＵによって、前記共有段階の間に少なくとも第２のＷＴＲＵから第２のデータ送信を受信するように構成された前記受信機と、
   前記第２のデータ送信が前記第１のＷＴＲＵによって成功して受信されることを条件に、協調的送信段階の間に、前記第２のＷＴＲＵと協調して第３のデータ送信を送信するように構成された前記送信機と
   を備えたことを特徴とするＷＴＲＵ。
10. 前記第３のデータ送信は、前記ｅＮＢに送信されることを特徴とする請求項９に記載のＷＴＲＵ。
11. 前記共有段階の間に、第４のデータ送信が第３のＷＴＲＵから前記第１のＷＴＲＵによって成功して受信されることを条件に、前記第３のＷＴＲＵと協調して前記第４のデータ送信の第４のデータを再送信することを特徴とする請求項９に記載のＷＴＲＵ。
12. 第３のＷＴＲＵが前記共有段階の前記第１のデータ送信の復号に成功することができないことを条件に、前記第３のデータ送信は、前記第３のＷＴＲＵではなく前記第２のＷＴＲＵと協調して送信されることを特徴とする請求項９に記載のＷＴＲＵ。
13. 前記第３のデータ送信は、
    前記第１のデータ送信に対応する第１のデータと、
    前記第２のデータ送信に対応する第２のデータと、を含み、
    前記第１のデータおよび第２のデータは、決定された時間インスタンスにおいて送信される
    ことを特徴とする請求項９に記載のＷＴＲＵ。
14. 前記ｅＮＢから前記第１のＷＴＲＵによって、前記決定された時間インスタンスのインジケーションを有する制御メッセージを受信するように構成された前記受信機をさらに備えたことを特徴とする請求項１３に記載のＷＴＲＵ。
15. 強調するセットマスタから前記ＷＴＲＵによって、前記決定された時間インスタンスのインジケーションを有する制御メッセージを受信するように構成された前記受信機をさらに備えたことを特徴とする請求項１３に記載のＷＴＲＵ。
16. 前記ＷＴＲＵによって、前記第１のデータ送信に対応する確認応答または否定応答を含むフィードバック情報を受信するように構成された前記受信機をさらに備えたことを特徴とする請求項９に記載のＷＴＲＵ。
17. 第１の無線送信／受信ユニット（ＷＴＲＵ）によって実行される複数段階協調的データ送信のための方法であって、
    協調的セットマスタから前記ＷＴＲＵによって、協調的セットＩＤを含む協調的セット構成情報を受信するステップと、
    前記協調的セットマスタから前記ＷＴＲＵによって、共有段階において第１のデータ送信についてのリソース割り当てを受信するステップと、
    前記受信されたリソース割り当てに示されるリソースを使用して、前記共有段階の間に前記第１のデータ送信を送信するステップと、
    前記第１のＷＴＲＵによって、前記共有段階の間に少なくとも第２のＷＴＲＵから第２のデータ送信を受信するステップと、
    前記第２のデータ送信が前記第１のＷＴＲＵによって成功して受信されることを条件に、協調的送信段階の間に、前記第２のＷＴＲＵと協調して第３のデータ送信を送信するステップと
    を備えたことを特徴とする方法。
18. 前記第３のデータ送信は、発展型Ｎｏｄｅ Ｂ（ｅＮＢ）に送信されることを特徴とする請求項１７に記載の方法。
19. 第３のＷＴＲＵが前記共有段階の間に送信されたデータを成功して復号することを条件に、前記第３のデータ送信は、前記第２のＷＴＲＵおよび前記第３のＷＴＲＵと協調して送信されることを特徴とする請求項１７に記載の方法。
20. 第３のＷＴＲＵが前記共有段階の間に送信されたデータを成功して復号することができないことを条件に、前記第３のデータ送信は、前記第３のＷＴＲＵではなく前記第２のＷＴＲＵと協調して送信されることを特徴とする請求項１７に記載の方法。

Images