JP5766718B2 - クロス・キャリア・スケジューリング・シナリオにおけるリソース割り当てのシグナリング - Google Patents

Description

本発明の一態様は、下りリンク（または上りリンク）用のリソース割り当てを含む下りリンク制御情報（ＤＣＩ）内に、下りリンク制御情報によってリソースが割り当てられるコンポーネント・キャリア上のサブフレーム内の制御シグナリングのために使用される１つまたは複数のＯＦＤＭシンボルの数を明示する。例示的な一実施形態では、制御シグナリングに使用される１つまたは複数のＯＦＤＭシンボルの数は、３ＧＰＰ ＬＴＥ−ＡネットワークにおいてシグナリングされるＰＣＦＩＣＨ値である。割り当てられるコンポーネント・キャリア上のサブフレーム内の１つまたは複数のＯＦＤＭシンボルの指示は、たとえば、他の制御シグナリング情報、たとえばキャリア・インジケータ・フィールドのキャリア指示と一緒に符号化される。また、本発明は、ハードウェアおよびソフトウェアにおいてこれらの方法を実施することにも関する。

ロング・ターム・エボルーション（ＬＴＥ）
ＷＣＤＭＡ無線アクセス技術に基づく第三世代モバイル・システム（３Ｇ）が世界中で広範囲に普及している。この技術を向上または発展させる第１のステップは、競争力の高い無線アクセス技術を実現する、高速下りリンク・パケット・アクセス（ＨＳＤＰＡ）、および高速上りリンク・パケット・アクセス（ＨＳＵＰＡ）とも呼ばれるエンハンスト（ｅｎｈａｎｃｅｄ）上りリンクを導入することを含む。

さらに増大するユーザの需要に備え、新しい無線アクセス技術に対する競争力を確保するために、ロング・ターム・エボルーション（ＬＴＥ）と呼ばれる新しいモバイル通信システムが導入された。ＬＴＥは、次の１０年の高速データ媒体転送と高容量音声サポートのキャリア要件を満たすように設計されている。高ビット・レートを実現する能力は、ＬＴＥの重要な手段である。

拡張ＵＭＴＳ地上無線アクセス（ＵＴＲＡ）およびＵＭＴＳ地上無線アクセス・ネットワーク（ＵＴＲＡＮ）と呼ばれるロング・ターム・エボルーション（ＬＴＥ）に関する作業項目（ＷＩ）仕様がリリース８（ＬＴＥ）として完成している。ＬＴＥシステムは、レイテンシが低くコストが安いＩＰベースの全機能を実現する、パケット・ベースの効率的な無線アクセスおよび無線アクセス・ネットワークを代表するシステムである。詳細なシステム要件が示されている。ＬＴＥでは、所与のスペクトルを使用して融通性に富んだシステム展開を実現するために、１．４ＭＨｚ、３．０ＭＨｚ、５．０ＭＨｚ、１０．０ＭＨｚ、１５．０ＭＨｚ、および２０．０ＭＨｚのようなスケーラブルな複数の送信帯域幅が指定されている。下りリンクでは、シンボル・レートが低く、周期プレフィックス（ＣＰ）が使用され、様々な送信帯域幅設定に適合するので、本来、マルチパス干渉の影響（ＭＰＩ）を受けにくいという理由で、直交周波数分割多重方式（ＯＦＤＭ）ベースの無線アクセスが採用された。上りリンクでは、ユーザ端末（ＵＥ）の送信電力が制限されることを考慮して、ピーク・データ・レートの向上よりも広いサービス・エリアのプロビジョニングが優先されたため、シングル・キャリア周波数分割多元接続（ＳＣ−ＦＤＭＡ）が採用された。多入力多出力（ＭＩＭＯ）チャネル送信技術を含む多数の重要なパケット無線アクセス技術が使用され、ＬＴＥ（リリース８）において極めて効率的な制御シグナリング構造が実現されている。

ＬＴＥアーキテクチャ
全体的なアーキテクチャが図１に示されており、Ｅ−ＵＴＲＡＮアーキテクチャのより詳細な表現が図２に示されている。Ｅ−ＵＴＲＡＮは、ユーザ端末に対して、Ｅ−ＵＴＲＡユーザ・プレーン（ＰＤＣＰ／ＲＬＣ／ＭＡＣ／ＰＨＹ）および制御プレーン（ＲＲＣ）プロトコル終了を提供するｅＮｏｄｅＢからなる。ｅＮｏｄｅＢ（ｅＮＢ）は、物理層（ＰＨＹ）、媒体アクセス制御（ＭＡＣ）層、無線リンク制御（ＲＬＣ）層、および、ユーザ・プレーン・ヘッダ圧縮と暗号化の機能を含むパケット・データ制御プロトコル（ＰＤＣＰ）層、を管理する。ｅＮｏｄｅＢは、制御プレーンに対応する無線リソース制御（ＲＲＣ）機能も実現する。ｅＮｏｄｅＢは、無線リソース管理、アドミッション制御、スケジューリング、取り決めた上りリンク・サービス品質（ＱｏＳ）の実施、セル情報ブロードキャスト、ユーザ・プレーン・データおよび制御プレーン・データの暗号化／解読、ならびに下りリンク／上りリンク・ユーザ・プレーン・パケット・ヘッダの圧縮／解凍を含む多数の機能を実行する。ｅＮｏｄｅＢ同士はＸ２インタフェースによって互いに接続される。

ｅＮｏｄｅＢは、Ｓ１インタフェースによってＥＰＣ（拡張パケットコア）にも接続され、より具体的にはＳ１−ＭＭｅによってＭＭＥ（無線通信移動管理装置）に接続され、Ｓ１−Ｕによってサービング・ゲートウェイ（ＳＧＷ）に接続される。Ｓ１インタフェースは、ＭＭＥ／サービング・ゲートウェイとｅＮｏｄｅＢとの間の多対多関係をサポートする。ＳＧＷはユーザ・データ・パケットをルーティングして転送し、一方、ｅＮｏｄｅＢ間ハンドオーバ時にユーザ・プレーンのモビリティ・アンカとしても働くとともに、ＬＴＥと他の３ＧＰＰ技術（Ｓ４インタフェースの終端および２Ｇ／３ＧシステムとＰＤＮ ＧＷとの間のトラフィックの中継）との間のモビリティ・アンカとしても働く。アイドル状態のユーザ端末の場合、ＳＧＷは、下りリンク・データ・パスを終端させ、下りリンク・データがユーザ端末に到着したときにページングをトリガする。ＳＧＷは、ユーザ端末のコンテキスト、たとえばＩＰベアラー・サービスのパラメータ、ネットワーク内部ルーティング情報を管理し記憶する。ＳＧＷは、合法的な傍受の場合にユーザ・トラフィックの複製も実行する。

ＭＭＥは、ＬＴＥアクセス・ネットワークの主要な制御ノードである。ＭＭＥは、アイドル・モードのユーザ端末トラッキングおよび再送を含むページング手順を実施する。ＭＭＥは、ベアラーのアクティベート／ディアクティベート・プロセスに関与し、初期アタッチ時およびコア・ネットワーク（ＣＮ）ノード・リロケーションを含むＬＴＥ内ハンドオーバ時にユーザ端末のＳＧＷを選択する。ＭＭＥは、（ＨＳＳと対話することによって）ユーザを認証する。ＮＡＳ（Ｎｏｎ−Ａｃｃｅｓｓ Ｓｔｒａｔｕｍ）のシグナリングは、ＭＭＥにおいて終端し、ユーザ端末のテンポラリＩＤを生成し割り当てる。ＭＭＥは、ユーザ端末の権限を検査して、サービス・プロバイダの地上波公共移動通信ネットワーク（ＰＬＭＮ）に入り、ユーザ端末のローミング上の制約を実施する。ＭＭＥは、ＮＡＳシグナリングの暗号化／インテグリティ保護のためにネットワークの末端に位置し、セキュリティ・キーの管理を行う。シグナリングの合法的な傍受もＭＭＥによってサポートされる。ＭＭＥは、ＬＴＥと２Ｇ／３Ｇアクセス・ネットワークとの間のモビリティに関する制御プレーン機能として、ＳＧＳＮからＭＭＥにおいて終了するＳ３インタフェースも実現する。ＭＭＥは、ローミングするユーザ端末用のホームＨＳＳ向けのＳ６ａインタフェースも終端させる。

ＬＴＥ（リリース８）におけるコンポーネント・キャリア構造
３ＧＰＰ ＬＴＥ（リリース８）の下りリンク・コンポーネント・キャリアは、時間−周波数領域においていわゆるサブフレームに細分される。３ＧＰＰ ＬＴＥ（リリース８）では、各サブフレームは２つの下りリンク・スロットに分割され、第１の下りリンク・スロットは、第１のＯＦＤＭシンボル内に制御チャネル領域（ＰＤＣＣＨ領域）を含む。各サブフレームは、時間領域における所与の数のＯＦＤＭシンボルからなり（３ＧＰＰ ＬＴＥ（リリース８）では１２個または１４個のＯＦＤＭシンボル）、各ＯＦＤＭシンボルは、コンポーネント・キャリアの帯域幅全体に及ぶ。したがって、各ＯＦＤＭシンボルは、図４にも示されているそれぞれの

個のサブキャリア上で送信されるいくつかの変調シンボルからなる。

たとえばＯＦＤＭを使用するマルチキャリア通信システムを仮定すると、たとえば３ＧＰＰの「ロング・タイム・エボルーション」作業項目で論じられているように、スケジューラによって割り当てることのできるリソースの最小単位は１つの「リソース・ブロック」である。物理的なリソース・ブロックは、図４に例示されているように、時間領域における

個の連続的なＯＦＤＭシンボルおよび周波数領域における

個の連続的なＯＦＤＭシンボルとして定義される。したがって、３ＧＰＰ ＬＴＥ（リリース８）では、物理リソース・ブロックは、時間領域における１つのスロットおよび周波数領域における１８０ｋＨｚに対応する

個のリソース要素からなる（下りリンク・リソース・グリッドに関する詳細は、ｈｔｔｐ：／ｗｗｗ．３ｇｐｐ．ｏｒｇにおいて入手可能であり、参照によって本明細書に組み込まれる３ＧＰＰ ＴＳ ３６．２１１「Ｅｖｏｌｖｅｄ Ｕｎｉｖｅｒｓａｌ Ｔｅｒｒｅｓｔｒｉａｌ Ｒａｄｉｏ Ａｃｃｅｓｓ（Ｅ−ＵＴＲＡ）；Ｐｈｙｓｉｃａｌ Ｃｈａｎｎｅｌｓ ａｎｄ Ｍｏｄｕｌａｔｉｏｎ（リリース８）」、バージョン８．７．０、第６．２節（非特許文献１）を参照されたい）。

下りリンク物理チャネルの概略的な構造
３ＧＰＰ ＴＳ ３６．２１１「Ｅｖｏｌｖｅｄ Ｕｎｉｖｅｒｓａｌ Ｔｅｒｒｅｓｔｒｉａｌ Ｒａｄｉｏ Ａｃｃｅｓｓ（Ｅ−ＵＴＲＡ）；Ｐｈｙｓｉｃａｌ ｃｈａｎｎｅｌｓ ａｎｄ ｍｏｄｕｌａｔｉｏｎ」、バージョン８．６．０、２００９年３月、第６．３節（非特許文献２）（ｈｔｔｐ：／ｗｗｗ．３ｇｐｐ．ｏｒｇにおいて入手可能であり、参照によって本明細書に組み込まれる）による概略的な下りリンクＬＴＥベースバンド信号処理が、図６に例示されている。ＬＴＥ下りリンクに関する詳細は、３ＧＰＰ ＴＳ ３６．２１１第６節に記載されている。まず、符号化されたビットのブロックにスクランブルをかける。最大で２つの符号語を１つのサブフレームにおいて送信してもよい。

一般に、符号化されたビットにスクランブルをかけると、受信側の復号では、チャネル符号によって実現される処理ゲインを十分に利用することができる。符号語ごとに、互いに近接するセルに様々なスクランブル・シーケンスを適用することによって、互いに干渉する信号が無作為化され、チャネル符号によって実現される処理ゲインが確実に十分に利用される。スクランブルをかけられたビットは、各符号語にデータ変調器を使用して複素変調シンボルのブロックに変換される。ＬＴＥ下りリンクによってサポートされる変調方式の組には、変調シンボル当たり２ビット、４ビット、または６ビットに相当するＱＰＳＫ、１６−ＱＡＭ、および６４−ＱＡＭが含まれる。

レイヤ・マッピングおよびプリコーディングはＭＩＭＯアプリケーションに関連付けられる。送信すべき各符号語の複素変調シンボルが、１つまたは複数のレイヤ上にマッピングされる。ＬＴＥは最大で４本の送信アンテナをサポートする。アンテナ・マッピングは、送信ダイバーシチ、ビーム形成、および空間多重化を含むマルチ・アンテナ方式を実現するように様々な方法で設定することができる。また、リソース・ブロック・マッパが、各アンテナ上で送信すべきシンボルを、送信に関してスケジューラによって割り当てられる１組のリソース・ブロック上のリソース要素にマッピングする。どのリソース・ブロックを選択するかは、チャネル品質情報によって決まる。

下りリンク制御シグナリングは、以下の３つの物理チャネルによって実行される。
- サブフレームにおける制御シグナリングのために使用されるＯＦＤＭシンボルの数（すなわち、制御チャネル領域のサイズ）を示すＰＣＦＩＣＨ
- ＵＬデータ送信に関連する下りリンクＡＣＫ／ＮＡＣＫを伝送するＰＨＩＣＨ
- 下りリンク・スケジューリング割り当ておよび上りリンク・スケジューリング割り当てを伝送するＰＤＣＣＨ

３ＧＰＰ ＬＴＥにおける下りリンク受信
３ＧＰＰ ＬＴＥ（リリース８）では、下りリンクおよび上りリンクにおいてコンポーネント・キャリアが１つしかなく、ＰＣＦＩＣＨは、周知の変調符号化方式を使用して下りリンクサブフレームの制御シグナリング領域内の周知の位置において送信される。ユーザ端末にどの下りリンク・リソースを割り当てるかの判定は、サブフレームの制御シグナリング領域のサイズ、すなわち所与のサブフレームにおける制御シグナリングのために使用されるＯＦＤＭシンボルの数に応じて行われるので、ユーザ端末は、ＰＣＦＩＣＨを復号して、シグナリングされるＰＣＦＩＣＨ値、すなわちサブフレームにおける制御シグナリングに使用されるＯＦＤＭシンボルの実際の数を取得する必要がある。

ユーザ端末がＰＣＦＩＣＨを復号できないかあるいは誤ったＰＣＦＩＣＨ値を取得した場合、このＰＣＦＩＣＨ検出エラーによって、ユーザ端末が制御シグナリング領域に備えられたＬ１／Ｌ２制御シグナリング（ＰＤＣＣＨ）を正しく復号できなくなり、したがって、制御シグナリング領域に含まれるすべてのリソース割り当てが失われる。

物理下りリンク制御チャネル（ＰＤＣＣＨ）割り当て
物理下りリンク制御チャネル（ＰＤＣＣＨ）は、下りリンク・データ送信または上りリンク・データ送信用のリソースを割り当てるためのスケジューリング・グラントを伝送する。各スケジューリング・グラントは、制御チャネル要素（ＣＣＥ）に基づいて定義される。各ＣＣＥは、１組のリソース要素（ＲＥ）に対応する。３ＧＰＰＰ ＬＴＥでは、１つのＣＣＥが９つのリソース要素群（ＲＥＧ）からなり、１つのＲＥＧが４つのＲＥからなる。

ＰＤＣＣＨは、サブフレーム内の最初の１〜３つのＯＦＤＭシンボル上で送信される。物理下りリンク共有チャネル（ＰＤＳＣＨ）上での下りリンクグラントの場合、ＰＤＣＣＨは同じサブフレーム内の（ユーザ）データ用のＰＤＳＣＨリソースを割り当てる。サブフレーム内のＰＤＣＣＨ制御チャネル領域は１組のＣＣＥからなり、サブフレームの制御領域内のＣＣＥの総数が、時間・周波数制御リソース全体にわたって分散される。複数のＣＣＥを組み合わせて制御チャネルの符号化率を効果的に低下させることができる。ＣＣＥは、ツリー構造を使用して所定の方法で組み合わされ、異なる符号化率を実現する。

３ＧＰＰ ＬＴＥでは、ＰＤＣＣＨが１つ、２つ、４つ、または８つのＣＣＥをアグリゲートする。制御チャネル割り当てに利用できるＣＣＥの数は、キャリア帯域幅、送信アンテナの数、制御に使用されるＯＦＤＭシンボルの数、およびＣＣＥサイズなどを含むいくつかの因子の関数である。複数のＰＤＣＣＨを１つのサブフレームで送信してもよい。

転送チャネル・レベルでは、ＰＤＣＣＨを介して送信される情報はＬ１／Ｌ２制御シグナリングとも呼ばれる。Ｌ１／Ｌ２制御シグナリングは下りリンクではユーザ端末（ＵＥ）ごとに送信される。制御シグナリングは、一般にサブフレーム内の下りリンク（ユーザ）データによって多重化される（ユーザ割り当てがサブフレームごとに変わると仮定する）。一般に、ユーザ割り当てをＴＴＩ(送信時間間隔)ごとに実行してもよいことに留意されたい、ここで（時間領域における）ＴＴＩの長さは１つまたは複数のサブフレームと等価である。ＴＴＩの長さは、すべてのユーザのサービス領域において一定であってもよく、あるいは場合によってはユーザごとに動的であってもよい。一般に、Ｌ１／Ｌ２制御シグナリングをＴＴＩ当たりに一度送信するだけでよい。

また、Ｌ１／Ｌ２制御シグナリング上で送信されるＰＤＣＣＨ情報を共有制御情報（ＳＣＩ）および下りリンク制御情報（ＤＣＩ）に分離してもよい。

下りリンクにおけるＬＴＥ物理チャネル構造およびＰＤＳＣＨ・ＰＤＣＣＨフォーマットに関する詳細は、Ｓｔ．Ｓｅｓｉａら著「ＬＴＥ−Ｔｈｅ ＵＭＴＳ Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ」、Ｗｉｌｌｅｙ ＆ Ｓｏｎｓ Ｌｔｄ．、ＩＳＢＮ９７８−０−４７０６９７１６−０、２００９年４月、第６節および第９節（非特許文献３）を参照されたい。

物理制御フォーマット・インジケータ・チャネル（ＰＣＦＩＣＨ）割り当て
物理制御フォーマット・インジケータ・チャネル（ＰＣＦＩＣＨ）は、サブフレームにおいてＰＤＣＣＨを送信するのに使用されるＯＦＤＭシンボルの数に関する情報を伝送する。サブフレーム内のＰＤＣＣＨに使用することが可能な１組のＯＦＤＭシンボルを以下の表１に示す。

表１を見るとわかるように、ＰＣＦＩＣＨ値はコンポーネント・キャリアの帯域幅によって決まる。以下の表２は、いくつかの例示的な送信シナリオおよび各シナリオのＰＣＦＩＣＨ値の典型的な設定を示している。

ＬＴＥ−ＬＴＥアドバンスト（３ＧＰＰ ＬＴＥ−Ａ）のさらなる向上
２００８年１１月にＷｏｒｌｄ Ｒａｄｉｏ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｃｏｎｆｅｒｅｎｃｅ ２００７（ＷＲＣ−０７）においてＩＭＴアドバンスト用の周波数スペクトルが決定された。ＩＭＴアドバンスト用の全体的な周波数スペクトルは決定されたが、利用可能な実際の周波数帯域幅は各地域または各国に応じて異なる。しかし、利用可能な周波数スペクトルの概要が決定された後、無線インタフェースの標準化が３ｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ（３ＧＰＰ）において開始された。３ＧＰＰ ＴＳＧ ＲＡＮ ＃３９会議において、「リリース１０」とも呼ばれる「Ｅ−ＵＴＲＡ（ＬＴＡアドバンスト）のさらなる向上」に関する検討項目名称が承認された。この検討項目は、たとえばＩＭＴアドバンストに関する要件を満たすために、Ｅ−ＵＴＲＡの発展について検討すべき技術要素を対象とする。ＬＴＥ−Ａについて現在検討中の２つの主要な技術要素について以下に説明する。

ＬＴＥ−Ａ（リリース１０）は、システム帯域幅全体を拡張するために、キャリア・アグリゲーションを使用する。キャリア・アグリゲーションでは、ＬＴＥ（リリース８）について定義された２つ以上のコンポーネント・キャリア（上述の図３および図４を参照されたい）がアグリゲートされてより広い送信帯域幅、たとえば最大１００ＭＨｚの帯域幅をサポートし、かつスペクトル・アグリゲーションを実施する。一般に、単一のコンポーネント・キャリアの帯域幅は２０ＭＨｚを超えないと仮定されている。

端末は、その機能に応じて１つまたは複数のコンポーネント・キャリア上で受信および／または送信を同時に行うことができる。

- キャリア・アグリゲーション用の受信機能および／または送信機能を有するＬＴＥアドバンスト（リリース１０）互換モバイル端末は、複数のコンポーネント・キャリア上で受信および／または送信を同時に行うことができる。コンポーネント・キャリア当たりに１つのトランスポート・ブロック（空間多重化を行わない場合）および１つのＨＡＲＱエンティティがある。

- ＬＴＥ（リリース８）互換モバイル端末は、コンポーネント・キャリアの構造がリリース８仕様に従うならば、単一のコンポーネント・キャリアのみで受信および送信を行うことができる。

アグリゲートされるコンポーネント・キャリアの数が上りリンクと下りリンクとで同じであるときには、すべてのコンポーネント・キャリアをＬＴＥ(リリース８)互換性をもつように設定することも考えられる。ＬＴＥ−Ａ（リリース１０）コンポーネント・キャリアの非後方互換性構成も考えられる。したがって、上りリンクと下りリンクとで場合によっては異なる帯域幅の異なる数のコンポーネント・キャリアをアグリゲートするようにユーザ端末を構成することが可能である。

また、３ＧＰＰ無線アクセス・ネットワーク・ワーキング・グループ１（ＲＡＮ１）第５７回ｂｉｓ会議では、ＬＴＥ−Ａ（リリース１０）に関してコンポーネント・キャリア・タイプの以下の定義が合意された。

- 後方互換性キャリア
すべての既存のＬＴＥリリースのユーザ端末からアクセスできるキャリア
単一のキャリアまたはキャリア・アグリゲーションの一部として動作させることができる（スタンドアロン）。
ＦＤＤの場合、後方互換性を有するキャリアは、上りリンクと下りリンクで常に対形態である。

- 非後方互換性キャリア
指定に応じて、初期のＬＴＥリリースのユーザ端末からはアクセスできないキャリアであるが、そのようなキャリアを定義するリリースのユーザ端末からはアクセスできるキャリア。
非後方互換性が二重距離によって実現されるか、あるいはキャリア・アグリゲーションの一部として実現される場合に、単一のキャリアとして動作することができる（スタンドアロン）。

- エクステンション・キャリア
指定に応じて、単一のキャリアとして動作できない（スタンドアロン）が、コンポーネント・キャリア・セットの一部でなければならず、このセット内のキャリアの少なくとも１つがスタンドアロン可能なキャリアであるキャリア。
エクステンション・キャリアがデータ専用キャリアであってよく、すなわち制御領域を有さなくてよいことも現在議論中である。

３ＧＰＰ ＬＴＥ−ＡにおけるＰＤＣＣＨ構造およびクロス・キャリア・スケジューリング
上記に指摘したように、３ＧＰＰ ＬＴＥ−Ａ（リリース１０）では、キャリア・アグリゲーション、すなわち上りリンクおよび下りリンクのそれぞれで複数のコンポーネント・キャリアが使用される。現在、３ＧＰＰによって、クロス・キャリア・スケジューリングを利用することが考えられており、すなわち、１つの下りリンク・コンポーネント・キャリア上の（単一の）ＰＤＣＣＨが複数のコンポーネント・キャリア上に下りリンク（物理下りリンク共有チャネル−ＰＤＳＣＨ）または（物理上りリンク共有チャネル−ＰＵＳＣＨ上の）上りリンク・リソースを割り当ててもよい（３ＧＰＰ ＲＡＮ １第５８回会議において合意され、ｈｔｔｐ：／／ｗｗｗ．３ｇｐｐで入手可能であり、参照によって本明細書に組み込まれる３ＧＰＰ Ｔｄｏｃ．Ｒ１−０９４９５９「ＴＰ ｆｏｒ ＴＲ３６．８１４ ｏｎ ｄｏｗｎｌｉｎｋ ｃｏｎｔｒｏｌ ｓｉｇｎａｌｌｉｎｇ ｆｏｒ ｃａｒｒｉｅｒ ａｇｇｒｅｇａｔｉｏｎ」（非特許文献４）を参照されたい）。クロス・キャリア・スケジューリングを使用する理由は、異種ネットワーク動作が可能であること、サポートエクステンション・キャリア動作が可能であること、ＰＤＣＣＨ ＣＣＥブロッキング確率の場合に効率的なスケジューリングが可能であることなどである。

３ＧＰＰでは、（下りリンク）コンポーネント・キャリア上のＰＤＣＣＨが同じコンポーネント・キャリア上にＰＤＳＣＨリソースを割り当て、リンクされた単一のＵＬコンポーネント・キャリア上にＰＵＳＣＨリソースを割り当ててもよいことが合意されている。各コンポーネント・キャリア上でリリース８ ＰＤＣＣＨ構造（同じ符号化、同じＣＣＥベースのリソース・マッピング）およびＤＣＩフォーマットが使用される。また、コンポーネント・キャリア上のＰＤＣＣＨを使用し、キャリア・インジケータ・フィールド（ＣＩＦ）を使用して複数のコンポーネント・キャリアの１つにＰＤＳＣＨリソースまたはＰＵＳＣＨリソースを割り当ててもよく、この場合、３ＧＰＰ ＬＴＥ（リリース８）ＤＣＩフォーマットが固定３ビット・キャリア・インジケータ・フィールドによって拡張され、３ＧＰＰ ＬＴＥ（リリース８）ＰＤＣＣＨ構造（同じ符号化、同じＣＣＥベースのリソース・マッピング）が再使用される。キャリア・インジケータ・フィールドの存在は半静的に設定されてもよい。図６は、３ＧＰＰ ＬＴＥ−Ａモバイル通信ネットワークでのクロス・キャリア・スケジューリングにおけるキャリア・インジケータ・フィールド（ＣＩＦ）の使用法を例示している。

このようなクロス・キャリア・スケジューリングをサポートする理由は以下の通りである。

- キャリア・インジケータ・フィールドを使用して、他の後方互換性／非後方互換性キャリアにおけるＰＤＣＣＨを使用するエクステンション・キャリア上のデータ送信をサポートすること。

- 異種ネットワーク動作。これは、ネットワークがマクロｅＮｏｄｅＢ、ホームｅＮｏｄｅＢ、フェムト／ピコ・セルからなってもよいことを意味する。この干渉シナリオは、それぞれの異なるネットワーク条件に応じて異なってもよい。したがって、干渉をあまり受けないコンポーネント・キャリア、典型的には、電力が高くチャネル条件がより優れているコンポーネント・キャリア上で、ＰＤＣＣＨを送信すればよい。また、変調符号化方式／トランスポート・ブロック・サイズをチャネル・サイズに適合することができるので、より低電力の（干渉が強い）コンポーネント・キャリア上でＰＤＳＣＨを送信してもよい。また、ＨＡＲＱを（制御するためではなく）データに使用してもよい。これらのシナリオでは、クロス・キャリア・スケジューリングを使用してもよい。

- より小さい帯域幅のコンポーネント・キャリアの場合、サブフレーム内の制御シグナリング領域は通常小さく、すなわち少数のＰＤＣＣＨしかシグナリングできない。したがって、このようなコンポーネント・キャリア上のＣＣＥブロッキング確率はより高い。この場合、ＰＤＣＣＨを他のより高い帯域幅のコンポーネント・キャリアから送信することができる（クロス・キャリア・スケジューリングを使用する）。

上述のように、下りリンク・データ割り当ての場合、データを伝送するコンポーネント・キャリア上のＰＣＦＩＣＨ検出エラーによって、３ＧＰＰ ＬＴＥにおけるＰＤＣＣＨ復号にエラーが生じる。クロス・キャリア・スケジューリングを使用する場合、ＰＤＣＣＨ内にＣＩＦフィールドが構成され、したがって、ユーザ端末が、ＰＤＣＣＨを伝送する下りリンク・コンポーネント・キャリアのＰＣＦＩＣＨ値を正しく求めたと仮定することがある。ＰＤＣＣＨも正しく復号された場合、ユーザ端末は、別の下りリンク・コンポーネント・キャリア上で「有効な」リソース割り当てを得ていると考えられる。以下に詳しく説明するように、ユーザ端末は、ＰＤＣＣＨが受信された下りリンク・コンポーネント・キャリア以外の下りリンク・コンポーネント・キャリア上の割り当てられる実際の時間−周波数リソースを判定するために、リソースが割り当てられるコンポーネント・キャリアに関するＰＣＦＩＣＨ値も知る必要がある。このコンポーネント・キャリアのＰＣＦＩＣＨ値が正しくない場合、ユーザ端末は、正しくない割り当てられる時間−周波数リソースを判定し、それに関するデータを受信する。

下りリンク・コンポーネント・キャリア上の送信に、ソフト合成を行うＨＡＲＱを使用すると仮定すると、割り当てられる時間−周波数リソースに関する誤ったデータを受信した場合、データの復号にエラーが生じ、復号済みのデータがソフト・バッファに記憶され、後で再送と組み合わされる。その結果、リソースが無駄になる（すなわち、再送によるさらなる下りリンク・オーバヘッド）とともに、ＨＡＲＱバッファのデータが破壊される。

３ＧＰＰ ＴＳ ３６．２１１「Ｅｖｏｌｖｅｄ Ｕｎｉｖｅｒｓａｌ Ｔｅｒｒｅｓｔｒｉａｌ Ｒａｄｉｏ Ａｃｃｅｓｓ（Ｅ−ＵＴＲＡ）；Ｐｈｙｓｉｃａｌ Ｃｈａｎｎｅｌｓ ａｎｄ Ｍｏｄｕｌａｔｉｏｎ（リリース８）」、バージョン８．７．０、第６．２節 ３ＧＰＰ ＴＳ ３６．２１１「Ｅｖｏｌｖｅｄ Ｕｎｉｖｅｒｓａｌ Ｔｅｒｒｅｓｔｒｉａｌ Ｒａｄｉｏ Ａｃｃｅｓｓ（Ｅ−ＵＴＲＡ）；Ｐｈｙｓｉｃａｌ ｃｈａｎｎｅｌｓ ａｎｄ ｍｏｄｕｌａｔｉｏｎ」、バージョン８．６．０、２００９年３月、第６．３節 Ｓｔ．Ｓｅｓｉａら著「ＬＴＥ−Ｔｈｅ ＵＭＴＳ Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ」、Ｗｉｌｌｅｙ ＆ Ｓｏｎｓ Ｌｔｄ．、ＩＳＢＮ９７８−０−４７０６９７１６−０、２００９年４月、第６節および第９節 ３ＧＰＰ Ｔｄｏｃ．Ｒ１−０９４９５９「ＴＰ ｆｏｒ ＴＲ３６．８１４ ｏｎ ｄｏｗｎｌｉｎｋ ｃｏｎｔｒｏｌ ｓｉｇｎａｌｌｉｎｇ ｆｏｒ ｃａｒｒｉｅｒ ａｇｇｒｅｇａｔｉｏｎ」 ３ＧＰＰ ＴＳ ３６．２１２「Ｅｖｏｌｖｅｄ Ｕｎｉｖｅｒｓａｌ Ｔｅｒｒｅｓｔｒｉａｌ Ｒａｄｉｏ Ａｃｃｓｅｅ（Ｅ−ＵＴＲＡ）；Ｍｕｌｔｉｐｌｅｘｉｎｇ ａｎｄ ｃｈａｎｎｅｌ ｃｏｄｉｎｇ （Ｒｅｌｅａｓｅ ８）」、バージョン８．７．０、第５．３．３．１節

本発明の一目的は、上記に概略的に説明した問題を解消することである。特に、本発明の一目的は、ＨＡＲＱソフト・バッファ破壊および／またはシステム・スループットの劣化を生じさせる可能性のある割り当てられる物理リソースの誤検出を回避しつつ、ＨＡＲＱキャリア・アグリゲーションを使用してモバイル通信システムにおけるクロス・キャリア・スケジューリングを可能にすることである。

この課題は、独立クレームの主題によって解決される。本発明の有利な実施態様は従属クレームに従う。

本発明の一態様は、下りリンク制御情報によってリソースが割り当てられるコンポーネント・キャリア上のサブフレーム内の制御シグナリングのために使用される１つまたは複数のＯＦＤＭシンボルの数を下りリンク制御情報（ＤＣＩ）内に明示する方式を提案する。割り当てられるコンポーネント・キャリア上のサブフレーム内の１つまたは複数のＯＦＤＭシンボルの指示は、たとえば、他の制御シグナリング情報、たとえばキャリア・インジケータ・フィールドのキャリア指示と一緒に符号化される。キャリア・インジケータ・フィールドは、下りリンク制御情報の一部であり、（下りリンク制御情報のリソース割り当てフィールドに備えられた）リソース割り当てに関するコンポーネント・キャリアと、リソース割り当てによって、制御シグナリングに使用されるリソースが割り当てられるコンポーネント・キャリア上のモバイル端末に割り当てられる、サブフレーム内の１つまたは複数のＯＦＤＭシンボルの数を示すのに使用される。語「下りリンク制御情報」と語「個別制御情報」が同義であることに留意されたい。

このように、クロス・キャリア・スケジューリング・シナリオでは、下りリンク・システム・スループットの劣化を回避することができ、リソースの誤った利用によるＨＡＲＱバッファの破壊を回避することができる。

本発明のいくつかの実施態様は、下りリンク制御情報用の新しいフォーマット（Ｌ１／Ｌ２制御シグナリングまたはＰＤＣＣＨとも呼ばれる）のプロビジョニングに関する。一実施態様によれば、下りリンクにおいてコンポーネント・キャリアのアグリゲーション（すなわち、キャリア・アグリゲーション）を使用することのできるモバイル通信システムにおいて使用される下りリンク制御情報フォーマットが設けられる。このような通信システムの一例は３ＧＰＰ ＬＴＥ−Ａ（リリース１０）システムであるが、本発明は、３ＧＰＰ ＬＴＥ−Ａ（リリース１０）システムのさらなる拡張システムに適用することもできる。

この実施態様では、下りリンク制御情報フォーマットは、下りリンクにおける１つのコンポーネント・キャリアのサブフレーム内の割り当てられる下りリンク・リソースを示すリソース割り当てフィールドと、下りリンク・リソースがどのコンポーネント・キャリアに割り当てられるかを示し、制御シグナリングに使用されるコンポーネント・キャリア上の割り当てられるサブフレーム内のＯＦＤＭシンボルの数をさらに示すキャリア・インジケータ・フィールドとを含む。例示的な一実施態様では、キャリア・インジケータ・フィールドはサイズが３ビットである（したがって、８つの符号点または値を示すことができる）。

本発明が、３ＧＰＰ ＬＴＥ−Ａのような３ＧＰＰベースの通信システムにおいて実施される場合、リソース割り当てフィールドを２つ以上の異なるフィールド、たとえば、１つまたは複数のリソース・ブロック・インデックス、すなわち割り当てられるリソース・ブロックを示すリソース・ブロック割り当てフィールドと、データの変調符号化方式とその冗長バージョンを示すのに使用される変調符号化方式フィールドとで構成することができることに留意されたい。

本発明のさらなる実施形態では、キャリア・インジケータ・フィールドのビットによって示すことのできる制御シグナリングに使用されるＯＦＤＭシンボルの数の範囲は、制御シグナリングに使用できるＯＦＤＭシンボルの数の全範囲のサブセットのみをカバーする。たとえば、サブフレームは制御シグナリングに使用されるＮ_ｍａｘ個のＯＦＤＭシンボルを有してもよく、一方、キャリア・インジケータ・フィールドのビットは、範囲［０，．．．，Ｎ_ｍａｘ］の値のサブセットしか指示できない。

このサブセットは、たとえば様々なパラメータによって決まり、かつ／またはネットワークからの上位層制御シグナリングによって（たとえば、基地局、３ＧＰＰ用語のｅＮｏｄｅＢ）設定されてもよい。たとえば、キャリア・インジケータ・フィールドによって示すことのできる制御シグナリングに使用されるＯＦＤＭシンボルの数の範囲のサブセットは、以下のパラメータのうちの少なくとも１つによって決まるものであってもよい。

- 割り当てられる下りリンク・コンポーネント・キャリア上の干渉条件および電力レベル、
- 割り当てられる下りリンク・コンポーネント・キャリア上のチャネル品質、
- 割り当てられる下りリンク・コンポーネント・キャリアの帯域幅、
- 下りリンク・コンポーネント・キャリアの負荷分散関数のステータス、
- 割り当てられる下りリンク・コンポーネント・キャリアの種類、
- 下りリンク制御情報が送信されるコンポーネント・キャリア上の制御シグナリングに使用されるＯＦＤＭシンボルの数、および
- 割り当てられるコンポーネント・キャリア上でシグナリングすべき下りリンクＡＣＫ／ＮＡＣＫの数

本発明のさらなる実施態様は、複数の下りリンク・コンポーネント・キャリアのうちの１つの下りリンク・コンポーネント・キャリアのサブフレーム内の下りリンク・リソースをモバイル端末に割り当てる方法を提供する。モバイル端末は、１つの下りリンク・コンポーネント・キャリアに関する個別制御チャネル情報を受信する。このコンポーネント・キャリアは、以下ではＰＤＣＣＨコンポーネント・キャリアとも呼ばれる。上記に概略的に説明したように、下りリンク制御情報フォーマットは、少なくとも下りリンク・コンポーネント・キャリア上のサブフレーム内の割り当てられる下りリンク・リソースを示すリソース割り当てフィールドと、キャリア・インジケータ・フィールドとを含む。キャリア・インジケータ・フィールドは、下りリンク・リソースをどのコンポーネント・キャリアに割り当てるかを示し、下りリンク制御情報によって下りリンク・リソースが割り当てられるコンポーネント・キャリア上のサブフレーム内の制御シグナリングのために使用されるＯＦＤＭシンボルの数をさらに示す。また、この方法によれば、モバイル端末は割り当てられる下りリンク・リソースに関する下りリンク・データを受信する。下りリンク制御情報が、本明細書で説明する下りリンク制御情報フォーマットの様々な例示的な実施態様の１つによるフォーマットを有してもよいことに留意されたい。

キャリア・インジケータ・フィールドは、下りリンク・リソースがどのコンポーネント・キャリアに割り当てられるかを示し、同時に、キャリア・インジケータのビットによって表すことのできる（すなわち、この２種類の情報が一緒に符号化される）様々な符号点（または値）によって、割り当てられるサブフレーム内で下りリンク・データが送信されるコンポーネント・キャリア上の制御シグナリングのために使用されるＯＦＤＭシンボルの数を示すのに使用される。例示的な一実施態様では、キャリア・インジケータ・フィールドによって表すことのできる符号点は、少なくとも２つの異なるサブセットに分割される。サブセットのそれぞれの符号点は、下りリンク制御情報によって下りリンク・リソースが割り当てられるコンポーネント・キャリア上のサブフレーム内の制御シグナリングのために使用されるそれぞれの異なる数のＯＦＤＭシンボルにモバイル端末によってマッピングされる。言い換えれば、サブセットはそれぞれ、下りリンク・リソースがモバイル端末に割り当てられるコンポーネント・キャリア上のサブフレーム内の制御シグナリングのために使用されるそれぞれの数のＯＦＤＭシンボルに関連付けられる。

たとえば、キャリア・インジケータ・フィールドの符号点が２つのサブセットに分割される場合、第１のサブセットに属する符号点は、制御シグナリングに使用されるコンポーネント・キャリア上の割り当てられるサブフレーム内にｎ_１∈［０，．．．Ｎ_ｍａｘ］個のＯＦＤＭシンボルがあることを示すことができ、一方、第２のサブセットの符号点は、制御シグナリングに使用されるコンポーネント・キャリア上の割り当てられるサブフレーム内にｎ_２∈［０，．．．Ｎ_ｍａｘ］個のＯＦＤＭシンボルがあることを示すことができる。もちろん、キャリア・インジケータ・フィールドが３つ、４つ、または５つ以上のサブセットに分割される場合に対応する方式を提供することもできる。

明らかに、シグナリングすることのできる制御シグナリング用のＯＦＤＭシンボルの考えられる数からの値の範囲は、サブセットの数に対応する範囲であってもよく、サブセットの数は、キャリア・インジケータ・フィールドのサイズ、および下りリンク制御情報におけるリソース割り当てが有効である様々なコンポーネント・キャリアを示すうえでサブセット当たりに必要な符号点の数によって制限することができる。サブセットの数が、ＰＤＣＣＨコンポーネント・キャリアによってクロス・スケジューリングすることのできるコンポーネント・キャリアの数にも依存することに留意されたい。本発明の別の実施態様では、制御シグナリングに使用されるそれぞれの異なる数のＯＦＤＭシンボルのシグナリングをより柔軟に行えるように、モバイル端末において事前に定められるかあるいは上位層のシグナリングによってモバイル端末に設定された複数の異なるマッピングがある。各マッピングは、各サブセットの符号点の、割り当てられる下りリンク・コンポーネント・キャリア上の制御シグナリングに使用されるそれぞれの数のＯＦＤＭシンボルへのそれぞれのマッピングを示す。

キャリア・インジケータ・フィールドの符号点が２つのサブセットに分割される上記の例を考えると、たとえば、キャリア・インジケータ・フィールドを解釈するためにモバイル端末によって使用されるときに、第１のサブセットに属する符号点が、下りリンク制御情報によってリソースが割り当てられるコンポーネント・キャリア上のサブフレーム内にｎ_１∈［０，．．．Ｎ_ｍａｘ］個のＯＦＤＭシンボルを生成し、一方、第２のサブセットの符号点が、下りリンク制御情報によってリソースが割り当てられるコンポーネント・キャリア上のサブフレーム内にｎ_２∈［０，．．．Ｎ_ｍａｘ］個のＯＦＤＭシンボルを生成することを意味する第１のマッピングＭ_１があってもよい。モバイル端末が別の第２のマッピングＭ_２を使用する場合、モバイル端末は、第１のサブセットに属する符号点が、下りリンク制御情報によってリソースが割り当てられるコンポーネント・キャリア上のサブフレーム内にｎ_３∈［０，．．．Ｎ_ｍａｘ］個のＯＦＤＭシンボルを生成し、一方、第２のサブセットの符号点が、下りリンク制御情報によってリソースが割り当てられるコンポーネント・キャリア上のサブフレーム内にｎ_４∈［０，．．．Ｎ_ｍａｘ］個のＯＦＤＭシンボルを生成することを理解する。ｎ_２がｎ_３に等しくてもよいことに留意されたい（必ずしもそうである必要はない）。

所与の数Ｓのサブセットのキャリア・インジケータ・フィールドによって数（ｎ_ｉ，ｎ_ｋ）（ｎ_ｉ，ｎ_ｋ∈［０，．．．Ｎ_ｍａｘ］）のすべての組み合わせを確実に示す必要がある場合、

個の異なるマッピング（可能なマッピング）を定義する必要がある。しかし、制御シグナリングに使用されるＯＦＤＭシンボルの数（ｎ_ｉ，ｎ_ｋ）のすべての可能な組み合わせシグナリングする必要があるわけではない。なぜなら、それらのいくつかは、実世界の通信システムでは生じない可能性があるためである。

また、例示的な一実装例では、モバイル端末当たりにマッピングを定義してもよい。この場合、マッピングは、下りリンク・リソースが割り当てられるコンポーネント・キャリアにかかわらずキャリア・インジケータ・フィールドの解釈を指定する。したがって、言い換えれば、マッピングは、リソースを割り当てることのできるすべての下りリンク・コンポーネント・キャリア上の制御シグナリング用のＯＦＤＭシンボルの数を定めるのに使用される。例示的な代替実装例では、マッピングはコンポーネント・キャリア当たりに定義される。すべてのモバイル端末が所与のコンポーネント・キャリアに同じマッピングを使用して、それぞれのコンポーネント・キャリア上の制御シグナリング用のＯＦＤＭシンボルの数を定めてもよい。あるいは、モバイル端末およびコンポーネント・キャリア当たりに定義された別個のマッピングがあってもよく、この場合、それぞれのコンポーネント・キャリア上の制御シグナリング用のＯＦＤＭシンボルを示すうえで融通性が最も高くなる。

したがって、本発明の別の実施態様では、上位層のシグナリングによって設定すべき複数の異なるマッピングは、すべての可能なマッピングのサブセットである。

また、本発明の別の実施態様では、それぞれのマッピングは、
- 割り当てられる下りリンク・コンポーネント・キャリア上の干渉条件および電力レベル、
- 割り当てられる下りリンク・コンポーネント・キャリア上のチャネル品質、
- 割り当てられる下りリンク・コンポーネント・キャリアの帯域幅、
- 下りリンク・コンポーネント・キャリアの負荷分散関数のステータス、
- 割り当てられる下りリンク・コンポーネント・キャリアの種類、
- 下りリンク制御情報が送信されるコンポーネント・キャリア上の制御シグナリングに使用されるＯＦＤＭシンボルの数、および
- 割り当てられるコンポーネント・キャリア上でシグナリングすべき上りリンクＡＣＫ／ＮＡＣＫの数
のうちの少なくとも１つによって決まる複数のユース・ケース・シナリオの各々に設けられる。

複数の下りリンク・コンポーネント・キャリアのうちの１つの下りリンク・コンポーネント・キャリアのサブフレーム内の下りリンク・リソースをモバイル端末に割り当てる改良された実施態様では、モバイル端末は、下りリンク制御情報のキャリア・インジケータ・フィールドから制御シグナリングに使用されるＯＦＤＭシンボルの数を定めるうえで、様々な（設定済みのまたは所定の）マッピングのうちのどのマッピングを使用すべきかを示すマッピング選択メッセージを受信する。

複数の下りリンク・コンポーネント・キャリアのうちの１つの下りリンク・コンポーネント・キャリアのサブフレーム内の下りリンク・リソースをモバイル端末に割り当てる改良された別の実施態様では、モバイル端末は、各サブセット内のそれぞれの値の、制御シグナリングに使用されるそれぞれの数のＯＦＤＭシンボルへの様々なマッピングを示す設定メッセージを受信する。モバイル端末は、設定メッセージを受信したことに応答してモバイル端末においてマッピングを記憶または更新する。

また、マッピング選択メッセージおよびマッピング設定メッセージがたとえばＲＲＣシグナリング・メッセージであってもよいことに留意されたい。ＲＲＣシグナリング・メッセージは、各コンポーネント・キャリアに特定的なメッセージ（すなわち、このコンポーネント・キャリアを使用するすべてのモバイル端末にアドレス指定するメッセージ）、たとえば共通ＲＲＣシグナリング・メッセージであっても、あるいは所与のモバイル端末に特定的なメッセージ（すなわち、モバイル端末のすべてのコンポーネント・キャリアにアドレス指定するメッセージ）、たとえば個別ＲＲＣシグナリング・メッセージであってもよい。

前述のように、時間−周波数リソースをリソース・ブロックごとにモバイル端末に割り当ててもよく、この場合、下りリンク・データ用の割り当てられる時間−周波数リソースは、制御シグナリングに使用されるＯＦＤＭシンボルの数および下りリンク・データがモバイル端末に割り当てられるコンポーネント・キャリア上で利用可能な帯域幅によって決まる。したがって、本発明のさらなる実施態様では、モバイル端末は、下りリンク・コンポーネント・キャリアのサブフレーム内の、モバイル端末に割り当てられるリソース・ブロックを、リソース割り当てフィールドおよび制御シグナリングに使用される割り当てられるサブフレーム内のＯＦＤＭシンボルの数から判定する。この場合、下りリンク・データの受信は、サブフレームの判定されたリソース・ブロックに関する変調シンボルを受信することを含む。さらに、モバイル端末はそれに続いて、受信された変調シンボルを復調して符号化された下りリンク・データを取得してもよく、さらに符号化された下りリンク・データを復号してもよい。それによって、変調符号化方式は、下りリンク制御情報のリソース割り当てフィールドによって示される。

本発明の別の実施態様では、下りリンク制御情報が、下りリンク・コンポーネント・キャリアの第１の下りリンク・コンポーネント・キャリア上で受信され、下りリンク・コンポーネント・キャリアのうちの別の第２のコンポーネント・キャリア上にリソースを割り当てる。

３ＧＰＰ ＬＴＥ−Ａ（リリース１０）システムまたは場合によってはそのさらに改善されたバージョンにおいて本発明の概念を実現するとき、ＯＦＤＭシンボルの示される数はＰＣＦＩＣＨ値に相当する。したがって、この場合、キャリア・インジケータ・フィールドは、下りリンク・リソースがどの下りリンク・コンポーネント・キャリアに割り当てられるかを示し、下りリンク・コンポーネント・キャリア上の割り当てられるサブフレームのＰＣＦＩＣＨ値をさらに示す。

さらに、有利なことに、たとえばＨＡＲＱのような、冗長／ソフト合成(redundancy/softcombining)を使用する再送プロトコルを使用してデータが送信／受信されるコンポーネント・キャリア・アグリゲーションを使用する通信システムにおいて本発明を使用できることに留意されたい。

本発明はさらに、本明細書に記載された本発明の様々な実施態様の１つによって複数の下りリンク・コンポーネント・キャリアのサブフレーム内の下りリンク・リソースをモバイル端末に割り当てる方法をハードウェアに実装することに関する。これは、モバイル端末、および様々な実施態様の１つによる方法のそれぞれのステップを実行するように適切に構成された、基地局（ｅＮｏｄｅＢ）のようなそれぞれのネットワーク・ノードをプロビジョニングすることを含む。なお、本発明のさらなる実施態様は、下りリンクでコンポーネント・キャリアのアグリゲーションを使用するモバイル通信システムにおいて使用され、複数の下りリンク・コンポーネント・キャリアのうちの１つの下りリンク・コンポーネント・キャリアのサブフレーム内の下りリンク・リソースを割り当てることができるモバイル端末を提供する。このモバイル端末は、１つの下りリンク・コンポーネント・キャリアに関する個別制御チャネル情報を受信する受信機を備える。ここで、下りリンク制御情報フォーマットは、少なくとも以下のうちの一つを含む。

- １つの下りリンク・コンポーネント・キャリアのサブフレーム内の割り当てられる下りリンク・リソースを示すリソース割り当てフィールド
- 下りリンク・リソースがどのコンポーネント・キャリアに割り当てられるかを示し、制御シグナリングに使用されるコンポーネント・キャリア上の割り当てられるサブフレーム内のＯＦＤＭシンボルの数をさらに示すキャリア・インジケータ・フィールド

受信機は、割り当てられる下りリンク・リソースに関する下りリンク・データを受信するようにさらに構成される。また、受信機は、それぞれのコンポーネント・キャリアのキャリア周波数に個別に同調される複数の受信回路からなってもよい。したがって、個別の回路は、（すべての下りリンク・コンポーネント・キャリアにわたる）サブフレームを受信する際、様々なコンポーネント・キャリアに属するサブフレームのリソースを受信し処理する（たとえば、復号、復号されたデータのＣＲＣ検査など）。

前述のように、下りリンク制御情報のキャリア・インジケータ・フィールドは、キャリア・インジケータ・フィールドのビットによって表すことのできる符号点の少なくとも２つの異なるサブセットを示せばよい。本発明のさらなるより発展した実施態様によるモバイル端末は、下りリンク制御情報によって下りリンク・リソースが割り当てられるコンポーネント・キャリア上のサブフレーム内の制御シグナリングのために使用されるそれぞれの異なる数のＯＦＤＭシンボルに、サブセットのそれぞれの符号点を、複数の異なるマッピングを使用してマッピングするプロセッサを備える。さらに、モバイル端末の受信機は、複数の異なるマッピングを設定する上位層のシグナリングを受信することができる。ここで、各マッピングは、各サブセットの符号点の、割り当てられる下りリンク・コンポーネント・キャリア上の制御シグナリングに使用されるそれぞれの数のＯＦＤＭシンボルへのそれぞれのマッピングを示す。

本発明のより発展した別の実施態様によるモバイル端末は、下りリンク制御情報によって下りリンク・リソースが割り当てられるコンポーネント・キャリア上のサブフレーム内の制御シグナリングのために使用されるそれぞれの異なる数のＯＦＤＭシンボルに、サブセットのそれぞれの符号点を、複数の所定の異なるマッピングのサブセットのうちの１つのマッピングを使用してマッピングするプロセッサを備える。この場合、受信機は、複数の異なるマッピングのサブセットをモバイル端末によって使用されるように設定する上位層の制御シグナリングを受信することができる。

本発明の別の実施態様では、モバイル端末のプロセッサは、下りリンク・コンポーネント・キャリアのサブフレーム内の、モバイル端末に割り当てられるリソース・ブロックを、リソース割り当てフィールドおよび制御シグナリングに使用される割り当てられるサブフレーム内のＯＦＤＭシンボルの数から判定するのに使用される。この場合、受信機は、サブフレームの判定されたリソース・ブロックに関する変調シンボルを受信することを含め、割り当てられる下りリンク・リソースに関する下りリンク・データを受信するように適切に構成される。

本発明のより発展した別の実施態様によるモバイル端末は、受信された変調シンボルを復調して符号化された下りリンク・データを取得する復調器と、符号化された下りリンク・データを復号する復号器とをさらに備える。この場合、変調符号化方式は、下りリンク制御情報のリソース割り当てフィールドによって示される。

本発明の別の実施態様は、モバイル端末のプロセッサによって実行されたときに、複数の下りリンク・コンポーネント・キャリアの１つに関する個別制御チャネル情報をモバイル端末に受信させる命令であって、下りリンク制御情報フォーマットが、下りリンク・コンポーネント・キャリアのサブフレーム内の割り当てられる下りリンク・リソースを示すリソース割り当てフィールドと、下りリンク・リソースがどのコンポーネント・キャリアに割り当てられるかを示し、制御シグナリングに使用されるコンポーネント・キャリア上の割り当てられるサブフレーム内のＯＦＤＭシンボルの数をさらに示すキャリア・インジケータ・フィールドとを含む命令と、割り当てられる下りリンク・リソースに関する下りリンク・データをモバイル端末に受信させる命令とを記憶するコンピュータ可読媒体に関する。

別の実施態様では、コンピュータ可読媒体は、モバイル端末のプロセッサによって実行されたときに、本明細書に記載された本発明の様々な実施態様の１つによって複数の下りリンク・コンポーネント・キャリアのうちの１つの下りリンク・コンポーネント・キャリアのサブフレーム内の下りリンク・リソースを割り当てる方法のステップをモバイル端末に実行させる命令をさらに記憶する。

以下に、本発明について、添付の図および図面を参照してより詳しく説明する。各図における同様な詳細または対応する詳細は、同じ参照符号によって示されている。

３ＧＰＰ ＬＴＥシステムの例示的なアーキテクチャを示す図である。 ３ＧＰＰ ＬＴＥの全体的なＥ−ＵＴＲＡＮアーキテクチャの例示的な概要を示す図である。 ３ＧＰＰ ＬＴＥ（リリース８）向けに定義された下りリンク・コンポーネント・キャリア上の例示的なサブフレーム構造を示す図である。 ３ＧＰＰ ＬＴＥ（リリース８）向けに定義された下りリンク・スロットの例示的な下りリンク・リソース・グリッドを示す図である。 ＬＴＥにおける下りリンク・ベースバンド処理を示す図である。 ３ＧＰＰ ＬＴＥ−Ａモバイル通信ネットワークでのクロス・キャリア・スケジューリングにおけるキャリア・インジケータ・フィールドの使用法を例示する図である。 本発明の一実施形態によるＦＤＤ動作に使用され、かつ３ＧＰＰ ＬＴＥ−Ａモバイル通信ネットワークに使用される例示的なＤＣＩフォーマット１を示す図である。 本発明の例示的な実施形態による下りリンク・キャリア・アグリゲーションおよびクロス・キャリア・スケジューリングを使用するＯＦＤＭベースのモバイル通信システムにおいてモバイル端末が下りリンク送信情報を受信するステップを示すフローチャートである。 本発明の一実施形態による３ＧＰＰ ＬＴＥ−Ａモバイル通信ネットワークでのクロス・キャリア・スケジューリングにおけるキャリア・インジケータ・フィールド（ＣＩＦ）の使用法を例示する図である。 ユーザ端末への送信向けに設定された３つの下りリンク・コンポーネント・キャリアがある、本発明のさらなる実施形態による３ＧＰＰ ＬＴＥ−Ａモバイル通信ネットワークでのクロス・キャリア・スケジューリングにおけるキャリア・インジケータ・フィールド（ＣＩＦ）の使用法を例示する図である。

以下の各パラグラフでは、本発明の様々な実施形態について説明する。例示のためのみに、大部分の実施形態は、上記の「背景技術」において論じられた３ＧＰＰ ＬＴＥ（リリース８）モバイル通信システムおよび３ＧＰＰ ＬＴＥ−Ａ（リリース１０）モバイル通信システムによる直交単一キャリア上りリンク無線アクセス方式に関して概略的に述べられている。有利なことに、たとえば、前述の３ＧＰＰ ＬＴＥ（リリース８）通信システムおよび３ＧＰＰ ＬＴＥ−Ａ（リリース１０）通信システムのようなモバイル通信システムに関連して本発明を使用することができるが、本発明がこの特定の例示的な通信ネットワークでの使用に限定されないことに留意されたい。

上記の「背景技術」の説明は、本明細書において説明する主として３ＧＰＰ ＬＴＥ（リリース８）および３ＧＰＰ ＬＴＥ−Ａ（リリース１０）固有の例示的な実施形態をよりよく理解することを目的としており、モバイル通信ネットワークにおけるプロセスおよび機能の前述の特定の実装例に本発明を限定するものと理解すべきではない。

上記に指摘したように、キャリア・アグリゲーションおよびクロス・キャリア・スケジューリングを使用する場合、割り当てられるコンポーネント・キャリア上の制御シグナリングに使用される１つまたは複数のＯＦＤＭシンボルの数の誤検出が生じると、場合によっては、このコンポーネント・キャリア上のＰＤＣＣＨが失われるだけでなく、ＨＡＲＱバッファが破壊されるおそれもある。

この欠点を解消する１つの可能な方法は、クロス・スケジューリングされるコンポーネント・キャリアの制御スケジューリング領域内でシグナリングされる実際のＰＣＦＩＣＨ値にかかわらず、ユーザ端末によってクロス・スケジューリングされるコンポーネント・キャリアに一定の既知のＰＣＦＩＣＨ値を仮定することである。ｅＮｏｄｅＢは、このユーザ端末の挙動を認識しているので、適切なレート・マッチングおよび物理層マッピングを実行することができ、それによって、データは、ユーザ端末が送信を行うサブフレームの正しいＯＦＤＭシンボル内で送信される。この解決手段の考えられる１つの欠点は、ＰＤＳＣＨリソースが割り当てられるクロス・スケジューリングされるコンポーネント・キャリア上で、リソースが効率的に使用されなくなるため性能が低下することである。さらに、このことは、ｅＮｏｄｅＢがクロス・キャリア・スケジューリングおよび非クロス・キャリア・スケジューリング用の２つの異なるスケジューリング動作をサポートする必要があることを意味する。

上述の問題の考えられる別の解決手段は、ＰＤＣＣＨ内の下りリンク制御情報内で暗黙的なＰＣＦＩＣＨ指示を使用することである。たとえば、ＰＤＣＣＨのＣＲＣフィールドをＰＣＦＩＣＨ固有のユーザ端末識別子（ＵＥ−ＩＤ）によってマスクしてもよく、したがって、各ユーザ端末に様々なＰＣＦＩＣＨ値用の複数のＵＥ−ＩＤを予約する必要がある。このことはもちろん、利用可能なＵＥ ＩＤがかなり少なくなることを意味する。

上述のように、さらなる解決手段は、下りリンク制御情報（ＤＣＩ）によってリソースが割り当てられるコンポーネント・キャリア上のサブフレーム内の制御シグナリングために使用される１つまたは複数のＯＦＤＭシンボルの数を下りリンク制御情報内に明示する方式を提案することである。この場合、クロス・スケジューリングされるコンポーネント・キャリア上の制御シグナリングに使用される１つまたは複数のＯＦＤＭシンボルの数を示す（追加的な）フィールドを下りリンク制御情報に含めることが可能である。

本発明の一態様による別の解決手段は、割り当てられるコンポーネント・キャリア上のサブフレーム内の１つまたは複数のＯＦＤＭシンボルの数を、この情報を他の制御シグナリング情報、たとえばキャリア・インジケータ・フィールドのキャリア指示と一緒に符号化することによって示すことである。コンポーネント・キャリア上の制御シグナリング用の１つまたは複数のＯＦＤＭシンボルの指示が、クロス・スケジューリングされるコンポーネント・キャリアのキャリア指示と一緒に符号化されると仮定するとき、下りリンク制御情報の対応するフィールドを、たとえばジョイント・キャリア指示・ＰＣＦＩＣＨフィールドと呼んでもよい。しかし、説明を簡単にするために、このフィールドを以下ではキャリア・インジケータ・フィールドと呼ぶ。

この改良されたキャリア・インジケータ・フィールドは、下りリンク制御情報の一部であり、（下りリンク制御情報のリソース割り当てフィールドに備えられた）リソース割り当てに関するコンポーネント・キャリアと、下りリンク制御情報、またはより厳密に言えば下りリンク制御情報内のリソース割り当てによって、制御シグナリングに使用されるリソースが、割り当てられるコンポーネント・キャリア上のモバイル端末に割り当てられる、コンポーネント・キャリアのサブフレーム内の１つまたは複数のＯＦＤＭシンボルの数を示すのに使用される。言い換えれば、本発明のこの態様による発明は、キャリア・インジケータ・フィールド内でシグナリングすることのできる符号点の新しい定義または再定義を可能にして、上記に概略的に説明した２種類の情報を示す。このように、クロス・キャリア・スケジューリング・シナリオにおいて回避することのできる下りリンク・システム・スループットの低下と、リソースの誤った利用によるＨＡＲＱバッファ破壊を、さらなる下りリンク・リソース・オーバヘッドなしに避けることができる。

本明細書において論じる本発明のいくつかの実施形態は、下りリンク制御情報の新しいフォーマット（Ｌ１／Ｌ２制御シグナリングまたはＰＤＣＣＨとも呼ばれる）、下りリンク制御情報フォーマットにすでに存在する可能性のあるキャリア・インジケータ・フィールドの意味の新しい定義のプロビジョニングに関する。一実施形態によれば、下りリンクにおいてコンポーネント・キャリアのアグリゲーション（キャリア・アグリゲーション）を使用することができるモバイル通信システムにおいて使用できる下りリンク制御情報フォーマットが設けられる。このような通信システムの一例は３ＧＰＰ ＬＴＥ（リリース１０）であるが、本発明は、そのさらなる発展形態に適用されてもよい。

また、上りリンクにおいてキャリア・アグリゲーションを使用するモバイル通信システムにおける上りリンク・データ送信にも本発明の原則を使用できることにも留意されたい。この場合、それにもかかわらず、下りリンク制御情報を下りリンクにおいて所与のコンポーネント・キャリア上のモバイル端末にシグナリングすることができるが、下りリンク制御情報に含まれるリソース割り当ては、１つまたは複数の上りリンク・コンポーネント・キャリアのうちの１つの上りリンク・コンポーネント・キャリア上の上りリンク・リソースを示し、一方、キャリア・インジケータ・フィールドは、上りリンク・リソースが有効である上りリンク・コンポーネント・キャリアを示し、リソース割り当てに応じて上りリンク・データが送信されるサブフレームにおける制御シグナリングに使用すべき１つまたは複数のＯＦＤＭシンボルの数をさらに示す。

以下に説明する例示的な実施形態では、下りリンク送信（または上りリンク送信）用のリソース割り当てが下りリンク制御情報フォーマットのリソース割り当てフィールドに含められると仮定される。このリソース割り当てフィールドは、下りリンク（上りリンク）における１つのコンポーネント・キャリアのサブフレーム内の割り当てられる下りリンク（または上りリンク）・リソースをモバイル端末に示す。また、下りリンク制御情報フォーマットは、下りリンク（または上りリンク）リソースがどのコンポーネント・キャリアに割り当てられるかを示し、モバイル端末にリソースが割り当てられるコンポーネント・キャリア上のサブフレーム内の制御シグナリングのために使用されるＯＦＤＭシンボルの数をさらに示すキャリア・インジケータ・フィールドも含む。

本発明の一実施形態によるＦＤＤ動作に使用され、かつ３ＧＰＰ ＬＴＥ−Ａモバイル通信ネットワークに使用される例示的なＤＣＩフォーマット１が図７に示されている（図を簡単にするために、ＣＲＣフィールドが示されていないことに留意されたい）。図７に示されているように、これらの例示的なフォーマットの下りリンク制御情報は、以下のものを含む。

- キャリア・インジケータ・フィールド（ＣＩＦ）：これは、リソースにどのコンポーネント・キャリアが割り当てられるかを示すものであり、下りリンク制御情報によってリソースが割り当てられるコンポーネント・キャリア上のサブフレーム内の制御シグナリングのために使用されるＯＦＤＭシンボルの数をさらに示すものである。

- リソース割り当てヘッダ（ＲＡ）：これは、リソース割り当てタイプ（タイプ０またはタイプ１）を示すものである（リソースが割り当てられるコンポーネント・キャリアの下りリンク帯域幅が１０物理リソース・ブロック以下である場合、このヘッダを省略してもよく、リソース割り当てタイプ０が仮定されることに留意されたい）

- リソース・ブロック割り当て（ＲＢＡ）フィールド：これは、所与のリソース割り当てタイプに応じてＰＤＳＣＨ上の下りリンク・リソース（リソース・ブロック）をユーザ端末に割り当てるものである（ＲＢＡフィールドに必要なビット数は、割り当てタイプ（ＲＡフィールド）と割り当てられるコンポーネント・キャリアの帯域幅によって決まる）

- 変調符号化方式フィールド（ＭＣＳ）：これは、ＰＤＳＣＨ上の割り当てられるリソース上での送信に関する変調方式、符号化率、および冗長バージョンを示すものである。

- ＨＡＲＱプロセス番号：これは、割り当てられるリソース上の下りリンク送信に使用すべきＨＡＲＱプロセスを示すものである。

- 新規データ・インジケータ（ＮＤＩ）：これは、所与のＨＡＲＱプロセス上の送信が新しいプロトコル・データ・ユニット（ＰＤＵ）であることを示すものである。

- 冗長バージョン（ＲＶ）・フィールド：これは、割り当てられるリソース上の下りリンク送信の冗長バージョンを示すものである。

- 送信電力制御（ＴＰＣ）コマンド・フィールド：これは、ＰＵＣＣＨ上で制御情報を送信するためのものである。

図６にさらに示されているように、フィールドＲＡ、ＲＢＡ、ＭＣＳ、ＮＤＩ、およびＲＶは、上述のリソース割り当てフィールドの実装例である。

本発明は、図７に示されているような拡張ＤＣＩフォーマット１に限定されないが、たとえば、ｈｔｔｐ：／／ｗｗｗ．３ｇｐｐ．ｏｒｇにおいて入手可能であり、参照によって本明細書に組み込まれる３ＧＰＰ ＴＳ ３６．２１２「Ｅｖｏｌｖｅｄ Ｕｎｉｖｅｒｓａｌ Ｔｅｒｒｅｓｔｒｉａｌ Ｒａｄｉｏ Ａｃｃｓｅｅ（Ｅ−ＵＴＲＡ）；Ｍｕｌｔｉｐｌｅｘｉｎｇ ａｎｄ ｃｈａｎｎｅｌ ｃｏｄｉｎｇ （Ｒｅｌｅａｓｅ ８）」、バージョン８．７．０、第５．３．３．１節（非特許文献５）で知られている他のＤＣＩフォーマット（たとえば、３ＧＰＰ ＴＳ ３６．２１２において定義されたフォーマット１Ａ〜１Ｄ、２Ａ、および２Ｂ）にＣＩＦを追加してもよいことに留意されたい。また、このような拡張ＤＣＩフォーマットの場合、ＣＩＦフィールドでは、リソースがどのコンポーネント・キャリアに割り当てられるかの指示と、下りリンク制御情報によってリソースが割り当てられるコンポーネント・キャリア上のサブフレーム内の制御シグナリングのために使用されるＯＦＤＭシンボルの数の指示を一緒に符号化してもよい。

また、本発明の原則は、たとえばキャリア・インジケータ・フィールドおよびリソース割り当てフィールドしか含めない（任意に、モバイル端末においてこの２つのフィールドの復号が正しいことを検証するのを可能にするＣＲＣフィールドを含む）他の個別制御チャネルに適用してもよい。

ＤＣＩフォーマットにおけるＣＩＦフィールドの位置に関しては、一例として、ＣＩＦフィールドはＤＣＩフォーマットの第１のフィールドである。しかし、例示的な別の実装例では、ＣＩＦフィールドは、ＤＣＩフォーマットにおける別の固定位置に配置され、したがって、モバイル端末（ユーザ端末）はＤＣＩフォーマット内のＣＩＦフィールドの位置を認識する。

本明細書において定義されるフォーマットに従った下りリンク制御情報を受信するモバイル端末の動作について以下に図８を参照して説明する。図８は、モバイル端末が、本発明の例示的な実施形態による下りリンク・キャリア・アグリゲーションおよびクロス・キャリア・スケジューリングを使用するＯＦＤＭベースのモバイル通信システムにおいて下りリンク送信情報を受信するステップを示すフローチャートを示している。さらなる詳細については、基地局（ｅＮｏｄｅＢ）からモバイル端末（ユーザ端末）によって受信される例示的な２つのサブフレームおよびその構造を示す図９も参照されたい。

モバイル端末はまず、システム内に設定された下りリンク・コンポーネント・キャリア（コンポーネント・キャリアＡおよびＢ）を介して送信されたサブフレーム９０１を受信し（８０１）、コンポーネント・キャリアＡで受信されたサブフレーム内の制御シグナリングのために使用される１つまたは複数のＯＦＤＭシンボルの数を、第１のコンポーネント・キャリア（コンポーネント・キャリアＡ）で受信されたサブフレームから判定する（８０２）。サブフレームが、モバイル端末のすべての設定済みコンポーネント・キャリアを介して延びているが、モバイル端末が、サブフレームの、様々なコンポーネント・キャリアに属する部分を受信して処理する（たとえば、復号、復号されたデータのＣＲＣ検査などを行う）独立の受信機回路を備えてもよいことに留意されたい。コンポーネント・キャリアＡで受信されたサブフレーム９０１内の制御シグナリングのために使用される１つまたは複数のＯＦＤＭシンボルの数を示す制御情報はたとえば、位置が固定されモバイル端末に知られている１つまたは複数の時間−周波数リソース内でシグナリングされてもよい。

３ＧＰＰベースのシステムでは、サブフレーム内の制御シグナリングのために使用される１つまたは複数のＯＦＤＭシンボルのこの数を、コンポーネント・キャリアＡの制御シグナリング領域９０５内でシグナリングされる、ＰＣＦＩＣＨ値９０６と呼ぶ。たとえば、ＰＣＦＩＣＨは、制御シグナリング領域９０５内のサブフレームの既知のリソース要素（図３および図４参照）上でシグナリングされる。

したがって、モバイル端末は、コンポーネント・キャリアＡで受信されたサブフレーム９０１内の制御シグナリングに使用される１つまたは複数のＯＦＤＭシンボルの数の知識に基づいて、モバイル端末の制御シグナリングを含む制御シグナリング領域９０５を形成するコンポーネント・キャリアＡで受信されたサブフレーム９０１内の１つまたは複数のＯＦＤＭシンボルを認識し、そこにモバイル端末のリソース割り当てが含まれているかどうかを判定する。図８では、制御シグナリング領域９０５が、クロス・スケジューリングされるコンポーネント・キャリア（コンポーネント・キャリアＢ）上のモバイル端末のリソース割り当て（リソース指示９０２）を含む下りリンク制御情報を含むと仮定する。モバイル端末は、コンポーネント・キャリアＡで受信されたサブフレーム９０１から下りリンク制御情報９０７（３ＧＰＰ用語ではＰＤＣＣＨまたはＬ１／Ｌ２制御シグナリングと呼ばれる）を復号し（８０３）、下りリンク制御情報９０７を取得する。３ＧＰＰベースのシステムでは、モバイル端末によって取得された下りリンク制御情報はたとえば、図７に示されているフォーマットを有してもよい。

モバイル端末は次に、コンポーネント・キャリアＡで受信された下りリンク制御情報９０７のキャリア・インジケータ・フィールド９０８から、下りリンク制御情報によってリソースが割り当てられるクロス・スケジューリングされるコンポーネント・キャリアＢへのポインタ（キャリア指示９０３）と、コンポーネント・キャリアＢで受信されたサブフレーム内の制御シグナリングに使用される１つまたは複数のＯＦＤＭシンボルの数（すなわち、コンポーネント・キャリアＢで受信されたサブフレーム９０１のＰＣＦＩＣＨ値９０４）を判定する（８０４）。前述のように、下りリンク制御情報９０７のキャリア・インジケータ・フィールド９０８は２種類の情報を一緒に符号化する。

モバイル端末は、コンポーネント・キャリアＢで受信されたサブフレーム内の制御シグナリングに使用される１つまたは複数のＯＦＤＭシンボルの数（すなわち、コンポーネント・キャリアＢで受信されたサブフレームのＰＣＦＩＣＨ値）を認識し、同じくコンポーネント・キャリアＡで受信された下りリンク制御情報９０７に備えられたリソース割り当てフィールドからコンポーネント・キャリアＢ上の割り当てられる下りリンク・リソース９０９を判定することができる。

たとえば、ＬＴＥ−Ａ（リリース１０）のような３ＧＰＰベースのシステムを考えると、リソース・ブロック割り当て（図６のＲＡフィールドおよびＲＢＡフィールドを参照されたい）は通常、図３および図４に関して例示したようなサブフレームの時間−周波数グリッド内の割り当てられるリソース・ブロックのインデックスを示す。ユーザ端末は、割り当ての時間−周波数リソースに関して、割り当てが、時間領域において、割り当てられるコンポーネント・キャリア上のサブフレーム内の制御シグナリングに使用されないすべてのＯＦＤＭシンボルに及び、したがって、ＲＢＡフィールドが基本的に、コンポーネント・キャリア上に割り当てられる周波数領域・リソース（すなわち、割り当てられるリソース・ブロックのサブキャリア）を示すと仮定することができる。割り当ての時間領域・リソースは、リソースがユーザ端末に割り当てられるコンポーネント・キャリアで受信されたサブフレーム内の制御シグナリングに使用される１つまたは複数のＯＦＤＭシンボルによって決まるので、ＰＤＳＣＨデータの送信を行う割り当てられるリソース・ブロックのリソース要素を判定するには、このコンポーネント・キャリアのＰＣＦＩＣＨ値の知識が重要である。リソースが割り当てられるコンポーネント・キャリア上のサブフレーム内の制御シグナリングに使用される１つまたは複数のＯＦＤＭシンボルの数が下りリンク制御情報（通常、ＣＲＣによって完全性が保護される）内でシグナリングされるので、モバイル端末は確実に、クロス・キャリア・スケジューリング・シナリオにおいて正しいＰＣＦＩＣＨ値を検討することができる。

したがって、モバイル端末は、下りリンク制御情報から下りリンク・リソースを判定すると、クロス・スケジューリングされるコンポーネント・キャリアＢで受信されたサブフレーム内の判定された下りリンク・リソースに関するデータを復号できる（８０６）。

上記に図８に関して示した例における下りリンク・データの送信を、冗長／ソフト合成を実現する再送プロトコルを使用して行ってもよいことに留意されたい。たとえば、この目的のためにＨＡＲＱプロトコルを使用してもよい。上述のようにモバイル端末に割り当てられるＰＤＳＣＨリソースから取得された下りリンク・データは通常、ＭＡＣプロトコル・データ・ユニット（ＰＤＵ）である。冗長／ソフト合成を実現する再送プロトコルを使用すると、モバイル端末の復号器において首尾よく復号されなかった（ステップ８０６参照）ＭＡＣ ＰＤＵは、モバイル端末によって削除されず、後で正しくないＭＡＣ ＰＤＵの１回または複数回の再送とソフト合成できるようにモバイル端末に設けられたメモリ内のソフト・バッファ領域に記憶され、したがって、復号器は、結合されたＰＤＵデータに対して復号を実行することができる（結合ゲインを使用することができる）。ＨＡＲＱプロトコルを使用することを考慮して、図８に示されているフローチャートは、図７に示されているように、ステップ８０３とステップ８０６の間に、ＨＡＲＱプロセス番号および新規データ・インジケータ（ＮＤＩ）を判定するステップをさらに含む。

ＮＤＩが所与のＨＡＲＱプロセスに関する前の送信に対して切り替えられた場合、このことは、この送信が新しいＰＤＵを含むことを意味し、モバイル端末は、図８に示されているようにステップ８０４、ステップ８０５、およびステップ８０６を実行してもよい。モバイル端末は、ステップ８０６において送信データを復号した後、データが首尾よく復号されたかどうか（このことは、たとえば各ＰＤＵに含まれるＣＲＣフィールドに基づくＣＲＣ検査によって確認してもよい）をさらに検査し、首尾よく復号された場合、モバイル端末の送信機は、肯定応答（ＡＣＫ）を基地局に送信する。データが首尾よく復号されなかった場合、モバイル端末は、ＨＡＲＱプロセスに関連するソフト・バッファ領域をフラッシュした後このソフト・バッファ領域に受信されたデータを記憶してもよい。

ＮＤＩが所与のＨＡＲＱプロセスに関する前の送信に対して切り替えられない場合、このことは、現在処理されているサブフレーム内の送信が、事前に送信されたＰＤＵの再送を含まないことを意味する。この場合、コンポーネント・キャリアＢで受信されたサブフレームの判定された割り当てられる下りリンク・リソースに関するデータが、ステップ８０６においてモバイル端末の復号器が結果として得られたデータを復号する前にＨＡＲＱプロセスに関連するソフト・バッファ領域に記憶されているデータとソフト合成される。

また、復号ステップの後、モバイル端末は、結果として結合されたデータが首尾よく復号されたかどうかをさらに検査する。これは、たとえばＣＲＣ検査によって実現される。データが首尾よく復号されていない場合、結果として結合されたデータは、ＰＤＵの以後の再送と結合されるように、ＨＡＲＱプロセスに関連するソフト・バッファ領域に記憶される。結果として結合されたデータが首尾よく復号された場合、モバイル端末は基地局に肯定応答（ＡＣＫ）を送信する。

以下に、上述の態様および概念による方式の実装例を、３つの下りリンク・コンポーネント・キャリアが設定された３ＧＰＰ ＬＴＥ−Ａ（リリース１０）システムに関して示す。また、例示のためのみに、（ＰＤＣＣＨの一部としての）ＤＣＩ内の下りリンク割り当てがユーザ端末に受信リソースを示すコンポーネント・キャリア上でシグナリングされるこれらの下りリンク割り当てが、３ＧＰＰ ＬＴＥ（リリース８）を使用し、すなわち、ＤＣＩに備えられた割り当てにはキャリア・インジケータ・フィールドがないと仮定する。クロス・キャリア・スケジューリングの場合、すなわち、ＰＤＣＣＨ（ＤＣＩを含む）がリソースを割り当てるコンポーネント・キャリアとは異なるコンポーネント・キャリア上でＰＤＣＣＨがシグナリングされる場合、リソースが割り当てられるコンポーネント・キャリアおよびこのコンポーネント・キャリアのＰＣＦＩＣＨ値を示すキャリア・インジケータ・フィールド（ＣＩＦ）を含む拡張ＤＣＩフォーマットが使用される。このような拡張ＤＣＩフォーマットの例が図７に示されている。

図１０は、３ＧＰＰ ＬＴＥ−Ａモバイル通信ネットワークでのこの例示的なクロス・キャリア・スケジューリングにおけるキャリア・インジケータ・フィールドの使用法を例示している。図９のように、コンポーネント・キャリアＡが、すべての３つのコンポーネント・キャリアＡ、Ｂ、およびＣに関するリソース割り当てを含むＰＤＣＣＨを伝送すると仮定する。上記に図８および図に関して説明したように、ユーザ端末は、コンポーネント・キャリアＡ上のＰＣＦＩＣＨ１００３を検出し、コンポーネント・キャリアＡの制御シグナリング領域１００２内のＰＤＣＣＨを復号する。ＰＤＣＣＨ１００５は、コンポーネント・キャリアＡ上にリソースを割り当て、３ＧＰＰ ＬＴＥ−Ａ（リリース８）フォーマットを有する（各矢印は、図６および図９と同様に、それぞれのＰＤＣＣＨがリソースを割り当てるコンポーネント・キャリアと割り当てられるリソースを示す）。それぞれコンポーネント・キャリアＢおよびＣ上でリソース１００７を割り当てる（クロス・スケジューリング）さらに２つのＰＤＣＣＨ１００４が、コンポーネント・キャリアＡの制御シグナリング領域１００２に存在する。この２つのＰＤＣＣＨ１００４は、拡張ＤＣＩフォーマットを有し、クロス・スケジューリングされるコンポーネント・キャリアおよびそのＰＣＦＩＣＨ値を示すＣＩＦフィールドを含む。この例示的な実施形態では、キャリア指示およびＰＣＦＩＣＨ指示へのＣＩＦ値（符号点）のマッピングは、以下の表３に示されているように定義される。

したがって、図１０に示されている例では、コンポーネント・キャリアＢ上にリソースを割り当てるＰＤＣＣＨのＤＣＩのＣＩＦフィールドは符号語「０１０」を示し、コンポーネント・キャリアＣ上にリソースを割り当てるＰＤＣＣＨのＤＣＩのＣＩＦフィールドは符号語「１０１」を示している。上記に図８および図９に関して説明したように、ユーザ端末は、それぞれのＰＤＣＣＨ内のＤＣＩから取得されたクロス・スケジューリングされるコンポーネント・キャリアの示されたフィードバック値１００６を使用して、クロス・スケジューリングされるコンポーネント・キャリア上の割り当てられるリソース１００７を判定し、正しいリソースに関するデータを受信（または送信）してもよい。

上記に図１０および表３に関して概略的に説明した例示的なシナリオでは、指示すべきＰＣＦＩＣＨ値範囲が［１，２，３，４］であり、かつクロス・スケジューリングのＰＤＣＣＨは、ＰＤＣＣＨが送信されるコンポーネント・キャリアを示す必要がない（通常指示できない）と仮定したが、前述のように、ＰＤＣＣＨがシグナリングされる下りリンク・コンポーネント・キャリア上（またはこの下りリンク・コンポーネント・キャリアにリンクされた上りリンク・コンポーネント・キャリア上）にＰＤＣＣＨがリソースを割り当てる場合、ＣＩＦフィールドを有さない３ＧＰＰ ＬＴＥ（リリース８）フォーマットが使用される。したがって、図示の例のように、ＣＩＦフィールドのサイズが３ビットである場合、ＣＩＦフィールドには８つの符号点があり、これに一致する数の、４つのＰＣＦＩＣＨ値と２つのクロス「スケジューリング可能な」コンポーネント・キャリアとの組み合わせ、すなわち、ＰＣＦＩＣＨ値とコンポーネント・キャリア指示の８つの組み合わせがある。

明らかに、アグリゲートされるコンポーネント・キャリアの数とＰＣＦＩＣＨ値範囲の現在可能なあらゆる設定を、ＤＣＩのＣＩＦフィールド内でシグナリングできる所与の数の符号点によってシグナリングできるわけではない。サブフレームが、制御シグナリングに使用される０個からＮ_ｍａｘ個のＯＦＤＭシンボルを有する（すなわち、コンポーネント・キャリア用の考えられるＮ_ｍａｘ＋１個の異なるＰＣＦＩＣＨ値がある）一般的なケースを考える。また、クロス・スケジューリングされるコンポーネント・キャリアを識別するために、ＣＩＦフィールド内に示す必要があるＣ_ＣＳ個のコンポーネント・キャリアがあると仮定することができる。したがって、コンポーネント・キャリアとＰＣＦＩＣＨ値のＣ_ＣＳ・（Ｎ_ｍａｘ＋１）個の可能な組み合わせがあり、この数は２^Ｌよりも大きくてもよく、Ｌはサイズ、すなわちＣＩＦフィールドのビット数である。

たとえば、５つのコンポーネント・キャリアＡ、Ｂ、Ｃ、Ｄ、およびＥがあり、また、クロス・キャリア割り当てを有するＰＤＣＣＨが、たとえばコンポーネント・キャリアＡ上でシグナリングされる場合、コンポーネント・キャリアＢ、Ｃ、Ｄ、およびＥ（Ｃ_ＣＳ＝４）を識別する必要があり、かつ考えられる４つの異なるＰＣＦＩＣＨがある。それゆえ、３ビットＣＩＦフィールドを使用してすべての組み合わせをシグナリングできるわけではない。したがって、本発明のさらなるより発展した実施形態では、ＰＣＦＩＣＨ値範囲［０，．．．，Ｎ_ｍａｘ］（すなわち、制御シグナリングに使用されるＯＦＤＭシンボルの数の範囲）は、すべてのＣ_ＣＳを明確に識別する必要があるので、制御シグナリングに使用できるＯＦＤＭシンボルの数の全範囲のサブセットのみをカバーする。

本発明の別の実施形態による、ＣＩＦ符号点の、キャリア指示およびＰＣＦＩＣＨ値への例示的なマッピングが、以下の表４に示されている。

この例示的なマッピングを見るとわかるように、ｅＮｏｄｅＢにおけるスケジューラは、すべての４つのコンポーネント・キャリアＢ、Ｃ、Ｄ、およびＥ上でリソースをクロス・スケジューリングすることができる。しかし、それぞれのクロス・スケジューリングされるキャリアに使用できるＰＣＦＩＣＨ値には制限がある。この場合も、ＤＬ ＤＣＩ（下りリンク・リソース割り当て）を含むＰＤＣＣＨがコンポーネント・キャリアＡ上でシグナリングされると仮定する。他のコンポーネント・キャリアＢ、Ｃ、Ｄ、およびＥについては、ＣＩＦフィールドのＰＣＦＩＣＨ値は１および２である。

また、上述の例および後述の例（の大部分）では、ＤＣＩを含むＰＤＣＣＨが受信されるコンポーネント・キャリア上のリソース割り当てに関して予約される符号点はない（たとえば、非クロス・キャリア・スケジューリング割り当てにはＤＣＩ用の３ＧＰＰ ＬＴＥ（リリース８）フォーマットが使用される）が、ＣＩＦフィールドに非クロス・キャリア・スケジューリング割り当ても示されるケースにこれらの例を拡張してもよい。表６を参照されたい。この場合、下りリンク・コンポーネント・キャリア上で受信されたＰＤＣＣＨ（ＤＣＩ内のリソース割り当て）が同じ下りリンク・コンポーネント・キャリア上にリソースを割り当てる場合、この下りリンク・コンポーネント・キャリアのＰＣＦＩＣＨ値はユーザ端末によってすでに正しく検出されている。なぜなら、そうでない場合、ＤＣＩを正しく復号することができないからである。したがって、この非クロス・キャリア・スケジューリングをＤＣＩのＣＩＦフィールドに示す場合、リソース割り当てを含むＤＣＩが、ＤＣＩ（またはより正確には、ＤＣＩを含むＰＤＣＣＨ）が受信された下りリンク・コンポーネント・キャリアに関係することを示す１つの符号点のみを予約する必要がある。

コンポーネント・キャリア指示およびＰＣＦＩＣＨ値のシグナリングを、この２つのパラメータのすべての組み合わせをＣＩＦフィールド内でシグナリングできるとは限らないシナリオにおいてより柔軟に行うには、様々なマッピングを定義し、ユーザ端末によって使用すればよい。上記の表４に示されている例を考えると、キャリア・インジケータ・フィールドの符号点を、各々がそれぞれのＰＣＦＩＣＨ値を生成する２つのサブセットに分割してもよい。さらなる一実施形態では、あるサブセットに属する符号点のそれぞれの異なるＰＣＦＩＣＨ値を示す様々なマッピングが定義される。たとえば、ユーザ端末によってキャリア・インジケータ・フィールドの解釈に使用されたときに、第１のサブセット｛０００，００１，０１０，０１１｝に属する符号点が、下りリンク制御情報によってリソースが割り当てられるコンポーネント・キャリア上でＰＣＦＩＣＨ値ｎ_１∈［０，．．．，Ｎ_ｍａｘ］を生成し、一方、第２のサブセット｛１００，１０１，１１０，１１１｝の符号点が、下りリンク制御情報によってリソースが割り当てられるコンポーネント・キャリア上でＰＣＦＩＣＨ値ｎ_２∈［０，．．．，Ｎ_ｍａｘ］を生成することを意味する第１のマッピングＭ_１が存在してもよい。ユーザ端末が別の第２のマッピングＭ_２を使用する場合、モバイル端末は、第１のサブセット｛０００，００１，０１０，０１１｝に属する符号点が、下りリンク制御情報によってリソースが割り当てられるコンポーネント・キャリア上のサブフレーム内にｎ_３∈［０，．．．，Ｎ_ｍａｘ］個のＯＦＤＭシンボルを生成し、一方、第２のサブセット｛１００，１０１，１１０，１１１｝の符号点が、下りリンク制御情報によってリソースが割り当てられるコンポーネント・キャリア上のサブフレーム内にｎ_４∈［０，．．．，Ｎ_ｍａｘ］個のＯＦＤＭシンボルを生成すると解釈する。ｎ_２がｎ_３に等しくてもよい（ただし、必ずしもそうである必要はない）ことに留意されたい。理論上、キャリア・インジケータ・フィールドによって、所与の数Ｓのサブセットについて、数（ｎ_ｉ，ｎ_ｋ）（ｎ_ｉ，ｎ_ｋ∈［０，．．．，Ｎ_ｍａｘ］）のすべての組み合わせを示すことができるようにすべきである場合、

個の異なるマッピング（可能なマッピング）を定義する必要がある。しかし、たとえば、以下に詳しく説明するように、ＰＣＦＩＣＨ値によっては所与のコンポーネント・キャリアにとって必要でないものもあるので、制御シグナリングに使用されるＯＦＤＭシンボルの数（ｎ_ｉ，ｎ_ｋ）のすべての可能な組み合わせをシグナリングする必要があるわけではない。

４つの下りリンク・コンポーネント・キャリアＢ、Ｃ、Ｄ、およびＥがクロス・スケジューリングされるキャリアとして示され、また、ＰＤＣＣＨがコンポーネント・キャリアＡ上でシグナリングされると仮定される例の場合に、様々なマッピングがどのようになるかに関する例が表５に示されている。

表５の例では、様々なマッピングにおいて示されるＰＣＦＩＣＨ値のみが異なることに留意されたい。

別の例では、２つよりも多くのサブセットが定義されてもよく、たとえば、３つまたは４つのサブセットがあってもよい。サブセットの数はたとえば、示す必要のあるコンポーネント・キャリアの数およびＣＩＦフィールドのサイズによって決まる。たとえば、ＣＩＦフィールドが所与のサイズ２^Ｌを有し、指示すべきコンポーネント・キャリアがＣ_ＣＳ個ある場合、

個のフル・サブセットを定義すればよい。フル・サブセットとは、各サブセットが、様々なコンポーネント・キャリアを識別するＣ_ＣＳ個の符号点を有することを意味する。同様に、

個の不完全なサブセットを設定してもよい。関数

および関数

はそれぞれ、実数値の次に小さい整数および次に大きい整数を与え、たとえば

および

である。

すでに指摘したように、利用可能なＰＣＦＩＣＨ値のある部分範囲が所与のコンポーネント・キャリアのみに当てはまることを示す可能性のあるいくつかの因子があると考えられ、したがって、クロス・スケジューリングすることのできるそれぞれのコンポーネント・キャリアに関してシグナリングする必要のあるＰＣＦＩＣＨ値の数を限定することができる。例示的な一実施形態では、それぞれの使用シナリオについて定義された様々なマッピングがあり、ＣＩＦの解釈は、適用可能な使用シナリオによって決まり、すなわち、ユーザ端末は適用可能な使用シナリオに対応するマッピングを使用してＤＣＩのＣＩＦフィールドを解釈する。使用シナリオはたとえば、ｅＮｏｄｅＢからユーザ端末へのマッピング選択メッセージ内でシグナリングされてもよい。たとえば、キャリア・インジケータ・フィールドの使用シナリオまたは解釈、すなわち、各フィールドの符号点の、それらの意味へのマッピングは、以下のうちの少なくとも１つによって決まるものであってもよい。

- 割り当てられる下りリンク・コンポーネント・キャリア上の干渉条件および電力レベル、
- 割り当てられる下りリンク・コンポーネント・キャリア上のチャネル品質、
- 割り当てられる下りリンク・コンポーネント・キャリアの帯域幅、
- 下りリンク・コンポーネント・キャリアの負荷分散関数のステータス、
- 割り当てられる下りリンク・コンポーネント・キャリアの種類、
- 下りリンク制御情報が送信されるコンポーネント・キャリア上の制御シグナリングに使用されるＯＦＤＭシンボルの数、および
- 割り当てられるコンポーネント・キャリア上でシグナリングすべき上りリンクＡＣＫ／ＮＡＣＫの数

以下に、例示的ないくつかの使用シナリオを詳しく説明する。

シナリオ１：ＨｅｔＮｅｔ／ホット・スポット・シナリオ
この例では、弱い干渉しか受けない（高電力条件）下りリンク・コンポーネント・キャリアが１つあり、かつ干渉が強いために低電力条件にあるさらなるコンポーネント・キャリアが下りリンクに存在すると仮定する。ｅＮｏｄｅＢからユーザ端末へのＤＣＩを含むＰＤＣＣＨは極めて信頼性の高いものであるべきであると仮定してもよい。信頼性の低いＰＤＣＣＨでは、制御シグナリング・リソースと大量のデータ・リソースの両方が無駄になり、さらに、下りリンク・シグナリング・オーバヘッドが著しく増大する。したがって、ｅＮｏｄｅＢは通常、受信電力が高く、すなわち干渉が弱いコンポーネント・キャリア上で１つまたは複数のＰＤＣＣＨを送信する。このことは、低電力コンポーネント・キャリア上で送信されるＰＤＣＣＨがほとんどない（場合によってはまったくない）場合があることを意味する。それにもかかわらず、ＰＤＳＣＨに関するデータをこのような低い電力で、すなわち干渉の強いコンポーネント・キャリア上で送信してもよい。これは、適応変調符号化（ＡＭＣ）を使用する場合、データの符号化方式／トランスポート・ブロック・サイズをチャネル条件に適合させることができ、さらにＨＡＲＱプロセスを使用することもできるからである。

したがって、これらの「低電力コンポーネント・キャリア」の場合（低電力コンポーネント・キャリアは、コンポーネント・キャリア上のチャネル品質がしきい値よりも低く、かつ／あるいはコンポーネント・キャリア上の干渉レベルが所与のしきい値よりも高い）、サブフレーム内の制御シグナリング領域が小さくなることがあり、そのため、ＰＣＦＩＣＨ値が小さくなる。したがって、ＰＣＦＩＣＨ値は、これらの低電力コンポーネント・キャリアの場合１または２のいずれかであり（または場合によっては０であり、すなわち、低電力コンポーネント・キャリア上には制御シグナリング領域がない）、すなわち、これらの低電力コンポーネント・キャリア上でリソースがクロス・スケジューリングされる場合、ＰＣＦＩＣＨ値の３および４をサポートする必要がなく、したがって、ＣＩＦフィールドによって示す必要がない場合がある。したがって、４つのコンポーネント・キャリアのクロス・キャリア指示用の３ビットＣＩＦフィールドをサポートすればよい（４・２＝８＝２^３）。基本的に、表４は、この使用シナリオの例示的なマッピングを生成する。

本発明のさらなる実施形態では、たとえば、ＣＩＦフィールドがすべてのＤＣＩフォーマットで存在する場合に、すなわち、ＤＣＩが受信される下りリンク・コンポーネント・キャリア上でＤＣＩがリソースを割り当てる場合にも、非クロス・キャリア・スケジューリング用のＣＩＦ符号点が予約される。したがって、この例では、下りリンクにおいて３ビットのＣＩＦフィールドおよび合計で５つのコンポーネント・キャリアを仮定すると、クロス・キャリア指示用の７つの符号点が利用可能である。この場合、たとえばクロス・スケジューリングできる４つのコンポーネント・キャリアのうちの１つのコンポーネント・キャリアについて、単一のＰＣＦＩＣＨ値を定義すればよい。例示的なマッピングを表６に示す。

さらなる例示的な実施形態では、同じく５つの下りリンク・コンポーネント・キャリアが利用可能であってもよい。これらのコンポーネント・キャリアのうちの２つは、高電力コンポーネント・キャリアであり（高電力コンポーネント・キャリアは、コンポーネント・キャリア上のチャネル品質がしきい値以上であり、かつ／あるいはコンポーネント・キャリア上の干渉レベルが所与のしきい値以下である）、したがって、ＤＣＩ（リソース割り当て）を含むＰＤＣＣＨはこの２つのコンポーネント・キャリアＡおよびＢ上でシグナリングされる。したがって、この場合、ＣＩＦ符号点は、コンポーネント・キャリアＣ、Ｄ、およびＥのみのクロス・キャリア・スケジューリングに関する複数のＰＣＦＩＣＨ値を示せばよい。これは、コンポーネント・キャリアＡとコンポーネント・キャリアＢとのクロス・キャリア・リソース割り当てが使用されず、リソースを割り当てるべきであるコンポーネント・キャリアＡまたはＢ上でそれぞれのＰＤＣＣＨを送信すればよいからである。このシナリオの例示的な２つのマッピングが表７および表８に示されている。表７は、ＣＩＦに非クロス・キャリア・スケジューリングも示される例を示している。

表８は、ＣＩＦに非クロス・キャリア・スケジューリングが示されず、すなわちクロス・キャリア・スケジューリングのみが示され、かつそれぞれのコンポーネント・キャリア上にリソースを割り当てる際、コンポーネント・キャリアＡおよびＢ上のリソース割り当てに３ＧＰＰ ＬＴＥ（リリース８）フォーマットのＤＣＩが使用される例を示している。

シナリオ２：狭帯域幅を含む後方互換性コンポーネント・キャリア
現在の３ＧＰＰ ＬＴＥ（リリース８）システムでは、ＰＣＦＩＣＨ値の４は狭帯域幅（たとえば、しきい値数のリソース・ブロックまたはしきい値帯域幅−たとえば、１．６ＭＨｚの帯域幅と同等の１０個のリソース・ブロック）にのみ使用されている。これは、狭帯域幅しか有さないＬＴＥシステムでは、ＯＦＤＭシンボル当たりＲＥＧ(ＣＣＥ)数が少なく、したがって、広帯域幅システムと比べてＯＦＤＭシンボル単位のサブフレーム内の制御シグナリング領域が広くなる（通常最大ＰＣＦＩＣＨ値の３を有する）からである。

狭帯域幅コンポーネント・キャリアでは制御領域が広いので、そのような狭帯域幅コンポーネント・キャリアは、狭帯域幅キャリアがＬＴＥ（リリース８）互換ユーザ端末にのみ使用される３ＧＰＰ ＬＴＥ−Ａ（リリース１０）キャリア・アグリゲーション・シナリオ内で、後方互換性キャリアとして使用されてもよい。このシナリオでは、そのようなＬＴＥ（リリース８）互換ユーザ端末個別のＬ１／Ｌ２制御シグナリング（ＰＤＣＣＨ）は、１つまたは複数の狭帯域幅コンポーネント・キャリアの制御シグナリング領域内で送信され、一方、クロス・キャリア・スケジューリングは、１つまたは複数の狭帯域幅コンポーネント・キャリア上の３ＧＰＰ ＬＴＥ−Ａ（リリース１０）互換ユーザ端末にリソースを割り当てるために３ＧＰＰ ＬＴＥ−Ａ（リリース１０）互換ユーザ端末に使用される。１つまたは複数の狭帯域幅コンポーネント・キャリア上の制御シグナリング領域は通常、利用可能なＣＣＥが少ないので広く、そのため、制御シグナリングにはより多くのＯＦＤＭシンボルが必要である。したがって、この実施形態では、ＣＩＦフィールドのマッピングとして、３ＧＰＰ ＬＴＥ−Ａ（リリース１０）互換ユーザ端末の１つまたは複数の狭帯域幅コンポーネント・キャリア上でリソースがクロス・スケジューリングされるときにＰＣＦＩＣＨ値の３または４のみを生成するようなマッピングを選択すればよい。

シナリオ３：ｅＮｏｄｅＢがすべてのコンポーネント・キャリアにわたって均等にＰＤＣＣＨを分配する。
この例示的な使用シナリオでは、ｅＮｏｄｅＢがシステム内のすべてのコンポーネント・キャリア上で負荷分散を使用し、したがって、下りリンクにおいて利用可能なすべてのコンポーネント・キャリアにわたって１つまたは複数のＰＤＣＣＨが均等にマッピングされる。したがって、このシナリオでは、クロス・スケジューリングを使用するときにＰＤＳＣＨコンポーネント・キャリアに関して示すべきＰＣＦＩＣＨ値は、対応するクロス・スケジューリング・リソース割り当てを含むＰＤＣＣＨを伝送するコンポーネント・キャリア（以下ではＰＤＣＣＨコンポーネント・キャリアと呼ぶ）上のＰＣＦＩＣＨに基づいて設定すればよい。

たとえば、ＰＤＣＣＨコンポーネント・キャリアのＰＣＦＩＣＨ値が１である場合、リソースが割り当てられるクロス・スケジューリングされるコンポーネント・キャリアに関してシグナリングすることのできるＰＣＦＩＣＨ値は１および２である。ＰＤＣＣＨコンポーネント・キャリアのＰＣＦＩＣＨ値が２または３である場合、リソースが割り当てられるクロス・スケジューリングされるコンポーネント・キャリアに関してシグナリングすることのできるＰＣＦＩＣＨ値は２または３のいずれかである。表９は、コンポーネント・キャリア指示、およびＰＤＣＣＨコンポーネント・キャリアのＰＣＦＩＣＨ値に基づいてクロス・スケジューリングされるコンポーネント・キャリアのＰＣＦＩＣＨ値への、ＣＩＦ符号点の例示的なマッピングを示している。

コンポーネント・キャリアＡ上のＰＣＦＩＣＨ値が２である場合、ＣＩＦフィールドにＰＣＦＩＣＨ値１、２、または３を指示できることが好ましいと考えられるが、オーバヘッドを低減させるには、この場合に２または３のみをシグナリングすることを許可してもよいことに留意されたい。

それにもかかわらず、一般に、クロス・スケジューリングされるそれぞれのコンポーネント・キャリア上でシグナリングできないＰＣＦＩＣＨ値が使用されることがあることに留意されたい。この場合、ｅＮｏｄｅＢのスケジューラは、実際にはコンポーネント・キャリアの制御シグナリング領域には存在しないが、ユーザ端末によって制御シグナリング領域の一部であると仮定される１つまたは複数のＯＦＤＭシンボルにデータがマッピングされないようにする（たとえば、レート・マッチングを使用する）必要がある。これは、そのようなＯＦＤＭシンボルが、所与のマッピングによってコンポーネント・キャリア上のクロス・スケジューリングに関して誤ったＰＣＦＩＣＨ値をシグナリングすることしかできないからである。

より一般的な観点からすると、この方式を、第１のサブセットがＰＤＣＣＨコンポーネント・キャリアに使用されるのと同じＰＣＦＩＣＨ値ＰＣＦＩＣＨ_{ＰＤＣＣＨ ＣＣ}にマッピングされ、一方、他のサブセットがＰＣＦＩＣＨ_{ＰＤＣＣＨ ＣＣ}＋ＯのＰＣＦＩＣＨ値にマッピングされるような、利用可能なＳ個のサブセットのＣＩＦ符号点のＰＣＦＩＣＨ値へのマッピングとみなしてもよい。この場合、Ｏは、ある整数オフセット、たとえば設定可能な整数オフセット、負の整数オフセット、または正の整数オフセットを表す。２つのサブセットの場合、一例として、Ｏ＝＋１である。３つのサブセットの場合、オフセットは、たとえばＣＩＦ符号点の第２のサブセットについてはＯ＝＋１であり、ＣＩＦ符号点の第３のサブセットについてはＯ＝＋２である。

代替実装例では、サブセットをＰＣＦＩＣＨ_{ＢＷ ＣＣ}＋ＯのＰＣＦＩＣＨ値にマッピングしてもよく、この場合、ＰＣＦＩＣＨ_{ＢＷ ＣＣ}は、クロス・スケジューリングされるコンポーネント・キャリア（ＣＣ）の帯域幅（ＢＷ）に関して事前に定められるＰＣＦＩＣＨ値であり、Ｏは、前述の例のように、ある整数オフセット、たとえば設定可能な整数オフセット、負の整数オフセット、または正の整数オフセットを表す。

例示的な３つの使用シナリオの考察からわかるように、ＣＩＦフィールドによってシグナリングすることのできるＰＣＦＩＣＨ値は、ユース・ケース・シナリオ／ｅＮｏｄｅＢ展開シナリオに基づいて制限されるが、シグナリングすることのできるＰＣＦＩＣＨ値が適切に選択されるので、その「制限」はシステム・スループットに対して顕著な影響を及ぼさない。また、この制限は、マッピングを設定する場合の上位層シグナリング・オーバヘッドを低減させる。

特に、ユーザ端末によって使用できるように設定し選択すべき様々なマッピングがあり、たとえばＲＲＣシグナリング・メッセージ（たとえば、マッピング設定メッセージ）を使用してｅＮｏｄｅＢからユーザ端末にシグナリングすればよい。

同様に、ｅＮｏｄｅＢはたとえば、ＲＲＣシグナリング・メッセージ（マッピング選択メッセージ）を使用して、ＤＣＩのＣＩＦフィールドを解釈するのにどのマッピングを使用すべきかをユーザ端末に示してもよい。いくつかの実施形態では、ｅＮｏｄｅＢは、所与の使用シナリオに関する設定に応じてＣＩＦ符号点のＰＣＦＩＣＨ値／マッピングを示すＲＲＣシグナリングを使用して１つまたは複数の所定の使用シナリオ（上述の例を参照されたい）を示してもよい。また、両方の機能を実現するマッピング設定と選択メッセージの組み合わせを選択してもよい。

あるいは、ＤＣＩ内のＣＩＦフィールドを解釈するのに使用すべきマッピングの選択は、ｅＮｏｄｅＢとユーザ端末との共通理解に基づいてユーザ端末によって行ってもよい。このような共通理解は、たとえば、関連する標準化文献におけるＵＥ手順を指定することによって事前に決定すればよい。

たとえば、ユーザ端末は、クロス・スケジューリングされるコンポーネント・キャリア、送信電力レベルなどに応じて適切なマッピングを選択してもよい。あるいは、ＲＲＣシグナリング・メッセージ内でシグナリングされるパラメータ（たとえば、帯域幅、コンポーネント・キャリア・タイプ、ＰＤＣＣＨ監視セットなど）からシナリオを導いてもよい。

さらなる代替実施形態では、マッピングの数が事前に設定されることも、使用すべき１つのマッピングが選択されることもなく、その代わりに、ｅＮｏｄｅＢが、ユーザ端末によって使用すべきマッピングをＲＲＣシグナリング・メッセージによってシグナリングし、ユーザ端末が、シグナリングされたマッピングを使用してＤＣＩのＣＩＦフィールドを解釈する。

すでに指摘したように、ＤＣＩのＣＩＦフィールド内のクロス・スケジューリングされるコンポーネント・キャリア上でＰＣＦＩＣＨ値のシグナリングをより柔軟に行うには、ＣＩＦ符号点の複数のマッピングを設ければよく、ユーザ端末は、自律的にあるいはｅＮｏｄｅＢからのあるシグナリング・メッセージに基づいて、１つのマッピングを選択してＣＩＦフィールドを解釈する。

この場合も、下りリンク・コンポーネント・キャリアが５つあり、ＣＩＦフィールドのサイズが３ビットであると仮定すると、２つの異なるＰＣＦＩＣＨ値を示すことができる。したがって、たとえば、ＲＲＣシグナリングを使用する場合、ｅＮｏｄｅＢは、以下の表１０に例示されているようにＰＣＦＩＣＨ値のすべての組み合わせに関するマッピングを設定することができる。８つのＣＩＦ符号点が２つのサブセットに分割され、各サブセットが、この８つの値のうちの４つからなり、かつクロス・キャリア・スケジューリングすることのできる４つのコンポーネント・キャリア（すなわち、ＰＤＣＣＨコンポーネント・キャリアに対応しない４つのコンポーネント・キャリア）のうちの１つに関連付けられると仮定されることに留意されたい。

表１０を見るとわかるように、１０個のマッピングを使用してＰＣＦＩＣＨ値のすべての可能な組み合わせをシグナリングできる。ユーザ端末によって使用されるマッピングを選択するためのＲＲＣメッセージを、ｅＮｏｄｅＢからユーザ端末にシグナリングしてもよい。ＰＣＦＩＣＨ値のシグナリングにおいてこのような十分な融通性を実現するために、１０個のマッピングのうちの１つをシグナリングするのに選択メッセージの４ビットが必要になる（

）。

しかし、５つよりも多くのコンポーネント・キャリアが下りリンクに設定されるシナリオでは、クロス・スケジューリングできるコンポーネント・キャリアの数が増え、ＰＣＦＩＣＨの様々な組み合わせがそれぞれの異なるコンポーネント・キャリアに適用可能になるとともに様々なＰＣＦＩＣＨ値をシグナリングする必要が生じる可能性が高くなる。たとえば、コンポーネント・キャリアＢの場合、マッピング１によるＰＣＦＩＣＨ値が適用可能であってよく、コンポーネント・キャリアＣの場合、マッピング２が適用可能であってよく、他のコンポーネント・キャリアについても同様である。このため、オーバヘッドが著しく増大する可能性があり、マッピング設定メッセージは非常に多くのマッピングをシグナリングする必要がある。

したがって、本発明のさらなる実施形態では、複数のマッピングを設定してもよいが、その数は、クロス・スケジューリングされるコンポーネント・キャリアに関するＰＣＦＩＣＨ値のシグナリングの融通性の一部しか実現しないように限定される。たとえば、ＲＲＣシグナリングによって定められるマッピングは以下のように限定される。

- 特定の使用シナリオに対応するいくつかのマッピングの定義：
ＲＲＣメッセージを使用して特定の使用シナリオのマッピングをシグナリングしてもよく、したがって、ＲＲＣメッセージは、シグナリングできるＰＣＦＩＣＨ値の可能な組み合わせ（上述のように、ユーザ端末によって使用シナリオに基づいて暗黙的に導かれる）を限定する。

- コンポーネント・キャリアのラベル付け：
下りリンク・コンポーネント・キャリアをその帯域幅に応じてソートしてもよい（たとえば、狭帯域幅、すなわちしきい値よりも狭い帯域幅を有するコンポーネント・キャリアは、より低いコンポーネント・キャリア・ラベル／ＩＤを有し、広帯域幅、すなわちしきい値よりも広い帯域幅を有するコンポーネント・キャリアは、より高いコンポーネント・キャリア・ラベル／ＩＤを有する）。

大きいＰＣＦＩＣＨ値（３または４）が必要になるのは狭帯域幅コンポーネント・キャリアだけでよい。たとえば、３つの狭帯域幅コンポーネント・キャリア（すなわち、帯域幅がしきい値よりも狭い）と２つの広帯域幅コンポーネント・キャリア（すなわち、帯域幅がしきい値以上である）とを含む５つの下りリンク・コンポーネント・キャリアの場合を仮定し、ＰＤＣＣＨコンポーネント・キャリアが広帯域幅コンポーネント・キャリア（コンポーネント・キャリアＥ）であると仮定する。また、示されるＰＣＦＩＣＨ値は、狭帯域幅コンポーネント・キャリアの場合は３および４であると仮定され、一方、広帯域幅コンポーネント・キャリアの場合のＰＣＦＩＣＨ値は１または２であると仮定される。

コンポーネント・キャリアのインデックス付けが無作為である場合、すなわち、狭／広帯域幅コンポーネント・キャリアが１から５の間の任意のラベル／インデックスを有してもよい場合、表１１に示されているように、例示的な６つのマッピングが必要になる。ＰＤＣＣＨコンポーネント・キャリアがコンポーネント・キャリア・インデックス５を有することが例示的に仮定されていることに留意されたい。また、表中の「１／２」は、それぞれのマッピングに応じて、ＣＩＦ符号点の第１のサブセットに応じたＣＩＦ符号点が、クロス・スケジューリングされるそれぞれのコンポーネント・キャリアに関してＰＣＦＩＣＨ値の１を示し、一方、ＣＩＦ符号点の第２のサブセットに応じたＣＩＦ符号点が、クロス・スケジューリングされるそれぞれのコンポーネント・キャリアに関してＰＣＦＩＣＨ値の２を示すことを意味する。同様に、表中の「３／４」は、それぞれのマッピングに応じて、ＣＩＦ符号点の第１のサブセットに応じたＣＩＦ符号点が、クロス・スケジューリングされるそれぞれのコンポーネント・キャリアに関してＰＣＦＩＣＨ値の３を示し、一方、ＣＩＦ符号点の第２のサブセットに応じたＣＩＦ符号点が、クロス・スケジューリングされるそれぞれのコンポーネント・キャリアに関してＰＣＦＩＣＨ値の４を示すことを意味する。

コンポーネント・キャリア・インデックス付けがコンポーネント・キャリア帯域幅に応じたものである場合、必要なマッピング方式は１つだけである。たとえば、狭帯域幅コンポーネント・キャリアが低いコンポーネント・キャリア・インデックスを有し、広帯域幅コンポーネント・キャリアが大きいインデックスを有する場合、以下の表１２に示されているマッピングを定義するだけでよい。

また、上述のいくつかの例では、ＣＩＦ符号点の所与のサブセットの符号点が同じＰＣＦＩＣＨ値にマッピングされている。基本的に、このことは、様々なコンポーネント・キャリアのＰＣＦＩＣＨ値に「共通のマッピング」があることを意味する。本発明のさらなる実施形態では、個々のコンポーネント・キャリアのＰＣＦＩＣＨ値は、ＣＩＦ符号点の各サブセットの様々な符号点に対して異なっていてもよい。

一例が表１３に示されており、この場合も、例示のために、ＤＣＩ（ＰＤＣＣＨ）が設定済みの５つの下りリンク・コンポーネント・キャリアＡ、Ｂ、Ｃ、Ｄ、およびＥのうちのコンポーネント・キャリアＡ上で送信されると仮定する。たとえば、コンポーネント・キャリアＢおよびＣは２つの広帯域幅コンポーネント・キャリア（たとえば、１５ＭＨｚまたは２０ＭＨｚ）であってよい。したがって、これらのコンポーネント・キャリア上の制御シグナリング領域は通常、１つまたは２つのＯＦＤＭシンボルにしか及ばない。一方、コンポーネント・キャリアＤおよびＥはたとえば、制御シグナリング領域がサブフレームの３つまたは４つのＯＦＤＭシンボルに及ぶ可能性が高い、後方互換性を有する（任意に狭帯域幅、たとえば５ＭＨzの）コンポーネント・キャリアであってもよい。

ＣＩＦ符号点のＰＣＦＩＣＨ値へのコンポーネント・キャリアに依存したマッピングをより柔軟に行うのを可能にする例示的な別の実施形態は、前述のように複数のマッピングをｅＮｏｄｅＢによって事前に設定するかあるいは設定してもよく、次いでｅＮｏｄｅＢが、ＣＩＦフィールド内の符号点の意味を解釈するうえでユーザ端末によって使用すべきマッピングをコンポーネント・キャリアごとに識別するＲＲＣシグナリング・メッセージ（マッピング選択メッセージ）を送信してもよい実施形態である。たとえば、一実装例では、ｅＮｏｄｅＢとユーザ端末は、利用可能な下りリンク・コンポーネント・キャリアを帯域幅単位に（たとえば、様々な下りリンク・コンポーネント・キャリアの帯域幅の昇順に）アグリゲートしてもよく、したがって、ｅＮｏｄｅＢとユーザ端末は、同じ順序のコンポーネント・キャリアを有し、それによって、コンポーネント・キャリアが「アドレス指定可能」になり、コンポーネント・キャリアをそれぞれの異なるマッピングに割り当てることができる。

一例では、ｅＮｏｄｅＢは単に、狭帯域幅コンポーネント・キャリアに関してより大きいＰＣＦＩＣＨ値（たとえば、３または４あるいは５以上）を示すいくつかのマッピング・テーブルをコンポーネント・キャリアの最初の２分の１に関してシグナリングしてもよく、さらに、広帯域幅コンポーネント・キャリアに関してより小さいＰＣＦＩＣＨ値（たとえば、０、１、または３）を示すいくつかのマッピング・テーブルをコンポーネント・キャリアの第２の２分の１に関してシグナリングしてもよい。また、コンポーネント・キャリアのいくつかの組み合わせでは小さいＰＣＦＩＣＨ値と大きいＰＣＦＩＣＨ値の両方を混ぜることが必要になることがあり、これは、この例示的な実施形態によって実現することができる。

さらなる実施形態では、モバイル端末において、使用シナリオを導き、それに関連して、ＤＣＩ内のＣＩＦフィールド用の対応するマッピング方式を選択する際に、一般に無線アクセス・ネットワークの個々のセル内でブロードキャストされるシステム・ブロードキャスト情報（ＳＩＢ）が使用される。この実施形態では、モバイル端末は、モバイル端末が無線セルにおいて適用できる使用シナリオを判定するのを可能にする１つまたは複数のパラメータを含むシステム・ブロードキャスト情報を受信し、モバイル端末はさらに、検出された使用シナリオに基づいてＣＩＦフィールドに使用すべきマッピングを選択する。

たとえば、上りリンク／下りリンク・コンポーネント・キャリアの帯域幅は典型的には、マスタ情報によってブロードキャストされる。たとえば、３ＧＰＰベースのネットワークでは、この情報はマスタ情報ブロック（ＭＩＢ）に含まれる。また、それぞれのコンポーネント・キャリアの周波数帯域は、システム情報ブロックＳＩＢ１に含まれる要素「ｆｒｅｑＢａｎｄｉｎｄｉｃａｔｏｒ」に示される。モバイル端末（ユーザ端末）は、これらのパラメータのうちの１つまたは複数に基づいて、ＤＣＩのＣＩＦにＰＣＦＩＣＨ値のどのサブセットが示されているかを判定してもよい。

他の実施形態では、モバイル端末がＣＩＦ符号点の適切なマッピングを選択するのを可能にする新規システム情報をブロードキャストしてもよい。たとえば、３ＧＰＰ ＬＴＥ−Ａ（リリース１０）システムを考えると、シナリオが導かれるパラメータはコンポーネント・キャリア・タイプ（後方互換／非後方互換／エクステンション・キャリア）であってもよい。コンポーネント・キャリア・タイプは、たとえばシステム・ブロードキャスト情報内で無線セル内のすべてのユーザ端末にブロードキャストされてもよい。しかし、エクステンション・キャリアの場合、送信されるブロードキャスト・メッセージはなくてもよい。したがって、エクステンション・キャリアの場合、コンポーネント・キャリアのタイプを個別のＲＲＣ接続再設定メッセージによってユーザ端末に送信してもよい。（後方互換／非後方互換／エクステンション・キャリアにかかわらず）コンポーネント・キャリア・タイプ全般を常に個別のＲＲＣメッセージを使用してシグナリングすることが可能であると考えられる。

また、システム情報ブロードキャストの代わりに、個別のＲＲＣシグナリング・メッセージを使用して、ユーザ端末が使用シナリオを導くことができるようにユーザ端末に所望のパラメータを供給し、ＤＣＩのＣＩＦ符号点を解釈するのに使用すべきマッピングを供給してもよいことに留意されたい。セル内のユーザ端末が様々な帯域幅を有するそれぞれの異なる数の下りリンク・コンポーネント・キャリアおよび上りリンク・コンポーネント・キャリアをアグリゲートすることができる場合、個別のＲＲＣシグナリングを使用した方が適切である場合がある。なぜなら、これによって個々のユーザ端末の設定に対処することが可能になるからである。したがって、例示的な一実施形態では、ＤＬ／ＵＬコンポーネント・キャリアの数および対応する帯域幅を個別のＲＲＣメッセージ内で各ユーザ端末にシグナリングしてもよく、その場合、ユーザ端末は、示されるパラメータに基づいてＤＣＩのＣＩＦを解釈するのに適切なマッピングを選択することができる。

異種ネットワーク動作に関する別の例示的な使用シナリオでは、それぞれマクロｅＮｏｄｅＢ、ホームｅＮｏｄｅＢ、フェムト／ピコ・セルｅＮｏｄｅＢによって制御される様々な種類のセル、たとえばマクロ・セル、ホーム・セル、フェムト／ピコ・セルなどがあってもよい。すべてのこれらのセルはその範囲および周波数リソースが部分的に重なり合ってもよい（たとえば、マクロｅＮｏｄｅＢは５つの下りリンク・コンポーネント・キャリア上でデータを送信してもよく、一方、ホームｅＮｏｄｅＢはこの５つの下りリンク・コンポーネント・キャリアのうちの２つの下りリンク・コンポーネント・キャリア上で送信を行ってもよい）。したがって、この動作の結果として生じる干渉シナリオは、様々なネットワーク条件に応じて異なる可能性がある。このため、ＰＤＣＣＨ（リソース割り当てを有するＤＣＩを含む）は、干渉の弱いコンポーネント・キャリア、通常、電力が高くチャネル条件がより適切なコンポーネント・キャリア上で送信されることが好ましい（すなわち、クロス・キャリア・スケジューリングを使用すべきである）。それにもかかわらず、変調符号化方式／トランスポート・ブロック・サイズをチャネル条件に適合させることができるので、ＰＤＳＣＨに関するデータを低電力コンポーネント・キャリア（高干渉）上で送信してもよい。

たとえば、５つのコンポーネント・キャリアＡ、Ｂ、Ｃ、Ｄ、およびＥを送信し制御するマクロｅＮｏｄｅＢを考える。さらに、２つのコンポーネント・キャリアＡおよびＢがこれらのコンポーネント・キャリアＡおよびＢ上（または少なくともそのサブバンドの部分上）のホームｅＮｏｄｅＢの送信によって強い干渉を受けると仮定する。この場合、マクロｅＮｏｄｅＢは、コンポーネント・キャリアＣ、Ｄ、および／またはＥ上でＤＣＩを含むＰＤＣＣＨを送信してもよく、この３つのコンポーネント・キャリア上のクロス・スケジューリングを使用してコンポーネント・キャリアＡおよびＢ上のデータ送信用のリソースを割り当てる。

前述のように、高干渉／低電力コンポーネント・キャリアＡおよびＢは、マクロｅＮｏｄｅＢがＤＣＩを含むＰＤＣＣＨを送信する場合に頻繁には使用されず、したがって、コンポーネント・キャリアＡおよびＢは小さい制御領域サイズを有してもよく、すなわち、ＰＣＦＩＣＨ値が１または２であってよく、極端なケースでは制御シグナリング領域がなくてもよい（ＰＣＦＩＣＨ＝０）。マクロｅＮｏｄｅＢは、システム・ブロードキャストまたは個別ＲＲＣメッセージを使用して、設定済みのコンポーネント・キャリアの干渉レベルをユーザ端末に通知してもよく、それによって、ユーザ端末は、それぞれの設定済みのコンポーネント・キャリア上の干渉レベルに基づいてＣＩＦ符号点を解釈するための対応するマッピング・テーブルを判定することができる。

あるいは、マクロｅＮｏｄｅＢによって制御されるマクロ・セル内の様々なユーザ端末が様々なコンポーネント・キャリアをアグリゲートすることができるので、マクロｅＮｏｄｅＢは、ユーザ端末にＰＤＣＣＨ監視セットをシグナリングして、ユーザ端末がどのコンポーネント・キャリア（たとえば、上述の例ではコンポーネント・キャリアＣ、Ｄ、およびＥ）のＰＤＣＣＨ（ＤＣＩ）を監視すべきかをそれぞれのユーザ端末に通知してもよい。ユーザ端末は、シグナリングされたＰＤＣＣＨ監視セットから、コンポーネント・キャリアＡおよびＢが低電力コンポーネント・キャリアである（すなわち、強い干渉を受ける）ことを判定することができ、したがって、ユーザ端末はこの場合も、示されるパラメータに基づいてＤＣＩのＣＩＦ符号点を解釈するのに適切なマッピングを判定することができる。

前述の例示的な実施形態および例示的なマッピングの大部分では、ｅＮｏｄｅＢのスケジューラによって実現されるクロス・スケジューリング機構は制限されていない。本発明のさらなる実施形態では、他のコンポーネント・キャリアをクロス・スケジューリングする可能性を制限することによって、ＣＩＦ符号点によってシグナリングすることのできるＰＣＦＩＣＨ値の数が増大される。

たとえば、上記に表７および表８に関して説明した例と同様に、「アンカー・キャリア」として働きかつＰＤＣＣＨ（ＤＣＩを含む）をシグナリングして他の下りリンク・コンポーネント・キャリア上のユーザ端末をクロス・キャリア・スケジューリングするのに使用されるいくつかの（たとえば、２つの）広帯域幅コンポーネント・キャリア（たとえば、１５ＭＨｚまたは２０ＭＨｚ）があると仮定してもよい。たとえば、２つのアンカー・コンポーネント・キャリアはコンポーネント・キャリアＡおよびＢであってもよく、一方、残りの下りリンク・コンポーネント・キャリアはＣ、Ｄ、およびＥとインデックス／ラベル付けされる。

ｅＮｏｄｅＢは、コンポーネント・キャリアＣおよびＤに関するクロス・キャリア・スケジューリングについてのＤＣＩをコンポーネント・キャリアＡ上にシグナリングしてもよく、一方、コンポーネント・キャリアＣおよびＤに関するクロス・キャリア・スケジューリングについてのＤＣＩがコンポーネント・キャリアＢ上に送信される。したがって、ＤＣＩのＣＩＦフィールドは２つのコンポーネント・キャリアを示すだけでよい。もちろん、クロス・スケジューリングできるコンポーネント・キャリアがアンカー・コンポーネント・キャリア上で重ならないようにすることも可能であると考えられるが、このことは、スケジューラがアンカー・コンポーネント・キャリア上にＰＤＣＣＨをマッピングする際のさらなる制限を意味し、ブロッキングの確率が高くなる可能性がある。

たとえば、表１４に示されている以下のマッピングを使用してコンポーネント・キャリアＡ上にシグナリングされるＤＣＩのＣＩＦフィールドを解釈してもよい。

一方、表１５に示されているマッピングを使用して、コンポーネント・キャリアＢ上にシグナリングされたＤＣＩのＣＩＦフィールドを解釈してもよい。

したがって、この例では、スケジューラがＤＣＩをアンカー・コンポーネント・キャリアＡおよびＢにマッピングする際の制限が許容されるレベルであるとき、コンポーネント・キャリアＣ、Ｄ、およびＥに関するクロス・キャリア・スケジューリングについてほぼすべてのＰＣＦＩＣＨ値（０を除く）を示すことができる。しかし、スケジューラがＤＣＩをアンカー・コンポーネント・キャリアＡおよびＢにマッピングする際にわずかに高いレベルの制限を許容すると、表１６および表１７に示されているようにＰＣＦＩＣＨ値の０もシグナリングすることができ、コンポーネント・キャリアＤに関するクロス・キャリア・スケジューリングについてＰＣＦＩＣＨ値同士の部分的な重なり合いが実現される。表１６は、コンポーネント・キャリアＡ上で受信されるＤＣＩのＣＩＦフィールドを解釈するのに使用される。

表１７は、コンポーネント・キャリアＢ上で受信されるＤＣＩのＣＩＦフィールドを解釈するのに使用される。

前述のように、たとえば、コンポーネント・キャリアの帯域幅のようなコンポーネント・キャリアのいくつかのパラメータは基本的に、このコンポーネント・キャリアの利用可能なＰＣＦＩＣＨ値のうちのいくつかのＰＣＦＩＣＨ値の使用を除外することができ、したがって、各コンポーネント・キャリアの（ほぼ）すべてのＰＣＦＩＣＨ値をシグナリングすることが可能でも、スケジューラに課される制限が相殺されることはない。したがって、スケジューラがクロス・キャリア・スケジューリングに関するＤＣＩを特定の（アンカー）コンポーネント・キャリアにマッピングする際の融通性の制限と、様々なコンポーネント・キャリアに関してシグナリングすることのできるＰＣＦＩＣＨ値の範囲とをある程度適切に兼ね合わせることができる。

たとえば、さらなる一実施形態では、ユーザ端末は、上記に表４、表６、または表１３に示されているようにコンポーネント・キャリアＡ上でシグナリングされたＤＣＩのＣＩＦフィールドを解釈し、コンポーネント・キャリアＡ上でのコンポーネント・キャリアＢのクロス・スケジューリングを可能にすることができ、一方、ユーザ端末は、表８に示されている例と同様にコンポーネント・キャリアＢ上にシグナリングされたＤＣＩのＣＩＦフィールドを解釈することができる。

本発明の別の実施形態は、ハードウェアおよびソフトウェアを使用した上述の様々な実施形態の実装例に関する。本発明の様々な実施形態をコンピューティング・デバイス（プロセッサ）を使用して実施または実行してもよいことを認識されたい。コンピューティング・デバイスまたはプロセッサはたとえば、汎用プロセッサ、デジタル信号プロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）、または他のプログラマブル・ロジック・デバイスなどであってもよい。本発明の様々な実施形態をこれらのデバイスの組み合わせによって実行または具体化してもよい。

また、本発明の様々な実施形態は、プロセッサによって実行されるかあるいは直接ハードウェア内で実行されるソフトウェア・モジュールによって実施されてもよい。また、ソフトウェア・モジュールとハードウェア実装例の組み合わせも可能であると考えられる。ソフトウェア・モジュールは、任意の種類のコンピュータ可読記憶媒体、たとえばＲＡＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、フラッシュ・メモリ、レジスタ、ハード・ディスク、ＣＤ−ＲＯＭ、ＤＶＤなどに記憶されてもよい。

また、本発明の様々な実施形態の個々の特徴が、個々に別の発明の主題であってもよく、あるいは個々の特徴を任意の組み合わせが別の発明の主題であってもよい。

当業者には、広義に説明した本発明の趣旨または範囲から逸脱せずに特定の実施形態に示されたように本発明に多数の変形および／または修正を施せることが理解されよう。したがって、本発明は、あらゆる点において例示的なものとみなすべきであり、制限的なものとみなすべきではない。

１ ＤＣＩフォーマット
９０１ サブフレーム
９０２ リソース指示
９０３ キャリア指示
９０４ ＰＣＦＩＣＨ値
９０５ 制御シグナリング領域
９０６ ＰＣＦＩＣＨ値
９０７ 下りリンク制御情報
９０８ キャリア・インジケータ・フィールド
９０９ 下りリンク・リソース
１００２ 制御シグナリング領域
１００３ ＰＣＦＩＣＨ
１００４ ＰＤＣＣＨ
１００５ ＰＤＣＣＨ
１００６ ＰＣＦＩＣＨ値
１００７ リソース

Claims (12)

1. 複数の下りリンク・コンポーネント・キャリアのうちの１つの下りリンク・コンポーネント・キャリアのサブフレーム内の下りリンク・リソースをモバイル端末に割り当てる方法であって、
   １つの前記下りリンク・コンポーネント・キャリアに関する下りリンク制御情報を受信し、前記下りリンク制御情報のフォーマットが、
   １つの前記下りリンク・コンポーネント・キャリアのサブフレーム内の割り当てられる下りリンク・リソースを示すリソース割り当てフィールドと、
   前記下りリンク・リソースが前記コンポーネント・キャリアのうちのどれに割り当てられるかを示し、前記下りリンク制御情報によって下りリンク・リソースが割り当てられる前記コンポーネント・キャリア上の前記サブフレーム内の制御シグナリングのために使用されるＯＦＤＭシンボルの数をさらに示すキャリア・インジケータ・フィールドと、
   を含み、前記キャリア・インジケータ・フィールドのビットによって示すことのできる制御シグナリングのために使用されるＯＦＤＭシンボルの数の範囲は、制御シグナリングに使用できるＯＦＤＭシンボルの数の全範囲のうち、選択されたサブセットのみをカバーする、ステップと、
   前記割り当てられる下りリンク・リソースに関する下りリンク・データを受信するステップと、
   を含み、
   前記下りリンク制御情報の前記キャリア・インジケータ・フィールドは、前記キャリア・インジケータ・フィールドの前記ビットによって表すことのできる符号点の少なくとも２つの異なるサブセットを示し、前記サブセットの前記それぞれの符号点は、前記下りリンク制御情報によって下りリンク・リソースが割り当てられる前記コンポーネント・キャリア上の前記サブフレーム内の制御シグナリングのために使用されるそれぞれの異なる数のＯＦＤＭシンボルに前記モバイル端末によってマッピングされる、
   方法。
2. 前記モバイル端末において事前に定められるかあるいは上位層のシグナリングによって設定された複数の異なるマッピングがあり、各マッピングは、前記各サブセットの前記符号点の、前記下りリンク制御情報によって下りリンク・リソースが割り当てられる前記割り当てられる下りリンク・コンポーネント・キャリア上の前記サブフレーム内の制御シグナリングのために使用されるそれぞれの数のＯＦＤＭシンボルへのそれぞれのマッピングを示す、
   請求項１に記載の方法。
3. 上位層のシグナリングによって設定すべき前記複数の異なるマッピングは、すべての可能なマッピングのサブセットである、
   請求項２に記載の方法。
4. 前記キャリア・インジケータ・フィールドによって示すことができる前記制御シグナリングのために使用されるＯＦＤＭシステムの数の範囲の前記サブセットは、
   前記割り当てられる下りリンク・コンポーネント・キャリア上の干渉条件および電力レベル、
   前記割り当てられる下りリンク・コンポーネント・キャリア上のチャネル品質、
   前記割り当てられる下りリンク・コンポーネント・キャリアの帯域幅、
   前記下りリンク・コンポーネント・キャリアの負荷分散関数のステータス、
   前記割り当てられる下りリンク・コンポーネント・キャリアの種類、
   前記下りリンク制御情報が送信される前記コンポーネント・キャリア上の制御シグナリングに使用されるＯＦＤＭシンボルの数、および
   前記割り当てられる下りリンク・コンポーネント・キャリア上でシグナリングすべき上りリンクＡＣＫ／ＮＡＣＫの数、
   のうちの少なくとも１つに基づく、
   請求項２または３に記載の方法。
5. 前記モバイル端末において、前記下りリンク制御情報の前記キャリア・インジケータ・フィールドから制御シグナリングのために使用されるＯＦＤＭシンボルの数を定めるうえで、様々なマッピングのうちのどのマッピングを使用すべきかを示すマッピング選択メッセージを受信するステップをさらに含む、
   請求項１から４のいずれか一項に記載の方法。
6. 前記下りリンク・コンポーネント・キャリアの前記サブフレーム内の、前記モバイル端末に割り当てられる前記リソース・ブロックを、前記リソース割り当てフィールド、および前記下りリンク制御情報によって下りリンク・リソースが割り当てられる前記コンポーネント・キャリア上のサブフレーム内の制御シグナリングのために使用されるＯＦＤＭシンボルの数から判定するステップを含み、
   前記割り当てられる下りリンク・リソースに関する下りリンク・データを受信するステップは、前記サブフレームの前記判定されたリソース・ブロックに関する変調シンボルを受信するステップを含む、
   請求項１から５のいずれか一項に記載の方法。
7. 前記下りリンク制御情報は、前記下りリンク・コンポーネント・キャリアの第１の下りリンク・コンポーネント・キャリア上で受信され、前記下りリンク・コンポーネント・キャリアのうちの別の第２の下りリンク・コンポーネント・キャリア上にリソースを割り当てる、
   請求項１から６のいずれか一項に記載の方法。
8. 下りリンクでコンポーネント・キャリアのアグリゲーションを使用するモバイル通信システムにおいて使用され、複数の下りリンク・コンポーネント・キャリアのうちの１つの下りリンク・コンポーネント・キャリアのサブフレーム内の下りリンク・リソースを割り当てることができるモバイル端末であって、
   １つの前記下りリンク・コンポーネント・キャリアに関する下りリンク制御情報を受信する受信機を備え、前記下りリンク制御情報のフォーマットが、
   １つの前記下りリンク・コンポーネント・キャリアのサブフレーム内の割り当てられる下りリンク・リソースを示すリソース割り当てフィールドと、
   前記下りリンク・リソースが前記コンポーネント・キャリアのうちのどれに割り当てられるかを示し、前記下りリンク制御情報によって下りリンク・リソースが割り当てられる前記コンポーネント・キャリア上の前記サブフレーム内の制御シグナリングのために使用されるＯＦＤＭシンボルの数をさらに示すキャリア・インジケータ・フィールドと、
   を少なくとも含み、前記キャリア・インジケータ・フィールドのビットによって示すことのできる制御シグナリングのために使用されるＯＦＤＭシンボルの数の範囲は、制御シグナリングに使用できるＯＦＤＭシンボルの数の全範囲のうち、選択されたサブセットのみをカバーし、
   前記受信機は、前記割り当てられる下りリンク・リソースに関する下りリンク・データを受信するように構成され、
   前記下りリンク制御情報の前記キャリア・インジケータ・フィールドは、前記キャリア・インジケータ・フィールドのビットによって表すことのできる符号点の少なくとも２つの異なるサブセットを示し、
   前記モバイル端末は、前記下りリンク制御情報によって下りリンク・リソースが割り当てられる前記コンポーネント・キャリア上の前記サブフレーム内の制御シグナリングのために使用されるそれぞれの異なる数のＯＦＤＭシンボルに、前記サブセットの前記それぞれの符号点を、複数の異なるマッピングのうちの１つを使用してマッピングするプロセッサを備え、
   前記受信機は、前記複数の異なるマッピングを設定する上位層のシグナリングを受信するようにさらに構成され、各マッピングは、前記各サブセットの前記符号点の、前記下りリンク制御情報によって下りリンク・リソースが割り当てられる前記下りリンク・コンポーネント・キャリア上の前記サブフレーム内の制御シグナリングのために使用されるそれぞれの数のＯＦＤＭシンボルへのそれぞれのマッピングを示す、
   モバイル端末。
9. 前記下りリンク制御情報の前記キャリア・インジケータ・フィールドは、前記キャリア・インジケータ・フィールドのビットによって表すことのできる符号点の少なくとも２つの異なるサブセットを示し、
   前記モバイル端末は、前記下りリンク制御情報によって下りリンク・リソースが割り当てられる前記コンポーネント・キャリア上の前記サブフレーム内の制御シグナリングのために使用されるそれぞれの異なる数のＯＦＤＭシンボルに、前記サブセットの前記それぞれの符号点を、複数の所定の異なるマッピングのサブセットのうちの１つのマッピングを使用してマッピングするプロセッサを備え、
   前記受信機は、前記複数の異なるマッピングの前記サブセットを前記モバイル端末によって使用されるように設定する上位層の制御シグナリングを受信するように構成される、
   請求項８に記載のモバイル端末。
10. 前記下りリンク・コンポーネント・キャリアの前記サブフレーム内の、前記モバイル端末に割り当てられる前記リソース・ブロックを、前記リソース割り当てフィールド、および前記下りリンク制御情報によって下りリンク・リソースが割り当てられる前記コンポーネント・キャリア上の前記サブフレーム内の制御シグナリングのために使用されるＯＦＤＭシンボルの数から判定するプロセッサをさらに備え、
    前記受信機は、前記サブフレームの前記判定されたリソース・ブロックに関する変調シンボルを受信することを含め、前記割り当てられる下りリンク・リソースに関する前記下りリンク・データを受信するように構成される、
    請求項８または９に記載のモバイル端末。
11. 前記受信された変調シンボルを復調して符号化された下りリンク・データを取得する復調器と、
    前記符号化された下りリンク・データを復号する復号器と、
    をさらに備え、
    変調符号化方式は、前記下りリンク制御情報の前記リソース割り当てフィールドによって示される、
    請求項１０に記載のモバイル端末。
12. モバイル端末のプロセッサによって実行されたときに、請求項１から７のいずれか一項に記載の方法のステップを前記モバイル端末に実行させる命令を記憶する、
    コンピュータ可読媒体。
    

Images