JP6036449B2 - 情報処理装置、情報処理方法、情報処理プログラム、及び情報処理システム - Google Patents

Description

本発明は、ネットワーク監視を行うための情報処理装置，情報処理方法，情報処理プログラム，及び情報処理システムに関する。

図１は、無線通信ネットワークシステムの構成例を示す図である。図１に示される無線通信ネットワークシステム５００は、移動端末の通信ためのネットワークである。無線通信ネットワークシステム５００は、無線ネットワーク５１０，無線アクセスネットワーク５２０，パケット交換コアネットワーク５３０を含む。移動端末（User Equipment）１０は、無線ネットワーク５１０内に存在する。無線ネットワーク５１０と無線アクセスネットワーク５２０との境界に、無線基地局（Base Transceiver Station）２０が存在する。無線基地局２０の上位に無線ネットワーク制御装置（Radio Network Controller）３０が存在する。無線アクセスネットワーク５２０の上位にはパケット交換コアネットワーク５３０が存在し、パケット交換コアネットワーク５３０には、複数の加入者パケット交換機４０と複数の中継パケット交換機５０が存在する。パケット交換コアネットワークには、インターネットやアプリケーションサーバ８０が接続される。

移動端末１０がインターネットやアプリケーションサーバ８０に接続する場合には、無線基地局２０，無線ネットワーク制御装置３０，加入者パケット交換機４０，中継パケット交換機５０を経由する。このとき、無線ネットワーク制御装置３０と中継パケット交換機５０との間でトンネルが形成され、移動端末１０とインターネット及びアプリケーションサーバ８０間のデータ転送では、該トンネルが用いられる。該トンネルを形成するトンネリングプロトコルには、例えば、ＧＴＰ（GPRS(General Packet Radio Service) Tunneling Protocol）がある。また、無線ネットワーク制御装置３０と中継パケット交換機５
０との間で形成されるトンネルには、例えば、ＧＴＰ-Ｕ（GTP for User plane）トンネ
ルがある。ＧＴＰ−Ｕトンネルは、ユーザ毎に形成される。

図２は、無線通信ネットワークにおける制御プレーン及びユーザプレーンのパケットの一例を示す図である。図２では、図１に示される無線通信ネットワークシステム５００のうち、無線ネットワーク制御装置３０とＷｅｂサービスゲートウェイ７０との間の部分が抽出されて示されている。なお、図２では、制御プレーンはＣ−Ｐｌａｎｅ、ユーザプレーンはＵ−Ｐｌａｎｅと表記されている。

ＧＴＰの制御プレーン制御用のプロトコルはＧＴＰ−Ｃ(GTP for Control plane)プロ
トコル、ユーザプレーン制御用のプロトコルはＧＴＰ−Ｕプロトコルである。ＧＴＰが用いられるネットワークでは、制御プレーンにおいて、ＧＴＰ−Ｃによるトンネル開設のための制御信号が、加入者パケット交換機４０と中継パケット交換機５０との間でやりとりされる。その結果、ユーザプレーンにおいて、ＧＴＰ−Ｕによるトンネルが開設される。

制御プレーンでは、加入者パケット交換機４０と中継パケット交換機５０との間では、ＧＴＰ−Ｃの制御パケットがやり取りされ、ＧＴＰ−Ｕのトンネル開設のための情報がやりとりされる。また、制御プレーンの加入者パケット交換機４０と無線ネットワーク制御装置３０との間では、例えば、ＲＡＮＡＰ（Radio Access Network Application Part）
によって制御パケットがやり取りされ、ＧＴＰ−Ｕのトンネル開設のための情報がやりとりされる。

データプレーンのＧＴＰ−Ｕトンネル内では、すなわち、無線ネットワーク制御装置３０と中継パケット交換機５０との間では、ＨＴＴＰ（Hypertext Transfer Protocol）等
の各種アプリケーションのユーザデータは、ＧＴＰ−Ｕによってカプセル化されて転送される。１つのＧＴＰ−Ｕトンネルには、１つの移動端末１０のユーザデータが流れる。また、１つのＧＴＰ−Ｕトンネル内には、１つの移動端末１０の複数のアプリケーションのデータが流れる。ユ−ザデータはユーザパケットともいう。

トンネルの両端に位置するネットワーク装置では、トンネル開設のための準備処理及び制御パケットの待ちうけ・メッセージのタイムアウト監視処理やカプセル化の処理の負荷がかかる。また、トンネルが開設されると、トンネル維持及び管理のために、制御プレーンにおいてネットワーク装置間で制御パケットがやり取りされ、トンネル維持のためユーザデータの通信が無い時でも帯域が消費される。したがって、トンネルの開設及び維持の処理は、ネットワーク装置にとって負荷の高い処理の一つである。

ＧＴＰ−Ｕトンネルは、帯域節約のため、ユーザデータの通信が所定時間行われずにタイムアウトすると削除されるように、ネットワーク管理者によって設定されることが多い。一方、移動端末１０の一例であるスマートフォンで用いられるアプリケーションには、例えば、バックグランドで起動し、所定の周期で通信を行うようなアプリケーションがある。例えば、該アプリケーションの通信間隔が、トンネルの削除タイマよりも短い場合には、トンネルは該アプリケーションの起動中は維持され続けることになる。また、例えば、該アプリケーションの通信間隔がトンネルの削除タイマよりも長い場合には、該アプリケーションの通信間隔でトンネルが開設されることになり、トンネルの開設が頻発するおそれがある。

したがって、所定の周期で通信を行うようなアプリケーションによる通信が、ネットワークの負荷要因の一つになっていることがある。安定したネットワーク保守のために、トンネル開設の要因となるアプリケーションを特定し、アプリケーション単位で負荷状況を把握することが所望される。

特開平７−２３１３１７号公報 特開２００２−２６１７９９号公報

しかしながら、アプリケーション単位で負荷状況を把握するためには、以下のような問題がある。

キャリアのネットワーク内では、安定したネットワーク保守のために、ネットワークの監視が行われる。ネットワークの監視は、例えば、トラフィックを監視したい所定の位置に、ＴＡＰ(Test Access Point)と呼ばれる信号分岐装置を配置し、ネットワークプロー
ブで分岐信号を解析することによって行われる。

トンネルの開設及び維持に係る負荷を把握する場合には、例えば、加入者パケット交換機４０と中継パケット交換機５０との間（図１のポイントＰ１）の、トンネル経路上のいずれかの位置に、ＴＡＰが配置される。

図３はＧＴＰ−Ｃのヘッダ部に含まれるフィールドと各フィールドに配される情報とを示す図である。図４は、回線接続要求時のＧＴＰ−Ｃのペイロード部に含まれるフィール
ドと各フィールドに配される情報とを示す図である。図５は、回線接続応答時のＧＴＰ−Ｃのペイロード部に含まれるフィールドと各フィールドに配される情報とを示す図である。図６は、ＧＴＰ−Ｕのヘッダ部に含まれるフィールドと各フィールドに配される情報とを示す図である。

例えば、図１に示されるポイントＰ１においてキャプチャされるＧＴＰパケットは、図３−図６のいずれかに示される情報を有する。図３−図６に示されるように、ＧＴＰ−Ｃプロトコル及びＧＴＰ−Ｕプロトコルの情報には、いずれにも、アプリケーションを特定可能な情報が含まれていない。一方、ＧＴＰ−Ｕプロトコルでカプセル化されているユーザデータから、アプリケーションを特定することは、逆カプセル化を実施することにより可能である。しかしながら、ＧＴＰ−Ｕトンネルは同一移動端末１０の複数のアプリケーションによって共有されているので、いずれのアプリケーションがトンネル開設要因となったかを特定することができない。したがって、ＧＴＰ−Ｕトンネル内を通過するＧＴＰ−Ｃ及びＧＴＰ−Ｕのパケットから、トンネルの開設要因となるアプリケーションを特定することはできない。

また、例えば、図２に示されるポイントＰ２のように、ＧＴＰ−Ｕトンネル外でパケットがキャプチャされる場合には、パケットにＧＴＰの情報が付与されていない。そのため、キャプチャされたパケットからアプリケーションを特定できても、該アプリケーションがトンネル開設の要因となるアプリケーションであるか否かを判定することができない。

したがって、トンネルの開設要因となるアプリケーションを特定できないことによって、ネットワークの負荷要因となるアプリケーション単位の制御信号の負荷を適切に予測することができない。結果、設計時に想定された負荷を上回る負荷が発生した場合に通信障害が発生する可能性がある。

本発明の一態様は、トンネルの開設要因となるアプリケーションを特定可能な情報処理装置，情報処理方法，情報処理プログラム，及び情報処理システムを提供することを目的とする。

本発明の態様の一つは、
プロセッサと、メモリとを備え、
ネットワーク内の所定の位置において、前記ネットワークを流れるパケットをキャプチャする情報処理装置であって、
前記プロセッサは、
前記キャプチャしたパケットが、所定のトンネリングプロトコルによるトンネルに最初に流れたユーザパケットであるか否かを判定し、
前記キャプチャしたパケットが前記トンネルに最初に流れたユーザパケットである場合に、前記キャプチャしたパケットから、前記トンネルの開設要因であるアプリケーションを識別する、
情報処理装置である。

本発明の他の態様の一つは、上述した情報処理装置が上述した処理を実行する情報処理方法である。また、本発明の他の態様は、コンピュータを上述した情報処理装置として機能させるプログラム、及び当該プログラムを記録したコンピュータ読み取り可能な記録媒体を含むことができる。コンピュータ等が読み取り可能な記録媒体には、データやプログラム等の情報を電気的、磁気的、光学的、機械的、または化学的作用によって蓄積し、コンピュータ等から読み取ることができる記録媒体をいう。

開示の情報処理装置，情報処理方法，情報処理プログラム，及び情報処理システムによれば、トンネルの開設要因となるアプリケーションを特定することができる。

無線通信ネットワークシステムの構成例を示す図である。 無線通信ネットワークにおける制御プレーン及びユーザプレーンのパケットの一例を示す図である。 ＧＴＰ−Ｃのヘッダ部に含まれるフィールドと各フィールドに配される情報とを示す図である。 回線接続要求時のＧＴＰ−Ｃのペイロード部に含まれるフィールドと各フィールドに配される情報とを示す図である。 回線接続応答時のＧＴＰ−Ｃのペイロード部に含まれるフィールドと各フィールドに配される情報とを示す図である。 ＧＴＰ−Ｕのヘッダ部に含まれるフィールドと各フィールドに配される情報とを示す図である。 第１実施形態におけるトンネル開設要因となるアプリケーションを特定する方法の説明のための図である。 ＧＴＰ−Ｕトンネル確立までのシーケンスの一例を示す図である。 品質監視システムの構成例を示す図である。 プローブ装置のハードウェア構成の一例を示す図である。 第１実施形態におけるプローブ装置の機能ブロックの一例を示す図である。 アプリケーション識別対象外パケットの識別手段と、具体例とを示す図である。 内部保持テーブルの一例の初期状態を示す図である。 プローブ装置が、発信側の装置Ａから着信側の装置Ｂに宛てられたトンネルの開設要求であるＣＲＥＡＴＥ ＰＤＰ ＣＯＮＴＥＸＴ ＲＥＱＵＥＳＴメッセージをキャプチャした後の、情報が格納された内部保持テーブルの一例である。 プローブ装置が、着信側の装置Ｂから発信側の装置Ａに宛てられたトンネルの開設要求に対する応答であるＣＲＥＡＴＥ ＰＤＰ ＣＯＮＴＥＸＴ ＲＥＳＰＯＮＳＥメッセージをキャプチャした後の、情報が格納された内部保持テーブルの一例である。 トンネルを流れるパケットが検出された後の内部保持テーブルの一例である。 アプリケーション識別情報の一例を示す図である。 アプリケーション識別部によって生成される情報の一例を示す図である。 周期集計部によって生成される品質データの一例を示す図である。 第１実施形態におけるプローブ装置のパケット解析処理のフローチャートの一例である。 第１実施形態におけるプローブ装置のパケット解析処理のフローチャートの一例である。 周期的に行われるパケットの情報の集計処理のフローチャートの一例である。 マネージャ装置の機能ブロックの一例を示す図である。 マネージャ装置の情報集計処理のフローチャートの一例である。 品質情報又はアラーム情報の表示処理のフローチャートの一例を示す図である。 品質情報の表示例の一つである。 品質情報の表示例の一つである。 品質情報の表示例の一つである。 品質情報の表示例の一つである。 第２実施形態のトンネル開設要因となるアプリケーションを特定する方法について説明するための図である。 第２実施形態におけるプローブ装置のパケット解析処理のフローチャートの一例である。

以下、図面に基づいて、本発明の実施の形態を説明する。以下の実施形態の構成は例示であり、本発明は実施形態の構成に限定されない。

＜第１実施形態＞
図７は、第１実施形態におけるトンネル開設要因となるアプリケーションを特定する方法の説明のための図である。ＧＴＰ−Ｕトンネルが確立された直後にＧＴＰ−Ｕトンネルを流れるパケット群は、該ＧＴＰ−Ｕトンネルの開設要因であるアプリケーションによって送出されたパケット群である可能性が高い。例えば、図７に示される例において、ＧＴＰ−Ｕトンネルが開設されてから、アプリケーション１、アプリケーション２の順でＧＴＰ−Ｕトンネルをパケット群が流れた場合には、アプリケーション１がトンネルの開設要因となるアプリケーションであると考えられる。

従って、第１実施形態では、ＧＴＰ−Ｕトンネルの開設直後に該ＧＴＰ−Ｕトンネルを流れるパケット群を送出したアプリケーションが、該ＧＴＰ−Ｕトンネルの開設要因のアプリケーションとして特定される。ＧＴＰ−Ｕトンネルの開設要因のアプリケーションを特定するために、まず、第１実施形態では、ＧＴＰ−Ｕトンネルの開設が検出される。

図８は、ＧＴＰ−Ｕトンネル確立までのシーケンスの一例を示す図である。図８では、図１に示される無線通信ネットワークシステム５００のうち、移動端末１０，加入者パケット交換機４０，中継パケット交換機５０が抽出されて示されている。

ＯＰ１では、移動端末１０が回線接続要求を送信する。ＯＰ２では、加入者パケット交換機４０は、移動端末１０からの回線接続要求を受信し、該回線接続要求に応じたＧＴＰ−Ｕトンネルを開設するために、トンネルの終端となる中継パケット交換機５０に、トンネル開設を要求するＧＴＰ−Ｃメッセージを送信する。このとき送信されるＧＴＰ−Ｃメッセージは“ＣＲＥＡＴＥ ＰＤＰ ＣＯＮＴＥＸＴ ＲＥＱＵＥＳＴ”である。

ＯＰ３では、ＧＴＰ−Ｕトンネルの終端となる中継パケット交換機５０がトンネル開設を要求するＧＴＰ−Ｃメッセージを受信し、この要求に対する応答のＧＴＰ−Ｃメッセージを加入者パケット交換機４０に送信する。ＯＰ２，ＯＰ３のＧＴＰ−Ｃメッセージの交換によって、トンネルの識別情報であるＴＥＩＤ（Tunnel Endpoint IDentifier）が決定され、トンネルが開設される。

ＯＰ４では、トンネルが開設されたので、加入者パケット交換機４０は、回線接続応答を移動端末１０に送信する。これ以降、移動端末１０は、ＧＴＰ−Ｕトンネルを通じて、通信を行うことができる。

第１実施形態では、加入者パケット交換機４０と中継パケット交換機５０との間のＧＴＰ−Ｕトンネルの経路上にパケットのキャプチャポイントを想定する。図８のＯＰ３においてＧＴＰ−Ｕトンネルが開設されるので、第１実施形態では、ＧＴＰ−ＣプロトコルのＣＲＥＡＴＥ ＰＤＰ ＣＯＭＴＥＸＴ ＲＥＳＰＯＰＮＳＥメッセージを検出することによって、ＧＴＰ−Ｕトンネルの開設が検出される。

＜品質監視システムの構成＞
図９は、品質監視システムの構成例を示す図である。第１実施形態では、ＴＡＰ ３は、ＧＴＰ−Ｕトンネルの経路上の、パケット交換コアネットワーク５３０に含まれるＩＰ（Internet Protocol）ルータ網のエッジルータと加入者パケット交換機４０又は中継パ
ケット交換機５０との間に、それぞれ配置される。

品質監視システム１００は、例えば、図１に示されるパケット交換コアネットワーク５３０内のトラフィックを監視し、統計情報を収集して、ネットワークの品質を管理するためのシステムである。品質監視システム１００は、複数のプローブ装置１と、マネージャ装置２とを含む。各プローブ装置１とマネージャ装置２とは、ＬＡＮ（Local Area Network）等のネットワークを介して接続される。

複数のプローブ装置１は、それぞれ、パケット交換コアネットワーク５３０内の所定の位置に配置された複数のＴＡＰ ３のそれぞれに接続しており、ＴＡＰ ３によって分岐されたパケットをキャプチャする。プローブ装置１は、キャプチャしたパケットを解析し、所定の周期で解析結果の集計をマネージャ装置２に送信する。

マネージャ装置２は、各プローブ装置１からパケットの解析結果を収集し、パケット交換コアネットワーク５３０全体の統計処理を行う。統計処理の結果、マネージャ装置２は、アラームや統計結果を、表示装置等を通じて、出力する。

＜プローブ装置の構成＞
図１０は、プローブ装置１のハードウェア構成の一例を示す図である。プローブ装置１は、例えば、プローブ装置としての専用のコンピュータ，汎用のコンピュータである。プローブ装置１は、プロセッサ１０１，主記憶装置１０２，入力装置１０３，出力装置１０４，補助記憶装置１０５，可搬記録媒体駆動装置１０６，ネットワークインタフェース１０７を備える。また、これらはバス１０９により互いに接続されている。

入力装置１０３は、例えば、キーボード，マウス等のポインティングデバイス等である。入力装置１０３から入力されたデータは、プロセッサ１０１に出力される。

可搬記録媒体駆動装置１０６は、可搬記録媒体１１０に記録されるプログラムや各種データを読出し、プロセッサ１０１に出力する。可搬記録媒体１１０は、例えば、ＳＤカード，ｍｉｎｉＳＤカード，ｍｉｃｒｏＳＤカード，ＵＳＢ（Universal Serial Bus）フラッシュメモリ，ＣＤ（Compact Disc），ＤＶＤ(Digital Versatile Disc)，Ｂｌｕ−ｒａｙディスク，又はフラッシュメモリカードのような記録媒体である。

ネットワークインタフェース１０７は、ネットワークとの情報の入出力を行うインタフェースである。ネットワークインタフェース１０７は、有線のネットワーク、および、無線のネットワークと接続する。プローブ装置１は、例えば、ネットワークインタフェース１０７を通じて、マネージャ装置２と通信する。ネットワークインタフェース１０７は、例えば、ＮＩＣ（Network Interface Card），無線ＬＡＮカード等である。ネットワークインタフェース１０７で受信されたデータ等は、プロセッサ１０１に出力される。なお、第１実施形態では、ネットワークインタフェース１０７は複数備えられ、そのうちの一つ、または複数は、ＴＡＰ ３との接続のためのインタフェースとしても使用される。

補助記憶装置１０５は、様々なプログラムや、各プログラムの実行に際してプロセッサ１０１が使用するデータを格納する。補助記憶装置１０５は、例えば、ＥＰＲＯＭ（Erasable Programmable ROM）、又はハードディスクドライブ（Hard Disc Drive）等の不揮発
性のメモリである。補助記憶装置１０５は、例えば、オペレーティングシステム（ＯＳ），ネットワーク監視プログラム，その他様々なアプリケーションプログラムを保持する。

主記憶装置１０２は、プロセッサ１０１に、補助記憶装置１０５に格納されているプログラムをロードする記憶領域および作業領域を提供したり、バッファとして用いられたりする。主記憶装置１０２は、例えば、ＲＡＭ（Random Access Memory），ＲＯＭ（Read Only Memory）のような半導体メモリである。

プロセッサ１０１は、例えば、ＣＰＵ（Central Processing Unit）である。プロセッ
サ１０１は、補助記憶装置１０５又は可搬記録媒体１１０に保持されたＯＳや様々なアプリケーションプログラムを主記憶装置１０２にロードして実行することによって、様々な処理を実行する。プロセッサ１０１は、１つに限られず、複数備えられてもよい。

出力装置１０４は、プロセッサ１０１の処理の結果を出力する。出力装置１０４は、例えば、スピーカ等の音声出力装置，ディスプレイ，プリンタを含む。

例えば、プローブ装置１は、プロセッサ１０１が補助記憶装置１０５に保持されるネットワーク監視プログラムを主記憶装置１０２にロードして実行する。プローブ装置１は、ネットワーク監視プログラムの実行を通じて、ＴＡＰ ３によって分岐されたパケットを解析することによって、ＧＴＰ−Ｕトンネルの開設を検出し、該ＧＴＰ−Ｕトンネルの開設直後に流れるパケット群を送出したアプリケーションを特定する。なお、プローブ装置１のハードウェア構成は、一例であり、上記に限られず、実施の形態に応じて適宜構成要素の省略や置換、追加が可能である。ネットワーク監視プログラムは、例えば、可搬記録媒体１１０に記録されていてもよい。プローブ装置１は、「情報処理装置」の一例である。ネットワーク監視プログラムは、「情報処理プログラム」の一例である。なお、マネージャ装置２のハードウェア構成も、図１０に示されるものと同様である。

図１１は、第１実施形態におけるプローブ装置１の機能ブロックの一例を示す図である。プローブ装置１は、例えば、プロセッサ１０１が補助記憶装置１０５に格納されるネットワーク監視プログラムを実行することによって、プロトコル解析部１１，ＩＰ集計部１２，アプリケーション識別部１３，周期集計部１４，マネージャインタフェース１５として動作する。なお、プローブ装置１の各機能ブロックは、プロセッサ１０１のソフトウェア処理によって実現されることに限られず、ハードウェアによって実現されてもよい。例えば、プローブ装置１の各機能ブロックを実現するハードウェアには、ＬＳＩ（Large Scale Integration），ＦＰＧＡ（Field-Programmable Gate Array）等がある。

プロトコル解析部１１は、ＴＡＰ ３によって分岐されたパケットのヘッダを解析し、パケットがいずれのプロトコルのパケットであるかを判定し、各プロトコルについてパケットの集計を行い、プロトコル情報を取得する。より具体的には、プロトコル解析部１１は、ＴＡＰ ３によって分岐されたパケットの中から、ＧＴＰパケットを検出する。プロトコル解析部１１は、例えば、ＩＰヘッダ内のプロトコル番号，ＵＤＰ又はＴＣＰヘッダ内のポート番号，ＧＴＰヘッダ内の各フィールドの情報によって、プロトコルを判定する。ＧＴＰプロトコルは、例えば、ＩＰヘッダ内のプロトコル番号がＵＤＰ（User Datagram Protocol）の１７，ＵＤＰヘッダ内の宛先または送信元ポート番号が３３８６であることによって判定される。また、ＧＴＰ−ＣプロトコルとＧＴＰ−Ｕプロトコルとの判別は、ＧＴＰヘッダ内のＰｒｏｔｏｃｏｌ Ｔｙｐｅフィールドの値によって識別される（図３、図６参照）。ＧＴＰ−Ｃプロトコルのメッセージは、ＧＴＰヘッダ内のＭｅｓｓａｇｅ Ｔｙｐｅフィールドによって判別される。

プロトコル解析部１１は、ＧＴＰ−ＣのＣＲＥＡＴＥ ＰＤＰ ＣＯＮＴＥＸＴ ＲＥ
ＱＵＥＳＴメッセージ、又は、ＣＲＥＡＴＥ ＰＤＰ ＣＯＮＴＥＸＴ ＲＥＳＰＯＮＳＥメッセージを検出した場合に、該メッセージによって開設されるＧＴＰ−Ｕトンネル情報を内部保持テーブル１７に記録する。内部保持テーブル１７への情報の記録については、後述する。

また、プロトコル解析部１１は、ＧＴＰ−Ｕパケットを検出した場合には、内部保持テーブル１７の情報を用いて、該ＧＴＰ−Ｕパケットが流れるＧＴＰ−Ｕトンネルを特定する。プロトコル解析部１１は、各ＧＴＰ-Ｕトンネルについて、トンネル開設以降トンネ
ルを流れるＧＴＰ−Ｕパケットの順番をカウントし、各ＧＴＰ−Ｕパケットに到着順カウントとして付与する。なお、到着順カウントは、各トンネルにおいて、それぞれ連続した番号でなくてもよく、到着順に大きい番号が付与されるのであれば連続していなくてもよい。例えば、到着順カウントは、プローブ装置１に入力されたパケットの通し番号であってもよい。

ＩＰ集計部１２は、プロトコル解析部１１によって解析された情報から、ＩＰ情報を抽出し、ＩＰ情報に基づく集計を行う。より具体的には、例えば、ＩＰ集計部１２は、ＩＰ情報として各パケットの宛先ＩＰアドレス，送信元ＩＰアドレス，宛先ＩＰアドレスと送信元ＩＰアドレスとの組み合わせ，等について、それぞれパケットを集計する。

アプリケーション識別部１３は、プロトコル解析部１１によって検出されたＧＴＰ−Ｕパケットから、ＧＴＰ−Ｃトンネルの開設要因であるアプリケーションを識別する。アプリケーション識別部１３は、プロトコル解析部１１によって各ＧＴＰ−Ｕパケットに付与されたトンネルでの到着順カウントを参照し、到着順カウントが最小のＧＴＰ−Ｕパケットについてアプリケーションの識別を行う。アプリケーション識別部１３は、到着順カウントが最小のＧＴＰ−Ｕパケットを、ＧＴＰ−Ｕトンネルの開設直後に流れたパケットであるとして取り扱うためである。

アプリケーション識別部１３は、例えば、到着順カウントが最小のＧＴＰ−Ｕパケットを逆カプセル化して、ユーザパケットを抽出する。アプリケーション識別部１３は、抽出したユーザパケットの情報と、アプリケーション識別情報１６に定義された情報と、を比較し、到着順カウントが最小のＧＴＰ−Ｕパケットを送出したアプリケーションを特定する。また、アプリケーション識別部１３は、特定したアプリケーションを含む、到着順カウントが最小のＧＴＰ−Ｕパケットの情報を周期集計部１４に通知する。

ただし、ＧＴＰ−Ｕトンネルの開設直後に流れるＧＴＰ−Ｕパケットの中には、アプリケーションの特定困難なものもある。例えば、ＨＴＴＰ（Hypertext Transfer Protocol
）のようにアプリケーションが通信先のＩＰアドレスを取得するために、アプリケーション通信に先立って名前解決が行われる場合の、複数のアプリケーションで共通して利用されるＤＮＳサーバ向けの名前解決パケットがある。また、例えば、同一のアプリケーションベンダによって提供される複数のアプリケーションがユーザ認証等の用途で同一の通信先のＩＰアドレスを用いる場合の、アプリケーションに先立って行われるユーザ認証等のパケットがある。上記のような、該アプリケーション識別困難なパケットについて、アプリケーション識別部１３は、アプリケーション識別の対象から除外する。

図１２は、アプリケーション識別対象外パケットの識別手段と、具体例とを示す図である。なお、図１２に示されるアプリケーション識別対象外パケットは、一例であって、これに限られない。

例えば、アプリケーション識別対象外パケットの識別手段には、１）プロトコル又はポート番号，２）事前に保持されたＩＰアドレス，サブネットアドレス，ＵＲＬ（Uniform
Resource Locator），３）トンネル開設からの経過時間，４）ＡＰＮ（Access Pont Name）識別情報，ベアラ種別識別情報，５）パケットサイズ等がある。いずれの識別手段の場合にも、事前に、アプリケーション識別対象外パケットの条件が、例えば、主記憶装置１０２の記憶領域に保持される。アプリケーション識別部１３は、最小の到着順カウントを有するＧＴＰ−Ｕパケットの情報と、該条件とを比較し、該条件に合致した場合には、該ＧＴＰ−Ｕパケットをアプリケーション識別の対象から除外する。なお、この場合には、アプリケーション識別部１３は、同じＧＴＰ−Ｕトンネルを流れる、到着順カウントが次に小さいパケットについて、アプリケーション識別の対象か否かを判定し、アプリケーション識別の対象である場合に該パケットについてアプリケーション識別を行う。

周期集計部１４は、所定の周期で、ＩＰ集計部１２、アプリケーション識別部１３からの情報を集約し、品質データを生成する。品質データを生成する所定の周期は、例えば、１分である。周期集計部１４が生成する品質データは、例えば、各アプリケーションについての１周期の間のトンネルの使用状況に関する情報であり、１周期間のアプリケーション毎のトンネル開設発生回数も含まれる。マネージャＩＦ １５は、マネージャ装置２とインタフェースである。周期集計部１４は、生成した品質データを、マネージャＩＦ １５を通じてマネージャ装置２に送信する。

＜プローブ装置で取り扱われる情報＞
（内部保持テーブル）
図１３Ａ，図１３Ｂ，図１３Ｃ，図１３Ｄは、それぞれ、内部保持テーブル１７の一例を示す図である。ＧＴＰ−Ｕトンネルは、接続先やアプリケーション等によってトンネルの両端に位置する装置が異なる。また、ＧＴＰ−Ｕトンネルは、トンネルの両端に位置する各装置において、ＴＥＩＤによって識別される。したがって、ＧＴＰ−Ｕパケットから、ＧＴＰ−Ｕトンネルを特定するためには、ＧＴＰ−Ｕトンネルの両端の各装置が使用するＴＥＩＤと、各装置のＩＰアドレスと、が用いられる。内部保持テーブル１７は、ＧＴＰ−ＵパケットからＧＴＰ−Ｕトンネルを特定するためのこれらの情報を格納する。内部保持テーブル１７は、例えば、主記憶装置１０２の記憶領域に生成される。

図１３Ａは、内部保持テーブルの一例の初期状態を示す図である。第１実施形態では、内部保持テーブル１７は、内部管理ＩＤ，ベアラ識別情報部，ベアラ状態情報部を含む。なお、ベアラとは、第１実施形態において、ＧＴＰ−Ｕトンネルを指す。内部管理ＩＤは、プローブ装置１内でＧＴＰ−Ｕトンネルを識別するための情報である。

ベアラ識別情報部は、トンネルの識別に用いられる情報を保持する。ベアラ識別情報部に保持される情報は、ＴＥＩＤとＩＰアドレスとに分けられる。ＴＥＩＤ、ＩＰアドレスのいずれについても、ＧＴＰ−ＣプロトコルとＧＴＰ−Ｕプロトコルとのそれぞれについて、発信側と着信側のものが格納される。図１３Ａ−図１３Ｄは、同じ内部保持テーブル１７を示し、ＧＴＰ−Ｃプロトコルの情報は「Ｃ側」、ＧＴＰ−Ｕプロトコルの情報は「Ｕ側」と表記されている。また、発信側の情報は「（発）」、着信側の情報は「（着）」と表記されている。すなわち、図１３Ａ―図１３Ｄに示される内部保持テーブル１７は、ベアラ識別情報部に、“Ｃ側ＴＥＩＤ（発）”，“Ｃ側ＴＥＩＤ（着）”、“Ｕ側ＴＥＩＤ（発）”、“Ｕ側ＴＥＩＤ（着）”、“Ｃ側ＩＰアドレス（発）”、“Ｃ側ＩＰアドレス（着）”、“Ｕ側ＩＰアドレス（発）”、“Ｕ側ＩＰアドレス（着）”の項目を含む。

ベアラ状態情報部には、トンネルの状態に関する情報が保持される。図１３Ａに示される例では、ベアラ状態情報部には、開設時刻とベアラ状態とが含まれる。内部保持テーブル１７は、初期状態では、いずれの項目も空の状態である。

以降、図１３Ｂ−図１３Ｄを用いて、内部保持テーブル１７の情報の取得について説明
する。図１３Ｂ−図１３Ｄでは、発信側の装置Ａ，着信側の装置Ｂとの間でトンネルが開設される場合について、説明する。例えば、発信側の装置Ａは、図２における加入者パケット交換機４０である。例えば、着信側の装置Ｂは、図２における中継パケット交換機５０である。

図１３Ｂには、プローブ装置１が、発信側の装置Ａから着信側の装置Ｂに宛てられたトンネルの開設要求であるＣＲＥＡＴＥ ＰＤＰ ＣＯＮＴＥＸＴ ＲＥＱＵＥＳＴメッセージをキャプチャした後の、情報が格納された内部保持テーブルの一例が示される。ＣＲＥＡＴＥ ＰＤＰ ＣＯＮＴＥＸＴ ＲＥＱＵＥＳＴメッセージは、プロトコル解析部１１によって検出される。プロトコル解析部１１は、このＣＲＥＡＴＥ ＰＤＰ ＣＯＮＴＥＸＴ ＲＥＱＵＥＳＴメッセージの送信元の情報を、内部保持テーブル１７における発信側の装置の情報として取り扱う。

プロトコル解析部１１は、ＣＲＥＡＴＥ ＰＤＰ ＣＯＮＴＥＸＴ ＲＥＱＵＥＳＴメッセージのペイロード部の情報（図４参照）から、内部保持テーブル１７の“Ｃ側ＴＥＩＤ（発）”，“Ｕ側ＴＥＩＤ（発）”，“Ｃ側ＩＰアドレス（発）”，“Ｕ側ＩＰアドレス（発）”を取得する。“Ｃ側ＴＥＩＤ（発）”，“Ｕ側ＴＥＩＤ（発）”，“Ｃ側ＩＰアドレス（発）”，“Ｕ側ＩＰアドレス（発）”は、それぞれ、ＣＲＥＡＴＥ ＰＤＰ ＣＯＮＴＥＸＴ ＲＥＱＵＥＳＴメッセージのペイロード部の、ＴＥＩＤ ｃｏｎｔｒｏｌ ｐｌａｎｅ，ＴＥＩＤ Ｄａｔａ Ｉ，ＳＧＳＮ Ａｄｄｒｅｓｓ ｆｏｒ ｓｉｇｎａｌｌｉｎｇ，ＳＧＳＮ Ａｄｄｒｅｓｓ ｆｏｒ ｕｓｅｒ ｔｒａｆｆｉｃの値である（図４参照）。

さらに、プロトコル解析部１１は、ＣＲＥＡＴＥ ＰＤＰ ＣＯＮＴＥＸＴ ＲＥＱＵＥＳＴメッセージを受信した時刻を、内部保持テーブル１７の“開設時刻”に格納する。“開設時刻”に格納される時刻は、例えば、プローブ装置１の内部時計の値であり、ネットワークインタフェース１０７においてＴＡＰ ３から分岐されたパケットを受信した際に付与される。また、プロトコル解析部１１は、内部保持テーブル１７の“ベアラ状態”に、“開設要求中”を格納する。

内部保持テーブル１７の内部管理ＩＤは、プロトコル解析部１１によって、例えば、１から順に、内部保持テーブル１７に格納される順に付与される。ただし、これに限られず、内部管理ＩＤは、他のエントリと重複しなければ、どのように付与されてもよい。

図１３Ｃには、プローブ装置１が、着信側の装置Ｂから発信側の装置Ａに宛てられたトンネルの開設要求に対する応答であるＣＲＥＡＴＥ ＰＤＰ ＣＯＮＴＥＸＴ ＲＥＳＰＯＮＳＥメッセージをキャプチャした後の、情報が格納された内部保持テーブルの一例が示される。ＣＲＥＡＴＥ ＰＤＰ ＣＯＮＴＥＸＴ ＲＥＳＰＯＮＳＥメッセージは、プロトコル解析部１１によって検出される。

なお、ＣＲＥＡＴＥ ＰＤＰ ＣＯＮＴＥＸＴ ＲＥＳＰＯＮＳＥメッセージが、図１３ＢにおけるＣＲＥＡＴＥ ＰＤＰ ＣＯＮＴＥＸＴ ＲＥＱＵＥＳＴメッセージの応答であることを、例えば、プロトコル解析部１１は、ＩＰヘッダの宛先ＩＰアドレス、ＧＴＰ−Ｃヘッダ内のＴＥＩＤが、内部保持テーブル１７の“Ｃ側ＩＰアドレス”（発），“Ｃ側ＴＥＩＤ（発）”に合致することによって判定する。また、この判定の際には、ＣＲＥＡＴＥ ＰＤＰ ＣＯＮＴＥＸＴ ＲＥＳＰＯＮＳＥメッセージと、ＣＲＥＡＴＥ ＰＤＰ ＣＯＮＴＥＸＴ ＲＥＱＵＥＳＴメッセージとの、ＧＴＰ−Ｃヘッダ内のＳｅｑｕｅｎｃｅ Ｎｕｍｂｅｒが共通していることによっても判定される（図３参照）。

プロトコル解析部１１は、ＣＲＥＡＴＥ ＰＤＰ ＣＯＮＴＥＸＴ ＲＥＳＰＯＮＳＥ
メッセージのペイロード部の情報から、内部保持テーブル１７の“Ｃ側ＴＥＩＤ（着）”，“Ｕ側ＴＥＩＤ（着）”，“Ｃ側ＩＰアドレス（着）”，“Ｕ側ＩＰアドレス（着）”を取得する。“Ｃ側ＴＥＩＤ（着）”，“Ｕ側ＴＥＩＤ（着）”，“Ｃ側ＩＰアドレス（着）”，“Ｕ側ＩＰアドレス（着）”は、それぞれ、ＣＲＥＡＴＥ ＰＤＰ ＣＯＮＴＥＸＴ ＲＥＳＰＯＮＳＥメッセージのペイロード部の、ＴＥＩＤ ｃｏｎｔｒｏｌ ｐｌａｎｅ，ＴＥＩＤ Ｄａｔａ Ｉ，ＳＧＳＮ Ａｄｄｒｅｓｓ ｆｏｒ ｓｉｇｎａｌｌｉｎｇ，ＳＧＳＮ Ａｄｄｒｅｓｓ ｆｏｒ ｕｓｅｒ ｔｒａｆｆｉｃの値である（図５参照）。

また、プロトコル解析部１１は、内部保持テーブル１７の“ベアラ状態”を、“開設要求中”から“開設済み”に書き換える。

以上より、プローブ装置１が、ＣＲＥＡＴＥ ＰＤＰ ＣＯＮＴＥＸＴ ＲＥＳＰＯＮＳＥメッセージを検出することによって、該当のＧＴＰ−Ｕトンネルが開設されたことが検出される。また、ＣＲＥＡＴＥ ＰＤＰ ＣＯＮＴＥＸＴ ＲＥＳＰＯＮＳＥメッセージが検出されることによって、内部保持テーブル１７の該当ＧＴＰ−Ｕトンネルに対応する情報がそろう。以降、プロトコル解析部１１は、内部保持テーブル１７を用いて、開設されたＧＴＰ−Ｕトンネルを流れるＧＴＰ-Ｕパケットを検出可能になる。

図１３Ｄは、トンネルを流れるパケットが検出された後の内部保持テーブル１７の一例を示す図である。プロトコル解析部１１は、ＧＴＰ−Ｕプロトコルのパケットを検出した場合に、ＧＴＰ−Ｕパケットのヘッダ情報と内部保持テーブル１７のエントリとを比較し、該ＧＴＰ−Ｕパケットが流れるトンネルを特定する。ＧＴＰ−ＵパケットのＧＴＰ−Ｕのヘッダ部のＴＥＩＤ，ＩＰヘッダ内の宛先ＩＰアドレスが、それぞれ、内部保持テーブル１７の“Ｕ側ＴＥＩＤ（着）”，“Ｕ側ＩＰアドレス（着）”、又は、“Ｕ側ＴＥＩＤ（発）”，“Ｕ側ＩＰアドレス（発）”に一致することによって、該パケットが流れるトンネルが特定される。

プロトコル解析部１１は、内部保持テーブル１７に保持されるトンネルにパケットが流れたことを検出すると、内部保持テーブル１７の該当のトンネルのエントリの“ベアラ状態”を“開設済み：Ｕ検知”に書き換え、該トンネルを流れるパケットの到着順カウントを開始する。プロトコル解析部１１は、内部保持テーブル１７の“ベアラ状態”が“開設済み：Ｕ検知”である間、該当トンネルを流れるパケットの到着順カウントをカウントする。

なお、内部保持テーブル１７のトンネルのエントリは、プロトコル解析部１１がＧＴＰ−Ｃプロトコルの該トンネルの削除に係るメッセージを検出した場合に、削除される。トンネル削除に係るＧＴＰ−Ｃプロトコルのメッセージは、ＤＥＬＥＴＥ ＰＤＰ ＣＯＮＴＥＸＴ ＲＥＱＵＥＳＴメッセージ，ＤＥＬＥＴＥ ＰＤＰ ＣＯＮＴＥＸＴ ＲＥＳＰＯＮＳＥメッセージである。

（アプリケーション識別情報）
図１４は、アプリケーション識別情報１６の一例を示す図である。アプリケーション識別情報１６は、アプリケーション識別部１３が、ＧＴＰ−Ｕパケットのアプリケーションを識別するために用いる情報であり、アプリケーションを定義する情報である。アプリケーション識別情報１６は、例えば、補助記憶装置１０５に格納されている。

図１４に示されるアプリケーション識別情報１６には、定義種別と、定義種別に対応する定義値と、対応アプリケーション識別子とが格納される。定義種別には、例えば、宛先ＩＰアドレス，宛先ポート番号，宛先ＩＰアドレスと宛先ポート番号との組み合わせ，Ｈ
ＴＴＰ内のＵＲＬ，ＤＮＳ解決リクエスト名等の、アプリケーションを識別可能な手段がある。対応アプリケーション識別子には、定義値に対応するアプリケーションの識別子が格納される。なお、図１４に示されるアプリケーション識別情報１６には、アプリケーション名は格納されていないが、アプリケーション識別子とアプリケーション名との対応付けは、品質監視システム１００で定義されており、少なくともマネージャ装置２に保持されていればよい。アプリケーション識別情報１６に、アプリケーション識別子の代わりにアプリケーション名が格納されてもよい。

例えば、最小の到着順カウントを有するＧＴＰ−Ｕパケットから抽出されるユーザパケットの宛先ＩＰアドレスが“１０．２０．３０．１０”である場合には、図１４より、アプリケーション識別部１３は、該パケットのアプリケーション識別子を１００と判定する。また、最小の到着順カウントを有するＧＴＰ−Ｕパケットから抽出されるユーザパケットの情報が、アプリケーション識別情報１６のいずれにも合致しない場合には、アプリケーション識別部１３は、該パケットのアプリケーション識別子を０（未知）と判定する。

（品質データ）
図１５は、アプリケーション識別部１３によって生成される情報の一例を示す図である。アプリケーション識別部１３は、トンネル内を流れた到着順カウントの最小のＧＴＰ−Ｕパケットについて、トンネル開設要因であるアプリケーションの識別を行う。そのため、アプリケーション識別部１３によって生成される情報は、トンネル開設要因であるアプリケーションによって生成された、トンネル内を最初に流れるＧＴＰ−Ｕパケットに関する情報となる。

例えば、図１５に示される例では、アプリケーション識別部１３によって生成される情報には、トンネル内を流れた到着順カウントの最小のＧＴＰ−Ｕパケットの取得時刻，アプリケーション識別子，該パケットが流れたトンネルの状態，該トンネルの両端の制御信号の発生ノード，等の情報が含まれる。例えば、図１５に示される一番上の情報は、１０時１０分１秒に、ＳＧＳＮ＃１とＧＧＳＮ＃２との間の、ユーザ０９０ＸＸＸのＧＴＰ−Ｕトンネルを最初に流れたＧＴＰ−Ｕパケットは、アプリケーション識別子１００のアプリケーションのパケットであることを示す。

図１６は、周期集計部１４によって生成される品質データの一例を示す図である。周期集計部１４は、所定周期で、ＩＰ集計部１２とアプリケーション識別部１３とから通知される情報を基に、品質データを生成する。そのため、品質データは、１周期における各アプリケーションについての、トンネルの使用状況に関する情報が含まれる。

例えば、図１６に示される例では、品質データには、集計時刻，アプリケーション識別子，トンネル開設発生回数，制御信号発生ノード，ユーザ信号パケット数，ユーザ信号使用帯域等が含まれる。例えば、図１６に示される一番上のエントリは、１０時１０分に集計された１周期の間に、ＳＧＳＮ＃１とＧＧＳＮ＃２との間に、アプリケーション識別子１００のアプリケーションによって、ＧＴＰ−Ｕトンネルが５回開設されたことを示す。

＜処理の流れ＞
図１７Ａ及び図１７Ｂは、第１実施形態におけるプローブ装置１のパケット解析処理のフローチャートの一例である。図１７Ａ及び図１７Ｂに示されるフローチャートは、ＴＡＰ ３から分岐されたパケットがプローブ装置１に入力された場合に開始される。

ＯＰ１１では、プロトコル解析部１１が入力パケットのプロトコル解析を行い、ＩＰ集計部１２が入力パケットのＩＰ情報を解析する。

ＯＰ１２では、入力パケットがＧＴＰ−Ｃプロトコルのメッセージである場合には（ＯＰ１２：ＹＥＳ）、処理がＯＰ１３に進む。また、入力パケットがＧＴＰ−Ｃプロトコルのメッセージでない場合には（ＯＰ１２：ＮＯ）、処理がＯＰ１４に進む。ＧＴＰ−Ｃプロトコルのメッセージとは、例えば、トンネル開設に係る、ＣＲＥＡＴＥ ＰＤＰ ＣＯＮＴＥＸＴ ＲＥＱＵＥＳＴメッセージ，ＣＲＥＡＴＥ ＰＤＰ ＣＯＮＴＥＸＴ ＲＥＳＰＯＮＳＥメッセージや、トンネル削除に係るＤＥＬＥＴＥ ＰＤＰ ＣＯＮＴＥＸＴ
ＲＥＱＵＥＳＴメッセージ，ＤＥＬＥＴＥ ＰＤＰ ＣＯＮＴＥＸＴ ＲＥＳＰＯＮＳＥメッセージである。

ＯＰ１３では、プロトコル解析部１１は、入力パケットから取得した情報を内部保持テーブル１７に記録する。なお、この場合の入力パケットは、ＧＴＰ−Ｃプロトコルのメッセージである。その後、図１７Ａ及び図１７Ｂに示される処理が終了する。例えば、図８に示されるトンネル開設処理におけるＯＰ２，ＯＰ３において、プローブ装置１にトンネル開設に係るＧＴＰ−Ｃメッセージが入力される度に、ＯＰ１１−ＯＰ１３の処理が実行され、図１３Ａ−図１３Ｃで説明されたように、内部保持テーブル１７に情報が記録されていく。また、例えば、トンネル削除に係るＧＴＰ−Ｃメッセージが入力されると、ＯＰ１３において、内部保持テーブル１７の該当する情報が削除される。

ＯＰ１４では、入力パケットがＧＴＰ−Ｕプロトコルのパケットである場合には（ＯＰ１４：ＹＥＳ）、処理がＯＰ１５に進む。また、ＯＰ１４では、入力パケットがＧＴＰ−Ｃプロトコルのトンネル開設に係るメッセージでなく（ＯＰ１２：ＮＯ）、且つ、ＧＴＰ−Ｕプロトコルのパケットでもない場合には（ＯＰ１４：ＮＯ）、処理がＯＰ２２に進む。

ＯＰ１５では、プロトコル解析部１１は、入力パケットの情報と、内部保持テーブル１７の情報とを比較し、入力パケットの情報に該当するトンネルの記録が内部保持テーブル１７に有るか否かを判定する。この場合の入力パケットは、ＧＴＰ−Ｕプロトコルのパケットである。入力パケットの情報に合致するトンネルの記録が内部保持テーブル１７にある場合には（ＯＰ１５：ＹＥＳ）、処理がＯＰ１６に進む。入力パケットの情報に合致するトンネルの記録が内部保持テーブル１７にない場合には（ＯＰ１５：ＮＯ）、処理がＯＰ２２に進む。

ＯＰ１６では、プロトコル解析部１１は、該当トンネルの到着順カウントに１を加算し、入力パケットに、該当トンネルの到着順カウントを付与する。入力パケットは、アプリケーション識別部１３に渡される。次に処理がＯＰ１７に進む。

ＯＰ１７及びＯＰ１８は、入力パケットについてアプリケーション識別を行うか否かを判定するための処理である。ＯＰ１７では、アプリケーション識別部１３は、入力パケットについて、アプリケーション識別の解析対象か、該当トンネルの開設要因のアプリケーションが未識別であるか、を判定する。入力パケットについて、アプリケーション識別の解析対象であり、且つ、該当トンネルの開設要因のアプリケーションが未識別である場合には（ＯＰ１７：ＹＥＳ）、処理がＯＰ１８に進む。入力パケットについて、アプリケーション識別の除外対象である、又は、該当トンネルについて開設要因のアプリケーションが識別済みである場合には（ＯＰ１７：ＮＯ）、処理がＯＰ２２に進む。

アプリケーション識別の解析対象の判定は、上述の通り、予め定められた条件（図１２参照）に合致するか否かを判定するによって行われる。該当トンネルのアプリケーションが未識別であるか否かは、例えば、アプリケーション識別部１３が周期集計部１４に通知した情報（図６参照）を所定時間主記憶装置１０２にバッファしておき、該当トンネルの情報がバッファ内に有るか否かを判定することによって行われる。または、該当トンネル
のアプリケーションが未識別であるか否かは、例えば、内部保持テーブル１７にアプリケーション識別の項目を設け、フラグを立てる等して、開設要因のアプリケーションの識別済みのトンネルを記録し、該記録によって判定されてもよい。

ＯＰ１８では、アプリケーション識別部１３は、ＯＰ１７において、アプリケーションの解析対象であり、該当トンネルの開設要因のアプリケーションが未識別であると判定した入力パケットの到着順カウントが、該当トンネルにおいて最小カウントであるか否かを判定する。入力パケットの到着順カウントが、該当トンネルにおいて最小カウントである場合には（ＯＰ１８：ＹＥＳ）、処理がＯＰ１９に進む。入力パケットの到着順カウントが、該当トンネルにおいて最小カウントでない場合には（ＯＰ１８：ＮＯ）、入力パケットについてアプリケーション識別は行われず、処理がＯＰ２２に進む。

例えば、この判定は、アプリケーション識別部１３が、存在する各トンネルについて最小の到着順カウントを記録するメモリを主記憶装置１０２に有し、入力パケットの到着順カウントが、該メモリに記録された到着順カウントより小さいか否かで判定する。該メモリに、入力パケットに該当するトンネルの最小の到着順カウントが記録されていない場合には、アプリケーション識別部１３は、該入力パケットに付与されている到着順カウントを最小の到着順カウントのＧＴＰ−Ｕパケットとして判定し、該到着順カウントをメモリに書込む。なお、入力パケットの到着順カウントが、メモリに記録された到着順カウントより小さい場合には、アプリケーション識別部１３は、入力パケットの到着順カウントで、該当トンネルの主記憶装置１０２に記録された到着順カウントを書き換える。

ＯＰ１９では、アプリケーション識別部１３は、入力パケットの情報と、アプリケーション識別情報１６とを比較し、入力パケットの情報と合致するアプリケーションが有るか否かを判定する。入力パケットの情報と合致するアプリケーションが有る場合には（ＯＰ１９：ＹＥＳ）、処理がＯＰ２０に進み、アプリケーション識別部１３は、入力パケットに該当のアプリケーション識別子を付与する。入力パケットの情報と合致するアプリケーションがない場合には（ＯＰ１９：ＮＯ）、処理がＯＰ２１に進み、アプリケーション識別部１３は、入力パケットに、例えば、該当のアプリケーションが無いことを示す０をアプリケーション識別子として付与する。次に処理がＯＰ２２に進む。

ＯＰ２２では、アプリケーション識別部１３またはＩＰ集計部１２は、入力パケットのパケット量をカウントしたりして、ＩＰ情報を解析する。アプリケーション識別部１３お及びＩＰ集計部１２は、解析した情報を周期集計部１４に送信する。その後、図１７Ａ及び図１７Ｂに示される処理が終了する。

なお、図１７Ａ及び図１７Ｂに示される処理は、一例であって、実行の有無，順序等は、適宜変更されてもよい。例えば、入力パケットについてアプリケーション識別を行うか否かを判定するＯＰ１７及びＯＰ１８の処理は、実行順が逆であってもよい。

図１８は、周期的に行われるパケットの情報の集計処理のフローチャートの一例である。図１８に示される処理は、周期集計部１４の品質データ生成の所定の周期のタイミングで開始される。

ＯＰ３１では、周期集計部１４は、ＩＰ集計部１２及びアプリケーション識別部１３から通知された１周期分の情報を集計し、品質データを生成する。このとき、周期集計部１４は、アプリケーション毎のトンネル開設発生回数をカウントする。例えば、情報は、アプリケーション単位で集計される。

ＯＰ３２では、周期集計部１４は、生成した品質データをマネージャＩＦ １５を通じ
てマネージャ装置２に送信する。その後、図１８に示される処理が終了する。

＜マネージャ装置＞
図１９は、マネージャ装置２の機能ブロックの一例を示す図である。マネージャ装置２のハードウェア構成は、図１０に示されるプローブ装置１とほぼ同様である。マネージャ装置２は、補助記憶装置１０５に品質集計プログラムを格納し、ＣＰＵ１０１が品質集計プログラムを実行することによって、情報収集部２１，品質値統計部２２，アラーム判定部２３として動作する。また、品質集計プログラムのロードにより、補助記憶装置１０５に、構成情報格納部２４，品質情報格納部２５，アラーム情報格納部２６が生成される。

情報収集部２１は、品質監視システム１００内の複数のプローブ装置１から品質データを受信する。各プローブ装置１からは、所定の周期で品質データが受信される。

品質値統計部２２は、情報収集部２１によって受信された品質データを、構成情報格納部２４に格納される情報を用いて、監視対象とする装置について統計に用いる品質データの絞り込みを行う。監視対象とする装置は、事前に決定されている。品質値統計部２２は、絞り込んだ品質データを集計し、パケット交換コアネットワーク５３０全体での、アプリケーション単位の品質情報，装置単位の品質情報等を生成し、品質情報格納部２５に蓄積し、アラーム判定部２３に通知する。例えば、品質統計部２２は、時間帯及びアプリケーション毎にトンネル開設が行われた回数を集計して、品質情報格納部２５に蓄積する。

アラーム判定部２３は、予め保持する閾値と、品質値統計部２２から通知される品質情報に含まれる値とを比較し、評価することで、品質の劣化を検出する。アラーム判定部２３は、品質の劣化を検出した情報を、アラーム情報格納部２６に蓄積する。また、アラーム判定部２６は、品質の劣化を検出した場合に、出力装置１０４からアラームを報知してもよい。なお、品質の劣化とは、負荷の増加のことであり、例えば、トンネル開設発生回数の増加等である。また、閾値は、品質情報に含まれる品質値毎に設定される。品質情報に含まれる品質値の一つは、例えば、トンネル開設発生回数であり、この場合の閾値は、ネットワーク全体におけるトンネル開設発生回数のうちの未識別のアプリケーションが占める割合の閾値、所定のアプリケーションの所定時刻におけるトンネル開設発生回数の閾値等である。品質情報に含まれる品質値には、他に、パケットロスの発生数及び発生率，瞬間最大のトラヒック流通量（バーストトラヒック）等がある。

表示処理部２７は、品質監視システム１００の運用者から指示が入力されると、指示に応じて、品質情報格納部２５又はアラーム情報格納部２６から情報を読出し、ディスプレイやスピーカ等の出力装置１０４に出力する。

構成情報格納部２４には、パケット交換コアネットワーク５３０に含まれる装置のＩＰアドレスや名称，各装置の接続関係等が格納される。品質情報格納部２５には、品質値統計部２２によって生成された品質情報が格納される。アラーム情報格納部２６には、アラーム判定部２３によって生成されたアラーム情報が格納される。

図２０は、マネージャ装置２の情報集計処理のフローチャートの一例である。図２０に示されるフローチャートは、例えば、所定の周期で開始される。または、図２０に示されるフローチャートは、例えば、品質監視システム１００内のいずれかのプローブ装置１からの品質データの受信を契機に開始される。

ＯＰ４１では、品質値統計部２２は、構成情報格納部２４に格納される情報を用いて、監視対象となる装置に品質データを絞り込む。

ＯＰ４２では、品質値統計部２２は、監視対象となる装置について、全てのプローブ装置１からの品質値を集計し、品質情報を生成する。例えば、品質値統計部２２は、時間帯毎、及び／又は、アプリケーション毎に、トンネル開設回数を集計して品質情報を生成する。ＯＰ４３では、品質値統計部２２は、生成した品質情報を品質情報格納部２５に蓄積する。品質値統計部２２は、生成した品質情報をアラーム判定部２３に通知する。

ＯＰ４４では、アラーム判定部２３は、閾値と品質情報に含まれる品質値を比較し、品質の劣化の有無を判定する。例えば、品質情報に含まれる品質値が、時間帯及びアプリケーション毎のトンネル開設回数である場合には、閾値よりも品質値が大きい場合に、アラーム判定部２３は、品質の劣化を判定する。品質の劣化が有る場合には（ＯＰ４４：ＹＥＳ）、処理がＯＰ４５に進み、アラーム判定部２３は、品質の劣化が検出された品質情報をアラーム情報としてアラーム情報格納部２６に格納する。その後、処理が終了する。品質の劣化が無い場合には（ＯＰ４４：ＮＯ）、図２０に示される処理が終了する。

図２１は、品質情報又はアラーム情報の表示処理のフローチャートの一例を示す図である。図２１に示されるフローチャートは、例えば、システム運用者から表示要求が入力された場合に開始される。システム運用者からの表示要求には、システム運用者が確認した情報についての条件が含まれる。条件には、例えば、時間帯の指定，装置の指定等が含まれる。

ＯＰ５１，ＯＰ５２では、表示処理部２７は、ぞれぞれ、アラーム情報格納部２６，品質情報格納部２５から、システム運用者によって指定された条件に合致する情報を検索する。ＯＰ５３では、表示処理部２７は、検索の結果得られた情報をディスプレイに表示する。その後、図２１に示される処理が終了する。

（品質情報の表示例）
図２２は、品質情報の表示例の一つである。図２２に示される例では、所定期間における、ユーザ信号パケット数と、トンネル開設発生回数と、について、各アプリケーションの占める割合が円グラフで示されている。

図２２に示される例では、ユーザ信号パケット数に占める割合は、アプリケーション１が大きいが、トンネル開設発生回数に占める割合は、アプリケーション３が大きい。すなわち、図２２に示される例から、アプリケーション３は、１回の通信で送受信されるデータ量は小さいものの、トンネル開設頻度が高いことが示され、アプリケーション３は、ネットワークにとって負荷をかけるアプリケーションであることが示される。このように、ユーザ信号パケット数とトンネル開設発生回数との各アプリケーションが占める割合を表示することによって、ネットワークに負荷をかけているアプリケーションを特定することができる。

また、図２２に示されるようなトンネル開設発生回数の各アプリケーションが占める割合を時系列で比較することによって、未知のアプリケーションが占める割合が増えた場合に、未知のアプリケーションの台頭を検出することができる。また、このとき、ユーザ信号パケット数に占める未知のアプリケーションの割合を参照することによって、未知のアプリケーションがネットワークにとって脅威となるものか否かを判定することも可能である。

図２３は、品質情報の表示例の一つである。図２３に示される例では、所定期間における各装置の負荷状況が棒グラフで示される。図２３に示される例から、負荷の集中している装置を検出したり、装置の性能向上に向けた目標値を確認することができる。また、各装置において、負荷をかけているアプリケーションを検出することができる。

図２４Ａ及び図２４Ｂは、品質情報の表示例の一つである。図２４Ａ及び図２４Ｂに示される例では、１つのアプリケーションについて、各時刻における全ユーザの制御信号発生回数を累積した棒グラフが示される。図２４Ａの表示例３１及び図２４Ｂの表示例３２は、同じアプリケーション１について、異なる日（表示例３２の方が新しい）の同じ時刻における全ユーザの制御信号発生回数を示す。

表示例３１では、時刻Ａ−Ｇにおいて、制御信号発生回数に偏りが無く、平均化されている。すなわち、システム運用者は、表示例３１から、アプリケーション１は、所定の間隔で通信を行うアプリケーションであることを判定することができる。

一方、表示例３２では、時刻Ａと時刻Ｅとに、制御信号の発生が集中している。すなわち、システム運用者は、表示例３２から、アプリケーション１は、所定の時刻において通信を行うアプリケーションであることを判定することができる。

表示例３１と表示例３２とから、システム運用者は、表示例３１と表示例３２との間に、例えば、アップデート等によってアプリケーション１の動作が変化したことを検出することができる。

所定の時刻において通信を行うアプリケーションでは、該所定の時刻に負荷が集中しやすく、ネットワークへの負荷が懸念される。図２４Ａ及び図２４Ｂに示される例のように、アプリケーション毎に、各時刻において全ユーザの制御信号発生回数を累積することによって、ネットワークへ負荷をかける、所定の時刻に通信を行うアプリケーションを特定することができる。

＜第１実施形態の作用効果＞
第１実施形態では、ＧＴＰ−Ｕトンネル開設直後に該トンネルを流れるＧＴＰ−Ｕパケットのアプリケーションを特定することによって、該トンネルの開設要因となるアプリケーションを識別することができる。これによって、ネットワーク内の装置のトラヒック処理性能をアプリケーション単位の各装置の負荷状況から設計することが可能となる。

また、トンネルの開設要因となるアプリケーションの情報を用いて、アプリケーション毎の負荷状況を監視することによって、例えば、アプリケーションのアップデートによる挙動変化や、未識別のアプリケーションによる負荷の増加等を検出することができる。また、これらの検出時に、マネージャ装置２がアラームを報知することによって、挙動の詳細調査が必要なタイミングを運用トリガとして運用に取り入れることが可能となる。これによって、定期的な監視が不要となり、アラーム発生時に調査を行うことで運用コストの削減が可能となる。

また、アプリケーション単位で制御信号の負荷を計測することによって、ネットワークへ負荷をかけているアプリケーションを特定し、アプリケーションのベンダへの改善依頼をすることができる。これによって、アプリケーションのベンダによるネットワーク負荷の削減となるアプリケーションの方式変更が期待でき、ネットワーク内の装置への投資を低減することが可能となる。

なお、第１実施形態は、ＧＴＰを例に説明したが、第１実施形態で説明された技術の適用は、ＧＴＰに限られない。第１実施形態で説明された技術は、例えば、ＰＭＩＰ（Proxy Mobile IPv6）等の、トンネル識別子を用いるトンネリングプロトコルに適用可能であ
る。

＜第２実施形態＞
第２実施形態では、プローブ装置１は、ＧＴＰ−Ｕトンネルを含む経路における装置間のトンネル外において、トンネル開設要因となるアプリケーションを特定する場合について説明される。第２実施形態では、第１実施形態と共通する説明は省略される。

例えば、図１に示される無線通信ネットワークシステム５００の中継パケット交換機５０とＷｅｂサービスゲートウェイ７０との間のポイントＰ２では、ＧＴＰパケットは流れない。すなわち、ポイントＰ２にプローブ装置１が配置された場合には、プローブ装置１は、ＧＴＰ−ＣパケットもＧＴＰ−Ｕのパケットも取得することができないため、ＧＴＰのパケットからトンネル開設要因となるアプリケーションを特定することができない。

図２５は、第２実施形態のトンネル開設要因となるアプリケーションを特定する方法について説明するための図である。図２５では、ＧＴＰ−Ｕトンネルの経路外のキャプチャポイントにおいて検出される、１のユーザの各時刻のパケット数が示される。ＧＴＰ−Ｕトンネルは、１つのトンネルにつき１つの携帯端末１０のユーザデータが流れる。そのため、ＧＴＰ−Ｕトンネルは、ネットワーク管理者によって設定された削除タイマが、該トンネルに対応する携帯端末１０のユーザパケットが流れずにタイムアウトすると、削除されるように設定されることが多い。すなわち、ＧＴＰ−Ｕトンネルの経路外のキャプチャポイントにおいて、１つの携帯端末１０のユーザパケットの受信間隔がＧＴＰ−Ｕトンネルの削除タイマの時間（図２５中「Ｎ秒」）以上である場合には、経路上に含まれる１つのＧＴＰ−Ｕトンネルが解放されたとみなすことができる。

したがって、第２実施形態では、プローブ装置１は、ＧＴＰ−Ｕトンネルの経路外のキャプチャポイントにおいて、１つの携帯端末１０についてパケットの受信間隔を監視し、パケットの受信間隔がＮ秒以上経過後の最初のパケットを、トンネルに最初に流れたユーザパケットとみなす。Ｎ秒は、例えば、ＧＴＰ−Ｕトンネルの削除タイマの値であり、６０秒である。

第２実施形態では、プローブ装置１のハードウェア構成及び機能ブロックは、第１実施形態と同様である。

第２実施形態では、ＩＰ集計部１２は、送信元ＩＰアドレスが同じパケットを同一セッションとして識別する。ＩＰ集計部１２は、セッションを内部的に識別するための内部セッションＩＤをパケットに付与し、アプリケーション識別部１３へ通知する。

アプリケーション識別部１３は、各セッションについて、最後に受信したパケットの受信時刻を、最終受信時刻として、例えば、主記憶装置１０２に保持する。アプリケーション識別部１３は、次に同一セッションのパケットを受信した場合に、該パケットに付与されている受信時刻と保持している最終受信時刻とから、パケットの受信間隔を算出する。受信間隔がＮ秒を超えていた場合、アプリケーション識別部１３は、受信したパケットについて、第１実施形態と同様に、アプリケーションの識別を行う。

＜処理の流れ＞
図２６は、第２実施形態におけるプローブ装置１のパケット解析処理のフローチャートの一例である。図２６に示されるフローチャートは、ＴＡＰ ３から分岐されたパケットをプローブ装置１が受信した場合に開始される。

ＯＰ６１では、プロトコル解析部１１が入力パケットのプロトコル解析を行い、ＩＰ集計部１２が入力パケットのＩＰ情報を解析する。ＩＰ集計部１２は入力パケットの送信元ＩＰアドレスによってセッションを判定し、入力パケットに内部セッションＩＤを付与す
る。

ＯＰ６２では、アプリケーション識別部１３は、入力パケットが新規セッションのパケットであるか否かを判定する。入力パケットが新規セッションのパケットである場合には（ＯＰ６２：ＹＥＳ）、処理がＯＰ６３に進み、アプリケーション識別部１３は、該当セッションの最終受信時刻を入力パケットに付与される受信時刻で更新する。その後、処理は、図１７ＢのＯＰ２２に進み、入力パケットについて集計が行われると、処理が終了する。入力パケットが既存のセッションのパケットである場合には（ＯＰ６２：ＮＯ）、処理がＯＰ６４に進む。

ＯＰ６４では、アプリケーション識別部１３は、入力パケットに付与された受信時刻と、保持する該当セッションの最終受信時刻とから、受信間隔を算出する。

ＯＰ６５では、アプリケーション識別部１３は、算出した受信間隔がＮ秒以上であるか否かを判定する。受信間隔がＮ秒以上である場合には（ＯＰ６５：ＹＥＳ）、アプリケーション識別部１３は、入力パケットについてアプリケーション識別を行うことを決定する。処理はＯＰ６６に進み、アプリケーション識別部１３は、該当セッションの最終受信時刻を入力パケットに付与される受信時刻で更新する。その後、処理は、図１７ＢのＯＰ１７に進み、入力パケットについてアプリケーション識別の処理が行われる。

受信間隔がＮ秒未満である場合には（ＯＰ６５：ＮＯ）、アプリケーション識別部１３は、入力パケットについてアプリケーション識別を行わないことを決定する。その後、処理がＯＰ６３に進み、アプリケーション識別部１３は、該当セッションの最終受信時刻を入力パケットに付与される受信時刻で更新する。その後、処理は、図１７ＢのＯＰ２２に進み、入力パケットについて集計が行われると、処理が終了する。

＜第２実施形態の作用効果＞
第２実施形態では、プローブ装置１は、１のユーザについて、パケットの受信間隔がＮ秒以上経過した後に受信する最初のパケットを、トンネルの開設要因となるアプリケーションのパケットとみなし、アプリケーションの識別を行う。これによって、トンネリングプロトコルを直接参照できないキャプチャポイントにおいても、制御信号の負荷を計測することができる。例えば、監視を行いたい通信先に限定してプローブ装置１を配置することにより、品質監視システムの導入コストを低減することが可能となる。

なお、第２実施形態では、１つのＧＴＰ−Ｕトンネルにつき１つの携帯端末１０のユーザパケットが流れるという設計下において、トンネル開設要因となるアプリケーション識別処理について説明した。ただし、第２実施形態で説明された技術の適用は、１つの携帯端末１０につき１つ開設されるトンネルに限られない。例えば、ＬＴＥにおいて、ＱＣＩ（QoS Class Identifier）毎に開設されるトンネルにも適用可能である。ＱＣＩは、ＱｏＳ種別を指摘するためのパラメータである。ＱＣＩ毎にトンネルが開設される場合には、プローブ装置１は、送信元ＩＰアドレスとＱＣＩとが同じパケットを同一のセッションとみなして、各セッションのパケットの受信間隔を計測する。

＜その他＞
第１実施形態及び第２実施形態において、マネージャ装置２はプローブ装置１とは異なる独立した装置として説明したが、マネージャ装置２は、プローブ装置１と同じ装置であってもよい。

１ プローブ装置
２ マネージャ装置
３ ＴＡＰ
１１ プロトコル解析部
１２ ＩＰ集計部
１３ アプリケーション識別部
１４ 周期集計部
１５ マネージャＩＦ
１６ アプリケーション識別情報
１７ 内部保持テーブル

Claims (9)

1. プロセッサと、メモリとを備え、
   ネットワーク内の所定の位置において、前記ネットワークを流れるパケットをキャプチャする情報処理装置であって、
   前記プロセッサは、
   前記キャプチャしたパケットが、所定のトンネリングプロトコルによるトンネルに最初に流れたユーザパケットであるか否かを判定し、
   前記キャプチャしたパケットが前記トンネルに最初に流れたユーザパケットである場合に、前記キャプチャしたパケットから、前記トンネルの開設要因であるアプリケーションを識別する、
   情報処理装置。
2. 前記情報処理装置は、前記トンネルの経路上に位置する装置間に流れるパケットをキャプチャし、
   前記プロセッサは、
   前記所定のトンネリングプロトコルの制御パケットを検出することで、前記トンネルの開設を検出し、
   前記トンネルを流れるユーザパケットに、前記トンネルの開設からの到着順を示す番号を付与し、
   前記トンネルを流れるユーザパケットに付与された番号が前記トンネルにおいて最小である場合に、前記トンネルを流れるパケットを前記所定のトンネルを最初に流れたパケットであることを判定する、
   請求項１に記載の情報処理装置。
3. 前記プロセッサは、
   前記制御パケットから開設されたトンネルの識別情報を取得して、前記メモリに格納し、
   前記所定のトンネリングプロトコルのユーザパケットを検出した場合に、前記メモリに格納された前記トンネルの識別情報を用いて、該ユーザパケットが前記トンネルを流れるパケットであることを判定する、
   請求項２に記載の情報処理装置。
4. 前記プロセッサは、
   前記アプリケーションの識別において、前記キャプチャしたパケットが、アプリケーションの識別困難なパケットである場合には、前記キャプチャしたパケットについて、前記アプリケーションの識別を行わない、
   請求項１から３のいずれか一項に記載の情報処理装置。
5. 前記情報処理装置は、前記トンネルを含む経路に位置する装置間のパケットを前記トンネル外でキャプチャし、
   前記プロセッサは、
   前記キャプチャしたパケットの受信間隔を計測し、
   前記受信間隔が、前記トンネルが削除される所定時間以上である場合に、該所定時間以上後に最初にキャプチャしたパケットを、前記前記トンネルに最初に流れたユーザパケットであると判定する、
   請求項１に記載の情報処理装置。
6. 前記プロセッサは、
   前記キャプチャしたパケットの送信元アドレス毎にパケットの受信間隔を計測する、
   請求項５に記載の情報処理装置。
7. プロセッサと、メモリとを備え、
   ネットワーク内の所定の位置において、前記ネットワークを流れるパケットをキャプチャする情報処理装置において、
   前記プロセッサが、
   前記キャプチャしたパケットが、所定のトンネリングプロトコルによるトンネルに最初に流れたユーザパケットであるか否かを判定し、
   前記キャプチャしたパケットが前記トンネルに最初に流れたユーザパケットである場合に、前記キャプチャしたパケットから、前記トンネルの開設要因であるアプリケーションを識別する、
   情報処理方法。
8. プロセッサと、メモリとを備え、
   ネットワーク内の所定の位置において、前記ネットワークを流れるパケットをキャプチャする情報処理装置において、
   前記プロセッサに、
   前記キャプチャしたパケットが、所定のトンネリングプロトコルによるトンネルに最初に流れたユーザパケットであるか否かを判定させ、
   前記キャプチャしたパケットが前記トンネルに最初に流れたユーザパケットである場合に、前記キャプチャしたパケットから、前記トンネルの開設要因であるアプリケーションを識別させる、
   ための情報処理プログラム。
9. ネットワーク内の所定の位置において、前記ネットワークを流れるパケットをキャプチャするキャプチャ部と、
   前記キャプチャしたパケットが、所定のトンネリングプロトコルによるトンネルに最初に流れたユーザパケットであるか否かを判定し、前記キャプチャしたパケットが前記トンネルに最初に流れたユーザパケットである場合に、前記キャプチャしたパケットから、前記トンネルの開設要因であるアプリケーションを識別する識別部と、
   所定の周期で、アプリケーション毎にトンネルの開設回数を集計する集計部と、
   を備える情報処理システム。

Images