(57)【特許請求の範囲】
【請求項１】
呼処理を複数のプロセッサに振り分けて処理するようにしたマルチプロセッサ型呼処理方式において、
呼処理を振り分ける振り分け手段と、所定種類の呼の処理を行う複数の呼処理手段と、少なくとも一つのホストプロセッサ手段とを備え、
前記各呼処理手段は、自身が処理できない種類の呼の処理を前記振り分け手段によって振り分けられたとき、前記ホストプロセッサ手段に前記呼の処理を依頼すると共に、呼処理をホストプロセッサ手段に依頼した際に前記振り分け手段に対して処理を依頼した呼及びホストプロセッサ手段を表す処理依頼内容を通知し、
前記振り分け手段は、前記処理依頼内容を第２の記憶手段に記憶し、前記第２の記憶手段に記憶された処理依頼内容を参照して、前記呼当ての後続するメッセージを該当する呼処理手段及びホストプロセッサ手段に送信し、
前記ホストプロセッサ手段は依頼された前記呼の処理を行うことを特徴とするマルチプロセッサ型呼処理方式。
【請求項２】
前記各呼処理手段は、前記ホストプロセッサ手段に依頼した呼及び呼処理を依頼したホストプロセッサ手段を対応付けした呼状態管理表を記憶する第１の記憶手段を有し、前記呼状態管理表を用いて、呼処理をホストプロセッサ手段に依頼している間は、その呼に関して後続するメッセージを該ホストプロセッサ手段へ転送することを特徴とする請求項１記載のマルチプロセッサ型呼処理方式。
【請求項３】
前記呼処理手段がホストプロセッサ手段に処理依頼を行う際、処理依頼メッセージに、処理依頼に必要な情報を付加して送信することを特徴とする請求項１又は２記載のマルチプロセッサ型呼処理方式。
【請求項４】
前記ホストプロセッサ手段が処理依頼を受けて呼処理した際、呼処理の依頼をした呼処理手段では処理できないメッセージが後続すると判断した場合、前記後続するメッセージの処理が該ホストプロセッサ手段で全て終了した後、処理終了通知を前記呼処理手段に送信することを特徴とする請求項１乃至３のいずれか一に記載のマルチプロセッサ型呼処理方式。
【請求項５】
前記振り分け手段又は呼処理手段が呼設定処理をキャンセルする要求を受け取った場合、前記振り分け手段又は呼処理手段が前記キャンセル要求に対する応答を行った後、前記呼処理手段は該当する呼状態管理表におけるエントリの削除処理を行うことを特徴とする請求項１乃至４のいずれか一に記載のマルチプロセッサ型呼処理方式。
【発明の詳細な説明】
【０００１】
【産業上の技術分野】
本発明は、呼処理を複数のプロセッサに振り分けて処理するようにしたマルチプロセッサ型呼処理方式に関する。
【０００２】
【従来の技術】
従来から、呼処理を複数のプロセッサに振り分けて処理するようにしたマルチプロセッサ型呼処理システムが開発され又、利用に供されている。
マルチプロセッサ型呼処理システムの例として、通話路容量や制御系処理能力それぞれの要求条件が異なる地域に対して、同一システムで迅速かつ効率的にサービスを提供するため、通話路系制御装置と、制御系制御装置を分離したアーキテクチャを採用し、各々独立に拡張できる通信ノードシステムの一例が、“マルチプロセッサノードシステムにおける装置分散制御方式”（信学技報ＳＳＥ９９−１０６・ＴＭ９９−４９、電子情報通信学会、１９９９年１１月発行）に記載されている。前記文献記載のシステムでは、制御系装置と、通話路系装置とがそれぞれ別の処理モジュールとして分離して実装されているため、システム性能のスケールアップに柔軟に対応が可能である。また、故障範囲がモジュール内に収まる場合、その故障によりシステム全体が停止することを避けられ、処理モジュールを交換するだけで故障から回復できる等の利点がある。
【０００３】
また、特開昭６２−９５０４９号公報、特開平６−７７９９７号公報、特開平１０−２３３７７６号公報、特開平１０−２４３０９５号公報、特開２０００−１９７０９４号公報、特開２０００−２２４６４９号公報には、マルチプロセッサ呼処理システムにおける呼処理の振り分け方法が記載されている。これらの公報に記載された呼処理の振り分け方法は、振り分け部が負荷の低い呼処理ユニットを認識できるように、各呼処理ユニットが振り分け部に対して自身の負荷状況を定期的に通知し、これにより、振り分け部は前記通知がない呼処理ユニットは異常状態、例えば輻輳状態にあると認識できようにしている。振り分け部は、これらの状態をもとに、異常状態にない呼処理ユニットに処理を振り分けたり、呼処理の負荷の均一化を図るようにしている。
【０００４】
【発明が解決しようとする課題】
しかしながら、システム性能を向上するに際して、処理性能向上と処理の多様化は、しばしばトレードオフの関係にあり、多様な例外処理が存在する場合、前記文献や各公報に記載された発明のように、単に負荷の状況に応じて処理を振り分けてマルチプロセッサ処理するだけでは高速化が十分に達成できないという問題がある。
【０００５】
本発明は、規模拡張性、および、機能拡張性に優れ、高速処理可能なマルチプロセッサ型呼処理システムを提供することを課題としている。
【０００６】
【課題を解決するための手段】
本発明によれば、呼処理を複数のプロセッサに振り分けて処理するようにしたマルチプロセッサ型呼処理方式において、呼処理を振り分ける振り分け手段と、所定種類の呼の処理を行う複数の呼処理手段と、少なくとも一つのホストプロセッサ手段とを備え、前記各呼処理手段は、自身が処理できない種類の呼の処理を前記振り分け手段によって振り分けられたとき、前記ホストプロセッサ手段に前記呼の処理を依頼し、前記ホストプロセッサ手段は依頼された前記呼の処理を行うことを特徴とするマルチプロセッサ型呼処理方式が提供される。各呼処理手段は、自身が処理できない種類の呼の処理を振り分け手段によって振り分けられたとき、ホストプロセッサ手段に前記呼の処理を依頼し、前記ホストプロセッサ手段は依頼された前記呼の処理を行う。
【０００７】
ここで、前記各呼処理手段は、前記ホストプロセッサ手段に依頼した呼及び呼処理を依頼したホストプロセッサ手段を対応付けした呼状態管理表を記憶する第１の記憶手段を有し、前記呼状態管理表を用いて、呼処理をホストプロセッサ手段に依頼している間は、その呼に関して後続するメッセージを該ホストプロセッサ手段へ転送するように構成してもよい。
また、前記各呼処理手段は、呼処理をホストプロセッサ手段に依頼した際に前記振り分け手段に対して処理を依頼した呼及びホストプロセッサ手段を表す処理依頼内容を通知し、前記振り分け手段は、前記処理依頼内容を第２の記憶手段に記憶し、前記第２の記憶手段に記憶された処理依頼内容を参照して、前記呼当ての後続するメッセージを該当するホストプロセッサ手段に送信するように構成してもよい。
また、前記各呼処理手段は、呼処理をホストプロセッサ手段に依頼した際に前記振り分け手段に対して処理を依頼した呼及びホストプロセッサ手段を表す処理依頼内容を通知し、前記振り分け手段は、前記処理依頼内容を第２の記憶手段に記憶し、前記第２の記憶手段に記憶された処理依頼内容を参照して、前記呼当ての後続するメッセージを該当する呼処理手段及びホストプロセッサ手段に送信するように構成してもよい。
【０００８】
また、前記呼処理手段がホストプロセッサ手段に処理依頼を行う際、処理依頼メッセージに、処理依頼に必要な情報を付加して送信するように構成してもよい。
また、前記ホストプロセッサ手段が処理依頼を受けて呼処理した際、呼処理の依頼をした呼処理手段では処理できないメッセージが後続すると判断した場合、前記後続するメッセージの処理が該ホストプロセッサ手段で全て終了した後、処理終了通知を前記呼処理手段に送信するように構成してもよい。
また、前記振り分け手段又は呼処理手段が呼設定処理をキャンセルする要求を受け取った場合、前記振り分け手段又は呼処理手段が前記キャンセル要求に対する応答を行った後、前記呼処理手段は該当する呼状態管理表におけるエントリの削除処理を行うように構成してもよい。
また、前記呼処理手段を処理機能単位の呼処理を行うように構成してもよい。
【０００９】
また、本発明によれば、呼処理を複数のプロセッサに振り分けて処理するようにしたマルチプロセッサ型呼処理方式において、呼処理を振り分ける振り分け手段と、第３の記憶手段と、所定種類の呼の処理を行う複数の呼処理手段と、少なくとも一つのホストプロセッサ手段とを有し、前記各呼処理手段は、自身が処理できない種類の呼の処理を前記振り分け手段によって振り分けられたとき、前記ホストプロセッサ手段に前記呼の処理を依頼すると共に、前記ホストプロセッサ手段に処理を依頼した呼及び該ホストプロセッサ手段名を前記振り分け手段に通知し、前記ホストプロセッサ手段は前記呼処理手段から依頼を受けた呼の処理を行ない、前記振り分け手段は、前記呼処理手段から受信した前記呼及びホストプロセッサ手段名を前記第３の記憶手段に記憶すると共に、前記第３の記憶手段の記憶内容を参照して、前記呼宛の後続するメッセージを該ホストプロセッサ手段に直接送信することを特徴とするマルチプロセッサ型呼処理方式が提供される。各呼処理手段は、自身が処理できない種類の呼の処理を振り分け手段によって振り分けられたとき、ホストプロセッサ手段に前記呼の処理を依頼すると共に、前記ホストプロセッサ手段に処理を依頼した呼及び該ホストプロセッサ手段名を前記振り分け手段に通知する。前記ホストプロセッサ手段は前記呼処理手段から依頼を受けた呼の処理を行なう。前記振り分け手段は、前記呼処理手段から受信した前記呼及びホストプロセッサ手段名を前記第３の記憶手段に記憶すると共に、前記第３の記憶手段の記憶内容を参照して、前記呼宛の後続するメッセージを該ホストプロセッサ手段に直接送信する。
【００１０】
【発明の実施の形態】
本発明の実施の形態に係るマルチプロセッサ型呼処理方式について説明するに先立って、先ず、その概要を説明する。
本発明の実施の形態に係るマルチプロセッサ型呼処理方式は、フロントエンドに配設した所定種類の呼の処理（例えば、単純な呼の処理）を行う複数の呼処理ユニット部にて効率的に処理し、前記所定種類以外の呼の処理（例えば、複雑な処理、もしくは、呼処理ユニット部が対応していない処理）については、少なくとも一つ設けられたホストプロセッサ部に処理依頼を行うことで、処理効率の高いシステムを構築している。マルチプロセッサ構成を取ることにより、規模拡張性も実現している。具体的には、呼処理ユニット部で高速な処理を行うために、呼状態管理表を呼処理ユニット部に配置することで、メモリアクセス時間の短縮を図っている。また、プロトコル動作の整合性を保つために、呼処理をホストプロセッサ部に依頼している間は、その呼に関するメッセージを確実に該ホストプロセッサ部へ転送している。
【００１１】
また、ホストプロセッサ部で処理すべきメッセージが呼処理ユニット部を経由せずに迅速にホストプロセッサへ到達するように構成することにより、ホストプロセッサ部での処理開始時間を短縮できるようにすると共に、ホストプロセッサ部での処理遅延が減少し、結果としてシステムの処理性能を向上させるようにしている。
また、呼処理ユニット部がホストプロセッサ部に処理の依頼（切り替え要求）を行う際に、処理依頼メッセージ（切り替え要求メッセージ）に、処理依頼に必要な情報（呼状態、呼処理ユニットが受信したメッセージ、呼処理ユニット番号）を追加して送付する。これにより、ホストプロセッサ部によって切り替え要求が承認された場合に、あらためて処理依頼に必要な情報を送らないで済むため、呼処理ユニット部とホストプロセッサ部とのメッセージ交換回数を減らすことが可能になり、したがって、処理速度を向上させることが可能になる。
【００１２】
また、ホストプロセッサ部がメッセージを処理した後、該ホストプロセッサ部は、呼処理ユニット部では処理できないメッセージが後続すると判断した場合、それらメッセージの処理が該ホストプロセッサ部で全て終了した後、処理終了の通知（切り替え要求）を呼処理ユニット部に送信する。これにより、ホストプロセッサ部と呼処理ユニット部との間での切り替え回数を減らすことができるため、処理時間を短縮することができる。
また、振り分け部もしくは呼処理ユニット部が呼設定処理をキャンセルする要求を示すキャンセル要求メッセージ受け取った場合、直ちに前記キャンセル要求に対する応答を行い、関連する処理（該当する呼状態表エントリーのクリア）は前記応答の後に行うようにしている。これにより、キャンセル要求メッセージに対する処理遅延を短縮できる。
【００１３】
また、呼処理ユニットを処理機能単位（例えば、転送処理機能、名前解決機能等）で構成する。これにより、ある機能に対する処理性能が不足している場合、対応する処理機能を実現する呼処理ユニットを追加すればよいため、機能毎の性能に応じた拡張を実現できるようにしている。また、ある機能の実装方式が変更になった場合にも呼処理ユニットを交換するだけで対応できるため、機能実装の変更に対する柔軟な対応が可能になるようにしている。
また、共通呼状態記憶部を備えるように構成することにより、ホストプロセッサ部への処理依頼時に、振り分け部とホストプロセッサ部間でのみメッセージ伝達が行われるので、振り分け部と呼処理ユニット部間でのメッセージ送受回数を減らして、システム資源を有効に活用できる。
【００１４】
以下、本発明の実施の形態について詳細に説明する。図１は、本発明の実施の形態に係るマルチプロセッサ型呼処理方式に使用するマルチプロセッサ型呼処理システムのブロック図であり、また、マルチプロセッサを用いた呼処理方法に適用されるシステムのブロック図である。本実施の形態においては、ＳＩＰ（Session Initiation Protocol）プロトコル処理を行うプロキシ（Proxy）サーバの例を示している。尚、ＳＩＰはアプリケーション層プロトコルであり、複数台のＳＩＰ端末装置間で呼の接続、切断を行うために使用されるシグナリング・プロトコルである。
【００１５】
図１において、マルチプロセッサ型呼処理システムは、振り分け手段を構成する振り分け部１０１、フロントエンドに配設され各々呼処理手段を構成する複数の呼処理ユニット１０５１、１０５２、・・・、ホストプロセッサ手段を構成する一つまたは複数のホストプロセッサ１０９１、１０９２、・・・、および加入者データベース１１０から構成される。
呼処理ユニット１０５１、１０５２・・・は、所定種類の呼の処理（例えば、単純な呼の処理）、つまり、予め定めた所定の処理のみを行い、前記所定種類以外の呼の処理（例えば、複雑な処理、もしくは、呼処理ユニット部が対応していない処理）については、少なくとも一つ設けられたホストプロセッサ部１０９１、１０９２、・・・に処理を依頼をする機能を有している。また、各呼処理ユニット１０５１、１０５２・・・の処理対象は後述するように各々相違するように設定できるが（例えば、音声信号の処理、呼処理ユニット１０５２はビデオ信号の処理）、ここでは、同一のものを想定している。
【００１６】
振り分け部１０１は、外部ネットワークから受信したメッセージを、どの呼処理ユニット１０５１、１０５２、・・・で処理すべきかを決定する機能を有しており、メッセージ送受信手段を構成するメッセージ送受信部１０２、メッセージ解析手段を構成するメッセージ解析部１０３、および、呼処理ユニット番号対応表が記憶され第２の記憶手段を構成する呼処理ユニット状態管理部１０４から成っている。メッセージ送受信部１０２は外部との間でメッセージの送受信を行う。メッセージ解析部１０３は、メッセージ送受信部１０２で受信したメッセージ内容を解析し、そのメッセージが対象としている呼を識別するための呼識別子（Call-ID：呼ＩＤ）を該メッセージから抽出する（必要であれば、呼ＩＤのみならず送信元アドレス及び宛先アドレスも抽出する）。呼処理ユニット状態管理部１０４は、呼ＩＤ（必要であれば、呼ＩＤのみならず送信元アドレス及び宛先アドレス）と呼処理ユニット１０５１、１０５２、・・・、若しくは、呼ＩＤ（必要であれば、呼ＩＤのみならず送信元アドレス及び宛先アドレス）とホストプロセッサ１０９１、１０９２、・・・との対応関係を記憶して管理している。メッセージ解析部１０３は、呼処理ユニット状態管理部１０４の記憶内容を参照することで、メッセージの転送先を決定することができる。
【００１７】
尚、メッセージはヘッダ部とボディ部から構成されている。ヘッダ部には、主に、このメッセージがどのプロトコル処理に対応しているのかを示すプロトコル処理情報（このメッセージは呼接続を行うのか、呼切断を行うのか等の情報）、及び、メッセージがネットワーク中を正しく伝播するために必要なアドレス情報（送信元アドレス、宛先アドレス、呼を識別するための呼ＩＤ、メッセージが伝播してきたコンピュータのアドレス等）が含まれる。また、ボディ部には、ＳＩＰとは直接関係のないあらゆる情報（例えば、ＳＩＰ端末装置間で使用するメディアをネゴシエーションするための情報）が格納される。また、メッセージの種類は、リクエストメッセージとレスポンスメッセージに大別される。リクエストメッセージはメソッド（METHOD：クライアントがサーバに対して行わせる処理であり、例えば、INVITE（呼の接続を要求）、ACK（呼の接続を確認し会議を開始）、BYE（呼を切断）、INFO（呼に関係した情報を送信）等）の種類に対応した数だけ複数存在し又、レスポンスメッセージはレスポンスコード（例えば、100番台は情報通知、200番台は成功、300番台はリダイレクト、400番台はリクエストが間違っていることによる失敗）の種類に対応した数だけ複数存在する。
【００１８】
呼処理ユニット部１０５１、１０５２、・・・は、受信したメッセージを入力として、該当する呼状態を遷移させ、それに伴う処理を行う。各呼処理ユニット部１０５１、１０５２、・・・は同一構成されているため、それらの構成を処理ユニット部１０５１を例にとって説明すると、呼処理ユニット部１０５１はメッセージ送受信手段を構成するメッセージ送受信部１０７１、呼処理プロセッサ手段を構成する呼処理プロセッサ部１０６１および、第１の記憶手段を構成する呼状態記憶部１０８１から構成される。メッセージ送受信部１０７１は、振り分け部１０１、および、ホストプロセッサ部１０９１、１０９２、・・・との間でメッセージを送受信する。呼状態記憶部１０８１は呼状態を表す呼状態管理表を記憶している。
加入者データベース１１０には加入者のデータが格納されており、メッセージの宛先を加入者データベース１１０で検索し、転送先が存在するか否かを調べるためのものである。
【００１９】
図２に、呼状態記憶部１０８１に記憶された呼状態管理表を示す。呼状態管理表の各エントリーは、呼ＩＤ、呼状態、処理を依頼しているホストプロセッサ番号、および、ホストプロセッサ部に転送したメッセージ数から構成される。尚、「ｎｕｌｌ」はホストプロセッサ部に処理依頼をしていないことを表している。呼処理プロセッサ部１０６１は受信したメッセージと、該当する呼状態から、処理を決定し呼処理を行う。
図３に、呼処理ユニット１０５１、１０５２、・・・のメッセージ送受信部１０７１、１０７２、・・・にメッセージが到着してからの処理手順を示しており、各呼処理ユニット１０５１、１０５２、・・・の呼処理プロセッサ部１０６１、１０６２、・・・が図３に示した処理を行う。呼処理ユニット１０５１、１０５２、・・・の処理手順は同一であり、各々、図３の処理を行う。
【００２０】
呼処理ユニット１０５１を例にとって図３の処理を説明すると、呼処理ユニット１０５１のメッセージ送受信部１０７１が振り分け部１０１からメッセージを受信した場合、呼処理プロセッサ部１０６１は該メッセージの内容を分析し（図３の処理ステップＡ１）、該当する呼状態を呼状態記憶部１０８１から検索する（ステップＡ２）。ここで、振り分け部１０１にて抽出した呼ＩＤ（必要であれば、呼ＩＤのみならず送信元アドレス及び宛先アドレス）を、振り分け部１０１が呼処理ユニット１０５１に転送するメッセージに付加し、呼処理プロセッサ部１０６１がそれを参照することで、該当する呼状態を呼状態記憶部１０８１から検索するように構成することもできる。
次に、該当する呼状態が“ホストプロセッサに処理依頼中”かどうかを判断し（ステップＡ３）、その呼がホストプロセッサに処理依頼中でなければ、呼処理プロセッサ１０６１での処理が開始される（Ａ５〜Ａ１２２）。
【００２１】
この場合、呼処理プロセッサ１０６１では、まずメッセージ種別を判断し（ステップＡ５）、そのメッセージが呼処理ユニット１０５１自身で処理可能か否か、即ち所定種類の呼か否かを判断する（ステップＡ６）。処理可能ならば、ステップＡ２で検索した呼状態を遷移させて呼処理を行う（ステップＡ７）。その後、それに伴うメッセージ送信処理を行う。この場合、先ず、遷移後の呼状態を呼状態記憶部１０８１に書き込んで更新し（ステップＡ８）、送信するメッセージがあれば、それを振り分け部１３１へ送信して終了する（ステップＡ９）。振り分け部１３１は前記メッセージをメッセージ送受信部１３２から外部へ送信する。
ステップＡ６において、受信したメッセージを呼処理ユニット１０５１自身で処理できないと判断した場合、ホストプロセッサへ処理を依頼する。この場合、先ず、処理を依頼するホストプロセッサを決定する（ステップＡ１０）。このとき、振り分け部１０１と同じように、ホストプロセッサ１０９１、１０９２、・・・の負荷状態を考慮してホストプロセッサを決定することが考えられる。そして、選択したホストプロセッサに対して、呼処理依頼ができるかどうか尋ねる、つまり、処理依頼通知（切り替え通知）を送信して呼処理依頼（処理の切り替え）が可能か否かを尋ねる（ステップＡ１１）。
【００２２】
該ホストプロセッサ部から切り替えが拒否された場合には、ステップＡ１０へ戻り（ステップＡ１２）、別のホストプロセッサ部を選択し、処理を継続する。ホストプロセッサ部によって切り替えが承認された場合（ステップＡ１２）、図１１の破線で示すように、該当するホストプロセッサに対して、処理依頼に必要な情報である呼状態、該呼処理ユニット１０５１が受信したメッセージ及び呼処理ユニット１０５１の呼処理ユニット番号を転送し、処理の依頼を行う（ステップＡ１２１）。依頼を行う際に用いるメッセージの内容を図４に示す。図４に示すように、依頼メッセージは、呼ＩＤ、呼状態、呼処理ユニット１０５１が受信したメッセージ及び呼処理ユニット１０５１の呼処理ユニット番号によって構成される。ＩＮＦＯは、呼に関係した情報を送信する旨を表すメッセージである。なお、処理の依頼が完了する前に呼処理ユニット１０５１に該当する呼宛てのメッセージが振り分け部１０１から到達した場合、ステップＡ１２１でそのメッセージも該ホストプロセッサ部に転送される。
その後、呼状態記憶部１０８１内の呼状態管理表（図２）の該当するエントリーを書き換えて呼状態を更新する（ステップＡ１２２）。このときエントリーの呼状態は、“ホストプロセッサに処理依頼中”、ホストプロセッサ番号には、該当するホストプロセッサ部のホストプロセッサ番号が書き込まれる。
【００２３】
ステップＡ３において、該当する呼が“ホストプロセッサで処理中”の場合、受け取ったメッセージを同じホストプロセッサに転送し、その処理を依頼する。
そのために、呼状態記憶部１０８１の該当するエントリーに含まれる転送メッセージ数を１つ増やし（ステップＡ１３）、エントリーに含まれるホストプロセッサ番号から転送先を決定し（ステップＡ１４）、メッセージを転送する（ステップＡ１５）。
ホストプロセッサが依頼された処理を終了すると、依頼を受けた呼処理ユニットに対して、処理を終了する旨を表す終了通知（切り替え要求）を通知する。なお、前記切り替え要求通知には、図５で示す処理結果メッセージが付加される。即ち、呼ＩＤ、呼状態及び転送メッセージ数が付加される。
【００２４】
図６に呼処理ユニット１０５１、１０５２、・・・がホストプロセッサ１０９１、１０９２、・・・から処理切り替え要求を通知された後の動作手順を示す。各呼処理ユニット１０５１、１０５２、・・・の呼処理プロセッサ１０６１、１０６１、・・・は図６に示した処理を行う。
呼処理ユニット１０５１を例にとって説明すると、メッセージ送受信部１０７１を介して終了通知（切り替え通知）を受信した呼処理プロセッサ１０６１では、呼状態記憶部１０８１の該当する呼の転送メッセージ数と、処理結果に含まれる転送メッセージ数とを比較する（ステップＢ１）。両者が等しければ、切り替え承認を該ホストプロセッサに伝え（ステップＢ３）、呼状態記憶部１０８１の呼状態管理表に処理後の呼状態を書き込んで更新する（ステップＢ４）。
ステップＢ２において、呼処理ユニット部１０５１が転送したメッセージ数が、該ホストプロセッサから転送されたメッセージ数よりも少ない場合、メッセージが転送中の可能性がある。そこで、両転送メッセージ数が異なる場合、該ホストプロセッサに終了（切り替え）の拒否を伝える（ステップＢ５）。また、該呼処理ユニット部１０５１の処理負荷が高く処理を行えない場合等にも切り替え拒否を伝えることもできる。切り替え拒否を受信した該ホストプロセッサは、後続メッセージを待って処理を行い、その処理が終わった時点で、再び切り替え要求を該当する呼処理ユニット１０５１に通知する。
【００２５】
図７にシステム全体の動作例を示す。この例では、ある呼に対応するメッセージが、呼ＩＤに対応する呼処理ユニット１０５２へ伝達されたものの、呼処理ユニット１０５２では該メッセージの処理ができず、ホストプロセッサ１０９１へ処理を依頼する例を示している。例を説明するために、ＳＩＰ（Session Initiation Protocol）を用いる。ＳＩＰの仕様に関しては、ＩＥＴＦ（Internet Engineering Task Force）発行のＲＦＣ２５４３に記載されている。
【００２６】
図７において、外部ネットワークからメッセージ＃１が振り分け部１０１に届くと（１）、該メッセージ♯１はメッセージ送受信部１０２で受信された後、メッセージ解析部１０３が該メッセージ♯１から呼ＩＤ（Call-ID）を抽出し、呼処理ユニット状態管理部１０４を参照して、転送先の呼処理ユニットを決定する。この例では呼処理ユニット１０５２へ転送する（２）。呼処理ユニット１０５２では、呼処理プロセッサ１０６２がメッセージ種別を判別する（図３のステップＡ５）。その結果、前記メッセージが呼処理ユニット１０５２では対応していない種類の呼処理であるＭＥＴＨＯＤ（例えばＩＮＦＯ）である場合、ホストプロセッサに処理を依頼することを決定する。ホストプロセッサ１０９１を転送先に決定し（ステップＡ１０）、ホストプロセッサ１０９１に対して処理依頼（切り替え）通知を行う（３）。
【００２７】
ホストプロセッサ１０９１から処理依頼（切り替え）承認を受けると（４）、呼処理ユニット１０５２が保持している呼状態、および、処理を依頼するメッセージを転送する。この例の場合、ホストコンピュータ１０９１への切り替え処理が終了する前に、その呼宛の新たなメッセージ♯２が転送されてきている（５）（６）。こうした場合、呼処理ユニット１０５２は、受信した（６）のメッセージ♯２を保持しておき、処理依頼時に、呼状態、および、最初に受信したメッセージ＃１をホストプロセッサ１０９１に転送した（７）後、保持していたメッセージ＃２も同じホストプロセッサ１０９１へ転送する（８）。
ホストプロセッサ１０９１に処理依頼中に、該当する呼宛てのメッセージ＃３が呼処理ユニット１０５２に転送されてきた場合（９）（１０）、呼処理ユニット１０５２は呼状態記憶部１０８２に格納された呼状態管理表を参照して、該当するホストプロセッサ１０９１にメッセージ♯３を転送する（１１）。
【００２８】
もし、ホストプロセッサ１０９１へ転送したメッセージ＃３がホストプロセッサ１０９１に到着する前に、ホストプロセッサ１０９１からの処理終了を表す終了通知（切り替え要求）が通知される（１２）と、メッセージ配信の不整合が発生する。しかし、この不整合は、ステップＢ１において転送メッセージ数を比較することで呼処理ユニット１０５２が発見できるため、終了（切り替え）の否認を行う（１３）。
終了の否認を受けたホストプロセッサ１０９１は、メッセージ＃３に対する処理を行った後、再び、終了通知（切り替え要求）を通知する。今度は、ステップＢ１においてメッセージ転送数が一致しているため、終了通知（切り替え）は承認され、呼処理ユニット１０５２へ処理後の呼状態が送信される。呼処理ユニット１０５２は呼状態記憶部１０８２の該当するエントリーを更新する。
【００２９】
以上述べた本発明の第１の実施の形態によれば、所定種類の処理のみを行う複数の呼処理ユニット１０５１、１０５２・・・を備えることによってマルチプロセッサ構成としているので、呼処理ユニットを追加することにより、処理単位ごとの追加を容易に行うことができ、したがって、規模拡張性を実現することが可能になる。この場合、前記所定種類の処理は複数の機能の処理であってもよい。
また、制御系装置を、単機能を処理する複数の呼処理モジュール部１０５１、１０５２、・・・と、複雑処理に対応する少なくとも１つのホストプロセッサ部１０９１、１０９２、・・・とに分離し、規模拡張性、および、機能拡張性に優れ、制御系処理能力をさらに高めたマルチプロセッサ型呼処理システムを構築することが可能になる。
【００３０】
さらに、フロントエンドに配置した呼処理ユニット１０５１、１０５２、・・・は、呼状態記憶部１０８１、１０８２、・・・内の呼状態管理表にアクセスしながら、単純な呼処理を高速に実現しているため、効率的な呼処理を実現することが可能になる。
さらにまた、呼処理ユニット１０５１、１０５２、・・・は単純な呼処理機能を提供すればよいので、その回路規模を小さくでき、それを複数追加することで、処理性能を低コストで向上させられるため、システムを低コストで実現することが可能になる。
また、プロトコル拡張は、ホストプロセッサ上のソフトウェア変更で対応できるため、柔軟な機能拡張を実現することが可能になる。
【００３１】
次に、本発明の第２の実施の形態について説明する。本第２の実施の形態のハードウェア構成は前記第１の実施の形態と同一であり、図１のように構成されれる。
本第２の実施の形態が前記第１の実施の形態と異なる点は、呼処理ユニット１０５１、１０５２、・・・がホストプロセッサ１０９１、１０９２、・・・に呼処理依頼中の場合、図１３の破線で示すように、振り分け部１０１がメッセージを、依頼処理を行っているホストプロセッサ１０９１、１０９２、・・・に直接転送する点である。
【００３２】
図１４は、呼処理ユニット１０５１、１０５２、・・・のメッセージ送受信部１０７１、１０７２、・・・にメッセージが到着してからの処理手順を示すフローチャートである。各呼処理ユニット１０５１、１０５２、・・・の呼処理プロセッサ部１０６１、１０６２、・・・が図１４に示した処理を行う。各呼処理プロセッサ部１０６１、１０６２、・・・は各々図１４に示す処理を行うため、呼処理ユニット１０５１の処理を例にとって説明する。
図１４において、ステップＡ１からステップＡ１２の各処理は前記第１の実施の形態の処理動作と同一であるため説明を省略する。
ステップＡ６で判断した結果、振り分け部１０１から受信したメッセージを該呼処理ユニット１０５１で処理できない場合、ホストプロセッサ１０９１、１０９２、・・・のいずれかに処理を依頼する。前記第１の実施の形態と異なるのは、処理依頼の後、呼処理プロセッサ部１０６１が、振り分け部１０１の中にある呼処理ユニット状態管理部１０４を書き替えて更新する点である（ステップＣ１）。即ち、呼処理ユニット１０５１がホストプロセッサに処理を依頼した後、呼処理プロセッサ部１０６１は、呼処理ユニット状態管理部１０４の記憶内容を、該呼に対する処理をホストプロセッサに依頼した旨及び依頼したホストプロセッサの番号を書き込む。
【００３３】
ステップＣ１の処理後、振り分け部１０１に、該当する呼宛てのメッセージが届いた場合に、メッセージ解析部１０３は、呼処理ユニット状態管理部１０４を参照して、図１３の破線で示すように、該当する呼の処理を、該当するホストプロセッサに依頼するため、前記メッセージを直接転送する。
また、ステップＡ３において該当する呼が“ホストプロセッサで処理中”の場合はエラーとなる（ステップＥ１）。これはステップＣ１により、振り分け部１０１の動作を変更させているため、呼処理ユニット１０５１へメッセージが転送されることがありえないためである。なお、第１の実施の形態で用いていた、各呼処理ユニット１０５１、１０５２、・・・が備える転送メッセージカウンタは、本実施の形態では用いない。
【００３４】
なお、ホストプロセッサでの処理が正常に終了した場合、振り分け部１０１の処理動作を変更し、ホストプロセッサ宛てにはメッセージを転送しないようにさせる必要がある。図１５に呼処理ユニット１０５１がホストプロセッサからの処理結果を受信した後の動作手順を示す。ステップＢ２からステップＢ５までは前記第１の実施の形態の処理手順と同一であるため説明を省略する。ホストプロセッサでの処理が正常に終了して終了通知を受信した場合、ステップＤ１で呼処理ユニット状態管理部１０４の記憶内容を、処理を完了した前記ホストプロセッサ宛てにメッセージを送信しないように変更する。
【００３５】
図１６に本第２の実施の形態におけるシステム全体の動作例を示す。この例では、ある呼に対応するメッセージが、呼ＩＤに対応する呼処理ユニット１０５２へ伝達されたものの、呼処理ユニット１０５２では該メッセージの処理ができず、ホストプロセッサ１０９１へ処理を依頼する例を示している。
図１６に示す第２の実施の形態のシステム全体の処理動作が、図７に示す前記第１の実施の形態の処理動作と異なる点は、図１６の（４）において呼処理ユニット１０５２がホストプロセッサ１０９１から処理依頼（切り替え）承認を受けた後に、（５）で振り分け部１０１に、該呼に対する処理をホストプロセッサ１０９１に処理依頼した旨の（切り替え）通知を送信して、振り分け部１０１の呼処理ユニット状態管理部１０４を変更する点である（図１４のステップＣ１）。この操作により、（１１）でメッセージ＃３が振り分け部１０１に到着した後、該メッセージ♯３は、図１３の破線で示すように、振り分け部１０１からホストプロセッサ１０９１へ直接転送される。ただし、ホストプロセッサ部１０９１から呼処理ユニット部１０５２へ処理切り替えを行った後なので、（１６）でホストプロセッサ１０９１へ転送されたメッセージを呼処理ユニット１０５２へ転送しなおしている。
【００３６】
ホストプロセッサ１０９１に依頼していた処理が終了し、呼処理ユニット１０５２が終了（切り替え）を承認した後（１３）には、処理終了（切り替え）を承認した旨を振り分け部１０１に通知し（１４）、振り分け部１０１は呼処理ユニット状態管理部１０４に記憶した呼処理ユニット状態を更新する（Ｄ１）。この操作により、これ以降は、該当する呼に対するメッセージは、呼処理ユニット部１０５１、１０５２、・・・だけに転送されることになる。
【００３７】
また、図１７に第２の実施の形態のシステム全体の処理動作の別の例を示す。この例では、（４）で呼処理ユニット１０５２がホストプロセッサ１０９１から切り替え承認を受けた後、（１０）で呼状態とメッセージ＃１を転送する前に、メッセージ＃３が振り分け部１０１からホストプロセッサ１０９１へ転送されている。この場合ホストプロセッサ１０９１は転送されてきたメッセージ＃３を、（１０）および（１１）でそれぞれ呼状態、メッセージ＃１、および、メッセージ＃２が転送されてくるまで保持しておいて、メッセージ番号順に処理を行う。このメッセージ番号はＳＩＰで定義されているシーケンス番号ヘッダ情報（ＣＳeq）を用いる。また、振り分け部１０１が各呼に対するメッセージにそれぞれ付加することもできる。
同じように（２０）でホストプロセッサ１０９１が呼処理ユニット１０５２にメッセージ＃4を転送する前に、（１９）で、振り分け部１０１から呼処理ユニット１０５２にメッセージ＃５が転送されている。この場合も、呼処理ユニット１０５２は（２０）でメッセージ＃４が転送されてきた後で、メッセージ＃５の処理を行う。
以上のように、本第２の実施の形態によれば、ホストプロセッサ１０９１、１０９２、・・・で処理すべきメッセージが呼処理ユニット１０５１、１０５２、・・・を経由せずにホストプロセッサ１０９１、１０９２、・・・に直接到達するため、ホストプロセッサ１０９１、１０９２、・・・での処理開始時間を短縮できるので、前記第１の実施の形態と比較して、ホストプロセッサ部１０９１、１０９２、・・・での処理遅延が減少し、結果としてシステムの処理性能を向上することが可能になる。
【００３８】
次に、本発明の第３の実施の形態について説明する。本第３の実施の形態のハードウェア構成は前記第１の実施の形態と同一であり、図１のように構成されれる。
本第３の実施の形態が前記第１の実施の形態と異なる点は、呼処理ユニット１０５１、１０５２、・・・がホストプロセッサ１０９１、１０９２、・・・に呼処理依頼中の場合、図１２の破線で示すように、振り分け部１０１がメッセージを、呼処理ユニット１０５１、１０５２、・・・だけでなく、ホストプロセッサ１０９１、１０９２、・・・にも転送する点である。
【００３９】
図８は、呼処理ユニット１０５１、１０５２、・・・のメッセージ送受信部１０７１、１０７２、・・・にメッセージが到着してからの処理手順を示すフローチャートである。各呼処理ユニット１０５１、１０５２、・・・の呼処理プロセッサ部１０６１、１０６２、・・・が図８に示した処理を行う。各呼処理プロセッサ部１０６１、１０６２、・・・は、図８に示す処理を行うため、呼処理ユニット１０５１の処理を例にとって説明する。
図８において、ステップＡ１からステップＡ１２、および、ステップＡ１３の各処理は前記第１の実施の形態の処理動作と同一であるため説明を省略する。
ステップＡ６で判断した結果、振り分け部１０１から受信したメッセージを該呼処理ユニット１０５１で処理できない場合、ホストプロセッサ１０９１、１０９２、・・・のいずれかに処理を依頼する。前記第１の実施の形態と異なるのは、処理依頼の後、呼処理プロセッサ部１０６１が、振り分け部１０１の中にある呼処理ユニット状態管理部１０４を書き替えて更新する点である（ステップＣ１）。即ち、呼処理ユニット１０５１がホストプロセッサに処理を依頼した後、呼処理プロセッサ部１０６１は、呼処理ユニット状態管理部１０４の記憶内容を、該呼に対する処理をホストプロセッサに依頼した旨及び依頼したホストプロセッサの番号を書き込む。
【００４０】
ステップＣ１の処理後、振り分け部１０１に、該当する呼宛てのメッセージが届いた場合に、メッセージ解析部１０３は、呼処理ユニット状態管理部１０４を参照して、図１２の破線で示すように、該当する呼の処理を振り分けた呼処理ユニット１０５１だけでなく、該当するホストプロセッサにも前記メッセージを転送する。
また、ステップＡ３において該当する呼が“ホストプロセッサで処理中”の場合、呼処理プロセッサ部１０６１は、呼状態記憶部１０８１の該当するエントリーに含まれる転送メッセージ数を１つ増やした後、そのメッセージは廃棄してしまう（ステップＣ２）。これはステップＣ１により、振り分け部１０１の動作を変更させているため、呼処理ユニット１５０１がメッセージを転送せずとも、同じメッセージが該当するホストプロセッサに到着しているためである。
【００４１】
なお、ホストプロセッサでの処理が正常に終了した場合、振り分け部１０１の処理動作を変更し、ホストプロセッサ宛てにはメッセージを転送しないようにさせる必要がある。図９に呼処理ユニット１０５１がホストプロセッサからの処理結果を受信した後の動作手順を示す。ステップＢ１からステップＢ５までは前記第１の実施の形態の処理手順と同一であるため説明を省略する。ホストプロセッサでの処理が正常に終了して終了通知を受信した場合、ステップＤ１で呼処理ユニット状態管理部１０４の記憶内容を、処理を完了した前記ホストプロセッサ宛てにメッセージを送信しないように変更する。
【００４２】
図１０に本第３の実施の形態におけるシステム全体の動作例を示す。この例では、ある呼に対応するメッセージが、呼ＩＤに対応する呼処理ユニット１０５２へ伝達されたものの、呼処理ユニット１０５２では該メッセージの処理ができず、ホストプロセッサ１０９１へ処理を依頼する例を示している。
図１０に示す第３の実施の形態のシステム全体の処理動作が、図７に示す前記第１の実施の形態の処理動作と異なる点は、図１０の（４）において呼処理ユニット１０５２がホストプロセッサ１０９１から処理依頼（切り替え）承認を受けた後に、（５）で振り分け部１０１に、該呼に対する処理をホストプロセッサ１０９１に処理依頼した旨の（切り替え）通知を送信して、振り分け部１０１の呼処理ユニット状態管理部１０４を変更する点である（図８のステップＣ１）。この操作により、（１０）でメッセージ＃３が振り分け部１０１に到着した後、該メッセージ♯３は、図１２の破線で示すように、振り分け部１０１から呼処理ユニット部１０５２およびホストプロセッサ部１０９１の両方に送信（バイキャスト）される。
【００４３】
ホストプロセッサ１０９１に依頼していた処理が終了し、呼処理ユニット１０５２が終了（切り替え）を承認した後（１６）には、処理終了（切り替え）を承認した旨を振り分け部１０１に通知し（１７）、振り分け部１０１は呼処理ユニット状態管理部１０４に記憶した呼処理ユニット状態を更新する（Ｄ１）。この操作により、これ以降は、該当する呼に対するメッセージは、呼処理ユニット部１０５１、１０５２、・・・だけに転送されることになる。
以上のように、本第３の実施の形態によれば、ホストプロセッサ１０９１、１０９２、・・・で処理すべきメッセージが呼処理ユニット１０５１、１０５２、・・・を経由せずにホストプロセッサ１０９１、１０９２、・・・に直接到達するため、ホストプロセッサ１０９１、１０９２、・・・での処理開始時間を短縮できるので、前記第１の実施の形態と比較して、ホストプロセッサ部１０９１、１０９２、・・・での処理遅延が減少し、結果としてシステムの処理性能を向上することが可能になる。
【００４７】
なお、前述した各実施の形態は種々の変更が可能である。例えば、前記各実施の形態において、呼処理ユニット部１０５１、１０５２、・・・がキャンセル要求メッセージ等の所定の処理には対応しておらず、前記キャンセル要求メッセージの処理をホストプロセッサ１０９１、１０９２、・・・に依頼した場合、ホストプロセッサ１０９１、１０９２、・・・までキャンセル要求メッセージが伝達された後、ホストプロセッサ１０９１、１０９２、・・・でキャンセル処理を行い、その結果を呼処理ユニット部１０５１、１０５２、・・・へ伝えるように処理が行われる。それに対して、振り分け部１０１もしくは呼処理ユニット部１０５１、１０５２、・・・が呼設定処理をキャンセルする要求を受け取った場合、振り分け部１０１もしくは呼処理ユニット部１０５１、１０５２、・・・が直ちにキャンセル要求に対する応答を行い、関連する処理（該当する呼状態管理表のエントリーのクリア）は呼処理ユニット部１０５１、１０５２、・・・が応答の後に行うようにしてもよい。これにより、キャンセル要求メッセージ等の所定のメッセージに対する処理遅延を短縮できる。
【００４８】
また、ホストプロセッサ１０９１、１０９２、・・・が呼処理の依頼を受けて呼処理した際、ホストプロセッサ１０９１、１０９２、・・・が前記呼処理を依頼した呼処理ユニット部１０５１、１０５２、・・・では処理できないメッセージが後続すると判断した場合、それらメッセージの処理が該ホストプロセッサで全て終了した後、処理終了通知を、依頼した呼処理ユニットに送信するようにしてもよい。
例えば、ホストプロセッサから、依頼した呼処理ユニットに対して、処理終了許可のリクエストメッセージを送信し、該呼処理ユニットからレスポンスメッセージを受信するまでは、呼処理を依頼した呼処理ユニット部では処理できないメッセージが後続すると判断するようにすればよい。これにより、ホストプロセッサと呼処理ユニットとの間での切り替え回数を低減することができ、処理時間を短縮することが可能になる。
【００４９】
また、呼処理ユニット１０５１、１０５２、・・・を処理機能単位（例えば、転送処理機能、名前解決機能等）で構成するようにしてもよい。これにより、機能毎の性能に応じた拡張を実現できるため、ある機能に対する処理性能が不足している場合、対応する処理機能を実現する呼処理ユニットを追加すればよい。また、機能実装の変更に対する柔軟な対応が可能になるため、ある機能の実装方式が変更になった場合にも、ユニットを交換するだけで対応可能になる。
【００５０】
【発明の効果】
本発明によれば、規模拡張性、および、機能拡張性に優れ、高速処理可能なマルチプロセッサ型呼処理方式を提供することが可能になる。
【図面の簡単な説明】
【図１】  本発明の第１乃至第３の実施の形態に使用するマルチプロセッサ型呼処理システムのブロック図である。
【図２】  本発明の実施の形態に使用する呼状態管理表を示す図である。
【図３】  本発明の第１の実施の形態における処理を示すフローチャートである。
【図４】  本発明の実施の形態で使用する依頼メッセージを示す図である。
【図５】  本発明の実施の形態で使用する処理結果メッセージを示す図である。
【図６】  本発明の第１の実施の形態における処理を示すフローチャートである。
【図７】  本発明の第１の実施の形態における処理を示す説明図である。
【図８】  本発明の第３の実施の形態における処理を示すフローチャートである。
【図９】  本発明の第３の実施の形態における処理を示すフローチャートである。
【図１０】  本発明の第３の実施の形態における処理を示す説明図である。
【図１１】  本発明の第１の実施の形態に使用するマルチプロセッサ型呼処理システムの説明図である。
【図１２】  本発明の第３の実施の形態に使用するマルチプロセッサ型呼処理システムの説明図である。
【図１３】  本発明の第２の実施の形態における処理を示す説明図である。
【図１４】  本発明の第２の実施の形態における処理を示すフローチャートである。
【図１５】  本発明の第２の実施の形態における処理を示すフローチャートである。
【図１６】  本発明の第２の実施の形態における処理を示す説明図である。
【図１７】  本発明の第２の実施の形態における処理を示す説明図である。
【符号の説明】
１０１・・・振り分け手段を構成する振り分け部
１０２、１０７１、１０７２・・・メッセージ送受信手段を構成するメッセージ送受信部
１０３・・・メッセージ解析手段を構成するメッセージ解析部
１０４・・・第２の記憶手段を構成する呼処理ユニット状態管理部
１０５１、１０５２・・・呼処理手段を構成する呼処理ユニット部
１０６１、１０６２・・・呼処理プロセッサ手段を構成する呼処理プロセッサ部
１０８１、１０８２・・・第１の記憶手段を構成する呼状態記憶部
１０９１、１０９２・・・ホストプロセッサ手段を構成するホストプロセッサ部
１１０・・・加入者データベース
【図１】
0003705121.tif 000002
【図２】
0003705121.tif 000003
【図３】
0003705121.tif 000004
【図４】
0003705121.tif 000005
【図５】
0003705121.tif 000006
【図６】
0003705121.tif 000007
【図７】
0003705121.tif 000008
【図８】
0003705121.tif 000009
【図９】
0003705121.tif 000010
【図１０】
0003705121.tif 000011
【図１１】
0003705121.tif 000012
【図１２】
0003705121.tif 000013
【図１３】
0003705121.tif 000014
【図１４】
0003705121.tif 000015
【図１５】
0003705121.tif 000016
【図１６】
0003705121.tif 000017
【図１７】
0003705121.tif 000018