(57)【要約】【課題】トラヒック量の増減を監視する装置と比較して、より安価に製造でき、より正確に通信異常を判断することができる情報を収集することが可能な情報収集装置を提供することを目的とする。【解決手段】シグナリングパケット解析部１２は、通信装置が他の機器に接続する際に送信するシグナリングパケットより、時刻と、送信した通信装置を識別する通信装置情報とを抽出する。集計部１３は、シグナリングパケット解析部１２が抽出した通信装置情報と時刻とに基づいて、所定の時間内に通信装置がシグナリングパケットを送信した回数を集計する。【選択図】図１
2009065277.tif 000002
【特許請求の範囲】
【請求項１】
通信装置が他の機器に接続する際に送信するシグナリングパケットより、送信した前記通信装置を識別する通信装置情報とを抽出するシグナリングパケット解析部と、
前記シグナリングパケット解析部が抽出した前記通信装置情報と時刻とに基づいて、所定の時間内に前記通信装置が前記シグナリングパケットを送信した回数を集計する集計部と、
を備えたことを特徴とする情報収集装置。
【請求項２】
通信装置が他の機器に接続する際に送信するシグナリングパケットより、送信した前記通信装置を識別する通信装置情報とを抽出するシグナリングパケット解析部と、
前記シグナリングパケット解析部が抽出した前記通信装置情報と時刻とに基づいて、前記通信装置が前記シグナリングパケットを送信した時間間隔を集計する集計部と、
を備えたことを特徴とする情報収集装置。
【請求項３】
通信装置が他の機器に接続する際に送信するシグナリングパケットより、送信した前記通信装置を識別する通信装置情報とを抽出するシグナリングパケット解析部と、
前記シグナリングパケット解析部が抽出した前記通信装置情報と時刻とに基づいて、所定の時間内に前記通信装置が前記シグナリングパケットを送信した回数を集計する集計部と、
前記集計部が集計した前記回数に基づいてネットワークの異常を判断する異常判断部と、
を備えたことを特徴とする通信異常検知装置。
【請求項４】
通信装置が他の機器に接続する際に送信するシグナリングパケットより、送信した前記通信装置を識別する通信装置情報とを抽出するシグナリングパケット解析部と、
前記シグナリングパケット解析部が抽出した前記通信装置情報と時刻とに基づいて、前記通信装置が前記シグナリングパケットを送信した時間間隔を集計する集計部と、
前記集計部が集計した前記時間間隔に基づいてネットワークの異常を判断する異常判断部と、
を備えたことを特徴とする情報収集装置。
【請求項５】
通信装置が他の機器に接続する際に送信するシグナリングパケットより、送信した前記通信装置を識別する通信装置情報とを抽出するシグナリングパケット解析ステップと、
前記シグナリングパケット解析ステップで抽出した前記通信装置情報と時刻とに基づいて、所定の時間内に前記通信装置が前記シグナリングパケットを送信した回数を集計する集計ステップと、
をコンピュータに実行させるためのコンピュータプログラム。
【請求項６】
通信装置が他の機器に接続する際に送信するシグナリングパケットより、送信した前記通信装置を識別する通信装置情報とを抽出するシグナリングパケット解析ステップと、
前記シグナリングパケット解析ステップで抽出した前記通信装置情報と時刻とに基づいて、前記通信装置が前記シグナリングパケットを送信した時間間隔を集計する集計ステップと、
をコンピュータに実行させるためのコンピュータプログラム。
【請求項７】
通信装置が他の機器に接続する際に送信するシグナリングパケットより、送信した前記通信装置を識別する通信装置情報とを抽出するシグナリングパケット解析ステップと、
前記シグナリングパケット解析ステップで抽出した前記通信装置情報と時刻とに基づいて、所定の時間内に前記通信装置が前記シグナリングパケットを送信した回数を集計する集計ステップと、
前記集計ステップで集計した前記回数に基づいてネットワークの異常を判断する異常判断ステップと、
をコンピュータに実行させるためのコンピュータプログラム。
【請求項８】
通信装置が他の機器に接続する際に送信するシグナリングパケットより、送信した前記通信装置を識別する通信装置情報とを抽出するシグナリングパケット解析ステップと、
前記シグナリングパケット解析ステップで抽出した前記通信装置情報と時刻とに基づいて、前記通信装置が前記シグナリングパケットを送信した時間間隔を集計する集計ステップと、
前記集計ステップで集計した前記時間間隔に基づいてネットワークの異常を判断する異常判断ステップと、
をコンピュータに実行させるためのコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークの異常を判断するための情報を収集する情報収集装置、通信異常検知装置およびコンピュータプログラムに関する。
【背景技術】
【０００２】
図２０は一般的な通信事業者網の構成を示した図である。一般的な通信事業者網は、図２０に示す通り、基地局１７１と、サーバ１７２と、ルータ１７３と、モデム１７４とを備え、他の通信事業者網と接続している。また、基地局１７１と携帯電話１７５とが無線通信接続している。図２０に示したとおり通信事業者網は、基地局１７１、サーバ１７２、ルータ１７３などの多数の通信装置から構成されており、それらが相互に接続されている。通信事業者網の障害を検知する方法として、トラヒック制御装置を使用する方法がある。トラヒック制御装置は、例えばＷｅｂアクセスに用いられるＨＴＴＰなどのアプリケーションプロトコルを解釈可能であり、さらにＩＰフロー単位でのトラヒック制御を行える場合が多い。またトラヒック制御装置は、ＩＰパケットをキャプチャし、ＩＰパケットの発／着となるＩＰアドレスやポート番号の組で識別される詳細なＩＰフロー単位でのトラヒック分析を行うことが可能である（例えば非特許文献１参照）。
【非特許文献１】Cisco SCE 2000シリーズ  −シスコシステムズ−  [online]. Cisco Systems, Inc. [retrieved on 2007-08-08]. Retrieved from the Internet: <URL: http://www.cisco.com/japanese/warp/public/3/jp/product/hs/sce/sce2000/index.shtml >.
【発明の開示】
【発明が解決しようとする課題】
【０００３】
しかしながら、トラヒック制御装置は、大量のパケットを扱わないといけないため、一般的に高価なものである。かつ、トラヒック制御装置は監視対象とする通信路毎に設置する必要があり、多数の通信路を監視する必要がある通信事業者のような網の場合は、多額の導入費用が必要となる。また、トラヒック制御装置で分析可能な内容は基本的にはトラヒック量の増減である。しかしながら、具体的なトラヒック増減の発生原因としては次のような内容が考えられる。（１）なんらかの理由により、ユーザが多数アクセスしているためトラヒックが増加する。（２）深夜などのユーザが少ない状況のためトラヒックが減少する。（３）通信事業者網内での障害発生のため、通信ができないことによりトラヒックが減少する。（４）通信事業者網内での障害発生のため、接続端末が通信を再試行することによるトラヒックが増加する。よって、トラヒック量の増減を見ているだけでは、トラヒック量の増減の発生原因が分からないという問題がある。すなわち、単にトラヒック増減を見ているだけでは、障害が発生しているのか、時間的な変化によるトラヒック増減が発生しているのかの判別が困難である。
【０００４】
本発明は上記の課題を解決するためになされたものであり、トラヒック量の増減を監視する装置と比較して、より導入費用の低減が図られ、より正確に通信異常を判断することができる情報を収集することが可能な情報収集装置および通信異常検知装置を提供することを目的とする。
【課題を解決するための手段】
【０００５】
本発明は、通信装置が他の機器に接続する際に送信するシグナリングパケットより、時刻と、送信した前記通信装置を識別する通信装置情報とを抽出するシグナリングパケット解析部と、前記シグナリングパケット解析部が抽出した前記通信装置情報と時刻とに基づいて、所定の時間内に前記通信装置が前記シグナリングパケットを送信した回数を集計する集計部と、を備えたことを特徴とする情報収集装置である。
【０００６】
また、本発明は、通信装置が他の機器に接続する際に送信するシグナリングパケットより、送信した前記通信装置を識別する通信装置情報とを抽出するシグナリングパケット解析部と、前記シグナリングパケット解析部が抽出した前記通信装置情報と時刻とに基づいて、前記通信装置が前記シグナリングパケットを送信した時間間隔を集計する集計部と、を備えたことを特徴とする情報収集装置である。
【０００７】
また、本発明は、通信装置が他の機器に接続する際に送信するシグナリングパケットより、送信した前記通信装置を識別する通信装置情報とを抽出するシグナリングパケット解析部と、前記シグナリングパケット解析部が抽出した前記通信装置情報と時刻とに基づいて、所定の時間内に前記通信装置が前記シグナリングパケットを送信した回数を集計する集計部と、前記集計部が集計した前記回数に基づいてネットワークの異常を判断する異常判断部と、を備えたことを特徴とする通信異常検知装置である。
【０００８】
また、本発明は、通信装置が他の機器に接続する際に送信するシグナリングパケットより、送信した前記通信装置を識別する通信装置情報とを抽出するシグナリングパケット解析部と、前記シグナリングパケット解析部が抽出した前記通信装置情報と時刻とに基づいて、前記通信装置が前記シグナリングパケットを送信した時間間隔を集計する集計部と、前記集計部が集計した前記時間間隔に基づいてネットワークの異常を判断する異常判断部と、を備えたことを特徴とする情報収集装置である。
【０００９】
また、本発明は、通信装置が他の機器に接続する際に送信するシグナリングパケットより、送信した前記通信装置を識別する通信装置情報とを抽出するシグナリングパケット解析ステップと、前記シグナリングパケット解析ステップで抽出した前記通信装置情報と時刻とに基づいて、所定の時間内に前記通信装置が前記シグナリングパケットを送信した回数を集計する集計ステップと、をコンピュータに実行させるためのコンピュータプログラムである。
【００１０】
また、本発明は、通信装置が他の機器に接続する際に送信するシグナリングパケットより、送信した前記通信装置を識別する通信装置情報とを抽出するシグナリングパケット解析ステップと、前記シグナリングパケット解析ステップで抽出した前記通信装置情報と時刻とに基づいて、前記通信装置が前記シグナリングパケットを送信した時間間隔を集計する集計ステップと、をコンピュータに実行させるためのコンピュータプログラムである。
【００１１】
また、本発明は、通信装置が他の機器に接続する際に送信するシグナリングパケットより、送信した前記通信装置を識別する通信装置情報とを抽出するシグナリングパケット解析ステップと、前記シグナリングパケット解析ステップで抽出した前記通信装置情報と時刻とに基づいて、所定の時間内に前記通信装置が前記シグナリングパケットを送信した回数を集計する集計ステップと、前記集計ステップで集計した前記回数に基づいてネットワークの異常を判断する異常判断ステップと、をコンピュータに実行させるためのコンピュータプログラムである。
【００１２】
また、本発明は、通信装置が他の機器に接続する際に送信するシグナリングパケットより、送信した前記通信装置を識別する通信装置情報とを抽出するシグナリングパケット解析ステップと、前記シグナリングパケット解析ステップで抽出した前記通信装置情報と時刻とに基づいて、前記通信装置が前記シグナリングパケットを送信した時間間隔を集計する集計ステップと、前記集計ステップで集計した前記時間間隔に基づいてネットワークの異常を判断する異常判断ステップと、をコンピュータに実行させるためのコンピュータプログラムである。
【発明の効果】
【００１３】
この発明によれば、トラヒック量の増減を監視する装置と比較して、より導入費用の低減が図られ、より正確に通信異常を判断することができる情報を収集することが可能となる。
【発明を実施するための最良の形態】
【００１４】
以下、本発明の一実施形態を、図面を参照して説明する。図２は、本実施形態での通信システムの構成を示した構成図である。図示する例では、通信システムの構成には、情報収集装置１と、サーバ２と、ユーザ端末３とが含まれる。また、サーバ２とユーザ端末３はネットワークで接続されている。情報収集装置１は、ユーザ端末３が送信するシグナリングパケットを収集する。なお、情報収集端末装置１はパケットキャプチャにより、ネットワーク上からシグナリングパケットを収集してもよく、ＳＮＭＰ等により、サーバ２より発呼間隔や発呼回数の集計結果もしくは集計に必要な情報を収集してもよい。また、情報収集装置１は収集したシグナリングパケットの解析、及び前記パケット解析結果もしくは前記サーバ２より得られた情報を用いて、発呼間隔や発呼回数の集計を実施する。ここで解析対象となるシグナリングパケットには、次のような場合がある。（１）呼接続要求メッセージの場合。この場合は、接続元のユーザ端末３がサーバ２経由で他の接続先のユーザ端末３に接続する際に、接続元のユーザ端末３がサーバ２に対して送信する。サーバ２は接続元のユーザ端末３と接続先のユーザ端末３とのセッションを確立する。ユーザ端末３はユーザ端末３同士でデータの送受信を行う。（２）サーバへの要求メッセージの場合。この場合は、ユーザ端末３がサーバ２に情報や接続を要求するメッセージを送信する。サーバ２はユーザ端末３に要求された情報を返答したり、接続を許可したりする。
【００１５】
次に、本実施形態での情報収集装置１の構成について図１を参照して説明する。図１は本実施形態における情報収集装置１の構成を示した構成図である。情報収集装置１は、キャプチャ用ネットワークインタフェース部１０と、パケットキャプチャ部１１と、シグナリングパケット解析部１２と、集計部１３と、表示部１４とを備える。
【００１６】
パケットキャプチャ部１１は、キャプチャ用ネットワークインタフェース部１０を介してパケットを収集し、さらにそのパケットの中からシグナリングパケットを抽出する。抽出する方法としては、パケットのヘッダ部分を解析し、シグナリングパケットのみを抽出する。パケットキャプチャ部１１は、抽出したシグナリングパケットに対して時刻情報を付加し、シグナリングパケットを図示せず記憶部に格納する。
【００１７】
シグナリングパケット解析部１２は記憶部からシグナリングパケットを読み出し、各シグナリングパケットから、そのシグナリングパケットを送信したユーザ端末を識別する端末情報と、パケットキャプチャ部１１によって付加された時刻情報とを抽出する。シグナリングパケット解析部１２は、抽出した端末情報と時刻情報とを関連付けて記憶部に格納する。
【００１８】
集計部１３は記憶部から端末情報と時刻情報を読み出し、ユーザ端末ごとに各単位時間で発生した呼接続の発生回数を集計する。具体的には、まず集計部１３は、端末情報によって識別される各ユーザ端末の時刻情報について、時刻情報が示す時刻が所定の単位時間に含まれるか否かを判定する。続いて、集計部１３は、所定の単位時間に含まれた時刻の数を算出する。この数がその単位時間における呼接続発生回数となる。集計部１３はこの計算を各ユーザ端末および各単位時間について実行し、各単位時間の識別情報と端末情報と呼接続発生回数とを関連付けた情報を生成する。
【００１９】
集計部１３はさらに、上記のようにして生成した情報に基づいて、所定の呼接続発生回数を記録したユーザ端末の数を単位時間ごとに集計し、各単位時間の識別情報と呼接続発生回数と端末数とを関連付けた情報を生成し、記憶部に格納する。
【００２０】
なお、集計部１３は記憶部から端末情報と時刻情報を読み出し、ユーザ端末ごとに各単位時間で発生した呼接続の発生間隔を集計しても良い。具体的には、まず集計部１３は、端末情報によって識別される各ユーザ端末の時刻情報について、時刻情報が示す時刻が所定の単位時間に含まれるか否かを判定する。続いて、集計部１３は、所定の単位時間に含まれた時刻とその直前の時刻との差を算出する。この差がその単位時間における呼接続間隔となる。集計部１３はこの計算を各ユーザ端末および各単位時間について実行し、各単位時間の識別情報と端末情報と呼接続間隔とを関連付けた情報を生成する。
【００２１】
集計部１３はさらに、上記のようにして生成した情報に基づいて、所定の呼接続間隔の発生回数を単位時間ごとに集計し、各単位時間の識別情報と呼接続間隔と呼接続発生回数とを関連付けた情報を生成し、記憶部に格納する。
【００２２】
表示部１４は、集計部１３が記憶部に格納した情報を表示する。
【００２３】
次に、本実施形態において情報収集装置１が取得および集計した情報より、ネットワークの異常を検知する方法について図３から図６を参照して説明する。ここでは、シグナリングメッセージが呼接続要求メッセージの場合として記載しているが、サーバへの要求メッセージの場合でも同様の判断が可能となる。一般的に通信システムにおいて、使用者が端末装置を用いて通信システムに接続する場合、端末装置が目的の接続先であるサーバに接続できない場合、使用者は端末装置を操作して再度接続操作を行う場合が多い。
【００２４】
例えば携帯電話パケット網において、携帯電話使用者は、携帯電話の呼接続ボタンを押して目的のサーバに接続しようとしても目的のサーバに接続できない場合、呼切断ボタンを押した後再度呼接続ボタンを押して再度接続操作を行う場合が多い。再接続操作は無線環境が悪い場合にも携帯電話使用者によって行われるが、携帯電話パケット網内で障害が発生している場合は、再接続操作が行われる携帯電話数は無線環境が悪い場合よりも多くなる。すなわち、携帯電話パケット網内で障害が発生している場合、各ユーザ端末の単位時間あたりの呼接続回数は多くなり、また、各ユーザ端末の呼接続間隔は短くなる。
【００２５】
図３は本実施形態での単位時間あたりの呼接続回数の例を示した図である。図示する例ではユーザ端末Ａと、ユーザ端末Ｂと、ユーザ端末Ｃと、ユーザ端末Ｄとがある。各ユーザ端末の横に記されている丸印は、各端末が呼接続を行ったタイミングを示す。また、横軸で時間を表している。本実施形態では所定の単位時間を設定し、その単位時間内で発生した呼接続についてその発生頻度（呼接続回数）を計算する。なお、単位時間は任意で決めてよく、図３では、例えば単位時間を１８０秒とする。また、図示する例では、単位時間は破線で記されている。
【００２６】
図示する例では、単位時間１８０秒の間にユーザ端末Ａが呼接続を行った回数は２回であり、ユーザ端末Ｂが呼接続を行った回数は１回であり、ユーザ端末Ｃが呼接続を行った回数は２回であり、ユーザ端末Ｄが呼接続を行った回数は０回である。よって、ユーザ端末４台中、呼接続回数０回のユーザ端末数は１端末あり、呼接続回数１回のユーザ端末数は１端末であり、呼接続回数２回のユーザ端末数は２端末である。これを割合に直すと、呼接続回数０回のユーザ端末数は全ユーザ端末数の２５％であり、呼接続回数１回のユーザ端末数は全ユーザ端末数の２５％であり、呼接続回数２回のユーザ端末数は全ユーザ端末数の５０％である。本実施形態では、ネットワーク管理者などの管理者が、本実施形態の情報収集装置１が表示する呼接続回数ごとに集計したユーザ端末数の割合を監視することで、ネットワークの異常を知ることができる。
【００２７】
ネットワークの異常を知る具体的な方法は図４を参照して説明する。図４は本実施形態において、単位時間あたりで、呼接続回数ごとに集計したユーザ端末数の割合を示した図である。横軸は経過時間であり、縦軸はユーザ端末数の割合である。単位時間は１８０秒である。単位時間あたりの呼接続回数は０回から１０回、１１回から２０回、２１回から３０回、・・・、９１回から１００回、１００回以上の１１区分に分けている。
【００２８】
各区分に属するユーザ端末数の割合を図に示している。図示する例では、経過時間が０秒から１８０秒の間で呼接続回数が０回から１０回であったユーザ端末の割合は９８％である。経過時間が０秒から１８０秒の間と同様に、経過時間が１２６０秒までは単位時間あたりの呼接続回数が０回から１０回であったユーザ端末の割合は９８％前後である。経過時間が１２６０秒から１４４０秒の間で呼接続回数が０回から１０回であったユーザ端末の割合は７７％となり、単位時間あたりの呼接続回数が１１回以上のユーザ端末数の割合が２３％と増えている。経過時間が１４４０秒から１６２０秒の間で呼接続回数が０回から１０回であったユーザ端末の割合は８％となり、単位時間あたりの呼接続回数が１１回以上のユーザ端末数の割合が９２％と増えている。以下同様に単位時間あたりでの呼接続回数ごとに集計したユーザ端末数の割合が図よりわかる。
【００２９】
図４の例では、経過時間が１２６０秒付近から単位時間あたりの呼接続回数が１１回以上のユーザ端末数の割合が増え、経過時間３０６０秒付近から単位時間あたりの呼接続回数が１１回以上のユーザ端末数の割合が減少していることから、携帯電話パケット網内での障害は、経過時間が１２６０秒付近から発生し、経過時間３０６０秒付近で復旧していることがわかる。
【００３０】
また、図５は本実施形態での単位時間あたりの呼接続間隔の例を示した図である。図示する例ではユーザ端末Ａと、ユーザ端末Ｂと、ユーザ端末Ｃと、ユーザ端末Ｄとがある。横軸は時間を表している。単位時間は横軸である時間軸の一部である。各ユーザ端末の横に記されている丸印は、各端末が呼接続を行ったタイミングを示す。また、丸印から他の丸印に伸びている矢印は、呼接続間隔を示す。図示する例では、単位時間は破線で記されている。なお、単位時間は任意で決めてよく、図５では、例えば単位時間を６０秒とする。
【００３１】
図示する例では、単位時間６０秒の間にユーザ端末Ａが呼接続を行った回数は２回であり、前回の呼接続との呼接続間隔は２０秒と１０秒である。単位時間６０秒の間にユーザ端末Ｂが呼接続を行った回数は１回であり、前回の呼接続との呼接続間隔は２０秒である。単位時間６０秒の間にユーザ端末Ｃが呼接続を行った回数は２回であり、前回の呼接続との呼接続間隔は１０秒と４０秒である。単位時間６０秒の間にユーザ端末Ｄが呼接続を行った回数は０回である。よって、単位時間６０秒の間では、前回の呼接続との呼接続間隔が１０秒で呼接続を行った呼接続回数は２回であり、前回の呼接続との呼接続間隔が２０秒で呼接続を行った呼接続回数は２回であり、前回の呼接続との呼接続間隔が４０秒で呼接続を行った呼接続回数は１回である。
【００３２】
これを割合に直すと、前回の呼接続との呼接続間隔が１０秒で呼接続を行った呼接続回数は、単位時間６０秒の間での全呼接続回数の４０％であり、前回の呼接続との呼接続間隔が２０秒で呼接続を行った呼接続回数は、単位時間６０秒の間での全呼接続回数の４０％であり、前回の呼接続との呼接続間隔が４０秒で呼接続を行った呼接続回数は、単位時間６０秒の間での全呼接続回数の２０％である。本実施形態では、ネットワーク管理者などの管理者が、本実施形態の情報収集装置１が表示する前回の呼接続との呼接続間隔ごとに集計した呼接続回数の割合を監視することで、ネットワークの異常を知ることができる。
【００３３】
ネットワークの異常を知る具体的な方法は図６を参照して説明する。図６は本実施形態において、単位時間あたりで、前回の呼接続との呼接続間隔ごとに集計した呼接続回数の割合を示した図である。横軸は経過時間であり、縦軸は呼接続回数の割合である。単位時間は６０秒である。呼接続間隔は０秒から２秒、２秒から４秒、４秒から８秒、・・・、２６秒から２８秒、２８秒以上の１５区分に分けている。各区分に属する呼接続回数の割合を図に示している。
【００３４】
図示する例では、経過時間が０秒から６０秒の間で呼接続間隔が０秒から２秒であった呼接続の割合は０％である。経過時間が６０秒から１２０秒の間で呼接続間隔が０秒から２秒であった呼接続の割合は４０％である。経過時間が０秒から１８０秒の間と同様に、経過時間が１２０秒から４２０秒までは単位時間において、呼接続間隔が０秒から２秒であった呼接続の割合は０％である。経過時間が４２０秒から２１００秒の間で呼接続間隔が０秒から２秒であった呼接続の割合は５０％以上である。以下同様に単位時間あたりで前回の呼接続との呼接続間隔ごとに集計した呼接続回数の割合が図６よりわかる。
【００３５】
図６の例では、経過時間が４２０秒付近から単位時間あたりの呼接続間隔が０秒から２秒であった呼接続の割合が増え、経過時間２１００秒付近から単位時間あたりの呼接続間隔が０秒から２秒であった呼接続の割合が減少していることから、携帯電話パケット網内での障害は、経過時間が４２０秒付近から発生し、経過時間２１００秒付近で復旧していることがわかる。
【００３６】
上述したとおり、本実施形態の情報収集装置１が集計する単位時間あたりの呼接続回数または呼接続間隔を参照することで、通信事業者網内で発生した障害を検知することが可能である。なお、情報収集装置１は単位時間あたりの呼接続回数を集計してもよく、単位時間あたりの呼接続間隔を集計してもよく、単位時間あたりの呼接続回数と呼接続間隔の両方を集計してもよい。
【００３７】
なお、本実施形態ではパケットキャプチャ部１１がシグナリングパケットに対して時刻情報を付加しているが、他の装置で時刻情報が付加されていても良い。例えば、ユーザ端末がシグナリングパケットに送信した時刻を時刻情報として付加しても良く、パケットを転送するサーバが、パケットを転送した時刻を時刻情報として付加しても良い。また、例えば、時刻情報はある時刻を基準とした相対時刻でもよい。
【００３８】
次に、本実施形態において情報収集装置１が取得するシグナリングパケットの一例について図７と図８とを参照して説明する。図７は本実施形態の携帯電話パケット網を示した構成図である。携帯電話パケット網は基地局７１と、ＰＤＳＮ７２（Ｐａｃｋｅｔ  Ｄａｔａ  Ｓｅｒｖｉｎｇ  Ｎｏｄｅ）と、課金／認証（ＲＡＤＩＵＳ、Ｒｅｍｏｔｅ  Ａｕｔｈｅｎｔｉｃａｔｉｏｎ  Ｄｉａｌ  Ｉｎ  Ｕｓｅｒ  Ｓｅｒｖｉｃｅ）サーバ７３と、ホームエージェント７４（ＨＡ、Ｈｏｍｅ  Ａｇｅｎｔ）とを含む。また、携帯電話パケット網は、ホームエージェント７４を介し、Ｗｅｂサービスを提供するＷｅｂサーバ７５や、メールサービスを提供するメールサーバ７６や、企業網７７や、インターネット７８などと接続している。ホームエージェント７４は接続サービスごとに用意されている。基地局７１は各地に点在しており、ＰＤＳＮ７２と、ホームエージェント７４と、ＲＡＤＩＵＳサーバ７３とは通信事業者の局舎内に設置されている場合が多い。また、携帯電話７９（ユーザ端末）は基地局７１と無線で接続される。基地局７１は無線アクセス網でＰＤＳＮ７２と接続されている。ＰＤＳＮ７２は携帯電話７９に対し課金や認証を行う。ＲＡＤＩＵＳサーバ７３はＰＤＳＮ７２に接続されており、携帯電話７９に対し行う課金や認証の管理を行う。
【００３９】
次に、携帯電話からＩＰパケット通信を行う手順について図８を参照して説明する。図８は本実施形態における携帯電話からＩＰパケット通信を行う手順のシーケンス図である。
【００４０】
（ステップＳ１０１）携帯電話７９はＰＤＳＮ７２に対してＰＰＰ（Ｐｏｉｎｔ−ｔｏ−Ｐｏｉｎｔ）セッション確立要求メッセージを送信する。ＰＰＰセッション確立要求メッセージにはユーザ名と、パスワードと、利用サービスと、端末番号とが含まれる。
【００４１】
（ステップＳ１０２）ＰＤＳＮ７２は、携帯電話７９より送信されたＰＰＰセッション確立要求メッセージに含まれるユーザ名とパスワードとが正しいか、ＲＡＤＩＵＳサーバ７３に問い合わせてユーザ認証を行う。ユーザ認証作業は、ＰＤＳＮ７２がＲＡＤＩＵＳサーバ７３に対して「ユーザ認証要求（Ｒａｄｉｕｓ  Ａｃｃｅｓｓ  Ｒｅｑｕｅｓｔ）」のＲＡＤＩＵＳパケットを送信し、ＲＡＤＩＵＳサーバ７３がＰＤＳＮ７２に対して「ユーザ認証応答（Ｒａｄｉｕｓ  Ａｃｃｅｓｓ  Ａｃｃｅｐｔ）」のＲＡＤＩＵＳパケットを送信することで実施する。
【００４２】
（ステップＳ１０３）ＰＤＳＮ７２は、携帯電話７８より送信されたＰＰＰセッション確立要求メッセージに含まれる利用サービス情報に基づいてセッション登録を行う。セッション登録作業は、ＰＰＰセッション確立要求メッセージに含まれる利用サービスを提供するＨＡ７４に対して、ＰＤＳＮ７２が、「セッション登録要求（Ｍｏｂｉｌｅ  ＩＰ  Ｒｅｇｉｓｔｒａｔｉｏｎ  Ｒｅｑｕｅｓｔ）」のＭｏｂｉｌｅ  ＩＰパケットを送信し、そのＭｏｂｉｌｅ  ＩＰパケットを受信したＨＡ７４がＰＤＳＮ７２に対して「セッション登録応答（Ｍｏｂｉｌｅ  ＩＰ  Ｒｅｇｉｓｔｒａｔｉｏｎ  Ｒｅｐｌｙ）」のＭｏｂｉｌｅ  ＩＰパケットを送信することで実施する。なお、「セッション登録要求（Ｍｏｂｉｌｅ  ＩＰ  Ｒｅｇｉｓｔｒａｔｉｏｎ  Ｒｅｑｕｅｓｔ）」のＭｏｂｉｌｅ  ＩＰパケットには、サービス名と、認証情報と、端末情報とが含まれる。
【００４３】
（ステップＳ１０４）ＰＤＳＮ７２は携帯電話７９に対し、ＰＰＰセッションが確立したことを通知する。
（ステップＳ１０５）携帯電話７９は通信相手先とＩＰパケットによるデータ通信を実施する。
以上が呼接続操作の手順である。
【００４４】
次に、呼接続回数、呼接続間隔の取得方法について説明する。本実施形態では、呼接続操作に関連したシグナリングパケットを解析することで、ユーザ端末の呼接続情報を取得する。
【００４５】
図７を参照して説明した呼接続操作では、シグナリングパケットはＰＰＰセッション確立要求メッセージと、Ｒａｄｉｕｓ  Ａｃｃｅｓｓ  Ｒｅｑｕｅｓｔと、Ｍｏｂｉｌｅ  ＩＰ  Ｒｅｇｉｓｔｒａｔｉｏｎ  Ｒｅｑｕｅｓｔとの３つのメッセージである。先述したとおり、これら３つのシグナリングパケットにはユーザ認証のための情報と、ユーザ端末を識別するための情報と、利用するサービスの情報とが含まれている。よって、これらのシグナリングパケットを解析することで、ユーザ端末単位での呼接続回数や呼接続間隔を示す呼接続情報を取得することができる。なお、呼接続情報を取得する際に、ＰＰＰセッション確立要求メッセージと、Ｒａｄｉｕｓ  Ａｃｃｅｓｓ  Ｒｅｑｕｅｓｔと、Ｍｏｂｉｌｅ  ＩＰ  Ｒｅｇｉｓｔｒａｔｉｏｎ  Ｒｅｑｕｅｓｔとの３つのシグナリングメッセージを使用しても良いし、この内の１つまたは２つを使用しても良い。
【００４６】
次に、具体的なＭｏｂｉｌｅ  ＩＰ  Ｒｅｇｉｓｔｒａｔｉｏｎ  Ｒｅｑｕｅｓｔのパケットフォーマットについて図９を参照して説明する。図９はＭｏｂｉｌｅ  ＩＰ  Ｒｅｇｉｓｔｒａｔｉｏｎ  Ｒｅｑｕｅｓｔのパケットフォーマットを示した図である。図示する様に、Ｍｏｂｉｌｅ  ＩＰ  Ｒｅｇｉｓｔｒａｔｉｏｎ  Ｒｅｑｕｅｓｔは通常Ｍｏｂｉｌｅ  Ｎｏｄｅ  ＮＡＩ  Ｅｘｔｅｎｓｉｏｎを含んでいる。図示するように、ＮＡＩはＭｏｂｉｌｅ  Ｎｏｄｅ  ＮＡＩ  ＥｘｔｅｎｓｉｏｎのＭＮ−ＮＡＩ部分に含まれる。ＮＡＩはＵＳＥＲ＠ｄｏｍａｉｎ形式で表されることが多く、“ＵＳＥＲ”部分でユーザ端末の識別が可能であり、“ｄｏｍａｉｎ”部分でサービスの識別が可能である。また、ユーザ端末の識別は、端末のＨｏｍｅ  ＮｅｔｗｏｒｋでのＩＰアドレスを示すＭｏｂｉｌｅ  ＩＰのＨｏｍｅ  Ａｄｄｒｅｓｓでも可能である。
【００４７】
次に、具体的なＲａｄｉｕｓ  Ａｃｃｅｓｓ  Ｒｅｑｕｅｓｔのパケットフォーマットについて図１０を参照して説明する。図１０はＲａｄｉｕｓ  Ａｃｃｅｓｓ  Ｒｅｑｕｅｓｔのパケットフォーマットを示した図である。図示する様に、Ｒａｄｉｕｓ  Ａｃｃｅｓｓ  Ｒｅｑｕｅｓｔパケットは、ユーザ名や端末番号を示すため、Ａｔｔｒｉｂｕｔｅ  Ｖａｌｕｅ  Ｐａｉｒ（ＡＶＰ）を含んでいる。Ｃａｌｌｉｎｇ  Ｓｔａｔｉｏｎ  ＩＤは端末の識別子を表しており、Ｕｓｅｒ−ＮａｍｅはＵＳＥＲ＠ｄｏｍａｉｎ形式でユーザ名を表すことが多い。Ｕｓｅｒ−ＮａｍｅがＵＳＥＲ＠ｄｏｍａｉｎ形式の場合、Ｍｏｂｉｌｅ  ＩＰ  Ｒｅｇｉｓｔｒａｔｉｏｎ  Ｒｅｑｕｅｓｔと同様、“ＵＳＥＲ”部分でユーザ端末の識別が可能であり、“ｄｏｍａｉｎ”部分でサービスの識別が可能である。なお、Ｃａｌｌｉｎｇ  Ｓｔａｔｉｏｎ  ＩＤと、Ｕｓｅｒ−Ｎａｍｅは共に値はＳｔｒｉｎｇの部分に入る。
【００４８】
次に、本実施形態の情報収集装置１をシグナリングパケット収集対象の通信システムに設置する設置例について図１１を参照して説明する。図１１は本実施形態の情報収集装置１を通信システムに接続した構成を示した図である。図示する例では、通信システムにはＰＤＳＮ１１１と、ＨＡ１１２と、ネットワークスイッチ１１３と、基地局１１４と、ユーザ端末１１５とが含まれる。なお、ＨＡ１１２ではなく、Ｒａｄｉｕｓサーバでも良い。
【００４９】
ネットワークスイッチ１１３にはＰＤＳＮ１１１とＨＡ１１２とが接続されている。また、ＰＤＳＮ１１１と、ＨＡ１１２とが接続されているスイッチに情報収集装置１は接続されている。図示する例では、ネットワークスイッチ１１３において、ポートミラーリングという手法で、各ユーザ端末１１５からＰＤＳＮ１１１を介してＨＡ１１２へ送信されるパケットを情報収集装置１は収集する。なお、パケット収集方法は、物理的（電気的、光学的）に分岐するＴＡＰと呼ばれる手法など、多数の手法があり、本実現手法ではそのどれを適用しても問題ない。また、情報収集装置１は、収集したパケットを解析して各ユーザ端末１１５の呼接続回数や呼接続間隔を取得する。
【００５０】
ユーザ端末（携帯端末）の呼接続情報は基地局など多数の箇所で取得することが可能であるが、上述したとおり、ネットワークスイッチ１１３に情報収集装置１を接続することにより、情報収集装置１を通信システムの中の一箇所のみの設置でユーザ端末（携帯端末）の呼接続情報を取得することが可能となる。
【００５１】
また、これまで通信事業の携帯電話パケット網を例として説明してきたが、本実施形態の情報収集装置１は、ユーザ端末が他の装置に接続を開始する際にシグナリングパケットが送信される通信網にも適用可能である。例えば、ＩＰ電話に用いられるＳＩＰ（Ｓｅｓｓｉｏｎ  Ｉｎｉｔｉａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）サーバを有するネットワークを例として図１２を参照して説明する。図１２は本実施形態におけるＳＩＰサーバを有するネットワークの構成を示す構成図である。図示する例では通信事業者網１２１と通信事業者網１２２とが接続されている。通信事業者網１２１にはＳＩＰサーバＡ１２３が含まれる。通信事業者網１２２にはＳＩＰサーバＢ１２４が含まれる。端末Ａ１２５は通信事業者網１２１に接続されている。端末Ｂ１２６は通信事業者網１２２に接続されている。
【００５２】
次に、図１２の端末Ａ１２５から端末Ｂ１２６に対して呼接続する際の手順について図１３を参照して説明する。図１３は本実施形態における端末Ａから端末Ｂに呼接続を行う手順のシーケンス図である。
【００５３】
（ステップＳ２０１）端末Ａ１２５はＳＩＰサーバＡ１２３にＩＮＶＩＴＥメッセージを送信する。
（ステップＳ２０２）ＳＩＰサーバＡ１２３は端末Ａ１２５にＴｒｙｉｎｇメッセージを送信する。
（ステップＳ２０３）ＳＩＰサーバＡ１２３はＳＩＰサーバＢ１２４にＩＮＶＩＴＥメッセージを送信する。
（ステップＳ２０４）ＳＩＰサーバＢ１２４はＳＩＰサーバＡ１２３にＴｒｙｉｎｇメッセージを送信する。
（ステップＳ２０５）ＳＩＰサーバＢ１２４は端末Ｂ１２６にＩＮＶＩＴＥメッセージを送信する。
（ステップＳ２０６）端末Ｂ１２６はＳＩＰサーバＢ１２４にＴｒｙｉｎｇメッセージを送信する。
（ステップＳ２０７）端末Ｂ１２６はＳＩＰサーバＢ１２４にＲｉｎｇｉｎｇメッセージを送信する。
（ステップＳ２０８）ＳＩＰサーバＢはＳＩＰサーバＡにＲｉｎｇｉｎｇメッセージを送信する。
（ステップＳ２０９）ＳＩＰサーバＡ１２３は端末Ａ１２５にＲｉｎｇｉｎｇメッセージを送信する。
【００５４】
図示するように、ＳＩＰにおいては、使用者がユーザ端末（端末Ａ）を用いて呼接続操作を行うたびに、ＩＮＶＩＴＥメッセージがユーザ端末より必ず送出される。ＩＮＶＩＴＥメッセージの例を図１４に示す。図１４は本実施形態でのＩＮＶＩＴＥメッセージの例を示した図である。図示する例では、ＩＮＶＩＴＥメッセージのＶｉａ、またはＩＮＶＩＴＥメッセージのＦｒｏｍ、またはＩＮＶＩＴＥメッセージのＩＰヘッダに含まれるＳｏｕｒｃｅ  ＩＰアドレスのいずれかをユーザ端末の識別子とみなすことが可能である。また、ＩＮＶＩＴＥメッセージのＣｏｎｔｅｎｔ−Ｔｙｐｅをサービス識別子とみなすことが可能である。また、サービス識別子については、ＳＩＰと共に用いられるＳＤＰ（Ｓｅｓｓｉｏｎ  Ｄｅｓｃｒｉｐｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）がＩＮＶＩＴＥメッセージに含まれている場合、より詳細なサービスの区別が可能となる。
【００５５】
また、ＩＮＶＩＴＥメッセージはユーザ端末からＳＩＰサーバに対して送信される。そのため、図１２に示す構成では、ＳＩＰサーバＡ１２３もしくはＳＩＰサーバＢ１２４でＩＮＶＩＴＥメッセージをパケットキャプチャし、ユーザ端末ごとの呼接続の回数や、呼接続の間隔を取得することで、ネットワークの異常を監視することが可能である。
【００５６】
さらに、これまで通信事業の携帯電話パケット網、ＩＰ電話に用いられるＳＩＰシグナリング例として説明してきたが、本実施形態の情報収集装置１は、ユーザ端末がサーバに情報を要求したり、接続を実施したりするシグナリングにも適用可能である。例えば、ホスト名からＩＰアドレスを解決するＤＮＳ（Ｄｏｍａｉｎ  Ｎａｍｅ  Ｓｙｓｔｅｍ）を例として図１７を参照して説明する。図１７は本実施形態におけるＤＮＳサーバを有する構成図である。図示する例では通信事業者網１３１は通信業者網１３２とが接続されている。通信事業者網１３１にはＤＮＳサーバＡ１３３が含まれる。通信事業者網１３２にはＤＮＳサーバＢ１３４が含まれる。ユーザ端末１３５は通信事業者網１３１に接続されている。ここで、通信事業者１３１はｅｘａｍｐｌｅＡ．ｊｐ、通信事業者１３２はｅｘａｍｐｌｅＢ．ｊｐというドメインを有しているとし、ＤＮＳサーバＡ１３３はｅｘａｍｐｌｅＡ．ｊｐドメインのホストとＩＰアドレスに関する情報、ＤＮＳサーバＢ１３４はｅｘａｍｐｌｅＢ．ｊｐドメインのホストとＩＰアドレスに関する情報をそれぞれ管理しているとする。
【００５７】
さらに、ＤＮＳサーバＡ１３３はネットワークスイッチ１３６に通信事業者網１３１内で接続されているものとし、情報収集装置１はネットワークスイッチ１３６でシグナリングパケットを収集可能であるとする。
【００５８】
次に、図１７のユーザ端末１３５がｈｏｓｔ．ｅｘａｍｐｌｅＢ．ｊｐというホスト名からＩＰアドレスをＤＮＳを用いて解決する際の手順について図１８を参照して説明する。なお、この操作は一般的に名前解決と呼称される。図１８は本実施形態におけるユーザ端末がホスト名からＩＰアドレスを解決する手順のシーケンス図である。
【００５９】
（ステップＳ３０１）ユーザ端末１３５はＤＮＳサーバＡ１３３にＤＮＳ  Ｑｕｅｒｙを送信する。
（ステップＳ３０２）ＤＮＳサーバＡ１３３はＤＮＳサーバＢ１３４にＤＮＳ  Ｑｕｅｒｙを送信する。
（ステップＳ３０３）ＤＮＳサーバＢ１３４はＤＮＳサーバＡ１３３にＤＮＳ  Ｒｅｓｐｏｎｓｅを送信する。
（ステップＳ３０４）ＤＮＳサーバＡ１３３はユーザ端末１３５にＤＮＳ  Ｒｅｓｐｏｎｓｅを送信する。
【００６０】
図示するように、ＤＮＳにおいては、使用者がユーザ端末上でホスト名からＩＰアドレスの解決をするたびに、ＤＮＳ Ｑｕｅｒｙがユーザ端末より必ず送出される。ＤＮＳ  Ｑｕｅｒｙメッセージの例を図１９に示す。図示する例では、ＤＮＳ  ＱｕｅｒｙのＳｏｕｒｃｅ ＩＰアドレスをユーザ端末の識別子としてみなすことが可能である。また、ＤＮＳ  Ｑｕｅｒｙメッセージの宛先ポート番号、または送信されているのがＤＮＳメッセージであることのいずれかをサービス識別子とみなすことが可能である。
【００６１】
また、ＤＮＳ  ＱｕｅｒｙメッセージはＤＮＳサーバに対して送信される。加えて、図１８に示したように、ユーザ端末は自端末が属するネットワークのＤＮＳサーバ（ＤＮＳサーバＡ１３３）にＤＮＳ  Ｑｕｅｒｙを送信し、ＤＮＳサーバＡは名前解決の対象となるホストが管理されているＤＮＳサーバ（ＤＮＳサーバＢ１３４）にＤＮＳ  Ｑｕｅｒｙを送信する。そのため、図１７に示す構成では、通信事業者網１３１の網内でパケットをキャプチャし、ユーザ端末毎にＤＮＳ  Ｑｕｅｒｙ送信を呼接続のためのシグナリングとみなし、その回数や間隔を取得することで、他事業者網（例えば、通信事業者網１３２）のＤＮＳサーバの不調や、ネットワークの異常を監視することが可能である。
【００６２】
なお、ここではＤＮＳによる名前解決を例として説明を実施したが、他の通信プロトコルで要求と応答があるような場合にも本実施形態を適用可能である。その他の例としては、ＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ）における接続方法である３ｗａｙ  Ｈａｎｄｓｈａｋｅがあげられる。
【００６３】
上述したとおり、本実施形態では、ユーザ端末が他の装置に接続を開始する際にシグナリングパケットを送信し、シグナリングパケットにユーザ端末を識別するための識別子を含む通信を行うネットワークにおいて、ユーザ端末ごとの呼接続の回数や、呼接続の間隔を取得することで、取得した情報に基づいてネットワークの異常を監視することができる。なお、シグナリングパケットに含まれるユーザ端末を識別するための識別子としては、シグナリングパケット内に端末番号のようなユーザ端末が一意に決定可能な情報でも良いし、シグナリングパケットの発信元のＩＰアドレスでも良い。
【００６４】
また、図１の情報収集装置はパケットキャプチャ部を備えているが、図１５に示す情報収集装置のようにパケットキャプチャ部の代わりに収集インターフェイス部を備えてもよい。この場合は、ＰＤＳＮや、ＨＡや、Ｒａｄｉｕｓサーバ等からＳＮＭＰ等のインターフェイスにより、ユーザ端末ごとの呼接続回数または呼接続間隔のデータを収集インターフェイス部が取得する。
【００６５】
図１５は本実施形態における収集インターフェイスを備えた情報収集装置のブロック図である。収集インターフェイスを備えた情報収集装置は、通信用ネットワークインタフェース２１と、収集インターフェイス部２２と、集計部２３と、表示部２４とを備える。通信用ネットワークインタフェース部２１は、ユーザ端末ごとの呼接続回数または呼接続間隔のデータを送信するサーバ等の機器（図示せず）と接続する。収集インターフェイス部２２は、通信用ネットワークインタフェース部２１を介してユーザ端末ごとの呼接続回数または呼接続間隔のデータを受信する。集計部２３は、収集インターフェイス部２２が取得したユーザ端末ごとの呼接続回数に基づいて、単位時間あたりのユーザ端末ごとの呼接続回数を集計する。なお、集計部２３は、収集インターフェイス部２２が取得したユーザ端末ごとの呼接続回数に基づいて、単位時間あたりのユーザ端末ごとの呼接続間隔を集計してもよい。表示部２４は、集計部２３が集計した結果を表示する。
【００６６】
また、本実施形態の情報収集装置に異常判断部を備えて通信異常検知装置とすることも可能である。図１６は本実施形態における通信異常検知装置の構成を示した構成図である。通信異常検知装置３０は、キャプチャ用ネットワークインタフェース部１０と、パケットキャプチャ部１１と、シグナリングパケット解析部１２と、集計部１３と、異常判断部３１と、表示部１４とを備える。キャプチャ用ネットワークインタフェース部１０と、パケットキャプチャ部１１と、シグナリングパケット解析部１２と、集計部１３とは、情報収集装置１と同様である。異常判断部３１は、集計部１３が集計したユーザ端末ごとの呼接続回数に基づいてネットワークの異常を判断する。例えば、単位時間あたりにおいて、呼接続回数が４０回以上のユーザ端末の割合が５０％を越えた場合、異常判断部３１はネットワークに異常があると判断する。表示部１４は異常判断部３１が判断した結果を表示する。なお、異常判断部３１は集計部１３が集計した単位時間あたりで、前回の呼接続との呼接続間隔ごとの呼接続回数に基づいてネットワークの異常を判断しても良い。例えば、単位時間あたりにおいて、呼接続間隔が０秒から２秒であった呼接続の割合が５０％を越えた場合、異常判断部３１はネットワークに異常があると判断しても良い。
【００６７】
上述したとおり本実施形態によれば、シグナリングパケットを取得し解析することで、トラヒック量の増減を監視することなく通信異常を判断するための情報を収集することが実現できる。また、情報収集装置に異常判断部を備えることで、トラヒック量の増減を監視することなく通信異常を検知することが実現できる。
【００６８】
また、シグナリングパケットにサービス識別のための情報を含む場合、サービス単位で呼接続回数や呼接続間隔を集計することで、サービス単位の障害検知が可能となる。また、シグナリングパケットの解析を行うため、ＰＤＳＮ、ＨＡ、Ｒａｄｉｕｓなどのサーバ別のパケット送信数や、送信されたシグナリング種別毎のパケット数も得ることが可能である。これにより、サーバ自体の障害や負荷を検知することも可能である。
【００６９】
なお、上述した実施形態における情報収集装置または通信異常検知装置のキャプチャ用ネットワークインタフェース機能全体あるいはその一部、パケットキャプチャ機能全体あるいはその一部、シグナリングパケット解析機能全体あるいはその一部、集計機能全体あるいはその一部、表示機能全体あるいはその一部、通信用ネットワークインタフェース機能全体あるいはその一部、収集インターフェイス機能全体あるいはその一部、異常判断機能全体あるいはその一部は、これらの機能実現するためのプログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行することによって実現しても良い。なお、ここでいう「コンピュータシステム」とは、ＯＳや周辺機器等のハードウェアを含むものとする。
【００７０】
また、「コンピュータ読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ＲＯＭ、ＣＤ−ＲＯＭ等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置のことをいう。さらに「コンピュータ読み取り可能な記録媒体」とは、インターネット等のネットワークや電話回線等の通信回線を介してプログラムを送信する場合の通信線のように、短時刻の間、動的にプログラムを保持するもの、その場合のサーバやクライアントとなるコンピュータシステム内部の揮発性メモリのように、一定時刻プログラムを保持しているものも含んでも良い。また上記プログラムは、前述した機能の一部を実現するためのものであっても良く、さらに前述した機能をコンピュータシステムにすでに記録されているプログラムとの組み合わせで実現できるものであっても良い。
【００７１】
以上、この発明の実施形態について図面を参照して詳述してきたが、具体的な構成はこの実施形態に限られるものではなく、この発明の要旨を逸脱しない範囲の設計等も含まれる。
【図面の簡単な説明】
【００７２】
【図１】本発明の一実施形態における情報収集装置の構成を示した構成図である。
【図２】本実施形態でのネットワーク構成を示した構成図である。
【図３】本実施形態での単位時間あたりの呼接続回数の例を示した図である。
【図４】本実施形態において、単位時間あたりで、呼接続回数ごとに集計したユーザ端末数の割合を示した図である。
【図５】本実施形態での単位時間あたりの呼接続間隔の例を示した図である。
【図６】本実施形態において、単位時間あたりで、前回の呼接続との呼接続間隔ごとに集計した呼接続回数の割合を示した図である。
【図７】本実施形態の携帯電話パケット網を示した構成図である。
【図８】本実施形態における携帯電話からＩＰパケット通信を行う手順のシーケンス図である。
【図９】Ｍｏｂｉｌｅ  ＩＰ  Ｒｅｇｉｓｔｒａｔｉｏｎ  Ｒｅｑｕｅｓｔのパケットフォーマットを示した図である。
【図１０】Ｒａｄｉｕｓ  Ａｃｃｅｓｓ  Ｒｅｑｕｅｓｔのパケットフォーマットを示した図である。
【図１１】本実施形態の情報収集装置１を通信システムに接続した構成を示した図である。
【図１２】本実施形態におけるＳＩＰサーバを有するネットワークの構成を示す構成図である。
【図１３】本実施形態における端末Ａから端末Ｂに呼接続を行う手順のシーケンス図である。
【図１４】本実施形態でのＩＮＶＩＴＥメッセージの例を示した図である。
【図１５】本実施形態における収集インターフェイスを備えた情報収集装置のブロック図である。
【図１６】本実施形態における通信異常検知装置の構成を示した構成図である。
【図１７】本実施形態におけるＤＮＳサーバを有するネットワークの構成を示す構成図である。
【図１８】本実施形態におけるユーザ端末からＤＮＳサーバを用いて名前解決を行う手順のシーケンス図である。
【図１９】本実施形態でのＤＮＳ  Ｑｕｅｒｙメッセージの例を示した図である。
【図２０】一般的な通信事業者網の構成を示した図である。
【符号の説明】
【００７３】
１・・・情報収集装置、２・・・サーバ、３，７９，１１５，１３５・・・ユーザ端末（携帯電話）、１０・・・キャプチャ用ネットワークインタフェース部、１１・・・パケットキャプチャ部、１２・・・シグナリングパケット解析部、１３，２３・・・集計部、１４，２４・・・表示部、２１・・・通信用ネットワークインタフェース、２２・・・収集インターフェイス部、３１・・・異常判断部、７１，１１４・・・基地局、７２，１１１・・・ＰＤＳＮ、７３・・・課金／認証サーバ（ＲＡＤＩＵＳサーバ）、７４，１１２・・・ホームエージェント（ＨＡ）、７５・・・Ｗｅｂサーバ、７６・・・メールサーバ、７７・・・企業網、７８・・・インターネット、１１３，１３６・・・ネットワークスイッチ、１２１，１２２，１３１，１３２・・・通信事業者網、１２３・・・ＳＩＰサーバＡ、１２４・・・ＳＩＰサーバＢ、１２５・・・端末Ａ、１２６・・・端末Ｂ、１３３・・・ＤＮＳサーバＡ、１３４・・・ＤＮＳサーバＢ
【図１】
2009065277.tif 000003
【図２】
2009065277.tif 000004
【図３】
2009065277.tif 000005
【図４】
2009065277.tif 000006
【図５】
2009065277.tif 000007
【図６】
2009065277.tif 000008
【図７】
2009065277.tif 000009
【図８】
2009065277.tif 000010
【図９】
2009065277.tif 000011
【図１０】
2009065277.tif 000012
【図１１】
2009065277.tif 000013
【図１２】
2009065277.tif 000014
【図１３】
2009065277.tif 000015
【図１４】
2009065277.tif 000016
【図１５】
2009065277.tif 000017
【図１６】
2009065277.tif 000018
【図１７】
2009065277.tif 000019
【図１８】
2009065277.tif 000020
【図１９】
2009065277.tif 000021
【図２０】
2009065277.tif 000022