JP2013179712A - バッファ状態報告装置、システム及び方法 - Google Patents

Abstract

【課題】バッファ状態報告の効率を高め且つバッファ状態報告をアップリンク容量に基づいて適応させるための装置、システム及び方法を提供する。
【解決手段】ユーザ装置は、複数のバッファの使用を監視し、複数のバッファの少なくとも１つに対応する複数の予め選択された条件の１つを検出し、その検出された予め選択された条件に基づいて複数のバッファ状態報告フォーマットの１つを指定し、そしてその指定されたバッファ状態報告フォーマットに基づいてバッファ状態報告をネットワーク装置へ通信するように構成される。バッファ状態報告フォーマットは、バッファ状態報告の通信により生じるバッファ状態報告オーバーヘッドを最小にするように構成される。
【選択図】図３

Description

本発明は、バッファ状態報告を通信するための方法及びシステムに関する。

アップリンクスケジューリングオペレーションをサポートするためのスケジューリング情報は、高速アップリンクパケットアクセス（ＨＳＵＰＡ）において導入された。ＨＳＵＰＡのスケジューリング情報は、基本的に、バッファ状態及び電力空き高(headroom)報告より成る。しかしながら、現在利用できる解決策のもとでバッファ状態報告を通信することは、アップリンク利用性を報告する必要性に基づいてバッファ状態報告フォーマットを調整することができないために、効率的でなく且つ融通性もない。

本発明は、技術現状、特に、現在利用できる通信システム技術によってまだ完全に解決されていない技術上の問題及びニーズに応じて開発された。従って、本発明は、バッファ状態報告装置、システム及び方法を可能にするために開発されたものである。

本発明の一実施形態において、この方法は、複数のバッファの使用を監視し、該複数のバッファに対応する複数の予め選択された条件の１つを検出し、その検出された予め選択された条件に基づいて複数のバッファ状態報告フォーマットの１つを指定し、そしてその指定されたバッファ状態報告フォーマットに基づいてバッファ状態報告をネットワーク装置へ通信することを含む。ある実施形態において、バッファ状態報告フォーマットは、バッファ状態報告の通信により生じるバッファ状態報告オーバーヘッドを最小にする。幾つかの実施形態において、複数の予め選択された条件は、無線ベアラグループに関連したバッファが予め選択されたスレッシュホールドを越えるデータを記憶することを含む。

ある実施形態において、複数のバッファ状態報告フォーマットは、長いバッファ状態報告フォーマット、及び短いバッファ状態報告フォーマットを含む。短いバッファ状態報告フォーマットは、単一の無線ベアラグループのバッファ状態を報告することに対応する。更に、長いバッファ状態報告フォーマットは、複数の無線ベアラグループのバッファ状態を報告することに対応する。

幾つかの実施形態において、指定ユニットは、長いバッファ状態報告フォーマットを使用して通信するに充分なアップリンク容量があるときには長いバッファ状態報告フォーマットのみを指定するように構成される。ある実施形態において、指定ユニットは、異なる無線ベアラグループの複数のバッファが予め選択されたスレッシュホールドを越えるデータを記憶するときには長いバッファ状態報告フォーマットのみを指定するように構成される。幾つかの実施形態において、指定ユニットは、アップリンク容量が不充分であるときには短いバッファ状態報告フォーマットを指定するように構成される。

幾つかの実施形態において、短いバッファ状態報告フォーマットは、１バイトの情報を含み、そして長いバッファ状態報告フォーマットは、３バイトの情報を含む。しかしながら、他の実施形態では、短いバッファ状態報告フォーマットは、２ビットの無線ベアラグループ識別子及び６ビットのバッファサイズも含む。又、ある実施形態において、長いバッファ状態報告フォーマットは、６ビットの情報の４つのセグメントを含み、各セグメントは、個別の無線ベアラグループに対応する。ある実施形態において、前記方法は、最も高いプライオリティの無線ベアラグループのバッファ状態を選択することも含む。最も高いプライオリティの無線ベアラグループは、無線ベアラグループバッファに最大量のデータを有する無線ベアラグループを含む。

本発明の別の実施形態において、装置は、複数のバッファの使用を監視するように構成された監視ユニットと、複数のバッファに対応する複数の予め選択された条件の１つを検出するように構成された検出ユニットと、その検出された予め選択された条件に基づいて複数のバッファ状態報告フォーマットの１つを指定するように構成された指定ユニットと、その指定されたバッファ状態報告フォーマットに基づいてバッファ状態報告をネットワーク装置へ通信するように構成された通信ユニットと、を備えている。

ある実施形態において、バッファ状態報告フォーマットは、バッファ状態報告の通信により生じるバッファ状態報告オーバーヘッドを最小にするように構成される。短いバッファ状態報告フォーマットは、単一の無線ベアラグループのバッファ状態を報告することに対応する。更に、長いバッファ状態報告フォーマットは、複数の無線ベアラグループのバッファ状態を報告することに対応する。

幾つかの実施形態において、指定ユニットは、長いバッファ状態報告フォーマットを使用して通信するに充分なアップリンク容量があるときには長いバッファ状態報告フォーマットのみを指定するように構成される。ある実施形態において、指定ユニットは、異なる無線ベアラグループの複数のバッファが予め選択されたスレッシュホールドを越えるデータを記憶するときには長いバッファ状態報告フォーマットのみを指定するように構成される。幾つかの実施形態において、指定ユニットは、アップリンク容量が不充分であるときには短いバッファ状態報告フォーマットを指定するように構成される。

幾つかの実施形態において、短いバッファ状態報告フォーマットは、１バイトの情報を含み、そして長いバッファ状態報告フォーマットは、３バイトの情報を含む。しかしながら、他の実施形態では、短いバッファ状態報告フォーマットは、２ビットの無線ベアラグループ識別子及び６ビットのバッファサイズも含む。又、ある実施形態において、長いバッファ状態報告フォーマットは、６ビットの情報の４つのセグメントを含み、各セグメントは、個別の無線ベアラグループに対応する。ある実施形態において、前記方法は、最も高いプライオリティの無線ベアラグループのバッファ状態を選択することも含む。最も高いプライオリティの無線ベアラグループは、無線ベアラグループバッファに最大量のデータを有する無線ベアラグループを含む。

本発明の別の実施形態において、装置は、複数のバッファの使用を監視するための監視手段と、複数のバッファに対応する複数の予め選択された条件の１つを検出するための検出手段とを備えている。又、装置は、その検出された予め選択された条件に基づいて複数のバッファ状態報告フォーマットの１つを指定するための指定手段と、その指定されたバッファ状態報告フォーマットに基づいてバッファ状態報告をネットワーク装置へ通信するための通信手段とを備えている。

本発明の一実施形態において、方法は、複数のバッファの使用を監視し、複数のバッファに対応する複数の予め選択された条件の１つを検出し、その検出された予め選択された条件に基づいて複数のバッファ状態報告フォーマットの１つを指定し、そしてその指定されたバッファ状態報告フォーマットに基づいてバッファ状態報告をネットワーク装置へ通信することを含む。ある実施形態において、バッファ状態報告フォーマットは、バッファ状態報告の通信により生じるバッファ状態報告オーバーヘッドを最小にする。ある実施形態において、複数の予め選択された条件は、無線ベアラグループに関連したバッファが予め選択されたスレッシュホールドを越えるデータを記憶することを含む。

ある実施形態において、複数のバッファ状態報告フォーマットは、長いバッファ状態報告フォーマット、及び短いバッファ状態報告フォーマットを含む。短いバッファ状態報告フォーマットは、単一の無線ベアラグループのバッファ状態を報告することに対応する。更に、長いバッファ状態報告フォーマットは、複数の無線ベアラグループのバッファ状態を報告することに対応する。

幾つかの実施形態において、指定ユニットは、長いバッファ状態報告フォーマットを使用して通信するに充分なアップリンク容量があるときには長いバッファ状態報告フォーマットのみを指定するように構成される。ある実施形態において、指定ユニットは、異なる無線ベアラグループの複数のバッファが予め選択されたスレッシュホールドを越えるデータを記憶するときには長いバッファ状態報告フォーマットのみを指定するように構成される。幾つかの実施形態において、指定ユニットは、アップリンク容量が不充分であるときには短いバッファ状態報告フォーマットを指定するように構成される。

幾つかの実施形態において、短いバッファ状態報告フォーマットは、１バイトの情報を含み、そして長いバッファ状態報告フォーマットは、３バイトの情報を含む。しかしながら、他の実施形態では、短いバッファ状態報告フォーマットは、２ビットの無線ベアラグループ識別子及び６ビットのバッファサイズも含む。又、ある実施形態において、長いバッファ状態報告フォーマットは、６ビットの情報の４つのセグメントを含み、各セグメントは、個別の無線ベアラグループに対応する。ある実施形態において、前記方法は、最も高いプライオリティの無線ベアラグループのバッファ状態を選択することも含む。最も高いプライオリティの無線ベアラグループは、無線ベアラグループバッファに最大量のデータを有する無線ベアラグループを含む。

本発明の別の実施形態において、装置は、複数のバッファの使用を監視するように構成された監視ユニットと、複数のバッファに対応する複数の予め選択された条件の１つを検出するように構成された検出ユニットと、その検出された予め選択された条件に基づいて複数のバッファ状態報告フォーマットの１つを指定するように構成された指定ユニットと、その指定されたバッファ状態報告フォーマットに基づいてバッファ状態報告をネットワーク装置へ通信するように構成された通信ユニットと、を備えている。

ある実施形態において、バッファ状態報告フォーマットは、バッファ状態報告の通信により生じるバッファ状態報告オーバーヘッドを最小にするように構成される。短いバッファ状態報告フォーマットは、単一の無線ベアラグループのバッファ状態を報告することに対応する。更に、長いバッファ状態報告フォーマットは、複数の無線ベアラグループのバッファ状態を報告することに対応する。

幾つかの実施形態において、指定ユニットは、長いバッファ状態報告フォーマットを使用して通信するに充分なアップリンク容量があるときには長いバッファ状態報告フォーマットのみを指定するように構成される。ある実施形態において、指定ユニットは、異なる無線ベアラグループの複数のバッファが予め選択されたスレッシュホールドを越えるデータを記憶するときには長いバッファ状態報告フォーマットのみを指定するように構成される。幾つかの実施形態において、指定ユニットは、アップリンク容量が不充分であるときには短いバッファ状態報告フォーマットを指定するように構成される。

幾つかの実施形態において、短いバッファ状態報告フォーマットは、１バイトの情報を含み、そして長いバッファ状態報告フォーマットは、３バイトの情報を含む。しかしながら、他の実施形態では、短いバッファ状態報告フォーマットは、２ビットの無線ベアラグループ識別子及び６ビットのバッファサイズも含む。又、ある実施形態において、長いバッファ状態報告フォーマットは、６ビットの情報の４つのセグメントを含み、各セグメントは、個別の無線ベアラグループに対応する。ある実施形態において、前記方法は、最も高いプライオリティの無線ベアラグループのバッファ状態を選択することも含む。最も高いプライオリティの無線ベアラグループは、無線ベアラグループバッファに最大量のデータを有する無線ベアラグループを含む。

本発明の別の実施形態において、装置は、複数のバッファの使用を監視するための監視手段と、複数のバッファに対応する複数の予め選択された条件の１つを検出するための検出手段とを備えている。又、装置は、その検出された予め選択された条件に基づいて複数のバッファ状態報告フォーマットの１つを指定するための指定手段と、その指定されたバッファ状態報告フォーマットに基づいてバッファ状態報告をネットワーク装置へ通信するための通信手段とを備えている。

本発明の更に別の実施形態において、複数のバッファの使用を監視し、複数のバッファに対応する複数の予め選択された条件の１つを検出することを含むオペレーションを遂行するようにプロセッサを制御するよう構成されたコンピュータプログラムでコンピュータ読み取り可能な媒体がエンコードされる。又、前記オペレーションは、その検出された予め選択された条件に基づいて複数のバッファ状態報告フォーマットの１つを指定し、そしてその指定されたバッファ状態報告フォーマットに基づいてバッファ状態報告をネットワーク装置へ通信することも含む。

本発明の更に別の実施形態において、複数のバッファの使用を監視し、複数のバッファに対応する複数の予め選択された条件の１つを検出することを含むオペレーションを遂行するようにプロセッサを制御するよう構成されたコンピュータプログラムでコンピュータ読み取り可能な媒体がエンコードされる。又、前記オペレーションは、その検出された予め選択された条件に基づいて複数のバッファ状態報告フォーマットの１つを指定し、そしてその指定されたバッファ状態報告フォーマットに基づいてバッファ状態報告をネットワーク装置へ通信することも含む。

本発明が容易に理解されるように保証するために、以上に簡単に述べた本発明を、添付図面に示された特定の実施形態を参照して詳細に説明する。これら添付図面は、本発明の典型的な実施形態を示すものに過ぎず、又、本発明の範囲を限定するものではないことを理解した上で、添付図面の使用により本発明を更に特定に且つ詳細に説明する。

本発明の一実施形態によるシステムのブロック図である。 本発明の一実施形態によるユーザ装置のブロック図である。 本発明の一実施形態による方法のフローチャートである。 本発明の一実施形態による方法のフローチャートである。 本発明の一実施形態による短いバッファ状態報告フォーマットを表すブロック図である。 本発明の一実施形態による長いバッファ状態報告フォーマットを表すブロック図である。

添付図面に示して一般に説明する本発明のコンポーネントは、種々様々な異なる構成で配置及び設計できることが容易に理解されよう。従って、添付図面に示す本発明の装置、システム及び方法の実施形態の以下の詳細な説明は、請求項に述べた本発明の範囲を限定するものではなく、本発明の選択された実施形態を単に例示するものに過ぎない。

実際に、本明細書全体にわたって述べる本発明の特徴、構造、又は特性は、１つ以上の実施形態において適当な仕方で組み合わせることができる。例えば、本明細書全体にわたって使用する「ある実施形態」、「幾つかの実施形態」又は同様の語は、その実施形態に関連して述べる特定の特徴、構造又は特性が、本発明の少なくとも１つの実施形態に含まれることを意味する。従って、本明細書全体にわたり「ある実施形態」、「幾つかの実施形態」、「他の実施形態」又は同様の語が現れたときは、必ずしもその全部が実施形態の同じグループを指すものではなく、ここに述べる特徴、構造又は特性は、１つ以上の実施形態において適当に組み合わせることができる。

図１は、本発明の一実施形態によるシステム１００のブロック図である。ここに示すシステム１００は、ユーザ装置（ＵＥ）１１０及びネットワーク装置１２０を備えている。システム１００のコンポーネントは、アップリンク容量に基づいてバッファ状態報告効率を最大にするように協働する。

ある実施形態では、ネットワーク装置１２０は、ユーザ装置１１０からバッファ状態報告を受け取るよう構成される。幾つかの実施形態では、ユーザ装置は、複数のバッファの使用を監視し、そして複数のバッファの少なくとも１つに対応する複数の予め選択された条件の１つを検出するように構成される。ある実施形態では、ユーザ装置は、その検出された予め選択された条件に基づいて複数のバッファ状態報告フォーマットの１つを指定し、そしてその指定されたバッファ状態報告フォーマットに基づいてバッファ状態報告をネットワーク装置へ通信するようにも構成される。

実施形態に基づき、指定されたバッファ状態報告フォーマットは、バッファ状態報告の通信により生じるバッファ状態報告オーバーヘッドを最小にする。従って、システム１００は、バッファ状態報告オーバーヘッドを最小にするように動作する。以下に更に詳細に述べるように、幾つかの実施形態では、システム１００は、ユーザ装置のアップリンク容量に基づいてバッファ状態報告オーバーヘッドを最小にするように動作する。

図２は、本発明の一実施形態によるユーザ装置２００のブロック図である。ここに示すユーザ装置２００は、監視ユニット２１０と、複数の通信バッファ２２０と、検出ユニット２３０と、アップリンク容量検出ユニット２４０と、バッファプライオリティ決めユニット２５０と、フォーマット指定ユニット２６０と、通信ユニット２７０と、を備えている。ユーザ装置２００のこれらユニットは、バッファ状態報告効率をアップリンク容量に基づいて最大にするように協働する。

幾つかの実施形態では、監視ユニット２１０は、複数のバッファ２２０の使用を監視するよう構成される。ある実施形態では、監視ユニット２１０及び検出ユニット２３０は、検出ユニット２３０が、複数のバッファに対応する複数の予め選択された条件の１つを検出できるように協働する。予め選択された条件は、以下で詳細に述べるが、例えば、１つ以上のバッファのデータや、予め選択されたスレッシュホールドを越える１つ以上のバッファのデータを含む。

ある実施形態では、指定ユニット２６０は、検出された予め選択された条件に基づいて複数のバッファ状態報告フォーマットの１つを指定するように構成される。ある実施形態では、複数のバッファ状態報告フォーマットは、短いフォーマット及び長いフォーマットを含む。以下に詳細に述べるように、幾つかの実施形態では、短いバッファ状態報告フォーマットは、単一の無線ベアラグループのバッファ状態を報告することに対応し、そして長いバッファ状態報告フォーマットは、複数の無線ベアラグループのバッファ状態を報告することに対応する。

ある実施形態では、アップリンク容量検出ユニット２４０は、ユーザ装置２００のアップリンク容量を検出する。このような実施形態では、アップリンク容量検出ユニット２４０は、指定ユニット２６０と協働して、適切なバッファ状態報告フォーマットを確認する。ある実施形態では、指定ユニット２６０により提案されるフォーマットは、アップリンク容量検出ユニット２４０により検出されたアップリンク容量を越える。

このような実施形態では、バッファプライオリティ決めユニット２５０は、アップリンク容量検出ユニット２４０及び指定ユニット２６０と協力して、指定ユニット２６０が、ユーザ装置２００のアップリンク容量に全て基づいて、最も有益なバッファ状態報告フォーマットを、最も高いプライオリティのバッファに割り当て／指定できるようにする。この協働は、図４において更に説明する。ある実施形態では、通信ユニット２７０は、指定されたバッファ状態報告フォーマットに基づいてバッファ状態報告をネットワーク装置へ通信するように構成される。このように、ユーザ装置は、バッファ状態報告の効率をユーザ装置のアップリンク容量に基づいて最大にすることができる。

ある実施形態では、バッファ状態報告（ＢＳＲ）に対して、無線ベアラを４つの無線ベアラグループ（ＲＢＧ）へと分類することができる。ＲＢＧへの無線ベアラのマッピングは、規格において固定することもできるし、又はＲＲＣにより動的に構成することもできる。両方の場合に、ＲＢＧは、１つの無線ベアラしか含まなくてもよいし、又はその全部を含んでもよい。

４つのＲＢＧを常にサポートする必要はないので（例えば、限定数のベアラしか構成されないときに）、複数のフォーマットのバッファ状態報告が有益である。第１のフォーマットでは、ＲＢＧ識別のために２つのビットが要求されるが、後者のケースでは、４つのバッファサイズフィールドが図５及び６に示すように連結される。

ある実施形態では、バッファ状態報告は、電力空き高報告、ＨＳＵＰＡプロトコル（高速アップリンクパケットアクセス）、ｅＮＢ（増強ノードＢ）、及びＥ−ＴＲＡＮ（ユニバーサル移動テレコミュニケーションズサービス（ＵＭＴＳ）地上無線アクセスネットワーク）に直接関係している。換言すれば、電力空き高報告は、ＨＳＵＰＡに対して最初に導入された。無線最適リソース管理は、ユーザ装置が最大送信電力の近くで動作しているかどうかｅＮＢが知ることを要求する。更に、適応送信帯域巾（即ち、ユーザ送信帯域巾をＴＴＩベースで変更できる）であるので、Ｅ−ＵＴＲＡＮアップリンクでは、例えば、最大ユーザ装置電力能力が与えられたときにサポートできない送信帯域巾をｅＮＢが割り当てるのを回避するために、ユーザ装置で使用される電力スペクトル密度を知ることが更に重要である。

４０−６０ｄＢの電力制御ダイナミックレンジ及び１ｄＢの解像度を仮定すれば（ＵＥにおいて行われる送信電力測定の実際の精度を考慮するとき、より微細な解像度は有益でないことがある）、アップリンクにおける電力空き高報告の送信のために６ビットで充分であると思われる。合計ビット数は、ＲＡＮ１及びＲＡＮ4により決定できるが、ＲＡＮ２では、電力空き高報告に１バイトで充分であると仮定する。実際に、幾つかの実施形態では、電力空き高報告は、１バイトの長さである。

本明細書で述べる多くの機能的ユニットは、それらの具現化独立性を特に強調するためにユニットと表示されている。例えば、ユニットは、カスタムＶＬＳＩ回路又はゲートアレイを含むハードウェア回路、既製の半導体、例えば、ロジックチップ、トランジスタ、又は他の個別コンポーネントとして実施することができる。又、ユニットは、プログラム可能なハードウェア装置、例えば、フィールドプログラマブルゲートアレイ、プログラマブルアレイロジック、プログラマブルロジック装置、等において実施することもできる。

又、ユニットは、種々の形式のプロセッサによって実行するためのソフトウェアで実施することもできる。実行可能なコードの識別されたユニットは、例えば、オブジェクト、手順又はファンクションとして編成されるコンピュータインストラクションの１つ以上の物理的又は論理的ブロックを含む。それでも、識別されたユニットの実行可能部は、物理的に一緒に配置される必要がなく、異なる位置に記憶された個別のインストラクションを含んでもよく、それらは、論理的に一緒に結合されたときに、ユニットを構成し、ユニットに対して述べられた目的を果たすものである。

実際に、実行可能なコードのユニットは、単一のインストラクションでも、多数のインストラクションでもよく、そして多数の異なるコードセグメントにわたり、異なるプログラム間で、異なるプロセッサ間で、且つ多数のメモリデバイスにわたり分布させることができる。同様に、演算データは、ここでは、ユニット内で識別されて示され、適当な形態で実施され、且つ適当な形式のデータ構造内に編成される。演算データは、単一のデータセットとして収集されてもよいし、異なる記憶装置を含む異なる位置にわたって分布されてもよく、そして少なくとも一部は、単にシステム又はネットワーク上の電子信号として存在してもよい。

更に、本発明の説明では、データ、パケット、及び／又はデータグラムという語が使用されるが、本発明は、多数の形式のネットワークデータをインポートする。本発明の説明上、データという語は、パケット、セル、フレーム、データグラム、ブリッジプロトコルデータユニットパケット、パケットデータ、及びその等効物を含む。

図３は、本発明の一実施形態による方法３００のフローチャートである。ここに示す方法３００は、バッファを監視し（３１０）、予め選択された条件を検出し（３２０）、フォーマットを指定し（３３０）、そしてバッファ状態報告を通信する（３４０）ことを含む。方法３００のオペレーションは、バッファ状態報告の効率をアップリンク容量に基づいて最大にするように協力するための解決策を提供する。

ある実施形態では、バッファを監視すること（３１０）は、１つ以上の通信バッファの使用を監視することを含む。幾つかの実施形態では、予め選択された条件を検出すること（３２０）は、１つ以上の通信バッファがデータを含むことを検出するか、又は通信バッファ内のデータが所定のスレッシュホールドを越えたことを検出する、ことを含む。ある実施形態では、フォーマットを指定すること（３３０）は、オペレーション３２０により検出された予め選択された条件に対して相補的なバッファ状態報告フォーマットを指定することを含む。検出オペレーション３２０及び指定オペレーション３３０は、図４及び５において更に詳細に説明する。幾つかの実施形態では、通信３４０は、指定オペレーション３３０により指定されたバッファ状態報告フォーマットに基づいて１つ以上のバッファに対応するバッファ状態報告を通信することを含む。

図４は、本発明の一実施形態による方法４００のフローチャートである。この方法４００は、バッファを監視するオペレーション４１０と、バッファの少なくとも１つがデータを有するかどうか決定するオペレーション４２０と、複数のバッファがデータを有するかどうか決定するオペレーション４３０と、アップリンク容量を決定するオペレーション４４０と、短いフォーマットを指定するオペレーション４５０と、長いフォーマットを指定するオペレーション４６０と、バッファプライオリティを決定するオペレーション４７０と、短いフォーマットを指定するオペレーション４８０と、バッファ状態報告を通信するオペレーション４９０と、を含む。方法４００のオペレーションは、バッファ状態報告の効率をアップリンク容量に基づいて最大にする。

ある実施形態では、方法４００は、複数のバッファのうちの少なくとも１つのバッファがデータを有するかどうか監視する（４１０）ことにより開始される。データがない場合には、方法４００は、バッファの監視（４１０）を続ける。しかしながら、データを伴う少なくとも１つのバッファがある場合には、この方法は、複数のバッファがデータを有するかどうか決定する（４３０）ことにより続く。１つのバッファしかデータをもたない場合には、方法４００は、通信（４９０）のために短いバッファ状態報告フォーマットを指定する（４５０）ことにより続く。

しかしながら、複数の通信バッファがデータを有する場合には、方法４００は、通信（４９０）のために長いバッファ状態報告フォーマットを使用してバッファ状態報告を通信するのに充分なアップリンク容量があるかどうか決定する（４４０）ことにより続く。充分なアップリンク容量がある場合には、方法４００は、長いバッファ状態報告フォーマットを指定することにより続く。しかしながら、長いフォーマットを使用するに充分なアップリンク容量がない場合には、方法４００は、データをもつバッファを決定する（４７０）ことにより続く。バッファのプライオリティが決定された後、方法４００は、最も高いプライオリティのバッファを通信する（４９０）ために短いバッファ状態報告フォーマットを指定することにより続く。このようにして、方法４００は、バッファ状態報告の効率をアップリンク容量に基づいて最大にする。

図５は、本発明の一実施形態による短いバッファ状態報告フォーマット５００を表すブロック図である。ここに示す短いバッファ状態報告フォーマット５００は、無線ベアラグループアイデンティティ５１０及びバッファサイズ５２０を含む。無線ベアラグループアイデンティティ５１０は、バッファ状態を知るために、即ち無線ベアラグループに対応するバッファにおけるデータを決定するために、ベースステーションのようなネットワーク装置をイネーブルする。ある実施形態では、短いバッファ状態報告フォーマット５００は、バッファ状態報告を行うために指定される。というのは、短いバッファ状態報告フォーマット５００は、最も効率の高いフォーマットだからである。

図６は、本発明の一実施形態による長いバッファ状態報告フォーマット６００を表すブロック図である。この長いバッファ状態報告フォーマット６００は、無線ベアラグループ１のバッファサイズ（６１０）と、無線ベアラグループ２のバッファサイズ（６２０）と、無線ベアラグループ３のバッファサイズ（６３０）と、無線ベアラグループ４のバッファサイズ（６４０）とを含む。長いバッファ状態報告フォーマット６００は、６ビットの４つのグループで割り当てられる。ある実施形態では、図５の短いバッファ状態報告フォーマット５００と同様に、長いバッファ状態報告フォーマット６００は、複数の無線ベアラグループのバッファ状態報告を行うために指定される。というのは、長いバッファ状態報告フォーマット６００は、最も効率の良いフォーマットだからである。従って、本発明は、必要に応じてバッファ状態報告のフォーマットを調整するための解決策を提供することにより効率を促進する。

バッファ状態報告に関しては、ＨＳＵＰＡに比して、Ｅ−ＵＴＲＡＮアップリンクは、直交マルチアクセススキム（ＳＣ−ＦＤＭＡ）に基づくものである。これらの状況のもとでは、送信すべきデータをもたないユーザに無線リソースを割り当てると、直接的に容量ロスを招くので、Ｅ−ＵＴＲＡＮアップリンクではバッファ状態報告スキムの設計が比較的重要である。

Ｅ−ＵＴＲＡＮにおけるバッファ状態報告は、異なるサービスクオリティ（ＱｏＳ）要求をもつ無線ベアラ間を区別できるようにする。ｅＮＢにおいてＱｏＳを区別できるようにするため、ある実施形態では、プライオリティベースのバッファ状態報告が与えられ、ここで、プライオリティバッファ状態報告とは、異なるプライオリティクラスに対するバッファ状態情報を含む「減少」バッファ状態報告である。プライオリティクラスは、同様のＱｏＳ要求をもつ無線ベアラをグループ化することにより定義される（が、１つのプライオリティクラスが１つの無線ベアラのみで構成されてもよい）。報告すべき無線ベアラグループの数は、スケジューラに充分な情報を与えるためにはあまり小さくてはならず、又、オーバーヘッドを制限するためにあまり大きくすることができない。ＬＣＩＤのための５ビットのサイズでは、４つの無線ベアラグループの合計が良好な妥協となる。従って、無線ベアラは、４つの無線ベアラグループ（ＲＢＧ）へと分類することができる。

全部で４つのＲＢＧは、グループの識別のために２ビットを含む。幾つかの実施形態では、バッファ状態報告（ＢＳＲ）の合計サイズは、バイト整列される。このような実施形態では、バッファサイズに対する候補サイズは、６ビット及び１４ビットである。しかしながら、１４ビットバッファサイズテーブルは、１６３８４個のコードポイント及び０．０７％のステップサイズを与え、これでは大き過ぎる。６ビットバッファサイズは、６４個のコードポイント及び１２．７７％のステップサイズを与え、これは、ＨＳＵＰＡの３２個のコードポイント及び２３．９％のステップサイズに匹敵する。従って、６ビットのバッファサイズフィールドが有益である。

実施形態にもよるが、バッファサイズとは、搬送ブロックを埋める前にバッファされるデータの量であるか、又は搬送ブロックを埋めた後にバッファされるデータの量である。幾つかの実施形態では、バッファ状態報告（ＢＳＲ）は、将来のリソースを割り当てる上でスケジューラを助けることを目的とする。従って、搬送ブロックを埋めた後にバッファされるデータの量を考慮するのが論理的である。従って、幾つかの実施形態では、バッファ状態報告は、搬送ブロックを埋めた後にバッファに残っているデータの量を含む。

幾つかの実施形態では、データは、無線リンク制御（ＲＬＣ）及びパケットデータ収斂プロトコル（ＰＤＣＰ）にわたってユーザ装置にバッファされる。ＲＬＣは、送信及び再送信のために暗号化及び圧縮されたＰＤＣＰプロトコルデータユニット（ＰＤＵ）を待機し、一方、ＰＤＣＰでは、非暗号化及び非圧縮のＰＤＣＰサービスデータユニット（ＳＤＵ）がバッファされる。ＰＤＣＰ ＳＤＵを処理して、送信のためにＲＬＣに与えることができるかどうかは、ＵＥの具現化の問題である。それ故、正に同じサービスに対して、異なるＵＥは、ＲＬＣが考慮されるかＰＤＣＰが考慮されるかに基づいて異なるＢＳＲを報告する。報告において考えられる非一貫性を減少するために、ＲＬＣとＰＤＣＰとの間を区別せずにバッファされたデータの合計量を報告することが行われる。ある実施形態では、ボイスオーバーインターネットプロトコル（ＶｏＩＰ）に対して特殊な考慮がなされる。幾つかの実施形態では、バッファ状態報告は、ＲＬＣであるかＰＤＣＰであるかに関わらず、無線ベアラグループ当たりの合計バッファデータ量を含む。

常に４つのＲＢＧを報告する必要はなく（例えば、限定された数のベアラしか構成されないときには）、ＢＳＲの２つのフォーマットを導入するのが有益である。その１つは、１つのＲＢＧしか報告されないものであり、そしてもう１つは、４つのＲＢＧ全部が報告されるものである。最初のケースでは、ＲＢＧ識別に２ビットが有益であり、一方、後者のケースでは、図６に示すように、４つのバッファサイズフィールドを結合することができる。

ある実施形態では、メディアアクセスコントロール（ＭＡＣ）のコントロール要素がバッファ状態報告及び電力空き高報告を搬送する。ある実施形態では、これは、電力空き高報告に使用される１つの言語コード識別子（ＬＣＩＤ）と、短いバッファ状態報告に使用される１つのＬＣＩＤと、長いバッファ状態報告に使用される１つのＬＣＩＤとを含む。幾つかの実施形態では、電力空き高が、ほとんどの時間に、長い又は短いバッファ状態報告と共に搬送されると思われる場合に、２つの情報を連結してシグナリングオーバーヘッドを減少するために、付加的なＬＣＩＤを予約することができる。

幾つかの実施形態では、検出された条件は、異なる無線ベアラグループ（ＲＢＧ）にバッファされるデータの量に依存するトリガーを含む。トリガーは、例えば、１つのＲＢＧしかバッファデータをもたず、短いフォーマットを使用して報告がなされるというシナリオを含むことができる。トリガーの別の例は、２つ以上のＲＢＧがバッファデータを有していて、長いＢＳＲフォーマットで報告がなされるというシナリオを含むことができる。幾つかの実施形態では、増強型ノードＢ（ｅＮＢ）が短いＢＳＲフォーマットを受け取るときに、ｅＮＢは、報告されたもの以外のＲＢＧがバッファされたデータをもたないことを知る。

幾つかの実施形態において、ＲＢＧベースで構成できるスレッシュホールドを変形例により導入することができる。従って、幾つかの実施形態では、１つのＲＢＧだけが、スレッシュホールドを越える量のバッファデータを有する場合には、短いＢＳＲフォーマットを使用する報告が通信される。又、幾つかの実施形態では、２つ以上のＲＢＧがそのスレッシュホールドを越える量のバッファデータを有する場合に、長いＢＳＲフォーマットの報告が通信される。従って、ｅＮＢは、短いＢＳＲフォーマットを受け取ると、報告されたもの以外のＲＢＧが、それらの各スレッシュホールドを越える量のバッファデータを有していないことを知る。

更に、幾つかの実施形態では、アップリンク（ＵＬ）許可のサイズも考慮しなければならない（即ち、アップリンク搬送ブロックのサイズ）。例えば、２つ以上のＲＢＧがバッファデータを有し且つＵＬ許可に充分な余裕があるや否や、長いフォーマットを使用する報告を通信することができる。充分なＵＬ許可がない場合には、最も高いプライオリティのＲＢＧ又はバッファデータの量が最大のＲＢＧで、短いフォーマットを通信することができる。他の実施形態では、２つ以上のＲＢＧが、スレッシュホールドを越える量のバッファデータを有し、且つ長いフォーマットの通信を許可するに充分な余裕がＵＬにあるや否や、長いＢＳＲフォーマットが使用され、さもなければ、最も高いプライオリティのＲＢＧ又はバッファデータの量が最大のＲＢＧで、短いフォーマットを使用して通信が行われる。従って、本発明は、ＢＳＲに関連したオーバーヘッドを最小にし、且つ利用可能なＵＬ帯域巾に適応させることができる。

コンピュータ読み取り可能な媒体を言及するときには、信号を発生し、信号を発生させ、又はデジタル処理装置においてマシン読み取り可能なインストラクションのプログラムを実行させることのできるいかなる形態をとることもできる。コンピュータ読み取り可能な媒体は、伝送線、コンパクトディスク、デジタルビデオディスク、磁気テープ、ベルヌーイドライブ、磁気ディスク、ホログラフディスク又はテープ、パンチカード、フラッシュメモリ、磁気抵抗メモリ、集積回路、又は他のデジタル処理装置メモリデバイスにより実施することができる。

更に、本発明のここに述べる特徴、構造又は特性は、１つ以上の実施形態において適当な仕方で組み合わせることができる。しかしながら、当業者であれば、１つ以上の特定の細部なしに、又は他の方法、コンポーネント、材料、等で、本発明を実施できることが明らかであろう。他の点について、本発明の態様を不明瞭にしないために、良く知られた構造、材料、又はオペレーションは、詳細に図示も説明もしない。

当業者であれば、上述した本発明は、異なる順序のステップで、及び／又はここに開示したものとは異なる構成のハードウェア要素で、実施できることが容易に理解されよう。それ故、本発明は、好ましい実施形態に基づいて説明したが、本発明の精神及び範囲から逸脱せずに、幾つかの変更、修正、及び代替構造が当業者に明らかであろう。

１１０：ユーザ装置
１２０：ネットワーク装置
２００：ユーザ装置
２１０：監視ユニット
２２０：通信バッファ
２３０：検出ユニット
２４０：アップリンク容量検出ユニット
２５０：バッファプライオリティ決めユニット
２６０：フォーマット指定ユニット
２７０：通信ユニット
５１０：無線ベアラグループアイデンティティ
５２０：バッファサイズ
６１０−６４０：バッファサイズ

Claims (1)

1. 複数のバッファの使用を監視するステップと、
   複数のバッファに対応する複数の予め選択された条件の１つを検出するステップと、
   その検出された予め選択された条件に基づいて複数のバッファ状態報告フォーマットの１つを指定するステップと、
   その指定されたバッファ状態報告フォーマットに基づいてバッファ状態報告をネットワーク装置へ通信するステップと、
   を備えた方法。

Images