(57)【要約】【課題】ネットワーク全体のトラフィック量の軽減を図ることを配慮しながら、接続要求の輻輳を効果的に解消することができる輻輳制御システム、方法及びプログラムを提供する。【解決手段】本発明の輻輳制御システムは、接続要求メッセージを同時期に複数受信することにより生じ得る輻輳を回復制御する輻輳制御システムにおいて、受信した接続要求メッセージの全部又は一部の発信元に対して、当該接続要求メッセージに対する暫定的な応答信号を送信して、接続要求メッセージの再送を抑制させる接続処理手段を備えることを特徴とする。【選択図】      図１
2008311944.tif 000002
【特許請求の範囲】
【請求項１】
接続要求メッセージを同時期に複数受信することにより生じ得る輻輳を回復制御する輻輳制御システムにおいて、
受信した上記接続要求メッセージの全部又は一部の発信元に対して、当該接続要求メッセージに対する暫定的な応答信号を送信して、上記接続要求メッセージの再送を抑制させる接続処理手段を備えることを特徴とする輻輳制御システム。
【請求項２】
上記接続処理手段が、上記暫定的な応答信号の送信後、接続処理を一時的に中断することを特徴とする請求項１に記載の輻輳制御システム。
【請求項３】
上記接続処理手段から、所定時間のタイマ設定の要求を受けると、所定時間を計時するタイマイベントの登録を行ない、所定時間に達したときに、上記接続処理手段に対してその旨を通知する時間管理手段を備えることを特徴とする請求項２に記載の輻輳制御システム。
【請求項４】
上記接続処理手段が、上記暫定的な応答信号の送信後、受信した上記接続要求メッセージを廃棄することを特徴とする請求項１〜３のいずれかに記載の輻輳制御システム。
【請求項５】
接続要求メッセージを同時期に複数受信することにより生じ得る輻輳を回復制御する輻輳制御方法において、
接続処理手段が、受信した上記接続要求メッセージの全部又は一部の発信元に対して、当該接続要求メッセージに対する暫定的な応答信号を送信して、上記接続要求メッセージの再送を抑制させる接続処理工程を有することを特徴とする輻輳制御方法。
【請求項６】
接続要求メッセージを同時期に複数受信することにより生じ得る輻輳を回復制御する輻輳制御プログラムにおいて、
コンピュータに、受信した上記接続要求メッセージの全部又は一部の発信元に対して、当該接続要求メッセージに対する暫定的な応答信号を送信して、上記接続要求メッセージの再送を抑制させる接続処理手段として機能させる輻輳制御プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、輻輳制御システム、方法及びプログラムに関し、例えば、ＳＩＰ（Session  Initiation  Protocol）を採用するＩＰ通信システムにおいて、呼制御信号の輻輳発生時に、輻輳を回復させる制御システム、方法及びプログラムに適用し得る。
【背景技術】
【０００２】
一般に、通信システムにおいて端末から接続要求などの制御信号の過度な通信装置への流入により、処理量を要求量が定常的に上回った状態を輻輳状態という。輻輳を招くトラフィックパターンとして、発信元が特定か又は不特定か、トラフィックの時間的変化として定常的か又は突発的か等に応じて分類できる。
【０００３】
従来、これら輻輳の対策としては、通信装置が、一部の接続要求に対し接続をエラー応答で拒否することや、接続要求そのものを装置内で廃棄すること、また、定常的に発生するものに対してはネットワーク装置の慢性的な処理能力不足も考えられるため、装置の増設等の処理能力の向上を図ることにより輻輳の緩和が図られてきた。
【０００４】
例えば、図２に示す従来の呼処理サーバ１０が行なう従来の輻輳制御方法を、図３〜図５を用いて説明する。図３は、呼制御サーバ１０が単一コールを制御する一般的なシーケンス図である。
【０００５】
呼処理サーバ１０は、メッセージを受信すると、その受信メッセージをキュー８０に一時的に保管し、各メッセージを処理部３０に与える。各メッセージが処理部３０に与えられると、処理部３０においては、呼処理スレッドがメッセージ毎に発生して、図３に示すフローに従った呼処理が行なわれる。
【０００６】
多量のメッセージが呼処理サーバ１０に与えられて輻輳状態になり、呼処理サーバ１０の処理負荷が閾値を超えると、呼処理サーバ１０は、図４又は図５に示すような処理を行なっている。
【０００７】
図４では、呼処理サーバ１０が、発信端末からＩＮＶＩＴＥを受信すると（ステップＳ２０１）、応答信号である１００  Ｔｒｙｉｎｇを発信端末に対して返信する（ステップＳ２０２）。その後、呼処理サーバ１０は、エラー応答信号「５０３」を発信端末に対して送信することで、呼処理サーバ１０におけるエラーが生じた旨を知らせ、発信端末からの接続要求を拒否する（ステップＳ２０３、Ｓ２０４）。
【０００８】
また、図５では、発信端末からＩＮＶＩＴＥを受信すると、応答信号を返信せず、受信したＩＮＶＩＴＥを廃棄する（ステップＳ３０１）。すなわち、図５に示すように、多量のＩＮＶＩＴＥが送られてきた場合に、受信したすべてのＩＮＶＩＴＥを廃棄するものとする。
【０００９】
特許文献１には、ＳＩＰを採用した通信システムにおいて、発呼端末における発呼制御に関する技術が記載されている。具体的には、発信端末がＩＮＶＩＴＥを送信した後、着信端末からＲｅｔｒｙ−Ａｆｔｅｒを受信した場合には、このＲｅｔｒｙ−Ａｆｔｅｒに含まれている受付可能時間経過後に、再度ＩＮＶＩＴＥを送信するという技術である。
【００１０】
【特許文献１】特開２００４−１１２１８２号公報
【発明の開示】
【発明が解決しようとする課題】
【００１１】
ところで、信号制御プロトコルにＳＩＰを用いた通信システムでは、トランスポートプロトコルにＵＤＰ（User  Datagram  Protocol）のような信頼性の低いプロトコルが使用されることがある。
【００１２】
ここで、一般に、発信端末が接続要求信号を送信後、所定時間内に応答信号を受信できなかったときには、発信端末は、接続要求信号の再送を行なう。この場合に、サーバが、上述した従来技術のように接続要求を廃棄する方法で対応しようとすると、呼処理サーバが接続要求を廃棄することにより、発信端末が接続要求を再送するため、ネットワーク全体のトラフィック量が増大し、その結果輻輳を助長するおそれがある（図５参照）。
【００１３】
また、例えばネットワーク障害等の通信不可能状態が回復すると、その直後は、バースト的なトラフィックが発生し易くなる。このような場合にも、サーバが、上述した従来技術のように接続拒否や接続要求廃棄を行なうことにより、再度接続を試みるケースが増えるので、輻輳を助長するおそれがある（図４及び図５参照）。
【００１４】
また、特許文献１は、端末に関する技術であるが、この技術を接続要求の輻輳回避手段としてサーバに適用することも考えられる。しかし、特許文献１に記載の技術は、接続性の効率化を目的とするものであって、ネットワーク全体のトラフィック量の軽減を目的とするものではなく、かつ、Ｒｅｔｒｙ−Ａｆｔｅｒに従って動作するのは端末だけであるから、そのままではサーバに適用することができないという問題がある。
【００１５】
そのため、ネットワーク全体のトラフィック量の軽減を図ることを配慮しながら、接続要求の輻輳を効果的に解消することができる輻輳制御システム、方法及びプログラム。
【課題を解決するための手段】
【００１６】
かかる課題を解決するために、第１の本発明の輻輳制御システムは、接続要求メッセージを同時期に複数受信することにより生じ得る輻輳を回復制御する輻輳制御システムにおいて、（１）受信した接続要求メッセージの全部又は一部の発信元に対して、当該接続要求メッセージに対する暫定的な応答信号を送信して、接続要求メッセージの再送を抑制させる接続処理手段を備えることを特徴とする。
【００１７】
第２の本発明の輻輳制御方法は、接続要求メッセージを同時期に複数受信することにより生じ得る輻輳を回復制御する輻輳制御方法において、（１）接続処理手段が、受信した接続要求メッセージの全部又は一部の発信元に対して、当該接続要求メッセージに対する暫定的な応答信号を送信して、接続要求メッセージの再送を抑制させる接続処理工程を有することを特徴とする。
【００１８】
第３の本発明の輻輳制御プログラムは、接続要求メッセージを同時期に複数受信することにより生じ得る輻輳を回復制御する輻輳制御プログラムにおいて、コンピュータに、受信した接続要求メッセージの全部又は一部の発信元に対して、当該接続要求メッセージに対する暫定的な応答信号を送信して、接続要求メッセージの再送を抑制させる接続処理手段として機能させるものである。
【発明の効果】
【００１９】
本発明によれば、ネットワーク全体のトラフィック量の軽減を図ることを配慮しながら、接続要求の輻輳を効果的に解消することができる。
【発明を実施するための最良の形態】
【００２０】
（Ａ）第１の実施形態
以下、本発明の輻輳制御システム、方法及びプログラムの第１の実施形態を、図面を参照しながら説明する。
【００２１】
第１の実施形態では、ＳＩＰを採用したＩＰ通信システムを構成する呼処理サーバに、本発明を適用した場合を例に挙げて説明する。
【００２２】
（Ａ−１）第１の実施形態の構成
図１は、第１の実施形態の呼処理サーバの主な内部機能を示す内部構成図である。図１に示すように、第１の実施形態の呼処理サーバ１は、受信部２、処理部３、遅延管理部４を、少なくとも有して構成される。
【００２３】
呼処理サーバ１のハードウェア構成の説明は省略するが、一般に、例えば、ＣＰＵ、ＲＯＭ、ＲＡＭ、ＥＥＰＲＯＭ、通信手段等を備えて構成されるものである。以下で説明する呼処理サーバ１の機能は、ソフトウェア処理で実現されるものである。
【００２４】
受信部２は、通信回線を通じて、呼処理に係る制御信号であるＳＩＰメッセージＭ１〜Ｍ３を受信するものである。受信部２は、キュー８を有しており、受信したメッセージを一旦保管すると、一時的に保管したメッセージを処理部３に与えるものである。
【００２５】
処理部３は、受信部２からのメッセージ毎に呼処理スレッドを発生させ、呼処理を行なうものである。これにより、個々のメッセージに応じた処理を並列的に行なうことができる。
【００２６】
また、処理部３は、メッセージを受信すると、その発信端末に対して応答信号を暫定的に返信するものである。これにより、メッセージの発信元に対して応答信号を返信することができるから、メッセージ発信元からのメッセージの再送をなくすことができる。また、多量のメッセージを一度に受信した場合でも、できる限り多くのメッセージに対して応答信号を返信することができる。その結果、従来よりもメッセージの再送を減らすことができる。従って、ネットワーク全体のトラフィック量を軽減することができ、輻輳を回避することができる。
【００２７】
さらに、処理部３は、暫定的な応答信号の送信後、遅延管理部４に対して遅延タイマ設定を要求し、呼処理を一時的に中断するものである。そして、設定した遅延タイマ時間になったことを遅延管理部４から通知されると、処理部３は呼処理を再開するものである。このように、呼処理を意図的に中断することにより、処理部３の処理負荷を軽減することができる。
【００２８】
遅延管理部４は、処理部３から遅延タイマ設定の要求を受けると、処理部３に通知する通知時間を要求毎に設定する。そして、各要求の通知時間になると、遅延管理部４は、当該要求に対するタイマ時間になったことを、処理部３に対して通知する。
【００２９】
ここで、タイマ時間（遅延時間）は、呼処理プロトコルで決められているタイムアウト内（例えば、数十秒内）で設定するものとする。これにより呼処理プロトコルの範囲内での設定ができる。
【００３０】
なお、遅延管理部４は、各タイム設定要求毎に、タイム時間を管理する。また、タイム時間は、呼処理プロトコルで決められているタイムアウトの範囲内であれば、輻輳状態に応じて設定変更可能としてもよい。例えば、単位時間内でのＩＮＶＩＴＥの受信量が多く閾値を超える場合には、タイム時間を大きく設定するようにしてもよい。
【００３１】
（Ａ−２）第１の実施形態の動作
次に、第１の実施形態の呼処理サーバ１における輻輳制御処理の動作を図面を参照しながら説明する。
【００３２】
まず、図１を参照しながら、第１の実施形態の呼処理サーバ１における処理について説明する。
【００３３】
メッセージＭ１〜Ｍ３が呼処理サーバ１に与えられると（ステップＳ７０１）、受信されたメッセージは受信部２のキュー８に一時的に保管される（ステップＳ７０２）。その後、一時的に保管されたメッセージは、処理部３に与えられ（ステップＳ７０３）、処理部３において、各メッセージ毎に呼処理スレッドが発生されて、それぞれ呼処理が行なわれる（ステップＳ７０４）。
【００３４】
ここで、図９は、処理部３における処理を示すフローチャートである。図９において、受信部２からのメッセージを処理部３が受け取ると（ステップＳ８０１）、処理部３は受信信号を解析する（ステップＳ８０２）。
【００３５】
ここでは、処理部３が、発信元や着信先に関する情報や、メッセージ種類や、受信したメッセージに対する応答等を分析する。また、このとき、処理部３は、暫定的な応答信号（例えば、１００  Ｔｒｙｉｎｇ）の返信処理を行なう（ステップＳ８０３）。
【００３６】
そして、受信信号が発信元からの要求メッセージ（例えば、ＩＮＶＩＴＥ等）である場合、処理部３は、遅延管理部４に対してタイマ設定の要求を行なう（ステップＳ８０４、図１のＳ７０５）。このとき、処理部３では、遅延管理部４からのタイマ通知待ちをしており（ステップＳ８０５）、このタイマ通知の待ちの期間、処理部３は当該呼処理を中断する。
【００３７】
一方、遅延管理部４では、図１０及び図１１に示す処理を行なう。図１０において、遅延管理部４は、処理部３からタイマ設定の要求受付をしており（ステップＳ８１１）、処理部３からタイマ設定要求を待機する。
【００３８】
遅延管理部４において、処理部３からタイマ設定要求を受信すると（ステップＳ８１２）、当該要求に対する通知時間を設定し（ステップＳ８１３）、タイマイベントの登録を行ない（ステップＳ８１４）、次のタイマ設定の要求を待機する（ステップＳ８１５）。
【００３９】
また、遅延管理部４では、図１１に示すように、登録されているタイマイベントを定期的に監視し（ステップＳ８１６）、現在時刻情報が通知時間情報になっているか否かを判断し、通知イベントの有無を判断する（ステップＳ８１７）。
【００４０】
そして、通知イベントがない場合には、ステップＳ８１６に戻り処理を繰り返し、通知イベントがある場合には、処理部３に対して当該要求に対するタイマ通知を行なう（ステップＳ８１８、図１のＳ７０７）。
【００４１】
図９に示すように、遅延管理部４からタイマ通知が処理部３に与えられると（ステップＳ８０６）、処理部３は、当該要求メッセージに対する応答信号を送信する（ステップＳ８０７）。また、その後においては、呼処理に必要な他の信号処理を行ない、処理を継続する（ステップＳ８０８、Ｓ８０９）。
【００４２】
続いて、呼処理サーバ１が単一コールの呼処理を行なうときの処理フローを、図６を参照しながら説明する。図６は、呼処理サーバ１が行なう単一コールの処理フローを示すフローチャートである。
【００４３】
まず、発信端末が送信したＩＮＶＩＴＥが呼処理サーバ１に与えられると（ステップＳ１０１）、呼処理サーバ１の処理部３は、発信元に対して応答信号１００  Ｔｒｙｉｎｇを返信する（ステップＳ１０２）。
【００４４】
呼処理サーバ１が応答信号１００  Ｔｒｙｉｎｇを送信すると、呼処理サーバ１は、所定時間だけ当該呼処理を意図的に中断し、本来、その後に送信する「４０７（Ｐｒｏｘｙ  Ａｕｔｈｅｎｔｉｃａｔｉｏｎ  Ｒｅｑｕｉｒｅｄ）」の送信を遅らせる（ステップＳ４０１）。
【００４５】
そして、所定時間が経過すると、呼処理サーバ１は、発信元に対して「４０７（Ｐｒｏｘｙ  Ａｕｔｈｅｎｔｉｃａｔｉｏｎ  Ｒｅｑｕｉｒｅｄ）」を送信する（ステップＳ１０３）。このように、処理部３の処理を一旦中断することにより、処理部３全体の負荷を軽減することができる。
【００４６】
その後の処理は通常の呼処理と同様に、発信元からＡＣＫが与えられ（ステップＳ１０４）、発信端末からのＩＮＶＩＴＥが呼処理サーバ１に与えられると（ステップＳ１０５）、呼処理サーバ１の処理部３は、発信元に対して応答信号１００  Ｔｒｙｉｎｇを返信すると共に（ステップＳ１０６）、上記同様に所定時間だけ処理を中断する（ステップＳ４０２）。
【００４７】
そして、所定時間が経過すると、呼処理サーバ１は、着信先に対してＩＮＶＩＴＥを送信する（ステップＳ１０７）。
【００４８】
その後の処理は通常の呼処理と同様である。つまり、着信先から１００  Ｔｒｙｉｎｇが与えられ（ステップＳ１０８）、その後、着信先から１８０  Ｒｉｎｇｉｎｇを受信すると（ステップＳ１０９）、その受信した１８０  Ｒｉｎｇｉｎｇを発信元に送信する（ステップＳ１１０）。また、着信先から２００  ＯＫが呼処理サーバ１に与えられると（ステップＳ１１１）、呼処理サーバ１は受信した２００  ＯＫを発信元に送信する（ステップＳ１１２）。そして、発信元からのＡＣＫを着信先に送信することで（ステップＳ１１３、Ｓ１１４）、発信元と着信先との間の通信を実現する。
【００４９】
なお、発信元と着信先との間の通信が終わり、ＢＹＥが呼処理サーバ１に与えられると、相手端末にＢＹＥを送信し、相手端末からの２００  ＯＫを返信することで通信が終了する（ステップＳ１１５〜Ｓ１１８）。
【００５０】
以上のように、単一コールの呼処理を行なう場合でも、受信したメッセージに対して暫定的な応答信号を返信した後、所定時間だけ意図的に処理を中断してから、その後の処理を続行することにより、呼処理サーバ１の処理部３の負荷を軽減することができる。
【００５１】
次に、例えば、ある特定の発信元から不特定多数の宛先の接続要求があった場合（いわゆるワン切り）等のような不正アクセスがあった場合の、呼処理サーバ１における処理を図７及び図８を参照しながら説明する。
【００５２】
なお、図７の処理は、図４に示す処理に対応するものであり、図８の処理は、図５に示す処理に対応するものである。また、例えば単位時間当たりのＩＮＶＩＴＥの受信量等に応じて、図７又は図８の処理を行なうことを柔軟に決定できる。
【００５３】
図７において、発信元からのＩＮＶＩＴＥが呼処理サーバ１に与えられると（ステップＳ２０１）、呼処理サーバ１の処理部３は、１００  Ｔｒｙｉｎｇを発信元に返信する（ステップＳ２０２）。
【００５４】
このとき、呼処理サーバ１では、１００  Ｔｒｙｉｎｇを返信すると、所定時間だけ意図的に処理を中断し、所定時間が経過すると（ステップＳ５０１）、エラー応答信号「５０３」を発信元に対して送信し、呼処理サーバ１０におけるエラーが生じた旨を知らせ、発信端末からの接続要求を拒否する（ステップＳ２０３、Ｓ２０４）。
【００５５】
また、図８において、発信元からのＩＮＶＩＴＥが呼処理サーバ１に与えられると（ステップＳ６０１）、呼処理サーバ１の処理部３は、１００  Ｔｒｙｉｎｇを発信元に返信する（ステップＳ６０２）。このとき、呼処理サーバ１では、暫定的な応答信号である１００  Ｔｒｙｉｎｇを返信してから、受信したＩＮＶＩＴＥを廃棄する。
【００５６】
このように、発信元からのＩＮＶＩＴＥを受信した場合に、呼処理サーバ１が暫定的に１００  Ｔｒｙｉｎｇを返信することにより、発信元が切断しない限り（ステップＳ６０３）、発信元は、同一回線を用いての別の発信（次のＩＮＶＩＴＥの発信）を行なうことができないこととなる。そのため、この特定の発信元から単位時間当たりのＩＮＶＩＴＥの発信数を効果的に減らすことができる。
【００５７】
（Ａ−１）第１の実施形態の効果
以上のように、第１の実施形態によれば、接続要求のＩＮＶＩＴＥを受信すると、その発信元に対して暫定的な応答信号を送信することで、発信元からのＩＮＶＩＴＥの再送を抑止させることができる。
【００５８】
また、第１の実施形態によれば、暫定的な応答信号の送信後、所定の接続処理プロトコルで決められたタイムアウト期間内で、タイム設定をし、その間一時的に処理を中断することで、処理部全体の処理負荷を軽減することができる。
【００５９】
さらに、第１の実施形態によれば、多量なＩＮＶＩＴＥが同時期に与えられた場合には、暫定的な応答信号を送信してから、受信したＩＮＶＩＴＥを廃棄することで、発信元からの連続的な不要なＩＮＶＩＴＥの送信を抑止させることができる。
【００６０】
以上より、ネットワーク上を流れる信号量を減らすことができるので、ネットワーク全体の輻輳を解消させることができる。
【００６１】
（Ｂ）他の実施形態
第１の実施形態では、呼処理サーバ１が備える処理部及び遅延管理部は、それぞれ物理的に同じサーバが備えるものとして説明したが、ネットワークを通じて接続可能であり、第１の実施形態で説明した機能を実現できるのであれば、それぞれ分散配置されるものとしても適用することができる。
【００６２】
第１の実施形態では、ＳＩＰを採用したＩＰ通信ネットワークを想定して説明したが、セッションを確立させるプロトコルはＳＩＰに限定されず広く適用できる。
【００６３】
上述したように、第１の実施形態の呼処理サーバ１の処理機能は、ソフトウェア処理で実現されることを想定している。すなわち、第１の実施形態で説明した処理部３の各機能は、例えば、処理プログラムとして、ＲＯＭに格納されており、ＣＰＵが、各処理プログラムを読み出して、処理に必要なデータを用いて処理プロラムを実行することで実現されるものである。なお、呼処理サーバの処理機能は、可能であれば、ハードウェアで実現されるものとしてもよい。
【図面の簡単な説明】
【００６４】
【図１】第１の実施形態の呼処理サーバの内部構成及び全体処理の流れを示す図である。
【図２】従来の呼処理サーバの内部構成及び全体処理の流れを示す図である。
【図３】従来の呼処理サーバによる単一コールの呼処理を示すフローチャートである。
【図４】従来の呼処理サーバによる不正アクセスに対する対応処理を示すフローチャートである（その１）。
【図５】従来の呼処理サーバによる不正アクセスに対する対応処理を示すフローチャートである（その２）。
【図６】第１の実施形態の呼処理サーバによる単一コールの呼処理を示すフローチャートである。
【図７】第１の実施形態の呼処理サーバによる不正アクセスに対する対応処理を示すフローチャートである（その１）。
【図８】第１の実施形態の呼処理サーバによる不正アクセスに対する対応処理を示すフローチャートである（その２）。
【図９】第１の実施形態の処理部における処理を示すフローチャートである。
【図１０】第１の実施形態の遅延管理部におけるタイマイベント登録処理を示すフローチャートである。
【図１１】第１の実施形態の遅延管理部におけるタイマイベント通知処理を示すフローチャートである。
【符号の説明】
【００６５】
１…呼処理サーバ、２…受信部、３…処理部、４…遅延管理部、８…キュー。
【図１】
2008311944.tif 000003
【図２】
2008311944.tif 000004
【図３】
2008311944.tif 000005
【図４】
2008311944.tif 000006
【図５】
2008311944.tif 000007
【図６】
2008311944.tif 000008
【図７】
2008311944.tif 000009
【図８】
2008311944.tif 000010
【図９】
2008311944.tif 000011
【図１０】
2008311944.tif 000012
【図１１】
2008311944.tif 000013