特許 5945587 半永続スケジューリングのための効果的な拡張されたパワーヘッドルーム報告

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】5945587

(24)【登録日】2016年6月3日

(45)【発行日】2016年7月5日

(54)【発明の名称】半永続スケジューリングのための効果的な拡張されたパワーヘッドルーム報告

(51)【国際特許分類】

   H04W 52/34 20090101AFI20160621BHJP

   H04W 24/10 20090101ALI20160621BHJP

   H04W 72/04 20090101ALI20160621BHJP

【ＦＩ】

   H04W52/34

   H04W24/10

   H04W72/04 132

【請求項の数】12

【全頁数】44

(21)【出願番号】特願2014-501465(P2014-501465)

(86)(22)【出願日】2012年3月2日

(65)【公表番号】特表2014-509811(P2014-509811A)

(43)【公表日】2014年4月21日

(86)【国際出願番号】EP2012000942

(87)【国際公開番号】WO2012130373

(87)【国際公開日】20121004

【審査請求日】2014年12月18日

(31)【優先権主張番号】11160833.7

(32)【優先日】2011年4月1日

(33)【優先権主張国】EP

(73)【特許権者】

【識別番号】514136668

【氏名又は名称】パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ

【氏名又は名称原語表記】Ｐａｎａｓｏｎｉｃ Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ Ｃｏｒｐｏｒａｔｉｏｎ ｏｆ Ａｍｅｒｉｃａ

(74)【代理人】

【識別番号】100105050

【弁理士】

【氏名又は名称】鷲田 公一

(72)【発明者】

【氏名】ロアー ヨアヒム

(72)【発明者】

【氏名】ヴェンゲルター クリスティアン

(72)【発明者】

【氏名】フォイヤーサンゲル マルティン

(72)【発明者】

【氏名】田村 尚志

【審査官】 齋藤 浩兵

(56)【参考文献】

【文献】 国際公開第２００９／１５４４０３（ＷＯ，Ａ２）

【文献】 特開２０１０−２２６７２０（ＪＰ，Ａ）

【文献】 特表２０１０−５４１４７４（ＪＰ，Ａ）

【文献】 Alcatel-Lucent, Alcatel-Lucent Shanghai Bell，"PCMAX,c signalling optimisation"[online]，3GPP TSG-RAN WG2#72bis R2-110139，２０１１年 １月２１日，URL:http://www.3gpp.org/ftp/tsg_ran/WG2_RL2/TSGR2_72bis/Docs/R2-110139.zip

【文献】 3GPP TS 36.321 V10.0.0，２０１０年１２月，pp.21,22,27,28,38-40，ＵＲＬ，http://www.3gpp.org/ftp/Specs/archive/36_series/36.321/36321-a00.zip

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｈ０４Ｂ ７／２４− ７／２６

Ｈ０４Ｗ ４／００−９９／００

３ＧＰＰ ＴＳＧ ＲＡＮ ＷＧ１−４

ＳＡ ＷＧ１−２

ＣＴ ＷＧ１

(57)【特許請求の範囲】

【請求項1】

上りリンクリソースの中で基地局にパワーヘッドルーム情報を送信するためのユーザ機器であって、
前記パワーヘッドルーム情報は、１つのコンポーネントキャリアに対して、可能な送信電力の情報を提供する基本のパワーヘッドルーム報告か、各アクティブ化された上りリンクのコンポーネントキャリアに対して、可能な送信電力および対応する最大送信電力の情報を提供する拡張されたパワーヘッドルーム報告のいずれかであり、
前記ユーザ機器は、前記拡張されたパワーヘッドルーム報告とともにパワーヘッドルーム情報を報告するために構成され、
前記ユーザ機器は、
前記上りリンクリソースが永続スケジューリング構成を介してスケジューリングされるケースでは、前記上りリンクリソースの中で、パワーヘッドルーム情報として前記基本のパワーヘッドルーム報告を前記基地局に送信する送信機を具備し、
前記送信機は、前記上りリンクリソースが動的スケジューリングを介してスケジューリングされるケースでは、前記上りリンクリソースの中で、パワーヘッドルーム情報として前記拡張されたパワーヘッドルーム報告を前記基地局に送信する、
ユーザ機器。

【請求項2】

前記パワーヘッドルーム情報を送信するための前記上りリンクリソースが、永続スケジューリング構成を介してスケジューリングされるか、あるいは、動的スケジューリングを介してスケジューリングされるかどうかを判断するプロセッサ、
を更に具備する請求項１に記載のユーザ機器。

【請求項3】

前記基本のパワーヘッドルーム報告は、１つのコンポーネントキャリアに対して、パワーヘッドルームレベルの情報を具備し、前記拡張されたパワーヘッドルーム報告は、各アクティブ化された上りリンクのコンポーネントキャリアに対して、パワーヘッドルームレベルの情報を具備し、各アクティブ化された上りリンクのコンポーネントキャリアに対して、コンポーネントキャリア特有の最大送信電力の情報を具備し、上りリンクェアードチャネル送信および上りリンク制御チャネル送信が同時に実行されれば、上りリンクシェアードチャネル送信および上りリンク制御チャネル送信のパワーヘッドルームレベルを具備する、
請求項１または請求項２に記載のユーザ機器。

【請求項4】

前記プロセッサは、前記基本のパワーヘッドルーム報告が前記上りリンクリソースの中で送信されるケースでは、前記拡張されたパワーヘッドルーム報告の送信を前記ユーザ機器の中でトリガし、
前記送信機は、前記トリガされた拡張されたパワーヘッドルーム報告を、その次の可能な上りリンクリソースの中で前記ユーザ機器から前記基地局に送信する、
前記次の可能な上りリンクリソースは、動的スケジューリングを介してスケジューリングされる、
請求項２に記載のユーザ機器。

【請求項5】

禁止タイマは、最初のパワーヘッドルーム情報を送信した後に特定の時間に対して第２のパワーヘッドルーム情報の送信を禁止するために使用され、前記禁止タイマは、前記トリガされた拡張されたパワーヘッドルーム報告に対して無視され、前記禁止タイマは、前記トリガされた拡張されたパワーヘッドルーム報告を送信した後に再スタートしない、
請求項４に記載のユーザ機器。

【請求項6】

上りリンクリソースの中で、ユーザ機器から基地局へのパワーヘッドルーム情報を送信するための方法であって、
前記パワーヘッドルーム情報は、１つのコンポーネントキャリアに対して、可能な送信電力の情報を提供する基本のパワーヘッドルーム報告か各アクティブ化された上りリンクのコンポーネントキャリアに対して、可能な送信電力および対応する最大送信電力の情報を提供する拡張されたパワーヘッドルーム報告のいずれかであり、
前記ユーザ機器は、前記拡張されたパワーヘッドルーム報告とともに前記パワーヘッドルーム情報を報告するために構成され、
前記方法は以下のステップを有する、
前記上りリンクリソースが永続スケジューリング構成を介してスケジューリングされるケースでは、基本のパワーヘッドルーム報告が、前記上りリンクリソースの中で、パワーヘッドルーム情報として前記基地局に送信され、
前記上りリンクリソースが動的スケジューリングを介してスケジューリングされるケースでは、拡張されたパワーヘッドルーム報告が、前記上りリンクリソースの中で、パワーヘッドルーム情報として前記基地局に送信される、
方法。

【請求項7】

前記パワーヘッドルーム情報を送信するための前記上りリンクリソースが、永続スケジューリング構成を介してスケジューリングされるか、あるいは、動的スケジューリングを介してスケジューリングされるかどうかを判断する、
請求項６に記載の方法。

【請求項8】

前記基本のパワーヘッドルーム報告は、１つのコンポーネントキャリアに対して、パワーヘッドルームレベルの情報を具備し、
前記拡張されたパワーヘッドルーム報告は、各アクティブ化された上りリンクのコンポーネントキャリアに対して、パワーヘッドルームレベルの情報を具備し、各アクティブ化された上りリンクのコンポーネントキャリアに対して、コンポーネントキャリア特有の最大送信電力の情報を具備し、上りリンクシェアードチャネル送信および上りリンク制御チャネル送信が同時に実行されれば、上りリンクシェアードチャネル送信および上りリンク制御チャネル送信のパワーヘッドルームレベルを具備する、
請求項６または請求項７に記載の方法。

【請求項9】

前記基本のパワーヘッドルーム報告が前記上りリンクリソースの中で送信されるケースでは、前記ユーザ機器の中で前記拡張されたパワーヘッドルーム報告の送信がトリガされ、
前記トリガされた拡張されたパワーヘッドルーム報告は、その次の可能な上りリンクリソースの中で前記ユーザ機器から前記基地局に送信される、
請求項６から請求項８のいずれかに記載の方法。

【請求項10】

前記基本のパワーヘッドルーム報告が前記上りリンクリソースの中で送信されるケースでは、前記ユーザ機器の中で前記拡張されたパワーヘッドルーム報告の送信がトリガされ、
前記トリガされた拡張されたパワーヘッドルーム報告は、動的スケジューリングを介してスケジューリングされたその次の可能な上りリンクリソースの中で前記ユーザ機器から前記基地局に送信される、
請求項６から請求項８のいずれかに記載の方法。

【請求項11】

禁止タイマは、最初のパワーヘッドルーム情報を送信した後に特定の時間に対して第２のパワーヘッドルーム情報の送信を禁止するために使用され、
前記禁止タイマは、前記トリガされた拡張されたパワーヘッドルーム報告に対して無視される、
請求項９または請求項１０に記載の方法。

【請求項12】

前記禁止タイマは、前記トリガされた拡張されたパワーヘッドルーム報告を送信した後に再スタートしない、
請求項１１に記載の方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、ユーザ機器から基地局へパワーヘッドルーム情報を送信するための方法、および、前記方法を実行するためのユーザ機器に関する。

【背景技術】

【0002】

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

【0003】

しかし、もう少し長い時間で見ると、ユーザの要求はさらに増加することに備えること、および、新たな無線アクセス技術に対して競争力を有することが必要である。この挑戦を満たすために、３ＧＰＰは、研究項目、進化されたＵＴＲＡおよびＵＴＲＡＮを始めた。研究で目指すところは、サービス配給およびコスト削減の項目の中に更なる実体的な飛躍を成し遂げることを意味するものである。この言葉の根拠として、３ＧＰＰは、ロングタームエボリューション（ＬＴＥ）と称される新しい移動通信システムのために、ターゲットと要求のセットを締結した。ＬＴＥは、今後１０年間にわたり、データおよびメディアの高速伝送ならびに大容量の音声サポートに要求されるキャリアを提供するように設計されている。
− 下りリンク方向で１００Ｍｂｐｓおよび上りリンク方向で５０Ｍｂｐｓを超えるピークレート
− 上りリンクおよび下りリンクに対してファクタ２および３によって改善された平均ユーザスループット
− 上りリンクおよび下りリンクに対してファクタ２によって改善されたセルエッジユーザスループット
− ファクタ２および３によってそれぞれ改善された上りリンクおよび下りリンクのスペクトル効率
− 著しく低減された制御プレーンレイテンシィ
− オペレータとエンドユーザのために低減されたコスト
− 多くの異なるスペクトラムの中で展開可能なスペクトル自由度

【0004】

高いビットレートを供給する能力が、ＬＴＥの重要な物差しである。多入力多出力（ＭＩＭＯ）技術を使用して、単一の端末に複数の並列データストリームを送信することは、これを実現するために重要なコンポーネントの１つである。より大きい送信帯域および同時に自由なスペクトラムの割り当ては、使用する無線アクセス技術を決定するときに考慮される他のピースである。下りリンクの中で、適応的マルチレイヤＯＦＤＭ、ＡＬＭ−ＯＦＤＭを選択することは、一般的な異なる帯域幅で作業することのみならず、特殊な高いデータレートの大きな帯域幅で作業することも容易にする。下りリンクには、ＯＦＤＭ（直交周波数分割多重）をベースとする無線アクセスが採用されており、その理由として、そのような無線アクセスは、シンボルレートが低いため本質的にマルチパス干渉（ＭＰＩ）を受けにくいこと、サイクリックプレフィックス（ＣＰ）を使用していること、さまざまな送信帯域幅の構成に対応可能であること、が挙げられる。上りリンクには、ＳＣ−ＦＤＭＡ（シングルキャリア周波数分割多元接続）をベースとする無線アクセスが採用されており、なぜなら、ユーザ機器（ＵＥ）の送信出力が限られていることを考えれば、ピークデータレートを向上させるよりも広いカバレッジエリアを提供することが優先されるためである。

【0005】

１．２５ＭＨｚから２０ＭＨｚに渡る様々なスペクトル配分は、ＡＬＭ−ＯＦＤＭサブキャリアの数に対応する割り当てによってサポートされる。時分割デュプレックスおよび周波数分割デュプレックスの両方で可能な、対になっているスペクトルおよび対になってないスペクトルの両方における作動は、ＡＬＭ−ＯＦＤＭによってサポートされる。ＬＴＥにおいては、与えられたスペクトルを使用してフレキシブルなシステム配備を達成する目的で、１．４、３．０、５．０、１０．０、１５．０および２０．０ＭＨｚのような複数の送信帯域幅が指定されている。

【0006】

ＬＴＥアーキテクチャ
図１は、ＬＴＥの全体的なアーキテクチャを示しており、図２は、Ｅ−ＵＴＲＡＮのアーキテクチャをさらに詳しく示している。

【0007】

Ｅ−ＵＴＲＡＮは、ｅＮｏｄｅＢから構成されており、ｅＮｏｄｅＢは、ユーザ機器（ＵＥ）に向かうＥ−ＵＴＲＡのユーザプレーン（ＰＤＣＰ／ＲＬＣ／ＭＡＣ／ＰＨＹ）および制御プレーン（ＲＲＣ）のプロトコルを終端させる。ｅＮｏｄｅＢ（ｅＮＢ）は、物理層（ＰＨＹ）、メディアアクセス制御（ＭＡＣ）層、無線リンク制御（ＲＬＣ）層、およびパケットデータ制御プロトコル（ＰＤＣＰ）層（ユーザプレーンのヘッダ圧縮および暗号化の機能を含んでいる）をホストする。ｅＮｏｄｅＢは、制御プレーンに対応する無線リソース制御（ＲＲＣ）機能も提供する。ｅＮｏｄｅＢは、無線リソース管理、アドミッション制御、スケジューリング、交渉された上りリンクＱｏＳ（サービス品質）の実施、セル情報のブロードキャスト、ユーザプレーンデータおよび制御プレーンデータの暗号化／復号化、下りリンク／上りリンクのユーザプレーンパケットヘッダの圧縮／復元など、多くの機能を実行する。ｅＮｏｄｅＢは、Ｘ２インタフェースによって互いに接続されている。

【0008】

ｅＮｏｄｅＢは、Ｓ１インタフェースによってＥＰＣ（Evolved Packet Core：進化したパケットコア）に接続されており、より具体的には、Ｓ１−ＭＭＥによってＭＭＥ（Mobility Management Entity：移動管理エンティティ）に接続されており、Ｓ１−Ｕによってサービングゲートウェイ（ＳＧＷ：Serving Gateway）に接続されている。Ｓ１インタフェースは、ＭＭＥ／サービングゲートウェイとｅＮｏｄｅＢとの間の多対多関係をサポートする。

【0009】

ＳＧＷは、ユーザデータパケットのルーティングおよび転送を行う一方で、ｅＮｏｄｅＢ間のハンドオーバ時にユーザプレーンのモビリティアンカー（mobility anchor）としての役割と、ＬＴＥとそれ以外の３ＧＰＰ技術との間のモビリティのためのアンカーとしての役割も果たす（Ｓ４インタフェースを終端させ、２Ｇ／３Ｇシステムとパケットデータネットワークゲートウェイ（ＰＤＮ ＧＷ）との間でトラフィックを中継する）。ＳＧＷは、アイドル状態のユーザ機器に対しては、そのユーザ機器への下りリンクデータが到着したとき下りリンク（ＤＬ）データ経路を終端させ、ページングをトリガする。ＳＧＷは、ユーザ機器のコンテキスト（例えば、ＩＰベアラサービスのパラメータ、ネットワーク内部ルーティング情報）を管理および格納する。さらに、ＳＧＷは、合法傍受（lawful interception）の場合にユーザトラフィックの複製を実行する。

【0010】

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

【0011】

ハイブリッドＡＲＱ方式
信頼できないチャネルを通じてのパケット送信システムにおける誤り検出・訂正のための一般的な手法は、ハイブリッド自動再送要求（ＨＡＲＱ：Hybrid Automatic Repeat reQuest）と称される。ハイブリッドＡＲＱは、順方向誤り訂正（ＦＥＣ）とＡＲＱの組合せである。

【0012】

自動再送要求（ＡＲＱ）は、データ送信のための誤り制御方法であり、ＡＣＫおよびタイムアウトを使用して信頼性のあるデータ送信を達成する。ＡＣＫは、受信側によって送信側に送られるメッセージであり、受信側がデータパケットを正しく受信したことを示している。送信側が、タイムアウト（ＡＣＫを受信するための適度な時間間隔）より前にＡＣＫを受信しない場合、通常では、送信側は、自身がＡＣＫを受信するまで、または所定の再送回数を超えるまで、フレームを再送信する。

【0013】

順方向誤り訂正は、データ送信における誤りを制御するために採用され、送信側が自身のメッセージに冗長データを追加する。これにより、受信側は、誤りが発生したかを検出することができ、さらに、送信側からの追加のデータを要求することなくいくつかの誤りを訂正することができる。結果として、順方向誤り訂正により、特定の制限内において誤りのいくつかを訂正できるため、データパケットの再送信をしばしば回避することができる。しかしながら、各データパケットに付加される追加のデータに起因して、この方策では広い帯域幅が要求される。

【0014】

ＦＥＣ符号化されたパケットが送信され、受信側がそのパケットを正しく復号できない場合（誤りは通常ではＣＲＣ（巡回冗長検査）によってチェックされる）、受信側はそのパケットの再送信を要求する。

【0015】

ＬＴＥでは、信頼性を提供するために２つのレベルの再送がある。すなわち、ＭＡＣレイヤでのＨＡＲＱとＲＬＣレイヤでのアウターＡＲＱである。アウターＡＲＱは、単一ビットエラー−フィードバック・メカニズム（すなわちＡＣＫ／ＮＡＣＫ）を用いることによって単純に行われるＨＡＲＱによって修正されない残差を取り扱うために要求される。Ｎプロセス・ストップアンドウェイトＨＡＲＱは、ＤＬ中の非同期再送とＵＬの同期再送を持つところで用いられる。同期ＨＡＲＱは、ＨＡＲＱブロックの再送があらかじめ定義された周期的間隔で起こることを意味する。それゆえに、明白なシグナリングが、受信機に再送スケジュールを示すために要求されることはない。非同期ＨＡＲＱは、無線インタフェース状況に基づく再送のスケジューリングの柔軟性を提供する。この場合、ＨＡＲＱプロセスのいくらかの識別は、正しい組み合わせおよびプロトコルオペレーションを考慮に入れるために送出される必要がある。

【0016】

下りリンクデータ送信のためのＨＡＲＱプロトコルオペレーションは、ＨＳＤＰＡに類似する、あるいは、同一でありさえする。

【0017】

上りリンクデータ送信のためのＨＡＲＱプロトコルオペレーションでは、再送のスケジュールの仕方が異なる２つのオプションがある。再送は、（同期の非適応的再送のために）ＮＡＣＫによってスケジュールされるか、（同期の適応的再送のために）ＰＤＣＣＨによって、明白なスケジューリングされる。同期の非適応的な再送の場合、再送は、前の上りリンク送信と同一のパラメータを使用する。すなわち、再送は、それぞれ同一の変調スキームを使用する同一の物理チャネルリソース上で送出される。

【0018】

同期の適応的再送は、ＰＤＣＣＨを介して明白にスケジュールされるから、ｅＮＢは、再送のための特定のパラメータを交換する可能性を持つ。例えば、再送は、上りリンクの中でフラグメーションを避けるために、異なる周波数リソース上でスケジュールされる。あるいは、ｅＮＢは、変調スキームを変更したり、ＵＥに再送のために使用するための冗長バージョンを示したりすることができる。

【0019】

ＨＡＲＱフィードバック（ＡＣＫ／ＮＡＣＫ）とＰＤＣＣＨシグナリングが、同一のタイミングで起こることに留意すべきである。したがって、ＵＥは、同期の非適応的再送が引き起こされるかどうか、すなわち、ＮＡＣＫのみが受信された、または、ｅＮＢが同期の適応的再送を要請したか否か、すなわちＰＤＣＣＨが送出されたか、について確認する必要があるのみである。

【0020】

第１層／第２層（Ｌ１／Ｌ２）制御シグナリング
スケジューリングされたユーザに、その割り当てステータス、トランスポートフォーマット、およびその他のデータ関連情報（例：ＨＡＲＱ情報、送信電力制御（ＴＰＣ）コマンド）を知らせる目的で、Ｌ１／Ｌ２制御シグナリングはデータと一緒に下りリンク上で送信される。Ｌ１／Ｌ２制御シグナリングは、サブフレームの中で下りリンクデータと一緒に多重化され、ユーザ割り当てがサブフレーム単位で変化しうるものとして仮定される。留意すべき点として、ユーザ割り当てはＴＴＩ（送信時間間隔）ベースで実行されることもあり、その場合、ＴＴＩ長はサブフレームの倍数である。ＴＴＩ長は、サービスエリアにおいてすべてのユーザについて一定とする、ユーザごとに異なる長さをとりうる、あるいは、ユーザごとに動的な長さとすることもできる。一般的には、Ｌ１／Ｌ２制御シグナリングをＴＴＩごとに１回送信するのみでよい。Ｌ１／Ｌ２制御シグナリングは、物理下りリンク制御チャネル（ＰＤＣＣＨ）を介して送信される。３ＧＰＰ，ＬＴＥの中では、上りリンクスケジューリンググラントあるいは上りリンクリソース割り当てとも呼ばれる、上りリンク送信のための割り当ても、ＰＤＣＣＨを介して送信される、ということに留意すべきである。

【0021】

下りリンクと上りリンクのデータ送信
下りデータ送信に関して、Ｌ１／Ｌ２制御シグナリングは、下りリンクパケットデータと共に送信される分離物理チャネル（ＰＤＣＣＨ）上で送信される。下りリンク制御情報は、全体的なサイズおよびその分野に含まれる情報も異なるいくつかのフォーマットの中に存在する。現在ＬＴＥのリリース８、リリース９（３ＧＰＰ ＬＴＥ）に定められた、異なるＤＣＩフォーマットは、３ＧＰＰ ＴＳ３６．２１２、“Multiplexing and channel coding (Release 9)”、バージョン８．８．０あるいは９．０．０、セクション５．３．３．１（ｈｔｔｐ：／／ｗｗｗ．３ｇｐｐ．ｏｒｇから入手可能であり、その内容は本明細書に援用される）に詳細に記述されている。このＬ１／Ｌ２制御シグナリングは、一般には以下の情報を含んでいる。
− データが送信される物理リソース（例えば、ＯＦＤＭにおけるサブキャリアあるいはサブキャリアブロック、ＣＤＭＡにおけるコード）。この情報は、端末（受信機）に対して、データが送信されるリソースを特定することを可能にする。
− ユーザ機器が、Ｌ１／Ｌ２制御シグナリングの中にキャリア識別フィールド（ＣＩＦ:Carrier Indication Field）を持つように構成されているときには、この情報は、特定の制御シグナリング情報が意味されるコンポーネントキャリアを特定する。これは、もう１つのコンポーネントキャリアを対象とした割り当てを、１つのコンポーネントキャリア上で送られること（"cross-carrier scheduling"）を可能にする。この他の、クロススケジュールコンポーネントキャリアは、例えば、ＰＤＣＣＨにはないコンポーネントキャリア、すなわち、そのクロススケジュールコンポーネントキャリアがＬ１／Ｌ２制御シグナリングを全く運ばないものとすることができる。
− 送信に使われるトランポートフォーマット。これは、データのトランポートブロックサイズ（ペイロードサイズ、情報ビットサイズ）、ＭＣＳ（Modulation and Coding Scheme）レベル、周波数利用効率、コードレート等である。この情報（通常はリソース割り当て（ユーザ機器に割り当てられたリソースブロック数等）と共に）は、ユーザ機器（受信機）に対して、復調、デレートマッチングおよび復号プロセスを開始するために、情報ビットサイズ、変調方式およびコードレートを明らかにすることを可能とする。この変調方式は、信号によって明確に示される。
− ハイブリッドＡＲＱ（ＨＡＲＱ）情報：
・ ＨＡＲＱプロセス数：ユーザ機器に対して、データがマッピングされたハイブリッドＡＲＱプロセスを明らかにすることを可能とする。
・ シーケンス数あるいは新規データインジケータ（ＮＤＩ：New Data Indicator）：ユーザ機器に対して、送信パケットが、新規パケットか再送パケットかを明らかにすることを可能とする。ソフト合成が、ＨＡＲＱプロトコルの中で実施されていれば、ＨＡＱＲプロセス数と共にあるシーケンス数あるいは新規データインジケータは、復号に先だってのＰＤＵのための送信パケットのソフト合成を可能とする。
・ 冗長性および／または配置バージョン：ユーザ機器に、使用された（デレートマッチングにおいて要求された）ハイブリッドＡＲＱ冗長性バージョン、および／または、使用された（復調において要求された）配置バージョンを伝える。
・ ＵＥ識別（ＵＥ ＩＤ）：Ｌ１／Ｌ２制御シグナリングがどのユーザ機器を目的としているのかを伝える。典型的な実施の中において、この情報は、この情報を読もうとする他のユーザ機器を妨げるために、Ｌ１／Ｌ２制御シグナリングのＣＲＣをマスクするために用いられる。

【0022】

上りリンクパケットデータ送信を可能にするために、Ｌ１／Ｌ２制御シグナリングは、送信の詳細についてユーザ機器に伝えるために、下りリンク（ＰＤＣＣＨ）上で送信される。このＬ１／Ｌ２制御シグナリングは、一般には以下の情報を含んでいる。
− データが送信される物理リソース：ユーザ機器がデータを送信するときのもの（例えば、ＯＦＤＭにおけるサブキャリアあるいはサブキャリアブロック、ＣＤＭＡにおけるコード）。
− ユーザ機器が、Ｌ１／Ｌ２制御シグナリングの中にキャリア識別フィールド（ＣＩＦ:Carrier Indication Field）を持つように構成されているときには、この情報は、特定の制御シグナリング情報が意味されるコンポーネントキャリアを特定する。これは、もう１つのコンポーネントキャリアを対象とした割り当てを、１つのコンポーネントキャリア上で送られること（"cross-carrier scheduling"）を可能にする。この他の、クロススケジュールコンポーネントキャリアは、例えば、ＰＤＣＣＨにはないコンポーネントキャリア、すなわち、そのクロススケジュールコンポーネントキャリアがＬ１／Ｌ２制御シグナリングを全く運ばないものとすることができる。
− 上りリンクグラントのためのＬ１／Ｌ２制御シグナリング：上りリンクのコンポーネントキャリアとリンクされたＤＬコンポーネントキャリアで、あるいは、いくつかのＤＬコンポーネントキャリアが同一のＵＬコンポーネントキャリアにリンクしていればいくつかのＤＬコンポーネントキャリアのひとつで送られる。
− トランポートフォーマット：ユーザ機器が送信のために使うべきもの。これは、データのトランポートブロックサイズ（ペイロードサイズ、情報ビットサイズ）、ＭＣＳ（Modulation and Coding Scheme）レベル、周波数利用効率、コードレート等である。この情報（通常はリソース割り当て（ユーザ機器に割り当てられたリソースブロック数等）と共に）は、ユーザ機器（受信機）に対して、復調、デレートマッチングおよび復号プロセスを開始するために、情報ビットサイズ、変調方式およびコードレートを明らかにすることを可能とする。この変調方式は、信号によって明確に示される。
− ハイブリッドＡＲＱ（ＨＡＲＱ）情報：
・ シーケンス数あるいは新規データインジケータ：ユーザ機器に、新規パケットあるいは再送パケットを送信することを伝える。
・ 冗長性および／または配置バージョン：ユーザ機器に、使用された（デレートマッチングにおいて要求された）ハイブリッドＡＲＱ冗長性バージョン、および／または、使用された（復調において要求された）配置バージョンを伝える。
・ ＵＥ識別（ＵＥ ＩＤ）：Ｌ１／Ｌ２制御シグナリングがどのユーザ機器を目的としているのかを伝える。典型的な実施の中において、この情報は、この情報を読もうとする他のユーザ機器を妨げるために、Ｌ１／Ｌ２制御シグナリングのＣＲＣをマスクするために用いられる。

【0023】

上りリンクと下りリンクのデータ伝送の中で上記に言及した情報部分の正確な送信の仕方についていくつかの異なる可能性がある。さらに、上りリンクと下りリンクの中で、Ｌ１／Ｌ２制御シグナリングが、さらなる情報を含む、あるいは、情報の一部を省略するかもしれない。例えば、以下の通りである。
− （いつも同一の冗長および／または配置（constellation）バージョンである）チェイスコンバイニングが使用されるか、冗長および／または配置バージョンが事前に決定されれば、冗長および／または配置バージョンは必要ないかもしれず、このためシグナリングされないかもしれない。
− 電力制御情報は、制御信号の中に追加的に含められるかもしれない。
− 例えば、プレコーディングのような制御情報に関連したＭＩＭＯは、制御信号の中に追加的に含められるかもしれない。
− 複数の符号語のＭＩＭＯ送信のケースにおいて、トランスポートフォーマットおよび／または複数の符号語のためのＨＡＲＱ情報は、含められるかもしれない。

【0024】

ＬＴＥの中で、ＰＤＣＣＨ上で送出された（物理上りリンクシェアードチャネル（ＰＵＳＣＨ）上の）上りリンクリソースの割り当てのために、Ｌ１／Ｌ２制御シグナリングは、ＨＡＱＲプロセス数を含まない。これは、同期ＨＡＲＱプロトコルがＬＴＥ上り回線のために使用されるためである。上りリンク送信に使われるＨＡＲＱプロセスは、タイミングによって与えられる。さらに、冗長バージョン（ＲＶ）情報がトランスポートフォーマット情報と共同で符号化される点に留意する必要がある。すなわち、ＲＶ情報は、トランスポートフォーマット（ＴＦ）フィールドの中に埋め込まれる。トランスポートフォーマット（ＴＦ）のそれぞれの変調と符号化のスキーム（ＭＣＳ）フィールドは、例えば５ビットのサイズを持ち、それらは、３２エントリに対応する。３つのＴＦ／ＭＣＳテーブルエントリは、冗長バージョン（ＲＶ）１、２または３を示すために予約される。残りのＭＣＳテーブルエントリは、暗黙的にＲＶ０を示すＭＣＳレベル（ＴＢＳ）を送出するために使用される。ＰＵＳＣＨのためにＰＤＣＣＨ上で送信される上りリンク割り当てのためのＴＢＳ／ＲＶシグナリングは、以下の（規格ＴＳ３６．２１３、テーブル８．６．１−１から取られた）テーブル１に示される。

【表1】

【0025】

ＰＤＣＣＨのＣＲＣフィールドのサイズは１６ビットである。変調オーダとトランスポートブロックサイズの計算は、規格ＴＳ３６．２１３のセクション８．６．２の中に記載されている（ｈｔｔｐ：／／ｗｗｗ．３ｇｐｐ．ｏｒｇから入手可能であり、その内容は本明細書に援用される）。上りリンクＰＵＳＣＨ送信のために使用されるトランスポートブロックサイズテーブルは、規格ＴＳ３６．２１３のセクション７．１．７．２．１の中に見ることができる（ｈｔｔｐ：／／ｗｗｗ．３ｇｐｐ．ｏｒｇから入手可能であり、その内容は本明細書に援用される）。

【0026】

ＬＴＥの中のＰＤＣＣＨ上でシグナリングされる下りリンク割り当て（ＰＤＳＣＨ）に対して、冗長バージョン（ＲＶ）が２ビットの領域の中に分かれてシグナリングされる。変調オーダ情報は、トランスポートフォーマット情報とともに一体で符号化される。上りリンクのケースと同様に、ＰＤＣＣＨ上でシグナリングされる５ビットのＭＣＳ領域がある。エントリの３つは、トランスポートフォーマット（トランスポートブロック）情報を提供しない明示的な変調オーダをシグナリングするために受信される。残りの２９エントリのために、変調オーダおよびトランスポートブロックサイズ情報が、（規格ＴＳ２６．２１３、Ｔａｂｌｅ ７．７．７．１−１から得られる）ＰＤＳＳＨのために以下のテーブル２で示されるようにシグナリングされる。

【表2】

【0027】

変調オーダとトランスポートブロックサイズの計算は、規格ＴＳ３６．２１３のセクション７．１．７の中に記載されている。

【0028】

半永続スケジューリング（ＳＰＳ）
下りリンクおよび上りリンクでは、スケジューリングを行うｅＮｏｄｅＢは、ユーザ機器がそれらを特定するＣ−ＲＮＴＩを介してアドレスされるＬ１／Ｌ２制御チャネル（ＰＤＣＣＨ）を介して送信時間間隔毎にユーザ機器にリソースを動的に割り当てる。既に上記で示したように、ＰＤＣＣＨのＣＲＣは、アドレスされたユーザ機器のＣ−ＲＮＴＩ（動的ＰＤＣＣＨと呼ばれる）とともにマークされる。マッチングＣ−ＲＮＴＩによるユーザ機器のみが、正しくＰＤＣＣＨの内容を復号することができる。即ち、ＣＲＣチェックがポジティブである。この種のＰＤＣＣＨシグナリングは、動的（スケジューリング）グラントとも呼ばれる。ユーザ機器は、それが割り当てられる可能性がある割り当て（下りリンクと上りリンク）を見つけるために、動的なグラントのためにＬ１／Ｌ２制御チャネルを送信時間間隔毎に監視する。

【0029】

加えて、Ｅ−ＵＴＲＡＮは、永続的に、最初のＨＡＲＱ送信に対して、上りリンク／下りリンクリソースを割り当てることができる。要求されたとき、再送は、Ｌ１／Ｌ２制御チャネルを介して明白に合図される。再送は、動的にスケジューリングされるため、この種のオペレーションは、半永続スケジューリング（ＳＰＳ）と呼ばれる。すなわち、リソースは半永続的な原則（半永続的なリソース割り当て）で、ユーザ機器に割り当てられる。その利益は、最初のＨＡＲＱ送信のためのＰＤＣＣＨリソースが保存されることである。半永続スケジューリングが、ＳＣｅｌｌではなく、リリース１０の中のＰＣｅｌｌで使用されるかもしれない。

【0030】

半永続スケジューリングを使用してスケジューリングされるかもしれない１つの例は、ボイスオーバＩＰ（ＶｏＩＰ）である。２０ｍｓ毎にＶｏＩＰパケットは、トーク・スパート（talk-spurt）の間のコーデックで生成される。したがって、ｅＮｏｄｅＢは、２０ｍｓ毎に、上りリンクあるいはそれぞれの下りリンクリソースを割り当てることができる。そのとき、そのリソースは、ボイスオーバＩＰパケットの送信のために使用され得る。一般的に、半永続スケジューリングは、予想されるトラフィック挙動が予測可能であるサービス（すなわち、ビットレートが一定であり、パケット到着時間が周期的である）に対するサービスのために有益である。

【0031】

ユーザ機器も、永続的に、最初の送信のために割り当てられたリソースのサブフレームの中でＰＤＣＣＨを監視する。動的（スケジューリング）グラント、すなわち、Ｃ−ＲＮＴＩ−マスクされたＣＲＣによるＰＤＣＣＨは、半永続的なリソース割り当てを優先させることができる。このケースでは、ユーザ機器は、ユーザ機器が半永続的なリソース割り当てを持つサブフレームの中に、Ｌ１／Ｌ２制御チャネル上のＣ−ＲＮＴＩを見つけた場合、このＬ１／Ｌ２制御チャネル割り当ては、送信時間間隔のための永続的リソース割り当てよりも優先される。そして、ユーザ機器は、動的グラントに従う。ユーザ機器は、動的グラントを探し出せないとき、半永続的なリソース割り当てに従って送信／受信を行う。

【0032】

半永続スケジューリングの構成は、ＲＲＣシグナリングによって行われる。例えば、永続的な配分の周期性（例えばＰＳ＿ＰＥＲＩＯＤ）は、無線リソース制御（ＲＲＣ）シグナリングの中で合図される。永続的な配分のアクティブ化、さらには物理的リソースおよびトランスポートフォーマットパラメータの正確なタイミングは、ＰＤＣＣＨシグナリングを介して送られる。一旦、半永続スケジューリングがアクティブ化すると、ユーザ機器は、すべてのＰＳ＿ＰＥＲＩＯＤにおいてＳＰＳアクティブ化ＰＤＣＣＨに従って半永続的なリソース割り当てを続ける。基本的に、ユーザ機器は、ＳＰＳアクティブ化ＰＤＣＣＨを保存し、合図された周期で、ＰＤＣＣＨに従う。

【0033】

永続スケジューリングをアクティブ化する動的ＰＤＣＣＨ（ＳＰＳアクティブ化ＰＤＣＣＨとも呼ばれる）をＰＤＣＣＨから区別するために、分離識別子が導入されている。基本的に、ＳＰＳアクティブ化ＰＤＣＣＨのＣＲＣは、以下ではＳＰＳ Ｃ−ＲＮＴＩと呼ばれるこの追加識別子によってマスクされる。ＳＰＳ Ｃ−ＲＮＴＩのサイズも、通常のＣ−ＲＮＴＩと同じく１６ビットである。さらに、ＳＰＳ Ｃ−ＲＮＴＩは、ユーザ機器特有のものであるすなわち、半永続のために構成される各ユーザ機器は、ユニークなＳＰＳ Ｃ−ＲＮＴＩを割り当てられる。

【0034】

このケースでは、ユーザ機器は、半永続的なリソース割り当てが、対応するＳＰＳアクティブ化ＰＤＣＣＨによってアクティブ化されたことを検出する。そのユーザ機器は、ＰＤＣＣＨの内容（すなわち半永続的なリソース割り当て指示）を記憶し、すべての半永続スケジューリング間隔、すなわち、ＲＲＣを介して合図された間隔でそれを適用する。既に述べたように、動的ＰＤＣＣＨ上で合図される動的割り当ては、１回限りの割り当てである。ＳＰＳ割り当ての再送も、ＳＰＳ Ｃ−ＲＮＴＩを使用して合図される。ＳＰＳアクティブ化をＳＰＳ再送から区別するために、ＮＤＩ（新規データインジケータ）ビットが使用される。ＳＰＳアクティブ化は、ＮＤＩビットを０にセットすることによって示される。１にセットされたＮＤＩビットのＳＰＳ ＰＤＣＣＨは、半永続スケジューリングされた最初の送信に対する再送を示す。

【0035】

半永続スケジューリングのアクティブ化と同様に、ｅＮｏｄｅＢは、ＳＰＳリソース開放とも呼ばれる、半永続スケジューリングを非アクティブ化することもできる。半永続スケジューリングの割り当ての取り消しが合図されるいくつかのオプションがある。１つのオプションは、いくつかの予め定義された値、すなわち、ゼロサイズリソース割り当てを示すＳＰＳ ＰＤＣＣＨにセットされるいくつかのＰＤＣＣＨフィールドで、ＰＤＣＣＨシグナリングを使用することである。もうひとつのオプションは、ＭＡＣ制御シグナリングを使用することである。

【0036】

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

【数1】

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

【0037】

たとえば３ＧＰＰロング・ターム・エボリューション（ＬＴＥ）で使用されているように、複数キャリア通信システム、たとえばＯＦＤＭを使用すると仮定すると、スケジューラによって割り当てることのできるリソースの最小単位は、１「リソースブロック」である。物理リソースブロックは、図４に例示されているように、時間領域では

【数2】

個の連続するＯＦＤＭシンボル、周波数領域では

【数3】

個の連続するサブキャリアとして定義される。したがって、３ＧＰＰ ＬＴＥ（リリース８）では、物理リソースブロックは、時間領域の１スロット、周波数領域の１８０ｋＨｚに対応する

【数4】

個のリソース要素からなる（下りリンク・リソース・グリッドに関するさらなる詳細については、たとえば、ｈｔｔｐ：／／ｗｗｗ．３ｇｐｐ．ｏｒｇから入手可能であり、その内容が本明細書に援用される３ＧＰＰ ＴＳ ３６．２１１、「Ｅｖｏｌｖｅｄ Ｕｎｉｖｅｒｓａｌ Ｔｅｒｒｅｓｔｒｉａｌ Ｒａｄｉｏ Ａｃｃｅｓｓ（Ｅ−ＵＴＲＡ）；Ｐｈｙｓｉｃａｌ Ｃｈａｎｎｅｌｓ ａｎｄ Ｍｏｄｕｌａｔｉｏｎ（Ｒｅｌｅａｓｅ ８）」、ｖｅｒｓｉｏｎ ８．９．０または９．０．０、セクション６．２を参照されたい）。

【0038】

「コンポーネントキャリア」という用語は、数個のリソースブロックの組合せに言及する。ＬＴＥの将来のリリースにおいて、「コンポーネントキャリア」という用語はもはや使用されない。代わりに、この用語は「セル」に変更される。「セル」は、ダウンリンクリソースおよび任意でアップリンクリソースの組合せに言及する。ダウンリンクリソースのキャリア周波数とアップリンクリソースのキャリア周波数との連結（linking）は、ダウンリンクリソースで送信されるシステム情報に示される

【0039】

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

【0040】

広い帯域幅のサポートのためのＬＴＥ−Ａのキャリアアグリゲーション
ＬＴＥシステムが２０ＭＨｚのみをサポートできるのに対して、ＬＴＥ−Ａｄｖａｎｃｅｄシステムがサポートすることができる帯域幅は１００ＭＨｚである。近頃、無線周波スペクトルの欠如は、無線ネットワークの開発のボトルネックになっていた。そして、その結果、ＬＴＥ−Ａｄｖａｎｃｅｄシステムのために十分に広いスペクトルバンドを見つけることは困難である。従って、より広い無線周波スペクトルバンドを得る方法を見つけることは緊急課題であって、ありうる答えはキャリアアグリゲーション機能である。

【0041】

キャリアアグリゲーション（ＣＡ）の中で、２またはそれ以上のコンポーネントキャリア（ＣＣＥ）が、１００ＭＨｚより広い送信帯域幅をサポートするためにアグリゲートされる。ＬＴＥのこれらのキャリアが異なる周波数帯域の中であるとしても、ＬＴＥシステムのいくつかのキャリアは１００ＭＨｚに対して十分に広いＬＴＥ−Ａｄｖａｎｃｅｄシステムの中の１つのより広いチャネルにアグリゲートされる。アグリゲーとされたより広いチャネル上で、ＬＴＥ−Ａｄｖａｎｃｅｄに準拠するユーザ機器は、いくつかのスペクトラム断片に対して同時にアクセスすることができる。一方、ＬＴＥユーザ機器は彼らの１つのスペクトル断片だけにのみアクセスすることができる。このように、ビットのコストを下げると同様に、スペクトラムの互換性のための必要性を検討する。

【0042】

少なくとも、上りリンクと下りリンクのコンポーネントキャリアのアグリゲータされた数が同一であるときには、すべてのコンポーネントキャリアは、３ＧＰＰ ＬＴＥ（リリース８／９）と互換性を持つように構成され得る。これは、すべてのコンポーネントキャリアが３ＧＰＰ ＬＴＥ（リリース８／９）と互換性を持つ必要があることを必ずしも意味するものではない。

【0043】

ユーザ機器は、１または複数のコンポーネントキャリア上で同時に送受信を行ってもよい。同時に送受信可能なコンポーネントキャリアの数は、ユーザ機器の能力に依存する。

【0044】

３ＧＰＰ ＬＴＥ（リリース８／９）と互換性を持つユーザ機器は、３ＧＰＰ ＬＴＥ（リリース８／９）の仕様に従うＣＣの構造を規定された単一ＣＣ上のみで送受信を行うことができる。一方、キャリアアグリゲーションのための送受信が可能な、３ＧＰＰ ＬＴＥ−Ａ（リリース１０）と互換性を持つユーザ機器は、複数のコンポーネントキャリア上で同時に送受信を行うことができる。

【0045】

キャリアアグリゲーションは、３ＧＰＰ ＬＴＥ（リリース８／９）の数理神秘学（numerology）を使用する周波数領域中の最大１１０リソースブロックに限定される各コンポーネントキャリアの隣接および非隣接のコンポーネントキャリアの両方に対してサポートする。

【0046】

同一のｅＮｏｄｅＢ（基地局）から始まる、上りリンクと下りリンクで帯域幅が異なるかもしれない、異なる数のコンポーネントキャリアをアグリゲートするために、３ＧＰＰ ＬＴＥ−Ａ（リリース１０）と互換性を持つユーザ機器を構成することができる。構成され得る下りリンクのコンポーネントキャリアの数はＵＥの下りリンクアグリゲーション能力に依存する。対照的に、構成され得る上りリンクのコンポーネントキャリアの数はＵＥの上りリンクアグリゲーション能力に依存する。下りリンクコンポーネントキャリアより多くの上りリンクコンポーネントキャリアでＵＥを構成することができないかもしれない。

【0047】

典型的なＴＤＤの配置では、コンポーネントキャリアの数および上りリンクと下りリンクにおける各コンポーネントキャリアの帯域幅は同一となる。同一のｅＮｏｄｅＢから始まるコンポーネントキャリアは、同一のカバレッジを供給しない必要がある。

【0048】

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

【0049】

複数キャリアのアグリゲーションの性質は、ＭＡＣレイヤ上でのみ公開される。上りリンクと下りリンクの両方のために、各アグリゲートされたコンポーネントキャリアにＭＡＣで要求される１つのＨＡＲＱエンティティがある。（上りリンクのためのＳＵ−ＭＩＭＯを除いて）コンポーネントキャリア毎に多くても一つのトランポートブロックがある。トランポートブロックとその潜在的なＨＡＲＱ再送は、同一のコンポーネントキャリア上にマッピングされる必要がある。

【0050】

動的なキャリアアグリゲーションのレイヤ２構造は、下りリンと上りリンクとで、それぞれ、図５と図６に示される。

【0051】

ＲＲＣ接続の設定／再設定で、１つのセルは、セキュリティ入力（１つのＥＣＧＩ、１つのＰＣＩおよび１つのＡＲＦＣＮ）およびＬＴＥ（リリース８／９）と同様に非アクセス層モビリティ情報（例えばＴＡＩ）を提供する。ＲＲＣ接続の設定／再設定の後、そのセルに対応するコンポーネントキャリアは、プライマリセル（ＰＣｅｌｌ）と呼ばれる。接続モード中のユーザ機器毎に構成される１つの下りリンクプライマリセル（ＤＬ ＰＣｅｌｌ）と１つの上りリンクプライマリセル（ＵＬ ＰＣｅｌｌ）のみがいつも存在する。コンポーネントキャリアのセットを構成された範囲内で、他のセルは、セカンダリセル（ＳＣｅｌｌｓ）と呼ばれる。下りリンクと上りリンクのプライマリセルの特徴は以下の通りである：
− 上りリンクＰＣｅｌｌは、レイヤ１上りリンク制御情報の送信のために使用される。
− 下りリンクＰＣｅｌｌは、ＳＣｅｌｌｓと異なり、非アクティブかすることができない。
− 下りリンクＰＣｅｌｌが、レイリーフェージング（ＲＬＦ）を経験するときであって、下りリンクＳＣｅｌｌｓがＲＬＦを経験するときではないときに、再設定は引き起こされる。
− 下りリンクＰＣｅｌｌは、ハンドオーバ時に変更することができる。
− 非アクセス層情報は、下りリンクＰＣｅｌｌから取られる。
− ＰＣｅｌｌは、ハンドオーバ手順（すなわちセキュリティ鍵変更とＲＡＣＨ手順）でのみ変更され得る。
− ＰＣｅｌｌは、ＰＵＣＣＨの送信のために使用される。

【0052】

コンポーネントキャリアの設定および再設定は、ＲＲＣによって実行され得る。アクティブ化および非アクティブ化は、ＭＡＣ制御エレメントを介して行われる。イントラＬＴＥハンドオーバで、ＲＲＣは、ターゲットセルの中の使用のためにＳＣｅｌｌｓを追加、削除あるいは変更することができる。新しいＳＣｅｌｌを加えるとき、専用のＲＲＣシグナリングがそのＳＣｅｌｌのシステム情報を送るために使用される。その情報は、（ハンドオーバのためのリリース８／９の場合のように）送信／受信のために必要となる。

【0053】

ユーザ機器は、キャリアアグリゲーションで構成されるとき、常にアクティブである一組の上りリンクと下りリンクのコンポーネントキャリアが存在する。その一組の下りリンクのコンポーネントキャリアは、「ＤＬアンカーキャリア」とも呼ばれる。同様のことが、上りリンクでも適用される。

【0054】

キャリアアグリゲーションが構成されるとき、ユーザ機器は、同時に複数のコンポーネントキャリアにスケジューリングされるかもしれないが、いつでも、最大でも１つのランダムアクセス手順しか進行しない。クロスキャリアスケジューリングは、もう一つのコンポーネントキャリア上のリソースをスケジューリングするために、コンポーネントキャリアのＰＤＣＣＨを用いることを可能にする。この目的のために、コンポーネントキャリア識別フィールドは、ＣＩＦと呼ばれるそれぞれのＤＣＩフォーマットの中に導入される。

【0055】

否クロスキャリアスケジューリングがあるとき、上りリンクと下りリンクとの間のコンポーネントキャリアのリンクは、グラントが適用されるための上りリンクのコンポーネントキャリアを特定することを可能にする。

【0056】

コンポーネントキャリアの（非）アクティブ化およびＤＲＸオペレーション
キャリアアグリゲーションの中で、ＵＥが１つのコンポーネントキャリアのみで構成されるときにはいつでも、リリース８／９の適用に従う非連続受信（ＤＲＸ）が適用される。他のケースでは、同一のＤＲＸオペレーションが、全ての、構成されアクティブ化されたコンポーネントキャリア（すなわち、ＰＤＣＣＨを監視するための同一のアクティブ時間）に適用される。アクティブ時間内のとき、コンポーネントキャリアは、いつも、他の構成され、アクティブ化されたコンポーネントキャリア（更なる規制ＦＦＳ）をスケジューリングするかもしれない。

【0057】

ＣＡが構成されるとき、合理的なＵＥバッテリの消費を可能にするために、ＤＬ ＳＣｅｌｌのためのコンポーネントキャリアのアクティブ化／非アクティブ化のメカニズムは導入される（すなわち、アクティブ化／非アクティブ化はＰＣに適用されない）。ＳＣｅｌｌがアクティブでないとき、ＵＥは、対応するＰＤＣＣＨまたはＰＤＳＣＨを受信する必要がなく、ＣＱＩ測定を実行することを要求されない。反対に、下りリンクＳＣｅｌｌがアクティブであるとき、ＵＥは、ＰＤＳＣＨと（存在するならば）ＰＤＣＣＨを受信し、ＣＱＩ測定を実行することが期待される。同様に、非アクティブ化されたＳＣｅｌｌのために、ＵＥは、ＳＣｅｌｌ上にＵＬ−ＳＣＨも、ＳＣｅｌｌ上でサウンディング基準信号（ＳＲＳ）も送信しない。

【0058】

ＳＣｅｌｌのためのアクティブ化／非アクティブ化のメカニズムの他の詳細は以下の通りである。
− ＳＣｅｌｌの明白なアクティブ化はＭＡＣシグナリングによって行われる。
− ＳＣｅｌｌの明白な非アクティブ化はＭＡＣシグナリングによって行われる。
− ＳＣｅｌｌの暗黙の非アクティブ化も可能である。
− ＳＣｅｌｌは、個別にアクティブ化／非アクティブ化され得る。そして、単一のアクティブ化／非アクティブ化コマンドは、構成された下りリンクＳＣｅｌｌのサブセットをアクティブ化／非アクティブ化することができる。
− 構成されたＣＣのセットに追加されたＳＣｅｌｌは、最初のうちは非アクティブ化されている。

【0059】

ＵＬレート制御／論理チャネルの優先順位付け手順
ＵＥは、無線ベアラ間で上りリンクリソースの共有を管理する上りリンクレート制御機能を持っている。以下では、この上りリンクレート制御機能は、論理チャネルの優先順位付け手順とも呼ばれる。論理チャネルの優先順位付け（ＬＣＰ）手順は、新規送信が実行されるとき、すなわち、トランスポートブロックが生成される必要があるときに適用される。キャパシティを割り当てるための１つの提案は、それぞれが、そのベアラのために最小限のデータレートにて割り当てられたものと等価のものを受信するまで、優先順序の中でそれぞれのベアラにリソースを割り当てることである。この後、追加のキャパシティが例えば、優先順序の中で、ベアラに割り当てられる。

【0060】

以下のＬＰＣ手順の説明から明らかなように、ＵＥにあるＬＣＰ手順の実行は、ＩＰ界でよく知られているトークンバケットトモデルに基づく。このモデルの基本機能性は、以下の通りである。周期的そして所定のレートで、データ量を送信するための権利を表すトークンがバケットに加えられる。ＵＥがリソースを与えられるとき、バケットの中のトークンの数によって表される量までデータを送信することが許可される。データを送信するとき、ＵＥは、送信されたデータ量に相当する数のトークンを取り去る。バケットがいっぱいの場合、さらなるトークンは破棄される。

【0061】

トークンの追加のために、このプロセスの繰り返しの期間がＴＴＩ毎であると推定され得る。しかし、トークンが毎秒加えられるだけであるようにこの周期を延ばすことが簡単にできる。基本的に、１ｍｓ毎にバケットにトークンを加える代わりに、１０００トークンが毎秒加えられ得る。以下に、リリース８で使用される論理チャネル優先順位付け手順が記載される（その内容が本明細書に援用される規格ＴＳ３６．３２１を参照）。

【0062】

ＲＲＣは、各論理チャネルに対して、シグナリングによって上りリンクデータのスケジューリングを制御する。
− "priority"：増加している優先度値が、低い優先度レベルを示す。
− "prioritisedBitRate"：優先されるビットレート（ＰＢＲ）をセットする。
− "bucketSizeDuration"：バケットサイズ期間（ＢＳＤ）をセットする。

【0063】

優先されるビット率の後の考えは、潜在的枯渇を避けるために最小限のビットレートを、各々のベアラ（低い優先度の非ＧＢＲベアラを含む）のため、サポートすることである。各ベアラは、優先されるビットレート（ＰＢＲ）を成し遂げるために、十分なリソースを少なくとも得なければならない。

【0064】

ＵＥは、各論理チャネルｊのために可変的なＢｊを維持する。関連した論理チャネルが確立されるとき、Ｂｊはゼロまで初期化されて、ＴＴＩ毎に製品ＰＢＲ×ＴＴＩ期間によってインクリメントされる。ここで、ＰＢＲは、論理チャネルｊの優先されるビットレートである。しかしながら、Ｂｊの値はバケットサイズを決して超えることができない。そして、Ｂｊの値が論理チャネルｊのバケットサイズより大きいならば、それはバケットサイズにセットされる。論理チャネルのバケットサイズはＰＢＲ×ＢＳＤに等しい。ここで、ＰＢＲとＢＳＤは上位レイヤによって構成される。

【0065】

ＵＥは、新たな送信が実行されるときに、以下の論理チャネル優先順位付け手順を実行する。
− ＵＥは、下記のステップの中で、論理チャネルにリソースを割り当てる。
− ステップ１：Ｂｊ＞０の全ての論理チャネルは、減少している優先度の命令の中でリソースが割り当てられる。無線ベアラのＰＢＲが「無限」にセットされているのであれば、ＵＥは、低い優先度の無線ベアラのＰＢＲを満たす前に、無線上で送信可能な全てのデータのためにリソースを割り当てる。
− ステップ２：ＵＥは、ステップ１の中で、論理チャネルｊのために扱われるＭＡＣ ＳＤＵの総サイズによってＢｊを減少させる。
注意：Ｂｊの値は、負であり得る。
− ステップ３：リソースが残れば、全ての論理チャネルは、最初に来るものはどれでも、論理チャネルのためのデータあるいはＵＬグラントが使い果たされるまで、（Ｂｊの値に関係なく）厳しく減少している優先度の命令の中で扱われる。等しい優先度で構成される論理チャネルは、等しく扱われる。
− ＵＥは、上記スケジューリング手順の間、下記のルールにも従う。
− 全てのＳＤＵ（あるいは部分的に送信されたＳＤＵあるいは再送されたＲＬＣ ＳＤＵ）が、残留している資源に適合するならば、ＵＥは、ＲＬＣ ＳＤＵ（あるいは部分的に送信されたＳＤＵあるいは再送されたＲＬＣ ＳＤＵ）を分割しない。
− ＵＥが論理チャネルからＲＬＣ ＳＤＵを分割するならば、ＵＥは、可能な限りグラントを満たすために、分割のサイズを最大にする。
− ＵＥは、データの送信を最大にする。

【0066】

論理チャネル優先順位付け手順のために、ＵＥは、減少している命令の中で、以下の相対的な優先度を考慮する。
− Ｃ−ＲＮＴＩのためのＭＡＣ制御エレメントまたはＵＬ−ＣＣＣＨからのデータ
− パディングのために含まれるＢＳＲを除く、ＢＳＲ（バッファ状態報告）のためのＭＡＣ制御エレメント
− ＰＨＲまたは拡張されたＰＨＲのためのＭＡＣ制御エレメント
− ＵＬ−ＣＣＣＨからのデータを除く、いずれかの論理チャネルからのデータ
− パディングのために含まれるＢＳＲのためのＭＡＣ制御エレメント

【0067】

ＵＥは、例えば、キャリアアグリゲーションあるいはＵＬ空間多重のケースのように、１つのＴＴＩの中に複数のＭＡＣ ＰＤＵを送信することを要求されたとき、ステップ１から３および関連のルールは、独立して各グラントに、あるいは、グラントの容量の合計に適用されるかもしれない。グラントが作動された命令も、ＵＥの実施に任せられる。ＵＥが１つのＴＴＩの中に複数のＭＡＣ ＰＤＵを送信することを要求されたとき、ＭＡＣ制御エレメントが含められたＭＡＣ ＰＤＵを決定することは、ＵＥの実施に任されている。

【0068】

電力制御
移動通信システムの上りリンク送信電力制御は、システムの他のユーザの干渉を最小化し、ユーザ機器のバッテリ寿命を最大化する必要性に対して、要求されるＱｏＳを成し遂げるために十分なビットあたりの送信電力のための必要性とのバランスを取ることを目的として提供される。電力制御（ＰＣ）の役割は、近隣のセルに因る干渉を同時に制御する間に、要求されたＳＩＮＲ（希望波対干渉波および雑音の比）を提供するために重大なものでなる。上りリンクの中の古典的なＰＣのアイデアは、全補償（full compensation）として知られる、全てのユーザからの信号が同一のＳＩＮＲで受信されるということである。これに代えて、ＬＴＥのリリース８／９において、部分電力制御（ＦＰＣ：Fractional Power Control）の使用を採用した。この新しい機能では、経路損失の大きいユーザは、より低いＳＩＮＲ要件で動作し、したがって多くの場合、隣接セルに引き起こされる干渉が小さい。

【0069】

ＬＴＥのリリース８／９の中で提供される電力制御方式は、開ループ制御と閉ループ制御の組み合わせを用いる。オペレーションのモードは、パスロス評価に基づく開ループ手段によって、送信電力密度スペクトルに対する粗い動作点を設定することを必要とする。より速いオペレーションが、閉ループ電力制御によって開ループ動作点のまわりで適用され得る。これは干渉を制御し、速いフェージングを含むチャネル状況に合うために、電力のセッティングを微調整する。

【0070】

このメカニズムの組合せで、ＬＴＥのリリース８／９の中の電力制御方式は、オペレーションの複数のモードをサポートする。それは、配備シナリオ、システム負荷およびオペレータ選択に従う異なる電力制御戦略のためのツールキットとみなすことができる。

【0071】

３ＧＰＰ ＴＳ３６．２１３のセクション５．１の中で、ＬＴＥのリリース８／９においては、物理上りリンクシェアードチャネル（ＰＵＳＣＨ）、物理上りリンク制御チャネル（ＰＵＣＣＨ）、およびサウンディング参照信号（ＳＲＳ）に対して、きめ細かい電力制御式が指定されている（ｈｔｔｐ／／ｗｗｗ．３ｇｐｐ．ｏｒｇから入手可能であり、その内容が本明細書に援用される）。これらの上りリンク信号のそれぞれの式は、同じ基本原理に従う。全てのケースにおいて、電力制御式は、２つの主項、すなわち基地局装置によってシグナリングされる静的パラメータまたは半静的パラメータから導かれる、開ループの基本動作点と、サブフレームごとに更新される動的オフセット（補正）と、の合計と考えることができる。

【0072】

リソースブロックあたりの送信電力のための開ループの基本動作点は、セル間干渉やセル負荷など複数の要因に依存する。開ループの基本動作点は、さらに２つの成分として、半静的な基本レベルＰ_０（これはさらにセル内のすべてのユーザ機器（ＵＥ）の共通電力レベル（測定単位：ｄＢｍ）とユーザ機器に固有なオフセットとからなる）と、開ループの経路損失補償成分とに、分解することができる。リソースブロックあたりの電力の動的オフセットの部分は、さらに２つの成分として、変調・符号化方式（ＭＣＳ）に依存する成分と、明示的な送信電力制御（ＴＰＣ：Transmitter Power Control）コマンドとに、分解することができる。

【0073】

ＭＣＳに依存する成分（ＬＴＥ仕様ではΔ_ＴＦと称し、ＴＦはトランスポートフォーマットの略）は、リソースブロックあたりの送信電力を、送信される情報のデータレートに従って適合させることができる。

【0074】

動的オフセットのもう１つの成分は、ユーザ機器に固有なＴＰＣコマンドである。このコマンドは、以下の２種類のモード、すなわち、累積的ＴＰＣコマンド（ＰＵＳＣＨ、ＰＵＣＣＨ、およびＳＲＳに対して利用できる）、および。絶対的ＴＰＣコマンド（ＰＵＳＣＨのみに対して利用できる）で動作することができる。ＰＵＳＣＨに対して、これら２つのモードの間の切替えは、ユーザ機器ごとにＲＲＣシグナリングによって半静的に設定される（すなわち、モードを動的に変更することはできない）。累積的ＴＰＣコマンドの場合、各ＴＰＣコマンドは、前のレベルを基準としたときの電力ステップをシグナリングする。

【0075】

関連するサブフレームｉのＰＵＳＣＨ送信のためのＵＥ送信電力Ｐ_{ＰＤＳＣＨ}［ｄＢｍ］のセッティングは、その内容が本明細書に援用される３ＧＰＰ ＴＳ３６．２１３のセクション５．１．１．１から明確に定義される。

【0076】

パワーヘッドルーム報告
ｅＮｏｄｅＢが上りリンク送信リソースを適当な形で異なるユーザ機器にスケジューリングするのを援助するためには、ユーザ機器がその使用可能なパワーヘッドルームをｅＮｏｄｅＢに報告できることが重要である。ｅＮｏｄｅＢは、ユーザ機器がサブフレームあたりどれほどの上りリンク帯域幅を使用できるのかを判定するのに、パワーヘッドルーム報告を使用することができる。これは、リソースの浪費を避けるために上りリンク送信リソースを使用できないユーザ機器に、そのリソースを割り当てるのを避けるのを助ける。

【0077】

パワーヘッドルーム報告の範囲は、＋４０ｄＢから−２３ｄＢまでである（ｈｔｔｐ／／ｗｗｗ．３ｇｐｐ．ｏｒｇから入手可能であり、その内容が本明細書に援用される３ＧＰＰ ＴＳ ３６．１３３を参照されたい）。この範囲の負の部分は、ユーザ機器が、そのユーザ機器（ＵＥ）が使用可能であるものより多くの送信電力を要求するＵＬ許可を受信した範囲をｅＮｏｄｅＢにシグナリングすることを可能にする。これは、ｅＮｏｄｅＢが、後続許可のサイズを減らし、送信リソースを解放して他のＵＥにその送信リソースを割り当てることを可能にする。

【0078】

パワーヘッドルーム報告を、ＵＥがＵＬ送信許可を有するサブフレーム内でのみ送信することができる。この報告は、それが送信されるサブフレームに関連する。したがって、ヘッドルーム報告は、直接測定値ではなく予測であり、ＵＥは、報告が送信されるサブフレームの実際の送信パワーヘッドルームを直接に測定することができない。したがって、ＵＥは、ＵＥの電力増幅器出力の穏当に正確な校正に頼る。

【0079】

パワーヘッドルーム報告をトリガする複数の判断基準が定義されている。これらは、次を含む。
−最後のパワーヘッドルーム報告以降の推定経路損の大きい変化。
−以前のパワーヘッドルーム報告以降に、構成された時間を超える時間が経過した。
−構成された個数を超える個数の閉ループＴＰＣコマンドがＵＥによって実施された。

【0080】

ｅＮｏｄｅＢは、システム負荷およびそのスケジューリング・アルゴリズムの要件に応じて、これらのトリガのそれぞれを制御するためにパラメータを構成することができる。より具体的には、ＲＲＣは、２つのタイマｐｅｒｉｏｄｉｃＰＨＲ−ＴｉｍｅｒおよびｐｒｏｈｉｂｉｔＰＨＲ−Ｔｉｍｅｒを構成することと、パワーヘッドルーム報告をトリガするための測定された下りリンク経路損の変化をセットするｄｌ−ＰａｔｈｌｏｓｓＣｈａｎｇｅをシグナリングすることとによって、パワーヘッドルーム報告を制御する。

【0081】

パワーヘッドルーム報告は、ＭＡＣ制御要素として送信される。パワーヘッドルーム報告は、最上位２ビットが予約済みであり、最下位６ビットが１ｄＢステップで上述の６４ｄＢ値を表す、単一のオクテットからなる。このＭＡＣ制御要素の構造を、図７に示す。

【0082】

Ｒ領域は、予約されたビットで有り、「０」にセットされる。パワーヘッドルーム（ＰＨ）領域は、パワーヘッドルームレベルを示す。その領域の長さは６ビットである。報告されたヘッドルームおよび対応するパワーヘッドルームレベルは、規格ＴＳ３６．３２１のテーブル６．１．３．６−１に示されている。

【0083】

サブフレームｉについて有効なＵＥパワーヘッドルームＰＨ［ｄＢ］は、以下の式１によって定義される（３ＧＰＰ ＴＳ ３６．２１３のセクション５．１．１．２を参照されたい）。
ＰＨ（ｉ）＝Ｐ_ＣＭＡＸ−｛１０・ｌｏｇ_１０（Ｍ_{ＰＵＳＣＨ}（ｉ））＋Ｐ_{Ｏ＿ＰＵＳＣＨ}（ｊ）＋α（ｊ）・ＰＬ＋Δ_ＴＦ（ｉ）＋ｆ（ｉ）｝ 式１

【0084】

パワーヘッドルームは、１ｄＢのステップで範囲［４０；−２３］ｄＢ内の最も近い値に丸められる。Ｐ_ＣＭＡＸは、総最大ＵＥ送信電力（またはユーザ機器の総最大送信電力）であり、次の制約に基づいてＰ_{ＣＭＡＸ＿Ｌ}およびＰ_{ＣＭＡＸ＿Ｈ}の所与の範囲内でユーザ機器によって選択される値である。

【0085】

−Ｐ_{ＣＭＡＸ＿Ｌ}≦Ｐ_ＣＭＡＸ≦Ｐ_{ＣＭＡＸ＿Ｈ}
−Ｐ_{ＣＭＡＸ＿Ｌ}＝ｍｉｎ（Ｐ_ＥＭＡＸ−ΔＴ_Ｃ，Ｐ_{ＰｏｗｅｒＣｌａｓｓ}−ＭＰＲ−ＡＭＰＲ−ΔＴ_Ｃ）
−Ｐ_{ＣＭＡＸ＿Ｈ}＝ｍｉｎ（Ｐ_ＥＭＡＸ，Ｐ_{ＰｏｗｅｒＣｌａｓｓ}）

【0086】

Ｐ_ＥＭＡＸは、ネットワークによってシグナリングされる値であり、ΔＴ_Ｃ、ＭＰＲ、およびＡＭＰＲ（Ａ−ＭＰＲ（追加最大電力削減）とも表される）は、ｈｔｔｐ／／ｗｗｗ．３ｇｐｐ．ｏｒｇから入手可能であり、その内容が本明細書に援用される３ＧＰＰ ＴＳ ３６．１０１の中で明示されている。

【0087】

ＭＰＲは、さまざまな変調方式および送信帯域幅に関連する隣接チャネル漏洩電力比（ＡＣＬＲ）を制御するのに使用される電力削減値である。

【0088】

Ａ−ＭＰＲは、追加最大電力削減である。ＡＭＰＲは、帯域固有であり、ネットワークによって構成される時に適用される。したがって、Ｐ_ＣＭＡＸは、ＵＥ実施態様固有であり、したがって、ｅＮＢには未知である。

【0089】

キャリアアグリゲーションに関する上りリンク電力制御
ＬＴＥ−ＡｄｖａｎｃｅｄにおけるＵＬ電力制御の１つの主なポイントは、コンポーネントキャリア固有上りリンク電力制御がサポートされていること、すなわち、ユーザ機器のために構成された上りリンクコンポーネントキャリアごとに１つの独立の電力制御ループがあることである。さらに、パワーヘッドルームがコンポーネントキャリアごとに報告される。

【0090】

さらに、ＬＴＥのリリース１０では、キャリアアグリゲーションのスコープ内に、２つの最大電力制限、すなわち、総最大ＵＥ送信電力Ｐ_{ＣＮＭＡＸ}およびコンポーネントキャリア固有最大送信電力Ｐ_{ＣＭＡＣ，ｃ}がある。３ＧＰＰ ＲＡＮ４ワーキング・グループは、単一キャリア動作モードのキャリアアグリゲーション対応ユーザ機器のリンク・バジェットに影響しないようにするために、ユーザ機器あたりの（公称）最大送信電力Ｐ_{ＣＮＭＡＸ}と（公称）最大コンポーネントキャリア固有送信電力Ｐ_{ＣＭＡＣ，ｃ}との両方が、サポートされるキャリアの個数にかかわりなく同一でなければならないことを既に示した。ＲＡＮ１は、コンポーネントキャリアごとに報告されるパワー・ヘッドルーム報告が、最大電力削減（ＭＰＲ）を考慮に入れることに合意した。言い替えると、ユーザ機器によって適用される電力削減は、コンポーネントキャリア固有最大送信電力Ｐ_{ｃｍａｘ，ｃ}で考慮される。ここで、ｃはコンポーネントキャリアを表す。

【0091】

さらに、ＬＴＥのリリース８／９とは異なって、ＬＴＥ−Ａのリリース１０では、ユーザ機器は、同時ＰＵＳＣＨ−ＰＵＣＣＨ送信、マルチクラスタ・スケジューリング、および複数コンポーネントキャリア上の同時送信にも対処しなければならず、これは、３ＧＰＰのリリース８／９と比較して、より大きいＭＰＲ値を必要とし、適用されるＭＰＲ値のより大きい変動をも引き起こす。

【0092】

実際の電力削減が、割当のタイプ、標準化されたＭＰＲ値、およびユーザ機器実施態様にも依存するので、ｅＮｏｄｅＢは、各コンポーネントキャリアに対してユーザ機器によって適用される電力削減を知らないことに留意されたい。したがって、ｅＮｏｄｅＢは、ユーザ機器がそれに関してパワーヘッドルームを計算するコンポーネントキャリア固有最大送信電力を知らない。たとえば、ＬＴＥのリリース８／９では、ユーザ機器最大送信電力Ｐ_{ＣＮＭＡＸ}は、上で説明したようにある範囲内にあるものとすることができる。
Ｐ_{ＣＭＡＸ＿Ｌ}≦Ｐ_ＣＭＡＸ≦Ｐ_{ＣＭＡＸ＿Ｈ}

【0093】

上で説明したｅＮｏｄｅＢには未知のコンポーネントキャリア固有最大送信電力Ｐ_{ＣＭＡＣ，ｃ}の削減に起因して、ｅＮｏｄｅＢは、実際に、ユーザ機器がその総最大送信電力Ｐ_{ＣＮＭＡＸ}のどれほど近くで動作しているのかを知り得ない。したがって、ユーザ機器が、総ユーザ機器最大送信電力Ｐ_{ＣＮＭＡＸ}を超えている（したがって、電力スケーリングを必要とする）状況がある可能性がある。図８に、ユーザ機器が電力制限される、すなわち、上りリンクで構成されたコンポーネントキャリアＣＣ＃１およびＣＣ＃２上で電力スケーリングを適用している、例示的なシナリオを示す。ユーザ機器は電力制限されるが、リリース８／９のＬＴＥ定義によるコンポーネントキャリア固有パワーヘッドルーム報告は、十分に大きいパワーヘッドルームを示す。

【0094】

コンポーネントキャリアの最大送信電力のために、ユーザ機器によって適用される電力削減がｅＮｏｄｅＢには知らされないという事実に起因して、リリース１０において、拡張されたパワーヘッドルームＭＡＣ制御エレメントとも呼ばれる、新たなパワーヘッドルームＭＡＣ制御エレメントを導入することが合意された。リリース８／９のＰＨＲ ＭＡＣ ＣＥフォーマットとの主な違いは、それが、各アクティブ化された上りリンクコンポーネントキャリアに対してリリース８／９のパワーヘッドルーム値を含み、それゆえに可変的なサイズである、ということである。

【0095】

さらに、それは、コンポーネントキャリアに対してパワーヘッドルーム値のみならず、対応するＰ_{ＣＭＡＣ，ｃ}（インデックスｃのコンポーネントキャリアの最大送信電力）値をも報告する。同時ＰＵＳＣＨ−ＰＵＣＣＨ送信を説明するために、ユーザ機器は、ＰＣｅｌｌのために、（タイプ１パワーヘッドルームとも呼ばれる）ＰＵＳＣＨのみの送信に関するリリース８／９のパワーヘッドルーム値を報告し、そして、ＵＥが同時ＰＵＳＣＨ−ＰＵＣＣＨ送信のために構成されるならば、タイプ２パワーヘッドルームとしても関連する、ＰＵＳＣＨおよびＰＵＳＣＨの送信を考慮する、更なるパワーヘッドルーム値を報告する。図９は、タイプ２パワーヘッドルーム情報を含む、拡張されたパワーヘッドルームＭＡＣ制御エレメントを示している。

【0096】

拡張されたパワーヘッドルームＭＡＣ制御エレメントの中のフィールドは、以下のように定義される。
− Ｃｉ：このフィールドは、セルインデックスｉのＳＣｅｌｌのアクティブ化／非アクティブ化の状態を示す。”１”にセットされたＣｉフィールドは、インデックスｉのＳＣｅｌｌに対するＰＨフィールドが報告されていることを示す。”０”にセットされたＣｉフィールドは、インデックスｉのＳＣｅｌｌに対するＰＨフィールドが報告されていないことを示す。
− Ｒ：受信されたビット、”０”にセットされる。
− Ｖ：このフィールドは、ＰＨ値が実際の送信に基づくか、あるいは、参照フォーマットに基づくかを示す。タイプ１のＰＨにおいて、Ｖ＝０はＰＵＳＣＨ上の実際の送信を示し、Ｖ＝１はＰＵＳＣＨの参照フォーマットが使用されたことを示す。タイプ２のＰＨにおいて、Ｖ＝０はＰＵＣＣＨ上の実際の送信を示し、Ｖ＝１はＰＵＣＣＨの参照フォーマットが使用されたことを示す。
− パワーヘッドルーム（ＰＨ）：このフィールドは、パワーヘッドルームのレベルを示す。このフィールドの長さは、６ビットである。報告されたＰＨおよび対応するパワーヘッドルームのレベルは、規格36.321のテーブル6.1.3.6-1に示されている。（ＦＦＳ：対応するＶが１であれば、ＰＣＭＡＸ，ｃを含むオクテットは省略される。）
− ＰＣＭＡＸ，ｃ：このフィールドは、前述のＰＨフィールドの計算のために使用されるＰＣＭＡＸ，ｃを含む。

【0097】

パワーヘッドルーム報告がトリガされたとき、ＵＥは、可能な上りリンクＰＣｅｌｌあるいはＳＣｅｌｌの１つで、上りリンクリソースの中で、拡張されたパワーヘッドルームＭＡＣ制御エレメントを送信する。そのコンポーネントキャリア上で送信されるｅＰＨＲは、受信された上りリンクグラントおよびパワーヘッドルームを報告するためのトリガに依存する。

【0098】

拡張されたパワーヘッドルームＭＡＣ制御エレメントのさらなる詳細は、その内容が本明細書に援用される規格ＴＳ３６．３２１のセクション６．１．３の中に載っている。

【0099】

従来技術の課題
上記で説明したように、リリース１０に従う、拡張されたパワーヘッドルームＭＡＣ制御エレメントは、リリース８／９のものと異なる。図７乃至９から明らかなように、１つの違いは、拡張されたパワーヘッドルームＭＡＣ制御エレメントのサイズが可変であり、例えば、アクティブ化されたコンポーネントキャリアの数に依存し、ユーザ機器が同時ＰＵＳＣＨ−ＰＵＣＣＨ送信のために構成されているか（すなわち、パワーヘッドルームＭＡＣ ＣＥがＰＣｅｌｌのためのタイプ２のパワーヘッドルームを含んでいるか）否かに依存する。加えて、（図９に示す）拡張されたパワーヘッドルームＭＡＣ制御エレメントのサイズは、（図７に示す）通常のパワーヘッドルームＭＡＣ制御エレメントのものよりも著しく大きい。

【0100】

リリース８／９によって定義された通常のパワーヘッドルームＭＡＣ制御エレメントは、１バイトのみである。ユーザ機器が、同時ＰＵＳＣＨ−ＰＵＣＣＨ送信のために構成され、２つのアクティブ化された上りリンクコンポーネントキャリアを持っている、と仮定すると、ｅＰＨＲ ＭＡＣ制御エレメントのサイズは７バイトになる。

【0101】

半永続スケジューリングは、主に、ボイスオーバＩＰアプリケーションのために設計された。それは、パケットが、小さく、同一のサイズを持ち、周期的に到着する、という特定の特徴を持つ。したがって、半永続スケジューリングに対して割り振られるリソース割り当ては、一般的に小さい。リリース８／９では、トランスポートブロック（ＴＢ）サイズテーブルは、最も突出した音声コーデックのために最適化される。すなわち、ＴＢサイズテーブルの確実なエントリは、効果的な半永続スケジューリングのサポートのために定義される。

【0102】

以下のテーブル４は、狭帯域（ＮＢ）と広帯域（ＷＢ）とで異なる音声コーデックのために最適化される、すなわち異なる適応可能なマルチレート（ＡＭＲ）に依存するトランスポートブロックサイズを示している。

【表4】

【0103】

例えば、狭帯域で１２．２ｋｂｐｓで符号化された音声データは、３２０ビットのトランスポートブロックサイズで送信される。ここで、その３２０ビットは、短いバッファ状態報告あるいはパワーヘッドルーム報告のための１６ビットを含む。したがって、音声データは、（プロトコルヘッダを含む）３０４ビットのＶｏＩＰパケットを持っている。２つのＭＡＣ制御エレメント（短いＢＳＲおよびＰＨＲ）の両方は、対応するＭＡＣサブヘッダのために１オクテットプラス１バイトのサイズを持っている。特に、これらのトランスポートブロックサイズは、ＡＭＲのための帯域幅の効率的なペイロードフォーマットを使用するＲＴＰペイロードとして、対応するスピーチフレームビットの数に基づいて選択される。加えて、その３２０ビットは、ＲＯＨＣ（Robust Header Compression）ヘッダの３オクテット、ＭＡＣ／ＲＬＣ／ＰＤＣＰヘッダのための３オクテット、および、ＲＯＣＨヘッダサイズおよび／またはＬ２ヘッダサイズ（例えば、短いＢＳＲおよびＰＨＲ）の中の小さいバリエーションを扱うための追加の２オクテットを含む。したがって、６４ビットが、オーバヘッドのために使用される。残る２５６ビットが、ＶｏＩＰペイロードである。同じことが、３２８ビットのトランスポートブロックサイズに適用される。そこでは、２６４ビットがＶｏＩＰペイロード（ＲＴＰペイロード）であり、６４ビットがプロトコルおよび制御シグナリングオーバヘッドである。

【0104】

以下のテーブル５は、リリース８／９に従って、リソースブロックサイズＮ_ＰＲＢとトランスポートブロックサイズインデックスＩ_ＴＢＳ（１−２６）に依存してトランスポートブロックサイズを決めるために使用されるトランスポートブロックサイズテーブルである。トランスポートブロックサイズインデックスＩ_ＴＢＳは、テーブル１、２から参照され得るＭＣＳインデックスによって指示される。

【表5】

【0105】

上記テーブル５は、本発明の議論に関連するリソースブロックサイズ、すなわちリソースブロックサイズ１−１０についてのみ示されている。テーブル５から明らかなように、リソースブロック割り当ての大きな数に対してサポートされた明確なトランスポートブロックサイズがある。例えば、３２８ビット（太字および下線）は、リソースブロックサイズ１−６、８−９に対して割り当てられ得る。同様に、トランスポートブロックサイズ１７６、２０８、２２４および２５６も、いくつかのリソースブロックサイズに対して、テーブル５の中で示されている。明らかなように、これらのトランスポートブロックサイズは、例えば、テーブル４に従った適応可能なマルチレートのような、典型的な音声コーデックに対して最適化されるものに一致する。

【0106】

例えば、３２８ビットのトランスポートブロックサイズは、１２．２ｋｂｐｓＮＢ−ＡＭＲコーデックあるいは１２．６５ｋｂｐｓＷＢ−ＡＭＲコーデックのＶｏＩＰパケット、および、ＰＨＲ ＭＡＣ制御エレメントあるいは代わりの短いＢＳＲ ＭＡＣ制御エレメント（２５６ビットＶｏＩＰデータ＋６４ビットヘッダ等＋８ビットパッディング；２６４ビットＶｏＩＰデータ＋６４ビットヘッダ等）の送信のために用いられる。

【0107】

ＰＨＲあるいはｅＰＨＲのためのＭＡＣ制御エレメントは、論理チャネル優先順位手順の中で、（ＵＬ−ＣＣＨを除く）論理チャネルのデータよりも高い優先度を持つことに留意すべきである。換言すれば、ｅＰＨＲ／ＰＨＲのためのＭＡＣ制御エレメントは、上りリンクトランスポートブロックの中に最初に含まれる。残りのビットは、例えばＶｏＩＰデータのような論理チャネルに割り当てられる。

【0108】

上記の内容は、ＬＴＥのリリース１０に従う拡張されたパワーヘッドルーム報告に対して著しく変化する。基本的に、リリース８／９に対して最適化されたトランスポートブロックサイズテーブルは、もはや、リリース１０に対して最適化されたものではない。なぜならば、拡張されたパワーヘッドルーム報告のサイズは、可変なものだからである。例えば、３２８ビットは、８ビット以上を持つ（ｅＰＨＲ ＭＡＣ ＣＥの最小値は２４ビット）拡張されたパワーヘッドルーム報告のために、ＶｏＩＰパケット（１２．２ｋｂｐｓあるいは１２．６５ｋｂｐｓ）および拡張されたパワーヘッドルーム報告の送信に対して用いられない。したがって、ｅＰＨＲ ＭＡＣ ＣＥおよびＭＡＣサブヘッダは少なくとも３２ビットを持つ。

【0109】

半永続スケジューリングのためのトランスポートブロックサイズは、特定の時間に対して固定される。例えば、３２８ビットのトランスポートブロックサイズは、使用されるためにセットされる。したがって、ユーザ機器がＶｏＩＰ上りリンクデータのための半永続上りリンクリソースを割り当てられているＴＴＩ（例えばサブフレーム）の中でｅＰＨＲ ＭＡＣ制御エレメントを送信する必要があるケースにおいて、ＵＥは、そのサブフレームに対して上りリンクの中で例えば３２８ビットのみを送信することができる。論理チャネル優先順位によってトランスポートブロックは、最初に、例えば７バイト長であるｅＰＨＲ ＭＡＣ制御エレメントで”満たされる”。制御情報（ＲＯＨＣ／ＭＡＣ／ＲＬＣ／ＰＤＣＰヘッダ）の６４ビットを考慮すると、３２８ビットのトランスポートブロックの残りの２０８ビットが、ＶｏＩＰデータのために使用され得る。しかしながら、ＶｏＩＰデータは、例えば（１２．２ｋｂｐｓあるいは１２．６５ｋｂｐｓに対して）２５６あるいは２６４ビット長である。

【0110】

従って、ＶｏＩＰデータは、同一のグラントで送信され得ない。ＭＡＣレイヤは、ＭＡＣ ＰＤＵの残りのビット（すなわちトランスポートブロック）の中で送信される適切なサイズを持つＲＬＣ ＰＤＵを生成するために、ＰＬＣ ＳＤＵのＲＬＣ分割（図５参照）を実行するＲＬＣレイヤに、これをシグナリングする。

【0111】

ＲＬＣ分割は、ＰＤＣＣＨと同様に、すなわち、ＲＬＣ ＳＤＵの残りの送信のために、データパケット送信の遅延を増加させるから、一般には回避されるべきである。ＶｏＩＰサービスに対して厳しい遅延の要求があるから、ＶｏＩＰパケットのＲＬＣ分割は不利である。

【0112】

ＲＬＣ分割は、上記のトランスポートブロックサイズテーブル５から、より大きいトランスポートブロックサイズ（例えば、３２８ビットの代わりに３９２ビット）を使用することによって回避される。しかしながら、これにより、ＶｏＩＰの容量は著しく減少させられる。すなわち、システムは、リリース８／９のケースのために、以前よりも少ないＶｏＩＰユーザ数しかサポートできない。また、拡張されたパワーヘッドルーム報告がトリガされず、そのためにＶｏＩＰパケットのみが永続的に割り当てられた上りリンクリソース上で送信されるサブフレームの中で、パディングが、より大きいトランスポートブロックサイズ（例えば、３２８ビットの代わりの３９２ビット）を満たすために使用される。ＶｏＩＰアプリケーションに対してより大きいトランスポートブロックサイズ（例えば、３９２ビット）を割り当てることのもう１つの不利な点は、トランスポートブロックサイズテーブルの中に３９２ビットより少ないエントリがあるから、再送のためのスケジューリングの柔軟性を減少させることである。

【0113】

拡張されたパワーヘッドルーム報告は可変であるから、拡張されたパワーヘッドルーム報告を考慮するリリース１０のための新たなトランスポートブロックサイズテーブルを定義することは困難である。従って、トランスポートブロックサイズテーブルは、全ての可能なｅＰＨＲ ＭＡＣ制御エレメントサイズに対して最適化されるわけではない。さらに、リリース１０のＵＥは、基本の（リリース８／９のＰＨＲ ＭＡＣ制御エレメント）パワーヘッドルーム報告および拡張されたパワーヘッドルーム報告をサポートするために、複数のトランスポートブロックサイズテーブルをサポートする必要がある。これは、複雑さを増加させる。

【発明の概要】

【0114】

本発明の１つの目的は、特に、パワーヘッドルーム情報を送信するために永続的に割り当てられる上りリンクリソースを使用するときの、ユーザ機器から基地局装置にパワーヘッドルーム報告を送信するための改善された方法を提案することである。

【0115】

この目的は、独立請求項の主題によって解決される。本発明の有利な実施形態は、従属請求項の主題である。

【0116】

本発明の第１の態様によると、パワーヘッドルーム報告は、そのパワーヘッドルームが送信される上りリンクリソースがどのようにスケジューリングされているかに依存する。換言すれば、本発明の第１の態様に従うパワーヘッドルーム報告は、スケジューリングモードに依存する。パワーヘッドルーム情報の種類は、ユーザ機器に、特にユーザ機器が拡張されたパワーヘッドルーム報告をサポートしているか単に基本のパワーヘッドルーム報告のみをサポートしているかに依存する基地局に送信される。

【0117】

基本のパワーヘッドルーム報告は、拡張されたパワーヘッドルーム報告よりもかなり少ない情報しか提供しない。基本のパワーヘッドルーム報告は、１つのコンポーネントキャリアについて、可能な送信電力の情報を提供する。一方、拡張されたパワーヘッドルーム報告は、各アクティブ化された上りリンクコンポーネントキャリアについて、可能な送信電力、および、対応する最大送信電力についての情報を提供する。

【0118】

ユーザ機器は、拡張されたパワーヘッドルーム情報の送信をサポートし、さらにユーザ機器は、拡張されたパワーヘッドルーム情報を送信するために基地局によって構成されもすると推定される。本発明の第１の態様に従って、拡張されたパワーヘッドルーム報告を送信するための構成は、半永続スケジューリングされる上りリンクリソースに対して効果的ではない。換言すれば、パワーヘッドルーム情報が永続的に割り当てられた上りリンクリソースを使用して送信されるとき、拡張されたパワーヘッドルーム報告ではなく、基本の（通常の）パワーヘッドルーム報告が送信される。

【0119】

より詳細には、ユーザ機器が、（例えば、最後のパワーヘッドルーム報告から推定された経路損失の重要な変化のために）パワーヘッドルーム情報を送るためにトリガされるときはいつでも、ユーザ機器は、次の上りリンクリソースに対してパワーヘッドルーム情報を送信する。本発明の第１の態様によると、ユーザ機器は、上りリンクリソースがユーザ機器にどのように割り当てられたかについて最初に決定する。どのように上りリンクリソースが割り当てられるかについて、基本的に、動的なものと永続的なものの２つの異なる可能性がある。

【0120】

上りリンクリソースが動的にスケジューリングされるとき、ユーザ機器は、前記動的に割り当てられた上りリンクリソースを使用して構成されたものとして、基地局に拡張されたパワーヘッドルーム報告を送信することができる。

【0121】

上りリンクリソースが（例えば半永続スケジューリング構成の中のものとして）永続スケジューリングされるとき、ユーザ機器は、前記永続的に割り当てられた上りリンクリソースを使用して、基地局に基本のパワーヘッドルーム報告を送信するであろう。実際には拡張されたパワーヘッドルーム情報を送信するように構成されているにもかかわらず、これは、ユーザ機器によってなされる。

【0122】

永続的に割り当てられた上りリンクリソースの中で基本のパワーヘッドルーム報告を送信し、動的に割り当てられた上りリンクリソースの中で拡張されたパワーヘッドルーム報告を送信することによって、データ遅延が起こることがない。特に、トランスポートブロックは、（音声）データと基本のパワーヘッドルーム報告を含めることが可能となる。そして、そのため、（音声）データは分割される必要がなく、遅延されない。

【0123】

本発明の第２の態様によると、永続スケジューリングされる上りリンクリソースに対して、拡張されたパワーヘッドルーム情報において、上りリンクデータが優先される。特に、ユーザ機器は、拡張されたパワーヘッドルーム情報を送信するために構成され、永続スケジューリングされている上りリンクリソースを使用して拡張されたパワーヘッドルーム情報を送信するようにトリガされると再び推定される。拡張されたパワーヘッドルーム情報のために（音声）上りリンクデータが遅延しないことを確認するために、パワーヘッドルーム情報において、上りリンクデータが優先される。

【0124】

背景技術の中で説明したように、論理チャネルの優先順位付け手順のために、永続スケジューリングされた上りリンクのトランスポートブロックは、最初に、拡張されたパワーヘッドルーム情報とそのときの上りリンクデータで満たされる。拡張されたパワーヘッドルーム情報は大きいから、上りリンクデータは分割され、そのトランスポートブロックの中で完全に送信され得ない。結果として生じる遅延、さらに分割されたデータパケットの残りの部分をスケジューリングするための追加のＰＤＣＣＨオーバヘッドを避けるために、本発明の第２の態様は、永続スケジューリングされる上りリンクリソース割り当てに対して、拡張されたパワーヘッドルーム情報において、上りリンクデータを優先させる論理チャネルの優先順位付け手順の中で、追加の優先付けルールを定めることを示す。あるいは、音声データは時間に厳しく遅延を避けなければならないから、論理チャネルの優先順位付け手順に対する追加の優先付けルールは、拡張されたパワーヘッドルーム情報において、音声上りリンクデータのみを優先させる。

【0125】

あるいは、拡張されたパワーヘッドルーム報告における上りリンクデータの優先付は、論理チャネルの優先順位付け手順の中ではなく、違う形で実行される。すなわち、それは、トランスポートブロックのサイズが、拡張されたパワーヘッドルーム報告および上りリンクデータを含むのに十分な大きさであるのか否かによって決定される。トランスポートブロックのサイズが十分な大きさではないケースでは、拡張されたパワーヘッドルーム報告は、トランスポートブロックに含まれず、上りリンクデータのみが含まれる。

【0126】

本発明は、上りリンクリソースの中で、ユーザ機器から基地局へのパワーヘッドルーム情報を送信するための方法を提供する。パワーヘッドルーム情報は、基本のパワーヘッドルーム報告か拡張されたパワーヘッドルーム報告のいずれかである。ユーザ機器は、拡張されたパワーヘッドルーム報告とともにパワーヘッドルーム情報を報告するために構成される。上りリンクリソースが永続スケジューリング構成を介してスケジューリングされるケースでは、基本のパワーヘッドルーム報告が、上りリンクリソースの中で、パワーヘッドルーム情報として基地局に送信される。上りリンクリソースが動的スケジューリングを介してスケジューリングされるケースでは、拡張されたパワーヘッドルーム報告が、上りリンクリソースの中で、パワーヘッドルーム情報として基地局に送信される。

【0127】

上記に加えて、または、代わりに使われ得る本発明の有利な実施形態においては、パワーヘッドルーム情報を送信するための上りリンクリソースが、永続スケジューリング構成を介してスケジューリングされるか、あるいは、動的スケジューリングを介してスケジューリングされるかどうかを判断する。

【0128】

上記に加えて、または、代わりに使われ得る本発明の有利な実施形態においては、基本のパワーヘッドルーム報告は、１つのコンポーネントキャリアに対して、可能な送信電力の情報を提供する。さらに、拡張されたパワーヘッドルーム報告は、各アクティブ化された上りリンクのコンポーネントキャリアに対して、可能な送信電力および対応する最大送信電力の情報を提供する。

【0129】

上記に加えて、または、代わりに使われ得る本発明の有利な実施形態においては、基本のパワーヘッドルーム報告は、１つのコンポーネントキャリアに対して、パワーヘッドルームレベルの情報を具備する。さらに、拡張されたパワーヘッドルーム報告は、各アクティブ化された上りリンクのコンポーネントキャリアに対して、パワーヘッドルームレベルの情報を具備し、各アクティブ化された上りリンクのコンポーネントキャリアに対して、コンポーネントキャリア特有の最大送信電力の情報を具備し、上りリンクシェアードチャネル送信および上りリンク制御チャネル送信が同時に実行されれば、上りリンクシェアードチャネル送信および上りリンク制御チャネル送信のパワーヘッドルームレベルを具備する。

【0130】

上記に加えて、または、代わりに使われ得る本発明の有利な実施形態においては、基本のパワーヘッドルーム報告が上りリンクリソースの中で送信されるケースでは、拡張されたパワーヘッドルーム報告の送信は、ユーザ機器の中でトリガされる。そのトリガされた拡張されたパワーヘッドルーム報告は、次の可能な上りリンクリソースの中でユーザ機器から基地局に送信される。

【0131】

上記に加えて、または、代わりに使われ得る本発明の有利な実施形態においては、基本のパワーヘッドルーム報告が上りリンクリソースの中で送信されるケースでは、拡張されたパワーヘッドルーム報告の送信は、ユーザ機器の中でトリガされる。そのトリガされた拡張されたパワーヘッドルーム報告は、動的スケジューリングを介してスケジューリングされた次の可能な上りリンクリソースの中でユーザ機器から基地局に送信される。

【0132】

上記に加えて、または、代わりに使われ得る本発明の有利な実施形態においては、禁止タイマは、最初のパワーヘッドルーム情報を送信した後に特定の時間に対して第２のパワーヘッドルーム情報の送信を禁止するために使用される。禁止タイマは、トリガされた拡張されたパワーヘッドルーム報告に対して無視される。

【0133】

上記に加えて、または、代わりに使われ得る本発明の有利な実施形態においては、禁止タイマは、トリガされた拡張されたパワーヘッドルーム報告を送信した後に再スタートしない。

【0134】

本発明は、さらに、ユーザ機器から基地局への拡張されたパワーヘッドルーム報告を送信するための方法を提供する。拡張されたパワーヘッドルーム報告および上りリンクデータは、上りリンクリソースの中で送信される。上りリンクリソースが永続スケジューリング構成を介してスケジューリングされるケースでは、トランスポートブロックが生成されるときに、全ての上りリンクデータがトランスポートブロックの中に含まれるように、上りリンクデータが、拡張されたパワーヘッドルーム報告よりも優先される。

【0135】

上記に加えて、または、代わりに使われ得る本発明の有利な実施形態においては、上りリンクデータは、ボイスオーバＩＰデータであり、優先付けは、拡張されたパワーヘッドルーム報告よりもボイスオーバＩＰ上りリンクデータを優先する。

【0136】

上記に加えて、または、代わりに使われ得る本発明の有利な実施形態においては、優先付けは、論理チャネルの優先順位付け手順の間、論理チャネルを優先し、上りリンクデータは、特定の論理チャネルを使用して送信されることによって優先される。

【0137】

上記に加えて、または、代わりに使われ得る本発明の有利な実施形態においては、トランスポートブロックのサイズが拡張されたパワーヘッドルーム報告および上りリンクデータを含むのに十分な大きさであるか否かを判断する。トランスポートブロックのサイズが十分な大きさではないケースでは、拡張されたパワーヘッドルーム報告は、そのトランスポートブロックの中には含まれない。

【0138】

上記に加えて、または、代わりに使われ得る本発明の有利な実施形態においては、もう１つの拡張されたパワーヘッドルーム報告は、次の可能な上りリンクリソースの中で送信される。

【0139】

本発明は、上りリンクリソースの中で基地局にパワーヘッドルーム情報を送信するためのユーザ機器を提供する。パワーヘッドルーム情報は、基本のパワーヘッドルーム報告か拡張されたパワーヘッドルーム報告のいずれかである。ユーザ機器は、拡張されたパワーヘッドルーム報告とともにパワーヘッドルーム情報を報告するために構成される。上りリンクリソースが永続スケジューリング構成を介してスケジューリングされるケースでは、ユーザ機器の送信機が、上りリンクリソースの中で、パワーヘッドルーム情報として基本のパワーヘッドルーム報告を基地局に送信する。上りリンクリソースが動的スケジューリングを介してスケジューリングされるケースでは、ユーザ機器の送信機が、上りリンクリソースの中で、パワーヘッドルーム情報として拡張されたパワーヘッドルーム報告を基地局に送信する。

【0140】

上記に加えて、または、代わりに使われ得る本発明の有利な実施形態においては、ユーザ機器のプロセッサは、パワーヘッドルーム情報を送信するための上りリンクリソースが、永続スケジューリング構成を介してスケジューリングされるか、あるいは、動的スケジューリングを介してスケジューリングされるかどうかを判断する。

【0141】

上記に加えて、または、代わりに使われ得る本発明の有利な実施形態においては、基本のパワーヘッドルーム報告は、１つのコンポーネントキャリアに対して、可能な送信電力の情報を提供する。さらに、拡張されたパワーヘッドルーム報告は、各アクティブ化された上りリンクのコンポーネントキャリアに対して、可能な送信電力および対応する最大送信電力の情報を提供する。より詳細には、基本のパワーヘッドルーム報告は、１つのコンポーネントキャリアに対して、パワーヘッドルームレベルの情報を具備する。さらに、拡張されたパワーヘッドルーム報告は、各アクティブ化された上りリンクのコンポーネントキャリアに対して、パワーヘッドルームレベルの情報を具備し、各アクティブ化された上りリンクのコンポーネントキャリアに対して、コンポーネントキャリア特有の最大送信電力の情報を具備し、上りリンクシェアードチャネル送信および上りリンク制御チャネル送信が同時に実行されれば、上りリンクシェアードチャネル送信および上りリンク制御チャネル送信のパワーヘッドルームレベルを具備する。

【0142】

上記に加えて、または、代わりに使われ得る本発明の有利な実施形態においては、基本のパワーヘッドルーム報告が上りリンクリソースの中で送信されるケースでは、プロセッサは、拡張されたパワーヘッドルーム報告の送信をユーザ機器の中でトリガする。さらに、送信機は、そのトリガされた拡張されたパワーヘッドルーム報告を、次の可能な上りリンクリソースの中でユーザ機器から基地局に送信する。より詳細には、次の可能な上りリンクリソースは、動的スケジューリングを介してスケジューリングされる。

【0143】

上記に加えて、または、代わりに使われ得る本発明の有利な実施形態においては、禁止タイマは、最初のパワーヘッドルーム情報を送信した後に特定の時間に対して第２のパワーヘッドルーム情報の送信を禁止するために使用される。禁止タイマは、トリガされた拡張されたパワーヘッドルーム報告に対して無視される。さらに、禁止タイマは、トリガされた拡張されたパワーヘッドルーム報告を送信した後に再スタートしない。

【0144】

本発明は、さらに、基地局に拡張されたパワーヘッドルーム報告を送信するためのユーザ機器を提供する。拡張されたパワーヘッドルーム報告および上りリンクデータは、上りリンクリソースの中で送信される。上りリンクリソースが永続スケジューリング構成を介してスケジューリングされるケースでは、トランスポートブロックが生成されるときに、全ての上りリンクデータがトランスポートブロックの中に含まれるように、ユーザ機器のプロセッサは、拡張されたパワーヘッドルーム報告よりも上りリンクデータを優先する。

【0145】

上記に加えて、または、代わりに使われ得る本発明の有利な実施形態においては、上りリンクデータは、ボイスオーバＩＰデータであり、優先付けは、拡張されたパワーヘッドルーム報告よりもボイスオーバＩＰ上りリンクデータを優先する。

【0146】

上記に加えて、または、代わりに使われ得る本発明の有利な実施形態においては、プロセッサは、論理チャネルの優先順位付け手順の間、論理チャネルを優先し、上りリンクデータは、特定の論理チャネルを使用して送信されることによって優先される。

【0147】

上記に加えて、または、代わりに使われ得る本発明の有利な実施形態においては、プロセッサは、トランスポートブロックのサイズが拡張されたパワーヘッドルーム報告および上りリンクデータを含むのに十分な大きさであるか否かを判断する。トランスポートブロックのサイズが十分な大きさではないケースでは、プロセッサは、拡張されたパワーヘッドルーム報告を、そのトランスポートブロックの中に含めない。

【0148】

上記に加えて、または、代わりに使われ得る本発明の有利な実施形態においては、ユーザ機器の送信機は、もう１つの拡張されたパワーヘッドルーム報告を、次の可能な上りリンクリソースの中で送信する。

【0149】

これは、詳細な明細書中に説明される発明の実施形態に関連してより明確になる。

【図面の簡単な説明】

【0150】

以下では、本発明について、添付の図面を参照しながらさらに詳しく説明する。図面において類似または対応する細部には、同じ参照数字を付してある。

【0151】

【図1】３ＧＰＰ ＬＴＥシステムの例示的なアーキテクチャを示している。

【図2】３ＧＰＰ ＬＴＥのＥ−ＵＴＲＡＮアーキテクチャ全体の例示的な概要を示している。

【図3】３ＧＰＰ ＬＴＥ（リリース８／９）に定義されている例示的な下りリンクコンポーネントキャリア上のサブフレーム構造を示している。

【図4】３ＧＰＰ ＬＴＥ（リリース８／９）に定義されている例示的な下りリンクスロットのリソースグリッドを示している。

【図5】下りリンクの動的なキャリアアグリゲーションの３ＧＰＰ ＬＴＥ−Ａ（リリース１０）レイヤ２構造を示している。

【図6】上りリンクの動的なキャリアアグリゲーションの３ＧＰＰ ＬＴＥ−Ａ（リリース１０）レイヤ２構造を示している。

【図7】コンポーネントキャリアのためのパワーヘッドルームを報告するためのＭＡＣ制御エレメントのフォーマットを示している。

【図8】ユーザ機器が電力制限される、すなわち、上りリンクで構成されたコンポーネントキャリアＣＣ＃１およびＣＣ＃２上で電力スケーリングを適用している、例示的なシナリオを示している。

【図9】タイプ２パワーヘッドルーム情報を含む、拡張されたパワーヘッドルームＭＡＣ制御エレメントを示している。

【図10】本発明の第１の態様に従うスケジューリングのタイプに依存するパワーヘッドルーム情報の送信を含む、ユーザ機器とｅＮｏｄｅＢとの間の通信チャネルおよびそれらのサブフレームを描くダイヤグラムである。

【図11】本発明の第１の態様に従う、上りリンクリソースのためのスケジューリングのタイプに依存する、ユーザ機器によってパワーヘッドルーム情報をｅＮｏｄｅＢに送信する手順を描くフローダイヤグラムである。

【図12】本発明の第２の態様に従う、上りリンクリソースのためのスケジューリングのタイプに依存する、ユーザ機器によってパワーヘッドルーム情報をｅＮｏｄｅＢに送信する手順を描くフローダイヤグラムである。

【図13】本発明の他の態様に従う、ユーザ機器によってパワーヘッドルーム情報をｅＮｏｄｅＢに送信する手順を描くフローダイヤグラムである。

【発明を実施するための形態】

【0152】

以下では、本発明のさまざまな実施形態について説明する。実施形態のほとんどは、上の背景技術のセクションで説明した３ＧＰＰ ＬＴＥ−Ａ（リリース１０）の移動通信システムに関連して概説されるが、これは例示を目的としているにすぎない。本発明は、例えば、前述した３ＧＰＰ ＬＴＥ−Ａ（リリース１０）通信システムなどの移動通信システムと組み合わせて有利に使用できるが、本発明は、この特定の例示的な通信ネットワークにおける使用に限定されないことに留意されたい。

【0153】

背景技術のセクションにおける説明は、本明細書に記載した主として３ＧＰＰ ＬＴＥ−Ａ（リリース１０）に関連する例示的な実施形態を深く理解することを目的としており、移動通信ネットワークにおけるプロセスおよび機能の、説明した特定の実施形態に本発明を制限するものではないことを理解されたい。しかしながら、本明細書に提案する改良は、背景技術のセクションに説明したアーキテクチャ／システムにおいて容易に適用することができ、本発明のいくつかの実施形態においては、これらのアーキテクチャ／システムの標準的な手順および改良された手順を利用することもできる。

【0154】

本発明で使用される「基本のパワーヘッドルーム報告」という用語は、ＬＴＥ規格のリリース８／９によって定義されるパワーヘッドルーム報告として理解される。特に、「基本のパワーヘッドルーム報告」は、図７に例示的に描かれたように、１つのコンポーネントキャリアのためのパワーヘッドルームレベルを報告する。接続としての「基本の」という用語は、単に、「拡張された」パワーヘッドルーム報告と対比させるために使用される。

【0155】

本発明で使用される「拡張されたパワーヘッドルーム報告」という用語は、ＬＴＥ規格のリリース１０によって新たにそして追加的に定義されるパワーヘッドルーム報告として理解される。特に、「拡張されたパワーヘッドルーム報告」は、図９に例示的に描かれたような情報を報告する。

【0156】

本発明で使用される「半永続スケジューリング」という用語は、動的ではなく永続的であるスケジューリングのタイプとして理解される。すなわち、この場合では、リソースは、すでに事前に定義され、したがって動的スケジューリンググラントを必要としない。「半永続スケジューリング」は、当業者に広く知られており、データパケットの最初の送信のために、永続的な上りリンクリソース割り当てを含み、一方で、データパケットの再送信のために、動的な上りリンクリソース割り当てを使用する。

【0157】

本発明で使用される「永続スケジューリング」という用語は、上記の「半永続スケジューリング」に密接に関係する。特に、「半永続スケジューリング」の最初の送信は、永続スケジューリングを介してスケジューリングされる。永続的割り当ては、すべての上りリンクリソースに対して基地局によって動的に制御されず、事前に定義された構成に従って割り当てられる。その構成は、特定の時間に対して（さもなければ、指示されるまで）有効である。現在の標準化において、永続スケジューリングは、半永続スケジューリングの一部であるが、これは必須のものではなく、将来、「永続スケジューリング」は別個に定義されるかもしれない。

【0158】

本発明は、背景技術の最後で説明した問題、特に、ＬＴＥ規格のリリース１０に従う拡張されたパワーヘッドルーム報告が、半永続スケジューリングされた上りリンクリソースの中で送信されるときに、上りリンクデータを送信する中で遅延を引き起こすことを低減するために用いられる。

【0159】

第１の態様
本発明の第１の態様に従って、パワーヘッドルーム報告は、パワーヘッドルーム情報が送信される上りリンクリソースに対するスケジューリングのタイプに依存する。要するに、パワーヘッドルーム報告がユーザ機器の中でトリガされるとき、対応する上りリンクリソースが、基地局から動的グラントを通してスケジューリングされるか、あるいは、永続的割り当てを通してスケジューリングされるかどうかを決定する。すなわち、構成された上りリンクグラントとしても言及される。通常、拡張されたパワーヘッドルーム情報を送信するために構成されたと推定されるユーザ機器は、拡張されたパワーヘッドルーム報告を送信するであろう。しかしながら、上りリンクリソースが永続スケジューリングされるとき、この構成は、ユーザ機器によって無視される。そして、基本の（拡張されていない）パワーヘッドルーム報告が、その永続的に割り当てられた上りリンクリソースを使用して基地局に送信される。他の全てのケースでは、ユーザ機器が、その構成に従い、拡張されたパワーヘッドルーム報告を基地局に送信する。

【0160】

より詳細には、以下のシナリオが想定される。リリース１０に従うユーザ機器は、拡張されたパワーヘッドルーム報告および通常のリリース８／９のパワーヘッドルーム報告をサポートする。基地局は、拡張されたパワーヘッドルーム報告によって提供される付加情報の利益を利用したく、拡張されたパワーヘッドルーム報告を送信するようにユーザ機器を構成する。基地局は、「基本の」通常のあるいは拡張されたパワーヘッドルームを報告するようにユーザ機器を構成することができることに留意されたい。この構成は、上位レイヤシグナリング、すなわちリソース制御（ＲＲＣ）シグナリングによって、なされる。

【0161】

さらに、ユーザ機器は、ボイスオーバＩＰアプリケーションを実行すると想定され、そのために基地局による半永続スケジューリング構成を持つ。換言すれば、初期送信のための上りリンクリソースは、ユーザ機器によって上りリンクボイスデータを送信するために、基地局によって永続的に構成される。ユーザ機器は、この構成を適用し、したがって全ての予め定められたサブフレームで基地局に上りリンクボイスデータを送信する。

【0162】

図１０は、ユーザ機器とｅＮｏｄｅＢ（基地局）との間のコンポーネントキャリアおよびそれらのサブフレームを描くダイヤグラムである。図１０から明らかなように、本発明の典型的な実施形態を説明するために、キャリアアグリゲーションがｅＮｏｄｅＢとユーザ機器との間で使用されると仮定する。ＰＣｅｌｌと１つのＳＣｅｌｌが構成される。

【0163】

現在の発明の実施形態が２つのコンポーネントキャリア（ＰＣｅｌｌとＳＣｅｌｌ）における通信に関連して記述されるけれども、これは発明の範囲を制限するもとして理解されるべきではない。現在の発明の実施形態は、１つのコンポーネントキャリアだけが構成されるとき、あるいは、いくつかのコンポーネントキャリアがユーザ機器と基地局との間で使われるときも同様に適用され得る。

【0164】

ＰＣｅｌｌのために、上りリンクリソースは、半永続スケジューリング構成の永続的な割り当てに基づいて４サブフレーム毎にスケジューリングされる。永続的割り当て（すなわち４サブフレーム）の特定の定期性は、単に例示として理解され、説明目的のためだけに４にセットされる。例えば、ＶｏＩＰアプリケーションでは、２０ｍｓの割り当てが一般的に用いられる。本発明の実施形態は、永続的割り当ての他のどの定期性にも適用可能である。

【0165】

図１０の中で表されるシナリオでは、サブフレーム１とサブフレーム１６において、パワーヘッドルーム報告が２回トリガされる。サブフレーム１において、ユーザ機器はＳＣｅｌｌのために動的な上りリンクリソース割り当てを行う。そして、パワーヘッドルーム情報は、このように、ＳＣｅｌｌの中でサブフレーム１の動的に割当られた上りリンクリソースの中で送信される。主なシナリオは、パワーヘッドルーム報告が、ユーザ機器がＰＣｅｌｌの中で上りリンクの半永続スケジューリング割り当てのみを行うＴＴＩ（サブフレーム）でトリガされるということである。さもなければ、ＳＣｅｌｌの上で同一のＴＴＩに、追加の、動的に割当られた上りリンクリソースがあるケースにおいて、ユーザ機器は、動的にスケジューリングされる上りリンクリソースの中に、拡張されたパワーヘッドルーム報告を含めることができる。そのケースでは、ＰＣｅｌｌ上でＶｏＩＰパケットの分割に関する問題が生じない。すなわち、ＶｏＩＰパケットは、永続スケジューリングされる上りリンクリソース上で送信され、拡張されたパワーヘッドルーム報告は、動的にスケジューリングされるＳＣｅｌｌ上の上り上で送信される。

【0166】

図１１は、ユーザ機器の、特に発明の第１の態様によってパワーヘッドルーム情報を基地局に送信する手順のフローダイヤグラムである。図１１は、拡張されたパワーヘッドルーム情報を報告するためにＵＥを構成するステップ、および、パワーヘッドルーム報告のトリガを示す。次のステップでは、ユーザ機器は、上りリンクリソースが現在の送信時間間隔（ＴＴＩ、通常１サブフレーム）の中に割り当てられることを決定する。

【0167】

サブフレーム１において、ユーザ機器は、サブフレーム１の上りリンクリソースが動的にスケジューリングされる、ことを決定する。すなわち、基地局は、上りリンクデータを送信するために、ユーザ機器に、ＰＤＣＣＨにおいて（図１０に図示しない）上りリンクグラント割り当てメッセージを送信した。対応して、ユーザ機器は、基地局に、拡張されたパワーヘッドルーム情報を送信する。

【0168】

より詳細には、ユーザ機器は、拡張されたパワーヘッドルーム情報を含むＭＡＣ制御エレメントを生成し、トランスポートブロックの中に、生成されたｅＰＨＲ ＭＡＣ制御エレメントを含める。さらに、ユーザ機器は、トランスポートブロックを、上りリンクで送信されるために待機している他のデータで満たす。

【0169】

サブフレーム１６の中のパワーヘッドルーム報告において、ユーザ機器は、対応する上りリンクリソースが永続スケジューリングを介して（すなわち、音声データを送信するために）スケジューリングされていることを知る。本発明の第１の態様によると、ユーザ機器は、そのとき、拡張されたパワーヘッドルーム報告のための構成を無視し、その代わりにリリース８／９の基本のパワーヘッドルーム報告を送信する。対応して、ユーザ機器は、ＰＨＲ ＭＡＣ制御エレメントを生成し、最初に、ＰＨＲ ＭＡＣ制御エレメントおよびそのときの音声データを挿入することにより、トランスポートブロックを生成する。

【0170】

半永続スケジューリングの割り当ては、動的グラントによって無効にされ得る。上記のケースでは、ユーザ機器は、上りリンクリソースが動的スケジューリングを介してスケジューリングされることを決定し、トリガされるならば拡張されたＰＨＲ ＭＡＣ制御エレメントを報告する。ｅＮｏｄｅＢは、そのケースでは、拡張されたパワーヘッドルーム報告とＶｏＩＰパケットの包含することが可能な十分に大きなグラントをスケジューリングすることができる。

【0171】

ユーザ機器は、異なる方法で、上りリンクリソースのスケジューリングのタイプを決定することができる。ユーザ機器は、このように、永続スケジューリングを構成され、その上りリンクリソースが永続スケジューリングの一部としてスケジューリングされたものであるのか否か、あるいは、ユーザ機器がＰＤＣＣＨの中で基地局から上りリンクグラント事前に受信していたか否かを推測することができる。ＰＤＣＣＨの存在に依存して、ＵＥは、その上りリンクリソースが永続的にスケジューリングされたものであるのかものであるのかを決定する。すなわち、上りリンクグラントが構成されたか、あるいは、上りリンクリソースが動的にスケジューリングされたものであるか否かについても言及される。

【0172】

基地局が上記の方法でユーザ機器を構成してから、基地局は、ユーザ機器から拡張されたパワーヘッドルーム報告を受信することを期待する。拡張されたパワーヘッドルームＭＡＣ制御エレメントおよび通常のリリース８／９のパワーヘッドルームＭＡＣ制御エレメントは、ＭＡＣ ＰＤＵサブヘッダの中で、異なる論理チャネルＩＤを持つ。したがって、ｅＮｏｄｅＢは、そのサブヘッダに基づいて双方のＭＡＣ制御エレメントを区別することができる。

【0173】

この全体の手順の利益の１つは、半永続スケジューリングとの組み合わせの中で拡張されたパワーヘッドルーム報告を考慮する新たなトランスポートブロックサイズテーブルが提示される必要がないことである。換言すれば、リリース８／９で定義されたものと同一のトランスポートブロックサイズテーブルが、使用され得る。さらに、ｅＮｏｄｅＢは、リリース８／９の中で使用された半永続スケジューリング割り当てに対して同一のトランスポートブロックサイズを割り当てることができる。それは、同様に、拡張されたパワーヘッドルーム報告が構成されたときに同一のＶｏＩＰ容量がリリース１０においてもサポートされることを意味する。特に、半永続スケジューリング作業は、パワーヘッドルーム報告と結合してリリース８／９に対するものと同一になる。

【0174】

明らかに、上りリンクデータおよびパワーヘッドルーム報告も遅延しない。パワーヘッドルームは、トリガされると直ぐに報告される。

【0175】

しかしながら、リリース８／９のパワーヘッドルーム報告は、リリース１０の拡張されたパワーヘッドルーム報告と同じレベルの情報を提供しない。上記で説明したように、また、図７、図１１から明らかなように、拡張されたパワーヘッドルーム報告は、追加のパワーヘッドルームの中に）対応するコンポーネントキャリアの最大送信電力が含まれる。それは、基本的に、コンポーネントキャリア上の上りリンク送信のために、使用された電力の削減（ＭＰＲ／Ａ−ＭＰＲ）の情報と共にｅＮｏｄｅＢに提供される。それにもかかわらず、半永続スケジューリングは、リリース１０のＰＣｅｌｌ上でのみ使用され、割り当てられたトランスポートブロックサイズは、一般に、半永続スケジューリングよりも小さい。したがって、使用されたＭＰＲの知識がより高いデータレートにおいてより重要になるから、半永続スケジューリング割り当てに対して使用された電力の削減の情報が供給されないという欠点は、重要なものとして考慮されない。

【0176】

この欠点は、本発明の以下の有効な実施形態によって解消され得る。ユーザ機器が永続的に割り当てられた上りリンクリソースに対して拡張されたパワーヘッドルーム報告の代わりにリリース８／９のパワーヘッドルーム報告を送信するとき、もう１つの（拡張された）パワーヘッドルーム報告が、次の可能な上りリンクリソースの中で送信のためにユーザ機器によって暗にトリガされる。これに対応して、ユーザ機器は、次の可能な上りリンクリソースの中で拡張されたパワーヘッドルーム報告を送信する。この有利な実施形態は、その追加のもう１つのパワーヘッドルーム報告のトリガがオプションであって必須ではないことを表すために、図１０、図１１の中でも破線で表されている。

【0177】

図１０、図１１の中で、ユーザ機器は、ＰＣｅｌｌの中で拡張されたパワーヘッドルーム報告を送信するためにユーザ機器によって使用され得る（次のＴＴＩである）サブフレーム１７の中で動的スケジューリングを持つと仮定される。図１１から明らかなように、ユーザ機器は、サブフレーム１７の上りリンクリソースのスケジューリングのタイプを等しくチェックし、そのときにサブフレーム１７が動的にスケジューリングされることを決定し、そのときに他の待機している上りリンクデータとともに拡張されたパワーヘッドルーム報告を送信する。

【0178】

ユーザ機器によって内的にトリガされた拡張されたパワーヘッドルーム報告が遅延しないために、ＰＨＲを禁止するタイマの作業が、サブフレーム１７の中で送られるこの追加のｅＰＨＲに対して無視される。換言すれば、ｅＰＨＲは、ＰＨＲを禁止するタイマが走っているかどうかとは無関係に、次の送信機会（この例ではサブフレーム１７）で送信される。

【0179】

さらに、ＰＨＲを禁止するタイマが、好都合に、サブフレーム１７のこの追加のｅＰＨＲの送信で再スタートされない。これは、暗にトリガされた拡張されたパワーヘッドルーム報告が、通常のパワーヘッドルーム報告手順にインパクトを持たない、という利益を有する。すなわち、暗にトリガされた拡張されたパワーヘッドルーム報告は、パワーヘッドルーム関連のタイマに従ってそれぞれがトリガする次の規則的なパワーヘッドルーム報告を遅延させない。

【0180】

本発明の上記で説明した有利な実施形態は、拡張されたパワーヘッドルーム報告からの追加情報、すなわちＰｃｍａｘおよびＰＨタイプ２が次の可能な上りリンクリソース機会の中でｅＮｏｄｅＢによって受信される。

【0181】

ＬＴＥの規格は、拡張されたパワーヘッドルーム情報を送信するときに、上りリンクリソースのスケジューリングのタイプを考慮するために、変更され得る。例えば、拡張されたＰＨＲが構成され、ＴＴＩのための上りリンクグラントが構成されていれば、ＵＥは、物理レイヤからタイプ１のパワーヘッドルームの値を得て、ＰＨＲ ＭＡＣ制御エレメントを生成して送信するために、多重および組み立ての手順を指示するであろう。

【0182】

第２の態様
本発明の第２の態様に従って、上りリンクデータは、永続的にスケジューリングされた上りリンクリソースにおいて、パワーヘッドルーム報告よりも優先される。

【0183】

これは、異なる方法で成し遂げられる。本発明の１つの実施形態に従って、論理チャネル優先順位付け手順が、以下で記述されるように構成される。

【0184】

特に、ユーザ機器は、基地局にパワーヘッドルーム情報を報告することをサポートし、構成されるものであると再び推測される。パワーヘッドルーム報告がトリガされ、利用可能な上りリンクリソースが存在するとき、ユーザ機器は、拡張されたパワーヘッドルーム報告ＭＡＣ制御エレメントを生成する。トリガされたパワーヘッドルーム報告のための上りリンクリソースは、永続的割り当てを介してスケジューリングされる。ＭＡＣレイヤは、待機している音声データと共に拡張されたパワーヘッドルーム報告を送信するために、対応するトランスポートブロックを生成する。トランスポートブロックを生成するとき、ユーザ機器は、論理チャネル優先付け手順を実行する。

【0185】

本発明の第２の態様の１つの実施形態に従って、対応する上りリンクリソースが永続的にスケジューリングされるとき、論理チャネルからの上りリンクデータは、拡張されたパワーヘッドルーム報告よりも優先される。この動作は、トランスポートブロックが、最初に、例えば時間に厳しい音声データ等の上りリンクデータで満たされる、という結果を招く。永続的割り当てのトランスポートブロックは、拡張されたＰＨＲを収容できるだけの十分な大きさではないから、拡張されたＰＨＲは、そのトランスポートブロックでは送信され得ない。ＭＡＣレイヤのなくなった分割機能のため（図６参照）、拡張されたＰＨＲ ＭＡＣ制御エレメントは分割され得ない点に留意すべきである。

【0186】

トランスポートブロックは、このため、上りリンクデータおよび必要に応じたパディングビットのみを含む。拡張されたパワーヘッドルーム報告は、そのとき、遅延され、動的にスケジューリングされる次の可能な上りリンク割り当ての中で送信される。この実施形態は、動的に割り当てられる上りリンクリソースに対して拡張されたパワーヘッドルーム報告を送信するためにユーザ機器によって採られるステップを説明する図１２に描かれている。

【0187】

論理チャネル優先付け手順の規格は、このため、以下の１つの例に従って表現される、対応する優先付けルールを含む。

【0188】

構成された上りリンクリソース割り当てのために、論理チャネルからのデータは、ｅＰＨＲ ＭＡＣ ＣＥよりも高い優先度を持つ。

【0189】

規格の技術仕様書の中で使用される「構成された上りリンクリソース」という用語は、永続的に割り当てられる上りリンクリソースに対応する。

【0190】

それらによって得られる１つの利益は、上りリンクデータ、特に音声データが、トランスポートブロックの中に拡張されたパワーヘッドルーム報告を含めることによって分割されず、このため遅延されない、ということである。その拡張されたパワーヘッドルーム報告が、代わりに遅延される。

【0191】

本発明の第２の態様のさらに他の実施形態に従って、音声データのみが、拡張されたパワーヘッドルーム報告よりも優先される。従来技術に従う、半永続的に割り当てられた上りリンクリソースとの組み合わせの拡張されたパワーヘッドルーム報告によって導入される遅延は、特に時間に厳しい音声データにとって著しく不利である。これは、時間遅延にあまりネガティブではない他のデータには必ずしも当てはまらない。

【0192】

論理チャネル優先付け手順の規格は、このため、以下の１つの例に従って表現される、対応する優先付けルールを含む。

【0193】

上りリンクグラントが構成されれば、上位レイヤによってセットアップされる論理チャネルＳＲ（Scheduling Request ）マスキング（logicalChannelSR-Mask）の論理チャネルのためのデータは、ｅＰＨＲ ＭＡＣ ＣＥよりも高い優先度を持つ。

【0194】

上記の優先付けルールは、フラグ"logicalChannelSR-Mask"がセットされるそれらの論理チャネルのために、永続的に割り当てられるリソースのケースにおけるｅＰＨＲ ＭＡＣ ＣＥより優先される論理チャネルを限定する。典型的には、そのフラグは、半永続スケジューリングが構成されるケースにおいてＶＯＩＰデータを運ぶ論理チャネルに対してセットされる。

【0195】

本発明の第２の態様のさらに他の実施形態に従って、論理チャネル優先付け手順は変更されないが、トランスポートブロックを生成するためのＭＡＣ手順は以下のように拡張される。これは、拡張されたパワーヘッドルーム報告を送信するためにユーザ機器によって採られるステップを説明する図１３を参照して説明される。

【0196】

ユーザ機器のＭＡＣレイヤは、永続的に割り当てられる上りリンクリソースの中で送信されるトランスポートブロックに対して、そのトランスポートブロックが、（サブヘッダを含む）拡張されたパワーヘッドルーム報告に加えて、送信可能な全ての待機中の上りリンクデータを収容できるかどうか、をチェックする。トランスポートブロックが小さすぎるケースでは、上りリンクデータのみが、そのトランスポートブロックの中に含められる。ｅＰＨＲ ＭＡＣ制御エレメントは、このため、後で上りリンクリソースで送信される。

【0197】

本発明のさらに他の実施形態に従って、パワーヘッドルーム報告の規格が、拡張されたパワーヘッドルーム報告の半永続スケジューリングの組み合わせが禁止されるように変更されとする。基本的に、ｅＮｏｄｅＢが半永続スケジューリングを構成して可能にするとき、「基本の」パワーヘッドルーム報告のみが構成され得る。

【0198】

更に代わりの解決案では、パワーヘッドルーム報告、すなわち、拡張された、あるいは、基本のパワーヘッドルーム報告の構成は、コンポーネントキャリア毎になされる。このケースでは、半永続スケジューリングがＰＣｅｌｌに対しても構成され、同時に拡張されたパワーヘッドルーム報告がアグリゲーとされるＳＣｅｌｌに対して構成されるケースにおいて、ｅＮＢが、ＰＣｅｌｌに対して「基本の」パワーヘッドルーム報告を構成することができる、

【0199】

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

【0200】

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

【0201】

ほとんどの実施形態は、３ＧＰＰに基づく通信システムのアーキテクチャに関して説明され、また、本書中で用いた用語は、主に３ＧＰＰの用語に関する。しかし、３ＧＰＰに基づくアーキテクチャに関するさまざまな実施形態の用語および説明は、本発明の原理および思想をそのようなシステムのみに限定するものではない。また、上記背景技術の節で述べた詳細な説明は、本書で述べた主に３ＧＰＰ特有の例示的な実施形態をもっと良く理解するためのものであり、本発明を移動通信ネットワークにおける処理および機能の上記特定の実施形態に限定するものとして理解してはならない。それにもかかわらず、本書で提案した改良は、背景技術の節で説明したアーキテクチャにおいて容易に適用され得る。さらに、本発明のコンセプトは、現在のＬＴＥ ＲＡＮおよび３ＧＰＰで議論されているその発展型（ＬＴＥ−Ａ）においても容易に使用され得る。

【0202】

先の段落では、本発明のさまざまな実施形態およびその変更例を説明した。広く記載した本発明の概念または範囲から逸脱することなく、特定の実施形態に示すように、本発明に対して多くのバリエーションおよび／または変更を加え得ることは、当業者によって理解されるであろう。

【図1】

【図2】

【図5】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図3】

【図4】

【図6】

【図7】