JPH07501675A - スイッチングによるコネクションの処理のためのオブジェクト指向プログラミング方式により構築されたプログラムモジュールを備えたプログラム制御ｉｓｄｎ交換システム - Google Patents

Abstract

(57)【要約】本公報は電子出願前の出願データであるため要約のデータは記録されません。

Description

【発明の詳細な説明】 スイッチングによるコネクションの処理のためのオブジェクト指向プログラミン グ方式により構築されたプログラムモジュールを備えたプログラム制御ｌ５ＤＮ 交換システム 公知のＩ　ＳＤＮ通信システムは標準化インターフェースを有する明確に規定さ れた機能モジュールを備える。種々異なる制御コンピュータへの機能分割により 種々の役割、タスクへの適合化及び機能及び新たな機能及びサービスフィーチャ の導入によってもシステム構造への影響が及ぼされないことが達成される。

側副″Ｄｉｅｎｔｓ　ｔ　ｉｎｔｅｇｒ　１ｅｒｅｎｄ−ｅｓ　Ｄｉｇｉｔａｌ ｎｅｔｚ　ｌ５ＤＮ”、Ｔｅｌｃｏｍ　Ｒｅｐｏｒｔ　８，１９８５．Ｓｉｅｍ ｅｎｓ　ＡＧ、　において、そのような通信システムとして″Ｓｉｅｍｅｎｓ″ 交換システムの主要な側面力（記載されている。

交換システムのハードウェア構造もソフトウェア構造もモジュラ一方式に従って 分けられている。ソフトウェア、即ち交換システムのプログラーム技術上のコン ポーネントがシステムプログラムモジュール−オペレーティングシステム、信号 転送制御、データ保護、作動技術（管理、保護技術）−に細分化され得る。

オペレーティングシステム機能は適用例に依存しないが、信号転送（機能）はＩ 　ＳＤＮ固有のサブシステムにより形成される。交換技術のシステムプログラム モジュールは端末機器のユーザインターフェースないし種々のネットワークへの インターフェース向けの本来の（アクチュアル）なサービスを提供する。

交換システム−システムプログラふモジエールの領域ではなお予期さるべき標準 化アクティビティに基づき、大きなコストをかけずに変更及び補充を行い得、そ して当該システムに課せられた実時間要求を充足することが重要である。

本発明の目的ないし課題とするところはＩ　ＳＤＮ通信システムに対して少なく とも交換システム用のプロトコルモジュールを次のように構造化する、即ち、機 能チャネル上のシーケンスにて変更及び補充が可及的にわずかなコストで実施可 能であり、交換システムにて誤り探索障害追跡（トラブルシューティング）が簡 単化されるように構造化することにある。

上記課題は請求の範囲１にて規定された構成要件により解決される。

交換システム用の（ないし呼処理）のプログラミングはオブジェクト指向プログ ラミングの方式により行われる。オブジェクト指向プログラミングのための詳細 情報は例えば下記文献に示されている。

Ｍｅｙｅｆ、１３．：　”Ｏｂｊｅｃｔｏｒｉｅｎｔｅｄ　Ｓｏｆｔｗａｒｅ　 Ｃｏｎ５ｔｒｕｔｉｏｎ”Ｐｒｅｎｔｉｃｅ−Ｈａｌｌ、Ｅｎｇｌｅｗｏｏｄ　 Ｃｊｉｆｆｓ、Ｎｅｗ　Ｙｏｒｋ、１９８８．又はＦｒａｕｎｈｅｉｍ、Ｂ、ａ ｔ　ａｌ： ”０ｂｊｅｋｔｏｒｉｅｎｔｉｅｒｔｅ　Ｐｒｏｇｒａｍｍｉｅｒｕｎｇ”　（ Ｃ＋＋プログラミングコース。

分冊１０８３分冊４．Ｅｌｅｋｔｒｏｎｉｋ　１９９０　第２２．、．２５巻 従来の手順プロセデュア的メソッド（手法）　（該手法では２つの相互に別個の 構造要素、即ち何等かの情報を成すデータ及びプログラム手順、プロセデュアで あって該手順の処理の際、データを処理加工して情報処理加工のために利用され るような当該手順プロセデュアが存在するにおける場合と異なって、オブジェク ト指向プログラミングでは次のような構造要素のみが存在する、即ちデータ及び プログラム手順プロセデュア（メソッド）のユニットからなり、外部に向かって 閉じられた構造を成す構造要素のみが存在する。そのような構造は一般的にオブ ジェクトと称される。

本発明によればプログラム−アーキテクチュアにて標準化のために使用される機 能上のプロトコルユニットはオブジェクト関連の構造要素換言すればクラスと見 なされる。オブジェクト関連の構造要素への機能上のプロトコルユニットの写像 （変換）により下記が確保される、即ち、交換システムにて標準化において規定 された交換システム上のシーケンス（プロセデュア）が維持され、プロトコルユ ニットの変更の場合、今後の（将来的）標準化手段によりたんに、当該のクラス のみをそれの機能に関して変更しさえすればよいことが確保される。

交換技術の１つの加入者から、接続形成、呼び（コール）及び／又はシグナリン グ処理を行わせるべき要求が報知されると直ちに、当該要求に係わる構造要素（ 備え）によりそのっど１つのオブジェクトが実現値化（ｉｎｓ　ｔａｎｔ　ｉａ 　ｔｅｄ）され、換言すれば、１つのコピーが作成され、メモリ内に入れられる 。当該の実現値化（ｉｎｓｔａｎｔｉａｔｅｄ）されたオブジェクトは基となる オブジェクト関連の構造要素のデータ領域のみを含む。上記データ領域は所定の 程度までコネクションデータ（該データは実現値化（ｉｎｓｔａｎｔｉａｔｅｄ ）を行わせるユーザの要求と関連して作成される）の記憶のためのパターンとし て用いられる。上記データ領域は当該の要求の持続時間中のみ維持される。

１つのクラスのデータ領域に対し、ないし、クラスから実現値化（ｉｎｓｔａｎ ｔｉａｔｅｄ）されたオブジェクトに対して唯基となるクラスのみ、即ちそれの プログラムのみがアクセス得るという事項に基づき、データ領域内にエントリさ れたコネクションデータが他の保守によってオーバーライドされ得ないことが確 保される。この観点によっては保守、殊に誤り走査障害追跡（トラブルシューテ ィング）が簡単化される、それというのはユーザの各要求に対してコネクション （接続）データを有する１つのデータ領域が作成され、そして、誤り（障害）の あるコネクションデータの場合当該データは基となる構造要素（クラス）によっ てのみ作成され得るからである。

本発明の有利な発展形態は引用請求項に示されている。

オブジェクト指向プログラミングにより可能な継承（インへりタンス関係）に基 づき特殊な適用例に対してサブクラスが形成され得、その際それに共通のプロセ デュア手順ないしアトリビュート（属性）は更に上位クラスと称されるオブジェ クト関連した構成要素中にセツティングされている。サブクラスは勿論上位クラ スのプログラミングコードを継承する。各サブクラスへの当該分解の利点はプロ グラミングコードの低減及び機能テストの際の比較的わずかな複雑性に存在する 。継承（インへりタンス）メカニズム及び実現値化（ｉｎｓｔａｎｔｉａｔｅｄ ）の使用により所要のプログラミングコードがわずかに保たれる。開発時間は短 縮され、プログラミングされた機能の実施が促進される。

図を用いて本発明を詳述する。

各図は下記を表す。

図１は当該勧告Ｑ、９３１及びＱ７６４にょるＣＣＩＴＴプロトコルアーキテク チュアを示す。

図２はシーケンスに付加的に設けられたクラスにおけるプロトコルアーキテクチ ュアを示す図である。

図３は適用クラスのハイアラーキの概念図である。

図４はサブクラスを有する図２のプロト；ルアーキテクチュアを示す。

実施例をより一層わかり易い理解のため幾つかの基本的な関連性に基づいて説明 する。

交換技術−ソフトウェア（これにはプログラミング制御交換装置にて主要な機能 が割付、付与される）は加入者シグナリング（ＤＳ！Ｍ）及びネットワークシグ ナリング（ＩＳＵＰ）に対するＣＣＩ　ＴＴ勧告標準化要求を充足しなければな らない。

オブジェクト指向プログラミング方式によるプログラミングの場合所謂“クラス ”は最重要な構造要素と解される。“クラス”とは翻訳の際及びプログラムコン フィギユレーションに対する管理可能な要素とも、また、抽象的データ型のイン プリメンテーション（実現実施）とも解される。

従ってオブジェクト指向プログラミングの場合、先ず何が“クラス”と称せられ るかを常に決定しなければならない。開発フェーズの始めにてクラスが２つのグ ループ例えば標準クラスと適用クラスに分けられるべきであることが明らかにな っている。標準クラスの基礎を成す課題とするところは、同じ基本的なデータ構 造が何度も繰り返されるのを排除することである。

よって、標準クラスはプログラマの開発ツールとして（丁度プログラミング言語 のように）見なされるべきである。

アプリケーション（適用）クラスは機能ユニット（これはそれぞれの特別の適用 債域を表す）を表す。

交換システムにおいてはそのようなユニットは例えば加入者、接続（ライン）ユ ニット、例えばスイッチングユニット又は“コネクションコントロール″　“Ｃ 。

ｎｎｅｃｔｉｎ　Ｃｏｎｔｒｏｌ”である。

標準クラスは多数の種々異なるソフトウェア複合体において使用され得る。当該 それらは一般化ないし乳化（ｇｅｎｅｒａ　］　１ｚｄｔ　１ｏｎ）を表し、そ の中から適用クラスを導出し得る。２つの標準クラスの形式（種別）を指定仕様 化し得る。

Ｇｅｎｅｒｉｃ　５ｔａｎｄａｒ　Ｃ１ａｓｓｓＩＴはクラスに対するパターン である。それによっては定数及びデータ型が”Ｇｅｎｅｒｉｃ　Ｐａｒａｍｅｔ ｅｒ”として設定され得る。実の値をそれらのパラメータに割り当てることによ り、ジェネリックインスタンス、要するにクラスも再び形成され得る。′ジェネ リッククラス”の使用により基本的なデータ構造が定式（立）化され、適用事例 の特定の必要性に適合され得る。”Ｇｅｎｅｒｉｃ　５ｔａｎｄａｒｄ　Ｃ１ａ ｓｓｅｓ”の事例は例えば”１−ＩＲｅｌａｔｉｏｎ”、”Ｌｉ５ｔ’　“Ｔａ ｂｌｅ”、”Ｉｎｄｅｘ　Ｔａｂｌｅである。”Ｌｉ５ｔ”のジェネリックなイ ンスタンスの例は１つのラインを介して通過動作するすべてのコネクションに対 するすべての参照基準（リファレンス）のリストである。

適用クラスに対する標準インターフェースを指定（仕様化）するために“バーチ ャルスタンダードクラス″　（Ｖｉｒｔｕａｌ　５ｔａｎｄａｒｄ　Ｃ１ａｓｓ ｅｓ）が使用されるオブジェクト指向プログラミングではクラス間の情報がクラ ス間に規定（定義）されているメソッド（手続き処理）の呼出によってのみ交換 され得る。従ってクラスへのインターフェースの指定（仕様）はメソッドの呼出 者（呼出側）にとって重要なすべてのファクタ（因子）、例えば“メソッド名” 、′パラメータ”、又は“パラメータ型”の定義を含む、、１つの適用クラスに おいてインターフェースの定義では通常メソッドの実行可能なプログラムコード により完結される。このプログラムコードはクラスの呼出側（呼出者）には可視 でない。

“パーチャルスタンダードクラス”においてはメソッドは“パーチャル”である 。即ちメソッドのインターフェースは定義されているが、メソッド自体はインプ リメント（実施）されていない。アプリケーションクラスは継承（インへりタン ス）コンセプトを用いて導出され得る（例えばサブクラスの形成により）。つま り“バーチャルクラス”のインターフェース（スーパークラスと見なされる）は サブクラスにより完全に継承（インへりタンス）される。

“パーチャルスタンダードクラヌ”はメソッドの実行可能なコードを含まないの で、このことはサブクラスにより行われなければならない。

交換ソフトウェアにおける“バーチャルスタンダードクラス”の例は”Ｔｉｍｅ ｒ　Ｅｖｅｎｔ　Ｒｅｃｅｔｖｅｒ″、”Ｅｘｔｅｒｎａｌ　Ｅｖｅｎ　Ｒｅｃ ｅｉｖｅｒ’又は”Ｃｏｎｔｒｏｌ″である。クラス“Ｃｏｎｔｒｏｌ″はメソ ッド“プロセス信号”を提供し、該“プロセス信号”は以て、自動的に“Ｃ。

ｎｔｒｏｌ”のすべてのサブクラスによりＣａ　ｌ　ＩＰｒｏｃｅｓｓｉｎｇ　 Ｃｏｎｔｒｏｌ　ＵｎｉｔＳに供給される。適用クラスの意味については以下詳 述する。

図１にはプロトコルモジュールを備えたプロトコルアーキテクチャが示しである 。ハツチングで示すプロトコルモジュールはＣＣＩＴＴ勧告から導出され、交換 ソフトウェアの構造化にとって重要な役割を果たす機能上のプロトコルユニット を成す。詳しくは上記プロトコルユニットは下記の機能を有する。

−一−″Ｑ、９３１−Ｐｒｏｔｏｃｏｌ−ｈａｎｄｌＩｎｇ″は加入者接続線路 上のプロトコル処理（“Ｐｒｏｔｃｏｌ　Ｃｏｎｔｒｏｌ”に対してＣＣＩ　Ｔ Ｔ勧告Ｑ、９３０／９３１にて仕様化されているような）に対して責務がある。

ここにおいて”Ｐｒｏｔｏｃ。

１−Ｈａｎｄｌｉｎｇ’は次のような状態のみをとり、即ち、コネクション形成 及び解除に必要とされる状態のみをとり、ファシリティ関連のタスク向けの状態 をとらない。

−−−”Ｃａ　Ｉ　Ｉ／Ｓｅ　ｒｖ　ｉ　ｃｅ−Ｃｏｎ　ｔ　ｒｏ　ｌ’、以下 Ｃ３Ｃと略称する、は呼び処理扱い（機能）を有する。このために、Ｃ３ｃは加 入者データに対してアクセスし、有資格性をチェックする。ＣＳＣはコネクショ ンの形成及び解除を行わせ、そして、料金登録を行わせる。Ｃ３Ｃは加入者側シ グナリングと、ネットワーク側シグナリングとの間のリンク（媒介連結）制御部 である。

−−−”Ｂｅａｒｅｒ　Ｃｏｎｎｅｃｔｉｏｎ　Ｃ。

ｎｔｒｏｌ’、以下ＢＣＣと略称する、は”ｌ５ＵＰ”の″Ｌｉｎｋ−ｂｙ−Ｌ ｉｎｋ’プロセデュア手順（ＣＣＩＴＴ勧告Ｑ７６４のモジュール”ＣａｌｌＰ ｒｏｃｅｓｓｉｎｇ　Ｃｏｎｔｒｏ＋’において規定仕様化されているような） を実行する。上記シグナリングプロセデュア手順はＢＩＳＤＮのステップ１にお いてＡとＢサイ１間のシステム内部のシグナリングのためのみ用いられる。

−−−”Ｃｏｎｎｅｃｔｉｖｉｔｙ　Ｃｏｎｔｒｏｌ″以下ＣＣと称される、は 交換システム内のコネクションの形成及び解除を制御し、即ち、ＣＣはＬＴＧＥ の交換技術−周辺部及びＣＰ＊との通信を実施し、交換技術上のハードウェアへ の調整セツティングを処理実行する。ＣＣはＧＰＨの他の適用クラスに対し、交 換システムのハードウェア構造をコンシールする。

オブジェクト指向ソフトウェア構造への変換の際第１アプローチにおいてのみ上 記プロトコルモジュールの各々に少なくとも１つのクラスが対応付けられる。

そのようにして用意（形成）されたクラスはそれだけではなく未だ実施可能でな く、未だオブジェクト指向システムとして最適化されていない、このことを達成 するため付加的クラスが導入される。

−一一図２には付加的に導入されたクラスが、２重に枠囲いしたブロックとして 示されている。

−ｍ−“Ｃａ１ｌ　Ｐｒｏｃｅｓｓｉｎｇ　ＭＯｎｉｔａｒ″　（これは到来励 振パルスを適正エンティティ（インスタンス）に送信する）。当該分布関数は存 在しなければならない、それというのは外部通信相手例えば端末機器又は制御コ ンピュータは交換技術のソフトウェアのオブジェクト構造を知らないからである 。

交換システムの物理的又は論理的に存在する“資源”（リソース）を表すクラス 一一一クラス内部″Ｒｅ　Ｉａ　ｔ　１ｏｎｓ″これは内部と外部量間又は内部 量相互間のみでの関係を表すクラ特表千７−５０１６７５　（５） ス、例えばロジック参照基準（リファレンス）を物理的参照−基準（リファレン ス）へ、亦、その逆に変換するための種々の参照基準管理プログラム（リファレ ンスマネジャ） 交換ソフトウェアにおけるクラスの継承（インへりタンス）ハイアラーキは図３ に示しである。クラスハイアラーキの形成の際アプリケーションクラスにて共通 の因子（ファクタ）が探索され、上記の共通の因子はスーパークラスにまとめら れている。その際すべての交換技術上のコントロールユニット殊にクラスＬＡＣ ，Ｃ３Ｃ，ＣＣ，ＢＣは標準インターフェースを介して到達し得なければならな い。従ってパーチャル標準クラス“Ｃｏｎｔｒｏｌ”はすべてのコントロールユ ニットに対するスーパークラスとしてインプリメント（実現）された。継承コン セプトによってはサブクラス＝Ｃｏｎｔｒｏｌ″のすべての実現値化（Ｉｎｓｔ ａｎｔｉａｔｅｄ）されたオブジェクトが、それ自体”Ｃｏｎｔｒｏｌ′のオブ ジェクトであるかのようにアドレッシングされ得る。上記の関係は多形性ないし ポリモアヒズム（Ｐｏｌｙｍｏｒｐｈｌｉｓｍ）と称せられる。クラスＬＡＣ， Ｃ３Ｃ，ＣＣには複数のバリエーション、即ちサブクラスがセットアツプされて いる。ＬＡＣ，Ｃ５ＣはそれぞれＢａ５ｉｃ　ＡＣＣｅＳＳ″及び’Ｐｒｉｍａ ｒｙ　Ｒａｔｅ　Ａｃｃ　ｅ　ｓ　ｓ”バリエーションを有する。ＣＣは“Ｄｉ ａｌ−ｕｐ　Ｃｏｎｎｅｃｔｉｏｎ″及びＰ　ｅ　ｒ　ｍ　ａｎｅｎｔ　Ｃｏｎ ｎｅｃｔｉｏｎ”を有する。１つのクラスの各バリエーションは１つの共通のプ ログラムロード及びデータを有するので、当該の共通のプログラムコード及びデ ータは当該バリエーションから除去され、１つの新たに作成されたスーパークラ ス内に転送される。最初に作成されたクラスはそれぞれのバリエーションに特有 のシーケンス及びデータのみを含む。

プロトコルアーキテクチャから導出されるプロトコルモジュールの一部は更に分 解され得、換言すれば複数のクラスに写像（マツピング）され得る。

図４にはプロトコルモジュール”Ｌｉｎｅ　Ａｃｃｅｓｓ　Ｃｏｎｔｒｏｌ’及 び”Ｃｏｎｎｅ　ｃ　ｔ　ｉ　ｖｉｔ）’　Ｃｏｎｔｒｏｌ″が更に分解される か即ち複数のクラスに写像（マツピング）されるかを示す。そのときプロトコル モジュール“Ｌｉｎｅ　ＡｃｃｅｓｓＣｏ　ｎ　ｔ　ｒ　ｏ　ｌ″は下記のクラ スにより表される。

−−一″Ｔｒａｎｓｐｏｒｔ　Ｃｏｎｔｒｏｌ”　（これはレイヤ２−コネクシ ョンの利用をレイヤ３により管理する） −−−１ｌＬｉｎｅ　Ｅｖｅｎｔ　Ｐｒｏｃｅｓｏｒ”（これはレイヤーコネク ションの呼びのすべての又は所定数に係わる写像の加工処理を引き受ける）−− −”Ｔｅｒｍｉｎａｌ　Ｃｌｅａｒｉｎｇ　Ｃｏｎｔｒｏｌ″　（これは呼び割 り当ての際考慮されていない端末機器をＢサイドで読出すためのプロトコルを処 理実行する） −−−”Ｌｉｎｅ　Ａｃｃｅｓｓ　Ｃｏｎｔｒｏｌ’（これはＱ、９３４プロト コルのその他の機能を加工処理する） プロトコルモジュール’ＣｏｎｎｅｃｔｉｖｉｔｙＣａｎ　ｔ　ｒ　ｏ　］”は 次の２つにクラスにより表されている。

一一一“Ｐｅｒｉｐｈｅｒａｌ　Ｃｏｎｔｒｏｌ”（これはシステムの交換技術 周辺部との通信を行う）−ｍ−″ＣＰ　Ｃｏｎｔｒｏｌ”　（これはバーチャル プロセッサＣＰ＊にて交換技術との通信を行う）図３に関連して既述のように、 継承（インへりタンス）関係に対する手法、可能性がめられ、利用される、換言 すれば、特別な適用例に対するサブクラスが形成され、それの共通のシーケンス （プロセデュア手順）ないしアトリビュートが１つのスーパークラスに入れられ る。

プロトコルモジュール”Ｃａ１ｌ／５ｅｒｖｉｃｅＣｏｎｔｒｏｌ”は例えば２ つのクラスによって表され、そのうちの第１のものはＡＴＭ加入者の呼処理のた めのサブクラスと、ＡＴＭ−ＰＢＸの呼処理のためのサブクラスを有する。ＡＴ Ｍ加入者及びＡＴＭ−ＰＢＸの呼処理加工の際の共通のフィーチャは第１クラス 内に含まれている。

プロトコルモジュール”Ｃａ１ｌ／５ｅｒｖｉｃｅＣｏｎｔｒｏｌ″の表現のた め設けられて第２クラスのうち丁度１つのスタチックなオブジェクトが存在しこ のオブジェクトはＢサイドにて呼びの形成に共働する。上記のスタチックなオブ ジェクトは現存のＢ　−加入者番号を有する１つの加入者が決定し得るために（ 呼び）加入者番号の評価を行う。そのような加入者が存在する場合、上記のスタ チックオブジェクトは適当なサブクラスを実現値化（ｉｎｓ　ｔａｎｔ　ｉａ　 ｔｅｄ）する、換言すればＡＴＶ加入者の呼処理のためか又はＡＴＭ−ＰＢＸの 呼処理のための適当なサブクラスを実現値化（ｉｎｓｔａｎｔｉａｔｅｄ）する 。そのような加入者が存在しない場合はスタチックなオブジェクトによりコネク ションが終了される。それにより、一方では両サブクラス間の分離が維持され、 他方ｌ”が加入者線の種別についての情報で負荷されないことが確保される。更 にスタチックなオブジェクトが次のような場合を処理すべき手法が用意される、 即ち、Ｂサイドの存在している不完全なコール（加入者）番号を用いてはＢサイ ドでは所定の場合を識別、決定できない場合であって、当該のコール（加入者） 番号を有する加入者端子（ライン）が存在するか否かを識別できないという所定 の場合を処理すべき手法が用意される。

ＩＧＩ 国際調査報告 １Ｍ１１＋ｍ＋、６ｍ。Ａ、、、、、ＰＣＴ／ＤＥ　９３１００２３３１・ｃ陛 −１１１キ＃ｅｔｌｌ１１１ｒ２＋０１２ｕ引ｉチーｏ噛−−１１１ｍＷＩ・ａ ｌｌＡｒ’Ｊｌ−４Ａｒ’Ｊ３　ＡｈＪ　ＮＥ：Ｘ　Ｉｋｒ　ＮＮＥ：ＸＩＥフ ロントページの続き （５１）　Ｉｎｔ、　Ｃ１，’　識別記号　庁内整理番号ＨＯ４Ｍ　３１００　 Ｂ　８４２６−５に１１１００　７４０６−５Ｋ Ｈ０４Ｑ　３１００　９０７６−５に ３１５８　１０１　８８４３−５に Ｉ

Claims (2)

【特許請求の範囲】
1. １．スイッチングによるないしコネクションないし呼び処理のためオブジェクト 指向プログラミング方式により構築されたシステムプログラムモジュールを有す るＩＳＤＮ交換システムであって、交換動作機能上の手順、シーケンス標準化の ためプロトコルアーキテクチュアにて使用されるプロトコルモジュールがオブジ ェクト指向構造要素として表されており、該構造要素のうちから、コネクション 及び／又は呼びのため及び／又はシグナリング動作過程のためオブジェクトが実 現値化（ｉｎｓｔａｎｔｉａｔｅｄ）され、当該の構造要素に属するデータ領域 から、データメモリ内にパターンの型としてコピーがセットアップされ、上記パ ターン内にはコネクション−ないし呼び−ないしシグナリング個別のデータがエ ントリされ、そして当該データ領域は当該のコネクションないし呼びないしシグ ナリングの持続時間中のみ維持されるようにしたことを特徴とするスイッチング によるコネクションの処理のためのオブジェクト指向プログラミング方式により 構築されたプログラムモジュールを備えたプログラム制御ＩＳＤＮ交換システム 。
2. ２．プロトコルモジュールはそれぞれ複数の構造要素により表され、該構造要素 上にて共通のプログラムシーケンス及びデータが１つのハイアラーキ的に上位の 構造要素にてまとめられるようにした請求の範囲１記載の交換システム。