JP2007507934A - Ｕｍｔｓにおける調和したデータフロー制御とバッファ共用 - Google Patents

Abstract

本発明ではＵＴＲＡＮのｌｕｂとｌｕｒのインタフェースによりＨＳ−ＤＳＣＨデータストリームを制御するフロー制御方法を記載している。２つのクレジット割当て方式も説明される。フロー制御方法が実行される無線ネットワークノードが提案される。最後に、そのフロー制御方法とクレジット割当て方式とを実行するコンピュータプログラム製品についても説明する。別々のユーザデータフロー制御がノードＢにより調整され、ｌｕｂとｌｕｒインタフェースによるデータ転送がＵｕインタフェースによるデータ転送に適合される。その主な利点はバッファリングが第１にＳＲＮＣにおいて維持できることである。提案されたフロー制御方法は、個々のデータフロー制御が互いに独立に実行される場合の方式と比較して、ノードＢのバッファレベルを著しく低減できることが示される。また、データフロー量に対する悪い影響が概して小さいことも示される。

Description

本発明は、全地球的規模の移動体通信システム（ＵＭＴＳ）におけるいくつかのユーザ間の希少なバッファリング資源を共用するシステムと方法に関するものである。

マルチメディア無線ネットワークは、ウェブブラウジング、資源の動的共用、オーディオやビデオのストリーミングのようなインターネット的なサービスに対する要求の高まりとともに急速に膨張している。そのような無線ネットワークは、移動体或いは固定ネットワークでも良い。この種の移動体ネットワークは第３世代（３Ｇ）移動体通信システムとして知られている。ＰＳＴＮ（公衆交換電話ネットワーク）からの回路交換の音声トラフィックを主として搬送する以前のタイプの移動体ネットワークとは異なり、３Ｇネットワークは、ＰＳＴＮ、Ｂ−ＩＳＤＮ、ＰＬＭＮ、及びインターネットを含む種々のネットワークからの種々のパケットデータを搬送する。

全地球的規模の移動体通信システム（ＵＭＴＳ）として総称的に知られているプロトコルのセットを標準化する進行中のプロセスがある。図１は、コアネットワーク２として言及される３ＧネットワークとＵＭＴＳ陸上無線アクセスネットワーク（ＵＴＲＡＮ）３とを有するＵＭＴＳネットワークを模式的に図示している。ＵＴＲＡＮは複数の無線ネットワーク制御局（ＲＮＣ）を有している。全てのＲＮＣは類似しているが、異なるＲＮＣが異なる役割をもっても良い。図１において、サービングＲＮＣ、即ち、ＳＲＮＣ４、ドリフトＲＮＣ、省略してＤＲＮＣ５が示されている。各ＲＮＣは基地局６のセットに接続されている。基地局はしばしばノードＢと呼ばれている。各ノードＢは、与えられた地理的セル内で移動体端末７（或いはユーザ機器ＵＥ）との通信を担当する。サービングＲＮＣはユーザをルーティングし、ノードＢとコアネットワークとの間でデータをシグナリングすることを担当する。コアネットワークとＲＮＣとの間の移動体はＩｕとして言及され、ＲＮＣ間の移動体はＩｕｒとラベルが付けられる。ＲＮＣとノードＢとの間の移動体はＩｕｂと記され、ノードＢと移動体端末との間の空中インタフェースはＵｕインタフェースである。

ＷＣＤＭＡ仕様の第５版（非特許文献１）では、高速ダウンリンク共用チャネル（ＨＳ−ＤＳＣＨ）として言及される新しい転送チャネルが導入された。ＨＳ−ＤＳＣＨに関していえば、現在のダウンリンク共用チャネルと比較して、高速自動繰返し要求（ＡＲＱ）プロトコル、高速リンク適合、高速チャネル依存スケジューリングのようないくつかの新しい無線インタフェース機能が備えられる。これら新しい機能の全ては、ノードＢに位置するＭＡＣ−ｈｓエンティティと呼ばれる媒体アクセス制御（ＭＡＣ）レイヤ上の新しい機能エンティティとして置かれる。フレームプロトコルとして言及される、データ転送を処理し、ＳＲＮＣとノードＢのユーザバッファ間のフロー制御を実行することの両方が可能な新しいプロトコルも導入される。もし、データがＳＲＮＣから直接ノードＢに転送されるなら、フレームプロトコルはＩｕｂインタフェースにより用いられる（非特許文献２参照）。データがＤＲＮＣを介してＳＲＮＣからノードＢに転送されるなら、そのフレームプロトコルはＩｕｒとＩｕｂインタフェースにより用いられる。

図２において、ｉ個（ｉ＝１，２，……）のユーザがあり、夫々が対応する移動体端末ＵＥ１、ＵＥ２、……、ＵＥｉをもっているとする。各ユーザに対するデータはコアネットワークからＳＲＮＣに到着し、そこでデータはバッファ８に格納される。そのバッファ各々は各ユーザに関係付けられる。もし、ユーザが多くの優先度クラスをもっているなら、ユーザ当たり幾つかのバッファがある。説明を簡単にするために、異なる優先度クラスは考慮されておらず、各ユーザは１つのバッファをもつことが示されている。ＳＲＮＣからユーザの格納データはノードＢに転送され、そこで、そのデータは一時的に対応する個々のバッファ９に格納される。ノードＢから、ユーザデータは空中インタフェースＵｕを介して個々のＵＥへと送信される。

フレームプロトコルでは、クレジットを基本としたフロー制御機構が用いられる。その機構では、容量要求フレーム１０と容量割当てフレーム１１とが、ノードＢとＳＲＮＣとの間で別々に、個々のユーザに関し、そしてそれ故に対応する個々のデータストリーム１２に関しても交換される。容量要求フレームは、個々のＵＥに関するＳＲＮＣバッファで処理待ち中（キューイング中）である数多くのＭＡＣ−ｄプロトコルデータユニット（ＭＡＣ−ｄ ＰＤＵ）のノードＢのバッファを通知するＳＲＮＣにより送信される。容量要求フレームの受信に応答して、ノードＢは割当てフレームをＳＲＮＣに送信する。その割当てフレームは、ＳＲＮＣがＵＥに送信するのを許可されたＭＡＣ−ｄ ＰＤＵの量を示している。ＳＲＮＣがその割当てフレームを受信するとき、ＭＡＣ−ｄ ＰＤＵの示された数をＳＲＮＣに送信する。ノードＢがＳＲＮＣに送信するのを許可するＭＡＣ−ｄ ＰＤＵの数はクレジットと呼ばれる。そのクレジットは一般には承諾クレジットフレームフィールドと呼ばれる（従って、クレジットを基本としたフロー制御という名前がある）フレームフィールド１３の割当てフレームにおいて示される。従って、ノードＢはＳＲＮＣとノードＢとの間のデータフローを制御する。

フレームプロトコルはまたＤＲＮＣで終了する。このことは２つの別々の制御ループがあることを意味する。１つはＤＲＮＣとノードＢとの間にある。このループはノードＢがＤＲＮＣからのデータフローを制御する場合に説明されたものとちょうど類似のものである。他の制御ループはＤＲＮＣとＳＲＮＣとの間にある。この場合、ＤＲＮＣはＳＲＮＣからのデータフローを制御する。しかしながら、ノードＢに見られるようなフロー制御ループは両方の場合に類似している。次に、ＳＲＮＣとノードＢとの間のダイレクトパスだけを考慮する。

正しく振舞うフロー制御方式の主要な目的は、ノードＢとそれに接続されたＵＥとの間での空中インタフェースにより流れるデータ量に悪い影響を与えることなく、ＳＲＮＣの１つのバッファからノードＢの対応するバッファに対して転送されるデータ量を調節することである。このことはノードＢのバッファが決してアンダフローになるべきではなく、或いはノードＢが余りにも多くのデータをためることのないようにすることを意味している。

“アンダフロー”という用語は、ＳＲＮＣがＵＥに対してＳＲＮＣバッファに処理待ち中の（キューイング中の）ユーザデータをもっているが、ノードＢのバッファがその同じＵＥに送信するユーザデータをもっていないことを意味している。それ故に、ノードＢのバッファは余りにも少ないデータを保持するようではいけないのである。

ノードＢが余りにも多くのデータをためるなら問題が生じる。なぜなら、複数のＵＥがしばしば１つのノードＢから別のノードＢにハンドオフされる一方、そのフレームプロトコルは異なるノードＢ間でデータを転送できないので、そうなるのである。耐性のために、それ故、できるだけ長くＳＲＮＣにユーザデータを保持することが望ましい。ハンドオフ手順はハンドオーバとも呼ばれる。

さらに、ノードＢにおける個々のバッファは余りにも小さくないかもしれないし、余りにも大きくはないかもしれない。もし、バッファが小さいなら、割当てフレームが頻繁に送信されねばならない。このことは可能性がない。なぜなら、これはＩｕｂインタフェースの広範な使用を必要とし、それは使用するのに高価であるからである。さらに、標準化に従えば、割当てフレームが送信される期間は１０ｍｓに制限される。従って、割当てフレームを頻繁に送信するのは不可能である。

ノードＢにおけるバッファ容量は一般に高価なものである。もし、そのバッファが余りにも大きいならノードＢは高価なものになるであろう。ノードＢはしばしば塔やマストや屋根などに設置されるので、新しいメモリ資源を付加することによりノードＢのバッファ全容量を拡張することは容易な仕事ではない。
国際公開第０２／４９２９２号パンフレット 米国特許出願公開第２００３／００１６６９８号明細書 欧州特許第０９１２０１６号明細書 第３世代パートナーシッププロジェクト；無線アクセスネットワーク技術仕様グループ；ＵＬＴＲＡ高速ダウンリンクパケットアクセス；概説；ステージ２，３ＧＰＰ ＴＳ２５．３０８（3rd Genration Partnership Project; Technical Specification Group Radio Access Network; ULTRA High Speed Downlink Packet Access; Overall Description; Page 2, 3GPP TS 25.308） 第３世代パートナーシッププロジェクト；無線アクセスネットワーク技術仕様グループ；共通転送チャネルデータストリームについてのＵＴＲＡＮ Ｉｕｒユーザプレーンプロトコル，３ＧＰＰ ＴＳ２５．４２５（3rd Genration Partnership Project; Technical Specification Group Radio Access Network; UTRAN Iur user plane protocols for Common Transport Channel data streams, 3GPP TS 25.425）

それ故に、データフロー量に悪い影響を与えることなく、ノードＢでバッファされる量をできるだけ小さく保つことに問題は帰結することになる。このことはまた、本発明によって解決されるべき主要な課題でもある。

次に、この問題は２つの問題、即ち、効率的なフロー制御と効率的なメモリの扱いへと分けることができる。フロー制御の目的は、ユーザデータフローにおける変化に依存する予期できない時間をスムーズにならすことにある。一方、メモリの扱いの目的は、用いられるメモリ量を最適化することにある。次の条件、即ち、（ａ）オーバフローによるデータの損失を避けねばならないこと、（ｂ）データフローが詰まってはならない、つまりアンダフローを回避しなければならないことという条件で、ノードＢにおける格納ユーザデータの総量を最小化したい（それは、潜在的なハンドオフ手順のために重要である）。

図３にはノードＢにおける公知のＭＡＣ−ｈｓレイヤ構造が図示されている。ＭＡＣ−ｈｓはフロー制御部１４、再送プロトコルハンドラＨＡＲＱ（ハイブリッド自動要求）１５、スケジューラ１６、転送フォーマット選択部（ＴＦ選択部）１７、及び共用無線チャネル１８とを有している。新しい転送チャネルはＨＳ−ＤＳＣＨとして示されている。

図４には以前から知られたクレジットを基本としたフロー制御機構が図示されている。それは、個々のＵＥのユーザデータフローを制御する“フロー毎（per flow）”を基本とするクレジット割当て方式を利用する。

次に、ＵＥ１に向けられたユーザデータについて説明する。矢印１９により図示された容量要求フレームはＳＲＮＣにより送信され、従って、ＵＥ１に関してＳＲＮＣで処理待ちのユーザデータ量についてノードＢのバッファ９に通知する。これに応答して、ノードＢは、そのノードＢのＵＥ１のバッファで利用可能な空きのバッファ空間に基づいていくらかの容量を割当てる。非常に一般的な言葉で、また不完全な方法で表現するのであるが、空きのバッファ空間は、バッファの最大メモリ空間−（マイナス）未処理のクレジットである。非常に一般的な言葉で、また不完全な方法で表現するのであるが、“未処理のクレジット（outstanding credit）”という用語は、ＳＲＮＣからノードＢへ送信するクレジットを承諾したのであるがノードＢによりまだ受信されていないユーザデータに言及するものである。通常、クレジットの量はＭＡＣ−ｄ ＰＤＵユニットで表現される。

次に、ノードＢは上側の矢２０により表現され、ＳＲＮＣがＵＥ１に関して送信するのを許可されたクレジットの数を示す割当てフレームを送信する。この量は承諾されたクレジットフレームフィールドで示される。

ＳＲＮＣはその割当てフレームを受信し、そこから承諾クレジットの数を抽出し、そのクレジットを以前に承諾されたクレジットを上書きする不図示のカウンタに書込み、対応する数のＭＡＣ−ｄ ＰＤＵを矢印２１で表現されているようにノードＢに送信する。ＳＲＮＣはまた、そのカウンタから送信されたＭＡＣ−ｄ ＰＤＵの数を減算する。その時点の割当てと、割当てられたＭＡＣ−ｄ ＰＤＵがノードＢにより受信される時点との間の時間間隔は、ラウンドトリップ（往復）時間と呼ばれる。図４には、その往復時間がＲで示されている。下側の矢２０はノードＢが更なる割当てフレームをＳＲＮＣに送信する第２の時点を表している。２つの矢は未処理のクレジット、即ち、与えられたが対応するデータは未だ受信していないクレジットを表している。なお、２つの連続する割当てフレームの受信時刻間の時間間隔で、ＳＲＮＣは処理待ちのユーザデータ（ＭＡＣ ＰＤＵ）をノードＢに送信しても良い。

ノードＢにおけるスケジューラは、ノードＢでバッファされるユーザデータが異なるＵＥに送信されるときのシーケンスを編成する。個々のＵＥに送信するようスケジュールされたユーザデータは対応するＵＥバッファからとられ、転送フォーマットセレクタにより生成された転送ブロックに挿入される。特に、そのスケジューラはノードＢに、送信される転送ブロック、送信に用いるタイムスロット、及びその転送ブロックが意図しているＵＥを伝える。転送ブロックは、異なるＵＥに送信されるデータ量に依存して変化する長さをもつ。各転送ブロックは、無線インタフェースＵｕで、固定時間、通常は、２ｍｓのタイムスロットで送信される。

無線インタフェースにより、転送ブロックは次々に送信される。通常、ただ１つのＵＥが与えられた瞬間でのタイムスロットを利用する。或いは、符号多重化をタイムスロットに用いることもでき、それは、そのタイムスロットが２つ以上のＵＥにより共用されることを示唆する。

なお、クレジット割当て手順とスケジューリング手順との間に何かの関係があるわけではない。データスケジューリングは短い間隔で発生し、個々のＵＥの瞬間的なチャネル品質に基づいて動的にそのスケジューリングはなされる。一方、与えられたＵＥについてのクレジット割当て手順はもっと長い時間間隔で発生する。そのクレジット割当て手順は、ＵＥのチャネル品質に関係していない。チャネル品質は連続するクレジット割当て期間に何回も変化する。

上述した公知の“フロー毎”を基本とするクレジット割当て方式で個々のＵＥに与えられたクレジットは、与えられた別のＵＥには独立のクレジットである。各ユーザデータフローが他のフローに対して独立なので、“フロー毎”を基本とすると呼ばれている。この方式の主な欠点は、アンダフローを回避するためには、ノードＢの全てのバッファが、ユーザデータで満たされる必要がある点である。従って、このバッファは無線チャネルにより実際にスケジュールできるデータ量に係わり無く、いっぱいである必要がある。なぜなら、スケジューラが送信のためにどのＵＥバッファを選択するかを予測することは不可能であるために、そのようになる。

さらにその上、ノードＢのバッファされたデータの総量はユーザデータフローの数に直接的に比例し、空中を送信されるデータ量にではない。データフローの数がより大きくなると、より多くのデータがノードＢでバッファされる。長期的には、ノードＢはＵＥに配信できるよりも多くのデータを格納するかもしれない。このことは、大量のデータがノードＢからの送信のためにキューイングしており、無線インタフェースによる送信のためにまだスケジュールされていないデータがあることを示唆している。このような環境下で、もし、ＵＥがあるノードＢから新しいノードＢにハンドオーバ手順により切替えられたなら、既にノードＢにバッファされたデータを新しいノードＢに転送するのに利用可能な機構はなく、そのバッファされたデータは喪失してしまう。その喪失データの再送信は新しいノードＢに対して生じなければならない。ＳＲＮＣからの再送信は低速であり、高価な手順である。なぜなら、それはＵＴＲＡＮインタフェースで発生するからである。これらは低速で、通常はいくつかのネットワークノードを横切ることになる。

特許文献１はＵＴＲＡＮネットワークにおけるフロー制御機構を開示している。ここでは、自動繰返し要求（ＡＲＱ）機構が実装されてノードＢにおけるバッファレベルを低くする。上述のフロー制御方法は互いに独立の別々のパケットデータストリームを扱い、ノードＢでバッファされるデータ量は与えられたＵＥに対してのみ少なくされるので、問題が生じる。その結果、バッファされたデータ総量、即ち、いくつかの独立なパケットデータフローからのバッファされたデータ合計は、ノードを横切るデータストリームの数に直接的に比例する。分離した個々のデータストリームについてのバッファレベルは低くすることができるが、それ故にバッファされたデータの総量は多くのユーザ人口に対しては過度なものとなる。従って、その問題はそのまま残り、バッファレベルを低くされたユーザ以外のユーザが１つのノードＢから別のノードＢへと移動して（ハンドオーバする）とき、データはＳＲＮＣからノードＢに再送されねばならない。

特許文献２はＷＣＤＭＡシーケンスにおいてＭＡＣレイヤエンティティを再設定する方法を開示している。ＲＬＣ（無線リンク制御）エンティティの再設定時、ＭＡＣレイヤエンティティを再設定することにより、不必要なデータがＭＡＣレイヤエンティティでバッファされるのを防止することが可能である。それにより、メモリ資源の利用効率を改善することが達成される。フロー制御は示されているが、その動作については開示されていない。

特許文献３はリモート端末に無線ネットワークにおけるオンデマンドでのバンド幅を提供する。基地局に送信するパケットをもつリモートホストは、アップリンクの初期コンテンションに関与する。そのコンテンションの間に、送信するパケットをもつ各リモートは基地局にアクセスを要求する。アクセス要求は衝突するかもしれず、衝突を起こしたリモートホストはアップリンク競合解消に関与する。基地局は、アクセス要求を行なう複数のリモートホスト間でのアップリンクバンド幅を割当て、それ自身のダウンリンク送信のバンド幅割当てがこれに続く。

特許文献３は、基地局制御ノード（ＢＳＣノード）におけるバッファ資源が驚くべきものであり、バッファのオーバフローとアンダフローとを回避しなければならない場合、ＭＳＣノードのようなコアネットワークノードからＢＳＣノードへの伝送制御には注目していない。特許文献３ではクレジットは与えられておらず、従って、その伝送制御はこれらのことを考慮していない。

特徴文献３では、無線によるパケット伝送はコンテンションを基本としている。しかしながら、本願発明はノードＢによって受信される各データユニットの厳密な制御を提供している。ノードＢは、ユーザ機器に対して無線により送信するためにすぐにスケジュールされるデータユニットをただ受信するだけである。

発明の要約
本発明の１つの目的は、ノードＢにおいて、各ユーザに対する送信のためにスケジュールされたデータ量に一般的は等しいデータ量をバッファリングする方法とシステムとを提供することにある。

本発明の別の目的は、調整されたフロー制御とバッファリング共用の方法を適用することにより、いくつかのデータストリーム間で希少なバッファリング資源を共用する方法とシステムとを提供することにある。

本発明によれば、そのフロー制御プロセスは、（１）未処理のクレジットの数を計数し、割当てがなされる度ごとにその未処理のクレジットの計数値を増加させ、データデータユニットが受信される度ごとにその未処理のクレジットの計数値を減少させることにより、未処理のクレジットの数の変化する計数値を保持し、（２）要求された容量を決して超えることができないように割当て容量を制限する第１のクレジット割当て規則／方式を有する。その第１のクレジット割当て規則／方式により、ノードＢにおけるユーザデータの受信を予測することが可能になり、上述の（ａ）と（ｂ）の条件とを満足する。ユーザデータフローの時間依存の変化はこれによりスムーズになる。

本発明によれば、そのフロー制御プロセスは、チャネル品質の指標がノード毎（per-node）を基本とした容量割当てを調整するために用いられる、第２のクレジット割当て規則／方式を用いる。そのようにすることで、経験するチャネル品質に比例して、いくつかのユーザ間で希少なメモリ資源を共用することが可能になる。従って、チャネル品質指標の使用により、最小のメモリ資源を用いて上述の条件（ａ）と（ｂ）との達成が可能になり、従って、メモリ最適化の問題に対する解決策を与えることができる。

希少なバッファリング資源は示されたチャネル品質に比例してユーザ間で共用される。実際、そのことは、各ユーザのＵＥはノードＢに、ノードＢとＵＥとの間の送信チャネルのチャネル品質をレポートすることを意味する。ノードＢは示されたチャネル品質を用いて、そのデータストリーム間でそのバッファリング資源を共用する。フロー制御は、別々のデータストリームに与えられたクレジット量がノードＢを横切るデータストリームの数の関数として計算されるように調整される。

ノードＢで全てのデータストリームに与えられたクレジットの総計は、ノードＢに送信するためにＳＲＮＣが要求するデータ量より小さい予め定義された値に制限される。このことはＳＲＮＣから送信されたデータを格納するのに利用可能なメモリ空間が常にあることを保証するであろう。

本発明の主要な利点の１つには、ノードＢのバッファレベルが、ノードを横切るパケットデータストリームの数の代わりに、スケジュールされたデータ量にだけ依存することがある。そのデータはノードＢから各ＵＥへの送信のためにスケジュールされたデータである。このことは、ユーザデータの主要なバッファリングがＳＲＮＣで維持され、そのことは次に、（１）ノードＢについてのメモリ要求が小さくなり、（２）通信の信頼性が増し、（３）ハンドオフが原因となるエラーイベントに対する耐性を改善し、（４）ＩｕｂとＩｕｒインタフェースによるトラフィックをスムーズにし、（５）ＳＲＮＣから送信され、しかし、ノードＢではまだ受信していないＭＡＣ−ｄ ＰＤＵの量を低減することを示唆する。ＳＲＮＣからの伝送が非常に低速であるために、送信され未だ受信していないＭＡＣ−ｄ ＰＤＵの数をできる限り小さく保つことは重要である。

図５には、本発明に従うフロー制御システムが示されており、それはＩｕｂインタフェースにより容量割当て機器２３と通信している容量要求機器２２とを有している。その容量要求機器はＳＲＮＣ内にあり、容量割当て機器はノードＢにある。ＳＲＮＣは図式的に示されているデータストリーム１２でユーザデータをノードＢに配信する。スケジューラ１６は容量割当て機器と通信を行なって、バッファ９でスケジュールされた個々のユーザデータが送信器２４を介してタイムスロットで共用無線チャネルにより送信される順序を制御する。個々のユーザデータが送信される順序は、バッファ出力における個々のスイッチ２５が閉じる順序に対応している。２つ以上のスイッチが同時に閉じられることは決してない。データフロー制御手段２６が示されており、ＳＲＮＣの個々のバッファ８の出力で接続されている。各フロー接続手段は容量要求機器からの個々の制御信号２７を受信する。個々の制御信号は、ノードＢにより発行された以前に述べた量のクレジット（割当てられたＭＡＣ−ＰＤＵの数）を含んでいる。参照番号２８は、ユーザエンティティＵＥ１、ＵＥ２、……ＵＥｉに対する個々の無線チャネルに関するチャネル品質指標ＱＩ１、ＱＩ２、……ＱＩｉを表している。容量割当て機器は、個々のＵＥに対して１つずつ備えられ、個々のユーザデータフローに対する未処理のクレジットの数をカウントするカウンタ２９を有している。説明を明瞭にするために、図５には図示されていないが、その容量割当て機器はまた、個々のＵＥ夫々に対して２つ以上のカウンタを備え、１つはＳＲＮＣで処理待ち中であるユーザデータユニットのユーザ数をカウントし、もう１つは割当てフレームがＳＲＮＣに送信されるべきとき、その瞬間の時間を計算する。

容量要求機器と容量割当て機器とはハードウェアとソフトウェアの両方で実装される。データフロー制御手段１４はＳＲＮＣの不図示のコンピュータで実行されるコンピュータプログラムによって実現される。

容量割当て機器により用いられるフロー制御プロセスはノードＢの不図示のコンピュータで実行されるコンピュータプログラムである。そのコンピュータプログラムは本発明に従うフロー制御プロセスの以下に説明する各工程を実行するソフトウェアコードの部分を有している。そのコンピュータプログラムはコンピュータが利用可能な媒体、例えば、フロッピィ（登録商標）ディスク、ＣＤレコード、インターネットなどから直接ローディングされる。

本発明に従う第１のフロー制御プロセスはノードＢで実行する。第１のフロー制御プロセスは次の部分では、フロー毎を基本とするフロー制御プロセスと呼ばれる。なぜなら、それは他のユーザのデータフローとは独立に各ユーザのデータフローを制御するからである。説明を明瞭にするために、１つのユーザに言及して説明する。

フロー毎を基本とするフロー制御において、容量要求と容量割当てフレームとは、１つのデータフローに関してノードＢとＳＲＮＣとの間で交換される。ノードＢは規則正しく容量割当てフレームを送信することにより、容量要求に応答する。言い換えると、容量割当ては、ＵＥに対して処理待ちであるデータユニットがＳＲＮＣにある限り、ある固定時間間隔で定期的に実行される。この割当て間隔は図４では“Ｒ”の印が付けられている。

本発明に従うフロー毎を基本とするフロー制御は次の工程を有している。

１．ＳＲＮＣは容量要求をノードＢに送信する。一般にはＭＡＣ−ｄ ＰＤＵの単位で表現され、その容量要求があった時点でＳＲＮＣでは処理待ち中であるユーザデータユニットの数は、容量要求フレームで示される。その処理待ちデータは、ＳＲＮＣで完全に処理されるＭＡＣ−ｄ ＰＤＵとして定義され、従って、ノードＢのバッファに送信するためにＳＲＮＣを離れる用意ができている。

２．ノードＢは要求フレームを受信し、処理待ちのＭＡＣ−ｄ ＰＤＵの数を読み出して、その新しい値でカウンタの以前の値を上書きする。その結果、ノードＢはＳＲＮＣのバッファの状態（フル、空き、或いは、それらの中間の値）についてのいくらかの知識を得る。

３．ノードＢは、現在バッファされているＭＡＣ−ｄ ＰＤＵの数を、前もって定義されたある目標値、例えば、利用可能なメモリ全空間から減算することにより、バッファが受け入れ／受信できるＭＡＣ−ｄ ＰＤＵの数を計算する。

４．ノードＢは、承諾されたクレジットの量、即ち、（容量割当ての時点で）ＳＲＮＣからノードＢに移動するＭＡＣ−ｄ ＰＤＵの数を計算する。そのクレジットは次の工程に従って計算される。

ｉ．未処理のクレジットの量を計算する。未処理のクレジットは、ＭＡＣ−ｄ ＰＤＵの対応する数は未だノードＢのバッファには到着していないが、既に承諾されたクレジットの数として定義される。

ii．ノードＢのバッファが受け入れ／受信できるＭＡＣ−ｄ ＰＤＵの数とＳＲＮＣで処理待ち中で留まっているＭＡＣ−ｄ ＰＤＵの数とを比較する。承諾されたクレジットの潜在的な数として少ない方の数を選択して、割当て容量が決して要求容量を超えることのないことを保証する。

iii.承諾されたクレジットの選択された潜在的数からクレジットの未処理の数を減算し、これを承諾されたクレジットの数として用いる。

５．ノードＢは容量割当てフレームをＳＲＮＣに送信する。承諾されたクレジットの数は割当てフレームで示される。

比較の工程iiは非常に重要なものである。もし、それが省略されるなら、長期的にはクレジット数は結局のところ大きな数になるであろう。そのフロー制御プロセスは、多くの未処理クレジットがあり（それは正しくない）、これ以上のクレジットが割当てられずバッファがアンダフローになるので、ノードＢへのデータフローが詰まってしまうと考えるであろう。比較の工程iiはクレジット割当てプロセス／方式と呼ばれる。

フロー毎を基本とするフロー制御を用いる主な利点は、その耐性が強い点にある。それは必要とされるもの以上にノードＢへのユーザデータユニットをフェッチすることは決してなく、それはノードＢが２つの割当て事象の間にユーザに送信できる以上のユーザデータを決して受信することはないことを意味している。従って、そのバッファは決してオーバフローすることはない。比較の工程iiはこのことを見ているのである。そのフロー制御プロセスはノードＢにおけるバッファされたデータのキューの長さを一定に保つようにし、決して超えることのない上限が存在する。

予め定義された目標レベルはバッファにおけるアンダフローを回避するのに十分に高いものであり、ＵＥに対してスケジュールされたデータ量より高くはない。

例１
図６において、ＳＲＮＣバッファにはノードＢにおける１個のユーザバッファに送信するための処理待ち中のＭＡＣ−ｄ ＰＤＵが１００個あるとする。また、この１個のユーザバッファは全バッファ容量が９０個分のＭＡＣ−ｄ ＰＤＵであり、バッファ要求フレームの受信時には１０個のＭＡＣ−ｄ ＰＤＵがノードＢに現在バッファされているとする。また、３つの以前の事象では、ノードＢはＳＲＮＣに、１０個、２０個、３０個のクレジット（ＭＡＣ−ｄ ＰＤＵの単位で表現）を与えたとする。従って、これら６０個のＭＡＣ−ｄ ＰＤＵが未処理のクレジットであり、対応するＭＡＣ−ｄ ＰＤＵはノードＢによって（例えば、伝送遅延などのために）未だ受信されていない。ＳＲＮＣとノードＢにおける１個のユーザバッファの状態が図６の上方に例示されている。

ＣＡＰＲＥＱ１００と印が付いた矢は、フロー毎を基本とするフロー制御プロセスにおけるステップ１を表わし、その矢の先端はステップ２を表現している。ステップ３はノードＢのバッファで図示されている。全バッファ空間（９０個のＭＡＣ−ｄ ＰＤＵ）の内、１０個が占有され、まだ８０個分のＭＡＣ−ｄ ＰＤＵのための余地が残されている。ステップ４ｉを適用するとその結果、１０＋２０＋３０＝６０個の未処理クレジットがある。ステップ４iiを適用することの意味は、ノードＢは８０個分のＭＡＣ−ｄ ＰＤＵのための余裕をもっていることである。この“８０”という数値は、ＳＲＮＣが送信を望んでいる１００個のＭＡＣ−ｄ ＰＤＵと比較すべきである。バッファのオーバフローを回避するために、より少ない数値“８０”が選択されている。そのバッファはこれら８０個に対して利用可能な十分なメモリ空間があることを保証する。ステップ４iiiでは、クレジットの未処理の数（６０個のＭＡＣ−ｄ ＰＤＵ）が、選択された数値（８０個のＭＡＣ−ｄ ＰＤＵ）から減算して２０個のＭＡＣ−ｄ ＰＤＵを残す。従って、２０個のクレジットが与えられる。２０Ｃ（クレジット）の印が付いた矢はステップ５を表す。１０、２０、３０の印が付いた次の矢は、ＳＲＮＣが以前に承諾されたＭＡＣ−ｄ ＰＤＵをノードＢの同じユーザバッファに送信するときの事象を表している。これらが送信される順序は必ずしも示されたものである必要はなく、変化しても良い。最後に、２０Ｃと印の付いた一番下の矢によって表現されているように、ステップ４iiiで割当てられたＭＡＣ−ｄ ＰＤＵがノードＢに送信される。

２０個のクレジットがＳＲＮＣに送信されるとき、上部の矢２０Ｃによって表現されるように、ノードＢの対応する未処理クレジットカウンタ２９は、２０個のＭＡＣ−ｄ ＰＤＵだけ、その未処理クレジットの計数値を増加させる。データユニットがノードＢの対応するユーザデータバッファに到着するときにはいつでも、その未処理クレジットの計数値は減少する。未処理クレジットカウンタを用いる主な利点は、容量割当てからの結果は常に予測可能であり、それ故に、そのバッファはオーバフローからの危険を決して被ることはない点にある。

ノードＢにおける固定バッファリング資源は、ＨＳ−ＤＳＣＨにより可能な最大送信速度を用いて連続送信をするなら、１つのデータストリームをサポートするのにもほとんど十分ではない。

従って、フロー毎を基本とするフロー制御プロセスはバッファのオーバフローの問題を扱うであろう。それは、ＳＲＮＣはノードＢで利用可能なバッファ空間よりも大きな処理待ちユーザデータをもつという推定に基づいたものである。

なお、実際には、ステップ３で全ての利用可能なバッファ空間を計算するとき、そのバッファは決して最大値になることはなく、それより少ない前記予め定義された目標レベルにまで達する。

次に、ノードＢで実行する第２のフロー制御プロセスについて説明する。この第２のフロー制御プロセスは以下、ノード毎を基本とするフロー制御プロセスと呼ばれる。なぜなら、それはノードＢの全てのアクティブなユーザのデータフローを調和のとれた方法で制御するからである。ノード毎を基本とするフロー制御プロセスがあると、１ユーザのデータフローは他のユーザのデータフローに依存して制御される。個々のデータフローが従って調整される。

ノード毎を基本とするフロー制御プロセスでは、容量要求フレームと容量割当てフレームとが、フロー毎を基本とするフロー制御プロセスのように、ノードＢとＳＲＮＣとの間で交換される。ノードＢにおける要求バッファ容量の総量が計算され、ノードＢにおける利用可能なバッファ資源の総量が、何らかの未処理クレジットを考慮して計算される。最後に、データフローの個々の無線チャネル品質／指標に比例して、個々のデータフロー間でクレジットが分配される。このようにして、データフローが調整される。希少なバッファリング資源は、幾つかの別々のデータフロー間で共有される。利用可能なバッファ資源の総量を計算するために、利用可能なバッファ資源の各アクティブユーザ量が、フロー毎を基本とするフロー制御プロセスにおけると同じステップ１〜５を用いて計算され、互いに加算される。要求バッファ全容量と利用可能なバッファ全容量と未処理クレジットの総量に言及する言葉で、ステップ１〜５の表現を置換することにより、ノード毎を基本とするフロー制御プロセスは、ステップ４iiiに続くステップ４iiiiをさらに有する。

４iiii．各ＵＥが経験する無線チャネル品質／指標に比例して、個々のデータストリーム間で得られたクレジットの総量を分配する。

ステップ４iiiiは、クレジット割当てプロセス／方式と呼ばれる。

チャネル品質指標を用いることの主な利点は、メモリ資源が効率的に使用されることにある。なぜなら、バッファされたデータの主要な部分は、おそらくは、良好なチャネル品質のために大量のデータを受信できるユーザに属しているからである。空中インタフェースＵｕによって流れるデータ量は無線チャネル品質に依存する。ノード毎を基本とするフロー制御プロセスを用いると、ノードＢがユーザに送信できる以上のデータユニットがノードＢに送信されない。従って、ユーザはバッファされたユーザデータの全てを受信することができないのであるから、バッファを最大限までいっぱいにするのは意味がない。

ユーザは同じ希少なメモリ資源を共用し、その希少なメモリ資源は、各チャネル品質に従ってユーザ間で分割される。品質の悪いチャネルをもつユーザはそれ故にデータを何も受信しない。

ノードＢにおいてバッファされたデータの総量は本質的には一定を維持し、それは目標レベルに等しい。また、そのバッファデータ量は、フロー毎を基本とするフロー制御プロセスと比較してより少ない。なぜなら、それはユーザの数に比例しないからである。フロー毎を基本とするフロー制御プロセスでは、ノードＢのバッファに格納されるデータ総量は全てのキューの総計であり、それはユーザの数に比例する。

フロー毎を基本とするフロー制御プロセスでのように、ノード毎を基本とするフロー制御プロセスはノードＢに格納されるデータ量を最小にするが、そのように格納されたデータは依然としてアンダフローを排除するのに十分である。ノード毎を基本とするフロー制御プロセスにおいて、キューの長さはより短い。なぜなら、データは最良のチャネル品質をもつユーザに転送され、それ故に、それらく、そのデータはすばやく処理される。最良の無線チャネル品質をもつユーザは、即ち、データをそのタイムスロットで、その無線チャネルが送信可能な最大のデータ速度で等しい量で送信することが許可される。このことは、割当てのあった時点で良好なチャネル品質をもつユーザはまた、その割当てられたデータが後でノードＢに到着するときにも良好なチャネル品質をもっていると思われるという推定に基づいている。その無線チャネル特性は時間相関のあるものである。

ノード毎を基本とするフロー制御プロセスを用いると、全てのデータを１ユーザに最大データ速度で送信するよりも多くのデータを複数のユーザに送信することはできない。このことは、次のことを意味する。ノードＢは高速データ速度で送信する１ユーザがあり、このユーザはまたＳＲＮＣからデータを受信するとする。さて、もし、新しいユーザがシステムに追加されたなら、そのユーザに対するデータをフェッチするという思想はない。なぜなら、彼らはそのメモリ資源を他のユーザを共用し、彼らの中では、全ての資源を握る１ユーザ、即ち、そのＵＥに最大データ速度で送信するユーザがある。

フロー毎を基本とするフロー制御プロセスのように、ステップ４iiのためにノード毎を基本とするフロー制御プロセスを用いると、オーバフローはない。

ノード毎を基本とするフロー制御プロセスを用いることのさらに別の利点は、大部分のデータがＳＲＮＣに格納され、それ故に、もしシステムの下位レベルで何かの不具合が生じても、データが喪失することはない点である。また、ハンドオフの問題も解決される。

従って、希少なバッファリング資源は、示されたチャネル品質に従って共用され、独立したパケットデータフローに割当てられたクレジット量は、ノードＢを通過するパケットデータフローの数に逆比例する。

バッファリング資源がチャネル品質に従って共用されるので、送信ユーザデータの実際量が時間的に変化しない場合、送信スケジュールを生成することができる。このことは、次のような極端な場合があると、その動機付けになる。１つのデータフローとステップ１〜５を有するフロー毎を基本とするフロー制御プロセスとがある場合、承諾されたクレジットが他のユーザの存在により影響を受けないので、流れるデータ量は変化しない。もし、ユーザ人口（ユーザエンティティの数）が多いなら、おそらくは良好な或いは最高度の無線チャネル条件にある１つ以上のユーザを見出すであろう。実際には、このことは、人口が多いと、ノードＢのチャネル依存の方式は非常に高速で変化のない伝送速度でデータをスケジュールできることを意味する。ノードＢにおけるバッファデータ量が示されたチャネル品質に比例するので、バッファのアンダフローが回避される。スケジューラはデータを最良の信号品質をもつユーザに送信する。ノード毎を基本とするフロー制御プロセスがユーザに流れるデータ量についてもつかもしれない影響は一般には小さい。

この場合の予め定義された目標レベルは、個々のバッファにおけるアンダフローを回避するには十分に高く、個々のＵＥに対してスケジュールされるデータ量よりも高くあるべきではない。

複数のＵＥ夫々はその無線チャネル品質を、図３に示された関連するアップリンクシグナリングパスによりノードＢにレポートする。

従って、ノードＢを横切る複数のデータストリームの間で比例的に共用される固定バッファリング資源をノードＢはもつ。ノードＢは、幾つかの独立なデータストリームからのバッファされるデータの総合計がノードＢで予め定義された一定のレベルに維持されるように個々の容量割当てを調整することにより、容量要求に応答する。その結果、バッファされたデータの総合計はノードＢを通過するパケットデータフローの実際の数に独立である。依然として、バッファのアンダフローは回避される。これは、幾つかの独立なデータストリームからのバッファされたデータの総合計が予め定義された一定レベルを下回って減少することは決してないためである。上述したことから示唆されるように、ＳＲＮＣは送信待ちのデータを常に含んでいると仮定される。

ノードＢにおけるＭＡＣ-ｄ ＰＤＵの到着速度は、ステップ１〜５を有するノード毎の割当てアルゴリズムで調整される。これは、各ＵＥによりレポートされるチャネル品質指標に基づいている。

上述のノードを基本としたフロー制御プロセスを用いると、ユーザデータの大部分はＳＲＮＣに格納され、最小限のデータがノードＢに格納される。さらに、ノードＢに格納されたデータはユーザへの送信のためにスケジュールされるデータであり、即ち、“不要”データはノードＢには格納されない。“不要”とは、もし、ハンドオーバが発生したなら、そのデータは喪失するという意味である。

例２
図７において、夫々が、ノードＢのバッファを通る水平の破線によって示唆されるように、ノードＢに対応するバッファをもつ３つのＵＥがあると仮定する。一般に、例１と同じ仮定が適用される。ノードＢの複数のバッファは種々のレベルにまで個々にいっぱいになる。これらを加算すると、それはノードＢのバッファが例１のように１０個のＭＡＣ-ｄ ＰＤＵで満たされることを示唆している。また、ＳＲＮＣは３つのＵＥに送信するための異なる量のユーザデータをもつと仮定する。これらの量が加算されたなら、ＳＲＮＣは例１のように、３つのＵＥに送信するためにＭＡＣ−ｄ ＰＤＵが合計１００個ある。例１のように、ノードＢのバッファの全メモリ空間は、９０個分のＭＡＣ−ｄ ＰＤＵである。最後に、ＵＥ１とＵＥ２とは両方とも、良好なチャネルを示唆するチャネル品質指標ＱＩ＝８をレポートし、一方、ＵＥ３は余り良くないチャネルを示唆するＱＩ＝４をレポートしたと仮定する。また、例１における仮定が適用され、ノードＢは９０個分のＭＡＣ-ｄ ＰＤＵである予め定義された総目標レベルをもつことを示している。

例１におけるステップ１〜４iiiに続き、承諾されたクレジットの数は２０個のＭＡＣ−ｄ ＰＤＵであり、それは、ステップ４iiiiにおいて、次の方程式にしたがって３つのＵＥの間で比例的に配分されるべきである。

即ち、０．８ｘ＋０．８ｘ＋０．４ｘ＝２０
ここで、ｘ＝１０である。

従って、ＵＥ１には０．８ｘ５＝８メモリユニットが割当てられる。

従って、ＵＥ２には０．８ｘ５＝８メモリユニットが割当てられる。

従って、ＵＥ３には０．４ｘ５＝４メモリユニットが割当てられる。

ステップ５では、承諾されたクレジットの数が送信される。２０（８，８，４）Ｃ（クレジット）と印が付けられた上から２番目の矢は、ステップ５を表している。１０、２０、３０の印が付いた次の矢は、ＳＲＮＣが以前に承諾されたＭＡＣ−ｄ ＰＤＵをノードＢの３つの異なるＵＥのユーザバッファに送信するときの事象を表している。最後に、８、８、４と印の付いた３つの一番下の矢によって表現されているように、ステップ４iiiiで計算されたＭＡＣ−ｄ ＰＤＵがＵＥ１、ＵＥ２、ＵＥ３のバッファに送信される。

承諾されたクレジットの数（ＭＡＣ−ｄ ＰＤＵで表現）はまた、複数のＵＥに送信されるＰＤＵの同じ数である。ノードＢはこれらを受信するのに利用可能なメモリ空間をもつであろう。

従来例で用いられたフロー毎を基本とするフロー制御プロセスが用いられ、例２の数値が適用されるなら、ユーザＵＥ１に対するノードＢのバッファは、８０個の潜在的なクレジット−（マイナス）未処理の１０個のクレジット、即ち、７０個のＭＡＣ−ｄ ＰＤＵのクレジットがＳＲＮＣに送信されるのが承諾されているのである。ユーザＵＥ２に対するノードＢのバッファは、８０個の潜在的なクレジット−（マイナス）未処理の２０個のクレジット、即ち、６０個のＭＡＣ−ｄ ＰＤＵのクレジットが承諾されているのである。同様に、ユーザＵＥ３に対するノードＢのバッファは、８０個−３０個のＭＡＣ−ｄ ＰＤＵ、即ち、５０個のＭＡＣ−ｄ ＰＤＵのクレジットが承諾されているのである。合計で５０＋６０＋７０＝１８０個のＭＡＣ−ｄ ＰＤＵが承諾され、バッファのオーバフローを示唆している。

典型的なＵＴＲＡＮシステムでは、ＩｕｂとＩｕｒのインタフェースによる遅延は、容量要求がＳＲＮＣから送信される周期と比較して非常に大きい。このことは、ノードＢが何らかのユーザデータを受信する前に幾つかのクレジット値を送信できることを意味している。それ故に、ＳＲＮＣからノードＢにダウンロードされたデータが以前の事象において良好なチャネル品質を示したユーザのためのデータであり、後になってダウンロードされたデータが高い確率で短い時間内、それがノードＢに到着後ほとんど即座にスケジュールされることを重要である。このことは、わずかな量のデータだけがノードＢのバッファに格納される必要があることを示唆しており、これによって、ノードＢにおけるバッファメモリの全サイズを最適化する。ダウンロードされるデータはおそらくほとんど即座的にスケジュールされるであろうＵＥに対するものであることが意図されており、それ故に、“不要”データはノードＢには格納されない。“不要”とは、もしＵＥがハンドオーバを実行したなら喪失することを意味している。低いチャネル品質をもつＵＥはおそらくはハンドオーバ手順を行なうことにあろうが、ノード毎の割当て方式に従えば、そのようなＵＥはＳＲＮＣからわずかな量のユーザデータを受信するに過ぎないであろう。

図８と図９とはノードＢで実行するフロー毎を基本とするフロー制御プロセスを図示したものである。以下、１つのユーザに関してのフロー制御を説明する。なお、全てのユーザフローが同じような方法で制御されることを理解されたい。そのフロー制御は、ボックス８０で未処理クレジットカウンタをゼロにセットすることで開始する。次に、そのフロー制御はボックス８１でループに入り、ＳＲＮＣからの容量要求フレームを待ち合わせる。そのフレームはＳＲＮＣで個々のユーザに対して処理待ちのユーザデータユニットの量を示している。要求フレームを受信すると、そのフロー制御は、選択ボックス８２で全体的に見られるように、データ要求量とノードＢで利用可能なメモリ空間の量とを比較する。２つの可能性が存在する。利用可能なメモリが十分であるか、或いは希少であるかである。もし、利用可能なメモリが十分であれば、ボックス８３において、承諾されたクレジットは処理待ちのユーザデータユニットの数に等しいようにセットされる。これはＳＲＮＣに全ての処理待ち中のユーザデータを送信することを伝える。もし、利用可能なメモリが希少であれば、ボックス８４において、クレジット量は利用可能なメモリ空間に等しいようにセットされる。両方の場合において、未処理クレジットカウンタのクレジット数がちょうど計算された未処理クレジットの数にセットされ、ボックス８５において、割当てフレームが送信される。そのフロー制御ではループが継続し、図９では、ボックス９０において、ノードＢに到着するユーザデータを待ち合わせる。もし、ユーザデータが到着したなら、ボックス９１では受信データユニットの数が未処理クレジット数から減算される。容量要求フレームがＳＲＮＣから到着すると、ボックス９３では、処理待ちユーザデータのためにそのカウンタの古い処理待ちユーザデータ数が、容量要求フレームで示される処理待ちデータの数で上書きされる。決定ボックス９４では、割当てフレームが送信されるべき時刻の計算を行なうカウンタはノードＢにおけるキューイングユーザデータ長を監視し、割当てフレームがいつ送信されるべきなのかを決定する。もし、そのキューが短くなる傾向があったり、キューイングデータの数がゼロになるなら、ボックス９５では割当てフレームが送信される。その割当てフレームがまさに送信されようとするとき、上記ステップ１〜４が実行され、承諾されたクレジットの数が、利用可能なメモリ空間と、ＳＲＮＣにおける処理待ちユーザデータ量と、未処理クレジットの数の関数として計算される。最後に、未処理クレジットカウンタが計算された承諾クレジットの数で増加され、割当てフレームが送信される。次に、選択ボックス９６では、フロー制御では、ループを継続する何らかの理由があるかをチェックする。それが、ボックス９５で送信された最後の割当てフレームであったなら、ユーザはこれ以上アクティブではなく、選択ボックス９６でＮＯとなって、そのループから出口へと抜けることになる。もし、割当てるデータがまだあるなら、選択ボックス９６ではＹＥＳとなって、そのフロー制御のループは選択ボックス９０へと戻り、さらなるユーザデータの到着をチェックする。データが到着すると、ボックス９１では到着データ量が未処理クレジットカウンタから減算される。

代替案として、割当てフレームが送信されるべき時刻を計算するカウンタは、容量要求フレームの内容に係りなく、１０ｍｓ毎に割当てフレームを送信するカウンタで置換しても良い。

図１０は、図８〜図９に従うフロー毎を基本とするフロー制御により送信される割当てフレームについて、承諾フレームの数がどのように計算されるのかを示したものである。上記ステップ３と４ｉ〜４iiiがボックス１００で実行される。次に、選択ボックス１０１で、クレジットの割当て数が決して要求容量（＝処理待ちユーザデータの数）を超えないことを保証するために比較がなされる。もし、クレジットの割当て数の方が大きいなら、ＹＥＳとなって、ボックス１０２において、クレジットの承諾数がＳＲＮＣにおける処理待ちユーザデータの数に等しくなるようにセットされる。ステップ１０１は、もし、承諾クレジットが処理待ちデータ量を超えるなら、未処理クレジットカウンタ２９が信頼できる情報を提供できなくなるために重要である。特に、そのカウンタは減少するよりも増加することの方が頻繁に生じる。

ノードＢでバッファされるユーザデータの総量を最小化するために、希少なメモリ資源が、図１１〜図１２にそのフロー図が示されているノード毎を基本とするフロー制御機構を利用する容量割当て機器を用いて、経験するチャネル品質に比例的に、いくつかのユーザにより共用される。ノード毎を基本とするフロー図は多くのステップを有しているが、それらは図８〜図９のフロー毎を基本とするフロー図でのステップに類似しており、それらは、それ故に、同じ参照番号で印が付けられている。

図１１は、ボックス８０で未処理クレジットカウンタをゼロにリセットすることで開始する。次に、ループが実行され、そこでは、ボックス１１０でノードＢはＵＥからのチャネル品質レポートを受信し、これらのレポートはボックス１１１ではＵＥがレポートを送信する度ごとに処理される。このループはフロー制御とは独立に実行される。フロー制御は品質情報に基づいており、フロー制御レポートは、メモリ容量が割当てられるかどうかに係りなく処理される。このループはＵＥがノードＢを聴取する限り実行される。未処理クレジットを用いると、メモリがゼロになったノードＢは、ボックス８１でＳＲＮＣからの割当て要求の受信を待ち合わせる。要求が受信されると、ノードＢはＳＲＮＣに送信されるべきクレジット数を計算する。もし、データ量が非常に少なくで全てがノードＢのメモリに収まるなら、選択ボックス８２ではＮＯとなりボックス８３に進み、ノードＢは、承諾されたクレジットの数が要求容量に等しいことを示唆する割当てフローを安全に送信することができる。もし、メモリ資源が希少であるなら、選択ボックス８２はＹＥＳとなり、要求容量は承諾されず、その代わりにより少ないクレジットが与えられ、このことが数回生じる。特に、ＳＲＮＣに送信されるクレジットの承諾された数が非常に制限されなければならないので、対応するデータユニットがノードＢに到着するときには、全ての受信データがノードＢのメモリに入る余地があるであろうし、この時はボックス８２でＹＥＳとなり、処理はボックス８４に進み、ボックス１１２に進んで、“割当てフレームを送信する”。従って、ノードＢは全てのデータがＳＲＮＣからノードＢに転送されるまで、幾つかの割当てフレームを送信しなければならないであろう。図１１におけるＢでは、ノードＢが割当てフレームを送信したが、ＳＲＮＣから何のデータもまだ受信していないという状態になっている。割当てと送信の後、ノードＢは発生する事象を待ち合わせ監視する。

次のステップでは、ノードＢに到着するデータを待ち合わせる。ＳＲＮＣが送信する全てのデータが転送ネットワークで発生するエラーのために到着することが確かであるとは言えない。しばしば、データがＳＲＮＣからノードＢに到着する前に幾つかの割当てフレームを送信することも必要である。従って、図１１でなされる割当てはしばしば十分ではない。割当てフレームが転送ネットワークで消失する場合さえあるかもしれない。そのような場合、再送がなさればならない。図１２におけるフロー制御プロセスはこのような場合を扱っている。

図１２は５つの事象がある。即ち、（１）ボックス９０でデータがノードＢに到着する。（２）ＳＲＮＣは、ボックス９２で新しい容量要求フレームを送信する。（３）選択ボックス９４で、新しい割当てフレームを送信する時がある。（４）ボックス９６で、全てのＵＥがノードＢを離れる。（５）選択ボックス８１では、複数のＵＥのいずれかがチャネル品質レポートを送信する。事象（１）は未処理クレジットカウンタが更新されつづけるために必要である。事象（２）はＳＲＮＣが容量要求をいつでも送信でき、ノードＢがより多くの容量を割当てることによりこれに応答しなければならないために必要である。新しいデータがいつＳＲＮＣに到着するのかを予測することはできず、この到着に応答してＳＲＮＣは容量要求を送信するのであるから、（例えば、インターネットとＳＲＮＣとの間の）この知られることのない到着プロセスが、フロー制御プロセスがＳＲＮＣとノードＢとの間で必要とされる理由である。事象（３）はノードＢが、メモリ資源が希少であるためにＳＲＮＣが要求する同じ量のデータを割当てることは必ずしもできず、ノードＢはしばしば複数の割当てフレームを送信しなければならないので必要である。もし、事象（３）がないとするなら、決してフロー制御は必要ではないであろう。なぜなら、ＳＲＮＣはすぐさまノードＢに対して全てのデータを送信するからである。一旦、割当てフレームを送信する時間となったなら、ボックス１２０では、クレジットの量が計算され、各チャネル品質に比例して個々のユーザ間でそのクレジットが分配される。事象（４）は、システムにＵＥがないとき、制御ループの実行を休止するために必要である。事象（５）は、連続的にチャネル品質指標を処理するために存在している。なお、割当てが生じるよりも頻繁に、２ｍｓの間隔で品質はレポートされる。割当て頻度は１０ｍｓおきである。ＳＲＮＣにおける全てのデータが転送されるまで、その制御ループは繰り返される。

図１３で実行される処理ステップに図１４の処理ステップが続き、これらは共に、図１２におけるボックス１２０で実行される処理ステップを説明している。第１のステップ、ボックス１３０では、ノードＢにおけるキューイングデータの総量が、ノードＢにおける全てのアクティブバッファにおけるキューイングデータユニットの数を合計することにより計算される。これは上述したステップ３に対応している。第２のステップ、ボックス１３１では、ＳＲＮＣにおける処理待ちデータの総量が、ＳＲＮＣにおける全てのアクティブバッファにおけるキューイングデータユニットの数を合計することにより計算される。これは上述したステップ２に対応している。第３の処理ステップ、ボックス１３２では、未処理クレジットの総量がノードＢにおける全てのアクティブユーザバッファに関する未処理クレジットの数を合計することにより計算される。これは上述したステップ４ｉに対応している。次に、全てのアクティブユーザが、ボックス１３３において、それらが経験したチャネル品質に従って、ソーティングされリストになる。処理待ちデータをもたないユーザは次に、ボックス１３４において、リストから除かれる。チャネル品質の総合計は、ボックス１３５において、ソートされたリストの全てのユーザに関し、チャネル品質を合計することにより計算される。

次の処理ステップである、ボックス１４０では、ノードＢの処理待ちデータカウンタで示される、ノードＢにおけるキューイングデータ量とＳＲＮＣの処理待ちデータの総量と全ての未処理クレジットカウンタとを、ノードＢの利用可能なメモリ空間より減算し、承諾されたクレジットの全量を計算値にセットする。ボックス１４１では、メトリック（metric）で、（ソートされたリストにおける）最良のチャネル品質のチャネル品質の総合計ｆに対する割合を表す。次に、対応する最良の品質をもつユーザに対する承諾されたクレジットが、ボックス１４２において、前のメトリックと承諾された全クレジットとに基づいて計算される。決定ボックス１４３では、承諾されたクレジットの数が処理待ちデータの数よりも大きいかどうかの判断がなされる。もし、ＹＥＳであれば、最良のチャネル品質をもつユーザに対する承諾されたクレジットが、前記最良の品質をもつユーザに関して処理待ちのデータユニットの量にセットされる。このステップは図１０における処理ステップ１０２に対応しており、ステップ１４５がこれに続く。ステップ１４５では、最良の品質をもつユーザがリストから除かれる。ボックス１４３におけるＮＯには処理ステップ１４５が続き、次に判断ボックス１４６が続く。ステップ１４６では、リストにユーザがあるかどうかをチェックする。もし、ＹＥＳであれば、処理ステップ１４１へのループを開始する。そのループでは、リストに残されたユーザがなくなるまで処理ステップ１４１〜１４５を実行する。スケジュールに用いられる方式は、チャネルに依存していても良いし、ラウンドロビンタイプでも良い。

チャネル依存のスケジューリングは、データは最善のチャネル品質をもつＵＥに送信されることを意味する。もし、本発明に従うＳＲＮＣとノードＢとの間のフロー制御アルゴリズムがまた、ノードＢと統計的には最善のチャネル品質をもっていると見られるＵＥとの間での伝送をスケジュールするのに用いられるなら、非常に少量のデータがノードＢのバッファに格納されるのが必要なだけであり、そのように格納されたデータは正しいユーザに対するデータであり、ノードＢに到着時にすぐさまスケジュールされるデータである。従って、本発明は、（ノードＢにおける）非常に大容量のバッファメモリと、従来のフロー毎の割当て方式に類似している。

ＵＭＴＳシステムの模式的な図である。 ＳＲＮＣとノードＢにおけるバッファの模式的な図である。 ノードＢのブロック図である。 ＳＲＮＣとノードＢとの間の容量要求メッセージと容量割当てメッセージとの間の交換を例示する図である。 本発明に従うフロー制御システムのブロック図である。 本発明のフロー毎を基本としたクレジット割当て方式の例を図示したフロー図である。 本発明のノード毎を基本としたクレジット割当て方式の例を図示したフロー図である。 フロー毎を基本としたフロー制御機構のフローチャートの１部である。 図８のフローチャートに続くフローチャートである。 図９のフローチャートにおける承諾されたクレジットの計算を示すフローチャートである。 本発明に従うノード毎を基本としたフロー制御機構のフローチャートの１部である。 図１１のフローチャートに続くフローチャートである。 ノード毎を基本としたフロー制御機構のフローチャートの始めの部分である。 図１３のフローチャートに続くフローチャートである。

Claims (9)

1. 無線伝送ネットワークにおける無線ネットワーク送信ノード（４）と無線ネットワーク受信ノード（６）との間のデータフローを調整し、前記送信ノードでは容量要求（１０）を、前記送信ノードにおいて処理待ち中にある指示された数のデータユニットを送信する許可を要求する前記受信ノードに送信し、前記受信ノードでは前記容量要求に応答して、前記送信ノードが送信のための許可を与えられたデータユニットの、クレジットとして言及される数を示す割当てフレーム（１１）を前記送信ノードに送信する、フロー毎に用いられる制御方法であって、
   前記受信ノードにおけるデータユニットを格納するバッファ資源（９）が枯渇する恐れがある場合、前記送信ノードと前記受信ノードとの間のデータフロー（１２）に関し、前記受信ノードは、
   要求されたデータユニットの数を即時的に計数する工程と、
   対象バッファの充填レベルから、
   前記バッファに現在格納されているデータユニットの数と、
   以前に与えられ、しかし未だ受信していない、未処理のクレジットとして言及されるものよりも少ないクレジットの数とを
   減算することにより、承諾されるクレジットの数を計算する工程と、
   前記容量要求に応答して、前記送信ノードに送信するために、前記計算された承諾されるクレジットの数を割当てフレーム（１０）に挿入する工程とを
   実行することを特徴とする制御方法。
2. 前記バッファに現在格納されているデータユニットの数と要求されたデータユニットの数とを比較する工程と、
   前記承諾されたクレジットの数を取得するために未処理のクレジットの数が減算される承諾されるクレジットの潜在的な数として、前記比較する工程における数の内の少ない方の数を選択する工程とをさらに有することを特徴とする請求項１に記載の制御方法。
3. 前記受信ノードは、未処理のクレジットの数の変化する計数値を、
   割当てフレームが送信される度ごとに前記計数値を前記割当てフレームにおいて示される承諾されたクレジットの数とともに増加させ、
   データユニットを受信する度ごとに前記計数値を受信されたデータユニットの数とともに減少させることにより、
   保持することを特徴とする請求項２に記載の制御方法。
4. 無線伝送ネットワークにおける無線ネットワーク送信ノード（４）と無線ネットワーク受信ノード（６）との間のデータフローを調整し、前記送信ノードでは容量要求（１０）を、前記送信ノードにおいて処理待ち中にあるデータユニットの指示された数を送信する許可を要求する前記受信ノードに送信し、前記受信ノードでは前記容量要求に応答して、前記送信ノードが送信のための許可を与えられたデータユニットの、クレジットとして言及される数を示す割当てフレーム（１１）を前記送信ノードに送信する、ノード毎に用いられる制御方法であって、
   前記受信ノードにおけるデータユニットを格納する複数のバッファ資源（９）が枯渇する恐れがある場合、前記送信ノードと前記受信ノードとの間のデータフロー（１２）夫々に関し、前記受信ノードは、
   各データフローにおいて要求されたデータユニットの数を即時的に計数して、要求されたデータユニットの総数を取得する工程と、
   前記データフローの総数に関し、対象バッファの充填レベルから、
   前記バッファ各々に現在格納されているデータユニットの総数と、
   以前に与えられ、しかし未だ受信していないクレジットの総数とを
   減算することにより、各データフローにおいて承諾されるクレジットの総数を計算する工程と、
   前記受信ノードのクレジットの総数を複数のユーザエンティティ各々により示される無線チャネル品質（２８）に比例的に分配する工程とを実行することを特徴とする制御方法。
5. 全てのデータストリームにおけるユーザデータの総計を前記ユーザ単位の要求された数以下の所望の値に限定することを特徴とする請求項４に記載の制御方法。
6. 無線伝送ネットワークにおける無線ネットワーク送信ノード（４）と無線ネットワーク受信ノード（６）との間のデータフローを調整し、前記送信ノードでは容量要求（１０）を、前記送信ノードにおいて処理待ち中にあるデータユニットの指示された数を送信する許可を要求する前記受信ノードに送信し、前記受信ノードでは前記容量要求に応答して、前記送信ノードが送信のための許可を与えられたデータユニットの、クレジットとして言及される数を示す割当てフレーム（１１）を前記送信ノードに送信する、ノード毎に用いられる制御方法であって、
   前記受信ノードがスケジュールしてデータユニットを無線伝送する複数のユーザエンティティ（７）夫々により示される無線チャネル品質（２８）に、前記受信ノードにより与えられたクレジットの数を比例的に分配することを特徴とする制御方法。
7. バッファ資源（９）と、個々のユーザエンティティ（６）に個々の量のユーザデータを割当てる容量割当て機器（２３）と、フロー制御プロトコルと、スケジューラ（１６）とを有し、送信ノード（４）からのデータのフローを調整する無線ネットワーク受信ノード（６）であって、
   前記容量割当て機器（２３）は、データユニットの対応する数はまだ前記受信ノード（６）には到着していないのであるが、前記容量割当て機器が前記送信ノード（４）が送信するのを許可したデータユニットの数として定義された未処理のクレジットの瞬間的な数の変化する計数値を保持するカウンタ（２９）を有することを特徴とする無線ネットワーク受信ノード。
8. 前記容量割当て機器は、前記送信ノードにおいて処理待ち中のユーザデータの変化する計数値を保持するカウンタを有することを特徴とする請求項７に記載の無線ネットワーク受信ノード。
9. 前記スケジューラ（１６）がスケジュールしてデータユニットを無線伝送する複数のユーザエンティティ（７）夫々により示される無線チャネル品質（２８）に、前記受信ノードにより与えられたクレジットの総数を比例的に分配するために適合された分配機器を有することを特徴とする請求項７又は８に記載の無線ネットワーク受信ノード。
   

Images