(57)【特許請求の範囲】
【請求項１】
ユーザ機器と基地局とを有する通信システムであって、
前記ユーザ機器は、
アップリンクデータをバッファリングするよう構成され、
前記バッファリングされたアップリンクデータの量を識別するバッファ状態報告を、アップリンクにおいて、送信するように構成され、
前記基地局は、
前記ユーザ機器に無線リソースを割当てるための許可情報を、ダウンリンクにおいて、送信するように構成され、
前記ユーザ機器は、
前記バッファリングされたアップリンクデータの量に基づき、前記基地局における前記許可情報の送信を停止させるための前記バッファ状態報告を送信し、
前記基地局は、
前記バッファ状態報告を受信し、
前記バッファ状態報告に基づき、前記許可情報の送信を停止し、
前記基地局は、
前記バッファ状態報告に基づき、前記ユーザ機器のバッファサイズを推定するように構成され、
前記推定した前記バッファサイズがゼロであり、かつ、前記推定の後に送信した前記許可情報が所定回数ユーザ機器にて受信できなかった場合、前記許可情報の送信を制限する
通信システム。
【請求項２】
ユーザ機器と通信するように構成された基地局であって、
前記ユーザ機器においてバッファリングされるアップリンクデータの量を識別するバッファ状態報告を、アップリンクにおいて、受信するように構成された受信機と、
前記アップリンクデータのための無線リソースを割当てるための許可情報を、ダウンリンクにおいて、送信するように構成された送信機と、
前記基地局における前記許可情報の送信を停止させることを、前記バッファ状態報告が示す場合において、
前記許可情報の送信を停止するよう前記送信機を制御するように構成されたプロセッサと、
を有し、
前記基地局は、
前記バッファ状態報告に基づき、前記ユーザ機器のバッファサイズを推定するように構成され、
前記推定した前記バッファサイズがゼロであり、かつ、前記推定の後に送信した前記許可情報が所定回数ユーザ機器にて受信できなかった場合、前記許可情報の送信を制限する
基地局。
【請求項３】
前記バッファ状態報告が、前記基地局における前記許可情報の送信を停止させることを示す場合、
前記基地局は、前記ユーザ機器にバッファリングされたアップリンクデータの量が実質的にゼロであると、判定する、
請求項２に記載の基地局。
【請求項４】
前記バッファ状態報告が、前記基地局における前記許可情報の送信を停止させることを示さない場合、
前記基地局は、前記許可情報の送信を停止しない、
請求項２または３に記載の基地局。
【請求項５】
前記推定された前記バッファサイズがゼロであり、かつ、
前記推定の後に受信する前記バッファ状態報告が、記基地局における前記許可情報の送信を停止させることを示さない場合、
前記許可情報の送信が継続される、
請求項２に記載の基地局。
【請求項６】
ユーザ機器であって、
アップリンクデータをバッファリングするように構成されたバッファと、
前記バッファにバッファリングされたアップリンクデータの量を識別するバッファ状態報告を、アップリンクにおいて、送信するように構成された送信機と、
前記ユーザ機器に無線リソースを割当てるための許可情報を、ダウンリンクにおいて、受信するように構成された受信機と、
前記バッファにバッファリングされているアップリンクデータの量に基づき、
前記バッファ状態報告が前記許可情報の送信を停止させることを示す情報を含むよう、前記送信機を制御するように構成されたプロセッサと、
を有し、
基地局によって前記バッファ状態報告に基づき推定されたバッファサイズがゼロであり、かつ、前記推定の後に送信された前記許可情報が所定回数前記受信機にて受信できなかった場合、前記許可情報の送信が制限される
ユーザ機器。
【請求項７】
基地局の通信方法であって、
ユーザ機器にバッファリングされるアップリンクデータの量を識別するバッファ状態報告を、アップリンクにおいて、受信し、
前記アップリンクデータのための無線リソースを割当てるための許可情報を、ダウンリンクにおいて、送信し、
前記バッファ状態報告が、前記基地局における前記許可情報の送信を停止させることを示す場合において、
前記許可情報の送信を停止し、
前記バッファ状態報告に基づき、前記ユーザ機器のバッファサイズを推定し、
前記推定した前記バッファサイズがゼロであり、かつ、前記推定の後に送信した前記許可情報が所定回数ユーザ機器にて受信できなかった場合、前記許可情報の送信を制限する
基地局の通信方法。
【請求項８】
基地局の通信方法をコンピュータに実行させるためのプログラムであって、
ユーザ機器にバッファリングされるアップリンクデータの量を識別するバッファ状態報告を、アップリンクにおいて、受信し、
前記アップリンクデータのための無線リソースを割当てるための許可情報を、ダウンリンクにおいて、送信し、
前記バッファ状態報告が、前記基地局における前記許可情報の送信を停止させることを示す場合において、
前記許可情報の送信を停止し、
前記バッファ状態報告に基づき、前記ユーザ機器のバッファサイズを推定し、
前記推定した前記バッファサイズがゼロであり、かつ、前記推定の後に送信した前記許可情報が所定回数ユーザ機器にて受信できなかった場合、前記許可情報の送信を制限する
プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、通信システム、基地局、ユーザ機器、通信方法、記憶媒体に関する。
【背景技術】
【０００２】
第３世代(３Ｇ)移動体通信システムの標準化プロジェクト（３ＧＰＰ：Third Generation Partnership Project）において、ロングタームエボリューション（LTE：Long Term Evolution)やLTE-Advancedの検討が行われている。【０００３】
特許文献１では、ＬＴＥにおいて、端末から基地局への無線リソース割当要求の送信周期を制御する方法が開示されている。端末は、基地局に対して無線リソースの割り当てを要求するために、無線リソース割当要求メッセージとして、スケジューリングリクエスト(SR: Scheduling Request)を発行する。特許文献１では、ＳＲを送信するための無線リソースの割り当てを抑えるために、端末が有する送信バッファの滞留量に応じてＳＲの送信周期を制御する。ＳＲは、端末が基地局（eNode B）へ送信すべき送信データを保持する場合に、基地局に対して上り無線リソースの割り当てを要求するために送信される。端末からＳＲを受信した場合において、基地局は、ＳＲ受信時点での上り無線リソースの空き状況に応じて、当該端末に割り当てる無線リソースを決定する。また基地局は、割り当てた無線リソースを通知するために端末に無線リソース割当通知メッセージ（SG：Scheduling Grant）を送信する。端末は基地局からＳＧを受信すると、ＳＧによって通知された無線リソースを使用して基地局にデータを送信する。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２０１０−１１４６８１号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、特許文献１には、基地局が端末から受信するバッファ滞留量から実際のバッファ滞留量を推定する具体的な方法が開示されていない。また、特許文献１には、推定されたバッファ滞留量と無線リソース割当通知メッセージ（ＳＧ）との関係性が開示されていない。【０００６】
対して、発明者は、端末の実際のバッファサイズと基地局が推定したバッファサイズとが異なる状況が生じる可能性（問題点）を見出した。【０００７】
さらに、発明者は、他の可能性（問題点）を見出した。ユーザ機器（端末）のバッファのバッファサイズについて、ユーザ機器と基地局との間で認識が一致しないために、ユーザ機器のアップリンクデータの送信が滞留し、適切な無線リソースのスケジューリングが行われない状況が生じる可能性（問題点）がある。【０００８】
そこで、例示的な実施形態の目的の１つは、ユーザ機器のバッファサイズに関するユーザ機器と基地局との間の認識の不一致を防止することが可能な通信システム、基地局、ユーザ機器、通信方法、記憶媒体を提供することである。なお、この目的は、本明細書に開示される実施形態が達成しようとする複数の目的の１つに過ぎないことに留意されるべきである。その他の目的又は課題と新規な特徴は、本明細書の記述又は添付図面から明らかにされる。
【課題を解決するための手段】
【０００９】
例示的な実施形態における通信システムは、ユーザ機器と基地局とを有する。該ユーザ機器は、アップリンクデータをバッファリングするよう構成され、前記バッファリングされたアップリンクデータの量を識別するバッファ状態報告を、アップリンクにおいて、送信するように構成され、前記基地局は、前記ユーザ機器に無線リソースを割当てるための許可情報を、ダウンリンクにおいて、送信するように構成され、前記ユーザ機器は、前記バッファリングされたアップリンクデータの量に基づき、前記基地局における前記許可情報の送信を停止させるための前記バッファ状態報告を送信する。前記基地局は、前記バッファ状態報告を受信し、前記バッファ状態報告に基づき、前記許可情報の送信を停止する。【００１０】
また、例示的な実施形態における基地局は、ユーザ機器と通信するように構成される。前記基地局は、前記ユーザ機器においてバッファリングされるアップリンクデータの量を識別するバッファ状態報告を、アップリンクにおいて、受信するように構成された受信機を有する。また、基地局は、前記アップリンクデータのための無線リソースを割当てるための許可情報を、ダウンリンクにおいて、送信するように構成された送信機を有する。また、基地局は、前記基地局における前記許可情報の送信を停止させることを、前記バッファ状態報告が示す場合において、前記許可情報の送信を停止するよう前記送信機を制御するように構成されたプロセッサと、を有する。【００１１】
また、例示的な実施形態におけるユーザ機器は、アップリンクデータをバッファリングするよう構成されたバッファを有する。またユーザ機器は、前記バッファにバッファリングされているアップリンクデータの量を識別するバッファ状態報告を、アップリンクにおいて、送信するように構成された送信機を有する。またユーザ機器は、前記ユーザ機器に無線リソースを割当てるための許可情報を、ダウンリンクにおいて、受信するように構成された受信機を有する。またユーザ機器は、前記バッファにバッファリングされているアップリンクデータの量に基づき、前記許可情報の送信を停止させることを示す情報を含むよう、前記送信機を制御するように構成されるプロセッサを有する。【００１２】
また、例示的な実施形態における基地局の通信方法では、ユーザ機器にバッファリングされるアップリンクデータの量を識別するバッファ状態報告を、アップリンクにおいて、受信し、前記アップリンクデータのための無線リソースを割当てるための許可情報を、ダウンリンクにおいて、送信し、前記バッファ状態報告が、前記基地局における前記許可情報の送信を停止させることを示す場合において、前記許可情報の送信を停止する。【００１３】
また、例示的な実施形態における記憶媒体は、基地局の通信方法をコンピュータに実行させるためのプログラムを記憶する。当該プログラムは、ユーザ機器にバッファリングされるアップリンクデータの量を識別するバッファ状態報告を、アップリンクにおいて、受信し、前記アップリンクデータのための無線リソースを割当てるための許可情報を、ダウンリンクにおいて、送信し、前記バッファ状態報告が、前記基地局における前記許可情報の送信を停止させることを示す場合において、前記許可情報の送信を停止すること、をコンピュータに実行させる。
【発明の効果】
【００１４】
本発明の例示的な実施形態によれば、ユーザ機器のバッファサイズに関するユーザ機器と基地局との間の認識の不一致を防止することができる。
【図面の簡単な説明】
【００１５】
【図１】第１の例示的な実施形態の通信システムを示す図である。
【図２】第１の例示的な実施形態のユーザ機器を示す図である。
【図３】第１の例示的な実施形態の基地局を示す図である。
【図４】第２の例示的な実施形態の通信システムを示す図である。
【図５】第２の例示的な実施形態の動作を示したシーケンスチャートである。
【図６】第２の例示的な実施形態の動作の一例を示す図である。
【図７】第２の例示的な実施形態の動作の他の例を示す図である。
【発明を実施するための形態】
【００１６】
以下では、具体的な実施形態の詳細が、図面を参照しながら示される。各図面において、同一又は対応する要素には同一の符号が付されており、説明の明確化のため、必要に応じて重複説明は省略される。
【００１７】
以下に説明される複数の実施形態は、独立に実施されることもできるし、適宜組み合わせて実施されることもできる。これら複数の実施形態は、互いに異なる新規な特徴を有している。したがって、これら複数の実施形態は、互いに異なる目的又は課題を解決することに寄与し、互いに異なる効果を奏することに寄与する。
【００１８】
＜第１の例示的な実施形態＞
図１は、第１の例示的な実施形態の通信システムを示す。
【００１９】
図１において、通信システム１は、ユーザ機器２と基地局３とを有する。
ユーザ機器２は、アップリンクデータをバッファリングするように構成される。また、ユーザ機器２は、バッファリングされるアップリンクデータの量を識別するバッファ状態報告を、アップリンクにおいて、送信するように構成される。
また、基地局３は、ユーザ機器２に無線リソースを割当てるための許可情報を、ダウンリンクにおいて、送信するように構成される。ここで、ユーザ機器２は、バッファリングされているアップリンクデータの量に基づき、基地局３における許可情報の送信を停止させることを示すバッファ状態報告を送信する。
なお、図面中の矢印の向きは、一例を示すものであり、ブロック間の信号の向きを限定するものではない。
【００２０】
図２は、第１の例示的な実施形態のユーザ機器を示す。
【００２１】
図２において、ユーザ機器２は、バッファ２１と送信機２２と受信機２３とプロセッサ２４とを有する。バッファ２１は、アップリンクデータをバッファリングするように構成される。送信機２２は、当該バッファにバッファリングされているアップリンクデータの量を識別するバッファ状態報告を、アップリンクにおいて、送信するように構成される。また、受信機２３は、ユーザ機器２に無線リソースを割当てるための許可情報を、ダウンリンクにおいて、受信するように構成される。プロセッサ２４は、バッファ２１にバッファリングされているアップリンクデータの量に基づき、バッファ状態報告が基地局における許可情報の送信を停止させることを示す情報を含むよう、送信機２２を制御するように構成される。なお、送信機２２及び受信機２３は一体となって、送受信機または送受信回路として動作してもよい。
なお、図面中の矢印の向きは、一例を示すものであり、ブロック間の信号の向きを限定するものではない。
【００２２】
図３は、第１の例示的な実施形態の基地局を示す。
【００２３】
図３において、基地局３は、受信機３１と送信機３２とプロセッサ３３とを有する。
【００２４】
受信機３１は、ユーザ機器２にバッファリングされるアップリンクデータの量を識別するバッファ状態報告を、アップリンクにおいて、受信するように構成される。送信機３２は、アップリンクデータのための無線リソースを割当てるための許可情報を、ダウンリンクにおいて、送信するように構成される。プロセッサ３３は、バッファ状態報告が、基地局３における許可情報の送信を停止させることを示す場合において、許可情報の送信を停止するよう送信機３２を制御するように構成される。なお、受信機３１及び送信機３２は一体となって、送受信機または送受信回路として動作してもよい。
本実施形態によれば、ユーザ機器２のアップリンクデータの量に関する、ユーザ機器２と基地局３との間の認識不一致の発生を防止することが可能である。このように、認識不一致の発生を防止することにより、ユーザ機器２のバッファにアップリンクデータが滞留することが抑制される。ユーザ機器２と基地局３との間の認識がより高い精度で一致する（最適化される）ことにより、基地局における許可情報による無線リソース割り当てが最適化される。
例えば、本実施形態によれば、プロセッサ３３が、バッファ状態報告が前記基地局における許可情報の送信を停止させることを示す場合において、許可情報の送信を停止するよう送信機３２を制御する。このため、ユーザ機器２のアップリンクデータの量に関するユーザ機器２と基地局３との間の認識不一致の発生を防止することが可能である。
なお、図面中の矢印の向きは、一例を示すものであり、ブロック間の信号の向きを限定するものではない。
＜第２の例示的な実施形態＞
図４は、第２の例示的な実施形態の通信システムを示す。
【００２５】
図４において、通信システムは、ユーザ機器４００と基地局５００とを有する。
ユーザ機器４００は、ＬＴＥに関するユーザ機器（UE：User Equipment）である。基地局５００は、ＬＴＥに関する基地局（eNBまたはeNodeB（evolved Node B））である。
なお、図面中の矢印の向きは、一例を示すものであり、ブロック間の信号の向きを限定するものではない。
【００２６】
ユーザ機器４００は、第１の物理層制御部４１０、ＭＡＣ(ミディアムアクセス制御またはMedium Access Controlという)レイヤ部４２０、バッファ４３０を有する。
【００２７】
バッファ４３０は、少なくとも一つのロジカルチャネル４３１を有する。バッファ４３０は、ロジカルチャネル４３１毎に、ＰＤＣＰ（Packet Data Convergence Protocolまたはパケットデータ収束プロトコルという）レイヤまたはＲＬＣ（無線リンク制御またはRadio Link Controlという）レイヤにおいて送信可能なデータをバッファ（記憶または保存ともいう）する。図４の例では、ロジカルチャネル４３１のゼロ番からＮ番まで其々において、送信可能なデータがバッファされている。
【００２８】
ＭＡＣレイヤ部４２０は、データ送信部４２１と第１のメモリ４２２とを有する。ＭＡＣレイヤ部４２０は、バッファ４３０にバッファされるデータのバッファサイズ（Buffer Size）を算出するように構成される。このバッファサイズは、ロジカルチャネル１つ毎に示されてもよい。またバッファサイズは、複数のロジカルチャネルのグループであるロジカルチャネルグループ（LCG：Logical Channel Group）単位で示されてもよい。LCGは、複数のロジカルチャネル（LCH：Logical Channel）がマッピングされたLCHのグループである。またLCGは、ＭＡＣレイヤ部４２０において、バッファ状態報告（BSR: Buffer Status Report）を生成する単位として用いられてもよい。
【００２９】
また、ＭＡＣレイヤ部４２０の第１のメモリ４２２は、算出したバッファサイズ（バッファ量ともいう）を記憶（保存）する。
【００３０】
また、ＭＡＣレイヤ部４２０は、第１のメモリ４２２に記憶されるバッファサイズに基づき、バッファ状態報告として、ＢＳＲ（Buffer Status Report）を生成する。例えば、ＢＳＲは、ロジカルチャネルグループを識別する識別子と、当該ロジカルチャネルグループにおいてバッファされるバッファサイズとを含んでもよい。バッファサイズは、実際のデータサイズ（またはバッファサイズ）を示すものでもよいし、第１のバッファサイズから第２のバッファサイズの間の所定の範囲に実際のデータサイズ（データサイズ）があることを示すインデックス値で示されてもよい。
【００３１】
また、ＭＡＣレイヤ部４２０のデータ送信部４２１は、生成したＢＳＲをアップリンクに送信する。また、データ送信部４２１は、基地局５００からの許可情報に基づき割り当てられるリソースを用いて、アップリンクデータを送信する。
【００３２】
ＭＡＣレイヤ部４２０は、ＭＡＣレイヤにおいて送信するためのアップリンクデータ（UL Data）を生成する。
【００３３】
ＭＡＣレイヤ部４２０は、第１の物理層制御部４１０との間で情報のやり取り（入出力または送受信ともいう）を行う。
【００３４】
第１の物理層制御部４１０は、基地局５００の第２の物理層制御部５１０との間で、情報の送受信を行う。また、第１の物理層制御部４１０は、ＭＡＣレイヤ部４２０との間で情報のやり取りを行う。
【００３５】
なお、ユーザ機器４００は、図４に示されるように、タイマー４４０を有してもよい。
【００３６】
基地局５００は、第２の物理層制御部５１０とＭＡＣレイヤ５２０とを有する。ＭＡＣレイヤ部５２０は、スケジューラ制御部５２１と、第２のメモリ５２２とを有する。
【００３７】
基地局５００は、ユーザ機器４００が送信したＢＳＲを受信する。
【００３８】
ＭＡＣレイヤ部５２０は、第２の物理層制御部５１０を介してＢＳＲを受信する。
【００３９】
スケジューラ制御部５２１は、受信したＢＳＲに基づき、ユーザ機器４００のバッファ４３０にバッファされたバッファサイズを推定する。
【００４０】
スケジューラ制御部５２１は、推定したバッファサイズに基づき、推定バッファサイズに対応する許可情報として、アップリンクグラント情報（UL-Grant: Uplink-Grant）をユーザ機器４００に送信する。このUL-Grantはリソース割り当て情報である。なお、スケジューラ制御部５２１は単にスケジューラと称することもできる。
【００４１】
第２のメモリ５２２には、ユーザ機器４００のバッファ４３０の推定バッファサイズが記憶（保存）される。
【００４２】
図５は、第２の例示的な実施形態の動作を示したシーケンスチャートである。
【００４３】
Ｓ１において、ユーザ機器４００は、PDCP又はRLCレイヤにおけるバッファ４３０のLCH（ロジカルチャネル）毎に滞留しているデータのBuffer量から、LCG(ロジカルチャネルグループ)毎の滞留Buffer量（バッファサイズ）を算出する。
【００４４】
Ｓ２において、ユーザ機器４００は、算出したBufferの量（算出バッファサイズ）を第１のメモリ４２２に保存する。
【００４５】
Ｓ３において、ユーザ機器４００は、第１のメモリ４２２に保存されるバッファサイズからＢＳＲを生成する。例えば、ユーザ機器４００は、保存されるバッファサイズから求められるＢＳＲのインデックス値を計算し、これをＢＳＲとして生成する。
【００４６】
Ｓ４において、ユーザ機器４００は、ＢＳＲを基地局５００に送信する。
【００４７】
Ｓ５において、基地局５００は、受信したＢＳＲに基づき、ユーザ機器４００のアップリンクバッファサイズ（UL Buffer Size）を推定する。
【００４８】
Ｓ６において、基地局５００は、推定したバッファサイズをLCG毎に第２のメモリ５２２に保存する。
【００４９】
Ｓ７において、基地局５００は、推定したバッファサイズに基づき、許可情報としてアップリンクグラント情報（UL-Grant）をユーザ機器４００に送信する。
【００５０】
Ｓ８において、基地局５００は、実際にUL-Grantで割り当てたサイズ等を、推定したバッファサイズから減算して、第２のメモリ５２２の推定バッファサイズを更新する。
【００５１】
Ｓ９において、ユーザ機器４００は、基地局５００から受信した許可情報（UL-Grant）にて示される（識別される）リソース割り当ての情報に基づき、アップリンクデータの送信を行う。なお、Ｓ７とＳ８のタイミングは、逆であってもよい。
【００５２】
＜ＢＳＲについて＞
ここで、バッファ状態報告の一例として示されたＢＳＲ（Buffer Status Report）の詳細が示される。
【００５３】
ＢＳＲは、例えば、周期的なＢＳＲ（Periodic BSR）、通常のレギュラーＢＳＲ（Regular BSR）、パディングＢＳＲ（Padding BSR）の何れであってもよい。
以下において、特にPeriodic BSRとRegular BSRに関する詳細が示される。
【００５４】
＜Periodic BSR＞
ユーザ機器４００は、周期的ＢＳＲタイマー（periodicBSR-Timer）を有する。Periodic BSRは、周期的ＢＳＲタイマーが満了した時に、送信すべきアップリンクデータがある場合に送信される。また、periodicBSR-Timerは、UL-Grantが割り当てられ、BSRが割り当てられるタイミングで、リスタートする。このため、UL-Grantが割り当てられ続ける限り、Periodic BSRがperiodicBSR-Timer長の周期で送信される。
＜Regular BSR＞
Regular BSRは、以下の（１）から（３）の処理の流れで、送信される。
（１）以下のＡ）かつＢ）かつＣ）の場合、ユーザ機器４００が基地局５００に対して、スケジューリングリクエスト（SR: Scheduling Request）を送信する。
Ａ）ユーザ機器４００のバッファ４３０に送信すべきデータが存在する。
Ｂ）retxBSR-Timerと呼ばれるTimerが満了した。
Ｃ）UL-Grantが割り当てられてない。
（２）基地局５００は、スケジューリングリクエストを受信すると、ユーザ機器４００へRegular BSR送信のための許可情報（UL-Grant）を送信する。
（３）上記（２）のUL-Grantに基づき、ユーザ機器４００は、Regular BSRを送信する。
retxBSR-Timerは、UL-Grantが割り当てられ、かつBSRが割り当てられるタイミングでリスタートする。このため、Regular BSR送信に必要なSRは、最短でretxBSR-Timer長の期間で送信される。また、retxBSR-Timerは、一定期間ＢＳＲが送信されていないことを検出するために使用される。
【００５５】
また、３ＧＰＰにおいて、periodicBSR-Timer長とretxBSR-Timer長が以下のように設定される。periodicBSR-Timer＜retxBSR-Timerと設定されるため、Periodic BSRの送信周期＜SRが送信可能な最短の期間となる。
・periodicBSR-Timerの範囲は、5[ms]から2560[ms]である。
・retxBSR-Timerの範囲は、320[ms]から10240[ms]である。
【００５６】
ここで、タイマー４４０は、periodicBSR-Timer及びretxBSR-Timerの少なくとも一方から構成することができる。
【００５７】
図６及び図７は、第２の例示的な実施形態の動作を示す。
【００５８】
図６及び図７において、基地局５００（eNB）での推定バッファサイズの推移と、基地局５００がUL-Grantを送信するタイミングとが、示される。
【００５９】
図６の例において、始点のタイミングにおいて、ユーザ機器４００（ＵＥ）のバッファ４３０は、データ量（バッファサイズ）として「ｘ１」のアップリンクデータをバッファしている。ここで例えば、バッファサイズが「ｘ１」である場合、「ｘ１」に対応するＢＳＲのインデックス値は「ａ」であると仮定する。
【００６０】
図６において、ユーザ機器４００がバッファサイズ「ゼロ」を通知するまで、基地局５００がUL-Grantを割り当て続ける（UL-Grantが送信され続ける）。ユーザ機器４００からバッファサイズ「ゼロ」が通知された場合に、基地局５００はUL-Grant割り当てを停止する。このように基地局５００とユーザ機器４００との間において、バッファ４３０のアップリンクのバッファサイズに関する認識が一致した時に、基地局５００がUL-Grantの割り当てを停止することにより、不要なUL-Grantが送信されることが防止される。
【００６１】
図７において、ユーザ機器４００がバッファサイズ「ゼロ」を通知するまで、基地局５００がUL-Grantを割り当て続ける。ユーザ機器４００からバッファサイズ「ゼロ」以外が通知された場合、基地局５００は、バッファサイズに応じたUL-Grant割り当てを行う。
【００６２】
＜図６及び図７に関する共通動作＞
（１）ユーザ機器４００は、バッファサイズ「ｘ１」に対応するＢＳＲのインデックス値として「ａ」を示すＢＳＲを基地局５００に送信する。
【００６３】
（２）基地局５００は、受信したBSRに基づき、ユーザ機器４００のバッファ４３０のバッファサイズが「ｘ２」であると推定する。
【００６４】
（３）基地局５００は、ユーザ機器４００に割り当て可能なリソースで、かつ、送信可能なデータサイズが「ｙ１」であるとする場合（ここで、「ｙ１」は「ｘ２」より小さい）、ユーザ機器４００へ割り当てるデータサイズが「ｙ１」であることを示す許可情報（UL-Grant）を送信する。また、基地局５００は、推定バッファサイズを「ｙ１」減算し、推定バッファサイズを「ｘ２−ｙ１」に更新する。
【００６５】
（４）ユーザ機器４００は、UL-Grantで示される情報に基づき、アップリンクデータを基地局５００に送信する。
【００６６】
（５）基地局５００での推定バッファサイズが「０」となるまで、上記（１）〜（４）の動作が繰り返される。ただし、上記（１）及び（２）は、ＢＳＲ（Periodic、Regular及びPadding BSR）の送受信タイミングにおいて実施される動作である。なお、図６において、基地局５００での推定バッファサイズが「ｙ２」で、割り当てるデータサイズが「ｙ２」となるようなUL-Grantを送信する場合において、推定バッファサイズは、「ゼロ」になるものとする。
【００６７】
（６）基地局５００での推定バッファサイズがゼロとなった場合、基地局５００はユーザ機器４００へ毎サブフレーム又は一定周期で連続して、ＢＳＲのためのUL-Grantを送信する。ここで、UL-Grantは、ＢＳＲが送信可能かつ、可能な限り少ない割り当てサイズを示すものとする。ユーザ機器４００は、上記UL-Grantで通知された情報に基づき、BSRを送信する。
【００６８】
＜図６の場合＞
（７−ａ）上記（６）の動作中に、ユーザ機器４００からＢＳＲでバッファサイズが「ゼロ」であることを通知された場合、基地局５００は、UL-Grantの割り当てを停止する。この場合、基地局５００は、ユーザ機器４００にバッファリングされたアップリンクデータの量が、ゼロまたは実質的にゼロであると判定してもよい。この判定に基づき、UL-Grantの割り当てが停止されてもよい。
【００６９】
＜図７の場合＞
（７−ｂ）上記（６）の動作中に、ユーザ機器４００からＢＳＲでバッファサイズが「ゼロより大きい」旨の通知がされた場合、基地局５００は、推定バッファサイズが通知された値（図７の場合は「ｚ２」の値）で更新した後、上記（１）〜（７）の動作を繰り返す。
【００７０】
上述のとおり、本実施形態によれば、基地局がユーザ機器のアップリンクバッファのサイズが「ゼロ」であると推定した後、ユーザ機器がバッファ状態報告（BSR）を基地局に送信する。このため、ユーザ機器のバッファサイズが基地局に通知されるまでの期間であっても、許可通知が送信され続ける。従って、基地局とユーザ機器との間において、ユーザ機器のアップリンクバッファのサイズの認識に仮に不一致が発生した場合であっても、UL-Grant割り当てまでの待ち時間が無くなる（または短くなる）ため、ユーザ機器のアップリンクデータの滞留が抑制され得る。
【００７１】
また、上述のとおり、ユーザ機器が、ユーザ機器のバッファサイズが「ゼロ」である旨を基地局に通知した場合には、この通知に基づき、基地局はUL-Grant割り当てを停止する。つまり、この通知に基づき、基地局はユーザ機器のアップリンクのバッファサイズを推定せずに、UL-Grantの割当を停止できる。この結果、基地局による不要なUL-Grant割り当てが防止される。
【００７２】
また、上述のとおり、ユーザ機器のバッファに送信すべきアップリンクデータが存在することを認識するまで待つケース（例えば、UL Data送信のためにretxBSR-Timerが満了するまで待つケース)の発生が防止できる。すなわち、基地局が、待ち時間無しで、ユーザ機器にリソース割り当てすることが可能となる。
【００７３】
＜第３の例示的な実施形態＞
第３の例示的な実施形態が以下にて示される。
【００７４】
本実施形態では、上記図６の動作説明における（６）において、基地局５００での推定バッファサイズが「ゼロ」となった後に、以下の条件を満たす場合、基地局５００はユーザ機器４００へBSRを送信するためのUL-Grantの送信を制約（制限）する。例えば、UL-Grantの送信が停止されてもよいし、UL-Grantの所定時間あたりの送信頻度が制限されてもよい。
【００７５】
上述の条件とは、BSRのためのUL-Grantが所定回数DTX（Discontinuous Transmission）判定となった場合である。つまり、ユーザ機器４００がUL-Grantを所定回数受信できない場合、またはUL-Grantを見落としている場合等である。
【００７６】
基地局５００が複数回数UL-Grant送信したにも関わらず、ユーザ機器４００でDTX判定となる原因の１つは、基地局５００での推定バッファサイズが「ゼロ」となった後に、ユーザ機器４００がセル端近傍に移動し、基地局５００から送信されるUL-Grantを認識するために必要な電力を確保できないことが考えられる。このような場合に、UL-Grantが継続して送信され続けても、正常処理できる可能性は低い。
【００７７】
上述のとおり、UL-Grantの送信が制約されることにより、不要なUL-Grantの発生が防止され得る。
【００７８】
＜他の実施形態＞
上述のとおり、ユーザ機器（ＵＥ）と基地局（eNB）との間のデータ通信のため、ユーザ機器は、アップリンクバッファにバッファリングされたアップリンクデータの量（UL Buffer量）をeNBへ報告(report)する。
【００７９】
例えば、UL Buffer量はインデックス値（Index値）で示される。このインデックス値を含むバッファ状態報告（BSR: Buffer Status Report)がユーザ機器からeNBに報告（report）される。また、eNBは、このBSRを受信する。BSRのインデックス値は、アップリンクデータの量が、ある値からある値の範囲にあることを示す。eNBは、このインデックス値から実際にUEのバッファにバッファリングされているバッファ量を推定する。eNBは、UL-Grantを用いてUEに無線リソースを割当てる。eNBは、この割り当てたサイズを、推定Buffer量から減算し、推定Buffer量の値を更新する。したがって、実際のUEが持つUL Buffer量と、eNBが推定したUL Buffer量とに関する認識に関し、eNBとUE間で一致しないケースが発生しうる。例えば、eNBが推定Buffer Sizeに対応するUL-Grantを送信した時点で、eNBはUL Bufferが無い（ゼロ）とみなしてしまう可能性がある。この場合、たとえ実際にUEのUL Bufferに送信されるべきアップリンクデータが存在していたとしても、eNB はUEに対して、UEが持つUL Buffer量を全て送信するために必要なUL-Grantを割り当てない可能性がある。なぜならば、eNBは、UL Bufferが無いとみなし、UL-Grant送信を停止するからである。すなわち、eNBがUEにUL Bufferが実際に存在すると認識するまで、UEのUL Bufferに送信すべきアップリンクデータが存在するにも関わらず、このアップリンクデータのための無線リソースが割り当てられない可能性がある。この可能性を発明者は発見した。
【００８０】
上述の実施形態は、例えば、次の状況において、有用である。
【００８１】
ユーザ機器のretxBSR-Timerが満了した後、Regular BSRが基地局へ送信される場合、基地局は、ＵＥのバッファに送信すべきアップリンクデータが存在することを認識する。しかし、retx BSR-Timerが満了する前の時間は、最後にUL-Grantが割り当てられた時間から一定時間経過した時間となるため、Regular BSRが送信されるまでに、待ち時間が発生しうる。この結果、UL-Grantによる割り当てが行われるまで遅延が発生する可能性がある。この遅延は、具体的には以下のケースにて起こりうる。
（１）新データのタイミングミス。
第１のケースは、ユーザ機器がBSRを送信した直後に、ユーザ機器のバッファに新たにUL Data が到着した場合である。
（２）誤認識。
第２のケースは、基地局が送信したUL-Grantをユーザ機器が受信できず、ユーザ機器は実際にUL Data を送信できなかったにも関わらず、基地局がユーザ機器からの送信があったと誤認識する場合である。
（３）ユーザ機器と基地局との算出方法による誤解。
基地局がUL Dataに含まれるPDCPレイヤ、RLCレイヤまたはMACレイヤにおけるデータのヘッダーやMAC Control Element 等を考慮したバッファサイズの推定を行っていなかった場合で、かつ、ユーザ機器のアップリンクのバッファサイズが、PDCPまたはRLCレイヤでのバッファサイズを基に算出されている場合である。
【００８２】
上述した実施形態の対象となる無線通信システムは、３ＧＰＰ  ＬＴＥ（Long Term Evolution）、３ＧＰＰ  Ｗ−ＣＤＭＡ（Wideband Code Division Multiple Access）、ＧＳＭ（登録商標）（Global System for Mobile communications）、ＷｉＭＡＸ（Worldwide interoperability for Microwave Access）等に適用可能であるが、これらに限定されない。
【００８３】
また、上記の無線通信システム及び無線通信端末は、ハードウェア、ソフトウェア又はこれらの組み合わせにより実現することができる。また、上記の通信システムの制御方法も、ハードウェア、ソフトウェア又はこれらの組み合わせにより実現することができる。ここで、ソフトウェアによって実現されるとは、コンピュータがプログラムを読み込んで実行することにより実現されることを意味する。
【００８４】
プログラムは、様々なタイプの非一時的なコンピュータ可読媒体（non-transitory computer readable medium）を用いて格納され、コンピュータに供給することができる。非一時的なコンピュータ可読媒体は、様々なタイプの実体のある記録媒体（tangible storage medium）を含む。非一時的なコンピュータ可読媒体の例は、磁気記録媒体（例えば、フレキシブルディスク、磁気テープ、ハードディスクドライブ）、光磁気記録媒体（例えば、光磁気ディスク）、ＣＤ−ＲＯＭ（Compact Disc-Read Only Memory）、ＣＤ−Ｒ（Compact Disc - Recordable）、ＣＤ−Ｒ／Ｗ（Compact Disc - Rewritable）、ＤＶＤ−ＲＯＭ（Digital Versatile Disc-ROM）、ＤＶＤ−Ｒ（Digital Versatile Disc - Recordable）、ＤＶＤ−Ｒ／Ｗ（Digital Versatile Disc-Rewritable）、半導体メモリ（例えば、マスクＲＯＭ、ＰＲＯＭ（Programmable ROM）、ＥＰＲＯＭ（Erasable PROM）、フラッシュＲＯＭ、ＲＡＭ（Random Access Memory）)を含む。
【００８５】
また、プログラムは、様々なタイプの一時的なコンピュータ可読媒体（transitory computer readable medium）によってコンピュータに供給されてもよい。一時的なコンピュータ可読媒体の例は、電気信号、光信号、及び電磁波を含む。一時的なコンピュータ可読媒体は、電線及び光ファイバ等の有線通信路、又は無線通信路を介して、プログラムをコンピュータに供給できる。
【００８６】
また、上述した各実施の形態は、適宜組み合わせて実施されることが可能である。また、本発明は、上述した各実施の形態に限定されず、様々な態様で実施されることが可能である。
【００８７】
（付記）
前述の実施形態の一部または全部は、以下の各付記のようにも記載することができる。しかしながら、以下の各付記は、あくまでも、本発明の単なる例示に過ぎず、本発明は、かかる場合のみに限るものではない。
（付記１）
ユーザ機器と基地局とを有する通信システムであって、
前記ユーザ機器は、
アップリンクデータをバッファリングするよう構成され、
前記バッファリングされるアップリンクデータの量を識別するバッファ状態報告を、アップリンクにおいて、送信するよう構成され、
前記基地局は、
前記ユーザ機器に無線リソースを割当てるための許可情報を、ダウンリンクにおいて、送信するよう構成され、
前記ユーザ機器は、
前記バッファリングされているアップリンクデータの量に基づき、前記許可情報の送信を停止するよう要求することを示す前記バッファ状態報告を送信する、
通信システム。
（付記２）
ユーザ機器と通信可能に構成される基地局であって、
前記ユーザ機器にバッファリングされるアップリンクデータの量を識別するバッファ状態報告を、アップリンクにおいて、受信するよう構成される受信機と、
前記アップリンクデータのための無線リソースを割当てるための許可情報を、ダウンリンクにおいて、送信するよう構成される送信機と、
前記バッファ状態報告が、前記許可情報の送信を停止する要求を示す場合において、
前記許可情報の送信を停止するよう前記送信機を制御するプロセッサと、
を有する基地局。
（付記３）
前記基地局は、
前記制御に基づき、前記許可情報の送信を停止する、
付記２記載の基地局。
（付記４）
前記基地局は、前記バッファ状態報告に基づき、前記ユーザ機器のバッファサイズを推定することが可能に構成される、
付記２または３記載の基地局。
（付記５）
前記推定された前記ユーザ機器のバッファサイズがゼロであり、かつ、前記推定後に送信される前記許可情報が所定回数ユーザ機器にて受信できない場合、
前記許可情報の送信が制限される、
付記４記載の基地局。
（付記６）
前記バッファ状態報告が前記許可情報の送信停止を要求することを示す場合、
前記基地局は、前記ユーザ機器にバッファリングされているアップリンクデータの量が実質的にゼロであると、判定する、
付記２乃至５の何れか１項に記載の基地局。
（付記７）
前記バッファ状態報告が、前記許可情報の送信停止を要求することを示さない場合、
前記基地局は、前記許可情報の送信を停止しない、
付記２乃至６の何れか１項に記載の基地局。
（付記８）
ユーザ機器であって、
アップリンクデータをバッファリングするよう構成されたバッファと、
前記バッファにバッファリングされているアップリンクデータの量を識別するバッファ状態報告を、アップリンクにおいて、送信するよう構成される送信機と、
前記ユーザ機器に無線リソースを割当てるための許可情報を、ダウンリンクにおいて、受信するよう構成される受信機と、
前記バッファにバッファリングされているアップリンクデータの量に基づき、
前記バッファ状態報告が前記許可情報の送信停止を要求することを示す情報を含むよう、前記送信機を制御可能に構成されるプロセッサと、
を有するユーザ機器。
（付記９）
ユーザ機器の通信方法であって、
アップリンクデータをバッファリングし、
前記バッファリングされているアップリンクデータの量を識別するバッファ状態報告を、アップリンクにおいて、送信し、
前記ユーザ機器に無線リソースを割当てるための許可情報を、ダウンリンクにおいて、受信し、
前記バッファリングされているアップリンクデータの量に基づき、
前記バッファ状態報告が前記許可情報の送信停止を要求することを示す情報を含むよう、前記送信機を制御する、
ユーザ機器の通信方法。
（付記１０）
ユーザ機器の通信方法をコンピュータに実行させるためのプログラムであって、
アップリンクデータをバッファリングするプロセスと、
前記バッファリングされているアップリンクデータの量を識別するバッファ状態報告を、アップリンクにおいて、送信するプロセスと、
前記ユーザ機器に無線リソースを割当てるための許可情報を、ダウンリンクにおいて、受信するプロセスと、
前記バッファリングされているアップリンクデータの量に基づき、
前記バッファ状態報告が前記許可情報の送信停止を要求することを示す情報を含むよう、前記送信機を制御するプロセスと、
をコンピュータに実行させるためのプログラム。
（付記１１）
ユーザ機器と基地局とを有する通信システムであって、
ユーザ機器は、
アップリンクデータをバッファリングするよう構成され、
前記バッファリングされるアップリンクデータの量を識別するバッファ状態報告を、アップリンクにおいて、送信するよう構成され、
前記基地局は、
前記ユーザ機器に無線リソースを割当てるための許可情報を、ダウンリンクにおいて、送信するよう構成され、
前記ユーザ機器は、
前記バッファリングされているアップリンクデータの量に基づき、前記基地局における前記許可情報の送信を停止させる前記バッファ状態報告を送信する、
前記基地局は、
前記バッファ状態報告を受信し、
受信したバッファ状態報告に基づき、前記許可情報の送信を停止する、
通信システム。
（付記１２）
前記基地局は、前記バッファ状態報告に基づき、前記ユーザ機器のバッファサイズを推定することが可能に構成される、
付記１１記載の通信システム。
（付記１３）
前記推定された前記ユーザ機器のバッファサイズがゼロであり、かつ、前記推定後に送信される前記許可情報が所定回数ユーザ機器にて受信できない場合、
前記許可情報の送信が制限される、
付記１２記載の通信システム。
（付記１４）
前記バッファ状態報告が、前記許可情報の送信停止を要求することを示さない場合、
前記基地局は、前記許可情報の送信を停止しない、
付記１１乃至１３の何れか１項に記載の通信システム。
（付記１５）
前記推定された前記バッファサイズがゼロであり、かつ、
前記推定の後に受信する前記バッファ状態報告が、記基地局における前記許可情報の送信を停止させることを示さない場合、
前記許可情報の送信が継続される、
付記１２記載の通信システム。
（付記１６）
ユーザ機器と通信可能に構成される基地局であって、
前記ユーザ機器にバッファリングされるアップリンクデータの量を識別するバッファ状態報告を、アップリンクにおいて、受信するよう構成される受信機と、
前記アップリンクデータのための無線リソースを割当てるための許可情報を、ダウンリンクにおいて、送信するよう構成される送信機と、
前記バッファ状態報告が、前記基地局における前記許可情報の送信を停止させることを示す場合において、
前記許可情報の送信を停止するよう前記送信機を制御するプロセッサと、
を有する基地局。
（付記１７）
ユーザ機器であって、
アップリンクデータをバッファリングするよう構成されたバッファと、
前記バッファにバッファリングされているアップリンクデータの量を識別するバッファ状態報告を、アップリンクにおいて、送信するよう構成される送信機と、
前記ユーザ機器に無線リソースを割当てるための許可情報を、ダウンリンクにおいて、受信するよう構成される受信機と、
前記バッファにバッファリングされているアップリンクデータの量に基づき、
前記バッファ状態報告が前記許可情報の送信停止させることを示す情報を含むよう、前記送信機を制御可能に構成されるプロセッサと、
を有するユーザ機器。
（付記１８）
基地局の通信方法であって、
ユーザ機器にバッファリングされるアップリンクデータの量を識別するバッファ状態報告を、アップリンクにおいて、受信し、
前記アップリンクデータのための無線リソースを割当てるための許可情報を、ダウンリンクにおいて、送信し、
前記バッファ状態報告が、前記基地局における前記許可情報の送信を停止させることを示す場合において、
前記許可情報の送信を停止する、
基地局の通信方法。
（付記１９）
基地局の通信方法をコンピュータに事項させるためのプログラムであって、
ユーザ機器にバッファリングされるアップリンクデータの量を識別するバッファ状態報告を、アップリンクにおいて、受信するプロセスと、
前記アップリンクデータのための無線リソースを割当てるための許可情報を、ダウンリンクにおいて、送信するプロセスと、
前記バッファ状態報告が、前記基地局における前記許可情報の送信を停止させることを示す場合において、
前記許可情報の送信を停止するプロセスと、
をコンピュータに実行させるためのプログラム。
（付記２０）
基地局の通信方法をコンピュータに実行させるためのプログラムを記憶する記憶媒体であって、
ユーザ機器にバッファリングされるアップリンクデータの量を識別するバッファ状態報告を、アップリンクにおいて、受信し、
前記アップリンクデータのための無線リソースを割当てるための許可情報を、ダウンリンクにおいて、送信し、
前記バッファ状態報告が、前記基地局における前記許可情報の送信を停止させることを示す場合において、
前記許可情報の送信を停止すること、
をコンピュータに実行させるためのプログラムを記憶する記憶媒体。
【００８８】
この出願は、２０１４年９月３日に出願された日本出願特願２０１４−１７９４５６を基礎とする優先権を主張し、その開示の全てをここに取り込む。
【符号の説明】
【００８９】
１  通信システム
２  ユーザ機器
３  基地局
２１  バッファ
２２  送信機
２３  受信機
２４  プロセッサ
３１  受信機
３２  送信機
３３  プロセッサ
４００  ユーザ機器
４１０  第１の物理層制御部
４２０  ＭＡＣレイヤ部
４２１  データ送信部
４２２  第１のメモリ
４３０  バッファ
４３１  ロジカルチャネル
４４０  タイマー
５００  基地局
５１０  第２の物理層制御部
５２０  ＭＡＣレイヤ部
５２１  スケジューラ制御部
５２２  第２のメモリ
【図１】
0006458805.tif 000002
【図２】
0006458805.tif 000003
【図３】
0006458805.tif 000004
【図４】
0006458805.tif 000005
【図５】
0006458805.tif 000006
【図６】
0006458805.tif 000007
【図７】
0006458805.tif 000008