JP5242773B2

JP5242773B2 - ダイアメータアプリケーションに基づいて、エンドツーエンド過負荷を制御するための方法およびネットワーク要素

Info

Publication number: JP5242773B2
Application number: JP2011508785A
Authority: JP
Inventors: チエン，シユイ; ニウ，ヨンボー; ホワン，ハイホイ
Original assignee: アルカテル−ルーセントユーエスエーインコーポレーテッド
Priority date: 2008-05-15
Filing date: 2008-05-15
Publication date: 2013-07-24
Anticipated expiration: 2028-05-15
Also published as: US20110061061A1; WO2009137956A1; EP2280520A4; KR20110014209A; EP2280520A1; KR101440670B1; JP2011521334A; CN102027725A

Description

本発明は、通信分野に関し、より詳細には、ダイアメータ（Ｄｉａｍｅｔｅｒ）アプリケーションに関するエンドツーエンド過負荷を制御するための方法、およびその方法を実装するためのネットワーク要素に関する。

ＲＦＣ３５８８において画定されるダイアメータベースプロトコルは、ネットワークアクセスサービスまたはＩＰモビリティなどのアプリケーションに関する認証、許可および課金（ＡＡＡ）フレームワークを提供することが意図される。現在のダイアメータ標準文書は、すべてのダイアメータアプリケーションによって使用されることになるメッセージフォーマット、トランスポート、誤り報告、課金、およびセキュリティサービスを指定する。プロトコル要素は、いくつかのコマンドおよびＡＶＰ（属性値対）からなり、クライアント、プロキシ、およびサーバの間で認証、許可および課金情報を通信することが可能である。しかし、クライアント、プロキシ、またはサーバのうちのいずれかは、自発的にセッション要求を送信することが可能であり、相手側は応答を提示することになり、したがって、このプロトコルは、ピア間エンティティプロトコル（ｉｎｔｅｒ−ｐｅｅｒｅｎｔｉｔｙｐｒｏｔｏｃｏｌ）とも呼ばれる。コマンドコード、ＡＶＰ値、およびＡＶＰクラスは、アプリケーション要件およびアプリケーション規則に従って拡張されることが可能である。

ますます多くの標準、仕様、およびＩＰ製品が、ＡＡＡ、ならびにＴＩＳＡＰＮ標準、３ＧＰＰ標準、および３ＧＰＰ２標準で画定された、ＩＰＱｏＳ制御サブシステム、次世代ネットワーク（ＮＧＮ）、ＩＰマルチメディアサブシステム（ＩＭＳ）などのＩＰネットワーク内のその他の制御プロトコルとして、ダイアメータを使用している。ダイアメータは、異なる要素間のインターフェース向けの最も人気のあるプロトコルである。

ダイアメータは比較的新しいプロトコルであるため、エンドツーエンドダイアメータアプリケーションの過負荷制御に関する既存の方法はまだ存在しない。過負荷制御は、容量、パフォーマンス、および信頼性に関する、製品の主な機能性のうちの１つであるため、これはダイアメータプロトコルの大きな弱点である。

上記の欠点を克服するために、本発明は、ダイアメータアプリケーションおよびダイアメータプロトコルを使用している製品に十分なエンドツーエンド過負荷制御を提供する。本発明により、過負荷が発生したとき、両側が現在の重要なダイアメータセッションを保護するための処置を取ることが可能であり、かつ過負荷状態を迅速に標準状態に戻すことが可能であるように、ダイアメータアプリケーション（サーバ／クライアント）は、その負荷状態についてその遠端ダイアメータアプリケーションに伝えて、過負荷制御要求を送信することが可能である。

このために、本発明は、
第１のアプリケーションが過負荷であるとき、過負荷制御情報が設定されて、第２のアプリケーションに送信されることと、
第２のアプリケーションが、その過負荷制御情報に従って処置を取ることとを含む、ダイアメータプロトコルに基づいて、第１のアプリケーションと第２のアプリケーションとの間の過負荷を制御するための方法を提案する。

本発明の一実施形態によれば、過負荷制御情報は、ダイアメータ応答メッセージを経由して、第２のアプリケーションに送信される。

本発明のもう１つの実施形態によれば、過負荷制御情報は、呼ギャップ（ＣａｌｌＧａｐ）要求ＣＧＲメッセージを経由して、第２のアプリケーションに送信される。

本発明の一実施形態によれば、過負荷制御情報は、過負荷属性値対の組合せである。過負荷属性値対のこの組合せは、負荷の現状を画定する負荷レベル属性値対と、過負荷制御期間を画定する過負荷制御期間属性値対と、その過負荷制御期間内に取られる処置を画定する過負荷制御処置属性値対と、過負荷制御期間内の要求メッセージの送信頻度を画定する要求送信頻度属性値対とを含む。

本発明は、過負荷が発生したとき、過負荷制御情報がそのネットワーク要素と通信している相手側のネットワーク要素に送信されるように設定するように構成された過負荷制御開始デバイスを含む、ダイアメータプロトコルベースのネットワーク要素も提案する。

加えて、本発明は、相手側から送信された過負荷制御情報を受信しているとき、その過負荷制御情報に従って処置を取るように構成された過負荷制御応答デバイスを含む、ダイアメータプロトコルベースのネットワーク要素をさらに提案する。

本発明の過負荷制御機構は、過負荷情報、過負荷要求、および過負荷応答が、２つ以上のダイアメータプロキシまたは中継ノードを経由して１つのダイアメータアプリケーションから任意のその他のダイアメータアプリケーションに送信されることを可能にするための、ダイアメータサーバとダイアメータクライアントとの間のエンドツーエンド過負荷制御機構であり、その中間ダイアメータプロキシまたは中継ノードは、その方法をサポートせず、もしくはその方法を知らず、あるいはいずれの処置も取らず、むしろ、ダイアメータコマンド／ＡＶＰをトランスペアレントに転送するだけであり、これは、これらの中間ダイアメータノード上の処理量を削減することになる。

本発明の一実施形態による、ダイアメータ応答メッセージを経由して、ダイアメータ過負荷制御を開始する例を示す図である。本発明の一実施形態による、特定のＣＧＲ／ＣＧＡコマンドを経由して、ダイアメータ過負荷制御を開始する例を示す図である。本発明の一実施形態による、過負荷制御を取り消す例を示す図である。本発明の一実施形態による、ダイアメータアプリケーション内に含まれた過負荷制御開始デバイスの例を示す図である。本発明の一実施形態による、ダイアメータアプリケーション内に含まれた過負荷制御応答デバイスの例を示す図である。

本発明の１つまたは複数の実施形態の詳細な説明は、本発明の原理を示す図面に関して以下に提供される。これらの実施形態に関して説明されるが、本発明は、これらの実施形態うちのいずれかに限定されない。本発明の範囲は、特許請求の範囲によって画定され、様々なオプションの方法、修正形態、および同等の代替形態を含む。本発明を完全に理解するために、多くの特定の詳細が以下の説明で提供される。これらの詳細は、完全に例として提供され、本発明は、これらの特定の詳細の一部またはすべてを伴わずに、特許請求の範囲に基づいて実装されることが可能である。分かりやすいように、本発明に関する技術分野で知られている技術的プロファイルは、本発明をあいまいにしないように、もはや詳細に説明されない。

本発明の実施形態において、ＡＡＲダイアメータメッセージならびにＡＡＡダイアメータメッセージは、特定のアプリケーションに関する要求および応答として使用され、実際に、本発明の方法は、任意のダイアメータの要求および応答により実装されることが可能である点を特にここで述べる必要がある。

図１は、ダイアメータ応答メッセージを経由して、ダイアメータ過負荷制御を開始する例を示す。この例では、関与するエンティティは、アプリケーションＡおよびアプリケーションＢであり、アプリケーションＡは、ダイアメータサーバであってよく、アプリケーションＢは、ダイアメータクライアントであってよく、またはアプリケーションＡは、ダイアメータクライアントであってよく、アプリケーションＢは、ダイアメータサーバであってもよい。サーバおよびクライアントのどちらも、自発的に過負荷制御要求を開始する可能性を有する。加えて、「中間ノード」と呼ばれる、１つまたは複数のプロキシ／二次ノードがアプリケーションＡとアプリケーションＢの間に存在し得る。これらの中間ノードは、過負荷制御に参加せずに、過負荷要求メッセージまたは過負荷応答メッセージをトランスペアレントに転送することだけが必要である。図１において、ステップ１０１に示すように、アプリケーションＡはＡＡＲ（認証、許可要求）をアプリケーションＢに送信し、中間ノードはＡＡＲ要求をトランスペアレントに転送すると仮定する。ステップ１０２において、アプリケーションＢは、例えば、重負荷により、自らがＡＡＲメッセージを処理することができないことを見出し、次いで、ステップ１０３において、アプリケーションＢは、アプリケーションＡに返信される状態にある応答ＡＡＡメッセージ内に過負荷ＡＶＰを記入し、結果コードＡＶＰの値を「トゥービジー（ｔｏｏｂｕｓｙ）」に設定する。ステップ１０４において、アプリケーションＢは、応答ＡＡＡメッセージをアプリケーションＡに送信し、同様に、中間ノードは、過負荷制御に参加せずに、このメッセージをアプリケーションＡにトランスペアレントに転送する。最終的に、ステップ１０５に示すように、アプリケーションＡが応答ＡＡＡメッセージを受け取るとき、アプリケーションＡは、そのメッセージ内に過負荷ＡＶＰを発見し、過負荷ＡＶＰの値に従って、対応する処置を取る。

ステップ１０５において実行される特定の過負荷制御処置を説明する目的で、本発明の過負荷ＡＶＰがまず紹介され、本発明の好ましい実施形態によれば、本明細書において、過負荷ＡＶＰは、グループ化されたＯｖｅｒ＿ｌｏａｄ＿ＡＶＰであってよく、このＡＶＰは、本発明の過負荷制御機構を実装するために提案される、新しいダイアメータＡＶＰであり、負荷状態および過負荷制御要求は、エンドツーエンドダイアメータアプリケーションの過負荷制御に関して含まれ、このＡＶＰは、任意のダイアメータ応答メッセージ内、または任意のダイアメータコマンド内に含まれることが可能である。このグループ化されたＯｖｅｒ＿ｌｏａｄ＿ＡＶＰは、以下のサブＡＶＰを含み得る：
・Ｌｏａｄ＿ｌｅｖｅｌ＿ＡＶＰ、すなわち、負荷レベルＡＶＰ。このＡＶＰは、ダイアメータアプリケーションの負荷状態を示し、その値は、例えば、ｏｖｅｒｌｏａｄ＿ｍｉｎｏｒ、ｏｖｅｒｌｏａｄ＿ｃｒｉｔｉｃａｌ、ｎｏｒｍａｌなどであり得る。当然、レベルは、実際の必要性に従って、より細かく分割され得る。
・Ｏｖｅｒｌｏａｄ＿ｄｕｒａｔｉｏｎ＿ＡＶＰ、すなわち、過負荷制御期間ＡＶＰ。このＡＶＰは、過負荷制御要求の寿命を示す。
・Ｏｖｅｒｌｏａｄ＿Ａｃｔｉｏｎ＿ＡＶＰ、すなわち、過負荷制御が要求されているダイアメータアプリケーション側によって取られる処置。以下の例は、値が０−４であるときの過負荷制御処置に対応している：
○ ０−いかなる要求も送信しない、
○ １−緊急の要求だけを送信する、
○ ２−アクティブなダイアメータセッションに関する要求だけを送信する、
○ ３−このＡＶＰ内の値未満の頻度でだけ要求を送信する、
○ ４−過負荷制御処置を取り消す。これは、ダイアメータアプリケーションがもはや過負荷でないときに使用され、これまでのｏｖｅｒｌｏａｄ＿ＡＶＰは、取り消されることが所望される。
○ その他の可能な値。
・Ｒｅｑｕｅｓｔ＿ｓｅｎｄｉｎｇ＿ｆｒｅｑｕｅｎｃｙ＿ＡＶＰ。このＡＶＰは、要求された側が過負荷制御を要求している側に送信することが可能な最大送信頻度を示す。当然、前述のように、本発明において、過負荷制御を開始しているアプリケーションは、ダイアメータクライアントであってよく、またはダイアメータサーバであってもよい。

この例では、ステップ１０５においてすでに予め記載されたように、アプリケーションＡが応答ＡＡＡメッセージを受信するとき、アプリケーションＡは、そのメッセージ内に過負荷ＡＶＰを見出し、その過負荷ＡＶＰの値に従って、対応する処置を取る。アプリケーションＡによって取られるこの処置は、グループ化されたＯｖｅｒ＿ｌｏａｄ＿ＡＶＰ、すなわち、前述のように、Ｌｏａｄ＿ｌｅｖｅｌ＿ＡＶＰ、Ｏｖｅｒｌｏａｄ＿ｄｕｒａｔｉｏｎ＿ＡＶＰ、Ｏｖｅｒｌｏａｄ＿Ａｃｔｉｏｎ＿ＡＶＰ、およびＲｅｑｕｅｓｔ＿ｓｅｎｄｉｎｇ＿ｆｒｅｑｕｅｎｃｙ＿ＡＶＰに基づいている。例えば、この実施形態では、Ｌｏａｄ＿ｌｅｖｅｌ＿ＡＶＰ＝ｏｖｅｒｌｏａｄ＿ｍｉｎｏｒ（軽過負荷）、Ｏｖｅｒｌｏａｄ＿Ａｃｔｉｏｎ＿ＡＶＰ＝３、Ｒｅｑｕｅｓｔ＿ｓｅｎｄｉｎｇ＿ｆｒｅｑｕｅｎｃｙ＿ＡＶＰ＝６０秒、およびＯｖｅｒｌｏａｄ＿ｄｕｒａｔｉｏｎ＿ＡＶＰ＝９００秒に設定する。この値のグループは、９００秒の期間内に、その要求が６０秒未満の頻度で過負荷制御を開始している側（すなわち、アプリケーションＢ）に送信されることを意味する。

次いで、ステップ１０５において、アプリケーションＢの要求に応答して、グループ化されたＯｖｅｒ＿ｌｏａｄ＿ＡＶＰの値に従って、かつアプリケーションＢの協力の下で、アプリケーションＡは、以下の過負荷制御処置を主に実行する：例えば、応答ＡＡＡメッセージを受信しているとき、アプリケーションＡは、６０秒待った後で、ＡＡＲ要求だけをアプリケーションＢに送信する。アプリケーションＢは、このメッセージを普通に処理し、次いで、結果コード＝２００１などのＡＡＡ応答メッセージをアプリケーションＡに送信する、アプリケーションＡは、ＡＡＡ応答メッセージを受信して、さらに６０秒後にだけ、別のＡＡＲ要求をアプリケーションＢに送信する。アプリケーションＢは、このメッセージを普通に処理し、次いで、結果コード＝２００１などのＡＡＡ応答メッセージをアプリケーションＡに送信する、．．．、９００秒の期間が終わるまで、類似の処理が続く。

ステップ１０５における処理は、アプリケーションＢの負荷を低減する。Ｏｖｅｒｌｏａｄ＿ｄｕｒａｔｉｏｎ＿ＡＶＰが終了するとき、エンドツーエンド過負荷制御は終了し、アプリケーションＢは、その現在の負荷状態に基づいて、過負荷制御が再度開始される必要があるかどうかを決定することになる。再度開始される必要がある場合、過負荷制御は、再度開始されることになる。

図２は、本発明の一実施形態に従って、特定のＣＧＲ／ＣＧＡコマンドを経由して、ダイアメータ過負荷制御を開始する例を示す。ＣＧＲ／ＣＧＡは、エンドツーエンドダイアメータ過負荷制御をサポートするために、ＲＦＣ３５８８プロトコルに基づいて拡張された、新しいダイアメータコマンドであることを特にここで述べる必要がある。このコマンドは、前述のグループ化されたＯｖｅｒ＿ｌｏａｄ＿ＡＶＰを含む。ＣＧＲコマンドは、呼ギャップ要求であり、この要求を送信することは、特に、遠端が、そのコマンド内の過負荷ＡＶＰに従って、過負荷制御プロセスを開始することが要求されていることを意味する。ＣＧＡコマンド、すなわち、呼ギャップ応答は、どんなＣＧＲが受け入れられても、受け入れられなくても、遠端から返信される。

この例では、ダイアメータクライアントまたはダイアメータサーバなどのアプリケーションＡは、ステップ２０１に示すように、自らが過負荷状態であることを見出す。この場合、アプリケーションＡの特定のアプリケーションに応じて、過負荷を「見出す」ための多くの既存の技術が存在し得る。例えば、最も一般的な技術は、ＣＰＵまたはメモリの使用から、過負荷であるかどうかを決定することであり、それによって、ユーザが自ら対応する過負荷しきい値を設定することが可能である。ステップ２０２において、アプリケーションＡは、例えば、Ｌｏａｄ＿ｌｅｖｅｌ＿ＡＶＰ＝ｏｖｅｒｌｏａｄ＿ｃｒｉｔｉｃａｌ、Ｏｖｅｒｌｏａｄ＿Ａｃｔｉｏｎ＿ＡＶＰ＝０、およびＯｖｅｒｌｏａｄ＿ｄｕｒａｔｉｏｎ＿ＡＶＰ＝９００秒を設定して、過負荷ＡＶＰの値をポピュレートし、設定され、グループ化されたＯｖｅｒｌｏａｄ＿ＡＶＰはＣＧＲコマンド内に入れられ、ＣＧＲ要求コマンドは、アプリケーションＢに送信される。ステップ２０３において、アプリケーションＢは、ＣＧＲ要求コマンドを受信して、過負荷ＡＶＰを復号し、次いで、アプリケーションＢが、そのＡＶＰの値に基づいて処置を取ることが可能かどうかを決定する。ステップ２０４において、アプリケーションＢが、そのＡＶＰの値に基づいて、処置を取ることが可能であることを決定した場合、すなわち、アプリケーションＢが、過負荷制御を実行するために、アプリケーションＡと協働することが可能である場合、アプリケーションＢは、ＣＧＲと対を組んだＣＧＡ応答コマンドを生成して、応答として、その応答コマンドＣＧＡをアプリケーションＡに送信することになる。この応答コマンド内で、結果コードＡＶＰの値は「２００１」（ＤＩＡＭＥＴＥＲ＿ＳＵＣＣＥＳＳ）に設定され、この値は、その要求が成功したことを相手側に知らせることを意味する。

最終的に、ステップ２０５において、アプリケーションＡおよびアプリケーションＢは、過負荷制御を実行するために、過負荷ＡＶＰの値に基づいて、対応する処置を取る。グループ化されたＯｖｅｒ＿ｌｏａｄ＿ＡＶＰの値のグループ、詳細には、Ｏｖｅｒｌｏａｄ＿Ａｃｔｉｏｎ＿ＡＶＰ＝０およびＯｖｅｒｌｏａｄ＿ｄｕｒａｔｉｏｎ＿ＡＶＰ＝９００秒に従って、アプリケーションＢは、その９００秒の期間内に、それ以上の要求をアプリケーションＡに送信しない。９００秒の終了まで、両者は通常の通信を開始する。前述のように、プロキシ／中継として機能している１つまたは複数の中間ノードがアプリケーションＡとアプリケーションＢとの間に存在することが可能であり、これらの中間ノードは、過負荷制御に参加せずに、関連する要求メッセージ／応答メッセージまたはＣＧＲコマンド／ＣＧＡコマンドをトランスペアレントに転送することだけが必要である点に留意されたい。これらの中間ノードがメッセージまたはコマンドを転送する説明は、本発明の説明を明瞭にするために、図２の実施形態において省略される。

上の図１および２を参照した説明は、過負荷制御機構をどのようにトリガするかの例を提供する。この説明を通じて、当業者は、セッションの間にダイアメータ応答メッセージ内に過負荷ＡＶＰの値を追加することによって、過負荷制御を開始するように相手側に通知することが可能であり、自らが過負荷状態であることを見出したとき、ＣＧＲメッセージをアクティブに生成して、過負荷制御を開始するよう相手側にインバイトするために、そのメッセージ内に過負荷ＡＶＰの値を追加することも可能であることを明瞭に認識されよう。アプリケーションＡとアプリケーションＢとの間の特定の過負荷制御処置は、過負荷ＡＶＰの値に依存する。

図１および２に関して説明された実施形態では、予め過負荷されて、過負荷制御を開始したダイアメータアプリケーションが、過負荷制御期間がまだ終了していない間に、自らがすでに通常の負荷状態であることを見出す場合が存在し得る。そのような場合、過負荷制御プロセスを進めることは不要である。そのような考慮事項に関して、図３は、本発明の実施形態に従って、過負荷制御を取り消す例を示す。

図３において、アプリケーションＡは、ＣＧＲコマンドを使用してダイアメータ過負荷制御を開始するが、ある期間の後、アプリケーションＡは、ステップ３０１に記載されたように、負荷制御プロセス全体が終了する前に、その処理量が標準状態に戻ったことを見出す場合があり、その時点で、アプリケーションＡは、過負荷制御を完了するために、その遠端がこの変更について知ることを望む。次いで、ステップ３０２において、アプリケーションＡは、例えば、Ｌｏａｄ＿ｌｅｖｅｌ＿ＡＶＰ＝ｎｏｒｍａｌ、およびＯｖｅｒｌｏａｄ＿Ａｃｔｉｏｎ＿ＡＶＰ＝ｃａｎｃｅｌを設定して、過負荷ＡＶＰの値をポピュレートし、ポピュレートされた、グループ化されたＯｖｅｒｌｏａｄ＿ＡＶＰは、ＣＧＲコマンド内に入れられ、次いで、ＣＧＲ要求コマンドがアプリケーションＢに送信される。ステップ３０３において、アプリケーションＢは、ＣＧＲ要求コマンドを受信して、過負荷ＡＶＰを復号し、次いで、それによって使用されている過負荷制御を取り消すための処置を取る。次に、ステップ３０４において、アプリケーションＢは、ＣＧＡ応答コマンドを生成して、応答として、その応答コマンドＣＧＡをアプリケーションＡに送信する。この応答コマンド内で、結果コードＡＶＰの値は、過負荷制御を取り消す動作が成功したことを相手側に伝えることを意味する「２００１」に設定される。最終的に、ステップ３０５において、アプリケーションＡおよびＢは、標準の制御状態のダイアメータセッション／トランザクション処理に戻る。

図４は、本発明の実施形態による、ダイアメータアプリケーションに含まれる過負荷制御開始デバイス４００の構造図を示す。好都合に説明するために、ダイアメータアプリケーションは、図２に提示されたアプリケーションＡ、すなわち、過負荷制御の開始側に対応する。アプリケーションＡは、ダイアメータサーバであってよく、ダイアメータクライアントであってもよい。示すように、アプリケーションＡは、過負荷制御情報設定モジュール４０１と、ポピュレートモジュール４０２と、ＣＧＲメッセージ生成モジュール４０３と、応答メッセージを送信するためのモジュール４０４とを含み得る、本発明の過負荷制御開始デバイス４００を備える。過負荷制御情報設定モジュール４０１は、負荷状態感知モジュール（図示せず）など、その他の機能的要素によって「見出された」過負荷状態に応答して、例えば、Ｌｏａｄ＿ｌｅｖｅｌ＿ＡＶＰ＝ｏｖｅｒｌｏａｄ＿ｃｉｒｉｔｉａｌ、Ｏｖｅｒｌｏａｄ＿Ａｃｔｉｏｎ＿ＡＶＰ＝０、およびＯｖｅｒｌｏａｄ＿ｄｕｒａｔｉｏｎ＿ＡＶＰ＝９００秒を設定して、過負荷ＡＶＰ値を設定する。ポピュレートされた後で、過負荷ＡＶＰは、その既存の状態に従って、ダイアメータ応答メッセージまたはＣＧＲを経由して、相手側（すなわち、遠端）に送信され、本実施形態において、詳細には、ＣＧＲによって相手側に送信される。図のＣＧＲ生成モジュール４０３は、ＣＧＲコマンドを生成するためであり、グループ化されたＯｖｅｒｌｏａｄ＿ＡＶＰセットアップは、ＣＧＲコマンドメッセージを生成するために、ポピュレートモジュール４０２によってＣＧＲ生成モジュール４０３に追加され、このＣＧＲメッセージは、アプリケーションＡの関連する送信デバイス（図示せず）によって、アプリケーションＢに送信されている。過負荷ＡＶＰが、ＡＡＡダイアメータなどの応答メッセージを介して相手側に送信された場合、ポピュレートされた過負荷ＡＶＰは、この場合、送信応答メッセージモジュール４０４を経由して、ダイアメータ応答メッセージ内で運ばれて、相手側に送信されることが考えられ得る。

それに応じて、図５は、図４のアプリケーションＡの過負荷制御開始デバイス４００に対応する、アプリケーションＢの過負荷制御応答デバイス５００の機能ブロック図を示す。デバイス５００は、ＣＧＡ生成モジュール５０１、過負荷制御開始モジュール５０１、タイマ５０４、タイマ５０５などをさらに含む。ＣＧＡ５０１は、ＣＧＲ要求コマンドを受信して、過負荷ＡＶＰを復号し、次いで、ＣＧＡ５０１がそのＡＶＰ値に従って処置を取ることができるかどうかを決定する。アプリケーションＢが、そのＡＶＰ値に従って処置を取ることができることを決定した場合、すなわち、アプリケーションＢが、過負荷制御を実行するために、アプリケーションＡと協働することが可能であることを決定した場合、アプリケーションＢは、ＣＧＲと対を組んだＣＧＡ応答コマンドを生成して、応答として、その応答コマンドＣＧＡをアプリケーションＡに送信することになる。この応答コマンド内で、結果コードＡＶＰの値は、その要求が成功したことを相手側に知らせることを意味する「２００１」に設定される。過負荷制御開始モジュール５０２は、グループ化されたＡＶＰ値内の過負荷制御情報、特に、Ｏｖｅｒｌｏａｄ＿Ａｃｔｉｏｎ＿ＡＶＰ＝０、およびＯｖｅｒｌｏａｄ＿ｄｕｒａｔｉｏｎ＿ＡＶＰ＝９００秒に従って、過負荷制御を実行する目的で、対応する処置を取るために使用される。タイマ５０４が、この場合、過負荷制御期間のタイミングを決めるためのタイマであると仮定すると、過負荷制御応答デバイス５００は、過負荷制御の始めにタイマ５０４を開始し、９００秒のタイムイアウト期間内に、過負荷制御開始モジュール５０２は、その期間が終了するまで、Ｏｖｅｒｌｏａｄ＿Ａｃｔｉｏｎ＿ＡＶＰ＝０（この値は、何の要求も送信しないことを意味する）に基づいて、ＡＡＲ要求の送信を抑制することになる。

本発明の実施形態による過負荷制御開始デバイス４００ならびに過負荷制御応答デバイス５００は、特定の実施形態に基づいて、それぞれ、図４および５で紹介された。当業者にとって、本発明の原理を理解することに基づいて、これらのデバイスおよびモジュールは、コンピュータソフトウェアによって実装されることが可能であり、これらのデバイスおよびモジュール自体が、本発明の基本概念の範囲内で、様々な修正形態を有し得る。加えて、ダイアメータサーバであろうと、ダイアメータクライアントであろうと、本発明のダイアメータアプリケーションは、過負荷制御をアクティブに開始することが可能であり、相手側によって開始された過負荷制御に応答することが可能である。したがって、ダイアメータアプリケーションは、過負荷制御開始デバイスおよび過負荷制御応答デバイスの両方を含むことが好ましい。

本発明の原理は、特定のデバイスおよび特定の実装形態に関してすでに詳細に説明されているが、この説明は、本発明の範囲を限定するのではなく、例として行われた点を理解されたい。本明細書で開示された本発明の基本原理および実施形態を考慮することによって、本発明のその他の実施形態は当業者に明らかになるであろう。本発明の範囲は、添付の特許請求の範囲によって画定される。

Claims

ダイアメータプロトコルに基づいて、第１のアプリケーションと第２のアプリケーションとの間の過負荷を制御する方法であって、
第１のアプリケーションが過負荷であるとき、過負荷制御情報を設定して、過負荷制御情報を第２のアプリケーションに送信することであって、過負荷制御情報は、第２のアプリケーションが第１のアプリケーションにメッセージを送信する仕方を指示する、送信することと、
第２のアプリケーションが、過負荷制御情報によって指示された仕方で、第１のアプリケーションにメッセージを送信することによって、過負荷制御情報に従って過負荷制御処置を開始することとを含む、方法。
過負荷制御情報が、任意のダイアメータ応答メッセージを経由して、第２のアプリケーションに送信されている、請求項１に記載の過負荷を制御する方法。
過負荷制御情報が、呼ギャップ要求ＣＧＲを経由して、第２のアプリケーションに送信されている、請求項１に記載の過負荷を制御する方法。
第２のアプリケーションが、呼ギャップ応答ＣＧＡを第１のアプリケーションに返信することをさらに含む、請求項３に記載の過負荷を制御する方法。
過負荷制御情報が、
負荷の現状を画定するための負荷レベル属性値対、
過負荷制御期間を画定するための過負荷制御期間属性値対、
過負荷制御期間内に取られた処置を画定するための過負荷制御処置属性値対、および
過負荷制御期間内の要求メッセージの送信頻度を画定するための要求送信頻度属性値対のうちの１つまたは複数を備える、グループ化された過負荷属性値対である、請求項１に記載の過負荷を制御する方法。
過負荷制御期間内に第１のアプリケーションの負荷状態が標準状態に回復されている場合、過負荷制御を取り消すコマンドメッセージが第２のアプリケーションに送信されることをさらに含む、請求項５に記載の過負荷を制御する方法。
処置が、いかなる要求メッセージも送信しないこと、緊急の要求だけを送信すること、アクティブなダイアメータセッションに関する要求だけを送信すること、属性値対において画定された要求送信頻度未満の要求送信頻度でだけ要求を送信すること、および過負荷制御を取り消すことのグループのうちのいずれか１つを含む、請求項５に記載の過負荷を制御する方法。
過負荷が発生したとき、過負荷制御情報がネットワーク要素と通信している相手側のネットワーク要素に送信されるように設定するように構成された過負荷制御開始デバイスを含み、過負荷制御情報は、第２のアプリケーションが第１のアプリケーションにメッセージを送信する仕方を指示する、ダイアメータプロトコルベースのネットワーク要素。
過負荷制御開始デバイスが、過負荷制御情報を任意のダイアメータ応答メッセージに追加するようにさらに構成されている、請求項８に記載のネットワーク要素。
過負荷制御開始デバイスが、呼ギャップ要求ＣＧＲを生成するようにさらに構成されている、請求項８に記載のネットワーク要素。
過負荷制御開始デバイスが、過負荷制御情報を呼ギャップ要求ＣＧＲに追加するようにさらに構成されている、請求項１０に記載のネットワーク要素。
相手側から送信された過負荷制御情報を受信しているとき、過負荷制御情報によって指示された仕方で、第１のアプリケーションにメッセージを送信することによって、過負荷制御情報に従って過負荷制御処置を開始するように構成された、過負荷制御応答デバイスを含むダイアメータプロトコルベースのネットワーク要素。
過負荷制御応答デバイスが、相手側によって送信された呼ギャップ要求ＣＧＲを受信しているとき、呼ギャップ応答ＣＧＡを生成するようにさらに構成されている、請求項１２に記載のネットワーク要素。