(57)【特許請求の範囲】
【請求項１】
自プロセッサに収容されている端末からの呼を受け付けて制御処理する呼制御プロセッサを複数有し、自プロセッサの稼動状況に応じて、該受け付けた制御処理を他の呼制御プロセッサに依頼して端末からの呼を制御処理するマルチプロセッサ電子交換機での呼損回避方法において、
前記各々の呼制御プロセッサが、
自呼制御プロセッサに関係付けられている端末または、他呼制御プロセッサからの呼の処理要求を受け付けて実行する通常状態；
自呼制御プロセッサに関係付けられている端末からの呼の処理要求に対しては、全ての他呼制御プロセッサがフローティング依頼状態の場合には当該処理要求を受け付けて実行し、他に通常状態又はフローティング拒否状態の呼制御プロセッサが有る場合には通常状態の呼制御プロセッサ、フローティング拒否状態の呼制御プロセッサの順に処理依頼し、他呼制御プロセッサからの呼の処理要求に対しては、全て拒否するフローティング依頼状態；
自呼制御プロセッサに関係付けられている端末からの呼の処理要求に対しては他呼制御プロセッサへの処理依頼をせず、他呼制御プロセッサからの呼の処理要求に対しては、他に通常状態の呼制御プロセッサが無い場合を除いて当該処理要求を拒否するフローティング拒否状態；
の何れの稼動状態で動作しているかを取得・保持し、呼制御プロセッサによって読み出される状態保持手段を有し、
前記呼制御プロセッサが端末からの呼を受け付けるステップと、
呼を受け付けると、当該呼制御プロセッサが自身の稼動状態を取得するステップと、
自身の稼動状態に応じて他の呼制御プロセッサの稼動状態を前記状態保持手段により取得するステップと、
当該取得した自呼制御プロセッサと他呼制御プロセッサの稼動状態に応じて、当該呼の制御処理を行う呼制御プロセッサを決定するステップと、を行ない、
当該決定された前記呼制御プロセッサにおいて、前記呼制御処理することを特徴とする呼損回避方法。
【請求項２】
前記呼の制御処理を行う呼制御プロセッサを決定するステップは、
最初に受け付けた起呼信号に対してのみ行なう、請求項１記載の呼損回避方法。
【請求項３】
自プロセッサに収容されている端末からの呼を受け付けて制御処理する呼制御プロセッサを複数有し、自プロセッサの稼動状況に応じて、該受け付けた呼の制御処理を他の呼制御プロセッサに依頼して端末から呼を制御処理して呼損の回避を行うマルチプロセッサ電子交換機であって、
前記各々の呼制御プロセッサが、
自呼制御プロセッサに関係付けられている端末または、他呼制御プロセッサからの呼の処理要求を受け付けて実行する通常状態；
自呼制御プロセッサに関係付けられている端末からの呼の処理要求に対しては、全ての他呼制御プロセッサがフローティング依頼状態の場合には当該処理要求を受け付けて実行し、他に通常状態又はフローティング拒否状態の呼制御プロセッサが有る場合には通常状態の呼制御プロセッサ、フローティング拒否状態の呼制御プロセッサの順に処理依頼し、他呼制御プロセッサからの呼の処理要求に対しては、全て拒否するフローティング依頼状態；
自呼制御プロセッサに関係付けられている端末からの呼の処理要求に対しては他呼制御プロセッサへの処理依頼をせず、他呼制御プロセッサからの呼の処理要求に対しては、他に通常状態の呼制御プロセッサが無い場合を除いて当該処理要求を拒否するフローティング拒否状態；
のいずれかの稼動状態で動作しているかを取得・保持し、呼制御プロセッサによって読み出される状態保持手段と、
前記呼制御プロセッサが端末からの呼を受け付けると、当該呼制御プロセッサが自身の稼動状態及び前記状態保持手段から取得できる他呼制御プロセッサの稼動状態に応じて、当該呼の制御処理を行う呼制御プロセッサを決定する呼制御プロセッサ判定手段と、
当該決定された前記呼制御プロセッサに対して前記呼を制御させる呼制御手段と、を有することを特徴とするマルチプロセッサ電子交換機。
【請求項４】
前記呼制御プロセッサ判定手段は、
最初に受け付けた起呼信号に対してのみ呼制御を行うプロセッサを決定する処理を行なう請求項３記載のマルチプロセッサ電子交換機。
【請求項５】
自プロセッサに収容されている端末からの呼を受け付けて制御処理する呼制御プロセッサを複数有し、自プロセッサの稼動状況に応じて、該受け付けた制御処理を他の呼制御プロセッサに依頼して端末からの呼を制御処理するマルチプロセッサ交換機に実行させる呼損回避プログラムであって、
前記請求項１乃至２記載の呼損回避方法の実現に用いられる処理を、マルチプロセッサ交換機として利用されるコンピュータに実行させることを特徴とする呼損回避プログラム。
【請求項６】
自プロセッサに収容されている端末からの呼を受け付けて制御処理する呼制御プロセッサを複数有し、自プロセッサの稼動状況に応じて、該受け付けた制御処理を他の呼制御プロセッサに依頼して端末からの呼を制御処理するマルチプロセッサ交換機に実行させる呼損回避プログラムを格納した記憶媒体であって、
前記請求項１乃至２記載の呼損回避方法の実現に用いられる処理を、マルチプロセッサ交換機として利用されるコンピュータに実行させるプログラムを格納したことを特徴とする呼損回避プログラムを格納した記憶媒体。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、呼損回避方法及びマルチプロセッサ電子交換機及び呼損回避プログラム及び呼損回避プログラムを格納した記憶媒体に係り、特に、マルチプロセッサ環境での移動体通信システムにおいて、在圏処理プロセッサの稼働率から呼制御プロセッサを決定し、特定プロセッサへの負荷集中を防いで呼損を回避するための呼損回避方法及びマルチプロセッサ電子交換機及び呼損回避プログラム及び呼損回避プログラムを格納した記憶媒体に関する。
【０００２】
【従来の技術】
従来のマルチプロセッサ電子交換機における呼損の回避方法として、例えば、特開平５−２５２５５１号（マルチプロセッサ型電子交換機の負荷分散方式）がある。この方法は、複数の通話路ネットワークとそれを専任で個別に制御するマルチプロセッサ電子交換機において、自ネットワーク内に折り返し通信路を備えた複数の通信路ネットワーク間を通話用ジャンクタで相互接続している構成において、負荷の高い呼制御プロセッサが制御するネットワークに対して発呼があった場合、当該呼制御プロセッサは、使用率が最も低い呼制御プロセッサの制御する通信路ネットワークを選択し、そのネットワークの折り返し通信路と通話用ジャンクタを介して接続する。それ以降の呼制御権を選択先ネットワークの呼制御プロセッサに委譲することにより負荷分散を図っている。
【０００３】
図１１は、従来のマルチプロセッサ型電子交換機の負荷分散方式を説明するための図である。
【０００４】
同図に示すマルチプロセッサ型電子交換機は、各々の通信路ネットワーク（ＮＷ）１２ａ〜１２ｘに自ネットワーク内に折り返し用通話路端子１７ａ〜１７ｘが設けられた構成である。
【０００５】
ある通信路端子１１ａから発呼があった場合には、当該通話路端子１１ａを収容しているネットワークとは無関係に当該時点での使用率が最も低い呼制御プロセッサ（ＣＬＰ−Ｘ）１３ｘに属するＮＷ１２ｘに収容された折り返し通話路端子１７ｘを選択する。実際に発呼した通話路端末１１ａと折り返し通話路端子１７ｘの一方の端子をジャンクタ１４を介して接続する。以降は、折り返し通話路端子１７ｘを収容する呼制御プロセッサＣＬＰ−Ｘ１３ｘに当該呼に関する呼制御権を付与する。これにより、交換機システム内の各呼制御プロセッサの使用率を自動的に均一化することができる。
【０００６】
【発明が解決しようとする課題】
上記従来のマルチプロセッサ型電子交換機は、使用率の最も低い呼制御プロセッサに呼制御をさせる。つまり、使用率の最も低い呼制御プロセッサをＣＬＰ１とすると、当該呼制御プロセッサＣＬＰ１は、他の呼制御プロセッサＣＬＰ３が制御する通話路ネットワークへの発呼に対して、呼制御の依頼、つまり、迂回接続を受ける。図１２に示すように、使用率の最も低いＣＬＰ１は、呼制御を行うことにより、使用率が上がり、使用率が最も低い呼制御プロセッサではなくなるので、次に、ＣＬＰ１が制御する通信路ネットワークの呼に対しては、ＣＬＰ３（但し、使用率が最も低くなった場合）に呼制御を依頼することになる。結果として、ＣＬＰ１は、他のプロセッサの通話路ネットワークに対する呼制御を行うが、ＣＬＰ１の制御する通話路ネットワークの呼の制御はしないことになり、互いに呼制御を依頼し合うという無駄な迂回接続が発生してしまう問題がある。
【０００７】
さらに、上記従来のマルチプロセッサ型電子交換機では、使用率の最も低い呼制御プロセッサに呼制御を依頼（迂回接続）するために各呼制御プロセッサの使用率を記憶するための処理、最も使用率の低い呼制御プロセッサの判定処理、及び、呼の迂回接続するための専用の装置（通信路ネットワーク等）が必要となる。
【０００８】
本発明は、上記の点に鑑みなされたもので、マルチプロセッサ電子交換機において、端末から呼を受けたプロセッサ内が稼動状態を判定し、呼制御プロセッサを決定するための専用の装置を用いずに、自プロセッサで受けた呼に対しては、可能な限り自プロセッサで呼制御を行うことが可能なマルチプロセッサ電子交換機における、呼損回避方法及びマルチプロセッサ電子交換機及び呼損回避プログラム及び呼損回避プログラムを格納した記憶媒体を提供することを目的とする。
【課題を解決するための手段】
本発明（請求項１）は、自プロセッサに収容されている端末からの呼を受け付けて制御処理する呼制御プロセッサを複数有し、自プロセッサの稼動状況に応じて、該受け付けた制御処理を他の呼制御プロセッサに依頼して端末からの呼を制御処理するマルチプロセッサ電子交換機での呼損回避方法において、
各々の呼制御プロセッサが、
自呼制御プロセッサに関係付けられている端末または、他呼制御プロセッサからの呼の処理要求を受け付けて実行する通常状態；
自呼制御プロセッサに関係付けられている端末からの呼の処理要求に対しては、全ての他呼制御プロセッサがフローティング依頼状態の場合には当該処理要求を受け付けて実行し、他に通常状態又はフローティング拒否状態の呼制御プロセッサが有る場合には通常状態の呼制御プロセッサ、フローティング拒否状態の呼制御プロセッサの順に処理依頼し、他呼制御プロセッサからの呼の処理要求に対しては、全て拒否するフローティング依頼状態；
自呼制御プロセッサに関係付けられている端末からの呼の処理要求に対しては他呼制御プロセッサへの処理依頼をせず、他呼制御プロセッサからの呼の処理要求に対しては、他に通常状態の呼制御プロセッサが無い場合を除いて当該処理要求を拒否するフローティング拒否状態；
の何れの稼動状態で動作しているかを取得・保持し、呼制御プロセッサによって読み出される状態保持手段を有し、
呼制御プロセッサが端末からの呼を受け付けるステップと、
呼を受け付けると、当該呼制御プロセッサが自身の稼動状態を取得するステップと、
自身の稼動状態に応じて他の呼制御プロセッサの稼動状態を状態保持手段により取得するステップと、
当該取得した自呼制御プロセッサと他呼制御プロセッサの稼動状態に応じて、当該呼の制御処理を行う呼制御プロセッサを決定するステップと、を行ない、
当該決定された呼制御プロセッサにおいて、呼制御処理をする。
【０００９】
本発明（請求項２）は、呼の制御処理を行う呼制御プロセッサを決定するステップは、
最初に受け付けた起呼信号に対してのみ行なう。
【００１１】
本発明（請求項３）は、自プロセッサに収容されている端末からの呼を受け付けて制御処理する呼制御プロセッサを複数有し、自プロセッサの稼動状況に応じて、該受け付けた呼の制御処理を他の呼制御プロセッサに依頼して端末から呼を制御処理して呼損の回避を行うマルチプロセッサ電子交換機であって、
各々の呼制御プロセッサが、
自呼制御プロセッサに関係付けられている端末または、他呼制御プロセッサからの呼の処理要求を受け付けて実行する通常状態；
自呼制御プロセッサに関係付けられている端末からの呼の処理要求に対しては、全ての他呼制御プロセッサがフローティング依頼状態の場合には当該処理要求を受け付けて実行し、他に通常状態又はフローティング拒否状態の呼制御プロセッサが有る場合には通常状態の呼制御プロセッサ、フローティング拒否状態の呼制御プロセッサの順に処理依頼し、他呼制御プロセッサからの呼の処理要求に対しては、全て拒否するフローティング依頼状態；
自呼制御プロセッサに関係付けられている端末からの呼の処理要求に対しては他呼制御プロセッサへの処理依頼をせず、他呼制御プロセッサからの呼の処理要求に対しては、他に通常状態の呼制御プロセッサが無い場合を除いて当該処理要求を拒否するフローティング拒否状態；
のいずれかの稼動状態で動作しているかを取得・保持し、呼制御プロセッサによって読み出される状態保持手段と、
呼制御プロセッサが端末からの呼を受け付けると、当該呼制御プロセッサが自身の稼動状態及び状態保持手段から取得できる他呼制御プロセッサの稼動状態に応じて、当該呼の制御処理を行う呼制御プロセッサを決定する呼制御プロセッサ判定手段と、
当該決定された呼制御プロセッサに対して呼を制御させる呼制御手段と、を有する。
【００１２】
本発明（請求項４）は、呼制御プロセッサ判定手段において、
最初に受け付けた起呼信号に対してのみ呼制御を行うプロセッサを決定する処理を行なう。
【００１３】
本発明（請求項５）は、自プロセッサに収容されている端末からの呼を受け付けて制御処理する呼制御プロセッサを複数有し、自プロセッサの稼動状況に応じて、該受け付けた制御処理を他の呼制御プロセッサに依頼して端末からの呼を制御処理するマルチプロセッサ交換機に実行させる呼損回避プログラムであって、
上記の請求項１乃至２記載の呼損回避方法の実現に用いられる処理を、マルチプロセッサ交換機として利用されるコンピュータに実行させるプログラムである。
【００１６】
本発明（請求項６）は、自プロセッサに収容されている端末からの呼を受け付けて制御処理する呼制御プロセッサを複数有し、自プロセッサの稼動状況に応じて、該受け付けた制御処理を他の呼制御プロセッサに依頼して端末からの呼を制御処理するマルチプロセッサ交換機に実行させる呼損回避プログラムを格納した記憶媒体であって、
請求項１乃至２記載の呼損回避方法の実現に用いられる処理を、マルチプロセッサ交換機として利用されるコンピュータに実行させるプログラムを格納した記憶媒体である。
【００１９】
上記のように、本発明では、呼制御の依頼を受けるプロセッサは、自プロセッサへの呼を呼制御できる能力を残した上で、負荷の高い他のプロセッサの呼制御の依頼を受けるようにする。これは、
（ａ）使用率を基準に３つの稼働状態（通常状態・フローティング拒否の状態・フローティング依頼の状態）を設定し、各プロセッサのメモリ上に記憶しておく；  （ｂ）稼働状態に従い呼を受けたプロセッサが稼働状態を判定し、呼制御プロセッサを決定する；
ことによって実現している。なお、ここで、『フローティング』とは、呼を受けたプロセッサがプロセッサの稼働状態（負荷状態）を判定して、他のプロセッサに呼制御を依頼する処理を指す。
【００２０】
このように、本発明では、各プロセッサの使用率に基づいて稼働状態（通常状態・フローティング拒否の状態・フローティング依頼の状態）をテーブルに設定しておくことにより、呼を受けたプロセッサにおいて、まず、自プロセッサの稼働状態を判定し、自プロセッサで呼制御ができない場合（「フローティング依頼の状態」）である場合には、他のプロセッサの状態を判定して、他のプロセッサに対して呼制御を依頼することにより、負荷分散を図ることができ、さらにプロセッサ間の無駄な呼制御のための通信回数を削減することが可能となる。
【００２１】
また、本発明において、呼を受けたプロセッサにおいて最初に受けた呼（起呼信号）のみに対して呼制御を行うプロセッサを判定するために、当該判定回数は１回で済むため、判定のための時間が短縮でき、また、呼を受けたプロセッサの負荷を抑えることができる。
【００２２】
【発明の実施の形態】
本発明は、自プロセッサで受けた呼に対しては、可能な限り自プロセッサで呼制御を行おうというものである。
【００２３】
具体的には、呼制御の依頼を受けるプロセッサは、自プロセッサへの呼を呼制御できる能力を残した上で、負荷の高い他のプロセッサの呼制御の依頼を受けるようにする。
【００２４】
このために、第１には、使用率を基準に３つの稼働状態を設定し、各プロセッサのメモリ上に記憶する。ここで、３つの稼働状態には、「通常」、「フローティング拒否」、「フローティング依頼」がある。
【００２５】
稼働状態：「通常」とは、自プロセッサの負荷が少なく、他のプロセッサから受けた呼の制御を行い、使用率が上昇したとしても、自プロセッサが受けた呼の制御も可能な状態である。
【００２６】
稼働状態：「フローティング拒否」とは、他のプロセッサが受けた呼の制御を行うことで自プロセッサの使用率が上昇し、自プロセッサの受けた呼の制御を行えないため、他のプロセッサからの呼制御依頼を拒否する状態である。
【００２７】
稼働状態：「フローティング依頼」とは、自プロセッサの使用率が限界を超え、他のプロセッサに呼制御を依頼するために設定した状態である。
【００２８】
これらの各状態における稼働状態における処理依頼、処理受入等について表１に示す。
【００２９】
【表１】
0003962224.tif 000002
上記のように稼働状態を使用率の基準値によって設定した場合、基準値を境に稼働状態の遷移が多発する恐れがある。これについては、状態遷移の基準値をずらすことで回避できる。例えば、基準値は、図１に示すように、「通常」から「フローティング拒否」の状態に遷移する際の基準値は、４５％とし、「フローティング拒否」から「通常」に遷移する際の基準値は、４０％（４５％より小さい）とする。また、「フローティング拒否」と「フローティング依頼」間の状態遷移についても同様に、例えば、「フローティング拒否」から「フローティング依頼」への状態遷移は、使用率が５５％以上の場合に行うようにする。
【００３０】
一方、所定の使用率より使用率が減少した場合には、上記と反対の状態遷移となる。例えば、「フローティング依頼」の使用率が５５％より小さくなった場合には、「フローティング拒否」に遷移する。
【００３１】
また、本発明では、第２に、稼働状態に従い、最初の呼（起呼信号）を受けたプロセッサが呼制御プロセッサを決定する。この場合の呼制御プロセッサの判定方法の概略を図２に示す。
【００３２】
呼制御プロセッサが呼を受け取ると（ステップ１０１）、呼を受け付けた呼制御プロセッサの稼働状態を判定する（ステップ１０２）。稼働状態が「フローティング依頼」以外であれば、呼を受け付けた呼制御プロセッサにおいて呼制御を行うものとする（ステップ１０３）。また、稼働状態が「フローティング依頼」であるとき、他に稼働状態が「通常」の呼制御プロセッサがあるかを判定し（ステップ１０４）、ある場合には、受け付けた呼を制御するプロセッサは、稼働状態が「通常」である呼制御プロセッサとする（ステップ１０５）。また、稼働状態が「通常」のプロセッサがない場合には、全てのプロセッサの状態を判定し、稼働状態が、「フローティング拒否」または、「フローティング拒否」と「フローティング依頼」が混在している状態であるときには、「フローティング拒否」となっているプロセッサを呼制御プロセッサとする（ステップ１０６）。また、全てのプロセッサの稼働状態が「フローティング依頼」となっているプロセッサがある場合には、呼制御プロセッサは、呼を受け付けたプロセッサとする（ステップ１０７）。
【００３３】
【実施例】
以下、図面と共に本発明の実施例を説明する。
【００３４】
図３は、本発明の一実施例のシステム構成を示す。
【００３５】
同図に示すシステムは、複数の呼制御プロセッサ（Ｐ）１００、使用率管理プロセッサ（Ｐ）２００、複数の端末３００から構成される。
【００３６】
呼制御プロセッサ１００1 （Ｐ１）〜１００n （Ｐｎ）は、呼制御プロセッサ（Ｐ）判定部１１０、使用率管理部１２０、呼制御部１３０、稼働状態管理テーブル１４１を有する稼働状態記憶部１４０、及び制御ルートテーブル１５１を有するメモリ１５０から構成される。
【００３７】
呼制御Ｐ判定部１１０は、稼働状態記憶部１４０の稼働状態管理テーブル１４１を参照して、稼働状態を判定して呼制御プロセッサを決定し、決定した呼制御プロセッサと呼番号（起呼信号の番号）をメモリ１５０内の制御ルートテーブル１５１に格納する。
【００３８】
使用率管理部１２０は、自プロセッサの使用率を監視すると共に、使用率を使用率管理Ｐ２００に通知し、全プロセッサの使用率の通知を使用率管理Ｐ２００から受け取る。
【００３９】
呼制御部１３０は、端末３００からの呼を受け付け、当該呼が起呼信号（端末３００から初めて受信した呼）であれば、当該呼を呼制御Ｐ判定部１１０に渡す。また、起呼信号でなければ、メモリ１５０の制御ルートテーブル１５１を参照して、対象となる呼制御プロセッサに対して呼制御依頼を行う。呼制御Ｐ判定部１１０で呼制御プロセッサが自プロセッサに決まった場合、通信パスの設定等の呼制御を行い、他のプロセッサに決まった場合、当該プロセッサに呼制御を依頼する。また、他の呼制御Ｐからの呼制御依頼を取得したりする。
【００４０】
稼働状態記憶部１４０は、全ての呼制御プロセッサの稼働状態を稼働状態管理テーブル１４１に記憶している。稼働状態管理テーブル１４１は、各呼制御プロセッサを識別するプロセッサ種別と、稼働状態『通常』、『フローティング拒否』、『フローティング依頼』の３つの状態を対にして記憶している。図４に稼働状態管理テーブル１４１の例を示す。同図の例では、稼働状態管理テーブル１４１は、呼制御プロセッサ１の稼働状態は『通常』であり、呼制御プロセッサ１００2 （Ｐ２）は、『フローティング拒否』の状態を示している。
【００４１】
次に、使用率管理プロセッサ２００の構成について説明する。
【００４２】
図３に示す使用率管理プロセッサ２００は、全プロセッサ（Ｐ）使用率管理部２１０と、全プロセッサ（Ｐ）使用率記憶部２２０から構成される。
【００４３】
全プロセッサ使用率管理部２１０は、各呼制御プロセッサの使用率を周期的に収集し、収集した使用率をプロセッサ使用率記憶部２２０に記憶する。また、全呼制御プロセッサの使用率を各プロセッサに通知する。
【００４４】
全プロセッサ使用率記憶部２２０は、全プロセッサ使用率管理部２１０から渡された全呼制御プロセッサの使用率を記憶する。
【００４５】
次に、上記の構成における呼制御プロセッサを判定する動作を説明する。
【００４６】
図５は、本発明の一実施例の呼制御プロセッサ判定動作のフローチャートである。
【００４７】
ステップ２０１）  呼制御プロセッサ１００1 （Ｐ１）において、端末３００Ａから呼を受信する。
【００４８】
ステップ２０２）  呼制御プロセッサ１００1 （Ｐ１）の呼制御Ｐ判定部１１０では、稼働状態管理テーブル１４１を参照し、自プロセッサの稼働状態を判定する。前述の図４の稼働状態管理テーブル１４１の例では、稼働状態が「通常」であるプロセッサ１（Ｐ１）、プロセッサ４（Ｐ４）、「フローティング拒否」であるプロセッサ２（Ｐ２）、プロセッサ５（Ｐ５）が呼を受けた場合に対応する。稼働状態が「フローティング依頼」の場合には、ステップ２０３に移行し、そうでない場合にはステップ２０４に移行する。
【００４９】
ステップ２０３）  自プロセッサ（Ｐ１）で呼制御を行う。
【００５０】
ステップ２０４）  ステップ２０２において、呼を受けたプロセッサの稼働状態を判定した結果、稼働状態が「フローティング依頼」である場合には、他のプロセッサの稼働状態を判定する。この処理を行うのは、図４の稼働状態管理テーブル１４１の稼働状態が「フローティング依頼」であるプロセッサ３（Ｐ３）が呼を受けた場合である。
【００５１】
ステップ２０５）  プロセッサ１００の呼制御プロセッサ判定部１１０では、において、稼働状態が「通常」であるプロセッサの有無を稼働状態管理テーブル１４１を参照して判定し、「通常」のプロセッサが有る場合には、ステップ２０６に移行し、ない場合にはステップ２０７に移行する。
【００５２】
ステップ２０６）  稼働状態が「通常」であるプロセッサ１００に呼制御を依頼する。例えば、図４の稼働状態管理テーブル１４１において稼働状態が「通常」であるプロセッサ（Ｐ１），プロセッサ（Ｐ４）に対して呼制御を依頼する。稼働状態が「通常」の呼制御プロセッサが複数存在する場合には、プロセッサ番号が小さい順に決定すればよい。
【００５３】
ステップ２０７）  ステップ２０５において、稼働状態が「通常」のプロセッサが稼働状態管理テーブル１４１上に無かった場合には、全プロセッサの稼働状態を判定する。
【００５４】
ステップ２０８）  全プロセッサの稼働状態が「フローティング拒否」、或いは、「フローティング依頼」が混在する場合には、ステップ２０９に移行し、そうでない場合には、ステップ２１０に移行する。
【００５５】
ステップ２０９）  「フローティング拒否」のプロセッサに対して呼制御を依頼する。なお、稼働状態が「フローティング拒否」の呼制御プロセッサが複数存在する場合には、プロセッサ番号の小さい順にプロセッサを決定すればよい。例えば、図６に示す状態管理テーブルにおいて、呼制御プロセッサがプロセッサ（Ｐ１）である場合に、「フローティング拒否」の状態であるプロセッサ２（Ｐ２）、プロセッサ５（Ｐ５）に呼制御の依頼を行う。
【００５６】
ステップ２１０）  ステップ２０８において、全プロセッサの稼働状態が「フローティング依頼」の場合には、呼を受けたプロセッサ自身が呼制御を行う。例えば、図７に示す稼働状態管理テーブル１４１において、稼働状態を判定しているプロセッサがＰ１である場合、全プロセッサの稼働状態が「フローティング依頼」であるため、プロセッサ１（Ｐ１）が呼制御を行う。
【００５７】
また、上記の稼働状態管理テーブル１４１に格納されている情報は、使用率管理プロセッサ２００から取得して格納される。各呼制御プロセッサ１００は、使用率管理部１２０で自プロセッサの使用率を監視し、使用率を使用率管理プロセッサ２００に通知する。また、使用率管理プロセッサ２００の全プロセッサ使用率管理部２１０において各呼制御プロセッサ１００から収集した使用率を全プロセッサ使用率記憶部２２０に記憶しておき、当該各呼制御プロセッサ１００の使用率管理部１２０に全プロセッサの使用率を通知する。これにより、各呼制御プロセッサの使用率管理部１２０では、取得した使用率で稼働状態記憶部１４０の稼働状態管理テーブル１４１の内容を更新する。
【００５８】
ここで、稼働状態管理テーブル１４１の更新処理について説明する。
【００５９】
図８、図９は、本発明の一実施例における稼働状態管理テーブルの更新処理を説明するための図である。
【００６０】
▲１▼  まず、各プロセッサの使用率を使用理管理プロセッサ２００に定期的に通知する。図８において、Ｐ１，Ｐ２，Ｐ３は各プロセッサを、ＸＸ％は各プロセッサで監視した使用率を表す。
【００６１】
▲２▼  使用率管理プロセッサ２００で収集した全プロセッサの使用率を、図９に示すように、各プロセッサに通知する。
【００６２】
▲３▼  各プロセッサの使用率管理部１２０は、全プロセッサの使用率と稼働状態に対応させて、４５％未満：通常、４５％以上５５％未満：フローティング拒否、５５％以上：フローティング依頼、の状態に稼働状態管理テーブル１４１を更新する。
【００６３】
なお、各呼制御プロセッサ１００が端末３００から受ける呼は、複数の信号（起呼信号、その他の端末に接続に必要な信号）によって構成され、これらの複数の信号を呼制御プロセッサ１００は、順次端末３００から受信するものとする。呼制御プロセッサ１００の呼制御プロセッサ制御部１１０における呼制御プロセッサの決定は、最初に受信した信号（起呼信号）のみを対象とし、以降の信号は、起呼信号で決定した制御ルートに従い呼制御プロセッサに依頼し、起呼信号以降の信号毎に何度も呼制御プロセッサ決定処理を行わない。
【００６４】
ここで、最初に端末３００から受信した起呼信号で決定した制御ルートは、当該起呼信号以降に受信した信号によって変更されることはないものとする。この理由は、各信号を受信の都度、呼制御を行う呼制御プロセッサ１００の判定をすると、使用率を圧迫することになるためである。
【００６５】
この制御ルートを引き継ぐためには、プロセッサが起呼信号を受信し、呼制御プロセッサを決定した場合、呼の識別及び制御ルートを特定するために、呼番号と呼制御プロセッサのプロセッサ種別をメモリ１５０上（制御ルートテーブル１５１）に記憶する。例えば、図１０に示す制御ルートテーブル１５１の例では、呼番号（０００１）、プロセッサ種別（プロセッサ３）である。
【００６６】
起呼信号以降の端末３００から受ける信号に対しては、呼制御プロセッサの判定はせず、各信号に付与された呼番号（０００１）を基に制御ルート管理テーブルを参照し、呼番号に対するプロセッサ種別（プロセッサ３）のプロセッサに呼制御を依頼する。
【００６７】
また、上記の実施例では、図３の構成に基づいて説明したが、各呼制御プロセッサの構成要素をプログラムとして構築し、当該プロセッサのＣＰＵにインストールする、または、ネットワークを介して流通させることが可能である。
【００６８】
また、構築されたプログラムを呼制御プロセッサとして利用されるコンピュータに接続されるハードディスク装置や、フロッピーディスク、ＣＤ−ＲＯＭ等の可搬記憶媒体に格納しておき、本発明を実施する際にインストールすることにより、容易に本発明を実現できる。
【００６９】
なお、本発明は、上記の実施例に限定されることなく、特許請求の範囲内において、種々変更・応用が可能である。
【００７０】
【発明の効果】
上述のように、本発明によれば、マルチプロセッサ電子交換機において、専用の装置を用意しなくとも、端末から呼を受け取ったプロセッサ内において、稼働状態を判定し、呼制御を行う呼制御プロセッサを決定することができる。
【００７１】
また、稼働状態として、他のプロセッサからの呼制御の依頼を受け付けない「フローティング拒否」を設けたことで、プロセッサ間の無駄な呼制御の依頼回数（プロセッサ間通信）を削減し、各プロセッサ個々の処理能力を超えた負荷分散処理が可能となる。
【図面の簡単な説明】
【図１】本発明の一実施の形態における稼働状態の遷移図である。
【図２】本発明の一実施の形態における呼制御プロセッサの判定方法の概略を示す図である。
【図３】本発明の一実施例のシステム構成図である。
【図４】本発明の一実施例の稼働状態管理テーブルの例である。
【図５】本発明の一実施例の呼制御プロセッサ判定動作のフローチャートである。
【図６】本発明の一実施例の稼働状態管理テーブルの例（全プロセッサがフローティング拒否又はフローティング依頼の場合）である。
【図７】本発明の一実施例の稼働状態管理テーブルの例（全プロセッサがフローティング依頼の場合）である。
【図８】本発明の一実施例における稼働状態管理テーブルの更新処理を説明するための図（その１）である。
【図９】本発明の一実施例における稼働状態管理テーブルの更新処理を説明するための図（その２）である。
【図１０】本発明の一実施例の制御ルート管理テーブルの例である。
【図１１】従来のマルチプロセッサ型電子交換機の負荷分散方式を説明するための図である。
【図１２】従来のマルチプロセッサ型交換機における呼制御依頼の遷移図である。
【符号の説明】
１００  呼制御プロセッサ
１１０  呼制御プロセッサ判定部
１２０  使用率管理部
１３０  呼制御部
１４０  稼働状態記憶部
１４１  稼働状態管理テーブル
１５０  メモリ
１５１  制御ルートテーブル
２００  使用率管理プロセッサ
２１０  全プロセッサ使用率管理部
２２０  全プロセッサ使用率記憶部
３００  端末
【図１】
0003962224.tif 000003
【図２】
0003962224.tif 000004
【図３】
0003962224.tif 000005
【図４】
0003962224.tif 000006
【図５】
0003962224.tif 000007
【図６】
0003962224.tif 000008
【図７】
0003962224.tif 000009
【図８】
0003962224.tif 000010
【図９】
0003962224.tif 000011
【図１０】
0003962224.tif 000012
【図１１】
0003962224.tif 000013
【図１２】
0003962224.tif 000014