(57)【要約】メッセージの通信のために配置されたターゲットノード、および、少なくとも１つのソースノードを含み、さらに、前記ターゲットノードは、少なくとも１つの前記ソースノードから受信したメッセージのうちの、少なくとも、いくつかを処理する手段と、前記ターゲットノードの処理負荷を検出する手段を含み、さらに、前記ターゲットノードは、ある特定の処理負荷レベルに達するか、または、ある特定の処理負荷レベルを越える場合、前記少なくとも１つのソースノードに通知する手段を含み、さらに、各ソースノードは、その通知に応答して、メッセージがターゲットノードに送信される割合を低下させる手段を含むことを特徴とする通信システム。
2008502184.tif 000002
【特許請求の範囲】
【請求項１】
メッセージの通信のために配置されたターゲットノード、および、少なくとも１つのソースノードを含み、さらに、前記ターゲットノードは、前記少なくとも１つのソースノードから受信したメッセージのうちの、少なくともいくつかを処理する手段と、前記ターゲットノードの処理負荷を検出する手段を含み、さらに、前記ターゲットノードは、ある特定の処理負荷レベルに達しているか、または、ある特定の処理負荷レベルを越えている場合、前記少なくとも１つのソースノードに通知する手段を含み、さらに、各ソースノードは、その通知に応答して、前記ターゲットノードにメッセージが送信される割合を低下させる手段を含むことを特徴とする通信システム。
【請求項２】
前記割合の低下を、前記ターゲットノードに転送を行う前記少なくとも１つのソースノードで受信されたメッセージのうち特定の割合のメッセージを拒否することで実現することを特徴とする請求項１に記載の通信システム。
【請求項３】
前記ターゲットノードは、前記特定の割合を、前記少なくとも１つのソースノードに通知する手段を含むことを特徴とする請求項１又は２に記載の通信システム。
【請求項４】
各ソースノードに配置される前記手段は、ある期間に亘って、これ以上の通知を受信することはないということを根拠に、メッセージが前記ターゲットノードに送信される割合を、ある時間経過後に増加させるよう構成されていることを特徴とする請求項１乃至３のいずれか１項に記載の通信システム。
【請求項５】
各ソースノードに配置される前記手段は、ある期間に亘って、これ以上の通知を受信することはないということを根拠に、メッセージが前記ターゲットノードに送信される割合を、ある時間経過後に減少させるよう構成されていることを特徴とする請求項１乃至３のいずれか１項に記載の通信システム。
【請求項６】
前記ターゲットノードは、各ソースノードに通知された情報を記録する手段を含むことを特徴とする請求項１乃至５のいずれか１項に記載の通信システム。
【請求項７】
前記ターゲットノードは、特定の処理負荷に達するか、または、越えた、ある期間中において、該ターゲットノードにメッセージを供給する前記ソースノードに通知することだけ実行するよう構成されていることを特徴とする請求項１乃至６のいずれか１項に記載の通信システム。
【請求項８】
前記ターゲットノードは、処理負荷の増加に続いて、前記ソースノードが単独でまたは複数で、さらにメッセージを該ターゲットノードに送信する場合に、請求項７に記載の前記ソースノードのいずれかに新しい通知をするよう構成されていることを特徴とする請求項７に記載の通信システム。
【請求項９】
前記ターゲットノードは、処理負荷の特定のレベルに対して１回だけ、前記ソースノードのいずれか１つに通知をするよう構成されていることを特徴とする請求項１乃至８のいずれか１項に記載の通信システム。
【請求項１０】
前記ターゲットノードは、前記ソースノードに送信されるメッセージのそれぞれに、特定の負荷に達したかどうか、あるいは、特定の負荷を越えたかどうかについての通知を付与するよう構成されていることを特徴とする請求項１乃至８のいずれか１項に記載の通信システム。
【請求項１１】
前記ターゲットノードは、前記ソースノードに送信される、呼に関係のない周期的なメッセージに、特定の負荷に達したかどうか、あるいは、特定の負荷を越えたかどうかについての通知を付与するよう構成されていることを特徴とする請求項１乃至８のいずれか１項に記載の通信システム。
【請求項１２】
前記ターゲットノードは、特定の処理負荷レベルに達しており、または、特定の処理負荷レベルを越えており、その負荷レベルがさらに上昇している場合に、すでに通知済みの少なくとも１つのソースノードに対して、さらに通知を行うよう構成されていることを特徴とする請求項１乃至１１のいずれか１項に記載の通信システム。
【請求項１３】
前記処理負荷は、前記ソースノードからメッセージが受信される率に応じて定義されることを特徴とする請求項１乃至１２のいずれか１項に記載の通信システム。
【請求項１４】
前記処理負荷を定義するために用いられる受信メッセージは、新しい接続要求であることを特徴とする請求項１乃至１３のいずれか１項に記載の通信システム。
【請求項１５】
前記少なくとも１つの前記ソースノードは、１種類以上のメッセージを前記ターゲットノードに送信するよう構成されており、さらに、前記ターゲットノードは、受信したメッセージの種類を特定し、新しい接続要求の同定の後すぐに、メッセージに如何なる処理もしないで、通知を送信するよう構成されていることを特徴とする請求項１乃至１４のいずれか１項に記載の通信システム。
【請求項１６】
前記ターゲットノードは、少なくとも１００個のソースノードからメッセージを受信するよう構成されていることを特徴とする請求項１乃至１５のいずれか１項に記載の通信システム。
【請求項１７】
前記ターゲットノードは、少なくとも１０００個のソースノードからメッセージを受信するよう構成されていることを特徴とする請求項１乃至１６のいずれか１項に記載の通信システム。
【請求項１８】
前記ターゲットノードは、少なくとも、１万個のソースノードからメッセージを受信するよう構成されていることを特徴とする請求項１乃至１７のいずれか１項に記載の通信システム。
【請求項１９】
前記ターゲットノードは、少なくとも１０万個のソースノードからメッセージを受信するよう構成されていることを特徴とする請求項１乃至１８のいずれか１項に記載の通信システム。
【請求項２０】
前記ターゲットノードは、少なくとも１００万個のソースノードからメッセージを受信するよう構成されていることを特徴とする請求項１乃至１９のいずれか１項に記載の通信システム。
【請求項２１】
前記ターゲットノードはコールサーバであることを特徴とする請求項１乃至２０のいずれか１項に記載の通信システム。
【請求項２２】
各ソースノードは、メディアゲートウエイ機能を提供するネットワーク終端装置を含むことを特徴とする請求項１乃至２１のいずれか１項に記載の通信システム。
【請求項２３】
前記メッセージは、インターネットプロトコル（ＩＰ）を基礎にしたメッセージであることを特徴とする請求項１乃至２２のいずれか１項に記載の通信システム。
【請求項２４】
前記メッセージがターゲットノードに到着する前に、メッセージの集中が発生しないようにしたことを特徴とする請求項１乃至２３のいずれか１項に記載の通信システム。
【請求項２５】
前記メッセージは、優先度の低いメッセージと優先度の高いメッセージに分類され、優先度の低いメッセージの割合を低下させることだけを実行するよう、前記少なくとも１つのソースノードが構成されていることを特徴とする請求項１乃至２４のいずれか１項に記載の通信システム。
【請求項２６】
少なくとも１つのソースノードからメッセージを受信し、該少なくとも１つのソースノードから受信するメッセージの少なくともいくつかを処理するターゲットノードでの負荷を制御する方法であって、前記ターゲットノードの処理負荷を検出するステップと、特定の処理負荷レベルに達しているか、または、特定の処理レベルを越えている場合、少なくとも１つのソースノードに通知するステップとを含み、各ソースノードが、その通知に応答して、前記ターゲットノードにメッセージが送信される割合を低下させることを特徴とする方法。
【請求項２７】
前記ターゲットノードにメッセージを転送するための、前記少なくとも１つのソースノードで受信されるメッセージの特定の割合を低下させるステップを含むことを特徴とする請求項２６に記載の方法。
【請求項２８】
前記ターゲットノードが、前記特定の割合を、少なくとも１つのソースノードに通知することを特徴とする請求項２６又は２７に記載の方法。
【請求項２９】
ある時間経過中にさらなる通知を受信しなかったことを前提に、その時間経過後に、前記ターゲットノードにメッセージが送信される割合を上昇させることを特徴とする請求項２６乃至２８のいずれか１項に記載の方法。
【請求項３０】
ある時間経過中にさらなる通知を受信しなかったことを前提に、その時間経過後に、前記ターゲットノードにメッセージが送信される割合を低下させることを特徴とする請求項２６乃至２８のいずれか１項に記載の方法。
【請求項３１】
各ソースノードに通知された情報を記録するステップを含むことを特徴とする請求項２６乃至３０のいずれか１項に記載の方法。
【請求項３２】
前記特定の処理レベルに達しているか、または、前記特定の処理レベルを越えている場合、ある時間の期間中、前記ターゲットノードにメッセージを供給するソースノードだけに通知をするステップを含むことを特徴とする請求項２６乃至３１のいずれか１項に記載の方法。
【請求項３３】
請求項３２に記載のソースノードのいずれかが、処理負荷の増加に続いて、さらにメッセージを前記ターゲットノードに送信する場合は、前記ターゲットノードが該ソースノードに新しい通知を送信するステップを含むことを特徴とする請求項３２に記載の通信システム。
【請求項３４】
前記ターゲットノードが前記ソースノードのいずれか１つに対して、前記処理負荷の特定のレベルについて１度だけ通知することを特徴とする請求項２６乃至３３のいずれか１項に記載の方法。
【請求項３５】
前記ソースノードに送信されたそれぞれのメッセージに対して、前記特定の処理負荷に達しているかどうか、特定の処理負荷を越えているかどうかについての通知を前記ターゲットノードが付与するステップを含むことを特徴とする請求項２６乃至３３のいずれか１項に記載の方法。
【請求項３６】
前記ソースノードに送信された呼に関係のない周期的なメッセージに対して、特定の処理負荷に達しているかどうか、特定の処理負荷を越えているかどうかについての通知を前記ターゲットノードが付与するステップを含むことを特徴とする請求項２６乃至３３のいずれか１項に記載の方法。
【請求項３７】
特定の処理負荷に達しており、または、特定の処理負荷を越えており、かつ、過負荷レベルがさらに増加している場合に、前記ターゲットノードが、すでにメッセージを通知されている少なくとも１つのソースノードのメッセージに対して、さらに通知をすることを特徴とする請求項２６乃至３６のいずれか１項に記載の方法。
【請求項３８】
前記処理負荷を、前記ソースノードからメッセージを受信する率に応じて定義することを特徴とする請求項２６乃至３７のいずれか１項に記載の方法。
【請求項３９】
前記処理負荷を定義するために用いられる受信メッセージは、新しい接続要求であることを特徴とする請求項２６乃至３８のいずれか１項に記載の方法。
【請求項４０】
前記少なくとも１つのソースノードが１種類以上のメッセージを前記ターゲットノードに送信するステップと、前記ターゲットノードが受信したメッセージの種類を特定するステップと、前記メッセージに対してそれ以上の処理なしで、新しい接続要求の特定の後に、すぐに通知を送信するステップとをさらに含むことを特徴とする請求項２６乃至３９のいずれか１項に記載の方法。
【請求項４１】
前記ターゲットノードが少なくとも１００個のソースノードからメッセージを受信することを特徴とする請求項２６乃至４０のいずれか１項に記載の方法。
【請求項４２】
前記ターゲットノードが少なくとも１０００個のソースノードからメッセージを受信することを特徴とする請求項２６乃至４１のいずれか１項に記載の方法。
【請求項４３】
前記ターゲットノードが少なくとも１万個のソースノードからメッセージを受信することを特徴とする請求項２６乃至４２のいずれか１項に記載の方法。
【請求項４４】
前記ターゲットノードが少なくとも１０万個のソースノードからメッセージを受信することを特徴とする請求項２６乃至４３のいずれか１項に記載の方法。
【請求項４５】
前記ターゲットノードが少なくとも１００万個のソースノードからメッセージを受信することを特徴とする請求項２６乃至４４のいずれか１項に記載の方法。
【請求項４６】
前記ターゲットノードがコールサーバであることを特徴とする請求項２６乃至４５のいずれか１項に記載の方法。
【請求項４７】
各ソースノードがネットワーク終端装置にメディアゲートウエイ機能を提供することを特徴とする請求項２６乃至４６のいずれか１項に記載の方法。
【請求項４８】
前記メッセージは、インターネットを基礎としたメッセージであることを特徴とする請求項２６乃至４７のいずれか１項に記載の方法。
【請求項４９】
前記メッセージが前記ターゲットノードに到着する前に、メッセージが集中するのを回避するステップをさらに含むことを特徴とする請求項２６乃至４８のいずれか１項に記載の方法。
【請求項５０】
前記メッセージを優先度の低いものと優先度の高いものに分類し、前記少なくとも１つのソースノードが優先度の低いメッセージを減少させるステップを含むことを特徴とする請求項２６乃至４９のいずれか１項に記載の方法。
【請求項５１】
実質的に図５、６、７、８を参照しながら記載され、かつ、図５、６、７、８に示された通信システムまたは通信方法。
【請求項５２】
実質的に図５、図１７乃至１９を参照しながら記載され、かつ、図５、図１７乃至１９に示された通信システムまたは通信方法。
【請求項５３】
実質的に図２０乃至２３を参照しながら記載され、かつ、図２０乃至２３に示された通信システムまたは通信方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般的には通信分野に関し、特に、通信システムと負荷管理に関連する方法に関する。
【背景技術】
【０００２】
現在使用されているＰＳＴＮ（公衆電話交換網）においては、発信が過多状態であるとき、つまり、ネットワークに供給された発信数が、そのネットワークの処理容量を超えている場合に、ネットワークが弾力的に確実に回復動作できるようにするために、多くの時間と多大な労力が費やされている。この弾力的な回復動作は、ネットワーク全体と、ネットワーク内にある個別交換機の両方で動作する負荷制御方式を導入することで実現されている。
【０００３】
このＰＳＴＮでの負荷制御に関しての動作については、ネットワークレベルでは、国際標準化機関、および、種々の国の標準化機関が取り纏めたものがある。これらの負荷制御に関する努力の成果は、国際標準化に関するＩＴＵ−Ｔ（国際電気通信連合・電気通信標準化部門）の勧告「Ｑ．７４６」、「信号方式Ｎｏ．７・ＩＳＤＮ（サービス総合デジタル網）ユーザ部手順」、「英国標準化規格ＰＮＯ−ＩＳＣ/ＳＰＥＣ００７、ＰＮＯ−ＩＳＣ規格」、「信号方式Ｎｏ．７・ＩＳＤＮユーザ部（ＩＳＵＰ）」に反映されている。一般的には、これらのネットワークレベルでの制御は、ＰＳＴＮのネットワーク内の交換機からの応答により起動される。そのために、ネットワーク内の交換機が過負荷である場合、合理的に動作・反応することが求められる。その意味で、ＩＴＵ−Ｔでは、過負荷である場合の交換機の動作についての勧告「Ｑ．５４３・デジタル交換機性能設計目標」を提供している。但し、勧告されたような交換機の動作が、どのように達成されるかに関しての正確な構成内容は、まだ特定されてはいない。図１は、過負荷時の交換機の特徴的な動作を示したものである。
【０００４】
基本的には、大抵のネットワークレベルの負荷制御方式は、交換機での過負荷に対処するために「バックオフ(back off)」メカニズムを利用している。つまり、一度通信が開始されると、ネットワークを基礎にした負荷制御方式では、過負荷状態になっている交換機に送信されるトラフィック量が制限されるので、その結果として、図２に示すように、交換機での処理量は合理的なレベルに維持されることになる。
【０００５】
これらのネットワークレベルでの方式の大多数は、呼およびルートの集中の度合いが非常に高いトランジット層で最も良好に動作する。つまり、クラス５（つまり、加入者が接続しているネットワーク内のノードまたは交換機）とクラス４（つまり、クラス５の交換機を接続するために使うネットワークノード）のトランジット層、クラス４とクラス４のトランジット層、または、クラス４とクラス５のトランジット層で動作する。集中の度合いが非常に低いか、あるは、集中がない場合、これらのメカニズムが有効に作用しない。オペレータ手動の方式（コールギャッピング方式）が使用される場合において、ＰＳＴＮの中に特に脆弱な箇所があり、それがアクセスコンセントレータ（集線装置）−クラス５インターフェースである。
【０００６】
すでに設置されている回線にブロッキング（閉塞）をもたらすほどに高水準のトラフィック量が集中する場合、アクセスコンセントレータとクラス５の交換機とのリンク規模により、その脆弱な箇所がどの程度保護されるかが決まってくる。
【発明の開示】
【発明が解決しようとする課題】
【０００７】
次世代のネットワークアーキテクチャにおいては、非常に大多数の加入者線（例えば、３０、０００回線を越える加入者数で、各加入者線の呼率が低いことが特徴）が、コールサーバのような単一の段で最初の集中が発生する。そのような状況下では、多数の回線における発呼率のほんの少しの増加が、呼の集中が発生しているポイントでの処理負荷の大きな増加の原因となる可能性がある。そのような全体の発呼率の増加が少ないために、コールサーバに大きな過負荷が発生してしまうことを防止できるだけの十分に速い応答速度を提供するメカニズムを得ることが課題である。
【０００８】
このような過負荷を防止し、従来の公衆電話交換網（ＰＳＴＮ）を淘汰させるほどのアクセスコンセントレータというメカニズムが、次世代のネットワークには存在していない。
【０００９】
次世代のネットワークアーキテクチャでは、この脆弱さがかなり悪化することが予想される。つまり、次世代のアーキテクチャでは、加入者線はメディアゲートウエイに接続されると想像される。このメディアゲートウエイは、従来のクラス５の交換機の代替であるコールサーバとして知られる装置に接続される。このアーキテクチャでは、メディアゲートウエイは、単独処理用の回線と、２０００回線におよぶ処理回線群との間において、サイズにばらつきがあるが、これらの２０００回線のすべてが、インターネットプロトコル（ＩＰ）を介して直接にコールサーバに接続されることとなり、このことは、コンセントレータの機能がネットワークから除去されるということである。
【００１０】
したがって、次世代アーキテクチャでは、数百あるいは数千、数百万のメディアゲートウエイが単一のコールサーバに接続されので、コールサーバに過負荷を発生させる、すべての回線とメディアゲートウエイとの間の発信の増加が適当なレベルとなるように操作するだけでよい。メディアにより誘発されたサービス、例えば、遠隔投票（テレボーティング）または大障害の発生の場合、各段において、発信のレベルに大きな変化が往々にして起こる。次世代アーキテクチャでは、そのような事態が発生すると、サービスを全面に停止させるような過負荷状態がコールサーバに発生する。明らかに、これは望まない結果であり、このことが発生するときは、緊急事態の処理能力、優先呼の処理能力も同時に麻痺するからである。そこで、このような事態を回避するために、メディアゲートウエイとコールサーバとの間で、十分に負荷を管理することが必要となる。
【００１１】
従来のＰＳＴＮでは、アクセスコントローラは、回線の１つを呼に割り当てることができる場合、「オフフック」の通知（つまり、新しい呼の設定要求）を、クラス５の交換機に対して送信するだけであった。このことは、クラス５の交換機に対応している回線の全部がビジー状態である場合、その呼がアクセスコントローラで拒否されることを意味する。
【００１２】
いくつかの信号方式が、次世代ネットワークのために提案されているが、[例えば、ＭＧＣＰ（メディアゲートウエイ制御プロトコル、Ｈ.２４８、および、ＳＩＰ（セッション開始プロトコル]、これらの点に関する解決策は示されていない。
【００１３】
すでに設置されている回線にブロッキングをもたらすほどに高水準のトラフィック量が集中する場合、アクセスコンセントレータとクラス５の交換機とのリンクの規模により、どの程度、呼が保護されるかが決まってくる。従来のＰＳＴＮでは、アクセスコントローラは、回線の１つを呼処理に割り当てることができる場合、「オフフック」の通知（つまり、新しい呼の設定要求）を、クラス５の交換機に対して通知するのみである。このことは、クラス５の交換機に対応している回線の全部がビジー状態である場合、その呼がアクセスコントローラで拒否されることを意味する。
【００１４】
可能な解決法は、ブロードキャストメカニズムを３０，０００以上の回線に備えることである。しかし、業界では、まだ適切なブロードキャストメカニズムが採用されておらず、そのような解決法は、まだ可能性として不適当として現在の発明者には拒否されるものである。
【課題を解決するための手段】
【００１５】
本発明は、メッセージの通信のために配置されたターゲットノード、および、少なくとも１つのソースノードを含み、さらに、ターゲットノードは、少なくとも１つのソースノードから受信したメッセージのうちの、少なくともいくつかを処理する手段と、ターゲットノードの処理負荷を検出する手段を含み、さらに、ターゲットノードは、ある特定の処理負荷レベルに達しているか、または、ある特定の処理負荷レベルを越えている場合、少なくとも１つのソースノードに通知する手段を含み、さらに、各ソースノードは、その通知に応答して、メッセージがターゲットノードに送信される割合を低下させる手段を含む通信システムを提供することである。
【００１６】
本発明は、少なくとも１つのソースノードからメッセージを受信し、少なくとも１つのソースノードから受信するメッセージの少なくともいくつかを処理するターゲットノードでの負荷を制御する方法であって、ターゲットノードの処理負荷を検出するステップ、特定の処理負荷レベルに達しているか、または、特定の処理レベルを越えている場合、少なくとも１つのソースノードに通知するステップを含み、各ソースノードが、その通知に応答して、メッセージがターゲットノードに送信される割合を低下させる負荷制御の方法。
【発明を実施するための最良の形態】
【００１７】
本発明の実施例を、図面を参照しながら以下に記載する。
【００１８】
以下で記載する負荷管理方式の基本的な動作は、あるメッセージがメディアゲートウエイにより過負荷メセージであると認識された場合（例えば、ノードに供給された発信数が、瞬時ピークの場合を除いて、その処理容量を超えている期間である場合）には、コールサーバが呼を拒否できること、そして、コールサーバにとっての過負荷メッセージがメディアゲートウエイに戻されること（個別メッセージにまたは過負荷メッセージの一部として）、メディアゲートウエイがコールサーバに供給する新しい呼の数の制限を開始することである。
【００１９】
コールサーバに対する発信数が増えるにつれて、その発信の増加に対応して、コールサーバで処理される負荷も次第に増加する。コールサーバの処理容量が最終的には最大値（つまり、コールサーバの全リソースが使用されている状態）に達する。それ以上の新しい発信の受け入れは、コールサーバを過負荷状態にして、呼の拒否が始まることになる（図１）。
【００２０】
コールサーバが新しい発信と関連して受けるシグナリングメッセージは「オフフック通知」として知られるものである。過負荷状態になったコールサーバは、オフフック通知の拒否を開始するが、その方法は以下の通りである。すなわち、コールサーバは、通常の方法で、オフフック・メッセージを処理し、呼を受け入れ、または、拒否する代わりに、さらに続いて、通常の応答、確認メッセージでメディアゲートウエイに応答する代わりに、メディアゲートウエイからのオフフック・メッセージへの応答を開始するが、この場合の応答は自動のＮＡＫ（否定応答）である。そのオフフック・メッセージにはコールサーバの過負荷レベルを知らせる内容が含まれている。このＮＡＫメッセージの作成は、通常のメッセージの処理と比較してきわめて効率的に実現できる。その理由は、ここで要求されることが、入ってくるメッセージを特定、点検して、新しい呼要求を特定するだけだからである。このことは、コールサーバに、処理オーバヘッドの負担をかけることなく実現可能であり、このために、直ちにコールサーバでの処理軽減が実現する一方、予防措置が取れるように、コールサーバの過負荷の内容をメディアゲートウエイに伝送する。
【００２１】
コールサーバからのＮＡＫメッセージを受け取り次第、メディアゲートウエイは以下のような応答動作を実行する。現時点で、メディアゲートウエイの拒否メカニズムが作動していなければ、それを作動させて、コールサーバにより示されるレベルの呼の拒否を開始する。拒否メカニズムがすでに作動していれば、メディアゲートウエイは拒否レベル（すなわち、メディアゲートウエイのフィルタメカニズムにより拒否された、メディアゲートウエイに供給された呼の部分）を修正する。メディアゲートウエイのフィルタメカニズムが、メッセージを受け入れるか拒否するかを決定する。そのメッセージがメディアゲートウエイのフィルタメカニズムにより受け入れられた場合、そのメッセージはコールサーバに戻されて、そのメッセージは、コールサーバの負荷制御メカニズムにより通常の処理がなされることになる。この場合、その負荷制御メカニズム自体が受け入れるか拒否するかを決定する。
【００２２】
コールサーバにどんな過負荷が発生しても、そのことは、同様な方法でメディアゲートウエイに通信され、それを受けて、メディアゲートウエイが呼フィルタメカニズムを適当に修正する。メディアゲートウエイのフィルタメカニズムが作動してないときに過負荷メッセージを受信した場合でも。フィルタメカニズムが呼び出されることになる。この場合に、メッセージは、再度コールサーバに送信されることはない。その理由は、コールサーバには、そのメッセージを処理するための資源（リソース）が不足しており、そのメッセージについては、コールサーバによりすでに拒否されているからである。
【００２３】
図４は、典型的な次世代ネットワークが、どのような形になるかを示したものである。図４が示すように、この次世代の新しいアーキテクチャでは、加入者回線はメディアゲートウエイとして知られるエンティティ（通信装置）に接続される。メディアゲートウエイは、コールサーバとして知られるクラス５の代替交換機に接続される。次世代ネットワークアーキテクチャでは、メディアゲートウエイの規模は、単独処理用のラインと２０００以上の加入者の回線群間では、変動があるが、これらの加入者回線はＩＰを介してコールサーバに接続されることになる。つまり、次世代ネットワークでは、コンセントレータ（集線装置）機能がネットワークから除去された形態となる。
【００２４】
このように、この新しいアーキテクチャでは、数千の回線、あるいは可能性としては、数千のメディアゲートウエイが単一のコールサーバに接続されることになる。したがって、その場合に要求されることは、すべての回線、メディアゲートウエイでの、発信の増加を適切なレベルに抑えて、コールサーバに過負荷を発生させないことだけである。例えば、遠隔投票サービスのようにメディアが誘発するイベントの場合、発信のレベルに大きな階梯の変化がある。次世代のネットワークアーキテクチャでは、そのようなイベントが、電話トラフィックを扱うコールサーバに過負荷を発生させ、サービスの完全な停止となってしまう可能性がある。明らかに、これは望まない結果であり、このことが発生するときは、緊急事態の処理能力、優先呼の処理能力も同時に麻痺するからである。それ故、サービスのロスを予防するためにメディアゲートウエイとコールサーバとの間での負荷を管理する必要性があるのである。
【００２５】
次世代で使用される信号方式標準（例えば、ＭＧＣＰ，Ｈ．２４８、ＳＩＰ）は、まだ完全には開発がされてはおらず、この部分を解決する提案もない。
【００２６】
ノードに供給された発信の数が、瞬時ピークの場合を除いて、ある時間長において、ノードの処理容量を越えるとノードに過負荷が発生する。ここで概説する制御管理方式の基本的な考え方は、ある特別なメッセージが過負荷を知らせるメッセージとしてメディアゲートウエイにより認識される場合、コールサーバが呼を拒否できること、コールサーバの過負荷状態がメディアゲートウエイに（個別または過負荷メッセージの一部として）戻すことができることである。この方式の長所は、メディアゲートウエイは、コールサーバからの情報に対応して、メディアゲートウエイからコールサーバに提供される新しい呼の数に制限を加えることができる点である。コールサーバでの過負荷レベルは、ある設定した時間長において拒否された呼の割合として定義できる。
【００２７】
コールサーバに供給される発信の数が増加するにつれて、この発信の増加に対応するために、コールサーバの処理負荷は確実に増加する。最後には、コールサーバの処理能力の最大値（つまり、コールサーバの全資源が使用されている状態）に達する。それ以上の新しい発信の受け入れは、コールサーバを過負荷状態にして、呼の拒否を始めることになる（つまり、図１に示されたような状態になる）。
【００２８】
コールサーバが新しい発信として受信するシグナリングメッセージは「オフフック通知」として知られるものであり、これは、従来の場合では、電話加入者が送受話器を上げることで開始されてきたものである。第一の実施例によれば、過負荷のコールサーバは、以下のような手順で、新しい呼に対応するオフフック通知の拒否を開始する。通常の方法で、呼を受け入れ、または、拒否する代わりに、あるいは、通常の応答・確認メッセージを使ってメディアゲートウエイに、呼の受け入れ・拒否を応答する代わりに、コールサーバは、メディアゲートウエイに対してＮＡＫ応答を開始する。このＮＡＫ応答には、（コールサーバで決定された）呼拒否の意味が含まれる。拒否の態様は、コールサーバからメディアゲートウエイに指示を出し、新しい呼の要求をコールサーバに転送しないで、新しい呼の要求のある割合をメディアゲートウエイが拒否するようにする。このＮＡＫメッセージの作成は、通常のメッセージの処理に比較してきわめて効率的に実現できる。その理由は、ここで要求されることは、入ってくるメッセージを特定、点検して、新しい呼要求を特定するだけだからである。このことは、コールサーバに、処理オーバヘッドの負担をかけることなく実現可能であり、このために、直ちにコールサーバでの処理軽減が実現する一方、予防措置が取れるように、コールサーバの過負荷の内容をメディアゲートウエイに伝送する。
【００２９】
メディアゲートウエイは、コールサーバからＮＡＫメッセージを受け取ると、以下のような応答をする。メディアゲートウエイの拒否メカニズムが現在作動していない場合、作動する状態になり、コールサーバが示すレベルで呼の拒否を開始する。拒否メカニズムがすでに作動していれば、メディアゲートウエイは適当に拒否レベルの修正を行う。メディアゲートウエイの拒否メカニズムが、このメッセージを受け入れるか拒否するかを選択をする。メディアゲートウエイの過負荷制御メカニズムにより、メッセージが受け入れられる場合、そのメッセージはコールサーバに戻され、コールサーバでは、コールサーバの負荷制御メカニズムにより通常の処理が行われる。この返信されたメッセージに対しては、コールサーバにより第二のＮＡＫが作成されることはない。その理由は、コールサーバが、この同じメッセージに対してＮＡＫを送信していることを記録しているからである。
【００３０】
拒否レベルを通知するには２つの方法がある。ひとつはＮＡＫであり、これは、オフフック・メッセージに対する即時の応答であり、もうひとつは、過負荷メッセージであり、これは、応答の流れの中できわめて遅い段階で送信されるものである。メディアゲートウエイからコールサーバに供給され、過負荷が原因でコールサーバから拒否されているメッセージあれば、メディアゲートウエイの呼拒否メカニズムの拒否レベルが適当に修正される。過負荷のメッセージを負荷制御メカニズムが作動していないメディアゲートウエイで受信すると、負荷制御メカニズムが呼び出される。この場合、コールサーバに再度供給されることはない。その理由は、そのメッセージが、コールサーバにはそれを処理するほどの資源がないために、すでにコールサーバにより拒否されているからである。
【００３１】
コールサーバでの過負荷が解消され、つまり、新しい呼要求がコールサーバにより受信され、その後に拒否される、新しい呼要求の割合がゼロになったとき、コールサーバからメディアゲートウエイへの過負荷メッセージに関する交信が停止する。これらのメッセージが停止した結果として、時間の経過とともに、メディアゲートウエイにおける新しい呼の拒否される割合が次第に減少する。
【００３２】
不要なメッセージの送信を回避するために、コールサーバが、ＮＡＫが送信されたメディアゲートウエイ側の通信記録を保持できることは長所である。この記録は、コールサーバの現在の過負荷レベルをメディアゲートウエイに戻す効率的な通信を可能にするために、コールサーバの過負荷が増加する度に、程度の低い過負荷に関してすでに通知したメッセージを含めて、更新（消去）されることが好ましい。
【００３３】
この方式の効果は、コールサーバに供給されている発信のレベルが過負荷の期間に大きく減少することである。これは、コールサーバが呼と正確に動作する能力を向上させ、特に、緊急事態や優先呼の処理などに適切にサポートする能力を維持できるとことである。
【００３４】
図５、６、７，８を参照して、本発明の第一の実施例について記載する。
【００３５】
図５は、インフォメーションモデルであり、「エンティティ・リレーション・ダイアグラム（通信装置相関図）」として知られるものである。図には、インフォメーションモデルを実行するためのデータ項目と、各データ項目間の関係が示されている。オブジェクト５である「ゲートウエイ」というのは、「メディアゲートウエイ」のことである。各ゲートウエイは、その特定のために使用する単一の属性「gateway_ id（ゲートウェイ識別情報）」を有する。各ゲートウエイは、さら２つの属性を有しており、そのひとつが、「reject_rate（拒否率）」である。これには、ゲートウエイにより拒否される呼の割合に関する情報が含まれる。もうひとつの属性は、「parent_id（親識別情報）」である。これは、このゲートウエイを制御しているコールサーバを特定するためのものである。さらに、各ゲートウエイは、状態変数「current_state（現在の状態）」という変数を有し、これは、そのステートマシン内におけるゲートウエイの位置を特定するための変数である。
【００３６】
オブジェクト４であるロード・インフォメーション・オブジェクト（負荷情報処理部）というのは、コールサーバに付加された新しい機能のことである。各コールサーバは、１つのロード・インフォメーションオ・ブジェクトを有し、コールサーバがどれだけ多くのメディアゲートウエイを制御するかに関係なく、このロード・インフォメーション・オブジェクトがコールサーバの識別用として使用される。このロード・インフォメーション・オブジェクトには単一の属性「reject_ rate」が含まれ、この属性には、全部のゲートウエイにより拒否される呼の割合に関する情報が含まれる。さらに、このロード・インフォメーション・オブジェクトには、状態変数「current_state」が含まれ、これが、ステートマシン内でのロード・インフォメーション・オブジェクトの状態の位置を特定する。
【００３７】
オブジェクト５であるゲートウエイ・ロード・インフォメーション・オブジェクトは、コールサーバが保持する各ゲートウエイに関するデータであり、ロード・インフォメーション・オブジェクト機能をサポートする。各ゲートウエイ・ ロード・インフォメーション・オブジェクトには、メディアゲートウエイごとの単一の属性「last_ reject_ rate（最終拒否率）」があり、呼が拒否されて最後にゲートウエイに通知された呼の割合を示すものである。このゲートウエイ・ロード・インフォメーション・オブジェクトは、コールサーバ上で稼動する。
【００３８】
図６は、「オブジェクト・コミュニケーション・モデル」を示しており、そのモデル内のオブジェクト間で送受信されるメッセージが図示されている。これらのメッセージの詳細については、図７と図８を参照しながら記載する。「インフォメーションモデル」に含まれる２つのステートマシン、すなわち、ゲートウエイ、および、ロード・インフォメーション・オブジェクトに加えて、図６には、４つのターミネータが示されている。
【００３９】
・エンドユーザ：これは、ネットワークの終端機器（例えば、電話の送受器など）と、それを使用している人である。
【００４０】
・タイマー：ゲートウエイの計時機能を担うタイマー。
【００４１】
・コールコントローラ：コールサーバの呼接続のための機能を有する。
【００４２】
・オペレーティングシステム：コールサーバのソフト機能を有する。
【００４３】
図７，８，１８，１９，２２，２３は、状態遷移図である。これらの状態遷移図では、各状態での内容は、各状態と関連づけられた動作を含めてボックスの形で示されている。ある状態と関連した動作が、その状態が現れる度に実行されていく。ステートマシンをシンプルな状態に保つために、オブジェクトである「ゲートウエイ」、および、「ロード・インフォメーション・オブジェクト」は、メッセージを、それらのオブジェクト自体に送信することができる。ステートマシンは、これらのメッセージを他のオブジェクトからのメッセージを処理する前に処理する。これらのステートマシンを初期化させるために、次のパターンが使用される。「Creating（作成処理）」という特別な状態に移行する場合、特別なメッセージ「Create（作成）」が使用される。この「Creating」と関連づけられた動作がなされると、オブジェクトデータが初期化され、メッセージ「Creation_Complete（作成完了）」が、オブジェクトに送信される。ある状態と関連づけられた動作の記述に加えて、各状態ボックスには、その各状態の動作により作成されたメッセージリストが順不同で配置されている。
【００４４】
図７は、第一実施例のゲートウエイの状態遷移図である。ゲートウエイの動作について図７を参照しながら説明する。
【００４５】
図７に示すように、ゲートウエイは、「Creating（作成処理）」の状態から、属性「reject_rate」の値として、適当なデフォルト値を設定して、状態２「Overloaded（過負荷）」に移行する。ゲートウエイは、メッセージを受け取るまで、状態２「Overloaded」にとどまる。ゲートウエイは、状態２「Overloaded」では、以下の６つあるメッセージのうちのいずれか１つを受け取ることになる。
【００４６】
・ゲートウエイを状態３「Process Timer（プロセスタイマー）」に遷移させる、タイマーからのメッセージ「ＧＷ３：Timer」。現在の属性「reject_rate」の値がゼロを越える（ゼロを含まない）場合、属性「reject_ rate」値を１だけ減ずる。属性「reject_rate」値がゼロ以下（ゼロを含まない）の場合、属性reject_rateの値をゼロに設定する。属性「reject_rate」の値がゼロに等しい場合、ゲートウエイは、メッセージ「ＧＷ４：Out_Of_Overload（非過負荷）」をゲートウエイ自身に送信し、その結果、ゲートウエイは、状態４である「Normal（通常）」に遷移する。ゼロでない場合、ゲートウエイは、メッセージ「GW:Stay_In_Overload（過負荷中）」をゲートウエイに送信し、その結果、ゲートウエイは、状態２である「Overloaded（過負荷）」に戻る。状態３である「Process Timer」に入力されている属性「reject_ rate」の値がゼロ以下（ゼロを含んで、それ以下）の場合、ゲートウエイは、メッセージ「GW４:Out_Of_Overload」をゲートウエイ自身に送信し、その結果、ゲートウエイは、状態４「Normal」に戻る。
【００４７】
・ゲートウエイを状態７「Handle_Neg_Ack（否定的応答処理）」に遷移させる、ロード・インフォメーション・オブジェクトからのメッセージ「GW6:Negative_Acknowledgement（否定応答）」。現時点での属性「reject_rate」の値が、受信したメッセージのパラメータ「new_ reject_ rate（新拒否率）」の値未満の場合には（パラメータ「new_ reject_ rate」の値を含まない）、属性「reject_rate」の値として、パラメータ「new_ reject_rate」の値を設定する。ゲートウエイは、メッセージ「GW5:Stay_In_Overload」をゲートウエイ自身に送信し、その結果、ゲートウエイは、動作の最後の時点において、状態２「Overloaded」に遷移する。その後、ゲートウエイは、メッセージ「GW8:Off_Hook（オフフック）」をゲートウエイ自身に送信し、その結果、否定応答を促したメッセージ「Off_Hook」が、状態９「Off_Hook_In_Overload（オフフック過負荷処理）」での動作によりフィルタリングされて除去される（図１８のGW8:Off_Hook下側参照）。
【００４８】
・ゲートウエイを状態５「Process_New_Load_Level（新規負荷レベル処理）」に遷移させる、ロード・インフォメーション・オブジェクトからのメッセージ「GW6:Load Level（負荷レベル）」。現時点での属性「reject_rate」値が、受信したメッセージのパラメータ「new_reject_rate（新規拒否率）」の値未満（パラメータnew_ reject_ rateの値を含まない）の場合、属性「reject_rate」の値を「new_reject_rate」の値に設定する。ゲートウエイは、メッセージ「GW5:Stay_In_Overload」をゲートウエイ自身に送信し、その結果、ゲートウエイは、動作の最後において、状態２である「Overloaded」に遷移する。
【００４９】
・ゲートウエイを、状態９「Off_Hook_In_Overload」に遷移させる、エンドユーザ・オブジェクトからのメッセージ「GW８:Off_Hook」。ゲートウエイは、現時点での属性「reject_rate」の値を基礎に、このメッセージ「Off_Hook」をコールサーバに送信するかどうかを決定する。オフフック・メッセージを送信するとの決定であれば、ゲートウエイは、メッセージ「LI6:Off_Hook」をコールサーバに送信して、そのイベント内容をコールサーバの親機に通知する。オフフック・メッセージを送信しないとの決定であれば、ゲートウエイは、そのことをエンドユーザに通知する。どちらの決定であっても、ゲートウエイは、メッセージ「GW5:Stay_In_Overload」をゲートウエイ自身に送信し、その結果、ゲートウエイは、状態２「Overloaded」に戻る。
【００５０】
・ゲートウエイを状態８「line_Event_In_Overload（回線イベント過負荷処理）」に遷移させるエンドユーザ・オブジェクトからのメッセージ「LI7:Other_Telephony_Event（他の電話イベント）」。ゲートウエイは、メッセージ「LI7:Other_Telephony_Event」をコールサーバに送信して、そのイベント内容をコールサーバに通知する。その後、ゲートウエイは、メッセージ「GW5:Stay_In_Overload」をゲートウエイ自身に送信し、その結果、ゲートウエイは、状態２「Overloaded」に戻る。
【００５１】
・ゲートウエイを状態１２「Overloaded_Response（過負荷応答）」に遷移させる、ロード・インフォメーション・オブジェクトからのメッセージ「GW10:Response（応答）」。ゲートウエイは, その応答を正常として処理する。その後、ゲートウエイは、メッセージ「GW5:Stay_In_Overload」をゲートウエイ自身に送信し、その結果、ゲートウエイは、状態２「Overloaded」に戻る。
【００５２】
ゲートウエイが、メッセージ「GW3:Timer」を十分に受信している場合、属性「reject_rate」の値はゼロまですでに下がり、ゲートウエイは、状態４「Normal」に遷移している。ゲートウエイは、メッセージを受信するまでは、状態４「Normal」にとどまる。この状態で、ゲートウエイは、次の５つあるメッセージのうちのいずれかを受信することになる。
【００５３】
・ゲートウエイを、状態３「Process Timer」に遷移させる、タイマーオブジェクトからのメッセージ「GW3:Timer」。状態３「Process Timer」に入る属性「reject_rate」の値がゼロ以下（ゼロを含んで、それ以下）の場合、ゲートウエイは、メッセージ「GW4:Out_Of_Overload」をゲートウエイ自身に送信し、その結果、ゲートウエイは、状態４「Normal」に戻る。
【００５４】
・ゲートウエイを状態７「Handle_Neg_Ack」に遷移させる、ロード・インフォメーション・オブジェクトからのメッセージ「GW6:Negative_Acknowlegement（否定的応答）」。現時点での属性「reject_rate」の値がゼロの場合、それは、メッセージで受信したパラメータ「new_ reject_ rate」の値未満（パラメータ値を含まない）となり、属性「reject_rate」の値を、パラメータ「new_ reject_ rate」の値に設定する。ゲートウエイは、メッセージ「GW5:Stay_In_Overload」をゲートウエイ自身に送信し、その結果、ゲートウエイは、動作の最後で、状態２「Overloaded」に遷移する。その後、ゲートウエイは、メッセージ「GW8:Off_Hook」をゲートウエイ自身に送信すると、その結果、否定応答を促したオフフック・メッセージが、状態９「Off_Hook_In_Overload」での動作によりフィルタリングして除去される（GW8:Off_Hook下側参照）。
【００５５】
・ゲートウエイを、状態５「Process_New_Load_Level」に遷移させる、ロード・インフォメーション・オブジェクトからのメッセージ「GW7:Load Level」。現時点での属性「reject_rate」の値がゼロの場合、それは、メッセージで受信したパラメータ「new_ reject_ rate」の値未満（パラメータ値を含まない）となり、属性「reject_rate」の値を、パラメータ「new_reject_rate」の値に設定する。ゲートウエイは、メッセージ「GW5:Stay_In_Overload」をゲートウエイ自身に送信し、その結果、ゲートウエイは、状態２「Overloaded」に遷移する。
【００５６】
・ゲートウエイを、状態１０「Off_Hook_Normal」に遷移させる、エンドユーザ・オブジェクトからのメッセージ「GW８:Off_Hook」。ゲートウエイは、メッセージ「LI6:Off_Hook」をコールサーバに送信して、そのイベント内容をコールサーバの親機に通知する。その後、ゲートウエイは、メッセージ「GW4:Out_Of_Overload」をゲートウエイ自身に送信し、その結果、ゲートウエイは、状態４「Normal」に戻る。
【００５７】
・ゲートウエイを、状態６「line_Event_Normal」に遷移させる、エンドユーザ・オブジェクトからのメッセージ「GW9:Other_Telephony_Event」。ゲートウエイは、メッセージ「LI7:Other_Telephony_Event」をコールサーバの親機に送信して、そのイベント内容をコールサーバの親機に通知する。その後、ゲートウエイは、メッセージ「GW4:Out_Of_Overload」をゲートウエイ自身に送信し、その結果、ゲートウエイは、状態４「Normal」に戻る。
【００５８】
・ゲートウエイを、状態11「Normal_Response」に遷移させる、ロードインフォメーション・オブジェクトからのメッセージ「GW10:Respnse」。ゲートウエイは, その応答を正常メッセージとして処理する。その後、ゲートウエイは、メッセージ「GW4:Out_Of_Overload」をゲートウエイ自身に送信し、その結果、ゲートウエイは、状態４「Normal」に戻る。
【００５９】
図８は、ロード・インフォメーション・オブジェクトの状態遷移図である。ロード・インフォメーション・オブジェクトの動作を、図８を参照して記載する。
【００６０】
図８に示されているように、ロード・インフォメーション・オブジェクトは、属性「reject_rate」の値をゼロに設定して、「Creating（作成処理）」状態から、状態２「Normal」に遷移する。ロード・インフォメーション・オブジェクトは、メッセージを受信するまで、状態２「Normal」にとどまる。ロードインフォメーション・オブジェクトは、この状態で、次の５つあるメッセージのうちのいずれかを受信する。
【００６１】
・ロード・インフォメーション・オブジェクトを、状態４「Check_Load_Level（負荷レベル確認処理）」に遷移させる、オペレーティングシステム・オブジェクトからのメッセージ「LI3:Load_Level」。属性「reject_rate」の値は、受信した「Load_Level」メッセージに含まれるパラメータ「new_ reject_ rate」の値に設定する。属性「reject_rate」の値がゼロであれば、コールサーバにより制御される各ゲートウエイに対して、ロード・インフォメーション・オブジェクトは、ゲートウエイと関連づけられた属性「last_reject_rate」値をゼロに設定し、その後、メッセージ「LI５ Out_ of_Overload」を、ロード・インフォメーション・オブジェクトに送信し、その結果、ロード・インフォメーション・オブジェクトは、状態２「Normal」に遷移する。属性「reject_rate」の値がゼロでない場合、ロード・インフォメーション・オブジェクトは、メッセージ「LI4: Into_ Overload（過負荷状態へ）」をロード・インフォメーション・オブジェクト自身に送信し、その結果、ロード・インフォメーション・オブジェクトを状態３「Overloaded」に遷移させる（下記を参照）。
【００６２】
・ロード・インフォメーション・オブジェクトを、状態８「Normal _ Off _ Hook（通常オフフック）」に遷移させる、ゲートウエイ・オブジェクトからのメッセージ「LI3 Off_Hook」。ロード・インフォメーション・オブジェクトは、メッセージ「CC1:Off_ Hook」をコールコントローラに送信して、そのイベント内容をコールコントローラに通知する。その後、ロード・インフォメーション・オブジェクトは、メッセージ「LI5:Out_Of_Overload」を、ロード・インフォメーション・オブジェクト自身に送信し、その結果、ロード・インフォメーション・オブジェクトは、状態２「Normal」に戻る。
【００６３】
・ロード・インフォメーション・オブジェクトを、状態５「Normal_Telephony_Event（通常電話イベント）」に遷移させる、ゲートウエイ・オブジェクトからのメッセージ「LI7: Other_Telephony_Event」。ロード・インフォメーション・オブジェクトは、メッセージ「LI7:Other_Telephony_Event」をコールコントローラに送信して、そのイベント内容をコールコントローラに通知する。その後、ロード・インフォメーション・オブジェクトは、メッセージ「LI5:Out_Of_Overload」を ロード・インフォメーション・オブジェクト自身に送信し、その結果、ロード・インフォメーション・オブジェクトは、状態２「Normal」に戻る。
【００６４】
・ロード・インフォメーション・オブジェクトを、状態１２「Normal_Reject」に遷移させる、コール・コントローラ・オブジェクトからのメッセージ「LI8: Reject_Call_For_Load（負荷呼の拒否）」。このメッセージ「L18: Reject_Call_For_Load」は、特別な応答であり、コールコントローラがビジーであるために、呼を処理できないことを示している。このメッセージ「LI8:Reject_Call_For_Load」は、ロード・インフォメーション・オブジェクトの状態が、状態２「Normal」であるときには着信可能である。その理由は、コールコントローラの拒否メカニズムは、ロード・インフォメーション・オブジェクトのメカニズムとは独立して作動するものであり、コールコントローラは、すべての呼がゲートウエイで受信されている間、呼を拒否できる（つまり、ゲートウエイのフィルタリング動作）はない）。ロード・インフォメーション・オブジェクトは、メッセージ「GW10:Response」をゲートウエイ送信して、そのイベント内容を、受信したメッセージ「Reject_Call_For_Load」に含まれるパラメータ「gateway_id」により特定されたゲートウエイに通知する。その後、ロード・インフォメーション・オブジェクトは、メッセージ「LI5:Out_Of_Overload」を ロード・インフォメーション・オブジェクト自身に送信し、その結果、ロード・インフォメーション・オブジェクトは、状態２「Normal」に戻る。
【００６５】
・ロード・インフォメーション・オブジェクトを、状態１１「Normal _ Response」に遷移させる、コール・コントローラ・オブジェクトからのメッセージ「LI9:Response」。ロード・インフォメーション・オブジェクトは、メッセージ「GW10:Response」をゲートウエイに送信して、そのイベント内容を、受信したメッセージ「LI9:Response」に含まれるパラメータ「gateway_id」により特定されたゲートウエイに通知する。その後、ロード・インフォメーション・オブジェクトは、メッセージ「LI5:Out_Of_Overload」を、ロード・インフォメーション・オブジェクト自身に送信し、その結果、ロード・インフォメーション・オブジェクトは、状態２「Normal」に戻る。
【００６６】
ロード・インフォメーション・オブジェクトが、オペレーティングシステムから、ゼロを越えるパラメータ「new_reject_rate」と共に、メッセージ「LI3:Load_Level」を受信していれば、状態３「Overloaded」に遷移している。ロード・インフォメーション・オブジェクトは、メッセージを受信するまで、状態３「Overloaded」にとどまる。ロードインフォメーション・オブジェクトは、この状態で、次の５つあるメッセージのうちのいずれかを受信する。
【００６７】
・ロード・インフォメーション・オブジェクトを、状態３「Check_Load_Level（負荷レベルの確認）」に遷移させる、オペレーティングシステムからのメッセージ「LI3:Load_Level」。属性「reject_rate」値を、受信したメッセージ「Load_Level」に含まれるパラメータ「new_reject_rate」に設定する。属性「reject_rate」値が、現在ゼロである場合、ロード・インフォメーション・オブジェクトが、コールサーバにより制御される各ゲートウエイに対して、それぞれのゲートウエイの属性「last_reject_rate」値をゼロに設定する。その後、ロード・インフォメーション・オブジェクトは、メッセージ「L5:Out_Of_Overload」を、ロード・インフォメーション・オブジェクト自身に送信し、その結果、ロード・インフォメーション・オブジェクトは、状態２「Normal」に戻る。属性「reject_rate」値が、ゼロでない場合、ロード・インフォメーション・オブジェクトは、メッセージ「LI4:Into_Overload」を、ロード・インフォメーション・オブジェクト自身に送信し、その結果、ロード・インフォメーション・オブジェクトは、状態３「Overloaded」に戻る。
【００６８】
・ロード・インフォメーション・オブジェクトを、状態６「Overloaded_Off_Hook」に遷移させる、ゲートウエイ・オブジェクトからのメッセージ「LI6:Off_Hook」。属性「reject_rate」の現在の値が受信したメッセージに含まれるパラメータ「gateway_id」により特定されるゲートウエイと関連づけられた属性「last_reject_rate」の値を越える（その値を含まない）場合、ロード・インフォメーション・オブジェクトは、現時点での属性「reject_rate」の値をパラメータとして使用して、メッセージ「GW6: Negative_Acknowledge」を、その特定されたゲートウエイに送信し、その特定されたゲートウエイに関連づけられた属性「last_reject_rate」を、現時点での属性「reject_rate」の値として設定する。そうでない場合、ロード・インフォメーション・オブジェクトは、メッセージ「CC1:Off_Hook」をコールコントローラに送信することで、イベント内容をコールコントローラに通知する。その後、ロード・インフォメーション・オブジェクトは、メッセージ「LI4:Into_Overload」を ロード・インフォメーション・オブジェクト自身に送信し、その結果、ロード・インフォメーション・オブジェクトは、状態３「Overloaded」に戻る。
【００６９】
・ロード・インフォメーション・オブジェクトを状態７「Overload_Other_Event」に遷移させる、ゲートウエイ・オブジェクトからのメッセージ「LI7:Other_Telephony_Event」。ロード・インフォメーション・オブジェクトは、メッセージ「CC2:Other_Telephony_Event」をコールコントローラに送信することで、イベント内容をコールコントローラに通知する。その後、ロード・インフォメーション・オブジェクトは、メッセージ「LI4:Into_Overload」を ロード・インフォメーション・オブジェクト自身に送信し、その結果、ロード・インフォメーション・オブジェクトは、状態３「Overloaded」に戻る。
【００７０】
・ロード・インフォメーション・オブジェクトを、状態９「Overloaded_ Reject」に遷移させる、コール・コントローラ・オブジェクトからのメッセージ「LI8:Reject_Call_for_Load」。ロード・インフォメーション・オブジェクトは、受信したメッセージ「LI8:Reject_Call_for_Load」に含まれるパラメータ「gateway_id」により特定されるゲートウエイに、メッセージ「GW10: Response」を送信することで、イベント内容をゲートウエイに通知する。その後、ロード・インフォメーション・オブジェクトは、現時点での属性「reject_rate」の値をパラメータとして使用して、メッセージ「GW7: Load_Level」を特定されたゲートウエイに送信することにより、適用すべき拒否率(reject rate)を、ゲートウエイに通知して、その特定されたゲートウエイに関連づけられた属性「last_reject_rate」の値を、現在の属性「reject_rate」の値として設定する。その後、ロード・インフォメーション・オブジェクトは、メッセージ「LI4:Into_Overload」を ロード・インフォメーション・オブジェクト自身に送信し、その結果、ロード・インフォメーション・オブジェクトは、状態３「Overloaded」に戻る。
【００７１】
・ロード・インフォメーション・オブジェクトを、状態１０「Overloaded_Response」に遷移させる、コール・コントローラ・オブジェクトからのメッセージ「LI9:Response」。ロード・インフォメーション・オブジェクトは、受信したメッセージ「LI9:Response」に含まれるパラメータ「gateway_id」により特定されるゲートウエイに、メッセージ「GW10:Response」をゲートウエイに送信することで、イベント内容をゲートウエイに通知する。その後、ロード・インフォメーション・オブジェクトは、メッセージ「LI4:Into_Overload」を ロード・インフォメーション・オブジェクト自身に送信し、その結果、ロード・インフォメーション・オブジェクトは、状態３「Overloaded」に戻る。
【００７２】
別の実施例によれば、緊急サービスやライフライン・サービスは、現在、英国では９９９、ヨーロッパでは１１２、北アメリカでは９１１の番号でアクセスできるが、本実施例では、このサービスは、メディアゲートウエイによりサポートされており、メディアゲートウエイが、この緊急・ライフラインを知らせる十分な数字(電話番号)を受信して集めたかどうかにより、このサービスが要請されているかどうかを決定する。そのような緊急・ライフライン要請を知らせる呼の場合、拒否フィルタをバイパスして、加入者コールがコールサーバに常に接続されることになる。優先事態に対応するための同様なサポートがほかにも提供されており、システムが過負荷であっても、エンドユーザに保証されたサービスの一部として提供されることは、このシステムの長所である。この実施例では、このような場合、コールサーバはメディアゲートウエイに、優先ユーザをサポートするためにメディアゲートウエイに接続された回線があること通知し、そのような回線からの呼は、呼拒否のフィルタをバイパスして常にコールサーバに提供されるようになっている。さらに別の実施例によれば、優先呼があった場合、その呼が接続に成功するように、拒否制御の緩やかな第二番目のフィルタに呼が接続されて、その優先呼がつながるようにしている。乱数表を用意して統計的な手法で優先呼を拒否するかどうかのフィルタリング機能を実現している実施例があるが、この発明の長所でもある。このフィルタリング機能を作動させるかどうか決定は、現時点での呼の拒否率が含まれている乱数表を使用して、その次に続く数字と、現時点での拒否率の数値を比較することにより実現している。その数字が拒否率を示す数値より大きいときにだけ、メッセージがコールサーバに届くようになっている。
【００７３】
さらに別の実施例によれば、コールエージェントに大きな過負荷が検知され、呼の拒否率が１００を越えた場合、つまり、メディアゲートウエイがライフライン要請の呼、および、優先呼を示す電話番号を受信した場合、関連メディアゲートウエイ内のフィルタは、他の呼を受け付けず、すべての呼を拒否するように指示されることになる。
【００７４】
ここで、図５乃至図１７を参照して第二の実施例を記載する。第二の実施例によれば、ゲートウエイに対するすべての応答メッセージに拒否率の情報を搭載する。第二の実施例では、コールサーバの負荷の変化に対応した確実で迅速な応答が実現するが、これは、本発明の長所である。第二の実施例のインフォメーションモデルは、図５に示されているように、第一の実施例と同じである。第二の実施例をさらに詳しく以下に述べる。
【００７５】
図１７に示されているように、第二実施例のオブジェクト・コミュニケーション・モデルは、第一実施例と同じようにステートマシンと端子（ターミネータ）から構成されており、ここでは、それらについて詳しくは記載しない。メッセージは第一実施例とは異なるので、以下に述べる。
【００７６】
図１８は、第二実施例のゲートウエイの状態遷移図である。図１８を参照しながら、ゲートウエイの動作について述べる。
【００７７】
ゲートウエイは、「Creating（作成）」の状態から、属性「reject_rate」の値として、適当なデフォルト値を設定して、状態２「Overloaded（過負荷）」に移行する。ゲートウエイは、メッセージを受け取るまで、状態２「Overload」にとどまる。ゲートウエイは、状態２「Overload」では、以下の５つあるメッセージのうちのいずれか１つを受け取ることになる。
・ゲートウエイを状態３「Process Timer」に遷移させる、タイマーオブジェクトからのメッセージ「ＧＷ３：Timer」。現在の属性「reject_ rate」の値がゼロを越える（ゼロを含まない）場合、属性「reject_ rate」値を１だけ減算する。属性「reject_ rate」の値がゼロ未満（ゼロを含まない）の場合、属性reject_ rateの値をゼロに設定する。属性「reject_ rate」の値がゼロに等しい場合、ゲートウエイが、メッセージ「ＧＷ４：Out_Of_Overload」をゲートウエイ自身に送信し、その結果、ゲートウエイは、状態４「Normal（通常）」に遷移する。ゼロでない場合、ゲートウエイが、メッセージ「GW:Stay_In_Overload」をゲートウエイ自身に送信し、その結果、ゲートウエイは、状態２「Overloaded」に戻る。状態３「Process Timer」に入力されている属性「reject_ rate」の値がゼロ以下（ゼロを含む）の場合、ゲートウエイは、メッセージ「GW４:Out_Of_Overload」をゲートウエイ自身に送信し、その結果、ゲートウエイは、状態４「Normal」に戻る。
【００７８】
・ゲートウエイを、状態７「Handle_Neg_Ack」に遷移させる、ロード・インフォメーション・オブジェクトからのメッセージ「GW6:Negative_Acknowledgement」。現時点での属性「reject_rate」の値が、受信したメッセージに含まれるパラメータ「new_reject_rate」の値未満の場合には（パラメータnew_ reject_rateの値を含まない）、属性「reject_rate」の値として、パラメータ「new_ reject_rate」の値を設定する。ゲートウエイは、メッセージ「GW5:Stay_In_Overload」をゲートウエイ自身に送信し、その結果、ゲートウエイは、動作の最後の時点において、状態２「Overloaded」に遷移する。その後、ゲートウエイは、メッセージ「GW8:Off_Hook」をゲートウエイ 自身に送信し、その結果、メッセージ「Off Hook」が、状態９「Off_Hook_In_Overload」の動作によりフィルタリングされて除去される（図１８のGW8:Off_Hook下側参照）。
【００７９】
・ゲートウエイを、状態９「Off_Hook_In_Overload」に遷移させる、「エンドユーザ」オブジェクトからのメッセージ「GW８:Off_Hook」。ゲートウエイは、現時点での属性「reject_rate」の値で、このメッセージ「Off _Hook 」をコールサーバに送信すべきかどうかを決定する。メッセージ「Off_Hook」を送信するとの決定であれば、ゲートウエイは、メッセージ「LI6:Off_Hook」をコールサーバに送信して、そのイベント内容をコールサーバの親機に通知する。オフフック・メッセージを送信しないとの決定であれば、ゲートウエイは、そのことをエンドユーザに通知する。どちらの決定であれ、ゲートウエイは、メッセージ「GW5:Stay_In_Overload」をゲートウエイ自身に送信し、その結果、ゲートウエイは、状態２「Overload」に戻る。
【００８０】
・ゲートウエイを、状態８「Line_Event_In_Overload」に遷移させるエンドユーザ・オブジェクトからのメッセージ「GW9:Other_Telephony_Event」。ゲートウエイは、メッセージ「LI7:Other_Telephony_Event」をコールサーバに送信して、そのイベント内容をコールサーバの親機に通知する。その後、ゲートウエイは、メッセージ「GW5:Stay_In_Overload」をゲートウエイ自身に送信し、その結果、ゲートウエイは、状態２「Overloaded」に戻る。
【００８１】
・ゲートウエイを、状態１２「Overload_Response」に遷移させる、ロード・インフォメーション・オブジェクトからのメッセージ「GW10:Response」。ゲートウエイは、現時点での属性「reject_rate」の値が、受信したメッセージに含まれるパラメータ「new_reject_rate」の値未満の場合には（パラメータnew_ reject_rateの値を含まない）、属性「reject_rate」の値として、パラメータ「new_ reject_rate」の値を設定する。ゲートウエイは、その応答を正常として処理する。その後、ゲートウエイは、メッセージ「GW5:Stay_ In_ Overload」をゲートウエイ自身に送信し、その結果、ゲートウエイは、状態２「Overload」に戻る。
【００８２】
ゲートウエイが、メッセージ「GW3:Timer」を十分に受信した場合、属性「reject_rate」の値はゼロまで下がり、ゲートウエイは、状態４「Normal」に遷移する。ゲートウエイは、メッセージを受信するまで、状態４「Normal」にとどまる。この状態で、ゲートウエイは、次の５つあるメッセージのうちのいずれかを受信することになる。
【００８３】
・ゲートウエイを、状態３「Process Timer」に遷移させる、タイマーオブジェクトからのメッセージ「GW3:Timer」。状態３「Process Timer」に入る属性「reject_rate」の値がゼロ以下（ゼロを含む）の場合、ゲートウエイは、メッセージ「GW4:Out_Of_Overload」をゲートウエイ自身に送信し、その結果、ゲートウエイは、状態４「Normal」に戻る。
【００８４】
・ゲートウエイを、状態７「Handle_Neg_Ack」に遷移させる、ロード・インフォメーション・オブジェクトからのメッセージ「GW6:Negative_Acknowlegement」。現時点での属性「reject_rate」の値が、受信したメッセージ「Negative_Acknowlegement」に含まれる、パラメータ「new_ reject_ rate」の値未満の場合には（パラメータnew_reject_rateの値を含まない）、属性「reject_rate」を、パラメータ「new_ reject_rate」値として設定する。ゲートウエイは、メッセージ「GW5:Stay_In_Overload」をゲートウエイ自身に送信し、その結果、ゲートウエイは、動作の最後で、状態２「Overloaded」に遷移する。その後、ゲートウエイは、メッセージ「GW8:Off_Hook」をゲートウエイ自身に送信し、その結果、メッセージ「Off Hook」は、状態９「Off_Hook_In_Overload」の動作により除去される（GW8:Off_Hook下側参照）。
【００８５】
・ゲートウエイを、状態１０「Off_Hook_Normal」に遷移させる、エンドユーザ・オブジェクトからのメッセージ「GW８:Off_Hook」。ゲートウエイは、メッセージ「LI6:Off_ Hook」をコールサーバに送信して、そのイベント内容をコールサーバの親機に通知する。その後、ゲートウエイは、メッセージ「GW4:Out_Of_Overload」をゲートウエイ自身に送信し、その結果、ゲートウエイは、状態４「Normal」に戻る。
【００８６】
・ゲートウエイを、状態６「Line_Event_Normal」に遷移させる、エンドユーザ・オブジェクトからのメッセージ「GW9:Other_Telephony_Event」。ゲートウエイは、メッセージ「LI7:Other_Telephony_Event」をコールサーバに送信して、そのイベント内容をコールサーバの親機に通知する。その後、ゲートウエイは、メッセージ「GW4:Out_Of_Overload」をゲートウエイ自身に送信し、その結果、ゲートウエイは、状態４「Normal」に戻る。
【００８７】
・ゲートウエイを、状態１1「Normal_Response」に遷移させる、ロード・インフォメーション・オブジェクトからのメッセージ「GW10:Response」。受信したメッセージ「Response_message」に含まれるパラメータ「new_reject_rate」の値が、ゼロ未満の場合には（ゼロを含まない）、属性「reject_rate」の値が、パラメータ「new_ reject_rate」の値に設定され、ゲートウエイは、メッセージ「GW5:Stay_ In_ Overload」をゲートウエイ自身に送信し、その結果、動作の最後の時点で、ゲートウエイは、状態２「Overload」に戻る。そうでない場合、ゲートウエイは、メッセージ「GW4:Out_ Of_ Overload」をゲートウエイ自身に送信し、その結果、動作の最後の時点で、ゲートウエイは、状態4「Overload」に戻る。ゲートウエイは、その応答を正常として処理する。
【００８８】
図１９は、第二実施例のロード・インフォメーション・オブジェクトの状態遷移図である。図１９を参照して、ロード・インフォメーション・オブジェクトの動作について図１９を参照して述べる。
【００８９】
ロード・インフォメーション・オブジェクトは、「Creating（作成処理）」の状態から、属性「reject_rate」の値をゼロに設定して、状態２「Normal（通常）」に移行する。ロード・インフォメーション・オブジェクトは、メッセージを受け取るまで、状態２「Normal」にとどまる。ロード・インフォメーション・オブジェクトは、状態２「Normal」では、以下の4つあるメッセージのうちのいずれか１つを受け取ることになる。
【００９０】
・ロード・インフォメーション・オブジェクトを、状態4「Check_Load Level」に遷移させる、オペレーティングシステムからのメッセージ「Check:Load_Level」。属性「reject_rate」の値を、受信されたメッセージ「Load_Level」に含まれるパラメータ「new_ reject_rate」値に設定する。この属性「reject_rate」の値が、現時点で、ゼロである場合、ロード・インフォメーション・オブジェクトは、コールサーバにより制御される、それぞれのゲートウエイに関連づけられた属性「last_ reject_rate」の値をゼロに設定して、その後、メッセージ「LI5:Out_Of_Overload」をロード・インフォメーション・オブジェクト自身に送信し、その結果、状態２「Normal」に遷移することになる。この属性「reject_rate」の値がゼロでない場合、メッセージ「LI4:Into_Overload」をロード・インフォメーション・オブジェクト自身に送信し、その結果、状態３「Overloaded」に遷移する。
【００９１】
・ロード・インフォメーション・オブジェクトを、状態８「Normal _Off_Hook」に遷移させる、ゲートウエイからのメッセージ「LI6:Off _Hook」。ロード・インフォメーション・オブジェクトは、メッセージ「CC1:Off_Hook」をコールコントローラに送信し、イベント内容をコールコントローラに通知する。その後、ロード・インフォメーション・オブジェクトは、メッセージ「LI5:Out_Of_Hook（フック終了）」をロード・インフォメーション・オブジェクト自身に送信して、その結果、状態２「Normal」に戻る。
【００９２】
・ロード・インフォメーション・オブジェクトを、状態５「Normal _Telephony_Event」に遷移させる、ゲートウエイからのメッセージ「LI7:Other_Telephony_Hook（他の電話によるフック）」。ロード・インフォメーション・オブジェクトは、メッセージ「CC２:Other_Telephony_Hook」をコールコントローラに送信し、イベント内容をコールコントローラに通知する。その後、ロード・インフォメーション・オブジェクトは、メッセージ「LI5:Out_Of_Overload」をロード・インフォメーション・オブジェクト自身に送信して、その結果、状態２「Normal」に戻る。
【００９３】
・ロード・インフォメーション・オブジェクトを、状態１１「Normal _Response」に遷移させる、ゲートウエイからのメッセージ「LI9:Response」。ロード・インフォメーション・オブジェクトは、現時点での属性「reject_rate」の値をパラメータとして使用して、受信したメッセージ「LI9:Response」に含まれるパラメータ「gateway_id」により特定されるゲートウエイに、メッセージ「GW10: Response」を送信することで、イベント内容をゲートウエイに通知する。ロード・インフォメーション・オブジェクトは、特定されたゲートウエイに関連づけられた属性「last_ reject_rate」の値を、現時点での属性「reject_rate」の値に設定する。その後、ロード・インフォメーション・オブジェクトは、メッセージ「LI5:Out_Of_Overload」をロード・インフォメーション・オブジェクト自身に送信して、その結果、状態２「Normal」に戻る。
【００９４】
ロード・インフォメーション・オブジェクトが、ゼロを越える（ゼロを含まない）パラメータ「new_ reject_rate」値を有するメッセージ「LI3:Load_Level」を受信している、状態３「Overloaded」に遷移している。ロード・インフォメーション・オブジェクトは、メッセージを受け取るまで、その状態３「Overloaded」にとどまる。ロード・インフォメーション・オブジェクトは、状態３「Overloaded」では、以下の4つあるメッセージのうちのいずれか１つを受け取ることになる。
【００９５】
・ロード・インフォメーション・オブジェクトを、状態４「Check_Load_Level」に遷移させる、オペレーティングシステムからのメッセージ「LI3:Load_Level」。属性「reject_rate」は、受信したメッセージ「LI3:Load_Level」に含まれるパラメータ「new_ reject_rate」値に設定される。属性「reject_rate」の値がゼロの場合は、ロード・インフォメーション・オブジェクトは、コールサーバにより制御されて各ゲートウエイに関連づけられた属性「last_ reject_rate」の値をゼロに設定する。その後、ロード・インフォメーション・オブジェクトは、メッセージ「LI5:Out_Of_Overload」をロード・インフォメーション・オブジェクト自身に送信して、その結果、状態２「Normal」に遷移する。属性「reject_rate」の値がゼロでない場合、ゲートウエイは、メッセージ「LI4:Into_Overload」をゲートウエイに送信し、その結果、ゲートウエイは、状態３「Overloaded」に遷移する。
【００９６】
・ロード・インフォメーション・オブジェクトを、状態６「Overload_Off_Hook」に遷移させる、ゲートウエイ・オブジェクトからのメッセージ「LI6:Off_Hook」。現時点での属性「reject_rate」の値が受信したメッセージ「LI6:Off_Hook」に含まれるパラメータ「gateway_id」により特定されるゲートウエイに関連づけられた属性「last_ reject_rate」の値を越えている場合、ロード・インフォメーション・オブジェクトは、現時点での属性「reject_rate」の値をパラメータとして使用して、メッセージ「GW6:Negative_Acknowlegement」を、その特定されたゲートウエイに送信し、その特定されたゲートウエイと関連づけられた属性「last_ reject_rate」の値を、現時点での属性「reject_rate」の値として設定する。そうでない場合、ロード・インフォメーション・オブジェクトは、メッセージ「CC1:Off_Hook」をコールサーバに送信することでイベントの内容をコールコントローラに通知する。その後、ロード・インフォメーション・オブジェクトは、メッセージ「LI4:Into_Overload」をロード・インフォメーション・オブジェクト自身に送信して、その結果、状態３「Normal」に戻る。
【００９７】
・ロード・インフォメーション・オブジェクトを、状態７「Overload_Other_Event」に遷移させる、ゲートウエイ・オブジェクトからのメッセージ「LI7:Other_Telephony_Event」。ロード・インフォメーション・オブジェクトは、メッセージ「CC2:Other_Telephony_Event」をコールコントローラに送信して、イベント内容をコールコントローラに通知する。その後、ロード・インフォメーション・オブジェクトは、メッセージ「LI4:Into_Overload」をロード・インフォメーション・オブジェクト自身に送信して、その結果、状態３「Overloaded」に戻る。
【００９８】
・ロード・インフォメーション・オブジェクトを、状態１０「Overloaded_Response」に遷移させる、ゲートウエイ・オブジェクトからのメッセージ「LI9:Response」。ロード・インフォメーション・オブジェクトは、現時点での属性「reject_rate」の値をパラメータとして使用して、受信したメッセージ「LI9:Response」に含まれるパラメータ「gateway_id」により特定されるゲートウエイに、メッセージ「GW10: Response」を送信することで、イベント内容をゲートウエイに通知する。ロード・インフォメーション・オブジェクトは、特定されたゲートウエイに関連づけられた属性「last_reject_rate」の値を、現時点での属性「reject_rate」の値として設定する。その後、ロード・インフォメーション・オブジェクトは、メッセージ「LI4:Into_Overload」をロード・インフォメーション・オブジェクト自身に送信して、その結果、状態３「Overloaded」に戻る。
【００９９】
第三の実施例を図２０乃至２３を参照しながら説明する。第三の実施例によれば、ゲートウエイがコールサーバからメッセージを受信しないと、ゲートウエイの拒否率（reject rate）が上がる。メディアゲートウエイとコールサーバとの間の通信が喪失するか、あるいは、中断があっても、正確な動作をするので、これは、第三実施例の長所である。図２０に示すように、第三実施例のインフォメーションモデルでは、第一実施例と第二実施例の機能を拡張しており、ロード・インフォメーション・オブジェクトに対して、属性「recent (リーセント)」を追加し、オブジェクト２であるゲートウエイに対して属性「timer_count（タイマーカウント値）」を追加している。新しい属性である「recent」は、ブール論理値であり、コールサーバが、最近の時点で、属性「reject_rate」をゲートウエイに送信したかどうかを示すものである。「TRUE（真）」の時は、最近において、メッセージが送信されたことを示している。さらに、新しい属性である「timer_count」は、属性「reject_rate」値が、前回、ゲートウエイに書き込みがなされた後から現時点までの間に発信されたタイマーメッセージの数の合計（整数値）を示す。
【０１００】
第三実施例のオブジェクト・コミュニケーション・モデルは、図２１に示すとおり、第一実施例と第二実施例と部分的に同じであり、その詳細については記載しない。このモデルは、第一実施例と第二実施例のモデルを拡張したものであり、新しいターミネータとして「CS Timer」が追加されており、これは、コールサーバのタイミング機能を示している。各メッセージは、メッセージ「LI8:Reject_Call_For_Load」が削除されている点を除いて、基本的に第一実施例でのメッセージと同じである。
【０１０１】
図２２は、第三実施例のゲートウエイの状態遷移図である。このゲートウエイの動作について、図２２を参照しながら、以下に説明する。
【０１０２】
ゲートウエイは、「Creating（作成）」の状態から、属性「reject_rate」と属性「timer_count」の値として、適当なデフォルト値を設定して、状態２「Overloaded」に移行する。ゲートウエイは、メッセージを受け取るまで、状態２「Overloaded」にとどまる。ゲートウエイは、状態２「Overloaded」では、以下の６つあるメッセージのうちのいずれか１つを受け取ることになる。
【０１０３】
・ゲートウエイ・オブジェクトを、状態３「Process Timer」に遷移させる、ゲーウエイ・タイマー・オブジェクトからのメッセージ「GW3:Timer」。属性「timer_count」の現時点での値が、事前に定義してある限度値(REFRESH_LIMIT)未満であれば（限度値を含まない）、属性「timer_count」値が１だけ増加する。属性「timer_count」値がすでに限度値(REFRESH_LIMIT)に達して、属性「reject_rate」値が１未満となれば、属性「reject_rate」値が増加する。属性「reject_rate」値が１を越える場合、属性「reject_rate」値を１に設定する。状態３「Process Timer」に入る属性「timer_count」の値がいかなる値であっても、属性「reject_rate」の値がゼロであれば、ゲートウエイはメッセージ「GW4:Out_Of_Overload」をゲートウエイ自身に送信し、その結果、状態４「Normal」に遷移する。属性「timer_count」の値が、現時点でゼロであれば、ゲートウエイはメッセージ「GW5:Stay_In_Overload」をゲートウエイ自身に送信し、その結果、状態２「Overloaded」に遷移する。
【０１０４】
・ロード・インフォメーション・オブジェクトを、状態７「Handle_Neg_Ack」に遷移させる、ロード・インフォメーション・オブジェクトからのメッセージ「GW６:Negative_Acknowlegement」。属性「timer_count」の現時点での値が、受信したメッセージ「GW６:Negative_Acknowlegement」に含まれるパラメータ「new_reject_rate」値を越えるか、または、パラメータ「new_ reject_rate」の値と等しい場合、ゲートウエイは、メッセージ「LI6:Off_Hook」をコールサーバの親機に送信して、イベント内容をコールサーバに再通知する。その後、ゲートウエイは、メッセージ「GW5:Stay_In_Overload」をゲートウエイ自身に送信し、その結果、ゲートウエイは、動作の最後の時点において、状態２「Overloaded」に遷移する。現時点での属性「reject_rate」の値が、受信したメッセージ「GW６:Negative_Acknowlegement」に含まれるパラメータ「new_reject_rate」の値未満の場合には（パラメータnew_reject_rateの値を含まない）、ゲートウエイは、メッセージ「GW5:Stay_In_Overload」をゲートウエイ自身に送信し、その結果、ゲートウエイは、動作の最後の時点において、状態２「Overloaded」に遷移する。その後、ゲートウエイは、メッセージ「GW8:Off_Hook」をゲートウエイ自身に送信し、その結果、メッセージ「Off Hook」が、状態９「Off_Hook_In_Overload」での動作によりフィルタリングして除去される（GW8:Off_Hook下側参照）。ここで、ゲートウエイは、属性「reject_rate」の値を、受信したメッセージ「Negative_Acknowlegement」に含まれるパラメータ「new_reject_rate」の値に設定し、その後、属性「timer_count」の値を、ゼロに設定する。
【０１０５】
・ゲートウエイを、状態９「Off_Hook_In_Overload」に遷移させる、「エンドユーザ」オブジェクトからのメッセージ「GW８:Off_Hook」。ゲートウエイは、現時点での属性「reject_rate」の値で、このメッセージ「Off _Hook 」をコールサーバに送信すべきかどうかを決定する。メッセージ「Off_Hook」を送信するとの決定であれば、ゲートウエイは、メッセージLI6:Off_Hookをコールサーバに送信して、そのイベント内容をコールサーバの親機に通知する。オフフック・メッセージを送信しないとの決定であれば、ゲートウエイは、そのことをエンドユーザに通知する。どちらの決定であれ、ゲートウエイは、メッセージ「GW5:Stay_In_Overload」をゲートウエイ自身に送信し、その結果、ゲートウエイは、状態２「Overload」に戻る。
【０１０６】
・ゲートウエイを、状態６「line_Event_Normal」に遷移させるエンドユーザ・オブジェクトからのメッセージ「GW9:Other_Telephony_Event」。ゲートウエイは、メッセージ「LI7:Other_Telephony_Event」をコールサーバに送信して、そのイベント内容をコールサーバの親機に通知する。その後、ゲートウエイは、メッセージ「GW５:Stay_In_Overload」をゲートウエイ自身に送信し、その結果、ゲートウエイは、状態２「Overload」に戻る。
【０１０７】
・ゲートウエイを状態１２「Overload_Response」に遷移させる、ロード・インフォメーション・オブジェクトからのメッセージ「GW10:Response」。ゲートウエイは、属性「reject_rate」の値を、受信したッセージ「GW10:Response」に含まれるパラメータ「new_reject_rate」の値に設定し、属性「timer_count」の値をゼロに設定する。属性「reject_rate」の値がゼロを越える場合には（ゼロを含まない）、ゲートウエイは、メッセージ「GW5:Stay_In_Overload」をゲートウエイ自身に送信し、その結果、ゲートウエイは、動作の最後の時点で、状態２「Overloaded」に戻る。属性「reject_rate」の値がゼロに等しい場合、ゲートウエイは、メッセージ「GW5:Stay_In_Overload」をゲートウエイ自身に送信し、その結果、ゲートウエイは、動作の最後の時点で、状態４「Normal」に戻る。ここで、ゲートウエイは、その応答を正常として処理する。
【０１０８】
・ゲートウエイを、状態１３「Process_New_Load_Level」に遷移させるロード・インフォメーション・オブジェクトからのメッセージ「GW11:Load_Level」。ゲートウエイは、属性「reject_rate」の値を、受信したッセージに含まれるパラメータ「new_reject_rate」の値に設定し、属性「timer_count」の値をゼロに設定する。属性「reject_rate」の値がゼロの場合、ゲートウエイは、メッセージ「GW4:Out_Of_Overload」をゲートウエイ自身に送信し、その結果、ゲートウエイは、動作の最後の時点で、状態４「Normal」に戻る。属性「reject_rate」の値がゼロを越える場合、ゲートウエイは、メッセージ「GW5:Stay_In_Overload」をゲートウエイ自身に送信し、その結果、ゲートウエイは、動作の最後の時点で、状態２「Overloaded」に遷移する。
【０１０９】
ゲートウエイが、値がゼロであるパラメータ「new_ reject_ rate」を含むメッセージ「GW11: Load _Level」を受信済みであれば、状態４「Normal」に遷移している。ゲートウエイは、メッセージを受信するまで、状態４「Overloaded」にとどまる。ゲートウエイは、状態４「Overloaded」では、以下の５つあるメッセージのうちのいずれか１つを受け取ることができる。
【０１１０】
・ゲートウエイを、状態３「Process Timer」に遷移させるゲートウエイ・タイマー・オブジェクトからのメッセージ「GW3:Timer」。属性「timer_count」の現時点での値が、事前に定義してある限度値(REFRESH_LIMIT)未満であれば（限度値を含まない）、属性「timer_count」値が１だけ増加する。属性「timer_count」値がすでに限度値(REFRESH_LIMIT)に達しており、属性「reject_rate」値が１未満であれば、属性「reject_rate」の値が増加する。属性「reject_rate」値が１を越える場合、属性「reject_rate」の値を１に設定する。入力されている属性「timer_count」の値が、いかなる値であっても、属性「reject_rate」の値がゼロであれば、ゲートウエイは、メッセージ「GW4:Out_Of_Overload」をゲートウエイ自身に送信し、その結果、状態４「Normal」に遷移する。属性「reject_rate」の値が、現時点でゼロでなければ、ゲートウエイはメッセージ「GW5:Stay _In_Overload」をゲートウエイ自身に送信し、その結果、状態２「Overloaded」に遷移する。
【０１１１】
・ロード・インフォメーション・オブジェクトを、状態７「Handle_Neg_Ack」に遷移させる、ロード・インフォメーション・オブジェクトからのメッセージ「GW６:Negative_Acknowlegement」。現時点での属性「reject_rate」の値が、受信したメッセージ「GW６:Negative_Acknowlegement」に含まれるパラメータ「new_ reject_rate」値を越えるか、または、パラメータ「new_reject_rate」の値と等しい場合、ゲートウエイは、メッセージ「LI6:Off_Hook」をコールサーバの親機に送信して、イベント内容をコールサーバに再通知する。その後、ゲートウエイは、メッセージ「GW5:Stay_In_Overload」をゲートウエイ自身に送信し、その結果、ゲートウエイは、動作の最後の時点において、状態２「Overloaded」に遷移する。現時点での属性「reject_rate」の値が、受信したメッセージ「GW６:Negative_Acknowlegement」に含まれるパラメータ「new_reject_rate」の値未満の場合には（パラメータnew_reject_rateの値を含まない）、ゲートウエイは、メッセージ「GW5:Stay_In_Overload」をゲートウエイ自身に送信し、その結果、ゲートウエイは、動作の最後の時点において、状態２「Overloaded」に遷移する。その後、ゲートウエイは、メッセージ「GW8:Off_Hook」をゲートウエイ自身に送信し、その結果、メッセージ「Off Hook」が、状態９「Off_Hook_In_Overload」での動作によりフィルタリングして除去される（GW8:Off_Hook下側参照）。ここで、ゲートウエイは、属性「reject_rate」の値を、受信したメッセージ「Negative_Acknowlegement」に含まれるパラメータ「new_reject_rate」の値に設定し、その後、属性「timer_count」の値を、ゼロに設定する。
【０１１２】
・ゲートウエイを、状態１０「Off_Hook_Normal」に遷移させる、「エンドユーザ」オブジェクトからのメッセージ「GW８:Off_Hook」。ゲートウエイは、メッセージLI6:Off_Hookをコールサーバの親機に送信して、そのイベント内容をコールサーバに通知する。ゲートウエイは、メッセージ「GW4:Out_Of_Overload」をゲートウエイ自身に送信し、その結果、ゲートウエイは、状態４「Normal」に戻る。
【０１１３】
・ゲートウエイを、状態６「Line_Event_Normal（回線イベント通常状態）」に遷移させる、エンドユーザからのメッセージ「GW9:Other_Telephony_Event」。ゲートウエイは、メッセージ「LI7:Other_Telephony_Event」をコールサーバの親機に送信することで、イベントをコールサーバに通知する。その後、ゲーウエイは、メッセージ「GW4:Out_Of_Overload」をゲートウエイ自身に送信し、その結果、ゲートウエイは、状態４「Normal」に戻る。
【０１１４】
・ゲートウエイを、状態１１「Normal_Response」に遷移させる、ロード・インフォメーション・オブジェクトからのメッセージ「GW10:Response」。ゲーウエイは、属性「reject_rate」の値を、受信したメッセージ「Response」に含まれるパラメータ「new_ reject_rate」の値として設定し、属性「timer_count」の値を、ゼロに設定する。ここで、属性「reject_rate」の値がゼロを越える（ゼロを含まない）場合、ゲートウエイは、メッセージ「GW5:Stay_In_Overload」を、ゲートウエイ自身に送信し、その結果、動作の最後の時点で、状態２「Overloaded」に遷移する。属性「reject_rate」の値がゼロに等しくない場合、ゲートウエイは、メッセージ「GW4:Out_Of_Overload」をゲートウエイ自身に送信し、その結果、動作の最後の時点で、状態４「Normal」に遷移する。このゲートウエイは、その応答を正常として処理する。
【０１１５】
・ゲートウエイを、状態１３「Process_New_Load_Level」に遷移させる、ロード・インフォメーション・オブジェクトからのメッセージ「GW11:Load_Level」。ゲートウエイは、属性「reject_rate」の値を、受信したメッセージ「GW11:Load_Level」に含まれるパラメータ「new_reject_rate」の値に設定し、その後、属性「timer_count」の値を、ゼロに設定する。ここで、現時点での属性「reject_rate」の値がゼロに等しくない場合、ゲートウエイは、メッセージ「GW4:Out_Of_Overload」をゲートウエイ自身に送信し、その結果、動作の最後の時点で、状態４「Normal」に遷移する。ここで、属性「reject_rate」の値が、ゼロを越える（ゼロを含まない）場合は、ゲートウエイは、メッセージ「GW5:Stay_In_Overload」を、ゲートウエイ自身に送信し、その結果、動作の最後の時点で、状態２「Overloaded」に遷移する。
【０１１６】
図２３は、第三実施例のロード・インフォメーション・オブジェクトの状態遷移図である。ロード・インフォメーション・オブジェクトの動作について図２３を参照して述べる。
【０１１７】
ロード・インフォメーション・オブジェクトは、属性「reject_rate」の値をゼロに設定して、「Creation」の状態から状態２「Normal」に移行する。ロード・インフォメーション・オブジェクトは、メッセージを受信するまで、状態２「Normal」にとどまる。ゲートウエイは、状態４「Normal」では、以下の５つあるメッセージのうちのいずれか１つを受け取ることができる。
【０１１８】
・ロード・インフォメーション・オブジェクトを状態４「Check _Load_Level」に遷移させる、オペレーティングシステムからのメッセージ「LI3:Load_Level」。属性「reject_rate」の値を、受信したメッセージ「LI1:Load」に含まれるパラメータ「new_reject_rate」の値として設定する。ここで、属性「reject_rate」の値がゼロの場合、ロード・インフォメーション・オブジェクトは、コールサーバにより制御される各ゲートウエイに関連づけられた属性「last_ reject_rate」の値を設定して、その後、ロード・インフォメーション・オブジェクトは、メッセージ「LI5:Out_Of_Overload」をロード・インフォメーション・オブジェクト自身に送信し、その結果、状態２「Normalに遷移する。属性「reject_rate」の値がゼロでない場合、ロード・インフォメーション・オブジェクトは、メッセージ「LI4:Into_Overload」をロード・インフォメーション・オブジェクト自身に送信し、その結果、状態３「Overloaded」に遷移する。
【０１１９】
・ロード・インフォメーション・オブジェクトを、状態８「Normal_Off_Hook」に遷移させる、ゲートウエイ・オブジェクトからのメッセージ「LI6:Off_Hook」。ロード・インフォメーション・オブジェクトは、メッセージ「CC1:Off_Hook」をコールコントローラに送信することで、イベントをコールコントローラに通知する。その後、ロード・インフォメーション・オブジェクトは、メッセージ「LI5:Out_Of_Overload」をロード・インフォメーション・オブジェクト自身に送信し、その結果、状態２「Normalに遷移する。
【０１２０】
・ロード・インフォメーション・オブジェクトを、状態５「Normal_Telephony_Event」に遷移させる、ゲートウエイからのメッセージ「LI7:Other_Telephony_Event」。ロード・インフォメーション・オブジェクトは、メッセージ「CC2:Other_Telephony_Event」をコールサーバに送信して、イベント内容をコールサーバに通知する。その後、ロード・インフォメーション・オブジェクトは、メッセージ「LI5:Out:Out_Of_Overload」をゲートウエイ自身に送信し、その結果、ゲートウエイは、状態２「Normal」に戻る。
【０１２１】
・ロード・インフォメーション・オブジェクトを、状態１１「Normal_Response」に遷移させる、コール・コントローア・オブジェクトからのメッセージ「LI9:Response」。ロード・インフォメーション・オブジェクトは、現時点での属性「reject_rate」の値をパラメータとして使用して、受信したメッセージ「LI9:Response」に含まれるパラメータ「gateway_id」により特定されるゲートウエイに、メッセージ「GW10: Response」を送信することで、イベント内容をゲートウエイに通知する。ここで、ロード・インフォメーション・オブジェクトは、特定されたゲートウエイに関連づけられた、属性「recent」を「TRUE」に設定し、特定されたゲートウエイに関連づけられた属性「last_ reject_rate」の値を、属性「reject_rate」の現時点での値に設定する。その後、ロード・インフォメーション・オブジェクトは、メッセージ「LI5:Out_of_Overload」をロード・インフォメーション・オブジェクト自身に送信し、その結果、状態２「Normal」に戻る。
【０１２２】
・ロード・インフォメーション・オブジェクトを、状態１３「Process_Timer」に遷移させる、コールサーバのタイマーオブジェクトからのメッセージ「LI10:Timer」。コールサーバにより制御される各ゲートウエイに対して、このゲートウエイに関連づけられている属性「recent（最新）」の値が、FALSE（偽）の場合、ロード・インフォメーション・オブジェクトは、現時点での属性「reject_rate」の値をパラメータとして使用して、メッセージ「GW11:Load_ Level」を、ゲートウエイに送信し、そのゲートウエイに関連づけられた属性「recent」の値をTRUE（真）として設定し、そうでない場合、ゲートウエイに関連づけられた属性「recent」の値をFALSE（偽）として設定する。ロード・インフォメーション・オブジェクトは、属性「reject_rate」の値がゼロの場合、メッセージ「LI5:Out_Of_Overload」を、ロード・インフォメーション・オブジェクト自身に送信し、その結果、ロード・インフォメーション・オブジェクトは、動作の最後の時点において、状態３「Normal」に遷移する。ロード・インフォメーション・オブジェクトは、属性「reject_rate」の値がゼロでない場合、メッセージ「LI4:Into_Overload」を ロード・インフォメーション・オブジェクト自身に送信し、その結果、ロード・インフォメーション・オブジェクトは、動作の最後の時点において、状態３「Overloaded」に遷移する。
【０１２３】
ロード・インフォメーション・オブジェクトが、ゼロを越える（ゼロを含まない）パラメータ「new_ reject_rate」値を有するメッセージ「LI3:Load_Level」を受信していると、状態３「Overloaded」に遷移している。ロード・インフォメーション・オブジェクトは、メッセージを受信するまで、状態３「Overloaded」にとどまる。ロード・インフォメーション・オブジェクトは、状態３「Overloaded」では、以下の4つあるメッセージのうちのいずれか１つを受け取ることになる。
【０１２４】
・ロード・インフォメーション・オブジェクトを状態４「Check_Load_Level」に遷移させる、オペレーティングシステムからのメッセージ「LI3:Load_Level」。属性「reject_rate」値を、受信したメッセージ「LI3:Load_Level」に含まれるパラメータ「new_reject_rate」として設定する。属性「reject_rate」値が、現時点で、ゼロである場合、ロード・インフォメーション・オブジェクトが、コールサーバにより制御される各ゲートウエイに対して、それぞれのゲートウエイに関連づけられた属性「last_reject_rate」値をゼロに設定し、その後、ロード・インフォメーション・オブジェクトは、メッセージ「LI5:Out_Of_Overload」を、ロード・インフォメーション・オブジェクト自身に送信し、その結果、ロード・インフォメーション・オブジェクトは、状態２「Normal」に戻ることになる。属性「reject_rate」値が、ゼロでない場合、ロード・インフォメーション・オブジェクトは、メッセージ「LI4:Into_Overload」を ロード・インフォメーション・オブジェクト自身に送信し、その結果、ロード・インフォメーション・オブジェクトは、状態３「Overloaded」に戻ることになる。
【０１２５】
・ロード・インフォメーション・オブジェクトを、状態６「Overloaded_Off_Hook」に遷移させる、ゲートウエイ・オブジェクトからのメッセージ「LI6:Off_Hook」。属性「reject_rate」の現在の値が受信したメッセージ「Off_Hook」に含まれるパラメータ「gateway_id」により特定されるゲートウエイと関連づけられた属性「last_reject_rate」の値を越える（その値を含まない）場合、ロード・インフォメーション・オブジェクトは、現時点での属性「reject_rate」の値をパラメータとして使用して、メッセージ「GW6: Negative_Acknowledge」を、その特定されたゲートウエイに送信し、ゲートウエイに関連づけられた属性「recent」の値を「TRUE」に設定し、その特定されたゲートウエイに関連づけられた属性「last_reject_rate」を属性「reject_rate」の値に設定する。そうでない場合、ロード・インフォメーション・オブジェクトは、メッセージ「CC1:Off_Hook」をコールコントローラに送信する。その後、ロード・インフォメーション・オブジェクトは、メッセージ「LI4:Into_Overload」を ロード・インフォメーション・オブジェクト自身に送信し、その結果、ロード・インフォメーション・オブジェクトは、状態３「Overloaded」に戻ることになる。
【０１２６】
・ロード・インフォメーション・オブジェクトを、状態７「Overload_Other_Event」に遷移させる、ゲートウエイ・オブジェクトからのメッセージ「LI７:Other_Telephony_Event」。ロード・インフォメーション・オブジェクトは、メッセージ「CC2:Other_Telephony_Event」をコールコントローラに送信して、そのイベント内容をコールコントローラに通知する。その後、ロード・インフォメーション・オブジェクトは、メッセージ「LI4:Into_Overload」を ロード・インフォメーション・オブジェクト自身に送信し、その結果、ロード・インフォメーション・オブジェクトは、状態３「Overloaded」に戻る。
【０１２７】
・ロード・インフォメーション・オブジェクトを状態１０「Overloaded_Response」に遷移させる、コール・コントローラ・オブジェクトからのメッセージ「LI9:Response」。ロード・インフォメーション・オブジェクトは、属性「reject_rate」の現時点での値をパラメータとして使用して、受信したメッセージ「LI9:Response」に含まれるパラメータ「gateway_id」により特定されるゲートウエイにメッセージ「GW10:Response」を送信することで、イベント内容をゲートウエイに通知する。ロード・インフォメーションは、ゲートウエイに関連づけられた属性「recent」の値を「TRUE」に設定し、その特定されたゲートウエイに関連づけられた属性「last_reject_rate」を、属性「reject_rate」の現在値に設定する。その後、ロード・インフォメーション・オブジェクトは、メッセージ「LI4:Into_Overload」を ロード・インフォメーション・オブジェクト自身に送信し、その結果、ロード・インフォメーション・オブジェクトは、状態３「Overloaded」に戻る。
【０１２８】
・ゲートウエイを、状態３「Process Timer」に遷移させる、コールサーバ・タイマーからのメッセージ「ＧＷ３：Timer」。コールサーバにより制御される各ゲートウエイに対して、このゲートウエイに関連づけられている属性「recent」の値が「FALSE（偽）」の場合、ロード・インフォメーション・オブジェクトは、現時点での属性「reject_rate」の値をパラメータとして使用して、メッセージ「GW11:Load_ Level」を、ゲートウエイに送信し、そのゲートウエイに関連づけられた属性「recent」の値をTRUE（真）として設定し、そうでない場合、ゲートウエイに関連づけられた属性「recent」の値を「FALSE（偽）」として設定する。ロード・インフォメーション・オブジェクトは、属性「reject_rate」の値がゼロであれば、メッセージ「LI5:Out_Of_Overload」を、ロード・インフォメーション・オブジェクト自身に送信し、その結果、ロード・インフォメーション・オブジェクトは、動作の最後の時点において、状態３「Normal」に遷移する。ロード・インフォメーション・オブジェクトは、属性「reject_rate」の値がゼロでない場合、メッセージ「LI4:Into_Overload」を ロード・インフォメーション・オブジェクト自身に送信し、その結果、ロード・インフォメーション・オブジェクトは、動作の最後の時点において、状態３「Overloaded」に遷移する。
【０１２９】
ここで、図９乃至図１６を参照して、メッセージシーケンスを記載する。
【０１３０】
図９と図１０は、従来のネットワークにおける典型的な動作を示しており、ここでは、図６、７、８で使用されたメッセージ名が使用されている。これらの図には、本発明で導入された新規なロード・インフォメーション・オブジェクトの機能は提示されていない。ゲートウエイは、エンドユーザからのメッセージ「GW8:Off_Hook」を受信することにより、エンドユーザが電話をかけることを望んでいることを知らされる。ゲートウエイは、メッセージ「CC1:Off_Hook」をコールサーバに送信することにより、このことを、コールサーバの親機に通知する。
【０１３１】
図９は、コールサーバが、発呼を受信する場合を示している。ここでは、コールサーバは、適当なパラメータを含んでいるメッセージ「GW10:Response」を、ゲートウエイに送信することにより、ゲートウエイの動作の継続を要求する。ゲートウエイは、エンドユーザに、ダイアルトーン(Dial Tone)を送信して、数字（電話番号）の入力を促す。
【０１３２】
図１０は、コールサーバが発呼を拒否する場合を示しており、ここでは、コールサーバが適当なパラメータを含むメッセージ「GW10:Response」をゲートウエイに送信して、ゲートウエイの動作を停止させる。ゲートウエイは、エンドユーザにネットワーク・ビジー・トーン(Network Busy Tone)を送信する。
【０１３３】
図１１乃至図１６は、本発明の実施例にかかる典型的な動作を示し、その内容は、すでに、図６，７，８を参照して述べたとおりである。
【０１３４】
図１１は、発呼を受け入れる場合である。ゲートウエイは、エンドユーザからメッセージ「GW8:Off_Hook」を受信することで、エンドユーザが電話をかけることを望んでいることを知らされる。ゲートウエイは、メッセージ「LI6:Off_Hook」をコールサーバの親機に送信して、このことを通知する。ロード・インフォメーション・オブジェクトは、メッセージ「CC1:Off_Hook」をコールコントローラに送信することで、このことを、コールコントローラに通知する。コールコントローラは、発呼を受け入れて、ロード・インフォメーション・オブジェクトにメッセージ「LI9:Rseponse」を送信して、ゲートウエイの動作の継続を要求する。ロード・インフォメーション・オブジェクトは、適当なパラメータを含むメッセージ「GW10:Response」をゲートウエイに送信することで、このことを、ゲートウエイに通知する。ゲートウエイは、エンドユーザにネットワーク・ビジー・トーン(Network Busy Tone)を送信して、数字の入力を促す。
【０１３５】
図１２は、コールサーバが、負荷レベルが低い期間に発呼を拒否する場合を示したものである。ゲートウエイは、エンドユーザからメッセージ「GW8:Off_Hook」を受信することで、エンドユーザが電話をかけることを望んでいることを知らされる。ゲートウエイは、メッセージ「LI6:Off_Hook」をゲートウエイに送信することで、このことを、ゲートウエイに通知する。ロード・インフォメーション・オブジェクトは、メッセージ「CC1:Off_Hook」を送信することで、このことを、コールサーバに通知する。コールコントローラは、発呼を拒否し、メッセージ「LI8:Reject_Call_For Load」を送信することで、ゲートウエイに動作を停止させる。ロード・インフォメーション・オブジェクトは、適当なパラメータを含んだメッセージ「GW10:Response」を発信することで、このことを、ゲートウエイに通知する。ゲートウエイは、エンドユーザにネットワーク・ビジー・トーンを発信する。
【０１３６】
図１３、１５は、前回の通信において、拒否のために必要な呼の割合が、ゲートウエイに知らされているために、コールサーバの負荷が増加した事例を示している。ゲートウエイは、エンドユーザからメッセージ「GW8:Off_Hook」を受信することで、エンドユーザが電話をかけることを望んでいることを知らされる。ゲートウエイは、メッセージ「LI6:Off_Hook」をコールサーバの親機に送信することで、このことを、ゲートウエイに通知する。ロード・インフォメーション・オブジェクトは、メッセージ「GW6: Negative_Acknowledge」をゲートウエイに送信する。ゲートウエイは、メッセージに供給されているパラメータ「new_reject_rate」の値を保存した後、メッセージ「Off_Hook」を再処理する。
【０１３７】
図１３は、ゲートウエイがメッセージ「LI6:Off_Hook」を再送することで、メッセージ「Off_Hook」の引渡しを決定する事例を示している。ロード・インフォメーション・オブジェクトは、送信側ゲートウエイが新しい呼の要求割合を拒否していることを検知しており、メッセージ「CC1:Off_Hook」をコールコントローラに送信することで、このことを、コールコントローラに通知する。コールコントロール（呼制御部）は発呼を受け入れ、メッセージ「LI9:Response」をロード・インフォメーション・オブジェクトに送信することで、ゲートウエイに動作を続行するように要求する。ロード・インフォメーション・オブジェクトは、適当なパラメータを含んだメッセージ「GW10:Response」を送信することで、このことを、ゲートウエイに通知する。ゲートウエイは、エンドユーザに、ダイアルトーンを発信して、数字の入力を促す。
【０１３８】
図１４は、ゲートウエイは、最初のフィルタリング段階で、メッセージ「Off_Hook」の受け入れを拒否することを決定する事例を示している。ゲートウエイは、エンドユーザにネットワーク・ビジー・トーンを送信する。コールサーバは、その呼について検知していない。
【０１３９】
図１５は、ゲートウエイがメッセージ「Off_Hook」の引渡しを決定したが、コールサーバが、その呼の受け入れを拒否する事例を示している。ゲートウエイは、メッセージ「LI6:Off_Hook」をロード・インフォメーション・オブジェクトに送信する。ロード・インフォメーション・オブジェクトは、負荷レベルがすでに増加していることを検知しており、このことを前回の通信でゲートウエイに通知している。したがって、新しい通知を含むメッセージ「Response」を送信して、「Off_Hook」の受け入れを拒否する。ゲートウエイは、より高い拒否率を適用して、メッセージ「Off_Hook」のフィルタリングを行い、再度、そのメッセージをコールサーバに送信することを決定する。ロード・インフォメーション・オブジェクトは、ゲートウエイが新しい呼の必要割合を拒否していることを検知しており、したがって、このことを、メッセージ「CC1:Off_Hook」を送信することで、コールコントローラに通知する。コールコントローラは、発呼を拒否し、メッセージ「LI8:Reject_Call_For Load」を送信することで、ゲートウエイの動作を停止させる。ロード・インフォメーション・オブジェクトは、適当なパラメータを含んだメッセージ「GW10:Response」を送信することで、このことを、ゲートウエイに通知する。ゲートウエイは、エンドユーザにネットワーク・ビジー・トーンを発信する。
【０１４０】
図１６は、コールサーバにより拒否されたメッセージ「Off_Hook」を、ゲートウエイが受け入れを拒否することを決定する事例を示している。ゲートウエイは、ネットワーク・ビジー・トーンを発信して、この拒否内容をエンドユーザに通知する。
【０１４１】
本発明は、前記で述べた特定の実施例のいずれかに限定されるものではなく、これらの実施例は単に例示のためのものである。前記で述べた特定の実施例に対する変更は、この発明の範囲を逸脱することなく遂行できる。例えば、この発明の実施のために、多様なメッセージフォーマットおよびプロトコルを使用してもよい。ダウンストリームレベルの負荷を処理し、正確で効果的なメッセージ制御が可能なソースノードを提供することにより、インターネットを基礎にした通信システムの性能を向上させることができることは、本発明の長所である。
【図面の簡単な説明】
【０１４２】
【図１】図１は、従来のコールサーバの応答特性を示したものである。
【図２】図２は、従来のコールサーバの応答特性を示したものである。
【図３】図３は、従来のＰＳＴＮを概略的に示したものである。
【図４】図４は、提案されている次世代ネットワークを概略的に示したものである。
【図５】図５は、本発明による情報フローを概略的に示したものである。
【図６】図６は、本発明による情報フローを概略的に示したものである。
【図７】、
【図７Ｉ】、
【図７ＩＩ】、
【図７ＩＩＩ】、
【図７ＩＶ】、
【図７Ｖ】図７は、本発明の概略状態遷移図である。
【図８】、
【図８Ｉ】、
【図８ＩＩ】、
【図８ＩＩＩ】、
【図８ＩＶ】、
【図８Ｖ】図８は、本発明の概略状態遷移図である。
【図９】図９は、先行技術のメッセージフローを概略的に示したものである。
【図１０】図１０は、従来技術のメッセージフローを概略的に示したものである。
【図１１】図１１は、本発明のメッセージフローを概略的に示したものである。
【図１２】図１２は、本発明のメッセージフローを概略的に示したものである。
【図１３】図１３は、本発明のメッセージフローを概略的に示したものである。
【図１４】図１４は、本発明のメッセージフローを概略的に示したものである。
【図１５】図１５は、本発明のメッセージフローを概略的に示したものである。
【図１６】図１６は、本発明のメッセージフローを概略的に示したものである。
【図１７】図１７は、本発明による情報フローを概略的に示したものである。
【図１８】、
【図１８Ｉ】、
【図１８ＩＩ】、
【図１８ＩＩＩ】、
【図１８ＩＶ】、
【図１８Ｖ】図１８は、本発明の概略状態遷移図である。
【図１９】、
【図１９Ｉ】、
【図１９ＩＩ】、
【図１９ＩＩＩ】、
【図１９ＩＶ】、
【図１９Ｖ】図１９は、本発明の概略状態遷移図である。
【図２０】図２０は、本発明による情報フローを概略的に示したものである。
【図２１】図２１は、本発明による情報フローを概略的に示したものである。
【図２２】、
【図２２Ｉ】、
【図２２ＩＩ】、
【図２２ＩＩＩ】、
【図２２ＩＶ】、
【図２２Ｖ】図２２は、本発明の概略状態遷移図である。
【図２３】、
【図２３Ｉ】、
【図２３ＩＩ】、
【図２３ＩＩＩ】、
【図２３ＩＶ】、
【図２３Ｖ】図２３は、本発明の概略状態遷移図である。
【図１】
2008502184.tif 000003
【図２】
2008502184.tif 000004
【図３】
2008502184.tif 000005
【図４】
2008502184.tif 000006
【図５】
2008502184.tif 000007
【図６】
2008502184.tif 000008
【図７】
2008502184.tif 000009
【図７Ｉ】
2008502184.tif 000010
【図７ＩＩ】
2008502184.tif 000011
【図７ＩＩＩ】
2008502184.tif 000012
【図７ＩＶ】
2008502184.tif 000013
【図７Ｖ】
2008502184.tif 000014
【図８】
2008502184.tif 000015
【図８Ｉ】
2008502184.tif 000016
【図８ＩＩ】
2008502184.tif 000017
【図８ＩＩＩ】
2008502184.tif 000018
【図８ＩＶ】
2008502184.tif 000019
【図８Ｖ】
2008502184.tif 000020
【図９】
2008502184.tif 000021
【図１０】
2008502184.tif 000022
【図１１】
2008502184.tif 000023
【図１２】
2008502184.tif 000024
【図１３】
2008502184.tif 000025
【図１４】
2008502184.tif 000026
【図１５】
2008502184.tif 000027
【図１６】
2008502184.tif 000028
【図１７】
2008502184.tif 000029
【図１８】
2008502184.tif 000030
【図１８Ｉ】
2008502184.tif 000031
【図１８ＩＩ】
2008502184.tif 000032
【図１８ＩＩＩ】
2008502184.tif 000033
【図１８ＩＶ】
2008502184.tif 000034
【図１８Ｖ】
2008502184.tif 000035
【図１９】
2008502184.tif 000036
【図１９Ｉ】
2008502184.tif 000037
【図１９ＩＩ】
2008502184.tif 000038
【図１９ＩＩＩ】
2008502184.tif 000039
【図１９ＩＶ】
2008502184.tif 000040
【図１９Ｖ】
2008502184.tif 000041
【図２０】
2008502184.tif 000042
【図２１】
2008502184.tif 000043
【図２２】
2008502184.tif 000044
【図２２Ｉ】
2008502184.tif 000045
【図２２ＩＩ】
2008502184.tif 000046
【図２２ＩＩＩ】
2008502184.tif 000047
【図２２ＩＶ】
2008502184.tif 000048
【図２２Ｖ】
2008502184.tif 000049
【図２３】
2008502184.tif 000050
【図２３Ｉ】
2008502184.tif 000051
【図２３ＩＩ】
2008502184.tif 000052
【図２３ＩＩＩ】
2008502184.tif 000053
【図２３ＩＶ】
2008502184.tif 000054
【図２３Ｖ】
2008502184.tif 000055
【手続補正書】
【提出日】平成18年4月4日(2006.4.4)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
メッセージの通信のために配置されたターゲットノード、および、少なくとも１つのソースノードを含み、さらに、前記ターゲットノードは、前記少なくとも１つのソースノードから受信したメッセージのうちの、少なくともいくつかを処理する手段と、前記ターゲットノードの処理負荷を検出する手段を含み、さらに、前記ターゲットノードは、ある特定の処理負荷レベルに達しているか、または、ある特定の処理負荷レベルを越えている場合、前記少なくとも１つのソースノードに通知する手段を含み、さらに、各ソースノードは、その通知に応答して、前記ターゲットノードにメッセージが送信される割合を低下させる手段を含み、
さらに、前記ターゲットノードは、前記少なくとも１つのソースノードで受信されたメッセージのうちある割合のメッセージを前記ターゲットノードへ転送することなく拒否するよう該ソースノードに指示するよう構成されていることを特徴とする通信システム。
【請求項２】
前記ターゲットノードはコールサーバであることを特徴とする請求項１に記載の通信システム。
【請求項３】
各ソースノードは、メディアゲートウエイ機能を提供することを特徴とする請求項１又は２に記載の通信システム。
【請求項４】
前記ターゲットノードは、単独で又は過負荷となっているメッセージの一部について拒否して戻されることになるメッセージの割合を、前記少なくとも１つのソースノードに対して通知するよう構成されていることを特徴とする請求項１乃至３のいずれか１項に記載の通信システム。
【請求項５】
前記ターゲットノードは、新規の発呼に関連して、前記少なくとも１つのソースノードからオフフックを通知するためのシグナリングメッセージを受信するよう構成されていることを特徴とする請求項１乃至４のいずれか１項に記載の通信システム。
【請求項６】
前記ターゲットノードは、前記通信システムが過負荷状態になると、前記少なくとも１つのソースノードから送信されるオフフックを通知するためのシグナリングメッセージに対して自動的な否定応答（ＮＡＫ）を用いて応答するよう構成されており、該否定応答には、拒否されるべき発呼の割合の情報が含まれていることを特徴とする請求項５に記載の通信システム。
【請求項７】
前記少なくとも１つのソースノードは、初期のフィルタリングによってオフフックの要求を拒否するよう構成されていることを特徴とする請求項５に記載の通信システム。
【請求項８】
前記少なくとも１つの前記ソースノードは、１種類以上のメッセージを前記ターゲットノードに送信するよう構成されており、さらに、前記ターゲットノードは、受信したメッセージの種類を特定し、新しい接続要求の同定の後すぐに、メッセージに如何なる処理もしないで、通知を送信するよう構成されていることを特徴とする請求項１乃至７のいずれか１項に記載の通信システム。
【請求項９】
前記メッセージは、優先度の低いメッセージと優先度の高いメッセージに分類され、優先度の低いメッセージの割合を低下させることだけを実行するよう、前記少なくとも１つのソースノードが構成されていることを特徴とする請求項１乃至８のいずれか１項に記載の通信システム。
【請求項１０】
前記優先度の高いメッセージは、接続に成功する確率が上昇するよう第２の厳格でないフィルタによって処理されることを特徴とする請求項９に記載の通信システム。
【請求項１１】
前記通信システムが過負荷状態になっても、エンドユーザの一部はサービスを保障されることを特徴とする請求項１乃至１０のいずれか１項に記載の通信システム。
【請求項１２】
前記通信システムは、緊急サービスについてのメッセージを、前記ターゲットノードにメッセージが送信される割合を低下させる前記手段をバイパスするよう構成されていることを特徴とする請求項１乃至１１のいずれか１項に記載の通信システム。
【請求項１３】
前記ターゲットノードは、自己の処理負荷を検出するよう構成されていることを特徴とする請求項１乃至１２のいずれか１項に記載の通信システム。
【請求項１４】
各ソースノードに配置される前記手段は、ある期間に亘って、これ以上の通知を受信することはないということを根拠に、メッセージが前記ターゲットノードに送信される割合を、ある時間経過後に減少させるよう構成されていることを特徴とする請求項１乃至１３のいずれか１項に記載の通信システム。
【請求項１５】
各ソースノードに配置される前記手段は、ある期間に亘って、これ以上の通知を受信することはないということを根拠に、メッセージが前記ターゲットノードに送信される割合を、ある時間経過後に増加させるよう構成されていることを特徴とする請求項１乃至１３のいずれか１項に記載の通信システム。
【請求項１６】
各ソースノードは、メディアゲートウエイ機能を提供するネットワーク終端装置を含むことを特徴とする請求項２乃至１５のいずれか１項に記載の通信システム。
【請求項１７】
前記ターゲットノードは、各ソースノードに通知された情報を記録する手段を含むことを特徴とする請求項１乃至１７のいずれか１項に記載の通信システム。
【請求項１８】
前記ターゲットノードは、特定の処理負荷に達するか、または、越えた、ある期間中において、該ターゲットノードにメッセージを供給する前記ソースノードに通知することだけを実行するよう構成されていることを特徴とする請求項１乃至１７のいずれか１項に記載の通信システム。
【請求項１９】
前記ターゲットノードは、処理負荷の増加に続いて、前記ソースノードが単独でまたは複数で、さらにメッセージを該ターゲットノードに送信する場合に、請求項１８に記載の前記ソースノードのいずれかに新しい通知をするよう構成されていることを特徴とする請求項１８に記載の通信システム。
【請求項２０】
前記ターゲットノードは、処理負荷の特定のレベルに対して１回だけ、前記ソースノードのいずれか１つに通知をするよう構成されていることを特徴とする請求項１乃至１９のいずれか１項に記載の通信システム。
【請求項２１】
前記ターゲットノードは、前記ソースノードに送信されるメッセージのそれぞれに、特定の負荷に達したかどうか、あるいは、特定の負荷を越えたかどうかについての通知を付与するよう構成されていることを特徴とする請求項１乃至１９のいずれか１項に記載の通信システム。
【請求項２２】
前記ターゲットノードは、前記ソースノードに送信される、呼に関係のない周期的なメッセージに、特定の負荷に達したかどうか、あるいは、特定の負荷を越えたかどうかについての通知を付与するよう構成されていることを特徴とする請求項１乃至１９のいずれか１項に記載の通信システム。
【請求項２３】
前記ターゲットノードは、特定の処理負荷レベルに達しており、または、特定の処理負荷レベルを越えており、その負荷レベルがさらに上昇している場合に、すでに通知済みの少なくとも１つのソースノードに対して、さらに通知を行うよう構成されていることを特徴とする請求項１乃至２２のいずれか１項に記載の通信システム。
【請求項２４】
前記処理負荷は、前記ソースノードからメッセージが受信される率に応じて定義されることを特徴とする請求項１乃至２３のいずれか１項に記載の通信システム。
【請求項２５】
前記処理負荷を定義するために用いられる受信メッセージは、新しい接続要求であることを特徴とする請求項１乃至２４のいずれか１項に記載の通信システム。
【請求項２６】
前記ターゲットノードは、少なくとも１００個のソースノードからメッセージを受信するよう構成されていることを特徴とする請求項１乃至２５のいずれか１項に記載の通信システム。
【請求項２７】
前記ターゲットノードは、少なくとも１０００個のソースノードからメッセージを受信するよう構成されていることを特徴とする請求項１乃至２６のいずれか１項に記載の通信システム。
【請求項２８】
前記ターゲットノードは、少なくとも、１万個のソースノードからメッセージを受信するよう構成されていることを特徴とする請求項１乃至２７のいずれか１項に記載の通信システム。
【請求項２９】
前記ターゲットノードは、少なくとも１０万個のソースノードからメッセージを受信するよう構成されていることを特徴とする請求項１乃至２８のいずれか１項に記載の通信システム。
【請求項３０】
前記ターゲットノードは、少なくとも１００万個のソースノードからメッセージを受信するよう構成されていることを特徴とする請求項１乃至２９のいずれか１項に記載の通信システム。
【請求項３１】
前記メッセージは、インターネットプロトコル（ＩＰ）を基礎にしたメッセージであることを特徴とする請求項１乃至３０のいずれか１項に記載の通信システム。
【請求項３２】
前記メッセージがターゲットノードに到着する前に、メッセージの集中が発生しないようにしたことを特徴とする請求項１乃至３１のいずれか１項に記載の通信システム。
【請求項３３】
少なくとも１つのソースノードからメッセージを受信し、該少なくとも１つのソースノードから受信するメッセージの少なくともいくつかを処理するターゲットノードでの負荷を制御する方法であって、前記ターゲットノードの処理負荷を検出するステップと、特定の処理負荷レベルに達しているか、または、特定の処理レベルを越えている場合、少なくとも１つのソースノードに通知するステップとを含み、各ソースノードが、その通知に応答して、前記ターゲットノードにメッセージが送信される割合を低下させ、
さらに、前記方法は、
前記少なくとも１つのソースノードで受信されたメッセージのうちある割合のメッセージを前記ターゲットノードへ転送することなく拒否するよう該ソースノードに前記ターゲットノードが指示するステップを含むことを特徴とする方法。
【請求項３４】
前記ターゲットノードがコールサーバであることを特徴とする請求項３３に記載の方法。
【請求項３５】
各ソースノードがメディアゲートウエイ機能を提供することを特徴とする請求項３３又は３４に記載の方法。
【請求項３６】
単独で又は過負荷となっているメッセージの一部について拒否して戻されることになるメッセージの割合を、前記少なくとも１つのソースノードに対して前記ターゲットノードが通知するステップをさらに含むことを特徴とする請求項３３乃至３５のいずれか１項に記載の方法。
【請求項３７】
新規の発呼に関連して、前記少なくとも１つのソースノードからオフフックを通知するためのシグナリングメッセージを前記ターゲットノードが受信するステップをさらに含むことを特徴とする請求項３３乃至３６のいずれか１項に記載の方法。
【請求項３８】
前記方法は、前記通信システムが過負荷状態になると、前記少なくとも１つのソースノードから送信されるオフフックを通知するためのシグナリングメッセージに対して自動的な否定応答（ＮＡＫ）を用いて前記ターゲットノードが応答するステップをさらに含み、該否定応答には、拒否されるべき発呼の割合の情報が含まれていることを特徴とする請求項３７に記載の方法。
【請求項３９】
初期のフィルタリングによってオフフックの要求を前記少なくとも１つのソースノードが拒否するステップさらに含むことを特徴とする請求項３８に記載の方法。
【請求項４０】
前記方法は、前記少なくとも１つのソースノードが１種類以上のメッセージを前記ターゲットノードに送信するステップと、前記ターゲットノードが受信したメッセージの種類を特定するステップと、前記メッセージに対してそれ以上の処理なしで、新しい接続要求の特定の後にすぐに通知を送信するステップとをさらに含むことを特徴とする請求項３３乃至３９のいずれか１項に記載の方法。
【請求項４１】
前記メッセージを優先度の低いものと優先度の高いものに分類し、前記少なくとも１つのソースノードが優先度の低いメッセージを減少させるステップを含むことを特徴とする請求項３３乃至４０のいずれか１項に記載の方法。
【請求項４２】
前記優先度の高いメッセージの接続に成功する確率が上昇するよう第２の厳格でないフィルタによって前記優先度の高いメッセージを処理するステップをさらに含むことを特徴とする請求項４１に記載の方法。
【請求項４３】
前記通信システムが過負荷状態になっても、エンドユーザの一部のサービスを保障するステップをさらに含むことを特徴とする請求項３３乃至４２のいずれか１項に記載の方法。
【請求項４４】
前記ターゲットノードにメッセージが送信される割合を低下させる前記手段を、緊急サービスについてのメッセージをバイパスすることを許容するステップをさらに含むことを特徴とする請求項３３乃至４３のいずれか１項に記載の方法。
【請求項４５】
前記ターゲットノードが自己の処理負荷を検出するステップをさらに含むことを特徴とする請求項３３乃至４４のいずれか１項に記載の方法。
【請求項４６】
ある時間経過中にさらなる通知を受信しなかったことを前提に、その時間経過後に、前記ターゲットノードにメッセージが送信される割合を低下させることを特徴とする請求項３３乃至４５のいずれか１項に記載の方法。
【請求項４７】
ある時間経過中にさらなる通知を受信しなかったことを前提に、その時間経過後に、前記ターゲットノードにメッセージが送信される割合を上昇させることを特徴とする請求項３３乃至４５のいずれか１項に記載の方法。
【請求項４８】
各ソースノードは、メディアゲートウエイ機能を提供するネットワーク終端装置を含むことを特徴とする請求項３３乃至４７のいずれか１項に記載の方法。
【請求項４９】
各ソースノードに通知された情報を記録するステップを含むことを特徴とする請求項３３乃至４８のいずれか１項に記載の方法。
【請求項５０】
前記特定の処理レベルに達しているか、または、前記特定の処理レベルを越えている場合、ある時間の期間中、前記ターゲットノードにメッセージを供給するソースノードだけに通知をするステップを含むことを特徴とする請求項３３乃至４９のいずれか１項に記載の方法。
【請求項５１】
請求項５０に記載のソースノードのいずれかが、処理負荷の増加に続いて、さらにメッセージを前記ターゲットノードに送信する場合は、前記ターゲットノードが該ソースノードに新しい通知を送信するステップを含むことを特徴とする請求項５０に記載の通信システム。
【請求項５２】
前記ターゲットノードが前記ソースノードのいずれか１つに対して、前記処理負荷の特定のレベルについて１度だけ通知することを特徴とする請求項３３乃至５１のいずれか１項に記載の方法。
【請求項５３】
前記ソースノードに送信されたそれぞれのメッセージに対して、前記特定の処理負荷に達しているかどうか、特定の処理負荷を越えているかどうかについての通知を前記ターゲットノードが付与するステップを含むことを特徴とする請求項３３乃至５１のいずれか１項に記載の方法。
【請求項５４】
前記ソースノードに送信された呼に関係のない周期的なメッセージに対して、特定の処理負荷に達しているかどうか、特定の処理負荷を越えているかどうかについての通知を前記ターゲットノードが付与するステップを含むことを特徴とする請求項３３乃至５１のいずれか１項に記載の方法。
【請求項５５】
特定の処理負荷に達しており、または、特定の処理負荷を越えており、かつ、過負荷レベルがさらに増加している場合に、前記ターゲットノードが、すでにメッセージを通知されている少なくとも１つのソースノードのメッセージに対して、さらに通知をすることを特徴とする請求項３３乃至５４のいずれか１項に記載の方法。
【請求項５６】
前記処理負荷を、前記ソースノードからメッセージを受信する率に応じて定義することを特徴とする請求項３３乃至５５のいずれか１項に記載の方法。
【請求項５７】
前記処理負荷を定義するために用いられる受信メッセージは、新しい接続要求であることを特徴とする請求項３３乃至５６のいずれか１項に記載の方法。
【請求項５８】
前記ターゲットノードが少なくとも１００個のソースノードからメッセージを受信することを特徴とする請求項３３乃至５７のいずれか１項に記載の方法。
【請求項５９】
前記ターゲットノードが少なくとも１０００個のソースノードからメッセージを受信することを特徴とする請求項３３乃至５８のいずれか１項に記載の方法。
【請求項６０】
前記ターゲットノードが少なくとも１万個のソースノードからメッセージを受信することを特徴とする請求項３３乃至５９のいずれか１項に記載の方法。
【請求項６１】
前記ターゲットノードが少なくとも１０万個のソースノードからメッセージを受信することを特徴とする請求項３３乃至６０のいずれか１項に記載の方法。
【請求項６２】
前記ターゲットノードが少なくとも１００万個のソースノードからメッセージを受信することを特徴とする請求項３３乃至６１のいずれか１項に記載の方法。
【請求項６３】
前記メッセージは、インターネットを基礎としたメッセージであることを特徴とする請求項３３乃至６２のいずれか１項に記載の方法。
【請求項６４】
前記メッセージが前記ターゲットノードに到着する前に、メッセージが集中するのを回避するステップをさらに含むことを特徴とする請求項３３乃至６３のいずれか１項に記載の方法。
【国際調査報告】
2008502184.tif 000056
2008502184.tif 000057