JPH0247989A - 分散型交換制御システム - Google Patents

Abstract

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

Description

【発明の詳細な説明】 〔産業上の利用分野〕 本発明は分散型交換制御システムに係り、詳しくは、分
散された制御装置上で実行される交換システム制御用の
ソフトウェア構成及びその処理方式に関する。

〔従来の技術〕 従来１分散した制御装置上で実行されるソフトウェアの
構成は、その制御装置の分散構成法及び機能分担に合わ
せて決定されている。また、処理方式も、制御装置の分
散構成法１機能と制御装置の対応、更には制御装置間の
通信を陽に意識した形で設計、製造されている。

具体的には、ソフトウェア構成に関しては、第２図に示
すように、同一制御装置内のプログラムは、サブルーチ
ンコール、共通メモリを介した処理で強く結合されてお
り、違う装置上のプログラムとは直接通信手段を介して
インターフェイスをとっている。

処理方式に関しては、処理の各段階で次の処理が行われ
る制御装置のプログラムコード上もしくはテーブル上の
データとして認識し、制御装置の違いに依存した方法で
制御を次の処理にわたしている。

〔発明が解決しようとする課題〕

上記従来の分散型交換制御システムにおけるソフトウェ
アの構成、処理方式では、次のような問題がある。

（１）制御装置の分散構成、機能分担に依存して、各方
式ごとにソフトウェア構成、処理方式を設計しなくては
ならない。

（２）ある分散構成で機能分担の変更が生じたとき。

プログラムのの変更量が大きい、しかも、直接、変更に
関係しない装置に関しても、プログラムを再コンパイル
する必要があったり、保守者によるデータの変更を伴っ
たりする。

（３）ある分散構成方式として範囲を限って、複数の制
御装置の分散構成パターンに対応できるようなソフトウ
ェア構成、処理方式が存在するが、そのためのメモリや
処理量のオーバヘッドが生じている。

本発明の目的は、分散型交換制御システムにおいて、制
御装置の分散構成に依存せず１機能分担の変更時のプロ
グラム変更（それによる他プログラムへの影響）が少な
く、更にメモリ量、処理量のオーバヘッドが少ないソフ
トウェア構成及びその処理方式を提供することにある。

〔課題を解決するための手段〕

上記目的を達成するため、本発明では、■分散制御装置
上の交換制御ソフトウェアを、メツセージを統一インタ
ーフェイスとするプロセス単位で構成し、各装置の共通
機能としてメツセージ送信相手の装置内／外を判定し、
それに応じて装置内のメツセージ転送、装置間の通信手
段を用いたメツセージ転送機能を具備する、■メツセー
ジの送信相手指定法としてプロセスにダイナミックに与
えられる名前を用い、プロセス生成時に伝えあう、■呼
の生成に伴って生成されるプロセスの名前は関係プロセ
スに直接伝える、呼の生成と関係なく存在するプロセス
の名前はテーブル上に管理する、■テーブルへの名前の
問合せは、呼処理に伴うメツセージと兼ねる、もしくは
メツセージ転送と兼ねることを主要な特徴とする。

〔作　用〕

上記■の特徴により、プロセスが存在する制御装置に関
係なくプロセス間のインターフェイスは同じなので、分
散単位をプロセス単位とした場合、制御装置の分散構成
法、機能分担法によらないソフトウェア構成、処理方式
となる。また、機能分担の変更に際して、プロセス単位
にプログラムを制御装置間で入れ替えすることで対処で
きる。また、■の特徴により、直接プロセスの入れ替え
に関わりのない制御装置に関しては、入れ替えのあった
プロセスの新たな名前を受取るだけで、再コンパイルや
保守者からのデータの変更の操作は伴わない。また、■
の特徴により、数は多いが参照するプロセスが少ないプ
ロセスの名前はテーブル形式にせず、数は多くないが参
照するプロセスの数の多いプロセスの名前をテーブル形
式にすることによって呼の超多重性による（名前管理の
ための）メモリ使用量の増大を抑えている。更に、■の
特徴により、名前の問合せによるメツセージの回数を抑
えて処理量の増大を抑えている。

〔実施例〕

以下１本発明の一実施例について図面により説明する。

第１図は本発明の一実施例の概略構成図を示したもので
ある。１０は分散された複数の制御装置であり、それぞ
れ通信手段２０を介して結合されている。各制御装置の
ソフトウェアはＡＰＬ部分１１、プロセス管理部分１２
、プロセス制御部分１３及び通信制御部分１４に分けら
れる。ＡＰＬ部分１２のソフトウェアはプロセスと呼ば
れる独立な実行単位の集合で構成されている。プロセス
管理部分１２はプロセス間のメツセージ通信の相手が制
御装置内か制御装置外かを判定する機能を具備する。プ
ロセス制御部分１３はプロセス生成時にメモリを確保し
たり、同一制御装置内のプロセス間のメツセージ転送を
行う。通信制御部分１４は他制溝装置へのメツセージ転
送機能を有する。

第３図にメツセージの論理構成を示す。即ち、メツセー
ジは転送相手プロセス名とメツセージ内容からなる。第
４図は転送相手プロセス名の構成例で、相手名は論理名
か物理名かのどちらかで指定し、両者の識別は先頭のビ
ットで行われる。物理名はプロセスが存在する制御装置
番号を示す装置ＩＤと制御装置内でのプロセスを識別す
るプロセスＩＤ（例えば、各プロセスのメイルアドレス
に対応した番号）から成っている。論理名はシステム全
体でユニークに付与する論理番号で二＼では通し番号を
付与する。

次に、メツセージ転送時の制御装置の各ソフトウェア部
分について説明する。

ＡＰＬ部分１１の各プロセスは、メツセージ転送時にシ
ステムコールもしくはサブルーチンコールの形でプロセ
ス管理部分１２を呼出す。プロセス管理部分１２の処理
フローを第５図に示す。

プロセス管理部分１２は各プロセスよりメツセージ転送
要求を受取ると、転送相手プロセス名が論理名か物理名
か判定しくステップ１０１）、送出相手名が物理名の場
合、装置ＩＤで相手プロセスが自制御装置内かを判定す
る（ステップ１０２）。

自装置の場合、プロセス制御部分１３にプロセスＩＤと
メツセージ内容を渡してメツセージ転送命令を指示する
（ステップ１０３）。プロセス制御部分１３は周知の手
法でメツセージを相手プロセスへ転送する。装置ＩＤが
自制御装置でない場合、信号フォーマットを作成し、物
理名とメツセージ内容を通信制御部分へ渡す（ステップ
１０４，１０５）０通信制御部分では周知の手法でメツ
セージを該制御装置へ転送する。一方、相手名が論理名
の場合、プロセス管理部分１２内の論理−物理名変換テ
ーブルで物理名に変換した後（ステップ１０６）、装置
Ｉ　Ｄ’が自制御装置か他制溝装置か判定しくステップ
１０７）、以下、物理名のときと同様の処理を行う。

第６図に論理−物理名変換テーブルの構成例を示す０通
常のメツセージ転送時における論理名から物理名への変
換は、論理名に相当するアドレスの物理名を与える。ま
た、後述するように初期設定時におけるメツセージ転送
の場合は、その以降につながっている各装置の物理名も
参照する。

次に、他制溝装置から送られたメツセージの処理を説明
する。他制溝装置からのメツセージを周知の手法で受信
すると１通信制御部分１４は、プロセス管理部分１２ヘ
メツセージを渡す、プロセス管理部分１２ではプロセス
ＩＤを判別しくステツブ１１１）、該プロセスＩＤとメ
ツセージ内容をプロセス制御部分１３に渡す（ステップ
１１２）。

プロセス制御部分は周知の手法でメツセージを相手プロ
セスへ転送する。

次にＡＰＬ部分１１のプログラム構成について説明する
。こ＼で、ＡＰＬ上のプロセスを、スタティックデータ
やリソースを管理するプロセス（これをシステムプロセ
スと呼ぶ）と呼処理に使う入呼トランク族［（ＯＧＴ）
、出呼トランク族［（ＩＣＴ）等の各リソースに対応す
るプロセスや呼単位の処理を行うプロセス（これをコー
ルプロセスと呼ぶ）に分ける。こ＼では、システムプロ
セスとコールプロセスの例を「ビルディングブロック型
のＴＳＪを例にとって説明する。

第７図はビルディング型ＴＳの構成概要を示したもので
ある。第７図において、各モジュール２０１は独立した
１個の交換機能を有し、複数のモジュール２０１がモジ
ュール間結合手段２０２により結合される。結合される
モジュールの数によって交換容量を増減させることがで
きる。制御装置は各モジュール２０１に付与されており
、各モジュールの制御装置間の通信手段２０３が用意さ
れている。

第８図にＡＰＬ内のプロセスの一例を示す。二＼で、共
通線信号装置（Ｃ８Ｅ）の制御を行うプロセス（Ｃ５と
略す）、ルート翻訳を行うプロセス（ＲＯＯＴａｎと略
す）、ＩＣＴ、ＯＧＴを管理するプロセス（各々Ｉ　Ｃ
Ｔｐｏｏｌ、　ＯＧ　Ｔｐｏｏｌと略す）はシステムプ
ロセスであり、システム初期設定時に生成される。また
、ＩＣＴ、ＯＧＴの動作を制御するプロセス（各々ＩＣ
０Ｔ、ＯＣＴと略す）はコールプロセスであり、呼の生
成に伴って生成される。どちらのプロセスも同種のプロ
セスが複数個存在する。コールプロセスはコール対応に
同種のプロセスが存在し、システムプロセスは各制御装
置に多重置きされる場合がある。同種複数呼のプロセス
の中の１個を特定するのは、先に示した物理名によって
おこなわれる。論理名はその種類のみを示している。第
９図にプロセスの名前保持法の３つのパターンを示す。

コールプロセスの名前は、このプロトコルを参照するプ
ロセスに直接知られ、そのプロセスのプロセスデータと
して保持される。例えば、ある呼の制御に使われるＯＣ
Ｔの名前は、これを管理する０ＧＴｐｏｏｌとこのＯＧ
Ｔと接続されるＩＣＴに伝えられ、そこでプロセスデー
タとして保持される（第９図（ａ）参照）。

一方、システムプロセスの名前はＡＰＬ内の特定プロセ
スもしくはプロセス管理部分で保持される。例えば、Ｏ
Ｇ　Ｔ　ｐｏｏｌの名前はＲＯＯＴａｎで保持され、Ｉ
ＣＴからルート翻訳依頼のメツセージ内容である回線番
号の値に応じてＯＧＴのトランクグループの番号（ＴＧ
Ｎ）とＯＧ　Ｔ　ｐｏｏｌの名前を決定し、ＩＣＴに渡
す。ＩＣＴは０ＧＴｐｏｏｌの名前を保持することなく
、この名前のプロセスへＯＧＴのハント依頼のメツセー
ジを送る（第９図（ｂ）参照）。

また、ＩＣＴがＲＯＯＴ　ａｎにメツセージを送出する
場合は、この物理名をＩＣＴのプロセスデータとして保
持しておらず、コンパイル時にソースコードとして与え
られる論理名でプロセス管理部分を経由して送出される
。プロセス管理部分では先に説明したように論理−物理
基変換を行って、その後物理基でメツセージ送出された
のと同じ処理を行う（第９図（ｃ）参照）。

次に、初期設定時のシステムプロセスの生成とその名前
の更新法について述べる。第１０図は初期設定のための
データ構成である。論理−物理基変換テーブル３０３は
第６図で説明したものである。ＰＡバッファ３０１はプ
ロセス管理部分用のシステムプロセス名を保持するバッ
ファであり、Ａ　Ｐ　／＜ソファ３０２はＡＰＬの特定
プロセスが保持するシステムプロセス名を保持するバッ
ファである。初期設定は、システム全体の初期設定と制
御装置単位の初期設定に分けられる。以下では後者につ
いて説明する。

第１１図は初期設定対象の制御装置の動作フローを示し
ている。初期設定対象の制御装置の動作は４つの段階に
分けられる。段階１ではプロセス管理部分１２、プロセ
ス実行制御部分１３、通信制御部分１４の初期設定を行
う。このときプロセス管理部分１２の各データをクリア
する。段階２では初期設定していることを通信手段を通
して他の制御装置に通知する。

段階３では各制御装置のプロセス管理部分１２の論理−
物理名変換テーブル３０３に名前を登録するシステムプ
ロセスを生成する。この名前を論理−物理名変換テーブ
ル３０３の論理番号に相当するアドレスに書込む、更に
この名前を論理名と共に他の全ての制御装置へ通知する
とへもにＰＡバッファ３０１に格納する。これと同時に
他の制御装置からシステムプロセスの論理名と物理名を
受信し、これを論理−物理名変換テーブル３０３の論理
名に相当するアドレスに何も書込まれていなければそこ
に書込み、書込まれていれば、そこからつながっている
リンクの最後尾に書込みつなぐ。

段階４では各制御装置のＡＰＬの特定プロセスで名前を
管理するシステムプロセスを生成する。

生成したプロセスの物理名を保持するＡＰＬのプロセス
に（先に示した例のＲＯＯＴ　ａｎ内で０ＧＴｐｏｏｌ
の名前を選択するような）生成したプロセスを選択する
ために必要なデータ（選択条件）と＼もに通知する。こ
のプロセスはこの情報を保持する。また、論理−物理名
変換テーブル３０３における生成したプロセスの論理番
号に相当するアドレスにつながっている全ての物理番号
（但し、自装置ｉＩＤの物理番号は除く）のプロセスに
対して。

生成したプロセスの物理名と選択条件を送出する。

それとへもに送出した情報をＡＰバッファ３０２内に格
納し、これと論理−物理名変換テーブル３０３における
このプロセスの論理番号に相当するアドレスをリンクさ
せる。これと同時に他制溝装置から初期設定巾制御装置
のＡＰＬの特定のシステムプロセスに対して、そのプロ
セスで保持すべきシステムプロセスの物理名とその選択
条件が送信され、受信したプロセスはこの物理名と選択
条件をプロセスデータとして保持する。

第１２図は初期設定対象外の制御装置の動作フローを示
している。

初期設定している制御装置から初期設定しているという
通知を受けたなら、自制溝装置のプロセス管理部分の論
理−物理名変換テーブル３０３のうち、初期設定中の制
御装置の装置ＩＤを持つ物理名をクリアする（ステップ
４０１）。更にＡＰＬのシステムプロセスの物理名を保
持するプロセスに初期設定中の制御装置番号を知らせる
（ステップ４０２）、これを受信したプロセスはこの情
報に基づき初期設定中の装置ＩＤを持つプロセス名をク
リアする。

次に初期設定中の制御装置へＰＡバッファ３０１にある
情報を送出する（ステップ４０３）。これと同時に、初
期設定中の制御装置から物理名と論理名を受信し、この
物理名を論理−物理名変換テーブル３０３の論理番号に
相当するアドレスに何も書込まれていなければそこに書
込み、書込まれていれば、そこからつなかっているリン
クの最後尾に書込みつなぐ（ステップ４０４）。

次に、ＡＰバッファ３０２に格納されている情報を、こ
れからリンクされている論理−物理名変換テーブル３０
３のアドレスからリンクされている物理名の内、初期設
定中の装置ＩＤを持つ物理名のプロセスへ送出する（ス
テップ４０５）、また、自制御装置ＡＰＬ内のシステム
プロセスの物理名を格納する特定プロセスは、初期設定
中の制御装置から保持すべき物理名と選択条件を受信す
る（ステップ４０６’）。

全装置初期設定の場合は、上記の各段階を、全制御装置
間で同期をとりながら、合わせて行うことによってなさ
れる。

第１３図はＬＳの呼処理のモデルプログラムを例に、同
時接続コール数とそのとき名前管理のために必要なメモ
リ量を示したものである。■は全で関係するプロセスの
プロセスデータとして保持する場合、■は全て各制御装
置で局所化して保持する場合、■は本発明方式で、プロ
セスの種類をコールシステムとシステムプログラムに分
けて、コールプロセスは■の方法、システムプロセスは
■の方法と使い分けた場合である（但し、制御装置の数
を１０とした）。この比較から本発明方式がメモリ量の
点から効果があることが分かる。

第１４図はシステムプロセスの名前問合せを縮退形で行
った効果例（制御装置外メツセージ通信の割合−１コー
ルスルーで経由するキュウの数）を示したものである。

処理遅延は、処理に経由するキュウの数に依るので、第
１４図はこの効果をキュウの数の削減効果として表した
ものである。

■は先のモデルプログラムの出接続のコールスルーに経
由するキュウの数をいちいち名前を問合わせる場合、■
は本発明方式（呼処理もしくはメツセージ転送を兼ねる
場合）の場合であり５本発明力式が処理遅延の削減効果
があることがわかる。

〔発明の効果〕

以上の説明から明らかな如く、本発明の分散型交換制御
システムによれば、以下のような効果が得られる。

（１）ＡＰＬ上の各プロセスは、実行中受信した物理名
もしくは制御装置に依存しない論理名で相手プロセスを
指定してメツセージ転送するので。

各プロセスの設計、作成は制御装置の構成、機能分担に
よらず、設計書及びプログラムの管理対象ファイルは分
散方式に依らず一本化できるという利点がある。

（２）機能分担の変更がプロセスに相当する単位で行わ
れる場合は、変更機能に相当するプロセスのソースコー
ドを移動し、初期設定ルーチンで生成するプロセス名の
書換えを行い、関係制御装置のファイルを再コンパイル
するだけで他のプロセスに関して修正することなく完了
するという利点がある。

（３）制御装置ごとの初期設定時に新たに生成されたプ
ロセスの名前を各制御装置に伝えることから、上記機能
分担変更時にこの変更と関係のない制御装置に関しては
、再コンパイルはおろか初期設定の必要もなく正常動作
させておけるという利点がある。

（４）プロセスをシステムプロセスとコールプロセスに
分けて、システムプロセスはその名前を管理する部分を
局所化し、コールプロセスは関係プロセスがプロセスデ
ータとして名前を保持することから、名前保持のための
データ量が少なくなるという利点がある。

（５）システムプロセスの名前を管理している部分に問
合せる場合、呼処理の中に埋込むか、もしくはメツセー
ジ転送と兼ねることによって処理遅延を減らす利点があ
る。

【図面の簡単な説明】

第１図は本発明による分散型交換制御システムの一実施
例の概略構成図、第２図は従来の構成例を示す図、第３
図はメツセージの構成例を示す図、第４図はプロセス名
の構成例を示す図、第５図は第１図のプロセス管理部分
の動作フローを示す図、第６図はプロセス管理部分の論
理−物理名変換テーブルの構成例を示す図、第７図はビ
ルディングブロック型ＴＳの構成概要を示す図、第８図
はビルディングブロック型ＴＳのＡＰＬ部分のプロセス
の一例を示す図、第９図はプロセスの名前保持法の３つ
のパターンを示す図、第１０図は初期設定時に使用する
データの構成例を示す図、第１１図は装置ごとの初期設
定における初期設定制御装置の動作概要フローを示す図
、第１２図は装置ごとの初期設定における非初期設定制
御装置の動作概要フローを示す図、第１３図は名前保持
をコールプロセスとシステムプロセスで変えて行ったこ
とによる効果を示す図、第１４図はシステムプロセスの
名前問合せを縮退形で行った効果例を示す図である。 １０・・・制御装置、　１１・・・ＡＰＬ部分１２・・
・プロセス管理部分、 １３・・・プロセス制御部分、 １４・・・通信制御部分、 ２０・・・通信手段。 第３図 第４ 図 沖２、ふｔ〕這子フ′Ｏせス、冶 ０　　　げ−−−−−”’−−−−　−一−１へ−３ 第１０図 第１２図

Claims (4)

【特許請求の範囲】
1. （１）複数の制御装置が通信手段を介して結合されてな
   る分散型交換制御システムにおいて、 各制御装置は交換制御用ソフトウェアとして、プロセス
   と呼ばれる独立な実行単位の集合で構成され、各プロセ
   スは通信手段で結合された複数の制御装置で実行され、
   プロセス間の同期とり及びパラメータの引継ぎをメッセ
   ージと呼ばれる統一されたインターフェイスで行うプロ
   グラム群（以下ＡＰＬと呼ぶ）と、上記プロセスの実行
   を管理する機能、メッセージ転送の相手プロセスが同一
   制御装置内か他制御装置に存在するかを切分ける機能、
   同一制御装置内のプロセスにメッセージを転送する機能
   、他制御装置へ通信手段を介してメッセージを転送する
   機能からなるオペレーションシステム（以下、ＯＳと呼
   ぶ）とを具備していることを特徴とする分散型交換制御
   システム。
2. （２）メッセージ転送時の送出相手プロセス指定は、プ
   ロセス生成時に付与されシステム全体でユニークかつプ
   ロセスの存在する制御装置を判別できるプロセスの名前
   を用い、各制御装置ごとの初期設定時及び呼生成時に、
   そのとき生成された上記プロセスの名前を関係するプロ
   セスに知らせることを特徴とする請求項（１）記載の分
   散型交換制御システム。
3. （３）プロセスを呼の生成に伴って生成されるコールプ
   ロセスと呼の生成に関係なく存在するシステムプロセス
   に大別し、コールプロセスに関しては、このプロセス（
   プロセスＡ）にメッセージを送るプロセス（プロセスＢ
   ）に対してプロセスＢの生成時にパラメータとして、も
   しくはメッセージによってプロセスＡの名前を知らせ、
   システムプロセスに関しては、このプロセス（プロセス
   Ｃ）にメッセージを送るプロセス（プロセスＤ）は、あ
   る特定のプロセス内もしくはＯＳにシステムプロセスの
   名前テーブルを備え、該名前テーブルに問合わせること
   によってプロセスＣの名前を知ることを特徴とする請求
   項（１）記載の分散型交換制御システム。
4. （４）システムプロセス（プロセスＥ）の名前を問合せ
   る場合、プロセスＥがリソースの収容場所の関係からど
   の制御装置のシステムプロセスかを判定するプロセス（
   プロセスＦ）がある場合にはプロセスＦ内にプロセスＥ
   の名前管理テーブルを設けて、名前の問合せと判定処理
   を兼ね、プロセスＥの名前管理テーブルがＯＳ内にある
   場合には名前の問合せとメッセージの転送を兼ねること
   を特徴とする請求項（３）記載の分散型交換制御システ
   ム。