(57)【要約】【課題】Ｃ−ＲＡＮアーキテクチャを採るセルラ通信システムに対して、よりきめ細かな輻輳判定や輻輳制御を行う技術を提供する。【解決手段】ネットワークノード間の第１のメッセージを用いてＣ−ＲＡＮのセルにおける端末の在圏情報を取得し、ネットワークノード間の第２のメッセージを用いてＣ−ＲＡＮのセルの輻輳指標を取得し、輻輳指標に基づいてセルの輻輳発生を判定し、端末の在圏情報に基づいて輻輳が発生しているセルに在圏する端末を特定し、特定された端末の最大利用可能帯域幅を制限するよう制御装置へ指示する。【選択図】  図１
2015220559.tif 000002
【特許請求の範囲】
【請求項１】
それぞれが地理的に離れて配置され端末と通信を行う複数の無線送受信装置と、前記複数の無線送受信装置に接続される処理装置とからなるＣ−ＲＡＮを有するセルラ通信システムにおけるトラフィック管理サーバであって、
前記セルラ通信システムを構成するネットワークノード間の第１のメッセージを用いて、前記複数の無線送受信装置それぞれのセルにおける前記端末の在圏情報を取得し、
前記セルラ通信システムを構成するネットワークノード間の第２のメッセージを用いて、前記セルの輻輳指標を取得し、
前記輻輳指標に基づいて、前記セルの輻輳発生を判定し、
前記端末の在圏情報に基づいて、前記輻輳が発生しているセルに在圏する端末を特定し、
前記特定された端末の最大利用可能帯域幅を制限するよう前記セルラ通信システムを構成する制御装置へ指示することを特徴とするトラフィック管理サーバ。
【請求項２】
地理的に離れて配置され端末と通信を行う複数の無線送受信装置と、前記複数の無線送受信装置に接続される処理装置とからなるＣ−ＲＡＮを有するセルラ通信システムにおけるトラフィック管理サーバであって、
同一の前記Ｃ−ＲＡＮに属し、かつ、前記複数の無線送受信装置が形成し地理的に近接するセルをセルクラスタとしてグルーピングを行い、
前記セルラ通信システムを構成するネットワークノード間の第１のメッセージを用いて、前記セルクラスタにおける前記端末の在圏情報を取得し、
前記セルラ通信システムを構成するネットワークノード間の第２のメッセージを用いて、前記セルクラスタの輻輳指標を取得し、
前記輻輳指標に基づいて、前記セルクラスタの輻輳発生を判定し、
前記端末の在圏情報に基づいて、前記輻輳が発生しているセルクラスタに在圏する端末を特定し、
前記特定された端末の最大利用可能帯域幅を制限するよう前記セルラ通信システムを構成する制御装置へ指示することを特徴とするトラフィック管理サーバ。
【請求項３】
請求項２に記載のトラフィック管理サーバであって、
前記複数の無線送受信装置それぞれが形成するセルごとに、隣接セル情報を保持し、
前記セルクラスタのグルーピングを行う際、所定のセルの前記隣接セル情報に含まれるセルのうち、前記所定のセルと同一のＣ−ＲＡＮに属するセルを、前記所定のセルと同一のセルクラスタとしてグルーピングを行うことを特徴とするトラフィック管理サーバ。
【請求項４】
請求項２に記載のトラフィック管理サーバであって、
前記端末が滞在したセルの情報を含むハンドオーバ履歴情報を保持し、
前記セルクラスタのグルーピングを行う際、前記ハンドオーバ履歴情報に含まれるセルのうち、ハンドオーバ前後の２つのセルが同一Ｃ−ＲＡＮに属する場合、前記２つのセルを同一のセルクラスタとしてグルーピングすることを特徴とするトラフィック管理サーバ。
【請求項５】
請求項２に記載のトラフィック管理サーバであって、
前記Ｃ−ＲＡＮに属するセル群と、基地局群との間で発生した端末の移動回数をカウントし、
前記セルクラスタのグルーピングを行う際、同一のＣ−ＲＡＮに属する前記セル群のうち、前記基地局群に含まれる同一基地局との間での前記移動回数が多いセルを、同一のセルクラスタとしてグルーピングすることを特徴とするトラフィック管理サーバ。
【請求項６】
請求項２に記載のトラフィック管理サーバであって、
前記セルクラスタにおける輻輳発生を判定するための判定閾値を、前記セルクラスタごとに保持し、
前記判定閾値を、前記セルクラスタに含まれるセル数に基づいて決定することを特徴とするトラフィック管理サーバ。
【請求項７】
それぞれが地理的に離れて配置され端末と通信を行う複数の無線送受信装置と、前記複数の無線送受信装置に接続される処理装置とからなるＣ−ＲＡＮを有するセルラ通信システムにおけるトラフィック管理サーバで実行される管理プログラムであって、
前記セルラ通信システムを構成するネットワークノード間の第１のメッセージを用いて、前記複数の無線送受信装置それぞれのセルにおける前記端末の在圏情報を取得し、
前記セルラ通信システムを構成するネットワークノード間の第２のメッセージを用いて、前記セルの輻輳指標を取得し、
前記輻輳指標に基づいて、前記セルの輻輳発生を判定し、
前記端末の在圏情報に基づいて、前記輻輳が発生しているセルに在圏する端末を特定し、
前記特定された端末の最大利用可能帯域幅を制限するよう前記セルラ通信システムを構成する制御装置へ指示することを特徴とする管理プログラム。
【請求項８】
地理的に離れて配置され端末と通信を行う複数の無線送受信装置と、前記複数の無線送受信装置に接続される処理装置とからなるＣ−ＲＡＮを有するセルラ通信システムにおけるトラフィック管理サーバで実行される管理プログラムであって、
同一の前記Ｃ−ＲＡＮに属し、かつ、前記複数の無線送受信装置が形成し地理的に近接するセルをセルクラスタとしてグルーピングを行い、
前記セルラ通信システムを構成するネットワークノード間の第１のメッセージを用いて、前記セルクラスタにおける前記端末の在圏情報を取得し、
前記セルラ通信システムを構成するネットワークノード間の第２のメッセージを用いて、前記セルクラスタの輻輳指標を取得し、
前記輻輳指標に基づいて、前記セルクラスタの輻輳発生を判定し、
前記端末の在圏情報に基づいて、前記輻輳が発生しているセルクラスタに在圏する端末を特定し、
前記特定された端末の最大利用可能帯域幅を制限するよう前記セルラ通信システムを構成する制御装置へ指示することを特徴とする管理プログラム。
【請求項９】
請求項８に記載の管理プログラムであって、
前記トラフィック管理サーバには、前記複数の無線送受信装置それぞれが形成するセルごとの隣接セル情報が保持され、
前記セルクラスタのグルーピングを行う際、所定のセルの前記隣接セル情報に含まれるセルのうち、前記所定のセルと同一のＣ−ＲＡＮに属するセルを、前記所定のセルと同一のセルクラスタとしてグルーピングを行うことを特徴とする管理プログラム。
【請求項１０】
請求項８に記載の管理プログラムであって、
前記トラフィック管理サーバには、前記端末が滞在したセルの情報を含むハンドオーバ履歴情報が保持され、
前記セルクラスタのグルーピングを行う際、前記ハンドオーバ履歴情報に含まれるセルのうち、ハンドオーバ前後の２つのセルが同一Ｃ−ＲＡＮに属する場合、前記２つのセルを同一のセルクラスタとしてグルーピングすることを特徴とする管理プログラム。
【請求項１１】
請求項８に記載の管理プログラムであって、
前記Ｃ−ＲＡＮに属するセル群と、基地局群との間で発生した端末の移動回数をカウントし、
前記セルクラスタのグルーピングを行う際、同一のＣ−ＲＡＮに属する前記セル群のうち、前記基地局群に含まれる同一基地局との間での前記移動回数が多いセルを、同一のセルクラスタとしてグルーピングすることを特徴とする管理プログラム。
【請求項１２】
請求項８に記載の管理プログラムであって、
前記セルクラスタにおける輻輳発生を判定するための判定閾値を、前記セルクラスタごとに、前記セルクラスタに含まれるセル数に基づいて決定することを特徴とする管理プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信ネットワークのトラフィック分析およびトラフィック制御技術に関する。
【背景技術】
【０００２】
セルラ通信システムでは、一部のネットワークノードに負荷が集中したり、ユーザが高データレートを要するサービスを利用したりなどすると、輻輳が生じる場合がある。輻輳が生じると、パケットの欠落や伝送遅延が増加し、ユーザ品質が劣化するおそれがある。そこで、輻輳が生じる場合は、アクセス制限や帯域制限が行われることがある。
【０００３】
特許文献１では、ＵＭＴＳ（Ｕｎｉｖｅｒｓａｌ  Ｍｏｂｉｌｅ  Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ  Ｓｙｓｔｅｍ）において、無線ネットワーク制御装置とＮｏｄｅＢとの間のＩｕｂまたはＩｕｂ／Ｉｕｒインタフェース上におけるユーザプレーントラフィック量を、過負荷期間中に制御する方法が開示されている。特許文献1によると、ＩｕｂまたはＩｕｂ／Ｉｕｒインタフェース上に確立されたアップリンクまたはダウンリンクコネクションの各々について、ＩｕｂまたはＩｕｂ／Ｉｕｒインタフェース上で伝送されたフレームの、無線ネットワーク制御装置またはＮｏｄｅＢにおける到着遅延を無線ネットワーク制御装置で監視した結果に基づき、必要に応じてコネクションについてのＩｕｂまたはＩｕｂ／Ｉｕｒ負荷を削減させる。
【０００４】
一方、セルラ通信システムにおけるＲＡＮ（Ｒａｄｉｏ  Ａｃｃｅｓｓ  Ｎｅｔｗｏｒｋ）のアーキテクチャとしてＣ−ＲＡＮ（Ｃｅｎｔｒａｌｉｚｅｄ  ＲＡＮ、あるいはＣｌｏｕｄ  ＲＡＮ）が注目を集めている。Ｃ−ＲＡＮでは、電波を送受信するＲＲＨ（Ｒｅｍｏｔｅ  Ｒａｄｉｏ  Ｈｅａｄ）とベースバンド信号処理を行うＢＢＵ（Ｂａｓｅｂａｎｄ  Ｕｎｉｔ）を地理的に分離させ、各サイトに設置したＲＲＨと、１か所に集約したＢＢＵを光ファイバで接続する。Ｃ−ＲＡＮには、ベースバンド信号処理を集約することによる、リソース共有やＲＲＨ間連携による高効率化が期待されている。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特表２００８−５１６４８６号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
セルラ通信システムの輻輳発生を判定する方法として、プローブ装置により取得した、コアネットワークのトラフィック情報やシグナリング情報を用いることが考えられる。例えば、３ＧＰＰ（３ｒｄ  Ｇｅｎｅｒａｔｉｏｎ  Ｐａｒｔｎｅｒｓｈｉｐ  Ｐｒｏｊｅｃｔ）で標準化されているＬＴＥ（Ｌｏｎｇ  Ｔｅｒｍ  Ｅｖｏｌｕｔｉｏｎ）では、ｅＮｏｄｅＢ（Ｅ−ＵＴＲＡＮ  ＮｏｄｅＢ）とＳ−ＧＷ（Ｓｅｒｖｉｎｇ  Ｇａｔｅｗａｙ）間のインタフェースであるＳ１−Ｕや、ＰＤＮ（Ｐａｃｋｅｔ  Ｄａｔａ  Ｎｅｔｗｏｒｋ）とＰ−ＧＷ（ＰＤＮ  Ｇａｔeｗａｙ）間のインタフェースであるＳＧｉを、プローブ装置でモニタリングすることにより、トラフィック情報を取得することができる。また、ｅＮｏｄｅＢとＭＭＥ（Ｍｏｂｉｌｉｔｙ  Ｍａｎａｇｅｍｅｎｔ  Ｅｎｔｉｔｙ）間のインタフェースであるＳ１−ＭＭＥや、ＭＭＥとＳ−ＧＷ間のインタフェースであるＳ１１をプローブ装置でモニタリングすることにより、シグナリング情報を取得することができる。
【０００７】
取得したトラフィック情報からは、トラフィック量やトラフィック種別などを得ることができ、これらは輻輳発生の判定基準として用いることができる。また、取得したシグナリング情報からは、トラフィックを発生させているユーザの在圏位置を得ることができる。例えば、初期接続やハンドオーバの際に発生するＳ１−ＭＭＥやＳ１１シグナリングを取得して、ユーザ在圏位置を得ることができる。
【０００８】
しかしながら、Ｃ−ＲＡＮの場合、同一Ｃ−ＲＡＮ内、つまり同一のＢＢＵに接続されるＲＲＨ間のハンドオーバは、Ｉｎｔｒａ−ｅＮｏｄｅＢハンドオーバと見なされる。つまり、ＵＥ（Ｕｓｅｒ  Ｅｑｕｉｐｍｅｎｔ）とＢＢＵ間で処理が終端するため、コアネットワークのシグナリングは発生しない。従って、同一Ｃ−ＲＡＮ内でのユーザの移動を、プローブ装置で取得したシグナリング情報で捕捉できないため、トラフィックを発生させているユーザの在圏位置は、Ｃ−ＲＡＮ単位で管理することになる。Ｃ−ＲＡＮ単位でのユーザの在圏位置情報を使用した、輻輳が発生しているか否かの判定は、Ｃ−ＲＡＮ単位で行うことになる。なお、Ｉｎｔｒａ−ｅＮｏｄｅＢハンドオーバとは、同一ｅＮｏｄｅＢが持つセル間のハンドオーバであり、ＵＥとｅＮｏｄｅＢ間で処理が終端するため、コアネットワークのシグナリングは発生しないものである。
【０００９】
一方で、Ｃ−ＲＡＮにおいては、複数のＲＲＨが互いに地理的に離れた場所に置かれることがある。このような状況においてもＣ−ＲＡＮ単位で輻輳発生の判定を行うと、地理的に離れたＲＲＨのカバーエリアを、一括して輻輳していると判定することになる。その場合、実際には輻輳していないエリアに在圏するユーザに対して、帯域制限やアクセス制限を行ってしまうおそれがある。
【００１０】
このため、Ｃ−ＲＡＮアーキテクチャを採るセルラ通信システムに対して、よりきめ細かな輻輳判定や輻輳制御を行う技術が求められている。
【課題を解決するための手段】
【００１１】
本願において開示される発明の代表的な例を示せば以下の通りである。すなわち、それぞれが地理的に離れて配置され端末と通信を行う複数の無線送受信装置と、前記複数の無線送受信装置に接続される処理装置とからなるＣ−ＲＡＮを有するセルラ通信システムにおけるトラフィック管理サーバであって、前記セルラ通信システムを構成するネットワークノード間の第１のメッセージを用いて、前記複数の無線送受信装置それぞれのセルにおける前記端末の在圏情報を取得し、前記セルラ通信システムを構成するネットワークノード間の第２のメッセージを用いて、前記セルの輻輳指標を取得し、前記輻輳指標に基づいて、前記セルの輻輳発生を判定し、前記端末の在圏情報に基づいて、前記輻輳が発生しているセルに在圏する端末を特定し、前記特定された端末の最大利用可能帯域幅を制限するよう前記セルラ通信システムを構成する制御装置へ指示することを特徴とするトラフィック管理サーバである。
【００１２】
また、地理的に離れて配置され端末と通信を行う複数の無線送受信装置と、前記複数の無線送受信装置に接続される処理装置とからなるＣ−ＲＡＮを有するセルラ通信システムにおけるトラフィック管理サーバであって、同一の前記Ｃ−ＲＡＮに属し、かつ、前記複数の無線送受信装置が形成し地理的に近接するセルをセルクラスタとしてグルーピングを行い、前記セルラ通信システムを構成するネットワークノード間の第１のメッセージを用いて、前記セルクラスタにおける前記端末の在圏情報を取得し、前記セルラ通信システムを構成するネットワークノード間の第２のメッセージを用いて、前記セルクラスタの輻輳指標を取得し、前記輻輳指標に基づいて、前記セルクラスタの輻輳発生を判定し、前記端末の在圏情報に基づいて、前記輻輳が発生しているセルクラスタに在圏する端末を特定し、前記特定された端末の最大利用可能帯域幅を制限するよう前記セルラ通信システムを構成する制御装置へ指示することを特徴とするトラフィック管理サーバである。
【００１３】
また、それぞれが地理的に離れて配置され端末と通信を行う複数の無線送受信装置と、前記複数の無線送受信装置に接続される処理装置とからなるＣ−ＲＡＮを有するセルラ通信システムにおけるトラフィック管理サーバで実行される管理プログラムであって、前記セルラ通信システムを構成するネットワークノード間の第１のメッセージを用いて、前記複数の無線送受信装置それぞれのセルにおける前記端末の在圏情報を取得し、前記セルラ通信システムを構成するネットワークノード間の第２のメッセージを用いて、前記セルの輻輳指標を取得し、前記輻輳指標に基づいて、前記セルの輻輳発生を判定し、前記端末の在圏情報に基づいて、前記輻輳が発生しているセルに在圏する端末を特定し、前記特定された端末の最大利用可能帯域幅を制限するよう前記セルラ通信システムを構成する制御装置へ指示することを特徴とする管理プログラムである。
【００１４】
また、地理的に離れて配置され端末と通信を行う複数の無線送受信装置と、前記複数の無線送受信装置に接続される処理装置とからなるＣ−ＲＡＮを有するセルラ通信システムにおけるトラフィック管理サーバで実行される管理プログラムであって、同一の前記Ｃ−ＲＡＮに属し、かつ、前記複数の無線送受信装置が形成し地理的に近接するセルをセルクラスタとしてグルーピングを行い、前記セルラ通信システムを構成するネットワークノード間の第１のメッセージを用いて、前記セルクラスタにおける前記端末の在圏情報を取得し、前記セルラ通信システムを構成するネットワークノード間の第２のメッセージを用いて、前記セルクラスタの輻輳指標を取得し、前記輻輳指標に基づいて、前記セルクラスタの輻輳発生を判定し、前記端末の在圏情報に基づいて、前記輻輳が発生しているセルクラスタに在圏する端末を特定し、前記特定された端末の最大利用可能帯域幅を制限するよう前記セルラ通信システムを構成する制御装置へ指示することを特徴とする管理プログラムである。
【発明の効果】
【００１５】
本発明の代表的な形態によれば、Ｃ−ＲＡＮアーキテクチャを採るセルラ通信システムに対して、よりきめ細かな輻輳判定や輻輳制御を行うことができる。前述した以外の課題、構成及び効果は、以下の実施例の説明により明らかにされる。
【図面の簡単な説明】
【００１６】
【図１】第１実施例のセルラ通信システムの構成を示す図である。
【図２】第１実施例のトラフィック管理サーバの構成を示す図である。
【図３】第１実施例のトラフィック管理サーバがセル単位で輻輳状態およびユーザの在圏位置を管理する手順を説明するためのシーケンス図である。
【図４】第１実施例のユーザ情報テーブルである。
【図５】第１実施例のユーザ在圏情報更新処理を説明するためのフロー図である。
【図６】第１実施例の輻輳指標更新処理を説明するためのフロー図である。
【図７】第１実施例の輻輳指標テーブルである。
【図８】第１実施例の輻輳判定処理を説明するためのフロー図である。
【図９】第１実施例の帯域制限指示処理を説明するためのフロー図である。
【図１０】第２実施例のセルラ通信システムの構成を示す図である。
【図１１】第２実施例のトラフィック管理サーバの構成を示す図である。
【図１２】第２実施例のセルクラスタ情報テーブルである。
【図１３】第２実施例で使用するセル位置情報テーブルである。
【図１４】第２実施例のセルクラスタ作成処理の方法の１つを説明するためのフロー図である。
【図１５】ＥＣＧＩとｅＮｏｄｅＢ  ＩＤの関係を説明するための図である。
【図１６】第２実施例で使用するネイバー関係テーブルである。
【図１７】第２実施例のセルクラスタ作成処理の方法の１つを説明するためのフロー図である。
【図１８】第２実施例のトラフィック管理サーバが端末のハンドオーバ履歴情報を取得する方法を説明するためのシーケンス図である。
【図１９】第２実施例で使用するハンドオーバ履歴テーブルである。
【図２０】第２実施例のセルクラスタ作成処理の方法の１つを説明するためのフロー図である。
【図２１】第２実施例のセルクラスタ作成処理の方法の１つを説明するためのフロー図である。
【図２２】第２実施例のモビリティカウントテーブルである。
【図２３】第２実施例のモビリティカウント処理のフロー図である
【図２４】第２実施例のユーザ情報テーブルである。
【図２５】第２実施例のユーザ在圏情報更新処理を説明するためのフロー図である。
【図２６】第２実施例の輻輳指標更新処理を説明するためのフロー図である。
【図２７】第２実施例の輻輳指標テーブルである。
【図２８】第２実施例の輻輳判定処理を説明するためのフロー図である。
【図２９】第２実施例の帯域制限指示処理を説明するためのフロー図である。
【図３０】第２実施例の効果を説明するためのセル配置の一例を示す図である。
【発明を実施するための形態】
【実施例１】
【００１７】
以下、本発明の実施の形態を図面に基づいて詳細に説明する。
【００１８】
なお、以下の実施の形態においては便宜上その必要があるときは、複数のセクションまたは実施の形態に分割して説明するが、特に明示した場合を除き、それらはお互いに無関係なものではなく、一方は他方の一部または全部の変形例、詳細、補足説明などの関係にある。
【００１９】
また、以下の実施の形態において、要素の数等（個数、数値、量、範囲等を含む）に言及する場合、特に明示した場合及び原理的に明らかに特定の数に限定される場合などを除き、その特定の数に限定されるものではなく、特定の数以上でも以下でも良いものとする。
【００２０】
さらに、以下の実施の形態において、その構成要素（要素ステップなどを含む）は、特に明示した場合及び原理的に明らかに必須であると考えられる場合などを除き、必ずしも必須のものではないことは言うまでもない。
【００２１】
本実施例では、セルラ通信システムの例として３ＧＰＰで標準化されているＬＴＥを用い、Ｃ−ＲＡＮが複数のセルを形成し、各セルが互いに地理的に離れて配置されているセルラ通信システムを対象とする。そして、セル単位で輻輳状態およびユーザの在圏位置を管理し、セル単位で輻輳発生を判定し、輻輳が発生しているセルに在圏する端末を特定し、特定された端末の最大利用可能帯域幅を制限するようセルラ通信システムを構成する制御装置へ指示するトラフィック管理サーバの実施例を示す。
【００２２】
図１は、本実施例のセルラ通信システムの構成を示す図である。本システムは、ユーザ端末であるＵＥ１０１、基地局装置であるｅＮｏｄｅＢ１１１、ＲＲＨ１２１、光ファイバ１２３、ＢＢＵ１２４、保守管理装置であるＥＭＳ１２５、Ｓ−ＧＷ１３１、ＭＭＥ１３２、Ｐ−ＧＷ１３３、プローブ装置１４１、トラフィック管理サーバ１４２から成る。ｅＮｏｄｅＢ１１１は、セル１１２を構成する。ＲＲＨ１２１は電波の増幅や送受信を行う無線送受信装置であり、ＢＢＵ１２４はベースバンド信号処理を行う処理装置である。ＲＲＨ１２１とＢＢＵ１２４は光ファイバ１２３を介して接続されており、Ｃ−ＲＡＮを構成し、セル１２２を構成する。同一Ｃ−ＲＡＮ管理下のセル１２２は、互いに地理的に離れて配置されている。Ｓ−ＧＷ１３１は、ユーザプレーンのトラフィック転送機能を有するゲートウェイである。ＭＭＥ１３２は、ＵＥのモビリティを管理する装置であり、制御プレーンのシグナリングを送受信する。Ｐ−ＧＷ１３３はユーザへのサービスを提供するパケットデータネットワークＰＤＮ１３４とのインタフェースを有するゲートウェイである。Ｓ−ＧＷ１３１、ＭＭＥ１３２、Ｐ−ＧＷ１３３は互いに接続されており、コアネットワークを構成する。プローブ装置１４１は、ネットワーク上のパケットを取得する装置であり、ｅＮｏｄｅＢ１１１、ＢＢＵ１２４、Ｓ−ＧＷ１３１、ＭＭＥ１３２、Ｐ−ＧＷ１３３といったネットワークノード間、あるいはＰ−ＧＷ１３３とＰＤＮ１３４の間で送受信されるトラフィックあるいはシグナリングを取得する。プローブ装置１４１は、取得したトラフィックあるいはシグナリングの情報を、トラフィック管理サーバ１４２へ送信する。トラフィック管理サーバ１４２は、プローブ装置１４１から取得した情報を用いて、帯域制限を行うＵＥを決定し、対象ＵＥの帯域制限を行うようＰ−ＧＷ１３３へ指示する。
【００２３】
図２は、本実施例のトラフィック管理サーバ１４２の構成を示す図である。トラフィック管理サーバの機能は、一般的なコンピュータの外部記憶装置にプログラムソフトウェアの形で格納され、メモリ上に展開されてＣＰＵにより実行される。また、トラフィック管理サーバはネットワークＩ／Ｆを介して前記プローブ装置及びＰ−ＧＷと通信する。トラフィック管理サーバのメモリは、ユーザ在圏情報更新処理プログラム２０１、輻輳指標更新処理プログラム２０２、輻輳判定処理プログラム２０３、帯域制限指示処理プログラム２０４を格納する。さらにトラフィック管理サーバのメモリは、ユーザ情報テーブル２１１、輻輳指標テーブル２１２を格納する。
【００２４】
本実施例では上記プログラムおよび上記情報を単一のコンピュータのメモリ上に格納する構成を示した。しかし、上記情報を外部記憶装置に格納し、上記プログラムの処理のつど上記情報を上記外部記憶装置から読み込み、それぞれの処理が完了するごとに外部記憶装置に格納する構成を取ることも可能である。
【００２５】
あるいは、上記プログラムおよび上記情報を複数のコンピュータに分散して格納することも可能である。例えば上記情報をそれぞれリレーショナルデータベースのテーブルとして実装してトラフィック管理サーバとは異なるデータベースサーバに格納し、トラフィック管理サーバ上で実行された上記プログラムがデータベースサーバ上の上記情報を参照及び更新することも可能である。
【００２６】
また、上記情報をトラフィック管理サーバとは異なる分散型のＫＶＳ（Ｋｅｙ−Ｖａｌｕｅ  Ｓｔｏｒｅ）サーバに格納し、トラフィック管理サーバ上で実行された上記プログラムがＫＶＳサーバ上の上記情報を参照及び更新することも可能である。
【００２７】
以上のような上記情報の格納方法の違いは、本発明の本質には影響を与えない。
【００２８】
本実施例のトラフィック管理サーバの特徴の概略を簡単に説明すれば、以下の通りである。すなわちトラフィック管理サーバは、Ｃ−ＲＡＮが複数のセルを形成し、各セルが互いに地理的に離れて配置されているセルラ通信システムにおいて、セル単位で輻輳状態およびユーザの在圏位置を管理し、セル単位で輻輳発生を判定し、輻輳が発生しているセルに在圏する端末を特定し、特定された端末の最大利用可能帯域幅を制限するようセルラ通信システムを構成する制御装置へ指示する。
【００２９】
まず、図３を用いて、トラフィック管理サーバが、セル単位で輻輳状態およびユーザの在圏位置を管理する手順を説明する。図３は、セル単位で輻輳状態およびユーザの在圏位置を管理する手順を説明するためのシーケンス図である。
【００３０】
新規接続時、ＵＥはシーケンス３０１で、Ａｔｔａｃｈ  ＲｅｑｕｅｓｔメッセージをＣ−ＲＡＮまたはｅＮｏｄｅＢを経由してＭＭＥに送信する。続いて、ＵＥとＭＭＥの間で認証プロシージャ（シーケンス３０２）やセキュリティプロシージャ（シーケンス３０３）が行われる。その後、セッション確立のため、ＭＭＥはシーケンス３０４で、Ｃｒｅａｔｅ  Ｓｅｓｓｉｏｎ  ＲｅｑｕｅｓｔメッセージをＳ−ＧＷに送信する。このとき、プローブ装置は、Ｃｒｅａｔｅ  Ｓｅｓｓｉｏｎ  Ｒｅｑｕｅｓｔメッセージを取得し、この情報をトラフィック管理サーバへ渡す。トラフィック管理サーバは、プローブ装置より取得したＣｒｅａｔｅ  Ｓｅｓｓｉｏｎ  Ｒｅｑｕｅｓｔメッセージの情報を使用して、シーケンス３０５でユーザ在圏情報更新処理を行う。Ｓ−ＧＷはＣｒｅａｔｅ  Ｓｅｓｓｉｏｎ  ＲｅｑｕｅｓｔメッセージをＰ−ＧＷに送信し（シーケンス３０６）、Ｐ−ＧＷはＣｒｅａｔｅ  Ｓｅｓｓｉｏｎ  Ｒｅｓｐｏｎｓｅメッセージにより応答する（シーケンス３０７）。Ｓ−ＧＷは、Ｃｒｅａｔｅ  Ｓｅｓｓｉｏｎ  ＲｅｓｐｏｎｓｅメッセージをＭＭＥに送信する（シーケンス３０８）。その後、ＭＭＥはシーケンス３０９で、Ａｔｔａｃｈ  ＡｃｃｅｐｔメッセージをＣ−ＲＡＮまたはｅＮｏｄｅＢを経由してＵＥに送信する。ＵＥはシーケンス３１０で、Ａｔｔａｃｈ  ＣｏｍｐｌｅｔｅメッセージをＣ−ＲＡＮまたはｅＮｏｄｅＢを経由してＭＭＥに送信する。
【００３１】
新規接続が完了した後、トラフィックがＰＤＮとＵＥの間で送受信される。例えば、シーケンス３１１で、ＰＤＮから受信された下り方向のトラフィックはＰ−ＧＷ、Ｓ−ＧＷ、Ｃ−ＲＡＮまたはｅＮｏｄｅＢ、を経由してＵＥに送信される。プローブ装置はＳ１−Ｕインタフェースをモニタリングし、下り方向のトラフィック量をユーザごとに計測し、計測結果を、Ｓ１−Ｕインタフェースにおけるユーザ識別子であるＳ１−Ｕ  Ｆ−ＴＥＩＤ（Ｆｕｌｌｙ  Ｑｕａｌｉｆｉｅｄ  Ｔｕｎｎｅｌ  Ｅｎｄｐｏｉｎｔ  Ｉｄｅｎｔｉｆｉｅｒ）とともにトラフィック管理サーバへ渡す。トラフィック量の計測は、例えばある一定の時間周期で行えばよい。トラフィック管理サーバは、プローブ装置より取得した下り方向のトラフィック量計測結果を使用して、シーケンス３１２で輻輳指標更新処理を行う。
【００３２】
ＵＥが、異なるＣ−ＲＡＮ間や、Ｃ−ＲＡＮとｅＮｏｄｅＢ間を移動したり、ＵＥの再アクティブ化が行われると、ＵＥとＭＭＥの間でモビリティプロシージャ（シーケンス３２１）が行われる。続いて、ベアラ情報更新のため、ＭＭＥはシーケンス３２２において、Ｍｏｄｉｆｙ  Ｂｅａｒｅｒ  ＲｅｑｕｅｓｔメッセージをＳ−ＧＷに送信する。このとき、プローブ装置は、Ｍｏｄｉｆｙ  Ｂｅａｒｅｒ  Ｒｅｑｕｅｓｔメッセージを取得し、この情報をトラフィック管理サーバへ渡す。トラフィック管理サーバは、プローブ装置より取得したＭｏｄｉｆｙ  Ｂｅａｒｅｒ  Ｒｅｑｕｅｓｔメッセージの情報を使用して、シーケンス３２３でユーザ在圏情報更新処理を行う。Ｓ−ＧＷはＭｏｄｉｆｙ  Ｂｅａｒｅｒ  ＲｅｑｕｅｓｔメッセージをＰ−ＧＷに送信し（シーケンス３２４）、Ｐ−ＧＷはＭｏｄｉｆｙ  Ｂｅａｒｅｒ  Ｒｅｓｐｏｎｓｅメッセージにより応答する（シーケンス３２５）。Ｓ−ＧＷは、Ｍｏｄｉｆｙ  Ｂｅａｒｅｒ  ＲｅｓｐｏｎｓｅメッセージをＭＭＥに送信する（シーケンス３２６）。
【００３３】
その後、シーケンス３３１でトラフィックがＰＤＮとＵＥの間で送受信され、トラフィック管理サーバは、プローブ装置より取得した下り方向のトラフィック量計測結果を使用して、シーケンス３３２で輻輳指標更新処理を行う。
【００３４】
図４は、ユーザ在圏情報や輻輳指標からなるユーザエントリを格納するための、ユーザ情報テーブル２１１である。ユーザエントリは、ＩＭＳＩ、ＥＣＧＩ、Ｓ１１  Ｆ−ＴＥＩＤ、Ｓ１−Ｕ  Ｆ−ＴＥＩＤ、輻輳指標からなる。Ｓ１１  Ｆ−ＴＥＩＤは、ＩＰアドレスとＳ１１トンネルの識別子であるＴＥＩＤからなる。Ｓ１−Ｕ  Ｆ−ＴＥＩＤは、ＩＰアドレスとＳ１−Ｕトンネルの識別子であるＴＥＩＤからなる。輻輳指標は、図４の例ではトラフィック量である。
【００３５】
図５を用いて、シーケンス３０５およびシーケンス３２３で行われる、ユーザ在圏情報更新処理を説明する。図５は、トラフィック管理サーバが行うユーザ在圏情報更新処理プログラム２０１により実行されるユーザ在圏情報更新処理の手順を示すフロー図である。ステップ５０１において、トラフィック管理サーバは、プローブ装置より取得したメッセージが、Ｃｒｅａｔｅ  Ｓｅｓｓｉｏｎ  ＲｅｑｕｅｓｔメッセージかＭｏｄｉｆｙ  Ｂｅａｒｅｒ  Ｒｅｑｕｅｓｔメッセージかを判定する。プローブ装置より取得したメッセージがＣｒｅａｔｅ  Ｓｅｓｓｉｏｎ  Ｒｅｑｕｅｓｔメッセージの場合、トラフィック管理サーバはステップ５０２において、Ｃｒｅａｔｅ  Ｓｅｓｓｉｏｎ  Ｒｅｑｕｅｓｔメッセージから、ユニークなユーザ識別子であるＩＭＳＩ（Ｉｎｔｅｒｎａｔｉｏｎａｌ  Ｍｏｂｉｌｅ  Ｓｕｂｓｃｒｉｂｅｒ  Ｉｄｅｎｔｉｔｙ）、セル識別子であるＥＣＧＩ（Ｅ−ＵＴＲＡＮ  Ｃｅｌｌ  Ｇｌｏｂａｌ  Ｉｄｅｎｔｉｆｉｅｒ）、Ｓ１１インタフェースにおけるユーザ識別子であるＳ１１  Ｆ−ＴＥＩＤ、Ｓ１−Ｕインタフェースにおけるユーザ識別子であるＳ１−Ｕ  Ｆ−ＴＥＩＤ、を抽出する。続いて、トラフィック管理サーバはステップ５０３において、抽出したＩＭＳＩ、ＥＣＧＩ、Ｓ１１  Ｆ−ＴＥＩＤ、Ｓ１−Ｕ  Ｆ−ＴＥＩＤをユーザ情報テーブル２１１に、新規ユーザエントリとして格納する。
【００３６】
一方、ステップ５０１において、プローブ装置より取得したメッセージがＭｏｄｉｆｙ  Ｂｅａｒｅｒ  Ｒｅｑｕｅｓｔメッセージの場合、トラフィック管理サーバはステップ５１１において、Ｍｏｄｉｆｙ  Ｂｅａｒｅｒ  ＲｅｑｕｅｓｔメッセージからＥＣＧＩ、Ｓ１１  Ｆ−ＴＥＩＤを抽出する。続いて、トラフィック管理サーバはステップ５１２において、ユーザ情報テーブル２１１のユーザエントリのうち、ステップ５１１で抽出したＳ１１  Ｆ−ＴＥＩＤと同一のＳ１１  Ｆ−ＴＥＩＤを持つエントリに対し、ＥＣＧＩをステップ５１１で抽出したものに更新する。このように、異なるＣ−ＲＡＮ間や、Ｃ−ＲＡＮとｅＮｏｄｅＢ間の移動、ＵＥの再アクティブ化に伴うＭｏｄｉｆｙ  Ｂｅａｒｅｒ  Ｒｅｑｕｅｓｔメッセージから、ＥＣＧＩを抽出して更新する。これにより、セル単位でユーザの在圏位置を管理することが可能となる。
【００３７】
図６を用いて、シーケンス３１２およびシーケンス３３２で行われる、輻輳指標更新処理を説明する。図６は、トラフィック管理サーバが行う輻輳指標更新処理プログラム２０２により実行される輻輳指標更新処理の手順を示すフロー図である。トラフィック管理サーバはステップ６０１で、プローブ装置からＳ１−Ｕ  ＴＥＩＤとトラフィック量計測結果を取得する。トラフィック管理サーバはステップ６０２で、ユーザ情報テーブル２１１のユーザエントリのうち、ステップ６０１で抽出したＳ１−Ｕ  Ｆ−ＴＥＩＤと同一のＳ１−Ｕ  Ｆ−ＴＥＩＤを持つエントリに対し、輻輳指標をステップ６０１で取得したトラフィック量計測結果に更新する。さらに、トラフィック管理サーバはステップ６０３で、ユーザ情報テーブル２１１のユーザエントリのうち同一のＥＣＧＩを持つエントリの輻輳指標を集計し、集計結果を輻輳指標テーブル２１２に格納する。
【００３８】
図７は、輻輳指標テーブル２１２である。輻輳指標テーブルは、セルごとに、すなわちＥＣＧＩごとに、輻輳指標集計結果および輻輳状態を保持する。
【００３９】
次に、図８を用いて、トラフィック管理サーバが、セル単位で輻輳発生を判定する手順を説明する。図８は、トラフィック管理サーバが行う輻輳判定処理プログラム２０３により実行される輻輳判定処理の手順を示すフロー図である。トラフィック管理サーバは、ステップ８０１において、輻輳指標テーブル２１２に格納されているセルの輻輳指標集計結果が、閾値を超えているか否かを判定する。なお、ステップ８０１で使用する閾値は、例えば、ネットワーク管理者が予め設定しておいてもよいし、トラフィック管理サーバが設定してもよい。セルの輻輳指標集計結果が閾値を超えている場合（ステップ８０１のＹｅｓ）、トラフィック管理サーバはステップ８０２において、そのセルが輻輳していると判定し、輻輳指標テーブル２１２における当該セルの輻輳状態を、“輻輳”とする。セルの輻輳指標集計結果が閾値を超えていない場合（ステップ８０１のＮｏ）、トラフィック管理サーバはステップ８１１において、そのセルが輻輳していないと判定し、輻輳指標テーブル２１２における当該セルの輻輳状態を、“非輻輳”とする。これらの処理は、輻輳指標テーブル２１２で管理される各セルについて行われる。なお、輻輳指標テーブル２１２は、最新の輻輳判定結果と、前回の輻輳判定結果を保持する。輻輳発生の判定は、例えば一定の時間周期で行えばよい。
【００４０】
図９を用いて、トラフィック管理サーバが、輻輳が発生しているセルに在圏する端末を特定し、特定された端末の最大利用可能帯域幅を制限するようセルラ通信システムを構成する制御装置へ指示する手順を説明する。図９は、トラフィック管理サーバが行う帯域制限指示処理プログラム２０４により実行される帯域制限指示処理の手順を示すフロー図である。トラフィック管理サーバはステップ９０１において、輻輳指標テーブル２１２の最新の輻輳状態と前回判定時の輻輳状態を参照し、輻輳状態が“非輻輳”から“輻輳”になったセル（ＥＣＧＩ）を抽出する。次にトラフィック管理サーバはステップ９０２において、ユーザ情報テーブル２１１を参照し、ステップ９０１で抽出したセル（輻輳状態になったセル）に在圏するユーザ（ＩＭＳＩ）を抽出する。トラフィック管理サーバはステップ９０３において、ステップ９０２で抽出したユーザ（ＩＭＳＩ）への帯域制限の適用を、Ｐ−ＧＷに指示する。帯域制限の適用は、例えば、ユーザに許容される最大ビットレートを設定することによって行う。あるいは、非輻輳時にも最大ビットレートが設定される場合は、より小さい値の最大ビットレートを設定することによって、帯域制限を行う。さらに、トラフィック管理サーバはステップ９０４において、輻輳指標テーブル２１２の最新の輻輳状態と前回判定時の輻輳状態を参照し、輻輳状態が“輻輳”から“非輻輳”になったセル（ＥＣＧＩ）を抽出する。次にトラフィック管理サーバはステップ９０５において、ユーザ情報テーブル２１１を参照し、ステップ９０４で抽出したセル（非輻輳状態になったセル）に在圏するユーザ（ＩＭＳＩ）を抽出する。トラフィック管理サーバはステップ９０６において、ステップ９０５で抽出したユーザ（ＩＭＳＩ）への帯域制限の解除を、Ｐ−ＧＷに指示する。
【００４１】
上記の説明では、トラフィック管理サーバがメッセージから情報要素を抽出したが、プローブ装置がこれを行った上、プローブ装置が抽出された情報をトラフィック管理サーバへ渡してもよい。
【００４２】
また、上記の説明では、ＭＭＥとＳ−ＧＷ間のインタフェースであるＳ１１で送受信されるメッセージから情報要素を抽出したが、ＭＭＥとＢＢＵ（あるいはｅＮｏｄｅＢ）間のインタフェースであるＳ１−ＭＭＥなどの他のインタフェースで送受信されるメッセージから情報要素を抽出してもよい。
【００４３】
また、上記の説明では、輻輳指標として下り方向のトラフィック量を用いたが、別の指標を用いてもよい。例えば、輻輳指標として、伝送遅延量、データレート、接続ユーザ数を用いてもよい。伝送遅延量、データレート、接続ユーザ数は、例えばプローブ装置がＳ１−Ｕインタフェース上のトラフィックをモニタリングすることにより取得することが可能である。あるいは、輻輳指標として、上り方向のトラフィックに関わる情報を用いてもよい。
【００４４】
また、上記の説明では、輻輳状態を“輻輳”と“非輻輳”の２種類としたが、３種類以上の輻輳状態を定義することもできる。３種類以上の輻輳状態を定義することにより、セルの輻輳度合いに応じて、後段の帯域制限において異なる上限値を使用することができる。例えば、輻輳度合いが軽い場合の、ユーザに許容される最大ビットレートを、輻輳度合いが重い場合の、ユーザに許容される最大ビットレートより、大きい値に設定する。これにより、輻輳状態の変動に伴う最大ビットレートの変化を緩やかにし、帯域制限によるユーザサービスへの影響を抑制することができる。
【００４５】
また、上記の説明では、輻輳しているセルに在圏する全ユーザへ帯域制限を適用するが、一部のユーザに対してのみ帯域制限を適用してもよい。例えば、優遇したいユーザを予めトラフィック管理装置に登録しておき、トラフィック管理装置が、優遇したいユーザを帯域制限の対象外としてもよい。あるいは、帯域制限を行いたい特定のトラフィック種別をトラフィック管理装置に予め登録しておき、トラフィック管理装置が、特定のトラフィック種別の送受信を行っているユーザのみを帯域制限の対象としてもよい。
【００４６】
図１では、同一Ｃ−ＲＡＮ管理下のセル１２２は、互いに地理的に離れて配置されている。プローブ装置がＣ−ＲＡＮ内の移動を捕捉できないことは既に述べたが、図１のセル配置ではＣ−ＲＡＮ内の移動は発生せず、Ｃ−ＲＡＮ管理下のセル１２２と他の任意のセルの間のハンドオーバは常に、プローブ装置が捕捉可能であるＩｎｔｅｒ−ｅＮＢハンドオーバである。すなわち、図１のセル配置で本実施例を適用することで、トラフィック管理サーバは、ユーザがＣ−ＲＡＮ内のどのセルに在圏するかを管理可能である。結果的に、トラフィック管理サーバは、セル単位で輻輳状態を把握することができ、セル単位で帯域制限を行うか否かを判定できる。よって、Ｃ−ＲＡＮ単位で輻輳発生の判定を行うと地理的に離れたＲＲＨのカバーエリアを、一括して輻輳していると判定した場合、実際には輻輳していないエリアに在圏のユーザに対して、帯域制限やアクセス制限を行ってしまうという課題が解決される。
【実施例２】
【００４７】
第１の実施例では、図１のように同一Ｃ−ＲＡＮ管理下のセルが互いに地理的に離れて配置されているため、Ｃ−ＲＡＮ管理下のセル１２２と他の任意のセルの間のハンドオーバは常に、プローブ装置が捕捉可能であるＩｎｔｅｒ−ｅＮＢハンドオーバであった。一方、同一Ｃ−ＲＡＮ管理下のセルが密集して配置されている場合は、プローブ装置が捕捉できない、Ｃ−ＲＡＮ内の移動が発生する。そこで、本実施例では、地理的に隣接する、同一Ｃ−ＲＡＮ管理下のセルをセルクラスタとしてグルーピングし、セルクラスタ単位でユーザ在圏位置や輻輳状態を管理する。
【００４８】
本実施例では、セルラ通信システムの例として３ＧＰＰで標準化されているＬＴＥを用い、セルクラスタ単位で輻輳状態およびユーザの在圏位置を管理し、セルクラスタ単位で輻輳発生を判定し、輻輳が発生しているセルクラスタに在圏する端末を特定し、特定された端末の最大利用可能帯域幅を制限するようセルラ通信システムを構成する制御装置へ指示するトラフィック管理サーバの実施例を示す。
【００４９】
図１０は、本実施例のセルラ通信システムの構成を示す図である。図１０のシステムの構成要素は、図１で説明した第１の実施例の構成要素と同一である。そのため、ここでは説明を省略する。図１０では、Ｃ−ＲＡＮ管理下のいくつかのセルが、互いに地理的に隣接している。
【００５０】
図１１は、本実施例のトラフィック管理サーバ１４２の構成を示す図である。トラフィック管理サーバの機能は、一般的なコンピュータの外部記憶装置にプログラムソフトウェアの形で格納され、メモリ上に展開されてＣＰＵにより実行される。また、トラフィック管理サーバはネットワークＩ／Ｆを介して前記プローブ装置及びＰ−ＧＷと通信する。トラフィック管理サーバのメモリは、ユーザ在圏情報更新処理プログラム１１０１、輻輳指標更新処理プログラム１１０２、輻輳判定処理プログラム１１０３、帯域制限指示処理プログラム１１０４、セルクラスタ作成処理プログラム１１０５を格納する。さらにトラフィック管理サーバのメモリは、ユーザ情報テーブル１１１１、輻輳指標テーブル１１１２、セルクラスタ情報テーブル１１１３、セル位置情報テーブル１１１４、ネイバー関係テーブル（ＮＲＴ：Ｎｅｉｇｈｂｏｒ  Ｒｅｌａｔｉｏｎ  Ｔａｂｌｅ）１１１５、ハンドオーバ履歴テーブル１１１６、モビリティカウントテーブル１１１７を格納する。
【００５１】
本実施例では上記プログラムおよび上記情報を単一のコンピュータのメモリ上に格納する構成を示した。しかし、上記情報を外部記憶装置に格納し、上記プログラムの処理のつど上記情報を上記外部記憶装置から読み込み、それぞれの処理が完了するごとに外部記憶装置に格納する構成を取ることも可能である。
【００５２】
あるいは、上記プログラムおよび上記情報を複数のコンピュータに分散して格納することも可能である。例えば上記情報をそれぞれリレーショナルデータベースのテーブルとして実装してトラフィック管理サーバとは異なるデータベースサーバに格納し、トラフィック管理サーバ上で実行された上記プログラムがデータベースサーバ上の上記情報を参照及び更新することも可能である。
【００５３】
また、上記情報をトラフィック管理サーバとは異なる分散型のＫＶＳサーバに格納し、トラフィック管理サーバ上で実行された上記プログラムがＫＶＳサーバ上の上記情報を参照及び更新することも可能である。
【００５４】
以上のような上記情報の格納方法の違いは、本発明の本質には影響を与えない。
【００５５】
本実施例のトラフィック管理サーバの特徴の概略を簡単に説明すれば、以下の通りである。すなわちトラフィック管理サーバは、セルクラスタを作成し、セルクラスタ単位で輻輳状態およびユーザの在圏位置を管理し、セルクラスタ単位で輻輳発生を判定し、輻輳が発生しているセルクラスタに在圏する端末を特定し、特定された端末の最大利用可能帯域幅を制限するようセルラ通信システムを構成する制御装置へ指示する。
【００５６】
まず、セルクラスタの作成手順について説明する。トラフィック管理サーバは、同一Ｃ−ＲＡＮ管理下のセルのうち、近接するものをグルーピングし、セルクラスタ情報テーブルに格納する。図１２は、トラフィック管理サーバが保持するセルクラスタ情報テーブル１１０３である。セルクラスタ情報テーブル１１０３には、セルクラスタの識別子であるセルクラスタＩＤと、各セルクラスタを構成するセルのＥＣＧＩが含まれる。セルクラスタは、１つまたは複数のセルから構成される。
【００５７】
セルクラスタ情報テーブル１１０３は、予めトラフィック管理サーバに登録しておいてもよい。あるいは、トラフィック管理サーバが、Ｃ−ＲＡＮの保守管理装置であるＥＭＳ（Ｅｌｅｍｅｎｔ  Ｍａｎａｇｅｍｅｎｔ  Ｓｙｓｔｅｍ）から取得した情報を用いて、セルクラスタ情報テーブル１１０３を作成してもよい。あるいは、トラフィック管理サーバが、プローブ装置から取得した情報を用いて、セルクラスタ情報テーブル１１０３を作成してもよい。
【００５８】
トラフィック管理サーバが、Ｃ−ＲＡＮの保守管理装置であるＥＭＳから取得した情報を用いてセルクラスタ情報テーブル１１０３を作成する方法として、セルの位置情報を用いる方法を、図１３および図１４を用いて説明する。図１３はトラフィック管理サーバがＥＭＳから取得するセル位置情報テーブル１１１４であり、ＥＣＧＩごとに、緯度情報と経度情報が保持される。図１４はセルの位置情報を用いてトラフィック管理サーバが行うセルクラスタ作成処理プログラム１１０５により実行されるセルクラスタ作成処理のフロー図である。
【００５９】
図１４で、トラフィック管理サーバはステップ１４０１において、セル位置情報テーブル１１１４に格納されるＥＣＧＩから、同一Ｃ−ＲＡＮ（あるいはｅＮｏｄｅＢ）に属するセル、すなわち同一ｅＮｏｄｅＢ  ＩＤを持つセルを抽出する。図１５はＥＣＧＩとｅＮｏｄｅＢ  ＩＤの関係を示す図である。図１５に示すように、ＥＣＧＩは、ＭＣＣ（Ｍｏｂｉｌｅ  Ｃｏｕｎｔｒｙ  Ｃｏｄｅ）およびＭＮＣ（Ｍｏｂｉｌｅ  Ｎｅｔｗｏｒｋ  Ｃｏｄｅ）からなるＰＬＭＮ  ＩＤ（Ｐｕｂｌｉｃ  Ｌａｎｄ  Ｍｏｂｉｌｅ  Ｎｅｔｗｏｒｋ  Ｉｄｅｎｔｉｆｉｅｒ）、Ｃ−ＲＡＮやｅＮｏｄｅＢの識別子であるｅＮｏｄｅＢ  ＩＤ、Ｃ−ＲＡＮやｅＮｏｄｅＢ管理下のセルの識別子であるＣｅｌｌ  Ｉｄｅｎｔｉｔｙを含んでいる。そのため、トラフィック管理サーバはセルが同一ｅＮｏｄｅＢ  ＩＤを持つことを、ＥＣＧＩから判定することができる。次に、トラフィック管理サーバはステップ１４０２において、ステップ１４０１で抽出した同一ｅＮｏｄｅＢ  ＩＤを持つセルについて、セル位置情報テーブル１１１４を用いてセル間距離を計算し、セル間距離が閾値以下のものを同一のセルクラスタとしてグルーピングする。この方法では、セルの位置情報を用いることにより、地理的に近接するセルを正確にセルクラスタとしてグルーピングすることができる。セル間距離の閾値をセルカバレッジ（あるいはセル送信電力）に応じて決定することにより、さらに精度の高いセルクラスタ作成が可能である。
【００６０】
トラフィック管理サーバが、Ｃ−ＲＡＮの保守管理装置であるＥＭＳから取得した情報を用いてセルクラスタ情報テーブル１１０３を作成する別の方法として、セルの隣接関係を含むネイバー関係テーブル（ＮＲＴ：Ｎｅｉｇｈｂｏｒ  Ｒｅｌａｔｉｏｎ  Ｔａｂｌｅ）を用いる方法を、図１６および図１７を用いて説明する。図１６はトラフィック管理サーバがＥＭＳから取得するＮＲＴ１１１５の一例である。ＮＲＴ１１１５はあるセル（ＥＣＧＩ＝ｎとする）に関して、ＥＣＧＩ＝ｎのセルと隣接するセルのリストである。ＮＲＴ１１１５は、少なくともＥＣＧＩを含む。さらにＮＲＴ１１１５は、無線リンクで使用されるセル識別子であるＰＣＩ（Ｐｈｙｓｉｃａｌ  Ｃｅｌｌ  Ｉｎｄｅｎｔｙ）、無線周波数チャネルのチャネル番号であるＥＡＲＦＣＮ（Ｅ−ＵＴＲＡ  Ａｂｓｏｌｕｔｅ  Ｒａｄｉｏ  Ｆｒｅｑｕｅｎｃｙ  Ｃｈａｎｎｅｌ  Ｎｕｍｂｅｒ）を含んでもよい。トラフィック管理サーバは、ＮＲＴ１１１５をＥＣＧＩごとに保持する。図１７はＮＲＴを用いてトラフィック管理サーバが行うセルクラスタ作成処理１１０５のフロー図である。図１７で、トラフィック管理サーバはステップ１７０１において、あるセル（ＥＣＧＩ＝ｎとする）のＮＲＴに、ＥＣＧＩ＝ｎと同一のｅＮｏｄｅＢ  ＩＤを持つセルがあるか否かを判定する。図１４の手順ですでに説明したように、トラフィック管理サーバはセルが同一ｅＮｏｄｅＢ  ＩＤを持つことを、ＥＣＧＩから判定することができる。ＥＣＧＩ＝ｎのＮＲＴにＥＣＧＩ＝ｎのセルと同一のｅＮｏｄｅＢ  ＩＤを持つセルがある場合（ステップ１７０１のＹｅｓ）、トラフィック管理サーバはステップ１７０２において、ＥＣＧＩ＝ｎのセルと、ＥＣＧＩ＝ｎのセルと同一のｅＮｏｄｅＢ  ＩＤを持つ全てのセルを、同一のセルクラスタ（セルクラスタＸとする）としてグルーピングする。ＥＣＧＩ＝ｎのＮＲＴにＥＣＧＩ＝ｎのセルと同一のｅＮｏｄｅＢ  ＩＤを持つセルがない場合（ステップ１７０１のＮｏ）、トラフィック管理サーバはステップ１７０３において、ＥＣＧＩ＝ｎのセルのみをメンバとするセルクラスタ（セルクラスタＸとする）を作成する。次に、トラフィック管理サーバはステップ１７０４において、セルクラスタＸのメンバであるセルに、既に作成済みのセルクラスタＹにも含まれるものがあるか否かを判定する。セルクラスタＸのメンバであるセルに、既に作成済みのセルクラスタＹにも含まれるものがある場合（ステップ１７０４のＹｅｓ）、トラフィック管理サーバはステップ１７０５において、セルクラスタＸとセルクラスタＹをマージする。トラフィック管理サーバは、Ｃ−ＲＡＮ管理下の全てのＥＣＧＩについてこれらの処理を行う。この方法では、トラフィック管理サーバがＥＭＳからセル位置の情報を取得することなく、セルクラスタ作成が可能である。
【００６１】
トラフィック管理サーバが、プローブ装置から取得した情報を用いてセルクラスタ情報テーブル１１０３を作成する方法として、端末のハンドオーバ履歴を用いる方法を説明する。まず、トラフィック管理サーバが端末のハンドオーバ履歴情報を取得する方法を、図１８、図１９を用いて説明する。図１８は、ＵＥがハンドオーバする際に発生するシグナリングから、トラフィック管理サーバが端末のハンドオーバ履歴情報を取得する手順を説明するシーケンス図である。図１８で、シーケンス１８０１においてハンドオーバが起動される。ソース（ハンドオーバ元）ＲＡＮ（Ｃ−ＲＡＮまたはｅＮｏｄｅＢ）はシーケンス１８０２で、Ｈａｎｄｏｖｅｒ  ＲｅｑｕｉｒｅｄメッセージをＭＭＥに送信する。このとき、プローブ装置は、Ｈａｎｄｏｖｅｒ  Ｒｅｑｕｉｒｅｄメッセージを取得し、この情報をトラフィック管理サーバへ渡す。トラフィック管理サーバは、プローブ装置より取得したＨａｎｄｏｖｅｒ  Ｒｅｑｕｉｒｅｄメッセージの情報を使用して、シーケンス１８０３でセルクラスタ作成処理を行う。ＭＭＥはＨａｎｄｏｖｅｒ  Ｒｅｑｕｅｓｔメッセージをターゲット（ハンドオーバ元）ＲＡＮ（Ｃ−ＲＡＮまたはｅＮｏｄｅＢ）に送信し（シーケンス１８０４）、ターゲットＲＡＮはＨａｎｄｏｖｅｒ  Ｒｅｑｕｅｓｔ  Ａｃｋｎｏｗｌｅｄｇｅメッセージを送信する（シーケンス１８０５）。ＭＭＥは、Ｈａｎｄｏｖｅｒ  ＣｏｍｍａｎｄメッセージをソースＲＡＮに送信する（シーケンス１８０６）。その後、シーケンス１８０７のＨａｎｄｏｖｅｒ  Ｅｘｅｃｕｔｉｏｎプロシージャにおいて、ＵＥが接続先をソースＲＡＮからターゲットＲＡＮへ切り替え、ソースＲＡＮからターゲットＲＡＮへのデータ転送が行われる。さらに、シーケンス１８０８のＨａｎｄｏｖｅｒ  Ｃｏｍｐｌｅｔｉｏｎプロシージャにおいて、トラフィックを転送するためのベアラの切替えが行われる。
【００６２】
トラフィック管理サーバは、プローブ装置より取得したＨａｎｄｏｖｅｒ  Ｒｅｑｕｉｒｅｄメッセージから、端末のハンドオーバ履歴を抽出し、ハンドオーバ履歴テーブルとして保持する。なお、ハンドオーバの履歴情報は、同一Ｃ−ＲＡＮ内ハンドオーバも含めてUEの接続先セルが変わる都度、基地局が更新して保持しておき、Ｈａｎｄｏｖｅｒ  Ｒｅｑｕｉｒｅｄメッセージに含めて送信される。
【００６３】
図１９は、トラフィック管理サーバが保持するハンドオーバ履歴テーブル１１１６である。ハンドオーバ履歴テーブル１１１６は、ＵＥが過去に滞在したセルの情報を端末が滞在した順に含む。図１９の例では、先頭行のセルが、端末が最も直近に滞在したセルである。すなわち、ハンドオーバ履歴テーブル１１１６において隣り合う行のセルは、地理的に近接すると推定される。ハンドオーバ履歴テーブル１１１６のセル情報は、少なくともＥＣＧＩを含む。さらに、ハンドオーバ履歴テーブル１１１６のセル情報は、セルタイプ（Ｃｅｌｌ  Ｔｙｐｅ）や滞在時間（Ｔｉｍｅ  ｏｆ  Ｓｔａｙ）を含んでもよい。トラフィック管理サーバは、例えば、ＵＥごと、あるいはＨａｎｄｏｖｅｒ  Ｒｅｑｕｉｒｅｄメッセージごとに、ハンドオーバ履歴情報を保持する。以下の説明では、トラフィック管理サーバは、ＵＥごとに、ハンドオーバ履歴情報を保持するものとする。
【００６４】
次に、図２０を用いて、トラフィック管理サーバが端末のハンドオーバ履歴情報を用いてセルクラスタ情報テーブル１１０３を作成する方法を説明する。図２０は端末のハンドオーバ履歴を用いてトラフィック管理サーバが行うセルクラスタ作成処理プログラム１１０５により実行されるセルクラスタ作成処理のフロー図である。図２０で、トラフィック管理サーバはステップ２００１において、ＵＥ＝ｍのハンドオーバ履歴テーブルのｉ行目のセルとｉ＋１行目のセルが、同一のｅＮｏｄｅＢ  ＩＤであるか否かを判定する。図１４の手順ですでに説明したように、トラフィック管理サーバはセルが同一ｅＮｏｄｅＢ  ＩＤを持つことを、ＥＣＧＩから判定することができる。ＵＥ＝ｍのハンドオーバ履歴テーブルのｉ行目のセルとｉ＋１行目のセルが、同一のｅＮｏｄｅＢ  ＩＤである場合（ステップ２００１のＹｅｓ）、トラフィック管理サーバはｉ行目のセルとｉ＋１行目のセルを同一のセルクラスタとしてグルーピングする。ＵＥ＝ｍのハンドオーバ履歴テーブルのｉ行目のセルとｉ＋１行目のセルが、同一のｅＮｏｄｅＢ  ＩＤでない場合（ステップ２００１のＮｏ）、トラフィック管理サーバはｉ行目のセルのみからなるセルクラスタを作成する。トラフィック管理サーバは、ＵＥ＝ｍのハンドオーバ履歴テーブルの全ての行に対してこれらの処理を行う。そして、トラフィック管理サーバはステップ２００４において、セルクラスタＡのメンバであるセルに、別のセルクラスタＢにも含まれるものがあるか否かを判定する。セルクラスタＡのメンバであるセルに、別のセルクラスタＢにも含まれるものがある場合（ステップ２００４のＹｅｓ）、トラフィック管理サーバはステップ２００５において、セルクラスタＡとセルクラスタＢをマージする。トラフィック管理サーバは、Ｃ−ＲＡＮが管理する全てのＵＥのハンドオーバ履歴テーブルについてこれらの処理を行う。この方法では、トラフィック管理サーバがＥＭＳから情報を取得することなく、セルクラスタ作成が可能である。この方法では、ＲＡＮとＭＭＥ間のＳ１−ＭＭＥインタフェースのシグナリングを取得する必要があるものの、比較的高い精度でセルクラスタ作成が可能である。
【００６５】
なお、図２０の例では、ハンドオーバ履歴テーブルにおいて同一のｅＮｏｄｅＢ  ＩＤを持つセルが隣り合う場合、これらのセルが必ず同一セルクラスタとしてグルーピングされるが、ハンドオーバ履歴テーブルにおいて同一のｅＮｏｄｅＢ  ＩＤを持つセルが隣り合う頻度に基づいてセルクラスタのグルーピングを行ってもよい。例えば、同一のｅＮｏｄｅＢ  ＩＤを持つセルの対がハンドオーバ履歴テーブルにおいて隣り合う回数をカウントし、隣り合う回数が閾値以上となるセルの対を、同一セルクラスタに属すると判定してもよい。
【００６６】
また、図２０の例では、トラフィック管理サーバは、全てのＵＥのハンドオーバ履歴テーブルを用いるものとしたが、いくつかのＵＥのハンドオーバ履歴テーブルを用いるものとしてもよい。
【００６７】
トラフィック管理サーバが、プローブ装置から取得した情報を用いてセルクラスタ情報テーブル１１０３を作成する方法として、Ｃ−ＲＡＮとｅＮｏｄｅＢ間の端末の移動回数を用いる方法を、図２１と図２２を用いて説明する。図２１はＣ−ＲＡＮとｅＮｏｄｅＢ間の端末の移動回数を用いてトラフィック管理サーバが行うセルクラスタ作成処理プログラム１１０５により実行されるセルクラスタ作成処理のフロー図である。図２２は、トラフィック管理サーバが保持するモビリティカウントテーブル１１１７である。
【００６８】
図２１で、トラフィック管理サーバはステップ２１０１において、後述のモビリティカウント処理を行う。モビリティカウント処理の結果、図２２のモビリティカウントテーブル１１１７が作成される。モビリティカウントテーブル１１１７は、Ｃ−ＲＡＮ管理下の各ＥＣＧＩ（Ｃ-ＲＡＮ  ＥＣＧＩ）について、各ｅＮｏｄｅＢ(ｅＮｏｄｅＢ  ＩＤ  ｏｆ  ｅＮｏｄｅＢ)から当該ＥＣＧＩへのユーザ移動の検出回数（モビリティ回数）を格納している。トラフィック管理サーバはステップ２１０２において、Ｃ−ＲＡＮ管理下の各ＥＣＧＩについて、最もモビリティ回数の多いｅＮｏｄｅＢを最頻ｅＮｏｄｅＢとして判定する。例えば、図２２の例では、１行目のＣ−ＲＡＮ  ＥＣＧＩ＝４４１００  ０００００００００００００００００００１  ００１の最頻ｅＮｏｄｅＢは、１列目のｅＮｏｄｅＢ  ＩＤ＝００００００００００００００００００３０である（５６０回）。その後、トラフィック管理サーバはステップ２１０３において、Ｃ−ＲＡＮ管理下のＥＣＧＩのうち、ＥＣＧＩのｅＮｏｄｅＢ  ＩＤが同一であり、かつ、ステップ２１０２で決定した最頻ｅＮｏｄｅＢが同一であるものを、同一セルクラスタとしてグルーピングする。図２２の例では、１行目のＣ−ＲＡＮ  ＥＣＧＩ＝４４１００  ０００００００００００００００００００１  ００１と２行目のＣ−ＲＡＮ  ＥＣＧＩ＝４４１００  ０００００００００００００００００００１  ００２は、ｅＮｏｄｅＢ  ＩＤが同一であり（ｅＮｏｄｅＢ  ＩＤ＝０００００００００００００００００００１）、かつ、最頻ｅＮｏｄｅＢが同一である（１列目のｅＮｏｄｅＢ  ＩＤ＝００００００００００００００００００３０）から、これら２つのＣ−ＲＡＮ  ＥＣＧＩは同一のセルクラスタとしてグルーピングされる。一方、４行目のＣ−ＲＡＮ  ＥＣＧＩ＝４４１００  ０００００００００００００００００００２  ００１は、１行目および２行目のＣ−ＲＡＮ  ＥＣＧＩと最頻ｅＮｏｄｅＢは同一であるものの、Ｃ−ＲＡＮ  ＥＣＧＩに含まれるｅＮｏｄｅＢ  ＩＤが異なるため、同一のセルクラスタとはならない。
【００６９】
ステップ２１０１において行われる、モビリティカウント処理を図２３を用いて説明する。すでに説明したように、トラフィック管理サーバが同一Ｃ−ＲＡＮ（あるいはｅＮｏｄｅＢ）内のユーザの移動を捕捉することは困難であるが、トラフィック管理サーバは異なるＣ−ＲＡＮ（あるいはｅＮｏｄｅＢ）間や、Ｃ−ＲＡＮとｅＮｏｄｅＢ間のユーザの移動を検出することは容易である。ユーザ移動の検出は、異なるＣ−ＲＡＮ（あるいはｅＮｏｄｅＢ）間や、Ｃ−ＲＡＮとｅＮｏｄｅＢ間の際に、コアネットワークのシグナリングをプローブ装置を通じて取得することによって実現される。その具体的な方法は第１の実施例で説明されており、さらなる詳細は図３および図５の説明で明示されている。モビリティカウント処理は、図５の処理にカウントを行うステップを追加することによって実現される。図２３は、トラフィック管理サーバが行うモビリティカウント処理のフロー図である。ステップ２３０１からステップ２３０３、およびステップ２３１１からステップ２３１２は、Ｓ１−Ｕ  Ｆ−ＴＥＩＤの格納を行うか否かを除けば、図５のステップ５０１からステップ５０３、およびステップ５１１からステップ５１２と同一であるから、説明は省略する。図５で行われるＳ１−Ｕ  Ｆ−ＴＥＩＤの格納は、Ｓ１−Ｕインタフェース上のトラフィックのユーザ識別のために行うものであり、図２３におけるモビリティカウント処理には不要である。トラフィック管理サーバはステップ２３１３において、ステップ２３１２の更新前のＥＣＧＩから抽出したｅＮｏｄｅＢ  ＩＤと、ステップ２３１２の更新後のＣ−ＲＡＮ  ＥＣＧＩとの間のユーザ移動としてカウントする。
【００７０】
この方法では、トラフィック管理サーバがＥＭＳから情報を取得することなく、セルクラスタ作成が可能である。この方法では、Ｃ−ＲＡＮ管理下のセルを、最も近接するｅＮｏｄｅＢごとにセルクラスタとして分類する。この方法では、トラフィック管理サーバはＳ１１インタフェースのシグナリングのみでユーザ在圏位置を把握するため、Ｓ１−ＭＭＥインタフェースのシグナリングの取得は不要である。
【００７１】
トラフィック管理サーバが、セルクラスタ単位で輻輳状態およびユーザの在圏位置を管理する手順は、図３で説明した、第１の実施例における手順と同一であるから、説明を省略する。第１の実施例との違いは、図３のシーケンス３０５およびシーケンス３２３で行われるユーザ在圏情報更新処理と、シーケンス３１２およびシーケンス３３２で行われる輻輳指標更新処理であり、これらは後述される。
【００７２】
図２４は、ユーザ在圏情報や輻輳指標からなるユーザエントリを格納するための、ユーザ情報テーブル１１１１である。ユーザエントリは、ＩＭＳＩ、セルクラスタＩＤ、Ｓ１１  Ｆ−ＴＥＩＤ、Ｓ１−Ｕ  Ｆ−ＴＥＩＤ、輻輳指標からなる。Ｓ１１  Ｆ−ＴＥＩＤは、ＩＰアドレスとＳ１１トンネルの識別子であるＴＥＩＤからなる。Ｓ１−Ｕ  Ｆ−ＴＥＩＤは、ＩＰアドレスとＳ１−Ｕトンネルの識別子であるＴＥＩＤからなる。輻輳指標は、図２４の例ではトラフィック量である。
【００７３】
図２５を用いて、本実施例におけるユーザ在圏情報更新処理を説明する。図２５は、トラフィック管理サーバが行うユーザ在圏情報更新処理１１０１の手順を示すフロー図である。ステップ２５０１において、トラフィック管理サーバは、プローブ装置より取得したメッセージが、Ｃｒｅａｔｅ  Ｓｅｓｓｉｏｎ  ＲｅｑｕｅｓｔメッセージかＭｏｄｉｆｙ  Ｂｅａｒｅｒ  Ｒｅｑｕｅｓｔメッセージかを判定する。プローブ装置より取得したメッセージがＣｒｅａｔｅ  Ｓｅｓｓｉｏｎ  Ｒｅｑｕｅｓｔメッセージの場合、トラフィック管理サーバはステップ２５０２において、Ｃｒｅａｔｅ  Ｓｅｓｓｉｏｎ  Ｒｅｑｕｅｓｔメッセージから、ユニークなユーザ識別子であるＩＭＳＩ、セル識別子であるＥＣＧＩ、Ｓ１１インタフェースにおけるユーザ識別子であるＳ１１  Ｆ−ＴＥＩＤ、Ｓ１−Ｕインタフェースにおけるユーザ識別子であるＳ１−Ｕ  Ｆ−ＴＥＩＤ、を抽出する。続いて、トラフィック管理サーバはステップ２５０３において、抽出したＩＭＳＩ、セルクラスタＩＤ、Ｓ１１  Ｆ−ＴＥＩＤ、Ｓ１−Ｕ  Ｆ−ＴＥＩＤをユーザ情報テーブル１１１１に、新規ユーザエントリとして格納する。セルクラスタＩＤは、セルクラスタ情報テーブル１１１３を参照して、ステップ２５０２で抽出したＥＣＧＩを変換することにより得られる。
【００７４】
一方、ステップ２５０１において、プローブ装置より取得したメッセージがＭｏｄｉｆｙ  Ｂｅａｒｅｒ  Ｒｅｑｕｅｓｔメッセージの場合、トラフィック管理サーバはステップ５１１において、Ｍｏｄｉｆｙ  Ｂｅａｒｅｒ  ＲｅｑｕｅｓｔメッセージからＥＣＧＩ、Ｓ１１  Ｆ−ＴＥＩＤを抽出する（ステップ２５１１）。続いて、トラフィック管理サーバはステップ５１２において、ユーザ情報テーブル１１１１のユーザエントリのうち、ステップ２５１１で抽出したＳ１１  Ｆ−ＴＥＩＤと同一のＳ１１  Ｆ−ＴＥＩＤを持つエントリに対し、セルクラスタＩＤをステップ５１１で抽出したものに更新する。セルクラスタＩＤは、セルクラスタ情報テーブル１１１３を参照して、ステップ２５１１で抽出したＥＣＧＩを変換することにより得られる。このように、異なるＣ−ＲＡＮ間や、Ｃ−ＲＡＮとｅＮｏｄｅＢ間の移動、ＵＥの再アクティブ化に伴うＭｏｄｉｆｙ  Ｂｅａｒｅｒ  Ｒｅｑｕｅｓｔメッセージから、ＥＣＧＩを抽出し、セルクラスタＩＤに変換して更新する。これにより、セルクラスタ単位でユーザの在圏位置を管理することが可能となる。
【００７５】
図２６を用いて、本実施例における輻輳指標更新処理を説明する。図２６は、トラフィック管理サーバが行う輻輳指標更新処理プログラム１１０２により実行される輻輳指標更新処理の手順を示すフロー図である。トラフィック管理サーバはステップ２６０１で、プローブ装置からＳ１−Ｕ  ＴＥＩＤとトラフィック量計測結果を取得する。トラフィック管理サーバはステップ２６０２で、ユーザ情報テーブル１１１１のユーザエントリのうち、ステップ２６０１で抽出したＳ１−Ｕ  Ｆ−ＴＥＩＤと同一のＳ１−Ｕ  Ｆ−ＴＥＩＤを持つエントリに対し、輻輳指標をステップ２６０１で取得したトラフィック量計測結果に更新する。さらに、トラフィック管理サーバはステップ２６０３で、ユーザ情報テーブル１１１１のユーザエントリのうち同一のセルクラスタＩＤを持つエントリの輻輳指標を集計し、集計結果を輻輳指標テーブル１１１２に格納する。
【００７６】
図２７は、輻輳指標テーブル１１１２である。輻輳指標テーブルは、セルクラスタＩＤ（Ｃｅｌｌ  Ｃｌｕｓｔｅｒ  ＩＤ）ごとに、セルクラスタに含まれるセル数（Ｎｕｍｂｅｒ  ｏｆ  Ｃｅｌｌｓ）、輻輳指標集計結果、輻輳状態を保持する。
【００７７】
次に、図２８を用いて、トラフィック管理サーバが、セルクラスタ単位で輻輳発生を判定する手順を説明する。図２８は、トラフィック管理サーバが行う輻輳判定処理プログラム１１０３により実行される輻輳判定処理の手順を示すフロー図である。トラフィック管理サーバは、ステップ２８０１において、輻輳指標テーブル１１１２に格納されているセルクラスタの輻輳指標集計結果が、閾値を超えているか否かを判定する。なお、ステップ２８０１で使用する閾値は、例えば、ネットワーク管理者が予め設定しておいてもよいし、トラフィック管理サーバが設定してもよい。また、ステップ２８０１で使用する閾値は、セルクラスタごとに、セルクラスタに含まれるセル数に応じて設定してもよい。例えば、セルクラスタに含まれるセル数が１の場合の閾値をＴｈ１とすると、セルクラスタに含まれるセル数がＮの場合の閾値をＴｈ１のＮ倍に設定すればよい。これにより、セルクラスタに含まれるセル数に応じて柔軟に、輻輳判定が可能となる。セルクラスタの輻輳指標集計結果が閾値を超えている場合（ステップ２８０１のＹｅｓ）、トラフィック管理サーバはステップ２８０２において、そのセルクラスタが輻輳していると判定し、輻輳指標テーブル１１１２における当該セルの輻輳状態を、“輻輳”とする。セルの輻輳指標集計結果が閾値を超えていない場合（ステップ２８０１のＮｏ）、トラフィック管理サーバはステップ２８１１において、そのセルが輻輳していないと判定し、輻輳指標テーブル１１１２における当該セルの輻輳状態を、“非輻輳”とする。これらの処理は、輻輳指標テーブル１１１２で管理される各セルについて行われる。なお、輻輳指標テーブル１１１２は、最新の輻輳判定結果と、前回の輻輳判定結果を保持する。輻輳発生の判定は、例えば一定の時間周期で行えばよい。
【００７８】
図２９を用いて、トラフィック管理サーバが、輻輳が発生しているセルに在圏する端末を特定し、特定された端末の最大利用可能帯域幅を制限するようセルラ通信システムを構成する制御装置へ指示する手順を説明する。図２９は、トラフィック管理サーバが行う帯域制限指示処理プログラム１１０４により実行される帯域制限指示処理の手順を示すフロー図である。トラフィック管理サーバはステップ２９０１において、輻輳指標テーブル１１１２の最新の輻輳状態と前回判定時の輻輳状態を参照し、輻輳状態が“非輻輳”から“輻輳”になったセルクラスタを抽出する。次にトラフィック管理サーバはステップ２９０２において、ユーザ情報テーブル１１１１を参照し、ステップ２９０１で抽出したセルクラスタ（輻輳状態になったセルクラスタ）に在圏するユーザ（ＩＭＳＩ）を抽出する。トラフィック管理サーバはステップ２９０３において、ステップ２９０２で抽出したユーザ（ＩＭＳＩ）への帯域制限の適用を、Ｐ−ＧＷに指示する。帯域制限の適用は、例えば、ユーザに許容される最大ビットレートを設定することによって行う。あるいは、非輻輳時にも最大ビットレートが設定される場合は、より小さい値の最大ビットレートを設定することによって、帯域制限を行う。さらに、トラフィック管理サーバはステップ２９０４において、輻輳指標テーブル１１１２の最新の輻輳状態と前回判定時の輻輳状態を参照し、輻輳状態が“輻輳”から“非輻輳”になったセルクラスタを抽出する。次にトラフィック管理サーバはステップ２９０５において、ユーザ情報テーブル２１１を参照し、ステップ２９０４で抽出したセル（非輻輳状態になったセルクラスタ）に在圏するユーザ（ＩＭＳＩ）を抽出する。トラフィック管理サーバはステップ２９０６において、ステップ２９０５で抽出したユーザ（ＩＭＳＩ）への帯域制限の解除を、Ｐ−ＧＷに指示する。
【００７９】
上記の説明では、トラフィック管理サーバがメッセージから情報要素を抽出したが、プローブ装置がこれを行った上、プローブ装置が抽出された情報をトラフィック管理サーバへ渡してもよい。
【００８０】
また、上記の説明では、輻輳指標として下り方向のトラフィック量を用いたが、別の指標を用いてもよい。例えば、輻輳指標として、伝送遅延量、データレート、接続ユーザ数を用いてもよい。伝送遅延量、データレート、接続ユーザ数は、例えばプローブ装置がＳ１−Ｕインタフェース上のトラフィックをモニタリングすることにより取得することが可能である。あるいは、輻輳指標として、上り方向のトラフィックに関わる情報を用いてもよい。
【００８１】
また、上記の説明では、輻輳状態を“輻輳”と“非輻輳”の２種類としたが、３種類以上の輻輳状態を定義することもできる。３種類以上の輻輳状態を定義することにより、セルの輻輳度合いに応じて、後段の帯域制限において異なる上限値を使用することができる。例えば、輻輳度合いが軽い場合の、ユーザに許容される最大ビットレートを、輻輳度合いが重い場合の、ユーザに許容される最大ビットレートより、大きい値に設定する。これにより、輻輳状態の変動に伴う最大ビットレートの変化を緩やかにし、帯域制限によるユーザサービスへの影響を抑制することができる。
【００８２】
また、上記の説明では、輻輳しているセルクラスタに在圏する全ユーザへ帯域制限を適用するが、一部のユーザに対してのみ帯域制限を適用してもよい。例えば、優遇したいユーザを予めトラフィック管理装置に登録しておき、トラフィック管理装置が、優遇したいユーザを帯域制限の対象外としてもよい。あるいは、帯域制限を行いたい特定のトラフィック種別を予めトラフィック管理装置に登録しておき、トラフィック管理装置が、特定のトラフィック種別の送受信を行っているユーザのみを帯域制限の対象としてもよい。
【００８３】
第１の実施例で説明したようなセルごとのユーザ在圏情報管理、輻輳判定、帯域制限は、例えば図１のようなセル配置に対して特に効果的であることはすでに説明した通りである。一方、すでに説明したように、同一Ｃ−ＲＡＮ内のユーザ移動をトラフィック管理サーバが捕捉することは困難である。例えば、図３０のように、Ｃ−ＲＡＮ管理下のセル１２２が近接して配置される場合、Ｃ−ＲＡＮ内のユーザ移動が多く発生するため、第１の実施例を適用すると、実際に輻輳しているセルとは異なるセルに対して帯域制限が行われることがあり、帯域制限を行ったにも関わらず輻輳が解消されない場合がある。本実施例のように、セルクラスタごとのユーザ在圏情報管理、輻輳判定、帯域制限を行うことにより、図３０のようなセル配置でも、実際に輻輳しているセルクラスタに対して帯域制限を行うことができ、効果的な輻輳制御が可能となる。
【符号の説明】
【００８４】
１０１  ユーザ端末（ＵＥ：Ｕｓｅｒ  Ｅｑｕｉｐｍｅｎｔ）
１１１  基地局（ｅＮｏｄｅＢ：Ｅ−ＵＴＲＡＮ  ＮｏｄeＢ）
１１２  ｅＮｏｄｅＢ管理下のセル
１２１  ＲＲＨ（Ｒｅｍｏｔｅ  Ｒａｄｉｏ  Ｈｅａｄ）
１２２  Ｃ−ＲＡＮ管理下のセル
１２３  光ファイバ
１２４  ＢＢＵ（Ｂａｓｅｂａｎｄ  Ｕｎｉｔ）
１２５  ＥＭＳ
１３１  Ｓ−ＧＷ（Ｓｅｒｖｉｎｇ  Ｇａｔｅｗａｙ）
１３２  ＭＭＥ（Ｍｏｂｉｌｉｔｙ  Ｍａｎａｇｅｍｅｎｔ  Ｅｎｔｉｔｙ
１３３  Ｐ−ＧＷ（ＰＤＮ  Ｇａｔeｗａｙ）
１３４  ＰＤＮ（Ｐａｃｋｅｔ  Ｄａｔａ  Ｎｅｔｗｏｒｋ）
１４１  プローブ装置
１４２  トラフィック管理サーバ
【図１】
2015220559.tif 000003
【図２】
2015220559.tif 000004
【図３】
2015220559.tif 000005
【図４】
2015220559.tif 000006
【図５】
2015220559.tif 000007
【図６】
2015220559.tif 000008
【図７】
2015220559.tif 000009
【図８】
2015220559.tif 000010
【図９】
2015220559.tif 000011
【図１０】
2015220559.tif 000012
【図１１】
2015220559.tif 000013
【図１２】
2015220559.tif 000014
【図１３】
2015220559.tif 000015
【図１４】
2015220559.tif 000016
【図１５】
2015220559.tif 000017
【図１６】
2015220559.tif 000018
【図１７】
2015220559.tif 000019
【図１８】
2015220559.tif 000020
【図１９】
2015220559.tif 000021
【図２０】
2015220559.tif 000022
【図２１】
2015220559.tif 000023
【図２２】
2015220559.tif 000024
【図２３】
2015220559.tif 000025
【図２４】
2015220559.tif 000026
【図２５】
2015220559.tif 000027
【図２６】
2015220559.tif 000028
【図２７】
2015220559.tif 000029
【図２８】
2015220559.tif 000030
【図２９】
2015220559.tif 000031
【図３０】
2015220559.tif 000032