JP5580253B2 - 呼接続装置およびその動作方法 - Google Patents

Description

本発明は、呼接続装置およびその動作方法に関するものである。

メディアサーバは、記憶装置に蓄積された音声や映像ファイルをデコードし、メディアストリームとして、ネットワーク経由で端末に送信するサーバである。

メディアサーバでは、呼が多数接続され、過負荷状態になると、メディアストリームを正常に送信できず、サービス品質が低下する。かかる事態を防ぐため、メディアサーバでは、呼の接続数を少なくする必要がある。

一方、端末としては、携帯端末から高精細映像端末まで、画面解像度やフレームレート等により異なる様々な種類のものがあり、メディアサーバで使用されるコーデックも多様である。デコードに必要なリソース量は、コーデックの種類により異なる。また、コーデックの種類などにより、呼は、必要なリソース量が少ない低負荷呼と、必要なリソース量が多い高負荷呼に分類される。

低負荷呼なら、接続数を多くできるが、高負荷呼なら接続数は少なくなる。

一般に、多数の端末にメディアストリームを送信する場合、複数のメディアサーバを設け、さらに、端末からの接続要求により呼を各メディアサーバへ接続させる呼接続装置を用いる。例えば、呼接続装置は、呼をランダムに振り分けて接続したり、呼をメディアサーバの負荷に応じて振り分けて接続する(非特許文献１参照)。

トニーブルーク著、「サーバ負荷分散技術」、オライリージャパン(2001) 島内他編、「アルゴリズム辞典」、共立出版(1994)

しかし、かかる方法では、メディアサーバ間で負荷に偏りが生じやすい。

例えば、軽負荷のメディアサーバに呼を接続する方法の場合、全てのメディアサーバでの空きリソース量を合計すると、高負荷呼を接続できるだけの量があるのに、個々のサーバでの空きリソース量は、高負荷呼を接続できる量に足りず、よって、高負荷呼を接続できない場合がある。

このような分割損を少なくする問題は、ビンパッキング問題という数理計画問題に定式化され、様々なアルゴリズムが考案されている。

しかし、このアルゴリズムは、予め与えられた全ての要求を満足する解を求めるものであるため、メディアサーバ間で空きリソース量や負荷の偏りが生じやすい。

また、メディアストリームの送信が終了し、呼が切断され、空きリソースが増えていき、負荷が軽減していくことを考慮していないので、呼接続装置の動作アルゴリズムとしては、そのままでは使用できない。

また、かかる問題は、メディアサーバのみならず、あらゆる種類のサーバに共通するものである。

本発明は、上記の課題に鑑みてなされたものであり、その目的とするところは、複数のサーバへ負荷が分散するように呼を接続でき、かつ、サーバ間での負荷の偏りを可及的に小さくできる呼接続装置およびその動作方法を提供することにある。

上記の課題を解決するために、第１の本発明は、複数のサーバへ負荷が分散するように呼を接続させる呼接続装置であって、サーバへの負荷の大きさにより高負荷呼に分類される呼がサーバに接続されたときのサーバでの必要なリソース量である第１のリソース量ならびに高負荷呼でない低負荷呼に分類される呼がサーバに接続されたときの必要なリソース量である第２のリソース量を予め記憶した呼種別必要リソーステーブルと、前記各サーバにつき、該サーバでの空きのリソース量である空きリソース量を管理するサーバ別リソース管理テーブルと、呼をサーバに接続させるにあたり、当該呼が高負荷であるか低負荷呼であるかを判定し、当該呼が高負荷呼であるなら、前記呼種別必要リソーステーブルから第１のリソース量を読み出し、前記サーバ別リソース管理テーブルから各空きリソース量を読み出し、

ただし、Ｒｖｉは、サーバｉについての空きリソース量、Ｒαは、第１のリソース量、を満たす１つの当該空きリソース量を選択し、該空きリソース量に対応するサーバに当該呼を接続させる一方、当該呼が低負荷呼であるなら、前記呼種別必要リソーステーブルから第１、第２のリソース量を読み出し、前記サーバ別リソース管理テーブルから各空きリソース量を読み出し、

ただし、Ｒｖｉは、サーバｉについての空きリソース量、Ｒαは、第１のリソース量、Ｒβは、第２のリソース量、ｍｏｄ（Ｒｖｉ、Ｒα）は、空きリソース量Ｒｖｉを第１のリソース量Ｒαで割った剰余、を満たす１つの空きリソース量を選択し、該空きリソース量に対応するサーバに当該呼を接続させる呼接続部とを備えることを特徴とする。

第２の本発明は、複数のサーバへ負荷が分散するように呼を接続させる呼接続装置の動作方法であって、前記呼接続装置は、サーバへの負荷の大きさにより高負荷呼に分類される呼がサーバに接続されたときのサーバでの必要なリソース量である第１のリソース量ならびに高負荷呼でない低負荷呼に分類される呼がサーバに接続されたときの必要なリソース量である第２のリソース量を予め記憶した呼種別必要リソーステーブルと、前記各サーバにつき、該サーバでの空きのリソース量である空きリソース量を管理するサーバ別リソース管理テーブルとを備え、前記動作方法は、前記呼接続装置の呼接続部が、呼をサーバに接続させるにあたり、当該呼が高負荷であるか低負荷呼であるかを判定し、前記呼接続部が、当該呼が高負荷呼であるなら、前記呼種別必要リソーステーブルから第１のリソース量を読み出し、前記サーバ別リソース管理テーブルから各空きリソース量を読み出し、

ただし、Ｒｖｉは、サーバｉについての空きリソース量、Ｒαは、第１のリソース量、 を満たす１つの当該空きリソース量を選択し、該空きリソース量に対応するサーバに当該呼を接続させる一方、当該呼が低負荷呼であるなら、前記呼種別必要リソーステーブルから第１、第２のリソース量を読み出し、前記サーバ別リソース管理テーブルから各空きリソース量を読み出し、

ただし、Ｒｖｉは、サーバｉについての空きリソース量、Ｒαは、第１のリソース量、Ｒβは、第２のリソース量、ｍｏｄ（Ｒｖｉ、Ｒα）は、空きリソース量Ｒｖｉを第１のリソース量Ｒαで割った剰余、を満たす１つの空きリソース量を選択し、該空きリソース量に対応するサーバに当該呼を接続させることを特徴とする。

本発明によれば、複数のサーバへ負荷が分散するように呼を接続でき、かつ、サーバ間での負荷の偏りを可及的に小さくすることができる。

本実施の形態に係る呼接続装置を含む通信システムの構成図である。 呼種別必要リソーステーブル１１の構成の一例を示す図である。 サーバ別リソース管理テーブル１２の構成の一例を示す図である。 呼接続装置１の動作を示すフローチャートである。 本実施の形態により得られる効果を説明するための図である。 第１の変形例により得られる効果を説明するための図である。 第２の変形例で使用される継続時間長テーブル１４の構成の一例を示す図である。 第２の変形例で使用される呼種別必要リソーステーブル１１Ａの構成の一例を示す図である。 第２の変形例で使用されるサーバ別リソース管理テーブル１２Ａの構成の一例を示す図である。

以下、本発明の実施の形態について図面を参照して説明する。

図１は、本実施の形態に係る呼接続装置を含む通信システムの構成図である。

呼接続装置１は、ネットワーク２および複数のメディアサーバ３に接続される。ネットワーク２には、複数の端末４が接続される。以下、メディアサーバ３を単にサーバ３という。

呼接続装置１は、各サーバ３へ負荷が分散するように呼を接続させる呼接続装置であって、呼種別必要リソーステーブル１１、サーバ別リソース管理テーブル１２、呼接続部１３を備える。

図２は、呼種別必要リソーステーブル１１の構成の一例を示す図である。

呼種別必要リソーステーブル１１は、（１）サーバ３への負荷の大きさにより高負荷呼に分類される呼がサーバ３に接続されたときのサーバ３での必要なリソース量である第１のリソース量Ｒαならびに（２）高負荷呼でない低負荷呼に分類される呼がサーバ３に接続されたときの必要なリソース量である第２のリソース量Ｒβを予め記憶したものである。

サーバ３は、呼が接続されたなら、予め記憶したメディアデータファイルを対応するコーデックでデコードし、得たメディアストリームを呼の接続要求の送信元である端末４に送信する。リソース量とは、デコード中において中央演算装置（ＣＰＵ）にて必要となる処理能力の量や必要なメモリ量などである。

高負荷呼とは、ここでは、予め定められた値以上のリソース量を必要とするデコードの場合の呼をいい、低負荷呼とは、当該値未満のリソース量を必要とするデコードの場合の呼をいう。かかるリソース量はコーデックに依存し、つまり、コーデックは、高負荷呼か低負荷呼かを定める１要素である。

図３は、サーバ別リソース管理テーブル１２の構成の一例を示す図である。

サーバ別リソース管理テーブル１２は、各サーバ３につき、（１）当該サーバ３での空きのリソース量である空きリソース量Ｒｖ１、Ｒｖ２、…、（２）当該サーバ３での高負荷呼の接続数Ｃ１α、Ｃ２α、…、（３）当該サーバ３での低負荷呼の接続数Ｃ１β、Ｃ２β、…、を管理するものである。

空きリソース量とは、使用可能であるが使用されていないリソース量をいう。

また、空きリソース量、接続数は、実際の空きリソース量、接続数を反映するように、適宜、更新されることとする。

図１に戻り、呼接続装置１は、呼種別必要リソーステーブル１１、サーバ別リソース管理テーブル１２の他に、図示しないが、高負荷呼がサーバ３に接続されたときに使用されるコーデックを示す識別情報と高負荷呼を示す識別情報を対応づけ、かつ、低負荷呼がサーバ３に接続されたときに使用されるコーデックを示す識別情報と低負荷呼を示す識別情報を対応づけたテーブル（便宜的にコーデックテーブルという）を有している。

（呼接続装置の動作）
図４は、呼接続装置１の動作を示すフローチャートである。

呼接続装置１において、いずれかの端末４から接続要求、つまり、呼接続装置１が新たに呼をサーバ３に接続することを要求する信号を受信したなら（Ｓ１）、呼接続部１３は、新たな呼が高負荷呼か低負荷呼かを判定する（Ｓ３）。

呼接続部１３は、例えば、接続要求内のパラメータなどを基に、新たな呼がサーバ３に接続されたときに使用されるコーデックを示す識別情報を求め、コーデックテーブルにおいて、当該識別情報に対し、高負荷呼の識別情報が対応づけられているなら、新たな呼は高負荷呼であり、一方、低負荷呼の識別情報が対応づけられているなら、新たな呼は低負荷呼であると判定する。

呼接続部１３は、新たな呼が高負荷呼なら、呼種別必要リソーステーブル１１から第１のリソース量Ｒαを読み出し、サーバ別リソース管理テーブル１２から各空きリソース量Ｒｖ１、Ｒｖ２、…を読み出し、各空きリソース量の中で、

ただし、Ｒｖｉは、サーバｉについての空きリソース量（後述の式においても同じ）、
を満たす空きリソース量があるか否かを判定する（Ｓ５）。

呼接続部１３は、全ての空きリソース量が式（１）を満たさないなら、呼損処理を行い（Ｓ７）、つまり、接続要求の送信元である端末４に接続不可の応答を送信し、処理を終える。

呼接続部１３は、一方、少なくとも１つの空きリソース量が式（１）を満たすなら、当該空きリソース量の１つを選択し、当該リソース量に対応するサーバ３に呼を接続させ（Ｓ９）、処理を終える。

接続先のサーバ３は、呼が接続されたなら、予め記憶したメディアデータファイルを対応するコーデックでデコードし、得たメディアストリームを接続要求の送信元である端末４に送信する。

呼接続装置１は、サーバ別リソース管理テーブル１２から、当該サーバ３および高負荷呼についての接続数、空きリソース量を検索し、接続数に１を加算し、空きリソース量から高負荷呼について予め定めたリソース量を減算する。

また、呼接続装置１は、メディアストリームの送信が終わり、呼が切断されたら、サーバ別リソース管理テーブル１２から、当該サーバ３および高負荷呼についての接続数、空きリソース量を検索し、接続数から１を減算し、空きリソース量に対し高負荷呼について予め定めたリソース量を加算する。

なお、実際の接続数、空きリソース量を、当該サーバ３から得て、これにより、サーバ別リソース管理テーブル１２を更新しもよい。

さて、呼接続部１３は、ステップＳ３で、新たな呼が低負荷呼であると判定したなら、呼種別必要リソーステーブル１１から第１、第２のリソース量Ｒα、Ｒβを読み出し、サーバ別リソース管理テーブル１２から各空きリソース量Ｒｖ１、Ｒｖ２、…を読み出し、各空きリソース量の中で、

ただし、ｍｏｄ（Ｒｖｉ、Ｒα）は、空きリソース量Ｒｖｉを第１のリソース量Ｒαで割った剰余、
を満たす空きリソース量があるか否かを判定する（Ｓ１１）。

呼接続部１３は、少なくとも１つの空きリソース量が式（２）を満たすなら、当該空きリソース量の１つを選択し、当該リソース量に対応するサーバ３に呼を接続させ（Ｓ１３）、処理を終える。

接続先のサーバ３は、前述のように、メディアデータファイルをコーデックでデコードし、メディアストリームを端末４に送信する。

また、呼接続装置１は、サーバ別リソース管理テーブル１２から、当該サーバ３および低負荷呼についての接続数、空きリソース量を検索し、接続数に１を加算し、空きリソース量から高負荷呼について予め定めたリソース量を減算する。

また、呼接続装置１は、メディアストリームの送信が終わり、呼が切断されたら、サーバ別リソース管理テーブル１２から、当該サーバ３および低負荷呼についての接続数、空きリソース量を検索し、接続数から１を減算し、空きリソース量に対し低負荷呼について予め定めたリソース量を加算する。

なお、実際の接続数、空きリソース量を、当該サーバ３から得て、これにより、サーバ別リソース管理テーブル１２を更新しもよい。

呼接続部１３は、一方、全ての空きリソース量が式（２）を満たさないなら、各空きリソース量Ｒｖ１、Ｒｖ２、…の中で、

を満たす空きリソース量があるか否かを判定する（Ｓ１５）。

呼接続部１３は、少なくとも１つの空きリソース量が式（３）を満たすなら、当該空きリソース量の１つを選択し、当該リソース量に対応するサーバ３に呼を接続させ（Ｓ１７）、処理を終える。

接続先のサーバ３は、前述のように、メディアデータファイルをコーデックでデコードし、メディアストリームを端末４に送信する。

また、呼接続装置１は、前述のように、サーバ別リソース管理テーブル１２を更新する。

呼接続部１３は、一方、全ての空きリソース量が式（３）を満たさないなら、呼損処理を行い（Ｓ１９）、処理を終える。

次に、かかる呼接続装置１の動作による効果を説明する。

図５において、空きリソース量Ｒｖｍは、式（３）を満たすが式（２）を満たさない空きリソース量であり、空きリソース量Ｒｖｎは、式（３）、式（２）の双方を満たす空きリソース量である。

空きリソース量Ｒｖｎは、式（２）を満たすので、例えば、ステップＳ１３で空きリソース量Ｒｖｎが選択され、その分、空きリソース量が減っても、まだ、第１のリソース量Ｒα以上の空きリソース量を確保でき、将来、高負荷を接続できる。また、第２のリソース量Ｒβ分の空きリソース量が減った後の空きリソース量Ｒｖｎと、空きリソース量Ｒｖｍの差は比較的小さく、つまり、負荷の偏りが小さい。

しかし、空きリソース量Ｒｖｎがあるのに、空きリソース量Ｒｖｍを選択してしまうと、つまり、ステップＳ１１を行わないと、例えば、ステップＳ１７で空きリソース量Ｒｖｍが選択され、その分、空きリソース量が減った場合、第１のリソース量Ｒα以上の空きリソース量を確保できず、将来、高負荷を接続できない。また、第２のリソース量Ｒβ分の空きリソース量が減った後の空きリソース量Ｒｖｍと、空きリソース量Ｒｖｎの差が大きくなり、つまり、負荷の偏りが大きい。

したがって、呼接続装置１によれば、ステップＳ１１を行うことにより、高負荷呼の接続をより多く行うことができ、しかも、負荷の偏りを小さくすることができる。

（第１の変形例）
ここでは、式（２）を満たす空きリソース量に対応するサーバが複数ある場合、または、式（３）を満たす空きリソース量に対応するサーバが複数ある場合において、つまり、ステップＳ１３またはステップＳ１７において当該式を満たす空きリソース量に対応する複数のサーバから１つを選択する方法の一例を説明する。かかる方法は、一方または双方、いずれのステップで実行してもよい。

呼接続部１３は、サーバ別リソース管理テーブル１２から接続数Ｃ１β、Ｃ２β、…、を読み出すとともに、

ただし、Ｃｉβは、サーバｉについての接続数、ｍｏｄ（Ｒｖｉ−Ｒβ、Ｒα）は、空きリソース量Ｒｖｉから第２のリソース量Ｒβを引いた差を第１のリソース量Ｒαで割った剰余、
を計算し、最大の計算結果の値に対応する１つのサーバ３に呼を接続させる。

第１の変形例による作用効果を説明する。

図６において、斜線部分は、式（４）のｍｏｄ（Ｒｖｉ−Ｒβ、Ｒα）に相当する。つまり、空きリソース量Ｒｖｘにおいては、斜線部分が小さく、空きリソース量Ｒｖｙにおいては、斜線部分が大きい。

斜線部分の空きリソース量は、第１のリソース量Ｒαより小さく、したがって、斜線部分に対し、高負荷呼を割り当てることはできないが、斜線部分が大きい方が、将来、低負荷呼が切断されて、トータルの空きリソース量が増えた場合、当該空きリソース量に対し、多くの高負荷呼を割り当てられる可能性が高い。

図６では、空きリソース量Ｒｖｘよりも空きリソース量Ｒｖｙの方が、将来、多くの高負荷呼を割り当てられる可能性が高い。

つまり、第１の変形例は、

を計算し、大きい計算結果の値に対応するサーバへ優先的に呼を接続させることで、将来、多くの高負荷呼を割り当てられる可能性を高め、負荷の偏りを可及的に小さくすることができる。

また、例えば、２つのサーバの空きリソース量を比較し、これらが等しくても、接続数Ｃｉβが多いサーバの方が、大きいリソース量を有していることが多い。

よって、２つのサーバで同じ程度で接続数が減少していき、つまり、低負荷が切断されてきけば、接続数Ｃｉβが多いサーバの方が、多くの高負荷呼を割り当てられる可能性が高い。

つまり、第１の変形例は、接続数Ｃｉβの多いサーバへ優先的に呼を接続させることで、将来、多くの高負荷呼を割り当てられる可能性を高め、負荷の偏りを可及的に小さくすることができる。

（第２の変形例）
次に、第２の変形例について説明する。

第２の変形例では、図７に示す継続時間長テーブル１４が呼接続装置１に設けられる。

継続時間長テーブル１４は、低負荷呼の接続が継続する継続時間長により低負荷呼が予め複数の低負荷呼に分類される場合において、各低負荷呼の接続が継続する継続時間長ｈ１、ｈ２、…を予め記憶したものである。継続時間長は、例えば、実際の継続時間長の平均である。

また、第２の変形例では、呼種別必要リソーステーブル１１に代えて、図８に示す呼種別必要リソーステーブル１１Ａが用いられる。

呼種別必要リソーステーブル１１Ａは、（１）第１のリソース量Ｒαならびに（２）各低負荷呼について第２のリソース量Ｒβ１、Ｒβ２、…、を予め記憶したものである。

また、第２の変形例では、サーバ別リソース管理テーブル１２に代えて、図９に示すサーバ別リソース管理テーブル１２Ａが用いられる。

サーバ別リソース管理テーブル１２Ａは、各サーバ３につき、（１）当該サーバ３での空きのリソース量である空きリソース量Ｒｖ１、Ｒｖ２、…、（２）当該サーバ３での高負荷呼の接続数Ｃ１α、Ｃ２α、…、（３）当該サーバ３での各低負荷呼の接続数Ｃ１β１、Ｃ１β２、…、Ｃ２β１、Ｃ２β２、…、を管理するものである。サーバ別リソース管理テーブル１２Ａは、サーバ別リソース管理テーブル１２と同様に、呼接続装置１によって、現状を反映するように、適宜更新されるものである。

第２の変形例では、ステップＳ１３またはステップＳ１７において式を満たす空きリソース量に対応する複数のサーバから１つを選択する場合、呼接続部１３は、各低負荷呼につき、継続時間長テーブル１４から継続時間長を読み出し、各低負荷呼につき、呼種別必要リソーステーブル１１Ａから第２のリソース量を読み出し、当該複数の空きリソース量に対応する各サーバにつき、サーバ別リソース管理テーブル１２Ａから各低負荷呼の接続数を読み出し、

ただし、Ｃｉβｊは、サーバｉでの低負荷呼ｊについての接続数、ｈｊは、低負荷呼ｊについての継続時間長、Ｒβｊは、低負荷呼ｊについての第２のリソース量、

は、（Ｃｉβｊ／ｈｊ）×Ｒβｊの総和、Ｒβｋは、接続しようとする低負荷呼についての第２のリソース量、ｍｏｄ（Ｒｖｉ−Ｒβｋ、Ｒα）は、空きリソース量Ｒｖｉから第２のリソース量Ｒβｋを引いた差を第１のリソース量Ｒαで割った剰余、
を計算し、最大の計算結果の値に対応する１つのサーバ３に呼を接続させる。かかる方法は、ステップＳ１３またはステップＳ１７の一方または双方、いずれのステップで実行してもよい。

なお、第２のリソース量Ｒβｋを求めるのには、予めコーデックテーブルの低負荷呼の部分を低負荷の種類に応じて細分化しておき、前述の方法と同様に、コーデックの識別情報に対応する低負荷の識別情報を求め、その低負荷についての第２のリソース量Ｒβ（つまり第２のリソース量Ｒβｋ）を呼種別必要リソーステーブル１１Ａから求めればよい。

式（６）の分母の作用効果については、第１の変形例と同様なので、説明を省略し、式（６）の分子の作用効果について、具体例を用いて説明する。

低負荷呼が低負荷呼β１、β２に分類される場合、呼接続部１３は、式（６）は、

となる。

ただし、Ｃｉβ１は、サーバｉでの低負荷呼β１についての接続数、Ｃｉβ２は、サーバｉでの低負荷呼β２についての接続数、ｈ１は、低負荷呼β１についての継続時間長、ｈ２は、低負荷呼β２についての継続時間長、Ｒβ１は、低負荷呼β１についての第２のリソース量、Ｒβ２は、低負荷呼β２についての第２のリソース量である。

ここで、具体的に数値を代入する。

あるサーバ３（サーバ３Ａという）と別のサーバ３（サーバ３Ｂという）での低負荷呼β１についての接続数ＣＡβ１、接続数ＣＢβ１がそれぞれ「６」、「３」であり、サーバ３Ａ、３Ｂでの低負荷呼β２についての接続数ＣＡβ２、接続数ＣＢβ２がそれぞれ「３」、「６」であり、サーバ３Ａ、３Ｂでの低負荷呼β１についての第２のリソース量Ｒβ１が共に「１００（単位は省略する）」であり、サーバ３Ａ、３Ｂでの低負荷呼β２についての第２のリソース量Ｒβ２が共に「１００（単位は省略する）」であり、低負荷呼β１、β２についての継続時間長ｈ１がそれぞれ「５（単位は省略する）」、「１０（単位は省略する）」であったこととする。

式（７）の分子は、サーバ３Ａについては、
{（６／５）×１００＋（３／１０）×１００}＝１５０
サーバ３Ｂについては、
{（３／５）×１００＋（６／１０）×１００}＝１２０
となる。

６／５、３／１０は、サーバ３Ａにおいて、接続数ＣＡβ１、ＣＡβ２のうち、将来のある時点で切断される呼の数の期待値を示している。

３／５、６／１０は、サーバ３Ａにおいて、接続数ＣＡβ１、ＣＡβ２のうち、将来のある時点で切断される呼の数の期待値を示している。

この場合、式（７）の分母がサーバ３Ａ、３Ｂで同じならば、大きい方の分子（１５０>１２０）に対応するサーバ３Ａに呼（低負荷呼）が接続される。つまり、期待値の高い方のサーバに呼が接続される。よって、次の呼が高負荷呼であった場合、その高負荷呼を接続できる可能性を高めることができる。

例えば、サーバ３Ｂに呼を接続してしまった場合、次の呼（高負荷呼）をどのサーバ３にも接続できないという可能性がある。

しかし、サーバ３Ａに呼を接続することで、かかる不都合の発生の可能性を低くすることができる。つまり、高負荷呼を接続できる可能性を高め、サーバ間での負荷の偏りを可及的に小さくすることができる。

なお、本実施の形態に係る呼接続装置としてコンピュータを機能させるためのコンピュータプログラムは、半導体メモリ、磁気ディスク、光ディスク、光磁気ディスク、磁気テープなどのコンピュータ読み取り可能な記録媒体に記録でき、また、インターネットなどの通信網を介して伝送させて、広く流通させることができる。

また、本実施の形態では、メディアサーバを例にしたが、サーバは、いかなる種類のサーバであってもよい。

１…呼接続装置
３…メディアサーバ（サーバ）
４…端末
１１、１１Ａ…呼種別必要リソーステーブル
１２、１２Ａ…サーバ別リソース管理テーブル
１３…呼接続部
１４…継続時間長テーブル

Claims (5)

1. 複数のサーバへ負荷が分散するように呼を接続させる呼接続装置であって、
   サーバへの負荷の大きさにより高負荷呼に分類される呼がサーバに接続されたときのサーバでの必要なリソース量である第１のリソース量ならびに高負荷呼でない低負荷呼に分類される呼がサーバに接続されたときの必要なリソース量である第２のリソース量を予め記憶した呼種別必要リソーステーブルと、
   前記各サーバにつき、該サーバでの空きのリソース量である空きリソース量を管理するサーバ別リソース管理テーブルと、
   呼をサーバに接続させるにあたり、当該呼が高負荷であるか低負荷呼であるかを判定し、
   当該呼が高負荷呼であるなら、前記呼種別必要リソーステーブルから第１のリソース量を読み出し、前記サーバ別リソース管理テーブルから各空きリソース量を読み出し、
   

   

   ただし、Ｒｖｉは、サーバｉについての空きリソース量、Ｒαは、第１のリソース量、
   を満たす１つの当該空きリソース量を選択し、該空きリソース量に対応するサーバに当該呼を接続させる一方、
   当該呼が低負荷呼であるなら、前記呼種別必要リソーステーブルから第１、第２のリソース量を読み出し、前記サーバ別リソース管理テーブルから各空きリソース量を読み出し、
   

   

   ただし、Ｒｖｉは、サーバｉについての空きリソース量、Ｒαは、第１のリソース量、Ｒβは、第２のリソース量、ｍｏｄ（Ｒｖｉ、Ｒα）は、空きリソース量Ｒｖｉを第１のリソース量Ｒαで割った剰余、
   を満たす１つの空きリソース量を選択し、該空きリソース量に対応するサーバに当該呼を接続させる
   呼接続部と
   を備えることを特徴とする呼接続装置。
2. 前記呼接続部は、
   前記式（２）を満たす空きリソース量に対応するサーバが複数あるなら、
   

   

   ただし、Ｒαは、第１のリソース量、Ｒｖｉは、サーバｉについての空きリソース量、Ｒβは、第２のリソース量、ｍｏｄ（Ｒｖｉ−Ｒβ、Ｒα）は、空きリソース量Ｒｖｉから第２のリソース量Ｒβを引いた差を第１のリソース量Ｒαで割った剰余、
   を計算し、大きい計算結果の値に対応するサーバに呼を優先的に接続させる
   ことを特徴とする請求項１記載の呼接続装置。
3. 前記サーバ別リソース管理テーブルは、
   前記各サーバにつき、該サーバでの低負荷呼の接続数を管理するものであり、
   前記呼接続部は、
   前記式（２）を満たす空きリソース量に対応するサーバが複数あるなら、
   当該各サーバにつき、前記サーバ別リソース管理テーブルから接続数を読み出すとともに、
   

   

   ただし、Ｃｉβは、サーバｉについての接続数、Ｒαは、第１のリソース量、Ｒｖｉは、サーバｉについての空きリソース量、Ｒβは、第２のリソース量、ｍｏｄ（Ｒｖｉ−Ｒβ、Ｒα）は、空きリソース量Ｒｖｉから第２のリソース量Ｒβを引いた差を第１のリソース量Ｒαで割った剰余、
   を計算し、最大の計算結果の値に対応する１つのサーバに呼を接続させる
   ことを特徴とする請求項１記載の呼接続装置。
4. 前記呼接続装置は、
   低負荷呼の接続が継続する継続時間長により低負荷呼が予め複数の低負荷呼に分類される場合において、当該各低負荷呼の接続が継続する継続時間長を予め記憶した継続時間長テーブルを備え、
   前記呼種別必要リソーステーブルは、
   前記各低負荷呼について第２のリソース量を予め記憶したものであり、
   前記サーバ別リソース管理テーブルは、
   前記各サーバにつき、該サーバでの当該各低負荷呼の接続数を管理するものであり、
   前記呼接続部は、
   前記式（２）を満たす空きリソース量に対応するサーバが複数あるなら、
   前記各低負荷呼につき、前記継続時間長テーブルから継続時間長を読み出し、前記各低負荷呼につき、前記呼種別必要リソーステーブルから第２のリソース量を読み出し、当該各サーバにつき、前記サーバ別リソース管理テーブルから各低負荷呼の接続数を読み出し、
   

   

   ただし、Ｃｉβｊは、サーバｉでの低負荷呼ｊについての接続数、ｈｊは、低負荷呼ｊについての継続時間長、Ｒβｊは、低負荷呼ｊについての第２のリソース量、
   

   

   は、（Ｃｉβｊ／ｈｊ）×Ｒβｊの総和、Ｒαは、第１のリソース量、Ｒｖｉは、サーバｉについての空きリソース量、Ｒβｋは、接続しようとする低負荷呼についての第２のリソース量、ｍｏｄ（Ｒｖｉ−Ｒβｋ、Ｒα）は、空きリソース量Ｒｖｉから第２のリソース量Ｒβｋを引いた差を第１のリソース量Ｒαで割った剰余、
   を計算し、最大の計算結果の値に対応する１つのサーバに呼を接続させる
   ことを特徴とする請求項１記載の呼接続装置。
5. 複数のサーバへ負荷が分散するように呼を接続させる呼接続装置の動作方法であって、
   前記呼接続装置は、
   サーバへの負荷の大きさにより高負荷呼に分類される呼がサーバに接続されたときのサーバでの必要なリソース量である第１のリソース量ならびに高負荷呼でない低負荷呼に分類される呼がサーバに接続されたときの必要なリソース量である第２のリソース量を予め記憶した呼種別必要リソーステーブルと、
   前記各サーバにつき、該サーバでの空きのリソース量である空きリソース量を管理するサーバ別リソース管理テーブルとを備え、
   前記動作方法は、
   前記呼接続装置の呼接続部が、呼をサーバに接続させるにあたり、当該呼が高負荷であるか低負荷呼であるかを判定し、
   前記呼接続部が、当該呼が高負荷呼であるなら、前記呼種別必要リソーステーブルから第１のリソース量を読み出し、前記サーバ別リソース管理テーブルから各空きリソース量を読み出し、
   

   

   ただし、Ｒｖｉは、サーバｉについての空きリソース量、Ｒαは、第１のリソース量、 を満たす１つの当該空きリソース量を選択し、該空きリソース量に対応するサーバに当該呼を接続させる一方、
   当該呼が低負荷呼であるなら、前記呼種別必要リソーステーブルから第１、第２のリソース量を読み出し、前記サーバ別リソース管理テーブルから各空きリソース量を読み出し、
   

   

   ただし、Ｒｖｉは、サーバｉについての空きリソース量、Ｒαは、第１のリソース量、Ｒβは、第２のリソース量、ｍｏｄ（Ｒｖｉ、Ｒα）は、空きリソース量Ｒｖｉを第１のリソース量Ｒαで割った剰余、
   を満たす１つの空きリソース量を選択し、該空きリソース量に対応するサーバに当該呼を接続させる
   ことを特徴とする呼接続装置の動作方法。

Images