スロットインターフェースアクセス装置、その方法及びそのプログラム並びに主装置の冗長構成及び代替方法
【課題】単一の主装置が、ネットワークにつながる全ての主装置のハードウェアのリソース等の情報を一元管理する。
【解決手段】入出力制御モジュールとその下位のスロットインターフェースとの間に、スロット管理モジュール、スロット制御モジュール及び物理スロット／管理スロット対照表を備え、入出力制御モジュールは、仮想スロット識別情報を用いてスロットインターフェースにアクセスし、スロット管理モジュールが、物理スロット／管理スロット対照表を参照して、仮想スロット識別情報を物理スロット識別情報に変換し、変換により得られた物理スロット識別情報に対応するスロット制御モジュールにアクセスすることにより、入出力制御モジュールによるスロットインターフェースへの物理的なアクセスが実現される。
【解決手段】入出力制御モジュールとその下位のスロットインターフェースとの間に、スロット管理モジュール、スロット制御モジュール及び物理スロット／管理スロット対照表を備え、入出力制御モジュールは、仮想スロット識別情報を用いてスロットインターフェースにアクセスし、スロット管理モジュールが、物理スロット／管理スロット対照表を参照して、仮想スロット識別情報を物理スロット識別情報に変換し、変換により得られた物理スロット識別情報に対応するスロット制御モジュールにアクセスすることにより、入出力制御モジュールによるスロットインターフェースへの物理的なアクセスが実現される。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数の主装置に分散して存在するスロットインターフェースにアクセスするためのスロットインターフェースアクセス装置、その方法及びそのプログラムに関する。
【０００２】
また、本発明は、主装置を複数設置し、マスターとなる主装置が機能不全となった場合に、他の主装置が代替のマスター主装置となる主装置の冗長構成及び主装置の代替方法に関する。
【背景技術】
【０００３】
従来より、主装置間をネットワークでつなぎ、主装置間で相互に相手の機能を利用する技術はあった。ここで、主装置とは、端末（ボタン電話など）を収容するインターフェースを備えたり、公衆回線と接続するためのインターフェースを備えたり、ＩＰネットワークと接続するためのインターフェースを備えたりする装置のことである。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】国際公開第１９９７／３５２５５号パンフレット
【特許文献２】特開２００１−３５８７３６号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかし、主装置の機能をネットワークを介して他の主装置で利用できるようにするためには、各機能を改造する必要があった。そのため、改造されていない機能はネットワークに対応しておらず、ある主装置の全ての機能をネットワーク経由で他の主装置が利用するということができなかった。
【０００６】
すなわち、従来、主装置間のネットワーキングによる接続は、各主装置がそれぞれのＣＰＵでリソースを管理し、端末、回線等の状態も別々に管理していたため、ネットワーク間で主装置の機能を動かすためには、単一の主装置で機能を動かすようには簡単にはいかず、ネットワークに対応するよう機能の作り変えが必要であった。
【０００７】
また、従来のネットワーキングシステムにおいては、主装置のリソースであるパッケージのスロットは、各システムごとに別々に管理されており、そのため、個々のシステムは互いに相手のリソースの情報、状態等を知ることができず、そのため、ネットワーク上で主装置の機能を利用する際、制限が生じていた。
【０００８】
そこで、本発明は、単一の主装置が、ネットワークにつながる全ての主装置のハードウェアのリソース等の情報を一元管理することにより、情報の管理を容易にし、機能制限のないネットワーキングを構築することを目的とする。
【課題を解決するための手段】
【０００９】
本発明では、従来、各々の主装置が管理していた全てのリソース情報を一台の主装置が一元管理し、また、呼制御も一台の主装置が一括して行うことで、従来の問題を回避する。
【００１０】
すなわち、ネットワークに接続されている他の主装置の端末、回線等の監視、制御を全て一台の主装置が一括して行うことで、ネットワーク上のリソースをあたかも自分の主装置に接続されているかのように扱うことができる。
【００１１】
つまり、他のシステムの端末、回線を、自分の端末、回線のように扱うことができるため、従来のように主装置の機能をネットワーク対応に改造する必要はなく、特にネットワークを意識する必要すらなくなる。
【００１２】
そして、現在ネットワーク対応していない機能を含め、全ての機能をネットワークで利用可能となる。
【００１３】
また、本発明では、一台の主装置が、ネットワークに接続する全ての主装置のスロットを一元管理することにより上記の問題を回避する。
【００１４】
すなわち、ネットワーク上で全ての呼処理を制御するマスター主装置が、自らのスロットと、自らに接続するスレーブ主装置のスロットを一元管理し、他システムのスロットであっても、あたかも自システムのスロットであるかのように扱う。
【００１５】
こうすることで、ネットワーク上のスロットの全情報をマスターが管理できることになり、同時に、スロットにインストールされたパッケージに接続する端末、回線など全てのリソースも、自システムのものであるかのように扱うことができるようになる。
【００１６】
本発明によれば、入出力制御モジュールとその下位のスロットインターフェースとの間に、スロット管理モジュール、スロット制御モジュール及び物理スロット／管理スロット対照表を備え、前記入出力制御モジュールは、仮想スロット識別情報を用いて前記スロットインターフェースにアクセスし、前記スロット管理モジュールが、前記物理スロット／管理スロット対照表を参照して、仮想スロット識別情報を物理スロット識別情報に変換し、変換により得られた物理スロット識別情報に対応するスロット制御モジュールにアクセスすることにより、前記入出力制御モジュールによる前記スロットインターフェースへの物理的なアクセスが実現されることを特徴とするスロットインターフェースアクセス装置が提供される。
【００１７】
また、本発明によれば、入出力制御モジュールとその下位のスロットインターフェースとの間に、スロット管理モジュール、スロット制御モジュール及び物理スロット／管理スロット対照表を設け、前記入出力制御モジュールは、仮想スロット識別情報を用いて前記スロットインターフェースにアクセスし、前記スロット管理モジュールが、前記物理スロット／管理スロット対照表を参照して、仮想スロット識別情報を物理スロット識別情報に変換し、変換により得られた物理スロット識別情報に対応するスロット制御モジュールにアクセスすることにより、前記入出力制御モジュールによる前記スロットインターフェースへの物理的なアクセスが実現されることを特徴とするスロットインターフェースアクセス方法が提供される。
【００１８】
更に、本発明によれば、複数の主装置を備え、そのうち１つの主装置がマスター主装置であり、他の主装置がスレーブ主装置であり、前記マスター主装置が機能不全となった場合、前記スレーブ主装置のうちの１つのスレーブ主装置が新たなマスター主装置となることを特徴とする主装置の冗長構成が提供される。
【００１９】
更に、本発明によれば、上記の主装置の冗長構成において、前記新たなマスター主装置は、機能不全となったマスター主装置が回復したか否かを監視し、機能不全となったマスター主装置が回復した時に、新たなマスター主装置は、回復したマスター主装置にシステム全体の制御権を戻すことを特徴とする主装置の冗長構成が提供される。
【００２０】
更に、本発明によれば、複数の主装置を備え、そのうち１つの主装置がマスター主装置であり、他の主装置がスレーブ主装置であり、前記マスター主装置が機能不全となった場合、前記スレーブ主装置のうちの１つのスレーブ主装置が新たなマスター主装置となることを特徴とする主装置の代替方法が提供される。
【００２１】
更に、本発明によれば、上記の主装置の代替方法において、前記新たなマスター主装置は、機能不全となったマスター主装置が回復したか否かを監視し、機能不全となったマスター主装置が回復した時に、新たなマスター主装置は、回復したマスター主装置にシステム全体の制御権を戻すことを特徴とする主装置の代替方法が提供される。
【００２２】
更に、本発明によれば、入出力制御モジュールとその下位のスロットインターフェースとの間に、スロット管理モジュール、スロット制御モジュール及び物理スロット／管理スロット対照表を備え、前記入出力制御モジュールは、仮想スロット識別情報を用いて前記スロットインターフェースにアクセスし、前記スロット管理モジュールが、前記物理スロット／管理スロット対照表を参照して、仮想スロット識別情報を物理スロット識別情報に変換し、変換により得られた物理スロット識別情報に対応するスロット制御モジュールにアクセスすることにより、前記入出力制御モジュールによる前記スロットインターフェースへの物理的なアクセスが実現されることを特徴とするスロットインターフェースアクセス装置であって、当該装置は、スロットインターフェースを有する他の装置よりもＣＰＵ能力が高いことを特徴とするスロットインターフェースアクセス装置が提供される。
【００２３】
更に、本発明によれば、入出力制御モジュールとその下位のスロットインターフェースとの間に、スロット管理モジュール、スロット制御モジュール及び物理スロット／管理スロット対照表を備え、前記入出力制御モジュールは、仮想スロット識別情報を用いて前記スロットインターフェースにアクセスし、前記スロット管理モジュールが、前記物理スロット／管理スロット対照表を参照して、仮想スロット識別情報を物理スロット識別情報に変換し、変換により得られた物理スロット識別情報に対応するスロット制御モジュールにアクセスすることにより、前記入出力制御モジュールによる前記スロットインターフェースへの物理的なアクセスが実現されることを特徴とするスロットインターフェースアクセス方法であって、当該方法は、スロットインターフェースを有する他の装置よりもＣＰＵ能力が高い装置により行われることを特徴とするスロットインターフェースアクセス方法が提供される。
【発明の効果】
【００２４】
本発明によれば、主装置の持つ、理論上全ての機能をネットワーク上で利用できるようになる。既存の技術では、各主装置が基本的に独立で動いており、それらを協調して動かすためには、一つ一つの機能に関して、特別な変更が必要であった。しかし、本発明によって、下位のレイヤーでネットワーク間の違いを吸収する仕組みを導入することで、上位レイヤーの機能は、ネットワーク間を意識することなく、機能を動かすことができるようになる。
【００２５】
また、本発明を利用することにより、信頼性の高いネットワーキングを構築できる。従来の方式では、それぞれの主装置が独立で動いており、リソースも別々に管理していた。そのため、タイミングによって、リソース間の状態等に矛盾が生じるといった問題が生じえた。本発明では、この問題も解消できる。
【００２６】
更に、本発明では、主装置の機能の最も下位のレイヤーで機能を構築するため、下位のレイヤーさえ問題なく作りこめば、上位のレイヤーで機能不具合が生じることはないし、リソースの集中管理をすることで、リソース間の状態等に矛盾が生じることもない。
【００２７】
更に、本発明を利用することで、ネットワーキングでありながら、それを意識させない仕組みを構築することが可能となる。
【００２８】
更に、処理の最も低いレイヤーでネットワークによる違いを吸収する仕組みを導入することで上位のアプリケーションは、ネットワークを意識することなく、機能を利用可能となる。
【００２９】
そのため、従来、アプリケーションレベルで必要であったネットワーク対応の処理がまったく必要なくなり、ネットワーク対応工数を大幅に削減できるだけでなく、品質も向上させることができる。
【００３０】
これによって、従来ネットワーク対応に機能改造するためにかかっていた膨大な工数をゼロにでき、また、品質も向上させることができる。
【図面の簡単な説明】
【００３１】
【図１】本発明の実施形態による、仮想パッケージを用いて、他の主装置の実パッケージを自主装置の実パッケージとして扱う様子を示す図である。
【図２】本発明の実施形態によるマスター主装置とスレーブ主装置の接続例を示す図である。
【図３】本発明の実施形態によるマスター主装置とスレーブ主装置の他の接続例を示す図である。
【図４】本発明の実施形態による仮想スロットと物理スロットとの対応関係を示す図である。
【図５】本発明の実施形態による仮想スロットと物理スロットとの対応関係及び各物理スロットの接続先の例を示す図である。
【図６】従来例によるＣＡＰＳ／ＯＰＭＳ、ＩＯＣＳ及びスロットインターフェースとの接続関係を示す図である。
【図７】本発明の実施形態によるＣＡＰＳ／ＯＰＭＳ、ＩＯＣＳ、スロット管理モジュール、物理スロット／仮想スロット対照表、スロット制御モジュール及びスロットインターフェースとの接続関係を示す図である。
【図８】本発明の実施形態による物理スロット／仮想スロット対照表の具体例を示す図である。
【図９】本発明の実施形態２によるマスター主装置とスレーブ主装置との接続関係を示す第１の図である。
【図１０】本発明の実施形態２によるマスター主装置とスレーブ主装置との接続関係を示す第２の図である。
【図１１】本発明の実施形態２による主装置間の優先順位の問い合わせの様子を示す図である。
【図１２】本発明の実施形態２によるマスター主装置とスレーブ主装置との接続関係を示す第３の図である。
【図１３】リソース集中管理方式のネットワーキングにおける通信端末との接続の概念図である。
【図１４】本発明の実施形態による、マスター主装置が切り替わった場合の通信端末とマスター主装置とスレーブ主装置との接続関係を示す図である。
【図１５】従来の通信端末と主装置との間の通信の概念図である。
【図１６】本発明の実施形態３による通信端末と主装置との間の通信の概念図である。
【図１７】本発明の実施形態３による通信端末がどの主装置にも接続できることを示す図である。
【図１８】本発明の実施形態４における通常時の主装置間の接続関係を示す図である。
【図１９】本発明の実施形態４における最優先マスター主装置に障害が発生した場合の主装置間の接続関係を示す図である。
【図２０】本発明の実施形態４における最優先マスター主装置が障害から回復した場合の主装置間の接続関係を示す図である。
【図２１】本発明の実施形態４において、代理のマスター主装置が障害が発生した最優先マスター主装置の復帰を監視することを示す図である。
【図２２】本発明の実施形態４による、マスター復帰を監視するタスク構成についての概念図である。
【図２３】本発明の実施形態４による、最優先マスター主装置が復旧し、それを代理マスター主装置が検出した場合の動作についての概念図である。
【図２４】本発明の実施形態４による正常時のマスター主装置とスレーブ主装置が接続されたネットワークの例を示す図である。
【図２５】本発明の実施形態４によるネットワークの一部が切断された場合のマスター主装置とスレーブ主装置が接続されたネットワークの例を示す図である。
【図２６】本発明の実施形態５によるＰＣをマスター主装置としたリソース集中管理方式のネットワーキングの概念図である。
【図２７】本発明の実施形態５によるパッケージ管理方式を示す図である。
【図２８】本発明の実施形態５による第１のＰＣをマスター主装置とし、第２のＰＣを代理マスター装置としたリソース集中管理方式のネットワーキングの概念図である。
【図２９】図２８に示す形態において、第１のＰＣが機能不全となった場合の主装置間の接続関係を示す図である。
【図３０】図２９に示す状態において、第１のＰＣが復旧した場合の主装置間の接続関係を示す図である。
【図３１】従来の実主装置をマスター主装置とした場合のネットワーキングの概念図である。
【図３２】ＰＣをマスター主装置とした場合のネットワーキングの概念図である。
【図３３】従来例による主装置群を示すブロック図である。
【図３４】本発明の実施形態による主装置群を示すブロック図である。
【図３５】本発明の実施形態による主装置の外観を示す斜視図である。
【図３６】本発明の実施形態によるパッケージの外観を示す正面図及び側面図である。
【発明を実施するための形態】
【００３２】
以下、図面を参照して本発明を実施するための最良の形態について詳細に説明する。
【００３３】
［実施形態１］
本実施形態のポイントは、ネットワーク上にあるリソースを自分のリソースのように扱う技術にある。
【００３４】
プログラム制御により動作する主装置では、ハードウェアのリソース管理、すなわち、端末、回線等の管理をパッケージ管理という形で行っている。
【００３５】
したがって、ネットワーク上のリソースを自分のリソースであるかのように扱うためにはネットワーク上のパッケージをあたかも自分のパッケージであるかのように扱うことができればよい。
【００３６】
図１にネットワーク間のパッケージ管理の概念図を示す。
【００３７】
主装置２にパッケージをインストールしたとき、パッケージの情報と、それに接続されている端末や回線等の情報はイーサネット(登録商標)経由で主装置１に伝達される。
【００３８】
一方、主装置２では、それらの情報は一切、パッケージ制御部や呼制御部に伝わらないため、主装置２としては、何も状況に変化があったようには見えない。
【００３９】
主装置１は、主装置２から上がってくるデータを下位のレイヤーで処理し、あたかも、自分のスロットから情報があがってきたかのように見せるため、主装置１としては、自分のスロットにパッケージが刺さったように見える。
【００４０】
また、パッケージに対する指示（下りデータ）に関しても、下位のレイヤーで処理し、仮想パッケージに対する指示は、ネットワーク上にある実パッケージに伝達する。
【００４１】
以上の仕組みを導入することにより、ネットワーク上のリソースをあたかも自分のリソースであるかのように扱うことが可能になる。
【００４２】
したがって、呼制御などの上位のレイヤーでは、ネットワーク上であることを意識することなく、リソースを自由に使用できる。
【００４３】
図２に、本発明によるネットワーキングの構成図を示す。
【００４４】
ネットワーク上の全リソースを管理し、全ての呼制御を行う主装置をマスターと呼ぶ。
【００４５】
他方、マスターに接続し、パッケージ情報を提供し、マスターからの指示にしたがう主装置をスレーブと呼ぶ。
【００４６】
本実施形態によるネットワーキングを行うためには、ネットワークを構成する複数の主装置の中で一台の主装置がマスターになる必要がある。スレーブは全てマスターに接続し、その指示に従い、自分では一切、呼制御等の処理を行わない。すなわち、スレーブが呼制御などを行うための機能部を持っていたとしても、これらは休止状態となる。
【００４７】
マスターは複数のスレーブを制御することができ、スレーブとして接続された主装置のリソースを全て自分のもののように扱うことができる。
【００４８】
以上によって、マスターと、スレーブにより構成されたネットワークがあたかも一つのシステムであるかのように振舞うことができる。
【００４９】
どの主装置がマスター、またはスレーブになるかといった情報、また、それぞれどのＩＰアドレスで接続されているかという情報はあらかじめ設定が必要である。
【００５０】
マスターとして設定された主装置は、スレーブの接続を待ち、スレーブは、あらかじめ設定されたマスターのＩＰアドレスに対し、接続を行う。
【００５１】
このようにして、マスターとスレーブの接続が確立されたあと、パッケージ情報の伝達等が行われ、ネットワークとして動作するようになる。
【００５２】
また、マスターが万が一、ダウンしたとき、これに接続する全ての主装置が利用不可能になってしまう。これを防ぐために、マスターがダウンしたときは、１又は複数のスレーブのうちの一つがマスターになり、マスターの役割を代行する(Redundancy)。
【００５３】
マスターがダウンしたとき、どのスレーブが代行するかという情報は、あらかじめ設定をしておく必要がある。
【００５４】
次に、ネットワーク上のリソースの集中管理を行うための具体的方法について説明する。
【００５５】
図３にネットワーキングにおけるシステム構成を示す。
【００５６】
ネットワーク上にマスターは唯一つ存在し、全てのスレーブを制御する。
【００５７】
ネットワーク上で各システムを識別するために、各システムはそれぞれシステムＩＤという重複しない値を持つ。
【００５８】
図４に、本発明におけるスロット管理の概念図を示す。
【００５９】
ネットワークに接続する、システムＩＤを持つ各システムには、スロットに物理的にパッケージがインストールされているが、これらの情報は、仮想スロットデータベースとして、一元的にまとめられ、マスター−システムで管理される。
【００６０】
マスターは、この仮想スロットデータベースを参照してスロットを制御する。
【００６１】
他システムのスロットであれば、物理的なスロットは、ＩＰ網で接続された遠隔地に存在するが、マスターは、遠隔地にある物理スロットを意識することなく、あたかもそれが自分のスロットであるかのように扱うことができる。
【００６２】
したがって、そのスロットにインストールされたパッケージに接続された端末、回線も自システムに接続された端末、回線と同じように扱うことができる。
【００６３】
これを表した図を図５に示す。
【００６４】
システムＩＤ：１のシステムには、端末を接続するパッケージ、システムＩＤ：２のシステムには、公衆回線に接続する回線を収容するパッケージ、システム：３のシステムには、ＩＰネットワークに接続するＩＰ回線を収容するパッケージがそれぞれインストールされている。
【００６５】
これらの物理的なスロットは、仮想スロットとして管理されているので、スロットに接続するパッケージに収容された端末、回線等を自システム同様、自由に制御できる。
【００６６】
以上の方法によって、ネットワークに分散したシステムであっても制限なく主装置の機能を利用することができる。
【００６７】
図５で示した各システムは、図３にあらわされるように、一台のマスターがそれ以外のスレーブを制御するサーバー・クライアント型の構成となっており、マスターが、自システム含め、全ての主装置の呼処理、データベース管理を行う。また、仮想スロットの管理もマスターが行う。
【００６８】
各システムはＩＰで接続されており、各システムを識別するためにそれぞれ固有のシステムＩＤを持つ。
【００６９】
システム１には、端末を収容するパッケージ、システム２には、通常回線を収容するパッケージ、システム３には、ＩＰ回線を収容するパッケージがそれぞれ収容されている。
【００７０】
これらは、仮想スロットデータベースで情報が管理されている。このデータは、基本的にマスターで管理されるが、マスターが交代したときのために、各スレーブでも同一のデータを保持している。
【００７１】
図５で示した実施例について、データの流れの観点から説明を加える。
【００７２】
図６は、従来のパッケージ制御のデータの流れを示したものである。
【００７３】
図６のように、パッケージからの上りデータは、スロットＩ／Ｆモジュール１０１から、ＩＯＣＳ（入出力制御モジュール）１０３を介し、ＣＡＰＳ（呼制御モジュール）／ＯＰＭＳ（パッケージ、端末管理モジュール）１０５に送られる。
【００７４】
そして、ＣＡＰＳ／ＯＰＭＳ１０５でデータが処理され、ＩＯＣＳ１０３を介して、スロットＩ／Ｆモジュール１０１に下りの指示が行われる。たとえば、パッケージがインストールされたとき、上りデータとして、ＯＰＭＳ１０５にデータが送られ、パッケージがインストールされたことを認識し、パッケージに対し、立ち上げを許可するという、パッケージの起動制御や、スロットにインストールされたパッケージに接続された端末がオフフックした場合なども、上りデータとして、ＣＡＰＳ１０５にオフフックした旨を伝え、ＣＡＰＳ１０５はそれを受け、端末にダイヤルトーンを出すコマンドを、ＩＯＣＳ１０３経由で下りデータとして送出する、などである。
【００７５】
図６では、スロットＩ／Ｆ１０１からのデータを直接、入力データとして上位モジュールに上げているので、当然、自システムに接続されたスロットしか制御できない。
【００７６】
図７に、本実施形態におけるデータの流れを示す。
【００７７】
図７の通り、スロットの入出力を制御するスロット制御モジュール１０７と、スロット情報を管理するスロット管理モジュール１０９を新たに追加することで、ネットワークを介したスロット管理を実現する。
【００７８】
スロットからの上りデータは、一旦、スロット制御モジュール１０７にスプールされ、自システムの属するマスターのスロット管理モジュール１０９に送られる。自身がマスターである場合は、自身のスロット管理モジュール１０９に送られる。スロット管理モジュール１０９に送られたデータは、上位モジュールであるＩＯＣＳ１０３に対し、データをある特定のスロットからデータが上がってきたかのように見せる。
【００７９】
ここで、図８を示し、スロット管理モジュール１０９の動作について、説明を加える。
【００８０】
スロット管理モジュール１０９は、ある特定のシステムの特定のスロットからデータを受け取ったとき、もし、それが、いままでに認識していないシステムのスロットであった場合、新たに仮想的なスロット番号をアサインし、以後、そのシステムのスロットを、アサインした仮想的なスロット番号のスロットとして扱う。
【００８１】
たとえば、システム１のスロット１より上りデータがあがってきた場合、それがいままでに認識していないスロットであった場合、仮想スロットとしてスロット１をアサインする。
【００８２】
このようにして、新たに仮想スロットをアサインしたとき、図８のような物理スロット／仮想スロット対照表１１１を作成していく。
【００８３】
以後、システム１のスロット１よりあがってきたデータは、ＩＯＣＳ，ＣＡＰＳ等の上位モジュールでは、自システムのスロット１であるかのように扱われ、ネットワークを意識する必要すらなくなる。
【００８４】
実際に、スロットに下りデータを送出し、ハードウェアに指示を出すときは、物理スロット／仮想スロット対照表１１１を参照して、適切なシステムのスロットに対して指示を出す。
【００８５】
その指示は、各システムのスロット制御モジュール１０７に届けられ、各システムの実際のパッケージに対してコマンドが送られる。
【００８６】
以上のように、ネットワーク上のスロットを制御、管理するモジュールを導入することで、主装置の処理の大部分では、ネットワークを意識する必要がなく、あたかも、自分のシステムを制御するかのようにハードウェアを制御することが可能となる。
【００８７】
なお、仮想スロットの個数については、物理スロットのようにハードウェア的な制限がなく、システムのメモリが許す限り、無限にアサインすることが可能である。
【００８８】
また、システムの内部的には、通常、仮想スロット番号で処理がされるが、システムデータの設定など、ユーザーの目に見える部分では、どのシステムのどのスロットなのか識別したい場合がある。
【００８９】
その場合には、物理スロット／仮想スロット対照表１１１を参照して、物理スロットで設定等を行うことができる。
【００９０】
［実施形態２］
実施形態１では、分散型のネットワーキングシステムの問題を回避するため、集中管理方式のネットワーキングの方式を発明したことで、従来から抱える問題点の多くを解決した。
【００９１】
しかし、同時に、システムの脆弱性という欠点も抱えてしまう。すなわち、実施形態１では、その性質上、一台のマスターとなる主装置（以下、「マスター主装置」という。）がネットワーク上の全てのリソースを集中管理し、全てのスレーブとなる主装置（以下、「スレーブ主装置」という。）を制御するため、マスター主装置が何らかの障害で機能不全となった場合、それに接続される全てのスレーブ主装置が動作不能になり、ネットワーク全体が機能不全となるという問題を抱えていた。
【００９２】
実施形態２は、実施形態１を改良したものであり、ネットワーキングシステムに冗長性(redundancy)を持たせることにより、ネットワーク機能不全等の障害に備え、システム全体の堅牢性を高めることを目的としたものである。
【００９３】
実施形態２では、マスター主装置となる主装置が機能不全となった場合、それに接続されるスレーブ主装置の中から、代理となる主装置を選出し、その主装置がマスター主装置として動作することで、上記の問題を回避する。
【００９４】
すなわち、マスター主装置が機能不全となった場合、それに接続されるスレーブ主装置は、それを検知し、あらかじめ設定された優先順位に従って、全てのスレーブ主装置の中から代理となる主装置を選出する。そして、代理のマスター主装置に変わったスレーブ主装置は、マスター主装置として稼動を開始し、全てのスレーブ主装置を制御する。この仕組みを導入することで、マスター主装置が機能不全となったとしても、ネットワーク全体が機能不全となることはなく、稼動を続けることが可能となり、システムの堅牢性を高めることができる。
【００９５】
実施形態２では、集中管理方式のネットワーキングにおいて、マスター主装置システムが機能不全となったとき、主装置各個に設定された優先順位に基づいて、代理マスター主装置を一意に選出し、選出された主装置にマスター主装置機能を引き継ぐ。
【００９６】
図９及び図１０に本発明の概念図を示す。
【００９７】
各矢印は、通信関係を示しており、マスター主装置／スレーブ主装置間で常に双方向の通信が行われている。
【００９８】
マスター主装置が機能不全となったり、ネットワーク障害等の理由で、通信が途切れたとき、マスター主装置の交代が行われ、図９のような状態から図１０のような状態に変化する。
【００９９】
図９及び図１０の楕円は、主装置を表しており、各主装置には、システムデータとして、マスター主装置優先順位が設定されている。障害時、稼動している主装置の中から、最もマスター主装置優先順位の高い主装置がマスター主装置として選出され、稼動する。また、全ての主装置に互いのＩＰアドレスが、それぞれ設定されている。
【０１００】
各スレーブ主装置は、常にマスター主装置との接続を監視しており、一定時間以上、マスター主装置と通信が行えない場合は、マスター主装置が機能不全となったり、ネットワーク上の障害が起きたとみなし、代理のマスター主装置の選出に入る。
【０１０１】
代理のマスター主装置の選出は、各主装置が、自分以外の全ての主装置に優先順位を問い合わせることによって行う。問い合わせは、各主装置の持つ、他の主装置のリスト（ＩＰアドレスで表現される）に、ＩＰ上で特定のパケットを投げることによって行う。
【０１０２】
このパケットを受信した主装置は、自身の優先順位を返信する。
【０１０３】
図１１に優先順位問い合わせの概念図を示す。
【０１０４】
各楕円は、優先順位を問い合わせ中の主装置を表し、矢印は、問い合わせを行っていることを表す。図の通り、総当り方式で優先順位を問い合わせている。
【０１０５】
自分の持つリストの主装置全てから、応答が返り、もし、自分自身が最も優先順位が高い場合、自分自身がマスター主装置として稼動を始める。一定時間が過ぎても応答が返らない主装置は、機能不全となっているとみなし、返信が返ってきたものの中で判断する。
【０１０６】
自分自身がマスター主装置となった場合、以後、問い合わせに対しては、自分がマスター主装置である旨を通知する。
【０１０７】
一方、優先順位の低い主装置は、優先順位の最も高い主装置がマスター主装置になるまで、問い合わせを続ける。問い合わせを続けているうちにマスター主装置となる主装置が稼動し始めるので、問い合わせに対して、新たなマスター主装置からそれがマスター主装置である旨が返信される。この返信を受けとったら、以後、返信元のマスター主装置に接続し、主装置自身はスレーブ主装置として稼動を始める。
【０１０８】
以上の流れは、自分自身がマスター主装置または、スレーブ主装置となるまで続けられ、これが繰り返されることで、優先順位の最も高いマスター主装置を一意に選出し、選出したマスター主装置を中心にした新しいネットワークを形成することができる。
【０１０９】
各主装置は、ＩＰ網で接続されており、それぞれユニークなＩＰアドレス、マスター主装置候補優先順位の値を持つ。また、ネットワークを構成する他の全ての主装置のＩＰアドレスのリストを持つ。また、各主装置を識別するため、それぞれの主装置はユニークなＩＤを持つ。以後、このＩＤをシステムＩＤと呼ぶ。システムＩＤをマスター主装置優先順位に等しいとみなしてもかまわない。
【０１１０】
図１２に本発明の構成図を示す。
【０１１１】
図１２に示すように、各主装置は、一意にＩＰアドレス及びシステムＩＤが振られており、データとして、他の主装置のＩＰアドレス及びシステムＩＤに関する情報を持つ。
【０１１２】
マスター主装置が機能不全となったときや、ネットワーク構築時等、マスター主装置がまだ決定していない場合、これらの情報を元にマスター主装置を決定する。
【０１１３】
この方法によって、代理マスター主装置を選出し、ネットワークとして最低限稼動を続けることは可能であるが、機能を損なわず、動作させるためには、この方法だけでは不十分である。次に、これを補うための方法について述べる。
【０１１４】
１．システムデータの同期
主装置は、電話機、回線等の設定情報をシステムデータと呼ばれるファイルとして保持している。
【０１１５】
集中管理方式のネットワーキングでは、マスター主装置が全てのスレーブ主装置の情報を管理し、動作するため、マスター主装置が保持するシステムデータをマスター主装置が参照する。
【０１１６】
したがって、マスター主装置が切り替わったとき、新しくマスター主装置となった主装置は、自分の主装置のシステムデータを参照するため、マスター主装置となりうる主装置は、常に、現在マスター主装置として稼動しているシステムと同じシステムデータを保持している必要がある。
【０１１７】
これを実現するために、集中管理方式のネットワーキングでは、マスター主装置がシステムデータを更新するたびに、常に最新のデータを配下のスレーブ主装置へ送信、同期する仕組みを導入する。
【０１１８】
２． 強制マスター主装置切り替え
上述したマスター主装置交代の方式では、マスター主装置との接続が一定時間行えない場合、マスター主装置に障害が発生したとみなし、自動的にマスター主装置交代を行うが、システムの設定変更等の理由でリセットすることもあり、その場合、マスター主装置を元の主装置に戻したい場合もある。
【０１１９】
また、ネットワークシステムの初期構築時、どの主装置がマスター主装置になるかは、立ち上がりの順番によって変わるので、特定の主装置をマスター主装置にしたい場合に都合が悪い。
【０１２０】
そのようなときのために、マスター主装置を強制的に設定する機能を提供する。
【０１２１】
マスター主装置の強制設定は、ユーザーによる手動で、マスター主装置としたい主装置のシステムＩＤを指定することで行う。たとえば、ある電話機端末で特定の番号（＃９９９など）＋システムＩＤを押したとき、そのシステムＩＤを持つ、主装置を強制的にマスター主装置とする。
【０１２２】
この操作は、ネットワークに接続されているどのシステムの端末からでも行うことができる。
【０１２３】
この操作が行われたとき、マスター主装置は、どのシステムＩＤが新規のマスター主装置になるか判断できるので、自身の持つＩＰアドレスのリストから、新規マスター主装置のＩＰアドレスを取得し、コマンドの送信先がマスター主装置になる旨のコマンドをパケットとして送信する。
【０１２４】
そのコマンドを受け取った主装置は、マスター主装置として稼動を開始し、全ての主装置にマスター主装置交代した旨を通知する。
【０１２５】
実施形態２によって、集中管理方式のネットワーキングにおいて抱えていた、マスターとなる主装置が機能不全となったときにネットワーク全体が機能不全となるという脆弱性の問題を回避することができる。
【０１２６】
これは、電話機のような、ミッションクリティカルな業務に使用されうるシステムにおいては特に重要な機能であり、不可欠であるといえる。
【０１２７】
［実施形態３］
実施形態２では、リソース集中管理方式のネットワーキングに冗長化機能を持たせることにより、ネットワーク全体を制御するマスター主装置を切り替えることができるようになり、システムの堅牢性は向上した。
【０１２８】
しかし、実施形態２では、同時に、マスター主装置が交代することにより、外部のＣＴＩ(Computer Telephony Integration)サーバ、ＡＣＤ−ＭＩＳ(Automatic Call Distributor-Management Information System)などの通信端末は、接続すべき通信相手が変わってしまい、通信できなくなるという問題点を抱えてしまう。また、外部のＣＴＩサーバ、ＡＣＤ−ＭＩＳなどの通信端末は、ネットワークのどの主装置がマスター主装置であるか、あらかじめ知っておく必要があった。
【０１２９】
実施形態３では、マスター主装置以外の各主装置が、ＣＴＩサーバ、ＡＣＤ−ＭＩＳなどの通信端末からの通信をマスター主装置に転送（リダイレクト）することで上記の問題を回避する。
【０１３０】
すなわち、通信端末からの接続を認識した主装置は、もし、自分がマスター主装置でないとき、すなわち、自分がスレーブ主装置であるときは、自分の接続しているマスター主装置に対し、通信端末からの接続をリダイレクトする。また、通信端末からのデータを転送し、マスター主装置からのデータを通信端末に中継する。
【０１３１】
こうすることで、通信端末としては、あたかもマスター主装置と通信しているように見え、マスター主装置としては、通信端末と通信しているように見える。
【０１３２】
これによって、通信端末としては、マスター主装置が切り替わったことを意識する必要はなく、また、ネットワーク上でどの主装置がマスター主装置であるかを意識する必要もない。
【０１３３】
そして、マスター主装置としても、従来どおり、通信端末と接続しているように見えるため、特に処理を変更する必要はない。
【０１３４】
以下、図面を参照して実施形態３について更に詳細に説明する。
【０１３５】
図１３にリソース集中管理方式のネットワーキングにおける通信端末との接続の概念図を示す。
【０１３６】
ネットワーク上で、呼制御、リソース管理の一切を行うマスター主装置はただ一つ存在し、スレーブ主装置となる主装置は、マスター主装置と通信し、すべてマスター主装置の指示に従う。
【０１３７】
通信端末は、あらかじめ設定されたＩＰアドレスに従い、マスター主装置と通信し、呼情報を取得したり、主装置を制御したりする。
【０１３８】
ここで、通信が途切れたり、システムがダウンしたとき、冗長化機能により、マスター主装置が交代する。このときの状態の概念図を図１４に示す。
【０１３９】
このとき、スレーブ主装置であった主装置がマスター主装置となり、マスター主装置であった主装置はスレーブ主装置となるが通信端末は、通常、単一の主装置と通信するようにしか作られていないため、マスター主装置が切り替わっても、従来どおりの相手先と通信するしかない。
【０１４０】
しかし、その通信相手は既にマスター主装置ではなく、マスター主装置からの指示に従うだけのスレーブ主装置なので通信端末と通信することはできるが、適切な情報を返すことができない。
【０１４１】
そこで本実施形態では、この通信端末の接続を中継し、通信端末は新たなマスター主装置と、新たなマスター主装置は通信端末と直接通信しているかのように見せる技術を提供する。
【０１４２】
図２で示された構成図では、各主装置はインターネットプロトコルで接続されており、マスター主装置は、各スレーブ主装置と相互に通信を行っている。マスター主装置は、呼情報、リソース情報など、システムの情報をすべて管理しているが、スレーブ主装置は基本的に、単に通信機能を有するのみであり、通信端末に対し、直接、適切な処理を行うことはできない。
【０１４３】
また、通信端末は、特定の主装置との接続を行うことしかできない。
【０１４４】
実施形態３の実際の動作について、説明を加える。
【０１４５】
図１５に、従来の通信端末と、主装置の通信の概念図を示す。
【０１４６】
主装置は、通信端末の接続のために、システムデータで設定された特定のポートをオープンし、接続をそのポートで待ち受ける。
【０１４７】
通信端末は、主装置のＩＰアドレスと、ポートに対し、接続を行う。
【０１４８】
これは、通信端末のアプリケーションによって行われ、ＩＰアドレスとポートはあらかじめ設定しておく必要がある。
【０１４９】
たとえば、ＣＴＩを行う場合、主装置はＣＴＩ用の通信ポート８０００を用意し、待ち受ける。それに対し、通信端末では、ＣＴＩのアプリケーションを立ち上げ、主装置のＩＰアドレス、通信ポート８０００を設定し、主装置に対し、接続する。
【０１５０】
そして、主装置に対し、データを送信することでコマンドを送信したり、データを受信することで、結果を得る。
【０１５１】
これに対し、図１６に実施形態３の概念図を示す。
【０１５２】
主装置は、通信端末からの接続を受けたとき、もし自分がマスター主装置でなかったら、通信端末からの接続を維持しつつ、マスター主装置に対し、接続を行う。
【０１５３】
このとき、マスター主装置（以前のスレーブ装置）とスレーブ主装置（以前のマスター装置）とでシステムデータは同期が取れているので、スレーブ主装置は、マスター主装置と同じポートで通信端末からの接続に対し待ち受けることができるし、マスター主装置の待ち受けポートに接続を行うことができる。
【０１５４】
スレーブ主装置からの接続を受けたマスター主装置は、その接続は、通信端末からの接続であると認識し、サービスを開始する。一方、通信端末の側も、スレーブ主装置に接続したことで、マスター主装置に接続したと認識し、動作を開始する。
【０１５５】
以後、スレーブ主装置は、通信端末からのデータをマスター主装置に転送、マスター主装置からのデータを通信端末に転送する。こうすることで、マスター主装置が実際にはどこにあろうとも、通信端末は一切それを意識することなく、通信することが可能になる。
【０１５６】
したがって、通信端末のアプリケーションがサードパーティー製であっても問題なく使用することが可能である。また、マスター主装置としても、従来どおり、通信端末が接続したように認識するため、処理を変更する必要がない。
【０１５７】
また、図１７に示すとおり、通信端末は、どの主装置に接続してもマスター主装置と通信を行うことができるため、通信端末は、ネットワークのどれか一つの主装置を接続先として登録しておけばよく、マスター主装置がどれであるか意識する必要はない。
【０１５８】
本発明を利用することで、冗長化機能によるマスター主装置交代によって、通信端末が接続できなくなるという問題を回避することができる。また、通信端末や、マスター主装置の従来どおりの動作を保証できるため、アプリケーションを変更する必要がない。
【０１５９】
実施形態３によって、集中管理方式のネットワーキングにおいて抱えていた、マスターとなる主装置が機能不全となったときにネットワーク全体が機能不全となるという脆弱性の問題を回避することができる。
【０１６０】
これは、電話機のような、ミッションクリティカルな業務に使用されうるシステムにおいては特に重要な機能であり、不可欠であるといえる。
【０１６１】
［実施形態４］
マスター主装置がダウンした場合の動作については実施形態２及び実施形態３で説明した。これに対し、実施形態４は、システムが復旧した場合についてのものである。
【０１６２】
実施形態４では、障害等で一時的に分割されたネットワーク状態において、復旧を自動的に検知することにより、ネットワークを統合し、元の運用状態へと自動的に移行するものである。
【０１６３】
実施形態２及び実施形態３では、リソース集中管理による機能制限のないネットワーキング（以下、集中管理ネットワーキング）におけるマスター主装置がダウンしたり、ネットワーク障害により通信ができなくなった場合に、代理となるマスター主装置をスレーブ主装置の中から選出することで、ネットワーク全体がダウンすることなく、稼動を継続することができた。
【０１６４】
一方、代理となるマスター主装置を選出した場合、たとえ元々のマスター主装置と他の主装置との間の通信が復旧しても、代理マスター主装置はそのまま代理マスター主装置として稼動を継続するため、マスター主装置が２つ以上できてしまい、それぞれ稼動を継続することができるものの、２つの主装置の系列の間での通信はでき、ネットワークは分断されたままであった。
【０１６５】
実施形態４では、ネットワーク障害発生後、代理のマスター主装置と本来のマスター主装置との通信が復旧したときに自動的にそれを検出し、本来のマスターを中心にネットワークを再構築することで上記の問題を回避する。
【０１６６】
すなわち、代理のマスター主装置は本来のマスター主装置の状態を定期的に監視し、本来のマスター主装置の復旧を検出できた場合には、代理のマスター主装置自身とその配下のスレーブ主装置を本来のマスター主装置をスレーブ主装置として再接続する。こうすることで、通信復旧後、ネットワークは自動的に統合され、障害前と同様の状態で稼動を継続することができる。
【０１６７】
図１８、図１９及び図２０に実施形態４の概念図を示す。
【０１６８】
図１８のように、集中管理ネットワーキングでは、マスターとなる主装置がスレーブとなる主装置のリソースを一元管理し、制御を行っていた。このため、マスター主装置がダウンした場合、制御を行う主装置が存在しなくなってしまい、そのため、実施形態２及び実施形態３にて示したように、代理のマスターを選出し、稼動を継続する仕組みを発明した（図１９）。実施形態４では、図２０に示すとおり、本来のマスター主装置が復旧したとき、ネットワークを再構築し、当初の通りの運用を継続することができる仕組みについて詳述する。
【０１６９】
図２１に概念図を示す。Ｆａｉｌ−Ｏｖｅｒ（障害時の代替マスター主装置の選出とネットワーク再構成）が起き、代理のマスター主装置を中心とするネットワークが形成されたとき、代理のマスター主装置は、あらかじめ設定された本来のマスター主装置のＩＰアドレスを取得し、本来のマスター主装置（以後、これを「最優先マスター主装置」という。）の復帰を監視する機能を走らせる。
【０１７０】
最優先マスターのＩＰアドレスについては、あらかじめ最優先マスター自身に自分のＩＰアドレスを設定しておけば、自動的にそのデータは各ノード（主装置）に伝達され、同期が取られるのでＦａｉｌ−Ｏｖｅｒが起きた後、そのＩＰアドレスを元に最優先マスター主装置の復帰を監視すればいい。
【０１７１】
図２２にマスター復帰を監視するタスク構成について概念図を示す。
【０１７２】
代理マスター主装置となった主装置は、代理マスター主装置として稼動を開始するとき、自分自身のＩＰアドレスと最優先マスターのＩＰアドレスを比較し、一致していなければ自分自身が代理マスター主装置であることを判断し、最優先マスター主装置の復帰を監視するタスクを起動する。このタスクは低い優先順位で定周期に動作し、最優先マスターのＩＰアドレスに対し、接続を試行する単一の作業を試行し続けるものである。
【０１７３】
この間、マスター主装置としてスレーブ主装置を制御するタスク等は通常通り動作し、最優先マスター主装置の復帰を監視しながら、通常通りマスター主装置としてスレーブ主装置を制御し、ネットワーキングを稼動し続けることができる。
【０１７４】
図２３に最優先マスター主装置が復旧し、それを代理マスター主装置が検出した場合の動作についての概念図を示す。
【０１７５】
最優先マスター主装置監視タスクによって、最優先マスター主装置の復旧が検出できたとき、代理マスター主装置は自身をスレーブ主装置とし、また、スレーブ主装置を制御するマスター主装置を、代理のマスター主装置から最優先マスター主装置に変更するための動作を始める。
【０１７６】
図２３に示すように、まず、自分自身をマスター主装置からスレーブ主装置に遷移させ、最優先マスター主装置に接続しなおす。
【０１７７】
このとき、最優先マスター主装置監視タスク、呼制御タスクはもはや不要なので削除し、スレーブ制御タスクをマスター通信タスクに切り替える。そしてハードウェア制御タスクを生成し、自分自身がスレーブ主装置として動作するように動作モードを切り替える。そして、自分自身の配下であったスレーブに対し、最優先マスター主装置のＩＰアドレスを通知し、接続先を最優先マスター主装置に切り替えるよう指示を行い、自分自身も最優先マスター主装置にスレーブ主装置に接続する。
【０１７８】
指示を受けたスレーブ主装置は代理のマスター主装置から最優先マスター主装置に接続しなおし、最優先マスター主装置による制御を受けるよう動作を切り替える。
【０１７９】
以上の動作によって、代理マスター主装置及びその配下のスレーブ主装置は、最優先マスター主装置に再接続し、Ｆａｉｌ−Ｏｖｅｒ前の接続状態に戻ることができる。これによって、ネットワーク復旧後、速やかに運用状態を回復させることができる。
【０１８０】
ここで、図２４に示すようなネットワーク構成を考える。
【０１８１】
黒点は、ルーターなどの、ネットワーク間を相互接続する通信機器を示しているものとする。
【０１８２】
図２５に示すようなネットワーク間での通信障害が発生したとき、実施形態２及び実施形態３では、通信可能なノード間で最大のネットワークを構成するようネットワークを再構築する方法を提示した。これによって図の×印で示されるネットワーク間での通信障害が発生した場合、図の２つの楕円で示したようなネットワークをそれぞれに構成し、各々のマスター主装置を中心として限定的ではあるが、ネットワークとして稼動することができた。
【０１８３】
実施形態４により、ネットワーク間での障害が復旧したとき、先の図２２、図２３で示した方法を使うことで、下部の孤立したネットワークは、上部のマスター主装置の復旧を検出することができ、当初の図２４で示した接続状態を復旧できる。これによって、障害時に限定されたネットワークで稼動しつつ、障害復旧時には完全なネットワークでの接続も復旧できる。
【０１８４】
図２４において、黒点はルーターなどのネットワーク間を相互接続する接続機器を表している。異なるネットワークをルーターで相互接続し、マスターとなる主装置が全ノードの情報を一元管理し、ネットワーキングを実現している。そのため、ネットワーク間での通信に障害が発生した場合、図２５に示すように同一ネットワークで最大の構成をとるようＦａｉｌ−Ｏｖｅｒ機能が動作する。
【０１８５】
図２４にて示したネットワーク構成において、ネットワーク間の通信上に障害が発生した場合、Ｆａｉｌ−Ｏｖｅｒ機能によって、図２５に示したように、分断されたネットワークにおいて最大の通信が行えるよう代理のマスター主装置を選出し、ネットワークの再構成が行われる。代理のマスター主装置となった主装置は、代理マスター主装置として稼動を開始した時点から図２２に示す最優先マスター主装置監視タスクを稼動させ、最優先マスターの復旧を監視し始める。
【０１８６】
最優先マスター主装置又はネットワークが復旧したとき、最優先マスター主装置からの応答を受け取ることができるようになるので、それをもって障害復旧を判断し、復旧のための動作を始める。
【０１８７】
代理マスター主装置の配下で稼動しているスレーブ主装置は、制御を受けるマスター主装置が交代するので、代理マスター主装置は、代理マスター主装置の配下のスレーブに対し、マスター主装置の変更と新しいマスター主装置のＩＰアドレスを通知する。
【０１８８】
スレーブ主装置としては基本的にそれまでどおりスレーブ主装置として稼動するだけであり、接続先が変わるだけであるのでこの際、特別な処理は必要としない。しかし、マスター主装置がスレーブ主装置になるとき、代理マスター主装置として動作するための各種タスクの停止と、スレーブタスクへの移行、そしてマスター主装置として一元管理していた各種リソースの開放が必要である。ここで、リソースの開放に関する説明を行う。
【０１８９】
図５に示したように、集中管理ネットワーキングでは、ネットワークに接続するノードのリソースをマスター主装置となる主装置で一元管理する方法をとっている。
【０１９０】
そのため、マスターの役割を終えたとき、これらのリソースの管理状態のクリアを行う。
【０１９１】
これらのタスク、リソースのクリアを行った後、代理マスター主装置はスレーブ主装置に移行し、最優先マスター主装置に再接続し、制御を受けることになる。代理マスター主装置としての状態は内部的にクリアされるので、システムを物理的にリセットする必要はなく、迅速な復旧動作が可能になる。
【０１９２】
以上の処理によって、完全に障害前の状態に迅速に復旧し、稼動を継続することができる。
【０１９３】
本実施形態を適用することで、障害復旧を自動的に感知し、元の運用状態に戻すことが可能になる。また、常に障害復旧を監視し、迅速に復旧処理を行うことができるため、常に最適な状態で運用するシステムを構築することが可能になる。
【０１９４】
なお、復旧処理においては、システムの物理的なリセットは必要ないが、タスクの切り替え、接続先変更に伴い、端末・回線を制御するパッケージをリセットする必要があり、そのため通話状態等をそのまま継続することはできない。そのため、復旧処理を自動で行うのではなく、システムがアイドル状態のときに手動で行うことも必要である。また、システムの状態を監視し、復旧を検出し、かつアイドルとなったときに復旧処理を行う方法も考えられる。
【０１９５】
［実施形態５］
実施形態１では、分散型のネットワーキングシステムの問題を回避するため、集中管理方式のネットワーキングの方式を参考形態したことで、従来から抱える問題点の多くを解決した。
【０１９６】
すなわち、リソース集中管理方式のネットワーキングを発明したことで、情報の管理が容易になり、機能制限のないネットワーキングを実現することができた。しかし、一台の主装置に処理が集中することになってしまい、ＣＰＵの負担が増し、多くのリソースを制御できないことがネックとなる。すなわち、ネットワーク上のすべてのシステムを一台のマスター主装置が制御することになり、マスター主装置には、膨大な負荷が集中することとなってしまっていた。
【０１９７】
そこで、実施形態５は、高いパフォーマンスを有するパーソナルコンピュータ（以下、「ＰＣ」という。）上のＣＰＵを利用してのネットワーキングを実現し、膨大なトラフィックのかかるマスター主装置の負荷低減と、外部アプリケーションとの親和性を向上させることを目的とする。
【０１９８】
実施形態５では、マスター主装置となるシステムとして、交換機ではなく、高性能な汎用ＰＣを利用することで上記の問題を回避する。すなわち、ＰＣ上で交換機と同様のプログラムを実行させ、各主装置とＰＣをＩＰ網で接続する。スレーブ主装置として接続された主装置のハードウェアをマスター主装置としてのＰＣにより制御する。
【０１９９】
こうすることで、ＰＣのもつ高性能なＣＰＵを利用することが可能となり、スレーブ主装置からの膨大なトラフィックを処理することができるようになる。
【０２００】
図２６にＰＣをマスター主装置としたリソース集中管理方式のネットワーキングの概念図を示す。
【０２０１】
図２６ではＰＣをマスター主装置として稼動させ、実主装置をスレーブ主装置として制御することをあらわしている。
【０２０２】
ここで、ＰＣは当然、交換機のハードウェアを直接制御できないので、それらの制御は、接続される各スレーブ主装置が行う。
【０２０３】
このことを図２７を用いて説明する。
【０２０４】
図２７のパッケージ管理方式は、参考形態を応用している。
【０２０５】
実際のハードウェアであるパッケージは、スレーブ主装置であるシステムＩＤ２、３、４にインストールされるが、それらの情報はすべてマスター主装置であるシステムＩＤ１に送られ、管理される。
【０２０６】
また、パッケージに接続する端末、回線などの情報もすべてマスター主装置に上りデータとしてあがってくる。
【０２０７】
このようにすることで、マスター主装置から見ると、パッケージを収容する能力がないにも関わらず、あたかも自分自身にパッケージがインストールされているかのように見える。
【０２０８】
また、実際のパッケージに対する指示は、各々のシステムのパッケージに転送し、端末、回線などを制御する。
【０２０９】
このようにすることで、パッケージを直接制御できない汎用のＰＣでも交換機を制御することが可能となり、また、高性能なＣＰＵを利用できるため、多数のスレーブ主装置を接続した場合でもトラフィックに耐えることができる。
【０２１０】
これにより、リソース集中管理によるネットワーキングの問題点が緩和され、より規模の大きなネットワーキングを構築することができる。
【０２１１】
また、リソース集中管理方式のネットワーキングでは、マスター主装置が何らかの理由でダウンしたり、通信が途切れたときに、代理のマスター主装置を選出して運用を継続する仕組みを導入している。
【０２１２】
図２６の仕組みでは、マスター主装置であるＰＣがダウンすると、ＰＣがネットワークに接続していないため、スレーブ主装置として接続している主装置の中で、あらかじめ設定されたマスター主装置候補優先順位の最も高い主装置がマスター主装置となってしまい、結果、ＣＰＵ能力の低いノードがマスター主装置となってしまう。
【０２１３】
これを防ぐために代理マスター主装置となるＰＣを待機させ、障害発生時に稼動させる仕組みを導入する。
【０２１４】
図２８に実施例を示す。
【０２１５】
図２８では、図２６で示したネットワークに新たにスレーブ主装置としてＰＣを参加させていることを示している。
【０２１６】
マスター主装置であるシステム１が正常に稼動している間は、接続されたシステムＩＤ５のＰＣは特に稼動せず、待機している。そしてマスター主装置に障害が発生したとき、それを検出し、システムＩＤ５のＰＣは代理のマスター主装置として稼動を開始する。こうすることで、図２９に示すようにマスター主装置であるＰＣで障害が発生しても、同様のＣＰＵ性能を持つＰＣがマスター主装置を引き継ぐことができて、トラフィック処理能力を下げるのを防ぐことができる。また、障害から復帰したとき、図３０に示すようにシステム１はスレーブ主装置としてシステム５に接続し、障害に備え待機する。そして、システム５に障害が発生したときは、システムＩＤ１のＰＣを再度マスター主装置として稼動を開始する。
【０２１７】
こうすることで、どちらかのＰＣが稼動していればＰＣをマスター主装置としてネットワークを稼動させることができる。
【０２１８】
システム２、３、４は、パッケージをインストールするスロットを持つ実際の主装置であり、それぞれ、端末、公衆回線、ＩＰネットワークと接続するパッケージを収容している。これらは、スレーブ主装置として稼動しており、システム１でマスター主装置として稼動しているＰＣにＩＰで接続し、制御を受けている。
【０２１９】
システム１のマスター主装置として稼動しているＰＣは、システム２、３、４のパッケージなどのハードウェア情報、呼状態などの情報などを一括して管理し、接続する全スレーブ主装置の呼制御を行う。
【０２２０】
また、システム５は、スレーブ主装置としてシステム１に接続し、障害時のためにシステム１を監視、待機している。
【０２２１】
次に、具体的な実現方法について説明を加える。
【０２２２】
パッケージのリソース管理に関する方法は、参考形態で説明した通りである。
【０２２３】
ここでは、それ以外の、マスター主装置としてＰＣを利用するための方法について述べる。
【０２２４】
図３１に、従来の実主装置をマスター主装置とした場合のネットワーキングの概念図を示す。
【０２２５】
本発明における機能モジュールを大まかに分けると、着信や通話などの制御を行う呼制御部、マスター主装置−スレーブ主装置間で、パッケージデータの送受信などを行う、通信部、パッケージからのデータを受信したり、パッケージに指示を行うハードウェア制御部となる。
【０２２６】
図３１では、マスター主装置となる主装置のみ呼制御部が動作しており、スレーブ主装置は呼制御を行っていない。
【０２２７】
スレーブ主装置は、ハードウェア制御部にてパッケージからデータを受信し、通信部にてマスター主装置にデータを送信する。
【０２２８】
マスター主装置は呼制御部にてそのデータをもとに呼制御を行い、折り返し、通信部でパッケージデータを送信し、スレーブ主装置はそのデータを受け取りハードウェアを制御する。
【０２２９】
また、マスター主装置自身にもパッケージを収容するスロットが存在するのでハードウェア制御部が稼動し、パッケージを制御する。
【０２３０】
図３２に、本実施形態における機能モジュールの概念図を示す。
【０２３１】
マスター主装置は汎用のＰＣであるため、当然、直接パッケージを収容できないので、ハードウェア制御部は不要である。
【０２３２】
また、不要であるだけではなく、存在しないハードウェアを制御しようとするため、動作自体を禁止しなければならない。
【０２３３】
したがって、実装すべきモジュールは、図の通り、呼制御部、通信部のみとなるため、処理的にターゲットに依存せず、ＰＣ上でも実装が可能となる。
【０２３４】
また、マスター主装置−スレーブ主装置間は、ＴＣＰ／ＩＰを用いて通信を行うため、処理的に同等であれば、マスター主装置−スレーブ主装置間でＯＳが同一である必要はない。たとえば、ＰＣ上ではＬｉｎｕｘ（登録商標）、実主装置上ではＶｘＷｏｒｋｓ（登録商標）やＮｕｃｌｅｕｓ Ｐｌｕｓなどの組み込み用ＯＳを搭載することが可能である。
【０２３５】
なお、図の通り、スレーブ主装置となる主装置は、基本的に通信部とハードウェア制御部しか動作していない。
【０２３６】
したがって、マスター主装置のＰＣには高性能なＣＰＵが必要であるが、スレーブ主装置となる主装置には安価なＣＰＵで十分といえる。また、同様にすべてのリソース管理がマスター主装置に集中するため、マスター主装置となるＰＣは多くのメモリリソースが必要であるが、スレーブ主装置となる主装置は、リソース管理を一切行わないため、非常に少ないメモリリソースで動作が可能である。
【０２３７】
なお、リソース集中管理方式のネットワーキングでは、マスター主装置がダウンしたときにあらかじめ設定されたマスター主装置優先順位の高いものから代理マスター主装置を選出し、運用を継続する機能があるが、貧弱なＣＰＵとメモリしか有しない実主装置が代理マスター主装置に選出されることがないよう、実主装置には低い優先順位を割り当て、バックアップのＰＣに高い優先順位を割り当てる必要がある。
【０２３８】
実施形態５を適用することで、高性能なＣＰＵを持つシステムをマスター主装置とすることが可能となり、より規模の大きなネットワーキングを構築することが可能となる。
【０２３９】
また、ＰＣ上で主装置のソフトを実行可能になることで、ＰＣと主装置の親和性が高まり、アプリケーション連携、たとえばＣＴＩ(Computer Telephony Integration)などを行うことが容易となる。
【０２４０】
［実施形態６］
実施形態６では、より具体的な構成について説明をする。
【０２４１】
図３３は、従来例による主装置群を示す。図３３を参照すると、従来例によれば、主装置群に含まれる主装置は、マスター主装置とスレーブ主装置に分類されない。各主装置は独自に動作し、ＶｏＩＰインターフェース２０１を介してＩＰネットワーク２０３により接続されている。各主装置には、ＣＡＰＳ／ＯＰＭＳ１０５、ＩＯＣＳ１０３、スロットＩ／Ｆ１０１が含まれているが、スロット管理モジュール１０９、物理スロット／仮想スロット対照表１１１、スロット制御モジュール１０７は含まれていない。
【０２４２】
図３４は、本発明の実施形態による主装置群を示す。図３４を参照すると、本発明の実施形態によれば、主装置群に含まれる主装置は、１つのマスター主装置２１１と複数のスレーブ主装置２１３に分類される。１つのマスター主装置２１１と複数のスレーブ主装置２１３は、ＶｏＩＰインターフェース２１５を介してＩＰネットワーク２１７により接続されている。複数のスレーブ主装置２１３は、１つのマスター主装置２１１の制御の下で動作する。マスター主装置２１１は、ＣＡＰＳ／ＯＰＭＳ１０５、ＩＯＣＳ１０３、スロット管理モジュール１０９、物理スロット／仮想スロット対照表１１１、スロットＩ／Ｆモジュール１０１を含む。各スレーブ主装置２１３は、スロット制御モジュール１０７、スロットＩ／Ｆ１０１を含む。
【０２４３】
図３５は、主装置の外観例を示す。主装置は、物理スロットを複数有し、物理スロットにパッケージが挿入されるようになっている。
【０２４４】
図３６は、パッケージの外観例を示す。パッケージには、物理スロットのバックボードコネクタ３０１（図３５参照）と接続されるコネクタ３０３、外線やＰＢＸ内線と接続されるコネクタ３０５を有する。
【産業上の利用可能性】
【０２４５】
本発明によれば、単一の主装置が、ネットワークにつながる全ての主装置のハードウェアのリソース等の情報を一元管理することができる。
【符号の説明】
【０２４６】
１０１ システムインターフェース
１０３ ＩＯＣＳ（入出力制御モジュール）
１０５ ＣＡＰＳ（呼制御モジュール）／ＯＰＭＳ（パッケージ、端末管理モジュール）
１０７ スロット制御モジュール
１０９ スロット管理モジュール
１１１ 物理スロット／管理スロット対照表
【技術分野】
【０００１】
本発明は、複数の主装置に分散して存在するスロットインターフェースにアクセスするためのスロットインターフェースアクセス装置、その方法及びそのプログラムに関する。
【０００２】
また、本発明は、主装置を複数設置し、マスターとなる主装置が機能不全となった場合に、他の主装置が代替のマスター主装置となる主装置の冗長構成及び主装置の代替方法に関する。
【背景技術】
【０００３】
従来より、主装置間をネットワークでつなぎ、主装置間で相互に相手の機能を利用する技術はあった。ここで、主装置とは、端末（ボタン電話など）を収容するインターフェースを備えたり、公衆回線と接続するためのインターフェースを備えたり、ＩＰネットワークと接続するためのインターフェースを備えたりする装置のことである。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】国際公開第１９９７／３５２５５号パンフレット
【特許文献２】特開２００１−３５８７３６号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかし、主装置の機能をネットワークを介して他の主装置で利用できるようにするためには、各機能を改造する必要があった。そのため、改造されていない機能はネットワークに対応しておらず、ある主装置の全ての機能をネットワーク経由で他の主装置が利用するということができなかった。
【０００６】
すなわち、従来、主装置間のネットワーキングによる接続は、各主装置がそれぞれのＣＰＵでリソースを管理し、端末、回線等の状態も別々に管理していたため、ネットワーク間で主装置の機能を動かすためには、単一の主装置で機能を動かすようには簡単にはいかず、ネットワークに対応するよう機能の作り変えが必要であった。
【０００７】
また、従来のネットワーキングシステムにおいては、主装置のリソースであるパッケージのスロットは、各システムごとに別々に管理されており、そのため、個々のシステムは互いに相手のリソースの情報、状態等を知ることができず、そのため、ネットワーク上で主装置の機能を利用する際、制限が生じていた。
【０００８】
そこで、本発明は、単一の主装置が、ネットワークにつながる全ての主装置のハードウェアのリソース等の情報を一元管理することにより、情報の管理を容易にし、機能制限のないネットワーキングを構築することを目的とする。
【課題を解決するための手段】
【０００９】
本発明では、従来、各々の主装置が管理していた全てのリソース情報を一台の主装置が一元管理し、また、呼制御も一台の主装置が一括して行うことで、従来の問題を回避する。
【００１０】
すなわち、ネットワークに接続されている他の主装置の端末、回線等の監視、制御を全て一台の主装置が一括して行うことで、ネットワーク上のリソースをあたかも自分の主装置に接続されているかのように扱うことができる。
【００１１】
つまり、他のシステムの端末、回線を、自分の端末、回線のように扱うことができるため、従来のように主装置の機能をネットワーク対応に改造する必要はなく、特にネットワークを意識する必要すらなくなる。
【００１２】
そして、現在ネットワーク対応していない機能を含め、全ての機能をネットワークで利用可能となる。
【００１３】
また、本発明では、一台の主装置が、ネットワークに接続する全ての主装置のスロットを一元管理することにより上記の問題を回避する。
【００１４】
すなわち、ネットワーク上で全ての呼処理を制御するマスター主装置が、自らのスロットと、自らに接続するスレーブ主装置のスロットを一元管理し、他システムのスロットであっても、あたかも自システムのスロットであるかのように扱う。
【００１５】
こうすることで、ネットワーク上のスロットの全情報をマスターが管理できることになり、同時に、スロットにインストールされたパッケージに接続する端末、回線など全てのリソースも、自システムのものであるかのように扱うことができるようになる。
【００１６】
本発明によれば、入出力制御モジュールとその下位のスロットインターフェースとの間に、スロット管理モジュール、スロット制御モジュール及び物理スロット／管理スロット対照表を備え、前記入出力制御モジュールは、仮想スロット識別情報を用いて前記スロットインターフェースにアクセスし、前記スロット管理モジュールが、前記物理スロット／管理スロット対照表を参照して、仮想スロット識別情報を物理スロット識別情報に変換し、変換により得られた物理スロット識別情報に対応するスロット制御モジュールにアクセスすることにより、前記入出力制御モジュールによる前記スロットインターフェースへの物理的なアクセスが実現されることを特徴とするスロットインターフェースアクセス装置が提供される。
【００１７】
また、本発明によれば、入出力制御モジュールとその下位のスロットインターフェースとの間に、スロット管理モジュール、スロット制御モジュール及び物理スロット／管理スロット対照表を設け、前記入出力制御モジュールは、仮想スロット識別情報を用いて前記スロットインターフェースにアクセスし、前記スロット管理モジュールが、前記物理スロット／管理スロット対照表を参照して、仮想スロット識別情報を物理スロット識別情報に変換し、変換により得られた物理スロット識別情報に対応するスロット制御モジュールにアクセスすることにより、前記入出力制御モジュールによる前記スロットインターフェースへの物理的なアクセスが実現されることを特徴とするスロットインターフェースアクセス方法が提供される。
【００１８】
更に、本発明によれば、複数の主装置を備え、そのうち１つの主装置がマスター主装置であり、他の主装置がスレーブ主装置であり、前記マスター主装置が機能不全となった場合、前記スレーブ主装置のうちの１つのスレーブ主装置が新たなマスター主装置となることを特徴とする主装置の冗長構成が提供される。
【００１９】
更に、本発明によれば、上記の主装置の冗長構成において、前記新たなマスター主装置は、機能不全となったマスター主装置が回復したか否かを監視し、機能不全となったマスター主装置が回復した時に、新たなマスター主装置は、回復したマスター主装置にシステム全体の制御権を戻すことを特徴とする主装置の冗長構成が提供される。
【００２０】
更に、本発明によれば、複数の主装置を備え、そのうち１つの主装置がマスター主装置であり、他の主装置がスレーブ主装置であり、前記マスター主装置が機能不全となった場合、前記スレーブ主装置のうちの１つのスレーブ主装置が新たなマスター主装置となることを特徴とする主装置の代替方法が提供される。
【００２１】
更に、本発明によれば、上記の主装置の代替方法において、前記新たなマスター主装置は、機能不全となったマスター主装置が回復したか否かを監視し、機能不全となったマスター主装置が回復した時に、新たなマスター主装置は、回復したマスター主装置にシステム全体の制御権を戻すことを特徴とする主装置の代替方法が提供される。
【００２２】
更に、本発明によれば、入出力制御モジュールとその下位のスロットインターフェースとの間に、スロット管理モジュール、スロット制御モジュール及び物理スロット／管理スロット対照表を備え、前記入出力制御モジュールは、仮想スロット識別情報を用いて前記スロットインターフェースにアクセスし、前記スロット管理モジュールが、前記物理スロット／管理スロット対照表を参照して、仮想スロット識別情報を物理スロット識別情報に変換し、変換により得られた物理スロット識別情報に対応するスロット制御モジュールにアクセスすることにより、前記入出力制御モジュールによる前記スロットインターフェースへの物理的なアクセスが実現されることを特徴とするスロットインターフェースアクセス装置であって、当該装置は、スロットインターフェースを有する他の装置よりもＣＰＵ能力が高いことを特徴とするスロットインターフェースアクセス装置が提供される。
【００２３】
更に、本発明によれば、入出力制御モジュールとその下位のスロットインターフェースとの間に、スロット管理モジュール、スロット制御モジュール及び物理スロット／管理スロット対照表を備え、前記入出力制御モジュールは、仮想スロット識別情報を用いて前記スロットインターフェースにアクセスし、前記スロット管理モジュールが、前記物理スロット／管理スロット対照表を参照して、仮想スロット識別情報を物理スロット識別情報に変換し、変換により得られた物理スロット識別情報に対応するスロット制御モジュールにアクセスすることにより、前記入出力制御モジュールによる前記スロットインターフェースへの物理的なアクセスが実現されることを特徴とするスロットインターフェースアクセス方法であって、当該方法は、スロットインターフェースを有する他の装置よりもＣＰＵ能力が高い装置により行われることを特徴とするスロットインターフェースアクセス方法が提供される。
【発明の効果】
【００２４】
本発明によれば、主装置の持つ、理論上全ての機能をネットワーク上で利用できるようになる。既存の技術では、各主装置が基本的に独立で動いており、それらを協調して動かすためには、一つ一つの機能に関して、特別な変更が必要であった。しかし、本発明によって、下位のレイヤーでネットワーク間の違いを吸収する仕組みを導入することで、上位レイヤーの機能は、ネットワーク間を意識することなく、機能を動かすことができるようになる。
【００２５】
また、本発明を利用することにより、信頼性の高いネットワーキングを構築できる。従来の方式では、それぞれの主装置が独立で動いており、リソースも別々に管理していた。そのため、タイミングによって、リソース間の状態等に矛盾が生じるといった問題が生じえた。本発明では、この問題も解消できる。
【００２６】
更に、本発明では、主装置の機能の最も下位のレイヤーで機能を構築するため、下位のレイヤーさえ問題なく作りこめば、上位のレイヤーで機能不具合が生じることはないし、リソースの集中管理をすることで、リソース間の状態等に矛盾が生じることもない。
【００２７】
更に、本発明を利用することで、ネットワーキングでありながら、それを意識させない仕組みを構築することが可能となる。
【００２８】
更に、処理の最も低いレイヤーでネットワークによる違いを吸収する仕組みを導入することで上位のアプリケーションは、ネットワークを意識することなく、機能を利用可能となる。
【００２９】
そのため、従来、アプリケーションレベルで必要であったネットワーク対応の処理がまったく必要なくなり、ネットワーク対応工数を大幅に削減できるだけでなく、品質も向上させることができる。
【００３０】
これによって、従来ネットワーク対応に機能改造するためにかかっていた膨大な工数をゼロにでき、また、品質も向上させることができる。
【図面の簡単な説明】
【００３１】
【図１】本発明の実施形態による、仮想パッケージを用いて、他の主装置の実パッケージを自主装置の実パッケージとして扱う様子を示す図である。
【図２】本発明の実施形態によるマスター主装置とスレーブ主装置の接続例を示す図である。
【図３】本発明の実施形態によるマスター主装置とスレーブ主装置の他の接続例を示す図である。
【図４】本発明の実施形態による仮想スロットと物理スロットとの対応関係を示す図である。
【図５】本発明の実施形態による仮想スロットと物理スロットとの対応関係及び各物理スロットの接続先の例を示す図である。
【図６】従来例によるＣＡＰＳ／ＯＰＭＳ、ＩＯＣＳ及びスロットインターフェースとの接続関係を示す図である。
【図７】本発明の実施形態によるＣＡＰＳ／ＯＰＭＳ、ＩＯＣＳ、スロット管理モジュール、物理スロット／仮想スロット対照表、スロット制御モジュール及びスロットインターフェースとの接続関係を示す図である。
【図８】本発明の実施形態による物理スロット／仮想スロット対照表の具体例を示す図である。
【図９】本発明の実施形態２によるマスター主装置とスレーブ主装置との接続関係を示す第１の図である。
【図１０】本発明の実施形態２によるマスター主装置とスレーブ主装置との接続関係を示す第２の図である。
【図１１】本発明の実施形態２による主装置間の優先順位の問い合わせの様子を示す図である。
【図１２】本発明の実施形態２によるマスター主装置とスレーブ主装置との接続関係を示す第３の図である。
【図１３】リソース集中管理方式のネットワーキングにおける通信端末との接続の概念図である。
【図１４】本発明の実施形態による、マスター主装置が切り替わった場合の通信端末とマスター主装置とスレーブ主装置との接続関係を示す図である。
【図１５】従来の通信端末と主装置との間の通信の概念図である。
【図１６】本発明の実施形態３による通信端末と主装置との間の通信の概念図である。
【図１７】本発明の実施形態３による通信端末がどの主装置にも接続できることを示す図である。
【図１８】本発明の実施形態４における通常時の主装置間の接続関係を示す図である。
【図１９】本発明の実施形態４における最優先マスター主装置に障害が発生した場合の主装置間の接続関係を示す図である。
【図２０】本発明の実施形態４における最優先マスター主装置が障害から回復した場合の主装置間の接続関係を示す図である。
【図２１】本発明の実施形態４において、代理のマスター主装置が障害が発生した最優先マスター主装置の復帰を監視することを示す図である。
【図２２】本発明の実施形態４による、マスター復帰を監視するタスク構成についての概念図である。
【図２３】本発明の実施形態４による、最優先マスター主装置が復旧し、それを代理マスター主装置が検出した場合の動作についての概念図である。
【図２４】本発明の実施形態４による正常時のマスター主装置とスレーブ主装置が接続されたネットワークの例を示す図である。
【図２５】本発明の実施形態４によるネットワークの一部が切断された場合のマスター主装置とスレーブ主装置が接続されたネットワークの例を示す図である。
【図２６】本発明の実施形態５によるＰＣをマスター主装置としたリソース集中管理方式のネットワーキングの概念図である。
【図２７】本発明の実施形態５によるパッケージ管理方式を示す図である。
【図２８】本発明の実施形態５による第１のＰＣをマスター主装置とし、第２のＰＣを代理マスター装置としたリソース集中管理方式のネットワーキングの概念図である。
【図２９】図２８に示す形態において、第１のＰＣが機能不全となった場合の主装置間の接続関係を示す図である。
【図３０】図２９に示す状態において、第１のＰＣが復旧した場合の主装置間の接続関係を示す図である。
【図３１】従来の実主装置をマスター主装置とした場合のネットワーキングの概念図である。
【図３２】ＰＣをマスター主装置とした場合のネットワーキングの概念図である。
【図３３】従来例による主装置群を示すブロック図である。
【図３４】本発明の実施形態による主装置群を示すブロック図である。
【図３５】本発明の実施形態による主装置の外観を示す斜視図である。
【図３６】本発明の実施形態によるパッケージの外観を示す正面図及び側面図である。
【発明を実施するための形態】
【００３２】
以下、図面を参照して本発明を実施するための最良の形態について詳細に説明する。
【００３３】
［実施形態１］
本実施形態のポイントは、ネットワーク上にあるリソースを自分のリソースのように扱う技術にある。
【００３４】
プログラム制御により動作する主装置では、ハードウェアのリソース管理、すなわち、端末、回線等の管理をパッケージ管理という形で行っている。
【００３５】
したがって、ネットワーク上のリソースを自分のリソースであるかのように扱うためにはネットワーク上のパッケージをあたかも自分のパッケージであるかのように扱うことができればよい。
【００３６】
図１にネットワーク間のパッケージ管理の概念図を示す。
【００３７】
主装置２にパッケージをインストールしたとき、パッケージの情報と、それに接続されている端末や回線等の情報はイーサネット(登録商標)経由で主装置１に伝達される。
【００３８】
一方、主装置２では、それらの情報は一切、パッケージ制御部や呼制御部に伝わらないため、主装置２としては、何も状況に変化があったようには見えない。
【００３９】
主装置１は、主装置２から上がってくるデータを下位のレイヤーで処理し、あたかも、自分のスロットから情報があがってきたかのように見せるため、主装置１としては、自分のスロットにパッケージが刺さったように見える。
【００４０】
また、パッケージに対する指示（下りデータ）に関しても、下位のレイヤーで処理し、仮想パッケージに対する指示は、ネットワーク上にある実パッケージに伝達する。
【００４１】
以上の仕組みを導入することにより、ネットワーク上のリソースをあたかも自分のリソースであるかのように扱うことが可能になる。
【００４２】
したがって、呼制御などの上位のレイヤーでは、ネットワーク上であることを意識することなく、リソースを自由に使用できる。
【００４３】
図２に、本発明によるネットワーキングの構成図を示す。
【００４４】
ネットワーク上の全リソースを管理し、全ての呼制御を行う主装置をマスターと呼ぶ。
【００４５】
他方、マスターに接続し、パッケージ情報を提供し、マスターからの指示にしたがう主装置をスレーブと呼ぶ。
【００４６】
本実施形態によるネットワーキングを行うためには、ネットワークを構成する複数の主装置の中で一台の主装置がマスターになる必要がある。スレーブは全てマスターに接続し、その指示に従い、自分では一切、呼制御等の処理を行わない。すなわち、スレーブが呼制御などを行うための機能部を持っていたとしても、これらは休止状態となる。
【００４７】
マスターは複数のスレーブを制御することができ、スレーブとして接続された主装置のリソースを全て自分のもののように扱うことができる。
【００４８】
以上によって、マスターと、スレーブにより構成されたネットワークがあたかも一つのシステムであるかのように振舞うことができる。
【００４９】
どの主装置がマスター、またはスレーブになるかといった情報、また、それぞれどのＩＰアドレスで接続されているかという情報はあらかじめ設定が必要である。
【００５０】
マスターとして設定された主装置は、スレーブの接続を待ち、スレーブは、あらかじめ設定されたマスターのＩＰアドレスに対し、接続を行う。
【００５１】
このようにして、マスターとスレーブの接続が確立されたあと、パッケージ情報の伝達等が行われ、ネットワークとして動作するようになる。
【００５２】
また、マスターが万が一、ダウンしたとき、これに接続する全ての主装置が利用不可能になってしまう。これを防ぐために、マスターがダウンしたときは、１又は複数のスレーブのうちの一つがマスターになり、マスターの役割を代行する(Redundancy)。
【００５３】
マスターがダウンしたとき、どのスレーブが代行するかという情報は、あらかじめ設定をしておく必要がある。
【００５４】
次に、ネットワーク上のリソースの集中管理を行うための具体的方法について説明する。
【００５５】
図３にネットワーキングにおけるシステム構成を示す。
【００５６】
ネットワーク上にマスターは唯一つ存在し、全てのスレーブを制御する。
【００５７】
ネットワーク上で各システムを識別するために、各システムはそれぞれシステムＩＤという重複しない値を持つ。
【００５８】
図４に、本発明におけるスロット管理の概念図を示す。
【００５９】
ネットワークに接続する、システムＩＤを持つ各システムには、スロットに物理的にパッケージがインストールされているが、これらの情報は、仮想スロットデータベースとして、一元的にまとめられ、マスター−システムで管理される。
【００６０】
マスターは、この仮想スロットデータベースを参照してスロットを制御する。
【００６１】
他システムのスロットであれば、物理的なスロットは、ＩＰ網で接続された遠隔地に存在するが、マスターは、遠隔地にある物理スロットを意識することなく、あたかもそれが自分のスロットであるかのように扱うことができる。
【００６２】
したがって、そのスロットにインストールされたパッケージに接続された端末、回線も自システムに接続された端末、回線と同じように扱うことができる。
【００６３】
これを表した図を図５に示す。
【００６４】
システムＩＤ：１のシステムには、端末を接続するパッケージ、システムＩＤ：２のシステムには、公衆回線に接続する回線を収容するパッケージ、システム：３のシステムには、ＩＰネットワークに接続するＩＰ回線を収容するパッケージがそれぞれインストールされている。
【００６５】
これらの物理的なスロットは、仮想スロットとして管理されているので、スロットに接続するパッケージに収容された端末、回線等を自システム同様、自由に制御できる。
【００６６】
以上の方法によって、ネットワークに分散したシステムであっても制限なく主装置の機能を利用することができる。
【００６７】
図５で示した各システムは、図３にあらわされるように、一台のマスターがそれ以外のスレーブを制御するサーバー・クライアント型の構成となっており、マスターが、自システム含め、全ての主装置の呼処理、データベース管理を行う。また、仮想スロットの管理もマスターが行う。
【００６８】
各システムはＩＰで接続されており、各システムを識別するためにそれぞれ固有のシステムＩＤを持つ。
【００６９】
システム１には、端末を収容するパッケージ、システム２には、通常回線を収容するパッケージ、システム３には、ＩＰ回線を収容するパッケージがそれぞれ収容されている。
【００７０】
これらは、仮想スロットデータベースで情報が管理されている。このデータは、基本的にマスターで管理されるが、マスターが交代したときのために、各スレーブでも同一のデータを保持している。
【００７１】
図５で示した実施例について、データの流れの観点から説明を加える。
【００７２】
図６は、従来のパッケージ制御のデータの流れを示したものである。
【００７３】
図６のように、パッケージからの上りデータは、スロットＩ／Ｆモジュール１０１から、ＩＯＣＳ（入出力制御モジュール）１０３を介し、ＣＡＰＳ（呼制御モジュール）／ＯＰＭＳ（パッケージ、端末管理モジュール）１０５に送られる。
【００７４】
そして、ＣＡＰＳ／ＯＰＭＳ１０５でデータが処理され、ＩＯＣＳ１０３を介して、スロットＩ／Ｆモジュール１０１に下りの指示が行われる。たとえば、パッケージがインストールされたとき、上りデータとして、ＯＰＭＳ１０５にデータが送られ、パッケージがインストールされたことを認識し、パッケージに対し、立ち上げを許可するという、パッケージの起動制御や、スロットにインストールされたパッケージに接続された端末がオフフックした場合なども、上りデータとして、ＣＡＰＳ１０５にオフフックした旨を伝え、ＣＡＰＳ１０５はそれを受け、端末にダイヤルトーンを出すコマンドを、ＩＯＣＳ１０３経由で下りデータとして送出する、などである。
【００７５】
図６では、スロットＩ／Ｆ１０１からのデータを直接、入力データとして上位モジュールに上げているので、当然、自システムに接続されたスロットしか制御できない。
【００７６】
図７に、本実施形態におけるデータの流れを示す。
【００７７】
図７の通り、スロットの入出力を制御するスロット制御モジュール１０７と、スロット情報を管理するスロット管理モジュール１０９を新たに追加することで、ネットワークを介したスロット管理を実現する。
【００７８】
スロットからの上りデータは、一旦、スロット制御モジュール１０７にスプールされ、自システムの属するマスターのスロット管理モジュール１０９に送られる。自身がマスターである場合は、自身のスロット管理モジュール１０９に送られる。スロット管理モジュール１０９に送られたデータは、上位モジュールであるＩＯＣＳ１０３に対し、データをある特定のスロットからデータが上がってきたかのように見せる。
【００７９】
ここで、図８を示し、スロット管理モジュール１０９の動作について、説明を加える。
【００８０】
スロット管理モジュール１０９は、ある特定のシステムの特定のスロットからデータを受け取ったとき、もし、それが、いままでに認識していないシステムのスロットであった場合、新たに仮想的なスロット番号をアサインし、以後、そのシステムのスロットを、アサインした仮想的なスロット番号のスロットとして扱う。
【００８１】
たとえば、システム１のスロット１より上りデータがあがってきた場合、それがいままでに認識していないスロットであった場合、仮想スロットとしてスロット１をアサインする。
【００８２】
このようにして、新たに仮想スロットをアサインしたとき、図８のような物理スロット／仮想スロット対照表１１１を作成していく。
【００８３】
以後、システム１のスロット１よりあがってきたデータは、ＩＯＣＳ，ＣＡＰＳ等の上位モジュールでは、自システムのスロット１であるかのように扱われ、ネットワークを意識する必要すらなくなる。
【００８４】
実際に、スロットに下りデータを送出し、ハードウェアに指示を出すときは、物理スロット／仮想スロット対照表１１１を参照して、適切なシステムのスロットに対して指示を出す。
【００８５】
その指示は、各システムのスロット制御モジュール１０７に届けられ、各システムの実際のパッケージに対してコマンドが送られる。
【００８６】
以上のように、ネットワーク上のスロットを制御、管理するモジュールを導入することで、主装置の処理の大部分では、ネットワークを意識する必要がなく、あたかも、自分のシステムを制御するかのようにハードウェアを制御することが可能となる。
【００８７】
なお、仮想スロットの個数については、物理スロットのようにハードウェア的な制限がなく、システムのメモリが許す限り、無限にアサインすることが可能である。
【００８８】
また、システムの内部的には、通常、仮想スロット番号で処理がされるが、システムデータの設定など、ユーザーの目に見える部分では、どのシステムのどのスロットなのか識別したい場合がある。
【００８９】
その場合には、物理スロット／仮想スロット対照表１１１を参照して、物理スロットで設定等を行うことができる。
【００９０】
［実施形態２］
実施形態１では、分散型のネットワーキングシステムの問題を回避するため、集中管理方式のネットワーキングの方式を発明したことで、従来から抱える問題点の多くを解決した。
【００９１】
しかし、同時に、システムの脆弱性という欠点も抱えてしまう。すなわち、実施形態１では、その性質上、一台のマスターとなる主装置（以下、「マスター主装置」という。）がネットワーク上の全てのリソースを集中管理し、全てのスレーブとなる主装置（以下、「スレーブ主装置」という。）を制御するため、マスター主装置が何らかの障害で機能不全となった場合、それに接続される全てのスレーブ主装置が動作不能になり、ネットワーク全体が機能不全となるという問題を抱えていた。
【００９２】
実施形態２は、実施形態１を改良したものであり、ネットワーキングシステムに冗長性(redundancy)を持たせることにより、ネットワーク機能不全等の障害に備え、システム全体の堅牢性を高めることを目的としたものである。
【００９３】
実施形態２では、マスター主装置となる主装置が機能不全となった場合、それに接続されるスレーブ主装置の中から、代理となる主装置を選出し、その主装置がマスター主装置として動作することで、上記の問題を回避する。
【００９４】
すなわち、マスター主装置が機能不全となった場合、それに接続されるスレーブ主装置は、それを検知し、あらかじめ設定された優先順位に従って、全てのスレーブ主装置の中から代理となる主装置を選出する。そして、代理のマスター主装置に変わったスレーブ主装置は、マスター主装置として稼動を開始し、全てのスレーブ主装置を制御する。この仕組みを導入することで、マスター主装置が機能不全となったとしても、ネットワーク全体が機能不全となることはなく、稼動を続けることが可能となり、システムの堅牢性を高めることができる。
【００９５】
実施形態２では、集中管理方式のネットワーキングにおいて、マスター主装置システムが機能不全となったとき、主装置各個に設定された優先順位に基づいて、代理マスター主装置を一意に選出し、選出された主装置にマスター主装置機能を引き継ぐ。
【００９６】
図９及び図１０に本発明の概念図を示す。
【００９７】
各矢印は、通信関係を示しており、マスター主装置／スレーブ主装置間で常に双方向の通信が行われている。
【００９８】
マスター主装置が機能不全となったり、ネットワーク障害等の理由で、通信が途切れたとき、マスター主装置の交代が行われ、図９のような状態から図１０のような状態に変化する。
【００９９】
図９及び図１０の楕円は、主装置を表しており、各主装置には、システムデータとして、マスター主装置優先順位が設定されている。障害時、稼動している主装置の中から、最もマスター主装置優先順位の高い主装置がマスター主装置として選出され、稼動する。また、全ての主装置に互いのＩＰアドレスが、それぞれ設定されている。
【０１００】
各スレーブ主装置は、常にマスター主装置との接続を監視しており、一定時間以上、マスター主装置と通信が行えない場合は、マスター主装置が機能不全となったり、ネットワーク上の障害が起きたとみなし、代理のマスター主装置の選出に入る。
【０１０１】
代理のマスター主装置の選出は、各主装置が、自分以外の全ての主装置に優先順位を問い合わせることによって行う。問い合わせは、各主装置の持つ、他の主装置のリスト（ＩＰアドレスで表現される）に、ＩＰ上で特定のパケットを投げることによって行う。
【０１０２】
このパケットを受信した主装置は、自身の優先順位を返信する。
【０１０３】
図１１に優先順位問い合わせの概念図を示す。
【０１０４】
各楕円は、優先順位を問い合わせ中の主装置を表し、矢印は、問い合わせを行っていることを表す。図の通り、総当り方式で優先順位を問い合わせている。
【０１０５】
自分の持つリストの主装置全てから、応答が返り、もし、自分自身が最も優先順位が高い場合、自分自身がマスター主装置として稼動を始める。一定時間が過ぎても応答が返らない主装置は、機能不全となっているとみなし、返信が返ってきたものの中で判断する。
【０１０６】
自分自身がマスター主装置となった場合、以後、問い合わせに対しては、自分がマスター主装置である旨を通知する。
【０１０７】
一方、優先順位の低い主装置は、優先順位の最も高い主装置がマスター主装置になるまで、問い合わせを続ける。問い合わせを続けているうちにマスター主装置となる主装置が稼動し始めるので、問い合わせに対して、新たなマスター主装置からそれがマスター主装置である旨が返信される。この返信を受けとったら、以後、返信元のマスター主装置に接続し、主装置自身はスレーブ主装置として稼動を始める。
【０１０８】
以上の流れは、自分自身がマスター主装置または、スレーブ主装置となるまで続けられ、これが繰り返されることで、優先順位の最も高いマスター主装置を一意に選出し、選出したマスター主装置を中心にした新しいネットワークを形成することができる。
【０１０９】
各主装置は、ＩＰ網で接続されており、それぞれユニークなＩＰアドレス、マスター主装置候補優先順位の値を持つ。また、ネットワークを構成する他の全ての主装置のＩＰアドレスのリストを持つ。また、各主装置を識別するため、それぞれの主装置はユニークなＩＤを持つ。以後、このＩＤをシステムＩＤと呼ぶ。システムＩＤをマスター主装置優先順位に等しいとみなしてもかまわない。
【０１１０】
図１２に本発明の構成図を示す。
【０１１１】
図１２に示すように、各主装置は、一意にＩＰアドレス及びシステムＩＤが振られており、データとして、他の主装置のＩＰアドレス及びシステムＩＤに関する情報を持つ。
【０１１２】
マスター主装置が機能不全となったときや、ネットワーク構築時等、マスター主装置がまだ決定していない場合、これらの情報を元にマスター主装置を決定する。
【０１１３】
この方法によって、代理マスター主装置を選出し、ネットワークとして最低限稼動を続けることは可能であるが、機能を損なわず、動作させるためには、この方法だけでは不十分である。次に、これを補うための方法について述べる。
【０１１４】
１．システムデータの同期
主装置は、電話機、回線等の設定情報をシステムデータと呼ばれるファイルとして保持している。
【０１１５】
集中管理方式のネットワーキングでは、マスター主装置が全てのスレーブ主装置の情報を管理し、動作するため、マスター主装置が保持するシステムデータをマスター主装置が参照する。
【０１１６】
したがって、マスター主装置が切り替わったとき、新しくマスター主装置となった主装置は、自分の主装置のシステムデータを参照するため、マスター主装置となりうる主装置は、常に、現在マスター主装置として稼動しているシステムと同じシステムデータを保持している必要がある。
【０１１７】
これを実現するために、集中管理方式のネットワーキングでは、マスター主装置がシステムデータを更新するたびに、常に最新のデータを配下のスレーブ主装置へ送信、同期する仕組みを導入する。
【０１１８】
２． 強制マスター主装置切り替え
上述したマスター主装置交代の方式では、マスター主装置との接続が一定時間行えない場合、マスター主装置に障害が発生したとみなし、自動的にマスター主装置交代を行うが、システムの設定変更等の理由でリセットすることもあり、その場合、マスター主装置を元の主装置に戻したい場合もある。
【０１１９】
また、ネットワークシステムの初期構築時、どの主装置がマスター主装置になるかは、立ち上がりの順番によって変わるので、特定の主装置をマスター主装置にしたい場合に都合が悪い。
【０１２０】
そのようなときのために、マスター主装置を強制的に設定する機能を提供する。
【０１２１】
マスター主装置の強制設定は、ユーザーによる手動で、マスター主装置としたい主装置のシステムＩＤを指定することで行う。たとえば、ある電話機端末で特定の番号（＃９９９など）＋システムＩＤを押したとき、そのシステムＩＤを持つ、主装置を強制的にマスター主装置とする。
【０１２２】
この操作は、ネットワークに接続されているどのシステムの端末からでも行うことができる。
【０１２３】
この操作が行われたとき、マスター主装置は、どのシステムＩＤが新規のマスター主装置になるか判断できるので、自身の持つＩＰアドレスのリストから、新規マスター主装置のＩＰアドレスを取得し、コマンドの送信先がマスター主装置になる旨のコマンドをパケットとして送信する。
【０１２４】
そのコマンドを受け取った主装置は、マスター主装置として稼動を開始し、全ての主装置にマスター主装置交代した旨を通知する。
【０１２５】
実施形態２によって、集中管理方式のネットワーキングにおいて抱えていた、マスターとなる主装置が機能不全となったときにネットワーク全体が機能不全となるという脆弱性の問題を回避することができる。
【０１２６】
これは、電話機のような、ミッションクリティカルな業務に使用されうるシステムにおいては特に重要な機能であり、不可欠であるといえる。
【０１２７】
［実施形態３］
実施形態２では、リソース集中管理方式のネットワーキングに冗長化機能を持たせることにより、ネットワーク全体を制御するマスター主装置を切り替えることができるようになり、システムの堅牢性は向上した。
【０１２８】
しかし、実施形態２では、同時に、マスター主装置が交代することにより、外部のＣＴＩ(Computer Telephony Integration)サーバ、ＡＣＤ−ＭＩＳ(Automatic Call Distributor-Management Information System)などの通信端末は、接続すべき通信相手が変わってしまい、通信できなくなるという問題点を抱えてしまう。また、外部のＣＴＩサーバ、ＡＣＤ−ＭＩＳなどの通信端末は、ネットワークのどの主装置がマスター主装置であるか、あらかじめ知っておく必要があった。
【０１２９】
実施形態３では、マスター主装置以外の各主装置が、ＣＴＩサーバ、ＡＣＤ−ＭＩＳなどの通信端末からの通信をマスター主装置に転送（リダイレクト）することで上記の問題を回避する。
【０１３０】
すなわち、通信端末からの接続を認識した主装置は、もし、自分がマスター主装置でないとき、すなわち、自分がスレーブ主装置であるときは、自分の接続しているマスター主装置に対し、通信端末からの接続をリダイレクトする。また、通信端末からのデータを転送し、マスター主装置からのデータを通信端末に中継する。
【０１３１】
こうすることで、通信端末としては、あたかもマスター主装置と通信しているように見え、マスター主装置としては、通信端末と通信しているように見える。
【０１３２】
これによって、通信端末としては、マスター主装置が切り替わったことを意識する必要はなく、また、ネットワーク上でどの主装置がマスター主装置であるかを意識する必要もない。
【０１３３】
そして、マスター主装置としても、従来どおり、通信端末と接続しているように見えるため、特に処理を変更する必要はない。
【０１３４】
以下、図面を参照して実施形態３について更に詳細に説明する。
【０１３５】
図１３にリソース集中管理方式のネットワーキングにおける通信端末との接続の概念図を示す。
【０１３６】
ネットワーク上で、呼制御、リソース管理の一切を行うマスター主装置はただ一つ存在し、スレーブ主装置となる主装置は、マスター主装置と通信し、すべてマスター主装置の指示に従う。
【０１３７】
通信端末は、あらかじめ設定されたＩＰアドレスに従い、マスター主装置と通信し、呼情報を取得したり、主装置を制御したりする。
【０１３８】
ここで、通信が途切れたり、システムがダウンしたとき、冗長化機能により、マスター主装置が交代する。このときの状態の概念図を図１４に示す。
【０１３９】
このとき、スレーブ主装置であった主装置がマスター主装置となり、マスター主装置であった主装置はスレーブ主装置となるが通信端末は、通常、単一の主装置と通信するようにしか作られていないため、マスター主装置が切り替わっても、従来どおりの相手先と通信するしかない。
【０１４０】
しかし、その通信相手は既にマスター主装置ではなく、マスター主装置からの指示に従うだけのスレーブ主装置なので通信端末と通信することはできるが、適切な情報を返すことができない。
【０１４１】
そこで本実施形態では、この通信端末の接続を中継し、通信端末は新たなマスター主装置と、新たなマスター主装置は通信端末と直接通信しているかのように見せる技術を提供する。
【０１４２】
図２で示された構成図では、各主装置はインターネットプロトコルで接続されており、マスター主装置は、各スレーブ主装置と相互に通信を行っている。マスター主装置は、呼情報、リソース情報など、システムの情報をすべて管理しているが、スレーブ主装置は基本的に、単に通信機能を有するのみであり、通信端末に対し、直接、適切な処理を行うことはできない。
【０１４３】
また、通信端末は、特定の主装置との接続を行うことしかできない。
【０１４４】
実施形態３の実際の動作について、説明を加える。
【０１４５】
図１５に、従来の通信端末と、主装置の通信の概念図を示す。
【０１４６】
主装置は、通信端末の接続のために、システムデータで設定された特定のポートをオープンし、接続をそのポートで待ち受ける。
【０１４７】
通信端末は、主装置のＩＰアドレスと、ポートに対し、接続を行う。
【０１４８】
これは、通信端末のアプリケーションによって行われ、ＩＰアドレスとポートはあらかじめ設定しておく必要がある。
【０１４９】
たとえば、ＣＴＩを行う場合、主装置はＣＴＩ用の通信ポート８０００を用意し、待ち受ける。それに対し、通信端末では、ＣＴＩのアプリケーションを立ち上げ、主装置のＩＰアドレス、通信ポート８０００を設定し、主装置に対し、接続する。
【０１５０】
そして、主装置に対し、データを送信することでコマンドを送信したり、データを受信することで、結果を得る。
【０１５１】
これに対し、図１６に実施形態３の概念図を示す。
【０１５２】
主装置は、通信端末からの接続を受けたとき、もし自分がマスター主装置でなかったら、通信端末からの接続を維持しつつ、マスター主装置に対し、接続を行う。
【０１５３】
このとき、マスター主装置（以前のスレーブ装置）とスレーブ主装置（以前のマスター装置）とでシステムデータは同期が取れているので、スレーブ主装置は、マスター主装置と同じポートで通信端末からの接続に対し待ち受けることができるし、マスター主装置の待ち受けポートに接続を行うことができる。
【０１５４】
スレーブ主装置からの接続を受けたマスター主装置は、その接続は、通信端末からの接続であると認識し、サービスを開始する。一方、通信端末の側も、スレーブ主装置に接続したことで、マスター主装置に接続したと認識し、動作を開始する。
【０１５５】
以後、スレーブ主装置は、通信端末からのデータをマスター主装置に転送、マスター主装置からのデータを通信端末に転送する。こうすることで、マスター主装置が実際にはどこにあろうとも、通信端末は一切それを意識することなく、通信することが可能になる。
【０１５６】
したがって、通信端末のアプリケーションがサードパーティー製であっても問題なく使用することが可能である。また、マスター主装置としても、従来どおり、通信端末が接続したように認識するため、処理を変更する必要がない。
【０１５７】
また、図１７に示すとおり、通信端末は、どの主装置に接続してもマスター主装置と通信を行うことができるため、通信端末は、ネットワークのどれか一つの主装置を接続先として登録しておけばよく、マスター主装置がどれであるか意識する必要はない。
【０１５８】
本発明を利用することで、冗長化機能によるマスター主装置交代によって、通信端末が接続できなくなるという問題を回避することができる。また、通信端末や、マスター主装置の従来どおりの動作を保証できるため、アプリケーションを変更する必要がない。
【０１５９】
実施形態３によって、集中管理方式のネットワーキングにおいて抱えていた、マスターとなる主装置が機能不全となったときにネットワーク全体が機能不全となるという脆弱性の問題を回避することができる。
【０１６０】
これは、電話機のような、ミッションクリティカルな業務に使用されうるシステムにおいては特に重要な機能であり、不可欠であるといえる。
【０１６１】
［実施形態４］
マスター主装置がダウンした場合の動作については実施形態２及び実施形態３で説明した。これに対し、実施形態４は、システムが復旧した場合についてのものである。
【０１６２】
実施形態４では、障害等で一時的に分割されたネットワーク状態において、復旧を自動的に検知することにより、ネットワークを統合し、元の運用状態へと自動的に移行するものである。
【０１６３】
実施形態２及び実施形態３では、リソース集中管理による機能制限のないネットワーキング（以下、集中管理ネットワーキング）におけるマスター主装置がダウンしたり、ネットワーク障害により通信ができなくなった場合に、代理となるマスター主装置をスレーブ主装置の中から選出することで、ネットワーク全体がダウンすることなく、稼動を継続することができた。
【０１６４】
一方、代理となるマスター主装置を選出した場合、たとえ元々のマスター主装置と他の主装置との間の通信が復旧しても、代理マスター主装置はそのまま代理マスター主装置として稼動を継続するため、マスター主装置が２つ以上できてしまい、それぞれ稼動を継続することができるものの、２つの主装置の系列の間での通信はでき、ネットワークは分断されたままであった。
【０１６５】
実施形態４では、ネットワーク障害発生後、代理のマスター主装置と本来のマスター主装置との通信が復旧したときに自動的にそれを検出し、本来のマスターを中心にネットワークを再構築することで上記の問題を回避する。
【０１６６】
すなわち、代理のマスター主装置は本来のマスター主装置の状態を定期的に監視し、本来のマスター主装置の復旧を検出できた場合には、代理のマスター主装置自身とその配下のスレーブ主装置を本来のマスター主装置をスレーブ主装置として再接続する。こうすることで、通信復旧後、ネットワークは自動的に統合され、障害前と同様の状態で稼動を継続することができる。
【０１６７】
図１８、図１９及び図２０に実施形態４の概念図を示す。
【０１６８】
図１８のように、集中管理ネットワーキングでは、マスターとなる主装置がスレーブとなる主装置のリソースを一元管理し、制御を行っていた。このため、マスター主装置がダウンした場合、制御を行う主装置が存在しなくなってしまい、そのため、実施形態２及び実施形態３にて示したように、代理のマスターを選出し、稼動を継続する仕組みを発明した（図１９）。実施形態４では、図２０に示すとおり、本来のマスター主装置が復旧したとき、ネットワークを再構築し、当初の通りの運用を継続することができる仕組みについて詳述する。
【０１６９】
図２１に概念図を示す。Ｆａｉｌ−Ｏｖｅｒ（障害時の代替マスター主装置の選出とネットワーク再構成）が起き、代理のマスター主装置を中心とするネットワークが形成されたとき、代理のマスター主装置は、あらかじめ設定された本来のマスター主装置のＩＰアドレスを取得し、本来のマスター主装置（以後、これを「最優先マスター主装置」という。）の復帰を監視する機能を走らせる。
【０１７０】
最優先マスターのＩＰアドレスについては、あらかじめ最優先マスター自身に自分のＩＰアドレスを設定しておけば、自動的にそのデータは各ノード（主装置）に伝達され、同期が取られるのでＦａｉｌ−Ｏｖｅｒが起きた後、そのＩＰアドレスを元に最優先マスター主装置の復帰を監視すればいい。
【０１７１】
図２２にマスター復帰を監視するタスク構成について概念図を示す。
【０１７２】
代理マスター主装置となった主装置は、代理マスター主装置として稼動を開始するとき、自分自身のＩＰアドレスと最優先マスターのＩＰアドレスを比較し、一致していなければ自分自身が代理マスター主装置であることを判断し、最優先マスター主装置の復帰を監視するタスクを起動する。このタスクは低い優先順位で定周期に動作し、最優先マスターのＩＰアドレスに対し、接続を試行する単一の作業を試行し続けるものである。
【０１７３】
この間、マスター主装置としてスレーブ主装置を制御するタスク等は通常通り動作し、最優先マスター主装置の復帰を監視しながら、通常通りマスター主装置としてスレーブ主装置を制御し、ネットワーキングを稼動し続けることができる。
【０１７４】
図２３に最優先マスター主装置が復旧し、それを代理マスター主装置が検出した場合の動作についての概念図を示す。
【０１７５】
最優先マスター主装置監視タスクによって、最優先マスター主装置の復旧が検出できたとき、代理マスター主装置は自身をスレーブ主装置とし、また、スレーブ主装置を制御するマスター主装置を、代理のマスター主装置から最優先マスター主装置に変更するための動作を始める。
【０１７６】
図２３に示すように、まず、自分自身をマスター主装置からスレーブ主装置に遷移させ、最優先マスター主装置に接続しなおす。
【０１７７】
このとき、最優先マスター主装置監視タスク、呼制御タスクはもはや不要なので削除し、スレーブ制御タスクをマスター通信タスクに切り替える。そしてハードウェア制御タスクを生成し、自分自身がスレーブ主装置として動作するように動作モードを切り替える。そして、自分自身の配下であったスレーブに対し、最優先マスター主装置のＩＰアドレスを通知し、接続先を最優先マスター主装置に切り替えるよう指示を行い、自分自身も最優先マスター主装置にスレーブ主装置に接続する。
【０１７８】
指示を受けたスレーブ主装置は代理のマスター主装置から最優先マスター主装置に接続しなおし、最優先マスター主装置による制御を受けるよう動作を切り替える。
【０１７９】
以上の動作によって、代理マスター主装置及びその配下のスレーブ主装置は、最優先マスター主装置に再接続し、Ｆａｉｌ−Ｏｖｅｒ前の接続状態に戻ることができる。これによって、ネットワーク復旧後、速やかに運用状態を回復させることができる。
【０１８０】
ここで、図２４に示すようなネットワーク構成を考える。
【０１８１】
黒点は、ルーターなどの、ネットワーク間を相互接続する通信機器を示しているものとする。
【０１８２】
図２５に示すようなネットワーク間での通信障害が発生したとき、実施形態２及び実施形態３では、通信可能なノード間で最大のネットワークを構成するようネットワークを再構築する方法を提示した。これによって図の×印で示されるネットワーク間での通信障害が発生した場合、図の２つの楕円で示したようなネットワークをそれぞれに構成し、各々のマスター主装置を中心として限定的ではあるが、ネットワークとして稼動することができた。
【０１８３】
実施形態４により、ネットワーク間での障害が復旧したとき、先の図２２、図２３で示した方法を使うことで、下部の孤立したネットワークは、上部のマスター主装置の復旧を検出することができ、当初の図２４で示した接続状態を復旧できる。これによって、障害時に限定されたネットワークで稼動しつつ、障害復旧時には完全なネットワークでの接続も復旧できる。
【０１８４】
図２４において、黒点はルーターなどのネットワーク間を相互接続する接続機器を表している。異なるネットワークをルーターで相互接続し、マスターとなる主装置が全ノードの情報を一元管理し、ネットワーキングを実現している。そのため、ネットワーク間での通信に障害が発生した場合、図２５に示すように同一ネットワークで最大の構成をとるようＦａｉｌ−Ｏｖｅｒ機能が動作する。
【０１８５】
図２４にて示したネットワーク構成において、ネットワーク間の通信上に障害が発生した場合、Ｆａｉｌ−Ｏｖｅｒ機能によって、図２５に示したように、分断されたネットワークにおいて最大の通信が行えるよう代理のマスター主装置を選出し、ネットワークの再構成が行われる。代理のマスター主装置となった主装置は、代理マスター主装置として稼動を開始した時点から図２２に示す最優先マスター主装置監視タスクを稼動させ、最優先マスターの復旧を監視し始める。
【０１８６】
最優先マスター主装置又はネットワークが復旧したとき、最優先マスター主装置からの応答を受け取ることができるようになるので、それをもって障害復旧を判断し、復旧のための動作を始める。
【０１８７】
代理マスター主装置の配下で稼動しているスレーブ主装置は、制御を受けるマスター主装置が交代するので、代理マスター主装置は、代理マスター主装置の配下のスレーブに対し、マスター主装置の変更と新しいマスター主装置のＩＰアドレスを通知する。
【０１８８】
スレーブ主装置としては基本的にそれまでどおりスレーブ主装置として稼動するだけであり、接続先が変わるだけであるのでこの際、特別な処理は必要としない。しかし、マスター主装置がスレーブ主装置になるとき、代理マスター主装置として動作するための各種タスクの停止と、スレーブタスクへの移行、そしてマスター主装置として一元管理していた各種リソースの開放が必要である。ここで、リソースの開放に関する説明を行う。
【０１８９】
図５に示したように、集中管理ネットワーキングでは、ネットワークに接続するノードのリソースをマスター主装置となる主装置で一元管理する方法をとっている。
【０１９０】
そのため、マスターの役割を終えたとき、これらのリソースの管理状態のクリアを行う。
【０１９１】
これらのタスク、リソースのクリアを行った後、代理マスター主装置はスレーブ主装置に移行し、最優先マスター主装置に再接続し、制御を受けることになる。代理マスター主装置としての状態は内部的にクリアされるので、システムを物理的にリセットする必要はなく、迅速な復旧動作が可能になる。
【０１９２】
以上の処理によって、完全に障害前の状態に迅速に復旧し、稼動を継続することができる。
【０１９３】
本実施形態を適用することで、障害復旧を自動的に感知し、元の運用状態に戻すことが可能になる。また、常に障害復旧を監視し、迅速に復旧処理を行うことができるため、常に最適な状態で運用するシステムを構築することが可能になる。
【０１９４】
なお、復旧処理においては、システムの物理的なリセットは必要ないが、タスクの切り替え、接続先変更に伴い、端末・回線を制御するパッケージをリセットする必要があり、そのため通話状態等をそのまま継続することはできない。そのため、復旧処理を自動で行うのではなく、システムがアイドル状態のときに手動で行うことも必要である。また、システムの状態を監視し、復旧を検出し、かつアイドルとなったときに復旧処理を行う方法も考えられる。
【０１９５】
［実施形態５］
実施形態１では、分散型のネットワーキングシステムの問題を回避するため、集中管理方式のネットワーキングの方式を参考形態したことで、従来から抱える問題点の多くを解決した。
【０１９６】
すなわち、リソース集中管理方式のネットワーキングを発明したことで、情報の管理が容易になり、機能制限のないネットワーキングを実現することができた。しかし、一台の主装置に処理が集中することになってしまい、ＣＰＵの負担が増し、多くのリソースを制御できないことがネックとなる。すなわち、ネットワーク上のすべてのシステムを一台のマスター主装置が制御することになり、マスター主装置には、膨大な負荷が集中することとなってしまっていた。
【０１９７】
そこで、実施形態５は、高いパフォーマンスを有するパーソナルコンピュータ（以下、「ＰＣ」という。）上のＣＰＵを利用してのネットワーキングを実現し、膨大なトラフィックのかかるマスター主装置の負荷低減と、外部アプリケーションとの親和性を向上させることを目的とする。
【０１９８】
実施形態５では、マスター主装置となるシステムとして、交換機ではなく、高性能な汎用ＰＣを利用することで上記の問題を回避する。すなわち、ＰＣ上で交換機と同様のプログラムを実行させ、各主装置とＰＣをＩＰ網で接続する。スレーブ主装置として接続された主装置のハードウェアをマスター主装置としてのＰＣにより制御する。
【０１９９】
こうすることで、ＰＣのもつ高性能なＣＰＵを利用することが可能となり、スレーブ主装置からの膨大なトラフィックを処理することができるようになる。
【０２００】
図２６にＰＣをマスター主装置としたリソース集中管理方式のネットワーキングの概念図を示す。
【０２０１】
図２６ではＰＣをマスター主装置として稼動させ、実主装置をスレーブ主装置として制御することをあらわしている。
【０２０２】
ここで、ＰＣは当然、交換機のハードウェアを直接制御できないので、それらの制御は、接続される各スレーブ主装置が行う。
【０２０３】
このことを図２７を用いて説明する。
【０２０４】
図２７のパッケージ管理方式は、参考形態を応用している。
【０２０５】
実際のハードウェアであるパッケージは、スレーブ主装置であるシステムＩＤ２、３、４にインストールされるが、それらの情報はすべてマスター主装置であるシステムＩＤ１に送られ、管理される。
【０２０６】
また、パッケージに接続する端末、回線などの情報もすべてマスター主装置に上りデータとしてあがってくる。
【０２０７】
このようにすることで、マスター主装置から見ると、パッケージを収容する能力がないにも関わらず、あたかも自分自身にパッケージがインストールされているかのように見える。
【０２０８】
また、実際のパッケージに対する指示は、各々のシステムのパッケージに転送し、端末、回線などを制御する。
【０２０９】
このようにすることで、パッケージを直接制御できない汎用のＰＣでも交換機を制御することが可能となり、また、高性能なＣＰＵを利用できるため、多数のスレーブ主装置を接続した場合でもトラフィックに耐えることができる。
【０２１０】
これにより、リソース集中管理によるネットワーキングの問題点が緩和され、より規模の大きなネットワーキングを構築することができる。
【０２１１】
また、リソース集中管理方式のネットワーキングでは、マスター主装置が何らかの理由でダウンしたり、通信が途切れたときに、代理のマスター主装置を選出して運用を継続する仕組みを導入している。
【０２１２】
図２６の仕組みでは、マスター主装置であるＰＣがダウンすると、ＰＣがネットワークに接続していないため、スレーブ主装置として接続している主装置の中で、あらかじめ設定されたマスター主装置候補優先順位の最も高い主装置がマスター主装置となってしまい、結果、ＣＰＵ能力の低いノードがマスター主装置となってしまう。
【０２１３】
これを防ぐために代理マスター主装置となるＰＣを待機させ、障害発生時に稼動させる仕組みを導入する。
【０２１４】
図２８に実施例を示す。
【０２１５】
図２８では、図２６で示したネットワークに新たにスレーブ主装置としてＰＣを参加させていることを示している。
【０２１６】
マスター主装置であるシステム１が正常に稼動している間は、接続されたシステムＩＤ５のＰＣは特に稼動せず、待機している。そしてマスター主装置に障害が発生したとき、それを検出し、システムＩＤ５のＰＣは代理のマスター主装置として稼動を開始する。こうすることで、図２９に示すようにマスター主装置であるＰＣで障害が発生しても、同様のＣＰＵ性能を持つＰＣがマスター主装置を引き継ぐことができて、トラフィック処理能力を下げるのを防ぐことができる。また、障害から復帰したとき、図３０に示すようにシステム１はスレーブ主装置としてシステム５に接続し、障害に備え待機する。そして、システム５に障害が発生したときは、システムＩＤ１のＰＣを再度マスター主装置として稼動を開始する。
【０２１７】
こうすることで、どちらかのＰＣが稼動していればＰＣをマスター主装置としてネットワークを稼動させることができる。
【０２１８】
システム２、３、４は、パッケージをインストールするスロットを持つ実際の主装置であり、それぞれ、端末、公衆回線、ＩＰネットワークと接続するパッケージを収容している。これらは、スレーブ主装置として稼動しており、システム１でマスター主装置として稼動しているＰＣにＩＰで接続し、制御を受けている。
【０２１９】
システム１のマスター主装置として稼動しているＰＣは、システム２、３、４のパッケージなどのハードウェア情報、呼状態などの情報などを一括して管理し、接続する全スレーブ主装置の呼制御を行う。
【０２２０】
また、システム５は、スレーブ主装置としてシステム１に接続し、障害時のためにシステム１を監視、待機している。
【０２２１】
次に、具体的な実現方法について説明を加える。
【０２２２】
パッケージのリソース管理に関する方法は、参考形態で説明した通りである。
【０２２３】
ここでは、それ以外の、マスター主装置としてＰＣを利用するための方法について述べる。
【０２２４】
図３１に、従来の実主装置をマスター主装置とした場合のネットワーキングの概念図を示す。
【０２２５】
本発明における機能モジュールを大まかに分けると、着信や通話などの制御を行う呼制御部、マスター主装置−スレーブ主装置間で、パッケージデータの送受信などを行う、通信部、パッケージからのデータを受信したり、パッケージに指示を行うハードウェア制御部となる。
【０２２６】
図３１では、マスター主装置となる主装置のみ呼制御部が動作しており、スレーブ主装置は呼制御を行っていない。
【０２２７】
スレーブ主装置は、ハードウェア制御部にてパッケージからデータを受信し、通信部にてマスター主装置にデータを送信する。
【０２２８】
マスター主装置は呼制御部にてそのデータをもとに呼制御を行い、折り返し、通信部でパッケージデータを送信し、スレーブ主装置はそのデータを受け取りハードウェアを制御する。
【０２２９】
また、マスター主装置自身にもパッケージを収容するスロットが存在するのでハードウェア制御部が稼動し、パッケージを制御する。
【０２３０】
図３２に、本実施形態における機能モジュールの概念図を示す。
【０２３１】
マスター主装置は汎用のＰＣであるため、当然、直接パッケージを収容できないので、ハードウェア制御部は不要である。
【０２３２】
また、不要であるだけではなく、存在しないハードウェアを制御しようとするため、動作自体を禁止しなければならない。
【０２３３】
したがって、実装すべきモジュールは、図の通り、呼制御部、通信部のみとなるため、処理的にターゲットに依存せず、ＰＣ上でも実装が可能となる。
【０２３４】
また、マスター主装置−スレーブ主装置間は、ＴＣＰ／ＩＰを用いて通信を行うため、処理的に同等であれば、マスター主装置−スレーブ主装置間でＯＳが同一である必要はない。たとえば、ＰＣ上ではＬｉｎｕｘ（登録商標）、実主装置上ではＶｘＷｏｒｋｓ（登録商標）やＮｕｃｌｅｕｓ Ｐｌｕｓなどの組み込み用ＯＳを搭載することが可能である。
【０２３５】
なお、図の通り、スレーブ主装置となる主装置は、基本的に通信部とハードウェア制御部しか動作していない。
【０２３６】
したがって、マスター主装置のＰＣには高性能なＣＰＵが必要であるが、スレーブ主装置となる主装置には安価なＣＰＵで十分といえる。また、同様にすべてのリソース管理がマスター主装置に集中するため、マスター主装置となるＰＣは多くのメモリリソースが必要であるが、スレーブ主装置となる主装置は、リソース管理を一切行わないため、非常に少ないメモリリソースで動作が可能である。
【０２３７】
なお、リソース集中管理方式のネットワーキングでは、マスター主装置がダウンしたときにあらかじめ設定されたマスター主装置優先順位の高いものから代理マスター主装置を選出し、運用を継続する機能があるが、貧弱なＣＰＵとメモリしか有しない実主装置が代理マスター主装置に選出されることがないよう、実主装置には低い優先順位を割り当て、バックアップのＰＣに高い優先順位を割り当てる必要がある。
【０２３８】
実施形態５を適用することで、高性能なＣＰＵを持つシステムをマスター主装置とすることが可能となり、より規模の大きなネットワーキングを構築することが可能となる。
【０２３９】
また、ＰＣ上で主装置のソフトを実行可能になることで、ＰＣと主装置の親和性が高まり、アプリケーション連携、たとえばＣＴＩ(Computer Telephony Integration)などを行うことが容易となる。
【０２４０】
［実施形態６］
実施形態６では、より具体的な構成について説明をする。
【０２４１】
図３３は、従来例による主装置群を示す。図３３を参照すると、従来例によれば、主装置群に含まれる主装置は、マスター主装置とスレーブ主装置に分類されない。各主装置は独自に動作し、ＶｏＩＰインターフェース２０１を介してＩＰネットワーク２０３により接続されている。各主装置には、ＣＡＰＳ／ＯＰＭＳ１０５、ＩＯＣＳ１０３、スロットＩ／Ｆ１０１が含まれているが、スロット管理モジュール１０９、物理スロット／仮想スロット対照表１１１、スロット制御モジュール１０７は含まれていない。
【０２４２】
図３４は、本発明の実施形態による主装置群を示す。図３４を参照すると、本発明の実施形態によれば、主装置群に含まれる主装置は、１つのマスター主装置２１１と複数のスレーブ主装置２１３に分類される。１つのマスター主装置２１１と複数のスレーブ主装置２１３は、ＶｏＩＰインターフェース２１５を介してＩＰネットワーク２１７により接続されている。複数のスレーブ主装置２１３は、１つのマスター主装置２１１の制御の下で動作する。マスター主装置２１１は、ＣＡＰＳ／ＯＰＭＳ１０５、ＩＯＣＳ１０３、スロット管理モジュール１０９、物理スロット／仮想スロット対照表１１１、スロットＩ／Ｆモジュール１０１を含む。各スレーブ主装置２１３は、スロット制御モジュール１０７、スロットＩ／Ｆ１０１を含む。
【０２４３】
図３５は、主装置の外観例を示す。主装置は、物理スロットを複数有し、物理スロットにパッケージが挿入されるようになっている。
【０２４４】
図３６は、パッケージの外観例を示す。パッケージには、物理スロットのバックボードコネクタ３０１（図３５参照）と接続されるコネクタ３０３、外線やＰＢＸ内線と接続されるコネクタ３０５を有する。
【産業上の利用可能性】
【０２４５】
本発明によれば、単一の主装置が、ネットワークにつながる全ての主装置のハードウェアのリソース等の情報を一元管理することができる。
【符号の説明】
【０２４６】
１０１ システムインターフェース
１０３ ＩＯＣＳ（入出力制御モジュール）
１０５ ＣＡＰＳ（呼制御モジュール）／ＯＰＭＳ（パッケージ、端末管理モジュール）
１０７ スロット制御モジュール
１０９ スロット管理モジュール
１１１ 物理スロット／管理スロット対照表
【特許請求の範囲】
【請求項１】
入出力制御モジュールとその下位のスロットインターフェースとの間に、スロット管理モジュール、スロット制御モジュール及び物理スロット／管理スロット対照表を備え、
前記入出力制御モジュールは、仮想スロット識別情報を用いて前記スロットインターフェースにアクセスし、
前記スロット管理モジュールが、前記物理スロット／管理スロット対照表を参照して、仮想スロット識別情報を物理スロット識別情報に変換し、変換により得られた物理スロット識別情報に対応するスロット制御モジュールにアクセスすることにより、前記入出力制御モジュールによる前記スロットインターフェースへの物理的なアクセスが実現されることを特徴とするスロットインターフェースアクセス装置。
【請求項２】
請求項１に記載のスロットインターフェースアクセス装置において、
前記スロットインターフェース及び前記スロット制御モジュールは、複数の主装置に分散して存在することを特徴とするスロットインターフェースアクセス装置。
【請求項３】
入出力制御モジュールとその下位のスロットインターフェースとの間に、スロット管理モジュール、スロット制御モジュール及び物理スロット／管理スロット対照表を設け、
前記入出力制御モジュールは、仮想スロット識別情報を用いて前記スロットインターフェースにアクセスし、
前記スロット管理モジュールが、前記物理スロット／管理スロット対照表を参照して、仮想スロット識別情報を物理スロット識別情報に変換し、変換により得られた物理スロット識別情報に対応するスロット制御モジュールにアクセスすることにより、前記入出力制御モジュールによる前記スロットインターフェースへの物理的なアクセスが実現されることを特徴とするスロットインターフェースアクセス方法。
【請求項４】
請求項３に記載のスロットインターフェースアクセス方法において、
前記スロットインターフェース及び前記スロット制御モジュールは、複数の主装置に分散して存在することを特徴とするスロットインターフェースアクセス方法。
【請求項５】
請求項１又は２に記載のスロットインターフェースアクセス装置としてコンピュータを機能させるためのプログラム。
【請求項６】
請求項１又は２に記載のスロットインターフェースアクセス装置を有した複数の主装置を備え、そのうち１つの主装置がマスター主装置であり、他の主装置がスレーブ主装置であり、
前記マスター主装置が機能不全となった場合、前記スレーブ主装置のうちの１つのスレーブ主装置が新たなマスター主装置となり、
各主装置には優先順位が付けられており、現在のマスター主装置が機能不全となった場合、他の主装置のうち優先順位が最も高い主装置が新たなマスター主装置となるものとし、
各主装置は、他の全ての主装置に優先順位の問合せ信号を総当り方式で送信し、該信号に対する返信で得た優先順位と主装置自身の優先順位とを比較し、主装置自身の優先順位が他の全ての主装置の優先順位よりも高い場合に、主装置自身がマスター主装置となり、他の主装置からの問合せに対し、主装置自身がマスター主装置である旨を通知し、
各主装置は、新たな主装置からその主装置がマスター主装置である旨の通知を受けたならば、主装置自身はスレーブ主装置であると認識することを特徴とする主装置の冗長構成。
【請求項７】
請求項６に記載の主装置の冗長構成において、
マスター主装置が保有しているシステムデータを他の主装置であるスレーブ主装置も保有するようにしたことを特徴とする主装置の冗長構成。
【請求項８】
請求項６又は７に記載の主装置の冗長構成において、
端末とマスター主装置との間の通信がスレーブ主装置を経由することを特徴とする主装置の冗長構成。
【請求項９】
請求項６乃至８の何れか１項に記載の主装置の冗長構成において、
前記新たなマスター主装置は、機能不全となったマスター主装置が回復したか否かを監視し、
機能不全となったマスター主装置が回復した時に、新たなマスター主装置は、回復したマスター主装置にシステム全体の制御権を戻すことを特徴とする主装置の冗長構成。
【請求項１０】
請求項９に記載の主装置の冗長構成において、
前記新たなマスター主装置は、機能不全となったマスター主装置に問い合わせをし、それに対する応答を機能不全となったマスター主装置から得られた場合に、機能不全となったマスター主装置が回復したと判断することを特徴とする主装置の冗長構成。
【請求項１１】
請求項１又は２に記載のスロットインターフェースアクセス装置を有した複数の主装置を備え、そのうち１つの主装置がマスター主装置であり、他の主装置がスレーブ主装置であり、
前記マスター主装置が機能不全となった場合、前記スレーブ主装置のうちの１つのスレーブ主装置が新たなマスター主装置となり、
各主装置には優先順位が付けられており、現在のマスター主装置が機能不全となった場合、他の主装置のうち優先順位が最も高い主装置が新たなマスター主装置となるものとし、
各主装置は、他の全ての主装置に優先順位の問合せ信号を総当り方式で送信し、該信号に対する返信で得た優先順位と主装置自身の優先順位とを比較し、主装置自身の優先順位が他の全ての主装置の優先順位よりも高い場合に、主装置自身がマスター主装置となり、他の主装置からの問合せに対し、主装置自身がマスター主装置である旨を通知し、
各主装置は、新たな主装置からその主装置がマスター主装置である旨の通知を受けたならば、主装置自身はスレーブ主装置であると認識することを特徴とする主装置の代替方法。
【請求項１２】
請求項１１に記載の主装置の代替方法において、
マスター主装置が保有しているシステムデータを他の主装置であるスレーブ主装置も保有するようにしたことを特徴とする主装置の代替方法。
【請求項１３】
請求項１１又は１２に記載の主装置の代替方法において、
端末とマスター主装置との間の通信がスレーブ装置を経由することを特徴とする主装置の代替方法。
【請求項１４】
請求項１１乃至１３の何れか１項に記載の主装置の代替方法において、
前記新たなマスター主装置は、機能不全となったマスター主装置が回復したか否かを監視し、
機能不全となったマスター主装置が回復した時に、新たなマスター主装置は、回復したマスター主装置にシステム全体の制御権を戻すことを特徴とする主装置の代替方法。
【請求項１５】
請求項１４に記載の主装置の代替方法において、
前記新たなマスター主装置は、機能不全となったマスター主装置に問い合わせをし、それに対する応答を機能不全となったマスター主装置から得られた場合に、機能不全となったマスター主装置が回復したと判断することを特徴とする主装置の代替方法。
【請求項１６】
入出力制御モジュールとその下位のスロットインターフェースとの間に、スロット管理モジュール、スロット制御モジュール及び物理スロット／管理スロット対照表を備え、
前記入出力制御モジュールは、仮想スロット識別情報を用いて前記スロットインターフェースにアクセスし、
前記スロット管理モジュールが、前記物理スロット／管理スロット対照表を参照して、仮想スロット識別情報を物理スロット識別情報に変換し、変換により得られた物理スロット識別情報に対応するスロット制御モジュールにアクセスすることにより、前記入出力制御モジュールによる前記スロットインターフェースへの物理的なアクセスが実現されることを特徴とするスロットインターフェースアクセス装置であって、
当該装置は、スロットインターフェースを有する他の装置よりもＣＰＵ能力が高いことを特徴とするスロットインターフェースアクセス装置。
【請求項１７】
請求項１６に記載のスロットインターフェースアクセス装置において、
当該装置は、前記スロットインターフェースを備えないことを特徴とするスロットインターフェースアクセス装置。
【請求項１８】
請求項１６又は１７に記載のスロットインターフェースアクセス装置と、当該スロットインターフェースアクセス装置が機能不全となった場合に、当該スロットインターフェースアクセス装置の代理をするスロットインターフェースアクセス装置であって、ＣＰＵ能力が、他の装置のＣＰＵ能力よりも高いものとを備えることを特徴とするスロットインターフェースアクセス装置群。
【請求項１９】
入出力制御モジュールとその下位のスロットインターフェースとの間に、スロット管理モジュール、スロット制御モジュール及び物理スロット／管理スロット対照表を備え、
前記入出力制御モジュールは、仮想スロット識別情報を用いて前記スロットインターフェースにアクセスし、
前記スロット管理モジュールが、前記物理スロット／管理スロット対照表を参照して、仮想スロット識別情報を物理スロット識別情報に変換し、変換により得られた物理スロット識別情報に対応するスロット制御モジュールにアクセスすることにより、前記入出力制御モジュールによる前記スロットインターフェースへの物理的なアクセスが実現されることを特徴とするスロットインターフェースアクセス方法であって、
当該方法は、スロットインターフェースを有する他の装置よりもＣＰＵ能力が高い装置により行われることを特徴とするスロットインターフェースアクセス方法。
【請求項２０】
請求項１９に記載のスロットインターフェースアクセス方法において、
当該方法を行う装置は、前記スロットインターフェースを備えないことを特徴とするスロットインターフェースアクセス方法。
【請求項２１】
請求項１９又は２０に記載のスロットインターフェースアクセス方法を行う装置が機能不全となった場合に、ＣＰＵ能力が、他の装置のＣＰＵ能力よりも高い装置が代理で当該方法を行うことを特徴とするスロットインターフェースアクセス方法。
【請求項２２】
コンピュータを請求項１６又は１７に記載のスロットインターフェースアクセス装置として機能させるためのプログラム。
【請求項１】
入出力制御モジュールとその下位のスロットインターフェースとの間に、スロット管理モジュール、スロット制御モジュール及び物理スロット／管理スロット対照表を備え、
前記入出力制御モジュールは、仮想スロット識別情報を用いて前記スロットインターフェースにアクセスし、
前記スロット管理モジュールが、前記物理スロット／管理スロット対照表を参照して、仮想スロット識別情報を物理スロット識別情報に変換し、変換により得られた物理スロット識別情報に対応するスロット制御モジュールにアクセスすることにより、前記入出力制御モジュールによる前記スロットインターフェースへの物理的なアクセスが実現されることを特徴とするスロットインターフェースアクセス装置。
【請求項２】
請求項１に記載のスロットインターフェースアクセス装置において、
前記スロットインターフェース及び前記スロット制御モジュールは、複数の主装置に分散して存在することを特徴とするスロットインターフェースアクセス装置。
【請求項３】
入出力制御モジュールとその下位のスロットインターフェースとの間に、スロット管理モジュール、スロット制御モジュール及び物理スロット／管理スロット対照表を設け、
前記入出力制御モジュールは、仮想スロット識別情報を用いて前記スロットインターフェースにアクセスし、
前記スロット管理モジュールが、前記物理スロット／管理スロット対照表を参照して、仮想スロット識別情報を物理スロット識別情報に変換し、変換により得られた物理スロット識別情報に対応するスロット制御モジュールにアクセスすることにより、前記入出力制御モジュールによる前記スロットインターフェースへの物理的なアクセスが実現されることを特徴とするスロットインターフェースアクセス方法。
【請求項４】
請求項３に記載のスロットインターフェースアクセス方法において、
前記スロットインターフェース及び前記スロット制御モジュールは、複数の主装置に分散して存在することを特徴とするスロットインターフェースアクセス方法。
【請求項５】
請求項１又は２に記載のスロットインターフェースアクセス装置としてコンピュータを機能させるためのプログラム。
【請求項６】
請求項１又は２に記載のスロットインターフェースアクセス装置を有した複数の主装置を備え、そのうち１つの主装置がマスター主装置であり、他の主装置がスレーブ主装置であり、
前記マスター主装置が機能不全となった場合、前記スレーブ主装置のうちの１つのスレーブ主装置が新たなマスター主装置となり、
各主装置には優先順位が付けられており、現在のマスター主装置が機能不全となった場合、他の主装置のうち優先順位が最も高い主装置が新たなマスター主装置となるものとし、
各主装置は、他の全ての主装置に優先順位の問合せ信号を総当り方式で送信し、該信号に対する返信で得た優先順位と主装置自身の優先順位とを比較し、主装置自身の優先順位が他の全ての主装置の優先順位よりも高い場合に、主装置自身がマスター主装置となり、他の主装置からの問合せに対し、主装置自身がマスター主装置である旨を通知し、
各主装置は、新たな主装置からその主装置がマスター主装置である旨の通知を受けたならば、主装置自身はスレーブ主装置であると認識することを特徴とする主装置の冗長構成。
【請求項７】
請求項６に記載の主装置の冗長構成において、
マスター主装置が保有しているシステムデータを他の主装置であるスレーブ主装置も保有するようにしたことを特徴とする主装置の冗長構成。
【請求項８】
請求項６又は７に記載の主装置の冗長構成において、
端末とマスター主装置との間の通信がスレーブ主装置を経由することを特徴とする主装置の冗長構成。
【請求項９】
請求項６乃至８の何れか１項に記載の主装置の冗長構成において、
前記新たなマスター主装置は、機能不全となったマスター主装置が回復したか否かを監視し、
機能不全となったマスター主装置が回復した時に、新たなマスター主装置は、回復したマスター主装置にシステム全体の制御権を戻すことを特徴とする主装置の冗長構成。
【請求項１０】
請求項９に記載の主装置の冗長構成において、
前記新たなマスター主装置は、機能不全となったマスター主装置に問い合わせをし、それに対する応答を機能不全となったマスター主装置から得られた場合に、機能不全となったマスター主装置が回復したと判断することを特徴とする主装置の冗長構成。
【請求項１１】
請求項１又は２に記載のスロットインターフェースアクセス装置を有した複数の主装置を備え、そのうち１つの主装置がマスター主装置であり、他の主装置がスレーブ主装置であり、
前記マスター主装置が機能不全となった場合、前記スレーブ主装置のうちの１つのスレーブ主装置が新たなマスター主装置となり、
各主装置には優先順位が付けられており、現在のマスター主装置が機能不全となった場合、他の主装置のうち優先順位が最も高い主装置が新たなマスター主装置となるものとし、
各主装置は、他の全ての主装置に優先順位の問合せ信号を総当り方式で送信し、該信号に対する返信で得た優先順位と主装置自身の優先順位とを比較し、主装置自身の優先順位が他の全ての主装置の優先順位よりも高い場合に、主装置自身がマスター主装置となり、他の主装置からの問合せに対し、主装置自身がマスター主装置である旨を通知し、
各主装置は、新たな主装置からその主装置がマスター主装置である旨の通知を受けたならば、主装置自身はスレーブ主装置であると認識することを特徴とする主装置の代替方法。
【請求項１２】
請求項１１に記載の主装置の代替方法において、
マスター主装置が保有しているシステムデータを他の主装置であるスレーブ主装置も保有するようにしたことを特徴とする主装置の代替方法。
【請求項１３】
請求項１１又は１２に記載の主装置の代替方法において、
端末とマスター主装置との間の通信がスレーブ装置を経由することを特徴とする主装置の代替方法。
【請求項１４】
請求項１１乃至１３の何れか１項に記載の主装置の代替方法において、
前記新たなマスター主装置は、機能不全となったマスター主装置が回復したか否かを監視し、
機能不全となったマスター主装置が回復した時に、新たなマスター主装置は、回復したマスター主装置にシステム全体の制御権を戻すことを特徴とする主装置の代替方法。
【請求項１５】
請求項１４に記載の主装置の代替方法において、
前記新たなマスター主装置は、機能不全となったマスター主装置に問い合わせをし、それに対する応答を機能不全となったマスター主装置から得られた場合に、機能不全となったマスター主装置が回復したと判断することを特徴とする主装置の代替方法。
【請求項１６】
入出力制御モジュールとその下位のスロットインターフェースとの間に、スロット管理モジュール、スロット制御モジュール及び物理スロット／管理スロット対照表を備え、
前記入出力制御モジュールは、仮想スロット識別情報を用いて前記スロットインターフェースにアクセスし、
前記スロット管理モジュールが、前記物理スロット／管理スロット対照表を参照して、仮想スロット識別情報を物理スロット識別情報に変換し、変換により得られた物理スロット識別情報に対応するスロット制御モジュールにアクセスすることにより、前記入出力制御モジュールによる前記スロットインターフェースへの物理的なアクセスが実現されることを特徴とするスロットインターフェースアクセス装置であって、
当該装置は、スロットインターフェースを有する他の装置よりもＣＰＵ能力が高いことを特徴とするスロットインターフェースアクセス装置。
【請求項１７】
請求項１６に記載のスロットインターフェースアクセス装置において、
当該装置は、前記スロットインターフェースを備えないことを特徴とするスロットインターフェースアクセス装置。
【請求項１８】
請求項１６又は１７に記載のスロットインターフェースアクセス装置と、当該スロットインターフェースアクセス装置が機能不全となった場合に、当該スロットインターフェースアクセス装置の代理をするスロットインターフェースアクセス装置であって、ＣＰＵ能力が、他の装置のＣＰＵ能力よりも高いものとを備えることを特徴とするスロットインターフェースアクセス装置群。
【請求項１９】
入出力制御モジュールとその下位のスロットインターフェースとの間に、スロット管理モジュール、スロット制御モジュール及び物理スロット／管理スロット対照表を備え、
前記入出力制御モジュールは、仮想スロット識別情報を用いて前記スロットインターフェースにアクセスし、
前記スロット管理モジュールが、前記物理スロット／管理スロット対照表を参照して、仮想スロット識別情報を物理スロット識別情報に変換し、変換により得られた物理スロット識別情報に対応するスロット制御モジュールにアクセスすることにより、前記入出力制御モジュールによる前記スロットインターフェースへの物理的なアクセスが実現されることを特徴とするスロットインターフェースアクセス方法であって、
当該方法は、スロットインターフェースを有する他の装置よりもＣＰＵ能力が高い装置により行われることを特徴とするスロットインターフェースアクセス方法。
【請求項２０】
請求項１９に記載のスロットインターフェースアクセス方法において、
当該方法を行う装置は、前記スロットインターフェースを備えないことを特徴とするスロットインターフェースアクセス方法。
【請求項２１】
請求項１９又は２０に記載のスロットインターフェースアクセス方法を行う装置が機能不全となった場合に、ＣＰＵ能力が、他の装置のＣＰＵ能力よりも高い装置が代理で当該方法を行うことを特徴とするスロットインターフェースアクセス方法。
【請求項２２】
コンピュータを請求項１６又は１７に記載のスロットインターフェースアクセス装置として機能させるためのプログラム。
【図９】
【図１０】
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図３１】
【図３２】
【図３３】
【図３４】
【図３５】
【図３６】
【図１０】
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図３１】
【図３２】
【図３３】
【図３４】
【図３５】
【図３６】
【公開番号】特開２０１３−３０１９０（Ｐ２０１３−３０１９０Ａ）
【公開日】平成２５年２月７日（２０１３．２．７）
【国際特許分類】
【出願番号】特願２０１２−２２８９５１（Ｐ２０１２−２２８９５１）
【出願日】平成２４年１０月１６日（２０１２．１０．１６）
【分割の表示】特願２００８−１３０７８０（Ｐ２００８−１３０７８０）の分割
【原出願日】平成２０年５月１９日（２００８．５．１９）
【出願人】（０００２２７２０５）ＮＥＣインフロンティア株式会社 (1,047)
【Ｆターム（参考）】
【公開日】平成２５年２月７日（２０１３．２．７）
【国際特許分類】
【出願日】平成２４年１０月１６日（２０１２．１０．１６）
【分割の表示】特願２００８−１３０７８０（Ｐ２００８−１３０７８０）の分割
【原出願日】平成２０年５月１９日（２００８．５．１９）
【出願人】（０００２２７２０５）ＮＥＣインフロンティア株式会社 (1,047)
【Ｆターム（参考）】
[ Back to top ]