JPH04213265A - サービス相互動作制御方式 - Google Patents

Abstract

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

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は交換機またはインテリジ
ェントネットワークのサービス制御ノードにおけるサー
ビス毎にモジュール化された呼処理プログラムの実行制
御におけるサービス相互動作制御方式に関する。

【０００２】近年，交換機またはインテリジェントネッ
トワーク等で実現される通信サービスは，多様化及び複
雑化が進んでおり，サービス実行時には，サービス同士
が互いに影響し合うことになる。従って，サービス開発
時にサービス間の干渉や競合等のサービス相互動作を綿
密に調査し，サービス間に矛盾する動作が行われないよ
うにサービス実行プログラムを開発しなければならない
。しかし，これはサービスの開発を難しくする要因とな
る。一方，サービス相互動作の実現によって，一つ一つ
のサービスを個々に実行する場合よりも，相乗効果によ
る高度なサービスが実現可能となる。従って，プログラ
マビリティを損なわない柔軟なサービス相互動作の実現
が望まれている。

【０００３】

【従来の技術】図４は従来例の２つの制御動作の例，図
５はサービス再開処理の具体的動作例である。図４の２
つの例Ａ．とＢ．は，２つのサービス間の相互動作（中
断と再開）の制御方式であり，先発する１つのサービス
が先発呼処理プログラム（ＣａｌｌＰｒｏｃｅｓｓｉｎ
ｇ　Ｐｒｏｇｒａｍｍ：ＣＰＰで表示）として各処理単
位を順次実行している時に，実行中のサービスに優先す
る他のサービスが要求されて後発ＣＰＰが起動された後
，後発ＣＰＰが動作終了した時の先発ＣＰＰの再開（復
帰）制御の２つのパターンを示す。

【０００４】すなわち，Ａ．の場合，先発ＣＰＰを中断
して起動元の位置から後発ＣＰＰへ移行する時，起動先
のＣＰＰの実行単位のポインタ（アドレス）と共に，復
帰先のポインタ（先発ＣＰＰの起動元の位置）を予め用
意しておき，後発ＣＰＰに移行する時その復帰先のポイ
ントをパラメータとして渡される。これにより，後発Ｃ
ＰＰが終了すると，先発ＣＰＰの元の位置に復帰するこ
とができる。また，Ｂ．の場合も起動先と復帰先をパラ
メータとして渡すが，復帰位置が先発ＣＰＰの起動元と
は別の位置になる例であり，このＢ．の制御は起動元の
状態と後発ＣＰＰの終了時の状態が異なる場合等に実行
される。

【０００５】上記した従来例では，ＣＰＰ間の関係（起
動先，復帰先）がＣＰＰの各処理単位（プログラム）中
に明確なポインタ（アドレス）として記述され，サービ
ス相互動作はＣＰＰ中に記述された範囲内でのみ実行さ
れる。この場合，図４のＡ．の場合は，起動先のサービ
ス終了後に起動元の位置に復帰するので呼情報の引き継
ぎ等が必要であるが，基本的に起動元へ復帰して再開が
可能である。

【０００６】ところが図４のＢ．の例では，後発ＣＰＰ
中に戻り先のアドレスをプログラム中に記述しておかな
い限り，先発ＣＰＰへの復帰は不可能である。図４のＢ
．のサービス再開処理の具体的動作例を図５に示すと，
先発ＣＰＰがアッドオンサービス（３者通話サービス）
で，後発のＣＰＰが割込みサービスに対応する。アッド
オンサービスの処理が開始され，最初に加入者Ａが加入
者Ｂを保留している状態（図５の５０）にあり，一方こ
の時，加入者Ｃ（＝Ｘ）は加入者Ｙと通話しているもの
とする（同６４）。

【０００７】ここで，加入者Ａが割込みサービスを要求
する特番と相手番号（Ｘ）をダイヤルすると，割込みサ
ービスが開始され，加入者Ａは加入者Ｃ（＝Ｘ）及びそ
の通話相手のＹとの間で３者通話が行われる（同６１）
。この話により，ＹがＸ（＝Ｃ）との通話を終了させて
オンフックすると（同６２），加入者ＡとＸとの接続が
行われる。この状態において，アッドオンサービスに復
帰する場合は，アッドオンサービスの処理プログラム中
の，起動元（５１の次の５２）ではなく，それより後の
状態５４になる（Ａ−Ｃが通話中で，Ｂは保留音を聞い
ている状態）。この後の処理は，Ａがフッキングするこ
とにより，Ａ，Ｂ，Ｃの３者通話が開始され（同５５，
５６），Ｂが通話を止めてオンフックすると（同５７）
，ＡとＣによる２者通話となる（同５８）。

【０００８】

【発明が解決しようとする課題】図５（図４のＢ．）に
ついて説明したサービス実行制御を行うためには，サー
ビス開発時に，あらゆるサービス間の関係を調べ，それ
をＣＰＰに記述しなければならない。このためサービス
の開発に時間がかかり，調査や試験が不十分な場合，サ
ービス実行時にサービス間に矛盾が発生し，サービスが
実行されないという障害が発生する危険性がある。そし
て，このような図４のＢ．のようなパターンは，サービ
ス相互動作として基本的なパターンであり，このような
制御方式を多くの制約を受けることは複数のサービスが
相互に関係する通信サービスを提供することが困難にな
るという問題があった。本発明は，サービスに対応する
各呼処理プログラム（ＣＰＰ）を基本的に独立して記述
して，サービス相互動作がダイナミックに実行できるサ
ービス相互動作制御方式を提供することを目的とする。

【０００９】

【課題を解決するための手段】図１は本発明の原理構成
図である。図において，１は電子交換機やインテリジェ
ントネットワークの呼制御を行う処理装置，１０は呼処
理プログラム実行中に発生したイベントを通知するイベ
ント通知部，１１は先発呼処理プログラムとの優先度を
判定するサービス相互動作判定部，１２は通知されたイ
ベントに従って呼処理プログラム格納部から該当する呼
処理プログラム（ＣＰＰ）を選択する呼処理プログラム
（ＣＰＰ）選択部，１３は選択された呼処理プログラム
を実行する基本単位実行エンジン（ＣＰＰＥ）を生成す
る基本単位（ＣＰＰＥ）実行エンジン生成部，１４は基
本単位実行エンジン，１５は各実行エンジンを制御する
実行エンジン制御部，２は呼処理プログラム（ＣＰＰ）
格納部，３は基本単位の構成を表す。

【００１０】本発明は一状態遷移を基本単位とし，各サ
ービスに対応する呼処理プログラムを実行して順次各基
本単位を実行するが，他の優先度の高い後発サービスが
起動すると，先発サービスの各基本単位に対応する基本
単位実行エンジンが生成され，以後各基本単位実行エン
ジンは後発サービスの状態を監視し，後発サービスが終
了すると，その後発サービスの終了時の遷移状態と各基
本単位実行エンジンの状態とのマッチングをとって一致
した１つの基本単位だけが起動して以後の処理が再開さ
れる。

【００１１】

【作用】各サービスに対応する呼処理プログラムは，一
状態遷移（条件状態，イベント，アクション，遷移先状
態）を基本単位３として，１つのサービスだけを実行す
る場合には，それぞれ異なる処理を実行する基本単位が
順番に実行される。処理装置１は交換機やインテリジェ
ントネットワークの呼処理において発生するイベントが
発生すると，イベント通知部１０でサービスの要求を検
出すると，サービス相互動作判定部１１で既に実行中の
先発サービスとの優先度を判定し，判定結果が呼処理プ
ログラム選択部１２に供給される。

【００１２】呼処理プログラム選択部１２は供給された
判定結果に対応する呼処理プログラムを呼処理プログラ
ム格納部２から選択して，基本単位実行エンジン生成部
１３に供給する。基本単位実行エンジン生成部１３は，
その呼処理プログラムの基本単位実行１４エンジンを生
成する。１つのサービスだけ実行している場合は，各基
本単位の実行順序は予め決められており，その順序は各
基本単位のプログラム内にリンケージ情報として格納さ
れている。

【００１３】一方，実行エンジン制御部１５は，先発サ
ービスの途中で後発サービスの実行エンジンが生成され
た場合は，基本単位実行エンジン生成部１３に対し先発
サービスの未実行の処理プログラムに含まれる基本単位
に対応する複数の並列に実行可能な基本単位実行エンジ
ン１４を生成させる。この並列に実行可能な先発サービ
スの基本単位実行エンジン１４はそれぞれ呼状態を監視
し，後発呼処理プログラムが終了した時点の呼状態と一
致する条件状態を有する基本単位実行エンジンだけが実
行再開される。

【００１４】

【実施例】図２はサービス相互制御動作の実施例，図３
はサービス相互動作の処理フローを示す。呼処理プログ
ラムの基本単位（ＣＰＰＥ）は，図２の左側に示すよう
に，最初の状態を表す「条件状態」に対し，外部から事
象の発生を表す「イベント」が入力されると，決められ
た動作「アクション」が実行され，その結果として「遷
移先状態」に移行する一連の処理により構成される。こ
の基本単位を以下ＣＰＰＥ（Ｃａｌｌ　Ｐｒｏｃｅｃｃ
ｉｎｇ　Ｐｒｏｇｒａｍｍ　Ｅｌｅｍｅｎｔ：　呼処理
プログラム基本単位）といい，加入者から要求された各
サービスを処理する各処理プログラム（ＣＰＰ）はこの
ＣＰＰＥが多数組合せた構成がとられている。

【００１５】次に，図２に示す実施例を説明する。この
実施例は，図１の基本構成を用いて，図５に示すアッド
オンと割込みサービスを本発明により実施する例であり
，図２の処理装置（メモリを含む）２０は図１の１に対
応し，２１はアッドオンＣＰＰ（アッドオンサービス用
の呼処理プログラム），２２はその中の各ＣＰＰＥ（呼
処理プログラムを構成する各基本単位），２３は一つの
サービスを実行中に生成されるＣＰＰＥ実行エンジン，
２４−１〜２４−ｎは後発サービスを実行する時に生成
される先発サービス用の複数のＣＰＰＥ実行エンジン，
２５は後発サービスである割込みＣＰＰ（割込みサービ
ス用の呼処理プログラム），２６は割込みＣＰＰを構成
するＣＰＰＥ，２７は割込みＣＰＰＥを実行する時に生
成される単一のＣＰＰＥ実行エンジン，２８は状態設定
プロセス，２９は呼状態データ領域，３０は状態通知プ
ロセスである。

【００１６】図１の処理装置（メモリを含む）１におい
て，イベント通知部１０によりアドオンサービスを要求
する特番ダイヤル検出を表すイベントが通知されると，
サービス相互動作判定部１１（図１）において，サービ
ス相互動作が判定され先発サービスが存在しないと，ア
ッドオンサービスがＣＰＰ選択部１２で選択され，さら
にＣＰＰＥ実行エンジン生成部１３においてＣＰＰＥ実
行エンジン２３が生成される。この場合実行エンジンは
１つだけ生成される（一つのサービスだけが実行中だか
ら）。ここで，実行エンジンは並列に実行可能なプロセ
スである。

【００１７】ＣＰＰＥ実行エンジン２３はアッドオンＣ
ＰＰ２１内のＣＰＰＥ（基本単位）２２を一つずつ逐次
実行する。実行方法は，ＣＰＰＥ（図２の左側参照）に
設定されている条件状態（先頭の状態）及びイベントを
現在の呼状態及び発生したイベントと照合し，マッチン
グに成功したＣＰＰＥを選択し，そのＣＰＰＥに規定さ
れたアクションを実行し，呼状態を規定された遷移先状
態に遷移させるものである。この時，全てのＣＰＰＥ（
実行エンジンは１つ）についてマッチング処理を行わな
ければならない。

【００１８】しかし，１サービス内ではＣＰＰＥの実行
順序は予め決められるものであるから，他のサービスが
途中で開始されない場合，その順序をＣＰＰＥ間のリン
ケージ情報としてＣＰＰ内に設定しておく。すなわち，
各ＣＰＰＥ（図２の２３）内に次に続くＣＰＰＥが格納
されたアドレス情報をリンケージ情報として保持させる
。この場合，実行エンジンはマッチング処理を行わず，
このリンケージ情報に基づきＣＰＰＥを順次実行する。 これによりマッチング処理のオーバーヘッドが削減でき
る。

【００１９】次にアッドオンＣＰＰ２１を実行中に，イ
ベント発生（割込みサービスを要求する特番ダイヤルを
検出）により割込みサービスの起動要求が検出されると
，サービス相互動作判定部１１（図１）の判定が行われ
て，先発サービスとの優先度を判定する。この場合，先
発サービスであるアッドオンよりも割込みサービスの優
先度が高いため，アッドオンサービスを中断し，制御を
割込みサービスに移す。この結果，ＣＰＰ選択部１２（
図１）において，割込みＣＰＰ２５が選択され，さらに
ＣＰＰＥ実行エンジン生成部１３（図１）において，割
込みＣＰＰ用のＣＰＰＥ実行エンジン２７が生成される
。

【００２０】実行エンジン制御部１５（図１）ではＣＰ
ＰＥ実行エンジン生成部１３（図１）に対し，アッドオ
ンＣＰＰ内の各ＣＰＰＥ毎に実行エンジンを生成するこ
とを指令する。また，現在の呼状態を呼状態データ領域
２９に設定する処理を行う状態設定プロセス２８及び呼
状態データ領域２９の内容をアッドオンＣＰＰ用の各実
行エンジンに通知する状態通知プロセス３０を生成する
。状態設定プロセス２８は，割込みＣＰＰ２５が各ＣＰ
ＰＥを実行する毎に，その遷移先状態をＣＰＰ実行エン
ジン２７から受けとり，呼状態データ領域２９に設定す
る。

【００２１】状態通知プロセス３０は，呼状態データ領
域２９に新たに呼状態が設定される毎に，それをアッド
オンＣＰＰ用の全てのＣＰＰＥ実行エンジン２４−０〜
２４〜２４ｎに通知する。但し，割込みサービスが終了
しない時は，これらの各実行エンジン２４−０〜２４〜
２４ｎはなにもしない。割込みサービスが終了すると，
終了したことを表す通知が，呼状態データと共に通知さ
れると，各実行エンジン２４−０〜２４〜２４ｎは，並
列してそれぞれのＣＰＰＥの条件状態と通知された呼状
態（割込みサービスの最終状態）を照合する。照合は，
それぞれ照合のサブルーチンを呼び出して行われる。マ
ッチングに成功した１つの実行エンジンのみが処理を継
続し，他の実行エンジンは消滅する。これによりアッド
オンサービスは割込みサービスの起動状態とは別の状態
から処理を再開することができる。

【００２２】次に図３に示す処理フローを説明する。こ
の処理フローは上記の図２の制御を実現するための処理
フローであり，処理装置（図１の処理装置に対応）にお
いて実行される。図３において，最初にイベント通知に
よりサービス起動要求を検出すると（同３１），先発サ
ービスが存在するか判断する（同３２）。先発サービス
がない場合は，初めてのサービス要求であるから，その
サービスの呼処理プログラムを選択する（同３３）。

【００２３】選択された呼処理プログラムは図１に示す
呼処理プログラム格納部２から取り出され，選択された
ＣＰＰ用のＣＰＰＥ実行エンジンを１つ生成する（同３
４）。なお，このＣＰＰＥ実行エンジンは，計算機等の
情報処理技術において公知のプロセス（またはタスク）
に対応する。このサービスには，先発サービスが存在し
ないので，１つのＣＰＰＥが実行されると，そのＣＰＰ
Ｅに格納されたリンケージ情報（次に実行されるべきＣ
ＰＰＥの格納アドレス）に基づいて順次ＣＰＰＥを実行
して（同３５），終了する。

【００２４】ステップ３２において，先発サービスがあ
る場合，要求された後発サービスが優先することが判別
されると，その後発サービスが実行される前に先発ＣＰ
Ｐ内の各ＣＰＰＥ毎にそれぞれ実行エンジンを生成する
（同３６）。これにより先発サービスの未実行の各ＣＰ
ＰＥに対応する複数のプロセスが並列に設けられるが，
何らかの状態が通知されて起動条件が成立するまで待機
状態に置かれる。この後，呼状態データ（現在の呼がど
のような状態にあるかを表示するデータ）を設定する処
理を行う呼状態設定プロセスと，呼状態データを他の待
機中の複数のプロセスに通知する処理を行う状態通知プ
ロセスを生成する（同３７）。

【００２５】次に後発ＣＰＰの各ＣＰＰＥ実行終了毎に
，そのＣＰＰＥの遷移先状態を状態設定プロセスにより
呼状態データ領域に設定する（同３８）。呼状態データ
領域に前記遷移先状態が設定されるとその都度，状態通
知プロセスが起動して設定された遷移先状態を先発サー
ビスについて生成された各ＣＰＰＥ実行エンジンに対し
て通知する（同３９）。この時，先発サービスが終了し
た場合には，終了通知も同時に付加されており，各ＣＰ
ＰＥ実行エンジンは，それぞれ先発サービスが終了した
かを判断し（同４０），終了してないと（終了通知が無
い場合）各実行エンジンはそのまま待機状態に留まり，
後発サービスの状態変化を監視する処理（ステップ３８
，３９）に戻る。

【００２６】後発サービスが終了した通知を，呼状態デ
ータと共に受けると，ステップ３０に移行し，先発ＣＰ
Ｐの各ＣＰＰＥ実行エンジンにおいて，それぞれのＣＰ
ＰＥの条件状態（図３の最初の状態）と通知された状態
（後発サービスの終了時の遷移先状態（図３の最後の状
態）を照合する動作を並行して実行する（同４１）。こ
の照合によりマッチング（一致）に成功した実行エンジ
ンだけが処理を継続させ，他の実行エンジンは消滅させ
る（同４２）。これによりサービス相互動作の制御を終
了する。

【００２７】

【発明の効果】本発明によれば先発呼処理プログラムの
各基本単位毎に実行エンジンが生成され，各実行エンジ
ンが呼状態を監視し，後発呼処理プログラムが終了した
時点の呼状態と一致する条件を有する基本単位の実行エ
ンジンだけが実行再開されるので，呼処理プログラム間
の関係を呼処理プログラム中に明示しないでも，サービ
ス相互動作の実現が可能となる。また，サービス追加時
に，既存サービスへの影響が少ない。さらに，サービス
開発時に，サービス相互動作を意識する必要が殆どなく
，基本的にそれぞれ独立して作成することができ，宣言
的記述のためサービスの部分変更／追加が比較的容易で
あり，基本単位を部品化することも可能となり，サービ
ス相互動作がダイナミックに実現できる。

【図面の簡単な説明】

【図１】本発明の基本的構成を示す図である。

【図２】サービス相互制御動作の実施例である。

【図３】サービス相互動作の処理フローを示す図である
。

【図４】従来例の２つの制御動作の例を示す図である。

【図５】サービス再開処理の具体的動作例である。

【符号の説明】

１　　　　　　電子交換機やインテリジェントネットワ
ークの呼制御を行う処理装置 １０　　　　イベント通知部 １１　　　　サービス相互動作判定部 １２　　　　呼処理プログラム（ＣＰＰ）選択部１３　
　　　基本単位（ＣＰＰＥ）実行エンジン生成部１４　
　　　基本単位（ＣＰＰＥ）実行エンジン１５　　　　
実行エンジン制御部 ２　　　　　　呼処理プログラム（ＣＰＰ）格納部３　
　　　　　基本単位

Claims (3)

【特許請求の範囲】
1. 【請求項１】　　交換機またはインテリジェントネット
   ワークのサービス制御ノードにおけるサービス毎にモジ
   ュール化された呼処理プログラムの実行制御において，
   条件状態，イベント，アクション，遷移先状態を組合せ
   た一状態遷移を基本単位とし，基本単位を組合せた宣言
   的記述により呼処理プログラムを構成し，一サービス内
   の各基本単位は，予め次に実行すべき基本単位にリンケ
   ージする情報を備えることを特徴とするサービス相互動
   作制御方式。
2. 【請求項２】　　請求項１において，一サービスの呼処
   理プログラムの実行中に優先度の高いサービスである後
   発の呼処理プログラムが起動されると，先発呼処理プロ
   グラムを中断すると共に先発呼処理プログラムの未実行
   の各基本単位毎に対応する基本単位実行エンジンが並行
   して生成され，各先発呼処理プログラムの基本単位実行
   エンジンは前記後発呼処理プログラムの呼状態を監視し
   て，後発呼処理プログラムが終了すると先発呼処理プロ
   グラムを再開することを特徴とするサービス相互動作制
   御方式。
3. 【請求項３】　　請求項２において，前記生成された先
   発呼処理プログラムの各基本単位実行エンジンは，後発
   呼処理プログラムの終了時の遷移先状態を通知されると
   ，該遷移先状態と自基本単位の条件状態とマッチングを
   取り，一致する条件状態を有する１つの基本単位実行エ
   ンジンのみが実行再開することを特徴とするサービス相
   互動作制御方式。