JP4847589B2 - 通信ネットワークにおけるトラフィック負荷制御 - Google Patents

Description

本発明は通信に関し、特に無線通信に関する。

現代の通信ネットワークでは、複数のタイプのサービスを提供することのニーズが次第に重要になってきている。例えば、サービス品質ＱｏＳ、リアルタイムＲＴサービスのための保障を提供することが重要である。ＲＴサービスはそのようなメディアストリーミング、音声／映像会話及びマルチメディアブロードキャストのようなものである。

ネットワークは多数のユーザによって共有されるので、各サービスセッションは、サービスセッションをサポートするネットワークにおける各リンクで呼搬送容量、即ち、帯域幅の適切な共有を必要とする。そのような容量は制限されているので、輻輳の問題がよく起こる。

輻輳したリンクで帯域幅を制御する公知の態様は、非リアルタイムＮＲＴサービスセッションに対して許容されるレートを減らすことである。目的はリアルタイムＲＴサービスセッションのための十分な帯域幅があることを確実にすることである。ＮＲＴトラフィック制御については、トラフィック整形及びレートに基づくフロー制御のような多数の周知の方法がある。

具体的には、ユニバーサル移動体通信システム（ＵＭＴＳ）ネットワークでは、基地局コントローラ（無線ネットワークコントローラＲＮＣ）とそれらが制御する基地局の間にはインターフェイスがあり、それはＩｕｂインターフェイスとして知られる。これらのＩｕｂインターフェイス上のトラフィックを制御するための公知のアプローチは、ＲＴセッションの送信速度を制限せずに、ＮＲＴセッションの、特に双方向及び背景ＵＭＴＳのＱｏＳクラスの送信速度を低減することである。

発明者は、既存のシステムを検討していて、帯域幅制御の公知のアプローチは、ＲＴトラフィックが常に優先されるべきという前提でＲＴトラフィックを制限せずに非リアルタイムＮＲＴトラフィックを軽減することを要求するものであることに気付いた。発明者はこの前提が誤っているのではないかと認識した。

通信ネットワークにおいてリンク上のトラフィックを制御する方法が提供される。リンクは非リアルタイムサービス及びリアルタイムサービスのユーザセッションを搬送する。その方法はリンク上のトラフィック負荷を周期的にモニタするステップを備える。その方法はさらに、上記負荷を所定のレベル未満にするようにリンク上のＮＲＴトラフィックとＲＴトラフィックを交互に連続的に制限するステップを備える。
本発明の実施例がここに例示として図面を参照して記載される。

図１は通信ネットワークを示す図である。 図２は図１に示すネットワークのリンクにおける帯域幅制御の方法を示す図である。 図３はＵＭＴＳ通信ネットワークを示す図である。 図４は図３に示すＵＭＴＳネットワークのリンクにおいて適用される帯域幅制御の方法を示す図である。

発明者は、既存のシステムを検討していて、帯域幅制御の公知のアプローチは非リアルタイムＮＲＴトラフィックの制御を関与させるが、リアルタイム「ＲＴ」トラフィックもまた適切な態様で制御される必要があることを認識した。発明者はこれを以下の理由によると考える。

（１）ＲＴトラフィックはＮＲＴトラフィックよりも常に高い優先度で扱われるべきという議論は妥当でないことがある。ユーザに知覚されるパフォーマンスについて、ウェブブラウジングの際の遅い応答や長時間のファイルダウンロードのようなＮＲＴサービスセッションの悪化は受け入れられない。

（２）ネットワークによっては、ＮＲＴ又はＲＴどちらのアプリケーションがユーザによって使用されているかにかかわらずユーザのトラフィックを差異付ける必要がある。例えば、ネットワークによっては、あるユーザのトラフィックに対して他に比べて厳しいサービス品質ＱｏＳ要件を適用し、及び適用することに課金する。一例は、ゴールド、シルバー、ブロンズＱｏＳが保障されたユーザである。ゴールドＱｏＳを契約したユーザは最も高い優先度を期待する緊急サービスプロバイダー、例えば、警察、救急車、消防隊及び他の政府機関等である。シルバーユーザは割増金を支払い、高いＱｏＳを期待する企業の顧客等となり得る。ブロンズユーザはより少ない支払いでいわゆるベストエフォートパフォーマンスを受け入れることができる不定期の顧客となり得る。

（３）多くのＲＴサービスセッションはセッションを終了することなくダウングレードすることができる。これらのダウングレードは通常、オン・ザ・フライ・メディアコーデックレートの低減、又は無線ベアラの再構成によってより少ない帯域幅が要求されることを意味する。ゴールドユーザがＮＲＴサービスセッションを有し、それが輻輳した場合、ゴールドユーザのＮＲＴサービスセッションの取扱いをダウングレードするのではなく、ブロンズユーザのＲＴサービスセッションの取扱いをダウングレードするのが好ましいことがある。

（４）場合によっては、特に異なるタイプのネットワークで構成される通信システムでは、負荷分散（バランシング）としても知られるトラフィックの負荷軽減が、幾つかのユーザをネットワーク内の他のリンク又は他のネットワークに移すように実行されることができる。標準的なシナリオは、第２世代（２Ｇ）ネットワークが重複無線カバレッジエリアを有する、ＵＭＴＳネットワーク等の第３世代ネットワーク（３Ｇ）にある。３Ｇネットワーク上のデータサービスのユーザが高いデータレートを享受することを維持できるように、３Ｇ音声サービスは２Ｇネットワークに負荷軽減できる。

発明者は自身の発明を成し遂げ、その実施例が以下に記載される。

＜第１のネットワーク例＞
図１に示すように、例示のネットワーク２はノード８に対するリンク６を含むノードコントローラ４からなる。ノードコントローラは帯域幅マネージャ１０を含む。

＜帯域幅マネージャ＞
帯域幅マネージャ１０は、制御されるべきリンク６のノードコントローラ４に存在するトラフィックコントローラである。帯域幅マネージャ１０は多数のタスクを有する。第１に、それはリンク負荷を連続的あるいは周期的にモニタし、リンク負荷ＬＬがトラフィック輻輳閾値Ｔｈ＿ＴＣを超える場合にトラフィック制御機能をトリガする。この閾値Ｔｈ＿ＴＣは合計リンク帯域幅の固定の割合、例えば９５％、又は単位時間あたりの固定のトラフィック量であればよい。

第２に、帯域幅マネージャ１０はリアルタイムトラフィックの種々のＱｏＳグループに適用されるべき帯域幅閾値のセット、及び非リアルタイムトラフィックの種々のＱｏＳグループに適用されるべき帯域幅閾値のセットも含む表を保持する。

第３に、帯域幅マネージャ１０は輻輳が起こった時に、上記表に従って所定のタイプのトラフィックに要求される軽減量を計算するステップ、及びそれらのタイプのトラフィックの進入を適切に低減するステップによって、トラフィックの軽減を実行する。これは以下の図２に関してより詳細に記載される。

第４に、必要があれば帯域幅マネージャは負荷分散、即ち、第１のリンク６を介したトラフィックを軽減するようにあるトラフィックを他のリンク６に移すステップを実行する。

第５に、輻輳を制御する必要があれば帯域幅マネージャ１０は選択されたユーザセッションを解放する。言い換えると、最も低いＱｏＳグループのユーザからユーザセッションを廃棄する。

＜リンク輻輳制御方法＞
リンク輻輳を制御するために帯域幅マネージャ１０によって使用される例示の方法がここに記載される。

根底にある原理は、輻輳が解消されるまで、記憶された閾値の表に従って交互にリアルタイムトラフィック及び非リアルタイムトラフィックに対する制限又は制限のセットをそれぞれのＱｏＳグループによって累積的に追加することである。制限は記憶された閾値の表に定義される。

表１は記憶された閾値の表の、多数の可能性の中の一例を示す。この表はＮＲＴトラフィックに対する一連の閾値「ＮＲＴ＿Ｉ（Ｉ＝１、２、３、・・・、Ｎ）」及びＲＴトラフィックに対する一連の閾値「ＲＴ＿Ｉ（Ｉ＝１、２、３、・・・、Ｎ）」を、全てキロビット／秒で示す。同表はまた、輻輳制御制限が適用される前の各タイプのトラフィックの初期最大許容レート（ベースレート）をキロビット／秒で示す。

表１：輻輳制御のための閾値例

表１から分かるように、トラフィックのタイプはそれらが非リアルタイム（ＮＲＴ）サービス又はリアルタイム（ＲＴ）サービスに関するかによって分けられる。ＱｏＳグループ１のユーザはＱｏＳグループ２よりも多くを支払い、より良いサービス品質を期待し、ＱｏＳグループ３は最小のＱｏＳ保障が与えられる。もちろん、他の類似の実施例において、３個より多いＱｏＳグループがあってもよい。

表１に示すベースレートは制限が適用される前の個人ユーザセッションに対する最大許容レートである。これらは最大ユーザベアラレート又はユーザリンクレイヤーレートとしても知られる。もちろん、ＮＲＴトラフィックについて、ユーザセッションの例示のデータレートはこのタイプのトラフィックのバースト性に起因して最大許容レートの０〜１倍のどこかになり得る。ＲＴトラフィックについて、例示のデータレートは変動がより少ないが、対応する最大許容レートよりも小さい。

閾値は、どのＮＲＴトラフィックＮＲＴ＿Ｉ（Ｉ＝１、２、３、・・・、Ｎ）に対する閾値のセットが、及びどのＲＴトラフィックＲＴ＿Ｉ（Ｉ＝１、２、３、・・・、Ｎ）に対する閾値が現在適用されているかに依存して、各タイプの各コールセッションに対する最大許容レートを示す。

なお、実際のレートが表１に与えられるが単なる例示である。代替的であるが類似の実施例では、多数の異なるベースレートを有する多数のトラフィックタイプがある場合に閾値を表示する容易な態様となり得るので、閾値はベースレートの割合として与えられる。

図２は帯域幅マネージャ１０で行われる輻輳制御プロセスの一例を示す。プロセスは以下の通りである。

帯域幅マネージャ１０はリンク負荷ＬＬレベルを判定する（ステップａ）。このＬＬレベルの判定は、例えば２０ミリ秒毎のような設定間隔で、あるいは連続的に行われる。負荷レベルＬＬが輻輳制御閾値Ｔｈ＿ＴＣ以下か否かについてチェックが行われる（ステップｂ）。リンク負荷（ＬＬ）がＴｈ＿ＴＣ以下である間は、全てのユーザセッションが関連のタイプのセッションについての最大許容レート（ベースレート）まで使用できる。

ＬＬがＴｈ＿ＴＣを超える場合には、トラフィック軽減の第１のステップ（ステップｃ）が適用される。即ち、表１に示すように帯域幅閾値ＮＲＴ−１の新たなセットがＮＲＴトラフィックに適用される。例えば、ＮＲＴＱｏＳグループ１のユーザのセッションに対する最大許容レートは８００ｋｐｂｓに維持される一方、ＮＲＴＱｏＳグループ２のユーザのセッションに対する最大許容レートは６００ｋｂｐｓに低減され、ＮＲＴＱｏＳグループ３のユーザのセッションに対する最大許容レートは４００ｋｂｐｓに低減される。

制限ＮＲＴ−１が適用されたら、ＬＬがＴｈ＿ＴＣより小さいかについてのチェックがなされる（ステップｄ）。ＬＬが未だにＴｈ＿ＴＣを超えている場合、更なるトラフィック軽減が今度はＲＴトラフィックに適用され、具体的には表１に示すようにＲＴトラフィックに適用される帯域幅閾値ＲＴ＿１のセットが適用される（ステップｅ）。具体的には、
ＲＴＱｏＳグループ１のユーザのセッションに対する最大許容レートが５００ｋｂｐｓに維持される一方で、ＲＴＱｏＳグループ２のユーザのセッションに対する最大許容レートが４００ｋｂｐｓに低減され、ＲＴＱｏＳグループ３のユーザのセッションに対する最大許容レートが３００ｋｂｐｓに低減される。

この態様では、輻輳制御サイクルにおいて、ＮＲＴトラフィックが最初に制限され、ＮＲＴトラフィックの制限がリンク負荷ＬＬを必要な閾値Ｔｈ＿ＴＣ以下にするのに十分でなかった場合にＲＴトラフィックの制限が続く。

最大許容レートが適用される実際のメカニズムは周知であり、例えば、フローレートを規制するようにパケットをバッファリングすること、ソース出力レート制御、及びパケットをランダムに廃棄すること等がある。

この第１のサイクルのトラフィック制御の後に、ＬＬが未だにＴｈ＿ＴＣを超えているかのチェックがなされる（ステップｆ）。超えている場合、更なるトラフィック制御、即ち、
更なるセットの閾値ＮＲＴ＿２をＮＲＴトラフィックに適用することによってＮＲＴトラフィック軽減の第２のステップ（ステップｇ）が行われる。具体的には、表２に示すように、ＮＲＴＱｏＳグループ１のユーザのセッションに対する最大許容レートが６００ｋｂｐｓに低減され、ＮＲＴＱｏＳグループ２のユーザのセッションに対する最大許容レートが４００ｋｂｐｓに低減され、ＮＲＴＱｏＳグループ３のユーザのセッションに対する最大許容レートが３００ｋｂｐｓに低減される。

再び、リンク負荷（ＬＬ）がＴｈ＿ＴＣよりも大きいかチェックが行われ（ステップｈ）、そうであれば、閾値ＲＴ＿２の更なるセットをＲＴトラフィックに適用することによって、ＲＴトラフィック軽減の第２のステップ（ステップｉ）が行われる。具体的には、表２に示すように、ＲＴＱｏＳグループ１のユーザに対する最大許容レートが４００ｋｂｐｓに低減され、ＲＴＱｏＳグループ２のユーザに対する最大許容レートが３００ｋｂｐｓに低減され、ＲＴＱｏＳグループ３のユーザに対する最大許容レートが２００ｋｂｐｓに低減される。

従って、ＮＲＴそしてＲＴトラフィック制限の第２のサイクルが行われる。図２に示すように、ＬＬ＞Ｔｈ＿ＴＣである間はそのようなサイクルが、Ｎ番目のサイクルが適用されるまで徐々に厳格な最大許容レート閾値が適用されて繰り返される。なお、Ｎは２以上の所定数、例えば５などである。最後のサイクルでは、ＮＲＴＱｏＳグループ及びＲＴＱｏＳグループに対する最大許容レートは表２の右側に示される。

最大許容レートにおける全てのそのような低減の後に、ＬＬが未だにＴｈ＿ＴＣを超えているかのチェックが行われる（ステップｊ）。超えている場合、リンク負荷を軽減するための更なるアプローチが適用される。まず、ＮＲＴトラフィックの負荷分散が可能かのチェックが行われる（ステップｋ）。これは帯域幅マネージャ１０が他のリンクのリンク負荷レベルについての情報を取得することによって示される。それらが予備的な容量を有している場合、いくつかのＮＲＴユーザセッションがそれらのリンクに移される（ステップｌ（エル））。

ＮＲＴ負荷分散が可能でない場合、それでもＲＴトラフィックを負荷分散することが可能な場合があるのでそれに関してのチェックが行われる（ステップｌ_２）。可能な場合、幾つかのリアルタイムユーザセッションが適切な他のリンクに移される（ステップｍ）。

他のあるいは類似の実施例では、負荷分散はＮＲＴトラフィックに対して最初に行われない。しばしば、移された先のリンクが劣った性能を有していたり、特定のタイプのトラフィックに対してのみ適切であったりするので、通常は移されるのは低いＱｏＳグループにあるユーザセッションのみである。

図２に示すように、負荷バランスが可能でない場合には、最後の手段として幾つかのユーザセッションが、まずは最も低いＱｏＳグループのユーザから、終了される（ステップｍ）。

他のあるいは類似の実施例では、負荷分散の後にＬＬ＞Ｔｈ＿ＴＣかのチェックが行われ、そうなっている場合には幾つかのユーザセッションが終了される。

＜最大許容レート制限の緩和＞
輻輳制御プロセスにおけるあらゆる段階で、例えばユーザ数の減少に起因してトラフィックレベルが低下すると、帯域幅マネージャ１０はそれに従って帯域幅閾値を緩和し、即ち、最大許容レートを表２に従って適切なステップ又は一連のステップで上昇させる。例えば、ＲＴ＿２からＲＴ＿１への各緩和の後に、ＬＬがＴｈ＿２よりも小さいかの評価が行われる。ここで、Ｔｈ＿２はＴｈ＿ＴＣよりも小さい。小さい場合、例えばＮＲＴ＿２からＮＲＴ＿１への更なる緩和が行われる。

この態様において、基本的には、輻輳制御は負荷レベルが高過ぎるときに提供される。

上記アプローチの１つの有利な効果は制御がＮＲＴ及びＲＴの両方に比較的徐々に適用され得ることである。制限されるのはＮＲＴトラフィックのみではないので、周知のシステムのアプローチよりも緻密なアプローチと考えることができる。

ネットワークオペレータは異なる輻輳制御サイクルにおける異なるトラフィックタイプに対する最大許容レートの選択において多くの選択肢を持つことができる。例えば、ネットワークオペレータがＲＴ中心のネットワークとしたい場合、ＲＴトラフィックに対する高い最大許容レートが設定される。言い換えると、一連の閾値ＲＴ＿Ｉ（Ｉ＝１、２，３、・・・、Ｎ）が比較的高く維持される一方で、ＮＲＴトラフィックに対する閾値ＮＲＴ＿Ｉ（Ｉ＝１、２、３、・・・、Ｎ）がより厳しくなる。

一方で、ネットワークオペレータがＮＲＴ中心のネットワークとしたい場合、ＮＲＴトラフィックに対する高い最大許容レートが設定される。言い換えると、一連の閾値ＮＲＴ＿Ｉ（Ｉ＝１、２、３、・・・、Ｎ）が比較的高く維持される一方で、ＲＴトラフィックに対する閾値ＲＴ＿Ｉ（Ｉ＝１、２、３、・・・、Ｎ）がより厳しくなる。

他の選択肢は閾値のセットＮＲＴ＿Ｉ（Ｉ＝１、２、３、・・・、Ｎ）及びＲＴ＿Ｉ（Ｉ＝１、２、３、・・・、Ｎ）の両方を高く設定することであり、この場合、データトラフィックレートへの変更は少ないが、輻輳を緩和するために負荷分散及びセッション解放の使用が多くなる。

＜第２の例：３ＧＵＭＴＳネットワークにおけるアプリケーション＞
ここまでの詳細な説明は、一般に、多くのタイプの通信ネットワーク内のノード間での多くのタイプのリンクに対してのものである。例えば、ユニバーサル移動体通信システム（ＵＭＴＳ）ネットワーク、ＣＤＭＡ無線ネットワーク、第３世代パートナーシップ３ＧＰＰのロングタームエボリューションＬＴＥネットワークのような４Ｇ移動体ネットワーク、及び共有ＩＰトランスポートチャネルを用いるネットワークである。

ここで上記のアプローチがどのようにして例示の第３世代パートナーシッププロジェクト３ＧＰＰ、ユニバーサル移動体通信システムＵＭＴＳネットワークにおいて実施されるかを説明する。

以下の例では、その負荷が問題となるリンクはいわゆるＩｕｂインターフェイスであり、その帯域幅マネージャが位置する基地局コントローラは無線ネットワークコントローラＲＮＣである。

＜ＵＭＴＳネットワーク＞
図３に示すように、この第２の例では、ネットワークはユニバーサル移動体通信システム（ＵＭＴＳ）地上アクセスネットワーク（ＵＴＲＡＮ）であり、移動体通信のための広帯域符号分割多重アクセス（ＣＤＭＡ）のタイプである。ＵＴＲＡＮネットワークは基本的には図３に示すようなものである。説明の簡明化のためにＵＴＲＡＮネットワーク２´の１個の無線ネットワークコントローラ４´及び２個の基地局８´を示す。同図において、ＵＴＲＡＮネットワーク２´は基地局８´を含む。図において、ＵＭＴＳ用語に従うと基地局８´の各々は「ノードＢ」とも言われる。セクタとも言われるセルは、基地局の対応アンテナによってサービングされる無線カバレッジエリアである。各基地局は通常は３個のセル３を有し、その各々は３個の指向性アンテナ５の１つに互いに１２０度の角度の方位でカバーされる。各無線ネットワークコントローラ（ＲＮＣ）４´は通常は幾つかの基地局８´を、それゆえ多数のセル３を制御する。基地局８´はその制御している無線ネットワークコントローラ（ＲＣＮ）４´を、Ｉｕｂインターフェイスとして知られるそれぞれのインターフェイス６´を介して接続される。この使用において、移動体ユーザ端末７（ＵＭＴＳ用語ではユーザ機器（ＵＥ）と言われることもある）は少なくとも１つの基地局８´の少なくとも１つのセル３を介してサービング無線ネットワークコントローラ（ＲＮＣ）４´と通信する。このように移動体ユーザ端末はＵＴＲＡＮネットワーク２と通信する。

各無線ネットワークコントローラＲＮＣ４´は帯域幅マネージャ１０´を含む。ＵＭＴＳネットワーク２´では幾つかのＲＴサービスのレート低減、例えば、適応的マルチレート（ＡＭＲ）音声レート適合、ストリーミングベアラのダウングレーディング等が可能である。また、負荷分散に関しては、ＵＭＴＳネットワークからＧＳＭネットワーク等の第２世代ネットワークへの負荷軽減が可能なこともあり、特に、ＵＭＴＳネットワークにおける高いデータセッションを維持しつつ音声ユーザセッション及びより低いレートのデータユーザセッションを負荷軽減する。ＵＭＴＳネットワークにおいても、異なるユーザが、ＱｏＳクラスによって定義される異なるＱｏＳを保障されることが知られている。

発明者は、つまり、より低いＱｏＳクラスを持つ音声ユーザが、高いＱｏＳクラスを持つデータユーザよりも高い優先度を必ずしも与えられるべきではないことを認識した。

ＵＭＴＳネットワークでは、Ｉｕｂインターフェイス６´が、音声、映像及びデータを含む複数のタイプのサービスを搬送する。Ｉｕｂインターフェイス６´上の帯域幅は制限されているが、データサービスはバースト性なこともあるので、Ｉｕｂインターフェイス６´はしばしば計画的に募集以上に申し込まれる。これは統計的な多重化として知られている。これは、ある瞬間に全てのユーザが彼らの許容データレートの最大を使用している状態は非常に起こり難いので受け入れられる。Ｉｕｂインターフェイスの輻輳制御の目的は、Ｉｕｂインターフェイスの使用の高いレベルを維持しつつ要求されたＱｏＳを適切に満足することである。

図４は概略として上記図１及び２に関連して記載される輻輳制御方法の例を示すが、異なる値の異なる表を有し、ここでは図３に示すＵＭＴＳネットワークに適用される。図４に、ＲＮＴトラフィック制御その後ＲＴトラフィック制御、それに続く負荷分散その後のユーザセッション解放の３サイクルを示す。

ＵＭＴＳシステムでは２つの非リアルタイム（ＮＲＴ）タイプのトラフィックがある。これらはインタラクティブクラス及びバックグランドクラスである。ＮＲＴユーザセッションに関連する種々のレベルのＱｏＳがある。具体的には、インタラクティブクラスのトラフィックに対して３つの基本的なレベルのＱｏＳ優先度、即ち、インタラクティブ１（最高優先度）、インタラクティブ２（中間優先度）、及びインタラクティブ３（最低優先度）がある。

リアルタイム（ＲＴ）トラフィックのクラスにはストリーミングクラス及び会話クラスがある。ストリーミングクラスにおけるトラフィックはストリーミングビデオ及びストリーミングオーディオアプリケーション用等のＲＴマルチメディアトラフィックを含む。回路交換音声ＣＳＶトラフィックは会話クラスに入る。

表２に示すように、最大許容レートの３個のセットがトラフィッククラス優先度に基づいて用いられる。表２においてＮ／Ａは適用不可を示す。

表２：ＵＭＴＳネットワークにおける輻輳制御のための閾値例

表２における閾値は、以下のように、値は異なるが表１における閾値に対応する。
ＮＲＴ＿１はＩ／Ｂ＿１に対応し、
ＲＴ＿１はＳｔｒ＿ｍｉｎ（ストリーミング用の最小レート）に対応し、
ＮＲＴ＿２はＩ／Ｂ＿２に対応し、
ＲＴ＿２はＣＳＶ＿ｍｉｄ（ＣＳＶフロー用の中間レート）に対応し、
ＮＲＴ＿３はＩ／Ｂ＿ｍｉｎ（Ｉ／Ｂフロー用の最小レート）に対応し、
ＲＴ＿３はＣＳＶ＿ｍｉｎ（ＣＳＶフロー用の最小レート）に対応する。

帯域幅マネージャ１０´はＩｕｂインターフェイス上のトラフィック負荷をモニタする。Ｉｕｂ負荷がＴｈ＿ＴＣを超えると、トラフィック軽減手順が、必要に応じて表２の閾値を段階毎に適用して実行される。

帯域幅マネージャ１０´はＩｕｂ負荷レベルを判定する（ステップａ´）。この判定は、例えば２０ミリ秒毎のような設定間隔で、あるいは連続的に行われる。Ｉｕｂ負荷が輻輳制御閾値Ｔｈ＿ＴＣ以下か否かについてチェックが行われる（ステップｂ´）。Ｉｕｂ負荷がＴｈ＿ＴＣ以下である間は、全てのユーザセッションが関連のタイプのセッションについての最大許容レート（ベースレート）まで使用できる。

Ｉｕｂ負荷がＴｈ＿ＴＣ以下である間は、全てのユーザセッションが関連のタイプのセッションについての最大許容レート（ベースレート）まで使用できる。

Ｉｕｂ負荷がＴｈ＿ＴＣを超える場合には、トラフィック軽減の第１のステップ（ステップｃ´）が適用される。即ち、表１に示すように帯域幅閾値Ｉ／Ｂ＿１の新たなセット、即ち、表２に示すインタラクティブクラス及びバックグランドクラスがＮＲＴトラフィックに適用される。具体的には、インタラクティブ１又はインタラクティブ２のクラスのユーザのセッションに対する最大許容レートは３８４ｋｐｂｓに維持される一方、インタラクティブ３のクラスのユーザのセッションに対する最大許容レートは２５６ｋｂｐｓに低減され、バックグランドクラスのユーザのセッションに対する最大許容レートは１２８ｋｂｐｓに低減される。

Ｉ／Ｂ＿１制限が適用されたら、Ｉｕｂ負荷がＴｈ＿ＴＣより小さいかについてのチェックがなされる（ステップｄ´）。Ｉｕｂ負荷が未だにＴｈ＿ＴＣを超えている場合、更なるトラフィック軽減が、今度はＲＴトラフィックに適用される。具体的には、帯域幅閾値Ｓｔｒ＿ｍｉｎが、表２に示すストリーミングクラスのＲＴトラフィックに適用される。ＲＴストリーミングクラスのユーザのセッションに対する最大許容レートは６４ｋｂｐｓに低減される。ＣＳＶクラスのＲＴユーザのセッションに対する最大許容レートは変更されない。

この態様では、輻輳制御サイクルにおいて、ＮＲＴトラフィックが最初に制限され、その後ＮＲＴトラフィックの制限がＩｕｂ負荷を必要な閾値Ｔｈ＿ＴＣ以下にするのに十分でなかった場合にＲＴトラフィックの制限が続く。

ＮＲＴトラフィックに対する制限は、実際には、ユーザ端末又はＲＮＣのようなソースがＩｕｂインターフェイスを介して送信できるプロトコルデータユニットＰＤＵの数をシグナリングすることによって行われる。ＲＴトラフィックへの制限は実際にはＵＭＴＳベアラ再構成手順によって行われる。

このトラフィック制御の最初のサイクルの後に、Ｉｕｂ負荷が未だにＴｈ＿ＴＣを超えているかのチェックが行われる（ステップｆ´）。超えていれば、更なるトラフィック制御、即ち、更なるセットの閾値Ｉ／Ｂ＿２をＮＲＴトラフィックに適用することによって、ＮＲＴトラフィック軽減の第２のステップ（ステップｇ´）が行われる。具体的には、図４に示すように、インタラクティブ１クラスのユーザのセッションに対する最大許容レートが２５６ｋｂｐｓに低減され、インタラクティブ２クラスのユーザのセッションに対する最大許容レートが１２８ｋｂｐｓに低減され、インタラクティブ３クラスのユーザのセッションに対する最大許容レートが６４ｋｂｐｓに低減され、バックグランドクラスのユーザのセッションに対する最大許容レートが３２ｋｂｐｓに低減される。

再度、Ｉｕｂ負荷＞Ｔｈ＿ＴＣかのチェックが行われ（ステップｈ´）、そうであれば、更なる制限をＲＴトラフィックに適用することによってＲＴトラフィック軽減の第２のステップ（ステップｉ´）が行われる。具体的には、表２に示すように帯域幅閾値ＣＳＶ＿ｍｉｄがＣＳＶクラスのＲＴトラフィックに適用される。ＲＴのＣＳＶクラスのユーザのセッションに対する当初１２.２ｋｂｐｓの最大許容レートは７.９５ｋｂｐｓに低減される。これは、適応性マルチレートＡＭＲとして知られるＣＳＶユーザコーデックレートを低減するためのＵＭＴＳベアラ再構成手順を用いて実行される。ストリーミングクラスのＲＴユーザのセッションに対する最大許容レートは変更されない。これによって第２のＮＲＴその後のＲＴトラフィック制限の第２のサイクルが行われた。

図４に示すように、Ｉｕｂ負荷＞Ｔｈ＿ＴＣかについての更なるチェックが行われる（ステップｎ´）。そうであれば、更なるセットの閾値Ｉ／Ｂ＿ｍｉｎをＮＲＴトラフィックに適用することによって、ＮＲＴトラフィック軽減の第３のサイクルに突入する（ステップｏ´）。具体的には、図４に示すように、インタラクティブ１クラスのユーザのセッションに対する最大許容レートが１２８ｋｂｐｓに低減され、インタラクティブ２クラスのユーザのセッションに対する最大許容レートが６４ｋｂｐｓに低減され、インタラクティブ３クラスのユーザのセッションに対する最大許容レートが３２ｋｂｐｓに低減され、バックグランドクラスのユーザのセッションに対する最大許容レートが８ｋｂｐｓに低減される。

再度、Ｉｕｂ負荷＞Ｔｈ＿ＴＣかのチェックが行われ（ステップｐ´）、そうであれば、更なる制限をＲＴトラフィックに適用することによってＲＴトラフィック軽減の第３のステップ（ステップｑ´）が行われる。具体的には、表２に示すように帯域幅閾値ＣＳＶ＿ｍｉｎがＣＳＶクラスのＲＴトラフィックに適用される。ＲＴのＣＳＶクラスのユーザのセッションに対する最大許容レートは４.７５ｋｂｐｓに低減される。これは、ＣＳＶユーザコーデックレートを低減するためのＵＭＴＳベアラ再構成手順を用いて実行される。ストリーミングクラスのＲＴユーザのセッションに対する最大許容レートは変更されない。

このような最大許容レートにおける全ての低減の後に、Ｉｕｂ負荷が未だにＴｈ＿ＴＣを超えているかのチェックがなされる（ステップｒ´）。超えている場合、Ｉｕｂ負荷を低減するための更なるアプローチが必要となる。まず、ＮＲＴトラフィックの負荷分散が可能か、特に、インタラクティブ又はバックグランドクラスのユーザセッションがあるか、及び単一の無線アクセスベアラを使用しているかのチェックが、これらは負荷分散に適しているので、行われる（ステップｓ´）。肯定される場合、これらのＮＲＴユーザセッションの幾つかが、フォワードアクセスチャネル「ＦＡＣＨ」として知られる共有チャネル又は２Ｇ（一般パケット無線システム「ＧＰＲＳ」）ネットワークのいずれかに転送される（ステップｔ´）。

ＮＲＴ負荷分散が可能でない場合、それでも負荷分散ＲＴトラフィックが可能かもしれないのでそれに関してチェックが行われる（ステップｕ´）。可能な場合、幾つかのリアルタイムＣＳＶユーザセッションが２Ｇ（一般パケット無線システム「ＧＰＲＳ」）ネットワークに転送される（ステップｖ´）。

図４に示すように、負荷分散が可能でない場合には、最後の手段として幾つかのユーザセッションが終了される（ステップｗ´）。

輻輳制御プロセスにおけるあらゆる段階で、例えばユーザ数の減少に起因してトラフィックレベルが低下すると、帯域幅マネージャ１０´はＩｕｂ負荷がＴｈ＿２よりも小さいかの評価を行う。なお、Ｔｈ＿２はＴｈ＿ＴＣよりも小さい。そうであれば、帯域幅マネージャ１０´はそれに従って帯域幅閾値を緩和し、即ち、最大許容レートを表２に従って適切なステップ又は一連のステップで減少させる。例えば、ＣＳＶ＿ｍｉｎからＣＳＶ＿ｍｉｄへの各緩和の後に、Ｉｕｂ負荷がＴｈ＿２よりも小さいかの評価が行われる。小さい場合、例えばＩ／Ｂ＿ｍｉｎからＩ／Ｂ＿２への更なる緩和が行われる。

この態様において、基本的には、輻輳制御は負荷レベルが高過ぎるときのみ提供される。

＜他の実施例＞
ＵＭＴＳには、相対的なユーザセッション優先度を示すものとして知られるパラメータＡＲＰがある。上記のＵＭＴＳ例では、ユーザは同じ割当て維持方針ＡＲＰを持つように扱われるので、ＡＲＰに基づく格差は出ない。

他の複雑なＵＭＴＳの例では、異なるユーザセッションが異なる関連ＡＲＰ値を持つことが考慮されるので、異なるＱｏＳ優先度グループの数が増加し、輻輳制御が種々のグループに異なった態様で適用される。これは、表２がユーザをさらに区分けするように、より多くの列を含むように改変するものとみなされる。より複雑な本例では、負荷分散が可能でない場合には、最後の手段として幾つかのユーザセッションが最低ＡＲＰのユーザのユーザセッションから終了される。

他のＵＭＴＳの例では、オペレータは、例えば、ＲＴトラフィックの優位、又はＮＲＴトラフィックの優位のいずれかにおいて制限を変更するために表２の閾値を変更することができる。

＜一般事項＞
本発明はその本質的な特徴から離れることなく他の特定の形式で具現化され得る。記載した実施例は全ての点において例示としてのみであって制限的ではないものとして考慮されるべきである。従って、発明の範囲は前述の記載によってではなく添付された特許請求の範囲によって示される。各請求項の均等となる意味及び範囲内に入る全ての変更は各請求項の範囲内に包含されるものである。

Claims (10)

1. 通信ネットワークにおけるリンク上のトラフィック負荷を制御する方法において、該リンクが非リアルタイム（ＮＲＴ）サービスのユーザセッション及びリアルタイム（ＲＴ）サービスのユーザセッションを搬送するものであり、
   該方法が、
   周期的に前記リンクのトラフィック負荷をモニタするステップ、及び
   前記負荷が所定のレベル以下になるように、前記リンク上のＮＲＴトラフィックとＲＴトラフィックを連続して交互に制限するステップ
   からなる方法。
2. 請求項１の方法において、
   前記負荷が前記所定のレベルを超えるものと判断されると、ＮＲＴトラフィック及びＲＴトラフィックの一方の少なくとも１つのＱｏＳクラスを制限するステップ、及び
   続いて、前記負荷が前記所定のレベルを超えるものと判断されると、ＮＲＴトラフィック及びＲＴトラフィックの他方の少なくとも１つのＱｏＳクラスを制限するステップ
   を備え、ＲＴトラフィック及びＮＲＴトラフィックの一方に関する前記制限するステップに続く次の制限するステップがＲＴトラフィック及びＮＲＴトラフィックの他方に関するものである方法。
3. 請求項２の方法において、前記制限するステップが、選択された単一又は複数のＱｏＳクラスのユーザセッションの最大許容レートを低減することによって行われる方法。
4. 請求項３の方法において、ＮＲＴトラフィック及びＲＴトラフィックの前記選択された単一又は複数のＱｏＳクラスの最大許容レートにおける適用される低減の大きさが、ＮＲＴトラフィックがＲＴトラフィックに比べて制限されるべき程度に依存して予め選択される方法。
5. 請求項２の方法において、
   前記負荷が低い側の所定レベル以下となると、ＮＲＴトラフィック及びＮＲトラフィックの一方の少なくとも１つのＱｏＳクラスのトラフィックの制限を緩和するステップ、及び
   続いて、前記負荷が前記低い側の所定レベル以下となると、ＮＲＴトラフィック及びＲＴトラフィックの他方の少なくとも１つのＱｏＳクラスのトラフィックの制限を緩和するステップ
   を備え、ＲＴトラフィック及びＮＲＴトラフィックの一方に関する前記緩和するステップに続く次の緩和するステップがＲＴトラフィック及びＮＲＴトラフィックの他方に関するものである方法。
6. 請求項５の方法において、前記緩和するステップが、選択された単一又は複数のＱｏＳクラスのユーザセッションの最大許容レートを上昇することによって行われる方法。
7. 非リアルタイム（ＮＲＴ）サービス及びリアルタイム（ＲＴ）サービスのユーザセッションを搬送する通信ネットワークであって、
   該ネットワークが、基地局コントローラにリンクされた少なくとも１つの基地局を備え、
   該ネットワークが該リンク上のトラフィック負荷の制御部及び表示部を備え、
   該制御部が、前記負荷が所定のレベル以下になるように前記リンク上のＮＲＴトラフィックとＲＴトラフィックを連続して交互に制限するように動作するネットワーク。
8. 請求項７のネットワークにおいて、
   前記制御部が、
   前記負荷が前記所定のレベルを超えると判断されると、ＮＲＴトラフィック及びＲＴトラフィックの一方の少なくとも１つのＱｏＳが制限され、
   続いて、前記負荷が前記所定のレベルを超えると判断されると、ＮＲＴトラフィック及びＲＴトラフィックの他方の少なくとも１つのＱｏＳが制限されるように動作し、
   ＲＴトラフィック及びＮＲＴトラフィックの一方に関する前記制限に続く次の制限がＲＴトラフィック及びＮＲＴトラフィックの他方に関するものであるネットワーク。
9. 請求項８のネットワークにおいて、前記制御部が、選択された単一又は複数のＱｏＳクラスのユーザセッションの最大許容レートを低減することによって制限するように動作するネットワーク。
10. 請求項９のネットワークにおいて、前記基地局コントローラが、トラフィック制限の所定の段階で所定のトラフィックタイプに適用されるべき低減された最大許容レートを記憶するように動作するメモリを備えたネットワーク。

Images