過負荷シグナルに基づく適応性速度制御
クライアント・コントロールを介したサーバー過負荷制限を目的とするコンピュータ・プログラム製品を含む方法及び装置について記述する。複数リクエストの第一セットを第一期間中に第一伝送速度でサーバーに伝送する。前記第一伝送速度を第一伝送制限速度以下になるよう制限する。サービスに関する前記複数リクエストの第一セットのうち少なくとも２以上のリクエストが過負荷基準を満たしているかどうかに基づいて過負荷値を決定する。前記過負荷値及び前記第一伝送制限速度に基づいて第二伝送制限速度を決定する。複数リクエストの第二セットを第二期間中に第二伝送速度で前記サーバーに伝送する。前記第二伝送速度を前記第二伝送制限速度以下になるよう制限する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、概して、ネットワーク中に集中するサーバー過負荷を検出及び軽減することを目的とするコンピュータ・プログラム製品を含めた方法及び装置に関する。
【背景技術】
【０００２】
通信サービスへの要求が増すにつれて、効果的な通信システムの重要性が増してきている。通信サービスには、電話コール設定要求の処理から、ネットワークのインターネット・プロトコル（ＩＰ）のデータ・パケットのルーティング、ウェブサイト及び／又はコンテンツを要求するハイパーテキスト・ドランスファー・プロトコル（ＨＴＴＰ）要求の処理等を含むことができる。通信システムには、クライアントからのサービス要求を処理するサーバーが一般的には含まれる。サーバーには、電話コール設定要求処理を行うための遠距離通信スイッチから、ＩＰデータ・パケットをルーティングするためのネットワーク・ルーター、ＨＴＴＰ要求を処理するためのウェブサーバー及び／又はコンテンツ・サーバー等を含むことができる。
【０００３】
時として、サービス要求（リクエスト）は、サーバーが前記要求を処理する速度よりも速い速度で前記サーバーに到達することがある。前記リクエストを処理するサーバーの速度は、以下の要素のうちの１以上が原因で変動しうる：異なる要求を処理する際のバリエーション；サーバー上で実行されるバックグラウンド動作又は管理動作；及び／又は前記サーバー中のソフトウェア若しくはハードウェアの部分的若しくは全体的な故障。通信サーバーは、典型的には過負荷制御（コントロール）を実施する。そして、高度な要求が成されている期間中、許容可能なレベルで、前記サーバーが処理を行うサービス要求のスループットを維持している。
【０００４】
過負荷が生じるのは、前記サーバーが受ける全ての要求を処理することに成功するためのサーバーのリソース（例えばＣＰＵの処理容量、メモリ、ネットワーク帯域、入力／出力、ディスク・リソース等）が不充分なときである。ある種のサーバーでは、サービス要求が高速度で入ってきたり、及び／又はネットワークが部分的に損傷することが原因となって、過負荷が継続される事態を経験する可能性がある。過負荷は、以下の要素（個々又は組合せ）によって生じうる：（１）メディアが喚起する大衆要求イベント（例えば、遠隔投票、慈善活動アピール、コンペ、マーケティング・キャンペーン等）；（２）緊急事態；（３）ネットワーク装置の故障；（４）自動スケジュール要求（例えば、雪の日にキャンセルする警告）；及び／又は（５）サービス拒否（Ｄｏｓ）攻撃。過負荷集中というものは、ネットワークのサブセットに過負荷が集中するという、ネットワーク過負荷の特殊なケースである。前記サブセットとしては、ネットワーク目的地（例えば、電話番号やＩＰアドレス等）から、ネットワーク・サーバのグループまで等が挙げられる。
【０００５】
過負荷制御がない状態では、こうした過負荷によって、通信ネットワークの安定性が脅かされる可能性がある。そして、サービス完了に成功する可能性を著しく減少させることにもなりうる。究極的には、要求が失われることが原因となって、サーバー（複数可）はサービス（複数可）を提供することに失敗する可能性があり、結果としてクライアントへサービスの非可用性へとつながる。また、過負荷問題については、これら過負荷問題自身が重なり合うことが良くあり、これによって、サーバー（複数可）に更なる負荷を引き起こす可能性がある。更に、過負荷がかかっている最中は、サーバー（複数可）の全体容量はダウンする可能性がある。なぜなら、該サーバーのリソースの多くは、サーバーが実際に処理することが出来ない負荷を拒否したり及び／又は処理したりするするのに費やされるからである。こうした深刻な過負荷の下、スループットは、元々の処理能力と比べて低い割合まで低下する可能性がある。こうした現象は、しばしば、コンジェスション・コラプス（ｃｏｎｇｅｓｔｉｏｎ ｃｏｌｌａｐｓｅ）と呼ばれる。更に言えば、過負荷によって、サービス要求が遅延したり及び／又は失われたりする傾向が生じ、これによって、クライアントの取り下げや及び／又はリトライ（ｒｅａｔｔｅｍｐｔｓ）を高速化させる可能性がある。
【０００６】
高度且つ予想不可能な要求レベルから保護することを目的とし、且つ、過負荷を処理する最中クライアントが早まってサービス要求を取り下げることを防ぐのに充分に短い応答時間を維持することを目的として、サーバーは、適応性の過負荷検出及び制御の形態を幾つか備えることができる。あるサーバーでは過負荷コントロール機構を内部に実装している。該機構では、過負荷がかかったサーバーは新たな要求を拒否して、許容セッションの完了が成功することを最大化させることができる。また、あるサーバーでは過負荷コントロール機構を外部に実装することができる。該機構では、１以上のクライアントにコントロール・メッセージを通信することによって、サービスを要求する追加要求をクライアントが送ることができる速度（例えば、要求速度についての制限を設定する等）にサーバーがコントロールすることができる。
【０００７】
しかし、サーバーが実装した、内部又は外部の機構は、「受信側ベース」のコントロール機構としても知られているが、上述したように、サーバーを過負荷から限定された度合いで保護することができるにすぎず、コンジェスション・コラプスを防止するのは困難である。特に、受信側ベース・コントロール機構は、サーバーに対して、サーバーの内部の過負荷レベルに基づいたクライアントへの制限を管理及び更新し、その後クライアントに対して過負荷フィードバック機構を介してこうした制限を配信する必要が生じる。例えば、制限には、明示的な速度メッセージ、（確認なしでサーバーに送ることができるメッセージ数を制限する）過負荷ウィンドウ・サイズ・メッセージ、及び／又はロス・パーセンテージ・メッセージ（該メッセージによりクライアント側はサーバーに向かって通常送られる要求の数を減らす）。全ての受信側ベースの概念は、配信リストを更新するために、クライアントの活動を監視する必要が生じる。配信リストについては、新たなクライアントが出現した場合に前記サーバー配信リストに新たなクライアントを追加することや、適切な時間クライアントが送信を中断している場合に既存のクライアントを削除すること等を含むことができる。こうしたことが各々必要になることにより、既に過負荷がかかっているサーバーに更に処理負荷が追加されることになってしまう。
【０００８】
更に、明示的な速度及び過負荷ウィンドウ・スキーマにおいて、過負荷がかかったサーバーは、各上流近隣から該サーバーが受け取る負荷の量を連続的に評価する。従って、適切な速度キャップ又は過負荷ウィンドウサイズを割り当て、それらについては、制限レベルを更新するために送信クライアントに対して、時間内に送り返すべきものである。ロス・パーセンテージをフィードバックする受信側ベースの概念は、過負荷のかかったサーバーにたいして同様のオーバーヘッドをかけることができない。なぜなら、同じロス・パーセンテージを全ての上流近隣に送ることが可能であり、従って、各クライアントから受け取る要求速度を追跡するための要求を落としてしまうからである。しかし、ロス・パーセンテージの概念は、効果的なコントロールを提供することができない。なぜなら、上流クライアントが、過負荷のかかったサーバー（該ロス・パーセンテージは素早く変動するが）に対する要求速度に関するロス・パーセンテージを適用するにつれて、前記過負荷のかかったサーバーに対する要求速度も素早く変動しうるからである。こうした変動があるため、過負荷のかかったサーバーには、スロットル・パーセンテージを現在の過負荷状態に素早く適応させる能力が要求される。
【０００９】
受信者ベース制御に関する別の欠点としては、該コントロールは、過負荷フィードバック機構を実装することを目的として、クライアント及びサーバー（複数可）において特定のプロトコル・スタックに対する変更を必要とする可能性がある点がある。例えば、集中過負荷を検出するために提案されたある技術は負荷フィルタリングであり、該技術においては、特定の目的地へのコールや特定のソースからのコールについては速度制限したりまたはランダムに落としたりするように指示するフィルターをネットワーク・オペレータが作成する。しかし、こうした機構では、サーバーのＳＩＰスタックが新たな過負荷イベント・パッケージを含むことが必要になる。プロトコル・スタックに対する変更は、こうした制御を適用することを遅くしてしまう可能性がある。更に、こうした機構は、過負荷イベントを予め知っていること（例えば、遠隔投票）に基づいて設計される静的な機構であり、突然の過負荷（例えば、緊急事態やネットワーク故障に関連した過負荷）に反応することについては失敗に終わるであろう。
【００１０】
集中過負荷を検出するために提案された別の技術として、特定の目的地へのコール拒否速度（例えば、コールされた数）を監視しており、前記速度が特定の閾値を超えているかどうかを監視している。そして、該目的地へ集中する可能性がある過負荷として該イベントをレポートする。前記サーバーは、該目的地へのコールに対するスロットルを開始し、同時に上流サーバーに対して該過負荷イベントを広げる。しかし、こうした検出アルゴリズムは、トークン・バケットを使用して実装され、大量のストレージを必要とする。更に言えば、こうした機構は、過負荷を検出するための明示的なコール拒否のみに依存しており、集中した過負荷イベントを検出するためにネットワーク間の配信されたモニターチームを必要とする。
【発明の概要】
【課題を解決するための手段】
【００１１】
過負荷がかかっている最中にサーバーのリソースをコントロールするためのアプローチの一つとして、クライアント・コントロールを介したサーバー過負荷制限が挙げられる。一態様において、本発明は、ネットワーク中のサーバー過負荷を制限するためのコンピュータ化された方法を特徴とする。該方法は、ネットワークのサーバー・ノードによって、下流サーバーからフィードバック・メッセージを受け取ることを含む。ここで前記フィードバック・メッセージは、通信プロトコルの統計情報を含む。前記方法は、前記フィードバック・メッセージ中に含まれる情報に基づいて１以上のハッシュ関数を用いて、コンピュータ・メモリ・モジュール中に保存された、カウンター配列からの１以上のカンウターのうちどれが下流サーバーと関連しているかを、サーバー・ノードが決定することを含む。１以上のカウンターは、下流サーバーから受け取った統計情報を含むフィードバック・メッセージの数に対応する数を保存する。前記方法は、統計情報を含むフィードバック・メッセージに応答して、１以上のカウンターをサーバー・ノードが増加させることを含む。前記方法は、１以上のカウンター中に保存された数の値を、１以上のハッシュ関数を用いて、サーバー・ノードが決定することを含む。前記方法は、前記値が所定の基準を充足するかどうかに基づいて、下流サーバーに関するネットワーク中の過負荷エピソードを前記値が表していることを、サーバー・ノードが決定することを含む。
【００１２】
別の実施形態では、前記所定の基準は閾値であり、前記決定することは、前記値が閾値を超えることを決定することを含む。前記閾値は、ヒステレシスを用いて計算することができる。過負荷エピソードを引きおこす原因となる１以上のソースを特定することができ、ここで各ソースは、下流サーバーに対して伝送を開始し、該伝送によって下流サーバーは、統計情報を含むフィードバック・メッセージを伝送させる。
【００１３】
別の実施形態では、前記値に基づくコントロール動作を行うことを目的とする１以上のコントロール・パラメータを決定する。ここで、前記コントロール動作は、過負荷エピソードの原因となる１以上のソースから下流サーバーへの転送データ速度を減少させる。前記１以上のコントロール・パラメータは、過負荷エピソードの原因となるソースと下流サーバーとの間のサーバー・ノードに送ることができる。前記コントロール動作は、ソースから下流サーバーへ伝送される伝送データ速度を減少させることによって、ソースから下流サーバーへ伝送されるデータに関してサーバー・ノードで行うことができる。ここで前記減少は１以上のコントロール・パラメータに基づいて行う。前記伝送速度は、過負荷エピソードの原因となる１以上のソースの下流サーバーへの要求試行速度（ｃａｌｌ ａｔｔｅｍｐｔ ｒａｔｅ）であってもよい。
【００１４】
別の実施形態では、１以上のコントロール・パラメータを決定することが、以下の決定することを含む：コントロール動作をどこで行うべきかを特定する動作位置を決定すること；前記動作位置でコントロール動作を適用する１以上のソースを定義する動作フィルターを決定すること；及び、コントロール動作に関する動作レベルを決定すること。前記動作レベルを決定することには以下の決定を含めることができる：所定の閾値を前記値が超えているかどうかを決定すること；そして、所定の閾値を前記値が超えている場合には、減少因子を用いて以前の動作レベルから減少させることを決定すること、前記値が前記所定の閾値未満の場合、前記動作レベルについて、増加ステップを用いて以前の前記動作レベルから増加させることを決定すること。前記所定の閾値はヒステレシスを用いて計算することができる。決定することについて、以下の動作定を含めることができる：前記値が所定の目標値と等しいかどうかを決定すること；並びに、もし前記値が前記所定の目標値と等しい場合には、前記動作レベルを変更しないこと；又は、もし前記値が前記所定の目標値と等しくない場合には、前記値と前記所定の目標値との差異及び以前の動作レベルに基づいて前記動作レベルを決定すること。前記１以上のコントロール・パラメータは前記動作位置に配信することができる。
【００１５】
別の実施形態では、前記方法は、以下のステップを含む：第二フィードバック・メッセージを第二下流サーバーから受け取るステップ（ここで前記 第二フィードバック・メッセージは前記統計情報を含む）；前記第二フィードバック・メッセージ中に含まれる情報に基づき１以上のハッシュ関数を用いて、カウンター配列からの１以上のカンウターのうちのどれが前記第二下流サーバーと関連しているかを決定するステップ；及び、前記統計情報を含む前記第二フィードバック・メッセージに応答して前記１以上のカウンターを増加させるステップ。複数のカウンター配列は保存することができ、ここで前記複数のカウンター配列それぞれは、異なるサーバー・ノードに保存されている。そして、複数のサーバー・ノードに跨る前記複数のカウンター配列に関連する各下流サーバーから受け取ったフィードバック・メッセージの数を計算するために前記複数のカウンター配列を集計することができる。前記通信プロトコルはセッション確立プロトコル (Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ、ＳＩＰ）であってもよく、及び前記統計情報がセッション拒否、前記下流サーバーからの過負荷フィードバック又はその両方であってもよい。前記通信プロトコルがセッション確立プロトコル、ハイパーテキスト・ドランスファー・プロトコル（ＨＴＴＰ）、ストリーム制御転送プロトコル（ＳＣＴＰ）、又はＴＣＰプロトコル（ｔｒａｎｓｍｉｓｓｉｏｎ ｃｏｎｔｒｏｌ ｐｒｏｔｏｃｏｌ）であってもよい。
【００１６】
別の実施形態では、前記１以上のハッシュ関数及び前記カウンター配列がカウンティング・ブルーム・フィルターに関連している。また、１以上のカウンターのうちどれが前記下流サーバーに関連するかについて決定することが、キーに関連するハッシュ関数を用いて前記１以上のカウンターを決定することを含み、前記キーは前記下流サーバーに関する識別子である。前記増加させるステップが以下のステップを含むことができる：前記１以上のカウンターを１ずつ増加させるステップ；又は、前記１以上のカウンターを１を超える数で増加させるステップ（ここで、前記１を超える数は以下に基づいて決定される：前記統計情報；一定期間、前記下流サーバーから受け取る統計情報；複数の一定期間、前記下流サーバーから受け取る統計情報；ソースから前記下流サーバーへ行われる伝送の種類；又はこれらの任意の組合せ）。
【００１７】
別の実施形態では、ブルーム・フィルターに基づくマルチ（複数）・レベルな閾値を動作位置に配信するステップを更に含む（ここで前記ブルーム・フィルターに基づくマルチ・レベルな閾値は、以下を保存する：複数の閾値(ここで前記複数の各閾値は、前記通信プロトコルに関するコール・リクエストと関連する複数のクラス（分類）からの１つのクラスに対応する)；及び、１以上のハッシュ関数を用いた前記複数の各クラスに関する、前記下流サーバーに対するコール・リクエストのカウント）。前記方法は、以下のステップを含むことができる：ソースから前記下流サーバーへのコール・リクエスト・メッセージを受け取るステップ（前記コール・リクエスト・メッセージは、前記複数のクラスのうち１つのクラスを含む）； 前記ブルーム・フィルターに基づくマルチ・レベルな閾値を用いて、以下を決定するステップ：（１）前記コール・リクエスト・メッセージ中の前記クラスに関する閾値；及び、（２）前記１以上のハッシュ関数を用いて、ブルーム・フィルターに基づく前記コール・リクエスト・メッセージ中の前記クラスに関する、前記下流サーバーへのコール・リクエストのカウント；並びに、もし、前記コール・リクエストのカウントが前記閾値を超える場合、前記コール・リクエスト・メッセージを拒否するステップ；又は、もし、前記コール・リクエストのカウントが前記閾値未満の場合、前記コール・リクエスト・メッセージを受け入れるステップ。前記統計情報は：ソースから前記下流サーバーへの失敗した接続リクエスト；前記下流サーバーからの過負荷通知；又はこれら両方であってもよい。
【００１８】
別の態様において、本発明は、ネットワーク中のサーバ過負荷を制限するためのシステムを特徴とする。前記システムは、以下を備える：カウンター配列を保存するように設計されるコンピュータ・メモリ・モジュール；及び、前記コンピュータ・メモリ・モジュールと通信し、以下の手段を備えるコントローラ：下流サーバーからフィードバック・メッセージを受け取るためのコンピューティング手段（ここで前記フィードバック・メッセージは通信プロトコルの統計情報を含む）；前記カウンター配列からの１以上のカウンターのうちのどれが前記下流サーバーに関連するかについて、１以上のハッシュ関数を用い、前記フィードバック・メッセージ中に含まれる情報に基づいて決定するためのコンピューティング手段（ここで前記１以上のカウンターは、前記下流サーバーから受け取り、且つ前記統計情報を含むフィードバック・メッセージの数に対応する数を保存する）。また、前記コントローラは、以下のコンピューティング手段を備える：前記統計情報を含む前記フィードバック・メッセージに応答して前記１以上のカウンターを増加させるためのコンピューティング手段；前記１以上のカウンターに保存される数の値を前記１以上のハッシュ関数を用いて決定するためのコンピューティング手段；及び、前記値が所定の基準を満たすかどうかに基づいて、前記下流サーバーが関連する前記ネットワーク中の過負荷エピソードを前記値が表すことを決定するためのコンピューティング手段。
【００１９】
別の態様において、本発明は、情報キャリア中で実際に実行されるコンピュータ・プログラム製品であることを特徴とする。コンピュータ・プログラム製品は、データ処理装置に以下の動作を行わせるために実行可能な指示を含む：下流サーバーからのフィードバック・メッセージを受け取ること（ここで前記フィードバック・メッセージは通信プロトコルの統計情報を含む）；コンピュータ・メモリ・モジュールに保存されたカウンター配列からの１以上のカウンターのうちのどれが前記下流サーバーと関連するかを、前記フィードバック・メッセージ中に含まれる情報に基づき、１以上のハッシュ関数を用いて決定すること（ここで前記１以上のカウンターは、前記下流サーバーから受け取とり、且つ前記統計情報を含むフィードバック・メッセージの数に対応する数を保存する）。前記コンピュータ・プログラム製品は、以下の動作をデータ処理装置に行わせるために実行可能な指示を更に含む：前記統計情報を含む前記フィードバック・メッセージに応答して前記１以上のカウンターを増加させること；前記１以上のカウンターに保存される数の値を前記１以上のハッシュ関数を用いて決定すること；及び、前記値が所定の基準を満たすかどうかに基づいて、前記下流サーバーが関連する前記ネットワーク中の過負荷エピソードを前記値が表すことを決定すること。
【００２０】
別の態様において、クライアント・コントロールを介したサーバー過負荷制限を目的とするコンピュータ化された方法がある。前記方法は、以下のステップを含む：サービスに関する複数要求（リクエスト）の第一セットを第一期間中第一伝送速度でサーバーに伝送するステップ；及び第一期間中第一伝送制限速度以下になるよう前記第一伝送速度を制限するステップ。また、前記方法は以下のステップを含む：サービスに関する前記複数リクエストの第一セットのうち少なくとも２以上のリクエストが過負荷基準を満たしているかどうかに基づいて過負荷値を決定するステップ;前記過負荷値をコンピュータ・メモリ・モジュールに保存するステップ。また、前記方法は以下のステップを含む：前記過負荷値及び前記第一伝送制限速度に基づいて第二伝送制限速度を決定するステップ。また、前記方法は以下のステップを含む：サービスに関する複数リクエストの第二セットを前記第一期間後の第二期間中に第二伝送速度で前記サーバーに伝送するステップ；及び、前記第二期間中の第二伝送速度を前記第二伝送制限速度以下になるよう制限するステップ。
【００２１】
別の態様において、クライアント・コントロールを介したサーバー過負荷制限を目的とするシステムがある。前記システムは、バッファ、伝送機、及びコントローラを備える。前記バッファは、サービスを要求する複数リクエストの第一セットを保存するように設計される。前記伝送機は、前記バッファと接続され、サービスを要求する前記１以上のリクエストを伝送制限速度以下となる伝送速度で第一期間中サーバーに伝送するように設計される。前記コントローラは、以下の手段を備える：サービスに関する前記複数リクエストの第一セットのうち少なくとも２以上のリクエストが過負荷基準を満たしているかどうかに基づいて過負荷値を決定するためのコンピューティング手段。また、前記コントローラは、以下の手段を備える：前記過負荷値及び前記伝送制限速度に基づいて、伝送制限速度を調整するためのコンピューティング手段。
【００２２】
別の態様において、コンピュータ・プログラム製品がある。前記コンピュータ・プログラム製品は、機械読取可能ストレージデバイスで実際に実行され、前記コンピュータ・プログラム製品が、データ処理装置に以下の動作を行わせるために実行可能な指示を含む：サービスに関する複数リクエストの第一セットを第一期間中第一伝送速度でサーバーに伝送すること；及び、前記第一伝送速度を前記第一期間中第一伝送制限速度以下に制限すること。また、前記コンピュータ・プログラム製品が、データ処理装置に以下の動作を行わせるために実行可能な指示を含む：サービスを要求する前記複数リクエストの第一セットのうち少なくとも２以上のリクエストが過負荷基準を満たしているかどうかに基づいて過負荷値を決定すること；及びコンピュータ・メモリ・モジュールに前記過負荷値を保存すること。また、前記コンピュータ・プログラム製品が、データ処理装置に以下の動作を行わせるために実行可能な指示を含む：前記過負荷値及び前記第一伝送制限速度に基づいて第二伝送制限速度を決定すること。また、前記コンピュータ・プログラム製品が、データ処理装置に以下の動作を行わせるために実行可能な指示を含む：サービスを要求する１以上のリクエストの第二セットを前記第一期間後である第二期間中に第二伝送速度で前記サーバーに伝送すること；及び、前記第二期間中前記第二伝送制限速度以下になるように前記第二伝送速度を制限すること。
【００２３】
他の態様において、上記態様の何れかは、以下の特徴の１以上を含むことができる。本発明では、前記過負荷値が目標過負荷値を下回るか上回るかを決定することをができる。前記過負荷値が前記目標過負荷値を超える場合に、前記第二伝送制限速度を決定することが、前記過負荷値と前記目標過負荷値との差分に比例する量だけ前記第一伝送制限速度を低下させることを含むことができる。前記過負荷値が前記目標過負荷値を超える場合に、前記第二伝送制限速度を決定するステップが、前記過負荷値に比例する量又は該過負荷値の目標過負荷値からの偏差に比例する量だけ前記第一伝送制限速度を低下させるステップを含むことができる。
【００２４】
幾つかの実施形態において、前記過負荷値が前記過負荷基準を満たすリクエスト速度を表す。前記過負荷値が前記目標過負荷値未満の場合に、前記第二伝送制限速度を決定することが前記第一伝送制限速度を速度ステップ（ｒａｔｅ ｓｔｅｐ）だけ上昇させることを含むことができる。前記速度ステップは固定されていてもよい。前記速度ステップは前記第一伝送制限速度に基づくことができる。前記速度ステップの範囲は最大速度ステップ及び最小速度ステップで決定することができる。第一層エンティティは前記過負荷値を決定することができ、第二層エンティティは前記第一伝送速度を制限することができ、前記第一層エンティティは前記第二層エンティティとは異なってもよい。前記第一層エンティティは、トランスポート層エンティティを含むことができ、前記第二層エンティティがアプリケーション層エンティティを含むことができる。
【００２５】
前記過負荷基準は明示的な過負荷基準であってもよい。前記明示的な過負荷基準は単一のリクエストのみに適用されてもよい。前記明示的な過負荷基準は非スロットリング型クライアント・レスポンスを特定することができる。さらに他の実施形態では、前記第一セットからのリクエストであって且つサービスを要求する第一リクエストに関する第一拒否メッセージを前記サーバーから受け取った場合、前記第一リクエストが前記明示的な過負荷基準を満たすことができる。
【００２６】
前記過負荷基準は暗黙的な過負荷基準であってもよい。前記第一セットからのリクエストであって且つサービスを要求する第一リクエストが伝送されてからの経過時間が遅延閾値を超える場合に、前記第一リクエストが前記暗黙的な過負荷基準を満たすことができる。ある時間間隔でサービスを要求する未応答のリクエストの割合が割合閾値以上になった場合に、前記暗黙的な過負荷基準を満たすことができる。前記暗黙的な過負荷基準はピア・コンジェスションとは無関係の前記サーバーからの１以上の応答メッセージに基づくことができる。前記１以上の応答の割合が割合閾値以上になった場合に、前記暗黙的な過負荷基準を満たすことができる。前記暗黙的な過負荷基準は、割合閾値以上である前記１以上の応答割合の変化に基づくことができる。
【００２７】
前記遅延閾値は静的であってもよい。前記遅延閾値は、前記サーバーに伝送されサービスを要求する１以上の以前のリクエストに対する平均応答時間に基づくことができる。前記遅延閾値は、前記サーバーに伝送されサービスを要求する１以上の以前のリクエストに対する百分率の応答時間に基づくことができる。前記第一セットからのリクエストであって且つサービスを要求する前記第一リクエストに対する第一応答を受け取る前に、前記第一セットからのリクエストであって且つサービスを要求する第二リクエストに対する第二応答を受け取るか否かに基づいて、第一リクエストが前記過負荷基準を満たすことができる（ここで、前記第二リクエストは、前記第一リクエストの後に前記サーバーへ伝送される）。
【００２８】
幾つかの実施形態において、前記過負荷値を決定するステップが、前記過負荷基準を満たす前記第一セットからのリクエスト数を平均化するステップ及び／又はフィルタリングするステップを含むことができる。前記過負荷値を決定するステップは、更に、前記第一期間の前の１以上の期間に関連する１以上の以前の過負荷値に基づくことができる。前記第一期間は、前記第二期間とブラインド間隔期間だけ離れていてもよい。前記ブラインド間隔は、固定時間間隔であるか、及び／又は前記サーバーに伝送されサービスを要求する１以上の以前のリクエストに対する平均応答時間に基づくことができる。
【００２９】
幾つかの実施形態において、前記複数リクエストの第一セットを伝送することは、前記１以上のリクエストの伝送について、リクエストの種類に基づいて優先順位を付けることを含むことができる。前記１以上のリクエストのリクエスト種類は、高優先度、通常、又はこれらの任意の組合せを含むことができる。前記複数リクエストの第一セット及び第二セットは、同一の分類又は種類であってもよい。前記複数リクエストの第一セットは、第一分類又は種類及び第二分類又は種類のリクエストを少なくとも含みことができる。前記複数リクエストの第二セットは前記第一分類及び／又は種類のリクエストのみを含むことができる。前記第一分類及び／又は種類は、１以上のサービス要求を自動的に再伝送することを含むことができる。
【００３０】
別の実施例において、方法に関連する上述の任意の特徴は、システム及び／又は前記システムのコントローラが実行することができ、該システム及び／又は該コントローラは前記方法を実行するために設計され又はそのための手段を有する。さらに、方法に関連する上述の任意の特徴は、コンピュータ・プログラム製品が実行することができ、プログラム製品がデータ処理装置に前記方法を行わせるために実行可能な指示を含む。
【発明の効果】
【００３１】
上述した任意の実施形態は、以下の１以上の利点を実現することができる。通信プロトコルの統計情報を保存するために、スペース的に有効な及びコンピュータ的に効果的なデータ構造（例えばブルーム・フィルター）を用いることにより、過負荷エピソード（例えば集中した過負荷エピソード）の検出を素早く効果的に行うことができる。前記実施形態は、複数のネットワーク要素（例えば、ソース、サーバー・ノード）に跨って保存されるデータ構造を集計するように設計することができ、下流サーバーやネットワーク要素に関連するネットワーク・ワイドな統計情報を集めることができる。コントロール・パラメータは、前記データ構造に基づいて計算され、適切な動作位置に配信される（例えば、クライアント、サーバー・ノード）。そして、過負荷エピソードを引き起こすメッセージの数を、下流サーバーに到達する前に減らす。そして、ネットワーク帯域を不必要に使用することを防止する。さらに、下流サーバーへの処理負荷を減らす。過負荷コントロールをクライアント側に分散させることにより、サーバーに与えられる負荷を、サーバースループットを最大化させるレベルにまで減少させることができる。幾つかの前記実施形態では、過負荷のかかったサーバーに到達する前に、幾つかのサービス要求をクライアントに抑えさせるように設計することができる。このことにより、結果としては、過負荷のかかったシステムに、より極端な過負荷が係ることを防止することができ、及び／又は過負荷イベントの全期間中最適に近い負荷でサーバーが稼動することを可能にすることができる。
【００３２】
他の実施形態では、応答（レスポンス）時間を決定することができる。サービス要求の遅延フィードバックを減らすことによりコントロールの安定性に寄与することができる点で有利である。更に、クライアント・ベースのコントロールは、処理過負荷をクライアント側に移行させることにより、クライアントへの制限レベル・コントロール・メッセージを更新及び／又は配信するというサーバー側の負荷を軽減できる点で有利である。更なる実施形態では、前記サービス・プロトコル（例えば、ＳＩＰ）の変更を必要とせずに設計できる点で有利である。更には、クライアント実施の過負荷コントロールは、前記クライアント・システム上で完全に実施することができる。そして、過負荷のかかったサーバーへの処理負荷を減らすことが出来る点で有利である。サーバーのパフォーマンスは、サービス由来のインフラの操作に非常に重要なものと成りうるため、クライアント実施過負荷コントロール技術は、メディアへの応用の際の待ち時間（例えば電話コールを開始する場合）を減らすことができる点で有利である。そして、サーバーに過負荷がかかったとしても、スループットを最大又は実質的に最大に維持できる点で有利である。
【００３３】
クライアント実施過負荷コントロール技術は、方法及び装置が含まれるが、例えば以下の要件を１以上満たすことができる：（１）過負荷のかかったサーバーにおいてスループットを自動的に最大化すること；（２）過負荷イベント期間中の高スループットを実現すること；（３）過負荷がかかっている最中、クライアントが早まってサービス要求を取り下げることが無い様に、応答時間の高い割合が充分に低いこと；（４）作業過負荷の変化に素早く反応すること。前記過負荷コントロール技術は、前記過負荷イベントを予め知っておくことに依存しない点で有利である。更に、サービス識別子（例えば、ユニーク・コード）は、特定のサービス要求を、１以上のサービス分類に分類することができる（例えば、各サービスの分類が異なるレベルのスループットを有する）。
【００３４】
１以上の実施例に関する詳細は、添付した図面及び以降の記述の中で述べる。更に、本発明の特徴、態様、及び利点については、本明細書、図面、及び特許請求の範囲から明らかになるであろう。前記図面については、必ずしも本発明そのものを表すものではなく、本発明の原則を例示する際に一般的に示されるものである点を強調しておく。
【００３５】
添付した図面と関連して以降の記載を参照することにより、上述した本発明の利点については、更なる利点と共に、より深く理解されるであろう。前記図面については、必ずしも本発明そのものを表すものではなく、本発明の原則を例示する際に一般的に示されるものである点を強調しておく。
【図面の簡単な説明】
【００３６】
【図１】クライアントからのサービス要求を処理するサーバーに関係する装置（デバイス）に関する例示的なネットワークを表したブロック図である。
【図２】クライアントの構成要素を表したブロック図である。
【図３】モデル・コントロール・ループの構成要素を表したブロック図である。
【図４】ウィンドウ化したタイム・インターバルを表す図である。
【図５】サーバー・リソースの外部コントロールを描いたフローチャートである。
【図６】サーバー・リソースの外部コントロールを描いたフローチャートである。
【図７】ＳＩＰメッセージ・フローのシミュレート・モデルを描いたハシゴ図である。
【図８】異なる過負荷コントロール概念（スキーマ）に関して、与えられた負荷に対するスループットを表した二次元プロットである。
【図９】本発明の例示的な実施形態に従って、集中したサーバー過負荷を検出及び制限することを目的とするネットワークを概念的に図示したものである。
【図１０】本発明の例示的な実施形態に従って、ネットワーク中の集中したサーバー過負荷を保存及び検出することを目的とするブルーム・フィルターを概念的に図示したものである。
【図１１】本発明の例示的な実施形態に従って、ネットワーク中の集中したサーバー過負荷を検出することを目的とする方法を例示したフローチャートである。
【図１２Ａ】本発明の例示的な実施形態に従って、ネットワーク中の集中したサーバー過負荷を検出することを目的とするカウンティング・ブルーム・フィルターに関するチャートを概念的に図示したものである。
【図１２Ｂ】本発明の例示的な実施形態に従って、ネットワーク中の集中したサーバー過負荷を検出することを目的とする集計カウンティング・ブルーム・フィルターに関するチャートを概念的に図示したものである。
【図１２Ｃ】本発明の例示的な実施形態に従って、ネットワーク中の集中したサーバー過負荷を検出することを目的とする、集計されたコール数の分布に関するチャートを概念的に図示したものである。
【図１３】本発明の例示的な実施形態に従って、ネットワーク中の集中したサーバー過負荷を制限することを目的とする１以上のコントロール・パラメータを決定するための方法を図示したフローチャートである。
【図１４Ａ】本発明の例示的な実施形態に従って、ネットワーク中の集中したサーバー過負荷を制限することを目的とする動作レベルを決定するための方法を図示したフローチャートである。
【図１４Ｂ】本発明の例示的な実施形態に従って、ネットワーク中の集中したサーバー過負荷を制限することを目的とする動作レベルを決定するための方法を図示したフローチャートである。
【図１５】本発明の例示的な実施形態に従って、ネットワーク中の集中したサーバー過負荷を制限することを目的とする方法を図示したフローチャートである。
【発明を実施するための形態】
【００３７】
１．ネットワークの概要
本明細書で記述するシステム及び方法は、コンピュータ中に通信プロトコル統計情報（例えば、下流サーバーからフィードバック・メッセージを介して受け取るなど）を保存するものであり、スペース的に有効な及びコンピュータ的に効果的なデータ構造（例えばブルーム・フィルター、カウンティング・ブルーム・フィルター、又はブルーム・フィルターに基づくマルチ・レベルな閾値(ＭＬＢＦ)）を使用する。ここで、用語「ブルーム・フィルター」が、本明細書において概して使用されているが、任意の種類のブルーム・フィルターを意味し、例えば、従来のブルーム・フィルター、カウンティング・ブルーム・フィルター、ＭＬＢＦ等が挙げられる点を理解されたい。前記データ構造を用いて、過負荷エピソードが下流サーバーや目的地に存在するかどうか（例えば、集中過負荷が下流サーバーに存在するかどうか）をネットワーク上のサーバーが決定する。もし、過負荷が存在する場合には、コントロール・パラメータがコンピューターを用いて計算され、該パラメータはコントロール動作を定義し、そして、該コントロール動作は１以上のネットワーク構成要素に配信され、過負荷エピソードをコントロールする（例えば、ソースから過負荷のかかった下流サーバーや目的地への伝送速度を減少させるなど）。
【００３８】
図１は、クライアントからのサービス要求を処理するサーバーに関係する装置に関する例示的なネットワーク（１００）を表したブロック図である。前記ネットワーク（１００）は、伝送媒体（１１０）、１以上のクライアント（１２０ａ、１２０ｂ、及び／又は１２０ｃ、概して１２０）、及び少なくとも１つのサーバー（１３０）（例えば下流サーバー）を含む。伝送媒体（１１０）（例えば、通信ネットワーク）は、サービス要求を含む情報を、１以上のクライアント（１２０）及び／又はサーバー（１３０）の間で伝送する役割を担う。以降でさらに詳述するが、クライアント（１２０）は、本明細書に記述された幾つかの発明技術に従って設計される。１以上のクライアント（１２０）及びサーバー（１３０）の間で、１以上の中継サーバー・ノードがあってもよく、該サーバー・ノードはクライアント（１２０）でもサーバー（１３０）（又は下流サーバー（１３０））でもない任意のノードである。
【００３９】
伝送媒体（１１０）は、接続部（１１５）によってクライアント（１２０）と接続することができる。クライアント（１２０）は、サーバー（１３０）からの１以上のサービスを要求することができる任意の装置である。クライアント（１２０）としては、ユーザーデバイスを含むことができ、例えば、コンピュータ、電話、ＩＰ電話、携帯端末（例えば、携帯電話、ＰＤＡ装置、ラップトップ・コンピュータ等）、及び／又は他の通信装置が挙げられる。幾つかの実施形態（例えば遠距離通信ネットワーク等）において、クライアント（１２０）は、メディア・ゲートウェイであり、例えば、コール・ソースからのセッション要求（図示しない）がネットワーク（１１０）に入る。また、幾つかの実施形態において、１以上のクライアント（１２０）は、１以上のサーバー機能を実行することもでき、従って、サーバー（１３０）とは異なるサーバー（複数可）としてみなしてもよい。例えば、遠距離通信ネットワークにおいては、遠距離通信スイッチ（例えば、端局又はタンデム・スイッチ）がサーバーとして動作することができ、及び／又は、任意の近隣遠距離通信スイッチに対するクライアントとして動作することができる。そして、それぞれが、コール・セットアップ等のサービスを要求するクライアントとして動作したり及び／又はサーバーとして動作したりすることができる。別の例においては、ＩＰルータやネットワーク・スイッチは、任意の近隣の又は遠隔のＩＰルータ又はネットワーク・スイッチに対するサーバー及び／又はクライアントとして動作することができる。そして、前記任意の近隣の又は遠隔のＩＰルータ又はネットワーク・スイッチも、それぞれ、クライアント及び／又はサーバーとして動作することができる。クライアントとして、近隣又は遠隔のＩＰ装置は、ＩＰパケットの伝送を要求することができ、及び／又はゲートウェイ・コントロール要求を送ることができる。本発明の別の例では、クライアント（１２０）及びサーバー（１３０）は、物理的に同一及び／又は論理的のいずれかの意味で同一のコンピューティング・デバイス内に配置することができる。例えば、コンピュータは、複数のタスク、プログラム、及び／又はプロセスを実行することができるが、この場合、サーバー（１３０）中の単一の処理ユニットは、クライアント（１２０）として動作するためのタスク、プログラム、及び／又はプロセスそれぞれに関するサービスの処理を担う。この例において、クライアント（１２０）が前記処理ユニット（即ち、サーバー（１３０））から分離している場合には、伝送媒体（１１０）は内部バスを含むことができる。
【００４０】
接続部（１１５）は、電線、光学ファイバー、及び／又は無線伝送部等を含むことができる。また、接続部（１１５）は、クライアント（１２０）をネットワーク（１１０）に接続する１以上の中継装置を含むことができる。クライアント（１２０）は、ユニークな識別子及び／又は共有された識別子によって識別することができる。ユニークなクライアント識別子は、例えば、電話番号、ＩＰアドレス等が挙げられる。共有されたクライアント識別子としては、例えば、ネットワーク・アドレス、エリア・コード、国別コード、サービス識別子等が挙げられる。
【００４１】
サービス識別子は、特定のサービス要求を１以上のサービス分類に分類するユニークなコードであってもよい。また、サービス要求は要求種類に基づいて分類することもできる。例えば、サービス要求は、新たなセッションを要求する要求メッセージ、又は既存のセッションの更新又は変更を要求する要求メッセージのいずれかに分類することができる。また、サービス要求は、以前送信された要求メッセージの再送信であるかどうかについて分類することができる（例えば、タイムアウト条件によって、クライアントに対して要求の再送信を指示した場合等）。別の例では、サービス要求は、データベース探索を必要としない要求メッセージ、又は１以上のデータベースの探索をプロセスに対して要求する要求メッセージの何れかに分類することができる。更に別の例では、サービス要求は、クライアントが登録した購入（ｓｕｂｓｃｒｉｐｔｉｏｎ）レベルに基づいて分類することができる。更に別の例では、サービス要求は、電子商取引購入活動、又は非電子商取引活動（例えば閲覧活動）のいずれかに関連するものとして分類することができる。更に別の例では、サービス要求は、以下のように優先度で分類することができる：優先要求；通常要求；又は、低優先度要求。一般的に、要求の優先度は、レベルに関する任意の番号で分類される（例えばレベル０〜１０までの優先度レベルを割り当てるなど）。
【００４２】
異なる分類のサービスを提供することは、サーバー（１３０）の異なるリソースを消費しうる（例えば、メモリ、ディスク帯域（ｄｉｓｋ ｂａｎｄｗｉｄｔｈ）、通信帯域、及び／又は処理サイクル）。別の実施形態では、クライアント（１２０）及び／又はサービス要求の分類付けは任意であってもよいため、クライアント（１２０）及び／又はサービス要求は識別子によって同定したり分類したりする必要がない。
【００４３】
また、伝送媒体（１１０）は、接続部（１１５）によって、サーバー（１３０）に接続することができる。サーバー（１３０）は、クライアント（１２０）からのサービスの各要求を処理することにより、１以上のクライアント（１２０）に対して、１種以上のサービスを提供する役割を担っている。サーバー（１３０）としては、例えば、ウェブ・サーバー、アプリケーション・サーバー、メディア・サーバー、ゲートウェイ、ソフトスイッチ、遠距離通信スイッチ（例えば、トール（ｔｏｌｌ）又はタンデム・スイッチ）、ネットワーク・ルータ、又はスイッチ等が含まれる。幾つかの実施形態において（例えば、ピア・ツー・ピア・ネットワークにおいて）、サーバー（１３０）は、他のサーバー（図示しない）からの１以上のサービスを要求することもでき、従って、該サーバーは、クライアント（１２０）とは別のクライアントとしてみなすこともできる。
【００４４】
サーバー（１３０）が提供しているサービスの種類として、例えば、音声サービス、ビデオ・サービス、データ・サービス、マルチメディア・サービス、及び／又は他の電子的なサービスを含むことができる。音声サービスとしては、例えば、遠距離通信ネットワークに関連するサービスの確立、維持、及び開放等が挙げられる。例えば、遠距離通信ネットワークに関して言えば、セッション要求がサーバーからネットワークへ出る。例えば、ＳＳ７ ＩＡＭメッセージ、ＳＩＰプロトコルＩＮＶＩＴＥメッセージ、又はＨ．３２３セットアップメッセージは、新たな電話コール又はコールセッションを開始するための要求であってもよい。同様にＳＩＰプロトコルＵＰＤＡＴＥメッセージは、既存のコールセッションの状態を更新するための要求であってもよい。ビデオ・サービスとしては、例えば、インターネットを介したビデオ・ストリーミングの確立、維持、及び開放を含むことができる。ビデオ・ストリーミングとしては、リアルタイム・ビデオ、及び／又はオンデマンド・ビデオを含むことができる。データ・サービスとしては、例えば、ウェブ・サイト（ＨＴＴＰ要求を処理する）、パケット・ルーティング（ＩＰパケットをルーティングする）、及び／又は一般的なコンテンツ配信を含むことができる。他のサービスとしては、例えば、１以上のビデオ、オーディオ、及び／又はデータ・サービスを含むことができる。他の実施形態では、例えば、飛行機の予約システムに関するウェブ・サーバー、１以上のオーディオ・サーバー、ｅ−ｍａｉｌサーバー、コラボレーション・サーバー、認証サーバー、及び／又は他のサーバー（複数可）がある。
【００４５】
特に、セッション確立プロトコル（ＳＩＰ）やＨ．３２３等のプロトコルは、様々な種類のメディア（例えば、音声、ビデオ、及び／又はテキストを含む）に関するセッションを作成したり、維持したり、及び／又は破棄したりするために使用することができる。ＳＩＰは、多くのメディア由来のアプリケーションで使用することができ、例えば、ボイップ（Ｖｏｉｃｅ ｏｖｅｒ ＩＰ （ＶｏＩＰ））、ボイスメール、インスタントメッセージ、プレゼンス（ｐｒｅｓｅｎｃｅ）、ＩＰＴＶ，ネットワーク・ゲーム等が上げられる。また、ＳＩＰは、ＩＰマルチメディアサブシステム（ＩＭＳ）に関するコアプロトコルとして使用することができ、固定電話及び無線電話ネットワーク両方のための第三世代パートナーシップ・プログラム（３ＧＰＰ）に関する基礎となっている。
【００４６】
一実施形態において、例えば、サーバー（１３０）は、クライアント（１２０）にとってインターネットを介して利用可能な１以上のウェブサイトを管理するウェブ・サーバーであってもよい。別の構成では、サーバー（１３０）は、電話コールをセットアップしたり切断したり（ｔｅａｒ ｄｏｗｎ）するためのＳＳ７シグナリング・メッセージを受信したり処理するＰＳＴＮに関するタンデム・スイッチであってもよい。別の構成では、サーバー（１３０）は、ＭＧＣＰメディア・ゲートウェイ又はＨ．２４８／ＭＥＧＡＣＯメディア・ゲートウェイであってもよく、それぞれ、コール・エージェント（複数可）やメディア・ゲートウェイ・コントローラ（複数可）（ＭＧＣ）からの要求を受け取る。更に別の構成では、サーバー（１３０）は、ネットワーク（１１０）上の他のクライアント（１２０）からのデータベース要求を処理するためのアプリケーション・サーバーであってもよい。他の構成では、サーバ（１３０）は、例えば、ソーナス・ネットワーク・ＰＳＸ（商標）、ＡＳＸ（商標）、ＧＳＸ（商標）／ＮＢＳ、及び／又はＡＧＣＦサーバーであっても良い。
【００４７】
ＩＩ クライアント実施過負荷コントロール
本発明に係る幾つかの実施形態によれば、外部の過負荷コントロールは、クライアント（１２０）（又は、クライアント（１２０）とサーバー（１３０）の間の中継サーバー・ノード、一般的には動作位置（ａｃｔｉｏｎ ｌｏｃａｔｉｏｎ）と呼ばれている）で実施されてもよい。有利な点として、クライアント実施過負荷コントロールは、過負荷がかかったサーバー（１３０）に対して、かかっている負荷をクライアント（１２０）が減らすことを可能にすることができ、その一方で、過負荷コントロールを目的として、サーバー（１３０）における負荷処理を犠牲にすることがない。その結果サーバー（１３０）のスループットが最大化できる。例えば、各クライアント（１２０）は、サーバー（１３０）での過負荷を表す明示的及び／又は暗黙的過負荷基準に基づいて、過負荷値（ｏｖｅｒｌｏａｄ ｖａｌｕｅ）を決定することができる。この決定された過負荷値をフィードバックとして使用して、クライアント（１２０）は、サーバー（１３０）へのサービス要求を伝送する速度を適切に調整することができる。例えば、サーバー（１３０）に対するサービス要求の伝送速度は、前記決定された過負荷値に反比例するようにすることができる。従って、クライアント実施過負荷コントロールは、過負荷コントロール目的（例えば内部の過負荷コントロール）でサーバー（１３０）が処理リソースを割り当る必要性を防止したり、及び／又は補助したりすることができ、代わりに、サービス要求を処理するために最大量のリソースを割り当て、それによってスループットを上昇させる。
【００４８】
一般的に、サービスに関するサービス要求の生成及び／又は発生は、通信プロトコル・スタックの任意の層で行うことができる。図２は、クライアント（１２０）の構成要素を表したブロック図（２００）である。クライアント（１２０）は、少なくとも１つのコントローラ（２８０）、少なくとも１つのコンピュータ・メモリ・モジュール（２９０）を含むことができ、また、ＯＳＩ参照モデル（ＩＴＵ−Ｔ勧告Ｘ．２００で定義されている）の１以上の層（２１０〜２７０）に従った１以上のプロトコルを含むことができる。前記ＯＳＩ参照モデルは、通信システムに関する抽象的な記述であり、以下のように７つの層に分割される；物理層（２１０）；データリンク層（２２０）；ネットワーク層（２３０）；トランスポート層（２４０）；セッション層（２５０）；プレゼンテーション層（２６０）；及びアプリケーション層（２７０）。各層内で、１以上のエンティティが、別の上位層又は下位層に対してサービスを提供する同様の機能の集合体を実装することができる。
【００４９】
物理層（２１０）は、機械的、電気的、機能的、及び手続き的な仕様を提供することができ、データリンクエンティティ間のビット伝送に関する物理的な接続を作動させたり、維持したり、不活化させたりする。データリンク層（２２０）は、機能的及び手続き的な仕様を提供することができ、ネットワーク・エンティティ間のデータリンク接続を確立したり、維持したり、及び開放したりすることを目的とする。そして、物理層（２１０）で発生するエラーを検出したり、おそらくは修正したりする。ネットワーク層（２３０）は、１以上のネットワーク上でのソース又は目的地間でのネットワーク接続を確立したり、維持したり、終了させたりするための仕様を提供することができ、そして、ソース及び目的地間でのデータ交換を行うための機能的及び手続き的な仕様を提供することができる。トランスポート層（２４０）は、セッション・エンティティ間での透過的なデータ伝送を提供する。そして、信頼性がありコスト的に有利なデータ伝送が達成される詳細な方法に関連する任意のものから開放する。また、トランスポート層（２４０）は、利用可能なネットワークの利用を最適化して、各セッション・エンティティが必要とする性能を最小限のコストで提供することができる。セッション層（２５０）は、エンティティ間でのダイアログ／接続をコントロールする仕様を提供することができる。また、セッション層（２５０）は、２つのプレゼンテーション・エンティティ間でのセッション接続を確立し、順番通りのデータ交換相互作用をサポートしたり、順番通りに接続を開放したりするためのサービスを提供することができる。プレゼンテーション層（２６０）は、アプリケーション・エンティティが通信内で通信又は参照のいずれかを行う情報を表したものを提供することができる。アプリケーション層（２７０）は、クライアント（１２０）上に存在するソフトウェア・アプリケーションと相互作用することができる。
【００５０】
図２に示したクライアント（１２０）では、ＯＳＩ参照モデルの７層に関してモデル化されたプロトコル・スタックを含んでいる。しかし、他のモデル及び／又は層を使用することもできる。例えば、クライアント（１２０）は、層２１０〜２３０（例えばルーターやレイヤー３スイッチ）のみに従ったプロトコルを含むことができる。また、他のモデルも使用可能であり、例えば、インターネットのＴＣＰ／ＩＰモデルが挙げられ、該モデルでは４つの抽象層（リンク層、インターネット層、トランスポート層、及びアプリケーション層）を含む。一般的に、通信プロトコルは、必ずしも前述した抽象層（２１０〜２７０）の１つに属する必要はなく、ある場合には、２つ以上の層に含まれることができる。
【００５１】
上述したように、サービス要求は、クライアント（１２０）のプロトコル・スタック（２１０〜２７０）中の１以上のプロトコルから発生又は生成することができる。コントローラ（２８０）は、プロトコル・スタック（２１０〜２７０）の１以上の層で、過負荷コントロールを実施して、サーバー（１３０）でのサービス要求処理に関するスループット及び／又は遅延を管理することを補助する。幾つかの実施形態において、コントローラ（２８０）は、プロセッサー又は装置であってもよい。他の実施形態では、コントローラ（２８０）はクライアント（１２０）中の別のプロセッサ又は装置によって実行される論理的な機能であってもよい。プロセッサとして、コントローラ（２８０）を設計することができ、コンピュータ・プログラムを実行し、入力データに関して操作したり及び／又は出力データを生成したりすることにより上述した技術を実践する。コンピュータ・プログラムを実行するのに適したプロセッサとして、例示的な意味で、汎用目的のマイクロプロセッサ、特定目的のマイクロプロセッサ、及び任意の種類のデジタル又はアナログコンピュータに関する１以上のプロセッサが含まれる。プロセッサは、例えばＲＯＭやＲＡＭ、又はその両方からの指示及びデータを受け取ることができる。
【００５２】
装置として、コントローラ（２８０）は、特定目的の論理回路として実装することができ、例えば、ＦＰＧＡ（ｆｉｅｌｄ ｐｒｏｇｒａｍｍａｂｌｅ ｇａｔｅ ａｒｒａｙ）、ＦＰＡＡ（ｆｉｅｌｄ−ｐｒｏｇｒａｍｍａｂｌｅ ａｎａｌｏｇ ａｒｒａｙ）、ＣＰＬＤ（ｃｏｍｐｌｅｘ ｐｒｏｇｒａｍｍａｂｌｅ ｌｏｇｉｃ ｄｅｖｉｃｅ）、ＰＳｏＣ（Ｐｒｏｇｒａｍｍａｂｌｅ Ｓｙｓｔｅｍ−ｏｎ−Ｃｈｉｐ）、ＡＳＩＰ（ａｐｐｌｉｃａｔｉｏｎ−ｓｐｅｃｉｆｉｃ ｉｎｓｔｒｕｃｔｉｏｎ−ｓｅｔ ｐｒｏｃｅｓｓｏｒ）、ＡＳＩＣ（ａｐｐｌｉｃａｔｉｏｎ−ｓｐｅｃｉｆｉｃ ｉｎｔｅｇｒａｔｅｄ ｃｉｒｃｕｉｔ）等が挙げられる。サブルーチンは、１以上の関数を実行する保存されたコンピュータ・プログラム、及び／又はプロセッサ、及び／又は特別回路の一部を参照することができる。
【００５３】
図２では、コントローラ（２８０）は、プロトコル・スタック（２１０〜２７０）とは別になるように図示されている。しかし、他の構成を使用することも可能である。例えば、コントローラ（２８０）は、プロトコル・スタック（２１０〜２７０）（例えばアプリケーション層（２７０））中の１以上のエンティティ（例えば、プロトコル又は層）に組み込むことができ、また前記プロトコル・スタック（２１０〜２７０）はコントローラ（２８０）に含むことができる。幾つかの実施形態において、一の層に組み込まれるコントローラ（２８０）には、プロトコル・スタック（２１０〜２７０）中の１以上の他のプロトコル又は層からのシグナルを提供することができる。例えば、アプリケーション層（２７０）に組み込まれたコントローラは、トランスポート層（２４０）からのシグナルに基づいた過負荷コントロールを実施することができる。
【００５４】
コントローラ（２８０）は、コンピュータ・メモリ・モジュール（２９０）と通信するように連結することができる。コンピュータ・メモリ・モジュール（２９０）としては、指示及び／又はデータを保存するための１以上のメモリ装置又はメモリ・サブ・モジュールを含むことができる。メモリ装置（例えばキャッシュ・メモリ）は、一時的にデータを保存するために使用することができる。また、メモリ装置は、マス・ストレージ・デバイスとして実装することができる。コントローラ（２８０）及びコンピュータ・メモリ・モジュール（２９０）は、特定目的の論理回路に補足したり組み込んだりすることができる。
【００５５】
クライアント・ベースの過負荷コントロールは、ホップ・バイ・ホップ又はエンド・ツー・エンドで実装することができる。ホップ・バイ・ホップには、直接トラフィックを交換する全ての近隣のクライアント（１２０）及びサーバー（１３０）間での分離したコントロール・ループを含むことができる。エンド・ツー・エンドには、サービス要求の全体パスにそったコントロール・ループを含むことができる。図３は、モデル・コントロール・ループ（３００）の構成要素を表したブロック図である。モデル・コントロール・ループ（３００）は、クライアント（１２０）のプロトコル・スタック（２１０〜２７０）の１以上の層において、クライアント・ベースの過負荷コントロール概念をどのように実装するかについて、物理的に又は論理的にの何れかで表すことができる。モデル・コントロール・ループ（３００）には、フィードバック・シグナル／値（３０５）を受け取ったり及び／又は暗黙的なフィードバック値（図示しない）を作成したりすることができるセンサー／フィルター（３１０）を含むことができる。センサー／フィルター（３１０）は、参照入力（３１５）を用いたコントロール・ユニット（３２０）と連結している。コントロール・ユニット（３２０）はアクチュエータ（３３０）（例えば、レストリクタ）と連結しており、該アクチュエータは、内部のサービス要求（３２５）（例えば、かけられた負荷）が出力される（３３５）速度を電子的に調整することができる。コントロール・ユニット（３２０）は、センサー／フィルター（３１０）からのフィードバック値と参照入力（３１５）との間の差分に基づいて速度設定を決定し、該設定をアクチュエータ（３３０）へ送ることができる。参照入力（３１５）（例えば、目標過負荷値）は、システム出力（３３５）に関する所望の値をとることができる。参照入力（３１５）は、固定値をとることもでき、及び／又は変数をとることもできる。例えば、参照入力（３１５）は、サーバー（１３０）の容量に基づくことができる。フィードバック値（３０５）及び／又はシステム出力（３３５）は、接続部（１１５）から若しくは該接続部へ及び／又はプロトコル・スタック（２１０〜２７０）の１以上の層から、受け取ったり又は送ったりすることができる。
【００５６】
センサー／フィルター（３１０）は、過負荷値を決定（例えば測定）することができ、該過負荷値は、サーバー（１３０）から受け取る明示的な過負荷シグナル又は通知（例えば、ＳＩＰ ５０３（Ｓｅｒｖｉｃｅ−Ｕｎａｖａｉｌａｂｌｅ）、Ｈ．３２３／Ｑ．９３１ Ｃａｕｓｅコード４２、Ｈ．２４８ 過負荷通知）の速度であってもよく、及び／又は暗黙的な過負荷値（例えば、リクエスト・タイムアウト）の速度であってもよい。また、暗黙的な過負荷通知は、過負荷コントロールを目的としないサーバー（１３０）から受け取ったメッセージを含むことができる（例えば、ＳＩＰ ４８０ （Ｔｅｍｐｏｒａｒｉｌｙ Ｕｎａｖａｉｌａｂｌｅ）、又はＨ．３２３／Ｑ．９３１ ４１ （Ｔｅｍｐｏｒａｒｙ Ｆａｉｌｕｒｅ））。更なる過負荷通知機構を用いて、過負荷フィードバックをクライアント（１２０）に送るために使用することができ、該フィードバックとしては、例えば、特別なＳＩＰ応答ヘッダ又はＳＩＰ過負荷イベント・パッケージが含まれる。前記ＳＩＰ過負荷イベント・パッケージによって、送信エンティティは、サーバーの過負荷状態に寄与したり、及びＮＯＴＩＦＹ要求における過負荷コントロール状態変化に関する通知を受け取ることができるようになる。
【００５７】
幾つかの実施形態において、過負荷通知（明示的及び／又は暗黙的）速度は、平均化フィルター（例えば、センサー／フィルター（３１０）中に含まれるもの）を通すことができ、測定を平坦化する。その後、平均過負荷通知速度を、目標過負荷値（３１５）と比較することができ、そして、その差分は、コントローラ（３２０）を作動させるために使用することができる。コントローラ（３２０）については、前記過負荷通知速度（３０５）（フィードバック値）（及び／又は暗黙的な過負荷値）が、小さな値を持つことができる目標過負荷値（３１５）の近くに集束させるようにするため、サーバー（１３０）へのサービス要求（３３５）の速度を許容された速度（コントロール入力）に調整することができる。拒否速度は、対象となるシステム（例えばサーバー（１３０））に関する負荷レベルを反映することができるため、良好なフィードバック値となりうる。サーバー（１３０）への負荷が増加するにつれて、サーバー（１３０）における内部過負荷コントロール・スキーマは、より多くのサービス要求を拒絶する。従って、過負荷通知を受け取る速度も同様に増加する。そして、拒否の変化速度が、かかっている負荷の変化速度に近づくことができる。
【００５８】
一般的に、センサー／フィルター（３１０）によって測定される過負荷通知は、明示的及び／又は暗黙的の何れかであってよい。幾つかの実施形態において、明示的な過負荷値は、例えば、５０３ Ｓｅｒｖｉｃｅ Ｕｎａｖａｉｌａｂｌｅという応答を介したＳＩＰ要求拒否をうけとったことを表すものであってもよい。暗黙的な過負荷値としては、例えば、サービス要求に対する応答が欠失していることを表すものであってもよい。一実施形態において、暗黙的な過負荷基準は、サービスを要求している仕掛中の要求（例えば、応答を受け取ってない要求）の割合を追跡することによって実現することができる。もし、ある時間間隔内での未応答のサービス要求の割合が割合閾値以上である場合、過負荷基準を満たすことができる。また、暗黙的な検出は、例えば、サービス要求を送るたびにクライアント（１２０）がタイマーをスタートさせることによって実現することもできる。前記タイマーは、タイムアウトを経過する前にサービス要求に対する応答を受け取った場合には、キャンセルすることができる。幾つかの実施形態において、前記タイムアウト期間は、サーバー（１３０）での高負荷で予想される応答時間を少し超える程度に設定することができる。センター（３１０）は、過負荷がかかったサーバー（１３０）からの暗黙的及び／又は明示的な過負荷通知の速度を測定することができる。幾つかの実施形態において、測定された速度は、指数加重移動平均（ＥＷＭＡ）ローパスフィルターを介して平均化することができる。フィルター（３１０）は、前記測定値の推計学情報を平坦化することができ、そして、前記コントロールが過負荷通知の突発的なバーストによって作動することのないようにすることができる。ＥＷＭＡフィルターは以下の通り記述することができる。
【数１】
（１）
ここで、Ｏm（ｎ）は、時間ｎで測定された過負荷値を表す。Ｏavg（ｎ）は、時間ｎでの平均過負荷値を表す。重みｗはローパス・フィルターの時間定数を表す。
【００５９】
幾つかの実施形態において、センサー／フィルター（３１０）は、サービス要求の１以上の特定の分類に関する過負荷通知を測定することができる。例えば、センサー／フィルター（３１０）は、通常のサービス要求のみに関する過負荷値を決定することができる。あるいは、センサー／フィルター（３１０）は、所定の優先値未満の優先値を持つ全てのサービス要求に関する過負荷値を決定することができる（例えば、優先分類が１０レベルであって、１〜６の間の優先レベルを有する全てのサービス要求）。別の実施形態又は補足的な実施形態では、センター／フィルター（３１０）は、１以上の過負荷値を決定し、コントローラ（３２０）に提供することができる。例えば、センサー／フィルター（３１０）は、通常のサービス要求及び優先度の高いサービス要求に第一過負荷値を提供することができ、そして再送信要求については第二過負荷値を提供することができる。
【００６０】
幾つかの実施形態において、かけられた負荷の変化の効果が功を奏し、クライアント（１２０）にフィードバックされる過負荷通知速度に反映されるまでは、クライアント（１２０）は過負荷通知応答を幾つも受け取る可能性がある。従って、毎回の過負荷通知で提供される速度が変化した場合には、早まってかかっている負荷を変化させる可能性があり、これによってかかっている負荷を過剰に矯正したり及び／又は著しく変動させたりする可能性がある。幾つかの実施形態において、提供された負荷速度に対して１以上の更新がなされた後で、待機期間Ｔｗａｉｔ（又は、ブラインド間隔期間）を導入することができ、該期間では過負荷通知はカウントしない。前記待機期間終了後は、過負荷通知を過負荷通知速度にカウントすることができる。
【００６１】
コントロール・ユニット（３２０）は、設計された目標過負荷値の近くに平均過負荷値を維持するように、許容されたサービス要求伝送速度をサーバー（１３０）に対して適用することができる。従って、コントロールは、平均過負荷値が目標過負荷値を超えるとすぐに作動することができる。幾つかの実施形態において、コントロール・ユニット（３２０）は、ＡＩＭＤ（Ａｄｄｉｔｉｖｅ Ｉｎｃｒｅａｓｅ／Ｍｕｌｔｉｐｌｉｃａｔｉｖｅ Ｄｅｃｒｅａｓｅ）の原理に基づいてもよく、時間に対する許容された速度を更に増加させることができる。過負荷を検出すると、その後、コントロール・ユニット（３２０）は、特定の因子によって許容速度を倍数的に減少させることができる。ＡＩＭＤコントロール・スキーマによって、安定且つ正当な稼動ポイントに収束させることができる。ＡＩＭＤアルゴリズムを用いて、コントロール・ユニット（３２０）は、固定サイズのステップで直線的に許容速度を増加させて、余分な容量を探ることができる。そして、過負荷を検出した際には、許容速度を固定因子（例えば０．５）によって倍数的に減少させることができる。
【００６２】
幾つかの実施形態において、コントロール・ユニット（３２０）は、過負荷値がすぐに目標過負荷値に収束するように許容速度を適用することができる。他の実施形態では、過負荷設定に素早く反応できるようにするため、許容速度の変化速度を、目標過負荷値に対する前記過負荷値の偏差に比例するようにすることができる。例えば、設定された目標速度に過負荷値が近い場合には、コントロール・ユニット（３２０）は、許容速度に対する変化を小さくすることができる。同様に、設定された目標過負荷値から更に過負荷値が離れるにつれて、コントロール・ユニット（３２０）は、許容速度への変化を大きくすることができる。該スキーマは、提供されたサービス要求伝送速度における急激な変化（増加及び／又は減少）に素早く反応することができる。
【００６３】
幾つかの実施形態において、コントロール・ユニット（３２０）は、１以上の特定分類の提供されるサービス要求（３２５）に関する許容サービス要求伝送速度をサーバー（１３０）に対して適用することができる。例えば、コントロール・ユニット（３２０）は、優先サービス要求に関する許容伝送速度については変化しない状態のままにする一方で、通常のサービス要求に関する許容伝送速度については適用することができる。あるいは、コントロール・ユニット（３２０）は、所定の優先度未満の優先度を持つ全てのサービス要求（例えば、１０段階の優先分類のなかで、優先度１〜６のサービス要求全て）に関して許容伝送速度を適用することができる。別の実施形態又は補足的な実施形態では、コントロール・ユニット（３２０）は、提供されたサービス要求（３２５）の１以上の分類に関して許容伝送速度を別々に適用することができる。例えば、第一種類のサービス要求に関する許容伝送速度は、センサー／フィルター（３１０）からの第一過負荷値に基づくことができ、第二種類のサービス要求に関する許容伝送速度は、センサー／フィルター（３１０）からの第二過負荷値に基づくことができる。
【００６４】
アクチュエータ（３３０）は、コントローラ（３２０）からの出力に基づいて、サービス要求（３３５）の伝送速度を電子的に制限することができる。前記制限を実施するために、異なる機構を使用することができる。例えば：（１）パーセント拒否；（２）要求ギャッピング；及び／又は（３）リーキィ・バケット（ｌｅａｋｙ ｂｕｃｋｅｔ）。割合拒否機構は、あるパーセンテージの提供された要求（３２５）を許容することができ、従って、提供された速度が変化するのに伴って許容速度を変化させることができる。コントローラ（３２０）は、許容サービス要求のパーセンテージを調整して、提供された速度を追跡することができる。もし、リーキィ・バケットを用いる場合、コントローラ（３２０）は、出力を更新する頻度をより少なくして、提供された速度を追跡することができる。これにより、フィードバック・コントロールを安定化させることを補助することができる。リーキィ・バケットと同様に、要求ギャッピングも、１つのトークンに関するバケットサイズを用いて動作することができる。補助的な実施形態において、アクチュエータ（３３０）は、入ってくる負荷（３２５）を一時的に保存するために１以上のバッファを含むことができる。
【００６５】
また、補足的又は別の実施形態において、アクチュエータ（３３０）は、分類に基づいてサービス要求の伝送を制限することもできる。一実施形態において、オーバーロード・フレンドリー・再伝送（ｏｖｅｒｌｏａｄ−ｆｒｉｅｎｄｌｙ ｒｅｔｒａｎｓｍｉｓｓｉｏｎｓ）は、以前のサービス要求からの再伝送である１以上の提供されたサービス要求（３２５）の自動再伝送を電子的に落とすアクチュエータ（３３０）を含むことができる。オーバーロード・フレンドリー・再伝送は、過負荷のかかったサーバー（１３０）に対する集合速度の自動コントロールを提供できる点で有利であり、該サーバーは古い要求の再伝送と新たな要求とを含む。更に、オーバーロード・フレンドリー・再伝送は、通常の要求の伝送よりも、高い優先度要求の再伝送を優先させることができる点で有利である。一般に、アクチュエータ（３３０）は、提供されたサービス要求（３２５）に関する１以上の分類に基づいて、サービス要求の伝送について優先度を付けることができる。
【００６６】
モデル・コントロール・ループ（３００）の構成要素は図３では別々に図示されているが、他の構成も使用可能である。例えば、モデル・コントロール・ループ（３００）の１以上の構成要素は、例えばコントローラ（２８０）等と同じユニット内に結合することができる。更に、クライアント（１２０）は、１以上の追加コントロール・ループ（３００）を有することができる。ある場合には、追加コントロール・ループ（３００）は、１以上の追加下流サーバーへのサービス要求伝送速度をコントロールするために使用することができる。補助的又は別の実施形態では、追加コントロール・ループ（３００）は、同じサーバーへの異なる分類のサービスに関するサービス要求伝送速度をコントロールするために使用することができる。
【００６７】
図４は、ウィンドウ化したタイム・インターバルを表す図である。幾つかの実施形態において、クライアント実施過負荷コントロール・スキーマはタイム・ドリブン（ｔｉｍｅ ｄｒｉｖｅｎ）であってもよい。タイム・ドリブン・スキーマにおいて、過負荷値は、所定の回数（例えば、ｔi， ｔi+1， ｔi+2等）で測定することができ、及び／又は所定の期間（例えば、Ｔn-1， Ｔn， Ｔn+1）測定することができる。１以上のブラインド間隔時間（例えば、ＴＢn-1， ＴＢn， ＴＢn+1等）を含むことができ、該間隔時間では、過負荷値を測定しない。幾つかの実施形態において、期間Ｔj及び／又はＴＢjを固定することができる。他の実施形態では、期間Ｔj及び／又はＴＢjは、変数であってもよい（例えば、既知のネットワーク遅延及び／又はシステム帯域等のシステム・パラメータに基づく）。
【００６８】
図５は、クライアント（１２０）での、コントローラ（２８０）によって実行されるクライアント・ベース過負荷コントロールを描いたフローチャート（５００）である。フローチャート（５００）の要素は、図３の例示的なモデル・コントロール・ループ（３００）を用いて記述される。クライアント・コントロールを介したサーバー過負荷制限としては、過負荷値（５１０）を決定すること（５１０）、過負荷値に基づいて伝送制限速度を決定すること（５２０）、伝送制限速度に基づいてサービス要求の伝送を制限すること（５３０）、及び／又は、任意で、新たな過負荷値を決定する前にブラインド間隔期間待機すること（５４０）が含まれる。幾つかの実施形態において、コントローラ（２８０）は、長さTのウィンドウ・タイム・インターバルに関するフローチャート（５００）中に描かれたアルゴリズムを実行することができる。例えば、もし、長さＴの間隔を１秒に設定した場合、コントローラ（２８０）は、フローチャート（５００）の要素を１秒ごとに実行する。補助的又は別の実施形態では、コントローラ（２８０）は、イベンド・ドリブン・ベースでフローチャート（５００）を実行することができる。例えば、フローチャート（５００）が最後に実行されてから受け取り、そして入ってくる要求（３２５）の数が、値Ｎを超えた場合に、コントローラ（２８０）は、フローチャート（５００）を実行することができる。フローチャート（５００）の要素は、クライアント（１２０）のプロトコル・スタック（２１０−２７０）内の１以上のプロトコル又はプロセスの間別々に実行することができるし、あるいは同時に実行することもできる。
【００６９】
過負荷値の決定（５１０）は、センサー／フィルター（３１０）が行うことができる。期間ｎの間の過負荷値の決定（５１０）は、Ｏn-avgで表すことができるが、以前にサーバー（１３０）に伝送された少なくとも２以上の要求が過負荷基準を満たしているかどうかを決定することを含むことができる。過負荷値Ｏn-avgは、例えばコンピュータ・メモリ・モジュール（２９０）中に保存することができる。幾つかの実施形態において、過負荷値は、過負荷基準を満たす要求の平均数であってもよい。例えば以下の通り。
【数２】
（２）
一般的に、過負荷値は、１以上の以前の期間からの過負荷測定数に基づく任意の関数ｆ（例えば、滑らかな関数）であってもよい。例えば、
【数３】
（３）
【００７０】
幾つかの実施形態によると、過負荷基準は、サーバー（１３０）からの明示的な拒否メッセージ（例えば、Ｏn-meashured＝Σｒｅｊｅｃｔｉｏｎｓ）を受け取ることを含むことができる。補足的又は別の実施形態では、過負荷基準は、例えば以下のタイムアウト等の暗黙的な値に基づいても良い。
【数４】
（４）
ここでＳｎは、１以上の現在の又は以前の期間（例えば、期間ｎ）の間に送られた要求の数を表し、また、
【数５】
（５）
ここでｔsiは、i番目要求が送られた時間を表すことができる。ｔriはi番目要求に対する要求を受け取った時間を表すことができる。tmeasuredは、過負荷測定の時間を表すことができる。Ｄは遅延閾値を表すことができる。前記遅延閾値Ｄは静的（例えば、予め知られたサーバー（１３０）遅延に基づく）及び／又は動的（例えば、クライアント（１２０）による設定変化）であってもよい。幾つかの実施形態において、時間ｎに関する動的遅延閾値Ｄnは、
【数６】
である。
ここで、Ｒnは平均応答時間を表すことができ、
【数７】
は、安全因子である(例えば≧１)。
平均応答時間は、
【数８】
であってもよい。ここで、αは平均因子を表すことができ、ｄは遅延測定を表すことができる。
【００７１】
更に他の補助的又は別の実施形態では、過負荷基準は暗黙的な値に基づくことができ、例えば、以下のような故障応答（ｏｕｔ ｏｆ ｏｒｄｅｒ）に基づくことができる。
【数９】
(6)
ここで、Ｓｎは１以上の期間（例えば、期間ｎ）の間に送られた要求の数を表すことができる。そして、
【数１０】
（７）
である。ここで、ｔsiは、ｉ番目の要求が送られた時間を表すことができる。triは、ｉ番目の要求に対する応答を受け取った時間を表すことができる。そして、ｆは|tsj - tsi| 及び／又は |j-i|の関数を表すことができる。一般的に、過負荷値は上記（２）〜（７）の１以上に基づくことができる。
【００７２】
過負荷値に基づいて伝送制限速度を決定すること（５２０）は、コントロール・ユニット（３２０）によって実行するこができる。図６は、過負荷値に基づいて伝送制限速度を決定すること（５２０）を表すフローチャート（６００）である。伝送制限速度を決定することには、過負荷条件が存在するかどうかを決定すること（６１０）が含まれる。もし、過負荷条件が存在する場合には、伝送制限速度はステップ・ダウンすることができる（６２０）。もし、過負荷条件が存在しない場合には、伝送制限速度はステップ・アップ（６３０）することができる。過負荷条件が存在するかどうかを決定すること（６１０）は、過負荷値と目標過負荷値（３１５）を比較することを含むことができ、該目標過負荷値はOtargetで表すことができる。
【００７３】
幾つかの実施形態によれば、伝送制限速度は、期間ｎ中に対する
【数１１】
で表現される。そして、
【数１２】
に従ってステップ・ダウン（６２０）される。ここで、Ｐn+1は以下の通り、伝送速度のパーセンテージである：
【数１３】
, (8)
ここで、ＧSDは、コントローラのステップ・ダウン・ゲインを表す。別の又は補助的な実施形態において、伝送速度制限は以下に従ってステップ・ダウンすること（６２０）ができる：
【数１４】
【００７４】
過負荷値が目標過負荷値を下回っている場合には、クライアント（１２０）は、ステップ・アップ・フェーズ（６３０）に入ることができる。前記ステップ・アップ・フェーズ（６３０）は、以下の条件の場合に継続される：（１）過負荷値が目標過負荷値を下回るとき；及び、（２）到達した過負荷（λ）（３２５）が、コントローラ（３２０）が許容した速度（λ＊）を上回る場合。幾つかの実施形態において、ステップ・アップ・フェーズは以下の２つのサブ・フェーズに分けることができる：「過負荷リカバリ」及び「過負荷防止」。過負荷リカバリの最中は、コントローラ（３２０）は、過負荷イベントの前に平均許容速度まで回復させようとすることができる。過負荷防止の最中は、コントローラ（３２０）は、許容速度をゆっくりと増加させることができる。補助的又は別の実施形態では、到達した過負荷（λ）（３２５）がコントローラ（３２０）が許容した速度（λ＊）を下回る場合に、コントローラ（３２０）での許容速度（λ＊）を変化しないままにすることができる。
【００７５】
伝送制限速度は以下に従ってステップ・アップすることができる（６３０）：
【数１５】
ここでｓｔｅｐ＿ｓｉｚｅは固定することができる。あるいは、ｓｔｅｐ＿ｓｉｚｅは以下に従って決定することができる：
【数１６】
ここでＧSUはステップ・アップ・ゲインを表し、
【数１７】
(9)
ここで、
【数１８】
は、クライアント（１２０）がサーバー（１３０）と共に有する最大シェアに基づくことができる値であって、予め設計された巨大な値を表すことができる。
そして、
【数１９】
は、過負荷に入る前又はステップ・ダウン・フェーズに入る前に提供される平均過負荷（３２５）を表すことができる。
【数２０】
であるときには、「過負荷リカバリ」と呼ぶことができるが、クライアント（１２０）は、過負荷状態の前の平均的な提供された負荷にリカバリすることを試みることができる。
【数２１】
であるときには、「過負荷回避」と呼ぶことができるが、クライアント（１２０）は、将来的な過負荷を回避するためにサーバー（１３０）を探索することを試みることができる。別の実施形態では、
【数２２】
は、時間ｎでの入ってくる要求（３２５）の速度を表すことができる。前記step_size値は、step_sizemaxを上限及び／又はstep_sizeminを下限値として境界値を設けることができる。ステップ・アップ・ゲインＧSUは固定しても、変動してもよい。例えば、
【数２３】
の場合には、より保守的にするために、ＧSUにより低いゲインを割り当てることができる。さらに別の又は補助的な実施形態では、step_sizeは以下に従って決定することができる：
【数２４】
【００７６】
調査フェーズ（即ち、ステップ・アップ・フェーズ）中、もし現在提供されている負荷（３２５）が最大速度ratemaxを超え、且つ最大速度ratemaxが
【数２５】
を下回る場合には、前記最大速度ratemaxは、
【数２６】
に設定される。前記調査フェーズ中、もし、センサー／フィルター（３１０）からの平均過負荷値が目標過負荷値（３１５）を超える場合には、クライアント（１２０）は、ステップ・ダウン・フェーズに（再度）突入し、現在の伝送制限速度を、最大速度ratemaxに関する現在の値として記録することができる。例えば、クライアント（１２０）は、現在の伝送制限速度を、
【数２７】
に関する現在の値として記録することができる。
【００７７】
伝送制限速度である
【数２８】
は、アクチュエータ（３３０）へ送られる。アクチュエータ（３３０）は、入ってきたサービス要求（３２５）を前記伝送制限速度である
【数２９】
によって（例えば前記伝送速度以下に）制限された速度で伝送（３３５）することができる。
【００７８】
新たな過負荷値を決定する（５１０）前のブラインド間隔期間待機するステップ（５４０）は、ブラインド間隔期間Tblindに基づくことができ、該期間は静的（例えば、サーバー（１３０）からの既知の平均応答時間に基づく）及び／又は動的（例えば、クライアント（１２０）による設定変化）であっても良い。幾つかの実施形態において、ブラインド間隔は、下記のとおり平均要求・応答遅延を動的に測定することに基づくことができる：
【数３０】
(10)
ここで、Ｒｎは平均応答時間を表す。αは平均因子であり、ｄは遅延測定である。時間ｎ＋１におけるブラインド時間間隔Ｔblindは、下記の通り設定することができる：
【数３１】
(11)
ここで、ｆblindは、１以上の安全因子（ｓａｆｅｔｙ ｆａｃｔｏｒ）を表すことができる。Ｔblindを動的に設定する別の方法として、連続した番号Ｎinit、及び速度を減少させた後の第一リクエストを送る時間を保存すること、並びに該ポイントでＴblindを開始することを含めることができる。Ｔblindは、Ｎinitよりも大きい連続番号Ｎを有する要求に関する応答を受け取ったあとで終了することができる。
【００７９】
新たな要求を拒絶することなく所定量の時間を維持し、過負荷値が目標過負荷値を下回った状態を維持した場合には、クライアント（１２０）は過負荷状態を脱することができ、以下のように設定することができる：
【数３２】
【００８０】
ＩＩＩ．計算の結果（Ｃｏｍｐｕｔａｔｉｏｎａｌ Ｒｅｓｕｌｔｓ）
量的な調査では、クライアント実施過負荷コントロールが、異なる過負荷プロファイル下で、ターゲット・サーバーの容量及び負荷分散をどのように適切に適用するかを表す。以下のシミュレーションでは、パケットレベルのシミュレーターＯＰＮＥＴを使用しており、該ＯＰＮＥＴは、ＳＩＰモジュール、並びにＳＩＰサーバー内の内外過負荷コントロールを実施するためのモジュールと共に拡張されている。ＳＩＰモデルはＳＩＰ ＲＦＣ ３２６１を実装する。ネットワーク・トポロジーには、ユーザー・エージェント（ＵＡ）が含まれており、該エージェントはエッジ・プロキシに接続されており、該プロキシはＵＡの要求をコア・プロキシに送る。各エッジ・プロキシは、１０のＵＡクライアント及び１０のＵＡサーバーに接続されている。エッジ・プロキシ及びコア・プロキシの数は、異なるシミュレーション・シナリオ間で変化する。各ＵＡクライアントは、INVITEトランザクションで表されるコールを生成し、続いてＢＹＥトランザクションで表されるコールを生成する。
【００８１】
図７は、セッション確立に関するシミュレートされたモデルＳＩＰメッセージ・フローを表したハシゴ図である。ＵＡクライアントが生成したコールは、ポワゾン到着モデルに従い、目的地ＵＡサーバーは、ネットワーク中の利用可能な全てのＵＡサーバーからランダムに選択される。全てのコア・プロキシが過負荷状態であるときには、エッジ・プロキシは要求を拒絶することができる。コア・プロキシは、目的地ＵＡのエッジ・プロキシに対する要求を送ることができる。プロキシは、到着するＳＩＰメッセージを保持する有限のキューとして表現することができ、一定の速度で該メッセージを提供（例えば、再伝送）することができる。こうしたサービス速度は、プロキシのメッセージ処理容量を規定する。このシミュレーションにおいては、エッジ・プロキシは無限の容量を有すると仮定されており、一方コア・プロキシは有限の容量を有するように設定されている。こうした仮定によって、コア・プロキシにおける過負荷の振る舞いに関する検証を行うことが可能となる。また、該仮定は、複数のエッジ・プロキシからの集中負荷をコア・プロキシが処理するものとして妥当な仮定である。このシミュレーションにおける全てのＳＩＰメッセージはＵＤＰを介して伝送され、従って、ＳＩＰによって再伝送を介してメッセージの信頼性が保障される。表１は、シミュレーションの為に使用される設定を表にしたものである（Ahmed Abdelal, Wassim Matragi, "Signal-Based Overload Control for SIP Servers", In Proceedings of IEEE Consumer Communications and Networking Conference (CCNC), January 2010を参照されたい。該文献全体を本明細書中に組み込む）。
【表１】
【００８２】
ＳＩＰシミュレーションにおいて、フル・コールすると、７つのメッセージの負荷がプロキシにかかる事になる（５つのメッセージはＩＮＶＩＴＥトランザクションであり、２つのメッセージはＢＹＥトランザクションである）。500 messages/secの容量で処理するコア・プロキシメッセージの場合、各コア・プロキシの容量は約72 calls/secである。以下の結果の中で、プロキシ／ネットワーク・スループットは、パフォーマンス・メトリックとして使用することができる。スループットは、成功したコールの速度を表す。もし、ＵＡクライアントが１０秒未満内に２００−ＯＫを受け取った場合コールが成功したものと定義する。そして、ＵＡサーバーはＩＮＴＩＴＥ−ＡＣＫを受け取る。コール・セットアップ遅延は、最初のＩＮＶＩＴＥ要求を送ってから２００−ＯＫを受け取るまでの間の時間で定義される。全てのシミュレーションは、システムが一貫した動作に達することを保証するのに充分長い時間実行される。
【００８３】
図８は、過負荷スキーマなし（８１０）、キュー・ベース実行を利用したサーバー・ベースの内部過負荷スキーマ（８２０）、及びクライアント・ベース過負荷スキーマ（８３０）に関しての与えられた負荷に対するスループットを表すシミュレーションの結果の二次元プロット図（８００）である。過負荷コントロールがない状態では、与えられた負荷がプロキシの集計容量である約142 calls/secを超えると、スループットが急速にゼロまで低下する。これは、キューのオーバー・フローによりＳＩＰメッセージが落ち、それに続いて上流クライアントからのＳＩＰ要求再伝送が行われることが原因となって生じる。内部過負荷コントロールは、過負荷コントロールが無い場合と比べると多少良好なスループットを達成できている。この理由は、拒否する作業量が、受け入れる場合と比べて労力を要さないからである。クライアント・ベースの過負荷コントロールでは、約142 Calls/Secのスループットを達成できている。
【００８４】
図９は、本発明の例示的な実施形態に従って、集中したサーバー過負荷を検出及び制限するためのネットワーク（９００）を概念的に表したものである。ネットワーク（９００）（例えば、図１の伝送媒体１１０）は、ソース（９０２Ａ，９０２Ｂ〜９０２Ｎ）（集合的にソース９０２）を含む。幾つかの例では、遠距離通信ネットワークに関して、通信プロトコルのセッション要求がネットワーク（９００）に入ってソース（９０２）を通過する（例えば、図１を参照すると、コールするクライアント（１２０）はセッション要求を接続部（１１５）を経由してソース（９０２）に伝送する）。例えば、通信プロトコルは、セッション確立プロトコル (SIP),ハイパーテキスト・ドランスファー・プロトコル (HTTP)、ストリーム制御転送プロトコル (SCTP)、トランスミッション・コントロール・プロトコル (TCP)、及び任意の他の種類のセッション／コネクションベースのプロトコル（例えば、要求−応答方法論に従ったプロトコル）であってよい。データは、ソース（９０２）から下流サーバー（９０４）（例えば図１のサーバー（１３０））へ送られる。また、ネットワークは、ソース（９０２Ａ及び９０２Ｂ）並びに下流サーバー（９０４）に接続されたサーバー・ノード（９０６）を含む。サーバー・ノード（９０６）は、プロセッサ（９０８）、コンピューター・メモリ・モジュール（９１０）（例えばデータベース）を含む。コンピューテーション・ノード（９１２）は、サーバー・ノード（９０６）を接続されている。コンピューテーション・ノード（９１２）は、コントロール・データベース（９１４）を含む。
【００８５】
ネットワーク（９００）は、１つのサーバー・ノード（９０６）及び１つの下流サーバー（９０４）だけを示してはいるが、ネットワーク（９００）は、任意の数のサーバー・ノード（例えば、ソース（９０２）と下流サーバー（９０４）との間の中継ノード）及び／又は下流サーバー（９０４）を含むように設計することができる。中継ノードは、ソース（例えばソース（９０２））でもなく、下流サーバー（例えば下流サーバー（９０４））でもない任意のノードである。ソース（９０２）からのデータは、下流サーバー（９０４）を介してネットワークを出発する（例えば、ソース（９０２）からのセッション要求が下流サーバー（９０４）を介してネットワーク（９００）を出発する）。コンピューテーション・ノード（９１２）は、該ノードが（例えばサーバー・ノード（９０６）を介して）受け取るデータを処理することができる。幾つかの実施形態において、コントロール・データベース（９１４）は、図１３−１４Ｂで更に詳述するが、１以上の動作位置（例えば、サーバー・ノード（９０６）等の中継ノード）にコントロール・パラメータ（即ち、コントロール情報）を送るためのコンピューテーション・ノード（９１２）によって使用される中央データベースである。
【００８６】
図１０は、本発明の例示的な実施形態に従って、ネットワーク中の集中したサーバー過負荷を保存及び検出するためのブルーム・フィルター（１０００）を概念的に表したものである。ブルーム・フィルター（１０００）は、ストレージ・デバイス（例えば、コンピュータ・メモリ・モジュール（９１０）及び／又はコントロール・データベース（９１４））によって実装され、ここで、キー（例えば、ｘ1及びｘ2）は、カウンター配列（１００４）中のカウンター（１００２Ａ〜１００２Ｎ）（集合的にカウンター（１００２））に、１以上のハッシュ関数（例えば、ハッシュ関数 Ｈａｓｈ1〜Ｈａｓｈ3）によって配置される。幾つかの実施形態において、カウンター配列（１００４）は、０又は１の何れかをセットできるカウンター・ビット配列である（ここで値０は、ブルーム・フィルター中の非メンバーシップを表し、値１はブルーム・フィルター中のメンバーシップを表す）。幾つかの実施形態において、ハッシュ関数及びカウンター配列（１００４）は、カウンティング・ブルーム・フィルター（又は、マルチ・レベル・ブルーム・フィルター（ＭＬＢＦ））であり、ここでカウンター配列（１００４）はカウンティング整数の配列である。例えば、ＭＬＢＦは複数閾値を有し、該閾値は異なるコール又はセッションに関連する。高優先度のコール又はセッションについては、高い閾値を使用し、一方で、低優先度のコール又はセッションについては、低い閾値を使用する。値がブルーム・フィルター（１０００）に挿入されるたびに、ハッシュ関数によって決定されるカウンティング整数が増加する（例えば、０又は１のいずれかを設定するのではなく、挿入の度に０〜１〜２等）。
【００８７】
ハッシュ関数は、任意のデータ・ストリームを入力（例えば、下流サーバー（９０４）等の下流サーバーの名前）として受け取り、整数を出力として戻す関数である。リターンされた整数は、カウンター配列（１００４）のカウンター（１００２）を同定するのに使用される（例えば、カウンター配列（１００４）中の全てのカウンター（１００２）が０に設定される）。従って、ブルーム・フィルター（１０００）は、複数のハッシュ関数（例えば、ハッシュ関数Ｈａｓｈ1〜Ｈａｓｈ3）を用いて、単一のキーについて、カウンター配列（１００４）内の複数のカウンター（１００２）にマッピングを行う。該実施形態において、２つの操作をブルーム・フィルター（１０００）上で実行することができる：INSERT(key) （例えば、INSERT (x1)（1010）及び INSERT (x2)（1012）) 並びに TEST(key) (例えば、 TEST(x1)（1014)）。ブルーム・フィルター（１０００）の一実施形態の機能性については、以降の図１１を参照しながら述べることにする。
【００８８】
ブルーム・フィルター（１０００）は、通信プロトコルに関する複数の統計情報についての追跡を継続するために使用することができる。例えば、もしネットワーク（例えばネットワーク（９００））がＳＩＰを使用している場合、ブルーム・フィルター（１０００）は、以下に関する数を保存する：下流サーバー（９０４）に関するセッション拒否；ソース（９０２）から下流サーバー（９０４）への失敗した接続要求；下流サーバー（９０４）からの過負荷通知；及び、任意で他の有用な通信プロトコル統計情報。ブルーム・フィルターは、分散させるやり方で、情報（例えば、セッション拒否統計情報等のフィードバック・メッセージ統計情報、及び／又は下流サーバー（９０４）からの他の過負荷フィードバック）を保存することを目的とする計算処理的及び空間的に有効な構造を提供する。有利な点として、ブルーム・フィルターは、一定の挿入時間、一定のテスト時間、及びフォールス・ポジティブに関する有限の確率（例えば、ブルーム・フィルターがキーを表す回数が、キーが設定されていなくてもブルーム・フィルター中に存在するなど）を有している。更に言えば、ブルーム・リルターは、保存目的用に極端にコンパクトであり、多数のブルーム・フィルターを追加して集合させることができる。例えば、複数のカウンター配列を（例えばネットワーク中（９００）で）使用することができ、ここで、複数のカウンター配列それぞれは、異なるサーバー・ノードに保存することができる（例えば、ネットワーク（９００）が複数のサーバー・ノード（９１２）を備える実施形態、又は中継ノード（９０６）がカウンティング・ブルーム・フィルターを保存するためのサーバー・ノードとして設計される実施形態など）。中央サーバー・ノード（例えば、コンピューテーション・ノード（９１２））は、複数のカウンター配列を集合させる。そして、異なるサーバー・ノード間での複数のカウンター配列に関連する各下流サーバー（例えば下流サーバー（９０４））からフィードバック・メッセージを受け取った数を計算する。
【００８９】
図１１は、本発明の例示的な実施形態に従って、ネットワーク中の集中したサーバー過負荷を検出するための方法（１１００）を示したフローチャート図である。
ステップ（１１０２）では、サーバー・ノード（９０６）は、下流サーバー（例えば下流サーバー（９０４））からフィードバック・メッセージを受け取る。フィードバック・メッセージは、通信プロトコルの統計情報（例えば下流サーバー（９０４）からのＳＩＰセッション拒否）を含む。ステップ（１１０４）では、サーバー・ノード（９０６）は、フィードバック・メッセージ中に含まれる情報をもとに（例えば下流サーバーの名前をもとに）１以上のハッシュ関数（例えば、ハッシュ関数Ｈａｓｈ1〜Ｈａｓｈ3）を用いて、カウンター配列（例えば、カウンター配列（１００４）であって、コンピューター・メモリ・モジュール（９１０）中に保存できるもの）からの１以上のカウンターのうちどれが下流サーバーに関連しているかを決定する。１以上のカウンターは、統計情報（例えば、下流サーバー（９０４）から受け取ったセッション拒否の数）を含む下流サーバーからのフィードバックの数に対応する数を保存することができる。
【００９０】
ステップ（１１０６）では、サーバー・ノード（９０６）は、統計情報を含むフィードバック・メッセージに応答して、１以上のカウンターを増加させる。ステップ（１１０８）では、サーバー・ノード（９０６）は、１以上のハッシュ関数を用いて、１以上のカウンター内に保存される数の値を決定する。ステップ（１１１０）では、サーバー・ノード（９０６）は、値が所定の基準を満たしているかどうかに基づいて、下流サーバーに関するネットワーク（例えばネットワーク（９００）中の過負荷エピソードを前記値が表しているかどうかを決定する。もし、前記値が過負荷エピソードを表していない場合には、前記方法はステップ（１１０２）に戻る。もし、前記値が過負荷エピソードを表す場合には、前記方法（１１００）はステップ（１１１２）に進む。該ステップでは、サーバー・ノード（９０６）（及び／又はコンピューテーション・ノード（９１２））は、過負荷エピソードの原因となっている１以上のソース（例えばソース（９０２）からの１以上のソース）を同定する。ここで、統計情報を含むフィードバック・メッセージを下流サーバーに伝送させている各ソースは、下流サーバーへの伝送を開始する。ステップ（１１１４）では、サーバー・ノード（９０６）（及び／又はコンピューテーション・ノード（９１２））は、前記値に基づいてコントロール動作を実行するための１以上のコントロール・パラメータを決定する。
【００９１】
ステップ（１１０４）に関して言うと、本発明のシステム及び方法は、下流サーバー（例えば下流サーバー（９０４））に関するネットワーク中の各サーバー・ノード（例えば、ネットワーク（９００）中のサーバー・ノード（９０６））において通信プロトコルの統計情報（例えばセッション拒否）の追跡を継続する。一実施形態において、各サーバー・ノードは、カウンティング・ブルーム・フィルターを使用し、サーバー・ノード基盤（ｂａｓｉｓ）ごとに、サーバー・ノード上の対象となる通信プロトコルの統計情報に関する計算を管理する。通信プロトコル統計情報を含むフィードバック・メッセージをサーバー・ノードが受け取るたびに、サーバー・ノードは、該サーバー・ノードに対応するカウンティング・ブルーム・フィルターと、増加され且つ組み合わされる目的キーに関するカウンターとを更新する。
【００９２】
通信プロトコル統計情報の受け取りについては、下流サーバーからサーバー・ノードへ伝送されるフィードバック・メッセージとして上述したが、サーバー・ノードは、複数の方法で観察可能なフィードバック・メッセージ（例えばセッション拒否通知）を観察することができる。例えば、サーバー・ノードは、明示的にフィードバック・メッセージを観察することができる（例えば、セッション・シグナリング・メッセージ等のフィードバック・メッセージの経路中にあるサーバー・ノード（９０６）等のネットワーク要素上への実装を介して）。サーバー・ノードは、暗黙的にフィードバック・メッセージを観察することができる（例えば、ＶｏＩＰ／ＩＭＳネットワーク内のコール・ディテール・レコード（ＣＤＲ：Ｃａｌｌ Ｄｅｔａｉｌ Ｒｅｃｏｒｄ）等のサーバー・ログを調査することによるなど）。
【００９３】
ブルーム・フィルターにキーを挿入（ＩＮＳＥＲＴ）することを目的として、Ｎ個のハッシュ関数の各ハッシュ関数をキーに適用することにより、Ｎ個のハッシュ値を作成する。その後、Ｎ個のハッシュ値に相当するビット・ベクトル中のＮ個のポジションを増加させる（例えば、１に設定し、１ずつ増加させる等）。図９及び１０を参照すると、サーバー・ノード（９０６）は、３つのハッシュ関数Ｈａｓｈ1〜Ｈａｓｈ3を用いて、カウンター配列（１００４）からの１以上のカウンター（１００２）のうちどれが下流サーバーと関連しているかについて決定を行っている。ここで、キーは、下流サーバー（９０４）の名前等、下流サーバーに関する識別子である。例えば、フィードバック・メッセージが下流サーバー（９０４）から送られたことを表すデータをサーバー・ノード（９０６）が保存する必要がある場合に、サーバー・ノード（９０６）は、ＩＮＳＥＲＴ（ｘ1）（１０１０）を実行して、新たな値をブルーム・フィルター（１０００）内に挿入する。ここで、ｘ1は、下流サーバー（９０６）の名前である。図１０に示すように、ＩＮＳＥＲＴ（ｘ1）（１０１０）は、３つのハッシュ関数Ｈａｓｈ1〜Ｈａｓｈ3を使用して、ｘ1（下流サーバー（９０６）の名称）に関連するカウンター配列内（１００４）のポジション（１０１０Ａ、１０１０Ｂ、及び１０１０Ｃ）を特定している。例えば、もし、フィードバック・バックメッセージが異なる下流サーバー（下流サーバー（９０４）ではない）から送られたことを表すデータを保存する必要がサーバー・ノード（９０６）にある場合には、サーバー・ノード（９０６）は、ＩＮＳＥＲＴ（ｘ2）（１０１２）を実行して、新たな値をブルーム・フィルター（１０００）に挿入することができる。ここでｘ2は前記異なる下流サーバーの名前である。図１０に示すように、ＩＮＳＥＲＴ（ｘx）（１０１２）は、３つのハッシュ関数Ｈａｓｈ1〜Ｈａｓｈ3を使用して、ｘ2（前記異なる下流サーバーの名前）に関連するカウンター配列（１００４）内のポジション（１０１２Ａ、１０１２Ｂ及び１０１２Ｃ）を同定する。
【００９４】
ステップ（１１０６）に関して述べると、特定の下流サーバーから受け取った通信プロトコルの統計情報（例えば、統計情報を含むフィードバック・メッセージ）の数に関するカウントを増加させる（例えば０から１へ、１から２へ等）ように、１以上のカウンター（１００２）を増加させる。幾つかの実施形態において、通信プロトコルの統計情報の数に基づいて、サーバー・ノード（９０６）はカウンター（１０１２Ａ，１０１２Ｂ，及び１０１２Ｃ）を直線的に増加させる（例えば、サーバー・ノード（９０６）は、各通信プロトコルの統計情報に対して、整数ｘだけ増加させることができる）。例えば、図１０に示すように、サーバー・ノード（９０６）は、カウンター（１０１２Ａ，１０１２Ｂ，及び１０１２Ｃ）を１だけ（即ち０から１へ）増加させる。幾つかの実施形態において、サーバー・ノード（９０６）は、１を超える数（例えば、２、３等）だけ、１以上のカウンターを増加させることもできる。１を超える数については、以下のものに基づいて決定することができる：サーバー・ノード（９０６）が監視している統計情報；ある期間下流サーバー（９０４）から受け取る統計情報（例えば、５分間の時間枠で受け取った統計情報）；ソースから下流サーバーへの伝送の種類（例えば、ソースが行うコールの種類に基づく）（ここで、高優先度のコール／セッションは、通常のコール／セッションよりも重み付けを低くすることができ、従って、高優先度のコール／セッションは成功率が高くなる）；及び／又は、複数の期間に下流サーバー（９０４）から受け取る統計情報（例えば、所定の５分の時間枠内で、３日間連続で受け取る統計情報）。幾つかの実施形態において、サーバー・ノード（９０６）は、非直線的な関数に基づいて、カウンター（１０１２Ａ，１０１２Ｂ，及び１０１２Ｃ）を増加させる（例えば、増加値ｘは、ＳＩＰ ５０３ （Ｓｅｒｖｉｃｅ Ｕｎａｖａｉｌａｂｌｅ）応答におけるＲｅｔｒｙ−Ａｆｔｅｒパラメーター、コール／拒否応答中に戻される過負荷レベルの値に基づくことができる）。
【００９５】
ステップ（１１０８）に関して述べると、サーバー・ノード（９０６）は、ネットワーク（例えば図９のネットワーク（９００））中の１以上の下流サーバーから受け取った下流サーバーに関する通信プロトコル統計情報の数を決定する。一実施形態において、サーバー・ノードは、ブルーム・フィルター中に保存する通信プロトコル統計情報のカウント（又は計算）に基づいて、各下流サーバーに関する受け取った通信プロトコル統計情報の数を決定する。ブルーム・フィルター中にキーが設定されているかどうかをテスト（ＴＥＳＴ）するために、Ｎ個のハッシュ関数を用いた挿入の間に、キーに関してＮ個のハッシュ値を計算する。ベクトル中の対応するＮ個のビット・ポジション全てが設定されている場合には、キーはブルーム・フィルター中に存在するといえる。例えば、図１０を参照すると、ＴＥＳＴ（ｘ1）（１０１４）操作は、所与のキーｘ1が、ブルーム・フィルター（１０００）に関するカウンター配列（１００４）に以前挿入されているかどうかを見るためにテストする。ハッシュ関数Ｈａｓｈ1〜Ｈａｓｈ3は、カウンター（１０１４Ａ〜１０１４Ｃ）をそれぞれ同定する。カウンター（１０１４Ａ〜１０１４Ｃ）は、ＩＮＳＥＲＴ（ｘ1）（１０１０）の際に同定された同一のカウンターに対応している。なぜなら、ハッシュ関数は、特定のキー（この場合はｘ1）に対しては同じ値を生成するからである。従って、ブルーム・フィルター（１０００）は、各カウンター（１０１４Ａ〜１０１４Ｃ）における値が１に設定されていることを決定し、キーｘ1がブルーム・フィルター（１０００）に存在し、１の値を持っていることを表す（例えば、カウンティング・ブルーム・フィルター（１０００）に関しては、キーｘ1はブルーム・フィルター（１０００）に一度挿入され、通信プロトコル統計情報がキーｘ1に関して一度観察されたことを示す）。例えば、もし、ｘ1が１５回挿入された場合には、カウンター（１０１４Ａ〜１０１４Ｃ）は「１」の代わりに「１５」になるであろう。
【００９６】
ステップ（１１１０）に関して述べると、サーバー・ノード（９０６）による所定の基準は、例えば、閾値（例えば、「２５」というカウント値）であってもよい。そして、過負荷エピソードがあることを決定するこが、値が閾値を超えることを決定することを含む。幾つかの実施形態において、所定の基準はヒステレシスを用いて掲載される（例えば、現在の値と以前の値の履歴との両方に基づいて）。例えば、コントロール理論において、ヒステレシスは、幾つかの目標値（例えばＸ）にシステムの出力を維持するために使用することができる。以下のように２つの閾値を定義することができる：（１）低い方の閾値をＸ−Δ、及び（２）高いほうの閾値をＸ＋Δ。この場合、コントロールは、システムの状態が連続する数のサンプルに関して、高いほうの閾値（即ち、Ｘ＋Δ）を超えたときに可能となる。一方で、システムの状態が、連続する数のサンプルに関して、低い方の閾値（即ち、Ｘ−Δ）を下回ったときには不能になる。こうしたことにより、オン・オフ状態をバタバタと切り替わることを防止できる点で有利である。
【００９７】
例えば、ステップ（１１１０）に関して述べると、サーバー・ノード（９０６）による所定の基準は、例えば、低い方の閾値及び高い方の閾値によって定義される閾値であってもよい（例えば、カウント値「２３」と「２５」）。そして、過負荷エピソードが存在することを決定することには、値が閾値を超えることを決定することが含まれる。任意の時間のポイントにおいて、システム状態が高い方と低い方の閾値の間にある場合には、システムは、以前の値の履歴を見ることなく過負荷エピソード（例えばコントロール状態；オン／オフ）があるかどうかの決定をすることができない。
【００９８】
幾つかの実施形態において、ブルーム・フィルターは、サーバー・ノード・基盤ごとに管理される（例えば、サーバー・ノードごとに１つのブルーム・フィルター）。各ブルーム・フィルターに関するカウンターは、上述したように各サーバー・ノードにおいて、及び／又は集合レベルで集計される。例えば、ブルーム・フィルターは、周期的に集計することができ（例えば、コンピューテーション・ノード（９１２）が３０秒ごとに１度）、広範な範囲（例えば、サーバー・ノード基盤ごとではなく、サーバー・ノード・ワイド又はネットワーク・ワイド）にわたる通信プロトコル統計情報を計算することができる（例えば、セッション拒否分散カウント）。幾つかの実施形態において、サーバー・ノード（９０６）及び／又はコンピューテーション・ノード（９１２）は、統計的な手法を用いて過負荷エピソードを検出することができる。例えば、ホルト・ウィンターズ法を使用することができる。ホルト・ウィンターズ法は、タイム・シリーズの複数の指数加重移動平均（ｍｕｌｔｉｐｌｅ ｅｘｐｏｎｅｎｔｉａｌｌｙ ｗｅｉｇｈｔｅｄ ｍｏｖｉｎｇ ａｖｅｒａｇｅｓ）を利用する例外検出アルゴリズムである。ホルト・ウィンターズ法は、例えば、データ・シリーズにおいて、単一のシーズン・バリエーション（ｓｉｎｇｌｅ ｓｅａｓｏｎａｌ ｖａｒｉａｔｉｏｎ）（例えば、遠距離通信ネットワークにおいて典型的なトラフィック量における日中のバリエーション（例えば、毎日発生する変動））を組み込むことができる。ホルト・ウィンターズ法は、データ・シリーズの平均を追跡するために、そして、許容可能な値範囲、シーズン・バリエーションを組み込む所与のユーザー特定モデルを予想するために使用することができる。もし、データ値が予想された許容値の範囲外になった場合には、例外（ａｎｏｍａｌｙ）が宣言される。
【００９９】
更にステップ（１１１０）に関して述べると、一旦過負荷エピソードが特定の下流サーバーに関して検出されると、適切な情報がステップ（１１１２）の同定フェーズに渡される。こうした情報としては、例えば、ネットワーク中に過負荷エピソードが存在することを表すものであったり、過負荷のかかった下流サーバーのカウンター（例えば、ビット又は整数）がマークされたブルーム・フィルターを含むことができる。幾つかの例において、同定フェーズに渡されたブルーム・フィルターは、通信プロトコル統計情報の追跡を継続するために使用されるブルーム・フィルターと同じであってもよい。
【０１００】
更にステップ（１１１０）に関して述べると、例えば、通信帯域だけでなくコンピューテーションの観点から効果的な態様で検出を行うことが有利である。ブルーム・フィルターの使用によって、検出を行うための極端に効果的な方法が提供されるという点で有利である。図１２Ａは、本発明の例示的な実施形態に従って、ネットワーク中の集中したサーバー過負荷を検出するためのカウンティング・ブルーム・フィルター（例えば特定のサーバー・ノードに関するブルーム・フィルター）に関するチャート（１２００）を概念的に示したものである。チャート（１２００）は、特定のカウンターに関するカウントを表す縦軸に沿った値（１２０２）（例えば、図１０のカウンター配列（１００４）のカウンターに関するもの）を含む。また、チャート（１２００）は、カウンター配列内の各カウンタのポジションを表す横軸に沿ったカウンター・インデックス（１２０４）（例えば、第一カウンター、第二カウンター等）を含む。また、チャート（１２００）は、特定のカウンター・インデックス（１２０４）に関する値（１２０２）を表すグラフ化された線（１２０６）を含む。チャート（１２００）は、ブルーム・フィルター中に保存された情報を視覚的に表しており、集中したサーバー過負荷を検出するのに使用される。例えば、ピーク（１２０８）は、インデックス部位が１９であるカウンターに関する値（約３２０）を示している。ブルーム・フィルターは、カウンター・インデックスにおける情報を特定のキー値（例えば下流サーバー名称）に割り当てている。例えば、インデックス部位１９に割り当てられた下流サーバーは、値３２０と関連付けられている（例えば、チャート（１２００）に関連付けられたブルーム・フィルターを保存するデバイス（例えば、サーバー・ノード（９０６））へ下流サーバーから送られた３２０のセッション拒否が存在する）。
【０１０１】
図１２Ｂは、本発明の例示的な実施形態に従って、ネットワーク中の集中したサーバー過負荷を検出するための、集合カウンティング・ブルーム・フィルター（例えば、図１２Ａに示したもの等の複数のサーバー・ノードに広がる複数のブルーム・フィルターの集計値を表すブルーム・フィルター）に関するチャート（１２３０）を概念的に表したものである。チャート（１２３０）は、複数のブルーム・フィルターにまたがる特定のカウンターに関するカウントを表す縦軸に沿った値（１２３２）を含む（例えば、特定のカウンター・インデックスに関する各カウンター配列のカウンター値の合計）。また、チャート（１２３０）は、複数の集合ブルーム・フィルター内の各カウンターのポジションを表す横軸に沿ったブルーム・フィルター・インデックス（１２３４）を含む（例えば、各ブルーム・フィルターに関する第一カウンター、第二カウンター等）。また、チャート（１２３０）は、特定のブルーム・フィルター・インデックス（１２３４）に関する値（１２３２）を表示するグラフ化された線（１２３６）を含む。チャート（１２３０）は、複数の集合ブルーム・フィルターにまたがって保存される情報を視覚的に表しており、集中しているサーバー過負荷を検出するために使用される。 例えば、ピーク（１２３８）は、ネットワークのブルームフィルター全てを一旦集合させると、図１２Ａのインデックス部位１９でのカウンターに関する値（約３２０）が、約１５１００まで上昇することを示している。ノード（例えばコンピューテーション・ノード（９１２））は、集合ブルーム・フィルターに関するカウンター・インデックスにおける情報を特定のキー値（例えばサーバー名称）に割り当てる。例えば、インデックス部位１９に割り当てられた下流サーバーは、値１５１００に関連付けられる（例えば、チャート（１２３０）において値を集合させたブルーム・フィルターが保存されているデバイスへ下流サーバーから伝送された１５１００のセッション拒否が存在する）。
【０１０２】
図１２Ｃは、本発明の例示的な実施形態に従って、ネットワーク中の集中したサーバー過負荷を検出するための集合させたコール数分布に関するチャート（１２６０）を概念的に表したものである。チャート（１２６０）は、各コール数インデックス（１２６４）（例えば、遠距離通信プロトコルにおいてコールされた各数）に関するコールの数（１２６２）をグラフ化したヒストグラムである。数学的な操作を通して、図１２Ｂの集合ブルーム・フィルターを、チャート（１２６０）に示したネットワーク・ワイド通信プロトコル統計情報ヒストグラム（例えばセッション拒否ヒストグラム）を計算するために使用することができる。サーバー・ノード（９０６）及び／又はコンピューテーション・ノード（９１２）は、特定の下流サーバーに対する通信プロトコル統計情報の頻度を決定するために、チャート（１２６０）を使用することができる。例えば、コンピューテーション・ノード（９１２）は、ソース（９０２）から特定の目的地数へのセッション拒否の数（又は値）を決定するためにチャート（１２６０）を使用することができる。ここで目的地数は下流サーバー（９０４）を通して到達する。そして、例外検出技術は、上述したようにこうしたチャート（又はヒストグラム）（１２６０）に適用され、過負荷エピソードが存在するかどうかについて決定する。
【０１０３】
ステップ（１１１２）について述べると、ステップ（１１１０）で検出される任意の過負荷エピソードを引き起こす伝送のソースは、フィードバック・メッセージを受け取ることに基づいて検出することができる。例えば、あるサーバー・ノードでのブルーム・フィルターは、目的地基盤（例えば下流サーバー目的地に基づく）に関する通信プロトコル統計情報を管理することができる。遠距離通信ネットワークに関して、例えば、セッション要求を受け取った場合、目的地は、上述したようにブルーム・フィルターへのキーとして使用することができる。目的地キーに関するＴＥＳＴは、目的地が現在過負荷がかかっているかどうかについて決定することができ、要求のソース（例えば、複数のクライアント（１２０）の１つ）を過負荷エピソードに関するコンジェスション（渋滞）のソースとして特定するであろう。
【０１０４】
ステップ（１１１４）に関して述べると、コントロール動作により、下流サーバー（例えば下流サーバー（９０４））に対して過負荷エピソードを引き起こす原因となっている１以上のソース（例えばソース（９０２））からのデータの伝送速度を減少させる。図１３は、本発明の例示的な実施形態に従った、ネットワーク中の集中したサーバー過負荷を制限するための１以上のコントロール・パラメータを決定する（例えば、図１１のステップ（１１１４）における１以上のコントロールパラメータを決定することを目的とする）ための方法（１３００）を表すフローチャートである。ステップ（１３０２）において、コンピューテーション・ノード（９１２）（又はサーバー・ノード（９０６））は、サーバー・ノード又は他のネットワーク要素がコントロール動作を受ける場所を特定する動作位置を決定する。ステップ（１３０４）では、コンピューテーション・ノード（９１２）は、動作位置においてコントロール動作を適用すべき１以上のソースを定義する動作フィルターを決定する。ステップ（１３０６）では、コンピューテーション・ノード（９１２）は、コントロール動作に関する動作レベルを（例えばヒステレシスを用いて）決定する。ステップ（１３０８）では、コンピューテーション・ノード（９１２）は、動作位置に１以上のコントロール・パラメータを配信する。
【０１０５】
ステップ（１３０２）に関して述べると、動作位置の値は、以下のいずれかであってもよい：ワイルドカード（例えば、コントロール・パラメータが全てのサーバー・ノードにおいてネットワークワイドに適用される）；又は、特定のサーバー・ノード（例えばネットワーク・スイッチ）、通信グループ（例えば、基幹グループ）等を特定する特定の組（ｔｕｐｌｅ）。動作位置の選定は、所定のアプリオリであるポリシー・レベルの決定であってよい。例えば、動作位置は、コントロール・パラメータが全てのソースにおける動作に適用されるように決定することができる（例えば、侵入（ｉｎｇｒｅｓｓ）ノード）。別の例として、遠距離通信ネットワークに関して、同定された目的地数にマッチする入ってくる基幹グループに関するコールは、入ってくる基幹グループからのコールを受け取るサーバー・ノードによって制限される速度であってよい。
【０１０６】
ステップ（１３０４）に関して述べると、動作フィルターは過負荷エピソードを引き起こす原因となる同定されたソースに基づいて計算することができる。ステップ（１３０６）に関して述べると、動作レベルは、複数のアルゴリズムを用いて計算することができる。図１４Ａ及び１４Ｂは、本発明の例示的な実施形態に従って、ネットワーク中の集中したサーバー過負荷を制限するための動作レベルを決定するための方法を表すフローチャートである。図１４Ａは、動作レベルを決定するための方法（１４００）を表す。ステップ（１４０２）では、コンピューテーション・ノード（９１２）（又はサーバー・ノード（９０６））は、値が所定の閾値を超えるかどうかを決定する。もし、値が所定の閾値を超える場合には、方法はステップ（１４０４）へと進み、コンピューテーション・ノード（９１２）が、減少因子を用いて以前の動作レベルから動作レベルを減少させるように決定する。もし、値が所定の閾値を下回る場合には、方法はステップ（１４０６）へと進み、コンピューテーション・ノード（９１２）が、増加ステップを用いて以前の動作レベルから動作レベルを増加させるように決定する。
【０１０７】
ステップ（１４０２〜１４０６）に関して述べると、方法は以下のような式を使用することができる：
while True: (12)
if VALUE > θ:
ACTION_LEVEL[k+1] = ACTION_LEVEL[k] × β
else:
ACTION_LEVEL[k+1] = ACTION_LEVEL[k] − step
k = k + 1
sleep T,
ここで：
VALUE = 現在の通信プロトコル統計情報に関する値（例えば、セッション拒否カウント）；
β = 許容されたインター・コール・ギャップ時間における倍数増加値（β> 1 (例えば1.1)）;
step =許容されたインター・コール・ギャップ時間における更なる減少値（単位はｍｓ、例えば10 ms）;
θ = コントロール・シグナル目標値(例えば、閾値）;
T = 周期的な動作計算間隔;
ACTION_LEVEL[k] = k番目の間隔での動作レベル(例えば、インター・コール・ギャップ・時間が50 ms)であり、その範囲が最大値及び最小値で規定することができる（例えば最小値が40 ms 及び最大値が60 ms）。
【０１０８】
ステップ（１４０２）に関して、Ｔ秒ごとに、新たな動作レベルをシータ（θ）に基づいて計算される。最初のACTION_LEVEL[k]には、例えば、初期値を設定する
（例えば、ｍｓ単位のコール・ギャップ、例えば１０ｍｓ等）。コンピューテーション・ノード（９１２）（又は、サーバー・ノード（９０６））は、VALUEがθを超えるかどうかを決定する。ステップ（１４０４）に関して、もし、VALUEがθを超える場合には、コンピューテーション・ノード（９１２）は、コール・ギャップにおける倍数増加（許容要求速度に対する減少である）を計算する。具体的には、式（１２）に関して述べると、ACTION_LEVEL[k+1]は、k番目の間隔での現在の動作レベルであるが、以前の動作レベルACTION_LEVEL[k]に対する倍数増加として計算される。ステップ（１４０６）に関して、もしVALUEがθ以下の場合には、コンピューテーション・ノード（９１２）は、コール・ギャップにおける更なる減少値（許容要求速度に対する増加である）を計算する。具体的には、式（１２）に関して述べると、ACTION_LEVEL[k+1]は、以前の動作レベルACTION_LEVEL[k]に対する更なる増加として計算される。有利な点として、式（１２）は容易に設計され、プロセッサ（例えばサーバー・ノード（９０６）のプロセッサ（９０８））上で素早く実行される。
【０１０９】
図１４Ｂは、動作レベルを決定するための方法（１４５０）を表すフローチャートである。ステップ（１４５２）では、コンピューテーション・ノード（９１２）は、値が所定の目標値と等しいかどうかを決定する。もし、値が所定の目標値と等しい場合には、方法はステップ（１４５４）に進み、コンピューテーション・ノード（９１２）は動作レベルの変更を行わない。もし、値が所定の目標値と等しくない場合には、方法はステップ（１４５６）に進み、コンピューテーション・ノード（９１２）は、以前の動作レベル、並びに値及び所定の目標値の差に基づいて動作レベルを決定する。
【０１１０】
ステップ（９１２〜９１４）に関して、方法は以下の式を使用することができる：
while True: (13)
if ABSOLUTE(VALUE − θ) > Δ:
ACTION_LEVEL[k+1] = ACTION_LEVEL[k] +γ× (VALUE -θ)
else:
ACTION_LEVEL[k+1] = ACTION_LEVEL[k]
k = k + 1
sleep T,
ここで：
Δ = 過負荷シグナルに対する目標値からの偏差に関する所定の閾値;
VALUE = 現在の通信プロトコル統計情報に関する値(例えばセッション拒否カウント）;
γ =コンジェスション中コール・ギャップがどれだけ急速に増加するかについてコントロールする比例利得定数（proportional gain constant）(例えば、001);
θ =コントロール・シグナル目標値;
T = 周期的な動作計算間隔;及び
ACTION_LEVEL[k] = k番目の間隔での動作レベル(例えば、インター・コール・ギャップ・時間が50 ms)。
【０１１１】
ステップ（１４５２）に関して、Ｔ秒ごとに、新たなACTION_LEVELをVALUEに基づいて計算する。コンピューテーション・ノード（９１２）は、VALUE−θの絶対値がΔを超えるかどうかを決定する。ステップ（１４５４）に関して、ABSOLUTE(VALUE −θ)がΔの場合（即ち値がθと等しい場合）、コンピューテーション・ノード（９１２）は動作レベルを変更しない。ステップ（１４５６）に関して、もし、ABSOLUTE(VALUE − θ)がΔを超える場合（即ち、VALUEがθと等しくない場合）、コンピューテーション・ノード（９１２）が、以前の動作レベルACTION_LEVEL[k]に基づいて、比例アルゴリズムを用いて動作レベルACTION_LEVEL[k+1]を決定する（例えば、コントロールシグナルVALUEと所望のレベルθとの差分に比例するコール・ギャップを増加させる等）。有利な点として、式（１３）は、振動動作するような結果にはならない。なぜなら、式（１３）は、コントロール理論概念を使用して（例えば、比例アルゴリズムを用いて）、目標ポイントθへより早く収束するようにしているからである。
【０１１２】
ステップ（１３０８）に関して述べると、コンピューテーション・ノード（９１２）は、過負荷エピソードを軽減するために、１以上のコントロール・パラメータを動作位置に配信することができる。例えば、サーバー・ノード（９０６）及び／又はコンピューテーション・ノード（９１２）は、過負荷エピソードの原因となるソースと下流サーバーとの間のサーバー・ノードに、１以上のコントロール・パラメータを送る。サーバー・ノードは、ソースから下流サーバーへ伝送されるデータに関する伝送速度（例えば、過負荷エピソードの原因となる１以上のソースから下流サーバーへのコール試行速度）を減少させることにより、サーバー・ノードでの該データに関するコントロール動作を実行する。ここで前記減少は１以上のコントロール・パラメータに基づいて実行される。
【０１１３】
例えば、検出され、及び（例えばコンピューテーション・ノード（９１２）により）同定された目的地であって、過負荷がかかった目的地（例えば、下流サーバー（９０４）又はコールされた目的地の電話番号等の下流サーバー（９０４）を介して到達可能な目的地）が与えられた場合は、セッション・ギャッピングを使用して、過負荷のかかった目的地へのセッション要求（例えばクライアント（１２０）からの要求）間に最小限の時間制限を適用することができる。セッション・ギャッピングは、過負荷のかかった目的地へのセッション要求の入ってくる速度を制限するために使用することができる。例えば、コンピューテーション・ノード（９１２）は、コントロール・パラメータを配信して、クライアント（１２０）から受け取ったセッション要求に対して、セッション・ギャッピング（コントロール動作）をソース（９０２）（例えば、ネットワークの侵入ノード）で実行することができる。コントロール動作は、過負荷のかかった目的地に対して、提供されたセッション要求速度をコントロールし、（拒否されるであろう）セッションがネットワークに入って、ネットワーク・リソースを使用することを防止する。過負荷がかかった目的地に対するコール間の最小限の時間間隔は、例えば、図１４Ａ及び図１４Ｂを参照しながら述べたACTION_LEVELとして計算することができる。このACTION_LEVELは、（例えば、マス・コーリング・イベント等の予想できないイベントに基づいて）目的地での過負荷の度合いが変化するにつれて変化することができる。
【０１１４】
図１５は、本発明の例示的な実施形態に従って、ネットワーク中の集中したサーバー過負荷を制限するための方法（１５００）を表したフローチャートである。ステップ（１５０２）では、コンピューテーション・ノード（９１２）は、ブルーム・フィルターに基づくマルチ・レベルな閾値を動作位置（例えばサーバー・ノード（９０６）に配信する。ブルーム・フィルターに基づくマルチ・レベルな閾値は複数の閾値を保存する。ここで、各複数の閾値は、通信プロトコルに関するコール・リクエストに関連する複数の分類からの１つのクラスに対応する。また、ブルーム・フィルターに基づくマルチ・レベルな閾値は、各複数の分類に関する下流サーバー（例えば、下流サーバー（９０４））へのコール・リクエストのカウントを、１以上のハッシュ関数を持ちいて保存する。ステップ（１５０４）では、動作位置は、ソースから下流サーバーへのコール・リクエスト・メッセージを受け取る。ここで、コール・リクエスト・メッセージは、複数の分類のうち一つの分類を含む。ステップ（１５０６）では、動作位置は、ブルーム・フィルターに基づくマルチ・レベルな閾値を用いて、以下について決定をする：（１）コール・リクエスト・メッセージにおける分類に関する閾値；及び（２）１以上のハッシュ関数を用いたブルーム・フィルターに基づく、コール・リクエスト・メッセージにおける分類に関する下流サーバーへのコール・リクエストのカウント。ステップ（１５０８）では、動作位置は、コール・リクエストのカウントが閾値を超えるかどうかを決定する。もし、コール・リクエストのカウントが閾値を超えている場合には、方法はステップ（１５１０）へ進み、動作位置はコール・リクエスト・メッセージを拒否する。コール・リクエストのカウントが閾値未満の場合には、方法はステップ（１５１２）へ進み、動作位置は、コール・リクエスト・メッセージを受け入れる。
【０１１５】
ステップ（１５０２）を参照すると、ブルーム・フィルターに基づくマルチ・レベルな閾値を、Ｍ個の分類のコール・リクエストを扱うために使用する（例えば、上述したような低、中、及び高優先度要求）。各分類は、伝送（例えば、クライアント（１２０）から下流サーバー（９０４）へ）が現状のネットワーク条件（例えば、過負荷エピソードがあるかどうか、又は下流サーバー（９０４）と関連するかどうか）の下で受け入れられる可能性を決定する関連優先度を有する。ブルーム・フィルターに基づくマルチ・レベルな閾値はＭ個の閾値を管理し、Ｍ個の分類の１分類につき１つずつ管理する。例えば、遠距離通信ネットワークに関するステップ（１５０４〜１５１２）を参照を参照すると、クライアント（１２０）から目的地へのコール・リクエストがソース（９０２）（例えば、侵入ノード）に入ったとき、ブルーム・フィルターに基づくマルチ・レベルな閾値によって追跡される現在のコンジェスション・レベル（目的地へのコール・リクエストのカウント）が、コール・リクエストに対応する分類に関する閾値と比較される。もし、コンジェスション・レベルが、コール・リクエスト閾値を超える場合には、コールは拒否される。そうでない場合にはコールは受け入れられる。
【０１１６】
上述した技術は、デジタル及び／又はアナログ電子回路や、コンピュータ・ハードウェア、ファームウェア、ソフトウェア、又はこれらの組合せにおいて実装することができる。こうした実装は、コンピュータ・プログラム製品として行うことができる。即ち、データ処理装置（例えば、プログラム可能なプロセッサ、コンピュータ、及び／又は複数のコンピュータ）での動作によって実行、又はコントロールするための機械読取可能ストレージデバイスで実際に実行されるコンピュータ・プログラムである。コンピュータ・プログラムは、任意の形態のコンピュータ言語又はプログラム言語で記載することができ、これらにはソース・コード、コンパイラ・コード、インタプリタ・コード、及び／又は機械コードが含まれる。そして、コンピュータ・プログラムは、任意の形態で配置することができ、該形態としては、スタンド・アロンなプログラム若しくはサブルーチン、要素、又はコンピューティング環境での使用に適した他のユニット等が含まれる。コンピュータ・プログラムは、１以上のサイトでの１つのコンピュータ又は複数のコンピュータで実行するために配置することができる。
【０１１７】
方法のステップは、コンピュータ・プログラムを実行する１以上のプロセッサによって実行される。そして、入力データに関して操作したり、及び／又は出力データを生成したりすることによって本発明の機能を実践する。また、方法のステップは、特定目的の論理回路（例えば、ＦＰＧＡ（ｆｉｅｌｄ ｐｒｏｇｒａｍｍａｂｌｅ ｇａｔｅ ａｒｒａｙ）、ＦＰＡＡ（ｆｉｅｌｄ−ｐｒｏｇｒａｍｍａｂｌｅ ａｎａｌｏｇ ａｒｒａｙ）、ＣＰＬＤ（ｃｏｍｐｌｅｘ ｐｒｏｇｒａｍｍａｂｌｅ ｌｏｇｉｃ ｄｅｖｉｃｅ）、ＰＳｏＣ（Ｐｒｏｇｒａｍｍａｂｌｅ ｓｙｓｔｅｍ−ｏｎ−Ｃｈｉｐ）、ＡＳＩＰ（ａｐｐｌｉｃａｔｉｏｎ−ｓｐｅｃｉｆｉｃ ｉｎｓｔｒｕｃｔｉｏｎ−ｓｅｔ ｐｒｏｃｅｓｓｏｒ）、又はＡＳＩＣ（ａｐｐｌｉｃａｔｉｏｎ−ｓｐｅｃｉｆｉｃ ｉｎｔｅｇｒａｔｅｄ ｃｉｒｃｕｉｔ）等）によって実行することができ、そして装置は該回路として実装することができる。サブルーチンは、保存されたコンピュータ・プログラムの一部を参照することができ、並びに／又は１以上の関数を実行することができるプロセッサ及び／若しくは特殊回路を参照することができる。
【０１１８】
コンピュータ・プログラムの実行に適したプロセッサとしては、例示的な意味で汎用目的のマイクロプロセッサ及び特殊目的のマイクロプロセッサの両方、並びに任意の種類のデジタル又はアナログコンピュータにおける１以上の任意のプロセッサが含まれる。一般的に、プロセッサは、ＲＯＭ、ＲＡＭ、又はその両方から指示やデータを受け取る。コンピュータの本質的な要素は、指示を実行するためのプロセッサ、並びに指示及び／又はデータを保存するための１以上のメモリ・デバイスである。キャッシュ等のメモリ・デバイスは、一時的にデータを保存するために使用することができる。また、メモリ・デバイスは長期間のデータ保存目的で使用することもできる。また、一般的に、コンピュータは、それらからデータを受け取ったり、又はそれらへデータを送ったり、又はその両方を目的として、データ保存用の１以上のマス・ストレージデバイス（例えば、磁気媒体、光磁気ディスク、又は光ディスク等）を含む、又は動作上連結している。また、ネットワークから指示及び／若しくはデータを受け取ったり、並びに／又はネットワークへ指示及び／若しくはデータを送ったりすることを目的として、コンピュータは動作上通信ネットワークと連結している。コンピュータ・プログラムの指示及びデータを実行することに適したコンピュータ読取可能保存媒体としては以下の物が含まれる：あらゆる形態の揮発性及び不揮発性メモリ（例示的な意味として、半導体メモリ・デバイス、例えば、ＤＲＡＭ、ＳＲＡＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ及びフラッシュ・メモリ・デバイス）；磁気ディスク（例えば、内部のハードディスク、又はリムーバブル・ディスク）；光磁気ディスク；及び光ディスク（ＣＤ、ＤＶＤ、ＨＤ−ＤＶＤ及びＢｌｕ−ｒａｙ）。プロセッサ及びメモリは、特殊目的の論理回路によって補足したり及び／又は該回路中に組み込むことができる。
【０１１９】
ユーザーとの相互作用を提供するために、上述した技術を、ユーザーに情報を表示するための表示装置（例としては、ＣＲＴ（ｃａｔｈｏｄｅ ｒａｙ ｔｕｂｅ）、プラズマ、又はＬＣＤ（液晶ディスプレイモニター））や、キーボード及びポインティング・デバイス（例えば、マウス、トラックボール、タッチパッド、モーション・センサー）（これらによって、ユーサーはコンピュータに入力を行うことができる（例えば、ユーザー・インターフェース要素と相互作用する））と通信するコンピュータ上で実行することができる。同様にユーザとの相互作用を提供する目的で他の種類のデバイスを使用することができる；例えば、ユーザーに提供するフィードバックとしては、任意の形態の感覚的フィードバック（例えば、視覚的フィードバック、聴覚的フィードバック、及び触覚的フィードバック）の形態であってもよい。そして、ユーザーからの入力については、音響、スピーチ、及び／又は触覚的な入力を含む任意の形態で受け取ることができる。
【０１２０】
上述した技術は、バック・エンド・コンポーネントを含む分散コンピューティング・システムにおいて実行することができる。バック・エンド・コンポーネントとしては、例えば、データ・サーバー、ミドルウェア・コンポーネント、及び／又はアプリケーション・サーバー等であってもよい。上述した技術は、フロント・エンド・コンポーネントを含む分散コンピューティング・システムにおいて実行することができる。フロント・エンド・コンポーネントとしては、例えば、ＧＵＩ、ユーザーが例示的な実装形態と相互作用することができるウェブ・ブラウザ、及び／又は伝送デバイス用の他のＧＵＩを有するクライアント・コンピュータであってもよい。上述した技術は、前述のバック・エンド、ミドルウェア、又はフロント・エンド・コンポーネントの任意の組合せを含む分散コンピューティング・システムにおいて実行することができる。
【０１２１】
コンピューティング・システムのコンポーネントは、伝送媒体（１１０）によって相互接続することができ、該媒体はデジタル又はアナログデータ通信に関する任意の形態又は媒体を含むことができる（例えば、通信ネットワーク）。伝送媒体（１１０）は、任意の設計において、１以上のパケット・ベースのネットワーク及び／又は１以上の回路・ベースのネットワークを含むことができる。パケット・ベースのネットワークとしては、以下のものを含むことができる：例えば、インターネット、キャリア・インターネット・プロトコル（ＩＰ）ネットワーク（例えば、ローカル・エリア・ネットワーク（ＬＡＮ）、ワイド・エリア・ネットワーク（ＷＡＮ）、キャンパス・エリア・ネットワーク（ＣＡＮ）、メトロポリタン・エリア・ネットワーク（ＭＡＮ），ホーム・エリア・ネットワーク（ＨＡＮ））、プライベートＩＰネットワーク、ＩＰ構内交換機（ＩＰ ｐｒｉｖａｔｅ ｂｒａｎｃｈ ｅｘｃｈａｎｇｅ （ＩＰＢＸ））、ワイヤレス・ネットワーク（例えば、ラジオ・アクセス・ネットワーク（ＲＡＮ）、Ｂｌｕｅｔｏｏｔｈ（登録商標）、Ｗｉ−Ｆｉ（登録商標）、ＷｉＭａｘ（登録商標）、ＧＰＲＳ（ｇｅｎｅｒａｌ ｐａｃｋｅｔ ｒａｄｉｏ ｓｅｒｖｉｃｅ）、ＨｉｐｅｒＬＡＮ）及び／又は他のパケット・ベースのネットワーク。回路ベースのネットワークとしては、例えば以下のものを含むことができる：公衆電話交換回線網（ＰＳＴＮ）、レガシーＰＢＸ、ワイヤレス・ネットワーク（例えば、ＲＡＮ、ＣＤＭＡ（符号分割多重接続）ネットワーク、ＴＤＭＡ（時分割多重接続）ネットワーク、ＧＳＭ（登録商標）ネットワーク）、及び／又は他の回路ベース・ネットワーク。
【０１２２】
伝送媒体（１１０）を介した情報伝達は、１以上の通信プロトコルに基づくことができる。通信プロトコルとしては、例えば以下のものを含めることができる：Ｅｔｈｅｒｎｅｔ（登録商標）プロトコル、インターネット・プロトコル（ＩＰ）、ボイップ（Ｖｏｉｃｅ ｏｖｅｒ ＩＰ （ＶｏＩＰ））、ピア・ツー・ピア・プロトコル（Ｐ２Ｐ）、ハイパーテキスト・ドランスファー・プロトコル (HTTP)、セッション確立プロトコル(SIP)、Ｈ．３２３、メディア・ゲートウェイ・コントロール・プロトコル（ＭＧＣＰ）、シグナリング・システム＃７（ＳＳ７）、ＧＳＭ（登録商標）プロトコル、プッシュ・ツー・トーク（ＰＴＴ）プロトコル、プッシュ・ツー・トーク・オーバー・セルラー（ＰＯＣ）プロトコル、及び／又は他の通信プロトコル。
【０１２３】
コンピューティング・システムの装置としては、例えば以下のものを含めることができる：コンピュータ、ブラウザ・デバイスを備えるコンピュータ、電話、ＩＰ電話、モバイル装置（例えば、携帯電話、ＰＤＡ、ラップトップ・コンピュータ、電子メール装置）、及び／又は他の通信装置。ブラウザ・デバイスとしては、例えば、ＷＷＷブラウザ（例えば、マイクロソフト（登録商標）社が提供しているMicrosoft Internet Explorer（登録商標）、Mozilla社から入手できる Mozilla（登録商標） Firefox）を備えるコンピュータが含まれる。モバイル・コンピューティング・デバイスとしては、例えば、Blackberry（登録商標）を含むことができる。ＩＰ電話としては、シスコシステムから入手できるCisco（登録商標）Unified IP Phone 7985Gや、Cisco Unified Wireless Phone 7920が含まれる。
【０１２４】
本発明の思想及び本質的な特性から乖離することなく他の特的の形態で本発明を実施できることを当業者は理解するであろう。従って、本明細書で記述した本発明に関して、上記実施形態は限定的にではなく全て例示的な観点で考慮すべきものである。よって、本発明の範囲は、上述した内容によってではなく、添付した特許請求の範囲によって表される。そして、前記特許請求の範囲の意味及び均等物の範囲内に入る全ての変更は、本発明の範囲に入ることを意図する。
【技術分野】
【０００１】
本発明は、概して、ネットワーク中に集中するサーバー過負荷を検出及び軽減することを目的とするコンピュータ・プログラム製品を含めた方法及び装置に関する。
【背景技術】
【０００２】
通信サービスへの要求が増すにつれて、効果的な通信システムの重要性が増してきている。通信サービスには、電話コール設定要求の処理から、ネットワークのインターネット・プロトコル（ＩＰ）のデータ・パケットのルーティング、ウェブサイト及び／又はコンテンツを要求するハイパーテキスト・ドランスファー・プロトコル（ＨＴＴＰ）要求の処理等を含むことができる。通信システムには、クライアントからのサービス要求を処理するサーバーが一般的には含まれる。サーバーには、電話コール設定要求処理を行うための遠距離通信スイッチから、ＩＰデータ・パケットをルーティングするためのネットワーク・ルーター、ＨＴＴＰ要求を処理するためのウェブサーバー及び／又はコンテンツ・サーバー等を含むことができる。
【０００３】
時として、サービス要求（リクエスト）は、サーバーが前記要求を処理する速度よりも速い速度で前記サーバーに到達することがある。前記リクエストを処理するサーバーの速度は、以下の要素のうちの１以上が原因で変動しうる：異なる要求を処理する際のバリエーション；サーバー上で実行されるバックグラウンド動作又は管理動作；及び／又は前記サーバー中のソフトウェア若しくはハードウェアの部分的若しくは全体的な故障。通信サーバーは、典型的には過負荷制御（コントロール）を実施する。そして、高度な要求が成されている期間中、許容可能なレベルで、前記サーバーが処理を行うサービス要求のスループットを維持している。
【０００４】
過負荷が生じるのは、前記サーバーが受ける全ての要求を処理することに成功するためのサーバーのリソース（例えばＣＰＵの処理容量、メモリ、ネットワーク帯域、入力／出力、ディスク・リソース等）が不充分なときである。ある種のサーバーでは、サービス要求が高速度で入ってきたり、及び／又はネットワークが部分的に損傷することが原因となって、過負荷が継続される事態を経験する可能性がある。過負荷は、以下の要素（個々又は組合せ）によって生じうる：（１）メディアが喚起する大衆要求イベント（例えば、遠隔投票、慈善活動アピール、コンペ、マーケティング・キャンペーン等）；（２）緊急事態；（３）ネットワーク装置の故障；（４）自動スケジュール要求（例えば、雪の日にキャンセルする警告）；及び／又は（５）サービス拒否（Ｄｏｓ）攻撃。過負荷集中というものは、ネットワークのサブセットに過負荷が集中するという、ネットワーク過負荷の特殊なケースである。前記サブセットとしては、ネットワーク目的地（例えば、電話番号やＩＰアドレス等）から、ネットワーク・サーバのグループまで等が挙げられる。
【０００５】
過負荷制御がない状態では、こうした過負荷によって、通信ネットワークの安定性が脅かされる可能性がある。そして、サービス完了に成功する可能性を著しく減少させることにもなりうる。究極的には、要求が失われることが原因となって、サーバー（複数可）はサービス（複数可）を提供することに失敗する可能性があり、結果としてクライアントへサービスの非可用性へとつながる。また、過負荷問題については、これら過負荷問題自身が重なり合うことが良くあり、これによって、サーバー（複数可）に更なる負荷を引き起こす可能性がある。更に、過負荷がかかっている最中は、サーバー（複数可）の全体容量はダウンする可能性がある。なぜなら、該サーバーのリソースの多くは、サーバーが実際に処理することが出来ない負荷を拒否したり及び／又は処理したりするするのに費やされるからである。こうした深刻な過負荷の下、スループットは、元々の処理能力と比べて低い割合まで低下する可能性がある。こうした現象は、しばしば、コンジェスション・コラプス（ｃｏｎｇｅｓｔｉｏｎ ｃｏｌｌａｐｓｅ）と呼ばれる。更に言えば、過負荷によって、サービス要求が遅延したり及び／又は失われたりする傾向が生じ、これによって、クライアントの取り下げや及び／又はリトライ（ｒｅａｔｔｅｍｐｔｓ）を高速化させる可能性がある。
【０００６】
高度且つ予想不可能な要求レベルから保護することを目的とし、且つ、過負荷を処理する最中クライアントが早まってサービス要求を取り下げることを防ぐのに充分に短い応答時間を維持することを目的として、サーバーは、適応性の過負荷検出及び制御の形態を幾つか備えることができる。あるサーバーでは過負荷コントロール機構を内部に実装している。該機構では、過負荷がかかったサーバーは新たな要求を拒否して、許容セッションの完了が成功することを最大化させることができる。また、あるサーバーでは過負荷コントロール機構を外部に実装することができる。該機構では、１以上のクライアントにコントロール・メッセージを通信することによって、サービスを要求する追加要求をクライアントが送ることができる速度（例えば、要求速度についての制限を設定する等）にサーバーがコントロールすることができる。
【０００７】
しかし、サーバーが実装した、内部又は外部の機構は、「受信側ベース」のコントロール機構としても知られているが、上述したように、サーバーを過負荷から限定された度合いで保護することができるにすぎず、コンジェスション・コラプスを防止するのは困難である。特に、受信側ベース・コントロール機構は、サーバーに対して、サーバーの内部の過負荷レベルに基づいたクライアントへの制限を管理及び更新し、その後クライアントに対して過負荷フィードバック機構を介してこうした制限を配信する必要が生じる。例えば、制限には、明示的な速度メッセージ、（確認なしでサーバーに送ることができるメッセージ数を制限する）過負荷ウィンドウ・サイズ・メッセージ、及び／又はロス・パーセンテージ・メッセージ（該メッセージによりクライアント側はサーバーに向かって通常送られる要求の数を減らす）。全ての受信側ベースの概念は、配信リストを更新するために、クライアントの活動を監視する必要が生じる。配信リストについては、新たなクライアントが出現した場合に前記サーバー配信リストに新たなクライアントを追加することや、適切な時間クライアントが送信を中断している場合に既存のクライアントを削除すること等を含むことができる。こうしたことが各々必要になることにより、既に過負荷がかかっているサーバーに更に処理負荷が追加されることになってしまう。
【０００８】
更に、明示的な速度及び過負荷ウィンドウ・スキーマにおいて、過負荷がかかったサーバーは、各上流近隣から該サーバーが受け取る負荷の量を連続的に評価する。従って、適切な速度キャップ又は過負荷ウィンドウサイズを割り当て、それらについては、制限レベルを更新するために送信クライアントに対して、時間内に送り返すべきものである。ロス・パーセンテージをフィードバックする受信側ベースの概念は、過負荷のかかったサーバーにたいして同様のオーバーヘッドをかけることができない。なぜなら、同じロス・パーセンテージを全ての上流近隣に送ることが可能であり、従って、各クライアントから受け取る要求速度を追跡するための要求を落としてしまうからである。しかし、ロス・パーセンテージの概念は、効果的なコントロールを提供することができない。なぜなら、上流クライアントが、過負荷のかかったサーバー（該ロス・パーセンテージは素早く変動するが）に対する要求速度に関するロス・パーセンテージを適用するにつれて、前記過負荷のかかったサーバーに対する要求速度も素早く変動しうるからである。こうした変動があるため、過負荷のかかったサーバーには、スロットル・パーセンテージを現在の過負荷状態に素早く適応させる能力が要求される。
【０００９】
受信者ベース制御に関する別の欠点としては、該コントロールは、過負荷フィードバック機構を実装することを目的として、クライアント及びサーバー（複数可）において特定のプロトコル・スタックに対する変更を必要とする可能性がある点がある。例えば、集中過負荷を検出するために提案されたある技術は負荷フィルタリングであり、該技術においては、特定の目的地へのコールや特定のソースからのコールについては速度制限したりまたはランダムに落としたりするように指示するフィルターをネットワーク・オペレータが作成する。しかし、こうした機構では、サーバーのＳＩＰスタックが新たな過負荷イベント・パッケージを含むことが必要になる。プロトコル・スタックに対する変更は、こうした制御を適用することを遅くしてしまう可能性がある。更に、こうした機構は、過負荷イベントを予め知っていること（例えば、遠隔投票）に基づいて設計される静的な機構であり、突然の過負荷（例えば、緊急事態やネットワーク故障に関連した過負荷）に反応することについては失敗に終わるであろう。
【００１０】
集中過負荷を検出するために提案された別の技術として、特定の目的地へのコール拒否速度（例えば、コールされた数）を監視しており、前記速度が特定の閾値を超えているかどうかを監視している。そして、該目的地へ集中する可能性がある過負荷として該イベントをレポートする。前記サーバーは、該目的地へのコールに対するスロットルを開始し、同時に上流サーバーに対して該過負荷イベントを広げる。しかし、こうした検出アルゴリズムは、トークン・バケットを使用して実装され、大量のストレージを必要とする。更に言えば、こうした機構は、過負荷を検出するための明示的なコール拒否のみに依存しており、集中した過負荷イベントを検出するためにネットワーク間の配信されたモニターチームを必要とする。
【発明の概要】
【課題を解決するための手段】
【００１１】
過負荷がかかっている最中にサーバーのリソースをコントロールするためのアプローチの一つとして、クライアント・コントロールを介したサーバー過負荷制限が挙げられる。一態様において、本発明は、ネットワーク中のサーバー過負荷を制限するためのコンピュータ化された方法を特徴とする。該方法は、ネットワークのサーバー・ノードによって、下流サーバーからフィードバック・メッセージを受け取ることを含む。ここで前記フィードバック・メッセージは、通信プロトコルの統計情報を含む。前記方法は、前記フィードバック・メッセージ中に含まれる情報に基づいて１以上のハッシュ関数を用いて、コンピュータ・メモリ・モジュール中に保存された、カウンター配列からの１以上のカンウターのうちどれが下流サーバーと関連しているかを、サーバー・ノードが決定することを含む。１以上のカウンターは、下流サーバーから受け取った統計情報を含むフィードバック・メッセージの数に対応する数を保存する。前記方法は、統計情報を含むフィードバック・メッセージに応答して、１以上のカウンターをサーバー・ノードが増加させることを含む。前記方法は、１以上のカウンター中に保存された数の値を、１以上のハッシュ関数を用いて、サーバー・ノードが決定することを含む。前記方法は、前記値が所定の基準を充足するかどうかに基づいて、下流サーバーに関するネットワーク中の過負荷エピソードを前記値が表していることを、サーバー・ノードが決定することを含む。
【００１２】
別の実施形態では、前記所定の基準は閾値であり、前記決定することは、前記値が閾値を超えることを決定することを含む。前記閾値は、ヒステレシスを用いて計算することができる。過負荷エピソードを引きおこす原因となる１以上のソースを特定することができ、ここで各ソースは、下流サーバーに対して伝送を開始し、該伝送によって下流サーバーは、統計情報を含むフィードバック・メッセージを伝送させる。
【００１３】
別の実施形態では、前記値に基づくコントロール動作を行うことを目的とする１以上のコントロール・パラメータを決定する。ここで、前記コントロール動作は、過負荷エピソードの原因となる１以上のソースから下流サーバーへの転送データ速度を減少させる。前記１以上のコントロール・パラメータは、過負荷エピソードの原因となるソースと下流サーバーとの間のサーバー・ノードに送ることができる。前記コントロール動作は、ソースから下流サーバーへ伝送される伝送データ速度を減少させることによって、ソースから下流サーバーへ伝送されるデータに関してサーバー・ノードで行うことができる。ここで前記減少は１以上のコントロール・パラメータに基づいて行う。前記伝送速度は、過負荷エピソードの原因となる１以上のソースの下流サーバーへの要求試行速度（ｃａｌｌ ａｔｔｅｍｐｔ ｒａｔｅ）であってもよい。
【００１４】
別の実施形態では、１以上のコントロール・パラメータを決定することが、以下の決定することを含む：コントロール動作をどこで行うべきかを特定する動作位置を決定すること；前記動作位置でコントロール動作を適用する１以上のソースを定義する動作フィルターを決定すること；及び、コントロール動作に関する動作レベルを決定すること。前記動作レベルを決定することには以下の決定を含めることができる：所定の閾値を前記値が超えているかどうかを決定すること；そして、所定の閾値を前記値が超えている場合には、減少因子を用いて以前の動作レベルから減少させることを決定すること、前記値が前記所定の閾値未満の場合、前記動作レベルについて、増加ステップを用いて以前の前記動作レベルから増加させることを決定すること。前記所定の閾値はヒステレシスを用いて計算することができる。決定することについて、以下の動作定を含めることができる：前記値が所定の目標値と等しいかどうかを決定すること；並びに、もし前記値が前記所定の目標値と等しい場合には、前記動作レベルを変更しないこと；又は、もし前記値が前記所定の目標値と等しくない場合には、前記値と前記所定の目標値との差異及び以前の動作レベルに基づいて前記動作レベルを決定すること。前記１以上のコントロール・パラメータは前記動作位置に配信することができる。
【００１５】
別の実施形態では、前記方法は、以下のステップを含む：第二フィードバック・メッセージを第二下流サーバーから受け取るステップ（ここで前記 第二フィードバック・メッセージは前記統計情報を含む）；前記第二フィードバック・メッセージ中に含まれる情報に基づき１以上のハッシュ関数を用いて、カウンター配列からの１以上のカンウターのうちのどれが前記第二下流サーバーと関連しているかを決定するステップ；及び、前記統計情報を含む前記第二フィードバック・メッセージに応答して前記１以上のカウンターを増加させるステップ。複数のカウンター配列は保存することができ、ここで前記複数のカウンター配列それぞれは、異なるサーバー・ノードに保存されている。そして、複数のサーバー・ノードに跨る前記複数のカウンター配列に関連する各下流サーバーから受け取ったフィードバック・メッセージの数を計算するために前記複数のカウンター配列を集計することができる。前記通信プロトコルはセッション確立プロトコル (Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ、ＳＩＰ）であってもよく、及び前記統計情報がセッション拒否、前記下流サーバーからの過負荷フィードバック又はその両方であってもよい。前記通信プロトコルがセッション確立プロトコル、ハイパーテキスト・ドランスファー・プロトコル（ＨＴＴＰ）、ストリーム制御転送プロトコル（ＳＣＴＰ）、又はＴＣＰプロトコル（ｔｒａｎｓｍｉｓｓｉｏｎ ｃｏｎｔｒｏｌ ｐｒｏｔｏｃｏｌ）であってもよい。
【００１６】
別の実施形態では、前記１以上のハッシュ関数及び前記カウンター配列がカウンティング・ブルーム・フィルターに関連している。また、１以上のカウンターのうちどれが前記下流サーバーに関連するかについて決定することが、キーに関連するハッシュ関数を用いて前記１以上のカウンターを決定することを含み、前記キーは前記下流サーバーに関する識別子である。前記増加させるステップが以下のステップを含むことができる：前記１以上のカウンターを１ずつ増加させるステップ；又は、前記１以上のカウンターを１を超える数で増加させるステップ（ここで、前記１を超える数は以下に基づいて決定される：前記統計情報；一定期間、前記下流サーバーから受け取る統計情報；複数の一定期間、前記下流サーバーから受け取る統計情報；ソースから前記下流サーバーへ行われる伝送の種類；又はこれらの任意の組合せ）。
【００１７】
別の実施形態では、ブルーム・フィルターに基づくマルチ（複数）・レベルな閾値を動作位置に配信するステップを更に含む（ここで前記ブルーム・フィルターに基づくマルチ・レベルな閾値は、以下を保存する：複数の閾値(ここで前記複数の各閾値は、前記通信プロトコルに関するコール・リクエストと関連する複数のクラス（分類）からの１つのクラスに対応する)；及び、１以上のハッシュ関数を用いた前記複数の各クラスに関する、前記下流サーバーに対するコール・リクエストのカウント）。前記方法は、以下のステップを含むことができる：ソースから前記下流サーバーへのコール・リクエスト・メッセージを受け取るステップ（前記コール・リクエスト・メッセージは、前記複数のクラスのうち１つのクラスを含む）； 前記ブルーム・フィルターに基づくマルチ・レベルな閾値を用いて、以下を決定するステップ：（１）前記コール・リクエスト・メッセージ中の前記クラスに関する閾値；及び、（２）前記１以上のハッシュ関数を用いて、ブルーム・フィルターに基づく前記コール・リクエスト・メッセージ中の前記クラスに関する、前記下流サーバーへのコール・リクエストのカウント；並びに、もし、前記コール・リクエストのカウントが前記閾値を超える場合、前記コール・リクエスト・メッセージを拒否するステップ；又は、もし、前記コール・リクエストのカウントが前記閾値未満の場合、前記コール・リクエスト・メッセージを受け入れるステップ。前記統計情報は：ソースから前記下流サーバーへの失敗した接続リクエスト；前記下流サーバーからの過負荷通知；又はこれら両方であってもよい。
【００１８】
別の態様において、本発明は、ネットワーク中のサーバ過負荷を制限するためのシステムを特徴とする。前記システムは、以下を備える：カウンター配列を保存するように設計されるコンピュータ・メモリ・モジュール；及び、前記コンピュータ・メモリ・モジュールと通信し、以下の手段を備えるコントローラ：下流サーバーからフィードバック・メッセージを受け取るためのコンピューティング手段（ここで前記フィードバック・メッセージは通信プロトコルの統計情報を含む）；前記カウンター配列からの１以上のカウンターのうちのどれが前記下流サーバーに関連するかについて、１以上のハッシュ関数を用い、前記フィードバック・メッセージ中に含まれる情報に基づいて決定するためのコンピューティング手段（ここで前記１以上のカウンターは、前記下流サーバーから受け取り、且つ前記統計情報を含むフィードバック・メッセージの数に対応する数を保存する）。また、前記コントローラは、以下のコンピューティング手段を備える：前記統計情報を含む前記フィードバック・メッセージに応答して前記１以上のカウンターを増加させるためのコンピューティング手段；前記１以上のカウンターに保存される数の値を前記１以上のハッシュ関数を用いて決定するためのコンピューティング手段；及び、前記値が所定の基準を満たすかどうかに基づいて、前記下流サーバーが関連する前記ネットワーク中の過負荷エピソードを前記値が表すことを決定するためのコンピューティング手段。
【００１９】
別の態様において、本発明は、情報キャリア中で実際に実行されるコンピュータ・プログラム製品であることを特徴とする。コンピュータ・プログラム製品は、データ処理装置に以下の動作を行わせるために実行可能な指示を含む：下流サーバーからのフィードバック・メッセージを受け取ること（ここで前記フィードバック・メッセージは通信プロトコルの統計情報を含む）；コンピュータ・メモリ・モジュールに保存されたカウンター配列からの１以上のカウンターのうちのどれが前記下流サーバーと関連するかを、前記フィードバック・メッセージ中に含まれる情報に基づき、１以上のハッシュ関数を用いて決定すること（ここで前記１以上のカウンターは、前記下流サーバーから受け取とり、且つ前記統計情報を含むフィードバック・メッセージの数に対応する数を保存する）。前記コンピュータ・プログラム製品は、以下の動作をデータ処理装置に行わせるために実行可能な指示を更に含む：前記統計情報を含む前記フィードバック・メッセージに応答して前記１以上のカウンターを増加させること；前記１以上のカウンターに保存される数の値を前記１以上のハッシュ関数を用いて決定すること；及び、前記値が所定の基準を満たすかどうかに基づいて、前記下流サーバーが関連する前記ネットワーク中の過負荷エピソードを前記値が表すことを決定すること。
【００２０】
別の態様において、クライアント・コントロールを介したサーバー過負荷制限を目的とするコンピュータ化された方法がある。前記方法は、以下のステップを含む：サービスに関する複数要求（リクエスト）の第一セットを第一期間中第一伝送速度でサーバーに伝送するステップ；及び第一期間中第一伝送制限速度以下になるよう前記第一伝送速度を制限するステップ。また、前記方法は以下のステップを含む：サービスに関する前記複数リクエストの第一セットのうち少なくとも２以上のリクエストが過負荷基準を満たしているかどうかに基づいて過負荷値を決定するステップ;前記過負荷値をコンピュータ・メモリ・モジュールに保存するステップ。また、前記方法は以下のステップを含む：前記過負荷値及び前記第一伝送制限速度に基づいて第二伝送制限速度を決定するステップ。また、前記方法は以下のステップを含む：サービスに関する複数リクエストの第二セットを前記第一期間後の第二期間中に第二伝送速度で前記サーバーに伝送するステップ；及び、前記第二期間中の第二伝送速度を前記第二伝送制限速度以下になるよう制限するステップ。
【００２１】
別の態様において、クライアント・コントロールを介したサーバー過負荷制限を目的とするシステムがある。前記システムは、バッファ、伝送機、及びコントローラを備える。前記バッファは、サービスを要求する複数リクエストの第一セットを保存するように設計される。前記伝送機は、前記バッファと接続され、サービスを要求する前記１以上のリクエストを伝送制限速度以下となる伝送速度で第一期間中サーバーに伝送するように設計される。前記コントローラは、以下の手段を備える：サービスに関する前記複数リクエストの第一セットのうち少なくとも２以上のリクエストが過負荷基準を満たしているかどうかに基づいて過負荷値を決定するためのコンピューティング手段。また、前記コントローラは、以下の手段を備える：前記過負荷値及び前記伝送制限速度に基づいて、伝送制限速度を調整するためのコンピューティング手段。
【００２２】
別の態様において、コンピュータ・プログラム製品がある。前記コンピュータ・プログラム製品は、機械読取可能ストレージデバイスで実際に実行され、前記コンピュータ・プログラム製品が、データ処理装置に以下の動作を行わせるために実行可能な指示を含む：サービスに関する複数リクエストの第一セットを第一期間中第一伝送速度でサーバーに伝送すること；及び、前記第一伝送速度を前記第一期間中第一伝送制限速度以下に制限すること。また、前記コンピュータ・プログラム製品が、データ処理装置に以下の動作を行わせるために実行可能な指示を含む：サービスを要求する前記複数リクエストの第一セットのうち少なくとも２以上のリクエストが過負荷基準を満たしているかどうかに基づいて過負荷値を決定すること；及びコンピュータ・メモリ・モジュールに前記過負荷値を保存すること。また、前記コンピュータ・プログラム製品が、データ処理装置に以下の動作を行わせるために実行可能な指示を含む：前記過負荷値及び前記第一伝送制限速度に基づいて第二伝送制限速度を決定すること。また、前記コンピュータ・プログラム製品が、データ処理装置に以下の動作を行わせるために実行可能な指示を含む：サービスを要求する１以上のリクエストの第二セットを前記第一期間後である第二期間中に第二伝送速度で前記サーバーに伝送すること；及び、前記第二期間中前記第二伝送制限速度以下になるように前記第二伝送速度を制限すること。
【００２３】
他の態様において、上記態様の何れかは、以下の特徴の１以上を含むことができる。本発明では、前記過負荷値が目標過負荷値を下回るか上回るかを決定することをができる。前記過負荷値が前記目標過負荷値を超える場合に、前記第二伝送制限速度を決定することが、前記過負荷値と前記目標過負荷値との差分に比例する量だけ前記第一伝送制限速度を低下させることを含むことができる。前記過負荷値が前記目標過負荷値を超える場合に、前記第二伝送制限速度を決定するステップが、前記過負荷値に比例する量又は該過負荷値の目標過負荷値からの偏差に比例する量だけ前記第一伝送制限速度を低下させるステップを含むことができる。
【００２４】
幾つかの実施形態において、前記過負荷値が前記過負荷基準を満たすリクエスト速度を表す。前記過負荷値が前記目標過負荷値未満の場合に、前記第二伝送制限速度を決定することが前記第一伝送制限速度を速度ステップ（ｒａｔｅ ｓｔｅｐ）だけ上昇させることを含むことができる。前記速度ステップは固定されていてもよい。前記速度ステップは前記第一伝送制限速度に基づくことができる。前記速度ステップの範囲は最大速度ステップ及び最小速度ステップで決定することができる。第一層エンティティは前記過負荷値を決定することができ、第二層エンティティは前記第一伝送速度を制限することができ、前記第一層エンティティは前記第二層エンティティとは異なってもよい。前記第一層エンティティは、トランスポート層エンティティを含むことができ、前記第二層エンティティがアプリケーション層エンティティを含むことができる。
【００２５】
前記過負荷基準は明示的な過負荷基準であってもよい。前記明示的な過負荷基準は単一のリクエストのみに適用されてもよい。前記明示的な過負荷基準は非スロットリング型クライアント・レスポンスを特定することができる。さらに他の実施形態では、前記第一セットからのリクエストであって且つサービスを要求する第一リクエストに関する第一拒否メッセージを前記サーバーから受け取った場合、前記第一リクエストが前記明示的な過負荷基準を満たすことができる。
【００２６】
前記過負荷基準は暗黙的な過負荷基準であってもよい。前記第一セットからのリクエストであって且つサービスを要求する第一リクエストが伝送されてからの経過時間が遅延閾値を超える場合に、前記第一リクエストが前記暗黙的な過負荷基準を満たすことができる。ある時間間隔でサービスを要求する未応答のリクエストの割合が割合閾値以上になった場合に、前記暗黙的な過負荷基準を満たすことができる。前記暗黙的な過負荷基準はピア・コンジェスションとは無関係の前記サーバーからの１以上の応答メッセージに基づくことができる。前記１以上の応答の割合が割合閾値以上になった場合に、前記暗黙的な過負荷基準を満たすことができる。前記暗黙的な過負荷基準は、割合閾値以上である前記１以上の応答割合の変化に基づくことができる。
【００２７】
前記遅延閾値は静的であってもよい。前記遅延閾値は、前記サーバーに伝送されサービスを要求する１以上の以前のリクエストに対する平均応答時間に基づくことができる。前記遅延閾値は、前記サーバーに伝送されサービスを要求する１以上の以前のリクエストに対する百分率の応答時間に基づくことができる。前記第一セットからのリクエストであって且つサービスを要求する前記第一リクエストに対する第一応答を受け取る前に、前記第一セットからのリクエストであって且つサービスを要求する第二リクエストに対する第二応答を受け取るか否かに基づいて、第一リクエストが前記過負荷基準を満たすことができる（ここで、前記第二リクエストは、前記第一リクエストの後に前記サーバーへ伝送される）。
【００２８】
幾つかの実施形態において、前記過負荷値を決定するステップが、前記過負荷基準を満たす前記第一セットからのリクエスト数を平均化するステップ及び／又はフィルタリングするステップを含むことができる。前記過負荷値を決定するステップは、更に、前記第一期間の前の１以上の期間に関連する１以上の以前の過負荷値に基づくことができる。前記第一期間は、前記第二期間とブラインド間隔期間だけ離れていてもよい。前記ブラインド間隔は、固定時間間隔であるか、及び／又は前記サーバーに伝送されサービスを要求する１以上の以前のリクエストに対する平均応答時間に基づくことができる。
【００２９】
幾つかの実施形態において、前記複数リクエストの第一セットを伝送することは、前記１以上のリクエストの伝送について、リクエストの種類に基づいて優先順位を付けることを含むことができる。前記１以上のリクエストのリクエスト種類は、高優先度、通常、又はこれらの任意の組合せを含むことができる。前記複数リクエストの第一セット及び第二セットは、同一の分類又は種類であってもよい。前記複数リクエストの第一セットは、第一分類又は種類及び第二分類又は種類のリクエストを少なくとも含みことができる。前記複数リクエストの第二セットは前記第一分類及び／又は種類のリクエストのみを含むことができる。前記第一分類及び／又は種類は、１以上のサービス要求を自動的に再伝送することを含むことができる。
【００３０】
別の実施例において、方法に関連する上述の任意の特徴は、システム及び／又は前記システムのコントローラが実行することができ、該システム及び／又は該コントローラは前記方法を実行するために設計され又はそのための手段を有する。さらに、方法に関連する上述の任意の特徴は、コンピュータ・プログラム製品が実行することができ、プログラム製品がデータ処理装置に前記方法を行わせるために実行可能な指示を含む。
【発明の効果】
【００３１】
上述した任意の実施形態は、以下の１以上の利点を実現することができる。通信プロトコルの統計情報を保存するために、スペース的に有効な及びコンピュータ的に効果的なデータ構造（例えばブルーム・フィルター）を用いることにより、過負荷エピソード（例えば集中した過負荷エピソード）の検出を素早く効果的に行うことができる。前記実施形態は、複数のネットワーク要素（例えば、ソース、サーバー・ノード）に跨って保存されるデータ構造を集計するように設計することができ、下流サーバーやネットワーク要素に関連するネットワーク・ワイドな統計情報を集めることができる。コントロール・パラメータは、前記データ構造に基づいて計算され、適切な動作位置に配信される（例えば、クライアント、サーバー・ノード）。そして、過負荷エピソードを引き起こすメッセージの数を、下流サーバーに到達する前に減らす。そして、ネットワーク帯域を不必要に使用することを防止する。さらに、下流サーバーへの処理負荷を減らす。過負荷コントロールをクライアント側に分散させることにより、サーバーに与えられる負荷を、サーバースループットを最大化させるレベルにまで減少させることができる。幾つかの前記実施形態では、過負荷のかかったサーバーに到達する前に、幾つかのサービス要求をクライアントに抑えさせるように設計することができる。このことにより、結果としては、過負荷のかかったシステムに、より極端な過負荷が係ることを防止することができ、及び／又は過負荷イベントの全期間中最適に近い負荷でサーバーが稼動することを可能にすることができる。
【００３２】
他の実施形態では、応答（レスポンス）時間を決定することができる。サービス要求の遅延フィードバックを減らすことによりコントロールの安定性に寄与することができる点で有利である。更に、クライアント・ベースのコントロールは、処理過負荷をクライアント側に移行させることにより、クライアントへの制限レベル・コントロール・メッセージを更新及び／又は配信するというサーバー側の負荷を軽減できる点で有利である。更なる実施形態では、前記サービス・プロトコル（例えば、ＳＩＰ）の変更を必要とせずに設計できる点で有利である。更には、クライアント実施の過負荷コントロールは、前記クライアント・システム上で完全に実施することができる。そして、過負荷のかかったサーバーへの処理負荷を減らすことが出来る点で有利である。サーバーのパフォーマンスは、サービス由来のインフラの操作に非常に重要なものと成りうるため、クライアント実施過負荷コントロール技術は、メディアへの応用の際の待ち時間（例えば電話コールを開始する場合）を減らすことができる点で有利である。そして、サーバーに過負荷がかかったとしても、スループットを最大又は実質的に最大に維持できる点で有利である。
【００３３】
クライアント実施過負荷コントロール技術は、方法及び装置が含まれるが、例えば以下の要件を１以上満たすことができる：（１）過負荷のかかったサーバーにおいてスループットを自動的に最大化すること；（２）過負荷イベント期間中の高スループットを実現すること；（３）過負荷がかかっている最中、クライアントが早まってサービス要求を取り下げることが無い様に、応答時間の高い割合が充分に低いこと；（４）作業過負荷の変化に素早く反応すること。前記過負荷コントロール技術は、前記過負荷イベントを予め知っておくことに依存しない点で有利である。更に、サービス識別子（例えば、ユニーク・コード）は、特定のサービス要求を、１以上のサービス分類に分類することができる（例えば、各サービスの分類が異なるレベルのスループットを有する）。
【００３４】
１以上の実施例に関する詳細は、添付した図面及び以降の記述の中で述べる。更に、本発明の特徴、態様、及び利点については、本明細書、図面、及び特許請求の範囲から明らかになるであろう。前記図面については、必ずしも本発明そのものを表すものではなく、本発明の原則を例示する際に一般的に示されるものである点を強調しておく。
【００３５】
添付した図面と関連して以降の記載を参照することにより、上述した本発明の利点については、更なる利点と共に、より深く理解されるであろう。前記図面については、必ずしも本発明そのものを表すものではなく、本発明の原則を例示する際に一般的に示されるものである点を強調しておく。
【図面の簡単な説明】
【００３６】
【図１】クライアントからのサービス要求を処理するサーバーに関係する装置（デバイス）に関する例示的なネットワークを表したブロック図である。
【図２】クライアントの構成要素を表したブロック図である。
【図３】モデル・コントロール・ループの構成要素を表したブロック図である。
【図４】ウィンドウ化したタイム・インターバルを表す図である。
【図５】サーバー・リソースの外部コントロールを描いたフローチャートである。
【図６】サーバー・リソースの外部コントロールを描いたフローチャートである。
【図７】ＳＩＰメッセージ・フローのシミュレート・モデルを描いたハシゴ図である。
【図８】異なる過負荷コントロール概念（スキーマ）に関して、与えられた負荷に対するスループットを表した二次元プロットである。
【図９】本発明の例示的な実施形態に従って、集中したサーバー過負荷を検出及び制限することを目的とするネットワークを概念的に図示したものである。
【図１０】本発明の例示的な実施形態に従って、ネットワーク中の集中したサーバー過負荷を保存及び検出することを目的とするブルーム・フィルターを概念的に図示したものである。
【図１１】本発明の例示的な実施形態に従って、ネットワーク中の集中したサーバー過負荷を検出することを目的とする方法を例示したフローチャートである。
【図１２Ａ】本発明の例示的な実施形態に従って、ネットワーク中の集中したサーバー過負荷を検出することを目的とするカウンティング・ブルーム・フィルターに関するチャートを概念的に図示したものである。
【図１２Ｂ】本発明の例示的な実施形態に従って、ネットワーク中の集中したサーバー過負荷を検出することを目的とする集計カウンティング・ブルーム・フィルターに関するチャートを概念的に図示したものである。
【図１２Ｃ】本発明の例示的な実施形態に従って、ネットワーク中の集中したサーバー過負荷を検出することを目的とする、集計されたコール数の分布に関するチャートを概念的に図示したものである。
【図１３】本発明の例示的な実施形態に従って、ネットワーク中の集中したサーバー過負荷を制限することを目的とする１以上のコントロール・パラメータを決定するための方法を図示したフローチャートである。
【図１４Ａ】本発明の例示的な実施形態に従って、ネットワーク中の集中したサーバー過負荷を制限することを目的とする動作レベルを決定するための方法を図示したフローチャートである。
【図１４Ｂ】本発明の例示的な実施形態に従って、ネットワーク中の集中したサーバー過負荷を制限することを目的とする動作レベルを決定するための方法を図示したフローチャートである。
【図１５】本発明の例示的な実施形態に従って、ネットワーク中の集中したサーバー過負荷を制限することを目的とする方法を図示したフローチャートである。
【発明を実施するための形態】
【００３７】
１．ネットワークの概要
本明細書で記述するシステム及び方法は、コンピュータ中に通信プロトコル統計情報（例えば、下流サーバーからフィードバック・メッセージを介して受け取るなど）を保存するものであり、スペース的に有効な及びコンピュータ的に効果的なデータ構造（例えばブルーム・フィルター、カウンティング・ブルーム・フィルター、又はブルーム・フィルターに基づくマルチ・レベルな閾値(ＭＬＢＦ)）を使用する。ここで、用語「ブルーム・フィルター」が、本明細書において概して使用されているが、任意の種類のブルーム・フィルターを意味し、例えば、従来のブルーム・フィルター、カウンティング・ブルーム・フィルター、ＭＬＢＦ等が挙げられる点を理解されたい。前記データ構造を用いて、過負荷エピソードが下流サーバーや目的地に存在するかどうか（例えば、集中過負荷が下流サーバーに存在するかどうか）をネットワーク上のサーバーが決定する。もし、過負荷が存在する場合には、コントロール・パラメータがコンピューターを用いて計算され、該パラメータはコントロール動作を定義し、そして、該コントロール動作は１以上のネットワーク構成要素に配信され、過負荷エピソードをコントロールする（例えば、ソースから過負荷のかかった下流サーバーや目的地への伝送速度を減少させるなど）。
【００３８】
図１は、クライアントからのサービス要求を処理するサーバーに関係する装置に関する例示的なネットワーク（１００）を表したブロック図である。前記ネットワーク（１００）は、伝送媒体（１１０）、１以上のクライアント（１２０ａ、１２０ｂ、及び／又は１２０ｃ、概して１２０）、及び少なくとも１つのサーバー（１３０）（例えば下流サーバー）を含む。伝送媒体（１１０）（例えば、通信ネットワーク）は、サービス要求を含む情報を、１以上のクライアント（１２０）及び／又はサーバー（１３０）の間で伝送する役割を担う。以降でさらに詳述するが、クライアント（１２０）は、本明細書に記述された幾つかの発明技術に従って設計される。１以上のクライアント（１２０）及びサーバー（１３０）の間で、１以上の中継サーバー・ノードがあってもよく、該サーバー・ノードはクライアント（１２０）でもサーバー（１３０）（又は下流サーバー（１３０））でもない任意のノードである。
【００３９】
伝送媒体（１１０）は、接続部（１１５）によってクライアント（１２０）と接続することができる。クライアント（１２０）は、サーバー（１３０）からの１以上のサービスを要求することができる任意の装置である。クライアント（１２０）としては、ユーザーデバイスを含むことができ、例えば、コンピュータ、電話、ＩＰ電話、携帯端末（例えば、携帯電話、ＰＤＡ装置、ラップトップ・コンピュータ等）、及び／又は他の通信装置が挙げられる。幾つかの実施形態（例えば遠距離通信ネットワーク等）において、クライアント（１２０）は、メディア・ゲートウェイであり、例えば、コール・ソースからのセッション要求（図示しない）がネットワーク（１１０）に入る。また、幾つかの実施形態において、１以上のクライアント（１２０）は、１以上のサーバー機能を実行することもでき、従って、サーバー（１３０）とは異なるサーバー（複数可）としてみなしてもよい。例えば、遠距離通信ネットワークにおいては、遠距離通信スイッチ（例えば、端局又はタンデム・スイッチ）がサーバーとして動作することができ、及び／又は、任意の近隣遠距離通信スイッチに対するクライアントとして動作することができる。そして、それぞれが、コール・セットアップ等のサービスを要求するクライアントとして動作したり及び／又はサーバーとして動作したりすることができる。別の例においては、ＩＰルータやネットワーク・スイッチは、任意の近隣の又は遠隔のＩＰルータ又はネットワーク・スイッチに対するサーバー及び／又はクライアントとして動作することができる。そして、前記任意の近隣の又は遠隔のＩＰルータ又はネットワーク・スイッチも、それぞれ、クライアント及び／又はサーバーとして動作することができる。クライアントとして、近隣又は遠隔のＩＰ装置は、ＩＰパケットの伝送を要求することができ、及び／又はゲートウェイ・コントロール要求を送ることができる。本発明の別の例では、クライアント（１２０）及びサーバー（１３０）は、物理的に同一及び／又は論理的のいずれかの意味で同一のコンピューティング・デバイス内に配置することができる。例えば、コンピュータは、複数のタスク、プログラム、及び／又はプロセスを実行することができるが、この場合、サーバー（１３０）中の単一の処理ユニットは、クライアント（１２０）として動作するためのタスク、プログラム、及び／又はプロセスそれぞれに関するサービスの処理を担う。この例において、クライアント（１２０）が前記処理ユニット（即ち、サーバー（１３０））から分離している場合には、伝送媒体（１１０）は内部バスを含むことができる。
【００４０】
接続部（１１５）は、電線、光学ファイバー、及び／又は無線伝送部等を含むことができる。また、接続部（１１５）は、クライアント（１２０）をネットワーク（１１０）に接続する１以上の中継装置を含むことができる。クライアント（１２０）は、ユニークな識別子及び／又は共有された識別子によって識別することができる。ユニークなクライアント識別子は、例えば、電話番号、ＩＰアドレス等が挙げられる。共有されたクライアント識別子としては、例えば、ネットワーク・アドレス、エリア・コード、国別コード、サービス識別子等が挙げられる。
【００４１】
サービス識別子は、特定のサービス要求を１以上のサービス分類に分類するユニークなコードであってもよい。また、サービス要求は要求種類に基づいて分類することもできる。例えば、サービス要求は、新たなセッションを要求する要求メッセージ、又は既存のセッションの更新又は変更を要求する要求メッセージのいずれかに分類することができる。また、サービス要求は、以前送信された要求メッセージの再送信であるかどうかについて分類することができる（例えば、タイムアウト条件によって、クライアントに対して要求の再送信を指示した場合等）。別の例では、サービス要求は、データベース探索を必要としない要求メッセージ、又は１以上のデータベースの探索をプロセスに対して要求する要求メッセージの何れかに分類することができる。更に別の例では、サービス要求は、クライアントが登録した購入（ｓｕｂｓｃｒｉｐｔｉｏｎ）レベルに基づいて分類することができる。更に別の例では、サービス要求は、電子商取引購入活動、又は非電子商取引活動（例えば閲覧活動）のいずれかに関連するものとして分類することができる。更に別の例では、サービス要求は、以下のように優先度で分類することができる：優先要求；通常要求；又は、低優先度要求。一般的に、要求の優先度は、レベルに関する任意の番号で分類される（例えばレベル０〜１０までの優先度レベルを割り当てるなど）。
【００４２】
異なる分類のサービスを提供することは、サーバー（１３０）の異なるリソースを消費しうる（例えば、メモリ、ディスク帯域（ｄｉｓｋ ｂａｎｄｗｉｄｔｈ）、通信帯域、及び／又は処理サイクル）。別の実施形態では、クライアント（１２０）及び／又はサービス要求の分類付けは任意であってもよいため、クライアント（１２０）及び／又はサービス要求は識別子によって同定したり分類したりする必要がない。
【００４３】
また、伝送媒体（１１０）は、接続部（１１５）によって、サーバー（１３０）に接続することができる。サーバー（１３０）は、クライアント（１２０）からのサービスの各要求を処理することにより、１以上のクライアント（１２０）に対して、１種以上のサービスを提供する役割を担っている。サーバー（１３０）としては、例えば、ウェブ・サーバー、アプリケーション・サーバー、メディア・サーバー、ゲートウェイ、ソフトスイッチ、遠距離通信スイッチ（例えば、トール（ｔｏｌｌ）又はタンデム・スイッチ）、ネットワーク・ルータ、又はスイッチ等が含まれる。幾つかの実施形態において（例えば、ピア・ツー・ピア・ネットワークにおいて）、サーバー（１３０）は、他のサーバー（図示しない）からの１以上のサービスを要求することもでき、従って、該サーバーは、クライアント（１２０）とは別のクライアントとしてみなすこともできる。
【００４４】
サーバー（１３０）が提供しているサービスの種類として、例えば、音声サービス、ビデオ・サービス、データ・サービス、マルチメディア・サービス、及び／又は他の電子的なサービスを含むことができる。音声サービスとしては、例えば、遠距離通信ネットワークに関連するサービスの確立、維持、及び開放等が挙げられる。例えば、遠距離通信ネットワークに関して言えば、セッション要求がサーバーからネットワークへ出る。例えば、ＳＳ７ ＩＡＭメッセージ、ＳＩＰプロトコルＩＮＶＩＴＥメッセージ、又はＨ．３２３セットアップメッセージは、新たな電話コール又はコールセッションを開始するための要求であってもよい。同様にＳＩＰプロトコルＵＰＤＡＴＥメッセージは、既存のコールセッションの状態を更新するための要求であってもよい。ビデオ・サービスとしては、例えば、インターネットを介したビデオ・ストリーミングの確立、維持、及び開放を含むことができる。ビデオ・ストリーミングとしては、リアルタイム・ビデオ、及び／又はオンデマンド・ビデオを含むことができる。データ・サービスとしては、例えば、ウェブ・サイト（ＨＴＴＰ要求を処理する）、パケット・ルーティング（ＩＰパケットをルーティングする）、及び／又は一般的なコンテンツ配信を含むことができる。他のサービスとしては、例えば、１以上のビデオ、オーディオ、及び／又はデータ・サービスを含むことができる。他の実施形態では、例えば、飛行機の予約システムに関するウェブ・サーバー、１以上のオーディオ・サーバー、ｅ−ｍａｉｌサーバー、コラボレーション・サーバー、認証サーバー、及び／又は他のサーバー（複数可）がある。
【００４５】
特に、セッション確立プロトコル（ＳＩＰ）やＨ．３２３等のプロトコルは、様々な種類のメディア（例えば、音声、ビデオ、及び／又はテキストを含む）に関するセッションを作成したり、維持したり、及び／又は破棄したりするために使用することができる。ＳＩＰは、多くのメディア由来のアプリケーションで使用することができ、例えば、ボイップ（Ｖｏｉｃｅ ｏｖｅｒ ＩＰ （ＶｏＩＰ））、ボイスメール、インスタントメッセージ、プレゼンス（ｐｒｅｓｅｎｃｅ）、ＩＰＴＶ，ネットワーク・ゲーム等が上げられる。また、ＳＩＰは、ＩＰマルチメディアサブシステム（ＩＭＳ）に関するコアプロトコルとして使用することができ、固定電話及び無線電話ネットワーク両方のための第三世代パートナーシップ・プログラム（３ＧＰＰ）に関する基礎となっている。
【００４６】
一実施形態において、例えば、サーバー（１３０）は、クライアント（１２０）にとってインターネットを介して利用可能な１以上のウェブサイトを管理するウェブ・サーバーであってもよい。別の構成では、サーバー（１３０）は、電話コールをセットアップしたり切断したり（ｔｅａｒ ｄｏｗｎ）するためのＳＳ７シグナリング・メッセージを受信したり処理するＰＳＴＮに関するタンデム・スイッチであってもよい。別の構成では、サーバー（１３０）は、ＭＧＣＰメディア・ゲートウェイ又はＨ．２４８／ＭＥＧＡＣＯメディア・ゲートウェイであってもよく、それぞれ、コール・エージェント（複数可）やメディア・ゲートウェイ・コントローラ（複数可）（ＭＧＣ）からの要求を受け取る。更に別の構成では、サーバー（１３０）は、ネットワーク（１１０）上の他のクライアント（１２０）からのデータベース要求を処理するためのアプリケーション・サーバーであってもよい。他の構成では、サーバ（１３０）は、例えば、ソーナス・ネットワーク・ＰＳＸ（商標）、ＡＳＸ（商標）、ＧＳＸ（商標）／ＮＢＳ、及び／又はＡＧＣＦサーバーであっても良い。
【００４７】
ＩＩ クライアント実施過負荷コントロール
本発明に係る幾つかの実施形態によれば、外部の過負荷コントロールは、クライアント（１２０）（又は、クライアント（１２０）とサーバー（１３０）の間の中継サーバー・ノード、一般的には動作位置（ａｃｔｉｏｎ ｌｏｃａｔｉｏｎ）と呼ばれている）で実施されてもよい。有利な点として、クライアント実施過負荷コントロールは、過負荷がかかったサーバー（１３０）に対して、かかっている負荷をクライアント（１２０）が減らすことを可能にすることができ、その一方で、過負荷コントロールを目的として、サーバー（１３０）における負荷処理を犠牲にすることがない。その結果サーバー（１３０）のスループットが最大化できる。例えば、各クライアント（１２０）は、サーバー（１３０）での過負荷を表す明示的及び／又は暗黙的過負荷基準に基づいて、過負荷値（ｏｖｅｒｌｏａｄ ｖａｌｕｅ）を決定することができる。この決定された過負荷値をフィードバックとして使用して、クライアント（１２０）は、サーバー（１３０）へのサービス要求を伝送する速度を適切に調整することができる。例えば、サーバー（１３０）に対するサービス要求の伝送速度は、前記決定された過負荷値に反比例するようにすることができる。従って、クライアント実施過負荷コントロールは、過負荷コントロール目的（例えば内部の過負荷コントロール）でサーバー（１３０）が処理リソースを割り当る必要性を防止したり、及び／又は補助したりすることができ、代わりに、サービス要求を処理するために最大量のリソースを割り当て、それによってスループットを上昇させる。
【００４８】
一般的に、サービスに関するサービス要求の生成及び／又は発生は、通信プロトコル・スタックの任意の層で行うことができる。図２は、クライアント（１２０）の構成要素を表したブロック図（２００）である。クライアント（１２０）は、少なくとも１つのコントローラ（２８０）、少なくとも１つのコンピュータ・メモリ・モジュール（２９０）を含むことができ、また、ＯＳＩ参照モデル（ＩＴＵ−Ｔ勧告Ｘ．２００で定義されている）の１以上の層（２１０〜２７０）に従った１以上のプロトコルを含むことができる。前記ＯＳＩ参照モデルは、通信システムに関する抽象的な記述であり、以下のように７つの層に分割される；物理層（２１０）；データリンク層（２２０）；ネットワーク層（２３０）；トランスポート層（２４０）；セッション層（２５０）；プレゼンテーション層（２６０）；及びアプリケーション層（２７０）。各層内で、１以上のエンティティが、別の上位層又は下位層に対してサービスを提供する同様の機能の集合体を実装することができる。
【００４９】
物理層（２１０）は、機械的、電気的、機能的、及び手続き的な仕様を提供することができ、データリンクエンティティ間のビット伝送に関する物理的な接続を作動させたり、維持したり、不活化させたりする。データリンク層（２２０）は、機能的及び手続き的な仕様を提供することができ、ネットワーク・エンティティ間のデータリンク接続を確立したり、維持したり、及び開放したりすることを目的とする。そして、物理層（２１０）で発生するエラーを検出したり、おそらくは修正したりする。ネットワーク層（２３０）は、１以上のネットワーク上でのソース又は目的地間でのネットワーク接続を確立したり、維持したり、終了させたりするための仕様を提供することができ、そして、ソース及び目的地間でのデータ交換を行うための機能的及び手続き的な仕様を提供することができる。トランスポート層（２４０）は、セッション・エンティティ間での透過的なデータ伝送を提供する。そして、信頼性がありコスト的に有利なデータ伝送が達成される詳細な方法に関連する任意のものから開放する。また、トランスポート層（２４０）は、利用可能なネットワークの利用を最適化して、各セッション・エンティティが必要とする性能を最小限のコストで提供することができる。セッション層（２５０）は、エンティティ間でのダイアログ／接続をコントロールする仕様を提供することができる。また、セッション層（２５０）は、２つのプレゼンテーション・エンティティ間でのセッション接続を確立し、順番通りのデータ交換相互作用をサポートしたり、順番通りに接続を開放したりするためのサービスを提供することができる。プレゼンテーション層（２６０）は、アプリケーション・エンティティが通信内で通信又は参照のいずれかを行う情報を表したものを提供することができる。アプリケーション層（２７０）は、クライアント（１２０）上に存在するソフトウェア・アプリケーションと相互作用することができる。
【００５０】
図２に示したクライアント（１２０）では、ＯＳＩ参照モデルの７層に関してモデル化されたプロトコル・スタックを含んでいる。しかし、他のモデル及び／又は層を使用することもできる。例えば、クライアント（１２０）は、層２１０〜２３０（例えばルーターやレイヤー３スイッチ）のみに従ったプロトコルを含むことができる。また、他のモデルも使用可能であり、例えば、インターネットのＴＣＰ／ＩＰモデルが挙げられ、該モデルでは４つの抽象層（リンク層、インターネット層、トランスポート層、及びアプリケーション層）を含む。一般的に、通信プロトコルは、必ずしも前述した抽象層（２１０〜２７０）の１つに属する必要はなく、ある場合には、２つ以上の層に含まれることができる。
【００５１】
上述したように、サービス要求は、クライアント（１２０）のプロトコル・スタック（２１０〜２７０）中の１以上のプロトコルから発生又は生成することができる。コントローラ（２８０）は、プロトコル・スタック（２１０〜２７０）の１以上の層で、過負荷コントロールを実施して、サーバー（１３０）でのサービス要求処理に関するスループット及び／又は遅延を管理することを補助する。幾つかの実施形態において、コントローラ（２８０）は、プロセッサー又は装置であってもよい。他の実施形態では、コントローラ（２８０）はクライアント（１２０）中の別のプロセッサ又は装置によって実行される論理的な機能であってもよい。プロセッサとして、コントローラ（２８０）を設計することができ、コンピュータ・プログラムを実行し、入力データに関して操作したり及び／又は出力データを生成したりすることにより上述した技術を実践する。コンピュータ・プログラムを実行するのに適したプロセッサとして、例示的な意味で、汎用目的のマイクロプロセッサ、特定目的のマイクロプロセッサ、及び任意の種類のデジタル又はアナログコンピュータに関する１以上のプロセッサが含まれる。プロセッサは、例えばＲＯＭやＲＡＭ、又はその両方からの指示及びデータを受け取ることができる。
【００５２】
装置として、コントローラ（２８０）は、特定目的の論理回路として実装することができ、例えば、ＦＰＧＡ（ｆｉｅｌｄ ｐｒｏｇｒａｍｍａｂｌｅ ｇａｔｅ ａｒｒａｙ）、ＦＰＡＡ（ｆｉｅｌｄ−ｐｒｏｇｒａｍｍａｂｌｅ ａｎａｌｏｇ ａｒｒａｙ）、ＣＰＬＤ（ｃｏｍｐｌｅｘ ｐｒｏｇｒａｍｍａｂｌｅ ｌｏｇｉｃ ｄｅｖｉｃｅ）、ＰＳｏＣ（Ｐｒｏｇｒａｍｍａｂｌｅ Ｓｙｓｔｅｍ−ｏｎ−Ｃｈｉｐ）、ＡＳＩＰ（ａｐｐｌｉｃａｔｉｏｎ−ｓｐｅｃｉｆｉｃ ｉｎｓｔｒｕｃｔｉｏｎ−ｓｅｔ ｐｒｏｃｅｓｓｏｒ）、ＡＳＩＣ（ａｐｐｌｉｃａｔｉｏｎ−ｓｐｅｃｉｆｉｃ ｉｎｔｅｇｒａｔｅｄ ｃｉｒｃｕｉｔ）等が挙げられる。サブルーチンは、１以上の関数を実行する保存されたコンピュータ・プログラム、及び／又はプロセッサ、及び／又は特別回路の一部を参照することができる。
【００５３】
図２では、コントローラ（２８０）は、プロトコル・スタック（２１０〜２７０）とは別になるように図示されている。しかし、他の構成を使用することも可能である。例えば、コントローラ（２８０）は、プロトコル・スタック（２１０〜２７０）（例えばアプリケーション層（２７０））中の１以上のエンティティ（例えば、プロトコル又は層）に組み込むことができ、また前記プロトコル・スタック（２１０〜２７０）はコントローラ（２８０）に含むことができる。幾つかの実施形態において、一の層に組み込まれるコントローラ（２８０）には、プロトコル・スタック（２１０〜２７０）中の１以上の他のプロトコル又は層からのシグナルを提供することができる。例えば、アプリケーション層（２７０）に組み込まれたコントローラは、トランスポート層（２４０）からのシグナルに基づいた過負荷コントロールを実施することができる。
【００５４】
コントローラ（２８０）は、コンピュータ・メモリ・モジュール（２９０）と通信するように連結することができる。コンピュータ・メモリ・モジュール（２９０）としては、指示及び／又はデータを保存するための１以上のメモリ装置又はメモリ・サブ・モジュールを含むことができる。メモリ装置（例えばキャッシュ・メモリ）は、一時的にデータを保存するために使用することができる。また、メモリ装置は、マス・ストレージ・デバイスとして実装することができる。コントローラ（２８０）及びコンピュータ・メモリ・モジュール（２９０）は、特定目的の論理回路に補足したり組み込んだりすることができる。
【００５５】
クライアント・ベースの過負荷コントロールは、ホップ・バイ・ホップ又はエンド・ツー・エンドで実装することができる。ホップ・バイ・ホップには、直接トラフィックを交換する全ての近隣のクライアント（１２０）及びサーバー（１３０）間での分離したコントロール・ループを含むことができる。エンド・ツー・エンドには、サービス要求の全体パスにそったコントロール・ループを含むことができる。図３は、モデル・コントロール・ループ（３００）の構成要素を表したブロック図である。モデル・コントロール・ループ（３００）は、クライアント（１２０）のプロトコル・スタック（２１０〜２７０）の１以上の層において、クライアント・ベースの過負荷コントロール概念をどのように実装するかについて、物理的に又は論理的にの何れかで表すことができる。モデル・コントロール・ループ（３００）には、フィードバック・シグナル／値（３０５）を受け取ったり及び／又は暗黙的なフィードバック値（図示しない）を作成したりすることができるセンサー／フィルター（３１０）を含むことができる。センサー／フィルター（３１０）は、参照入力（３１５）を用いたコントロール・ユニット（３２０）と連結している。コントロール・ユニット（３２０）はアクチュエータ（３３０）（例えば、レストリクタ）と連結しており、該アクチュエータは、内部のサービス要求（３２５）（例えば、かけられた負荷）が出力される（３３５）速度を電子的に調整することができる。コントロール・ユニット（３２０）は、センサー／フィルター（３１０）からのフィードバック値と参照入力（３１５）との間の差分に基づいて速度設定を決定し、該設定をアクチュエータ（３３０）へ送ることができる。参照入力（３１５）（例えば、目標過負荷値）は、システム出力（３３５）に関する所望の値をとることができる。参照入力（３１５）は、固定値をとることもでき、及び／又は変数をとることもできる。例えば、参照入力（３１５）は、サーバー（１３０）の容量に基づくことができる。フィードバック値（３０５）及び／又はシステム出力（３３５）は、接続部（１１５）から若しくは該接続部へ及び／又はプロトコル・スタック（２１０〜２７０）の１以上の層から、受け取ったり又は送ったりすることができる。
【００５６】
センサー／フィルター（３１０）は、過負荷値を決定（例えば測定）することができ、該過負荷値は、サーバー（１３０）から受け取る明示的な過負荷シグナル又は通知（例えば、ＳＩＰ ５０３（Ｓｅｒｖｉｃｅ−Ｕｎａｖａｉｌａｂｌｅ）、Ｈ．３２３／Ｑ．９３１ Ｃａｕｓｅコード４２、Ｈ．２４８ 過負荷通知）の速度であってもよく、及び／又は暗黙的な過負荷値（例えば、リクエスト・タイムアウト）の速度であってもよい。また、暗黙的な過負荷通知は、過負荷コントロールを目的としないサーバー（１３０）から受け取ったメッセージを含むことができる（例えば、ＳＩＰ ４８０ （Ｔｅｍｐｏｒａｒｉｌｙ Ｕｎａｖａｉｌａｂｌｅ）、又はＨ．３２３／Ｑ．９３１ ４１ （Ｔｅｍｐｏｒａｒｙ Ｆａｉｌｕｒｅ））。更なる過負荷通知機構を用いて、過負荷フィードバックをクライアント（１２０）に送るために使用することができ、該フィードバックとしては、例えば、特別なＳＩＰ応答ヘッダ又はＳＩＰ過負荷イベント・パッケージが含まれる。前記ＳＩＰ過負荷イベント・パッケージによって、送信エンティティは、サーバーの過負荷状態に寄与したり、及びＮＯＴＩＦＹ要求における過負荷コントロール状態変化に関する通知を受け取ることができるようになる。
【００５７】
幾つかの実施形態において、過負荷通知（明示的及び／又は暗黙的）速度は、平均化フィルター（例えば、センサー／フィルター（３１０）中に含まれるもの）を通すことができ、測定を平坦化する。その後、平均過負荷通知速度を、目標過負荷値（３１５）と比較することができ、そして、その差分は、コントローラ（３２０）を作動させるために使用することができる。コントローラ（３２０）については、前記過負荷通知速度（３０５）（フィードバック値）（及び／又は暗黙的な過負荷値）が、小さな値を持つことができる目標過負荷値（３１５）の近くに集束させるようにするため、サーバー（１３０）へのサービス要求（３３５）の速度を許容された速度（コントロール入力）に調整することができる。拒否速度は、対象となるシステム（例えばサーバー（１３０））に関する負荷レベルを反映することができるため、良好なフィードバック値となりうる。サーバー（１３０）への負荷が増加するにつれて、サーバー（１３０）における内部過負荷コントロール・スキーマは、より多くのサービス要求を拒絶する。従って、過負荷通知を受け取る速度も同様に増加する。そして、拒否の変化速度が、かかっている負荷の変化速度に近づくことができる。
【００５８】
一般的に、センサー／フィルター（３１０）によって測定される過負荷通知は、明示的及び／又は暗黙的の何れかであってよい。幾つかの実施形態において、明示的な過負荷値は、例えば、５０３ Ｓｅｒｖｉｃｅ Ｕｎａｖａｉｌａｂｌｅという応答を介したＳＩＰ要求拒否をうけとったことを表すものであってもよい。暗黙的な過負荷値としては、例えば、サービス要求に対する応答が欠失していることを表すものであってもよい。一実施形態において、暗黙的な過負荷基準は、サービスを要求している仕掛中の要求（例えば、応答を受け取ってない要求）の割合を追跡することによって実現することができる。もし、ある時間間隔内での未応答のサービス要求の割合が割合閾値以上である場合、過負荷基準を満たすことができる。また、暗黙的な検出は、例えば、サービス要求を送るたびにクライアント（１２０）がタイマーをスタートさせることによって実現することもできる。前記タイマーは、タイムアウトを経過する前にサービス要求に対する応答を受け取った場合には、キャンセルすることができる。幾つかの実施形態において、前記タイムアウト期間は、サーバー（１３０）での高負荷で予想される応答時間を少し超える程度に設定することができる。センター（３１０）は、過負荷がかかったサーバー（１３０）からの暗黙的及び／又は明示的な過負荷通知の速度を測定することができる。幾つかの実施形態において、測定された速度は、指数加重移動平均（ＥＷＭＡ）ローパスフィルターを介して平均化することができる。フィルター（３１０）は、前記測定値の推計学情報を平坦化することができ、そして、前記コントロールが過負荷通知の突発的なバーストによって作動することのないようにすることができる。ＥＷＭＡフィルターは以下の通り記述することができる。
【数１】
（１）
ここで、Ｏm（ｎ）は、時間ｎで測定された過負荷値を表す。Ｏavg（ｎ）は、時間ｎでの平均過負荷値を表す。重みｗはローパス・フィルターの時間定数を表す。
【００５９】
幾つかの実施形態において、センサー／フィルター（３１０）は、サービス要求の１以上の特定の分類に関する過負荷通知を測定することができる。例えば、センサー／フィルター（３１０）は、通常のサービス要求のみに関する過負荷値を決定することができる。あるいは、センサー／フィルター（３１０）は、所定の優先値未満の優先値を持つ全てのサービス要求に関する過負荷値を決定することができる（例えば、優先分類が１０レベルであって、１〜６の間の優先レベルを有する全てのサービス要求）。別の実施形態又は補足的な実施形態では、センター／フィルター（３１０）は、１以上の過負荷値を決定し、コントローラ（３２０）に提供することができる。例えば、センサー／フィルター（３１０）は、通常のサービス要求及び優先度の高いサービス要求に第一過負荷値を提供することができ、そして再送信要求については第二過負荷値を提供することができる。
【００６０】
幾つかの実施形態において、かけられた負荷の変化の効果が功を奏し、クライアント（１２０）にフィードバックされる過負荷通知速度に反映されるまでは、クライアント（１２０）は過負荷通知応答を幾つも受け取る可能性がある。従って、毎回の過負荷通知で提供される速度が変化した場合には、早まってかかっている負荷を変化させる可能性があり、これによってかかっている負荷を過剰に矯正したり及び／又は著しく変動させたりする可能性がある。幾つかの実施形態において、提供された負荷速度に対して１以上の更新がなされた後で、待機期間Ｔｗａｉｔ（又は、ブラインド間隔期間）を導入することができ、該期間では過負荷通知はカウントしない。前記待機期間終了後は、過負荷通知を過負荷通知速度にカウントすることができる。
【００６１】
コントロール・ユニット（３２０）は、設計された目標過負荷値の近くに平均過負荷値を維持するように、許容されたサービス要求伝送速度をサーバー（１３０）に対して適用することができる。従って、コントロールは、平均過負荷値が目標過負荷値を超えるとすぐに作動することができる。幾つかの実施形態において、コントロール・ユニット（３２０）は、ＡＩＭＤ（Ａｄｄｉｔｉｖｅ Ｉｎｃｒｅａｓｅ／Ｍｕｌｔｉｐｌｉｃａｔｉｖｅ Ｄｅｃｒｅａｓｅ）の原理に基づいてもよく、時間に対する許容された速度を更に増加させることができる。過負荷を検出すると、その後、コントロール・ユニット（３２０）は、特定の因子によって許容速度を倍数的に減少させることができる。ＡＩＭＤコントロール・スキーマによって、安定且つ正当な稼動ポイントに収束させることができる。ＡＩＭＤアルゴリズムを用いて、コントロール・ユニット（３２０）は、固定サイズのステップで直線的に許容速度を増加させて、余分な容量を探ることができる。そして、過負荷を検出した際には、許容速度を固定因子（例えば０．５）によって倍数的に減少させることができる。
【００６２】
幾つかの実施形態において、コントロール・ユニット（３２０）は、過負荷値がすぐに目標過負荷値に収束するように許容速度を適用することができる。他の実施形態では、過負荷設定に素早く反応できるようにするため、許容速度の変化速度を、目標過負荷値に対する前記過負荷値の偏差に比例するようにすることができる。例えば、設定された目標速度に過負荷値が近い場合には、コントロール・ユニット（３２０）は、許容速度に対する変化を小さくすることができる。同様に、設定された目標過負荷値から更に過負荷値が離れるにつれて、コントロール・ユニット（３２０）は、許容速度への変化を大きくすることができる。該スキーマは、提供されたサービス要求伝送速度における急激な変化（増加及び／又は減少）に素早く反応することができる。
【００６３】
幾つかの実施形態において、コントロール・ユニット（３２０）は、１以上の特定分類の提供されるサービス要求（３２５）に関する許容サービス要求伝送速度をサーバー（１３０）に対して適用することができる。例えば、コントロール・ユニット（３２０）は、優先サービス要求に関する許容伝送速度については変化しない状態のままにする一方で、通常のサービス要求に関する許容伝送速度については適用することができる。あるいは、コントロール・ユニット（３２０）は、所定の優先度未満の優先度を持つ全てのサービス要求（例えば、１０段階の優先分類のなかで、優先度１〜６のサービス要求全て）に関して許容伝送速度を適用することができる。別の実施形態又は補足的な実施形態では、コントロール・ユニット（３２０）は、提供されたサービス要求（３２５）の１以上の分類に関して許容伝送速度を別々に適用することができる。例えば、第一種類のサービス要求に関する許容伝送速度は、センサー／フィルター（３１０）からの第一過負荷値に基づくことができ、第二種類のサービス要求に関する許容伝送速度は、センサー／フィルター（３１０）からの第二過負荷値に基づくことができる。
【００６４】
アクチュエータ（３３０）は、コントローラ（３２０）からの出力に基づいて、サービス要求（３３５）の伝送速度を電子的に制限することができる。前記制限を実施するために、異なる機構を使用することができる。例えば：（１）パーセント拒否；（２）要求ギャッピング；及び／又は（３）リーキィ・バケット（ｌｅａｋｙ ｂｕｃｋｅｔ）。割合拒否機構は、あるパーセンテージの提供された要求（３２５）を許容することができ、従って、提供された速度が変化するのに伴って許容速度を変化させることができる。コントローラ（３２０）は、許容サービス要求のパーセンテージを調整して、提供された速度を追跡することができる。もし、リーキィ・バケットを用いる場合、コントローラ（３２０）は、出力を更新する頻度をより少なくして、提供された速度を追跡することができる。これにより、フィードバック・コントロールを安定化させることを補助することができる。リーキィ・バケットと同様に、要求ギャッピングも、１つのトークンに関するバケットサイズを用いて動作することができる。補助的な実施形態において、アクチュエータ（３３０）は、入ってくる負荷（３２５）を一時的に保存するために１以上のバッファを含むことができる。
【００６５】
また、補足的又は別の実施形態において、アクチュエータ（３３０）は、分類に基づいてサービス要求の伝送を制限することもできる。一実施形態において、オーバーロード・フレンドリー・再伝送（ｏｖｅｒｌｏａｄ−ｆｒｉｅｎｄｌｙ ｒｅｔｒａｎｓｍｉｓｓｉｏｎｓ）は、以前のサービス要求からの再伝送である１以上の提供されたサービス要求（３２５）の自動再伝送を電子的に落とすアクチュエータ（３３０）を含むことができる。オーバーロード・フレンドリー・再伝送は、過負荷のかかったサーバー（１３０）に対する集合速度の自動コントロールを提供できる点で有利であり、該サーバーは古い要求の再伝送と新たな要求とを含む。更に、オーバーロード・フレンドリー・再伝送は、通常の要求の伝送よりも、高い優先度要求の再伝送を優先させることができる点で有利である。一般に、アクチュエータ（３３０）は、提供されたサービス要求（３２５）に関する１以上の分類に基づいて、サービス要求の伝送について優先度を付けることができる。
【００６６】
モデル・コントロール・ループ（３００）の構成要素は図３では別々に図示されているが、他の構成も使用可能である。例えば、モデル・コントロール・ループ（３００）の１以上の構成要素は、例えばコントローラ（２８０）等と同じユニット内に結合することができる。更に、クライアント（１２０）は、１以上の追加コントロール・ループ（３００）を有することができる。ある場合には、追加コントロール・ループ（３００）は、１以上の追加下流サーバーへのサービス要求伝送速度をコントロールするために使用することができる。補助的又は別の実施形態では、追加コントロール・ループ（３００）は、同じサーバーへの異なる分類のサービスに関するサービス要求伝送速度をコントロールするために使用することができる。
【００６７】
図４は、ウィンドウ化したタイム・インターバルを表す図である。幾つかの実施形態において、クライアント実施過負荷コントロール・スキーマはタイム・ドリブン（ｔｉｍｅ ｄｒｉｖｅｎ）であってもよい。タイム・ドリブン・スキーマにおいて、過負荷値は、所定の回数（例えば、ｔi， ｔi+1， ｔi+2等）で測定することができ、及び／又は所定の期間（例えば、Ｔn-1， Ｔn， Ｔn+1）測定することができる。１以上のブラインド間隔時間（例えば、ＴＢn-1， ＴＢn， ＴＢn+1等）を含むことができ、該間隔時間では、過負荷値を測定しない。幾つかの実施形態において、期間Ｔj及び／又はＴＢjを固定することができる。他の実施形態では、期間Ｔj及び／又はＴＢjは、変数であってもよい（例えば、既知のネットワーク遅延及び／又はシステム帯域等のシステム・パラメータに基づく）。
【００６８】
図５は、クライアント（１２０）での、コントローラ（２８０）によって実行されるクライアント・ベース過負荷コントロールを描いたフローチャート（５００）である。フローチャート（５００）の要素は、図３の例示的なモデル・コントロール・ループ（３００）を用いて記述される。クライアント・コントロールを介したサーバー過負荷制限としては、過負荷値（５１０）を決定すること（５１０）、過負荷値に基づいて伝送制限速度を決定すること（５２０）、伝送制限速度に基づいてサービス要求の伝送を制限すること（５３０）、及び／又は、任意で、新たな過負荷値を決定する前にブラインド間隔期間待機すること（５４０）が含まれる。幾つかの実施形態において、コントローラ（２８０）は、長さTのウィンドウ・タイム・インターバルに関するフローチャート（５００）中に描かれたアルゴリズムを実行することができる。例えば、もし、長さＴの間隔を１秒に設定した場合、コントローラ（２８０）は、フローチャート（５００）の要素を１秒ごとに実行する。補助的又は別の実施形態では、コントローラ（２８０）は、イベンド・ドリブン・ベースでフローチャート（５００）を実行することができる。例えば、フローチャート（５００）が最後に実行されてから受け取り、そして入ってくる要求（３２５）の数が、値Ｎを超えた場合に、コントローラ（２８０）は、フローチャート（５００）を実行することができる。フローチャート（５００）の要素は、クライアント（１２０）のプロトコル・スタック（２１０−２７０）内の１以上のプロトコル又はプロセスの間別々に実行することができるし、あるいは同時に実行することもできる。
【００６９】
過負荷値の決定（５１０）は、センサー／フィルター（３１０）が行うことができる。期間ｎの間の過負荷値の決定（５１０）は、Ｏn-avgで表すことができるが、以前にサーバー（１３０）に伝送された少なくとも２以上の要求が過負荷基準を満たしているかどうかを決定することを含むことができる。過負荷値Ｏn-avgは、例えばコンピュータ・メモリ・モジュール（２９０）中に保存することができる。幾つかの実施形態において、過負荷値は、過負荷基準を満たす要求の平均数であってもよい。例えば以下の通り。
【数２】
（２）
一般的に、過負荷値は、１以上の以前の期間からの過負荷測定数に基づく任意の関数ｆ（例えば、滑らかな関数）であってもよい。例えば、
【数３】
（３）
【００７０】
幾つかの実施形態によると、過負荷基準は、サーバー（１３０）からの明示的な拒否メッセージ（例えば、Ｏn-meashured＝Σｒｅｊｅｃｔｉｏｎｓ）を受け取ることを含むことができる。補足的又は別の実施形態では、過負荷基準は、例えば以下のタイムアウト等の暗黙的な値に基づいても良い。
【数４】
（４）
ここでＳｎは、１以上の現在の又は以前の期間（例えば、期間ｎ）の間に送られた要求の数を表し、また、
【数５】
（５）
ここでｔsiは、i番目要求が送られた時間を表すことができる。ｔriはi番目要求に対する要求を受け取った時間を表すことができる。tmeasuredは、過負荷測定の時間を表すことができる。Ｄは遅延閾値を表すことができる。前記遅延閾値Ｄは静的（例えば、予め知られたサーバー（１３０）遅延に基づく）及び／又は動的（例えば、クライアント（１２０）による設定変化）であってもよい。幾つかの実施形態において、時間ｎに関する動的遅延閾値Ｄnは、
【数６】
である。
ここで、Ｒnは平均応答時間を表すことができ、
【数７】
は、安全因子である(例えば≧１)。
平均応答時間は、
【数８】
であってもよい。ここで、αは平均因子を表すことができ、ｄは遅延測定を表すことができる。
【００７１】
更に他の補助的又は別の実施形態では、過負荷基準は暗黙的な値に基づくことができ、例えば、以下のような故障応答（ｏｕｔ ｏｆ ｏｒｄｅｒ）に基づくことができる。
【数９】
(6)
ここで、Ｓｎは１以上の期間（例えば、期間ｎ）の間に送られた要求の数を表すことができる。そして、
【数１０】
（７）
である。ここで、ｔsiは、ｉ番目の要求が送られた時間を表すことができる。triは、ｉ番目の要求に対する応答を受け取った時間を表すことができる。そして、ｆは|tsj - tsi| 及び／又は |j-i|の関数を表すことができる。一般的に、過負荷値は上記（２）〜（７）の１以上に基づくことができる。
【００７２】
過負荷値に基づいて伝送制限速度を決定すること（５２０）は、コントロール・ユニット（３２０）によって実行するこができる。図６は、過負荷値に基づいて伝送制限速度を決定すること（５２０）を表すフローチャート（６００）である。伝送制限速度を決定することには、過負荷条件が存在するかどうかを決定すること（６１０）が含まれる。もし、過負荷条件が存在する場合には、伝送制限速度はステップ・ダウンすることができる（６２０）。もし、過負荷条件が存在しない場合には、伝送制限速度はステップ・アップ（６３０）することができる。過負荷条件が存在するかどうかを決定すること（６１０）は、過負荷値と目標過負荷値（３１５）を比較することを含むことができ、該目標過負荷値はOtargetで表すことができる。
【００７３】
幾つかの実施形態によれば、伝送制限速度は、期間ｎ中に対する
【数１１】
で表現される。そして、
【数１２】
に従ってステップ・ダウン（６２０）される。ここで、Ｐn+1は以下の通り、伝送速度のパーセンテージである：
【数１３】
, (8)
ここで、ＧSDは、コントローラのステップ・ダウン・ゲインを表す。別の又は補助的な実施形態において、伝送速度制限は以下に従ってステップ・ダウンすること（６２０）ができる：
【数１４】
【００７４】
過負荷値が目標過負荷値を下回っている場合には、クライアント（１２０）は、ステップ・アップ・フェーズ（６３０）に入ることができる。前記ステップ・アップ・フェーズ（６３０）は、以下の条件の場合に継続される：（１）過負荷値が目標過負荷値を下回るとき；及び、（２）到達した過負荷（λ）（３２５）が、コントローラ（３２０）が許容した速度（λ＊）を上回る場合。幾つかの実施形態において、ステップ・アップ・フェーズは以下の２つのサブ・フェーズに分けることができる：「過負荷リカバリ」及び「過負荷防止」。過負荷リカバリの最中は、コントローラ（３２０）は、過負荷イベントの前に平均許容速度まで回復させようとすることができる。過負荷防止の最中は、コントローラ（３２０）は、許容速度をゆっくりと増加させることができる。補助的又は別の実施形態では、到達した過負荷（λ）（３２５）がコントローラ（３２０）が許容した速度（λ＊）を下回る場合に、コントローラ（３２０）での許容速度（λ＊）を変化しないままにすることができる。
【００７５】
伝送制限速度は以下に従ってステップ・アップすることができる（６３０）：
【数１５】
ここでｓｔｅｐ＿ｓｉｚｅは固定することができる。あるいは、ｓｔｅｐ＿ｓｉｚｅは以下に従って決定することができる：
【数１６】
ここでＧSUはステップ・アップ・ゲインを表し、
【数１７】
(9)
ここで、
【数１８】
は、クライアント（１２０）がサーバー（１３０）と共に有する最大シェアに基づくことができる値であって、予め設計された巨大な値を表すことができる。
そして、
【数１９】
は、過負荷に入る前又はステップ・ダウン・フェーズに入る前に提供される平均過負荷（３２５）を表すことができる。
【数２０】
であるときには、「過負荷リカバリ」と呼ぶことができるが、クライアント（１２０）は、過負荷状態の前の平均的な提供された負荷にリカバリすることを試みることができる。
【数２１】
であるときには、「過負荷回避」と呼ぶことができるが、クライアント（１２０）は、将来的な過負荷を回避するためにサーバー（１３０）を探索することを試みることができる。別の実施形態では、
【数２２】
は、時間ｎでの入ってくる要求（３２５）の速度を表すことができる。前記step_size値は、step_sizemaxを上限及び／又はstep_sizeminを下限値として境界値を設けることができる。ステップ・アップ・ゲインＧSUは固定しても、変動してもよい。例えば、
【数２３】
の場合には、より保守的にするために、ＧSUにより低いゲインを割り当てることができる。さらに別の又は補助的な実施形態では、step_sizeは以下に従って決定することができる：
【数２４】
【００７６】
調査フェーズ（即ち、ステップ・アップ・フェーズ）中、もし現在提供されている負荷（３２５）が最大速度ratemaxを超え、且つ最大速度ratemaxが
【数２５】
を下回る場合には、前記最大速度ratemaxは、
【数２６】
に設定される。前記調査フェーズ中、もし、センサー／フィルター（３１０）からの平均過負荷値が目標過負荷値（３１５）を超える場合には、クライアント（１２０）は、ステップ・ダウン・フェーズに（再度）突入し、現在の伝送制限速度を、最大速度ratemaxに関する現在の値として記録することができる。例えば、クライアント（１２０）は、現在の伝送制限速度を、
【数２７】
に関する現在の値として記録することができる。
【００７７】
伝送制限速度である
【数２８】
は、アクチュエータ（３３０）へ送られる。アクチュエータ（３３０）は、入ってきたサービス要求（３２５）を前記伝送制限速度である
【数２９】
によって（例えば前記伝送速度以下に）制限された速度で伝送（３３５）することができる。
【００７８】
新たな過負荷値を決定する（５１０）前のブラインド間隔期間待機するステップ（５４０）は、ブラインド間隔期間Tblindに基づくことができ、該期間は静的（例えば、サーバー（１３０）からの既知の平均応答時間に基づく）及び／又は動的（例えば、クライアント（１２０）による設定変化）であっても良い。幾つかの実施形態において、ブラインド間隔は、下記のとおり平均要求・応答遅延を動的に測定することに基づくことができる：
【数３０】
(10)
ここで、Ｒｎは平均応答時間を表す。αは平均因子であり、ｄは遅延測定である。時間ｎ＋１におけるブラインド時間間隔Ｔblindは、下記の通り設定することができる：
【数３１】
(11)
ここで、ｆblindは、１以上の安全因子（ｓａｆｅｔｙ ｆａｃｔｏｒ）を表すことができる。Ｔblindを動的に設定する別の方法として、連続した番号Ｎinit、及び速度を減少させた後の第一リクエストを送る時間を保存すること、並びに該ポイントでＴblindを開始することを含めることができる。Ｔblindは、Ｎinitよりも大きい連続番号Ｎを有する要求に関する応答を受け取ったあとで終了することができる。
【００７９】
新たな要求を拒絶することなく所定量の時間を維持し、過負荷値が目標過負荷値を下回った状態を維持した場合には、クライアント（１２０）は過負荷状態を脱することができ、以下のように設定することができる：
【数３２】
【００８０】
ＩＩＩ．計算の結果（Ｃｏｍｐｕｔａｔｉｏｎａｌ Ｒｅｓｕｌｔｓ）
量的な調査では、クライアント実施過負荷コントロールが、異なる過負荷プロファイル下で、ターゲット・サーバーの容量及び負荷分散をどのように適切に適用するかを表す。以下のシミュレーションでは、パケットレベルのシミュレーターＯＰＮＥＴを使用しており、該ＯＰＮＥＴは、ＳＩＰモジュール、並びにＳＩＰサーバー内の内外過負荷コントロールを実施するためのモジュールと共に拡張されている。ＳＩＰモデルはＳＩＰ ＲＦＣ ３２６１を実装する。ネットワーク・トポロジーには、ユーザー・エージェント（ＵＡ）が含まれており、該エージェントはエッジ・プロキシに接続されており、該プロキシはＵＡの要求をコア・プロキシに送る。各エッジ・プロキシは、１０のＵＡクライアント及び１０のＵＡサーバーに接続されている。エッジ・プロキシ及びコア・プロキシの数は、異なるシミュレーション・シナリオ間で変化する。各ＵＡクライアントは、INVITEトランザクションで表されるコールを生成し、続いてＢＹＥトランザクションで表されるコールを生成する。
【００８１】
図７は、セッション確立に関するシミュレートされたモデルＳＩＰメッセージ・フローを表したハシゴ図である。ＵＡクライアントが生成したコールは、ポワゾン到着モデルに従い、目的地ＵＡサーバーは、ネットワーク中の利用可能な全てのＵＡサーバーからランダムに選択される。全てのコア・プロキシが過負荷状態であるときには、エッジ・プロキシは要求を拒絶することができる。コア・プロキシは、目的地ＵＡのエッジ・プロキシに対する要求を送ることができる。プロキシは、到着するＳＩＰメッセージを保持する有限のキューとして表現することができ、一定の速度で該メッセージを提供（例えば、再伝送）することができる。こうしたサービス速度は、プロキシのメッセージ処理容量を規定する。このシミュレーションにおいては、エッジ・プロキシは無限の容量を有すると仮定されており、一方コア・プロキシは有限の容量を有するように設定されている。こうした仮定によって、コア・プロキシにおける過負荷の振る舞いに関する検証を行うことが可能となる。また、該仮定は、複数のエッジ・プロキシからの集中負荷をコア・プロキシが処理するものとして妥当な仮定である。このシミュレーションにおける全てのＳＩＰメッセージはＵＤＰを介して伝送され、従って、ＳＩＰによって再伝送を介してメッセージの信頼性が保障される。表１は、シミュレーションの為に使用される設定を表にしたものである（Ahmed Abdelal, Wassim Matragi, "Signal-Based Overload Control for SIP Servers", In Proceedings of IEEE Consumer Communications and Networking Conference (CCNC), January 2010を参照されたい。該文献全体を本明細書中に組み込む）。
【表１】
【００８２】
ＳＩＰシミュレーションにおいて、フル・コールすると、７つのメッセージの負荷がプロキシにかかる事になる（５つのメッセージはＩＮＶＩＴＥトランザクションであり、２つのメッセージはＢＹＥトランザクションである）。500 messages/secの容量で処理するコア・プロキシメッセージの場合、各コア・プロキシの容量は約72 calls/secである。以下の結果の中で、プロキシ／ネットワーク・スループットは、パフォーマンス・メトリックとして使用することができる。スループットは、成功したコールの速度を表す。もし、ＵＡクライアントが１０秒未満内に２００−ＯＫを受け取った場合コールが成功したものと定義する。そして、ＵＡサーバーはＩＮＴＩＴＥ−ＡＣＫを受け取る。コール・セットアップ遅延は、最初のＩＮＶＩＴＥ要求を送ってから２００−ＯＫを受け取るまでの間の時間で定義される。全てのシミュレーションは、システムが一貫した動作に達することを保証するのに充分長い時間実行される。
【００８３】
図８は、過負荷スキーマなし（８１０）、キュー・ベース実行を利用したサーバー・ベースの内部過負荷スキーマ（８２０）、及びクライアント・ベース過負荷スキーマ（８３０）に関しての与えられた負荷に対するスループットを表すシミュレーションの結果の二次元プロット図（８００）である。過負荷コントロールがない状態では、与えられた負荷がプロキシの集計容量である約142 calls/secを超えると、スループットが急速にゼロまで低下する。これは、キューのオーバー・フローによりＳＩＰメッセージが落ち、それに続いて上流クライアントからのＳＩＰ要求再伝送が行われることが原因となって生じる。内部過負荷コントロールは、過負荷コントロールが無い場合と比べると多少良好なスループットを達成できている。この理由は、拒否する作業量が、受け入れる場合と比べて労力を要さないからである。クライアント・ベースの過負荷コントロールでは、約142 Calls/Secのスループットを達成できている。
【００８４】
図９は、本発明の例示的な実施形態に従って、集中したサーバー過負荷を検出及び制限するためのネットワーク（９００）を概念的に表したものである。ネットワーク（９００）（例えば、図１の伝送媒体１１０）は、ソース（９０２Ａ，９０２Ｂ〜９０２Ｎ）（集合的にソース９０２）を含む。幾つかの例では、遠距離通信ネットワークに関して、通信プロトコルのセッション要求がネットワーク（９００）に入ってソース（９０２）を通過する（例えば、図１を参照すると、コールするクライアント（１２０）はセッション要求を接続部（１１５）を経由してソース（９０２）に伝送する）。例えば、通信プロトコルは、セッション確立プロトコル (SIP),ハイパーテキスト・ドランスファー・プロトコル (HTTP)、ストリーム制御転送プロトコル (SCTP)、トランスミッション・コントロール・プロトコル (TCP)、及び任意の他の種類のセッション／コネクションベースのプロトコル（例えば、要求−応答方法論に従ったプロトコル）であってよい。データは、ソース（９０２）から下流サーバー（９０４）（例えば図１のサーバー（１３０））へ送られる。また、ネットワークは、ソース（９０２Ａ及び９０２Ｂ）並びに下流サーバー（９０４）に接続されたサーバー・ノード（９０６）を含む。サーバー・ノード（９０６）は、プロセッサ（９０８）、コンピューター・メモリ・モジュール（９１０）（例えばデータベース）を含む。コンピューテーション・ノード（９１２）は、サーバー・ノード（９０６）を接続されている。コンピューテーション・ノード（９１２）は、コントロール・データベース（９１４）を含む。
【００８５】
ネットワーク（９００）は、１つのサーバー・ノード（９０６）及び１つの下流サーバー（９０４）だけを示してはいるが、ネットワーク（９００）は、任意の数のサーバー・ノード（例えば、ソース（９０２）と下流サーバー（９０４）との間の中継ノード）及び／又は下流サーバー（９０４）を含むように設計することができる。中継ノードは、ソース（例えばソース（９０２））でもなく、下流サーバー（例えば下流サーバー（９０４））でもない任意のノードである。ソース（９０２）からのデータは、下流サーバー（９０４）を介してネットワークを出発する（例えば、ソース（９０２）からのセッション要求が下流サーバー（９０４）を介してネットワーク（９００）を出発する）。コンピューテーション・ノード（９１２）は、該ノードが（例えばサーバー・ノード（９０６）を介して）受け取るデータを処理することができる。幾つかの実施形態において、コントロール・データベース（９１４）は、図１３−１４Ｂで更に詳述するが、１以上の動作位置（例えば、サーバー・ノード（９０６）等の中継ノード）にコントロール・パラメータ（即ち、コントロール情報）を送るためのコンピューテーション・ノード（９１２）によって使用される中央データベースである。
【００８６】
図１０は、本発明の例示的な実施形態に従って、ネットワーク中の集中したサーバー過負荷を保存及び検出するためのブルーム・フィルター（１０００）を概念的に表したものである。ブルーム・フィルター（１０００）は、ストレージ・デバイス（例えば、コンピュータ・メモリ・モジュール（９１０）及び／又はコントロール・データベース（９１４））によって実装され、ここで、キー（例えば、ｘ1及びｘ2）は、カウンター配列（１００４）中のカウンター（１００２Ａ〜１００２Ｎ）（集合的にカウンター（１００２））に、１以上のハッシュ関数（例えば、ハッシュ関数 Ｈａｓｈ1〜Ｈａｓｈ3）によって配置される。幾つかの実施形態において、カウンター配列（１００４）は、０又は１の何れかをセットできるカウンター・ビット配列である（ここで値０は、ブルーム・フィルター中の非メンバーシップを表し、値１はブルーム・フィルター中のメンバーシップを表す）。幾つかの実施形態において、ハッシュ関数及びカウンター配列（１００４）は、カウンティング・ブルーム・フィルター（又は、マルチ・レベル・ブルーム・フィルター（ＭＬＢＦ））であり、ここでカウンター配列（１００４）はカウンティング整数の配列である。例えば、ＭＬＢＦは複数閾値を有し、該閾値は異なるコール又はセッションに関連する。高優先度のコール又はセッションについては、高い閾値を使用し、一方で、低優先度のコール又はセッションについては、低い閾値を使用する。値がブルーム・フィルター（１０００）に挿入されるたびに、ハッシュ関数によって決定されるカウンティング整数が増加する（例えば、０又は１のいずれかを設定するのではなく、挿入の度に０〜１〜２等）。
【００８７】
ハッシュ関数は、任意のデータ・ストリームを入力（例えば、下流サーバー（９０４）等の下流サーバーの名前）として受け取り、整数を出力として戻す関数である。リターンされた整数は、カウンター配列（１００４）のカウンター（１００２）を同定するのに使用される（例えば、カウンター配列（１００４）中の全てのカウンター（１００２）が０に設定される）。従って、ブルーム・フィルター（１０００）は、複数のハッシュ関数（例えば、ハッシュ関数Ｈａｓｈ1〜Ｈａｓｈ3）を用いて、単一のキーについて、カウンター配列（１００４）内の複数のカウンター（１００２）にマッピングを行う。該実施形態において、２つの操作をブルーム・フィルター（１０００）上で実行することができる：INSERT(key) （例えば、INSERT (x1)（1010）及び INSERT (x2)（1012）) 並びに TEST(key) (例えば、 TEST(x1)（1014)）。ブルーム・フィルター（１０００）の一実施形態の機能性については、以降の図１１を参照しながら述べることにする。
【００８８】
ブルーム・フィルター（１０００）は、通信プロトコルに関する複数の統計情報についての追跡を継続するために使用することができる。例えば、もしネットワーク（例えばネットワーク（９００））がＳＩＰを使用している場合、ブルーム・フィルター（１０００）は、以下に関する数を保存する：下流サーバー（９０４）に関するセッション拒否；ソース（９０２）から下流サーバー（９０４）への失敗した接続要求；下流サーバー（９０４）からの過負荷通知；及び、任意で他の有用な通信プロトコル統計情報。ブルーム・フィルターは、分散させるやり方で、情報（例えば、セッション拒否統計情報等のフィードバック・メッセージ統計情報、及び／又は下流サーバー（９０４）からの他の過負荷フィードバック）を保存することを目的とする計算処理的及び空間的に有効な構造を提供する。有利な点として、ブルーム・フィルターは、一定の挿入時間、一定のテスト時間、及びフォールス・ポジティブに関する有限の確率（例えば、ブルーム・フィルターがキーを表す回数が、キーが設定されていなくてもブルーム・フィルター中に存在するなど）を有している。更に言えば、ブルーム・リルターは、保存目的用に極端にコンパクトであり、多数のブルーム・フィルターを追加して集合させることができる。例えば、複数のカウンター配列を（例えばネットワーク中（９００）で）使用することができ、ここで、複数のカウンター配列それぞれは、異なるサーバー・ノードに保存することができる（例えば、ネットワーク（９００）が複数のサーバー・ノード（９１２）を備える実施形態、又は中継ノード（９０６）がカウンティング・ブルーム・フィルターを保存するためのサーバー・ノードとして設計される実施形態など）。中央サーバー・ノード（例えば、コンピューテーション・ノード（９１２））は、複数のカウンター配列を集合させる。そして、異なるサーバー・ノード間での複数のカウンター配列に関連する各下流サーバー（例えば下流サーバー（９０４））からフィードバック・メッセージを受け取った数を計算する。
【００８９】
図１１は、本発明の例示的な実施形態に従って、ネットワーク中の集中したサーバー過負荷を検出するための方法（１１００）を示したフローチャート図である。
ステップ（１１０２）では、サーバー・ノード（９０６）は、下流サーバー（例えば下流サーバー（９０４））からフィードバック・メッセージを受け取る。フィードバック・メッセージは、通信プロトコルの統計情報（例えば下流サーバー（９０４）からのＳＩＰセッション拒否）を含む。ステップ（１１０４）では、サーバー・ノード（９０６）は、フィードバック・メッセージ中に含まれる情報をもとに（例えば下流サーバーの名前をもとに）１以上のハッシュ関数（例えば、ハッシュ関数Ｈａｓｈ1〜Ｈａｓｈ3）を用いて、カウンター配列（例えば、カウンター配列（１００４）であって、コンピューター・メモリ・モジュール（９１０）中に保存できるもの）からの１以上のカウンターのうちどれが下流サーバーに関連しているかを決定する。１以上のカウンターは、統計情報（例えば、下流サーバー（９０４）から受け取ったセッション拒否の数）を含む下流サーバーからのフィードバックの数に対応する数を保存することができる。
【００９０】
ステップ（１１０６）では、サーバー・ノード（９０６）は、統計情報を含むフィードバック・メッセージに応答して、１以上のカウンターを増加させる。ステップ（１１０８）では、サーバー・ノード（９０６）は、１以上のハッシュ関数を用いて、１以上のカウンター内に保存される数の値を決定する。ステップ（１１１０）では、サーバー・ノード（９０６）は、値が所定の基準を満たしているかどうかに基づいて、下流サーバーに関するネットワーク（例えばネットワーク（９００）中の過負荷エピソードを前記値が表しているかどうかを決定する。もし、前記値が過負荷エピソードを表していない場合には、前記方法はステップ（１１０２）に戻る。もし、前記値が過負荷エピソードを表す場合には、前記方法（１１００）はステップ（１１１２）に進む。該ステップでは、サーバー・ノード（９０６）（及び／又はコンピューテーション・ノード（９１２））は、過負荷エピソードの原因となっている１以上のソース（例えばソース（９０２）からの１以上のソース）を同定する。ここで、統計情報を含むフィードバック・メッセージを下流サーバーに伝送させている各ソースは、下流サーバーへの伝送を開始する。ステップ（１１１４）では、サーバー・ノード（９０６）（及び／又はコンピューテーション・ノード（９１２））は、前記値に基づいてコントロール動作を実行するための１以上のコントロール・パラメータを決定する。
【００９１】
ステップ（１１０４）に関して言うと、本発明のシステム及び方法は、下流サーバー（例えば下流サーバー（９０４））に関するネットワーク中の各サーバー・ノード（例えば、ネットワーク（９００）中のサーバー・ノード（９０６））において通信プロトコルの統計情報（例えばセッション拒否）の追跡を継続する。一実施形態において、各サーバー・ノードは、カウンティング・ブルーム・フィルターを使用し、サーバー・ノード基盤（ｂａｓｉｓ）ごとに、サーバー・ノード上の対象となる通信プロトコルの統計情報に関する計算を管理する。通信プロトコル統計情報を含むフィードバック・メッセージをサーバー・ノードが受け取るたびに、サーバー・ノードは、該サーバー・ノードに対応するカウンティング・ブルーム・フィルターと、増加され且つ組み合わされる目的キーに関するカウンターとを更新する。
【００９２】
通信プロトコル統計情報の受け取りについては、下流サーバーからサーバー・ノードへ伝送されるフィードバック・メッセージとして上述したが、サーバー・ノードは、複数の方法で観察可能なフィードバック・メッセージ（例えばセッション拒否通知）を観察することができる。例えば、サーバー・ノードは、明示的にフィードバック・メッセージを観察することができる（例えば、セッション・シグナリング・メッセージ等のフィードバック・メッセージの経路中にあるサーバー・ノード（９０６）等のネットワーク要素上への実装を介して）。サーバー・ノードは、暗黙的にフィードバック・メッセージを観察することができる（例えば、ＶｏＩＰ／ＩＭＳネットワーク内のコール・ディテール・レコード（ＣＤＲ：Ｃａｌｌ Ｄｅｔａｉｌ Ｒｅｃｏｒｄ）等のサーバー・ログを調査することによるなど）。
【００９３】
ブルーム・フィルターにキーを挿入（ＩＮＳＥＲＴ）することを目的として、Ｎ個のハッシュ関数の各ハッシュ関数をキーに適用することにより、Ｎ個のハッシュ値を作成する。その後、Ｎ個のハッシュ値に相当するビット・ベクトル中のＮ個のポジションを増加させる（例えば、１に設定し、１ずつ増加させる等）。図９及び１０を参照すると、サーバー・ノード（９０６）は、３つのハッシュ関数Ｈａｓｈ1〜Ｈａｓｈ3を用いて、カウンター配列（１００４）からの１以上のカウンター（１００２）のうちどれが下流サーバーと関連しているかについて決定を行っている。ここで、キーは、下流サーバー（９０４）の名前等、下流サーバーに関する識別子である。例えば、フィードバック・メッセージが下流サーバー（９０４）から送られたことを表すデータをサーバー・ノード（９０６）が保存する必要がある場合に、サーバー・ノード（９０６）は、ＩＮＳＥＲＴ（ｘ1）（１０１０）を実行して、新たな値をブルーム・フィルター（１０００）内に挿入する。ここで、ｘ1は、下流サーバー（９０６）の名前である。図１０に示すように、ＩＮＳＥＲＴ（ｘ1）（１０１０）は、３つのハッシュ関数Ｈａｓｈ1〜Ｈａｓｈ3を使用して、ｘ1（下流サーバー（９０６）の名称）に関連するカウンター配列内（１００４）のポジション（１０１０Ａ、１０１０Ｂ、及び１０１０Ｃ）を特定している。例えば、もし、フィードバック・バックメッセージが異なる下流サーバー（下流サーバー（９０４）ではない）から送られたことを表すデータを保存する必要がサーバー・ノード（９０６）にある場合には、サーバー・ノード（９０６）は、ＩＮＳＥＲＴ（ｘ2）（１０１２）を実行して、新たな値をブルーム・フィルター（１０００）に挿入することができる。ここでｘ2は前記異なる下流サーバーの名前である。図１０に示すように、ＩＮＳＥＲＴ（ｘx）（１０１２）は、３つのハッシュ関数Ｈａｓｈ1〜Ｈａｓｈ3を使用して、ｘ2（前記異なる下流サーバーの名前）に関連するカウンター配列（１００４）内のポジション（１０１２Ａ、１０１２Ｂ及び１０１２Ｃ）を同定する。
【００９４】
ステップ（１１０６）に関して述べると、特定の下流サーバーから受け取った通信プロトコルの統計情報（例えば、統計情報を含むフィードバック・メッセージ）の数に関するカウントを増加させる（例えば０から１へ、１から２へ等）ように、１以上のカウンター（１００２）を増加させる。幾つかの実施形態において、通信プロトコルの統計情報の数に基づいて、サーバー・ノード（９０６）はカウンター（１０１２Ａ，１０１２Ｂ，及び１０１２Ｃ）を直線的に増加させる（例えば、サーバー・ノード（９０６）は、各通信プロトコルの統計情報に対して、整数ｘだけ増加させることができる）。例えば、図１０に示すように、サーバー・ノード（９０６）は、カウンター（１０１２Ａ，１０１２Ｂ，及び１０１２Ｃ）を１だけ（即ち０から１へ）増加させる。幾つかの実施形態において、サーバー・ノード（９０６）は、１を超える数（例えば、２、３等）だけ、１以上のカウンターを増加させることもできる。１を超える数については、以下のものに基づいて決定することができる：サーバー・ノード（９０６）が監視している統計情報；ある期間下流サーバー（９０４）から受け取る統計情報（例えば、５分間の時間枠で受け取った統計情報）；ソースから下流サーバーへの伝送の種類（例えば、ソースが行うコールの種類に基づく）（ここで、高優先度のコール／セッションは、通常のコール／セッションよりも重み付けを低くすることができ、従って、高優先度のコール／セッションは成功率が高くなる）；及び／又は、複数の期間に下流サーバー（９０４）から受け取る統計情報（例えば、所定の５分の時間枠内で、３日間連続で受け取る統計情報）。幾つかの実施形態において、サーバー・ノード（９０６）は、非直線的な関数に基づいて、カウンター（１０１２Ａ，１０１２Ｂ，及び１０１２Ｃ）を増加させる（例えば、増加値ｘは、ＳＩＰ ５０３ （Ｓｅｒｖｉｃｅ Ｕｎａｖａｉｌａｂｌｅ）応答におけるＲｅｔｒｙ−Ａｆｔｅｒパラメーター、コール／拒否応答中に戻される過負荷レベルの値に基づくことができる）。
【００９５】
ステップ（１１０８）に関して述べると、サーバー・ノード（９０６）は、ネットワーク（例えば図９のネットワーク（９００））中の１以上の下流サーバーから受け取った下流サーバーに関する通信プロトコル統計情報の数を決定する。一実施形態において、サーバー・ノードは、ブルーム・フィルター中に保存する通信プロトコル統計情報のカウント（又は計算）に基づいて、各下流サーバーに関する受け取った通信プロトコル統計情報の数を決定する。ブルーム・フィルター中にキーが設定されているかどうかをテスト（ＴＥＳＴ）するために、Ｎ個のハッシュ関数を用いた挿入の間に、キーに関してＮ個のハッシュ値を計算する。ベクトル中の対応するＮ個のビット・ポジション全てが設定されている場合には、キーはブルーム・フィルター中に存在するといえる。例えば、図１０を参照すると、ＴＥＳＴ（ｘ1）（１０１４）操作は、所与のキーｘ1が、ブルーム・フィルター（１０００）に関するカウンター配列（１００４）に以前挿入されているかどうかを見るためにテストする。ハッシュ関数Ｈａｓｈ1〜Ｈａｓｈ3は、カウンター（１０１４Ａ〜１０１４Ｃ）をそれぞれ同定する。カウンター（１０１４Ａ〜１０１４Ｃ）は、ＩＮＳＥＲＴ（ｘ1）（１０１０）の際に同定された同一のカウンターに対応している。なぜなら、ハッシュ関数は、特定のキー（この場合はｘ1）に対しては同じ値を生成するからである。従って、ブルーム・フィルター（１０００）は、各カウンター（１０１４Ａ〜１０１４Ｃ）における値が１に設定されていることを決定し、キーｘ1がブルーム・フィルター（１０００）に存在し、１の値を持っていることを表す（例えば、カウンティング・ブルーム・フィルター（１０００）に関しては、キーｘ1はブルーム・フィルター（１０００）に一度挿入され、通信プロトコル統計情報がキーｘ1に関して一度観察されたことを示す）。例えば、もし、ｘ1が１５回挿入された場合には、カウンター（１０１４Ａ〜１０１４Ｃ）は「１」の代わりに「１５」になるであろう。
【００９６】
ステップ（１１１０）に関して述べると、サーバー・ノード（９０６）による所定の基準は、例えば、閾値（例えば、「２５」というカウント値）であってもよい。そして、過負荷エピソードがあることを決定するこが、値が閾値を超えることを決定することを含む。幾つかの実施形態において、所定の基準はヒステレシスを用いて掲載される（例えば、現在の値と以前の値の履歴との両方に基づいて）。例えば、コントロール理論において、ヒステレシスは、幾つかの目標値（例えばＸ）にシステムの出力を維持するために使用することができる。以下のように２つの閾値を定義することができる：（１）低い方の閾値をＸ−Δ、及び（２）高いほうの閾値をＸ＋Δ。この場合、コントロールは、システムの状態が連続する数のサンプルに関して、高いほうの閾値（即ち、Ｘ＋Δ）を超えたときに可能となる。一方で、システムの状態が、連続する数のサンプルに関して、低い方の閾値（即ち、Ｘ−Δ）を下回ったときには不能になる。こうしたことにより、オン・オフ状態をバタバタと切り替わることを防止できる点で有利である。
【００９７】
例えば、ステップ（１１１０）に関して述べると、サーバー・ノード（９０６）による所定の基準は、例えば、低い方の閾値及び高い方の閾値によって定義される閾値であってもよい（例えば、カウント値「２３」と「２５」）。そして、過負荷エピソードが存在することを決定することには、値が閾値を超えることを決定することが含まれる。任意の時間のポイントにおいて、システム状態が高い方と低い方の閾値の間にある場合には、システムは、以前の値の履歴を見ることなく過負荷エピソード（例えばコントロール状態；オン／オフ）があるかどうかの決定をすることができない。
【００９８】
幾つかの実施形態において、ブルーム・フィルターは、サーバー・ノード・基盤ごとに管理される（例えば、サーバー・ノードごとに１つのブルーム・フィルター）。各ブルーム・フィルターに関するカウンターは、上述したように各サーバー・ノードにおいて、及び／又は集合レベルで集計される。例えば、ブルーム・フィルターは、周期的に集計することができ（例えば、コンピューテーション・ノード（９１２）が３０秒ごとに１度）、広範な範囲（例えば、サーバー・ノード基盤ごとではなく、サーバー・ノード・ワイド又はネットワーク・ワイド）にわたる通信プロトコル統計情報を計算することができる（例えば、セッション拒否分散カウント）。幾つかの実施形態において、サーバー・ノード（９０６）及び／又はコンピューテーション・ノード（９１２）は、統計的な手法を用いて過負荷エピソードを検出することができる。例えば、ホルト・ウィンターズ法を使用することができる。ホルト・ウィンターズ法は、タイム・シリーズの複数の指数加重移動平均（ｍｕｌｔｉｐｌｅ ｅｘｐｏｎｅｎｔｉａｌｌｙ ｗｅｉｇｈｔｅｄ ｍｏｖｉｎｇ ａｖｅｒａｇｅｓ）を利用する例外検出アルゴリズムである。ホルト・ウィンターズ法は、例えば、データ・シリーズにおいて、単一のシーズン・バリエーション（ｓｉｎｇｌｅ ｓｅａｓｏｎａｌ ｖａｒｉａｔｉｏｎ）（例えば、遠距離通信ネットワークにおいて典型的なトラフィック量における日中のバリエーション（例えば、毎日発生する変動））を組み込むことができる。ホルト・ウィンターズ法は、データ・シリーズの平均を追跡するために、そして、許容可能な値範囲、シーズン・バリエーションを組み込む所与のユーザー特定モデルを予想するために使用することができる。もし、データ値が予想された許容値の範囲外になった場合には、例外（ａｎｏｍａｌｙ）が宣言される。
【００９９】
更にステップ（１１１０）に関して述べると、一旦過負荷エピソードが特定の下流サーバーに関して検出されると、適切な情報がステップ（１１１２）の同定フェーズに渡される。こうした情報としては、例えば、ネットワーク中に過負荷エピソードが存在することを表すものであったり、過負荷のかかった下流サーバーのカウンター（例えば、ビット又は整数）がマークされたブルーム・フィルターを含むことができる。幾つかの例において、同定フェーズに渡されたブルーム・フィルターは、通信プロトコル統計情報の追跡を継続するために使用されるブルーム・フィルターと同じであってもよい。
【０１００】
更にステップ（１１１０）に関して述べると、例えば、通信帯域だけでなくコンピューテーションの観点から効果的な態様で検出を行うことが有利である。ブルーム・フィルターの使用によって、検出を行うための極端に効果的な方法が提供されるという点で有利である。図１２Ａは、本発明の例示的な実施形態に従って、ネットワーク中の集中したサーバー過負荷を検出するためのカウンティング・ブルーム・フィルター（例えば特定のサーバー・ノードに関するブルーム・フィルター）に関するチャート（１２００）を概念的に示したものである。チャート（１２００）は、特定のカウンターに関するカウントを表す縦軸に沿った値（１２０２）（例えば、図１０のカウンター配列（１００４）のカウンターに関するもの）を含む。また、チャート（１２００）は、カウンター配列内の各カウンタのポジションを表す横軸に沿ったカウンター・インデックス（１２０４）（例えば、第一カウンター、第二カウンター等）を含む。また、チャート（１２００）は、特定のカウンター・インデックス（１２０４）に関する値（１２０２）を表すグラフ化された線（１２０６）を含む。チャート（１２００）は、ブルーム・フィルター中に保存された情報を視覚的に表しており、集中したサーバー過負荷を検出するのに使用される。例えば、ピーク（１２０８）は、インデックス部位が１９であるカウンターに関する値（約３２０）を示している。ブルーム・フィルターは、カウンター・インデックスにおける情報を特定のキー値（例えば下流サーバー名称）に割り当てている。例えば、インデックス部位１９に割り当てられた下流サーバーは、値３２０と関連付けられている（例えば、チャート（１２００）に関連付けられたブルーム・フィルターを保存するデバイス（例えば、サーバー・ノード（９０６））へ下流サーバーから送られた３２０のセッション拒否が存在する）。
【０１０１】
図１２Ｂは、本発明の例示的な実施形態に従って、ネットワーク中の集中したサーバー過負荷を検出するための、集合カウンティング・ブルーム・フィルター（例えば、図１２Ａに示したもの等の複数のサーバー・ノードに広がる複数のブルーム・フィルターの集計値を表すブルーム・フィルター）に関するチャート（１２３０）を概念的に表したものである。チャート（１２３０）は、複数のブルーム・フィルターにまたがる特定のカウンターに関するカウントを表す縦軸に沿った値（１２３２）を含む（例えば、特定のカウンター・インデックスに関する各カウンター配列のカウンター値の合計）。また、チャート（１２３０）は、複数の集合ブルーム・フィルター内の各カウンターのポジションを表す横軸に沿ったブルーム・フィルター・インデックス（１２３４）を含む（例えば、各ブルーム・フィルターに関する第一カウンター、第二カウンター等）。また、チャート（１２３０）は、特定のブルーム・フィルター・インデックス（１２３４）に関する値（１２３２）を表示するグラフ化された線（１２３６）を含む。チャート（１２３０）は、複数の集合ブルーム・フィルターにまたがって保存される情報を視覚的に表しており、集中しているサーバー過負荷を検出するために使用される。 例えば、ピーク（１２３８）は、ネットワークのブルームフィルター全てを一旦集合させると、図１２Ａのインデックス部位１９でのカウンターに関する値（約３２０）が、約１５１００まで上昇することを示している。ノード（例えばコンピューテーション・ノード（９１２））は、集合ブルーム・フィルターに関するカウンター・インデックスにおける情報を特定のキー値（例えばサーバー名称）に割り当てる。例えば、インデックス部位１９に割り当てられた下流サーバーは、値１５１００に関連付けられる（例えば、チャート（１２３０）において値を集合させたブルーム・フィルターが保存されているデバイスへ下流サーバーから伝送された１５１００のセッション拒否が存在する）。
【０１０２】
図１２Ｃは、本発明の例示的な実施形態に従って、ネットワーク中の集中したサーバー過負荷を検出するための集合させたコール数分布に関するチャート（１２６０）を概念的に表したものである。チャート（１２６０）は、各コール数インデックス（１２６４）（例えば、遠距離通信プロトコルにおいてコールされた各数）に関するコールの数（１２６２）をグラフ化したヒストグラムである。数学的な操作を通して、図１２Ｂの集合ブルーム・フィルターを、チャート（１２６０）に示したネットワーク・ワイド通信プロトコル統計情報ヒストグラム（例えばセッション拒否ヒストグラム）を計算するために使用することができる。サーバー・ノード（９０６）及び／又はコンピューテーション・ノード（９１２）は、特定の下流サーバーに対する通信プロトコル統計情報の頻度を決定するために、チャート（１２６０）を使用することができる。例えば、コンピューテーション・ノード（９１２）は、ソース（９０２）から特定の目的地数へのセッション拒否の数（又は値）を決定するためにチャート（１２６０）を使用することができる。ここで目的地数は下流サーバー（９０４）を通して到達する。そして、例外検出技術は、上述したようにこうしたチャート（又はヒストグラム）（１２６０）に適用され、過負荷エピソードが存在するかどうかについて決定する。
【０１０３】
ステップ（１１１２）について述べると、ステップ（１１１０）で検出される任意の過負荷エピソードを引き起こす伝送のソースは、フィードバック・メッセージを受け取ることに基づいて検出することができる。例えば、あるサーバー・ノードでのブルーム・フィルターは、目的地基盤（例えば下流サーバー目的地に基づく）に関する通信プロトコル統計情報を管理することができる。遠距離通信ネットワークに関して、例えば、セッション要求を受け取った場合、目的地は、上述したようにブルーム・フィルターへのキーとして使用することができる。目的地キーに関するＴＥＳＴは、目的地が現在過負荷がかかっているかどうかについて決定することができ、要求のソース（例えば、複数のクライアント（１２０）の１つ）を過負荷エピソードに関するコンジェスション（渋滞）のソースとして特定するであろう。
【０１０４】
ステップ（１１１４）に関して述べると、コントロール動作により、下流サーバー（例えば下流サーバー（９０４））に対して過負荷エピソードを引き起こす原因となっている１以上のソース（例えばソース（９０２））からのデータの伝送速度を減少させる。図１３は、本発明の例示的な実施形態に従った、ネットワーク中の集中したサーバー過負荷を制限するための１以上のコントロール・パラメータを決定する（例えば、図１１のステップ（１１１４）における１以上のコントロールパラメータを決定することを目的とする）ための方法（１３００）を表すフローチャートである。ステップ（１３０２）において、コンピューテーション・ノード（９１２）（又はサーバー・ノード（９０６））は、サーバー・ノード又は他のネットワーク要素がコントロール動作を受ける場所を特定する動作位置を決定する。ステップ（１３０４）では、コンピューテーション・ノード（９１２）は、動作位置においてコントロール動作を適用すべき１以上のソースを定義する動作フィルターを決定する。ステップ（１３０６）では、コンピューテーション・ノード（９１２）は、コントロール動作に関する動作レベルを（例えばヒステレシスを用いて）決定する。ステップ（１３０８）では、コンピューテーション・ノード（９１２）は、動作位置に１以上のコントロール・パラメータを配信する。
【０１０５】
ステップ（１３０２）に関して述べると、動作位置の値は、以下のいずれかであってもよい：ワイルドカード（例えば、コントロール・パラメータが全てのサーバー・ノードにおいてネットワークワイドに適用される）；又は、特定のサーバー・ノード（例えばネットワーク・スイッチ）、通信グループ（例えば、基幹グループ）等を特定する特定の組（ｔｕｐｌｅ）。動作位置の選定は、所定のアプリオリであるポリシー・レベルの決定であってよい。例えば、動作位置は、コントロール・パラメータが全てのソースにおける動作に適用されるように決定することができる（例えば、侵入（ｉｎｇｒｅｓｓ）ノード）。別の例として、遠距離通信ネットワークに関して、同定された目的地数にマッチする入ってくる基幹グループに関するコールは、入ってくる基幹グループからのコールを受け取るサーバー・ノードによって制限される速度であってよい。
【０１０６】
ステップ（１３０４）に関して述べると、動作フィルターは過負荷エピソードを引き起こす原因となる同定されたソースに基づいて計算することができる。ステップ（１３０６）に関して述べると、動作レベルは、複数のアルゴリズムを用いて計算することができる。図１４Ａ及び１４Ｂは、本発明の例示的な実施形態に従って、ネットワーク中の集中したサーバー過負荷を制限するための動作レベルを決定するための方法を表すフローチャートである。図１４Ａは、動作レベルを決定するための方法（１４００）を表す。ステップ（１４０２）では、コンピューテーション・ノード（９１２）（又はサーバー・ノード（９０６））は、値が所定の閾値を超えるかどうかを決定する。もし、値が所定の閾値を超える場合には、方法はステップ（１４０４）へと進み、コンピューテーション・ノード（９１２）が、減少因子を用いて以前の動作レベルから動作レベルを減少させるように決定する。もし、値が所定の閾値を下回る場合には、方法はステップ（１４０６）へと進み、コンピューテーション・ノード（９１２）が、増加ステップを用いて以前の動作レベルから動作レベルを増加させるように決定する。
【０１０７】
ステップ（１４０２〜１４０６）に関して述べると、方法は以下のような式を使用することができる：
while True: (12)
if VALUE > θ:
ACTION_LEVEL[k+1] = ACTION_LEVEL[k] × β
else:
ACTION_LEVEL[k+1] = ACTION_LEVEL[k] − step
k = k + 1
sleep T,
ここで：
VALUE = 現在の通信プロトコル統計情報に関する値（例えば、セッション拒否カウント）；
β = 許容されたインター・コール・ギャップ時間における倍数増加値（β> 1 (例えば1.1)）;
step =許容されたインター・コール・ギャップ時間における更なる減少値（単位はｍｓ、例えば10 ms）;
θ = コントロール・シグナル目標値(例えば、閾値）;
T = 周期的な動作計算間隔;
ACTION_LEVEL[k] = k番目の間隔での動作レベル(例えば、インター・コール・ギャップ・時間が50 ms)であり、その範囲が最大値及び最小値で規定することができる（例えば最小値が40 ms 及び最大値が60 ms）。
【０１０８】
ステップ（１４０２）に関して、Ｔ秒ごとに、新たな動作レベルをシータ（θ）に基づいて計算される。最初のACTION_LEVEL[k]には、例えば、初期値を設定する
（例えば、ｍｓ単位のコール・ギャップ、例えば１０ｍｓ等）。コンピューテーション・ノード（９１２）（又は、サーバー・ノード（９０６））は、VALUEがθを超えるかどうかを決定する。ステップ（１４０４）に関して、もし、VALUEがθを超える場合には、コンピューテーション・ノード（９１２）は、コール・ギャップにおける倍数増加（許容要求速度に対する減少である）を計算する。具体的には、式（１２）に関して述べると、ACTION_LEVEL[k+1]は、k番目の間隔での現在の動作レベルであるが、以前の動作レベルACTION_LEVEL[k]に対する倍数増加として計算される。ステップ（１４０６）に関して、もしVALUEがθ以下の場合には、コンピューテーション・ノード（９１２）は、コール・ギャップにおける更なる減少値（許容要求速度に対する増加である）を計算する。具体的には、式（１２）に関して述べると、ACTION_LEVEL[k+1]は、以前の動作レベルACTION_LEVEL[k]に対する更なる増加として計算される。有利な点として、式（１２）は容易に設計され、プロセッサ（例えばサーバー・ノード（９０６）のプロセッサ（９０８））上で素早く実行される。
【０１０９】
図１４Ｂは、動作レベルを決定するための方法（１４５０）を表すフローチャートである。ステップ（１４５２）では、コンピューテーション・ノード（９１２）は、値が所定の目標値と等しいかどうかを決定する。もし、値が所定の目標値と等しい場合には、方法はステップ（１４５４）に進み、コンピューテーション・ノード（９１２）は動作レベルの変更を行わない。もし、値が所定の目標値と等しくない場合には、方法はステップ（１４５６）に進み、コンピューテーション・ノード（９１２）は、以前の動作レベル、並びに値及び所定の目標値の差に基づいて動作レベルを決定する。
【０１１０】
ステップ（９１２〜９１４）に関して、方法は以下の式を使用することができる：
while True: (13)
if ABSOLUTE(VALUE − θ) > Δ:
ACTION_LEVEL[k+1] = ACTION_LEVEL[k] +γ× (VALUE -θ)
else:
ACTION_LEVEL[k+1] = ACTION_LEVEL[k]
k = k + 1
sleep T,
ここで：
Δ = 過負荷シグナルに対する目標値からの偏差に関する所定の閾値;
VALUE = 現在の通信プロトコル統計情報に関する値(例えばセッション拒否カウント）;
γ =コンジェスション中コール・ギャップがどれだけ急速に増加するかについてコントロールする比例利得定数（proportional gain constant）(例えば、001);
θ =コントロール・シグナル目標値;
T = 周期的な動作計算間隔;及び
ACTION_LEVEL[k] = k番目の間隔での動作レベル(例えば、インター・コール・ギャップ・時間が50 ms)。
【０１１１】
ステップ（１４５２）に関して、Ｔ秒ごとに、新たなACTION_LEVELをVALUEに基づいて計算する。コンピューテーション・ノード（９１２）は、VALUE−θの絶対値がΔを超えるかどうかを決定する。ステップ（１４５４）に関して、ABSOLUTE(VALUE −θ)がΔの場合（即ち値がθと等しい場合）、コンピューテーション・ノード（９１２）は動作レベルを変更しない。ステップ（１４５６）に関して、もし、ABSOLUTE(VALUE − θ)がΔを超える場合（即ち、VALUEがθと等しくない場合）、コンピューテーション・ノード（９１２）が、以前の動作レベルACTION_LEVEL[k]に基づいて、比例アルゴリズムを用いて動作レベルACTION_LEVEL[k+1]を決定する（例えば、コントロールシグナルVALUEと所望のレベルθとの差分に比例するコール・ギャップを増加させる等）。有利な点として、式（１３）は、振動動作するような結果にはならない。なぜなら、式（１３）は、コントロール理論概念を使用して（例えば、比例アルゴリズムを用いて）、目標ポイントθへより早く収束するようにしているからである。
【０１１２】
ステップ（１３０８）に関して述べると、コンピューテーション・ノード（９１２）は、過負荷エピソードを軽減するために、１以上のコントロール・パラメータを動作位置に配信することができる。例えば、サーバー・ノード（９０６）及び／又はコンピューテーション・ノード（９１２）は、過負荷エピソードの原因となるソースと下流サーバーとの間のサーバー・ノードに、１以上のコントロール・パラメータを送る。サーバー・ノードは、ソースから下流サーバーへ伝送されるデータに関する伝送速度（例えば、過負荷エピソードの原因となる１以上のソースから下流サーバーへのコール試行速度）を減少させることにより、サーバー・ノードでの該データに関するコントロール動作を実行する。ここで前記減少は１以上のコントロール・パラメータに基づいて実行される。
【０１１３】
例えば、検出され、及び（例えばコンピューテーション・ノード（９１２）により）同定された目的地であって、過負荷がかかった目的地（例えば、下流サーバー（９０４）又はコールされた目的地の電話番号等の下流サーバー（９０４）を介して到達可能な目的地）が与えられた場合は、セッション・ギャッピングを使用して、過負荷のかかった目的地へのセッション要求（例えばクライアント（１２０）からの要求）間に最小限の時間制限を適用することができる。セッション・ギャッピングは、過負荷のかかった目的地へのセッション要求の入ってくる速度を制限するために使用することができる。例えば、コンピューテーション・ノード（９１２）は、コントロール・パラメータを配信して、クライアント（１２０）から受け取ったセッション要求に対して、セッション・ギャッピング（コントロール動作）をソース（９０２）（例えば、ネットワークの侵入ノード）で実行することができる。コントロール動作は、過負荷のかかった目的地に対して、提供されたセッション要求速度をコントロールし、（拒否されるであろう）セッションがネットワークに入って、ネットワーク・リソースを使用することを防止する。過負荷がかかった目的地に対するコール間の最小限の時間間隔は、例えば、図１４Ａ及び図１４Ｂを参照しながら述べたACTION_LEVELとして計算することができる。このACTION_LEVELは、（例えば、マス・コーリング・イベント等の予想できないイベントに基づいて）目的地での過負荷の度合いが変化するにつれて変化することができる。
【０１１４】
図１５は、本発明の例示的な実施形態に従って、ネットワーク中の集中したサーバー過負荷を制限するための方法（１５００）を表したフローチャートである。ステップ（１５０２）では、コンピューテーション・ノード（９１２）は、ブルーム・フィルターに基づくマルチ・レベルな閾値を動作位置（例えばサーバー・ノード（９０６）に配信する。ブルーム・フィルターに基づくマルチ・レベルな閾値は複数の閾値を保存する。ここで、各複数の閾値は、通信プロトコルに関するコール・リクエストに関連する複数の分類からの１つのクラスに対応する。また、ブルーム・フィルターに基づくマルチ・レベルな閾値は、各複数の分類に関する下流サーバー（例えば、下流サーバー（９０４））へのコール・リクエストのカウントを、１以上のハッシュ関数を持ちいて保存する。ステップ（１５０４）では、動作位置は、ソースから下流サーバーへのコール・リクエスト・メッセージを受け取る。ここで、コール・リクエスト・メッセージは、複数の分類のうち一つの分類を含む。ステップ（１５０６）では、動作位置は、ブルーム・フィルターに基づくマルチ・レベルな閾値を用いて、以下について決定をする：（１）コール・リクエスト・メッセージにおける分類に関する閾値；及び（２）１以上のハッシュ関数を用いたブルーム・フィルターに基づく、コール・リクエスト・メッセージにおける分類に関する下流サーバーへのコール・リクエストのカウント。ステップ（１５０８）では、動作位置は、コール・リクエストのカウントが閾値を超えるかどうかを決定する。もし、コール・リクエストのカウントが閾値を超えている場合には、方法はステップ（１５１０）へ進み、動作位置はコール・リクエスト・メッセージを拒否する。コール・リクエストのカウントが閾値未満の場合には、方法はステップ（１５１２）へ進み、動作位置は、コール・リクエスト・メッセージを受け入れる。
【０１１５】
ステップ（１５０２）を参照すると、ブルーム・フィルターに基づくマルチ・レベルな閾値を、Ｍ個の分類のコール・リクエストを扱うために使用する（例えば、上述したような低、中、及び高優先度要求）。各分類は、伝送（例えば、クライアント（１２０）から下流サーバー（９０４）へ）が現状のネットワーク条件（例えば、過負荷エピソードがあるかどうか、又は下流サーバー（９０４）と関連するかどうか）の下で受け入れられる可能性を決定する関連優先度を有する。ブルーム・フィルターに基づくマルチ・レベルな閾値はＭ個の閾値を管理し、Ｍ個の分類の１分類につき１つずつ管理する。例えば、遠距離通信ネットワークに関するステップ（１５０４〜１５１２）を参照を参照すると、クライアント（１２０）から目的地へのコール・リクエストがソース（９０２）（例えば、侵入ノード）に入ったとき、ブルーム・フィルターに基づくマルチ・レベルな閾値によって追跡される現在のコンジェスション・レベル（目的地へのコール・リクエストのカウント）が、コール・リクエストに対応する分類に関する閾値と比較される。もし、コンジェスション・レベルが、コール・リクエスト閾値を超える場合には、コールは拒否される。そうでない場合にはコールは受け入れられる。
【０１１６】
上述した技術は、デジタル及び／又はアナログ電子回路や、コンピュータ・ハードウェア、ファームウェア、ソフトウェア、又はこれらの組合せにおいて実装することができる。こうした実装は、コンピュータ・プログラム製品として行うことができる。即ち、データ処理装置（例えば、プログラム可能なプロセッサ、コンピュータ、及び／又は複数のコンピュータ）での動作によって実行、又はコントロールするための機械読取可能ストレージデバイスで実際に実行されるコンピュータ・プログラムである。コンピュータ・プログラムは、任意の形態のコンピュータ言語又はプログラム言語で記載することができ、これらにはソース・コード、コンパイラ・コード、インタプリタ・コード、及び／又は機械コードが含まれる。そして、コンピュータ・プログラムは、任意の形態で配置することができ、該形態としては、スタンド・アロンなプログラム若しくはサブルーチン、要素、又はコンピューティング環境での使用に適した他のユニット等が含まれる。コンピュータ・プログラムは、１以上のサイトでの１つのコンピュータ又は複数のコンピュータで実行するために配置することができる。
【０１１７】
方法のステップは、コンピュータ・プログラムを実行する１以上のプロセッサによって実行される。そして、入力データに関して操作したり、及び／又は出力データを生成したりすることによって本発明の機能を実践する。また、方法のステップは、特定目的の論理回路（例えば、ＦＰＧＡ（ｆｉｅｌｄ ｐｒｏｇｒａｍｍａｂｌｅ ｇａｔｅ ａｒｒａｙ）、ＦＰＡＡ（ｆｉｅｌｄ−ｐｒｏｇｒａｍｍａｂｌｅ ａｎａｌｏｇ ａｒｒａｙ）、ＣＰＬＤ（ｃｏｍｐｌｅｘ ｐｒｏｇｒａｍｍａｂｌｅ ｌｏｇｉｃ ｄｅｖｉｃｅ）、ＰＳｏＣ（Ｐｒｏｇｒａｍｍａｂｌｅ ｓｙｓｔｅｍ−ｏｎ−Ｃｈｉｐ）、ＡＳＩＰ（ａｐｐｌｉｃａｔｉｏｎ−ｓｐｅｃｉｆｉｃ ｉｎｓｔｒｕｃｔｉｏｎ−ｓｅｔ ｐｒｏｃｅｓｓｏｒ）、又はＡＳＩＣ（ａｐｐｌｉｃａｔｉｏｎ−ｓｐｅｃｉｆｉｃ ｉｎｔｅｇｒａｔｅｄ ｃｉｒｃｕｉｔ）等）によって実行することができ、そして装置は該回路として実装することができる。サブルーチンは、保存されたコンピュータ・プログラムの一部を参照することができ、並びに／又は１以上の関数を実行することができるプロセッサ及び／若しくは特殊回路を参照することができる。
【０１１８】
コンピュータ・プログラムの実行に適したプロセッサとしては、例示的な意味で汎用目的のマイクロプロセッサ及び特殊目的のマイクロプロセッサの両方、並びに任意の種類のデジタル又はアナログコンピュータにおける１以上の任意のプロセッサが含まれる。一般的に、プロセッサは、ＲＯＭ、ＲＡＭ、又はその両方から指示やデータを受け取る。コンピュータの本質的な要素は、指示を実行するためのプロセッサ、並びに指示及び／又はデータを保存するための１以上のメモリ・デバイスである。キャッシュ等のメモリ・デバイスは、一時的にデータを保存するために使用することができる。また、メモリ・デバイスは長期間のデータ保存目的で使用することもできる。また、一般的に、コンピュータは、それらからデータを受け取ったり、又はそれらへデータを送ったり、又はその両方を目的として、データ保存用の１以上のマス・ストレージデバイス（例えば、磁気媒体、光磁気ディスク、又は光ディスク等）を含む、又は動作上連結している。また、ネットワークから指示及び／若しくはデータを受け取ったり、並びに／又はネットワークへ指示及び／若しくはデータを送ったりすることを目的として、コンピュータは動作上通信ネットワークと連結している。コンピュータ・プログラムの指示及びデータを実行することに適したコンピュータ読取可能保存媒体としては以下の物が含まれる：あらゆる形態の揮発性及び不揮発性メモリ（例示的な意味として、半導体メモリ・デバイス、例えば、ＤＲＡＭ、ＳＲＡＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ及びフラッシュ・メモリ・デバイス）；磁気ディスク（例えば、内部のハードディスク、又はリムーバブル・ディスク）；光磁気ディスク；及び光ディスク（ＣＤ、ＤＶＤ、ＨＤ−ＤＶＤ及びＢｌｕ−ｒａｙ）。プロセッサ及びメモリは、特殊目的の論理回路によって補足したり及び／又は該回路中に組み込むことができる。
【０１１９】
ユーザーとの相互作用を提供するために、上述した技術を、ユーザーに情報を表示するための表示装置（例としては、ＣＲＴ（ｃａｔｈｏｄｅ ｒａｙ ｔｕｂｅ）、プラズマ、又はＬＣＤ（液晶ディスプレイモニター））や、キーボード及びポインティング・デバイス（例えば、マウス、トラックボール、タッチパッド、モーション・センサー）（これらによって、ユーサーはコンピュータに入力を行うことができる（例えば、ユーザー・インターフェース要素と相互作用する））と通信するコンピュータ上で実行することができる。同様にユーザとの相互作用を提供する目的で他の種類のデバイスを使用することができる；例えば、ユーザーに提供するフィードバックとしては、任意の形態の感覚的フィードバック（例えば、視覚的フィードバック、聴覚的フィードバック、及び触覚的フィードバック）の形態であってもよい。そして、ユーザーからの入力については、音響、スピーチ、及び／又は触覚的な入力を含む任意の形態で受け取ることができる。
【０１２０】
上述した技術は、バック・エンド・コンポーネントを含む分散コンピューティング・システムにおいて実行することができる。バック・エンド・コンポーネントとしては、例えば、データ・サーバー、ミドルウェア・コンポーネント、及び／又はアプリケーション・サーバー等であってもよい。上述した技術は、フロント・エンド・コンポーネントを含む分散コンピューティング・システムにおいて実行することができる。フロント・エンド・コンポーネントとしては、例えば、ＧＵＩ、ユーザーが例示的な実装形態と相互作用することができるウェブ・ブラウザ、及び／又は伝送デバイス用の他のＧＵＩを有するクライアント・コンピュータであってもよい。上述した技術は、前述のバック・エンド、ミドルウェア、又はフロント・エンド・コンポーネントの任意の組合せを含む分散コンピューティング・システムにおいて実行することができる。
【０１２１】
コンピューティング・システムのコンポーネントは、伝送媒体（１１０）によって相互接続することができ、該媒体はデジタル又はアナログデータ通信に関する任意の形態又は媒体を含むことができる（例えば、通信ネットワーク）。伝送媒体（１１０）は、任意の設計において、１以上のパケット・ベースのネットワーク及び／又は１以上の回路・ベースのネットワークを含むことができる。パケット・ベースのネットワークとしては、以下のものを含むことができる：例えば、インターネット、キャリア・インターネット・プロトコル（ＩＰ）ネットワーク（例えば、ローカル・エリア・ネットワーク（ＬＡＮ）、ワイド・エリア・ネットワーク（ＷＡＮ）、キャンパス・エリア・ネットワーク（ＣＡＮ）、メトロポリタン・エリア・ネットワーク（ＭＡＮ），ホーム・エリア・ネットワーク（ＨＡＮ））、プライベートＩＰネットワーク、ＩＰ構内交換機（ＩＰ ｐｒｉｖａｔｅ ｂｒａｎｃｈ ｅｘｃｈａｎｇｅ （ＩＰＢＸ））、ワイヤレス・ネットワーク（例えば、ラジオ・アクセス・ネットワーク（ＲＡＮ）、Ｂｌｕｅｔｏｏｔｈ（登録商標）、Ｗｉ−Ｆｉ（登録商標）、ＷｉＭａｘ（登録商標）、ＧＰＲＳ（ｇｅｎｅｒａｌ ｐａｃｋｅｔ ｒａｄｉｏ ｓｅｒｖｉｃｅ）、ＨｉｐｅｒＬＡＮ）及び／又は他のパケット・ベースのネットワーク。回路ベースのネットワークとしては、例えば以下のものを含むことができる：公衆電話交換回線網（ＰＳＴＮ）、レガシーＰＢＸ、ワイヤレス・ネットワーク（例えば、ＲＡＮ、ＣＤＭＡ（符号分割多重接続）ネットワーク、ＴＤＭＡ（時分割多重接続）ネットワーク、ＧＳＭ（登録商標）ネットワーク）、及び／又は他の回路ベース・ネットワーク。
【０１２２】
伝送媒体（１１０）を介した情報伝達は、１以上の通信プロトコルに基づくことができる。通信プロトコルとしては、例えば以下のものを含めることができる：Ｅｔｈｅｒｎｅｔ（登録商標）プロトコル、インターネット・プロトコル（ＩＰ）、ボイップ（Ｖｏｉｃｅ ｏｖｅｒ ＩＰ （ＶｏＩＰ））、ピア・ツー・ピア・プロトコル（Ｐ２Ｐ）、ハイパーテキスト・ドランスファー・プロトコル (HTTP)、セッション確立プロトコル(SIP)、Ｈ．３２３、メディア・ゲートウェイ・コントロール・プロトコル（ＭＧＣＰ）、シグナリング・システム＃７（ＳＳ７）、ＧＳＭ（登録商標）プロトコル、プッシュ・ツー・トーク（ＰＴＴ）プロトコル、プッシュ・ツー・トーク・オーバー・セルラー（ＰＯＣ）プロトコル、及び／又は他の通信プロトコル。
【０１２３】
コンピューティング・システムの装置としては、例えば以下のものを含めることができる：コンピュータ、ブラウザ・デバイスを備えるコンピュータ、電話、ＩＰ電話、モバイル装置（例えば、携帯電話、ＰＤＡ、ラップトップ・コンピュータ、電子メール装置）、及び／又は他の通信装置。ブラウザ・デバイスとしては、例えば、ＷＷＷブラウザ（例えば、マイクロソフト（登録商標）社が提供しているMicrosoft Internet Explorer（登録商標）、Mozilla社から入手できる Mozilla（登録商標） Firefox）を備えるコンピュータが含まれる。モバイル・コンピューティング・デバイスとしては、例えば、Blackberry（登録商標）を含むことができる。ＩＰ電話としては、シスコシステムから入手できるCisco（登録商標）Unified IP Phone 7985Gや、Cisco Unified Wireless Phone 7920が含まれる。
【０１２４】
本発明の思想及び本質的な特性から乖離することなく他の特的の形態で本発明を実施できることを当業者は理解するであろう。従って、本明細書で記述した本発明に関して、上記実施形態は限定的にではなく全て例示的な観点で考慮すべきものである。よって、本発明の範囲は、上述した内容によってではなく、添付した特許請求の範囲によって表される。そして、前記特許請求の範囲の意味及び均等物の範囲内に入る全ての変更は、本発明の範囲に入ることを意図する。
【特許請求の範囲】
【請求項１】
クライアント・コントロールを介したサーバー過負荷制限を目的とするコンピュータ化した方法であって、以下のステップを含む方法：
サービスに関する複数リクエストの第一セットを第一期間中第一伝送速度でサーバーに伝送するステップ；
第一期間中第一伝送制限速度以下になるよう前記第一伝送速度を制限するステップ；
サービスに関する前記複数リクエストの第一セットのうち少なくとも２以上のリクエストが過負荷基準を満たしているかどうかに基づいて過負荷値を決定するステップ;
前記過負荷値をコンピュータ・メモリ・モジュールに保存するステップ；
前記過負荷値及び前記第一伝送制限速度に基づいて第二伝送制限速度を決定するステップ；
サービスに関する複数リクエストの第二セットを前記第一期間後の第二期間中に第二伝送速度で前記サーバーに伝送するステップ；及び、
前記第二期間中の第二伝送速度を前記第二伝送制限速度以下になるよう制限するステップ。
【請求項２】
請求項１に記載の方法であって、前記過負荷値が目標過負荷値を下回るか上回るかを決定するステップを更に含む方法。
【請求項３】
請求項２に記載の方法であって、前記過負荷値が前記目標過負荷値を超える場合に、前記第二伝送制限速度を決定するステップが、前記過負荷値と前記目標過負荷値との差分に比例する量だけ前記第一伝送制限速度を低下させるステップを含む該方法。
【請求項４】
請求項２に記載の方法であって、前記過負荷値が前記目標過負荷値を超える場合に、前記第二伝送制限速度を決定するステップが、前記過負荷値に比例する量だけ前記第一伝送制限速度を低下させるステップを含む該方法。
【請求項５】
請求項４に記載の方法であって、前記過負荷値が前記過負荷基準を満たすリクエスト速度を表す該方法。
【請求項６】
請求項２に記載の方法であって、前記過負荷値が前記目標過負荷値未満の場合に、前記第二伝送制限速度を決定するステップが前記第一伝送制限速度を速度ステップだけ上昇させるステップを含む該方法。
【請求項７】
請求項６に記載の方法であって、前記速度ステップが固定されている該方法。
【請求項８】
請求項６に記載の方法であって、前記速度ステップが前記第一伝送制限速度に基づく該方法。
【請求項９】
請求項８に記載の方法であって、前記速度ステップの範囲が最大速度ステップ及び最小速度ステップで決定される該方法。
【請求項１０】
請求項１に記載の方法であって、第一層エンティティが前記過負荷値を決定し、第二層エンティティが前記第一伝送速度を制限し、前記第一層エンティティは前記第二層エンティティとは異なる該方法。
【請求項１１】
請求項１０に記載の方法であって、前記第一層エンティティがトランスポート層エンティティを含み、前記第二層エンティティがアプリケーション層エンティティを含む該方法。
【請求項１２】
請求項１に記載の方法であって、前記過負荷基準が明示的な過負荷基準である該方法。
【請求項１３】
請求項１２に記載の方法であって、前記明示的な過負荷基準が単一のリクエストのみに適用される該方法。
【請求項１４】
請求項１２に記載の方法であって、前記明示的な過負荷基準が非スロットリング型クライアント・レスポンスを特定する該方法。
【請求項１５】
請求項１２に記載の方法であって、前記第一セットからのリクエストであって且つサービスを要求する第一リクエストに関する第一拒否メッセージを前記サーバーから受け取った場合、前記第一リクエストが前記明示的な過負荷基準を満たす該方法。
【請求項１６】
請求項１に記載の方法であって、前記過負荷基準が暗黙的な過負荷基準である該方法。
【請求項１７】
請求項１６に記載の方法であって、前記第一セットからのリクエストであって且つサービスを要求する第一リクエストが伝送されてからの経過時間が遅延閾値を超える場合に、前記第一リクエストが前記暗黙的な過負荷基準を満たす該方法。
【請求項１８】
請求項１６に記載の方法であって、ある時間間隔でサービスを要求する未応答のリクエストの割合が割合閾値以上になった場合に、前記暗黙的な過負荷基準を満たす該方法。
【請求項１９】
請求項１６に記載の方法であって、前記暗黙的な過負荷基準がピア・コンジェスションとは無関係の前記サーバーからの１以上の応答メッセージに基づく該方法。
【請求項２０】
請求項１９に記載の方法であって、前記１以上の応答の割合が割合閾値以上になった場合に、前記暗黙的な過負荷基準を満たす該方法。
【請求項２１】
請求項１９に記載の方法であって、前記暗黙的な過負荷基準が、割合閾値以上である前記１以上の応答割合の変化に基づく該方法。
【請求項２２】
請求項１７に記載の方法であって、前記遅延閾値が静的である該方法。
【請求項２３】
請求項１７に記載の方法であって、前記遅延閾値が、前記サーバーに伝送されサービスを要求する１以上の以前のリクエストに対する平均応答時間に基づく該方法。
【請求項２４】
請求項１７に記載の方法であって、前記遅延閾値が、前記サーバーに伝送されサービスを要求する１以上の以前のリクエストに対する百分率の応答時間に基づく該方法。
【請求項２５】
請求項１５又は１６に記載の方法であって、前記第一セットからのリクエストであって且つサービスを要求する前記第一リクエストに対する第一応答を受け取る前に、前記第一セットからのリクエストであって且つサービスを要求する第二リクエストに対する第二応答を受け取るか否かに基づいて、第一リクエストが前記過負荷基準を満たす該方法（ここで、前記第二リクエストは、前記第一リクエストの後に前記サーバーへ伝送される）。
【請求項２６】
請求項１に記載の方法であって、前記過負荷値を決定するステップが、前記過負荷基準を満たす前記第一セットからのリクエスト数を平均化するステップ及び／又はフィルタリングするステップを含む該方法。
【請求項２７】
請求項２６に記載の方法であって、前記過負荷値を決定するステップが、更に、前記第一期間の前の１以上の期間に関連する１以上の以前の過負荷値に基づく該方法。
【請求項２８】
請求項１に記載の方法であって、前記第一期間が前記第二期間とブラインド間隔期間だけ離れている該方法。
【請求項２９】
請求項２８に記載の方法であって、前記ブラインド間隔が固定時間間隔であるか、及び／又は前記サーバーに伝送されサービスを要求する１以上の以前のリクエストに対する平均応答時間に基づく該方法。
【請求項３０】
請求項１に記載の方法であって、前記複数リクエストの第一セットを伝送するステップが、前記１以上のリクエストの伝送について、リクエストの種類に基づいて優先順位を付けるステップを含む該方法。
【請求項３１】
請求項３０に記載の方法であって、前記１以上のリクエストのリクエスト種類が、高優先度、通常、又はこれらの任意の組合せを含む該方法。
【請求項３２】
請求項１に記載の方法であって、前記複数リクエストの第一セット及び第二セットが同一の分類である該方法。
【請求項３３】
請求項１に記載の方法であって、前記複数リクエストの第一セットが第一分類及び第二分類のリクエストを少なくとも含み、前記複数リクエストの第二セットが前記第一分類のリクエストのみからなる該方法。
【請求項３４】
クライアント・コントロールを介したサーバー過負荷制限を目的とするシステムであって、以下を備えるシステム：
サービスを要求する複数リクエストの第一セットを保存するように設計されたバッファ；
前記バッファと接続される伝送機であって、サービスを要求する前記１以上のリクエストを伝送制限速度以下となる伝送速度で第一期間中サーバーに伝送するように設計される伝送機；及び
以下の手段を備えるコントローラ：
サービスに関する前記複数リクエストの第一セットのうち少なくとも２以上のリクエストが過負荷基準を満たしているかどうかに基づいて過負荷値を決定するためのコンピューティング手段；
前記過負荷値及び前記伝送制限速度に基づいて、伝送制限速度を調整するためのコンピューティング手段。
【請求項３５】
コンピュータ・プログラム製品であって、機械読取可能ストレージデバイスで実際に実行され、前記コンピュータ・プログラム製品が、データ処理装置に以下の動作を行わせるために実行可能な指示を含む該プログラム製品：
サービスに関する複数リクエストの第一セットを第一期間中第一伝送速度でサーバーに伝送すること；
前記第一伝送速度を前記第一期間中第一伝送制限速度以下に制限すること；
サービスを要求する前記複数リクエストの第一セットのうち少なくとも２以上のリクエストが過負荷基準を満たしているかどうかに基づいて過負荷値を決定すること；
コンピュータ・メモリ・モジュールに前記過負荷値を保存すること；
前記過負荷値及び前記第一伝送制限速度に基づいて第二伝送制限速度を決定すること；
サービスを要求する複数リクエストの第二セットを前記第一期間後である第二期間中に第二伝送速度で前記サーバーに伝送すること；及び
前記第二期間中前記第二伝送制限速度以下になるように前記第二伝送速度を制限すること。
【請求項３６】
ネットワーク中のサーバー過負荷を制限するためのコンピュータ化された方法であって、以下のステップを含む方法：
ネットワークのサーバー・ノードが下流サーバーからのフィードバック・メッセージを受け取るステップ（ここで前記フィードバック・メッセージは通信プロトコルの統計情報を含む）；
コンピュータ・メモリ・モジュールに保存されたカウンター配列からの１以上のカウンターのうちどのカウンターが前記下流サーバーと関連しているかを、前記フィードバック・メッセージ中に含まれる情報に基づき１以上のハッシュ関数を用いて前記サーバー・ノードが決定するステップ（ここで、前記１以上のカウンターは、前記統計情報を含み且つ前記下流サーバーから受け取ったフィードバック・メッセージ数に対応する数を保存する）；
前記統計情報を含む前記フィードバック・メッセージに応答して、前記サーバー・ノードが前記１以上のカウンターを増加させるステップ；
前記１以上のカウンター内に保存された数の値を前記１以上のハッシュ関数を用いて前記サーバー・ノードが決定するステップ；及び
前記値が所定の基準を満たすかどうかに基づいて、前記下流サーバーに関する前記ネットワーク内の過負荷エピソードを前記値が表すことを、前記サーバー・ノードが決定するステップ。
【請求項３７】
請求項３６に記載の方法であって、前記所定の基準が閾値であり、且つ前記決定するステップが、前記値が前記閾値を超えている事を決定するステップを含む該方法。
【請求項３８】
請求項３７に記載の方法であって、前記閾値をヒステレシスを用いて計算する該方法。
【請求項３９】
請求項３６に記載の方法であって、前記過負荷エピソードの誘発を担う１以上のソースを特定するステップを更に含む該方法（ここで各ソ−スは、前記統計情報を含むフィードバック・メッセージを前記下流サーバーに伝送させる前記下流サーバーへの伝送を初期化する）。
【請求項４０】
請求項３６に記載の方法であって、前記値に基づくコントロール動作を行うための１以上のコントロール・パラメータを決定するステップを更に含む該方法（ここで前記コントロール動作は、前記下流サーバーに対する前記過負荷エピソードの誘発を担う１以上のソースからのデータに関する伝送速度を減少させる）。
【請求項４１】
請求項４０に記載の方法であって、更に以下のステップを含む該方法：
前記過負荷エピソードの誘発を担うソースと前記下流サーバーとの間のサーバー・ノードへ、前記１以上のコントロール・パラメータを伝送するステップ；及び
前記ソースから前記下流サーバーへ伝送されるデータに関する伝送速度を減少させることにより、前記ソースから前記下流サーバーへの伝送データに関する前記サーバー・ノードでの前記コントロール動作を行うステップ（ここで、前記速度減少は前記１以上のコントロール・パラメータに基づいて行われる）。
【請求項４２】
請求項４０に記載の方法であって、前記伝送速度が、前記過負荷エピソードの誘発を担う１以上のソースから前記下流サーバーへのコール・アテンプト速度である該方法。
【請求項４３】
請求項４０に記載の方法であって、前記１以上のコントロール・パラメータを決定するステップが以下のステップを含む該方法：
前記コントロール動作をどこで行うべきかを特定する動作位置を決定するステップ；
前記動作位置で前記コントロール動作を適用する対象となる１以上のソースを定義する動作フィルターを決定するステップ；及び、
前記コントロール動作に関する動作レベルを決定するステップ。
【請求項４４】
請求項４３に記載の方法であって、前記動作レベルを決定するステップが以下のステップを含む該方法：
前記値が所定の閾値を超えるかどうかを決定するステップ；及び
前記値が前記所定の閾値を超える場合、前記動作レベルについて、減少因子を用いて以前の動作レベルから減少させることを決定するステップ；又は、
前記値が前記所定の閾値未満の場合、前記動作レベルについて、増加ステップを用いて以前の前記動作レベルから増加させることを決定するステップ。
【請求項４５】
請求項４４に記載の方法であって、前記閾値をヒステレシスを用いて計算する該方法。
【請求項４６】
請求項４４に記載の方法であって、決定するステップが以下のステップを含む該方法：
前記値が所定の目標値と等しいかどうかを決定するステップ；並びに、
もし前記値が前記所定の目標値と等しい場合には、前記動作レベルを変更しないステップ；又は、
もし前記値が前記所定の目標値と等しくない場合には、前記値と前記所定の目標値との差異及び以前の動作レベルに基づいて前記動作レベルを決定するステップ。
【請求項４７】
請求項４４に記載の方法であって、前記１以上のコントロール・パラメータを前記動作位置に配信するステップを更に含む該方法。
【請求項４８】
請求項３６に記載の方法であって、更に以下のステップを含む該方法：
第二フィードバック・メッセージを第二下流サーバーから受け取るステップ（ここで前記 第二フィードバック・メッセージは前記統計情報を含む）；
前記第二フィードバック・メッセージ中に含まれる情報に基づき１以上のハッシュ関数を用いて、カウンター配列からの１以上のカンウターのうちのどれが前記第二下流サーバーと関連しているかを決定するステップ；及び、
前記統計情報を含む前記第二フィードバック・メッセージに応答して前記１以上のカウンターを増加させるステップ。
【請求項４９】
請求項３６に記載の方法であって、更に以下のステップを含む該方法：
複数のカウンター配列を保存するステップ（ここで前記複数のカウンター配列それぞれは、異なるサーバー・ノードに保存されている）；及び
複数のサーバー・ノードに跨る前記複数のカウンター配列に関連する各下流サーバーから受け取ったフィードバック・メッセージの数を計算するために前記複数のカウンター配列を集計するステップ。
【請求項５０】
請求項３６に記載の方法であって、前記通信プロトコルがセッション確立プロトコル (Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ、ＳＩＰ）であり；及び
前記統計情報がセッション拒否、前記下流サーバーからの過負荷フィードバック又はその両方である該方法。
【請求項５１】
請求項３６に記載の方法であって、前記通信プロトコルがセッション確立プロトコル、ハイパーテキスト・ドランスファー・プロトコル（ＨＴＴＰ）、ストリーム制御転送プロトコル（ＳＣＴＰ）、又はＴＣＰプロトコル（ｔｒａｎｓｍｉｓｓｉｏｎ ｃｏｎｔｒｏｌ ｐｒｏｔｏｃｏｌ）である該方法。
【請求項５２】
請求項３６に記載の方法であって、前記１以上のハッシュ関数及び前記カウンター配列がカウンティング・ブルーム・フィルターに関連する該方法。
【請求項５３】
請求項５２に記載の方法であって、１以上のカウンターのうちどれが前記下流サーバーに関連するかについて決定することが、キーに関連するハッシュ関数を用いて前記１以上のカウンターを決定することを含み、前記キーは前記下流サーバーに関する識別子である該方法。
【請求項５４】
請求項３６に記載の方法であって、前記増加させるステップが以下のステップを含む該方法：
前記１以上のカウンターを１ずつ増加させるステップ；又は、
前記１以上のカウンターを１を超える数で増加させるステップ（ここで、前記１を超える数は以下に基づいて決定される：前記統計情報；一定期間、前記下流サーバーから受け取る統計情報；複数の一定期間、前記下流サーバーから受け取る統計情報；ソースから前記下流サーバーへ行われる伝送の種類；又はこれらの任意の組合せ）。
【請求項５５】
請求項３６に記載の方法であって、ブルーム・フィルターに基づくマルチ・レベルな閾値を動作位置に配信するステップを更に含む該方法
（ここで前記ブルーム・フィルターに基づくマルチ・レベルな閾値は、以下を保存する：
複数の閾値(ここで前記複数の各閾値は、前記通信プロトコルに関するコール・リクエストと関連する複数のクラスからの１つのクラスに対応する)；及び、
１以上のハッシュ関数を用いた前記複数の各クラスに関する、前記下流サーバーに対するコール・リクエストのカウント）。
【請求項５６】
請求項５５に記載の方法であって、以下のステップを含む該方法：
ソースから前記下流サーバーへのコール・リクエスト・メッセージを受け取るステップ（前記コール・リクエスト・メッセージは、前記複数のクラスのうち１つのクラスを含む）；
前記ブルーム・フィルターに基づくマルチ・レベルな閾値を用いて、以下を決定するステップ：
（１）前記コール・リクエスト・メッセージ中の前記クラスに関する閾値；及び、
（２）前記１以上のハッシュ関数を用いて、ブルーム・フィルターに基づく前記コール・リクエスト・メッセージ中の前記クラスに関する、前記下流サーバーへのコール・リクエストのカウント；並びに、
もし、前記コール・リクエストのカウントが前記閾値を超える場合、前記コール・リクエスト・メッセージを拒否するステップ；又は
もし、前記コール・リクエストのカウントが前記閾値未満の場合、前記コール・リクエスト・メッセージを受け入れるステップ。
【請求項５７】
請求項３６に記載の方法であって、前記統計情報が：ソースから前記下流サーバーへの失敗した接続リクエスト；前記下流サーバーからの過負荷通知；又はこれら両方である該方法。
【請求項５８】
ネットワーク中のサーバー過負荷を制限するためのシステムであって、以下を備える該システム：
カウンター配列を保存するように設計されるコンピュータ・メモリ・モジュール；及び
前記コンピュータ・メモリ・モジュールと通信し、以下の手段を備えるコントローラ：
下流サーバーからフィードバック・メッセージを受け取るためのコンピューティング手段（ここで前記フィードバック・メッセージは通信プロトコルの統計情報を含む）；
前記カウンター配列からの１以上のカウンターのうちのどれが前記下流サーバーに関連するかについて、１以上のハッシュ関数を用い、前記フィードバック・メッセージ中に含まれる情報に基づいて決定するためのコンピューティング手段（ここで前記１以上のカウンターは、前記下流サーバーから受け取り、且つ前記統計情報を含むフィードバック・メッセージの数に対応する数を保存する）；
前記統計情報を含む前記フィードバック・メッセージに応答して前記１以上のカウンターを増加させるためのコンピューティング手段；
前記１以上のカウンターに保存される数の値を前記１以上のハッシュ関数を用いて決定するためのコンピューティング手段；及び、
前記値が所定の基準を満たすかどうかに基づいて、前記下流サーバーが関連する前記ネットワーク中の過負荷エピソードを前記値が表すことを決定するためのコンピューティング手段。
【請求項５９】
コンピュータ・プログラム製品であって、機械読取可能ストレージデバイスで実際に実行され、前記コンピュータ・プログラム製品が、データ処理装置に以下の動作を行わせるために実行可能な指示を含む該プログラム製品：
下流サーバーからのフィードバック・メッセージを受け取ること（ここで前記フィードバック・メッセージは通信プロトコルの統計情報を含む）；
コンピュータ・メモリ・モジュールに保存されたカウンター配列からの１以上のカウンターのうちのどれが前記下流サーバーと関連するかを、前記フィードバック・メッセージ中に含まれる情報に基づき、１以上のハッシュ関数を用いて決定すること（ここで前記１以上のカウンターは、前記下流サーバーから受け取とり、且つ前記統計情報を含むフィードバック・メッセージの数に対応する数を保存する）；
前記統計情報を含む前記フィードバック・メッセージに応答して前記１以上のカウンターを増加させること；
前記１以上のカウンターに保存される数の値を前記１以上のハッシュ関数を用いて決定すること；及び、
前記値が所定の基準を満たすかどうかに基づいて、前記下流サーバーが関連する前記ネットワーク中の過負荷エピソードを前記値が表すことを決定すること。
【請求項１】
クライアント・コントロールを介したサーバー過負荷制限を目的とするコンピュータ化した方法であって、以下のステップを含む方法：
サービスに関する複数リクエストの第一セットを第一期間中第一伝送速度でサーバーに伝送するステップ；
第一期間中第一伝送制限速度以下になるよう前記第一伝送速度を制限するステップ；
サービスに関する前記複数リクエストの第一セットのうち少なくとも２以上のリクエストが過負荷基準を満たしているかどうかに基づいて過負荷値を決定するステップ;
前記過負荷値をコンピュータ・メモリ・モジュールに保存するステップ；
前記過負荷値及び前記第一伝送制限速度に基づいて第二伝送制限速度を決定するステップ；
サービスに関する複数リクエストの第二セットを前記第一期間後の第二期間中に第二伝送速度で前記サーバーに伝送するステップ；及び、
前記第二期間中の第二伝送速度を前記第二伝送制限速度以下になるよう制限するステップ。
【請求項２】
請求項１に記載の方法であって、前記過負荷値が目標過負荷値を下回るか上回るかを決定するステップを更に含む方法。
【請求項３】
請求項２に記載の方法であって、前記過負荷値が前記目標過負荷値を超える場合に、前記第二伝送制限速度を決定するステップが、前記過負荷値と前記目標過負荷値との差分に比例する量だけ前記第一伝送制限速度を低下させるステップを含む該方法。
【請求項４】
請求項２に記載の方法であって、前記過負荷値が前記目標過負荷値を超える場合に、前記第二伝送制限速度を決定するステップが、前記過負荷値に比例する量だけ前記第一伝送制限速度を低下させるステップを含む該方法。
【請求項５】
請求項４に記載の方法であって、前記過負荷値が前記過負荷基準を満たすリクエスト速度を表す該方法。
【請求項６】
請求項２に記載の方法であって、前記過負荷値が前記目標過負荷値未満の場合に、前記第二伝送制限速度を決定するステップが前記第一伝送制限速度を速度ステップだけ上昇させるステップを含む該方法。
【請求項７】
請求項６に記載の方法であって、前記速度ステップが固定されている該方法。
【請求項８】
請求項６に記載の方法であって、前記速度ステップが前記第一伝送制限速度に基づく該方法。
【請求項９】
請求項８に記載の方法であって、前記速度ステップの範囲が最大速度ステップ及び最小速度ステップで決定される該方法。
【請求項１０】
請求項１に記載の方法であって、第一層エンティティが前記過負荷値を決定し、第二層エンティティが前記第一伝送速度を制限し、前記第一層エンティティは前記第二層エンティティとは異なる該方法。
【請求項１１】
請求項１０に記載の方法であって、前記第一層エンティティがトランスポート層エンティティを含み、前記第二層エンティティがアプリケーション層エンティティを含む該方法。
【請求項１２】
請求項１に記載の方法であって、前記過負荷基準が明示的な過負荷基準である該方法。
【請求項１３】
請求項１２に記載の方法であって、前記明示的な過負荷基準が単一のリクエストのみに適用される該方法。
【請求項１４】
請求項１２に記載の方法であって、前記明示的な過負荷基準が非スロットリング型クライアント・レスポンスを特定する該方法。
【請求項１５】
請求項１２に記載の方法であって、前記第一セットからのリクエストであって且つサービスを要求する第一リクエストに関する第一拒否メッセージを前記サーバーから受け取った場合、前記第一リクエストが前記明示的な過負荷基準を満たす該方法。
【請求項１６】
請求項１に記載の方法であって、前記過負荷基準が暗黙的な過負荷基準である該方法。
【請求項１７】
請求項１６に記載の方法であって、前記第一セットからのリクエストであって且つサービスを要求する第一リクエストが伝送されてからの経過時間が遅延閾値を超える場合に、前記第一リクエストが前記暗黙的な過負荷基準を満たす該方法。
【請求項１８】
請求項１６に記載の方法であって、ある時間間隔でサービスを要求する未応答のリクエストの割合が割合閾値以上になった場合に、前記暗黙的な過負荷基準を満たす該方法。
【請求項１９】
請求項１６に記載の方法であって、前記暗黙的な過負荷基準がピア・コンジェスションとは無関係の前記サーバーからの１以上の応答メッセージに基づく該方法。
【請求項２０】
請求項１９に記載の方法であって、前記１以上の応答の割合が割合閾値以上になった場合に、前記暗黙的な過負荷基準を満たす該方法。
【請求項２１】
請求項１９に記載の方法であって、前記暗黙的な過負荷基準が、割合閾値以上である前記１以上の応答割合の変化に基づく該方法。
【請求項２２】
請求項１７に記載の方法であって、前記遅延閾値が静的である該方法。
【請求項２３】
請求項１７に記載の方法であって、前記遅延閾値が、前記サーバーに伝送されサービスを要求する１以上の以前のリクエストに対する平均応答時間に基づく該方法。
【請求項２４】
請求項１７に記載の方法であって、前記遅延閾値が、前記サーバーに伝送されサービスを要求する１以上の以前のリクエストに対する百分率の応答時間に基づく該方法。
【請求項２５】
請求項１５又は１６に記載の方法であって、前記第一セットからのリクエストであって且つサービスを要求する前記第一リクエストに対する第一応答を受け取る前に、前記第一セットからのリクエストであって且つサービスを要求する第二リクエストに対する第二応答を受け取るか否かに基づいて、第一リクエストが前記過負荷基準を満たす該方法（ここで、前記第二リクエストは、前記第一リクエストの後に前記サーバーへ伝送される）。
【請求項２６】
請求項１に記載の方法であって、前記過負荷値を決定するステップが、前記過負荷基準を満たす前記第一セットからのリクエスト数を平均化するステップ及び／又はフィルタリングするステップを含む該方法。
【請求項２７】
請求項２６に記載の方法であって、前記過負荷値を決定するステップが、更に、前記第一期間の前の１以上の期間に関連する１以上の以前の過負荷値に基づく該方法。
【請求項２８】
請求項１に記載の方法であって、前記第一期間が前記第二期間とブラインド間隔期間だけ離れている該方法。
【請求項２９】
請求項２８に記載の方法であって、前記ブラインド間隔が固定時間間隔であるか、及び／又は前記サーバーに伝送されサービスを要求する１以上の以前のリクエストに対する平均応答時間に基づく該方法。
【請求項３０】
請求項１に記載の方法であって、前記複数リクエストの第一セットを伝送するステップが、前記１以上のリクエストの伝送について、リクエストの種類に基づいて優先順位を付けるステップを含む該方法。
【請求項３１】
請求項３０に記載の方法であって、前記１以上のリクエストのリクエスト種類が、高優先度、通常、又はこれらの任意の組合せを含む該方法。
【請求項３２】
請求項１に記載の方法であって、前記複数リクエストの第一セット及び第二セットが同一の分類である該方法。
【請求項３３】
請求項１に記載の方法であって、前記複数リクエストの第一セットが第一分類及び第二分類のリクエストを少なくとも含み、前記複数リクエストの第二セットが前記第一分類のリクエストのみからなる該方法。
【請求項３４】
クライアント・コントロールを介したサーバー過負荷制限を目的とするシステムであって、以下を備えるシステム：
サービスを要求する複数リクエストの第一セットを保存するように設計されたバッファ；
前記バッファと接続される伝送機であって、サービスを要求する前記１以上のリクエストを伝送制限速度以下となる伝送速度で第一期間中サーバーに伝送するように設計される伝送機；及び
以下の手段を備えるコントローラ：
サービスに関する前記複数リクエストの第一セットのうち少なくとも２以上のリクエストが過負荷基準を満たしているかどうかに基づいて過負荷値を決定するためのコンピューティング手段；
前記過負荷値及び前記伝送制限速度に基づいて、伝送制限速度を調整するためのコンピューティング手段。
【請求項３５】
コンピュータ・プログラム製品であって、機械読取可能ストレージデバイスで実際に実行され、前記コンピュータ・プログラム製品が、データ処理装置に以下の動作を行わせるために実行可能な指示を含む該プログラム製品：
サービスに関する複数リクエストの第一セットを第一期間中第一伝送速度でサーバーに伝送すること；
前記第一伝送速度を前記第一期間中第一伝送制限速度以下に制限すること；
サービスを要求する前記複数リクエストの第一セットのうち少なくとも２以上のリクエストが過負荷基準を満たしているかどうかに基づいて過負荷値を決定すること；
コンピュータ・メモリ・モジュールに前記過負荷値を保存すること；
前記過負荷値及び前記第一伝送制限速度に基づいて第二伝送制限速度を決定すること；
サービスを要求する複数リクエストの第二セットを前記第一期間後である第二期間中に第二伝送速度で前記サーバーに伝送すること；及び
前記第二期間中前記第二伝送制限速度以下になるように前記第二伝送速度を制限すること。
【請求項３６】
ネットワーク中のサーバー過負荷を制限するためのコンピュータ化された方法であって、以下のステップを含む方法：
ネットワークのサーバー・ノードが下流サーバーからのフィードバック・メッセージを受け取るステップ（ここで前記フィードバック・メッセージは通信プロトコルの統計情報を含む）；
コンピュータ・メモリ・モジュールに保存されたカウンター配列からの１以上のカウンターのうちどのカウンターが前記下流サーバーと関連しているかを、前記フィードバック・メッセージ中に含まれる情報に基づき１以上のハッシュ関数を用いて前記サーバー・ノードが決定するステップ（ここで、前記１以上のカウンターは、前記統計情報を含み且つ前記下流サーバーから受け取ったフィードバック・メッセージ数に対応する数を保存する）；
前記統計情報を含む前記フィードバック・メッセージに応答して、前記サーバー・ノードが前記１以上のカウンターを増加させるステップ；
前記１以上のカウンター内に保存された数の値を前記１以上のハッシュ関数を用いて前記サーバー・ノードが決定するステップ；及び
前記値が所定の基準を満たすかどうかに基づいて、前記下流サーバーに関する前記ネットワーク内の過負荷エピソードを前記値が表すことを、前記サーバー・ノードが決定するステップ。
【請求項３７】
請求項３６に記載の方法であって、前記所定の基準が閾値であり、且つ前記決定するステップが、前記値が前記閾値を超えている事を決定するステップを含む該方法。
【請求項３８】
請求項３７に記載の方法であって、前記閾値をヒステレシスを用いて計算する該方法。
【請求項３９】
請求項３６に記載の方法であって、前記過負荷エピソードの誘発を担う１以上のソースを特定するステップを更に含む該方法（ここで各ソ−スは、前記統計情報を含むフィードバック・メッセージを前記下流サーバーに伝送させる前記下流サーバーへの伝送を初期化する）。
【請求項４０】
請求項３６に記載の方法であって、前記値に基づくコントロール動作を行うための１以上のコントロール・パラメータを決定するステップを更に含む該方法（ここで前記コントロール動作は、前記下流サーバーに対する前記過負荷エピソードの誘発を担う１以上のソースからのデータに関する伝送速度を減少させる）。
【請求項４１】
請求項４０に記載の方法であって、更に以下のステップを含む該方法：
前記過負荷エピソードの誘発を担うソースと前記下流サーバーとの間のサーバー・ノードへ、前記１以上のコントロール・パラメータを伝送するステップ；及び
前記ソースから前記下流サーバーへ伝送されるデータに関する伝送速度を減少させることにより、前記ソースから前記下流サーバーへの伝送データに関する前記サーバー・ノードでの前記コントロール動作を行うステップ（ここで、前記速度減少は前記１以上のコントロール・パラメータに基づいて行われる）。
【請求項４２】
請求項４０に記載の方法であって、前記伝送速度が、前記過負荷エピソードの誘発を担う１以上のソースから前記下流サーバーへのコール・アテンプト速度である該方法。
【請求項４３】
請求項４０に記載の方法であって、前記１以上のコントロール・パラメータを決定するステップが以下のステップを含む該方法：
前記コントロール動作をどこで行うべきかを特定する動作位置を決定するステップ；
前記動作位置で前記コントロール動作を適用する対象となる１以上のソースを定義する動作フィルターを決定するステップ；及び、
前記コントロール動作に関する動作レベルを決定するステップ。
【請求項４４】
請求項４３に記載の方法であって、前記動作レベルを決定するステップが以下のステップを含む該方法：
前記値が所定の閾値を超えるかどうかを決定するステップ；及び
前記値が前記所定の閾値を超える場合、前記動作レベルについて、減少因子を用いて以前の動作レベルから減少させることを決定するステップ；又は、
前記値が前記所定の閾値未満の場合、前記動作レベルについて、増加ステップを用いて以前の前記動作レベルから増加させることを決定するステップ。
【請求項４５】
請求項４４に記載の方法であって、前記閾値をヒステレシスを用いて計算する該方法。
【請求項４６】
請求項４４に記載の方法であって、決定するステップが以下のステップを含む該方法：
前記値が所定の目標値と等しいかどうかを決定するステップ；並びに、
もし前記値が前記所定の目標値と等しい場合には、前記動作レベルを変更しないステップ；又は、
もし前記値が前記所定の目標値と等しくない場合には、前記値と前記所定の目標値との差異及び以前の動作レベルに基づいて前記動作レベルを決定するステップ。
【請求項４７】
請求項４４に記載の方法であって、前記１以上のコントロール・パラメータを前記動作位置に配信するステップを更に含む該方法。
【請求項４８】
請求項３６に記載の方法であって、更に以下のステップを含む該方法：
第二フィードバック・メッセージを第二下流サーバーから受け取るステップ（ここで前記 第二フィードバック・メッセージは前記統計情報を含む）；
前記第二フィードバック・メッセージ中に含まれる情報に基づき１以上のハッシュ関数を用いて、カウンター配列からの１以上のカンウターのうちのどれが前記第二下流サーバーと関連しているかを決定するステップ；及び、
前記統計情報を含む前記第二フィードバック・メッセージに応答して前記１以上のカウンターを増加させるステップ。
【請求項４９】
請求項３６に記載の方法であって、更に以下のステップを含む該方法：
複数のカウンター配列を保存するステップ（ここで前記複数のカウンター配列それぞれは、異なるサーバー・ノードに保存されている）；及び
複数のサーバー・ノードに跨る前記複数のカウンター配列に関連する各下流サーバーから受け取ったフィードバック・メッセージの数を計算するために前記複数のカウンター配列を集計するステップ。
【請求項５０】
請求項３６に記載の方法であって、前記通信プロトコルがセッション確立プロトコル (Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ、ＳＩＰ）であり；及び
前記統計情報がセッション拒否、前記下流サーバーからの過負荷フィードバック又はその両方である該方法。
【請求項５１】
請求項３６に記載の方法であって、前記通信プロトコルがセッション確立プロトコル、ハイパーテキスト・ドランスファー・プロトコル（ＨＴＴＰ）、ストリーム制御転送プロトコル（ＳＣＴＰ）、又はＴＣＰプロトコル（ｔｒａｎｓｍｉｓｓｉｏｎ ｃｏｎｔｒｏｌ ｐｒｏｔｏｃｏｌ）である該方法。
【請求項５２】
請求項３６に記載の方法であって、前記１以上のハッシュ関数及び前記カウンター配列がカウンティング・ブルーム・フィルターに関連する該方法。
【請求項５３】
請求項５２に記載の方法であって、１以上のカウンターのうちどれが前記下流サーバーに関連するかについて決定することが、キーに関連するハッシュ関数を用いて前記１以上のカウンターを決定することを含み、前記キーは前記下流サーバーに関する識別子である該方法。
【請求項５４】
請求項３６に記載の方法であって、前記増加させるステップが以下のステップを含む該方法：
前記１以上のカウンターを１ずつ増加させるステップ；又は、
前記１以上のカウンターを１を超える数で増加させるステップ（ここで、前記１を超える数は以下に基づいて決定される：前記統計情報；一定期間、前記下流サーバーから受け取る統計情報；複数の一定期間、前記下流サーバーから受け取る統計情報；ソースから前記下流サーバーへ行われる伝送の種類；又はこれらの任意の組合せ）。
【請求項５５】
請求項３６に記載の方法であって、ブルーム・フィルターに基づくマルチ・レベルな閾値を動作位置に配信するステップを更に含む該方法
（ここで前記ブルーム・フィルターに基づくマルチ・レベルな閾値は、以下を保存する：
複数の閾値(ここで前記複数の各閾値は、前記通信プロトコルに関するコール・リクエストと関連する複数のクラスからの１つのクラスに対応する)；及び、
１以上のハッシュ関数を用いた前記複数の各クラスに関する、前記下流サーバーに対するコール・リクエストのカウント）。
【請求項５６】
請求項５５に記載の方法であって、以下のステップを含む該方法：
ソースから前記下流サーバーへのコール・リクエスト・メッセージを受け取るステップ（前記コール・リクエスト・メッセージは、前記複数のクラスのうち１つのクラスを含む）；
前記ブルーム・フィルターに基づくマルチ・レベルな閾値を用いて、以下を決定するステップ：
（１）前記コール・リクエスト・メッセージ中の前記クラスに関する閾値；及び、
（２）前記１以上のハッシュ関数を用いて、ブルーム・フィルターに基づく前記コール・リクエスト・メッセージ中の前記クラスに関する、前記下流サーバーへのコール・リクエストのカウント；並びに、
もし、前記コール・リクエストのカウントが前記閾値を超える場合、前記コール・リクエスト・メッセージを拒否するステップ；又は
もし、前記コール・リクエストのカウントが前記閾値未満の場合、前記コール・リクエスト・メッセージを受け入れるステップ。
【請求項５７】
請求項３６に記載の方法であって、前記統計情報が：ソースから前記下流サーバーへの失敗した接続リクエスト；前記下流サーバーからの過負荷通知；又はこれら両方である該方法。
【請求項５８】
ネットワーク中のサーバー過負荷を制限するためのシステムであって、以下を備える該システム：
カウンター配列を保存するように設計されるコンピュータ・メモリ・モジュール；及び
前記コンピュータ・メモリ・モジュールと通信し、以下の手段を備えるコントローラ：
下流サーバーからフィードバック・メッセージを受け取るためのコンピューティング手段（ここで前記フィードバック・メッセージは通信プロトコルの統計情報を含む）；
前記カウンター配列からの１以上のカウンターのうちのどれが前記下流サーバーに関連するかについて、１以上のハッシュ関数を用い、前記フィードバック・メッセージ中に含まれる情報に基づいて決定するためのコンピューティング手段（ここで前記１以上のカウンターは、前記下流サーバーから受け取り、且つ前記統計情報を含むフィードバック・メッセージの数に対応する数を保存する）；
前記統計情報を含む前記フィードバック・メッセージに応答して前記１以上のカウンターを増加させるためのコンピューティング手段；
前記１以上のカウンターに保存される数の値を前記１以上のハッシュ関数を用いて決定するためのコンピューティング手段；及び、
前記値が所定の基準を満たすかどうかに基づいて、前記下流サーバーが関連する前記ネットワーク中の過負荷エピソードを前記値が表すことを決定するためのコンピューティング手段。
【請求項５９】
コンピュータ・プログラム製品であって、機械読取可能ストレージデバイスで実際に実行され、前記コンピュータ・プログラム製品が、データ処理装置に以下の動作を行わせるために実行可能な指示を含む該プログラム製品：
下流サーバーからのフィードバック・メッセージを受け取ること（ここで前記フィードバック・メッセージは通信プロトコルの統計情報を含む）；
コンピュータ・メモリ・モジュールに保存されたカウンター配列からの１以上のカウンターのうちのどれが前記下流サーバーと関連するかを、前記フィードバック・メッセージ中に含まれる情報に基づき、１以上のハッシュ関数を用いて決定すること（ここで前記１以上のカウンターは、前記下流サーバーから受け取とり、且つ前記統計情報を含むフィードバック・メッセージの数に対応する数を保存する）；
前記統計情報を含む前記フィードバック・メッセージに応答して前記１以上のカウンターを増加させること；
前記１以上のカウンターに保存される数の値を前記１以上のハッシュ関数を用いて決定すること；及び、
前記値が所定の基準を満たすかどうかに基づいて、前記下流サーバーが関連する前記ネットワーク中の過負荷エピソードを前記値が表すことを決定すること。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２Ａ】
【図１２Ｂ】
【図１２Ｃ】
【図１３】
【図１４Ａ】
【図１４Ｂ】
【図１５】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２Ａ】
【図１２Ｂ】
【図１２Ｃ】
【図１３】
【図１４Ａ】
【図１４Ｂ】
【図１５】
【公表番号】特表２０１２−５２５７８０（Ｐ２０１２−５２５７８０Ａ）
【公表日】平成２４年１０月２２日（２０１２．１０．２２）
【国際特許分類】
【出願番号】特願２０１２−５０８５８９（Ｐ２０１２−５０８５８９）
【出願日】平成２２年４月２７日（２０１０．４．２７）
【国際出願番号】ＰＣＴ／ＵＳ２０１０／０３２５６３
【国際公開番号】ＷＯ２０１０／１２９２７５
【国際公開日】平成２２年１１月１１日（２０１０．１１．１１）
【出願人】（５０５２８５７５５）ソーナス ネットワークス， インコーポレイテッド (10)
【住所又は居所原語表記】４ Ｔｅｃｈｎｏｌｏｇｙ Ｐａｒｋ Ｄｒｉｖｅ，Ｗｅｓｔｆｏｒｄ，ＭＡ ０１８８６ Ｕ．Ｓ．Ａ．
【Ｆターム（参考）】
【公表日】平成２４年１０月２２日（２０１２．１０．２２）
【国際特許分類】
【出願日】平成２２年４月２７日（２０１０．４．２７）
【国際出願番号】ＰＣＴ／ＵＳ２０１０／０３２５６３
【国際公開番号】ＷＯ２０１０／１２９２７５
【国際公開日】平成２２年１１月１１日（２０１０．１１．１１）
【出願人】（５０５２８５７５５）ソーナス ネットワークス， インコーポレイテッド (10)
【住所又は居所原語表記】４ Ｔｅｃｈｎｏｌｏｇｙ Ｐａｒｋ Ｄｒｉｖｅ，Ｗｅｓｔｆｏｒｄ，ＭＡ ０１８８６ Ｕ．Ｓ．Ａ．
【Ｆターム（参考）】
[ Back to top ]