JP2532148B2

JP2532148B2 - インテリジェント・ネットワ―クにおけるデ―タベ―ス管理方式

Info

Publication number: JP2532148B2
Application number: JP2008415A
Authority: JP
Inventors: 秀夫柚木; 好宏窪田
Original assignee: Fujitsu Ltd
Current assignee: Fujitsu Ltd
Priority date: 1990-01-19
Filing date: 1990-01-19
Publication date: 1996-09-11
Anticipated expiration: 2011-09-11
Also published as: JPH03214851A; US5574904A

Description

【発明の詳細な説明】〔概要〕インテリジェント・ネットワークにおけるデータベー
ス管理方式に関し、通信網において、データベースの構造を意識せずにサ
ービス・アプリケーション・プログラムを開発できるよ
うにすることを目的とし、複数のサービス実行手段を有するインテリジェント・
ネットワークにおいて、発加入者からのサービス要求メ
ッセージに基づいてデータベース処理依頼要求を出力す
る翻訳モジュールと、該翻訳モジュールからのデータベ
ース処理依頼要求に基づいて、データベースのアクセス
と前記複数のサービス実行手段に対するサービス処理依
頼要求を行うと共に、該サービス実行手段からのデータ
ベース処理依頼要求に基づいてデータベースへのアクセ
スを行うデータベース処理モジュールと、前記サービス
実行手段からの出力処理依頼要求に基づいて通信網への
メッセージの出力を行う出力処理モジュールとを有し、
前記各モジュール間及び各モジュールとサービス実行手
段間のそれぞれの処理依頼要求を、共通化したデータフ
ォーマットに基づいて行うように構成する。

〔産業上の利用分野〕

本発明は、インテリジェント・ネットワークにおける
データベース管理方式に関する。

〔従来の技術〕

電話網などにおいては、着信課金、３社通話、電話会
議などの種々のサービスがユーザに提供されている。

一般に、これらのサービスを実現するサービス・アプ
リケーション・プログラムは、それらのサービスに使用
するデータベースと共に交換局内に設置されている。

最近、これらのサービス・アプリケーション・プログ
ラムを、交換処理と分離し網内の一点で集中管理するこ
とが考えられており、これを実現する通信網をインテリ
ジェント・ネットワークと呼んでいる。これは、従来、
交換局の交換機の機種に依存して作成さているサービス
・アプリケーション・プログラムを、交換機の機種に依
存せず交換網の運用者等が自由に作成できる機能を実現
することを目的としている。

第20図は、インテリジェント・ネットワークの構成の
一例を示す図である。

SSP（Service Switching Point）11は、端末間の接続
制御等を行う交換機であり、各SSP11は信号網を介してS
CP（Service Control Point）12に接続されている。こ
のSCP12内にサービス処理を行うアプリケーション・プ
ログラムとデータベースとを集中させて、加入者からの
サービス要求を処理することをめざしている。

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

しかしながら、現状ではデータベースの集中化が図ら
れた程度で、交換網の運用者が新規のサービス・アプリ
ケーション・プログラムを自由に作用できるようにはな
っていない。その理由は、サービス・アプリケーショウ
・プログラムとデータベース管理機能が密に結合されて
いる為に、アプリケーション・プログラムの開発には、
データベースの構造等を充分に熟知する必要があり、特
殊なノウハウと膨大な開発工数が必要になるからであ
る。

また、電話網等のユーザに提供している複数のサービ
スは、全てが同時に起動できるわけではなく、それのサ
ービスの中には、何れかを優先させて起動するるサービ
ス、あるいは同時に起動できないサービス等がある。

そこで、同じ発加入者から複数のサービス要求があっ
た場合には、各サービス間の相互規制の有無をチェック
する必要がある。

このチェックは、それぞれのアプリケーション・プロ
グラムの中で行われており、新規のアプリケーション・
プログラムを作成すると、既存のアプリケーション・プ
ログラムを変更する必要が生じる。これがプログラムの
開発効率を低下させる原因となっている。

本発明は、通信網において、データベースの構造を意
識せずにサービス・アプリケーション・プログラムを開
発できるようにすることを目的とする。

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

第１図は、本発明の原理説明図である。

複数のサービス実行手段５を有するインテリジェント
・ネットワークにおいて、翻訳モジュール１は、発加入者からのサービス要求メ
ッセージ２を解析し、そのサービス要求メッセージ２に
基づいてデータベース処理依頼要求３を作成する。

データベース処理モジュール４は、翻訳モジュール１
からのデータベース処理依頼要求３に基づいて、データ
ベース18のアクセスと複数のサービス実行手段５に対す
るサービス処理依頼要求６を行う。また、データベース
処理モジュール４は、サービス実行手段５からのデータ
ベース処理依頼要求３に基づいてデータベース18へのア
クセスを行う。

出力処理モジュール７は、サービス実行手段５からの
出力処理依頼要求８に基づいて通信網へのメッセージの
出力を行う。

上記各モジュール間及び各モジュールとサービス実行
手段４間のそれぞれの処理依頼要求３、６、８は、共通
化したデータフォーマットに基づいて行っている。

〔作用〕

翻訳モジュール１は、例えば受信したサービス要求メ
ッセージ２の各パラメータに、そのサービスに対応した
処理タグを付与してデータベース処理依頼要求３を作成
する。

データベース処理モジュール４は、上記のデータベー
ス処理依頼要求３に基づいてデータベース18をアクセス
して所望の情報を入手する。そして、その得られた情報
と、サービス要求メッセージ２の各パラメータとからサ
ービス処理依頼要求６を作成する。

このサービス処理依頼要求６により指定されたサービ
ス実行手段５は、個々のサービス処理を実行し、実行結
果が通信網に出力すべきものであれば、出力処理依頼要
求８を作成して出力処理モジュール７に出力する。

また、サービス実行の結果、データベース18をアクセ
スする必要が生じた場合には、必要な処理内容に対応し
たデータベース処理依頼要求３を作成しデータベース処
理モジュール４に出力する。

このように、通信網とサービス実行手段５間、又はデ
ータベース18とサービス実行手段５間等に、翻訳モジュ
ール１、データベース処理モジュール４、及び出力処理
モジュール７を介在させ、それら各モジュールとサービ
ス実行手段５間の処理依頼要求を共通化させたデータフ
ォーマットにより行うことにより、サービス実行手段５
をデータベース18と分離した形で構成することができ
る。

従って、例えばサービス実行手段に対応するサービス
・アプリケーション・プログラムを、データベース18の
構造を意識せずに開発することができ、プログラムの開
発効率をより高めることができる。

〔実施例〕

以下、本発明の実施例を図面を参照しながら説明す
る。

本実施例は、本発明に係るデータベース管理方式を実
行するSCP（Service Control Point）12に関するもので
ある。

尚、インテリジェント・ネットワークの全体構成は特
には図示していないが、例えば第20図に示したような構
成を有しており、SCP12内にデータベースと、各種サー
ビス・アプリケーション・プログラムと、後述するAPIP
22とが設けられている。

第２図は、SCP12の主要部の構成図である。

同図において、翻訳チェック処理モジュール13は、SS
P（Service Switching Point）11を介して与えらえる発
加入者からの受信メッセージ（MSG）を解析するモジュ
ールである。このとき、同一発加入者から複数のサービ
ス要求があった場合には、後述する相互規制マトリック
ステーブル14を参照して、それらのサービスが同時に実
行可能なサービスか、あるいは何れかを一方のみが実行
可能なサービスか等を判断する。

また、翻訳チェック処理モジュール13は、実行すべき
サービスを決定したなら、サービス内容に対応した処理
タグを付与し、共通とデータフォーマットからなるDB
（データベース）処理依頼伝票15（後述する）を作成し
データベース処理モージュル16に送る。

データベース処理モジュール（以下、DB処理モジュー
ルと呼ぶ）16は、翻訳チェック処理モジュール13又はア
プリケーション・プログラム17（後述する）からのDB処
理依頼伝票15の処理タグに従って、対象となるデータベ
ース18をアクセスしてデータの読み出し、書き込み等を
行う。また、DB処理モジュール16は、処理タグに従って
処理したデータを基にAP処理依頼伝票19（後述する）を
作成する。

アプリケーション・プログラム17は、CUG（Closed Us
er Group）、３者通話、着信課金などの各種のサービス
処理を実行するものであり、個別のサービス処理を実行
した後、DB処理依頼伝票15を作成してデータベース18の
更新等を行う。また、処理結果を基に出力処理依頼伝票
20（後述する）を作成して出力処理モジュール21に出力
する。

出力処理モジュール21は、出力処理依頼伝票20として
受け取ったデータを、信号網において規定されているプ
ロトコルに基づいて所定のデータフォーマットに変換す
るモジュールである。

上述した翻訳チェック処理モジュール13、DB処理モジ
ュール16、及び出力処理モージュル21の全体をまとめて
APIP（Application Interface Platform）22と呼ぶ。

また、上記APIP22には、サービス追加時に各モジュー
ルの機能を拡張する為のコマンド等を入力する為のマン
・マシーン・インタフェース（MMI）23が接続されてい
る。

次に、以上のような構成の実施例の動作を説明する。

以下、加入者からCUG及び着信課金サービスの２つの
サービス要求があった場合について説明する。

第３図は、翻訳チェック処理モジュール13における翻
訳チェック処理のフローチャートである。

先ず、発加入者からのメッセージ（MSG）を受信する
（第３図S1）。

次に、受信メッセージの中からサービスキー（SVC K
EY）を抽出する（第３図S2）。

次に、抽出したサービスキーで相互規制マトリックス
テーブル14（第４図）をサーチし（第３図S3）、両サー
ビス間に相互規制条件が設定されているか否かを判別す
る（第３図S4）。

相互規制マトリックステーブル14とは、第４図に示す
ように縦軸及び横軸に各サービス名Ａ〜Ｆを記載し、そ
れら各サービス相互間の相互規制条件をマトリックス上
に定義したものである。

第４図において、例えばＡサービスとＢサービスとの
交点に記載されている「０」は、両サービス間に相互規
制が無いことを表しており、ＡサービスとＥサービスの
交点に記載されている「pA」はＡサービスを優先して実
行し、Ｅサービスは無視されることを表している。その
他、第４図に示すような種々の相互規制条件に従って、
各サービス間の相互規制条件が決められている。

第３図に戻り、要求のあったサービス間が同時に起動
でないサービスであるときには、出力処理モジュール21
にその内容を通知し、発加入者へメッセージを出力させ
る（第３図S5）。

他方、両サービス間に相互規制条件が無いときには、
両サービスを起動させる（第３図S6）。そして、メッセ
ージとして送られてきた、CUG及び着信課金に関する受
信パラメータ、サービスキー、発信番号、インデックス
コード（Index Code）、OA表示、着信番号等をメモリ
（図示せず）セーブする（第３図S7）。

さらに、サービスキーの内容に対応した処理タグを付
与し、CUG関連及び着信課金関連DB処理依頼伝票15を作
成する（第３図S8）。

本実施例では、各モジュール関及び各モジュールとア
プリケーション・プログラム17間の処理依頼等を共通化
したデータフォーマットにより行っている。

そして、DB処理モジュール16に対して処理依頼を行う
ものをDB処理依頼伝票15、アプリケーション・プログラ
ム17に対して処理依頼を行うものをAP処理依頼伝票19、
出力処理モジュール21に対して処理依頼を行うものを出
力処理依頼伝票20と呼んでいる。これらの処理依頼伝票
は、SCP12内のメモリに記憶される。

第５図は、CUGサービスに関するDB処理依頼伝票15の
一例を示す図である。

この場合、サービスキーが「CUG」であることから、
翻訳チェック処理モジュール13により、処理タグとして
リレー変換が指定され、さらに第１パラメータ（1ST PR
A）としてサービスキー「CUG」が、第２パラメータ（2N
D）して発信番号が、第３パラメータ（3RD）としてCUG
インデックス・・・等が指定されて、第５図に示すよう
なDB処理伝票15が作成される。

ここで、処理タグとは、実行すべき処理内容を指定す
る情報であり、第６図に示すようにそれぞれのサービス
の機能に対応して定義されている。

第６図において、例えば情報Ａから情報Ｂを求め、さ
らに情報Ｂに対応する情報Ｃを求めるCUGのチェック処
理等の場合には、処理タグとしてリレー変換が指定され
る。また、情報Ａと情報Ｂとの一致を調べるパスワード
のチェックなどの場合には、処理タグとしてチェックが
指定される。

他のサービスに対しても、そのサービスが果たす機能
に従って、第６図に示す処理タグがそれぞれ指定され
る。

第７図は、第３図S9のDB処理の内容を説明するフロー
チャートである。

以下、CUGサービスに関するDB処理について、第７図
のフローチャートを参照して説明する。

CUGサービスとは、登録された特定の加入者に対して
のみ行われるサービスである。個々の加入者には、個別
のインデックスコードが割当られており、そのインデッ
クッスコードに対応して決められているインタロックコ
ードが、着信先のCUGデータベースに登録されていれ
ば、サービスを受けることができる。

第７図において、翻訳チェック処理モジュール13から
のDB処理依頼伝票を151受信する（第７図S10）。

次に、そのDB処理依頼伝票15の処理タグから実行すべ
き処理がリレー変換であることを認識する（第７図S1
1）。

次に、DB処理依頼伝票15の第１パラメータのサービス
キーから、アクセス先データベースがCUGデータベース
であることを認識する（第７図S12）。

第８図（ａ）〜（ｄ）は、発側CUGデータベース（Ori
gination CUG DB）及び着側CUGデータベース（Destinat
ion CUG DB）の一例を示す図である。

以下第８図を参照しながらフローチャートの説明を行
う。

次に、第２パラメータの発信番号で発側CUGデータベ
ース24を検索して対応するデータユニット（Deta Uni
t）25（第８図（ａ））を決定する（第７図S13）。

次に、そのデータユニット25の中で、第３パラメータ
のCUGインデックスコードに対応するインタロックコー
ドを抽出する（第７図S14）。次の第４パラメータが区
切りを示すデリミッタであるので、抽出したインタロッ
クコードをソースデータとして登録する（第７図S1
5）。

次に、着信番号で着側CUGデータベース26を検索し対
応するデータユニット27（第８図（ｃ））を決定する
（第７図S16）。

さらに、そのデータユニット27の中をソースデータ、
すなわちインタロックコードで検索し、対応する着側イ
ンデックスコードを求める（第７図S17）。

このようにして求めたインデックスコード（索出デー
タ）と、受信メッセージとからAP処理依頼伝票19を作成
する（第７図S18）。

例えば、DB処理依頼伝票が第５図に示すようなもので
あるとすると、第２パラメータの発信番号「7126666」
から、第８図（ａ）に示すデータユニット25を決定す
る。次に、第３パラメータのインデックスコード「09
0」から、第８図（ｂ）に示すように指定されたユニッ
ト25内のインデックスコード「090」に対応するインタ
ロックコード「12345」を求める。

次に、このインタロックコードがアクセス先に登録さ
れているか否かを調べる為に、第５パラメータの着信番
号「7125555」から、第８図（ｃ）に示すように着側CUG
データベース26のデータユニット27を決定する。さら
に、第８図（ｄ）に示すように、そのデータユニット27
をインタロックコード「12345」で検索し、対応する着
側インデックスコード「010」を求める。

すなわち、上述した処理では、個々のユーザに割当ら
れているインデックスコードを、一旦発CUGデータベー
ス24内部に登録されているインタロックコードに変換し
ている。さらに、着信番号とそのインタロックコードと
から、着側CUGデータベース26にそのインタロックコー
ドが存在するかどうかにより、CUGユーザとして登録さ
れているか否かをチェックしてる。

そして、最終的な着側インデックスコードが得られれ
ば、そのインデックスコードと受信メッセージとからAP
処理依頼伝票19を作成する。

第９図は、上述したDB処理により作成されるAP処理依
頼伝票19の一例を示す図である。

同図に示すAP処理依頼伝票19は、第５図のCUG関連DB
処理依頼伝票15に基づいて作成されたものである。

第９図において、AP処理依頼伝票19の先頭には、実行
すべきアプリケーション・プログラム17を指定するPRO
G.NO.として「CUG」が記憶され、発信番号、着信番号と
共に、DB処理により求めたインタロックコード「090」
と、着側インデックスコード「010」とが記憶されてい
る。

次に、AP処理依頼伝票19を受信したときのアプリケー
ションプログラム（AP）17側での処理内容を、第10図の
フローチャートを参照して説明する。

以下の説明では、アプリケーション・プログラム17と
出力処理モージュル21又はDB処理モジュール16との間の
インタフェースに関する処理についてのみ説明する。

先ず、AP処理依頼伝票19のPROG.NO.により指定される
アプリケーション・プログラム17の個別処理を実行する
（第10図S19）。

次に、この個別処理により得られたデータに基づいて
出力処理依頼伝票20を作成する（第10図S20）。

第11図は、上記出力処理依頼伝票20の一例を示す図で
ある。

同図に示す出力処理依頼伝票20は、第９図のCUG関連A
P処理依頼伝票19に基づいて作成されたものである。

第11図において、出力処理依頼伝票20の先頭には、送
信に関する処理依頼であることを示す処理タグが付与さ
れ、第１パラメータとして送信先の着信番号「712555
5」が、第２パラメータとして着側インデックスコード
「010」等が記憶されている。

第10図に戻り、次にデータベース18の統計情報を更新
する必要があるか否かを判別する（第10図S21）。

統計情報を更新する必要のないときには、第10図のS2
2又はS24に進み、作成した出力処理依頼伝票20を出力処
理モジュール21に出力し、又は個別のAP処理で作成され
るDB処理依頼伝票15をDB処理モジュール15に出力する。

このS22の出力処理は、出力処理モジュール21により
実行されるものであり、出力処理依頼伝票20の処理タグ
から送信処理であることを認識し、さらにそれに続く情
報を信号網のプロトコルに従って所定のフォーマットに
変換して信号網に出力する。

他方、統計情報を更新する必要があるときには、統計
情報の更新の為のDB処理依頼伝票15を作成する（第10図
S23）。そして、次のS24に進み、作成したDB処理依頼伝
票15をDB処理モジュール16に出力してDB処理を起動させ
る。

第12図（ａ）、（ｂ）は、CUGデータベースに対する
アクセス回数を、発信番号別、あるいはインタロックコ
ード別に集計するときのDB処理依頼伝票15の一例を示す
図である。

この場合、第12図に示すように、それぞれのDB処理依
頼伝票15の先頭には、更新処理を指定する処理タグが付
与され、第１パラメータのDB種別を示す情報として「CU
G統計」が、第４パラメータの演算内容を示す情報とし
て「加算」が、第５パラメータの演算単位を示す情報と
して「１」等がそれぞれ記憶される。

第12図（ａ）、（ｂ）示すDB処理依頼伝票15をDB処理
モジュール16が受け取った場合には、先ず、処理タグ及
びDB種別から、CUG統計データベースに関する統計情報
の更新であることを認識する。

次いで、第13図に示すCUG統計情報が記憶されている
データベースのヘッドテーブル30及び２次テーブル31
を、発信番号「7126666」及びインタロックコードによ
り検索し、対応するエリアのデータをそれぞれ＋１とし
て統計情報（この場合アクセス回数）を更新する。

以上のように、上記実施例ではデータベース18とアプ
リケーション・プログラム17との間にAPIP22を設け、こ
のAPIP22の各モジュール間、各モジュールとデータベー
ス18及びアプリケーション・プログラム17間の処理依頼
等を、共通化したデータフォーマット、例えば処理依頼
伝票の形式により行うようにした。

従って、アプリケーション・プログラム17の開発を、
データベース18の構造を意識することなく行うことがで
きる。これにより、プログラム開発が容易になり、交換
網の運用者等が独自にアプリケーション・プログラム17
を開発することが可能となる。

また、従来各アプリケーション・プログラム17内で行
われていたアプリケーション間の相互規制チェックを、
APIP22内部に設けた翻訳チェック処理モジュール13が行
うようにしたので、新たなサービスを追加したときに
も、既存のアプリケーション・プログラム17を変更する
必要がなく、プログラムの開発効率をより高めることが
できる。

次に、新たなサービスを追加する場合に、翻訳チェッ
ク処理モジュール13及びDB処理モジュール16等の機能を
拡張するときの手順について説明する。

以下の説明では、CUGサービスが存在しない状態で、
新たにCUGサービスを追加する場合について述べる。

先ず、翻訳チェック処理モジュール13の機能を拡張す
る場合の手順について、第14図のフローチャートを参照
して説明する。

サービスを追加しようとする場合には、オペレータ
（例えば、交換網の運用者）は、マン・マシーン・イン
タフェース（MMI）23のキーボード（図示せず）等を介
して新たなサービスキーを定義する（第14図S25）。

次に、相互規制マトリックステーブル14（第４図）を
MMI23のディスプレ上に表示させて、そのマトリックス
テーブル14上に新たなサービスを登録し、さらに各サー
ビスキー間の相互規制条件を設定する（第14図S26）。
また、このとき信号網からの受信する受信メッセージの
パラメータを設定する。

次に、追加したサービスのDB処理依頼伝票15のフォー
マットをディスプレイ上で作成し、さらに受信メッセー
ジの各パラメータと、DB処理依頼伝票15の各パラメータ
との対応を定義する（第14図S27）。

第15図は、受信メッセージ及びDB処理依頼伝票15のパ
ラメータの対応関係の説明図である。

例えば、第15図に示すように、受信メッセージのパラ
メータと、DB処理依頼伝票15のパラメータとをディスプ
レイ上に表示させ、それらの対応関係を定義することが
できる。この定義に基づいて、翻訳チェック処理モジュ
ール13は追加されたサービスのDB処理依頼伝票15の作成
を行う。

このように、新たなサービスを追加した場合にも、相
互規制マトリックテーブル14上において、他のサービス
との相互規制条件を設定するだけで良く、既存のアプリ
ケーション・プログラムを変更する必要がない。また、
相互規制条件の設定も非常に簡単になる。

次に、サービス追加時にDB処理モジュール16の機能を
拡張するときの手順を、第16図のフローチャートを参照
して説明する。

先ず、定義したCUGサービスに対応した発CUGデータベ
ース28及び着CUGデータベース29（第17図）の最大サイ
ズを定義する（第16図S28）。また、このとき発CUGデー
タベース28及び着CUGデータベース29をどのコード（例
えば、インデックスコード又はインタロックコードによ
り検索するかを定義しておく。

次に、それぞれのデータベースの構成を定義する（第
16図S29）。

このデータベースの構成の定義にあたっては、例え
ば、次のような拡張コマンドにより新たなデータベース
エリアを定義することができる。

ORG_CUG_DB;発番号;INDEX（0,15）;INTERLOCK（16,3
1）上記のコマンドは、発CUGデータベース28の構成を定
義するコマンドであり、32ビット長のデータエリアの０
ビットから15ビットをインデックスコードのデータエリ
アとし、16ビットから31ビットをインターロックコード
のデータエリアとし、さらに個々の発加入者のインデッ
クスコード及びイントーロックコードを、発信番号順に
データベースに格納することを意味している。

同様な拡張コマンドにより着CUGデータベース29の構
成も定義することができる。

これにより、第17図に示すような発CUGデータベース2
8エリアと、着CUGデータベース29エリアとが確保され
る。

このように、コマンドレベルでデータベースエリアの
確保等を行うことができるので、サービスの追加時のAP
IP22内部の各モジュールの機能拡張を容易に行うことが
できる。

第16図に戻り、次に、追加したサービスに対応するAP
処理依頼伝票19のフォーマットを定義する（第18図S3
0）。

第18図は、受信メッセージ及びAP処理依頼伝票19のパ
ラメータの対応関係の説明図である。

例えば、第18図に示すように受信メッセージとAP処理
依頼伝票19の各パラメータを表示させ、両者をディスプ
レイ上で対応づけることにより、各パラメータ間の関係
を定義することができる。

また、このときDB処理により求められるインタロック
コードと、着インデックスコードとは、それぞれ第４パ
ラメータのデータ、第６パラメータのデータとして定義
しておく。

さらに、新たに追加したCUGサービスのPROG.NO.（サ
ービスキー）を起動管理テーブル（図示せず）に登録し
ておく（第16図S31）。

次に、CUGサービスが起動された際に更新される統計
情報のデータベースエリアを定義する（第16図S32）。

S32の処理では、先ず、何に関する統計情報かを示す
項目と、そのエリアサイズを定義する。これにより、第
13図に示したように、そのデータベースの統計情報が、
発番号とインターロックコードに関するものであること
を示すヘッドテーブル30定義される。

次に、２次テーブル31のエリアサイズ、すなわちそれ
ぞれの項目別の統計情報を記憶するエリアサイズと、イ
ンデックス項目とを定義する。

以上により、発番号別及びインタロックコード別のア
クセス回数を記憶するCUG統計データベースエリアが定
義される。

次に、出力処理モジュールの機能の拡張を行う。

第19図は、このとき定義される出力処理依頼伝票20と
信号網に出力するデータフォーマットとの対応関係の説
明図である。

例えば、第19図に示すようにディスプレイ上で出力処
理依頼伝票20のフォーマットと、信号網へ出力するデー
タフォーマットとを作成し、両者の対応関係を定義する
ことがきる。

このように、MMI23のディスプレイ上で相互規制マト
リックステーブル14、各種の処理依頼伝票等を定義する
ことができるので、新たなサービスを追加する場合の変
更を簡単に行うことができる。

また、各モジュールの機能拡張をMMI23からのコマン
ド入力により行うことができるので、サービス追加に対
して柔軟に対応することができる。

〔発明の効果〕

本発明によれば、データベースの構造を意識すること
なくアプリケーション・プログラム等の開発を行うこと
ができるので、交換網の運用者等が容易にプログラム開
発を行うことができる。

また、各アプリケーションプログラム間の相互規制条
件をマトリックテーブルとして、共通のモジュール内に
持っているので、サービス追加時に既存のアプリケーシ
ョンプログラムを変更する必要が無くなる。

【図面の簡単な説明】

第１図は、本発明の原理説明図、第２図は、本発明の実施例の構成図、第３図は、翻訳チェック処理のフローチャート、第４図は、相互規制マトリックステーブルの説明図、第５図は、CUG関連DB処理依頼伝票の一例を示す図、第６図は、処理タグの説明図、第７図は、DB処理のフローチャート、第８図（ａ）〜（ｄ）は、CUG関連DB処理の説明図、第９図は、CUG関連AP処理依頼伝票の一例を示す図、第10図は、AP側のインタフェース処理のフローチャー
ト、第11図は、出力処理依頼伝票の一例を示す図、第12図（ａ）、（ｂ）は、DB処理依頼伝票の一例を示す
図、第13図は、CUG統計データベースの構成図、第14図は、翻訳チェック処理モジュールの機能拡張時の
手順を示すフローチャート、第15図は、受信メッセージ及びDB処理依頼伝票のパラメ
ータの対応関係の説明図、第16図は、DB処理モジュールの機能拡張時の手順を示す
フローチャート、第17図は、発CUGデータベース及び着CUGデータベースの
一例を示す図、第18図は、受信メッセージ及びAP処理依頼伝票のパラメ
ータの対応関係の説明図、第19図は、出力処理依頼伝票と信号網に出力するデータ
フォーマットとの対応関係の説明図、第20図は、インテリジェントネットワークの構成の一例
を示す図である。１……翻訳モジュール、２……サービス要求メッセージ、３……データベース処理依頼要求、４……データベース処理モジュール、５……サービス実行手段、６……サービス処理依頼要求、７……出力処理モジュール、８……出力処理依頼要求．

Claims

(57)【特許請求の範囲】

【請求項１】複数のサービス実行手段（５）を有するイ
ンテリジェント・ネットワークにおいて、発加入者からのサービス要求メッセージ（２）に基づい
てデータベース処理依頼要求（３）を出力する翻訳モジ
ュール（１）と、該翻訳モジュール（１）からのデータベース処理依頼要
求（３）に基づいて、データベース（18）のアクセスと
前記複数のサービス実行手段（５）に対するサービス処
理依頼要求（６）を行うと共に、該サービス実行手段
（５）からのデータベース処理依頼要求（３）に基づい
てデータベース（18）へのアクセスを行うデータベース
処理モジュール（４）と、前記サービス実行手段（５）からの出力処理依頼要求
（８）に基づいて通信網へのメッセージの出力を行う出
力処理モジュール（７）とを有し、前記各モジュール間（１、４、７）及び各モジュール
（４、７）とサービス実行手段（５）間のそれぞれの処
理依頼要求（３、６、８）を、共通化したデータフォー
マットに基づいて行うことを特徴とするインテリジェン
ト・ネットワークにおけるデータベース管理方式。
【請求項２】前記翻訳モジュール（１）は、複数のサー
ビス実行手段（５）間の相互規制条件を定義した相互規
制マトミックステーブル（14）を有し、同一発加入者か
らの複数のサービス要求に対し、該相互規制マトリック
ステーブル（14）を参照して、該複数のサービスの実行
の可否を判断することを特徴とする請求項１記載のイン
テリジェント・ネットワークにおけるデータベース管理
方式。