JP2004201028A - パケット分析装置、パケット分析方法、パケット分析プログラム - Google Patents

Abstract

【課題】特定のサービスについての輻輳状況を把握する。
【解決手段】パケット取得処理部１１によって取得したパケットについて、そのパケットが準拠しているプロトコルをプロトコル検出処理部１２で検出し、さらにパケット内分析処理部１３でパケットの内容を分析する。こうすることにより、携帯電話網・ＩＰ網にて提供されるある特定のサービスのみについての輻輳状況が把握できる。例えば、Ｗｅｂ関連のサービスが輻輳状態である場合、Ｗｅｂ関連のどのサービスが輻輳しているのかを特定することができ、他のサービスに影響を与えずに特定サービスのみを遮断することができる。また、プロトコルを検出し、パケットの内容を分析することにより、携帯電話網・ＩＰにて提供されるサービスについて、どの年代や性別が多く利用しているか等のデータを取得でき、網を流通しているデータそのものを経営資源とすることができる。
【選択図】 図１

Description

【０００１】
【発明の属する技術分野】
本発明はパケット分析装置、パケット分析方法、パケット分析プログラムに関し、特に携帯電話網及びＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）網における通信を分析し、分析結果を各種窓口等のサービスフロント業務や、保守・建設・経営部門等へフィードバックさせ、網を流通しているデータそのものを経営資源とするための技術に関するものである。
【０００２】
【従来の技術】
一般に、携帯電話網及びＩＰ網等の公衆回線網においては、通信トラヒックが増加すると、網が輻輳状態になる。この場合、通信トラヒックを制御することによって、輻輳状態を解除するのが一般的である（例えば、非特許文献１）。しかし、そのような処理を行うと種々の問題が生じる。これら問題点について、第１従来例〜第３従来例と共に説明する。
（第１従来例）
従来では輻輳状況のみの監視、またＮＥ（Ｎｅｔｗｏｒｋ Ｅｌｅｍｅｎｔ）に特定しての監視であるとともに、ＮＥが呼処理をしている・していないというレベルでの検出しかできていないために、▲１▼どのサービスで、▲２▼何をしたいのか、を検出することは不可能であった。
【０００３】
例えば、図６（ａ）に示されているように、携帯電話機やパーソナルコンピュータ（以下、ＰＣと略称する）から、携帯電話網内やＩＰ網内のサービス関連ＮＥを介して、同じ網内の装置によるサービスＡ，Ｂ又はサービスＣの提供を受ける場合を考える。
この場合において、サービス関連ＮＥで輻輳が発生すると、その輻輳状態を輻輳監視システムによって検出することはできる。しかし、輻輳の原因、すなわちどのサービスで何をしたい人が多くて輻輳しているかはわからないという問題がある。
（第２従来例）
従来のトラヒック監視においては、ＮＥの呼処理を監視する。このため、自社網を経由して他網（ｉｎｔｅｒｎｅｔ網等）でサービスを行う場合に輻輳したときは、他網と接続しているＮＥの輻輳状態を監視・制御するしかなく、輻輳の原因のトラヒックが、▲１▼どの網で、▲２▼何のサービスを享受したいトラヒックなのか、を検出することは不可能であった。
【０００４】
例えば、図７（ａ）に示されているように、携帯電話機やパーソナルコンピュータから、携帯電話網内やＩＰ網内の他網接続ＮＥを介して、他の網内の装置によるサービスＡ，Ｂ又はサービスＣの提供を受ける場合を考える。
この場合において、他網接続ＮＥで輻輳が発生すると、その輻輳状態を輻輳監視システムによって検出することはできる。しかし、どの網のサービスで何をしたい人が多くて輻輳しているかはわからない。このため、他網接続ＮＥ全体に規制をかけるしか術はなく、規制をかけると通信量が減少し、通信会社の利益が減少するという問題がある。
（第３従来例）
従来のトラヒック監視は、ＮＥの呼処理単位で監視を行うため、誰がどこでどんなサービスを要求しているか等、詳細な情報を知る術は無かった。
【０００５】
例えば、図８（ａ）に示されているように、携帯電話機やパーソナルコンピュータから、携帯電話網内やＩＰ網内のサービス提供ＮＥからサービスの提供を受ける場合を考える。
この場合、輻輳監視システムによって取得できる情報は、利用頻度のみである。すなわち、何時にどのくらいの利用があったか、程度の情報しかわからないという問題がある。このため、例えば、あるサービスの利用者は女性よりも男性の方が多い等の情報は得られない。
【０００６】
【非特許文献１】
立川敬二監修「Ｗ−ＣＤＭＡ移動通信方式」丸善株式会社、２００１年６月２５日発行、ｐ．３１６−３２０
【０００７】
【発明が解決しようとする課題】
上述したように、従来技術には、以下のような問題点があった。
▲１▼従来ではネットワーク上を流れるデータ分析といえば、トラヒック監視のみであり、分析から得られる結果は輻輳情報のみであった。あるサービスの混み具合を確認するには、そのサービスに関連するＮＥのトラヒックを確認し、輻輳状態か否かを判断するしかなかった。また、あるＮＥが複数サービスに関連している場合、特定のサービスの混み具合を確認するのは不可能である。
【０００８】
▲２▼従来では網独自での輻輳検出しかしていない。このため、将来的なＩＰサービス、すなわち網を経由してＩＳＰ（Ｉｎｔｅｒｎｅｔ Ｓｅｒｖｉｃｅ Ｐｒｏｖｉｄｅｒ）のサービスに繋がる場合は、輻輳状況を確認することは不可能である。
▲３▼従来のトラヒック分析から取得できる情報は輻輳情報のみであり、どの年代がどのサービスをよく利用しているか等、経営指針となりうる情報の取得は不可能であった。
【０００９】
本発明は上述した従来技術の欠点を解決するためになされたものであり、その目的は特定のサービスについての輻輳状況が把握でき、また、サービス拡充や経営判断の材料となるデータを取得することのできるパケット分析装置、パケット分析方法、パケット分析プログラムを提供することである。
【００１０】
【課題を解決するための手段】
本発明の請求項１によるパケット分析装置は、網内を流れるパケットを取得するパケット取得手段と、前記パケット取得手段によって取得したパケットが準拠しているプロトコルを検出するプロトコル検出手段と、前記プロトコル検出手段によって検出したプロトコルに従って前記パケットの内容を分析する分析手段と、前記分析手段の分析結果を参照して所定の処理を行う処理手段とを含むことを特徴とする。パケットが準拠しているプロトコルを検出し、さらにパケットの内容を分析することにより、所望の処理を行うことができる。
【００１１】
本発明の請求項２によるパケット分析装置は、請求項１において、前記処理手段は、前記分析結果に応じて前記網の輻輳制御処理を行うことを特徴とする。これにより、携帯電話網・ＩＰ網にて提供されるある特定のサービスのみについての通信を規制する輻輳制御を行うことができる。
本発明の請求項３によるパケット分析装置は、請求項１において、前記処理手段は、前記分析結果について統計処理を行うことを特徴とする。これにより、携帯電話網・ＩＰにて提供されるサービスについて、どの年代や性別が多く利用しているか等、サービス拡充や経営判断の材料となるデータを取得できる。
【００１２】
本発明の請求項４によるパケット分析装置は、請求項１乃至３のいずれか１項において、前記パケット取得手段は、前記網内を流れるパケット全てを、廃棄せずに取得し、それらパケットのヘッダに基づいて再構築したパケットについて前記プロトコル検出手段がプロトコルを検出することを特徴とする。再構築されたパケットのデータ部を見ることにより、そのパケットが準拠している上位プロトコルが何であるのか検出することができる。
【００１３】
本発明の請求項５によるパケット分析装置は、請求項１乃至４のいずれか１項において、前記分析手段は、前記プロトコル検出手段によって検出されたプロトコル毎にパケットの中身を分析することを特徴とする。検出されたプロトコル毎にヘッダ部・データ部を確認することにより、そのデータは何をしたいのかを分析することができる。
【００１４】
本発明の請求項６によるパケット分析方法は、網内を流れるパケットを取得するパケット取得ステップと、前記パケット取得ステップにおいて取得したパケットが準拠しているプロトコルを検出するプロトコル検出ステップと、前記プロトコル検出ステップにおいて検出したプロトコルに従って前記パケットの内容を分析する分析ステップと、前記分析ステップの分析結果を参照して所定の処理を行う処理ステップとを含むことを特徴とする。パケットが準拠しているプロトコルを検出し、さらにパケットの内容を分析することにより、所望の処理を実現できる。例えば、携帯電話網・ＩＰ網にて提供されるある特定のサービスのみについての輻輳状況が把握できる。また、携帯電話網・ＩＰにて提供されるサービスについて、どの年代や性別が多く利用しているか等、サービス拡充や経営判断の材料となるデータを取得できる。
【００１５】
本発明の請求項７によるパケット分析プログラムは、網内を流れるパケットを取得するパケット取得ステップと、前記パケット取得ステップにおいて取得したパケットが準拠しているプロトコルを検出するプロトコル検出ステップと、前記プロトコル検出ステップにおいて検出したプロトコルに従って前記パケットの内容を分析する分析ステップと、前記分析ステップの分析結果を参照して所定の処理を行う処理ステップとを含むことを特徴とする。パケットが準拠しているプロトコルを検出し、さらにパケットの内容を分析することにより、所望の処理を実現できる。例えば、携帯電話網・ＩＰ網にて提供されるある特定のサービスのみについての輻輳状況が把握できる。また、携帯電話網・ＩＰにて提供されるサービスについて、どの年代や性別が多く利用しているか等、サービス拡充や経営判断の材料となるデータを取得できる。
【００１６】
要するに、モバイルネットワーク、企業ネットワーク、インターネット、ＩＳＰ、ＮＳＰ（Ｎｅｔｗｏｒｋ Ｓｅｒｖｉｃｅ Ｐｒｏｖｉｄｅｒ）接続での通信におけるサービスアプリケーションのパケットデータを分析することにより、プロトコル、サービス、ユーザ属性をリアルタイムに抽出でき、また統計処理を行うことができる。
【００１７】
本発明では、インターネットで使用されているＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｃｏｌ）やメールで使われるＳＭＴＰ（Ｓｉｍｐｌｅ Ｍａｉｌ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｃｏｌ）、または網内独自のプロトコル等が実装されるレイヤ５（ＯＳＩ参照モデルにおいて、通信の開始時や終了時等に送受信するデータの形式等を規定しているセッション層）以上の層における分析を行う。レイヤ５以上にはアプリケーションで使われるデータが格納されているため、様々な情報を得ることができる。
【００１８】
網内を流れるパケット全てを本装置で捕らえ、独自プロトコルに準拠しているパケットについては端末所有者等の情報を検出する。また、ＨＴＴＰやその他のプロトコルに準拠しているパケットについてはその中身の情報を見ることにより、どのＷｅｂサイトに何を要求しているのか等を検出することができる。
【００１９】
【発明の実施の形態】
次に、図面を参照して本発明の実施の形態について説明する。なお、以下の説明において参照する各図においては、他の図と同等部分に同一符号が付されている。
図１は本発明によるパケット分析装置の実施の一形態を示すブロック図である。同図に示されているように、本実施形態によるパケット分析装置は、網内を流れるパケットデータ（以下、パケットと略称する）を拾い上げるパケット取得処理部１１と、パケットのプロトコルを検出するプロトコル検出処理部１２と、パケットの中身を分析するパケット内分析処理部１３−ｉ（ｉ＝１〜Ｎ、以下同じ）と、分析結果を蓄積する分析結果蓄積処理部１４と、を含んで構成されている。以下、これら各処理部の機能等について説明した後、装置全体の動作について説明する。
（パケット取得処理部）
パケット取得処理部１１は、網内を流れるパケットを拾い上げる機能を有している。この機能について図２を参照して説明する。
【００２０】
同図に示されているように、パケット取得処理部１１から、各セグメントａ，ｂに対して、物理的な接続を行う。その接続先は、具体的には、ルータやサーバ、ハブ等の、ポートが空いている場所である。そして、パケット取得処理部１１は、取得したパケットに付加されているＩＰヘッダの識別子に基づいて、分割されたデータを再構築する。
【００２１】
すなわち、一般的なＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）は自分が繋がっているネットワークのパケットを全て受信しており、必要の無いものを廃棄する仕様になっている。これに対し、パケット取得処理部１１は、各セグメントのパケットを全て取得する。そして、パケット取得処理部１１においては、それら全てを廃棄せずに、ＩＰヘッダの識別子を基にして、パケットの再構築を行う。この再構築したパケットは、プロトコル検出処理部１２に引渡される。なお、このようなパケット取得処理部１１の処理は、ＵＮＩＸ（登録商標）の「ｔｃｐｄｕｍｐ」等と同様の処理である。
（プロトコル検出処理部）
プロトコル検出処理部１２は、パケット取得処理部１１から引渡されたパケットが準拠しているプロトコルを検出する。この場合、パケットのデータ部を見ることにより、そのパケットが準拠しているプロトコルを検出することができる。すなわち、プロトコル検出処理部１２は、まずＩＰヘッダの内容を見て上位プロトコルが何であるのかを判別する。
【００２２】
プロトコル検出処理部１２は、例えば、パケットが準拠しているプロトコルが、ＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）であるか、ＵＤＰ（Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ）であるか判別する。ＩＰヘッダのプロトコル番号が「６」であればＴＣＰ、「１７」であればＵＤＰと判別できる。これらのようにプロトコル番号が標準で割り当てられているもの以外の独自プロトコル等については、個別に対応しなければならない。要するに、このプロトコル検出処理部１２は、レイヤ４のプロトコルが何であるのかを判別する機能を有している必要がある。
【００２３】
プロトコル検出処理部１２は、より上位層すなわちアプリケーション（以下、ＡＰと略称する）レイヤのプロトコルを確認する。ＡＰレイヤのプロトコルを確認するには、まず、ＴＣＰヘッダやＵＤＰヘッダのポート番号を確認する。ＩＰ網においてはポート番号規約がある。このため、このポート番号ならばＨＴＴＰである等とプロトコルを確定することができる。
【００２４】
このＩＰ網でよく用いられるポート番号は、ウェルノウンポート番号（Ｗｅｌｌ−ｋｎｏｗｎ Ｐｏｒｔ Ｎｕｍｂｅｒ）と呼ばれている。このポート番号には、「０」から「１０２３」までの番号が振られている。なお、最新のポ一ト番号一覧は、インターネット上のサイトhttp://www.iana.org/assignments/port-numbersに記載されている。
【００２５】
プロトコル検出処理部１２は、ＴＣＰ／ＵＤＰヘッダのポート番号を確認し、予め用意しておいたポート番号表と対応させることで、ＡＰレイヤのプロトコルを判別する。また、網内独自のプロトコルを用いる場合は、１０２４番以降の番号でポート番号表に登録しておき、判別できるようにしておく。
プロトコル検出処理部１２によるプロトコル解析が終了した場合、そのパケットのデータは、各プロトコルに特化したパケット内分析処理部１３−ｉに渡される。すなわち、プロトコル検出処理部１２は、ＡＰレイヤのプロトコルがＨＴＴＰと判別した場合にはＨＴＴＰ用のパケット内分析処理部へ、ＡＰレイヤのプロトコルがＳＭＴＰ（Ｓｉｍｐｌｅ Ｍａｉｌ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｃｏｌ）と判別した場合にはＳＭＴＰ用のパケット内分析処理部へ、独自プロトコルならばそれ専用のパケット内分析処理部へ、それぞれデータを引渡す。
（パケット内分析処理部）
パケット内分析処理部１３−ｉは、プロトコルの種類がＮ種類である場合、各プロトコルに準拠しているパケットそれぞれに対応してＮ個用意される。例えば、ＨＴＴＰ用のパケット内分析処理部１３−１，ＳＭＴＰ用のパケット内分析処理部１３−２，…，網内独自プロトコル用のパケット内分析処理部１３−Ｎ、である。これらパケット内分析処理部１３による分析結果は、分析結果蓄積処理部１４に蓄積される。
【００２６】
パケット内分析処理部１３−ｉは、プロトコル検出処理部１２から取得したパケットの中身を、例えば以下のように分析する。すなわち、パケットを引渡されたパケット内分析処理部１３−ｉは、ＩＰヘッダの送信元・宛先ＩＰアドレス、レイヤ５以上のアプリケーションレイヤ（以下、ＡＰレイヤと略称する）のヘッダ部・データ部を確認することにより、そのデータは何をしたいのかを分析する。
【００２７】
ここで、図３には、ＯＳＩ参照モデルにおける各層の関係が示されている。同図に示されているように、ネットワーク層であるレイヤ３の上位に、トランスポート層であるレイヤ４が位置している。周知のＩＰはレイヤ３に属し、ＴＣＰやＵＤＰはレイヤ４に属している。本装置では、より上位の層であるレイヤ５以上の層、すなわちアプリケーションが使用する層において、パケットを分析することになる。
【００２８】
例えば、ＨＴＴＰプロトコルの場合であれば、ＡＰレイヤが以下の内容であった時、
【００２９】
【数１】

【００３０】
ＨＴＴＰ用のパケット内分析処理部は、ＡＰレイヤの中身をパース（ｐａｒｓｅ；データを上から順に下まで読むこと）する。このパースの結果、「この通信はhttp://www.w3.org/test/test.htmlを参照しに行っていて、送信元のＩＰアドレスは〜で…」等という情報が得られる。得られた情報は全てデータベース（以下、ＤＢと略称する）として分析結果蓄積処理部１４に記録する。
【００３１】
パケット内分析処理部１３−ｉは、上記のようにＡＰレイヤをパースし、各プロトコルのルール（仕様）に沿って中身を分折する。また、プロトコル毎に決められた、蓄えるべき情報を抽出し、ＤＢに書込む。
各プロトコルに準拠しているパケットのヘッダには必ず意味があるため、基本的にはその意味を抽出してＤＢに書込む。
【００３２】
ＳＭＴＰのようなコマンドでやり取りするようなプロトコルの場合はコマンドの中身、応答結果を抽出する。
（分析結果蓄積処理部）
パケット内分析処理部１３−ｉによってパケットを分析した結果は、分析結果蓄積処理部１４に蓄積される。この蓄積されるデータは、プロトコル毎に異なるものである。
【００３３】
例えば、プロトコルがＨＴＴＰであるならば、「リクエストなのかレスポンスなのか」「どのサイトに対するリクエストなのか」「送信先はどこか」等を蓄積する。また、プロトコルがＳＭＴＰであるならば、「宛先アドレス又はドメイン」「送信元アドレス又はドメイン」等を蓄積する。以上のような一般的なプロトコルにおいては、ユーザの個人的な情報は蓄積されない。
【００３４】
一報、網内の独自プロトコルであれば、個人情報が特定できるものもある。その場合は、ユーザの個人情報も含めて蓄積する。例えば、独自のプロトコルを使用している携帯電話網においては、携帯電話機からＷｅｂアクセスを行った場合は、「誰の」「どの端末から」「どのサイトにアクセスしているか」が分かるので、これらを蓄積する。
【００３５】
また、得られた情報は即座にＤＢに全て蓄積する。この場合、各プロトコルの仕様に従い、分析結果から抽出される情報が分類されてＤＢに書込まれる。ＤＢに書込む場合、情報を例えば「いつ」「誰が」「何をしている」の３つに大まかに分類して書込む。ここで、「いつ」とは時刻のことである。「誰が」は性別・年齢のことを指す。「何を」はＷｅｂアクセスなのかメールなのか、そのほか別な何かかということである。特に、Ｗｅｂアクセスについては、どのサイトにアクセスしているのか、メールはどの宛先に出しているのか等が書込まれる。
（パケット分析装置の動作）
図４を参照して、パケット分析装置の動作について説明する。
【００３６】
各種端末から様々な要求を受けている網には、様々なプロトコルに準拠したパケットが絶えず流れている。パケット取得処理部１１は、網内を流れるパケットを全て取得する。すなわち、網内の全てのパケットを取得できるように処理を行い、後述する統計分析の基となるバケットの通信を阻害しないように、パケットを取得する。
【００３７】
次に、この取得したパケットについて、プロトコル検出処理部１２により、そのパケットが準拠しているプロトコルを検出する。通常、網内を流れるデータには予め決められているプロトコルしか流通しない。このため、例えばＨＴＴＰやＳＭＴＰ、又は独自プロトコル等の分析用データを用意してプロトコル検出処理部１２に格納しておき、この検出用データを利用し、そのパケットがどのプロトコルに準拠して通信を行っているかを迅速に検出する。
【００３８】
次に、検出した各プロトコルに特化したパケット内分析処理部１３を用いて、必要な情報をパケットから取出し、内部を分析する。この分析結果から、例えばＨＴＴＰであれば、どの端末が何のサービスに（どのＵＲＬに）・何を要求しているのか等がわかる。
そして、このパケット内分析処理部１３の分析結果を、分析結果蓄積処理部１４に蓄積する。この分析結果蓄積処理部１４は、分析結果をどう生かすかを反映したデータベース（以下、ＤＢと略称する）を含んで構成されており、このＤＢを用いて情報の統計処理等を行う。ＤＢ内の情報は、データウェアハウス（以下、ＤＷＨと略称する）を用いて統計処理される。なお、ＤＢに格納する形態は、その格納される情報をどのように活用していくかに依存する。
【００３９】
ところで、分析結果蓄積処理部１４を利用した統計処理の結果は、統計データ１４ａとして出力される。この統計データ１４ａは、例えば、「Ａサイトのαサービスが混んでいてβは空いている」、「サービスＢは全体的に２０代男性の利用者が多い」、「サービスＢは特定時間に女性利用者が増える」等といった統計情報である。
【００４０】
本装置においては、分析結果蓄積処理部１４に蓄積されている内容を参照することにより、所望の処理を行うことができる。例えば、携帯電話網・ＩＰ網にて提供されるある特定のサービスのみについての通信を規制する輻輳制御処理を行うことができる。これにより、不必要な規制をかけることによる通信会社の利益減少が生じなくなる。
【００４１】
また、携帯電話網・ＩＰにて提供されるサービスについて、どの年代や性別が多く利用しているか等、サービス拡充や経営判断の材料となるデータを取得できる。これにより、分析結果を各種窓口等のサービスフロント業務や、保守・建設・経営部門等へフィードバックさせ、網を流通しているデータそのものを経営資源とすることができる。
（従来例の問題の解決）
前述した第１従来例の問題は、以下のように解決することができる。すなわち、網を流れるパケットデータを解析することにより、パケットデータ内のアプリケーションレイヤ（以下、ＡＰレイヤと略称する）やパケットのヘッダ情報から、上述した▲１▼どのサービスで、▲２▼何をしたいのか、を検出できる。つまり、図６（ｂ）に示されているように、網内を流れるパケットを分析し、どのサービスで何をしたい人が多いために輻輳しているか監視することができる。
【００４２】
前述した第２従来例の問題は、以下のように解決することができる。すなわち、ＡＰレイヤトラヒックを監視することにより、上述した▲１▼どの網で、▲２▼何のサービスを享受したいトラヒックなのか、を検出できる。つまり、特定のトラヒックのみを制御するための情報が得られることから、特定呼のみに規制をかけ、利益となる呼を通すことができる。
【００４３】
つまり、図７（ｂ）に示されているように、パケットを分析してどの網の何のサービスへの呼が混んでいるということが検出できる。このため、その特定呼のみを何らかの方法で制御し、他の呼には規制をかけずに通すことができる。よって、通信会社の利益減少を防ぐことができる。
第３従来例の問題は、以下のように解決することができる。すなわち、ＡＰレイヤ監視システムを用いて網を流れるパケットを分析することにより、ＡＰレイヤ内の情報から、性別や年齢、要求しているサービス等を割り出し、サービスの利用状況分析や、サービス拡充のための指針となるデータを得ることできる。
【００４４】
つまり、図８（ｂ）に示されているように、網内流通パケットから、性別・年齢・利用サービス等を検出する。つまり、網内流通パケットのＡＰレイヤを監視することにより、いつ・誰が・何のサービスで・何を要求しているのかを検出できる。よって、サービスの利用状況等が把握できるため、利用者の統計を取得することや、特定の年代・性別へのサービスを容易に拡充することができる。
【００４５】
一般に、携帯電話網等には、トラヒック制御監視を目的とした装置が設置されているが、これはＮＥ毎の呼処理の量等を測定するに留まっている。また、ＴＣＰ／ＩＰのレイヤ４（コネクションの確立を行う機能を具備するトランスポート層）までの監視であるために、その呼が具体的に何をしたいのかまでを検出することはできない。これに対し、本装置では、携帯電話網及びＩＰ網を流れるパケットの、ＡＰレイヤを監視・分析し、所定の処理を行うので、輻輳状況の把握や、サービス拡充や経営判断の材料となるデータを取得できる。
（パケット分析方法）
ところで、以上説明したパケット分析装置においては、図５に示されているようなパケット分析方法が実現されている。すなわち、同図に示されているように、網内を流れるパケットを取得するパケット取得ステップＳ１０１と、このパケット取得ステップＳ１０１において取得したパケットが準拠しているプロトコルを検出するプロトコル検出ステップＳ１０２と、このプロトコル検出ステップＳ１０２において検出したプロトコルに従って前記パケットの内容を分析する分析ステップＳ１０３と、この分析ステップＳ１０３の分析結果を蓄積しておき、これを参照して所定の処理を行うステップＳ１０４と、を含むパケット分析方法が実現されている。
【００４６】
このようなパケット分析方法によれば、パケットが準拠しているプロトコルを検出し、さらにパケットの内容を分析することにより、携帯電話網・ＩＰ網にて提供されるある特定のサービスのみについての輻輳状況が把握できる。また、携帯電話網・ＩＰにて提供されるサービスについて、どの年代や性別が多く利用しているか等、サービス拡充や経営判断の材料となるデータを取得できる。
（パケット分析プログラム）
また、図５に示されている動作を実現するためのパケット分析プログラムを用意し、これによってコンピュータを制御すれば、上述と同様にパケット分析を行うことができることは明白である。
【００４７】
このパケット分析プログラムを記録するための記録媒体には、図１等に示されていない半導体メモリ、磁気ディスク、光ディスク等の他、種々の記録媒体を用いることができる。このようなパケット分析プログラムを用いてコンピュータを制御すれば、パケットが準拠しているプロトコルを検出し、さらにパケットの内容を分析することができ、携帯電話網・ＩＰ網にて提供されるある特定のサービスのみについての輻輳状況が把握できる。また、携帯電話網・ＩＰにて提供されるサービスについて、どの年代や性別が多く利用しているか等、サービス拡充や経営判断の材料となるデータを取得できる。
【００４８】
【発明の効果】
以上説明したように本発明は、パケットが準拠しているプロトコルを検出し、さらにパケットの内容を分析することにより、携帯電話網・ＩＰ網にて提供されるある特定のサービスのみについての輻輳状況が把握できるという効果がある。例えば、Ｗｅｂ関連のサービスが輻輳状態である場合、Ｗｅｂ関連のどのサービスが輻輳しているのかを特定することができ、他のサービスに影響を与えずに特定サービスのみを遮断することができる。その結果、不必要な規制をかけることによる通信会社の利益減少が生じなくなる。
【００４９】
また、プロトコルを検出し、パケットの内容を分析することにより、携帯電話網・ＩＰにて提供されるサービスについて、どの年代や性別が多く利用しているか等、サービス拡充や経営判断の材料となるデータを取得できるという効果がある。このようなデータが取得できれば、特定の時間に、特定のユーザに対するサービス提供を効果的に実施することや、サービス毎の稼働率を判断して設備増設等の判断も可能となる。つまり、携帯電話網及びＩＰ網における通信を分析し、分析結果を各種窓口等のサービスフロント業務や、保守・建設・経営部門等へフィードバックさせ、網を流通しているデータそのものを経営資源とすることができる。
【図面の簡単な説明】
【図１】本発明によるパケット分析装置の実施の一形態を示すブロック図である。
【図２】パケット取得処理部の機能を示す図である。
【図３】ＯＳＩ参照モデルにおける各層の関係を示す図である。
【図４】パケット分析装置の動作を示す図である。
【図５】本発明によるパケット分析方法を示すフローチャートである。
【図６】（ａ）は第１従来例による問題点を説明するための図、（ｂ）はその問題点を解決できることを説明するための図である。
【図７】（ａ）は第２従来例による問題点を説明するための図、（ｂ）はその問題点を解決できることを説明するための図である。
【図８】（ａ）は第３従来例による問題点を説明するための図、（ｂ）はその問題点を解決できることを説明するための図である。
【符号の説明】
１ パケット分析装置
１１ パケット取得処理部
１２ プロトコル検出処理部
１３ パケット内分析処理部
１４ 分析結果蓄積処理部
１４ａ 統計データ

Claims (7)

1. 網内を流れるパケットを取得するパケット取得手段と、前記パケット取得手段によって取得したパケットが準拠しているプロトコルを検出するプロトコル検出手段と、前記プロトコル検出手段によって検出したプロトコルに従って前記パケットの内容を分析する分析手段と、前記分析手段の分析結果を参照して所定の処理を行う処理手段とを含むことを特徴とするパケット分析装置。
2. 前記処理手段は、前記分析結果に応じて前記網の輻輳制御処理を行うことを特徴とする請求項１記載のパケット分析装置。
3. 前記処理手段は、前記分析結果について統計処理を行うことを特徴とする請求項１記載のパケット分析装置。
4. 前記パケット取得手段は、前記網内を流れるパケット全てを、廃棄せずに取得し、それらパケットのヘッダに基づいて再構築したパケットについて前記プロトコル検出手段がプロトコルを検出することを特徴とする請求項１乃至３のいずれか１項に記載のパケット分析装置。
5. 前記分析手段は、前記プロトコル検出手段によって検出されたプロトコル毎にパケットの中身を分析することを特徴とする請求項１乃至４のいずれか１項に記載のパケット分析装置。
6. 網内を流れるパケットを取得するパケット取得ステップと、前記パケット取得ステップにおいて取得したパケットが準拠しているプロトコルを検出するプロトコル検出ステップと、前記プロトコル検出ステップにおいて検出したプロトコルに従って前記パケットの内容を分析する分析ステップと、前記分析ステップの分析結果を参照して所定の処理を行う処理ステップとを含むことを特徴とするパケット分析方法。
7. 網内を流れるパケットを取得するパケット取得ステップと、前記パケット取得ステップにおいて取得したパケットが準拠しているプロトコルを検出するプロトコル検出ステップと、前記プロトコル検出ステップにおいて検出したプロトコルに従って前記パケットの内容を分析する分析ステップと、前記分析ステップの分析結果を参照して所定の処理を行う処理ステップとを含むことを特徴とするパケット分析プログラム。

Images