JP4531866B2

JP4531866B2 - 通信ネットワーク

Info

Publication number: JP4531866B2
Application number: JP53170498A
Authority: JP
Inventors: フント、ローランド・ジェフレイ
Original assignee: British Telecommunications PLC
Current assignee: British Telecommunications PLC
Priority date: 1997-01-22
Filing date: 1998-01-14
Publication date: 2010-08-25
Anticipated expiration: 2018-01-14
Also published as: WO1998033333A3; AU739159B2; US6330313B1; DE69829165T2; EP0954934B1; WO1998033333A2; JP2001508621A; CA2278183C; AU5568898A; CA2278183A1; NZ336657A; DE69829165D1; EP0954934A2

Description

本発明は通信ネットワーク、とくに通信ネットワークのオーバーロードを防ぐ方法及び装置に関する。
遠隔通信ネットワークにおいて最も需要の高いトラヒックパターンの幾つかは、テレマーケティング呼応答センタの動作に関係している。例えば、呼応答センタの電話番号が全国放送の商品広告の一部として表示されることがある。したがって広告後、短時間に何千もの呼が呼応答センタの電話番号対して行われることがある。このような呼レベルは多数の地点、例えば中間のＤＭＳＵ（ディジタルメインスイッチングユニット）および宛先交換局でネットワークをオーバーロードさせる潜在性がある。
ＩＮ（インテリジェントネットワーク）アーキテクチャを使用するネットワークでは、以前にＩＮプラットフォームに呼ギャッピング機構(call gaping mechanism:呼と呼との間にポーズをとる)を設けることが提案された。この提案では、プラットフォームはサービススイッチングポイント（ＳＳＰ）へ指令を送り、ＳＳＰからＩＮプラットフォームへのインバウンド呼のレートを低減することができる。しかしながら、この機構はＩＮプラットフォームにおいてオーバーロードするのを防ぐのに効果的であるが、プラットフォームからのダウンストリームにある宛先交換局をそれ自身では適切に保護しない。ＩＮプラットフォームは、一般的に個々の交換局の容量よりも数倍大きい呼処理容量をもつ。したがってＩＮプラットフォームを保護するために呼ギャッピング機構が呼出される相当前に、プラットフォームは、宛先交換局でソフトウエア故障の危険をもたらすのに十分なほどのレートで宛先交換局へ呼を送ることがある。宛先交換局がトラヒックの突然のピークに耐えて、呼を応答センタへ送っても、応答センタの容量を超えているときは呼の多くは繋がらず、発呼者へビジー信号が送られることになる。無駄なことであるとこんな呼は分かっているし、ネットワークオペレータにとっても、応答センタにとっても収益を稼げないが、それでいてネットワークトラヒックに呼が追加されるので、ネットワークインフラストラクチャによって支援されなければならない。
宛先交換局へのオーバーロードを防ぎ、無駄な呼数を低減するために、本発明の出願人は以前に、ネットワークプラットフォームから宛先交換局へ向うアウトワードレッグで呼レートを制御する機構を提案した。国際特許出願PCT/GB94/02512号明細書では、呼レベルを監視および制御して、呼応答センタから所定の比較的低レベルのビジー信号を維持するアプローチ（やり方）を開示し、請求の範囲に記載している。このアプローチ（やり方）は、応答センタのリソースを効果的に使用し、一方でローカル交換局をオーバーロードから保護することを保証することを助ける。このアプローチではネットワーク上の無駄な呼数をある程度低減するが、相当数はそのままである。さらに、各応答センタごとに所定数の超過呼を認めているので、呼応答が幾つかのセンタに分配されるときは無駄な呼の合計カウントは増加する。
本発明の第１の態様にしたがって、通信ネットワークを動作する方法であって：
ａ）多数の呼を受取る容量をもつ選択された宛先電話番号について、現在進行中の呼数のカウントを維持する段階と；
ｂ）呼が選択された宛先に認められるとき、および呼が終了するとき、前記カウントを自動的に更新する段階と；
ｃ）選択された宛先電話番号の最大容量値を記憶する段階と；
ｄ）新しい呼が宛先電話番号に対して行われるとき、進行中の呼数のカウントと前記最大容量値とを比較して、呼を認めることによって最大容量値を超えるときにこの新しい呼を拒絶する段階とを含む通信ネットワークを動作する方法。
本明細書で使用しているように“選択された宛先電話番号”という用語は、１つの電話番号、例えば０８００４００４９６、または選択されたグループの電話番号もしくは一定の範囲の電話番号、例えば０８００４００＊＊＊（尚、＊＊＊は任意の３つのディジットである）を含む。
本発明は、宛先電話番号、例えば応答センタの電話番号に対する呼レベルを制御する新しいアプローチを採用している。あるレートのビジー信号の生成のみに依存するのではなく、ネットワーク内で、例えばＩＮプラットフォームに配置された応答サーバ内で、容量、すなわち同時呼の最大数と、宛先電話番号の現在の状態とをモデル化する。したがって、応答センタの全容量が使用中であることが確認されると直ぐに、それ以上の別の呼はローカル交換局に送られるのではなく、解放(release)されるかまたは再方向付けされる。これにより応答センタの量を適切に使用し、一方で無効呼数をわずかなレベルにまで低減することを保証する。
好ましくは、該方法は：
ｅ）認められた呼に対するネットワークの応答に依存して、段階（ｃ）で記憶された最大容量値を後に変更する段階をさらに含む。
本発明の発明者は、ネットワークからのフィードバックに基づいて容量値を変更することによって、呼制御プロセスの効率が著しく向上することに気付いた。これによりプロセスは容量の変更に自動的に適合でき、容量値を最初に完壁に正確に決める必要がなくなった。
好ましくは段階（ｃ）は：
宛先電話番号の最大容量を推定し、その推定値を記憶する段階を含む。好ましくは容量を推定する段階は：
一定の期間の間に、宛先電話番号への完了呼数Ｎｃを監視し、各呼を完了するのにかかる時間Ｔ_cを記録する段階と；
該宛先電話番号への呼の平均保持時間から容量推定値を計算し、平均保持時間が前記一定期間中に記録されるＮ_cおよびＴ_cの値から導き出される段階とを含む。
本発明のこの好ましい特徴は、応答センタまたは他の宛先電話番号のモデル化を支援するのに必要なデータまたはシグナリング量を最小にする。各応答センタの容量に関するデータを記憶し、センタの容量が変化するたびに該データをマニュアルで変更しなければならないのに代って、このモデルは応答センタ容量の最初の推定値を計算するトレーニングプロセスを経ることができる。トレーニングプロセス中には、全ての発呼が応答センタに認められるかまたは少なくともかなりの呼の超過が応答センタの応答レート能力以上で認められる。トレーニングプロセスが終了すると、好ましい構成では、システムは追跡モードになり、追跡モードでは呼を認めても現在進行中の呼の合計が応答センタの現在の容量推定値を越えないときのみ、発信された呼が認められる。さらに本発明は追跡モードで、宛先の状態に関する情報を伝えるネットワークからのシグナリングに応答して応答センタの現在の容量推定値に適合させることができる。この追跡プロセスは、例えば宛先電話番号がビジー信号に応答するときの検出に依存することができる。これを検出したとき、推定値をデクレメントすることができる。これとは対照的に、推定容量に既に到達してしまっているときに新しい呼が認められると、かつビジー信号を戻さずに新しい呼が接続されると、推定容量値をインクレメントすることができる。
好ましくは、宛先電話番号における積滞（混雑）を検出したときのみ、段階（ａ）乃至（ｄ）が開始される。好ましくは段階（ａ）乃至（ｄ）は、複数の前記選択された宛先電話番号にサービスする単一のサーバにおいて実行され、段階（ａ）乃至（ｄ）を実行するためのリソースは、前記宛先電話番号で積滞が検出されたときにサーバ上で各宛先電話番号へ割当てられる。
電話番号が積滞したときに特定の電話番号をダイナミックにかつ自動的に監視するためにリソースを割当てることによって監視プロセスの効率はさらに最大限に向上する。トリガは、例えば応答センタによって戻される第１のビジー信号であってもよい。このアプローチでは監視を必要とするときのみこれを行ない、ネットワーク上の関係付けられたシグナリングオーバーヘッドを最小に保つことを保証する。これにより単一の監視センタ、または少数の呼センタで、イギリスのＰＳＴＮにおける全応答センタにサービスできるという実効レベルを達成できる。
可能な限り迅速に応答容量を推定するために、呼保持時間と比較可能かまたは一層短い時間中に、呼保持時間を推定することが好ましい。好ましくは、該電話番号への呼の平均保持時間は次の関係から導き出される：

なお、

は推定平均保持時間であり、Ｔ_cは監視される既に終わった呼を終了するのにかかった時間であり、Ｎ_cは該監視される既に終わった呼の電話番号であり、Ｔ_Iは監視されるまだ終わっていない呼の現在までに経過した時間であり、Ｎ_Iは該監視されるまだ終わっていない呼の電話番号である。この結果は、保持時間が負の指数関数的分布をもつ呼に当てはまる。これは国内ネットワーク全体の呼の母集団(population)にほぼ当てはまる。しかしながらこの母集団のサブセットは時には異なる母集団をもってもよい。例えば、電話投票またはクレジットカードで寄付を行う電話呼において、保持時間を予め決めるかまたは全体的に固定することができる。この形式の決定論的分配では、次の関係を使用して平均保持時間を決定する：

本発明の第２の態様にしたがって、端末リソースを接続するようにされた複数の相互接続されたノードを含む通信ネットワークで使用するのに適した呼制御サーバであって：
ａ）選択された宛先電話番号に割当て可能であり、宛先電話番号への進行中の呼の合計数のカウントを維持するようにされた呼カウンタと；
ｂ）選択された宛先電話番号への呼が完了したときに生成されるネットワーク信号を受取るようにされたネットワークシグナリングインターフェイスと；
ｃ）ネットワークシグナリングインターフェイスおよび呼カウンタに接続され、ネットワークシグナリングインターフェイスで受取られる前記信号に応答して呼カウンタによって維持されているカウントを自動的に更新するようにされたカウンタ制御装置と；
ｄ）選択された宛先電話番号の容量値でプログラムされているメモリと；
ｅ）呼カウンタおよびメモリに接続され―
呼カウンタの値と前記メモリ内のプログラムされた値とを比較するコンパレータと；
新しい呼に接続したときに宛先電話番号の容量を超過してしまう場合に、制御信号を生成して、宛先にルート設定せずに新しい呼を拒絶するようにされた制御信号生成装置とを含む呼制御装置とを備えた呼制御サーバを提供する。
本発明の第３の態様にしたがって、通信ネットワークであって：
ａ）端末リソースを接続するようにされた複数の相互接続されたノードと；
ｂ）第２の態様にしたがう呼制御サーバとを備えた通信ネットワークを提供する。
ここで本発明の実施形態を添付の図面を引用して例示的にさらに詳しく記載する：
図１は、本発明を実現するネットワークの模式図である；
図２は、図１の応答センタサーバの状態図である；
図３は、複数の応答センタサーバを含むネットワークの模式図である；
図４および５は、図１のネットワークの動作を示す呼のフローチャートである；
図６は、サービス制御ポイント（ＳＣＰ）のアーキテクチャをさらに詳細に示すネットワークの模式図である；
図７は、図６のＳＣＰ内の異なるプロトコル層を示すダイヤグラムである；
図８は、応答サーバの主な機能素子を示すダイヤグラムである。
ＩＮ（インテリジェントネットワーク）のアーキテクチャを使用する遠隔通信ネットワークはサービス制御ポイント１を含み、本明細書ではサービス制御ポイント１をネットワークインテリジェンスプラットフォーム（ＮＩＰ）とも記載している。サービス制御ポイント１は、基幹ディジタルメインスイッチングユニット（ＤＭＳＵ）２、３およびディジタルローカル交換局（ＤＬＥ）４、５へも接続されている。ＤＭＳＵとＤＬＥの両方は、サービススイッチングポイント（ＳＳＰ）として機能する。呼の進行中に一定のポイントで、ＳＳＰは呼の制御をサービス制御ポイントに転送する。サービス制御ポイントは電話番号変換のような機能を行ない、音声メッセージ送信プラットフォームのような付加的なリソースへのゲートウエイを準備する。さらに本発明のこの実施形態では、ＳＣＰは応答センタサーバ（ＡＣＳ）100を構成している。
図６は、ＳＣＰの１つの可能なアーキテクチャをさらに詳しく示している。この例ではＳＣＰは、多数のＣ７フロントエンド（前置）プロセッサ（ＦＥＰ）62及びバックエンド（後置）プロセッサ（ＢＥＰ）61をＦＤＤＩＬＡＮ63によって接続した形で含んでいる。ＡＣＳを構成しているオーバーロード制御サーバ（ＯＣＳ）66もＦＤＤＩＬＡＮ63に接続されている。ＳＳＰ65からの信号はＣ７シグナリングネットワーク64を介して各前置プロセッサの１つへ伝えられる。新しい呼は後置プロセッサの１つに割当てられる。到来呼も各ＢＥＰに割当てられ、割当てはロード共有アルゴリズムによって判断することができる。
図７は、ＢＥＰおよびＦＥＰ内の異なるプロトコル層を示す。この例では２つのタイプのＢＥＰ、すなわちトランザクションサーバ71およびアドバンストトランザクションサーバ73を使用している。アドバンストトランザクションサーバはサービス論理730を含み、サービス論理730はアドバンストサービスの特徴を構成し、トランザクションサーバ71のサービス層710にインターフェイスしている。トランザクションサーバおよびアドバンストトランザクションサーバの両方のサービス層はＡＣＳに対してインターフェイスＩ／Ｆ712、731を含んでいる。その代りに、ＡＣＳインターフェイスは、トランザクションサーバのＩＮＡＰ（インテリジェントネットワークアプリケーションパート）層711に配置することができる。ＴＣＡＰ層713、720はＢＥＰ71およびＦＥＰ72間で分割される。ＦＥＰ72は、ＳＣＣＰシグナリング層721およびＭＴＰトランスポート層722も含む。
図１に示したように、呼応答センタ６はＤＬＥ5に接続されている。この例では、呼応答センタは１つの電話番号、例えば０８００４００４９６、および５０の同時呼を取扱う容量をもつ。図を簡単にするために、１つの呼応答センタのみを示したが、実際にはＳＣＰは、ＤＭＳＵおよびＤＬＥを介して多くのこのような呼応答センタに接続できる。例えば、イギリスのＰＳＴＮでは１つのＳＣＰ／ＡＣＳが数百の応答センタを支援すると認識している。ＡＣＳでは、呼応答センタが積滞するときのみ、所定の呼応答センタへの呼制御プロセスの発生が生ずる。各呼を監視するときに発生するであろうシグナリングオーバーヘッドを回避するために、ＡＣＳは呼を間欠的にサンプリングする。例えば、ＡＣＳは10秒ごとに１つの呼を選択してもよい。ＡＣＳは、選択された呼に対して送信元のＳＳＰにおいて検出点を設定し、検出点は応答センタの電話番号、０８００４００４９６への呼に対してＤＬＥからビジー信号が戻されるときにトリガされる。トリガに応答して、呼制御プロセスのインスタンスがその電話番号に対して生成される。以下でさらに詳しく記載するように、この電話番号に対する進行中の呼の合計数を記録するカウンタが作動する。センタの全容量が推定され、この値が記憶される。この推定値は、呼制御プロセスが呼が認められるか否かを制御する前に、最初のトレーニング段階で導き出すことができる。トレーング段階が完了した後で、例えばＤＬＥ４に接続された加入者から、応答センタへ次の呼が行われるとき、ＳＣＰのサービス制御機能から応答センタサーバへ処理要求が送られる。応答センタサーバは、サーバ容量値とカウンタ値とを比較する。進行中の呼の合計カウント（新しい呼を除く）が応答センタの容量値よりも少ないときは、呼が認められ、カウンタは進行中の付加的な呼を反映するためにインクリメントされる。これは応答センタサーバによってサービス制御機能へシグナリング（信号送り）される。次に呼は従来のやり方で送られる。同時に、応答センタは次の終末イベント、すなわちビジー、ＲＴＮＲ（呼出し音を発するが応答がないこと）、放棄、応答、接続断、ルート設定失敗に対する検出点を設定する。これらの終末イベントの何れかを行うとき、これはＳＣＦ／ＡＣＳインターフェイスを介してシグナリングされ、カウンタは１だけデクレメントとされる。別の呼を受けるときはいつでも、これらの段階が繰返され、呼が認められるときはカウンタは再びインクリメントされる。進行中の呼数が応答センタの容量値に対応するまで、このプロセスはさらに反復される。次に別の呼を受取ると、進行中の呼数が容量よりも少ないという状態が満たされなくなる。この場合、サーバはＳＣＰに送信元交換局へ呼の解放メッセージ(ReleaseCall message)を送らせる。このメッセージは呼を完了するのに失敗した理由、すなわち使用中(user busy)を含んでもよい。ビジー信号が宛先のＤＬＥから戻される従来のネットワークの機能とは対照的に、呼は送信元のＳＳＰおよびＳＣＰを超えて先へ進まない。呼は宛先交換局のトラヒックの増加の原因とはならず、したがって宛先交換局のインフラストラクチャはこれらの環境から送られる呼を支援するように設計する必要はない。
この呼が制御されている宛先で認められない場合は、ＳＣＰがこの呼を転送できないならば、ＡＣＳはＳＣＰに命令して呼解放を送る。これは、ＳＣＰが、呼に対する“割込み(interrupting)”モードで検出点を設定しなかった場合である。その代りに、割込み検出点が設定されたときは、ＡＣＳはＳＣＰに“実際の”ビジー表示をネットワークから受取ったように振舞わせる。検出点を“通知および継続(notify and continue)”モードに設定したときは、ＡＣＳは、適切なタイプの実際のイベント報告、例えばビジーを受取ったことをＳＣＰへシグナリングするようにされている。
図２は、ＡＣＳでの制御プロセスのある時間についての状態機械(state machine)を表している。待機タイムアウトおよびアイドル状態では、ＡＣＳは能動的に呼レベルを制御し、呼を認めることを許可する要求を受取り、認可の結果を報告する。これらの状態に入る前に、トレーニング状態でＡＣＳプロセスが開始され、これは応答センタの容量の推定値を設定するのに使用される。トレーニング状態では、ＡＣＳは割当てられた宛先への呼を制限しないが、ＳＣＰに命令してその宛先への全ての呼に対して送信元ＳＳＰにおける検出点を設定する。ＡＣＳは監視している進行中の呼の記録を維持する。この状態では、可能な限り迅速に応答センタの容量を推定して、ＡＣＳを追跡モードに移行させ、能動的に呼の認可を制御することを目的としている。応答容量を可能な限り迅速に推定する、すなわち呼保持時間と比較可能かまたは更に短い時間で推定するために、呼保持時間で推定が行われる。この応答時間の迅速な推定は次のように得られる。すなわち電話番号に対して行われた呼の平均保持時間は次の関係から導き出される：

なお、

は推定平均保持時間であり、Ｔ_Cは監視される既に終わった呼を終了するのにかかった時間であり、Ｎ_Cはこの監視される既に終わった呼の回数であり、Ｔ_Iは監視されるまだ終わっていない呼の現在までに経過した時間であり、Ｎ_Iは監視されるまだ終わっていない呼の回数である。上述の序説に記載したように、この関係は負の指数関数的分布をもつ呼に対して真である。これは国内のネットワーク全体の呼の分布にほぼ当てはまる。しかしながらときには、この母集団のサブセットは異なる分布をもってもよい。例えば電話投票またはクレジットカードで寄付を行うための電話呼において、保持時間を予め決めるかまたはおおむね固定することができる。このタイプの決定論的分布では、好ましくは次の関係を使用して、平均保持時間を決定する：

ＡＣＳは、発信と着信が分かっている呼の呼保持時間の合計と、これらの呼のカウントとを維持する。ＡＣＳはさらに呼数、および開始され、しかも依然として保持中の呼についての合計呼保持時間を計算できる。応答センタの容量の十分に正確な推定値を生成する基準が設定され、例えば、少なくとも２０の呼が開始したことが分かっており、開始した呼の中で少なくとも半分が完了しているようなことを要件としてよい。いったん基準が満たされると、次に記述する方法により集められたデータから応答センタの容量推定値を計算でき、ＡＣＳは追跡モード（状態待機タイムアウト(AwaitTimeout)およびアイドル(Idle)）を入力できる。
オーバーロードした応答センタへ最初に割当てられるとき、応答センタサーバは宛先に認められた全ての呼に対してＩＮ検出点を送信元のＳＳＰに設定する。各呼について、検出点が呼設定段階（応答、放棄、ルート選択失敗、呼出し音に応答なし）の全ての可能な結果およびディスコネクト（接続を解く）に対して設定される。したがって応答センタサーバは、応答センタサーバを応答センタに割当てた後に認められた宛先への呼の結果についての完全な知識をもつことになる。しかしながら、応答センタサーバは、割当てられる前の送信元の個々の呼に関する知識をもたないことになる。しかしながら１つの（サンプリングされた）呼がビジーイベント報告を戻しているので、応答センタサーバが応答センタに割当てられたときに、その応答センタは完全に塞がっていると推論できる。応答センタサーバを応答センタに時間ｔ＝０で割当て、応答センタが容量Ｎラインをもたせることにする。分かりやすくするために、割当てられるまでの期間において呼到達レートがでほぼ一定であると仮定する（これは、応答センタがちょうどオーバーロードしてしまうために完全に真にはならないが、呼到達レートを変化させる立上がり時間が呼保持時間よりも長いならばほぼ真である）。したがって負の指数関数の呼保持時間において、ｔ＝０になる前に開始し、依然として保持中の呼数は次の通りである：
Ｎ_H(t)＝Ｎexp(−t／Ｔ_H)
割当て後に送られる進行中の呼、すなわち応答センタサーバが検出点を設定した呼、したがって応答センタに分かっている呼数の期待値は次の通りである：
Ｎ_K(t)＝Ｎ−Ｎ_H＝Ｎ（１−exp（−t／Ｔ_H)
および、応答センタの容量の評価は次の通りである：

決定論的（一定の）呼保持時間に対して、ｔ＝０になる前に開始し、依然として保持中の呼数は次の通りである：
Ｎ_H(t)＝（１−（t／Ｔ_H）），t＜Ｔ_H
既知の呼数は：
Ｎ_K(t)＝Ｎ−Ｎ_H＝Ｎt/Ｔ_H，ｔ＝Ｔ_H
決定論的呼保持時間に対する応答センタの容量推定値は次の通りである：

容量値がトレーニングプロセスによって設定されたとき、次に発生する容量変更に対して該値を適合させることが依然として必要である。例えば応答センタにおいて多数の呼応答エージェントが増加または減少するときに、容量をステップ式に変更してもよい。状態機械は、次のようにこのような変更を追跡するように機能する。標準動作では、進行中の呼数が最大容量よりも少ないとき、システムはアイドル状態である。アイドル状態でビジーを受信するときは、容量値は高過ぎることを示しており、したがってデクレメントされる。進行中の呼数が現在の容量値と等しい状態ででアイドル(Idle)状態から待機タイムアウト(AwaitTimeout)状態への遷移が予測される。この遷移が行われるとき、タイマは、例えば10秒間動作するようにセットされる。この数からはビジー(busy)信号を受信せずにこの期間が経過するときは、現在の容量値は正しいかまたは低すぎると断定される。したがってこの値はインクリメントされる。同時に、システムはアイドル状態に戻る。その代りに、システムが待機タイムアウト状態であるとき、ビジー信号を受取ると、アイドル状態に遷移し、容量値はデクレメントする。
応答センタが全容量で動作しているが、容量が一定のときはＡＣＳは、タイマが費消されるたびごとに、１つの無効呼を生成する。この無効呼は、容量が増加していないことを保証するのに必要であり、言い換えると容量変更を追跡できるようにするために必要である。したがってタイマの継続時間は、十分に低いレートの認められる無効呼と応答センタの容量変更のＡＣＳによる追跡に十分な応答性とを達成することの妥協である。
選択的に、容量をインクレメントすると同時にタイムアウト遷移をするときはいつでも、関連するインクリメントの値がそれ自身を増加してよい。例えば、最初のこのような遷移では、容量値を１だけインクリメントすることができ、インクリメントの値それ自身は１だけインクリメントされ、したがって次にこのような遷移をするときは、容量値は２だけインクリメントされる。ビジー信号を次に受信するとき、インクリメントする値は１にリセットされる。他の方法も可能であり―１例として効果的に適用されるたびごとに、インクリメントは２倍にされる。この別の方式では、大きな変更を一層迅速に追跡でき、呼応答エージェント数を数分間に何十または何百も変えることが期待されるときに使用できる。
容量推定値を２以上インクリメントした後でビジーを受取るとき、ＡＣＳは、例えば：（ａ）現在の容量の推定値を現在進行中の呼と置換し；（ｂ）インクリメントを１にリセットすることができる。（容量推定値が真の容量を超えたときに認められる顕著な呼のために）受取った別のビジーイベントが容量推定値をさらにデクレメントする。
上述の第１の方法では、ＡＣＳはａ＋ｂｔ＋ｃｔ²によって記述される呼制限についての放物線適合を達成する。なお、ｔは適合するのにかかった時間であり、ａ、ｂ、およびｃは定数である。これによりＡＣＳは、例えば、特別なラインの大きいブロックを応答センタに付加して、期待されるトラヒックサージ（急増）を取扱うことができる。
電話番号の呼レベルが、応答センタの容量よりも相当に低いときにＡＣＳは割当てを解かれる。このために、進行中の呼が推定容量と等しいときはいつでも、第２の（割当て解除）タイマがスタートするかまたは再スタートする。割当て解除タイマの継続時間は、既に記載した１０秒のタイマよりも長く―おそらく数分間の継続期間をもつことができる。継続期間が切れるとき、センタはタイマの継続期間に対する容量ではなくなり、ＡＣＳが割当て解除できる。
割当て解除に対する代りの好ましいアプローチでは、呼がクリアし、進行中の呼数が、現在進行中の呼（ＣＩＰ）の最大呼数（ＭＣＩＰ）からＭＣＩＰ−１に等しい値へ下がるときはいつでも割当て解除タイマがスタートまたは再スタートする。このアプローチが好ましいとされ、その理由は監視されている応答センタが依然として全容量で動作する間は、割当て解除が発生しないことを保証するし、もし呼保持時間が割当て解除タイマの継続時間よりも長いかまたはほぼ等しいときには、上述の第１の方法と一緒に発生できるからである。
ここでＡＣＳの構成をさらに詳しく記載することにする。
この例では、ＡＣＳはオーバーロード制御サーバ（ＯＣＳ）の一部を形成し、単一のＯＣＳはネットワーク内の各ＮＩＰ内に含まれる。他の構成も可能である：例えば、ＮＩＰが１以上のＯＣＳを含むことができるか、または単一のＯＣＳが幾つかのＮＩＰにサービスすることができる。しかしながら、ＮＩＰに対するアウトバウンド制御を局所化する単一のＯＣＳの使用が好ましい。ＳＣＰ内の独立トランザクションサーバが独立した呼制御方式を維持する構成とは対照的に、単一のモニタおよび制御プロセスを使用することによって、イベント到達の総レートはさらに高くなり、したがって一層迅速な制御応答を提供できる。この構成によりさらに、呼は応答センタへ一層円滑に到達し、他のＮＩＰプロセスにおいてオーバーロード呼処理の衝撃を低減し、他のサイトにおいてオーバーロード制御プロセスとの通信を容易にし、呼処理またはＴＣＡＰサーバへの簡単なインターフェイスを提供することを可能にする。
ＯＣＳ／ＡＣＳはＵＮＩＸマイクロプロセッサのクラスタ上で構成することができる。適切なシステムは、Digital Equipment CorporationからＴｒｕｃｌｕｓｔｅｒ^TMとして販売されている。これは“メモリチャンネル”または“反射メモリ(reflective memory)”として知られている方式を使用して、異なるプロセッサ間で迅速な通信を行う。プロセッサ間のメモリ―対―メモリ接続は、非常に広い帯域幅、短い待ち時間、および少ないシグナリングオーバーヘッドを提供するので、単一のオーバーヘッド制御プラットフォーム上で実時間で多数のオーバーロード制御オブジェクトを支援することができる。
ＯＣＳのプロセス間通信と同様に、異なるサイトのＯＣＳ間でシグナリングを使用する。図３に示したように、これはＦＤＤＩＷＡＮ33上のＴＣＰ／ＩＰプロトコルを使用して実行される。任意のサイトにおける任意のＯＣＳは任意の応答センタのＡＣＳになることができる。図３は、オーバーロード制御サーバ（ＯＣＳ）31ａ乃至ｃをサービス制御機能32ａ乃至ｃと関係付けて示している。サービス制御機能は、ＩＮＡＰ（インテリジェントネットワークアプリケーションパート）シグナリングチャンネルを介して各サービス制御スイッチングポイント（ＳＳＰ）34と通信する。ＡＣＳがＯＣＳ、例えば図３において参照符号31ａのＯＣＳにおいて生成されるとき、該ＯＣＳはＦＤＤＩＷＡＮ33を介して他のＯＣＳへシグナリングし、応答センタを制御する。３つのＯＣＳは、イギリスの国内ネットワークで一般的な総合レベルでテレマーケティングトラヒックを取扱う、ＡＣＳと接続されたＯＣＳプラットフォーム間の通信に必要な帯域幅は約２２０kbit／sであることがわかる。
ＡＣＳ、およびＯＣＳの他の機能は、呼処理へのインターフェイスを備えている。このインターフェイスは、オブジェクト試行設計およびプログラミング環境のコンテキストにおいて２つの方法、すなわちadmitCallqueryおよびeventReportとして構成することができる。これらの方法は次のように定義される：
obc_admitCallQuery(called,destinationId):goAndReports
この方法は呼を宛先へ送る前にサービスによって呼出される。アウトバウンド制御は、呼を認めるべきか否かを示すブール演算子を戻す。
呼を認めるべきときは、アウトバウンド制御はさらに、何れの呼に対して何れのイベント報告を要求すべきかを示す。サービスはイベント報告要求を次のように取扱う。すなわち全てのオーバーロード制御要求報告は通知及び継続報告として要求されるが、例えばビジー呼プラン（計画）での迂回機能の一部として、所定の報告を割込み報告として要求しなければならないとサービスが判断していないことを条件とする。
アウトバウンド制御が呼は認められないと判断すると、理由、例えばビジー(Busy)、ルート選択失敗(Route_Select_Failure)、またはおそらくは応答なし(NoAnswer)を戻す。この理由を受取ったサービスは、イベント報告で同じ理由を応答センタそれ自身から戻されたかのように振舞う。サービスは、例えばビジー状態のの迂回連鎖(divert-on-busy-chain)において次の終端ノードを試みるか、または呼解放(ReleseCall)を送信元のＳＳＰへ戻すことができる。
イベント報告はアウトバウンド制御によって要求され、それに続いて、サービスは以下の第２の方法を呼出すべきであるとする呼への該イベント報告を受取るとき：
obc_eventReport(called,event):null
これは、特定の呼に対してイベントが発生していることをアウトバウンド呼に示している。
これらのインターフェイスは、低抽出比サンプリング、応答センタがビジーになることの探索、自動呼制限（ＡＣＲ）のアウトバウンド制御、およびＡＣＳのダイナミック割当てを可能にする。図７に関係付けて記載したように、ＡＣＲインターフェイスはトランザクションサーバのサービス層の一部とＳＣＰ内のアドバンスト（最新の）トランザクションサーバとを形成する。種々の場合のサービス論理はＡＣＲインターフェイスをアドレスし、次にＡＣＲインターフェイスはＡＣＳへ照会及びイベント報告を伝える。ＡＣＳはこのサイトのローカルなオーバーロード制御サーバ（ＯＣＳ）に配置されるか、または異なるサイトに配置されて、ローカルＯＣＳを、例えばＴＣＰ／ＩＰ接続でインターフェイスを遠隔のサイトへ拡張してもよい。
図８は、ＡＣＳの主要な機能素子を示す。カウンタ制御装置81はカウンタ82およびネットワークシグナリングインターフェイス83に接続されている。呼制御装置84はコンパレータ86を含み、カウンタ82の値とメモリ85に記録された呼容量値とを比較する。呼制御装置は呼信号発生器87を使用して、比較の結果に依存してネットワークインターフェイスを介して制御信号を戻す。これらの素子の一部または全てに専用ハードウエアを使用してもよいが、より一般的には該素子はプログラムされたマイクロプロセッサおよび関係付けられたＲＡＭ（ランダムアクセスメモリ）によって実現される。ＡＣＳを構成する適切なソフトウエアの例は下記の付録に記載した。
この例でＯＣＳは、ＡＣＳに加えて多数の他のリソースを使用して、トラヒックレベルを監視し、制御するようにされている。とくに、ＯＣＳはアウトバウンドトラヒックについて自動呼制限（ＡＣＲ）も使用する。上述で引用した国際特許出願において、ＡＣＲは応答センタに認められた呼レートを、応答センタの応答レート能力よりもむしろ高い値に制限する。これを実行するために応答センタの応答レート能力を知る必要はない。すなわちテレトラヒックの結果は、１０秒以上の呼保持時間に対しては、１．８呼ｓ^-1の平均応答容量を超える到達が、ライン数がいくつでも９５％の占有率を保証するのに十分としている。応答センタに認められた呼について、ビジー、応答なし、およびルート選択失敗のイベントに対するトリガするように設定することによって、容量を超えて呼が到達するレートが検出される。（実際には、さらにトリガを応答及び放棄に設定して呼のコンテキスト情報の消去（クリーンアップ）を助けるようにしてもよいが、タイムアウトは常に結果的に古いコンテキストを消去することを保証しなければならない）。モニタは応答センタに認められた呼失敗レートを検出し、このレートを（例えば、１．８の失敗ｓ^-1という）高占有率を保証するのに十分な目標レートと比較する。調節可能なレート制御素子は応答センタに認められる呼のレートを判断する。失敗のレートが目標レートと異なるとき、負のフィードバック機構は認められる呼レートに制御素子を調節する。認められるレートの制御は、呼失敗レートを目標の呼失敗レートの近くに維持するレベルに認められる呼レートを設定する。
ＡＣＲモニタは、各混雑イベントによってインクリメントされる目標混雑イベントレートに等しい固定リークレートをもつリークのあるバケットとして機能する。ＡＣＲ制御は、モニタからフィードバックによって制御される可変リークレートの別のリークのあるバケットである：モニタが空である（トラヒックが不十分）のとき増加し、モニタが充填されている（トラヒックが超過している）とき、低減する。制御バケットのリークレートが、応答センタに対して呼を認める平均レートを固定する。制御バケットが充填されていない（一杯でない）とき、呼は応答センタに認められ、また呼が認められるとき、制御バケットがインクリメントされる。呼が認められないときは、制御バケットはインクリメントされない。
ＡＣＲモニタはダイナミックに割当てられたリソースであり、リソースは応答センタで積滞イベントに遭遇したときに割当てられる。したがってオーバーロードでＡＣＲが起動されなければならないときに全ての応答センタへ送られることになる少なくとも１つの呼サンプルについてトリガが設定されなければならない。オーバーロードを検出してモニタを割当てることが目的であるので、抽出比は小さく、例えば１０秒に１回の呼であってもよい。モニタがいったん割当てられてしまうと、呼の最も大きな割合がサンプルされ（例えば、２秒に１回の呼または３秒に１回の呼）、制御フィードバックループからの十分に迅速な応答が可能になる。
ＡＣＲ制御はダイナミックに割当てられたリソースであり、ＡＣＲモニタが最初に開始閾値を越したときに、最初のリークレートが割当てられ、供給される。割当てられた制御のリークレートは、モニタから負のフィードバック制御のもとで調節される。オーバーロードが低減すると、リークレートが最大値に到達して、リソースが割当て解除されるまで、一層高い制御レートに適合するように、制御が続けられる。
ＮＩＰについてのＡＣＲの多くの場合（インスタンス）には、応答センタ容量を超えている認められたトラヒックについての超過分に対する目標レート（例えば、１．８ｓ^-1）は、各インスタンスに全体的に均等に区分される。
実際には、ＡＣＲおよびＡＣＳは動作上相補的であることが見付けられた。応答センタが非常に高いレートで無効呼を受取っているとき、レートの著しい低減がＡＣＲだけで行われる。応答センタが、例えば１０秒ごとに１未満の無効呼を受取るときには、ＡＣＲは低減せず、そのときはＡＣＳは比較的に僅かに低減する。しかしながらこれらの両極端の間には範囲があり、そこではＡＣＲそれだけを使用することと比較してＡＣＳは大きな低減を与える。選択的に、ＯＣＳが無効呼のレートを監視して、このレートがこの最適範囲内にあるときのみＡＣＳを呼出す。
ＤＡＣＳ（ダイナミックＡＣＳ）およびＡＣＲを一緒に使用するときは、ＡＣＲが最初に照会される。ＡＣＲが呼を許可するとすると、次にＤＡＣＳが照会される。ＡＣＲとＤＡＣＳの両方が呼を許可するとき、呼は認められる。ＡＣＲがＤＡＣＳよりも少ないコンピューティングおよび通信リソースを使用して、ＤＡＣＳのインスタンスの数は制限され、一方でＡＣＲは常に使用可能であることを保証するようにする。次に、ＤＡＣＳを割当てに使用できないとき、ＡＣＲは制御されたままになる。
ＯＣＳは状態応用(Condition Based)ルーティング（ＣＢＲ）とコンパチブルに設計されている。ＯＣＳとＣＢＲノードとの効果的な相互動作を保証するように、ＯＣＳ／ＡＣＳはプログラムされ、通知検出点が設定されるときはいつでも、呼の通常の処理においてＣＢＲノードによって期待されるトリガを模倣する。割込み検出点が設定されると、呼をリリースする代りに、ＯＣＳ／ＡＣＳは適切なイベント報告をＣＢＲノードへ戻して、例えば異なる電話番号へ迂回することによって、ＣＢＲノードによる呼の別の処理の可能性を残しておく。したがってＯＣＳ／ＡＣＳの振舞いは、次のサービスによって設定された検出点（ＤＰ）の性質にしたがって変化する：
１．サービスは割込みＤＰを設定せず、ＡＣＳは呼を認める。ＳＣＰはサービスによって設定される全てのＤＰを記録し、通知および継続（Ｎ＆Ｃ）モードで呼の結果に対して全てのＤＰを用意する。ＳＣＰは、サービスによって設定されたＤＰへサービスイベント報告を送る。
２．サービスは割込みＤＰを設定せず、ＡＣＳは呼を拒絶する。ＳＣＰはリリース呼をＳＳＰへ送る。サービスがビジーＤＰを設定するとき、ビジーイベント報告がサービスへ戻される。
３．サービスは少なくとも１つの割込みＤＰを設定し、ＡＣＳは呼を認める。記録ＤＰはサービスによって設定される。ＤＰが何れのモードにも設定されないときは、Ｎ＆Ｃモードに設定される。サービスによって設定されたＤＰに対してサービスイベント報告を送る。
４．サービスは少なくとも１つの割込みＤＰを設定し、ＡＣＳは呼を拒絶する。ビジーのイベント報告をサービスへ戻す。呼解放をＳＳＰへ送るなとする。
図４および５は、上述のシステムにおける呼の流れを示している。図４は、単一の宛先AnsCtrに対する単一のサービスの２つのインスタンス（サービス１およびサービス２）と、最初に割当てられていない応答センタサーバのインスタンス”ACServer”とを示している。サービス１およびサービス２は異なるコンピュータ上で走行してもよい。サービス１およびサービス２の両方は呼の成功をサンプリングする。この呼は呼の僅かな部分（例えば、１０回に１回）で呼の失敗（ビジー、応答なし、ルート選択失敗）についての検出点を設定することによって宛先へ送られる。図面の上部ではサービス１から１つのこのようにサンプルリングされた呼がビジーに出会う。サービス１はローカルのＯＣＳに失敗を知らせ、ＯＣＳはACServerを宛先に割当てる。ACServerは全サービス例を同報通信の“monitor（モニタ）dest”メッセージを介して、宛先へ割当てられたことを知らせる。トレーニング（学習）段階では、サービスのインスタンスが宛先への呼を認める前にACServerから明示された認証を得る必要がなく、この場合構成はこの事実を利用して、トレーニング段階中にACServerに要求することを避ける。例えばサービスのインスタンスは、ＩＮＡＰ接続メッセージをＩＮＡＰ要求報告メッセージと一緒に送信元のＳＳＰへ送って、呼の結果に対して検出点を設定する。次にサービスのインスタンスはACServerに呼が始まったことを報告する。１、２、および３と表示した３つの呼を示した。これらの呼の会話段階が終了するとき、送信元のＳＳＰはサービスへのディスコネクト（接続解除）のためのイベント報告を送り、それをACServerへ中継する。この段階中に、ACServerは各認められた呼の呼記録を構築し、その中に呼開始時間を記憶している。会話段階なしに呼が失敗するとき、呼記録は取り除かれるが、呼が応答するとき、ディスコネクトが受領されるまでその記録は保持される。この点で、保持時間は完了呼の保持時間の和に付加され、完了した呼数のカウントはインクリメントされる。したがって数のカウントはインクリメントされる。したがってACServerは、呼が宛先へ割当てられた後に始まった呼の合計保持時間を得ることができ、ここで終了する。進行中の呼に関する保持された呼記録について加算することによって、ACServerがトレーニングのための要求に応じて、現在保持中の呼数、およびこれまでの総継続時間を知ることができる。
図５は、追跡モードにおけるＤＡＣＳの動作を示す。１、２、および３と表示された３つの呼は方向付けられ、各場合にこれらの呼を処理するサービスのインスタンスがACServerの要求を行って、呼を認めるべきか否かを判断する。各場合に呼は認められるが、呼３は現在進行中の呼が現在進行中の最大呼数に到達するようにする。追跡タイマが作動し、ACServerはAwaitTimeout状態に入る。この状態で、別の最初の呼はサービスのインスタンス、サービス２によって処理され、ACServerへ要求を行う。現在進行中の呼が現在進行中の最大呼に等しいとき、要求は拒絶される（“ビジー”メッセージはＡＣＳerverからサービス２へ“ビジー”メッセージを送る）。次のイベントで、呼２は、呼１によって進行中の呼をディスコネクトし、低減し、次に呼４を認めることができる。これに続いて、追跡タイマが終了し、ACServerに最大呼数をインクリメントさせる。したがって呼５を開始するためのサービス２からの次の要求が承諾されるが、実際にはAnsCtrの容量の最初の（インクリメント前の）評価が正しく、したがって呼５はＳＳＰから“ビジー”イベント報告を戻す。これに応答して、ACServerは進行中最大呼数をデクレメントして、正しい値に戻す。
下記の付録は、ＡＣＳの試作品構成に対するＣソースコードのリストを示す。ソースコードは、番号変換サービスの動作におけるイベントに基づいたシミュレーションを実行するプログラムの一部である。サービスは、インテリジェントネットワークを使用して構成される。ここに含まれるＣソースコードは、宛先に対するトラヒックのＡＣＲ応用制御の構成要素；および宛先に対するトラヒックのＤＡＣＳ(ダイナミックＡＣＳ)の構成要素、サービスの動作をシミュレーションできるシミュレーションプログラムの構成要素を含む。ここに示したコードはさらに、宛先それ自身をモデル化する。この部分以外のプログラムの構成要素は、イベントドライブシミュレーションの時間順序のイベントを管理し；呼の到達をモデル化し；シミュレーションを制御するパラメータを含む入力データファイルを読取り；シミュレーションの結果をプリントし表示することができる。
個々の呼はデータ項目CallIdによって識別されて、これが機能サービス()によって割当てられる（下記参照）。呼は、実際のＩＮ構成におけるＴＣＡＰトランザクション識別子をモデル化したときに観察することができる。
コード内の幾つか点では：
fprintf(stderr,“PANIC......”)
に類似したライン（行）が生成される。これらのラインは、プログラムが内部データの不一致を検出したときに実行され、保護プログラミングとしてのみ存在する。これらは試作品の通常の動作で実行される。
次の記述は、それらがプログラム部分に表れる順序でＣ機能を取扱う。
最初の２つの機能、すなわちfreeSvcCallRecord()およびremoveACRecord()はハウスキーピング機能である。これらは、サービスおよび宛先をモデル化する機能によって維持される呼記録を除去することができる。
このコード内の機能answeringCentre()は、宛先へ通じているライン数、宛先で呼に応答できるエージェント（人々）数、呼保持時間、および現在全てのラインが使用中であるときに、宛先に対して認められた呼がビジーになるように個々の進行中の呼イベントをモデル化する。さもなければエージェントが使用可能であるとき、呼に直ぐに応答し、CALL_COMPLETESイベントが生成されて、呼のディスコネクトをモデル化する。サービスのパラメータによって与えられる中間値を使用して負の指数を分配した呼保持時間の後で、CALL_COMPLETESイベントが起こる。何れのエージェントも使用できないとき、呼はRENR＿TIMEによって設定される期間の間呼をリンギングできる。RENR＿TIMEの終了前にエージェントが使用可能となると、呼が応答されるが、そうでないときは呼が失敗する。呼の進行中にイベントが発生すると、宛先はサービスデータのフラグ要素を検査して、イベントをサービスに報告すべきか否かを判断する。この動作は、ＩＮＡＰメッセージ要求報告ＢＣＳＭイベントをモデル化し、これを実際の構成ではソースＳＳＰへ送る。特定のイベントの１つが行われるとき、宛先モデルは、状態変更の報告を生成し、それがシミュレーションのイベントリストへロードされて、シミュレーションの遅延の後でサービス論理へ送るようにする。この遅延はシグナリングネットワークおよび実際のＩＮの処理遅延特性をシミュレートする。機能answeringCentre()は、特定のイベントが行われるときに呼ばれる。イベントはTS＿COMPLETES、新しい呼を開始する試行、または成功した呼の会話段階の終了時に発生するCALL＿COMPLETES;またはエージェントが使用不能で特定の時間制限内で呼に応答できないために、呼が失敗したときに行われるRTNR＿EVENTの１つであってもよい。answeringCentre()はcallsBusy、すなわち進行中の会話段階中にあり、ラインとエージェントの両方が使用不能である呼のカウント；呼のカウント、すなわち会話段階進行中または呼出し中(Ringing)状態の何れかの呼のカウントを維持する。calls-callsBusyの差は、呼出し中状態にあり、エージェントではなくラインを占めている呼の数である。これらのカウントは、呼が開始されるか、またはイベントによって呼がその状態を変更するときはいつでも適当に操作される。
イベントTS＿COMPLETESを受取ると、全てのラインがビジーであり、新しい呼を開始する試みをしないとき、answeringCentre()は最初に検査する。イエスのとき、サービスはビジー状態のイベント報告を要求したか否かを検査し、イエスのとき、サービスは報告を送る。全てのラインがビジーのとき、answeringCentre()は呼に対してそれ自身の呼記録を生成しない。ラインが使用可能のとき、answeringCentre()は最初に呼に対してそれ自身の記録を生成し、エージェントが使用可能であるか否かを検査する。イエスのとき、answeringCentre()は直ぐに呼に応答し、応答に対するイベント報告が要求されたときサービスを知らせる。answeringCentre()が呼の完了に対してシミュレーションイベントを設定する。さもなければ、answeringCentre()は、リングのタイムアウトに対してシミュレーションタイマを設定することによって呼出し中呼をシミュレートする。
イベントRTNR＿EVENTを受取ると、answeringCentre()は、呼の記録を見付ける。シミュレーションは、呼の進行がイベントを無関係にする場合に時間順序のイベントリストからRTNR＿EVENTを明らかに取除かないので、結果的に呼が応答されずに、（おそらくは）後でディスコネクトされたとしても、直ぐに応答しなかった呼に対して常にRTNR＿EVENTを受取ることになる。したがって、呼の記録が見つからないとき、または見付かった記録が呼が状態Answered（応答完了）であることが示されるとき、RTNR＿EVENTは無視される。さもなければ、記録は見付けられ、呼状態は依然としてRinging（呼出し中）であり、answeringCentre()は、サービスがリングのタイムアウトに対するイベント報告を要求したか否かを検査し、イエスのときは、報告を送る。次にansweringCentre()は、失敗した呼に対してそれ自身の呼を取除く。
イベントCALL＿COMPLETESを受取ると、answeringCentre()は最初に、サービスが呼のディスコネクトに関するイベント報告を要求したか否か検査する。イエスのときは、answeringCentre()は報告を送る。answeringCentre()は完了した呼に関する呼記録を取除く。次にansweringCentre()は呼出し中状態の呼を検査する。呼出し中状態の呼があるときは、answeringCentre()は最も古い呼に対して、この新しい呼の完了イベントを設定する。応答イベントに関する報告が要求されたとき、answeringCentre()はサービスに知らせる。
機能obControl()は、宛先のオーバーロードを制御するＡＣＲ方式の制御素子の調節をモデル化する。機能obControl()は、関係付けられたモニタからオンセットイベント(E＿ONSET)、減少(abatement)(E＿ABATE)イベント、およびタイマ(ETB)イベントを受取る。オンセットイベントは、関係付けられた宛先でビジーまたは他の失敗イベントの新しいまたは更新されたサージを検出したことを示し、宛先に対してトラヒックが認められるレートを低減する制御の調節を導く。減少イベントは、失敗イベントの予め報告したサージがモニタの特徴レートより低いレートへ落ちたことを示し、宛先に対してトラヒックが認められるレートを高める制御の調節を導く。有効なタイマイベントはさらに、スタートが開始または減少イベントとして予め報告された状態が持続していることを示す。有効なタイマイベントは、適切な方向における制御を更に調節する。開始または減少イベントが行われるか、または有効なタイマイベントが処理されるときはいつでもタイマイベントが生成される。この構成では、それらが無関係になる（例えば、開始イベントの後に設定されたタイマイベントは、後続する減少イベントの後で完成するとき無視される）とき、タイマイベントは除去される。無関係のタイマイベントが無視されることを保証するために、この構成は各タイマイベントに識別子を与える。(所定の制御のインスタンスに対して)唯一の有効なタイマイベントは最新のタイマイベント（最近に割当てられた識別子に対応する）である。
第１の開始イベントは、制御の割当ておよび初期設定を行う。したがって、緩和またはタイマイベントは、制御レートを実効最大レートに調節し、制御の割当てを行う。
機能dripMonCon()およびallocateMonCon()は共に、ＡＣＲ方式のモニタ素子をモデル化する。ビジーイベントが宛先に対するサービスによって分かるとき、service()機能（下記参照）は割当てられたモニタを検査する。service()機能（下記参照）が割当てられたモニタを見付けるとき、dripMonCon()を呼んで、モニタをインクリメントする。dripMonCon()はE＿ONSETイベントをobControl()へ送ることができる。しかしながらサービスが宛先用の割当てられたモニタを見付けないとき、dripMonCon()はallocateMonCon()を呼び、allocateMonCon()はモニタを割当てて作動することを試行する。
“ＬＥＡＫ”イベントがシミュレーションの主要な時間順序のイベントリスト上で成熟するとき、モニタのリークがあるバケットが定期的にリークを行われ、したがってこのコード部分には示されていない。各モニタのインスタンスに対して最初の“ＬＥＡＫ”イベントを生成することだけが、このコード、すなわちallocateMonCon()内にある。
機能OBCadmitCall()は、宛先への呼を認めるか否かを判断する制御の使用をモデル化する。制御が割当てられないとき、モニタが割当てられても、られなくても、呼は認められる。制御が割当てられるとき、制御のリークのあるバケットのレベルは最初に制御の現在のリークレートを使用して低減され、次に呼を認めることができるか否かを調べるレベルテストを行う。呼を認めることができるとき、バケットレベルはインクリメントされる。機能のリターン値は呼が認められるか否かを示す。
機能ACSadmitCall()の主要なタスクは、特定の呼がＤＡＣＳによって認められるべきであるかを判断し、進行中の最大呼数の制限値の調節を制御することである。ＤＡＣＳがトレーニングモードであるか、またはＤＡＣＳが追跡モードであり、進行中の呼数が進行中の最大呼数に対する現在の制限値よりも少ないときに、呼は認められる。呼が認められるとき、ＤＡＣＳは、呼の状態を呼出し中と最初に記載する呼記録を生成する。ＤＡＣＳが追跡モードであるときは、ACSadmitCall()は、この進行中の呼を進行中の呼の最大値に対する現在の制限値にする。このとき現在の状態がアイドルであるときは、これはACSadmitCall()追跡および再割り当てタイマを設定する。ＤＡＣＳが追跡モードおよび状態AwaitingTimeoutのときは、ACSadmitCall()は、追跡タイマが終了したか否かを検査する。追跡タイマが終了したときは、進行中の呼の最大値の制限値をインクリメントし、状態をアイドルに設定する。ACSadmitCall()によって実行される別のタスク、すなわち再割り当てタイマが終了したか否かを検査すること、および再割り当てタイマが終了したときは、宛先からＤＡＣＳのインスタンスを再割り当てて、ＤＡＣＳの現在の呼記録によって使用されるメモリをクリアする。
ある宛先についてビジーイベントが検出されるとき、機能service()によって機能ACSallocate()が呼ばれる（下記参照）。ＤＡＣＳのインスタンスは宛先に割当てるのに使用できるときは、ＤＡＣＳは割当てられて始動され、ACSallocateはＤＡＣＳのインスタンスの識別子をservice()へ戻す。
ＤＡＣＳが割当てられている宛先への呼に対する応答イベントを受取ると、機能ACSanswer()が呼出される。この機能ACSanswer()は会話段階の進行中の呼の最大値を維持しているので、この呼への成功した応答は同時進行中の会話の現在数になり、この数は先の最大同時会話数よりも大きく、移動（ランニング）最大値は現在進行中の会話数に等しく設定される。ＤＡＣＳがトレーニングモードであるときは、試験されて、トレーニングを完了する状況が達成されたか否かを調べる。トレーニング状態が完了しているときは、ＤＡＣＳは、トレーニングモードから導き出される推定値に等しく設定されたmaxCallsInProgressで追跡モードに入る。次にＤＡＣＳは応答された呼の呼記録を見付け、それを応答完了に等しい状態に設定する。
ＤＡＣＳが割当てられている宛先への呼が終了イベントを受取るとき、機能ACSterminate()が呼出される。終了理由がビジー、RTNR（すなわち、応答なし）、またはディスコネクション（実際のＤＡＣＳは放棄された呼も取扱うが、これらはここではシミュレートされない）がある。ACSterminate()は、この呼の呼記録を見付ける。終了理由がビジーであると、進行中の呼のカウントはデクレメントされる。ＤＡＣＳがTracking（追跡）状態であると、進行中の呼の最大数に対する現在の制限値はデクレメントされ、調節のためのインクリメントは１にリセットされる。終了理由がＲＴＮＲであるとき、進行中の呼のカウントはデクレメントされる。終了理由がディスコネクションであるときは、現在進行中の呼および現在の会話の両方のカウントがデクレメントされる。完了呼の保持時間の移動（ランニング）の和は（トレーニングで使用するために）更新される。
機能service()はサービス論理をシミュレートする。シミュレートされるタスクは：呼の開始、呼を認めることを許可するOBCAdmitCall()およびACSadmitCall()への要求、および認められた呼に対する次のイベント報告の処理である。それはイベントパラメータTS＿COMPLETES、AC＿ANSWER、ACRTNR、AC＿COMPLETES、AC＿BUSY、またはAC＿ABANDONの何れかで呼ばれ、これらのパラメータはそれぞれ、新しい呼、応答された呼に対するイベント報告、応答されない呼（呼出し音に応答がない）に対するイベント報告、会話段階後の呼のディスコネクションに対するイベント報告、宛先がビジーであることに対するイベント報告、および放棄された呼に対するイベント報告（この簡単なシミュレーションでは実行されない）を示す。Service()へのこれらの呼は全て、シミュレーションの時間指定されたイベントリスト上のイベント結果として行われる。TS＿COMPLETEは先行するＮＩＰ機能で遅延をシミュレートする処理を行なう。AC＿ANSWER、AC＿RTNR、AC＿COMPLETES、AC＿BUSY、またはAC＿ABANDONの全ては宛先におけるイベント結果として生成されるが、遅延した後（シグナリングネットワーク全体における送信をシミュレートすること）でのみサービスに分かるようになる。
イベントTS＿COMPLETEでは、service()は、最初にcallIdを呼に割当て、次にダイヤルした電話番号に対応するサービスを探す。このプログラムはサービスが定められていないバックグラウンドトラヒックのシミュレーションを可能にするので、サービスは全ての呼に対して必ずしも発見されない。サービスが見付けられたときは、service()は最初にOBCadmitCall()から、次に（ＤＡＣＳが宛先に割当てられているときは）ACSadmitCall()から呼を認める許可を要求する。呼が認められ、イベント報告が生成されるときは、呼記録が生成され、呼の状態を追跡することを可能にするように作動する。最後に応答センタデータが（変換された）宛先の電話番号について見付けられ、また呼がansweringCentre()を呼出すことによって宛先へ送られる。カウンタはシミュレーションの結果、例えばserviceArray[i].acrejeがＤＡＣＳによって拒絶された呼をカウントし、serviceArray[i].rejeがＡＣＲによって拒絶された呼をカウントしたシミュレーションの結果を報告できるように維持される。
これは、最初にＡＣＲ（OBCadmitCall()によって実行される）を照会し、次にＤＡＣＳ（ACSadmitCall()によって実行される）を照会することによってＡＣＲおよびＤＡＣＳの統合を示す。ＡＣＲが呼を許可しないときは、直ぐに呼は終了する。しかしながらＡＣＲが呼を許可するときは、ＤＡＣＳへ次の照会を行う。両方の制御方式が呼を許可するときのみ、呼は認められる。したがってＤＡＣＳがトレーニングモードである間は、ＡＣＲが宛先へのトラヒックの急速に上昇する遷移を制限できる。ＤＡＣＳが追跡モードに入ると直ぐに、宛先で検出される積滞イベント（ビジーまたはRTNR）の数は、ＡＣＲのモニタレートよりも迅速に低くなる。したがってＡＣＲの制御により、それがトラヒックを制限しない認可レートに適合し、その結果ＤＡＣＳは呼の認可を制御したまま割当てをする。
ＤＡＣＳに認められる呼のＡＣＲによる制御は、呼の保持時間のみに依存する上述のＤＡＣＳトレーニング方式には影響を与えない。
イベントAC＿ANSWERのときは、service()は宛先電話番号に対する適切なサービスデータを見付け、応答した呼に対する報告カウントをインクリメントする。ＤＡＣＳが割当てられると、それを呼んで応答イベント（上述に記載されている）を処理する。
イベントAC＿RTNRのときは、service()は宛先電話番号に対してサービスデータを見付け、呼出し音応答なしに当たる呼の報告カウンタをインクリメントする。これは呼の終了イベントであるので、それは呼に関するそれ自身の記録を消去する。これは呼の失敗イベントであるので、それはＡＣＲ機能を呼出し、宛先用の既存のモニタをインクリメントするか、または宛先へモニタを割当てる（上述参照）。ＤＡＣＳのインスタンスが割当てられるとき、それはRTNRイベント（上述参照）に対してACSterminate()を呼出す。
イベントAC＿COMPLETEでは、service()は宛先電話番号の電話番号のサービスデータを見付ける。これは呼終了イベントであるので、呼に関するそれ自身の記録を除去する。ＤＡＣＳの場合が割当てられるとき、ディスコネクトイベント（上述に記載）に対してACSterminate()を呼出す。
イベントAC＿BUSYでは、service()は宛先電話番号についてのサービスデータを見付け、ビジーに当たる呼の報告カウントをインクリメントする。これは呼終了イベントであるので、呼に関するそれ自身の記録を除去する。これは呼の失敗イベントであるので、それはＡＣＲ機能を呼出して、宛先に既存のモニタをインクリメントするか、または宛先ごとに１つのモニタを割当てる（上述参照）。ＤＡＣＳのインスタンスが割当てられるとき、それはビジーイベントに対してACSterminate()を呼出す（上述参照）。

Claims

通信ネットワークを動作する方法であって、
多数の呼を受取る容量をもつ選択された宛先電話番号について、現在進行中の呼数のカウントを維持するステップと、
選択された宛先電話番号に対する呼解放が完了するとき、前記カウントを自動的に更新するステップと、
選択された宛先電話番号の最大容量値を記憶するステップと、
新しい呼が宛先電話番号に対して行われるとき、進行中の呼数のカウントと前記最大容量値とを比較して、呼解放を完了することによって最大容量値を超えるときにこの新しい呼を拒絶するステップと、
認められた呼に対するネットワークの応答に依存して、選択された宛先電話番号の最大容量値を記憶する前記ステップで記憶された最大容量値を後に変更するステップとを含み、
選択された宛先電話番号の最大容量値を記憶する前記ステップにおいて、前記値は、
一定の期間の間、該宛先電話番号への呼の解放を完了した呼の数Ｎ_Cを監視し、各呼の解放を完了するのにかかった時間Ｔ_Cを記録し、
前記一定期間中に記録されたＮ_CおよびＴ_Cの値から導き出される、該宛先電話番号への呼の平均保持時間から、該宛先番号の最大容量の推定値を計算することによって、
宛先電話番号の最大容量を推定し、推定された最大容量値を記憶するステップを実行することによって得られる推定値を含む、方法。
宛先電話番号において混雑が検出されるときのみ、請求項１の前記維持するステップ、前記更新するステップ、前記記憶するステップ、および前記拒絶するステップを開始する請求項１記載の方法。
複数の前記選択された宛先電話番号にサービスする単一のサーバにおいて、請求項１の前記維持するステップ、前記更新するステップ、前記記憶するステップ、および前記拒絶するステップが実行され、前記宛先電話番号において混雑が検出されるときに、前記維持するステップ、前記更新するステップ、前記記憶するステップ、および前記拒絶するステップを実行するリソースが、サーバにおいて各宛先電話番号へ割当てられる請求項２記載の方法。
宛先電話番号への呼の発生割合が、低い方の呼の発生割合よりも高く、高い方の呼の発生割合よりも低いときのみ、請求項１の前記維持するステップ、前記更新するステップ、前記記憶するステップ、および前記拒絶するステップが実行される請求項２または３記載の方法。
選択された宛先電話番号の最大容量値を記憶する前記ステップにおいて、
宛先の容量推定値が次の関係、

を使用して導き出され、なお、Ｔ_Hは平均保持時間であり、Ｔ_Cは監視されている呼の解放を完了するのにかかった時間であり、Ｎ_Cは該監視されている呼の解放を完了した呼の数であり、Ｔ_Iは監視されているまだ呼の解放が完了していない呼の現在までに経過した時間であり、Ｎ_Iは該監視されているまだ呼の解放が完了していない呼の数である請求項１乃至４の何れか１項記載の方法。
選択された宛先電話番号の最大容量値を記憶する前記ステップにおいて、
宛先の容量推定値が次の関係、

を使用して導き出され、なお、Ｔ_Hは平均保持時間であり、Ｔ_Cは監視されている呼の解放を完了するのにかかった時間であり、Ｎ_Cは該監視されている呼の解放を完了した呼の数である請求項１乃至４の何れか１項記載の方法。
記憶された最大容量値をインクリメントするステップと、
新しい呼を認めるステップと、
ビジー信号が戻されるときには記憶された最大容量値をデクレメントし、それ以外のときには記憶された最大容量値をインクリメントしたレベルに維持するステップとを含む請求項１乃至６の何れか１項記載の方法。
呼カウンタ値が記憶された最大容量値よりも小さいときに認められた呼に応答してビジー信号が受取られるときはいつでも、記憶された最大容量値を低減するステップを含む請求項１乃至７の何れか１項記載の方法。
端末リソースを接続するように構成された複数の相互接続されたノードを含む通信ネットワークで使用するのに適した呼制御サーバであって、前記呼制御サーバは、
選択された宛先電話番号に割当て可能であり、宛先電話番号への進行中の呼の合計数のカウントを維持するように構成された呼カウンタと、
選択された宛先電話番号への呼の解放が完了したときに生成されるネットワーク信号を受取るように構成されたネットワークシグナリングインターフェイスと、
ネットワークシグナリングインターフェイスおよび呼カウンタに接続され、ネットワークシグナリングインターフェイスで受取られる前記信号に応答して呼カウンタによって維持されているカウントを自動的に更新するように構成されたカウンタ制御装置と、
選択された宛先電話番号に対する最大容量値を記憶しているメモリと、
呼カウンタおよびメモリに接続された呼制御装置とを含み、
呼制御装置は、
呼カウンタの値と前記メモリ内のプログラムされた値とを比較するコンパレータと、
新しい呼を完了したときに宛先電話番号の容量を超過してしまう場合に、制御信号を生成して、新しい呼を宛先にルート設定せずに新しい呼を拒絶するように構成された制御信号生成装置と、
認められた呼へのネットワークの応答に依存して、前記メモリ内に変更容量値を自動的に書込むように構成されている容量追跡装置とを含み、
前記容量追跡装置は、
宛先電話番号の最大容量を推定するように構成された手段を含み、
前記推定値は、
該電話番号への呼の解放を完了した呼の数Ｎ_Cを監視するように構成された監視手段と、
各呼の解放を完了するのにかかった時間Ｔ_Cを記録するように構成された記録手段と、
前記一定の期間中に記録されたＮ_CおよびＴ_Cの値から導き出される、該電話番号への呼の平均保持時間から容量推定値を計算するように構成された手段とによって与えられ、前記メモリは、選択された宛先電話番号の最大容量の前記推定値により変更される、呼制御サーバ。
宛先電話番号における混雑を示すネットワークからの信号に応答して、呼カウンタ、カウンタ制御装置、および呼制御装置を初期設定するように構成されている混雑検出器をさらに含む請求項９記載の呼制御サーバ。
混雑検出器に接続されたリソースアロケータをさらに含む呼制御サーバであって、前記リソースアロケータは、宛先電話番号における混雑の検出に応答してサーバリソースを各電話番号に割当てるように構成されている請求項１０記載の呼制御サーバ。
容量追跡装置は、進行中の呼数が記憶された最大容量値に等しいとき、記憶された最大容量値をインクリメントして、新しく認められた呼に対するネットワークの応答を監視し、ビジー信号が戻されるときは記憶された最大容量値をデクレメントし、それ以外のときは記憶された最大容量値をインクリメントしたレベルに維持するように構成されている請求項１１記載の呼制御サーバ。
容量追跡装置は、呼カウンタ値が記憶された最大容量値よりも小さいときに認められた呼に応答してビジー信号が受取られるときはいつでも、記憶された最大容量値を低減するように構成されている請求項９または１０に記載の呼制御サーバ。
通信ネットワークであって、
ａ）端末リソースを接続するように構成された複数の相互接続されたノードと、
ｂ）請求項９乃至１２の何れか１項記載の呼制御サーバとを備えた通信ネットワーク。