(57)【要約】【課題】ＳＩＰサーバにおける輻輳の状況を正確に把握する。【解決手段】監視対象のＳＩＰサーバの輻輳状態を検出する装置であって、前記ＳＩＰサーバに入力するInitial INVITE電文の単位時間当たりの件数を計測する手段と、前記ＳＩＰサーバのInitial INVITE電文に対する内部処理時間を計測する手段と、前記ＳＩＰサーバが出力するInitial INVITE電文の、前記内部処理時間だけタイミングを後ろにずらした単位時間当たりの件数を計測する手段と、計測した入力電文件数と出力電文件数とを比較することにより輻輳状態であるか否かを判定する手段とを備える。【選択図】図６
2011055225.tif 000002
【特許請求の範囲】
【請求項１】
監視対象のＳＩＰサーバの輻輳状態を検出する装置であって、
前記ＳＩＰサーバに入力するInitial INVITE電文の単位時間当たりの件数を計測する手段と、
前記ＳＩＰサーバのInitial INVITE電文に対する内部処理時間を計測する手段と、
前記ＳＩＰサーバが出力するInitial INVITE電文の、前記内部処理時間だけタイミングを後ろにずらした単位時間当たりの件数を計測する手段と、
計測した入力電文件数と出力電文件数とを比較することにより輻輳状態であるか否かを判定する手段と
を備えたことを特徴とする輻輳検出装置。
【請求項２】
請求項１に記載の輻輳検出装置において、
前記ＳＩＰサーバに入力するInitial INVITE電文の入力時刻と、前記ＳＩＰサーバが出力する100Tryingの応答の出力時刻との差に基づいて前記内部処理時間を計測する
ことを特徴とする輻輳検出装置。
【請求項３】
請求項１または２のいずれか一項に記載の輻輳検出装置において、
前記ＳＩＰサーバとエッジルータの間に挿入したＳＰＡＮタップから、前記ＳＩＰサーバに入出力する電文を取得する
ことを特徴とする輻輳検出装置。
【請求項４】
監視対象のＳＩＰサーバの輻輳状態を検出する方法であって、
前記ＳＩＰサーバに入力するInitial INVITE電文の単位時間当たりの件数を計測する工程と、
前記ＳＩＰサーバのInitial INVITE電文に対する内部処理時間を計測する工程と、
前記ＳＩＰサーバが出力するInitial INVITE電文の、前記内部処理時間だけタイミングを後ろにずらした単位時間当たりの件数を計測する工程と、
計測した入力電文件数と出力電文件数とを比較することにより輻輳状態であるか否かを判定する工程と
を備えたことを特徴とする輻輳検出方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＳＩＰ（Session Initiation Protocol）サーバの輻輳を検出する技術に関する。
【背景技術】
【０００２】
従来のＰＳＴＮ（Public Switched Telephone Networks）網での電話の輻輳は、伝送路に対して発生していた。これは、相手方が話中でも伝送路を先に確保するため、呼の発生が増えると伝送路が不足するためである。
【０００３】
しかしながら、ＩＰ（Internet Protocol）通信をベースとするＮＧＮ（Next Generation Network）網では、伝送路に対して輻輳は発生しない。すなわち、電話がつながるまでは音声のための帯域は確保せず、ＳＩＰの制御パケットだけが伝送路上を流れ、それは音声データのパケットと比較すると小さいためである。その代わりに、ＳＩＰの制御パケットの処理を行うＳＩＰサーバに対しては、伝送路に余裕があるため、大量のＳＩＰ制御パケットが一気に到着することになり、処理が間に合わず、ＳＩＰサーバで輻輳が発生することとなる。
【０００４】
図１は従来におけるシステムの構成例を示す図である。
【０００５】
図１において、ＮＧＮネットワーク１には複数のＳＩＰサーバ２Ａ〜２Ｄと、複数のエッジルータ３Ａ〜３Ｃとが設けられており、エッジルータ３Ａ〜３Ｃに複数の電話機４Ａ〜４Ｆが接続されている。
【０００６】
今、電話機４Ａ→エッジルータ３Ａ→ＳＩＰサーバ２Ａ、電話機４Ｂ→エッジルータ３Ａ→ＳＩＰサーバ２Ａへと呼が発生し、その宛先がＳＩＰサーバ２Ｂの配下であるものとする。同様に、電話機４Ｄ→エッジルータ３Ｂ→ＳＩＰサーバ２Ｃへと呼が発生し、その宛先がＳＩＰサーバ２Ｂの配下であるものとする。同様に、電話機４Ｅ→エッジルータ３Ｃ→ＳＩＰサーバ２Ｄ、電話機４Ｆ→エッジルータ３Ｃ→ＳＩＰサーバ２Ｄへと呼が発生し、その宛先がＳＩＰサーバ２Ｂの配下であるものとする。この場合、ＳＩＰサーバ２Ｂは負荷が高くなり、エッジルータ３Ｂを介して電話機４Ｃ、４Ｄへの接続処理に遅延が発生する。電話の輻輳は、特定の地域や特定の電話番号に発呼が集中するため、このような状態が発生しやすい傾向を持っている。
【０００７】
また、ＳＩＰサーバは従来の交換機とは異なり、ハードウェアロジックではなく、ソフトウェアロジックで機能実現している。そのため、通常想定される特定地域への発呼の増大だけではなく、設定ミスや、プログラムミス等の様々な原因による能力ダウンが発生することが想定される。
【０００８】
ＮＧＮで採用されるＳＩＰサーバの処理能力は、ワイヤースピードによる限界負荷の数十分の１である。これは、ほとんどのデータは音声データが占めることとなるため、ＳＩＰサーバが処理すべき制御パケットの量は相対的に小さいからである。
【０００９】
そのため、複数のＳＩＰサーバから特定の１台のＳＩＰサーバに要求が集中すると、ワイヤースピードに余裕があるので、処理可能な数十倍の負荷が掛かることになる。その場合、そのＳＩＰサーバは要求を読み取ることができなくなり、負荷を正しく把握することができなくなる。
【００１０】
以下に、負荷発生時のデータ量の算出例について説明する。例として、１００万ＢＨＣＡ（Busy Hour/Interval Call Attempts：電話網が最も混雑する時間帯（busy hour）における回線呼び出しの回数の総量）の性能をもつＳＩＰサーバの性能限界発生時のトラフィック量は次のようになる。
・ＳＩＰサーバの能力：１００万ＢＨＣＡ  →  １０００，０００コール／Ｈｒ  →  ２７８コール／秒
・１コール当たりのＳＩＰ電文数：２３件
・１電文当たりの長さ：５００バイト
・最大能力時のデータ伝送量：２７８×２３×５００  →  ３Ｍバイト／秒
【００１１】
これに対して１Ｇｂｐｓのネットワーク上でＳＩＰパケットが転送される最大数は次のようになる。
・ワイヤースピード：１Ｇｂｐｓ  →  １２５Ｍバイト／秒
・１コール当たりのＳＩＰ電文数：２３件
・１電文当たりの長さ：５００バイト
・ワイヤースピードでのＳＩＰパケット総量：１２５Ｍ  ÷（２３＊５００）／秒  →  １０８６９コール／秒
【００１２】
よって、要求が集中した場合、ＳＩＰサーバの性能の４０倍（１０８６９／２７８）の負荷が掛かる場合がある。
【００１３】
ＳＩＰサーバには、一般に、所定数を超えるセッションをリジェクトする機能が設けられているが、セッション数オーバとなってリジェクトされるInitial INVITEであっても、ＳＩＰサーバでは、通常のInitial INVITEの開設処理と同様に電文解析処理を行うため、ＳＩＰサーバへの負荷となる。これは、通話の継続を行うためのre INVITEがInitial INVITEと同じ形式で到来するため、区別なく電文解析処理を行う必要があるからである。
【００１４】
よって、最終的には、セッション数オーバでリジェクトされるInitial INVITEのＳＩＰ電文が多数となり、接続中のセッションのＳＩＰ電文が処理されなくなり、セッションが全て成立しなくなる輻輳状態となる。
【００１５】
そのため、早急に輻輳中であることを検出して他のＳＩＰサーバへ通知し、輻輳中のＳＩＰサーバへの接続要求を抑える必要がある。
【００１６】
従来におけるＳＩＰサーバの輻輳の検出の手法としては、ＳＩＰサーバ内に監視機能を持たせ、呼数をカウントして所定数を超えた場合に輻輳であると判定するのが一般的である。
【００１７】
また、特許文献１〜３にはＳＩＰサーバにおける輻輳の防止に関する他の技術が開示されている。
【先行技術文献】
【特許文献】
【００１８】
【特許文献１】特開２００８−２４４９７０号公報
【特許文献２】特開２００７−２６７１５１号公報
【特許文献３】特開２００８−９２１１６号公報
【発明の概要】
【発明が解決しようとする課題】
【００１９】
上述したように、従来からＳＩＰサーバの輻輳を検出するために種々の方策がとられているが、次のような問題が指摘されていた。
（１）ＳＩＰサーバ自体の過負荷による輻輳状態を正常に監視できない。すなわち、ＳＩＰサーバの過負荷による輻輳をＳＩＰサーバ自体に監視機能を持たせ、その報告を受けて把握しようとすると、ＳＩＰサーバ自体が過負荷状態のため、その輻輳監視が正常に実施できず、機能することができない。
（２）呼数をカウントするだけでは正確な負荷状態を把握することができない。すなわち、ＳＩＰサーバは従来の交換機とは異なり、ハードウェアロジックでなくソフトウェアロジックで機能実現しているため、通常想定される特定地域への発呼の増大だけではなく、設定ミスや、プログラムミス等の様々な原因による能力ダウンが問題となることが想定される。従って、単位時間当たりのInitial INVITE数をカウントして固定値の最大処理可能数と比較するだけではＳＩＰサーバの性能劣化を検知することが困難である。ＳＩＰサーバの処理能力の変化に対応できる手法による、呼処理の遅れを検知する仕組みが必要である。
【００２０】
上記の従来の問題点に鑑み、ＳＩＰサーバにおける輻輳の状況を正確に把握することのできる輻輳検出装置を提供することを目的とする。
【課題を解決するための手段】
【００２１】
この輻輳検出装置の一実施態様では、監視対象のＳＩＰサーバの輻輳状態を検出する装置であって、前記ＳＩＰサーバに入力するInitial INVITE電文の単位時間当たりの件数を計測する手段と、前記ＳＩＰサーバのInitial INVITE電文に対する内部処理時間を計測する手段と、前記ＳＩＰサーバが出力するInitial INVITE電文の、前記内部処理時間だけタイミングを後ろにずらした単位時間当たりの件数を計測する手段と、計測した入力電文件数と出力電文件数とを比較することにより輻輳状態であるか否かを判定する手段とを備える。
【発明の効果】
【００２２】
開示の輻輳検出装置にあっては、ＳＩＰサーバに入力するInitial INVITE電文の単位時間当たりの件数と、ＳＩＰサーバが出力するInitial INVITE電文の、内部処理時間だけタイミングを後ろにずらした単位時間当たりの件数とを用いて輻輳を判定するため、輻輳の状況を正確に把握することができる。
【図面の簡単な説明】
【００２３】
【図１】従来におけるシステムの構成例を示す図である。
【図２】一実施形態にかかるシステムの構成例を示す図である。
【図３】ＳＩＰサーバにおけるInitial INVITEの要求受信とInitial INVITEのＨＯＰ送信の時間的関係を示す図である。
【図４】ＳＩＰサーバの負荷によるInitial INVITE要求受信数とInitial INVITE ＨＯＰ送信数の変化の例を示す図である。
【図５】ＴＣＰバッファにおけるInitial INVITEの滞留とＳＩＰサーバ処理時間の関係を示す図である。
【図６】輻輳検出装置の内部構成例を示す図である。
【図７】電文解析・抽出部の処理例を示すフローチャートである。
【図８】INVITE[入]集計部の処理例を示すフローチャートである。
【図９】INVITE[出]集計部の処理例を示すフローチャートである。
【図１０】滞留時間算出部の処理例を示すフローチャートである。
【図１１】輻輳検出部の処理例を示すフローチャートである。
【発明を実施するための形態】
【００２４】
以下、本発明の好適な実施形態につき説明する。
【００２５】
＜構成＞
図２は一実施形態にかかるシステムの構成例を示す図である。
【００２６】
図２において、ＮＧＮネットワーク１には複数のＳＩＰサーバ２Ａ〜２Ｄと、複数のエッジルータ３Ａ〜３Ｃとが設けられており、エッジルータ３Ａ〜３Ｃに複数の電話機４Ａ〜４Ｆが接続されている。また、ＳＩＰサーバ２Ａとエッジルータ３Ａの間にはＳＰＡＮタップ５Ａが、ＳＩＰサーバ２Ｂとエッジルータ３Ｂの間にはＳＰＡＮタップ５Ｂが、ＳＩＰサーバ２Ｃとエッジルータ３Ｂの間にはＳＰＡＮタップ５Ｃが、ＳＩＰサーバ２Ｄとエッジルータ３Ｃの間にはＳＰＡＮタップ５Ｄが設けられている。そして、ＳＩＰサーバ２Ｂを監視対象とする輻輳検出装置６がＳＰＡＮタップ５Ｂに接続されている。
【００２７】
図３はＳＩＰサーバ２（２Ａ〜２Ｄ）におけるInitial INVITEの要求受信とInitial INVITEのＨＯＰ送信の時間的関係を示す図である。
【００２８】
着目しているＳＩＰサーバ２において、他のＳＩＰサーバからInitial INVITEを受信すると、その処理結果としてInitial INVITEのＨＯＰ送信を更に他のＳＩＰサーバ２に対して行う。Initial INVITEの要求受信とInitial INVITEのＨＯＰ送信は、ＳＰＡＮタップ５によりＳＩＰサーバ２に出入りするＩＰパケットをコピーして取り出すことで、監視が可能である。
【００２９】
ＳＩＰサーバ２で受信されるInitial INVITEをINVITE[入]、ＳＩＰサーバ２からＨＯＰ送信されるInitial INVITEをINVITE[出]とし、それぞれの件数をカウントして計測する。
【００３０】
ＳＩＰサーバ２が輻輳していない場合、一定期間に集計したINVITE[入]件数は、内部処理時間後に一定期間集計したINVITE[出]件数と等しくなる。
【００３１】
図４はＳＩＰサーバの負荷によるInitial INVITE要求受信数とInitial INVITE ＨＯＰ送信数の変化の例を示す図である。
【００３２】
ＳＩＰサーバ２にて、単位時間ｔ当たりのINVITE[入]件数（要求件数）をｎとし、ＳＩＰサーバ２での内部処理時間をｔ'後の単位時間ｔ当たりのINVITE[出]件数（ＨＯＰ件数）をｍとする。
【００３３】
この場合、ＳＩＰサーバ２が過負荷もなく輻輳状態で無い場合、図４（ａ）に示すように、要求件数ｎは、内部処理時間ｔ'後のＨＯＰ件数ｍと同数となる。すなわち、処理が遅延していない間は、ｎとｍの値は等しくなる。
【００３４】
一方、ＳＩＰサーバ２が過負荷処理により輻輳状態となると、図４（ｂ）に示すように、要求件数ｎよりも、内部処理時間ｔ'後のＨＯＰ件数ｍが小さくなる。すなわち、処理が遅延してくると、ｎ＞ｍとなる。
【００３５】
このように、単位時間当たりのINVITE[入]件数と、ＳＩＰサーバ２の内部処理時間分ずらした単位時間当たりのINVITE[出]件数とを比較し、INVITE[入]件数の方が多い場合は、処理の遅延が発生していると判定することができる。
【００３６】
INVITE[入]と、そのINVITE[入]の処理結果であるINVITE[出]を対応付けることができれば、その取得時間の差から内部処理時間ｔ'を測定することができ、上記の輻輳の判定に用いることができる。しかしながら、一般に普及しているＢ２ＢＵＡ型のＳＩＰサーバの場合、入出力のInitial INVITEの関連付けができない。すなわち、入力したInitial INVITEとは別のコールＩＤが、出力するInitial INVITEに付されるため、両者を対応付けることができない。そのため、内部処理時間ｔ'を測定するために工夫が必要となる。以下、内部処理時間を測定する手法につき説明する。
【００３７】
図５はＴＣＰバッファにおけるInitial INVITEの滞留とＳＩＰサーバ処理時間の関係を示す図である。
【００３８】
図５（ａ）に示すように、ＳＩＰサーバ２に入力したInitial INVITEはＴＣＰバッファに蓄えられた後、先頭から取り出されて処理される。
【００３９】
この場合、図５（ｂ）に示すように、ＳＩＰサーバ２は、Initial INVITEを受信した後、ＴＣＰバッファでの滞留時間ｔ２'を経て、即座に100Tryingの応答が行われ、その後に純粋処理時間ｔ１'を経て対向の他のＳＩＰサーバへInitial INVITEを送出する。従って、内部処理時間ｔ'は滞留時間ｔ２'と純粋処理時間ｔ１'を加えたものとなる。
【００４０】
ここで、ＳＩＰサーバとして一般に普及しているＢ２ＢＵＡ型であっても、受信したInitial INVITEと応答される100Tryingには同じコールＩＤが付されているため、滞留時間ｔ２'の測定が可能である。通常、100Trying応答はInitial INVITEの受信後に直ちに応答される。そのため、輻輳していない状態では、滞留時間ｔ２'は小さな値となる。しかし、ＳＩＰサーバ２の負荷が高くなると、Initial INVITEの受信（ＴＣＰバッファのキューへ登録）から100Trying応答までに大きな滞留時間が発生し、滞留時間ｔ２'は大きくなる。また、純粋処理時間ｔ１'はＳＩＰサーバ２のスペックにより決まるほぼ固定の時間である。
【００４１】
従って、滞留時間ｔ２'と純粋処理時間ｔ１'を加算することで、正確な内部処理時間ｔ'を求めることができる。なお、純粋処理時間ｔ１'は小さな値（例：２〜３ｍｓ）であり、輻輳発生時の滞留時間ｔ２'（例：数秒）に比べると無視し得る値であるため、内部処理時間ｔ'を滞留時間ｔ２'とみなして差し支えない。
【００４２】
図６は輻輳検出装置６の内部構成例を示す図である。
【００４３】
図６において、輻輳検出装置６は、キャプチャ部６１と電文解析・抽出部６２とINVITE[入]集計部６３とINVITE[出]集計部６４と滞留時間算出部６５と輻輳検出部６６と輻輳制御部６７とを備えている。
【００４４】
キャプチャ部６１は、ＳＰＡＮタップ５によりコピーされたデータからデータを取得する機能を有している。
【００４５】
電文解析・抽出部６２は、キャプチャ部６１により取得されたデータに対して電文の解析および抽出を行う機能を有している。電文解析・抽出部６２は、計測対象データ＃１として、発生時刻付きのINVITE[入]の通知をINVITE[入]集計部６３に出力する。また、計測対象データ＃２として、発生時刻付きのINVITE[出]の通知をINVITE[出]集計部６４に出力する。また、計測対象データ＃３として、発生時刻付きのINVITE[入]と100Trying[出]の通知をINVITE[出]集計部６４に出力する。
【００４６】
INVITE[入]集計部６３は、電文解析・抽出部６２からINVITE[入]発生の通知を受けて、単位時間毎のINVITE[入]件数を集計する機能を有している。
【００４７】
INVITE[出]集計部６４は、電文解析・抽出部６２からINVITE[出]発生の通知を受けて、単位時間毎のINVITE[出]件数を集計する機能を有している。
【００４８】
滞留時間算出部６５は、電文解析・抽出部６２からINVITE[入]発生と100Trying[出]発生の通知を受けて、INVITE[入]とそれに対応する100Trying[出]の時間差から滞留時間を算出する機能を有している。
【００４９】
輻輳検出部６６は、INVITE[入]集計部６３により集計された単位時間毎のINVITE[入]件数と、INVITE[出]集計部６４により集計された単位時間毎のINVITE[出]件数と、滞留時間算出部６５により計算された滞留時間とに基づき、監視対象のＳＩＰサーバに輻輳が発生しているか否か判定する機能を有している。
【００５０】
輻輳制御部６７は、輻輳が発生しているＳＩＰサーバおよび周辺のＳＩＰサーバに対して通知を行い、接続要求を抑える等の措置をとらせる機能を有している。
【００５１】
＜動作＞
図７は電文解析・抽出部６２の処理例を示すフローチャートである。
【００５２】
図７において、電文解析・抽出部６２は、キャプチャ部６１から入力したキャプチャデータに対し、Ｌ２（Layer 2）解析として、Ｅｔｈｅｒレベルのパケット解析を行い、ＩＰパケットのみを抽出する（ステップＳ２１）。
【００５３】
次いで、電文解析・抽出部６２は、Ｌ３（Layer 3）解析として、ＩＰレベルのパケット解析を行い、監視対象のＳＩＰサーバへ出入りするパケットを抽出する（ステップＳ２２）。
【００５４】
次いで、電文解析・抽出部６２は、Ｌ４（Layer 4）解析として、ＴＣＰ／ＵＤＰレベルのパケット解析を行い、ＳＩＰ送受信データの組み立てを行う（ステップＳ２３）。
【００５５】
そして、電文解析・抽出部６２は、ＳＩＰ電文解析として、ＳＩＰ手順レベルの電文解析を行い、解析対象となるINVITE[入]、INVITE[出]、100Trying[出]の電文を抽出し、発生事項を付けて通知する（ステップＳ２４）。すなわち、INVITE[入]発生をINVITE[入]集計部６３と滞留時間算出部６５に通知し、INVITE[出]発生をINVITE[出]集計部６４に通知し、100Trying[出]発生を滞留時間算出部６５に通知する。
【００５６】
図８はINVITE[入]集計部６３の処理例を示すフローチャートである。
【００５７】
図８において、INVITE[入]集計部６３は、電文解析・抽出部６２からINVITE[入]発生の通知を受けると、INVITE[入]集計として、単位時間毎のINVITE[入]件数を集計する（ステップＳ３１）。
【００５８】
すなわち、今回の発生時刻が前回の発生時刻と同一の集計単位時間であれば、件数カウンタをカウントアップする。
【００５９】
また、今回の発生時刻が前回の発生時刻と同一の集計単位時間でなければ、
・件数オーバした場合は、一番古い記録データをパージ
・集計した時刻と件数カウンタを記録
・件数カウンタへ１をセット
の処理を行う。
【００６０】
一方、輻輳検出部６６から参照開始／終了時刻を指定して単位時間毎のINVITE[入]件数が要求された場合、INVITE[入]集計部６３は、INVITE[入]参照として、指定時間のINVITE[入]件数を参照し、参照開始時刻と終了時刻の間に発生したINVITE[入]件数をサマリして応答する（ステップＳ３２）。
【００６１】
図９はINVITE[出]集計部６４の処理例を示すフローチャートである。
【００６２】
図９において、INVITE[出]集計部６４は、電文解析・抽出部６２からINVITE[出]発生の通知を受けると、INVITE[出]集計として、単位時間毎のINVITE[出]件数を集計する（ステップＳ４１）。
【００６３】
すなわち、今回の発生時刻が前回の発生時刻と同一の集計単位時間であれば、件数カウンタをカウントアップする。
【００６４】
また、今回の発生時刻が前回の発生時刻と同一の集計単位時間でなければ、
・件数オーバした場合は、一番古い記録データをパージ
・集計した時刻と件数カウンタを記録
・件数カウンタへ１をセット
の処理を行う。
【００６５】
一方、輻輳検出部６６から参照開始／終了時刻を指定して単位時間毎のINVITE[出]件数が要求された場合、INVITE[出]集計部６４は、INVITE[出]参照として、指定時間のINVITE[出]件数を参照し、参照開始時刻と終了時刻の間に発生したINVITE[出]件数をサマリして応答する（ステップＳ４２）。
【００６６】
図１０は滞留時間算出部６５の処理例を示すフローチャートである。
【００６７】
図１０において、滞留時間算出部６５は、電文解析・抽出部６２からINVITE[入]発生と100Trying[出]発生の通知を受けると、滞留時間算出として、INVITE[入]とそれに対応する100Trying[出]の時間差測定を行う（ステップＳ５１）。
【００６８】
すなわち、状態が未計測でINVITE[入]を受けた場合、
・INVITE[入]の発生時刻とコールＩＤを記録
・状態を計測中に変更
・INVITE[入]の発生時刻＋タイムアウト時間をタイムアウト時刻として記録
の処理を行う。
【００６９】
また、状態が計測中で記録しているコールＩＤと同一値のコールＩＤを持つ100Trying[出]を受けた場合、
・100Trying[出]発生時刻を滞留算出時刻として、INVITE[入]の発生時刻と100Trying[出]発生時刻の差分を滞留時間として記録（最新の１件のみ）
・INVITE[入]の発生時刻とコールＩＤをパージ
・状態を未計測に変更
の処理を行う。
【００７０】
また、状態が計測中で受けた電文の発生時刻がタイムアウト時刻を超過した場合、
・INVITE[入]の発生時刻とコールＩＤをパージ
・状態を未計測に変更
の処理を行う。
【００７１】
また、その他の場合は、通知を破棄（何もしない）する。
【００７２】
一方、輻輳検出部６６から参照が行われた場合、滞留時間算出部６５は、滞留時間参照として、計測した最新の滞留時間、その計測時刻を参照し、記録している滞留時間、その計測時刻を応答する。
【００７３】
図１１は輻輳検出部６６の処理例を示すフローチャートである。
【００７４】
図１１において、輻輳検出部６６は、インターバルタイマーにより周期的に処理を開始する。
【００７５】
すなわち、滞留時間取得として、最新の滞留時間、その計測時刻を参照する（ステップＳ６１）。すなわち、滞留時間算出部６５を使用して最新の滞留時間、その計測時刻を取得する。
【００７６】
次いで、計測時刻更新確認として、計測時刻が前回と異なるかを確認する（ステップＳ６２）。すなわち、計測時刻が保存計測時刻と同一の場合は、処理を終了する。また、計測時刻が保存計測時刻と異なる場合は、今回の計測時刻を保存計測時刻へ設定して処理を継続する。
【００７７】
次いで、INVITE[出]取得として、指定時間のINVITE[出]件数を参照する（ステップＳ６３）。すなわち、INVITE[出]集計部６４を使用して参照開始を計測時刻、終了を計測時刻＋計測期間として、その間に発生したINVITE[出]件数を取得する。
【００７８】
次いで、INVITE[入]取得として、指定時間のINVITE[入]件数を参照する（ステップＳ６４）。すなわち、INVITE[入]集計部６３を使用して参照開始を計測時刻−滞留時間、終了を計測時刻＋計測期間−滞留時間として、その間に発生したINVITE[入]件数を取得する。
【００７９】
次いで、輻輳判定として、INVITE[出]件数とINVITE[入]件数を比較して輻輳を判定する（ステップＳ６５）。すなわち、INVITE[入]件数／INVITE[出]件数  ＜  輻輳閾値の場合は、処理を終了する。また、上記以外の場合は、INVITE[入]件数／INVITE[出]件数を輻輳係数とし、輻輳が発生しているＳＩＰサーバのＩＰアドレスと共に、輻輳制御部６７へ通知する。
【００８０】
輻輳制御部６７は、輻輳が発生しているＳＩＰサーバおよび周辺のＳＩＰサーバに対して通知を行い、輻輳中のＳＩＰサーバへの接続要求を抑える等の措置をとらせる。
【００８１】
＜総括＞
以上説明したように、本実施形態によれば、次のような利点がある。
（１）ＳＩＰサーバに入力するInitial INVITEの単位時間当たりの件数と、ＳＩＰサーバが出力するInitial INVITEの、内部処理時間だけタイミングを後ろにずらした単位時間当たりの件数とを用いて輻輳を判定するため、輻輳の状況を正確に把握することができる。
（２）監視対象のＳＩＰサーバとは別の装置で計測を行うため、ＳＩＰサーバが過負荷状態であっても、輻輳の状況を正確に把握することができる。
（３）監視対象のＳＩＰサーバ毎にInitial INVITE件数の閾値を設ける必要がなく、Initial INVITEの入出力件数を直接測定して判定できるため、機器毎での閾値設定等の作業が不要となる。
【００８２】
以上、本発明の好適な実施の形態により本発明を説明した。ここでは特定の具体例を示して本発明を説明したが、特許請求の範囲に定義された本発明の広範な趣旨および範囲から逸脱することなく、これら具体例に様々な修正および変更を加えることができることは明らかである。すなわち、具体例の詳細および添付の図面により本発明が限定されるものと解釈してはならない。
（付記１）
監視対象のＳＩＰサーバの輻輳状態を検出する装置であって、
前記ＳＩＰサーバに入力するInitial INVITE電文の単位時間当たりの件数を計測する手段と、
前記ＳＩＰサーバのInitial INVITE電文に対する内部処理時間を計測する手段と、
前記ＳＩＰサーバが出力するInitial INVITE電文の、前記内部処理時間だけタイミングを後ろにずらした単位時間当たりの件数を計測する手段と、
計測した入力電文件数と出力電文件数とを比較することにより輻輳状態であるか否かを判定する手段と
を備えたことを特徴とする輻輳検出装置。
（付記２）
付記１に記載の輻輳検出装置において、
前記ＳＩＰサーバに入力するInitial INVITE電文の入力時刻と、前記ＳＩＰサーバが出力する100Tryingの応答の出力時刻との差に基づいて前記内部処理時間を計測する
ことを特徴とする輻輳検出装置。
（付記３）
付記１または２のいずれか一項に記載の輻輳検出装置において、
前記ＳＩＰサーバとエッジルータの間に挿入したＳＰＡＮタップから、前記ＳＩＰサーバに入出力する電文を取得する
ことを特徴とする輻輳検出装置。
（付記４）
監視対象のＳＩＰサーバの輻輳状態を検出する方法であって、
前記ＳＩＰサーバに入力するInitial INVITE電文の単位時間当たりの件数を計測する工程と、
前記ＳＩＰサーバのInitial INVITE電文に対する内部処理時間を計測する工程と、
前記ＳＩＰサーバが出力するInitial INVITE電文の、前記内部処理時間だけタイミングを後ろにずらした単位時間当たりの件数を計測する工程と、
計測した入力電文件数と出力電文件数とを比較することにより輻輳状態であるか否かを判定する工程と
を備えたことを特徴とする輻輳検出方法。
（付記５）
付記４に記載の輻輳検出方法において、
前記ＳＩＰサーバに入力するInitial INVITE電文の入力時刻と、前記ＳＩＰサーバが出力する100Tryingの応答の出力時刻との差に基づいて前記内部処理時間を計測する
ことを特徴とする輻輳検出方法。
（付記６）
付記４または５のいずれか一項に記載の輻輳検出方法において、
前記ＳＩＰサーバとエッジルータの間に挿入したＳＰＡＮタップから、前記ＳＩＰサーバに入出力する電文を取得する
ことを特徴とする輻輳検出方法。
【符号の説明】
【００８３】
１                  ＮＧＮネットワーク
２、２Ａ〜２Ｄ      ＳＩＰサーバ
３、３Ａ〜３Ｃ      エッジルータ
４、４Ａ〜４Ｆ      電話機
５、５Ａ〜５Ｄ      ＳＰＡＮタップ
６                  輻輳検出装置
６１                キャプチャ部
６２                電文解析・抽出部
６３                INVITE[入]集計部
６４                INVITE[出]集計部
６５                滞留時間算出部
６６                輻輳検出部
６７                輻輳制御部
【図１】
2011055225.tif 000003
【図２】
2011055225.tif 000004
【図３】
2011055225.tif 000005
【図４】
2011055225.tif 000006
【図５】
2011055225.tif 000007
【図６】
2011055225.tif 000008
【図７】
2011055225.tif 000009
【図８】
2011055225.tif 000010
【図９】
2011055225.tif 000011
【図１０】
2011055225.tif 000012
【図１１】
2011055225.tif 000013