JP2015149577A - 帯域制御装置 - Google Patents

Abstract

【課題】通信量の急増に応じて、システムダウンを招かずに中継処理サーバの増設を実現すること、中継処理サーバの増設の最中でも優先ユーザに対して品質の良い通信を提供し続けること、中継処理サーバの増減設を繰り返してもシステムダウンを招かず優先ユーザに対して品質の良い通信を提供し続けることが課題である。【解決手段】サーバ装置に備えられた複数の仮想ノードへパケットを送信する帯域制御装置であって、複数の高優先キューおよび複数の低優先キューと、仮想ノード毎に備えられ、複数の高優先キューおよび低優先キューの中で自身に対応付けられた高優先キューおよび低優先キューからパケットを読み出して仮想ノード毎に定められた上限帯域に制限する仮想ノード用帯域制限部と、を有し、仮想ノードの増減設を判断する前記制御サーバから指示に基づき、高優先キューおよび低優先キューと仮想ノード用帯域制限部との対応付けを変更する帯域制御装置。【選択図】 図２

Description

本発明は、通信システム、特に帯域制御装置に関する。

近年、スマートフォンやタブレット端末が急速に普及した結果、モバイルトラフィックが急激に増加している。通信キャリアは、これらのトラフィック量を事前に予測し、必要となるネットワーク装置をモバイルコア網の通信ノード（ＭＭＥ（Ｍｏｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ Ｅｎｔｉｔｙ）、Ｓ−ＧＷ（Ｓｅｒｖｉｎｇ ＧａｔｅＷａｙ）、Ｐ−ＧＷ（Ｐｕｂｌｉｃ Ｄａｔａ Ｎｅｔｗｏｒｋ ＧａｔｅＷａｙ）等）として準備する必要がある。

通常、それらのネットワーク装置は、専用ハードウェアで構成されており、調達期間が数ヶ月単位と長い、また、設計や設定・運用性の柔軟性が低い、設備コストが高い、といった課題を抱えている。こうした課題を受け、これらの専用ハードウェアに代わって、汎用サーバに仮想化技術を導入して課題の解決を図ろうとするネットワーク機能仮想化（ＮＦＶ：Ｎｅｔｗｏｒｋ Ｆｕｎｃｔｉｏｎｓ Ｖｉｒｔｕａｌｉｚａｔｉｏｎ）の概念が、ＥＴＳＩ Ｉｎｄｕｓｔｒｙ Ｓｐｅｃｉｆｉｃａｔｉｏｎ Ｇｒｏｕｐにより２０１２年１１月に提唱された。ＮＦＶの概念を用いると、モバイルコア網の通信ノード（ＭＭＥ、Ｓ−ＧＷ、Ｐ−ＧＷ等）を汎用サーバ上の仮想マシンで実現し、通信変動量に応じて中継処理を行う通信ノードを自動的に増減設することが可能となる。

一方で、ノードを自動増設する際、増設が完了するまでには早くても数秒から数分の時間が最低限必要であり、増設が完了する前に大量の通信を受け続ける場合、仮想マシンを稼動させるＯＳやファームウェアなどが過負荷状況となり、システムがダウンしてしまう恐れがある。

また、本システムを利用しているユーザの通信は、他のユーザの通信が大量に増加する場合、通信ノードの増設が完了するまでに大量のパケットロスが生じてしまう。これは、追加料金を払ってでも品質の良い通信を望むユーザにとっては問題である。

通信変動に応じてシステム中のサーバを増設して過負荷を避けるという観点では、特許文献１において、「クラウド環境において、需要変化に応答してサーバ規模を増減させるオートスケーリング機構を実現する情報処理システム、情報処理装置、スケーリング方法、プログラムおよび記録媒体を提供すること。」が課題として記載されている。その解決手段として、「本情報処理システムは、複数の処理サーバを含む処理サーバ群と、処理サーバ群に代替して応答するための代替サーバと、処理サーバ群にトラフィックを分散するとともに、上記処理サーバ群が過負荷状態となった際に代替サーバにトラフィックを転送するロードバランサとを含む。本情報処理システムは、さらに、上記ロードバランサにより処理サーバ群へ転送される転送量と上記代替サーバへ転送される転送量とに応じて、処理サーバ群の目標規模を演算し、処理サーバ群の現在の規模から目標規模へ増強するため処理サーバ群の処理サーバを準備する。」と記載されている。

特開２０１２−２０８７８１号公報

特許文献１に記載された技術では、ウェブサーバが過負荷になった際に、新規の接続要求を代替サーバへ転送し、その間にウェブサーバの増設を行うことで、ウェブサーバを過剰接続によるダウンから保護している。しかしながら、一般的なモバイル通信を中継処理するサーバへ特許文献１の技術を適用した場合、ユーザが一斉にテキスト参照をやめて、動画参照などの大量のデータ通信を行う状況では、中継サーバにとっては新規接続要求とはならないため、代替サーバへの転送は行われない。その結果、中継サーバの負荷が増えるため、中継サーバの過負荷状態を避けることができず、増設（スケールアウト）完了までにシステムダウンを引き起こしうる。換言すれば、通信量の急増に応じて、システムダウンを招かずに中継処理サーバの増設（スケールアウト）を実現することが課題である。

また、中継処理サーバの増設（スケールアウト）の最中でも、優先ユーザに対して、品質の良い通信を提供し続けることが課題である。

また、中継処理サーバの増減設を繰り返しても、システムダウンを招かず、優先ユーザに対して品質の良い通信を提供し続けることが課題である。

本発明は、上記課題のうち少なくとも一つを解決するための手段を複数含んでいるが、その一例を挙げるならば、
「サーバ装置に備えられた複数の仮想ノードへパケットを送信する帯域制御装置であって、前記帯域制御装置の制御をおこなう制御部と、前記パケットを保持するキューを制御するバッファ部と、を有し、前記バッファ部は、高優先のパケットを保持し、パケット送信量を所定の保証帯域で保証する複数の高優先キューと、低優先のパケットを保持する複数の低優先キューと、前記仮想ノード毎に備えられ、複数の前記高優先キューおよび前記低優先キューの中で自身に対応付けられた高優先キューおよび低優先キューからパケットを読み出して前記仮想ノード毎に定められた上限帯域に制限する仮想ノード用帯域制限部と、を有し、前記仮想ノードの増減設を判断する前記制御サーバから指示を受けた前記制御部からの指示により、前記バッファ部は、前記高優先キューおよび前記低優先キューと前記仮想ノード用帯域制限部との対応付けを変更する」ことを特徴とする帯域制御装置である。

本発明によれば、少なくとも以下いずれかの効果を奏する。本発明によれば、過負荷状況においても、各ノードへの通信流入量を制御するため、システムダウン（ノード群のダウン）を回避することができる。また、優先ユーザの通信に対して、過負荷状況においてもパケットロスを回避し、高品質な通信を提供し続けることができる。また、ノードの増減設を繰り返しても、システムダウンを招かず、優先ユーザに対して品質の良い通信を提供し続けることができる。

モバイルコアシステムの構成例を示す図である。 帯域制御装置の構成例を示す図である。 バッファ管理テーブルの構成例を示す図である。 帯域制御装置の動作フローチャート例を示す図である。 帯域制御装置の構成例（３階層シェーピング）を示す図である。 システムの平常時および増設設定時の処理シーケンス例を示す図である。 帯域制御装置の設定用フローチャート例を示す図である。 帯域制御装置の増減設対応バッファ部の増設対応例を示す図である。 振分けテーブルの増設対応例を示す図である。 システムの減設設定時の処理シーケンス例を示す図である。

以下、本発明の実施形態の例を添付図面に基づき説明する。各図における同一符号は同一物あるいは相当物を示す。説明の都合上、符号に添え字を追加して区別することがある。
本実施例では、通信変動量に応じて通信の中継処理を行う通信ノードを自動的に増減設するシステムを備えるモバイルコア網へ、本実施形態の帯域制御装置を導入してシステムダウンを回避する方法、および、優先ユーザに対して高品質通信の提供を行う方法について説明する。

（システム全体の構成）
図１は、本発明の実施形態によるモバイルコアシステムの構成例を示す。データセンタなどの配信サーバ６０が接続されるインターネット５０と、ユーザの携帯端末１０が通信する無線基地局２０が接続されるアクセス網３０の間のモバイルコア網相当の位置に、本実施形態のモバイルコアシステムを配置する。モバイルコアシステムは、スイッチ５００を介して、モバイル通信の中継処理を行う通信ノードを仮想マシン３３０上の仮想ノードとして動作させるためのサーバ３００、適切な仮想ノードへモバイル通信を振分けるためのロードバランサ２００、帯域制御装置１００、および、モバイルコアシステムを制御する制御サーバ４００を接続した構成である。

図１では、ロードバランサ２００と帯域制御装置１００は、網（インターネット５０、アクセス網３０）とサーバ３００に対してワンアーム構成で配置しているが、網（インターネット５０、アクセス網３０）とサーバ３００の間に設置するインライン構成で配置してもよい。

（サーバ）
サーバ３００は、物理的には１台以上の物理サーバであり、極小規模なシステムを除くと、複数台の物理サーバで構成される。物理サーバ３００のＣＰＵ３１１、メモリ３１２、ストレージ３１３、ＮＩＣ（Ｎｅｔｗｏｒｋ Ｉｎｔｅｒｆａｃｅ Ｃａｒｄ）３１４などのハードウェアリソース３１０を備え、ハードウェアリソース３１０上で動作する仮想化ソフトウェアのハイパーバイザ３２０を備え、ＬｉｎｕｘなどのＯＳをゲストＯＳ３３１とした仮想マシン３３０を稼動させる。

また、サーバ３００で動作する仮想マシン３３０上の仮想ノードとしては、ＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）の場合、基地局制御装置であるＭＭＥ、ユーザデータの中継処理を行うＳ−ＧＷとＰ−ＧＷを、それぞれ、仮想ＭＭＥ、仮想Ｓ−ＧＷ、仮想Ｐ−ＧＷとして割り当てる。仮想ＭＭＥ、仮想Ｓ−ＧＷ、仮想Ｐ−ＧＷの数は、オペレータが直接指定した数、もしくは、オペレータからの通知される利用ユーザ数、総セッション数、セッションあたりのスループット要求などに基づいて制御サーバ４００が決定した数を、制御サーバ４００がサーバ３００に指示し、初期状態として準備する。図１では、仮想マシン３３０は、ＬＴＥの仮想ノードとして仮想ＭＭＥ３３２ａや仮想Ｓ−ＧＷ３３２ｂ、３３２ｃ、仮想Ｐ−ＧＷ３３２ｄ、３３２ｅを動作させている様子を示している。

図１では、説明を簡易化するためにサーバ３００やロードバランサ２００、本実施形態の帯域制御装置１００は１台ずつとしているが、それぞれ複数台を用いても構わない。また、ロードバランサ２００と帯域制御装置１００は一体化した装置を用いても構わない。

（ロードバランサ）
ロードバランサ２００は、複数存在する同一機能を備える仮想ノード、例えば、仮想Ｓ−ＧＷａ３３３ａと仮想Ｓ−ＧＷｂ３３３ｂの間の負荷分散や、仮想Ｐ−ＧＷａ３３４ａと仮想Ｐ−ＧＷｂ３３４ｂの間の負荷分散を行うために用いる。図１では、便宜上、仮想Ｓ−ＧＷも仮想Ｐ−ＧＷも二つずつしか示していないが、実際に運用する際には、数十〜数百、場合によっては数千を超える仮想Ｓ−ＧＷ３３３や仮想Ｐ−ＧＷ３３４に対して負荷分散を行う。

（帯域制御装置の構成）
帯域制御装置１００は、図２に示すように、外部の制御サーバ４００と通信して帯域制御装置１００内部の制御をおこなう制御部１１０と、通過パケット量などの指定した通信パケット量の計測を行う統計部１１１、パケットを保持するバッファを管理するバッファ管理テーブル１１２、受信パケットのヘッダを解析し、ロードバランサ２００と同じ振分けロジックを用いて処理を行うべき仮想ノードの番号の特定と、該当パケットが所属するユーザや通信種類からキュー番号の特定を行うパケットヘッダ解析部１２０、前記の仮想ノード番号とキュー番号に基づいてパケットを振分ける振分け部１３０、増減設対応バッファ部１４０を備える。

増減設対応バッファ部１４０は、帯域保証したパケット送信を実現する高優先キュー１４５、ベストエフォートのパケット送信のための低優先キュー１４６、制御サーバ４００から割当要求がない場合は利用しない未使用キュー１５０、仮想ノード毎に帯域制限を行う仮想ノード用帯域制限部１４４、増減設対応バッファ部１４０内のパケットのうちひとつを選択して出力する出力選択部１６０とを備える。 （帯域制御装置のバッファ管理テーブル）
また、オペレータは、高優先通信の契約を結ぶユーザに関して、図３に示す帯域制御装置１００のバッファ管理テーブル１１２のキュー管理テーブル１１９へ、保証する帯域を設定する。具体的には、制御サーバ４００は、該当ユーザのために未使用キュー１５０の内のひとつを高優先キュー１４５として割当て、割当状況を割当済みとして割当状況フィールド１９１に、割当てたキュー番号をキュー番号フィールド１９２に、プロトコルや送受信ＩＰアドレスなどで該当通信を区別する通信識別子フィールド１９３に、該当ユーザを区別するＩＰアドレスなどの識別子をユーザ識別子フィールド１９４に、優先度をＨＩＧＨとして優先度フィールド１９５に、保証帯域を保証帯域フィールド１９６に、キュー長をキュー長フィールド１９７に、それぞれ記録する。

また、制御サーバ４００は、仮想ノード毎の上限帯域を決定し、図３に示す帯域制御装置１００のバッファ管理テーブル１１２の仮想ノード管理テーブル１１８に記録する。具体的には、仮想ノードに割当てた番号を仮想ノード番号フィールド１８１に、その仮想ノードの上限帯域を上限帯域フィールド１８２に記録する。さらに、制御サーバ４００は、該当仮想ノードで処理すべきユーザに該当する高優先キュー１４５の番号と低優先キュー１４６の番号を接続キューフィールド１８３に記録する。なお、上限帯域とは、該当仮想ノードに対するパケット送信量の上限を示す。また、接続キューフィールド１８３は、本例では仮想ノード管理テーブル１１８内に設けているが、独立させてもよいし、キュー管理テーブル１１９の中に、接続する仮想ノード番号の情報を記録するフィールドとして設けてもよい。

なお、仮想Ｐ−ＧＷ３３４や仮想Ｓ−ＧＷ３３３などのデータ転送処理を行う仮想ノードの場合は、上限帯域を指定する上限帯域フィールド１８２の利用が有効であるが、仮想ＭＭＥ３３２のような接続処理を行う仮想ノードの場合は、上限帯域フィールド１８２をトランザクション量の上限を指定するものとして利用するのが好適である。ここで、トランザクション量とは、携帯端末１０をモバイル通信網に接続する際に、携帯端末１０と仮想ＭＭＥ３３２の間で複数回のパケットの一連のやり取りがどれだけ行われるかを示す量であり、携帯端末１０からの最初の接続要求を示すパケットのみを抽出して、そのパケットの総量（1秒あたり等、一定時間あたりのパケット数）を用いるのが望ましい。

上限帯域フィールド１８２に記録する値は、様々な決定方法があるが、一例として帯域制御装置１００で計測した個別の仮想Ｐ−ＧＷ３３４からの出力帯域に対して、同じ仮想Ｐ−ＧＷ３３４への入力帯域の比率を算出し、その値が１.０となる値を上限帯域として利用する方法がある。その他、本システムとは別の系で、該当する仮想Ｐ−ＧＷ３３４に対して、モバイル網を模擬したダミートラフィックを入力し、仮想Ｐ−ＧＷ３３４からの出力帯域に対して、同じ仮想Ｐ−ＧＷ３３４への入力帯域の比率を算出し、その値が１.０となる値を上限帯域として利用する方法がある。仮想ＭＭＥ３３２であれば、接続要求を示すパケットだけを入力し続けて、それに対する返信パケットを生成が正常にできる範囲の最大ケース（１秒間等、一定時間あたりに接続要求パケットをさばける数）を上限帯域（上限トランザクション数）として利用する方法がある。

また、上限帯域フィールド１８２に記録する値は、一旦記録した後に、定期的に変更してもよい。これは、仮想Ｐ−ＧＷ３３４や仮想Ｓ−ＧＷ３３３、仮想ＭＭＥ３３２に到着するパケットの長さや種類の割合が、時々刻々と変化する場合に、適切な上限帯域を再設定するためである。ただし、1時間おきや数時間おきなどのあまりに短い期間で変更するのは、システムが不安定になる恐れがあり、望ましくない。定期的に変更する場合は、1日おき、数日おき、1週間おき、数週間おき、などのある程度長い期間で変更するのが望ましい。

図３の例では、仮想ノード１は上限帯域が１０００Ｍｂｐｓで、通信識別子をＳ−ＧＷからＰ−ＧＷへの通信としたキュー１、キュー２、キュー３を接続している。キュー１とキュー２は保証帯域を５Ｍｂｐｓとした高優先キュー１４５で、それぞれＩＰアドレス＝１０．０．０．１、ＩＰ＝１０．２．１．３をユーザ識別子とし、キュー３は帯域保証を行わない低優先キュー１４６で高優先キュー１４５以外のＩＰアドレスを指定している。

なお、制御サーバ４００は、サーバ３００で動作する仮想マシン３３０の上で動作させるアプリケーションとしてもよい。同様に、ロードバランサ２００は、サーバ３００とは別装置として示したが、ロードバランサ２００をサーバ３００で動作する仮想マシン３３０の上で動作させるアプリケーションとしてもよい。同様に、帯域制御装置１００は、図１ではサーバ３００とは別装置として示したがサーバ３００で動作する仮想マシン３３０の上で動作させるアプリケーションとしても良い。

ただし、ロードバランサ２００と帯域制御装置１００は、システム上ですべてのパケットが通過する最も負荷の高い部位であるため、過負荷時には仮想マシン３３０にも過大な負荷がかかり、ロードバランサ２００や帯域制御装置１００の機能を実行するアプリケーションが稼動しているゲストＯＳ３３１やそのファームウェアが誤動作を引き起こし、本実施形態で開示した機能を実現できない恐れもある。このため、ロードバランサ２００、帯域制御装置１００に関しては、サーバ３００とは別の専用ハードウェア、もしくは、サーバとして実施する形態が望ましい。

例えば、帯域制御装置１００をサーバとして実施する形態の場合、当該サーバは、ＣＰＵ、メモリ、ストレージ等を有しており、例えば制御部１１０、統計部１１１、パケットヘッダ解析部１２０、振分部１３０、仮想ノード用帯域制限部１４４、出力選択部１６０は、これらの機能を提供するためのソフトウェアプログラムをメモリやストレージ等から読みだしてＣＰＵが実行することにより実現することが可能である。また、バッファ管理テーブル１１２、高優先キュー１４５、低優先キュー１４６、未使用キュー１５０は、メモリやストレージ等によって実現することが可能である。

（システム全体の動作）
まず、帯域制御装置１００を含むシステム全体の平常時の動作について説明する。携帯端末１０からの通信は、最初に仮想ＭＭＥを介して仮想Ｓ−ＧＷ、仮想Ｐ−ＧＷとインターネットとの間で通信路（トンネル、ベアラ）の確立を行うが、説明を簡易化するため、前記の通信路の確立は完了しているものとする。

本実施形態のモバイルコア網の利用者は、携帯端末１０を用いて、最終的には、所望の情報を保持するデータセンタなどの配信サーバ６０へアクセスすることによってデータ（ホームページなどのブラウジングする画面や、メールや動画など）をダウンロードする。携帯端末１０からのアクセスは、最寄りの無線基地局２０を経由して、アクセス網３０を通過し、スイッチ５００を介して、ロードバランサ２００へ転送される。

ロードバランサ２００は、携帯端末１０からのパケットのヘッダ情報を検査し、モバイル通信の中継処理を行う仮想Ｓ−ＧＷ３３３の中の指定したひとつを選択し、該当する仮想Ｓ−ＧＷ３３３を示すためのＶＬＡＮタグなどの識別子をパケットに付与するか、パケットの宛先ＩＰアドレスを置換するかなどしたのち、帯域制御装置１００へ転送する。

帯域制御装置１００は、後述する手順に従ってパケットをバッファリングしたのち、指定された帯域に従ってパケットを該当する仮想Ｓ−ＧＷ３３３に向けて転送する。

仮想Ｓ−ＧＷ３３３は、受信したパケットをカプセル化し、スイッチ５００へ送信する。スイッチ５００は、仮想Ｓ−ＧＷ３３３から受信したパケットをロードバランサ２００へ転送する。

ロードバランサ２００は、受信したパケットのヘッダ情報を検査し、モバイル通信の中継処理を行う仮想Ｐ−ＧＷ３３４の中の指定したひとつを選択し、該当する仮想Ｐ−ＧＷ３３４を示すためのＶＬＡＮタグなどの識別子をパケットに付与するか、パケットの宛先ＩＰアドレスを置換するかなどしたのち、帯域制御装置１００へ転送する。

帯域制御装置１００は、後述する手順に従ってパケットをバッファリングしたのち、指定された帯域に従ってパケットを該当する仮想Ｐ−ＧＷ３３４に向けて転送する。

仮想Ｐ−ＧＷ３３４は、受信したパケットのカプセルを外し、スイッチ５００へ送信する。スイッチ５００は、仮想Ｐ−ＧＷ３３４から受信したパケットをインターネット５０へ送信する。

インターネット５０を経由して、指定のデータセンタなどの配信サーバ６０に携帯端末１０からのパケットが届き、パケットのペイロードの内容に応じて、配信サーバ６０は、携帯端末１０へ要求されたデータをパケットにして返信する。

配信サーバ６０からのパケットは、先に説明した携帯端末１０から配信サーバ６０へのアクセスとは逆の経路を通って携帯端末１０へ届く。すなわち、配信サーバ６０からのパケットは、インターネット５０を通過し、スイッチ５００を介して、ロードバランサ２００へ転送される。

ロードバランサ２００は、受信したパケットのヘッダ情報を検査し、モバイル通信の中継処理を行う仮想Ｐ−ＧＷ３３４の中の指定したひとつを選択し、該当する仮想Ｐ−ＧＷ３３４を示すためのＶＬＡＮタグなどの識別子をパケットに付与するか、パケットの宛先ＩＰアドレスを置換するかなどしたのち、帯域制御装置１００へ転送する。

帯域制御装置１００は、後述する手順に従ってパケットをバッファリングしたのち、指定された帯域に従ってパケットを該当する仮想Ｐ−ＧＷ３３４に向けて転送する。

仮想Ｐ−ＧＷ３３４は、受信したパケットをカプセル化し、スイッチ５００へ送信する。スイッチ５００は、仮想Ｐ−ＧＷ３３４から受信したパケットをロードバランサ２００へ送信する。

ロードバランサ２００は、受信したパケットのヘッダ情報を検査し、モバイル通信の中継処理を行う仮想Ｓ−ＧＷ３３３の中の指定したひとつを選択し、該当する仮想Ｓ−ＧＷ３３３を示すためのＶＬＡＮタグなどの識別子をパケットに付与するか、パケットの宛先ＩＰアドレスを置換する等したのち、帯域制御装置１００へ転送する。

帯域制御装置１００は、後述する手順に従ってパケットをバッファリングしたのち、指定された帯域に従ってパケットを該当する仮想Ｓ−ＧＷ３３３に向けて転送する。

仮想Ｓ−ＧＷ３３３は、受信したパケットのカプセルを外し、スイッチ５００へ送信する。スイッチ５００は、仮想Ｓ−ＧＷ３３３から受信したパケットをアクセス網３０へ送信し、指定された無線基地局２０を経由して、携帯端末１０へパケットが届く。

（帯域制御装置１００の動作）
次に、帯域制御装置１００の動作に関して、図２の帯域制御装置１００の構成例、図３のバッファ管理テーブル１１２の構成例、図４の帯域制御装置用フローチャート例を用いて説明する。

帯域制御装置１００は、パケットを受信する（図４のステップＳ８００）とパケットヘッダ解析部１２０で、パケットのヘッダ情報から仮想Ｓ−ＧＷ３３３、仮想Ｐ−ＧＷ３３４など、どの仮想ノード宛のパケットかを特定するための情報、さらに、該当仮想ノードが仮想Ｐ−ＧＷであれば、複数ある仮想Ｐ−ＧＷ３３４の中のどの仮想Ｐ−ＧＷ３３４宛であるかを特定するための情報、さらに、該当パケットが所属するユーザや通信種類から、保持されるべきキュー番号を特定するための情報を抽出する。便宜上、前記で抽出した情報を検索キーと呼ぶ。

例えば、上り方向の通信（アクセス網３０からインターネット５０向きの通信）で仮想Ｐ−ＧＷ３３４宛であることを特定するためには、仮想Ｓ−ＧＷ３３３と仮想Ｐ−ＧＷ３３４の間で、例えば、ＧＲＥ（Ｇｅｎｅｒｉｃ Ｒｏｕｔｉｎｇ Ｅｎｃａｐｓｕｌａｔｉｏｎ）トンネルが確立されているはずなので、ＧＲＥのパケットフォーマットであること、パケットの送信元ＩＰアドレスが仮想Ｓ−ＧＷ３３３を示すこと、宛先ＩＰアドレスが仮想Ｐ−ＧＷ３３４を示すことを特定すればよい。よって、これらの条件（パケットフォーマット、送信元ＩＰアドレス、宛先ＩＰアドレス）を検索キーとして抽出する。

また、前記の場合、ＧＲＥのパケットヘッダからＧＲＥキーと呼ぶ識別子を、複数ある仮想Ｐ−ＧＷ３３４の中のどの仮想Ｐ−ＧＷ３３４宛であるかを特定するための検索キーとして抽出する。ＧＲＥキーは、ユーザを特定するためにも利用できるため、キュー番号を特定するための検索キーとしても抽出する。

振分部１３０は、パケットと前記の検索キーを受信すると、ロードバランサ２００と同じ振分け論理により、どの仮想ノード宛か（例えば仮想Ｐ−ＧＷ３３４のいずれ宛か）を決定する（ステップＳ８０１）。

例えば、振分け論理にハッシュ関数を利用していれば、検索キーに対してハッシュ関数を適用し、得られた演算結果の番号を所定の一覧表に照らし合わせ、仮想ノード番号として扱うことで、仮想ノードを特定する。例えば、図９の左側に示す振分けテーブル１１７を備え、ハッシュ関数の結果をハッシュ値フィールド１７１の値として扱い、該当エントリに対応する仮想ノードフィールド１７２に書き込まれている値を仮想ノード番号として扱う。

また、振分け論理にハッシュ関数を利用しないテーブルを利用していれば、検索キーをインデックスにしてテーブルを検索し、該当エントリに記載されている仮想ノード番号を読み出すことで仮想ノードを特定する。

また、振分部１３０は、前述の例ではＧＲＥキーを検索キーとしてキュー番号を特定する（ステップＳ８０２）。

いずれにしても、振分け部１３０は、該当パケットが処理されるべき仮想ノード番号とキュー番号を特定すると、増減設対応バッファ部１４０の該当するキューのバッファ残量を確認し、バッファに空き領域が存在すれば、該当パケットを該当する高優先キュー１４５、または、低優先キュー１４６に格納する（ステップＳ８０３→ステップＳ８０４）。

バッファに空き領域が存在しなかったり、存在していてもＲＥＤ（Ｒａｎｄｏｍ Ｅａｒｌｙ Ｄｒｏｐ）などのアルゴリズムを適用していたりして、パケットの廃棄条件を満たしていれば、該当パケットを格納せずに廃棄する（ステップＳ８０３→ステップＳ８０６）
仮想ノード用帯域制限部１４４は、仮想ノード毎に上限帯域を設定しておき、所定のアルゴリズムに従って保証帯域を提供する高優先キュー１４５、または、保証帯域は提供しない低優先キュー１４６からパケットを取り出しつつ、該当仮想ノードが処理できる量のパケットとなるように各仮想ノードへのパケット送信量を調整し、出力選択部１６０から該当パケットを出力する（ステップＳ８０５）。

なお、好ましい実施形態では、パケット取り出しの際には、ラウンドロビン方式で複数ある仮想ノード用帯域制限部１４４の一つを選択する。また、高優先キュー１４５と低優先キュー１４６を設けている場合には、各仮想ノード用帯域制限部１４４は、高優先キュー１４５からのパケット取出しを優先する。

別の好ましい実施形態としては、高優先キュー１４５にパケットがある場合には、常に高優先キュー１４５からの取り出しを優先するストリクトプライオリティ、高優先キュー１４５にパケットがあっても、一定の割合で低優先キュー１４６からの取り出しを行う重み付きラウンドロビンなどのアルゴリズムを適用する。

（帯域制御装置１００のキュー）
増減設対応バッファ部１４０は、初期状態では、複数のキューを未使用キュー1５０として保持し、制御サーバ４００からの指示に従い、該当するユーザの通信に未使用キュー１５０を高優先キュー１４５、または、低優先キュー１４６として割当て、該当する仮想ノード毎に仮想ノード用帯域制限部１４４を割当て、仮想ノード用帯域制限部１４４と該当する高優先キュー１４５、および、低優先キュー１４６を関連付ける。

なお、別の実施形態としては、高優先キュー１４５と低優先キュー１４６のように２レベルの優先キューではなく、複数レベルの優先キューを設け、ユーザ毎に、リアルタイム性を要するＶｏＩＰ（Ｖｏｉｃｅ ｏｖｅｒ ＩＰ）やリアルタイム映像は高い優先度のキューに、ＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）で運ばれる電子メールやファイル、ウェブブラウジングなどは低い優先度のキューに割当て、ユーザ内での通信の優先順位付けを行っても良い。

なお、ユーザ毎に高優先、低優先を区別しない場合は、該当ユーザの通信をひとつの高優先キュー１４５、または、低優先キュー１４６を割当てるか、高優先、低優先の区別をなくしたキューに割当てても良い。

以上で説明したキューの構成は、仮想ノード用帯域制限部１４４を１階層目、高優先キュー１４５と低優先キュー１４６を２階層目、とした場合、２階層のシェーピングを行う形式となる。

また、１個以上の仮想ＭＭＥ３３２のグループ、１個以上の仮想Ｓ−ＧＷ３３３のグループ、１個以上の仮想Ｐ−ＧＷ３３４のグループ、として、それぞれの仮想ノード種別毎の合計値としても帯域制限を行う場合は、図５に示すように、１階層目を仮想Ｐ−ＧＷ３３４だけ等の仮想ノード種類単位で帯域制限を行う仮想ノード種別用帯域制限部１４３、２階層目をＰ−ＧＷ３３４等の個別の仮想ノードで帯域制限を行う仮想ノード用帯域制限部１４４、３階層目を高優先キュー１４５と低優先キュー１４６として、３階層のシェーピングを行う形式となる。

例えば、図１の仮想Ｐ−ＧＷ３３４ａ、仮想Ｐ−ＧＷ３３４ｂ全体の帯域制限用に図５の仮想ノード種別用帯域制限部１４３ａを割当て、個別の仮想Ｐ−ＧＷ３３４ａ用の帯域制限に仮想ノード用帯域制限部１４４ａを、仮想Ｐ−ＧＷ３３４ｂ用の帯域制限に仮想ノード用帯域制限部１４４ｂを割当てる。

また、ＭＶＮＯ（Ｍｏｂｉｌｅ Ｖｉｒｔｕａｌ Ｎｅｔｗｏｒｋ Ｏｐｅｒａｔｏｒ）を想定し、複数の通信事業者が、本実施形態のシステムを共有利用する場合は、図５の仮想ノード種別用帯域制限部１４３と出力選択部１６０の間に、事業者毎の帯域制限部を１階層加えて、全体として４階層のシェーピングを行う形式となる。もしくは、図５の仮想ノード種別用帯域制限部１４３を、事業者毎の帯域制限部として扱い、３階層のシェーピングを行う形式としても良い。

いずれの形式でも、一番下の階層となる高優先キュー１４５では最低保証帯域を設定し、通信帯域を保証する。残りの全ての階層では、上限帯域を設定し、該当する事業者のシステムや仮想ノードに対して、指定した以上の通信が流れ込まないことを保証する。

なお、高優先キュー１４５の保証帯域の合計値は、仮想ノード用帯域制限部１４４や仮想ノード種別用帯域制限部１４３の上限帯域を超えない値となるようにする必要がある
（スケールアウトの動作）
次に、図６を用いて、本実施形態で、仮想Ｐ−ＧＷ３３４等の仮想ノードを増減する（スケーリングする）際の動作について説明する。帯域制御装置１００は、仮想Ｐ−ＧＷ３３４や仮想Ｓ−ＧＷ３３３などの仮想ノードの種別毎に、該当装置に向けて送信されるものとして帯域制御装置１００で受信したパケットの総量（1秒あたり等、一定時間あたりのパケット数とビット数）と、個別の仮想ノード宛として帯域制御装置１００で受信したパケットの総量（1秒あたり等、一定時間あたりのパケット数とビット数）の計測を常時行う（ステップＳ６０１）。これらの計測結果は、仮想Ｐ−ＧＷ３３４や仮想Ｓ−ＧＷ３３３などのデータ転送処理を行う仮想ノードの増減設を判断するのに好適である。

また、仮想ＭＭＥ３３２のような接続処理を行う仮想ノードの増減設を判断するためには、携帯端末１０をモバイル通信網に接続する際に、携帯端末１０と仮想ＭＭＥ３３２の間で複数回のパケットのやり取りが行われるため、帯域制御装置１００は、仮想ＭＭＥ３３２宛のパケットのうち、携帯端末１０からの最初の接続要求を示すパケットのみを抽出して、そのパケットの総量（1秒あたりのパケット数）を計測して用いるのが好適である。

制御サーバ４００は、３秒おきや１０秒おき、1分おきなど、あらかじめ指定したタイミングで定期的に帯域制御装置１００へ計測読出し要求を通知する（ステップＳ６０２）。帯域制御装置１００は、これに応える形で計測量通知を行う（ステップＳ７２１）。なお、あらかじめ制御サーバ４００から計測結果を定期的に通知するタイミングを指定しておき、帯域制御装置１００が、能動的に制御サーバ４００へ計測結果を通知してもよい。また、帯域制御装置１００は、制御サーバ４００から指定された条件（トラフィックが急増、急減等）に達するまでは1分おきや１０分おきなど、比較的長い時間粒度で計測結果を通知し、指定された条件に達した場合に、３秒おきや１０秒おきなど、比較的短い時間粒度で計測結果を通知してもよい。

帯域制御装置１００の視点から見ると、図７のフローチャートでステップＳ７００→ステップＳ７２０→ステップＳ７２１と遷移し、統計部１１１で計測した計測結果を制御サーバ４００に通知する。なお、通知すべき計測内容の設定に関しては、図７のフローチャートでステップＳ７００→ステップＳ７０１→ステップＳ７０２→ステップＳ７０３→ステップＳ７１４と遷移し、仮想ノードの増減設トリガ用の計測内容の情報を受信し、制御部１１０を介して統計部１１１に対して設定を行う。

制御サーバ４００は、計測量通知を受信すると、仮想Ｓ−ＧＷ３３３や仮想Ｐ−ＧＷ３３４などの仮想ノードの種類毎に過去の計測履歴と最新の計測履歴を勘案し、所定の閾値を超えるなどの増設条件に達するかどうかを判定する。すなわち、必要な仮想ノード数を計算する（図６のステップＳ６０３）。増設条件に達しない場合は、システムの構成をそのまま維持する（図６のＳ６００の増減設なしのフローチャートに相当）。増設条件に達した場合、該当する仮想ノードの増設（スケールアウト）を実施する。（図６のＳ６１０の増設ありのフローチャートに相当）。

ここでは、仮想Ｐ−ＧＷ３３４の増設条件に達した場合の動作について、図６、図７のフローチャートと図８に示す帯域制御装置１００内の増減設対応バッファ部１４０の変更説明図、図９に示す振分けテーブル１１７の変更説明図を用いて説明する。本例では、高優先通信を契約するユーザの数は増えずに、インターネットライブなどのイベントが生じて、ユーザが一斉に動画視聴を開始し、ユーザあたりのトラフィック量が増加するケースで説明する。

本例では、仮想Ｐ−ＧＷ３３４を１台増設する場合について説明するが、２台以上増設する場合も、以下の説明を踏襲することで対応可能である。仮想Ｐ−ＧＷ３３４の増設条件に達した場合、制御サーバ４００は、サーバ３００に対して増加させる仮想Ｐ−ＧＷ３３４分の仮想マシン３３０の準備、および、該当仮想マシン３３０上での仮想Ｐ−ＧＷ３３４プログラムの起動を指示する（図６のステップＳ６１１）。また、起動した仮想Ｐ−ＧＷ３３４ｃに対して、既に稼働中の仮想Ｐ−ＧＷ３３４ａ，３３４ｂのから、移動する通信セッションのステート情報のコピーを行う（図６のステップＳ６１２）。

該当仮想ノード（仮想Ｐ−ＧＷ３３４）が起動すると、制御サーバ４００は、帯域制御装置１００に対して増設した仮想ノード（仮想Ｐ−ＧＷ３３４）分のキュー増設設定を通知する（図６のステップＳ６２０）。本例では、図８に示すように、高優先キュー１４５は追加せず、追加した仮想Ｐ−ＧＷ３３４分の低優先キュー１４６ｃを１本追加する。

帯域制御装置１００の視点から見ると、図７のフローチャートでステップＳ７００→ステップＳ７０１→ステップＳ７１１と遷移し、対象キューの番号、処理内容（追加/削除/更新）、識別子、優先度、キュー長、保証帯域を設定する。図８の例では、帯域制御装置１００の制御部１１０は、制御サーバ４００から、追加するキューの番号、 処理内容として「追加」、識別子として「通信識別子（仮想Ｓ−ＧＷ３３３から仮想Ｐ−ＧＷ３３４であることを示す情報）」、優先度として「低優先」、キュー長として例えば「８Ｋｂｙｔｅ」、の情報を受信し、バッファ管理テーブル１１２のキュー管理テーブル１１９へ記録する。そして、制御部１１０は、キュー管理テーブル１１９の内容を増減設対応バッファ部１４０に対して設定する。なお、設定内容が低優先キューだけであるため保証帯域の設定値は有効な値を受け取らない。

次に、制御サーバ４００は、帯域制御装置１００に対して増設した仮想ノード（仮想Ｐ−ＧＷ３３４）分の仮想ノード増設設定を通知する（図６のステップＳ６２１）。本例では、図８に示すように、仮想ノード用帯域制限部１４４ｃを追加する。

帯域制御装置１００の視点から見ると、図７のフローチャートでステップＳ７００→ステップＳ７０１→ステップＳ７０２→ステップＳ７１２と遷移し、対象仮想ノードの番号、 処理内容（追加/削除/更新）、上限帯域を設定する。図８の例では、帯域制御装置１００の制御部１１０は、制御サーバ４００から、追加する仮想ノードの番号、処理内容として「追加」、上限帯域として例えば「１０００Ｍｂｐｓ」の情報を受信し、バッファ管理テーブル１１２の仮想ノード管理テーブル１１８へ記録する。そして、制御部１１０は、仮想ノード管理テーブル１１８の内容を増減設対応バッファ部１４０に対して設定する。

次に、制御サーバ４００は、帯域制御装置１００に対してキューと仮想ノード（仮想Ｐ−ＧＷ３３４）の接続変更（対応付け変更）と振分け変更の設定を通知する（図６のステップＳ６２２）。本例では、図８に示すように、高優先キュー１４５ｃと高優先キュー１４５ｆを仮想ノード用帯域制限部１４４ｃに繋ぎ換え、低優先キュー１４６ｃも仮想ノード用帯域制限部１４４ｃに繋ぐ（つまり、高優先キューおよび低優先キューと仮想ノード用帯域制限部との対応付けを変更する）。また、振分けのための振分けテーブルのエントリ内容を更新することで、増設に対応した振分けを実現する。

帯域制御装置１００の視点から見ると、図７のフローチャートでステップＳ７００→ステップＳ７０１→ステップＳ７０２→ステップＳ７０３→ステップＳ７１３と遷移し、対象キューと対象仮想ノードの接続変更（対応付け変更）と振分変更を設定する。図８の例では、帯域制御装置１００の制御部１１０は、接続変更として、制御サーバ４００から、仮想ノード１（仮想Ｐ−ＧＷ３３４ａ）の仮想ノード用帯域制限部１４４ａから高優先キュー１４５ｃを、仮想ノード２（仮想Ｐ−ＧＷ３３４ｂ）の仮想ノード用帯域制限部１４４ｂから高優先キュー１４５ｆを、それぞれ取り除き、仮想ノード３（仮想Ｐ−ＧＷ３３４ｃ）の仮想ノード用帯域制限部１４４ｃに接続すること、また、低優先キュー１４６ｃも仮想ノード用帯域制限部１４４ｃに接続することを「対象キューと対象仮想ノードの接続変更」情報として受信し、バッファ管理テーブル１１２の仮想ノード管理テーブル１１８の接続キューフィールド１８３へ記録する。そして、制御部１１０は、仮想ノード管理テーブル１１８の内容を増減設対応バッファ部１４０に対して設定する。

なお、図８に基づいた以上の説明では、高優先キュー１４５は追加せず、追加した仮想Ｐ−ＧＷ３３４分の低優先キュー１４６ｃを１本追加する場合の動作に関して説明したが、仮想ノード用帯域制限部１４４ｃを追加する際に、高優先キュー１４５も新規に追加し、これまで、仮想ノード用帯域制限部１４４ａ、１４４ｂに接続し扱っていた高優先キュー１４５ｃ、１４５ｆの通信セッションを仮想ノード用帯域制限部１４４ｃ用に新規追加した高優先キュー１４５で扱うようにしてもよい。この場合、キュー管理テーブル１１９の該当するキュー番号のエントリをいったん削除するか、無効状態として扱い、新規追加した高優先キューのエントリ情報を追加すればよい。

また、振分変更として、図９の振分けテーブル１１７の増減設前後の変更図に示すように、振分けにハッシュ関数を用いている場合は、ハッシュ値フィールド１７１に対する仮想ノード番号フィールド１７２の値を、増設前は１（仮想Ｐ−ＧＷ３３４ａに相当）と２（仮想Ｐ−ＧＷ３３４ｂに相当）だけだったものを、増設後は１、２に３（仮想Ｐ−ＧＷ３３４ｃに相当）も加えるように更新する。

以上の制御により、帯域制御装置１００の設定変更を終えると、制御サーバ４００は、ロードバランサ２００に対して振分け情報の再設定を通知する（図６のステップＳ６３０）。具体的には、帯域制御装置１００の振分変更で説明した図９の振分けテーブル１１７の設定変更と同等の処理をロードバランサ２００に対して実施する。

以上の設定が全て完了すると、仮想Ｐ−ＧＷ３３４の増設が完了となり、以後、ロードバランサ２００と帯域制御装置１００を経由して、２台から３台に増設された仮想Ｐ−ＧＷ３３４を利用したモバイル通信の中継処理が行われることになる。

本例では、高優先通信を契約するユーザの数は増えずに、インターネットライブなどのイベントが生じて、ユーザが一斉に動画視聴を開始し、ユーザあたりのトラフィック量が増加するケースで説明したが、ユーザ数が急増して総トラフィック量が増加するケース、両ケースの混在ケースも存在する。これらのケースの場合は、高優先キュー１４５を新規追加することだけが先に説明したケースとの違いであり、残りの処理は先の説明と同様に行えばよい。

（スケールインの動作）
次に、仮想Ｐ−ＧＷ３３４の減設条件に達した場合の動作について、図１０、図７のフローチャートと図８に示す帯域制御装置１００内の増減設対応バッファ部１４０の変更説明図、図９に示す振分けテーブル１１７の変更説明図を用いて説明する。

本例では、高優先通信を契約するユーザの数は増えずに、インターネットライブなどのイベントが終了して、ユーザが一斉に動画視聴を終了し、ユーザあたりのトラフィック量が減少するケースで説明する。

制御サーバ４００は、３秒おきや１０秒おき、1分おきなど、あらかじめ指定したタイミングで定期的に帯域制御装置１００へ計測読出し要求を通知する（図１０のステップＳ６０２）。帯域制御装置１００は、これに応える形で計測量通知を行う（図１０のステップＳ７２１）。

制御サーバ４００は、計測量通知を受信すると、仮想Ｓ−ＧＷ３３３や仮想Ｐ−ＧＷ３３４などの仮想ノードの種類毎に過去の計測履歴と最新の計測履歴を勘案し、所定の閾値を下回るなどの減設条件に達するかどうかを判定する。すなわち、必要な仮想ノード数を計算する（図１０のステップＳ６０３）。減設条件に達した場合、該当する仮想ノードの減設（スケールイン）を実施する（図１０のＳ６０９の減設ありのフローチャートに相当）。

本例では、仮想Ｐ−ＧＷ３３４を１台減設する場合について説明するが、２台以上減設する場合も、以下の説明を踏襲することで対応可能である。

制御サーバ４００は、サーバ３００に対して、減設する仮想Ｐ−ＧＷ３３４ｃから、存在を維持する仮想Ｐ−ＧＷ３３４ａ，３３４ｂに対して移動する通信セッションのステート情報のコピーを行う（図１０のステップＳ６１３）。

続いて、制御サーバ４００は、帯域制御装置１００に対して、キューと仮想ノード（仮想Ｐ−ＧＷ３３４）の接続変更（対応付け変更）と振分け変更の設定を通知する（図１０のステップＳ６２２）。本例は、図８の逆の例、すなわち、増設後から増設前に戻す例に相当する。このため、高優先キュー１４５ｃを仮想ノード用帯域制限部１４４ａに、高優先キュー１４５ｆを仮想ノード用帯域制限部１４４ｂに、それぞれ繋ぎ換え、低優先キュー１４６ｃと仮想ノード用帯域制限部１４４ｃの接続を解除する（つまり、高優先キューおよび低優先キューと仮想ノード用帯域制限部との対応付けを変更する）。また、振分けのための振分けテーブルのエントリ内容を更新することで、減設に対応した振分けを実現する。

帯域制御装置１００の視点から見ると、図７のフローチャートでステップＳ７００→ステップＳ７０１→ステップＳ７０２→ステップＳ７０３→ステップＳ７１３と遷移し、対象キューと対象仮想ノードの接続変更（対応付け変更）と振分変更を設定する。本例では、帯域制御装置１００の制御部１１０は、接続変更として、制御サーバ４００から、前述の接続変更の情報を「対象キューと対象仮想ノードの接続変更」情報として受信し、バッファ管理テーブル１１２の仮想ノード管理テーブル１１８の接続キューフィールド１８３へ記録する。そして、制御部１１０は、仮想ノード管理テーブル１１８の内容を増減設対応バッファ部１４０に対して設定する。

なお、図８に基づいた以上の説明では、高優先キュー１４５ｃと高優先キュー１４５ｆの接続変更する場合の動作に関して説明したが、仮想ノード用帯域制限部１４４ａ、１４４ｂにおいて追加で扱う高優先キュー１４５をキュー管理テーブル１１９に新規追加するか、無効化しておいたものを再度有効化して、仮想ノード用帯域制限部１４４ａ、１４４ｂに接続して利用するようにしてもよい。

また、この場合の振分変更は、図９の振分けテーブル１１７の増減設前後の変更図の例の逆の例、すなわち、増設後から増設前に戻す例に相当する。振分けにハッシュ関数を用いている場合は、ハッシュ値フィールド１７１に対する仮想ノード番号フィールド１７２の値を、減設前は１（仮想Ｐ−ＧＷ３３４ａに相当）と２（仮想Ｐ−ＧＷ３３４ｂに相当）と３（仮想Ｐ−ＧＷ３３４ｃに相当）であったところを、減設後は１、２だけに更新する。

次に、制御サーバ４００は、帯域制御装置１００に対して減設した仮想ノード（仮想Ｐ−ＧＷ３３４ｃ）分のキュー減設設定を通知する（図１０のステップＳ６２３）。本例では、図８に示すように、減設する仮想Ｐ−ＧＷ３３４ｃ分の低優先キュー１４６ｃを１本削除する。

帯域制御装置１００の視点から見ると、図７のフローチャートでステップＳ７００→ステップＳ７０１→ステップＳ７１１と遷移し、対象キューの番号、処理内容（追加/削除/更新）、識別子、優先度、キュー長、保証帯域を設定する。図８の逆の例では、帯域制御装置１００の制御部１１０は、制御サーバ４００から、削除するキューの番号、処理内容として「削除」、識別子として「通信識別子（仮想Ｓ−ＧＷ３３３から仮想Ｐ−ＧＷ３３４であることを示す情報）」、の情報を受信し、バッファ管理テーブル１１２のキュー管理テーブル１１９へ記録する。そして、制御部１１０は、キュー管理テーブル１１９の内容を増減設対応バッファ部１４０に対して設定する。なお、設定内容が削除であるため、優先度と、キュー長、保証帯域の設定値は有効な値を受け取らない。

次に、制御サーバ４００は、帯域制御装置１００に対して減設した仮想ノード（仮想Ｐ−ＧＷ３３４ｃ）分の仮想ノード減設設定を通知する（図１０のステップＳ６２４）。本例では、図８の逆の例として示すように、仮想ノード用帯域制限部１４４ｃを削除する。

帯域制御装置１００の視点から見ると、図７のフローチャートでステップＳ７００→ステップＳ７０１→ステップＳ７０２→ステップＳ７１２と遷移し、対象仮想ノードの番号、 処理内容（追加/削除/更新）、上限帯域を設定する。図８の逆の例では、帯域制御装置１００の制御部１１０は、制御サーバ４００から、削除する仮想ノードの番号、処理内容として「削除」の情報を受信し、バッファ管理テーブル１１２の仮想ノード管理テーブル１１８へ記録する。そして、制御部１１０は、仮想ノード管理テーブル１１８の内容を増減設対応バッファ部１４０に対して設定する。なお、設定内容が削除であるため、上限帯域の設定値は有効な値を受け取らない。

以上の制御により、帯域制御装置１００の設定変更を終えると、制御サーバ４００は、ロードバランサ２００に対して振分け情報の再設定を通知する（図１０のステップＳ６３０）。具体的には、帯域制御装置１００の振分変更で説明した図９の振分けテーブル１１７の設定変更の逆の変更と同等の処理をロードバランサ２００に対して実施する。

これで、減設した仮想ノードである仮想Ｐ−ＧＷ３３４ｃにはパケットが到着しなくなるため、制御サーバ４００は、サーバ３００に対して該当する仮想ノードの減設設定を行い、仮想Ｐ−ＧＷ３３４ｃを削除する（図１０のステップＳ６１４）。

以上の設定が全て完了すると、仮想Ｐ−ＧＷ３３４ｃの減設が完了となり、以後、ロードバランサ２００と帯域制御装置１００を経由して、３台から２台に減設された仮想Ｐ−ＧＷ３３４を利用したモバイル通信の中継処理が行われることになる。

本例では、高優先通信を契約するユーザの数は減らずに、インターネットライブなどのイベントが終了して、ユーザが一斉に動画視聴を終了し、ユーザあたりのトラフィック量が減少するケースで説明したが、ユーザ数が急減して総トラフィック量が減少するケース、両ケースの混在ケースも存在する。これらのケースの場合も、先の説明と同様に行えばよい。

（本実施形態でシステムを保護が可能な理由）
以上に説明した本実施形態によれば、帯域制御装置１００の増減設対応バッファ部１４０に設けた仮想ノード用帯域制限部１４４や仮想ノード種別用帯域制限部１４３を導入することで、平常時、および、スケールアウトの最中、いずれであっても仮想Ｓ−ＧＷ３３３や仮想Ｐ−ＧＷ３３４などの仮想ノードには過剰な通信流入がなくなるため、システム保護が可能となる。

（本実施形態で高優先ユーザの通信を保護が可能な理由）
また、本実施形態によれば、帯域制御装置１００の増減設対応バッファ部１４０に高優先キュー１４５を導入することで、追加料金を払ってでも品質の良い通信を望むユーザの通信に対して、過負荷状況においてもパケットロスを回避し、高品質な通信を提供し続けることができる。

（本実施形態で増減設を繰り返してもシステム保護が可能な理由）
また、本実施形態によれば、仮想Ｐ−ＧＷ３３４などの仮想ノードの増減設（スケールアウト、スケールイン）時に、帯域制御装置１００の増減設対応バッファ部１４０のバッファ管理テーブル１１２を用いて制御して、高優先キュー１４５と低優先キュー１４６、仮想ノード用帯域制限部１４４との接続関係を更新制御することで、仮想ノードの増減設を繰り返しても、システムダウンを招かず、優先ユーザに対して品質の良い通信を提供し続けることができる。

10：携帯端末、20：無線基地局、30：アクセス網、50：インターネット、60：配信サーバ、100：帯域制御装置、110：制御部、111：統計部、112：バッファ管理テーブル、117：振り分けテーブル、118：仮想ノード管理テーブル、119：キュー管理テーブル、120：パケットヘッダ解析部、130：振分部、140：増減設対応バッファ部、143：仮想ノード種別用帯域制限部、144：仮想ノード用帯域制限部、145：高優先キュー、146：低優先キュー、150：未使用キュー、160：出力選択部、200：ロードバランサ、300：サーバ、310：ハードウェアリソース、311：ＣＰＵ、312：メモリ、313：ストレージ、314：ＮＩＣ、320：ハイバーバイザ、330：仮想マシン、331：ゲストＯＳ、332：仮想ＭＭＥ、333：仮想Ｓ−ＧＷ、334：仮想Ｐ−ＧＷ、400：制御サーバ、500：スイッチ

Claims (17)

1. サーバ装置に備えられた複数の仮想ノードへパケットを送信する帯域制御装置であって、
   前記帯域制御装置の制御をおこなう制御部と、
   前記パケットを保持するキューを制御するバッファ部と、を有し、
   前記バッファ部は、
   高優先のパケットを保持し、パケット送信量を所定の保証帯域で保証する複数の高優先キューと、
   低優先のパケットを保持する複数の低優先キューと、
   前記仮想ノード毎に備えられ、複数の前記高優先キューおよび前記低優先キューの中で自身に対応付けられた高優先キューおよび低優先キューからパケットを読み出して前記仮想ノード毎に定められた上限帯域に制限する仮想ノード用帯域制限部と、を有し、
   前記仮想ノードの増減設を判断する制御サーバから指示を受けた前記制御部からの指示により、
   前記バッファ部は、前記高優先キューおよび前記低優先キューと前記仮想ノード用帯域制限部との対応付けを変更することを特徴とする帯域制御装置。
2. 請求項１に記載の帯域制御装置であって、
   前記制御サーバが前記仮想ノードを増設することを判断した場合、前記制御部からの指示により、
   前記バッファ部は、増設された仮想ノード用の新たな仮想ノード用帯域制限部と新たな低優先キューを追加して対応付けるとともに、他の仮想ノード用帯域制限部に対応付けられていた高優先キューを前記新たな仮想ノード用帯域制限部に対応付けるよう変更し、
   前記新たな仮想ノード用帯域制限部は、自身に対応付けられた前記高優先キューおよび前記新たな低優先キューからパケットを読み出して前記増設された仮想ノードに定められた上限帯域に制限することを特徴とする帯域制御装置。
3. 請求項１に記載の帯域制御装置であって、
   前記制御サーバが前記仮想ノードを増設することを判断した場合、前記制御部からの指示により、
   前記バッファ部は、増設された仮想ノード用の新たな仮想ノード用帯域制限部と新たな高優先キューおよび新たな低優先キューとを追加して対応付けるとともに、他の仮想ノード用帯域制限部に対応付けられていた高優先キューを削除するか無効化し、
   前記新たな仮想ノード用帯域制限部は、前記新たな高優先キューおよび前記新たな低優先キューからパケットを読み出して前記増設された仮想ノードに定められた上限帯域に制限することを特徴とする帯域制御装置。
4. 請求項１から請求項３のいずれかに記載の帯域制御装置であって、
   前記制御サーバが前記仮想ノードを減設することを判断した場合、前記制御部からの指示により、
   前記バッファ部は、減設される仮想ノード用の仮想ノード用帯域制限部に対応付けられていた高優先キューを他の仮想ノード用帯域制限部に対応付けるよう変更し、減設される仮想ノード用の仮想ノード用帯域制限部に対応付けられていた低優先キューを削除し、減設される仮想ノード用の仮想ノード用帯域制限部を削除することを特徴とする帯域制御装置。
5. 請求項１から請求項３のいずれかに記載の帯域制御装置であって、
   前記制御サーバが前記仮想ノードを減設することを判断した場合、前記制御部からの指示により、
   前記バッファ部は、減設される仮想ノード用の仮想ノード用帯域制限部に対応付けられていた高優先キューと低優先キューを削除し、かつ、減設される仮想ノード用の仮想ノード用帯域制限部を削除し、前記減設される仮想ノード用の仮想ノード用帯域制限部に対応付けられていた高優先キューに相当する高優先キューを新たに作成し、残った仮想ノード用の仮想ノード用帯域制限部に対応付けることを特徴とする帯域制御装置。
6. 請求項１から請求項５のいずれかに記載の帯域制御装置であって、
   所定の通信パケット量を計測する統計部と、
   前記バッファ部を管理するためのバッファ管理テーブルと、をさらに有し、
   前記制御部は、
   前記統計部で計測した計測結果を前記制御サーバへ送信し、
   前記制御サーバからの前記指示として、前記高優先キューおよび前記低優先キューの設定情報と、前記仮想ノード用帯域制限部の設定情報と、前記高優先キューおよび前記低優先キューと前記仮想ノード用帯域制限部との間の対応付けを決定する設定情報と、を受信して前記バッファ管理テーブルに記録し、
   前記バッファ管理テーブルに記録した設定内容に基づいて、前記バッファ部に前記対応付けを変更するための指示をすることを特徴とする帯域制御装置
7. 請求項６に記載の帯域制御装置であって、
   前記制御部は、前記制御サーバから前記計測結果の読出し要求があった場合、または、予め設定した時刻に達した場合に、前記制御サーバへ前記計測結果を送信することを特徴とする帯域制御装置。
8. 請求項６または請求項７に記載の帯域制御装置であって、
   前記バッファ管理テーブルは、
   前記仮想ノードを識別するための仮想ノード番号と、
   前記仮想ノード毎に定められた上限帯域と、
   前記仮想ノード用帯域制限部に対応付けられたキューを識別するための対応キュー情報と、
   前記バッファ部が備えるキューが前記高優先キューまたは前記低優先キューとして割り当てられているかを識別する割当状況と、
   前記バッファ部が備えるキューを識別するキュー番号と、
   前記キューに格納するパケットの通信を識別するための通信識別子と、
   前記キューに格納するパケットのユーザを識別するためのユーザ識別子と、
   前記キューを前記高優先キューと前記低優先キューのいずれとして扱うか示す優先度と、
   前記高優先キューにおいてパケット送信量を保証するための保証帯域と、
   前記高優先キューまたは前記低優先キューのキュー長と、
   を管理することを特徴とする帯域制御装置。
9. 請求項６から請求項８のいずれかに記載の帯域制御装置であって、
   前記仮想ノードがデータ転送処理を行う通信ノードである場合、
   前記統計部は、前記帯域制御装置で受信した一定時間あたりのパケットのパケット数、または、ビット数を前記仮想ノード毎に計測したものを前記所定の通信パケット量とし、
   前記仮想ノードが接続処理を行う通信ノードである場合、
   前記統計部は、前記帯域制御装置で受信した一定時間あたりの最初の接続要求を示すパケットのパケット数を前記仮想ノード毎に計測したものを前記所定の通信パケット量とすることを特徴とする帯域制御装置。
10. 請求項１から請求項９のいずれかに記載の帯域制御装置であって、
    前記上限帯域、および、前記保証帯域は、
    前記仮想ノードがデータ転送処理を行う通信ノードである場合、一定時間あたりのパケットのパケット数、または、ビット数で定められ、
    前記仮想ノードが接続処理を行う通信ノードである場合、一定時間あたりの最初の接続要求を示すパケットのパケット数で定められることを特徴とする帯域制御装置。
11. 請求項１から請求項１０のいずれかに記載の帯域制御装置であって、
    前記上限帯域は、前記制御サーバから定期的に更新されることを特徴とする帯域制御装置。
12. 請求項１から請求項１１のいずれかに記載の帯域制御装置であって、
    前記仮想ノード用帯域制限部は、１階層目の帯域制御として前記上限帯域を使用した上限帯域制御を行い、
    前記高優先キューは、２階層目の帯域制御として前記保証帯域を使用した保証帯域制御を行うことを特徴とする帯域制御装置。
13. 請求項１から請求項１１のいずれかに記載の帯域制御装置であって、
    前記バッファ部は、さらに、仮想ノード種別毎に帯域制御を行う仮想ノード種別用帯域制限部を備え、
    前記仮想ノード種別用帯域制御部は、１階層目の帯域制御として前記仮想ノード種別毎に定められた第２の上限帯域を使用した上限帯域制御を行い、
    前記仮想ノード用帯域制限部は、２階層目の帯域制御として前記上限帯域を使用した上限帯域制御を行い、
    前記高優先キューは、３階層目の帯域制御として前記保証帯域を使用した保証帯域制御を行うことを特徴とする帯域制御装置。
14. 請求項１から請求項１１のいずれかに記載の帯域制御装置であって、
    前記バッファ部は、さらに、通信事業者毎に帯域制御を行う通信事業者用帯域制限部を備え、
    前記通信事業者用帯域制限部は、１階層目の帯域制御として前記通信事業者毎に定められた第３の上限帯域を使用した上限帯域制御を行い、
    前記仮想ノード用帯域制限部は、２階層目の帯域制御として前記上限帯域を使用した上限帯域制御を行い、
    前記高優先キューは、３階層目の帯域制御として前記保証帯域を使用した保証帯域制御を行うことを特徴とする帯域制御装置。
15. 請求項１から請求項１４のいずれかに記載の帯域制御装置であって、さらに、
    受信パケットのヘッダを解析し、処理を行うべき仮想ノード情報と、該当パケットを保持するキュー情報を特定するヘッダ解析部と、
    前記仮想ノード情報と前記キュー情報に基づいてパケットを前記高優先キューおよび前記低優先キューに振分ける振分部と、を有し、
    前記振分部は、前記サーバ装置とネットワークを介して接続され、適切な仮想ノードへモバイル通信を振分けるためのロードバランサと同じ振分アルゴリズムを使用することを特徴とする帯域制御装置。
16. 請求項１から請求項１４のいずれかに記載の帯域制御装置であって、
    前記帯域制御装置は、専用のハードウェアで構成することを特徴とする帯域制御装置。
17. 請求項１から請求項１４のいずれかに記載の帯域制御装置であって、
    前記帯域制御装置は、前記サーバ装置の仮想マシンによって構成することを特徴とする帯域制御装置。

Images