JP2011503964A

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

Info

Publication number: JP2011503964A
Application number: JP2010531993A
Authority: JP
Inventors: サンドルラツァ，; ペテルルンド，; ジルヴェスツァーナダス，; シー，ゾルタンナギー
Original assignee: テレフオンアクチーボラゲットエルエムエリクソン（パブル）
Priority date: 2007-11-01
Filing date: 2008-10-29
Publication date: 2011-01-27
Anticipated expiration: 2028-10-29
Also published as: US8339962B2; US20100260049A1; JP5238036B2; EP2204018B1; ATE505883T1; WO2009058078A1; DE602008006242D1; EP2204018A1

Abstract

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

Description

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Claims

無線ネットワーク（１００）における無線ネットワーク制御装置（ＲＮＣ）（１１０）において実行される方法であって、前記無線ネットワーク制御装置（１１０）は、ＮｏｄｅＢ（１２０）を介してユーザ装置（ＵＥ）（１３０）と通信を実行する装置であり、
前記方法は、
初期フロー設定において、前記ユーザ装置（１３０）と関連付けられたデータフローについての無線リンク制御（ＲＬＣ）の送信ウインドウサイズを設定するステップ（Ｓ４１０）と、
前記データフローについてのデータレートを示す情報を前記ＮｏｄｅＢ（１２０）から受信するステップ（Ｓ４２０）と、
前記受信したデータレートを示す情報に基づいて前記無線リンク制御（ＲＬＣ）の送信ウインドウサイズを更新するステップ（Ｓ４３０）と
を有し、
前記データフローは、前記無線ネットワーク制御装置（１１０）と前記ユーザ装置（１３０）との間で伝送される無線リンク制御（ＲＬＣ）のプロトコルデータユニット（ＰＤＵ）であり、
前記無線リンク制御（ＲＬＣ）の送信ウインドウサイズは、前記ユーザ装置（１３０）から確認応答（ＡＣＫ）を受信するまで、前記無線ネットワーク制御装置（１１０）から前記ユーザ装置（１３０）へ送信することができる前記データフローの注目データのデータ量のうち最大量を規定するサイズであることを特徴とする方法。
前記データフローについてのデータレートを示す情報を前記ＮｏｄｅＢ（１２０）から受信する前記ステップ（Ｓ４２０）は、
Ｉｕｂトランスポートネットワーク（ＴＮ）を介して前記ＮｏｄｅＢから前記データフローについてＨＳ−ＤＳＣＨＣＡＰＡＣＩＴＹＡＬＬＯＣＡＴＩＯＮ制御フレームを受信するステップ（Ｓ５１０）と、
前記受信したＳ−ＤＳＣＨＣＡＰＡＣＩＴＹＡＬＬＯＣＡＴＩＯＮ制御フレームから特定されるパラメータのうち、最大ＭＡＣ−ｄＰＤＵ長、ＨＳ−ＤＳＣＨ証明書、ＨＳ−ＤＳＣＨインターバル、ＨＳ−ＤＳＣＨ繰返し周期のいずれか１つ以上に基づいて前記データレートを算出する算出ステップ（Ｓ５２０）と
をさらに有することを特徴とする請求項１に記載の方法。
前記無線リンク制御（ＲＬＣ）の送信ウインドウサイズを更新する前記ステップ（Ｓ４３０）において、前記無線リンク制御（ＲＬＣ）の送信ウインドウサイズに対応したデータ量が、前記データレートに基づいて前記無線ネットワーク制御装置（１１０）と前記ユーザ装置（１３０）との間におけるＩｕｂトランスポートネットワーク（ＴＮ）の所定のターゲットラウンドトリップ時間内に伝送可能なデータ量と実質的に等しくなるように、前記無線リンク制御（ＲＬＣ）の送信ウインドウサイズが設定されることを特徴とする請求項１に記載の方法。
前記無線リンク制御（ＲＬＣ）の送信ウインドウサイズを更新する前記ステップ（Ｓ４３０）において、前記無線リンク制御（ＲＬＣ）の送信ウインドウサイズが、次式に基づいて設定され、

ＷＳ（Ｔｘ）は前記無線リンク制御（ＲＬＣ）の送信ウインドウサイズであり、
ＤＲは前記データレートであり、
ＲＴＴは前記Ｉｕｂトランスポートネットワーク（ＴＮ）の所定のターゲットラウンドトリップ時間であり、
Ｓ（ＲＰ）は前記無線リンク制御（ＲＬＣ）のプロトコルデータユニット（ＰＤＵ）の１つあたりのサイズであることを特徴とする請求項３に記載の方法。
前記無線リンク制御（ＲＬＣ）の送信ウインドウサイズを更新する前記ステップ（Ｓ４３０）において、前記無線リンク制御（ＲＬＣ）の送信ウインドウサイズが、次式に基づいて設定され、

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