JPH09502841A - 通信網用耐障害サービス提供装置 - Google Patents

Abstract

(57)【要約】 基本呼処理により呼の設定、保守および切断を実現する交換機と、該交換機と通信して該基本呼処理に追加のサービスを提供するサービス提供手段（ＳＰＡ）とを含む通信網アーキテクチャは周知である。一般に通信網に課せられる高い可用性の要件ために、サービス提供手段は、一般に耐障害設計である必要がある。サービス提供手段の第１のサービス論理（５０）から現在提供されているサービスについての状態データを確実に記憶（５５）するためのチェックポインティングに依存する耐障害アーキテクチャが提供されている。すなわち、第１のサービス論理（５０）が故障した場合、第２のサービス論理（５２）が動作し、バックアップ記憶（５５）から現在のサービスに所要の状態データが提供される。第１の論理（５０）によるデータのチェックポインティングの量を減らすために、状態データは、対応する呼が安定段階に達した時にのみチェックポインティングされ、設定時の呼の損失は、呼が確立された後よりもはるかに許容できるものとなる。

Description

【発明の詳細な説明】 通信網用耐障害サービス提供装置 技術分野 本発明は、通信網、さらに詳細には、通信網の交換局に呼処理サービスを提供 する耐障害サービス提供装置に関する。 背景技術 呼の設定、保守および切断を行う基本呼処理を実現する交換機と、該交換機と 通信して該基本呼処理に追加のサービスを提供するサービス提供手段とを含む通 信網アーキテクチャは周知である。そのような追加のサービスの例は次のような ものである。 ３ウェイ呼出し コール・スクリーニング コール・フォワーディング コール・ウェイティング テレボーティング ８００番号ルックアップ イエロー・ページ・プラス アカウント・カード／クレジット・カード呼出し ネットワーク自動呼出し配布 専用仮想ネットワーク コール・ブロッキング ウェイクアップ・コール フリーフォン／テレインフォメーション 呼出し名前送達 高速ダイヤル呼出し 汎用個人電話 番号翻訳 そのような配置の交換機は、一般に、２つまたはそれ以上の呼部分（「セグメ ント」ともいう）からなる呼を扱い、そのような各呼部分の設定、保守および切 断を実行する。したがって、交換機が複数の交換局または交換点からなる場合、 一般に、各交換局において発着信呼部分を有する呼を扱う。もちろん、そのよう な配置でも、呼は、高位レベルではただ１つの部分からなると考えられる。交換 機の基本呼処理機能性とサービス提供手段とを接続するために、交換機にはイン タフェース手段が備えられる。これらのインタフェース手段により、交換機が、 特定の呼部分に関してサービス提供手段からサービス提供を要求し、かつその呼 部分の設定、保守および切断のプロセスによってサービス提供手段に経過を報告 できるようになり、また該サービス提供手段が、サービス提供手段によって提供 されているサービスに従ってそのプロセスを促進できるようになる。 ＡＩＮ（Aｄｖａｎｃｅｄ Ｉｎｔｅｌｌｉｇｅｎｔ Ｎｅｔｗｏｒｋ）と呼 ばれるそのような従来技術の通信網アーキテクチャの１つがＢｅｌｌｃｏｒｅに よって提案され、以下およびその他の文献に詳細に記述されている。 Ａｄｖａｎｃｅｄ Ｉｎｔｅｌｌｉｇｅｎｔ Ｎｅｔｗｏｒｋ Ｒｅｌｅａｓｅ １ Ｎｅｔｗｏｒｋ＆Ｏｐｅｒａｔｉｏｎｓ Ｐｌａｎ，Ｂｅｌｌｏｒｅ Ｓ ｐｅｃｉａｌ Ｒｅｐｏｒｔ ＳＲ−ＮＰＬ−００１６２３（１９９０年６月発 行）。 Ａｄｖａｎｃｅｄ Ｉｎｔｅｌｌｉｇｅｎｔ Ｎｅｔｗｏｒｋ Ｒｅｌｅａｓｅ １ Ｓｗｉｔｃｈ−Ｓｅｒｖｉｃｅ Ｃｏｎｔｒｏｌ Ｐｏｉｎｔ（ＳＣＰ） Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｔｏｃｏｌ Ｉｎｔｅｒｆａｃｅ Ｇｅｎｅｒ ａｌ Ｒｅｑｕｉｒｅｍｅｎｔｓ，Ｂｅｌｌｃｏｒｅ Ｔｅｃｈｎｉｃａｌ Ａ ｄｖｉｓｏｒｙ ＴＡ−ＮＷＴ−００１１２６（１９９１年５月発行）。 本願に含まれる本発明の実施例の説明は、ＡＩＮネットワークの文脈において 行い、したがって本発明の記載した実施例に関連して、全体的なネットワーク・ アーキテクチャの実施の詳細について前記の文献を参照する。しかしながら、前 記の文献を参照しなくとも本発明を容易に理解できるように、ＡＩＮネットワー クのいくつかの重要な様態について、第１図から第９図までを参照して、本願で 説明する。これらの図は、Ｂｅｌｌｃｏｒｅの文献に現れる図に基づく。本発明 は、ＡＩＮネットワーク以外の環境においても適用可能であることを理解された い。 本導入を目的として、添付の図面の第１図を参照して、一般的なＡＩＮアーキ テクチャの概略を述べる。 第１図のネットワークでは、基本呼処理（すなわち、呼の設定、保守および切 断）は、エンド・ユーザ１１がそれに接続されている１つ（または複数）のサー ビス交換点ＳＳＰ１０によって実行される。前掲のサービスのような追加のサー ビスは、要求があれば、どちらもサービス提供手段（ＳＰＡ）の例であるサービ ス制御点（ＳＣＰ）１２か付属１３のどちらかによってＳＳＰ１０に提供される 。付属１３は、ＳＳＰ１０と直接関連するが、ＳＣＰ１２とＳＳＰ１０は、一般 に信号転送点１８を含む共通チャネル交換（ＣＣＳ）ネットワーク１４を介して 互いに通信する。ＳＣＰ１２は、複数のＳＳＰ１０と関連できる。各ＳＰＡ（Ｓ ＣＰ１２でも付属１３でも）は、１つまたは複数のサービス論理プログラム（Ｓ ＬＰ）１６のインスタンスが実行できるサービス論理実行環境（ＳＬＥＥ）１５ を提供する。ＳＬＥＥ１５とＳＬＰ１６は共同で、ＳＳＰ１０にサービスを提供 するサービス論理機能性を提供する。 動作中、ＳＳＰ１０は、呼を受信すると、呼がＳＰＡ１２、１３の提供するサ ービスを必要としているかどうかを確認するために、内部トリガ条件あるいはユ ーザ情報（例えばダイヤル番号）を検査する。すなわち、トリガ条件の検査は、 呼処理において複数の異なる点で実行される。ＳＳＰ１０は、サービスが必要で あると決定する場合、所望のサービスを要求するようにＳＰＡにメッセージを送 り、その接続性および呼処理状況で表された論理表現をそれに送る。次いで、Ｓ ＰＡは、要求されたサービスを提供する。これは、ＳＳＰとＳＰＡの間の単一の 対話か、対話のセッションのどちらかを伴う。 ＳＳＰ１０と付属１３の他に、第１図のネットワークは、インテリジェント周 辺機器（ＩＰ）１６とオペレーション・システム（ＯＳ）１７を含む。ＩＰ１６ は、音声告知能力やＤＴＭＦ番号収集能力などの資源をＳＳＰ１０に提供する。 ＯＳ１７は、ネットワークおよびそのサービスを概観し、ネットワークの監視や 制御などの機能を実行する。 ネットワークがそれにより呼を経路指定できる複数のＳＳＰ１０からなる場合 、各ＳＳＰは、第１図のＳＳＰ１０と同じサポート資源を備えることが好ましい 。 前記のＡＩＮネットワークの概観から、ＳＰＡ１２、１３がネットワークの不 可欠な部分であり、したがって、可用性および信頼性に関してＳＳＰ１０自体と 同様な制約を受けることが理解されよう。これらの要件を満足するために、ＳＰ Ａ１２、１３に耐障害アーキテクチャが必要である。 １つの可能な解決策は、構成要素やサブシステムの障害が検出処理される場所 に低位レベル（すなわちハードウェア）の耐障害性を提供することである。しか しながら、そのような解決策は、一般に高価であり、プロセッサ技法の改善によ り迅速に利益を得られない。 したがって、さらに魅力的な解決策は、汎用プロセッサを使用して処理能力の 複写を行うことである。この種の可能な解決策の１つは、多数のプロセッサが、 それぞれ同じプロセスを実行し、同じデータを受信し、かつ同じ処理を実行する 能動複写を使用し、次いで多数決投票スキームを使用して処理結果を決定するこ とであろう。しかしながら、そのような解決策は、高価であり、システム動作が 決定的である場合にのみ可能である。処理能力の複写を使用する他の可能な解決 策は、通常主処理資源が処理を実行し、次いで処理の結果に従ってバックアップ 処理資源を更新する受動複写である。このようにして、バックアップ処理資源は 、状態データに関して連続的に更新され、したがって主資源が故障した場合に、 主資源を迅速に受け継ぐ。しかしながら、ＳＰＡは、一般に１秒間に１千回のサ ービス要求を処理する。ＳＰＡが呼情報を（例えば）３分間保持する必要がある とすると、常に１８万回の呼についての情報（料金請求情報を含む）が記憶され ることになる。サービス要求の数が多すぎるので、データが変化するときはいつ でも、各呼に関する状態データを主処理手段から転送することは実際的ではない （状態データが変化する場合、対応する呼に関するすべての状態データを転送す るか、または変化のみを転送する前に、変化を識別記録するために特別な処理を 実行する必要があることに留意されたい。どちらの場合も、資源ローディングは 、一般に状態データの変化を生じた処理の結果をＳＰＡに戻すのに必要なローデ ィ ングよりもかなり大きい。） 他の可能な耐障害アーキテクチャは、受動複写の場合のように主処理手段およ びバックアップ処理手段を提供するが、状態データを主処理手段から安定な記憶 装置にバックアップすることである。すなわち、主処理手段が故障した場合、バ ックアップ処理手段を動作させ、バックアップ記憶装置内に保持された状態デー タを通過させる。しかしながら、そのようなアーキテクチャには、受動複写に関 連して前記と同じ欠点がある。 本発明の目的は、改善された耐障害サービス提供手段を提供することである。 発明の概要 本発明の１つの様態によれば、それにより設定、保守および切断される呼セグ メントに関して、呼処理サービスを通信網の交換局に提供するサービス提供装置 において、 通常該サービスを交換局に提供する第１のサービス論理手段と、 該第１のサービス論理手段が故障した場合、該サービスを交換局に提供する第２ のサービス論理手段と、 該第１のサービス論理手段の故障に反応して、該第２のサービス論理手段を動作 させる障害回復手段と、 バックアップ記憶装置とを含み、 該第１のサービス論理手段が、現在サービスを提供している各呼セグメントにサ ービスが提供されると、第１のサービス論理手段によって保持される状態データ を該バックアップ記憶装置に保管し、この状態データの保管が、第１のサービス 論理手段が対応する呼セグメントの設定時に必要なそのサービス提供動作の少な くとも大部分をほぼ完了したことを決定した直後に、該呼セグメントに関して実 現され、該第２のサービス論理手段が動作すると、現在の呼セグメントにサービ スを提供し続けるのに必要な状態データを該バックアップ記憶装置から検索する ことを特徴とするサービス提供装置が提供されている。 この配置によれば、ＳＳＰとＳＰＡの間の対話のほとんどが呼の設定（設定の 持続期間は１秒以下）中に起こるので、状態データをバックアップするのに必要 なＳＰＡ（すなわち、前述の「第１のサービス論理手段」）の主処理資源の資源 ローディングはかなり減少する。呼の設定中に呼情報が失われたとしても、収入 はほとんど失われず、エンド・ユーザは、呼が故障しても再試行できるのでまっ たく問題はない。ＳＰＡが呼の設定中に累積する単位呼情報は、関連する呼部分 がＳＳＰとＳＰＡの間の対話の数が一般に小さい点において安定な場合（すなわ ち確立されている場合）にのみ重要になり、データは、呼出し期間が進行するに つれて徐々に重要になる。 本発明によれば、ＳＰＡの第１のサービス論理手段は、呼セグメントの設定時 に必要なサービス提供動作の少なくとも大部分が完了している点を自動的に認識 し、障害を回避するバックアップ記憶装置に呼データを保管する。故障の場合に は、設定の進行中に呼の大部分が失われるが、サービス提供状態データがバック アップ記憶装置内に記憶された（すべての安定な呼を含む）どの呼についても、 第２のサービス論理手段を開始し、かつそれにバックアップ記憶装置内に保持さ れた状態データを提供することによって、サービス提供を再開できる。 １つの実施例では、呼セグメントの設定プロセスの少なくとも大部分が完了し たことを交換局によって通知された場合、第１のサービス論理手段は、対応する 呼セグメントの設定時に必要なそのサービス提供動作の少なくとも大部分をほぼ 完了したことを決定する。あるいは、第１のサービス論理手段は、サービス提供 が進行中の場所を通知するだけで、対応する呼セグメントの設定時に必要なその サービス提供動作の少なくとも大部分をほぼ完了したことを決定する。後者と同 様な他の方法は、第１のサービス論理手段が、対応する呼セグメントがその安定 段階に入るまで、次のサービス提供動作が必要とされないことを決定する場合、 対応する呼セグメントの設定時に必要なそのサービス提供動作の少なくとも大部 分をほぼ完了したことを決定することである。 バックアップ記憶装置内に保持された状態データを最新に保つために、第１の サービス論理手段による特定の呼セグメントに関する状態データの記憶装置への 第１の保管に従って、第１のサービス論理手段においてこの状態データが変化す ると、バックアップ記憶装置内に保持された状態データが更新される。 該バックアップ記憶装置は、耐障害データベースまたはディスク・ドライブで あることが好ましい。 バックアップされたデータは、第２のサービス論理手段の動作時にすべてがそ れに転送されないことが有利である。すなわち、バックアップされたデータは、 すべて第２のサービス論理手段に転送されると、第２の論理手段が利用できる前 に大きい遅延が導入されるだけでなく、データの一部が再び必要とされないので 不要となる。代わりに、特定の呼セグメントに関する状態データは、該第２のサ ービス論理手段が該交換局からの通信の結果としてそのような情報を必要とする 場合、該第２のサービス論理手段に転送されることが好ましい。 １つまたは複数の呼のセッションが、そのようなセッションに関するセッショ ン情報をＳＰＡ内に保持して確立できる場合、このセッション情報も、該バック アップ記憶装置にバックアップされることが好ましい。このバックアップされた セッション情報は、第２のサービス論理手段が動作すると、バックアップ記憶装 置から第２のサービス論理手段に転送されることだけであることが有利である。 その場合、対応するセッションに関連する現在の呼セグメントについての状態デ ータも第２のサービス論理手段に転送される。 本発明の他の様態によれば、それにより設定、保守および切断される呼セグメ ントに関して、呼処理サービスを通信網の交換局に提供するサービス提供装置に おいて、 通常該サービスを交換局に提供する第１のサービス論理手段と、 該第１のサービス論理手段が故障した場合、該サービスを交換局に提供する第２ のサービス論理手段と、 該第１のサービス論理手段の故障に反応して、該第２のサービス論理手段を動作 させる障害回復手段と、 バックアップ記憶装置とを含み、 該第１のサービス論理手段が、現在サービスを提供している各呼セグメントにサ ービスが提供されると、第１のサービス論理手段によって保持される状態データ を該バックアップ記憶装置に保管し、この状態データの保管が、セグメントの設 定プロセスの少なくとも大部分が完了した直後に、該呼セグメントに関して実現 され、該第２のサービス論理手段が動作すると、現在の呼セグメントにサービス を提供し続けるのに必要な状態データを該バックアップ記憶装置から検索するこ とを特徴とするサービス提供装置が提供されている。この場合、状態データをい つ保管すべきか決定するのに使用されるのは、（サービス提供動作の完了ではな く）呼セグメント設定プロセス自体の少なくとも大部分の完了である。 本発明の他の様態によれば、呼の設定、保守および切断を行う基本呼処理を実 現する交換機と、該基本呼処理に追加のサービスを提供する該交換機と通信する 手段とを含む通信網において、該交換機が、該呼を少なくとも１つの呼部分から なるものとして扱い、該交換機がそのような各呼部分の設定、保守および切断を 行い、交換機とサービス提供手段とを接続し、それにより交換機が特定の呼部分 に関してそこからサービス提供を要求し、その呼部分の設定、保守および切断の プロセスによってサービス提供手段に経過を報告できるようになり、かつ該サー ビス提供手段が、サービス提供手段によって提供されているサービスに従ってそ のプロセスを促進できるようになるインタフェース手段を含み、 該インタフェース手段が、対応する呼部分の設定が少なくともほぼ完了した時に サービス提供手段に報告し、 該サービス提供手段が、通常該サービスを交換機に提供する第１のサービス論理 手段と、該第１のサービス論理手段が故障した場合、該サービスを交換機に提供 する第２のサービス論理手段と、該第１のサービス論理手段の故障に反応して、 該第２のサービス論理手段を動作させる障害回復手段と、バックアップ記憶装置 とを含み、該第１のサービス論理手段が、第１のサービス論理手段によって保持 される現在サービスを提供している各呼部分に関する呼部分関連データを該バッ クアップ記憶装置に保管し、このバックアップが、交換機の該インタフェース手 段がその呼部分の設定が少なくともほぼ完了したことを報告した直後に、該呼部 分に関して実現され、かつ該第２のサービス論理手段が、動作すると、現在の呼 部分に要求されたサービスを提供し続けるのに必要な該呼部分関連データを該バ ックアップ記憶装置から提供されることを特徴とする通信網が提供されている。 図面の簡単な説明 添付の概略図面を参照し、非制限的な例を用いて、本発明を実施するサービス 提供装置（ＳＰＡ）について説明する。 第１図は、基本呼の設定および切断に追加のサービスを提供するように企図さ れた通信網用の周知の一般的なアーキテクチャを示す図である。第１図のネット ワークは、特に、サービス交換点（ＳＳＰ）と、サービス提供装置（ＳＰＡ）の ２つの配置、すなわちサービス制御点（ＳＣＰ）および付属プロセッサを含む。 第２図は、発信呼セグメントと着信呼セグメントを含む、単一のＳＳＰによっ て扱われる２者呼用の接続性モデルを示す図である。 第３図は、それぞれ各ＳＳＰの発信呼セグメントと着信呼セグメントを含む、 ２つのＳＳＰを通過する２者呼用の接続性モデルを示す図である。 第４図は、第１図のＳＳＰの処理機能性の図である。 第５図は、発信呼セグメントについて第１図のＳＳＰ基本呼処理機能性をモデ ル化した発信基本呼モデル（ＢＣＭ）の簡単化した状態遷移図である。 第６図は、第５図と同様な着信ＢＣＭの簡単化した状態遷移図である。 第７図は、それぞれ第５図および第６図の発信ＢＣＭおよび着信ＢＣＭによる 進行に関連する発信呼セグメントおよび着信呼セグメントの接続性状態を示す図 である。 第８図は、第５図および第６図に示されるトリガ・チェック・ポイント（ＴＣ Ｐ）ブロックによって表される処理を示す流れ図である。 第９図は、接続ビュー（ＣＶ）の構成を表し、ＣＶ処理に関連する情報の流れ を示す図である。 第１０図は、本発明を実施する、第１図のＳＣＰまたは付属プロセッサとして 使用するのに適したサービス提供装置のブロック図である。 好ましい実施例の説明 本発明を実施するサービス提供装置を、前に概説した第１図の従来技術のネッ トワークに関して、以下に説明する。サービス提供装置が、呼処理時のどの段階 において、呼状態情報のバックアップを実現するかを十分に理解するためには、 ＳＳＰ１０とＳＰＡ１２、１３の間の対話に関連する要素を画定する前述のＢｅ ｌｌｃｏｒｅの文献に示される呼モデルを理解する必要がある。したがって、こ の呼モデルの主要な特徴を以下に説明する。 呼モデルは、多くの現在のデジタル交換機に使用されている既存のデジタル交 換機の機能性に基づいて作成される概念モデルである。具体的には、呼モデルは 、ＳＳＰ内にどのような追加の処理機能性が必要であるか、さらにＳＰＡとのイ ンタフェースを提供するために、標準的な基本呼処理を画定する。以下でさらに 詳しく説明するように、この追加の機能性は、２つの処理ブロック、すなわち呼 部分を設定および切断する基本呼処理に関連するＢＣＭ処理と、サービスを必要 とする各呼部分の概観を提供し、ＳＰＡと対話する接続ビュー（ＣＶ）処理に分 割される。そのＢＣＭおよびＣＶ処理機能性ブロックを有する呼モデルが、ＳＳ ＰとＳＰＡの間の対話をモデル化する手段であることを理解されたい。すなわち 、ＳＳＰの実際の実行は、一般に、モデルに直接対応しないが、それでもモデル の全体的な機能性を包含する。 接続性の表現 呼モデルは、呼が通過する各ＳＳＰ１０内の発信呼部分と着信呼部分から構成 される呼のビューに基づく。これらの呼部分は、呼セグメントＣＳと呼ばれ、現 在のデジタル交換機の実行に従って機能上異なった方法で扱われる。したがって 、各ＣＳには、ＳＰＡ１２、１３からそれぞれのサービスが独立して提供され、 同じ呼に関連する異なるＣＳが、異なるＳＰＡによってサービス提供される。 第２図は、単一のＳＳＰ１０を通って完成され、したがって２つの呼セグメン トＣＳ１、ＣＳ２のみからなる２者呼を示す。しかしながら、第３図は、２つの ＳＳＰ１０を通過し、したがってＣＳ１からＣＳ４の４つの呼セグメントからな る２者呼を示す。セグメントＣＳ１、ＣＳ３は、発信ＣＳであり、セグメントＣ Ｓ２、ＣＳ４は、着信ＣＳである。 第２図および第３図からわかるように、ＣＳ自体は、２つの脚ＬＯ、ＬＩと接 続点ＣＰから構成されると考えられる。すなわち、２つの脚は、発呼側と被呼側 のそれぞれに向かう通信経路に対応する（したがって、第３図のＣＳ２の脚ＬＯ はトランクを表す。） 実際に、ＣＳは、接続点の片側に複数の脚がある多者呼のような場合、２つ以 上の脚を含む。脚とＣＳのＣＰとの関連は、ＣＰの接続性、すなわち、接続の構 成方法を表す。 呼モデル 前記のＳＳＰ内の発信ＣＳと着信ＣＳへの呼のセグメンテーションの結果、Ｓ ＳＰ１０とＳＰＡ１２、１３を相互接続する呼モデルが、ＣＳに関連して画定さ れる。 さらに具体的には、呼モデルは、ＳＰＡと、ＣＳの交換に基づいた呼処理とを 相互接続するために、ＢＣＭ処理機能性とＣＶ処理機能性の両方を各ＣＳにもた らした基本呼処理に追加される。したがって、第４図では、ＳＳＰ内の２者呼用 の交換に基づいた呼処理（呼の設定、保守および切断）は、アクセス処理ブロッ ク２０および基本呼処理ブロック２１によって表され、一方、追加のＢＣＭ処理 ブロック２２およびＣＶ処理ブロック２３は、各ＣＳに加えられる。ＢＣＭ処理 ブロック２２は、アクセス処理ブロック２０および基本呼処理ブロック２１と対 話して、どちらも関連するＣＶ処理ブロック２３に、関連するＣＳについての基 本呼処理操作の進行について報告し、かつこれらの基本操作をＣＶ処理ブロック を介してＳＰＡにより制御できるようになる。ＣＶ処理ブロック２３は、ＳＰＡ によるＣＳへのサービス提供に関して必要とされるＳＰＡとメッセージを交換し 、かつＳＰＡが要求されたサービスを実施するのに必要とするＣＳの呼処理およ び接続性の様態をそれぞれ制御するために、ＢＣＭ処理ブロック２２と基本呼処 理ブロック２１に制御プリミティブを通過させる場合、ＣＳの接続性の概観を保 つ責任がある。 ＢＣＭ処理ブロック２２は、ＳＰＡが進行を告知され、次の処理を促進する交 換に基づいた基本呼処理内の点を画定する基本呼モデル（ＢＣＭ）と呼ばれる呼 モデルに従ってその機能を実行する。 ＣＶ処理ブロック２３は、ＣＳのどの要素が可視であり、ＳＰＡにアクセス可 能であるかを画定する接続ビュー（ＣＶ）と呼ばれる呼モデル構成要素を使用し て、その機能を実行する。 基本呼モデル（ＢＣＭ） 基本呼モデルは、２者呼用のＳＳＰにおける基本呼処理をモデル化した状態遷 移図の形の表現である。重要と考えられる処理は、ＢＣＭの状態を構成する一連 のＰＩＣ（呼内の点）によって表される。各ＰＩＣは、所定の事象の発生に基づ いて励起される。２者呼に必要な基本処理に重要でないすべての処理特徴（交換 に基づいたサービスか、ＳＰＡ１２、１３から要求するサービスか）は、各ＰＩ Ｃからの出口のところにあるトリガ・チェック・ポイント（ＴＣＰ）において係 合する。そのような他の処理特徴は、特定のＴＣＰにおいて契合するかどうかは 、ＴＣＰにおいて指定されたトリガ基準で決まる。トリガ基準がＴＣＰにおいて 満足されない場合、処理は次のＰＩＣで行われる。トリガ基準が満足される場合 、ＳＰＡサービスが必要であれば、メッセージが関連する呼の詳細とともに関連 するＳＰＡに送られ、次いで要求されたサービスが提供される。ＳＰＡは、処理 が続くＢＣＭ内の点を制御でき、次のＰＩＣで処理を続けさせるか、または処理 を再開する他のＰＩＣを指定する。 ＢＣＭは、発信ＣＳに関連する処理をモデル化する発信ＢＣＭと、着信ＣＳに 関連する処理をモデル化する着信ＢＣＭとに分けられる。第５図および第６図は 、それぞれ発信ＢＣＭおよび着信ＢＣＭを示すが、どちらの場合も、これらのＢ ＣＭは、中間呼および例外事象を省略することにより簡単化されている。 第５図に示される発信ＢＣＭは、図に指名されたそれぞれ重要な呼処理段を表 す１０個のＰＩＣ１〜１０を含む。各ＰＩＣから励起させる事象Ｅも、第５図に 示されている。したがって、例えば、ＰＩＣ６は、呼の設定許可の段を表し、関 連する出口事象Ｅは、この付与される許可である。すなわち、励起されるＰＩＣ ６上の他のすべてのＰＩＣのように、トリガ基準が、関連するＴＣＰ内で試験さ れる。 第６図から、切断事象がどのＰＩＣにおいても検出されるのであれば、処理は ＴＣＰを介して空白状態ＰＩＣ１に戻ることが理解されよう。 第６図に示される着信ＢＣＭは、全体的な形状が第５図のＢＣＭと同じである が、それらの関連するＴＣＰを有する７個のＰＩＣ１１〜１７のみからなる。 もちろん、その接続性特徴（ＣＰ、脚）で表されるＣＳの状態は、対応するＢ ＣＭを通る進行とともに変化する。第７図は、（第７図の左側に簡略化した形で 示される）対応するＢＣＭを通る進行に関連する発信ＣＳおよび着信ＣＳ（第７ 図の右側）の接続性特徴の状態を示すことによってこの変化を示す。 ＣＳの呼の設定段階の間、ＣＳは、１つまたは両方の脚がない。ＣＳに両方の 脚が付けば、安定であると呼び、呼が切断されるまで安定なままである。もちろ ん、呼をＳＳＰにより十分に設定する場合は、発信ＣＳと着信ＣＳの両方がそれ らの安定段階にある必要がある。第７図から、発信ＣＳは、ＰＩＣ１〜６によっ て設定され、ＰＩＣ７〜１０によって安定になり、一方、着信ＣＳは、ＰＩＣ１ １〜１４によって設定され、ＰＩＣ１５〜１７によって安定となることが理解さ れよう。第７図は、発信ＢＣＭおよび着信ＢＣＭのＰＩＣ間の相対オフセットも 示す。 次に第８図のＴＣＰ処理フローチャートを参照して、ＴＣＰがＢＣＭ内で遭遇 する場合に起こることについて詳細に考察する。すでに述べたように、ＴＣＰに おいて、ＳＰＡ１２、１３にメッセージを送るべきか確認するためにトリガ基準 が検査される（ブロック３１）。これらのトリガ基準は、接触するＳＰＡに関す る情報、ＳＰＡに送るパラメータとともにＯＳ１７（第１図参照）によってＳＳ Ｐ１０内に設定され、関連するＣＳに関してＳＳＰ内で処理するかどうかは、Ｓ ＰＡからの応答を保留する必要がある。トリガ基準のブロック３１内の試験の結 果は、ブロック３２内で試験され、トリガが満足されなければ、処理は次のＰＩ Ｃにおいて再開する（ブロック３３参照）。ブロック３２の試験が、トリガは満 足されているが、処理を保留せずにＳＰＡに指定するように報告するだけである 場合は、これは、次のＰＩＣに進む前に、ブロック３４内で行われる。最後に、 ブロック３２の試験が、トリガが満足され、ＣＳ処理を保留し、指定されたＳＰ Ａに報告を行い、応答を受け取る場合、ＴＣＰ処理は、ＳＰＡに報告するために ブロック３５に進み、応答を受け取る。この後者の場合、ＳＰＡからの応答は、 ＳＳＰからの応答を必要とし（ブロック３６参照）、この場合、ブロック３５が 再加入する。そうでなければ、応答は進行し（ブロック３７）、シーケンス内の 次のＰＩＣと異なるＰＩＣへのジャンプが要求された場合（ブロック３８内で試 験される）、これはＴＣＰ処理の励起時にブロック３９内で行われる。 ブロック３５におけるその応答の部分として、ＳＰＡは、事象マスクを設定し て、ある特定の事象が、関連するＣＳの処理中に発生した場合、それを告知する ように尋問することができる。この場合、次のＴＣＰにおいて、この事象マスク は、（関連するＴＣＰのトリガ基準とともに）ブロック３１内で検査され、要求 された事象が発生していれば、適切な報告をＳＰＡに返す。トリガの場合のよう に、この報告は、ＣＳ処理の保留の有無に関わらず発生するように指定でき、そ れによりＴＣＰ処理ブロック３２〜３９は、トリガに関して要求された事象に均 等に適用される。 呼モデルによれば、ＢＣＭ処理は、ＳＰＡとの通信に直接影響を及ぼさないこ とが理解されよう。代わりに、前述のように、ＢＣＭ処理は、報告する事象をＣ Ｖ処理に伝達し、後者はＳＰＡと通信する。 接続ビュー（ＣＶ） すでに述べたように、ＣＶは、ＳＰＡ１２、１３にアクセス可能な基本呼処理 資源の表現を特定のＣＳに関して提供する。ＣＶ処理機能性（第４図、ブロック ２３）は、ＣＶを管理し、ＳＰＡが（ＢＣＭ処理によって）関連するＣＳならび にＣＳの接続性様態の基本呼処理を制御できるように、ＣＶによって示される資 源へのアクセスをＳＰＡに提供する。 ＣＶは、ＢＣＭオブジェクトによるＣＳに関連する基本呼処理資源、およびＣ Ｐによる接続性資源および脚オブジェクトを表すＣＶオブジェクトの集合の形を とる。ＣＶオブジェクトによって表される資源の状態は、いつでも、ＣＶコンテ クストを構成する。すなわち、第９図に示されるように、ＣＶコンテクスト４０ は、関連するＣＳの呼処理（ＢＣＭ）様態に関する構成要素（ＢＣＭコンテクス ト４１）およびＣＳの接続性様態に関する構成要素（接続性コンテクスト４２） を含む。 第９図は、ＣＶに関して実行されるＣＶ処理に関連する情報の流れも示す。具 体的には、呼処理事象は、ＢＣＭ処理２２か基本呼処理２１のどちらかから報告 され、制御プリミティブは、後でそれらの両方に通過する。さらに、メッセージ 「交換ＣＶ」がＳＰＡ１２、１３を通過し、メッセージ「ＳＰＡ ＣＶ」が戻っ てくる。 ＣＶ処理機能性によって実現されるＣＶの管理では、サービスがＳＰＡ１２、 １３から要求することを示す時にいつでも対応するＢＣＭからの事象報告が特定 のＣＳに関してＣＶを作成すること、必要な場合にＣＶコンテクストのコピーと ともに事象（トリガを含む）をＳＰＡに報告すること、ＳＳＰ内の呼処理事象か またはＳＰＡからのメッセージ「ＳＰＡ ＣＶ」に応答して呼処理資源を操作す る動作のどちらかのために、呼処理資源の状態の変化を反映するＣＶコンテクス トを更新すること、ＳＰＡに興味がなくなった場合ＣＶを除去することが行われ る。 安定したＣＶ報告 以下で説明するように、第１０図を参照して以下に述べるＳＰＡでは、呼処理 中に、それにサービスを提供するＣＳがいつその安定段階に達したかを知る必要 がある。前記の説明からこれがどのように達成されるかが明らかとなろう。 具体的には、ＢＣＭの処理中にサービスがＳＰＡから要求されることを示すト リガが検出されると、ＢＣＭは、これをＣＶ処理に報告し、その結果対応するＣ Ｖが発生し、メッセージ「交換ＣＶ」がＳＰＡに出力される。トリガは、応答が ＳＰＡから要求される形で１に指定される。メッセージ「ＳＰＡ ＣＶ」内に戻 されたＳＰＡ応答は、ＣＳをその安定段階に入れる事象（発信ＣＳの場合、これ は、「呼設定が許可された事象」）の発生を知っていることを尋問する事象マス クを含むようになされている。この事象マスクは、ＣＳ用のＢＣＭに送られる。 次いで、ＣＳがその安定段階に入ることを示す事象が発生した場合、関連するＴ ＣＰ処理がＳＰＡに報告させる。 サービス提供装置（ＳＰＡ） 第１０図は、第１図のＳＰＡ１２、１３に使用される本発明を実施するＳＰＡ の形態を示す。特定のサービスを提供するのに必要なハードウェアおよびソフト ウェアの実際の詳細は本発明とは関係がなく、したがってここでは説明しない。 重要なことは、ＳＰＡに使用される全体的な耐障害アーキテクチャである。 第１０図の実施例では、ＳＰＡは、一般に汎用プロセッサ（ローカル・メモリ を含む）の形をした、ＳＬＥＥ機能性を提供するためにオペレーティング・シス テム・ソフトウェアを動作する、第１のサービス論理５０、および１つまたは複 数のＳＬＰプログラムを含む。第１のサービス論理５０は、インタフェース５１ を介してＳＳＰと対話し、通常ＳＳＰにサービスを提供する形でＳＰＡの機能性 を提供する。 ＳＰＡはまた、第１のサービス論理５０とほぼ同じ機能性を有するが通常は動 作しない第２のサービス論理５２も含む。第２のサービス論理５２は、第１のサ ービス論理５０が故障した場合、後者のバックアップの役目をする。障害回復制 御機能ユニット５３は、第１のサービス論理５０を監視し、後者の故障を検出す ると、第２のサービス論理５２が動作し、それに応じてメッセージをＳＳＰから 論理５０にではなく論理５２に交換するようにインタフェース５１を制御する。 第２のサービス論理５２が、第１のサービス論理５０の故障時にそれによって 扱われるサービス要求の少なくとも一部に関して、サービスを提供し続けること が可能となるように、信頼できるバックアップ５５を備える。第１のサービス論 理５０は、ＣＳサービス要求に応答して、要求しているＣＳのＢＣＭ用の事象マ スクを設定するようになされており、その結果後者により、第１のサービス論理 ５０が、ＣＳが呼処理のその安定段階に入る時を知ることができる。第１のサー ビス論理５０に、それが現在サービスを提供しているＣＳがその安定段階に入っ たことが知らされると、サービス論理５０は、ＣＳサービス要求を処理するすベ ての関連状態データを確実な記憶装置５５に保管する。このデータは、関連ＣＶ コンテクスト・データ、およびサービス要求をサービスするように実行されるＳ ＬＰ処理に関するデータを含む。もちろん、ＣＳがサービスを要求する前にすで にその安定段階に達している場合は、サービス論理５０は、サービス要求に応答 した際に適切な状態データを記憶装置５５に保管する。 第１のサービス論理５０が通常動作を続けると仮定すると、ＣＳに関連する状 態データが変化した場合、状態データは、再び記憶装置５５に保管される（ある いは、変化のみが保管される）。サービス論理５０が要求されたＣＶへのサービ ス提供を完了すると、論理５０は、記憶装置５５内に保持される状態データを削 除する。 サービス要求が単一の中間応答のみを必要とする場合、状態データは、この要 求に関して記憶装置５５に送られない。 第１のサービス論理５０が故障し、第２のサービス論理５２が動作するとき、 それらの安定段階に達しているＣＳに提供されるサービスに関する状態データが 、第２のサービス論理にとって利用可能であり、第２のサービス論理がユーザに わかる方法で関連サービスを提供し続けることできる。単に記憶装置５５内に保 持されたすべての状態データをバックアップ・サービス論理５２に送るだけなら 可能であるが、これは、同時に行った場合かなりの時間を要する。したがって、 第２のサービス論理５２が現在のサービスに関してＳＳＰからメッセージを受け 取る際に、各ＣＳに関する状態データを変換することが好ましい。 確実な記憶装置５５は、例えば、耐障害データベースまたはディスク・ドライ ブである。この記憶装置５５は、一般にその内容を周期的に走査し、サービス要 求が流通している最大実効時間よりも長く設定された所定の期間よりも長い時間 存在したエントリを除去するようになされている。このようにして、記憶装置５ ５は、価値のないエントリで妨害されなくなる。 第２のサービス論理５２も故障した場合は、他のサービス論理が次々に動作で きるように、複数のバックアップ・サービス論理を提供できることが理解されよ う。多数のバックアップ・サービス論理が提供される場合、各論理（能動論理の 場合）は、論理５０について前述したように、安定なＣＳに関するデータを保管 する同じプロセスを実行する。 もちろん、第１０図のＳＰＡに各種の他の変形を行うことも可能である。例え ば、状態データが保管されたＣＳ呼処理内の点を、ＣＳをその安定段階に入れて 正確なＢＣＭ出口事象から変形できる。重要な点は、サービス提供動作のほとん どが呼の設定時に起こるので、ＣＳへのサービス提供に関連する状態データの保 管が、ＣＳ設定時に必要なサービス提供動作の大部分が完了した後でなければ開 始しない場合、すべてのサービス提供動作が記憶装置５５に保管を開始させる場 合よりも必要な保管動作はかなり少ない。 ＳＰＡが多数のサービスを提供する場合、サービス提供ＳＬＰは、ＣＳがその 安定段階に入る点またはその近くにおいて要求される。そのような場合、ＳＬＰ 自体を使用して、状態データの記憶装置５５への保管を開始するため、ＳＳＰか ら明確な事象報告を行う必要はない。したがって、対応するＢＣＭ事象マスクは 、ＣＳ呼処理が安定段階に入ったことを確認するために事象報告を要求するよう に設定する必要はない。実際、状態データの保管を開始するために、サービスが 特に事象の報告を要求しない方法を採用できる。代わりに、状態データの保管は 、サービスを引き受ける次に続く動作が、関連するＣＳがその安定段階に入るま で起こらないことが決定される場合はいつでも、特定のサービスに対して最初に 行われる。これは、次のサービス提供動作がＣＳがその安定段階に入るまで起こ らないような動作である場合、状態データがＣＳの設定段階において前もって保 管されることを意味する。 状態データの第１の保管がＳＳＰによって明確に促されるか、サービス提供の プロセス中にある場所に従ってＳＰＡによって決定されるかどうかに関わらず、 その影響により、ＣＳの設定時に必要なサービス提供動作のすべてまたはほとん どが完了するまで、状態データの保管を延期しなければならない。

【手続補正書】特許法第１８４条の８ 【提出日】１９９５年４月７日 【補正内容】 ４．該第１のサービス論理手段が、対応する呼セグメントがその安定段階に入る まで、次のサービス提供動作が必要とされないことを決定する場合、対応する呼 セグメントの設定時に必要なそのサービス提供動作の少なくとも大部分をほぼ完 了したことを決定することを特徴とする、請求の範囲第１項に記載のサービス提 供装置。 ５．第１のサービス論理手段による特定の呼セグメントに関する状態データの記 憶装置への第１の保管に従って、第１のサービス論理手段においてこの状態デー タが変化すると、バックアップ記憶装置内に保持された状態データが更新される ことを特徴とする、請求の範囲第１項に記載のサービス提供装置。 ６．該バックアップ記憶装置が、耐障害データベースであることを特徴とする、 請求の範囲第１項に記載のサービス提供装置。 ７．特定の呼セグメントに関する状態データが、該第２のサービス論理手段が該 交換局からの通信の結果としてそのような情報を必要とする場合、該第２のサー ビス論理手段に転送されるだけであることを特徴とする、請求の範囲第１項に記 載のサービス提供装置。 ８．１つまたは複数の呼のセッションが、そのようなセッションに関するセッシ ョン情報を該サービス提供手段内に保持し、かつ該バックアップ記憶装置に保管 して確立でき、対応するセッションに関連する現在の呼セグメントについての状 態データも第２のサービス論理手段に転送される場合にのみ、該セッション情報 が、第２のサービス論理手段が動作すると、バックアップ記憶装置から第２のサ ービス論理手段に転送されることを特徴とする、請求の範囲第１項に記載のサー ビス提供装置。 ９．それにより設定、保守および切断される呼セグメントに関して、呼処理サー ビスを通信網の交換局に提供するサービス提供装置において、

Claims (1)

1. 【特許請求の範囲】 １．それにより設定、保守および切断される呼セグメントに関して、呼処理サー ビスを通信網の交換局に提供するサービス提供装置において、 通常該サービスを交換局に提供する第１のサービス論理手段と、 該第１のサービス論理手段が故障した場合、該サービスを交換局に提供する第２ のサービス論理手段と、 該第１のサービス論理手段の故障に反応して、該第２のサービス論理手段を動作 させる障害回復手段と、 バックアップ記憶装置とを含み、 該第１のサービス論理手段が、現在サービスを提供している各呼セグメントにサ ービスが提供されると、第１のサービス論理手段によって保持される状態データ を該バックアップ記憶装置に保管し、この状態データの保管が、第１のサービス 論理手段が対応する呼セグメントの設定時に必要なそのサービス提供動作の少な くとも大部分をほぼ完了したことを決定した直後に、該呼セグメントに関して実 現され、該第２のサービス論理手段が動作すると、現在の呼セグメントにサービ スを提供し続けるのに必要な状態データを該バックアップ記憶装置から検索する ことを特徴とするサービス提供装置。 ２．呼セグメントの設定プロセスの少なくとも大部分が完了したことを交換局に よって通知された場合、第１のサービス論理手段が、対応する呼セグメントの設 定時に必要なそのサービス提供動作の少なくとも大部分をほぼ完了したことを決 定することを特徴とする、請求の範囲第１項に記載のサービス提供装置。 ３．サービス論理手段による特定の呼セグメントへのサービス提供の進行がその ように示す場合、第１のサービス論理手段が、対応する呼セグメントの設定時に 必要なそのサービス提供動作の少なくとも大部分をほぼ完了したことを決定する ことを特徴とする、請求の範囲第１項に記載のサービス提供装置。 ４．該第１のサービス論理手段が、対応する呼セグメントがその安定段階に入る まで、次のサービス提供動作が必要とされないことを決定する場合、対応する呼 セグメントの設定時に必要なそのサービス提供動作の少なくとも大部分をほぼ完 了したことを決定することを特徴とする、請求の範囲第１項に記載のサービス提 供装置。 ５．第１のサービス論理手段による特定の呼セグメントに関する状態データの記 憶装置への第１の保管に従って、第１のサービス論理手段においてこの状態デー タが変化すると、バックアップ記憶装置内に保持された状態データが更新される ことを特徴とする、請求の範囲第１項に記載のサービス提供装置。 ６．該バックアップ記憶装置が、耐障害データベースであることを特徴とする、 請求の範囲第１項に記載の通信網。 ７．特定の呼セグメントに関する状態データが、該第２のサービス論理手段が該 交換局からの通信の結果としてそのような情報を必要とする場合、該第２のサー ビス論理手段に転送されるだけであることを特徴とする、請求の範囲第１項に記 載の通信網。 ８．１つまたは複数の呼のセッションが、そのようなセッションに関するセッシ ョン情報を該サービス提供手段内に保持し、かつ該バックアップ記憶装置に保管 して確立でき、対応するセッションに関連する現在の呼セグメントについての状 態データも第２のサービス論理手段に転送される場合にのみ、該セッション情報 が、第２のサービス論理手段が動作すると、バックアップ記憶装置から第２のサ ービス論理手段に転送されることを特徴とする、請求の範囲第１項に記載の通信 網。 ９．それにより設定、保守および切断される呼セグメントに関して、呼処理サー ビスを通信網の交換局に提供するサービス提供装置において、 通常該サービスを交換局に提供する第１のサービス論理手段と、 該第１のサービス論理手段が故障した場合、該サービスを交換局に提供する第２ のサービス論理手段と、 該第１のサービス論理手段の故障に反応して、該第２のサービス論理手段を動作 させる障害回復手段と、 バックアップ記憶装置とを含み、 該第１のサービス論理手段が、現在サービスを提供している各呼セグメントにサ ービスが提供されると、第１のサービス論理手段によって保持される状態データ を該バックアップ記憶装置に保管し、この状態データの保管が、該呼セグメント の設定プロセスの少なくとも大部分が完了した直後に、該呼セグメントに関して 実現され、該第２のサービス論理手段が動作すると、現在の呼セグメントにサー ビスを提供し続けるのに必要な状態データを該バックアップ記憶装置から検索す ることを特徴とするサービス提供装置。 １０．呼の設定、保守および切断を行う基本呼処理を実現する交換機と、該基本 呼処理に追加のサービスを提供する該交換機と通信する手段とを含む通信網にお いて、該交換機が、該呼を少なくとも１つの呼部分からなるものとして扱い、該 交換機がそのような各呼部分の設定、保守および切断を行い、交換機とサービス 提供手段とを接続し、それにより交換機が特定の呼部分に関してそこからサービ ス提供を要求し、その呼部分の設定、保守および切断のプロセスによってサービ ス提供手段に経過を報告できるようになり、かつ該サービス提供手段が、サービ ス提供手段によって提供されているサービスに従ってそのプロセスを促進できる ようになるインタフェース手段を含み、 対応する呼部分の設定が少なくともほぼ完了した時にサービス提供手段に報告し 、該サービス提供手段が、通常該サービスを交換機に提供する第１のサービス論 理手段と、該第１のサービス論理手段が故障した場合、該サービスを交換機に提 供する第２のサービス論理手段と、該第１のサービス論理手段の故障に反応して 、該第２のサービス論理手段を動作させる障害回復手段と、バックアップ記憶装 置とを含み、該第１のサービス論理手段が、第１のサービス論理手段によって保 持 される現在サービスを提供している各呼部分に関する呼部分関連データを該バッ クアップ記憶装置に保管し、このバックアップが、交換機の該インタフェース手 段がその呼部分の設定が少なくともほぼ完了したことを報告した直後に、該呼部 分に関して実現され、かつ該第２のサービス論理手段が、動作すると、現在の呼 部分に要求されたサービスを提供し続けるのに必要な該呼部分関連データを該バ ックアップ記憶装置から提供されることを特徴とする通信網。