(57)【要約】【課題】システム内部で輻輳が生じた場合でも、正常に呼制御を行うことが可能とする。【解決手段】通信装置１は、呼制御信号を用いて呼制御を行う処理を所定の処理単位により実行する呼制御部１１と、対向通信装置２ら呼制御信号に対応したデータを受信し、呼制御部１１へ呼制御信号を送信する処理を所定の処理単位により実行するデータ受信部１２と、データ受信部１２に対し、呼制御部１１への呼制御信号の再送を要求する再送部１３と、を備えるものである。【選択図】図１
2013126240.tif 000002
【特許請求の範囲】
【請求項１】
呼制御信号を用いて呼制御を行う処理を所定の処理単位により実行する呼制御部と、
対向通信装置から前記呼制御信号に対応したデータを受信し、前記呼制御部へ前記呼制御信号を送信する処理を前記所定の処理単位により実行するデータ受信部と、
前記データ受信部に対し、前記呼制御部への前記呼制御信号の再送を要求する再送部と、
を備える通信装置。
【請求項２】
前記所定の処理単位は、スレッドであり、
前記データ受信部は、スレッド間通信により前記呼制御部へ前記呼制御信号を送信する、
請求項１に記載の通信装置。
【請求項３】
前記呼制御部は複数のスレッドを含むマルチスレッドにより構成され、
前記データ受信部は１つのスレッドを含むシングルスレッドにより構成されている、
請求項２に記載の通信装置。
【請求項４】
前記データ受信部は、前記呼制御部の前記スレッドである呼制御スレッドを捕捉できた場合に、捕捉した前記呼制御スレッドへ前記呼制御信号を送信する、
請求項２または３に記載の通信装置。
【請求項５】
前記呼制御スレッドの空き状態を管理する呼制御スレッド管理テーブルを有し、
前記データ受信部は、前記呼制御スレッド管理テーブルにおいて、前記呼制御スレッドを捕捉する、
請求項４に記載の通信装置。
【請求項６】
前記再送部は、前記データ受信部に対し、前記呼制御スレッドの捕捉を要求することで、前記データ受信部に前記呼制御信号を再送させる、
請求項４または５に記載の通信装置。
【請求項７】
前記データ受信部から前記呼制御部へ前記呼制御信号の送信が失敗した場合に、前記呼制御信号を再送するための再送情報を記録する再送情報記録部を有し、
前記再送部は、定期的に前記再送情報記録部を参照し、前記再送情報記録部に前記再送情報が記録されている場合に、前記データ受信部に対し再送を要求する、
請求項１乃至６のいずれか一項に記載の通信装置。
【請求項８】
第１の通信装置と第２の通信装置との間で呼制御信号を送受信する通信システムであって、
前記第１の通信装置は、
前記第２の通信装置へ第１の呼制御信号を送信する送信部を備え、
前記第２の通信装置は、
前記第１の呼制御信号に対応した第２の呼制御信号を用いて呼制御を行う処理を所定の処理単位により実行する呼制御部と、
前記第１の通信装置から前記第１の呼制御信号を受信し、前記呼制御部へ前記第２の呼制御信号を送信する処理を前記所定の処理単位により実行するデータ受信部と、
前記データ受信部に対し、前記呼制御部への前記第２の呼制御信号の再送を要求する再送部と、を備える
通信システム。
【請求項９】
通信装置において呼制御を行うための通信方法であって、
呼制御信号を用いて呼制御を行う処理を所定の処理単位により実行し、
対向通信装置から前記呼制御信号に対応したデータを受信し、前記呼制御部へ前記呼制御信号を送信する処理を前記所定の処理単位により実行し、
前記呼制御信号を送信する前記所定の処理単位に対し、前記呼制御部への前記呼制御信号の再送を要求する、
通信方法。
【請求項１０】
通信装置に通信処理を実行させるための通信プログラムであって、前記通信処理は、
呼制御信号を用いて呼制御を行う処理を所定の処理単位により実行し、
対向通信装置から前記呼制御信号に対応したデータを受信し、前記呼制御部へ前記呼制御信号を送信する処理を前記所定の処理単位により実行し、
前記呼制御信号を送信する前記所定の処理単位に対し、前記呼制御部への前記呼制御信号の再送を要求する、
通信プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信装置、通信システム、通信方法及び通信プログラムに関し、特に、呼制御を行う通信装置、通信システム、通信方法及び通信プログラムに関する。
【背景技術】
【０００２】
一般に、複数の通信装置を接続する通信システムでは、通信が集中した場合における動作を保障するため、様々な輻輳制御が行われている。例えば、輻輳等によって通信データが欠落した場合には、通信データを再送することで一定の通信品質が確保されている。一例として特許文献１には、通信装置間でメッセージを再送することが記載されている。
【０００３】
また、呼制御を行う通信装置として交換機が知られている。図７は、関連する交換機の構成を示している。図７に示すように、関連する交換機９００は、対向する通信装置との間で所定のプロトコルにより通信を行うプロトコル制御部９１０と、プロトコル制御部９１０を介して呼制御メッセージを送受信することで呼制御を行う呼制御部９２０と、を有している。呼制御部９２０は、同時に複数の呼を制御できるよう、複数の呼制御スレッド９２１によるマルチスレッド構成となっている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特表２００９−５３１７４９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
図７に示すような関連する交換機９００では、呼制御部９２０が、発呼受付時から通話中までの状態遷移、及び切断時の状態遷移の機能を具備するため、プロトコル制御部９１０よりも処理に時間を要する。したがって、関連する交換機９００では、システム構成上、データ受け渡しを主とするプロトコル制御部９１０は、呼制御部９２０に比べ処理が軽量であるため、呼制御部９２０側でのデータ受け取りが詰まり、プロトコル制御部９１０と呼制御部９２０間の通信インタフェースがボトルネックとなり、輻輳が発生する可能性がある。
【０００６】
このような輻輳を回避するため、一般的に関連する交換機はトラヒック制御機能を有しており、一例に単位時間内の発呼数と入り呼の許容呼数を超えた呼に対して規制する方法がある。この方法では、プロトコル制御部９１０にて呼受付可否判定結果を受けて、規制有無を決定している。このため、この方法を採用したとしても、規制無しと判定した後には、プロトコル制御部９１０と呼制御部９２０における処理時間の関係から、プロトコル制御部―呼制御部間の輻輳が発生する場合がある。
【０００７】
このようなシステム内の輻輳は、呼制御スレッド９２１が加入者間の通話操作と連動しているため、保留時間が異なることにも起因する。また、トラヒック制御機能のもう一例として、システムのＣＰＵ使用率を監視しシステムとしての許容呼数を変動させる規制方法もあるが、これも同様にプロトコル制御部９１０にて呼受付可否判定結果を受けて規制有無を決定しており、同じようにシステム内で輻輳が発生する場合がある。
【０００８】
また、プロトコル制御部が単一スレッドで構成され、呼制御部が複数スレッドで構成される場合においては、呼制御スレッド数が有限であることからも、データが詰まる理由となる。
【０００９】
すなわち、一般的に呼制御スレッドのスレッド数は、トラヒックモデルに連動したシステムの諸元に基づき予め必要数を定義している有限のリソースである。プロトコル制御部９１０は、有限リソースである呼制御スレッド９２１を管理するための呼制御スレッド管理テーブルを具備している。プロトコル制御部９１０は他ノードからの信号を受信した後、呼制御スレッド９２１に呼処理を要求するため、呼制御スレッド管理テーブルから空いている呼制御スレッドを確保し、メッセージを送信する。
【００１０】
このようなシステム内部における輻輳に対し、関連する交換機９００では、プロトコル制御部９１０が、呼制御スレッド９２１を管理するテーブルを参照して全てビジーであった場合に、プロトコル制御部９１０で呼制御信号を破棄していた。
【００１１】
なお、呼制御スレッド９２１がビジーとなるのを防ぐために、常に空きがあるよう呼制御スレッド数の拡張を行う対応方法も考えられるが、拡張に応じてメモリ使用量が増加することからハードウェア制限に左右されること、また、装置再開時に増加スレッド分の生成・初期化時間が増加するため、故障時間が長くなりサービス提供が遅れることになる。
【００１２】
また、図８に、システム内部の輻輳制御を行う他の関連する交換機の構成を示す。図８に示すように、他の関連する交換機９０１は、プロトコル制御部９１０、呼制御部９２０に加えて救済スレッド９３０を備えている。
【００１３】
他の関連する交換機９０１では、プロトコル制御部９１０が、通信中状態で呼制御スレッド９２１の捕捉に失敗した場合に備え、呼制御スレッド９２１の代わりに呼制御を継続する機能を有する救済スレッド９３０を予め用意する。プロトコル制御部９１０は、他ノードからの信号を受信した後、呼制御スレッド９２１に呼処理を要求するため、呼制御スレッド管理テーブルを確認するが、全てビジーの場合に救済スレッド９３０へ要求キューに追加する。要求キューに要求が溜まっていた場合、救済スレッド９３０は呼制御スレッド９２１に代わり、切断完了まで呼制御を行う。
【００１４】
しかしながら、他の関連する交換機９０１では、救済スレッド９３０が、１つの呼しか取り扱えないため、２以上の呼が発生した場合には、図７の場合と同様に輻輳が生じ、呼制御信号が破棄されるおそれがある。
【００１５】
このように、図７や図８で示したような関連する交換機では、システム内部で輻輳が生じた場合、呼制御信号を破棄するおそれがあるため、正常に呼制御を行うことができないという問題があった。本発明の目的は、このような課題を解決する通信装置、通信システム、通信方法及び通信プログラムを提供することにある。
【課題を解決するための手段】
【００１６】
本発明に係る通信装置は、呼制御信号を用いて呼制御を行う処理を所定の処理単位により実行する呼制御部と、対向通信装置から前記呼制御信号に対応したデータを受信し、前記呼制御部へ前記呼制御信号を送信する処理を前記所定の処理単位により実行するデータ受信部と、前記データ受信部に対し、前記呼制御部への前記呼制御信号の再送を要求する再送部と、を備えるものである。
【００１７】
本発明に係る通信システムは、第１の通信装置と第２の通信装置との間で呼制御信号を送受信する通信システムであって、前記第１の通信装置は、前記第２の通信装置へ第１の呼制御信号を送信する送信部を備え、前記第２の通信装置は、前記第１の呼制御信号に対応した第２の呼制御信号を用いて呼制御を行う処理を所定の処理単位により実行する呼制御部と、前記第１の通信装置から前記第１の呼制御信号を受信し、前記呼制御部へ前記第２の呼制御信号を送信する処理を前記所定の処理単位により実行するデータ受信部と、前記データ受信部に対し、前記呼制御部への前記第２の呼制御信号の再送を要求する再送部と、を備えるものである。
【００１８】
本発明に係る通信方法は、通信装置において呼制御を行うための通信方法であって、呼制御信号を用いて呼制御を行う処理を所定の処理単位により実行し、対向通信装置から前記呼制御信号に対応したデータを受信し、前記呼制御部へ前記呼制御信号を送信する処理を前記所定の処理単位により実行し、前記呼制御信号を送信する前記所定の処理単位に対し、前記呼制御部への前記呼制御信号の再送を要求するものである。
【００１９】
本発明に係る通信プログラムは、通信装置に通信処理を実行させるための通信プログラムであって、前記通信処理は、呼制御信号を用いて呼制御を行う処理を所定の処理単位により実行し、対向通信装置から前記呼制御信号に対応したデータを受信し、前記呼制御部へ前記呼制御信号を送信する処理を前記所定の処理単位により実行し、前記呼制御信号を送信する前記所定の処理単位に対し、前記呼制御部への前記呼制御信号の再送を要求するものである。
【発明の効果】
【００２０】
本発明によれば、システム内部で輻輳が生じた場合でも、正常に呼制御を行うことが可能な通信装置、通信システム、通信方法及び通信プログラムを提供することができる。
【図面の簡単な説明】
【００２１】
【図１】本発明に係る通信装置の特徴を説明するための構成図である。
【図２】本発明の実施の形態１に係る通信システムの構成を示す構成図である。
【図３】本発明の実施の形態１に係る交換機の構成を示す構成図である。
【図４】本発明の実施の形態１に係る通信システムの動作を示すシーケンス図である。
【図５】本発明の実施の形態１に係る交換機の動作を示すシーケンス図である。
【図６】本発明の実施の形態１に係る交換機の動作を示すシーケンス図である。
【図７】関連する交換機の構成を示す構成図である。
【図８】関連する交換機の構成を示す構成図である。
【発明を実施するための形態】
【００２２】
（本発明の特徴）
本発明の実施の形態の説明に先立って、図１を用いて、本発明の特徴についてその概要を説明する。
【００２３】
図１に示すように、本発明に係る通信システム１００は、データ通信可能に接続された対向通信装置２（第１の通信装置）と通信装置１（第２の通信装置）とを有している。そして、通信装置１は、呼制御信号（第２の呼制御信号）を用いて呼制御を行う処理を所定の処理単位（スレッド等）により実行する呼制御部１１と、対向通信装置２から呼制御信号に対応したデータ（第１の呼制御信号）を受信し、呼制御部１１へ呼制御信号を送信する処理を所定の処理単位により実行するデータ受信部（プロトコル制御部等）１２と、データ受信部１２に対し、呼制御部１１への呼制御信号の再送を要求する再送部１３と、を備えることを主要な特徴としている。
【００２４】
一般的な交換機などでは、トラヒック制御機能を有するものの、隣接ノードとのトラヒックをシステムのＩＦに近いところで、監視し、規制値を超えた場合に規制しており、システム内部での輻輳のような内部データ通信については監視されていないため、輻輳時に呼制御信号が破棄されて、正常に呼制御を行うことができなかった。
【００２５】
本発明の通信装置１では、データ受信部１２と呼制御部１１の各処理がスレッド等のプログラムの処理単位により実行されており、データ受信部１２と呼制御部１１とのデータ通信は、スレッド間通信のような処理単位間通信を介して行われる。そして、データ受信部１２の処理単位から呼制御部１１の処理単位へ呼制御信号の送信が失敗した場合に、再送部１３が、データ受信部１２に対しその呼制御信号の再送処理を要求する。これにより、呼制御信号が呼制御部１１へ確実に送信されるため、呼制御部１１において本来制御されるべき呼制御を正常に行うことが可能となる。
【００２６】
（本発明の実施の形態１）
以下、図面を参照して本発明の実施の形態１について説明する。まず、図２及び図３を用いて、本発明の実施の形態１に係る通信システム１００及び交換機１０の構成について説明する。
【００２７】
図２に示すように、通信システム１００は、加入者端末２０ａ、加入者側網２１ａ、交換機１０、ＳＩＰ（Session Initiation Protocol）交換網２１ｂ、ＳＩＰ端末２０ｂを備えている。交換機１０は、加入者側網２１ａを介して加入者端末２０ａに接続され、また、ＳＩＰ交換網２１ｂを介してＳＩＰ端末２０ｂに接続されている。なお、加入者端末２０ａもしくはＳＩＰ端末２０ｂのいずれかを単に端末２０と称する場合があり、加入者側網２１ａもしくはＳＩＰ交換網２１ｂのいずれかを単に網２１と称する場合がある。
【００２８】
通信システム１００では、交換機１０が、加入者端末２０ａ及び加入者側網２１ａと、ＳＩＰ端末２０ｂ及びＳＩＰ交換網２１ｂとの間で、呼制御メッセージを送受信することで呼制御プロトコルにしたがって呼制御を行うことで、加入者端末２０ａ及び加入者側網２１ａとＳＩＰ端末２０ｂ及びＳＩＰ交換網２１ｂとの間で通話等のデータ通信を可能にする。
【００２９】
加入者端末２０ａは、呼制御プロトコルとして加入者側プロトコルにしたがって、呼制御メッセージを送受信するとともに、呼接続中に接続先の端末とデータ通信を行う。例えば、加入者側プロトコルは、Ｎｏ．７共通線方式等の呼制御プロトコルである。なお、加入者端末２０ａがＮ０．７共通線方式に準拠していなくてもよく、少なくとも加入者側網２１ａと交換機１０との間がＮ０．７共通線方式に準拠していればよい。
【００３０】
加入者側網２１ａは、加入者端末２０ａと交換機１０との間で、加入者側プロトコルにしたがった呼制御メッセージ及びデータの伝送・交換を行う。なお、ここでは、加入者側網２１ａを介して加入者端末２０ａと交換機１０とを接続しているが、加入者端末２０ａを交換機１０に直接接続してもよい。
【００３１】
ＳＩＰ端末２０ｂは、呼制御プロトコルとしてＳＩＰプロトコルにしたがって、呼制御メッセージを送受信するとともに、呼接続中に接続先の端末とデータ通信を行う。なお、ＳＩＰ端末２０ｂがＳＩＰプロトコルに準拠していなくてもよく、少なくともＳＩＰ交換網２１ｂと交換機１０との間がＳＩＰプロトコルに準拠していればよい。また、ＳＩＰプロトコルは、交換網側の呼制御プロトコルの一例であり、ＳＩＰ以外のその他の呼制御プロトコルであってもよい。
【００３２】
ＳＩＰ交換網２１ｂは、ＶｏＩＰ（Voice over Internet Protocol）網等であり、ＳＩＰ端末２０ｂと交換機１０との間で、ＳＩＰプロトコルにしたがった呼制御メッセージ及びデータの伝送・交換を行う。なお、ここでは、ＳＩＰ交換網２１ｂを介してＳＩＰ端末２０ｂと交換機１０とを接続しているが、ＳＩＰ端末２０ｂを交換機１０に直接接続してもよい。
【００３３】
交換機１０は、呼制御部１０１、加入者側プロトコル制御部１０２ａ（第１のプロトコル制御部）、ＳＩＰプロトコル制御部１０２ｂ（第２のプロトコル制御部）、再送部１０３、再送情報記録部１０４、加入者管理部１０５を備えている。例えば、交換機１０は、ＣＰＵ（Central Processing Unit）、記憶装置、通信インタフェース等を備えており、ＣＰＵが所定の通信プログラムを実行することで各機能が実現されている。
【００３４】
なお、加入者側プロトコル制御部１０２ａもしくはＳＩＰプロトコル制御部１０２ｂのいずれかを単にプロトコル制御部１０２と称する場合がある。また、図２では、２つの再送部１０３及び再送情報記録部１０４を加入者側と交換網側のそれぞれに記載しているが、後述のように、加入者側と交換網側とで共通化されているため、それぞれ１つの再送部１０３及び再送情報記録部１０４として構成されている。なお、加入者側と交換網側とで別々に設けて、加入者側再送部、加入者側再送情報記録部、ＳＩＰ再送部、ＳＩＰ再送情報記録部として構成してもよい。
【００３５】
加入者管理部１０５は、加入者の契約等に基づいて登録された加入者情報や加入者回線情報を管理する。すなわち、加入者管理部１０５は、データベース等の記録部を有しており、加入者ごとに、加入者情報や加入者回線の回線リソース等が登録されている。なお、加入者情報等を登録するデータベースは、交換機１０の内部に備えていてもよいし、外部に備えていてもよい。
【００３６】
加入者側プロトコル制御部１０２ａは、加入者側網２１ａ及び加入者端末２０ａに接続され、加入者側プロトコルを終端する。加入者側プロトコル制御部１０２ａは、加入者側プロトコルにしたがって加入者端末２０ａ及び加入者側網２１ａとの間で呼制御メッセージを送受信し、また、共通プロトコルにしたがって呼制御部１０１との間で呼制御メッセージを送受信する。すなわち、加入者側プロトコル制御部１０２ａは、加入者側プロトコルにより受信した呼制御メッセージを共通プロトコルの呼制御メッセージに変換して送信し、また、共通プロトコルにより受信した呼制御メッセージを加入者側プロトコルの呼制御メッセージに変換（インタワーク）して送信する。加入者側プロトコル制御部１０２ａは、加入者管理部１０５から加入者情報や加入者回線などの必要な情報を取得し、呼制御部１０１、加入者側網２１ａ及び加入者端末２０ａへ通知する。
【００３７】
ＳＩＰプロトコル制御部１０２ｂは、ＳＩＰ交換網２１ｂ及びＳＩＰ端末２０ｂに接続され、ＳＩＰプロトコルを終端する。ＳＩＰプロトコル制御部１０２ｂは、ＳＩＰプロトコルにしたがってＳＩＰ端末２０ｂ及びＳＩＰ交換網２１ｂとの間で呼制御メッセージを送受信し、また、共通プロトコルにしたがって呼制御部１０１との間で呼制御メッセージを送受信する。すなわち、ＳＩＰプロトコル制御部１０２ｂは、ＳＩＰプロトコルにより受信した呼制御メッセージを共通プロトコルの呼制御メッセージに変換して送信し、また、共通プロトコルにより受信した呼制御メッセージをＳＩＰプロトコルの呼制御メッセージに変換（インタワーク）して送信する。
【００３８】
再送情報記録部１０４は、加入者側プロトコル制御部１０２ａ及びＳＩＰプロトコル制御部１０２ｂから呼制御部１０１へ呼制御メッセージを再送するための再送情報を記録する。すなわち、加入者側プロトコル制御部１０２ａから呼制御部１０１への呼制御メッセージの送信が失敗した場合に、加入者側プロトコル制御部１０２ａが再送情報記録部１０４に再送情報を記録する。また、ＳＩＰプロトコル制御部１０２ｂから呼制御部１０１への呼制御メッセージの送信が失敗した場合に、ＳＩＰプロトコル制御部１０２ｂが再送情報記録部１０４に再送情報を記録する。なお、再送情報記録部１０４は、交換機１０の内部に備えていてもよいし、外部に備えていてもよい。
【００３９】
再送部１０３は、再送情報記録部１０４に記録されている再送情報に基づいて、呼制御部１０１へ呼制御メッセージの再送処理を実行する。再送部１０３は、定期的に再送情報記録部１０４に記録された再送情報を監視し、加入者側プロトコル制御部１０２ａまたはＳＩＰプロトコル制御部１０２ｂへ呼制御メッセージの再送を要求する。
【００４０】
呼制御部１０１は、端末及び網側の呼制御プロトコルに依存しない共通呼処理機能を有する。すなわち、呼制御部１０１は、加入者側プロトコル及びＳＩＰプロトコルとは異なる、交換機内部で共通の共通プロトコルにしたがって動作する。呼制御部１０１は、加入者側プロトコル制御部１０２ａとＳＩＰプロトコル制御部１０２ｂとの間で、共通プロトコルにしたがって呼制御メッセージを送受信し、加入者端末２０ａ及びＳＩＰ端末２０ｂの呼制御を行う。呼制御部１０１は、加入者端末２０ａ及びＳＩＰ端末２０ｂから送信される呼制御メッセージを共通プロトコルによって受信し、宛先の特定等を行って、呼接続シーケンスや呼切断シーケンスを制御し、呼状態を管理する。
【００４１】
また、呼制御部１０１は、加入者端末２０ａ及びＳＩＰ端末２０ｂの呼状態に応じて、加入者の課金情報を管理する。呼制御部１０１は、呼接続シーケンス完了の時刻と呼切断シーケンス完了の時刻を記録し、呼接続完了から呼切断完了までの期間を課金対象の期間として管理する。なお、課金情報の記録・管理は、交換機１０の内部で行ってもよいし、外部の他の交換機や課金装置等で行ってもよい。
【００４２】
図３は、本実施形態に係る交換機１０におけるプロトコル制御部１０２、呼制御部１０１及び再送部１０３の詳細な構成を示している。加入者側プロトコル制御部１０２ａとＳＩＰプロトコル制御部１０２ｂでは、呼制御部１０１との通信部は共通処理として共通化しているため、ここでは、プロトコル制御部１０２として図示している。
【００４３】
呼制御部１０１は、複数の呼制御スレッド１１１及び呼制御テーブル１０６を備えている。呼制御テーブル１０６は、呼状態等の呼制御情報を、呼ごとに記憶・管理するためのテーブルである。呼制御部１０１は、複数の呼制御スレッド１１１から実現されるマルチスレッド構成である。１つの呼制御スレッド１１１は、１つの呼の制御処理を実行するためのスレッドである。呼制御スレッド１１１は、プロトコル制御部１０２との間で呼制御メッセージを送受信し、呼制御メッセージに応じて呼制御テーブル１０６の呼状態等を参照・更新することで呼制御を行う。
【００４４】
プロトコル制御部１０２は、プロトコル制御スレッド１１２及び呼制御スレッド管理テーブル１０７を備えている。呼制御スレッド管理テーブル１０７は、呼制御部１０１の呼制御スレッド１１１の空き状態（使用状態）を、呼制御スレッドごとに記憶・管理するためのテーブルである。
【００４５】
プロトコル制御部１０２は、１つのプロトコル制御スレッド１１２から実現されるシングルスレッド構成である。プロトコル制御スレッド１１２は、加入者側網２１ａまたはＳＩＰ交換網２１ｂから呼制御メッセージを受信し、呼制御スレッド１１１の空き状態に応じて呼制御スレッド１１１を捕捉し、捕捉した呼制御スレッド１１１へ変換後の呼制御メッセージを送信する。また、プロトコル制御スレッド１１２は、呼制御スレッド１１１に空きが無い場合、再送情報記録部１０４に呼制御メッセージの再送情報を記録する。なお、プロトコル制御部１０２は、複数のプロトコル制御スレッド１１２によりマルチスレッドで構成してもよい。
【００４６】
再送部１０３は、１つの再送スレッド１１３から実現されるシングルスレッド構成である。再送スレッド１１３は、再送情報記録部１０４の再送情報の有無を判定し、再送情報がある場合に、プロトコル制御部１０２のプロトコル制御スレッド１１２へスレッド捕捉要求を通知することで、プロトコル制御スレッド１１２から呼制御スレッド１１１へ呼制御メッセージを再送させる。なお、再送部１０３からの再送要求に対し、プロトコル制御部１０２は複数のデータを再送することができ、呼制御部の空きスレッド数まで同時に再送処理を行うことが可能である。
【００４７】
次に、図４〜図６を用いて、本発明の実施の形態１に係る通信システム１００及び交換機１０の動作について説明する。
【００４８】
まず、本発明に係る再送動作の前提となる正常な場合の動作について説明する。図４は、交換機１０内で輻輳が生じない正常な場合の呼接続シーケンス及び呼切断シーケンスを示している。なお、実際には、Ｎｏ．７共通線方式及びＳＩＰのプロトコルに準拠して、複数の呼制御メッセージが送受信されるが、ここでは説明簡略化のため、呼接続シーケンスは呼接続要求及び呼接続応答のみ、呼切断シーケンスは呼切断完了のみとして説明する。また、ここでは、加入者側から呼接続要求及び呼切断要求を送信する例について説明するが、交換網側から呼接続要求及び呼切断要求を送信する場合も同様の動作となる。
【００４９】
呼接続シーケンスでは、まず、加入者端末２０ａから呼接続が開始されると、加入者側網２１ａから交換機１０へ、加入者側プロトコルによる呼接続要求（「ＳＥＴＵＰ」メッセージ等）が送信される（Ｓ１０１）。
【００５０】
次に、交換機１０の加入者側プロトコル制御部１０２ａでは、プロトコル制御スレッド１１２が、呼接続要求を受信すると、受信した呼接続要求の信号パラメータから加入者情報・加入者回線種別を識別し、呼制御スレッド管理テーブル１０７を参照して呼制御スレッド１１１の空き状態を確認する（Ｓ１０２）。Ｓ１０２において、プロトコル制御スレッド１１２は、呼制御スレッド管理テーブル１０７により呼制御スレッド１１１に空きがある場合、呼制御スレッド１１１を捕捉する（Ｓ１０３）。
【００５１】
次に、プロトコル制御スレッド１１２は、捕捉した呼制御スレッド１１１へ、共通プロトコルによる呼接続要求を送信する（Ｓ１０４）。呼制御部１０１の呼制御スレッド１１１は、呼接続要求を受信すると、呼接続要求の信号パラメータにより接続先の網及び端末の特定等を行い、共通プロトコルによる呼接続要求をＳＩＰプロトコル制御部１０２ｂのプロトコル制御スレッド１１２へ送信する（Ｓ１０５）。なお、このとき、呼制御スレッド１１１は、呼制御テーブル１０６の呼状態を呼接続処理中に設定する。
【００５２】
次に、ＳＩＰプロトコル制御部１０２ｂのプロトコル制御スレッド１１２は、呼接続要求を受信すると、ＳＩＰプロトコルによる呼接続要求（「ＩＮＶＩＴＥ」メッセージ等）をＳＩＰ交換網２１ｂへ送信する（Ｓ１０６）。
【００５３】
次に、呼接続要求に対してＳＩＰ端末２０ｂから、呼接続の応答があると、ＳＩＰ交換網２１ｂから交換機１０へ、ＳＩＰプロトコルによる呼接続応答（「２００  ＯＫ」メッセージ等）が送信される（Ｓ１０７）。交換機１０のＳＩＰプロトコル制御部１０２ｂでは、プロトコル制御スレッド１１２が、呼接続応答を受信すると、呼接続を要求していた呼制御スレッド１１１に対し、共通プロトコルによる呼接続応答を送信する（Ｓ１０８）。
【００５４】
次に、呼制御部１０１の呼制御スレッド１１１は、呼接続応答を受信すると、共通プロトコルによる呼接続応答を加入者側プロトコル制御部１０２ａのプロトコル制御スレッド１１２へ送信する。加入者側プロトコル制御部１０２ａのプロトコル制御スレッド１１２は、呼接続応答を受信すると、加入者側プロトコルによる呼接続応答（「ＣＯＮＮＥＣＴ」メッセージ等）を加入者側網２１ａへ送信する（Ｓ１１０）。
【００５５】
これにより、呼接続シーケンスが完了して呼が接続され、加入者端末２０ａとＳＩＰ端末２０ｂとの間でデータ通信が可能となる。このとき、呼制御部１０１では、呼制御スレッド１１１が、呼制御テーブル１０６の呼状態を通信中に設定し（Ｓ１１１）、課金が開始される（Ｓ１１２）。そして、呼接続シーケンスが完了したため、呼制御スレッド１１１が解放されて、呼制御スレッド管理テーブル１０７に空き情報が記録される（Ｓ１１３）。
【００５６】
呼切断シーケンスでは、まず、加入者端末２０ａから呼切断が開始されると、加入者側網２１ａから交換機１０へ、加入者側プロトコルによる呼切断完了（「ＲＥＬ  ＣＯＭＰ」メッセージ等）が送信される（Ｓ２０１）。
【００５７】
次に、交換機１０の加入者側プロトコル制御部１０２ａでは、プロトコル制御スレッド１１２が、呼切断完了を受信すると、受信した呼切断完了の信号パラメータから加入者情報・加入者回線種別を識別し、呼制御スレッド管理テーブル１０７を参照して呼制御スレッド１１１の空き状態を確認する（Ｓ２０２）。Ｓ２０２において、プロトコル制御スレッド１１２は、呼制御スレッド管理テーブル１０７により呼制御スレッド１１１に空きがある場合、呼制御スレッド１１１を捕捉する（Ｓ２０３）。プロトコル制御スレッド１１２は、捕捉した呼制御スレッド１１１へ、共通プロトコルによる呼切断完了を送信する（Ｓ２０４）。
【００５８】
次に、呼制御部１０１の呼制御スレッド１１１は、呼切断完了を受信すると、呼切断完了の信号パラメータにより切断する呼や通信中の網及び端末の特定等を行い、共通プロトコルによる呼切断完了をＳＩＰプロトコル制御部１０２ｂのプロトコル制御スレッド１１２へ送信する（Ｓ２０５）。ＳＩＰプロトコル制御部１０２ｂのプロトコル制御スレッド１１２は、呼切断完了を受信すると、ＳＩＰプロトコルによる呼切断完了（「ＢＹＥ」メッセージ等）をＳＩＰ交換網２１ｂへ送信する（Ｓ２０６）。
【００５９】
これにより、呼切断シーケンスが完了して呼が切断され、加入者端末２０ａとＳＩＰ端末２０ｂとの間のデータ通信が終了する。このとき、呼制御部１０１では、呼制御スレッド１１１が、呼制御テーブル１０６の呼状態を空状態に設定し（Ｓ２０７）、課金が終了する（Ｓ２０８）。そして、呼切断シーケンスが完了したため、呼制御スレッド１１１が解放されて、呼制御スレッド管理テーブル１０７に空き情報が記録される（Ｓ２０９）。
【００６０】
次に、本発明の主要な特徴であるシステム内の再送動作について説明する。図５は、加入者側網の加入者から呼切断が開始され、交換機１０内で再送が行われる場合の動作を示している。再送部１０３および再送情報記録部１０４は、加入者側も交換網側も共通であり、発側であるか着側であるかを意識する必要がないため、加入者側プロトコル制御部１０２ａとＳＩＰプロトコル制御部１０２ｂの再送動作は同様となる。このため、ここでは加入者側と交換網側とを共通的に図示し、加入者端末２０ａもしくはＳＩＰ端末２０ｂを端末２０、加入者側網２１ａもしくはＳＩＰ交換網２１ｂを網２１、加入者側プロトコル制御部１０２ａもしくはＳＩＰプロトコル制御部１０２ｂをプロトコル制御部１０２として説明する。
【００６１】
図５に示すように、まず、端末２０から呼切断が開始されると、網２１から交換機１０へ、呼切断信号（図４の呼切断完了に相当）が送信される（Ｓ３０１）。
【００６２】
次に、交換機１０のプロトコル制御部１０２では、プロトコル制御スレッド１１２が、呼切断信号を受信すると、受信した呼切断信号の信号パラメータから加入者情報・加入者回線種別を識別し、呼制御スレッド管理テーブル１０７を参照して呼制御スレッド１１１の空き状態を確認する（Ｓ３０２）。Ｓ３０２において、プロトコル制御スレッド１１２は、呼制御スレッド管理テーブル１０７を参照し、全ての呼制御スレッド１１１が使用中で全てビジーの場合、呼切断信号の再送に必要な再送情報を再送情報記録部１０４に格納する（Ｓ３０３）。なお、プロトコル制御スレッド１１２は、呼制御スレッド１１１が捕捉できた場合でも、呼制御スレッド１１１への送信が失敗した場合には、再送情報を再送情報記録部１０４に記録する。
【００６３】
再送部１０３の再送スレッド１１３は、再送処理を実行していない場合、ＷＡＩＴ状態であるため、プロトコル制御スレッド１１２は、再送部１０３の再送スレッド１１３へ再送処理開始を通知し（Ｓ３０４）、再送スレッド１１３をＲＵＮ状態に遷移させる。
【００６４】
なお、再送スレッド１１３が、ＷＡＩＴ状態とＲＵＮ状態とを定期的に繰り返す等することで、プロトコル制御スレッド１１２から再送スレッド１１３へ再送処理開始を通知せずに、再送情報記録部１０４に再送情報が格納された場合に、再送スレッド１１３が再送処理を開始してもよい。
【００６５】
次に、再送処理開始通知によりＲＵＮ状態となった再送スレッド１１３は、再送情報記録部１０４に再送情報の有無をチェックする（Ｓ３０５）。Ｓ３０５において、再送スレッド１１３は、再送情報記録部１０４に再送情報が格納されている場合、再送を試みるため呼制御スレッド捕捉要求をプロトコル制御部１０２のプロトコル制御スレッド１１２に通知する（Ｓ３０６）。
【００６６】
プロトコル制御部１０２のプロトコル制御スレッド１１２は、呼制御スレッド捕捉要求を受信したため、再度、呼制御スレッド管理テーブル１０７を参照して呼制御スレッド１１１の空き状況を確認する（Ｓ３０７）。Ｓ３０７において、プロトコル制御スレッド１１２は、呼制御スレッド管理テーブル１０７を参照し、空きの呼制御スレッド１１１がある場合、呼制御スレッド１１１を捕捉する（Ｓ３０８）。
【００６７】
そして、プロトコル制御スレッド１１２は、捕捉した呼制御スレッド１１１に対しスレッド間通信により呼切断信号を送信する（Ｓ３０９）。これにより、図４と同様に、呼制御スレッド１１１では、呼切断、課金終了等が正常に実行される。
【００６８】
次に、プロトコル制御スレッド１１２は、呼切断信号の送信に成功したため、再送情報記録部１０４から再送情報を削除する（Ｓ３１０）。そして、プロトコル制御スレッド１１２は、スレッドの捕捉が成功したことを通知する（Ｓ３１１）。なお、この捕捉成功通知は、呼制御スレッドの捕捉が成功したことを意味するとともに、呼制御信号の再送が成功したことを意味する。再送スレッド１１３は、プロトコル制御スレッド１１２からスレッド捕捉成功通知を受けたため、再送処理のループ処理を終了させ、ＷＡＩＴ状態に遷移する。
【００６９】
図６は、図５と同様に加入者側網の加入者から呼切断が開始され、交換機１０内での再送が失敗する場合の動作を示している。
【００７０】
図６に示すように、図５と同様にして、端末２０及び網２１から呼切断信号が送信されると（Ｓ３０１）、プロトコル制御部１０２のプロトコル制御スレッド１１２が、呼制御スレッド管理テーブル１０７を確認し、再送情報記録部１０４に再送情報を格納し（Ｓ３０３）、再送部１０３の再送スレッド１１３へ再送処理開始を通知する（Ｓ３０４）。
【００７１】
そうすると、再送スレッド１１３は、ＲＵＮ状態となって、再送情報記録部１０４に再送情報の有無をチェックし、プロトコル制御部１０２のプロトコル制御スレッド１１２へ、呼制御スレッド捕捉要求を送信する（Ｓ３０６）。
【００７２】
次に、プロトコル制御部１０２のプロトコル制御スレッド１１２は、呼制御スレッド管理テーブル１０７を参照して、呼制御スレッド１１１の空き状況を確認し（Ｓ３２０）、空きの呼制御スレッド１１１が無い場合、呼制御スレッド１１１の捕捉に失敗した結果を再送スレッド１１３へ通知する（Ｓ３２１）。
【００７３】
なお、プロトコル制御スレッド１１２は、呼制御スレッド管理テーブル１０７に空きがあり、呼制御スレッド１１１の捕捉に成功した場合でも、スレッド間通信用バッファの確保失敗やスレッド間通信の失敗などの理由により、正常に通信が完了できなかったと判断した場合にも、失敗した結果を再送スレッドに通知する（Ｓ３２１）。
【００７４】
再送スレッド１１３は、プロトコル制御部１０２のプロトコル制御スレッド１１２から失敗通知を受けると、再送制御のループ処理を繰り返すかどうか判定する（Ｓ３２２）。すなわち、再送スレッド１１３は、再送情報記録部１０４に再送情報の有無と再送リトライ回数を判定する。再送スレッド１１３は、再送情報記録部１０４に再送情報が登録されており、かつ、再送リトライ回数が一定値より小さい場合、再送リトライ回数をインクリメントしてＳ３０５以降の再送処理を繰り返す。
【００７５】
再送スレッド１１３は、再送情報記録部１０４に再送情報が無い場合、または、再送リトライ回数が一定値以上になった場合、ループ処理を終了してＷＡＩＴ状態に遷移する。再送情報記録部１０４に再送情報が残っている場合には、再送情報を削除する。
【００７６】
なお、再送リトライ上限値を超えて再送情報を削除した場合、以後再送契機を失うことになるが、別の状態一致化処理にてリソース解放を行う。状態一致化処理は、隣接ノード間や、交換機内で関連するリソースを保持する機能モジュール間で、浮いているリソースを解消する機構である。
【００７７】
再送情報記録部１０４はプロトコル制御部のプロトコル制御スレッド１１２と再送部１０３の再送スレッド１１３の双方から参照するため、各方面からのアクセス時は、排他処理を行うこともできる。状態一致化処理と、本発明の再送制御で競合する可能性があることから、再送スレッド１１３がＲＵＮ状態においては、状態一致化の周期が回ってきた場合でも、状態一致化処理を開始しないことが好ましい。
【００７８】
ここで、本発明の効果の理解を助けるため、図７及び図８で示した関連する交換機の課題について改めて説明する。すなわち、図７のような、呼制御部とプロトコル制御部から構成された、関連する交換機９００では次のような課題が生じる。
【００７９】
第１の課題は、災害時などにより想定を上回るトラヒック増加が発生した場合、プロトコル制御部での信号破棄により、本来切断される呼が切断されず過課金となる。
【００８０】
第２の課題は、バーストトラヒック受信時に限らず、呼制御部とプロトコル制御部のスレッド保留時間の差異から、通常運用時においてもプロトコル制御部で切断信号が破棄される可能性があり、その場合に過課金となる。
【００８１】
第３の課題は、上記の第１の課題と第２の課題の例により呼切断できなければ、交換機内部でリソースを確保したままとなり、新規呼または入り呼用のリソースが確保できず、本来受け付けることのできるはずである呼処理サービスが適切に継続できなくなる。
【００８２】
また、図８のような、呼制御部、プロトコル制御部及び救済スレッドから構成された、関連する交換機９０１では次のような課題が生じる。
【００８３】
第４の課題は、救済スレッドはシングルスレッドにより構成されるため、複数の呼を扱うコールウェイティングや、コールホールドのサービスを実施することができない。
【００８４】
第５の課題は、救済スレッドはシングルスレッドにより構成されるため、救済される呼は１つの呼に限られ、同時に複数の呼を扱うことができない。
【００８５】
第６の課題は、第５の課題にあるよう、救済スレッドでは１度に１つの呼しか扱えないためにその他の呼は要求キューへ保留されたままとなり、負荷状態によりキューサイズ以上の要求が溜まるバッファビジーの状況となるとプロセス障害が発生し、システムが再開する間、ユーザへのサービス提供ができなくなる。
【００８６】
これに対し、本実施形態では、プロトコル制御部にて呼制御スレッドとのスレッド間データ通信ができなかった場合に、通信データを破棄することなく、その情報を再送情報として保持し、再送スレッドにて定期的に再送を試みることで、従来の呼制御方式を利用してスレッド間通信を救済し、本来制御されるべき呼を制御することを可能とした。これにより、上記課題を解決することができ、特に以下のような効果を奏する。
【００８７】
第１の効果は、交換機内における輻輳などにより呼制御スレッドが全てビジーの場合でも、再送制御を行うことで、スレッド間通信でのデータ消失が発生せず、正常に呼制御を実施できるため、過課金を防止することができる。例えば、災害時などにより想定を上回るトラヒックが発生した場合でも、正常に呼を切断することができる。また、災害時でなくとも、隣接する他ノードの再開等により一時的なバースト信号が発生する可能性があり、また、自ノード再開等により、非救済対象呼の一斉切断等でも同様の状況に陥る可能性があるため、このような状況においても、正常に呼を切断することができる。
【００８８】
第２の効果は、バーストトラヒック受信時に限らず、呼制御部とプロトコル制御部のスレッド保留時間の差異から、通常運用時においてもプロトコル制御部で切断信号が破棄される可能性があり、その場合にも本実施形態の再送制御を行うことで、正常に呼制御を実施し、過課金となることを防止できることが可能である。
【００８９】
第３の効果は、再送制御により呼切断を確実に行うことができるため、交換機内部のリソース解放漏れによるリソース不足を解決し、新規呼を受け付けられることを可能にすることができる。
【００９０】
なお、本発明は上記実施の形態に限られたものではなく、趣旨を逸脱しない範囲で適宜変更することが可能である。
【００９１】
例えば、上記の例に限らず、ルータ、ＲＮＣ（Radio Network Controller）、ＳＩＰサーバ、Ｎｏ．７共通線方式を扱う交換機、及びIP通信に移行した交換機に適用することができる。また、ＴＣＰ／ＩＰをベースとするネットワーク装置に適用することができる。
【００９２】
上記のように、交換機において、プロトコル制御部と呼制御部ではスレッド保留時間が異なるため、保留時間の短いプロトコル制御部では処理が溜まる傾向にあり、一時的なトラヒック増加でなくても、長時間通話など呼状況と連動して、正常に呼制御が実施できないという課題が発生しうる状況となる。この、「プロトコル制御部と呼制御部」の関係は、交換機に限らないため、「プロトコル制御部と呼制御部」と同様な処理時間の関係を有する装置に適用することができる。
【００９３】
また、上記の例では、システム内の各ブロックの処理単位としてスレッドを用いて説明したが、その他の処理単位としてプロセスやタスクとしてもよい。
【００９４】
上記の例では、再送スレッドが、プロトコル制御スレッドに対して再送を要求し、プロトコル制御スレッドから呼制御スレッドへ再送を行ったが、これに限らず、再送スレッドが直接呼制御スレッドへ再送を行ってもよい。この場合、プロトコル制御スレッドと再送スレッドとの間で排他制御することが好ましい。
【００９５】
上記の例では、主に呼切断時の再送制御について説明したが、呼切断時に限らず、呼接続時や通信中に輻輳が発生した場合に、上記と同様の再送制御を行ってもよい。
【符号の説明】
【００９６】
１      通信装置
２      対向通信装置
１０    交換機
１１    呼制御部
１２    データ受信部
１３    再送部
２０    端末
２０ａ  加入者端末
２０ｂ  ＳＩＰ端末
２１    網
２１ａ  加入者側網
２１ｂ  ＳＩＰ交換網
１００  通信システム
１０１  呼制御部
１０２  プロトコル制御部
１０２ａ  加入者側プロトコル制御部
１０２ｂ  ＳＩＰプロトコル制御部
１０３  再送部
１０４  再送情報記録部
１０５  加入者管理部
１０６  呼制御テーブル
１０７  呼制御スレッド管理テーブル
１１１  呼制御スレッド
１１２  プロトコル制御スレッド
１１３  再送スレッド
【図１】
2013126240.tif 000003
【図２】
2013126240.tif 000004
【図３】
2013126240.tif 000005
【図４】
2013126240.tif 000006
【図５】
2013126240.tif 000007
【図６】
2013126240.tif 000008
【図７】
2013126240.tif 000009
【図８】
2013126240.tif 000010