JP4988865B2 - 無線通信システムのリソースリクエスト - Google Patents

Description

本出願は、題号「Ａ ＭＥＴＨＯＤ ＡＮＤ ＡＰＰＡＲＡＴＵＳ ＦＯＲ ＵＳＩＮＧ Ａ ＲＥＶＥＲＳＥ ＣＯＮＴＲＯＬ ＣＨＡＮＮＥＬ ＭＡＣ ＰＲＯＴＯＣＯＬ」である２００７年１月３０日に出願された米国仮出願番号６０／８８７，３４２、題号「ＲＥＳＯＵＲＣＥ ＲＥＱＵＥＳＴＳ ＦＯＲ ＷＩＲＥＬＥＳＳ ＣＯＭＭＵＮＩＣＡＴＩＯＮ ＳＹＳＴＥＭＳ」である２００７年２月５日に出願された米国仮出願番号６０／８８８，１９２の優先権を主張し、これらは譲受人に譲り渡され、ここで参照されて含まれるものである。

本開示は、一般に無線通信に関し、より具体的には、無線通信システムにおける無線リソースをリクエストする技術に関する。

無線通信システムは音声、ビデオ、パケットデータ、メッセージング、ブロードキャストなどのような様々な通信内容を提供するために広く用いられる。これらの無線システムは、利用可能なシステムリソースの共有により複数のユーザをサポートすることができる多重アクセスシステムである。このような多重アクセスシステムの例は符号分割多重アクセス（ＣＤＭＡ）システム、時分割多重アクセス（ＴＤＭＡ）システム、周波数分割多重アクセス（ＦＤＭＡ）システム、直交周波数分割多重アクセス（ＯＦＤＭＡ）システム及び単一キャリアFDMA (SC-FDMA)システムを含んでいる。

無線通信システムは、フォワードリンク及びリバースリンク上の多くの端末のための通信をサポートすることができる多くの基地局を含む。フォワードリンク（あるいは「ダウンリンク」）は基地局から端末へ通信リンクを示し、リバースリンク（あるいは「アップリンク」）は端末から基地局への通信リンクを示している。システムは、端末がリバースリンク上に送るためのデータを持っている場合は常に、端末が無線リソースのリクエストを送るリソース割り当てスキームを利用してもよい。一般に、無線リソースは時間、周波数、符号、電力および／または送信に使用可能な他のタイプのリソースを含む。基地局は、端末からのリソースリクエストを処理し、端末に無線リソースの許可を送る。その後、端末は、許可されたリソースを使用して、リバースリンク上でデータを送信する。リバースリンクリソースはリソースリクエストを送るために消費される。したがって、効率的にリソースリクエストを送る技術分野において必要性がある。

概要

無線通信システムにおけるリソースリクエストを送る技術がここに記述される。１つのアスペクトでは、複数のタイプのサービス品質情報（ＱｏＳ）はリソースリクエストのためにサポートされ、ＱｏＳクラス及び待ち時間(latency)デッドラインを含む。端末はリバースリンク上で送られるデータを有し、データのためのＱｏＳ情報を決定する。ＱｏＳ情報は少なくとも１つのＱｏＳタイプを含んでもよく、リソースリクエストを送るための使用に選択されたコンフィグレーションに依存してもよい。端末はさらに送るべきデータの量を示すバックログレベル情報を決定してもよい。端末は、バックログレベル情報及びＱｏＳ情報を含むリソースリクエストを生成し、送る。ある設計では、リソースリクエストは（ｉ）バックログレベル情報及び第１のコンフィグレーションのＱｏＳクラス情報 （ｉｉ）バックログレベル情報及び第２のコンフィグレーションのＱｏＳクラス情報あるいは待ち時間デッドライン情報 （ｉｉｉ）バックログレベル情報及び第３のコンフィグレーションの待ち時間デッドライン情報を含む。リソースリクエストは、さらに他の設計のための情報の他のあるコンビネーションを含む。

他のアスペクトでは、複数のフォーマットはリソースリクエストのためにサポートされる。端末は、リソースリクエストで送るために少なくとも１つのタイプの情報を決定する。端末は、送るべき少なくとも１つのタイプの情報に基づいて、複数のフォーマットの中からリソースリクエストに使用するためのフォーマットを決定する。複数のフォーマットは、バックログレベルの第１のフォーマットのＱｏＳ情報及び単なるバックログレベルの第２のフォーマットを含む。端末は、決定されたフォーマットにおける少なくとも１つのタイプの情報を含むリソースリクエストを生成する。１つの設計では、リソースリクエストは、すべてのフォーマットのために固定ビット数（例えば６ビット）を持ち、第１のフォーマットは第１の範囲の値（例えば、０〜４７）に対応し、第２のフォーマットは第２の範囲の値（例えば、４８〜６３）に対応する。

開示の様々な態様及び特徴は、さらに以下に詳細に記述される。

図１は無線通信システムを示す。 図２は、スーパーフレームの設計を示す。 図３は、リソースリクエストの設計を示す。 図４は、リソースリクエストの他の表現を示す。 図５はＱｏＳ情報を備えたリソースリクエストを送るためのプロセス及び装置を示す。 図６はＱｏＳ情報を備えたリソースリクエストを送るためのプロセス及び装置を示す。 図７は異なるフォーマットを備えたリソースリクエストを送るためのプロセス及び装置を示す。 図８は異なるフォーマットを備えたリソースリクエストを送るためのプロセス及び装置を示す。 図９はＱｏＳ情報を備えたリソースリクエストを送るための他のプロセス及び他の装置を示す。 図１０はＱｏＳ情報を備えたリソースリクエストを送るための他のプロセス及び他の装置を示す。 図１１はスペクトルの効率を考慮することによりリソースリクエストを送るためのプロセス及び装置を示す。 図１２はスペクトルの効率を考慮することによりリソースリクエストを送るためのプロセス及び装置を示す。 図１３はバックオフ(backoff)を備えた制御メッセージを送るためのプロセス及び装置を示す。 図１４はバックオフ(backoff)を備えた制御メッセージを送るためのプロセス及び装置を示す。 図１５は、基地局と端末のブロック図を示す。

詳細な説明

図１は無線通信システム１００を示し、アクセス・ネットワーク（ＡＮ）と呼ばれてもよい。システム１００は複数の基地局１１０を含む。基地局は端末と通信し、アクセス・ポイント、ノードＢ、展開された(evolved)ノードＢなどと呼ばれてもよい局である。基地局はそれぞれ特定の地理的エリアに通信カバレッジを提供する。システムコントローラ１３０は基地局１１０へ接続されて、これらの基地局に調整と制御を供給する。

端末１２０はシステムの全体にわたって分散されており、各端末は静止してるものでも良いし、モバイルでもよい。端末も、アクセス端末（ＡＴ）、移動局、ユーザ機器、加入者局装置、局などと呼ばれてもよい。端末は、携帯電話、パーソナルデジタルアシスタント（ＰＤＡ）、ワイヤレス通信装置、無線モデム、ハンドヘルド装置、ラップトップコンピュータ、コードレスホンなどでも良い。端末は、所与の瞬間にフォワードリンク及び／またはリバースリンク上の０、１あるいは複数の基地局と通信できる。

ここに述べられた技術は、ＣＤＭＡ、ＴＤＭＡ、ＦＤＭＡ、ＯＦＤＭＡ及びＳＣ−ＦＤＭＡシステムのような様々な無線通信システムに使用される。「システム」、「ネットワーク」という用語はしばしば交換して使用される。ＣＤＭＡシステムは、ｃｄｍａ２０００、欧州次世代移動通信（ＵＴＲＡ）のような無線技術を実行する。ＯＦＤＭＡシステムは、ウルトラモバイルブロードバンド（ＵＭＢ）、発展したＵＴＲＡ（Ｅ−ＵＴＲＡ）、ＩＥＥＥ８０２．１６（ＷｉＭＡＸ）、ＩＥＥＥ８０２．２０、フラッシュ−ＯＦＤＭ（登録商標）などのような無線技術を実行する。ＵＴＲＡ及びＥ−ＵＴＲＡは「第３世代パートナシッププロジェクト」（３ＧＰＰ）と名づけられた組織からの文献に記述されている。ｃｄｍａ２０００とＵＭＢは、「第３世代パートナシッププロジェクト２」（３ＧＰＰ２）と名づけられた組織からの文献に記述されている。これら様々な無線技術及び標準はこの分野において知られている。

明確化のために技術のあるアスペクトはＵＭＢのために下記に述べられ、ＵＭＢ用語は下記の説明の中で多く使用される。ＵＭＢは、直交周波数分割マルチプレキシング（ＯＦＤＭ）及び符号分割マルチプレキシング（ＣＤＭ）のコンビネーションを利用する。ＵＭＢは、３ＧＰＰ２ Ｃ．Ｓ００８４−００１における題名「Physical Layer for Ultra Mobile Broadband (UMB) Air Interface Specification」、Ｃ．Ｓ００８４−００２における題名「Medium Access Control Layer For Ultra Mobile Broadband (UMB) Air Interface Specification」、Ｃ．Ｓ００８４−００３における題名「Radio Link Layer for Ultra Mobile Broadband (UMB) Air Interface Specification」において述べられ、これらは２００７年８月付けで、公に入手可能である。

図２は、リバースリンクに使用されるスーパーフレーム構造２００の設計を示す。送信タイムラインはスーパーフレームのユニットに分割される。各スーパーフレームは特定のタイムデュレーション(time duration)に及んでもよく、これは、固定或いはコンフィギュラブル（設定可能な）であっても良い。Ｍ＞１の一般的な場合には、各スーパーフレームはＭ物理レイヤー（ＰＨＹ）フレームへ分割される。ある設計では、Ｍ＝２５であって、各スーパーフレームにおける２５個のＰＨＹフレームは、０〜２４のインデックスに割り当てられる。一般的に、Ｎ＞１であって、ある設計ではＮ＝８の場合に、各ＰＨＹフレームはＮ個のＯＦＤＭシンボル周期をカバーする。

図２はさらにサブキャリア構造を示す。システム帯域幅は複数の（Ｋ）直交サブキャリアへ分割され、トーン、ビンなどとも呼ばれる。隣接したサブキャリア間の間隔は固定され、サブキャリアの数はシステム帯域幅に依存する。例えば、１．２５、２．５、５、１０或いは２０ＭＨｚのシステム帯域幅それぞれの１２８、２５６の、５１２、１０２４或いは２０４８サブキャリアである。

図２は、さらにリバースリンク上のパイロット、信号及びあるトラヒックデータの送信をサポートすることができるＣＤＭＡセグメントの設計を示す。ＣＤＭＡセグメントは、リバースＣＤＭＡ専用制御チャネル（Ｒ−ＣＤＣＣＨ）のような１つ以上の物理的なチャネルをサポートする。Ｒ−ＣＤＣＣＨは、リバースリンクリクエストチャネル（ｒ−ｒｅｑｃｈ）のような１つ以上の論理チャネルを運んでもよい。ＣＤＭＡセグメントは、任意の次元の時間周波数リソースのブロックを占める。ある設計では、一般的に、Ｃ≧１の場合に、ＣＤＭＡセグメントはＣ個のＣＤＭＡセグメントを含む。ある設計において、Ｓ＝１２８の場合に、各ＣＤＭＡサブセグメントは、１つのＰＨＹフレームのＮ個のＯＦＤＭシンボル期間のＳ個の隣接するサブキャリアをカバーする。

図２に示される設計では、一般に、Ｑ≧１、Ｑ＝４，６，８などの場合に、ＣＤＭＡセグメントはすべてのＱ個のＰＨＹフレームにおいて送られる。ＣＤＭＡセグメントは、（図２に示されたように）時間にわたりシステム帯域幅を横切ってホップし、或いはサブキャリア（図２に示されない）の固定セット上で送られてもよい。複数の端末は、パイロット、信号などのためのＣＤＭＡセグメントを共有する。

端末はリバースＯＦＤＭＡデータチャネル（Ｒ−ＯＤＣＨ）のためのリバースリンクリソースに割り当てられてもよい。ある設計では、割り当てられたリソースは、タイルのユニットで与えられてもよい。タイルは時間周波数リソースのブロックでもよく、シンボル期間の設定回数におけるサブキャリアの設定回数をカバーする。ある設計では、タイルは、１つのＰＨＹフレームの８つのシンボル期間の１６のサブキャリアをカバーし、１２８個のシンボルを送るまで使用される。割り当てられたタイルは、図２に示されるようなホッピングパターンに基づいてシステム帯域幅を横切ってホップする。端末は、割り当てられたタイル上のデータ及び／又は縦に並べられた信号を送信する。

端末は１つ以上のフローを構成するためにアクセスネットワークと通信する。各フローは１つ以上のストリームのコレクションである。各ストリームは１つ以上のより高いレイヤーアプリケーションのコレクションであり、１つ以上のアプリケーションのためのデータ及び／又は制御情報を運ぶ。各アプリケーションは予約に関係し、そのアプリケーション用パケットの識別のための１組のパケットフィルタを含む。例えば、ＨｙｐｅｒＴｅｘｔ転送プロトコル（ＨＴＴＰ）、ファイル転送プロトコル（ＦＴＰ）、音声及びビデオのような異なるアプリケーションは、１つ以上のフロー上で運ばれた１つ以上のストリームにマップされる。各アプリケーションにはある要求がある。端末は、ＱｏＳブロブ(blobs)或いはプロファイルを使用して、活性化されたアプリケーションの要求を報告する。アクセスネットワークは、そのフローにマップされたすべてのアプリケーションの報告されたＱｏＳブロブ或いはプロファイルに基づいで各フローのＱｏＳ要求を決定する。各フローは特定のＱｏＳクラスに属し、そのフローの１組のＱｏＳ要求に関係している。異なるＱｏＳクラスは、ＱｏＳ要求の異なる組に関連しても良い。

ある設計では、複数のコンフィグレーションはフローのためにサポートされる。第１のフローコンフィグレーションでは、８つまでのフローがサポートされ、各フローは異なるＱｏＳクラスに関連づけられる。第２のフローコンフィグレーションでは、４つまでのフローがサポートされ、各フローは異なるＱｏＳクラスに関連付けられる。適切なフローコンフィグレーションは、端末ですべての活性化されたアプリケーションの報告されたＱｏＳブロブ或いはプロファイルに基づいて、（例えばアクセスネットワークによって）選択される。

送信するべきデータがある場合は常に、端末はＲ−ＯＤＣＨ上の各ストリームのデータを送る。Ｒ−ＯＤＣＨは基地局のスケジューラによってスケジュールされる。任意のストリームのデータがある場合は常に、端末はリクエストチャネル上でリソースリクエストを送信する。スケジューラは、リソースリクエストに応じて端末にＲ−ＯＤＣＨの上のリソースを割り当てる。効率的なスケジューリング及びリソースの割り当てをサポートするために、端末によって送られるデータに関する関連情報を提供することは、リソースリクエストにとって望ましい。

アスペクトでは、リソースリクエストはデータのＱｏＳ情報と同様に送信するデータの量を示す情報を含む。送信するデータの量を示す情報もバックログレベル、バッファサイズ、キューサイズ、ペイロードサイズなどと呼ばれてもよい。明瞭化のために、バックログレベルは、下記説明の中で多く使用される。下記に述べられるように、ＱｏＳ情報はいくつかの方法で提供される。バックログレベル情報及びＱｏＳ情報は、どの端末がリバースリンク上のデータ伝送のスケジュールをするか及び／又はどれだけのリソースを各スケジュールされた端末に割り当てるかを決定するために使用される。

リソースリクエストは固定サイズを有し、固定ビット数で送信される。送られるデータについて可能な限り多くの情報を運ぶために利用可能なビットを利用することが望ましい。一般に、いずれのビット数もリソースリクエストに使用される。明確化のために、次の説明の多くはリソースリクエストが６ビットで送信される設計に関する。

図３は、リソースリクエストの設計を示し、リクエスト報告、ＲＥＱＲｅｐｏｒｔ、ＲＥＱＣＨＲｅｐｏｒｔなどとも呼ばれる。この設計では、リソースリクエストは６ビットで送信され、０〜６３の全範囲内の値を有する。図３に示される設計では、全範囲は２つのリクエストフォーマットのための２つの範囲へ分割される。０〜４７の第１の範囲はリクエストフォーマット１に使用され、４８〜６３の第２の範囲はリクエストフォーマット２に使用される。リクエストフォーマット１については、バックログレベル情報及びバックログタイプ情報の両方がリソースリクエストにおいて送られる。バックログタイプ情報は、送られるデータのＱｏＳ情報を含む。図３に示される設計では、バックログレベル情報は、６つの可能な値のうちの１つを含み、バックログタイプ情報は、８つの可能な値のうちの１つを含み、４８の可能なコンビネーションのうちの１つはリクエストフォーマット１を使用して、リソースリクエストにおいて送られてもよい。リクエストフォーマット２については、バックログレベル情報だけがリソースリクエストにおいて送られ、バックログタイプ情報が省略される。バックログレベル情報は、１６の可能な値のうちの１つを含む。

図４は、図３に示される設計のリソースリクエストの別の表現を示す。図４に示されるように、リソースリクエストの最初の３ビット（例えば３つの最上位ビット（ＭＳＢ））は、「０００」から「１１１」（バイナリ）の８つの可能な値を有する。最初の６つの値「０００」から「１０１」はリクエストフォーマット１用であり、最後の２つの値「１１０」及び「１１１」はリクエストフォーマット２用である。リクエストフォーマット１については、最初の３ビットはバックログレベル用で「０００」から「１０１」で６つの可能な値のうちの１つを供給し、最後の３ビットはバックログタイプ用で「０００」から「１１１」で８つの可能な値のうちの１つを供給する。リクエストフォーマット２については、６ビットはバックログタイプ用で「１１００００」から「１１１１１１」によって１６の可能な値のうちの１つを供給する。バックログレベル及びバックログタイプの値が下記に述べられる。

一般に、リソースリクエストの値の全範囲は、任意の数のリクエストフォーマットの任意の数の範囲に分割される。各範囲は任意の数の値をカバーし、関連するリクエストフォーマットを使用して、送る情報量に基づいて決定されたサイズを有する。各リクエストフォーマットは任意のタイプの情報を含み、そのリクエストフォーマットを使用して送る情報のすべてのタイプの任意のメッセージフォーマットを使用する。明瞭化のために、次の説明の多くは図３に示される２つのリクエストフォーマット用である。

ある設計では、バックログレベル情報は、端末によって達成可能なスペクトルの効率（ＳＥ）を考慮に入れる量によって与えられる。スペクトルの効率は、１つのシンボル期間において１つのサブキャリア上で送ることができ、データ伝送に使用された符号レート及び変調オーダーに依存する情報ビット数によって与えられる。例えば、１のスペクトル効率は符号レート１／２及びＱＰＳＫで達成される。スペクトルの効率はチャネル条件に依存し、その結果、より高いスペクトルの効率はよいチャネル条件の下で達成可能であり、より低いスペクトルの効率は悪いチャネル条件の下で達成可能である。リソースの所定量については、より多くのデータがより高いスペクトル効率で送信されその逆も正しい。スペクトルの効率を考慮に入れることによって、送信するデータの量はより適切に量子化され、バックログレベル情報は要求されたリソース量をより良く伝送することができる。バックログレベル情報を決定する際に使用するスペクトルの効率は最後のリソース割り当てのスペクトル効率、リバースリンク上の最後のデータ伝送で使用されるスペクトル効率、端末などによって送られたチャネル品質インジケータ（ＣＱＩ）によって示されるスペクトルの効率である。

表１は、バックログレベル情報を提供する２つの設計を示す。第１の設計では、バックログレベル情報は、要求されているベースタイルの数を示し、表１の第２欄で与えられる。この設計では、端末は、最初に送信するデータに必要とされるタイルの数tを計算する。端末は、スペクトル効率に基づいてファクタｇを決定する。このファクタは、１以上のスペクトル効率については１に等しく、０．５のスペクトル効率については２に等しく、０．２のスペクトル効率については５に等しい。ベースタイルの数ｍは次にm=t/gとして計算される。第２の設計では、バックログレベル情報は、送信するデータのバイト数ｎを示す。１以下のスペクトル効率については、表１の第３欄で示されるように、バイト数が与えられる。１より大きいスペクトル効率については、バイト数はスペクトル効率によってスケールされ、表１の第４欄で示されるように与えられてもよい。例えば、２のバックログレベル値は、１以下のスペクトル効率の１２８バイト、２のスペクトル効率の２５６バイト、３のスペクトル効率の３８４バイトなどを示す。バックログレベル情報は、他の手法でも提供される。

ある設計では、複数のリクエストコンフィグレーション或いはモードがリクエストフォーマット１で送られたバックログタイプ情報のためにサポートされ、異なるタイプのＱｏＳ情報を提供するために使用される。

ある設計では、あるリクエストコンフィグレーションはアクセスネットワークによる使用のために選択され、（例えば、より高いレイヤ信号を介して送られたＲＥＱＣｏｎｆｉｇパラメータにおいて）端末に送られる。ある設計では、各リクエストコンフィグレーションは、バックログタイプ情報がＱｏＳクラス或いは待ち時間デッドラインの観点から与えられることを可能にする。待ち時間デッドラインは、パケットが終了する前の残り時間でもよく、パケット到着時及びパケットの最大待ち時間に依存しても良い。ＱｏＳクラスもフロークラスと呼ばれてもよい。異なるフローは異なるＱｏＳクラスに属し、上述のように異なるＱｏＳ要求に関連付けられる。

ある設計では、各ストリームは、リソースリクエストの待ち時間タイプかＱｏＳクラスタイプ信号に関連付けられる。各待ち時間タイプストリームについては、アクセスネットワークは、最大時間量を示す待ち時間デッドラインを割り当てても良く、そのストリームのためのパケットは終了する前に待機できる。各ＱｏＳクラスタイプストリームについては、アクセスネットワークは、ストリームが属するフローのためのＱｏＳクラスを割り当ててもよい。各ストリームのリソースリクエストは、（ｉ）ストリームがＱｏＳクラスに関連付けられている場合のＱｏＳクラス情報 （ｉｉ）ストリームが待ち時間デッドラインに関連付けられている場合の待ち時間デッドライン情報を含む。端末は、待ち時間デッドライン又はストリームのために送るデータのＱｏＳクラス情報を決定し、リソースリクエストにおけるこの待ち時間デッドライン或いはＱｏＳクラス情報を提供する。

ある設計では、３つのリクエストコンフィグレーションがバックログタイプ情報のためにサポートされ、ＲＥＱＣｏｎｆｉｇ＝１、２及び３によって識別される。ある設計では、表２に示されるように、ＲＥＱＣｏｎｆｉｇ＝１を備えた第１のリクエストコンフィグレーションは８つの可能なＱｏＳクラス値のうちの１つを報告することをサポートする。このコンフィグレーションでは、各ストリームは、ストリーム属性によって示されるＣｆｇ１ＱｏＳＣｌａｓｓ値に関係しているかもしれない。与えられたストリームＮＮ（ここでＮＮはストリームＩＤである）のリソースリクエストは、バックログタイプ情報としてのこのストリームに対するＣｆｇ１ＱｏＳＣｌａｓｓ値を含む。第１のリクエストコンフィグレーションは、いくつかのＱｏＳクラスのうちの１つに関連したバッファレベルを示すために使用される。

ある設計では、表３に示されるように、ＲＥＱＣｏｎｆｉｇ＝２を備えた第２のリクエストコンフィグレーションは４つの可能なＱｏＳクラス値の１つ或いは４つの可能な待ち時間デッドライン値のうちの１つのいずれかを報告することをサポートする。このコンフィグレーションでは、各ストリームはストリーム属性によって示されるＣｆｇ２ＱｏＳＣｌａｓｓ値に関連する。与えられたストリームＮＮのリソースリクエストは、バックログタイプ情報としてこのストリームに対するＣｆｇ２ＱｏＳＣｌａｓｓ値を含む。或いは、リソースリクエストは、バックログタイプ情報としてストリームＮＮに対する待ち時間デッドライン値を含む。

ある設計では、表４に示されるように、ＲＥＱＣｏｎｆｉｇ＝３を備えた第３のリクエストコンフィグレーションは８つの可能な待ち時間デッドライン値のうちの１つを報告することををサポートする。このコンフィグレーションでは、与えられたストリームＮＮのリソースリクエストは、バックログタイプ情報としてこのストリームのための待ち時間デッドラインを含む。第３のリクエストコンフィグレーションはいくつかの待ち時間デッドラインのうちの１つに関連したバッファレベルを示すために使用される。リソースリクエストにおいて送られたバックログレベル情報は、示された待ち時間デッドラインを有するすべてのストリームのための送るデータ総量を示す。例えば、ストリーム１が２０ミリセカンドの待ち時間デッドラインで１００バイトを持っている場合、ストリーム２は２０ミリセカンドの待ち時間デッドラインで２００バイトを持っており、ストリーム３は４０ミリセカンドの待ち時間デッドラインで１５０バイトを持っており、そして、端末は、ストリーム１及び２について、２０ミリセカンドの待ち時間デッドラインで３００バイトのリソースリクエストを送る。

表２乃至表４は、バックログタイプ情報のための３つのリクエストコンフィグレーションの設計例を示す。一般に、リクエストコンフィグレーションのどんな数もサポートされ、各リクエストコンフィグレーションは任意のタイプのＱｏＳ情報を提供する。

リクエストフォーマット１は、同じＱｏＳクラスに属するか、同じ待ち時間デッドラインを有する１つ以上のストリームにバックログレベル及びバックログタイプ情報の両方を供給するために使用される。バックログタイプ情報は特定のＱｏＳクラス或いは１つ以上のストリームのための特定の待ち時間デッドラインを含む。異なるＱｏＳクラスに属するか、異なる待ち時間デッドラインを有するストリームのためのバックログレベル及びバックログタイプ情報は、例えば、同じＱｏＳクラス或いは同じ待ち時間デッドラインを有する１つ以上のストリームの各組のあるリソースリクエストである複数のリソースリクエストにおいて送られる。

リクエストフォーマット２は、全てのストリームの総バックログレベルを供給するために使用され、ＱｏＳ情報がストリームのために指定されない場合に使用される。全てのストリームのバックログレベルは総バックログレベルを得るために合計される。ある設計では、総バックログレベルは、端末によって達成可能なスペクトル効率を考慮に入れる量で与えられる。表５は、総バックログレベル情報を提供する２つの設計を示す。第１の設計では、総バックログレベル情報は、要求されているベースタイルの数を示し、それは表５の第２欄で与えられる。端末は、上述の表１に述べられたベースタイルの数を計算する。第２の設計では、総バックログレベル情報は、スペクトル効率によってスケールされたデータのバイト総数を示し、「ｋ」が１０２４バイトを示す場合に表５の第４欄で与えられる。

リソースリクエストを生成するために、端末は、最初にバックログバイトの数を決定し、それは送るデータを含んでいてもよく、巡回冗長検査（ＣＲＣ）、データとともに送信する任意のインバンド信号などのオーバヘッドを決定する。端末は、スペクトル効率と同様に選択されたリクエストフォーマットにも依存するマッピングに基づいて、バックログバイト数をバックログレベル値にマップする。このスペクトル効率は、最後のリバースリンク割り当て、現在の達成可能なスペクトル効率、デフォルトのスペクトル効率など（例えば端末がスケジューラからどんなリバースリンク割り当てを受信していない場合）のスペクトル効率である。その後、端末は、バックログレベル情報及びバックログ型／ＱｏＳ情報（適用可能な場合に）に基づいてリソースリクエストを生成する。

端末は、リソースリクエストを送り、端末でのバッファのステータスに関するバックログレベル情報及び可能であればＱｏＳ情報を有するスケジューラを提供する。端末はｒ−ｒｅｑｃｈ上の帯域外信号としてリソースリクエストを送り、それはＣＤＭＡサブセグメントにおけるＲ−ＣＤＣＣＨ上で送られる。端末は、さらにＲ−ＯＤＣＨ上のデータと共に帯域内信号としてリソースリクエストを送ってもよい。

ある設計では、端末は、Ｒ−ＯＤＣＨ上の帯域内信号として以下のようにリソースリクエストを送ってもよい。端末は、パケットにおいてリソースリクエストを送り、パケットが送られる場合、帯域内リクエストタイマーをスタートする。パケットが誤って解読される場合、端末は帯域内リクエストタイマーを停止させ、パケットが正確に解読される場合、タイマーを再スタートする。帯域内リクエストタイマーがアクティブな間、最後の帯域内リソースリクエストにおいて考慮されなかった新規のバックログ情報がある場合のみ、端末は別のリソースリクエストを送る。帯域内リクエストタイマーは同じ情報が既に帯域内で送られている場合に、制御チャネルの使用を防ぐために使用される。これは制御チャネル上の負荷を低減する。端末は、所定サイズより大きなパケット、最低の待ち時間パケット、最優先フローなどにおいて帯域内リソースリクエストを送ってもよい。

ある設計では、端末は、ｂａｃｋｏｆｆスキームに基づいたＣＤＭＡサブセグメントにおけるＲ−ＣＤＣＣＨ上の帯域外信号としてリソースリクエストを送ってもよい。端末はｒ−ｒｅｑｃｈ上のリソースリクエストを送った後にｂａｃｋｏｆｆタイマーをスタートする。ｂａｃｋｏｆｆタイマーがアクティブな間、端末は、（ｉ）最後のリソースリクエストにおける全てのストリームの優先度より高い優先度を備えたストリームのリソースリクエスト或いは（ｉｉ）（上述の設計における２０ミリセカンドの）最低の待ち時間要求を示すリソースリクエストであって、最後のリソースリクエストで示されなかったもの、を除いてリソースリクエストを送ることをやめる。端末は、０からＷのウィンドウ内の偽似乱数値にタイマーをセットし、リソースリクエストが送られ、リソース割り当てが所定時間期間内に受け取られない場合は常に、Ｗを増加させてもよい（例えば、２倍）。端末は、ハンドオフの後に（例えばあるサービング・セクターから別のサービング・セクターへ）ｂａｃｋｏｆｆタイマーを０にリセットする。このｂａｃｋｏｆｆスキームは、ＣＤＭＡサブセグメントの過負荷をかけることを防ぎ、他の制御チャネル（例えばＣＱＩチャネル）に適用される。Ｆが４、８、１２などに等しい場合であって、Ｆ ＰＨＹフレーム内で利用可能な場合、端末は、Ｒ−ＣＤＣＣＨ（Ｒ−ＣＤＣＣＨの代わりに）上でリソースリクエストを送る。

図５は、ＱｏＳ情報を備えたリソースリクエストを送る処理５００の設計を示す。プロセス５００は端末或いは他のあるエンティティによって行なわれる。端末は、複数のコンフィグレーション（ブロック５１２）の中からリソースリクエストを送るための使用に選択されたコンフィグレーションを決定し、受信する。各コンフィグレーションは、複数の可能なＱｏＳタイプの少なくとも１つに関連する。ある設計では、複数の可能なＱｏＳタイプはＱｏＳクラス及び待ち時間デッドラインを含む。端末は、選択されたコンフィグレーションに基づいてリソースリクエストで送るために少なくとも１つのＱｏＳタイプを決定する（ブロック５１４）。

端末は、送るべきデータを有し、データ（ブロック５１６）のためのＱｏＳ情報を決定する。ＱｏＳ情報は、選択されたコンフィグレーションのための少なくとも１つのＱｏＳタイプを含んてもよい。端末は、さらに送るデータのためのバックログレベル情報を決定する（ブロック５１８）。バックログレベル情報は、複数のバックログレベル値のうちの１つを含んでもよく、全てのコンフィグレーションに適用可能である。端末は、バックログレベル情報及びＱｏＳ情報を含むリソースリクエストを生成し送る（ブロック５２０）。

ある設計では、リソースリクエストは（ｉ）第１のコンフィグレーションが選択されている場合のバックログレベル情報及びＱｏＳクラス情報 （ｉｉ）第２のコンフィグレーションが選択されている場合のバックログレベル情報及びＱｏＳクラス情報か、待ち時間デッドライン情報の一方 （ｉｉｉ）第３のコンフィグレーションが選択されている場合、バックログレベル情報及び待ち時間デッドライン情報を含む。リソースリクエストは、さらに他の設計の情報の他のコンビネーションを含んでもよい。ある設計では、リソースリクエストは、第１のコンフィグレーションの８つの可能なＱｏＳクラス値のうちの１つ或いは第２のコンフィグレーションの４つの可能なＱｏＳクラス値のうちの１つを含む。ある設計では、リソースリクエストは、第２のコンフィグレーションの４つの可能な待ち時間デッドライン値のうちの１つ或いは第３のコンフィグレーションの８つの可能な待ち時間デッドライン値のうちの１つを含む。第１のコンフィグレーションは第１の数のフロー（例えば８つのフロー）のために選ばれ、第２のコンフィグレーションは第２の数のフロー（例えば４つのフロー）のために選ばれる。リソースリクエストは、全てのコンフィグレーションのための固定ビット数（例えば６ビット）を含む。

図６は、ＱｏＳ情報を備えたリソースリクエストを送る装置６００の設計を示す。装置６００は、リソースリクエストを送るための使用に選択されたコンフィグレーションを決定する手段（モジュール６１２）と、選択されたコンフィグレーションに基づいてリソースリクエストにおいて送るための少なくとも１つのＱｏＳタイプを決定する手段（モジュール６１４）と、選択されたコンフィグレーションの少なくとも１つのＱｏＳタイプを含むＱｏＳ情報とともに、送るデータのＱｏＳ情報を決定する手段と、（モジュール６１６）と、送るデータのためのバックログレベル情報を決定する手段（モジュール６１８）と、バックログレベル情報及びＱｏＳ情報を含むリソースリクエストを生成する手段（モジュール６２０）とを含む。

図７は、異なるフォーマットを備えたリソースリクエストを送る処理７００の設計を示す。処理７００は端末或いは他のあるエンティティによって行なわれる。端末は、リソースリクエストで送るための少なくとも１つのタイプの情報を決定する（ブロック７１２）。端末は、送るべき少なくとも１つのタイプの情報に基づいて複数のフォーマットの中からリソースリクエストに使用するためのフォーマットを決定する（ブロック７１４）。複数のフォーマットは、バックログレベル情報及びＱｏＳ情報の第１のフォーマット及び単にバックログレベル情報の第２のフォーマットを含む。少なくとも１つのタイプの情報がバックログレベル情報及びＱｏＳ情報を含む場合、端末が第１のフォーマットを使用する。少なくとも１つのタイプの情報が単にバックログレベル情報を含む場合、端末は第２のフォーマットを使用する。端末は、リソースリクエストが特定のストリームのためのものである場合、第１のフォーマットを使用し、リソースリクエストが複数のストリームのものである場合、第２のフォーマットを使用する。端末はＱｏＳ情報に関連したストリームのための第１のフォーマットを使用し、無ＱｏＳ情報に関連したストリーム或いは変化するＱｏＳ情報を備えた複数のストリームのための第２のフォーマットを使用する。端末は、さらに他の基準に基づいた第１の又は第２フォーマットを選択する。

端末は、決定されたフォーマットにおいて少なくとも１つのタイプの情報を含むリソースリクエストを生成する（ブロック７１６）。リソースリクエストは、全ての複数のフォーマットの固定ビット数（例えば６ビット）を含む。第１のフォーマットは、リソースリクエストのための値（例えば、０〜４７）の第１の範囲に対応し、第２のフォーマットは値（例えば、４８〜６３）の第２の範囲に対応する。

装置８００は、リソースリクエストで送る少なくとも１つのタイプの情報を決定するための手段（モジュール８１２）と、送るべき少なくとも１つのタイプの情報に基づいて複数のフォーマットの中からリソースリクエストに使用するためのフォーマットを決定するための手段（モジュール８１４）と、決定されたフォーマットにおいて少なくとも１つのタイプの情報を含むリソースリクエストを生成する手段（モジュール８１６）とを含む。

図９は、ＱｏＳ情報を備えたリソースリクエストを送る処理９００の設計を示す。処理９００は端末或いは他のあるエンティティによって行なわれる。端末は、送るデータのＱｏＳクラス情報或いは待ち時間デッドライン情報を決定する（ブロック９１２）。端末が、送るデータのためにバックログレベル情報を決定する（ブロック９１４）。端末は、第１のフィールドにおけるバックログレベル情報及び第２のフィールドにおけるＱｏＳクラス情報或いは待ち時間デッドライン情報を含むリソースリクエストを生成する（ブロック９１６）。

ブロック９１２の１つの設計では、端末は、送るデータが属する少なくとも１つのストリームを識別し、少なくとも１つのストリームがＱｏＳクラス或いは待ち時間デッドラインに関連しているかどうか決定する。次に、端末は、（ｉ）ＱｏＳクラスに関連していた場合の少なくとも１つのストリームのＱｏＳクラス情報 或いは（ｉｉ）待ち時間デッドラインに関連していた場合の少なくとも１つのストリームの待ち時間デッドライン情報を決定する。

ブロック９１６のある設計においては、端末は、（ｉ）第２のフィールドの値の第１の範囲にＱｏＳクラス情報をマップするか、（ｉｉ）第２のフィールドの値の第２の範囲に待ち時間デッドライン情報をマップする。ある設計では、第２のフィールドは３ビットを含み、端末は（ｉ）する、第２のフィールドの４つの可能な値のうちの１つにＱｏＳクラス情報をマップするか、（ｉｉ）第２のフィールドの４つの異なる可能な値のうちの１つに待ち時間デッドライン情報をマップする。

図１０は、ＱｏＳ情報を備えたリソースリクエストを送る装置１０００の設計を示す。装置１０００は、送るデータのＱｏＳクラス情報或いは待ち時間デッドライン情報を決定するための手段と（モジュール１０１２）、送るデータのバックログレベル情報を決定するための手段（モジュール１０１４）と、第１のフィールドにおけるバックログレベル情報及び第２のフィールドにおけるＱｏＳクラス情報或いは待ち時間デッドライン情報を含むリソースリクエストを生成する手段（モジュール１０１６）とを含む。

図１１は、スペクトル効率を考慮することによりリソースリクエストを送る処理１１００の設計を示す。処理１１００は端末或いは他のあるエンティティによって行なわれる。端末は、送るデータの量及びスペクトル効率に基づいてバックログレベル情報を決定する（ブロック１１１２）。端末は、最近割り当てられたリソース、最近のＣＱＩなどに基づいてスペクトル効率を決定する。端末は、バックログレベル情報を含むリソースリクエストを生成する（ブロック１１１４）。

ある設計では、例えば、表１又は表５に示されるように、端末はスペクトル効率によってスケールされた異なるバイト数に対応する複数のバックログレベル値のうちの１つを選択する。他の設計では、端末は、（ｉ）スペクトル効率が閾値より大きい場合のスペクトル効率によってスケールされた異なるバイト数 （ｉｉ）スペクトル効率が閾値以下の場合の異なるバイト数に対応する複数のバックログレベル値のうちの１つを選択する。また他の設計では、例えば、表１又は表５に示されるように、端末はスペクトル効率に基づいて決定された異なるタイル数に対応する複数のバックログレベル値のうちの１つを選択する。端末は、さらに他の手法で複数のバックログレベル値のうちの１つを選択する。全ての設計について、端末は、選択されたバックログレベル値を含むリソースリクエストを生成する。

図１２は、スペクトル効率を考慮することによりリソースリクエストを送る装置１２００の設計を示す。装置１２００は、送るデータの量及びスペクトル効率に基づいてバックログレベル情報を決定するための手段（モジュール１２１２）と、バックログレベル情報を含むリソースリクエストを生成する手段（モジュール１２１４）を含む。

図１３は、ｂａｃｋｏｆｆを備えた制御メッセージを送る処理１３００の設計を示す。処理１３００は端末或いは他のあるエンティティによって行なわる。端末は第１の制御メッセージ、例えば送るデータのためのリソースリクエスト、ハンドオフリクエスト、ＣＱＩ報告などを送る（ブロック１３１２）。端末は、ウィンドウ内の第１の擬似乱数値を選択し（ブロック１３１４）、第１の制御メッセージを送ると、第１の擬似乱数値にｂａｃｋｏｆｆタイマーをセットする（ブロック１３１６）。

端末は、ｂａｃｋｏｆｆタイマーに基づいて第２の制御メッセージを送るかどうか決定する（ブロック１３１８）。ある設計では、第１の制御メッセージについてのレスポンスが受信されず（例えば、リソースリクエストについての割り当てが受信されない）、ｂａｃｋｏｆｆタイマーが終了する場合、端末は第２の制御メッセージを送る。端末は第２の制御メッセージを送った後にウィンドウを増加し、増加したウィンドウ内の第２の偽似乱数値を選択し、第２の制御メッセージを送ると、第２の偽似乱数値にｂａｃｋｏｆｆタイマーをセットする。その後、端末は、ｂａｃｋｏｆｆタイマーに基づいて他の制御メッセージを送るべきかどうか決定する。

ある設計では、制御メッセージはリソースリクエストであり、（ｉ）第１のリソースリクエストで示された少なくとも１つのストリームの最も高い優先度より高い優先権をストリームが有する場合、（ｉｉ）ストリームが最短の待ち時間デッドラインを有し、最短の待ち時間デッドラインが第１のリソースリクエストで示されていない場合、（ｉｉｉ）他のある基準が満たされている場合に、端末はｂａｃｋｏｆｆタイマーが終了する前に、ストリームのための第２のリソースリクエストを送る。

図１４は、ｂａｃｋｏｆｆを備えた制御メッセージを送る装置１４００の設計を示す。装置１４００は、例えば、送るデータのためのリソースリクエストである第１の制御メッセージを送る手段（モジュール１４１２）と、ウィンドウ内の第１の擬似乱数値を選択する手段（モジュール１４１４）と、第１の制御メッセージを送ると第１の擬似乱数値にｂａｃｋｏｆｆタイマーをセットする手段（モジュール１４１６）と、ｂａｃｋｏｆｆタイマーに基づいて第２の制御メッセージを送るか否かを決定する手段（モジュール１４１８）とを含む。

図６、８、１０、１２及び１４のモジュールは、プロセッサ、エレクトロニクスデバイス、ハードウェアデバイス、エレクトロニクスコンポーネント、論理回路、メモリなど或いはそれらの任意の組合せを含む。

図１５は、基地局１１０及び端末１２０の設計のブロック図を示し、基地局のうちの１つ、及び図１の中の端末のうちの１つである。この設計では、一般的にＴ≧１及びＲ≧１であり、端末１２０は、Ｔ個のアンテナ１５３４ａ〜１５３４ｔを有し、基地局１１０はＲ個のアンテナ１５５２ａ〜１５５２ｒを具備する。

端末１２０では、送信（ＴＸ）データ及び制御プロセッサ１５２０はデータ源１５１２からのトラヒックデータを受信し、トラヒックデータを処理（例えば、符号化、インタリーブ、スクランブル、シンボルマップ）し、データシンボルを提供する。プロセッサ１５２０は、さらにコントローラ／プロセッサ１５４０から制御情報（例えばリソースリクエスト）を受信し、制御情報を処理し、制御シンボルを提供する。プロセッサ１５２０は、さらにデータ及び制御シンボルでパイロットシンボルを生成し多重化する。ＴＸ ＭＩＭＯプロセッサ１５３０は、プロセッサ１５２０からのシンボルを処理（例えばプレコード）し、Ｔ出力シンボルストリームをＴ変調器（ＭＯＤ）１５３２ａ〜１５３２ｔに供給する。端末１２０が単一のアンテナを装備している場合、ＴＸ ＭＩＭＯプロセッサ１５３０は省略可能である。各変調器１５３２は、出力チップストリームを得るためにその出力シンボルストリームを処理（例えばＯＦＤＭ、ＣＤＭなどのための）する。各変調器１５３２は、リバースリンク信号を生成するためにその出力チップストリームを調整（例えば、アナログ変換、フィルタ、増幅、アップコンバート）する。変調器１５３２ａ〜１５３２ｔからのＴ個のリバースリンク信号は、Ｔ個のアンテナ１５３４ａ〜１５３４ｔそれぞれを介して送信される。

基地局１１０では、アンテナ１５５２ａ〜１５５２ｒは端末１２０及び／又は他の端末からのリバースリンク信号を受信する。各アンテナ１５５２はそれぞれの復調器（ＤＥＭＯＤ）１５５４に受信信号を供給する。各復調器１５５４は、サンプルを得るためにその受信信号を調整（例えば、フィルタ、増幅、ダウンコンバート、ディジタル化）し、さらに復調されたシンボルを得るためにサンプルを（例えばＯＦＤＭ、ＣＤＭなどのために）処理する。ＲＸ ＭＩＭＯプロセッサ１５６０は全てのＲ個の復調器１５５４ａ〜１５５４ｒからの復調されたシンボル上でＭＩＭＯ検出を行ない、検出されたシンボルを提供する。受信（ＲＸ）データ及び制御プロセッサ１５７０は検出されたシンボルを処理（例えば、復調、デインタリーブ、デスクランブル、復号化）し、データシンク１５７２に復号化されたデータを供給し、コントローラ／プロセッサ１５９０に復号化された制御情報（例えばリソースリクエスト）を提供する。一般に、プロセッサ１５６０及び１５７０による処理は端末１２０でのプロセッサ１５３０及び１５２０それぞれによる処理と相補的である。

基地局１１０は、端末１２０へフォワードリンク上でトラヒックデータ及び／又は制御情報を送信する。データ源１５７８からのトラフィックデータ及び／又はコントローラ／プロセッサ１５９０からの制御情報（例えばリソース割り当て）は、ＴＸデータ及び制御プロセッサ１５８０によって処理され、Ｒ出力シンボルストリームを得るためにＴＸ ＭＩＭＯプロセッサ１５８２によってさらに処理される。Ｒ個の変調器１５５４ａ〜１５５４ｒは、Ｒ個の出力チップストリームを得るためにＲ個の出力シンボルストリーム（例えばＯＦＤＭのための）を処理し、Ｒ個のフォワードリンク信号を得るために出力チップストリームをさらに調整し、それらはＲ個のアンテナ１５５２ａ〜１５５２ｒを通して送信される。端末１２０では、基地局１１０からのフォワードリンク信号はアンテナ１５３４ａ〜１５３４ｔによって受信され、復調器１５３２ａ〜１５３２ｔによって調整、処理され、さらに、端末１２０へ送られたトラヒックデータ及び制御情報を回復するためにＲＸ ＭＩＭＯプロセッサ１５３６（適用可能な場合）及びＲＸデータ及び制御プロセッサ１５３８によって処理される。トラヒックデータはデータシンク１５３９へ提供される。

コントローラ／プロセッサ１５４０及び１５９０は端末１２０及び基地局１１０それぞれでのオペレーションを管理する。メモリ１５４２及び１５９２は端末１２０及び基地局１１０それぞれのデータとプログラムコードを格納する。スケジューラ１５９４はフォワード及び／又はリバースリンク上のデータ伝送のために端末をスケジュールし、スケジュールされた端末にリソースを割り当てる。

当業者は、情報と信号が様々な異なる技術及び技能のいずれかを使用して表わすことができることを理解することができる。例えば、上記の説明の全体にわたって言及されたデータ、指示、コマンド、情報、信号、ビット、シンボル及びチップは、電圧、電流、電磁波、磁場、磁粒子、光学フィールド、光学粒子、或いはそれらの任意のコンビネーションで表わすことができる。

当業者は、さらに、ここにおける開示と関連して開示された様々な図示した論理的なブロック、モジュール、回路及びアルゴリズムステップが電子ハードウェア、コンピューターソフトウェア或いは両方のコンビネーションとして実現されることを認識することができる。ハードウェアとソフトウェアとの互換性を明白に示すために、様々な図示したコンポーネント、ブロック、モジュール、回路及びステップが、それらの機能性の点から一般的に上述された。そのような機能性がハードウェア又はソフトウェアとして実現されるかどうかは、全体的なシステムに課された特定用途及び設計制約に依存する。当業者は各特定用途の方法を変更することで開示された機能性を実現することができるが、そのような実現の決定は本開示の範囲を離れることを引き起こすものとして解釈されるべきではない。

ここにおける開示に関連して述べられた様々な図示した論理的なブロック、モジュール及び回路は、ここにおいて述べられた機能を実行するための汎用目的プロセッサ、デジタル信号プロセッサー（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレー（ＦＰＧＡ）或いは他のプログラマブル論理装置、ディスクリートゲート、トランジスターロジック、ディスクリートハードウェアコンポーネント或いはそれらの任意の組み合わせで実現される。汎用目的プロセッサはマイクロプロセッサーでもよく、また、プロセッサは従来のプロセッサ、コントローラ、マイクロコントローラ或いはステートマシンの任意の組合せでも良い。プロセッサも、コンピューティングデバイス（例えばＤＳＰとマイクロプロセッサーの組み合わせ、複数のマイクロプロセッサー、ＤＳＰコアに関連する１つ以上のマイクロプロセッサー或いは他のそのようなコンフィグレーション）の組み合わせとして実現される。

ここにおける開示に関連する述べられたアルゴリズム或いは方法のステップは、ハードウェア、プロセッサによって実行されるソフトウェアモジュール、或いは２つのコンビネーションで直接具体化される。ソフトウェアモジュールは、ＲＡＭメモリ、フラッシュメモリ、ＲＯＭメモリ、ＥＰＲＯＭメモリ、ＥＥＰＲＯＭメモリ、レジスタ、ハードディスク、リムーバブルディスク、ＣＤ−ＲＯＭ或いは公知の他の記憶メディアの形式に存在することができる。例示的な記憶メディアは、プロセッサが情報を読むことができ、かつプロセッサが情報を記憶メディアに書き込むことができるようにプロセッサに接続される。また、記憶メディアはプロセッサと一体化しても良い。プロセッサと記憶メディアはＡＳＩＣに存在してもよい。ＡＳＩＣはユーザ端末に存在しても良い。また、プロセッサと記憶メディアはユーザ端末の個別のコンポーネントとして存在しても良い。

１つ以上の例示的な設計では、述べられた関数は、ハードウェア、ソフトウェア、ファームウェア或いはそれらの任意のコンビネーションで実現されてもよい。ソフトウェアで実現される場合、関数は、コンピューター読み出し可能なメディアの１つ以上の命令或いはコードとして格納されるか、或いは送信される。コンピュータ読み出し可能なメディアは、及びある場所から別の場所へコンピュータプログラムの転送を容易にするどんなメディアを含む通信媒体及びコンピュータ記憶装置メディアの両方を含む。記憶媒体は、汎用目的又は特定目的のコンピューターによってアクセスされることができるどんな利用可能なメディアでもよい。例によって、限定するものではないが、このようなコンピュータ読み取り可能なメディアは、汎用目的或いは特定目的コンピューター、或いは汎用目的又は特定目的プロセッサによってアクセスされることができ、所望のプログラムコード手段を命令或いはデータ構造の形式で伝送し或いは格納するのに使用されることができるＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、ＣＤ−ＲＯＭ又は他の光ディスク記憶装置、磁気ディスク記憶装置或いは他の磁気記憶装置を含む。さらに、どんな接続も適切にコンピューター読み取り可能なメディアと名付けられる。例えば、同軸ケーブル、光ファイバーケーブル、ツイストペア、デジタル加入者線（ＤＳＬ）或いは赤外線、無線及びマイクロ波のような無線技術を使用して、ソフトウェアがウェブサイト、サーバー或いは他のリモートソースから送信される場合、同軸ケーブル、光ファイバーケーブル、ツイストペア、ＤＳＬ或いは赤外線、無線及びマイクロ波のような無線技術は、メディアの定義に含まれる。ディスクがレーザーでデータを光学的に再生する間であって、ディスクが通常磁気的にデータを再生する場合、ここにおいて使用されるディスク(disk or disc)は、コンパクトディスク（ＣＤ）、レーザーディスク（登録商標）、光ディスク、デジタルバーサタイルディスク（ＤＶＤ）、フロッピ−（登録商標）ディスク及びブルーレイディスクを含む。上記の組み合わせもコンピュータ読み取り可能なメディアの範囲内に含まれてべきである。

開示の以前の説明はどんな当業者も開示を作るか、使用することを可能にするために提供される。開示への様々な修正は当業者にとって容易に明白であり、ここに定義された一般的な原則は、開示の精神か範囲から外れずに、他の変化に適用できる。したがって、開示は、ここで述べられた例及び設計に限定されることを意図するものではなく、ここに開示された原則及び新規な特徴と一致する最も広い範囲に従うものである。

Claims (47)

1. 送るデータのためのサービス品質（ＱｏＳ）情報を決定するように構成された少なくとも１つのプロセッサと、前記ＱｏＳ情報は、複数の可能なＱｏＳタイプの少なくとも１つを含み、前記少なくとも１つのプロセッサは、前記ＱｏＳ情報を含むリソースリクエストを生成し、
   前記少なくとも１つのプロセッサに接続されたメモリと
   を具備し、
   前記少なくとも１つのプロセッサは、リソースリクエストの複数のコンフィグレーションの中から選択されたリソースリクエストのコンフィグレーションに基づいて、リソースリクエストで送るために少なくとも１つのＱｏＳタイプを決定するように構成され、各コンフィグレーションは、１つ以上の複数の可能なＱｏＳタイプに関連付けられている、
   無線通信のための装置。
2. 前記複数の可能なＱｏＳタイプはＱｏＳクラス及び待ち時間デッドラインを含む請求項１記載の装置。
3. 前記少なくとも１つのプロセッサは、送るデータの量を示すバックログレベル情報を決定し、さらにバックログレベル情報を含むリソースリクエストを生成するように構成されている請求項１記載の装置。
4. 前記少なくとも１つのプロセッサは、送信するデータの量に基づいて複数のバックログレベル値のうちの１つを決定するように構成され、前記複数のバックログレベル値は複数のコンフィグレーションの全てについて適用可能であり、前記少なくとも１つのプロセッサは、前記決定されたバックログレベル値をさらに含むリソースリクエストを生成するように構成されている請求項３記載の装置。
5. 前記リソースリクエストは複数のコンフィグレーションの全てのための固定ビット数を含む請求項１記載の装置。
6. 前記少なくとも１つのプロセッサは、第１のコンフィグレーションが選択されている場合に送るデータの量を示すバックログレベル情報及びＱｏＳクラス情報を含むリソースリクエストを生成するように構成されている請求項１記載の装置。
7. 前記少なくとも１つのプロセッサは、第２のコンフィグレーションが選択されている場合に、前記バックログレベル情報、ＱｏＳクラス情報或いは待ち時間デッドライン情報のいずれか一方を含むリソースリクエストを生成するように構成される請求項６記載の装置。
8. 前記少なくとも１つのプロセッサは、第３のコンフィグレーションが選択されている場合に前記バックログレベル情報及び待ち時間デッドライン情報を含むリソースリクエストを生成するように構成される請求項７記載の装置。
9. 前記第１のコンフィグレーションは第１のフロー数について選択され、前記第２のコンフィグレーションは、フローの第１の数未満の第２のフロー数について選択される請求項７記載の装置。
10. 前記ＱｏＳ情報はＱｏＳクラス情報を含み、前記リソースリクエストは、前記第１のコンフィグレーションについての８つの可能なＱｏＳクラス値のうちの１つ或いは前記第２のコンフィグレーションのための４つの可能なＱｏＳクラス値のうちの１つを含む請求項７記載の装置。
11. 前記ＱｏＳ情報は待ち時間デッドライン情報を含み、前記リソースリクエストは、第２のコンフィグレーションについての４つの可能な待ち時間デッドライン値のうちの１つ或いは第３のコンフィグレーションについての８つの可能な待ち時間デッドライン値のうちの１つを含む請求項８記載の装置。
12. 送るデータのためのサービス品質（ＱｏＳ）情報を決定し、前記ＱｏＳ情報は、複数の可能なＱｏＳタイプの少なくとも１つを含み、
    前記ＱｏＳ情報を含むリソースリクエストを生成し、
    前記リソースリクエストで送るための少なくとも１つのＱｏＳタイプは、リソースリクエストの複数のコンフィグレーションの中から選択されたリソースリクエストのコンフィグレーションに基づいて決定され、各コンフィグレーションは、１つ以上の複数の可能なＱｏＳタイプに関連付けられている、
    無線通信のための方法。
13. 前記送るデータの量を示すバックログレベル情報を決定し、
    前記リソースリクエストを生成することは、さらにバックログレベル情報を含むリソースリクエストを生成することをさらに含む請求項１２記載の方法。
14. 前記リソースリクエストを生成することは、
    第１のコンフィグレーションが選択されている場合にバックログレベル情報及びＱｏＳクラス情報を含むリソースリクエストを生成し、
    第２のコンフィグレーションが選択されている場合に、バックログレベル情報、ＱｏＳクラス情報或いは待ち時間デッドライン情報のいずれか一方を含むリソースリクエストを生成し、
    第３のコンフィグレーションが選択されている場合にバックログレベル情報及び待ち時間デッドライン情報を含むリソースリクエストを生成することを含む請求項１３記載の方法。
15. 送るデータのためのサービス品質（ＱｏＳ）情報を決定する手段と、前記ＱｏＳ情報は、複数の可能なＱｏＳタイプの少なくとも１つを含み、
    前記ＱｏＳ情報を含むリソースリクエストを生成する手段とを具備し、
    前記複数の可能なＱｏＳタイプの少なくとも１つは、リソースリクエストの複数のコンフィグレーションの中から選択されたリソースリクエストのコンフィグレーションに基づいて決定され、各コンフィグレーションは、１つ以上の複数の可能なＱｏＳタイプに関連付けられている、
    無線通信のための装置。
16. 前記送るデータの量を示すバックログレベル情報を決定する手段と、
    前記リソースリクエストを生成する手段は、さらにバックログレベル情報を含むリソースリクエストを生成する手段をさらに具備する請求項１５記載の装置。
17. 前記リソースリクエストを生成する手段は、
    第１のコンフィグレーションが選択されている場合にバックログレベル情報及びＱｏＳクラス情報を含むリソースリクエストを生成する手段と、
    第２のコンフィグレーションが選択されている場合に、バックログレベル情報、ＱｏＳクラス情報或いは待ち時間デッドライン情報のいずれか一方を含むリソースリクエストを生成する手段と、
    第３のコンフィグレーションが選択されている場合にバックログレベル情報及び待ち時間デッドライン情報を含むリソースリクエストを生成する手段と
    を具備する請求項１６記載の装置。
18. 少なくとも１つのコンピュータに、送るデータのためのサービス品質（ＱｏＳ）情報を決定させるコードと、前記ＱｏＳ情報は、複数の可能なＱｏＳタイプの少なくとも１つを含み、
    前記少なくとも１つのコンピュータに、前記ＱｏＳ情報を含むリソースリクエストを生成させるためのコードとを含み、
    前記複数の可能なＱｏＳタイプの少なくとも１つは、リソースリクエストの複数のコンフィグレーションの中から選択されたリソースリクエストのコンフィグレーションに基づいて決定され、各コンフィグレーションは、１つ以上の複数の可能なＱｏＳタイプに関連付けられている、
    コンピュータプログラム。
19. 前記少なくとも１つのコンピュータに、前記送るデータの量を示すバックログレベル情報を決定させるコードと、
    前記少なくとも１つのコンピュータに、バックログレベル情報を含むリソースリクエストを生成させるコードとをさらに含む請求項１８記載のコンピュータプログラム。
20. リソースリクエストで送る少なくとも１つのタイプの情報を決定し、前記送る少なくとも１つのタイプの情報に基づいて、複数のフォーマットの中からリソースリクエストに使用するフォーマットを決定し、前記決定されたフォーマットにおける前記少なくとも１つのタイプの情報を含む前記リソースリクエストを生成するように構成された少なくとも１つのプロセッサと、
    前記少なくとも１つのプロセッサに接続されたメモリと
    を具備する無線通信のための装置。
21. 前記複数のフォーマットは送信するデータの量を示すバックログレベル情報及びサービス品質（ＱｏＳ）情報のための第１のフォーマットを含み、前記少なくとも１つのプロセッサは前記少なくとも１つのタイプの情報がバックログレベル情報及びＱｏＳ情報を含む場合に、前記第１のフォーマットを使用するように構成される請求項２０記載の装置。
22. 前記複数のフォーマットは前記バックログレベル情報のみのための第２のフォーマットをさらに含み、前記少なくとも１つのタイプの情報が前記バックログレベル情報のみを含む場合に、前記少なくとも１つのプロセッサは第２のフォーマットを使用するように構成される請求項２１記載の装置。
23. 前記少なくとも１つのプロセッサは、リソースリクエストが特定のストリームについてのものである場合に第１のフォーマットを使用するように構成され、リソースリクエストが複数のストリームについてのものである場合に第２のフォーマットを使用するように構成される請求項２２記載の装置。
24. 前記少なくとも１つのプロセッサは、ＱｏＳ情報に関連したストリームについて第１のフォーマットを使用し、ＱｏＳ情報に関連しないストリーム或いは変化するＱｏＳ情報を備えた複数のストリームについて第２のフォーマットを使用するように構成された請求項２２記載の装置。
25. 前記リソースリクエストは複数のフォーマットの全てについての固定ビット数を含む請求項２０記載の装置。
26. 前記第１のフォーマットは第１の範囲の値に相当し、前記第２のフォーマットは前記リソースリクエストについての第２の範囲の値に相当する請求項２２記載の装置。
27. 前記リソースリクエストは６ビットを含み、前記第１のフォーマットは０から４７までの第１の範囲に対応し、前記第２のフォーマットは４８から６３までの第２の範囲に対応する請求項２２の装置。
28. リソースリクエストで送る少なくとも１つのタイプの情報を決定し、
    送る少なくとも１つのタイプの情報に基づいて複数のフォーマットの中からのリソースリクエストに使用するためのフォーマットを決定し、
    前記決定されたフォーマットにおいて少なくとも１つのタイプの情報を含むリソースリクエストを生成する無線通信のための方法。
29. 前記複数のフォーマットは、送信するデータの量を示すバックログレベル情報及びサービス品質（ＱｏＳ）情報についての第１のフォーマットを含み、前記フォーマットを決定することは、前記少なくとも１つのタイプの情報が前記バックログレベル情報及びＱｏＳ情報を含む場合に第１のフォーマットを使用することを含む請求項２８の方法。
30. 前記複数のフォーマットはう前記バックログレベル情報のみのための第２のフォーマットをさらに含み、前記フォーマットを決定することは、前記少なくとも１つのタイプの情報がバックログレベル情報のみを含む場合に、第２のフォーマットを使用することを含む請求項２９記載の方法。
31. 前記リソースリクエストを生成することは、前記第１のフォーマットについての第１の範囲の値の範囲内及び前記第２のフォーマットについての第２の範囲の値の範囲内でリソースリクエストについての値を決定することを含む請求項２９記載の方法。
32. 送るデータのためのサービス品質（ＱｏＳ）クラス情報或いは待ち時間デッドライン情報を決定し、前記送るデータの量を示すバックログレベル情報を決定し、前記第１のフィールドにおいてバックログレベル情報及び前記第２のフィールドにおいてＱｏＳクラス情報或いは待ち時間デッドライン情報を含むリソースリクエストを生成する少なくとも１つのプロセッサと、
    前記少なくとも１つのプロセッサに接続されたメモリとを具備し、
    前記送るデータのためのサービス品質（ＱｏＳ）クラス情報或いは待ち時間デッドライン情報は、リソースリクエストの複数のコンフィグレーションの中から選択されたリソースリクエストのコンフィグレーションに基づいて決定される、無線通信のための装置。
33. 前記少なくとも１つのプロセッサは、前記ＱｏＳクラス情報を前記第２のフィールドについての第１の範囲の値にマップし、或いは待ち時間デッドラインを前記第２のフィールドについての第２の範囲の値にマップするように構成される請求項３２記載の装置。
34. 前記第２のフィールドは３ビットを含み、前記少なくとも１つのプロセッサはＱｏＳクラス情報を前記第２のフィールドについての４つの可能な値のうちの１つにマップする或いは待ち時間デッドライン情報を前記第２のフィールドについての４つの異なる可能な値のうちの１つにマップするように構成される請求項３２記載の装置。
35. 前記少なくとも１つのプロセッサは、前記送るデータが属する少なくとも１つのストリームを識別し、前記少なくとも１つのストリームがＱｏＳクラスか待ち時間デッドラインに関係しているかどうか決定し、ＱｏＳクラスに関係していた場合に少なくとも１つのストリームについてのＱｏＳクラス情報を決定し、待ち時間デッドラインに関係していた場合に少なくとも１つのストリームについての待ち時間デッドライン情報を決定するように構成されている請求項３２記載の装置。
36. 送るデータのためのサービス品質（ＱｏＳ）クラス情報或いは待ち時間デッドライン情報を決定し、
    前記送るデータの量を示すバックログレベル情報を決定し、
    前記第１のフィールドにおいてバックログレベル情報及び前記第２のフィールドにおいてＱｏＳクラス情報或いは待ち時間デッドライン情報を含むリソースリクエストを生成し、
    前記送るデータのためのサービス品質（ＱｏＳ）クラス情報或いは待ち時間デッドライン情報は、リソースリクエストの複数のコンフィグレーションの中から選択されたリソースリクエストのコンフィグレーションに基づいて決定される、無線通信のための方法。
37. 前記リソースリクエストを生成することは、
    前記ＱｏＳクラス情報を前記第２のフィールドについての第１の範囲の値にマップし、或いは待ち時間デッドラインを前記第２のフィールドについての第２の範囲の値にマップする請求項３６記載の方法。
38. 前記第２のフィールドは３ビットを含み、前記リソースリクエストを生成することは、ＱｏＳクラス情報を前記第２のフィールドについての４つの可能な値のうちの１つにマップする或いは待ち時間デッドライン情報を前記第２のフィールドについての４つの異なる可能な値のうちの１つにマップすることを含む請求項３６記載の方法。
39. 前記ＱｏＳクラス情報或いは前記待ち時間デッドライン情報を決定することは、
    前記送るデータが属する少なくとも１つのストリームを識別し、
    前記少なくとも１つのストリームがＱｏＳクラスか待ち時間デッドラインに関係しているかどうか決定し、
    ＱｏＳクラスに関係していた場合に少なくとも１つのストリームについてのＱｏＳクラス情報を決定し、
    待ち時間デッドラインに関係していた場合に少なくとも１つのストリームについての待ち時間デッドライン情報を決定することを含む請求項３６記載の方法。
40. 送信するデータの量及びスペクトル効率に基づいてバックログレベル情報を決定し、前記バックログレベル情報を有するリソースリクエストを生成するように構成された少なくとも１つのプロセッサと、
    前記少なくとも１つのプロセッサに接続されたメモリと
    を具備し、
    前記バックログレベル情報は、リソースリクエストの複数のコンフィグレーションの中から選択されたリソースリクエストのコンフィグレーションに基づいて決定される、無線通信のための装置。
41. 前記少なくとも１つのプロセッサは、最も最近のリソース割り当てに基づいてスペクトル効率を決定するように構成されている請求項４０記載の装置。
42. 前記少なくとも１つのプロセッサは、前記スペクトル効率によってスケールされた異なるバイト数に対応する複数のバックログレベル値のうちの１つを選択し、前記選択されたバックログレベル値を含むリソースリクエストを生成するように構成されている請求項４０記載の装置。
43. 前記少なくとも１つのプロセッサは、前記スペクトル効率が閾値よりも大きい場合に、前記スペクトル効率によってスケールされた異なるバイト数に対応する複数のバックログレベル値のうちの１つを選択し、前記スペクトル効率が閾値以下の場合に、異なるバイト数に対応する複数のバックログレベル値のうちの１つを選択するように構成されている請求項４０記載の装置。
44. 前記少なくとも１つのプロセッサは、前記スペクトル効率に基づいて各複数のバックログレベル値についてのタイル数を決定し、送るデータの量に基づいて複数のバックログレベル値のうちの１つを選択するように構成される請求項４０記載の装置。
45. 送信するデータの量及びスペクトル効率に基づいてバックログレベル情報を決定し、
    前記バックログレベル情報を有するリソースリクエストを生成し、
    前記バックログレベル情報は、リソースリクエストの複数のコンフィグレーションの中から選択されたリソースリクエストのコンフィグレーションに基づいて決定される、無線通信のための方法。
46. 前記バックログレベル情報を決定することは、前記スペクトル効率によってスケールされた異なるバイト数に対応する複数のバックログレベル値のうちの１つを選択し、前記リソースリクエストを生成することは、前記選択されたバックログレベル値を含むリソースリクエストを生成することを含む請求項４５記載の方法。
47. 前記バックログレベル情報を決定することは、前記スペクトル効率が閾値よりも大きい場合に、前記スペクトル効率によってスケールされた異なるバイト数に対応する複数のバックログレベル値のうちの１つを選択し、前記スペクトル効率が閾値以下の場合に、異なるバイト数に対応する複数のバックログレベル値のうちの１つを選択することを含み、前記リソースリクエストを生成することは、前記選択されたバックログレベル値を含む前記リソースリクエストを生成する請求項４５記載の方法。

Images