JP3936172B2 - 交換システム - Google Patents

Description

【０００１】
【発明の属する技術分野】
本発明は、例えば、ＭＨＮ−Ｓ（Multimedia Handling Node-STM(Synchronous Transfer Mode)）を用いた交換システムに関し、更に詳細には、ＶｏＩＰ（Voice Over IP）呼処理制御機能部において、ＶｏＩＰ加入者への既存呼処理制御機能部の提供サービス実現にあたり、既存呼処理制御機能部上で管理されていたサービス契約情報（以下、加入者データと呼ぶ）を、ＶｏＩＰ呼処理制御機能部上に分散管理させ、既存呼処理制御機能部を用いてサービスを実現させるようにした交換システムに関するものである。
【０００２】
【従来の技術】
既存呼処理制御モデルにおける加入者データは次のように定義されている。
図２は、既存加入者データのモデル構成図である。
【０００３】
既存呼処理制御モデルでは、データ分散配備のため、サービス実現クラス（以降、シナリオと呼ぶ）にてデータ管理クラスを意識して加入者データの参照・設定を実現している。即ち、シナリオが、サービス用加入者データクラスと、これのリンク関係を保持しているリソース用加入者データクラスとを用いてサービスを提供している。また、サービス用加入者データクラスで、サービス用加入者クラスポインタとサービス契約情報（加入者データ）とを管理し、更に、リソース用加入者データクラスでリソース用加入者クラスポインタと加入者データとを管理している。
【０００４】
既存呼処理制御モデルにおいて、加入者データは常駐クラス（図２中のバックアップ領域）として存在するが、ＶｏＩＰ呼処理制御モデルにおいては、呼毎のダイナミックなクラスであり、非常駐クラスとなる。即ち、既存呼処理制御モデルでは、加入者データはその加入者を収容する局に固定的に設けられているが、ＶｏＩＰ呼処理制御モデルでは、加入者データを呼毎に生成／解放するからである。
【０００５】
【発明が解決しようとする課題】
このような既存呼処理制御モデルを用いてＶｏＩＰ呼処理制御モデルのサービスを実現しようとした場合、次のような課題が存在していた。
●ＶｏＩＰ呼処理制御側では、加入者データが他のモジュールで管理されているため、再開時（交換機のリセット時）に初期設定を必要とするが、既存呼処理制御側では再開時に初期設定を必要としないデータとなる。即ち、ＶｏＩＰ呼処理制御側では、再開時に加入者データをクリアする必要があるのに対し、既存呼処理制御側では加入者データをクリアする必要がない。従って、このようなデータ属性の違いを隠蔽する必要があった。
【０００６】
●ＶｏＩＰ呼処理制御モデルでは、ＶｏＩＰ加入者データは非常駐のクラスであるため、呼毎に生成／解放が必要となる。
【０００７】
●ＶｏＩＰ呼処理制御モデルに配備されたデータを直接既存呼処理制御モデルにて参照・設定しようとした場合、既存呼処理制御モデル側では、どちらに配備されている加入者データであるかが分からない。
【０００８】
●ＶｏＩＰ呼処理制御モデルと既存呼処理制御モデルの双方で加入者データを配備すると二重に配備することになり、メモリ使用量が増加してしまう。
【０００９】
【課題を解決するための手段】
本発明は、前述の課題を解決するため次の構成を採用する。
〈構成１〉
バックアップ領域に保持されているデータと、発呼要求を受けてサービス実現クラスからアクセス要求があるとバックアップ領域を参照してデータに基づいて加入者データを設定する加入者クラスとを有し、サービス実現クラスが設定された加入者データを利用してサービスを提供する既存呼処理制御機能部と、ＶｏＩＰ加入者の加入者データを設定するためのキャッシュ情報が格納されているデータ保持部を有するＶｏＩＰ呼処理制御機能部とを備える交換システムにおいて、既存呼処理制御機能部は、ＶｏＩＰ加入者からの発呼要求を受けるとその加入者データの作成要求を行うアダプタ部と、作成要求を受けるとデータ保持部の加入者データを得るためのデータのエリアを示すポインタを取得して該ポインタに基づいてサービス実現クラスに供給するための加入者データを設定するＶＬＲクラスを生成するＶＬＲクラス作成部と、を含み、ＶＬＲクラスは呼の解放要求を受けるとＶｏＩＰ呼処理制御機能部にデータ保持部に対するキャッシュ情報の解放指示を行うことを特徴とする交換システム。
【００１１】
【発明の実施の形態】
以下、本発明の実施の形態を具体例を用いて詳細に説明する。
《具体例》
〈構成〉
図１は、本発明の交換システムの具体例を示す構成図である。
図示の交換システムは、特定の呼処理制御機能部である既存呼処理制御機能部（既存呼処理制御モデル）１ａと、他の呼処理制御機能部であるＶｏＩＰ呼処理制御機能部（ＶｏＩＰ呼処理制御モデル）１ｂのクラス構成を示している。
【００１２】
既存呼処理制御機能部１ａでは、呼制御管理部（コール制御クラス）２、シナリオ（サービス実現クラス）３、ＶＬＲクラス作成部（ＶＬＲ−ＳＯＤ：visitor location register-subscriber order）４、加入者クラス（Ａ加入者クラス，Ｂ加入者クラス）５ａ，５ｂ、ＶＬＲクラス（Ａ−ＶＬＲクラス，Ｂ−ＶＬＲクラス）６ａ，６ｂ、初期設定機能部（初期設定代表クラス）７が存在する。また、ＶｏＩＰ呼処理制御機能部１ｂでは、インタフェースルーチン機能部（Subscriber）９、データ保持部（キャッシュ）１０が存在する。更に、これら双方のインターワークを提供するアダプタ部（ＡＤＰ（adapter）クラス）８が存在する。
【００１３】
呼制御管理部２は、呼毎に生成され、呼処理に関する種々の動作を統轄するクラスであり、既存呼処理制御機能部１ａにおける種々の呼処理制御を行うと共に、ＶｏＩＰ呼処理制御機能部１ｂに属する加入者の呼に対して解放要求があった場合にその呼に対応した生成されたＶＬＲクラス６の解放を行う機能を有している。シナリオ３は、従来と同様に既存呼処理制御機能部１ａにおいて、各種のサービスを提供するためのクラスである。ＶＬＲ作成部４は、ＶｏＩＰ呼処理制御機能部１ｂに属する加入者からの発呼があった場合に、アダプタ部８からの指示を受けて、その加入者に対応したＶＬＲクラス６を生成するクラスである。
【００１４】
加入者クラス５は、加入者データを定義しているクラスであり、機能（プログラム）とデータとからなり、加入者データの参照・設定機能を備えている。また、ＶＬＲクラス６は、加入者クラス５を継承しているクラスであり、仮想関数を用いることにより、シナリオ３は、加入者クラス５に代わってＶＬＲクラス６にアクセスできるよう構成されている。
【００１５】
図３は、加入者クラスとＶＬＲクラスの継承関係の説明図である。
図示のように、加入者クラス５は、データ配備領域におけるバックアップ領域の各データ（加入者データ、クラス間リンク情報、既存呼制御用論理データ）の参照・設定を行う機能を有し、ＶＬＲクラス６は、非バックアップ領域における各データの参照・設定を行う機能を有している。
【００１６】
ＶＬＲクラス６は、ＶｏＩＰ呼処理制御機能部１ｂ側のデータ保持部１０のオブジェクトＩＤ、既存呼処理で加入者データ設定時に生成されるデータを配備する。尚、ここで、既存呼処理で生成されるデータとは、既存呼処理制御機能部１ａに対応したクラス構成でＶＬＲクラス６を生成するためのＶＬＲクラス６でのクラス間リンク情報および加入者データから生成される論理的なデータであり、一時的なデータ（非バックアップデータ）として保持することで問題のないデータである。
【００１７】
また、ＶＬＲクラス６は、加入者クラス５で定義された関数のみ継承し、データの配備場所となるエリアの継承は行わない。即ち、ＶＬＲクラス６は、既存呼処理制御機能部１ａ側で保持している契約者情報（加入者データ）は保持せず、データ保持部１０のポインタを保持するよう構成され、このポインタ情報を元にデータ保持部１０のデータを参照・設定する機能を提供するものである。これにより、ＶＬＲクラス６にアクセスがあった場合、ＶＬＲクラス６は、ＶｏＩＰ呼処理制御機能部１ｂのデータ保持クラスであるデータ保持部１０に対してアクセスを行う。
【００１８】
初期設定機能部７は、交換システムの再開時（リセット時）に初期設定を行うためのクラスであり、初期設定時はＶＬＲクラス６のクリア処理を実施する機能を有している。
【００１９】
アダプタ部８は、既存呼処理制御機能部１ａとＶｏＩＰ呼処理制御機能部１ｂとのインターワークを提供するクラスであり、また、呼毎に生成／解放するＶＬＲクラス６の生成契機を判断し、これをＶＬＲ作成部４に伝える機能を有している。
【００２０】
インタフェースルーチン機能部９は、アダプタ部８を介してＶｏＩＰ呼処理制御機能部１ｂ側にアクセスがあった場合に、データ保持部１０からの情報収集やデータ保持部１０への解放指示あるいはデータベース設定指示といった制御を行うクラスである。また、データ保持部１０は、図示省略した他のデータベースに保持されている加入者データ等のデータを保持するためのキャッシュである。
【００２１】
〈動作〉
次に、本具体例の動作について説明する。
図４は、ＶｏＩＰ呼処理制御機能部１ｂに属する加入者発信におけるＶＬＲクラス６作成までのシーケンスを示す説明図である。
ＶｏＩＰ加入者において、既存呼制御サービス提供時は、アダプタ部８を経由して呼制御信号が通知される。ここで、アダプタ部８においてＶｏＩＰ加入者という識別を行うことで、ＶＬＲ作成契機が判断できる（ステップＳ１）。アダプタ部８において、ＶＬＲを作成すべきと判断した場合、アダプタ部８はＶＬＲ作成部４にＶＬＲ作成要求を行う（ステップＳ２）。
【００２２】
ＶＬＲ作成部４では、要求に対し、先ずアダプタ部８を介してインタフェースルーチン機能部９にキャッシュ情報収集要求を行う（ステップＳ３）。これによりインタフェースルーチン機能部９は、データ保持部１０を参照してデータ収集を行う（ステップＳ４）。ここで、データ保持部１０にデータを収集済みの場合は、対象エリアのポインタをＶＬＲ作成部４に返送し、未収集の場合は、他モジュールから収集を行い、収集先ポインタをＶＬＲ作成部４に返送する（ステップＳ５）。
【００２３】
キャッシュ情報を収集したＶＬＲ作成部４は、対象となる加入者のＶＬＲクラス６を生成する（ステップＳ６）。そして、収集したキャッシュ情報のキャッシュポインタをＶＬＲクラス６に送る（ステップＳ７）。それ以降の処理は既存呼制御処理であり、その発呼に対応した呼制御管理部２の生成を行い、この呼制御管理部２に対して発呼要求を行う。
【００２４】
次に、呼制御管理部２がＶＬＲクラス６のキャッシュデータを参照・設定する動作を説明する。
図５は、キャッシュデータ参照・設定のシーケンスを示す説明図である。
シナリオ３は、呼制御管理部２に対して加入者クラス５のオブジェクトＩＤ収集要求を行い（ステップＳ１１）、加入者クラス５のデータ参照を行う（ステップＳ１２）。ここで、シナリオ３は加入者クラス５の型で関数呼び出しを行うが、加入者クラス５とＶＬＲクラス６は継承関係にあり、仮想関数定義を行うことによりＶＬＲクラス６が呼び出される。
【００２５】
ＶＬＲクラス６では、シナリオ３に対して要求されたデータを返送するが、データ保持部１０に存在しないデータ（ＶｏＩＰ呼処理制御機能部１ｂ側では使用しないデータ）である場合は、予め決められたデフォルト値を返却する（ステップＳ１３）。また、データ保持部１０に存在するデータの場合はアダプタ部８を介してインタフェースルーチン機能部９に加入者データ収集要求を行い（ステップＳ１４）、インタフェースルーチン機能部９は、そのデータをＶＬＲクラス６に返送する。
【００２６】
次に、シナリオ３が加入者データを設定する場合、上記の加入者データの参照時と同様に、加入者クラス５の型で関数呼び出しを行う（ステップＳ１５）が、加入者クラス５とＶＬＲクラス６とは継承関係にあり、仮想関数定義を行うことによりＶＬＲクラス６が呼び出される。ＶＬＲクラス６では、設定されるデータがデータ保持部１０に存在するデータであるかを判断し、データ保持部１０に存在するデータである場合は、アダプタ部８を介してインタフェースルーチン機能部９に加入者データ設定を行う（ステップＳ１６、Ｓ１７）。これを受けたインタフェースルーチン機能部９は、この加入者データでデータベース（ＤＢ）を更新するようデータ保持部１０に設定指示を行う（ステップＳ１８）。一方、ＶＬＲクラス６にてデータ保持部１０に存在するデータかどうかを判断した結果、ＶｏＩＰ呼処理制御機能部１ｂ側で使用しないデータであった場合は何もしない。
【００２７】
このように、ＶＬＲクラス６については既存の加入者クラス５を継承していることにより、シナリオ３は、既存呼処理制御機能部１ａ側の加入者データかＶＬＲの加入者データかを意識することなく参照・設定処理が可能となる。
【００２８】
尚、上記ステップＳ１３において、ＶｏＩＰ呼処理制御機能部１ｂ側に存在しないデータであった場合、ＶＬＲクラス６はデフォルト値を返却するようにしたが、このような値もデフォルト値としてデータ保持部１０で保持するようにし、これをＶＬＲクラス６に返却するよう構成してもよい。
【００２９】
次に、ＶＬＲの解放時の動作を説明する。
図６は、ＶＬＲ解放時のシーケンスを示す説明図である。
呼制御管理部２に対して呼の解放要求がなされる（ステップＳ２１）と、呼制御管理部２は、ＶＬＲクラス６に対して解放要求を送出する（ステップＳ２２）。尚、この制御が従来と異なる点である。これにより、ＶＬＲクラス６はアダプタ部８を介してインタフェースルーチン機能部９にキャッシュ情報の解放指示を行い（ステップＳ２３）、これを受けたインタフェースルーチン機能部９はデータ保持部１０に対してキャッシュ情報の解放指示を行う（ステップＳ２４）。
このような動作により、アダプタ部８から生成される呼制御管理部２が解放されるのとリンクして呼毎に解放することが可能となる。
【００３０】
次に、呼制御動作中の初期設定動作について説明する。
図７は、再開時の初期設定シーケンスの説明図である。
交換システムにおいて、ソフトウェアに起因する障害等の発生により、呼制御の動作中で、一旦システムリセットを行う場合がある。このような場合は、非常駐であるＶＬＲクラス６はクリアする必要がある。
【００３１】
初期設定機能部７で、図示しないリセット通知部から再開通知を受け取る（ステップＳ３１）と、初期設定機能部７は加入者クラス５およびＶＬＲクラス６に対して再開通知を送出する（ステップＳ３２、Ｓ３３）。ここで、加入者クラス５は常駐のクラスであるため、クリア処理は実施しない（ステップＳ３４）。一方、ＶＬＲクラス６に対しては、非常駐のクラスであるため、そのクリアを実施する（ステップＳ３５）。
このような動作により、再開時においてもデータ属性の違いを隠蔽することができる。
【００３２】
〈効果〉
以上のように、具体例によれば、加入者データが分散管理されているＶｏＩＰ加入者に対し、加入者データがモジュール内で管理されている既存呼処理制御機能を利用してサービスの実現が可能となる。しかも、既存呼処理制御機能への変更箇所はコール制御のみであるため、ソフトウェア変更に伴うコスト上昇を最小限に抑えることができる。更に、データの二重配備は行わないためメモリエリアの有効利用が図れ、機能実現のためのコスト上昇も抑えることができる。
【００３３】
《利用形態》
上記具体例では、他の呼処理制御機能部としてＶｏＩＰ呼処理制御モデルの例を説明したが、これ以外の呼処理制御機能であっても同様に適用可能である。また、対象となるデータも上記具体例では加入者データとしたが、加入者データに限らず、他の呼処理制御機能との共有データがあれば、そのデータに対して同様に適用することができる。
【図面の簡単な説明】
【図１】本発明の交換システムの具体例を示す構成図である。
【図２】既存加入者データのモデル構成図である。
【図３】加入者クラスとＶＬＲクラスの継承関係の説明図である。
【図４】ＶｏＩＰ呼制御モデルの加入者発信におけるＶＬＲクラス作成までのシーケンスを示す説明図である。
【図５】キャッシュデータ参照・設定のシーケンスを示す説明図である。
【図６】ＶＬＲ解放時のシーケンスを示す説明図である。
【図７】再開時の初期設定シーケンスの説明図である。
【符号の説明】
１ａ 既存呼処理制御機能部（特定の呼処理制御機能部）
１ｂ ＶｏＩＰ呼処理制御機能部（他の呼処理制御機能部）
２ 呼制御管理部（コール制御クラス）
３ シナリオ（サービス実現クラス）
４ ＶＬＲ作成部（ＶＬＲ−ＳＯＤ）
５ａ，５ｂ 加入者クラス
６ａ，６ｂ ＶＬＲクラス
７ 初期設定機能部
１０ データ保持部

Claims (1)

1. バックアップ領域に保持されているデータと、発呼要求を受けてサービス実現クラスからアクセス要求があると前記バックアップ領域を参照して前記データに基づいて加入者データを設定する加入者クラスとを有し、前記サービス実現クラスが前記設定された加入者データを利用してサービスを提供する既存呼処理制御機能部と、
   ＶｏＩＰ加入者の加入者データを設定するためのキャッシュ情報が格納されているデータ保持部を有するＶｏＩＰ呼処理制御機能部とを備える交換システムにおいて、
   前記既存呼処理制御機能部は、
   前記ＶｏＩＰ加入者からの発呼要求を受けるとその加入者データの作成要求を行うアダプタ部と、
   前記作成要求を受けると前記データ保持部の加入者データを得るためのデータのエリアを示すポインタを取得して該ポインタに基づいて前記サービス実現クラスに供給するための加入者データを設定するＶＬＲクラスを生成するＶＬＲクラス作成部と、を含み、
   前記ＶＬＲクラスは呼の解放要求を受けると前記ＶｏＩＰ呼処理制御機能部に前記データ保持部に対するキャッシュ情報の解放指示を行う、
   ことを特徴とする交換システム。

Images