JP2014140231A - 電気通信ネットワークにおける輻輳制御 - Google Patents

Abstract

【課題】電気通信ネットワークにおける輻輳制御方法を提供する。
【解決手段】第１通信端末および第２通信端末に、第１ベアラおよび第２ベアラをそれぞれ設け、更に、共通グループ識別子が格納されるまたは格納されているグループに割り当てられる。第１通信端末および第２通信端末の第１ベアラに対する第１個別輻輳パラメータと、第２ベアラに対する第２個別輻輳パラメータとが、格納されるか、または格納されている。共通グループ識別子に対応する端末のグループに対して、グループ負荷指標が定められる。このグループ負荷指標を監視し、共通グループ識別子に対応する少なくとも第１通信端末および第２通信端末のグループのグループ負荷条件と比較する。グループ負荷指標がグループ負荷条件を満たすとき、第１ベアラの第１個別輻輳パラメータおよび第２ベアラの第２個別輻輳パラメータの内少なくとも１つを調整することによって、輻輳を制御する。
【選択図】図７Ａ

Description

一般的には、本発明は、ネットワークにおける輻輳を制御するように構成された方法および電気通信ネットワークに関するものである。更に具体的には、本発明は、マシン・ツー・マシン通信(machine-to-machine communications)に用いられるネットワークにおける輻輳制御に関するものである。

従来技術

ワイヤレス・アクセスを提供する電気通信ネットワーク（例えば、ＧＳＭ、ＵＭＴＳ、ＷｉＭＡＸ、ＬＴＥ）は、過去数年にわたって飛躍的に発展した。このようなネットワークでは、音声およびデータ・サービスを、高い移動性を有する端末に提供することができる。即ち、通信端末は、特定の位置に拘束されず、ネットワークによってカバーされるエリア中を自由に移動可能である。電気通信ネットワークのゲートウェイ・ノードが、更に別のネットワーク、例えば、インターネットのようなＩＰベースのネットワークへの接続を可能にする。

このような更に別のネットワークに接続された電気通信ネットワークが利用可能になった結果、いわゆるマシン・ツー・マシン（Ｍ２Ｍ）サービス(machine-to-machine service)に関係するサービスを含む、より多くのサービスが求められることになった。Ｍ２Ｍの用途では、通例、数百、数千、または数百万もの通信モジュールが関与し、その各々が電気通信ネットワークに対して通信端末として動作する。一例では、別のネットワークに接続されているサーバから電気通信ネットワークを通じて、大きな顧客基盤の過程における、例えば、「スマート」電気メータを電子的に読み取ることを伴う。他の例では、センサ、メータ、自動販売機、コーヒー・マシン等が含まれ、これらには通信モジュールを装備することができ、電気通信ネットワークを通じてステータス情報をデータ処理センタに報告することが可能になる。また、このようなデバイスをサーバによって監視することもできる。データ処理センタは、例えば、機械、メータ、センサ等を修理するまたは補充するために、データを格納すること、および／または保守要員のために予定を組むこともできる。

Ｍ２Ｍ用途の一部には、サーバとのデータ交換が頻繁でない、例えば、スマート電気メータでは毎日１回程度であるという特徴がある。

通例、電気通信ネットワークの運用者とサーバまたはデータ処理センタの所有者／運用者との間には、電気通信端末の各々のベアラ(bearer)に適用可能な通信パラメータについて同意が存在する。一例として、このような通信パラメータは、例えば、ＱｏＳクラスに関係し、更に特定の通信端末とサーバまたはデータ処理センタとの間におけるデータ・セッションをサポートするために用いられる電気通信ネットワークにおいてベアラに許される最大ビット・レートに関係する。一例として、ＧＰＲＳまたはＵＭＴＳ電気通信ネットワークでは、これらの通信パラメータは、通信端末についてのＰＤＰコンテキストに含まれる。他のネットワーク、例えば、ＬＴＥネットワークまたはケーブル・ネットワークでは、通信パラメータは同様のコンテキストにおいて与えられる。

通信パラメータは、ポリシー制御および課金制御（ＰＣＣ：policy and charging control）のアーキテクチャを用いて制御できることは、一般に知られている。このようなＰＣＣアーキテクチャの一例が、３ＧＰＰ ＴＳ ２３．２０３に記載されている。ポリシー制御は、通信ネットワークにおいて周知のプロセスであり、これによって、ポリシー制御エンティティがポリシー施行エンティティに、例えば、ＩＰコネクティビティ・アクセス・ネットワーク（ＩＰ−ＣＡＮ）ベアラのベアラ・リソースを、例えば、どのように制御するのかを示す。このようなＩＰ−ＣＡＮベアラは、ＧＰＲＳまたはＵＭＴＳ通信ネットワークにおけるベアラを含み、ＬＴＥ通信ネットワークにおけるＥＰＳベアラを含み、ケーブル通信ネットワークにおいてＤＯＣＳＩＳサービス・フローを含む等とすることができる。ポリシー制御は、電気通信ネットワークにおいてＱｏＳ特性を制御するために用いることもできる。

通信端末の各々によって発生されるトラフィックが、ベアラに対して通信パラメータ（例えば、ＰＤＰコンテキスト）において指定されている、同意された制限(agreed limits)以内であっても、そしてこのような制限が厳格に施行されていても、端末が故意にまたは意図せずに制限を破ると、輻輳が発生する場合がある。例えば、多数の電気メータの各々が頻繁にサーバとデータを交換しなくても、同時にサーバとデータを交換しようとすると、電気通信ネットワークと別のネットワークにおけるサーバとの間における接続が過負荷になる虞れがあり、または電気通信ネットワークの他の部分で輻輳が発生する虞れもある。過負荷は、アップリンクおよびダウンリンクいずれかまたは双方の方向で発生する可能性がある。即ち、端末からサーバに送信されるデータ、またはサーバから通信端末に送信されるデータに、それぞれ発生する可能性がある。

現在、電気通信ネットワークの運用者は、このような過負荷を効率的に防止する手段を有しておらず、輻輳が発生したときにこれを制御するのに適した手段も有していない。

米国特許第６８６５１８５号は、ワイヤレス・ネットワークにおいてトラフィックをキューイングする方法およびシステムを開示する。この方法およびシステムは、ワイヤレス・ネットワークにおける送信のためのパケットのストリームを受信することを含む。各パケットは、フロー識別子を含み、このフロー識別子に基づいて、複数の仮想グループの内１つに割り当てられる。仮想グループは、離散送信リソースを含む。各パケットは、ワイヤレス・ネットワークにおける送信のために、割り当てられた仮想グループにおいてキューイングされる。

当技術分野では、一層柔軟性を高めた輻輳制御方法が求められていることは明らかである。

電気通信ネットワークにおける輻輳制御方法を開示する。この電気通信ネットワークは、サーバと少なくとも第１通信端末および第２通信端末との間における１つ以上のアクティブなデータ・セッションを、これらの端末に少なくとも第１ベアラおよび第２ベアラをそれぞれ設けることによって、サポートする。

少なくとも第１通信端末および第２通信端末は、共通グループ識別子が格納されるまたは格納されているグループに割り当てられる。更に、第１通信端末および第２通信端末の第１ベアラに対する第１個別輻輳パラメータと、第２ベアラに対する第２個別輻輳パラメータとが、格納されるか、または格納されている。共通グループ識別子に対応する端末のグループに対して、グループ負荷指標が定められる。このグループ負荷指標を監視し、共通グループ識別子に対応する少なくとも第１通信端末および第２通信端末のグループのグループ負荷条件と比較する。前記グループ負荷指標がグループ負荷条件を満たすとき、第１ベアラの第１個別輻輳パラメータおよび第２ベアラの第２個別輻輳パラメータの内少なくとも１つを調整することによって、輻輳を制御する。

この方法は、電気通信ネットワークの１つ以上の（ゲートウェイ）ノード（１つまたは複数）において用いることができる。

この方法を実行するためのコンピュータ・プログラム、およびこのようなコンピュータ・プログラムを収容する担体も開示する。このプログラムの一部は、電気通信ネットワークを通じて分散し、分散機能を実行することもできる。

更に、少なくとも第１ベアラおよび第２ベアラをそれぞれ設けることによって、サーバと少なくとも第１通信端末および第２通信端末との間におけるデータ・セッションを可能にするように構成されている電気通信ネットワークも開示する。この電気通信ネットワークの第１記憶ノードは、少なくとも第１通信端末および第２通信端末を含むグループに割り当てられた共通グループ識別子を格納する。第２記憶ノードは、第１記憶ノードと同一のノードとすることもでき、前記第１通信端末および第２通信端末の第１ベアラに対する第１個別輻輳パラメータと、第２ベアラに対する第２個別輻輳パラメータとをそれぞれ格納する。共通グループ識別子に対応する少なくとも第１通信端末および第２通信端末のグループに対するグループ負荷指標を、電気通信ネットワークにおいて監視するように構成されている監視モジュールが設けられている。また、グループ負荷識別子を、共通グループ識別子に対応する前記少なくとも第１通信端末および第２通信端末のグループについてのグループ負荷条件と比較するように構成されている分析部も設けられている。最後に、電気通信ネットワークは、前記グループ負荷指標がグループ負荷条件を満たすときに、第１ベアラの第１個別輻輳パラメータおよび第２ベアラの第２個別輻輳パラメータの少なくとも１つを調整することによって、電気通信ネットワークにおける輻輳制御を行うように構成されている輻輳制御部を備えている。

尚、開示する方法および電気通信ネットワークは、その電気通信ネットワーク自体に発生する輻輳、および／または当該電気通信ネットワークとサーバとの間に設けられる別のネットワーク（１つまたは複数）に発生する輻輳も制御することができることは認められてしかるべきである。

また、グループ負荷指標を監視する監視ステップ、および監視したグループ負荷指標をグループ負荷条件と比較する比較ステップは、必ずしも２つの個別の続いたステップではなく、例えば、１つのステップに統合してもよいことは認められてしかるべきである。

また、通常、通信端末は、当該通信端末とサーバとの間における１つ以上のデータ・セッションをサポートするために、電気通信ネットワークにおいて単一のベアラを用いる。そして、共通グループ識別子は、通信端末に関係付けることができ、通信端末は１対１でベアラに対応する。しかしながら、通信端末が１つよりも多いベアラを用いる場合、１つの通信端末を数個のグループに割り当てることができるように、ベアラ毎にグループ識別子を割り当てることもできる。

グループの端末のベアラの個別輻輳パラメータは、そのグループの個々の端末のコンテキスト（例えば、ＰＤＰコンテキスト）の輻輳関連通信パラメータである。このような輻輳パラメータの一例には、ベアラに対して同意された（最大）ビット・レートが含まれる。グループ負荷指標は、特定の時点において、またある時間間隔中に端末のグループに対して実際に測定された負荷に関する。一例として、グループ負荷インディエータは、端末によって使用された実際のビット・レートの尺度であり、このビット・レートは、電気通信ネットワークにおいて監視される。グループ負荷条件とは、満たされたときに、グループの端末の個々のベアラの輻輳パラメータの調整をトリガする条件である。一例として、グループ負荷条件は、グループに対するビット・レート閾値を含む。端末の実際のビット・レートを監視して、グループ・ビット・レート閾値を超えた場合、個々の端末の（少なくとも１つまたはその一部の）ベアラに対する同意された輻輳パラメータを調整する。次いで、調整した輻輳パラメータを実施 (enforce)し、輻輳を回避または低減する。

グループ負荷条件を満たすことを検出しても、必ずしも、実際の輻輳が起こったことを意味する訳ではない。輻輳状態が起こる前に、個別輻輳パラメータの調整がトリガされるように、グループ負荷条件を定めることもできる。一例として、より高い閾値によって輻輳を解決するのではなく、グループ負荷条件としてより低い閾値を選択することによって、輻輳を防止することができる。

輻輳を解決する動作は、個々の端末に対する個々の最大ビット・レートを下方向に調整する以外の動作を含むこともでき、これらの端末の内１つ以上のＱｏＳ属性を修正することが含まれる。代替案として、追加の容量を（一時的に）グループの端末に割り当てることができる。

開示する方法および電気通信ネットワークは、個々の通信端末に対する輻輳関連パラメータ（の値）を定めることに加えて、共通グループ識別子によって識別されるグループに属する通信端末に対して、グループ負荷条件を定めることを可能にする。端末のグループについてのグループ負荷指標を監視することによって、グループ負荷条件は、電気通信ネットワークの運用者が、グループ負荷指標をグループ負荷条件と比較することによって輻輳を予測することを可能にし、更に、グループの中にある端末の個別輻輳パラメータを調整する役割を果たし、更にこれらの調整を施行して、グループの端末によって生じる輻輳を回避または軽減することが可能になる。

一例として、電気通信ネットワークの運用者は、通信端末のグループに対してグループ・ビット・レート閾値を定めることができる。グループ・ビット・レートがこのグループ・ビット・レート閾値を超えた場合、電気通信ネットワークの運用者は、電気通信ネットワークにおける輻輳を軽減するために、個々の通信端末に対する同意ビット・レートを低下させることができる。

請求項２の実施形態では、電気通信ネットワークへのアクセスを要求する端末に対する輻輳制御を可能にする。電気通信ネットワークへのアクセスを要求する端末が、輻輳条件を満たすことを定められたグループに割り当てられている場合、未調整のパラメータ値を用いてネットワークへの新たな端末アクセスを付与することによって発生する可能性がある輻輳を回避または制限するために、端末によって確立されたベアラに対する個別輻輳パラメータの調整を受けることになる。

請求項３の実施形態では、最後のデータ交換時点に基づいて、個別輻輳パラメータの調整が適時に行われるという利点が得られる。

請求項４の実施形態では、特定の端末の個々の識別子に基づいて、この端末が属する共通グループ識別子の読み出しを可能にする。したがって、共通グループ識別子は、端末には知られないままとなっている。個々の端末の識別子の例には、ＩＭＳＩ、端末番号、申し込み番号(application number)等が含まれる。

請求項５の実施形態では、ビット・レートが輻輳制御にとって重要なパラメータであることを規定する。

請求項６の実施形態は、通信ネットワークを１つ以上のグループに割り当て、（一時的に）グループ内にある１つ以上の通信端末の個別輻輳パラメータを調整することを可能にすることによって、Ｍ２Ｍサーバの所有者／運用者にフレキシビリティを与える。サーバの所有者／運用者は、通信端末全体に対するグループ輻輳条件が満たされていない限り、グループ内にある１つ以上の個々の端末の輻輳パラメータ（の値）をフレキシブルに調整することができる。

請求項７の実施形態では、１つの通信端末を多数のグループに割り当てること、および異なる対応するグループ負荷条件をこれらのグループに適用することを可能にする。

請求項８の実施形態では、特定のグループについての個々の通信端末の輻輳閾値パラメータの漸次調整（例えば、段階的）を可能にする。

請求項９の実施形態において定められるように、端末に対する輻輳パラメータが調整されるまたは既に調整されている場合、例えば、アップリンク方向におけるデータ送信に対する最大ビット・レートを低下させるために、これらの端末にベアラ特性の調整について知らせること（例えば、シグナリング・メッセージを介して）は利点となるはずである。輻輳パラメータを調整しないグループの端末には、知らせる必要はない。

このような調整情報を相当多数の通信端末に伝達しなければならないとき、ネットワークにおいて相当なシグナリング・トラフィックが生ずる可能性がある。請求項１０および１３の実施形態では、共通グループ識別子を利用する。共通グループ識別子から、メッセージの宛先として意図されるグループの個々の通信端末を、電気通信インフラストラクチャにおける適した場所（下位）において導き出す(derive)ことができる。

請求項１１の実施形態では、更に、電気通信ネットワークにおけるシグナリング・トラフィックを低減し、共通グループ識別子を含む情報を、電気通信ネットワークの１つ以上の部分においてブロードキャストし、そのグループに属する通信端末によって受信することを規定する。この実施形態では、通信端末は、共通グループ識別子を所有するか、またはこれを知らされており、この情報を用いて、ブロードキャストから調整情報メッセージを読み出す。

以後、本発明の実施形態について更に詳しく説明する。しかしながら、これらの実施形態は、本発明の保護範囲を限定するように解釈してはいけないことは、認められてしかるべきである。

図１は、別のネットワークを通じて通信端末をサーバに接続する、先行技術の電気通信ネットワークの模式図である。 図２は、図１の電気通信ネットワークにおいて用いられる先行技術のポリシーおよび課金制御（ＰＣＣ）アーキテクチャの模式図である。 図３Ａは、本発明の一実施形態による個別加入レコードおよびグループ・レコードを示す。 図３Ｂは、本発明の一実施形態による個別加入レコードおよびグループ・レコードを示す。 図４は、本発明の一実施形態による電気通信ネットワークの模式図である。 図５Ａは、図３Ａのレコードと組み合わせて図４の電気通信ネットワークにおいて行われる輻輳制御方法において用いられる、本発明の一実施形態による個別ＰＣＣルールおよびグループ・ルールを示す。 図５Ｂは、図３Ｂのレコードと組み合わせて図４の電気通信ネットワークにおいて行われる輻輳制御方法において用いられる、本発明の一実施形態による個別ＰＣＣルールおよびグループ・ルールを示す。 図６Ａは、サーバによる電気通信ノードのプロビジョニングの実施形態を表す信号フロー・チャートを示す。 図６Ｂは、サーバによる電気通信ノードのプロビジョニングの実施形態を表す信号フロー・チャートを示す。 図７Ａは、ビット・レート使用をビット・レート使用限度と共に示す模式図を示す。 図７Ｂは、本発明の一実施形態による輻輳制御方法を表す信号フロー・チャートを示す。 図７Ｃは、ビット・レート使用をビット・レート使用限度と共に示す模式図を示す。 図８は、ＧＧＳＮ始動グループＰＤＰコンテキスト修正手順の一実施形態を示す信号フロー・チャートである。 図９は、セル・ブロードキャスト・センタを含む電気通信ネットワークの模式図を示す。 図１０は、セル・ブロードキャスト技術を用いるＧＧＳＮ始動グループＰＤＰコンテキスト修正手順の一実施形態を示す信号フロー・チャートである。

図１は、電気通信ネットワーク１の模式図を示す。電気通信ネットワーク１は、パケット・データ・ネットワーク４を通じたサーバ２と端末３との間におけるデータ・セッションを可能とし、この場合、端末の電気通信ネットワーク１へのアクセスはワイヤレスである。

図１の電気通信ネットワークでは、簡単のために、３系統の電気通信ネットワークの形成が模式的に一緒に図示されている。このアーキテクチャおよび全体像の更に詳しい説明は、３ＧＰＰ ＴＳ ２３．００２において見いだすことができる。この文書をここで引用したことにより、その内容全体が本願にも含まれるものとする。

図１の下側の分岐は、ＧＰＲＳまたはＵＭＴＳ電気通信ネットワークを表し、ゲートウェイＧＰＲＳサポート・ノード（ＧＧＳＮ）、サービングＧＰＲＳサポート・ノード（ＳＧＳＮ）、および無線アクセス・ネットワーク（ＲＡＮまたはＵＴＲＡＮ）を備えている。ＧＳＭ／ＥＤＧＥ無線アクセス・ネットワーク（ＧＥＲＡＮ）では、ＲＡＮは、複数の基地局送受信機（ＢＴＳ）に接続されている基地局コントローラ（ＢＳＣ）を備えているが、双方とも図示されていない。ＵＭＴＳ無線アクセス・ネットワーク（ＵＴＲＡＮ）では、ＲＡＮは、複数のノードＢに接続されている無線ネットワーク・コントローラ（ＲＮＣ）を備えているが、これらも図示されていない。ＧＧＳＮおよびＳＧＳＮは、通常では、端末３の加入情報を収容するホーム・ロケーション・レジスタ（ＨＬＲ）に接続されている。

図１における上側の分岐は、次世代電気通信ネットワークを表し、一般にはロング・ターム・エボリューション（ＬＴＥ：Long Term Evolution）またはエボルブド・パケット・システム（ＥＰＳ：Evolved Packet System）として示されている。このようなネットワークは、ＰＤＮゲートウェイ（Ｐ−ＧＷ）およびサービング・ゲートウェイ（Ｓ−ＧＷ）を備えている。ＥＰＳのＥ−ＵＴＲＡＮは、パケット・ネットワークを通じてＳ−ＧＷに接続されている端末３にワイヤレス・アクセスを提供する発展ノードＢ（ｅＮｏｄｅＢまたはｅＮＢ）を備えている。Ｓ−ＧＷは、シグナリングの目的のために、ホーム加入者サーバＨＳＳおよびモビリティ・マネジメント・エンティティＭＭＥに接続されている。ＨＳＳは、加入プロファイル・レポジトリＳＰＲを含む。

ＥＰＳネットワークの総合的なアーキテクチャについてのこれ以上の情報は、３ＧＰＰ ＴＳ ２３．４０１において見いだすことができる。

勿論、３ＧＧＰによって規定された以外のアーキテクチャ、例えば、ＷｉＭＡＸまたはケーブル・ネットワークも、本発明の文脈において用いることもできる。

添付した特許請求の範囲において定義されている発明は、このようなネットワークに通常適用可能であるが、以下ではＧＰＲＳ／ＵＭＴＳネットワークについて更に詳細な説明を行う。

このようなネットワークでは、ＳＧＳＮは通例電気通信ネットワーク１と端末３との間の接続を制御する。尚、電気通信ネットワーク１は一般に複数のＳＧＳＮを備えており、これらのＳＧＳＮの各々が通例数個のＢＳＣ／ＲＮＣに接続されており、数カ所の基地局／ノードＢを通じて端末３にパケット・サービスを提供することは認められてしかるべきであろう。

ＧＧＳＮは、パケット・データ・ネットワーク４、例えば、インターネット、法人ネットワーク、または他の運用者のネットワークに接続されている。一方、ＧＧＳＮは１つ以上のＳＧＳＮに接続されている。

ＧＧＳＮは、ネットワーク４を通じてサーバ２から端末３に宛てられたデータ・ユニットを受信し（ダウンリンク）、端末３からサーバ２にデータ・ユニットを送信する（アップリンク）ように構成されている。

Ｍ２Ｍ環境では、多数の端末３との通信に、１つのサーバ２が通常用いられる。個々の端末３は、ＩＰアドレス、ＩＭＳＩ、またはその他の端末識別子のような、個別識別子によって識別することができる。

図２は、３ＧＧＰ ＴＳ ２３．２０３から周知である、ポリシーおよび課金制御（ＰＣＣ）アーキテクチャを示す。３ＧＧＰ ＴＳ ２３．２０３をここで引用したことにより、その内容全体が本願にも含まれるものとする。このアーキテクチャは、ＧＰＲＳ、ＵＭＴＳ、ＬＴＥ、またはその他のタイプの電気通信ネットワーク１に含めることができる。

図２のＰＣＣアーキテクチャの中心的要素は、ポリシーおよび課金規則機能ＲＣＲＦである。ＰＣＲＦは、ＩＰコネクティビティ・アクセス・ネットワーク（ＩＰ−ＣＡＮ）におけるサービス品質（ＱｏＳ）およびサービス・データ・セッションの課金の扱いに関するポリシー決定を行う。ＩＰ−ＣＡＮは、ＩＰ−ＣＡＮベアラをサポートすることができるネットワークであり、このネットワーク上でデータ・セッションを規定することができる。ＩＰ−ＣＡＮベアラは、例えば、容量、遅延、ビット・エラー・レートによって規定されるＩＰ送信経路である。

ＰＣＲＦは、その決定において、Ｓｐインターフェースを通じてＳＰＲから受信した加入情報、およびＩＰ−ＣＡＮの能力についての情報を考慮に入れる。ＰＣＲＦは、そのポリシー決定を、いわゆるＰＣＣルールにおいて定式化する。ＰＣＣルールとは、サービス・データ・フローの検出を可能にし、ポリシー制御および／または課金制御のためにパラメータを供給する情報セットである。このようなＰＣＣルールは、とりわけ、サービス・データ・フロー（例えば、５タプル・ソース／宛先ＩＰアドレス、ソース／宛先ポート番号、プロトコル）を検出するための情報、ならびにこのサービス・データ・フローに対して要求されるＱｏＳおよび課金の取り扱いに関する情報を収容する。また、これは、アップリンクおよびダウンリンク毎に別々に、サービス・データ・フローに対して許可されている最大ビット・レートも含む。ＰＣＣルールは、予め規定されていてもよく、または確定時に動的にプロビジョニングされてもよく、更にはＩＰ−ＣＡＮセッションの期間中に規定し直すこともできる。

ＰＣＲＦは、その決定をいわゆるＰＣＣルールとして定式化し、この定式化したＰＣＣルールをＧｘインターフェースを通じて、ポリシーおよび課金施行機能（ＰＣＥＦ）に向けて伝達する。更に、ＰＣＲＦは、ネットワーク・イベントの発生が通知されることを望むＰＣＥＦには、このネットワーク・イベントについて知らせる。

ＰＣＥＦは、サービス・フロー検出、ポリシー施行、およびフローに基づく課金の機能を包括的に含む。これらの機能は、ＰＣＣルールにしたがって実行され、ＰＣＣルールは、ＰＣＲＦから受けとられる（動的ＰＣＣルール）か、またはＰＣＥＦ自体において予め規定されている（既定ＰＣＣルール）。更に、ＰＣＥＦは、Ｇｘインターフェースを通じて、ＰＣＲＦへの通知を必要とするネットワーク・イベントについてＰＣＲＦに知らせる。ＰＣＥＦは、ゲートウェイ・ノード（例えば、図１におけるＧＧＳＮまたはＰ−ＧＷ）に配置されており、ＩＰ−ＣＡＮを外部パケット・データ・ネットワーク４に接続する。ネットワーク４は、サーバ２に接続されており、電気通信ネットワーク１のゲートウェイとサーバ２との間における通信をサポートするのであれば、いずれのネットワークまたはネットワークの組み合わせでも可能であり、例えば、専用線（ゲートウェイをサーバ２に接続する銅線または光ファイバ・ケーブル）、バックボーンＩＰネットワーク等がある。

ＳＰＲは、ＩＭＳＩのような個々の加入者識別子に基づいて個々の通信端末３について加入者に基づくポリシー決定をＰＣＲＦによって行う際に必要となる全ての加入情報を収容する。加入情報は、Ｓｐインターフェースを通じてＰＣＲＦによって要求される。また、ＳＰＲは、加入情報が変化したときにも、ＰＣＲＦに通知することができる。ＳＰＲは、必ずしもネットワークにおいて加入情報の重複を生ずることにはならない。例えば、ＳＰＲはＨＳＳまたはＨＬＲを収容することができる。

図１に示したように、端末３のグループＧは、電気通信ネットワークおよびパケット・ネットワーク４を通じてサーバ２とのデータ・セッションを有するために、電気通信ネットワーク１に接続することができる、または接続可能にすることができる。このような端末３のグループを特定するために、本発明の一態様では、ＨＬＲおよび／またはＳＰＲは、個々の端末３についての前述した加入情報を収容する個別加入レコードに加えて、グループ・レコードに関する共通グループ識別子を格納することができる。

図３Ａおよび図３Ｂは、個別加入レコードおよびグループ・レコードを示す。個別加入レコードは、端末３毎に加入情報を個別に収容する。個別加入レコードは、例えば、個別加入識別子、個別ＱｏＳおよび課金ポリシー、アップリンクおよびダウンリンク方向に対する保証ビット・レート、その他の輻輳制御関連情報、および／またはその他の加入情報を収容する。個別ＱｏＳおよび課金ポリシーは、アップリンクおよびダウンリンク方向に対する最大ビット・レート（アップリンクおよびダウンリンクで異なる可能性がある）、アップリンクおよびダウンリンク毎に保証されているビット・レートを含むことができる。

グループ・レコードは、例えば、グループ識別子、グループ負荷状態のようなグループ全体に関する情報、輻輳パラメータ調整ポリシー、およびこのグループに属する通信端末またはベアラの識別子のリストを収容する。グループＧに入っている通信端末３についての個別加入レコード、およびグループ・レコードは、グループ識別子および個別加入識別子によってリンクされている。即ち、グループＧについてのグループ・レコードは、共通グループ識別子と、グループＧに属する通信端末３またはベアラの識別子リストとを有する。また、グループＧに入っている通信端末についての個別加入レコードは、端末３に割り当てられているグループＧのグループ識別子も収容することができる。個別加入レコードにグループ識別子を含めることは、通信端末が、これらに割り当てられているグループＧについての情報を必要とする場合に、有利となることがある。その一例を以下に示す。その例では、共通グループ識別子がブロードキャスト信号に含まれる。通信端末３に割り当てられているグループに関する情報を必要とする通信端末３は、次に、そのグループに関連があるブルオードキャスト信号からその情報を読み出す（選択する）ことができる。

尚、１つの通信端末３を１つよりも多いグループに割り当てることができることは、認められてしかるべきであろう。

グループの情報には、特定の要件はない。グループは、例えば（特に）、それらのグループのメンバが、重複していても、離れていてもよい。また、階層構造を用いることもでき、その場合、グループＧの中に、サブグループが作られる（例えば、特定のＳＧＳＮ／Ｓ−ＧＷからサービスを受ける全ての端末）。また、全ての端末が１つのグループに含まれる必要もない。輻輳制御のコンテキストでは、グループの形成は、輻輳が起こることが予想され得る場合の評価によって左右されると思われる。

通信端末３のグループにグループ・レコードを設けることによって、電気通信ネットワーク１において種々の新たな独創的な方法が可能になる。その例には、通信端末３のグループに対する効率的なメッセージ送信、通信端末３のグループに対するアクセス制御、および輻輳制御に関するフレキシビリティが含まれる。

これより、これらの例の組み合わせについて更に詳しく説明する。

図４は、以下で更に詳しく説明するように、図２のＰＣＣアーキテクチャに関して修正されたＰＣＣ^＊アーキテクチャを備えている電気通信ネットワーク１を示す。グループＧに属する第１通信端末および第２通信端末３Ａ、３Ｂが、サーバ２と通信する（例えば、家庭における小規模電気計測のために、サーバ２に計測データを供給する）。

ＩＰ−ＣＡＮベアラＡ１およびＢ１（この場合、ＰＤＰコンテキストによって規定されている）が、端末３Ａ、３Ｂと電気通信ネットワークのゲートウェイ（ここでは、ＧＧＳＮ）との間に確立される。このようなＩＰ−ＣＡＮベアラを通じて伝達されるデータは、ＩＰ−ＣＡＮベアラに関連付けられるＱｏＳ処置を受ける。端末３Ａ、３Ｂとサーバ２との間におけるデータ・セッションＡ２、Ｂ２は、電気通信ネットワークにおいてＩＰ−ＣＡＮベアラＡ１、Ｂ１によってサポートされ、更にネットワーク４を通じてサポートされる。

ベアラＡ１およびＢ１がしかるべきＱｏＳ特性を確実に得るために、ベアラ確立のときに、ＰＣＥＦ^＊がインターフェースＧｘ^＊を通じてＰＣＲＦ^＊を参照する(consult)。一方、ＰＣＲＦ^＊は、インターフェースＳｐ＊を通じて、関連のある加入情報についてＳＰＲ^＊を参照する。ＰＣＲＦ^＊は、ポリシー決定を下し、インターエースＧｘ^＊を通じてＰＣＥＦ^＊に知らせる。ＰＣＥＦ^＊は、これらの決定を施行する。

前述のように、本発明の一態様による端末３Ａ、３Ｂについてのグループ情報は、電気通信ネットワーク１による一層効率的な輻輳制御のために、有利に用いることができる。

本発明の一態様では、プロビジョニング・インターフェースＰｘおよび／またはＰｙを規定することによって、サーバ２とＳＰＲ^＊および／またはＰＣＲＦ^＊との間における通信が可能となる。これについては、図６Ａおよび図６Ｂを参照して以下で更に説明する。

図３Ｂに示したようなグループ・レコードは、ベアラＡ１−Ｂ１によってそれぞれサポートされる、サーバ２とのデータ・セッションＡ２−Ｂ２を有する多数の通信端末３Ａ、３Ｂに適用される。グループ・レコードは、ＳＰＲ^＊に収容されている。グループ・レコードにおけるグループ情報は、例えば、グループＧの中にある端末３Ａ、３Ｂの全てのベアラＡ１、Ｂ１に対する総計ビット・レートに関係するビット・レート閾値を収容する。グループＧの中にある全ての通信端末３が、個別加入レコードにおいて指定されている最大ビット・レートでサーバ２と同時にデータを交換するということは可能性が非常に低いという統計的結果を生かすために、グループＧにおける端末３Ａ、３Ｂ、または端末３Ａ、３Ｂの全てのベアラＡ１、Ｂ１の全ての個別加入の最大ビット・レート値の和は、グループＧに対して指定されたビット・レート閾値よりも大きくてもよい。

図３Ｂに示すように、グループ・レコードは、グループ識別子、そのグループの中にある端末またはベアラの個別加入ＩＤ（例えば、ＩＭＳＩ）の識別、および前述のグループＧに対する総計ビット・レート閾値のような、グループに関する情報を収容することができる。

また、グループ・レコードを用いる結果、グループ識別の識別(identification of the group identification)を、そのグループに入る複数の個別加入に追加することになる場合もある。個別加入は、多数のグループ加入に収容されることが可能である。

個々の通信端末３Ａ、３Ｂ毎にＰＣＲＦ^＊によって下されたポリシー決定は、インターフェースＧｘ^＊を通じてＰＣＥＦ^＊に伝達される。ＰＣＥＦ^＊は、これらの決定を施行する。

グループ負荷条件を満たす場合、例えば、グループＧについてのグループ情報において指定されている前述の総計ビット・レート閾値を上回る場合、ＰＣＲＦ^＊はＰＣＥＦ^＊によって通知されず、ＰＣＲＦ^＊は個々のポリシー決定を調整する。その結果、グループＧにおいてアクティブな端末３Ａ、３Ｂのベアラの内少なくとも１つが修正されることになる。ＰＣＲＦ^＊は、インターフェースＧｘ^＊を通じて、調整された個々のポリシー決定をＰＣＥＦ^＊に伝える。この結果、例えば、ベアラＡ１および／またはＢ１に指定されている最大ビット・レートのダウンスケーリング(downscaling)、ならびに端末３Ａ、３Ｂとサーバ２との間におけるデータ・セッションＡ２および／またはＢ２において交換されるユーザ・データのビット・レートの低下が生ずる場合がある。

尚、グループ負荷条件を満たすことの検出、およびイベントをＰＣＲＦ^＊に報告することは、ＰＣＥＦ^＊以外のエンティティによって行ってもよいことは注記してしかるべきであろう。ＰＣＥＦ^＊以外のエンティティには、ＰＣＥＦ^＊の位置とは異なる位置（例えば、ＳＧＳＮ／Ｓ−ＧＷにおける、またはＧＧＳＮ／Ｐ−ＧＷをＳＧＳＮ／Ｓ−ＧＷに接続するインターフェースにおける位置）にあるエンティティが含まれる。これについては、図８を参照して更に説明する。

ＰＣＥＦ^＊が単にＰＣＲＦ^＊に輻輳負荷条件が満たされたことを通知することに加えて、輻輳負荷条件を満たすという通知を有する追加の情報を含んでもよい。また、ＰＣＲＦ^＊は、追加情報を監視し報告するように、ＰＣＥＦ^＊に要求することもできる。ＰＣＥＦ^＊によって監視および報告することができる追加情報の一例には、最近データが交換されたことがあるベアラ（あるいはデータ・セッションまたは端末）の内１つ以上を識別する識別子のリストである。この追加データは、ＰＣＲＦ^＊がそのポリシー決定に対して調整を行うとき、そして調整したＰＣＣルールを最初に適用するベアラ（あるいはデータ・セッションまたは端末）に優先順位を付ける際に役立ち、輻輳を解消することに対して一層直接的な効果を狙うことができる。

図５Ａおよび図５Ｂは、個別ＰＣＣルールおよびグループ・ルールの例を示す。グループ・ルールは共通ＰＣＣルールとは異なるが、この説明においては両方ともＰＣＣルールと呼ぶことにする。ＰＣＥＦ^＊は、これらのＰＣＣルールをＰＣＲＦ^＊から受け取り、これらを施行または実施する。図示のように、個別ＰＣＣルールは、個々のＰＣＣルールを識別する情報、ＰＣＥＦ^＊が関係するＩＰフローを検出するために用いる情報、ならびに必要とされるＱｏＳおよび課金処置についての情報を収容する。必要とされるＱｏＳおよび課金処置についての情報は、例えば、ダウンリンクおよびアップリンクに対する最大ビット・レートの設定、ダウンリンクおよびアップリンクの保証ビット・レート、ＩＰ ＤｉｆｆＳｅｒｖ ＤＳＣＰマーキング、およびその他の輻輳に関する情報を含む。

グループ・ルール（図５Ｂ）も同様に、グループ・ルールを識別する情報、ＰＣＥＦ^＊がそのグループに向けられたＩＰフローを検出するために用いる情報（グループ内にあるベアラに対して個別ＰＣＣルールにおいて指定された個々のフロー検出情報から集計することができる）、そして特にグループ負荷条件を収容する。

代替実施形態（図５Ｂにおいて破線で示す）では、グループ・ルールは、グループ内にある端末／ベアラのＰＣＣルールＩＤを収容することができる。この情報は、グループの中にある端末／ベアラに対するフロー検出を指定する役割を果たすことができる。

本発明の摘要において既に述べたように、開示する方法およびシステムは、サーバ２の所有者／運用者にフレキシビリティを与える。図６Ａに示すように、サーバ２とＳＰＲ^＊との間におけるＰｘプロビジョニング・インターフェースを通じた相互作用によって、例えば、グループ・レコードの作成、このレコードのアダプテーション、個々の端末３に対する輻輳閾値パラメータの調整、一旦負荷条件が満たされたならグループの中にあるアクティブなベアラをどのように調整するか（図３Ｂのグループ・レコードを参照のこと）等というような、グループ・レコードにおける他の情報の調整等を行うことができる。図６Ｂに示すように、ＰＣＲＦ^＊は、ポリシー入力要求を通じて、サーバ２とも相互作用して、ポリシー入力プロビジョニング・メッセージを通じて、グループの中にあるアクティブなベアラをどのように調整するかについての情報を読み出すこともできる。あるいは、サーバはこの情報をＰＣＲＦ^＊にプッシュすることもできる。この情報は、勿論、ＳＰＲ^＊からインターフェースＳｐ^＊を通じて読み出すこともできる。更に、例えば、Ｐｘインターフェースを用いて、グループ内部のサブグループについての更に別の情報、および／または個々の輻輳関係パラメータをどのように（例えば、どのレベル（１つまたは複数）まで）および／またはどのようなシーケンスで調整すべきかに関する情報も、グループ・レコードおよび／または個別加入レコードに収容することができる。

図７Ａおよび図７Ｂは、図４のＰＣＣ^＊アーキテクチャを用いて、電気通信ネットワーク１において輻輳を制御する方法の第１例を示す。

図７Ａは、ＰＣＥＦ^＊からＰＣＲＦ^＊との相互作用をトリガするアクティブな端末３Ａ〜３Ｄの使用の一例を示す。端末３Ａ〜３Ｄには、共通グループ識別子が割り当てられており、したがって同じグループＧに属する。個別輻輳パラメータ、ここでは、同意最大ビット・レートＭＢＲは、端末３Ａ、３Ｂに対しては４０、そして３Ｃおよび３Ｄに対しては２０である。全ての端末３Ａ〜３Ｄには、図１のＧＰＲＳネットワーク１においてアクティブなデータ・セッションを可能にするベアラが確立されている。グループ負荷条件ＧＬＣ１が定められており、当該グループについて監視されている総計ビット・レートが８０の値を超えたときに輻輳を通知することになっている。ＰＣＥＦ^＊は、これにしたがってＰＣＲＦ^＊によって命令されており、グループ負荷指標、例えば、グループＧの総計ビット・レートを監視する。一例として、陰影線を付けた棒グラフで示すように、端末３Ａ、３Ｂが実際に用いているビット・レートが３０に過ぎず、端末３Ｃが１０に過ぎず、端末３Ｄが５に過ぎないと仮定する。すると、ＰＣＥＦ^＊は、値が７５のグループ負荷指標を察知することができる。これは、グループ負荷条件を満たしていない。代替実施態様では、ＰＣＥＦ^＊は、例えば、このグループの総計ビット・レートを、８０のビット・レートに設定されたトークン・バケットまたは同様のものにおけるような基準レートと比較することによって、もっと直接的な方法でグループ負荷条件を検出することができ、グループに対する総計ビット・レートの値を明示的に判定しない。更に別の代替実施態様では、ＰＣＥＦ^＊は、通信端末３毎に別個にビット・レートを、例えば、既存のＰＣＣルールの一部として監視することができ、そしてグループＧの中にある端末の各々に関する値を合計し、グループＧのグループ負荷指標を求めることができる。

ＰＣＥＦ^＊が、グループ負荷条件ＧＬＣ１が満たされていることを察知すると（例えば、３Ｄのビット・レートが５から２０に増加したことによって生ずる）（図７Ａでは端末３Ｄに対して上向きの矢印で示されている）、グループ負荷条件ＧＬＣ１を満たしたことによって、この条件をＰＣＲＦ^＊を通知するようにＰＣＥＦ^＊を作動させる。任意に、ＰＣＥＦ^＊は、この状況の過酷度に関する追加情報を提供することもでき、ＰＣＲＦ^＊がこれを考慮に入れることが可能になる。

ＰＣＲＦ^＊は、グループＧの中にある通信端末の内少なくとも１つについて、個別ＰＣＣルールを調整する。調整は、例えば、最大ビット・レートのダウンスケーリングに関係付けることができる。図７Ａでは、通信端末３Ａ〜３Ｄの最大ビット・レート（ＭＢＲ）の値は、ＭＢＲ_Ａ〜ＭＢＲ_Ｄとして示されている。この例では、ＰＣＲＦ^＊は、通信端末３Ａおよび３Ｂの最大ビット・レート・パラメータ、即ち、ＭＢＲ_ＡおよびＭＢＲ_Ｂの値を４０から２０にダウンスケールすることを決定する。ＰＣＥＦ^＊は、ＰＣＲＦ^＊から更新ＰＣＣルール（１つまたは複数）を受け取った後、ＭＢＲ_ＡおよびＭＢＲ_Ｂに対して下向きの矢印によって示すように、ベアラのＭＢＲ_Ａ〜ＭＢＲ_Ｄの個別輻輳パラメータを調整する（この例では、ＭＢＲ_ＡおよびＭＢＲ_Ｂのみを調整する必要がある）。該当する端末３Ａおよび３Ｂは、そのビット・レートが２０以下に低下する。端末が、ＭＢＲのような、調整後のデータ・セッション通信パラメータに適合し損ねた場合、これは通常の方法でＰＣＥＦ^＊によって設定される。この例では、個別輻輳パラメータ（ＭＢＲ）は、この時点では全て２０の値に設定されている。ここでは、電気通信ネットワーク１は、８０よりも高いビット・レートを配信せず、グループ負荷条件ＧＬＣ１はもはや満たされなくなる。

個別輻輳パラメータ値の下方向への調整は、所定の値を現在のパラメータ値から減算することによって行い、例えば、所定のもっと小さい値にするか、または現在のパラメータ値の端数（例えば、７０％）を求めることによって、行うことができる。したがって、パラメータ値の下方向の調整は、グループ内で異なってもよい。

ＰＣＥＦ^＊は、総計ビット・レートが限度以内に再び戻ったときに、ＰＣＲＦ^＊に通知することができる。また、ＰＣＲＦ^＊は、輻輳条件の終結 (expiration)を通知する前に、ＰＣＥＦ^＊に所定のヒステリシスを適用するように命令することもできる。

最大ビット・レート値ＭＢＲのような、個別輻輳パラメータの上方向の調整は、ＰＣＥＦ^＊からの「フィードバック」を用いて、例えば、各ステップの後に、段階的に行うとよい。上方向の調整、およびＩＰ−ＣＡＮベアラまたは端末３Ａ〜３Ｄ間におけるそれらの分布の大きさは、ＰＣＲＦ^＊によって決定される。一例として、分布は、ＳＰＲ^＊に格納されているグループ・レコードにおいて予め規定されていてもよく、またはＰＣＲＦ^＊は、図６Ｂに示したように、プロビジョニング・インターフェースＰｙを通じてサーバ２を参照することもでき、あるいは通信端末が上方向の調整を要求し、通常の方法でＰＣＲＦ^＊からの承認を受けることもできる。

尚、個別輻輳パラメータの調整は、下方向または上方向のいずれであっても、先に例示したような種々のポリシーにしたがって行うことができる。グループに対する輻輳パラメータ調整ポリシーは、図３Ｂに模式的に示したように、グループ・レコードに含めることができる。

図７Ａに示すように、ＰＣＥＦ^＊をＰＣＲＦ^＊に通知するように作動させるための下位トリガ・レベルとして機能する第２グループ負荷条件ＧＬＣ２を定めることができる。グループ負荷条件ＧＬＣ２がもはや満たされなくなると、ＰＣＲＦ^＊は、ビット・レートをいくらか高めにすると効果を得ることができる、グループＧの中にある端末３Ａ〜３Ｄに対して既に設定されているＰＣＣルールの内１つ以上をスケールアップする決定を下すことができる。

図７Ｂは、アップリンク・トラフィックについて先に説明した例におけるＰＣＥＦ^＊とＰＣＲＦ^＊との間における通信の模式フロー・チャートを示す。

ステップ１において、ＰＣＥＦ^＊は、グループ負荷条件ＧＬＣ１またはＧＬＣ２が満たされたことを確定する。本例では、ＰＣＥＦ^＊は、グループＧの中にある通信端末３の総計ビット・レートが特定の時点において所定値を超えたことを検出する。

ステップ２では、ＰＣＥＦ^＊が、グループ負荷条件ＧＬＣ１が満たされたという事実をＰＣＲＦ^＊に通知する。

ステップ３では、ＰＣＲＦ^＊によって、新たなポリシー決定、例えば、ＰＣＣルールに対して、したがって、グループＧの端末３Ａおよび３Ｂのベアラに対して、最大ビット・レート・パラメータ（ＭＢＲ）をスケールダウンする決定が行われる。どのベアラおよび／またはどのパラメータを適合させるべきかについての情報は、輻輳パラメータ調整ポリシーによって判定されるか、または、先に説明した図６Ａに示したように、例えば、ＳＰＲ^＊またはサーバ２から得られる。

ステップ４において、図５Ａに示したように、端末３Ａおよび３Ｂに対する調整後の個々のＰＣＣルールを、ＰＣＥＦ^＊に知らせる。また、更新されたグループ・ルールは、例えば、電気通信ネットワーク１の運用者がグループ負荷条件ＧＬＣ１および／またはＧＬＣ２を適合させることを望むときに、ＰＣＥＦ^＊にも提供することができる。

ステップ５において、該当する通信端末（この例では、端末３Ａおよび端末３Ｂ）のＩＰ−ＣＡＮベアラを、その通信端末に対して調整したＰＣＣルールにしたがって修正する。関与する端末（この例では、端末３Ａおよび３Ｂ）には、個々のパラメータの調整値（この例では、ＭＢＲのダウンスケール値）について知らせ、端末はそれにしたがって動作する。

これらのメッセージはゲートウェイＧＧＳＮから端末（この例では、端末３Ａおよび３Ｂ）の各々に別個に送ることができるが、グループＧの中にある通信端末のデータ・セッション通信パラメータ（例えば、ＰＤＰコンテキストおよびＩＰ−ＣＡＮベアラ）を調整するために、グループＧのグループ識別子を用い、電気通信ネットワーク１において更に下流にあるネットワーク・ノードにグループ更新要求を送ると有利な場合もある。これについては、図８以降を参照して以下で更に詳しく説明する。

ステップ６において、ＰＣＥＦ^＊は、（この例では）端末３Ａおよび３Ｂに対して調整したＰＣＣルールを用いて、新たな個別ＰＣＣルールを施行する。

最後に、ステップ７において、ＰＣＥＦ^＊は、ＩＰ−ＣＡＮベアラの調整が首尾良くできたこと、そして、おそらくは、調整したグループ負荷条件の確立について、ＰＣＲＦ^＊に知らせる。

勿論、このプロセスは、同じ（おそらくは、調整された）グループ負荷条件またはその他のこのような条件に関する追加の通知に対してもステップ１から繰り返すことができ、および／または、例えば、先に行った下方向の調整では未だ十分に輻輳が解決できなかったときに、個別輻輳パラメータを更に下方向に調整するために、またはＰＣＲＦ^＊が上方向の調整を決定したときにそれを命令するために、ステップ３から繰り返すことができる。

ＰＣＲＦ^＊が輻輳条件について知らせを受けたとき、ＰＣＲＦ^＊は、ベアラ（１つまたは複数）の輻輳パラメータを調整することに加えて、確立することを要求された追加のベアラにＱｏＳリソースを許可するために、またはグループにおいてアクティブになることを要求することができる追加のデータ・セッションにＱｏＳリソースを許可するために、そのポリシーに対して調整を行うことを決定することもできる。これを、端末３Ｅについて図７Ｃに示す。例えば、ＰＣＲＦ^＊は、グループＧにおける追加のベアラまたはセッションに許可され得る最大ビット・レートを、例えば、４０の値から例えば１０の値に調整することも決定する。グループＧの中にある追加の端末３Ｅが、例えば、ＭＢＲ_Ｅが４０であるベアラを確立することを要求するのであった場合、ＰＣＲＦ^＊はポリシー決定を下す。この場合、要求された４０のＭＢＲ_Ｅは他の場合であれば許可されたであろうが、ＰＣＲＦ^＊は、この４０のＭＢＲ_Ｅを付与せずに、ＭＢＲ_Ｅを１０としたＰＣＣルールを発行する。これは、端末３Ｅに対する下方向を指し示す矢印によって示されている。

前述のように、グループ・レコードおよび共通グループ識別子が利用可能であるため、先に説明したような輻輳制御方法およびシステムの組み合わせ、ならびに本願と同一日に出願された同時係属中の特許出願"Information transmission in machine-to-machine telecommunication network"（マシン・ツー・マシン電気通信ネットワークにおける情報送信）に記載されているような他の目的の双方に有利になるように、グループ・レコードおよび共通グループ識別子を用いることができる。この特許出願をここで引用したことにより、その内容が全て本願にも含まれるものとする。

一般に、共通グループ識別子は、多数の通信端末の、ＰＤＰコンテキストまたはＩＰ−ＣＡＮのパラメータというような、ＩＰ−ＣＡＮベアラを調整するために用いることができる。現在、特定のＰＤＰのコンテキストをネットワーク始動で修正する場合、殆どの最近の電気通信ネットワーク技術によってサポートされる。現在の技法は、少なくとも１つのネットワーク・ノードと通信端末の各々との間におけるシグナリングを必要とする。

既知の方法では、関与のある通信端末の各々のベアラのＰＤＰコンテキストを修正すると、ＩＰ−ＣＡＮベアラの数（通常、端末の数）に比例するシグナリング負荷が誘発される。言い換えると、ＩＰ−ＣＡＮベアラ修正メッセージが、ベアラ毎に発生する。ＰＤＰコンテキスト修正手順は、例えば、３ＧＰＰ ＴＳ ２３．０６０に記載されている。加えて、負荷が本質的に最大になるのは、相当多数の通信端末に対して修正が開始されるときである。例えば、前述の輻輳制御方法およびシステムでは、グループＧの通信端末３にアップリンク・トラフィックに対するＰＣＣルールの調整について知らせる必要があるときに、この修正が必要となることがある。また、このピークは、関与するネットワーク・エレメントの処理負荷についてもオブザーブされる。

通信端末の共通グループ識別子は、相当多数の通信端末のベアラに対して個別輻輳パラメータの調整を開始するときに、ネットワークにおけるシグナリング負荷を低減するために用いることができる。また、シグナリング負荷のピーク、およびネットワーク・エレメントにおける処理負荷も、同様に低減することができる。

一例として、個々の通信端末３のＩＰ−ＣＡＮベアラの修正を含むＩＰ−ＣＡＮベアラ・グループ修正手順を用いることができる。ＨＬＲまたはＨＳＳ／ＳＰＲにおける共通（サブ）グループ識別子によって、（サブ）グループを識別し、通信端末をこれらのグループの１つ以上に割り当てることができる。

このようなグループ修正手順は、例えば、このような修正のトリガの検出時に、ＧＧＳＮ／Ｐ−ＧＷまたはＳＧＳＮ／Ｓ−ＧＷのようなネットワーク・ノードにおいて開始することができる（輻輳負荷条件を満たす、先の実施形態を参照のこと）。

図８は、通信端末３Ａ〜３Ｚを備えているグループＧに対するＧＧＳＮ−始動グループＰＤＰコンテキスト修正手順の一実施形態である。

トリガ（図示せず）後の最初のステップでは、ＧＧＳＮがグループＰＤＰコンテキスト更新要求を１つ以上のＳＧＳＮに送る。このメッセージは、例えば、ＨＬＲ／ＳＰＲ^＊またはＨＳＳ／ＳＰＲ^＊に格納されているグループ・レコードから得られる、共通グループ識別子を収容している。また、このメッセージは、グループＧにおけるベアラの各々に対する所望のＱｏＳプロファイルを示すＱｏＳ要求パラメータも収容している。ここでは、相当な効率が得られる。何故なら、ベアラ毎に更新要求が個々に要求される先行技術の手順とは異なり、１つの要求だけがＧＧＳＮからＳＧＳＮに送信されるからである。グループＰＤＰコンテキスト更新要求は、前述の輻輳制御方法および電気通信ネットワーク１に対するＩＰ−ＣＡＮベアラ調整を収容することができる。

ＳＧＳＮは、共通グループ識別子を用いてＨＬＲと相互作用することによって、ＧＧＳＮから受けたグループＰＤＰコンテキスト更新要求から、関与する通信端末３Ａ〜３Ｚを導き出す。個々の通信端末３Ａ〜３Ｚについての情報（即ち、その個々の識別子）は、ＨＬＲから読み出すこと、および／または読み出した後ＳＧＳＮに格納することができる。

ＳＧＳＮは、ステップ２において、ＰＤＰコンテキスト修正要求メッセージを各端末３Ａ〜３Ｚに送る。このメッセージは、とりわけ、情報、新たに取り決められたＱｏＳを含む。新たに取り決められたＱｏＳは、ＳＧＳＮによって更に制限されていることもある。

各端末３Ａ〜３Ｚは、ＰＤＰコンテキスト修正受入メッセージをＳＧＳＮに返送することによって、ステップ２のＰＤＰコンテキスト修正要求を承認する。端末３Ａ〜３Ｚが新たに取り決められたＱｏＳを受け入れない場合、代わりに、端末始動ＰＤＰコンテキスト不活性化手順によって、ＰＤＰコンテキストを不活性化することができる。次いで、ＳＧＳＮは、端末始動ＰＤＰコンテキスト不活性化手順（図示せず）に従えばよい。

少なくともＵＭＴＳネットワークにおいて、ＰＤＰコンテキスト修正はＲＡＢ（無線アクセス・ベアラ）修正を伴う。ＲＡＢ修正は、ＰＤＰコンテキスト修正要求（ステップ２）後、またはＰＤＰコンテキスト修正受入（ステップ３）後直ちに、ステップ４において個々の通信端末３Ａ〜３Ｚ毎に行われる。あるいは、ＲＡＢ修正は、ステップ３のＰＤＰコンテキスト修正受入を受け取った後に、端末の各々に対して行われる。

全ての端末３Ａ〜３ＺからＰＤＰコンテキスト修正受入メッセージを受信したとき、または全てのＲＡＢ修正手順を完了したとき（ＵＭＴＳネットワークの場合）、ＳＧＳＮはグループＰＤＰコンテキスト更新応答メッセージをＧＧＳＮに返送する。このメッセージは、例えば、ＧＧＳＮから受けたグループＰＤＰコンテキスト更新要求に収容されていたのと同じ共通グループ識別子を収容している。シグナリング・メッセージ交換では、トランザクション識別子を用いることも可能である。トランザクション識別子の値は、ＧＧＳＮによって指定され、ＧＧＳＮがステップ１の要求に含めたのであり、ＳＧＳＮは、その値を、おそらくはグループ識別子の代わりとして、ステップ５においてその応答に含める。

また、図８に示すように、グループＰＤＰコンテキスト修正は、例えば、ＳＧＳＮまたは関連のあるエンティティが、先に説明したように、輻輳負荷条件を検出したときに、ＳＧＳＮによって開始することもできる。このような状況では、ＳＧＳＮは、輻輳条件を他のネットワーク・ノード（例えば、ＧＧＳＮへまたはＰＣＥＦ^＊へ）に報告し、他のネットワーク・エンティティにしかるべき処置を開始させるのではなく、グループＰＤＰコンテキスト修正を直ちに開始することができる利点がある。この場合、グループが定められており、このグループに属する全てのデータ・セッション（通信端末）は、ＳＧＳＮの制御下にあると仮定する。次いで、図８について説明したように、同様の手順に従うことができ、この場合、図８の最初と最後のステップにおけるＧＧＳＮとの相互作用が省略される。しかしながら、修正の間または修正の完了後、ＳＧＳＮは、ＧＧＳＮに修正について通知する。この通知には、そのＳＧＳＮ指向グループ(SGSN-oriented group)の共通グループ識別子を用いることができる利点がある。また、ＳＧＳＮは、グループＰＤＰコンテキスト更新要求をＧＧＳＮに送ることができ、ＧＧＳＮは、ＧＧＳＮにおいて入手可能な情報（例えば、制限）を考慮に入れるために、ＳＧＳＮへの関係応答メッセージ(related response message)で応答することができる。

尚、図８を参照して説明したグループＰＤＰコンテキスト修正の手順は、輻輳制御に関する修正に限定されるのではなく、輻輳解消または軽減に効果をあげることができる個別輻輳パラメータの修正に限定されるのでもないことは、認められてしかるべきであろう。また、この手順は、他のタイプのネットワークにおいて多数のＰＤＰコンテキストまたは同様のコンテキストを修正すべき他の場合にも用いることができる利点があり、また、この手順は、アクセス・ポイント名（ＡＰＮ）の修正、ＱｏＳクラスの修正、適用すべきＤｉｆｆＳｅｒｖ ＤＳＣＰマーキングの修正というような、他のパラメータにも用いることができる。

特定の場合に、メッセージを通信端末のグループにブロードキャストすることが有用であることもある。これらのメッセージは、共通グループ識別子を収容しており、例えば、輻輳制御に関する情報、または通信端末３のグループＧに関連のある他の情報に関する情報を収容することができる。このような場合、通信端末３は、このブロードキャストから情報を読み出す（選択する）ために、共通グループ識別子を有していなければならない（アクセスできなければならない）。この共通グループ識別子に関する情報は、例えば、電気通信ネットワーク１への接続手順(attach procedure)の間に得ることができ、共通グループ識別子（１つまたは複数）を、個別加入レコード（図３Ａ参照）から読み出して、端末に送信することができる。また、共通グループ識別子（１つまたは複数）は、通信端末３（のモジュール）において格納することまたは予めプログラミングすることもできる。

ブロードキャストの実施形態は、周知のような、セル・ブロードキャスト・センタＣＢＣを応用することができる。種々のアーキテクチャが可能であり、例えば、図９に示すように、ＣＢＣを複数のＳＧＳＮ／Ｓ−ＧＷおよび／または複数のＧＧＳＮ／ＰＧ−Ｗに接続する。この場合も、メッセージ送信は、ＳＧＳＮまたはＧＧＳＮのいずれからでも開始することができる。セル・ブロードキャスト・サービスは、３ＧＰＰ ＴＳ ２３．０４１において指定されている。

図１０は、端末３Ａ〜３ＺのグループＧのＰＤＰコンテキスト修正のフロー・チャートを示し、前述のようにＰＤＰコンテキストを修正することがトリガされたとき（ステップ１）に、ＧＧＳＮがグループＰＤＰコンテキスト更新要求を開始し、ＣＢＣはＳＧＳＮによって制御される。

ＧＧＳＮは、ステップ２において、グループＰＤＰコンテキスト更新要求を１つ以上のＳＧＳＮに送る。この要求は、少なくとも修正しなければならない通信端末３Ａ〜３Ｚに対する共通グループ識別子と、グループＧの中にある端末３Ａ〜３Ｚのベアラに所望のＱｏＳを示すパラメータ（１つまたは複数）とを収容している。関連のある全てのＳＧＳＮがこの要求を確実に受けるために、ＧＧＳＮは異なる手法に従うことができる。１つの手法は、ＧＧＳＮが、それが接続している全てのＳＧＳＮに要求を送ることである。別の手法は、ＧＧＳＮが（ＨＬＲ／ＨＳＳを参照することによって）該当するＳＧＳＮを求めて、要求をこれら該当するＳＧＳＮのみに送ることである。更に別の手法は、グループ毎に、ＧＧＳＮがマルチキャスト・グループを設定することであり、このグループに対してメッセージをマルチキャストすることができる。次いで、あるグループＧに属する端末に対してＰＤＰコンテキストが設定されると、ＳＧＳＮは、グループＧと関連のあるマルチキャスト・グループにおいて送信される全てのメッセージを受信することをそれが引き受ける(subscribe)ことを、ＧＧＳＮに知らせる。グループ更新ＰＤＰ要求の場合、全ての該当するＳＧＳＮ（全てそのグループに加入している）がメッセージを確実に受け取るためには、ＧＧＳＮは、１つのメッセージを、グループＧと関連のあるマルチキャスト・グループに挿入するだけでよい。

ＳＧＳＮは、ブロードキャストまたはマルチキャスト技術を用いて、ＰＤＰコンテキスト更新・グループ要求について、グループＧの中にある通信端末３Ａ〜３Ｚに知らせる。更に具体的には、この実施形態では、セル・ブロードキャスト（ＣＢ）が用いられる。ＳＧＳＮは、セル・ブロードキャスト・エンティティ（ＣＢＥ）として動作する（３ＧＰＰ ＴＳ ２３．０４１参照）。これは、メッセージをブロードキャストすべき地理的エリアを定める。この地理的エリアは、セル・ブロードキャスト・エリアとして知られている。これは、ＳＧＳＮと関連のある全てのセルとすることができる。ステップ３において、ＳＧＳＮはＣＢメッセージ要求をＣＢＣに送る。このＣＢメッセージは、ＰＤＰコンテキスト修正・グループ要求パラメータ、グループＧに対する共通グループ識別子、およびグループＧにおけるＰＤＰコンテキストに要求されるＱｏＳを示すパラメータ（１つまたは複数）を収容している。

ステップ４ａにおいて、ＣＢＣは、（定められた）セル・ブロードキャスト・エリアにしたがって、書き込み−置換メッセージ(Write-Replace message)においてＣＢメッセージをＲＡＮに、即ち、１つ以上のＢＳＣ／ＲＮＣに転送する。一方、ＲＡＮは、ステップ４ｂにおいて、ＳＭＳブロードキャスト要求を通じて、定められたエリアにおいてＣＢメッセージをブロードキャストすることを要求する。ＣＢメッセージは、グループＧの共通グループ識別子も収容している。したがって、このブロードキャスト・メッセージを受信した各通信端末は、受信したメッセージがその端末に宛てられたのか否か判断することができる。これは、受信したメッセージにおけるグループ識別子の内少なくとも１つが、端末のグループ識別子の内少なくとも１つに一致する場合である。このように、グループＧのグループ識別子ＩＤ_Ｇを有する通信端末は、図１０のステップ４ｂに示すように、受信したブロードキャスト・メッセージがグループ識別子ＩＤ_Ｇを含んでおり、その端末に宛てられたのであることを認識し、このメッセージを受信した他の端末は、このメッセージを無関係であるとして無視することができる（図１０には示されていない）。あるいは、多数のセル・ブロードキャスト・チャネルが利用可能である場合、グループ識別子は、どのチャネルに通信端末を同調させるべきか判断することができる。ステップ４ｃにおいて、ＲＡＮは書き込み−置換に応答して報告−成功(Report-Success)を送る。このステップ４におけるメッセージのブロードキャストは、セル・ブロードキャスト・サービスの仕様に従うものである。３ＧＰＰ ＴＳ ２３．０４１を参照のこと。

ＲＡＮから、即ち、全ての関与するＢＳＣ／ＲＮＣから報告−成功メッセージを受信した後、ＣＢＣは、ステップ５において、ＣＢメッセージ報告をＳＧＳＮに送る。また、通信端末３Ａ〜３Ｚの内、ステップ４ｂにおいてＣＢメッセージを受信しそのメッセージがそれに宛てられていることを認識した端末は、ステップ６ａ〜６ｚにおいて、修正要求を受け入れる。これらの各々は、通常のＰＤＰ修正受入メッセージ（最終的に、ＰＤＰコンテキストが属する通信端末３Ａ〜３ＺのグループＧの識別を含む）をＳＧＳＮに送る。以前に示したように、トランザクション識別子を用いることも一般的であり、その値は、ＳＧＳＮによって指定することができ、ＳＧＳＮは、ステップ３のＣＢメッセージ要求においてグループＰＤＰコンテキスト修正要求に、トランザクション識別子を含ませ、端末３Ａ〜３Ｚの各々は、その値を、ステップ６ａ〜６ｚにおいてその応答に含ませる。

ステップ７ａ〜７ｚにおいて、個々の端末に対するＰＤＰコンテキスト修正受入メッセージ６ａ〜６ｚを受信した後に、無線アクセス・ベアラ（ＲＡＢ）修正を、端末３Ａ〜３Ｚの各々に対して個別に実行する。この場合も、これらのステップ７ａ〜７ｚは、個々のＰＤＰコンテキスト修正受入メッセージを全て受信した後（ステップ６ａから６ｚ）に実行することもできる。

グループＧの中にある全ての通信端末３Ａ〜３ＺからのＰＤＰコンテキスト修正手順を処理するときに、ＳＧＳＮは、ステップ８において、グループＰＤＰコンテキスト更新応答メッセージをＧＧＳＮに返送する。このメッセージは、少なくとも、グループＧの共通グループ識別子を収容している。以前に示したように、トランザクション識別子を用いることも一般的であり、その値は、ＧＧＳＮによって指定することができ、ＧＧＳＮは、ステップ２のグループＰＤＰコンテキスト更新要求において、グループＰＤＰコンテキスト修正要求にトランザクション識別子を含ませ、ＳＧＳＮは、ステップ８において、その値をその応答に含ませる。

最後に、ＧＧＳＮは、ＰＤＰコンテキストのグループ毎修正をトリガしたエンティティに、ＰＤＰコンテキスト修正の成果について知らせることができる（ステップ９）。

既に記したように、図１０の実施形態には他の異体も可能である。一例として、ＧＧＳＮは、修正要求をグループＧの中にある通信端末３Ａ〜３Ｚに送るように、ＣＢＣを作動させることができる。次いで、ＳＧＳＮとＣＢＣとの間で行われる代わりに、ＧＧＳＮとＣＢＣとの間でセル・ブロードキャスト相互作用が行われる。次いで、ステップ２では、ＧＧＳＮからＳＧＳＮの情報メッセージが、ＧＧＳＮがセル・ブロードキャスト・エンティティ（ＣＢＥ）として動作することの通知も含む。

考えられるその他の実施形態では、通信端末３Ａ〜３ＺのグループＧに対する修正を開始するように、ＳＧＳＮ（ＧＧＳＮの代わりに）を作動させる。すると、ＳＧＳＮは、グループＰＤＰコンテキスト更新要求をＧＧＳＮに送ることができ、ＧＧＳＮはグループＰＤＰコンテキスト更新応答メッセージをＳＧＳＮに返送することができる。

更に別の実施形態では、通信端末３Ａ〜３ＺのグループＧの修正を開始するようにＳＧＳＮを動作させる（前述の実施形態と同様）が、ＧＧＳＮはＣＢＥとして動作する。ＳＧＳＮは、内部で作動させられて、グループＰＤＰコンテキスト更新要求をＧＧＳＮに送る。ＧＧＳＮは、グループＰＤＰコンテキスト更新応答メッセージをＳＧＳＮに返送する。セル・ブロードキャスト相互作用は、ＧＧＳＮとＣＢＣとの間で行われ、ＧＧＳＮは、それがＣＢＥとして動作することを、ＳＧＳＮに知らせる。

Claims (15)

1. 電気通信ネットワーク（１）における輻輳制御方法であって、前記電気通信ネットワークが、少なくとも第１ベアラおよび第２ベアラをそれぞれ設けることによって、サーバ（２）と少なくとも第１通信端末および第２通信端末（３）との間における１つ以上のアクティブなデータ・セッションをサポートし、前記方法が、
   −前記少なくとも第１通信端末および第２通信端末を含むグループに割り当てられた共通グループ識別子を格納するステップと、
   −前記第１通信端末および第２通信端末についての前記第１ベアラに対する第１個別輻輳パラメータと、前記第２ベアラに対する第２個別輻輳パラメータとをそれぞれ格納するステップと、
   −前記電気通信ネットワークにおいて、前記共通グループ識別子に対応する前記少なくとも第１端末および前記第２端末のグループに対して定められたグループ負荷指標を監視するステップと、
   −前記グループのグループ負荷指標を、前記共通グループ識別子に対応する前記少なくとも第１端末および第２通信端末の前記グループのグループ負荷条件と比較するステップであって、前記グループ負荷条件が、該条件を満たすときに、前記グループの前記少なくとも第１通信端末および第２通信端末における前記第１ベアラの第１個別輻輳パラメータおよび前記第２ベアラの第２個別輻輳パラメータの内少なくとも１つを調整することをトリガするための条件である、ステップと、
   −前記グループ負荷指標が前記グループ負荷条件を満たし、前記第１ベアラの第１個別輻輳パラメータおよび前記第２ベアラの第２個別輻輳パラメータの内少なくとも１つを調整することによって、前記電気通信ネットワークにおける輻輳を制御するステップと、
   を備えている、方法。
2. 請求項１記載の方法において、前記グループ負荷指標が、第３端末に対しても定められており、前記方法が、更に、
   −前記第３通信端末に対する前記共通グループ識別子を格納するステップと、
   −前記第３通信端末についての第３ベアラに対する第３個別輻輳パラメータを格納するステップと、
   −前記サーバと前記第３通信端末との間におけるアクティブなデータ・セッションを可能にするために、前記第３ベアラを確立する要求を受けるステップと、
   −前記グループ輻輳指標が前記グループ負荷条件を満たすときに、前記第３ベアラの第３個別輻輳パラメータも調整することによって、前記電気通信ネットワークにおける輻輳を制御するステップと、
   −前記サーバと、前記第３ベアラに対して前記調整された第３個別輻輳パラメータを適用する前記第３通信端末との間における１つ以上のアクティブなデータ・セッションをサポートする前記第３ベアラを確立する前記要求を許可するステップと、
   を備えている、方法。
3. 請求項１または２記載の方法であって、更に、
   −前記第２端末が前記第２ベアラを通じてデータを交換したよりときよりも後になってから、前記第１通信端末が前記第１ベアラを通じてデータを交換したと判定するステップと、
   −前記グループ負荷指標が前記グループ負荷条件を満たすときに、前記第２ベアラの第２個別輻輳パラメータを調整する前に、前記第１ベアラの第１個別輻輳パラメータを調整するステップと、
   を備えている、方法。
4. 請求項１から３いずれか一項に記載の方法において、前記第１通信端末および第２通信端末が、第１個別識別子および第２個別識別子によってそれぞれ識別可能であり、前記方法が、更に、
   −前記第１個別識別子および第２個別識別子と前記共通グループ識別子との間における関係を格納するステップと、
   −前記第１個別識別子および第２個別識別子を受け取るステップと、
   −前記第１個別識別子および第２個別識別子と前記共通グループ識別子との間における、前記格納されている関係に基づいて、前記共通グループ識別子を決定するステップと、
   −前記共通グループ識別子に基づいて、前記グループに対して前記適用可能なグループ負荷指標およびグループ負荷条件を決定するステップと、
   を備えている、方法。
5. 請求項１から４のいずれか一項に記載の方法において、前記第１個別輻輳パラメータおよび第２個別輻輳パラメータ、前記グループ負荷指標、並びに前記グループ負荷条件が、（最大）ビット・レートを含み、前記グループ負荷条件を満たすことが、グループ・ビット・レート閾値を超えることを含む、方法。
6. 請求項１から５のいずれか一項に記載の方法において、前記サーバが、プロビジョニング・インターフェースを通じて、前記第１通信端末および第２通信端末の前記共通グループ識別子を格納するネットワーク・ノードに接続されており、前記方法が、前記共通グループ識別子を前記第１通信端末および第２通信端末に、前記サーバから前記プロビジョニング・インターフェースを通じて割り当てるステップを備えている、方法。
7. 請求項１から６のいずれか一項に記載の方法であって、更に、
   −通信端末の第１グループの第１共通グループ識別子を格納し、通信端末の第２グループの第２共通グループ識別子を格納するステップであって、前記第１通信端末が前記第１グループおよび前記第２グループ双方に割り当てられる、ステップと、
   −前記電気通信ネットワークにおいて、前記第１共通グループ識別子に対応する前記通信端末の第１グループの第１グループ負荷指標と、前記第２共通グループ識別子に対応する前記通信端末の第２グループの第２グループ負荷指標とを監視するステップと、
   −前記第１グループ負荷指標を、前記第１共通グループ識別子に対応する前記通信端末の第１グループの第１グループ負荷条件と比較するステップと、
   −前記第２グループ負荷指標を、前記第２共通グループ識別子に対応する前記通信端末の第２グループの第２グループ負荷条件と比較するステップと、
   −前記第１グループ負荷指標および前記第２グループ負荷指標の少なくとも１つが前記第１グループ負荷条件および第２グループ負荷条件をそれぞれ満たすとき、前記第１ベアラの第１個別輻輳パラメータを調整することによって、前記電気通信ネットワークにおける輻輳を制御するステップと、
   を備えている、方法。
8. 請求項１から７のいずれか一項に記載の方法であって、更に、前記第１個別輻輳パラメータおよび前記第２個別輻輳パラメータの少なくとも１つを徐々に調整するステップを備えている、方法。
9. 請求項１から８のいずれか一項に記載の方法において、前記グループ負荷指標が前記グループ負荷条件を満たすときに、前記第１ベアラおよび前記第２ベアラの第１個別輻輳パラメータおよび第２個別輻輳パラメータの少なくとも１つをそれぞれ調整するステップが、前記第１通信端末および第２通信端末から前記サーバに向かうアップリンク・トラフィックに対して実行され、更に、前記輻輳パラメータが調整される対象である前記第１通信端末および／または第２通信端末に、前記１つ以上のアクティブなデータ・セッションに対する前記第１ベアラおよび第２ベアラそれぞれの特性の調整を知らせるステップを備えている、方法。
10. 請求項９記載の方法において、前記第１通信端末および／または第２通信端末に知らせる前記ステップが、前記第１通信端末および／または第２通信端末に知らせるために、前記電気通信ネットワークにおける情報メッセージに前記共通グループ識別子を含ませるステップを備えている、方法。
11. 請求項１０記載の方法において、前記共通グループ識別子を収容する前記情報メッセージが、前記電気通信ネットワークの少なくとも一部においてブロードキャストされる、方法。
12. 少なくとも第１ベアラおよび第２ベアラをそれぞれ設けることによって、サーバ（２）と少なくとも第１通信端末および第２通信端末（３）との間におけるデータ・セッションを可能にするように構成されている電気通信ネットワーク（１）であって、
    −前記少なくとも第１通信端末および第２通信端末を含むグループに割り当てられた共通グループ識別子を格納する第１記憶ノードと、
    −前記第１通信端末および前記第２通信端末の第１ベアラに対する第１個別輻輳パラメータと、第２ベアラに対する第２個別輻輳パラメータとをそれぞれ格納する第２記憶ノードと、
    −前記共通グループ識別子に対応する前記少なくとも第１通信端末および第２通信端末のグループに対して定められたグループ負荷指標を監視するように構成されている監視モジュールと、
    −前記グループ負荷識別子を、前記共通グループ識別子に対応する前記少なくとも第１通信端末および第２通信端末のグループのグループ負荷条件と比較するように構成されている分析部であって、前記グループ負荷条件が、該条件を満たすときに、前記グループの前記少なくとも第１通信端末および第２通信端末における前記第１ベアラの第１個別輻輳パラメータおよび前記第２ベアラの第２個別輻輳パラメータの内少なくとも１つを調整することをトリガするための条件である、分析部と、
    −前記グループ負荷指標が前記グループ負荷条件を満たし、前記第１ベアラの第１個別輻輳パラメータおよび前記第２ベアラの第２個別輻輳パラメータの少なくとも１つを調整することによって、前記電気通信ネットワークにおける輻輳制御を行うように構成されている輻輳制御部と、
    を備えている、電気通信ネットワーク。
13. 請求項１２記載の電気通信ネットワークにおいて、この電気通信ネットワークが、例えば、ブロードキャスト・メッセージにおいて第１ユーザ端末および第２ユーザ端末に向けて情報メッセージを送信するように構成されており、前記メッセージが、前記共通グループ識別子を含み、前記データ・セッションのアップリンク・トラフィック方向における前記ベアラの特性調整に関する情報を収容する、電気通信ネットワーク。
14. 請求項１２記載の電気通信ネットワークにおいて、請求項２から９のいずれか一項に記載の方法が有する複数のステップを実行するための１または複数の手段を備えている、電気通信ネットワーク。
15. ＰＣＥＦおよび／もしくはＰＣＲＦに具備され、またはＳＧＳＮおよび／もしくはＧＧＳＮに具備される１または複数のプロセッサによって実行されると、請求項１から１１のいずれか一項記載の方法が有する複数のステップを実行するように構成されている、ソフトウェア・コード部を備えているコンピュータ・プログラム。
    

Images