JP2012110047A - バッファ状態報告 - Google Patents

Abstract

【課題】基地局がサービス品質認識アップリンク資源割当てを実行することができるようにする。
【解決手段】移動通信環境における、特に３ＧＰＰネットワークに適用することができるバッファ状態報告を提供するシステムが提案される。そのシステムは２つのタイプのバッファ状態報告、すなわち絶対バッファ状態報告及び相対バッファ状態報告を使用する。絶対バッファ状態報告は、アプリケーション開始時に、又はバッファレベルが設定されたしきい値よりも大きいか若しくは小さいときに送信される。そうでない場合には、相対バッファ状態報告が送信され、相対バッファ状態報告は、直前に送信された絶対バッファ状態報告からの差に関して、現在のバッファレベルを符号化する。
【選択図】図１

Description

本発明は、移動通信ネットワーク、限定はしないが、特に３ＧＰＰ標準規格、又はその等価物若しくは派生物に従って動作するネットワークにおけるバッファ状態の報告に関する。

移動通信ネットワークにおいて、データを送信したいユーザ装置（ＵＥ）は、基地局（ｅＮｏｄｅＢ）に、そのユーザ装置が送信のためにバッファリングしているデータの量を指示するバッファ状態報告を送信する。それに応答して、基地局は、ＵＥがそのデータを送信することができるように、そのＵＥに適切なシステム資源及び送信機会を割り当てる。３ＧＰＰでは、提案される高速アップリンクパケットアクセス（ＨＳＵＰＡ）と比べて、さらに良好なＱｏＳ認識スケジューリングに対応するために、さらに詳細なバッファ状態報告が行われるべきであることが最近になって理解されてきた。本発明者は、必要とされる制御シグナリングオーバーヘッドを最小限に抑えるために、バッファ状態が報告される方法を改善する必要があることを理解している。

当業者が効率よく理解することをできるようにするために、本発明を３Ｇシステムとの関連で詳細に説明するが、バッファ状態報告の原理は、他のシステム、たとえば、必要に応じてシステムの対応する構成要素を変更しながら、移動デバイス又はユーザ装置（ＵＥ）がいくつかの他のデバイス（ｅＮｏｄｅＢに対応する）のうちの１つと通信する他のＣＤＭＡ又は無線システムにも適用することができる。

第１の態様によれば、本発明は、移動通信デバイスから基地局にバッファ状態情報を通知する方法であって、移動通信デバイスのための現在のバッファ状態情報を求めること、現在のバッファ状態情報と１つ又は複数の所定の判定基準との間の関係を求めること、及び求められた関係に従って、現在のバッファ状態を指示する絶対バッファ状態報告、又は、先行するバッファ状態報告以後のバッファ状態の変化を指示する相対バッファ状態報告を基地局に送信することを含む、方法を提供する。

関係を求める際に用いられるバッファ状態情報は、たとえば、バッファに現在保持されているデータの量、又はデータがバッファに書き込まれている速度を含むことができる。送信される報告は、関係を求めるために用いられるデータと同じタイプのバッファ状態データ、又はそれとは異なるタイプのバッファ状態データを含むことができる。

求められる関係は、バッファ状態情報が或る特定の範囲内にあること、又はその情報が所定の値より大きいか若しくは小さいことを判定するものとすることができる。たとえば、現在のバッファ状態情報が、先行する測定以後の、データがバッファに書き込まれている速度の変化を含む場合には、求められる関係は、現在のバッファ状態情報が所定の速度の変化より高いか又は低いかということにすることができる。

相対バッファ状態報告は、先行するバッファ状態報告以後のバッファ内に保持されるデータの量の変化、又は、先行するバッファ状態報告以後の、データがバッファに書き込まれている速度の変化を指示することができる。好ましくは、相対バッファ状態報告は、直前に送信された絶対バッファ状態報告以後のバッファ状態の変化を指示する。これは、これによって、そうでない場合に生じ得る誤差の伝搬が回避されるためである。

該方法は、現在のバッファ状態情報と、直前の絶対バッファ状態報告に対応するバッファ状態情報との違いを求めるステップであって、直前に送信された絶対バッファ状態報告以後のバッファ状態の変化を求める、違いを求めるステップも含むことができる。

一実施の形態において、移動通信デバイスは、異なるタイプのデータを同時に送信することができ、バッファ状態報告は、データのタイプ毎のバッファ状態情報を含む。各タイプのデータは無線ベアラグループに関連付けられることが好ましく、バッファ状態報告は無線ベアラグループ毎のバッファ状態報告を含む。これにより、基地局が、バッファ内のデータの量に基づくだけでなく、異なるトラフィックタイプに関連付けられる相対的な優先度にも基づいて、アップリンク資源（移動通信デバイスから基地局にデータを通信するために用いられる）を割り当てることを可能にすることができる。

本発明はまた、移動通信デバイスに資源を割り当てる方法であって、移動通信デバイスから先行して受信された、先行する時点における移動通信デバイス内のバッファ状態を指示するバッファ状態情報を格納すること、移動通信デバイスから、先行するバッファ状態報告以後の移動通信デバイス内のバッファ状態の変化を指示する相対バッファ状態報告を受信すること、移動通信デバイス内の現在のバッファ状態を求めるため格納されたバッファ状態報告及び相対バッファ状態報告を用いること、及びに求められた現在のバッファ状態に従って、移動通信デバイスに資源を割り当てることを含む、方法を提供する。

格納されたバッファ状態情報は、先行する時点におけるバッファ状態を指示する絶対バッファ状態報告であることが好ましいか、又はそのような絶対状態報告から得られると共に１つ又は複数の後続の相対バッファ状態報告で更新されるバッファ状態情報とすることができる。該方法は、格納された絶対バッファ状態報告及び最後の相対バッファ状態報告だけを用いて、移動通信デバイス内の現在のバッファ状態を求めることが好ましい。

一実施の形態において、基地局が移動通信デバイスから新たな絶対バッファ状態報告を受信するとき、その基地局は、格納された絶対バッファ状態報告を新たな絶対バッファ状態報告で置き換える。

基地局は、好ましくは、多数の異なる移動デバイスからそのようなバッファ状態報告を受信し、それらの移動デバイスの送信要件に従って、利用可能な資源を割り当てるであろう。複数の移動デバイスが、異なる優先度を有する異なるタイプのデータを送信することができる場合、基地局は、１つの移動デバイスから受信されるバッファ状態報告に基づいて、且つ他のデバイスから送信されるデータ及びそのデータの優先度に従って、その移動デバイスに資源を割り当てることが好ましい。

本発明は、開示される全ての方法の場合に、対応する装置において実行するための対応するコンピュータプログラム又はコンピュータプログラム製品、装置自体（ユーザ装置、ノード又はその構成要素）、及び装置を更新する方法を提供する。

ここで、例として、添付の図面を参照しながら、本発明の実施形態を説明する。

実施形態を適用することができるタイプの移動通信システムを示す概略図である。 図１に示されるシステムの一部を形成する基地局を示す概略図である。 図１に示されるシステムの一部を形成する移動通信デバイスを示す概略図である。 図１に示される移動通信デバイス及び基地局において用いられるプロトコルスタックの３つの層を示す図である。 ＨＴＴＰトラフィックのためのデータ送信の典型的なモデルを示す図である。 ＦＴＰファイルダウンロードトラフィックのためのデータ送信の典型的なモデルを示す図である。 ＦＴＰファイルアップロードトラフィックのためのデータ送信の典型的なモデルを示す図である。 マルチメディアビデオ共有トラフィックのためのデータ送信の典型的なモデルを示す図である。 マルチメディアメッセージ伝送／マルチプレーヤゲーム／プッシュ・ツー・トークトラフィックのためのデータ送信の典型的なモデルを示す図である。 ＶｏＩＰトラフィックのためのデータ送信の典型的なモデルを示す図である。 単一のサービスを行なう場合の絶対バッファ状態報告及び相対バッファ状態報告の送信を示す図である。 多数のサービスを行なう場合の絶対バッファ状態報告及び相対バッファ状態報告の送信を示す図である。 ３ＧＰＰ ＬＴＥ標準規格におけるＴＣＰに基づくアプリケーションのためのトラフィックモデルを示す図である。 ３ＧＰＰ ＬＴＥ標準規格におけるＨＴＴＰウェブブラウジングトラフィックのための典型的なモデルを示す図である。 ＦＴＰトラフィックのための典型的なモデルを示す図である。 マルチメディアビデオ共有におけるアップリンクの一般的なパターンを示す図である。 マルチメディアメッセージ伝送／マルチプレーヤゲーム／プッシュ・ツー・トークにおける一般的なパターンを示す図である。 ＶｏＩＰトラフィックにおける一般的なパターンを示す図である。 単一のサービスを行なう場合の絶対バッファ状態報告及び相対バッファ状態報告の送信を示す図である。 多数のサービスを行なう場合の絶対バッファ状態報告及び相対バッファ状態報告の送信を示す図である。 絶対バッファ状態報告及び相対バッファ状態報告の両方を用いる誤り処理動作を示す図である。

概説
図１は、移動（セルラー）通信システム１を概略的に示している。該システムにおいて、移動電話（ＭＴ）３−０、３−１及び３−２のユーザが、基地局５−１又は５−２のうちの１つ及び電話網７を介して、他のユーザ（図示せず）と通信することができる。移動電話３と基地局５との間の無線リンクのために、多数のアップリンク及びダウンリンク通信資源（サブキャリア、タイムスロット等）を利用することができる。この実施形態において、移動電話３に送信されるデータの量に応じて、基地局５は、各移動電話３にダウンリンク資源を割り当てる。同様に、移動電話３が基地局５に送信しなければならないデータの量及びタイプに応じて、基地局５は、各移動電話３にアップリンク資源を割り当てる。これを行うことを可能にするために、各移動電話３は、その基地局５に定期的なバッファ状態報告を送信し、移動電話３が送信のためにそのバッファ内に有するデータの量及びタイプを基地局５に通知する。この実施形態において、移動電話３は、２つのタイプのバッファ状態報告を送信するように構成される。
１．移動電話のバッファ内のデータの量を指示する絶対バッファ状態報告。
２．直前の絶対バッファ状態報告以後の移動電話のバッファ内のデータの量の変化を指示する相対バッファ状態報告。

本発明者らは、この構成によって、ＱｏＳ認識スケジューリングのために必要とされるシグナリングオーバーヘッドを著しく低減することができることを発見した。

基地局
図２は、この実施形態において用いられる基地局５のそれぞれの主な構成要素を示すブロック図である。図に示されるように、各基地局５はトランシーバ回路２１を備えており、該トランシーバ回路は、１つ又は複数のアンテナ２３を介して移動電話３に対し信号を送受信するように動作することができ、且つネットワークインタフェース２５を介して電話網７に対し信号を送受信するように動作することができる。コントローラ２７が、メモリ２９に格納されるソフトウエアに従って、トランシーバ回路２１の動作を制御する。そのソフトウエアは、中でも、オペレーティングシステム３１、資源割当てモジュール３３及びダウンリンクスケジューラ３５を含む。資源割当てモジュール３３は、各移動電話３に、アップリンク及びダウンリンク通信のための上記の通信資源を割り当てるように動作することができ、ダウンリンクスケジューラは、割り当てられた資源に基づいて、各移動電話３へのダウンリンクデータの送信をスケジュールする。

移動電話
図３は、図１に示される移動電話３のそれぞれの主な構成要素を示すブロック図である。図に示されるように、移動電話３は、１つ又は複数のアンテナ７３を介して基地局５に対し信号を送受信するように動作することができるトランシーバ回路７１を備える。図に示されるように、移動電話３はコントローラ７５も備えており、該コントローラは、移動電話３の動作を制御し、且つトランシーバ回路７１に接続され、スピーカ７７、マイクロフォン７９、ディスプレイ８１及びキーパッド８３に接続される。コントローラ７５は、メモリ８５内に格納されるソフトウエア命令に従って動作する。図に示されるように、これらのソフトウエア命令は、中でも、オペレーティングシステム８７、アップリンクスケジューラ８９及びバッファ状態報告モジュール９０を含む。この実施形態では、メモリは、アップリンクデータバッファ９１も提供する。アップリンクスケジューラ８９は、そのアップリンク送信のために基地局５によって移動電話３に割り当てられる資源に従って、バッファ９１からのアップリンクデータの送信をスケジュールするための役割を担う。バッファ状態報告モジュール９０は、バッファ状態情報を求め、それを基地局に通知するための役割を担う。

理解するのを容易にするために、上記の説明では、基地局５及び移動電話３は、個別の資源割当てモジュール、スケジューリングモジュール及びバッファ状態報告モジュールを有するものとして説明される。特定のアプリケーションの場合、たとえば、既存のシステムが本発明を実施するように変更されている場合に、このようにこれらのモジュールが提供される場合があるが、他のアプリケーション、たとえば、最初から本発明の特徴を念頭において設計されたシステムでは、これらのモジュールは、オペレーティングシステム又はコード全体の中に構成することができるので、これらのモジュールは個別のエンティティとして区別することができない場合がある。

動作
図４は、移動電話３及び基地局５において用いられるプロトコルスタックの一部（下位の３つの層）を示す。最初の層は物理層（Ｌ１）であり、無線通信チャネルを介してデータを実際に送信するための役割を担う。その上には第２の層（Ｌ２）があり、Ｌ２は３つの副層、すなわち、無線インタフェースへのアクセスを制御するための役割を担う媒体アクセス制御層（Ｌ２／ＭＡＣ）と、必要に応じて、データパケットの連結及びセグメント化、パケットの肯定応答、並びにデータパケットの再送のための役割を担う外部ＡＲＱ層（Ｌ２／ＯＡＲＱ）と、ヘッダ圧縮及び暗号化のための役割を担うＰＤＣＰ層（Ｌ２／ＰＤＣＰ）とに分割される。第２の層上には、基地局５と移動電話３との間の無線インタフェースにおいて用いられる無線資源を制御するための役割を担う無線資源制御（ＲＲＣ）層（Ｌ３／ＲＲＣ）がある。図に示されるように、Ｌ２／外部ＡＲＱ層は、Ｃプレーンデータ及びＵプレーンデータの送信を管理するために用いられる多数の外部ＡＲＱエンティティ９５を含み、Ｌ２／ＰＤＣＰ層は、Ｃプレーン及びＵプレーンデータを処理するために用いられるＰＤＣＰエンティティ９７を含む。

図４は、送信されるデータの各データ源に割り当てられる無線ベアラ９８も示す。いくつかのソフトウエアアプリケーションが、同時に動作していることがあり、各アプリケーションがデータを送信及び／又は受信していることがある。無線ベアラも、そのデータタイプに応じて、複数のグループにグループ分けされる。たとえば、ユーザは、移動電話３上のソフトウエアを用いてインターネット上のウェブサイトに写真をアップロードしていることがあり、同時に、ネットワークサーバからファイルをダウンロードしていることがある。それぞれの無線ベアラは、各タスクに関連付けられることになり、この場合には、それらが両方ともＦＴＰ（ファイル転送プロトコル）に関連するので、その２つの無線ベアラは、同じ無線ベアラグループに属するであろう。その後、ユーザが音声通話を行なう場合には、別の無線ベアラ（別の無線ベアラグループに属する）を用いて、その音声通話のためのデータ送信及び受信が制御されるであろう。さらに、音声通話データは緊急性が高いので、そのデータはＦＴＰデータよりも高い優先度を割り当てられる。アップリンクのために基地局５によって割り当てられる通信資源は、その割り当てられる優先度及びデータ速度に応じて、無線ベアラ９８間で共有される。ＲＲＣ層９６は、無線ベアラ９８毎にデータ速度及び優先度を設定する。その後、アップリンクスケジューラ８９は、ＲＲＣ層９６によって無線ベアラに割り当てられたデータ速度及び優先度に基づいて、各無線ベアラ９８のデータパケットの送信のためのスケジューリングを制御する。

典型的には、移動電話３によって要求されるアップリンク資源は、その移動電話が送信しなければならないデータ速度が変化するのに応じて、時間と共に変化するであろう。これが、異なるタイプのデータに関して図５ａ〜図５ｆにおいて示されており、その図において、データの量はプロットの高さによって表される。詳細には、図５ａはＨＴＴＰトラフィックのためのデータ送信の典型的なモデルを示し、図５ｂはＦＴＰファイルダウンロードトラフィックのためのデータ送信の典型的なモデルを示し、図５ｃはＦＴＰファイルアップロードトラフィックのためのデータ送信の典型的なモデルを示し、図５ｄはマルチメディアビデオ共有トラフィックのためのデータ送信の典型的なモデルを示し、図５ｅはマルチメディアメッセージ伝送／マルチプレーヤゲーム／プッシュ・ツー・トークトラフィックのためのデータ送信の典型的なモデルを示し、図５ｆはＶｏＩＰトラフィックのためのデータ送信の典型的なモデルを示す。図に示されるように、マルチメディアメッセージ伝送のようないくつかのアプリケーションは、実際には予測不可能であるバーストトラフィックを生成するのに対して、ＶｏＩＰのような他のアプリケーションはより予測可能であり、持続的なスケジューリングを通じて、準静的な資源割当てを可能にする。しかしながら、ＴＣＰに基づくトラフィック又はマルチメディアビデオ共有トラフィックの場合、初期の開始段階後、ビット速度はより安定している。

この実施形態では、任意の時点におけるアップリンク資源の割当てを最適化しようと試みるために、基地局５（詳細には、資源割当てモジュール３３）は、その必要性に基づいて、各移動電話３に割り当てられる資源を動的に調整する。送信される前に、各無線ベアラ９８に関連付けられるアップリンクデータは、アップリンク送信バッファ９１にバッファリングされる。それゆえ、データ速度が変化すると、必要とされる資源と、現在割り当てられている資源との間の差に応じて、バッファ９１は一杯になるか、又は空になるであろう。したがって、バッファ９１内のデータの量を基地局５に通知することによって、基地局５は、各移動電話３に割り当てられる資源を動的に調整することができる。基地局５が、送信される異なるタイプのデータに要求されるサービス品質（ＱｏＳ）を考慮に入れて、アップリンク資源を割り当てることができるようにするために、移動電話３によって送信されるバッファ状態報告は、無線ベアラ９８の異なるグループ毎のバッファ状態を含む。このようにして、基地局５は、その基地局がサービスを提供している移動電話３毎に、移動電話３がどのくらいの量のＨＴＴＰウェブブラウジングトラフィックを送信しなければならないか、移動電話３がどのくらいの量のＦＴＰトラフィックを送信しなければならないか、移動電話３がどのくらいの量のマルチメディアビデオ共有トラフィックを送信しなければならないか、移動電話３がどのくらいの量のＶｏＩＰトラフィックを送信しなければならないか等を知るであろう。それゆえ、基地局５は、各移動電話３が送信しなければならないデータに関連付けられる優先度に基づいて、全ての移動電話３の間で、利用可能なアップリンク資源を割り当てることができる。

異なる無線ベアラグループのためのバッファ状態情報をそれぞれが含む、複数の定期的なバッファ状態報告を送信することは、著しいシグナリングオーバーヘッドを必要とし、ビット速度が概ね一定のままである持続的な期間が存在するため、大部分の時間においては不要であることを、本発明人は理解している。それゆえ、本発明者は、移動電話３が２つのタイプのバッファ状態報告、すなわち絶対バッファ状態報告及び相対バッファ状態報告を送信することを提案する。

絶対バッファ状態報告（ＡＢＳＲ）
これは、無線ベアラグループ毎のバッファ状態を含むことになり、アプリケーションが開始されたばかりであり且つビット速度が安定した値に達する前に時間的に変化しているセッション開始段階中に送信することができる。絶対バッファ状態報告は基本的に、移動電話のバッファ９１内（又は代わりに、トラフィックフロー内）のデータの量が、所定のしきい値より高く（又は低く）なるときに起動される事象であろう。

相対バッファ状態報告（ＲＢＳＲ）
これは、直前の絶対バッファ状態報告に対する差分バッファ状態（瞬間のビット速度の変化を指示する）のみを含むことになり、アプリケーションが相対的に安定したビット速度に達しているときに周期的に送信することができる。相対バッファ状態報告は、小さいサイズを有し、データＰＤＵ（プロトコルデータユニット）を使ってバッファ状態情報をピギーバックすることを可能にし、それによって、アップリンク資源を要求するために絶対バッファ状態報告を周期的に送信することから生じるアップリンクオーバーヘッドを大きく低減するであろう。相対バッファ状態報告は、無線ベアラグループ毎の差分バッファ状態情報を含み、それによって、基地局５が、該基地局がサービスを提供している移動電話３間のＱｏＳ認識アップリンク資源割当てを実行することができることを可能にするであろう。

図６ａ及び図６ｂはそれぞれ、単一のサービスを行なう場合（ファイルアップロード）及び多数のサービスを行なう場合（ファイルアップロード＋ウェブブラウジングトラフィックのためのＴＣＰ／ＲＬＣ肯定応答）の絶対バッファ状態報告及び相対バッファ状態報告の使用例を示す。図６ａに示されるように、最初に、アプリケーションが開始されたばかりであり且つビット速度が変化しているときに、絶対バッファ状態報告１１１が送信される。その後、データ速度が概ね一定のままであるときに、相対バッファ状態報告１１３が周期的に送信される。図６ｂに示されるように、２つのユーザデータ源（一方はファイルアップロード、他方は受信されたユーザデータパケットに対する肯定応答）が存在するので、示される期間にわたって、要求されるデータ速度はより変化し、それゆえ、より多くの絶対バッファ状態報告１１１が送信される。

この実施形態において、バッファ状態報告モジュール９０は、バッファ９１内のデータの量と、格納されている上側しきい値（Ｔ_Ｕ）及び格納されている下側しきい値（Ｔ_Ｌ）とを比較することによって、絶対バッファ状態報告を送信するか、相対バッファ状態報告を送信するかを判定する。バッファ内のデータの量が上側しきい値より大きいか、又は下側しきい値よりも小さい場合には、バッファ状態報告モジュール９０は絶対バッファ状態報告を送信し、そうでない場合には、相対バッファ状態報告を送信するであろう。当業者には理解されるように、測定されたバッファ状態情報から相対バッファ状態報告を計算することを可能にするために、バッファ状態報告モジュール９０は、送信された直前の絶対バッファ状態報告において送信されたバッファ状態情報を格納しなければならず、この情報はメモリ８５に格納される。

基地局５、詳細には資源割当てモジュール３３の動作に関して、そのモジュールは、その基地局がサービスを提供している種々の移動電話３から受信される絶対バッファ状態報告を把握し、受信した相対バッファ状態報告と共に、それらの絶対バッファ状態報告を用いて、各移動電話３内の現在のバッファ状態を求めなければならず、それによって、動的資源割当てを実行することができるようになる。

当業者には理解されるように、相対バッファ状態報告は、要求される情報を種々の方法において符号化することができる。たとえば、それらの方法は、直前に送信された絶対バッファ状態報告内のビットの数よりも多いか若しくは少ないビット数のカウント、又は直前の絶対バッファ状態報告以後のパーセンテージ変化（たとえば、２５％単位）を含むことができる。相対バッファ状態報告は、たとえば、以下のものを含むこともできる。
１．直前の絶対バッファ状態報告以後に、無線ベアラグループ毎に追加されるか若しくはバッファから除去されるバイト数（所定のしきい値内）、又は
２．直前のＡＢＳＲにおいて報告されたサイズのパーセンテージとしての現在のバッファサイズ、たとえば、２５％単位で０〜２００パーセント、又は
３．基地局５及び移動電話３は、さらに上位の層によって、基準バッファサイズに関して合意することができ、その後、相対バッファ状態報告は、この基準のパーセンテージとして現在のサイズを通知することができる。

又は、直前の相対バッファ状態報告に対するバッファ状態の変化を指示する相対バッファ状態報告を用いることも可能であろう。しかしながら、１つの相対バッファ状態報告が失われる（基地局５によって受信されない）場合には、次の絶対バッファ状態報告まで、後続の報告を通じて次々と誤りが伝わることになるので、これは好ましくない。直前の絶対バッファ状態報告に対して相対報告が行われるとき、次の相対バッファ状態報告は正確であるので、状態報告が失われても問題にはならない。

当業者には理解されるように、同様に、移動電話３は絶対バッファ状態報告を送信するか又は相対バッファ状態報告を送信するかを種々の方法において判断することができる。上記の例では、バッファ状態報告モジュール９０は、バッファ内のデータの量を、上側しきい値及び下側しきい値と比較した。代わりに、データがバッファ９１に書き込まれている速度を、上側しきい値及び下側しきい値と比較することもできる。さらに、代わりに、現時点と先行する時点との間のデータ速度の差、又はバッファに格納される実際のデータ量の差を所定の値を比較することもでき、その結果によって、絶対バッファ状態報告を送信するか又は相対バッファ状態報告を送信するかが規定される。

さらに、当業者には理解されるように、絶対バッファ状態報告を送信するか又は相対バッファ状態報告を送信するかを判定するために用いられるバッファ状態情報は、その報告に含まれるバッファ状態データと異なってもよい。たとえば、その判定は、データがバッファ９１に書き込まれている速度に基づいて行われる場合があるが、その一方で、その報告は、絶対バッファ状態報告であるか又は相対バッファ状態報告であるかに応じて、バッファ９１内に含まれる実際のデータ量に関連するカウント、又はバッファ９１内のデータ量の変化に関連するカウントを含むことができる。

当業者には理解されるように、基地局５及び移動電話３の動作は、専用のハードウエア回路によって制御することができるか、又はソフトウエアによって制御されるプログラム可能なコントローラによって制御することができる。そのソフトウエアは、製造時に提供される場合があるか、又は遠隔サイトからソフトウエアをダウンロードした後にインストールされる場合がある。

さらに、相対バッファ状態報告は、ＶｏＩＰサービスの場合に有音期間から無音期間に、又はその逆に切り替えるための基地局５への指示として利用することもできる。移動電話３からのこの指示に基づいて、基地局５は、有音期間から無音期間に切り替えるときに、持続的に割り当てられたアップリンク資源を解放することができるか、又は無音期間から有音期間に切り替えるときに、アップリンク資源を再び割り当てることができる。

種々の他の変更形態が当業者には明らかであると思われるため、ここでは、それらの変更形態をさらに詳細に説明しない。

以下において、現在提案されている３ＧＰＰ ＬＴＥ標準規格において本発明を実施することができる方法を詳細に説明する。種々の特徴が不可欠であるか又は必要であるように説明されるが、これは、たとえばその標準規格によって課せられる他の要件に起因して、提案されている３ＧＰＰ ＬＴＥ標準規格の場合にのみ当てはまり得る。それゆえ、これらの記載は、決して本発明を制限するものと解釈されるべきではない。

序論／背景
これまでのＲＡＮ２会合において、Ｅ−ＵＴＲＡＮのためのバッファ報告が、バッファ報告の内容及びグラニュラリティに関して積極的に議論されてきた。現在、ＲＡＮ２内では、全バッファ状態及び最も優先度の高い論理チャネルのバッファ状態だけがＮＢに報告されるＨＳＵＰＡに比べて、ＱｏＳ認識スケジューリングをさらに良好に支援するために、さらに詳細なバッファ状態情報がｅＮＢに報告されるべきであると一般的に理解されている。一般的に、ＱｏＳ認識スケジューリングを行なうために、そして同時に、無線ベアラ毎に報告することに比べて制御シグナリングオーバーヘッドを制限するために、ＬＴＥにおいて、無線ベアラグループに基づくバッファ状態報告が採用されることが好ましい。これに貢献するために、本発明者らは、種々のアプリケーションのためのアップリンクトラフィックモデルを研究し、制御シグナリングオーバーヘッドを最小限に抑える最適な報告を提案する。

アップリンクにおける主なアプリケーションのためのソーストラフィックモデル
ソーストラフィックモデルは基本的に、２つの部分：ユーザ活動のための到着過程及び活動段階を記述する過程から成る。到着過程は、ユーザが自分の活動を開始した瞬間を決定する。そのような瞬間は到着時刻として表される。ＷＷＷユーザについて考えると、ＨＴＴＰアプリケーションの場合に、ユーザが自分のウェブブラウジングセッションを開始する瞬間が到着時刻である。ここでは、簡単にするために、到着時刻のためのモデル化手法は考慮せず、種々のアプリケーションの場合に同じであると仮定する。

説明されるトラフィックモデルは、オン／オフモデルの一般的な形に基づいており、そのモデルでは、１つのセッションが一般的に、適当な分布によって記述されるオン／オフ期間の或る乱数から構成される。各オン期間は、パケット、パケット持続時間、パケットｉｔｅｒｔ（itert）到着時刻等の乱数に関して、さらに規定されることになる。

活動段階のためのモデルを、アップリンクトラフィックパターンに焦点を当てて、以下のセクションおいて異なるサービスに関して個別に説明する。さらに、ＴＣＰに基づくアプリケーションの場合、そのトラフィックモデルは、スロースタート後の活動段階中に安定した最大ビット速度を仮定する。図７において、遅延要素が示される。

ＨＴＴＰウェブブラウジングトラフィック
簡単な形のウェブブラウジングモデルは、オン／オフモデルであり、オン状態は、１つのウェブ要求を受け付けた後に、そのウェブ要求に属する全てのオブジェクトを取り出すための活動を表し、オフ状態は、１つのウェブ要求内の全てのオブジェクトが取り出された後の沈黙期間を表す。ウェブトラフィックは基本的には、図８に示されるように、オン期間中に、ダウンリンクにおいて大量のデータが送信され、そのストリームは安定しており、アップリンクではＴＣＰ／ＡＲＱ肯定応答が行なわれる。

ＦＴＰトラフィック
１つのみのウェブ要求を有し、活動段階が長時間に及ぶウェブセッションのようなＦＴＰファイル転送を説明することによって、ＦＴＰサービスを包括することができる。ＦＴＰファイル転送は、図９に示されるようにして実行される。

マルチメディアビデオ共有
リアルタイムビデオ共有のようなイメージングサービスは、電話接続の自分の側において起こっていることを他方の側に表示することである。現在のネットワークにおけるビデオストリーミングコーデックからの初期推定に基づくと、持続時間が数十秒から数分まで変化する場合に、ビット速度の下限は典型的には約４０ｋｂｐｓ〜６４ｋｂｐｓである。ストリーミングトラフィックの場合、その資源は、図１０に示されるように、持続的に割り当てることができるが、ストリーミングトラフィックは、ＭＢＲとＧＢＲとの間で絶えず変化し得るので、本発明者らは、資源を動的に割り当てる方が効率的な場合があると考える。

マルチメディアメッセージ伝送／マルチプレーヤゲーム／プッシュ・ツー・トーク
これらのアプリケーションは、ユーザ活動に応じて不規則な時間間隔で短いデータバーストが生じることによって特徴付けられる。一般的なパターンが図１１に示される。

ＶｏＩＰ
ＶｏＩＰアプリケーションは、図１２に示されるようにして、有音期間中に２０ｍｓ毎に一定サイズのパケットを生成するであろう。

マルチメディアメッセージ伝送／マルチプレーヤゲーム／プッシュ・ツー・トークアプリケーションは、実際には予測することができないトラフィックバーストを生成し、適切に資源を割り当てるために、アップリンクｅＮＢスケジューラによって厳密なバッファ状態が必要とされる。

ＶｏＩＰの場合、有音期間中に２０ｍｓ秒毎にパケットが生成され、それらの資源は、持続的なスケジューリングを通じて、準静的に割り当てられるので、ＶｏＩＰのための動的な資源割当ては、本明細書においてこれ以上検討しない。

ＴＣＰに基づくトラフィック又はマルチメディアビデオ共有の場合、それらのアプリケーションは、ステーティング後に安定したビット速度を達成することになり、ＵＥは、活動段階中にアップリンク資源を周期的に要求しなければならないであろう。本発明者らは、そのような場合にバッファ状態を報告するアップリンクシグナリングオーバーヘッドをかなり最適化することができるものと考える。

バッファ状態報告
無線の世界において用いられている最も一般的なアプリケーションの場合のトラフィックパターンに基づいて、本発明者らは、以下の２つの要件を満たすために、最適化されたバッファ状態報告機構のための仕組みを明示することができる。
１．ＱｏＳ認識スケジューリングを実行するのに十分であるバッファ状態報告のグラニュラリティ。
２．制御シグナリングオーバーヘッドを最小限に抑えること。

ＬＴＥシステムの場合、本発明者らは、同じ優先度を有する無線ベアラグループに基づくバッファ状態報告が、ＱｏＳ認識スケジューリングを実行するのに十分であると考える。この方式では、ＵＥは、あらゆる報告において、全ての無線ベアラグループ（ＲＢＧ）のバッファ状態を含むことになり、結果として、数多くのＲＢＧが存在する場合には特に、オーバーヘッドを被るであろう。

セクション２の種々のアプリケーションのトラフィックパターンに注目するとき、ＦＴＰ（ファイルアップロード）、ＳＭＴＰ（電子メール送信）及びＨＴＴＰ（ＴＣＰ／ＲＬＣ肯定応答）のようなＴＣＰに基づくアプリケーションの場合のビット速度が、ＴＣＰスロースタート段階後に概ね一定のままになる持続的な時間期間（オン期間）が存在することに、本発明者らは気が付いている。マルチメディアビデオ共有アプリケーションの場合、オン期間中に、同じく概ね一定のビット速度が保持されるであろう。

これを考慮すると、ビットが概ね一定である持続時間中に特に、ＵＥがあらゆる報告において全ての無線ベアラグループ（ＲＢＧ）のバッファ状態を報告し続ける場合には、オーバーヘッドが大きくなると思われる。アップリンクオーバーヘッドを低減するために、本発明人らは、２種類のバッファ報告を有することを提案する。
・絶対バッファ状態報告
・相対バッファ状態報告

絶対バッファ状態報告（ＡＢＳＲ）：これは、全ての無線ベアラグループのバッファ報告を含むことになり、アプリケーションが開始されたばかりであり且つビット速度が安定した値に達する前に時間的に変化しているセッション開始段階中に送信することができる。絶対バッファ状態報告は基本的に、ＵＥバッファ内（又は代わりに、トラフィックフロー内）のデータの量が、所定のしきい値より高く（又は低く）なるときに起動される事象であろう。

相対バッファ状態報告（ＲＢＳＲ）：これは、直前に送信された絶対バッファ状態報告に対する差分バッファ状態（瞬間のビット速度の変化を指示する）のみを含むことになり、アプリケーションが相対的に安定したビット速度に達しているときに周期的に送信することができる。相対バッファ状態報告は、小さいサイズを有し、データＰＤＵ（プロトコルデータユニット）においてバッファ情報をピギーバックすることを可能にし、それによって、アップリンク資源を要求するために絶対バッファ状態報告を周期的に送信することから生じるアップリンクオーバーヘッドを大きく低減するであろう。相対バッファ状態報告は、以下のものを含むことができる。
１．直前の絶対バッファ状態報告以後に、所定のしきい値内で、追加されるか若しくはバッファから除去されるバイト数、又は
２．直前のＡＢＳＲにおいて報告されたサイズのパーセンテージとしての現在のバッファサイズ、たとえば、２５％単位で０〜２００パーセント、又は
３．ｅＮＢ及びＵＥは、さらに上位の層によって、基準バッファサイズに関して合意することができ、その後、相対バッファ状態報告は、この基準のパーセンテージとして現在のサイズを通知することができる。
４．ＲＢＳＲは、ＶｏＩＰサービスの場合に有音期間から無音期間に、又はその逆に切り替えるためのｅＮＢへの指示として利用することもできる。ＵＥからのこの指示に基づいて、ｅＮＢは、有音期間から無音期間に切り替えるときに、持続的に割り当てられた資源を解放することができるか、又は無音期間から有音期間に切り替えるときに、資源を再び割り当てることができる。

単一のサービスを行なう場合、及び多数のサービスを行なう場合に絶対バッファ状態報告及び相対バッファ状態報告を組み合わせて使用することを示す例が、図１３及び図１４に示される。

結論
本発明者らは、絶対バッファ状態報告に加えて相対バッファ状態報告を有し、ＬＴＥにおけるバッファ状態報告のためのシグナリングオーバーヘッドを低減することを提案する。アプリケーションが安定したビット速度を達成した後に、ＵＥは、絶対バッファ状態報告から相対バッファ状態報告に素早く切り替えることができる。シグナリングオーバーヘッドの減少を実証するために、単一のサービスを行なう場合及び多数のサービスを行なう場合の絶対バッファ状態報告及び相対バッファ状態報告の使用が示される。そのような方式によれば、アップリンクｅＮＢスケジューラに与えられる情報のグラニュラリティを失うことなく、シグナリングオーバーヘッドを許容限度に抑えて、ＱｏＳ認識スケジューリングを実行することができる。

参考文献
［１］Ｒ２−０６０８２９「Buffer Reporting for E-UTRAN」（Nokia）
［２］Ｒ２−０６１９１５「Comparison of UL buffer reporting/scheduling schemes in LTE」（Motorola）

付録：誤り処理
本発明人らは、絶対バッファ状態報告及び相対バッファ状態報告の組み合わせによって、アップリンクｅＮＢスケジューラがＱｏＳ認識スケジューリングを実行するためのロバストな仕組みが提供されるものと考える。

相対バッファ状態報告（ＲＢＳＲ）は直前に送信されたＡＢＳＲに対する差分バッファ状態である（瞬間のビット速度の変化を指示する）ので、ＲＢＳＲのうちの１つが失われる場合であっても、次にスケジュールされた時間間隔においてＵＥは、直前のＡＢＳＲに対する差を再び報告するか、又はバッファが所定のしきい値を増大する場合には、ＡＢＳＲを送信するであろう。図１５に示されるように、ネットワークは、失われたＲＢＳＲ後に、後続のＲＢＳＲ又はＡＢＳＲを受信すると、適当に資源を割り当てることが可能であろう。

最後に、本発明の例を以下に列挙する。

例１は、移動通信デバイスから基地局にバッファ状態情報を通知する方法であって、
移動通信デバイスのための現在のバッファ状態情報を求めること、
現在のバッファ状態情報と１つ又は複数の所定の判定基準との間の関係を求めること、及び
求められた関係に従って、現在のバッファ状態を指示する絶対バッファ状態報告、又は、先行するバッファ状態報告以後のバッファ状態の変化を指示する相対バッファ状態報告を基地局に送信することを含む、方法を示す。

例２は、上記バッファ状態情報がバッファ内に現在保持されているデータの量を含む方法を示す。

例３は、上記バッファ状態情報がデータがバッファに書き込まれている速度を含む方法を示す。

例４は、上記バッファ状態報告がバッファ内に現在保持されているデータの総量を指示する方法を示す。

例５は、上記絶対バッファ状態報告がデータがバッファに書き込まれている速度を指示する方法を示す。

例６は、上記相対バッファ状態報告が、上記先行するバッファ状態報告以後のバッファ内に保持されるデータの量の変化を指示する方法を示す。

例７は、上記相対バッファ状態報告が、直前の絶対バッファ状態報告以後に所定のしきい値内で追加されるか又はバッファから除去されるバイト数を指示する方法を示す。

例８は、上記相対バッファ状態報告が、直前の絶対バッファ状態報告において報告されるバッファサイズのパーセンテージとして現在のバッファサイズを指示する方法を示す。

例９は、上記相対バッファ状態報告が、所定の基準バッファサイズのパーセンテージとして現在のバッファサイズを指示する方法を示す。

例１０は、上記相対バッファ状態報告が、上記先行するバッファ状態報告以後の、データがバッファに書き込まれている速度の変化を指示する方法を示す。

例１１は、上記相対バッファ状態報告が、直前に送信された絶対バッファ状態報告以後のバッファ状態の変化を指示する方法を示す。

例１２は、直前に送信された絶対バッファ状態報告以後のバッファ状態の変化を求めるため、現在のバッファ状態情報と、直前の絶対バッファ状態報告に対応するバッファ状態情報との違いを求めるステップを含む方法を示す。

例１３は、上記１つ又は複数の判定基準が上限及び下限を含み、上記求められた関係が、現在のバッファ状態情報が上記上限及び上記下限内に入るか否かを判定する方法を示す。

例１４は、現在のバッファ状態情報が上記上限及び上記下限から外れる場合には、絶対バッファ状態報告を送信すること、並びに、現在のバッファ状態情報が上記上限及び上記下限内に入る場合には、相対バッファ状態報告を送信することを含む方法を示す。

例１５は、上記１つ又は複数の判定基準が、データがバッファに書き込まれている速度の所定の変化を含み、上記現在のバッファ状態情報が、先行する測定以後の、データがバッファに書き込まれている速度の変化を含み、関係が、現在のバッファ状態情報が速度の所定の変化より大きいか又は小さいかである方法を示す。

例１６は、移動通信デバイスが異なるタイプのデータを送信することができ、バッファ状態報告がデータのタイプ毎のバッファ状態情報を含む方法を示す。

例１７は、データのタイプのそれぞれが１つの無線ベアラグループに関連付けられ、バッファ状態報告が無線ベアラグループ毎のバッファ状態情報を含む方法を示す。

例１８は、各無線ベアラグループ内の多数のデータ源からデータを送信することを含む方法を示す。

例１９は、相対バッファ状態報告において、ＶｏＩＰサービスの場合に基地局が有音期間と無音期間とを切り替えるべきであることを指示することを含む方法を示す。

例２０は、移動通信デバイスに資源を割り当てる方法であって、
移動通信デバイスから先行して受信された移動通信デバイス内の先行するバッファ状態を指示するバッファ状態情報を格納すること、
移動通信デバイスから、先行するバッファ状態報告以後の移動通信デバイス内のバッファ状態の変化を指示する相対バッファ状態報告を受信すること、
移動通信デバイス内の現在のバッファ状態を求めるため、格納されたバッファ状態情報及び相対バッファ状態報告を用いること、及び
移動通信デバイス内の求められた現在のバッファ状態に従って、移動通信デバイスに資源を割り当てることを含む、方法を示す。

例２１は、上記用いるステップが、格納された絶対バッファ状態報告及び相対バッファ状態報告のみを用いて、移動通信デバイス内の現在のバッファ状態を求める方法を示す。

例２２は、上記用いるステップが、格納された絶対バッファ状態報告、受信された相対バッファ状態報告及び先行して受信された１つ又は複数の相対バッファ状態報告を用いて、移動通信デバイス内の現在のバッファ状態を求める方法を示す。

例２３は、移動通信デバイスから新たな絶対バッファ状態報告を受信すること、及び、該新たな絶対バッファ状態報告で格納されたバッファ状態情報を更新することを含む方法を示す。

例２４は、複数の移動通信デバイスからバッファ状態報告を受信することを含む方法であって、上記割り当てるステップが、少なくとも１つの他の移動通信デバイスから受信されるバッファ状態報告にも従って、移動通信デバイスに資源を割り当てる、方法を示す。

例２５は、バッファ状態報告が、移動通信デバイスから送信される異なるデータタイプ毎のバッファ状態情報を含み、該データタイプが異なる優先度を有し、上記割り当てるステップが、異なるデータタイプ毎に受信されるバッファ状態情報に従って、移動通信デバイスに資源を割り当てる方法を示す。

例２６は、相対バッファ状態報告が、有音期間と無音期間とを切り替えるための指示を含み、該切り替えるための指示を受信するのに応答して、方法が、持続的に割り当てられたアップリンク資源を解放するか又は移動通信デバイスに再び割り当てるステップを含む方法を示す。

例２７は、移動通信デバイスであって、
該移動通信デバイスのための現在のバッファ状態情報を求める手段と、
現在のバッファ状態情報と１つ又は複数の所定の判定基準との間の関係を求める手段と、
求められた関係に従って、現在のバッファ状態を指示する絶対バッファ状態報告、又は、先行するバッファ状態報告以後のバッファ状態の変化を指示する相対バッファ状態報告を基地局に送信する手段とを備える、移動通信デバイスを示す。

例２８は、移動通信デバイスであって、
コントローラを備え、該コントローラはプログラムの制御下で、
移動通信デバイスのための現在のバッファ状態情報を求め、
現在のバッファ状態情報と１つ又は複数の所定の判定基準との間の関係を求め、
求められた関係に従って、現在のバッファ状態を指示する絶対バッファ状態報告、又は先行するバッファ状態報告以後のバッファ状態の変化を指示する相対バッファ状態報告を基地局に送信するように動作することができる、移動通信デバイスを示す。

例２９は、例２〜１９のいずれか１つに記載の方法を実行するように動作することができる移動通信デバイスを示す。

例３０は、基地局であって、
移動通信デバイスから先行して受信された、該移動通信デバイス内の先行するバッファ状態を指示するバッファ状態情報を格納する手段と、
移動通信デバイスから、先行するバッファ状態報告以後の移動通信デバイス内のバッファ状態の変化を指示する相対バッファ状態報告を受信する手段と、
移動通信デバイス内の現在のバッファ状態を求めるため、格納されたバッファ状態情報及び相対バッファ状態報告を用いる手段と、
移動通信デバイス内の求められた現在のバッファ状態に従って、移動通信デバイスに資源を割り当てる手段とを備える、基地局を示す。

例３１は、基地局であって、
コントローラを備え、該コントローラはプログラムの制御下で、
移動通信デバイス内の先行するバッファ状態に関連するバッファ状態情報を格納し、
移動通信デバイスから、先行するバッファ状態報告以後の移動通信デバイス内のバッファ状態の変化を指示する相対バッファ状態報告を受信し、
格納されたバッファ状態情報及び相対バッファ状態報告を用いて、移動通信デバイス内の現在のバッファ状態を求め、
移動通信デバイス内の求められた現在のバッファ状態に従って、移動通信デバイスに資源を割り当てるように動作することができる、基地局を示す。

例３２は、例２１〜２６のいずれか１つに記載の方法を実行するように動作することができる基地局を示す。

例３３は、コンピュータデバイスが例１〜２６のいずれか１つに記載の方法を実行するためのコンピュータ実施可能命令を含む、コンピュータ実施可能命令製品を示す。

例３４は、移動通信デバイスから基地局にバッファ状態情報を通知する方法であって、
移動通信デバイスのための現在のバッファ状態情報を求めること、
現在のバッファ状態情報と１つ又は複数の所定の判定基準との間の関係を求めること、
求められた関係に従って、現在のバッファ状態を指示するバッファ状態報告を基地局に送信すること、及び
ＶｏＩＰサービスの場合に、バッファ状態報告において基地局が有音期間と無音期間とを切り替えるべきであることを指示することを含む、方法を示す。

例３５は、移動通信デバイスから基地局にバッファ状態情報を通知する方法であって、
移動通信デバイスから基地局に異なるタイプのデータで、データのタイプのそれぞれはそれぞれの無線ベアラグループに関連付けられるデータを送信すること、
送信されるデータを送信バッファにバッファリングすること、
無線ベアラグループ毎に、送信バッファ内にバッファリングされたデータのためのバッファ状態情報を求めること、
求められたバッファ状態情報に従って、無線ベアラグループ毎の現在のバッファ状態を指示するバッファ状態報告を基地局に送信すること、及び
ＶｏＩＰサービスの場合に、バッファ状態報告において基地局が有音期間と無音期間とを切り替えるべきであることの指示を含むことを含む、方法を示す。

例３６は、移動通信デバイスに資源を割り当てる方法であって、
移動通信デバイスからデータを受信すること、
ＶｏＩＰサービスの場合に、移動通信デバイスから、基地局が有音期間と無音期間とを切り替えるべきであることを指示するバッファ状態報告を受信すること、及び
受信された指示に従って、持続的に割り当てられたアップリンク資源を解放するか又は移動通信デバイスに再び割り当てることを含む、方法を示す。

例３７は、移動通信デバイスに資源を割り当てる方法であって、
移動通信デバイスから異なるタイプのデータを受信すること、
データのタイプ毎のバッファ状態情報と、ＶｏＩＰサービスの場合に、基地局が有音期間と無音期間とを切り替えるべきであることの指示とを有するバッファ状態報告を移動通信デバイスから受信すること、及び
受信された指示に従って、持続的に割り当てられたアップリンク資源を解放するか又は移動通信デバイスに再び割り当てることを含む、方法を示す。

本出願は、２００７年６月１９日に出願の英国特許出願第０７１１８８４．７号に基づいており、その特許出願からの優先権の利益を主張し、その特許出願の開示は参照によりその全体が本明細書に援用される。

Claims (21)

1. 移動通信デバイスから基地局にバッファ状態情報を通知する方法であって、
   前記移動通信デバイスのための現在のバッファ状態情報を求めること、
   前記現在のバッファ状態情報と１つ又は複数の所定の判定基準との間の関係を求めること、及び
   前記求められた関係に従って、前記現在のバッファ状態を指示する絶対バッファ状態報告、又は、先行するバッファ状態報告以後の前記バッファ状態の変化を指示する相対バッファ状態報告を前記基地局に送信することを含み、
   前記１つ又は複数の判定基準は上限及び下限を含み、前記求められた関係は、前記現在のバッファ状態情報が前記上限及び前記下限内に入るか否かを判定することを特徴とする、方法。
2. 前記バッファ状態情報は、前記バッファ内に現在保持されているデータの量を含む、請求項１に記載の方法。
3. 前記バッファ状態情報は、データが前記バッファに書き込まれている速度を含む、請求項１に記載の方法。
4. 前記絶対バッファ状態報告は、前記バッファ内に現在保持されているデータの総量を指示する、請求項１〜３のいずれか一項に記載の方法。
5. 前記絶対バッファ状態報告は、データが前記バッファに書き込まれている速度を指示する、請求項１〜３のいずれか一項に記載の方法。
6. 前記相対バッファ状態報告は、前記先行するバッファ状態報告以後の前記バッファ内に保持されるデータの量の変化を指示する、請求項１〜５のいずれか一項に記載の方法。
7. 前記相対バッファ状態報告は、直前の絶対バッファ状態報告以後に所定のしきい値内で追加されるか又は前記バッファから除去されるバイト数を指示する、請求項１〜５のいずれか一項に記載の方法。
8. 前記相対バッファ状態報告は、直前の絶対バッファ状態報告において報告されるバッファサイズのパーセンテージとして前記現在のバッファサイズを指示する、請求項１〜５のいずれか一項に記載の方法。
9. 前記相対バッファ状態報告は、所定の基準バッファサイズのパーセンテージとして前記現在のバッファサイズを指示する、請求項１〜５のいずれか一項に記載の方法。
10. 前記相対バッファ状態報告は、前記先行するバッファ状態報告以後の、データが前記バッファに書き込まれている速度の変化を指示する、請求項１〜５のいずれか一項に記載の方法。
11. 前記相対バッファ状態報告は、直前に送信された絶対バッファ状態報告以後の前記バッファ状態の変化を指示する、請求項１〜１０のいずれか一項に記載の方法。
12. 前記直前に送信された絶対バッファ状態報告以後の前記バッファ状態の変化を求めるため、前記現在のバッファ状態情報と、前記直前の絶対バッファ状態報告に対応する前記バッファ状態情報との違いを求めるステップを含む、請求項１１に記載の方法。
13. 前記現在のバッファ状態情報が前記上限及び前記下限から外れる場合には、前記絶対バッファ状態報告を送信すること、並びに、前記現在のバッファ状態情報が前記上限及び前記下限内に入る場合には、前記相対バッファ状態報告を送信することを含む、請求項１に記載の方法。
14. 前記１つ又は複数の判定基準は、データが前記バッファに書き込まれている速度の所定の変化を含み、前記現在のバッファ状態情報は、先行する測定以後の、データが前記バッファに書き込まれている速度の変化を含み、前記関係は、前記現在のバッファ状態情報が前記速度の所定の変化より大きいか又は小さいかである、請求項１〜１３のいずれか一項に記載の方法。
15. 前記移動通信デバイスは異なるタイプのデータを送信することができ、前記バッファ状態報告はデータのタイプ毎のバッファ状態情報を含む、請求項１〜１４のいずれか一項に記載の方法。
16. 前記データのタイプのそれぞれは１つの無線ベアラグループに関連付けられ、前記バッファ状態報告は該無線ベアラグループ毎のバッファ状態情報を含む、請求項１５に記載の方法。
17. 各前記無線ベアラグループ内の多数のデータ源からデータを送信することを含む、請求項１６に記載の方法。
18. 前記相対バッファ状態報告において、ＶｏＩＰサービスの場合に前記基地局が有音期間と無音期間とを切り替えるべきであることを指示することを含む、請求項１〜１７のいずれか一項に記載の方法。
19. 移動通信デバイスであって、
    該移動通信デバイスのための現在のバッファ状態情報を求める手段と、
    前記現在のバッファ状態情報と１つ又は複数の所定の判定基準との間の関係を求める手段と、
    前記求められた関係に従って、前記現在のバッファ状態を指示する絶対バッファ状態報告、又は、先行するバッファ状態報告以後の前記バッファ状態の変化を指示する相対バッファ状態報告を前記基地局に送信する手段とを含み、
    前記１つ又は複数の判定基準は上限及び下限を含み、前記求められた関係は、前記現在のバッファ状態情報が前記上限及び前記下限内に入るか否かを判定することを特徴とする、移動通信デバイス。
20. 請求項２〜１８のいずれか一項に記載の方法を実行するように動作することができる請求項１９に記載の移動通信デバイス。
21. コンピュータデバイスに請求項１〜１８のいずれか一項に記載の方法を実行させるためのコンピュータ実施可能命令を含む、コンピュータプログラム。

Images