"キャリアアグリゲーションをサポートする移動通信システムの端末におけるスケジューリング情報を処理する方法であって、前記キャリアアグリゲーションによって追加されるアップリンクキャリアに関する情報を含む制御メッセージを基地局から受信するステップと、前記制御メッセージに含まれた情報に基づいて前記基地局にバッファ状態報告のために使用される新たなバッファ状態テーブルを決定するステップと、を有することを特徴とする方法。前記決定するステップは、前記制御メッセージに含まれた情報は前記追加されるアップリンクキャリアの数を含み、前記追加されるアップリンクキャリアの数に基づいて前記新たなバッファ状態テーブルを決定するステップをさらに有することを特徴とする請求項1に記載の方法。前記決定するステップは、前記制御メッセージに含まれた情報は最大アップリンク伝送速度を計算するための情報を含み、前記最大アップリンク伝送速度に対応するように前記新たなバッファ状態テーブルを決定するステップをさらに有することを特徴とする請求項1に記載の方法。前記制御メッセージは、新たなバッファ状態テーブルを指示する情報をさらに含むことを特徴とする請求項1に記載の方法。キャリアアグリゲーションをサポートする移動通信システムの端末におけるスケジューリング情報を処理する方法であって、基地局からアップリンクキャリア設定を指示する制御メッセージを受信して新たに使用されるバッファ状態テーブルを決定するステップと、バッファ状態報告がトリガされた場合、前記決定したバッファ状態テーブルの識別子と前記BSRを含むメディアアクセス制御パケットデータユニットを生成して前記基地局に伝送するステップと、を有することを特徴とする方法。前記決定されたバッファ状態テーブルの識別子は、前記MACPDUに格納される少なくとも一つのMACPDUのサブヘッダで予備ビットに設定されることを特徴とする請求項5に記載の方法。キャリアアグリゲーションをサポートする移動通信システムの端末におけるスケジューリング情報を処理する方法であって、基地局からサブフレームに対する新たな伝送を指示するアップリンクグラントを受信し、関連したダウンリンクキャリアから制御チャンネルを受信するステップと、バッファ状態報告がトリガされた場合、前記バッファ状態報告のフォーマットとバッファ状態値を決定するステップと、を有することを特徴とする方法。前記基地局に伝送されるサブフレーム内の複数のMACPDUのうちいずれか一つに前記バッファ状態報告が含まれることを特徴とする請求項7に記載の方法。前記基地局に伝送されるサブフレームに対して複数のアップリンクグラントが割り当てられた場合、最後のアップリンクグラントを処理しつつ前記バッファ状態報告を生成することを特徴とする請求項7に記載の方法。キャリアアグリゲーションをサポートする移動通信システムの端末におけるスケジューリング情報を処理する方法であって、アップリンクグラントを受信した後、アップリンクキャリアに対するデータチャンネル電力ヘッドルーム報告がトリガされたか否かを判断するステップと、前記データチャンネルPHRがトリガされ、前記アップリンクキャリアがプライマリコンポーネントキャリアである場合、制御チャンネルPHRが設定されたか否かによって前記制御チャンネルPHRを生成して基地局に伝送するステップと、を有することを特徴とする方法。前記制御チャンネルPHRが設定された場合、前記データチャンネルPHRと共に前記制御チャンネルPHRを生成して前記基地局に生成するステップをさらに有することを特徴とする請求項10に記載の方法。キャリアアグリゲーションをサポートする移動通信システムの端末におけるスケジューリング情報を処理する方法であって、基地局から新たな伝送のためのアップリンクリソースの割り当てを受信するステップと、前記新たな伝送のためのアップリンクリソースがMACリセット以後で最初に割り当てられたアップリンクリソースである場合、周期的PHRタイマが設定されているアップリンクキャリアの前記周期的PHRタイマを駆動させるステップと、を有することを特徴とする方法。キャリアアグリゲーションをサポートする移動通信システムの端末におけるスケジューリング情報を処理する方法であって、基地局からバッファ状態報告をトリガするためのパラメータを受信して前記トリガを活性化するステップと、前記トリガされたバッファ状態報告のバッファ状態値が基準バッファ状態値を満たすか否かを確認するステップと、前記バッファ状態値が前記基準バッファ状態値を満たす場合、所定の基準トリガを適用するステップと、を有することを特徴とする方法。前記所定の基準トリガは、伝送量基準のトリガであることを特徴とする請求項13に記載の方法。前記所定の基準トリガは、伝送レート基準のトリガであることを特徴とする請求項13に記載の方法。キャリアアグリゲーションをサポートする移動通信システムの端末におけるスケジューリング情報を処理する方法であって、アップリンク伝送の際に、伝送出力の縮小が発生するか否かを判定するステップと、前記伝送出力の縮小が発生した場合、アップリンクキャリアの中から電力ヘッドルーム報告が設定されたアップリンクキャリアのPHRをトリガするステップと、を有することを特徴とする方法。キャリアアグリゲーションをサポートする移動通信システムの端末におけるスケジューリング情報を処理する方法であって、基地局から電力ヘッドルーム報告設定情報を含む制御メッセージを受信してPHRがトリガされるか否かを判定するステップと、前記PHRがトリガされると、プライマリキャリア用PHRとセカンダリキャリア用PHRを含むパケットデータユニットを前記基地局に伝送するステップと、を有することを特徴とする方法。前記制御メッセージは、経路損失変化、周期的PHRタイマ、禁止PHRタイマ、PHRがトリガされるか否かを判定するキャリアコンポーネント、及びPHR用セカンダリキャリア識別子のうち少なくとも一つを含むことを特徴とする請求項17に記載の方法。前記セカンダリキャリア用PHRは一つ又は複数個であることを特徴とする請求項17に記載の方法。一つのセカンダリキャリア用PHRにすべてのセカンダリキャリアのPHを格納する場合、前記セカンダリキャリア用PHRのMACサブヘッダには前記セカンダリキャリア用PHRのサイズを指示する情報が含まれることを特徴とする請求項17に記載の方法。したがって、上記のような従来技術の問題点を解決するために、本発明の目的は、移動通信システムにおけるスケジューリング情報を効率的に処理する方法及び装置と、そのシステムを提供することにある。本発明の他の目的は、キャリアアグリゲーションをサポートする移動通信システムにおいて、端末と基地局との間のスケジューリング情報を効率的に処理する方法及び装置と、そのシステムを提供することにある。また、本発明の目的は、キャリアアグリゲーションをサポートする移動通信システムにおいて、端末のバッファ状態報告を効率的に遂行する方法及び装置と、そのシステムを提供することにある。さらに、本発明の目的は、キャリアアグリゲーションをサポートする移動通信システムにおいて、端末の電力ヘッドルーム報告を効率的に遂行する方法及び装置と、そのシステムを提供することにある。上記のような目的を達成するために、本発明の一態様によれば、キャリアアグリゲーションをサポートする移動通信システムの端末におけるスケジューリング情報を処理する方法であって、キャリアアグリゲーションによって追加されるアップリンクキャリアに関する情報を含む制御メッセージを基地局から受信するステップと、制御メッセージに含まれた情報に基づいて基地局にバッファ状態報告のために使用される新たなバッファ状態テーブルを決定するステップとを有する。本発明の他の態様によれば、キャリアアグリゲーションをサポートする移動通信システムの端末におけるスケジューリング情報を処理する方法であって、基地局からアップリンクキャリア設定を指示する制御メッセージを受信して新たに使用されるバッファ状態テーブルを決定するステップと、バッファ状態報告がトリガされた場合、決定したバッファ状態テーブルの識別子とBSRを含むメディアアクセス制御パケットデータユニットを生成して基地局に伝送するステップとを有する。本発明の他の態様によれば、キャリアアグリゲーションをサポートする移動通信システムの端末におけるスケジューリング情報を処理する方法であって、基地局からサブフレームに対する新たな伝送を指示するアップリンクグラントを受信し、関連したダウンリンクキャリアから制御チャンネルを受信するステップと、バッファ状態報告がトリガされた場合、バッファ状態報告のフォーマットとバッファ状態値を決定するステップとを有する。本発明の他の態様によれば、キャリアアグリゲーションをサポートする移動通信システムの端末におけるスケジューリング情報を処理する方法であって、アップリンクグラントを受信した後、アップリンクキャリアに対するデータチャンネル電力ヘッドルーム報告がトリガされたか否かを判断するステップと、データチャンネルPHRがトリガされ、アップリンクキャリアがプライマリコンポーネントキャリアである場合、制御チャンネルPHRが設定されたか否かによって制御チャンネルPHRを生成して基地局に伝送するステップと、アップリンクグラントを受信した後、アップリンクキャリアに対するPUSCHPHRがトリガされたか否かを判断するステップと、PUSCHPHRがトリガされてアップリンクキャリアがPCCである場合、PUCCHPHRが設定されたか否かによってPUCCHPHRを生成して基地局に伝送するステップとを有する。本発明の他の態様によれば、キャリアアグリゲーションをサポートする移動通信システムの端末におけるスケジューリング情報を処理する方法であって、基地局から新たな伝送のためのアップリンクリソースの割り当てを受信するステップと、新たな伝送のためのアップリンクリソースがMACリセット以後に最初に割り当てられたアップリンクリソースである場合、周期的PHRタイマが設定されているアップリンクキャリアの周期的PHRタイマを駆動させるステップとを有する。本発明の他の態様によれば、キャリアアグリゲーションをサポートする移動通信システムの端末におけるスケジューリング情報を処理する方法であって、基地局からバッファ状態報告をトリガするためのパラメータを受信してトリガを活性化するステップと、トリガされたバッファ状態報告のバッファ状態値が基準バッファ状態値を満たすか否かを確認するステップと、バッファ状態値が基準バッファ状態値を満たす場合、所定の基準トリガを適用するステップとを有する。本発明の他の態様によれば、キャリアアグリゲーションをサポートする移動通信システムの端末におけるスケジューリング情報を処理する方法であって、アップリンク伝送の際に、伝送出力の縮小が発生するか否かを判定するステップと、伝送出力の縮小が発生した場合、アップリンクキャリアの中から電力ヘッドルーム報告が設定されたアップリンクキャリアのPHRをトリガするステップを有する。本発明の他の態様によれば、キャリアアグリゲーションをサポートする移動通信システムの端末におけるスケジューリング情報を処理する方法であって、基地局から電力ヘッドルーム報告設定情報を含む制御メッセージを受信してPHRがトリガされるか否かを判定するステップと、PHRがトリガされると、プライマリキャリア用PHRとセカンダリキャリア用PHRを含むパケットデータユニットを基地局に伝送するステップとを有する。以下、本発明の望ましい実施形態を添付の図面を参照して詳細に説明する。下記の説明で、本発明に関連した公知の機能又は構成に関する具体的な説明が本発明の要旨を不明にすると判断された場合に、その詳細な説明を省略する。本発明は、複数のキャリアが集約された端末がBSR機能とPHR機能を遂行する方法及び装置に関するものである。本発明を本格的に説明するに先立ち、図1、図2、及び図3を通じてLTEシステムについてより詳細に説明する。図1は、本発明が適用されるLTEシステムの構成を示す。図1を参照すると、図示のように、LTEシステムの無線アクセスネットワークは、次世代基地局105,110,115,120と、MME125と、S‐GW135は、ENB105~120及びS‐GW130を通じて外部ネットワークにアクセスする。図1において、ENB105~120は、UMTSシステムの既存ノードBに対応する。ENBは、UE135と無線チャンネルで接続され、既存ノードBより複雑な役割を遂行する。LTEシステムにおいては、インターネットプロトコルを通したVoIPのようなリアルタイムサービスだけでなく、すべてのユーザートラフィックが共有チャンネルを介してサービスされるため、UEのバッファ状態、電力ヘッドルーム状態、チャンネル状態のような状態情報を集めてスケジューリングを遂行する装置が必要であり、ENB105~120は、これを担当する。一つのENBは、通常、複数のセルを制御する。例えば、100Mbpsの伝送速度を実現するために、LTEシステムは、例えば、20MHz帯域幅で直交周波数分割多重方式を適用する。SGW130は、データベアラを提供する装置であり、MME125の制御によってデータベアラを生成又は除去する。MMEは、端末に対する移動性管理機能だけでなく各種制御機能を担当する装置であって、複数の基地局に接続される。図2は、本発明が適用されるLTEシステムにおける無線プロトコル構造を示す。図2を参照すると、LTEシステムの無線プロトコルは、端末とENBで各々PDCP205,240、RLC210,235、MAC215,230を含む。PDCP205,240は、IPヘッダの圧縮復元の動作を遂行し、無線リンク制御210,235は、PDCPPDUを適切なサイズで再構成してARQ動作などを遂行する。MAC215,230は、一つの端末に構成された数個のRLC階層装置と接続され、MACPDUにRLCPDUを多重化し、MACPDUからRLCPDUを逆多重化する動作を遂行する。MAC215,230は、BSRの生成及び伝送、PHRの生成及び伝送を遂行する。物理階層220,225は、上位階層データをチャンネル符号化及び変調してOFDMシンボルに生成して無線チャンネルを介して伝送し、無線チャンネルを介して受信したOFDMシンボルを復調してチャンネル復号化して上位階層に伝送する。伝送に基づいてプロトコルエンティティに入力されるデータをSDUと称し、プロトコルエンティティから出力されるデータをPDUと称する。図3は、端末においてキャリアアグリゲーションを説明するための図である。図3を参照すると、一つの基地局では、一般的に複数の周波数帯域にわたって複数のキャリアが送信及び受信される。例えば、ENB305から中心周波数がf1であるキャリア315と中心周波数がf3であるキャリアが送信される場合、従来からは一つの端末が2つのキャリアのうちいずれか一つを用いてデータを送受信した。しかしながら、キャリアアグリゲーション能力を有する端末は、複数のキャリアから同時にデータを送受信することができる。基地局305は、キャリアアグリゲーション能力を持っている端末330に対して、状況に従ってより多くのキャリアを割り当てることによって、端末330の伝送速度を増加させることができる。従来の意味では、一つの基地局で送受信される一つのダウンリンクキャリアと一つのアップリンクキャリアが一つのセルを構成すると仮定すれば、キャリアアグリゲーションは、端末が同時に複数のセルを通してデータを送受信することがわかる。このように、最大伝送速度は、集約されるキャリアの数に比例して増加する。以下、本発明の説明において、端末が任意のダウンリンクキャリアを介してデータを受信し、あるいは任意のアップリンクキャリアを介してデータを伝送することは、キャリアを特徴づける中心周波数と周波数帯域に対応するセルで提供する制御チャンネルとデータチャンネルを介してデータを送受信することと同一の意味を有する。また、以下、本発明の実施形態はLTEシステムを仮定して説明されるが、本発明は、キャリアアグリゲーションをサポートする各種無線通信システムに適用可能である。下記の実施形態の中で、<第1の実施形態>から<第3の実施形態>、<第7の実施形態>は、端末が基地局に伝送するスケジューリング情報のうち、バッファ状態報告サンプリングした値である。バッファ状態値の最大値は、端末が最大伝送速度で伝送する状況で所定のバッファ状態報告の遅延を仮定したとき、伝送が断絶なしに進行されるように設定した値である。例えば、端末の最大速度がxbpsで、ysecがバッファ状態報告の伝送に要求されると、バッファ状態の最大値は、xとyの積である。端末の最大伝送速度を決定する要素は、端末固有の性能又は任意のタイミングで端末に設定されているアップリンクキャリアの数である。この中で設定されたアップリンクキャリアの数は、端末の最大伝送速度に大きい影響を及ぼし、与えられた端末性能において、1個のアップリンクキャリアを用いてzbpsの伝送速度が可能であると、znbpsの伝送速度は、n個のアップリンクキャリアを用いて可能である。本発明では、複数のバッファ状態テーブルを定義し、端末が使用できるアップリンクキャリアの最大個数に従って端末と基地局は、適切なバッファ状態テーブルを使用してバッファ状態報告を遂行する。参考のために、従来は、0バイト~150000バイト間のバッファ状態を指示するバッファ状態テーブルを使用した。以下、説明の便宜のために、従来から使用されてきたバッファ状態テーブルを基本バッファ状態テーブルとして称する。下記の<表1>は、3GPP規格36321の2009年12月バージョンのセクション6131にある基本バッファ状態テーブルである。以下、本発明において、規格36321は、規格36321の2009年12月バージョンと呼ばれることを理解するものとする。<表1>は、基本バッファ状態テーブルの一例を示し、本発明では基本バッファ状態テーブルが下記の<表1>に限定されるものではない。本発明の第1の実施形態において、端末と基地局は、<表1>のような基本バッファ状態テーブルを包含して複数のバッファ状態テーブルを有する。この端末と基地局は、所定の規則を適用して任意のタイミングで複数のバッファ状態テーブルの中から使用するバッファ状態テーブルを決定する。所定の規則は、例えば該当タイミングで設定されるアップリンクキャリアの数となり得る。基本バッファ状態テーブル以外に追加的に提供されるバッファ状態テーブルは、端末の最大伝送速度に合せて定義することができる。例えば、端末に設定可能なアップリンクキャリアの個数がn個であると、端末は、バッファ状態の最大値が基本バッファ状態テーブルの2倍であるバッファ状態テーブル、3倍であるバッファ状態テーブルなど、すべてn個の追加的なバッファ状態テーブルを有することができる。もしくは、端末は、過度に多くの数のバッファ状態テーブルを有する代わりに、制限された数、例えば2個又は3個のバッファ状態テーブルのみを有することもできる。便宜上、端末と基地局は、基本バッファ状態テーブル、追加バッファ状態テーブル1、及び追加バッファ状態テーブル2の3個のバッファ状態テーブルを有すると仮定する。追加バッファ状態テーブル1は、端末に設定されたアップリンクキャリアの数が2個である場合を仮定して定義されたものであり、最大バッファ報告値は300000バイトである。追加バッファ状態テーブル2は、端末に設定されたアップリンクキャリアの数が3個以上である場合のために定義されたものであり、最大バッファ報告値は1500000バイトである。追加バッファ状態テーブル1と追加状態バッファ状態テーブル2の例を下記の<表2>と<表3>に各々示す。以下、本発明では、端末が基本バッファ状態テーブル、追加バッファ状態テーブル1、及び追加バッファ状態テーブル2を有すると仮定する。しかしながら、端末と基地局は、より多い数のバッファ状態テーブルを有するか、あるいは少ない数のバッファ状態テーブルを有することができる。図4は、本発明の第1の実施形態によるバッファ状態報告方法のフローを示す。図4を参照すると、端末405は、ステップ415で、RRC接続設定過程を遂行した後、キャリアが追加に割り当てられる前までステップ420で、従来のLTE端末と同一の方式で基地局410と通信を遂行する。すなわち、端末405と基地局410は、一般的なLTE端末の場合と同様に、一つのダウンリンクキャリアと一つのアップリンクキャリアでダウンリンクデータとアップリンクデータを送受信する。この場合、設定されたアップリンクキャリアの数が一つであるので、端末405と基地局410は、基本バッファ状態テーブルを使用する。この後、ステップ430で、任意のタイミングで端末405のトラフィックが増加すると、基地局410は、端末405に新たなキャリアを追加することAdditionを決定する。基地局410は、端末405に所定のRRCメッセージを制御メッセージとして伝送し、このRRCメッセージは、新たに追加されるアップリンクキャリアに関連した情報、例えばキャリア中心周波数及び帯域幅情報を含む。端末405は、新たに追加されるアップリンクキャリアの数を参照して以後に使用するバッファ状態テーブルを決定する。例えば、端末405に一つのアップリンクキャリアが新たに追加されて端末405が2個のアップリンクキャリアが設定されると、端末405は、追加バッファ状態テーブル1を使用する。または、端末405に2個のアップリンクキャリアが新たに追加されて端末405に総3個のアップリンクキャリアが設定される場合、端末405は、追加バッファ状態テーブル2を使用する。他の実施形態において、端末は、設定されたアップリンクキャリアの数でなく、追加されたアップリンクキャリアによる端末の最大アップリンク伝送速度を参照して使用するバッファ状態テーブルを決定することができる。ここで、最大アップリンク伝送速度は、アップリンク帯域幅、伝送アンテナの数、及び変調方式を因子により定義される関数である。端末405と基地局410は、最大アップリンク伝送速度がxbps以下である場合には基本バッファ状態テーブルを、xbpsとybpsとの間である場合には追加バッファ状態テーブル1を、ybps以上である場合には追加バッファ状態テーブル2を使用することとして予め定められ得る。最大アップリンク伝送速度は、アップリンクキャリア別に算出された後に合算できる。任意のアップリンクキャリアx、最大変調次数を用いてアップリンクキャリア別最大伝送速度を計算し、アップリンクキャリア別に計算された値を合算してアップリンクキャリアの最大伝送速度の総合を計算する。端末405は、設定又は追加されたアップリンクキャリアによる最大アップリンク伝送速度の値が対応するバッファ状態テーブルを確認し、その後に使用するバッファ状態テーブルを決定する。上記のように、端末405は、アップリンクキャリア設定状況を考慮してバッファ状態テーブルを自分自身で決定する代わり、基地局410が端末405にどのバッファ状態テーブルを使用するかを直接指示することができる。ここで、使用されるバッファ状態テーブルを指示する情報は、キャリアを新たに追加するために、ステップ430で伝送される制御メッセージに含まれることができる。端末405は、RRCメッセージを受信して新たなバッファ状態テーブルを使用しなければいけないことを認知すると、ステップ435で、BSRをトリガして所定の手順を通してトリガされたBSRを伝送する。BSRをトリガする理由は、バッファ状態テーブルの変更の際に発生し得る不確実性を除去するためである。例えば、端末405は、新たなバッファ状態テーブルを適用する直前に以前のバッファ状態テーブルを使用したBSRを伝送した場合、基地局410は、BSRが新たなバッファ状態テーブルに基づいたものであるか、あるいは以前のバッファ状態テーブルに基づいたものであるかを正確に判断できないことがある。これを解決するために、端末405は、バッファ状態テーブルが変更されると、正規BSRをトリガして変更されたバッファ状態テーブルを用いて基地局410にバッファ状態を可能な限り早く報告する。ステップ440で、基地局410は、BSRを成功的に受信すると、端末405にアップリンクグラントを割り当て、ステップ445で、端末405は、割り当てられたアップリンクグラントを用いてアップリンク伝送を遂行する。ステップ445において、アップリンク伝送は、例えばステップ430で受信したRRC制御メッセージに対する応答メッセージであり得る。以後、ステップ450において、端末405と基地局410は、バッファ状態テーブルが新たに変更される前まで新たなバッファ状態テーブルを用いてアップリンクデータ送受信を遂行する。図5は、本発明の第1の実施形態によるバッファ状態報告方法による端末の動作を示すフローチャートである。図5を参照すると、ステップ505において、端末は、基地局からキャリアを設定する制御メッセージを受信する。キャリアを設定する制御メッセージは、端末に新たなキャリアを追加に設定する制御メッセージであり、あるいは端末に設定されているキャリアを除去する制御メッセージでもあり得る。制御メッセージを受信した端末は、ステップ510で、設定追加されたアップリンクキャリアの数または設定追加されたアップリンクキャリアによる最大アップリンク伝送速度に従って使用するバッファ状態テーブルを決定する。このとき、端末と基地局は、所定の規則を適用してバッファ状態テーブルを決定する。上記規則は、例えば次のようなものとなり得る。規則1端末に設定されたアップリンクキャリアの数が1である場合、基本バッファ状態テーブルを使用。端末に設定されたアップリンクキャリアの数が2である場合、追加バッファ状態テーブル1を使用。端末に設定されたアップリンクキャリアの数がn以上である場合、追加バッファ状態テーブルn1を使用規則2端末の最大アップリンク伝送速度がx0bps以下である場合、基本バッファ状態テーブルを使用。端末の最大アップリンク伝送速度がx0bpsより大きく、x1bps以下である場合、追加バッファ状態テーブル1を使用。端末の最大アップリンク伝送速度xnbps以上である場合、追加バッファ状態テーブルnを使用ステップ505において、伝送される制御メッセージに端末が使用するバッファ状態テーブルを指示する情報が含まれることもできる。この場合、端末は、基地局が指示するバッファ状態テーブルを使用する。使用するバッファ状態テーブルを決定すると、端末は、ステップ515で、バッファ状態テーブルが変更されたか否かを確認する。すなわち、端末は、上記キャリアを設定する制御メッセージを受信することによって、以前に使用したバッファ状態テーブルと異なるバッファ状態テーブルを使用するように決定した場合、端末は、ステップ520で正規BSRをトリガする。正規BSRは、端末に格納されているデータより優先順位が高いデータが発生する場合にはトリガされるBSRであり、詳細な内容は、363221のセクション545及び6131に開示されている。以後、端末は、ステップ525で、制御メッセージで指示したようにアップリンクキャリアを設定する動作を遂行する。端末は、ステップ510で決定したバッファ状態テーブルを用いてBSRのバッファ状態値を決定する。図6は、本発明の第1の実施形態によるバッファ状態報告方法による基地局の動作を示すフローチャートである。図6を参照すると、ステップ605において、基地局は、端末に新たなアップリンクキャリアを追加的に設定することを決定する。例えば、端末のデータ要求量が増加すると、基地局は、アップリンクキャリアを追加設定できる。ステップ610において、基地局は、キャリア設定を指示する制御メッセージを生成して端末に伝送する。制御メッセージは、端末が使用すべきバッファ状態テーブルを指示する情報を含むことができる。基地局は、制御メッセージで指示された情報に基づいて端末が今後に使用するバッファ状態テーブルを判定する。また、基地局は、上記した規則1又は規則2に従って端末がどのバッファ状態テーブルを使用するかがわかる。基地局は、制御メッセージが成功的に転送される場合、ステップ615に進行する。ステップ615において、基地局は、以後に端末が伝送するBSRがステップ610で制御メッセージを通じて指示したバッファ状態テーブルを参照して生成されたものと見なし、その制御メッセージに従って変更されたバッファ状態テーブルを参照して端末が伝送するBSRを解析し、端末のバッファ状態を把握する。したがって、基地局は、変更されたバッファ状態テーブルに基づいてそのバッファ状態値から端末の実際バッファ状態を推定できる。<第2の実施形態>端末がどのバッファ状態テーブルを使用してBSRを報告するかをより明確にするために、BSRに関連情報を含めることができる。本発明の第2の実施形態においては、例えば、BSRのサブヘッダの使用しない2個のビットを用いて該当BSRのバッファ状態値が参照したバッファ状態テーブルを示す方法を提供する。本発明の第2の実施形態を説明するに先立って、BSRとMACPDUのフォーマットについてより詳しく説明する。BSRは、端末が基地局に伝送可能なデータの量を報告するMAC階層の制御情報である。MAC階層の制御情報は、MAC制御要素とも知られており、MACPDUに受納されて伝送される。BSRは、論理チャンネルグループ別に伝送可能なデータの量が書き込まれ、伝送可能なデータの量はバッファ状態テーブルのインデックスで表現される。。図7を参照すると、MACPDUは、サブヘッド部分705とペイロード部分710を含む。ペイロード部分710に示すように、複数のMACPDUは一つのMACPDUに格納され、MACPDUは、上位階層データであるRLCPDU又はMACCEである。サブヘッド部分705に示すように、MACPDU当たり一つのサブヘッダが挿入され、各サブヘッダは、該当MACPDUが生成された論理チャンネルを示す論理チャンネル識別子715、MACPDUのサイズを示す長さフィールド720を含む。MACPDUがMACCEである場合、論理チャンネル識別子715は、MACCEに格納される制御情報のタイプを指示する。現在のLTE規格において、例えば、11010はPHRを、11100~11110は各種BSRを、それぞれ指示する。参考として、BSRは、ロングBSR、ショートBSR、及び短縮BSRのような3つのタイプが定義されており、11100はロングBSRを、11101はショートBSRを、11110は短縮BSRを、各々指示する。BSRの種類に関する詳細な内容は、LTE規格で36321のセクション545及び6131に記述されているので、その詳細な説明を省略する。サブヘッド部分705は、その他にも使用しないRビット725、最後のサブヘッダであるか否かを示すEフィールド730、及びLフィールドの長さを示すFビット735を含む。本発明の第2の実施形態では、使用しないRビット725は、端末がBSRの生成に使用したバッファ状態テーブルを示すために使用される。例えば、端末と基地局は、4個のバッファ状態テーブルを有し、各バッファ状態テーブルに0~3の識別子が割り当てられる。任意のタイミングで端末の生成したBSRがバッファ状態テーブル1を用いて生成される場合、例えば図8のように、端末は、BSR805のサブヘッダのRビット810を01に設定して伝送する。すると、基地局は、BSRのサブヘッダでRビット810に基づいて端末がBSRを生成したバッファ状態テーブルを判定する。図9は、本発明の第2の実施形態によるバッファ状態報告方法による端末の動作を示すフローチャートである。図9を参照すると、ステップ905において、端末は、基地局からキャリア設定を指示する制御メッセージを受信し、ステップ910に進行して、使用するバッファ状態テーブルを決定する。ここで、所定の識別子は、バッファ状態テーブルごとに割り当てられ、識別子情報は、端末に予め設定され、あるいは端末の初期呼設定過程で端末にシグナリングされ得る。以後、端末は、BSRがトリガされるまで待機する。ステップ915において、BSRがトリガされる場合、端末は、ステップ920で、ステップ910で決定したバッファ状態テーブルを使用してBSRとサブヘッダを生成する。バスヘッダのRビットを、BSR生成の際に参照したバッファ状態テーブルの識別子に合せて設定する。BSRとサブヘッダを生成した端末は、ステップ925で、生成したBSRとサブヘッダをMACPDUに格納して伝送する。ステップ930において、端末は、BSRがトリガされるか、あるいはバッファ状態テーブルが変更されるまで待機する。以後、図9には示されていないが、ステップ930において、端末は、BSRがトリガされる場合にはステップ920に進行し、バッファ状態テーブルが変更される場合にはステップ915に進行する。上記した第2の実施形態の動作において、MACPDUは、サブヘッド部分705でRビット725を用いて端末が使用したバッファ状態テーブルを直接指示する代わり、バッファ状態テーブルの変更のみを指示する方式で変更可能である。すなわち、端末は、BSRの初期生成の際に、Rビットの値を00に初期化する。その後、バッファ状態テーブルが変更される度にRビット725の値を、例えば、1ずつ増加させることによって、現在伝送したBSRに使用されるバッファ状態テーブルが以前に使用したバッファ状態テーブルと同一であるか否かを指示できる。<第3の実施形態>周波数帯域が異なるDLCCと共に設定され、あるいは送信される位置が異なるDLCCが共に設定される場合、DLCCは、端末が体験する受信タイミングが異なる。以下、ダウンリンクキャリアをDLCC、アップリンクキャリアをULCCと称する。例えば、図10を参照すると、端末1015が、基地局1005からDLCC11020とDLCC21025を、中継器1010からDLCC31030とDLCC41035を受信する場合が考えられる。同一の位置から送信されるDLCCであっても周波数帯域が異なる場合には、端末で受信されるタイミングが微細なずれを有することがあり得る。また、送信される位置が異なる場合、DLCCの受信タイミングは、相当な差を見せることがある。例えば、図11を参照すると、同一の位置から送信されるDLCC11120とDLCC21125との間の受信タイミングの差、又はDLCC31130とDLCC41135との間の受信タイミングの差は、ダウンリンクフレームの境界を基準として基地局が指示した間隔だけ移動したタイミングで形成される。ダウンリンクフレームの境界とアップリンクフレームの境界との間の差はNTAと称し、NTAは、ランダムアクセス過程で基地局が端末に指示する。複数のDLCCが集約された場合、DLCCのフレーム境界に従って設定するULCCのフレーム境界を決定すべきである。以下、説明の便宜のために、任意のULCCのフレーム境界に対する基準タイミングを提供するDLCCは、ULCCの基準DLCCと称する。DLCCとULCCは、周波数帯域で対として定義されているので、任意のULCCと同一の周波数帯域のDLCCは、ULCCの基準DLCCとして使用することが一般的である。しかしながら、複数のULCCに対して個別的にアップリンクフレームタイミングを定義することは、端末の複雑度を増加させる問題点を引き起こすため、複数のULCCに対して一つの基準DLCCを定義する方が一層好ましい。例えば、図11を参照すると、ULCC11140はDLCC11120と、ULCC21145はDLCC21125と、ULCC31150はDLCC31130と、ULCC41155はDLCC41135と、各々同一の周波数帯域であると仮定する場合、DLCC11120とDLCC21125のフレーム境界の差1115があまり大きくない場合には、ULCC11140とULCC21145の基準DLCCとしてDLCC11120又はDLCC21125のうちいずれか一つを使用することができる。DLCC11120が基準DLCCとして使用されると、ULCC11140とULCC21145のフレーム境界は、両方ともDLCC11120を基準として調整され、その結果、ULCC11140とULCC21145は、同一のフレーム境界を有する。同様に、DLCC31130がULCC31150とULCC41155の基準DLCCとして設定される場合、ULCC31150とULCC41155のフレーム境界は、DLCC31130に基づいて調整される。したがって、上記した方式によると、図11に示すように、同一のNTA11160はULCC11140とULCC21145に適用され、NTA11160は基準DLCCであるDLCC11120のフレーム境界を基準として適用される。他のNTA21165は、ULCC31150とULCC41155には適用され、NTA21165は、基準DLCCであるDLCC31130のフレーム境界を基準として適用される。上記のようにダウンリンクフレームが正確に一致しない状態では、アップリンクグラントは、時差をおいて端末に受信される。例えば、n番目のダウンリンクサブフレームで受信されたアップリンクグラントにより生成されたMACPDUは、n4番目のアップリンクサブフレームで伝送される。同一の基準DLCCによってフレーム境界が設定されたULCCで伝送されるMACPDUに対するアップリンクグラントは、ULCCに対するアップリンクグラントが相互に異なるDLCCにより受信される場合、若干の時差をおいて端末に受信する可能性がある。例えば、図11において、ULCC11140のn4番目のサブフレームとULCC21145のn4番目のサブフレームに対するアップリンクグラントは、DLCC11120のn番目のサブフレームとDLCC21125のn番目のサブフレームで受信されるので、端末がDLCC11120でアップリンクグラントの受信を完了するタイミングとDLCC21125でアップリンクグラントの受信を完了するタイミングは異なることがある。アップリンクグラントは、ダウンリンクサブフレームのPDCCH領域で転送され、端末は、ダウンリンクサブフレームを受信した順にアップリンクグラントを認知する。また、端末は、アップリンクグラントを受信すると、すぐアップリンクグラントの内容に従って動作を遂行する。例えば、端末は、アップリンクグラントを受信すると、アップリンクグラントで割り当てられた伝送リソースを論理チャンネルの優先順位に従って論理チャンネル別に分配し、分配した伝送リソースの量によって論理チャンネルからデータを取り、取ったデータを連結してMACPDUを生成する動作を遂行する。このとき、BSRがトリガされた状態では、端末は、BSRがトリガされた後、最初のアップリンクグラントを受信する瞬間、BSRを生成するための動作、すなわちBSRのタイプを決定し、MACPDUを生成した後に残っているバッファの量を考慮してBSRで報告するバッファ状態値を決定する動作を開始する。この動作は、現在バッファに格納されている伝送可能なデータの量と割り当てられた伝送リソースの量を入力とする計算動作であるため、迅速に進行することができる。言い換えれば、図11において、DLCC11120のn番目のサブフレームで受信したアップリンクグラントに対して上記動作を完了した後、DLCC21125のn番目のサブフレームで他のアップリンクグラントを受信することもできる。したがって、端末は、n番目のサブフレームで一つ以上のアップリンクグラントを受信した場合、最初のアップリンクグラントのみを考慮してBSRのタイプとBSRで報告するバッファ状態値を決定する可能性が高い。本発明では、任意のサブフレームで一つ以上のアップリンクグラントが受信される場合、端末は、すべてのアップリンクグラントを考慮してBSRのタイプとBSRで報告するバッファ状態値を決定するようにする。例えば、図11のDLCC11120で100バイトデータの伝送を指示するアップリンクグラントを受信し、DLCC21125で100バイトデータの伝送を指示するアップリンクグラントを受信した場合、端末は、論理チャンネルグループ1のデータを200バイト、論理チャンネルグループ2のデータを200バイト格納していると仮定する。端末が、従来のようにDLCC11120で受信したアップリンクグラントのみを考慮してBSRのタイプとBSRで報告するデータの量を決定すると、ロングBSRは、論理チャンネルグループ1で100バイトを伝送した後にも論理チャンネルグループ1と論理チャンネルグループ2にデータが存在するので選択される。また、論理チャンネルグループ1に100バイトのデータが論理チャンネルグループ2に200バイトのデータが格納されていることが報告される。一方、本発明のようにDLCC11120とDLCC21125で受信したアップリンクグラントをすべて考慮すると、論理チャンネルグループ1のデータはすべて伝送され、論理チャンネルグループ2のデータのみが残るので、ショットBSRが選択され、論理チャンネルグループ2に200バイトのデータが格納されていることが報告される。後者が基地局により正確な情報を提供することは明らかである。本発明の第3の実施形態において、同一のアップリンクフレームタイミングを有するアップリンクキャリアは、一つのグループにグループ化し、同一のアップリンク伝送タイミンググループに属するアップリンクキャリアに対するアップリンクグラントを提供する可能性のあるダウンリンクキャリアをもう一つのグループにグループ化する。端末は、同一のアップリンク伝送タイミンググループに属するアップリンクキャリアのm番目のサブフレームで伝送されるBSRのフォーマットと内容を決定することにおいて、アップリンク伝送タイミンググループに対応するアップリンクグラントグループに属するダウンリンクキャリアの番目のサブフレームのPDCCH領域の受信が完了した後、m番目のサブフレームで適用されるアップリンクグラントをすべて考慮してBSRのフォーマットと内容を決定する。図11の例において、ULCC11140とULCC21145は、他のアップリンク伝送タイミンググループとして設定され、ULCC31150とULCC41155は、他のアップリンク伝送タイミンググループ、ULCC11140に対するアップリンクグラントはDLCC11120を通じて、ULCC21145に対するアップリンクグラントは、DLCC21125を通じて受信できると、DLCC11120とDLCC21125は、同一のアップリンクグラントグループに属する。同一のアップリンクグラントグループに属するダウンリンクキャリアからPDCCH受信が完了するまで待機することは、ダウンリンクキャリアのPDCCH領域から伝送される信号を受信して上記信号に関する解析を完了することを意味する。言い換えれば、アップリンクグラントがダウンリンクキャリアで受信されたか否かに対する判断が完了することを意味する。端末は、n番目のアップリンクサブフレームに対して関連したDLCCのPDCCH受信を完了すると、ステップ1215に進行して正規BSRや周期的BSRがトリガされた状態であるか否かを確認する。2つのBSRのうちいずれか一つがトリガされた場合、端末は、ステップ1230に進行する。ステップ1230において、端末は、アップリンクグラントが受信された順序に従って最初のグラントから最後の2番目のグラントまで各アップリンクグラントにより生成されるMACPDUに格納されるデータを決定する。各アップリンクグラント別に格納されるデータを決定することは、論理チャンネルの優先順位過程を遂行するとも表現し、LTE規格で36321のセクション5431に詳細に記述されている。端末は、最初のグラントから最後の2番目のグラントまで、アップリンクグラント別に論理チャンネル優先順位過程を遂行してMACPDUにどの論理チャンネルグループから何バイトのデータが受納されるかを決定すると、ステップ1235に進行する。端末は、ステップ1235で、最後のグラントを除いた残りのグラントにより生成されるMACPDUに包含されるデータの量を該当タイミングで端末が格納している伝送可能なデータの量から引いたとき、伝送可能なデータが残っている論理チャンネルグループの数に基づいてロングBSRを生成するか、あるいはショットBSRを生成するかを決定する。例えば、端末は、各々100バイトのデータ伝送を指示する2個のアップリンクグラントが受信され、論理チャンネルグループ1に100バイトのデータを、論理チャンネルグループ2に500バイトのデータを格納している。端末は、最初のグラントに対して論理チャンネル優先順位過程を遂行した結果、論理チャンネルグループ1で100バイトのデータをMACPDUに格納することに決定する場合、端末は、残っている伝送可能なデータは論理チャンネルグループ2の500バイトであるのでショットBSRを選択する。上記のように、BSRのフォーマットを決定した後、端末は、ステップ1240で、最後のMACPDUに格納されるデータの論理チャンネルグループとデータの量を決定し、ステップ1245に進行する。ステップ1245において、端末は、最後のMACPDUに受納されるデータの量を考慮してBSRで報告するデータの量空間が存在するか否かを判断し、パディングBSRを受納できる十分なパディング空間が存在してもパディングBSRを挿入しないように決定する。これは、同一のサブフレームで伝送されるMACPDUには一つのBSRのみを伝送するためである。同一のサブフレームで伝送されるとしても、MACPDUは、相互に異なるアップリンクキャリアを介して別個のHARQ過程を通じて伝送されるので、MACPDUは、相互に異なるタイミングで基地局に到着できる。これは、基地局が端末のバッファ状態を誤認する結果を招く可能性があるため、同一のアップリンクサブフレームで複数のMACPDUが伝送されるとき、一つのMACPDUのみがBSRを格納可能にする。ステップ1250に進行することは、既に周期的BSR又は正規BSRが伝送されることを意味するので、パディング空間が十分であってもパディングBSRを使用しないことを意味する。したがって、ステップ1225では、複数のMACPDUの中から一つのMACPDUにパディングBSRが格納されるが、ステップ1250では、複数のMACPDUのうちいずれにもパディングBSRが格納されないことに留意すべきである。一方、ステップ1215において、周期的BSR又は正規BSRがトリガされない場合に、端末は、ステップ1220で、受信したアップリンクグラントに対応するMACPDUに格納されるデータを決定する。ステップ1225において、端末は、パディングBSRが格納されるMACPDUがあるか否かを判定する。パディングBSRが格納されるMACPDUが複数個存在する場合、端末は、パディング空間が最も大きなMACPDUにパディングBSRを格納し、あるいは選択された一つのMACPDUにパディングBSRを格納し、残りのMACPDUにはパディングBSRを格納しないように決定する。これは、パディング空間が十分でないので、伝送可能なデータが格納された論理チャンネルグループの数が2以上にもかかわらず、ショットパディングBSRが挿入されることを防止するためである。ステップ1250又はステップ1225でパディングBSRが格納されるか否かを判定した後、端末は、ステップ1255で、MACPDUを生成して物理階層に伝送し、n番目のサブフレームで伝送されるようにする。端末は、同一のアップリンクサブフレームで伝送されるMACPDUにどの論理チャンネルグループでどのデータを格納するかの決定において、第3の実施形態の他の実施形態によって、アップリンクサブフレームに対して受信されたアップリンクグラントをすべて合算した後、合算したアップリンクグラントを用いて論理チャンネル優先順位過程を一回だけ遂行することができ、この場合にも本発明は適用可能である。このとき、端末は、論理チャンネル優先順位化過程を遂行する前にBSRのフォーマットを決定し、論理チャンネル優先順位化過程を遂行した後、BSRの内容を決定することを除けば、図12に提示された端末動作がその通り適用される。第3の実施形態の他の実施形態の動作は、図13と同様であり、図13のステップ1305,1310,1315は、図12のステップ1205,1210,1215と同一なので、その詳細な説明を省略する。図13のステップ1335において、端末は、該当タイミングに伝送可能なデータを格納している論理チャンネルグループの数を考慮してBSRのフォーマットを決定する。図13のステップ1340では、アップリンクグラントをすべて合算して論理チャンネル優先順位過程を遂行し、MACPDU別に格納するデータの論理チャンネルグループとデータの量を決定する。図13のステップ1345,1350,1355は、図12でステップ1245,1250,1255と同一なので、その詳細な説明を省略する。また、図13のステップ1320はステップ1340と同一であり、ステップ1325はステップ1225と同一である。上記した本発明の第3の実施形態を要約すると、次のようである。まず、基地局は、任意の端末に複数のアップリンクキャリアが設定されている場合、同一のアップリンクフレームタイミングを有するアップリンクキャリアを決定して端末に通知する。その後、端末は、任意のサブフレームで伝送するBSRのタイプと内容を決定することにおいて、サブフレームと同一のアップリンクフレームタイミングを有するアップリンクキャリアで転送されるすべてのMACPDUのサイズと格納されるデータの種類を考慮する。すなわち、同一のアップリンクフレームタイミングを有するアップリンクキャリアで伝送されるすべてのMACPDUにどの論理チャンネルグループでどの程度のデータが含まれるかを把握した後、BSRで報告する論理チャンネルグループ別データの量を決定する。また、同一のアップリンクフレームタイミングを有する伝送が遂行される同一のアップリンクフレームタイミングを有するアップリンクキャリアで伝送されるMACPDUのうち、パディングBSRを格納できる余分の空間のある複数のMACPDUがある場合、ステップ1225のように、端末は、複数のMACPDUの中から一つを選択した後、選択したMACPDUにのみパディングBSRを含めて残りのMACPDUの余分の空間にはパディングを含めることができる。この場合、パディングBSRは残りのMACPDUに格納されない。<第4の実施形態>端末は、基地局のスケジューリングを補助するために、PHR機能を有する。端末は、所定の条件を満たすと、MACPDUにPHRと呼ばれるMAC制御要素を格納して基地局に伝送する。PHRは、MACPDU伝送のために要求される要求伝送電力と端末の最大伝送電力との間の差を受納する。要求伝送電力は、MACPDU伝送に使用された伝送リソースの量、MCSレベル、関連したダウンリンクキャリアの経路損失などの値を考慮して計算される値であって、詳細な事項は、LTE規格で36213の511に記述されている。PHRは、PUSCHを介して伝送されるMACPDUに関連するので、以下、PUSCHPHRと称する。キャリアアグリゲーションを通じて複数のアップリンクキャリアを有する端末の場合、アップリンクキャリア別に電力ヘッドルームが異なることがあるため、PHR機能は、アップリンクキャリア別に設定することができる。その上、PHR機能は、PUCCHまで拡張することができる。PUCCH伝送の際に、端末が使用する伝送電力に関する情報を基地局が認知する場合、基地局は、PUCCHが伝送されるサブフレームでPUSCH伝送リソースを割り当てらなければならない方法をより正確に判断できる。以下、説明の便宜のために、PUCCH伝送に関連したPHRをPUCCHPHRと称する。PUCCHPHRの必要性に対して論議されているが、PUCCHPHR伝送のための様々な手順は、まだ定義されていない。本発明の第4の実施形態では、PUCCHPHR機能を特定のアップリンクキャリアのPUSCHPHR機能と連係することによって、PUCCHPHRを示す別途の論理チャンネル識別子の必要性を取り除き、PUCCHPHRトリガ条件を別に定義する煩わしさを避ける方法を提示する。PUCCHは、具体的に端末のダウンリンクチャンネル状態を報告するCQIとアップリンクHARQフィードバック情報とDSRと呼ばれる特定キャリアのみを通じて伝送される。したがって、複数のアップリンクキャリアに個別的に設定できるPUSCHPHRとは違い、PUCCHPHRはアップリンクPCCにのみ設定される。さらに、アップリンクPCCに既にPUSCHPHRが設定されていると、PUCCHPHRのトリガ条件は、PUSCHPHRのトリガ条件と連結できる。要するに、PUCCHPHRは、アップリンクPCCでPUSCHPHRがトリガされる場合に共にトリガされる。PUSCHPHRトリガ条件は、アップリンクキャリアの属性を考慮して定義されるため、PUSCHとPUCCHという異なる属性を有するチャンネルであっても、同一のキャリアで伝送される場合、同一のトリガ条件を適用しても問題とならない。最後に、PUCCHPHRを常にPUSCHPHRと共に転送されるように定義すると、PUCCHPHR用に別途の論理チャンネル識別子を使用する必要がない。例えば、図14を参照すると、任意のMACPDUにPHRMACCEが格納されている場合、すなわちサブヘッダの論理チャンネル識別子1405がPHRMACCEを指示する場合、PHRMACCEは、アップリンクPCCに対するPHRMACCEであると、図14AのようにPHRMACCEはPUSCHPHR1410とPUCCHPHR1415両方ともを格納し、PHRMACCEがアップリンクPCCに対するものでない場合、図14Bのように、PHRMACCEは、PUSCHPHR1425のみを含む。任意のPHRMACCEがどのULCCに関するものであるかを示す方法は、2つのタイプがある。第1は、PHRMACCE又はPHRMACCE用のサブヘッダで使用しないフィールドを用いてULCCの識別子を指示する方法がある。第2の方法としては、任意のULCCに対するPHRが該当ULCCのみを通じて伝送されるように制限する方法がある。したがって、第1の方法を使用すると、PHRMACCEの所定のフィールド又はPHRMACCE用のサブヘッダの所定のフィールドがアップリンクPCCを指示する場合、該当PHRMACCEにはPUSCHPHRとPUCCHPHRがすべて格納され、所定のフィールドがアップリンクPCCでなく、他のULCCを指示する場合には該当PHRMACCEにはPUSCHPHRのみが格納される。第2の方法を使用すると、ULPCCを通じて伝送されるMACPDUのPHRMACCEにはPUSCHPHRとPUCCHPHRがすべて格納され、ULPCCでない他のULCCを通じて伝送されるMACPDUのPHRMACCEにはPUSCHPHRのみが格納される。図15は、本発明の第4の実施形態による電力ヘッドルーム報告方法による端末の動作を示すフローチャートであって、任意のULCCに対するPUSCHPHRが該当ULCCでのみ伝送される場合の端末動作を示す。図15を参照すると、ステップ1505において、任意のULCCで新たな伝送を指示するアップリンク伝送リソースが割り当てられるので、新たな伝送のためのアップリンク伝送リソースは、ULCCに対して使用可能である。端末は、ステップ1510で、ULCCに対するPUSCHPHRがトリガされたか否かを確認する。PUSCHPHRは、例えば周期的PHRタイマが満了し、あるいは関連したダウンリンクキャリアの経路損失変化が所定の基準値以上である場合にトリガされる。PUSCHPHRがトリガされると、端末は、ステップ1515で、PUSCHPHRのトリガされたULCCがPCCであるか否かを確認する。その結果、PCCである場合、端末は、ステップ1520に進行する。一方、PUSCHPHRがトリガされたULCCがPCCでない場合には、端末は、ステップ1530に進行する。ステップ1520において、端末は、PUCCHPHRが設定されたか否かを確認する。PUCCHPHRは、ネットワークを格納してMACCEがPHRMACCEであることを指示する。ステップ2815において、PUCCHとPUSCHの同時伝送が可能でないと判断された場合、端末は、ステップ2820でPUSCHの電力ヘッドルームを計算し、ステップ2830でPUSCHの電力ヘッドルーム情報を包含するPHRMACCEを生成する。端末は、PHRMACCEのMACサブヘッダに所定のLCIDを格納してMACCEがPHRMACCEであることを示す。本発明の実施形態では、端末の性能や端末の設定に従って所定の端末のみがPUCCHPHRとPUSCHPHRを共に報告し、他の所定の端末はPUSCHPHRのみを報告する。また、PUCCHPHRとPUSCHPHRを共に報告する端末は、PUSCHPHRとPUCCHPHRを常に共にトリガして伝送するため、PUSCHPHとPUCCHPHを共に包含するPHRとPUSCHPHのみを包含するPHRは、両方とも同一のLCIDを使用する。言い換えれば、PUCCHPHのために別途のLCIDを使用する必要がない。ステップ2835で、端末は、MACPDUを生成して伝送する。MACPDUは、PHRMACCEを包含することもできる。<第5の実施形態>任意のアップリンクキャリアにPHR機能が設定されても、PHR機能は、該当アップリンクキャリアで常に必須ではない。例えば、任意のアップリンクキャリアとスケジューリングの側面で関連したすべてのダウンリンクキャリアが非活性状態であり、あるいはアップリンクキャリアのアップリンク伝送電力の計算のための経路損失を提供するダウンリンクキャリアのチャンネル状態が非常に不良なので、サービス不能状態であると見なされる場合、アップリンクキャリアを通じたデータ伝送は不可能である。この状況でもアップリンクキャリアのPHR機能を運営することは、タイマ駆動又はPHRトリガの可否に対する判断のような不必要な動作をもたらす。本発明の第5の実施形態では、上記のような状況では、該当アップリンクキャリアのPHR機能を一時的に中止する方法を提供する。図18は、本発明の第5の実施形態による電力ヘッドルーム報告方法による端末の動作を示すフローチャートである。図18を参照すると、ステップ1805において、端末の任意のアップリンクキャリアにPHR機能が設定される。任意のアップリンクキャリアにPHR機能が設定されるということは、キャリアに対して周期的PHRタイマ、経路損失変更基準が設定されることを意味する。端末は、周期的PHRタイマの通知されたタイマ値と経路損失変更基準を用いて該当アップリンクキャリアに対してPHRがトリガされるか否かを判定する。端末は、ステップ1810において、PHR機能が設定されたアップリンクキャリアに関連したダウンリンクキャリアを監視する。監視するダウンリンクキャリアは、該当アップリンクキャリアとスケジューリングの側面で関連したダウンリンクキャリアと経路損失の側面で関連したダウンリンクキャリアである。任意のアップリンクキャリアが任意のダウンリンクキャリアとスケジューリングの側面で関連するということは、アップリンクキャリアに対するスケジューリング命令に生成され、MACPDUに格納されて伝送される。PHRタイマは、PHRの伝送により駆動され、PHRの伝送は、PHRタイマの満了によってトリガされるので、PHRタイマの駆動とPHRの伝送は循環する因果関係を有する。しかしながら、ハンドオーバーのような理由でPHRタイマが中止されると、PHRタイマは、ハンドオーバーを完了した後、新たなPHRが伝送されない限り再駆動できない。ハンドオーバー過程で、端末は、MAC階層で駆動中であるすべてのタイマを中止する。ハンドオーバーが完了した後、中止されたPHRタイマが再駆動されない場合には、周期的PHR機能が意図と異なり中止するという結果をもたらす。従来には上記のようにハンドオーバー後にPHRタイマが再駆動できないという問題点を解決するために、ハンドオーバー後に端末が新たなセルで最初のアップリンク伝送を遂行すると、PHRタイマを駆動するように定義した。しかしながら、上記のように新たなセルで任意のキャリアで最初のアップリンク伝送を遂行した後、該当キャリアのPHRタイマを駆動する場合、PHRタイマは、設定されたアップリンクキャリアのPHRタイマがすべて再駆動するまで相当な遅延が発生し得る。これに関連して、PHRは、BSRに比べてその重要性が落ちるため、ハンドオーバーが完了すると、すぐにPHRをトリガする必要はない。それにもかかわらず、端末の電力ヘッドルームに対して如何なる情報も持っていない基地局にできるだけ速くPHRを伝送する必要がある。本発明の第6の実施形態では、このために端末がMACのリセット後に初めてアップリンク伝送を遂行すると、周期的PHR機能が設定されたすべてのアップリンクキャリアの周期的PHRタイマを共に駆動する方法を提供する。図19は、本発明の第6の実施形態による電力ヘッドルーム報告方法による端末の動作を示すフローチャートである。図19を参照すると、ステップ1905において、任意のULCCで新たな伝送を指示するアップリンク伝送リソースが割り当てられる理由で、該当ULCCに対して新たな伝送のためのアップリンク伝送リソースが使用可能になる。端末は、ステップ1910において、新たに使用可能な新たな伝送のための伝送リソースがMACリセット以後に初めて使用可能になる新たな伝送のための伝送リソースであるか否かを確認する。その結果、上記伝送リソースである場合には、端末は、ステップ1915で、周期的PHRタイマが設定されているアップリンクCCの周期的PHRタイマをすべて駆動する。このタイマは、端末がMACリセットを遂行しつつ中止させるので、MACリセット以後に再駆動しないと、周期的PHR機能が意図と違って非活性化される結果をもたらす。以後、ステップ1920において、端末は、使用可能な伝送リソースを通じて伝送するMACPDUを生成し、伝送リソースを通じてMACPDUを伝送する。ステップ1910で、MACリセット以後に最初のリソース割り当てでない場合、端末は、一般的なUL伝送を遂行する。<第7の実施形態>本発明の第7の実施形態においては、高速データ通信環境で端末のバッファ状態を基地局に効率的に報告するための方案として、新たなバッファ状態報告トリガを提供する。一つのサブフレームに多い量のデータを送信できる高速データ通信環境、例えば複数のアップリンクキャリアが集約された環境では、端末が最も最近に報告したバッファ状態は、基地局が認知できない状況で急激に変化する可能性がある。例えば、端末は1000000バイトの伝送可能なデータを格納しているとしても、バッファ状態テーブルの限界によって伝送可能なデータの量が150000バイト以上であると報告することができる。端末のチャンネル状況が非常に良好で、該当セルのロードが低くて基地局が端末に、例えば一回に150000バイトのデータ伝送を命令した場合、基地局は、端末がある程度のデータをさらに格納しているか知らないので、以後の新たなバッファ状態報告を受信する前までは端末に適切にグラントを割り当てることができない。このように、端末は、多い量のデータを伝送した後に新たなバッファ状態報告をトリガすべき必要性が増加する。第7の実施形態で提供する第1の方案では、端末が一定量以上のデータを伝送する度にバッファ状態報告をトリガする伝送量基準のトリガ方式を提供する。伝送量基準のトリガ方式は、既に一般的に使われているもので、端末が予め定められた所定の基準値以上のデータを伝送した後に所定の動作を遂行する。通常的な方式をその通り適用する場合、バッファ状態報告が不必要に頻繁に発生するという短所を有する。上記したように、本発明が解決しようとする課題は、端末のバッファ状態が最も最近報告したバッファ状態から格段に変化した場合、特に端末のバッファ状態の変化を基地局が推定できない場合にバッファ状態報告を提供するものである。したがって、一定量のデータを伝送する度にバッファ状態報告をトリガすることは、過度に多くのバッファ状態報告を発生させるという問題を発生する可能性がある。本発明の実施形態で提供する他の方案は、このような問題を補完するために、最も最近のバッファ状態報告から一定量のデータを伝送したときにバッファ状態報告をトリガする方法を提供する。例えば、伝送したデータの量を記録するカウンタを従来のようにカウント値が定められた基準値を超える場合にのみ0に初期化することでなく、他の理由であり、あるいはステップ2005で通知された値であり得る。バッファ状態報告のバッファ状態値が基準バッファ状態値のうちいずれか一つと一致する場合、伝送量基準のトリガを適用するために、端末は、ステップ2020に進行する。バッファ状態報告のバッファ状態値が基準バッファ状態のうちいずれの値とも一致しない場合、端末は、ステップ2035で、伝送量基準のトリガを非活性化する。伝送量基準のトリガを非活性化するということは、伝送量基準のトリガに関連した一切の動作、例えば端末が前述したCOUNTを管理する動作を遂行しないことを意味する。ステップ2020において、端末は、COUNTを0に初期化する。アップリンクでデータが伝送されると、データが伝送される度に伝送されたデータの量をCOUNTに累算する。図20において、カウント動作と並行して端末は、ステップ2025で、カウンタが基準値を超える前に所定のBSRがトリガされるか否かを確認する。所定のBSRは、例えばパディング空間の不足によって基地局に不完全な情報を伝送する短縮BSRを除いた残りのすべてのBSR、すなわち正規BSR、周期的BSR、パディングBSRであり得る。COUNTが基準値を超過する前に所定のBSRに該当するBSRがトリガされることは、端末が基地局に端末のバッファ状態を新たに報告することを意味するので、伝送量基準BSRをトリガする必要がなくなることを意味する。この場合、端末は、ステップ2015に進行し、伝送量基準のトリガが活性化状態であるか否かの判断動作を再開する。例えば、新たにトリガされたBSRのバッファ状態値を確認し、伝送量基準トリガを適用するか否かを判断する後続動作を遂行する。ステップ2025において、COUNTが基準値を超えるまで所定のBSRがトリガされない場合、ステップ2030において、端末は、COUNTが基準値を超えるタイミングで周期的BSRをトリガし、COUNTを0に初期化する。すると、端末は、ステップ2015に戻る。周期的BSRをトリガするということは、端末がBSRを伝送するためにスケジューリング要求信号を伝送しないことを意味する。参考のために、端末は、正規BSRがトリガされる場合、BSRを迅速に伝送するためにスケジューリング要求信号を伝送する。COUNTは、データが伝送される度に伝送されたデータの量だけ増加する。このとき、特定の論理チャンネルグループに属するデータに対してのみCOUNTを増加させることも可能である。特定の論理チャンネルグループは、例えば最も最近報告したBSRでバッファ状態値が基準バッファ状態値以上である論理チャンネルグループであり得る。上記した第7の実施形態の他の動作で、端末が最も最近報告したバッファ状態で一定比率以上のデータが伝送されると、BSRをトリガする方法が図21に示されている。図21は、本発明の第7の実施形態によるバッファ状態報告方法による端末の他の動作を示すフローチャートである。図21を参照すると、ステップ2105において、端末は、呼設定過程を通して基地局から伝送レート基準のトリガに関連したパラメータの通知を受信する。パラメータは、伝送レート基準のトリガの起動条件を定義するパラメータ、すなわち伝送レート基準と、伝送レート基準トリガの適用条件を定義するパラメータ、すなわち基準バッファ状態値を含む。伝送レート基準トリガの適用条件を定義するパラメータの代わりに基準バッファサイズを使用することができる。基準バッファ状態値は、上記したように、一種のインデックスである。場合によって、伝送レート基準トリガを適用するか否かはバッファ状態報告で報告したデータ量の和によって判断することがより望ましい。この場合、基準バッファサイズは、実際のバッファに格納されているデータをバイト単位で示す基準バッファサイズを使用する。伝送量基準のトリガの適用条件も、同様にバッファに格納されているデータをバイト単位で示す基準バッファサイズを使用することができる。ステップ2110において、端末は、バッファ状態報告が最初にトリガされるまで待機し、バッファ状態報告がトリガされる場合、ステップ2115で、伝送レート基準のトリガを適用するか否かを判定する。ステップ2115において、端末は、トリガされたバッファ状態報告のバッファ状態値が基準バッファ状態値のうちいずれか一つと一致するか、あるいはトリガされたバッファ状態報告のバッファ状態値から誘導される全体バッファ状態が基準バッファ状態以上であるかを判定する。全体バッファ状態は、バッファ状態報告のバッファ状態値から所定の規則を適用して得られる値である。例えば、端末がバッファ状態報告で論理チャンネルグループ1に対してバッファ状態値10である。基準バッファ状態が1000バイトである場合、伝送レート基準のトリガは適用されない。基準バッファ状態が200バイトである場合、伝送レート基準のトリガは適用される。ステップ2115で提示した伝送レート基準トリガを適用するか否かを判断する過程は、ステップ2115の伝送量基準のトリガを適用するか否かを判断する過程にも適用可能である。ステップ2115で伝送レート基準のトリガを適用するか否かを判断した結果、端末は、伝送レート基準トリガの適用が必要である場合にはステップ2120に進行し、伝送レート基準トリガの適用が必要でない場合にはステップ2135に進行して伝送レート基準のトリガを非活性化する。ここで、伝送レート基準トリガの非活性化は、端末が伝送レート基準トリガと関連した一切の動作、例えば伝送レート変数を管理する動作を遂行しないことを意味する。一方、伝送レート基準トリガの適用が必要な場合、ステップ2120において、端末は、伝送レート変数を0に初期化する。アップリンクにデータが伝送される度に伝送されたデータの累積値と比較値との比率を伝送レートの変数に格納する。比較値は、最も最近トリガされたバッファ状態報告で報告したデータの和である。上記動作と並行して端末は、ステップ2125で、伝送レート変数が基準値を超える前にBSRがトリガされるか否かを確認する。BSRは、例えばパディング空間の不足によって基地局に不完全な情報を伝送する短縮BSRを除いた残りのすべてのBSRであり得る。伝送レートが基準値を超える前にBSRがトリガされる場合、端末は、ステップ2115で、伝送レート基準トリガが活性化されるか否かを確認する。伝送レートが基準値を超えるまで、BSRがトリガされない場合、端末は、ステップ2130で、伝送レートが基準値を超過するタイミングで周期的BSRをトリガし、ステップ2115に戻る。上記した第7の実施形態のもう一つの動作において、所定のサイズ以上のアップリンクデータが伝送されるときは常にBSRがトリガ可能にする方法を提供する。上述したように、大きなデータが伝送されると、バッファ状態に顕著な変化、すなわちバッファ状態の急激な減少が起きるので、新たなBSRをトリガしなければならないという必要性が増加する。特に、大きなデータにBSRを格納する場合、BSRのサイズは固定されるので、BSRによるオーバーヘッドが相対的に小さい。図22は、本発明の第7の実施形態によるバッファ状態報告方法による端末のもう一つの動作を示すフローチャートである。ステップ2205において、端末は、トリガ関連のパラメータを認知する。トリガ関連パラメータは、何バイト以上のMACPDUを伝送するとき、BSRを含めなければならないか否かを指示する情報である。ステップ2210において、基地局から新たな伝送を指示するアップリンクグラントを受信する場合、端末は、ステップ2215で、新たな伝送を指示するアップリンクグラントが何バイトのMACPDUサイズの伝送を指示するか否かを確認する。そして、伝送されるMACPDUのサイズをステップ2205で認知した基準サイズと比較してMACPDUのサイズが基準サイズを超える場合、MACPDUのサイズが基準サイズより小さい場合、端末は、ステップ2225に進行して従来技術に従って動作する。<第8の実施形態>本実施形態では、要求される伝送出力が端末の最大伝送出力を超えると、端末は、伝送出力を最大伝送出力に低くして伝送する。これを伝送出力の縮小と表現する。伝送出力の縮小が発生することは、基地局が端末の伝送出力状況を誤認しているという強い証拠である。したがって、端末は、PHRを伝送して基地局に端末の伝送出力状況を通知する必要がある。特に、端末に複数のアップリンクキャリアが設定されている場合、基地局がどのアップリンクキャリアの伝送出力状況を誤認して伝送出力の縮小が発生したかが明確でないことがある。また、伝送出力の縮小が発生したサブフレームでの伝送は信頼度が格段に落ちることによって、PHR伝送が失敗する可能性も高い。すべての状況を考慮して、第8の実施形態において、端末は、任意のサブフレームで伝送出力の縮小が発生すると予想されると、サブフレームでデータ伝送が予定されたすべてのアップリンクキャリアのPHRをトリガし、伝送の信頼度を向上させるためにPHRを伝送した後、PHRを再びトリガする方法を提供する。以下の説明において、伝送出力縮小の発生は、伝送出力が不足するということと同一の意味である。図23は、本発明の第8の実施形態による電力ヘッドルーム報告方法による端末の動作を示すフローチャートである。図23を参照すると、ステップ2305において、新たな伝送のためのアップリンク伝送リソースが使用可能である場合、端末は、ステップ2310に進行する。アップリンク伝送リソースは、一つのアップリンクキャリア向けであり、あるいは複数のアップリンクキャリア向けであり得る。ステップ2310において、端末は、アップリンク伝送の際に伝送出力の縮小を発生するか否かを判定する。アップリンク伝送が複数のアップリンクキャリアを介して遂行される場合、例えばステップ2305で使用可能であるアップリンク伝送リソースがアップリンクキャリア1でXバイトのデータを伝送し、アップリンクキャリア2でYバイトのデータを伝送する場合には、各アップリンクキャリアの個別的なアップリンク伝送の要求伝送出力は、端末の最大伝送出力を超えないが、アップリンクキャリア別要求伝送出力の和は、端末の最大伝送出力を超えることによって、伝送出力の縮小が発生することもある。このように伝送出力の縮小が発生する場合、端末は、ステップ2315に進行する。ステップ2315で、端末は、伝送出力の縮小が発生するアップリンク伝送に関連したアップリンクキャリアの中で、PHRが設定されたアップリンクキャリアのPHRをトリガする。例えば、端末にアップリンクキャリア1、アップリンクキャリア2、アップリンクキャリア3が設定されている場合、すべてのアップリンクキャリアにPHRが設定されており、任意のサブフレームにアップリンクキャリア1とアップリンクキャリア2でアップリンク伝送を同時に遂行することによって伝送出力の縮小が発生する場合、端末は、アップリンクキャリア1とアップリンクキャリア2のPHRをトリガし、ステップ2330に進行する。一方、ステップ2310で、伝送出力の縮小が発生しない場合、端末は、ステップ2320で、周期的PHR又は正規PHRが発生したか否かを判定する。周期的PHRと正規PHRに対する詳細な説明は、3GPPTS36321のセクション5.4.6に規定しているので、その詳細な説明を省略する。ステップ2320において、周期的PHR又は正規PHRがトリガされない場合には、端末は、ステップ2325で、PHRを生成せずに上記手順を終了する。ステップ2320において、周期的PHRまたは正規PHRがトリガされた場合、端末は、ステップ2330で、PHRがトリガされたアップリンクキャリアに対するPHRを生成して伝送する。PHR伝送は、例えば該当アップリンクキャリアのみを介してなされることもできるので、トリガされたPHRは、相互に異なるタイミングで伝送することができる。ステップ2330において、端末は、PHRを伝送した後にステップ2335に進行して、伝送されたPHRが伝送出力の縮小によってトリガされたPHRであるか否かを確認する。トリガされたPHRであると、ステップ2340に進行し、伝送出力縮小でない他の理由でトリガされるPHRである場合にはステップ2350に進行する。ステップ2340で、端末は、伝送が完了したPHRを取消す。ステップ2345において、端末は、取り消したPHRを再びトリガして次の伝送機会にもう一回伝送されるようにする。これは、PHRが縮小した伝送出力に伝送されたため、伝送失敗が発生する可能性が高いためである。ステップ2335で伝送されたPHRが伝送出力の縮小でない他の理由でトリガされたPHRである場合、ステップ2350で、端末は、禁止タイマを駆動する。禁止タイマは、PHRが過度によく伝送されることを防止するためのもので、PHRが伝送される度に駆動され、端末は、禁止タイマが駆動される間には周期的PHR又は正規PHRをトリガしない。参考のため、伝送出力の縮小により発生したPHRに対してはPHRが伝送された後、禁止タイマを駆動する動作は遂行されない。これは、禁止タイマの主目的が従来の周期的PHR又は正規PHRがよく発生することを防ぐためのものであるため、従来のPHRとは異なる重要度を有する伝送出力の縮小によるPHRを禁止タイマと独立に駆動するためである。<第9の実施形態>端末に複数のキャリアが設定されているとき、端末は、電力消耗を低減させるためにキャリアのうち一部のみを活性化状態で駆動し、残りは非活性化状態を維持する。キャリア活性化及び非活性化は、基地局が伝送するMAC階層の制御メッセージによって制御される。MAC階層制御メッセージは、所定のビットマップを含み、ビットマップでプライマリキャリアを除いた残りのキャリアの状態を指示する。一方、キャリアのうちいずれか一つのキャリアは、プライマリキャリアとして指定され、プライマリキャリアは、常に活性化状態を維持する特徴を有する。基地局は、必要に応じて端末のプライマリキャリアを変更できる。ビットマップのビットとキャリアとの間のマッピング関係は、例えばキャリアを設定する制御メッセージで設定することができる。例えば、端末にキャリア1、キャリア2、キャリア3が設定されており、キャリア1がプライマリキャリアであることを仮定した場合、基地局は、端末にキャリア2とキャリア3を設定する制御メッセージにキャリア2がビットマップの何番目のビットに対応し、キャリア3がビットマップの何番目のビットに対応するかを指示できる。端末のプライマリキャリアが変更される場合、基地局は、以前のプライマリキャリアがビットマップの何番目のビットと対応するかを指示すべきである。端末に設定されているキャリアの集合を設定キャリア集合と称する場合、プライマリキャリアが変更される場合には、以前プライマリキャリアと新たなプライマリキャリアがすべて設定キャリア集合に属する場合とそうでない場合に区分できる。プライマリキャリアの変更が、通常、ロードバランシングの面で遂行される可能性が高いという点を考慮すれば、第1のタイプに属するプライマリキャリアの変更がさらに頻繁になると予想される。第1のタイプのプライマリキャリアの変更は、以前プライマリキャリアと新たなプライマリキャリア両方ともが予め設定されているキャリアであるため、新たなプライマリキャリアが使用したビット位置が使用可能である。言い換えれば、このようなタイプのプライマリキャリアの変更手順では、以前プライマリキャリアのビット位置として、新たなプライマリキャリアのビット位置を使用することができる。例えば、プライマリキャリアが、キャリア1からキャリア2に変更される場合、キャリア2に既に割り当てられたビット位置がある場合に、端末は、キャリア1のビット位置としてキャリア2が使用したビット位置を使用する。図24は、本発明の実施形態によるプライマリキャリア変更方法を示すフローチャートである。図24を参照すると、ステップ2405において、端末は、基地局からプライマリキャリアを変更する制御メッセージを受信する。参考として、キャリアとセルは相互に異なる概念であるが、3GPP規格では、キャリアアグリゲーションと関連してよく混用される。本発明でも、特別な言及がない限り、キャリアとセルは同一の文脈で理解すべきである。端末は、プライマリキャリア変更メッセージの指示に従ってプライマリキャリアを変更する。ステップ2410において、端末は、制御メッセージに以前プライマリキャリアのビット位置に関する情報があるか否かを確認する。上記情報がある場合、端末は、ステップ2420に進行して、指示されたビット位置を以前プライマリキャリアに対応させる。ビット位置に関する情報は、該当キャリアがビットマップの何番目のビットであるかを指示する情報である。制御メッセージに以前プライマリキャリアのビット位置に関する情報がない場合、端末は、ステップ2415で、制御メッセージを通じて新たなプライマリキャリアとなるキャリアのビット位置を確認し、この確認したキャリアのビット位置を以前プライマリキャリアのビット位置として設定する。<第10の実施形態>図25は、本発明の第10の実施形態による電力ヘッドルーム報告方法による端末のもう一つの動作を示すフローチャートであって、本実施形態では端末がキャリアアグリゲーションと関連した複数のキャリアのPHRを処理する手順を提供する。一つの端末に複数のアップリンクキャリアが集約され、それぞれのキャリアにPHR機能が設定される場合、一つの端末は複数のキャリアに対してPHRを発生したか否かを確認しなければならない。上記したように、PHRの発生有無は、周期的タイマと経路損失変化の量によって判断される。適時にPHRを基地局に伝送するという側面では、アップリンクキャリア別に独立に周期的タイマと経路損失の基準値を設定する。しかしながら、現在キャリアアグリゲーション動作が適用されると予想される周波数バンドを考慮すると、アップリンクキャリア別経路損失の差が大きくないことがある。したがって、複数のアップリンクキャリアの中で選択されたアップリンクキャリア一つに対してのみPHRがトリガされたか否かを判断し、選択されたアップリンクキャリアに対してPHRがトリガされる場合、PHRが設定されたすべてのアップリンクキャリアのPHRを共にトリガされると、端末動作を単純化できる。このとき、トリガされたPHRを同時に伝送する場合、PHRトリガ、PHR発生、及びPHR伝送がすべてのアップリンクキャリアに対して一括的に管理されて端末の複雑度が格段に減少される。このために、任意のPHRがどのアップリンクキャリアに対するPHRであるかを示す必要がある。例えば、現在PHRには使用しない2ビットがあり、この2ビットを用いてPHRに対応するアップリンクキャリアを指示することが可能である。この場合、一つの問題は、端末に集約できるアップリンクキャリアが、例えば最大5個であるため、2ビットでは各PHRがどのアップリンクキャリアに対するPHRであるかを表現できないということである。本発明の実施形態では、上記の問題を解決するために、PHRをプライマリキャリア用PHRとセカンダリキャリア用PHRに区分する。例えば、LTEシステムでは、キャリアアグリゲーションで端末が利用できるキャリアには一つのプライマリキャリアと最大4個のセカンダリキャリアが存在するという点を考慮して、セカンダリキャリア用PHRを新たに定義すると、セカンダリキャリア用PHRの使用しない2ビットで任意のセカンダリキャリア用PHRがどのセカンダリキャリアに対するものであるかを指示できる。一方、図25を参照すると、PHRは、MAC制御要素、現在規格で使用しない論理チャンネル識別子、例えば11001をセカンダリキャリア用論理チャンネル識別子2655として使用することができる。ここで、プライマリキャリア用PHR2635のペイロード2610の1番目の2ビットにはプライマリキャリアのPHが受納される。本発明の第4の実施形態で提示したように、プライマリキャリア用PHR2635のペイロード2610は、2バイトで構成され、プライマリキャリアのPUSCH用PHはそのペイロード2610の1番目のバイト2620に格納され、PUCCH用PHが2番目のバイト2625に格納され得る。セカンダリキャリア用PHR2670のペイロード2650の1番目の2ビット2660には該当PHRがどのセカンダリキャリアに対するものであるかを示す情報が格納され、そのペイロードの残り6ビット2665にはセカンダリキャリアのPHが書き込まれる。複数のセカンダリキャリアのPHは、セカンダリキャリア用PHR2670に格納されることもできる。例えば、セカンダリキャリアの識別子2660とセカンダリキャリアのPH2665は、セカンダリキャリア用PHR2670のペイロード2650の各バイト別に格納できる。このとき、セカンダリキャリアのPHR2670のペイロード2650のサイズは、受納されたセカンダリキャリアのPHの個数に従って可変的なので、セカンダリキャリアに対するPHR2670のサイズを明示的に表示する必要がある。セカンダリキャリアに対するPHR2670のサイズは、例えばMACサブヘッダ2645の使用しない2ビットを用いて、そのサイズを指示できる。図27は、本発明の第10の実施形態による電力ヘッドルーム報告方法を示すフローチャートである。図27を参照すると、一つのプライマリキャリアと複数のセカンダリキャリアが集約された端末2705と基地局2710を仮定する場合、ステップ2715で、基地局2710は、所定の制御メッセージを用いて端末2705にPHR設定情報を伝送する。PHR設定情報は、経路損失変化、周期的PHRタイマ、禁止PHRタイマ、PHRトリガリングの可否を判断するキャリアコンポーネント、及び上記セカンダリキャリアPHR2670で使用するセカンダリキャリアの識別子2660のうち少なくとも一つを含む。禁止PHRタイマである。PHRトリガリングの可否が判断されるトリガリングCCは、ダウンリンクCCであり、基地局が直接指示するか、端末と基地局との間に所定の決定することができる。例えば、プライマリCCを用いてPHRトリガリングの可否を判断できる。セカンダリキャリアの識別子2660は、例えば、0~3の4個すべてが定義され、セカンダリキャリア別に直接指示され、あるいは他の情報から推定類推することができる。例えば、キャリア別にもう一つの用途の識別子が割り当てられる場合、その割り当てられた識別子のサイズ順にPHR向けのセカンダリキャリア識別子が所定の方式で割り当てられることができる。または、キャリアの中心周波数順に、高い周波数から低い周波数に、又はその逆順にPHR向けのセカンダリキャリア識別子が割り当てられることができる。図27のステップ2720で、端末は、ステップ2715で基地局から上記PHR設定情報を受信すると、PHR設定情報に基づいてPHRがトリガされたか否かを判定する。PHRのトリガリングに対する判定は、PHRトリガリングの可否が判定されるダウンリンクキャリアの経路損失変化が所定の基準値を超えるか、あるいは周期的タイマが満了したかに基づいて遂行される。ステップ2725で任意のタイミングでPHRがトリガされる場合、ステップ2730で、端末は、最も早いタイミングで伝送されるMACPDUにPHRを含めて伝送する。このとき、PHRは、プライマリキャリア用のPHRとセカンダリキャリア用のPHRを含む。セカンダリキャリア用のPHRは、一つ又は複数であり得る。一つのセカンダリキャリア用のPHRにすべてのセカンダリキャリアのPHを格納する場合、セカンダリキャリア用PHRのMACサブヘッダは、セカンダリキャリア用PHRのサイズを指示する情報も共に格納される。以後、ステップ2735において、基地局は、ステップ2730で端末が伝送したPHRを受信すると、端末の各キャリア別PHをステップ2730で報告された値にアップデートした後、アップリンクスケジューリング時に参照する。本発明の上記した第10の実施形態においてキャリアは、よくセルと同一の意味で理解され、プライマリキャリアはプライマリセルとして、セカンダリキャリアはセカンダリセルとして理解され得る。図29は、本発明の実施形態による端末の構成を示すブロック構成図である。図29の端末は、送受信部2905、制御部2910、マルチプレクサ及びデマルチプレクサ2920、制御メッセージ処理部2935、及び各種上位階層処理部2925,2930を含む。図29において、送受信部2905は、ダウンリンクキャリアでデータ及び所定の制御信号を受信し、アップリンクキャリアでデータ及び所定の制御信号を伝送する。複数のキャリアが設定された場合、送受信部2905は、複数のキャリアでデータ送受信及び制御信号送受信を遂行する。マルチプレクサ及びデマルチプレクサ2920は、上位階層処理部2925,2930又は制御メッセージ処理部2935で発生したデータを多重化したり、送受信部2905から受信したデータを逆多重化して適切な上位階層処理部2925,2930又は制御メッセージ処理部2935に伝送する。マルチプレクサ及びデマルチプレクサ2920は、制御部2910から受信した制御メッセージ、例えばBSR又はPHRをMACPDUに多重化する。制御メッセージ処理部2935は、ネットワークにより伝送された制御メッセージを処理して必要な動作を遂行する。このとき、制御メッセージ処理部2935は、制御メッセージに格納されたキャリア関連情報を制御部2910に伝送する。上位階層処理部2925,2930は、サービス別に構成でき、FTPやVoIPのようなユーザーサービスで発生するデータを処理してマルチプレクサ及びデマルチプレクサ2920に伝送するか、あるいはマルチプレクサ及びデマルチプレクサ2920から受信したデータを処理して上位階層のサービスアプリケーションに伝送する。制御部2910は、送受信部2905を通じて受信されたスケジューリング命令、例えばアップリンクグラントを解析し、適切なタイミングで適切な伝送リソースでアップリンク伝送が遂行されるように、送受信部2905とマルチプレクサ及びデマルチプレクサ2920を制御する。また、制御部2910は、BSR又はPHRのようなスケジューリング情報を適切なタイミングで生成してマルチプレクサ及びデマルチプレクサ2920に伝送する。すなわち、制御部2910は、上記した第1の実施形態から第3の実施形態、及び第7の実施形態で説明した方法の中で所定の方法に従ってBSRが遂行されるように制御する。すなわち、制御部2910は、BSRの生成条件が満足されると、BSRの生成に使用するバッファ状態テーブルを決定し、同一のサブフレームに対して複数のアップリンクグラントが受信される場合、どのタイミングで論理チャンネル優先順位化過程に進行し、いつBSRフォーマットとBSRのバッファ状態値を決定するかを判定する。また、制御部2910は、上記した第4の実施形態から第6の実施形態、及び第8の実施形態と第10の実施形態で説明した方法の中で所定の方法によってPHRが遂行されるように制御する。すなわち制御部2910は、PUSCH用電力ヘッドルーム情報のトリガ可否をアップリンクキャリア別に判定する。制御部2910は、任意のアップリンクキャリアに対するPHRMACCEの生成において、PUCCH用電力ヘッドルーム情報も共に格納するか否かを判定する。制御部2910は、任意のアップリンクキャリアに対するPHR機能の活性化の可否を判定する。制御部2910は、アップリンク伝送のためのアップリンクグラントを受信すると、PHR機能が設定されたアップリンクキャリアのPHRタイマを再駆動するか否かを判定する。また、制御部2910は、第9の実施形態で説明したプライマリキャリア変更方法によって基地局から受信したプライマリキャリア変更制御メッセージに従って新たな又は以前プライマリキャリアのビット位置を設定できる。図30は、本発明の実施形態による基地局の構成を示すブロック構成図である。図30を参照すると、図30の基地局装置は、送受信部3005、制御部3010、マルチプレクサ及びデマルチプレクサ3020、制御メッセージ処理部3035、各種上位階層処理部3025,3030、及びスケジューラ3040を含む。送受信部3005は、アップリンクキャリアでデータ及び所定の制御信号を受信し、ダウンリンクキャリアでデータ及び所定の制御信号を伝送する。複数のキャリアが設定された場合、送受信部3005は、複数のキャリアでデータ送受信及び制御信号送受信を遂行する。マルチプレクサ及びデマルチプレクサ3020は、上位階層処理部3025,3030又は制御メッセージ処理部3035で発生したデータを多重化したり、送受信部3005から受信したデータを逆多重化して適切な上位階層処理部3025,3030又は制御メッセージ処理部3035に伝送する。マルチプレクサ及びデマルチプレクサ3020は、制御部3010から受信した制御メッセージ、例えばBSR又はPHRをMACPDUから逆多重化して制御部3010に伝送する。制御メッセージ処理部3035は、所定の制御メッセージを生成してマルチプレクサ及びデマルチプレクサ3020に伝送したり、マルチプレクサ及びデマルチプレクサ3020から受信した制御メッセージを処理する動作を遂行する。制御メッセージ処理部3035は、例えば任意の端末にキャリアを追加に設定する制御メッセージを生成してマルチプレクサ及びデマルチプレクサ3020に伝送できる。例えば、上位階層処理部3025,3030は、特定端末別に各々のサービスで構成でき、FTP又はVoIPのようなユーザーサービスで発生するデータを処理してマルチプレクサ及びデマルチプレクサ3020に伝送し、あるいはマルチプレクサ及びデマルチプレクサ3020から受信したデータを処理して上位階層のサービスアプリケーションに伝送する。また、制御部3010は、BSRとPHRのようなスケジューリング情報を解析してスケジューラ3040に端末のバッファ状態又は電力ヘッドルームを通知する。上記した第1の実施形態から第3の実施形態、及び第7の実施形態で説明した方法の中で所定の方法でBSRが遂行されるように制御する。すなわち、制御部3010は、受信したBSRがどのバッファ状態テーブルに基づいて構成されるかを判断し、BSRから端末に格納された伝送可能なデータの量と伝送可能なデータが格納された論理チャンネルグループを認知し、この情報をスケジューラ3040に通知する。制御部3010は、第4の実施形態から第6の実施形態、第8の実施形態及び第10の実施形態で説明した方法の中で所定の方法でPHRが遂行されるように制御する。制御部3010は、受信したPHRから電力ヘッドルーム情報を駆動してスケジューラ3040に通知する。マルチプレクサ及びデマルチプレクサ3020は、送受信部3005から受信したMACPDUのサブヘッダを確認して適切な上位階層処理部3025,3030に伝送する。マルチプレクサ及びデマルチプレクサ3020は、MACPDUにBSR又はPHRが格納されている場合、格納された情報を制御部3010に伝送する。マルチプレクサ及びデマルチプレクサ3020は、PCCに対するPHRが格納されたMACPDUを受信すると、ペイロード部分からPUSCHに対する電力ヘッドルーム情報とPUCCHに対する電力ヘッドルーム情報ともを包含するPHRMACCEを逆多重化して制御部3010に伝送する。スケジューラ3040は、端末のバッファ状態、チャンネル状態などを考慮して端末別に伝送リソースを割り当て、伝送フォーマットを決定する動作を遂行する。また、制御部3010は、第9の実施形態で説明したプライマリキャリア変更方法によって端末にプライマリキャリア変更制御メッセージを伝送し、端末が新たな又は以前プライマリキャリアのビット位置を設定可能なようにする。"