JP2012525786A - Ｈａｒｑバッファ管理および無線システム用のフィードバック設計 - Google Patents

Abstract

【解決手段】 ＨＡＲＱバッファ管理を実行する方法を開示する。当該ＨＡＲＱバッファ管理方法は、基地局ではなく移動局に、移動局のバッファのサイズを制御させる新しいバッファオーバーフロー管理方法である。当該ＨＡＲＱバッファ管理では、バッファサイズ、バッファ使用率ステータス、および、バッファオーバーフローを基地局に報告して、基地局と移動局との間で効率よく通信が行われるようにする。
【選択図】 図１

Description

本願は、高度無線インターフェース規格でのハイブリッド自動再送要求（ＨＡＲＱ）バッファ管理に関する。

ＩＥＥＥ８０２．１６は、米国電気電子学会（ＩＥＥＥ）が公表している一連の無線放送規格である。ＩＥＥＥ８０２．１６ｍは、高度な無線インターフェース規格として知られている。ハイブリッド自動再送要求（ＨＡＲＱ）は、現在の技術水準に応じた無線通信規格では広くサポートされている。自動再送要求（ＡＲＱ）の場合には、送信前にエラー検出情報をデータに追加して、受信機がデータを復号できるようにする。ＨＡＲＱの場合には、さらに前方誤り訂正（ＦＥＣ）ビットをデータに追加する。

無線通信規格には、米国電気電子学会（ＩＥＥＥ）が定めたものがあり、例えば、８０２．１６ｅ（ブロードバンド無線アクセス）および８０２．１６ｍ（高度無線インターフェース規格）がある。本明細書では、ＩＥＥＥ８０２．１６ｅは「８０２．１６ｅ」または「ブロードバンド無線アクセス規格」と呼び、ＩＥＥＥ８０２．１６ｍは「８０２．１６ｍ」または「高度無線インターフェース規格」と呼ぶ。

またこの規格では、最多で６ビットの情報をサポートする主要高速フィードバックチャネル（ＰＦＢＣＨ）と、最多で２４ビットの情報をサポートする副次高速フィードバックチャネル（ＳＦＢＣＨ）という２種類のアップリンク高速フィードバックチャネルがある。ＳＦＢＣＨは本来、最高でＰＦＢＣＨの３倍を格納することができる。ＰＦＢＣＨあるいはＳＦＢＣＨの一方が利用可能であるか、または、両方の高速フィードバックチャネルが利用可能であるかは、基準によって変わる。

実際に実施する場合には、移動局が、ＨＡＲＱバッファとして知られているバッファに、正確に復号されなかったバーストからの情報を格納する。このバッファは、サイズが限られており、満杯の場合にはさらなるバーストは格納することはできない。このバッファのサイズおよび管理方式は、移動局の最大スループットおよびＨＡＲＱの性能に影響を与える。８０２．１６ｍでサポートしているトラフィックレートに対処するためには大容量のバッファが必要となるので、バッファ管理方式は、バッファの利用とＨＡＲＱの性能との間でバランスを取らなければならない。

本明細書の上述した側面およびそれらに付随する多くの利点は、添付図面と共に以下に記載する詳細な説明を参照することによってより深く理解されることでより容易に認められるであろう。添付図面では、特に明記していない限り、同様の参照番号は、複数の図面にわたって同様の構成要素に割り当てられる。
一部の実施形態に係る、ＨＡＲＱバッファ管理方法を示す概略図である。 一部の実施形態においてどのように移動局が基地局から受信したブロックをバッファするかを説明するための概略図である。 一部の実施形態においてどのように基地局が移動局のバッファサイズの記録を取るのかを説明するための概略図である。 一部の実施形態において、各送信の失敗の確率が０．３であると仮定して、１６回の試行でｘ回失敗した場合にバッファが完全に満杯になる確率を説明するためのグラフである。 一部の実施形態に係る、移動局がバッファのサイズを大きくする４つの方法を説明するための図である。 一部の実施形態に係る、図１のＨＡＲＱバッファ管理方法を用いて基地局にＨＡＲＱバッファステータスを報告するために定義されているコードワードシーケンスの例を示す表である。 一部の実施形態に係る、図１のＨＡＲＱバッファ管理方法においてバッファオーバーフロー、バッファ使用率ステータスおよびバッファサイズを報告するチャネルの例を示す表である。

本明細書に記載する実施形態に従って、ＨＡＲＱバッファ管理を実行する方法を開示する。本発明に係るＨＡＲＱバッファ管理によれば、基地局ではなく移動局が、自身が備えるバッファのサイズを制御することができるようになる。本発明に係るＨＡＲＱバッファ管理によると、バッファオーバーフロー、バッファ使用率ステータスおよびバッファサイズを基地局に報告して、基地局と移動局との間の通信を効率化する。

図１は、一部の実施形態に係るＨＡＲＱバッファ管理方法１００を示すブロック図である。ＨＡＲＱバッファ管理方法１００は、バッファオーバーフロー管理およびバッファ使用率フィードバック報告を含む。ＨＡＲＱバッファ管理方法１００は、バッファオーバーフロー３０、バッファ使用率４０、および、バッファサイズ５０を、移動局６０から基地局７０へと報告する。ＨＡＲＱバッファ管理方法１００の処理は、以下でより詳細に説明する。

移動局６０は、ＨＡＲＱバッファ２００を含む。基地局７０は複数のブロックで符号化データを送信するので、移動局６０は全ブロックを基地局から受信するまで一部のブロックを格納しておく。この後、移動局６０は全ブロックを共に復号する。ある１つのブロックがエラー送信されると、エラー送信されたブロックについて、移動局６０は基地局７０からの再送を要求する。

一部の実施形態に係る上記の処理の概略を図２に示す。図２によると、データ送信は、４つの別個のブロック８０_Ａ、８０_Ｂ、８０_Ｃ、および８０_Ｄ（「ブロック８０」と総称する）から構成される。または、さまざまなサイズの部分送信から構成される。ブロック８０は、移動局６０に送信される前に基地局７０で符号化される。４つのブロックのうち、８０_Ａ、８０_Ｂおよび８０_Ｄの３ブロックは、基地局７０への送信に成功し、移動局６０は、このように成功した送信についてはそれぞれについて基地局に確認応答（「ＡＣＫ」）を送信する。しかし、ブロック８０_Ｃはエラー送信されてしまう。移動局６０は、基地局７０にブロック８０_Ｃの再送を通知する否定確認応答（「ＮＡＣＫ」）を送信する。このため、基地局７０は、移動局にブロック８０_Ｃを再送し、この後、移動局６０は、送信が成功したことを認める。

移動局６０に設けられているＨＡＲＱバッファ２００は、ブロック８０を基地局７０から受信すると、ブロック８０を格納する。図２では、ＨＡＲＱバッファ２００は先入れ先出し（ＦＩＦＯ）メモリバッファであるが、移動局はその他の種類のバッファストレージを利用するとしてもよい。４ブロックから成るデータ送信は、元のデータ送信の全ブロック８０を受信するまでは、復号されない。このように、ＨＡＲＱバッファ２００は、受信に成功した送信のうち一部（ブロック８０_Ａ、８０_Ｂおよび８０_Ｄ）を、全ブロックを受信する（ブロック８０_Ｃ）まで、保存しておく。この後、移動局６０はデータを復号することができる。

図２は、ＨＡＲＱバッファ２００の利用原理を概略的に示す図である。送信されるブロック８０のために利用可能なストレージがある限り、移動局６０は、ブロックがエラー送信された場合には、再送を要求するだけでよい（「ＮＡＣＫ」）。再送が必要になる別の場合として、バッファ２００がオーバーフローして、移動局６０が部分送信を格納できなくなる場合がある。ＨＡＲＱバッファ２００は、データが満杯でさらにデータを格納できない場合に、オーバーフローしたと認められる。バッファ２００が基地局７０から受信したブロック８０を格納できるようになる（オーバーフローしていない状態になる）まで、移動局６０は再送を要求しなければならない。

移動局６０において十分なサイズのバッファを利用できるか否かは、移動局と基地局７０との間の送信のスループットに直接関係する。ＨＡＲＱバッファ２００のサイズ（ＨＡＲＱバッファサイズ５０と呼ぶ）が非常に小さいと、バッファはすぐに満杯になり、移動局６０は基地局７０からの再送を要求する。このため従来は、基地局７０が移動局６０のＨＡＲＱバッファ２００を制御するという従来からのやり方でバッファを管理していた。

ＨＡＲＱバッファ管理方法１００は、従来のバッファ管理方法とは異なるやり方を採用する。一部の実施形態によると、ＨＡＲＱバッファ管理方法１００ではバッファサイズの制御を移動局６０で行い、移動局６０は基地局７０に対して、移動局へのデータ送信をインテリジェントに行うために十分な程度の、ＨＡＲＱバッファ２００のステータス情報を供給する。

＜バッファオーバーフロー管理＞
本明細書で用いる場合、「バッファオーバーフロー」とは、ＨＡＲＱバッファ２００が処理可能な量を超えて（復号エラーが発生した）データをＨＡＲＱバッファ２００で受信することと定義される。バッファオーバーフローが発生すると、ＨＡＲＱの性能が劣化してしまう。言い換えると、基地局７０と移動局６０との間の送信のスループットは、ＨＡＲＱバッファ２００でオーバーフローが発生すると、低下してしまう。

このスループットの問題は、２つの理由によりインクリメンタル・リダンダンシ（Ｉｎｃｒｅｍｅｎｔａｌ Ｒｅｄｕｎｄａｎｃｙ）ＨＡＲＱ（ＩＲ−ＨＡＲＱまたはＨＡＲＱ−ＩＲ）および適応型ＨＡＲＱの場合に、より深刻になる。第一に、ＨＡＲＱ−ＩＲでは、再送はパリティビットのみを含む場合がある。チャネル・ツー・チャネル（ＣＴＣ）復号器の性能は、システマティックビット（組織部）に格納されている初期情報がないと、好ましくないレベルになってしまう。また、場合によっては、ノイズがない場合であっても（ＳＮＲ→∞）、元の送信を利用しないことには再送を復号することは不可能である。また、適応型ＨＡＲＱでは、復号に必要な状の大半は前回の送信で受信されていると仮定して、再送のサイズは非常に小さい場合がある。

したがって、一部の実施形態によると、ＨＡＲＱバッファ管理方法１００では、ＨＡＲＱバッファ２００のオーバーフローは、移動局６０へのデータ送信を管理する基地局のスケジューラによって管理される。移動局６０は、ＨＡＲＱバッファサイズ５０を基地局７０に報告して、この後基地局は（次にＨＡＲＱバッファサイズが報告されるまで）移動局のバッファ２００における使用率レベルの記録を取る。基地局７０は、バッファサイズ５０を取得し、移動局６０への送信の記録を取ることによって、一部の実施形態では、スループットが改善するように移動局６０へのデータ送信を制御する。

図３は、一部の実施形態に係る、ＨＡＲＱバッファ管理方法１００でのバッファオーバーフロー管理を示す概略図である。移動局６０は、基地局７０にＨＡＲＱバッファサイズ５０を報告する。基地局７０は、さまざまなデータおよび基地局が実行する処理の記録を取るスケジューラ３００を備える。データとしては、基地局がサービスを提供する各移動局に関するデータが含まれる。スケジューラ３００はさらに、ＨＡＲＱバッファ２００のサイズに影響を及ぼす移動局６０へのデータ送信の記録を取るプロセッサ９０を有する。（プロセッサ９０は、移動局への送信の記録を取る単純な構成のカウンタまたはタイマであってもよい。）移動局６０は基地局７０（「サービス提供基地局」と呼ぶ）からの送信を受信するのみであるので、基地局は、最初にサイズ情報（バッファサイズ５０）を移動局６０から取得して、ＨＡＲＱバッファ２００が満杯か空かに関係してくる、基地局から移動局への送信の記録を取ることによって、ＨＡＲＱバッファ２００のサイズの記録を取ることができる。一部の実施形態によると、移動局６０は、バッファサイズ５０を基地局７０に定期的に送信する。移動局６０がバッファサイズ５０を基地局７０に送信する度に、スケジューラ３００はプロセッサ９０を再開させる。

＜最大スループットおよびＨＡＲＱバッファ使用率＞
オーバーフローを回避する従来のバッファ管理方式では、所与のＨＡＲＱバッファサイズで移動局６０が実現可能な最大スループットが制限されている。高度無線インターフェース規格（８０２．１６ｍ）の目的の１つに、２×２のＭＩＭＯ（多入力多出力方式）で２０ＭＨｚの帯域幅について約１８０Ｍｂｉｔ／秒という高スループットのトラフィックをサポートする点がある。モバイル・ブロードバンド・無線規格（８０２．１６ｅ）で利用されていたような従来の設計は、８０２．１６ｍに利用され得るが、上記のようなスループットをサポートするためには、以下の計算式で示されるような大型のバッファを利用する可能性がある。しかし、大型のバッファは、移動局のコストが増加してしまい、１００％利用されていない場合には非効率になってしまう。

サポートされ得る最大スループットは以下の式で表される。

式中、Ｒ_ｍａｘは最大符号レート（例えば、５／６）であり、ＲＴＴ（ラウンドトリップ時間）はある送信とその再送または新規送信との間の時間である。新規送信は、８０２．１６ｍにおいて、受信機処理時間、（否定）確認応答チャネル信号伝達、および、再送／新規送信のスケジューリングを含み、少なくとも１サブフレーム（５ｍｓ）で、数１の「バッファサイズ」はバッファ内のソフトビットまたはメトリックの数である。

このようにスループットに対する制限が大きくなる理由は、基地局７０が、バーストが受信され正しく復号され、新規情報を受信する余裕がある旨の確認応答を受信する前には、移動局６０のバッファサイズ以上の符号化ビットを送信することはできないためである。

このような最悪状況方式では、（制御信号伝達でエラーが発生しない限り）ＨＡＲＱバッファでオーバーフローは決して発生しないことが保証される。しかし、実際には、この方式ではバッファ機能を上手く利用できていない。１フレーム中の情報を同サイズの１６個のバーストに分割すると仮定する。尚、バースト毎にＨＡＲＱチャネルが異なり、各バーストのエラー確率は０．３であり、エラー確率はバースト同士で依存しない。フレームの終端までにバッファが満杯になる確率は、４＊１０^−９と小さい。このことから、移動局６０にさらに情報を送信してもエラー確率を無視できる程度に抑えられたと分かる。図４は、各送信の失敗の確率は０．３であると仮定して、１６回の試行でｘ回失敗する場合にバッファが満杯になる確率を示すグラフである（０≦ｘ≦１６）。図４によると、確率を１０−２とすると、最大でバッファの半分（バースト８個）がフレーム終端時点において利用されることになる。

オーバーフローを回避するための従来のバッファ管理プロトコルでは、リソースを浪費しており、最大ユーザスループットに制限がある。このため、基地局７０は、報告されている移動局のバッファサイズより多くの情報を送信して、移動局６０のバッファを酷使する可能性があり、（バッファでオーバーフローを発生させない）１フレーム中の失敗の最大回数について統計的仮定を利用する。しかし、バッファを酷使しているか否かの統計的仮定は、移動局のバッファの管理に左右される。

基地局７０がＨＡＲＱバッファ２００のサイズを制御する先行技術とは対照的に、ＨＡＲＱバッファ管理方法１００では、移動局６０が自身のバッファサイズを制御できるようになり、増減が可能であるので、バッファの利用を高効率化することができる。

一部の実施形態によると、ＨＡＲＱバッファ管理方法１００によれば、移動局６０がバッファサイズ５０を拡大する方法は幾つか考えられる。一部の実施形態で選択肢として挙げられるものを図５に概略的に示す。バッファ２００から排除される項目を点線で示す。例えば、移動局６０は、バッファ２００から、正しく復号された前方誤り訂正（ＦＥＣ）ブロック８２を退避させるとしてよい。前方誤り訂正符号化では、巡回冗長検査（ＣＲＣ）ビットまたはチェックサムビット等の誤り検出ビットと同様に「データビット」を符号化する。このように、ＦＥＣ符号化では送信するビット数が増加する。例えば、符号レートが１／２の場合、２００個の「符号化ビット」によって１００個の「データビット」が送信される。符号化ビットは、移動局６０での復調によって取得され、エラーが多く発生することが多い。符号化ビットは、「メトリック」として保存され、各メトリックは、送信された符号化ビットの推定値をその信頼性と共に表す。例えば、メトリック「∞」は符号化ビットが確実に「０」であることを意味し、メトリック「−∞」は符号化ビットが確実に「１」であることを意味する。メトリック「０」は、符号化ビットが等しい確率で「１」または「０」であることを意味する。このようなメトリックは、「ソフトビット」と呼ばれることもある。メトリックは、量子化されて保存され、一例を挙げると、８ビットとなる。

例えば、データビットが１００個で符号レートが１／２の場合、移動局６０は、１００を１／２で除算した商、つまり２００個のソフトビット（符号化ビット毎に１つ）を保存する必要があり、バッファ２００において２００に８を乗算した積、つまり１６００個のビットが必要となる（今回の復号化およびＨＡＲＱ合成のためである）。しかし、バッファ２００にデータビットのみを格納する場合、バッファ内で必要な空間は１００ビットのみとなる。また、データビットが誤り検出ビット（例えば、ＣＲＣビット）を含む場合、誤り検出ビットを保存する必要はないが、保存したとしても非常に小さい。

これに代えて、移動局６０はバッファオーバーフロー・イベントをスマート方式で処理するとしてよく、例えば、図５に示すように、バッファオーバーフローハンドラ２１０を利用して、より多くのバッファリソースをオンザフライで割り当てるとしてよい。一部の実施形態によると、バッファオーバーフローハンドラ２１０は、バッファオーバーフローのために、または、バッファ２００が満杯で、移動局６０が停止してしまいリセットする必要がある場合に、呼び出される。または、バッファオーバーフローハンドラ２１０は、順不同または何らかの基準に基づいて古い送信を退避させることによって、バッファ２００で常に、新規送信を復号する余裕が確実にあるようにするとしてもよい。例えば、バッファ２００は最も古い送信を最初に削除するとしてよい（ＦＩＦＯバッファ）。これは、基地局７０はそれより古いデータを再送することはないためである。

より高度な方法では、バッファオーバーフローハンドラ２１０は、パリティソフトビットのみを退避させて、システマティックビットのメトリックを保存するように試みるとしてよい。システマティックビットは、他のビットよりも復号器の性能にとってより重要な符号化ビットである。このため、システマティックビットの前に他のビットを退避させるのは理に適っている。別の選択肢としては、バッファオーバーフローハンドラ２１０は、各メトリックを保存するためのビットを減らすとしてよい。例えば、１メトリック毎に８ビットではなく、１メトリック毎に２ビットとして、バッファ２００内で空き空間を増やすとしてよい。上記のような選択肢は、性能（ＨＡＲＱ合成ゲイン）と、バッファサイズの制限との間で均衡を取るための方法である。

さらに別の選択肢として、移動局６０は、マザー符号化ビット８４のバッファ空間を確保せずに、実際に受信した符号化ビット８６のみについてメトリックを保存するとしてよい。インクリメンタル・リダンダンシＨＡＲＱでは、再送で新規の符号化ビットが送信されてくるので、再送後にはバッファサイズを大きくする必要がある。単純な実施例では、最初の送信を受信する時に、後続の送信の全てを受信するのに十分なバッファサイズを割り当てる。バッファのサイズは、最小有効符号レートまたは「マザー符号レート」に応じて決まる。８０２．１６ｍに準拠したシステムでは、マザー符号レートは１／３で、送信の実際の符号レートは、例えば、１／２または５／６であり、大幅に小さいバッファを利用する。ＨＡＲＱバッファ管理方法１００では、マザー符号ビット８４、つまり、再送で用いられる新規に符号化されたビットは、先行技術とは異なり、ＨＡＲＱバッファ２００には格納されない。

または、移動局６０は、バッファサイズのために性能を犠牲にするとしてもよい（受信した情報を不可逆的に圧縮する）。

上記に列挙した内容から分かるように、移動局の内部バッファ管理を完全に標準化するのは困難であり望ましくないとしてよい。例えば、バッファ２００から基地局７０にＦＥＣブロック８２を除去することを完全に仕様に含めるには、移動局６０は、ソフトビットバッファのサイズ、復号ビットバッファのサイズ、および、正しく受信したブロックを基地局に退避させる際の遅延に関するパラメータを報告する必要がある。基地局７０は、この情報を取得したとしても、送信時の最大トラフィックを決定するために十分な情報を持たない。これは、上記のバッファの利用は最終的にはチャネルの挙動によって変わるためである。

したがって、ＨＡＲＱバッファ管理方法１００は別のやり方で実行される。移動局内部バッファ管理は、基地局７０には明らかにされない。そうではなく、基地局７０は、基地局７０がトラフィックレートを管理できるようにするメトリックを移動局６０から受信する。このメトリックは、チャネル挙動および具体的な移動局の実施例も網羅する。

一部の実施形態によると、ＨＡＲＱバッファ管理方法１００では、移動局６０は、十分に検討した上でＨＡＲＱバッファ２００にビットを格納する。受信したビットの中に正しく復号されるものもあれば復号できないものもある場合、ＨＡＲＱ再送が開始される。先行技術では、ソフトビットは全て、ＨＡＲＱ再送と合成するべく、バッファ２００に保存される。ＨＡＲＱバッファ管理方法１００では、移動局６０は、正しく復号されたＦＥＣブロックはデータビットとして保存するが、符号化ソフトビットはバッファ２００から別の場所に退避させられる。正しく復号されなかったＦＥＣブロックのみが、ソフトビットとして保存される。

＜バッファ使用率フィードバック＞
基地局７０がＨＡＲＱバッファ２００を最適に利用できるように、ＨＡＲＱバッファ管理方法１００では、図１に示すように、移動局６０から基地局７０までのフィードバックとして２種類を利用する。最初に、ＨＡＲＱバッファサイズ５０が移動局６０から基地局へと報告される。一部の実施形態によると、移動局６０は、ＨＡＲＱバッファ２００に格納可能な符号化ソフトビット数を機能として報告する。また、バッファ使用率通知４０が、移動局６０から基地局７０へと報告される。バッファ使用率４０は、バッファ利用効率の評価基準である。一部の実施形態によると、バッファ使用率４０は、要求時（要求に応じて）または周期的に、基地局７０に報告される。

＜要求に応じてバッファ使用率をフィードバックで報告するメカニズム＞
ＨＡＲＱバッファオーバーフローは不定期に発生するので、バッファ管理に関する情報は要求に応じてフィードバックする方がより効率的である。ＨＡＲＱバッファ管理方法１００では、一部の実施形態によると、２種類のステータスを報告する。バッファ使用率４０については、割合しきい値ＢｕｆＴｈｒが予め定められている。バッファ使用率４０がＢｕｆＴｈｒしきい値を超えると、移動局６０は基地局７０に通知を送信する。

例えば、バッファしきい値ＢｕｆＴｈｒが４０％であると仮定する。バッファ使用率４０が４０％を超えると（つまり、バッファ２００の少なくとも４０％が利用されているか、またはデータで埋まっている場合）、移動局６０は基地局７０に通知する。この通知は、一部の実施形態によると、１ビットで行うことが可能である。バッファ使用率４０が４０％未満である間は、通知は送信されない。

第二に、ＨＡＲＱバッファ管理方法１００は、基地局７０にバッファオーバーフロー情報３０をフィードバックする。この場合、移動局６０は、最後に報告されてからＨＡＲＱバッファ２００でオーバーフローが発生すると基地局７０に通知を送信する。

上述したバッファ使用率４０およびバッファサイズ５０を要求に応じて報告する方法としてはさまざまなものが考えられる。一部の実施形態によると、ＨＡＲＱバッファ管理方法１００では、要求に応じてバッファ使用率４０およびオーバーフロー通知をフィードバックするために主要高速フィードバックチャネル（ＰＦＢＣＨ）を利用し、ＰＦＢＣＨ内の２つのコードワードを確保する。一方のコードワードはバッファ使用率を表し、他方のコードワードで要求に応じてバッファオーバーフローを表す。

図６は、一部の実施形態に係る、ＨＡＲＱバッファ管理方法１００においてＰＦＢＣＨを用いてバッファオーバーフロー３０およびバッファ使用率４０を報告するためのコードワードシーケンスを示す表２４である。シーケンスの中には、チャネル品質指標（ＣＱＩ）の報告のために確保されているものある。「Ｘ＋１」および「Ｘ＋２」と表されている２つのコードワードは、移動局６０が基地局７０にバッファ情報を報告するために利用されると定義されている。コードワード「Ｘ＋１」は、バッファ使用率４０を示し、バッファ２００が所定のしきい値ＢｕｆＴｈｒを超えているか否かを示す。コードワード「Ｘ＋２」は、基地局７０に、ＨＡＲＱバッファ２００のオーバーフロー（バッファオーバーフロー３０）を通知する。

別の選択肢によると、帯域幅要求チャネル（ＢＷＲＣＨ）を用いて、要求に応じてバッファオーバーフロー３０およびバッファ使用率４０を示す１ビットのメッセージを送信するとしてもよい。このため、これらのバッファステータス指標のそれぞれについて、表２４（図６）で定義されているコードワードに代えて、１ビットを定義するとしてよい。さらに、副次高速フィードバックチャネル（ＳＦＢＣＨ）を用いてバッファサイズ５０をフィードバックするとしてよい。図７は、このデータを移動局６０が基地局７０に報告する際のさまざまな方法を示す表である。

このように、バッファサイズ５０、バッファオーバーフロー指標３０、バッファ使用率ステータス４０は、ＰＦＢＣＨ、ＳＦＢＣＨ、ＢＷＲＣＨ等のアップリンクフィードバックチャネルまたはその他のチャネルを用いて報告されるとしてよい。さらに他の実施形態によると、バッファサイズ５０、バッファオーバーフロー指標３０、バッファ使用率ステータス４０は、ＬＴＥ（ロング・ターム・エボリューション）システムにおける物理アップリンク制御チャネル（ＰＵＣＣＨ）等の１種類のフィードバックチャネルを用いて報告するとしてもよい。

限られた数の実施形態を参照しつつ本願を説明してきたが、当業者であれば、上記の記載から数多くの変形例および変更例に想到するであろう。請求項は、このような変形例および変更例を全て、本発明の真の意図および範囲に含まれるものとして、包含するものである。

Claims (20)

1. ハイブリッド自動再送要求（ＨＡＲＱ）バッファを管理する方法であって、
   前記ＨＡＲＱバッファのサイズを示すバッファサイズを基地局に送信する段階と、
   前記ＨＡＲＱバッファでオーバーフローが発生すると、バッファオーバーフロー指標を前記基地局に送信する段階と、
   前記基地局から何も入力されることなく前記ＨＡＲＱバッファのサイズを管理する段階と
   を備え、
   前記バッファサイズは前記ＨＡＲＱバッファのサイズが変化すると送信される方法。
2. 前記ＨＡＲＱバッファの使用率が所定のしきい値を超えると、バッファ使用率通知を前記基地局に送信する段階をさらに備える請求項１に記載の方法。
3. 前記バッファサイズを基地局に送信する段階はさらに、前記バッファサイズを副次高速フィードバックチャネルで前記基地局に送信する段階を有する請求項１に記載の方法。
4. 前記バッファ使用率通知を前記基地局に送信する段階はさらに、主要高速フィードバックチャネルを用いてコードワードとして、前記バッファ使用率通知を前記基地局に送信する段階を含む請求項２に記載の方法。
5. 前記バッファ使用率通知を前記基地局に送信する段階はさらに、帯域幅要求チャネルを用いてビットとして、前記バッファ使用率通知を送信する段階を含む請求項２に記載の方法。
6. 主要高速フィードバックチャネルを用いてコードワードとして、前記バッファ使用率通知および前記バッファオーバーフロー指標を前記基地局に送信する段階をさらに備える請求項２に記載の方法。
7. アップリンクフィードバックチャネルを用いて、前記バッファサイズ、前記バッファ使用率通知、および、前記バッファオーバーフロー指標を送信する段階をさらに備える請求項２に記載の方法。
8. 前記基地局から何も入力されることなく前記ＨＡＲＱバッファのサイズを管理する段階はさらに、正しく復号された前方誤り訂正ブロックを前記ＨＡＲＱバッファから退避させる段階を有する請求項１に記載の方法。
9. 前記基地局から何も入力されることなく前記ＨＡＲＱバッファのサイズを管理する段階はさらに、
   ソフトパリティビットを前記ＨＡＲＱバッファから退避させる段階と、
   復号器の性能に良い影響を与えるシステマティックビットを前記ＨＡＲＱバッファに格納する段階と
   を有する請求項１に記載の方法。
10. 前記基地局から何も入力されることなく前記ＨＡＲＱバッファのサイズを管理する段階はさらに、前記ＨＡＲＱバッファにはマザー符号化ビットは格納しない段階を有する請求項１に記載の方法。
11. 前記基地局から何も入力されることなく前記ＨＡＲＱバッファのサイズを管理する段階はさらに、
    前記基地局から受信した一部のブロックを、利用するメモリビットの数を少なくしつつＨＡＲＱ合成ゲインが可能となるような方法で圧縮された状態で前記ＨＡＲＱバッファに格納する段階と、
    前記基地局から受信したその他のブロックを、前記ＨＡＲＱバッファに格納しない段階と
    を有し、
    格納された前記ブロックは、前記基地局から送信されたデータを一部を損失した状態で復号するのに十分である請求項１に記載の方法。
12. ハイブリッド自動再送要求（ＨＡＲＱ）バッファを管理する方法であって、
    移動局内に設けられている前記ＨＡＲＱバッファのサイズを示すバッファサイズを前記移動局から受信する段階と、
    前記ＨＡＲＱバッファでオーバーフローが発生すると、バッファオーバーフロー指標を前記移動局から受信する段階と、
    前記ＨＡＲＱバッファを管理することなく前記移動局に対するトラフィックレートを管理する段階と
    を備え、
    前記バッファサイズは、前記ＨＡＲＱバッファのサイズが変化した場合に受信する方法。
13. 前記ＨＡＲＱバッファの使用率が所定のしきい値を超えると、バッファ使用率通知を前記移動局から受信する段階をさらに備える請求項１２に記載の方法。
14. 前記バッファサイズを前記移動局から受信する段階はさらに、最大２４ビットを持つ副次高速フィードバックチャネルからバッファサイズを受信する段階を有する請求項１２に記載の方法。
15. 前記バッファオーバーフロー指標および前記バッファ使用率通知を、主要高速フィードバックチャネルのコードワードとして受信する段階をさらに備える請求項１３に記載の方法。
16. 前記バッファオーバーフロー指標を帯域幅要求チャネルのビットとして受信する段階をさらに備える請求項１２に記載の方法。
17. 前記バッファ使用率通知を帯域幅要求チャネルのビットとして受信する段階をさらに備える請求項１３に記載の方法。
18. 無線システムで利用されるハイブリッド自動再送要求（ＨＡＲＱ）バッファを管理する段階を備える方法であって、
    前記管理する段階は、
    前記ＨＡＲＱバッファのサイズが変化するとサービス提供中の基地局に対して前記ＨＡＲＱバッファのサイズを送信する段階と、
    前記ＨＡＲＱバッファが満杯になると、バッファオーバーフロー指標を前記基地局に送信する段階と、
    前記バッファの格納内容が所定のしきい値を超えると、前記基地局にバッファ使用率指標を送信する段階と
    を有する方法。
19. 前記ＨＡＲＱバッファを管理する段階はさらに、
    復号ビットおよび受信ビットの両方を含むブロックを前記基地局から受信する段階と、
    前記復号ビットを前記ＨＡＲＱバッファに格納する段階と、
    前記受信ビットを前記ＨＡＲＱバッファに格納しない段階と
    を有する請求項１８に記載の方法。
20. 前記受信ビットを前記ＨＡＲＱバッファに格納しない段階はさらに、
    前方誤り訂正ビットを前記ＨＡＲＱバッファに格納しない段階を含む
    請求項１９に記載の方法。

Images