JP5238036B2 - Ｈｓｄｐａフロー制御におけるｒｌｃウインドウサイズの制限 - Google Patents

Description

本発明は、無線ネットワークにおいて効率的かつロバストなフロー制御の実施を可能にする装置および方法に関する。

より高いスループット、すなわちより高いビットレートの要求と、無線ネットワークによるパケットデータのより効率的な伝送の要求とが増大するにつれて、第３世代パートナーシッププロジェクト（３ＧＰＰ）は、高速ダウンリンパケットアクセス（ＨＳＤＰＡ）の仕様を拡張している。ＨＳＤＰＡの中に、高速ダウンリンク共用チャネル（ＨＳ−ＤＳＣＨ）と呼ばれる、新しい共用ダウンリンクトランスポートチャネルが導入されている。このチャネルは、主に時間領域においてパケットデータユーザ間で動的に共用される。共用チャネルの利用は、利用可能な無線リソースの使用をより効率的にする。ＨＳＤＰＡは、適応変調符号化（ＡＭＣ）とも呼ばれる、伝送パラメータの瞬間的な無線状態への迅速な適応に頼る新しい機能もサポートする。ＨＳＤＰＡの主な機能には、高速リンクアダプテーション、高速ハイブリッドＡＲＱ（ＨＡＲＱ：Ｈｙｂｒｉｄ−Ａｕｔｏｍａｔｉｃ Ｒｅｐｅａｔ Ｒｅｑｕｅｓｔ）、およびチャネル状態依存高速スケジューリングを含む。

ＨＳＤＰＡが出現する前は、トランスポートチャネルが、リリース９９のネットワークなど、無線ネットワーク内の無線ネットワーク制御装置（ＲＮＣ）で終端されていた。これは、例えばＡＲＱに役立つパケットデータの再送信などの機能が、ＲＮＣに配置されていたことを意味する。ＨＳＤＰＡの出現で、ＵＭＴＳ（Ｕｎｉｖｅｒｓａｌ Ｍｏｂｉｌｅ Ｔｅｌｅｐｈｏｎｅ Ｓｙｓｔｅｍ）地上無線アクセスネットワーク（ＵＴＲＡＮ）などの無線ネットワークにおいて、無線フレームスケジューリングの制御は、ＲＮＣからＮｏｄｅ Ｂ、すなわち基地局に移されている。このように、パケットデータの送信および再送信は、Ｎｏｄｅ Ｂが直接制御してもよく、そうすることにより、より高速な再送信をもたらす。これは、順により短い遅延およびよりよいスループットをもたらす。

図１は、一例のＵＴＲＡＮシステム１００を示す。システム１００は、Ｉｕインタフェースを通じてコアネットワーク（図示せず）と通信しているＲＮＣ１１０を有する。システムは、Ｉｕｂインタフェースを通じてＲＮＣ１１０に接続された、Ｎｏｄｅ Ｂ１２０としても知られる無線基地局も複数有する。ユーザ装置（ＵＥ）１３０は、通常は移動端末であり、Ｕｕインタフェース（無線リンク）を通じて１つ以上のＮｏｄｅ Ｂ１２０と通信する。Ｎｏｄｅ Ｂ１２０とＲＮＣ１１０との間のＩｕｂインタフェースは、Ｎｏｄｅ Ｂ１２０内のバッファが適切に使用されるのを確実にして、バッファオーバーフローによるデータ損失を確実に防ぐフロー制御（ＦＣ）メカニズムを有する。

ＵＴＲＡＮでは、アクセスネットワークの従来の個別チャネル（ＤＣＨ）トラヒック用に、固定容量（例えば６４ｋｐｂｓ）が予約されてもよい。しかし、ＨＳＤＰＡに関しては、Ｕｕインタフェースのスループットがはるかに高く、かつより大きく変動するので、フロー当たり帯域幅予約は効率的でない。帯域幅予約が使用されない場合、ＲＮＣとＮｏｄｅ Ｂとの間のＩｕｂトランスポートネットワーク（ＴＮ）のみならずＮｏｄｅ ＢとＵＥとの間のＵｕインタフェースでもまた輻輳が起こりうる。現在のアーキテクチャでは、ＴＣＰは、アクセスネットワークの輻輳状況を効率的に解消できない、より下位レイヤでの再送信により、ＴＣＰから輻輳状況が見えなくなっているからである。それ故、ＨＳＤＰＡにおけるＲＮＣとＮｏｄｅ Ｂとの間のデータ転送を制御するために、フロー制御機能が採用されている。

３ＧＰＰ ＴＳ ２５．４０２

元々は、フロー制御（ＦＣ）は、Ｕｕインタフェースの伝送能力だけを考慮して、レイヤ２シグナリングの遅延を制限するように設計されていた。しかし、Ｕｕインタフェース容量の増加は、実際にはＩｕｂ ＴＮ容量の同様の増加と常に一致したわけではなかった。Ｉｕｂトランスポートリンクのコストは、依然として高く、格段に下がることは期待されていない。スループットが、Ｉｕｂ ＴＮリンクで利用可能な容量によって制限され、Ｕｕインタフェースの容量によって制限されないのは、よくあるシナリオである。これらのコストの高いＴＮリンクでは、高い効率を維持することが重要である。

ＨＳＤＰＡに係わるプロトコルレイヤおよびノードが図２に示されている。ＨＳＤＰＡ ＦＣはＮｏｄｅ Ｂに配置されている。ＦＣのタスクは、ＲＮＣからＮｏｄｅ Ｂへの媒体アクセス制御プロトコルデータユニット（ＭＡＣ−ｄ ＰＤＵ）の転送を調節することである。より正確には、ＦＣが、ＲＮＣ内の無線リンク制御（ＲＬＣ）バッファからＮｏｄｅ Ｂ内のＭＡＣ−ｈｓバッファへのデータ転送を調節する。

Ｉｕｂ ＴＮボトルネックとエアインタフェース（Ｕｕ）ボトルネックの少なくとも２つのタイプのボトルネックがある。典型的に、Ｉｕｂ ＴＮボトルネックはＲＮＣとＮｏｄｅ Ｂとの間の単一リンクであり、同じＮｏｄｅ Ｂの全フローが同じＴＮボトルネックバッファおよびＴＮ容量を共用する。これらのフローは、高優先トラヒック（例えばＤＣＨ）に使用された残りのＴＮ容量を利用しうる。同じセルに属する各フローはＵｕリソースを共用するが、各フローは、Ｎｏｄｅ Ｂ内にＭＡＣ−ｈｓバッファ形式の個別優先度付きキュー（プライオリティキュー：ＰＱ）を有する。Ｎｏｄｅ Ｂは、１つ以上のセルを有してもよい。ＦＣは、これらの変化するＴＮボトルネックおよびＵｕボトルネックの効率的な使用に責任がある。エンドユーザの高いスループットを維持する一方で、ゲームのような遅延に敏感なアプリケーションに対するエンドツーエンド遅延を短く維持することも望ましい。ＭＡＣ−ｄ ＰＤＵ用の遅延目標は、通常１００ｍｓ未満である。

ＨＳＤＰＡ ＦＣは、Ｉｕｂ ＴＮの輻輳およびＵｕの輻輳を回避または制限するために使用される。Ｎｏｄｅ Ｂでは、フロー制御機能がＨＳＤＰＡフローのビットレートを計算し、計算したビットレートをＲＮＣに標準容量割り当て（ＣＡ）制御フレームを用いて送信する。ＲＮＣでは、ＨＳＤＰＡがこのビットレートでシェーピングされる。実質的には、Ｉｕｂ ＴＮ部分またはＵｕ部分にある程度の輻輳がある場合、フロー制御機能がＨＳＤＰＡフローのビットレートを減らし輻輳を解消する。

一態様では、効率的かつロバストなＨＳＤＰＡフロー制御解決手段を提供しうるＲＮＣの動作方法が開示される。ＲＮＣは、Ｎｏｄｅ Ｂから下り方向のデータフローの許容データレートに関する情報を受信しうる。受信データレート情報に基づいて、および必要に応じて他の所定の考慮すべき事項に基づいて、ＲＮＣは、データフローに合わせてＲＬＣ ＰＤＵの転送のためのＲＬＣ送信ウィンドウサイズを調節する。ＲＬＣ送信ウィンドウが適切な大きさに合わせられると、輻輳に対する反応は、既存のＩｕｂフロー制御に比べて速く実行されうる。

一実施形態では、ＲＮＣは、Ｎｏｄｅ Ｂから許容データレート情報を、例えばＨＳ−ＤＳＣＨ容量割り当て（ＣＡ）制御フレームの形式で受信する。ＣＡフレームに含まれた情報に基づいて、許容データレートが計算され、ＲＬＣ送信ウィンドウサイズが決定され更新される。データレートは、ビットレートまたは他のタイプのレート測定尺度で表されてもよい。

好ましくは、ＲＬＣ送信ウインドウサイズは、フローのデータレートに基づいて、ＲＮＣとＮｏｄｅ Ｂとの間のＩｕｂ ＴＮの往復時間内に実質的に転送されうるデータ量を提供できるように設定される。往復時間は所定のＲＴＴ目標、所定の一方向目標遅延の２倍、実際のＲＴＴ、または実際の一方向遅延の２倍でもよい。

別の実施形態では、データレートに加えて、輻輳があるか否かなどの他の考慮すべき事項も、ＲＬＣ送信ウインドウサイズを決定するとき考慮されてもよい。輻輳状態が存在する場合、ＲＬＣ送信ウィンドウサイズはさらに減らされてもよい。「損失」タイプの輻輳に起因する減少量は、「遅延」タイプの輻輳による減少量より大きいことが好ましい。

また別の実施形態では、ＲＬＣ送信ウインドウサイズは、既存の３ＧＰＰ規格に準拠してＲＬＣ機能を実施するＲＬＣ部を変更することなしに、ＲＮＣで設定される。個別のエンティティが、指定の送信ウィンドウサイズをその中に有するＲＬＣ ＳＴＡＴＵＳ ＰＤＵをＲＬＣ部に送信しうる。個別のエンティティは、新しいＲＬＣ ＳＴＡＴＵＳ ＰＤＵを生成してもよいか、またはＲＬＣエンティティ宛ての到着ＲＬＣ ＳＴＡＴＵＳ ＰＤＵを直してもよい。

少なくとも以下を含む利点がある。提案の実施形態は、既存のＲＬＣプロトコルアーキテクチャで実施されうる。また、Ｎｏｄｅ ＢおよびＵＥなどの他のノードは、変更されないままでもよい。さらに、提案の実施形態は、ボトルネック状況が発生したとき、無線ネットワークシステムによる、より効率的かつよりロバストな反応を可能にする。

本発明の前述および他の目的、特徴および利点は、参照文字が種々の図面を通して同じ構成要素を指す添付の図面に示される好ましい実施形態についての、以下のより詳細な説明から明らかになるであろう。図面は、必ずしも一定の割合で縮小拡大されていないどころか、本発明の原理を明らかにするために強調が行われている。

一例の無線ネットワークシステムを示す図である。 ＨＳＤＰＡに係わるプロトコルレイヤおよびノードを示す図である。 送信ウィンドウサイズ設定可能なＲＬＣを具備するＲＮＣのアーキテクチャの一実施形態を示す図である。 ＲＬＣ送信ウィンドウサイズをデータフローに適応させるようにＲＮＣを動作させる方法の一例を示す図である。 Ｎｏｄｅ Ｂから受信した情報に基づいてデータレートを決定するプロセスの一例を示す図である。 ＲＮＣとＮｏｄｅ Ｂとの間で使用される同期手順を視覚化して示す図である。 ＲＬＣ送信ウィンドウサイズを更新するプロセスの別の例を示す図である。 ＲＬＣ送信ウィンドウサイズを更新するプロセスのまた別の例を示す図である。 ＲＬＣ送信ウィンドウサイズを更新するプロセスの一例を示す図である ＲＮＣ内のＲＬＣエンティティにＲＬＣ ＳＴＡＴＵＳ ＰＤＵを送信するプロセスの一例を示す図である。 ＲＮＣ内のＲＬＣエンティティにＲＬＣ ＳＴＡＴＵＳ ＰＤＵを送信するプロセスの別の一例を示す図である。 ＲＮＣの一実施形態を示す図である。

以下の記述では、本発明の完璧な理解を提供するために、限定のためでなく説明のために、特定のアーキテクチャ、インタフェース、技法等のような特定の詳細を記載する。しかし、本発明がこれらの特定の詳細から離れた他の実施形態で実践されてもよいことは、当業者には明白であろう。すなわち、本明細書には明示的に記述も図示もされていないが、本発明の原理を具体化し、かつ本発明の精神内および範囲内に含まれる種々のアレンジメントを、当業者は考案できるだろう。

場合によっては、周知のデバイス、回路および方法の詳細な記述は、不要な詳細で本発明の記述を不明瞭にしないように省略している。本発明の原理、態様および実施形態ならびにそれらの具体例を挙げる本明細書のすべての記載は、それらの構成上と機能上の両方の均等物を包含することを意図している。さらに、そのような均等物は、現在既知の均等物および将来開発される均等物を含む、すなわち構成にかかわらず同じ機能を実行するすべての開発要素を含むことを意図している。

従って、例えば本明細書のブロック図が、本技術の原理を具体化する例証となる回路の概念図を表してもよいことを、当業者は理解するであろう。同様に、フロー図、状態遷移図、疑似コードなどのどれもが種々のプロセスを表し、それらのプロセスはコンピュータで読み取り可能な記憶媒体に実質上表現されて、コンピュータまたはプロセッサが明示的に示されていようがいまいが、コンピュータまたはプロセッサによって実行されてもよいことも理解するであろう。

「プロセッサ」または「コントローラ」と名付けられているかまたは記述されている機能ブロックを含む種々の要素の機能は、専用ハードウェアおよび適切なソフトウェアと連携したソフトウェア実行可能ハードウェアの使用を通じて提供されてもよい。プロセッサによって提供されるとき、機能は、単一の専用プロセッサによって、単一の共用プロセッサによって、または一部が共用または分散されてもよい複数の個別のプロセッサによって提供されてもよい。さらに、「プロセッサ」または「コントローラ」という用語の明示的な使用は、ソフトウェア実行能力のあるハードウェアだけを指すと解釈されるべきでなく、デジタル信号プロセッサ（ＤＳＰ）ハードウェア、ソフトウェアを格納するリードオンリメモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）および不揮発性記憶装置を含んでもよいが、それらに限定されない。

図２に示されるＨＳＤＰＡアーキテクチャでは、ＲＮＣ内のＲＬＣレイヤが、ＵＥ内のピアのＲＬＣエンティティに送信するＲＬＣ ＰＤＵを生成する。ＲＬＣレイヤは、ＲＬＣ ＰＤＵをＭＡＣレイヤに提供する。ＭＡＣレイヤは、ＲＮＣとＮｏｄｅ Ｂとの間で分割されている。ＲＮＣによって生成された（ＲＬＣ ＰＤＵと関係がある）ＭＡＣ ＰＤＵは、ＭＡＣ−ｄ ＰＤＵと呼ばれ、ＨＳ−ＤＳＣＨデータフレームの中に集められ、Ｉｕｂインタフェースを通じてＮｏｄｅ Ｂに送信される。ＭＡＣ−ｄ ＰＤＵがスケジュールされ、Ｕｕインタフェースを通じてＵＥに首尾よく送信されるまで、Ｎｏｄｅ Ｂは、ＭＡＣ−ｄ ＰＤＵを関連したプライオリティキュー（ＰＱ）の中に、すなわちＭＡＣ−ｈｓバッファに保留する。Ｉｕｂを通じたＭＡＣ−ｄ ＰＤＵの送出はＩｕｂ ＦＣによって管理される。一態様では、データフロー（または単にフロー）は、ＲＮＣとＵＥとの間のＮｏｄｅ Ｂ経由の、ＲＬＣレイヤからのＭＡＣ−ｄ ＰＤＵと関係があるＲＬＣ ＰＤＵのフローと見なされてもよい。別の視点からは、フローは、ＲＬＣ ＰＤＵと関係があるＭＡＣ−ｄ ＰＤＵのフローと見なされてもよい。

Ｉｕｂ ＦＣ関連のデータフレームおよび制御フレームは、３ＧＰＰで標準化されている。ＨＳ−ＤＳＣＨ Ｉｕｂデータフレームは、ユーザデータを有して、ユーザバッファサイズ（ＵＢＳ）と呼ばれる、ＲＮＣが待つユーザデータの量についての情報を伝え、また輻輳検出、フレームシーケンス番号（ＦＳＮ）および遅延基準時間（ＤＲＴ）に関する情報を含む。

ＵＢＳ、Ｕｕ関連情報および輻輳検出情報に基づいて、Ｎｏｄｅ ＢのＩｕｂ ＦＣアルゴリズムは、所与のフローに関してＲＮＣからＭＡＣ−ｄ ＰＤＵをいくつ送信しうるかを決定する。Ｎｏｄｅ Ｂは、これをＨＳ−ＤＳＣＨ容量割り当て（ＣＡ）制御フレームを用いてＲＮＣに報告する。ＣＡメッセージには、以下のパラメータを含んでもよい。

・ＨＳ−ＤＳＣＨクレジット：割り当てられたＭＡＣ−ｄ ＰＤＵの数
・最大ＭＡＣ−ｄ ＰＤＵ長：各ＭＡＣ−ｄ ＰＤＵの最大サイズ
・ＨＳ−ＤＳＣＨ間隔：データが送信されてもよい時間間隔、および
・ＨＳ−ＤＳＣＨ反復期間：この割り当てがリフレッシュされ繰り返される期間
ＲＮＣにおけるＭＡＣ−ｄシェーピングは、所与のＨＳ−ＤＳＣＨ間隔内に多くてもＨＳ−ＤＳＣＨクレジットのＰＤＵまでしか送信されないことを確実にする。ＨＳ−ＤＳＣＨ反復期間は、ＨＳ−ＤＳＣＨ間隔およびＨＳ−ＤＳＣＨクレジットが何回繰り返されるかを規定する。新しく受信されたＣＡは、古いＣＡに優先する。

上記のように、既存のプロトコルアーキテクチャでは、ＨＳＤＰＡ ＦＣ機能がＨＳＤＰＡフローのビットレートを計算し、計算されたビットレートをＮｏｄｅ Ｂが標準ＣＡ制御フレームを用いてＲＮＣに送信する。ＲＮＣにおいて、このビットレートでＨＳＤＰＡがシェーピングされる。すなわち、Ｉｕｂ ＴＮまたはＵｕで輻輳が検出されると、ＨＳＤＰＡフローのビットレートが減らされ、既存のＨＳＤＰＡアーキテクチャ内の輻輳を解消する。

ＨＳＤＰＡのビットレートを制御する代わりに（またはそれに加えて）、本開示技術の一態様では、ＲＬＣレイヤの能力を用いてフローレートを制御することを提案している。一態様では、ＲＬＣは、Ｎｏｄｅ Ｂからフローに関するＣＡフレームを受信する。ＣＡフレーム内に含まれた情報に基づいて、ＲＮＣは、フローに合わせてＲＬＣ送信ウィンドウサイズを調節する。このようにして、確認応答されていないＲＬＣ ＰＤＵ数を制限してもよい。

既存のＨＳＤＰＡシステムでは、ＲＬＣ送信ウインドウサイズは実際のシステム状況にかかわらず最大値に設定され、サイズＲＬＣ送信ウインドウサイズは変化しない。Ｉｕｂ ＴＮが輻輳する場合、既存のＦＣアルゴリズムは反応するための時間を必要とする。この時間は３００ｍｓにもなることがあり、遅延目標の１００ｍｓより著しく長い。ビットレートは、フロー制御反応時間後にやっと減らされるであろう。

しかし、ＲＬＣ送信ウインドウサイズの調節により、はるかに反応の速い適応が可能になる。ＲＮＣにおいて、ＲＬＣ送信ウィンドウサイズは、一実施形態ではＮｏｄｅ Ｂから受信したフローに関するデータレートに基づいて、かつＩｕｂ ＴＮ遅延などの目標遅延に基づいて、制限されてもよい。現実のＩｕｂ ＴＮ遅延が目標遅延以下である場合、送信ウィンドウサイズの制限は伝送に影響を及ぼさない。しかし、遅延がそれより大きくなる場合、送信ウィンドウサイズの制限は、ＲＬＣ ＰＤＵの送信レートを自動的に減少する。好ましくは、ＲＬＣ送信ウィンドウサイズは、トランスポートネットワークにおけるラウンドトリップ時間（往復時間：ＲＴＴ）に実質的に等しく設定される。

ビットレートの制御に関してＲＬＣ送信ウインドウサイズを調節する１つの重要な利点は、反応時間がはるかに速いことである。実際には、以前送ったＲＬＣ ＰＤＵに対する確認応答がＵＥから（Ｎｏｄｅ Ｂを通じて）到着すると、ＲＮＣは、新しいＲＬＣ ＰＤＵを送信する。これは、Ｉｕｂ ＴＮの輻輳への対応をより効率的にする。

図３は、送信ウインドウサイズ設定可能なＲＬＣを具備するＲＮＣのアーキテクチャの一実施形態を示す。受信した各ＣＡメッセージに関して、ＲＮＣは以下を実行する。

・ＣＡからシェーピングレート（ＣＡデータレート）を取り出す。

・取り出したＣＡデータレートおよび場合によっては他の所定の内容に基づき、新しいＲＬＣ送信ウィンドウサイズを計算する。

・ＲＬＣ送信ウィンドウサイズを設定する。

・元のプロセスに従って受信ＣＡメッセージの処理を続ける。

ＲＬＣ送信ウインドウサイズを設定するために、一実施形態では、ＲＮＣ内のＲＬＣエンティティが、新しい機能で拡張される。この変更は、ＲＮＣ内だけの内的変更である。Ｎｏｄｅ ＢおよびＵＥなどの他のノードは影響を受けない。

あるいは、ＲＬＣ送信ウインドウサイズは、３ＧＰＰで標準化されたＲＮＣのＲＬＣ機能に少しの変更もなしに設定されてもよい。この代替形態では、ＲＬＣ送信ウィンドウサイズは、ＲＬＣ ＳＴＡＴＵＳ ＰＤＵを介して変更されてもよい。以下でさらに示すように、新しいＲＬＣ ＳＴＡＴＵＳ ＰＤＵが生成されてもよいし、また到着するＲＬＣ ＳＴＡＴＵＳ ＰＤＵの中のサイズが上書きされてもよい。ＲＬＣ ＳＴＡＴＵＳ ＰＤＵは、新しく生成されたにしろ上書きされたにしろ、既存の３ＧＰＰ規格に準拠して機能するＲＬＣエンティティに送信されてもよい。

図４は、ＲＬＣ送信ウインドウサイズをデータフローに適応させるようにＲＮＣを動作させる一例の方法Ｍ４００を示す。ここでＲＮＣは、Ｎｏｄｅ Ｂを介してＵＥとＲＬＣ ＰＤＵを交換していると想定されている。すなわち、ＲＮＣは、Ｎｏｄｅ Ｂ経由でＵＥと通信中である。本方法では、ステップＳ４１０の最初のフロー設定時に、ＲＬＣ送信ウィンドウサイズが最初に設定される。一実施形態では、ＲＬＣ機能を実施するように構成されたＲＬＣ部が最初の設定を実行して、最初のＲＬＣ送信ウィンドウサイズを決定してもよい。別の実施形態では、ＵＥとの無線リンクが最初に構成されるとき、最初のウィンドウサイズを決定するために、Ｎｏｄｅ Ｂ自体がＨＳ−ＤＳＣＨクレジットの最初の割り当てを行ってもよい。また別の実施形態では、スロースタートフェーズが使用されてもよい。例えば、あらゆる確認応答されたＲＬＣ ＰＤＵに関して、ＲＬＣ送信ウィンドウサイズは、１つのＲＬＣ ＰＤＵ分だけ増加されてもよい。

一例の方法Ｍ４００では、フローは、ＲＮＣとＵＥとの間のＲＬＣ ＰＤＵのフローと見なされてもよい。ＲＬＣ送信ウィンドウサイズは、ＵＥから確認応答（ＡＣＫ）が受信されるまでに、ＲＮＣからＵＥへ（Ｎｏｄｅ Ｂを介して）送信されてもよいデータフローの最大送信データ量を設定する。

ステップＳ４２０では、ＲＮＣは、Ｎｏｄｅ Ｂからフローに関するデータレート情報を受信する。一実施形態では、データレート情報は、ＨＳ−ＤＳＣＨ ＣＡフレームで提供される。図５は、ステップＳ４２０を実行するプロセスの一例を示す。ステップＳ５１０では、ＲＮＣは、Ｎｏｄｅ ＢからＣＡフレームを受信し、ステップＳ５２０で許容データレートを計算する。データレートは、ＣＡフレーム内の指定の最大ＭＡＣ−ｄ ＰＤＵ長、ＨＳ−ＤＳＣＨクレジット（証明書）、ＨＳ−ＤＳＣＨインターバル（間隔）、およびＨＳ−ＤＳＣＨ繰り返し周期の中の任意の１つ以上のパラメータに基づいて計算される。

図４の参照に戻って、ステップＳ４３０でＲＮＣは、受信データレートに基づいてＲＬＣ送信ウインドウサイズを更新する。一実施形態では、ＲＬＣ送信ウインドウサイズに対応するデータ量が、データレートに基づいてＲＮＣとＮｏｄｅ Ｂとの間のＩｕｂトランスポートネットワークＴＮの所定のターゲット（目標）往復時間内に転送されうるデータ量に実質的に等しくなるようにウインドウサイズが設定されるように、ＲＬＣ送信ウインドウサイズは設定される。

代数表現では、ＲＬＣ送信サイズは、以下の式に従って設定されてもよい。

上式で、ＷＳ（Ｔχ）はＲＬＣ送信ウィンドウサイズ、ＤＲはデータレート、ＲＴＴは所定の目標Ｉｕｂ ＴＮラウンドトリップ（往復）時間、Ｓ（ＲＰ）は１つのＲＬＣ ＰＤＵのサイズである。Ｓ（ＲＰ）のサイズは、バイト数またはオクテット数を含むいくつものやり方で表わされてもよい。

別の実施形態では、ターゲットＲＴＴは、Ｉｕｂ ＴＮの一方向遅延の２倍と単純に想定される。この事例では、ＲＬＣ送信サイズは、以下の式に従って設定されてもよい。

上式で、ＤＴは片道での所定のターゲットＩｕｂ ＴＮ遅延時間である。

また別の実施形態では、実際の遅延が目標遅延の代わりに使用されてもよい。図６は、非特許文献１に記載されているＲＮＣとＮｏｄｅ Ｂとの間で使用される同期プロシージャ（手順）を視覚化したものである。図示のように、ＲＮＣは、メッセージがいつ送信されたかを示す時刻Ｔ１を有するＤＬ ＮＯＤＥ ＳＹＮＣＨＲＯＮＩＺＡＴＩＯＮメッセージをＮｏｄｅ Ｂに送信する。ＲＮＣからのそのメッセージは、時刻Ｔ２にＮｏｄｅ Ｂに到着する。それに応えて、Ｎｏｄｅ Ｂは、メッセージがいつ送信されたかを示す時刻Ｔ３を有するＵＬ ＮＯＤＥ ＳＹＮＣＨＲＯＮＩＺＡＴＩＯＮメッセージをＲＮＣに送信する。このメッセージには、時刻Ｔ２も含む。Ｎｏｄｅ Ｂからのこのメッセージが時刻Ｔ４にＲＮＣに到着する。ＲＮＣは、実際のＲＴＴを（Ｔ２−Ｔ１）＋（Ｔ４−Ｔ３）と計算しうる。

図７Ａは、ステップＳ４３０を実行するプロセスの一例を示す。ステップＳ７１０で、ＲＮＣは実際の往復時間を決定する。一例として、上記で示す同期手順が、この目的に使用されてもよい。ステップＳ７２０で、ＲＬＣ送信ウィンドウサイズが、実際のＲＴＴおよびデータレートに基づいて更新される。代数表現では、以下の式が適用されてもよい。

上式で、ＲＴＴ（Ａ）は実際のＩｕｂ ＴＮ往復時間である。この実施形態では、ＲＬＣ送信ウィンドウサイズに対応するデータ量が、データレートに基づいてＩｕｂ ＴＮの実際の往復時間内に転送されうるデータ量に実質的に等しくなるように、ＲＬＣ送信ウィンドウサイズは設定される。

別の実施形態では、ステップＳ４３０を実行するプロセスの一例を示す図７Ｂに示されるように、（Ｔ２−Ｔ１）と（Ｔ４−Ｔ３）の時間の１つが使用されてもよい。ステップＳ７１５では、実際のダウンリンク（Ｔ２−Ｔ１）遅延時間およびアップリンク（Ｔ４−Ｔ３）遅延時間が決定される。ステップＳ７２５では、ＲＬＣ送信ウィンドウサイズが、実際のＤＬまたはＵＬの遅延時間とデータレートに基づき更新される。代数表現では、以下の式が適用されてもよい。

上式で、ＤＴ（Ａ）は、一方向Ｉｕｂ ＴＮ遅延時間の（Ｔ２−Ｔ１）と（Ｔ４−Ｔ３）のどちらかである。好ましくは、用心深くあるために、（Ｔ２−Ｔ１）と（Ｔ４−Ｔ３）の長い方の時間が使用される。この実施形態では、ＲＬＣ送信ウインドウサイズに対応するデータ量が、実際のアップリンクまたはダウンリンクのどちらか大きい方の遅延時間の２倍の時間内に転送されうるデータ量に実質的に等しくなるように、ＲＬＣ送信サイズは設定される。

図４の参照に戻って、ＲＬＣ送信ウインドウサイズを更新するとき、Ｉｕｂ ＴＮのデータレートおよび遅延以外の要因があってもよい。図８は、これらの他の要因を考慮してステップＳ４３０を実行するプロセスの一例を示す。ステップＳ８１０で、適切なＲＬＣ送信ウィンドウサイズがデータレートに基づいて決定される。式（１）、（２）、（３）、（４）の中の任意の１つ以上の式が、この目的のために使用されてもよいことに留意されたい。

ステップＳ８２０では、ＲＮＣが、Ｉｕｂ ＴＮに輻輳があるかどうかを判定する。一実施形態では、Ｎｏｄｅ Ｂから受信したＨＳ−ＤＳＣＨ ＣＡフレームがこの目的に使用される。ＣＡフレームは、既存の３ＧＰＰ規格に従って、フローの下り方向（ＲＮＣからＮｏｄｅ Ｂ）に輻輳状態が存在するか否かを示す２ビットの輻輳状態パラメータを含んでもよい。「損失」または「遅延」の２つのタイプがある。損失は実際のデータフレームが紛失していることを示し、再送信が必要である。遅延は、フローのＰＤＵパケットがＮｏｄｅ Ｂ内に所定の閾値を超えてたまっていることを示す。

輻輳が検出されると、ＲＬＣ送信ウインドウサイズをさらに減らすことが望ましいことがある。これはステップＳ８３０に反映されており、輻輳が検出されるとＲＬＣ送信ウィンドウサイズが減少される。減少量は輻輳のタイプに応じて変わってもよい。一例として、輻輳がフレームの損失があることを示す場合、減少量は、輻輳が遅延の存在を示す場合より大きいであろう。

上記の方法においては、ＲＬＣエンティティが、ＲＬＣ送信ウインドウサイズを更新してもよい。これは、既存の３ＧＰＰ規格からの逸脱と考えられてもよい。しかし、ＲＬＣ送信ウィンドウサイズの更新は、３ＧＰＰ規格から逸脱することなく達成されうる。この規格が示しているのは、ＲＬＣ ＰＤＵの受信機（ＵＥかまたはＲＮＣのどちらか）は、所望の送信ウィンドウサイズをＲＬＣ ＳＴＡＴＵＳ ＰＤＵの中に示すＲＬＣ ＳＴＡＴＵＳ ＰＤＵを受信機に送信することによって、送信機（ＲＮＣまたはＵＥ）のＲＬＣ送信ウィンドウサイズを設定しうる。送信機は、ＲＬＣ ＳＴＡＴＵＳ ＰＤＵの受信時、それに応じてウィンドウサイズを調節する。

このように一実施形態では、ＲＮＣ内のＲＬＣ部が規格に準拠してＲＬＣ機能を実行する。この実施形態では、ＲＬＣ部から分離した別のエンティティが使用される。「分離」は別の機能が提供されることだけを示すことに注目されたい。完全に別のハードウェアが設けられてもよいが、類似の結果はソフトウェアおよび／またはファームウェアによって達成されてもよい。

図８の参照に戻って、ＲＬＣ送信ウインドウサイズがステップＳ８１０またはステップ８３０で決定された後、決定されたウインドウサイズを有するＲＬＣ ＳＴＡＴＵＳ ＰＤＵメッセージが、ステップＳ８４０で標準ＲＬＣ機能を実施するＲＬＣ部に送信される。一実施形態では、ＲＬＣ ＳＴＡＴＵＳ ＰＤＵは、それがＲＬＣ ＰＤＵのフローの受信機すなわち対応するＵＥからであるかのように見えるようにされる。ステップＳ８４０のボックスは、これが代替手段であることを示すために破線になっている。この実施形態では、（好ましくはＲＮＣ内の）別のエンティティがＲＬＣ部にＲＬＣ ＳＴＡＴＵＳ ＰＤＵを送信する。

図９Ａは、ステップＳ８４０を実施するプロセスの一例を示す。この事例では、ＲＬＣ送信ウィンドウサイズを有する全く新しいＲＬＣ ＳＴＡＴＵＳ ＰＤＵがステップＳ９１０で生成され、生成されたＲＬＣ ＳＴＡＴＵＳ ＰＤＵはステップＳ９２０でＲＬＣ部に送信される。

しかし、ＲＬＣ ＰＤＵの実際の受信機すなわちＵＥがＲＮＣ宛てのＲＬＣ ＳＴＡＴＵＳ ＰＤＵを送信する事例があってもよい。図９Ｂは、そのような状況でステップＳ８４０を実施するプロセスの一例を示す。ステップＳ９１５において、到着するＲＬＣ ＳＴＡＴＵＳ ＰＤＵが途中でインターセプト（捕捉）され、ステップＳ９２５で、フローに対するＲＬＣ送信ウィンドウサイズが指定されているか否かが判定される。ウィンドウサイズが指定されていない場合、ステップＳ９３５で、ウィンドウサイズ指定がＲＬＣ ＳＴＡＴＵＳ ＰＤＵに付加されてもよい。ウィンドウサイズがＵＥからのＲＬＣ ＳＴＡＴＵＳ ＰＤＵの中に指定されている場合、ウィンドウサイズ指定は、ステップＳ８１０またはＳ８３０で決定されたＲＬＣ送信ウィンドウサイズで上書きされてもよい。一実施形態では、ＲＬＣ送信ウィンドウサイズは、決定されたサイズがＲＬＣ ＳＴＡＴＵＳ ＰＤＵの中で既に指定されたサイズより小さい場合だけ上書きされる。次いでステップＳ７５５で、ＲＬＣ ＳＴＡＴＵＳ ＰＤＵはＲＬＣ部に転送される。

図１０は、上記の方法を実施するように構成されたＲＮＣの実施形態の一例を示す。ＲＮＣは、処理部１０１０、監視部１０２０、記憶部１０３０、通信部１０４０およびＲＬＣ部１０５０を有する。処理部１０１０は、本方法を実行するために、他のユニット１０２０〜１０５０の調整制御を含むＲＮＣの動作全体を制御するように構成されている。

監視部１０２０は、Ｉｕｂ ＴＮなどのＲＮＣとＮｏｄｅ Ｂとの間の通信リンクのデータトラヒック状態の監視を含むＲＮＣの状態を監視するように構成されている。記憶部１０３０は、ＲＮＣとＵＥとの間のデータフローに関するデータおよび制御情報の格納を含む、ＲＮＣ１１０が適切に働くために必要な情報を格納するように構成されている。記憶部１０３０は、プロトコルアーキテクチャを実施するために、ＲＬＣ ＰＤＵ、ＭＡＣ ＰＤＵ等をバッファに保留するために使用されてもよい。通信部１０４０は、Ｎｏｄｅ Ｂ経由でＵＥと、対応するＭＡＣ−ｄ ＰＤＵに詰められたＲＬＣ ＰＤＵの交換を含む通信を行うように構成されている。Ｎｏｄｅ Ｂとの通信は、Ｉｕｂ ＴＮを通じて行われてもよい。

ＲＮＣは、３ＧＰＰ規格に準拠してＲＬＣ手順を実行するように構成されたＲＬＣ部１０５０も有してもよい。この事例では、処理部１０１０が、上記のように、ＲＬＣ送信ウィンドウサイズを決定し、送信サイズをその中で指定しているＲＬＣ ＳＴＡＴＵＳ ＰＤＵをＲＬＣ部１０５０に送信してもよい。

１０１０〜１０５０の諸部は、図１０に個別の構成単位として示されている。しかし、これは単に機能が別々であることを示すに過ぎない。諸部は、個別のハードウェアデバイスとして提供されてもよい。しかし、他の構成も可能である。諸部の任意の組み合わせが、ソフトウェア、ハードウェアおよび／またはファームウェアの任意の組み合わせで実装されてもよい。

これまでの説明は多くの特定の事項を含むが、これらの事項は、本発明の範囲を限定すると解釈されるべきでなく、本発明の現在好ましい実施形態のいくつかの例証を提供するに過ぎないと解釈されるべきである。それ故、本発明の範囲は当業者には明白になるかもしれない他の実施形態も完全に包含し、それに応じて本発明の範囲が限定されないものであることは、理解されるであろう。当業者に公知の、上記の好ましい実施形態の要素の機能上の均等物は、参照によって明示的にここに援用し、本明細書に包含することを意図している。さらに、１つのデバイスまたは方法が、本明細書に記載のまたは本明細書に包含している本技術が解決を目指す、ありとあらゆる問題に取り組む必要はない。さらに、本開示の要素、コンポーネントまたは方法動作のどれも、大衆に捧げる意図はない。

Claims (16)

1. 無線ネットワーク（１００）における無線ネットワーク制御装置（ＲＮＣ）（１１０）において実行される方法であって、前記無線ネットワーク制御装置（１１０）は、Ｎｏｄｅ Ｂ（１２０）を介してユーザ装置（ＵＥ）（１３０）と通信を実行する装置であり、
   前記方法は、
   初期フロー設定において、前記ユーザ装置（１３０）と関連付けられたデータフローについての無線リンク制御（ＲＬＣ）の送信ウインドウサイズを設定するステップ（Ｓ４１０）と、
   前記データフローについてのデータレートを示す情報を前記Ｎｏｄｅ Ｂ（１２０）から受信するステップ（Ｓ４２０）と、
   前記無線リンク制御（ＲＬＣ）の送信ウインドウサイズに対応したデータ量が前記無線ネットワーク制御装置（１１０）と前記Ｎｏｄｅ Ｂ（１２０）との間におけるＩｕｂトランスポートネットワーク（ＴＮ）の所定のターゲットラウンドトリップ時間内に伝送可能なデータ量と実質的に等しくなるように、前記受信したデータレートを示す情報に基づいて前記無線リンク制御（ＲＬＣ）の送信ウインドウサイズを更新するステップ（Ｓ４３０）と
   を有し、
   前記データフローは、前記無線ネットワーク制御装置（１１０）と前記ユーザ装置（１３０）との間で伝送される無線リンク制御（ＲＬＣ）のプロトコルデータユニット（ＰＤＵ）であり、
   前記無線リンク制御（ＲＬＣ）の送信ウインドウサイズは、前記ユーザ装置（１３０）から確認応答（ＡＣＫ）を受信するまで、前記無線ネットワーク制御装置（１１０）から前記ユーザ装置（１３０）へ送信することができる前記データフローの注目データのデータ量のうち最大量を規定するサイズであることを特徴とする方法。
2. 前記データフローについてのデータレートを示す情報を前記Ｎｏｄｅ Ｂ（１２０）から受信する前記ステップ（Ｓ４２０）は、
   Ｉｕｂトランスポートネットワーク（ＴＮ）を介して前記Ｎｏｄｅ Ｂから前記データフローについてＨＳ−ＤＳＣＨ ＣＡＰＡＣＩＴＹ ＡＬＬＯＣＡＴＩＯＮ制御フレームを受信するステップ（Ｓ５１０）と、
   前記受信したＨＳ−ＤＳＣＨ ＣＡＰＡＣＩＴＹ ＡＬＬＯＣＡＴＩＯＮ制御フレームから特定されるパラメータのうち、最大ＭＡＣ−ｄ ＰＤＵ 長、ＨＳ−ＤＳＣＨ証明書、ＨＳ−ＤＳＣＨインターバル、ＨＳ−ＤＳＣＨ繰返し周期のいずれか１つ以上に基づいて前記データレートを算出する算出ステップ（Ｓ５２０）と
   をさらに有することを特徴とする請求項１に記載の方法。
3. 前記無線リンク制御（ＲＬＣ）の送信ウインドウサイズを更新する前記ステップ（Ｓ４３０）において、前記無線リンク制御（ＲＬＣ）の送信ウインドウサイズが、次式に基づいて設定され、
   ＷＳ（Ｔｘ）≒ＤＲ＊ＲＴＴ／Ｓ（ＲＰ）
   ＷＳ（Ｔｘ）は前記無線リンク制御（ＲＬＣ）の送信ウインドウサイズであり、
   ＤＲは前記データレートであり、
   ＲＴＴは前記Ｉｕｂトランスポートネットワーク（ＴＮ）の所定のターゲットラウンドトリップ時間であり、
   Ｓ（ＲＰ）は前記無線リンク制御（ＲＬＣ）のプロトコルデータユニット（ＰＤＵ）の１つあたりのサイズであることを特徴とする請求項１に記載の方法。
4. 前記無線リンク制御（ＲＬＣ）の送信ウインドウサイズを更新する前記ステップ（Ｓ４３０）において、前記無線リンク制御（ＲＬＣ）の送信ウインドウサイズが、次式に基づいて設定され、
   ＷＳ（Ｔｘ）≒２＊ＤＲ＊ＤＴ／Ｓ（ＲＰ）
   ＷＳ（Ｔｘ）は前記無線リンク制御（ＲＬＣ）の送信ウインドウサイズであり、
   ＤＲは前記データレートであり、
   ＤＴは前記Ｉｕｂトランスポートネットワーク（ＴＮ）における片道での所定のターゲット遅延時間であり、
   Ｓ（ＲＰ）は前記無線リンク制御（ＲＬＣ）のプロトコルデータユニット（ＰＤＵ）の１つあたりのサイズであることを特徴とする請求項１に記載の方法。
5. 前記無線リンク制御（ＲＬＣ）の送信ウインドウサイズを更新する前記ステップ（Ｓ４３０）は、
   前記無線ネットワーク制御装置（１１０）と前記Ｎｏｄｅ Ｂ（１２０）との間における前記Ｉｕｂトランスポートネットワーク（ＴＮ）における実際のラウンドトリップ時間を決定するステップ（Ｓ７１０）と、
   前記決定した実際のラウンドトリップ時間に基づいて前記無線リンク制御（ＲＬＣ）の送信ウインドウサイズを更新するステップ（Ｓ７２０）とを有し、
   前記無線リンク制御（ＲＬＣ）の送信ウインドウサイズに対応したデータ量が、前記データレートに基づいて前記Ｉｕｂトランスポートネットワーク（ＴＮ）における前記実際のラウンドトリップ時間内に伝送可能なデータ量と実質的に等しくなるように、前記無線リンク制御（ＲＬＣ）の送信ウインドウサイズが設定されることを特徴とする請求項１に記載の方法。
6. 前記無線リンク制御（ＲＬＣ）の送信ウインドウサイズを更新する前記ステップ（Ｓ４３０）は、
   前記無線ネットワーク制御装置（１１０）と前記Ｎｏｄｅ Ｂ（１２０）との間における前記Ｉｕｂトランスポートネットワーク（ＴＮ）における実際のアップリンクの遅延時間とダウンリンクの遅延時間とを決定するステップ（Ｓ７１５）と、
   前記決定した実際のアップリンクの遅延時間とダウンリンクの遅延時間とに基づいて前記無線リンク制御（ＲＬＣ）の送信ウインドウサイズを更新するステップ（Ｓ７２５）とを有し、
   前記無線リンク制御（ＲＬＣ）の送信ウインドウサイズに対応したデータ量が、前記実際のアップリンクの遅延時間とダウンリンクの遅延時間とのうちいずれか大きい遅延時間の２倍となる時間内に伝送可能なデータ量と実質的に等しくなるように、前記無線リンク制御（ＲＬＣ）の送信ウインドウサイズが設定されることを特徴とする請求項１に記載の方法。
7. 前記無線リンク制御（ＲＬＣ）の送信ウインドウサイズを更新する前記ステップ（Ｓ４３０）は、
   前記算出したデータレートに基づいて前記無線リンク制御（ＲＬＣ）の送信ウインドウサイズを決定するステップ（Ｓ８１０）と、
   前記無線ネットワーク制御装置（１１０）から前記Ｎｏｄｅ Ｂ（１２０）へのダウンリンク方向において前記Ｉｕｂトランスポートネットワーク（ＴＮ）に輻輳が発生していることを前記受信したＨＳ−ＤＳＣＨ ＣＡＰＡＣＩＴＹ ＡＬＬＯＣＡＴＩＯＮ制御フレームに含まれている輻輳ステータスパラメータが示しているときは、前記無線リンク制御（ＲＬＣ）の送信ウインドウサイズをさらに所定量だけ削減するステップ（Ｓ８３０）と
   を有することを特徴とする請求項２に記載の方法。
8. 前記無線リンク制御（ＲＬＣ）の送信ウインドウサイズを更新する前記ステップ（Ｓ４３０）は、
   前記算出したデータレートに基づいて前記無線リンク制御（ＲＬＣ）の送信ウインドウサイズを決定するステップ（Ｓ８１０）と、
   前記無線リンク制御（ＲＬＣ）の送信ウインドウサイズを指定するためのＲＬＣ ＳＴＡＴＵＳ ＰＤＵを前記無線ネットワーク制御装置（ＲＮＣ）が備える無線リンク制御（ＲＬＣ）エンティティへ送信するステップ（Ｓ８４０）と
   を有し、
   前記無線リンク制御（ＲＬＣ）エンティティは、３ＧＰＰ規格に準拠したＲＬＣプロシージャを実行するように構成されたエンティティである
   ことを特徴とする請求項２に記載の方法。
9. 前記ＲＬＣ ＳＴＡＴＵＳ ＰＤＵを前記無線ネットワーク制御装置（ＲＮＣ）が備える無線リンク制御（ＲＬＣ）エンティティへ送信する前記ステップ（Ｓ８４０）は、
   前記データフローについて到来してきた前記ＲＬＣ ＳＴＡＴＵＳ ＰＤＵをインターセプトするステップ（Ｓ９１５）と、
   前記到来してきた前記ＲＬＣ ＳＴＡＴＵＳ ＰＤＵが前記無線リンク制御（ＲＬＣ）の送信ウインドウサイズを示す規格情報を含んでいないときに、前記無線リンク制御（ＲＬＣ）の送信ウインドウサイズを示す規格情報を前記到来してきた前記ＲＬＣ ＳＴＡＴＵＳ ＰＤＵに追加するステップ（Ｓ９３５）と、
   前記到来してきた前記ＲＬＣ ＳＴＡＴＵＳ ＰＤＵが前記無線リンク制御（ＲＬＣ）の送信ウインドウサイズを示し規格情報を含んでいたときに、前記無線リンク制御（ＲＬＣ）の送信ウインドウサイズを示す規格情報を上書きするステップ（Ｓ９４５）と、
   修正された前記ＲＬＣ ＳＴＡＴＵＳ ＰＤＵを前記無線リンク制御（ＲＬＣ）エンティティへ転送するステップ（Ｓ９５５）と
   を有することを特徴とする請求項８に記載の方法。
10. 無線ネットワーク（１００）における無線ネットワーク制御装置（ＲＮＣ）（１１０）であって、
    Ｉｕｂトランスポートネットワーク（ＴＮ）でＮｏｄｅ Ｂ（１２０）を介してユーザ装置（１３０）と無線リンク制御（ＲＬＣ）のプロトコルデータユニット（ＰＤＵ）を送受信する通信ユニット（１０４０）と、
    前記無線ネットワーク制御装置（１１０）とユーザ装置（１３０）との間にある通信リンクと前記無線ネットワーク制御装置（１１０）と前記Ｎｏｄｅ Ｂ（１２０）との間にある通信リンクとにおけるデータトラフィックの状況を監視する監視ユニット（１０２０）と、
    前記無線ネットワーク制御装置（１１０）と前記ユーザ装置（１３０）との間で送受信されるデータについての制御情報と当該データとを記憶する記憶ユニット（１０３０）と、
    前記無線ネットワーク制御装置（１１０）についての通信処理を実行するために、前記通信ユニット（１０４０）、前記監視ユニット（１０２０）および前記記憶ユニット（１０３０）を制御する処理ユニット（１０１０）と
    を備え、
    前記処理ユニット（１０１０）は、
    初期フロー設定において、前記ユーザ装置（１３０）と関連付けられたデータフローについての無線リンク制御（ＲＬＣ）の送信ウインドウサイズを設定し、
    前記通信ユニット（１０４０）を通じて前記データフローについてのデータレートを示す情報を前記Ｎｏｄｅ Ｂ（１２０）から受信し、
    前記無線リンク制御（ＲＬＣ）の送信ウインドウサイズに対応したデータ量が前記無線ネットワーク制御装置（１１０）と前記Ｎｏｄｅ Ｂ（１２０）との間におけるＩｕｂトランスポートネットワーク（ＴＮ）の所定のターゲットラウンドトリップ時間内に伝送可能なデータ量と実質的に等しくなるように、前記受信したデータレートを示す情報に基づいて前記無線リンク制御（ＲＬＣ）の送信ウインドウサイズを更新し、
    前記データフローは、前記無線ネットワーク制御装置（１１０）と前記ユーザ装置（１３０）との間で伝送される無線リンク制御（ＲＬＣ）のプロトコルデータユニット（ＰＤＵ）であり、
    前記無線リンク制御（ＲＬＣ）の送信ウインドウサイズは、前記ユーザ装置（１３０）から確認応答（ＡＣＫ）を受信するまで、前記無線ネットワーク制御装置（１１０）から前記ユーザ装置（１３０）へ送信することができる前記データフローの注目データのデータ量のうち最大量を規定するサイズであることを特徴とする無線ネットワーク制御装置。
11. 前記処理ユニット（１０１０）は、
    Ｉｕｂトランスポートネットワーク（ＴＮ）を介して前記Ｎｏｄｅ Ｂから前記データフローについてＨＳ−ＤＳＣＨ ＣＡＰＡＣＩＴＹ ＡＬＬＯＣＡＴＩＯＮ制御フレームを受信し、
    前記受信したＨＳ−ＤＳＣＨ ＣＡＰＡＣＩＴＹ ＡＬＬＯＣＡＴＩＯＮ制御フレームから特定されるパラメータのうち、最大ＭＡＣ−ｄ ＰＤＵ 長、ＨＳ−ＤＳＣＨ証明書、ＨＳ−ＤＳＣＨインターバル、ＨＳ−ＤＳＣＨ繰返し周期のいずれか１つ以上に基づいて前記データレートを算出する
    ことを特徴とする請求項１０に記載の無線ネットワーク制御装置。
12. 前記処理ユニット（１０１０）は、
    ＲＮＣとＮｏｄｅ Ｂとの間の同期手順を使用して前記無線ネットワーク制御装置（１１０）と前記Ｎｏｄｅ Ｂ（１２０）との間における前記Ｉｕｂトランスポートネットワーク（ＴＮ）における実際のラウンドトリップ時間を決定し、
    前記決定した実際のラウンドトリップ時間に基づいて前記無線リンク制御（ＲＬＣ）の送信ウインドウサイズを更新し、
    前記無線リンク制御（ＲＬＣ）の送信ウインドウサイズに対応したデータ量が、前記データレートに基づいて前記Ｉｕｂトランスポートネットワーク（ＴＮ）における前記実際のラウンドトリップ時間内に伝送可能なデータ量と実質的に等しくなるように、前記無線リンク制御（ＲＬＣ）の送信ウインドウサイズが設定される
    ことを特徴とする請求項１０に記載の無線ネットワーク制御装置。
13. 前記処理ユニット（１０１０）は、
    ＲＮＣとＮｏｄｅ Ｂとの間の同期手順を使用して前記無線ネットワーク制御装置（１１０）と前記Ｎｏｄｅ Ｂ（１２０）との間における前記Ｉｕｂトランスポートネットワーク（ＴＮ）における実際のアップリンクの遅延時間とダウンリンクの遅延時間とを決定し、
    前記決定した実際のアップリンクの遅延時間とダウンリンクの遅延時間とに基づいて前記無線リンク制御（ＲＬＣ）の送信ウインドウサイズを更新し、
    前記無線リンク制御（ＲＬＣ）の送信ウインドウサイズに対応したデータ量が、前記実際のアップリンクの遅延時間とダウンリンクの遅延時間とのうちいずれか大きい遅延時間の２倍となる時間内に伝送可能なデータ量と実質的に等しくなるように、前記無線リンク制御（ＲＬＣ）の送信ウインドウサイズが設定される
    ことを特徴とする請求項１０に記載の無線ネットワーク制御装置。
14. 前記処理ユニット（１０１０）は、
    前記算出したデータレートに基づいて前記無線リンク制御（ＲＬＣ）の送信ウインドウサイズを決定し、
    前記無線ネットワーク制御装置（１１０）から前記Ｎｏｄｅ Ｂ（１２０）へのダウンリンク方向において前記Ｉｕｂトランスポートネットワーク（ＴＮ）に輻輳が発生していることを前記受信したＨＳ−ＤＳＣＨ ＣＡＰＡＣＩＴＹ ＡＬＬＯＣＡＴＩＯＮ制御フレームに含まれている輻輳ステータスパラメータが示しているときは、前記無線リンク制御（ＲＬＣ）の送信ウインドウサイズをさらに所定量だけ削減し、
    前記所定量は、前記輻輳ステータスパラメータが遅延の増加を示しているときには第１の量であり、前記輻輳ステータスパラメータがフレームの損失を示しているときには第２の量であることを特徴とする請求項１１に記載の無線ネットワーク制御装置。
15. ３ＧＰＰ規格に準拠したＲＬＣプロシージャを実行する無線リンク制御（ＲＬＣ）ユニット（１０５０）をさらに備え、
    前記処理ユニット（１０１０）は、
    前記算出したデータレートに基づいて前記無線リンク制御（ＲＬＣ）の送信ウインドウサイズを決定し、
    前記データフローについて指定された前記無線リンク制御（ＲＬＣ）の送信ウインドウサイズを示す情報を含むＲＬＣ ＳＴＡＴＵＳ ＰＤＵを生成し、
    前記生成したＲＬＣ ＳＴＡＴＵＳ ＰＤＵを前記無線リンク制御（ＲＬＣ）ユニット（１０５０）へ転送する
    ことで前記無線リンク制御（ＲＬＣ）の送信ウインドウサイズを更新することを特徴とする請求項１１に記載の無線ネットワーク制御装置。
16. ３ＧＰＰ規格に準拠したＲＬＣプロシージャを実行する無線リンク制御（ＲＬＣ）ユニット（１０５０）をさらに備え、
    前記処理ユニット（１０１０）は、
    前記データフローについて到来してきたＲＬＣ ＳＴＡＴＵＳ ＰＤＵをインターセプトし、
    前記到来してきた前記ＲＬＣ ＳＴＡＴＵＳ ＰＤＵが前記無線リンク制御（ＲＬＣ）の送信ウインドウサイズを示す情報を含んでいないときに、前記無線リンク制御（ＲＬＣ）の送信ウインドウサイズを示す規格情報を前記到来してきた前記ＲＬＣ ＳＴＡＴＵＳ ＰＤＵに追加し、
    前記到来してきた前記ＲＬＣ ＳＴＡＴＵＳ ＰＤＵが前記無線リンク制御（ＲＬＣ）の送信ウインドウサイズを示し規格情報を含んでいたときに、前記無線リンク制御（ＲＬＣ）の送信ウインドウサイズを示す規格情報を上書きし、
    修正された前記ＲＬＣ ＳＴＡＴＵＳ ＰＤＵを前記無線リンク制御（ＲＬＣ）ユニット（１０５０）へ転送する
    ことで前記無線リンク制御（ＲＬＣ）の送信ウインドウサイズを更新することを特徴とする請求項１１に記載の無線ネットワーク制御装置。

Images