(57)【要約】      （修正有）【課題】通信装置が、ユーザ機器にスケジューリングされた上りリンク・コンポーネント・キャリアのパワー・ヘッドルームの報告を受信する方法を提供する。【解決手段】方法は、下りリンク・コンポーネント・キャリア上で、ユーザ機器にリソース割当情報を送信し、リソース割当情報は、複数のビットを含み、一つのビットは、対応する下りリンク・コンポーネント・キャリアがアクティブ化されるべきかまたは非アクティブ化されるべきかのいずれかを示し、前記複数のビットに含まれるいずれかのビットが、対応する下りリンク・コンポーネント・キャリアがアクティブ化されるべきことを示す場合は、前記複数のビットは、パワー・ヘッドルームの報告を要求するパワー・ヘッドルーム報告要求をさらに示す。前記リソース割当情報に従って、ユーザ機器によりアクティブ化された上りリンク・コンポーネント・キャリアのパワー・ヘッドルームを受信する。【選択図】なし【特許請求の範囲】
【請求項１】
ユーザ機器と通信する通信装置の処理を制御する集積回路であって、前記処理は、
下りリンク・コンポーネント・キャリア上で、前記ユーザ機器に上りリンク・リソースまたは下りリンク・リソースを割り当てるためのリソース割当情報を送信し、前記リソース割当情報は、複数のビットを含み、複数の下りリンク・コンポーネント・キャリアの各々は、前記複数のビットに含まれる一つのビットと対応しており、前記一つのビットは、対応する下りリンク・コンポーネント・キャリアがアクティブ化されるべきかまたは非アクティブ化されるべきかのいずれかを示し、前記複数のビットに含まれるいずれかのビットが、対応する下りリンク・コンポーネント・キャリアがアクティブ化されるべきことを示す場合は、前記複数のビットは、パワー・ヘッドルームの報告を要求するパワー・ヘッドルーム報告要求をさらに示し、
前記リソース割当情報に従って、前記ユーザ機器によりアクティブ化された下りリンク・コンポーネント・キャリアに対応する上りリンク・コンポーネント・キャリアを用いて、前記ユーザ機器にスケジューリングされた上りリンク・コンポーネント・キャリアのパワー・ヘッドルームと、前記ユーザ機器にスケジューリングされていない上りリンク・コンポーネント・キャリアの仮想パワー・ヘッドルームとを受信し、前記スケジューリングされた上りリンク・コンポーネント・キャリアのパワー・ヘッドルームは、前記リソース割当情報に基づいて、前記ユーザ機器により計算されたものであり、前記仮想パワー・ヘッドルームは、スケジューリングされていない上りリンク・コンポーネント・キャリアの事前に構成された仮想上りリンク・リソース割当に基づいて、前記ユーザ機器により計算されたものである、
集積回路。
【請求項２】
前記事前に構成された仮想上りリンク・リソース割当は、前記スケジューリングされていない上りリンク・コンポーネント・キャリアに割り当てられるべきリソース・ブロックの個数が１つであるものとして構成されたものである、
請求項１に記載の集積回路。
【請求項３】
前記事前に構成された仮想上りリンク・リソース割当は、更に、トランスポート・フォーマットのオフセット値が０であるものとして構成されたものである、
請求項１又は２に記載の集積回路。
【請求項４】
前記仮想パワー・ヘッドルームは、前記ユーザ機器の前記スケジューリングされていない上りリンク・コンポーネント・キャリアの事前に構成された最大送信電力（Ｐｃｍａｘ，ｃ）にさらに基づいて計算される、
請求項１から３のいずれか一項に記載の集積回路。
【請求項５】
前記ユーザ機器の前記スケジューリングされていない上りリンク・コンポーネント・キャリアの前記事前に構成された仮想上りリンク・リソース割当および前記事前に構成された最大送信電力に関する情報を有し、
前記受信された仮想パワー・ヘッドルームと前記事前に構成された仮想上りリンク・リソース割当および事前に構成された最大送信電力とに基づいて、前記スケジューリングされていない上りリンク・コンポーネント・キャリアの経路損および／またはリソース・ブロックあたりの電力を判定する、
請求項１から４のいずれか一項に記載の集積回路。
【請求項６】
前記スケジューリングされていない上りリンク・コンポーネント・キャリアの前記事前に構成された最大送信電力には、前記ユーザ機器の上りリンク・コンポーネント・キャリアの最高の（Ｐｃｍａｘ＿Ｈ）または最低の（Ｐｃｍａｘ＿Ｌ）構成可能な最大送信電力がセットされる、
請求項４または５に記載の集積回路。
【請求項７】
前記仮想パワー・ヘッドルームは、前記スケジューリングされていない上りリンク・コンポーネント・キャリアについて前記ユーザ機器によって構成された最大送信電力（Ｐｃｍａｘ，ｃ）と等しい、
請求項１または２に記載の集積回路。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、基準サブフレームの上りリンク・リソース割当を有しない上りリンク・コンポーネント・キャリアのパワー・ヘッドルームの報告に関する。さらに、本発明は、モバイル端末の新しいパワー・ヘッドルーム報告の使用に関する。
【背景技術】
【０００２】
＜ロング・ターム・エボリューション（ＬＴＥ）＞
ＷＣＤＭＡ（登録商標）無線アクセス技術に基づく第３世代モバイル・システム（３Ｇ）が、全世界で大規模に展開されている。この技術を強化しまたは進歩させる第１ステップは、高速下りリンク・パケット・アクセス（ＨＳＤＰＡ）と、高速上りリンク・パケット・アクセス（ＨＳＵＰＡ）とも称する機能強化された上りリンクを導入し、非常に競争力のある無線アクセス技術を与えることである。
【０００３】
さらに増加するユーザ需要に備え、新しい無線アクセス技術に対して競争力を持つために、３ＧＰＰは、ロング・ターム・エボリューション（ＬＴＥ）と呼ばれる新しいモバイル通信システムを導入した。ＬＴＥは、次の１０年間の高速のデータ・トランスポートおよび媒体トランスポートならびに大容量の音声サポートに関するキャリアの必要を満足するために設計されている。高いビット・レートを提供する能力が、ＬＴＥの主要な手段である。
【０００４】
拡張ＵＭＴＳ地上波無線アクセス（ＵＴＲＡ）およびＵＭＴＳ地上無線アクセス・ネットワーク（ＵＴＲＡＮ）と呼ばれるロング・ターム・エボリューション（ＬＴＥ）のワーク・アイテム（ＷＩ）仕様は、リリース８（ＬＴＥ）として最終化される予定である。ＬＴＥシステムは、短待ち時間および低コストと共にフルＩＰベース機能性を提供する、効率的なパケットベースの無線アクセスおよび無線アクセス・ネットワークを表す。詳細なシステム要件を与える。ＬＴＥでは、所与のスペクトルを使用する柔軟なシステム展開を達成するために、１．４ＭＨｚ、３．０ＭＨｚ、５．０ＭＨｚ、１０．０ＭＨｚ、１５．０ＭＨｚ、および２０．０ＭＨｚなどのスケーラブルな複数の送信帯域幅が指定される。下りリンクでは、直交周波数分割多重（ＯＦＤＭ）ベースの無線アクセスが、低シンボル・レートに起因する多経路干渉（ＭＰＩ）に対するその固有のイミュニティ、サイクリック・プレフィックスの使用、および異なる送信帯域幅配置に対するその親和性のゆえに、採用された。上りリンクでは、大面積カバレージのプロビジョニングが、ユーザ機器（ＵＥ）の制限された送信電力を考慮して、ピーク・データ・レートの改善より優先されたので、シングル・キャリア周波数分割多元接続（ＳＣ−ＦＤＭＡ）ベースの無線アクセスが採用された。多重入力・多重出力（ＭＩＭＯ）チャネル伝送技法を含む多数の主要なパケット無線アクセス技術が使用され、非常に効率的な制御シグナリング構造が、ＬＴＥ（リリース８）で達成される。
【０００５】
＜ＬＴＥアーキテクチャ＞
全体的なアーキテクチャを図１に示し、Ｅ−ＵＴＲＡＮアーキテクチャのより詳細な表現を、図２に示す。Ｅ−ＵＴＲＡＮは、Ｅ−ＵＴＲＡユーザ・プレーン（ＰＤＣＰ／ＲＬＣ／ＭＡＣ／ＰＨＹ）とユーザ機器（ＵＥ）に向かう制御プレーン（ＲＲＣ）プロトコル終端とを提供するｅノードＢからなる。ｅノードＢ（ｅＮＢ）は、物理（ＰＨＹ）レイヤ、媒体アクセス制御（ＭＡＣ）レイヤ、無線リンク制御（ＲＬＣ）レイヤ、ならびにユーザプレーン・ヘッダ圧縮および暗号化の機能性を含むパケット・データ制御プロトコル（ＰＤＣＰ）レイヤをホスティングする。ｅノードＢ（ｅＮＢ）は、制御プレーンに対応する無線リソース制御（ＲＲＣ）機能性をも提供する。ｅノードＢ（ｅＮＢ）は、無線リソース管理、アドミッション制御、スケジューリング、ネゴシエートされた上りリンク・サービス品質（ＱｏＳ）の実施、セル情報ブロードキャスト、ユーザ・プレーン・データおよび制御プレーン・データの暗号化／暗号化解除、ならびに上りリンク／下りリンク・ユーザ・プレーン・パケット・ヘッダの圧縮／圧縮解除を含む多数の機能を実行する。ｅノードＢは、Ｘ２インターフェースによってお互いに相互接続される。
【０００６】
ｅノードＢは、Ｓ１インターフェースによってＥＰＣ（発展型パケット・コア）に、より具体的にはＳ１−ＭＭＥによってＭＭＥ（無線通信移動管理装置）に、およびＳ１−Ｕによってサービング・ゲートウェイ（ＳＧＷ）にも接続される。Ｓ１インターフェースは、ＭＭＥ／サービング・ゲートウェイとｅノードＢとの間の多対多関係をサポートする。ＳＧＷは、ｅノードＢ間ハンドオーバ中にユーザ・プレーンのモビリティ・アンカとして、およびＬＴＥと他の３ＧＰＰ技術との間のモビリティのアンカとしても働き（Ｓ４インターフェースを終端し、２Ｇ／３ＧシステムとＰＤＮ  ＧＷとの間のトラフィックを中継し）ながら、ユーザ・データ・パケットをルーティングし、転送する。アイドル状態のユーザ機器について、ＳＧＷは、下りリンク・データ経路を終端し、ユーザ機器に関して下りリンク・データが到着する時にページングをトリガする。ＳＧＷは、ユーザ機器コンテキスト、たとえばＩＰベアラ・サービスのパラメータ、ネットワーク内部ルーティング情報を管理し、格納する。ＳＧＷは、合法的傍受（ｌａｗｆｕｌ  ｉｎｔｅｒｃｅｐｔｉｏｎ）の場合にユーザ・トラフィックの複製をも実行する。
【０００７】
ＭＭＥは、ＬＴＥアクセス・ネットワークの主要な制御ノードである。ＭＭＥは、再送信を含む、アイドル・モード・ユーザ機器の追跡およびページング手順の責任を負う。ＭＭＥは、ベアラ・アクティブ化／非アクティブ化プロセスに用いられ、初期アタッチ時およびコア・ネットワーク（ＣＮ）ノード・リロケーションを伴うＬＴＥ内ハンドオーバの時に、ユーザ機器のＳＧＷを選択する責任をも負う。ＭＭＥは、ユーザを認証する（ＨＳＳと相互作用することによって）責任を負う。非アクセス層（ＮＡＳ）シグナリングは、ＭＭＥで終端し、ＭＭＥは、一時アイデンティティを生成し、ユーザ機器に割り当てる責任をも負う。ＭＭＥは、サービス・プロバイダの公衆陸上移動ネットワーク（ＰＬＭＮ）にキャンプするためのユーザ機器の許可をチェックし、ユーザ機器ローミング制限を実施する。ＭＭＥは、ＮＡＳシグナリングに関する暗号化／完全性保護のネットワーク内の終端点であり、セキュリティ鍵管理を処理する。シグナリングの合法的傍受も、ＭＭＥによってサポートされる。ＭＭＥは、ＬＴＥアクセス・ネットワークと２Ｇ／３Ｇアクセス・ネットワークとの間のモビリティの制御プレーン機能をも提供し、ＳＧＳＮからのＳ３インターフェースは、ＭＭＥで終端する。ＭＭＥは、ローミング・ユーザ機器のホームＨＳＳに向かうＳ６ａインターフェースをも終端する。
【０００８】
＜媒体アクセス制御（ＭＡＣ）およびＭＡＣ制御要素＞
ＭＡＣレイヤは、ＬＴＥ無線プロトコル・スタックのレイヤ２アーキテクチャ内で最下のサブレイヤである（その全体が参照によって本明細書に組み込まれている、ｈｔｔｐ／／ｗｗｗ．３ｇｐｐ．ｏｒｇで入手可能な３ＧＰＰ  ＴＳ  ３６．３２１、「Ｍｅｄｉｕｍ  Ａｃｃｅｓｓ  Ｃｏｎｔｒｏｌ（ＭＡＣ）ｐｒｏｔｏｃｏｌ  ｓｐｅｃｉｆｉｃａｔｉｏｎ」、ｖｅｒｓｉｏｎ  ８．７．０、具体的にはセクション４．２、４．３、５．４．３、および６を参照されたい）。下の物理レイヤへの接続は、トランスポート・チャネルを介し、上のＲＬＣレイヤへの接続は、論理チャネルを介する。ＭＡＣレイヤは、論理チャネルとトランスポート・チャネルとの間の多重化および多重分離を実行する。送信する側（次の例ではユーザ機器）のＭＡＣレイヤは、論理チャネルを介して受信されたＭＡＣ  ＳＤＵから、トランスポート・ブロックとも称するＭＡＣ  ＰＤＵを構成し、受信する側のＭＡＣレイヤは、トランスポート・チャネルを介して受信されたＭＡＣ  ＰＤＵからＭＡＣ  ＳＤＵを回復する。
【０００９】
多重化および多重分離するエンティティ内では、複数の論理チャネルからのデータを１つのトランスポート・チャネルへ／から多重化（多重分離）することができる。多重化するエンティティは、無線リソースが新しい送信のために使用可能である時に、ＭＡＣ  ＳＤＵからＭＡＣ  ＰＤＵを生成する。このプロセスは、どの論理チャネル（１つまたは複数）からのどれほど多くのデータを各ＭＡＣ  ＰＤＵに含めるべきなのかを判断するために論理チャネルからのデータに優先順位を付けることを含む。ユーザ機器内でＭＡＣ  ＰＤＵを生成するプロセスを、３ＧＰＰ用語で論理チャネル優先順位付け（ＬＣＰ）とも称することに留意されたい。
【００１０】
多重分離するエンティティは、ＭＡＣ  ＰＤＵからＭＡＣ  ＳＤＵを再組立し、これらを適当なＲＬＣエンティティに配布する。さらに、ＭＡＣレイヤの間のピアツーピア通信について、「ＭＡＣ制御要素」と呼ばれる制御メッセージを、ＭＡＣ  ＰＤＵに含めることができる。
【００１１】
ＭＡＣ  ＰＤＵは、主にＭＡＣヘッダおよびＭＡＣペイロードからなる（３ＧＰＰ  ＴＳ  ３６．３２１、セクション６を参照されたい）。ＭＡＣヘッダは、さらに、ＭＡＣサブヘッダからなり、ＭＡＣペイロードは、ＭＡＣ制御要素、ＭＡＣ  ＳＤＵ、およびパディングからなる。各ＭＡＣサブヘッダは、論理チャネルＩＤ（ＬＣＩＤ）および長さ（Ｌ）フィールドからなる。ＬＣＩＤは、ＭＡＣペイロードの対応する部分がＭＡＣ制御要素であるかどうかを示し、そうでない場合には、関連するＭＡＣ  ＳＣＵがどの論理チャネルに属するのかを示す。Ｌフィールドは、関連するＭＡＣ  ＳＤＵまたはＭＡＣ制御要素のサイズを示す。上で既に述べたように、ＭＡＣ制御要素は、上りリンクでのＢＳＲ情報およびＵＥの使用可能電力の報告と、下りリンクでのＤＲＸコマンドおよびタイミング・アドバンス・コマンド（ｔｉｍｉｎｇ  ａｄｖａｎｃｅ  ｃｏｍｍａｎｄ）との配送を含む、ＭＡＣレベル・ピアツーピア・シグナリングに使用される。ＭＡＣ制御要素のタイプごとに、１つの特殊なＬＣＩＤが割り当てられる。ＭＡＣ  ＰＤＵの例を、図２１に示す。
【００１２】
＜電力制御＞
モバイル通信システム内の上りリンク送信器電力制御は、システムの他のユーザへの干渉を最小にし、ユーザ機器のバッテリ寿命を最大にする必要に対して、要求されるＱｏＳを達成するのに十分なビットあたりの送信エネルギの必要のバランスをとるという目的のために働く。これを達成するために、上りリンク電力制御は、経路損、シャドウイングおよび高速フェージングを含む無線伝搬チャネルの特性に適合しなければならないと同時に、同一セル内および隣接セル内の他のユーザからの干渉を克服するようにしなければならない。電力制御（ＰＣ）の役割は、隣接するセルに対して引き起こされる干渉を制御すると同時に、要求されるＳＩＮＲ（信号対干渉雑音比）を提供するのに決定的な役割をもつ。上りリンクでの古典的ＰＣ方式のアイデアは、すべてのユーザが同一ＳＩＮＲで受信されることであり、これを完全補償（ｆｕｌｌ  ｃｏｍｐｅｎｓａｔｉｏｎ）と称する。代替案として、３ＧＰＰは、ＬＴＥ  Ｒｅｌ．８／９に断片的電力制御（Ｆｒａｃｔｉｏｎａｌ  Ｐｏｗｅｒ  Ｃｏｎｔｒｏｌ／ＦＰＣ）の使用を採用した。この新しい機能性は、より高い経路損を有するユーザを、より低いＳＩＮＲ要件で動作させることで、それらのユーザが隣接するセルへ及ぼす干渉をより少なくなるようにしている。
【００１３】
ＬＴＥ  Ｒｅｌ．８／９で提供される電力制御方式は、開ループ制御と閉ループ制御との組合せを使用する。動作モードは、開ループ手段によって経路損推定に基づいて送信電力密度スペクトルの粗動作点をセットすることを含む。その後、高速動作を、閉ループ電力制御によって開ループ動作点付近で適用することができる。これにより、干渉を制御し、高速フェージングを含むチャネル条件に合わせて電力セッティングを微調整する。
【００１４】
機構のこの組合せを用いて、ＬＴＥ  Ｒｅｌ．８／９の電力制御方式は、複数の動作モードのサポートを提供する。ＬＴＥ  Ｒｅｌ．８／９の電力制御方式は、展開シナリオ、システム負荷、およびオペレータ・プリファレンスに応じた異なる電力制御戦略のツールキットと考えることができる。
【００１５】
詳細な電力制御公式は、ｈｔｔｐ：／／ｗｗｗ．３ｇｐｐ．ｏｒｇで入手可能であり、参照によって本明細書に組み込まれている３ＧＰＰ  ＴＳ  ３６．２１３、「Ｐｈｙｓｉｃａｌ  ｌａｙｅｒ  ｐｒｏｃｅｄｕｒｅｓ」、ｖｅｒｓｉｏｎ  ８．８．０のセクション５．１で、物理上りリンク共用チャネル（ＰＵＳＣＨ）、物理上りリンク制御チャネル（ＰＵＣＣＨ）、およびサウンディング基準信号（ＳＲＳ）についてＬＴＥ  Ｒｅｌ．８／９で指定されている。これらの上りリンク信号のそれぞれの公式は、同一の基本原則に従っている。すなわち、すべての場合に、それらは、２つの主要な項の合計と考えることができる。２つの主要な項とは、ｅノードＢによってシグナリングされる静的または半静的パラメータから導出される基本開ループ動作点と、サブフレームからサブフレームへと更新される動的オフセットと、である。
【００１６】
リソース・ブロックごとの送信電力の基本開ループ動作点は、セル間干渉およびセル負荷を含む複数の要因に依存する。これは、２つのコンポーネントすなわち、半静的ベース・レベルＰ０（さらに、セル内のすべてのユーザ機器の共通電力レベル（ｄＢｍ単位で測定される）およびＵＥ固有オフセットからなる）および開ループ経路損補償コンポーネントにさらに分解することができる。リソース・ブロックあたりの電力の動的オフセット部分も、さらに、２つのコンポーネントすなわちＭＣＳに依存するコンポーネントと明示的な送信器電力制御（ＴＰＣ）コマンドとに分解することができる。
【００１７】
ＭＣＳ依存コンポーネント（ＬＴＥ仕様ではΔＴＦと称し、ＴＦは、「トランスポート・フォーマット」を表す）は、リソース・ブロックあたりの送信される電力を、送信される情報データ・レートに従って適合させることを可能にする。
【００１８】
動的オフセットの他方のコンポーネントは、ＵＥ固有ＴＰＣコマンドである。これは、２つの異なるモードすなわち、累積ＴＰＣコマンド（ａｃｃｕｍｕｌａｔｉｖｅ  ＴＰＣ  ｃｏｍｍａｎｄ）（ＰＵＳＣＨ、ＰＵＣＣＨ、およびＳＲＳについて使用可能）および絶対ＴＰＣコマンド（ａｂｓｏｌｕｔｅ  ＴＰＣ  ｃｏｍｍａｎｄ）（ＰＵＳＣＨのみについて使用可能）で動作することができる。ＰＵＳＣＨについて、この２つのモードの間の切替は、ＲＲＣシグナリングによってＵＥごとに半静的となるように構成されている。すなわち、モードを動的に変更することはできない。累積ＴＰＣコマンドを用いて、各ＴＰＣコマンドは、以前のレベルに対する電力ステップをシグナリングする。モバイル通信システム内の上りリンク送信器電力制御は、システムの他のユーザへの干渉を最小にし、ユーザ機器のバッテリ寿命を最大にする必要に対して、要求されるＱｏＳを達成するのに十分なビットあたりの送信エネルギの必要のバランスをとるという目的のために働く。
【００１９】
これを達成する際に、上りリンク電力制御は、経路損、シャドウイング、および高速フェージングを含む無線伝搬チャネルの特性に適合しなければならないと同時に、同一セル内および隣接セル内の他のユーザからの干渉を克服するようにしなければならない。
【００２０】
基準サブフレームｉ内のＰＵＳＣＨ送信に関するＵＥ送信電力ＰＰＵＳＣＨ［ｄＢｍ］のセッティングは、
ＰＰＵＳＣＨ（i）＝ｍｉｎ｛ＰＣＭＡＸ，１０ｌｏｇ１０（ＭＰＵＳＣＨ（ｉ））＋ＰＯ＿ＰＵＳＣＨ（ｊ）＋α（ｊ）・ＰＬ＋ΔＴＦ（ｉ）＋ｆ（ｉ）｝    式１
によって定義される（３ＧＰＰ  ＴＳ  ３６．２１３のセクション５．１．１．１を参照されたい）。
【００２１】
−ＰＣＭＡＸは、所与の範囲内のＵＥによって選択される最大ＵＥ送信電力であり（下を参照されたい）、
−ＭＰＵＳＣＨは、割り当てられる物理リソース・ブロック（ＰＢＲ）の個数である。より多くのＰＢＲが割り当てられるほど、より多くの上りリンク送信電力が割り当てられる。
−ＰＯ＿ＰＵＳＣＨ（j）は、ＲＲＣによってシグナリングされるベース送信電力を示す。半永続的スケジューリング（ＳＰＳ）および動的スケジューリングの場合、これは、セル固有公称コンポーネントＰＯ＿ＮＯＭＩＮＡＬ＿ＰＵＳＣＨ（ｊ）∈［−１２６，…，２４］とＵＥ固有コンポーネントＰＯ＿ＵＥ＿ＰＵＳＣＨ（ｊ）∈［−１２７，…，−９６］との合計である。ＲＡＣＨメッセージ３の場合、プリアンブル送信電力からのオフセットである。
−αは、セル固有パラメータを表す（システム情報でブロードキャストされる）。このパラメータは、どれほどの経路損ＰＬが補償されるのかを示す。α＝１は、ｅノードＢでの受信信号レベルが、ユーザ機器の位置がセル・エッジ付近であろうとセル中央であろうと、その位置にかかわりなく同じであることを意味する。経路損が完全に補償される場合には、セル・エッジ・データ・レートに対する劣化が回避される。ＳＰＳおよび動的スケジューリングについて、α＝｛０，０．４，０．５，０．６，０．７，０．８，０．９，１｝であり、ＲＡＣＨメッセージ３の場合には、α（ｊ）＝１である。
−ＰＬは、基準信号受信電力（ＲＳＲＰ）測定値およびシグナリングされた基準信号（ＲＳ）送信電力に基づいてユーザ機器で導出されるＵＥ経路損である。ＰＬを、
ＰＬ＝基準信号電力−上位レイヤのフィルタリングされたＲＳＲＰ
と定義することができる。
−ΔＴＦは、変調および符号化方式（トランスポート・フォーマット）依存の電力オフセットである。したがって、これは、リソース・ブロックあたりの送信電力を、送信される情報データ・レートに従って適合させることを可能にする。
−ｆ（ｉ）は、ｅノードＢからＵＥにシグナリングされた閉ループ電力制御コマンドの関数である。ｆ（）は、累積ＴＰＣコマンドの場合に累積を表す。閉ループ・コマンドが累積（各ＴＰＣコマンドは、前のレベルに対する相対的な電力ステップをシグナリングする）または絶対（各ＴＰＣコマンドは、以前のＴＰＣコマンドのシーケンスと独立である）のどちらであるのかは、上位レイヤによって構成される。累積ＴＰＣコマンドについて、２組の電力ステップ値すなわち、ＤＣＩフォーマット３Ａ用の（−１，１）ｄＢおよびＤＣＩフォーマット３用の（−１，０＋１，＋３）ｄＢ、が提供される。絶対ＴＰＣコマンドによってシグナリングできる値の組は、ＤＣＩフォーマット３によって示される（−４，−１，１，４）ｄＢである。
【００２２】
＜電力ヘッドルーム報告＞
ｅノードＢが上りリンク送信リソースを適当な形で異なるユーザ機器にスケジューリングするのを援助するためには、ユーザ機器がその使用可能パワー・ヘッドルームをｅノードＢに報告できることが重要である。
【００２３】
ｅノードＢは、ユーザ機器がサブフレームあたりどれほどの上りリンク帯域幅を使用できるのかを判定するのに、パワー・ヘッドルーム報告を使用することができる。これは、リソースの浪費を避けるために上りリンク送信リソースを使用できないユーザ機器に、そのリソースを割り当てるのを避けるのを助ける。
【００２４】
パワー・ヘッドルーム報告の範囲は、＋４０ｄＢから−２３ｄＢまでである（ｈｔｔｐ／／ｗｗｗ．３ｇｐｐ．ｏｒｇから入手可能であり、参照によってその全体が本明細書に組み込まれている３ＧＰＰ  ＴＳ  ３６．１３３、「Ｒｅｑｕｉｒｅｍｅｎｔｓ  ｆｏｒ  ｓｕｐｐｏｒｔ  ｏｆ  ｒａｄｉｏ  ｒｅｓｏｕｒｃｅ  ｍａｎａｇｅｍｅｎｔ」、ｖｅｒｓｉｏｎ  ８．７．０、セクション９．１．８．４を参照されたい）。この範囲の負の部分は、ユーザ機器が、そのユーザ機器（ＵＥ）が使用可能であるものより多くの送信電力を要求するＵＬ許可を受信した範囲をｅノードＢにシグナリングすることを可能にする。これは、ｅノードＢが、後続許可のサイズを減らし、送信リソースを解放して他のＵＥにその送信リソースを割り当てることを可能にする。
【００２５】
パワー・ヘッドルーム報告を、ＵＥがＵＬ送信許可を有するサブフレーム内でのみ送信することができる。この報告は、それが送信されるサブフレームに関連する。したがって、ヘッドルーム報告は、直接測定値ではなく予測であり、ＵＥは、報告が送信されるサブフレームの実際の送信パワー・ヘッドルームを直接に測定することができない。したがって、ＵＥは、ＵＥの電力増幅器出力の穏当に正確な校正に頼る。
【００２６】
パワー・ヘッドルーム報告をトリガする複数の判断基準が定義されている。これらは、次を含む。
【００２７】
−最後のパワー・ヘッドルーム報告以降の推定経路損の大きい変化
−以前のパワー・ヘッドルーム報告以降に、構成された時間を超える時間が経過した
−構成された個数を超える個数の閉ループＴＰＣコマンドがＵＥによって実施された
【００２８】
ｅノードＢは、システム負荷およびそのスケジューリング・アルゴリズムの要件に応じて、これらのトリガのそれぞれを制御するためにパラメータを構成することができる。より具体的には、ＲＲＣは、２つのタイマｐｅｒｉｏｄｉｃＰＨＲ−ＴｉｍｅｒおよびｐｒｏｈｉｂｉｔＰＨＲ−Ｔｉｍｅｒを構成することと、パワー・ヘッドルーム報告をトリガするための測定された下りリンク経路損の変化をセットするｄｌ−ＰａｔｈｌｏｓｓＣｈａｎｇｅをシグナリングすることとによって、パワー・ヘッドルーム報告を制御する。
【００２９】
パワー・ヘッドルーム報告は、ＭＡＣ制御要素として送信される。パワー・ヘッドルーム報告は、最上位２ビットが予約済みであり、最下位６ビットが１ｄＢステップで上述の６４ｄＢ値を表す、単一のオクテットからなる。このＭＡＣ制御要素の構造を、図２２に示す。
【００３０】
サブフレームｉについて有効なＵＥパワー・ヘッドルームＰＨ［ｄＢ］は、
ＰＨ（ｉ）＝ＰＣＭＡＸ−｛１０・ｌｏｇ１０（ＭＰＵＳＣＨ（ｉ））＋ＰＯ＿ＰＵＳＣＨ（ｊ）＋α（ｊ）・ＰＬ＋ΔＴＦ（ｉ）＋ｆ（ｉ）｝    式２
によって定義される（３ＧＰＰ  ＴＳ  ３６．２１３のセクション５．１．１．２を参照されたい）。
【００３１】
パワー・ヘッドルームは、１ｄＢのステップで範囲［４０；−２３］ｄＢ内の最も近い値に丸められる。ＰＣＭＡＸは、総最大ＵＥ送信電力（またはユーザ機器の総最大送信電力）であり、次の制約に基づいてＰＣＭＡＸ＿ＬおよびＰＣＭＡＸ＿Ｈの所与の範囲内でユーザ機器によって選択される値である。
【００３２】
−ＰＣＭＡＸ＿Ｌ≦ＰＣＭＡＸ≦ＰＣＭＡＸ＿Ｈ
−ＰＣＭＡＸ＿Ｌ＝ｍｉｎ（ＰＥＭＡＸ−ΔＴＣ，ＰＰｏｗｅｒＣｌａｓｓ−ＭＰＲ−ＡＭＰＲ−ΔＴＣ）
−ＰＣＭＡＸ＿Ｈ＝ｍｉｎ（ＰＥＭＡＸ，ＰＰｏｗｅｒＣｌａｓｓ）
【００３３】
ＰＥＭＡＸは、ネットワークによってシグナリングされる値であり、ΔＴＣ、ＭＰＲ、およびＡＭＰＲ（Ａ−ＭＰＲ（追加最大電力削減）とも表される）は、ｈｔｔｐ／／ｗｗｗ．３ｇｐｐ．ｏｒｇから入手可能であり、参照によって本明細書に組み込まれている３ＧＰＰ  ＴＳ  ３６．１０１、「Ｅｖｏｌｖｅｄ  Ｕｎｉｖｅｒｓａｌ  Ｔｅｒｒｅｓｔｒｉａｌ  Ｒａｄｉｏ  Ａｃｃｅｓｓ（Ｅ−ＵＴＲＡ）；  Ｕｓｅｒ  Ｅｑｕｉｐｍｅｎｔ（ＵＥ）ｒａｄｉｏ  ｔｒａｎｓｍｉｓｓｉｏｎ  ａｎｄ  ｒｅｃｅｐｔｉｏｎ」、ｖｅｒｓｉｏｎ  ８．７．０、セクション６．２で指定されている。
【００３４】
ＭＰＲは、さまざまな変調方式および送信帯域幅に関連する隣接チャネル漏洩電力比（ＡＣＬＲ）を制御するのに使用される電力削減値、いわゆる最大電力削減である。隣接チャネルは、たとえば、別の拡張ユニバーサル地上無線アクセス（Ｅ−ＵＴＲＡ）チャネルまたはＵＴＲＡチャネルのいずれかである。最大の許容される電力削減（ＭＰＲ）も、３ＧＰＰ  ＴＳ  ３６．１０１で定義されている。これは、チャネル帯域幅および変調方式に依存して異なる。ユーザ機器の削減は、この最大の許容される電力削減（ＭＰＲ）値未満である。３ＧＰＰは、ユーザ機器の最大送信電力が、公称総最大送信電力からＭＰＲを引いたもの以上でありつつ、それでもＡＣＬＲ要件に従っていることを検証するＭＰＲテストを指定している。
【００３５】
次の表１に、ＵＥ電力クラス３の最大電力削減を示す。
【表１】
2020043580.tif 000002
【００３６】
たとえば、１０ＭＨｚのチャネル帯域幅の割当の場合に、１２個を超えるリソース・ブロックを割り当て、ＱＰＳＫ変調を使用する時に、ユーザ機器によって適用されるＭＰＲは、１ｄＢ以下でなければならない。ユーザ機器によって適用される実際のＭＰＲは、ＵＥの実施態様に依存し、したがって、ｅＮＢには未知である。
【００３７】
上で示したように、ＡＭＰＲは、追加最大電力削減である。ＡＭＰＲは、帯域固有であり、ネットワークによって構成される時に適用される。上の説明からわかるように、ＰＣＭＡＸは、ＵＥ実施態様固有であり、したがって、ｅノードＢには未知である。
【００３８】
図２３に、ＵＥ送信電力状況および対応するパワー・ヘッドルームの例示的なシナリオを示す。図２３の左側では、ユーザ機器は、電力制限されていない（正のＰＨＲ）が、図２３の右側では、負のパワー・ヘッドルームが、ユーザ機器の電力制限を暗示している。ＰＣＭＡＸ＿Ｌ≦ＰＣＭＡＸ≦ｍｉｎ（ＰＥＭＡＸ，ＰＰｏｗｅｒＣｌａｓｓ）であり、下界ＰＣＭＡＸ＿Ｌが、通常は主に最大電力削減ＭＰＲおよび追加最大電力削減ＡＭＰＲに依存する、すなわちＰＣＭＡＸ＿ｌ≒ＰＰｏｗｅｒＣｌａｓｓ−ＭＰＲ−ＡＭＰＲであることに留意されたい。
【００３９】
＜ＬＴＥ（リリース８）のコンポーネント・キャリア構造＞
３ＧＰＰ  ＬＴＥ（リリース８）の下りリンク・コンポーネント・キャリアは、時間周波数領域でいわゆるサブフレームに副分割される。３ＧＰＰ  ＬＴＥ（リリース８）では、各サブフレームは、図３に示されている２つの下りリンク・スロットに分割され、第１の下りリンク・スロットは、第１のＯＦＤＭシンボル内に制御チャネル領域（ＰＤＣＣＨ領域）を含む。各サブフレームは、時間領域で所与の個数のＯＦＤＭシンボルからなり（３ＧＰＰ  ＬＴＥ（リリース８）では１２個または１４個のＯＦＤＭシンボル）、ＯＦＤＭシンボルのそれぞれは、コンポーネント・キャリアの全帯域幅にまたがる。したがって、ＯＦＤＭシンボルは、それぞれ、図４にも示されているように、
【数１】
2020043580.tif 000003
個のサブキャリア上で送信される複数の変調シンボルからなる。
【００４０】
たとえば３ＧＰＰロング・ターム・エボリューション（ＬＴＥ）で使用されているように、複数キャリア通信システム、たとえばＯＦＤＭを使用すると仮定すると、スケジューラによって割り当てることのできるリソースの最小単位は、１「リソース・ブロック」である。物理リソース・ブロックは、図４に例示されているように、時間領域では
【数２】
2020043580.tif 000004
個の連続するＯＦＤＭシンボル、周波数領域では
【数３】
2020043580.tif 000005
個の連続するサブキャリアとして定義される。したがって、３ＧＰＰ  ＬＴＥ（リリース８）では、物理リソース・ブロックは、時間領域の１スロット、周波数領域の１８０ｋＨｚに対応する
【数４】
2020043580.tif 000006
個のリソース要素からなる（下りリンク・リソース・グリッドに関するさらなる詳細については、たとえば、ｈｔｔｐ：／／ｗｗｗ．３ｇｐｐ．ｏｒｇから入手可能であり、参照によって本明細書に組み込まれている３ＧＰＰ  ＴＳ  ３６．２１１、「Ｅｖｏｌｖｅｄ  Ｕｎｉｖｅｒｓａｌ  Ｔｅｒｒｅｓｔｒｉａｌ  Ｒａｄｉｏ  Ａｃｃｅｓｓ（Ｅ−ＵＴＲＡ）；Ｐｈｙｓｉｃａｌ  Ｃｈａｎｎｅｌｓ  ａｎｄ  Ｍｏｄｕｌａｔｉｏｎ（Ｒｅｌｅａｓｅ  ８）」、ｖｅｒｓｉｏｎ  ８．９．０または９．０．０、セクション６．２を参照されたい）。
【００４１】
＜レイヤ１／レイヤ２（Ｌ１／Ｌ２）制御シグナリング＞
スケジューリングされたユーザにその割当状況、トランスポート・フォーマット、および他のデータ関連情報（たとえば、ＨＡＲＱ情報、ｔｒａｎｓｍｉｔ  ｐｏｗｅｒ  ｃｏｎｔｒｏｌ（ＴＰＣ）コマンド）について知らせるために、Ｌ１／Ｌ２制御シグナリングが、データと一緒に下りリンク上で送信される。Ｌ１／Ｌ２制御シグナリングは、ユーザ割当がサブフレームごとに変化する可能性があると仮定して、サブフレーム内で下りリンク・データと多重化される。ユーザ割当をＴＴＩ（送信時間間隔）を基礎として実行することもでき、ＴＴＩ長がサブフレームの倍数であることに留意されたい。ＴＴＩ長は、あるサービス・エリア内ですべてのユーザについて固定される場合があり、異なるユーザについて異なる場合があり、あるいは、ユーザごとに動的である場合さえある。一般に、Ｌ１／２制御シグナリングは、ＴＴＩごとに１回送信されることだけを必要とする。Ｌ１／Ｌ２制御シグナリングは、物理下りリンク制御チャネル（ＰＤＣＣＨ）上で送信される。３ＧＰＰ  ＬＴＥでは、上りリンク・スケジューリング許可または上りリンク・リソース割当とも称する上りリンク・データ送信の割当も、ＰＤＣＣＨ上で送信されることに留意されたい。
【００４２】
スケジューリング許可に関して、Ｌ１／Ｌ２制御シグナリング上で送信される情報を、次の２つのカテゴリに分離することができる。
【００４３】
Ｃａｔ  １情報を搬送する共用制御情報（ＳＣＩ）
Ｌ１／Ｌ２制御シグナリングの共用制御情報部分は、リソース割当（表示）に関連する情報を含む。共用制御情報は、通常は次の情報を含む。
−リソースに割り当てられるユーザ（１つまたは複数）を示すユーザ・アイデンティティ。
−ユーザ（１つまたは複数）が割り当てられるリソース（リソース・ブロック（ＲＢ））を示すＲＢ割当情報。割り当てられるリソース・ブロックの個数を、動的とすることができる。
−複数のサブフレーム（またはＴＴＩ）にまたがる割当が可能である場合には、割当の持続時間（任意選択）。
【００４４】
他のチャネルのセットアップおよび下りリンク制御情報（ＤＣＩ）（下を参照されたい）のセットアップに依存して、共用制御情報は、さらに、上りリンク送信のＡＣＫ／ＮＡＣＫ、上りリンク・スケジューリング情報、ＤＣＩに関する情報（リソース、ＭＣＳなど）などの情報を含むことができる。
【００４５】
Ｃａｔ  ２／３情報を搬送する下りリンク制御情報（ＤＣＩ）
Ｌ１／Ｌ２制御シグナリングの下りリンク制御情報部分は、Ｃａｔ  １情報によって示されるスケジューリングされたユーザに送信されるデータの送信フォーマットに関連する情報（Ｃａｔ  ２情報）を含む。さらに、再送信プロトコルとして（ハイブリッド）ＡＲＱを使用する場合には、Ｃａｔ  ２情報は、ＨＡＲＱ（Ｃａｔ  ３）情報を搬送する。下りリンク制御情報は、Ｃａｔ  １に従ってスケジューリングされたユーザによって復号されることだけを必要とする。下りリンク制御情報は、通常は次に関する情報を含む。
【００４６】
−Ｃａｔ  ２情報：  変調方式、トランスポート・ブロック（ペイロード）サイズまたは符号化レート、ＭＩＭＯ（多重入力・多重出力）関連情報など。トランスポート・ブロック（またはペイロード・サイズ）または符号レートのいずれかをシグナリングすることができる。どの場合でも、これらのパラメータを、変調方式情報およびリソース情報（割り当てられたリソース・ブロックの個数）を使用することによって、お互いから計算することができる。
−Ｃａｔ  ３情報：  ＨＡＲＱ関連情報、たとえば、ハイブリッドＡＲＱプロセス番号、冗長性バージョン、再送信シーケンス番号
【００４７】
下りリンク制御情報は、全体的なサイズおよびそのフィールドに含まれる情報において異なる複数のフォーマットで現れる。ＬＴＥ  リリース８／９（３ＧＰＰ  ＬＴＥ）に関して現在定義されている異なるＤＣＩフォーマットは、３ＧＰＰ  ＴＳ  ３６．２１２、「Ｍｕｌｔｉｐｌｅｘｉｎｇ  ａｎｄ  ｃｈａｎｎｅｌ  ｃｏｄｉｎｇ（Ｒｅｌｅａｓｅ  ９）」、ｖｅｒｓｉｏｎ  ８．８．０または９．０．０、セクション５．３．３．１（ｈｔｔｐ：／／ｗｗｗ．３ｇｐｐ．ｏｒｇから入手可能であり、参照によって本明細書に組み込まれている）に詳細に記載されている。
【００４８】
下りリンクおよび上りリンクのデータ送信
下りリンク・データ送信に関して、Ｌ１／Ｌ２制御シグナリングは、下りリンク・パケット・データ送信と一緒に、別々の物理チャネル（ＰＤＣＣＨ）上で送信される。このＬ１／Ｌ２制御シグナリングは、通常は次に関する情報を含む。
【００４９】
−データが送信される物理リソース（１つまたは複数）（たとえば、ＯＦＤＭの場合にはサブキャリアまたはサブキャリアブロック、ＣＤＭＡの場合には符号）。この情報は、ＵＥ（受信器）が、データが送信されるリソースを識別することを可能にする。
【００５０】
−ユーザ機器が、Ｌ１／Ｌ２制御シグナリング内にキャリア指示フィールド（ＣＩＦ）を有するように構成される時には、この情報は、特定の制御シグナリング情報が対象としているコンポーネント・キャリアを特定する。これは、別のコンポーネント・キャリアを対象とした割当を、ある１つのコンポーネント・キャリアで送信することを可能にする（「クロスキャリア・スケジューリング」）。この他方のクロススケジューリングされるコンポーネント・キャリアは、たとえば、ＰＤＣＣＨのないコンポーネント・キャリアであり得る。すなわち、クロススケジューリングされるコンポーネント・キャリアは、Ｌ１／Ｌ２制御シグナリングを全く搬送しない。
【００５１】
−送信に使用されるトランスポート・フォーマット。これは、データのトランスポート・ブロック・サイズ（ペイロード・サイズ、情報ビット・サイズ）、ＭＣＳ（変調および符号化スキーム）レベル、スペクトル効率、符号レートなどであり得る。この情報は（通常は、リソース割当（たとえば、ユーザ機器に割り当てられたリソース・ブロックの個数）と一緒に）、ユーザ機器（受信器）が、復調、デレートマッチング、および復号プロセスを開始するために、情報ビット・サイズ、変調方式、および符号レートを識別することを可能にする。変調方式を、明示的にシグナリングすることができる。
【００５２】
−ハイブリッドＡＲＱ（ＨＡＲＱ）情報
・ＨＡＲＱプロセス番号：  ユーザ機器が、データがマッピングされるハイブリッドＡＲＱプロセスを識別することを可能にする。
・シーケンス番号または新データ・インジケータ（ＮＤＩ）：  ユーザ機器が、送信が新しいパケットまたは再送信されたパケットであるかどうかを識別することを可能にする。ソフト合成がＨＡＲＱプロトコル内で実施される場合には、シーケンス番号または新データ・インジケータは、ＨＡＲＱプロセス番号と一緒に、復号の前のＰＤＵの送信のソフト合成を可能にする。
・冗長性および／またはコンステレーション・バージョン：  どのハイブリッドＡＲＱ冗長性バージョンが使用されるのか（デレートマッチングに必要）および／またはどの変調コンステレーション・バージョンが使用されるのか（復調に必要）をユーザ機器に知らせる。
【００５３】
−ＵＥアイデンティティ（ＵＥ  ＩＤ）：  Ｌ１／Ｌ２制御シグナリングがどのユーザ機器に向けたものであるのかを知らせる。通常の実施態様では、この情報は、他のユーザ機器がこの情報を読み取るのを防ぐために、Ｌ１／Ｌ２制御シグナリングのＣＲＣをマスクするのに使用される。
【００５４】
上りリンク・パケット・データ送信を可能にするために、Ｌ１／Ｌ２制御シグナリングは、下りリンク（ＰＤＣＣＨ）で送信され、送信詳細についてユーザ機器に知らせる。このＬ１／Ｌ２制御シグナリングは、通常、次に関する情報を含む。
【００５５】
−ユーザ機器がデータを送信しなければならない物理リソース（１つまたは複数）（たとえば、ＯＦＤＭの場合にはサブキャリアまたはサブキャリアブロック、ＣＤＭＡの場合にはコード）。
【００５６】
−ユーザ機器が、Ｌ１／Ｌ２制御シグナリング内にキャリア指示フィールド（ＣＩＦ）を有するように構成される時には、この情報は、特定の制御シグナリング情報が対象としているコンポーネント・キャリアを特定する。これは、別のコンポーネント・キャリアを対象とした割当を、ある１つのコンポーネント・キャリアで送信することを可能にする。この他方のクロススケジューリングされるコンポーネント・キャリアは、たとえば、ＰＤＣＣＨのないコンポーネント・キャリアであり得る。すなわち、クロススケジューリングされるコンポーネント・キャリアは、Ｌ１／Ｌ２制御シグナリングを全く搬送しない。
【００５７】
−上りリンク許可のためのＬ１／Ｌ２制御シグナリングは、上りリンク・コンポーネント・キャリアにリンクされたＤＬコンポーネント・キャリアで、または、複数のＤＬコンポーネント・キャリアが同一のＵＬコンポーネント・キャリアにリンクされる場合には複数のＤＬコンポーネント・キャリアのうちの１つで、送信される。
【００５８】
−ユーザ機器が送信に使用しなければならないトランスポート・フォーマット。これは、データのトランスポート・ブロック・サイズ（ペイロード・サイズ、情報ビット・サイズ）、ＭＣＳ（変調および符号化スキーム）レベル、スペクトル効率、符号レートなどとすることができる。この情報は（通常は、リソース割当（たとえば、ユーザ機器に割り当てられたリソース・ブロックの個数）と一緒に）、ユーザ機器（送信器）が、変調、レートマッチング、および符号化プロセスを開始するために、情報ビット・サイズ、変調方式、および符号レートを選ぶことを可能にする。いくつかの場合に、変調方式を、明示的にシグナリングすることができる。
【００５９】
−ハイブリッドＡＲＱ情報
・ＨＡＲＱプロセス番号：  ユーザ機器がどのハイブリッドＡＲＱプロセスからデータを選択しなければならないのかをユーザ機器に知らせる。
・シーケンス番号または新データ・インジケータ（ＮＤＩ）：  新しいパケットを送信しまたはパケットを再送信するようにユーザ機器に命ずる。ソフト合成がＨＡＲＱプロトコル内で実施される場合には、シーケンス番号または新データ・インジケータは、ＨＡＲＱプロセス番号と一緒になって、復号の前にプロトコル・データ・ユニット（ＰＤＵ）のための送信のソフト合成を可能にする。
・冗長性および／またはコンステレーション・バージョン：  どのハイブリッドＡＲＱ冗長性バージョンを使用すべきなのか（レートマッチングに必要）および／またはどの変調コンステレーション・バージョンを使用すべきなのか（変調に必要）をユーザ機器に知らせる。
【００６０】
−ＵＥアイデンティティ（ＵＥ  ＩＤ）：  どのユーザ機器がデータを送信しなければならないのかを知らせる。通常の実施態様では、この情報は、他のユーザ機器がこの情報を読み取るのを防ぐために、Ｌ１／Ｌ２制御シグナリングのＣＲＣをマスクするのに使用される。
【００６１】
上で言及した情報を上りリンク・データ送信および下りリンク・データ送信で正確にどのように送信すべきかに関する複数の異なる特色がある。さらに、上りリンクおよび下りリンクでは、Ｌ１／Ｌ２制御情報は、追加情報をも含むことができ、あるいは、情報の一部を省略することができる。たとえば、
−同期ＨＡＲＱプロトコルの場合に、ＨＡＲＱプロセス番号は、必要ではない場合がある、すなわち、シグナリングされない。
−チェース・コンバイニング（Ｃｈａｓｅ  Ｃｏｍｂｉｎｉｎｇ）が使用される（必ず同一の冗長性および／またはコンステレーション・バージョン）場合あるいは冗長性および／またはコンステレーション・バージョンのシーケンスが事前に定義される場合には、冗長性および／またはコンステレーション・バージョンが、必要ではなく、したがってシグナリングされない場合がある。
−電力制御情報が、さらに、制御シグナリングに含まれる場合がある。
−たとえばプリコーディングなど、ＭＩＭＯ関連制御情報が、さらに、制御シグナリングに含まれる場合がある。
−マルチコードＭＩＭＯ送信の場合に、マルチコードのトランスポート・フォーマットおよび／またはＨＡＲＱ情報が含まれる場合がある。
【００６２】
ＬＴＥにおいてＰＤＣＣＨでシグナリングされる上りリンク・リソース割当（物理上りリンク共用チャネル（ＰＵＳＣＨ））については、ＬＴＥ上りリンクには同期ＨＡＲＱプロトコルが使用されるので、Ｌ１／Ｌ２制御情報は、ＨＡＲＱプロセス番号を含まない。上りリンク送信に使用されるＨＡＲＱプロセスは、タイミングによって与えられる。さらに、冗長性バージョン（ＲＶ）情報が、トランスポート・フォーマット情報と共に合同で符号化される、すなわち、ＲＶ情報が、トランスポート・フォーマット（ＴＦ）フィールドに組み込まれることに留意されたい。トランスポート・フォーマット（ＴＦ）すなわち変調および符号化スキーム（ＭＣＳ）フィールドそれぞれは、たとえば、３２個のエントリに対応する５ビットのサイズを有する。３つのＴＦ／ＭＣＳテーブル・エントリが、冗長性バージョン（ＲＶ）１、２、または３を示すために予約される。残りのＭＳＣテーブル・エントリは、暗黙のうちにＲＶ０を示すＭＣＳレベル（ＴＢＳ）をシグナリングするのに使用される。ＰＤＣＣＨのＣＲＣフィールドのサイズは、１６ビットである。
【００６３】
ＬＴＥではＰＤＣＣＨでシグナリングされる下りリンク割当（ＰＤＳＣＨ）については、冗長バージョン（ＲＶ）は、別々に２ビット・フィールド内でシグナリングされる。さらに、変調オーダー情報が、トランスポート・フォーマット情報と共に合同で符号化される。上りリンクの場合に似て、ＰＤＣＣＨでシグナリングされる５ビットＭＳＣフィールドがある。エントリのうちの３つは、トランスポート・フォーマット（トランスポート・ブロック）情報を提供せずに明示的な変調オーダーをシグナリングするために予約される。残りの２９のエントリについて、変調オーダーおよびトランスポート・ブロック・サイズ情報がシグナリングされる。
【００６４】
物理下りリンク制御チャネル（ＰＤＣＣＨ）
物理下りリンク制御チャネル（ＰＤＣＣＨ）は、Ｌ１／Ｌ２制御シグナリング、すなわち送信電力制御コマンドと、下りリンク・データ送信または上りリンク・データ送信のリソースを割り当てるスケジューリング許可とを搬送する。より正確には、下りリンク制御チャネル情報（すなわち、それぞれ、ＤＣＩ内容またはＬ１／Ｌ２制御シグナリング情報）は、それに対応する物理チャネルであるＰＤＣＣＨにマッピングされる。この「マッピング」は、下でより詳細に説明するように、ＲＮＴＩを用いてマスクされる下りリンク制御チャネル情報に基づいて計算されるＣＲＣである下りリンク制御チャネル情報のＣＲＣアタッチメントの決定を含む。下りリンク制御チャネル情報およびそのＣＲＣアタッチメントは、その後、ＰＤＣＣＨで送信される（３ＧＰＰ  ＴＳ  ３６．２１２、セクション４．２および５．３．３を参照されたい）。
【００６５】
各スケジューリング許可は、制御チャネル要素（Ｃｏｎｔｒｏｌ  Ｃｈａｎｎｅｌ  Ｅｌｅｍｅｎｔ（ＣＣＥ））に基づいて定義される。各ＣＣＥは、１組のリソース要素（ＲＥ）に対応する。３ＧＰＰ  ＬＴＥでは、１つのＣＣＥは、９個のリソース要素グループ（ＲＥＧ）からなり、１つのＲＥＧは、４つのＲＥからなる。
【００６６】
ＰＤＣＣＨは、あるサブフレーム内の最初の１つから３つまでのＯＦＤＭシンボルで送信される。下りリンク共有物理チャネル（ＰＤＳＣＨ）の下りリンク許可については、ＰＤＣＣＨは、同一サブフレーム内の（ユーザ）データのためにＰＤＳＣＨリソースを割り当てる。あるサブフレーム内のＰＤＣＣＨ制御チャネル領域は、１組のＣＣＥからなり、サブフレームの制御領域内のＣＣＥの総数は、時間および周波数制御リソース全体に分散される。複数のＣＣＥを組み合わせて、制御チャネルの符号化レートを効果的に下げることができる。ＣＣＥは、異なる符号化レートを達成するために木構造を使用する所定の形で組み合わされる。
【００６７】
３ＧＰＰ  ＬＴＥ（リリース８／９）では、ＰＤＣＣＨは、１つ、２つ、４つ、または８つのＣＣＥをアグリゲートすることができる。制御チャネル割当に使用可能なＣＣＥの数は、キャリア帯域幅、送信アンテナの個数、制御に使用されるＯＦＤＭシンボルの個数、およびＣＣＥサイズなどを含む複数の因子からなる関数である。複数のＰＤＣＣＨを１つのサブフレーム内で送信することができる。
【００６８】
ＤＣＩの形の下りリンク制御チャネル情報は、あるＲＮＴＩ（Ｒａｄｉｏ  Ｎｅｔｗｏｒｋ  Ｔｅｒｍｉｎａｌ  Ｉｄｅｎｔｉｆｉｅｒ）のための下りリンク・スケジューリング情報または上りリンク・スケジューリング情報、非周期的ＣＱＩ報告の要求、または上りリンク電力制御コマンドをトランスポートする。ＲＮＴＩは、データまたは情報を特定のユーザ機器に向けるために、３ＧＰＰ  ＬＴＥ（リリース８／９）などの３ＧＰＰシステムで一般的に使用される一意識別子である。ＲＮＴＩは、ＤＣＩを用いて計算されたＣＲＣをＲＮＴＩでマスクすることによって、ＰＤＣＣＨ内に暗黙のうちに含められる。この動作の結果が、上で言及したＣＲＣアタッチメントである。ユーザ機器の側では、データのペイロード・サイズの復号が成功した場合に、ユーザ機器は、そのユーザ機器宛のＤＣＩを検出する。このＤＣＩの検出は、「マスクされない」ＣＲＣ（すなわち、ＲＮＴＩを用いたマスキングを除去した後のＣＲＣ）を用いている、復号されたペイロード・データのＣＲＣが成功であるかどうかをチェックすることによって行う。ＣＲＣ符号のマスキングは、たとえば、ＲＮＴＩを用いてＣＲＣをスクランブルすることによって実行される。
【００６９】
３ＧＰＰ  ＬＴＥ（リリース８）では、次の異なるＤＣＩフォーマットが定義されている。
【００７０】
−上りリンクＤＣＩフォーマット：
・フォーマット０は、ＵＬ  ＳＣＨ割当の送信に使用される
・フォーマット３は、２ビット電力調整と共にＰＵＣＣＨおよびＰＵＳＣＨのＴＰＣコマンドの送信に使用される（複数のＵＥがアドレッシングされる）
・フォーマット３Ａは、単一ビット電力調整と共にＰＵＣＣＨおよびＰＵＳＣＨのＴＰＣコマンドの送信に使用される（複数のＵＥがアドレッシングされる）
【００７１】
−下りリンクＤＣＩフォーマット：
・フォーマット１は、ＳＩＭＯ動作のＤＬ  ＳＣＨ割当の送信に使用される
・フォーマット１Ａは、ＳＩＭＯ動作のＤＬ  ＳＣＨ割当のコンパクト送信に使用される
・フォーマット１Ｂは、連続的なリソース割当の可能性のある、閉ループ単一ランク送信をサポートするのに使用される
・フォーマット１Ｃは、ページング、ＲＡＣＨ応答、および動的ＢＣＣＨスケジューリングの、下りリンク送信のためのものである
・フォーマット１Ｄは、プリコーディングおよび電力オフセット情報を伴う１つのＰＤＳＣＨ符号語のコンパクト・スケジューリングに使用される
・フォーマット２は、閉ループＭＩＭＯ動作のＤＬ−ＳＣＨ割当の送信に使用される
・フォーマット２Ａは、開ループＭＩＭＯ動作のＤＬ−ＳＣＨ割当の送信に使用される
【００７２】
下りリンクでのＬＴＥ物理チャネル構造、ＰＤＳＣＨフォーマット、およびＰＤＣＣＨフォーマットに関するさらなる情報については、Ｓｔｅｆａｎｉａ  Ｓｅｓｉａ他、「ＬＴＥ  −  Ｔｈｅ  ＵＭＴＳ  ロング・ターム・エボリューション」、Ｗｉｌｅｙ  ＆  Ｓｏｎｓ  Ｌｔｄ．、ＩＳＢＮ  ９７８−０−４７０６９７１６−０、２００９年４月、セクション６および９を参照されたい。
【００７３】
＜ユーザ機器でのＰＤＣＣＨのブラインド復号＞
３ＧＰＰ  ＬＴＥ（リリース８／９）では、ユーザ機器は、いわゆる「ブラインド復号」を使用してＰＤＣＣＨ内のＤＣＩを検出することを試みる。これは、下りリンクでシグナリングされるＰＤＣＣＨのＣＣＥアグリゲーションサイズまたは変調・符号化方式を示す関連する制御シグナリングがないことを意味するが、ユーザ機器は、ＣＣＥアグリゲーションサイズと変調・符号化方式とのすべての可能な組合せについてテストし、ＲＮＴＩに基づくＰＤＣＣＨの成功の復号を確認する。複雑さをさらに制限するために、ＬＴＥコンポーネント・キャリアの制御シグナリング領域内に、ユーザ機器がＰＤＣＣＨを検索するための共通および専用の検索空間が、定義されている。
【００７４】
３ＧＰＰ  ＬＴＥ（リリース８／９）では、ＰＤＣＣＨペイロード・サイズは、１つのブラインド復号の試みで検出される。ユーザ機器は、下の表１で強調されているように、すべての構成された送信モードについて２つの異なるペイロード・サイズを復号することを試みる。表１は、ＤＣＩフォーマット０、１Ａ、３、および３Ａのペイロード・サイズＸが、送信モード構成にかかわりなく同一であることを示す。他のＤＣＩフォーマットのペイロード・サイズは、送信モードに依存する。
【００７５】
【表２】
2020043580.tif 000007
【００７６】
したがって、ユーザ機器は、第１のブラインド復号の試みでＤＣＩのペイロード・サイズをチェックすることができる。さらに、ユーザ機器は、処理量の増加を抑制するために、ＤＣＩフォーマットの所与のサブセットのみを検索するようにさらに構成される。
【００７７】
＜Ｆｕｒｔｈｅｒ  Ａｄｖａｎｃｅｍｅｎｔｓ  ｆｏｒ  ＬＴＥ（ＬＴＥ−Ａ）＞
ＩＭＴ−Ａｄｖａｎｃｅｄの周波数スペクトルは、Ｗｏｒｌｄ  Ｒａｄｉｏｃｏｍｍｕｎｉｃａｔｉｏｎ  Ｃｏｎｆｅｒｅｎｃｅ  ２００７（ＷＲＣ−０７）で決定された。ＩＭＴ−Ａｄｖａｎｃｅｄの全体的な周波数スペクトルが決定されたが、実際の使用可能周波数帯域幅は、各地域または国によって異なる。しかし、使用可能周波数スペクトル概要が決定された後に、無線インターフェースの標準化が、３ｒｄ  Ｇｅｎｅｒａｔｉｏｎ  Ｐａｒｔｎｅｒｓｈｉｐ  Ｐｒｏｊｅｃｔ（３ＧＰＰ）で開始された。３ＧＰＰ  ＴＳＧ  ＲＡＮ  ＃３９会議では、「Ｆｕｒｔｈｅｒ  Ａｄｖａｎｃｅｍｅｎｔｓ  ｆｏｒ  Ｅ−ＵＴＲＡ（ＬＴＥ−Ａｄｖａｎｃｅｄ）」に関するスタディ・アイテム（Ｓｔｕｄｙ  Ｉｔｅｍ）記述が、３ＧＰＰで承認された。このスタディ・アイテムは、たとえばＩＭＴ−Ａｄｖａｎｃｅｄでの要件を満たし、Ｅ−ＵＴＲＡの進歩のために考慮すべき技術要素をカバーするものである。ＬＴＥ−Ａについて現在考慮されている２つの主要な技術要素を、次で説明する。
【００７８】
＜より広い帯域幅をサポートするためのＬＴＥ−Ａでのキャリア・アグリゲーション＞
キャリア・アグリゲーション（ＣＡ）では、複数のコンポーネント・キャリア（ＣＣ）が、１００ＭＨｚまでのより広い送信帯域幅をサポートするためにアグリゲートされる。少なくとも上りリンクおよび下りリンクでアグリゲートされるコンポーネント・キャリアの個数が同一である時に、すべてのコンポーネント・キャリアを、３ＧＰＰ  ＬＴＥ  リリース８／９互換になるように構成することができる。これは、必ずしも、すべてのコンポーネント・キャリアが３ＧＰＰ  ＬＴＥ（リリース８／９）互換である必要があることを意味するのではない。
【００７９】
ユーザ機器は、１つまたは複数のコンポーネント・キャリア上で同時に受信しまたは送信することができる。何個のコンポーネント・キャリア上で同時受信／送信が可能であるのかは、ユーザ機器の能力に依存する。
【００８０】
３ＧＰＰ  ＬＴＥ（リリース８／９）互換ユーザ機器は、ＣＣの構造が３ＧＰＰ  ＬＴＥ（リリース８／９）仕様に従うならば、単一のＣＣ上でのみ受信し、送信することができるが、キャリア・アグリゲーションのための受信能力および／または送信能力を有する３ＧＰＰ  ＬＴＥ−Ａ（リリース１０）互換ユーザ機器は、複数のコンポーネント・キャリア上で同時に受信し、かつ／または送信することができる。
【００８１】
キャリア・アグリゲーションは、連続するコンポーネント・キャリアと連続しないコンポーネント・キャリアとの両方についてサポートされ、各コンポーネント・キャリアは、３ＧＰＰ  ＬＴＥ（リリース８／９）数秘術（ｎｕｍｅｒｏｌｏｇｙ）を使用すると、周波数領域で最大１１０個のリソース・ブロックに制限される。
【００８２】
同一のｅノードＢ（基地局）から発する、おそらくは上りリンクおよび下りリンクで異なる帯域幅を有する異なる個数のコンポーネント・キャリアをアグリゲートするように、３ＧＰＰ  ＬＴＥ−Ａ（リリース１０）互換ユーザ機器を構成することが可能である。構成できる下りリンク・コンポーネント・キャリアの個数は、ＵＥの下りリンク・アグリゲーション能力に依存する。逆に、構成できる上りリンク・コンポーネント・キャリアの個数は、ＵＥの上りリンク・アグリゲーション能力に依存する。下りリンク・コンポーネント・キャリアより多数の上りリンク・コンポーネント・キャリアを用いてＵＥを構成することは、可能ではない可能性がある。通常のＴＤＤの配置では、上りリンクおよび下りリンクのコンポーネント・キャリアの個数および各コンポーネント・キャリアの帯域幅は、同一である。同一のｅノードＢから発するコンポーネント・キャリアが、同一のカバレージを提供する必要はない。
【００８３】
連続してアグリゲートされるコンポーネント・キャリアの中心周波数の間の間隔は、３００ｋＨｚの倍数でなければならない。これは、３ＧＰＰ  ＬＴＥ（リリース８／９）の１００ｋＨｚ周波数ラスタと互換にするためであり、かつ、１５ｋＨｚ間隔を有するサブキャリアの直交性を維持するためである。アグリゲーション・シナリオに依存して、ｎ×３００ｋＨｚ間隔は、連続するコンポーネント・キャリアの間に少数の未使用サブキャリアを挿入することによって容易に実現できる。
【００８４】
複数キャリアのアグリゲーションの性質は、ＭＡＣレイヤまでしか及ばない。上りリンクと下りリンクとの両方について、アグリゲートされるコンポーネント・キャリアごとにＭＡＣで要求される１つのＨＡＲＱエンティティがある。（上りリンクのＳＵ−ＭＩＭＯの不在の下で）コンポーネント・キャリアあたり多くとも１つのトランスポート・ブロックがある。トランスポート・ブロックおよびその潜在的ＨＡＲＱ再送信は、同一のコンポーネント・キャリアにマッピングされる必要がある。
【００８５】
アクティブ化されたキャリア・アグリゲーションを有するレイヤ２構造を、それぞれ下りリンクおよび上りリンクについて図５および図６に示す。
【００８６】
キャリア・アグリゲーションが構成される時に、ユーザ機器は、ネットワークと１つのＲＲＣ接続をもつだけである。ＲＲＣ接続確立／再確立時に、１つのセルが、ＬＴＥ  Ｒｅｌ．  ８／９と同様に、セキュリティ入力（１つのＥＣＧＩ、１つのＰＣＩ、および１つのＡＲＦＣＮ）および非アクセス層モビリティ情報（たとえば、ＴＡＩ）を提供する。ＲＲＣ接続確立／再確立の後に、そのセルに対応するコンポーネント・キャリアが、下りリンク・プライマリ・セル（Ｐｒｉｍａｒｙ  Ｃｅｌｌ、ＰＣｅｌｌ）と称される。常に、接続モードでユーザ機器あたり、１つの下りリンクＰＣｅｌｌ（ＤＬ  ＰＣｅｌｌ）および１つの上りリンクＰＣｅｌｌ（ＵＬ  ＰＣｅｌｌ）だけが構成される。コンポーネント・キャリアの構成された組の中で、他のセルは、セカンダリ・セル（Ｓｅｃｏｎｄａｒｙ  Ｃｅｌｌ、ＳＣｅｌｌ）と称される。下りリンクＰＣｅｌｌおよび上りリンクＰＣｅｌｌの特性は、次の通りである。
【００８７】
−上りリンクＰＣｅｌｌは、レイヤ１上りリンク制御情報の送信に使用される。
−下りリンクＰＣｅｌｌを非アクティブ化することはできない。
−下りリンクＳＣｅｌｌがレイリー・フェージング（ＲＬＦ）を受ける時ではなく、下りリンクＰＣｅｌｌがＲＬＦを受ける時に、再確立がトリガされる。
−下りリンクＰＣｅｌｌセルは、ハンドオーバに伴って変化する可能性がある。
−非アクセス層情報は、下りリンクＰＣｅｌｌからとられる。
【００８８】
コンポーネント・キャリアの再構成、追加、および除去は、ＲＲＣによって実行することができる。ＬＴＥ内ハンドオーバ時に、ＲＲＣは、ターゲット・セル内での使用のためにコンポーネント・キャリアを追加し、除去し、または再構成することもできる。新しいコンポーネント・キャリアを追加する時に、専用ＲＲＣシグナリングが、コンポーネント・キャリアのシステム情報を送信するのに使用され、この情報は、コンポーネント・キャリア送信／受信に必要である（ハンドオーバに関してＲｅｌ−８／９と同様）。
【００８９】
ユーザ機器が、キャリア・アグリゲーションを用いて構成される時には、常にアクティブである上りリンク・コンポーネント・キャリアおよび下りリンク・コンポーネント・キャリアの１つの対がある。その対の下りリンク・コンポーネント・キャリアは、「ＤＬアンカ・キャリア（ａｎｃｈｏｒ  ｃａｒｒｉｅｒ）」とも称される場合がある。同一のことが、上りリンクにもあてはまる。
【００９０】
キャリア・アグリゲーションが構成される時に、ユーザ機器は複数のコンポーネント・キャリアにまたがって同時にスケジューリングされ得るが、どの時にもせいぜい１つのランダム・アクセス手順が進行中でなければならない。クロスキャリア・スケジューリングは、コンポーネント・キャリアのＰＤＣＣＨが別のコンポーネント・キャリア上でリソースをスケジューリングすることを可能にする。こうするために、コンポーネント・キャリア識別フィールドが、それぞれのＤＣＩフォーマットに導入される。
【００９１】
上りリンク・コンポーネント・キャリアと下りリンク・コンポーネント・キャリアとの間でリンクすることは、クロスキャリア・スケジューリングがない時に、許可が適用される上りリンク・コンポーネント・キャリアを識別することを可能にする。
【００９２】
上りリンク・コンポーネント・キャリアへの下りリンク・コンポーネント・キャリアのリンケージは、必ずしも１対１である必要がない。言い替えると、複数の下りリンク・コンポーネント・キャリアが、同一の上りリンク・コンポーネント・キャリアにリンクすることができる。下りリンク・コンポーネント・キャリアは、同時に１つの上りリンク・コンポーネント・キャリアだけにリンクすることができる。図７および８に、下りリンク・コンポーネント・キャリアと上りリンク・コンポーネント・キャリアとの間の可能なリンケージを例示的に示す。図７では、すべての下りリンク・コンポーネント・キャリアが、同一の上りリンク・コンポーネント・キャリアにリンクされるが、図８では、下りリンク・コンポーネント・キャリア１および２が、上りリンク・コンポーネント・キャリア１にリンクされ、下りリンク・コンポーネント・キャリア３が、上りリンク・コンポーネント・キャリア２にリンクされる。
【００９３】
＜ＤＲＸおよびキャリア・アグリゲーション＞
ユーザ機器の適度なバッテリ消費を提供するために、３ＧＰＰ  ＬＴＥ（リリース８／９）ならびに３ＧＰＰ  ＬＴＥ−Ａ（リリース１０）は、不連続受信（ＤＲＸ）の概念を提供する。
【００９４】
この概念について、次の用語が、ＤＲＸに関するユーザ機器の状態を記述する。
【００９５】
−オン持続時間：  ＤＲＸからウェイク・アップした後に、ユーザ機器がＰＤＣＣＨを受信するために待つ、下りリンク・サブフレーム単位での持続時間。ユーザ機器がＰＤＣＣＨを成功して復号する場合には、ユーザ機器は、アウェイクしたままになり、インアクティビティ・タイマを始動する。
【００９６】
−インアクティビティ・タイマ：  ＰＤＣＣＨの最後の成功の復号（これに失敗する場合にはＤＲＸに再入する）からの、ユーザ機器がＰＤＣＣＨを成功して復号するために待つ、下りリンク・サブフレーム単位の持続時間。ユーザ機器は、最初の送信の間に限ってＰＤＣＣＨの単一の成功の復号の後にインアクティビティ・タイマを再始動しなければならない（すなわち、再送信の間には再始動しない）。
【００９７】
−アクティブ時間：  ユーザ機器がアウェイクしている総持続時間。これは、ＤＲＸサイクルの「オン持続時間」、インアクティビティ・タイマが満了していない間にユーザ機器が連続受信を実行している時間、およびユーザ機器が１つのＨＡＲＱ  ＲＴＴ（ラウンド・トリップ時間）の後に下りリンク再送信を待っている間に連続受信を実行している時間を含む。上記に基づいて、最小アクティブ時間はオン持続時間と等しい長さを有し、最大アクティブ時間は未定義（無限）である。
【００９８】
ユーザ機器あたり１つのＤＲＸサイクルだけが存在する。すべてのアグリゲートされるコンポーネント・キャリアは、このＤＲＸパターンに従う、すなわち、同一のＤＲＸ動作が、すべての構成のアクティブ化されたコンポーネント・キャリアにあてはまる（たとえば、ＰＤＣＣＨ監視のための同一のアクティブ時間）。アクティブ時間内では、すべてのコンポーネント・キャリアは、必ず、任意の他の構成のアクティブ化されたコンポーネント・キャリア上でＰＤＳＣＨをスケジューリングすることができる（さらなる制約ＦＦＳ）。
【００９９】
キャリア・アグリゲーションが構成される時のさらなるバッテリ節約最適化を可能にするために、ＳＣｅｌｌのコンポーネント・キャリアのアクティブ化／非アクティブ化のさらなるステップが導入される。本質的に、下りリンク・コンポーネント・キャリアは、３つの状態のうちの一つをとることができる。すなわち、非構成の状態、構成されたが非アクティブ化された状態、およびアクティブの状態のうちの１つである。下りリンクＳＣｅｌｌがアクティブではない時（すなわち、構成されたが非アクティブ化された時、または非構成の時）には、ユーザ機器は、対応するＰＤＣＣＨまたはＰＤＳＣＨを受信する必要がなく、ＣＱＩ測定を実行することを要求されない。逆に、下りリンクＳＣｅｌｌがアクティブである時には、ユーザ機器は、ＰＤＳＣＨおよびＰＤＣＣＨを受信しなければならず（存在する場合に）、ＣＱＩ測定を実行できると期待される。上で説明したように、下りリンク・コンポーネントでＰＤＣＣＨおよびＰＤＳＣＨを受信させるために、コンポーネント・キャリアを構成した後に、下りリンク・コンポーネント・キャリアは、構成されているが非アクティブ状態から、アクティブ状態に遷移される必要がある。
【０１００】
セカンダリ・コンポーネント・キャリアのアクティブ化／非アクティブ化機構の他の詳細は、次とすることができる。
・下りリンクＳＣｅｌｌの明示的アクティブ化は、ＭＡＣシグナリングによって行われる。
・下りリンクＳＣｅｌｌの明示的非アクティブ化は、ＭＡＣシグナリングによって行われる。
・下りリンクＳＣｅｌｌの暗黙のアクティブ化も、可能である。
・下りリンクＳＣｅｌｌを、個別にアクティブ化し、非アクティブ化することができ、単一のアクティブ化および非アクティブ化コマンドが、構成された下りリンク・セカンダリＳＣｅｌｌの部分集合をアクティブ化／非アクティブ化することができる。
・構成されたコンポーネント・キャリアのセットに追加されたＳＣｅｌｌは、最初に「非アクティブ化される」。
【０１０１】
＜キャリア・アグリゲーションに関する上りリンク電力制御＞
キャリア・アグリゲーションに関する上りリンク電力制御アルゴリズムの詳細のほとんどは、未公開または３ＧＰＰワーキング・グループで議論中であるが、ＬＴＥ−Ａ  Ｒｅｌ．  １０が、コンポーネント・キャリア固有上りリンク電力制御をサポートする、といった全般的な合意がなされている。すなわち、ユーザ機器のために構成された上りリンク・コンポーネント・キャリアごとに１つの独立の電力制御ループがある。さらに、パワー・ヘッドルームがコンポーネント・キャリアごとに報告されなければならないことが決定された。電力制限については、すなわちＵＥ送信電力が総最大ＵＥ送信電力を超えている場合には、次の電力スケーリングが適用される。
【０１０２】
電力スケーリングについて、ＰＵＣＣＨ電力が優先されなければならず、残り電力を、ＰＵＳＣＨによって使用することができる（すなわち、ＰＵＳＣＨ電力が、まず、おそらく０までスケール・ダウンされる）。さらに、上りリンク制御情報（ＵＣＩ）を有するＰＵＳＣＨは、ＵＣＩを有しないＰＵＳＣＨより優先される。さらに、ＵＣＩを有しないＰＵＳＣＨ送信に等しい電力スケーリングが考慮される。
【０１０３】
各コンポーネント・キャリアが、それ自体の電力制御ループを有すると仮定でき、各コンポーネント・キャリアの各トランスポート・ブロックが、コンポーネント・キャリアについて個別にセットされた電力を用いて送信されるので、パワー・ヘッドルーム報告は、コンポーネント・キャリアごとに実行されるべきである。キャリア・アグリゲーションは、複数のＬＴＥ  Ｒｅｌ．  ８／９（コンポーネント）キャリアの乗算とみなすことができるので、個々のコンポーネント・キャリアでのパワー・ヘッドルーム報告も、ＬＴＥ  Ｒｅｌ．  ８／９パワー・ヘッドルーム報告手順を再利用するであろうと仮定することができる。
【０１０４】
さらに、ＬＴＥ  Ｒｅｌ．１０では、キャリア・アグリゲーションのスコープ内に、２つの最大電力制限、すなわち、総最大ＵＥ送信電力ＰＣＮＭＡＸおよびコンポーネント・キャリア固有最大送信電力ＰＣＭＡＣ，ｃがある。３ＧＰＰ  ＲＡＮ４ワーキング・グループは、単一キャリア動作モードのキャリア・アグリゲーション対応ユーザ機器のリンク・バジェットに影響しないようにするために、ユーザ機器あたりの（公称）最大送信電力ＰＣＮＭＡＸと（公称）最大コンポーネント・キャリア固有送信電力ＰＣＭＡＣ，ｃとの両方が、サポートされるキャリアの個数にかかわりなく同一でなければならないことを既に示した。ＲＡＮ１は、コンポーネント・キャリアごとに報告されるパワー・ヘッドルーム報告が、最大電力削減（ＭＰＲ）を考慮に入れることに合意した。言い替えると、ユーザ機器によって適用される電力削減は、コンポーネント・キャリア固有最大送信電力Ｐｃｍａｘ，ｃで考慮される。ここで、ｃはコンポーネント・キャリアを表す。
【０１０５】
ＬＴＥ  Ｒｅｌ．  ８／９とは異なって、ＬＴＥ−Ａ  Ｒｅｌ．  １０では、ユーザ機器は、同時ＰＵＳＣＨ−ＰＵＣＣＨ送信、マルチクラスタ・スケジューリング、および複数コンポーネント・キャリア上の同時送信にも対処しなければならず、これは、３ＧＰＰ  Ｒｅｌ．  ８／９と比較して、より大きいＭＰＲ値を必要とし、適用されるＭＰＲ値のより大きい変動をも引き起こす。
【０１０６】
実際の電力削減が、割当のタイプ、標準化されたＭＰＲ値、およびユーザ機器実施態様にも依存するので、ｅノードＢは、各コンポーネント・キャリアに対してユーザ機器によって適用される電力削減を知らないことに留意されたい。したがって、ｅノードＢは、ユーザ機器がそれに関してパワー・ヘッドルームを計算するコンポーネント・キャリア固有最大送信電力を知らない。たとえば、ＬＴＥ  Ｒｅｌ．  ８／９では、ユーザ機器最大送信電力ＰＣＮＭＡＸは、上で説明したようにある範囲内にあるものとすることができる（ＰＣＭＡＸ＿Ｌ≦ＰＣＭＡＸ≦ＰＣＭＡＸ＿Ｈ）。
【０１０７】
上で説明したｅノードＢには未知のコンポーネント・キャリア固有最大送信電力ＰＣＭＡＣ，ｃの削減に起因して、ｅノードＢは、実際に、ユーザ機器がその総最大送信電力ＰＣＮＭＡＸのどれほど近くで動作しているのかを知り得ない。したがって、ユーザ機器が、総ユーザ機器最大送信電力ＰＣＮＭＡＸを超えている（したがって、電力スケーリングを必要とする）状況がある可能性がある。図２４に、ユーザ機器が電力制限される、すなわち、上りリンクで構成されたコンポーネント・キャリアＣＣ＃１およびＣＣ＃２上で電力スケーリングを適用している、例示的なシナリオを示す。ユーザ機器は電力制限されるが、ＬＴＥ定義によるコンポーネント・キャリア固有パワー・ヘッドルーム報告は、十分に大きいパワー・ヘッドルームを示す。
【０１０８】
一般に、電力スケーリングは、どちらかといえば例外的なケースであろう。したがって、これらの電力制限ケースが減らされるようにパワー・ヘッドルーム報告手順を設計することが有利かもしれない。たとえば、特許出願欧州特許出願第０９０１３７５６．３号）で言及されているように、ＵＥ固有パワー・ヘッドルーム報告を、コンポーネント・キャリア固有パワー・ヘッドルーム報告に加えて導入することができ、たとえば、ＵＥ固有パワー・ヘッドルーム報告が、ｅＮＢにＵＥ電力状況を十分に与えるために、コンポーネント・キャリア固有パワー・ヘッドルーム報告と一緒に報告される。
【０１０９】
ユーザ機器電力節約のために、追加のコンポーネント・キャリアを効率的で高速な形で非アクティブ化でき、アクティブ化できることが非常に重要である。バースト的データ送信を用いる場合、高ビット・レートの利益を利用でき、かつ、バッテリ保護をサポートできるように、追加のコンポーネント・キャリアをすばやくアクティブ化でき、非アクティブ化できることが、必須である。前に説明したように、ユーザ機器は、構成されたが非アクティブ化された下りリンク・コンポーネント・キャリアに対してＣＱＩ測定を実行せず、報告せず、ＲＳＲＰ（基準信号受信電力）測定およびＲＳＲＱ（基準信号受信品質）測定などの無線リソース管理関連測定だけを実行し、報告する。したがって、下りリンク・コンポーネント・キャリアをアクティブ化する時には、ｅノードＢが、効率的な下りリンク・スケジューリングのために適当なＭＣＳを選択できるようになるために、新たにアクティブ化されたコンポーネント・キャリア（１つまたは複数）のＣＱＩ情報をすばやく獲得することが重要である。ＣＱＩ情報がなければ、ｅノードＢは、ユーザ機器の下りリンク・チャネル状態に関する知識を持たず、下りリンク・データ送信についてどちらかといえば保守的なＭＣＳを選択するのみである可能性があり、これは、リソース利用の非効率性につながる。
【０１１０】
ＣＱＩ情報をすばやく獲得するために、ｅノードＢは、上りリンク・スケジューリング許可によって非周期的ＣＱＩをスケジューリングすることができる。非周期的ＣＱＩは、物理上りリンク共用チャネル（ＰＵＳＣＨ）上で送信される。したがって、構成された下りリンク・コンポーネント・キャリアをアクティブ化するために、ｅノードＢは、本質的に、下りリンク・コンポーネント・キャリアのアクティブ化コマンドを伝えるための１つの下りリンクＰＤＣＣＨおよび非周期的ＣＱＩの送信のために上りリンク・リソースをスケジューリングする１つの上りリンクＰＤＣＣＨという２つの許可（ＰＤＣＣＨ）をＵＥに発行する必要がある。さらに、両方のＰＤＣＣＨは、ユーザ機器が正しい下りリンク・コンポーネント・キャリアすなわちアクティブ化される下りリンク・コンポーネント・キャリアについてＣＱＩ情報を測定し、報告することを保証するために、それぞれ同一のＴＴＩで送信され、受信されなければならない。
【０１１１】
非周期的ＣＱＩの正しい受信は、下りリンク・アクティブ化コマンドの肯定応答として働くことができる。すなわち、非周期的ＣＱＩが受信された時に、ｅノードＢは、ユーザ機器が下りリンクＰＤＣＣＨで示される下りリンク・コンポーネント・キャリアをアクティブ化し終えたと仮定する。
【０１１２】
明らかに、上で説明したコンポーネント・キャリア・アクティブ化方法の主な欠点は、下りリンク・コンポーネント・キャリアをアクティブ化するために２つのＰＤＣＣＨが必要であることである。さらに、２つのＰＤＣＣＨが同時に受信／送信される必要があるという事実に起因して、ＰＤＣＣＨ消失によりある種のエラー・ケースが発生する可能性がある。
【０１１３】
下りリンク「アクティブ化」ＰＤＣＣＨだけが失われる場合には、ユーザ機器は、下りリンク・コンポーネント・キャリアをアクティブ化しない。しかし、受信されたＣＱＩ情報に基づいて、ｅＮＢは、下りリンク・アクティブ化が成功したと誤って仮定する。非周期的ＣＱＩを要求する上りリンクＰＤＣＣＨだけが失われる第２のエラー・ケースでは、ｅノードＢは、ＣＱＩを獲得せず、下りリンク・アクティブ化が失敗したと誤って仮定する。
【０１１４】
３ＧＰＰ  ＬＴＥ  Ｒｅｌ．  ８／９仕様によるパワー・ヘッドルーム報告に関連する問題もある。既に前に示したように、３ＧＰＰ  ＬＴＥ  Ｒｅｌ．  ８／９仕様によるパワー・ヘッドルーム報告は、パワー・ヘッドルームが公称ユーザ機器最大送信電力とＰＵＳＣＨ上の割り当てられた上りリンク送信の推定電力との間の差を示すので、ＵＥがＰＵＳＣＨ（トランスポート・ブロック）上での送信の上りリンク割当を有するサブフレーム内でのみ送信され得る。コンポーネント・キャリア・アグリゲーションを使用する時には、スケジューリングされていないコンポーネント・キャリアすなわちそれぞれのサブフレーム内で上りリンク・リソース割当を有しないコンポーネント・キャリアについて、パワー・ヘッドルーム報告を実行することはできない。これは、ＰＵＣＣＨ／ＰＵＳＣＨ送信がない場合に、コンポーネント・キャリア固有最大送信電力を判定できないという事実に起因する。明らかに、上りリンク送信なしの、すなわち割り当てられたリソース・ブロックすなわちＭＣＳを伴わない送信フォーマットもない。
【０１１５】
しかし、ｅノードＢは、ＵＥがサブフレームあたりどれほどのさらなる上りリンク帯域幅を使用できるのかを判定するために、パワー・ヘッドルーム報告を使用する。ｅＮＢが、前記スケジューリングされていない上りリンク・コンポーネント・キャリア上で上りリンク送信をスケジューリングすると判断する時に、ｅＮＢは、前記上りリンク・コンポーネント・キャリアの電力状況を粗く推定する必要があり、あるいは、コンポーネント・キャリア上で将来の上りリンク送信をブラインドでスケジューリングする。というのは、スケジューリングされていない上りリンク・コンポーネント・キャリアに関するパワー・ヘッドルーム情報がないからである。当然、このブラインド・スケジューリングは、最適には程遠い可能性があり、したがって、上りリンクのリソースの浪費につながる可能性がある。
【先行技術文献】
【特許文献】
【０１１６】
【特許文献１】欧州特許出願第０９０１３７５６．３号明細書
【非特許文献】
【０１１７】
【非特許文献１】３ＧＰＰ  ＴＳ  ３６．３２１、「Ｍｅｄｉｕｍ  Ａｃｃｅｓｓ  Ｃｏｎｔｒｏｌ（ＭＡＣ）ｐｒｏｔｏｃｏｌ  ｓｐｅｃｉｆｉｃａｔｉｏｎ」、ｖｅｒｓｉｏｎ  ８．７．０
【非特許文献２】３ＧＰＰ  ＴＳ  ３６．２１３、「Ｐｈｙｓｉｃａｌ  ｌａｙｅｒ  ｐｒｏｃｅｄｕｒｅｓ」、ｖｅｒｓｉｏｎ  ８．８．０
【非特許文献３】３ＧＰＰ  ＴＳ  ３６．１３３、「Ｒｅｑｕｉｒｅｍｅｎｔｓ  ｆｏｒ  ｓｕｐｐｏｒｔ  ｏｆ  ｒａｄｉｏ  ｒｅｓｏｕｒｃｅ  ｍａｎａｇｅｍｅｎｔ」、ｖｅｒｓｉｏｎ  ８．７．０
【非特許文献４】３ＧＰＰ  ＴＳ  ３６．１０１、「Ｅｖｏｌｖｅｄ  Ｕｎｉｖｅｒｓａｌ  Ｔｅｒｒｅｓｔｒｉａｌ  Ｒａｄｉｏ  Ａｃｃｅｓｓ（Ｅ−ＵＴＲＡ）；  Ｕｓｅｒ  Ｅｑｕｉｐｍｅｎｔ（ＵＥ）ｒａｄｉｏ  ｔｒａｎｓｍｉｓｓｉｏｎ  ａｎｄ  ｒｅｃｅｐｔｉｏｎ」、ｖｅｒｓｉｏｎ  ８．７．０
【非特許文献５】３ＧＰＰ  ＴＳ  ３６．２１１、「Ｅｖｏｌｖｅｄ  Ｕｎｉｖｅｒｓａｌ  Ｔｅｒｒｅｓｔｒｉａｌ  Ｒａｄｉｏ  Ａｃｃｅｓｓ（Ｅ−ＵＴＲＡ）；Ｐｈｙｓｉｃａｌ  Ｃｈａｎｎｅｌｓ  ａｎｄ  Ｍｏｄｕｌａｔｉｏｎ（Ｒｅｌｅａｓｅ  ８）」、ｖｅｒｓｉｏｎ  ８．９．０または９．０．０
【非特許文献６】３ＧＰＰ  ＴＳ  ３６．２１２、「Ｍｕｌｔｉｐｌｅｘｉｎｇ  ａｎｄ  ｃｈａｎｎｅｌ  ｃｏｄｉｎｇ（Ｒｅｌｅａｓｅ  ９）」、ｖｅｒｓｉｏｎ  ８．８．０または９．０．０
【非特許文献７】Ｓｔｅｆａｎｉａ  Ｓｅｓｉａ他、「ＬＴＥ  −  Ｔｈｅ  ＵＭＴＳ  Ｌｏｎｇ  Ｔｅｒｍ  Ｅｖｏｌｕｔｉｏｎ」、Ｗｉｌｅｙ  ＆  Ｓｏｎｓ  Ｌｔｄ．、ＩＳＢＮ  ９７８−０−４７０６９７１６−０、２００９年４月、セクション６および９
【発明の概要】
【発明が解決しようとする課題】
【０１１８】
本発明の１つの目的は、上で説明された問題のうちの少なくとも１つを克服することである。さらに、本発明のもう１つの目的は、現在上りリンク送信がスケジューリングされていない上りリンク・コンポーネント・キャリア上で、将来の送信についての効率的なスケジューリングを可能にすることである。
【課題を解決するための手段】
【０１１９】
本発明は、主に、ＬＴＥ  Ｒｅｌ−８／９仕様に従ってパワー・ヘッドルーム報告を計算することが不可能なケースに適用可能である。上で説明したように、特定のコンポーネント・キャリアのパワー・ヘッドルームは、一般に、コンポーネント・キャリアに固有の最大送信電力から、上りリンク電力制御公式の結果として特定のコンポーネント・キャリアを介する上りリンク・リソース割当に従って上りリンク送信を実行するのに必要な上りリンク送信電力を引いたものと定義することができる。したがって、上りリンク送信用のサブフレーム内に上りリンク・リソース割当がなく、したがって上りリンク送信がない時には、この特定のサブフレームについてパワー・ヘッドルームを計算することができない。通信システム内でキャリア・アグリゲーションを使用する時には、ユーザ機器は、複数の上りリンク・コンポーネント・キャリアを構成させることができ、１つまたは複数の上りリンク・コンポーネント・キャリアが、上りリンク送信のためにスケジューリングされない場合がある。コンポーネント・キャリアは、アクティブ化された状態、または構成されたが非アクティブ化された状態である可能性がある。
【０１２０】
上りリンク送信がないので、送信電力は、ユーザ機器によって適用されず、パワー・ヘッドルームは、前記特定のスケジューリングされていない上りリンク・コンポーネント・キャリアについてユーザ機器によって計算され得ない。
【０１２１】
本発明の主たる一態様は、ユーザ機器と通信する通信装置の処理を制御する集積回路であって、前記処理は、下りリンク・コンポーネント・キャリア上で、前記ユーザ機器に上りリンク・リソースまたは下りリンク・リソースを割り当てるためのリソース割当情報を送信し、前記リソース割当情報は、複数のビットを含み、複数の下りリンク・コンポーネント・キャリアの各々は、前記複数のビットに含まれる一つのビットと対応しており、前記一つのビットは、対応する下りリンク・コンポーネント・キャリアがアクティブ化されるべきかまたは非アクティブ化されるべきかのいずれかを示し、前記複数のビットに含まれるいずれかのビットが、対応する下りリンク・コンポーネント・キャリアがアクティブ化されるべきことを示す場合は、前記複数のビットは、パワー・ヘッドルームの報告を要求するパワー・ヘッドルーム報告要求をさらに示し、前記リソース割当情報に従って、前記ユーザ機器によりアクティブ化された下りリンク・コンポーネント・キャリアに対応する上りリンク・コンポーネント・キャリアを用いて、前記ユーザ機器にスケジューリングされた上りリンク・コンポーネント・キャリアのパワー・ヘッドルームと、前記ユーザ機器にスケジューリングされていない上りリンク・コンポーネント・キャリアの仮想パワー・ヘッドルームとを受信し、前記スケジューリングされた上りリンク・コンポーネント・キャリアのパワー・ヘッドルームは、前記リソース割当情報に基づいて、前記ユーザ機器により計算されたものであり、前記仮想パワー・ヘッドルームは、スケジューリングされていない上りリンク・コンポーネント・キャリアの事前に構成された仮想上りリンク・リソース割当に基づいて、前記ユーザ機器により計算されたものである、集積回路である。
【０１２２】
本発明の第１の態様によれば、ユーザ機器は、仮想パワー・ヘッドルームを計算することと、スケジューリングされていない上りリンク・コンポーネント・キャリアについてその仮想パワー・ヘッドルームをｅノードＢに送信することとが可能にされなければならない。
【０１２３】
対応する上りリンク・リソース割当は、事前に構成され、その後、ユーザ機器によって、ｅノードＢによって割り当てられる通常の上りリンク許可の代わりに、パワー・ヘッドルームを計算／推定するのに使用され得る。ユーザ機器は、事前に構成された仮想上りリンク・リソース割当に従う上りリンク送信が、基準サブフレームとも称する、パワー・ヘッドルームが計算されなければならないサブフレーム内で、あたかもｅノードＢによってスケジューリングされたかのように、仮想パワー・ヘッドルームを計算することができる。
【０１２４】
用語「仮想パワー・ヘッドルーム」および「事前に構成された仮想上りリンク・リソース割当」に関連する用語「仮想」は、その標準的ではない特性に言及するものである。「事前に構成された仮想上りリンク・リソース割当」は、上りリンク・リソース割当が、意図された通りに、すなわち上りリンク送信を実行するために使用されるのではなく、パワー・ヘッドルームを計算するためにのみ使用されるという意味で、仮想である。上りリンク・コンポーネント・キャリアは、この事前に構成された仮想上りリンク・リソース割当を有する場合であっても、スケジューリングされないままになる。それに対応して、「仮想パワー・ヘッドルーム」は、コンポーネント・キャリアの最大送信電力と前記スケジューリングされていない上りリンク・コンポーネント・キャリア上で実行される実際の上りリンク送信との間の差を反映するのではなく、単に、実際には行われない上りリンク送信を仮定する。
【０１２５】
仮想パワー・ヘッドルームを計算した後に、ユーザ機器は、これをｅノードＢに送信する。ｅノードＢが、仮想パワー・ヘッドルームを計算するのに使用される、事前に構成された仮想上りリンク・リソース割当の詳細を知っていると仮定する。前記ケースでは、ｅノードＢは、受信された仮想パワー・ヘッドルームからおよび仮想上りリンク・リソース割当から、スケジューリングされていない上りリンク・コンポーネント・キャリアに関するおよびユーザ機器に関する電力状況に関する情報を推定することができる。ｅノードＢが正確に推論できるものは、仮想ヘッドルームの計算に依存し、より詳細には以下で特に発明を実施するための形態で説明される。
【０１２６】
第１の代替案によれば、通常はユーザ機器に固有であり、ユーザ機器によって構成される（したがって、ｅノードＢには未知）コンポーネント・キャリアの最大送信電力には、固定された値がセットされる。言い替えると、最大送信電力は、事前に構成され、ユーザ機器だけによってセットされるのではない。背景技術セクションで説明したように、最大送信電力には、上限および下限、すなわちＰｃｍａｘ＿ＨおよびＰｃｍａｘ＿Ｌがある。事前に構成される最大送信電力には、たとえば、コンポーネント・キャリアに適用可能な最高のまたは最低の構成可能な最大送信電力をセットすることができる。どの場合でも、ｅノードＢは、どの事前に構成された最大送信電力が仮想パワー・ヘッドルームを計算するためにユーザ機器によって適用されるのかを知っている。
【０１２７】
有利なことに、可能な最大送信電力は、事前に構成される。Ｐｃｍａｘ＿Ｈ（＝ｍｉｎ（ＰＥＭＡＸ，ＰＰｏｗｅｒＣｌａｓｓ））は、両方ともｅノードＢに既に知られているＰＥＭＡＸおよびＰＰｏｗｅｒｃｌａｓｓだけに依存する。したがって、Ｐｃｍａｘ＿Ｈが事前に構成される場合に、ｅノードＢはこれを既に知っており、これは、Ｐｃｍａｘ＿Ｌには完全にはあてはまらない。より具体的には、Ｐｃｍａｘ＿Ｌ（＝ｍｉｎ（ＰＥＭＡＸ−ΔＴＣ，ＰＰｏｗｅｒＣｌａｓｓ−ＭＰＲ−ＡＭＰＲ−ΔＴＣ）は、さらに、実際にユーザ機器によって構成される、ｅノードＢには未知の最大電力削減に依存する。前記ケースでは、ｅノードＢは、仮想パワー・ヘッドルームの計算でユーザ機器によって適用される正確な事前に構成された最大送信電力を知らない。これを避けるために、ユーザ機器が、事前に構成された最大送信電力としてＰｃｍａｘ＿Ｌを使用する時に、仕様で定義される最大のＭＰＲ値を使用することを認めることができる。したがって、ｅノードＢは、Ｐｃｍａｘ＿Ｌ自体の値を計算することができる。
【０１２８】
当然、事前に構成された最大送信電力の任意の他の値を、ｅノードＢがこれを知っている限り、認めることができる。
【０１２９】
事前に構成された最大送信電力は、スケジューリングされていない上りリンク・コンポーネント・キャリアの仮想パワー・ヘッドルームを計算するために、固定と考えられるのみであることに留意されたい。他のスケジューリングされた上りリンク・コンポーネント・キャリアのパワー・ヘッドルーム報告の計算について、ユーザ機器は、それ自体のコンポーネント・キャリア固有の構成された最大送信電力を使用する。
【０１３０】
事前に構成された仮想上りリンク・リソース割当は、特定の個数のリソース・ブロックおよび特定のトランスポート・フォーマットを定義することができる。たとえば、リソース・ブロックの個数に１をセットすることができ、トランスポート・フォーマットのオフセット値ΔＴＦに０ｄＢをセットすることができる。その結果、パワー・ヘッドルームの公式内の対応するコンポーネント１０ｌｏｇ１０ＭＰＵＳＣＨ（ｉ）およびΔＴＦを無視することができ、これは、パワー・ヘッドルームの計算を容易にする。
【０１３１】
しかし、リソース・ブロックの個数およびトランスポート・フォーマット・オフセットΔＴＦについて、ｅノードＢがこれらの値を知っている限り、任意の値をとることができる。
【０１３２】
説明したように仮想パワー・ヘッドルームを計算した後に、ユーザ機器は、これをｅノードＢに送信する。その仮想パワー・ヘッドルームが計算済みである上りリンク・コンポーネント・キャリアの実際の上りリンク許可はないので、仮想パワー・ヘッドルームを、その上りリンク許可がｅノードＢによって割り当てられた任意の他の使用可能な上りリンク・コンポーネント・キャリアで送信することができる。
【０１３３】
このようにして、スケジューリングされていない上りリンク・コンポーネント・キャリアの仮想パワー・ヘッドルームが、ｅノードＢに報告される。仮想パワー・ヘッドルームを受信した時に、ｅノードＢは、それがスケジューリングされていない上りリンク・コンポーネント・キャリアを参照していることを認識する。さらに、ｅノードＢは、それからこのスケジューリングされていない上りリンク・コンポーネント・キャリアのリソース・ブロックあたりの電力および／または経路損を計算することができる。というのは、ｅノードＢが、ユーザ機器がそれを基礎として受信された仮想パワー・ヘッドルームを計算した、対応するパラメータを知っているからである。この知識を、より効率的な無線リソース管理のためにｅノードＢによって使用することができる。
【０１３４】
第２の代替案によれば、仮想パワー・ヘッドルームは、スケジューリングされていない上りリンク・コンポーネント・キャリアについてユーザ機器によって構成された最大送信電力と等しくなるように計算される。言い替えると、スケジューリングされていない上りリンク・コンポーネント・キャリアの上りリンク送信電力には、０ｄＢがセットされ、その結果、パワー・ヘッドルームを計算するための公式に従って、仮想パワー・ヘッドルームは、ユーザ機器の最大送信電力になると定義される。
【０１３５】
これは、ユーザ機器とｅノードＢとの両方に知られている事前に構成された固定された値を仮定する第１の代替案とは異なる。しかし、第２の代替案では、最大送信電力は、通常通りにユーザ機器によって決定される。すなわち、対応する公式に従ってユーザ機器に固有の電力削減を考慮して、決定される。
【０１３６】
仮想パワー・ヘッドルームは、それぞれの上りリンク・コンポーネント・キャリアの最大送信電力であり、たとえば上りリンク許可を有する別の上りリンク・コンポーネント・キャリア上で、ｅノードＢに送信される。
【０１３７】
ｅノードＢは、コンポーネント・キャリアの最大送信電力である仮想パワー・ヘッドルームを受信し、スケジューリングされていない上りリンク・コンポーネント・キャリアについてユーザ機器によって適用される電力削減を、それから計算することができる。特に最大送信電力は、ユーザ機器のＰｃｍａｘ＿Ｈ＝ｍｉｎ（ＰＥＭＡＸ，ＰＰｏｗｅｒＣｌａｓｓ）から、この上りリンク・コンポーネント・キャリアについてユーザ機器によって適用される電力削減を引いたものである。ｅノードＢは、Ｐｃｍａｘ＿Ｈを知っており、したがって、このコンポーネント・キャリアについてユーザ機器によって適用される電力削減を計算することができる。
【０１３８】
有利なことに、通信システムでの電力削減は、他の上りリンク・コンポーネント・キャリア上の送信をも考慮しており、したがって、同一の電力削減が、すべての上りリンク・コンポーネント・キャリア送信に適用される。前記ケースでは、受信された仮想パワー・ヘッドルームに基づいて電力削減を計算することによって、ｅノードＢは、ユーザ機器によってすべての他の上りリンク・コンポーネント・キャリアに実際に適用される電力削減を知る。したがって、ｅノードＢは、スケジューリングされた上りリンク・コンポーネント・キャリアの絶対送信電力を知り、それゆえＵＥの総送信電力状況を知り、将来の上りリンク送信のより正確なスケジューリングが可能になる。
【０１３９】
本発明は、コンポーネント・キャリア・アグリゲーションを使用するモバイル通信システム内でユーザ機器のスケジューリングされていない上りリンク・コンポーネント・キャリアのパワー・ヘッドルームをｅノードＢに報告する方法を提供する。ユーザ機器は、スケジューリングされていない上りリンク・コンポーネント・キャリアの事前に構成された仮想上りリンク・リソース割当に基づいて、前記スケジューリングされていない上りリンク・コンポーネント・キャリアの仮想パワー・ヘッドルームを計算する。事前に構成された仮想上りリンク・リソース割当は、ｅノードＢに既知である。その後、ユーザ機器は、計算された仮想パワー・ヘッドルームをＮｏｄｅＢに送信する。
【０１４０】
本発明の有利な実施形態によれば、仮想パワー・ヘッドルームは、さらに、ユーザ機器のスケジューリングされていない上りリンク・コンポーネント・キャリアの事前に構成された最大送信電力（Ｐｃｍａｘ，ｃ）に基づいて計算される。この実施形態は、発明を実施するための形態で述べる第１の代替案に当てはまる。
【０１４１】
本発明のさらなる実施形態では、ｅノードＢは、ユーザ機器のスケジューリングされていない上りリンク・コンポーネント・キャリアの、事前に構成された仮想上りリンク・リソース割当および事前に構成された最大送信電力に関する情報を有する。したがって、ｅノードＢは、受信された仮想パワー・ヘッドルーム、事前に構成された仮想上りリンク・リソース割当、および事前に構成された最大送信電力に基づいて、スケジューリングされていない上りリンク・コンポーネント・キャリアの経路損および／またはリソース・ブロックあたりの電力を判定する。
【０１４２】
本発明のもう１つの実施形態について、ｅノードＢは、ユーザ機器の上りリンク・コンポーネント・キャリアの上りリンク送信をスケジューリングする時に、スケジューリングされていない前記上りリンク・コンポーネント・キャリアの判定された経路損および／またはリソース・ブロックあたりの電力を考慮する。
【０１４３】
本発明のさらなる実施形態を参照すると、スケジューリングされていない上りリンク・コンポーネント・キャリアの事前に構成された最大送信電力には、ユーザ機器の上りリンク・コンポーネント・キャリアの最高の（Ｐｃｍａｘ＿Ｈ）または最低の（Ｐｃｍａｘ＿Ｌ）構成可能な最大送信電力がセットされる。
【０１４４】
本発明のより詳細な実施形態では、事前に構成された最大送信電力に最低の最大送信電力がセットされる場合に、ユーザ機器は、最低の最大送信電力を計算するために事前に決定された電力削減を使用する。スケジューリングされていない上りリンク・コンポーネント・キャリアの経路損の判定は、事前に決定された電力削減に基づいてユーザ機器の上りリンク・コンポーネント・キャリアの最低の最大送信電力を計算することを含む。
【０１４５】
本発明の代替実施形態によれば、仮想パワー・ヘッドルームは、スケジューリングされていない上りリンク・コンポーネント・キャリアについてユーザ機器によって構成された最大送信電力（Ｐｃｍａｘ，ｃ）と等しい。これは、発明を実施するための形態で述べる第２の実施形態に当てはまる。また、第２の実施の形態は、スケジューリングされていない上りリンク・コンポーネント・キャリアの上りリンク送信電力が仮想パワー・ヘッドルームの計算のために０と定義されることをも開示する。
【０１４６】
本発明のもう１つの実施形態について、各上りリンク・コンポーネント・キャリアの電力削減の計算は、ユーザ機器の他の構成された上りリンク・コンポーネント・キャリア（１つまたは複数）上の送信（１つまたは複数）を考慮する。前記ケースでは、ユーザ機器は、スケジューリングされていない上りリンク・コンポーネント・キャリアの電力削減（ＭＰＲ）を判定する。ここで、その電力削減（ＭＰＲ）は、ユーザ機器の他の構成された上りリンク・コンポーネント・キャリア（１つまたは複数）上の送信（１つまたは複数）を考慮してある。ユーザ機器は、判定された電力削減（ＭＰＲ）に基づいて、最大送信電力を計算する。ｅノードＢは、受信した仮想パワー・ヘッドルームに基づいて、その上りリンク・コンポーネント・キャリアのすべてについてユーザ機器によって使用される電力削減を計算する。
【０１４７】
本発明のもう１つの実施形態について、スケジューリングされていないコンポーネント・キャリアは、アクティブ化された状態または構成されたが非アクティブ化された状態である。
【０１４８】
本発明のさらなる実施形態によれば、事前に構成された上りリンク・リソース割当は、スケジューリングされていない上りリンク・コンポーネント・キャリア上で上りリンク送信を実行するためにはユーザ機器によって使用されない。これが、それが「仮想」と呼ばれる理由である。
【０１４９】
本発明の有利な実施形態では、仮想パワー・ヘッドルームは、ｅノードＢによってスケジューリングされた上りリンク・リソース割当を有する別の上りリンク・コンポーネント・キャリアを使用して、ｅノードＢに送信される。
【０１５０】
本発明のもう１つの実施形態について、仮想パワー・ヘッドルームは、ＭＡＣ（媒体アクセス制御）制御要素内のフラグ、または仮想パワー・ヘッドルームを含むＭＡＣプロトコル・データ・ユニットのサブヘッダ内のフラグのいずれかに基づいて、スケジューリングされていない上りリンク・コンポーネント・キャリアを参照するためにｅノードＢによって識別される。
【０１５１】
本発明の異なる態様は、０から６３までの値をとる仮想パワー・ヘッドルーム、またはオフセット値を使用して計算される仮想パワー・ヘッドルームに関する。
【０１５２】
本発明は、コンポーネント・キャリア・アグリゲーションを使用するモバイル通信システム内で、ユーザ機器のスケジューリングされていない上りリンク・コンポーネント・キャリアのパワー・ヘッドルームをｅノードＢに報告するユーザ機器を提供する。ユーザ機器のプロセッサは、スケジューリングされていない上りリンク・コンポーネント・キャリアの事前に構成された仮想上りリンク・リソース割当に基づいて、前記スケジューリングされていない上りリンク・コンポーネント・キャリアの仮想パワー・ヘッドルームを計算する。事前に構成された仮想上りリンク・リソース割当は、ｅノードＢに既知である。ユーザ機器の送信器は、計算された仮想パワー・ヘッドルームをｅノードＢに送信する。
【０１５３】
もう１つの実施形態によれば、プロセッサは、さらにユーザ機器のスケジューリングされていない上りリンク・コンポーネント・キャリアの事前に構成された最大送信電力（Ｐｃｍａｘ，ｃ）に基づいて、仮想パワー・ヘッドルームを計算する。
【０１５４】
本発明のさらなる実施形態に関して、スケジューリングされていない上りリンク・コンポーネント・キャリアの事前に構成された最大送信電力には、ユーザ機器の上りリンク・コンポーネント・キャリアの最高の（Ｐｃｍａｘ＿Ｈ）または最低の（Ｐｃｍａｘ＿Ｌ）構成可能な最大送信電力がセットされ、事前に構成された最大送信電力に最低の最大送信電力がセットされる場合には、プロセッサは、最低の最大送信電力を計算するために事前に決定された電力削減を使用する。
【０１５５】
本発明の有利な実施形態では、プロセッサは、スケジューリングされていない上りリンク・コンポーネント・キャリアのユーザ機器によって構成される最大送信電力（Ｐｃｍａｘ，ｃ）と等しい仮想パワー・ヘッドルームを計算する。
【０１５６】
本発明のもう１つの実施形態について、プロセッサは、各上りリンク・コンポーネント・キャリアの電力削減を計算するために、ユーザ機器の他の構成された上りリンク・コンポーネント・キャリア（１つまたは複数）上の送信（１つまたは複数）を考慮する。プロセッサは、さらに、ユーザ機器の他の構成された上りリンク・コンポーネント・キャリア（１つまたは複数）上の送信（１つまたは複数）を考慮するスケジューリングされていない上りリンク・コンポーネント・キャリアの電力削減（ＭＰＲ）を判定する。プロセッサは、判定された電力削減（ＭＰＲ）に基づいて、最大送信電力を計算する。
【０１５７】
本発明のさらなる実施形態によれば、プロセッサは、スケジューリングされていない上りリンク・コンポーネント・キャリア上の上りリンク送信を実行するために、事前に構成された上りリンク・リソース割当を無視する。
【０１５８】
本発明のもう１つの実施形態を参照すると、送信器は、ｅノードＢによってスケジューリングされた上りリンク・リソース割当を有する別の上りリンク・コンポーネント・キャリアを使用して、仮想パワー・ヘッドルームをｅノードＢに送信する。
【０１５９】
本発明のもう１つの実施形態について、プロセッサは、オフセット値を考慮して仮想パワー・ヘッドルームを計算する。
【０１６０】
本発明は、コンポーネント・キャリア・アグリゲーションを使用するモバイル通信システム内でのユーザ機器からｅノードＢへの送信のためのＭＡＣ制御要素をも提供する。ＭＡＣ制御要素は、仮想ヘッドルーム報告を識別するためのパワー・ヘッドルーム・タイプ・ビットを含む。仮想パワー・ヘッドルームは、コンポーネント・キャリア・アグリゲーションを使用するモバイル通信システム内のスケジューリングされていない上りリンク・コンポーネント・キャリアについてユーザ機器によって計算される。ＭＡＣ制御要素は、パワー・ヘッドルーム値をも含む。
【０１６１】
本発明のさらなる目的は、シグナリング・オーバーヘッドを最小にしながら、コンポーネント・キャリアの効率的で頑健な（非）アクティブ化を可能にすることである。
【０１６２】
この目的は、独立請求項の主題によって解決される。本発明の有利な実施形態は、従属請求項の対象である。
【０１６３】
本発明の第１の態様は、モバイル端末（３ＧＰＰ用語ではユーザ機器と称する）のために構成された個々の下りリンク・コンポーネント・キャリアのアクティブ化／非アクティブ化を可能にする、新しい上りリンク・リソース割当フォーマットおよび新しい下りリンク・リソース割当フォーマットの提案である。新しい上りリンクまたは下りリンクのリソース割当は、構成された下りリンク・コンポーネント・キャリアのアクティブ化状態の表示を含む。すなわち、どの下りリンク・コンポーネント・キャリア（１つまたは複数）がアクティブ化されまたは非アクティブ化されるのかを示す。この表示は、たとえば、構成された上りリンク・コンポーネント・キャリアのどれがそれぞれアクティブ化されまたは非アクティブ化されるのかを示すビットマスクによって実施される。
【０１６４】
さらに、新しい下りリンク・リソース割当フォーマットの提案に関して、単一の下りリンク・リソース割当を使用して、下りリンク・コンポーネント・キャリア（１つまたは複数）を（非）アクティブ化し、アクティブ化された下りリンク・コンポーネント・キャリア（すなわち、下りリンク・リソース割当を受信する時に既にアクティブ状態である下りリンク・コンポーネント・キャリア）上で下りリンク・リソースを同時に割り当てることができる。
【０１６５】
３ＧＰＰ  ＬＴＥ−Ａ（リリース１０）または下りリンクでキャリア・アグリゲーションを使用する将来のリリースなど、下りリンクでキャリア・アグリゲーションを使用する３ＧＰＰベースの通信システム内のフォーマットの１つの例示的実施態様では、新しいリソース割当フォーマットを、既存のＤＣＩフォーマットに対する拡張または新しいＤＣＩフォーマットと考えることができる。
【０１６６】
もう１つの例示的実施態様では、ビットマスク内のビットのそれぞれは、それぞれの構成された下りリンク・コンポーネント・キャリアに関連付けられ、そのアクティブ化状態を示す。上りリンクまたは下りリンクのリソース割当に含まれるこのビットマスクをチェックすることによって、モバイル端末は、構成された下りリンク・コンポーネント・キャリアのそれぞれについて、それぞれの下りリンク・コンポーネント・キャリアのアクティブ化状態が変更されるかどうか、すなわち、構成された下りリンク・コンポーネント・キャリアのどの１つまたは複数がアクティブ化されまたは非アクティブ化される必要があるのかを判定することができる。
【０１６７】
さらに、より高度な例示的実施態様では、コンポーネント・キャリア・アクティブ化／非アクティブ化情報を含む上りリンク・リソース割当は、モバイル端末に、新たにアクティブ化されるコンポーネント・キャリア（すなわち、その状態が非アクティブ化からアクティブ化に変更されたコンポーネント・キャリア（１つまたは複数））に関するチャネル品質測定値を送信するように指示することもできる。したがって、モバイル端末は、新たにアクティブ化されるコンポーネント・キャリアごとにチャネル品質測定を実行し、上りリンク・リソース割当によってモバイル端末に割り当て済みである上りリンク・リソース上で基地局（３ＧＰＰ用語ではｅノードＢと称する）に測定の結果を送信する。チャネル品質測定結果（１つまたは複数）の送信は、モバイル端末が、それぞれ、上りリンク・リソース割当を成功して受信し、または構成された下りリンク・コンポーネント・キャリアを成功してアクティブ化／非アクティブ化したことを基地局に示す。したがって、チャネル品質測定結果（１つまたは複数）の送信を、それぞれ上りリンク・リソース割当またはモバイル端末による構成された下りリンク・コンポーネント・キャリアのアクティブ化／非アクティブ化の肯定応答と考えることができる。
【０１６８】
本発明の一実施形態では、上りリンク・リソース割当の新しいフォーマットは、コンポーネント・キャリア・アグリゲーションを使用するモバイル通信システム内で下りリンク・コンポーネント・キャリアを（非）アクティブ化するための方法で使用される。モバイル端末によって実行されるこの方法では、モバイル端末は、下りリンク・コンポーネント・キャリア上で、モバイル端末に上りリンク・リソースを割り当てるための上りリンク・リソース割当を受信する。上りリンク・リソース割当は、複数の構成された下りリンク・コンポーネント・キャリアのどれが、それぞれアクティブ化されまたは非アクティブ化されるのかを示すビットマスクを含む。モバイル端末は、上りリンク・リソース割当に含まれるビットマスクに従って、構成された下りリンク・コンポーネント・キャリアをアクティブ化しまたは非アクティブ化する。
【０１６９】
本発明のさらなる実施形態では、モバイル端末は、上りリンク・リソース割当によって新たにアクティブ化される下りリンク・コンポーネント・キャリア（すなわち、上りリンク・リソース割当の受信時にまだアクティブ化されていない下りリンク・コンポーネント・キャリア（１つまたは複数））ごとにチャネル品質測定を実行し、アクティブ化された下りリンク・コンポーネント・キャリア（１つまたは複数）のチャネル品質測定値（１つまたは複数）を、割り当てられた上りリンク・リソース上で送信する。代替案では、本発明のもう１つの実施形態に従って、モバイル端末は、上りリンク・スケジューリングのスケジューリング関連情報を、割り当てられた上りリンク・リソース上で送信することもできる。
【０１７０】
両方のケースで、割り当てられた上りリンク・リソース上での上りリンク送信は、考慮されることができ、かつ、上りリンク・リソース割当の（成功の）受信または下りリンク・コンポーネント・キャリアの成功の（非）アクティブ化の肯定応答とすることができる。
【０１７１】
もう１つの例示的実施形態では、新しい上りリンク・リソース割当フォーマットは、基地局によって実行されるコンポーネント・キャリア・アグリゲーションを使用するモバイル通信システム内で下りリンク・コンポーネント・キャリアを（非）アクティブ化するもう１つの方法で使用され、基地局は、モバイル端末に上りリンク・リソースを割り当てるためにモバイル端末に上りリンク・リソース割当を送信する。上りリンク・リソース割当は、アクティブな構成された下りリンク・コンポーネント・キャリア上でモバイル端末に送信される。さらに、モバイル端末への上りリンク割当のほかに、上りリンク・リソース割当は、複数の構成された下りリンク・コンポーネント・キャリアのどれがそれぞれアクティブ化されまたは非アクティブ化されるのかを示すビットマスクを含む。この上りリンク・リソース割当に応答して、基地局は、上りリンク・リソース割当の受信が成功したこと示すまたは下りリンク・コンポーネント・キャリアの（非）アクティブ化が成功したことを示す、肯定応答を受信する。肯定応答は、割り当てられた上りリンク・リソース上で送信される。さらに、肯定応答は、たとえば、新たにアクティブ化される下りリンク・コンポーネント・キャリア（１つまたは複数）のチャネル品質測定値（１つまたは複数）の形またはその代わりにモバイル端末から基地局に送信されるスケジューリング関連情報の形で受信される。
【０１７２】
本発明のもう１つの実施形態では、下りリンク・リソース割当の新しいフォーマットは、コンポーネント・キャリア・アグリゲーションを使用するモバイル通信システム内で下りリンク・コンポーネント・キャリアを（非）アクティブ化する方法で使用される。モバイル端末によって実行されるこの方法では、モバイル端末は、下りリンク・コンポーネント・キャリア上で、モバイル端末に下りリンク・リソースを割り当てるための下りリンク・リソース割当を受信する。下りリンク・リソース割当は、複数の構成された下りリンク・コンポーネント・キャリアのどれがそれぞれアクティブ化されまたは非アクティブ化されるのかを示す表示を含む。モバイル端末は、上りリンク・リソース割当に含まれる表示に従って、構成された下りリンク・コンポーネント・キャリアをアクティブ化しまたは非アクティブ化する。表示は、たとえばビットマスクの形で実現することができる。
【０１７３】
さらに、モバイル端末は、下りリンク・リソース割当内で示される下りリンク・データをさらに受信する。割り当てられた下りリンク・リソースが、下りリンク・リソース割当の受信時に既にアクティブ状態である下りリンク・コンポーネント・キャリア（この下りリンク・コンポーネント・キャリアは、下りリンク・リソース割当が受信された下りリンク・コンポーネント・キャリアとすることができ、または、アクティブ状態のクロススケジューリングされた他の下りリンク・コンポーネント・キャリアとすることができる）上にあることに留意されたい。
【０１７４】
さらに、本発明のさらなる例示的実施形態では、下りリンク・リソース割当および割り当てられた下りリンク・リソース上の下りリンク・データは、単一のサブフレーム内で受信される。
【０１７５】
上で説明した方法では、本発明のもう１つの実施形態に従って、上りリンク・リソース割当は、下りリンク・コンポーネント・キャリアのアクティブ化および非アクティブ化のためにモバイル端末に割り当てられる無線ネットワーク一時識別子（ＲＮＴＩ）を用いてマスクされるＣＲＣフィールドを含む。下りリンク・コンポーネント・キャリアのアクティブ化および非アクティブ化のためにモバイル端末に割り当てられる「特殊な」ＲＮＴＩを使用することで、基地局は、たとえば、受信された上りリンク・リソース割当のフォーマットをモバイル端末に示すことができる。下りリンク・コンポーネント・キャリアのアクティブ化および非アクティブ化のための特殊なＲＮＴＩは、特にモバイル端末に有利であり、その結果、上りリンクまたは下りリンクのリソース割当についての予定の受信器をさらに示す必要がなくなる。
【０１７６】
上で述べたように、下りリンクでキャリア・アグリゲーションを使用する３ＧＰＰベースの通信システム内で本発明の概念を実施する状況では、本明細書で提案される上りリンク・リソース割当ならびに下りリンク・リソース割当を、Ｌ１／Ｌ２制御情報の「特殊な」ＤＣＩフォーマットと考えることができる。同一サイズを有する複数のＤＣＩフォーマットが存在し得るので、下りリンク・コンポーネント・キャリアのアクティブ化および非アクティブ化のためにモバイル端末に割り当てられるＲＮＴＩは、下りリンク・コンポーネント・キャリア・アクティブ化状態に関する情報を含む組み合わされた上りリンク割当をそれぞれ上りリンクまたは下りリンクのコンポーネント・キャリア上の「純粋な」リソース割当から区別するためのフォーマット表示とすることができる。
【０１７７】
例示のために３ＧＰＰ状況下での本発明の概念の例示的実施態様に留まると、上りリンク・リソース割当は、たとえば、３ＧＰＰ  ＬＴＥ（リリース８／９）のＤＣＩフォーマット０を再利用であり得、３ＧＰＰ  ＬＴＥ  ＤＣＩフォーマット０の新データ・インジケータ（ＮＤＩ）のビット、ＴＰＣコマンド・フィールド、およびＣＱＩ要求フラグが、ビットマスクを示すために再利用される。その代わりに、もう１つの例示的実施態様では、モバイル端末が上りリンク・リソース割当に対して新たにアクティブ化される下りリンク・コンポーネント・キャリア（１つまたは複数）のチャネル品質測定値を送信するかどうかの表示と、３ＧＰＰ  ＬＴＥ  ＤＣＩフォーマット０の新データ・インジケータ（ＮＤＩ）のビット、ＴＰＣコマンド・フィールド、ＣＱＩ要求フラグ、ならびに変調および符号化方式フィールドの１ビットを再利用してビットマスクを示すために、モバイル端末が新たにアクティブ化される下りリンク・コンポーネント・キャリア（１つまたは複数）のチャネル品質測定値を送信するかどうかの表示をさらに含む。
【０１７８】
本発明のさらなる実施形態では、下りリンクでキャリア・アグリゲーションを使用する３ＧＰＰベースの通信システムで本発明の概念を実施する状況では、上りリンク・リソース割当は、ＦＤＤ動作のための下りリンク制御情報（ＤＣＩ）と考えられ、次からなる。
【０１７９】
−フォーマット・フラグ、これは、同一のビット数／サイズを有するように定義されるＤＣＩフォーマットを区別するものである、
−ホッピング・フラグ、これは、モバイル端末が上りリンク・リソース・ホッピングを使用すべきか否かを示すものである、
−リソース・ブロック割当フィールド、これは、ＰＵＳＣＨ上で上りリンク・リソースをモバイル端末に割り当てるものである、
−変調および符号化方式フィールド、これは、ＰＵＳＣＨ上で割り当てられたリソースを使用した送信に関する、変調方式、符号化レート、および冗長性バージョンを示すものである、
−ＤＭＲＳフィールド、これは、基準シンボル・シーケンスに適用される循環シフトを構成するものである、
−コンポーネント・キャリア（非）アクティブ化フィールド、これは、複数の下りリンク・コンポーネント・キャリアのそれぞれについて、それぞれの下りリンク・コンポーネント・キャリアがアクティブ化されまたは非アクティブ化されるのかどうかをビットマスクによって示すものである、および
−１つまたは複数のパディング・ビット、これは、専用制御情報のサイズを所定のビット数に整列させるためのものであり、このビットは必要な場合に（すなわち、オプションで）設けられる。
【０１８０】
本発明のもう１つの代替実施形態では、上りリンク・リソース割当は、さらに（すなわち、上で述べたフィールドに加えて）、上りリンク・リソースが複数の上りリンク・コンポーネント・キャリアのうちのどれに割り当てられるのかを示すキャリア・インジケータ・フィールドからなる。この実施態様は、クロスキャリア・スケジューリングを使用できる３ＧＰＰ  ＬＴＥ−Ａ（リリース１０）で有用であり得る。
【０１８１】
先の段落で論じた両方の例示的な上りリンク割当フォーマットでは、上りリンク・リソース割当は、オプションで、さらに、モバイル端末が新たにアクティブ化された下りリンク・コンポーネント・キャリア（１つまたは複数）のチャネル品質測定値を送信すべきかどうかを示すＣＱＩフラグからなることができる。このＣＱＩフラグは、必ずしも３ＧＰＰ  ＬＴＥ（リリース８／９）ＤＣＩフォーマット０から既知のＣＱＩフラグではないことに留意されたい。代替実施態様では、先の段落で論じた２つの上りリンク・リソース割当フォーマットは、オプションで、モバイル端末が新たにアクティブ化された下りリンク・コンポーネント・キャリア（１つまたは複数）のチャネル品質測定値を送信すべきかどうかを示すために変調および符号化方式フィールド内で表現可能な少なくとも１つのコードポイントを利用することができる。
【０１８２】
３ＧＰＰの状況で提案される下りリンク割当の実施態様に関連するもう１つの例示的実施形態では、下りリンク・リソース割当は、たとえば３ＧＰＰ  ＬＴＥ（リリース８／９）ＤＣＩフォーマット１Ａを再利用であり得る。たとえば、新データ・インジケータ（ＮＤＩ）のビットおよび／または３ＧＰＰ  ＬＴＥ  ＤＣＩフォーマット１ＡのＰＵＣＣＨフィールドのＴＰＣコマンドを再利用して、下りリンク・コンポーネント・キャリアのアクティブ化状態を示すことができる。たとえば、新しい下りリンク・コンポーネント・キャリア（ＤＬ  ＣＣ）（非）アクティブ化フラグとしてＮＤＩフラグを再定義する場合に、この新しいフラグを使用して、すべての下りリンク・コンポーネント・キャリア（常にアクティブ化される、下りリンク・コンポーネント・キャリアのうちの１つ、たとえばアンカ・キャリアを除く）をアクティブ化しまたは非アクティブ化することができる。ＰＵＣＣＨフィールドのＴＰＣコマンドおよびＮＤＩフラグが再利用される場合には、１ビットを使用することによって１つのコンポーネント・キャリアのアクティブ化状態（アクティブまたは構成されたが非アクティブ化された）を示し、（非）アクティブ化が関係する１つの下りリンク・コンポーネント・キャリアを示すのに残りの使用可能なビットを使用することが可能である。
【０１８３】
本発明のさらなる実施形態では、それぞれ上りリンクまたは下りリンクのリソース割当は、モバイル端末へのリソース割当のためにモバイル端末に割り当てられた無線ネットワーク一時識別子（ＲＮＴＩ）を用いてマスクされたＣＲＣフィールドを含み、それぞれ上りリンクまたは下りリンクのリソース割当のキャリア・インジケータ・フィールド（ＣＩＦ）のコードポイントのうちの少なくとも１つは、それぞれ上りリンクもしくは下りリンクのリソース割当が構成された下りリンク・コンポーネント・キャリアを（非）アクティブ化するためのビットマスクを示しているかどうか、または上りリンク・リソース割当が構成された下りリンク・コンポーネント・キャリアの（非）アクティブ化に使用されず、それぞれ上りリンクまたは下りリンクのリソースを割り当てるのみであるかどうかを示している。
【０１８４】
本発明のさらなる態様は、ハードウェアおよびソフトウェアまたはその組合せでの本明細書で議論されるさまざまな実施形態によるコンポーネント・キャリア・アグリゲーションを使用するモバイル通信システム内で下りリンク・コンポーネント・キャリアを（非）アクティブ化する異なる方法の実施である。この状況では、本発明のもう１つの実施形態は、コンポーネント・キャリア・アグリゲーションを使用するモバイル通信システム内で使用されるモバイル端末を提供する。このモバイル端末は、モバイル端末に上りリンク・リソースを割り当てる上りリンク・リソース割当を下りリンク・コンポーネント・キャリア上で受信する受信器を含み、上りリンク・リソース割当は、複数の構成された下りリンク・コンポーネント・キャリアのうちのどれがそれぞれアクティブ化されまたは非アクティブ化されるのかを示すビットマスクを含んでいる。さらに、モバイル端末は、上りリンク・リソース割当に含まれるビットマスクに従って、構成された下りリンク・コンポーネント・キャリアをアクティブ化しまたは非アクティブ化するプロセッサを含む。
【０１８５】
本発明のさらなる実施形態では、モバイル端末は、上りリンク・リソース割当によって新たにアクティブ化される下りリンク・コンポーネント・キャリアごとにチャネル品質測定を実行するチャネル品質測定ユニットと、割り当てられた上りリンク・リソース上でアクティブ化された下りリンク・コンポーネント・キャリア（１つまたは複数）のチャネル品質測定値（１つまたは複数）を送信する送信器とをも含む。
【０１８６】
本発明のもう１つの実施形態は、コンポーネント・キャリア・アグリゲーションを使用するモバイル通信システム内で使用されるさらなるモバイル端末を提供する。モバイル端末は、モバイル端末に下りリンク・リソースを割り当てるための下りリンク・リソース割当を下りリンク・コンポーネント・キャリア上で受信する受信器を含み、上りリンク・リソース割当は、複数の構成された下りリンク・コンポーネント・キャリアのどれがそれぞれアクティブ化されまたは非アクティブ化されるのかを示すビットマスクを含んでいる。モバイル端末の受信器は、さらに、下りリンク・リソース割当によって割り当てられた下りリンク・リソース上で下りリンク・データを受信する。さらに、モバイル端末は、上りリンク・リソース割当に含まれるビットマスクに従って、構成された下りリンク・コンポーネント・キャリアをアクティブ化しまたは非アクティブ化するプロセッサを含む。
【０１８７】
本発明のもう１つの実施形態では、モバイル端末は、ＨＡＲＱプロトコルの複数のＨＡＲＱプロセスのうちの１つを使用して下りリンク・データを受信し、下りリンク・データの送信に関して新データ・インジケータ（ＮＤＩ）の既知の値を仮定する。
【０１８８】
本発明のもう１つの実施形態によれば、それぞれ上りリンクまたは下りリンクのリソース割当は、１つのサブフレームの制御シグナリング領域内で受信される。したがって、モバイル端末（または正確にはその受信器）は、サブフレームの制御シグナリング領域内でリソース割当のブラインド検出を実行することができる。
【０１８９】
本発明のさらなる実施形態では、モバイル端末のプロセッサは、さらに、それぞれ上りリンクまたは下りリンクのリソース割当のＣＲＣフィールドからマスクされたＣＲＣ符号を入手し、これによってＣＲＣ符号を入手するために下りリンク・コンポーネント・キャリアのアクティブ化および非アクティブ化のためにモバイル端末に割り当てられた無線ネットワーク一時識別子（ＲＮＴＩ）を用いて、マスクされたＣＲＣ符号をマスク解除し、ＣＲＣ符号に基づいてリソース割当についてのブラインド検出の成功を検証する。
【０１９０】
さらに、本発明のもう１つの実施形態は、コンポーネント・キャリア・アグリゲーションを使用するモバイル通信システム内のための基地局を提供する。基地局は、モバイル端末に上りリンク・リソースを割り当てるための上りリンク・リソース割当をアクティブの構成された下りリンク・コンポーネント・キャリア上でモバイル端末へ送信する送信器を含み、上りリンク・リソース割当は、複数の構成された下りリンク・コンポーネント・キャリアのどれがそれぞれアクティブ化されまたは非アクティブ化されるのかを示すビットマスクを含んでいる。さらに、基地局は、上りリンク・リソース割当の受信が成功したことを示すまたは下りリンク・コンポーネント・キャリアの（非）アクティブ化が成功したことを示す肯定応答を、割り当てられた上りリンク・リソース上で受信する受信器を含み、肯定応答は、新たにアクティブ化された下りリンク・コンポーネント・キャリア（１つまたは複数）のチャネル品質測定値（１つまたは複数）の形で受信される。
【０１９１】
下りリンク・リソースの割当に関して、本発明のさらなる実施形態は、コンポーネント・キャリア・アグリゲーションを使用するモバイル通信システム内のための基地局を提供する。基地局は、モバイル端末に下りリンク・リソースを割り当てるために下りリンク・リソース割当をアクティブの構成された下りリンク・コンポーネント・キャリア上でモバイル端末に送信する送信器を含み、下りリンク・リソース割当は、複数の構成された下りリンク・コンポーネント・キャリアのどれがそれぞれアクティブ化されまたは非アクティブ化されるのかを示すビットマスクを含む。基地局は、さらに、下りリンク・リソース割当と同一のサブフレーム内で、割り当てられた下りリンク・リソース上で、下りリンク・データ（たとえば、トランスポート・ブロック）をモバイル端末に送信する。
【０１９２】
本発明のもう１つの実施形態では、基地局は、下りリンク・データの送信にＨＡＲＱプロトコルの複数のＨＡＲＱプロセスのうちの１つを使用し、下りリンク・データの送信に関して新データ・インジケータ（ＮＤＩ）の既知の値を仮定する。
【０１９３】
本発明のより特別な実施形態による基地局は、さらに、それぞれ上りリンクまたは下りリンクのリソース割当のためにＣＲＣフィールドを生成し、それぞれ上りリンクまたは下りリンクのリソース割当をモバイル端末に送信する前に下りリンク・コンポーネント・キャリアのアクティブ化および非アクティブ化のためにモバイル端末に割り当てられた無線ネットワーク一時識別子（ＲＮＴＩ）を用いてＣＲＣフィールドをマスクするプロセッサを含む。
【０１９４】
さらに、基地局の送信器は、下りリンク・コンポーネント・キャリアのアクティブ化および非アクティブ化のためにモバイル端末に割り当てられた無線ネットワーク一時識別子（ＲＮＴＩ）をモバイル端末に送信することができる。
【０１９５】
上で述べたように、本発明の態様は、本明細書で議論されるさまざまな実施形態によるコンポーネント・キャリア・アグリゲーションを使用するモバイル通信システム内で下りリンク・コンポーネント・キャリアを（非）アクティブ化する方法のソフトウェアでの実施およびそのコンピュータ可読記憶媒体への格納である。
【０１９６】
さらなる実施形態によれば、本発明は、モバイル端末のプロセッサによって実行される時に、本明細書で議論されるさまざまな実施形態のうちの１つによるコンポーネント・キャリア・アグリゲーションを使用するモバイル通信システム内で下りリンク・コンポーネント・キャリアを（非）アクティブ化する方法のうちの１つをモバイル端末に実行させる命令を格納するコンピュータ可読媒体を提供する。命令の実行は、たとえば、モバイル端末に、モバイル端末に上りリンクまたは下りリンクのリソースを割り当てるためのリソース割当を下りリンク・コンポーネント・キャリア上で受信させることができ、リソース割当は、複数の構成された下りリンク・コンポーネント・キャリアのどれがそれぞれアクティブ化されまたは非アクティブ化されるのかを示しており、命令の実行は、モバイル端末に、さらに、上りリンク・リソース割当に含まれるビットマスクに従って、構成された下りリンク・コンポーネント・キャリアをアクティブ化または非アクティブ化させることができる。
【０１９７】
本発明のもう１つの実施形態は、基地局のプロセッサによって実行される時に、本明細書で議論されるさまざまな実施形態のうちの１つによるコンポーネント・キャリア・アグリゲーションを使用するモバイル通信システム内で下りリンク・コンポーネント・キャリアを（非）アクティブ化する方法のうちの１つを基地局に実行させる命令を格納するコンピュータ可読媒体を提供している。命令を実行することで、たとえば、基地局に、モバイル端末に上りリンク・リソースを割り当てるための上りリンク・リソース割当を、アクティブの構成された下りリンク・コンポーネント・キャリア上でモバイル端末に送信させることができ、上りリンク・リソース割当は、複数の構成された下りリンク・コンポーネント・キャリアのどれがそれぞれアクティブ化されまたは非アクティブ化されるのかを示すビットマスクを含み、命令を実行することで、基地局に、上りリンク・リソース割当の成功の受信または下りリンク・コンポーネント・キャリアの成功の（非）アクティブ化の肯定応答を、割り当てられた上りリンク・リソース上で受信させることができ、肯定応答は、新たにアクティブ化された下りリンク・コンポーネント・キャリア（１つまたは複数）のチャネル品質測定値（１つまたは複数）の形で受信される。
【０１９８】
本発明のさらなる実施形態は、基地局のプロセッサによって実行される時に、基地局に、モバイル端末に下りリンク・リソースを割り当てるための下りリンク・リソース割当を、アクティブの構成された下りリンク・コンポーネント・キャリア上でモバイル端末に送信させる命令を格納するコンピュータ可読媒体を提供しており、上りリンク・リソース割当は、複数の構成された下りリンク・コンポーネント・キャリアのどれがそれぞれアクティブ化されまたは非アクティブ化されるのかを示す。命令は、さらに、基地局に、割り当てられた下りリンク・リソース上で、下りリンク・リソース割当がその中で送信される同一のサブフレーム内で、下りリンク・データをモバイル端末に送信させる。
【０１９９】
次では、本発明を、添付図面および線図を参照して、より詳細に説明する。図内の類似する詳細または対応する詳細は、同一の符号を用いてマークされる。
【図面の簡単な説明】
【０２００】
【図１】３ＧＰＰ  ＬＴＥシステムの例示的アーキテクチャを示す図である。
【図２】３ＧＰＰ  ＬＴＥの全体的なＥ−ＵＴＲＡＮアーキテクチャの例示的な概要を示す図である。
【図３】３ＧＰＰ  ＬＴＥ（リリース８／９）について定義された下りリンク・コンポーネント・キャリア上の例示的なサブフレーム構造を示す図である。
【図４】３ＧＰＰ  ＬＴＥ  （リリース８／９）について定義された下りリンク・スロットの例示的な下りリンク・リソース・グリッドを示す図である。
【図５】それぞれ下りリンクおよび上りリンクのアクティブ化されたキャリア・アグリゲーションを有する３ＧＰＰ  ＬＴＥ−Ａ（リリース１０）レイヤ２構造を示す図である。
【図６】それぞれ下りリンクおよび上りリンクのアクティブ化されたキャリア・アグリゲーションを有する３ＧＰＰ  ＬＴＥ−Ａ（リリース１０）レイヤ２構造を示す図である。
【図７】３ＧＰＰ  ＬＴＥ−Ａ（リリース１０）での下りリンク・コンポーネント・キャリアと上りリンク・コンポーネント・キャリアとの間の例示的なリンケージを示す図である。
【図８】３ＧＰＰ  ＬＴＥ−Ａ（リリース１０）での下りリンク・コンポーネント・キャリアと上りリンク・コンポーネント・キャリアとの間の例示的なリンケージを示す図である。
【図９】それぞれクロスキャリア・スケジューリング用のＣＩＦフィールドを伴わないおよび伴う、それぞれ３ＧＰＰ  ＬＴＥ（リリース８／９）および３ＧＰＰ  ＬＴＥ−Ａ（リリース１０）のＤＣＩフォーマット０の内容を示す図である。
【図１０】それぞれクロスキャリア・スケジューリング用のＣＩＦフィールドを伴わないおよび伴う、それぞれ３ＧＰＰ  ＬＴＥ（リリース８／９）および３ＧＰＰ  ＬＴＥ−Ａ（リリース１０）のＤＣＩフォーマット０の内容を示す図である。
【図１１】３ＧＰＰ  ＬＴＥ−Ａ（リリース１０）で使用される、本発明の例示的実施形態による構成された下りリンク・コンポーネント・キャリアを（非）アクティブ化するための例示的な改善されたＤＣＩフォーマット０を示す図である。
【図１２】３ＧＰＰ  ＬＴＥ−Ａ（リリース１０）で使用される、本発明の例示的実施形態による構成された下りリンク・コンポーネント・キャリアを（非）アクティブ化するためのもう１つの例示的な改善されたＤＣＩフォーマット０を示す図である。
【図１３】３ＧＰＰ  ＬＴＥ−Ａ（リリース１０）で使用される、本発明の例示的実施形態による構成された下りリンク・コンポーネント・キャリアを（非）アクティブ化するためのもう１つの例示的な改善されたＤＣＩフォーマット０（ＤＣＩフォーマットの内容の解釈は、ＣＩＦフィールドのコードポイントに依存する）を示す図である。
【図１４】３ＧＰＰ  ＬＴＥ−Ａ（リリース１０）で使用される、本発明の例示的実施形態による構成された下りリンク・コンポーネント・キャリアを（非）アクティブ化するためのもう１つの例示的な改善されたＤＣＩフォーマット０（ＤＣＩフォーマットの内容の解釈は、ＣＩＦフィールドのコードポイントに依存する）を示す図である。
【図１５】本発明の実施形態による例示的な３ＧＰＰベースの通信システムで下りリンク・コンポーネント・キャリアを（非）アクティブ化する手順を例示する図である。
【図１６】ＰＨＲ報告およびＳＲＳ信号アクティブ化を含む、本発明の実施形態による例示的な３ＧＰＰベースの通信システムで下りリンク・コンポーネント・キャリアを（非）アクティブ化するもう１つの手順を示す図である。
【図１７】それぞれクロスキャリア・スケジューリング用のＣＩＦフィールドを伴わないおよび伴う、それぞれ３ＧＰＰ  ＬＴＥ（リリース８／９）および３ＧＰＰ  ＬＴＥ−Ａ（リリース１０）のＤＣＩフォーマット１の内容を示す図である。
【図１８】それぞれクロスキャリア・スケジューリング用のＣＩＦフィールドを伴わないおよび伴う、それぞれ３ＧＰＰ  ＬＴＥ（リリース８／９）および３ＧＰＰ  ＬＴＥ−Ａ（リリース１０）のＤＣＩフォーマット１の内容を示す図である。
【図１９】３ＧＰＰ  ＬＴＥ−Ａ（リリース１０）で使用される、本発明の例示的実施形態による構成された下りリンク・コンポーネント・キャリアを（非）アクティブ化するための例示的な改善されたＤＣＩフォーマット１を示す図である。
【図２０】３ＧＰＰ  ＬＴＥ−Ａ（リリース１０）で使用される、本発明の例示的実施形態による構成された下りリンク・コンポーネント・キャリアを（非）アクティブ化するためのもう１つの例示的な改善されたＤＣＩフォーマット１を示す図である。
【図２１】例示的なＭＡＣ  ＰＤＵのフォーマットを示す図である。
【図２２】コンポーネント・キャリアのパワー・ヘッドルームを報告するＭＡＣ制御要素のフォーマットを示す図である。
【図２３】正および負のパワー・ヘッドルームをもたらす、ＵＥ送信電力状況および対応するパワー・ヘッドルームの例示的なシナリオを示す図である。
【図２４】ユーザ機器が電力制限される、すなわち、上りリンクで構成されたコンポーネント・キャリアＣＣ＃１およびＣＣ＃２上で電力スケーリングを適用している、例示的なシナリオを示す図である。
【図２５】特定のコンポーネント・キャリアの電力削減が、他の上りリンク・コンポーネント・キャリア上の送信を考慮し、ＭＰＲＣＣ＃１＆ＣＣ＃２をもたらす、例示的なシナリオを示す図である。
【図２６】特定のコンポーネント・キャリアの電力削減が、コンポーネント・キャリアごとに別々に計算され、異なるＭＰＲすなわちＭＰＲＣＣ＃１およびＭＰＲＣＣ＃２をもたらす、例示的なシナリオを示す図である。
【図２７】ＭＡＣサブヘッダが通常のパワー・ヘッドルームと本発明による仮想パワー・ヘッドルームとの間で区別するための「ＰＨＲタイプ・フラグ」を含む、パワー・ヘッドルームを含むＭＡＣ制御要素のＭＡＣサブヘッダのフォーマットを示す図である。
【発明を実施するための形態】
【０２０１】
以下の段落では、本発明のさまざまな実施形態を説明する。例示のみのために、実施形態のほとんどは、上の背景技術セクションで議論した３ＧＰＰ  ＬＴＥ（リリース８）およびＬＴＥ−Ａ（リリース１０）モバイル通信システムによる直交単一キャリア上りリンク無線アクセス方式に関連して概要を示される。本発明を、たとえば前に説明した３ＧＰＰ  ＬＴＥ（リリース８）およびＬＴＥ−Ａ（リリース１０）通信システムなどのモバイル通信システムに関連して有利に使用することができるが、本発明が、この特定の例示的通信ネットワークでの使用に限定されないことに留意されたい。
【０２０２】
上の背景技術セクションで与えた説明は、本明細書で説明される主として３ＧＰＰ  ＬＴＥ（リリース８）およびＬＴＥ−Ａ（リリース１０）固有の例示的実施形態をよりよく理解するためのものであることが意図されており、本発明は、モバイル通信ネットワーク内のプロセスおよび機能について述べられた特定の実施態様に限定して理解されるべきではない。
【０２０３】
上で説明したように、３ＧＰＰ  ＬＴＥ−Ａ（リリース１０）システムから既知の従来技術の１つの主要な欠点は、下りリンク・コンポーネント・キャリアをアクティブ化するために２つのＰＤＣＣＨを送信する必要があることである。この従来技術解決策の問題は、下りリンク・コンポーネント・キャリアのアクティブ化を示す単一の下りリンクＰＤＣＣＨが、同時にＰＤＳＣＨリソースを割り当てることができないことである。ＰＤＣＣＨおよびＰＤＳＣＨは、３ＧＰＰ  ＬＴＥでは同一のサブフレーム内で送信される。すなわち、ＰＤＣＣＨは、たとえばあるサブフレームの最初の３つのＯＦＤＭシンボル内で送信され、ユーザ機器は、下りリンク・コンポーネント・キャリアがアクティブ化される時を知らないので、ユーザ機器は、新たにアクティブ化される下りリンク・コンポーネント・キャリアのアクティブ化ＰＤＣＣＨがシグナリングされる時に、この下りリンク・コンポーネント・キャリア上の同一のサブフレーム内でＰＤＳＣＨ上の下りリンク・データを受信することができない。
【０２０４】
本発明は、単一の上りリンクまたは下りリンクのリソース割当が、下りリンク・コンポーネント・キャリアをアクティブ化／非アクティブ化するために使用され、さらに、それぞれ上りリンクまたは下りリンクのリソースの同時スケジューリングを可能にする方法を提供する。本発明の一態様によれば、モバイル端末（３ＧＰＰ用語ではユーザ機器と称される）のために構成された個々の下りリンク・コンポーネント・キャリアのアクティブ化／非アクティブ化を可能にする、新しい上りリンク・リソース割当フォーマットが提案される。新しい上りリンク・リソース割当は、構成された下りリンク・コンポーネント・キャリアのアクティブ化状態の表示を含む。すなわち、どの下りリンク・コンポーネント・キャリア（１つまたは複数）がアクティブ化されまたは非アクティブ化されるのかを示す。さらに、本発明のもう１つの態様によれば、モバイル端末のために構成された個々の下りリンク・コンポーネント・キャリアのアクティブ化／非アクティブ化と、モバイル端末への下りリンク・データの送信のための下りリンク・リソースの同時割当とを可能にする、新しい下りリンク・リソース割当フォーマットが提案される。新しい下りリンク・リソース割当は、構成された下りリンク・コンポーネント・キャリアのアクティブ化状態の表示を含む。すなわち、どの下りリンク・コンポーネント・キャリア（１つまたは複数）がアクティブ化されまたは非アクティブ化されるのかを示す。
【０２０５】
両方のリソース割当でのこの表示は、すべての構成されたコンポーネント・キャリアについて、またはＲＲＣ接続モードでユーザ機器のために常にアクティブである必要がある１つの下りリンク・コンポーネント・キャリア（このコンポーネント・キャリアを、ユーザ機器のアンカ・キャリアと称する）以外のすべての構成されたコンポーネント・キャリアについて送信することができる。
【０２０６】
さらに、アクティブ化状態の表示は、たとえば、構成された下りリンク・コンポーネント・キャリアのどれがそれぞれアクティブ化されまたは非アクティブ化されるのかを示すビットマスクによって実施される。
【０２０７】
あるいは、それぞれ上りリンクまたは下りリンクの提案されるリソース割当が、１つの単一の構成された下りリンク・コンポーネント・キャリアをアクティブ化しまたは非アクティブ化するのみならば、表示は、少なくとも（非）アクティブ化される構成された下りリンク・コンポーネント・キャリアの識別子を示す必要がある。構成された下りリンク・コンポーネント・キャリアの識別子の表示は、モバイル端末に、示された下りリンク・コンポーネント・キャリアのアクティブ化状態をトグルさせる（構成されたが非アクティブ化された←→アクティブ）。コンポーネント・キャリアＩＤのシグナリングについて、アンカ・キャリアを上りリンク・リソース割当によってアクティブ化／非アクティブ化できないとすると、
【数５】
2020043580.tif 000008
ビットが必要とされる。ここで、Ｎは、構成されたコンポーネント・キャリアの個数であり、
【数６】
2020043580.tif 000009
は、天井関数である。
【０２０８】
アクティブ化状態の暗黙の表示は、モバイル端末およびアクセス・ネットワーク（基地局）内のアクティブ化状態の脱同期につながる可能性があるので、示された下りリンク・コンポーネント・キャリアのアクティブ化状態（構成されたが非アクティブ化されたまたはアクティブ）を明示的に示している、さらなる追加のビット／フラグを上りリンク・リソース割当に含めることは有利となり得る。
【０２０９】
構成された下りリンク・コンポーネント・キャリアのアクティブ化状態をシグナリングするもう１つの代替案は、必ずアクティブである１つの下りリンク・コンポーネント・キャリア、たとえば下りリンク内の「特殊な」コンポーネント・キャリアまたはアンカ・コンポーネント・キャリア以外のすべての下りリンク・コンポーネント・キャリア、のアクティブ化状態（構成されたが非アクティブ化されたまたはアクティブ）を示す単一のビット／フラグを使用することである。これは、すべての非アンカ・コンポーネント・キャリアの同時アクティブ化または同時非アクティブ化を可能にするのみであるが、シグナリング・オーバーヘッドを大幅に減らす。
【０２１０】
３ＧＰＰ  ＬＴＥ−Ａ（リリース１０）またはキャリア・アグリゲーションを使用する将来のリリースなどの下りリンクでキャリア・アグリゲーションを使用する３ＧＰＰベースの通信システムでの、この新しいそれぞれ上りリンクまたは下りリンクのリソース割当フォーマットの使用を考慮すると、新しいリソース割当フォーマットを、既存ＤＣＩフォーマットの拡張または新しいＤＣＩフォーマットと考えることができる。
【０２１１】
本発明の１つの例示的実施形態では、それぞれ上りリンクまたは下りリンクのリソース割当のＤＣＩフォーマットは、通信システム内で定義される少なくとも１つの他のＤＣＩフォーマットと同一のサイズを有する。さらに、下りリンクでＯＦＤＭを使用する３ＧＰＰベースの通信システムでは、リソース割当が、１つまたは複数のユーザ機器へ下りリンク・コンポーネント・キャリア上のサブフレーム内で送信されるＰＤＣＣＨのペイロード（ＤＣＩ）を形成していると仮定することができ、ユーザ機器は、ＰＤＣＣＨ上のサブフレーム内でシグナリングされる異なるＤＣＩフォーマットに対してブラインド復号を実行する。リソース割当フォーマットについて通信システム内で定義される少なくとも１つの他のＤＣＩフォーマットと同一のサイズを使用することと、このフォーマットの暗黙のまたは明示的な表示を使用することと（下でさらに詳細に説明するように）によって、モバイル端末のブラインド復号の労力を増やさないことが可能である。
【０２１２】
所与のモバイル端末のために構成された下りリンク・コンポーネント・キャリアのアクティブ化状態を示すのにビットマスクを使用する場合に、ビットマスク内のビットのそれぞれは、たとえば、複数の構成された下りリンク・コンポーネント・キャリアのそれぞれの構成された下りリンク・コンポーネント・キャリアに関連しており、そのアクティブ化状態を示す。それぞれ上りリンクまたは下りリンクのリソース割当に含まれるこのビットマスクをチェックすることによって、モバイル端末は、構成された下りリンク・コンポーネント・キャリアのそれぞれについて、それぞれの下りリンク・コンポーネント・キャリアのアクティブ化状態が変更されるかどうか、すなわち構成された下りリンク・コンポーネント・キャリアのどの１つまたは複数がアクティブ化されまたは非アクティブ化される必要があるのかを判定することができる。
【０２１３】
本発明の１つの例示的実施形態および実施態様では、下りリンク・コンポーネント・キャリアを、３つのアクティブ化状態すなわち、非構成、構成されたが非アクティブ化された、およびアクティブのうちの１つであると定義することができる。下りリンク・コンポーネント・キャリアが、構成されたが非アクティブ化された時には、ユーザ機器は、対応するＰＤＣＣＨまたはＰＤＳＣＨを受信する必要はなく、ＣＱＩ測定を実行することも要求されない。逆に、下りリンク・コンポーネント・キャリアがアクティブである時には、ユーザ機器は、ＰＤＳＣＨおよびＰＤＣＣＨ（存在する場合に）を受信しなければならず、ＣＱＩ測定を実行できると期待される。コンポーネント・キャリア（１つまたは複数）の構成の後には、そのコンポーネント・キャリア（１つまたは複数）は、構成されたが非アクティブ化された状態である。下りリンク・コンポーネント・キャリア上でのＰＤＣＣＨおよびＰＤＳＣＨの受信を可能にするために、下りリンク・コンポーネント・キャリアは、構成されたが非アクティブ化された状態からアクティブ状態に遷移される必要がある。新しく提案される上りリンクまたは下りリンクのリソース割当は、たとえば、構成されたが非アクティブ化された状態とアクティブ（「構成されアクティブ化された」）状態との間の状態遷移を示すのに使用することができる。この目的にビットマスクを使用する場合には、ビットマスクの１ビットの論理値１が、そのビットに関連する構成された下りリンク・コンポーネント・キャリアがアクティブであることを示すことができ、ビットマスクの１ビットの論理値０が、そのビットに関連する対応する構成された下りリンク・コンポーネント・キャリアが構成されたが非アクティブ化されたことを示すことができる（またはその逆）。
【０２１４】
提案される上りリンク／下りリンク・リソース割当は、構成された下りリンク・コンポーネント・キャリアの１つで受信されるので、これは、この下りリンク・コンポーネント・キャリアがアクティブ状態であることを暗示する。たとえば、上りリンク／下りリンク・リソース割当が受信される下りリンク・コンポーネント・キャリアを、（常に）モバイル端末のために常に構成されアクティブ化される専用の「特殊な」コンポーネント・キャリア（またはアンカ・コンポーネント・キャリア）とすることができる。したがって、上りリンク・リソース割当は、この特殊なコンポーネント・キャリアについてアクティブ化状態の表示を含む必要がない（が、含むことはできる）。
【０２１５】
特殊なコンポーネント・キャリアのアクティブ化状態の表示もシグナリングされる場合には、提案される新しい上りリンク／下りリンク・リソース割当が特殊なコンポーネント・キャリア上または別の構成されたコンポーネント・キャリア上のどちらでシグナリングされるのかに無関係に、たとえば、本明細書で議論される新しい上りリンク／下りリンク・リソース割当によって、特殊なコンポーネント・キャリアを再構成することが可能である可能性がある。
【０２１６】
さらに、より高度な例示的実施態様では、コンポーネント・キャリア・アクティブ化／非アクティブ化情報を含む上りリンク・リソース割当は、モバイル端末に、新たにアクティブ化されたコンポーネント・キャリア（すなわち、状態が非アクティブ化からアクティブ化に変化したコンポーネント・キャリア（１つまたは複数））のチャネル品質測定値を送信するように指示することもできる。したがって、モバイル端末は、アクティブ化されたコンポーネント・キャリアごとにチャネル品質測定を実行し、測定の結果を、上りリンク・リソース割当によってモバイル端末に割り当てられた上りリンク・リソース上で基地局（３ＧＰＰ用語ではｅノードＢと称する）に送信する。チャネル品質測定結果は、たとえば、ＣＱＩ情報の形でシグナリングし得る。
【０２１７】
チャネル品質測定結果（１つまたは複数）の送信は、モバイル端末が、それぞれ上りリンク・リソース割当を成功して受信し、または構成された下りリンク・コンポーネント・キャリアを成功してアクティブ化／非アクティブ化したことを基地局に示す。したがって、チャネル品質測定結果（１つまたは複数）の送信を、それぞれ上りリンク・リソース割当またはモバイル端末による構成された下りリンク・コンポーネント・キャリアのアクティブ化／非アクティブ化の肯定応答と考えることができる。
【０２１８】
本発明のもう１つの態様は、具体的にはモバイル端末が下りリンク制御チャネル情報（ＤＣＩフォーマット）のブラインド復号を実行すると仮定される時に、新しく提案される上りリンク／下りリンク・リソース割当を「通常の」上りリンク／下りリンク・リソース割当から区別することに関する。したがって、新しく提案されるリソース割当のフォーマットは、他のＤＣＩフォーマットから区別される必要がある場合がある。１つの案は、本明細書で提案されるリソース割当のために新しいＤＣＩフォーマット（新しい所与のサイズの）を定義することである。しかし、これは、新しいＤＣＩフォーマットを復号するためにモバイル端末によって実行される必要があるブラインド復号の試みの増加を暗示するかもしれない。本発明のさらなる実施形態による代替実施態様は、上りリンク／下りリンク・リソース割当をシグナリングするために既存ＤＣＩフォーマットを再利用し、再利用される既存ＤＣＩフォーマットのいくつかのフィールド（１つまたは複数）内の未使用コードポイントを使用することによってまたはコンポーネント・キャリア（非）アクティブ化のためにモバイル端末ごとに定義される新たに定義されたＲＮＴＩを用いてＣＲＣアタッチメントをマスクすることによって、異なる上りリンク・リソース割当フォーマットの区別を提供することである。
【０２１９】
たとえば、ＬＴＥ−Ａ（リリース１０）またはその後継物などの３ＧＰＰベースのシステムで本発明を実施する時に、３ＧＰＰ  ＬＴＥ（リリース８／９）のために定義された上りリンクＤＣＩフォーマット０または３ＧＰＰ  ＬＴＥ（リリース８／９）のために定義された下りリンクＤＣＩフォーマット１Ａを、下りリンク・コンポーネント・キャリア（１つまたは複数）の（非）アクティブ化について再利用することができる。下りリンク・コンポーネント・キャリア（１つまたは複数）を（非）アクティブ化する上りリンク／下りリンク・リソース割当がシグナリングされる場合に、そのＣＲＣを、たとえば、次でＣＣ−ＲＮＴＩと称する、この目的のために定義される新しいユーザ機器固有ＲＮＴＩを用いてスクランブルすることができる。ＣＣ−ＲＮＴＩは、たとえば、ｅノードＢが上りリンク／下りリンク・コンポーネント・キャリア（１つまたは複数）の組を構成する時に、ユーザ機器に割り当てられ得る。ＣＣ−ＲＮＴＩは、たとえば、アグリゲートされる下りリンク／上りリンク・コンポーネント・キャリア（１つまたは複数）の組を含むＲＲＣ接続再構成メッセージ内でユーザ機器にシグナリングされ得る。したがって、ユーザ機器で、ＰＤＣＣＨ（すなわち、このケースではリソース割当）のペイロードのＣＲＣアタッチメントがＣＣ−ＲＮＴＩによってマスクされていることを検出することによって、ユーザ機器は、したがって、ＰＤＣＣＨのペイロードのフォーマットに関して結論を出し、構成された下りリンク・コンポーネント・キャリア（１つまたは複数）の（非）アクティブ化に関する情報を含む上りリンク・リソース割当の異なるフィールドを正しく読み取ることができる。
【０２２０】
本発明のもう１つの代替実施形態によれば、上りリンク／下りリンク・リソース割当内のＣＩＦフィールド（存在する場合に）は、ＰＤＣＣＨのペイロードのフォーマット、すなわち、ペイロードが通常の上りリンク／下りリンク・リソース割当または構成された下りリンク・コンポーネント・キャリア（１つまたは複数）の（非）アクティブ化に関する情報を含む上りリンク・リソース割当のどちらであるのかを示すために使用され得る。背景技術セクションで説明したように、ＣＩＦ（キャリア・インジケータ・フィールド）は、３ビットからなり、特定の制御シグナリング情報用のコンポーネント・キャリアを識別する（すなわちクロスキャリア・スケジューリング・シナリオを使って）。３ビットは８つのコードポイントを提供するが、ユーザ機器のために構成される下りリンク／上りリンク・コンポーネントは多くとも５つであり得るので、ＣＩＦコードポイントのいくつか、すなわちコードポイント６、７、および８は、未使用である。この実施形態によれば、ＣＩＦフィールドのこれらの未使用コードポイントのうちの少なくとも１つは、上りリンク／下りリンク・リソース割当が下りリンク・コンポーネント・キャリア（１つまたは複数）の（非）アクティブ化に関する情報を含むことを示すのに使用され、ユーザ機器は、ＰＤＣＣＨのペイロード内のある種のビットをどのように解釈すべきかを知る。通常の上りリンク／下りリンク・リソース割当（構成された下りリンク・コンポーネント・キャリア（１つまたは複数）の（非）アクティブ化に関する情報を有しない）および構成された下りリンク・コンポーネント・キャリア（１つまたは複数）の（非）アクティブ化に関する情報を有する上りリンク／下りリンク・リソース割当のＤＣＩフォーマットは、ＣＩＦフィールド内でシグナリングされるコードポイントによって区別されるので、上りリンク許可に使用されるものと同一のＲＮＴＩ（Ｃ−ＲＮＴＩ）を使用して、ＣＲＣをスクランブルすることができる。したがって、この代替実施形態では、追加の新しいＣＣ−ＲＮＴＩを定義する必要はない。
【０２２１】
さらに、本発明のもう１つの実施形態では、上で説明したＰＤＣＣＨペイロードのＤＣＩフォーマットをどのように示すかの２つの案は、一緒に使用し得る。背景技術セクションで述べたように、３ＧＰＰ  ＬＴＥ−Ａ（リリース１０）では、上りリンクＰＤＣＣＨ内にＣＩＦが存在するように構成することは可能である。したがって、ユーザ機器は、ＰＤＣＣＨペイロード内にＣＩＦを含めるように構成され、ｅノードＢは、ＰＤＣＣＨペイロードが構成された下りリンク・コンポーネント・キャリア（１つまたは複数）の（非）アクティブ化に関する情報を有するリソース割当であることを示すために、事前定義のＣＩＦコードポイント（１つまたは複数）を使用する。ＰＤＣＣＨペイロード内にＣＩＦを含めないように構成されたユーザ機器は、上で述べたＣＣ−ＲＮＴＩが割り当てられ、このＣＣ−ＲＮＴＩは、構成されたダウンロード・コンポーネント・キャリア（１つまたは複数）の（非）アクティブ化に関する情報を有するリソース割当を通常のリソース割当（構成されたダウンロード・コンポーネント・キャリア（１つまたは複数）の（非）アクティブ化に関する情報を有しない）から区別するのに、ｅノードＢによって使用される。
【０２２２】
上で概要を示したように、ＣＣ−ＲＮＴＩの導入または少なくとも１つのＣＩＦコードポイントの予約は、（非）アクティブ化される下りリンク・コンポーネント・キャリア（１つまたは複数）の表示を組み込むためのＤＣＩフィールドの一部の再定義を可能にする。最大Ｎ＝５個の構成された下りリンク・コンポーネント・キャリアがあり、常にアクティブである特定の下りリンク・コンポーネント・キャリア、たとえばアンカ・キャリアについてシグナリングすべきアクティブ化状態がないと例示的に仮定すると、Ｎ−１＝４ビットが、ビットマスクを使用して下りリンク・コンポーネント・キャリアの任意の組合せをアクティブ化／非アクティブ化することを実現するために必要である。これによって、ビットマスク内の各ビットは、下りリンク・コンポーネント・キャリアのうちの１つのアクティブ化状態を表す。たとえば、「１」をセットされたビットマスク内のビットは、対応する下りリンク・コンポーネント・キャリアをアクティブ化しなければならないことを示すことができ、「０」をセットされたビットは、対応する下りリンク・コンポーネント・キャリアを非アクティブ化しなければならないことを示すことができる（またはその逆）。
【０２２３】
本発明の１つの例示的実施形態では、本発明が実施されるそれぞれのシステムに既に存在するＤＣＩフォーマットの１つが、構成された下りリンク・コンポーネント・キャリア（１つまたは複数）の（非）アクティブ化を示すためのビットマスクのシグナリングを含めるために再定義される。提案される上りリンク・リソース割当の実施態様に関して、既に３ＧＰＰ  ＬＴＥ（リリース８／９）または３ＧＰＰ  ＬＴＥ−Ａ（リリース１０）で定義されている上りリンクＤＣＩフォーマット０を再利用する場合には、ビットマスク内でシグナリングできるようにするためには、このＤＣＩフォーマット内で４ビットが再定義される必要がある（最大Ｎ＝５個の構成された下りリンク・コンポーネント・キャリアがあると仮定して）。図９に、３ＧＰＰ  ＬＴＥ（リリース８／９）のＤＣＩフォーマット０を示す。ＤＣＩフォーマット０は、次からなる。
【０２２４】
−フォーマット・フラグ（フラグ・フォーマット０／１Ａ）、これは、同一のビット数／サイズを有するように定義される、ＤＣＩフォーマット０とＤＣＩフォーマット１Ａとを区別するためのである、
−ホッピング・フラグ（Ｈｏｐｐｉｎｇ  Ｆｌａｇ）、これは、ユーザ機器が上りリンク・リソース・ホッピングを使用すべきか否かを示すものである、
−リソース・ブロック割当フィールド、これは、ユーザ機器にＰＵＳＣＨ上の上りリンク・リソースを割り当てるものである（非周期的チャネル品質フィードバックをトリガする時には、チャネル品質フィードバックおよび任意選択でさらなるユーザ・データが、そのＰＵＳＣＨを介して、これらの割り当てられるリソース上で多重化され、送信される）、
−変調および符号化方式フィールド（ＭＣＳ＆ＲＶ）、これは、ＰＵＳＣＨ上で割り当てられたリソースの送信に関する変調方式、符号化レート、および冗長性バージョンを示すものである、
−新データ・インジケータ（ＮＤＩ）、これは、ユーザ機器が新しいデータを送信しなければならないのかまたは再送信をしなければならないのかを示すものである、
−ＤＭＲＳフィールド（サイクリック・シフトＤＭＲＳ）、これは、基準シンボル・シーケンスに適用される循環シフトを構成するためのものである、
−ＣＱＩ要求フラグ、これは、ユーザ機器からの非周期的チャネル品質フィードバック報告をトリガするためのである、および
−１つまたは複数のパディング・ビット、これは、専用制御情報のサイズを所定のビット数に整列させるためのものであり、このビットは必要な場合に（すなわち、オプションで）設けられる。
【０２２５】
さらに、図１０に示されているように、３ＧＰＰ  ＬＴＥ−Ａ（リリース１０）の拡張されたＤＣＩフォーマット０は、シグナリングされるリソース割当がクロススケジューリング・シナリオで関係する上りリンク・コンポーネント・キャリアを示すためのＣＩＦフィールドをさらに含むことを除いて、３ＧＰＰ  ＬＴＥ（リリース８／９）のＤＣＩフォーマット０に本質的に類似する。
【０２２６】
下りリンク・コンポーネント・キャリア（１つまたは複数）の（非）アクティブ化に関する情報を含む上りリンク・リソース割当によってスケジューリングされる上りリンク送信が、新しい初期送信を暗示するという仮定の下で、通常は初期／再送信を示すＮＩＤビットを再利用することができる。同様に、「ＣＱＩ要求」フラグを再利用することができる。というのは、下りリンク・コンポーネント・キャリア（１つまたは複数）がアクティブ化される時にユーザ機器が必ず非周期的ＣＱＩを送信しなければならないことを、ルールによって定義できるからである。４ビット・ビットマスクのシグナリングのために要求される残りの２ビットは、たとえば、ＴＰＣビットから盗用することができる。というのは、このビットは、非周期的ＣＱＩの送信のために必要ではなく、上りリンク送信の耐性は現状の変調および符号化方式を正しく選択することによって達成することもできるので、さらなる電力制御が要求されない可能性があるからである。
【０２２７】
したがって、ユーザ機器は、どのＲＮＴＩがＣＲＣアタッチメントのＣＲＣ符号をスクランブルするのに使用されたのかに依存して、ＰＤＣＣＨから入手された復号された下りリンク制御チャネル情報の内容を解釈することができる。ＣＣ−ＲＮＴＩが、上りリンク・リソース割当のＣＲＣをマスクするために基地局によって使用された場合には、ユーザ機器は、ＤＣＩフォーマット０のＮＤＩフラグ、ＴＰＣフィールド、およびＣＱＩフラグを、構成された下りリンク・コンポーネント・キャリア（１つまたは複数）のどれが（非）アクティブ化されるのかを示す４ビットのビットマスクとして解釈する。図１１に、３ＧＰＰ  ＬＴＥ−Ａ（リリース１０）で使用される、本発明の例示的実施形態による構成された下りリンク・コンポーネント・キャリアを（非）アクティブ化するための例示的な改善されたＤＣＩフォーマット０を示す。ここで、ＮＤＩフラグ、ＴＰＣフィールド、およびＣＱＩフラグは、ＣＣ−ＲＮＴＩがＣＲＣをスクランブルするのに使用された場合に、ビットマスクとして解釈される。ＣＲＣアタッチメント内のＣＲＣが、Ｃ−ＲＮＴＩを用いてマスクされている場合には、ユーザ機器は、ＤＣＩフォーマット０のフィールドを、３ＧＰＰ  ＬＴＥ（リリース８／９）について定義され、図９に示されているものとして、すなわち「通常の」上りリンク・リソース割当として解釈する。
【０２２８】
図１２に、３ＧＰＰ  ＬＴＥ−Ａ（リリース１０）で使用される、本発明の例示的実施形態による構成された下りリンク・コンポーネント・キャリアを（非）アクティブ化するためのもう１つの例示的な改善されたＤＣＩフォーマット０を示す。この例では、３ＧＰＰ  ＬＴＥ（リリース８／９）から既知であるＤＣＩフォーマット０に基づく新しいＤＣＩフォーマットが定義される。図１１の例に関しては、フォーマットのサイズが、ＤＣＩフォーマット０および１Ａに類似していることが保証できるので、この新しいＤＣＩフォーマットを復号するためにユーザ機器がさらなるブラインド復号をする必要がなくなる。図１２に示された例示的なＤＣＩフォーマットでは、ビットマスクを伝えるために４ビットからなる、新しいＤＬ  ＣＣ（非）アクティブ化フィールドが定義される。上で図１１に関連して概要を示したように、ＮＤＩフラグ、ＴＰＣフィールドおよびＣＱＩフラグは、ＤＬ  ＣＣ（非）アクティブ化フィールドに対応するために図１２の上りリンク・リソース割当では省略される。
【０２２９】
上で説明した例示的実施形態は、３ＧＰＰ  ＬＴＥ（リリース８／９）のＤＣＩフォーマット０の再利用に関連して説明されたが、同様に、３ＧＰＰ  ＬＴＥ−Ａ（リリース１０）のＤＣＩフォーマット０を再利用することが可能である。後者の場合、構成された下りリンク・コンポーネント・キャリアを（非）アクティブ化するための上りリンク・リソース割当のＤＣＩフォーマット再利用または新しいＤＣＩフォーマットは、ＣＩＦフィールドをさらに含むことを除いて、図１１および図１２の例と同様である。
【０２３０】
ＮＤＩフラグ、ＴＰＣフィールド、およびＣＱＩフラグの再利用が、３ＧＰＰ  ＬＴＥ（リリース８／９）およびＬＴＥ−Ａ（リリース１０）のＤＣＩフォーマット０のフィールドの再利用の一例にすぎないことにも留意されたい。もう１つのオプションは、下りリンク・コンポーネント・キャリア（１つまたは複数）を（非）アクティブ化するためのビットマスクをシグナリングするのに使用できる４ビットを解放するために、フラグ・フォーマット０／１Ａ、ＴＰＣフィールド、およびＣＱＩフラグ、またはその代わりにフラグ・フォーマット０／１Ａ、ＴＰＣフィールド、およびＮＤＩフラグを再利用することである。ＣＣ−ＲＮＴＩがＤＣＩフォーマットを示すのに使用される場合には、フラグ・フォーマット０／１Ａは、もはやＤＣＩフォーマット内で必要ではなく、したがって再利用することができる。
【０２３１】
代替案では、上りリンク・リソース割当によってスケジューリングされる上りリンク送信が耐性があるものであると仮定すると、高いスペクトル効率をうむ変調方式（６４−ＱＡＭなど）は、要求される送信に使用されない可能性が高い。これは、変調および符号化方式のシグナリング用のＭＣＳフィールドの５ビットのうちの４ビットだけが使用されることを可能にし、その結果、２４＝１６個のＭＣＳレベル「だけ」をシグナリングできるようになる。ＭＣＳフィールドの「解放された」１ビットを、ビットマスクの１ビットとして使用することもできる。これは、たとえば、４ビット・ビットマスクのシグナリングのために、フラグ・フォーマット０／１Ａ、ＮＤＩフラグ、ＭＳＣフィールドの１ビット、およびＣＱＩフラグを再利用することを可能にする。この形で、ＴＰＣコマンドをそれでもシグナリングすることができ、これによって、上りリンク送信の信頼性の制御がさらに改善される。
【０２３２】
したがって、下りリンク・コンポーネント・キャリアのアクティブ化状態をシグナリングするためのビットマスクは、３ＧＰＰ  ＬＴＥ（リリース８／９）または３ＧＰＰ  ＬＴＥ−Ａ（リリース１０）のＤＣＩフォーマット０の中の、次のフィールドの任意の組合せによって形成することができる。なお、次のフィールドは、ビットマスクのシグナリングのための４ビットをうむ。
【０２３３】
−フラグ・フォーマット０／１Ａ（１ビット）、
−ＭＳＣフィールドの１ビット、
−ＮＤＩフラグ（１ビット）、
−ＴＰＣコマンド・フィールド（２ビット）、および
−ＣＱＩ要求フラグ（１ビット）。
【０２３４】
代替案では、前に述べたように、上りリンク・リソース割当が、１つの単一の構成された下りリンク・コンポーネント・キャリアだけをアクティブ化しまたは非アクティブ化する場合、表示は、少なくとも、（非）アクティブ化される構成された下りリンク・コンポーネント・キャリアの識別子を示す必要がある。構成された下りリンク・コンポーネント・キャリアの識別子の表示は、モバイル端末に、示された下りリンク・コンポーネント・キャリアのアクティブ化状態をトグルさせる（構成されたが非アクティブ化された←→アクティブ）。コンポーネント・キャリアＩＤをシグナリングするためには、アンカ・キャリアを上りリンク・リソース割当によってアクティブ化／非アクティブ化できないとすると、
【数７】
2020043580.tif 000010
ビットが必要である。Ｎ＝５の場合に、これは、それぞれ、（非）アクティブ化される構成された下りリンク・コンポーネント・キャリアの表示をシグナリングするために２ビットが要求され、または（非）アクティブ化される構成された下りリンク・コンポーネント・キャリアの表示およびアクティブ化状態の明示的表示をシグナリングするために３ビットが要求されることを意味する。
【０２３５】
もう１つの実施形態によれば、１つの下りリンク・コンポーネント・キャリアのアクティブ化状態をシグナリングするためのＤＬ  ＣＣ（非）アクティブ化フィールドは、３ＧＰＰ  ＬＴＥ（リリース８／９）または３ＧＰＰ  ＬＴＥ−Ａ（リリース１０）のＤＣＩフォーマット０の中の、次のフィールドの任意の組合せによって形成することができる。なお、次のフィールドは、（非）アクティブ化される１つの下りリンク・コンポーネント・キャリアの識別子（およびアクティブ化状態の明示的表示）をシグナリングするための２ビット（または３ビット）をうむ。
【０２３６】
−フラグ・フォーマット０／１Ａ（１ビット）、
−ＭＳＣフィールドの１ビット、
−ＮＤＩフラグ（１ビット）、
−ＴＰＣコマンド・フィールド（２ビット）、および
−ＣＱＩ要求フラグ（１ビット）。
【０２３７】
（非）アクティブ化される１つの下りリンク・コンポーネント・キャリアの識別子およびアクティブ化状態の明示的表示をシグナリングするための３ビットを得る１つの例示的実施態様は、フラグ・フォーマット０／１Ａ、ＮＤＩフラグ、およびＣＱＩ要求フラグの組合せである。同様に、ＴＰＣコマンド・フィールドと、フラグ・フォーマット０／１Ａ、ＮＤＩフラグ、およびＣＱＩ要求フラグのうちの１つとを使用することもできる。
【０２３８】
もう１つの例示的実施形態では、構成された下りリンク・コンポーネント・キャリアのアクティブ化状態は、常にアクティブである１つの下りリンク・コンポーネント・キャリア、たとえば下りリンクの「特殊な」コンポーネント・キャリアまたはアンカ・コンポーネント・キャリア以外のすべての下りリンク・コンポーネント・キャリアのアクティブ化状態（構成されたが非アクティブ化されたまたはアクティブ）を示す単一のビット／フラグによってシグナリングされる。これは、すべての非アンカ・コンポーネント・キャリアの同時アクティブ化または非アクティブ化を可能にするのみであるが、シグナリング・オーバーヘッドを大幅に減らす。この単一ビット／（非）アクティブ化フラグをシグナリングするために、３ＧＰＰ  ＬＴＥ（リリース８／９）または３ＧＰＰ  ＬＴＥ−Ａ（リリース１０）のＤＣＩフォーマット０の次のフラグ
−フラグ・フォーマット０／１Ａ（１ビット）、
−ＭＳＣフィールドの１ビット、
−ＮＤＩフラグ（１ビット）、
−ＴＰＣコマンド・フィールド（２ビット）、
−ＣＱＩ要求フラグ（１ビット）
のうちの１つを再利用することができる。
【０２３９】
３ＧＰＰの状況で、下りリンク・コンポーネント・キャリアのアクティブ化状態のシグナリングを可能にする下りリンク・リソース割当の実施態様に関して、本発明のもう１つの実施形態は、３ＧＰＰ  ＬＴＥ（リリース８／９）または３ＧＰＰ  ＬＴＥ−Ａ（リリース１０）の下りリンクＤＣＩフォーマット１Ａの再利用または再定義を提案する。
【０２４０】
３ＧＰＰ  ＬＴＥ（リリース８／９）のＦＤＤモードのための下りリンクＤＣＩフォーマット１Ａは、図１７に示されており、次のものから構成される。
【０２４１】
−フォーマット・フラグ（フラグ・フォーマット０／１Ａ）、これは、同一のビット数／サイズを有するように定義され、ＤＣＩフォーマット０とＤＣＩフォーマット１Ａとを区別するものである、
−局所化／分散割当フラグ、これは、局所化送信モードまたは分散送信モードのどちらが使用されるのかを示すものである、
−リソース・ブロック割当（ＲＢＡ）フィールド、これは、所与のリソース割当タイプに従ってユーザ機器にＰＤＳＣＨ上の下りリンク・リソース（リソース・ブロック）を割り当てるためのものであり、ＲＢＡフィールドに要求されるビット数は、割当タイプ（ＲＡフィールド）および割り当てられるコンポーネント・キャリアの帯域幅に依存する、
−変調および符号化方式フィールド（ＭＣＳ）、これは、ＰＤＳＣＨ上で割り当てられるリソース上の送信の変調方式、符号化レート、および冗長性バージョンを示すものである、
−ＨＡＲＱプロセス番号、これは、割り当てられるリソース上の下りリンク送信に使用されるＨＡＲＱプロセスを示すものである、
−新データ・インジケータ（ＮＤＩ）フラグ、これは、所与のＨＡＲＱプロセス上の送信が新しいプロトコル・データ・ユニット（ＰＤＵ）であることを示すものである、
−冗長バージョン（ＲＶ）フィールド、これは、割り当てられたリソース上の下りリンク送信の冗長性バージョンを示すものである、
−送信電力制御（ＴＰＣ）コマンド・フィールド、これは、ＰＵＣＣＨ上の制御情報を送信するためのものである。
【０２４２】
３ＧＰＰ  ＬＴＥ−Ａ（リリース１０）の下りリンクＤＣＩフォーマット１Ａは、図１８に示され、３ＧＰＰ  ＬＴＥ（リリース８／９）の下りリンクＤＣＩフォーマット１のフィールドに加えて、リソースがどのコンポーネント・キャリアに割り当てられるのかを示すキャリア・インジケータ・フィールド（ＣＩＦ）が割り当てられる。ＴＤＤモードのために、３ＧＰＰ  ＬＴＥ（リリース８／９）および３ＧＰＰ  ＬＴＥ−Ａ（リリース１０）のＤＣＩフォーマット１Ａは、さらに、下りリンク割当インデックスを有する。
【０２４３】
本発明のもう１つの実施形態によれば、ＤＣＩフォーマット１ＡのＮＤＩビットは、ｅノードＢが常にアクティブの下りリンク・コンポーネント・キャリア以外のすべての下りリンク・コンポーネント・キャリアをアクティブ化しまたは非アクティブ化することを可能にするフラグ（ＤＬ  ＣＣ（非）アクティブ化フラグ）を提供するために再利用される。ＤＬ  ＣＣ（非）アクティブ化フラグを含む下りリンク・リソース割当の新しいＤＣＩフォーマットの例を、図１９に示す。本発明のもう１つの代替実施形態では、ＤＣＩフォーマット１ＡのＰＵＣＣＨフィールドのＴＰＣコマンドまたはＰＵＣＣＨフィールドのＮＤＩフラグおよびＴＰＣコマンドが、再利用され、ＤＬ  ＣＣ（非）アクティブ化フラグを形成する。下りリンク・リソース割当の例示的ＤＣＩフォーマットを、図２０に示す。
【０２４４】
図１９および図２０の例のＤＣＩフォーマットが、さらに、図１８に示されているようにＣＩＦフィールドを含み得ることに留意されたい。ＤＣＩフォーマット１ＡのＮＤＩフラグが再利用される場合には、ＤＬ  ＣＣ（非）アクティブ化フラグを含む提案された下りリンク・リソース割当が受信される時に、割り当てられた下りリンク・リソース上でのユーザ機器への下りリンク送信（トランスポート・ブロック）が、必ず初期送信であると定義することが望ましいかもしれない。さらに、ユーザ機器は、下りリンク送信を提供するＨＡＲＱプロセスの既知のＮＤＩ値を仮定することもできる。
【０２４５】
上で説明したすべての代替案では、ＤＣＩフォーマットのフィールドの再利用およびＣＲＣのマスキングに使用されるＲＮＴＩに依存する内容の解釈を使用することができ（図１１に関連して説明したように）、あるいは、ＤＣＩフィールドの結果の内容を、新しいＤＣＩフォーマットとして定義することができる（図１２、１９、および２０に関連して説明したように）ことに留意されたい。
【０２４６】
上の段落で議論された、アクティブ化されまたは非アクティブ化される下りリンク・コンポーネント・キャリア（１つまたは複数）の表示をどのようにシグナリングするのかの例では、基地局が、それぞれのユーザ機器によって構成された下りリンク・コンポーネント・キャリアのアクティブ化および非アクティブ化に関連する情報をシグナリングするためにユーザ機器に特殊なＲＮＴＩ（ＣＣ−ＲＮＴＩ）を割り当てると仮定した。ＣＣ−ＲＮＴＩの使用に基づいて、ユーザ機器は、それぞれ、ＰＤＣＣＨ上で受信された上りリンク／下りリンク・リソース割当のＤＣＩフォーマットをどのように解釈する必要があるのか、またはそれにどのフィールドが含まれるのかを判定することができる。
【０２４７】
本発明のもう１つの実施形態によるもう１つの代替実施態様では、ｅノードＢは、ＰＤＣＣＨペイロードが、構成された下りリンク・コンポーネント・キャリア（１つまたは複数）の（非）アクティブ化に関する情報を伴う上りリンク／下りリンク・リソース割当であることを示すために１つまたは複数の事前定義のＣＩＦコードポイントを使用し、その結果、特殊なＲＮＴＩは不要になる。したがって、ユーザ機器は、ＰＤＣＣＨを復号し、ＣＩＦフィールド内でシグナリングされるコードポイントに依存してＤＣＩフォーマット（それぞれ、ＤＣＩフォーマット内の内容／残りのフィールドの解釈）を判定する。このケースでは、ＰＤＣＣＨによって示される割り当てられた上りリンク／下りリンク・リソースは、事前定義の上りリンク／下りリンク・コンポーネント・キャリアまたは非クロスキャリア・スケジューリングの場合すなわちＣＩＦフィールドが存在しなかった場合に使用される上りリンク／下りリンク・コンポーネント・キャリアのいずれかのためのものである。これは、たとえば、モバイル端末の上りリンク／下りリンク・アンカ・コンポーネント・キャリアであり得る。
【０２４８】
図１３および図１４に、３ＧＰＰ  ＬＴＥ−Ａ（リリース１０）で使用される、本発明のこの実施形態による構成された下りリンク・コンポーネント・キャリアを（非）アクティブ化するための例示的な改善された上りリンクＤＣＩフォーマット０を示す。この実施の形態では、ＤＣＩフォーマットの内容の解釈は、ＣＩＦフィールドのコードポイントに依存する。ＣＩＦフィールドのコードポイントが「１１１」である場合には、ＤＣＩフォーマット（上りリンク・リソース割当）は、下りリンク・コンポーネント・キャリアのアクティブ化状態をシグナリングするためのＤＬ  ＣＣ（非）アクティブ化フィールドを含み（図１３を参照されたい）、コードポイントが「１１１」ではない場合には、ＤＣＩフォーマットは、図１０に示されたＤＣＩフォーマット０であり、ＣＩＦフィールドは、上りリンク・リソースが割り当てられるクロススケジューリングされたコンポーネント・キャリアを示す。ＤＣＩフォーマットを示すための特殊なＣＩＦコードポイント（１つまたは複数）の定義が、もちろん、ＣＩＦフィールドがフォーマットに追加されると仮定すれば、下りリンク割当のケースについて図１９および図２０に示されたＤＣＩフォーマットにも適用可能であることに留意されたい。
【０２４９】
本発明のもう１つの実施形態によるもう１つの代替実施態様では、ＤＣＩフォーマット（リソース割当）が、それぞれアクティブ化されまたは非アクティブ化される少なくとも１つのＤＬコンポーネント・キャリアを識別する情報を含むことを示すために、２つの事前定義のＣＩＦコードポイントが使用される。ＣＩＦフィールドのコードポイントが「１１１」である場合には、ＤＣＩフォーマット（リソース割当）は、識別子フィールドによって識別される少なくとも１つの下りリンク・コンポーネント・キャリアがアクティブ化されていることを示し、ＣＩＦフィールドのコードポイントが「１１０」である場合には、ＤＣＩフォーマットは、ＤＣＩフォーマット内の識別子フィールドによって識別される少なくとも１つの下りリンク・コンポーネント・キャリアが非アクティブ化されていることを示す。
【０２５０】
本発明のさらなるもう１つの態様は、下りリンク・コンポーネント・キャリア（非）アクティブ化に応答する非周期的ＣＱＩの送信に関する。上で説明したように、１つの例の実施態様では、上りリンク・リソース割当による下りリンク・コンポーネント・キャリアのアクティブ化（構成されたが非アクティブ化された状態からアクティブ状態への遷移）は、モバイル端末に、新たにアクティブ化されたコンポーネント・キャリアのそれぞれについてチャネル品質測定を実行させ、測定の結果を基地局にシグナリングさせる。下りリンク・コンポーネント・キャリアを（非）アクティブ化する時に基地局がＣＱＩ情報を受信することは、必ずしも必要でないまたは有益ではない可能性があるので、基地局がチャネル品質測定値の送信をイネーブル／ディスエーブルできるようにすることが、望ましいかもしれない。ＣＱＩ要求フラグが下りリンク・コンポーネント・キャリアのアクティブ化状況の表示をシグナリングするのに使用されない実施態様では、ＣＱＩ要求フラグを基地局によって使用して、新たにアクティブ化された下りリンク・コンポーネント・キャリアのＣＱＩ情報の送信を制御することができる。
【０２５１】
ＣＱＩ要求フラグが下りリンク・コンポーネント・キャリアのアクティブ化状況の表示をシグナリングするのに使用されるケースについて、本発明の一実施形態に従って、リソース・ブロック割当（ＲＢＡ）フィールド内でシグナリングされるコードポイントをセットすることによってチャネル品質フィードバック／ＣＱＩの送信を制御することが提案される。たとえば、ＲＢＡフィールドに、無効なリソース割当であるすべて「１」をセットすることによって、基地局は、チャネル品質フィードバック／ＣＱＩ報告を無効にし得る。ユーザ機器は、それでも、シグナリングされた通りに下りリンク・コンポーネント・キャリア（１つまたは複数）を（非）アクティブ化するが、新たにアクティブ化されたコンポーネント・キャリアのチャネル品質フィードバック／ＣＱＩ情報を送信しない。
【０２５２】
チャネル品質報告を抑制するもう１つの実現性は、上りリンク・リソース割当フォーマットを区別するためのＣＩＦフラグの使用（上で図１３および図１４に関連して説明した）に関係する。複数のＣＩＦコードポイントが必要ではない可能性があるので、２つのコードポイントを、上りリンク・リソース割当のフォーマットを示すために予約することができる。この２つのコードポイントの一方は、下りリンク・コンポーネント・キャリア（１つまたは複数）の（非）アクティブ化に関する情報を含む上りリンク・リソース割当を示すために定義され得、新たにアクティブ化された下りリンク・コンポーネント・キャリアに関するチャネル品質を報告するようにモバイル端末に要求する。一方、２つのコードポイントの他方は、下りリンク・コンポーネント・キャリア（１つまたは複数）の（非）アクティブ化に関する情報を含む上りリンク・リソース割当を示すために定義され得、新たにアクティブ化された下りリンク・コンポーネント・キャリアに関するチャネル品質を報告しないようにモバイル端末に要求する。
【０２５３】
下りリンク・コンポーネント・キャリア（非）アクティブ化シグナリングに十分な耐性を提供するために、本発明のもう１つの実施形態では、上りリンク・リソース割当によって割り当てられる上りリンク・リソース上の送信（下りリンク・コンポーネント・キャリア（非）アクティブ化に関する情報を含む）が、上りリンク・リソース割当の受信の肯定応答として働くことを提案する。したがって、チャネル品質が、割り当てられた上りリンク・リソース上で報告される場合に、基地局でのこのチャネル品質情報の受信時に、基地局は、上りリンク・リソース割当（下りリンク・コンポーネント・キャリア（非）アクティブ化に関する情報を含む）がモバイル端末によって正しく受信されたと仮定することができる。
【０２５４】
図１５に、本発明の実施形態による例示的な３ＧＰＰベースの通信システムで下りリンク・コンポーネント・キャリアを（非）アクティブ化する手順を例示する。キャリア・アグリゲーションのために構成された２つの下りリンク・コンポーネント・キャリア（ＤＬ  ＣＣ１およびＤＬ  ＣＣ２）および１つの上りリンク・コンポーネント・キャリア（ＵＬ  ＣＣ１）があると例示的に仮定する。まず、ＤＬ  ＣＣ２が非アクティブ化され、ＤＬ  ＣＣ１およびＵＬ  ＣＣ１だけがアクティブである（ＵＬ  ＣＣ１およびＤＬ  ＣＣ１は、ユーザ機器がＲＲＣ接続モードで少なくとも１つのアクティブな上りリンクおよび下りリンクのコンポーネント・キャリアを常に有する必要があるので、常にアクティブである）。
【０２５５】
時刻Ｔ１、たとえばＤＬトラフィック需要が増える時に、ｅノードＢは、ＤＬ  ＣＣ２のアクティブ化を開始するＣＣ−ＲＮＴＩを用いてスクランブルされた上りリンク・リソース割当（ＵＬ  ＰＤＣＣＨ）を送信することによって、ユーザ機器のためにＤＬ  ＣＣ２をアクティブ化する。ユーザ機器での上りリンク・リソース割当の受信時に、ユーザ機器は、ＤＬ  ＣＣ２をアクティブ化し、たとえば、対応するＰＤＣＣＨ／ＰＤＳＣＨの監視を開始し、ＤＬ  ＣＣ２のチャネル品質（ＣＱＩ情報）を測定する。ＣＱＩのフォーマットを、たとえばｅノードＢによって事前に構成することができ、その結果、ユーザ機器は、広帯域ＣＱＩまたは周波数選択的ＣＱＩのどちらを報告すべきなのかを知る。ユーザ機器は、時刻Ｔ２に、時刻Ｔ１に受信された上りリンク・リソース割当によって上りリンク（ＵＬ  ＣＣ１）に割り当てられたＰＵＳＣＨリソース上で、計算されたＣＱＩ情報を送信する。ＣＱＩ情報は、３ＧＰＰ  ＬＴＥ（リリース８／９）で予見された実施態様と同様に、時刻Ｔ１に受信された上りリンク・リソース割当の受信から４ｍｓ後に送信される。
【０２５６】
ｅノードＢがアクティブ化された下りリンク・コンポーネント・キャリアＤＬ  ＣＣ１、ＤＬ  ＣＣ２上のいくつかのサブフレームで下りリンク・データを送信したそのいくつかのサブフレームの後に、ｅノードＢは、ＤＬ  ＣＣ２を非アクティブ化すると判断する。したがって、ｅノードＢは、時刻Ｔ３に、ＣＣ−ＲＮＴＩおよびＤＬ  ＣＣ２の非アクティブ化を示す対応するビットマスクを用いてスクランブルされたもう１つの上りリンク・リソース割当（ＵＬ  ＰＤＣＣＨ）を送信する。非アクティブ化された下りリンク・コンポーネント・キャリアのＣＱＩ情報は有用ではない可能性があるので、ｅノードＢは、ＣＱＩ送信を無効にするために、ＲＢＡフィールドにすべて「１」をセットすることができる。
【０２５７】
時刻Ｔ１およびＴ３の上りリンク・リソース割当が、それぞれ下りリンク・コンポーネント・キャリアＤＬ  ＣＣ２のアクティブ化または非アクティブ化に使用されるので、ｅノードＢが、同時に、下りリンク・コンポーネント・キャリアを（非）アクティブ化し、アンカ・キャリアすなわちＤＬ  ＣＣ１上で下りリンク・データを送信できることにも留意されたい。
【０２５８】
上で述べたいくつかの実施形態によれば、チャネル品質フィードバックは、下りリンク・コンポーネント・キャリア（１つまたは複数）をアクティブ化する上りリンク・リソース割当によって割り当てられたＰＵＳＣＨリソース上で上りリンクでＣＱＩ情報すなわち非周期的ＣＱＩによって提供された。さらなる実施形態では、新たにアクティブ化された下りリンク・コンポーネント・キャリア（１つまたは複数）について報告されるチャネル品質情報に加えて、モバイル端末は、オプションで、さらに、アクティブ化された下りリンク・コンポーネント・キャリア（１つまたは複数）にリンクされた上りリンク・コンポーネント・キャリア（１つまたは複数）上でサウンディング基準信号（１つまたは複数）（ＳＲＳ）および／または新たにアクティブ化された下りリンク・コンポーネント・キャリア（１つまたは複数）にリンクされた上りリンク・コンポーネント・キャリア（１つまたは複数）のパワー・ヘッドルーム報告（ＰＨＲ）情報を送信することができる。ＰＨＲ情報は、上りリンク・リソース割当によって割り当てられた上りリンク・リソース上で送信される。ＳＲＳおよびＰＨＲ情報は、たとえば、ＰＵＳＣＨ送信を効率的にスケジューリングするためにｅノードＢにとって有用である。
【０２５９】
したがって、本発明のこの実施形態によれば、基地局は、下りリンク・コンポーネント・キャリア（１つまたは複数）をアクティブ化する時に、ＰＨＲ送信および／またはＳＲＳをスケジューリングし得る。それゆえ、新しい提案されるプリンク・リソース割当によって割り当てられた上りリンク・リソース上でのアクティブ化された下りリンク・コンポーネント・キャリアのチャネル品質の報告の代わりにまたはそれに加えて、モバイル端末は、ＳＲＳおよび／またはＰＨＲ報告などのスケジューリング関連情報を基地局にシグナリングすることもできる。
【０２６０】
図１６に示された例示的シナリオでは、ＵＬ  ＣＣ２のパワー・ヘッドルーム情報が、ＵＬ  ＣＣ１上で送信される。ユーザ機器がＵＬ  ＣＣ２のパワー・ヘッドルームを計算しなければならないサブフレームのＵＬ  ＣＣ２上での上りリンク・リソース割当がないので、本発明のさらなる態様および実施形態によれば、ＵＬ  ＣＣ２のパワー・ヘッドルームの計算は、３ＧＰＰ  ＬＴＥ（リリース８／９）と比較して再定義される。３ＧＰＰ  ＬＴＥ（リリース８／９）では、パワー・ヘッドルーム報告は、ユーザ機器がＰＵＳＣＨ上での送信のための上りリンク割当（トランスポート・ブロック）を有するサブフレーム内でのみ送信され得る。というのは、パワー・ヘッドルームが、ユーザ機器の公称最大送信電力とＰＵＳＣＨ上の割り当てられた上りリンク送信の推定電力との間の差を示すからである。パワー・ヘッドルームが報告される上りリンク・コンポーネント・キャリア上に上りリンク割当がないケースのために、パワー・ヘッドルームが判定されなければならないサブフレームの上りリンク・リソース割当を有しない上りリンク・コンポーネント・キャリアのパワー・ヘッドルームが、事前に構成された基準上りリンク・リソース割当を使用することによって計算されることを提案する。本質的に、パワー・ヘッドルームは、ユーザ機器の公称最大送信電力と事前に構成された基準上りリンク・リソース割当による上りリンク送信の推定電力との間の差で示してある。事前に構成された基準上りリンク・リソース割当は、たとえば、無線リソース制御（ＲＲＣ）シグナリングによってユーザ機器にシグナリングされ得る。
【０２６１】
事前に構成された基準上りリンク・リソース割当を使用する、上りリンク割当を伴わない上りリンク・コンポーネント・キャリアのパワー・ヘッドルームの計算に関する本発明の詳細な実施形態は、後で説明する。
【０２６２】
同様に、チャネル品質報告に関して、それぞれＳＲＳまたはＰＨＲの送信も、すべての場合に有益／必要なわけではない。したがって、上で説明した実施形態と同様に、基地局は、下りリンク・コンポーネント・キャリア（１つまたは複数）をアクティブ化しまたは非アクティブ化する時に、ＳＲＳおよび／またはＰＨＲ報告をイネーブル／ディスエーブルすることもできる。これは、チャネル品質フィードバックの抑制に関して上で説明したものに類似する機構によって達成することができる。したがって、上りリンク・リソース割当に特殊なフラグを含めることまたは上りリンク・リソース割当のＣＩＦフィールドもしくはＲＢＡフィールド内で特殊なコードポイントを定義することを使用して、ＳＲＳおよび／またはＰＨＲ報告を送信することが要求されるかどうかをモバイル端末に示すことができる。
【０２６３】
代替案では、所定のルールが、ＳＲＳ／ＰＨＲ情報を送信すべきかどうかを定義することができる。たとえば、モバイル端末は、リンクされた上りリンク・コンポーネント（１つまたは複数）がまだアクティブではない場合、すなわち、ＰＵＳＣＨ／ＰＵＣＣＨ送信がリンクされた上りリンク・コンポーネント・キャリア（１つまたは複数）上でモバイル端末によって行われなかった場合に限って、リンクされた上りリンク・コンポーネント・キャリア上でＳＲＳを送信し、かつ／またはリンクされた上りリンク・コンポーネント・キャリア（１つまたは複数）のＰＨＲ情報を送信する。
【０２６４】
ユーザ機器の構成の例として図８に示されたシナリオを考慮しつつ、下りリンク・コンポーネント・キャリア・アクティブ化の場合のＳＲＳ／ＰＨＲの送信を、図１６に関して次で明らかにする。前提は、ＤＬ  ＣＣ１およびＵＬ  ＣＣ１だけが、現在アクティブ化されており、ｅノードＢが、時刻Ｔ１にＤＬ  ＣＣ２およびＤＬ  ＣＣ３をアクティブ化すると判断することである。ｅノードＢは、これらのＤＬ  ＣＣ２およびＤＬ  ＣＣ３をアクティブ化することを示す、提案される上りリンク・リソース割当をユーザ機器にシグナリングする。さらに、上りリンク・リソース割当は、新たにアクティブ化される下りリンク・コンポーネント・キャリア（１つまたは複数）にリンクされた上りリンク・コンポーネント・キャリア（１つまたは複数）すなわちこの例ではＵＬ  ＣＣ１およびＵＬ  ＣＣ２のＰＨＲ情報をも送信すること、および、リンクされた上りリンク・コンポーネント・キャリア（１つまたは複数）上でＳＲＳを送信することを、ユーザ機器に指令する。
【０２６５】
新しく提案される上りリンク・リソース割当の受信時の、本発明の一実施形態によるユーザ機器の挙動は、次の通りである。ユーザ機器は、ＤＬ  ＣＣ２およびＤＬ  ＣＣ３をアクティブ化する。さらに、ユーザ機器は、２つの新たにアクティブ化されたＤＬ  ＣＣ上でＣＱＩ情報を測定し、時刻Ｔ２に、上りリンク・リソース割当によって割り当てられたＵＬ  ＣＣ１上の上りリンク・リソース上でＤＬ  ＣＣ２およびＤＬ  ＣＣ３のＣＱＩ報告を送信する。さらに、ユーザ機器は、アクティブ化されたＤＬ  ＣＣ３がリンクされたＵＬ  ＣＣ２なので、ＵＬ  ＣＣ１上で割り当てられたリソース上でＵＬ  ＣＣ２のパワー・ヘッドルーム情報を送信する。さらに、ユーザ機器は、ＵＬ  ＣＣ２上でのＳＲＳの送信を開始する。これを、上りリンク・コンポーネント・キャリアの暗黙のアクティブ化／非アクティブ化と称することもできる。すなわち、下りリンク・コンポーネント・キャリアのアクティブ化／非アクティブ化によって、リンクされた上りリンク・コンポーネント・キャリアも、周期的ＳＲＳ送信および／またはＰＨＲ送信ならびにＰＵＳＣＨ送信について暗黙のうちにそれぞれアクティブ化されまたは非アクティブ化される。したがって、それぞれＤＬコンポーネント・キャリアまたは下りリンクＳＣｅｌｌのアクティブ化／非アクティブ化コマンドによって、周期的ＳＲＳ報告を、それぞれ対応するリンクされたＵＬコンポーネント・キャリアまたはＵＬ  ＳＣｅｌｌ上でイネーブル／ディスエーブルすることができる。用語「リンクされた」は、たとえば、下りリンクおよび上りリンクのセル／コンポーネント・キャリアの間のＳＩＢ２リンキングまたは下りリンクおよび上りリンクのコンポーネント・キャリア／セルの間のスケジューリング関係を指す。
【０２６６】
本発明のさらなる実施形態によれば、ＳＲＳ送信の構成パラメータは、上位レイヤのシグナリングすなわちＲＲＣシグナリングを介してユーザ機器にシグナリングされる。たとえば、キャリア・アグリゲーションのために下りリンクおよび上りリンクのコンポーネント・キャリア（１つまたは複数）の組を用いてユーザ機器を構成する時に、構成メッセージは、特定の上りリンク・コンポーネント・キャリアのＳＲＳ構成パラメータをも含み得る。これらの構成パラメータは、たとえば、サブフレーム構成すなわち、ＳＲＳが無線フレーム内で送信されるサブフレームの組、周期性、およびサウンディング帯域幅（ｓｏｕｎｄｉｎｇ  ｂａｎｄｗｉｄｔｈ）を含み得る。同様に、下りリンク・コンポーネント・キャリア上のチャネル品質測定に関連する構成すなわち送信モードおよび報告モードをも、コンポーネント・キャリア構成メッセージ内でシグナリングし得る。
【０２６７】
本発明のもう１つの実施形態は、３ＧＰＰベースの通信システム、たとえば３ＧＰＰ  ＬＴＥ−Ａ（リリース１０）での下りリンク・コンポーネント・キャリアの改善された非アクティブ化機構に関する。上で概要を示したように、ユーザ機器がコンポーネント・キャリアの非アクティブ化に応答してＣＱＩ情報を報告する時は、それは必ずしも必要／有益であるわけではない。たとえば、非アクティブ化の場合に、非アクティブ化されたばかりの下りリンク・コンポーネント・キャリアのＣＱＩ情報を送信するよい動機付けがあるとは思われない。したがって、上りリンク・リソース割当内の上りリンク・リソース割当関連フィールドすなわちＲＢＡフィールド、ＭＣＳフィールド、ＵＬホッピング・フラグ、およびＤＭＲＳフィールドは、他の目的に使用することができる。
【０２６８】
ユーザ機器がＰＤＣＣＨを監視する時には、モバイル端末がＰＤＣＣＨを誤って検出する確率（誤警報率（ｆａｌｓｅ  ａｌａｒｍ  ｒａｔｅ））がいつもあり、ＰＤＣＣＨのＣＲＣ検査は、ＰＤＣＣＨがこのユーザ機器宛ではない場合であっても正しくなり得る。すなわち、ＣＲＣは、ＲＮＴＩ不一致（意図されないユーザ）がある場合であっても合格する。このいわゆる誤警報は、無線チャネルによって引き起こされる送信誤りとＲＮＴＩ不一致との２つの影響がお互いに打ち消し合う場合に発生する可能性がある。偽陽性に復号されるＰＤＣＣＨの確率は、ＣＲＣ長に依存する。ＣＲＣ長が長いほど、ＣＲＣ保護されたメッセージが誤って正しく復号される確率が下がる。１６ビットのＣＲＣサイズを用いると、誤警報確率は、１．５・１０−５になる。
【０２６９】
ユーザ機器が、ある下りリンク・コンポーネント・キャリア（１つまたは複数）の非アクティブ化を示す上りリンク・リソース割当を有するＰＤＣＣＨを誤って検出する場合に、そのユーザ機器は、それらの示された下りリンク・コンポーネント・キャリア（１つまたは複数）のＰＤＣＣＨ／ＰＤＳＣＨの監視を止め、ＣＱＩ測定値の報告をも止める。したがって、そのようなユーザ機器挙動の深刻な結果を考慮すると、誤警報確率を下げることが望ましい。許容できるレベルまで誤警報率を下げる、この実施形態で提案される１つの手段は、１６ビットＣＲＣを拡張するために「仮想ＣＲＣ」を使用することである。すなわち、ＲＢＡフィールド、ＭＣＳフィールド、ＵＬホッピング・フラグ、およびＤＭＲＳフィールドなど、下りリンク・コンポーネント・キャリア非アクティブ化に有用ではないＰＤＣＣＨ上でシグナリングされる上りリンク・リソース割当のＤＣＩフィールドのうちの１つまたは複数に固定された既知の値をセットすることによって、ＣＲＣフィールドの長さを、仮想的に拡張することができる。ユーザ機器は、これらのフィールド内の値が正しくない（すなわち、既知の値に対応していない）場合には、下りリンク・キャリア非アクティブ化に関する上りリンク・リソース割当を含むＰＤＣＣＨを無視しなければならない。上りリンク・リソース割当関連のＤＣＩフィールドは、本質的に、下りリンク・コンポーネント・キャリア非アクティブ化の場合に必要ではないので、これらのフィールドを使用して、ＣＲＣを仮想的に拡張し、これによって誤警報確率を下げることができる。説明されたような誤警報率をさらに下げるためにＣＲＣ長を仮想的に拡張するための機構に類似する機構を、ＤＬコンポーネント・キャリア・アクティブ化のケースに適用することもできる。
【０２７０】
本発明のもう１つの態様は、下りリンク・コンポーネント・キャリア（１つまたは複数）の（非）アクティブ化のための上りリンク・リソース割当を送信するのに使用されるＨＡＲＱプロセスのＨＡＲＱプロトコル動作に関する。これが、下りリンク・コンポーネント・キャリア（非）アクティブ化を示す上りリンク・リソース割当によってスケジューリングされる上りリンク共有チャネル（ＵＬ−ＳＣＨ）上の送信（トランスポート・ブロック）がある場合、たとえば、ＰＨＲ情報が上りリンク共有チャネル上での送信のためにスケジューリングされる場合にのみあてはまることに留意されたい。これは、物理上りリンク共用チャネル（ＰＵＳＣＨ）上の非周期的ＣＱＩの送信と対照的であり、用いられるトランスポート・ブロック送信がない、すなわち、ＰＵＳＣＨ上の物理レイヤ送信のみであることに留意されたい。通常はＨＡＲＱプロセス管理に使用されるＮＤＩ（すなわち、トグルされたＮＤＩは、初期送信を示す）は、いくつかの実施態様で下りリンク・コンポーネント・キャリア（１つまたは複数）のアクティブ化状態の表示ために再利用できるので、いくつかの新しいユーザ機器挙動が、これらの実施態様のために定義される必要があるかもしれない。
【０２７１】
本発明の実施形態による１つの手法は、ユーザ機器が、ＮＤＩが以前の送信内の値と比較してトグルされたかどうかを判定する時に、下りリンク・コンポーネント・キャリア（１つまたは複数）の（非）アクティブ化を示す上りリンク・リソース割当を無視することである。
【０２７２】
その代わりに、本発明のもう１つの実施形態では、ユーザ機器は、下りリンク・コンポーネント・キャリア（１つまたは複数）の（非）アクティブ化を示すリソース割当の送信に使用されるＨＡＲＱプロセスのＮＤＩ値にある事前定義の値、たとえば０／１をセットする。ｅノードＢは、この挙動を知っているので、ＨＡＲＱ状況情報のＮＤＩ値に、下りリンク・コンポーネント・キャリア（１つまたは複数）の（非）アクティブ化を示すリソース割当を送信するのに使用されるＨＡＲＱプロセスの事前定義の値をセットすることもできる。これは、このＨＡＲＱプロセスのさらなる初期／再送信のための正しいＨＡＲＱプロセス管理を可能にする。
【０２７３】
上の議論について、下りリンクＳＣｅｌｌの（非）アクティブ化コマンドが、ＰＤＣＣＨを使用して物理レイヤ・シグナリングによって送信されると仮定した。しかし、その代わりにＭＡＣ制御シグナリングを使用して、（非）アクティブ化コマンドを送信することができる。
【０２７４】
下りリンクＳＣｅｌｌの（非）アクティブ化の種類が、スケジューリングされていない上りリンク・コンポーネント・キャリアのパワー・ヘッドルーム報告に関する本発明の実施形態に影響しないことにも留意されたい。言い替えると、仮想パワー・ヘッドルームの計算および報告は、通信システムがコンポーネント・キャリア・アグリゲーションを使用する限り、コンポーネント・キャリアのアクティブ化または非アクティブ化に使用されるシグナリングの種類とは独立である。
【０２７５】
特定の規制要件（ＳＥＭ、ＡＣＲＬなど）に基づいて、最大電力削減の値は、たとえば、割り当てられたリソース・ブロックの個数およびチャネル帯域幅に依存する。１つの電力増幅器を用いる連続キャリア・アグリゲーションについて、ＭＰＲ値は、異なるコンポーネント・キャリア上の割り当てられたリソース・ブロックの間の距離にも依存する。
【０２７６】
複数のコンポーネント・キャリアが上りリンク送信のためにスケジューリングされている時の特定のコンポーネント・キャリアのＭＰＲの判定は、ＬＴＥリリース１０での新しい問題である。リリース８／９では、１つのコンポーネント・キャリアだけがあり、したがって、ＭＰＲは、ユーザ機器ごとに計算される。基本的に、ＭＰＲに関して複数のコンポーネント・キャリアをどのように扱うべきかに関する２つのオプションがある。すなわち、特定のコンポーネント・キャリアについて他のコンポーネント・キャリアの影響を考慮するか、各コンポーネント・キャリアを独立に考慮するかのいずれかがある。
【０２７７】
手法１：  他のコンポーネント・キャリアを考慮する時には、ＭＰＲ（ＭＰＲＣＣ＃１＆ＣＣ＃２）が、各コンポーネント・キャリア固有最大送信電力（Ｐｃｍａｘ＿ｃ）に適用される。総最大送信電力は、ユーザ機器の電力クラスの最大電力と同一の最大送信電力である。図２５にこの手法を示し、図２５をより詳細に説明する。別々に計算される時の両方のキャリアの最大電力削減（図２６と比較して）を、ＭＰＲＣＣ＃１およびＭＰＲＣＣ＃２と表す。ＭＰＲは、他のコンポーネント・キャリア送信を考慮する時に、より大きく、ＭＰＲＣＣ＃１＆ＣＣ＃２と表される。ＭＰＲＣＣ＃１＆ＣＣ＃２は、異なるコンポーネント・キャリアの間で同一であり、ＭＰＲＣＣ＃１＆ＣＣ＃２の値は、Ｒｅｌ−８  ＭＰＲ要件と比較してはるかに大きい可能性がある。
【０２７８】
手法１に基づくＭＰＲを使用する時に、計算されるパワー・ヘッドルームは、実際の残り電力により近くなる可能性がある。しかし、１つの懸念は、このパワー・ヘッドルームが、上りリンク・スケジューリングの変化を正確に反映しない可能性があることである。たとえば、２つのアクティブ・キャリアを仮定すると、コンポーネント・キャリア１およびコンポーネント・キャリア２のパワー・ヘッドルームが報告される。少数のサブフレームの後に、第１のコンポーネント・キャリア１だけがスケジューリングされる。すなわち、コンポーネント・キャリア２上の上りリンク送信がない場合には、ｅＮＢは、新しいパワー・ヘッドルーム報告がトリガされるまで、コンポーネント・キャリア１の「古い」パワー・ヘッドルーム報告を使用する。しかし、前記ケースでは、コンポーネント・キャリア１のパワー・ヘッドルームは、実際にはもはや存在しない第２のコンポーネント・キャリア上の上りリンク送信を考慮する。したがって、ｅノードＢは、コンポーネント・キャリア１のユーザ機器の増加したパワー・ヘッドルームの潜在能力全体を利用しにくい。
【０２７９】
手法２：他のコンポーネント・キャリアを考慮しない時に、ＭＰＲは、コンポーネント・キャリアごとに別々に計算され（ＭＰＲ１、ＭＰＲ２）、コンポーネント・キャリア固有最大送信電力（Ｐｃｍａｘ＿ｃ）に適用される。複数のコンポーネント・キャリアに起因するＭＰＲが、その後、ユーザ機器の総最大送信電力に適用される。図２６にこの手法を示し、図２６をより詳細に説明する。
【０２８０】
ＭＰＲがコンポーネント・キャリアごとに別々に計算される場合には、ＬＴＥリリース８要件を再利用することができる。したがって、各コンポーネント・キャリアは、２ｄＢまでの最大値を有することができるそれ自体のＭＰＲ値を有する。図２６に示されているように、ＭＰＲＣＣ＃１は、コンポーネント・キャリア１の最大電力削減を指し、ＭＰＲＣＣ＃２は、コンポーネント・キャリア２の最大電力削減を指す。
【０２８１】
手法２すなわちＭＰＲがコンポーネント・キャリアごとに別々に計算される利益は、パワー・ヘッドルームが他のコンポーネント・キャリアの存在によって影響されないので、ｅノードＢが、各コンポーネント・キャリアのスケジューリングおよび電力調整潜在能力をよりよく理解できることである。たとえば、あるコンポーネント・キャリアの割り当てられたリソース・ブロックが、第２のコンポーネント・キャリアのリソース・ブロック割当よりはるかに少ない場合、第１のコンポーネント・キャリアは、送信電力増加のためにより大きい余地を得る。したがって、各コンポーネント・キャリアのＭＰＲが別々に計算される場合には、ｅノードＢは、コンポーネント・キャリアの間の差ポテンシャルを簡単に知る。
【０２８２】
本発明の次の実施形態は、ｅノードＢによる上りリンク・リソース割当を有しない上りリンク・コンポーネント・キャリアのパワー・ヘッドルーム報告に言及するものである。上で既に述べたように、前記スケジューリングされない上りリンク・コンポーネント・キャリアの基準サブフレーム内に上りリンク・リソース割当／許可を有することなく上りリンク・コンポーネント・キャリアのパワー・ヘッドルーム情報を送信することに関する提案を、下に示す。
【０２８３】
通常、そのようなケースでは、パワー・ヘッドルームは、前記コンポーネント・キャリアのために可能ではない。というのは、３ＧＰＰ  ＬＴＥ  ｒｅｌ．  ８／９によれば、パワー・ヘッドルーム報告は、ＵＥがＰＵＳＣＨ上の送信のための上りリンク・リソース割当を有するサブフレーム内でのみ送信できるからである。パワー・ヘッドルームは、ユーザ機器の最大送信電力とＰＵＳＣＨ上に割り当てられた上りリンク送信の推定電力との間の差を示す。明らかに、割り当てられたリソース・ブロックまたは使用すべき変調および符号化方式などのような、送信フォーマットはない。上りリンク送信がない場合には、パワー・ヘッドルームを計算し、報告することはできない。
【０２８４】
本発明の実施形態によれば、事前に構成された基準上りリンク・リソース割当が、スケジューリングされていない上りリンク・コンポーネント・キャリアのパワー・ヘッドルームを計算するためにユーザ機器によって使用される。したがって、パワー・ヘッドルームは、本質的に、スケジューリングされていない上りリンク・コンポーネント・キャリアの最大送信電力と、事前に構成された仮想上りリンク・リソース割当による上りリンク送信の推定電力との間の差を示している。
【０２８５】
ユーザ機器での事前に構成された基準上りリンク・リソース割当は、事前に定義され、パワー・ヘッドルーム報告のためにのみ使用される。すなわち、上りリンク・コンポーネント・キャリア上での実際のデータの送信には使用されない。したがって、以下では、これを、事前に構成された仮想上りリンク・リソース割当と呼ぶ場合もある。このパワー・ヘッドルームは、実際の上りリンク送信に関係しないので、以下では、これを仮想パワー・ヘッドルームと呼ぶ。
【０２８６】
ｅノードＢは、ユーザ機器が仮想パワー・ヘッドルーム計算の基礎を置く、事前に構成された仮想上りリンク・リソース割当に関する情報をも有する。事前に構成された仮想上りリンク・リソース割当は、ユーザ機器のスタートアップ時に、ユーザ機器とｅノードＢとの間で取り決めることができる。これは、たとえば無線リソース制御（ＲＲＣ）シグナリングによってユーザ機器にシグナリングされてもよい。その代わりに、これを仕様でユーザ機器内で固定に設定してもよく、その場合、ＲＲＣシグナリングを不要にすることができる。
【０２８７】
構成された上りリンク・コンポーネント・キャリアのパワー・ヘッドルームの計算および報告がトリガされた時に、ユーザ機器は、事前に構成された仮想上りリンク・リソース割当を使用することによって、スケジューリングされていない上りリンク・コンポーネント・キャリアの仮想パワー・ヘッドルームをも計算する。仮想パワー・ヘッドルームは、その後、スケジューリングされている上りリンク・コンポーネント・キャリアのパワー・ヘッドルーム情報と一緒にｅノードＢに送信される。仮想パワー・ヘッドルームが計算されるスケジューリングされていない上りリンク・コンポーネント・キャリアの他の基準サブフレームの欠けている上りリンク・リソース割当に鑑みて、仮想パワー・ヘッドルームは、異なる上りリンク・コンポーネント・キャリア上で送信される。仮想パワー・ヘッドルームは、ＭＡＣ制御要素としてトランスポートされ得る。
【０２８８】
スケジューリングされていない上りリンク・コンポーネント・キャリアの仮想パワー・ヘッドルームをｅノードＢに送信することによって、ｅノードＢは、ユーザ機器の電力状況に関するおよびスケジューリングされていない上りリンク・コンポーネント・キャリアの電力状況にも関する重要な情報を知ることができる。これは、ｅノードＢが、前記上りリンク・コンポーネント・キャリア上の将来の上りリンク送信をよりよくスケジューリングすることを可能にする。仮想パワー・ヘッドルーム情報がなければ、ｅノードＢは、前記上りリンク・コンポーネント・キャリアを介する上りリンク送信をスケジューリングすると判断した後に、上りリンク・コンポーネント・キャリアの電力状況を粗く推定する必要があり、あるいは、スケジューリングされていない上りリンク・コンポーネント・キャリア上の将来の上りリンク送信をブラインドでスケジューリングする必要がある。
【０２８９】
仮想パワー・ヘッドルームに基づいて、ｅノードＢは、スケジューリングされていない上りリンク・コンポーネント・キャリアの電力状況を知り、スケジューリング効率を高めるためにこの情報を使用することができる。
【０２９０】
より詳細な実施形態を以下で説明するが、以下では、基本的に、仮想パワー・ヘッドルームをどのように計算すべきかに関する２つの代替案がある。仮想パワー・ヘッドルームをどのように計算すべきかについてある手法では、ｅノードＢが受信した仮想パワー・ヘッドルームから正確に何を知ることができるのかを判断する。
【０２９１】
第１の代替案によれば、コンポーネント・キャリア固有最大送信電力Ｐｃｍａｘ，ｃには、スケジューリングされていない上りリンク・コンポーネント・キャリアの仮想パワー・ヘッドルームを計算するために、ある事前定義の固定値がセットされる。ｅノードＢは、ユーザ機器によって使用される事前に構成された最大送信電力Ｐｃｍａｘ，ｃを知っていなければならない。Ｐｃｍａｘ，ｃには任意の値をセットすることができるが、好ましくは、２つの限界Ｐｃｍａｘ＿ＬとＰｃｍａｘ＿Ｈとの間でセットされる。
【０２９２】
基準ＰＵＳＣＨフォーマットすなわち事前に構成された仮想上りリンク・リソース割当を、次の例に従ってセットすることができる。リソース・ブロックの個数には１がセットされ、これは、１０ｌｏｇ１０（ＭＰＵＳＣＨ（ｉ））が０ｄＢであることを意味する。さらに、ΔＴＦには０ｄＢがセットされる。
【０２９３】
上の例示的な事前に構成された上りリンク・リソース割当の場合に、パワー・ヘッドルームを計算する公式は、
ＰＨ（ｉ）＝ＰＣＭＡＸ−｛１０・ｌｏｇ１０（ＭＰＵＳＣＨ（ｉ））＋ＰＯ＿ＰＵＳＣＨ（ｊ）＋α（ｊ）・ＰＬ＋ΔＴＦ（ｉ）＋ｆ（ｉ）｝
であるが、これを
ｖＰＨ（ｉ）＝ＰＣＭＡＸ＿ｐｒｅｃｏｎｆ−｛ＰＯ＿ＰＵＳＣＨ（ｊ）＋α（ｊ）・ＰＬ＋ｆ（ｉ）｝
に換算することができる。
【０２９４】
仮想パワー・ヘッドルーム（ｖＰＨ）を計算するための残りのパラメータは、ユーザ機器に既知である。経路損（ＰＬ）、受信されたＴＰＣコマンド（ｆ（ｉ））、およびＰＯ＿ＰＵＳＣＨ（ｉ）またはαなどの他のコンポーネント・キャリア固有定数の値は、上りリンク・データ送信を有しない場合であっても、スケジューリングされていない上りリンク・コンポーネント・キャリアについて利用可能である。
【０２９５】
Ｐｃｍａｘ＿ｐｒｅｃｏｎｆのために事前に構成された固定値を使用して、ユーザ機器は、上の公式に従って、スケジューリングされていない上りリンク・コンポーネント・キャリアの仮想パワー・ヘッドルームを計算することが可能となる。計算された仮想パワー・ヘッドルームは、たとえばスケジューリングされた上りリンク・コンポーネント・キャリアを介してＭＡＣ制御要素内で、ｅＮｏｄｅに送信される。
【０２９６】
それぞれ上述した基準ＰＵＳＣＨフォーマットまたは対応する電力制御パラメータは、非ＭＩＭＯケースについてのみ考慮された。上りリンク単一ユーザＭＩＭＯの場合、たとえば、それぞれ基準ＰＵＳＣＨフォーマットまたは対応する電力制御パラメータを、いくつかのＭＩＭＯ固有パラメータによって拡張することができる。これらのパラメータを、非ＭＩＭＯケースと同一の形で事前に構成することができる。
【０２９７】
Ｐｃｍａｘ＿ｐｒｅｃｏｎｆｉｇのｅノードＢの知識に基づいて、ＰＬ、すなわちこのスケジューリングされていない上りリンク・コンポーネント・キャリアについてユーザ機器によって測定された経路損、に関するある情報を取り出すことが可能である。したがって、仮想パワー・ヘッドルームは、より効率的な無線リソース管理のためにｅノードＢによって使用し得る、対応する上りリンク・コンポーネント・キャリアの経路損状況に関するある情報を明らかにする。たとえば、ｅノードＢは、アグリゲートされたコンポーネント・キャリアの間の大きい経路損差を検出することができる。大きい経路損差は、回避されなければならず、ｅノードＢは、ユーザ機器の観点から類似する経路損特を有するコンポーネント・キャリアをアグリゲートしなければならない。
【０２９８】
経路損状況が、通常はユーザ機器の速度に依存して非常にゆっくり変化し、したがって、仮想パワー・ヘッドルームに基づいて計算される経路損値が、かなり長い間有効なままになり得、ｅノードＢが、将来の上りリンク送信スケジューリングについて基本的に同一の経路損状況を仮定できることに留意されたい。
【０２９９】
ｅノードＢは、対応する上りリンク・コンポーネント・キャリアのリソース・ブロックあたりの電力（ＰＯ＿ＰＵＳＣＨ（ｊ）＋α（ｊ）・ＰＬ＋ｆ（ｉ））を計算することもでき、したがって、ｅノードＢが、現在はスケジューリングされていないその上りリンク・コンポーネント・キャリア上の将来の上りリンク送信を効率的にスケジューリングすることが可能になる。たとえば、ｅノードＢは、このコンポーネント・キャリア上の上りリンク送信をスケジューリングすべきか否かを判断するために、この情報を使用することができる。電力スペクトル密度が大きすぎる値を有する場合には、ユーザ機器が電力制限される危険性があるので、ｅノードＢは、このコンポーネント・キャリアのスケジューリングを控える。同一の形で、ｅノードＢは、アグリゲートされたコンポーネント・キャリアの間の大きいＰＳＤ差を検出することができる。コンポーネント・キャリアの間のＰＳＤ差が大きい場合には、ユーザ機器によって複数のコンポーネント・キャリア上で同時に送信することが不可能であるか、それが電力増幅器のダイナミック・レンジに影響するのでユーザ機器の複雑さを大幅に増やすかのいずれかである。
【０３００】
既に述べたように、第１の代替案について、スケジューリングされていない上りリンク・コンポーネント・キャリアのユーザ機器の構成された最大送信電力には、固定された事前に構成された値をセットすることができる。たとえば、これにＰｃｍａｘ＿Ｈをセットすることができ、このＰｃｍａｘ＿ＨはＰＣＭＡＸ＿Ｈ＝ｍｉｎ（ＰＥＭＡＸ，ＰＰｏｗｅｒＣｌａｓｓ）である。ＰＥＭＡＸは、ネットワークによってシグナリングされる値であり、ＰＰｏｗｅｒＣｌａｓｓも、ネットワークによって知られているので、ｅノードＢは、Ｐｃｍａｘ＿Ｈを知っている。ＰｃｍａｘにＰｃｍａｘ＿Ｈをセットすることは、対応するスケジューリングされていない上りリンク・コンポーネント・キャリアについて考慮されるＭＰＲ／Ａ−ＭＰＲに起因する電力削減がないことを意味し、これは、例示的な基準ＰＵＳＣＨフォーマットに従って複数のリソース・ブロックに関する電力に０がセットされるので、穏当と思われる。
【０３０１】
代替案では、ＰｃｍａｘにＰｃｍａｘ＿Ｌをセットすることができ、このＰｃｍａｘ＿Ｌは、
ＰＣＭＡＸ＿Ｌ＝ｍｉｎ（ＰＥＭＡＸ−ΔＴＣ，ＰＰｏｗｅｒＣｌａｓｓ−ＭＰＲ−ＡＭＰＲ−ΔＴＣ）
である。
【０３０２】
ユーザ機器の最大電力削減は、ｅＮｏｄｅによって知られてはいないが、電力クラス３のユーザ機器について背景技術セクションの表１に従い、送信フォーマットに基づいてユーザ機器によって選択される。たとえば、ｅノードＢは、ユーザ機器が最大値で適用できる最大電力削減が１ｄＢ未満でなければならないことだけを判定することができる。したがって、ｅノードＢは、特定のユーザ機器の最大電力削減がどの値であるのかを知らない。ユーザ機器によって使用される実際の電力削減は、ユーザ機器によって構成された最大電力削減より小さい可能性がある。
【０３０３】
しかし、ｅノードＢは、通常、ユーザ機器が特定の上りリンク送信について適用できる最大電力削減を知らない。ｅノードＢがｅノードＢの最大電力削減についてそれでも知るために、仮想パワー・ヘッドルームを計算し、事前に構成されたＰｃｍａｘ＿ｐｒｅｃｏｎｆｉｇとしてＰｃｍａｘ＿Ｌを使用する時に、ユーザ機器が、仕様（たとえば、背景技術セクションの表１）で定義される最大の可能なすなわち最も控えめなＭＰＲ値を使用すると定義することができる。Ｐｃｍａｘ＿Ｌをどのようにして計算するのかを取り決めることによって、ｅノードＢが、仮想パワー・ヘッドルームの計算でユーザ機器によって使用されるＰｃｍａｘ＿ｐｒｅｃｏｎｆｉｇを知ることが可能になり、したがって、ｅノードＢは、上で説明したように経路損／リソース・ブロックあたりの電力を推論することができる。
【０３０４】
一般に、この第１の代替実施形態による仮想パワー・ヘッドルーム定義は、特に有益であるが、ＭＰＲが上りリンク・コンポーネント・キャリアごとに別々に計算されるＭＲＰ計算（図２６に関連する上述の手法２を参照されたい）に限定されない。より具体的には、ｅＮＢは、スケジューリングされた上りリンク・コンポーネント・キャリアの受信された対応するパワー・ヘッドルーム報告に基づいて、前記スケジューリングされた上りリンク・コンポーネント・キャリアのリソース・ブロックあたりの電力を粗く推定することができる。ｅノードＢは、使用されるコンポーネント・キャリア固有最大送信電力Ｐｃｍａｘ＿ｃを正確には知らないが、使用される電力削減は、電力クラス３のユーザ機器について表１に例示されているように仕様からの変調オーダー、リソース割当などに関するＭＰＲ要件から、ｅノードＢによって粗く推定され得る。有利なことに、ｅノードＢは、たとえば、スケジューリングされた上りリンク・コンポーネント・キャリアのＰｃｍａｘ＿ｃを判定するために、最も控えめな（最大の）ＭＰＲ値を常に仮定することができる。したがって、受信した仮想パワー・ヘッドルーム報告および通常のパワー・ヘッドルーム報告に基づいて、ｅノードＢは、将来の送信についてユーザ機器の総電力状況を推定することができる。
【０３０５】
上の解決策とは異なるさらなる代替解決策によれば、仮想ＰＵＳＣＨ電力には、０ｄＢがセットされ、Ｐｃｍａｘは、任意の他のコンポーネント・キャリアについて通常通りにユーザ機器によって計算される。
【０３０６】
これによれば、仮想パワー・ヘッドルームは、次の公式を用いて計算される。
ｖＰＨ（ｉ）＝ＰＣＭＡＸ−｛０｝
上りリンク送信に関するすべてのパラメータには、０ｄＢがセットされる。これは、このスケジューリングされていない上りリンク・コンポーネント・キャリアの仮想パワー・ヘッドルームに影響する送信、経路損、または電力コマンドがないと仮定されることを意味する。仮想パワー・ヘッドルームは、本質的に、ユーザ機器のスケジューリングされていない上りリンク・コンポーネント・キャリアのコンポーネント・キャリア固有最大送信電力を報告する。
【０３０７】
既に述べたように、Ｐｃｍａｘは、通常の手順すなわち、スケジューリングされた上りリンク・コンポーネント・キャリアと同一の手順に従って、ユーザ機器によって計算される。したがって、ユーザ機器の電力削減は、上りリンク許可を有する他のコンポーネント・キャリアの通常のパワー・ヘッドルーム報告と同一の形で、仮想パワー・ヘッドルームのために考慮される。
【０３０８】
第２の代替案は、ＭＰＲ計算が他の上りリンク・コンポーネント・キャリア上の上りリンク送信を考慮する時（手法１、図２５を参照されたい）に特に有利であるが、明白になるように、これに限定されない。前記ケースでは、第２の代替案は、ｅノードＢが、仮想パワー・ヘッドルームが実際に送信されるスケジューリングされていない上りリンク・コンポーネント・キャリアの電力削減を知ることを可能にするだけではなく、ｅノードＢは、これにより、残りのスケジューリングされた上りリンク・コンポーネント・キャリアの電力削減をも知ることができる。手法１によれば、電力削減（ＭＰＲＣＣ＃１＆ＣＣ＃２）は、すべてのコンポーネント・キャリアについて同一である。したがって、ｅノードＢがスケジューリングされていない上りリンク・コンポーネント・キャリアについて受信された仮想パワー・ヘッドルームから判定する電力削減も、ユーザ機器が他のスケジューリングされた上りリンク・コンポーネント・キャリア上の上りリンク送信に適用するものと同一の電力削減である。
【０３０９】
報告された仮想パワー・ヘッドルームおよびそのように獲得された電力削減値に基づいて、ｅノードＢは、他のスケジューリングされた上りリンク・コンポーネント・キャリアの、それぞれ絶対送信電力またはリソース・ブロックあたりの電力を計算することができる。したがって、ｅノードＢは、ＵＥの総送信電力状況を正確に計算でき、これは、将来の上りリンク送信の正確なスケジューリングを可能にする。
【０３１０】
この特定の利益は、ＭＰＲ計算の手法２について可能ではない。というのは、ＭＰＲが、コンポーネント・キャリアごとに別々に計算され、したがって、コンポーネント・キャリアごとに異なるＭＰＲ値をも有するからである。
【０３１１】
本発明のもう１つの実施形態によれば、上で提示されたスケジューリングされていない上りリンク・コンポーネント・キャリアのパワー・ヘッドルームを報告する２つの代替案を組み合わせることができる。より詳細には、ユーザ機器は、両方の代替実施形態に従って仮想パワー・ヘッドルームを計算でき、シナリオに応じて１つの代替案を選択する。たとえば、通信システム内で、ＭＰＲ値が、通常は他の上りリンク・コンポーネント・キャリア上の上りリンク送信を考慮して計算される（手法１、図２５を参照されたい）時には、ユーザ機器は、好ましくは、第２の代替案を使用し得、ここで、ＰＵＳＣＨ上りリンク送信電力には、０がセットされ、Ｐｃｍａｘ＿ｃは、ユーザ機器によって適用される電力削減を考慮して計算される。ｅノードＢは、ユーザ機器から受信された仮想パワー・ヘッドルーム値を正しく解釈するために、ユーザ機器によって仮想パワー・ヘッドルームの計算にどの代替案が選択されるかを知る。
【０３１２】
逆に、ユーザ機器は、通信システム内でＭＰＲがコンポーネント・キャリアごとに別々に計算される時には、事前に構成されたＰｃｍａｘ＿ｃ（たとえば、Ｐｃｍａｘ＿Ｈ）および事前に構成された上りリンク・リソース割当を使用して仮想パワー・ヘッドルームを計算することができる。代替案では、ユーザ機器は、仮想パワー・ヘッドルーム計算の一方または他方の方法を使用するように、ｅノードＢによって構成されることができる。この構成は、たとえば、ＲＲＣなどの上位レイヤ・シグナリングによってシグナリングされ得る。
【０３１３】
次に、仮想パワー・ヘッドルームをどのように計算するのかに関する上の２つの代替解決策に関する他の態様を、以下で議論する。
【０３１４】
多くのシナリオについて、ｅノードＢが、通常のＰＨＲと本発明の実施形態による仮想ＰＨＲとを区別できることが有利である。たとえば、ＰＤＣＣＨ（上りリンク・リソース割当）が失われる場合、対応する上りリンク・コンポーネント・キャリアは、ユーザ機器の観点からはスケジューリングされないままになるが、ｅノードＢの観点からはスケジューリングされる。したがって、トリガされた時に、ユーザ機器は、上で論じた２つの代替案のうちの１つに従って、対応するスケジューリングされていない上りリンク・コンポーネント・キャリアの仮想パワー・ヘッドルームを計算するが、ｅノードＢは、ユーザ機器に以前に送信した上りリンク・リソース割当に従って、標準仕様によって定義される通りに計算されたパワー・ヘッドルームを期待する。前記ケースでは、ｅノードＢは、受信したパワー・ヘッドルーム値を誤って解釈し、これによりユーザ機器の電力状況の判定に悪影響を及ぼし、それゆえ、非効率的なスケジューリングにつながる。
【０３１５】
これおよび類似する状況を回避するために、仮想パワー・ヘッドルーム報告を通常のパワー・ヘッドルーム報告から区別するために、仮想パワー・ヘッドルーム報告をしかるべくマークすることができる。１ビット・フラグを、前記の点で使用することができる。たとえば、図２７に示されているように、パワー・ヘッドルームＭＡＣ制御要素に対応するＭＡＣ  ＰＤＵサブヘッダ内の２つの予約済みビットのうちの１つを使用することができる。図からわかるように、ＬＣＩＤ＝１１０１０は、パワー・ヘッドルームであることを特定し、「ＰＨＲタイプ」フラグは、パワー・ヘッドルームが「仮想」パワー・ヘッドルームを表しているか否かを示す。すなわち、スケジューリングされていない上りリンク・コンポーネント・キャリアに関するか否かを示す。
【０３１６】
代替案では、パワー・ヘッドルームに関するＭＡＣ制御要素（図２２を参照されたい）内の予約済みビットのうちの１つを使用して、パワー・ヘッドルームのタイプを識別することができる。
【０３１７】
既に説明したように、パワー・ヘッドルームが報告できる範囲は、Ｒｅｌ．  ８／９仕様に従って６ビットに制限され、具体的には＋４０ｄＢから−２３ｄＢまでの値に制限される。仮想パワー・ヘッドルームは送信が実際には実施されない上りリンク・コンポーネント・キャリア上で報告するので、仮想パワー・ヘッドルームは定義された範囲を超えることがあり得る。たとえば、第１の代替案に従って計算される仮想パワー・ヘッドルームは、少ない経路損を有するユーザ機器について、頻繁に上限すなわち４０ｄＢを超える可能性がある。したがって、パワー・ヘッドルームに対して上で示した範囲（４０〜−２３ｄＢ）を使用すると、仮想パワー・ヘッドルームが正しく示されない場合がある。
【０３１８】
この問題を解決するために、仮想パワー・ヘッドルームが絶対に負になり得ないので、負の値を再定義することによって正の範囲を拡大することができる。前記ケースでは、仮想パワー・ヘッドルームの範囲を、６４ｄＢから０ｄＢまでになるように定義することができる。
【０３１９】
代替案では、範囲外の仮想パワー・ヘッドルーム値が可能範囲内にオフセットされるように、仮想パワー・ヘッドルームを計算する時に、あるオフセット値を考慮することができる。詳細には、５０ｄＢと計算された仮想パワー・ヘッドルーム値は、４０ｄＢから−２３ｄＢまでというＲｅｌ．  ８／９の範囲外の値になる。仮想パワー・ヘッドルームの計算にオフセット値を使用することによって、たとえば２０ｄＢのオフセットを使用することによって、報告される仮想パワー・ヘッドルーム値を、６ビット範囲によって表すことができる。オフセット値は、仮想パワー・ヘッドルームの計算に使用されるＰＵＳＣＨ電力に既に加算されているものとすることができる。どの場合でも、使用されるオフセット値およびそれをどのように適用するのかが、ｅノードＢによって知られなければならず、これにより、ｅノードＢは、受信した仮想パワー・ヘッドルーム値から実際の仮想パワー・ヘッドルーム値を正しく計算することができる。
【０３２０】
仮想パワー・ヘッドルーム計算の第２の代替案すなわち、仮想パワー・ヘッドルームがコンポーネント・キャリアの最大送信電力を報告する場合にも、範囲をＲｅｌ．  ８／９仕様と比較して再定義する必要がある。ｖＰＨはｖＰＨ（ｉ）＝ＰＣＭＡＸ−｛０｝なので、ｖＰＨは、通常のパワー・ヘッドルーム報告に関してｄＢｍ単位であってｄＢ単位ではなく、値を変更しなければならない。また、範囲が異なる、すなわち、範囲は、たとえば使用可能な６ビットに関するより微細な粒度を有する２３ｄＢｍから２０ｄＢｍまででなければならない。
【０３２１】
本発明のもう１つの実施形態は、ハードウェアおよびソフトウェアを使用する、上で説明されたさまざまな実施形態の実施に関する。本発明のさまざまな実施形態を、コンピューティング・デバイス（プロセッサ）を使用して実施しまたは実行できる。コンピューティング・デバイスまたはプロセッサは、たとえば、汎用プロセッサ、ディジタル信号プロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）、または他のプログラマブル論理デバイスなどとすることができる。本発明のさまざまな実施形態を、これらのデバイスの組合せによって実行しまたは実施することもできる。
【０３２２】
さらに、本発明のさまざまな実施形態を、プロセッサによってまたは直接にハードウェアで実行される、ソフトウェア・モジュールによって実施することもできる。また、ソフトウェア・モジュールとハードウェア実装との組合せが可能である。ソフトウェア・モジュールを、任意の種類のコンピュータ可読記憶媒体、たとえばＲＡＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、フラッシュ・メモリ、レジスタ、ハード・ディスク、ＣＤ−ＲＯＭ、ＤＶＤ、その他に格納することができる。
【０３２３】
さらに、本発明の異なる実施形態の個々の特徴を、個別にまたは任意の組合せで別の発明の主題にすることができることに留意されたい。
【０３２４】
当業者は、幅広く説明された本発明の趣旨または範囲から逸脱しない限り、特定の実施形態に示された本発明に対して多数の変更および／または修正を行うことができることを了解するであろう。したがって、本実施形態は、すべてにおいて例示的であり、制限的ではないと考えられなければならない。
【図１】
2020043580.tif 000011
【図２】
2020043580.tif 000012
【図３】
2020043580.tif 000013
【図４】
2020043580.tif 000014
【図５】
2020043580.tif 000015
【図６】
2020043580.tif 000016
【図７】
2020043580.tif 000017
【図８】
2020043580.tif 000018
【図９】
2020043580.tif 000019
【図１０】
2020043580.tif 000020
【図１１】
2020043580.tif 000021
【図１２】
2020043580.tif 000022
【図１３】
2020043580.tif 000023
【図１４】
2020043580.tif 000024
【図１５】
2020043580.tif 000025
【図１６】
2020043580.tif 000026
【図１７】
2020043580.tif 000027
【図１８】
2020043580.tif 000028
【図１９】
2020043580.tif 000029
【図２０】
2020043580.tif 000030
【図２１】
2020043580.tif 000031
【図２２】
2020043580.tif 000032
【図２３】
2020043580.tif 000033
【図２４】
2020043580.tif 000034
【図２５】
2020043580.tif 000035
【図２６】
2020043580.tif 000036
【図２７】
2020043580.tif 000037