輻輳制御プログラム、輻輳制御装置及び輻輳制御方法
【課題】 性能リソースの最適配分を行うことが可能な技術を提供する。
【解決手段】 各メッセージ毎の時刻に対する受信イベント数を示すトラヒックモデルを格納し、各メッセージ毎の通信性能とＣＰＵ使用率との関係を示す性能モデルを格納し、トラフィックモデルに基づいて算出された所定の時刻におけるイベント毎のＣＰＵの性能配分率を算出し、性能モデルと性能配分率とに基づいて各メッセージに対する通信性能を算出し、通信性能を満たすための処理速度を各メッセージ毎に算出し、処理速度算出工程により算出された処理速度に基づいて、キューからイベントを取り出す。
【解決手段】 各メッセージ毎の時刻に対する受信イベント数を示すトラヒックモデルを格納し、各メッセージ毎の通信性能とＣＰＵ使用率との関係を示す性能モデルを格納し、トラフィックモデルに基づいて算出された所定の時刻におけるイベント毎のＣＰＵの性能配分率を算出し、性能モデルと性能配分率とに基づいて各メッセージに対する通信性能を算出し、通信性能を満たすための処理速度を各メッセージ毎に算出し、処理速度算出工程により算出された処理速度に基づいて、キューからイベントを取り出す。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、輻輳制御の技術に関する。
【背景技術】
【０００２】
インターネット上に設置されるサーバ等、通信ネットワーク上に配備される装置には、大量のトラヒックが集中した場合にも、スループットの極端な低下やシステム停止に陥りサービス提供が不能となってしまうことを回避するために、装置の輻輳発生を抑止するための仕組みが導入されているのが一般的である。
【特許文献１】特開２００４−８８６６６号公報
【特許文献２】特開２００４−７２２４２号公報
【特許文献３】特開２００２−１５２２２４号公報
【発明の開示】
【発明が解決しようとする課題】
【０００３】
システム装置の受け口で受信したイベントをバッファリングすることで輻輳制御を行う装置では、バッファオーバ時やバッファ使用率がある閾値を越えた場合に、該当イベントを破棄することで輻輳状態を回避するのが一般的である。
【０００４】
この様な輻輳制御手法では装置性能を事前に考慮して決定した処理速度でバッファリングされているイベントに対して処理を行うことで輻輳発生を抑止する。この処理速度で処理し切れない量のイベントを受信した場合には、イベントがバッファに蓄積されていき、格納しきれないものについては破棄されることになるが、破棄されたイベントによっては、クライアントが意図したセッション状態の変更が行われないなど、通信状態の不整合が発生してしまう恐れがある。
【０００５】
一方、バッファをシステムに１つだけ保持する手法では、ある一種のイベントを一斉に受信し続ける場合、その処理のためにだけシステム稼動が占有されることになり、その他に必要な処理を行うイベントがあった場合にも一切受理されなくなる懸念がある。この問題を回避する為にイベント種別毎にバッファを設けて各々のバッファに対して処理優先度を事前に決定して置く手法もあるが、トラヒックパタンを把握できなければ適切な優先度設定が困難である。
【０００６】
本発明は、上記事情に鑑みなされたもので、性能リソースの最適配分を行うことが可能な技術を提供することを目的とする。
【課題を解決するための手段】
【０００７】
上記目的を達成するため、本発明の輻輳制御プログラムは、
コンピュータを、
各メッセージ毎の時刻に対する受信イベント数を示すトラヒックモデルを格納するトラフィックモデル保持手段、
前記各メッセージ毎の通信性能とＣＰＵ使用率との関係を示す性能モデルを格納する性能モデル保持手段、
前記トラフィックモデルに基づいて算出された所定の時刻におけるイベント毎のＣＰＵの性能配分率を算出し、前記性能モデルと前記性能配分率とに基づいて各メッセージに対する通信性能を算出し、該通信性能を満たすための処理速度を各メッセージ毎に算出する処理速度算出手段、及び、
前記処理速度算出手段により算出された処理速度に基づいて、キューからイベントを取
り出すイベント取り出し手段として機能させる。
【０００８】
また、本発明の輻輳制御プログラムは、
前記コンピュータを、
前記受信イベント数を収集し、前記トラフィックモデルを生成する収集手段として機能させる。
【０００９】
また、本発明の輻輳制御プログラムは、
前記コンピュータを、
キューに積まれたイベントの数が所定の数を超えた場合に、検出通知を出力する振り分け手段、及び、
前記検出通知を受信した際に、処理速度を変更するための処理速度変更通知を出力する監視手段として機能させ、
前記処理速度算出手段は、前記処理速度変更通知に基づいて、イベント毎の処理速度を変更する。
【００１０】
また、本発明の輻輳制御装置は、
各メッセージ毎の時刻に対する受信イベント数を示すトラヒックモデルを格納するトラフィックモデル保持手段と、
前記各メッセージ毎の通信性能とＣＰＵ使用率との関係を示す性能モデルを格納する性能モデル保持手段と、
前記トラフィックモデルに基づいて算出された所定の時刻におけるイベント毎のＣＰＵの性能配分率を算出し、前記性能モデルと前記性能配分率とに基づいて各メッセージに対する通信性能を算出し、該通信性能を満たすための処理速度を各メッセージ毎に算出する処理速度算出手段と、
前記処理速度算出手段により算出された処理速度に基づいて、キューからイベントを取り出すイベント取り出し手段とを備える。
【００１１】
また、本発明の輻輳制御方法は、
各メッセージ毎の時刻に対する受信イベント数を示すトラヒックモデルを格納するトラフィックモデル保持工程と、
前記各メッセージ毎の通信性能とＣＰＵ使用率との関係を示す性能モデルを格納する性能モデル保持工程と、
前記トラフィックモデルに基づいて算出された所定の時刻におけるイベント毎のＣＰＵの性能配分率を算出し、前記性能モデルと前記性能配分率とに基づいて各メッセージに対する通信性能を算出し、該通信性能を満たすための処理速度を各メッセージ毎に算出する処理速度算出工程と、
前記処理速度算出工程により算出された処理速度に基づいて、キューからイベントを取り出すイベント取り出し工程とを備える。
【発明の効果】
【００１２】
本発明ではトラヒックパタンを事前に予測して性能リソースを動的に分配させることが可能となる。また本発明は、輻輳状態に陥った場合にも輻輳たらしめるイベントを検出することが可能で、他イベントの為に確保されている性能リソースに空きがある場合には、該当イベントに対してより多くの性能リソースを割り当てることができる為、装置性能を最大限に生かすことが可能となる。またこの際バッファーオーバフローにより破棄されるイベント量の最小化も併せて図られる。
【発明を実施するための最良の形態】
【００１３】
以下、図面を参照して本発明を実施するための最良の形態について説明する。以下の実
施の形態の構成は例示であり、本発明は実施の形態の構成に限定されない。
【００１４】
まず、本発明の輻輳制御装置の一実施形態の概要について説明する。本実施形態では、ＳＩＰメッセージの種別毎にキューを用意し、各々のキューには処理速度を割り当て、各々のキューに対する処理速度をＳＩＰメッセージのトラヒック状況に応じて動的に変化させる手法を採用する。本手法では、トラヒックモデル、トラヒック現状値、トラヒック予測値に応じて動的に性能リソースが各ＳＩＰメッセージを処理するために配分される。本実施形態の主な特徴は、以下の３点である。
【００１５】
１）本実施形態は、トラヒックモデル、トラヒック現状値、トラヒック予測値に応じて処理速度をＳＩＰメッセージ種別毎に用意したキューに対して動的に変更させる。すなわち、本実施形態では、トラヒックに応じた性能リソースの動的分配を行う。
【００１６】
２）また、本実施形態では、キューに積まれたメッセージ数（キュー長）がキュー自体の長さに対してある割合（閾値）を越えた場合には、そのメッセージに対する処理速度を上げる様に処理速度を変動させる。このようにして、本実施形態では、破棄されるメッセージの最小化を図る。
【００１７】
３）また、本実施形態では、キューに積むイベントを選別する。全ＳＩＰメッセージを一律キューへ積む対象とするのではなく、必要と判断した重要なメッセージのみを接続遅延処理の対象とする。本実施形態では、後述のように、ＳＩＰプロトコルにおける通話開始のためのＩＮＶＩＴＥリクエストや位置情報登録のためのＲＥＧＩＳＴＥＲリクエストをキューへ積む対象としている。
【００１８】
ここで、上述の処理速度はキューからのイベント取り出し速度のことであり、イベント取り出し周期と一周期単位で取り出されるイベント数によって決定されるものである。キューに積まれているイベントは、イベント取り出し周期のサイクルで取り出しの契機が与えられ、一周期単位で処理されるイベント数分のイベントがその都度キューから取り出される。
【００１９】
次に、本発明の輻輳制御装置の一実施形態について図面を参照して説明する。図１に、本発明の輻輳制御装置の一実施形態としてのＳＩＰサーバの構成図を示す。
【００２０】
図１に示されるように、ＳＩＰサーバは、イベント刈り取り部１０１と、接続遅延処理部１０２と、ＳＩＰ信号処理部１０３と、処理速度決定部１０４と、トラフィック統計情報収集部１０５と、ＣＰＵ使用率監視部１０６と、キュー長監視部１０７とを備える。
【００２１】
接続遅延処理部１０２は、イベント種別判定部１０８と、キューへのイベント振り分け部１０９と、キューからのイベント取出し部１１０とを備える。
【００２２】
処理速度決定部１０４は、トラフィックモデル保持部１１１と、性能モデル保持部１１２と、処理速度算出部１１３とを備える。
【００２３】
イベント刈り取り部１０１は、受信したイベントを刈り取りＳＩＰ信号処理部１０３へ受け渡す。イベント刈り取り部１０１は、一度に大量のイベントを受信し刈り取れないイベントが発生した場合には、接続遅延処理の対象とするかを判断させるために、該当イベントをイベント種別判定部１０８へ渡す。ここで、キューに積むイベントを選別し、キューからイベントを取り出すまでの一連の処理を接続遅延処理と呼ぶ。
【００２４】
ここで、イベント刈り取り部１０１の動作について図２を参照して説明する。図２は、
図１に示されるイベント刈り取り部１０１の動作のフローチャートである。
【００２５】
図２に示されるように、イベント刈り取り部１０１は、ＳＩＰイベントを蓄積する（Ｓ２０１）。そして、イベント刈り取り部１０１は、イベント数がＹ以上であるか否かを判定する（Ｓ２０２）。Ｙは、イベント刈り取り部１０１が処理可能なイベント数である。
【００２６】
そして、イベント刈り取り部１０１は、イベント数がＹ以上でなければ（ＮＯ）、ＳＩＰイベントをＳＩＰ信号処理部へ送信し（Ｓ２０３）、イベント数がＹ以上であれば（ＹＥＳ）、ＳＩＰイベントをイベント種別判定部へ送信する（Ｓ２０４）。
【００２７】
次に、上述のＳＩＰイベントのデータ構造について、図３を参照して説明する。図３は、図１に示されるＳＩＰサーバにおいて使用されるＳＩＰイベントのデータ構造の概念図である。図３に示されるように、ＳＩＰイベントは、ＩＰパケットに含まれる。そして、ＳＩＰイベントは、ＳＩＰヘッダと、ＳＩＰペイロードとを備える。ＳＩＰヘッダの先頭行には、ＩＮＶＩＴＥ、ＲＥＧＩＳＴＥＲ、ＡＣＫ、ＢＹＥ、ＣＡＣＥＬ、ＯＰＴＩＯＮＳのリクエスト信号や、１ｘｘ〜６ｘｘのレスポンス信号のＳＩＰメッセージ種別が判別可能な情報が含まれている。
【００２８】
次に、イベント種別判定部１０８について説明する。イベント種別判定部１０８は、ＳＩＰヘッダ先頭行から判別可能なＳＩＰメッセージ種別を元に接続遅延処理の対象とするイベントを特定する。イベント種別判定部１０８は、接続遅延処理の対象とならないイベントを破棄する。
【００２９】
ここで、ＳＩＰヘッダについて、図４に示す。図４は、図３に示されるＳＩＰヘッダの一例を示す概念図である。図４の（ａ）は、リクエスト信号例であり、図４の（ｂ）は、レスポンス信号例である。
【００３０】
次に、キューへのイベント振り分け部１０９について説明する。キューへのイベント振り分け部１０９は、キューへイベントを振り分けてＰｕｓｈする。キューへのイベント振り分け部１０９は、もし、キューに積まれているイベントが満杯であれば、イベントを破棄する。本実施形態では、ＳＩＰメッセージのうちＩＮＶＩＴＥ及びＲＥＧＩＳＴＥＲを対象にそれぞれのキューを用意する。そして、ＩＮＶＩＴＥ信号が詰まれるキューをＩＮＶＩＴＥキュー、ＲＥＧＩＳＴＥＲ信号が詰まれるキューをＲＥＧＩＳＴＥＲキューと呼ぶ。
【００３１】
ここで、イベント種別判定部１０８及びキューへのイベント振り分け部１０９の動作について図５を参照して説明する。図５は、図１に示されるイベント種別判定部１０８及びキューへのイベント振り分け部１０９の動作のフローチャートである。
【００３２】
イベント種別判定部１０８は、ＳＩＰイベントの判定処理を行う。すなわち、ＳＩＰヘッダの先頭行からＳＩＰメッセージ種別を特定する（Ｓ５０１）。そして、イベント種別判定部１０８は、ＳＩＰメッセージ種別がＩＮＶＩＴＥもしくはＲＥＧＩＳＴＥＲであるか否かを判定する（Ｓ５０２）。イベント種別判定部１０８は、ＳＩＰメッセージ種別がＩＮＶＩＴＥもしくはＲＥＧＩＳＴＥＲでなければ（ＮＯ）、信号を破棄する（Ｓ５０４）。
【００３３】
そして、イベント種別判定部１０８は、ＳＩＰメッセージ種別がＩＮＶＩＴＥもしくはＲＥＧＩＳＴＥＲであれば（ＹＥＳ）、ＩＮＶＩＴＥもしくはＲＥＧＩＳＴＥＲをイベント振り分け部へ送信する（Ｓ５０３）。
【００３４】
キューへのイベント振り分け部１０９は、ＳＩＰメッセージ種別がＩＮＶＩＴＥであればＩＮＶＩＴＥキューへ、ＲＥＧＩＳＴＥＲであればＲＥＧＩＳＴＥＲキューへイベントをＰｕｓｈする（Ｓ５０５）。
【００３５】
キューからのイベント取り出し部１１０は、キュー毎に決定されている処理速度に従い各々のキューからイベントをＰｏｐし、ＳＩＰ信号処理部へイベントを渡す。
【００３６】
ここで、キューからのイベント取り出し部１１０の動作について図６を参照して説明する。図６は、図１に示されるキューからのイベント取り出し部１１０の動作フローチャートである。
【００３７】
図６に示されるように、まず、処理速度決定部は、該当時刻（ｔ）における処理速度を定めるイベント取り出し周期Ｔ（ｔ）と一周期単位で取り出されるイベントＮ（ｔ）を保持する（Ｓ６０１）。
【００３８】
そして、キューからのイベント取り出し部１１０は、ＩＮＶＩＴＥ及びＲＥＧＩＳＴＥＲキューの処理速度を参照する。この際、キューからのイベント取り出し部１１０は、Ｔ（ｔ）、Ｎ（ｔ）の参照を行う（Ｓ６０２）。
【００３９】
そして、キューからのイベント取り出し部１１０は、ＩＮＶＩＴＥ及びＲＥＧＩＳＴＥＲキューからのＮ（ｔ）個のイベントを取り出す（Ｓ６０３）。そして、そして、キューからのイベント取り出し部１１０は、ＩＮＶＩＴＥ及びＲＥＧＩＳＴＥＲイベントをＳＩＰ信号処理部へ送信する。そして、そして、キューからのイベント取り出し部１１０は、この処理をＴ（ｔ）周期で繰り返す。
【００４０】
ＳＩＰ信号処理部１０３は、ＳＩＰプロトコルに準拠してＶｏＩＰ呼制御を行うＳＩＰサーバ機能部である。
【００４１】
トラヒックモデル保持部１１１は、トラフィック統計情報保持部１０５にて保持されているＩＮＶＩＴＥ及びＲＥＧＩＳＴＥＲの受信時刻及び受信数に関するトラフィックモデルをトラフィックモデルとして保持している。このトラフィックモデルは定期的に更新される。また、このトラフィックモデルは処理速度を決定するための情報となる。
【００４２】
ここで、上記トラフィックモデルについて図７を参照して説明する。図７は、本発明の輻輳制御装置の一実施形態において使用されるトラフィックモデルの一例のグラフである。図７では、横軸に時刻、縦軸に受信イベント数を設定している。また、図７に示される例では、ＩＮＶＩＴＥとＲＥＧＩＳＴＥＲの例を示している。
【００４３】
性能モデル保持部１１２は、事前に測定された装置性能モデルを保持する。この装置性能モデルは、通信処理量とＣＰＵ使用率を要素とする性能グラフと、例えば図７に示されるトラヒックモデルを基に算出された、性能リソースのイベント種別毎配分率（性能配分率Ｘ）にて決定されるモデルである。性能モデル保持部１１２は、性能配分率Ｘを時刻に従い動的に変化させる。このモデルは、処理速度を決定するための情報となる。
【００４４】
ここで、上記性能モデルについて図８及び図９を参照して説明する。図８は、本発明の輻輳制御装置の一実施形態におけるＩＮＶＩＴＥのＳＩＰメッセージに対する性能モデルの概念図であり、図９は、本発明の輻輳制御装置の一実施形態におけるＲＥＧＩＳＴＥＲのＳＩＰメッセージ種別に対する性能モデルの概念図である。図８において、横軸は、ＢＨＣＡを示し、縦軸はＣＰＵ使用率を示す。ＢＨＣＡとは、１時間あたりに処理するコール数である。また、性能配分率Ｘとは、ＣＰＵの性能を各イベントの処理に配分する率で
ある。この性能配分率Ｘについては後述する。また、図９において、横軸はＡＰＳを示し、縦軸はＣＰＵ使用率を示す。ＡＰＳとは、１秒間におけるレジスタイベント処理量である。
【００４５】
処理速度算出部１１３は、上記トラヒックモデルと性能モデルを基に処理速度を各キューごとに決定する。すなわち、処理速度算出部１１３は、トラヒックモデルを基にある時刻におけるイベント種別毎性能配分率（Ｘ）を決定し、さらに性能配分率と性能モデルから時刻ｔにおけるイベント種別毎最大通信性能を求める。このように、前述の図８及び図９に示されるイベント種別毎性能配分率（Ｘ）は、各イベントの各時刻のトラフィックモデルに比例して決定される値である。処理速度算出部１１３は、このイベント種別毎最大通信性能を満たすための処理速度をイベント種別毎キューごとに算出する。
【００４６】
トラヒック統計情報収集部１０５は、イベント受信情報（イベント受信時刻とイベント種別）をロギングする。トラヒックモデルはイベント受信情報を基に作成される。ここで、トラフィック統計情報収集部１０５の動作について図１０を参照して説明する。図１０は、図１に示されるトラフィック統計情報収集部１０５の動作のフローチャートである。
【００４７】
まず、ＳＩＰ信号処理部は、ＳＩＰイベントの判定処理を行う（Ｓ１００１）。ここで、ＳＩＰ信号処理部は、ＳＩＰヘッダの先頭行からＳＩＰメッセージ種別を特定する。このＳＩＰメッセージ種別は、トラフィック統計情報収集部に通知される。トラフィック統計情報収集部は、受信したＳＩＰメッセージ種別とその受信時刻をロギングする。また、該当ＳＩＰメッセージ種別に対応するメッセージ受信数カウンタを加算する（Ｓ１００２）。
【００４８】
ＣＰＵ使用率監視部１０６は、現状のＣＰＵ使用率を監視する。ＣＰＵ使用率は、ＯＳが提供するシステムインターフェースから取得が可能である。
【００４９】
キュー長監視部１０７は、図１１に示されるように、各キュー毎にキュー長（キューに積まれたイベント数）を監視し、ある閾値を越えた場合に、該当イベントに対する処理性能をＵＰさせるために処理速度の再設定を行うように処理速度決定部１０４へ通知を行う。また、キュー長監視部１０７は、キュー長がある閾値を下回った場合に処理速度を通常状態に戻す契機を処理速度決定部１０４に与える。図１１は、本発明の輻輳制御装置の一実施形態における処理速度の再設定動作の概念図である。
【００５０】
ここで、キュー長監視部１０７の動作について図１２を参照して説明する。図１２は、図１に示されるキュー長監視部１０７の動作のフローチャートである。まず、キューへのイベント振り分け部は、ＳＩＰメッセージ種別がＩＮＶＩＴＥであればＩＮＶＩＴＥキューへ、ＲＥＧＩＳＴＥＲであればＲＥＧＩＳＴＥＲキューへイベントをＰｕｓｈする（Ｓ１２０１）。そして、キューへのイベント振り分け部は、キュー長が閾値を超えたか否かを判定する（Ｓ１２０２）。キューへのイベント振り分け部は、キュー長が閾値を超えた場合（ＹＥＳ）、キュー長閾値オーバ検出通知をキュー長監視部へ送信する（Ｓ１２０３）。
【００５１】
そして、キュー長監視部は、処理速度変更通知を処理速度決定部に送信する（Ｓ１２０４）。処理速度変更通知を受信した処理速度決定部は、Ｔ’（ｔ）、Ｎ’（ｔ）の再設定を行う（Ｓ１２０５）。
【００５２】
そして、キューへのイベント振り分け部は、ＳＩＰメッセージ種別がＩＮＶＩＴＥであればＩＮＶＩＴＥキューへ、ＲＥＧＩＳＴＥＲであればＲＥＧＩＳＴＥＲキューへイベントをＰｕｓｈする（Ｓ１２０６）。そして、キューへのイベント振り分け部は、キュー長
が閾値を下回ったか否かを判定する（Ｓ１２０７）。キューへのイベント振り分け部は、キュー長が閾値を下回った場合（ＹＥＳ）、キュー長閾値オーバ解除検出通知をキュー長監視部に送信する（Ｓ１２０８）。
【００５３】
そして、キュー長監視部は、処理速度変更通知を処理速度決定部に送信する（Ｓ１２０９）。処理速度変更通知を受信した処理速度決定部は、Ｔ（ｔ）、Ｎ（ｔ）の再設定を行う（Ｓ１２１０）。
【００５４】
＜処理速度の再設定について＞
ここで、処理速度の再設定についてさらに説明する。処理速度決定部１０４は、あるイベントの性能分配率がＸであった場合、１−Ｘ分が他イベントの処理のために確保されるが、１−Ｘ分の性能リソースが未使用若しくは空きがある場合に、本性能配分率Ｘよりも性能リソース（ＣＰＵ使用率）を該当イベントのために多く割り当てる様に接続遅延レートを決定する。処理速度決定部１０４は、性能リソースの未使用分は「１００％−現状のＣＰＵ使用率」で算出し、本値と性能モデルからさらに処理可能な通信処理量を求めて接続遅延レートを再設定する。本処理速度の再設定により未使用分の性能リソースが有効に活用される。
【００５５】
（付記１)
コンピュータを、
各メッセージ毎の時刻に対する受信イベント数を示すトラヒックモデルを格納するトラフィックモデル保持手段、
前記各メッセージ毎の通信性能とＣＰＵ使用率との関係を示す性能モデルを保持する性能モデル保持手段、
前記トラフィックモデルに基づいて算出された所定の時刻におけるイベント毎のＣＰＵの性能配分率を算出し、前記性能モデルと前記性能配分率とに基づいて各メッセージに対する通信性能を算出し、該通信性能を満たすための処理速度を各メッセージ毎に算出する処理速度算出手段、及び、
前記処理速度算出手段により算出された処理速度に基づいて、キューからイベントを取り出すイベント取り出し手段として機能させるための輻輳制御プログラム。
【００５６】
（付記２)
前記コンピュータを、
前記受信イベント数を収集し、前記トラフィックモデルを生成する収集手段として機能させる付記１記載の輻輳制御プログラム。
【００５７】
（付記３)
前記コンピュータを、
キューに積まれたイベントの数が所定の数を超えた場合に、検出通知を出力する振り分け手段、及び、
前記検出通知を受信した際に、処理速度を変更するための処理速度変更通知を出力する監視手段として機能させ、
前記処理速度算出手段は、前記処理速度変更通知に基づいて、イベント毎の処理速度を変更する付記１記載の輻輳制御プログラム。
【００５８】
（付記４)
前記処理速度算出手段は、
性能リソースの未使用分の値を、１００%−現状のＣＰＵ使用率により算出し、該算出
した性能リソースの未使用分の値と前記性能モデルから、さらに処理可能な通信性能を求めて処理速度を再設定する付記１記載の輻輳制御プログラム。
【００５９】
（付記５)
前記キューが、前記メッセージ毎に用意されている付記１記載の輻輳制御プログラム。
【００６０】
（付記６)
コンピュータを、
前記キューに積むメッセージの種別を選別する判定手段として機能させる付記１記載の輻輳制御プログラム。
【００６１】
(付記７)
各メッセージ毎の時刻に対する受信イベント数を示すトラヒックモデルを格納するトラフィックモデル保持手段と、
前記各メッセージ毎の通信性能とＣＰＵ使用率との関係を示す性能モデルを格納する性能モデル保持手段と、
前記トラフィックモデルに基づいて算出された所定の時刻におけるイベント毎のＣＰＵの性能配分率を算出し、前記性能モデルと前記性能配分率とに基づいて各メッセージに対する通信性能を算出し、該通信性能を満たすための処理速度を各メッセージ毎に算出する処理速度算出手段と、
前記処理速度算出手段により算出された処理速度に基づいて、キューからイベントを取り出すイベント取り出し手段とを備える輻輳制御装置。
【００６２】
（付記８)
各メッセージ毎の時刻に対する受信イベント数を示すトラヒックモデルを格納するトラフィックモデル保持工程と、
前記各メッセージ毎の通信性能とＣＰＵ使用率との関係を示す性能モデルを格納する性能モデル保持工程と、
前記トラフィックモデルに基づいて算出された所定の時刻におけるイベント毎のＣＰＵの性能配分率を算出し、前記性能モデルと前記性能配分率とに基づいて各メッセージに対する通信性能を算出し、該通信性能を満たすための処理速度を各メッセージ毎に算出する処理速度算出工程と、
前記処理速度算出工程により算出された処理速度に基づいて、キューからイベントを取り出すイベント取り出し工程とを備える輻輳制御方法。
【図面の簡単な説明】
【００６３】
【図１】本発明の輻輳制御装置の一実施形態としてのＳＩＰサーバの構成図である。
【図２】図１に示されるイベント刈り取り部１０１の動作のフローチャートである。
【図３】図１に示されるＳＩＰサーバにおいて使用されるＳＩＰイベントのデータ構造の概念図である。
【図４】図３に示されるＳＩＰヘッダの一例を示す概念図である。
【図５】図１に示されるイベント種別判定部１０８及びキューへのイベント振り分け部１０９の動作のフローチャートである。
【図６】図１に示されるキューからのイベント取り出し部１１０の動作フローチャートである。
【図７】本発明の輻輳制御装置の一実施形態において使用されるトラフィックモデルの一例のグラフである。
【図８】本発明の輻輳制御装置の一実施形態におけるＩＮＶＩＴＥのＳＩＰメッセージに対する性能モデルの概念図である。
【図９】本発明の輻輳制御装置の一実施形態におけるＲＥＧＩＳＴＥＲのＳＩＰメッセージ種別に対する性能モデルの概念図である。
【図１０】図１に示されるトラフィック統計情報収集部１０５の動作のフローチャートである。
【図１１】本発明の輻輳制御装置の一実施形態における処理速度の再設定動作の概念図である。
【図１２】図１に示されるキュー長監視部１０７の動作のフローチャートである。
【符号の説明】
【００６４】
１０１ イベント刈り取り部
１０２ 接続遅延処理部
１０３ ＳＩＰ信号処理部
１０４ 処理速度決定部
１０５ トラフィック統計情報収集部
１０６ ＣＰＵ使用率監視部
１０７ キュー長監視部
１０８ イベント種別判定部
１０９ キユーへのイベント振り分け部
１１０ キユーからのイベント取り出し部
１１１ トラフィックモデル保持部
１１２ 性能モデル保持部
１１３ 処理速度算出部
【技術分野】
【０００１】
本発明は、輻輳制御の技術に関する。
【背景技術】
【０００２】
インターネット上に設置されるサーバ等、通信ネットワーク上に配備される装置には、大量のトラヒックが集中した場合にも、スループットの極端な低下やシステム停止に陥りサービス提供が不能となってしまうことを回避するために、装置の輻輳発生を抑止するための仕組みが導入されているのが一般的である。
【特許文献１】特開２００４−８８６６６号公報
【特許文献２】特開２００４−７２２４２号公報
【特許文献３】特開２００２−１５２２２４号公報
【発明の開示】
【発明が解決しようとする課題】
【０００３】
システム装置の受け口で受信したイベントをバッファリングすることで輻輳制御を行う装置では、バッファオーバ時やバッファ使用率がある閾値を越えた場合に、該当イベントを破棄することで輻輳状態を回避するのが一般的である。
【０００４】
この様な輻輳制御手法では装置性能を事前に考慮して決定した処理速度でバッファリングされているイベントに対して処理を行うことで輻輳発生を抑止する。この処理速度で処理し切れない量のイベントを受信した場合には、イベントがバッファに蓄積されていき、格納しきれないものについては破棄されることになるが、破棄されたイベントによっては、クライアントが意図したセッション状態の変更が行われないなど、通信状態の不整合が発生してしまう恐れがある。
【０００５】
一方、バッファをシステムに１つだけ保持する手法では、ある一種のイベントを一斉に受信し続ける場合、その処理のためにだけシステム稼動が占有されることになり、その他に必要な処理を行うイベントがあった場合にも一切受理されなくなる懸念がある。この問題を回避する為にイベント種別毎にバッファを設けて各々のバッファに対して処理優先度を事前に決定して置く手法もあるが、トラヒックパタンを把握できなければ適切な優先度設定が困難である。
【０００６】
本発明は、上記事情に鑑みなされたもので、性能リソースの最適配分を行うことが可能な技術を提供することを目的とする。
【課題を解決するための手段】
【０００７】
上記目的を達成するため、本発明の輻輳制御プログラムは、
コンピュータを、
各メッセージ毎の時刻に対する受信イベント数を示すトラヒックモデルを格納するトラフィックモデル保持手段、
前記各メッセージ毎の通信性能とＣＰＵ使用率との関係を示す性能モデルを格納する性能モデル保持手段、
前記トラフィックモデルに基づいて算出された所定の時刻におけるイベント毎のＣＰＵの性能配分率を算出し、前記性能モデルと前記性能配分率とに基づいて各メッセージに対する通信性能を算出し、該通信性能を満たすための処理速度を各メッセージ毎に算出する処理速度算出手段、及び、
前記処理速度算出手段により算出された処理速度に基づいて、キューからイベントを取
り出すイベント取り出し手段として機能させる。
【０００８】
また、本発明の輻輳制御プログラムは、
前記コンピュータを、
前記受信イベント数を収集し、前記トラフィックモデルを生成する収集手段として機能させる。
【０００９】
また、本発明の輻輳制御プログラムは、
前記コンピュータを、
キューに積まれたイベントの数が所定の数を超えた場合に、検出通知を出力する振り分け手段、及び、
前記検出通知を受信した際に、処理速度を変更するための処理速度変更通知を出力する監視手段として機能させ、
前記処理速度算出手段は、前記処理速度変更通知に基づいて、イベント毎の処理速度を変更する。
【００１０】
また、本発明の輻輳制御装置は、
各メッセージ毎の時刻に対する受信イベント数を示すトラヒックモデルを格納するトラフィックモデル保持手段と、
前記各メッセージ毎の通信性能とＣＰＵ使用率との関係を示す性能モデルを格納する性能モデル保持手段と、
前記トラフィックモデルに基づいて算出された所定の時刻におけるイベント毎のＣＰＵの性能配分率を算出し、前記性能モデルと前記性能配分率とに基づいて各メッセージに対する通信性能を算出し、該通信性能を満たすための処理速度を各メッセージ毎に算出する処理速度算出手段と、
前記処理速度算出手段により算出された処理速度に基づいて、キューからイベントを取り出すイベント取り出し手段とを備える。
【００１１】
また、本発明の輻輳制御方法は、
各メッセージ毎の時刻に対する受信イベント数を示すトラヒックモデルを格納するトラフィックモデル保持工程と、
前記各メッセージ毎の通信性能とＣＰＵ使用率との関係を示す性能モデルを格納する性能モデル保持工程と、
前記トラフィックモデルに基づいて算出された所定の時刻におけるイベント毎のＣＰＵの性能配分率を算出し、前記性能モデルと前記性能配分率とに基づいて各メッセージに対する通信性能を算出し、該通信性能を満たすための処理速度を各メッセージ毎に算出する処理速度算出工程と、
前記処理速度算出工程により算出された処理速度に基づいて、キューからイベントを取り出すイベント取り出し工程とを備える。
【発明の効果】
【００１２】
本発明ではトラヒックパタンを事前に予測して性能リソースを動的に分配させることが可能となる。また本発明は、輻輳状態に陥った場合にも輻輳たらしめるイベントを検出することが可能で、他イベントの為に確保されている性能リソースに空きがある場合には、該当イベントに対してより多くの性能リソースを割り当てることができる為、装置性能を最大限に生かすことが可能となる。またこの際バッファーオーバフローにより破棄されるイベント量の最小化も併せて図られる。
【発明を実施するための最良の形態】
【００１３】
以下、図面を参照して本発明を実施するための最良の形態について説明する。以下の実
施の形態の構成は例示であり、本発明は実施の形態の構成に限定されない。
【００１４】
まず、本発明の輻輳制御装置の一実施形態の概要について説明する。本実施形態では、ＳＩＰメッセージの種別毎にキューを用意し、各々のキューには処理速度を割り当て、各々のキューに対する処理速度をＳＩＰメッセージのトラヒック状況に応じて動的に変化させる手法を採用する。本手法では、トラヒックモデル、トラヒック現状値、トラヒック予測値に応じて動的に性能リソースが各ＳＩＰメッセージを処理するために配分される。本実施形態の主な特徴は、以下の３点である。
【００１５】
１）本実施形態は、トラヒックモデル、トラヒック現状値、トラヒック予測値に応じて処理速度をＳＩＰメッセージ種別毎に用意したキューに対して動的に変更させる。すなわち、本実施形態では、トラヒックに応じた性能リソースの動的分配を行う。
【００１６】
２）また、本実施形態では、キューに積まれたメッセージ数（キュー長）がキュー自体の長さに対してある割合（閾値）を越えた場合には、そのメッセージに対する処理速度を上げる様に処理速度を変動させる。このようにして、本実施形態では、破棄されるメッセージの最小化を図る。
【００１７】
３）また、本実施形態では、キューに積むイベントを選別する。全ＳＩＰメッセージを一律キューへ積む対象とするのではなく、必要と判断した重要なメッセージのみを接続遅延処理の対象とする。本実施形態では、後述のように、ＳＩＰプロトコルにおける通話開始のためのＩＮＶＩＴＥリクエストや位置情報登録のためのＲＥＧＩＳＴＥＲリクエストをキューへ積む対象としている。
【００１８】
ここで、上述の処理速度はキューからのイベント取り出し速度のことであり、イベント取り出し周期と一周期単位で取り出されるイベント数によって決定されるものである。キューに積まれているイベントは、イベント取り出し周期のサイクルで取り出しの契機が与えられ、一周期単位で処理されるイベント数分のイベントがその都度キューから取り出される。
【００１９】
次に、本発明の輻輳制御装置の一実施形態について図面を参照して説明する。図１に、本発明の輻輳制御装置の一実施形態としてのＳＩＰサーバの構成図を示す。
【００２０】
図１に示されるように、ＳＩＰサーバは、イベント刈り取り部１０１と、接続遅延処理部１０２と、ＳＩＰ信号処理部１０３と、処理速度決定部１０４と、トラフィック統計情報収集部１０５と、ＣＰＵ使用率監視部１０６と、キュー長監視部１０７とを備える。
【００２１】
接続遅延処理部１０２は、イベント種別判定部１０８と、キューへのイベント振り分け部１０９と、キューからのイベント取出し部１１０とを備える。
【００２２】
処理速度決定部１０４は、トラフィックモデル保持部１１１と、性能モデル保持部１１２と、処理速度算出部１１３とを備える。
【００２３】
イベント刈り取り部１０１は、受信したイベントを刈り取りＳＩＰ信号処理部１０３へ受け渡す。イベント刈り取り部１０１は、一度に大量のイベントを受信し刈り取れないイベントが発生した場合には、接続遅延処理の対象とするかを判断させるために、該当イベントをイベント種別判定部１０８へ渡す。ここで、キューに積むイベントを選別し、キューからイベントを取り出すまでの一連の処理を接続遅延処理と呼ぶ。
【００２４】
ここで、イベント刈り取り部１０１の動作について図２を参照して説明する。図２は、
図１に示されるイベント刈り取り部１０１の動作のフローチャートである。
【００２５】
図２に示されるように、イベント刈り取り部１０１は、ＳＩＰイベントを蓄積する（Ｓ２０１）。そして、イベント刈り取り部１０１は、イベント数がＹ以上であるか否かを判定する（Ｓ２０２）。Ｙは、イベント刈り取り部１０１が処理可能なイベント数である。
【００２６】
そして、イベント刈り取り部１０１は、イベント数がＹ以上でなければ（ＮＯ）、ＳＩＰイベントをＳＩＰ信号処理部へ送信し（Ｓ２０３）、イベント数がＹ以上であれば（ＹＥＳ）、ＳＩＰイベントをイベント種別判定部へ送信する（Ｓ２０４）。
【００２７】
次に、上述のＳＩＰイベントのデータ構造について、図３を参照して説明する。図３は、図１に示されるＳＩＰサーバにおいて使用されるＳＩＰイベントのデータ構造の概念図である。図３に示されるように、ＳＩＰイベントは、ＩＰパケットに含まれる。そして、ＳＩＰイベントは、ＳＩＰヘッダと、ＳＩＰペイロードとを備える。ＳＩＰヘッダの先頭行には、ＩＮＶＩＴＥ、ＲＥＧＩＳＴＥＲ、ＡＣＫ、ＢＹＥ、ＣＡＣＥＬ、ＯＰＴＩＯＮＳのリクエスト信号や、１ｘｘ〜６ｘｘのレスポンス信号のＳＩＰメッセージ種別が判別可能な情報が含まれている。
【００２８】
次に、イベント種別判定部１０８について説明する。イベント種別判定部１０８は、ＳＩＰヘッダ先頭行から判別可能なＳＩＰメッセージ種別を元に接続遅延処理の対象とするイベントを特定する。イベント種別判定部１０８は、接続遅延処理の対象とならないイベントを破棄する。
【００２９】
ここで、ＳＩＰヘッダについて、図４に示す。図４は、図３に示されるＳＩＰヘッダの一例を示す概念図である。図４の（ａ）は、リクエスト信号例であり、図４の（ｂ）は、レスポンス信号例である。
【００３０】
次に、キューへのイベント振り分け部１０９について説明する。キューへのイベント振り分け部１０９は、キューへイベントを振り分けてＰｕｓｈする。キューへのイベント振り分け部１０９は、もし、キューに積まれているイベントが満杯であれば、イベントを破棄する。本実施形態では、ＳＩＰメッセージのうちＩＮＶＩＴＥ及びＲＥＧＩＳＴＥＲを対象にそれぞれのキューを用意する。そして、ＩＮＶＩＴＥ信号が詰まれるキューをＩＮＶＩＴＥキュー、ＲＥＧＩＳＴＥＲ信号が詰まれるキューをＲＥＧＩＳＴＥＲキューと呼ぶ。
【００３１】
ここで、イベント種別判定部１０８及びキューへのイベント振り分け部１０９の動作について図５を参照して説明する。図５は、図１に示されるイベント種別判定部１０８及びキューへのイベント振り分け部１０９の動作のフローチャートである。
【００３２】
イベント種別判定部１０８は、ＳＩＰイベントの判定処理を行う。すなわち、ＳＩＰヘッダの先頭行からＳＩＰメッセージ種別を特定する（Ｓ５０１）。そして、イベント種別判定部１０８は、ＳＩＰメッセージ種別がＩＮＶＩＴＥもしくはＲＥＧＩＳＴＥＲであるか否かを判定する（Ｓ５０２）。イベント種別判定部１０８は、ＳＩＰメッセージ種別がＩＮＶＩＴＥもしくはＲＥＧＩＳＴＥＲでなければ（ＮＯ）、信号を破棄する（Ｓ５０４）。
【００３３】
そして、イベント種別判定部１０８は、ＳＩＰメッセージ種別がＩＮＶＩＴＥもしくはＲＥＧＩＳＴＥＲであれば（ＹＥＳ）、ＩＮＶＩＴＥもしくはＲＥＧＩＳＴＥＲをイベント振り分け部へ送信する（Ｓ５０３）。
【００３４】
キューへのイベント振り分け部１０９は、ＳＩＰメッセージ種別がＩＮＶＩＴＥであればＩＮＶＩＴＥキューへ、ＲＥＧＩＳＴＥＲであればＲＥＧＩＳＴＥＲキューへイベントをＰｕｓｈする（Ｓ５０５）。
【００３５】
キューからのイベント取り出し部１１０は、キュー毎に決定されている処理速度に従い各々のキューからイベントをＰｏｐし、ＳＩＰ信号処理部へイベントを渡す。
【００３６】
ここで、キューからのイベント取り出し部１１０の動作について図６を参照して説明する。図６は、図１に示されるキューからのイベント取り出し部１１０の動作フローチャートである。
【００３７】
図６に示されるように、まず、処理速度決定部は、該当時刻（ｔ）における処理速度を定めるイベント取り出し周期Ｔ（ｔ）と一周期単位で取り出されるイベントＮ（ｔ）を保持する（Ｓ６０１）。
【００３８】
そして、キューからのイベント取り出し部１１０は、ＩＮＶＩＴＥ及びＲＥＧＩＳＴＥＲキューの処理速度を参照する。この際、キューからのイベント取り出し部１１０は、Ｔ（ｔ）、Ｎ（ｔ）の参照を行う（Ｓ６０２）。
【００３９】
そして、キューからのイベント取り出し部１１０は、ＩＮＶＩＴＥ及びＲＥＧＩＳＴＥＲキューからのＮ（ｔ）個のイベントを取り出す（Ｓ６０３）。そして、そして、キューからのイベント取り出し部１１０は、ＩＮＶＩＴＥ及びＲＥＧＩＳＴＥＲイベントをＳＩＰ信号処理部へ送信する。そして、そして、キューからのイベント取り出し部１１０は、この処理をＴ（ｔ）周期で繰り返す。
【００４０】
ＳＩＰ信号処理部１０３は、ＳＩＰプロトコルに準拠してＶｏＩＰ呼制御を行うＳＩＰサーバ機能部である。
【００４１】
トラヒックモデル保持部１１１は、トラフィック統計情報保持部１０５にて保持されているＩＮＶＩＴＥ及びＲＥＧＩＳＴＥＲの受信時刻及び受信数に関するトラフィックモデルをトラフィックモデルとして保持している。このトラフィックモデルは定期的に更新される。また、このトラフィックモデルは処理速度を決定するための情報となる。
【００４２】
ここで、上記トラフィックモデルについて図７を参照して説明する。図７は、本発明の輻輳制御装置の一実施形態において使用されるトラフィックモデルの一例のグラフである。図７では、横軸に時刻、縦軸に受信イベント数を設定している。また、図７に示される例では、ＩＮＶＩＴＥとＲＥＧＩＳＴＥＲの例を示している。
【００４３】
性能モデル保持部１１２は、事前に測定された装置性能モデルを保持する。この装置性能モデルは、通信処理量とＣＰＵ使用率を要素とする性能グラフと、例えば図７に示されるトラヒックモデルを基に算出された、性能リソースのイベント種別毎配分率（性能配分率Ｘ）にて決定されるモデルである。性能モデル保持部１１２は、性能配分率Ｘを時刻に従い動的に変化させる。このモデルは、処理速度を決定するための情報となる。
【００４４】
ここで、上記性能モデルについて図８及び図９を参照して説明する。図８は、本発明の輻輳制御装置の一実施形態におけるＩＮＶＩＴＥのＳＩＰメッセージに対する性能モデルの概念図であり、図９は、本発明の輻輳制御装置の一実施形態におけるＲＥＧＩＳＴＥＲのＳＩＰメッセージ種別に対する性能モデルの概念図である。図８において、横軸は、ＢＨＣＡを示し、縦軸はＣＰＵ使用率を示す。ＢＨＣＡとは、１時間あたりに処理するコール数である。また、性能配分率Ｘとは、ＣＰＵの性能を各イベントの処理に配分する率で
ある。この性能配分率Ｘについては後述する。また、図９において、横軸はＡＰＳを示し、縦軸はＣＰＵ使用率を示す。ＡＰＳとは、１秒間におけるレジスタイベント処理量である。
【００４５】
処理速度算出部１１３は、上記トラヒックモデルと性能モデルを基に処理速度を各キューごとに決定する。すなわち、処理速度算出部１１３は、トラヒックモデルを基にある時刻におけるイベント種別毎性能配分率（Ｘ）を決定し、さらに性能配分率と性能モデルから時刻ｔにおけるイベント種別毎最大通信性能を求める。このように、前述の図８及び図９に示されるイベント種別毎性能配分率（Ｘ）は、各イベントの各時刻のトラフィックモデルに比例して決定される値である。処理速度算出部１１３は、このイベント種別毎最大通信性能を満たすための処理速度をイベント種別毎キューごとに算出する。
【００４６】
トラヒック統計情報収集部１０５は、イベント受信情報（イベント受信時刻とイベント種別）をロギングする。トラヒックモデルはイベント受信情報を基に作成される。ここで、トラフィック統計情報収集部１０５の動作について図１０を参照して説明する。図１０は、図１に示されるトラフィック統計情報収集部１０５の動作のフローチャートである。
【００４７】
まず、ＳＩＰ信号処理部は、ＳＩＰイベントの判定処理を行う（Ｓ１００１）。ここで、ＳＩＰ信号処理部は、ＳＩＰヘッダの先頭行からＳＩＰメッセージ種別を特定する。このＳＩＰメッセージ種別は、トラフィック統計情報収集部に通知される。トラフィック統計情報収集部は、受信したＳＩＰメッセージ種別とその受信時刻をロギングする。また、該当ＳＩＰメッセージ種別に対応するメッセージ受信数カウンタを加算する（Ｓ１００２）。
【００４８】
ＣＰＵ使用率監視部１０６は、現状のＣＰＵ使用率を監視する。ＣＰＵ使用率は、ＯＳが提供するシステムインターフェースから取得が可能である。
【００４９】
キュー長監視部１０７は、図１１に示されるように、各キュー毎にキュー長（キューに積まれたイベント数）を監視し、ある閾値を越えた場合に、該当イベントに対する処理性能をＵＰさせるために処理速度の再設定を行うように処理速度決定部１０４へ通知を行う。また、キュー長監視部１０７は、キュー長がある閾値を下回った場合に処理速度を通常状態に戻す契機を処理速度決定部１０４に与える。図１１は、本発明の輻輳制御装置の一実施形態における処理速度の再設定動作の概念図である。
【００５０】
ここで、キュー長監視部１０７の動作について図１２を参照して説明する。図１２は、図１に示されるキュー長監視部１０７の動作のフローチャートである。まず、キューへのイベント振り分け部は、ＳＩＰメッセージ種別がＩＮＶＩＴＥであればＩＮＶＩＴＥキューへ、ＲＥＧＩＳＴＥＲであればＲＥＧＩＳＴＥＲキューへイベントをＰｕｓｈする（Ｓ１２０１）。そして、キューへのイベント振り分け部は、キュー長が閾値を超えたか否かを判定する（Ｓ１２０２）。キューへのイベント振り分け部は、キュー長が閾値を超えた場合（ＹＥＳ）、キュー長閾値オーバ検出通知をキュー長監視部へ送信する（Ｓ１２０３）。
【００５１】
そして、キュー長監視部は、処理速度変更通知を処理速度決定部に送信する（Ｓ１２０４）。処理速度変更通知を受信した処理速度決定部は、Ｔ’（ｔ）、Ｎ’（ｔ）の再設定を行う（Ｓ１２０５）。
【００５２】
そして、キューへのイベント振り分け部は、ＳＩＰメッセージ種別がＩＮＶＩＴＥであればＩＮＶＩＴＥキューへ、ＲＥＧＩＳＴＥＲであればＲＥＧＩＳＴＥＲキューへイベントをＰｕｓｈする（Ｓ１２０６）。そして、キューへのイベント振り分け部は、キュー長
が閾値を下回ったか否かを判定する（Ｓ１２０７）。キューへのイベント振り分け部は、キュー長が閾値を下回った場合（ＹＥＳ）、キュー長閾値オーバ解除検出通知をキュー長監視部に送信する（Ｓ１２０８）。
【００５３】
そして、キュー長監視部は、処理速度変更通知を処理速度決定部に送信する（Ｓ１２０９）。処理速度変更通知を受信した処理速度決定部は、Ｔ（ｔ）、Ｎ（ｔ）の再設定を行う（Ｓ１２１０）。
【００５４】
＜処理速度の再設定について＞
ここで、処理速度の再設定についてさらに説明する。処理速度決定部１０４は、あるイベントの性能分配率がＸであった場合、１−Ｘ分が他イベントの処理のために確保されるが、１−Ｘ分の性能リソースが未使用若しくは空きがある場合に、本性能配分率Ｘよりも性能リソース（ＣＰＵ使用率）を該当イベントのために多く割り当てる様に接続遅延レートを決定する。処理速度決定部１０４は、性能リソースの未使用分は「１００％−現状のＣＰＵ使用率」で算出し、本値と性能モデルからさらに処理可能な通信処理量を求めて接続遅延レートを再設定する。本処理速度の再設定により未使用分の性能リソースが有効に活用される。
【００５５】
（付記１)
コンピュータを、
各メッセージ毎の時刻に対する受信イベント数を示すトラヒックモデルを格納するトラフィックモデル保持手段、
前記各メッセージ毎の通信性能とＣＰＵ使用率との関係を示す性能モデルを保持する性能モデル保持手段、
前記トラフィックモデルに基づいて算出された所定の時刻におけるイベント毎のＣＰＵの性能配分率を算出し、前記性能モデルと前記性能配分率とに基づいて各メッセージに対する通信性能を算出し、該通信性能を満たすための処理速度を各メッセージ毎に算出する処理速度算出手段、及び、
前記処理速度算出手段により算出された処理速度に基づいて、キューからイベントを取り出すイベント取り出し手段として機能させるための輻輳制御プログラム。
【００５６】
（付記２)
前記コンピュータを、
前記受信イベント数を収集し、前記トラフィックモデルを生成する収集手段として機能させる付記１記載の輻輳制御プログラム。
【００５７】
（付記３)
前記コンピュータを、
キューに積まれたイベントの数が所定の数を超えた場合に、検出通知を出力する振り分け手段、及び、
前記検出通知を受信した際に、処理速度を変更するための処理速度変更通知を出力する監視手段として機能させ、
前記処理速度算出手段は、前記処理速度変更通知に基づいて、イベント毎の処理速度を変更する付記１記載の輻輳制御プログラム。
【００５８】
（付記４)
前記処理速度算出手段は、
性能リソースの未使用分の値を、１００%−現状のＣＰＵ使用率により算出し、該算出
した性能リソースの未使用分の値と前記性能モデルから、さらに処理可能な通信性能を求めて処理速度を再設定する付記１記載の輻輳制御プログラム。
【００５９】
（付記５)
前記キューが、前記メッセージ毎に用意されている付記１記載の輻輳制御プログラム。
【００６０】
（付記６)
コンピュータを、
前記キューに積むメッセージの種別を選別する判定手段として機能させる付記１記載の輻輳制御プログラム。
【００６１】
(付記７)
各メッセージ毎の時刻に対する受信イベント数を示すトラヒックモデルを格納するトラフィックモデル保持手段と、
前記各メッセージ毎の通信性能とＣＰＵ使用率との関係を示す性能モデルを格納する性能モデル保持手段と、
前記トラフィックモデルに基づいて算出された所定の時刻におけるイベント毎のＣＰＵの性能配分率を算出し、前記性能モデルと前記性能配分率とに基づいて各メッセージに対する通信性能を算出し、該通信性能を満たすための処理速度を各メッセージ毎に算出する処理速度算出手段と、
前記処理速度算出手段により算出された処理速度に基づいて、キューからイベントを取り出すイベント取り出し手段とを備える輻輳制御装置。
【００６２】
（付記８)
各メッセージ毎の時刻に対する受信イベント数を示すトラヒックモデルを格納するトラフィックモデル保持工程と、
前記各メッセージ毎の通信性能とＣＰＵ使用率との関係を示す性能モデルを格納する性能モデル保持工程と、
前記トラフィックモデルに基づいて算出された所定の時刻におけるイベント毎のＣＰＵの性能配分率を算出し、前記性能モデルと前記性能配分率とに基づいて各メッセージに対する通信性能を算出し、該通信性能を満たすための処理速度を各メッセージ毎に算出する処理速度算出工程と、
前記処理速度算出工程により算出された処理速度に基づいて、キューからイベントを取り出すイベント取り出し工程とを備える輻輳制御方法。
【図面の簡単な説明】
【００６３】
【図１】本発明の輻輳制御装置の一実施形態としてのＳＩＰサーバの構成図である。
【図２】図１に示されるイベント刈り取り部１０１の動作のフローチャートである。
【図３】図１に示されるＳＩＰサーバにおいて使用されるＳＩＰイベントのデータ構造の概念図である。
【図４】図３に示されるＳＩＰヘッダの一例を示す概念図である。
【図５】図１に示されるイベント種別判定部１０８及びキューへのイベント振り分け部１０９の動作のフローチャートである。
【図６】図１に示されるキューからのイベント取り出し部１１０の動作フローチャートである。
【図７】本発明の輻輳制御装置の一実施形態において使用されるトラフィックモデルの一例のグラフである。
【図８】本発明の輻輳制御装置の一実施形態におけるＩＮＶＩＴＥのＳＩＰメッセージに対する性能モデルの概念図である。
【図９】本発明の輻輳制御装置の一実施形態におけるＲＥＧＩＳＴＥＲのＳＩＰメッセージ種別に対する性能モデルの概念図である。
【図１０】図１に示されるトラフィック統計情報収集部１０５の動作のフローチャートである。
【図１１】本発明の輻輳制御装置の一実施形態における処理速度の再設定動作の概念図である。
【図１２】図１に示されるキュー長監視部１０７の動作のフローチャートである。
【符号の説明】
【００６４】
１０１ イベント刈り取り部
１０２ 接続遅延処理部
１０３ ＳＩＰ信号処理部
１０４ 処理速度決定部
１０５ トラフィック統計情報収集部
１０６ ＣＰＵ使用率監視部
１０７ キュー長監視部
１０８ イベント種別判定部
１０９ キユーへのイベント振り分け部
１１０ キユーからのイベント取り出し部
１１１ トラフィックモデル保持部
１１２ 性能モデル保持部
１１３ 処理速度算出部
【特許請求の範囲】
【請求項１】
コンピュータを、
各メッセージ毎の時刻に対する受信イベント数を示すトラヒックモデルを格納するトラフィックモデル保持手段、
前記各メッセージ毎の通信性能とＣＰＵ使用率との関係を示す性能モデルを格納する性能モデル保持手段、
前記トラフィックモデルに基づいて算出された所定の時刻におけるイベント毎のＣＰＵの性能配分率を算出し、前記性能モデルと前記性能配分率とに基づいて各メッセージに対する通信性能を算出し、該通信性能を満たすための処理速度を各メッセージ毎に算出する処理速度算出手段、及び、
前記処理速度算出手段により算出された処理速度に基づいて、キューからイベントを取り出すイベント取り出し手段として機能させるための輻輳制御プログラム。
【請求項２】
前記コンピュータを、
前記受信イベント数を収集し、前記トラフィックモデルを生成する収集手段として機能させる請求項１記載の輻輳制御プログラム。
【請求項３】
前記コンピュータを、
キューに積まれたイベントの数が所定の数を超えた場合に、検出通知を出力する振り分け手段、及び、
前記検出通知を受信した際に、処理速度を変更するための処理速度変更通知を出力する監視手段として機能させ、
前記処理速度算出手段は、前記処理速度変更通知に基づいて、イベント毎の処理速度を変更する請求項１記載の輻輳制御プログラム。
【請求項４】
各メッセージ毎の時刻に対する受信イベント数を示すトラヒックモデルを格納するトラフィックモデル保持手段と、
前記各メッセージ毎の通信性能とＣＰＵ使用率との関係を示す性能モデルを格納する性能モデル保持手段と、
前記トラフィックモデルに基づいて算出された所定の時刻におけるイベント毎のＣＰＵの性能配分率を算出し、前記性能モデルと前記性能配分率とに基づいて各メッセージに対する通信性能を算出し、該通信性能を満たすための処理速度を各メッセージ毎に算出する処理速度算出手段と、
前記処理速度算出手段により算出された処理速度に基づいて、キューからイベントを取り出すイベント取り出し手段とを備える輻輳制御装置。
【請求項５】
各メッセージ毎の時刻に対する受信イベント数を示すトラヒックモデルを格納するトラフィックモデル保持工程と、
前記各メッセージ毎の通信性能とＣＰＵ使用率との関係を示す性能モデルを格納する性能モデル保持工程と、
前記トラフィックモデルに基づいて算出された所定の時刻におけるイベント毎のＣＰＵの性能配分率を算出し、前記性能モデルと前記性能配分率とに基づいて各メッセージに対する通信性能を算出し、該通信性能を満たすための処理速度を各メッセージ毎に算出する処理速度算出工程と、
前記処理速度算出工程により算出された処理速度に基づいて、キューからイベントを取り出すイベント取り出し工程とを備える輻輳制御方法。
【請求項１】
コンピュータを、
各メッセージ毎の時刻に対する受信イベント数を示すトラヒックモデルを格納するトラフィックモデル保持手段、
前記各メッセージ毎の通信性能とＣＰＵ使用率との関係を示す性能モデルを格納する性能モデル保持手段、
前記トラフィックモデルに基づいて算出された所定の時刻におけるイベント毎のＣＰＵの性能配分率を算出し、前記性能モデルと前記性能配分率とに基づいて各メッセージに対する通信性能を算出し、該通信性能を満たすための処理速度を各メッセージ毎に算出する処理速度算出手段、及び、
前記処理速度算出手段により算出された処理速度に基づいて、キューからイベントを取り出すイベント取り出し手段として機能させるための輻輳制御プログラム。
【請求項２】
前記コンピュータを、
前記受信イベント数を収集し、前記トラフィックモデルを生成する収集手段として機能させる請求項１記載の輻輳制御プログラム。
【請求項３】
前記コンピュータを、
キューに積まれたイベントの数が所定の数を超えた場合に、検出通知を出力する振り分け手段、及び、
前記検出通知を受信した際に、処理速度を変更するための処理速度変更通知を出力する監視手段として機能させ、
前記処理速度算出手段は、前記処理速度変更通知に基づいて、イベント毎の処理速度を変更する請求項１記載の輻輳制御プログラム。
【請求項４】
各メッセージ毎の時刻に対する受信イベント数を示すトラヒックモデルを格納するトラフィックモデル保持手段と、
前記各メッセージ毎の通信性能とＣＰＵ使用率との関係を示す性能モデルを格納する性能モデル保持手段と、
前記トラフィックモデルに基づいて算出された所定の時刻におけるイベント毎のＣＰＵの性能配分率を算出し、前記性能モデルと前記性能配分率とに基づいて各メッセージに対する通信性能を算出し、該通信性能を満たすための処理速度を各メッセージ毎に算出する処理速度算出手段と、
前記処理速度算出手段により算出された処理速度に基づいて、キューからイベントを取り出すイベント取り出し手段とを備える輻輳制御装置。
【請求項５】
各メッセージ毎の時刻に対する受信イベント数を示すトラヒックモデルを格納するトラフィックモデル保持工程と、
前記各メッセージ毎の通信性能とＣＰＵ使用率との関係を示す性能モデルを格納する性能モデル保持工程と、
前記トラフィックモデルに基づいて算出された所定の時刻におけるイベント毎のＣＰＵの性能配分率を算出し、前記性能モデルと前記性能配分率とに基づいて各メッセージに対する通信性能を算出し、該通信性能を満たすための処理速度を各メッセージ毎に算出する処理速度算出工程と、
前記処理速度算出工程により算出された処理速度に基づいて、キューからイベントを取り出すイベント取り出し工程とを備える輻輳制御方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【公開番号】特開２００６−１５７８０２（Ｐ２００６−１５７８０２Ａ）
【公開日】平成１８年６月１５日（２００６．６．１５）
【国際特許分類】
【出願番号】特願２００４−３４８６５５（Ｐ２００４−３４８６５５）
【出願日】平成１６年１２月１日（２００４．１２．１）
【出願人】（０００００５２２３）富士通株式会社 (25,993)
【Ｆターム（参考）】
【公開日】平成１８年６月１５日（２００６．６．１５）
【国際特許分類】
【出願日】平成１６年１２月１日（２００４．１２．１）
【出願人】（０００００５２２３）富士通株式会社 (25,993)
【Ｆターム（参考）】
[ Back to top ]