JP6363129B2 - 移動通信システムにおけるスケジューリング情報を処理する方法及び装置 - Google Patents

Description

本発明は、移動通信システムにおいて複数のダウンリンクキャリア及びアップリンクキャリアが集約された端末がスケジューリング情報を処理する方法及び装置に関するものである。

一般的に、移動通信システムは、ユーザーの移動性を確保しつつ、通信を可能にする目
的で開発された。このような移動通信システムは、技術の飛躍的な発展によって音声通信
だけでなく、高速のデータ通信サービスを提供可能な段階に到達した。

近年、次世代移動通信システムのうちの一つとして、３ＧＰＰでＬＴＥ(Long Term Evolution)に対する規格作業が進行中である。ＬＴＥは、２０１０年程度の商用化を目標として現在提供されているデータ伝送レートより高い最大１００Ｍｂｐｓ程度の伝送速度を有する高速パケットベースの通信を実現する技術であって、現在規格化がほぼ完了した。ＬＴＥ規格の完了に対応して、最近ＬＴＥ通信システムに多様な新技術を適用して伝送速度をより向上させる進化したＬＴＥシステム(LTE-Advanced：ＬＴＥ-Ａ)に対する議論が本格化されている。以下、ＬＴＥシステムは、既存のＬＴＥシステムとＬＴＥ-Ａシステムを含む意味として理解すべきである。新たに導入される技術の中で代表的なものとしては、キャリア・アグリゲーション(Carrier Aggregation）が挙げられる。キャリアアグリゲーションは、端末が複数のキャリアを用いてデータを送受信する技術である。より具体的に説明すると、端末は、集約されたキャリアの所定のセル(通常、同一の基地局に属するセル)を通じてデータを送受信し、これは、すなわち端末が複数個のセルを通じてデータを送受信することと同一である。キャリアアグリゲーションは、基地局が端末に集約されるキャリア情報を伝送し(これを、‘キャリアを設定する’と称する)、以後の適切なタイミングで設定されたキャリアを活性化する手順からなる。キャリアの設定とキャリアの活性化という二元的な手順を使用する理由は、端末に集約されたすべてのキャリアに対する送受信器(transceiver)を常に駆動せずに活性化されたキャリアに対する送受信器のみを駆動することによって、端末のバッテリー消耗を最小化するためである。

一般的に、ＬＴＥシステムにおいて、端末は、アップリンクスケジューリングのために基地局にスケジューリング情報を伝送する。このスケジューリング情報は、バッファ状態報告(Buffer Status Report：ＢＳＲ)と電力ヘッドルーム報告(Power Headroom Report：ＰＨＲ)である。

しかしながら、キャリアアグリゲーションを通じて複数のキャリアが設定された端末の場合、理論的な最大アップリンク伝送速度は、設定されたキャリアの数に比例して増加する傾向があるため、従来と同一の方式でバッファ状態を報告する場合には様々な非効率をもたらす可能性がある。また、設定されたアップリンクキャリアのチャンネル属性は、アップリンクキャリアの周波数帯域に従って差があり得るので、従来と同一の方式で電力ヘッドルームを報告することは多くの非効率をもたらす可能性もある。

特表２００９−５１０８０４号公報

ZTE，Considerations on scheduling in carrier aggregation，3GPP TSG RAN WG2 Meeting #66bis R2-093886，２００９年 ６月２９日，ＵＲＬ，http://www.3gpp.org/ftp/tsg_ran/wg2_rl2/TSGR2_66bis/Docs/R2-093886.zip Samsung，MAC header format for LTE-A，3GPP TSG RAN WG2 #67 R2-094857，２００９年 ８月２４日，ＵＲＬ，http://www.3gpp.org/ftp/tsg_ran/wg2_rl2/TSGR2_67/Docs/R2-094857.zip

したがって、上記のような従来技術の問題点を解決するために、本発明の目的は、移動通信システムにおけるスケジューリング情報を効率的に処理する方法及び装置と、そのシステムを提供することにある。

本発明の他の目的は、キャリアアグリゲーションをサポートする移動通信システムにおいて、端末と基地局との間のスケジューリング情報を効率的に処理する方法及び装置と、そのシステムを提供することにある。

また、本発明の目的は、キャリアアグリゲーションをサポートする移動通信システムにおいて、端末のバッファ状態報告を効率的に遂行する方法及び装置と、そのシステムを提供することにある。

さらに、本発明の目的は、キャリアアグリゲーションをサポートする移動通信システムにおいて、端末の電力ヘッドルーム報告を効率的に遂行する方法及び装置と、そのシステムを提供することにある。

上記のような目的を達成するために、本発明の一態様によれば、キャリアアグリゲーションをサポートする移動通信システムの端末におけるスケジューリング情報を処理する方法であって、キャリアアグリゲーションによって追加されるアップリンクキャリアに関する情報を含む制御メッセージを基地局から受信するステップと、制御メッセージに含まれた情報に基づいて基地局にバッファ状態報告のために使用される新たなバッファ状態テーブルを決定するステップとを有する。

本発明の他の態様によれば、キャリアアグリゲーションをサポートする移動通信システムの端末におけるスケジューリング情報を処理する方法であって、基地局からアップリンクキャリア設定を指示する制御メッセージを受信して新たに使用されるバッファ状態テーブルを決定するステップと、バッファ状態報告(ＢＳＲ)がトリガされた場合、決定したバッファ状態テーブルの識別子とＢＳＲを含むメディアアクセス制御(ＭＡＣ)パケットデータユニット(ＰＤＵ)を生成して基地局に伝送するステップとを有する。

本発明の他の態様によれば、キャリアアグリゲーションをサポートする移動通信システムの端末におけるスケジューリング情報を処理する方法であって、基地局からサブフレームに対する新たな伝送を指示するアップリンクグラントを受信し、関連したダウンリンクキャリアから制御チャンネルを受信するステップと、バッファ状態報告がトリガされた場合、バッファ状態報告のフォーマットとバッファ状態値を決定するステップとを有する。

本発明の他の態様によれば、キャリアアグリゲーションをサポートする移動通信システムの端末におけるスケジューリング情報を処理する方法であって、アップリンクグラントを受信した後、アップリンクキャリアに対するデータチャンネル電力ヘッドルーム報告(ＰＨＲ)がトリガされたか否かを判断するステップと、データチャンネルＰＨＲがトリガされ、アップリンクキャリアがプライマリコンポーネントキャリア(ＰＣＣ)である場合、制御チャンネルＰＨＲが設定されたか否かによって制御チャンネルＰＨＲを生成して基地局に伝送するステップと、アップリンクグラントを受信した後、アップリンクキャリアに対するＰＵＳＣＨ ＰＨＲがトリガされたか否かを判断するステップと、ＰＵＳＣＨ ＰＨＲがトリガされてアップリンクキャリアがＰＣＣである場合、ＰＵＣＣＨ ＰＨＲが設定されたか否かによってＰＵＣＣＨ ＰＨＲを生成して基地局に伝送するステップとを有する。

本発明の他の態様によれば、キャリアアグリゲーションをサポートする移動通信システムの端末におけるスケジューリング情報を処理する方法であって、基地局から新たな伝送のためのアップリンクリソースの割り当てを受信するステップと、新たな伝送のためのアップリンクリソースがＭＡＣリセット以後に最初に割り当てられたアップリンクリソースである場合、周期的ＰＨＲタイマが設定されているアップリンクキャリアの周期的ＰＨＲタイマを駆動させるステップとを有する。

本発明の他の態様によれば、キャリアアグリゲーションをサポートする移動通信システムの端末におけるスケジューリング情報を処理する方法であって、基地局からバッファ状態報告をトリガするためのパラメータを受信してトリガを活性化するステップと、トリガされたバッファ状態報告のバッファ状態値が基準バッファ状態値を満たすか否かを確認するステップと、バッファ状態値が基準バッファ状態値を満たす場合、所定の基準トリガを適用するステップとを有する。

本発明の他の態様によれば、キャリアアグリゲーションをサポートする移動通信システムの端末におけるスケジューリング情報を処理する方法であって、アップリンク伝送の際に、伝送出力の縮小が発生するか否かを判定するステップと、伝送出力の縮小が発生した場合、アップリンクキャリアの中から電力ヘッドルーム報告(ＰＨＲ)が設定されたアップリンクキャリアのＰＨＲをトリガするステップを有する。

本発明の他の態様によれば、キャリアアグリゲーションをサポートする移動通信システムの端末におけるスケジューリング情報を処理する方法であって、基地局から電力ヘッドルーム報告(ＰＨＲ)設定情報を含む制御メッセージを受信してＰＨＲがトリガされるか否かを判定するステップと、ＰＨＲがトリガされると、プライマリキャリア用ＰＨＲとセカンダリキャリア用ＰＨＲを含むパケットデータユニット(ＰＤＵ)を基地局に伝送するステップとを有する。

本発明が適用されるＬＴＥシステムの構成を示す図である。 本発明が適用されるＬＴＥシステムにおける無線プロトコルの構成を示す図である。 端末におけるキャリアアグリゲーションを説明するための図である。 本発明の第１の実施形態によるバッファ状態報告方法のフローを示す図である。 本発明の第１の実施形態によるバッファ状態報告方法による端末の動作を示すフローチャートである。 本発明の第１の実施形態によるバッファ状態報告による基地局の動作を示すフローチャートである。 本発明の第２の実施形態によるバッファ状態報告方法に適用されるＭＡＣ ＰＤＵの構成を示す図である。 本発明の第２の実施形態によるバッファ状態報告方法を説明するための図である。 本発明の第２の実施形態によるバッファ状態報告方法による端末の動作を示すフローチャートである。 本発明の第３の実施形態によるバッファ状態報告方法による端末に複数のキャリアが設定される一例を示す図である。 本発明の第３の実施形態によるバッファ状態報告方法による端末のダウンリンクサブフレームとアップリンクサブフレームのタイミングを示す図である。 本発明の第３の実施形態によるバッファ状態報告方法による端末の動作を示すフローチャートである。 本発明の第３の実施形態によるバッファ状態報告方法による端末の他の実施形態の動作を示すフローチャートである。 本発明の第４の実施形態による電力ヘッドルーム報告方法を説明するための図である。 本発明の第４の実施形態による電力ヘッドルーム報告方法を説明するための図である。 本発明の第４の実施形態による電力ヘッドルーム報告方法による端末の動作を示すフローチャートである。 本発明の第４の実施形態による電力ヘッドルーム報告方法の他の実施形態において、端末の動作を示すフローチャートである。 本発明の第４の実施形態による電力ヘッドルーム報告方法による基地局の動作を示すフローチャートである。 本発明の第５の実施形態による電力ヘッドルーム報告方法による端末の動作を示すフローチャートである。 本発明の第６の実施形態による電力ヘッドルーム報告方法による端末の動作を示すフローチャートである。 本発明の第７の実施形態によるバッファ状態報告方法による端末の動作を示すフローチャートである。 本発明の第７の実施形態によるバッファ状態報告方法による端末の他の動作を示すフローチャートである。 本発明の第７の実施形態によるバッファ状態報告方法による端末の他の動作を示すフローチャートである。 本発明の第８の実施形態による電力ヘッドルーム報告方法による端末のその他の動作を示すフローチャートである。 本発明の第９の実施形態によるプライマリキャリア変更方法を示すフローチャートである。 本発明の第１０の実施形態による電力ヘッドルーム報告方法を説明するための図である。 本発明の第１０の実施形態による電力ヘッドルーム報告方法を説明するための図である。 本発明の第１０の実施形態による電力ヘッドルーム報告方法を説明するための図である。 本発明の第４の実施形態による電力ヘッドルーム報告方法の他の実施形態において、端末の動作を示すフローチャートである。 本発明の実施形態による端末の構成を示すブロック構成図である。 本発明の実施形態による基地局の構成を示すブロック構成図である。

以下、本発明の望ましい実施形態を添付の図面を参照して詳細に説明する。
下記の説明で、本発明に関連した公知の機能又は構成に関する具体的な説明が本発明の要旨を不明にすると判断された場合に、その詳細な説明を省略する。

本発明は、複数のキャリアが集約された端末がＢＳＲ機能とＰＨＲ機能を遂行する方法及び装置に関するものである。本発明を本格的に説明するに先立ち、図１、図２、及び図３を通じてＬＴＥシステムについてより詳細に説明する。

図１は、本発明が適用されるＬＴＥシステムの構成を示す。
図１を参照すると、図示のように、ＬＴＥシステムの無線アクセスネットワークは、次世代基地局(Evolved Node B：以下、‘ＥＮＢ’又は‘Ｎｏｄｅ Ｂ’と称する)１０５，１１０，１１５，１２０と、ＭＭＥ(Mobility Management Entity)１２５と、Ｓ‐ＧＷ(Serving‐Gateway）１３０とを含む。ユーザー端末(User Equipment：以下、‘ＵＥ’と称する)１３５は、ＥＮＢ１０５〜１２０及びＳ‐ＧＷ１３０を通じて外部ネットワークにアクセスする。

図１において、ＥＮＢ１０５〜１２０は、ＵＭＴＳシステムの既存ノードＢに対応する。ＥＮＢは、ＵＥ１３５と無線チャンネルで接続され、既存ノードＢより複雑な役割を遂行する。ＬＴＥシステムにおいては、インターネットプロトコルを通したＶｏＩＰ(Voice over IP)のようなリアルタイムサービスだけでなく、すべてのユーザートラフィックが共有チャンネル(shared channel)を介してサービスされるため、ＵＥのバッファ状態、電力ヘッドルーム状態、チャンネル状態のような状態情報を集めてスケジューリングを遂行する装置が必要であり、ＥＮＢ１０５〜１２０は、これを担当する。一つのＥＮＢは、通常、複数のセルを制御する。例えば、１００Ｍｂｐｓの伝送速度を実現するために、ＬＴＥシステムは、例えば、２０ＭＨｚ帯域幅で直交周波数分割多重(Orthogonal Frequency Division Multiplexing：ＯＦＤＭ）方式を無線アクセス技術として使用する。また、端末のチャンネル状態に応じて変調方式(modulation scheme）とチャンネル符号化率(channel coding rate）を決定する適応変調符号化(Adaptive Modulation & Coding：ＡＭＣ)方式を適用する。Ｓ-ＧＷ１３０は、データベアラを提供する装置であり、ＭＭＥ１２５の制御によってデータベアラを生成又は除去する。ＭＭＥは、端末に対する移動性管理機能だけでなく各種制御機能を担当する装置であって、複数の基地局に接続される。

図２は、本発明が適用されるＬＴＥシステムにおける無線プロトコル構造を示す。

図２を参照すると、ＬＴＥシステムの無線プロトコルは、端末とＥＮＢで各々ＰＤＣＰ(Packet Data Convergence Protocol)２０５，２４０、ＲＬＣ(Radio Link Control)２１０，２３５、ＭＡＣ(Medium Access Control)２１５，２３０を含む。ＰＤＣＰ(Packet Data Convergence Protocol)２０５，２４０は、ＩＰヘッダの圧縮/復元の動作を遂行し、無線リンク制御(Radio Link Control：ＲＬＣ)２１０，２３５は、ＰＤＣＰ ＰＤＵ(Packet Data Unit)を適切なサイズで再構成してＡＲＱ動作などを遂行する。ＭＡＣ２１５，２３０は、一つの端末に構成された数個のＲＬＣ階層装置と接続され、ＭＡＣ ＰＤＵにＲＬＣ ＰＤＵを多重化し、ＭＡＣ ＰＤＵからＲＬＣ ＰＤＵを逆多重化する動作を遂行する。ＭＡＣ２１５，２３０は、ＢＳＲの生成及び伝送、ＰＨＲの生成及び伝送を遂行する。物理階層２２０，２２５は、上位階層データをチャンネル符号化及び変調してＯＦＤＭシンボルに生成して無線チャンネルを介して伝送し、無線チャンネルを介して受信したＯＦＤＭシンボルを復調してチャンネル復号化して上位階層に伝送する。伝送に基づいてプロトコルエンティティに入力されるデータをＳＤＵ(Service Data Unit)と称し、プロトコルエンティティから出力されるデータをＰＤＵ(Protocol Data Unit)と称する。

図３は、端末においてキャリアアグリゲーションを説明するための図である。

図３を参照すると、一つの基地局では、一般的に複数の周波数帯域にわたって複数のキャリアが送信及び受信される。例えば、ＥＮＢ３０５から中心周波数がｆ１であるキャリア３１５と中心周波数がｆ３であるキャリアが送信される場合、従来からは一つの端末が２つのキャリアのうちいずれか一つを用いてデータを送受信した。しかしながら、キャリアアグリゲーション能力を有する端末は、複数のキャリアから同時にデータを送受信することができる。基地局３０５は、キャリアアグリゲーション能力を持っている端末３３０に対して、状況に従ってより多くのキャリアを割り当てることによって、端末３３０の伝送速度を増加させることができる。従来の意味では、一つの基地局で送受信される一つのダウンリンクキャリアと一つのアップリンクキャリアが一つのセルを構成すると仮定すれば、キャリアアグリゲーションは、端末が同時に複数のセルを通してデータを送受信することがわかる。このように、最大伝送速度は、集約されるキャリアの数に比例して増加する。以下、本発明の説明において、端末が任意のダウンリンクキャリアを介してデータを受信し、あるいは任意のアップリンクキャリアを介してデータを伝送することは、キャリアを特徴づける中心周波数と周波数帯域に対応するセルで提供する制御チャンネルとデータチャンネルを介してデータを送受信することと同一の意味を有する。また、以下、本発明の実施形態はＬＴＥシステムを仮定して説明されるが、本発明は、キャリアアグリゲーションをサポートする各種無線通信システムに適用可能である。

下記の実施形態の中で、＜第１の実施形態＞から＜第３の実施形態＞、＜第７の実施形態＞は、端末が基地局に伝送するスケジューリング情報のうち、バッファ状態報告(ＢＳＲ）を効率的に遂行する方法に関するものであり、＜第４の実施形態＞から＜第６の実施形態＞、＜第８の実施形態＞、＜第１０の実施形態＞は、上記状態情報のうち電力ヘッドルーム報告(ＰＨＲ）を効率的に遂行する方法に関するものである。＜第９の実施形態＞は、制御メッセージによるプライマリキャリア変更方法に関するものである。下記の実施形態は、すべてキャリアアグリゲーションにおけるスケジューリング情報を伝送する方法に関する。

＜第１の実施形態＞
本発明の第１の実施形態では、端末が適切なバッファ状態報告テーブルを選択してバッファ状態を報告する方法及び装置を提供する。より詳細に説明すると、端末と基地局は、各々複数のバッファ状態テーブルを有し、端末に設定されているアップリンクキャリアの数、あるいは他の所定の条件を考慮して適切なバッファ状態テーブルを選択する方法及び装置を提供する。

端末は、所定の条件が満足される場合にはＢＳＲをトリガし、アップリンク伝送が可能となる場合にはＢＳＲを生成して伝送する。ＢＳＲトリガ条件については、後述する。ＢＳＲは、端末のバッファ状態を報告するために使用する所定のフォーマットを有するＭＡＣ制御情報であって、簡単に言えば、端末の論理チャンネルグループ別に伝送可能なデータの量を示す情報である。論理チャンネルは、所定の上位階層データをサービスするために生成されるチャンネルである。また、論理チャンネルは、サービスデータを処理するために構成されるＰＤＣＰ階層とＰＤＣＰ階層で処理され、この論理チャンネルごとに伝送バッファが備えられる。論理チャンネルは、一般的にユーザーサービスごとに一つずつ設定され、マッピングされたサービスの要求品質を満たすために優先順位が与えられる。論理チャンネルは、最大１１個が設定可能であり、ＬＴＥシステムでは、最大１１個の論理チャンネル別にバッファ状態を個別的に報告する代わり、同様な優先順位を有する論理チャンネルをグループ化した論理チャンネルグループ別にバッファ状態を報告する。論理チャンネルグループ別に格納されている伝送可能なデータの量は、バッファ状態値を示す６ビットの情報で表現される。バッファ状態値は、所定の最小値と所定の最大値との間でバッファ状態値の個数だけを対数的に(logarithmically)サンプリングした値である。バッファ状態値の最大値は、端末が最大伝送速度で伝送する状況で所定のバッファ状態報告の遅延を仮定したとき、伝送が断絶なしに進行されるように設定した値である。例えば、端末の最大速度がｘｂｐｓで、ｙｓｅｃがバッファ状態報告の伝送に要求されると、バッファ状態の最大値は、ｘとｙの積である。端末の最大伝送速度を決定する要素は、端末固有の性能又は任意のタイミングで端末に設定されているアップリンクキャリアの数である。この中で設定されたアップリンクキャリアの数は、端末の最大伝送速度に大きい影響を及ぼし、与えられた端末性能において、１個のアップリンクキャリアを用いてｚｂｐｓの伝送速度が可能であると、ｚ＊ｎｂｐｓの伝送速度は、ｎ個のアップリンクキャリアを用いて可能である。本発明では、複数のバッファ状態テーブルを定義し、端末が使用できるアップリンクキャリアの最大個数に従って端末と基地局は、適切なバッファ状態テーブルを使用してバッファ状態報告を遂行する。

参考のために、従来は、０バイト〜１５００００バイト間のバッファ状態を指示するバッファ状態テーブルを使用した。以下、説明の便宜のために、従来から使用されてきたバッファ状態テーブルを基本バッファ状態テーブルとして称する。下記の＜表１＞は、３ＧＰＰ規格３６.３２１の２００９年１２月バージョンのセクション６.１.３.１にある基本バッファ状態テーブルである。以下、本発明において、規格３６.３２１は、規格３６.３２１の２００９年１２月バージョンと呼ばれることを理解するものとする。＜表１＞は、基本バッファ状態テーブルの一例を示し、本発明では基本バッファ状態テーブルが下記の＜表１＞に限定されるものではない。

本発明の第１の実施形態において、端末と基地局は、＜表１＞のような基本バッファ状態テーブルを包含して複数のバッファ状態テーブルを有する。この端末と基地局は、所定の規則を適用して任意のタイミングで複数のバッファ状態テーブルの中から使用するバッファ状態テーブルを決定する。所定の規則は、例えば該当タイミングで設定されるアップリンクキャリアの数となり得る。基本バッファ状態テーブル以外に追加的に提供されるバッファ状態テーブルは、端末の最大伝送速度に合せて定義することができる。例えば、端末に設定可能なアップリンクキャリアの個数がｎ個であると、端末は、バッファ状態の最大値が基本バッファ状態テーブルの２倍であるバッファ状態テーブル、３倍であるバッファ状態テーブルなど、すべてｎ個の追加的なバッファ状態テーブルを有することができる。もしくは、端末は、過度に多くの数のバッファ状態テーブルを有する代わりに、制限された数、例えば２個又は３個のバッファ状態テーブルのみを有することもできる。便宜上、端末と基地局は、基本バッファ状態テーブル、追加バッファ状態テーブル１、及び追加バッファ状態テーブル２の３個のバッファ状態テーブルを有すると仮定する。追加バッファ状態テーブル１は、端末に設定されたアップリンクキャリアの数が２個である場合を仮定して定義されたものであり、最大バッファ報告値は３０００００バイトである。追加バッファ状態テーブル２は、端末に設定されたアップリンクキャリアの数が３個以上である場合のために定義されたものであり、最大バッファ報告値は１５０００００バイトである。追加バッファ状態テーブル１と追加状態バッファ状態テーブル２の例を下記の＜表２＞と＜表３＞に各々示す。以下、本発明では、端末が基本バッファ状態テーブル、追加バッファ状態テーブル１、及び追加バッファ状態テーブル２を有すると仮定する。しかしながら、端末と基地局は、より多い数のバッファ状態テーブルを有するか、あるいは少ない数のバッファ状態テーブルを有することができる。

図４は、本発明の第１の実施形態によるバッファ状態報告方法のフローを示す。

図４を参照すると、端末４０５は、ステップ４１５で、ＲＲＣ接続設定過程を遂行した後、キャリアが追加に割り当てられる前までステップ４２０で、従来のＬＴＥ端末と同一の方式で基地局４１０と通信を遂行する。すなわち、端末４０５と基地局４１０は、一般的なＬＴＥ端末の場合と同様に、一つのダウンリンクキャリアと一つのアップリンクキャリアでダウンリンクデータとアップリンクデータを送受信する。この場合、設定されたアップリンクキャリアの数が一つであるので、端末４０５と基地局４１０は、基本バッファ状態テーブルを使用する(ステップ４２５)。この後、ステップ４３０で、任意のタイミングで端末４０５のトラフィックが増加すると、基地局４１０は、端末４０５に新たなキャリアを追加すること(Carrier Aggregation(CA) Addition）を決定する。基地局４１０は、端末４０５に所定のＲＲＣメッセージを制御メッセージとして伝送し、このＲＲＣメッセージは、新たに追加されるアップリンクキャリアに関連した情報、例えばキャリア中心周波数及び帯域幅情報を含む。端末４０５は、新たに追加されるアップリンクキャリアの数を参照して以後に使用するバッファ状態テーブルを決定する。例えば、端末４０５に一つのアップリンクキャリアが新たに追加されて端末４０５が２個のアップリンクキャリアが設定されると、端末４０５は、追加バッファ状態テーブル１を使用する。または、端末４０５に２個のアップリンクキャリアが新たに追加されて端末４０５に総３個のアップリンクキャリアが設定される場合、端末４０５は、追加バッファ状態テーブル２を使用する。

他の実施形態において、端末は、設定されたアップリンクキャリアの数でなく、追加されたアップリンクキャリアによる端末の最大アップリンク伝送速度を参照して使用するバッファ状態テーブルを決定することができる。ここで、最大アップリンク伝送速度は、アップリンク帯域幅、伝送アンテナの数、及び変調方式を因子(factor)により定義される関数である。端末４０５と基地局４１０は、最大アップリンク伝送速度がｘｂｐｓ以下である場合には基本バッファ状態テーブルを、ｘｂｐｓとｙｂｐｓとの間である場合には追加バッファ状態テーブル１を、ｙｂｐｓ以上である場合には追加バッファ状態テーブル２を使用することとして予め定められ得る。最大アップリンク伝送速度は、アップリンクキャリア別に算出された後に合算できる。任意のアップリンクキャリアｘ(ＵＬ ＣＣ ｘ）の最大伝送速度は、例えば下記の＜数式１＞を用いて計算 できる。

＜数式１＞
ＵＬ ＣＣ ｘの最大データレート＝（ＵＬ ＣＣ ｘのＢＷ）×（ＵＬ ＣＣ ｘの最大スペクトル効率）
ＵＬ ＣＣ ｘの最大スペクトル効率＝（最大変調次数）×（ＵＬ ＣＣ ｘに対するアンテナ数）

端末４０５は、設定されたアップリンクキャリアの帯域幅、ＭＩＭＯ設定可否(例えば、該当キャリアで使用するアンテナの個数)、最大変調次数を用いてアップリンクキャリア別最大伝送速度を計算し、アップリンクキャリア別に計算された値を合算してアップリンクキャリアの最大伝送速度の総合を計算する。

端末４０５は、設定又は追加されたアップリンクキャリアによる最大アップリンク伝送速度の値が対応するバッファ状態テーブルを確認し、その後に使用するバッファ状態テーブルを決定する。上記のように、端末４０５は、アップリンクキャリア設定状況を考慮してバッファ状態テーブルを自分自身で決定する代わり、基地局４１０が端末４０５にどのバッファ状態テーブルを使用するかを直接指示することができる。ここで、使用されるバッファ状態テーブルを指示する情報は、キャリアを新たに追加するために、ステップ４３０で伝送される制御メッセージ(例えば、ＲＲＣメッセージ)に含まれることができる。端末４０５は、ＲＲＣメッセージを受信して新たなバッファ状態テーブルを使用しなければいけないことを認知すると、ステップ４３５で、ＢＳＲをトリガして所定の手順を通してトリガされたＢＳＲを伝送する。ＢＳＲをトリガする理由は、バッファ状態テーブルの変更の際に発生し得る不確実性を除去するためである。例えば、端末４０５は、新たなバッファ状態テーブルを適用する直前に以前のバッファ状態テーブルを使用したＢＳＲを伝送した場合、基地局４１０は、ＢＳＲが新たなバッファ状態テーブルに基づいたものであるか、あるいは以前のバッファ状態テーブルに基づいたものであるかを正確に判断できないことがある。これを解決するために、端末４０５は、バッファ状態テーブルが変更されると、正規(regular)ＢＳＲをトリガして変更されたバッファ状態テーブルを用いて基地局４１０にバッファ状態を可能な限り早く報告する。ステップ４４０で、基地局４１０は、ＢＳＲを成功的に受信すると、端末４０５にアップリンクグラントを割り当て、ステップ４４５で、端末４０５は、割り当てられたアップリンクグラントを用いてアップリンク伝送を遂行する。ステップ４４５において、アップリンク伝送は、例えばステップ４３０で受信したＲＲＣ制御メッセージに対する応答メッセージであり得る。以後、ステップ４５０において、端末４０５と基地局４１０は、バッファ状態テーブルが新たに変更される前まで新たなバッファ状態テーブルを用いてアップリンクデータ送受信を遂行する。

図５は、本発明の第１の実施形態によるバッファ状態報告方法による端末の動作を示すフローチャートである。

図５を参照すると、ステップ５０５において、端末は、基地局からキャリアを設定する制御メッセージを受信する。キャリアを設定する制御メッセージは、端末に新たなキャリアを追加に設定する制御メッセージであり、あるいは端末に設定されているキャリアを除去する制御メッセージでもあり得る。制御メッセージを受信した端末は、ステップ５１０で、設定/追加されたアップリンクキャリアの数または設定/追加されたアップリンクキャリアによる最大アップリンク伝送速度に従って使用するバッファ状態テーブルを決定する。このとき、端末と基地局は、所定の規則を適用してバッファ状態テーブルを決定する。上記規則は、例えば次のようなものとなり得る。

[規則１]
端末に設定されたアップリンクキャリアの数が１である場合、基本バッファ状態テーブルを使用。
端末に設定されたアップリンクキャリアの数が２である場合、追加バッファ状態テーブル１を使用。
端末に設定されたアップリンクキャリアの数がｎ以上である場合、追加バッファ状態テーブル[ｎ-１]を使用

[規則２]
端末の最大アップリンク伝送速度がｘ０ｂｐｓ以下である場合、基本バッファ状態テーブルを使用。
端末の最大アップリンク伝送速度がｘ０ｂｐｓより大きく、ｘ１ｂｐｓ以下である場合、追加バッファ状態テーブル１を使用。
端末の最大アップリンク伝送速度ｘｎｂｐｓ以上である場合、追加バッファ状態テーブルｎを使用

ステップ５０５において、伝送される制御メッセージに端末が使用するバッファ状態テーブルを指示する情報が含まれることもできる。この場合、端末は、基地局が指示するバッファ状態テーブルを使用する。使用するバッファ状態テーブルを決定すると、端末は、ステップ５１５で、バッファ状態テーブルが変更されたか否かを確認する。すなわち、端末は、上記キャリアを設定する制御メッセージを受信することによって、以前に使用したバッファ状態テーブルと異なるバッファ状態テーブルを使用するように決定した場合、端末は、ステップ５２０で正規ＢＳＲをトリガする。正規ＢＳＲは、端末に格納されているデータより優先順位が高いデータが発生する場合にはトリガされるＢＳＲであり、詳細な内容は、３６.３２２１のセクション５.４.５及び６.１.３.１に開示されている。以後、端末は、ステップ５２５で、制御メッセージで指示したようにアップリンクキャリアを設定する動作を遂行する。端末は、ステップ５１０で決定したバッファ状態テーブルを用いてＢＳＲのバッファ状態値を決定する。

図６は、本発明の第１の実施形態によるバッファ状態報告方法による基地局の動作を示すフローチャートである。

図６を参照すると、ステップ６０５において、基地局は、端末に新たなアップリンクキャリアを追加的に設定することを決定する。例えば、端末のデータ要求量が増加すると、基地局は、アップリンクキャリアを追加設定できる。ステップ６１０において、基地局は、キャリア設定を指示する制御メッセージを生成して端末に伝送する。制御メッセージは、端末が使用すべきバッファ状態テーブルを指示する情報を含むことができる。基地局は、制御メッセージで指示された情報に基づいて端末が今後に使用するバッファ状態テーブルを判定する。また、基地局は、上記した規則１又は規則２に従って端末がどのバッファ状態テーブルを使用するかがわかる。基地局は、制御メッセージが成功的に転送される場合、ステップ６１５に進行する。ステップ６１５において、基地局は、以後に端末が伝送するＢＳＲがステップ６１０で制御メッセージを通じて指示したバッファ状態テーブルを参照して生成されたものと見なし、その制御メッセージに従って変更されたバッファ状態テーブルを参照して端末が伝送するＢＳＲを解析し、端末のバッファ状態を把握する。したがって、基地局は、変更されたバッファ状態テーブルに基づいてそのバッファ状態値から端末の実際バッファ状態を推定できる。

＜第２の実施形態＞
端末がどのバッファ状態テーブルを使用してＢＳＲを報告するかをより明確にするために、ＢＳＲに関連情報を含めることができる。本発明の第２の実施形態においては、例えば、ＢＳＲのサブヘッダの使用しない２個のビットを用いて該当ＢＳＲのバッファ状態値が参照したバッファ状態テーブルを示す方法を提供する。本発明の第２の実施形態を説明するに先立って、ＢＳＲとＭＡＣ ＰＤＵのフォーマットについてより詳しく説明する。ＢＳＲは、端末が基地局に伝送可能なデータの量を報告するＭＡＣ階層の制御情報である。ＭＡＣ階層の制御情報は、ＭＡＣ制御要素(Control Element：ＣＥ)とも知られており、ＭＡＣ ＰＤＵに受納されて伝送される。ＢＳＲは、論理チャンネルグループ別に伝送可能なデータの量が書き込まれ、伝送可能なデータの量はバッファ状態テーブルのインデックスで表現される。(ここで、バッファ状態テーブルのインデックスは、本発明ではバッファ状態値として称する)。

図７を参照すると、ＭＡＣ ＰＤＵは、サブヘッド部分７０５とペイロード部分７１０を含む。ペイロード部分７１０に示すように、複数のＭＡＣ ＰＤＵは一つのＭＡＣ ＰＤＵに格納され、ＭＡＣ ＰＤＵは、上位階層データであるＲＬＣ ＰＤＵ又はＭＡＣ ＣＥである。サブヘッド部分７０５に示すように、ＭＡＣ ＰＤＵ当たり一つのサブヘッダが挿入され、各サブヘッダは、該当ＭＡＣ ＰＤＵが生成された論理チャンネルを示す論理チャンネル識別子７１５、ＭＡＣ ＰＤＵのサイズを示す長さフィールド(Length：Ｌ)７２０を含む。ＭＡＣ ＰＤＵがＭＡＣ ＣＥである場合、論理チャンネル識別子７１５は、ＭＡＣ ＣＥに格納される制御情報のタイプを指示する。現在のＬＴＥ規格において、例えば、１１０１０はＰＨＲを、１１１００〜１１１１０は各種ＢＳＲを、それぞれ指示する。参考として、ＢＳＲは、ロング(long)ＢＳＲ、ショート(short)ＢＳＲ、及び短縮(truncated)ＢＳＲのような３つのタイプが定義されており、１１１００はロングＢＳＲを、１１１０１はショートＢＳＲを、１１１１０は短縮ＢＳＲを、各々指示する。ＢＳＲの種類に関する詳細な内容は、ＬＴＥ規格で３６.３２１のセクション５.４.５及び６.１.３.１に記述されているので、その詳細な説明を省略する。サブヘッド部分７０５は、その他にも使用しないＲ(Reserved)ビット７２５、最後のサブヘッダであるか否かを示すＥフィールド７３０、及びＬフィールドの長さを示すＦビット７３５を含む。

本発明の第２の実施形態では、使用しないＲビット７２５は、端末がＢＳＲの生成に使用したバッファ状態テーブルを示すために使用される。例えば、端末と基地局は、４個のバッファ状態テーブルを有し、各バッファ状態テーブルに０〜３の識別子が割り当てられる。任意のタイミングで端末の生成したＢＳＲがバッファ状態テーブル１を用いて生成される場合、例えば図８のように、端末は、ＢＳＲ８０５のサブヘッダのＲビット８１０を“０１”に設定して伝送する。すると、基地局は、ＢＳＲのサブヘッダでＲビット８１０に基づいて端末がＢＳＲを生成したバッファ状態テーブルを判定する。

図９は、本発明の第２の実施形態によるバッファ状態報告方法による端末の動作を示すフローチャートである。

図９を参照すると、ステップ９０５において、端末は、基地局からキャリア設定を指示する制御メッセージを受信し、ステップ９１０に進行して、使用するバッファ状態テーブルを決定する。ここで、所定の識別子は、バッファ状態テーブルごとに割り当てられ、識別子情報は、端末に予め設定され、あるいは端末の初期呼設定過程で端末にシグナリングされ得る。以後、端末は、ＢＳＲがトリガされるまで待機する。ステップ９１５において、ＢＳＲがトリガされる場合、端末は、ステップ９２０で、ステップ９１０で決定したバッファ状態テーブルを使用してＢＳＲとサブヘッダを生成する。バスヘッダのＲビットを、ＢＳＲ生成の際に参照したバッファ状態テーブルの識別子に合せて設定する。ＢＳＲとサブヘッダを生成した端末は、ステップ９２５で、生成したＢＳＲとサブヘッダをＭＡＣＰＤＵに格納して伝送する。ステップ９３０において、端末は、ＢＳＲがトリガされるか、あるいはバッファ状態テーブルが変更されるまで待機する。以後、図９には示されていないが、ステップ９３０において、端末は、ＢＳＲがトリガされる場合にはステップ９２０に進行し、バッファ状態テーブルが変更される場合にはステップ９１５に進行する。

上記した第２の実施形態の動作において、ＭＡＣ ＰＤＵは、サブヘッド部分７０５でＲビット７２５を用いて端末が使用したバッファ状態テーブルを直接指示する代わり、バッファ状態テーブルの変更のみを指示する方式で変更可能である。すなわち、端末は、ＢＳＲの初期生成の際に、Ｒビットの値を“００”に初期化する。その後、バッファ状態テーブルが変更される度にＲビット７２５の値を、例えば、１ずつ増加させることによって、現在伝送したＢＳＲに使用されるバッファ状態テーブルが以前に使用したバッファ状態テーブルと同一であるか否かを指示できる。

＜第３の実施形態＞
周波数帯域が異なるＤＬ ＣＣ(Downlink Component Carrier)と共に設定され、あるいは送信される位置が異なるＤＬ ＣＣが共に設定される場合、ＤＬ ＣＣは、端末が体験する受信タイミングが異なる。以下、ダウンリンクキャリアをＤＬ ＣＣ、アップリンクキャリアをＵＬ ＣＣと称する。例えば、図１０を参照すると、端末１０１５が、基地局１００５からＤＬ ＣＣ１ １０２０とＤＬ ＣＣ２ １０２５)を、中継器１０１０からＤＬ ＣＣ３ １０３０とＤＬ ＣＣ４ １０３５を受信する場合が考えられる。同一の位置から送信されるＤＬ ＣＣであっても周波数帯域が異なる場合には、端末で受信されるタイミングが微細なずれを有することがあり得る。また、送信される位置が異なる場合、ＤＬＣＣの受信タイミングは、相当な差を見せることがある。例えば、図１１を参照すると、同一の位置から送信されるＤＬ ＣＣ１ １１２０とＤＬ ＣＣ２ １１２５との間の受信タイミングの差(参照番号１１１５)、又はＤＬ ＣＣ３ １１３０とＤＬ ＣＣ４ １１３５との間の受信タイミングの差(参照番号１１１０）は、あまり大きくない反面、送信される位置が異なるＤＬ ＣＣ、例えばＤＬ ＣＣ１ １１２０とＤＬ ＣＣ３ １１３０との間の受信タイミングの差(参照番号１１０５）は、かなり大きい。アップリンクフレームの境界(boundary)は、ダウンリンクフレームの境界を基準として基地局が指示した間隔だけ移動したタイミングで形成される。ダウンリンクフレームの境界とアップリンクフレームの境界との間の差はＮ_ＴＡ(N_Timing Advance)と称し、Ｎ_ＴＡは、ランダムアクセス過程で基地局が端末に指示する。複数のＤＬ ＣＣが集約された場合、ＤＬ ＣＣのフレーム境界に従って設定するＵＬ ＣＣのフレーム境界を決定すべきである。

以下、説明の便宜のために、任意のＵＬ ＣＣのフレーム境界に対する基準タイミングを提供するＤＬ ＣＣは、ＵＬ ＣＣの基準ＤＬ ＣＣと称する。ＤＬ ＣＣとＵＬ ＣＣは、周波数帯域で対として定義されているので、任意のＵＬ ＣＣと同一の周波数帯域のＤＬ ＣＣは、ＵＬ ＣＣの基準ＤＬ ＣＣとして使用することが一般的である。しかしながら、複数のＵＬ ＣＣに対して個別的にアップリンクフレームタイミングを定義することは、端末の複雑度を増加させる問題点を引き起こすため、複数のＵＬ ＣＣに対して一つの基準ＤＬ ＣＣを定義する方が一層好ましい。

例えば、図１１を参照すると、ＵＬ ＣＣ１ １１４０はＤＬ ＣＣ１ １１２０と、ＵＬ ＣＣ２ １１４５はＤＬ ＣＣ２ １１２５と、ＵＬ ＣＣ３ １１５０はＤＬ ＣＣ３ １１３０と、ＵＬ ＣＣ４ １１５５はＤＬ ＣＣ４ １１３５と、各々同一の周波数帯域であると仮定する場合、ＤＬ ＣＣ１ １１２０とＤＬ ＣＣ２ １１２５のフレーム境界の差１１１５があまり大きくない場合には、ＵＬ ＣＣ１ １１４０とＵＬ ＣＣ２ １１４５の基準ＤＬ ＣＣとしてＤＬ ＣＣ１ １１２０又はＤＬ ＣＣ２ １１２５のうちいずれか一つを使用することができる。ＤＬ ＣＣ１ １１２０が基準ＤＬ ＣＣとして使用されると、ＵＬ ＣＣ１ １１４０とＵＬ ＣＣ２ １１４５のフレーム境界は、両方ともＤＬ ＣＣ１ １１２０を基準として調整され、その結果、ＵＬ ＣＣ１ １１４０とＵＬ ＣＣ２１１４５は、同一のフレーム境界を有する。同様に、ＤＬ ＣＣ３ １１３０がＵＬ ＣＣ３ １１５０とＵＬ ＣＣ４ １１５５の基準ＤＬ ＣＣとして設定される場合、ＵＬ ＣＣ３ １１５０とＵＬ ＣＣ４ １１５５のフレーム境界は、ＤＬ ＣＣ３ １１３０に基づいて調整される。したがって、上記した方式によると、図１１に示すように、同一のＮ_ＴＡ１ １１６０はＵＬ ＣＣ１ １１４０とＵＬ ＣＣ２ １１４５に適用され、Ｎ_ＴＡ１ １１６０は基準ＤＬ ＣＣであるＤＬ ＣＣ１ １１２０のフレーム境界を基準として適用される。他のＮ_ＴＡ２ １１６５は、ＵＬ ＣＣ３ １１５０とＵＬ ＣＣ４ １１５５には適用され、Ｎ_ＴＡ２ １１６５は、基準ＤＬ ＣＣであるＤＬ ＣＣ３ １１３０のフレーム境界を基準として適用される。

上記のようにダウンリンクフレームが正確に一致しない状態では、アップリンクグラントは、時差をおいて端末に受信される。例えば、ｎ番目のダウンリンクサブフレームで受信されたアップリンクグラントにより生成されたＭＡＣ ＰＤＵは、[ｎ＋４]番目のアップリンクサブフレームで伝送される。同一の基準ＤＬ ＣＣによってフレーム境界が設定されたＵＬ ＣＣで伝送されるＭＡＣ ＰＤＵに対するアップリンクグラントは、ＵＬ ＣＣに対するアップリンクグラントが相互に異なるＤＬ ＣＣにより受信される場合、若干の時差をおいて端末に受信する可能性がある。例えば、図１１において、ＵＬ ＣＣ１ １１４０の[ｎ＋４]番目のサブフレームとＵＬ ＣＣ２ １１４５の[ｎ＋４]番目のサブフレームに対するアップリンクグラントは、ＤＬ ＣＣ１ １１２０のｎ番目のサブフレームとＤＬ ＣＣ２１１２５のｎ番目のサブフレームで受信されるので、端末がＤＬ ＣＣ１１１２０でアップリンクグラントの受信を完了するタイミングとＤＬ ＣＣ２ １１２５でアップリンクグラントの受信を完了するタイミングは異なることがある。アップリンクグラントは、ダウンリンクサブフレームのＰＤＣＣＨ(Physical Downlink Control Channel)領域で転送され、端末は、ダウンリンクサブフレームを受信した順にアップリンクグラントを認知する。また、端末は、アップリンクグラントを受信すると、すぐアップリンクグラントの内容に従って動作を遂行する。例えば、端末は、アップリンクグラントを受信すると、アップリンクグラントで割り当てられた伝送リソースを論理チャンネルの優先順位に従って論理チャンネル別に分配し、分配した伝送リソースの量によって論理チャンネルからデータを取り、取ったデータを連結してＭＡＣ ＰＤＵを生成する動作を遂行する。このとき、ＢＳＲがトリガされた状態では、端末は、ＢＳＲがトリガされた後、最初のアップリンクグラントを受信する瞬間、ＢＳＲを生成するための動作、すなわちＢＳＲのタイプを決定し、ＭＡＣ ＰＤＵを生成した後に残っているバッファの量を考慮してＢＳＲで報告するバッファ状態値を決定する動作を開始する。この動作は、現在バッファに格納されている伝送可能なデータの量と割り当てられた伝送リソースの量を入力とする計算動作であるため、迅速に進行することができる。言い換えれば、図１１において、ＤＬ ＣＣ１ １１２０のｎ番目のサブフレームで受信したアップリンクグラントに対して上記動作を完了した後、ＤＬ ＣＣ２ １１２５のｎ番目のサブフレームで他のアップリンクグラントを受信することもできる。

したがって、端末は、ｎ番目のサブフレームで一つ以上のアップリンクグラントを受信した場合、最初のアップリンクグラントのみを考慮してＢＳＲのタイプとＢＳＲで報告するバッファ状態値を決定する可能性が高い。本発明では、任意のサブフレームで一つ以上のアップリンクグラントが受信される場合、端末は、すべてのアップリンクグラントを考慮してＢＳＲのタイプとＢＳＲで報告するバッファ状態値を決定するようにする。

例えば、図１１のＤＬ ＣＣ１ １１２０で１００バイトデータの伝送を指示するアップリンクグラントを受信し、ＤＬ ＣＣ２ １１２５で１００バイトデータの伝送を指示するアップリンクグラントを受信した場合、端末は、論理チャンネルグループ１のデータを２００バイト、論理チャンネルグループ２のデータを２００バイト格納していると仮定する。端末が、従来のようにＤＬ ＣＣ１ １１２０で受信したアップリンクグラントのみを考慮してＢＳＲのタイプとＢＳＲで報告するデータの量を決定すると、ロングＢＳＲは、論理チャンネルグループ１で１００バイトを伝送した後にも論理チャンネルグループ１と論理チャンネルグループ２にデータが存在するので選択される。また、論理チャンネルグループ１に１００バイトのデータが論理チャンネルグループ２に２００バイトのデータが格納されていることが報告される。一方、本発明のようにＤＬ ＣＣ１ １１２０とＤＬ ＣＣ２ １１２５で受信したアップリンクグラントをすべて考慮すると、論理チャンネルグループ１のデータはすべて伝送され、論理チャンネルグループ２のデータのみが残るので、ショットＢＳＲが選択され、論理チャンネルグループ２に２００バイトのデータが格納されていることが報告される。後者が基地局により正確な情報を提供することは明らかである。

本発明の第３の実施形態において、同一のアップリンクフレームタイミングを有するアップリンクキャリアは、一つのグループ(以下、アップリンク伝送タイミンググループ)にグループ化し、同一のアップリンク伝送タイミンググループに属するアップリンクキャリアに対するアップリンクグラントを提供する可能性のあるダウンリンクキャリアをもう一つのグループ(以下、アップリンクグラントグループ)にグループ化する。端末は、同一のアップリンク伝送タイミンググループに属するアップリンクキャリアのｍ番目のサブフレームで伝送されるＢＳＲのフォーマットと内容を決定することにおいて、アップリンク伝送タイミンググループに対応するアップリンクグラントグループに属するダウンリンクキャリアの(ｍ-４)番目のサブフレームのＰＤＣＣＨ領域の受信が完了した後、ｍ番目のサブフレームで適用されるアップリンクグラントをすべて考慮してＢＳＲのフォーマットと内容を決定する。図１１の例において、ＵＬ ＣＣ１ １１４０とＵＬ ＣＣ２ １１４５は、他のアップリンク伝送タイミンググループ(アップリンク伝送タイミンググループ１)として設定され、ＵＬ ＣＣ３ １１５０とＵＬ ＣＣ４ １１５５は、他のアップリンク伝送タイミンググループ(アップリンク伝送タイミンググループ２）として設定され得る。アップリンクスケジューリングの観点で、ＵＬ ＣＣ１ １１４０はＤＬ ＣＣ１ １１２０と、ＵＬ ＣＣ２ １１４５はＤＬ ＣＣ２ １１２５と、ＵＬ ＣＣ３ １１５０はＤＬ ＣＣ３ １１３０と、ＵＬ ＣＣ４ １１５５はＤＬ ＣＣ４ １１３５と、各々相互に関連されていると、本発明の第３の実施形態により、アップリンク伝送タイミンググループ１に対応するアップリンクグラントグループはＤＬ ＣＣ１ １１２０とＤＬ ＣＣ２ １１２５を含み、アップリンク伝送タイミンググループ２に対応するアップリンクグラントグループはＤＬ ＣＣ３ １１３０とＤＬ ＣＣ４ １１３５を含む。

図１２は、本発明の第３の実施形態によるバッファ状態報告方法による端末の動作を示すフローチャートである。

図１２を参照すると、ステップ１２０５において、任意のｎ番目のアップリンクサブフレームに対する新たな伝送(new transmission）を指示するアップリンクグラントを受信すると、端末は、ステップ１２１０に進行する。ステップ１２１０において、端末は、アップリンクグラントが受信されたダウンリンクキャリアと同一のアップリンクグラントグループに属するすべてのダウンリンクキャリアからＰＤＣＣＨの受信が完了するまで待機する。上記したように、キャリア設定メッセージの制御メッセージを用いて、基地局は、最初の情報として端末に同一のアップリンク伝送タイミングを有するアップリンクキャリアを指示する。基地局は、２番目の情報として端末にアップリンクキャリア別にアップリンクグラントが受信されるダウンリンクキャリアを指示する。端末は、２つの情報を用いて、同一のアップリンクグラントグループに属するダウンリンクキャリアを認識する。端末は、同一のアップリンク伝送タイミングを有するアップリンクキャリアに対するアップリンクグラントが送受信可能なダウンリンクキャリアを、同一のアップリンクグラントグループに属するダウンリンクキャリアとして認識する。例えば、図１１において、ＵＬ ＣＣ１ １１４０とＵＬ ＣＣ２ １１４５は同一のアップリンク伝送タイミングを共有し(すなわち、同一のアップリンクフレーム境界を有し)、ＵＬ ＣＣ１ １１４０に対するアップリンクグラントはＤＬ ＣＣ１ １１２０を通じて、ＵＬ ＣＣ２ １１４５に対するアップリンクグラントは、ＤＬ ＣＣ２ １１２５を通じて受信できると、ＤＬ ＣＣ１ １１２０とＤＬ ＣＣ２ １１２５は、同一のアップリンクグラントグループに属する。同一のアップリンクグラントグループに属するダウンリンクキャリアからＰＤＣＣＨ受信が完了するまで待機することは、ダウンリンクキャリアのＰＤＣＣＨ領域から伝送される信号を受信して上記信号に関する解析を完了することを意味する。言い換えれば、アップリンクグラントがダウンリンクキャリアで受信されたか否かに対する判断が完了することを意味する。

端末は、ｎ番目のアップリンクサブフレームに対して関連したＤＬ ＣＣのＰＤＣＣＨ受信を完了すると、ステップ１２１５に進行して正規ＢＳＲや周期的ＢＳＲがトリガされた状態であるか否かを確認する。２つのＢＳＲのうちいずれか一つがトリガされた場合、端末は、ステップ１２３０に進行する。ステップ１２３０において、端末は、アップリンクグラントが受信された順序に従って最初のグラントから最後の２番目(one before the last)のグラントまで各アップリンクグラントにより生成されるＭＡＣ ＰＤＵに格納されるデータを決定する(例えば、図１１において、同一のアップリンクサブフレームに対してＤＬ ＣＣ１ １１２０で送受信されるアップリンクグラントがＤＬ ＣＣ２ １１２５で送受信されたアップリンクグラントより速く受信されるので、ＤＬ ＣＣ１ １１２０で受信されたアップリンクグラントが最初のグラントであり、ＤＬ ＣＣ２ １１２５で受信されたアップリンクグラントが最後のグラントである)。各アップリンクグラント別に格納されるデータを決定することは、論理チャンネルの優先順位過程を遂行するとも表現し、ＬＴＥ規格で３６.３２１のセクション５.４.３.１に詳細に記述されている。端末は、最初のグラントから最後の２番目のグラントまで、アップリンクグラント別に論理チャンネル優先順位過程を遂行してＭＡＣ ＰＤＵにどの論理チャンネルグループから何バイトのデータが受納されるかを決定すると、ステップ１２３５に進行する。端末は、ステップ１２３５で、最後のグラントを除いた残りのグラントにより生成されるＭＡＣ ＰＤＵに包含されるデータの量を該当タイミングで端末が格納している伝送可能なデータの量から引いたとき、伝送可能なデータが残っている論理チャンネルグループの数に基づいてロングＢＳＲを生成するか、あるいはショットＢＳＲを生成するかを決定する。例えば、端末は、各々１００バイトのデータ伝送を指示する２個のアップリンクグラントが受信され、論理チャンネルグループ１に１００バイトのデータを、論理チャンネルグループ２に５００バイトのデータを格納している。端末は、最初のグラントに対して論理チャンネル優先順位過程を遂行した結果、論理チャンネルグループ１で１００バイトのデータをＭＡＣＰＤＵに格納することに決定する場合、端末は、残っている伝送可能なデータは論理チャンネルグループ２の５００バイトであるのでショットＢＳＲを選択する。上記のように、ＢＳＲのフォーマットを決定した後、端末は、ステップ１２４０で、最後のＭＡＣ ＰＤＵに格納されるデータの論理チャンネルグループとデータの量を決定し、ステップ１２４５に進行する。ステップ１２４５において、端末は、最後のＭＡＣ ＰＤＵに受納されるデータの量を考慮してＢＳＲで報告するデータの量(バッファ状態値）を決定する。すなわち、論理チャンネルグループ別に現在端末が格納している伝送可能なデータから、最後のＭＡＣ ＰＤＵを含むすべてのＭＡＣ ＰＤＵに格納されるデータの量を引いた値に対応するバッファ状態値を選択する。端末は、ステップ１１２５０で、各ＭＡＣ ＰＤＵにパディング(padding)空間が存在するか否かを判断し、パディングＢＳＲを受納できる十分なパディング空間が存在してもパディングＢＳＲを挿入しないように決定する。これは、同一のサブフレームで伝送されるＭＡＣ ＰＤＵには一つのＢＳＲのみを伝送するためである。同一のサブフレームで伝送されるとしても、ＭＡＣ ＰＤＵは、相互に異なるアップリンクキャリアを介して別個のＨＡＲＱ過程を通じて伝送されるので、ＭＡＣ ＰＤＵは、相互に異なるタイミングで基地局に到着できる。これは、基地局が端末のバッファ状態を誤認する結果を招く可能性があるため、同一のアップリンクサブフレームで複数のＭＡＣ ＰＤＵが伝送されるとき、一つのＭＡＣ ＰＤＵのみがＢＳＲを格納可能にする。ステップ１２５０に進行することは、既に周期的ＢＳＲ又は正規ＢＳＲが伝送されることを意味するので、パディング空間が十分であってもパディングＢＳＲを使用しないことを意味する。したがって、ステップ１２２５では、複数のＭＡＣ ＰＤＵの中から一つのＭＡＣ ＰＤＵにパディングＢＳＲが格納されるが、ステップ１２５０では、複数のＭＡＣ ＰＤＵのうちいずれにもパディングＢＳＲが格納されないことに留意すべきである。

一方、ステップ１２１５において、周期的ＢＳＲ又は正規ＢＳＲがトリガされない場合に、端末は、ステップ１２２０で、受信したアップリンクグラントに対応するＭＡＣ ＰＤＵに格納されるデータを決定する。ステップ１２２５において、端末は、パディングＢＳＲが格納されるＭＡＣ ＰＤＵがあるか否かを判定する。パディングＢＳＲが格納されるＭＡＣ ＰＤＵが複数個存在する場合、端末は、パディング空間が最も大きなＭＡＣ ＰＤＵにパディングＢＳＲを格納し、あるいは選択された一つのＭＡＣ ＰＤＵにパディングＢＳＲを格納し、残りのＭＡＣ ＰＤＵにはパディングＢＳＲを格納しないように決定する。これは、パディング空間が十分でないので、伝送可能なデータが格納された論理チャンネルグループの数が２以上にもかかわらず、ショットパディングＢＳＲが挿入されることを防止するためである。ステップ１２５０又はステップ１２２５でパディングＢＳＲが格納されるか否かを判定した後、端末は、ステップ１２５５で、ＭＡＣ ＰＤＵを生成して物理階層に伝送し、ｎ番目のサブフレームで伝送されるようにする。

端末は、同一のアップリンクサブフレームで伝送されるＭＡＣ ＰＤＵにどの論理チャンネルグループでどのデータを格納するかの決定において、第３の実施形態の他の実施形態によって、アップリンクサブフレームに対して受信されたアップリンクグラントをすべて合算した後、合算したアップリンクグラントを用いて論理チャンネル優先順位過程を一回だけ遂行することができ、この場合にも本発明は適用可能である。このとき、端末は、論理チャンネル優先順位化過程を遂行する前にＢＳＲのフォーマットを決定し、論理チャンネル優先順位化過程を遂行した後、ＢＳＲの内容を決定することを除けば、図１２に提示された端末動作がその通り適用される。

第３の実施形態の他の実施形態の動作は、図１３と同様であり、図１３のステップ１３０５，１３１０，１３１５は、図１２のステップ１２０５，１２１０，１２１５と同一なので、その詳細な説明を省略する。図１３のステップ１３３５において、端末は、該当タイミングに伝送可能なデータを格納している論理チャンネルグループの数を考慮してＢＳＲのフォーマットを決定する。図１３のステップ１３４０では、アップリンクグラントをすべて合算して論理チャンネル優先順位過程を遂行し、ＭＡＣ ＰＤＵ別に格納するデータの論理チャンネルグループとデータの量を決定する。図１３のステップ１３４５，１３５０，１３５５は、図１２でステップ１２４５，１２５０，１２５５と同一なので、その詳細な説明を省略する。また、図１３のステップ１３２０はステップ１３４０と同一であり、ステップ１３２５はステップ１２２５と同一である。

上記した本発明の第３の実施形態を要約すると、次のようである。まず、基地局は、任意の端末に複数のアップリンクキャリアが設定されている場合、同一のアップリンクフレームタイミングを有するアップリンクキャリアを決定して端末に通知する。その後、端末は、任意のサブフレームで伝送するＢＳＲのタイプと内容を決定することにおいて、サブフレームと同一のアップリンクフレームタイミングを有するアップリンクキャリアで転送されるすべてのＭＡＣ ＰＤＵのサイズと格納されるデータの種類を考慮する。すなわち、同一のアップリンクフレームタイミングを有するアップリンクキャリアで伝送されるすべてのＭＡＣ ＰＤＵにどの論理チャンネルグループでどの程度のデータが含まれるかを把握した後、ＢＳＲで報告する論理チャンネルグループ別データの量を決定する。また、同一のアップリンクフレームタイミングを有する伝送が遂行される同一のアップリンクフレームタイミングを有するアップリンクキャリアで伝送されるＭＡＣ ＰＤＵのうち、パディングＢＳＲを格納できる余分の空間のある複数のＭＡＣ ＰＤＵがある場合、ステップ１２２５のように、端末は、複数のＭＡＣ ＰＤＵの中から一つを選択した後、選択したＭＡＣ ＰＤＵにのみパディングＢＳＲを含めて残りのＭＡＣ ＰＤＵの余分の空間にはパディングを含めることができる。この場合、パディングＢＳＲは残りのＭＡＣ ＰＤＵに格納されない。

＜第４の実施形態＞
端末は、基地局のスケジューリングを補助するために、ＰＨＲ(Power Headroom Report)機能を有する。端末は、所定の条件を満たすと、ＭＡＣ ＰＤＵにＰＨＲと呼ばれるＭＡＣ制御要素(ＣＥ)を格納して基地局に伝送する。ＰＨＲは、ＭＡＣ ＰＤＵ伝送のために要求される要求伝送電力と端末の最大伝送電力との間の差を受納する。要求伝送電力は、ＭＡＣ ＰＤＵ伝送に使用された伝送リソースの量、ＭＣＳレベル、関連したダウンリンクキャリアの経路損失などの値を考慮して計算される値であって、詳細な事項は、ＬＴＥ規格で３６.２１３の５.１.１に記述されている。ＰＨＲは、ＰＵＳＣＨ(Physical Uplink Shared Channel)を介して伝送されるＭＡＣ ＰＤＵに関連するので、以下、ＰＵＳＣＨ ＰＨＲと称する。

キャリアアグリゲーションを通じて複数のアップリンクキャリアを有する端末の場合、アップリンクキャリア別に電力ヘッドルームが異なることがあるため、ＰＨＲ機能は、アップリンクキャリア別に設定することができる。その上、ＰＨＲ機能は、ＰＵＣＣＨ(Physical Uplink Control Channel)まで拡張することができる。ＰＵＣＣＨ伝送の際に、端末が使用する伝送電力に関する情報を基地局が認知する場合、基地局は、ＰＵＣＣＨが伝送されるサブフレームでＰＵＳＣＨ伝送リソースを割り当てらなければならない方法をより正確に判断できる。以下、説明の便宜のために、ＰＵＣＣＨ伝送に関連したＰＨＲをＰＵＣＣＨ ＰＨＲと称する。ＰＵＣＣＨ ＰＨＲの必要性に対して論議されているが、ＰＵＣＣＨ ＰＨＲ伝送のための様々な手順は、まだ定義されていない。本発明の第４の実施形態では、ＰＵＣＣＨ ＰＨＲ機能を特定のアップリンクキャリアのＰＵＳＣＨ ＰＨＲ機能と連係することによって、ＰＵＣＣＨ ＰＨＲを示す別途の論理チャンネル識別子の必要性を取り除き、ＰＵＣＣＨ ＰＨＲトリガ条件を別に定義する煩わしさを避ける方法を提示する。

ＰＵＣＣＨは、具体的に端末のダウンリンクチャンネル状態を報告するＣＱＩ(Channel Quality Information)とアップリンクＨＡＲＱフィードバック情報とＤ-ＳＲ(Dedicated Scheduling Request：端末に予め割り当てられた所定の周期を有する伝送リソースを通じて伝送される信号として、端末が基地局に伝送リソース割り当てを要求する用途で使われる）と呼ぶ。ＰＵＣＣＨ信号は、端末に設定された複数のアップリンクキャリアのうち、ＰＣＣ(Primary Component Carrier)と呼ばれる特定キャリアのみを通じて伝送される。したがって、複数のアップリンクキャリアに個別的に設定できるＰＵＳＣＨ ＰＨＲとは違い、ＰＵＣＣＨ ＰＨＲはアップリンクＰＣＣにのみ設定される。さらに、アップリンクＰＣＣに既にＰＵＳＣＨ ＰＨＲが設定されていると、ＰＵＣＣＨ ＰＨＲのトリガ条件は、ＰＵＳＣＨ ＰＨＲのトリガ条件と連結できる。要するに、ＰＵＣＣＨ ＰＨＲは、アップリンクＰＣＣでＰＵＳＣＨ ＰＨＲがトリガされる場合に共にトリガされる。ＰＵＳＣＨ ＰＨＲトリガ条件は、アップリンクキャリアの属性を考慮して定義されるため、ＰＵＳＣＨとＰＵＣＣＨという異なる属性を有するチャンネルであっても、同一のキャリアで伝送される場合、同一のトリガ条件を適用しても問題とならない。最後に、ＰＵＣＣＨ ＰＨＲを常にＰＵＳＣＨ ＰＨＲと共に転送されるように定義すると、ＰＵＣＣＨ ＰＨＲ用に別途の論理チャンネル識別子を使用する必要がない。例えば、図１４を参照すると、任意のＭＡＣ ＰＤＵにＰＨＲ ＭＡＣ ＣＥが格納されている場合、すなわちサブヘッダの論理チャンネル識別子１４０５がＰＨＲ ＭＡＣ ＣＥを指示する場合、ＰＨＲ ＭＡＣ ＣＥは、アップリンクＰＣＣに対するＰＨＲ ＭＡＣ ＣＥであると、図１４ＡのようにＰＨＲ ＭＡＣ ＣＥはＰＵＳＣＨ ＰＨＲ１４１０とＰＵＣＣＨ ＰＨＲ１４１５両方ともを格納し、ＰＨＲ ＭＡＣ ＣＥがアップリンクＰＣＣに対するものでない場合、図１４Ｂのように、ＰＨＲ ＭＡＣ ＣＥは、ＰＵＳＣＨ ＰＨＲ１４２５のみを含む。任意のＰＨＲ ＭＡＣ ＣＥがどのＵＬ ＣＣに関するものであるかを示す方法は、２つのタイプがある。第１は、ＰＨＲ ＭＡＣ ＣＥ又はＰＨＲ ＭＡＣ
ＣＥ用のサブヘッダで使用しないフィールドを用いてＵＬ ＣＣの識別子を指示する方法がある。第２の方法としては、任意のＵＬ ＣＣに対するＰＨＲが該当ＵＬ ＣＣのみを通じて伝送されるように制限する方法がある。したがって、第１の方法を使用すると、ＰＨＲ ＭＡＣ ＣＥの所定のフィールド又はＰＨＲ ＭＡＣ ＣＥ用のサブヘッダの所定のフィールドがアップリンクＰＣＣを指示する場合、該当ＰＨＲ ＭＡＣ ＣＥにはＰＵＳＣＨ ＰＨＲとＰＵＣＣＨ ＰＨＲがすべて格納され、所定のフィールドがアップリンクＰＣＣでなく、他のＵＬ ＣＣを指示する場合には該当ＰＨＲ ＭＡＣ ＣＥにはＰＵＳＣＨ ＰＨＲのみが格納される。第２の方法を使用すると、ＵＬ ＰＣＣを通じて伝送されるＭＡＣ ＰＤＵのＰＨＲ ＭＡＣ ＣＥにはＰＵＳＣＨ ＰＨＲとＰＵＣＣＨ ＰＨＲがすべて格納され、ＵＬ ＰＣＣでない他のＵＬ ＣＣを通じて伝送されるＭＡＣ ＰＤＵのＰＨＲ ＭＡＣ ＣＥにはＰＵＳＣＨ ＰＨＲのみが格納される。

図１５は、本発明の第４の実施形態による電力ヘッドルーム報告方法による端末の動作を示すフローチャートであって、任意のＵＬ ＣＣに対するＰＵＳＣＨ ＰＨＲが該当ＵＬＣＣでのみ伝送される場合の端末動作を示す。

図１５を参照すると、ステップ１５０５において、任意のＵＬ ＣＣで新たな伝送を指示するアップリンク伝送リソースが割り当てられるので、新たな伝送のためのアップリンク伝送リソースは、ＵＬ ＣＣに対して使用可能である。端末は、ステップ１５１０で、ＵＬ ＣＣに対するＰＵＳＣＨ ＰＨＲがトリガされたか否かを確認する。ＰＵＳＣＨ ＰＨＲは、例えば周期的ＰＨＲタイマが満了し、あるいは関連したダウンリンクキャリアの経路損失変化が所定の基準値以上である場合にトリガされる。ＰＵＳＣＨ ＰＨＲがトリガされると、端末は、ステップ１５１５で、ＰＵＳＣＨ ＰＨＲのトリガされたＵＬ ＣＣがＰＣＣであるか否かを確認する。その結果、ＰＣＣである場合、端末は、ステップ１５２０に進行する。一方、ＰＵＳＣＨ ＰＨＲがトリガされたＵＬ ＣＣがＰＣＣでない場合には、端末は、ステップ１５３０に進行する。ステップ１５２０において、端末は、ＰＵＣＣＨ ＰＨＲが設定(configured)されたか否かを確認する。ＰＵＣＣＨ ＰＨＲは、ネットワーク(例えば、基地局）の決定に従って設定され、あるいは設定されない。ＰＵＣＣＨ ＰＨＲが設定されない場合、端末は、ＵＬ ＰＣＣに対するＰＵＳＣＨ ＰＨＲがトリガされてもＰＵＣＣＨ ＰＨＲをトリガしてはならないので、ステップ１５３０に進行する。ＰＵＣＣＨ ＰＨＲが設定された場合、端末は、ステップ１５２５で、ＰＵＳＣＨに対する電力ヘッドルーム情報とＰＵＣＣＨに対する電力ヘッドルーム情報ともを含むＰＨＲ ＭＡＣ ＣＥを生成する。ＰＵＳＣＨ電力ヘッドルーム情報とＰＵＣＣＨ電力ヘッドルーム情報は、例えば、各々１バイトサイズを有し、最初の２ビットを除いた残りの６ビットに電力ヘッドルーム情報が書き込まれることができる。ＰＨＲ ＭＡＣ ＣＥを生成した後、端末は、ステップ１５３５に進行してＭＡＣ ＰＤＵを生成する。すなわち、ＭＡＣ ＰＤＵのペイロード部分に挿入されるＭＡＣ ＰＤＵとＭＡＣサブヘッダを順に連結する。ＰＨＲ ＭＡＣ ＣＥは、ＰＵＳＣＨに対する電力ヘッドルーム情報とＰＵＣＣＨに対する電力ヘッドルーム情報がすべて格納されるため、例えば、２バイトのサイズを有する。端末は、ＰＨＲ ＭＡＣ ＣＥのＭＡＣサブヘッダにＰＨＲを指示する論理チャンネル識別子を書き込まれる。端末は、ステップ１５３０に進行すると、ＰＵＳＣＨに対する電力ヘッドルーム情報のみを格納するＰＨＲ ＭＡＣ ＣＥを生成する。ＰＵＳＣＨに対する電力ヘッドルーム情報のみを格納するＰＨＲ ＭＡＣ ＣＥは、従来と同様に、例えば、１バイトサイズを有する。ＰＨＲ ＭＡＣ ＣＥを生成した端末は、ステップ１５３５でＭＡＣ ＰＤＵを生成する。ＰＨＲ ＭＡＣ ＣＥは、例えば、１バイトのサイズを有し、ＰＨＲを指示する論理チャンネル識別子は、ＰＨＲ ＭＡＣ ＣＥのＭＡＣサブヘッダに書き込まれる。

図１６は、本発明の第４の実施形態による電力ヘッドルーム報告方法の他の実施形態で端末の動作を示すフローチャートであって、ＰＨＲ ＭＡＣ ＣＥの所定のフィールド又は該当サブヘッダの所定のフィールドにＰＨＲがどのＵＬ ＣＣに対するものであるかを指示する情報が格納される場合の端末動作を示す。

図１６を参照すると、ステップ１６０５において、任意のＵＬ ＣＣで新たな伝送を指示するアップリンク伝送リソースが割り当てられるので、該当ＵＬ ＣＣに対して新たな伝送のためのアップリンク伝送リソースが使用可能である。端末は、ステップ１６１０で、ＰＨＲ機能が設定されたＵＬ ＣＣの中で、ＰＵＳＣＨ ＰＨＲのトリガされたＵＬ ＣＣがあるか否かを確認する。ＰＵＳＣＨ ＰＨＲは、例えば周期的ＰＨＲタイマが満了し、関連したダウンリンクキャリアの経路損失変化が所定の基準値以上である場合にはトリガされる。任意のＵＬ ＣＣでＰＵＳＣＨ ＰＨＲがトリガされた場合、端末は、ステップ１６１５に進行し、ＰＵＳＣＨ ＰＨＲがトリガされたＵＬ ＣＣがＰＣＣであるか否かを確認する。その結果、上記ＵＬ ＣＣがＰＣＣである場合、端末は、ステップ１６２０に進行する。ＰＵＳＣＨＰＨＲのトリガされたＵＬ ＣＣがＰＣＣでない場合、端末は、ステップ１６３０に進行する。ステップ１６２０において、端末は、ＰＵＣＣＨ ＰＨＲが設定されたか否かを確認する。ＰＵＣＣＨ ＰＨＲは、ネットワークの決定に従って設定されたり、あるいは設定されない。ＰＵＣＣＨ ＰＨＲが設定されない場合、ＵＬ ＰＣＣに対するＰＵＳＣＨ ＰＨＲがトリガされてもＰＵＣＣＨ ＰＨＲをトリガしてはならないので、ステップ１６３０に進行する。ＰＵＣＣＨ ＰＨＲが設定された場合、端末は、ステップ１６２５で、ＰＵＳＣＨに対する電力ヘッドルーム情報とＰＵＣＣＨに対する電力ヘッドルーム情報をすべて含むＰＨＲ ＭＡＣ ＣＥを生成する。ＰＨＲ ＭＡＣ ＣＥを生成した後、端末は、ステップ１５３５でＭＡＣ ＰＤＵを生成する。すなわち、ＭＡＣ ＰＤＵのペイロード部分に挿入されるＭＡＣ ＰＤＵとＭＡＣサブヘッダを順に連結する。ＰＨＲ ＭＡＣ ＣＥは、ＰＵＳＣＨに対する電力ヘッドルーム情報とＰＵＣＣＨに対する電力ヘッドルーム情報ともを含むので、例えば２バイトのサイズを有する。ＰＨＲを指示する論理チャンネル識別子は、ＰＨＲ ＭＡＣ ＣＥのＭＡＣサブヘッダに 書き込まれる。また、ＭＡＣサブヘッダの最初の２ビットにＰＨＲ ＭＡＣ ＣＥがどのＵＬ ＣＣに対するものであるかを示す識別子を包含する。端末は、ステップ１６３０で、ＰＵＳＣＨに対する電力ヘッドルーム情報のみを格納したＰＨＲ ＭＡＣ ＣＥを生成する。ＰＵＳＣＨに対する電力ヘッドルーム情報のみを格納するＰＨＲ ＭＡＣ ＣＥは、従来と同様に、例えば１バイトサイズを有する。ＰＨＲ ＭＡＣ ＣＥを生成した端末は、ステップ１５３５で、ＭＡＣ ＰＤＵを生成する。ＰＨＲ ＭＡＣ ＣＥは、１バイトのサイズを有し、ＰＨＲ ＭＡＣ ＣＥのＭＡＣサブヘッダにはＰＨＲを指示する論理チャンネル識別子が書き込まれる。そして、ＭＡＣサブヘッダの最初の２ビットにＰＨＲ ＭＡＣ ＣＥがどのＵＬ ＣＣに対するものであるかを示す識別子を格納する。

図１７は、本発明の第４の実施形態による電力ヘッドルーム報告方法による基地局の動作を示すフローチャートである。図１７を参照すると、ステップ１７０５において、任意のＵＬ ＣＣでＭＡＣ ＰＤＵを受信すると、基地局は、ステップ１７１０で、ＭＡＣ ＰＤＵにＰＨＲ ＭＡＣ ＣＥが含まれているか否かを確認する。上記ＰＨＲ ＭＡＣ ＣＥが含まれている場合、基地局は、ステップ１７１５で、ＰＨＲ ＭＡＣ ＣＥがＵＬ ＰＣＣに対するものであるか否かを判定する。図１６の実施形態と同様にＰＨＲ ＭＡＣ ＣＥ又は該当サブヘッダに、ＰＨＲ ＭＡＣ ＣＥがどのＵＬ ＣＣに対するものであるかを示す識別子が書き込まれている場合、基地局は、識別子を確認してＰＨＲ ＭＡＣ ＣＥがＵＬＰＣＣに対するものであるか否かを判定する。図１５の実施形態のように、任意のＵＬ ＣＣに対するＰＨＲ ＭＡＣ ＣＥが該当ＵＬ ＣＣのみを通じて伝送される場合、基地局は、ＰＨＲ ＭＡＣ ＣＥの受信されたＵＬ ＣＣがＵＬ ＰＣＣであるか否かを確認してＰＨＲ ＭＡＣ ＣＥがＵＬ ＰＣＣに対するものであるか否かを判定する。ステップ１７１５の判定結果、受信したＰＨＲ ＭＡＣ ＣＥがＵＬ ＰＣＣに対するものである場合、基地局は、ステップ１７２０で、端末にＰＵＣＣＨ ＰＨＲが設定されたか否かを確認する。ＰＵＣＣＨ ＰＨＲが設定されている場合、基地局は、ステップ１７２５で、受信したＭＡＣ ＰＤＵからＰＵＳＣＨに対する電力ヘッドルーム情報とＰＵＣＣＨに対する電力ヘッドルーム情報を逆多重化し、ステップ１７３５に進行する。ステップ１７１５の判定結果、受信したＰＨＲ ＭＡＣ ＣＥがＵＬ ＰＣＣに対するものでなく、あるいはＰＵＣＣＨ ＰＨＲが設定されていない場合、基地局は、ステップ１７３０に進行し、ＭＡＣ ＰＤＵからＰＵＳＣＨに対する電力ヘッドルーム情報を逆多重化し、ステップ１７３５に進行する。以後、ステップ１７３５で、基地局は、ＭＡＣサブヘッダを解析して残りのＭＡＣ ＰＤＵを逆多重化して適切な装置に伝送する。

図２８は、本発明の第４の実施形態による電力ヘッドルーム報告方法の他の実施形態で端末の動作を示すフローチャートである。

ステップ２８０５において、端末に新たな伝送のためのアップリンク伝送リソースが割り当てられる場合、端末は、ステップ２８１０で、ＰＣｅｌｌのＰＵＳＣＨ ＰＨＲが転送されなければならないか否かを確認する。ＰＣｅｌｌは、ＴＳ３６.３００に提示されたように、プライマリキャリアと類似した意味を有する。ＰＣｅｌｌのＰＵＳＣＨ ＰＨＲが伝送されなければならないと、例えば経路損失の変化が基準値を超えるか、あるいは周期的タイマが満了した場合は、ＰＣｅｌｌのＰＵＳＣＨ ＰＨＲが伝送されなければならない場合である。ＰＣｅｌｌのＰＵＳＣＨ ＰＨＲ伝送が必要であると、端末は、ステップ２８１５に進行し、そうでないとステップ２８３５に進行する。ステップ２８１５において、端末は、ＰＵＣＣＨとＰＵＳＣＨの同時伝送が可能であるか否かを確認する。ＰＵＣＣＨとＰＵＳＣＨの同時伝送が可能であるか否かは、端末固有の能力に関連され、同時伝送は、端末に従って可能あるいは不可能である。同時伝送が可能な端末は、ＰＵＣＣＨ ＰＨＲとＰＵＳＣＨ ＰＨＲを共に報告し、ステップ２８２５に進行する。ステップ２８２５において、端末は、ＰＵＣＣＨの電力ヘッドルームとＰＵＳＣＨの電力ヘッドルームとを計算し、ステップ２８３０で、ＰＵＣＣＨの電力ヘッドルーム情報とＰＵＳＣＨの電力ヘッドルーム情報を包含するＰＨＲ ＭＡＣ ＣＥ(Control Element）を生成する。端末は、ＰＨＲ ＭＡＣ ＣＥのＭＡＣサブヘッダに所定のＬＣＩＤ(Logical Channel Identification)を格納してＭＡＣ ＣＥがＰＨＲ ＭＡＣ ＣＥであることを指示する。ステップ２８１５において、ＰＵＣＣＨとＰＵＳＣＨの同時伝送が可能でないと判断された場合、端末は、ステップ２８２０でＰＵＳＣＨの電力ヘッドルームを計算し、ステップ２８３０でＰＵＳＣＨの電力ヘッドルーム情報を包含するＰＨＲ ＭＡＣ ＣＥを生成する。端末は、ＰＨＲ ＭＡＣ ＣＥのＭＡＣサブヘッダに所定のＬＣＩＤを格納してＭＡＣ ＣＥがＰＨＲ ＭＡＣ ＣＥであることを示す。本発明の実施形態では、端末の性能や端末の設定に従って所定の端末のみがＰＵＣＣＨ ＰＨＲとＰＵＳＣＨ ＰＨＲを共に報告し、他の所定の端末はＰＵＳＣＨ ＰＨＲのみを報告する。また、ＰＵＣＣＨ ＰＨＲとＰＵＳＣＨ ＰＨＲを共に報
告する端末は、ＰＵＳＣＨ ＰＨＲとＰＵＣＣＨ ＰＨＲを常に共にトリガして伝送するため、ＰＵＳＣＨ ＰＨとＰＵＣＣＨ ＰＨを共に包含するＰＨＲとＰＵＳＣＨ ＰＨのみを包含するＰＨＲは、両方とも同一のＬＣＩＤを使用する。言い換えれば、ＰＵＣＣＨ ＰＨのために別途のＬＣＩＤを使用する必要がない。ステップ２８３５で、端末は、ＭＡＣ ＰＤＵを生成して伝送する。ＭＡＣ ＰＤＵは、ＰＨＲ ＭＡＣ ＣＥを包含することもできる。

＜第５の実施形態＞
任意のアップリンクキャリアにＰＨＲ機能が設定されても、ＰＨＲ機能は、該当アップリンクキャリアで常に必須ではない。例えば、任意のアップリンクキャリアとスケジューリングの側面で関連したすべてのダウンリンクキャリアが非活性状態であり、あるいはアップリンクキャリアのアップリンク伝送電力の計算のための経路損失を提供するダウンリンクキャリアのチャンネル状態が非常に不良なので、サービス不能状態であると見なされる場合、アップリンクキャリアを通じたデータ伝送は不可能である。この状況でもアップリンクキャリアのＰＨＲ機能を運営することは、タイマ駆動又はＰＨＲトリガの可否に対する判断のような不必要な動作をもたらす。

本発明の第５の実施形態では、上記のような状況では、該当アップリンクキャリアのＰＨＲ機能を一時的に中止する方法を提供する。

図１８は、本発明の第５の実施形態による電力ヘッドルーム報告方法による端末の動作を示すフローチャートである。図１８を参照すると、ステップ１８０５において、端末の任意のアップリンクキャリアにＰＨＲ機能が設定される。任意のアップリンクキャリアにＰＨＲ機能が設定されるということは、キャリアに対して周期的ＰＨＲタイマ、経路損失変更基準が設定されることを意味する。端末は、周期的ＰＨＲタイマの通知されたタイマ値と経路損失変更基準を用いて該当アップリンクキャリアに対してＰＨＲがトリガされるか否かを判定する。端末は、ステップ１８１０において、ＰＨＲ機能が設定されたアップリンクキャリアに関連したダウンリンクキャリアを監視する。監視するダウンリンクキャリアは、該当アップリンクキャリアとスケジューリングの側面で関連したダウンリンクキャリアと経路損失の側面で関連したダウンリンクキャリアである。任意のアップリンクキャリアが任意のダウンリンクキャリアとスケジューリングの側面で関連するということは、アップリンクキャリアに対するスケジューリング命令(アップリンクグラント）がダウンリンクキャリアのみを介して送受信されることを意味する。ここで、関連関係は、キャリア設定を指示する制御メッセージで設定することができる。任意のアップリンクキャリアが任意のダウンリンクキャリアと経路損失の側面で関連するということは、アップリンクキャリアの伝送電力の計算において関連したダウンリンクキャリアの経路損失を使用することを意味する。ここで、関連関係は、キャリアを設定する制御メッセージで設定され得る。スケジューリング側面での関連関係と経路損失側面での関連関係は同一であるか、あるいはそうでないこともある。端末は、ステップ１８１５で、スケジューリングの面で関連したダウンリンクキャリアが非活性状態であるか否かを確認する。任意のダウンリンクキャリアが非活性化状態ということは、端末がダウンリンクキャリアのＰＤＣＣＨを受信しない状態であることを意味する。基地局は、端末の電力消耗を最小化するために、端末に設定されたダウンリンクキャリアのうち必ず必要なキャリアを除いた残りのキャリアを非活性化状態にする。任意のダウンリンクキャリアを活性化または非活性化することは、基地局が端末に明示的な制御命令を伝送することによってなされることができる。ＰＨＲ機能が設定されたアップリンクキャリアとスケジューリングの面で関連するすべてのダウンリンクキャリアが非活性化状態である場合、アップリンクキャリアに対するスケジューリングが不可能であることを意味するので、ＰＨＲ機能を遂行する必要性が低下し、端末はステップ１８３０に進行する。ＰＨＲ機能が設定されたアップリンクキャリアとスケジューリング側面で関連したダウンリンクキャリアが一つでも活性化状態であると、端末は、ステップ１８２０に進行する。ステップ１８２０において、端末は、アップリンクキャリアと経路損失の側面で関連したダウンリンクキャリアが悪いチャンネル受信品質を有して正常な受信が不可能な状態であるか否かを確認する。この判断は、ダウンリンクキャリアのチャンネル受信品質が所定の基準値以下である状態で一定期間以上維持されたか否かによって判定する。ステップ１８２０において、経路損失の側面で関連したダウンリンクキャリアで正常なサービスが不可能な状態であると、該当アップリンクキャリアを通じるアップリンク伝送の際に高い経路損失によって正常なアップリンク伝送が難しくなる可能性が高い。したがって、端末は、ステップ１８３０でＰＨＲ機能を非活性化する。ＰＨＲ機能を非活性化するということは、周期的ＰＨＲタイマの駆動を中止し、ＰＨＲがトリガされたか否かを判断するために格納されている情報を廃棄することを意味する。一方、ステップ１８１５でスケジューリングの側面で関連したダウンリンクキャリアが活性化状態であり、ステップ１８２０で経路損失の側面で関連したダウンリンクキャリアがサービス不可能状態でなる場合、端末は、ステップ１８２５でＰＨＲ機能を活性化する。ＰＨＲ機能が既に活性化されている場合、端末は、現在ＰＨＲ機能の活性化状態を維持する。ＰＨＲ機能を活性化するということは、周期的ＰＨＲタイマを駆動し、アップリンク伝送の際に経路損失の変化を確認してＰＨＲがトリガされたか否かを判断する動作を遂行することを意味する。ステップ１８２５で、ＰＨＲ機能が非活性化状態から活性化状態に変更される場合、端末は、周期的ＰＨＲタイマを駆動してＰＨＲを新たにトリガする。任意のアップリンクキャリアに対するＰＨＲ機能が非活性化状態から活性化状態に変更されるということは、該当アップリンクキャリアに対して長い間ＰＨＲが報告されなかった可能性が高いため、基地局にＰＨＲを報告するためである。

＜第６の実施形態＞
ＰＨＲ機能がアップリンクキャリア別に設定されるということは、ＰＨＲタイマがキャリア別に独立に駆動し、ＰＨＲが独立にトリガされることを意味する。ＰＨＲタイマは、ＰＨＲの周期的伝送のためのものであって、ＰＨＲが伝送されると、ＰＨＲタイマは駆動される。周期的ＰＨＲタイマの満了は、ＰＨＲをトリガさせる。トリガされたＰＨＲは、アップリンク伝送が可能な最も近いタイミング(例えば、ＰＨＲがトリガされた後に初めてアップリンクグラントを受信する場合)に生成され、ＭＡＣ ＰＤＵに格納されて伝送される。ＰＨＲタイマは、ＰＨＲの伝送により駆動され、ＰＨＲの伝送は、ＰＨＲタイマの満了によってトリガされるので、ＰＨＲタイマの駆動とＰＨＲの伝送は循環する因果関係を有する。しかしながら、ハンドオーバーのような理由でＰＨＲタイマが中止されると、ＰＨＲタイマは、ハンドオーバーを完了した後、新たなＰＨＲが伝送されない限り再駆動できない。ハンドオーバー過程で、端末は、ＭＡＣ階層で駆動中であるすべてのタイマを中止する。ハンドオーバーが完了した後、中止されたＰＨＲタイマが再駆動されない場合には、周期的ＰＨＲ機能が意図と異なり中止するという結果をもたらす。従来には上記のようにハンドオーバー後にＰＨＲタイマが再駆動できないという問題点を解決するために、ハンドオーバー後に端末が新たなセルで最初のアップリンク伝送を遂行すると、ＰＨＲタイマを駆動するように定義した。しかしながら、上記のように新たなセルで任意のキャリアで最初のアップリンク伝送を遂行した後、該当キャリアのＰＨＲタイマを駆動する場合、ＰＨＲタイマは、設定されたアップリンクキャリアのＰＨＲタイマがすべて再駆動するまで相当な遅延が発生し得る。これに関連して、ＰＨＲは、ＢＳＲに比べてその重要性が落ちるため、ハンドオーバーが完了すると、すぐにＰＨＲをトリガする必要はない。それにもかかわらず、端末の電力ヘッドルームに対して如何なる情報も持っていない基地局にできるだけ速くＰＨＲを伝送する必要がある。本発明の第６の実施形態では、このために端末がＭＡＣのリセット後に初めてアップリンク伝送を遂行すると、周期的ＰＨＲ機能が設定されたすべてのアップリンクキャリアの周期的ＰＨＲタイマを共に駆動する方法を提供する。

図１９は、本発明の第６の実施形態による電力ヘッドルーム報告方法による端末の動作を示すフローチャートである。図１９を参照すると、ステップ１９０５において、任意のＵＬ ＣＣで新たな伝送を指示するアップリンク伝送リソースが割り当てられる理由で、該当ＵＬ ＣＣに対して新たな伝送のためのアップリンク伝送リソースが使用可能になる。端末は、ステップ１９１０において、新たに使用可能な新たな伝送のための伝送リソースがＭＡＣリセット以後に初めて使用可能になる新たな伝送のための伝送リソースであるか否かを確認する。その結果、上記伝送リソースである場合には、端末は、ステップ１９１５で、周期的ＰＨＲタイマが設定されているアップリンクＣＣの周期的ＰＨＲタイマをすべて駆動する。このタイマは、端末がＭＡＣリセットを遂行しつつ中止させるので、ＭＡＣリセット以後に再駆動しないと、周期的ＰＨＲ機能が意図と違って非活性化される結果をもたらす。以後、ステップ１９２０において、端末は、使用可能な伝送リソースを通じて伝送するＭＡＣ ＰＤＵを生成し、伝送リソースを通じてＭＡＣ ＰＤＵを伝送する。ステップ１９１０で、ＭＡＣリセット以後に最初のリソース割り当てでない場合、端末は、一般的なＵＬ伝送を遂行する。

＜第７の実施形態＞
本発明の第７の実施形態においては、高速データ通信環境で端末のバッファ状態を基地局に効率的に報告するための方案として、新たなバッファ状態報告トリガを提供する。一つのサブフレームに多い量のデータを送信できる高速データ通信環境、例えば複数のアップリンクキャリアが集約された環境では、端末が最も最近に報告したバッファ状態は、基地局が認知できない状況で急激に変化する可能性がある。例えば、端末は１,０００,０００バイトの伝送可能なデータを格納しているとしても、バッファ状態テーブルの限界によって伝送可能なデータの量が１５０,０００バイト以上であると報告することができる(例えば、端末は、基本バッファ状態テーブルのバッファ状態値６３を報告する)。端末のチャンネル状況が非常に良好で、該当セルのロードが低くて基地局が端末に、例えば一回に１５０,０００バイトのデータ伝送を命令した場合、基地局は、端末がある程度のデータをさらに格納しているか知らないので、以後の新たなバッファ状態報告を受信する前までは端末に適切にグラントを割り当てることができない。このように、端末は、多い量のデータを伝送した後に新たなバッファ状態報告をトリガすべき必要性が増加する。

第７の実施形態で提供する第１の方案では、端末が一定量以上のデータを伝送する度にバッファ状態報告をトリガする伝送量基準のトリガ方式を提供する。伝送量基準のトリガ方式は、既に一般的に使われているもので、端末が予め定められた所定の基準値以上のデータを伝送した後に所定の動作を遂行する。通常的な方式をその通り適用する場合、バッファ状態報告が不必要に頻繁に発生するという短所を有する。上記したように、本発明が解決しようとする課題は、端末のバッファ状態が最も最近報告したバッファ状態から格段に変化した場合、特に端末のバッファ状態の変化を基地局が推定できない場合(例えば、バッファ状態テーブルの最大値の限界により、端末が基地局に不完全な情報を提供した場合)にバッファ状態報告を提供するものである。したがって、一定量のデータを伝送する度にバッファ状態報告をトリガすることは、過度に多くのバッファ状態報告を発生させるという問題を発生する可能性がある。

本発明の実施形態で提供する他の方案は、このような問題を補完するために、最も最近のバッファ状態報告から一定量のデータを伝送したときにバッファ状態報告をトリガする方法を提供する。例えば、伝送したデータの量を記録するカウンタを従来のようにカウント値(ＣＯＵＮＴ)が定められた基準値を超える場合にのみ０に初期化することでなく、他の理由(優先順位が高いデータの発生、パディングＢＳＲの発生など）でバッファ状態報告がトリガされる場合にも０に初期化することによって、ＢＳＲが不必要によく発生することを防止する。また、伝送量基準のトリガは、端末がバッファ状態テーブルで指示できる範囲を外れたデータ量を報告した場合に最も効用が高いため、最も最近伝送したバッファ状態報告で報告したバッファ状態値に従ってトリガを選択的に適用できる。例えば、バッファ状態値として最も高い値を報告した場合、あるいはバッファ状態値として所定の基準値以上を報告した場合にのみ、伝送量基準のトリガを適用することができる。

図２０は、本発明の第７の実施形態によるバッファ状態報告方法による端末の動作を示すフローチャートであって、本発明の実施形態ではバッファ状態報告のための新たなトリガを定義する。

図２０を参照すると、ステップ２００５において、端末は、呼設定過程を通して基地局から伝送量基準のトリガに関連したパラメータの通知を受信する。パラメータは、伝送量基準及び基準バッファ状態値などであり得る。基準バッファ状態値は、伝送量基準トリガを適用するか否かを判断する基準値である。端末は、基準バッファ状態値に該当するバッファ状態値を包含するバッファ状態報告がトリガされると、伝送量基準のトリガを活性化する。基準バッファ状態値を明示的にシグナリングする代わり、端末と基地局との間で予め約束された値を使用するか、あるいはバッファ状態テーブルの最も高い値を基準バッファ状態値として決定して使用することができる。

ステップ２０１０において、端末は、バッファ状態報告が最初にトリガされるまで待機し、バッファ状態報告がトリガされる場合、ステップ２０１５で、トリガされたバッファ状態報告に含まれたバッファ状態値が基準バッファ状態値に該当するか否かを確認する。基準バッファ状態値は、バッファ状態テーブルで定義された最大値(例えば、バッファ状態値６３)であり、あるいはステップ２００５で通知された値であり得る。バッファ状態報告のバッファ状態値が基準バッファ状態値のうちいずれか一つと一致する場合、伝送量基準のトリガを適用するために、端末は、ステップ２０２０に進行する。バッファ状態報告のバッファ状態値が基準バッファ状態のうちいずれの値とも一致しない場合、端末は、ステップ２０３５で、伝送量基準のトリガを非活性化する。伝送量基準のトリガを非活性化するということは、伝送量基準のトリガに関連した一切の動作、例えば端末が前述したＣＯＵＮＴを管理する動作を遂行しないことを意味する。ステップ２０２０において、端末は、ＣＯＵＮＴを０に初期化する。アップリンクでデータが伝送されると、データが伝送される度に伝送されたデータの量をＣＯＵＮＴに累算する。

図２０において、カウント動作と並行して端末は、ステップ２０２５で、カウンタが基準値を超える前に所定のＢＳＲがトリガされるか否かを確認する。所定のＢＳＲは、例えばパディング空間の不足によって基地局に不完全な情報を伝送する短縮(truncated)ＢＳＲ(３ＧＰＰＰ ＴＳ３６.３２１を参照)を除いた残りのすべてのＢＳＲ、すなわち正規ＢＳＲ、周期的ＢＳＲ、パディングＢＳＲであり得る。ＣＯＵＮＴが基準値を超過する前に所定のＢＳＲに該当するＢＳＲがトリガされることは、端末が基地局に端末のバッファ状態を新たに報告することを意味するので、伝送量基準ＢＳＲをトリガする必要がなくなることを意味する。この場合、端末は、ステップ２０１５に進行し、伝送量基準のトリガが活性化状態であるか否かの判断動作を再開する。例えば、新たにトリガされたＢＳＲのバッファ状態値を確認し、伝送量基準トリガを適用するか否かを判断する後続動作を遂行する。ステップ２０２５において、ＣＯＵＮＴが基準値を超えるまで所定のＢＳＲがトリガされない場合、ステップ２０３０において、端末は、ＣＯＵＮＴが基準値を超えるタイミングで周期的ＢＳＲをトリガし、ＣＯＵＮＴを０に初期化する。すると、端末は、ステップ２０１５に戻る。周期的ＢＳＲをトリガするということは、端末がＢＳＲを伝送するためにスケジューリング要求信号を伝送しないことを意味する。参考のために、端末は、正規ＢＳＲがトリガされる場合、ＢＳＲを迅速に伝送するためにスケジューリング要求信号を伝送する。

ＣＯＵＮＴは、データが伝送される度に伝送されたデータの量だけ増加する。このとき、特定の論理チャンネルグループに属するデータに対してのみＣＯＵＮＴを増加させることも可能である。特定の論理チャンネルグループは、例えば最も最近報告したＢＳＲでバッファ状態値が基準バッファ状態値以上である論理チャンネルグループであり得る。

上記した第７の実施形態の他の動作で、端末が最も最近報告したバッファ状態で一定比率以上のデータが伝送されると、ＢＳＲをトリガする方法が図２１に示されている。

図２１は、本発明の第７の実施形態によるバッファ状態報告方法による端末の他の動作を示すフローチャートである。

図２１を参照すると、ステップ２１０５において、端末は、呼設定過程を通して基地局から伝送レート基準のトリガに関連したパラメータの通知を受信する。パラメータは、伝送レート基準のトリガの起動条件を定義するパラメータ、すなわち伝送レート基準と、伝送レート基準トリガの適用条件を定義するパラメータ、すなわち基準バッファ状態値を含む。伝送レート基準トリガの適用条件を定義するパラメータの代わりに基準バッファサイズを使用することができる。基準バッファ状態値は、上記したように、一種のインデックスである。場合によって、伝送レート基準トリガを適用するか否かはバッファ状態報告で報告したデータ量の和によって判断することがより望ましい。この場合、基準バッファサイズは、実際のバッファに格納されているデータをバイト単位で示す基準バッファサイズを使用する。伝送量基準のトリガの適用条件も、同様にバッファに格納されているデータをバイト単位で示す基準バッファサイズを使用することができる。

ステップ２１１０において、端末は、バッファ状態報告が最初にトリガされるまで待機し、バッファ状態報告がトリガされる場合、ステップ２１１５で、伝送レート基準のトリガを適用するか否かを判定する。ステップ２１１５において、端末は、トリガされたバッファ状態報告のバッファ状態値が基準バッファ状態値のうちいずれか一つと一致するか、あるいはトリガされたバッファ状態報告のバッファ状態値から誘導される全体バッファ状態が基準バッファ状態以上であるかを判定する。全体バッファ状態は、バッファ状態報告のバッファ状態値から所定の規則を適用して得られる値である。例えば、端末がバッファ状態報告で論理チャンネルグループ１に対してバッファ状態値１０(３６＜ＢＳ≦４２）を、論理チャンネルグループ２に対してバッファ状態値２０(１７１＜ＢＳ≦２００）を報告したとき、全体バッファ状態は、各バッファ状態値が指示する範囲の最大値(又は最小値）の和として定義でき、上記の例では２４２バイト(又は２０９バイト)である。基準バッファ状態が１０００バイトである場合、伝送レート基準のトリガは適用されない。基準バッファ状態が２００バイトである場合、伝送レート基準のトリガは適用される。ステップ２１１５で提示した伝送レート基準トリガを適用するか否かを判断する過程は、ステップ２１１５の伝送量基準のトリガを適用するか否かを判断する過程にも適用可能である。

ステップ２１１５で伝送レート基準のトリガを適用するか否かを判断した結果、端末は、伝送レート基準トリガの適用が必要である場合にはステップ２１２０に進行し、伝送レート基準トリガの適用が必要でない場合にはステップ２１３５に進行して伝送レート基準のトリガを非活性化する。ここで、伝送レート基準トリガの非活性化は、端末が伝送レート基準トリガと関連した一切の動作、例えば伝送レート変数を管理する動作を遂行しないことを意味する。

一方、伝送レート基準トリガの適用が必要な場合、ステップ２１２０において、端末は、伝送レート変数を０に初期化する。アップリンクにデータが伝送される度に伝送されたデータの累積値と比較値との比率を伝送レートの変数に格納する。比較値は、最も最近トリガされた(又は伝送された)バッファ状態報告で報告したデータの和である。上記動作と並行して端末は、ステップ２１２５で、伝送レート変数が基準値を超える前にＢＳＲがトリガされるか否かを確認する。ＢＳＲは、例えばパディング空間の不足によって基地局に不完全な情報を伝送する短縮ＢＳＲ(３６.３２１を参照)を除いた残りのすべてのＢＳＲであり得る。伝送レートが基準値を超える前にＢＳＲがトリガされる場合、端末は、ステップ２１１５で、伝送レート基準トリガが活性化されるか否かを確認する。伝送レートが基準値を超えるまで、ＢＳＲがトリガされない場合、端末は、ステップ２１３０で、伝送レートが基準値を超過するタイミングで周期的ＢＳＲをトリガし、ステップ２１１５に戻る。

上記した第７の実施形態のもう一つの動作において、所定のサイズ以上のアップリンクデータが伝送されるときは常にＢＳＲがトリガ可能にする方法を提供する。上述したように、大きなデータが伝送されると、バッファ状態に顕著な変化、すなわちバッファ状態の急激な減少が起きるので、新たなＢＳＲをトリガしなければならないという必要性が増加する。特に、大きなデータにＢＳＲを格納する場合、ＢＳＲのサイズは固定されるので、ＢＳＲによるオーバーヘッドが相対的に小さい。

図２２は、本発明の第７の実施形態によるバッファ状態報告方法による端末のもう一つの動作を示すフローチャートである。

ステップ２２０５において、端末は、トリガ関連のパラメータを認知する。トリガ関連パラメータは、何バイト以上のＭＡＣ ＰＤＵを伝送するとき、ＢＳＲを含めなければならないか否かを指示する情報である。ステップ２２１０において、基地局から新たな伝送を指示するアップリンクグラントを受信する場合、端末は、ステップ２２１５で、新たな伝送を指示するアップリンクグラントが何バイトのＭＡＣ ＰＤＵサイズの伝送を指示するか否かを確認する。そして、伝送されるＭＡＣ ＰＤＵのサイズをステップ２２０５で認知した基準サイズと比較してＭＡＣ ＰＤＵのサイズが基準サイズを超える場合、ＭＡＣ ＰＤＵのサイズが基準サイズより小さい場合、端末は、ステップ２２２５に進行して従来技術に従って動作する。

＜第８の実施形態＞
本実施形態では、要求される伝送出力が端末の最大伝送出力を超えると、端末は、伝送出力を最大伝送出力に低くして伝送する。これを伝送出力の縮小(スケーリング)(power scaling)と表現する。

伝送出力の縮小が発生することは、基地局が端末の伝送出力状況を誤認しているという強い証拠である。したがって、端末は、ＰＨＲを伝送して基地局に端末の伝送出力状況を通知する必要がある。特に、端末に複数のアップリンクキャリアが設定されている場合、基地局がどのアップリンクキャリアの伝送出力状況を誤認して伝送出力の縮小が発生したかが明確でないことがある。また、伝送出力の縮小が発生したサブフレームでの伝送は信頼度が格段に落ちることによって、ＰＨＲ伝送が失敗する可能性も高い。すべての状況を考慮して、第８の実施形態において、端末は、任意のサブフレームで伝送出力の縮小が発生すると予想されると、サブフレームでデータ伝送が予定されたすべてのアップリンクキャリアのＰＨＲをトリガし、伝送の信頼度を向上させるためにＰＨＲを伝送した後、ＰＨＲを再びトリガする方法を提供する。以下の説明において、伝送出力縮小の発生は、伝送出力が不足するということと同一の意味である。

図２３は、本発明の第８の実施形態による電力ヘッドルーム報告方法による端末の動作を示すフローチャートである。

図２３を参照すると、ステップ２３０５において、新たな伝送のためのアップリンク伝送リソースが使用可能である場合、端末は、ステップ２３１０に進行する。アップリンク伝送リソースは、一つのアップリンクキャリア向けであり、あるいは複数のアップリンクキャリア向けであり得る。ステップ２３１０において、端末は、アップリンク伝送の際に伝送出力の縮小を発生するか否かを判定する。アップリンク伝送が複数のアップリンクキャリアを介して遂行される場合、例えばステップ２３０５で使用可能であるアップリンク伝送リソースがアップリンクキャリア１でＸバイトのデータを伝送し、アップリンクキャリア２でＹバイトのデータを伝送する場合には、各アップリンクキャリアの個別的なアップリンク伝送の要求伝送出力は、端末の最大伝送出力を超えないが、アップリンクキャリア別要求伝送出力の和は、端末の最大伝送出力を超えることによって、伝送出力の縮小が発生することもある。

このように伝送出力の縮小が発生する場合、端末は、ステップ２３１５に進行する。ステップ２３１５で、端末は、伝送出力の縮小が発生するアップリンク伝送に関連したアップリンクキャリアの中で、ＰＨＲが設定されたアップリンクキャリアのＰＨＲをトリガする。例えば、端末にアップリンクキャリア１、アップリンクキャリア２、アップリンクキャリア３が設定されている場合、すべてのアップリンクキャリアにＰＨＲが設定されており、任意のサブフレームにアップリンクキャリア１とアップリンクキャリア２でアップリンク伝送を同時に遂行することによって伝送出力の縮小が発生する場合、端末は、アップリンクキャリア１とアップリンクキャリア２のＰＨＲをトリガし、ステップ２３３０に進行する。一方、ステップ２３１０で、伝送出力の縮小が発生しない場合、端末は、ステップ２３２０で、周期的ＰＨＲ又は正規ＰＨＲが発生したか否かを判定する。周期的ＰＨＲと正規ＰＨＲに対する詳細な説明は、３ＧＰＰ ＴＳ３６.３２１のセクション５．４．６に規定しているので、その詳細な説明を省略する。ステップ２３２０において、周期的ＰＨＲ又は正規ＰＨＲがトリガされない場合には、端末は、ステップ２３２５で、ＰＨＲを生成せずに上記手順を終了する。ステップ２３２０において、周期的ＰＨＲまたは正規ＰＨＲがトリガされた場合、端末は、ステップ２３３０で、ＰＨＲがトリガされたアップリンクキャリアに対するＰＨＲを生成して伝送する。ＰＨＲ伝送は、例えば該当アップリンクキャリアのみを介してなされることもできるので、トリガされたＰＨＲは、相互に異なるタイミングで伝送することができる。

ステップ２３３０において、端末は、ＰＨＲを伝送した後にステップ２３３５に進行して、伝送されたＰＨＲが伝送出力の縮小によってトリガされたＰＨＲであるか否かを確認する。トリガされたＰＨＲであると、ステップ２３４０に進行し、伝送出力縮小でない他の理由でトリガされるＰＨＲである場合にはステップ２３５０に進行する。ステップ２３４０で、端末は、伝送が完了したＰＨＲを取消す。ステップ２３４５において、端末は、取り消したＰＨＲを再びトリガして次の伝送機会にもう一回伝送されるようにする。これは、ＰＨＲが縮小した伝送出力に伝送されたため、伝送失敗が発生する可能性が高いためである。

ステップ２３３５で伝送されたＰＨＲが伝送出力の縮小でない他の理由でトリガされたＰＨＲである場合、ステップ２３５０で、端末は、禁止タイマを駆動する。禁止タイマは、ＰＨＲが過度によく伝送されることを防止するためのもので、ＰＨＲが伝送される度に駆動され、端末は、禁止タイマが駆動される間には周期的ＰＨＲ又は正規ＰＨＲをトリガしない。参考のため、伝送出力の縮小により発生したＰＨＲに対してはＰＨＲが伝送された後、禁止タイマを駆動する動作は遂行されない。これは、禁止タイマの主目的が従来の周期的ＰＨＲ又は正規ＰＨＲがよく発生することを防ぐためのものであるため、従来のＰＨＲとは異なる重要度を有する伝送出力の縮小によるＰＨＲを禁止タイマと独立に駆動するためである。

＜第９の実施形態＞
端末に複数のキャリアが設定されているとき、端末は、電力消耗を低減させるためにキャリアのうち一部のみを活性化状態で駆動し、残りは非活性化状態を維持する。キャリア活性化及び非活性化は、基地局が伝送するＭＡＣ階層の制御メッセージによって制御される。ＭＡＣ階層制御メッセージは、所定のビットマップを含み、ビットマップでプライマリキャリア(primary carrier)を除いた残りのキャリアの状態を指示する。一方、キャリアのうちいずれか一つのキャリアは、プライマリキャリアとして指定され、プライマリキャリアは、常に活性化状態を維持する特徴を有する。基地局は、必要に応じて端末のプライマリキャリアを変更できる。

ビットマップのビットとキャリアとの間のマッピング関係は、例えばキャリアを設定する制御メッセージで設定することができる。例えば、端末にキャリア１、キャリア２、キャリア３が設定されており、キャリア１がプライマリキャリアであることを仮定した場合、基地局は、端末にキャリア２とキャリア３を設定する制御メッセージにキャリア２がビットマップの何番目のビット(例えば、１番目のビット)に対応し、キャリア３がビットマップの何番目のビット(例えば、２番目のビット)に対応するかを指示できる。

端末のプライマリキャリアが変更される場合、基地局は、以前のプライマリキャリアがビットマップの何番目のビットと対応するかを指示すべきである。端末に設定されているキャリアの集合を設定キャリア集合と称する場合、プライマリキャリアが変更される場合には、以前プライマリキャリアと新たなプライマリキャリアがすべて設定キャリア集合に属する場合とそうでない場合に区分できる。プライマリキャリアの変更が、通常、ロードバランシング(load balancing)の面で遂行される可能性が高いという点を考慮すれば、第１のタイプに属するプライマリキャリアの変更がさらに頻繁になると予想される。

第１のタイプのプライマリキャリアの変更は、以前プライマリキャリアと新たなプライマリキャリア両方ともが予め設定されているキャリアであるため、新たなプライマリキャリアが使用したビット位置が使用可能である。言い換えれば、このようなタイプのプライマリキャリアの変更手順では、以前プライマリキャリアのビット位置として、新たなプライマリキャリアのビット位置を使用することができる。例えば、プライマリキャリアが、キャリア１からキャリア２に変更される場合、キャリア２に既に割り当てられたビット位置がある場合に、端末は、キャリア１のビット位置としてキャリア２が使用したビット位置を使用する。

図２４は、本発明の実施形態によるプライマリキャリア変更方法を示すフローチャートである。

図２４を参照すると、ステップ２４０５において、端末は、基地局からプライマリキャリアを変更する制御メッセージを受信する。参考として、キャリアとセルは相互に異なる概念であるが、３ＧＰＰ規格では、キャリアアグリゲーションと関連してよく混用される。本発明でも、特別な言及がない限り、キャリアとセルは同一の文脈で理解すべきである。端末は、プライマリキャリア変更メッセージの指示に従ってプライマリキャリアを変更する。ステップ２４１０において、端末は、制御メッセージに以前プライマリキャリアのビット位置に関する情報があるか否かを確認する。上記情報がある場合、端末は、ステップ２４２０に進行して、指示されたビット位置を以前プライマリキャリアに対応させる。ビット位置に関する情報は、該当キャリアがビットマップの何番目のビットであるかを指示する情報である。制御メッセージに以前プライマリキャリアのビット位置に関する情報がない場合、端末は、ステップ２４１５で、制御メッセージを通じて新たなプライマリキャリアとなるキャリアのビット位置を確認し、この確認したキャリアのビット位置を以前プライマリキャリアのビット位置として設定する。

＜第１０の実施形態＞
図２５は、本発明の第１０の実施形態による電力ヘッドルーム報告方法による端末のもう一つの動作を示すフローチャートであって、本実施形態では端末がキャリアアグリゲーションと関連した複数のキャリアのＰＨＲを処理する手順を提供する。

一つの端末に複数のアップリンクキャリアが集約され、それぞれのキャリアにＰＨＲ機能が設定される場合、一つの端末は複数のキャリアに対してＰＨＲを発生したか否かを確認しなければならない。上記したように、ＰＨＲの発生有無は、周期的タイマと経路損失変化の量(値)によって判断される。適時にＰＨＲを基地局に伝送するという側面では、アップリンクキャリア別に独立に周期的タイマと経路損失の基準値を設定する。

しかしながら、現在キャリアアグリゲーション動作が適用されると予想される周波数バンドを考慮すると、アップリンクキャリア別経路損失の差が大きくないことがある。したがって、複数のアップリンクキャリアの中で選択されたアップリンクキャリア一つに対してのみＰＨＲがトリガされたか否かを判断し、選択されたアップリンクキャリアに対してＰＨＲがトリガされる場合、ＰＨＲが設定されたすべてのアップリンクキャリアのＰＨＲを共にトリガされると、端末動作を単純化できる。

このとき、トリガされたＰＨＲを同時に伝送する場合、ＰＨＲトリガ、ＰＨＲ発生、及びＰＨＲ伝送がすべてのアップリンクキャリアに対して一括的に管理されて端末の複雑度が格段に減少される。このために、任意のＰＨＲがどのアップリンクキャリアに対するＰＨＲであるかを示す必要がある。

例えば、現在ＰＨＲには使用しない２ビットがあり、この２ビットを用いてＰＨＲに対応するアップリンクキャリアを指示することが可能である。この場合、一つの問題は、端末に集約できるアップリンクキャリアが、例えば最大５個であるため、２ビットでは各ＰＨＲがどのアップリンクキャリアに対するＰＨＲであるかを表現できないということである。

本発明の実施形態では、上記の問題を解決するために、ＰＨＲをプライマリキャリア用ＰＨＲとセカンダリキャリア用ＰＨＲに区分する。例えば、ＬＴＥシステムでは、キャリアアグリゲーションで端末が利用できるキャリアには一つのプライマリキャリアと最大４個のセカンダリキャリアが存在するという点を考慮して、セカンダリキャリア用ＰＨＲを新たに定義すると、セカンダリキャリア用ＰＨＲの使用しない２ビットで任意のセカンダリキャリア用ＰＨＲがどのセカンダリキャリアに対するものであるかを指示できる。

一方、図２５を参照すると、ＰＨＲは、ＭＡＣ制御要素(Control Element：ＣＥ）の一種として、ＭＡＣサブヘッダ２５０５とペイロード２５１０を含む。該当ＭＡＣ ＣＥがＰＨＲであることを指示する情報はＭＡＣサブヘッダの論理チャンネル識別子フィールド２５１５に挿入され、ＰＨ(Power Headroom）はペイロードの６ビット２５３０に挿入される。

また、図２６を参照すると、本発明の実施形態では、プライマリキャリア用ＰＨＲ２６８５を指示する論理チャンネル識別子とセカンダリキャリア用ＰＨＲ２６７０を指示する論理チャンネル識別子を各々定義し、ＭＡＣサブヘッダ２６４５の論理チャンネル識別子フィールドに適切な論理チャンネル識別子を挿入することによって、プライマリキャリア用ＰＨＲ２６３５とセカンダリキャリア用ＰＨＲ２６７０が区別されるようにする。

従来は端末が用いるアップリンクキャリアとして一つのキャリアのみが存在し、この存在する一つのキャリアがプライマリキャリアと同一の属性を有することに鑑みて、プライマリキャリア用ＰＨＲの論理チャンネル識別子を別に定義する代わり、従来のＰＨＲ用として定義された論理チャンネル識別子を再使用することができる。すなわち、現在規格でＰＨＲの論理チャンネル識別子として定義される、例えば“１１０１０”をプライマリキャリア用論理チャンネル識別子として使用し(２６１５)、現在規格で使用しない論理チャンネル識別子、例えば“１１００１”をセカンダリキャリア用論理チャンネル識別子２６５５として使用することができる。

ここで、プライマリキャリア用ＰＨＲ２６３５のペイロード２６１０の１番目の２ビット(２６２０）は、使用されず、そのペイロードの残りの６ビット(２６３０)にはプライマリキャリアのＰＨが受納される。

本発明の第４の実施形態で提示したように、プライマリキャリア用ＰＨＲ２６３５のペイロード２６１０は、２バイトで構成され、プライマリキャリアのＰＵＳＣＨ用ＰＨはそのペイロード２６１０の１番目のバイト２６２０に格納され、ＰＵＣＣＨ用ＰＨが２番目のバイト２６２５に格納され得る。セカンダリキャリア用ＰＨＲ２６７０のペイロード２６５０の１番目の２ビット２６６０には該当ＰＨＲがどのセカンダリキャリアに対するものであるかを示す情報が格納され、そのペイロードの残り６ビット２６６５にはセカンダリキャリアのＰＨが書き込まれる。

複数のセカンダリキャリアのＰＨは、セカンダリキャリア用ＰＨＲ２６７０に格納されることもできる。例えば、セカンダリキャリアの識別子２６６０とセカンダリキャリアのＰＨ２６６５は、セカンダリキャリア用ＰＨＲ２６７０のペイロード２６５０の各バイト別に格納できる。このとき、セカンダリキャリアのＰＨＲ２６７０のペイロード２６５０のサイズは、受納されたセカンダリキャリアのＰＨの個数に従って可変的なので、セカンダリキャリアに対するＰＨＲ２６７０のサイズを明示的に表示する必要がある。セカンダリキャリアに対するＰＨＲ２６７０のサイズは、例えばＭＡＣサブヘッダ２６４５の使用しない２ビット(２６７５，２６８０)を用いて、そのサイズを指示できる。

図２７は、本発明の第１０の実施形態による電力ヘッドルーム報告方法を示すフローチャートである。

図２７を参照すると、一つのプライマリキャリアと複数のセカンダリキャリアが集約された端末２７０５と基地局２７１０を仮定する場合、ステップ２７１５で、基地局２７１０は、所定の制御メッセージを用いて端末２７０５にＰＨＲ設定情報を伝送する。ＰＨＲ設定情報は、経路損失変化(dl-pathlossChange)、周期的ＰＨＲタイマ(periodicPHR-timer)、禁止ＰＨＲタイマ(prohibitPHR-timer)、ＰＨＲトリガリングの可否を判断するキャリアコンポーネント(ＣＣ)、及び上記セカンダリキャリアＰＨＲ２６７０で使用するセカンダリキャリアの識別子(以下、ＰＨＲ用セカンダリキャリア識別子)２６６０のうち少なくとも一つを含む。禁止ＰＨＲタイマ(prohibitPHR-timer）は、ＰＨＲが過度によく発生することを防止するものであって、ＰＨＲが伝送されると駆動される。禁止ＰＨＲタイマが駆動される間に、ＰＨＲはトリガできない。ＰＨＲがトリガリングされたか否かを判断するＣＣは、端末が経路損失変化に基づいてＰＨＲトリガリングの可否を判断する場合に使用されるＣＣ(以下、トリガリングＣＣ)である。ＰＨＲトリガリングの可否が判断されるトリガリングＣＣは、ダウンリンクＣＣであり、基地局が直接指示するか、端末と基地局との間に所定の決定することができる。例えば、プライマリＣＣを用いてＰＨＲトリガリングの可否を判断できる。セカンダリキャリアの識別子２６６０は、例えば、０〜３の４個すべてが定義され、セカンダリキャリア別に直接指示され、あるいは他の情報から推定類推することができる。例えば、キャリア別にもう一つの用途の識別子が割り当てられる場合、その割り当てられた識別子のサイズ順にＰＨＲ向けのセカンダリキャリア識別子が所定の方式で割り当てられることができる。または、キャリアの中心周波数順に、高い周波数から低い周波数に、又はその逆順にＰＨＲ向けのセカンダリキャリア識別子が割り当てられることができる。

図２７のステップ２７２０で、端末は、ステップ２７１５で基地局から上記ＰＨＲ設定情報を受信すると、ＰＨＲ設定情報に基づいてＰＨＲがトリガされたか否かを判定する。ＰＨＲのトリガリングに対する判定は、ＰＨＲトリガリングの可否が判定されるダウンリンクキャリアの経路損失変化が所定の基準値を超えるか、あるいは周期的タイマが満了したかに基づいて遂行される。

ステップ２７２５で任意のタイミングでＰＨＲがトリガされる場合、ステップ２７３０で、端末は、最も早いタイミングで伝送されるＭＡＣ ＰＤＵにＰＨＲを含めて伝送する。このとき、ＰＨＲは、プライマリキャリア用のＰＨＲとセカンダリキャリア用のＰＨＲを含む。セカンダリキャリア用のＰＨＲは、一つ又は複数であり得る。一つのセカンダリキャリア用のＰＨＲにすべてのセカンダリキャリアのＰＨを格納する場合、セカンダリキャリア用ＰＨＲのＭＡＣサブヘッダは、セカンダリキャリア用ＰＨＲのサイズを指示する情報も共に格納される。

以後、ステップ２７３５において、基地局は、ステップ２７３０で端末が伝送したＰＨＲを受信すると、端末の各キャリア別ＰＨをステップ２７３０で報告された値にアップデートした後、アップリンクスケジューリング時に参照する。

本発明の上記した第１０の実施形態においてキャリアは、よくセルと同一の意味で理解され、プライマリキャリアはプライマリセルとして、セカンダリキャリアはセカンダリセルとして理解され得る。

図２９は、本発明の実施形態による端末の構成を示すブロック構成図である。図２９の端末は、送受信部２９０５、制御部２９１０、マルチプレクサ及びデマルチプレクサ２９２０、制御メッセージ処理部２９３５、及び各種上位階層処理部２９２５，２９３０を含む。

図２９において、送受信部２９０５は、ダウンリンクキャリアでデータ及び所定の制御信号を受信し、アップリンクキャリアでデータ及び所定の制御信号を伝送する。複数のキャリアが設定された場合、送受信部２９０５は、複数のキャリアでデータ送受信及び制御信号送受信を遂行する。

マルチプレクサ及びデマルチプレクサ２９２０は、上位階層処理部２９２５，２９３０又は制御メッセージ処理部２９３５で発生したデータを多重化したり、送受信部２９０５から受信したデータを逆多重化して適切な上位階層処理部２９２５，２９３０又は制御メッセージ処理部２９３５に伝送する。マルチプレクサ及びデマルチプレクサ２９２０は、制御部２９１０から受信した制御メッセージ、例えばＢＳＲ又はＰＨＲをＭＡＣ ＰＤＵに多重化する。

制御メッセージ処理部２９３５は、ネットワークにより伝送された制御メッセージを処理して必要な動作を遂行する。このとき、制御メッセージ処理部２９３５は、制御メッセージに格納されたキャリア関連情報を制御部２９１０に伝送する。上位階層処理部２９２５，２９３０は、サービス別に構成でき、ＦＴＰやＶｏＩＰのようなユーザーサービスで発生するデータを処理してマルチプレクサ及びデマルチプレクサ２９２０に伝送するか、あるいはマルチプレクサ及びデマルチプレクサ２９２０から受信したデータを処理して上位階層のサービスアプリケーションに伝送する。

制御部２９１０は、送受信部２９０５を通じて受信されたスケジューリング命令、例えばアップリンクグラントを解析し、適切なタイミングで適切な伝送リソースでアップリンク伝送が遂行されるように、送受信部２９０５とマルチプレクサ及びデマルチプレクサ２９２０を制御する。また、制御部２９１０は、ＢＳＲ又はＰＨＲのようなスケジューリング情報を適切なタイミングで生成してマルチプレクサ及びデマルチプレクサ２９２０に伝送する。すなわち、制御部２９１０は、上記した第１の実施形態から第３の実施形態、及び第７の実施形態で説明した方法の中で所定の方法に従ってＢＳＲが遂行されるように制御する。すなわち、制御部２９１０は、ＢＳＲの生成条件が満足されると、ＢＳＲの生成に使用するバッファ状態テーブルを決定し、同一のサブフレームに対して複数のアップリンクグラントが受信される場合、どのタイミングで論理チャンネル優先順位化過程に進行し、いつＢＳＲフォーマットとＢＳＲのバッファ状態値を決定するかを判定する。また、制御部２９１０は、上記した第４の実施形態から第６の実施形態、及び第８の実施形態と第１０の実施形態で説明した方法の中で所定の方法によってＰＨＲが遂行されるように制御する。すなわち制御部２９１０は、ＰＵＳＣＨ用電力ヘッドルーム情報のトリガ可否をアップリンクキャリア別に判定する。制御部２９１０は、任意のアップリンクキャリアに対するＰＨＲ ＭＡＣ ＣＥの生成において、ＰＵＣＣＨ用電力ヘッドルーム情報も共に格納するか否かを判定する。制御部２９１０は、任意のアップリンクキャリアに対するＰＨＲ機能の活性化の可否を判定する。制御部２９１０は、アップリンク伝送のためのアップリンクグラントを受信すると、ＰＨＲ機能が設定されたアップリンクキャリアのＰＨＲタイマを再駆動するか否かを判定する。また、制御部２９１０は、第９の実施形態で説明したプライマリキャリア変更方法によって基地局から受信したプライマリキャリア変更制御メッセージに従って新たな又は以前プライマリキャリアのビット位置を設定できる。

図３０は、本発明の実施形態による基地局の構成を示すブロック構成図である。

図３０を参照すると、図３０の基地局装置は、送受信部３００５、制御部３０１０、マルチプレクサ及びデマルチプレクサ３０２０、制御メッセージ処理部３０３５、各種上位階層処理部３０２５，３０３０、及びスケジューラ３０４０を含む。

送受信部３００５は、アップリンクキャリアでデータ及び所定の制御信号を受信し、ダウンリンクキャリアでデータ及び所定の制御信号を伝送する。複数のキャリアが設定された場合、送受信部３００５は、複数のキャリアでデータ送受信及び制御信号送受信を遂行する。

マルチプレクサ及びデマルチプレクサ３０２０は、上位階層処理部３０２５，３０３０又は制御メッセージ処理部３０３５で発生したデータを多重化したり、送受信部３００５から受信したデータを逆多重化して適切な上位階層処理部３０２５，３０３０又は制御メッセージ処理部３０３５に伝送する。マルチプレクサ及びデマルチプレクサ３０２０は、制御部３０１０から受信した制御メッセージ、例えばＢＳＲ又はＰＨＲをＭＡＣ ＰＤＵから逆多重化して制御部３０１０に伝送する。

制御メッセージ処理部３０３５は、所定の制御メッセージを生成してマルチプレクサ及びデマルチプレクサ３０２０に伝送したり、マルチプレクサ及びデマルチプレクサ３０２０から受信した制御メッセージを処理する動作を遂行する。制御メッセージ処理部３０３５は、例えば任意の端末にキャリアを追加に設定する制御メッセージを生成してマルチプレクサ及びデマルチプレクサ３０２０に伝送できる。例えば、上位階層処理部３０２５，３０３０は、特定端末別に各々のサービスで構成でき、ＦＴＰ又はＶｏＩＰのようなユーザーサービスで発生するデータを処理してマルチプレクサ及びデマルチプレクサ３０２０に伝送し、あるいはマルチプレクサ及びデマルチプレクサ３０２０から受信したデータを処理して上位階層のサービスアプリケーションに伝送する。

また、制御部３０１０は、ＢＳＲとＰＨＲのようなスケジューリング情報を解析してスケジューラ３０４０に端末のバッファ状態又は電力ヘッドルームを通知する。上記した第１の実施形態から第３の実施形態、及び第７の実施形態で説明した方法の中で所定の方法でＢＳＲが遂行されるように制御する。すなわち、制御部３０１０は、受信したＢＳＲがどのバッファ状態テーブルに基づいて構成されるかを判断し、ＢＳＲから端末に格納された伝送可能なデータの量と伝送可能なデータが格納された論理チャンネルグループを認知し、この情報をスケジューラ３０４０に通知する。制御部３０１０は、第４の実施形態から第６の実施形態、第８の実施形態及び第１０の実施形態で説明した方法の中で所定の方法でＰＨＲが遂行されるように制御する。制御部３０１０は、受信したＰＨＲから電力ヘッドルーム情報を駆動してスケジューラ３０４０に通知する。マルチプレクサ及びデマルチプレクサ３０２０は、送受信部３００５から受信したＭＡＣ ＰＤＵのサブヘッダを確認して適切な上位階層処理部３０２５，３０３０に伝送する。マルチプレクサ及びデマルチプレクサ３０２０は、ＭＡＣ ＰＤＵにＢＳＲ又はＰＨＲが格納されている場合、格納された情報を制御部３０１０に伝送する。マルチプレクサ及びデマルチプレクサ３０２０は、ＰＣＣに対するＰＨＲが格納されたＭＡＣ ＰＤＵを受信すると、ペイロード部分からＰＵＳＣＨに対する電力ヘッドルーム情報とＰＵＣＣＨに対する電力ヘッドルーム情報ともを包含するＰＨＲ ＭＡＣ ＣＥを逆多重化して制御部３０１０に伝送する。スケジューラ３０４０は、端末のバッファ状態、チャンネル状態などを考慮して端末別に伝送リソースを割り当て、伝送フォーマットを決定する動作を遂行する。また、制御部３０１０は、第９の実施形態で説明したプライマリキャリア変更方法によって端末にプライマリキャリア変更制御メッセージを伝送し、端末が新たな又は以前プライマリキャリアのビット位置を設定可能なようにする。

１０５，１１０，１１５，１２０ 次世代基地局（Ｅｖｏｌｖｅｄ Ｎｏｄｅ Ｂ、‘ＥＮＢ’、‘Ｎｏｄｅ Ｂ’）
１２５ ＭＭＥ（Ｍｏｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ Ｅｎｔｉｔｙ）
１３０ Ｓ‐ＧＷ（Ｓｅｒｖｉｎｇ‐Ｇａｔｅｗａｙ）１３０
１３５ ユーザー端末（Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ：‘ＵＥ’）
２０５，２４０ ＰＤＣＰ（Ｐａｃｋｅｔ Ｄａｔａ Ｃｏｎｖｅｒｇｅｎｃｅ Ｐｒｏｔｏｃｏｌ）
２１０，２３５ 無線リンク制御（Ｒａｄｉｏ Ｌｉｎｋ Ｃｏｎｔｒｏｌ：ＲＬＣ）
２１５，２３０ ＭＡＣ（Ｍｅｄｉｕｍ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ
２２０，２２５ 物理階層
３０５ 基地局
３１５ キャリア
３３０ 端末
４０５ 端末
４１０ 基地局
７０５ サブヘッド部分
７１０ ペイロード部分
７１５ 論理チャンネル識別子
７２０ 長さフィールド（Ｌｅｎｇｔｈ：Ｌ）
７２５ Ｒ（Ｒｅｓｅｒｖｅｄ）ビット
７３０ Ｅフィールド
７３５ Ｆビット
８１０ Ｒビット
１０００ 基準バッファ状態が
１００５ 基地局
１０１０ 中継器
１０１５ 端末
１１０５ ＤＬ ＣＣ１ １１２０とＤＬ ＣＣ３ １１３０との間の受信タイミングの差
１１１０ ＤＬ ＣＣ３ １１３０とＤＬ ＣＣ４ １１３５との間の受信タイミングの差
１１１５ ＤＬ ＣＣ１ １１２０とＤＬ ＣＣ２ １１２５との間の受信タイミングの差
１４０５ 論理チャンネル識別子
１４１０ ＰＵＳＣＨ ＰＨＲ
１４１５ ＰＵＣＣＨ ＰＨＲ
１４２５ ＰＵＳＣＨ ＰＨＲ
２５０５ ＭＡＣサブヘッダ
２５１０ ペイロード
２５１５ 論理チャンネル識別子フィールド
２５３０ ペイロードの６ビット
２６１０ プライマリキャリア用ＰＨＲ２６３５のペイロード
２６２０ ペイロード２６１０の１番目のバイト
２６２５ ＰＵＣＣＨ用ＰＨが２番目のバイト
２６４５ ＭＡＣサブヘッダ
２６５０ セカンダリキャリア用ＰＨＲ２６７０のペイロード
２６５５ セカンダリキャリア用論理チャンネル識別子
２６６０ 識別子（ＰＨＲ用セカンダリキャリア識別子）、セカンダリキャリア用ＰＨＲ２６７０のペイロード２６５０の１番目の２ビット
２６６５ ペイロードの残り６ビット
２６７５，２６８０ ＭＡＣサブヘッダ２６４５の使用しない２ビット
２７０５ 端末
２７１０ 基地局
２９０５ 送受信部
２９１０ 制御部
２９２０ マルチプレクサ及びデマルチプレクサ
２９２５，２９３０ 上位階層処理部
２９３５ 制御メッセージ処理部
３００５ 送受信部
３０１０ 制御部
３０２０ マルチプレクサ及びデマルチプレクサ
３０２５，３０３０ 上位階層処理部
３０３５ 制御メッセージ処理部
３０４０ スケジューラ

Claims (14)

1. ユーザー端末（ＵＥ）により基地局に電力ヘッドルーム報告（ＰＨＲ）を送信するための方法であって、
   アップリンクコンポーネントキャリア（ＵＬ ＣＣ）に対するＰＨＲがトリガされるか否かを判断するステップと、
   前記ＰＨＲがトリガされる場合、物理的アップリンク制御チャンネル（ＰＵＣＣＨ）の電力ヘッドルーム（ＰＨ）が報告されるように構成されるか否かを判断するステップと、
   前記ＰＵＣＣＨのＰＨが報告されるように構成される場合、前記ＵＬ ＣＣに対する前記ＰＵＣＣＨのＰＨ及び物理的アップリンク共有チャンネル（ＰＵＳＣＨ）のＰＨの両方ともを含むＰＨＲを生成するステップと、
   前記ＰＵＳＣＨのＰＨ及び前記ＰＵＣＣＨのＰＨの両方ともを含むＰＨＲを前記基地局に送信するステップと、を含み、
   前記ＰＵＣＣＨに対するＰＨＲは、前記ＰＵＳＣＨに対するＰＨＲと同一のトリガ条件で共にトリガされるよう設定され、
   前記ＰＵＳＣＨのＰＨ及び前記ＰＵＣＣＨのＰＨの両方ともを含むＰＨＲは、同一の論理チャンネル識別子（ＬＣＩＤ）により示されることを特徴とする、方法。
2. 前記ＵＬ ＣＣに対するＰＨＲがトリガされるか否かを判断するステップは、
   前記ＵＬ ＣＣに連関するダウンリンクキャリアの経路損失が閾値を超過して変更されたか否かを判断するステップ、または、
   周期的ＰＨＲタイマが満了したか否かを判断するステップを含むことを特徴とする、請求項１に記載の方法。
3. 前記ＰＵＣＣＨのＰＨが報告されるように構成されない場合、前記ＰＵＳＣＨのＰＨのみを含むＰＨＲを生成するステップをさらに含むことを特徴とする、請求項１に記載の方法。
4. 前記ＰＵＳＣＨのＰＨ及び前記ＰＵＣＣＨのＰＨの両方ともを含むＰＨＲ、及び論理チャンネル識別子（ＬＣＩＤ）を含むＰＨＲメディアアクセス制御（ＭＡＣ）制御エレメント（ＣＥ）を生成するステップをさらに含み、
   前記ＰＨＲを送信するステップは、前記生成されたＰＨＲ ＭＡＣ ＣＥを送信するステップを含むことを特徴とする、請求項１に記載の方法。
5. 前記ＵＥが前記ＰＵＳＣＨ及び前記ＰＵＣＣＨを同時に伝送できるか否かを判断するステップをさらに含み、
   前記ＰＨＲを生成するステップは、前記ＵＥが前記ＰＵＳＣＨ及び前記ＰＵＣＣＨを同時に伝送でき、また前記ＰＵＣＣＨのＰＨが報告されるように構成されると、前記ＰＵＳＣＨのＰＨ及び前記ＰＵＣＣＨのＰＨの両方ともを含むＰＨＲを生成するステップを含むことを特徴とする、請求項１に記載の方法。
6. ユーザー端末（ＵＥ）であって、
   アップリンクコンポーネントキャリア（ＵＬ ＣＣ）に対する電力ヘッドルーム報告（ＰＨＲ）がトリガされるか否かを判断し、
   前記ＰＨＲがトリガされる場合、物理的アップリンク制御チャンネル（ＰＵＣＣＨ）の電力ヘッドルーム（ＰＨ）が報告されるように構成されるか否かを判断し、
   前記ＰＵＣＣＨのＰＨが報告されるように構成される場合、前記ＵＬ ＣＣに対する前記ＰＵＣＣＨのＰＨ及び物理的アップリンク共有チャンネル（ＰＵＳＣＨ）のＰＨの両方ともを含むＰＨＲを生成するように構成される制御部と、
   前記ＰＵＳＣＨのＰＨ及び前記ＰＵＣＣＨのＰＨの両方ともを含むＰＨＲを基地局に送信するように構成される送受信器と、を含み、
   前記ＰＵＣＣＨに対するＰＨＲは、前記ＰＵＳＣＨに対するＰＨＲと同一のトリガ条件で共にトリガされるよう設定され、
   前記ＰＵＳＣＨのＰＨ及び前記ＰＵＣＣＨのＰＨの両方ともを含むＰＨＲは、同一の論理チャンネル識別子（ＬＣＩＤ）により示されることを特徴とする、ユーザー端末（ＵＥ）。
7. 前記ＵＬ ＣＣに対するＰＨＲがトリガされるか否かを判断することは、
   前記ＵＬ ＣＣに連関するダウンリンクキャリアの経路損失が閾値を超過して変更されたか否かを判断すること、または、
   周期的ＰＨＲタイマが満了したか否かを判断することを含むことを特徴とする、請求項６に記載のユーザー端末（ＵＥ）。
8. 前記制御部は、さらに、
   前記ＰＵＣＣＨのＰＨが報告されるように構成されない場合、前記ＰＵＳＣＨのＰＨのみを含むＰＨＲを生成するように構成されることを特徴とする、請求項７に記載のユーザー端末（ＵＥ）。
9. 前記制御部は、さらに、
   前記ＰＵＳＣＨのＰＨ及び前記ＰＵＣＣＨのＰＨの両方ともを含むＰＨＲ、及び論理チャンネル識別子（ＬＣＩＤ）を含むＰＨＲメディアアクセス制御（ＭＡＣ）制御エレメント（ＣＥ）を生成するように構成され、
   前記ＰＨＲを送信することは、前記生成されたＰＨＲ ＭＡＣ ＣＥを送信することを含むことを特徴とする、請求項６に記載のユーザー端末（ＵＥ）。
10. 前記制御部は、さらに、
    前記ＵＥが前記ＰＵＳＣＨ及び前記ＰＵＣＣＨを同時に伝送できるか否かを判断するように構成され、
    前記ＰＨＲを生成することは、前記ＵＥが前記ＰＵＳＣＨ及び前記ＰＵＣＣＨを同時に伝送でき、また、前記ＰＵＣＣＨのＰＨが報告されるように構成されると、前記ＰＵＳＣＨのＰＨ及び前記ＰＵＣＣＨのＰＨの両方ともを含むＰＨＲを生成することを含むことを特徴とする、請求項６に記載のユーザー端末（ＵＥ）。
11. 基地局により遂行される方法であって、
    ユーザー端末（ＵＥ）から電力ヘッドルーム報告（ＰＨＲ）を受信するステップと、
    物理的アップリンク制御チャンネル（ＰＵＣＣＨ）の電力ヘッドルーム（ＰＨ）が報告されるように構成されるか否かを判断するステップと、
    前記ＰＵＣＣＨのＰＨが報告されるように構成されると、同一の論理チャンネル識別子（ＬＣＩＤ）により示される前記受信されたＰＨＲから前記ＰＵＣＣＨのＰＨ及び物理的アップリンク共有チャンネル（ＰＵＳＣＨ）のＰＨを獲得するステップを含み、
    前記ＰＵＣＣＨに対するＰＨＲは、前記ＰＵＳＣＨに対するＰＨＲと同一のトリガ条件で共にトリガされるよう設定され、
    前記ＰＵＳＣＨのＰＨ及び前記ＰＵＣＣＨのＰＨの両方ともを含むＰＨＲは、前記同一の論理チャンネル識別子（ＬＣＩＤ）により示されることを特徴とする、基地局により遂行される方法。
12. 前記ＰＵＣＣＨのＰＨが報告されるように構成されないと、前記受信されたＰＨＲから前記ＰＵＳＣＨのＰＨのみを獲得するステップをさらに含むことを特徴とする、請求項１１に記載の基地局により遂行される方法。
13. 基地局であって、
    ユーザー端末（ＵＥ）から電力ヘッドルーム報告（ＰＨＲ）を受信するように構成される送受信器と、
    物理的アップリンク制御チャンネル（ＰＵＣＣＨ）の電力ヘッドルーム（ＰＨ）が報告されるように構成されるか否かを判断し、
    前記ＰＵＣＣＨのＰＨが報告されるように構成されると、同一の論理チャンネル識別子（ＬＣＩＤ）により示される前記受信されたＰＨＲから前記ＰＵＣＣＨのＰＨ及び物理的アップリンク共有チャンネル（ＰＵＳＣＨ）のＰＨを獲得するように構成される制御部と、を含み、
    前記ＰＵＣＣＨに対するＰＨＲは、前記ＰＵＳＣＨに対するＰＨＲと同一のトリガ条件で共にトリガされるよう設定され、
    前記ＰＵＳＣＨのＰＨ及び前記ＰＵＣＣＨのＰＨの両方ともを含むＰＨＲは、前記同一の論理チャンネル識別子（ＬＣＩＤ）により示されることを特徴とする、基地局。
14. 前記制御部は、さらに、
    前記ＰＵＣＣＨのＰＨが報告されるように構成されないと、前記受信されたＰＨＲから前記ＰＵＳＣＨのＰＨのみを獲得するように構成されることを特徴とする、請求項１３に記載の基地局。

Images