JP5063781B2 - 無線通信システムでアップリンクデータ及びバッファ状態報告を伝送する方法及びこれを具現する無線装置 - Google Patents

Description

本発明は、セルラー通信ネットワークにおけるパケット伝送に関するもので、特に、無線装置から基地局へのアップリンクデータパケットに対するバッファ状態の報告に関する。以下では、説明の便宜上、ＬＴＥ（ｌｏｎｇ ｔｅｒｍ ｅｖｏｌｕｔｉｏｎ）タイプのセルラーネットワークを中心に記述するが、通信分野における当業者には、以下に開示される発明を様々な形態のセルラーネットワークに適用可能であるということがわかる。

ＵＭＴＳ（Ｕｎｉｖｅｒｓａｌ ｍｏｂｉｌｅ ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ ｓｙｓｔｅｍ）は、ヨーロッパシステムベースのＷＣＤＭＡ（ｗｉｄｅｂａｎｄ ｃｏｄｅ ｄｉｖｉｓｉｏｎ ｍｕｌｔｉｐｌｅ ａｃｃｅｓｓ）、ＧＳＭ（ｇｌｏｂａｌ ｓｙｓｔｅｍ ｆｏｒ ｍｏｂｉｌｅ ｃｏｍｍｕｎｉｃａｔｉｏｎｓ）及びＧＰＲＳ（ｇｅｎｅｒａｌ ｐａｃｋｅｔ ｒａｄｉｏ ｓｅｒｖｉｃｅｓ）で動作する第３世代（３Ｇ）非同期移動通信システムである。ＵＭＴＳのＬＴＥ（ｌｏｎｇ ｔｅｒｍ ｅｖｏｌｕｔｉｏｎ）は、ＵＭＴＳを標準化する３ＧＰＰ（３^ｒｄ ｇｅｎｅｒａｔｉｏｎ ｐａｒｔｎｅｒｓｈｉｐ ｐｒｏｊｅｃｔ）の下に議論中にある。

３ＧＰＰ ＬＴＥは、高速パケット通信を可能にする技術である。ユーザとプロバイダのコスト（ｃｏｓｔ）低減、サービス品質改善、及びカバレッジとシステム容量の改善などを含むＬＴＥの目標のために多くの手法が提案されている。３Ｇ ＬＴＥは、ビット当たりのコスト減少、サービス可用性の増加、周波数帯域の柔軟な使用、単純な構造、開放インタフェース及び上位レベル要求に応じた端末の適応的電力消費を要求する。

図１は、Ｅ−ＵＭＴＳ（ｅｖｏｌｖｅｄ ｕｎｉｖｅｒｓａｌ ｍｏｂｉｌｅ ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ ｓｙｓｔｅｍ）のネットワーク構造を示すブロック図である。Ｅ−ＵＭＴＳはＬＴＥシステムとも呼ばれる。通信ネットワークは、音声及びパケットデータのような多様な通信サービスを提供するために広く配置される。

図１に示すように、Ｅ−ＵＭＴＳネットワークは、Ｅ−ＵＴＲＡＮ（ｅｖｏｌｖｅｄ ＵＭＴＳ ｔｅｒｒｅｓｔｒｉａｌ ｒａｄｉｏ ａｃｃｅｓｓ ｎｅｔｗｏｒｋ）、ＥＰＣ（Ｅｖｏｌｖｅｄ Ｐａｃｋｅｔ Ｃｏｒｅ）及び一つ以上のユーザ機器を含む。Ｅ−ＵＴＲＡＮは、一つ以上のｅＮｏｄｅＢ（ｅｖｏｌｖｅｄ ＮｏｄｅＢまたはｅＮＢ）２０と、一つのセルに位置する複数のＵＥ（ｕｓｅｒ ｅｑｕｉｐｍｅｎｔ）を含む。一つ以上のＥ−ＵＴＲＡＮ ＭＭＥ（ｍｏｂｉｌｉｔｙ ｍａｎａｇｅｍｅｎｔ ｅｎｔｉｔｙ）／ＳＡＥ（ｓｙｓｔｅｍ ａｒｃｈｉｔｅｃｔｕｒｅ ｅｖｏｌｕｔｉｏｎ）ゲートウェイ３０が、ネットワークの終端に位置して、外部ネットワークと連結される。

以下では、ダウンリンクは、ｅＮｏｄｅＢ ２０からＵＥ １０への通信とし、アップリンクは、ＵＥからｅＮｏｄｅへの通信とする。ＵＥ １０は、ユーザが携帯する通信装置とし、これは、ＭＳ（ｍｏｂｉｌｅ ｓｔａｔｉｏｎ）、ＵＴ（ｕｓｅｒ ｔｅｒｍｉｎａｌ）、ＳＳ（ｓｕｂｓｃｒｉｂｅｒ ｓｔａｔｉｏｎ）または無線装置とも呼ばれる。

ｅＮｏｄｅＢ ２０は、ＵＥ １０にユーザプレーンと制御プレーンの終点を提供する。ＭＭＥ／ＳＡＥゲートウェイ３０は、ＵＥ １０のためのセッションの終点とモビリティマネジメント（ｍｏｂｉｌｉｔｙ ｍａｎａｇｅｍｅｎｔ）機能を提供する。ｅＮｏｄｅＢとＭＭＥ／ＳＡＥゲートウェイは、Ｓ１インタフェースを介して連結される。

ｅＮｏｄｅＢ ２０は、一般的にＵＥ １０と通信する固定した施設であり、これは、ＢＳ（ｂａｓｅｓ ｔａｔｉｏｎ）またはアクセスポイント（ａｃｃｅｓｓ ｐｏｉｎｔ）と呼ばれる。一つのｅＮｏｄｅＢ ２０はセルごとに配置される。ユーザトラフィックと制御トラフィックを伝送するためのインタフェースがｅＮｏｄｅＢ ２０間で利用される。

ＭＭＥは、ｅＮｏｄｅＢ ２０に、ページングメッセージの分散、保安制御、待機状態モビリティ制御、ＳＡＥベアラー制御及びＮＡＳ（ｎｏｎ−ａｃｃｅｓｓ ｓｔｒａｔｕｍ）シグナリングの暗号化と完全性保護を含む多様な機能を提供する。ＳＡＥゲートウェイホストは、ページングのためのＵ−プレーンパケットの除去とＵＥモビリティを支援するためのＵ−プレーンのスイッチングを含む多様な機能を提供する。より明確な説明のために、ＭＭＥ／ＳＡＥゲートウェイ３０は、以下ではゲートウェイと簡単に呼ばれるが、このようなエンティティは、ＭＭＥ及びＳＡＥゲートの両方を含むということが理解できる。

多数のノードは、Ｓ１インタフェースを介してｅＮｏｄｅＢ ２０とゲートウェイ３０との間に連結される。ｅＮｏｄｅＢ ２０のそれぞれは、互いにＸ２インタフェースを介して連結され、隣接するｅＮｏｄｅＢは、Ｘ２インタフェースを含むメッシュネットワーク（ｍｅｓｈｅｄ ｎｅｔｗｏｒｋ）構造を有することができる。

図２（ａ）は、一般的なＥ−ＵＴＲＡＮとＥＰＣの構造を示すブロック図である。同図に示すように、ｅＮｏｄｅＢ ２０は、ゲートウェイ３０の選択、ＲＲＣ（Ｒａｄｉｏ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ）活性期間中のゲートウェイへのルーティング、ページングメッセージのスケジューリングと送信、アップリンク及びダウンリンクの両方におけるＵＥ １０へのリソースの動的割当、ｅＮｏｄｅＢ測定の設定と提供、無線ベアラー（ｒａｄｉｏ ｂｅａｒｅｒ）制御、ＲＡＣ（ｒａｄｉｏ ａｄｍｉｓｓｉｏｎ ｃｏｎｔｒｏｌ）、及びＬＴＥ＿ＡＣＴＩＶＥ状態で接続モビリティ（ｃｏｎｎｅｃｔｉｏｎ ｍｏｂｉｌｉｔｙ）制御などを行う。ＥＰＣでは、上述した通り、ゲートウェイ３０は、ページング基盤の機能、ＬＴＥ−ＩＤＬＥ状態管理、ユーザプレーンの暗号化、ＳＡＥ（Ｓｙｓｔｅｍ Ａｒｃｈｉｔｅｃｔｕｒｅ Ｅｖｏｌｕｔｉｏｎ）ベアラー制御、及びＮＡＳ（Ｎｏｎ−Ａｃｃｅｓｓ Ｓｔｒａｔｕｍ）シグナリングの暗号化と完全性保護を行う。

図２（ｂ）及び図２（ｃ）は、Ｅ−ＵＭＴＳにおけるユーザプレーンプロトコルスタックと制御プレーンプロトコルスタックを示す図である。図示のように、プロトコル階層は、通信システム分野で広く知られたＯＳＩ（ｏｐｅｎ ｓｙｓｔｅｍ ｉｎｔｅｒｃｏｎｎｅｃｔｉｏｎ）標準モデルの下位の３層に基づく第１層（Ｌ１）、第２層（Ｌ２）及び第３層（Ｌ３）に区分される。

物理層、すなわち、第１層（Ｌ１）は、物理チャネルを用いて上位層に情報送信サービスを提供する。物理層は、上位レベルに位置しているＭＡＣ（ｍｅｄｉｕｍ ａｃｃｅｓｓ ｃｏｎｔｒｏｌ）層と伝送チャネル（ｔｒａｎｓｐｏｒｔ ｃｈａｎｎｅｌ）を介して連結され、ＭＡＣ層と物理層との間のデータは、伝送チャネルを通じて伝達される。互いに異なる物理層の間、すなわち、送信側物理層と受信側物理層との間には、データが物理チャネルを通じて伝達される。

第２層（Ｌ２）であるＭＡＣ層は、より上位層であるＲＬＣ（ｒａｄｉｏ ｌｉｎｋ ｃｏｎｔｒｏｌ）層に論理チャネル（ｌｏｇｉｃａｌ ｃｈａｎｎｅｌ）を通じてサービスを提供する。第２層（Ｌ２）であるＲＬＣ層は、信頼性あるデータ送信を支援する。図２（ｂ）及び図２（ｃ）に示すＲＬＣ層は、ＲＬＣ機能がＭＡＣ層によって具現されて行われる場合は、ＲＬＣ層自体が要求されないということに注意したい。第２層（Ｌ２）であるＰＤＣＰ（ｐａｃｋｅｔ ｄａｔａ ｃｏｎｖｅｒｇｅｎｃｅ ｐｒｏｔｏｃｏｌ）層は、不要な制御情報を減少させるヘッダ圧縮機能を行い、ＩＰｖ４またはＩＰｖ６のようなＩＰ（Ｉｎｔｅｒｎｅｔ ｐｒｏｔｏｃｏｌ）パケットを用いて送信されるデータは、相対的に小さい帯域幅を持つラジオ（無線）インタフェースを通じて效果的に伝送されることができる。

第３層（Ｌ３）の最下部に位置しているＲＲＣ（ｒａｄｉｏ ｒｅｓｏｕｒｃｅ ｃｏｎｔｒｏｌ）層は、制御プレーンでのみ定義され、無線ベアラー（ＲＢ）の設定、再設定及び解除と関連して論理チャネル、伝送チャネル及び物理チャネルを制御する。ここで、ＲＢとは、装置（ＵＥ）とＥ−ＵＴＲＡＮ間のデータ伝送のために第２層（Ｌ２）によって提供されるサービスを意味する。

図２（ｂ）に示すように、（ネットワーク側上のｅＮｏｄｅＢ ２０で終わる）ＲＬＣ及びＭＡＣ層は、スケジューリング、ＡＲＱ（Ａｕｔｏｍａｔｉｃ Ｒｅｐｅａｔ Ｒｅｑｕｅｓｔ）及びＨＡＲＱ（ｈｙｂｒｉｄ ａｕｔｏｍａｔｉｃ ｒｅｐｅａｔ ｒｅｑｕｅｓｔ）のような機能を行う。（ネットワーク側上のｅＮｏｄｅＢ ２０で終わる）ＰＤＣＰ層は、ヘッダ圧縮、完全性保護及び暗号化のようなユーザプレーン機能を果たす。

図２（ｃ）に示すように、（ネットワーク側上のｅＮｏｄｅＢ ２０で終わる）ＲＬＣ及びＭＡＣ層は、制御プレーンでも同一の機能を行う。図示のように、（ネットワーク側上のｅＮｏｄｅＢ ２０で終わる）ＲＲＣ層は、ブロードキャスティング、ページング、ＲＲＣ接続管理、ＲＢ（Ｒａｄｉｏ Ｂｅａｒｅｒ）制御、モビリティ機能、ＵＥ測定報告と制御のような機能を果たす。（ネットワーク側上のＭＭＥゲートウェイ３０で終わる）ＮＡＳ制御プロトコルは、ＳＡＥベアラー管理、認証、ＬＴＥ＿ＩＤＬＥモビリティハンドリング、ＬＴＥ＿ＩＤＬＥでのページング開始（ｏｒｉｇｉｎａｔｉｏｎ）及びゲートウェイとＵＥ １０との間のシグナリングのための保安制御のような機能を果たす。

ＮＡＳ制御プロトコルは、三つの異なる状態を利用する。第一に、ＲＲＣエンティティがない場合のＬＴＥ＿ＤＥＴＡＣＨＥＤ状態であり、第二に、最小限のＵＥ情報を保存するが、ＲＲＣ接続はないＬＴＥ＿ＩＤＬＥ ｓｔａｔｅ状態であり、第三に、ＲＲＣ接続が形成されたＬＴＥ＿ＡＣＴＩＶＥ状態である。また、ＲＲＣ状態は、ＲＲＣ＿ＩＤＬＥとＲＲＣ＿ＣＯＮＮＥＣＴＥＤのような２つの異なる状態に区別される。

ＲＲＣ＿ＩＤＬＥ状態では、ＵＥ １０が、ＮＡＳによって設定されたＤＲＸ（Ｄｉｓｃｏｎｔｉｎｕｏｕｓ Ｒｅｃｅｐｔｉｏｎ）を特定しながら、システム情報とページング情報に関する放送（ｂｒｏａｄｃａｓｔ）を受信する。また、ＵＥには、追跡領域でＵＥを唯一に確認するＩＤ（ｉｄｅｎｔｉｆｉｃａｔｉｏｎ）が割り当てられる。また、ＲＲＣ−ＩＤＬＥ状態では、ｅＮｏｄｅＢにＲＲＣ情報が保存されない。

ＲＲＣ＿ＣＯＮＮＥＣＴＥＤ状態で、ＵＥ １０はＥ−ＵＴＲＡＮとＲＲＣ接続されながら、Ｅ−ＵＴＲＡＮにはＵＥ情報を含め、これにより、ネットワーク（ｅＮｏｄｅＢ）にまたはネットワーク（ｅＮｏｄｅＢ）からデータを伝送及び／または受信可能になる。また、ＵＥ １０は、ｅＮｏｄｅＢにチャネル品質情報（ｃｈａｎｎｅｌ ｑｕａｌｉｔｙ ｉｎｆｏｒｍａｔｉｏｎ）とフィードバック情報を報告する。

ＲＲＣ＿ＣＯＮＮＥＣＴＥＤ状態で、Ｅ−ＵＴＲＡＮは、ＵＥ １０の属するセルを認知する。したがって、ネットワークは、ＵＥ １０にまたはＵＥ １０からデータを伝送及び／または受信することができ、ネットワークは、ＵＥのモビリティ（ハンドオーバー）を制御でき、ネットワークは隣接セルのためのセル測定を行うことができる。

ＲＲＣ＿ＩＤＬＥ状態では、ＵＥ １０がページングＤＲＸ（Ｄｉｓｃｏｎｔｉｎｕｏｕｓ Ｒｅｃｅｐｔｉｏｎ）周期を特定する。特に、ＵＥ １０が、全てのＵＥ特定ページングＤＲＸサイクル周期ごとに特定のページング機会でページング信号を監視する。

図３には、ＵＥ側の第２層におけるアップリンクユーザトラフィックのバッファリングを図式化する。第３層から受信したＵ−プレーントラフィックは、一般的に上位アプリケーション層からのペイロード５１を持つＩＰパケット５０で構成され、これはＰＤＣＰ層のロジック５５によって処理される。これらのパケット５０は、上位層から伝送され、ＰＤＣＰバッファ５６に保存されるＰＤＣＰ ＳＤＵ（ｓｅｒｖｉｃｅ ｄａｔａ ｕｎｉｔ）を形成する。各パケット５０は、ＩＰヘッダと、場合により、例えば、ＶｏＩＰ（ｖｏｉｃｅ ｏｖｅｒ ＩＰ）アプリケーションの場合においてＲＴＰ（ｒｅａｌ ｔｉｍｅ ｐｒｏｔｏｃｏｌ）のような上位層プロトコルからの他のヘッダフィールドとを含むヘッダ５２を有する。

ＰＤＣＰ層５５から生成されたＰＤＣＰ ＰＤＵ（ｐｒｏｔｏｃｏｌ ｄａｔａ ｕｎｉｔ）６０，７０は、ＲＬＣ層８０に伝送され、ＲＬＣバッファ８１に保存される。各ＰＤＣＰ ＰＤＵ６０，７０は、ＰＤＣＰシーケンス番号とＰＤＵタイプに対する指示子とを含む短いヘッダ６１，７１を有する。

（短いヘッダ６１で指示される）一部のＰＤＣＰ ＰＤＵ ６０は、一般的にＰＤＵ当たり一つのＩＰパケットの形態でユーザトラフィックを運搬する。このようなＩＰパケットのヘッダ５２は、ＰＤＣＰ層５５でＲｏＨＣ（ｒｏｂｕｓｔ ｈｅａｄｅｒ ｃｏｍｐｒｅｓｓｉｏｎ）と呼ばれるヘッダ圧縮アルゴリズムによって（図３で示す圧縮されたヘッダ６２に）圧縮される。また、ＰＤＣＰ層は、ユーザデータを暗号化と完全性保護（ＭＡＣ−Ｉ）のためのメッセージ認証を付加する。ヘッダ圧縮は、ＩＰヘッダの多くのフィールドが動的に変更されないという点に基づく。例えば、ＶｏＩＰ呼中に、ターゲットＩＰアドレスとソースＩＰアドレスは一般的に変更されずに維持される。したがって、それが変更される場合にのみこの種の情報を含むことが必要である。ＲｏＨＣ手法は、よく知られたように、プロトコルヘッダ内に存在する様々なリダンダンシ（ｒｅｄｕｎｄａｎｃｙ）を活用する。例えば、ＩＥＴＦ（Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ）で２００７年７月に出版した“Ｔｈｅ Ｒｏｂｕｓｔ Ｈｅａｄｅｒ Ｃｏｍｐｒｅｓｓｉｏｎ（ＲＯＨＣ） Ｆｒａｍｅｗｏｒｋ”のＲＦＣ（ｒｅｑｕｅｓｔ ｆｏｒ ｃｏｍｍｅｎｔｓ）４９９５を参照する。

（短いヘッダ７１によって指示される）他のアップリンクＰＤＣＰ ＰＤＵ ７０は、次のような制御情報を伝送するＰＤＣＰ制御ＰＤＵである。
ハンドオーバー以後のダウンリンクＰＤＣＰ ＳＤＵの欠落または認知に関するＰＤＣＰ状態報告。このような状態報告は、新しいセルをサービングするｅＮｏｄｅＢ内のピア（ｐｅｅｒ）ＰＤＣＰ層で用いられて、ＰＤＣＰ ＳＤＵを再伝送するか否かを決定する。
圧縮過程のロバスト性を保障するためにヘッダ圧縮アルゴリズムによって生成された散在ＲｏＨＣフィードバックのような、ヘッダ圧縮制御情報。ヘッダフィールドにおける変更を指示するパケットが消失される場合に備えて、受信機は送信機にこのようなＲｏＨＣフィードバック情報を送信でき、例えば、アップデートのような重要な情報は反復される。したがって、送信機は、ＲｏＨＣフィードバック情報を受信したことに対応するために、ヘッダをできるだけ遅く圧縮する。図３で、矢印８２は、ダウンリンクチャネルでＵＥ １０により受信され、アップリンクユーザデータの伝送が実行されるＰＤＣＰ層５５のＲｏＨＣアルゴリズムに提供されるＲｏＨＣフィードバックを意味する。

透明（Ｔｒａｎｓｐａｒｅｎｔ）、応答（Ａｃｋｎｏｗｌｅｄｇｅｄ）または無応答（Ｕｎａｃｋｎｏｗｌｅｄｇｅｄ）モードでデータ伝送制御のために、そして関連したＡＲＱ過程を行うために、ＲＬＣ層８０はＰＤＣＰ ＰＤＵを処理する。それぞれの論理チャネルに対するＲＬＣ ＰＤＵは、ＭＡＣ層８５を通過してＭＡＣヘッダ情報が付加され、スケジューリングまたはＨＡＲＱ（ｈｙｂｒｉｄ ＡＲＱ）のような他の媒体接近機能を行う。アップリンク伝送チャネルに具現されたＭＡＣシグナリング手順の一つは、バッファ状態報告手順である。ＵＥ １０でバッファリングされるアップリンクデータの量に関する情報がサービングｅＮｏｄｅＢ ２０に提供される。このような情報は、他の論理チャネルに割り当てられる優先権（ｐｒｉｏｒｉｔｙ）のような他の情報と一緒に、与えられた時間でどのＵＥまたは論理チャネルに無線リソースが割り当てられるかを決定するためにｅＮｏｄｅＢ ２０のＭＡＣ層によって実行されるアップリンクスケジューリングアルゴリズムに有用である。バッファ状態情報は、伝送時に利用可能なデータの量を指示する。ＵＭＴＳでは、図３のブロック８４に示すように、スケジューリング情報は、ＲＬＣバッファ８１に保存されたデータを指示し、ＭＡＣ層はＲＬＣ層に利用可能なデータの量を報告するように要請し、データの量は、一つのアップリンクＭＡＣ ＰＤＵに含まれたＢＳＲ（ｂｕｆｆｅｒ ｓｔａｔｕｓ ｒｅｐｏｒｔ）を用いてネットワークに報告されることができる。

しかしながら、ＬＴＥでは、データの量を減少させるために、ＲｏＨＣアルゴリズムによって特定コーディングをＩＰヘッダに適用するヘッダ圧縮が利用される。したがって、ＰＤＣＰエンティティ間で伝送されるデータの量は、一般的にＰＤＣＰエンティティからＲＬＣエンティティに伝送されるデータの量よりも多い。ＰＤＣＰ制御ＰＤＵを時々挿入しなければならないということは、誤りの他の根源となる。

ＲｏＨＣが利用される場合、送信機が、伝送される残存データの正確な大きさを指示することができず、これは、伝送前に圧縮される必要があるためである。特に、受信機からのフィードバック情報は、データ大きさに影響を及ぼす。送信機では、圧縮が完了する前まで圧縮以後の正確なデータ大きさを認知するということが不可能であり、したがって、バッファの正確な大きさを指示することが不可能である。

本発明の目的は、ヘッダ圧縮が用いられる場合に、無線装置からネットワークに報告されるバッファリングされたデータ量の信頼性を改善することにある。

上述した技術的問題を解決するために、本発明では様々な実施例を提供する。無線機器から無線通信システムの基地局にバッファ状態報告を送信する方法が、以下に提案される。この方法は、前記無線機器の第１バッファ（５６）に、圧縮されていないデータ（５０）を保存する段階と；前記無線機器から前記基地局に、前記無線機器から伝送される圧縮されていないデータの量に関する情報を含むバッファ状態報告を送信する段階と；を含み、前記情報は、前記第１バッファに含まれたデータの量に依存する。
実施例として、前記方法は、前記基地局（２０）から受信した情報に基づいて、圧縮されたデータの大きさを決定する段階をさらに含む。また、前記方法は、前記基地局（２０）から受信したフィードバック情報に基づいて前記圧縮されていないデータの圧縮を行う段階と；第２バッファ（８１）に前記圧縮されたデータを保存する段階と；前記無線機器から前記基地局に、前記保存された圧縮データを送信する段階と；をさらに含む。

他の実施例として、前記方法は、前記無線機器の第１バッファに、それぞれのユーザパケット別にそれぞれのヘッダを含む、ユーザパケットを保存する段階と、前記第１バッファから読み取られた前記ユーザパケットを、前記無線機器の第２バッファに記録されるデータユニットに変換する段階と、前記無線機器から前記基地局に、前記第２バッファから読み取られたデータユニットを送信する段階と、前記無線機器から前記基地局に、前記無線機器から伝送されるデータの量に関する情報を含むバッファ状態報告を送信する段階と、を含み、前記変換は、前記基地局から受信したフィードバック情報によって前記ユーザパケットのヘッダに適用されるヘッダ圧縮を含み、前記情報は、前記第１バッファに含まれたデータ量に依存する。

前記ヘッダ圧縮は、ネットワークからフィードバックされた情報を考慮するので、できるだけ遅く適用することが好ましい。これは、第２バッファ（例えば、ＲＬＣバッファ）で一定時間に保存されるデータの量が、時々、第１バッファ（例えば、ＰＤＣＰバッファ）で同一時間に保存されるデータの量と比較してより小さいということを意味する。第１バッファの内容（第１バッファの内容のみ、または、好ましくは、第２バッファの内容と結合された）に基づくバッファ状態報告は、ヘッダ圧縮フィードバック情報の良好な反応を維持しながら、相当正確な推定値を獲得することを可能にする。

基地局は、実時間で物理チャネルスケジューリングを決定するために、一つ以上の無線機器からのバッファ状態報告を考慮することができ、これは、ＭＡＣ（ｍｅｄｉｕｍ ａｃｃｅｓｓ ｃｏｎｔｒｏｌ）手順である。これは、ヘッダがユーザパケットの重要な部分を表す場合に特に有用である。

また、他の手順と特に制御プレーンＲＲＣ手順の構造では、伝送時に利用可能なデータに関する情報が、ＵＥからネットワークに送信されることができる。特に、ＴＶＭ（ｔｒａｆｆｉｃ ｖｏｌｕｍｅ ｍｅａｓｕｒｅｍｅｎｔ）は、ＵＥ測定報告を制御するｅＮｏｄｅＢによって要請されることができる。例えば、ＵＥの状態変化を起こし、ＵＥデータの伝送のための適切なタイプのチャネルを提供するのに、このような測定が利用されることができる。

これにより、前記無線機器の前記第２バッファに記録される前記データユニットは、前記ユーザパケットの変換が具現されるプロトコル層で生成された情報を持つ制御データユニットをさらに含む。このような実施例では、前記バッファ状態報告は、前記第２バッファに保存されたデータの量を指示する。または、前記バッファ状態報告は、（制御データユニットを除く）前記第２バッファに保存された圧縮データの量を指示することもできる。

本発明の実施例では、前記バッファ状態報告は、前記第１バッファに保存された非圧縮データの量を指示する。前記ヘッダ圧縮に適用されて獲得される圧縮因子の推定値を持つ付加的バッファ状態報告は、前記無線機器から前記基地局に送信される。前記付加的バッファ状態報告は、前記第１バッファに保存された非圧縮データの量を指示する前記バッファ状態報告よりも低い周波数で伝送される。

また、前記バッファ状態報告は、前記第１バッファに保存された非圧縮データから得られる圧縮データの量の推定値を指示する。前記圧縮因子は、ヘッダ圧縮アルゴリズムの動作から地域的に推定されることができる。または、圧縮因子の値は、基地局によって提供されても良い。

また、前記バッファ状態報告は、ＲＬＣ／ＭＡＣヘッダのように、前記第２バッファから読み取られた前記データユニットの送信のために付加される追加ヘッダの大きさに依存するデータの量を指示する。

本発明の他の観点は、複数の基地局を持つネットワークと通信する無線機器に関するものである。前記無線機器は、それぞれのユーザパケット別にそれぞれのヘッダを含む、ユーザパケットを保存する第１バッファ、前記第１バッファから読み取られた前記ユーザパケットを、前記無線機器の第２バッファに記録されるデータユニットに変換する変換器、及び前記基地局に、前記第２バッファから読み取られるデータユニットと、前記無線機器から伝送されるデータの量に関する情報を持つバッファ状態報告とを伝送するために配置された送信機、を含み、前記変換器は、前記基地局から受信したフィードバック情報を用いて前記ユーザパケットのヘッダにヘッダ圧縮を適用し、前記情報は、前記第１バッファに含まれたデータ量に依存する。
（項目１）
無線機器（１０）から無線通信システムの基地局（２）へのデータ送信方法であって、
前記無線機器の第１バッファ（５６）に、それぞれのユーザパケット別にそれぞれのヘッダを含む、ユーザパケット（５０）を保存し、
前記第１バッファから読み取られた前記ユーザパケットを、前記無線機器の第２バッファ（８１）に記録されるデータユニット（６０）に変換し、
前記無線機器から前記基地局に、前記第２バッファから読み取られたデータユニットを送信し、
前記無線機器から前記基地局に、前記無線機器から伝送されるデータの量に関する情報を含むバッファ状態報告を送信すること、
を含み、
前記変換は、前記基地局から受信したフィードバック情報によって前記ユーザパケットのヘッダに適用されるヘッダ圧縮を含み、
前記情報は、前記第１バッファに含まれたデータの量に依存する、データ送信方法。
（項目２）
前記無線機器の前記第２バッファ（８１）に記録される前記データユニットは、
前記ユーザパケット（５０）の変換が具現されるプロトコル層（５５）で生成された情報を有する制御データユニット（７０）をさらに含む、項目１に記載のデータ送信方法。
（項目３）
前記バッファ状態報告は、前記第２バッファ（８１）に保存されたデータの量を指示する、項目２に記載のデータ送信方法。
（項目４）
前記バッファ状態報告は、前記第１バッファに保存された非圧縮データの量を指示する、項目１に記載のデータ送信方法。
（項目５）
前記無線機器から前記基地局に、前記ヘッダ圧縮に適用されて獲得される圧縮因子の推定値を有する付加的バッファ状態報告を送信することをさらに含み、
前記付加的バッファ状態報告は、前記第１バッファ（５６）に保存された非圧縮データの量を指示する前記バッファ状態報告よりも低い周波数で伝送される、項目１に記載のデータ送信方法。
（項目６）
前記バッファ状態報告は、前記第１バッファ（５６）に保存された非圧縮データから得られる圧縮データの量の推定値を指示する、項目１に記載のデータ送信方法。
（項目７）
前記バッファ状態報告は、前記第２バッファ（８１）に保存される圧縮データの量をさらに指示する、項目２に記載のデータ送信方法。
（項目８）
前記無線機器から伝送されるデータの量に関する情報は、前記基地局（２０）によって提供される圧縮因子の値にさらに依存する、項目１に記載のデータ送信方法。
（項目９）
前記バッファ状態報告は、前記第２バッファから読み取られた前記データユニットの送信のために付加される追加ヘッダの大きさに依存するデータの量を指示する、項目１に記載のデータ送信方法。
（項目１０）
前記バッファ状態報告は、ＭＡＣ（ｍｅｄｉｕｍ ａｃｃｅｓｓ ｃｏｎｔｒｏｌ）手順の一部として伝送される、項目１に記載のデータ送信方法。
（項目１１）
前記バッファ状態報告は、ＲＲＣ（ｒａｄｉｏ ｒｅｓｏｕｒｃｅ ｃｏｎｔｒｏｌ）手順の一部として伝送される、項目１に記載のデータ送信方法。
（項目１２）
前記ユーザパケット（５０）の前記データユニット（６０）への変換は、ＰＤＣＰ（ｐａｃｋｅｔ ｄａｔａ ｃｏｎｖｅｒｇｅｎｃｅ ｐｒｏｔｏｃｏｌ）手順の一部である、項目１に記載のデータ送信方法。
（項目１３）
複数の基地局（２０）を有するネットワークと通信する無線機器（１０）であって、
それぞれのユーザパケット別にそれぞれのヘッダを含む、ユーザパケット（５０）を保存する第１バッファ（５６）と、
前記第１バッファから読み取られた前記ユーザパケットを、前記無線機器の第２バッファ（８１）に記録されるデータユニット（６０）に変換する変換器（５５）と、
前記基地局に、前記第２バッファから読み取られるデータユニットと、前記無線機器から伝送されるデータの量に関する情報を有するバッファ状態報告とを伝送するために配置された送信機と、
を含み
前記変換器は、前記基地局から受信したフィードバック情報を用いて前記ユーザパケットのヘッダにヘッダ圧縮を適用し、
前記情報は、前記第１バッファに保存されたデータに量に依存する、無線機器。
（項目１４）
前記バッファ状態報告は、前記第１バッファに保存された非圧縮データの量を指示する、項目１３に記載の無線機器。
（項目１５）
前記無線機器から伝送されるデータの量に関する情報は、前記変換器によって適用される圧縮因子の推定値に依存する、項目１３または１４に記載の無線機器。
例えば、本発明はさらに以下の項目も提供する。
（項目１Ａ）
無線機器（１０）から無線通信システムの基地局（２）にバッファ状態報告を送信する方法であって、
上記無線機器の第１バッファ（５６）に、圧縮されていないデータ（５０）を保存し、
上記無線機器から上記基地局に、上記無線機器から伝送される圧縮されていないデータの量に関する情報を含むバッファ状態報告を送信すること、
を含み、
上記情報は、上記第１バッファに含まれたデータの量に依存する、バッファ状態報告送信方法。
（項目２Ａ）
上記基地局（２０）から受信した情報に基づいて、圧縮されたデータの大きさを決定することをさらに含む、項目１Ａに記載のバッファ状態報告送信方法。
（項目３Ａ）
上記基地局（２０）から受信したフィードバック情報に基づいて上記圧縮されていないデータの圧縮を行い、
第２バッファ（８１）に上記圧縮されたデータを保存し、
上記無線機器から上記基地局に、上記保存された圧縮データを送信すること、
をさらに含む、項目１Ａまたは２Ａに記載のバッファ状態報告送信方法。
（項目４Ａ）
上記圧縮は、上記圧縮されていないデータを形成するパケットのヘッダを圧縮する、項目３Ａに記載のバッファ状態報告送信方法。
（項目５Ａ）
上記バッファ状態報告は、上記圧縮データの量をさらに指示する、項目１Ａ〜４Ａのいずれか１項に記載のバッファ状態報告送信方法。
（項目６Ａ）
複数の基地局（２０）を有するネットワークと通信する無線機器（１０）であって、
それぞれのユーザパケット別にそれぞれのヘッダを含む、ユーザパケット（５０）を保存する第１バッファ（５６）と、
上記第１バッファから読み取られた上記ユーザパケットを、上記無線機器の第２バッファ（８１）に記録されるデータユニット（６０）に変換する変換器（５５）と、
上記基地局に、上記第２バッファから読み取られるデータユニットと、上記無線機器から伝送されるデータの量に関する情報を有するバッファ状態報告を伝送するために配置された送信器と、
を含み、
上記変換器は、上記基地局から受信したフィードバック情報を用いて上記ユーザパケットのヘッダにヘッダ圧縮を適用し、
上記情報は、上記第１バッファに保存されたデータの量に依存する、無線機器。
（項目７Ａ）
上記バッファ状態報告は、上記第１バッファに保存された非圧縮データの量を指示する、項目６Ａに記載の無線機器。
（項目８Ａ）
上記無線機器から伝送されるデータの量に関する情報は、上記変換器によって適用される圧縮因子の推定値に基づく、項目６Ａまたは７Ａに記載の無線機器。
（項目９Ａ）
上記送信器は、
上記ヘッダ圧縮が適用されて獲得される圧縮因子の推定値を有する付加的バッファ状態報告を上記基地局（２０）にさらに送信し、
上記付加的バッファ状態報告は、上記第１バッファ（５６）に保存された非圧縮データの量を指示する上記バッファ状態報告よりも低い周波数で伝送される、項目７Ａに記載の無線機器。
（項目１０Ａ）
上記第２バッファ（８１）に記録されるデータユニット（６０）は、
上記ユーザパケット（５０）の変換を具現するプロトコル階層（５５）で生成された情報を含む制御データユニット（７０）をさらに含む、項目６Ａ〜９Ａのいずれか１項に記載の無線機器。
（項目１１Ａ）
上記バッファ状態報告は、上記第２バッファ（８１）に保存されたデータの量をさらに指示する、項目１０Ａに記載の無線機器。
（項目１２Ａ）
上記バッファ状態報告は、上記第１バッファ（５６）に保存された非圧縮データから導き出される圧縮データの量の推定値を指示する、項目６Ａ〜１１Ａのいずれか１項に記載の無線機器。
（項目１３Ａ）
上記バッファ状態報告は、上記第２バッファ（８１）に保存された圧縮データの量をさらに指示する、項目６Ａ〜１２Ａのいずれか１項に記載の無線機器。
（項目１４Ａ）
上記バッファ状態報告は、上記第２バッファから読み取られた上記データユニットの送信のためにさらに付加されるヘッダの大きさに基づくデータの量を指示する、項目６Ａ〜１３Ａのいずれか１項に記載の無線機器。
（項目１５Ａ）
上記バッファ状態報告は、ＲＲＣ（ｒａｄｉｏ ｒｅｓｏｕｒｃｅ ｃｏｎｔｒｏｌ）手順の一部として伝送される、項目６Ａ〜１４Ａのいずれか１項に記載の無線機器。
（項目１６Ａ）
上記ユーザパケット（５０）の上記データユニット（６０）への変換は、ＰＤＣＰ（ｐａｃｋｅｔ ｄａｔａ ｃｏｎｖｅｒｇｅｎｃｅ ｐｒｏｔｏｃｏｌ）手順の一部である、項目６Ａ〜１５Ａのいずれか１項に記載の無線機器。

本発明は、次のような長所を有する。

（ＲＲＣまたはＭＡＣレベルで）様々な測定報告において、アップリンクでは非圧縮データに関する情報だけで充分であり、これは、ｅＮｏｄｅＢがＲｏＨＣ復元器を用いて圧縮率に関する利得情報を獲得できるためである。

圧縮されたデータ大きさに関する情報は、選択的なものであり、さらに正確性を改善する。これは、ＭＡＣリソース要請が、利用可能なデータの総量にできるだけ多く対応する特定状況、例えば、全てのＰＤＣＰ ＳＤＵが直ちに圧縮される音声対話データまたはアップリンクＴＣＰ ＡＣＫメッセージで特に有用である。

本発明の他の目的、特徴及び長所は、添付の図面を参照して以下に詳細に記述されるが、本発明が下記の例示的な実施例に限定されるわけではない。
Ｅ−ＵＭＴＳ（またはＬＴＥ）システムのネットワーク構造を示すブロック図である。 ＬＴＥシステムの一般的なネットワークエンティティの論理構造を示すブロック図である。 ユーザプレーン（Ｕ−ｐｌａｎｅ）プロトコルスタックの一般的なネットワークエンティティの論理構造を示すブロック図である。 制御プレーン（Ｃ−ｐｌａｎｅ）プロトコルスタックの一般的なネットワークエンティティの論理構造を示すブロック図である。 図２（ｂ）に示すユーザプレーンプロトコルスタックと関連したバッファ配列を示す図である。 本発明の実施例において、図２（ｂ）に示すユーザプレーンプロトコルスタックと関連したバッファ配列を示す図である。

以下では、無線機器からセルラーネットワークの基地局に、パケット伝送に関するバッファ状態情報を提供する方法が特にＬＴＥシステムで記述されるが、必ずしもＬＴＥシステムに限定されるわけでない。

図３を参照して上述した事項と比較すると、図４は、バッファ状態を報告する別の方法を示す。図４の実施例で、ＢＳＲを生成するためにバッファ状態報告ブロック８４によって利用される情報は、ＰＤＣＰバッファ５６の内容に関する情報を含む。

ＰＤＣＰ ＳＤＵ（ＩＰパケット）５０がＰＤＣＰ ＰＤＵ ６０に変換されるために、ＰＤＣＰバッファ５６から読み取られる度に、ＰＤＣＰ層５５は、バッファ５６からそれを取り込む。したがって、ＰＤＣＰバッファ５６は、ＰＤＣＰ層によってそして特にＲｏＨＣアルゴリズムによってまだ処理されていないユーザパケットのみを含む。

ＰＤＣＰ ＳＤＵ ５０がＰＤＣＰ層５５によって処理されない間は、それに対応するＰＤＣＰ ＰＤＵ ６０の正確な大きさを認知することが不可能であり、これは、当該大きさが、ＰＤＣＰ層５５がｅＮｏｄｅＢにおけるＰＤＣＰピア（ｐｅｅｒ）エンティティから受信するＲｏＨＣフィードバックに依存するからである。また、ＰＤＣＰ制御ＰＤＵ ７０（ハンドオーバーに関連したａｃｋｎｏｗｌｅｄｇｅｍｅｎｔに対する状態報告及び／または逆方向のＲｏＨＣフィードバック）として付加されるデータの量を予測することが難しい。しかし、ＰＤＣＰ層５５における遅いヘッダ圧縮の方針により、ＲＬＣバッファ８１の満たされている与えられたレベルは、ＵＥ １０で伝送のために現在待機中にある実際ユーザデータの量に関する情報に対して非常に少ない情報のみを提供することができる（ＰＤＣＰバッファ５６はほとんど空いている、または、ＲＬＣバッファ８１よりも多いデータを含んでいることができる）。したがって、ＰＤＣＰバッファ５６に待機中であるパケットデータの量は、信頼性あるＵＥバッファ状態報告のための重要なパラメータである。

本発明の第１の実施例では、ＢＳＲは、ＰＤＣＰバッファ５６に保存された伝送しようとする非圧縮データの大きさ（一般的に、オクテット（ｏｃｔｅｔ）の個数）を指示する。これは、バッファ状態を報告する簡単な方法である。どのような他の情報が伝送されるかによって、ＢＳＲは、ＲＬＣ層に伝達された圧縮ＰＤＣＰ ＳＤＵを含むＰＤＣＰ ＰＤＵ、すなわち、ユーザデータトラフィックのためのＰＤＵを指示する短いヘッダ６１と共に、ＲＬＣバッファ８１に保存されたＰＤＵ ６０の大きさをさらに含む。アプリケーションによって、ＲＬＣバッファ８１に保存されたＰＤＣＰ制御ＰＤＵ ７０の大きさが含まれることもできる。

本発明の第２の実施例では、ＢＳＲは、伝送されるデータの圧縮された大きさの推定値を提供する。例えば、この情報は、ＰＤＣＰバッファ５６の内容と、該当する無線ベアラーのデータに対して既になされた圧縮因子とに基づいて計算される。場合によっては、圧縮因子は、圧縮アルゴリズムによって提供される数字であっても良い。

または、圧縮因子の推定値は、ｅＮｏｄｅＢによって提供される。ｅＮｏｄｅＢは、ｅＮｏｄｅＢ ＰＤＣＰエンティティで実行されるＲｏＨＣ復元アルゴリズムによって以前ＰＤＵで観察された圧縮率に基づいて当該因子を測定する。

圧縮因子が地域的にＵＥ １０で推定される場合、興味深い可能性は、例えば、毎１００ｍｓのような相対的に高い周波数で、ＰＤＣＰバッファ５６に含まれた非圧縮データの量を報告するということと、例えば、毎１秒または１０秒のような低い周波数で、観察された圧縮因子を報告するということである。すると、ｅＮｏｄｅＢは、バッファ大きさの最近受信値と圧縮因子の最近受信値との積によって、ＵＥから受信してバッファリングされるデータの量を求めることができる。

圧縮率は、圧縮器とトラフィックタイプに依存するので、圧縮率は、一定時間以後にのみ圧縮器または復元器によって決定されることができる。圧縮器または復元器は、トラフィックとチャネル状態に関する充分な情報をまず獲得しなければならない。

他の可能性は、既に圧縮されたデータ（ＰＤＣＰ ＰＤＵ ６０）の大きさに加えて、まだ圧縮が行われていないＰＤＣＰ ＳＤＵの圧縮される大きさに関する推定値のような、まだ圧縮されていないデータに関する情報のみを報告するという点である。このような推定値は、ＵＥベースである、または、ｅＮｏｄｅＢ ２０から与えられた圧縮率値から得られるものでありうる。ＶｏＩＰの場合を挙げると、これにより、すべての利用可能なＰＤＣＰ ＳＤＵが既に圧縮されてＲＬＣバッファ８１にある場合、正確なデータ大きさが、場合によりＲＬＣヘッダとＭＡＣヘッダを含めて、報告されることを許容する。

一般的に、ＲＬＣ／ＭＡＣヘッダによるオーバーヘッドの大きさの推定値は、ＢＳＲに含まれることができ、これは、報告の正確度を増加させる。

代表的な実施例として、ＵＥは、ｅＮｏｄｅＢに非圧縮データ、すなわち、ＰＤＣＰバッファ５６の内容の大きさと、圧縮データ、すなわち、ＲＬＣバッファ８１の内容の大きさまたはユーザデータＰＤＵ ６０の大きさのみを報告する。ｅＮｏｄｅＢにおけるＭＡＣスケジューリング手法は、ｅＮｏｄｅＢから与えられた圧縮率とまだ圧縮されていない各無線ベアラーのための非圧縮ＰＤＣＰ ＳＤＵの大きさとを乗じ、伝送待機中であるＰＤＣＰ ＰＤＵの大きさを、場合によりＲＬＣ／ＭＡＣヘッダによるオーバーヘッドを含めて、加えるものである。

図４に示す実施例では、バッファ状態報告は、ＭＡＣ（ｍｅｄｉｕｍ ａｃｃｅｓｓ ｃｏｎｔｒｏｌ）機能によって行われる。バッファ状態報告がＲＲＣ（ｒａｄｉｏ ｒｅｓｏｕｒｃｅ ｃｏｎｔｒｏｌ）手順の一部として伝送されることもできるということがわかる。

大部分の測定報告においては（ＲＲＣレベルまたはＭＡＣレベル）、アップリンクでは非圧縮データに関する情報で充分であり、これは、ｅＮｏｄｅＢがＲｏＨＣ復元器を用いて圧縮率に関する情報を獲得するためである。

圧縮データの大きさに関する情報は、選択的なものであり、さらに正確度を改善する。これは、ＭＡＣリソース要請が、利用可能なデータの総量にできるだけ多く対応する特定状況、例えば、全てのＰＤＣＰ ＳＤＵが直ちに圧縮される音声対話データまたはアップリンクＴＣＰ ＡＣＫメッセージで特に有用である。

以上、本発明の実施例を、３ＧＰＰ ＬＴＥシステムを取り上げて説明してきた。無線通信分野における当業者には、本発明及び添付の請求範囲を逸脱しない範囲内で様々な改変ができるということが理解する。したがって、当業者は、本発明が３ＧＰＰ ＬＴＥシステムの他に別の通信システムにも適用可能であることがわかる。

本発明は、無線広帯域アクセスシステムのうちのいずれかにおいて利用可能である。

Claims (22)

1. 無線機器から無線通信システムの基地局にバッファ状態報告を送信する方法であって、前記方法は、
   前記無線機器の第１バッファに、圧縮されていないデータを保存することと、
   前記無線機器の第２バッファに、圧縮されたデータを保存することと、
   ＲＯＨＣ（ｒｏｂｕｓｔ ｈｅａｄｅｒ ｃｏｍｐｒｅｓｓｉｏｎ）手法を採用するＰＤＣＰ（ｐａｃｋｅｔ ｄａｔａ ｃｏｎｖｅｒｇｅｎｃｅ ｐｒｏｔｏｃｏｌ）層により、前記圧縮されていないデータを圧縮することと、
   前記無線機器から前記基地局にバッファ状態報告を送信することであって、前記バッファ状態報告は、前記無線機器から送信される前記第１バッファに保存された前記圧縮されていないデータの量および前記無線機器から送信される前記第２バッファに保存された前記圧縮されたデータの量を示す情報を含み、前記圧縮されていないデータは、少なくとも１つのＰＤＣＰ ＳＤＵ（ｓｅｒｖｉｃｅ ｄａｔａ ｕｎｉｔ）を含む、ことと
   を含む、方法。
2. 前記第２バッファは、さらに、１つ以上のＰＤＣＰコントロールＰＤＵを含む、請求項１に記載の方法。
3. 前記情報は、前記圧縮されていないデータの量と前記圧縮されたデータの量の両方の総量を示すように、送信されるデータの総量を示す、請求項１に記載の方法。
4. 前記圧縮されていないデータの圧縮は、前記基地局から受信されたフィードバック情報に依存して実行される、請求項１に記載の方法。
5. さらに、ＭＡＣ層を介して前記保存された圧縮されたデータを前記基地局に送信することを含む、請求項１に記載の方法。
6. 前記圧縮されていないデータの圧縮は、前記少なくとも１つのＰＤＣＰ ＳＤＵを形成するパケットのヘッダを圧縮することを含む、請求項１に記載の方法。
7. さらに、ＭＡＣ層により前記基地局に付加的バッファ状態報告を送信することを含み、
   前記付加的バッファ状態報告は、前記ＲＯＨＣ手法を採用することにより達成される圧縮因子の推定値を含み、前記付加的バッファ状態報告の送信は、前記情報を含む前記バッファ状態報告の送信よりも低い周波数で実行される、請求項１に記載の方法。
8. 前記バッファ状態報告は、さらに、前記第２バッファから読み取られたデータの送信のために付加される付加的ヘッダの大きさに依存するデータの量を示す、請求項１に記載の方法。
9. 前記第１バッファは、ＰＤＣＰバッファである、請求項１に記載の方法。
10. 前記第２バッファは、ＲＬＣ（ｒａｄｉｏ ｌｉｎｋ ｃｏｎｔｒｏｌ）バッファである、請求項１に記載の方法。
11. 基地局と通信する無線機器であって、前記無線機器は、
    圧縮されていないデータを保存するように構成された第１バッファと、
    圧縮されたデータを保存するように構成された第２バッファと、
    ＲＯＨＣ（ｒｏｂｕｓｔ ｈｅａｄｅｒ ｃｏｍｐｒｅｓｓｉｏｎ）手法を採用して前記圧縮されていないデータを圧縮するＰＤＣＰ（ｐａｃｋｅｔ ｄａｔａ ｃｏｎｖｅｒｇｅｎｃｅ ｐｒｏｔｏｃｏｌ）層と、
    前記基地局にバッファ状態報告を送信するように構成されたＭＡＣ（ｍｅｄｉｕｍ ａｃｃｅｓｓ ｃｏｎｔｒｏｌ）層であって、前記バッファ状態報告は、前記無線機器から送信される前記第１バッファに保存された前記圧縮されていないデータの量および前記無線機器から送信される前記第２バッファに保存された前記圧縮されたデータの量を示す情報を含み、前記圧縮されていないデータは、少なくとも１つのＰＤＣＰ ＳＤＵ（ｓｅｒｖｉｃｅ ｄａｔａ ｕｎｉｔ）を含む、ＭＡＣ層と
    を含む、無線機器。
12. 前記第２バッファは、さらに、１つ以上のＰＤＣＰコントロールＰＤＵを含む、請求項１１に記載の無線機器。
13. 前記情報は、前記圧縮されていないデータの量と前記圧縮されたデータの量の両方の総量を示すように、送信されるデータの総量を示す、請求項１１に記載の無線機器。
14. 前記圧縮されていないデータの圧縮は、前記基地局から受信されたフィードバック情報に依存して実行される、請求項１１に記載の無線機器。
15. 前記ＭＡＣ層は、さらに、前記保存された圧縮されたデータを前記無線機器から前記基地局に送信するように構成される、請求項１１に記載の無線機器。
16. 前記圧縮されていないデータの圧縮は、前記少なくとも１つのＰＤＣＰ ＳＤＵを形成するパケットのヘッダを圧縮することを含む、請求項１１に記載の無線機器。
17. 前記情報は、前記ＰＤＣＰ層により適用される圧縮因子の推定値に依存する、請求項１１に記載の無線機器。
18. 前記ＭＡＣ層は、さらに、前記基地局に付加的バッファ状態報告を送信するように構成され、
    前記付加的バッファ状態報告は、前記ＲＯＨＣ手法を採用することにより達成される圧縮因子の推定値を含み、前記付加的バッファ状態報告は、前記情報を含む前記バッファ状態報告の送信よりも低い周波数で送信される、請求項１１に記載の無線機器。
19. 前記バッファ状態報告は、さらに、前記第２バッファから読み取られたデータの送信のために付加される付加的ヘッダの大きさに依存するデータの量を示す、請求項１１に記載の無線機器。
20. 前記バッファ状態報告は、ＭＡＣ（ｍｅｄｉｕｍ ａｃｃｅｓｓ ｃｏｎｔｒｏｌ）手順またはＲＲＣ（ｒａｄｉｏ ｒｅｓｏｕｒｃｅ ｃｏｎｔｒｏｌ）手順の一部として送信される、請求項１１に記載の無線機器。
21. 前記第１バッファは、ＰＤＣＰバッファである、請求項１１に記載の無線機器。
22. 前記第２バッファは、ＲＬＣ（ｒａｄｉｏ ｌｉｎｋ ｃｏｎｔｒｏｌ）バッファである、請求項１１に記載の無線機器。