JP2006187019A - チャネル品質条件に基づく認知フロー制御 - Google Patents

Abstract

【課題】無線ネットワークコントローラ（ＲＮＣ）（１２）とノードＢ（５４）の間でデータフローの制御をインテリジェントに使用することにより、無線送信システムのパフォーマンスを改良するシステムおよび方法。
【解決手段】本システムは、特定の基準をモニタし、必要な場合はＲＮＣ（１２）とノードＢ（５４）との間のデータフローを適応的に減少または増加させる。これにより、再送信されるデータ、シグナリング手順、およびその他のデータがより高い速度で正常に受信されるようにし、ノードＢ（５４）でバッファされるデータ量を最小限にすることにより、送信システムのパフォーマンスを向上させる。チャネル品質が劣化すると、高速ダウンリンク共有チャネル（ＨＳ−ＤＳＣＨ）のハンドオーバの前に、フローの制御が実施されてノードＢ（５４）でのバッファリングを減少させる。
【選択図】図３Ａ

Description

本発明は、無線通信の分野に関する。より詳細には、本発明は、第３世代（３Ｇ:third generation）通信(telecommunication)システムにおいて無線ネットワークコントローラ（ＲＮＣ:radio network controller）とノード(node)Ｂとの間におけるデータ伝送(data transmission)のフロー制御(flow control)に関する。

第３世代（３Ｇ） ＵＴＲＡＮ(Universal Terrestrial Radio Access Network)は、数個のＲＮＣを備え、それぞれのＲＮＣは１つまたは複数のノードＢに関連付けられ、さらに各ノードＢ(Node B)は、１つまたは複数のセルに関連付けられている。

３Ｇ ＦＤＤ(frequency division duplex)モードおよびＴＤＤ(time division duplex)モードでは、通例、ＲＮＣを使用することにより、少なくとも１つのユーザ機器（ＵＥ:user equipment）へデータ伝送(data transmission)の配信(distribute)（すなわちバッファ(buffer)およびスケジュール(schedule)）を行う。しかし、３Ｇセルラシステム(cellular system)における高速チャネルの場合は、ノードＢによってデータの送信(transmission)がスケジュールされる。そうした高速チャネル(high speed channel)の１つは、例えば、高速ダウンリンク共有チャネル（ＨＳ−ＤＳＣＨ:high speed downlink shared channel）である。データがノードＢによってスケジュールされるので、ＵＥに送信するためには、ノードＢにおいてデータをバッファすることが必要となる。

ノードＢでバッファされる多くのデータ量(amount of data)が、システムの全体的な動作(overall operation)に負の影響(negative impact)を与えるシナリオ(scenario)は数多くある。そうしたシナリオのいくつかを次に記載する。

第１のシナリオは、端末間データ送信(end-to-end data transmission)において高い信頼性を達成するための、３Ｇシステムの再送信機構(retransmission mechanism)に関連する。当業者には、ノードＢとＵＥとの間の送信の失敗(transmission failure)は多様な理由に起因することが理解されよう。例えば、ノードＢが数回送信を試みたものの成功しなかった場合がある。あるいは、特定の送信に割り当てられた送信時間(transmission time)が経過してしまった場合がある。以下でさらに詳細に説明する本発明は、上記のような状況およびデータ送信が失敗したことにより無線リンクコントロール（ＲＬＣ:radio link control）の再送信が必要となる他の状況の両方を包含することを意図する。

多くのレベルの再送信機構(retransmission mechanism)が存在する。例えば、機構の１つは、高速ダウンリンクパケットアクセス（ＨＳＤＰＡ:high speed downlink packet access）のためのハイブリッド自動反復要求（Ｈ−ＡＲＱ:hybrid automatic repeat request）プロセスの再送信(retransmission)である。このＨ−ＡＲＱプロセスは、誤受信された送信が送信機(transmitter)に知らされ、そのデータが正しく受信されるまで送信機がデータを再送信する機構(mechanism)を提供する。

Ｈ−ＡＲＱプロセスに加えて、ＲＮＣとＵＥの中には複数のエンティティ(entity)がある。送信側ＲＬＣエンティティ(sending RLC entity)は、特定のプロトコルデータユニット（ＰＤＵ:protocol data unit）におけるヘッダ中シーケンス番号（ＳＮ:sequence number）を通知(signal)し、その番号が受信側ＲＬＣエンティティによって使用されて、送信で欠落したＰＤＵがないようにする。シーケンスから外れたＰＤＵの配信(out-of-sequence delivery)によって発生するように、送信中に欠落(miss)したＰＤＵがある場合、受信側ＲＬＣエンティティは、ステータスリポートＰＤＵ(status report PDF)を送信することにより、特定のＰＤＵが欠落していることを送信側ＲＬＣエンティティに知らせる。このステータスリポートＰＤＵは、データ送信(data transmission)が成功したというステータス、および／または、成功しなかったというステータスを記述(describe)する。ステータスリポートＰＤＵは、欠落した(missed)ＰＤＵまたは受信された(received)ＰＤＵのＳＮを識別する。ＰＤＵが欠落している場合、送信側ＲＬＣエンティティは、欠落したＰＤＵの複製(duplicate)を受信側ＲＬＣエンティティに再送信する。

システムパフォーマンスに対する再送信の影響(impact of retransmission)について、図１を参照して説明する。図１に示すように、ＳＮ＝３であるＰＤＵがＵＥによって正常に受信されないと、ＵＥ(user equipment)内のＲＬＣ(radio link control)は、ＲＮＣ(radio network controller)内のピアエンティティ(peer entity)に再送信(retransmission)を要求(request)する。その間に、ＳＮ＝６およびＳＮ＝７であるＰＤＵは、ノードＢのバッファに待ち行列として入れられる。

図２に示すように、再送信プロセス(retransmission process)は有限量の時間(finite amount of time)を要し、データは送信し続けられるので、ＳＮ＝６およびＳＮ＝７であるＰＤＵの後であって且つＳＮ＝３である再送信されるＰＤＵの前に、ＳＮ＝８およびＳＮ＝９のＰＤＵがもう２つ待ち行列に入れられる。ＳＮ＝３であるＰＤＵは、ＳＮ＝６〜９であるＰＤＵがＵＥに送信されるまで待機しなければならない。また、より高いレイヤに対して順番にデータを配信(in-sequence delivery of data)する必要性があるので、ＳＮ＝３のＰＤＵが受信されて順番通りのデータの配信が行われるまで、ＳＮ＝４〜９であるＰＤＵは、より高いレイヤに渡されない。

欠落したＰＤＵ(missing PDU)を送信することができるまで、順番が外れたデータ(out-of-sequence data)をバッファするためにＵＥが必要となる。この結果、送信が遅れるだけでなく、ＵＥは、欠落したデータが正常に再送信されるまで継続してデータを受信するためにデータバッファリングが可能なメモリを持つ必要がある。そのようなメモリがないと、有効なデータ送信レート(effective data transmission rate)は減少し、それによりサービス品質(quality of service)が影響を受ける。メモリは非常に高価なので、これは望ましくない設計上の制約である。したがって、この第１のシナリオによれば、ＲＬＣを再送信する必要があり、しかも、大きなデータ量がノードＢでバッファされる結果としてデータ再送信の遅延が長くなり、且つより多くのＵＥメモリが必要となる。

ノードＢでのデータのバッファリングがシステムパフォーマンスに負の影響を与える第２のシナリオとは、レイヤ２（Ｌ２）またはレイヤ３（Ｌ３）のメッセージおよびデータ送信が、同じスケジューリングプロセス(scheduling process)によって処理されるか、または、ノードＢにおいて単一のバッファを共有する場合である。データがバッファされ且つ処理され、その後にＬ２／Ｌ３メッセージが入ってくる間、メッセージは、送信待ち行列(transmission queue)を回避（circumvent）することができない。送信バッファ（先入れ先出し（ＦＩＦＯ）バッファとして動作する）中のデータ量が多いほど、Ｌ２／Ｌ３メッセージまたはデータがバッファを通過する(get through)のに要する時間は長くなる。したがって、より優先度が高いＬ２／Ｌ３メッセージが、バッファ中のデータによって遅れることになる。

ノードＢでのデータのバッファがシステムパフォーマンスに負の影響を与える第３のシナリオは、サービングＨＳ−ＤＳＣＨセル(serving HS-DSCH cell)が変わる場合である。ノードＢは、ＨＳ−ＤＳＣＨのためにデータのスケジューリングとバッファリングを行うので、ＵＥが、ソースノードＢ(source Node B)からターゲットノードＢ(target Node B)へサービングＨＳ−ＤＳＣＨセルの変更を行うと、ハンドオーバ後にはソースノードＢにかなりのデータ量がなおバッファされている可能性がある。ソースノードＢにバッファされたデータをターゲットノードＢに送信する機構(mechanism)がＵＴＲＡＮ(Universal Terrestrial Radio Access Network)アーキテクチャには存在しないので、このデータを回復することはできない。サービングＨＳ−ＤＳＣＨセルが変わるとき、ＲＮＣは、ソースノードＢにどのようなデータがバッファされているかを知らないので、例えデータが失われたとしても、ＲＮＣは、どれほどのデータが失われたかに関する情報を持っていない。ＨＳ−ＤＳＣＨセルの変更があった時にノードＢでバッファされているデータ量が多いほど、最終的にソースノードＢに取り残されるので、再送信されなければならないデータ量が多くなる。

したがって、上述の理由から、ノードＢにバッファされるデータ量を制限することが望ましいことになる。

本発明は、ＲＮＣとノードＢとの間におけるデータフローの制御をインテリジェントに使用(intelligent use)することにより、ワイヤレス送信システムのパフォーマンスを改良するシステムおよび方法である。このシステムは、ある一定の基準(certain criteria)をモニタし、必要な場合はＲＮＣとノードＢと間のデータフローを適応的に減少または増加させる。これにより、再送信されるデータ(retransmitted data)、シグナリング手順(signaling procedure)、およびその他のデータが、従来技術のシステムと比べてより高い速度で正常に受信されるようにし、ノードＢでバッファされるデータ量を最小限にすることにより、送信システムのパフォーマンスを向上させることができる。チャネル品質が劣化すると、ＨＳ−ＤＳＣＨハンドオーバに先だって、ノードＢにおけるバッファリングを減らすためにフロー制御を実施する。

本発明の好ましい実施形態では、ワイヤレス通信システムとして、データを格納するための少なくとも１つのバッファを有するノードＢと通信する無線ネットワークコントローラ（ＲＮＣ:radio network controller）を含んでいる。このＲＮＣは、ノードＢに対して、ＲＮＣがあるデータ量をノードＢに送信するという要求を通知する。ノードＢは、選択された品質インジケータ(quality indicator)をモニタし、その選択された品質インジケータに基づいてバッファのキャパシティ割り当て(capacity allocation)を計算する。ノードＢは、そのキャパシティ割り当てをＲＮＣに通知(signal)する。キャパシティ割り当てを受信するのに応答して、ＲＮＣは、そのキャパシティ割り当てに従って決定されたデータフローレート(data flow rate)によりノードＢに対してデータを送信する。

本発明のより詳細な理解は、添付図面と併せて以下の詳細な説明から得られるであろう。

すべての図面において、同様の参照符号は同様の要素を表す。ここでは、バッファの待ち行列に入れられる具体的な数のＰＤＵ（１０個のＰＤＵなど）を参照して説明していくが、このＰＤＵの数は、単に説明を簡略にするために挙げたものである。上述のシナリオに従って送信されバッファされる実際のＰＤＵの数は、数百あるいはそれ以上のＰＤＵである可能性が高い。本発明に係る実施形態およびその教示は、任意数のＰＤＵと任意サイズの送信バッファに適用可能である。

一般に、本実施形態では、ＵＥのチャネル品質(channel quality)の劣化(degradation)があるときにはそのＵＥについてのノードＢへのデータフローを減らし、他方、そのＵＥのチャネル品質の改良が見られるときにはノードＢへのデータフローを増加させる。ＲＮＣとノードＢと間でデータ伝送のフローを制御するために、本実施形態は、チャネル品質についての１つまたは複数のパラメータをモニタする。このフロー制御は、１つの基準、または多くの異なった基準の組み合わせに基づくことができる。また、後に詳細に説明するように、この基準は、ノードＢによって内部的に生成されてもよく、あるいは、外部エンティティ(external entity)（ＵＥなど）によって生成されノードＢに送信されてもよい。

図３Ａは、本実施形態に従って通信チャネルの品質をモニタし、ＲＮＣ５２ノードＢ５４と間のデータフローを調整(adjust)する方法５０を示している。この方法５０は、ＲＮＣ５２とノードＢ５４との間のデータの送信を扱う。ＲＮＣ５２は、ノードＢ５４にキャパシティ要求(capacity request)を送信する（ステップ５８）。このキャパシティ要求は、基本的に、ＲＮＣ５２があるデータ量をノードＢ５４に送信することを求めるという、ＲＮＣ５２からノードＢ５４への要求である。ノードＢ５４は、キャパシティ要求を受信し、選択された品質インジケータ(quality indicator)をモニタする（ステップ６０）。この選択された品質インジケータは、ＵＥから送信されたデータに基づいても（下記で詳細に説明する）よく、あるいは、ノードＢ５４におけるバッファの深さ(depth)など、内部的に生成された品質インジケータに基づいてもよい。

ノードＢ５４は、ノードＢにおけるバッファのステータスもモニタする（ステップ６２）。当業者には理解されるように、本実施形態では、説明を簡略にするためにノードＢ５４内の単一のバッファを参照して説明してあるが、多くの場合、バッファは、複数のバッファ、または複数の部分バッファ(sub-buffer)に区分(segment)された単一のバッファからなり、各バッファまたは部分バッファが、１つまたは複数のデータフローに関連付けられている。１つのバッファであるか複数のバッファであるかに拘わりなく、バッファ中のデータ量を示すインジケータは、一般にはノードＢの内部で生成される。これにより、ノードＢ５４は、バッファ内のデータ量をモニタし、且つ、バッファが受け付けることができる追加的なデータ量もモニタすることができる。

ノードＢ５４は、キャパシティ割り当て(capacity allocation)を計算し、ＲＮＣ５２に送信する（ステップ６４）。このキャパシティ割り当ては、ノードＢ５４による、ＲＮＣ５２があるデータ量を送信することの許可(authorization)である。ＲＮＣ５２は、キャパシティ割り当てを受信すると、その割り当てに従ってデータを送信する（ステップ６６）。すなわち、ＲＮＣ５２は、キャパシティ割り当てを超えないデータ量をノードＢ５４に送信する。次いで、ノードＢは、その量に応じて自身のバッファを調整(adjust)してデータを受信し、格納する（ステップ６９）。バッファに格納されたデータ量は、ＲＮＣ５２から送信される受信データと、ＵＥ８２に送信される送出データ(outgoing data)に従って変化する（図３Ｂに示す）。

図３Ａに示した方法５０は、データがＲＮＣ５２からノードＢ５４に流れ、フローレート(flow rate)がノードＢ５４によって継続的に調整(adjust)されるのに従って、持続的に繰り返されることが当業者には理解されよう。ステップ５８、６０、６２、６４、６６、および６９は、順番通りに行われるとは限らず、方法５０において別のステップが適用される前に、あるステップが複数回適用されてよいことにも留意されたい。また、キャパシティ割り当てのステップ６４など一部のステップは、データの送信（ステップ６６）を周期的に実施できるようにする反復的なデータ割り当て(repetitive data allocation)を意味することができる。

図３Ｂには、ノードＢ５４とＵＥ８２との間における通信チャネル(communication channel)の品質をモニタする方法８０を示してある。ノードＢ５４は、ＵＥ８２に対してデータを送信する（ステップ８４）。ＵＥ８２は、データを受信し、ノードＢ５４に対してチャネル品質インデックス（ＣＱＩ:channel quality index）などの信号品質インジケータ(signal quality indicator)を送信する（ステップ８６）。次いで、図３Ａのステップ６０において、この信号品質インジケータを、選択された品質インジケータ(selected quality indicator)として使用することができる。

当業者は、ステップ８４とステップ８６が実際には必ずしも連続しないことを気付くであろう。例えば、ＦＤＤモードでは、データが送信されるか否かに関係なく、信号品質インジケータが周期的にＵＥ８２から送信される。そのような場合、ＵＥ８２は、周期的に、または特定のイベント(specific event)に応答して、ノードＢ５４に信号品質インジケータを送信する。そして、図３Ａのステップ６０において、この信号品質インジケータを、選択された品質インジケータとして使用することができる。

上述のように、上記選択された品質インジケータは、ノードＢによって内部的に生成されてもよく、あるいは、ＵＥなど別のエンティティによって外部的に生成されてからノードＢに送信されてもよい。第１の実施形態によれば、上記基準(criterion)は、ＵＥからのチャネル品質フィードバック(channel quality feedback)である。この第１の実施形態では、ダウンリンクチャネル品質(downlink channel quality)のインジケータであるＣＱＩが使用される。

第２の実施形態において、上記基準(criterion)は、Ｈ−ＡＲＱプロセスに従ってＵＥが生成するＡＣＫまたはＮＡＣＫである。例えば、ある期間におけるＡＣＫの数および／またはＮＡＣＫの数を使用することにより、そのチャネルの品質の指示(indication of the quality of the channel)を得ることができる。

第３の実施形態において、上記基準(criterion)は、データ送信を成功させるために必要とされる変調および符号化セット（ＭＣＳ:modulation and coding set）について、ノードＢによる選択(choice)である。当業者には理解されるように、チャネル条件(channel condition)が不良(poor)な時には非常に強固(robust)なＭＣＳが使用される。あるいは、チャネル条件が良好であり、大きなデータ量を送信することができる場合は、それほど強固でないＭＣＳを利用することができる。最も強固なＭＣＳセット(most robust MCS set)の選択は、不良なチャネル品質条件(poor channel quality condition)のインジケータとして利用することができる。これに対して、最も強固でないＭＣＳ(least robust MCS)の使用は、チャネル品質条件(channel quality condition)が好適(favorable)であることを示す(signify)ことができる。

第４の実施形態において、上記基準(criterion)は、ノードＢの送信バッファ内部における待ち行列の深さである。例えば、ノードＢ５４のバッファが現在多くのデータ量を格納している場合、それは、データがノードＢのバッファで「列をなしている(backing up)」ことになるので、チャネル品質条件が不良(poor)である可能性のインジケータとなる。負荷が軽いバッファは、チャネル品質条件が良好(good)であり、データが渋滞していないことのインジケータとなる。

第５の実施形態において、上記基準(criterion)は、ノードＢで「ドロップ(dropped)される」データ量である。当業者には理解されるように、ドロップされるデータ(dropped data)は、ノードＢが数回再送信を試み、所定回数の再試行の後断念したデータである。ノードＢにより多数の送信がドロップされる場合は、チャネル品質条件が不良であることの表れである。

第６の実施形態において、上記基準(criterion)は、１００ミリ秒など所定の継続時間内にノードＢによって送信することができるデータ量である。通信チャネルの品質に応じて、ノードＢでバッファされるＰＤＵの数は変化する可能性がある。所定の継続時間が固定的なものであったとしても、チャネル品質条件が変化することにより、上記所定の継続時間内に送信することができるＰＤＵの量は、劇的に変化する可能性がある。例えば、チャネル品質条件(channel quality condition)が良好(good)な場合は、１００ミリ秒の継続時間内に１００個のＰＤＵを送信することができるが、チャネル品質条件が非常に悪い場合(very poor)は、１００秒の継続時間内に１０個のＰＵＤしか送信することができない場合がある。

当業者には、チャネル条件を直接的にまたは間接的に表すことができる他の基準も、利用可能であることが理解されよう。さらに、システムユーザの具体的な必要性に応じて、上記の基準を２つ以上組み合わせること、または必要性に応じて重み付けすることが可能である
図４を参照すると、ＲＮＣとノードＢとの間におけるデータのフローを適応的(adaptively)に制御することの利益(benefit)を理解することができる。この例は、送信が失敗したことにより再送信が必要とされ、ＲＮＣとノードＢと間におけるデータのフローが減少する、というシナリオを示している。データフローが減少した結果、ＳＮ＝８である唯１つの追加的なＰＤＵが、ＳＮ＝３である再送信されるＰＤＵ(retransmitted PDU with SN=3)の前に、待ち行列として入れられる。図４に示したフロー制御の実施形態は、図２に示した再送信の従来処理技術と比べて、ＳＮ＝３であるＰＤＵの再送信の待ち時間を短縮する。すなわち、ＳＮ＝８であるＰＤＵについてみると、ＳＮ＝３であるＰＤＵの前に待ち行列として入れられている。したがって、ＳＮ＝３のＰＤＵをより早くＵＥに再送信することができる。この順番で配信を行う必要性(the in-sequence delivery requirement)の結果、ＰＤＵ４〜８をより早く処理してより高いレイヤへの配信(delivery)を行うことができる。

以上、好ましい実施形態に即して本発明を説明してきたが、当業者には、特許請求の範囲に記載された発明の範囲内にある他の変形実施形態とすることが明らかであろう。

従来技術による、ＲＮＣ、ノードＢ、およびＵＥにおけるデータのバッファリングを示す図である。 従来技術による、再送信の際におけるＲＮＣ、ノードＢ、およびＵＥにおけるデータのバッファリングを示す図である。 本発明にしたがって、ＲＮＣとノードＢとの間のチャネル品質をモニタし、データのフローを調整する方法を示す図である。 本発明にしたがって、ＲＮＣとノードＢとの間のチャネル品質をモニタし、データのフローを調整する方法を示す図である。 図３Ａおよび図３Ｂの方法を使用することにより、再送信の際における、ＲＮＣ、ノードＢ、およびＵＥにおけるデータのバッファリングを示す図である。

符号の説明

５０ 方法
８０ 方法

Claims (11)

1. データを格納するための少なくとも１つのバッファを有するノードＢと通信する無線ネットワークコントローラ（ＲＮＣ）を含んだワイヤレス通信システムにおいて、前記ＲＮＣと前記ノードＢ間のデータフローを制御する方法であって、
   （ａ）前記ＲＮＣがあるデータ量を前記ノードＢに送信するという要求を、前記ＲＮＣから前記ノードＢに通知するステップと、
   （ｂ）前記ノードＢは、選択された品質インジケータをモニタするステップと、
   （ｃ）前記ノードＢは、前記選択された品質インジケータに基づいて、前記バッファのためのキャパシティ割り当てを計算するステップと、
   （ｄ）前記ノードＢは、前記キャパシティ割り当てを前記ＲＮＣに通知するステップと、
   （ｅ）前記キャパシティ割り当ての受信に応答して、前記ＲＮＣは、前記キャパシティ割り当てと少なくとも１つの所定の基準とに従って決定されたデータフローレートにより、前記ノードＢに対してデータを送信するステップと、
   （ｆ）前記ノードＢは、前記バッファを適宜調整するステップと
   を具備したことを特徴とする方法。
2. 前記選択された品質インジケータは、少なくとも１つのユーザ機器（ＵＥ）から前記ノードＢに送信されるデータに基づいていることを特徴とする請求項１に記載の方法。
3. 前記選択された品質インジケータは、前記ＵＥと前記ノードＢとの間に確立されたダウンリンクチャネルの品質を示すチャネル品質インデックス（ＣＱＩ）であることを特徴とする請求項２に記載の方法。
4. 前記少なくとも１つの所定の基準は、前記ＵＥがハイブリッド自動反復要求（Ｈ−ＡＲＱ）に従って生成するＡＣＫまたはＮＡＣＫに基づくことを特徴とする請求項２に記載の方法。
5. 前記データフローレートは、前記選択された品質インジケータの改善に応答して増加することを特徴とする請求項１に記載の方法。
6. 前記データフローレートは、前記選択された品質インジケータの劣化に応答して減少することを特徴とする請求項１に記載の方法。
7. 前記選択された品質インジケータは、前記ノードＢにより内部的に生成されることを特徴とする請求項１に記載の方法。
8. 前記少なくとも１つの所定の基準は、前記ノードＢにより選択される変調および符号化セット（ＭＣＳ）に基づくことを特徴とする請求項１に記載の方法。
9. 前記少なくとも１つの所定の基準は、前記ノードＢにおけるバッファ内の待ち行列の深さに基づくことを特徴とする請求項１に記載の方法。
10. 前記少なくとも１つの所定の基準は、前記ノードＢでドロップされるデータ量に基づくことを特徴とする請求項１に記載の方法。
11. 前記少なくとも１つの所定の基準は、所定の継続時間内に前記ノードＢにより送信できるデータ量に基づくことを特徴とする請求項１に記載の方法。
    

Images