JP2001526876A - インテリジェントネットワークをシミュレーションするためのシミュレータ - Google Patents

Abstract

(57)【要約】 本発明は、１つのインテリジェントネットワーク（ＩＮ）のパフォーマンスをシミュレートするための、以下の構成要素を持つシミュレータに関する。１．トラヒック理論にそって任意のＩＮ型事象列（トラヒックシミュレータ）をシミュレートするための１つのモジュール（２０１，３０１，４０１）、２．プロセスモジュールを使って行うサービス制御ポイントの事象指向シミュレーション（ＳＣＰシミュレータ）のための１つのモジュール（２０２，３０２，４０２）、３．モジュール間のデータ受け渡しのための装置（２０３，２０４，３０４−３０７，４０６−４０９）、４．ネットワークコンフィギュレーション、通信サービス仕様、およびその他のシミュレーションパラメータの入力と保存のため、ならびに対応するモジュールへそれらを渡すための装置（２０７，３１１，４１６，２０８−２１２，３１２−３１７，４１１−４１５）、５．シミュレートされたデータの出力および／または保存のための装置（２０５−２０７，３０８−３１０，４１７−４２０，４２３）。その他にＳＳ７符号化システムのシミュレーションのためのモジュール（３０３，４０３，５０３，４０４，５０２）が、好適には、サービス中継ポイントＳＲＰ（１０３）の機能を考慮しながら、ＩＮ内部の過負荷防御メカニズムによって設定されている。シミュレーションモジュールはデータファイルモードで伝達データファイルを介して、またはオンラインモードで共通の組織プログラムを介して、オンラインシミュレータに接続されている。オンラインモードでのシミュレータの中央要素は事象カレンダーであり、その中にはシミュレーションモジュールが処理する事象が処理の順番で登録されており、実際には平行に進行するプロセスを連続処理することをが可能になる。本発明のＩＮシミュレータにより、現在実現されるＩＮ、および将来実現されるＩＮのパフォーマンスを有利に算定できるようになり、その結果弱点ポイントが見つけ出され、ＩＮの効率が向上する。

Description

【発明の詳細な説明】 インテリジェントネットワークをシミュレーションするためのシミュレータ 技術分野 本発明は、インテリジェントネットワークのシミュレーションに関し、特に弱 点ポイントの発見と分析のため、通信網コンフィギュレーションおよび／または 制御メカニズムの試験のため、および通信網の性能を向上させる方法を発見する ためのシミュレータに関する。 発明の背景 インテリジェントネットワーク（ＩＮ）という概念は、すべての電気通信網に 世界的に適用される通信網アーキテクチャのコンセプトである。このコンセプト の中心的要素は、電気通信サービスの顧客用のソフトウェアで定義される個別通 信プロファイルである。ＩＮにおいては重要な機能とデータは集中化され、１つ だけのノード、または少数のノードで準備される。こうした機能とデータは、情 報、たとえば、１つのコールは、発信元、ダイヤルした番号、時刻、および／ま たはその他のパラメータに依存するＩＮ特有のコール番号でどのように処理され るか、たとえば、コールが伝送されるかどうか、どの加入者に伝送されるか、メ ッセージをコールが接続するかどうか、またはどのメッセージが接続されるか、 またはコールが計数されるかどうかといった情報に関係する。インテリジェント ネットワークによって、多くのサービスアクセスポイント（サービス交換ポイン ト、ＳＳＰ）から、データと機能のサービス制御のための１つ、またはいくつか の中央ノード（サービス制御ポイント、ＳＣＰ）への知的な、分岐したデータバ ンクアクセスが実現される。 インテリジェントネットワークはこの際、組織的には電話網を介する集中化さ れたネットワークとなり、電話網を介する構築、解除、接続のためのインテリジ ェンスを使用できる。電話網とインテリジェントネットワークとのインタフェー スはＳＳＰによって作られ、そこに、ＩＮ仕様のコール番号を持つコールが届き 、その指示に沿ってＳＣＰが伝送処理情報を受け取ると、コールが処理される。 たとえば、ＳＣＰが知らせた１つのコール番号に伝えられる。 インテリジェントネットワークでは、個別の機能複合体が別々のシステムレベ ルで実現される。ＩＮ輸送・伝送機能はＳＳＰレベル（サービス交換ポイント） で実現され、サービス制御機能とサービスデータの管理はＳＣＰレベル（サービ ス制御ポイント）で、サービス管理はサービス管理システム（ＳＭＳ）で実現さ れる。ＳＳＰレベルとＳＣＰレベルの間の通信は符号化システム７番（ＳＳ７シ ステム）を介して行われ、そのシステムを介してコール処理のためのＩＮ仕様の 情報が送られる。ＳＳ７システム内での符号化伝送とその制御は、１つ、または 複数のサービス伝送ポイント（ＳＴＰ）ないし中継ポイント（ＳＲＰ）を介して 実現される。ＳＴＰないしＳＲＰはその際、ＳＣＰとＳＳＰ間の中央符号化回路 にある情報の伝送と分配（ルーティング）に有用である。ＳＴＰないしＳＲＰは 情報の出入り口として使用できるようになり、それらはその他のネットワーク事 業者のＩＮサービスに適合し、その他のＩＮのＳＣＰによって処理されなければ ならない。１つのＩＮ情報の重要なルーティング基準はグローバルなタイトル（ ｇｌｏｂａｌ ｔｉｔｌｅ）である。ＳＴＰ／ＳＲＰレベルはその際グローバル タイトルトランスレーション（ＧＴＴ）を実現する。 ＳＳＰレベルには、ＩＮ接続を、たとえば、コール番号によって認識し、支援 する可能性がある。こうした接続の場合、その他の接続構築のためにＳＣＰに情 報を問い合わせなければならない。ＳＣＰには、サービス制御のためのプログラ ムとそれに関連する関連データが入っている。さらにＳＣＰは課金と統計的評価 のためのデータを集める。複数のＳＳＰは中央のＳＣＰにアクセスする。ＳＣＰ の上にはサービス管理システムが置かれており、これにはＩＮサービスのアドミ ニストレーションとＩＮ構成要素が入っている。 インテリジェントネットワークによって、たとえば、以下のＩＮサービスが実 現される。 テレボトム（ＴＶ）：テレボトムサービスでは、サービス加入者が自分のテレ ボトム番号でコール回数を記録することが可能になる。このサービスの１つの変 更例では、コールがあるとＳＣＰへ問い合わせがあり、もう１つの変更例では、 コールがＳＳＰで計数され、ＳＣＰへはそれぞれｋ番目のコールのときに問い合 わせがある。選んだ変更例とは無関係にＩＮシステムに入ってきた個々のＴＶコ ールが記録される。その際、アクティブなトラヒック案内プログラムに依存して 、個々のｎ番目のコールを特別に処理できる。たとえば、サービス加入者が決め た目的アドレスへ記録してからさらに伝送できる。その他のすべてのコールは記 録されてから、同様にトラヒック案内プログラムでサービス加入者が定めた１つ のメッセージの方へ進む。 フリーホン（ＦＰＨ）：フリーホンサービスではサービス利用者が「サービス 加入者」に料金無料で電話できる。全体の料金はサービス加入者が引き受ける。 ユニバーサル電話番号（ＵＮＵ）：ユニバーサル電話番号サービスでは、サー ビス加入者に単一の、地域に無関係の電話番号でどこからでも電話できる。この 種の接続料金はサービス加入者の規定に従って、発呼者だけから、または双方に 分配して徴収することができる。 テレインフォサービス（ＴＩＳ）：テレインフォサービスでは、サービス加入 者の情報提供へのアクセスへのコールが、そのメッセージ装置を介して、または 直接対話して可能になる。料金は発呼者に対して計算され、接続関連の情報を 使って、ネットワーク事業者とサービス加入者の間で分配できる。 さらにその他のサービスが考えられる。たとえば、ある顧客への１つのコール 番号によるすべてのコールを接続回線へ割り当てる代わりに顧客の所在地へ割り 当てるサービス。この意味ではモバイル無線網もインテリジェントネットワーク である。 サービス加入者はその他の特徴を利用してサービスを専門化できる。たとえば 、コール迂回（リルーティング）：ダイヤルされた加入者が電話に出ないか、ま たは話し中ならばそのコールはメッセージ装置に接続されるか、またはその他の 番号に接続される。このプロセスは規定の回数まで試行し続けることができ、そ うされなければコールは拒否される。 コール制限：コール回数が、ある時間内で、サービス加入者が決めた限度を超 えると、超過したコールは、決められたもう１つのコール番号、またはメッセー ジに導かれる。 時間依存の目標制御：コール時間が、周期的および／または一時的な時間窓（ ウィンドウ）で検査される。有効な時間窓が見つからないと、ＳＣＰがそのＩＮ コールを標準指示メッセージに導く。そうでなければ、コール目標へ、またはそ の次のサービスヘ分岐される。 発信依存の目標制御：ネットワーク発信情報をトラヒック誘導プログラムに入 っている発信情報と比べる。一致しないならば、ＳＣＰはそのコールを１つの標 準指示メッセージへ導く。そうでなければコール目標へ、またはその次のサービ スへ分岐される。 コール分配：コール分配サービスでは個別の割合を決めることができる。それ によってコールはさまざまな目的地に分配される。 コールが１つのメッセージに切り替わるとＳＳＰが架空の通信加入者として機 能する。ＳＳＰはネットワーク性能に関連する標準案内メッセージをサポートし 、それをコール目標として制御できる。個別のメッセージは問い合わせ場所の数 が制限される。問い合わせ場所すべてが占有されていると、多く計数されたコー ルは拒否される。個々のメッセージは最大聴取時間とリピート回数によって制限 される。 ほとんどのＩＮサービス、たとえば、ＦＰＨ、ＵＮＵ、ＴＩＳおよび前払いな しのＴＶについての、インテリジェントネットワークの課題は、ダイヤルしたＩ Ｎ番号がトラヒック誘導プログラムで定義されたサービスパラメータに依存して 真の番号に変換することである。これは以下の基本的流れで進められる。 １．ＳＳＰで、ダイヤルされた電話番号の第１の符号が判定され、ＩＮサービ スが認識する。ＳＳＰは、情報ＰＲＯＶＩＤＥ ＩＮＳＴＲＵＣＴＩＯＮでコー ル処理するために、ＳＣＰに１つの質問を送る。その情報にはパラメータとして 、サービス使用者がダイヤルしたＩＮ加入者コール番号（ＣＡＬＬＥＤ−ＰＡＲ ＴＹ−ＡＤＤＲＥＳＳ）とそのコールのコール番号（ＣＡＬＬＩＮＧ−ＰＡＲＴ Ｙ−ＡＤＤＲＥＳＳ）が含まれる。 ２．ＳＣＰでは、情報ＰＲＯＶＩＤＥ ＩＮＳＴＲＵＣＴＩＯＮが、対応する ＩＮサービスのためのサービス論理プログラムに働きかける。ＣＡＬＬＥＤ−Ｐ ＡＲＴＹ−ＡＤＤＲＥＳＳを介してアドレス指定された加入者特有のトラヒック 誘導プログラムが制御される。ここで説明する定格事例の場合、結果として接続 構築のための目標が決められ、それがコール番号またはメッセージになりうる。 追加的にトラヒックプログラムから接続監視のための要求、たとえば、「加入者 話し中」、「応答ありません」を監視せよとの要求が出されることがある。ＳＣ Ｐは接続特有のコンテキストでその結果を保護し、情報ＣＲＥＡＴＥ−ＪＯＩＮ およびＭＯＮＩＴＯＲをＳＳＰに送る。その情報にはパラメータとしてＣＡＬＬ ＥＤ−ＰＡＲＴＹ−ＡＤＤＲＥＳＳおよびＥＶＥＮＴＬＩＳＴが含まれ、それら は監視される事象を特殊化する。 ３．ＳＳＰでは、ＣＲＥＡＴＥ−ＪＯＩＮで渡された目標コール番号とＢ加入 者との接続構築が、電話網を介してなされるか、または１つのメッセージに切り 替えられる。 ４．このことがＥＶＥＮＴＬＩＳＴにおいて特殊化されたならば、ＳＳＰはＢ 加入者への接続構築を監視する。Ｂ加入者が反応しないならば、Ｂ加入者の方向 への接続はタイムアウトになると解消され、ＳＣＰは情報ＥＶＥＮＴで、発生し た事象を伝える。 ５．トラヒック案内プログラムから選択目標が決められ（リルーティング）、 １つの情報ＣＲＥＡＴＥ−ＪＯＩＮおよびＭＯＮＩＴＯＲが対応するパラメータ と共にＳＳＰに送られる。 ６．ＳＳＰでは、ＣＲＥＡＴＥ・ＪＯＩＮで伝えられた目標コール番号に関し て、電話網を介して、Ｂ加入者への接続構築が行われるか、または１つのメッセ ージに切り替えられる。Ｂ加入者が応答すると接続が行われる。 ７．通話の最後に、ＳＳＰでは課金と統計のために必要なデータがまとめられ 、情報ＥＶＥＮＴ（ＣＡＬＬ−ＥＮＤ）で伝送される。ＳＳＰではタイマーで、 この情報のＳＣＰによる確認が監視される。タイマーが終わるまでに確認されな いと情報ＥＶＥＮＴ（ＣＡＬＬ−ＥＮＤ）の送信が繰り返される。 ８．情報ＥＶＥＮＴ（ＣＡＬＬ−ＥＮＤ）が受信されると、ＳＣＰはＴＣＡＰ ダイアログを終了するための情報を送る。ＳＣＰでは、接続特有のコンテキスト が再びアクティブになる。受信されたタイムスタンプは、コンテキストに残され ているデータと共に保存される（コールチケット）。それはその後ＳＭＳに送ら れ、さらに処理される。ＳＣＰでは（たとえば、成功したコールに関して）導か れたカウンタが、高く計数される（カウンタチケット）。 こうした流れになると、４項、５項および６項はリルーティングの場合にのみ 行われる。 高いトラヒックのある場合も、ＩＮの正常な運転を確実に行うために、ＩＮの 内部で過負荷防御メカニズムが準備される。過負荷防御によって、ＳＳＰは一定 の条件に沿ってＩＮコールをＳＣＰへ問い合わせしないで拒否する。過負荷防御 メカニズムの例はＡＵＴＯＭＡＴＩＣ−ＣＡＬＬ−ＧＡＰＰＩＮＧ（ＡＣＧ）、 またはＬＥＡＫＹ−ＢＵＣＫＥＴ方式である。サービス依存の、および／または 目標依存の過負荷防御が可能である。 サービス制御ポイントは、通常は１つのハードウェア基盤および、複数の、通 常は３つのレイヤを持つ多層システムである。ハードウェア基盤は、接続導線、 固定プレート、磁気バンド、端末およびプリンタ付きの、１つまたは複数の並列 して動作するプロセッサを有する１つのコンピュータで構成される。第１のソフ トウェアレイヤにはシステムソフトウェアが含まれる。第２のソフトウェアレイ ヤ（ＮＯＤＥソフトウェア）にはサービスアプリケーション用の一般的機能が含 まれる。第３のソフトウェアレイヤはコール処理するサービスを支援するアプリ ケーションで構成される。ＳＣＰの並列処理アーキテクチャの場合、複数のプロ セッサが付いており、それらはＣＰＵ、主記憶装置、電源および入出力プロセッ サを持つ独立ユニットになり、バスシステムと相互に結び付いている。 さまざまなＳＣＰソフトウェアレイヤには、運転システムプロセッサおよび一 般的なプロセッサのほかに、運転システムに直接的には帰属しないプロセッサ、 たとえば、プロセッサ相互間の通信のための、またはローカルな記憶装置の効果 的な管理のためのプロセッサ、アプリケーションプロセッサが含まれており、そ れらはＩＮ情報の処理のために必要である。ＳＣＰに届くＩＮ情報はＳＣＰのさ まざまなレイヤを通過し、それがコール処理するための問い合わせに対する答え になるＳＣＰからＳＳＰへのＩＮ情報である。そのプロセスは、サービス依存、 および／またはサービス加入者依存になることがあり、またはそれとは無関係に 全体のＩＮ情報によって利用できる。そのプロセスは、ＳＣＰのすべての、ない し選ばれたプロセッサにおいて１つまたは複数のインカーネーション（体現）で 実行される。 ＳＣＰでのＩＮ情報の処理は基本的には以下の図式で進められ、個別プロセス の規定されたチェーンを呼び出すことによって実現される。 ＳＳＰからの１つの情報が受信され、ＳＣＰ計算機に送られる。ＳＣＰ計算機 はその情報を受け取り、記億装置が使用できるようになり、情報の有効エリアが 検証される。コール処理のためのコンテキストが作られる。１つのルーチンツリ ーが作業記憶装置から、または固定プレートからロードされる。ルーチンツリー から選ぶべきコール番号が決められる。コールのためのコンテキストが保存され 、ＳＳＰへの答えが作られる。答えは新しいＩＮ情報としてＳＳＰへ送られる ＩＮコールを処理するために必要なすべてのプロセスは、１つのプロセッサだ けに合わせて起動され、その際、それまでのプロセスは、次のプロセスを起動で きるようになる前に終了していなければならない。 接続がＳＳＰへの交換局によって解消されると、接続終了処理が発呼者によっ て、先に説明した接続構築処理に対してアナログで、対応するプロセスチェーン によってなされる。 ＩＮ情報の処理は、ＳＴＰ／ＳＲＰで、同様に連続するプロセスの規定された チェーンを処理することによって行われる。 技術的課題： 現在のＩＮネットワーク、特にその中央の構成要素ＳＣＰで計測する場合、高 い平均的処理時間が観察された。このことはＩＮトラヒックによるシステムの負 荷が高い場合に、受容できないような長い接続構築時間、特にテレボトムサービ スのピーク時間を導くが、それはその他の影響によっても引き起こされることも ある。しかし、そうした高い応答時間を導くようなＩＮネットワークの弱点ポイ ントの分析には、問題が多い。なぜなら測定値は統計データであり、情報処理の それぞれの段階で必ずしも測定できないからである。さらに、真のＩＮでの測定 の場合、すべての真のデータファイル測定が、検査されるシステムのパフォーマ ンスに、正規のＩＮコール処理には帰属しない追加測定プロセスが活発化される ことによって、影響を与えるという基本的な問題がある。 既存のＩＮに新しい構成要素を入れる場合は、さらにもう１つの問題が生じる 。ＩＮはそれぞれの時点で運転状態になっており、こうした複合システムでのパ ラメータ変更は運転安全性を危険にする可能性を伴う。さらに現在のところ、た とえば、特定の技術仕様を持つプロセッサが製造者が保証した性能を実際に示す かどうかは確かめられない。 既存のインテリジェントネットワークの弱点ポイントを分析することが必要で あり、そのほかに、まだ実現されていないネットワークコンフィギュレーション をプランニングスタディーにおいて試験し、所与の条件内で最善のパフォーマン スを持つコンフィギュレーションを確かめる必要がある。たとえば、ＳＣＰ計算 機ないし個別プロセッサにはどんな性能がなければならないか、またはどの程度 の容量が必要か、場合によっては個別サービスに関してどんな形で準備されなけ ればならないかが問われる。さらに、ＩＮのプロセッサ内部でプロセス管理を変 えることによって、より良いパフォーマンスが達成可能かどうか、またはどのよ うにして達成できるかが問題になる。そのほかに、インテリジェントネットワー クを運転する際の重要な要素は過負荷防御であり、これによってシステムを出力 限度にできるだけ近づけて安定させなければならない。対応する過負荷防御パラ メータの算定は実際には困難なので、その他のネットワークコンフィギュレーシ ョンに依存する過負荷防御の最適な調整値を、ネットワーク運転とは無関係に求 め、真のネットワークに伝送することが必要である。 本発明の基礎は、それゆえ、ＩＮ構造の通信網のパフォーマンスを算定するた めの１つのツールを利用できるようにすることである。その際、ユーザは、ネッ トワークコンフィギュレーションならびにネットワーク構成要素内部でのコール 処理方式を指示し、変更することができる。シミュレーションも、選んだＩＮプ ラットフォームとは無関係に行える。ネットワークのパフォーマンスに関する統 計データが作られ、真のＩＮ構成要素で測定されたデータとの比較が可能になり 、真のネットワークではアクセスできないそうしたデータも利用できるようにな り、インテリジェントネットワークを通過する際の処理時間のコール特有の（特 殊化された）プロトコル化がなされる。 本発明の公開とその長所： 課題は、以下の構成要素を持つインテリジェントネットワークの（ＩＮ）のパ フォーマンスをシミュレートするための本発明のシミュレータで解決される。 １．トラヒック理論に沿った任意のＩＮ型の事象列をシミュレートするための １つのモジュール（トラヒックシミュレータ）。 ２．プロセスモデルを使ったサービス制御ポイント（ＳＣＰシミュレータ）の 事象指向のシミュレーションのための１つのモジュール。 ３．モジュール間のデータ伝送手段。 ４．ネットワークコンフィギュレーション、通信サービス仕様、およびその他 のシミュレーションパラメータの保存と入力、ならびにそれを、対応するモ ジュールへ伝送するための手段。 ５．シミュレートされたデータの出力および／または保存のための手段。 インテリジェントネットワークのパフォーマンス不足は、その中央化された構 造のためであり、中央のＳＣＰでその原因が探されることが多いので、シミュレ ータの中心部分のＳＣＰがモデル化される。待ち行列モデル／プロセスモデルに よって、ＳＣＰのソフトウェア構造の詳細なモデル化を実現できる。その他のモ ジュール、トラヒックシミュレーターはＩＮシミュレーターでは、ＩＮ特有の負 荷を生成し、ＳＣＰシミュレーターのための実際の入力を作り出すために必要で ある。 シミュレータの中心部分はコンピュータプログラムによって実現される。この プログラムはスタート時に、またはシミュレーション中に、データファイルにア クセスし、そのデータファイルに、ネットワークないしネットワーク構成要素の コンフィギュレーションのための、ないし通信サービスの特殊化のためのパラメ ータ、つまり、コール処理の方式、流れおよびその他のシミュレーション流れに 関係するパラメータ、たとえば、トラヒック発生に関するステートメントが保存 される。こうしたデータファイルに、ユーザは既知の方法で書き込みと変更を行 える。好適には、シミュレーションパラメータはコンピュータのディスプレイと キーボードを使って入力される。シミュレーションパラメータは保存され、新し いシミュレーションが終了する前に、個別に、または全体を変えることができる ので、個別パラメータが、シミュレートされるＩＮパーフォーマンスに及ぼす作 用を分析することができる。 使われるシミュレーション方式はいわゆる事象制御シミュレーションに対応す る。特別の時間に関してＩＮ特有の事象が生成され、その事象は処理のために、 シミュレータの個別構成要素を通過する。個別のシミュレーションモジュールに おける処理時間、場合によってはシミュレーションモジュールの下部構成要素に おける処理時間も一緒にプロトコル化される。 好適には、ＩＮシミュレータは基本構成要素、ＳＣＰシミュレータおよびトラ ヒックシミュレータのほかに、符号化システム７番の、事象指向シミュレーショ ンのための１つのモジュールを有する。このＳＳ７シミュレータは、待ち合わせ モデルを基礎にして動作する。ただし、機能性がＳＳ７に統合されたプロセッサ を模倣し、および／または１つの情報に一定の遅延時間が刻印され、それがＳＳ ＰとＳＣＰの間の符号化回路での最終的な運転時間を考慮する。ＳＳ７シミュレ ータ内部でシミュレートされる構成要素はＳＳＰレベル、ＳＴＰ／ＳＲＰレベル 、およびネットワークコンフィギュレーションに沿った個々のＳＣＰレベルのプ ロセッサ／プロセスチェーン、たとえば、１つのＳＣＰ入力プロセッサ（ＦＲＯ ＮＴ ＥＮＤ ＳＹＳＴＥＭ）であり、それは符号化システムのためのインタフ ェースになる。 本発明のその他の有利な実施例では、過負荷防御メカニズムによるシミュレー ションのための１つのモジュールが準備される。この過負荷防御シミュレータは 、その他の１つ以上のシミュレーションモジュールで処理される事象の個数を、 １つまたは複数のシミュレーションモジュールのロードに依存して、たとえば、 待ち行列長さおよび／またはユーザ定義可能なパラメータに依存して、修正する 。ユーザ定義のパラメータは、たとえば、負荷限度であり、それを超えると過負 荷防御がアクティブになる。確定された限度の代わりに「穏やかな」判定を設定 することもできる。たとえば、ファジー論理を使う。現実の特性に最適に対応す るのは過負荷防御シミュレータであり、これはＳＣＰシミュレータから制御パラ メータを受け取り、トラヒックシミュレータにアクセスし、それによって作られ た、または伝えられたＩＮ事象の個数を制御パラメータに依存して制御する。過 負荷防御がなされると、トラヒックシミュレータによって最初に作られるコール は、ＳＳＰからＳＣＰへの問い合わせに対応するＩＮ事象にはほとんど変換され ない。つまりその他のシミュレーションモデルには伝えられない。実際にはこれ はＳＳＰが拒否したコールになる。 好適には、過負荷防御シミュレータは、Ａｕｔｏｍａｔｉｃ Ｃａｌｌ Ｇａ ｐｐｉｎｇ（ＡＣＧ）のメカニズムを模倣する。その際、一定の時間間隔で一定 の回数を超えて出されたコール／事象は拒否される。 モジュール・トラヒックシミュレータ、ＳＣＰシミュレータ、場合によっては ＳＳ７シミュレータ、ならびに過負荷防御シミュレータは、対応するネットワー ク構成要素の独自のシミュレータである。それらの機能はデータファイルを介し て結合されるか（データファイルモード）、または、好適には、組織プログラム を介して統合され（オンラインモード）、それによって、ＩＮシミュレータのす べての構成要素による個別のＩＮ事象の処理が保証される。 データファイルモードで、データファイルへの書き込みないし読み取りアクセ スの形で、シミュレーションモジュール間の通信がなされ、データファイルには 、ネットワークのコンフィギュレーション、ないしシミュレートされるネットワ ーク構成要素に関するデータ、場合によってはシミュレーションモジュールが作 るデータも預けられている。 ネットワークの完全なシミュレーションを行うためには、部分シミュレーショ ンを次々に呼び出さなければならない。シミュレーション流れは、トラヒックシ ミュレータによってＩＮでのトラヒック発生が生成されるときに始まる。生成さ れた情報（作成時間ｔ１で、ＰＲＯＶＩＤＥ ＩＮＳＴＲＵＣＴＩＯＮがＥＶＥ ＮＴまたはＣＡＬＬ ＥＮＤになる）は、第１の伝達データファイルに保存され 、続いて呼び出されたシミュレーションモジュールがそれを読み取る。それぞれ の 情報に関してコール識別番号が保存されており、それによって、１つのコールに 複数の情報が割り当てられ、コール特有の応答時間が定められるようになる。 シミュレータの最も簡単なバージョンでは、この２番目のシミュレーションモ ジュールはＳＣＰシミュレータである。ＳＳ７を考慮する場合、第１のデータフ ァイルはＳＳ７シミュレータに伝えられる。この場合、ＳＳ７シミュレータ通過 後の情報がＳＳ７出力時点ｔ２で補完され、第２の伝達データファイルに書き込 まれ、そこへＳＣＰシミュレータがアクセスする。ＳＣＰシミュレータは伝えら れたデータファイルに存在するそれぞれの登録に関して、情報ＣＲＥＡＴＥ −ＪＯＩＮまたはＣＡＬＬ ＥＮＤを作りだし、これを出力時間ｔ３で第３の データファイルに書きこむ。情報がＳＳＰに届く前に、場合によっては再度ＳＳ ７シミュレータに通され、その際ＳＳ７出力時点ｔ４がプロトコル化される。 シミュレーションモジュールの伝達データファイルからプロトコル化された時 間ラベルの差分を作ることによって、個別のネットワーク構成要素での、および 全体ネットワークでの遅延時間が算定できる。 部分シミュレーションの連続運転によって、ネットワーク構成要素間のフィー ドバックが接続解除されるので、実際のネットワークの機能性を模倣するという 状態を保持するために、上記の行程を複数回、通過しなければならない。 データファイル運転は個別のネットワーク構成要素の特性を、ネットワークと は別に、つまりフィードバックなしに検証するのに適している。個別構成要素の 特性は、たとえば、対応するシミュレーションパラメータの変更によってすばや く、直接、確かめられる。その際、個別のＩＮ構成要素は別々に変更でき、分析 できる。データファイルモードでは、構成要素間の個別ＥＶＥＮＴをフォローす ることが容易である。しかし、全体システムの静的特性はデータファイルモード の適切な初期条件で反復して算定する。 オンラインモードでは組織プログラムによって、部分シミュレーションが準並 行に進行するようにする。それによってシミュレータはネットワークを全体とし てシミュレートできるようになり、その際、特に構成要素間のフィードバックも 直接考慮される。実際に平行に進められるネットワーク構成要素の情報処理を、 シミュレーションモジュールでのＩＮ事象の連続処理ないし準並行処理に変える ことは事象カレンダーによって実現される。事象カレンダーは、１つの要素、た とえば、シミュレータ、シミュレーションモジュールまたは、処理される事象、 たとえば、ＩＮ情報または個別プロセスの１つのモジュールの１つの部分構成要 素のすべてのリストであり、それらは年代順にこのリストに登録される。事象カ レンダーによってオンラインシミュレータは、どの事象が次に処理されるべきか を決める（事象指向のシミュレータ）。次の事象の開始時刻は、開始時刻とそれ 以前の事象の持続時間の和になる。シミュレーションモジュールの準並行運転を 実現する場合、中心的役割を果たすのは大域事象カレンダーであり、それにはシ ミュレーションモジュールによって処理される事象を年代準に含まれる。大域事 象カレンダーを使って、シミュレータはどの部分シミュレータがどのシミュレー ション時刻で呼び出されるかを決める。大域事象カレンダーのほかにローカルな 事象カレンダーもあり、これはシミュレーションモジュールによって導かれる。 大域事象カレンダーでは以下のようなグループの事象が登録される。 内的事象：内的事象は対応するシミュレーションモジュールのローカルカレン ダーへの指示である。それは１つの個別のシミュレーションステップ分だけ１つ のシミュレーションモジュールを接続することに関連する。 外的事象：外的事象は１つのＩＮ情報の１つの部分シミュレーションへの入力 を表わし、それらはシミュレーション構成要素間で送られる情報であり、シミュ レーション構成要素の相互の通信に有用である。 コール依存の事象：本発明を発展させるとそうした事象も、ＩＮ事象から独立 しており、たとえば、部分構成要素での運転システムのシミュレーションに帰属 する大域カレンダーに登録される。 すべての事象は基本的にはそれぞれのシミュレーションモジュールに１つの続 き事象を生成させ、それは大域事象カレンダーに、条件によってはローカルな事 象カレンダーにも登録される。いくつかの事象は処理の後にプロトコル化を指示 し、それを使って、１つの情報がそれぞれのシミュレーションモジュールによっ ていかに早く処理されたかが追体験できる。 ＩＮシミュレーシータの機能を、ユーザは、好適には、ユーザレベルから使用 できる。このレベルは、１つまたは複数のシミュレーションの管理を引き受け、 そこでは個別シミュレーションモジュールのシミュレーションパラメータを入力 するための入力マスクが準備され、それは入力されたデータを対応するデータフ ァイルに入れ、シミュレーション関連で保存する。新しいシミュレーションの生 成は選んだパラメータのコピーと修正によって、ユーザが行うことができる。ユ ーザレベルにはさらに、コンフィギュレーションデータファイルと結果データフ ァイルの個々のシミュレーションに帰属するシステムの独立したデータファイル 管理が含まれる。ユーザは、全体的にシミュレータされたデータを提示させるこ とができる。ユーザが選んだ「測定量」、たとえば、ＳＣＰの負荷、ＳＣＰでの 待ち行列長さ、ＩＮでのトラヒック発生がグラフィックプログラムを使って準備 され、グラフィックとしてコンピュータのディスプレイに表示される。好適には 、１つのシミュレーションおよび異なるシミュレーションのシミュレーション結 果を一緒にディスプレイに表示できる。さらに好適には、データフィルターを介 して、その他のプログラムで処理するための出力ファイルを作ることも可能であ る。 図の説明 図１は、インテリジェントネットワークのトポロジーを示す。 図２および図３は、データファイルモードで運転されるシミュレータの本発明 に沿った構造を示す。 図４は、データファイルモードおよびオンラインモードで運転できるシミュレ ータの本発明に沿った構造を示す。 図５は、ＩＮシミュレータの基本構造を示す。 図６は、トラヒックシミュレータのコンフィギュレーションパラメータの例を 示す。 図７は、データモードでの基本的なシミュレーション流れを示す。 図８は、オンラインモードでの基本的なシミュレーション流れを示す。 図９は、オンラインシミュレーションの視点による大域内的事象の処理図式を 示す。 図１０は、ＳＣＰシミュレーションの基本を示す。 図１１は、ＳＣＰシミュレータのコンフィギュレーションの例を示す。 図１２、図１３は、ＣＰＵプロセス管理の、ＳＣＰシミュレーションに基礎を 置くモデルを示す。 図１４は、ＳＣＰシミュレータの図式的、オブジェクト指向モデルを示す。 図１５は、ＳＳ７層の配置を示す。 図１６は、ＳＲＰのＭＴＰ３レベルのモデル化を示す。 図１７は、ＳＳ７のＴＣＡＰ層のモデル化を示す。 図１８は、ＳＳ７シミュレータのコンフィギュレーションパラメータの例を示 す。 図１９は、オンラインモードでのＩＮシミュレータへの過負荷防御シミュレー タのインプリメンテーションを示す。 図２０は、過負荷防御シミュレータのデータファイルモードでのＩＮシミュレ ータへのインプリメンテーションを示す。 図２１、図２２、図２３は、ＩＮシミュレータで算定されるシミュレーション データの例を示す。 本発明を実施するための方法 図１はシミュレーションコンセプトを表わすためのインテリジェントネットワ ークのトポロジーを示す。インテリジェントネットワークは実質的には３つの論 理的構成要素、つまりサービス制御ポイント（ＳＣＰ）１０９、サービス交換ポ イント（ＳＳＰ）１０２、および信号伝送ポイントないし信号中継ポイント（Ｓ ＴＰないしＳＲＰ）１０３で構成される。ＳＳＰレベルは外部機器とみなされる 顧客機器の信号化要求を、電話網の交換局１０１の１つを介して受け取り、そう したＩＮ特有の接続のための接続構築を行う。 ＳＣＰレベルにはコール判定と接続管理のための手順とデータバンクが含まれ る。こうした情報は電話網を介する接続のための回路を見つけるのに有用である 。ＳＣＰないしＳＲＰは、ＳＣＰ とＳＳＰの間の伝送機能を引き受ける。構成 要素ＳＳＰ、ＳＣＰおよびＳＴＰ／ＳＲＰ間の通信は符号化システム７番（ＳＳ ７）を経て行われる。そのために基本的にはＳＴＰ／ＳＲＰとＳＳＰないしＳＴ Ｐ間の複数の符号化回路１０６、１０７、１０８が設けられる。 原則的には３つの論理的な構成要素ＳＳＰ、ＳＣＰおよびＳＴＰ／ＳＲＰを１ つの物理的機器、たとえば、１つの交換局に統合できる。しかし基本は図１に示 した中央のＳＣＰ１０９インテリジェントネットワークのピラミッド型構造であ り、それには、ＳＳ７システムの情報ノードになる複数のＳＳＰ１０２、および いくつかのＳＴＲ／ＳＲＰ１０３の中央ＳＣＰが付いている。電話網の交換局と ＳＳＰのそれとの間に物理的有効回路１０５があり、これを経て電話網接続を構 築できる。ＩＮ特有のコール番号でのコールは、まず基本的にはＳＳＰへ伝えら れ、ＳＳＰはＳＣＰから処理情報を受け取るとその接続をそれぞれの目標へさら に伝える。ＳＳＰは電話網とインテリジェントネットワークの間のインタフェー スである。ＳＳＰ機能を直接、交換局に統合することもできる。 ＩＮシミュレーションの枠内で、ＳＳＰからインテリジェントネットワークに 届けられたＩＮトラヒックは、トラヒックシミュレータでシミュレートされ、Ｓ ＣＰの機能はＳＣＰシミュレータによってモデル化され、ＳＳ７シミュレータは ＳＳＰ、ＳＴＰ／ＳＲＰ、ＳＣＰ入力プロセッサ１０４およびこれらの構成要素 間の接続回線の機能をモデル化する。シミュレータを使用する者は、ネットワー クコンフィギュレーションのための入力の枠内でネットワークトポロジーを自由 に選び、シミュレートされたネットワークの構造を任意の基準に合わせることが できる。ユーザ定義のシミュレーションパラメータは、ＳＳＰ１０２の個数、Ｓ ＴＰ／ＳＲＰ１０３の個数、ＳＣＰ入力プロセッサ１０４の個数、ＳＴＰ／ＳＲ ＰおよびＳＣＰないしＳＳＰの間の符号回路の個数であり、場合によってはＳＣ Ｐの個数も含まれる。 図２は、本発明に沿ったデータファイルモードで運転されるＩＮシミュレータ の構造、シミュレーションモジュール、トラヒックシミュレータ２０１、および ＳＣＰシミュレータ２０２を示す。トラヒックシミュレータ２０１は、入力デー タファイル２０８、２０９、２１０、２１１、２１２に預けられているユーザス テートメントに沿って、場合によっては伝達データファイル２０４に保存されて いるデータを考慮しながら、ＩＮ特有のトラヒック発生、つまり一連の事象を生 成する。これはＳＣＰへの、１つまたは複数のＳＳＰのＩＮ情報になる。入力デ ータファイル２０８から２１２に、ユーザは、好適には、共通のユーザレベル を経てアクセスでき、トラヒックシミュレータ２０１がシミュレーション開始時 にそれを読みこむ。入力データファイル２０８から２１２には、シミュレーショ ンのそのつど異なる様態に関係する、たとえば、ＩＮネットワークと電話網の間 のインタフェースの領域のネットワークコンフィギュレーション（ＳＳＰ個数） 、ＳＳＰの内的調整（サービス、タイムアウトまでの時間ごとにメッセージ場所 の数、回線数）、確率に関係するコールのその他の運命（平均通話時間および／ またはメッセージ時間、最大メッセージ時間、方向転換確率）、１つまたは複数 の連続インターバルに関する、時間単位とサービスごとのコール平均回数のステ ートメントに関係するパラメータが含まれる。入力データファイル２０８から２ １２の個数は無作為であり、たとえば、全体のユーザステートメントが、その他 のシミュレーションモジュールに関連するものであっても、任意の数のデータフ ァイルに、たとえただ１つのデータファイルであっても、それに保存できること は自明である。 ここに提示する例では、ＳＣＰシミュレータ２０２はＳＣＰ入力データファイ ル２０７をもち、そのなかでＳＣＰコンフィギュレーションに関するユーザステ ートメントが保存され、それをＳＣＰシミュレータ２０２がシミュレーション開 始時に読む。 データファイルモードでは、モジュール・トラヒックシミュレータ２０１とＳ ＣＰシミュレータ２０２が続いて運転される。トラヒックシミュレータが作り出 す事象列は第１の伝達データファイル２０３に書き込まれ、それにはさらにＳＣ Ｐシミュレータ２０２によって処理された事象列が含まれる。次の段階ではＳＣ Ｐシミュレータがこの伝達データファイル２０３を読み、その中に保存されてい た事象を処理する。処理された事象はＳＣＰシミュレータ２０２によって第２の 伝達データファイル２０４に登録される。これはこのシミュレーションでは再度 トラヒックシミュレータ２０１に伝達されるが、第１の伝達データファイル２０ ３のように直接、判定のために送ることもできる。 伝達データファイルは内容的にはそれぞれの受信モジュールの事象カレンダー である。伝達データファイル２０３、２０４には、トラヒックシミュレータ２０ １、ないしＳＣＰシミュレータ２０２が作ったデータがデータセットとして保存 され、そのデータセットは、トラヒックシミュレータでの対応する情報、ないし ＳＣＰシミュレータでの情報の作成時間を知らせる１つ以上の時間ラベル、およ び、２つの情報、ないしそれ以上の情報を１つのコールに帰属するものとして配 置することを可能にする１つの識別番号を含む。２つの時間ラベルの差分はＳＣ Ｐでの情報処理時間を示す。それゆえ図２に示すシミュレータは、与えられたト ラヒック発生に対するＳＣＰの反応を直接シミュレートする。符号化システム７ 番はその際考慮されない。 シミュレーションモジュール２０１、２０２は、さらに、統計データ、たとえ ば、ＳＣＰのプロセッサロード、ＳＣＰの待ち行列長さ、または、ＳＳＰから、 およびＳＳＰへの回線ロードに関する統計データを、出力データファイル２０５ 、２０６に納める。その中に記録されたデータもシミュレーション結果判定に使 われる。 図３は、データファイルモードで運転される本発明のシミュレータの構造を示 す。このシミュレータには、シミュレーションモジュールのトラヒックシミュレ ータ３０１、ＳＳ７シミュレータ３０３、およびＳＣＰシミュレータ３０２が付 いている。図２のシミュレータに比べると、図３のシミュレータはモジュールＳ Ｓ７シミュレータ３０３が増えているだけである。その結果、部分シミュレーシ ョンを連続処理する際にモジュール間で４つの伝達データファイル３０４、３０ ５、３０６、３０７が受け渡される。 インテリジェントネットワークのシミュレーションは上述のように、１つのＩ Ｎ特有のトラヒック発生が生成される時に始まる。トラヒックシミュレータ３０ １は、図２のデータファイル２０８〜２１２に対応する入力データファイル３１ ２〜３１６を読み、伝達データファイル３０７があるなら、それも読みこまれる 。トラヒックシミュレータ３０１が生成した事象列は第１伝達データファイル３ ０４に保存される。次にＳＳ７シミュレータ３０３が呼び出される。このシミュ レータはまずＳＳ７入力データファイル３１７を読み込む。その中には、たとえ ば、ＳＳ７システムのコンフィギュレーションに関するデータが保存されている 。ＳＳ７シミュレータ３０３はそれ自身が処理した事象列を第２伝達データファ イル３０５に保存し、それはＳＣＰシミュレータ３０２によって、その呼び出し 時に読みこまれる。ＳＣＰシミュレータ３０２が処理した事象列は、１つの伝達 データファイル３０６に登録される。ＩＮ情報のＳＣＰからＳＳＰへの戻りをシ ミュレートするために、ＳＳ７シミュレータ３０３があらためて活発化され、第 ３伝達データファイル３０６に保存されていた事象列が処理され、結果が第４伝 達データファイル３０７に納められる。必要ならば、再度トラヒックシミュレー タ３０１が活発化され、ＳＳ７シミュレータ、ＳＣＰシミュレータ、ＳＳ７シミ ュレータというサイクルがあらてめて繰り返されると、ネットワーク構成要素間 のフィードバックがシミュレートされる。その反復は、１つまたは複数の伝達デ ータファイル３０４〜３０７（ないし上記の２０３、２０４）におけるトラヒッ クデータの変更が、ユーザが受け入れられる基準を下回り、システムが一過性の 状態になるまで続けられる。 個別シミュレーションモジュール３０１、３０２、３０３に関する統計データ は、出力データファイル３０９、３０８ないし３１０に書き込まれる。ＳＳ７シ ミュレーションに関する統計データは、たとえば、ＳＲＰプロセッサのロードま たはＳＲＰからＳＣＰへの回線ないしＳＳＰへの占有された回線の数である。 伝達データファイルに預けられたデータは、コール特有のデータセットであり 、これは少なくとも１つの時間ラベルを含む。これらの時間ラベルは、対応する シミュレーションモジュールでのそれに帰属する情報を作成ないし処理する時に 、実際のシミュレーション時間から作られる。差分を作ることによって、それぞ れのシミュレートされたネットワーク構成要素での処理時間が計算される。 図４は、データファイルモードないしオンラインモードで運転される本発明の シミュレータの構造を示す。このシミュレータは、図３ですでに示し、説明した シミュレーションモジュールのトラヒックシミュレータ４０１、ＳＳ７シミュレ ータ４０３およびＳＣＰシミュレータ４０２を有する。これらは上述のように、 伝達データファイル４０６、４０７、４０８、４０９を介して通信する。 図３のシミュレータとは異なり、ここに説明するシミュレータには過負荷防御 シミュレーションのためのモジュール４０４が含まれている。このモジュールは 、トラヒックシミュレータ４０１の生成した、ないし伝えた事象列をデータファ イル４２２に保存された一定のユーザ定義のパラメータ、およびその他のシミュ レーションモジュールのロードに依存して制御する。 シミュレーションモジュール４０１、４０２、４０３、４０４は共通の組織プ ログラム・オンラインシミュレータ４０５を介して結合される。さらにユーザレ ベル４１０があり、これはすべての構成要素と、つまりシミュレーションモジュ ールと直接、単一方向接続または双方向接続されている。そのほかにユーザレベ ルとシミュレーションモジュールは間接的に、データファイル４１１から４１４ まで（トラヒックシミュレータ４０１用の入力データファイル）、４１５（ＳＳ ７入力データファイル）、４１６および４２３（ＳＣＰ入出力データファイル） 、４１７から４２０（オンラインシミュレータ４０５の出力データファイ ル）を介して接続され、それらを経てモジュールをコンフィギュレートし、算出 されたシステムデータをも読み出すことができる。図４の破線の矢印は、図２、 図３でも示したようなデータファイル演算を示す。まっすぐの矢印は直接通信を 意味する。たとえば、共通の組織プログラムでの結合による通信を示す。矢印は 、パラメータまたは情報をその他のシミュレーション部分に渡すような構成要素 から出ている。 図４に示したシミュレータでは、個別シミュレーションモジュールの連続コー ルでのデータファイル運転も、オンライン運転も可能であり、その場合、シミュ レーションモジュールは準並行に動作する。 ユーザレベルはトラヒックシミュレータ、ＳＳ７シミュレータ、およびＳＣＰ シミュレータと接続している。それぞれのシミュレーションは、対応するシミュ レーションパラメータが渡されるユーザレベルからスタートする。データファイ ルモードの場合、部分システムは呼び出されると自立したプログラムとして、レ べルとは無関係に、かつ、インタラタションなしでスタートする。 ユーザレベル４１０とオンラインシミュレータ４０５が双方向接続されている ため、一方では対応するパラメータ伝達によるシミュレーションスタートが可能 になり、他方では「測定データ」から、進行中に（オンラインモード）グラフィ ッタステートメントへのフィードバックが可能になる。さらにユーザはシミュレ ーション流れを一時的に中断するか、または早めに終了することができる。 シミュレーションモジュール４０１、４０２、４０３、および４０４はプログ ラミング技術でオンラインシミュレータ４０５に統合され、それは部分シミュレ ーションの準並行の流れを、大域事象カレンダーで管理される情報の送受信によ って制御する。オンライン運転では、モジュール・トラフィッタシミュレータ４ ０１、ＳＳ７シミュレータ４０３およびＳＣＰシミュレータ４０２相互間の全 体の通信プロセスは、オンラインシミュレータ４０５を介して行われる。伝達デ ータファイル４０６から４０９はオンラインモードでは直接には使用されない。 しかし、間接的にローカルな事象カレンダーでは見つけられる。 オンラインシミュレータ４０５は、あらかじめ決められるプロトコルの大きさ の登録を指示する。たとえば、上述の時間ラベルｔ１からｔ４まで、ＳＣＰロー ド、ネットワークロードのためにデータ、占有される回線数が、プロトコルデー タファイル４１７、４１８、４１９、４２０に登録される。そこに保存されたデ ータは、既知の方法でユーザレベルで出力可能であり、目で見られるようになる 。 過負荷防御メカニズムが、ＩＮに届くトラヒックをフィードバックによって制 御するので、過負荷防御メカニズムによるシミュレーションはほとんどの場合、 オンラインモジュールでのみ有意義に動作する。過負荷防御モジュール４０４は 、それゆえ図４に示したシミュレータの場合、ＳＣＰシミュレータとは直接接続 されない。そのロードによって、過負荷防御シミュレータ４０４は、トラヒック シミュレータ４０１が生成する事象個数を制御する。ＳＣＰシミュレータ４０２ と過負荷防御シミュレータ４０４は、オンラインモードで間接的にオンラインシ ミュレータ４０５を介してのみ接続される。 図５は、ユーザの視点からのＩＮシミュレーションの基本流れを示す。シミュ レーションモジュール自体は図示されていないが、ブラックボックス５０１の枠 内で処理される。その際、過負荷防御シミュレータ５０２および／またはＳＳ７ シミュレータ５０３を、それぞれ接続できるか、または解除でき、図５ではスイ ッチ記号で表わされている。さらにユーザはデータファイルモードとオンライン モードを選択でき、これも同様にスイッチ記号で表されている。 シミュレータの、調節に関連する構造のほかに、ユーザはシミュレータが始動 してから、実際のシミュレーションパラメータ、つまり、シミュレートされるべ きネットワークコンフィギュレーション、トラヒック発生などを定義できる。最 初の始動時に全体の入力データファイルがシミュレーションモジュールによって 新たに読みこまれる。しかし、新しいシミュレーションを生成するために個別パ ラメータを変更すること、または古いシミュレーションを再度実行することも可 能である。シミュレータ５０１は、以前に決めた、または呼び出されたシミュレ ーションパラメータに基づいて規定の出力データ、トラヒック、ＣＰＵロード、 シミュレーション時間の関数として、待ち行列を算定し、それらをデータファイ ルに書きこむ。データはディスプレイに表示するか、またはデータキャリアに保 存でき、さらに処理するために送ることもできる。 図６は、トラヒックシミュレータのコンフィギュレーションパラメータならび にそれに関する数値の例を示す。図６の表に記されたパラメータは、全体でシミ ュレートされるサービスに関して別々に調整できるサービス特有のパラメータ、 サービスＴｅｌｅｖｏｔｕｍに関連するＴｅｌｅｖｏｔｕｍパラメータ、および 、全体サービスに関するパラメータ、つまりトラヒックゼネレータが生成するす べてのコールについて有効な一般パラメータに分類される。サービス特有のパラ メータは以下のＩＮサービスのために調整できる。フリーホン（ＦＰＨ）、テレ インフォサービス（ＴＩＳ）、汎用コール番号（ＵＮＵ）、イン・サービスＦＰ ＨＬ、およびＴｅｌｅｖｏｔｕｍ（ＴＶＳ）。Ｔｅｌｅｖｏｔｕｍサービスにつ いては、その他のサービスのために調整できるパラメータのすべてが必ずしも意 味を持つわけではない。それゆえそのような欄にはＸが記入される。そのほかに 電話通常トラヒック（ＮＶＫ）も考慮できる。なぜならＩＮ特有のコールも一定 のネットワークコンフィギュレーションでは、ＳＳＰに負担をかけず、それゆえ ＩＮがフル稼働できるからである。ＮＶＫでは、第１のサービス特有のパラ メータのステートメント、つまり平均通話時間だけが意味を持つ。なぜならその 他のＩＮパラメータは、１つのコールの１つのメッセージへの切り替え、または １つのコールの方向転換のようなＩＮ機能に関係するからである。 サービス特有のパラメータは、平均通話時間、平均メッセージ時間、最大メッ セージ時間、メッセージと方向転換確率、ならびに「加入者話し中」による方向 転換確率に関するメッセージ場所の数である。このパラメータは個々のシミュレ ーション時点で続き事象生成の確率を決めるために、つまり１つの事象ＥＶＥＮ ＴまたはＥＶＥＮＴ（ＣＡＬＬ ＥＮＤ）の生成に関する確率を決めるために必 要である。 Ｔｅｌｅｖｏｔｕｍパラメータは、それぞれのサービス加入者ＴＶ１、ＴＶ２ などのために別々に指示できる。ここに示す例では２人のサービス加入者だけが アクティブである。調整可能なパラメータは、目標値ＳＳＰＩないしＳＳＰ２、 接続までの目標値の数、開始時間、終了時間、および連続コールの終了時間であ る。パラメータ「目標値」はその際Ｔｅｌｅｖｏｔｕｍコールの回数を知らせ、 それは指示されたＳＳＰに届かなければならない。それによってＳＣＰへの１つ の情報が生成される。このパラメータが数値１にセットされると前カウントなし のオプションＴｅｌｅｖｏｔｕｍとなり、その数値が１以上ならＳＳＰで前カウ ントされるＴｅｌｅｖｏｔｕｍとなる。次のパラメータ「接続までの目標値の数 」はサービス加入者と接続されるかどうか、何番目のコールでサービス加入者と 接続されるかを指示する。サービスＴｅｌｅｖｏｔｕｍは基本的には短い制限時 間で提供されるので、それに合わせてサービス開始ないし終了の指示が準備され る。「連続コールに関する終了時間」パラメータは、遅れて受け入れられたＴＶ コールがどの時点で、情報的なメッセージに、場合によってはサービス加入者特 有のメッセージに変わるかを指示する。Ｔｅｌｅｖｏｔｕｍパラメータは、ど んな条件で、トラヒックゼネレータによってまず作られるＴＶコールがＩＮ第１ 事象を引き起こすかを指示する。 さらに、一般的なコンフィギュレーションパラメータは調整可能である。パラ メータ「タイムアウトまでの時間」は、ＩＮ情報がＳＣＰに送られ、ＳＣＰから 回答がないなら何分後に１つのコールがＳＳＰによって拒否されるかを指示する 。パラメータ「方向転換のための時間遅延」はコール・リルーティングの場合の 遅延を知らせる。パラメータ「平均メッセージ時間と最大時間『ＴＶ不活発』」 、およびそれらのステートメントに関する「メッセージ場所の数」は、サービス Ｔｅｌｅｖｏｔｕｍがアクティブでない時に届いたＴＶコールがどのように処理 されるかを知らせる。パラメータ「ＳＳＰからの回線数、ないしＳＳＰへの回線 数」は、交換局とＳＳＰの間のエリアのネットワークコンフィギュレーションに 関係する。さらにフリーホンサービス用の回線の数を規定できる。パラメータ「 Ａ加入者の平均待ち時間」は、接続がなされないとコールしている加入者は平均 何分後に受話器を置くかを指示する。この次の２つのパラメータは接続がうまく いかない場合、どの程度の確率で連続コールするか、および最大何回コールする かを指示する。 ＩＮ特有の組み合わせトラヒック発生にするために、主にＩＮ続き事象（ＥＶ ＥＮＴ）を生成するための上述のパラメータのほかに、対応するＩＮ第１事象（ ＰＲＯＶＩＤＥ ＩＮＳＴＲＵＣＴＩＯＮ）を生成するための限界条件を決める その他のパラメータが必要である。それゆえ、平均的なトラヒック発生を時間単 位ごとのコール回数で入力することが予定される。平均的なトラヒック発生は、 ユーザが決められる任意の時点で変化するが、それまでは一定で変化しない。そ れによって任意の形で時間的負荷曲線を作ることができる。特に、意味のあるサ ービス規定の場合に、Ｔｅｌｅｖｏｔｕｍサービスに関して典型的に見られる ような突出部を作ることもできる。平均的なトラヒック発生は個々のＩＮサービ ス（ＦＰＨ，ＴＩＳ，ＵＮＵ，ＦＰＨＬ，ＴＶ１，．．．，ＴＶｎ）、および通 常の電話トラヒック（ＮＶＫ）のために入力される。複数のＳＳＰがある場合は 、トラヒック発生は個々のＳＳＰのサービス特有に、別々に入力される。それゆ えＳＳＰの個数もパラメータであり、それはトラヒックシミュレーションの枠内 で調節できる。 トラヒック発生の場合、段階式の時間的経過が基礎になっており、個々の段階 ないし個々の時間間隔は、好適には、同じ時間的長さを持っている。間隔の数な らびに間隔長さはあらかじめ決められる。 トラヒック理論の基本に沿って、個々のシミュレーション時点に関して、ない し個々のシミュレーション間隔に関して、上記のステートメントに基づいて、１ つのコールが特別のサービス目印ないしサービス加入者目印をつけて、１つのＳ ＳＰに届く確率が算定される。シミュレーション時間間隔の長さは、好適には、 実際には、ユーザが平均的なトラヒック発生に関して決めた間隔よりも短い。シ ミュレーション間隔の長さは、好適には、ナノセカンドの範囲であり、一方トラ ヒック発生は秒の単位、たとえば、１０〜１００秒の単位で変化する。シミュレ ーション時間間隔は、好適には、最大で１つのコールが１間隔ごとに作られ、そ れによって全体で作られたコールが年代順にリスト化されるような間隔にする。 瞬時の確率は、適切な確率分布を想定して、ならびに処理されるサービス、サ ービス加入者、ないしＳＳＰに関して決められた瞬時平均トラヒック量を想定し て計算される。使用する確率分布は、好適には、ポアゾン分布である。なぜなら これは相互に独立した事象の統計的的中を説明し、それによって電話トラヒック の統計的変動が最も良く再現されるからである。個々のサービス、サービス加入 者、および／またはＳＳＰに関して、事象の時間列が作られ、時間単位ごとの コール回数が、統計的にこれまで与えられた瞬時の平均値の分だけ変動する。Ｆ ＰＨ、ＴＩＳ、ＵＮＵ、ＦＰＨＬおよび前カウントなしのＴｅｌｅｖｏｔｕｍサ ービスの場合、潜在的には個々の生成されたコールが１つのＩＮ特有の事象にな り、それらはインテリジェントネットワークのロードを軽減させ、それゆえ、Ｉ Ｎ、特にＳＣＰのパフォーマンスをシミュレートするために重要である。 そのように生成され、ＩＮ情報ＰＲＯＶＩＤＥ ＩＮＳＴＲＵＣＴＩＯＮに対 応する第１事象は、その生成時間ｔ１で年代順に、大域事象カレンダー、ないし はデータファイルモードの第１の伝達データファイルに登録される。Ｔｅｌｅｖ ｏｔｕｍコールは、アクティブな前カウントでは、それぞれのｎ番目のコールの 時にのみ、１つのＩＮ事象（ＰＲＯＶＩＤＥ ＩＮＳＴＲＵＣＴＩＯＮ）になる 。これも同様に生成時間ｔ１で大域事象カレンダーないし伝達データファイルに 受け入れられる。その他のコールおよび通常の電話トラヒックのコールはＳＳＰ だけをロードし、ＩＮ事象は作成しない。 さらにトラヒックゼネレータは、１つのＩＮコールないし第１事象に割り当て られた続き事象を、１つのＩＮ事象のその後の運命に関係するコンフィギュレー ションデータファイルに入力された確率を考慮しながら作成する。たとえば、真 の加入者へのＩＮ接続、ないしＳＣＰによる接続処理情報（ＣＲＥＡＴＥ−ＪＯ ＩＮ）に基づく１つのメッセージ場所への切り替えが、シミュレーションにおい て規定通りならば、通話は、指示された平均通話時間ないしメッセージ時間が経 過すると終了し、その間にトラヒックゼネレータが続き事象ＥＶＥＮＴ（ＣＡＬ Ｌ ＥＮＤ）を作成し、伝達データファイルないし大域事象カレンダーに登録す る。ＩＮが、シミュレーションではＳＣＰが通知する真の加入者と接続されてお らず、このことをトラヒックゼネレータが、指示された確率を考慮しながら、確 認するなら、トラヒックゼネレータは続き事象としてＩＮ情報ＥＶＥＮＴを作成 し、それと共に、たとえば、ＳＣＰからのリルーティング情報が要求される。こ のような方法で、トラヒックゼネレータはＩＮ型の事象列を作成できるようにな り、それはＩＮにおける真のトラヒック発生に対応する。 個々のＩＮ事象については次のパラメータが保存される。コールの識別番号、 情報がＳＳＰから送られる時間ｔ１、情報の識別番号、たとえば、１はＰＲＯＶ ＩＤＥ ＩＮＳＴＲＵＣＴＩＯＮ、２はＥＶＥＮＴ、３はＥＶＥＮＴ（ＣＡＬＬ ＥＮＤ）、サービスの識別番号、たとえば、３はＴＩＳ、５はＵＮＵ、６はＦＰ Ｈ、１０＋ｊ（Ｊ＝０，．．．，８９）はサービスＴＶのｊ番目のサービス加入 者、ならびにＳＳＰの識別番号。 さらにＩＮでの大域タイトル翻訳を考慮するために、本発明を有利な成形にす ると、大域タイトル（ＧＴ）の識別符号もルーティング基準として生成され、Ｉ Ｎ事象のパラメータとして保存される。ＧＴ等級も同様に所与の確率分布で生成 される。ＳＴＰ／ＳＲＰシミュレータでは、次いで、好適には、ＧＴ特有のプロ セスチェーンが突き合わされ、それはＳＴＰ／ＳＲＰレベルのルーチング機能性 をシミュレートする。つまり、たとえば、その他のネットワーク提供者のネット ワークへコールを伝送することがシミュレートされる。 さらにトラヒックシミュレータによって生成された事象を、有効等級と負荷等 級に分類することは有利である。コール関連のＩＮ事象は有効等級に分類され、 一方、たとえば、ＩＮレベル相互の管理トラヒックは負荷等級の事象によってシ ミュレートできる。トラヒックシミュレータが生成した個々の事象に対して、対 応する等級識別符号が作られ、保存され、その識別符号はその他のシミュレーシ ョンモジュールによって認識され、場合によってはその事象をさらに処理する決 定に関与する。 オンラインモードでは、シミュレーション運転中にトラヒックゼネレータが適 切な確率で続き事象を作る。その前に、関連する第１事象が、シミュレーション モジュールＳＣＰシミュレータ、および場合によってはＳＳ７シミュレータを通 過しており、つまりＳＣＰ情報ＣＲＥＡＴＥ−ＪＯＩＮに対応する１つの事象が ＳＣＰシミュレータによって作られており、場合によってはトラヒックシミュレ ータではＳＳ７シミュレータを通過した後、処理されるために残っている。それ によってオンライン運転でシミュレーションモジュール相互間フィードバックが 、自動的に、ＩＮ特有の事象列の場合は、トラヒックシミュレータによって考慮 される。 データファイルモードではそうしたフィードバックは、シミュレーションモジ ュールの連続コールがあるために、反復によってのみ達成できる。それゆえトラ ヒックシミュレータが最初に呼び出されると、上述の方法で第１事象が生成され 、続き事象のためにまず所定の、たとえば、時間的に一定のＳＣＰ回答時間が想 定される。この回答時間は、トラヒックシミュレータが再度呼び出されると、Ｓ ＣＰシミュレータないしＳＳ７シミュレータがトラヒックシミュレータに渡した データファイルから作られる回答時間によって訂正される。シミュレータを複数 回通過すると、定常状態になり、そのさいモジュール相互の交替作用も考慮され る。 オンライン運転におけるＩＮ特有の第１事象は、全体シミュレーションの進行 中に生成される。つまり個々のシミュレーション時点で、たとえば、ｎｓ間隔で 生成される。それによってその他のシミュレーションモジュールが瞬時過負荷に なる際の過負荷防御の介入もシミュレートできるようになり、１つの対応するＩ Ｎ事象が作成ないし伝達される前のコールが拒否される。 ＳＳＰないし複数のＳＳＰに届く１連のコールは、基本的にはＩＮ事象になる が、シミュレーション開始の前に、上述のトラヒック理論方法にそって作成する ことができ、シミュレーション中に処理できる。つまりＩＮ事象として与えられ るか、または過負荷防御に基づいて見捨てられる。 生成されたトラヒックから、個々のシミュレーション時点に関するインテリジ ェントネットワークの符号回路のロードを算定できる。コールのその後の運命（ たとえば、定められた平均時間のメッセージまたは通話）に関するユーザ定義の 確率を基にして、ＳＳＰへの、またはＳＳＰからの占有されている通話回線の数 および／またはフリーホンサービス加入者のために占有されている一般回線の数 も時間の関数としてプロトコル化され、出力される。さらにシミュレーション時 間の関数として、さまざまな段階でコールが拒否された回数、たとえば、過負荷 防御の直後に、ＳＣＰが反応しない場合のタイムアウトの後に拒否された回数、 または全体のメッセージ場所が使用中であるために拒否された回数を出力できる 。 図７はデータファイルモジュールでの基本的なシミュレーション流れを示す。 シミュレータの始動後に個別シミュレーションモジュールの入力データファイル が読み込まれる。トラヒックシミュレータは、すでにＳＣＰの情報を持つデータ ファイルがあるかどうか（図２の伝達データファイル２０４、ないし図３の伝達 データファイル３０７）を確かめる。あるならば、そのデータはＳＣＰ回答時間 に関して分析され、事象列を生成する際にトラヒックシミュレータによって考慮 される。もしないならば分析せずに次の段階へ伝達され、ＳＣＰ回答時間に関し て１つのデフォルト値が使われる。カウンタの初期化には、内部シミュレーショ ン時計をゼロ時にセットにすること、状態変数の初期化、および初期値での統計 的カウンタが含まれる。 次の段階では、スタート事象が生成される。つまり、第１の情報ＰＲＯＶＩＤ Ｅ ＩＮＳＴＲＵＣＴＩＯＮが生成され、事象カレンダーに登録される。事象カ レンダーには、シミュレーション中に処理されるべきすべての事象が、スタート 時間にそって記されている。 初期化のあと、１つのループの内側で独自のシミュレーションが始まる。まず 中断条件の問い合わせがあり、その際、実際のシミュレーション時間ｔが所与の シミュレーション時間より大きいならば、シミュレーションが中断される。ルー プの内側で、その次の事象がカレンダーから削除され、シミュレーション時計が その次の事象の時点に切り替えられる。シミュレーションのスタートの際、これ らの事象はシミュレーションにそって作られる第１の事象である。処理される事 象の事象型式が決められ、それにそって関連する事象ルーティンが処理される。 この例では新しいさまざまな事象形式が予定されている。左から右へ、新しい コールの到着（ＮＥＷ ＣＡＬＬ）、リダイヤルされたコールの到着（ＦＯＣＡ ＬＬ）、ＳＣＰからの情報ＣＲＥＡＴＥ−ＪＯＩＮの受け取り（ＣＯＮＮＥＣＴ ＳＳＰＣＯＮ）、Ｂ加入者への接続構築（ＣＯＮＮＥＣＴ Ｂ）、コール経路変 更（ＲＥＲＯＵＴ）、コール経路変更の際のＳＣＰからの情報ＣＲＥＡＴＥ−Ｊ ＯＩＮの受け取り（ＲＥＲＯＵＴＣＯＮ）、通話終了（ＴＡＬＫＥＮＤ）、メッ セージ終了（ＴＡＰＥＮＤ）、およびコールの拒否（ＲＥＪＥＣＴ）。 カレンダーに第１に登録されている事象は、基本的に１つの新しいコール（Ｎ ＥＷ ＣＡＬＬ）である。それに割り当てられている事象ルーチンは、トラヒッ クゼネレータにその次のコールの生成、およびＳＳＰへの接続構築のシミュレー ションをさせる。事象ルーチンＮＥＷＣＡＬＬはＳＳＰからのＩＮ情報ＰＲＯＶ ＩＤＥ ＩＮＳＴＲＵＣＴＩＯＮのＳＣＰへの送信を、対応する事象を生成する ことによって、および事象カレンダー、ないし伝達データファイルに登録するこ とによってシミュレートする。 ＳＣＰはさらに情報ＣＲＥＡＴＥ−ＪＯＩＮをＳＳＰに送る。シミュレーショ ンではそれゆえＳＣＰのＣＲＥＡＴＥ−ＪＯＩＮの受け取りは、その時点の実際 のシミュレーション時間プラスＳＣＰ回答時間の事象として事象カレンダーに登 録される。それによって第１の事象ルーチンは終了し、シミュレーション時計が 次の事象時間にセットされ、その事象は、シミュレーション時間がすでに終了し ていなければ、読まれ、処理される。２つの事象の間の時間は飛ばされる。 その次の事象は、ＳＣＰの情報ＣＲＥＡＴＥ−ＪＯＩＮの受け取りである。Ｓ ＳＰの接続構築の継続が事象ルーチン（ＣＯＮＮＥＣＴＳＳＰＣＯＮ）でシミュ レートされる。その際、Ｂ加入者への接続構築が成功したかどうか（続き事象Ｃ ＯＮＮＥＣＴＢ）が、たとえば、上述の確率で確かめられ、その際Ｂ加入者は真 の加入者であるか、または１つのメッセージになることがあり、またはそれ以前 にトライされたが伝達されなコールが経路変更しなければならないかどうかが確 かめられる（続き事象（ＣＯＮＮＥＣＴＢ またはＲＥＲＯＵＴ））。事象ＣＯ ＮＥＣＴＢが呼び出されると、Ｂ加入者への接続が構築される。続き事象はＴａ ｌｋ−ＥｎｄないしＴａｐｅ−Ｅｎｄであり、その時間は平均コールないしメッ セージ時間ならびに実際のシミュレーション時間で決まる。接続構築がうまくい かないとある程度の確率で、続きコールが作られ、その事象ＦＯＣＡＬＬは事象 カレンダーに登録される。リダイヤルされたコールはその後、最初のコールと同 じように処理される。 １つの事象を事象カレンダーからループ呼び出しすること、対応する事象ルー チンの終了、場合によっては続き事象の作成および事象カレンダーへの登録、事 象カレンダーに登録されているその次の事象にシミュレーション時間をセットす ること、およびその呼び出しは、その前に調節したシミュレーション時間になる まで、つまりシミュレーションの終わりを特徴付ける事象が生じるまで一巡され る。シミュレーション終了後、処理されたインテリジェントネットワークのパフ ォーマンスを評価するために、事象カレンダーまたはプロトコルデータファイ ルに登録され、シミュレータによって作成され処理されたデータファイルないし 個別の構成要素が自由に使用できるようになる。 図８は、オンラインモードでの基本的なシミュレーション流れを示す。まずコ ンフィギュレーションをユーザが決める。その際、対応するコンフィギュレーシ ョンデータファイルをシミュレーションモジュールが読みこむ。図８に示した例 ではトラヒック−、ＳＳ７−、ＳＣＰ−、および過負荷防御−（ＡＣＧ−シミュ レータ）はアクティブであり、共通の組織プログラムであるオンラインシミュレ ータによって管理される。図７の実施例について説明されているように、まずト ラヒックシミュレータによってスタート事象が作られる。大域のシミュレーショ ン時計がｔ＝０にセットされる。ループの内側では、図７に示したシミュレーシ ョン流れのように、大域事象カレンダーに登録された事象ルーチンが、年代順に 処理され、呼び出され、その事象ルーチンが関係する事象ルーチンを処理し、場 合によっては作られた続き事象が大域カレンダーに登録される。１つの事象ルー チンが終わるとそのつど、シミュレーション時間はその次の事象の時刻にセット され、その事象が処理される。ループの中断条件になるのは、あらかじめ決めら れた最大のシミュレーション時間であり、これが個々のループ通過の際に実際の シミュレーション時間と比較される。シミュレーションエンドに達すると、動的 な記憶装置が解放されるによって部分シミュレーションが終わりになる。シミュ レーションエンドに達しなければ、ユーザレベルがシミュレーション中にデータ 呼び出しする共同記憶装置が現実化されるので、実際のシステムデータがユーザ に対して直接表示されるようになる。さらに過負荷防御シミュレーションのため のシステムデータが現実化される。最後にコンスタントな時間間隔で算出された 測定データ、つまりＳＣＰロード、待ち行列長さなどがプロトコル化され、対応 するプロトコルデータファイルに登録され、および／またはユーザに視覚的 に示される。次いでカレンダー内のその次の事象が処理される。 ここに提示する例では、全部で１３の大域事象に分類されており、それらは２ つのグループに区分される。 内的事象：内的事象になるのは個別シミュレーションモジュールの状態にだけ 影響を与えるルーチンである。個々のシミュレーションモジュールは、多数の事 象とその管理に関する独自のローカルカレンダーを有する独立した事象指向のプ 口グラムである。全体シミュレータの流れ制御の観点から見ると、この場合、３ つの大域の内的事象ＴＲＡＦＩＣ ＩＮＴＥＲＮ、ＳＳ７ ＩＮＴＥＲＮおよび ＳＣＰ ＩＮＴＥＲＮがあり、それらはそれぞれローカルな事象カレンダーを指 示する。 図９は、オンラインシミュレーションの観点から見たそうした内的事象の処理 を図式的に示す。部分構成要素が呼び出されると、内部プログラム流れに依存し てその次の内部事象、および場合によってはその次の外部事象が作られ、シミュ レーションモジュールのローカルカレンダーに登録される。さらに事象のすべて の必要なパラメータが、流れ制御に渡され、その結果全体シミュレーションの大 域カレンダーに分類して入れられる。 図８に提示されているシミュレーション流れのその他の事象は、シミュレーシ ョンモジュール相互の通信に有用な外部事象である。それらは真のインテリジェ ントネットワークで１つの構成要素からその他の構成要素に送られる情報、たと えば、ＰＲＯＶＩＤＥ ＩＮＳＴＲＵＣＴＩＯＮ、ＣＲＥＡＴＥ−ＪＯＩＮ、Ｅ ＶＥＮＴに対応する。ここで発生する外部事象は、ＰＲＯＩＮＳＴ ＴＯ ＳＳ ７、ＥＶＥＮＴ ＴＯ ＳＳ７およびＳＳＰ ＣＡＬＬＥＮＤ ＴＯ ＳＳ７で あり、これらは情報ＩＮＳＴＲＵＣＴＩＯＮ、ＥＶＥＮＴないしＳＣＰにあるＳ ＳＰのＥＶＥＮＴ（ＣＡＬＬ ＥＮＤ）に対応する。列挙した内部事象は、ト ラヒックシミュレータで生成される（ルーチン：ＴＲＡＦＦＩＣ ＩＮＴＥＲＮ ）。データファイルモードでそれらに相当するのは、第１の伝達データファイル ３０４（図３）に登録されている事象である。 外部事象ＰＲＯＶＩＮＳＴ ＴＯ ＳＣＰ、ＥＶＥＮＴ ＴＯ ＳＣＰおよび ＣＡＬＬ ＥＮＤ ＴＯ ＳＣＰは、情報ＰＲＯＶＩＤＥ ＩＮＳＴＲＵＣＴＩ ＯＮ、ＥＶＥＮＴないしＥＶＥＮＴ（ＣＡＬＬ ＥＮＤ）のためであり、それら はＳＳ７システムないしＳＲＰ／ＳＴＰからＳＣＰへ伝達される。これらの事象 は、第２の伝達データファイル３０５（図３）に登録された事象に対応する。 ＳＣＰの回答は、事象ＳＣＰ ＣＡＬＬ ＥＮＤ ＴＯ ＳＳ７およびＣＲＥ ＡＴＥ−ＪＯＩＮ ＴＯ ＳＳ７の中にある。事象ＳＣＰ ＣＡＬＬ ＥＮＤ ＴＯ ＳＳ７は、接続解消を承認し、事象ＣＲＥＡＴＥ−ＪＯＩＮ ＴＯ ＳＳ ７は、接続構築情報の伝送をシミュレートする。これらの事象は第３の伝達デー タファイル３０６に登録された事象に対応する。それらはＳＣＰシミュレータに よって生成され、ＳＳ７シミュレータに向けられる。外部事象ＣＡＬＬ ＥＮＤ ＴＯ ＳＳＰおよびＣＲＥＡＴＥ−ＪＯＩＮ ＴＯ ＳＳＰは、ＳＳ７シミュ レータによって生成され、ＳＣＰからの１つの情報をＳＳＰへ、ＳＳ７システム を介して伝送することを確保する。対応する事象はデータファイルモードで第４ の伝達データファイル３０７に保存される。 情報ＣＡＬＬ ＥＮＤ ＴＯ ＳＳＰは、ＳＳ７が不活発な場合にのみ必要と なる。 １つの外部事象を流れ制御の内側で処理することは、１つのシミュレーション 構成要素に対応する情報を入力することである。その際、構成要素に、その情報 によって新しい内部事象を生成させることが可能であり、その事象はさらにオン ラインシミュレーションの方に送られ、大域カレンダーに登録される。１つの事 象ルーチンが処理されると、その次の事象が大域カレンダーから削除され、シミ ュレーション時計が現実化される。つまりその続き事象のスタート時点にセット される。 内部事象ＴＲＡＦＦＩＣ ＩＮＴＥＲＮが処理されると、トラヒックシミュレ ータが呼び出され、１つの新しいコールを生成する。その他のシミュレーション モジュールの実際のロードに基づいて、この新しいコールが過負荷防御（ＡＣＧ ）によって拒否されるかどうかが決められる。コールが過負荷防御によって拒否 されると、その事実がプロトコル化され、事象ルーチンが終了する。コールが拒 否されないと、そのコールはシミュレーションに受け入れられる。つまり、対応 する事象ＰＲＯＶＩＮＳＴ ＴＯ ＳＳ７が大域カレンダーに登録される。プロ トコルデータファイルには、生成されたコールのために１つの新しい要素が追加 され、その次のデータ、つまりそのコール生成時にトラヒックシミュレータによ って作られるそれぞれのコールの識別番号、そのコールが届いたＳＳＰの番号、 そのコールのサービス識別番号、情報ＰＲＯＶＩＤＥ ＩＮＳＴＲＵＣＴＩＯＮ またはＥＶＥＮＴがあるかどうかの情報識別番号、および実際のコールに関し て対応する情報ＰＲＯＶＩＤＥ ＩＮＳＴＲＵＣＴＩＯＮまたはＥＶＥＮＴが生 成された時間ｔ１が保存される。シミュレーション進行中にこのプロトコル列は その他の時間ラベルによって補完される。つまり、ルーチンＰＲＯＶＩＮＳＴ ＴＯ ＳＣＰまたはＥＶＥＮＴ ＴＯ ＳＣＰをＳＳ７シミュレータ（時間ラベ ルｔ２）によって処理した後、ルーチンＣＲＥＡＴＥ−ＪＯＩＮ ＳＳ７をＳＣ Ｐシミュレータ（時間ラベルｔ３）によって処理した後、およびルーチンＣＲＥ ＡＴＥ−ＪＯＩＮ ＴＯ ＳＳＰをＳＳ７シミュレータ（時間ラベルｔ４）によ って処理した後に補完される。 ＣＡＬＬ ＥＮＤ型の情報はプロトコル化のさいに考慮されない。それが引き 起こす遅延時間は、ＩＮ発呼者の待ち時間には有用な作用をせず、回答時間を超 えるメッセージを改ざんするからかもしれないからである。別の質問設定にすれ ば対応する時間ラベルのプロトコル化も意味を持つことがある。 第２、第３の時間構成要素には、ＳＳ７シミュレータがアクティブな場合に有 効な数値だけが含まれる。 １つの個別のコールに関する１つの完全なデータセットは、ＳＳＰに情報ＣＲ ＥＡＴＥ−ＪＯＩＮが届く時点ではじめて存在するので、データはまず中間保存 されなければならない。１つのコールを生成すると新しいデータセットが作成さ れ、それはプログラム流れの間に、まだ不充分な時間構成要素が補完される。個 別の、コールに関連する時間ラベル相互の差分を作ることにより、次のような回 答時間を算定できる。 ｔ２−ｔ１：ＳＣＰへの途中のＳＳ７の１つの情報の遅延 ｔ３−ｔ２：ＳＣＰの１つの情報の遅延 ｔ４−ｔ３：ＳＣＰへの途中のＳＳ７の１つの情報の遅延 ｔ４−ｔ１：ＩＮでの１つの情報の全体遅延 ネットワーク負荷はシミュレーション流れの間は一定の時間間隔で保存される 。コール特有の情報ではなく大域の統計的なネットワークデータが保存される。 その際、好適には、次のような大きさがプロトコル化される。実際の測定時間、 ＩＮに届いた１秒ごとのコール回数、ＳＣＰへの途中にあるＳＳ７において処理 されている情報の割合、ＳＣＰならびにＳＳＰへの途中にあるＳＳ７にある情報 の個数。 ＳＣＰシミュレータ内では、個々のプロセッサに関して負荷、待ち行列長さお よび処理される情報の数量（ｄｉｓｐａｔｃｈｅｓ）が算定され、プロトコルデ ータファイルに保存される。オンラインシミュレータはこのデータにアクセス し、すべてのＣＰＵを介して算定される数値をデータファイルに書き込む。その データはオンラインシミュレーション中にユーザレベルを経て表示できる。 最後に、トラヒックデータを使って占有されているＳＳＰからの、ないしＳＳ Ｐへの回線の数が算定され、シミュレーション時間の関数としてプロトコル化さ れる。 図８ａは図８を補完するために、使われた事象相互の関係を示す。図８のシミ ュレータにはＳＲＰのシミュレーションのための１つの個別モジュールが追加さ れている。そのモジュールはＳＳ７シミュレータの一部にもなりうる。それゆえ 、ここではＳＲＰ＿ＩＮＴＥＲＮ型の事象も生じる。４つの内部事象ＴＲＡＦＦ ＩＣ＿ＩＮＴＥＲＮ、ＳＳ７＿ＩＮＴＥＲＮ、ＳＲＰ＿ＩＮＴＥＲＮおよびＳＣ Ｐ＿ＩＮＴＥＲＮは、１つの事象を処理するためにシミュレーションモジュール の呼び出しを指示する。その他の外部モジュールはすべて、１つのシミュレーシ ョンモジュールをその次に移行させる上で有用である。全体シミュレーションに おけるスタート事象は、常に１つの事象ＴＲＡＦＦＩＣ＿ＩＮＴＥＲＮである。 なぜならそのトラヒックシミュレータはＩＮコールの源泉だからである。 個々のシミュレーションモジュールは、内部事象を処理（ｗｏｒｋ ｏｆｆ） してから、処理（ｐｒｏｃｅｓｓｉｎｇ）のための続き事象を同じシミュレーシ ョンモジュールで生成できる。それと同時に、曲がった矢印をつけてある外部事 象の１つを生成できる。この情報はそれぞれのシミュレーションモジュールのオ ンラインシミュレータに含まれる。 １つの外部事象の呼び出しは、ＩＮのそれぞれ別のノードへの１つの情報の送 信に対応する。１つの情報を送信すると、３つの情報が区別される。トラヒック ゼネレータからＳＣＰシミュレータへの移行が３通りになる。１つのＴＲＡＦＦ ＩＣ＿ＩＮＴＥＲＮ事象が呼び出され、その事象は、その情報を生成し、その コールに対して、シミュレーションの内側で明白な１つの番号（ＣＡＬＬＩＤ） を与える。その後、さらに多くのトラヒックが生成される場合は、情報に応じて ＰＲＯＩＮＳＴ−ＴＯ−ＳＳ７−、ＥＶＥＮＴ−ＴＯ−ＳＳ７またはＳＳＰ−Ｃ ＡＬＬＥＮＤ−ＴＯ−ＳＳ７事象、およびもう１つのＴＲＡＦＦＩＣ＿ＩＮＴＥ ＲＮ事象が続く。次いで外部事象が処理され、ＳＳ７−ＩＮＴＥＲＮ事象が続く 。これは、ＳＳＰのＳＳ７部分での処理が終わり、ＳＲＰへの１つの外部事象が 生成されるまで、次々に何回も起きる。情報はその際、変化しない。つまり、入 ってくるＰＲＯＶＩＤＥ−ＩＮＳＴＲＵＣＴＩＯＮがそうした事象としても伝送 される。この外部事象の後には、アナログでＳＳ７ＩＮＴＥＲＮ事象になるまで 、複数のＳＲＰ−ＩＮＴＥＲＮ事象が続く。ＳＣＰ−ＩＮＴＥＲＮ事象への伝達 は、ＳＳ７ＩＮＴＥＲＮ事象のＳＲＰ−ＩＮＴＥＲＮ事象への伝達とアナログで 行われる。 １つのＳＣＰ−ＩＮＴＥＲＮ事象を複数回処理した後、ＳＣＰシミュレータは 、オンラインンシミュレータに１つの情報をＳＳＰシミュレータに送るように委 任する。２つの異なる情報ＣＲＥＡＴＥ−ＪＯＩＮ、ＣＡＬＬＥＮＤがあり、こ れらはアナログで、すでに説明したシナリオでＳＳ７シミュレータに導かれ、Ｓ Ｓ７−ＩＮＴＥＲＮ事象になる。しかし、そこからはＣＲＥＡＴＥ−ＪＯＩＮ型 のみがＴＲＡＦＦＩＣ＿ＩＮＴＥＲＮ事象になる。ＣＡＬＬＥＮＤ型の事象は、 トラヒックゼネレータに、それに関係する続き事象を作らせない。しかし、続き コールはコンフィギュレートされ、接続できなかった場合、偶然ゼネレータが決 めた時間になると、続きコールをトラヒックシミュレータによってスタートさせ ることは可能である。これは最初のコールとおなじＣＡＬＬ ＩＤを持つ。 トラヒックシミュレータを、ＣＲＥＡＴＥ−ＪＯＩＮ事象の結果になるＴＲＡ ＦＦＩＣ＿ＩＮＴＥＲＮ事象を通して呼び出すと、偶然ゼネレータごとに、あら かじめ決められた確率にそって、この事象についてのその次の情報が、いつ送ら れるが決められる。この時点で上述の事象チェーンが始動する。 １つ以上のコールの場合、それぞれのコールに関してこの事象チェーンが保持 される。重なりあう複数のコールの事象は、大域の事象カレンダーにおけるその 位置に依存して処理される。 以下に、ＳＣＰ−、ＳＳ７シミュレータの構造を説明する。 図１０はＳＣＰシミュレーションの原理を図式的に示す。事象制御のシミュレ ーションであり、不連続の事象時点だけが考慮され、それぞれの事象時点で状態 変化が生じることがある。 ＳＣＰシミュレータはローカルな事象カレンダーをもっており、その中に、Ｓ ＣＰシミュレータによって処理される事象全体が年代順に登録されている。次の ような事象が区別される。情報：情報はＳＳＰないしＳＳ７のＳＣＰへの、コー ル処理のための質問であり、その場合、ＳＣＰないしＳＣＰシミュレータに、１ つの情報が到着すると、あらかじめ決められたプロセス列で構成されるサービス 処理プログラムがスタートする。１つの情報は１つの大域外部事象に対応する。 （ローカルな）内部事象：１つのローカルな内部事象は、１つのプロセスない し事象の終了および１つの新しいプロセスないし対応する事象の生成を導く。そ の際、その種類と特性はサービス処理プログラムで定義されたプロセスチェーン からもたらされる。 （ローカルな）外部事象：１つのローカルな外部事象は、１つのサービス処理 プログラムが終了すると、つまりプロセスチェーンで最後に特殊化されたプロセ スが処理されたあとに、生成される。１つの外部事象は１つの情報のＳＳＰから ＳＳ７への送信を導き、１つの大域の外部事象の生成と大域事象カレンダーへの 登録を導く。 図１１は、ＳＣＰシミュレータのコンフィギュレーションパラメータの１例で ある。表の上部はシミュレートされる全体プロセスの一覧であり、これはＳＣＰ によって実行できる接続構築ないし接続解除に関連するプロセスである。個別プ ロセスの特徴はプロセス識別番号（プロセスＩＤ）で示されている。プロセス名 称を指示することによって、真のＳＣＰの機能にコンフィギュレーションを合わ せることが容易になる。それぞれのプロセスに、ここではミリセカンドで指示さ れるプロセス時間と１つの優先性が割り当てられる。ステートメントはユーザ定 義可能であるため、たとえば、優先性配置またはプロセス時間変更の影響がシミ ュレータで算定できる。 表の下段には、ユーザ定義可能なＳＣＰサービス流れが示されている。ここで は識別番号が特徴の個々のサービスと、情報識別番号が特徴になっているサービ ス特有の個々の情報ＰＲＯＶＩＤＥ ＩＮＳＴＲＵＣＴＩＯＮ、ＥＶＥＮＴまた はＥＶＥＮＴ（ＣＡＬＬ ＥＮＤ）に、１つのプロセス列が割り当てられている 。プロセス列ないしサービス処理プログラムは、その際、上にリスト化したプロ セスのプロセスＩＤを次々に指示（ステートメント）することによって定義され る。さらにここでは個々の情報は、サービス特有で、ＣＰＵに割り当てられ、そ のＣＰＵでプロセス列が処理される。全体の情報も全体で使用可能なＣＰＵで処 理できる。 さらに、１つの個別プロセスを任意の多くの部分プロセスに分けることも可能 であり、それらの間に別のプロセスのプロセス列が入ることもある。最初の部分 プロセスが、プロセスＩＤに関連するコピーを１つのプロセス列に置くならば、 これは最後の部分プロセスが完全に処理されるまでそこに置かれたままである。 そうした特性はすべてのサービスプロセスに見られる。 貯蔵所（Ｃａｃｈｅ）アクセス、固定プレートアクセスまたはＴＶサービス用 の１つのカウンター増分をシミュレートするために、待ちプロセスをプロセス列 に入れることができる。平均待ち時間とその変数は調節できる。実際値は、シミ ュレーション中に、これらのパラメータでの適切な確率分布、たとえば、ガウス 分布を基礎にして算定される。 さらに図１１で示すように、パラメータとしては、多くのネットワークトポロ ジーでＳＣＰとＳＳ７システムの間のインタフェースになるＦｒｏｎｔ Ｅｎｄ Ｓｙｓｔｅｍ ＳＴ２０００の遅延、およびＴｅｒｅｖｏｔｕｍサービス用の 最大カウンタ示度を挙げることができる。 図１２はＳＣＰシミュレーションに基づく、ＳＣＰ内のＣＰＵ１２０１のプロ セス管理のモデルを示す。基本的にそうしたプロセス管理の個々のモデルは、待 ち行列ないし事象カレンダーを適切に定義すれば、ＳＣＰシミュレータによって 受け入れられる。プロセス管理においては、ＳＣＰ待ち行列、ないしＳＣＰシミ ュレータ内のローカル事象カレンダーの結合方式と回数だけが決められ、それに よって、１つの情報のように、ないしそこから生じる個別プロセスのように、シ ミュレータ内で処理される。シミュレータはユーザステートメントに合わせられ るので、任意のリアリティがシミュレートできる。特定のハードウェアおよび／ またはソフトウェア構造は想定されず、任意のコンフィギュレーションをモデル 化できる。 ＣＰＵ１２０１は、図１２の事例では、ネットワーク（ＬＡＮ）１２０２、１ ２０３の２つのローカルエリアを使ってＳＳ７に、たとえば、２つのＴｏｋｅｎ −Ｂｕｓ−ＬＡＮによってＦｒｏｎｔ Ｅｎｄ Ｓｙｓｔｅｍ ＳＴ２０００を 介して接続される。 ＳＣＰに届いた情報１２０８（ＰＲＯＶＩＤＥ ＩＮＳＴＲＵＣＴＩＯＮ）は 、それぞれのサービスに依存して、サービス特有の待ち行列１２０４、１２０５ 、 １２０６、１２０７に書き込まれる。この待ち行列において、１つのプロセスな いし１つの情報が外部／内部情報を待っており、その情報は処理のためのプロセ スを呼び出す。プロセスは希望する情報を得ると、活発化されたプロセスの待ち 行列に入る。この優先待ち行列１２１０には、活発化されたプロセスが優先性に そって並んでおり、一方、サービス特有の待ち行列１２０４から１２０７までに 登録された事象は年代順に並んでいる。優先待ち行列１２１０の中で最高の優先 性を持つプロセスは、ＣＰＵを入手し、そこで処理される。呼び出されるプロセ スのすべてのインカーネーションは占有されているために、たとえば、１つのプ ロセスがＣＰＵによって処理できない場合は、この進行できないプロセスは、プ 口セスインカーネーションが再び準備され、そのプロセスが進行できる状態にな るまで、追加の待ち行列１２０９において管理される。次いで優先待ち行列１２ １０に登録される。 図１３はＳＣＰ機能をシミュレートするためのＣＰＵのプロセス管理のもう１ つのモデルを示す。ＣＰＵ１３０１に届いた情報は、サービス処理プログラムに そって１つのプロセス列に変換される。この中の第１のプロセスがプロセス特有 の待ち行列１３０２、１３０３、１３０４、１３０５に登録され、その結果、割 り当てられたプロセスルーチン１３０７、１３０８、１３０９、１３１０によっ て処理される。プロセス特有の待ち行列１３０２から１３０５には、届いたプロ セスが年代順に整理して入れられる。個々のプロセスルーチン１３０７、１３０ ８、１３０９、１３１０には、さらに一定の優先性Ｐ１からＰｎが割り当てられ る。待ち行列１３０２、１３０３、１３０４、１３０５だけは、優先性特有のコ ンフィギュレーションも考えられる。つまりすべての、異なるプロセスも一定の 優先性を受け入れ、それらが年代順に処理される。 プロセスルーチンは、同じプロセスについていくつかにインカーネーションす ることが可能であり、たとえば、サービスごとに１つのコピーがある。この場合 、プロセス特有の待ち行列１３０２〜１３０５もサービス特有である。プロセス ルーチン１３０７〜１３１０が準備されているなら、次のプロセスは対応する待 ち行列１３０２〜１３０５から呼び出される。するとそのプロセスはスタンバイ になる。ＣＰＵ１３０１がフリーなら、そのプロセスは処理される。プロセス終 了後、ＣＰＵ１３０１によって、プロセスチェーンにおいて、終了したプロセス に続くプロセスが生成され、対応する待ち行列に登録される。進行できないプロ セスは、再び、進行できる状態になるまで、追加の待ち行列１３０６において管 理される。中断されたが進行できる状態のプロセスはその待ち行列の始めに置か れ、その優先性が認められるなら、次のプロセスとして処理される。 進行しているプロセスは、たとえば、ＣＰＵの運転システムをシミュレートす るプロセス、ないし事象によって中断される。そうした事象には、そのシミュレ ーションにおいては、サービス処理するプロセスよりも高い優先性が与えられる 。ＣＰＵがそうしたプロセスの処理に平均でどのくらい時間を使うべきかは、ユ ーザが調節できる。そのようなプロセス自体は偶然ゼネレータによって生成され る。 図１４はＳＣＰシミュレータのオブジェクト指向モデルを図式的に示す。シミ ュレータは多くのサブユニットをもち、これらはそれぞれＣＰＵ１４０１、１４ ０２、１４０３、１４０４の機能をシミュレートする。これらのサブユニットは モジュールでＳＣＰシミュレータに統合できる。 届いた情報はＦｒｏｎｔ Ｅｎｄ Ｓｙｓｔｅｍ ＳＴ２０００、参照記号１ ４０５で受信され、規定されたＣＰＵ選択基準にそって、ＣＰＵ１４０１から１ ４０４へ完全な処理のために送られる。フロントエンドシステム１４０５は、そ の際一定の遅延時間でシミュレートされる。そのシステムはＳＣＰシミュレータ 内では１つの独自の待ち行列を持つこともある。 続き事象、たとえば、情報ＥＶＥＮＴまたはＥＶＥＮＴ（ＣＡＬＬ ＥＮＤ） は、第１事象が処理されているＣＰＵで自動的に処理される。実際にはそこにコ ールのためのコンテキストが保存されているからである。ＣＰＵへの第１事象の 指示（ＰＲＯＶＩＤＥ ＩＮＳＴＲＵＣＴＩＯＮ）は、さまざまな基準で行うこ とができる。ＳＣＰシミュレータの統計データに関して考慮されるのは、たとえ ば、それぞれのＣＰＵのロード、ＣＰＵの瞬時の状態（アクティブまたは非アク ティブ）と共に、ＣＰＵで処理されるための情報の個数、ＣＰＵで進行する、な いし待っているプロセスのすべての残り待ち時間の総量である。これは統計デー タとそれに対応する決定所見を求めるためのシミュレーション中に演算時間を要 求する。それゆえＣＰＵによる自立した情報受け入れを設定することもできる。 全体の第１事象（情報ＰＲＯＶＩＤＥ ＩＮＳＴＲＵＣＴＩＯＮに対応）は、す べてのＣＰＵで共通の待ち時間に書き込まれる。続き事象（情報ＥＶＥＮＴまた はＥＶＥＮＴ（ＣＡＬＬＥＮＤ）に対応）は、ＣＰＵ特有の待ち時間、場合によ ってはＣＰＵ特有の待ち時間と情報特有の待ち時間に登録される。１つのＣＰＵ のプロセッサがフリーなら、自動的に次の情報がＣＰＵ特有の、または共通の待 ち時間から読み出される。 その事象は、ＣＰＵシミュレーションの内部で処理される際に決められたプロ セス列、たとえば、図１１に示すようなプロセス列を通過する。プロセス列の個 々のプロセスは多くの部分プロセスに分けることができ、その際、部分プロセス の間で別のプロセスが終了することがある。個々のプロセスについて、ＣＰＵに 少なくとも１つのプロセスルーチン１４０８、１４０９、１４１３〜１４１６が あり、それによってプロセス待ち時間１４１０、１４１１に登録されたプロセス が、順番がきているなら処理される。１つのプロセスルーチンは複数のイン カーネーションになってＣＰＵに存在し、その際、たとえば、１つの事象がプロ セスルーチンの１つにサービス特有で割り当てられる。このことは図１４で、そ れぞれ１つのプロセス待ち時間１４１０ないし１４１１を持つ、プロセスルーチ ン１４０８、１４０９、１４１３ないし１４１４から１４１６の２つのブロック によって記号的に示す。 入ってくる事象は次のように処理される。その事象はまずプロセス待ち時間１ ４１０ないし１４１１に登録され、呼び出されたプロセスの、対応するプロセス ルーチンがフリーになるのを待つ。プロセスがスタンバイになるとその事象は優 先待ち時間に入れられる。優先待ち時間１４０７に登録された事象はＣＰＵ１４ ０１によって順番通りに処理される。ＣＰＵによるプロセス処理中に待ち事象、 たとえば、固定プレートへのアクセスをシミュレートするような待ち事象が生じ ることがある。これらの待ち事象は偶然にまたはプロセス条件で生成され、待ち 時間１４１２に登録される。これらの事象は高い優先性をもち、ＣＰＵ１４０１ で進行中のプロセスを中断する。 １つのプロセス処理中に、サービス依存するカウンタ事象が要求されることが ある。それはカウンター１４０６によって生成される。このカウンター１４０６ にはすべてのＣＰＵから質問が入りこみ、互いにブロックすることがある。この ことは、呼び出されたＣＰＵがそれによりロードされないにもかかわらず、プロ セス処理時間の延長をもたらす。 ＣＰＵロードは、ＳＣＰ統計データを得るためにＳＣＰシミュレータによって 次のように算定される。ユーザが指示したそれぞれの時間に、たとえば、ｎシミ ュレーション秒ごとに、残っている、ユーザ定義の時間間隔Δｔの内部で何時間 （％）、ＣＰＵがアクティブだったか、が計算される。つまり最新の時間間隔Δ ｔの中で進行した個別プロセスのすべての時間が加算され、時間間隔Δｔに占 める％割合が計算される。 ＳＣＰロードに関するその他の基準として待ち時間が、それぞれの待ち時間な いしローカルな事象カレンダーの長さから直接生成される。 図１５はＳＳ７レイヤの配置を示す。このレイヤはＳＳＰとＳＣＰとの対話に 関与し、それゆえＳＳ７シミュレータでシミュレートされる。一番上のレイヤ１ ５０１はＳＳ７ユーザのレイヤであり、ＳＳＰないしＳＣＰとＳＳ７との結合を 示す。ここから情報がインテリジェントネットワークないしＳＳ７に送信される か、または受信される。その下にはＴＣＡＰレイヤ１５０２、ＳＣＣＰレイヤ１ ５０３およびＭＴＰレイヤ１５０４（レベル３から１）があり、これらはそれぞ れ固有のプロセッサで決まるＳＳ７機能性を実現する。ＳＳＰからＳＣＰへの情 報流れは、右図のように、レイヤ１５０１から１５０４にまで流れ、１５０１へ 戻り、その際、情報流れは双方向性である。 ＳＳ７のシミュレーションのために、ＳＳ７レベル１５０２から１５０４、つ まりＴＣＡＰ、ＳＣＣＰ、ＭＴＰＩ−３が別々にモデル化される。１つのレベル の個別プロセスは遅延時間によって模倣される。符号化情報の流れを１つのレベ ル内で、ないし２つのレベルの間でシミュレートできるようにするために１つの 待ち行列モデルが使われる。 例として図１６には、ＳＳ７シミュレータ内でのＳＲＰのＭＴＰ３レベル１０ ０８のモデル化が示されている。このレベルで生じる３つのプロセスは、ＭＥＳ ＳＡＧＥ ＤＩＳＴＲＩＢＵＴＩＯＮ（ＨＭＤＴ）、ＭＥＳＳＡＧＥ ＤＩＳＣ ＲＩＭＩＮＡＴＩＯＮ（ＨＭＤＣ）およびＭＥＳＳＡＧＥ ＲＯＵＴＩＮＧ（Ｈ ＭＲＴ）である。プロセス相互の作用（ビヘイビア）と、制限されたレイヤＳＣ ＣＰ１６０７ないし、ＭＴＰ２ １６０９との作用は、図１６ａでは流れ線図と して、図１６ｂではローカルなプロセス待ち行列１６０１、１６０２、１６０３ として示されている。 プロセスＨＭＤＣ１６０４にはレベルＭＴＰ２の符号化情報が含まれ、これは 情報の目標ノードに依存して分配される。プロセスＨＭＤＣ１６０４で処理され る前に、情報はそれに関係するプロセス待ち行列１６０３に入れて整理される。 独自ノードについては、つまりＭＴＰレイヤ１６０８に割り当てられるＳＲＰに ついては、定められた情報がプロセスＨＭＤＴ１６０５に導かれる。それらは、 対応する往路待ち行列１６０１に入れられ、プロセスＨＭＤＴで処理された後に ＳＣＣＰ１００７へ渡される。１つの情報が別のノードに対して定められている 場合は、プロセスＨＭＤＣ１６０４からプロセスＨＭＲＴ１６０６へ導かれる。 このプロセスは情報を、処理された後、つまり対応するプロセス待ち行列１６０ ２からの呼び出しの後にレベルＭＴＰ２ １６０９へ伝える。ＳＣＣＰ１６０７ のレベルＭＴＰ３ １６０８を含む情報についても同様である。 図１６ｂで使われているＦＩＦＯ待ち行列１６０１、１６０２、１６０３は複 数の符号化情報を受け入れ、次々に処理できる状態にある。処理の順番はそれぞ れの遅延時間で決まり、ＳＲＰないしＳＳ７シミュレータのローカルな事象カレ ンダーに登録される。 図１７は、別の例として、ＳＳ７のＴＣＡＰレイヤのモデル化を示す。図１５ の図式のように、ＴＣＡＰレイヤ１７０２は、ＳＳ７−ＵＳＥＲ１７０１とＳＣ ＣＰレイヤ１７０３の間にある。レイヤの間、およびＴＣＡＰレイヤ１７０２に おける情報の流れは矢印で示す。ＴＣＡＰレイヤ１７０２では、４つのプロセス がシミュレートされている。プロセスＩＮＶＯＣＡＴＩＯＮ ＳＴＡＴＥ ＭＡ ＣＨＩＮＥ １７０４、ＣＯＭＰＯＮＥＮＴ ＣＯＯＲＤＩＮＡＴＯＲ １７０ ５、ＤＩＡＬＯＧ ＨＡＮＤＬＩＮＧ １７０６およびＴＲＡＮＳＡＣＴＩＯＮ ＳＵＢ−ＬＡＹＥＲ １７０７である。それぞれのプロセスには、１つのプロ セス待ち行列１７０８〜１７１１が割り当てられている。１つの待ち行列に登録 されていた１つの事象が処理されると、ここに示した情報流れに応じて同じレイ ヤの次のプロセスが呼び出されるか、またはその上か下にあるＳＳ７レイヤにそ の情報が送られる。プロセス列はユーザが決めることができるので、ＴＣＡＰレ イヤ内の真のプロセス流れにフレキシブルに適応可能である。 図１８は、ＳＳ７シミュレータのコンフィギュレーションパラメータの例を示 す。まず、個別のＳＳ７レイヤに関して、ＳＳＰとＳＣＰ間の通信に関与するプ ロセスについてのプロセス時間を指示できる。その際、この例では、ＳＳＰとＳ ＣＰの側でのＴＣＡＰプロセッサとＳＣＣＰプロセッサのプロセス時間、および ＳＳＰ、ＳＴＰおよびＳＣＰエリアのＭＴＰ３レベルのプロセッサのプロセス時 間が指示される。それぞれのレベルで３つまたは４つのプロセスが関与する。Ｓ Ｓ７レイヤでのプロセス順番は、ＳＣＰシミュレーションの場合のサービス処理 プログラムのように、ユーザが決めることができるので、真の条件にフレキシブ ルに適応できる。個別プロセスに、一定の優先性を割り当てることも可能だが、 これについてはここでは記述しない。 図１８の下の表は、ユーザが決めることのできるパラメータを示し、これはＳ Ｓ７のエリアにおけるインテリジェントネットワークのトポロジーに関連する。 たとえば、ＳＣＰの個数、ＳＳＰとＳＴＰの間およびＳＴＰとＳＣＰの間の符号 回路の数、およびプロセッサ相互間の遅延である。そのほかに情報長さも指示で きる。 図１９は、オンライン運転でのＩＮシミュレータでの過負荷防御シミュレータ １９０３のインプリメンション（実行）およびその基本的な機能を示す。過負荷 防御シミュレータ１９０３は、この例では、トラヒックシミュレータ１９０２が 生成した、または送ったトラヒック量をシステムデータに基づいて制御し、それ は瞬時の負荷状況、特にＳＣＰシミュレータの負荷状況についてのメッセージを 許容し、オンラインシミュレータ１９０１によって管理され、過負荷防御シミュ レータ１９０３に、オンラインインタフェースを介して伝達される。 ここで示す例では、過負荷防御シミュレータ１９０３はトラヒックシミュレー タ１９０２が生成した、または送ったトラヒック量を自動コールギャッピング（ ＡＣＧ）の原理で制御する。時間間隔Δｔ１（ギャップ時間）の中で、たとえば 、そのつど１つのコールだけを、場合によってはあらかじめ決めた特性をもたせ てＳＳＰからＳＣＰへ通過させる。時間間隔Δｔ２（ギャップ持続）は、そうし た低減措置がどのくらい続くかを示す。「Ｌｅａｋｙ Ｂｕｃｋｅｔ」の原理に そった過負荷防御メカニズムも、過負荷防御シミュレータ１９０３で模倣できる 。 過負荷シミュレータ１９０３（オーバーロードプロセス）は、トラヒックシミ ュレータ１９０２によって呼び出される。それは、対応するパラメータ、たとえ ば、サービス識別番号、情報識別番号、ＳＳＰ識別番号、時間で１つのコールを 伝達する。このデータのほかにオーバーロードプロセスは、実際のシステムデー タ、たとえば、ＣＰＵロード、回答時間および待ち行列を、オンラインシミュレ ータ１９０１から受け取る。１回初期化されたオーバーロードプロセスは、独自 のカウンタと伝えられたシステムデータによって進行する。個々のＳＳＰ、サー ビス、および／またはサービス等級に関して、独自のカウンタを設けることがで きる。そのコールが対応するカウンタで把握されると、過負荷防御シミュレータ はシステムデータによって実際の過負荷レベルを計算する。続いて実際の過負荷 レベルのためのギャップパラメータが初期化表から読み出される。初期化表は初 期化データファイルに入っており、それは過負荷防御シミュレータ１９０３のス タート時に呼び出される。ギャップパラメータは、たとえば、１つのコー ル、場合によっては定められた特性を持つコールがＳＳＰからＳＣＰへ通される 時間間隔Δｔ１（ギャップ時間）、およびそうした低減措置がどのくらい続くか を示す時間間隔Δｔ２（ギャップ持続）である。 実際の過負荷レベルを計算するためには、決められた時間窓の中ですべてのコ ールがカウントされ、場合によっては時間で重みを付けられる。重みは、好適に は、コールの古さに指数的に依存しており、その際若い方のコールは古い方のコ ールよりも強く重みをかけられる。さらにＳＳＰないしサービスへのロードの分 配がなされ、サービス依存および／またはＳＳＰ依存の過負荷防御をシミュレー トできるようになり、その際、決められた特性を持つコールが選ばれて押さえら れる。 さまざまな過負荷レベルをユーザは定義でき、それにはユーザ定義のギャップ パラメータが割り当てられている。 過負荷レベルが計算された後、ギャップ措置が現実化され、たとえば、時間間 隔Δｔ１ないしΔｔ２の長さが適合される。次いで実際のコールがそうした措置 の下位になるかどうかが検査される。呼び出されるプロセスには、成功した場合 、返還値ＴＲＵＥまたはその他の特性記号がつけられ、そうでなければ値ＦＡＬ ＳＥないしその他の、それに割り当てられた特性符号がつけられる。 返還値はトラヒックシミュレータ１９０２によって評価される。ＦＡＬＳＥの 場合は、互いに調整された確率が次のコールを生成する。ＴＲＵＥの場合、コー ルはトラヒックシミュレータ１９０２によってオンラインインタフェースへ送ら れ、そこからコールはＳＣＰシミュレータないしＳＳ７シミュレータに伝えられ る。トラヒックシミュレータは１つの新しいコールを生成し、プロセスが新たに 始まる。 図２０は、データファイル運転でのＩＮシミュレータでの過負荷防御シミュ レータ２００２のインプリメンション（実行）を示す。データファイル運転では コールは先にトラヒックシミュレータによって生成され、伝達データファイル２ ００１に入れられる。データファイル運転では、実際のシステムデータは過負荷 防御シミュレータ２００２には送られないので、シミュレータ自体が、時間単位 ごとのコールの形になっている実際のロードを測定する。実際のロードを、トラ ヒックシミュレータから出されるコールの最大の回数に関して決められた値と比 較する。この値が、たとえば、初期化データファイルに保存される。実際に入り こんだロードと出ていく最大のロードから実際の過負荷レベルが計算される。オ ンライン運転に対してアナログで、新しい防御パラメータが初期化表から読み出 され、防御措置が現実化される。 図２１は、ＩＮシミュレータで求めたシミュレーションデータの例である。こ れは、図６、図１１、および図１８に示されているコンフィギュレーションデー タファイルから作られるコンフィギュレーションが基礎になっている。ＳＳ７シ ミュレータは、過負荷防御シミュレータが接続解除されている間、アクティブで ある。時間間隔０から５００秒で、１秒ごとにコール３０回の電話トラヒックが 設定された。 図２１ａ−ｃは、シミュレータがネットワーク統計のために算出したデータを 示す。図２１ａには選んだ平均電話トラヒック、およびトラヒックシミュレータ によって生成された電話トラヒックが、それぞれシミュレーション時間の関数と して示されている。調整された電話トラヒックには線が引いてあり、上述の条件 に対応する。つまり間隔０から５００秒でコンスタントに１秒に３０回コールが あり、その後０になる。生成された電話トラヒックは直線で示してあるが、あら かじめ選んだ平均値のところで統計的変動が見られる。電話トラヒックはｔ＝５ ００ｓになるとゼロになる。 図２１ｂはシミュレーション時間の関数としてのＳＣＰ回答時間（秒）を示す 。１秒で約３０回のコールというコンスタントな電話トラヒックでは、このシミ ュレーション結果にそった定常状態になる。つまりＳＣＰは出された質問に０． ４から０．７秒の回答時間で対応する。 図２１ｃは、処理のためにＳＣＰシミュレータに入っているシミュレーション 時間の関数となる情報の個数を示す。ＳＣＰでのコールの回数とＳＣＰの回答時 間は互いに相関することが望ましい。 図２１ｄ−ｆは、時間の関数となるＳＣＰ統計データ、％でのＣＰＵのロード 、ＣＰＵ待ち行列での情報の個数、時間単位ごとに１つのＣＰＵで処理されるプ ロセスの個数を示す。それぞれ最大、最少および平均のＣＰＵロード、待ち行列 長さ、およびディスパッチの個数が示されている。ある一定の時間にＳＣＰでは 、処理されている情報の個数は、図２１ｃにそって２０から６０の間を揺れ動き 、一方、待ち行列には図２１ｅでは平均で６つの情報しか入っていない。この数 値から、また平均ＣＰＵロードが８０％であることからも、ＳＣＰは選んだコン フィギュレーションで、１秒に３０回コールという１つのトラヒック発生を問題 なく処理することが理解できる。 図２１ｇ−ｉはＳＳ７統計データを示す。図２１ｇは図２１ａに対応し、シミ ュレーション時間の関数となる、調節された、ないし生成された電話トラヒック を示す。図２１ｈはＳＳＰからＳＣＰへの途中でのＳＳ７シミュレータの情報の 遅延（線が消してある）を時間の関数として、およびＳＣＰからＳＳＰへの途中 での１つの情報の遅延（点々になっている）を示す。図２１ｉは、ＳＣＰ方向（ 線が消してある）でのＳＳ７の情報の個数ないし、ＳＳＰ方向（点々になってい る）での情報の個数をシミュレーション時間の関数として示す。符号化システム での遅延はＳＣＰのそれよりもかなり下にあり、最大値０．０４５秒になる。 図２１ｊは時間の関数となるＳＳＰ統計データを示す。つまりＳＳＰ１ないし ＳＳＰ２（左ないし右のグラフ）からＳＳＰ１ないしＳＳＰ２への占有されてい る回線の数を示す。ＳＳＰから、およびＳＳＰへの占有されている回線の数は約 ３００のときに定常状態になる。Ｔ＝３００秒の時に全体の電話トラヒックはＳ ＳＰ１からＳＳＰ２に代わる。これはトラヒックデータファイルで調節されてい た。 図２２はＩＮシミュレータで算出し別のシミュレーションデータの例を示す。 大きく変わるトラヒック発生の時のデータである。トラヒック発生は１００秒ご とに変化した。１秒ごとに４０から２０、８０、１０、５０、および５回コール に変わった。ＳＳ７シミュレータは、過負荷防御が非アクティブである間はアク ティブである。シミュレートされる大きさは図２１と同じ大きさで表わす。 図２２ａでは、生成されたトラヒックはｔ＝２５０秒までは、調節されたトラ ヒック発生をフォローするが、その際、生成されたトラヒック発生には統計的変 動による歪みが見られる。ｔ＝２５０秒の時点で生成されたトラヒック発生、つ まりＩＮに届き、トラヒックシミュレータによって生成された情報の個数は、基 準よりもかなり少なくなっている。これについては図２２ｊを使って説明する。 ネットワークに通じる回線はすべてｔ＝２５０秒のときに占有されるているので コールのほんの一部だけがＩＮ事象になることができる。 図２２の過負荷防御が介入しないシミュレーションでは、１秒にコール３０回 という限度を超えると直ちにＳＣＰ回答時間が大幅に増加する。ＳＣＰでのコー ル回数およびＳＣＰ待ち行列長さも同様に増える。この限度が３０回を下回ると 、ＳＣＰは待っている情報を処理できるようになるので、遅延時間と待ち行列の 長さも減少する。中央の符号化システムの情報の処理時間は、さまざまなトラヒ ック量にもかかわらず０．０２秒だけ変動する。 図２３は、図２２の場合と同じに調整されたトラヒック発生でのシミュレーシ ョンを示すが、ここではアクティブな過負荷防御シミュレータが付いている。過 負荷防御シミュレータには１秒にコール３０回という最大のトラヒック発生が設 定された。図２３ａから、生成されたトラヒック発生は、コール平均３０回に制 限されていることがわかる。ＳＣＰの回答時間（図２３ｂ）は、それゆえ約０． ４から０．５秒の値に減少したが、これは、図２１の例で、コンスタントなトラ ヒック発生について１秒に３０回コールで算出したＳＣＰ回答時間に対応する。 回答時間はそれによって図２２の例よりも係数で１００小さくなる。 実用性： 本発明のＩＮシミュレータは、インテリジェントネットワークの計画、および 運転のすべての段階で、ネットワークのパフォーマンスを試験し、一定の基準に 適合させ、ならびに弱点部分を見つけ出すために、意味のあるツールである。シ ミュレーションモジュールのフレキシビリティーが大きいので、与えられたリア リティ、将来のリアリティにも適合させることが問題なく可能である。シミュレ ートされた値、およびシミュレーションに基礎を置くパラメータを比べることに よって、真のインテリジェントネットワークのコンフィギュレーションを、与え られた限界条件でＩＮの最良の効率が実現されるように、選択することが可能に なる。このことは、インテリジェントネットワークの運転および計画の際のコス トの大幅な削減に通じる。ＩＮシミュレーションを使えば、インテリジェントネ ットワークおよびその構成要素の最適なコンフィギュレーションが確かめられ、 真のＩＮでの高価な実験時間を必要とすることなく、直接、リアリティに変える ことが可能である。ＩＮシミュレータは、たとえば、不確実な過負荷防御の基礎 を安定させることのできる管理パラメータを算出するための適切なツールである 。シミュレーションの結果は、一般的な大域の管理機能またはネットワークノー ド 関連の管理機能の開発と検証をも可能にし、それはこれまで使われた過負荷防御 メカニズムよりもより効果的に実現され、導入できる。 参照番号一覧： １０１ 交換局 １０２ ＳＳＰ １０３ ＳＴＰないしＳＲＰ １０４ ＳＣＰ入力プロセッサ １０５ 電話−有効回路 １０６，１０７，１０８ ＳＳ７回路 １０９ ＳＣＰ ２０１，３０１，４０１，１９０２ トラヒックシミュレータ ２０２，３０２，４０２ ＳＣＰシミュレータ ３０３，４０３，５０３ ＳＳ７シミュレータ ２０３，２０４，３０４，３０５，３０６，３０７，４０６−４０９，２００１ 伝送データ ２０５，３０８，４２３ ＳＣＰ出力データ ２０６，３０９ トラヒック出力データ ３１０ ＳＳ７出力データ ２０７，３１１，４１６ ＳＣＰ入力データ ２０８，２０９，２１０，２１１，２１２，３１２−３１６，４１１−４１４ トラヒック入力データ ３１７，４１５ ＳＳ７入力データ ４０４，５０２，１９０３，２００２ 過負荷防御シミュレータ ４１０ ユーザエリア ４１７−４２０ プロトコルデータ ４２１ ファイル名称−データ ４２２ 過負荷防御−入力データ ５０１ 「ブラックボックス」 １２０１，１３０１，１４０１，１４０２，１４０３，１４０４ ＣＰＵ １２０２，１２０３ ＬＡＮ（ＳＳ７に接続するため） １２０４，１２０５，１２０６，１２０７，１４１０，１４１１ サービス特有 の待ち行列（キューイング） １２０８ ＩＮ情報／事象 １２０９，１３０６ 進行できないプロセスに関する待ち行列 １２１０，１４０７ （アクティブ化され、進行できるプロセスに関する）優先 性待ち行列 １３０２，１３０３，１３０４，１３０５，１６０１，１６０２，１６０３ プ ロセス特有の待ち行列 １３０７−１３１０，１４０８，１４０９，１４１３−１４１６，１６０４，１ ６０５，１６０６，１７０４−１７０７ プロセスルーチン １４０５ フロントエンドシステム １４０６ カウンタ １４１２ 「待ち事象」 １５０１，１７０１ ＳＳ７ユーザレイヤ １５０２，１７０２ ＴＣＡＰレイヤ １５０３，１７０３，１６０７ ＳＣＣＰレイヤ １５０４，１５０５，１５０６，１６０８，１６０９ ＭＴＰレイヤ ４０５，１９０１ オンラインシミュレータ

───────────────────────────────────────────────────── フロントページの続き (72)発明者 フィッシャー，ハンス ディーター ドイツ国．デー―44879 ボクム，フォー ゲルベーアヴェグ 41 (72)発明者 グレーガー，ベルトホルト ドイツ国．デー―45721 ハルテルン，ヴ ィーケルシュトラッセ ２ (72)発明者 ライヒ，フリッツ−ユルゲン ドイツ国．デー―44799 ボクム，ツェダ ーンヴェグ ６ 【要約の続き】 モジュール（３０３，４０３，５０３，４０４，５０ ２）が、好適には、サービス中継ポイントＳＲＰ（１０ ３）の機能を考慮しながら、ＩＮ内部の過負荷防御メカ ニズムによって設定されている。シミュレーションモジ ュールはデータファイルモードで伝達データファイルを 介して、またはオンラインモードで共通の組織プログラ ムを介して、オンラインシミュレータに接続されてい る。オンラインモードでのシミュレータの中央要素は事 象カレンダーであり、その中にはシミュレーションモジ ュールが処理する事象が処理の順番で登録されており、 実際には平行に進行するプロセスを連続処理することを が可能になる。本発明のＩＮシミュレータにより、現在 実現されるＩＮ、および将来実現されるＩＮのパフォー マンスを有利に算定できるようになり、その結果弱点ポ イントが見つけ出され、ＩＮの効率が向上する。

Claims (1)

1. 【特許請求の範囲】 １．ＩＮ特有のコール番号が伝送される１つ以上のサービス交換ポイントＳＳ Ｐ（１０２）、ＳＳＰにコール処理のための情報を提供するサービス制御ポイン トＳＣＰ（１０９）、およびＳＳＰ（１０２）とＳＣＰ（１０９）の対話がそれ を介して行われる符号化システム７番（ＳＳ７）で構成されるインテリジェント ネットワーク（ＩＮ）のシミュレーションのためのシミュレータであって、以下 の構成要素を有しているシミュレータ： １．１ トラヒック理論の基本にそった任意のＩＮ型の事象列（トラヒックシ ミュレータ）をシミュレートするための１つのモジュール（２０１，３０１，４ ０１）、 １．２ プロセスモデルを使ったサービス制御ポイント（ＳＣＰシミュレータ ）の事象指向シミュレーションのための１つのモジュール（２０２，３０２，４ ０２）、 １．３ モジュール間のデータ受け渡しのための装置（２０３，２０４，３０ ４−３０７，４０６−４０９）、 １．４ ネットワークコンフィギュレーション、通信サービス仕様およびその 他のシミュレーションパラメータを入力し、保存するための、ならびにそれを対 応するモジュールへ渡すための装置（２０７，３１１，４１６，２０８−２１２ ，３１２−３１７，４１１−４１５）、 １．５ シミュレートされたデータを出力させるため、および／または保存す るための装置（２０５−２０７，３０８−３１０，４１７−４２０，４２３）。 ２．プロセスモデルおよび／または一定の遅延時間を基本にした符号化システ ム７番（ＳＳ７シミュレータ）の事象指向シミュレーションのための１つのモ ジュール（３０３，４０３，５０３）が設定されていることを特徴とする請求項 １に記載のシミュレータ。 ３．ＳＳ７シミュレータ（３０３，４０３，５０３）が構成要素ＳＳＰ、信号 伝達ポイントないし信号中継ポイント（ＳＴＰないしＳＲＰ）およびプロセスモ デルによるＳＣＰとの結合をシミュレートし、ならびにＳＳＰ、ＳＴＰおよびＳ ＣＰ間のＳＳ７符合回路を一定の遅延によってシミュレートすることを特徴とす る請求項２に記載のシミュレータ。 ４．１つのモジュール（４０４、５０２）が過負荷防御メカニズムのシミュレ ーションのために設定されており（過負荷防御シミュレータ）、１つ以上のその 他のモジュールによって処理される事象の個数が、１つまたは複数のシミュレー ションモジュールのロードに依存して、たとえば、待ち行列長さに依存して、ユ ーザ定義パラメータによって変更されることを特徴とする請求項１から請求項３ の何れか１項に記載のシミュレータ。 ５．過負荷防御シミュレータ（４０４，５０２）が、トラヒックシミュレータ （２０１，３０１，４０１）によって生成され、および／または伝送された事象 の量をＳＣＰシミュレータ（２０２，３０２，４０２）のロードに依存して制御 することを特徴とする請求項４に記載のシミュレータ。 ６．ネットワークコンフィギュレーションおよび／または通信サービス仕様を 提示するために１つ以上の、好適には、複数個の、次項に記すパラメータを、仕 様エディター、特にユーザレベル（４１０）への入力によってユーザが定義でき 、その際、パラメータは１つまたは複数のコンフィギュレーションデータファイ ル（２０７，３１１，４１６，２０８−２１２，３１２−３１７，４１１−４１ ５）に保存され、シミュレーション開始時に、それぞれのシミュレーションモジ ュールに渡されることを特徴とする請求項１から請求項５の何れか１項に記載 のシミュレータ： ６．１ ＳＳ７シミュレーション関係：ＳＳＰの個数、ＳＴＰ／ＳＲＰの個数 、ＳＴＰ／ＳＲＰとＳＣＰないしＳＳＰ間の符号回路の個数、ＳＴＰ／ＳＲＰと ＳＣＰないしＳＳＰ間の遅延、ＭＴＰ１、ＭＴＰ２、ＭＴＰ３、ＳＣＣＰ、ＴＣ ＡＰのようなさまざまなＳＳ７レイヤに導入されているプロセッサの種類および ／または個数、その上を進行するプロセス（プロセス時間つき）の種類および／ または個数、それらのプロセッサ間の遅延、 ６．２ ＳＣＰシミュレーション関係：ＳＣＰのプロセッサ（ＣＰＵ）の種類 および／または個数、プロセッサ（たとえば、サービス特有の）への事象の割り 当ての方式、ＳＣＰで進行中のプロセスの種類、持続時間、および／または優先 性、ＩＮ事象のＳＣＰプロセス列への変換の方式、ＣＰＵごとのプロセスのイン カーネーションの個数、 ６．３ トラヒックシミュレーション関係： ６．３．１ −般パラメータ：タイムアウトまでの時間、方向転換時の遅延時 間、ＳＳＰからの回線数、および／またはＳＳＰへの回線数、その次のコールの 確率、その次のコールの最大回数、平均／最長メッセージ時間、メッセージ場所 の数、 ６．３．２ サービス特有のパラメータ：平均通話時間および／またはメッセ ージ時間、最長メッセージ時間、メッセージ場所の数、メッセージ確率、方向転 換確率、回線数、 ６．３．３ ＴＶサービスの関係：開始時間、終了時間、その次のコールに関 する終了時間、目標値、目標値の数、 ６．４ 過負荷防御シミュレータ関係：臨界的ＳＣＰ、待ち行列長さ、臨界的 ＳＣＰロード、ＳＳＰでのコール防御の持続時間。 ７．トラヒックシミュレータ（２０１，３０１，４０１）がＩＮ型事象列を、 全体的にまたは部分的にユーザが定義できるステートメントに基づいて生成し、 それは１つまたは複数のデータファイルに保存され、シミュレーション開始時に トラヒックシミュレータに渡され、その中には少なくとも以下が含まれているこ とを特徴とする請求項１から請求項６の何れか１項に記載のシミュレータ： ７．１ 時間単位ごとの、その都度考慮すべきＩＮサービスおよび／またはサ ービス加入者および／またはＳＳＰごとのコールにおける平均トラヒック量の時 間的流れについてのステートメント、 ７．２ 下記の場合の、コールの別の運命の確率についてのステートメント、 ７．２．１ ＳＣＰからの別の処理情報を得た後、たとえば、伝送が成功した 後の平均通話時間ないしメッセージ持続時間、伝送ができない確率（話し中、加 入者が出ない場合）、 ７．２．２ ＳＣＰから別の処理情報、たとえば、タイムアウト、発呼者が電 話機を置くという情報が得られる前に、１つの事象列が生成される場合、 ７．３ そこでは、個々のシミュレーション時間間隔に関して、考慮すべきＩ Ｎサービスおよび／またはサービス加入者、および／またはＳＳＰごとに、１つ の適切な確率分布を想定して、好適には、ポアゾン分布および７．１項に対応し て先に決められた瞬時の平均トラヒック量を考慮して１つのコールないし第１事 象（ＰＲＯＶＩＤＥ ＩＮＳＴＲＵＣＴＩＯＮ）が生成され、生成時間に依存し て事象カレンダーに登録され、 ７．４ １つのコールないし第１事象に割り当てられたその次の情報ないしそ の次の事象（ＥＶＥＮＴ，ＥＶＥＮＴ（ＣＡＬＬ−ＥＮＤ））が、６．２項のス テートメントを考慮して生成され、生成時間に依存して事象カレンダーに登録さ れ、 ７．５ 事象カレンダーはそれによって全体の第１事象とその次の事象を年代 順に受け入れる。 ８．トラヒックシミュレータ（２０１，３０１，４０１）によって生成された コール、ないしシミュレータを通過する時に生成されたＩＮ情報のそれぞれに関 して、次の時間ラベルがプロトコル化されることを特徴とする請求項１、請求項 ６、または請求項７に記載のシミュレータ（時間ラベル：コールないし第１事象 が生成されるときの時間ラベルｔ１、これはＳＳＰでのその情報の生成時点に対 応する；トラヒックシミュレータ（２０１，３０１，４０１）からの１つの情報 がＳＣＰシミュレータ（２０２，３０２，４０２）によって処理された後の時間 ラベルｔ４）。 ９．トラヒックシミュレータ（２０１，３０１，４０１）が生成したコールの それぞれに関して、そのシミュレータを通過するときに次の時間ラベルがプロト コル化されることを特徴とする請求項２から請求項７の何れか１項に記載のシミ ュレータ（時間ラベル：コールないし第１事象の生成されるときの時間ラベルｔ １。これはＳＳＰでのその情報の生成時点に対応する。トラヒックシミュレータ からの１つの情報がＳＳ７シミュレータ（３０３，４０３，５０３）によって処 理された後の時間ラベルｔ２。ＳＳ７シミュレータからの１つの情報がＳＣＰシ ミュレータ（２０２，３０２，４０２）によって処理された後の時間ラベルｔ３ 。ＳＣＰシミュレータ（２０２，３０２，４０２）からの１つの情報がＳＳ７シ ミュレータによって処理された後の時間ラベルｔ４）。 １０．以下を特徴とする請求項１から請求項９の何れか１項に記載のシミュレ ータ： １０．１ トラヒックシミュレータ（２０１，３０１，４０１）が生成した事 象列が第１の伝達データファイル（２０３）に登録され、それはＳＣＰシミュ レータに渡され、それによって処理され、その際それぞれの事象に関して、ＳＳ Ｐでのその情報の生成時点に対応する時点ｔ１が保存されており、 １０．２ ＳＣＰシミュレータが処理した事象が第２の伝達データファイル（ ２０４）に登録され、それはトラヒックシミュレータに渡され、その際それぞれ の事象に関して、ＳＣＰでのその次の情報の生成時点とＳＳＰへのその情報の到 着時点に対応する時点ｔ４が保存されていること（データファイルモード）。 １１．以下を特徴とする請求項２に記載のシミュレータ： １１．１ トラヒックシミュレータが生成した事象列が第１の伝達データファ イル（３０４，４０６）に登録され、それがＳＳ７シミュレータに渡され、それ によって処理され、その際それぞれの事象に関して、ＳＳＰでのその情報の生成 時点に対応する時点ｔ１が保存されており、 １１．２ ＳＳ７シミュレータが処理した事象が第２の伝達データファイル（ ３０５，４０７）に登録され、それがＳＣＰシミュレータに渡され、その際それ ぞれの事象に関して、その情報がＳＣＰに到着した時間に対応する処理時間ｔ２ が保存されており、 １１．３ ＳＣＰシミュレータが処理した事象が第３の伝達データファイル（ ３０６，４０８）に登録され、それがＳＳ７シミュレータに渡され、その際それ ぞれの事象に関して、ＳＣＰでの、続き情報の生成時点に対応する時点ｔ３が保 存されており、 １１．４ ＳＳ７シミュレータが処理した事象が第４の伝達データファイル（ ３０７，４０９）に登録され、それはトラヒックシミュレータに渡され、その際 それぞれの事象に関して、その情報がＳＳＰに到着した時間に対応する時間ｔ４ が保存されていること。 １２．ステップ１０．１および１０．２ないし１１．１から１１．４までが多 数回、次々に実行され、その際、トラヒックシミュレータが続き事象を生成する ためのステップ１０．１ないし１１．１において最初の通過がなされる時に、一 定のＳＣＰ遅延時間ないしＳＣＰとＳＳ７の遅延時間が想定され、その遅延時間 はその後のサイクルにおいて、第２ないし第４の伝達データファイルから、ＳＣ ＰシミュレータないしＳＣＰとＳＳ７のシミュレータを通過した後に、算出され た回答時間によって変更されることを特徴とする請求項１０または請求項１１に 記載のシミュレータ。 １３．トラヒックシミュレータに割り当てられたローカルな事象カレンダーで あって、そこにはトラヒックシミュレータが処理した事象が登録されている事象 カレンダーを特徴とする請求項１から請求項９の何れか１項に記載のシミュレー タ。 １４．ＳＳ７シミュレータに割り当てられたローカルな事象カレンダーであっ て、そこにはＳＳ７シミュレータが処理した事象が、それらの時間ラベルおよび ／または優先性の関数として登録されている事象カレンダーを特徴とする請求項 １から請求項９または請求項１３の何れか１項に記載のシミュレータ。 １５．ＳＣＰシミュレータに割り当てられたローカルな事象カレンダーであっ て、そこにはＳＣＰシミュレータが処理した事象がそれらの時間ラベルおよび／ または優先性の関数として登録されている事象カレンダーを特徴とする請求項１ から請求項９、請求項１３または請求項１４の何れか１項に記載のシミュレータ 。 １６．１つのローカルな事象カレンダーには複数の接続された待ち行列があり 、それらにはシミュレーションモジュールの下部構成要素によって処理される事 象が入っていることを特徴とする請求項１３から請求項１５の何れか１項に記載 のシミュレータ。 １７．１つの大域の事象カレンダーであって、それには、ＳＳＰ、ＳＣＰ間の 情報、場合によってはＳＳ７システムに対応する事象（大域外部事象）と、トラ ヒックシミュレータおよび／またはＳＣＰシミュレータのモジュール、および／ またはＳＳ７シミュレータを参照せよとの指示が、共通の待ち行列として入って おり（大域内部事象）、その際その事象は時間および／または優先性の関数とし て大域事象カレンダーに登録される（オンラインモード）ような１つの大域事象 カレンダーを特徴とする請求項１３から請求項１６の何れか１項に記載のシミュ レータ。 １８．ネットワーク構成要素内のコールに依存しない行程、たとえば、ＳＣＰ プロセッサ内での運転システム干渉を考慮するために、コールに依存しない事象 が偶然に生成され、大域の事象カレンダー、および場合によっては対応するロー カルな事象カレンダーに登録され、それぞれのシミュレーションモジュールによ って処理されることを特徴とする請求項１７に記載のシミュレータ。 １９．シミュレータとシミュレーションモジュールにそれぞれ１つのシミュレ ータ時計が割り当てられており、それは大域の、ないしローカルな事象カレンダ ーからの１つの事象を処理している間は止まっており、それが終わると、対応す る大域の、ないしローカルの事象カレンダーに登録されているその次の事象の時 点に進められることを特徴とする請求項１から請求項１８の何れか１項に記載の シミュレータ。 ２０．１つのシミュレーションモジュールが、定義された持続時間（Δｔ）を 持つ１つの、または一連の内部事象を、ユーザ定義可能な、１つの外部情報ない し１つの外部事象に分類し、個別事象をローカルな事象カレンダーに登録（内部 事象の生成）することを特徴とする請求項１から請求項１９の何れか１項に記載 のシミュレータ。 ２１．以下を特徴とする請求項２０に記載のシミュレータ： ２１．１ １つのシミュレーションモジュールが、大域の事象カレンダーに登 録されており、ローカルな事象カレンダーを考慮するように指示する内部事象に よってその次の内部事象を処理するために呼び出され、 ２１．２ その事象が処理されると内部シミュレーション時計が合わされ、そ の際、 ２１．３．１ プロセスチェーンに帰属する事象がもう１つ存在する場合は、 実際の内部シミュレーション時間で、その次の内部事象を考慮するようにとの指 示が大域の事象カレンダーに登録され、 ２１．３．２ または、実際に処理された事象がプロセスチェーンの最後であ る場合は、１つの外部事象がシミュレーションモジュールによって生成され、実 際の内部シミュレーション時間で大域の事象カレンダーに登録される。 ２２．電話通常トラヒックがトラヒックシミュレーションに加えられることを 特徴とする請求項１から請求項２１の何れか１項に記載のシミュレータ。 ２３．一定の時間間隔で、またはあらかじめ決められるシミュレーション時間 に関して、１つ以上の、下記のネットワークロード量がそれに関係するシミュレ ーション時間で出力データファイルに書き込まれることを特徴とする請求項１か ら請求項２２の何れか１項に記載のシミュレータ。 （ネットワークロード量： トラヒックシミュレータが生成し、ＩＮに届く時間単位ごとのコール回数。 ＳＣＰシミュレータへの途中のＳＳ７シミュレータで処理されている情報の数 。 ＳＣＰシミュレータにある情報の数。 トラヒックシミュレータへの途中のＳＳ７シミュレータで処理されている情報 の数。） ２４．ＳＣＰシミュレータが、一定の時間間隔で、または決められたシミュ レーション時点に関してＣＰＵロードおよび／または待ち行列長さおよび／また は時間単位ごとに処理されたプロセス（ディスパッチ）の数を、それぞれＣＰＵ 番号にそって個別化し、および／またはすべてのＣＰＵを介して、および／また はＣＰＵの最小値および最大値をＳＣＰ統計の大きさとして関連するシミュレー ション時間で、１つの出力データファイルに書きこむことを特徴とする請求項１ から請求項２３の何れか１項に記載のシミュレータ。 ２５．一定の時間間隔で、またはあらかじめ決められたシミュレーション時点 に関して、占有された回線の数が、ＳＳＰ特有で、１つの伝送場所で、および／ またはＩＮにおいてプロトコル化され、１つのデータファイルに書き込まれるこ とを特徴とする請求項１から請求項２４の何れか１項に記載のシミュレータ。 ２６．ユーザレベルが設定されており、それはシミュレーションパラメータの 入力によりシミュレーションを生成するための入力要素になり、それはコンフィ ギュレーションデータファイルを管理し、シミュレーション結果がグラフィック で示されるようになることを特徴とする請求項１から請求項２５の何れか１項に 記載のシミュレータ。 ２７．その他のネットワーク構成要素の事象指向のシミュレーションのための １つのモジュールが設定されており、特にサービス管理システム（ＳＭＳ）およ び／またはインテリジェント周辺機器（ＩＰｓ）のシミュレーションのための１ つのモジュールが設定されていることを特徴とする請求項１から請求項２６の何 れか１項に記載のシミュレータ。