(57)【要約】ＵＭＴＳ無線アクセスネットワークの無線ネットワーク制御装置とノードＢとの間のIub又はIub/Iurインタフェース上におけるユーザプレーントラフィック量を過負荷期間中に制御する方法である。この方法は、Iub又はIub/Iurインタフェース上に確立されたアップリンク又はダウンリンクコネクションの各々について、Iub又はIub/Iurインタフェース上で伝送されたフレームの、無線ネットワーク制御装置又はノードＢにおける到着遅延を無線ネットワーク制御装置で監視するステップと、監視の結果に基づき、必要に応じてコネクションについてのIub又はIub/Iur負荷を削減させるステップとを有する。
2008516486.tif 000002
【特許請求の範囲】
【請求項１】
ＵＭＴＳ無線アクセスネットワークの無線ネットワーク制御装置とノードＢとの間のIub又はIub/Iurインタフェース上におけるユーザプレーントラフィック量を過負荷期間中に制御する方法であって、前記Iub又はIub/Iurインタフェース上に確立されたアップリンク又はダウンリンクコネクションの各々について、前記Iub又はIub/Iurインタフェース上で伝送されたフレームの前記無線ネットワーク制御装置又は前記ノードＢにおける到着遅延を前記無線ネットワーク制御装置で監視するステップと、前記監視の結果に基づき、必要に応じてコネクションについての前記Iub又はIub/Iur負荷を削減させるステップとを有することを特徴とする方法。
【請求項２】
前記方法が前記Iub又はIub/Iurインタフェース上のパケット交換コネクションに適用されることを特徴とする請求項１記載の方法。
【請求項３】
前記フレームの到着遅延を監視するステップが、フレームプロトコルエンティティから与えられる結果を解析するステップを有することを特徴とする請求項１又は請求項２記載の方法。
【請求項４】
前記結果が、前記ダウンリンク方向については前記ノードＢから前記無線ネットワーク制御装置が受信するＴＡフレームから得られ、前記アップリンク方向においては前記無線ネットワーク制御装置においてフレームの到着時刻に基づいて直接得られることを特徴とする請求項３記載の方法。
【請求項５】
前記フレームの到着遅延を監視する前記ステップが、前記ダウンリンク方向についてのＴＡフレームの数及び／又は前記アップリンク方向における到着遅延フレームの数を計数するステップと、計数値をなんらかの閾値と比較するステップを有することを特徴とする請求項１乃至請求項４のいずれか１項に記載の方法。
【請求項６】
Iub又はIub/Iur負荷削減が、前記計数値が前記閾値以上となったことをきっかけに行われることを特徴とする請求項５記載の方法。
【請求項７】
Iub又はIub/Iur負荷削減が、ＴＡフレームの受信又はフレームの到着遅延後に、ある規定された確率に基づいて行われることを特徴とする請求項１乃至請求項６のいずれか１項に記載の方法。
【請求項８】
前記フレームの到着遅延を監視するステップが、受信したＴＡフレームに含まれる到着時刻の値又は、到着遅延フレームについて計算された遅延の値を監視するステップと、前記到着時刻又は遅延がある規定された閾値を超えたことをきっかけとしてIub又はIub/Iur負荷削減を行わせるステップとを有することを特徴とする請求項１乃至請求項７のいずれか１項に記載の方法。
【請求項９】
前記Iub又はIub/Iur負荷の削減を行わせるステップが、送信側メディアアクセス制御エンティティが利用可能な転送フォーマットのうち、許可されるものを制限するステップを有することを特徴とする請求項１乃至請求項８のいずれか１項に記載の方法。
【請求項１０】
前記Iub又はIub/Iur負荷の削減を行わせるステップが、無線リンク制御ウィンドウのサイズを削減するステップを有することを特徴とする請求項１乃至請求項９のいずれか１項に記載の方法。
【請求項１１】
前記Iub又はIub/Iur負荷の削減を行わせるステップが、無線アクセスベアラを、Iubリソースの消費がより少ない状態に切り替えるステップを有することを特徴とする請求項１乃至請求項１０のいずれか１項に記載の方法。
【請求項１２】
前記Iub又はIub/Iur負荷の削減を行わせるステップが、輻輳したIub又はIub/Iurリンク上での伝送待ち状態のＩＰパケットを削減するステップを有することを特徴とする請求項１乃至請求項１１のいずれか１項に記載の方法。
【請求項１３】
前記Iub又はIub/Iur負荷の削減を行わせるステップが、前記無線ネットワーク制御装置において前記ノードＢから１以上のＴＡフレームを受信したことに応答して、前記Iubユーザプレーンフレームの一部を廃棄するステップを有することを特徴とする請求項１乃至請求項１２のいずれか１項に記載の方法。
【請求項１４】
前記Iub又はIub/Iur負荷を削減させるステップが、マルチレート音声エンコーダ／デコーダペアのコーディングレート削減を要求するステップを有することを特徴とする請求項１乃至請求項１３のいずれか１項に記載の方法。
【請求項１５】
ＵＭＴＳ無線アクセスネットワークの無線ネットワーク制御装置とノードＢとの間のIub又はIub/Iurインタフェース上におけるユーザプレーントラフィック量を過負荷期間中に制御する方法であって、前記Iub又はIub/Iurインタフェース上に確立されたアップリンク又はダウンリンクコネクションの各々について、無線リンク制御再送レート又は無線リンク制御スループットを前記無線ネットワーク制御装置又はユーザ端末で監視するステップと、前記監視の結果に基づき、必要に応じてコネクションについての前記Iub又はIub/Iur負荷を削減させるステップとを有することを特徴とする方法。
【請求項１６】
ＵＭＴＳ無線アクセスネットワークの無線ネットワーク制御装置とノードＢとの間のIub又はIub/Iurインタフェース上におけるユーザプレーントラフィック量を過負荷期間中に制御する方法であって、前記Iub又はIub/Iurインタフェース上に確立されたダウンリンクコネクションの各々について、前記Iub又はIub/Iurインタフェース上で伝送されたフレームの前記ノードＢにおける到着遅延を前記ノードＢで監視するステップと、前記監視の結果に基づいて、必要に応じてコネクションについての前記Iub又はIub/Iur負荷を削減させるステップとを有することを特徴とする方法。
【請求項１７】
前記監視するステップは、受信フレーム内に含まれるタイムスタンプをローカルクロックと比較するステップを有することを特徴とする請求項１６記載の方法。
【請求項１８】
ＵＭＴＳ無線アクセスネットワークの無線ネットワーク制御装置とノードＢとの間のIub又はIub/Iurインタフェース上におけるユーザプレーントラフィック量を過負荷期間中に制御する方法であって、前記Iub又はIub/Iurインタフェース上に確立されたアップリンク又はダウンリンクコネクションの各々について、前記Iub又はIub/Iurインタフェース上で伝送されたフレームの前記無線ネットワーク制御装置又は前記ノードＢにおける到着遅延を監視するステップと、前記監視の結果に基づいて、送信側メディアアクセス制御エンティティが利用可能な転送フォーマットのうち、許可されるものをコネクション単位で制限することにより、前記Iub又はIub/Iur負荷を減少させるステップとを有することを特徴とする方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、電気通信システムの無線アクセスネットワーク内での輻輳制御機構に関する。特に、本発明は、ＵＭＴＳ無線アクセスネットワークのIub又はIub/Iurインタフェースのための輻輳制御機構に関する。
【背景技術】
【０００２】
３ＧＰＰとして知られる第３世代パートナーシッププロジェクトグループは、現在進行中の、ＵＭＴＳ(Universal Mobile Telecommunications System)又は３Ｇと呼ばれるＷＣＤＭＡプロトコル群の標準化作業に関与している。ＵＭＴＳオペレータネットワークは、複数の主要構成要素、すなわちユーザセッションの設定及び制御の責を負う１つ又は複数のコアネットワークと、エアインタフェースへのアクセスを制御するＵＭＴＳ無線アクセスネットワーク（ＵＴＲＡＮ）とに分けることができる。ＵＴＲＡＮの模式的なアーキテクチャを図１に示す。ＵＴＲＡＮとユーザ端末（ＵＥ）との間の、ノードによって与えられるインタフェースは、（２Ｇ／ＧＳＭネットワークにおける基地局のように）「ノードＢ」と呼ばれる。ノードＢは無線ネットワーク制御装置（ＲＮＣ）に制御されるとともに、エアインタフェースを通じたデータ送受信の責を負う。ユーザデータ及び制御データは、ノードＢ及びＲＮＣを介して、ＵＥ及びコアネットワークの間でルーティングされる。ノードＢとＲＮＣとの間のインタフェースを、Iubインタフェースと呼ぶ。
【０００３】
あるＵＥとＲＮＣとの間で、２つ又はそれより多いノードＢを介して同一のデータが伝送されうるような状況がある。これはダイバーシチハンドオーバ機能（ＤＨＯ）又はマクロダイバーシチと呼ばれる。複数のノードＢは、同一又は異なる複数のＲＮＣによって制御されうる。後者の場合、データはドリフトＲＮＣを介して制御（又はサービング）ＲＮＣへルーティングされる。サービングＲＮＣとドリフトＲＮＣとの間のインタフェースを、Iurインタフェースと呼ぶ。これらの両方を図１に示す。共通（即ち共用）チャネル及び個別チャネルについて、ＲＮＣとノードＢとの間のペイロード搬送の責を負うプロトコルは3GPP TS 25.435及びTS 25.427にそれぞれ記載されている。ＲＮＣ及びノードＢに存在するプロトコルレイヤを図２に示す。ここで特に関係があるのは、ノードＢとＲＮＣとの間で、上位層（ＭＡＣ／ＲＬＣ）から与えられるユーザプレーンデータを搬送する責を負うフレームプロトコル（図２ではＦＰと表記されている）である。
【０００４】
フレームプロトコル下のトランスポートネットワーク（ＴＮ）は、セル交換型のＡＴＭネットワーク又はパケットベースのＩＰネットワークのいずれかによって実現可能である。必要なサービス品質をトランスポートネットワークが実現することを保証するための通常の手法は、利用可能な容量があれば新しいコネクションを許可する、ある種のトランスポートネットワーク許可制御機構を適用することである。この手法は、与えられる負荷や統計的特性がよく知られ、かつ分かっているコネクション、例えば音声に対してはうまく機能する。こういったコネクションの負荷の総計は、簡単且つ精度良く推定することができる。推定負荷がトランスポートネットワークの容量を超える場合、新たなコネクションは許可されない。このようにして、保守的に過ぎる許可機構によってリソースを無駄にすることなく、全てのアクティブなコネクションが期待されるトランスポートネットワークサービス品質を享受することを保証できる。
【０００５】
トランスポートネットワークの予約及び許可制御は、以下に述べるような理由により、パケット交換型（ＰＳ）データコネクションを考慮する場合にはずっと難しくなる。
・ＰＳチャネルが与える負荷は、音声コネクションに対する負荷よりもずっと高くなりうること。個別チャネル（ＤＣＨ）上では最大384Kbps又はそれ以上、高速ダウンリンク共有チャネル（ＨＳ−ＤＳＣＨ）上ではMbpsのオーダ又はそれ以上である。
・ＰＳベアラ上のトラフィックパターンが、長いアイドル期間に続く大きなデータバーストを呈する音声コネクションと比較して、ずっと大きな変化を示すこと。
・ＰＳトラフィックの統計的特性は、良く分かっておらず、さらに、簡単なモデルによって捕えられてもいないこと。負荷は、リンク品質、価格設定、顧客セグメント、時刻や時期等の複雑な関数となりうる。
【０００６】
ＰＳトラフィックにトランスポートネットワーク許可手順を用いる場合、２つの異なる手法を行いうる。
慎重な許可：必要とされる性能をトランスポートネットワークが常に実現することを確実にするため、入来するコネクションを控えめな予約レベルでブロックする。難点は、許可されているコネクションのアクティビティが低い場合には、入来コネクションが不必要にブロックされそうなことである。この方法は、トランスポートネットワークの低利用率と、コネクションがブロックされる原因となる。
寛容な許可：不必要なブロックを避けるため、（全ユーザが同時にデータを送信又は受信することはないという仮定の下に）全てのコネクションがアクティブになった場合に直ちに処理可能な数よりも多くのＰＳユーザを許可する。難点は、多すぎるコネクションが負荷を与えた場合にトランスポートネットワークが過負荷となる可能性があることである。
【０００７】
通常はこれらのうち前者の方法が用いられる。つまり、その時々で、例えば384KbpsのＰＳコネクションがわずかばかり許可されうるに過ぎない。これは、帯域の狭い(thin)Ｅ１又はＴ１リンクによってIubが実現される場合に特に当てはまる。
【０００８】
より多くのＰＳコネクションを許可し（ブロックを回避し）、起こりうるIubの過負荷状況に対処する方法を有することが望ましいであろう。そのような手法を実現するうえで２つ問題がある。１つ目は、コネクション毎に、Iubインタフェースの輻輳を明確に検出するための機構が存在しないこと。２つ目は、関与するIubプロトコルが、Iub輻輳に反応しないことである。これは、ＦＰエンティティが、Iubインタフェース上で起こりうる過負荷とは無関係に、ＭＡＣ／ＲＬＣエンティティから与えられる負荷をトランスポートネットワークへ常に供給することを意味する。Iub負荷制御に関する既存技術（例えば、Sarayder等による、「Iubリンクの容量におけるレート制御の影響：複数サービスの場合」、WCNC 2003会報）は、ある輻輳制御アルゴリズムに基づく中央集中的な解決法を用いている。EP1331768及びUS2003223454もまた、Iub負荷制御の問題に対する中央集中的な解決策を提案している。
【０００９】
寛容な許可により、狭帯域のIubを通じていくつかの384Kbpsベアラが許可されていると仮定すると、問題点をさらに明らかにすることができる。いくつかの／全てのベアラがたまたま同時にトラフィックを与えた場合、コネクションの一部又は全てについて、Iubフレームの遅延又は損失が生じるであろう。ＰＳベアラは通常、確認モード(AM)を用いて実現されるので、受信側ＲＬＣエンティティは損失したフレーム内容の再送を要求するであろう。送信側ＭＡＣ／ＲＬＣが再送データを与える限り、ＦＰインスタンスはデータをIub上で入れ替え続けるであろう。従って、過負荷が継続しうることを意味する。想定される最悪の事態では、どのコネクションも時間通りにデータを受信できず、全ての損失データが送信側ＲＬＣ再送バッファへ回される。そして、ＲＬＣ／ＭＡＣ／ＦＰエンティティは、プロトコルエラーが発生し、リセットによって再送が放棄されるまで、何の救済もなしに、過負荷データをIubへ与え続けるであろう。
【発明の開示】
【００１０】
上述した過負荷問題の１つの解決法は、過負荷時にIub負荷をうまく(gracefully)削減する方法を作り出すことである。Iubインタフェースから受信する局所測定に基づく非中央集中的な手法を用いてIub輻輳を軽減しようとする仕組みが提案される。検出されたIub輻輳に対応するため、既存及び新しい方法の両方を用いて輻輳を制御する様々な手段が検討される。これはまた、Iub/Iur結合インタフェース上で過負荷が生じる状況においても同様に適用できる。
【００１１】
Iub（又はIub/Iur)過負荷の最初の徴候は、受信側ＦＰエンティティでのフレーム到着遅れである。ダウンリンク方向（すなわち、ＲＮＣからノードＢ方向）について、ＦＰはウィンドウに基づく仕組みを規定し、これによりフレームの到着が監視される。この仕組みは図２に示されており、（マクロダイバーシチをサポートするため）フレームが無線で時間通りに伝送されることを確保するために必要である。フレームが「遅い」又は「遅すぎ」領域で受信される場合、ノードＢは、フレームが無線送信に（殆ど）遅すぎであったことを示すタイミング調整（ＴＡ）フレームをＲＮＣへ送信することにより応答する。このＴＡフレームの主な目的は、マクロダイバーシチ手法の異なるIubレグが異なる遅延を有しうるため、ＲＮＣにおけるタイミングオフセット制御を管理することである。アップリンク方向（すなわちノードＢからＲＮＣ方向）においても、タイミングデータを直接アクセス可能なＲＮＣを用いて、ウィンドウに基づく同様の仕組みを実施可能である（すなわち、アップリンク方向では、ＴＡフレームを送信する必要がない）。
【００１２】
本発明の１つの目的は、Iubインタフェースを通じたフレームの到着遅延を検出するための、ウィンドウに基づく仕組みを用い、Iub輻輳の初期徴候を提供することにある。この手法はアップリンク及びダウンリンクの両方に適用可能であり、コネクション毎の輻輳検出を可能にする。これは、Iubインタフェースの輻輳制御のための中央集中型の解決法のみを提供する既知の中央集中型手法とは対照的である。本発明の第１の見地によれば、ＵＭＴＳ無線アクセスネットワークの無線ネットワーク制御装置とノードＢとの間のIub又はIub/Iurインタフェース上におけるユーザプレーントラフィック量を制御する方法であって、Iub又はIub/Iurインタフェース上に確立されたアップリンク又はダウンリンクコネクションの各々について、Iubインタフェース上で伝送されたフレームの無線ネットワーク制御装置又はノードＢでの到達遅延を無線ネットワーク制御装置で監視するステップと、監視の結果に基づき、必要に応じてコネクションについてのIub負荷を減少させるステップとを有する方法が与えられる。
【００１３】
本発明は、特に、Iubインタフェース上で確立されたパケット交換（ＰＳ）コネクションに対して適用可能である。本発明の実施形態は、Iub上で常により多くのＰＳベアラを許可することが可能なので、コネクションがブロックされる可能性を低減する。そして、これにより増加するIub輻輳の可能性は、輻輳時に負荷をうまく低減するような方法によって対処される。本発明による利点は、
Iubリソースの利用率向上−ネットワーク配備コストの低減、
コネクションブロックの可能性低減−顧客満足度の向上、
ユーザ知覚に与える影響を小さくしながら、うまく輻輳に対処する−顧客満足度の向上
を含む。
【００１４】
さらに、ここで提案する方法は、あるコネクションの負荷制御がIubリンクを用いる他のいかなるコネクションとも独立した非中央集中的な負荷制御を用いている。これにより、ここで提案する仕組みは、非常に単純且つ簡単に配備できる。
【００１５】
ここで提案する方法はIub輻輳測定を用いる。これは、従来技術が通常、各Iubリンクの全てのコネクションの負荷を加算して総計負荷を計算する方法に依存していることとは対照的である。繰り返すが、これにより、提案する方法は、より単純且つ簡単に実施できる。
【００１６】
本発明の制御方法は、Iubインタフェース上の全コネクションにも、そのサブセットのみにも適用可能である。例えば、パケット交換データを転送するコネクションのみに方法を適用することができる。本発明は、音声のような回線交換データを転送するためにIub上に確立されたコネクションにも適用可能である。Iub負荷削減は、音声データ用のコーデックレートを削減することで実現できる。
【００１７】
本発明のある実施形態において、フレームの到着遅延を監視するステップは、フレームプロトコルエンティティから与えられる結果を解析するステップを有する。ダウンリンク方向の場合、これら結果はノードＢから無線ネットワーク制御装置が受信するＴＡフレームから得られる。アップリンク方向の場合、これら結果は無線ネットワーク制御装置におけるフレーム到着時刻から直接的に得られる。
【００１８】
フレームの到着遅延を監視するステップは、ダウンリンク方向についてのＴＡフレームの数及び／又はアップリンク方向における到着遅延フレームの数を計数するステップと、計数値をある閾値と比較するステップを有していて良く、計数値が閾値以上となったことをきっかけにIub負荷削減を行う。あるいは、ＴＡフレームの受信又はフレームの到着遅延後に、ある規定された確率に基づいて負荷削減を行っても良い。
【００１９】
フレームの到着遅延を監視するステップは、受信したＴＡフレームに含まれる到着時刻の値又は、到着遅延フレームについて計算された到着時刻を監視するステップ及び、到着時刻がある規定された閾値を超えたことをきっかけとしてIub負荷削減を行わせるステップとを有しうる。
【００２０】
Iub負荷削減を行わせるステップは、以下の１つ以上のステップを有しうる。
・ＭＡＣエンティティが利用可能な転送フォーマットのうち、許可するものを制限するステップ。
・ＲＬＣウィンドウのサイズを削減するステップ。
・無線アクセスベアラ（ＲＡＢ）を、Iubリソースの消費がより少い状態へ切り替えるステップ。
・輻輳したIubリンク上での伝送待ち状態のＩＰパケットを削減(drop)するステップ、
・ノードＢから無線ネットワーク制御装置がＴＡフレームを受信したことに応答して、Iubユーザプレーンフレームの一部を廃棄するステップ。
【００２１】
あるいは、又はさらに、Iub又はIub/Iur負荷を削減させるステップは、マルチレート音声エンコーダ／デコーダペアのコーディングレート削減を要求するステップを有する。
【００２２】
本発明の第２の見地によれば、ＵＭＴＳ無線アクセスネットワークの無線ネットワーク制御装置とノードＢとの間のIub又はIub/Iurインタフェース上におけるユーザプレーントラフィック量を過負荷期間中に制御する方法であって、Iub又はIub/Iurインタフェース上に確立されたアップリンク又はダウンリンクコネクションの各々について、ＲＬＣ再送レート又はＲＬＣスループットを無線ネットワーク制御装置又はユーザ端末で監視するステップと、監視の結果に基づき、必要に応じてコネクションについてのIub負荷を減少させるステップとを有する方法が与えられる。
【００２３】
本発明の第３の見地によれば、ＵＭＴＳ無線アクセスネットワークの無線ネットワーク制御装置とノードＢとの間のIubインタフェース上におけるユーザプレーントラフィック量を過負荷期間中に制御する方法であって、Iub又はIub/Iurインタフェース上に確立されたダウンリンクコネクションの各々について、Iubインタフェース上で伝送されたフレームのノードＢにおける到着遅延をノードＢで監視するステップと、監視の結果に基づき、必要に応じてコネクションについてのIub負荷を減少させるステップとを有する方法が与えられる。
【００２４】
発明のこの見知に係る実施形態において、監視するステップは、受信フレーム内に含まれるタイムスタンプをローカルクロックと比較するステップを含みうる。
【００２５】
本発明の第４の見地によれば、ＵＭＴＳ無線アクセスネットワークの無線ネットワーク制御装置とノードＢとの間のIub又はIub/Iurインタフェース上におけるユーザプレーントラフィック量を過負荷期間中に制御する方法であって、Iub又はIub/Iurインタフェース上に確立されたアップリンク又はダウンリンクコネクションの各々について、Iub又はIub/Iurインタフェース上で伝送されたフレームの無線ネットワーク制御装置又はノードＢにおける到着遅延を監視するステップと、監視の結果に基づいて、送信側メディアアクセス制御エンティティが利用可能な転送フォーマットのうち、許可されるものをコネクション単位で制限することにより、Iub又はIub/Iur負荷を減少させるステップとを有する方法が与えられる。
【発明を実施するための最良の形態】
【００２６】
ＲＮＣとノードＢとの間のフレームプロトコル（ＦＰ）及び、そのプロトコルスタック内での位置を模式的に図２に示す。ＦＰの責務の１つは、ＲＮＣと関連するノードＢ（マクロダイバーシチにおいては複数のノードＢ）との間のIubインタフェース上のフレームのタイミングを取りはからうフレーム同期機能の実施である。図３は、ダウンリンク（ＤＬ）無線フレーム構成に関するノードＢでのフレーム同期ウィンドウを示す図である。ここで、ノードＢでフレームを処理するために使われる時間をＴprocと定義する。アップリンク方向において、サービングＲＮＣは、異なる複数のIub/Iur上で受信された複数の同一フレームの受け取り(receipt)を調整することができ、ここでもフレーム同期機能が、サービングＲＮＣにおいてそれらフレームが時間通り受信されることを保証すべきである。
【００２７】
ダウンリンク方向について考慮すると、付随ＣＦＮ番号付きのフレームは、ある所定時刻に無線伝送されなければならない。複数のノードＢ及びIub/Iurが関与する場合、ノードＢの全てはその特定のフレームを同時に伝送しなければならない。Iubリンク上の遅延が異なると仮定すると、送信を行うノードＢの全てにおいて遅れずにフレームが受信されるように、サービングＲＮＣは十分なタイムオフセットを持ってフレームを送信しなければならない。それら、高速Iubリンクの「背後にある」ノードＢは、スケジュールされた送信時刻までフレームをバッファしなければならない。
【００２８】
この機能を管理するため、3GPP TS 25.402は、フレームがノードＢに早く受信されたか、遅れて受信されたかを監視するのを容易にする「受信ウィンドウ」を規定するパラメータを指定している。これらパラメータを図３に示す。ウィンドウは、ToAWS（到着時刻ウィンドウ開始点）が最も早い点並びにノードＢが必要とする最小のバッファ容量を規定し、ToAWE（到着時刻ウィンドウ終了点）がフレームの「望ましい」最終到着時刻を規定するような「目標」として機能する。ToAWEとLtoA（最終到着時刻）点の間に受信されたフレームは遅れたものと見なされるが、伝送に間に合わないわけではない。LtoA以降に受信されたフレームは廃棄される。標準規格は、フレームがウィンドウ外で受信された場合、ＲＮＣがオフセットを適合できるよう、ノードＢがＲＮＣにどのように報告すべきかについて規定している。すなわち、受信ウィンドウ外で受信された各フレームについて、ノードＢは、サービングＲＮＣがオフセットを調整できるよう、そのフレームのToA（到着時刻）を示す「タイミング調整」(TA)フレームを用いて応答しなければならないとされている。
【００２９】
本明細書では、ＴＡフレームの機構を、ダウンリンク方向における輻輳の表示として用い、ＲＮＣにおいて輻輳を軽減するための適切な対応を取ることを提案している。もちろん、これは、ＴＡフレームをその意図された目的、すなわちフレーム同期にも用いることに何の影響も及ぼさない。アップリンク方向において、ＲＮＣは、ＲＮＣにおいて、ＦＰエンティティが生成するタイミングデータを直接利用可能である。
【００３０】
ＦＰは負荷制御のための方法を全くサポートしないため、負荷削減は、ＲＮＣにおいて、メディアアクセス制御（ＭＡＣ）、無線リンク制御（ＲＬＣ）又は無線リソース制御（ＲＲＣ）レベルで利用可能な方法を用いて実現することができる。これらの方法は、以下の一時的な対処を含む。
ａ）ＭＡＣエンティティが利用可能な転送フォーマットのうち、許可するものを制限する。これは、384Kbpsコネクションにおいて、ある有限期間、（転送ブロックが４０オクテットのペイロードを含み、伝送間隔が１０ｍｓに等しいとした場合、伝送間隔あたりの転送ブロック最大数を１２から４に削減することにより、）コネクション容量が例えば128Kbpsへ低下しうることを意味する。これはおそらく好ましい方法である。
ｂ）ＲＬＣウィンドウのサイズを削減する。ＲＬＣウィンドウは未処理(outstanding)データの最大量を制限するので、これにより過負荷が軽減されるであろう。例えば、ＲＬＣウィンドウを現在使用中のレベルに制限することが可能であり、この場合、受信側エンティティで新たなデータの確認がなされない限り、再送のみが許可されることになる。
ｃ）無線アクセスベアラ（ＲＡＢ）を、Iubリソースの消費のより少ない状態へ切り替える。これは、ＲＮＣとユーザ端末（ＵＥ）との間のＲＲＣシグナリングを伴う。
ｄ）輻輳したIubリンク上での伝送待ち状態のＩＰパケット(RLC SDU)を削減(drop)する。
ｅ）ノードＢから無線ネットワーク制御装置がＴＡフレームを受信したことに応答して、Iubユーザプレーンフレームの一部、例えば１／２又は１／３を廃棄する（「選択的なフレーム廃棄」）。
【００３１】
これら対処の全ては、輻輳したIubリンク上のコネクションによる負荷を削減するであろう。また、これら対処の全ては、ダウンリンク及びアップリンクの両方に適用可能である。
【００３２】
輻輳検出に応じて負荷削減を実施するために動作する機能(intelligence)は、ＲＮＣ内に配置されている。この機能は、Iub/Iur過負荷を制御するためにＭＡＣ，ＲＬＣ及び／又はＲＲＣにおいて利用可能な「ツール」である。それは基本的にＲＮＣ内部の転送リソース管理エンティティである。
【００３３】
過負荷削減を行うきっかけとなる水準は、ネットワーク容量のみならず予期されるネットワークの振る舞いにもある程度依存するであろう設計事項である。しかし、一例を挙げれば、過負荷削減を行うきっかけとなるＴＡフレームの数を定めることができるであろう。別の解決法は、ＴＡフレームを受信した際に、ある確率、例えば５０％の確率で過負荷削減を実行することである。つまりこの場合、ＴＡフレームの受信毎に、５０％の確率で過負荷削減が引き起こされる可能性がある。いずれによっても、２つの問題が解決される。すなわち、まず１つめに、全てのコネクションが同時に同期して速度低下(synchronised back-off)することを回避し、２つめに、ＴＡフレームの原因が静的遅延(static delay)である場合のビットレート低下を回避する。２番目の問題は、ソフトハンドオーバにおける「新たな」レグに対するＴＡフレームが到着した場合には反応しないようにすることでも解決可能であろう。これは、そのフレームが新たなレグについての静的遅延によるものであろうからである。この、ＴＡフレームのフィルタリングは、提案した他の解決法の１つと組み合わせて用いることもできる。
【００３４】
先に概説した過負荷制御処置ａ）及びｂ）は、それぞれ、3GPP TA25.321及びTS25.322に規定された確立したプロトコル手順である。いずれの処置も、損失を増やすことなく負荷を削減するであろう。ダウンリンクでの作用は非常に高速であり、ＴＴＩベースでの割り当てが可能である。アップリンク負荷制御については、ＴＦＣＳ制限（又はＲＬＣウィンドウサイズ制限）をＲＮＣからＵＥへ無線送信しなければならないため、いくらか多めの遅延が存在する。
【００３５】
処置ｃ）は標準ＲＲＣ手順を含むが、（処置ａ）及びｂ）と比較すると）遅延が大きい。処置ｃ）の利点は、ベアラ利用率の低い期間、無線リソースも解放される点である。例えば、低いベアラレートへの切替えは、ＷＣＤＭＡダウンリンク用の拡散コードリソースを解放する。60Kbpsを384Kbpsリンク上で送信するよりも、60Kbpsを64Kbpsリンク上で送信する方が効率的である。これは、384Kbps上での「ビット毎」のリソース消費が、64Kbpsと比較して大きいためである。符号(code)も符号化労力(code-power)も、帯域が狭いダウンリンク上の方が簡単(cheaper)である。
【００３６】
瞬時負荷を削減するのみならず、処置ｄ）は、ＲＬＣ ＳＤＵがＲＬＣ ＡＭループ外で廃棄され、損失がＴＣＰのようなエンドツーエンドプロトコルで検知可能となれば、ＴＣＰ（「動的キュー管理」：ＡＱＭ）のようなエンドツーエンドプロトコルの反応性を通じ、より持続的なエンドツーエンドの負荷をも削減するであろうという利点を有する。ＴＣＰはパケット損失に反応してその負荷を軽減するので、Iubリンクに与えられる負荷が低減される。
【００３７】
処置ｅ）は、輻輳しているIubレグのみに影響するという利点を有する。ＵＥがソフトハンドオーバ中であり、他のレグ（輻輳Iubレグを除く）からの受信に基づいてのみフレームの内容を識別可能であれば、ＲＬＣ／ＭＡＣスループットは影響を受けないままであるということである。ＵＥが廃棄されたフレームの内容を受信しないとすると、その内容はＲＬＣにより再送要求されるであろう。
【００３８】
アップリンクIub輻輳をノードＢに知らせる手段が現在は存在せず、またそのような通知は輻輳点に至る前にパケットを削減するために必要であろうため、処置ｅ）は現在ダウンリンクにのみ適用可能である（その目的のために何らかの新しい測定法が標準化される可能性もあり、その場合、この処置をアップリンクにも同様に適用可能である）。しかし、ダウンリンクについて、Iubから出てゆくユーザプレーンフレームを廃棄することにより、すくなくとも以下の利点が得られる。
・トランスポートネットワークレイヤ（ＴＮＬ）上に１つ以上の待ち行列が形成されること、すなわち伝送ノード上のＥＴボード(ET-Board)を回避することができる。長い待ち行列は過大な遅延をもたらし、従ってノードＢでのフレーム到着が非常に遅れる結果となり、そのような非常に遅れたフレームは結局ノードＢで廃棄されることになる。
・ＴＮＬバッファが短い場合の、ＴＮＬ上の損失を回避できる。多数／全てのコネクションについて何の制御もなしにフレームを廃棄する代わりに、１つ又は少数のコネクションについて、制御された方法でフレームを廃棄する。
【００３９】
ＲＮＣでの負荷制御処置の実装は、過負荷状況をすぐに解除しなくても良い。その場合、輻輳の表示がさらに受信されたならば、処置を繰り返すことができる。ある特定のコネクションについて、最後の輻輳表示からガード時間内にさらなる輻輳表示が受信されなければ、もともと割り当てられていたリソースをそのコネクションに対して再割り当てすることができる。輻輳処置によって影響を受けていた全ユーザが同時に負荷を再増加させることを回避するため、ガード時間は、好ましくは無作為に変化するタイマーであって良い。さらに、あるいはその代わりに、各コネクションが輻輳表示に対して反応する確率を割り当てて、全てのコネクションが輻輳状況に同時に反応しないことを確実にしても良い（過負荷のきっかけを、ＴＡフレームの受信の後の確率として規定する上述の検討を参照のこと）。
【００４０】
過負荷処置ａ）〜ｅ）は、個別又は組み合わせて展開されうる。組み合わせて配置する場合の一例として、ａ）〜ｅ）における対策を、以下のように輻輳の持続性に応じて順番に展開することができる。
・所定のコネクションに対する最初の輻輳表示の後：
−そのコネクションがソフトハンドオーバ中であり、かつ輻輳レグが「主」レグでなければ、ｄ）を展開する。
−さもなければ、ａ）又はｂ）を展開する。
・輻輳が持続していれば、ｃ）及びｅ）の両方を展開する。
ｃ）及びｅ）は、効果が得られるまでに時間がかかるため、オプションで、上述のように、さらにｄ）又はａ）／ｂ）を実行してもよい。
【００４１】
標準化されたＴＡフレームを輻輳表示として用いる代わりに、現在のタイミングオフセット値を用いたり、輻輳表示のための特有の測定を開発及び標準化することも考えられるであろう。前者の場合、オフセット値を監視し、オフセットが所定の閾値を超えて増加しそうであることが見出された場合には、ａ）及びｃ）〜ｅ）に記載される対策のいずれかを選択することができるであろう。本発明は、以下の測定結果を含む、他の測定結果をIub輻輳表示として利用する可能性をも含みうる。
・ＲＬＣ再送レート（持続的な輻輳の場合に、非常に増加する）、
・ＲＬＣスループット、
・ジッタ及び／又は遅延解析用の、タイプスタンプを有するフレーム。
【００４２】
本方法は、既存の標準規格を変更することなく適用可能である。しかし、標準化に当って考慮し得る点が存在する。
・オフセット調整とIub輻輳制御とを切り離すために、それぞれに個別の測定を規定する必要があるかもしれない点。
・Iubアップリンク輻輳：Iubアップリンク輻輳時に素速く負荷を削減するためには、ＲＮＣからノードＢへ輻輳を知らせる必要があるかもしれない。これは現在の標準規格を用いては行えない。この可能性がなければ、無線によるシグナリングを伴うUu負荷制御によりIub輻輳を軽減しなければならない。ＲＮＣがノードＢにノードＢの負荷を削減するように要求することができれば、ノードＢはIub上で許可されているフレームの量を削減するための対策を素速く行うことができ、有害な結果である過負荷を最小化することができるであろう。
【００４３】
上述の説明ではIubインタフェースを参照したが、サービングＲＮＣ及びドリフトＲＮＣの両方があるコネクションに関与している場合には、結合Iub/Iurインタフェース上で輻輳が生じること、サービングＲＮＣがＴＡフレーム（又は他の輻輳表示）を受信し、過負荷削減処置を行わせるであろうことが理解されよう。ドリフトＲＮＣは実質上ＴＡフレームに対しては透過的であるため、過負荷状況には反応しない。
【００４４】
本技術分野に属する当業者は、本発明の範囲内で、上述の実施形態に対して様々な変更を加えることが可能であることを理解するであろう。
【図面の簡単な説明】
【００４５】
【図１】ＵＭＴＳシステムのＵＴＲＡＮアーキテクチャを模式的に示す図である。
【図２】図１のＵＴＲＡＮのＲＮＣ及びノードＢに存在するプロトコルスタックの要素を示す図である。
【図３】図１のＵＴＲＡＮのノードＢに実装されたフレーム同期ウィンドウの概念を模式的に示す図である。
【図１】
2008516486.tif 000003
【図２】
2008516486.tif 000004
【図３】
2008516486.tif 000005
【国際調査報告】
2008516486.tif 000006
2008516486.tif 000007
2008516486.tif 000008