(57)【特許請求の範囲】
【請求項１】
発側端末から発呼されたリクエストを処理して発呼先の着側端末へと出力する呼処理サーバであって、
前記呼処理サーバは、
前記リクエストを処理するための１つ以上のスレッドを１つのパイプラインのステージとして、前記発側端末からの前記リクエストの入力を受け付けるステージから前記着側端末へ前記リクエストを出力するステージまで、複数段のステージが順に接続される前記パイプラインを構成し、
前記パイプラインのステージを構成するスレッド集合は、ステージの開始スレッドから終了スレッドまでが、順序が連続したスレッド集合であり、かつ、前記ステージの終了スレッドは、データアクセスを行うスレッド、または、前記ステージが属するプロセス内の最終スレッドであり、
前記パイプラインの各ステージにおいて、前段のステージと後段のステージとの間に前記リクエストを一時的に保持するキューを記憶手段内に設け、
前記前段のステージが処理した前記リクエストを、前記後段のステージとの間に位置する前記キューへと出力し、前記後段のステージは、前記前段のステージとの間に位置する前記キューから前記前段のステージが処理した前記リクエストを読み込んで処理することを特徴とする
呼処理サーバ。
【請求項２】
前記呼処理サーバは、前記パイプラインの各ステージを１つ以上のスレッドから構成されるスレッドプールとして構成し、前記リクエストを前記キューから読み出した後に、当該リクエストを処理するスレッドを、前記スレッドプールに属するスレッドから選択することを特徴とする
請求項１に記載の呼処理サーバ。
【請求項３】
発側端末から発呼されたリクエストを処理して発呼先の着側端末へと出力する呼処理サーバによる呼処理方法であって、
前記呼処理サーバは、
前記リクエストを処理するための１つ以上のスレッドを１つのパイプラインのステージとして、前記発側端末からの前記リクエストの入力を受け付けるステージから前記着側端末へ前記リクエストを出力するステージまで、複数段のステージが順に接続される前記パイプラインを構成し、
前記パイプラインのステージを構成するスレッド集合は、ステージの開始スレッドから終了スレッドまでが、順序が連続したスレッド集合であり、かつ、前記ステージの終了スレッドは、データアクセスを行うスレッド、または、前記ステージが属するプロセス内の最終スレッドであり、
前記パイプラインの各ステージにおいて、前段のステージと後段のステージとの間に前記リクエストを一時的に保持するキューを記憶手段内に設け、
前記前段のステージが処理した前記リクエストを、前記後段のステージとの間に位置する前記キューへと出力し、前記後段のステージは、前記前段のステージとの間に位置する前記キューから前記前段のステージが処理した前記リクエストを読み込んで処理することを特徴とする
呼処理方法。
【請求項４】
前記呼処理サーバは、前記パイプラインの各ステージを１つ以上のスレッドから構成されるスレッドプールとして構成し、前記リクエストを前記キューから読み出した後に、当該リクエストを処理するスレッドを、前記スレッドプールに属するスレッドから選択することを特徴とする
請求項３に記載の呼処理方法。
【請求項５】
請求項３または請求項４に記載の呼処理方法を、コンピュータである前記呼処理サーバに実行させるための呼処理プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、呼処理サーバ、呼処理方法、および、呼処理プログラムの技術に関する。
【背景技術】
【０００２】
ＩＰ（Internet Protocol）ネットワークが高負荷になっても、そのＩＰネットワーク上での呼処理を迅速に行うことは、呼を利用するユーザに提供するサービスの品質において、重要である。例えば、特許文献１において、ＩＰネットワークでの呼処理サーバに関し、優先度の異なる２種類以上のキューを用意することで、呼処理時のキュー取り出しにおいて接続リクエストの実行を切断リクエストの実行よりも優先する通信制御処理実行方式が開示されている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００７−３２９６１７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかしながら、特許文献１では、優先度の高い接続リクエストを先に実行し、優先度の低い切断リクエストを後回しにするように順序変更するだけなので、リクエストの処理時間は、システム全体としては、効率化されていない。
ＩＰネットワークの高速化により、接続要求や、切断要求などのリクエストの数も増え続けている現状では、単位時間あたりに処理できるリクエスト数（スループット）を向上させて、多くのリクエストを処理するシステムが求められている。
【０００５】
そこで、本発明は、複数の呼処理のリクエストを高速で処理することを、主な目的とする。
【課題を解決するための手段】
【０００８】
前記課題を解決するために、本発明は、発側端末から発呼されたリクエストを処理して発呼先の着側端末へと出力する呼処理サーバであって、前記呼処理サーバが、前記リクエストを処理するための１つ以上のスレッドを１つのパイプラインのステージとして、前記発側端末からの前記リクエストの入力を受け付けるステージから前記着側端末へ前記リクエストを出力するステージまで、複数段のステージが順に接続される前記パイプラインを構成し、前記パイプラインのステージを構成するスレッド集合が、ステージの開始スレッドから終了スレッドまでは、順序が連続したスレッド集合であり、かつ、前記ステージの終了スレッドが、データアクセスを行うスレッド、または、前記ステージが属するプロセス内の最終スレッドであり、前記パイプラインの各ステージにおいて、前段のステージと後段のステージとの間に前記リクエストを一時的に保持するキューを記憶手段内に設け、前記前段のステージが処理した前記リクエストを、前記後段のステージとの間に位置する前記キューへと出力し、前記後段のステージが、前記前段のステージとの間に位置する前記キューから前記前段のステージが処理した前記リクエストを読み込んで処理することを特徴とする。
【０００９】
これにより、パイプラインのステージ数を適度な数としつつ、データアクセスなどの処理量が多くなりそうな箇所でステージを分割するため、ステージ間の処理のオーバーヘッドが大きな場合でも、呼処理サーバ全体のスループットを向上させることができる。
【００１０】
本発明は、前記呼処理サーバが、前記パイプラインの各ステージを１つ以上のスレッドから構成されるスレッドプールとして構成し、前記リクエストを前記キューから読み出した後に、当該リクエストを処理するスレッドを、前記スレッドプールに属するスレッドから選択することを特徴とする。
【００１１】
これにより、１つのステージが、複数の同種類のスレッドを構成するスレッドプールにより構成されるので、処理が集中するステージでも、多くのスレッドをスレッドプールから割り当てることができ、呼処理サーバ全体のスループットを向上させることができる。
【発明の効果】
【００１２】
本発明によれば、複数の呼処理のリクエストを高速で処理することができる。
【図面の簡単な説明】
【００１３】
【図１】本発明の一実施形態に関する呼処理システムを示す構成図である。
【図２】本発明の一実施形態に関する呼処理システムの各構成要素を示す構成図である。
【図３】本発明の一実施形態に関する呼処理サーバ内の各処理部を実現するソフトウェア構成を示す。
【図４】本発明の一実施形態に関する方式２のパイプライン構成を作成するためのフローチャートである。
【発明を実施するための形態】
【００１４】
以下、本発明の一実施形態について、図面を参照して詳細に説明する。
【００１５】
図１は、呼処理システムを示す構成図である。図１（ａ）の呼処理システムは、発側サーバ２と、着側サーバ３とが、別々の筐体で構成される例であり、発呼信号（ＳＩＰ（Session Initiation Protocol）のＩＮＶＩＴＥなど）の通過順に、発側端末１、発側サーバ２、コアルータ５、着側サーバ３、着側端末４が接続されて構成されている。発側端末１は、発側サーバ２に収容される発信者の端末であり、着側端末４は、着側サーバ３に収容される着信者の端末である。コアルータ５は、発呼信号を転送するＩＰネットワーク９内の装置である。
【００１６】
発側サーバ２および着側サーバ３は、ＩＰネットワーク９内でＩＮＶＩＴＥを転送する呼処理サーバとして動作する。呼処理サーバは、ＩＭＳ（IP multimedia subsystem）におけるＣＳＣＦ（Call State Control Function）のような呼処理制御を行う装置である。
ＣＳＣＦとは、ユーザ間や、ユーザと各種サーバとの間の通信パスであるセッション設定制御や、アプリケーションサーバへのアクセスによるサービス処理の起動を行う機構である。
【００１７】
発側サーバ２は、発側端末１からＩＮＶＩＴＥを受信すると、発側サーバ２内に記憶されている加入者情報やサービス情報などのＩＮＶＩＴＥを処理するための情報を読み込み、読み込んだ情報と受信したＩＮＶＩＴＥとをもとに、ユーザを確認し、どのようなサービスを利用しようとしているのか、また、誰と接続しようとしているのかなどを解析する。
【００１８】
なお、図１の呼処理システムを構成する各装置は、ＣＰＵ（Central Processing Unit）とメモリとハードディスク（記憶手段）とネットワークインタフェースを有するコンピュータとして構成され、このコンピュータは、ＣＰＵが、メモリ上に読み込んだプログラムを実行することにより、各処理部を動作させる。
【００１９】
図１（ｂ）の呼処理システムは、発側サーバ２と、着側サーバ３とが、同一筐体で構成される例である。例えば、発側端末１と着側端末４とが同一市内に位置するときには、図１（ｂ）に示すようにコアルータ５を介さない通信が行われる。
【００２０】
図２は、呼処理システムの各構成要素を示す構成図である。図２の片方向の矢印は、リクエストの流れを示す。
【００２１】
発側サーバ２は、ヘッダ解析部１１と、機種分析部１２と、発機種情報ＤＢ（Data Base）１３と、信号分析部１４と、発加入者情報収集部１５と、加入者情報ＤＢ１６と、番号分析部１７と、番号情報ＤＢ１８と、発帯域予約部１９と、発帯域予約ＤＢ２０と、発サービス分析部２１とを有する。
着側サーバ３は、着機種情報ＤＢ３３と、着加入者情報収集部３５と、着帯域予約部３９と、着帯域予約ＤＢ４０と、着サービス分析部４１と、着サービスインターワーク部４２とを有する。
【００２２】
まず、発側サーバ２の各処理部および各データについて、説明する。
【００２３】
ヘッダ解析部１１は、発側端末１からのリクエストを受信すると、そのリクエストがＳＩＰのヘッダコードを有しているか否かを確認する。有しているときには、リクエストを機種分析部１２へ通知する。
機種分析部１２は、リクエストの通知を受けると、発機種情報ＤＢ１３を参照することで、そのリクエストを送信した発側端末１の機種を確認する。なお、発機種情報ＤＢ１３には、機種のリストが格納されている。本パイプラインで処理する機種からのリクエストであるときには、リクエストを信号分析部１４へ通知する。
信号分析部１４は、リクエストの通知を受けると、そのリクエストのヘッダの中身が正常か（破損していないか、など）を確認する。正常であるときには、リクエストを発加入者情報収集部１５へ通知する。
【００２４】
発加入者情報収集部１５は、リクエストの通知を受けると、加入者情報ＤＢ１６を参照することで、リクエストを送信した発側端末１の発加入者について、その発加入者が正規のユーザか否か、および、発加入者がリクエストを発行できるようなサービスに加入しているか否か、などを認証する。なお、加入者情報ＤＢ１６には、電話番号やユーザＩＤなどの、発加入者の個人特定用情報や、発加入者が加入しているサービス特定用情報が格納されている。発加入者の認証が確認されたときには、リクエストを番号分析部１７へ通知する。
【００２５】
番号分析部１７は、リクエストの通知を受けると、番号情報ＤＢ１８を参照することで、リクエストで指定されている電話番号に対する番号翻訳などの番号分析処理を実行する。なお、番号翻訳とは、電話番号を先頭から順に走査し、その電話番号に応じて電話サービスやその電話サービスに関連する情報を特定する処理である。例えば、先頭から３桁「１１０」を読み取ったときには、警察連絡サービスを起動させる。
また、番号情報ＤＢ１８には、発加入者の電話番号から、その発加入者の地域や、市内局番からダイヤルしたときの閉塞番号の地域などを特定するための情報が格納されている。番号分析処理が成功したとき（本パイプラインで処理する電話番号であるとき）には、リクエストを発帯域予約部１９へ通知する。
【００２６】
発帯域予約部１９は、リクエストの通知を受けると、ＩＰネットワーク９の帯域予約を行い、その結果を発帯域予約ＤＢ２０へと書き出す。帯域予約に成功したときには、リクエストを発サービス分析部２１へ通知する。
【００２７】
発サービス分析部２１は、リクエストの通知を受けると、そのリクエストにより起動されるサービスを分析する。分析したサービスが正常である（例えば、ＩＰネットワーク９が提供可能なサービス、発加入者が利用可能なサービスなど）ときには、リクエストを着加入者情報収集部３５へ通知する。ここで、図１（ａ）のように、発側サーバ２（発サービス分析部２１）と、着側サーバ３（着加入者情報収集部３５）とが別々の筐体であるときには、リクエストをパケットとして通信する。
【００２８】
次に、着側サーバ３の各処理部および各データについて、説明する。
【００２９】
着加入者情報収集部３５は、リクエストの通知を受けると、着機種情報ＤＢ３３を参照することで、発加入者情報収集部１５と同様に、リクエストを送信した発側端末１の発加入者を認証する。また、着加入者情報収集部３５は、機種分析部１２と同様に、そのリクエストを送信した発側端末１の機種を確認する処理を行ってもよい。なお、着機種情報ＤＢ３３には、発機種情報ＤＢ１３および加入者情報ＤＢ１６と同じデータが格納されている。発加入者の認証が確認されたときには、リクエストを着サービス分析部４１へ通知する。
【００３０】
着サービス分析部４１は、リクエストの通知を受けると、発サービス分析部２１と同様に、そのリクエストにより起動されるサービスを分析する。分析したサービスが正常であるときには、リクエストを着帯域予約部３９へ通知する。
着帯域予約部３９は、リクエストの通知を受けると、発帯域予約部１９と同様に、ＩＰネットワーク９の帯域予約を行い、その結果を着帯域予約ＤＢ４０へと書き出す。帯域予約に成功したときには、リクエストを着サービスインターワーク部４２へ通知する。
【００３１】
着サービスインターワーク部４２は、発加入者側（発側端末１、発側サーバ２）と、着加入者側（着側サーバ３、着側端末４）とのサービスのインターワークを実行する。インターワークとは、発加入者と着加入者のサービスを合わせるための処理であり、具体的には、発番号に応じて、着側のサービスを変更する処理を指す。
例えば、発側で「番号通知あり」が指定されていても、着側で「番号通知なし」の指定があるときには、番号通知サービスを無効化する旨のインターワークを行う。
または、発側で「番号通知あり」が指定されていても、着側端末４がナンバーディスプレイ（登録商標）機能（発信者の電話番号を着側端末４のディスプレイ上に表示する機能）に対応していなければ、番号通知サービスを無効化する旨のインターワークを行う。
【００３２】
図３は、呼処理サーバ（発側サーバ２、着側サーバ３）内の各処理部を実現するソフトウェア構成を示す。なお、図３では、図２の構成要素の一部（ヘッダ解析部１１、機種分析部１２、信号分析部１４）を抽出して説明するが、図３に記載されていない他の構成要素（番号分析部１７など）も同じソフトウェア構成により実現される。
【００３３】
呼処理サーバ（発側サーバ２、着側サーバ３）は、ヘッダ解析部１１などの各処理部を実現するために、以下のソフトウェア構成を用いる。
【００３４】
スレッドは、１つの処理部を実現するための処理単位であり、各時刻において、１つのスレッドは、１つのリクエストを処理する。スレッドの状態には、現在リクエストを処理中の状態（稼働中）と、稼働中ではない状態（待機中）とが存在する。
【００３５】
スレッドプールは、同じ種類の処理部を実現するスレッドの集合である。例えば、図３では、ヘッダ解析部１１を実現するためのヘッダ解析部スレッド１１ｓが３つ含まれているスレッドプールが例示されている。同様に、機種分析部１２を実現するための機種分析部スレッド１２ｓを含むスレッドプールや、信号分析部１４を実現するための信号分析部スレッド１４ｓを含むスレッドプールも図示されている。
【００３６】
パイプラインのステージ（パイプラインの１処理単位）は、１つ以上の直列に接続されるスレッドから構成される。例えば、図３では、３つのステージ（ヘッダ解析部１１、機種分析部１２、信号分析部１４）が図示されている。そして、前のステージと、次のステージとの間には、ステージ間でリクエストを通知するときの、処理待ちのリクエストを一時的に保持するためのキューが設けられている。
プロセスは、１段以上のステージから構成される。ステージは、前記したように、１つ以上のスレッドから構成されるため、プロセスは、１つ以上のスレッドから構成される。
【００３７】
パイプラインの各ステージを構成するスレッドは、キューから入力されたリクエストを処理し、その処理結果に応じて、次に進むスレッドを選択する。
例えば、ヘッダ解析部スレッド１１ｓが、ＩＮＶＩＴＥのリクエストを処理したときには、次のステージである機種分析部スレッド１２ｓ（が読み込むキュー）へとリクエストを出力する。これは、ヘッダ解析部スレッド１１ｓを含むパイプラインが、ＩＮＶＩＴＥのリクエストを処理可能なパイプラインであるためである。
【００３８】
一方、ヘッダ解析部スレッド１１ｓが、ＢＹＥのリクエストを処理したときには、例外処理を行うヘッダ解析部例外処理スレッド１１ｅへとリクエストを出力することで、パイプラインから脱却させる。これは、ヘッダ解析部スレッド１１ｓを含むパイプラインが、ＢＹＥのリクエストの処理に対応していないためである。
例外処理を行うスレッドは、例えば、入力されたリクエストをエラーとして、そのエラー出力を発側端末１に返却してもよいし、入力されたリクエストを処理可能な別のスレッド（別のパイプラインでもよい）へ、処理を依頼（委譲）してもよい。
機種分析部スレッド１２ｓも同様に、パイプラインが処理可能な機種Ａのリクエストをパイプラインの後段へ出力し、パイプラインが処理不可能な機種Ｂのリクエストをパイプライン外の例外処理スレッドへ出力するように振り分ける。
【００３９】
以上、図３で説明したように、パイプラインのステージを構成するスレッドをどのようにするかにより、パイプラインの処理効率が決定される。一般的には、パイプラインのステージ数が多いほど、リクエスト処理の並列度が増えるので、処理が高速化される。ただし、前段ステージから後段ステージへのキューを介したリクエストの伝達処理などで処理のオーバーヘッドが発生することもあるので、ステージ数と並列度とは単純な比例関係ではないことが多い。処理のオーバーヘッドは、例えば、データをステージ間で受け渡すための処理時間の増加やメモリアクセスの多用により、発生する。
【００４０】
以下、パイプラインのステージ構成として、２つの方式を例示する。
【００４１】
【表１】
0005476254.tif 000002
【００４２】
表１に示す（方式１）は、Super-multistage thread poolの方式である。この方式は、１つの処理部と、１つのステージとを対応させる方式である。そのため、ステージの数が多いので、処理のオーバーヘッドが少ないときには、呼処理の並列度が多くなり、リクエストのスループットが向上する。
表１の読み方として、例えば、プロセスＰ２は、６つのステージ（ＳＡ２→ＳＡ３→ＳＡ４→ＳＡ５→ＳＡ６→ＳＡ７の順）から構成されており、そのうちのステージＳＡ２は、機種分析部１２の処理を行うスレッドにより実現される。
【００４３】
【表２】
0005476254.tif 000003
【００４４】
表２に示す（方式２）DB-access-based-multistage thread poolの方式である。この方式は、以下に示す所定の条件を満たす複数のスレッドを１つのステージでグルーピングすることにより、（方式１）よりもステージの数が少ない方式である。
・ステージの開始スレッドから終了スレッドまでが、順序が連続したスレッド集合である。
・ステージの終了スレッドは、ＤＢアクセスを行うスレッド（表のＤＢアクセス列が空欄ではない）、または、プロセスの最終スレッド（Ｐ２ならＳＢ６、Ｐ３ならＳＢ９）である。
この方式２では、ステージの数が方式１よりも少ないので、処理のオーバーヘッドが多いときでも、適度な呼処理の並列度を保つことで、リクエストのスループットが向上する。
ここで、方式２では、ＤＢアクセスを行うスレッドをステージの区切りとすることにより、１つのステージには、処理時間がかかるＤＢアクセスを行うスレッドが１つまでとなっている。これにより、パイプラインの各ステージには、ＤＢアクセスを行うスレッドが複数個存在しないため、ステージ間の処理負荷（実行時間）が均等化される。
パイプラインの性能は、各ステージの実行時間のうちの最悪の実行時間により決定されるため、ステージ間が均等化されることで、パイプライン全体の性能を低下させずに済む。
【００４５】
図４は、方式２のパイプライン構成を作成するためのフローチャートである。このフローチャートは、パイプラインを実現する呼処理サーバ（発側サーバ２など）が実行してもよいし、パイプラインを設計する開発用装置（図示省略）が実行してもよい。以下、発側サーバ２をフローチャートの動作主体として説明する。
【００４６】
Ｓ１０１として、開始スレッドを、最初のスレッド（ヘッダ解析部１１のスレッド）とし、着目スレッドを、開始スレッドとする。記号「Ａ←Ｂ」は、変数Ａに値Ｂを代入する旨を示す。
Ｓ１０２として、着目スレッドがプロセスの終端であるか否かを判定し、ＹｅｓならＳ１０５へ、ＮｏならＳ１０３へ進む。
Ｓ１０３として、着目スレッドの処理において、ＤＢへのアクセスがあるか否かを判定し、ＹｅｓならＳ１０５へ、ＮｏならＳ１０４へ進む。
Ｓ１０４として、着目スレッドを１つ先のスレッドに進める。そして、処理をＳ１０２へ戻す。
【００４７】
Ｓ１０５として、終了スレッドを着目スレッドとして、「開始スレッド〜終了スレッド」の範囲を１つのステージとする。
Ｓ１０６として、着目スレッドが最終スレッド（図２の着サービスインターワーク部４２のスレッド）であるか否かを判定し、Ｙｅｓなら処理を終了し、ＮｏならＳ１０７へ進む。
Ｓ１０７として、開始スレッドを着目スレッドの１つ先のスレッドとし、着目スレッドを開始スレッドとして、処理をＳ１０２へ戻す。
【００４８】
以上説明した本実施形態によれば、ＳＩＰのＩＮＶＩＴＥリクエストを受け付けたときの呼処理について、その呼処理を多段階のステージに分割し、各ステージを直列に接続するパイプラインを構成することにより、多くのリクエストを高速に処理する（スループットを向上させる）ことができる。
【００４９】
さらに、各ステージを構成するスレッドについて、同種類のスレッドを複数個用意してスレッドプール内に確保することにより、処理が集中するステージに多くのスレッドを割り当てることができ、パイプラインにおけるボトルネックの発生を低減できる。
なお、どのステージに処理が集中するかは、同一の処理でもＤＢの応答時間などの条件（キャッシュにあるものを利用するか、ＤＢにアクセスし取得するかなど）により処理時間が異なるため、事前に予想するよりも、動的にスレッド割当数を変動させるほうが、効果的である。
【００５０】
一方、比較例として、プロセスのパイプライン化を行わず、１スレッドだけでＩＮＶＩＴＥのリクエスト処理を行う形態が挙げられる。この比較例の形態では、リクエスト数が増えたときには、そのリクエストを並列処理せずに、１つずつ順番に処理するだけなので、スループットが落ちてしまう。
【符号の説明】
【００５１】
１      発側端末
２      発側サーバ（呼処理サーバ）
３      着側サーバ（呼処理サーバ）
４      着側端末
５      コアルータ
９      ＩＰネットワーク
１１    ヘッダ解析部
１２    機種分析部
１３    発機種情報ＤＢ
１４    信号分析部
１５    発加入者情報収集部
１６    加入者情報ＤＢ
１７    番号分析部
１８    番号情報ＤＢ
１９    発帯域予約部
２０    発帯域予約ＤＢ
２１    発サービス分析部
３３    着機種情報ＤＢ
３５    着加入者情報収集部
３９    着帯域予約部
４０    着帯域予約ＤＢ
４１    着サービス分析部
４２    着サービスインターワーク部
【図１】
0005476254.tif 000004
【図２】
0005476254.tif 000005
【図３】
0005476254.tif 000006
【図４】
0005476254.tif 000007