JP6749388B2 - アップリンク送信インジケーション - Google Patents

Description

本発明は、２つの別個の無線システムが共有する帯域でのデータの送受信であって、２つの別個の無線システムが共有していることにより、スケジューリングされたデータの場合であっても送信前にリッスンビフォアトーク（listen before talk）手順が利用されるデータの送受信に関する。

＜ロングタームエボリューション（ＬＴＥ）＞
ＷＣＤＭＡ（登録商標）無線アクセス技術をベースとする第３世代の移動通信システム（３Ｇ）が世界中で広範な規模で配備されている。この技術を機能強化または発展・進化させるうえでの最初のステップとして、高速ダウンリンクパケットアクセス（ＨＳＤＰＡ）と、エンハンストアップリンク（高速アップリンクパケットアクセス（ＨＳＵＰＡ）とも称する）とが導入され、これにより、極めて競争力の高い無線アクセス技術が提供されている。

ユーザからのますます増大する需要に対応し、新しい無線アクセス技術に対する競争力を確保する目的で、３ＧＰＰは、ロングタームエボリューション（ＬＴＥ）と称される新しい移動通信システムを導入した。ＬＴＥは、今後１０年間にわたり、データおよびメディアの高速伝送ならびに大容量の音声サポートに要求されるキャリアを提供するように設計されている。高いビットレートを提供する能力は、ＬＴＥにおける重要な方策である。

ＬＴＥ（ロングタームエボリューション）に関する作業項目（ＷＩ）の仕様は、Ｅ−ＵＴＲＡ（Evolved UMTS Terrestrial Radio Access（ＵＴＲＡ）：進化したＵＭＴＳ地上無線アクセス）およびＥ−ＵＴＲＡＮ（Evolved UMTS Terrestrial Radio Access Network（ＵＴＲＡＮ）：進化したＵＭＴＳ地上無線アクセスネットワーク）と称され、最終的にリリース８（ＬＴＥリリース８）として公開されている。ＬＴＥシステムは、パケットベースの効率的な無線アクセスおよび無線アクセスネットワークであり、ＩＰベースの全機能を低遅延かつ低コストで提供する。ＬＴＥでは、与えられたスペクトルを用いてフレキシブルなシステム配備を達成するために、スケーラブルな複数の送信帯域幅（例えば、１．４ＭＨｚ、３．０ＭＨｚ、５．０ＭＨｚ、１０．０ＭＨｚ、１５．０ＭＨｚ、および２０．０ＭＨｚ）が指定されている。ダウンリンクには、ＯＦＤＭ（Orthogonal Frequency Division Multiplexing：直交周波数分割多重）をベースとする無線アクセスが採用されている。かかる無線アクセスを採用する理由は、この無線アクセスが低いシンボルレートのため本質的にマルチパス干渉（ＭＰＩ：Multipath Interference）を受けにくいこと、サイクリックプレフィックス（ＣＰ）が使用されていること、および、さまざまな送信帯域幅の構成に対応可能なことである。アップリンクには、ＳＣ−ＦＤＭＡ（Single-Carrier Frequency Division Multiple Access：シングルキャリア周波数分割多元接続）をベースとする無線アクセスが採用されている。ユーザ機器（ＵＥ）の送信出力が限られていることを考えれば、ピークデータレートを向上させることよりも広いカバレッジエリアを提供することが優先されるからである。ＬＴＥリリース８／９では、数多くの主要なパケット無線アクセス技術（例えば、ＭＩＭＯ（多入力多出力）チャネル伝送技術）が採用され、高効率の制御シグナリング構造が達成されている。

＜ＬＴＥのアーキテクチャ＞
ＬＴＥの全体的なアーキテクチャは、図１に示してある。Ｅ−ＵＴＲＡＮは、ｅＮｏｄｅＢから構成され、ｅＮｏｄｅＢは、ＵＥ向けの、Ｅ−ＵＴＲＡのユーザプレーン（ＰＤＣＰ／ＲＬＣ／ＭＡＣ／ＰＨＹ）および制御プレーン（ＲＲＣ）のプロトコルを終端処理する。ｅＮｏｄｅＢ（ｅＮＢ）は、物理（ＰＨＹ）レイヤ、媒体アクセス制御（ＭＡＣ）レイヤ、無線リンク制御（ＲＬＣ）レイヤ、およびパケットデータ制御プロトコル（ＰＤＣＰ）レイヤ（これらのレイヤはユーザプレーンのヘッダ圧縮および暗号化の機能を含む）をホストする。ｅＮＢは、制御プレーンに対応する無線リソース制御（ＲＲＣ）機能も提供する。ｅＮＢは、無線リソース管理、アドミッション制御、スケジューリング、交渉によるアップリンクＱｏＳ（サービス品質）の実施、セル情報のブロードキャスト、ユーザプレーンデータおよび制御プレーンデータの暗号化／復号、ダウンリンク／アップリンクのユーザプレーンパケットヘッダの圧縮／復元など、多くの機能を実行する。複数のｅＮｏｄｅＢは、Ｘ２インタフェースによって互いに接続されている。

また、複数のｅＮｏｄｅＢは、Ｓ１インタフェースによってＥＰＣ（Evolved Packet Core：進化したパケットコア）、より具体的には、Ｓ１−ＭＭＥによってＭＭＥ（Mobility Management Entity：移動管理エンティティ）、Ｓ１−Ｕによってサービングゲートウェイ（ＳＧＷ：Serving Gateway）に接続されている。Ｓ１インタフェースは、ＭＭＥ／サービングゲートウェイとｅＮｏｄｅＢとの間の多対多関係をサポートする。ＳＧＷは、ユーザデータパケットをルーティングして転送する一方で、ｅＮｏｄｅＢ間のハンドオーバー時におけるユーザプレーンのモビリティアンカーとして機能し、さらに、ＬＴＥと他の３ＧＰＰ技術との間のモビリティのためのアンカー（Ｓ４インタフェースを終端させ、２Ｇ／３ＧシステムとＰＤＮ ＧＷとの間でトラフィックを中継する）として機能する。ＳＧＷは、アイドル状態のユーザ機器に対しては、ダウンリンクデータ経路を終端させ、そのユーザ機器へのダウンリンクデータが到着したときにページングをトリガーする。ＳＧＷは、ユーザ機器のコンテキスト（例えばＩＰベアラサービスのパラメータ、ネットワーク内部ルーティング情報）を管理および格納する。さらに、ＳＧＷは、合法的傍受の場合にユーザトラフィックの複製を実行する。

ＭＭＥは、ＬＴＥのアクセスネットワークの主要な制御ノードである。ＭＭＥは、アイドルモードのユーザ機器の追跡およびページング手順（再送信を含む）の役割を担う。ＭＭＥは、ベアラのアクティブ化／非アクティブ化プロセスに関与し、さらには、最初のアタッチ時と、コアネットワーク（ＣＮ）ノードの再配置を伴うＬＴＥ内ハンドオーバー時とに、ユーザ機器のＳＧＷを選択する役割も担う。ＭＭＥは、（ＨＳＳと対話することによって）ユーザを認証する役割を担う。非アクセス層（ＮＡＳ：Non-Access Stratum）シグナリングはＭＭＥにおいて終端され、ＭＭＥは、一時的なＩＤを生成してユーザ機器に割り当てる役割も担う。ＭＭＥは、サービスプロバイダの公衆陸上移動網（ＰＬＭＮ：Public Land Mobile Network）に入るためのユーザ機器の認証をチェックし、ユーザ機器のローミング制約を実施する。ＭＭＥは、ＮＡＳシグナリングの暗号化／完全性保護においてネットワーク内の終端点であり、セキュリティキーの管理を行う。シグナリングの合法的傍受も、ＭＭＥによってサポートされる。さらに、ＭＭＥは、ＬＴＥのアクセスネットワークと２Ｇ／３Ｇのアクセスネットワークとの間のモビリティのための制御プレーン機能を提供し、ＳＧＳＮからのＳ３インタフェースを終端させる。さらに、ＭＭＥは、ローミングするユーザ機器のためのホームＨＳＳに向かうＳ６ａインタフェースを終端させる。

＜ＬＴＥにおけるコンポーネントキャリアの構造＞
３ＧＰＰ ＬＴＥシステムのダウンリンクコンポーネントキャリアは、いわゆるサブフレームにおける時間−周波数領域でさらに分割される。３ＧＰＰ ＬＴＥでは、各サブフレームは、図２に示すように２つのダウンリンクスロットに分割されており、第１のダウンリンクスロットが、第１のＯＦＤＭシンボル内に制御チャネル領域（ＰＤＣＣＨ領域）を含んでいる。各サブフレームは、時間領域における所定の数のＯＦＤＭシンボルから構成され（３ＧＰＰ ＬＴＥ（リリース８）では１２個または１４個のＯＦＤＭシンボル）、各ＯＦＤＭシンボルはコンポーネントキャリアの帯域幅全体に広がる。したがってＯＦＤＭシンボルそれぞれは、それぞれのサブキャリアで送信される複数の変調シンボルから構成される。ＬＴＥでは、各スロットにおける送信信号は、Ｎ^ＤＬ _ＲＢ×Ｎ^ＲＢ _ｓｃ本のサブキャリアとＮ^ＤＬ _ｓｙｍｂ個のＯＦＤＭシンボルのリソースグリッドによって記述される。Ｎ^ＤＬ _ＲＢは、帯域幅の中のリソースブロックの数である。数Ｎ^ＤＬ _ＲＢは、セルにおいて設定されているダウンリンク送信帯域幅に依存し、Ｎ^{ｍｉｎ，ＤＬ} _ＲＢ≦Ｎ^ＤＬ _ＲＢ≦Ｎ^{ｍａｘ，ＤＬ} _ＲＢを満たし、この場合、Ｎ^{ｍｉｎ，ＤＬ} _ＲＢ＝６およびＮ^{ｍａｘ，ＤＬ} _ＲＢ＝１１０は、それぞれ、現在のバージョンの仕様によってサポートされている最小ダウンリンク帯域幅および最大ダウンリンク帯域幅である。Ｎ^ＲＢ _ｓｃは、１個のリソースブロックの中のサブキャリアの数である。通常のサイクリックプレフィックスのサブフレーム構造の場合、Ｎ^ＲＢ _ｓｃ＝１２、Ｎ^ＤＬ _ｓｙｍｂ＝７である。

例えば３ＧＰＰロングタームエボリューション（ＬＴＥ）において使用されるような、例えばＯＦＤＭを使用する、マルチキャリア通信システムを想定すると、スケジューラによって割り当てることができるリソースの最小単位は、１つの「リソースブロック」である。物理リソースブロック（ＰＲＢ）は、図２に例示したように、時間領域における連続するＯＦＤＭシンボル（例えば７個のＯＦＤＭシンボル）および周波数領域における連続するサブキャリア（例えばコンポーネントキャリアの１２本のサブキャリア）として定義される。したがって３ＧＰＰ ＬＴＥ（リリース８）では、物理リソースブロックはリソースエレメントから構成され、時間領域における１つのスロットおよび周波数領域における１８０ｋＨｚに対応する（ダウンリンクリソースグリッドに関するさらなる詳細は、例えば非特許文献１の６．２節（３ＧＰＰのウェブサイト（http://www.3gpp.org）で入手可能であり、参照により本明細書に組み込まれている）を参照）。

１つのサブフレームが２つのスロットで構成されているため、いわゆる「通常の」ＣＰ（サイクリックプレフィックス）が使用されるときにはサブフレーム内に１４個のＯＦＤＭシンボルが存在し、いわゆる「拡張」ＣＰが使用されるときにはサブフレーム内に１２個のＯＦＤＭシンボルが存在する。専門用語を目的として、以下で、サブフレーム全体に広がる同じ連続するサブキャリアと同等の時間−周波数リソースは、「リソースブロックペア」または同意義の「ＲＢペア」もしくは「ＰＲＢペア」と呼ばれる。

「コンポーネントキャリア」という用語は、周波数領域におけるいくつかのリソースブロックの組合せを示す。ＬＴＥの将来のリリースでは、「コンポーネントキャリア」という用語はもはや使用されず、その代わりに、その専門用語はダウンリンクおよびオプションでアップリンクリソースの組合せを示す「セル」に変更される。ダウンリンクリソースのキャリア周波数とアップリンクリソースのキャリア周波数との間のリンク付けは、ダウンリンクリソースで送信されるシステム情報において指示される。

コンポーネントキャリアの構造に関する同様の想定が以降のリリースにも適用される。

＜より広い帯域幅のサポートのためのＬＴＥ−Ａにおけるキャリアアグリゲーション＞
世界無線通信会議２００７（ＷＲＣ−０７）において、ＩＭＴ−Ａｄｖａｎｃｅｄの周波数スペクトルが決定された。ＩＭＴ−Ａｄｖａｎｃｅｄのための全体的な周波数スペクトルは決定されたが、実際に利用可能な周波数帯域幅は、地域や国によって異なる。しかしながら、利用可能な周波数スペクトルのアウトラインの決定に続いて、３ＧＰＰ（第３世代パートナーシッププロジェクト）において無線インタフェースの標準化が開始された。３ＧＰＰ ＴＳＧ ＲＡＮ ＃３９会合において、「Further Advancements for E-UTRA (LTE-Advanced)」に関する検討項目の記述が承認された。この検討項目は、Ｅ−ＵＴＲＡを進化・発展させるうえで（例えば、ＩＭＴ−Ａｄｖａｎｃｅｄの要求条件を満たすために）考慮すべき技術要素をカバーしている。

ＬＴＥ−Ａｄｖａｎｃｅｄシステムがサポートすることができる帯域幅は１００ＭＨｚであり、一方、ＬＴＥシステムは２０ＭＨｚのみをサポートすることができる。今日、無線スペクトルの不足がワイヤレスネットワークの開発のボトルネックになっており、結果として、ＬＴＥ−Ａｄｖａｎｃｅｄシステムのために十分広いスペクトル帯域を見つけることが困難である。したがって、より広い無線スペクトル帯域を獲得するための方法を見つけることが急務であり、キャリアアグリゲーション機能が解決策であり得る。

キャリアアグリゲーションでは、最大で１００ＭＨｚのより広い送信帯域幅をサポートする目的で、２つ以上のコンポーネントキャリアがアグリゲートされる。ＬＴＥ−Ａｄｖａｎｃｅｄシステムでは、ＬＴＥシステムにおけるいくつかのセルが、より広い１つのチャネルにアグリゲートされており、ＬＴＥにおけるこれらのセルは異なる周波数帯域にありうるが、このチャネルは１００ＭＨｚに対して十分に広い。

少なくともコンポーネントキャリアの帯域幅がＬＴＥリリース８／９のセルのサポートされる帯域幅を超えないときには、すべてのコンポーネントキャリアをＬＴＥリリース８／９互換であるように設定することができる。ユーザ機器によってアグリゲートされるすべてのコンポーネントキャリアが必ずしもＬＴＥリリース８／９互換でなくてよい。リリース８／９のユーザ機器がコンポーネントキャリアにキャンプオンすることを回避するため、既存のメカニズム（例：バーリング）を使用することができる。

ユーザ機器は、自身の能力に応じて１つまたは複数のコンポーネントキャリア（複数のサービングセルに対応する）を同時に受信または送信することができる。キャリアアグリゲーションのための受信能力および／または送信能力を備えた、ＬＴＥ−Ａリリース１０のユーザ機器は、複数のサービングセル上で同時に受信および／または送信することができ、これに対して、ＬＴＥリリース８／９のユーザ機器は、コンポーネントキャリアの構造がリリース８／９の仕様に従う場合、１つのみのサービングセル上で受信および送信を行うことができる。

キャリアアグリゲーションは、連続するコンポーネントキャリアおよび不連続なコンポーネントキャリアの両方においてサポートされ、各コンポーネントキャリアは、（３ＧＰＰ ＬＴＥ（リリース８／９）の計算方式（numerology）を使用して）周波数領域における最大１１０個のリソースブロックに制限される。

同じｅＮｏｄｅＢ（基地局）から送信される、場合によってはアップリンクおよびダウンリンクにおいて異なる帯域幅の異なる数のコンポーネントキャリアをアグリゲートするように、３ＧＰＰ ＬＴＥ−Ａ（リリース１０）互換のユーザ機器を設定することが可能である。設定することのできるダウンリンクコンポーネントキャリアの数は、ユーザ機器のダウンリンクのアグリゲーション能力に依存する。逆に、設定することのできるアップリンクコンポーネントキャリアの数は、ユーザ機器のアップリンクのアグリゲーション能力に依存する。現時点では、ダウンリンクコンポーネントキャリアよりもアップリンクコンポーネントキャリアが多い状態に移動端末を設定することはできない。一般的なＴＤＤ配備では、コンポーネントキャリアの数および各コンポーネントキャリアの帯域幅は、アップリンクとダウンリンクとで同じである。同じｅＮｏｄｅＢから送信されるコンポーネントキャリアは、同じカバレッジを提供する必要はない。

連続的にアグリゲートされるコンポーネントキャリアの中心周波数の間隔は、３００ｋＨｚの倍数である。これは、３ＧＰＰ ＬＴＥ（リリース８／９）の１００ｋＨｚの周波数ラスターとの互換性を保つと同時に、１５ｋＨｚ間隔のサブキャリアの直交性を維持するためである。アグリゲーションのシナリオによっては、連続するコンポーネントキャリアの間に少数の使用されないサブキャリアを挿入することによって、ｎ×３００ｋＨｚの間隔あけを容易にすることができる。

複数のキャリアをアグリゲートする影響は、ＭＡＣ層に及ぶのみである。ＭＡＣ層には、アップリンクおよびダウンリンクの両方において、アグリゲートされるコンポーネントキャリアごとに１つのＨＡＲＱエンティティが要求される。コンポーネントキャリアあたりのトランスポートブロックは最大１個である（アップリンクにおけるＳＵ−ＭＩＭＯを使用しない場合）。トランスポートブロックおよびそのＨＡＲＱ再送信（発生時）は、同じコンポーネントキャリアにマッピングする必要がある。

キャリアアグリゲーションが設定されているとき、移動端末はネットワークとの１つのＲＲＣ接続のみを有する。ＲＲＣ接続の確立／再確立時、１つのセルが、ＬＴＥリリース８／９と同様に、セキュリティ入力（１つのＥＣＧＩ、１つのＰＣＩ、および１つのＡＲＦＣＮ）と、非アクセス層（ＮＡＳ）モビリティ情報（例：ＴＡＩ）とを提供する。ＲＲＣ接続の確立／再確立の後、そのセルに対応するコンポーネントキャリアは、ダウンリンクプライマリセル（ＰＣｅｌｌ）と称される。接続状態では、ユーザ機器あたりつねに１つのダウンリンクＰＣｅｌｌ（ＤＬ ＰＣｅｌｌ）および１つのアップリンクＰＣｅｌｌ（ＵＬ ＰＣｅｌｌ）が設定される。コンポーネントキャリアの設定されたセット内において、他のセルはセカンダリセル（ＳＣｅｌｌ）と呼ばれ、ＳＣｅｌｌのキャリアはダウンリンクセカンダリコンポーネントキャリア（ＤＬ ＳＣＣ）およびアップリンクセカンダリコンポーネントキャリア（ＵＬ ＳＣＣ）である。１基のＵＥに対して、最大５つのサービングセル（ＰＣｅｌｌを含む）を設定することができる。

ダウンリンクＰＣｅｌｌおよびアップリンクＰＣｅｌｌの特徴は以下のとおりである。
・ＳＣｅｌｌごとに、ダウンリンクリソースに加えてアップリンクリソースのユーザ機器による使用を設定することができる。したがって、設定されるＤＬ ＳＣＣの数はＵＬ ＳＣＣの数よりもつねに大きいかまたは等しく、アップリンクリソースのみを使用するようにＳＣｅｌｌを設定することはできない。
・ダウンリンクＰＣｅｌｌは、ＳＣｅｌｌとは異なり非アクティブ化することはできない。
・ダウンリンクＰＣｅｌｌにおいてレイリーフェージング（ＲＬＦ）が発生すると再確立がトリガーされるが、ダウンリンクＳＣｅｌｌにＲＬＦが発生しても再確立はトリガーされない。
・非アクセス層情報はダウンリンクＰＣｅｌｌから取得される。
・ＰＣｅｌｌは、ハンドオーバー手順（すなわちセキュリティキー変更およびＲＡＣＨ手順）によってのみ変更することができる。
・ＰＣｅｌｌは、ＰＵＣＣＨの送信に使用される。
・アップリンクＰＣｅｌｌは、第１層のアップリンク制御情報の送信に使用される。
・ＵＥの観点からは、各アップリンクリソースは１つのサービングセルにのみ属する。

コンポーネントキャリアの設定および再設定、ならびに追加および削除は、ＲＲＣによって実行することができる。アクティブ化および非アクティブ化は、ＭＡＣ制御要素を介して行われる。ＬＴＥ内ハンドオーバー時、ＲＲＣによって、ターゲットセルで使用するためのＳＣｅｌｌを追加、削除、または再設定することもできる。新しいＳＣｅｌｌを追加するときには、ＳＣｅｌｌのシステム情報（送信／受信に必要である）を送るために専用のＲＲＣシグナリングが使用される（ＬＴＥリリース８／９におけるハンドオーバー時と同様）。１基のＵＥにＳＣｅｌｌが追加されるとき、各ＳＣｅｌｌにはサービングセルインデックスが設定される。ＰＣｅｌｌはつねにサービングセルインデックス０を有する。

キャリアアグリゲーションを使用するようにユーザ機器が設定されているとき、アップリンクコンポーネントキャリアとダウンリンクコンポーネントキャリアの少なくとも一対がつねにアクティブである。この対のうちのダウンリンクコンポーネントキャリアは、「ダウンリンクアンカーキャリア」と称されることもある。同じことがアップリンクについてもあてはまる。

キャリアアグリゲーションが設定されているとき、同時に複数のコンポーネントキャリアについてユーザ機器をスケジューリングすることができるが、同時に進行させることのできるランダムアクセス手順は最大で１つである。クロスキャリアスケジューリング（cross-carrier scheduling）では、コンポーネントキャリアのＰＤＣＣＨによって他のコンポーネントキャリアのリソースをスケジューリングすることができる。この目的のため、それぞれのＤＣＩフォーマットにコンポーネントキャリア識別フィールド（「ＣＩＦ」と称する）が導入されている。

クロスキャリアスケジューリングが行われていないときには、アップリンクコンポーネントキャリアとダウンリンクコンポーネントキャリアのリンク（ＲＲＣシグナリングによって確立される）によって、グラントが適用されるアップリンクコンポーネントキャリアを識別することができる。アップリンクコンポーネントキャリアへのダウンリンクコンポーネントキャリアのリンクは、必ずしも１対１である必要はない。言い換えれば、同じアップリンクコンポーネントキャリアに複数のダウンリンクコンポーネントキャリアをリンクすることができる。一方で、１つのダウンリンクコンポーネントキャリアは、１つのアップリンクコンポーネントキャリアのみにリンクすることができる。

＜第１層／第２層制御シグナリング＞
スケジューリングされたユーザに、ユーザの割当て状態、トランスポートフォーマット、およびその他の送信関連情報（例：ＨＡＲＱ情報、送信電力制御（ＴＰＣ）コマンド）を知らせる目的で、第１層／第２層制御シグナリングがデータと一緒にダウンリンクで送信される。第１層／第２層制御シグナリングは、サブフレーム内にダウンリンクデータと一緒に多重化される（ユーザ割当てがサブフレーム単位で変化しうるものと想定する）。なお、ユーザ割当てをＴＴＩ（送信時間間隔）ベースで実行することもでき、その場合、ＴＴＩ長をサブフレームの倍数とすることができることに留意されたい。ＴＴＩ長を、サービスエリア内ですべてのユーザに対して一定としてもよいし、異なるユーザに対して異なる長さとしてもよいし、ユーザ毎に動的としてもよい。第１層／第２層制御シグナリングは、一般的にはＴＴＩあたり１回送信するのみでよい。以下では、一般性を失うことなく、ＴＴＩが１サブフレームに等しいものと想定する。

第１層／第２層制御シグナリングは、物理ダウンリンク制御チャネル（ＰＤＣＣＨ：Physical Downlink Control CHannel）で送信される。

ＰＤＣＣＨは、ダウンリンク制御情報（ＤＣＩ）としてメッセージを伝送し、ＤＣＩには、ほとんどの場合、移動端末またはＵＥのグループを対象とするリソース割当ておよびその他の制御情報が含まれる。一般的には、いくつかのＰＤＣＣＨを１つのサブフレーム内で送信することができる。

なお、３ＧＰＰ ＬＴＥでは、アップリンクデータ送信のための割当て（アップリンクスケジューリンググラントまたはアップリンクリソース割当てとも称する）も、ＰＤＣＣＨで送信されることに留意されたい。さらに、リリース１１ではＥＰＤＣＣＨが導入され、ＥＰＤＣＣＨは基本的にＰＤＣＣＨと同じ機能を果たし（すなわち第１層／第２層制御シグナリングを伝える）、ただし送信方法の細部はＰＤＣＣＨとは異なる。さらなる詳細については、特に、非特許文献１および非特許文献２（３ＧＰＰのウェブサイト（www.3gpp.org）で入手可能であり、参照により本明細書に援用されている）に記載されている。したがって、背景技術および実施形態の中で概説したほとんどの項目は、特に明記しない限り、ＰＤＣＣＨおよびＥＰＤＣＣＨ、または第１層／第２層制御シグナリングを伝える他の手段にあてはまる。

アップリンク無線リソースまたはダウンリンク無線リソースを割り当てる目的で第１層／第２層制御シグナリングで送られる情報は（特にＬＴＥ（−Ａ）リリース１０）、一般的には以下の項目に分類することができる。
− ユーザ識別情報： 割り当てる対象のユーザを示す。この情報は、一般には、ＣＲＣをユーザ識別情報によってマスクすることによってチェックサムに含まれる。
− リソース割当て情報： ユーザに割り当てられるリソース（例：リソースブロック（ＲＢ））を示す。あるいはこの情報はリソースブロック割当て（ＲＢＡ）と称される。なお、ユーザに割り当てられるリソースブロック（ＲＢ）の数は動的とすることができる。
− キャリアインジケータ： 第１のキャリアで送信される制御チャネルが、第２のキャリアに関連するリソース（すなわち第２のキャリアのリソースまたは第２のキャリアに関連するリソース）を割り当てる場合に使用される（クロスキャリアスケジューリング）。
− 変調・符号化方式： 採用される変調方式および符号化率を決める。
− ＨＡＲＱ情報： データパケットまたはその一部の再送信時に特に有用である、新規データインジケータ（ＮＤＩ）や冗長バージョン（ＲＶ）など。
− 電力制御コマンド： 割り当てられたアップリンクのデータまたは制御情報の送信時の送信電力を調整する。
− 参照信号情報： 割当てに関連する参照信号の送信または受信に使用される、適用されたサイクリックシフトや直交カバーコードインデックスなど。
− アップリンク割当てインデックスまたはダウンリンク割当てインデックス： 割当ての順序を識別するために使用され、ＴＤＤシステムにおいて特に有用である。
− ホッピング情報： 例えば、周波数ダイバーシチを増大させる目的でリソースホッピングを適用するか否か、および適用方法の指示情報。
− ＣＳＩ要求： 割り当てられるリソースにおいてチャネル状態情報を送信するようにトリガーするために使用される。
− マルチクラスタ情報： シングルクラスタ（リソースブロックの連続的なセット）またはマルチクラスタ（連続的なリソースブロックの少なくとも２つの不連続なセット）で送信を行うかを指示して制御するために使用されるフラグである。マルチクラスタ割当ては、３ＧＰＰ ＬＴＥ−（Ａ）リリース１０によって導入された。

なお、上記リストは、すべてを網羅したものではなく、また、使用されるＤＣＩフォーマットによっては、リストした情報項目すべてを各ＰＤＣＣＨ送信に含める必要がないことに留意されたい。

ダウンリンク制御情報はいくつかのフォーマットの形をとり、これらのフォーマットは、全体のサイズにおいて、また、上述したフィールドに含まれる情報において異なる。ＬＴＥにおいて現在定義されている各ＤＣＩフォーマットは、以下のとおりであり、非特許文献３の５．３．３．１節（現在のバージョン１２．４．０が３ＧＰＰのウェブサイト（http://www.3gpp.org）で入手可能であり、参照により本明細書に援用されている）に詳しく記載されている。さらに、ＤＣＩフォーマットと、ＤＣＩにおいて送信される具体的な情報に関するさらなる詳細については、上に挙げた技術規格、または非特許文献４の９．３章（参照により本明細書に援用されている）を参照されたい。
− フォーマット０： ＤＣＩフォーマット０は、アップリンク送信モード１または２におけるシングルアンテナポート送信を使用するＰＵＳＣＨのためのリソースグラントを送信するために使用される。
− フォーマット１： ＤＣＩフォーマット１は、単一コードワードＰＤＳＣＨの送信（ダウンリンク送信モード１，２，７）のためのリソース割当てを送信するために使用される。
− フォーマット１Ａ： ＤＣＩフォーマット１Ａは、単一コードワードＰＤＳＣＨ送信のためのリソース割当てをコンパクトにシグナリングする目的と、競合のないランダムアクセスのために専用プリアンブルシグネチャ（dedicated preamble signature）を移動端末に割り当てる目的とに使用される（すべての送信モード）。
− フォーマット１Ｂ： ＤＣＩフォーマット１Ｂは、ランク１送信による閉ループプリコーディングを使用してのＰＤＳＣＨ送信（ダウンリンク送信モード６）のためのリソース割当てをコンパクトにシグナリングするために使用される。送信される情報はフォーマット１Ａと同じであるが、それに加えて、ＰＤＳＣＨの送信に適用されるプリコーディングベクトルのインジケータが送信される。
− フォーマット１Ｃ： ＤＣＩフォーマット１Ｃは、ＰＤＳＣＨ割当てを極めてコンパクトに送信するために使用される。フォーマット１Ｃが使用されるとき、ＰＤＳＣＨ送信は、ＱＰＳＫ変調の使用に制約される。このフォーマットは、例えば、ページングメッセージをシグナリングしたり、システム情報メッセージをブロードキャストしたりするために使用される。
− フォーマット１Ｄ： ＤＣＩフォーマット１Ｄは、マルチユーザＭＩＭＯを使用してのＰＤＳＣＨ送信のためのリソース割当てをコンパクトにシグナリングするために使用される。送信される情報は、フォーマット１Ｂの場合と同じであるが、プリコーディングベクトルのインジケータのビットのうちの１つの代わりに、データシンボルに電力オフセットが適用されるかを示すための１個のビットが存在する。この構成は、２基のユーザ機器の間で送信電力が共有されるか否かを示すために必要である。ＬＴＥの今後のバージョンでは、この構成は、より多くの数のユーザ機器の間で電力を共有する場合に拡張されうる。
− フォーマット２： ＤＣＩフォーマット２は、閉ループＭＩＭＯ動作の場合にＰＤＳＣＨのためのリソース割当てを送信するために使用される（送信モード４）。
− フォーマット２Ａ： ＤＣＩフォーマット２Ａは、開ループＭＩＭＯ動作の場合にＰＤＳＣＨのためのリソース割当てを送信するために使用される。送信される情報はフォーマット２の場合と同じであるが、異なる点として、ｅＮｏｄｅＢが２つの送信アンテナポートを有する場合、プリコーディング情報は存在せず、４つのアンテナポートの場合、送信ランクを示すために２ビットが使用される（送信モード３）。
− フォーマット２Ｂ： リリース９において導入され、デュアルレイヤビームフォーミングの場合にＰＤＳＣＨのためのリソース割当てを送信するために使用される（送信モード８）。
− フォーマット２Ｃ： リリース１０において導入され、閉ループシングルユーザＭＩＭＯ動作またはマルチユーザＭＩＭＯ動作（最大８レイヤ）の場合にＰＤＳＣＨのためのリソース割当てを送信するために使用される（送信モード９）。
− フォーマット２Ｄ： リリース１１において導入され、最大８レイヤの送信に使用され、主としてＣｏＭＰ（協調マルチポイント）において使用される（送信モード１０）。
− フォーマット３および３Ａ： ＤＣＩフォーマット３および３Ａは、それぞれ、２ビットまたは１ビットの電力調整を有する、ＰＵＣＣＨおよびＰＵＳＣＨのための電力制御コマンドを送信するために使用される。これらのＤＣＩフォーマットは、ユーザ機器のグループのための個々の電力制御コマンドを含む。
− フォーマット４： ＤＣＩフォーマット４は、アップリンク送信モード２における閉ループ空間多重化送信を使用する、ＰＵＳＣＨのスケジューリングに使用される。
− ＰＤＣＣＨは、連続する制御チャネルエレメント（ＣＣＥ：Control Channel Element）の１つまたは複数の連続する制御チャネルエレメントでＤＣＩを伝送する。１つの制御チャネルエレメントは、それぞれが４つまたは６つのリソースエレメントからなる９つのリソースエレメントグループ（ＲＥＧ：Resource Element Group）に相当する。
− サーチスペースは、ＵＥが自身のＰＤＣＣＨを見つけうる一組のＣＣＥ位置を示す。各ＰＤＣＣＨは１つのＤＣＩを伝送しており、ＤＣＩのＣＲＣ付加において暗黙的に符号化された無線ネットワーク一時識別子（ＲＮＴＩ：radio network temporary identity）によって識別される。ＵＥは、ブラインド復号およびＣＲＣのチェックによって設定されたサーチスペースのＣＣＥをモニタリングする。
− サーチスペースは、共通サーチスペースであっても、ＵＥ固有サーチスペースであってもよい。ＵＥは、共通サーチスペースおよびＵＥ固有サーチスペースを両方ともモニタリングする必要がある（共通サーチスペースとＵＥ固有サーチスペースは重複している場合がある）。共通サーチスペースは、システム情報（ＳＩ−ＲＮＴＩを使用）、ページング（Ｐ−ＲＮＴＩ）、ＰＲＡＣＨレスポンス（ＲＡ−ＲＮＴＩ）、またはＵＬ ＴＰＣコマンド（ＴＰＣ−ＰＵＣＣＨ／ＰＵＳＣＨ−ＲＮＴＩ））等の、すべてのＵＥに共通のＤＣＩを伝送する。ＵＥ固有サーチスペースは、ＵＥに割り当てられたＣ−ＲＮＴＩを使用するＵＥ固有の割当て、半永続スケジューリング（ＳＰＳ Ｃ−ＲＮＴＩ）、または初期割当て（一時Ｃ−ＲＮＴＩ）のためのＤＣＩを伝送することができる。

＜アンライセンスバンドにおけるＬＴＥ： ライセンスアシストアクセス（ＬＡＡ：Licensed-Assisted Access）＞
３ＧＰＰは、２０１４年９月に、アンライセンススペクトルにおけるＬＴＥ運用に関する新たな検討項目に着手しており、これは、２０１５年６月に非特許文献３（３ＧＰＰのウェブサイト（www.3gpp.org）で入手可能）で結論付けられている。アンライセンスバンドでの運用のためのＬＴＥの仕様に焦点を当てた、対応する作業項目は、３ＧＰＰ ＲＡＮ１＃８２で２０１５年６月に着手され、２０１５年８月に開始される。ＬＴＥをアンライセンスバンドに拡張する理由は、ライセンスバンドの量が限られていることに加えて、無線ブロードバンドデータの需要が高まり続けていることである。したがって、携帯電話の事業者が、アンライセンススペクトルを自社のサービス提供を拡大するための補足的な手段とみなす傾向が強まっている。ＷｉＦｉ等の他の無線アクセス技術（ＲＡＴ：Radio Access Technology）に頼ることと比較した場合の、アンライセンスバンドにおけるＬＴＥの利点は、ＬＴＥプラットホームにアンライセンススペクトルを用いたアクセスを補足することによって、通信事業者およびベンダが無線ネットワークおよびコアネットワークのＬＴＥ／ＥＰＣハードウェアへの既存の投資または計画された投資を活用することができることである。

しかしながら、アンライセンススペクトルにおける他の無線アクセス技術（ＲＡＴ）と共存することが避けられないため、アンライセンススペクトルを用いたアクセスがライセンススペクトルの品質には決して同等にはなり得ないことを考慮に入れなければならない。したがって、アンライセンスバンドにおけるＬＴＥ運用は、少なくとも開始時には、アンライセンススペクトルにおける独立した運用というよりライセンススペクトルにおけるＬＴＥへの補足とみなされるであろう。この仮定に基づき、３ＧＰＰは、少なくとも１つのライセンスバンドと併用してアンライセンスバンドでＬＴＥを運用することに対して、ライセンスアシストアクセス（ＬＡＡ：Licensed Assisted Access）という用語を確立した。しかしながら、将来的な、ＬＡＡに頼らないアンライセンススペクトルにおけるＬＴＥの独立運用は、除外されない。

３ＧＰＰにおいて現在意図されている一般的なＬＡＡの方法は、すでに策定されているリリース１２のキャリアアグリゲーション（ＣＡ）の枠組みを最大限に利用することであり、キャリアアグリゲーション（ＣＡ）の枠組みの構成は、いわゆるプライマリセル（ＰＣｅｌｌ）キャリアおよび１つまたは複数のセカンダリセル（ＳＣｅｌｌ）キャリアを含む。キャリアアグリゲーション（ＣＡ）では、一般的に、セルのセルフスケジューリング（スケジューリング情報とユーザデータが同じキャリアで送信される）と、セル間のクロスキャリアスケジューリング（ＰＤＣＣＨ／ＥＰＤＣＣＨによるスケジューリング情報と、ＰＤＳＣＨ／ＰＵＳＣＨによるユーザデータが、異なるキャリアで送信される）の両方がサポートされる。

３ＧＰＰにおいて想定されている基本的な方法は、ＰＣｅｌｌをライセンスバンドで動作させ、その一方で、１つまたは複数のＳＣｅｌｌをアンライセンスバンドで動作させるというものである。この方式の利点は、アンライセンススペクトルにおけるＰＣｅｌｌでは、場合によっては他のＲＡＴとの共存が避けられないことによってある程度大幅にＱｏＳが低下しうるが、ライセンスバンドで動作させるＰＣｅｌｌは、制御メッセージと、高いサービス品質（ＱｏＳ）が求められるユーザデータ（例えば音声および映像など）とを高い信頼性で送信するために使用可能であることである。ライセンスＰＣｅｌｌ、ライセンスＳＣｅｌｌ１、および様々なアンライセンスＳＣｅｌｌｓ２、３、４（スモールセルとして例示）を有する非常に基本的なシナリオを図３に例示する。アンライセンスＳＣｅｌｌｓ２、３、４の送受信ネットワークノードは、ｅＮＢによって管理された遠隔無線ヘッド、または、ネットワークにアタッチされているがｅＮＢによって管理されていないノードであり得る。簡潔にするために、これらのノードのｅＮＢまたはネットワークへの接続は、図に明示していない。

現在、３ＧＰＰにおいて想定されている基本的な方法は、ＰＣｅｌｌをライセンスバンドで動作させ、その一方で、１つまたは複数のＳＣｅｌｌをアンライセンスバンドで動作させるというものである。この方式の利点は、アンライセンススペクトルにおけるＳＣｅｌｌでは、場合によっては他のＲＡＴとの共存が避けられないことによってある程度大幅にＱｏＳが低下しうるが、ＰＣｅｌｌは、制御メッセージと、高いサービス品質（ＱｏＳ）が求められるユーザデータ（例えば音声および映像など）とを高い信頼性で送信するために使用可能であることである。

３ＧＰＰでは、ＬＡＡの調査および仕様化の焦点を５ＧＨｚのアンライセンスバンドに当てることが合意されている。したがって最も重要な問題の１つは、これらのアンライセンスバンドで動作するＷｉ−Ｆｉ（ＩＥＥＥ ８０２．１１）システムとの共存である。ＬＴＥと他の技術（Ｗｉ−Ｆｉなど）との間の公平な共存をサポートし、さらに、同じアンライセンスバンドにおける複数の異なるＬＴＥ事業者間の公平性を保証する目的で、アンライセンスバンドでのＬＴＥのチャネルアクセスでは、地域および特定の周波数帯によって異なる特定の一連の規制に従わなければならない。５ＧＨｚのアンライセンスバンドでの運用に関する規制要件の包括的な説明は、上述の非特許文献３に記載されている。ＬＡＡ手順を設計するときに考慮しなければならない規制要件には、地域および帯域によって異なるが、動的周波数選択（ＤＦＳ：Dynamic Frequency Selection）、送信電力制御（ＴＰＣ：Transmit Power Control）、リッスンビフォアトーク（ＬＢＴ：Listen Before Talk）、最大送信時間長が限られた不連続送信、が含まれる。３ＧＰＰの意図は、ＬＡＡの国際的な単一の枠組みを目標とすることであり、すなわち基本的には、システムを設計する場合、さまざまな地域および５ＧＨｚ帯域に関するすべての要件を考慮しなければならない。

ＤＦＳは、レーダーシステムからの干渉を検出してこれらのシステムとの同一チャネル動作を回避する目的で、特定の地域および帯域に要求される。これは、周波数帯のほぼ均一な負荷を達成することをさらに意図している。ＤＦＳの動作および対応する要件は、マスター／スレーブ原理に関連する。マスターがレーダー干渉を検出するが、マスターは、レーダー検出を実現するために、マスターに関連付けられる他の装置に頼ることができる。

５ＧＨｚのアンライセンスバンドでの運用は、ほとんどの地域では、ライセンスバンドでの運用と比較してかなり低い送信電力レベルに制限され、結果としてカバレッジ領域が小さくなる。特定の地域および帯域に関するさらなる要件として、同じアンライセンスバンドで動作する他の装置に引き起こされる干渉の平均レベルを低減する目的で、ＴＰＣ（送信電力制御）を使用する。

装置は、ＬＢＴに関する欧州の規制に従って、無線チャネルを占有する前に空きチャネル判定（ＣＣＡ：Clear Channel Assessment）を実行しなければならない。エネルギー検出に基づいてチャネルが空きとして検出された後にのみ、アンライセンスチャネルでの送信を開始することが許可される。ＣＣＡ時、機器は特定の最小時間にわたりチャネルを監視しなければならない。検出されたエネルギーレベルが、設定されているＣＣＡのしきい値を超える場合、チャネルは占有されているとみなされる。チャネルが空きとして分類される場合、機器はただちに送信することが許可される。この点に関し、同じ帯域で動作する他の装置との公平なリソース共有を促進する目的で、最大送信時間長が制限される。

ＣＣＡのためのエネルギー検出は、チャネル帯域幅全体（例えば、５ＧＨｚのアンライセンスバンドにおける２０ＭＨｚ）にわたって行われる。これは、そのチャネル内のＬＴＥのＯＦＤＭシンボルまたはＳＣ−ＦＤＭＡシンボルのすべてのサブキャリアの受信電力レベルが、ＣＣＡを行った装置の評価エネルギーレベルに寄与することを意味する。

さらに、機器が、キャリアの利用可能性を再評価（すなわちＬＢＴ／ＣＣＡ）せずに、該キャリアで送信を行う合計時間は、チャネル占有時間として定義される（ＥＴＳＩ ３０１ ８９３の条項４．８．３．１参照）。チャネル占有時間は、１ｍｓ〜１０ｍｓの範囲の長さとされ、最長チャネル占有時間は、例えばヨーロッパで現在定義されているような４ｍｓであり得る。さらに、ＵＥがアンライセンスセルでの送信後に送信を許可されない最小のアイドル時間があり、この最小のアイドル時間は、チャネル占有時間の少なくとも５％である。アイドル期間の終端近くで、ＵＥは新たなＣＣＡ等を行うことができる。この送信挙動を、図４に概略的に例示している。この図は、ＥＴＳＩ ＥＮ ３０１ ８９３から得たものである（ＥＴＳＩ ＥＮ ３０１ ８９３では、図２：「Example of timing for Frame Based Equipment」）。

様々な規制要件を考慮すると、ライセンスバンドでの運用に限定されている現在のリリース１２の仕様と比較して、アンライセンスバンドで運用するためのＬＴＥの仕様には、いくつかの変更が必要になることが明白である。

＜ＬＡＡダウンリンクバースト＞
ライセンスバンドでのＬＴＥ運用とは対照的に、アンライセンスバンドでの運用の特徴は、上述のような要求されるＬＢＴ挙動と、許可される最大チャネル占有時間長の制約とによる不連続送信によって形づくられる。

したがって、ＬＡＡのダウンリンク送信は、空きチャネル判定（ＣＣＡ）が行われるリスニング段階およびｅＮＢからの連続した信号送信が、各送信バーストに先行するバースト構造を呈する。この信号送信段階には、データ保持信号に加えて、例えば予約信号、同期信号、参照信号等の多数の様々な信号が含まれ得る。以下、この信号送信段階をＬＡＡダウンリンクバーストという。通常、ＬＡＡダウンリンクバーストはそれぞれ、複数のＬＴＥサブフレームを含む。

上述の非特許文献３に記載されるように、ライセンスＰＣｅｌｌおよびアンライセンスＳＣｅｌｌのサブフレーム境界をそろえることがＬＡＡの検討項目の段階でＲＡＮ１において合意されている。特に、サブフレーム境界は、空きチャネル判定（ＣＣＡ）によってチャネルアクセス挙動を決定するチャネル占有条件には適合されない。さらに、ＬＴＥノードと同じ帯域で動作するＷｉ−Ｆｉノードが、ＬＴＥのサブフレーム境界パターンに従っていない。これは、チャネルがＬＴＥのサブフレーム境界内の任意の瞬間に空き状況になることができることを意味する。

基地局とユーザ機器はいずれも、データ送信前にＣＣＡを行わなければならない。換言すれば、アンライセンスキャリアでの送信は、一般的にＬＢＴ手順の後に行われなければならない。したがって、所望の送信時間にチャネルが利用可能であることを常に保証できるわけではない。

3GPP TS 36.211， "Evolved Universal Terrestrial Radio Access (E-UTRA); Physical Channels and Modulation (Release 8)" 3GPP TS 36.213, v12.6.0, June 2015, titled "Evolved Universal Terrestrial Radio Access (E-UTRA); Physical layer procedures" TR 36.889, v13.0.0 of June 2015, titled "Study on Licensed-Assisted Access to Unlicensed Spectrum" LTE - The UMTS Long Term Evolution - From Theory to Practice, Edited by Stefanie Sesia, Issam Toufik, Matthew Baker

上述の背景に基づいて、送信機がデータを送信しない理由がいくつかありうる。その理由とは、ａ） スケジューリンググラントを含むＤＣＩがエラーにより受信されなかった（正確に受信されなかった）こと、ｂ） 矛盾するＤＣＩが、エラー（ＤＣＩを誤って有効と認識することに起因する誤報（false alarm））により受信された結果、いずれのＤＣＩにも従わなかったこと、ｃ） アンライセンスキャリアが所望の送信時間（スケジューリングされた時間）に他の送信によって占有されうることである。現在、送信し損なう原因を明確に区別する手段がない。

これらの様々な原因を区別しないと、特に複数の冗長バージョンを有する増分冗長性（incremental redundancy）を適用するＨＡＲＱと組み合わされて遅延およびオーバーヘッドが生じうる。或る特定の問題が原因ｃに起因する。送信機が他の送信を検出し、スケジューリングされたデータの送信を差し控える場合、受信機が、当該他のデータをスケジューリングされたデータと解釈して、間違ったデータを処理する可能性がある。ＣＲＣによってデータが不正確に受信されたことが明らかになりうるとしても、受信機は、それらのデータと他の（後の）冗長バージョンとを合成しようとする。しかしながら、当該他の送信が、スケジューリングされたデータとは無関係であるため、合成バッファの内容全体が歪曲され得、後に再送信することによってもデータを上手く復号する助けにならない場合がある。

したがって、本発明のねらいは、アンライセンスバンドで動作するＨＡＲＱの効率を高めることである。これは、アップリンクデータ送信の場合に特に有利になりうる。

独立請求項は、本発明を制限することのない例示的な実施形態を提供する。有利な実施形態が従属請求項の主題である。

本発明を制限することのない例示的な一実施形態では、無線通信システムのサブフレームにおいてデータを送信するための改良方法であって、ユーザ機器（ＵＥ：User Equipment）装置によって行われる以下のステップ、すなわち、アップリンクキャリアの所定のリソースでデータを送信するためのアップリンクグラントを受信するステップと、前記所定のリソースが送信に利用可能か否かをキャリアセンスによって検出するステップと、前記所定のリソースが送信に利用可能であることが検出される場合、前記所定のリソースにおいてデータを送信し、かつ前記データが送信されたことを示す送信確認インジケーションを送信するステップと、を含む、方法が提供される。

本発明を制限することのない例示的な他の実施形態では、無線通信システムのサブフレームにおいてデータを受信する方法であって、基地局によって行われる以下のステップ、すなわち、ユーザ機器がアップリンクキャリアの所定のリソースでデータを送信するためのアップリンクグラントを生成するステップと、前記所定のリソースにおいてデータを受信するステップと、前記データが前記ユーザ機器によって送信されたことを示す送信確認インジケーションを受信するステップと、を含む、方法が提供される。

本発明を制限することのない例示的な他の実施形態では、無線通信システムのサブフレームにおいてデータを送信する装置であって、アップリンクキャリアの所定のリソースでデータを送信するためのアップリンクグラントを受信する受信ユニットと、前記所定のリソースが送信に利用可能か否かをキャリアセンスによって検出するキャリアセンスユニットと、前記所定のリソースが送信に利用可能であることが検出される場合、前記所定のリソースにおいてデータを送信し、かつ前記データが送信されたことを示す送信確認インジケーションを送信する送信ユニットと、を有する、装置が提供される。

本発明を制限することのない例示的な他の実施形態では、無線通信システムのサブフレームにおいてデータを受信する装置であって、ユーザ機器がアップリンクキャリアの所定のリソースでデータを送信するためのアップリンクグラントを生成するスケジューラと、前記所定のリソースにおいてデータを受信するデータ受信部と、前記データが前記ユーザ機器によって送信されたことを示す送信確認インジケーションを受信する制御受信部と、を有する、装置が提供される。

開示されている実施形態のさらなる恩恵および利点は、本明細書および各図から明らかになるであろう。これらの恩恵および／または利点は、本明細書および図面に開示したさまざまな実施形態および特徴によって個別に提供され得、これらの恩恵および／または利点の１つまたは複数を得るためにすべてを備える必要はない。

これらの一般的な態様および特定の態様は、システム、方法、コンピュータプログラム、またはこれらの任意の組合せを使用して実施することができる。

以下では、例示的な実施形態について添付の図面を参照しながらより詳細に説明する。

３ＧＰＰ ＬＴＥシステムの例示的なアーキテクチャの図である。 ３ＧＰＰ ＬＴＥ（リリース８／９）において定義されている、サブフレームのダウンリンクスロットの例示的なダウンリンクリソースグリッドの図である。 さまざまなライセンスセルおよびアンライセンスセルが存在する、例示的なライセンスアシストアクセスのシナリオの図である。 さまざまな期間（すなわち、チャネル占有時間、アイドル期間、および固定フレーム期間）を含むアンライセンスバンドでの送信タイミングを概略的に例示する図である。 ＬＢＴキャリアでのスケジューリングされた送信を例示する概略図である。 ＰＵＳＣＨリソースへの確認信号の例示的なマッピングを示す概略図である。 ＰＵＳＣＨリソースへの確認信号の例示的なマッピングを示す概略図である。 ＰＵＳＣＨリソースへの確認信号の例示的なマッピングを示す概略図である。 アップリンクでのデータ送信方法のフローチャートである。 ＬＢＴキャリアでのアップリンク通信のための装置を例示するブロック図である。

「移動局」または「移動ノード」または「ユーザ端末」または「ユーザ機器」は、通信ネットワーク内の物理エンティティである。１つのノードがいくつかの機能エンティティを有していてもよい。機能エンティティとは、所定の一連の機能を実施する、および／または、所定の一連の機能をノードまたはネットワークの別の機能エンティティに提供するソフトウェアモジュールまたはハードウェアモジュールを意味する。ノードは、通信機器または通信媒体にノードをアタッチする１つまたは複数のインタフェースを有していてもよく、ノードはこれらのインタフェースを通じて通信することができる。同様に、ネットワークエンティティは、機能エンティティを通信機器または通信媒体にアタッチする論理インタフェースを有していてもよく、ネットワークエンティティは論理インタフェースを通じて別の機能エンティティや通信相手ノードと通信しうる。

特許請求の範囲および本出願において使用されている「無線リソース」という用語は、物理無線リソース（時間−周波数リソースなど）を意味するものと広義に理解されたい。

特許請求の範囲および本出願において使用されている「アンライセンスセル」という用語、または、代替的に「アンライセンスキャリア」という用語は、「ライセンス不要周波数バンド」とも呼ばれることがあるアンライセンス周波数バンドにおけるセル／キャリアを意味するものと広義に理解されたい。同様に、特許請求の範囲および本出願において使用されている「ライセンスセル」という用語、または、代替的に「ライセンスキャリア」という用語は、ライセンス周波数バンドにおけるセル／キャリアを意味するものと広義に理解されたい。例として、これらの用語は、リリース１２／１３時点での３ＧＰＰおよびライセンスアシストアクセスの作業項目のコンテキストにおいて理解されたい。

システムのアンライセンスセルは、特に、アンライセンスセルのリソースが様々な規格に従って作動する他の複数の装置の送信と共有されている（すなわち、当該システムによってスケジューリングされていない）点でライセンスセルと異なりうる。したがって、システムがアンライセンスセルにおいても送信をスケジューリングするとしても、スケジューリングされたデータを実際に送信する前のキャリアセンスが依然として必要である。

図５は、本発明の発端である問題を例示する。ｘ軸が時間領域のサブフレームを意味する。事前に定義された持続時間長のサブフレーム内でライセンスバンドが運用されることが想定されている。図５は、サブフレーム番号がＮであるサブフレームに対応する時点Ｎを示す。この時点Ｎでは、ＵＥがＰＤＣＣＨ上の（すなわち、ダウンリンク制御情報（ＤＣＩ：Downlink Control Information）内の）アップリンクグラントを受信している。現在のＬＴＥ−Ａの仕様（リリース１２）によれば、アップリンクグラントによってスケジューリングされたデータは、Ｎ＋４番目のサブフレームにおいて（すなわち、当該グラントを受信してから４サブフレーム後に）送信されることになっている。また、図５は、時点Ｎ＋４においてＵＥによるＰＵＳＣＨでの送信が失敗したことを示している。この例における上記送信は、ＣＣＡの失敗が原因で失敗している。換言すれば、ＬＢＴ手順を行う際に、ＵＥは、例えばスケジューリングされたリソースで他のエンティティが送信していることによりチャネルが使用中である／占有されていることを検出した。そのような送信は、例えばＷＬＡＮ送信でありうる。したがってＵＥは、送信を開始も、停止もしない、すなわち、ＬＡＡセルにおいて不連続送信（ＤＴＸ）を行う。しかしながら、この場合、この送信のためのグラントを含むＤＣＩを送信した基地局（ｅＮＢ）は、ＵＥからデータを受信することを依然として期待している。したがって、この基地局（ｅＮＢ）は、スケジューリングされたリソース上で検出されるデータを復号する。検出されたデータがむしろ他のシステム（ＷＬＡＮ）によるノイズおよび／または送信に相当するため、例えばＣＲＣチェックによって誤った復号が検出される可能性が高い。しかしながら、ハイブリッドＡＲＱ合成を利用するために、上記検出されたデータは依然として、合成バッファ内に保存され、存在しうる先の送信または後の再送信と合成される。

そのように全くの別データを合成バッファ内に保存し、そのような全くの別データを他の送信との合成のために使用していては、データ復号を改良することができない。それどころか、別データの存在は、復号結果全体を歪曲しうる。

さらに、図５は、Ｎ＋８番目のサブフレームにおいてＰＤＣＣＨ上の他のアップリンクグラントを受信し、次いで４サブフレーム後に、すなわち、サブフレームＮ＋１２においてデータをＰＵＳＣＨ送信していることを例示している。この例では、ＣＣＡが成功し、かつスケジューリングされたリソースが使用されていなかったため上記送信は行われた。

合成バッファの歪曲を回避するために、ｅＮＢは、キャリアセンスを行うことによって、ＵＥが送信しているかを検出しようとしてもよい。予定の時間周波数リソースで電力が実質的に受信される場合、ｅＮＢは、所望のＵＥがデータを送信していると想定する。しかしながら、ＷＬＡＮ送信装置等の他の送信装置が存在すると、ＣＣＡの失敗によりＵＥが送信していなくても、十分な電力が測定されうる。他方、アンライセンスセルの遠端のＵＥは検出閾値未満になり得、当該ＵＥによる送信が無視されうる。

他の可能性は、参照シンボル相関（reference symbol correlation）に基づいて、ＵＥからの送信の有無を検出することである。しかしながら、このアプローチでも、ＵＥによる送信を検出し損なったり、間違った検出になったりしうる。

したがって本発明によれば、ＵＥは、当該ＵＥがデータを送信したことを示す確認信号（確認インジケーション）を送信する。この確認インジケーションに基づいて、ｅＮＢは、ＵＥが実際にデータの送信に成功したか否かの通知を受け、ＵＥが送信に成功しなかった場合、対応する受信データを合成バッファから廃棄しうる。

所定のリソースが利用可能か否か検出することには、所定のリソースの少なくとも一部での測定が含まれる。この測定は、例えば、単にリソースの信号電力の測定でありうる。しかしながら、本発明はこれに限定されず、上記測定には、事前に定義された基準系列と受信信号とをマッチングして、系列の受信品質を測定することが含まれうる。例えば、それぞれが良好な自己相関特性を備えた複数のＰＮ系列を受信信号と相関させてもよく、ＰＮ系列と受信信号との最良の相関が、リソースが利用可能か否か決定するために使用されうる。リソースは、例えば他のワイヤレスシステムがこのリソースで送信を行う場合、利用不可能である。しかしながら、高いノイズまたは高干渉の場合も同じ結果、すなわちリソースが利用不可能である結果が検出されうることに留意されたい。

ＬＴＥ／ＬＴＥ−Ａシステムでは、ＵＥは、物理ダウンリンク制御チャネル（ＰＤＣＣＨ：physical downlink control channel）で送信されたダウンリンク制御情報に含まれたアップリンクグラントを受信した際、物理アップリンク共有チャネル（ＰＵＳＣＨ：Physical Uplink Shared CHannel）でアップリンクデータを送信する。本発明によれば、ＵＥがＰＵＳＣＨを送信する場合、ＵＥは確認インジケーションも送信する。確認インジケーションの送信は、可能性としてはシステム構成に応じて異なる様々な方法で行うことができる。

例えば、本発明の一実施形態によれば、確認インジケーションは、データが同様に送信されるＰＵＳＣＨサブフレーム（例えばＣＣＡが成功の場合）、またはデータが送信されるはずだったが送信されなかったＰＵＳＣＨサブフレーム（例えばＣＣＡが失敗の場合）において送信される。アップリンクでのフィードバック情報（すなわち、基地局からＵＥへのダウンリンク送信に関するフィードバック情報）等のアップリンク制御情報（ＵＣＩ：Uplink Control Information）を送信するための、現在一般に行われている手順に次いでこの確認インジケーションが送信される場合に有利である。これは、ダウンリンクデータ送信が行われていれば可能である。具体的には、確認インジケーションは、ＰＤＳＣＨチャネルもしくはＤＬ−ＳＣＨデータに対する肯定的なもしくは否定的な確認応答（ＡＣＫ／ＮＡＣＫ：positive or negative acknowledgements）、ランクインジケータ（ＲＩ：Rank Indicator）、チャネル品質インジケータ（ＣＱＩ：Channel Quality Indicator）、またはプリコーディング行列インジケータ（ＰＭＩ：Pre-coding Matrix Indicator）と同様にＰＵＳＣＨに多重化することができる。このフィードバック情報の現在一般に行われている多重化は、非特許文献３の５．２．２．７節、５．２．３節、および５．２．４節に詳しく記載されており、物理層におけるＰＵＳＣＨおよびＰＵＣＣＨの送信、したがって物理リソースへのＰＵＳＣＨおよびＰＵＣＣＨのマッピングは、非特許文献１の５．３節に示されている。ＵＣＩの処理は、非特許文献２の１０．１節に記載されている。

例えば、確認インジケーションを、復調用参照信号（ＤＭ−ＲＳ：DeModulation Reference Signal）に隣接して多重化することができる。ＤＭ−ＲＳ信号に隣接することによって確実に高品質なチャネル品質検出を行うことができるため、そのような多重化によって、受信品質がより良好になる利点が提供される。具体的には、確認インジケーションは、ＰＵＳＣＨにおいて、ＤＭ−ＲＳ信号と同じサブキャリアおよび隣接ＳＣ−ＦＤＭＡシンボルの時間周波数グリッド内で多重化される。換言すれば、確認インジケーションは、ＤＭ−ＲＳ信号と直接隣り合うＳＣ−ＦＤＭＡシンボルにおいて、またはより一般的にはチャネル評価基準として役立つ情報を伝送するリソースに（時間／周波数リソースの点で）隣り合うＳＣ−ＦＤＭＡシンボルにおいてマッピングされる。

確認インジケーションは、１ビット以上でありうる。この１つ以上のビットは、事前に定義または設定されたビット系列として表現され得、次いで、このビット系列は、事前に定義された変調次数の対応する１つまたは複数の変調シンボルにマッピングされる。確認インジケーションに対応する２つ以上のシンボルがある場合、これらのシンボルは、周波数領域（２つ以上のサブキャリアを含む周波数領域）の方向にマッピングされる。

物理リソースへの確認インジケーションのマッピング例を図６に示す。具体的には、図６は、時間領域に７つのシンボル（ＳＣ−ＦＤＭＡ）を含む時間スロットのリソースグリッドであって、周波数領域に１２のサブキャリアを含むリソースグリッドを示す（すなわち、図２に示されるようなＬＴＥ／ＬＴＥ−Ａの通常のサイクリックプレフィックス長の場合のリソースブロックが図示される）。この例では、４番目のシンボルの全体がアップリンク参照信号（ＤＭ−ＲＳ）に使用されている、すなわち、４番目のシンボルの全サブキャリアがアップリンクＲＳを伝送している。図から分かるように、確認インジケーションフィードバックは、時間領域においてＲＳ信号の左右に隣接してＲＳ信号に沿ってマッピングされている。この例では、このＰＵＳＣＨにおいてＡＣＫ／ＮＡＣＫは送信されていない。

図７が他の例を示しており、この例では、周波数においてＲＳに沿ってマッピングされたＡＣＫ／ＮＡＣＫに続けて確認インジケーションがマッピングされている（時間領域においてＲＳに直接隣接しかつＡＣＫ／ＮＡＣＫの送信に使用されなかったサブキャリアにマッピングされている）。なお、これらの図は例示である。例えば、図７では、ＲＳの両側に８つのリソースエレメントがある。しかしながら、本発明はこの形態に限定されず、ＰＵＳＣＨのリソースグリッドにおいて１つまたは複数の確認インジケーションを伝送するために任意の数の（１つまたは複数の）リソースエレメントが使用されうる。同様に、図６は、ＲＳの両側で４つのリソースエレメントが確認信号のために使用される一例を示しているに過ぎない。しかしながら、この例は、本発明を限定するものではない。任意の１つ以上のそのようなリソースエレメントが使用されうる。ＤＭ−ＲＳの近傍を占める性質が保持される、代替的なマッピングとしては、ＡＣＫ／ＮＡＣＫおよび確認インジケーションが、それぞれ、ＤＭ−ＲＳに先行／後続するシンボルにマッピングされるものがある。一般に、確認インジケーションのマッピングは、ＲＳの位置に対して必ずしも左右対称ではない（すなわち、確認インジケーションをＲＳに先行または後続するシンボルにマッピングすることができる）。

他の例を図８に示す。図８では、ＡＣＫ／ＮＡＣＫシンボルがＲＳ信号に直接隣接してマッピングされている。そして、確認信号は、ＡＣＫ／ＮＡＣＫを伝送するシンボルに接して（接近して）マッピングされている、すなわち、ＲＳシンボルに直接隣接していないシンボルに（図６における第２のシンボルおよび第６のシンボルに）マッピングされている。

ビット系列には、反復符号化、リード−マラー符号化、畳み込み符号化、またはターボ符号化等の誤り訂正符号化を行ってもよい。これにより、確認インジケーションの内容がさらに保護される。

上記多重化に代えてまたは上記多重化に加えて、ＰＤＳＣＨのためのフィードバック信号等の既存のＵＣＩと同様に確認信号を符号化してもよい。

例えば、確認インジケーションのビット系列へのマッピングおよびビット系列の変調シンボルへのマッピングは、確認インジケーションの複数の値のユークリッド距離が最大でありうるように行われうる。例えば、確認インジケーションが１ビット長であり、データが送信されたか否かのみを示すことができる場合、変調後に確認インジケーションの２つの値が対蹠的な変調シンボルにマッピングされるようにビット系列にマッピングされる。

上述のような本発明は、いくつかの利点を提供する。例えば、基地局は、受信したアップリンク送信が、意図された（スケジューリングされた）ＵＥから来ているか否かを確実に検出することができる。結果的に、ＨＡＲＱバッファの破損を回避することができる。これにより、ＨＡＲＱまたは上位層での再送信が少なくなり、ひいては低遅延または高スループットに結びつく。

一般に、確認インジケーションは、必ずしも単一ビットに限定されていない。具体的には、確認インジケーションは、単に現在のデータが送信されたか否か以上のことを示しうる。例えば、確認信号は、同じ再送信プロセス（ＨＡＲＱプロセス）の先の送信の状態に関する追加情報を提供しうる。

例えば、同じ再送信プロセスの先の送信が実行された場合、ＵＥはこの追加情報を「状態１」によって示してもよく、この追加情報の状態を受信する基地局は受信データとＨＡＲＱバッファに存在するデータとを合成しうる。一方、同じ再送信プロセスの先の送信が実行されなかった場合、ＵＥはこの追加情報を「状態２」によって示してもよい。「状態２」は、基地局が再送信バッファをフラッシュすることができることを意味する。

なお、本発明は、送信確認インジケーションの受信機での特定の処理に制限されない。この処理は、実装に応じて異なりうる。例えば、合成バッファに先の送信と再送信との合成成果物のみが格納される場合、バッファデータとは無関係な受信をこの成果物と合成するとバッファが破壊され得、この場合、バッファをフラッシュする必要がある。一方、受信した同じデータの送信と再送信とが合成バッファに別々に格納される場合、誤って受信された送信をバッファから除去すれば十分である。

同じ再送信プロセスの先行サブフレームのダウンリンク制御情報が欠損または破損していることが先の送信が実行されない理由でありうる。アンライセンスキャリア（ＬＢＴキャリア）については、ダウンリンク制御情報は正確に受信されたがスケジューリングされたリソースが利用不可能であることが追加的な理由でありうる。上述のように、リソースが利用不可能である原因は、そのリソースを使用する他のシステムでありうる。これらの原因を区別することがｅＮＢ等の受信機にとって有益でありうる。例えば、「状態２．１」が、破損ＤＣＩにより送信が実行されなかったことを示しうる一方、「状態２．２」が、アンライセンスキャリアの送信リソースが利用不可能であることにより送信が実行されなかったことを示しうる。状態２．１については、例えば、より大きな送信電力またはよりロバストな変調・符号化方式によってＤＣＩの受信品質を高めるために、また、状態２．２については、利用不可能になりにくいと思われる異なるライセンスキャリアまたはアンライセンスキャリアに後のデータを好ましくスケジューリングするためにそのような情報を役立てることができる。

有利なことに、この追加情報は、送信が成功した場合に確認インジケーションに含まれるのみである。なお、確認インジケーションを上記追加情報と共に符号化してもよい。

以下、あり得る確認インジケーションおよび／または追加情報の状態を例示するための、本発明を限定しないいくつかの例を提供する。

表１から分かるように、確認インジケーションは、一方の値が、スケジューリングされたデータがＰＵＳＣＨで送信されたことを示し、他方の値が、スケジューリングされたデータがＰＵＳＣＨで送信されなかったことを示す２つの値をとりうる確認フラグである。この例には、低オーバーヘッドである利点がある。この確認フラグのシグナリングには１ビットのみ必要である。しかしながら、この例も単一ビットには制限されないことに留意されたい。すなわち、上記２つの状態のシグナリングに使用される有効ビット数は、パディング、符号化、多重化、またはさらなるステップによって異なりうる。代替的に、「ＰＵＳＣＨが送信されなかった」という情報状態は、確認インジケーションが送信されない場合に関連付けられ得る。

表２が他の例を示す。この例では、確認インジケーションは、ＤＣＩの検出が成功した場合に送信されるのみである。上記の場合のように、確認インジケーション（送信された場合）は、アップリンクデータ（ＰＵＳＣＨ）が送信されたことを示す第１の値、およびアップリンクデータが送信されなかったことを示す第２の値をとることができる。ＤＣＩの受信が成功しなかった場合、確認インジケーションは送信されない。

表３が他の例を示しており、この例では、確認インジケーションは、データが送信された場合に送信されるのみである。この例における確認インジケーション（送信された場合）は、データ送信が現在のＨＡＲＱバッファと合成されるべきことを伝える第１の値、およびデータ送信によってＨＡＲＱバッファを上書きするべきことを伝える第２の値の２つの値をとることができる。例えば、許可されたリソースが利用可能ではないことを示すキャリアセンス（および／またはＤＣＩが受信されないこと）によりデータを送信することができなかった場合、確認インジケーションは送信されない。そのように確認インジケーションが送信されないことは、例えば、予定の確認インジケーションリソースにおいて受信する電力が不十分である（すなわち、電力が閾値未満である（この場合、受信機の実装に応じて正確な閾値を決定する必要があることを理解されたい））ことによって、または、確認インジケーションの送信にＣＲＣ等のエラー検出符号が使用される場合に１つ以上のエラーを検出することによって検出可能である。受信機が、ＰＵＳＣＨが送信されないことを想定する場合、受信機はＨＡＲＱバッファを更新しない。

表４は、確認インジケーションが表１と同様に２つの値をとることができる例を示す。さらに、確認インジケーションが、データが送信されたことを示す場合、２つの状態（すなわち、先のデータ送信が行われたか否か）を区別する追加情報が含まれる。

なお、これらの例は、本発明を制限するものではない。例えば、０および１の値の割当ては、異なっていてもよい。さらに、任意の他の符号化を適用してもよい。例えば、確認情報を符号化し、かつ、符号化情報の値に応じて追加情報を符号化する代わりに、以下の表５に例示するように、一緒に符号化してもよい。したがって、確認インジケーションは、３つの値をとることができる。

同じく上述のように、上記の各表における確認インジケーションの値は、確認インジケーションを伝えるために実際に使用されるビット数とは必ずしも一致しない。むしろ、各表は、必要な最小ビット数を示す。

本発明の他の一実施形態によれば、確認インジケーションは、ＰＵＳＣＨでは送信されず、物理アップリンク制御チャネル（ＰＵＣＣＨ：Physical Uplink Control CHannel）で送信される。なお、この実施形態を上記実施形態と組み合わせることもできる。例えば、ダウンリンク送信のための同時にペンディングとなるＵＣＩ（co-pending UCI）が存在する場合には、確認インジケーションをＰＵＳＣＨで送信し、ダウンリンク送信ための同時にペンディングとなるＵＣＩが存在しない場合には、確認インジケーションをＰＵＣＣＨで送信する。しかしながら、本発明はこの例に制限されず、常にＰＵＣＣＨで信号が送られるようにシステムを構成してもよい。

ＰＵＣＣＨリソースは、好ましくは、準静的な（semi-static）構成によってリザーブされる。具体的には、無線リソース制御プロトコルに、確認インジケーションを送信するための対応するＰＵＣＣＨリソースを特定する情報要素が含まれうる。このリソースの構成は、任意のベアラ設定手順またはベアラ修正手順に含まれうる。

さらに、ライセンスキャリア、好ましくはＰＣｅｌｌのＰＵＣＣＨで確認信号を送信することが有利である。上述のように、対応するＰＵＣＣＨリソースは、無線リソース制御（ＲＲＣ：Radio Resource Control）プロトコル構成によってリザーブされうる。ＰＵＣＣＨリソースがプライマリセルに位置しているほうが、制御情報を、該制御情報のために使用可能とされるキャリア（アンライセンスキャリア）で送信するよりも、ある程度高い信頼性で送信することができる。さらに、アンライセンスキャリアのシナリオでは、プライマリセルのＰＵＣＣＨにおける確認インジケーションは常に、アンライセンスセルが利用可能か否かとは無関係に送信されうる。換言すれば、アンライセンスセルリソースが他の送信との衝突が理由で利用可能でない場合、データも確認も送信することができない。これらの場合については、確認インジケーションを他のセル（キャリア）で送信することが有益である。

上述のように、確認インジケーションを、データが送信されたサブフレームと同じサブフレームにマッピングすることができる場合に有利である。特に、そのようなアプローチの結果、遅延が小さくなる。しかしながら、本発明は、かかる形態に制限されない。むしろ、確認インジケーションは、データが送信されたサブフレームより後のサブフレームにおいて（ＰＵＳＣＨまたはＰＵＣＣＨで）送信されうる。これは、確認インジケーションがＡＣＫ／ＮＡＣＫ等の他のＵＣＩのように扱われる場合に特に有益である。例えば、複数のダウンリンク送信のためのＵＣＩが単一のアップリンクフィードバック送信サブフレーム内に集められ、かつバンドルされる／多重化される時分割複信（ＴＤＤ：Time Division Duplex）アクセス方式の場合である。

他の例示的な実施形態によれば、確認インジケーションは、以下の少なくとも２つの状態を示す。
− ＵＬ送信を許可するＤＣＩが受信され、対応するアップリンク送信が実行された。これは、データ送信の肯定的確認応答（ＡＣＫ）（すなわち、データを送信することができたことの確認）である。
− ＵＬ送信を許可するＤＣＩが受信されたが、アップリンク送信は行われない。この状態は、例えばアンライセンスキャリア上のチャネルが占有されていることによって生じうる。ＵＥがデータの送信を一定時間（すなわち、チャネルが占有されている時間）差し控えるため、シグナリングの状態は不連続送信（ＤＴＸ）に類似する。
− ＵＬ送信を許可するＤＣＩが検出されない。そのような場合には送信が全く行われないため、このステータスは否定的確認応答（ＮＡＣＫ）に類似する。

上記の各状態をＨＡＲＱ−ＡＣＫフィードバックに使用される用語（すなわちＡＣＫ、ＮＡＣＫ、ＤＴＸ）に関連付けることによって、確認インジケーションをＨＡＲＱ−ＡＣＫ情報の代わりにまたはＨＡＲＱ−ＡＣＫ情報に加えて送信する目的で、確認信号を補足ＨＡＲＱ−ＡＣＫ情報のように扱うことが容易に可能になる。これにより、ＨＡＲＱ−ＡＣＫに関連する既存のハードウェア、アルゴリズムまたはコンピュータプログラムに容易に組み込むことができる。例えば、複数のＨＡＲＱ−ＡＣＫ情報を多重化してフィードバックを行う場合、本明細書に参照により援用される非特許文献２の１０．１節に、複数のＨＡＲＱ−ＡＣＫフィードバックの場合のフィードバック情報および／またはフィードバックリソースを取得する規則が、例えば、表６として以下に再現した表１０．１．２．２．１−３に定義されている。

具体的には、ＨＡＲＱ−ＡＣＫ（０）およびＨＡＲＱ−ＡＣＫ（１）は、２つの異なるデータブロックの確認応答である（ＬＴＥでは通常、１つのトランスポートブロックにつき１つのＨＡＲＱ−ＡＣＫが存在する）。上記トランスポートブロックは、２つの異なるコンポーネントキャリア（アグリゲーションシナリオの場合）に属していてもよく、異なるサブフレーム（ＴＤＤシナリオの場合）に属していてもよい。

３列目では、２つのＨＡＲＱ−ＡＣＫの組合せが送信されるリソースが特定される。最後の列は、ＨＡＲＱ−ＡＣＫの組合せを表す値ｂ（０）および値ｂ（１）を示しており、これらの値は３番目の列のリソースで送信される。

そして、そのような規則の表または規則セットは、確認インジケーションをＨＡＲＱ−ＡＣＫインジケーションのように扱うために有利に適合される。これは、以下の表７および表８に例示される。例えば、確認インジケーションを、ＨＡＲＱ−ＡＣＫ（０）のように（表７参照）、またはＨＡＲＱ−ＡＣＫ（１）のように（表８参照）処理する。これにより、確認信号を様々に弁別することができる。例えば、下記の例において確認信号をＨＡＲＱ−ＡＣＫ（１）のように扱う場合、通常、ＮＡＣＫの状態とＤＴＸの状態を区別することができない。すなわち、フィードバックの受信機は、フィードバックによっては、ＤＣＩの欠損によってＰＵＳＣＨが送信されないこと（ＮＡＣＫ）と、アップリンクリソースが使用中であることによってＰＵＳＣＨが送信されないこと（ＤＴＸ）とを差別化することができない。他方、確認信号をＨＡＲＱ−ＡＣＫ（０）のように扱うことによって、少なくともＨＡＲＱ−ＡＣＫ（１）＝ＮＡＣＫ／ＤＴＸの場合に差別化が可能である。

換言すれば、一実施形態によれば、確認インジケーションは、ＡＣＫ／ＮＡＣＫ／ＤＴＸフィードバック（送信確認応答）と共に符号化される。送信確認応答および確認インジケーションは、いずれも３つの値（ＡＣＫ、ＮＡＣＫ、ＤＴＸ）をとりうる。

送信確認応答については、ＡＣＫは肯定的な確認応答（データの復号が成功したこと）を、ＮＡＣＫは否定的な確認応答（データの復号が失敗したこと）を、そしてＤＴＸは不連続送信（例えばデータがＤＣＩの欠損により受信されないこと）を意味する。

確認インジケーションについては、上述のように、「ＡＣＫ」はデータが送信されたことを、「ＮＡＣＫ」はリソースが利用不可能であることによってデータが送信されなかったことを、そして「ＤＴＸ」はＤＣＩが欠損していることによりデータが送信されなかったことを意味する。特に、ＮＡＣＫの状態とＤＴＸの状態とを、フィードバックパラメータｎ（１）＿ＰＵＣＣＨおよび（ｂ（０）、ｂ（１））に基づきはっきり区別することが完全には可能でない、表７および表８に示す例では、ＮＡＣＫの状態およびＤＴＸの状態を、類似する諸条件に関連付けることが合理的である。「リソースが利用不可能であることによってデータが送信されなかったこと」および「ＤＣＩが欠損していることによりデータが送信されなかったこと」では、「データが送信されない」状態が共通しているため、これらの２つの状態をＮＡＣＫおよびＤＴＸに関連付けることが有益である。ここで、当業者には、「ＤＴＸ」が、リソースが利用不可能であることによってデータが送信されなかったことを意味してもよく、「ＮＡＣＫ」が、ＤＣＩが欠損していることによりデータが送信されなかったことを意味してもよいことが明白であろう。

上記の表７および表８からから分かるように、送信確認応答と確認インジケーションとの組合せによって、この組合せが送信されるリソース（ｎ（１）＿ＰＵＣＣＨ，Ｉ、ｉ＝０または１）および送信される値（ｂ（０）、ｂ（１））が決定される。ここで、（ｂ（０）、ｂ（１））が符号化および変調等のさらなる処理ステップの対象となることを理解されたい。換言すれば、受信機における送信確認応答および確認インジケーションの組合せは、この組合せが受信されるリソースおよび受信された値に基づいて取得される。

上記の例は、本発明を制限するものではない。むしろ、例えば、ＡＣＫと確認インジケーションの組合せの代わりに２つ以上の確認インジケーションの組合せを送信してもよい。

なお、上記の表７および表８では、２つの送信確認応答（ＨＡＲＱ−ＡＣＫ（０）およびＨＡＲＱ−ＡＣＫ（１）または確認インジケーション）がバンドルされている例が示される。しかしながら、規格（ＡＣＫをバンドルすることについて）も、本発明（確認インジケーションおよび場合によってはＡＣＫをバンドルすることについて）も、２つの要素をバンドルすることに制限されない。むしろ、１つ以上の確認インジケーションを、送信確認応答とはバンドルしなくてもよいし、１つの送信確認応答とバンドルしても、複数の送信確認応答とバンドルしてもよい。異なるコンポーネントキャリアで受信されるトランスポートブロックのＨＡＲＱ−ＡＣＫをバンドルしてこのＨＡＲＱ−ＡＣＫを効率的に送信するコンポーネントキャリアアグリゲーション、および／または、異なるサブフレームにおいて受信されるトランスポートブロックのＨＡＲＱ−ＡＣＫをバンドルしてこのＨＡＲＱ−ＡＣＫを効率的に送信するＴＤＤ等の時間領域でのバンドリングにとって、上記のような構成は特に有利である。

これらの３つの状態を伝える利点は、基地局がアップリンク送信状態についておよび送信が無い場合の理由について詳細な情報を有することである。

そのような情報を、さらに送信品質を高めるために使用することができる。例えば、ＤＣＩが正確に検出されなかった場合、スケジューリングエンティティ（基地局）は、その後のＤＣＩ送信のためにこの情報を使用してＤＣＩ送信のロバスト性を高めてもよい。これは、例えば、ＤＣＩ送信の電力を大きくすることによって、または変調・符号化方式をＤＣＩ送信のために適合することによって実現されうる。キャリアセンスによって検出されたチャネルが利用できないことが理由である場合、スケジューリングエンティティは、送信を他のキャリアにスケジューリングすること、または同じキャリアのより後にスケジューリングすること等を決定しうる。

図９は、無線通信システムのサブフレームにおいてデータを送信する例示的な方法を示す。無線通信システムを、ＬＴＥ／ＬＴＥ−Ａ等の任意のシステムとしてもよい。しかしながら、本発明はこの例に制限されず、本発明は他のシステムにおいても利用されうる。この図では、システムは、２つのエンティティ（すなわち、基地局（ＢＳ：Base Station）およびユーザ機器（ＵＥ：User Equipment））によって例示されている。しかしながら、上記エンティティを、一方の装置が他方の装置の送信のためのグラントを少なくとも一時的に提供する、２つの類似の装置にしてもよい。本発明は一般的にはアップリンクに制限されず、特に、本発明はデータ送信のためのＤＣＩおよび対応するデータ送信が異なる時間インスタンス（例えばサブフレーム）に生じる場合であって、両方のイベントのためのＣＣＡが異なる結果（例えば、ＤＣＩでは「空き」、対応するデータ送信では「使用中」）になり得る場合に適用されうる。

上記方法は、ユーザ機器（ＵＥ）装置によって行われうる以下のステップ、すなわち、アップリンクキャリアの所定のリソースでデータを送信するためのグラントを受信するステップ７４０と、前記所定のリソースが送信に利用可能か否かをキャリアセンス７５０によって検出するステップ７５５と、を含む。所定のリソースが送信に利用可能であることが検出される場合、前記所定のリソースにおいてデータを送信するステップ７６０と、前記データが送信されたことを示す送信確認インジケーションを送信するステップ７７０が行われる。なお、ステップ７６０および７７０は、必ずしも同じ送信リソース（例えば、時間／周波数リソース）に結び付けられてはいない。

グラントは、データが送信されるべきリソースを示すリソース割当てを含みうる。キャリアセンスは単に、所定のまたは事前に定義された参照信号の検出の電力を検出することでありうる。キャリアセンスは、上述のＣＣＡまたはＬＢＴの手順に相当しうる。一般に、キャリアセンス７５０は、参照信号の受信の電力または品質等の所定の受信値を測定することを含む。次いで、リソースが利用可能か否かを判定するステップ７５５が、測定値に基づき、例えばこの測定値と、事前に設定されうる（固定のまたは設定可能な）所定の閾値とを比較することにより行われる。

上記方法は、前記所定のリソースが利用可能ではないことが検出される場合、前記所定のリソースにおいてデータを送信せず、かつ前記データが送信されなかったことを示す送信確認インジケーションを送信するステップと、を含みうる。

図９から分かるように、無線通信システムのサブフレームにおいてデータを受信する方法も提供する。この受信方法は、上記送信方法と相補的でありうる。これは、同様に図示されるように、上記送信方法によって送信されたデータおよび制御信号がこの受信方法によって受信されうることを意味する。そのような方法は、基地局によって行われうる。しかしながら、上述のように、本発明はその形態に制限されず、本方法を他の受信装置によって実行してもよい。

このデータ受信方法は、ユーザ機器がアップリンクキャリアの所定のリソースでデータを送信するためのアップリンクグラントを生成するステップと；生成した前記グラントを送信するステップ７１０と；前記所定のリソースにおいてデータを受信するステップ７２０と；前記データがユーザ機器によって送信されたことを示す送信確認インジケーションを受信するステップ７３０と、を含む。

有利には、送信確認インジケーションは、物理リソースブロック内で復調用参照信号に隣接して多重化されて送信され、この場合、物理リソースブロックは、所定の数のサブキャリアおよび時間シンボルからなる時間周波数リソースである。上記「隣接」は、時間領域において直接隣接することが含まれうる（すなわち、確認インジケーションはＤＭ−ＲＳを伝送するシンボルに隣接するシンボルにマッピングされる）ため、有益である。ＬＴＥ／ＬＴＥ−Ａの場合のシンボルは、例えばアップリンクにおいてはＳＣ−ＦＤＭＡシンボルである。しかしながら、ＬＴＥ／ＬＴＥ−Ａが例示的な実施形態に過ぎず、シンボルを異なる方法で時間において形成してもよいことに留意されたい。

有利なことに、送信確認インジケーションは、ＤＭ−ＲＳ信号と同じサブキャリアにマッピングされる。さらに、ＤＭ−ＲＳ信号に隣接することには、周波数領域において隣接することが含まれうる。例えば、送信確認は、ＤＭ−ＲＳが送信されるサブキャリアと隣り合うサブキャリアにマッピングされうる。

換言すれば、一実施形態によれば、送信確認インジケーションは、時間周波数リソースグリッド上に、ＤＭ−ＲＳを伝送するシンボルと隣り合うシンボルにマッピングされ、このマッピングは、周波数領域に沿って、すなわち、１つ以上の連続するサブキャリアに行われる。

送信確認インジケーションは、物理アップリンク共有チャネル（ＰＵＳＣＨ）の物理リソースブロックに、また、対応するダウンリンク送信に関する肯定的もしくは否定的な確認応答、ランクインジケータ、プリコーディング行列インジケータ、およびチャネル品質情報の少なくとも１つを含むフィードバック情報と隣り合わせで多重化されうる。

あるいは、送信確認インジケーションを、物理アップリンク制御チャネル（ＰＵＣＣＨ）リソースで送信してもよい。

確認インジケーションの送信は、無線リソース制御プロトコルシグナリング（radio resource control protocol signalling）によって準静的に設定されうる。例えば、ＲＲＣは、或るキャリアでの送信についての確認を送るべきか否かを設定しうる。したがって、アンライセンスキャリア（データ送信前にキャリアセンスが行われることになっているキャリア）等の特定のキャリアに対して確認インジケータの送信を設定することができる。さらに、確認インジケーションの送信は、他のシステムも動作している環境において運用されるアンライセンスキャリアに対して設定されうる。

送信確認インジケーションのロバスト性および効率を高めるために、送信確認インジケーションは、キャリアセンスが行われないキャリアの物理アップリンク制御チャネルリソースで送信される。例えば、送信確認インジケーションは、ライセンスキャリアで、有利にはプライマリセルにおいて送信されうる。

送信確認インジケーションは、以下の状態の１つを示しうる。
− アップリンクグラントが受信され、かつデータ送信が実行された。
− アップリンクグラントが検出されなかった。
− アップリンクグラントは受信されたが、データ送信は実行されなかった。

例えば、確認インジケーションは２つの値をとりうる（一方の値が、アップリンクグラントが受信されかつデータ送信が実行されたことを示し、他方の値が、グラントが受信されなかったこと、または送信が行われなかったことを示す）。

他の例によれば、確認インジケーションは、３つを以上の値をとり得、アップリンクグラントは受信されたがデータ送信は実行されなかった状態からアップリンクグラントが検出されなかった状態を区別しうる。

なお、ＵＥは、グラントのリクエストがスケジューリングエンティティに送信されたが、ブラインドデコーダが特定のサブフレームの（Ｅ）ＰＤＣＣＨ上にアップリンクグラントを検出しない場合に、アップリンクグラントが送信されたが検出されなかったか否かを判定してもよい。

有利には、送信確認インジケーションは、先の送信からバッファされたデータと送信されたデータとを合成すべきであること、または、送信されたデータによってバッファの内容を置換すべきであることをさらに示す。したがって、送信確認インジケーションの受信側では、送信確認インジケーションの値によって処理が異なり、この処理には、現在のバッファを合成またはフラッシュすることが含まれうる。

さらに、確認インジケーションは、データが送信されたことを確認インジケーションが示す場合、現在のアップリンクのハイブリッド自動再送要求（ＨＡＲＱ：Hybrid Automatic Repeat reQuest）プロセスのステータスを示しうる。このステータスは、データの先行する送信が成功したか否かを示す。これは、確認インジケーションを受信する受信機（ＢＳ）が上述の合成バッファを管理することに役立ちうる。

確認インジケーションは、好ましくは、前方誤り訂正符号化を使用して、すなわち、冗長性を付加することによって符号化される。

簡潔にするために、上記方法では、１つのグラントおよび１つのデータ送信が生じる場合に焦点を当てている。キャリアアグリゲーションのシナリオでは、そのようなグラントおよびデータ送信は、同時に複数生じ得る。そのようなシナリオには、グラントおよびキャリアごとに確認インジケーションが決定および送信されるように上記方法を適用することができる。例えば、２つのキャリアがアグリゲートされる場合、同時に２つのキャリアにおけるリソースを許可する１つのＤＣＩ（グラント）が存在することも、１つのキャリアにおけるリソースをそれぞれが許可する２つのＤＣＩ（グラント）が存在することもできる。ＣＣＡは、１つのキャリアごとに別々に実行されうるため、一方では成功し、他方では成功しない場合もある。結果的に、キャリアごとに確認インジケーションを伝えることが有益である。これは、例えば、表７および表８を参照して言及したような確認インジケーションのバンドリングにより行われうる。具体的には、確認応答を確認インジケーションとバンドルする代わりに（または、確認応答を確認インジケーションとバンドルすることに加えて）、各キャリアのためのより多くの確認インジケーションをバンドルしてもよい。換言すれば、特にＨＡＲＱ−ＡＣＫフィードバックが確認インジケーションと同時にペンディングとなる場合に確認インジケーションをＨＡＲＱ−ＡＣＫ信号のように処理することについての上記説明のように、複数の確認インジケータを送信する場合も、好ましくは複数のＨＡＲＱ−ＡＣＫフィードバックを処理する場合の規則に従う。

上述のように、キャリアアグリゲーションのシナリオでは、割り当てられたキャリアのいくつかが送信に利用できない（例えば、ＣＣＡの失敗によって）場合、ＵＥは、いずれのキャリアで送信が遂行されたか、および、いずれのキャリアで送信が遂行されなかったかを受信機に知らせるために対応する確認インジケーションを発する。これは、ＵＥに複数のキャリアのグラントが与えられる場合であって、ＵＥが可能性としてキャリアの一部のみで送信することを選択する場合に拡張されうるか、または、そのような場合と置換されうる。例えば、ｅＮＢは、複数のアップリンクキャリアのためのグラントを含むＤＣＩであって、それらのキャリアの１つの送信のみを要求するＤＣＩを送ることができる。これにより、ＵＥには、いずれのキャリアを送信に使用するかを選択する選択肢が残される。例えばＣＣＡの失敗によってキャリアのいくつかが適当ではない場合があるが、依然としてＵＥは、ＵＥが送信することができる２つ以上のキャリアの選択肢を有しうる。この場合、確認インジケーションは、いずれのキャリアで送信がなされたかを示すことに役立つ。所望であれば、前提として、キャリアは利用可能である（例えば、ＣＣＡが成功した）が、ＵＥが当該キャリアを送信のために選択しなかった場合を追加情報に含めることができる。これにより、確認インジケーションは、アンライセンスキャリアのグラントは与えられず、むしろライセンスキャリアのグラントのみが与えられる場合にも特に適用可能である。好ましいことに、この場合、ＵＥは、いずれのキャリアが送信に使用されるか選択する場合のために、および／または特定のキャリアのグラントが受信されたか否かを示すために確認インジケーションを使用することができる。

この場合、例示的な一実施形態では、確認信号は、表９に示されるような状態を示すことができ、好ましくは、許可されたキャリアごとの確認インジケーション、または代替的には利用可能なキャリアセット内のキャリアごとの確認インジケーションが得られる。

換言すれば、確認インジケーションは、４つの値の１つをとりうる。４つの値には、アップリンクグラントが受信され、かつデータが送信されたことを示す第１の値と、アップリンクグラントは受信されたが、リソースが利用可能でないことを示すキャリアセンスが原因でデータが送信されなかったことを示す第２の値と、アップリンクグラントは受信されたが、送信機がそれらのリソースでデータを送信しないことを決定したためデータが送信されなかったことを示す第３の値と、ＤＣＩが受信されず、したがって、データが送信されなかったことを示す第４の値と、が含まれる。

一実施形態では、確認インジケーションは、ダウンリンク送信に関する確認応答フィードバック情報とバンドルされ、バンドルされた確認インジケーションおよび確認応答フィードバックは、所定のリソースで送信される。上述のように、確認応答フィードバックおよび確認インジケーションは、有利なことに３つの値（すなわち、ＡＣＫ、ＮＡＣＫ、およびＤＴＸ）をとる。有益なことに、確認インジケーションと確認応答フィードバック情報とのバンドルは、両方の要素のＡＣＫ／ＮＡＣＫ／ＤＴＸの全てのあり得る組合せ数より少ない値をとりうる。上述の各方法は、送信前にリッスンビフォアトーク手順が行われるキャリアで動作する、ＬＴＥ／ＬＴＥ−Ａに基づいたシステムである無線通信システムに容易に適用可能である。しかしながら、本発明がこれらのシステムに制限されないことに留意されたい。

図１０は、改良された例示的な装置を示す。無線通信システムのサブフレームにおいてデータを送信する装置８００Ａが左手側に示されており、装置８００Ａは、アップリンクキャリアの所定のリソースでデータを送信するためのアップリンクグラントを受信する受信ユニット８１０と、前記所定のリソースが送信に利用可能か否かをキャリアセンスによって検出するキャリアセンスユニット８２０と、前記所定のリソースが送信に利用可能であることが検出される場合、前記所定のリソースにおいてデータを送信し、かつ前記データが送信されたことを示す送信確認インジケーションを送信する送信ユニット８５０と、を有する。

図１０に示されるように、データおよび確認インジケーションは、それぞれのマッピングユニット８３０および８４０において、送信ユニット８５０によって送信されるリソースにマッピングされうる。確認情報のマッピングおよびシグナリングは、上記の各実施形態および各例の１つに従って行われる。データを送信する装置は、有利なことに、ＬＴＥ／ＬＴＥ−ＡのｅＮＢ等の基地局へのアップリンクにおいてデータを送信するＵＥである。しかしながら、データを送信する装置を、他の装置としてもよい。

同様に、図１０の右手側には、無線通信システムのサブフレームにおいてデータを受信する装置８００Ｂが示されており、装置８００Ｂは、ユーザ機器がアップリンクキャリアの所定のリソースでデータを送信するためのアップリンクグラントを生成するスケジューラ８６０と、前記所定のリソースにおいてデータを受信するデータ受信部８８０と、前記データが前記ユーザ機器によって送信されたことを示す送信確認インジケーションを受信する制御受信部８９０と、を有する。

図１０に示されるように、例示的な受信機８００Ｂは、スケジューラ８６０によって生成されたＤＣＩを送信する送信ユニット８７０を備えていてもよい。さらに、データ受信ユニット８８０および制御情報受信ユニット８９０は、実際には１つの受信ユニット、および受信信号からデータおよび確認情報を多重分離（デマッピング）するデマッピング部として実装されうることに留意されたい。

データの受信機８００Ｂは、ＬＴＥ／ＬＴＥ−ＡのｅＮＢ等の基地局でありうる。一般に、受信機８００Ｂを、他の装置８００Ａによる送信のスケジューリングを行う任意の装置としてよい。具体的には、基地局が関与しない装置間コミュニケーションでは、受信機８００Ｂは、一時的にスケジューリングを行うユーザ機器等の装置でありうる。

＜ハードウェアおよびソフトウェアによる本発明の実施＞
他の例示的な実施形態は、上述したさまざまな実施形態を、ハードウェア、ソフトウェア、またはハードウェアと協働するソフトウェアを使用して実施することに関する。これに関連して、ユーザ端末（移動端末）およびｅＮｏｄｅＢ（基地局）を提供する。ユーザ端末および基地局は、本明細書に記載されている方法を実行するように構成されており、これらの方法に適切に関与する対応するエンティティ（受信機、送信機、プロセッサなど）を含む。

さらに、さまざまな実施形態が、コンピューティングデバイス（プロセッサ）を使用して実施または実行されうるものと認識される。コンピューティングデバイスまたはプロセッサは、例えば、汎用プロセッサ、デジタル信号プロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ：Field Programmable Gate Array）、または、その他プログラマブルロジックデバイスなどである。さまざまな実施形態は、これらのデバイスの組合せによっても実行または具現化されうる。特に、上に説明した各実施形態の説明において使用される各機能ブロックは、集積回路としてのＬＳＩによって実施することができる。各機能ブロックを個々にチップとして形成してもよいし、１つのチップを、機能的ブロックの一部または全部を含むように形成してもよい。チップは、チップに結合されたデータ入力部およびデータ出力部を有しうる。本明細書においてＬＳＩを、集積度の違いにより、ＩＣ、システムＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩということもできる。集積回路化の手法はＬＳＩに限るものではなく、専用回路または汎用プロセッサで実現してもよい。また、ＬＳＩ製造後にプログラムすることが可能なＦＰＧＡや、ＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブルプロセッサを利用してもよい。

さらに、さまざまな実施形態は、ソフトウェアモジュールによっても実施され得る。これらのソフトウェアモジュールは、プロセッサによって実行されるか、または、ハードウェアにおいて直接実行される。また、ソフトウェアモジュールとハードウェア実装の組合せも可能でありうる。ソフトウェアモジュールは、任意の種類のコンピュータ可読記憶媒体、例えば、ＲＡＭやＥＰＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ、レジスタ、ハードディスク、ＣＤ−ＲＯＭ、ＤＶＤなどに格納され得る。さらには、複数の異なる実施形態の個々の特徴は、個々に、または任意の組合せにおいて、別の実施形態の主題とすることができることに留意されたい。

具体的な実施形態に示した本発明には、広義に記載されている本発明の概念または範囲から逸脱することなく、さまざまな変更および／または修正を行うことができることが、当業者には理解されるであろう。したがって、本明細書に示した実施形態は、あらゆる点において例示的であり、本発明を制限するものではないものとみなされる。

要約すると、本発明は、無線通信システムのサブフレームにおいてデータを送受信することに関する。本発明は、ユーザ機器において、アップリンクキャリアの所定のリソースでデータを送信するためのアップリンクグラントを受信するステップと、前記所定のリソースが送信に利用可能か否かをキャリアセンスによって検出するステップと、前記所定のリソースが送信に利用可能であることが検出される場合、前記所定のリソースにおいてデータを送信し、かつ前記データが送信されたことを示す送信確認インジケーションを送信するステップと、を含む。受信側では、送信確認インジケーションが送信され、送信確認インジケーションに基づき受信データが処理される。

Claims (13)

1. 無線通信システムのサブフレームにおいてデータを送信する装置であって、
   アップリンクキャリアの所定のリソースでデータを送信するためのアップリンクグラントを受信する受信ユニットと、
   前記所定のリソースが送信に利用可能か否かをキャリアセンスによって検出するキャリアセンスユニットと、
   前記所定のリソースが送信に利用可能であることが検出される場合、前記所定のリソースにおいてデータを送信し、かつ前記データが送信されたことを示す送信確認インジケーションを前記所定のリソースと異なるリソースにおいて送信する送信ユニットと、を有し、
   前記所定のリソースが送信に利用可能ではないことが検出される場合、前記送信ユニットは、前記所定のリソースにおいて前記データを送信せず、かつ前記データが送信されなかったことを示す前記送信確認インジケーションを前記異なるリソースにおいて送信し、
   前記送信確認インジケーションは、送信された前記データが、以前の送信からバッファされたデータと合成されるべきであること、および、送信された前記データによって前記バッファの内容が置換されるべきであることのいずれであるかをさらに示唆する、
   装置。
2. 無線通信システムのサブフレームにおいてデータを受信する装置であって、
   ユーザ機器がアップリンクキャリアの所定のリソースでデータを送信するためのアップリンクグラントを生成するスケジューラと、
   前記所定のリソースにおいてデータを受信するデータ受信部と、
   前記データが前記ユーザ機器によって送信されたこと、および、前記データが前記ユーザ機器によって送信されなかったことのいずれかを示す送信確認インジケーションを受信する制御受信部と、を有し、
   前記送信確認インジケーションは、送信された前記データが、以前の送信からバッファされたデータと合成されるべきであること、および、送信された前記データによって前記バッファの内容が置換されるべきであることのいずれであるかをさらに示唆する、
   装置。
3. 無線通信システムのサブフレームにおいてデータを送信する方法であって、ユーザ機器（ＵＥ：User Equipment）装置によって行われる以下のステップ、すなわち、
   アップリンクキャリアの所定のリソースでデータを送信するためのアップリンクグラントを受信するステップと、
   前記所定のリソースが送信に利用可能か否かをキャリアセンスによって検出するステップと、
   前記所定のリソースが送信に利用可能であることが検出される場合、前記所定のリソースにおいてデータを送信し、かつ前記データが送信されたことを示す送信確認インジケーションを前記所定のリソースと異なるリソースにおいて送信するステップと、
   前記所定のリソースが送信に利用可能ではないことが検出される場合、前記所定のリソースにおいて前記データを送信せず、かつ前記データが送信されなかったことを示す前記送信確認インジケーションを前記異なるリソースにおいて送信するステップと、
   を含み、
   前記送信確認インジケーションは、送信された前記データが、以前の送信からバッファされたデータと合成されるべきであること、および、送信された前記データによって前記バッファの内容が置換されるべきであることのいずれであるかをさらに示唆する、
   方法。
4. 前記送信確認インジケーションは、物理リソースブロック内で復調用参照信号に隣接して多重化されて送信され、
   前記物理リソースブロックは、所定の数のサブキャリアおよび時間シンボルからなる時間周波数リソースである、
   請求項３に記載の方法。
5. 前記送信確認インジケーションは、前記物理リソースブロック内で、前記復調用参照信号に近接する１つ以上の連続するサブキャリアに多重化され、
   前記物理リソースブロックは、物理アップリンク共有チャネルのリソースである、
   請求項４に記載の方法。
6. 前記送信確認インジケーションは、物理アップリンク制御チャネルリソースで送信される、
   請求項３に記載の方法。
7. 前記送信確認インジケーションは、無線リソース制御プロトコルシグナリング（radio resource control protocol signalling）によって準静的に設定される、
   請求項６に記載の方法。
8. 前記送信確認インジケーションは、キャリアセンスが行われないキャリアの物理アップリンク制御チャネルリソースで送信される、
   請求項６または７に記載の方法。
9. 前記送信確認インジケーションは、
   − 前記アップリンクグラントが受信され、かつデータ送信が実行された状態、
   − アップリンクグラントが検出されなかった状態、
   − 前記アップリンクグラントは受信されたが、データ送信は実行されなかった状態、の１つを示す、
   請求項６〜８のいずれか一項に記載の方法。
10. 前記送信確認インジケーションは、前記データが送信されたことを示す場合に現在のアップリンクハイブリッド自動再送要求（ＨＡＲＱ：Hybrid Automatic Repeat reQuest）プロセスのステータスを示し、
    前記ステータスは、前記データの先行する送信が成功したか否かを示す、
    請求項３〜９のいずれか一項に記載の方法。
11. 前記送信確認インジケーションは、前方誤り訂正符号化を使用して符号化される、
    請求項３〜８のいずれか一項に記載の方法。
12. 前記送信確認インジケーションは、ダウンリンク送信に関する確認応答フィードバック情報とバンドルされ、
    バンドルされた前記送信確認インジケーションおよび前記確認応答フィードバック情報は、所定のリソースで送信される、
    請求項３〜１１のいずれか一項に記載の方法。
13. 無線通信システムのサブフレームにおいてデータを受信する方法であって、基地局によって行われる以下のステップ、すなわち、
    ユーザ機器がアップリンクキャリアの所定のリソースでデータを送信するためのアップリンクグラントを生成および送信するステップと、
    前記所定のリソースにおいてデータを受信するステップと、
    前記データが前記ユーザ機器によって送信されたこと、および、前記データが前記ユーザ機器によって送信されなかったことのいずれかを示す送信確認インジケーションを受信するステップと、を含み、
    前記送信確認インジケーションは、送信された前記データが、以前の送信からバッファされたデータと合成されるべきであること、および、送信された前記データによって前記バッファの内容が置換されるべきであることのいずれであるかをさらに示唆する、
    方法。