JP6017325B2 - バッファ状態報告の指示方法および無線基地局装置 - Google Patents

Description

本発明は、無線通信技術の分野に関し、特に、ユーザ装置に対するバッファ状態報告の指示方法と無線基地局装置に関する。

ＬＴＥ（Long Term Evolution）において、ユーザ装置（ＵＥ）は、送信すべきアップリンクデータが発生した場合、以下のステップで無線基地局（ｅＮＢ）に対してスケジューリング要求を行うことが規定されている（たとえば、非特許文献１参照）。
(1)ステップ１：スケジューリング要求の送信
図１（Ａ）に示すように、ユーザ装置にアップリンクデータが発生したときに、ユーザ装置が個別のアップリンクリソース（ＰＵＣＣＨ）を持っているのであれば、このアップリンクリソースを用いてスケジューリング要求を送信する（PUCCH-SR）。ユーザ装置が個別のアップリンクリソースを保持していない場合は、ランダムアクセス（ＲＡ）手順を起動する。
(2)ステップ２：バッファ状態報告（ＢＳＲ：Buffer Status Report）の送信
ステップ１の要求に対して割り当てられたUL grantに対応するＰＵＳＣＨ（Physical Uplink Shared Channel）にてＢＳＲを送信する。ランダムアクセス手順の場合には、ランダムアクセス応答（RA response）でUL grantが指示される。

図１（Ｂ）に示すように、データが存在する論理チャネルグループ（LCH#A〜LCH#D）ごとにデータの総量が算出されてＢＳＲが報告される。

ユーザ装置（ＵＥ）は、以下の場合にＢＳＲをトリガする。
(1)データが発生したとき、あるいはより優先度の高いデータが発生したとき
(2)送信すべきデータがなくなった場合
(3)ＭＡＣ ＰＤＵ（Medium Access Control Protocol Data Unit）の余剰ビット数がＢＳＲ格納に必要なビット数よりも大きい場合（Padding BSR）
(4)Periodic BSRタイマが満了した場合（周期的なＢＳＲトリガ）

３ＧＰＰ，ＴＳ３６．３２１

現状では、ＢＳＲはユーザ装置（ＵＥ）におけるトリガでしか報告することができないため、ｅＮＢがリアルタイムにＵＥ内のバッファ滞留量を把握することができない。

たとえば、ＢＳＲが無線で欠落すると、ｅＮＢ側でリアルタイムにＵＥのバッファ滞留量を把握することができない。ＵＥの周期的なＢＳＲのトリガを頻繁に行なうことも考えられるが、頻度が多すぎると、ＢＳＲ報告が不要な場合にもＢＳＲが報告されてしまい、リソース効率の観点から望ましくない。

そこで、本発明は、無線基地局でユーザ装置のバッファ滞留量をリアルタイムで把握することのできるバッファ状態報告の指示方法と無線基地局装置の構成を提供する。

第１の態様では、バッファ状態報告の指示方法を提供する。この方法は、
無線基地局において、ユーザ装置に対してバッファ状態報告をトリガさせる契機となる条件を設定し、
前記条件が満たされる場合に、前記無線基地局から前記ユーザ装置に対してバッファ状態報告トリガ指示を送信し、
前記無線基地局で、前記バッファ状態報告トリガ指示に応答するバッファ状態報告を前記ユーザ装置から受信する、
ことを特徴とする。

第２の態様では、無線基地局装置を提供する。無線基地局装置は、
ユーザ装置に対してバッファ状態報告のトリガを指示する条件を設定し、前記条件が満たされる場合に、前記ユーザ装置に対するバッファ状態報告トリガ指示を生成するアップリンクバッファ管理部と、
前記バッファ状態報告トリガ指示を前記ユーザ装置に送信する送信部と、
前記バッファ状態報告トリガ指示に応答するバッファ状態報告を前記ユーザ装置から受信する受信部と、
を有する。

無線基地局装置にて、ユーザ装置のバッファ滞留量をリアルタイムで把握することが可能になる。

ＬＴＥにおけるＢＳＲ制御の概要を示す図である。 実施形態のＢＳＲ報告の一例を示す図である。 実施形態のＢＳＲ報告を別の例を示す図である。 ユーザ装置で行われる処理を示すフローチャートである。 ユーザ装置の構成例を示す図である。 ネットワーク（ｅＮＢ）で行われる処理を示すフローチャートである。 ｅＮＢの構成例を示す図である。

以下で図面を参照して実施形態を説明する。
＜ユーザ装置における動作＞
図２は、ユーザ装置（ＵＥ）によるＢＳＲの送信動作の一例を示す図である。ユーザ装置は、無線基地局（ｅＮＢ）からの指示に従ってバッファ状態報告（ＢＳＲ）をトリガする。図２の例では、ｅＮＢはＢＳＲのトリガ指示のみを行ない、ＢＳＲ送信用の無線リソースであるUL-SCH（Uplink Shared Channel）を、別途割り当てる。この場合、トリガした後の動作は現状のＢＳＲ制御に準拠する。

具体的には、ユーザ装置は、ｅＮＢからＢＳＲトリガ指示を受信する（Ｓ１）。ＢＳＲトリガ指示は、たとえば、ＭＡＣ（Media Access Control）制御エレメント（ＣＥ：Control Element）や、無線リソース制御（ＲＲＣ：Radio Resource Control）信号、物理ダウンリンク制御チャネル（ＰＤＣＣＨ）により送信されてくる。

ユーザ装置は、ＢＳＲトリガ指示の受信に基づいて、ＢＳＲをトリガする（Ｓ２）。ＢＳＲトリガ指示に引き続いて、ユーザ装置はＢＳＲ送信用のリソースを指示するUL grantをｅＮＢから受信する（Ｓ３）。ユーザ装置は、UL-grantに対応するＰＵＳＣＨでＢＳＲを送信する（Ｓ４）。

ｅＮＢからのＢＳＲトリガ指示によりユーザ装置でＢＳＲがトリガされた場合、ユーザ装置はスケジューリング要求（ＳＲ）をトリガしなくてもよい。

この方法によると、ユーザ装置は従来のＢＳＲトリガのタイミングを待たずに、ｅＮＢの指示にしたがってバッファ滞留情報を送信することができる。逆にいうと、ｅＮＢはユーザ装置によるＢＳＲトリガのタイミングよりも早く、所望のタイミングでバッファ滞留情報を取得することができる。

図３は、ユーザ装置によるＢＳＲの送信動作の別の例を示す図である。図３の例では、ユーザ装置は、ｅＮＢからＢＳＲのトリガ指示と同時に、ＢＳＲ送信用のリソースを指定するUL-grantを受信する（Ｓ５）。ユーザ装置はこのトリガ指示に基づいて、ＢＳＲをトリガし（Ｓ６）、トリガ指示で割り当てられたUL-SCHで必ずＢＳＲを送信する。すなわち、ユーザ装置は、ｅＮＢからアップリンクリソースの割り当てとともにトリガ指示を受け取ったときは、ＢＳＲよりも優先度の高いデータがある場合でも、ＢＳＲを最優先でネットワーク（ｅＮＢ）に送信する。このときのトリガ指示は、UL-grantのＰＤＣＣＨ内で指示されてもよい。

この方法でも、ユーザ装置はＢＳＲトリガのタイミングを待たずに、ｅＮＢの指示にしたがってバッファ滞留情報を送信することができる。ｅＮＢはユーザ装置によるＢＳＲトリガのタイミングよりも早く、所望のタイミングでバッファ滞留情報を取得することができる。

次に、ＢＳＲ送信の適用例として、アップリンクキャリア・アグリゲーション（UL CA）が設定されている場合を説明する。

キャリア・アグリケーションは、２０ＭＨｚを超える広帯域通信（たとえば１００ＭＨｚ）を実現するために、複数のコンポーネントキャリアを束ねて通信を行う手法である。キャリア・アグリゲーションは、同一基地局（ｅＮＢ）配下のセル間でコンポーネントキャリアを束ねるだけではなく、異なる基地局（ｅＮＢ）配下のセルを束ねるサイト間キャリア・アグリゲーション（Inter-site CA）も含む。Inter-site CAにより、さらに柔軟なネットワーク・アーキテクチャが実現される。

サイト間アップリンクキャリア・アグリゲーションの場合、たとえば、ユーザ装置が在圏する無線基地局（たとえばマクロｅＮＢ）の配下のセルを、信頼性の高いプライマリセル（PCell：primary serving cell）に設定し、他の無線基地局の配下のセル（他のマクロセルあるいはスモールセル）を補足的（additional）なセカンダリセル（SCell：secondary serving cell）に設定することができる。

ユーザ装置とセカンダリセルのｅＮＢとの間の接続は、プライマリセルのｅＮＢまたはネットワーク側で管理することができる。図２及び図３のように、ユーザ装置がＢＳＲトリガ指示に応じてＢＳＲをトリガする場合、ＢＳＲをプライマリセルのＰＵＳＣＨで送信してもよい。あるいは、セカンダリセルの中で、最も大きい、または最も小さいインデックス番号（SCell-Index）を有するセカンダリセルのｅＮＢに送信してもよい。この場合、ＢＳＲを受信したセカンダリセルが、ユーザ装置のバッファ滞留量に応じてユーザ装置のためのスケジューリングを行う。

あるいは、セカンダリセルの中で、品質がよいと推定されるセカンダリセルのｅＮＢにＢＳＲを送信してもよい。品質がよいセルとは、たとえば、ＣＱＩが良いセルや、UL HARQ（Uplink Hybrid Automatic Repeat reQuest）再送回数が少ないセルである。

あるいは、ユーザ装置はｅＮＢの指定にしたがってＢＳＲを送信すべきセルを認識し、指定されたｅＮＢにＢＳＲを送信してもよい。ＢＳＲ送信先のセルは、ＭＡＣ制御エレメントやＰＤＣＣＨ（物理ダウンリンク制御チャネル）によりダイナミックに指定されてもよいし、ＲＲＣ信号によりsemi-staticに指定されてもよい。

さらに、ユーザ装置が複数のｅＮＢに接続されている場合、どのｅＮＢに対してＢＳＲを送信すべきかの指示をネットワークから受信する構成としてもよい。たとえば、ユーザ装置が制御プレーン（C-plane）のデータの送受信のためにプライマリセルのｅＮＢに接続されるとともに、ユーザプレーン（U-plane）のデータ送信のためにセカンダリセルのｅＮＢに接続されている場合、ユーザ装置はプライマリセルのｅＮＢから、ＢＳＲの送信先となるｅＮＢの指示を受信する構成としてもよい。

さらに別の適用例として、ユーザ装置がｅＮＢからのＢＳＲトリガ指示にしたがってＢＳＲを送信した場合は、ＢＳＲ関連のタイマを再起動しない構成としてもよい。現状ではユーザ装置がＢＳＲを報告すると、ユーザ装置のPeriodic BSRタイマは最初から再起動される。しかし、実施形態の適用例では、周期的ＢＳＲタイマを新たに再起動せずに、起動されている現在の状態をそのまま維持してもよい。ＢＳＲタイマの現状を維持することによって、ＢＳＲ送信から新たに周期がカウントされることを防止し、ＢＳＲタイマの満了のタイミングで次のＢＳＲを早めに送信することができる。

図４は、ユーザ装置が行う処理フローを示す図である。まず、ユーザ装置におけるＢＳＲトリガの条件が満たされているか否かを判断する(Ｓ１０１)。ＢＳＲトリガの条件が満たされている場合とは、たとえば、
(a)ユーザ装置でデータが発生した場合（送信すべきデータがない状態から新たにデータは発生した場合と、送信データある状態で別のデータが発生した場合の双方を含む）、
(b)送信すべきデータがなくなった場合、
(c)MAC PDUの余剰ビット数がＢＳＲ格納に必要なビット数よりも大きい場合、
(d)Periodic BSRタイマが満了した場合、
などである。

ＢＳＲトリガの条件が満たされている場合は（Ｓ１０１でＹＥＳ）、ユーザ装置はＢＳＲをトリガする（Ｓ１０３）。

ＢＳＲトリガの条件が満たされていない場合は（Ｓ１０１でＮＯ）、ｅＮＢからＢＳＲトリガ指示を受けているか否かを判断する（Ｓ１０２）。ＢＳＲトリガ指示を受けている場合は（Ｓ１０２でＹＥＳ）、ユーザ装置は、ＢＳＲをトリガする（Ｓ１０３）。ＢＳＲトリガ指示を受けていない場合は（Ｓ１０２でＮＯ）、ステップＳ１０１に戻って、ＢＳＲトリガの条件が満たされるか否かを判断する。

この処理により、ユーザ装置は、ＬＴＥにおける通常のＢＳＲ制御に加えて、ｅＮＢからのＢＳＲトリガ指示にしたがったＢＳＲの報告を行うことができる。

図５は、ユーザ装置１０の構成例を示すブロック図である。ユーザ装置は、ダウンリンク（ＤＬ）信号受信部１１と、アップリンク（ＵＬ）信号送信部１２と、ＭＡＣ管理部１３と、アップリンク（ＵＬ）バッファ管理部１５を有する。ＭＡＣ管理部１３は、ＢＳＲ管理部１４を含む。

ＤＬ信号受信部１１は、図示しないアンテナを介して、ダウンリンクの無線信号を受信する。ＵＬ信号送信部１２は、図示しないアンテナを介して、アップリンクの無線信号を送信する。アンテナやベースバンド処理部等は、本発明と直接関係がないので図示を省略しているが、ＤＬ信号受信部１１とＵＬ信号送信部１２のＲＦ側は、１以上のアンテナ素子に接続され、ベースバンド側はベースバンド処理部（ディジタル信号処理部を含む）に接続されている。

ＭＡＣ管理部１３は、MAC PDU (Protocol Date Unit)の生成・処理や、ＨＡＲＱ（Hybrid Automatic Repeat Request）管理、ＲＡＣＨ管理等を行う。ＢＳＲ管理部１４は、ＢＳＲの生成、処理を行なう。ＵＬバッファ管理部１５は、アップリンクのバッファ滞留量を監視し、アップリンクのバッファ滞留量をＢＳＲ管理部１４に通知する。

ＢＳＲ管理部１４は、ＤＬ信号受信部１１にてＢＳＲトリガ指示を受信した場合に、ＵＬバッファ管理部１５からの情報に基づいてＢＳＲを生成し、ＵＬ信号送信部１２を介してＢＳＲを送信させる。

このような構成により柔軟なＢＳＲ報告が実現される。
＜ｅＮＢにおける動作＞
図６は、ｅＮＢによる処理を示すフローチャートである。ｅＮＢはネットワークにおけるＢＳＲトリガ指示（報告指示）の条件が満たされるか否かを判断する（Ｓ２０１）。条件が満たされる場合は、ユーザ装置に対してＢＳＲトリガ指示（報告指示）を送信する（Ｓ２０２）。

ＢＳＲトリガ指示の条件が満たされて（Ｓ２０１でＹＥＳ）、ＢＳＲトリガ指示を出す場合とは、たとえば以下の場合である。
(1)バッファ滞留量（データ）がない旨のＢＳＲを受信した後に所定期間が経過した場合にＢＳＲトリガ指示を出す。

たとえば、ユーザ装置にデータがなくなった後でも、ＴＣＰ（Transport Control Protocol）ＡＣＫのように遅延要求の厳しいデータが発生している可能性を見越して、すぐにアップリンクリソースの割り当てができるようにＢＳＲをトリガし、できるだけ早く遅延要求の厳しいデータ発生の有無を把握できるようにする。
(2)最後にＢＳＲを受信してから所定期間が経過しても後続のＢＳＲを受信できない場合にＢＳＲトリガ指示を出す。

たとえば、データ通信中にユーザ装置内でさらなるデータが発生した場合に、ｅＮＢでできるだけ早期にこのデータ発生を把握して、スケジューリングに活かすことができる。
(3)ＢＳＲの受信にかかわらず、周期がきたときにＢＳＲトリガ指示を出す（周期的なトリガ）。トリガの周期は、たとえばトラヒックの統計に基づいて決定することができる。ユーザ装置の種類によっては、一定期間ごとにバックグラウンドデータが発生するものがあるので、その周期に合わせてもよい。
(4)キャリア・アグリゲーション（ＣＡ）を行う、あるいはセカンダリセルを解除（deconfigure）する際にＢＳＲトリガ指示を出す。

たとえば、セカンダリセル（SCell）を追加またはアクティベートする際や、アップリンクキャリア・アグリゲーション（UL CA）の場合はアップリンクタイミングアライメントを行った際に、最新のＢＳＲを受信しておけば、SCellにおけるスケジューリングを早期にはじめることができる。

また、セカンダリセルをdeactivate／deconfigureするに先立って、念のためアップリンクデータ滞留量を確認して、データが少ないかほとんど無いことを担保する構成としてもよい。このとき、アップリンクデータ滞留量が多いようであれば、SCellのdeactivate／deconfigureを中止してもよい。
(5)ユーザ装置をＩＤＬＥ遷移させる場合にＢＳＲトリガ指示を出す。

ユーザ装置をＩＤＬＥ遷移させる際に念のためＢＳＲでバッファ滞留量を確認することで、ＩＤＬＥ遷移させるぎりぎりのタイミングでデータが発生している場合に、アップリンクデータがあるにもかかわらずＩＤＬＥ遷移してしまう事態を回避することができる。アップリンクデータがあるのにＩＤＬＥ遷移すると、アップリンクデータ再開までに時間がかかるので、ＩＤＬＥ遷移に先立ってＢＳＲトリガ指示を出すことに意義がある。
(6)ＢＳＲトリガ指示を送信したにもかかわらず、所定期間ＢＳＲを受信できない場合に、ＢＳＲトリガ指示を再送する。
(7)Truncate BSRを受信した場合にＢＳＲトリガ指示を出す。

Truncate BSRではユーザ装置のバッファ滞留量の一部しか報告されていないため、正確かつ十分なバッファ滞留情報を取得するために、Truncate BSRを受信した場合は、即座に後続のＢＳＲをトリガするのが望ましい。
(8)割当要求（Scheduling Request）に対して割り当てを行ったが、所定期間ＢＳＲを受信できない場合にＢＳＲトリガ指示を出す。

Scheduling Requestに対する割り当てを行った場合、ユーザ装置は最初のUL grantに応えてＢＳＲを格納してくるはずであるが、ＢＳＲが受信できないということは、最初のUL grantに対応するＰＵＳＣＨが無線で欠落した可能性がある。この場合、できるだけ早期にＢＳＲを受信するためにＢＳＲトリガ指示を出すのが望ましい。
(9)DRX command MAC CEによりユーザ装置を強制的にＤＲＸ（間欠受信）状態に遷移させる場合にＢＳＲトリガ指示を出す。ＤＲＸ状態に遷移させる前に、アップリンクデータが発生していないことを担保することができる。
(10)DL SRB（Signaling Radio Bearer）データをユーザ装置に送信してから、所定期間内にユーザ装置からＢＳＲを受信できない場合に、ＢＳＲトリガ指示を出す。

基本的には、DL SRBデータをユーザ装置が受信すると、ユーザ装置はそれに対するＲＲＣ（Radio Resource Control）レベルあるいはＲＬＣ（Radio Link Control）レベルのフィードバック情報を送信する。したがって、そのようなフィードバック情報が発生したことをＢＳＲで報告するはずである。そこで、フィードバック情報が発生したか否か、あるいはDL SRBデータを受信できたか否かを確認するためにＢＳＲトリガ指示を出してもよい。
(11)ｅＮＢが認識するアップリンクデータ滞留量が残り少なくたってきた場合（たとえば所定バイト以下になった場合）に、ＢＳＲトリガ指示を出す。

このタイミングで指示を出すことにより、たとえば、直前のＢＳＲでバッファ滞留量が５００Byteとして報告を受け、これに対して４９０Byte分のデータに対してリソースを割り当て、残り１０Byte分の割り当てを行うときに、ユーザ装置で多量のデータが発生していないかどうかを確認することができる。

これらは、ｅＮＢ主導でのＢＳＲトリガ指示の条件の一例である。ｅＮＢからユーザ装置に対してＢＳＲトリガ指示を出すことによって、ｅＮＢはユーザ装置のＢＳＲタイミングを待たずに、所望のタイミングでバッファ滞留量情報を取得することができる。

図７は、ｅＮＢ（無線基地局）２０の概略ブロック図である。ｅＮＢ２０は、ダウンリンク（ＤＬ）信号送信部２１と、アップリンク（ＵＬ）信号受信部２２と、ＭＡＣスケジューラ部２３と、アップリンク（ＵＬ）バッファ管理部２４を有する。ＵＬバッファ管理部２４は、ＢＳＲ処理部２５を含む。

ＤＬ信号送信部２１は、図示しないアンテナを介して、ダウンリンクの無線信号を送信する。ＵＬ信号受信部２２は、図示しないアンテナを介して、アップリンクの無線信号を受信する。アンテナやベースバンド処理部等は、本発明と直接関係がないので図示を省略しているが、ＤＬ信号送信部２１とＵＬ信号受信部２２のＲＦ側は、１以上のアンテナ素子に接続され、ベースバンド側はベースバンド処理部（ディジタル信号処理部を含む）に接続されている。

ＭＡＣスケジューラ部２３は、各ユーザ装置に共有チャネル上の無線リソースを割り当てる。ＵＬバッファ管理部２４は、各ユーザ装置について、ＢＳＲトリガ指示の条件が満たされるか否かを判断する。ＢＳＲトリガ指示の条件の例は上述したとおりである。ＢＳＲトリガ指示の条件が満たされる場合、ＵＬバッファ管理部２４はＢＳＲトリガ指示を生成し、ＤＬ信号送信部２１を介してＢＳＲトリガ指示をユーザ装置に送信させる。

図２のように、ＢＳＲトリガ指示とUL grantが別個に送信される場合は、ＵＬバッファア管理部２４は、ＢＳＲトリガ指示の送信に引き続き、ＭＡＣスケジューラ２３によって割り当てられたアップリンクリソースをユーザ装置に通知する。

図３のように、ＢＳＲトリガ指示と同時にUL grantが送信される場合は、ＵＬバッファ管理部２４は、たとえばUL grantを送信するダウンリンクチャネル（ＰＤＣＣＨなど）にＢＳＲトリガ指示が含まれるように図示しない信号多重部を制御する。

ＢＳＲ処理部２５は、ユーザ装置から報告されるＢＳＲを処理する。ＵＬバッファ管理部２４は、ＢＳＲ処理部２５の処理結果に基づき、ユーザ装置からのＢＳＲが受信されているか否か、ＢＳＲに示されるバッファ滞留量がゼロに近い状態か否か、アップリンクデータ滞留量が残り少なくなってきているか、などを判断する。

上記の構成により、ｅＮＢ２０は所望のタイミングでユーザ装置１０にＢＳＲトリガを実行させ、ユーザ装置のバッファ滞留量をリアルタイムで把握することができる。

１０ ユーザ装置
１１ ＤＬ信号受信部
１２ ＵＬ信号送信部
１３ ＭＡＣ管理部
１４ ＢＳＲ管理部
１５ ＵＬバッファ管理部
２０ ｅＮＢ（無線基地局）
２１ ＤＬ信号送信部
２２ ＵＬ信号受信部
２３ ＭＡＣスケジューラ部
２４ ＵＬバッファ管理部
２５ ＢＳＲ処理部

Claims (17)

1. 無線基地局において、ユーザ装置に対してバッファ状態報告をトリガさせる契機となる条件を設定し、
   前記条件が満たされる場合に、前記無線基地局から前記ユーザ装置に対してバッファ状態報告トリガ指示を送信し、
   前記無線基地局で、前記バッファ状態報告トリガ指示に応答するバッファ状態報告を前記ユーザ装置から受信する
   ことを特徴とするバッファ状態報告の指示方法。
2. 前記無線基地局から前記ユーザ装置に対して、前記バッファ状態報告トリガ指示と同時に、前記バッファ状態報告のためのアップリンクのリソース割り当てを通知することを特徴とする請求項１に記載のバッファ状態報告の指示方法。
3. 前記無線基地局から前記ユーザ装置に対して、前記バッファ状態報告トリガ指示とは別個に前記バッファ状態報告のためのアップリンクリソース割り当てを通知することを特徴とする請求項１に記載のバッファ状態報告の指示方法。
4. 前記無線基地局は、前記ユーザ装置から滞留するデータがない旨のバッファ状態報告を受信した後に所定期間が経過した場合に、前記ユーザ装置に前記バッファ状態報告トリガ指示を送信することを特徴とする請求項１に記載のバッファ状態報告の指示方法。
5. 前記無線基地局は、前記ユーザ装置から最後にバッファ状態報告を受信してから、所定期間が経過しても後続のバッファ状態報告を受信しない場合に、前記ユーザ装置に前記バッファ状態報告トリガ指示を送信することを特徴とする請求項１に記載のバッファ状態報告の指示方法。
6. 前記無線基地局は、前記ユーザ装置からのバッファ状態報告を受信したか否かにかかわらず、前記ユーザ装置に対して周期的に前記バッファ状態報告トリガ指示を送信することを特徴とする請求項１に記載のバッファ状態報告の指示方法。
7. 前記周期は、トラヒックの統計またはユーザ装置の仕様に基づいて決定されることを特徴とする請求項６に記載のバッファ状態報告の指示方法。
8. 前記無線基地局は、前記ユーザ装置のためにキャリア・アグリゲーションを行う際、またはキャリア・アグリゲーション中にセカンダリセルを設定解除する場合に、前記ユーザ装置に対して前記バッファ状態報告トリガ指示を送信することを特徴とする請求項１に記載のバッファ状態報告の指示方法。
9. 前記無線基地局は、前記ユーザ装置をＩＤＬＥ状態または間欠受信状態に遷移させる場合に、前記ユーザ装置に対して前記バッファ状態報告トリガ指示を送信することを特徴とする請求項１に記載のバッファ状態報告の指示方法。
10. 前記無線基地局は、前記ユーザ装置に対して前記バッファ状態報告トリガ指示を送信してから所定期間バッファ状態報告を受信しない場合に、前記バッファ状態報告トリガ指示を再送することを特徴とする請求項１に記載のバッファ状態報告の指示方法。
11. 前記無線基地局は、前記ユーザ装置からトランケートされたバッファ状態報告を受信した場合に、前記ユーザ装置に対して前記バッファ状態報告トリガ指示を送信することを特徴とする請求項１に記載のバッファ状態報告の指示方法。
12. 前記無線基地局は、前記ユーザ装置からのスケジューリング要求に対してアップリンクリソースを割り当てた後、所定期間経過してもバッファ状態報告を受信しない場合に、前記ユーザ装置に対して前記バッファ状態報告トリガ指示を送信することを特徴とする請求項１に記載のバッファ状態報告の指示方法。
13. 前記無線基地局は、前記ユーザ装置に対してシグナリング無線ベアラでデータを送信してから所定期間が経過しても前記ユーザ装置からバッファ状態報告を受信しない場合に、前記ユーザ装置に対して前記バッファ状態報告トリガ指示を送信することを特徴とする請求項１に記載のバッファ状態報告の指示方法。
14. 前記無線基地局は、前記無線基地局で把握する前記ユーザ装置のアップリンクデータ滞留量が所定量以下になった場合に、前記ユーザ装置に対して前記バッファ状態報告トリガ指示を送信することを特徴とする請求項１に記載のバッファ状態報告の指示方法。
15. ユーザ装置に対してバッファ状態報告のトリガを指示する条件を設定し、前記条件が満たされる場合に、前記ユーザ装置に対するバッファ状態報告トリガ指示を生成するアップリンクバッファ管理部と、
    前記バッファ状態報告トリガ指示を前記ユーザ装置に送信する送信部と、
    前記バッファ状態報告トリガ指示に応答するバッファ状態報告を前記ユーザ装置から受信する受信部と、
    を有することを特徴とする無線基地局装置。
16. 前記ユーザ装置に対するアップリンクリソースを割り当てるスケジューラ、
    をさらに有し、
    前記アップリンクバッファ管理部は、前記送信部を介して、前記バッファ状態報告トリガ指示と同時に、前記バッファ状態報告のためのアップリンクリソースの割り当て通知を送信させることを特徴とする請求項１５に記載の無線基地局装置。
17. 前記ユーザ装置に対するアップリンクリソースを割り当てるスケジューラ、
    をさらに有し、
    前記アップリンクバッファ管理部は、前記送信部を介して、前記バッファ状態報告トリガ指示とは別個に、前記バッファ状態報告のためのアップリンクリソースの割り当て通知を送信させることを特徴とする請求項１５に記載の無線基地局装置。

Images