JP2008502184A - 通信システムおよび負荷管理の方法 - Google Patents

通信システムおよび負荷管理の方法 Download PDF

Info

Publication number
JP2008502184A
JP2008502184A JP2007513928A JP2007513928A JP2008502184A JP 2008502184 A JP2008502184 A JP 2008502184A JP 2007513928 A JP2007513928 A JP 2007513928A JP 2007513928 A JP2007513928 A JP 2007513928A JP 2008502184 A JP2008502184 A JP 2008502184A
Authority
JP
Japan
Prior art keywords
message
gateway
target node
rate
communication system
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2007513928A
Other languages
English (en)
Other versions
JP4504421B2 (ja
Inventor
イアン ブロードハースト，
アンソニー， ピーター ラム，
ドナルド， デイビット スチュワート，
Original Assignee
エリクソン エービー
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by エリクソン エービー filed Critical エリクソン エービー
Publication of JP2008502184A publication Critical patent/JP2008502184A/ja
Application granted granted Critical
Publication of JP4504421B2 publication Critical patent/JP4504421B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q3/00—Selecting arrangements
    • H04Q3/0016—Arrangements providing connection between exchanges
    • H04Q3/0062—Provisions for network management
    • H04Q3/0091—Congestion or overload control
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13034—A/D conversion, code compression/expansion
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13106—Microprocessor, CPU
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13166—Fault prevention
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13196—Connection circuit/link/trunk/junction, bridge, router, gateway
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13387—Call gapping
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13389—LAN, internet

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Telephonic Communication Services (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Monitoring And Testing Of Exchanges (AREA)

Abstract

メッセージの通信のために配置されたターゲットノード、および、少なくとも１つのソースノードを含み、さらに、前記ターゲットノードは、少なくとも１つの前記ソースノードから受信したメッセージのうちの、少なくとも、いくつかを処理する手段と、前記ターゲットノードの処理負荷を検出する手段を含み、さらに、前記ターゲットノードは、ある特定の処理負荷レベルに達するか、または、ある特定の処理負荷レベルを越える場合、前記少なくとも１つのソースノードに通知する手段を含み、さらに、各ソースノードは、その通知に応答して、メッセージがターゲットノードに送信される割合を低下させる手段を含むことを特徴とする通信システム。

Description

本発明は、一般的には通信分野に関し、特に、通信システムと負荷管理に関連する方法に関する。
現在使用されているＰＳＴＮ（公衆電話交換網）においては、発信が過多状態であるとき、つまり、ネットワークに供給された発信数が、そのネットワークの処理容量を超えている場合に、ネットワークが弾力的に確実に回復動作できるようにするために、多くの時間と多大な労力が費やされている。この弾力的な回復動作は、ネットワーク全体と、ネットワーク内にある個別交換機の両方で動作する負荷制御方式を導入することで実現されている。
このＰＳＴＮでの負荷制御に関しての動作については、ネットワークレベルでは、国際標準化機関、および、種々の国の標準化機関が取り纏めたものがある。これらの負荷制御に関する努力の成果は、国際標準化に関するＩＴＵ−Ｔ（国際電気通信連合・電気通信標準化部門）の勧告「Ｑ．７４６」、「信号方式Ｎｏ．７・ＩＳＤＮ（サービス総合デジタル網）ユーザ部手順」、「英国標準化規格ＰＮＯ−ＩＳＣ/ＳＰＥＣ００７、ＰＮＯ−ＩＳＣ規格」、「信号方式Ｎｏ．７・ＩＳＤＮユーザ部（ＩＳＵＰ）」に反映されている。一般的には、これらのネットワークレベルでの制御は、ＰＳＴＮのネットワーク内の交換機からの応答により起動される。そのために、ネットワーク内の交換機が過負荷である場合、合理的に動作・反応することが求められる。その意味で、ＩＴＵ−Ｔでは、過負荷である場合の交換機の動作についての勧告「Ｑ．５４３・デジタル交換機性能設計目標」を提供している。但し、勧告されたような交換機の動作が、どのように達成されるかに関しての正確な構成内容は、まだ特定されてはいない。図１は、過負荷時の交換機の特徴的な動作を示したものである。
基本的には、大抵のネットワークレベルの負荷制御方式は、交換機での過負荷に対処するために「バックオフ(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」を、ゲートウエイが受け入れを拒否することを決定する事例を示している。ゲートウエイは、ネットワーク・ビジー・トーンを発信して、この拒否内容をエンドユーザに通知する。
本発明は、前記で述べた特定の実施例のいずれかに限定されるものではなく、これらの実施例は単に例示のためのものである。前記で述べた特定の実施例に対する変更は、この発明の範囲を逸脱することなく遂行できる。例えば、この発明の実施のために、多様なメッセージフォーマットおよびプロトコルを使用してもよい。ダウンストリームレベルの負荷を処理し、正確で効果的なメッセージ制御が可能なソースノードを提供することにより、インターネットを基礎にした通信システムの性能を向上させることができることは、本発明の長所である。
図１は、従来のコールサーバの応答特性を示したものである。 図２は、従来のコールサーバの応答特性を示したものである。 図３は、従来のＰＳＴＮを概略的に示したものである。 図４は、提案されている次世代ネットワークを概略的に示したものである。 図５は、本発明による情報フローを概略的に示したものである。 図６は、本発明による情報フローを概略的に示したものである。 、 、 、 、 、 図７は、本発明の概略状態遷移図である。 、 、 、 、 、 図８は、本発明の概略状態遷移図である。 図９は、先行技術のメッセージフローを概略的に示したものである。 図１０は、従来技術のメッセージフローを概略的に示したものである。 図１１は、本発明のメッセージフローを概略的に示したものである。 図１２は、本発明のメッセージフローを概略的に示したものである。 図１３は、本発明のメッセージフローを概略的に示したものである。 図１４は、本発明のメッセージフローを概略的に示したものである。 図１５は、本発明のメッセージフローを概略的に示したものである。 図１６は、本発明のメッセージフローを概略的に示したものである。 図１７は、本発明による情報フローを概略的に示したものである。 、 、 、 、 、 図１８は、本発明の概略状態遷移図である。 、 、 、 、 、 図１９は、本発明の概略状態遷移図である。 図２０は、本発明による情報フローを概略的に示したものである。 図２１は、本発明による情報フローを概略的に示したものである。 、 、 、 、 、 図２２は、本発明の概略状態遷移図である。 、 、 、 、 、 図２３は、本発明の概略状態遷移図である。

Claims (53)

  1. メッセージの通信のために配置されたターゲットノード、および、少なくとも１つのソースノードを含み、さらに、前記ターゲットノードは、前記少なくとも１つのソースノードから受信したメッセージのうちの、少なくともいくつかを処理する手段と、前記ターゲットノードの処理負荷を検出する手段を含み、さらに、前記ターゲットノードは、ある特定の処理負荷レベルに達しているか、または、ある特定の処理負荷レベルを越えている場合、前記少なくとも１つのソースノードに通知する手段を含み、さらに、各ソースノードは、その通知に応答して、前記ターゲットノードにメッセージが送信される割合を低下させる手段を含むことを特徴とする通信システム。
  2. 前記割合の低下を、前記ターゲットノードに転送を行う前記少なくとも１つのソースノードで受信されたメッセージのうち特定の割合のメッセージを拒否することで実現することを特徴とする請求項１に記載の通信システム。
  3. 前記ターゲットノードは、前記特定の割合を、前記少なくとも１つのソースノードに通知する手段を含むことを特徴とする請求項１又は２に記載の通信システム。
  4. 各ソースノードに配置される前記手段は、ある期間に亘って、これ以上の通知を受信することはないということを根拠に、メッセージが前記ターゲットノードに送信される割合を、ある時間経過後に増加させるよう構成されていることを特徴とする請求項１乃至３のいずれか１項に記載の通信システム。
  5. 各ソースノードに配置される前記手段は、ある期間に亘って、これ以上の通知を受信することはないということを根拠に、メッセージが前記ターゲットノードに送信される割合を、ある時間経過後に減少させるよう構成されていることを特徴とする請求項１乃至３のいずれか１項に記載の通信システム。
  6. 前記ターゲットノードは、各ソースノードに通知された情報を記録する手段を含むことを特徴とする請求項１乃至５のいずれか１項に記載の通信システム。
  7. 前記ターゲットノードは、特定の処理負荷に達するか、または、越えた、ある期間中において、該ターゲットノードにメッセージを供給する前記ソースノードに通知することだけ実行するよう構成されていることを特徴とする請求項１乃至６のいずれか１項に記載の通信システム。
  8. 前記ターゲットノードは、処理負荷の増加に続いて、前記ソースノードが単独でまたは複数で、さらにメッセージを該ターゲットノードに送信する場合に、請求項７に記載の前記ソースノードのいずれかに新しい通知をするよう構成されていることを特徴とする請求項７に記載の通信システム。
  9. 前記ターゲットノードは、処理負荷の特定のレベルに対して１回だけ、前記ソースノードのいずれか１つに通知をするよう構成されていることを特徴とする請求項１乃至８のいずれか１項に記載の通信システム。
  10. 前記ターゲットノードは、前記ソースノードに送信されるメッセージのそれぞれに、特定の負荷に達したかどうか、あるいは、特定の負荷を越えたかどうかについての通知を付与するよう構成されていることを特徴とする請求項１乃至８のいずれか１項に記載の通信システム。
  11. 前記ターゲットノードは、前記ソースノードに送信される、呼に関係のない周期的なメッセージに、特定の負荷に達したかどうか、あるいは、特定の負荷を越えたかどうかについての通知を付与するよう構成されていることを特徴とする請求項１乃至８のいずれか１項に記載の通信システム。
  12. 前記ターゲットノードは、特定の処理負荷レベルに達しており、または、特定の処理負荷レベルを越えており、その負荷レベルがさらに上昇している場合に、すでに通知済みの少なくとも１つのソースノードに対して、さらに通知を行うよう構成されていることを特徴とする請求項１乃至１１のいずれか１項に記載の通信システム。
  13. 前記処理負荷は、前記ソースノードからメッセージが受信される率に応じて定義されることを特徴とする請求項１乃至１２のいずれか１項に記載の通信システム。
  14. 前記処理負荷を定義するために用いられる受信メッセージは、新しい接続要求であることを特徴とする請求項１乃至１３のいずれか１項に記載の通信システム。
  15. 前記少なくとも１つの前記ソースノードは、１種類以上のメッセージを前記ターゲットノードに送信するよう構成されており、さらに、前記ターゲットノードは、受信したメッセージの種類を特定し、新しい接続要求の同定の後すぐに、メッセージに如何なる処理もしないで、通知を送信するよう構成されていることを特徴とする請求項１乃至１４のいずれか１項に記載の通信システム。
  16. 前記ターゲットノードは、少なくとも１００個のソースノードからメッセージを受信するよう構成されていることを特徴とする請求項１乃至１５のいずれか１項に記載の通信システム。
  17. 前記ターゲットノードは、少なくとも１０００個のソースノードからメッセージを受信するよう構成されていることを特徴とする請求項１乃至１６のいずれか１項に記載の通信システム。
  18. 前記ターゲットノードは、少なくとも、１万個のソースノードからメッセージを受信するよう構成されていることを特徴とする請求項１乃至１７のいずれか１項に記載の通信システム。
  19. 前記ターゲットノードは、少なくとも１０万個のソースノードからメッセージを受信するよう構成されていることを特徴とする請求項１乃至１８のいずれか１項に記載の通信システム。
  20. 前記ターゲットノードは、少なくとも１００万個のソースノードからメッセージを受信するよう構成されていることを特徴とする請求項１乃至１９のいずれか１項に記載の通信システム。
  21. 前記ターゲットノードはコールサーバであることを特徴とする請求項１乃至２０のいずれか１項に記載の通信システム。
  22. 各ソースノードは、メディアゲートウエイ機能を提供するネットワーク終端装置を含むことを特徴とする請求項１乃至２１のいずれか１項に記載の通信システム。
  23. 前記メッセージは、インターネットプロトコル（ＩＰ）を基礎にしたメッセージであることを特徴とする請求項１乃至２２のいずれか１項に記載の通信システム。
  24. 前記メッセージがターゲットノードに到着する前に、メッセージの集中が発生しないようにしたことを特徴とする請求項１乃至２３のいずれか１項に記載の通信システム。
  25. 前記メッセージは、優先度の低いメッセージと優先度の高いメッセージに分類され、優先度の低いメッセージの割合を低下させることだけを実行するよう、前記少なくとも１つのソースノードが構成されていることを特徴とする請求項１乃至２４のいずれか１項に記載の通信システム。
  26. 少なくとも１つのソースノードからメッセージを受信し、該少なくとも１つのソースノードから受信するメッセージの少なくともいくつかを処理するターゲットノードでの負荷を制御する方法であって、前記ターゲットノードの処理負荷を検出するステップと、特定の処理負荷レベルに達しているか、または、特定の処理レベルを越えている場合、少なくとも１つのソースノードに通知するステップとを含み、各ソースノードが、その通知に応答して、前記ターゲットノードにメッセージが送信される割合を低下させることを特徴とする方法。
  27. 前記ターゲットノードにメッセージを転送するための、前記少なくとも１つのソースノードで受信されるメッセージの特定の割合を低下させるステップを含むことを特徴とする請求項２６に記載の方法。
  28. 前記ターゲットノードが、前記特定の割合を、少なくとも１つのソースノードに通知することを特徴とする請求項２６又は２７に記載の方法。
  29. ある時間経過中にさらなる通知を受信しなかったことを前提に、その時間経過後に、前記ターゲットノードにメッセージが送信される割合を上昇させることを特徴とする請求項２６乃至２８のいずれか１項に記載の方法。
  30. ある時間経過中にさらなる通知を受信しなかったことを前提に、その時間経過後に、前記ターゲットノードにメッセージが送信される割合を低下させることを特徴とする請求項２６乃至２８のいずれか１項に記載の方法。
  31. 各ソースノードに通知された情報を記録するステップを含むことを特徴とする請求項２６乃至３０のいずれか１項に記載の方法。
  32. 前記特定の処理レベルに達しているか、または、前記特定の処理レベルを越えている場合、ある時間の期間中、前記ターゲットノードにメッセージを供給するソースノードだけに通知をするステップを含むことを特徴とする請求項２６乃至３１のいずれか１項に記載の方法。
  33. 請求項３２に記載のソースノードのいずれかが、処理負荷の増加に続いて、さらにメッセージを前記ターゲットノードに送信する場合は、前記ターゲットノードが該ソースノードに新しい通知を送信するステップを含むことを特徴とする請求項３２に記載の通信システム。
  34. 前記ターゲットノードが前記ソースノードのいずれか１つに対して、前記処理負荷の特定のレベルについて１度だけ通知することを特徴とする請求項２６乃至３３のいずれか１項に記載の方法。
  35. 前記ソースノードに送信されたそれぞれのメッセージに対して、前記特定の処理負荷に達しているかどうか、特定の処理負荷を越えているかどうかについての通知を前記ターゲットノードが付与するステップを含むことを特徴とする請求項２６乃至３３のいずれか１項に記載の方法。
  36. 前記ソースノードに送信された呼に関係のない周期的なメッセージに対して、特定の処理負荷に達しているかどうか、特定の処理負荷を越えているかどうかについての通知を前記ターゲットノードが付与するステップを含むことを特徴とする請求項２６乃至３３のいずれか１項に記載の方法。
  37. 特定の処理負荷に達しており、または、特定の処理負荷を越えており、かつ、過負荷レベルがさらに増加している場合に、前記ターゲットノードが、すでにメッセージを通知されている少なくとも１つのソースノードのメッセージに対して、さらに通知をすることを特徴とする請求項２６乃至３６のいずれか１項に記載の方法。
  38. 前記処理負荷を、前記ソースノードからメッセージを受信する率に応じて定義することを特徴とする請求項２６乃至３７のいずれか１項に記載の方法。
  39. 前記処理負荷を定義するために用いられる受信メッセージは、新しい接続要求であることを特徴とする請求項２６乃至３８のいずれか１項に記載の方法。
  40. 前記少なくとも１つのソースノードが１種類以上のメッセージを前記ターゲットノードに送信するステップと、前記ターゲットノードが受信したメッセージの種類を特定するステップと、前記メッセージに対してそれ以上の処理なしで、新しい接続要求の特定の後に、すぐに通知を送信するステップとをさらに含むことを特徴とする請求項２６乃至３９のいずれか１項に記載の方法。
  41. 前記ターゲットノードが少なくとも１００個のソースノードからメッセージを受信することを特徴とする請求項２６乃至４０のいずれか１項に記載の方法。
  42. 前記ターゲットノードが少なくとも１０００個のソースノードからメッセージを受信することを特徴とする請求項２６乃至４１のいずれか１項に記載の方法。
  43. 前記ターゲットノードが少なくとも１万個のソースノードからメッセージを受信することを特徴とする請求項２６乃至４２のいずれか１項に記載の方法。
  44. 前記ターゲットノードが少なくとも１０万個のソースノードからメッセージを受信することを特徴とする請求項２６乃至４３のいずれか１項に記載の方法。
  45. 前記ターゲットノードが少なくとも１００万個のソースノードからメッセージを受信することを特徴とする請求項２６乃至４４のいずれか１項に記載の方法。
  46. 前記ターゲットノードがコールサーバであることを特徴とする請求項２６乃至４５のいずれか１項に記載の方法。
  47. 各ソースノードがネットワーク終端装置にメディアゲートウエイ機能を提供することを特徴とする請求項２６乃至４６のいずれか１項に記載の方法。
  48. 前記メッセージは、インターネットを基礎としたメッセージであることを特徴とする請求項２６乃至４７のいずれか１項に記載の方法。
  49. 前記メッセージが前記ターゲットノードに到着する前に、メッセージが集中するのを回避するステップをさらに含むことを特徴とする請求項２６乃至４８のいずれか１項に記載の方法。
  50. 前記メッセージを優先度の低いものと優先度の高いものに分類し、前記少なくとも１つのソースノードが優先度の低いメッセージを減少させるステップを含むことを特徴とする請求項２６乃至４９のいずれか１項に記載の方法。
  51. 実質的に図５、６、７、８を参照しながら記載され、かつ、図５、６、７、８に示された通信システムまたは通信方法。
  52. 実質的に図５、図１７乃至１９を参照しながら記載され、かつ、図５、図１７乃至１９に示された通信システムまたは通信方法。
  53. 実質的に図２０乃至２３を参照しながら記載され、かつ、図２０乃至２３に示された通信システムまたは通信方法。
JP2007513928A 2004-06-04 2005-05-25 通信システムおよび負荷管理の方法 Expired - Fee Related JP4504421B2 (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
GB0412574A GB2414891B (en) 2004-06-04 2004-06-04 Communications system
PCT/EP2005/052387 WO2005120087A1 (en) 2004-06-04 2005-05-25 Communications system and method for load management

Publications (2)

Publication Number Publication Date
JP2008502184A true JP2008502184A (ja) 2008-01-24
JP4504421B2 JP4504421B2 (ja) 2010-07-14

Family

ID=32696713

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2007513928A Expired - Fee Related JP4504421B2 (ja) 2004-06-04 2005-05-25 通信システムおよび負荷管理の方法

Country Status (6)

Country Link
US (1) US8817609B2 (ja)
EP (1) EP1772025A1 (ja)
JP (1) JP4504421B2 (ja)
CN (1) CN101027915B (ja)
GB (1) GB2414891B (ja)
WO (1) WO2005120087A1 (ja)

Families Citing this family (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN100411482C (zh) * 2005-07-27 2008-08-13 华为技术有限公司 接入媒体网关过载控制方法
US8446829B2 (en) 2006-09-11 2013-05-21 Telefonaktiebolaget L M Ericsson (Publ) System and method for overload control in a next generation network
US9253099B2 (en) 2006-09-11 2016-02-02 Telefonaktiebolaget L M Ericsson (Publ) System and method for overload control in a next generation network
US9497229B2 (en) * 2007-05-16 2016-11-15 At&T Intellectual Property I, L.P. Methods and apparatus to manage internet protocol (IP) multimedia subsystem (IMS) network capacity
WO2010009764A1 (en) * 2008-07-24 2010-01-28 Telefonaktiebolaget Lm Ericsson (Publ) Overload control in a quality-of-service- aware telecommunications network
US9467308B2 (en) 2008-08-01 2016-10-11 At&T Intellectual Property I, L.P. Methods and apparatus to control synchronization in voice over internet protocol networks after catastrophes
US7965629B2 (en) 2009-02-27 2011-06-21 Telefonaktiebolaget L M Ericsson (Publ) System and method providing overload control in next generation networks
EP2302888A1 (en) * 2009-09-29 2011-03-30 BRITISH TELECOMMUNICATIONS public limited company Telephone access network
CN103034654B (zh) * 2011-10-10 2016-06-15 中国电信股份有限公司 社会化动态消息呈现控制方法及系统
US10091629B2 (en) 2015-04-07 2018-10-02 At&T Intellectual Property I, L.P. Method and system for providing broadcast media services in a communication system
CN107682301B (zh) * 2016-08-02 2020-05-01 中国电信股份有限公司 用于实现话务控制的方法、装置和系统
CN111490911B (zh) * 2020-03-30 2022-06-14 中移（杭州）信息技术有限公司 网关故障信息收集方法、装置、网络设备及存储介质

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS61210751A (ja) * 1985-03-14 1986-09-18 Nec Corp 基本サ−ビス保護制御方法
JP2001333114A (ja) * 2000-05-22 2001-11-30 Hitachi Ltd インタネットゲートウェイシステムでの迂回制御方法
JP2003009221A (ja) * 2001-06-27 2003-01-10 Nec Corp 交換機の輻輳制御装置および交換機の輻輳制御方法
WO2003010931A1 (en) * 2001-07-26 2003-02-06 Koninklijke Philips Electronics N.V. Method for reliable and efficient support of congestion control in nack-based protocols
JP2003179636A (ja) * 2001-12-12 2003-06-27 Fujitsu Ltd ＶｏＩＰネットワークの輻輳制御システム

Family Cites Families (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CA2112756C (en) * 1993-01-06 1999-12-14 Chinatsu Ikeda Burst band-width reservation method in asynchronous transfer mode (atm) network
US5450483A (en) * 1993-11-18 1995-09-12 British Telecommunications P.L.C. Method of controlling overloads in a telecommunications network
US5650993A (en) * 1995-03-20 1997-07-22 Bell Communications Research, Inc. Drop from front of buffer policy in feedback networks
KR100318957B1 (ko) * 1996-09-02 2002-04-22 윤종용 비동기전송모드망에서의폭주통보장치및폭주제어방법
EP0955749A1 (en) * 1998-05-08 1999-11-10 Nortel Networks Corporation Receiver based congestion control and congestion notification from router
US6542462B1 (en) * 1998-05-27 2003-04-01 Lucent Technologies Inc. Method and apparatus for overload control of multimedia communications in a hybrid switching system
US6097697A (en) * 1998-07-17 2000-08-01 Sitara Networks, Inc. Congestion control
US6363052B1 (en) * 1998-07-20 2002-03-26 At&T Corp Congestion control in network systems
JP3556495B2 (ja) * 1998-12-15 2004-08-18 株式会社東芝 パケットスイッチ及びパケット交換方法
US7254228B2 (en) * 2000-09-28 2007-08-07 Eci Telecom Ltd. Method and system for effective utilizing the switching capacity of local exchanges
GB2375002B (en) * 2001-04-25 2003-07-09 Lucent Technologies Inc A method for overload control in a telecommunications network and apparatus therefor
US7630359B1 (en) * 2001-09-28 2009-12-08 At&T Corp. Technique for providing translation between the packet environment and the PSTN environment
KR100415115B1 (ko) * 2001-11-29 2004-01-13 삼성전자주식회사 통신시스템의 데이터 혼잡 통보 방법 및 장치
CN1225216C (zh) * 2002-09-11 2005-11-02 西安大鹏生物科技股份有限公司 一种含功能性低聚糖的运动饮料
EP1416668B1 (en) * 2002-11-04 2009-04-22 Siemens Aktiengesellschaft Method and apparatus for achieving an optimal response time in a telecommunication system

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS61210751A (ja) * 1985-03-14 1986-09-18 Nec Corp 基本サ−ビス保護制御方法
JP2001333114A (ja) * 2000-05-22 2001-11-30 Hitachi Ltd インタネットゲートウェイシステムでの迂回制御方法
JP2003009221A (ja) * 2001-06-27 2003-01-10 Nec Corp 交換機の輻輳制御装置および交換機の輻輳制御方法
WO2003010931A1 (en) * 2001-07-26 2003-02-06 Koninklijke Philips Electronics N.V. Method for reliable and efficient support of congestion control in nack-based protocols
JP2003179636A (ja) * 2001-12-12 2003-06-27 Fujitsu Ltd ＶｏＩＰネットワークの輻輳制御システム

Also Published As

Publication number Publication date
CN101027915A (zh) 2007-08-29
US8817609B2 (en) 2014-08-26
EP1772025A1 (en) 2007-04-11
WO2005120087A1 (en) 2005-12-15
CN101027915B (zh) 2013-03-13
JP4504421B2 (ja) 2010-07-14
US20080267064A1 (en) 2008-10-30
GB2414891B (en) 2007-11-07
GB2414891A (en) 2005-12-07
GB0412574D0 (en) 2004-07-07

Similar Documents

Publication Publication Date Title
JP4504421B2 (ja) 通信システムおよび負荷管理の方法
CA2220898C (en) Systems and methods for providing communications through an alternate communication network
RU2391790C2 (ru) Способ контроля перегрузки медиа-шлюза доступа и медиа-шлюз доступа
US7515904B2 (en) Method and system for notifying a caller that a cellular phone destination is available
JP3871604B2 (ja) ＶｏＩＰネットワークシステム
CN100421529C (zh) 一种呼叫释放控制系统及其方法
WO2008040237A1 (fr) Procédé, système, terminal et serveur destinés à l'interception de courrier électronique indésirable dans le domaine de la téléphonie ip
KR100403725B1 (ko) 보이스 오버 인터넷 프로토콜 시스템에서의 그룹 착신 호제어방법
US20020176558A1 (en) Modem and system with call waiting switching facilities and method of supporting customer access to a service provider
US20080089504A1 (en) Method for Providing Presence Information in a Telecom Network
CN1719788A (zh) 软交换监听的呼叫控制及业务监听方法
US6681006B1 (en) Service activation upon automatic callback and automatic recall expiration
JP2002290550A (ja) 音声ゲートウェイ装置、その処理方法及びそのプログラム
Rumsewicz On the efficacy of using the transfer-controlled procedure during periods of STP processor overload in SS7 networks
JP3583565B2 (ja) 通信ネットワークにおける接続制御システムおよびその方法および通信ネットワーク内で優先度を付けた接続を確立するシステム
JP3319457B2 (ja) 電話音声応答システム
JPH09507979A (ja) ファシリティ系及びベース交換系を備えた通信交換システム
CN100512237C (zh) V5接入适配的c路径状态检测方法
KR100451785B1 (ko) 물리링크(ｅ１) 수 변동에 따른 ｖ５.２리 프로비젼 절차방법
EP1943825B1 (en) System and method for managing the replacement of an existing subscriber call connection by a call waiting party
JP3656978B2 (ja) 通信内容記録装置及び通信内容記録方法
JP4530560B2 (ja) 電話網を利用した、データ通信端末装置への任意の着信を可能とする通信システム
EP0982922A1 (en) Shared voice and data link
JPH06276295A (ja) Ａｔｍ交換機におけるマルチパーティ制御装置
AU2001249157A2 (en) Continuity testing in communication networks

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20080514

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20090903

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20090918

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20091215

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20091218

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20100402

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20100422

R150 Certificate of patent or registration of utility model

Ref document number: 4504421

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

Free format text: JAPANESE INTERMEDIATE CODE: R150

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20130430

Year of fee payment: 3

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20130430

Year of fee payment: 3

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20140430

Year of fee payment: 4

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

LAPS Cancellation because of no payment of annual fees