(57)【要約】ある実施形態において、ＲＬＣの送信ウィンドウを使用してフローの転送レートを制御することにより、アップリンク方向のＩｕｂトランスポートネットワーク輻輳を解消する機構が提供される。ＲＮＣ（１１０）は、アップリンクにおけるフローに対するＩｕｂ  ＴＮ輻輳を検出する。ＲＮＣ（１１０）で実行されるＥＵＬフロー制御は、フローに対するＵＥのＲＬＣ送信ウィンドウサイズを計算し、計算したＲＬＣ送信ウィンドウサイズは、ＲＬＣ  ＳＴＡＴＵＳ  ＰＤＵを通してＵＥ（１３０）におけるピアＲＬＣ実体へ信号送信される。【選択図】図３Ａ
2011504002.tif 000002
【特許請求の範囲】
【請求項１】
無線ネットワーク（１００）における無線ネットワーク制御装置（ＲＮＣ）（１１０）のオペレーションを行う方法であって、前記ＲＮＣ（１１０）はユーザ装置（ＵＥ）（１３０）と通信しており、
初期データフローセットアップにおいてフローに対する前記ＵＥ（１３０）の無線リンク制御（ＲＬＣ）送信ウィンドウサイズを設定するステップ（Ｓ４１０）と、
アップリンク方向における前記フローに対する前記ＲＮＣ（１１０）とＮｏｄｅ−Ｂ（１２０）との間のＩｕｂトランスポートネットワーク（ＴＮ）接続に輻輳が存在するかどうか判定するステップ（Ｓ４２０）と、
前記輻輳が存在すると判定された場合、前記ＲＬＣ送信ウィンドウサイズを縮小するステップ（Ｓ４５０）と、
縮小した前記ＲＬＣ送信ウィンドウサイズに関して前記ＵＥ（１３０）に通知するステップ（Ｓ４６５）と
を含み、
前記フローは、前記ＲＮＣ（１１０）と前記ＵＥ（１３０）との間で交換されるＲＬＣ  ＰＤＵから形成された媒体アクセス制御−ｄプロトコルデータユニット（ＭＡＣ−ｄ  ＰＤＵ）のフローであり、
前記ＲＬＣ送信ウィンドウサイズは、前記フローに対して、確認応答（ＡＣＫ）が前記ＲＮＣ（１１０）から送信されるまでに１または２以上のＲＬＣ  ＰＤＵで前記ＵＥ（１３０）から前記ＲＮＣ（１１０）へ送信可能な未処理データの最大量を設定する、方法。
【請求項２】
前記ＵＥ（１３０）に通知するステップ（Ｓ４６５）は、縮小した前記ＲＬＣ送信ウィンドウサイズを特定したＲＬＣ  ＳＴＡＴＵＳ  ＰＤＵを形成して、前記ＵＥ（１３０）へ送信するステップを含む、請求項１に記載の方法。
【請求項３】
前記ＲＬＣ送信ウィンドウサイズを縮小するステップ（Ｓ４５０）は、
前記輻輳が所定の時間内で最初の輻輳であるかどうか判定するステップ（Ｓ５１０）と、
前記輻輳が最初の輻輳であると判定される場合、前記ＲＬＣ送信ウィンドウサイズを縮小するステップ（Ｓ５２０、Ｓ５４０、Ｓ５５０）と
を含み、
前記所定の時間は、前記ＵＥ（１３０）の前記初期データフローセットアップまたは以前の測定時間の満了のいずれか後に発生した方から経過した時間である、請求項１に記載の方法。
【請求項４】
前記輻輳が最初の輻輳であると判定される場合に前記ＲＬＣ送信ウィンドウサイズを縮小するステップ（Ｓ５２０、Ｓ５４０、Ｓ５５０）では、前記ＲＬＣ送信ウィンドウサイズの縮小量が前記輻輳のタイプに基づく、請求項３に記載の方法。
【請求項５】
前記輻輳が最初の輻輳であると判定される場合に前記ＲＬＣ送信ウィンドウサイズを縮小するステップ（Ｓ５２０、Ｓ５４０、Ｓ５５０）は、
前記輻輳は前記Ｎｏｄｅ−Ｂ（１２０）から前記ＲＮＣ（１１０）への前記フローの転送の遅延を示す遅延形成輻輳であるか、または前記転送におけるデータの損失を示すトランスポートネットワーク（ＴＮ）損失輻輳であるかを判定するステップ（Ｓ５２０）と、
前記輻輳が前記遅延形成輻輳であると判定される場合、第１縮小量だけ前記ＲＬＣ送信ウィンドウサイズを縮小するステップ（Ｓ５４０）と、
前記輻輳が前記ＴＮ損失輻輳であると判定される場合、第２縮小量だけ前記ＲＬＣ送信ウィンドウサイズを縮小するステップ（Ｓ５５０）と、
を含み、
前記第１縮小量は前記第２縮小量よりも小さい、請求項３に記載の方法。
【請求項６】
前記遅延形成輻輳は、前記Ｎｏｄｅ−Ｂ（１２０）から前記ＲＮＣ（１１０）への前記フローに対する前記ＭＡＣ−ｄ  ＰＤＵを伝送するＥ−ＤＣＨデータフレームの転送に遅延があることを示し、
前記ＴＮ損失輻輳は、前記Ｎｏｄｅ−Ｂ（１２０）から前記ＲＮＣ（１１０）への前記フローに対する１または２以上のＥ−ＤＣＨデータフレームが失われたことを示す、請求項５に記載の方法。
【請求項７】
前記ＵＥ（１３０）の前記ＲＬＣ送信ウィンドウサイズを縮小するステップ（Ｓ４５０）は、
前記輻輳は前記初期データフローセットアップから最初に発生したＴＮ損失輻輳であるかどうかを判定するステップ（Ｓ５３０）と、
前記輻輳が最初に発生したものであると判定される場合、前記ＵＥ（１３０）の前記ＲＬＣ送信ウィンドウサイズを縮小するステップ（Ｓ５５０）と
を含み、
前記ＴＮ損失輻輳は、前記Ｎｏｄｅ−Ｂ（１２０）から前記ＲＮＣ（１１０）への前記フローの転送におけるデータの損失を示す、請求項３に記載の方法。
【請求項８】
前記ＲＬＣ送信ウィンドウサイズを縮小するステップ（Ｓ４５０）は、所定の最小ウィンドウサイズ以上になるように前記ＲＬＣ送信ウィンドウサイズを設定するステップを含む、請求項１に記載の方法。
【請求項９】
前記ＵＥ（１３０）からの前記フローのＲＬＣ  ＰＤＵが適切に受信されたかどうか判定するステップ（Ｓ４３０）と、
前記ＵＥからの前記ＲＬＣ  ＰＤＵが適切に受信されたと判定される場合、前記ＵＥ（１３０）の前記ＲＬＣ送信ウィンドウサイズを増大させるステップ（Ｓ４６０）と、
増大した前記ＲＬＣ送信ウィンドウサイズに関して前記ＵＥ（１３０）に通知するステップ（Ｓ４６５）と
をさらに含む、請求項１に記載の方法。
【請求項１０】
前記ＲＬＣ送信ウィンドウサイズを増大させるステップ（Ｓ４６０）は、所定の最大ウィンドウサイズよりも大きくならないように前記ＲＬＣ送信ウィンドウサイズを設定するステップを含む、請求項９に記載の方法。
【請求項１１】
前記ＵＥ（１３０）に通知するステップ（Ｓ４６５）は、増大した前記ＲＬＣ送信ウィンドウサイズを特定したＲＬＣ  ＳＴＡＴＵＳ  ＰＤＵを形成して、前記ＵＥ（１３０）へ送信するステップを含む、請求項９に記載の方法。
【請求項１２】
前記初期データフローセットアップまたは以前の測定時間の満了のいずれか後に発生した方から所定量の時間が経過したかどうか判定するステップ（Ｓ４４０）と、
前記所定判定量の時間が経過したと判定された場合、前記ＲＬＣ送信ウィンドウサイズを増大させるステップ（Ｓ４６０）と、
増大した前記ＲＬＣ送信ウィンドウサイズに関して前記ＵＥ（１３０）に通知するステップ（Ｓ４６５）と
をさらに含む、請求項１に記載の方法。
【請求項１３】
無線ネットワーク（１００）における無線ネットワーク制御装置（ＲＮＣ）（１１０）であって、
Ｎｏｄｅ−Ｂ（１２０）を介してＵＥ（１３０）とＲＬＣ  ＰＤＵを交換する通信部（６４０）と、
前記ＲＮＣ（１１０）と前記Ｎｏｄｅ−Ｂ（１２０）との間の通信リンクのデータトラフィック条件を監視する監視部（６２０）と、
前記ＲＮＣ（１１０）と前記ＵＥ（１３０）との間のフローに対するデータと制御情報とを記憶する格納部（６３０）と、
前記通信部（６４０）と、前記監視部（６２０）と、前記格納部（６３０）とを制御して、前記ＲＮＣ（１１０）に対する通信オペレーションを行わせる処理部（６１０）と
を備える無線ネットワーク制御装置であって、
前記処理部（６１０）は、
初期データフローセットアップにおいてフローに対するＵＥ（１３０）のＲＮＣ送信ウィンドウサイズを設定し、
アップリンク方向における前記フローに対する前記ＲＮＣ（１１０）と前記Ｎｏｄｅ−Ｂ（１２０）との間のＩｕｂ  ＴＮ接続に輻輳が存在するかどうか判定し、
前記輻輳が存在すると判定された場合、前記ＲＬＣ送信ウィンドウサイズを縮小し、
縮小した前記ＲＬＣ送信ウィンドウサイズに関して前記ＵＥ（１３０）に通知し、
前記フローは、前記ＲＮＣ（１１０）と前記ＵＥ（１３０）との間で交換されるＲＬＣ  ＰＤＵから形成された媒体アクセス制御−ｄプロトコルデータユニット（ＭＡＣ−ｄ  ＰＤＵ）のフローであり、
前記ＲＬＣ送信ウィンドウサイズは、前記フローに対して、確認応答（ＡＣＫ）が前記ＲＮＣ（１１０）から送信されるまでに１または２以上のＲＬＣ  ＰＤＵで前記ＵＥ（１３０）から前記ＲＮＣ（１１０）へ送信可能な未処理データの最大量を設定する、ＲＮＣ（１１０）。
【請求項１４】
前記処理部（６１０）は、縮小した前記ＲＬＣ送信ウィンドウサイズを特定したＲＬＣ  ＳＴＡＴＵＳ  ＰＤＵを形成して送信し、前記ＵＥ（１３０）に通知する、請求項１３に記載のＲＮＣ（１１０）。
【請求項１５】
前記処理部（６１０）は、
前記輻輳が所定の時間内で最初の輻輳であるかどうか判定し、
前記輻輳が最初の輻輳であると判定される場合、前記ＲＬＣ送信ウィンドウサイズを縮小すること
によって、前記ＲＬＣ送信ウィンドウサイズを縮小し、
前記所定の時間は、前記ＵＥ（１３０）の前記初期データフローセットアップまたは以前の測定時間の満了のいずれか後に発生した方から経過した時間である、請求項１３に記載のＲＮＣ（１１０）。
【請求項１６】
前記処理部（６１０）は、
前記輻輳は前記Ｎｏｄｅ−Ｂ（１２０）から前記ＲＮＣ（１１０）への前記フローの転送の遅延を示す遅延形成輻輳であるか、または前記転送におけるデータの損失を示すトランスポートネットワーク（ＴＮ）損失輻輳であるかを判定し、
前記輻輳が前記遅延形成輻輳であると判定される場合、第１縮小量だけ前記ＲＬＣ送信ウィンドウサイズを縮小し、
前記輻輳が前記ＴＮ損失輻輳であると判定される場合、第２縮小量だけ前記ＲＬＣ送信ウィンドウサイズを縮小すること
によって、前記輻輳が最初の輻輳であると判定される場合に前記ＲＬＣ送信ウィンドウサイズを縮小し、
前記第１縮小量は前記第２縮小量よりも小さい、請求項１５に記載のＲＮＣ（１１０）。
【請求項１７】
前記遅延形成輻輳は、前記Ｎｏｄｅ−Ｂ（１２０）から前記ＲＮＣ（１１０）への前記フローに対する前記ＭＡＣ−ｄ  ＰＤＵを伝送するＥ−ＤＣＨデータフレームの転送に遅延があることを示し、
前記ＴＮ損失輻輳は、前記Ｎｏｄｅ−Ｂ（１２０）から前記ＲＮＣ（１１０）への前記フローに対する１または２以上のＥ−ＤＣＨデータフレームが失われたことを示す、請求項１６に記載のＲＮＣ（１１０）。
【請求項１８】
前記処理部（６１０）は、
前記輻輳は前記初期データフローセットアップから最初に発生したＴＮ損失輻輳であるかどうかを判定し、
前記輻輳が最初に発生したものであると判定される場合、前記ＵＥ（１３０）の前記ＲＬＣ送信ウィンドウサイズを縮小すること
によって、前記ＲＬＣ送信ウィンドウサイズを縮小し、
前記ＴＮ損失輻輳は、前記Ｎｏｄｅ−Ｂ（１２０）から前記ＲＮＣ（１１０）への前記フローの転送におけるデータの損失を示す、請求項１５に記載のＲＮＣ（１１０）。
【請求項１９】
前記処理部（６１０）は、所定の最小ウィンドウサイズ以上になるように前記ＲＬＣ送信ウィンドウサイズを縮小する、請求項１３に記載のＲＮＣ（１１０）。
【請求項２０】
前記処理部（６１０）は、
前記ＵＥ（１３０）からの前記フローのＲＬＣ  ＰＤＵが適切に受信されたかどうか判定し、
前記ＵＥからの前記ＲＬＣ  ＰＤＵが適切に受信されたと判定される場合、前記ＵＥ（１３０）の前記ＲＬＣ送信ウィンドウサイズを増大させ、
増大した前記ＲＬＣ送信ウィンドウサイズに関して前記ＵＥ（１３０）に通知する、請求項１３に記載のＲＮＣ（１１０）。
【請求項２１】
前記処理部（６１０）は、所定の最大ウィンドウサイズよりも大きくならないように前記ＲＬＣ送信ウィンドウサイズを増大させる、請求項２０に記載のＲＮＣ（１１０）。
【請求項２２】
前記処理部（６１０）は、増大した前記ＲＬＣ送信ウィンドウサイズを特定したＲＬＣ  ＳＴＡＴＵＳ  ＰＤＵを形成して送信する、前記ＵＥ（１３０）に通知する、請求項２０に記載のＲＮＣ（１１０）。
【発明の詳細な説明】
【技術分野】
【０００１】
開示する技術は、無線ネットワークにおける効率的な改善アップリンクフロー制御を促進することに関する。
【背景技術】
【０００２】
より高いスループット、すなわちより高いビットレートと、無線ネットワークによるパケットデータのより効率的な送信とに対する要求が大きくなるにつれ、第３世代パートナーシッププロジェクト（３ＧＰＰ：3rd  Generation  Partnership  Project）は、無線ネットワーク制御装置（ＲＮＣ：radio  network  controller）から無線基地局（Ｎｏｄｅ−Ｂ）へ、そして最終的にユーザ装置（ＵＥ：user  equipment）へ向かうダウンリンク方向にパケット化データを転送する高速ダウンリンクパケットアクセス（ＨＳＤＰＡ：High  Speed  Downlink  Packet  Access）でその仕様を拡張してきた。ＨＳＤＰＡの主な目的は、ダウンリンク方向においてアクセス可能性を増加させ、スループットを増加させ、遅延を低減させることで、ネットワーク容量を改善することである。
【０００３】
ＵＥからＮｏｄｅ−Ｂへのアップリンク方向でも、３ＧＰＰは、改善アップリンク（ＥＵＬ：Enhanced  Uplink）でその仕様を拡張してきた。ＥＵＬは、リリース’９９のものなどの以前のアップリンクオペレーションよりも高速にする特徴を提供する。新たな特徴には、マルチコード送信、短い送信時間（ＴＴＩ：transmission  time  interval）、高速ハイブリッド自動再送要求（ＨＡＲＱ：fast  hybrid  automatic  repeat  request）、高速スケジューリングが含まれる。
【０００４】
図１は、ＵＴＲＡＮシステム例１００を示している。システム１００は、Ｉｕインタフェースによってコアネットワーク（図示せず）と通信するＲＮＣ１１０を含む。また、システムは、ＩｕｂインタフェースによってＲＮＣ１１０に接続された複数Ｎｏｄｅ−Ｂ１２０を含む。ユーザ装置（ＵＥ）１３０は、典型的には移動端末であり、Ｕｕインタフェース（無線リンク）によって１または２以上のＮｏｄｅ−Ｂ１２０と通信する。
【０００５】
プロトコルレイヤと、ＲＮＣとＵＥとの間のデータ交換に関するノードとを図２に示す。ＲＮＣのＲＬＣ（radio  link  control：無線リンク制御）レイヤは、ダウンリンク方向におけるＵＥのＲＬＣレイヤにＲＬＣプロトコルデータユニット（ＰＤＵ：protocol  data  unit）を提供する。逆に、アップリンク方向では、ＵＥのＲＬＣレイヤが、ＵＥのＲＬＣレイヤにＲＬＣ  ＰＤＵを送信する。ＲＬＣ  ＰＤＵは、媒体アクセス制御−ｄ（ＭＡＣ−ｄ：Medium  Access  Control-d）ＰＤＵにパッケージ化され、これらのＭＡＣ−ｄ  ＰＤＵがＮｏｄｅ−Ｂを通してＲＮＣとＵＥとの間で交換される。
【０００６】
アップリンク方向でもダウンリンク方向でも、データ送信の障害が生じることがある。Ｎｏｄｅ−ＢとＲＮＣとの間のＩｕｂインタフェースにも、Ｎｏｄｅ−ＢとＵＥとの間のＵｕインタフェースにも、障害が生じることがある。輻輳状況に対処するには、フロー制御が必要である。
【０００７】
アップリンクについては、ＥＵＬフロー制御（ＦＣ：Flow  Control）のフレームワークが３ＧＰＰで規格化されている。３ＧＰＰ  ＴＳ  ２５．４２７  Ｖ６．６．０（２００６−０３）の「UTRAN  Iub/Iur  interface  user  plane  protocol  for  DCH  data  streams（ＤＣＨデータストリーム用ＵＴＲＡＮ  Ｉｕｂ／Ｉｕｒインタフェースユーザプレーンプロトコル）」という書類において、Ｅ−ＤＣＨ（enhanced  dedicated  transport  channel：改善専用トランスポートチャネル）ＤＡＴＡ  ＦＲＡＭＥ（ＤＦ：データフレーム）とＴＮＬ輻輳表示（ＴＣＩ：TNL  Congestion  Indication）制御フレーム（ＣＦ：Control  Frame）とが定義されている。Ｎｏｄｅ−Ｂから受信したＥ−ＤＣＨ  ＤＡＴＡ  ＦＲＡＭＥシーケンスに基づいて、ＲＮＣは、ＴＮＬ（transport  network  layer：トランスポートネットワークレイヤ）輻輳を検出し、ＴＣＩ  ＣＦを使用してＲＢＳに様々な輻輳のタイプを示すことができる。Ｅ−ＤＣＨ  ＭＡＣ−ｄフローを伝送するトランスポートベアラにおいて、ＲＮＣは、Ｉｕｂインタフェースに発生した輻輳状況を検出することができる。服装状況を検出すると、ＲＮＣは、ＴＣＩ  ＣＦを通して輻輳をＮｏｄｅ−Ｂに通知することができる。
【０００８】
ＴＣＩ  ＣＦを受信すると、Ｎｏｄｅ−Ｂは、Ｅ−ＤＣＨ  ＭＡＣ−ｄフローについてＩｕｂインタフェースのビットレートを低下させる。実際、ＭＡＣ−ｄフローのアップリンクに輻輳があると、既存のＵｕスケジューラは、ビットレートを制御して、輻輳を解消しようとする。ビットレート制御は、輻輳条件を変えるための反応時間を長くしてしまうことがあり、遅延を増加させてしまうことがある。
【発明の概要】
【０００９】
ある観点において、ＲＬＣの送信ウィンドウを使用して、ＵＥからＲＮＣへの、例えばＲＬＣ  ＰＤＵのフローなどのデータのフローの転送レートを制御することによって、アップリンク方向のＩｕｂトランスポート（ＴＮ）ネットワーク輻輳を解消する機構が提供される。ＲＮＣは、フローに対するＩｕｂ  ＴＮ輻輳を検出する。輻輳が検出されると、ＲＮＣで実行されるＥＵＬフロー制御が、フローに対するＵＥのＲＬＣ送信ウィンドウサイズを計算し、計算したＲＬＣ送信ウィンドウはＵＥにおけるピアＲＬＣ実体へ信号送信される。
【００１０】
ある実施形態において、ＲＮＣは、Ｉｕｂ輻輳検出部とＥＵＬ  ＦＣ部とを備える。Ｉｕｂ輻輳検出部は、アップリンク方向のフローに対するＩｕｂ  ＴＮ輻輳を検出する。Ｉｕｂ輻輳検出部は、ＲＮＣにおいてフレーミングプロトコルレベルにあるとすることができる。ＥＵＬ  ＦＣ部は、Ｉｕｂ輻輳検出部由来のＩｕｂ  ＴＮ輻輳の検出に反応する。ＥＵＬ  ＦＣは、ＵＥの新たなＲＬＣ送信ウィンドウサイズを計算し、ＲＬＣ  ＳＴＡＴＵＳ  ＰＤＵを通して、ＵＥにおけるＲＬＣ実体へ情報を送信する。
【００１１】
送信ウィンドウは未確認のＲＬＣ  ＰＤＵの数を制限する。アップリンクに輻輳が検出されると、ＵＥのＲＬＣ送信ウィンドウサイズは縮小される。縮小量は、検出された輻輳のタイプに依存する。ＲＬＣ  ＰＤＵ転送が成功したり、輻輳を検出することなく任意量の時間が経過したりすると、ＵＥのＲＬＣ送信ウィンドウサイズは増大される。
【００１２】
ウィンドウに基づく解決手段は、既存のアーキテクチャで実施することが可能である。また、Ｎｏｄｅ−ＢもＵＥも、プロトコルアーキテクチャに修正は必要ない。さらに、Ｎｏｄｅ−Ｂにおける既存のＵｕスケジューラとのやり取りが必要ない。さらに、輻輳制御はトランスポートネットワークに対して独立である。輻輳検出のみ、適用したＩｕｂ  ＴＮ（ＡＴＭやＩＰなど）に依存する。
【図面の簡単な説明】
【００１３】
本発明の上記およびその他の目的、特徴、効果は、添付図面に示した好ましい実施形態についての以下のより具体的な説明から明らかとなろう。添付図面においては、参照文字は、様々な図にわたって同一の部分を指している。図面は必ずしも寸法どおりではなく、その代わり、本発明の原理を説明するにあたって強調もしてある。
【００１４】
【図１】図１は、無線ネットワークシステムの一例を示す。
【図２】図２は、プロトコルレイヤと、ＥＵＬに関するノードとを示す。
【図３Ａ】図３Ａは、Ｉｕｂ  ＴＮ輻輳処理の送信ウィンドウサイズサポートを有するＲＬＣを備えるＲＮＣのアーキテクチャの一実施形態を示す。
【図３Ｂ】図３Ｂは、ＲＬＣ  ＳＴＡＴＵＳ  ＰＤＵメッセージを処理するＵＥのアーキテクチャの一実施形態を示す。
【図４】図４は、アップリンクにおけるＲＬＣ  ＰＤＵのフローについてＲＬＣ送信ウィンドウサイズにＲＮＣを適応させる方法の一例を示す。
【図５】図５は、ＵＥのＲＬＣ送信サイズの縮小を決定する処理の一例を示す。
【図６】図６は、ＲＮＣの一実施形態を示す。
【発明を実施するための形態】
【００１５】
以下の説明では、本発明の徹底的な理解を提供するために、限定ではなく説明を目的として、特定のアーキテクチャ、インタフェース、技術などの特定の詳細について記載する。しかしながら、当業者であれば、そのような特定の詳細から逸脱する他の実施形態において本発明を実施することも可能であることは明らかであろう。つまり、本発明の原理を具体化する、本発明の本質および範囲に含まれた様々な構成について、当業者であれば、かかる構成がここで明示的に記載されたり図示されたりしていなくとも工夫することが可能であろう。
【００１６】
例によっては、本発明の説明を不用な詳細で不明瞭にしないため、周知の装置、回路、方法の詳細な説明を省略する。本発明の原理、観点、実施形態、特定例についてここで記載した全ての言葉は、本発明の構造的均等物も機能的均等物も含むものとしたい。加えて、このような均等物は、現在周知の均等物も、将来開発される均等物も含むもの、すなわち構造に拘らず同一の機能を行うように開発されたいかなる構成も含むものであるとしたい。
【００１７】
このように、例えば、ここでのブロック図は、本技術の原理を具体化する例示的回路網の概念図を表すことがあるということが、当業者であれば了解されよう。同様に、いかなるフローチャート、状態遷移図、疑似符号なども、コンピュータや処理部が明示的に示されているかどうかに拘らず、コンピュータ読出可能媒体で実質的に表すことが可能で、そしてコンピュータや処理部で実行することが可能な様々な処理を表す、というも了解されよう。
【００１８】
「処理部」や「制御部」とラベルまたは説明された機能ブロックを含む様々な構成の機能は、専用ハードウェア、適切なソフトウェアに関連したソフトウェア実行可能ハードウェアを使用して提供することができる。処理部によって機能を提供される場合、単一の専用処理部、単一の共有処理部、いくつかが共有または分散された複数の個別処理部によって提供することができる。また、「処理部」や「制御部」という用語を明示的に使用しても、ソフトウェア実行可能ハードウェアを排他的に指すものと解釈すべきではなく、デジタル信号処理（ＤＳＰ：digital  signal  processor）ハードウェア、ソフトウェアを記憶する読出専用メモリ（ＲＯＭ：read  only  memory）、ランダムアクセスメモリ（ＲＡＭ：random  access  memory）、不揮発性ストレージを含むものとすることが可能であり、上記に限られない。
【００１９】
図２に示すアーキテクチャでは、ＵＥのＲＬＣレイヤが、ＲＮＣのピアＲＬＣレイヤへ送信するＲＬＣ  ＰＤＵを生成する。ＲＬＣレイヤは、ＲＬＣ  ＰＤＵをＭＡＣレイヤに提供する。ＭＡＣレイヤはＲＮＣとＮｏｄｅ−Ｂとの間で分割される。（ＲＬＣ  ＰＤＵに関連した）ＵＥが生成したＭＡＣ  ＰＤＵは、ＭＡＣ−ｄ  ＰＤＵといい、ＵｕインタフェースによってＮｏｄｅ−Ｂへ送信される。Ｎｏｄｅ−Ｂは、ＭＡＣ−ｄ  ＰＤＵをバッファし、ＩｕｂインタフェースによってＲＮＣへ送信する。
【００２０】
ある観点においては、Ｎｏｄｅ−Ｂを介したＵＥとＲＮＣとの間のＲＬＣレイヤからの、ＭＡＣ−ｄ  ＰＤＵに関連したＲＬＣ  ＰＤＵのフローとして、データフロー（あるいは単にフロー）を考えることができる。別の視点からは、ＲＮＣとＵＥとの間のＭＡＣ−ｄ  ＰＤＵのフローとして、フローを考えることもできる。
【００２１】
３ＧＰＰでは、ＵＥおよびＲＮＣのＲＬＣレイヤは、確認モード（ＡＭ：Acknowledged  Mode）でオペレーションを行うものとすることができる。ＡＭのＲＬＣを使用して、ＭＡＣレイヤなどの下位レイヤにおけるＨＡＲＱ不具合を補償することができる。ＲＬＣ  ＡＭでは、受信機が、ＲＬＣ  ＰＤＵ  ＡＣＫメッセージを送信部に送信することで、ＲＬＣ  ＰＤＵの受信を確認する。アップリンク方向では、ＲＮＣが受信機であり、ＵＥが送信機である。
【００２２】
ＲＬＣのオペレーションをＡＭで行う場合、送信機は、失われたＲＬＣ  ＰＤＵを全て再送する。損失は、Ｉｕｂ  ＴＮまたはＵｕにおいて発生していることがある。パケットが失われ、その結果ＲＬＣが再送されると、遅延変動が大きく増加する。このように、パケット損失とＲＬＣ再送とを最小化することが望ましい。
【００２３】
送信機がＲＬＣ  ＰＤＵを再送する理由の１つは、Ｉｕｂ  ＴＮまたはＵｕのいずれかにおいて障害が発生すると、輻輳によって、ＲＬＣ  ＰＤＵが失われたり、大きく遅延したりすることがあるためである。輻輳問題に対処するには既存の解決手段がある。既存の解決手段では、１）ＴＮ輻輳は全く考慮しない（ＴＮは障害になり得ないと想定する）。２）ＴＮ輻輳はＮｏｄｅ−ＢのＵｕスケジューラで処理する。ＲＮＣによって輻輳が検出され多ことを示すＴＣＩ  ＣＦをＵｕスケジューラが受信すると、スケジューラはフローのビットレートを低下させる。
【００２４】
既存の解決手段には不利な点がある。第１の解決手段では、ＴＮ輻輳を避けるためには、ＴＮネットワークに対して過供給を行わなければならない。これは深刻なパフォーマンスの低下を引き起こすことがある。第２の解決手段では、Ｕｕスケジューラの複雑さが、システムのＵｕ部分に関係のない機能性とともに増大する。
【００２５】
しかしながら、ＲＬＣそのものには輻輳を解消する能力がある。ある観点では、ＲＬＣ送信ウィンドウを使用して、フローのデータレートを制御する。送信機のＲＬＣの送信ウィンドウサイズは、Ｉｕｂ  ＴＮの輻輳状況に基づいて調整する。ＲＬＣ送信ウィンドウは、前述のように、未確認のＲＬＣ  ＰＤＵの数を限定する。つまり、ＲＬＣ送信ウィンドウがＵＥについて設定されると、ＲＮＣから確認応答（ＡＣＫ）が送信されるまでに１または２以上のＲＬＣ  ＰＤＵにおいてＵＥからＲＮＣへ送信可能なフローに対する未処理のデータの最大量を設定する。
【００２６】
輻輳が発生すると、ＲＬＣ送信ウィンドウサイズは縮小する。このように、フローのデータレートすなわちビットレートは低下する。輻輳がなければ、ＲＬＣ送信ウィンドウを増大させることができる。
【００２７】
様々なタイプの輻輳が区別され、輻輳のタイプに対する反応は異なるものとすることができる。例えば、Ｎｏｄｅ−ＢからＲＮＣへＭＡＣ−ｄ  ＰＤＵを伝送するＥ−ＤＣＨデータフレームの損失などのＩｕｂ  ＴＮにおける「損失」であれば、ＵＥのＲＬＣ送信ウィンドウサイズを比較的大きく縮小するものとすることができる。Ｅ−ＤＣＨデータフレームの転送の遅延などの「遅延形成」輻輳であれば、ＲＬＣ送信ウィンドウサイズを比較的わずかに縮小するものとすることができる。
【００２８】
アップリンクについて、ＲＮＣはフローのＩｕｂ  ＴＮ輻輳を検出する。ＲＮＣは、輻輳を検出したフローについてＵＥのＲＬＣ送信ウィンドウサイズを計算し、計算したＲＬＣ送信ウィンドウサイズはＲＬＣ  ＳＴＡＴＵＳ  ＰＤＵを通してＵＥのＲＬＣ実体へ信号送信される。効果の１つとして、既存のＲＬＣプロトコルを修正する必要がない。
【００２９】
輻輳を処理するために提案する解決手段の一例は、ＲＬＣにおいて以下の役割を含む。
・例えばＲＮＣのフレーミングプロトコルレベルにおいて、Ｉｕｂ  ＴＮ輻輳検出。この役割は、トランスポートネットワーク輻輳（すなわちＩｕｂ  ＴＮ輻輳）を検出する。
・ＲＮＣにおけるＥＵＬ  ＦＣ。この役割は、ＲＮＣにおけるＩｕｂ輻輳検出由来のＩｕｂ  ＴＮ輻輳に反応する。新たな送信ウィンドウサイズの計算後、この情報をＲＬＣ  ＳＴＡＴＵＳ  ＰＤＵを通してＵＥのＲＬＣ実体へ送信する。
【００３０】
図３Ａは、上述の２つの役割を含むＩｕｂ  ＴＮ輻輳処理の送信ウィンドウサイズサポートを有するＲＬＣを備えるＲＮＣのアーキテクチャの一実施形態を示している。
【００３１】
図３ＢはＵＥのアーキテクチャを示している。ＵＥにおけるＲＬＣ実体は、既存のプロトコルから修正していない。図３Ｂを提供したのは、単に、ＵＥ内のＲＬＣ実体が、ウィンドウサイズを特定するＲＬＣ  ＳＴＡＴＵＳ  ＰＤＵを受信すると、そのＲＬＣ送信ウィンドウサイズを規格化プロトコルにしたがって修正することを単に説明するためである。
【００３２】
図４は、アップリンクにおけるＲＬＣ  ＰＤＵのフローについてＲＬＣ送信ウィンドウサイズにＲＮＣを適応させる方法例Ｍ４００を示している。ここで、ＲＮＣがＮｏｄｅ−Ｂを通してＵＥとＲＬＣ  ＰＤＵを交換することができると想定する。より具体的には、ＲＮＣのＲＬＣレイヤを実施するＲＬＣ実体（部）が、ＵＥにおけるピアＲＬＣ実体とＲＬＣ  ＰＤＵを交換する。
【００３３】
ステップＳ１４０において、フローに対するＵＥのＲＬＣ送信ウィンドウサイズは初期フローセットアップ時に設定される。ある実施形態では、ＲＬＣ機能を実施するＲＬＣ部は、初期セットアップを行い、初期ＲＬＣ送信ウィンドウサイズを決定することができる。別の実施形態では、Ｎｏｄｅ−Ｂそのものが、ＵＥとの無線リンクが最初に構成された際に初期決定を行うことができる。さらに別の実施形態では、スロースタートフェーズを使用することも可能である。例えば、確認されたＲＬＣ  ＰＤＵ全てについて、ＲＬＣ送信ウィンドウのサイズは１ＲＬＣ  ＰＤＵだけ増大させることができる。
【００３４】
ステップＳ４２０において、ＲＮＣは、フローに対するＲＮＣとＮｏｄｅ−Ｂとの間のＩｕｂ  ＴＮ接続に輻輳が存在するかどうか判定する。Ｉｕｂ  ＴＮに輻輳が検出された場合、ステップＳ４５０においてＲＮＣはＵＥのＲＬＣ送信ウィンドウサイズを縮小する。
【００３５】
図５は、ステップＳ４５０を実施する処理の一例を示す。ステップＳ５１０において、ＲＮＣは、輻輳が所定の時間内の最初の輻輳であるかどうか判定する。ここで、所定の時間については、初期フローセットアップまたは以前の測定時間の満了のいずれか後に発生した方からの時間と見なすことができる。
【００３６】
輻輳が所定の時間内に最初に検出された輻輳である場合、ステップＳ５２０において、ＲＮＣは、輻輳が遅延形成輻輳なのかＴＮ損失輻輳なのか判定する。遅延形成輻輳とは、Ｎｏｄｅ−ＢからＲＮＣへフローに対するＭＡＣ−ｄ  ＰＤＵを伝送するＥ−ＤＣＨデータフレームの転送に遅延があることを示すものとすることができる。ＴＮ損失輻輳とは、フローに対する１または２以上のＥ−ＤＣＨデータフレームが失われたことを示すものとすることができる。
【００３７】
輻輳が遅延形成輻輳である場合、ステップ５５０において、ＵＥのＲＬＣ送信ウィンドウサイズが第１量だけ縮小される。輻輳が遅延形成タイプである場合、ステップ５５０において、第１量よりも大きな第２量だけＲＬＣ送信ウィンドウサイズが縮小される。つまり、縮小量は輻輳タイプに依存しており、遅延形成輻輳が発生したときよりもＴＮ損失輻輳が発生したときに大きく縮小するのが好ましい。
【００３８】
ある実施形態では、第１量および第２量は固定とすることができる。別の実施形態では、第１量および第２量は、現ＲＬＣ送信サイズに印加される固定乗算因子とすることも可能である。例えば、遅延形成輻輳またはＴＮ損失輻輳に遭遇すると、ＵＥの現ＲＬＣ送信ウィンドウサイズに第１因子ｆ１または第２因子ｆ２をそれぞれ乗算するものとすることができる。この場合、関係０＜ｆ１＜ｆ２＜１を真としておくべきである。
【００３９】
これが所定の時間内において最初の輻輳発生かどうか判定し、最初の発生のみに対して実行することによって、任意の時間内で複数の輻輳が検出されたとしても、ＲＬＣ送信ウィンドウサイズを非常に頻繁に調整することを避けることができる。
【００４０】
しかしながら、任意の所定の時間内の後続の輻輳検出に反応することが望ましい例もあり得る。より具体的には、初期フローセットアップからの最初のＴＮ損失輻輳の発生では、ＲＬＣ送信ウィンドウを適宜縮小するのが好ましい。これについては、ステップＳ５１０、Ｓ５３０、Ｓ５５０に反映されている。
【００４１】
最小ＲＬＣ送信ウィンドウサイズを維持して、あまりにも小さなウィンドウサイズを避けるのが望ましいということに留意されたい。したがって、ある実施形態では、ＲＬＣ送信ウィンドウサイズを縮小した結果、ウィンドウサイズが所定の最小ウィンドウサイズを下回ってしまった場合、ＲＬＣ送信ウィンドウサイズを所定の最小ウィンドウサイズ以上になるように設定する。
【００４２】
ステップＳ４５０、より具体的にはステップＳ５４０およびＳ５５０では、ＲＮＣが、ＵＥのＲＬＳ送信ウィンドウサイズをどれだけ縮小すべきか判定するが、ＲＬＣ送信ウィンドウサイズの実際の設定はＲＮＣでは行われないということに留意されたい。その代わりに、図４に示すように、ステップＳ４６５において、縮小したＲＬＣ送信ウィンドウサイズに関してＲＮＣがＵＥに通知する。
【００４３】
ある実施形態では、ＲＬＣ送信ウィンドウサイズの縮小に関してＵＥに通知するため、ＲＮＣはまず、縮小したＲＬＣ送信ウィンドウサイズを特定したＲＬＣ  ＳＴＡＴＵＳ  ＰＤＵを形成する。そしてＲＮＣはＲＬＣ  ＳＴＡＴＵＳ  ＰＤＵをＵＥへ送信する。ＵＥは、ＲＬＣ  ＳＴＡＴＵＳ  ＰＤＵメッセージを受信すると、フローに対するそのＲＬＣ送信ウィンドウサイズを更新する。
【００４４】
輻輳は、ＵＥのＲＬＣ送信サイズを縮小してフローのスループットを低下させるべきであるということを示すものであるが、他にも、ＲＬＣ送信サイズを増大させてスループットを上昇させるということを示す状況もあり得る。図４を再度参照すると、ステップＳ４３０において、ＲＮＣは、ＵＥから送信された１または２以上のＲＬＣ  ＰＤＵが適切に受信されたかどうか判定する。適切に受信された場合、これは、ＲＮＣとＵＥとの間のトランスポートリンクが高いスループットで処理されているということを示していることがある。このように、ＲＬＣ  ＰＤＵが適切に受信されたと判定されると、ステップ４６０において、ＲＮＣはＵＥのＲＬＣ送信サイズを増大させることができる。
【００４５】
また、Ｓ４６０においてＵＥのＲＬＣ送信ウィンドウサイズをどれだけ増加させるべきかについては、ＲＮＣが決定するが、実際の設定は行わない。その代わりに、ステップ４６５において、増大させたＲＬＣ送信ウィンドウサイズに関してＲＮＣがＵＥに通知する。ＲＮＣは、増大させたウィンドウサイズを特定したＲＬＣ  ＳＴＡＴＵＳ  ＰＤＵを形成して送信することによって、ＵＥに通知するものとすることができる。
【００４６】
他に、ＲＮＣとＵＥとの間のトランスポートリンクが高いスループットで処理されていると示すのは、任意の所定の時間内でＩｕｂ  ＴＮに輻輳が検出されないときである。これについてはステップＳ４４０に反映されており、輻輳が検出されることなく、初期データフローセットアップまたは以前の測定時間の満了のいずれか後に発生した方から所定の時間が過ぎたかどうか、ＲＮＣが判定する。輻輳が検出されなければ、ＲＮＣは、ステップＳ４６０においてＵＥのＲＬＣ送信ウィンドウを増大させ、ステップＳ４６５においてＵＥに通知することができる。明示はしていないが、タイマは、ステップＳ４６０において満了するとリセットされるものと想定することができる。
【００４７】
ＵＥのＲＬＣ送信ウィンドウサイズはあまりに大きくしないようにするのが好ましい。したがって、ある実施形態では、ＲＬＣ送信ウィンドウを増大させる場合、所定の最大ウィンドウサイズよりも大きくならないように設定する。
【００４８】
実際の効果の１つは、ＲＬＣ送信ウィンドウサイズを（増大または縮小のいずれかに）設定することによって、フローについて、ＲＮＣから確認応答（ＡＣＫ）が送信されるまで１または２以上のＲＬＣ  ＰＤＵでＵＥからＲＮＣへ送信可能な未処理データの最大量が設定される。
【００４９】
図６は、上述の方法を実施するＲＮＣの一実施形態例を示している。ＲＮＣは、処理部６１０と、監視部６２０と、格納部６３０と、通信部６４０とを備える。処理部６１０はＲＮＣのオペレーション全体を制御するものであり、ＲＮＣのオペレーション全体には、その他の部６２０〜６４０の調整および制御を行って、当該方法を行わせることが含まれる。
【００５０】
監視部６２０はＲＮＣの状況を監視するものであり、監視には、Ｉｕｂ  ＴＮなどのＲＮＣとＮｏｄｅ−Ｂとの間の通信リンクのデータトラフィック条件を監視することが含まれる。格納部６３０はＲＮＣ１１０の適切な機能に必要な情報を記憶するものであり、記憶には、ＲＮＣとＵＥとの間のデータフローに対するデータおよび制御情報を記憶することが含まれる。格納部６３０を使用して、ＲＬＣ  ＰＤＵやＭＡＣ  ＰＤＵなどをバッファし、プロトコルアーキテクチャを実施することが可能である。通信部６４０は、Ｎｏｄｅ−Ｂを通してＵＥと通信を行うものであり、通信には、対応するＭＡＣ−ｄ  ＰＤＵにパッケージ化されたＲＬＣ  ＰＤＵを交換することが含まれる。Ｎｏｄｅ−Ｂとの通信は、Ｉｕｂ  ＴＮによって行われるものとすることができる。
【００５１】
部６１０〜６４０は、図６では別々の部として示してある。しかしながら、これは機能が別々であることを単に示しているだけである。部は、別々のハードウェア装置として提供することができる。しかしながら、その他の構成も可能である。部のいかなる組合せについても、ソフトウェア、ハードウェア、および／またはファームウェアのいかなる組合せで実施することも可能である。
【００５２】
開示した１または２以上の実施形態の効果は多数ある。効果には、少なくとも以下のものが含まれる。
・提案した解決手段は、既存のアーキテクチャで実施することができる。
・Ｎｏｄｅ−ＢもＵＥも、プロトコルアーキテクチャを修正する必要がない。
・Ｎｏｄｅ−Ｂにおける既存のＵｕスケジューラとのやり取りが必要ない。
・輻輳制御はトランスポートネットワークに対して独立である。輻輳検出のみ、適用したＩｕｂ  ＴＮ（ＡＴＭやＩＰなど）に依存する。
【００５３】
上述の説明には多くの特異性が含まれているが、これらについては本発明を限定するものと解釈すべきではなく、単に現時点で好ましい本発明の実施形態のいくつかの説明を提供するものであると解釈すべきである。したがって、本発明の範囲は、当業者には明らかなものとなり得る他の実施形態を完全に含むものであり、本発明の範囲はそのように限定されるものではないと了解されよう。当業者が知っている上述の好ましい実施形態における構成に対する全ての構造的均等物および機能的均等物は、参照により本明細書に明確に組み入れるものとし、本明細書に含まれるものとしたい。また、装置や方法については、ここで説明した問題全て、または本技術が解決しようとすることで本明細書に含まれる問題全てに対処する必要はない。さらに、本開示における構成、構成要素、方法動作は、公に供するものではないとしたい。
【図１】
2011504002.tif 000003
【図２】
2011504002.tif 000004
【図３Ａ】
2011504002.tif 000005
【図３Ｂ】
2011504002.tif 000006
【図４】
2011504002.tif 000007
【図５】
2011504002.tif 000008
【図６】
2011504002.tif 000009
【国際調査報告】
2011504002.tif 000010
2011504002.tif 000011
2011504002.tif 000012