JP2002505045A - サービス制御ポイント（ｓｃｐ）におけるオーバーロード防止 - Google Patents

Abstract

(57)【要約】 トランザクション処理システム、例えば遠隔通信サービスプラットフォームはネットワークインターフェイスを含み、ネットワークインターフェイスは使用の際に通信ネットワーク、トランザクションプロセッサ、およびガバナに接続される。ガバナは、トランザクション処理レートについての固定制限値をもつようにしてプログラムされ、固定制限値に達するとインバウンドトランザクションを解放する。ガバナは、トランザクションを開始するときの最初のメッセージと、トランザクションの次の処理中の中間のメッセージの両方に応答することができる。

Description

【発明の詳細な説明】 サービス制御ポイント（ＳＣＰ）におけるオーバーロード防止 本発明は通信ネットワークにおけるトランザクション処理システム、とくにイ ンバウンド（到着）トラヒックによるトランザクション処理システムのオーバー ロードの防止に関する。 通信ネットワークを設計するとき、ネットワーク資源を効率的に使用し、その 一方で多様に変化するトラヒックレベルのもとでネットワークが確実に機能する ことを保証することが必要である。第１の基準からすると、ほぼ最大容量でサー ビスプラットフォームを動作するのが望ましい。しかしながら、トラヒックが突 然ピークになり、最大容量を超すると、プラットフォームが故障してしまう危険 がある。これはインテリジェントネットワークのサービス制御プラットフォーム (SCP)に関する特別な問題である。ＳＣＰはしばしば、回路と関係していないシ グナリングシステムによってネットワークの他の構成要素に接続される。有効回 路数を制限することによって、ネットワークの他の要素をオーバーロードから保 護するための制約を設けることができるが、ＳＣＰへ向かうインバウンド信号に 対してこのような制約は適用されない。したがって、ＳＣＰはとくにオーバーロ ードに対して脆弱である。このようなオーバーロードを明示すると、処理ケーパ ビリティの不足、フリーメモリの不足、または利用可能な内部通信用バンド幅の 枯渇がある。 本発明の第１の態様にしたがって、通信ネットワークで使用するトランザクシ ョン処理システムであって： ａ）インバウンドトラヒックのシグナリングを通信するネットワークインタ ーフェイスと、 ｂ）トラヒックに関係するシグナリングレートについての固定（静的な）制 限値を備えてプログラムされたガバナと、 ｃ）ガバナに応答し、かつ固定制限値に達したときにインバウンドトランザ クションを解放するようにされているトランザクションプロセッサとを含むトラ ンザクション処理システムを提供する。 トランザクション処理システムは遠隔通信ネットワークで使用するサービスプ ラットフォームを含むことが好ましい。サービスプラットフォームは、インテリ ジェントネットワークで使用さ れるサービス制御プラットフォーム（ＳＣＰ）であってもよい。その代りにサー ビスプラットフォームは、ＣＴＩ（コンピュータ電話統合）技術を使用して、イ ンテリジェントサービスを電話ネットワークへ提供するコンピュータ応用システ ムの形態をとってもよい。本発明はさらに、インターネット（ＴＣＰ／ＩＰ）パ ケットの実時間処理を実行するシステムにも応用できる。 本発明は、ガバナを準備することによってサービスプラットフォームまたは他 のトランザクション処理システムを保護する。ガバナはブラットフォームへのイ ンバウンド呼のレートを固定制限値または閾値と比較し、制限値を超えたときに 呼を解放する。発明者は、このやり方は融通が利き、プラットフォームを保護す るのに有効であり、何れのプラットフォーム資源がオーバーロードポイントを決 定するかが不確かであるときでも効果的に機能することを発見した。意外にも、 固定制限値を使用すると、プラットフォームの使用可能な資源を直接に監視して 、オーバーロードポイントを判断するよりも良い結果が得られることが分かった 。ガバナはサービスプラットフォームの詳細な設計とは実質的に無関係に動作可 能であり、ネットワーク資源がプラットフォーム内で局部に位置しなくてもネッ トワーク資源を保護することができる。 好ましくはトランザクション処理システムはさらに： ｄ）オーバーロード制御装置を含み、このオーバーロード制御装置はガバナ に接続され、ネットワーク上で接続信号を出力し、固定制限値を越えたときに、 トランザクション処理システムへのインバウンドトランザクションレートを低減 するようにされている。好ましくはガバナは第１のより低い固定制限値および第 ２のより高い固定制限値を使用してプログラムされ、第１のより低い固定制限値 に達したときにオーバーロード制御装置へシグナリングするようにされ、第２の より高い固定制限値に達したときのみインバウンド呼を解放するようにされてい る。 レートガバナとオーバーロード制御装置との組合せはとくに好都合であること が分かっている。次にガバナによる呼解放イベントは、オーバーロード制御装置 への入力としてサービスする。次にオーバーロード制御装置は、送信元のスイッ チへ呼ギャッピング命令を送ることによってインバウンド呼のレートを低減する ことができる。この流れにおいては、２つの制限値をもつガバナを動作するか、 言い換えると、それぞれ異なる制限値をもつ２つのガバナを使用することによっ て、さらに別の好結果が得られる。次にガバナは、より低い制限値とより高い制 限値の間の呼レートでインバウンド呼の擬似拒絶を行い、したがって呼は依然と して認められるが、拒絶イベント信号がオーバーロード制御装置へ送られる。以 下でさらに詳しく記載するように、擬似拒絶を使用することにより、一連のトラ ンザクション処理においてレートを制限するネットワーク資源がガバナより先に ある環境で呼をより効率的に処理することができる。 好ましくは、ガバナは最初のトラヒックに関係する信号の合計レートと所定の 中間トラヒックに関係する信号の合計レートに応答するようにされている。 以下でさらに詳しく記載するように、ガバナが中間のトラヒックに関係する信 号、送信元のスイッチからネットワークインテリジェント周辺機器へ呼レッグ(l eg)のセットアップに関係する信号のレートに応答するとき、さらに加えて最初 の信号に応答するときに効果的である。次にガバナは多様な処理オーバーヘッド をもつ異なるトランザクションを処理することができる。 好ましくはトランザクション処理システムはさらに： ｅ）ガバナに接続され、固定制限値に対してその値を自動的に設定するよう にされているガバナ制御装置を含む。好ましくはシステムは複数の処理システム を含み、各処理システムはトランザクションプロセッサ、および各トランザクシ ョンプロセッサに接続されたガバナを含み、 ガバナ制御装置は複数の処理システムに接続され、異なる各ガバナの固定制 限値に対して独立したそれぞれの値を設定する。 本発明のこれらの好ましい特徴は、固定制限値を自動的に設定し、それぞれが 専用のガバナをもつ幾つかのプロセッサ間で呼処理を分配することによって、ト ランザクション処理システムの回復力および応答性を向上する。ガバナは呼ごと にガバナ制御装置を参照する必要はない。ガバナは呼のサンプルに対して定期的 に制御装置を参照すればよい。したがって処理のオーバーヘッドは低減する。 好ましくはガバナ制御装置はシステムの目標のトランザクションレートを用い てプログラムされ、異なるガバナごとに固定制限値を設定し、合計の認められた トランザクションレートが前記目標のトランザクションレートに実質的に一致す るようにされる。好ましくはガバナ制御装置はモニタ入力を含み、モニタ入力は 複数の処理システムに接続され、処理システムに関する状態データを受取り、ガ バナ制御装置は、機能しているトランザクションプロセッサ数が変化したことを 前記状態データが示したときに、異なる各ガバナのレート制限値を修正するよう にされている。したがってガバナは、異なるトランザクションプロセッサの制限 値と平衡を保ち、構成要素処理システムの１つが故障したときでさえも全体的な システムに対する所望の全体的なトランザクションレートを可能な限り維持する ことができる。 好ましくは、ガバナ制御装置はネットワークスイッチの識別子を監視し、ネッ トワークスイッチは使用の際にインバウンドシグナリングをトランザクション処 理システムへ向け、ガバナ制御装置は、通常別のトランザクション処理システム を使用するスイッチからシグナリングを受取ると、トランザクション処理システ ムに対する目標の呼レートを自動的に高めるようにされている。 本発明の好ましい特徴は、ガバナ制御装置の機能を拡張し、例えば別のサービ スプラットフォームが故障すると、ガバナ制御装置が通信ネットワーク状態の変 化に自動的に応答できるようにする。プラットフォームと通信するスイッチの識 別子を監視することによって、付加的なプラットフォーム間のシグナリングを要 求せずにこの拡張機能を達成することができる。 本発明の第２の態様にしたがって、第１の態様に示したトランザクション処理 システムを含む通信ネットワークを提供する。 本発明の別の態様にしたがって、通信ネットワークのトランザクション処理シ ステムを動作する方法であって： ａ）トランザクション処理システム内に置かれた通信ネットフークとガバナ との間で、インバウンドトランザクションの信号を送ることと； ｂ）ガバナにおいて、トランザクション処理システムによって処理されるト ランザクションの現在のレートを固定制限値と比較することと； ｃ）固定制限値に達したときに、トランザクションを解放することとを含む 方法を提供する。 本発明の別の態様にしたがって、通信ネットワークで使用するサービスプラッ トフォームであり： インバウンド呼のシグナリングを受取るネットワークインターフェイスと、 所定の呼レート閾値でプログラムされたスタティックガバナと、 スタティックガバナに応答し、所定の呼レート閾値に達したときにインバウ ンド呼を解放するようにされている呼処理プロセッサとを含むサービスプラット フォームを提供する。 本発明の別の態様にしたがって、通信ネットワークを操作する方法であって： ａ）シグナリングイベントに応答するリークバケットカウンタをインクリメ ントすることによって、ネットワーク資源のイベントレートと閾値レートとを比 較することと； ｂ）異なるシグナリングイベントにおいて段階（ａ）のインクリメントに対 して、異なるシグナリングイベントと関係するネットワーク資源へのローディン グの度合いに依存して異なる重み付けを与えることとを含む方法を提供する。 本発明のこの態様は、インバウンドシグナリングによる制御プラットフォーム のオーバーロードを防止するのに使用するのに制限されず、一般的にネットワー ク資源のオーバーロード防止に応用できる。本発明はさらにこのような方法で使 用するプラットフォームを含む。 ここで本発明を実現する手段を添付の図面を参照して例示的にさらに詳しく記 載することにする： 図１は、本発明を実現する通信ネットワークの模式図である； 図２は、図１のネットワークで使用するサービスプラットフォームの模式図で ある； 図３ａおよび３ｂは、図２のサービスプラットフォームにおける拒絶イベント を示すダイヤグラムである； 図４は、図２のプラットフォームにおける拒絶イベントを示すダイヤグラムで ある； 図５は、幾つかのサイトを横切るガバナ閾値の平衡を示すダイヤグラムである ； 図６は、図２のプラットフォームを構成するのに使用される共有メモリネット ワークを示すダイヤグラムである； 図７は、図２のプラットフォームを構成するのに使用される物理的アーキテク チャを示す； 図８は、本発明を実現するガバナのフローチャートである； 図９は、別の実施形態を示す。 IN（インテリジェントネットワーク）アーキテクチャを使用する遠隔通信ネッ トワークはサービス制御ポイント１を含み、サービス制御ポイント１は本明細書 においてネットワークインテリジェンスプラットフォーム(NIP)とも記載されて いる。サービス制御ポイント１は、トランクディジタルメインスイッチングユニ ット(DMSU)２、３と、ディジタルローカル交換(DLE)４、５に接続されている。 ＤＭＳＵおよびＤＬＥの両方はサービススイッチングポイント(SSP)として機能 する。呼の進行中に一定の点で、ＳＳＰは呼の制御をサービス制御ポイントへ移 す。サービス制御ポイントは、数字変換のような機能を行い、音声メッセージン グプラットフォームのような追加の資源に対するゲートウエイを準備する。 図２に示したように、この例のサービス制御ポイント１はオーバーロード制御 サーバ(OCS)21、多数のトランザクションサーバ22、および通信サーバ23を含む 。通信サーバ23は共通のチャンネルシグナリングネットワークへのインターフェ イスを備えている。トランザクションサーバは共通のバックエンドシステム24に リンクされ、共通のバックエンドシステム24は呼統計の収集のような管理機能に 応答することができる。動作の際は、最初の検出点が、例えばDLE４およびDMSU ２を経由して行なわれた呼に現れるとき、SSP(DMSU)は最初の検出点(IDP)メッセ ージをC7共通チャンネルシグナリングネットワークを経由してサービスプラット フォーム１へ伝える。呼は、例えば０８００番を相当する宛先番号に変換するこ とによってトランザクションサーバ22の１つの中で実質的に処理され、処理結果 はシグナリングネットワークを経由してDMSU２へ戻され、次にDMSU２では、例え ば他のDMSU３およびDLE５を経由して宛先へ呼をルー ト設定することができる。 上述の序説に記載したように、サービスプラットフォームに到達する呼に関係 するシグナリングのレートがプラットフォームが処理可能なレートを超えること があるといった潜在的なリスクがある。したがってプラットフォームの動作を許 容できないほど劣化するか、またはプラットフォームが完全に故障する結果にな ることがある。これを防ぐために、トランザクションサーバ22はスタティック（ 静的な）ガバナ220を含む。スタティックガバナ220は、トランザクションサーバ を構成するプロセッサ上で実行されるソフトウエアモジュールとして具現するこ とができ、各トランザクションサーバにおいてインバウンドの呼に関係するシグ ナリングレートを監視し、所定の固定呼レート閾値または制限値に達すると、呼 を解放する。ガバナはさらに拒絶イベントの信号をオーバーロードサーバへ送る 。理想的にはガバナは、サービスプラットフォームのシグナリングエントリポイ ントに可能な限り近くに位置し、その結果、前段のシステム(pre-governor)、例 えば通信サーバが混雑する前に、トラヒックのピークを可能な限り早く検出する 機会をもつ。本発明の構成では、ガバナは呼処理プロトコル層内に位置している 。呼が幾つかあるときは、ガバナは呼の最初のメッセージのみを処理する。呼処 理層内にガバナを置くことにより、ガバナは到来するメッセージに関して十分な 知識を得て、最初のメッセージを同じ呼によって生成された他のメッセージと区 別することを保証にする。この位置取りはさらに、呼処理プロトコル層の機能の １つであるので、呼拒絶メッセージの生成を容易にする。別の長所は、ガバナが 与えられた呼に関するデータおよび送信元のSSPの識別子にアクセスすることで ある。 オーバーロード制御サーバ(OCS)は、呼ギャップ命令を送信元のSSPへ送ること によってガバナによってシグナリングされる呼解放イベントに応答する。このよ うな命令はそれぞれ、インターバルおよび継続時間のタイマを保持する。SSPが 呼を承認すると、最初の検出ポイント(IDP)が生成され、ギャップインターバル タイマが作動する。インターバルが終了すると、次に与えられた呼が承認される 。このプロセスは継続時間が切れるまで繰返される。 この例では、呼処理層は、インテリジェントネットワークのITU基準において 特定されるINAP(インテリジェントネットワークアプリケーションプロトコル)層 （レイヤ）である。この場合の最初のメッセージはINAP InitialDPのオペレーシ ョンである。呼を解放するために、ReleaseCallのオペレーションを使用し、解 放する理由を特定する。この結果トーンまたはアナウンスメントが呼の発信者へ 再生される。ノードの全体的なタイトルは発呼アドレス内に含まれ、発呼アドレ スTCAP（トランザクションケーパビリティアプリケーションパート）TC-Beginメ ッセージから検索される。このタイトルを使用して、各呼に対して送信元のSSP を独特に識別する。 各トランザクションサーバ内のガバナは、“リークバケット(leaky bucket)” アルゴリズムと呼ばれるものを使用して承認される呼のレートを制限する。本発 明者の国際特許出願PCT/GB 94/02512号に記載したように、リークバケットは、 固定レート、すなわちリークレートで定期的にデクレメントされるカウンタであ る。この例では、新しい呼に対して最初のメッセージが各トランザクションサー バによって受取られ、呼が受領される度ごとに、ガバナはドリップをバケットに 加える、すなわちカウンタをインクリメントする。バケットが、拒絶閾値に到達 するレベルまで満たされると、バケットがリークするまで全ての呼が拒絶される 。バケットは、管理される中間到達レートに等しいレートでリークする。バケッ トリークレートおよび拒絶閾値の両者は、OCS内のガバナ制御装置によって設定 される。次にアルゴリズムを以下のように演算する： １．バケットが０の充填レベルであるとき、新しい呼を承認するたびごとに値１ のドリップ（滴）を受取る。 ２．全てのドリップが“開始”レベルよりも高い充填レベルをもつとき、充填レ ベルに影響を与えない。 ３．ドリップが開始レベルよりも高いバケットをもつとき、呼は拒絶されるべき である。 ４．バケットはガバナ閾値に等しいレートでリークする。 このアルゴリズムの結果、与えられたトラヒックレートがガバナ閾値を越える とき、承認レートは閾値に制限されることを確実にする。 この構成では、ガバナは２つのタイプの拒絶イベント、すなわち“実拒絶(rea l rejection)”および“擬似拒絶(pseudo rejection)”をトリガする。別々の呼レ ート閾値は各タイプの拒絶イベントに対して維持され、それぞれ個別のリークバ ケットカウンタを使用する。実拒絶イベントは上述のように使用される。この実 拒絶イベントでは、図３ｂに示したようにガバナは解放呼メッセージを生成し、 その結果所定の呼レート閾値に到達するときに呼が拒絶される。これは、ボトル ネック、すなわちオーバーロードする資源が一連の呼処理においてガバナの後に あるときに適している。しかしながら、ボトルネックがガバナの前にあるときも ある。これは、ガバナに関して呼を受取ったとき、ガバナの後に呼を処理する十 分な容量があることが多いことを示唆している。この場合、呼を解放するのでは なく、呼の処理を継続するのがより効果的である。この場合は擬似拒絶イベント を使用する。最初のメッセージは、さらに処理を行うために後段のガバナシステ ム(post-governor)へ送られる。同時に、拒絶イベントの信号がOCSのオーバーロ ード制御機能へ送られるとき、OCSは到来する呼レートを低減するように働き、 それによって前段のガバナシステム内の潜在的にオーバーロードされる資源を保 護する。擬似拒絶イベント閾値は実拒絶イベント閾値よりも低い値に設定されて いる。例えば、擬似拒絶イベントの閾値は１００呼／秒に設定され、実拒絶イベ ントの閾値は１２０呼／秒に設定してもよい。したがって、現在の呼レートが、 例えば１１０呼／秒であるとき、擬似拒絶イベントがトリガされる。呼レートが 、例えば１２０呼／秒に達すると、実拒絶イベントがトリガされる。 図４は、イベントが３タイプの状況で進行することを示している。領域ａでは 現在の呼レートが両方の閾値よりも低く、拒絶は生じない。領域ｂでは、現在の 呼レートは擬似拒絶イベント閾値よりも高く、実拒絶イベント閾値よりも低い。 領域ｃでは、現在の呼レートは、擬似拒絶イベント閾値および実拒絶イベント閾 値の両方よりも高い。ダイヤグラムに示したイベントの位置は、左から右へ向っ てシグナリングネットワーク(CTN)、ガバナ、ガバナ制御装置、オーバーロード 制御機能(OCF)、ノードメンバシップ変更機能(NMCF)、およびバックエンドシス テムである。 図２に示されているように、サービスプラットフォームは実際には、多数のト ランザクションサーバ（参照符号１ないしｎ）として構成することができ、各ト ランザクションサーバは専用のガバナを有する。幾つかのトランザクションサー バを使用すると、プラットフォームの容量を増加し、加えて局部の構成要素の故 障に耐えるケーパビリティを強化する。ガバナ制御装置は、トランザクションサ ーバの１つが故障しても、全体的なプラットフォームのスループットを可能な限 り維持するように設計される。したがって、ガバナ制御装置は監視機能を含む。 この構成ではガバナ制御装置は、メモリチャンネルネットワークを使用してトラ ンザクションサーバと通信し、監視機能は、メモリチャンネルネットワークと関 係しているノードメンバ変更機能（NMCF）を使用して構成される。使用の際に監 視機能は、サービスプラットフォームサイトにおいて幾つのトランザクションサ ーバが作動しているかを判断する。次にガバナ制御装置はサービスプラットフォ ームサイトに対する目標割当てレートを示して、この目標割当てレートはネット ワーク管理機能によって予め設定してもよく、使用可能なトランザクションサー バ数によって除算する。ガバナ制御装置は、トランザクションサーバに割当てら れた生成された閾値が、トランザクションサーバが処理できる最大レートを超え ないことを確実にする。追加の安全測定では、各ガバナは最大閾値でプログラム される。ガバナそれ自体が個別に動作することが分かると、例えばサイトガバナ 制御装置が故障すると、ガバナは最大閾値に対してデフォルトとする。 図５に示したものに代る実施形態では、サービスプラットフォームは３つのサ イト、Ｍ、Ｎ、Ｐ間で分割される。各サイトは多数のトランザクションサーバ、 加えて通信サーバおよびオーバーロード制御サーバをもつ。トランザクションサ ーバは各ガバナを含み、ガバナ制御装置は図２のサービスプラットフォームに関 して既に記載したように、各オーバーロード制御サーバ内に位置付けられている 。異なるサイトは共通のバックエンドシステムに接続されている。図２には、ネ ットワークSSPを４つ示した。このSSPはノードの全体的なタイトル、Ａ、Ｂ、Ｃ 、およびＤをもつ。各SSPは各サービスプラットフォームサイトに接続している 。図２では、好ましい接続を実線の矢印で示した。別の第２の選択接続は点線の 矢印で示した。特定のサービスプラットフォームサイトが故障するとき、全ての SSPは、第１の選択として現在使用している故障したサイトから、それぞれ第２ の選択サイトへスイッチする。(図５の下部のNodal GTはノードのグローバル タイトルの意)。 ネットワークが中央オペレーションユニットを準備し、中央オペレーションユ ニットが異なるサイト全体で閾値の平衡をとるとき、現在の好ましい構成はガバ ナを使用し、サイト内のガバナ制御装置は自動的にサイト全体の閾値の平衡をと る。各サイト内のガバナ制御装置は、サイトに与えられた全てのトラヒックを登 録し、サイトへ向う信号を方向付ける各SSPの識別子をモニタする。所定の時間 内で出会った異なるSSP識別子の数から、ガバナ制御装置は、幾つのSSPをそれに 接続したかを計算する。次にそれにしたがってサイトに対する目標の閾値を設定 する。例えば、合計累積目標が９００秒／呼の３つのサイトがあり、１つのSSP が故障しているとし、故障したサイトに予め接続されているSSPが残りの２つサ イトの間で等しく分割されると仮定すると、各残りのサイトは、以前は見えなか った１つの付加的な呼からの呼を見る。これが、各残りのサイト内のガバナ制御 装置によって検出される。ガバナ制御装置は、各サイト内のトランザクションサ ーバの目標ガバナ設定を上昇して、サイトによって処理される増加したトラヒッ クを考慮に入れる。 SCPには使用可能なマニュアル式の制御停止装置機構を含み、例えば１つのSCP が故障したときに、他のサイトがトラヒックレベルの上昇を停止することができ る。 次の表１ａおよび１ｂは、図５のネットワークにおける閾値の平衡をさらに詳 細に示している。 表１ａは、全NIP、すなわち３つのサイトおよび共通のバックエンドシステム の状態が標準のときの変数についての設定を示す。表１ｂは１つのサイト（サイ トＰ）が故障し、トランザクションサーバがサイトＮで故障したときに、これら の設定がどのように変化するかを示す。簡単に示すために、図には幾つがのSSP のみを示したが、実際のネットワークでは数百のSSPを３つのSCPサイトに接続す ることができる。したがって、サイトの１つが故障すると、各残りのSCPサイト は多数のSSPを有することになり、SSPはサイトを第２の選択としてSCPサイトへ スイッチする。 図７は、図２のサービスプラットフォームの物理的構成を示す。本発明は、と くにDCE Alpha 4100トランザクションサーバおよびDCE Alpha 4100オーバー ロード制御サーバに関係している。ガバナおよびガバナ制御装置はこれらのサー バ上で実行されるソフトウエアモジュールとして構成される。これらは “メモリチャンネル”（MC）と呼ばれる共有メモリ通信リンクを使用する。メモ リチャンネルシステムはDECから販売されている。ノードメンバ変更機能NMCFを 実行するのに、メモリチャンネルが使用される。上述のように、NMCFによりガバ ナ制御装置では活性のトランザクションサーバが幾つあるかをモニタできる。メ モリチャンネルはさらに、トランザクションサーバが、ガバナ制御装置およびOC FのようなOCS上の中央サービスと通信する実効手段を準備している。図６は、メ モリチャンネルネットワークの動作を示している。メモリチャンネル方式では、 そのAPI（アプリケーションプログラムインターフェイス）の一部としてロック 機能を準備している。MCは（設定時間内で）ノード（サーバ）が故障したときに ロックを解除することを保証する。ガバナ制御装置はトランザクションサーバの 識別子で予めプログラムされている。ガバナ制御装置は、各トランザクションサ ーバに属しているロックを掴む(grab)試行を定期的に行う。ガバナ制御装置がロ ックの１つを何とか得るとき、予め活性のトランザクションサーバ現在故障して いることが分かる。(以前は得られたが)ロックが最早得られなくなったときは、 トランザクションサーバが現在活性であることが分かる。 この構成では、次の情報流がメモリチャンネル：擬似および実拒絶閾値；与え られた呼および関係するSSP IDのカウントを介して通信している。閾値は、メ モリチャンネル内に保持されている簡単なデータ項目である。OCS上のガバナ制 御装置ソフトウエアは値を書込み、一方でトランザクションサーバ上のソフトウ エア方法で値を読むことができる。各与えられた呼に対して、トランザクション サーバ上のソフトウエアは共通の呼計数にアクセスし、次にカウントをロックす る一方で、カウントの値をインクリメントする。 上述の例において、SCPに対して行なわれる各呼は、SCPに対するロードがほぼ 同じになると仮定する。異なる呼に関係するローディングが幾らか分散していて も、ロードがほぼ同じであるために、受け入れられる結果を得ることができる。 例えば、幾つかの呼は簡単な数字変換を含み、この場合SCPは最初のDPを処理し て、次にFurnishChargmgInformation、SendChargingInformation、およびConnec t信号を処理し、一方で他の呼では数字変換と呼統計演算とを結合する。（これ らのイベントと信号、および以下で参照する他のイベントと信号は ITU INAP基準で正式に規定されており、本明細書で使用した用語はこのITUINAP 基準からとったものである）。他の呼の場合、特別なRequestReportBCSMEventオ ペレーションが必要である。したがって特別なメッセージ、EventReportBCSMは 、SSPからSCPへ送られ、呼の状態を示す。このためSCP上の処理ロードの増加が 比較的に少ない。この結果、ガバナは呼のタイプとは無関係に、各InitialDPに 対するリークバケットカウンタへ単に１ドリップ付加することのみによって効果 的に機能することができる。 ある種の状況では、SCPは、ロードが多様に変わる異なる呼を処理することを 要求されることがある。これは、呼の幾つかが多数のレッグを含むときに関係す る。このような呼はSSPにおける検出ポイントを用意し、RequestReportBSCMEven tをinterrupted(割込みされた)として使用することを含む。この場合、SCPは、 例えばビジーに対する検出ポイントをトリガし、次に呼の制御はSCPのままであ る。この場合SCPはSSPと、次に単一のInitialDP(最初の検出ポイント)イベント と多数の対話を行ってもよい。さらに、ここではサービスは、インテリジェント 周辺機器、例えば音声メッセージングプラットフォームの使用を含んでもよい。 次にSCPはインテリジェント周辺機器に対して仮のレッグを設定し、音声による 対話を可能にしなければならない。同時に、SCPへ信号を送られた他の呼は依然 として簡単な数字変換のみを含んでもよい。 上の段落で記載したシナリオでは、各initialDPが簡単な数字変換の処理ロー ドと関係しているという仮定のもとでガバナがプログラムされるとすると、実際 に受取った呼が多数のレッグをもつときには、SCPの容量を越える可能性が高い 。他方で、各InitialDPが多数のレッグをもつ呼(multiple-legged call)と関係 しているという仮定のもとでレート制限が設定されるとすると、呼の大半が簡単 な数字変換であるときには、SCPの資源は十分に利用されていないことになる。 これらの問題を克服するために、本発明の別の構成において、InitialDPメッセ ージをSCPで受取るときだけでなく、イベント報告が割込みされたEDP（イベント 検出ポイント）であるとき、SCPとの間で他のオペレーションを送受信すると、 例えばEventReportBCSMメッセージを受取るときも、ガバナはリークバケットカ ウンタにドリップを加えるようにプログラムされる。この段階で呼が既に認め られているとき、生成された拒絶イベントは擬似拒絶イベントである。サービス がインテリジェント周辺機器へのレッグを含むとき、EstablishTemporaryConnec tionオペレーションが行なわれると、リークバケットカウンタをインクリメント する別のトリガとして取扱われる。この場合に、トリガはSCPからSSPへ、他の例 では逆方向へ送られた信号に関係している。ここでもまた、拒絶イベントは擬似 拒絶イベントである。 この代りの構成の別の特徴は種々のドリップを使用することである―すなわち リークバケットカウンタは、ドリップを発生したイベントの性質に依存して異な る量をインクリメントされる。InitialDPと関係するドリップは２の値をもち、 一方でEventReportBCSMと関係するドリップは、１の単位値をもってもよい。異 なるイベントに対する適切なドリップ値、およびガバナに対する閾値は、特定の プラットフォームをプロトタイプにして試験するか、または異なるタイプの呼に 対して表示サービス時間を使用してモデリングすることから、あるいはその両方 によって決定できる。原則として、サービスプラットフォームで生成される中間 のシグナリングイベントの幾つかまたは全てを使用して、リークバケットカウン タへのドリップの追加をトリガできる。構成を簡単にするために、このような全 てのイベントを潜在的にドリップを追加するものとして処理できるが、選択した イベントに対してはドリップの重み付けをゼロに設定してもよい。 図８は、直前の段落に記載した可変の重み付けドリップを使用するガバナのフ ローチャートである。図を分かり易くするために、リークバケットカウンタから の規則的なドリッピングは、図のイベント流から削除した。これは同時に発生す る外部イベントとしてもよい。段階s1では、ガバナがネットワークインターフェ イスを経由して信号を送受信するときに、メッセージイベントを生成する。段階 s2において、ガバナはイベントタイプを決定する。段階s3において、イベントが InitialDP(IDP)であると判断されると、ドリップの重み付け値は、例えば３に等 しく設定される。段階s4では、変数r_currentlevelの値、すなわち実拒絶イベン トにおけるリークバケットカウンタの現在のレベルが読取られる。段階s5では、 ドリップの重み付けがr_currentlevelrに付加され、結果は仮のレジスタ“temp ”に書込まれる。段階s6では、tempの値はreal_currentlevel、すなわ ち実拒絶イベントの制限値と比較される。制限値を越えると、段階s7ではガバナ は実拒絶イベントの通知をOCSへ送る。段階s8においてガバナは呼を解放する。 制限値を越えないときは、段階s9(図8iii参照)において、real_currentlevelが 仮のレジスタ内に保持される値に等しく設定されるとき、ドリップがバケットに 追加される。段階s10で擬似拒絶イベントにおけるリークバケットカウンタレベ ルの値p_currentlevelが読取られ、段階s11でドリップの重み付けはこの値に付 加され、仮レジスタに書込まれる。段階s12ではtempの値がpseudo I、すなわち 擬似拒絶イベントの制限値と比較される。制限値を越えたときは、段階s13でガ バナは擬似拒絶イベントの通知をOCSへ送る。制限値を越えないときは、段階s14 で変数p_currentlevel値が仮のレジスタに保持された値に等しく設定されるよう に、ドリップをバケットに加える。 IDPイベントおよび呼の承認に続いて、中間のイベントを使用して、リークバ ケットにおいて実拒絶および擬似拒絶のレベルまで加える。例えば、中間のイベ ントはSCPからSSPへ送られるEstablishTemporaryConnection(ETC)信号であると き、段階s15でドリップの重み付けは、例えば３に等しく設定される(図8ii参照) 。段階s16において、別の中間イベント、EventReportBCSM(ERBE)では、ドリップ の重み付けは、例えば１に等しく設定される。同様に、他の重み付けは他の中間 イベントに設定してもよい。段階17ないし20では、適切なドリップ値は両方のリ ークバケットに付加される。ガバナは、この例ではSCPとSSPとの間の全てのイベ ント流に対してリークバケットにドリップを加える。これらのイベントは、次の ように構成される： SSPからSCPへ ・InitialDP ・EventReportBCSM ・ActivityTest result SCPからSSPへ ・FurnishChargingInformation ・SendChargingInformation ・Connect ・ActivityTest ・EstablishTemporaryConnection ・RequestResportBCSMEvent これらのオペレーションはそれぞれ、割当てられたドリップ値を有する。 InitialDPは特別な場合であり、ドリッピングなしに拒絶することができる。す でに記載したように、幾つかのイベントはドリップに対してゼロの値を割当てて もよい。 図９は、異なるドリッブの重み付けを使用した本発明の好ましい構成を示して いる。この例ではSCPはトランザクションサーバ呼処理モジュール91、トランザ クションケーパビリティアプリケーションパート(TCAP)サーバ92、TCAPバックエ ンドプロセッサ93、および通信サーバ94を含む。転送モジュール95は、TCAPサー バ92をアドバンストトランザクションサーバ96へリンクし、アドバンストトラン ザクションサーバ96では一定の先行トランザクションを行う責務を負う。既に記 載した実施形態に示したように、TCAPサーバは、リークバケットアルゴリズムを 使用するガバナを含む。 図９において１ないし６で分類された６つのインターフェイスを通るメッセー ジの処理ために、トランザクションサーバにロードし、これらのインターフェイ スを横切るメッセージレートの重み付けされた和としてモデルリングすることが できる。同様にシグナリングネットワークロードは、図９で１ないし４で分類さ れた２つのインターフェイスを横切るメッセージの重み付けされた和としてモデ リングすることができる。ガバナにおけるドリップの重み付けは、各メッセージ によって含まれる重み付け量に比例して設定される。構成可能なドリップの大き さは、各インターフェイスにおいてメッセージのタイプごとに記載されている。 表２には図に示した各インターフェイス(i/f)に対する異なるメッセージを記載 した。 これは５＋３＋５＋９＋４＋７＝３３の構成可能なドリップの大きさの準備を 要求する。本発明の比較的に簡単な構成では、IDP（最初の検出ポイント）のみ がインターフェイス１においてガバナリークバケットのレベルに役立ち、そのド リップの大きさは１（ユニティ）である。あるTSがロードを落とす(shed、少な くする)唯一の許容可能なやり方は、IDPをTS Call Processingへ送るのではなく 、到来するIDPに対してReleaseCallを戻すことであるときは、実拒絶Govenerリ ークバケットは、IDPが拒絶されるレベルを越えて充填できない。その理由は許 容可能なIDPのみがバケットにドリップを加えられる結果となるからである。し かしながら好ましい実施形態では、ガバナリークバケットレベルが、到来するID P（“新しいロード"）が拒絶されるレベルよりも大きくても、後続の呼に対する メッセージはインターフェイスで拒絶されない。 １例として、図９に示した構成では、例えばATSによって処理されるサービス 、異なるメッセージに対するドリップの重み付け（ここでは“サイズ”と記載さ れる）、および異なるインターフェイスを次のように設定できる：注釈<message >(<interface_number>)を使用して、ドリップサイズを特定すると、付加される ドリップは次の重み付けマトリックスIDP(1)、IDP(2)、INAP Control(3)、IDP(5 )、SCI(6)、FCI(6)、Connect(6)、SCI(4)、Connect(4)を有する。ここではINAP ControlメッセージはTCAP Serverを示すメッセージであり、このメッセージはTC AP ServerからATSへ送られることになる。 第２の例として、ガバナバケットレベルはIDPが拒絶される閾値レベルよりも 高いので、IDPが拒絶される結果としてガバナバケットへ加えられるドリップに ついて検討する。次に加えられるドリップはサイズIDP(1)、ReleaseCall(4)を有 する。これは、拒絶される呼を仮定して、トランザクションサーバのローディン グをゼロにする構成よりも一層正確にロードをモデル化する。 本発明にしたがってプラットフォームを構成し、ガバナ内のリークバケットを 使用するとき、メッセージに関係するドリップをリークバケットに加える度ごと にバケットをリークする必要はない。IDPが到達するとき正確なレベルを判断す ることのみが必要であり、呼を処理するか、すなわち解放するか否かを判断しな ければならない。したがってこの判断を行う直前にバケットはリークされなけれ ばならないが、他のときはリークされる必要はない。 バケット充填レベル、ドリップの大きさ、および各リーク時間に排出される量 は全て本来整数ではなく、実数である。ドリップの大きさを設定するときの最大 の融通性とコードの明白性および保守可能性についてみると目盛りのついた整数 を使用するのではなく、浮動小数点とかまたは二重形式としてそれらを表すこと が望ましい。浮動小数点式のハードウエアを使用すると、演算の不利を引き起こ す可能性は非常に低い。２つの浮動少数点の数字を比較するとき、不等式（＜、 ＞、＞＝、＜＝）を含む試験のみを使用するので：等式に対する試験は信頼でき ない。 図９に関して既に記載した構成において、インターフェイスの位置およびメッ セージイベント識別子に対応する二次元の重み付けマトリックスを使用する。こ の例における重み付けは、単一の仮定されたボトルネックの位置に関係して、例 えばTCAPサーバにおいて、判断される。多数の異なる潜在的なボトルネックであ って、その中の１つは呼の混合に依存して真のボトルネックになることのあるよ うなボトルネックを検討することによって、ガバナの機能をさらに拡張すること ができる。そのときはドリップの重み付けを判断するに使われる２つの重み付け マトリックス（または同じように単一の三次元マトリックス）があり、一方のマ トリックスはメッセージタイプおよびインターフェイスの次元を有し、これはオ ンボックスおよびオフボックスインターフェイスを横切るメッセージによってロ ーカルボックス（ここではトランザクションサーバ）に含まれるロードに関係し ている。他方のマトリックスは、メッセージタイプおよびボトルネックの次元を 有し、これはボトルネックと通信するインターフェイスを横切るメッセージによ って遠隔のボトルネックに含まれるロードに関係する。 例えば、全ての呼が成功および失敗に関する実時間報告を要求するときは、報 告エンジンはボトルネックであってもよく；多数の短いシグナリングメッセージ があるときは、ルーティングのためのシグナリングネットワークの処理はボトル ネックであることがあってもよく；平均シグナリングメッセージ長が大きいとき は、シグナリングリンクのバンド幅はボトルネックであってもよい。 多数のボトルネックはガバナによって次のように保護される：各潜在的なボト ルネックに対して、含まれているボトルネックのローディングを各メッセージに よって評価する。例えば、報告エンジンにおけるローディングはNotifyAndConti nueモードで受取られるINAP Event Reportsのみによるものであり、したがって このメッセージのみがゼロ以外の重み付けを有しており；シグナリングルーティ ングプロセッサのローディングは全てのメッセージに対して等しく；シグナリン グリンクのローディングはメッセージの長さに比例する。 絶対値は、ガバナバケットの選択された（任意の）リークレートおよびボトル ネックの容量に依存する：例えば報告エンジンは、毎秒２００の呼結果報告を処 理でき、ガバナリークレートが毎秒１．０であるときは、各Event Report（イ ベント報告）は０．００５の重み付けをもつ。シグナリングネットワークにおけ るルーティングプロセッサは毎秒２５０のメッセージを処理することができ、ロ ード共有方式では４つのこのようなプロセッサがあり、各メッセージは０．００ １の重み付けを有する。 その結果ガバナドリップ重み付けマトリックスが生成され、(例えば)ボトルネ ックでインデックスを付した列を有し、またメッセージタイプでインデックスを 付した行を有する。全ての潜在的なボトルネックにおける混雑から保護するため に、各メッセージにおいてその列に現れる最大重み付け、すなわちメッセージが 最大のローディングを含んでいるボトルネックに対応する重み付けを選択する。 そこで既に記載したインターフェイス／メッセージタイプマトリックス内で代用 される値がこれである。したがって次に、インターフェイス／メッセージマトリ ックスにおける異なるエントリは異なる潜在的なボトルネックの位置によって判 断される。 上述の簡単な例を使用して、報告エンジンおよびシグナリングルーティングプ ロセッサが２つのみの潜在的なボトルネックであるとすると、NotifyAndContinu eモードで受取られるEvent Reportは０．００５の重み付け （０．００５および０．００１の２つの重み付けの最大値）に割当てられ、全て の他のメッセージは０．００１の重み付け（０および０．００１の２つの重み付 けの最大値）に割当てられる。例示の報告エンジンボトルネックは、インターフ ェイスを横切ってTCAP ServerからTCSPおよびTSからATSへのイベント報告によっ て含まれるロードを有する。シグナリングネットワークのボトルネックは、TCAP Serverへのネットワークインターフェイスを横切る全てのメッセージによって 含まれるロードを有する。これらの異なる重み付けは、メッセージタイプ、イン ターフェイスインデックス、およびボトルネックインデックスを有する３次元の 重み付けマトリックスによって構成することができる。 上述ではリークバケットカウンタに関して記載したが、トランザクション処理 システムにおけるシグナリングイベントを計数する際に異なる重み付けを使用す る原理を他の方式のレート監視を使用する構成に利用することもできる。さらに 本発明のガバナを使用するのとは別に、異なる重み付けをリークバケットに使用 して、他のコンテキストでネットワーク資源を保護することもできる。例えば公 衆交換電話ネットワーク（PSTN）の宛先番号に焦点を合わせたオーバーロードを 防ぐためのアウトバンドレート制御で使用できるのであり、これについては本発 明者の欧州特許EP-B-334612（1993年８月４日に認可され、1988年３月21日を優 先日とする）に記載され、その内容は参考文献として本明細書に組込まれている とする。

───────────────────────────────────────────────────── フロントページの続き (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＣＹ， ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，Ｉ Ｔ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ ，ＣＦ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＭＬ，ＭＲ， ＮＥ，ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＧＨ，ＧＭ，ＫＥ，Ｌ Ｓ，ＭＷ，ＳＤ，ＳＺ，ＵＧ，ＺＷ)，ＥＡ(ＡＭ，ＡＺ ，ＢＹ，ＫＧ，ＫＺ，ＭＤ，ＲＵ，ＴＪ，ＴＭ)，ＡＬ ，ＡＭ，ＡＴ，ＡＵ，ＡＺ，ＢＡ，ＢＢ，ＢＧ，ＢＲ， ＢＹ，ＣＡ，ＣＨ，ＣＮ，ＣＵ，ＣＺ，ＤＥ，ＤＫ，Ｅ Ｅ，ＥＳ，ＦＩ，ＧＢ，ＧＥ，ＧＨ，ＧＭ，ＧＷ，ＨＵ ，ＩＤ，ＩＬ，ＩＳ，ＪＰ，ＫＥ，ＫＧ，ＫＰ，ＫＲ， ＫＺ，ＬＣ，ＬＫ，ＬＲ，ＬＳ，ＬＴ，ＬＵ，ＬＶ，Ｍ Ｄ，ＭＧ，ＭＫ，ＭＮ，ＭＷ，ＭＸ，ＮＯ，ＮＺ，ＰＬ ，ＰＴ，ＲＯ，ＲＵ，ＳＤ，ＳＥ，ＳＧ，ＳＩ，ＳＫ， ＳＬ，ＴＪ，ＴＭ，ＴＲ，ＴＴ，ＵＡ，ＵＧ，ＵＳ，Ｕ Ｚ，ＶＮ，ＹＵ，ＺＷ (72)発明者 スコット、マイケル イギリス国、アイピー６・８ティービー、 サフォーク、イプスウィッチ、ニードハ ム・マーケット、チェインハウス・ロード 33 (72)発明者 ウイリアムソン、ポール イギリス国、アイピー12・１ジェイディ ー、サフォーク、メルトン、ブリー・ヒル 58 (72)発明者 ハント、ローランド・ジェフリー イギリス国、アイピー４・２ティーエイ チ、サフォーク、イプスウイッチ、サウ ス・クローズ 11 (72)発明者 クックソン、マーティン・デビッド イギリス国、シービー１・６ビーエル、ケ ンブリッジシャー、ケンブリッジ、リト ル・アビントン、ケンブリッジ・ロード 11、ザ・スピニー（番地なし)

Claims (1)

1. 【特許請求の範囲】 １．通信ネットワークで使用するトランザクション処理システムであって： ａ）インバウンドトラヒックのシグナリングを通信するネットワークインタ ーフェイスと、 ｂ）トラヒックに関係するシグナリングレートについての固定制限値を備え てプログラムされたガバナと、 ｃ）ガバナに応答し、かつ固定制限値に達したときにインバウンドトランザ クションを解放するようにされているトランザクションプロセッサとを含むトラ ンザクション処理システム。 ２．ｄ）ガバナに接続され、ネットワーク上で接続信号を出力し、固定制限値を 越えたときに、トランザクション処理システムへのインバウンドトランザクショ ンレートを低減するようにされているオーバーロード制御装置をさらに含むトラ ンザクション処理システム。 ３．最初のトラヒックに関係する信号および所定の中間のトラックに関係する信 号の両方の合計レートに応答するようにされている請求項１または２記載のトラ ンザクション処理システム。 ４．前記所定の中間のトラヒックに関係する信号が、中断検出ポイントの設定と 関係する信号を含む請求項３記載のトランザクション処理システム。 ５．前記中間のトラヒックに関係する信号が中断EventReportBSCMメッセージを 含む請求項４記載のトランザクション処理システム。 ６．ガバナが前記最初のトラヒックに関係する信号の合計呼レートへの寄与およ び前記中間のトラヒックに関係する信号の合計呼レートへの寄与と異なって重み 付けするようにされている請求項３ないし５の何れか１項記載のトランザクショ ン処理システム。 ７．ガバナが第１のより低い固定限界値と第２のより高い固定限界値とでプログ ラムされ、第１のより低い固定限界値に達したときはオーバーロード制御装置に 信号を送るようにされ、第２のより高い閾値に達したときのみインバウンド呼を 解放するようにされている請求項2、または請求項２に従属するときは請求項３ ないし６の何れか１項記載のトランザクション処理システム。 ８．前記制御信号が、スイッチにアドレスされる呼ギャップメッセージを含み、 使用の際にスイッチがトランザクション処理システムに接続される請求項２ない し７の何れか１項記載のトランザクション処理システム。 ９．ｅ）ガバナに接続され、固定制限値に対してその値を自動的に設定するよう にされているガバナ制御装置を含むガバナ制御装置をさらに含む請求項１ないし ８の何れか１項記載のトランザクション処理システム。 １０．複数の処理システムを含み、各処理システムはトランザクションプロセッ サ、および各トランザクションプロセッサに接続されたガバナを含み、 ガバナ制御装置は複数の処理システムに接続され、異なる各ガバナの各固定 制限値に対して独立して設定される請求項９記載のトランザクション処理システ ム。 １１．ガバナ制御装置はシステムの目標のトランザクションレートを用いてプロ グラムされ、異なるガバナごとに固定制限値を設定し、合計の認められたトラン ザクションレートが前記目標のトランザクションレートに実質的に一致するよう にされる請求項１０記載のトランザクション処理システム。 １２．ガバナ制御装置はモニタ入力を含み、モニタ入力は複数の処理システムに 接続され、処理システムに関する状態データを受取り、ガバナ制御装置は、機能 しているトランザクションプロセッサ数が変化したことを前記状態データが示し たときに、異なる各ガバナの固定制限値を修正するようにされている請求項１１ 記載のトランザクション処理システム。 １３．ガバナ制御装置はネットワークスイッチの識別子を監視し、ネットワーク スイッチは使用の際にインバウンドシグナリングをトランザクション処理システ ムへ方向付け、ガバナ制御装置は、通常別のトランザクション処理システムを使 用するスイッチからシグナリングを受取ると、トランザクション処理システムに 対する目標の呼レートを自動的に高めるようにされている請求項９ないし１２の 何れか１項記載のトランザクション処理システム。 １４．請求項１ないし１３の何れか１項記載のトランザクション処理システムを 含む通信ネットワーク。 １５．通信ネットワークのトランザクション処理システムを動作する方法であっ て： ａ）通信ネットワークとガバナとの間で、インバウンドトランザクションの 信号を送ることと； ｂ）ガバナにおいて、トランザクション処理システムによって処理される呼 の現在のレートを固定制限値と比較することと； ｃ）固定制限値に達したときに、インバウンドトランザクションを解放する こととを含む方法。 １６．制御信号をネットワークへ出力し、それによってガバナによってトリガさ れる呼拒絶イベントに応答して、トランザクション処理システムへのインバウン ド呼のレートを低減することをさらに含む請求項１５記載の方法。 １７．拒絶イベントが行なわれるときにガバナからオーバーロード制御装置へ拒 絶イベント信号を送り、続いてオーバーロード制御装置から制御信号を出力する ことを含む請求項１６記載の方法。 １８．第１のより低い固定限界値に達したときに、前記拒絶イベント信号をオー バーロード制御装置へ送り、第２のより高い固定限界値に達したときのみ、オー バーロード制御装置へのシグナリング、インバウンド呼の解放の両方を含む請求 項１７記載の方法。 １９．段階（ｂ）においてガバナは最初のトラヒックに関係する信号および中間 のトラヒックに関係する信号の合計レートと、前記閾値とを比較する請求項１５ ないし１８の何れか１項記載の方法。 ２０．前記所定の中間のトラヒックに関係する信号が、中断検出ポイントの設定 と関係する信号を含む請求項１９記載の方法。 ２１．前記中間のトラヒックに関係する信号が、中断EventReportBSCMメッセー ジを含む請求項２０記載の方法。 ２２．最初のトラヒックに関係する信号の合計呼びレートへの寄与と中間のトラ ヒックに関係する信号の合計呼レートへの寄与とが異なって重み付けされる請求 項１９ないし２１の何れか１項記載の方法。 ２３．トランザクション処理システムが遠隔通信ネットワークで使用するサービ スプラットフォームである請求項１ないし２２の何れか１項記載の方法。 ２４．ガバナが、システムと通信ネットワーク間で送られる信号に応答するリー クバケットカウンタをインクリメントする請求項１５ないし２３の何れか１項記 載の方法。 ２５．通信ネットワークで使用するサービスプラットフォームであり： ａ）インバウンド呼のシグナリングを受取るネットワークインターフェイス と、 ｂ）所定の呼レート閾値でプログラムされたスタティックガバナと、 ｃ）スタティックガバナに応答し、所定の呼レート閾値に達したときにイン バウンド呼を解放するようにされている呼処理プロセッサとを含むサービスプラ ットフォーム。 ２６．ガバナが、呼の処理と関連して送られる異なる各メッセージタイプと関係 するリークバケットのインクリメント（“ドリップ"）へ異なる重み付けを与え る請求項２４記載の方法。 ２７．ガバナが、呼の処理と関連してプラットフォーム内の異なる各インターフ ェイス上でメッセージを送ることに関係するリークバケットのインクリメント（ “ドリップ"）へ異なる重み付けを与える請求項２４記載の方法。 ２８．メッセージタイプの次元とインターフェイス識別子の次元を有する重み付 けマトリックスが前記リークバケットのインクリメントに与えられ、前記マトリ ックスにおける異なるエントリが、呼に対するシグナリングの処理中に異なるボ トルネックごとに判断される値を有する、請求項２６に依存するときの請求項２ ７記載の方法。 ２９．トランザクション処理システムによる呼の処理に関係する異なるシグナリ ングイベントへ異なる重み付けを加えることによって処理される呼の現在のレー トを判断する請求項１５ないし２８の何れか１項記載の方法。 ３０．異なる重み付けが、トランザクション処理システム内の異なるシグナリン グインターフェイスを横切るシグナリングイベントへ与えられる請求項２９記載 の方法。 ３１．異なる重み付けが、異なるメッセージタイプに対応するシグナリングイベ ントに与えられる請求項２９または３０の何れか１項記載の方法。 ３２．通信ネットワークを操作する方法であって： ａ）シグナリングイベントに応答するリークバケットカウンタをインクリメ ントすることによって、ネットワーク資源のイベントレートと閾値レートとを比 較することと； ｂ）異なるシグナリングイベントにおいて段階（ａ）のインクリメントに対 して、異なるシグナリングイベントと関係するネットワーク資源へのローディン グの度合いに依存して異なる重み付けを与えることとを含む方法。 ３３．ａ）ネットワーク資源のイベントレートと閾値レートとを比較するカウン タを使用して、シグナリングイベントに応答してインクリメントするようにされ ているリークバケットカウンタと； ｂ）異なるシグナリングイベントごとにリークバケットのインクリメントに 対して異なる重み付けを与え、重み付けが異なるシグナリングイベントと関係す るネットワーク資源のローディングの度合いに依存する手段とを含む通信ネット ワークで使用するプラットフォーム。 ３４．メッセージタイプ、インターフェイスの指標、およびボトルネックの指標 の次元を有する３次元重み付けマトリックスを与えることを含む請求項２４、お よび２６ないし３２の何れか１項記載の方法。