(57)【要約】      （修正有）【課題】シグナリングを発生させたアプリケーションを特定するシステム及び装置を提供する。【解決手段】パケット詳細解析装置ＣＰ−ＤＰＩ１４２はネットワークとユーザー端末１０１との間の接続要求に関する制御信号を監視し、受信ログを生成する。パケット詳細解析装置ＵＰ−ＤＰＩ１４１はユーザデータを転送するゲートウェイ装置Ｓ−ＧＷ１３１に入出力されるパケットを監視しセッション毎に分け、セッションを生成するアプリケーション種別を特定しアプリケーションの種別を含むセッションログを生成する。トラフィック管理サーバ１４３はパケット詳細解析装置ＵＰ−ＤＰＩが生成した受信ログとパケット詳細解析装置ＣＰ−ＤＰＩが生成したセッションログとを取得し、受信ログの発生時刻、セッションログの発生時刻及び端末の識別子を用いて受信ログとセッションログとを関連付け、制御信号を発生させたセッションに関連するアプリケーションを特定する。【選択図】図１
2016096415.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークと端末との間の接続要求に関する制御信号を監視し、受信ログを生成する第一の監視装置と、
ユーザデータを転送するゲートウェイ装置に入出力されるパケットを監視し、前記パケットをセッション毎に分け、前記セッションを生成するアプリケーションの種別を特定し、前記アプリケーションの種別を含むセッションログを生成する第二の監視装置と、
前記第一の監視装置が生成した受信ログと、前記第二の監視装置が生成したセッションログとを取得し、前記受信ログの発生時刻、前記セッションログの発生時刻及び前記端末の識別子を用いて前記受信ログと前記セッションログとを関連付け、前記制御信号を発生させたセッションに関連するアプリケーションを特定するトラフィック管理サーバと、を備えることを特徴とする通信システム。
【請求項２】
請求項１に記載の通信システムであって、
前記第一の監視装置は、前記端末が属するユーザグループ毎に前記受信ログを分けて出力し、
前記第二の監視装置は、前記ユーザグループ毎に前記セッションログを分けて出力し、
前記トラフィック管理サーバは、
前記ユーザグループ毎に分けられた受信ログ及びセッションログを取得し、
前記ユーザグループに従って前記受信ログと前記セッションログとを関連付けることを特徴とする通信システム。
【請求項３】
請求項１に記載の通信システムであって、
前記接続要求に関する制御信号を処理する通信装置を備え、
前記第一の監視装置は、前記ゲートウェイ装置及び前記通信装置の組毎に前記受信ログを分けて出力し、
前記第二の監視装置は、前記ゲートウェイ装置及び前記通信装置の組毎に前記セッションログを分けて出力し、
前記トラフィック管理サーバは、
前記ゲートウェイ装置及び前記通信装置の組毎に分けられた受信ログ及びセッションログを取得し、
前記ゲートウェイ装置及び前記通信装置の組に従って前記受信ログと前記セッションログとを関連付けることを特徴とする通信システム。
【請求項４】
請求項１に記載の通信システムであって、
前記接続要求に関する制御信号を処理する通信装置を備え、
前記第一の監視装置は、前記ゲートウェイ装置、前記通信装置及びユーザグループの組毎に前記受信ログを分けて出力し、
前記第二の監視装置は、前記ゲートウェイ装置、前記通信装置及びユーザグループの組毎に前記セッションログを分けて出力し、
前記トラフィック管理サーバは、
前記ゲートウェイ装置、前記通信装置及び前記ユーザグループの組ごとに分けられた受信ログ及びセッションログを取得し、
前記ゲートウェイ装置、前記通信装置及び前記ユーザグループの組に従って前記受信ログと前記セッションログとを関連付けることを特徴とする通信システム。
【請求項５】
請求項１に記載の通信システムであって、
前記第二の監視装置は、前記端末が送受信する制御信号から前記端末の接続状態を推定し、前記接続状態の変化から所定時間内に発生したセッションログにラベルを付けて、出力し、
前記トラフィック管理サーバは、前記ラベル付けされたセッションログを取得し、前記ラベル付けされたセッションログと前記受信ログとを関連付けることを特徴とする通信システム。
【請求項６】
請求項１に記載の通信システムであって、
前記第二の監視装置は、前記端末が送受信する制御信号から前記端末の接続状態を推定し、前記接続状態の変化から所定時間内に発生したセッションログを出力することを特徴とする通信システム。
【請求項７】
通信システムを構成するネットワークと端末との間の接続要求に関する制御信号を監視する第一の監視装置から出力された受信ログを取得し、
ユーザデータを転送するゲートウェイ装置に入出力されるパケットを監視し、前記パケットをセッション毎に分け、前記セッションを生成するアプリケーションの種別を特定する第二の監視装置から出力されたセッションログを取得し、
前記受信ログの発生時刻、前記セッションログの発生時刻及び前記端末の識別子を用いて前記受信ログと前記セッションログとを関連付け、
前記制御信号を発生させたセッションに関連するアプリケーションを特定することを特徴とする管理サーバ。
【請求項８】
請求項７に記載の管理サーバであって、
前記第二の監視装置は、前記端末が送受信する制御信号から前記端末の接続状態を推定し、前記接続状態の変化から所定時間内に発生したセッションログにラベルを付けて、出力し、
前記管理サーバは、前記ラベル付けされたセッションログを取得し、前記ラベル付けされたセッションログと前記受信ログとを関連付けることを特徴とする管理サーバ。
【請求項９】
請求項７に記載の管理サーバであって、
前記第一の監視装置は、前記端末が属するユーザグループ毎に前記受信ログを分けて出力し、
前記第二の監視装置は、前記ユーザグループ毎に前記セッションログを分けて出力し、
前記管理サーバは、
前記ユーザグループ毎に分けられた受信ログ及びセッションログを取得し、
前記ユーザグループに従って前記受信ログと前記セッションログとを関連付けることを特徴とする管理サーバ。
【請求項１０】
請求項７に記載の管理サーバであって、
前記通信システムは、前記接続要求に関する制御信号を処理する通信装置を有し、
前記第一の監視装置は、前記ゲートウェイ装置、前記通信装置及びユーザグループの組毎に前記受信ログを分けて出力し、
前記第二の監視装置は、前記ゲートウェイ装置、前記通信装置及びユーザグループの組毎に前記セッションログを分けて出力し、
前記管理サーバは、
前記ゲートウェイ装置、前記通信装置及び前記ユーザグループの組ごとに分けられた受信ログ及びセッションログを取得し、
前記ゲートウェイ装置、前記通信装置及び前記ユーザグループの組に従って前記受信ログと前記セッションログとを関連付けることを特徴とする管理サーバ。
【請求項１１】
通信システムにおけるゲートウェイ装置に入出力されるパケットを監視する監視装置であって、
前記パケットをセッション毎に分け、
前記セッションを生成するアプリケーションの種別を特定し、
ユーザグループ毎に前記セッションのセッションログを生成し、
前記通信システムを構成するネットワークと端末との間の接続要求に関する制御信号を監視した受信ログと前記生成されたセッションログとを関連付けさせるために、前記生成したセッションログをトラフィック管理サーバに出力することを特徴とする監視装置。
【請求項１２】
請求項１１に記載の監視装置であって、
前記通信システムは、前記接続要求に関する制御信号を処理する通信装置を有し、
前記監視装置は、前記ゲートウェイ装置、前記通信装置及びユーザグループの組毎に前記セッションログを生成することを特徴とする監視装置。
【請求項１３】
請求項１１に記載の監視装置であって、
前記端末が送受信する制御信号から前記端末の接続状態を推定し、前記接続状態の変化から所定時間内に発生したセッションログにラベルを付けて、出力することを特徴とする監視装置。
【請求項１４】
請求項１１に記載の監視装置であって、
前記端末が送受信する制御信号から前記端末の接続状態を推定し、
前記接続状態の変化から所定時間内に発生したセッションログを出力することを特徴とする監視装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ユーザデータを転送する通信システムに関する。
【背景技術】
【０００２】
セルラ通信システムでは、スマートフォンの普及に伴い、ビデオストリーミング、ゲーム、ＳＮＳ（Ｓｏｃｉａｌ  Ｎｅｔｗｏｒｋｉｎｇ  Ｓｅｒｖｉｃｅ）、ＩＭ（Ｉｎｓｔａｎｔ  Ｍｅｓｓｅｎｇｅｒ）等の様々なアプリケーションが使用されている。スマートフォンで使用されるアプリケーションには常時接続をするものがあり、このようなアプリケーションはセルラ通信システムへ頻繁に接続を要求する。又は、多数のユーザが同時にアプリケーションの情報を更新するなど、アプリケーションの挙動によっては、多数のユーザが同時に接続を要求する。このように接続要求が同時に発生することによって、セルラ通信システムのコアネットワークでは、特定の短期間において多くのシグナリングが発生するシグナリングバーストが見られる。このようなシグナリングバーストが発生すると、コアネットワーク装置が過負荷となり、ユーザがセルラ通信システムに接続できなくなるなど、セルラ通信システムのサービスへ影響を与える。
【０００３】
シグナリングバーストによるセルラ通信システムのサービスへの影響を防ぐため、モバイルネットワーク事業者は、シグナリングを発生させるアプリケーションを特定して、シグナリングバーストを発生させるアプリケーションの開発者に改修を求めることがある。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２０１４−３４０８号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
セルラ通信システムにおいて、接続要求のシグナリングを発生させる端末を特定する方法、端末の送受信したトラフィックのアプリケーションを特定する方法として、プローブ装置によりコアネットワークのシグナリング情報やトラフィック情報を取得し、解析する方法がある。例えば、３ＧＰＰ（３ｒｄ  Ｇｅｎｅｒａｔｉｏｎ  Ｐａｒｔｎｅｒｓｈｉｐ  Ｐｒｏｊｅｃｔ）で標準化されているＬＴＥ（Ｌｏｎｇ  Ｔｅｒｍ  Ｅｖｏｌｕｔｉｏｎ）では、ｅＮｏｄｅＢとＭＭＥ（Ｍｏｂｉｌｉｔｙ  Ｍａｎａｇｅｍｅｎｔ  Ｅｎｔｉｔｙ）と間のインタフェースであるＳ１−ＭＭＥや、ＭＭＥとＳ−ＧＷ間のインタフェースであるＳ１１をプローブ装置で監視することによって、シグナリング情報を取得することができる。また、ｅＮｏｄｅＢ（Ｅ−ＵＴＲＡＮ  ＮｏｄｅＢ）とＳ−ＧＷ（Ｓｅｒｖｉｎｇ  Ｇａｔｅｗａｙ）間のインタフェースであるＳ１−Ｕや、ＰＤＮ（Ｐａｃｋｅｔ  Ｄａｔａ  Ｎｅｔｗｏｒｋ）とＰ−ＧＷ（ＰＤＮ  Ｇａｔｅｗａｙ）間のインタフェースであるＳＧｉを、プローブ装置で監視することによって、トラフィック情報を取得することができる。
【０００６】
取得したシグナリング情報から、ネットワークへの接続を要求した端末と、要求時刻を取得できる。また、トラフィック情報から、アドレス、ポート番号、ペイロード中に含まれるデータパターン、トラフィックの振る舞いを取得することによって、アプリケーションを特定することができる。
【０００７】
これらを組み合わせた分析、つまりシグナリングを発生させたアプリケーションを特定しようとすると、シグナリング情報とトラフィック情報とを一つのプローブに入力する必要がある。しかし、ＬＴＥでは、シグナリングとトラフィックとは完全に分離されているため、同一端末のシグナリング情報とトラフィック情報とを一つのプローブに入力することは困難である。
【０００８】
このため、セルラ通信システム全体で、シグナリングを発生させたアプリケーションを特定し、可視化する技術が求められている。
【課題を解決するための手段】
【０００９】
本願において開示される発明の代表的な一例を示せば以下の通りである。すなわち、ネットワークと端末との間の接続要求に関する制御信号を監視し、受信ログを生成する第一の監視装置と、ユーザデータを転送するゲートウェイ装置に入出力されるパケットを監視し、前記パケットをセッション毎に分け、前記セッションを生成するアプリケーションの種別を特定し、前記アプリケーションの種別を含むセッションログを生成する第二の監視装置と、前記第一の監視装置が生成した受信ログと、前記第二の監視装置が生成したセッションログとを取得し、前記受信ログの発生時刻、前記セッションログの発生時刻及び前記端末の識別子を用いて前記受信ログと前記セッションログとを関連付け、前記制御信号を発生させたセッションに関連するアプリケーションを特定するトラフィック管理サーバと、を備える。
【発明の効果】
【００１０】
本発明の代表的な形態によれば、シグナリングを発生させるアプリケーションを特定することができる。前述した以外の課題、構成及び効果は、以下の実施例の説明により明らかにされる。
【図面の簡単な説明】
【００１１】
【図１】本発明の第一の実施例のセルラ通信システムの構成を示す図である。
【図２】本発明の第一の実施例のパケット詳細解析装置（ＣＰ−ＤＰＩ）の構成を示す図である。
【図３】本発明の第一の実施例のユーザ情報管理テーブルの構成例を示す図である。
【図４】本発明の第一の実施例のシグナリングレコード出力ファイルの構成例を示す図である。
【図５】本発明の第一実施例のユーザ情報更新処理のフローチャートである。
【図６】本発明の第一の実施例のシグナリングレコード生成処理のフローチャートである。
【図７】本発明の第一の実施例のレコード出力処理のフローチャートである。
【図８】本発明の第一の実施例のパケット詳細解析装置（ＵＰ−ＤＰＩ）の構成を示す図である。
【図９】本発明の第一の実施例において、ＵＰ−ＤＰＩからトラフィック管理サーバへ送信されるセッションレコードに含まれる情報を示す図である。
【図１０】本発明の第一の実施例のセッションレコード管理処理のフローチャートである。
【図１１】本発明の第一の実施例のトラフィック管理サーバの構成を示す図である。
【図１２】本発明の第一の実施例の関連付け済レコード管理テーブルの構成例を示す図である。
【図１３】本発明の第一の実施例の接続アプリ統計レコード管理テーブルの構成例を示す図である。
【図１４】本発明の第一の実施例のレコード関連付け処理のフローチャートである。
【図１５】本発明の第一の実施例の統計処理プログラムのフローチャートである。
【図１６】本発明の第一の実施例の統計出力表示プログラムにより作成される画面の一例を示す図である。
【図１７】本発明の第二の実施例のレコード出力処理のフローチャートである。
【図１８】本発明の第三の実施例のレコード出力処理のフローチャートである。
【図１９】本発明の第四の実施例のセルラ通信システムの構成を示す図である。
【図２０】本発明の第四の実施例のパケット詳細解析装置（ＵＰ−ＤＰＩ）の構成を示す図である。
【図２１】本発明の第四の実施例のユーザ情報管理テーブルの構成例を示す図である。
【図２２】本発明の第四の実施例のセッションレコードの構成例を示す図である。
【図２３】本発明の第四の実施例における、ＵＰ−ＤＰＩにて管理するユーザの接続状態の遷移図である。
【図２４】本発明の第四の実施例のユーザ情報更新処理のフローチャートである。
【図２５】本発明の第四の実施例のセッションラベリング処理のフローチャートである。
【図２６】本発明の第四の実施例のレコード関連付け処理のフローチャートである。
【図２７】本発明の第五の実施例のレコード出力処理のフローチャートである。
【発明を実施するための形態】
【００１２】
以下、本発明の実施例を図面に基づいて詳細に説明する。
【００１３】
なお、以下の実施例において、説明の便宜上必要があるときは、複数のセクションまたは実施例に分割して説明するが、特に明示した場合を除き、それらはお互いに無関係なものではなく、一方は他方の一部又は全部の変形例、詳細、補足説明などの関係にある。
【００１４】
また、以下の実施例において、要素の数等（個数、数値、量、範囲等を含む）に言及する場合、特に明示した場合及び原理的に明らかに特定の数に限定される場合などを除き、その特定の数に限定されるものではなく、特定の数以上でも以下でもよいものとする。
【００１５】
さらに、以下の実施例において、その構成要素（要素ステップなどを含む）は、特に明示した場合及び原理的に明らかに必須であると考えられる場合などを除き、必ずしも必須のものではないことは言うまでもない。
【００１６】
本実施例では、セルラ通信システムの例として３ＧＰＰで標準化されているＬＴＥを用い、シグナリングを発生させた要因となるアプリケーション情報を取得するトラフィック管理システムの実施例を示す。
【実施例１】
【００１７】
図１は、第一の実施例のセルラ通信システムの構成を示す図である。
【００１８】
第一の実施例のセルラ通信システムは、基地局装置であるｅＮｏｄｅＢ１１１、ゲートウェイ装置であるＳ−ＧＷ１３１、Ｐ−ＧＷ１３３、通信制御装置であるＭＭＥ１３２、パケット詳細解析装置であるＵＰ−ＤＰＩ１４１、ＣＰ−ＤＰＩ１４２、及び、トラフィック管理サーバ１４３を有する。ｅＮｏｄｅＢ１１１には、ユーザ端末であるＵＥ１０１が接続される。
【００１９】
Ｓ−ＧＷ１３１は、ユーザプレーンのトラフィック転送機能を有する。ＭＭＥ１３２は、ＵＥ１０１のモビリティを管理する装置であり、制御プレーンのシグナリングを送受信する。Ｐ−ＧＷ１３３は、ユーザへのサービスを提供するＰＤＮ１３４とのインタフェースを有する。Ｓ−ＧＷ１３１、ＭＭＥ１３２及びＰ−ＧＷ１３３は互いに接続されており、コアネットワーク（ＥＰＣ）１１５を構成する。
【００２０】
パケット詳細解析装置１４１、１４２は、ネットワーク上のパケットを取得する装置であり、ｅＮｏｄｅＢ１１１、Ｓ−ＧＷ１３１、ＭＭＥ１３２、Ｐ−ＧＷ１３３などのネットワークノード間、及びＰ−ＧＷ１３３とＰＤＮ１３４の間で送受信されるトラフィック又はシグナリングを取得する。パケット詳細解析装置１４１、１４２は、取得したトラフィック又はシグナリングの情報を、トラフィック管理サーバ１４３へ送信する。トラフィック管理サーバ１４３は、パケット詳細解析装置１４１、１４２から取得した情報を用いて、シグナリングを発生させた要因となるアプリケーションの情報を取得する。
【００２１】
本実施例では、ＵＰ−ＤＰＩ１４１はＳ−ＧＷ毎に設置され、リファレンスポイントＳ１−Ｕ及びＳ１１で転送されるトラフィックを取得する。ＣＰ−ＤＰＩ１４２はＭＭＥ毎に設置され、リファレンスポイントＳ１−ＭＭＥ、ＮＡＳ、Ｓ６ａ、Ｓ１０、Ｓ１１で転送されるトラフィックを取得する。以下の説明では、これらのリファレンスポイントでトラフィックを取得する場合について説明する。ただし、一つのＵＰ−ＤＰＩ１４１が複数のＳ−ＧＷ１３１を収容してもよいし、複数のＵＰ−ＤＰＩ１４１が一つのＳ−ＧＷ１３１を収容してもよい。同様に、一つのＣＰ−ＤＰＩ１４２が複数のＭＭＥ１３２を収容してもよいし、複数のＣＰ−ＤＰＩ１４２が一つのＭＭＥ１３２を収容してもよい。
【００２２】
また、ＵＰ−ＤＰＩ１４１及びトラフィック管理サーバ１４３が一つの計算機に収容されてもよい。同様に、ＣＰ−ＤＰＩ１４２及びトラフィック管理サーバ１４３が一つの計算機に収容されてもよい。
【００２３】
図２は、第一の実施例のパケット詳細解析装置（ＣＰ−ＤＰＩ）１４２の構成を示す図である。
【００２４】
ＣＰ−ＤＰＩ１４２の機能は、一般的なコンピュータの補助記憶装置２０２にプログラム（ソフトウェア）の形で格納され、ＣＰＵ２０４が、補助記憶装置２０２から読み出したプログラムをメモリ上に展開して、実行する。ＣＰ−ＤＰＩ１４２は、ネットワークＩ／Ｆ２０５を介して、各リファレンスポイントで転送されるトラフィックを取得し、トラフィック管理サーバ１４３と通信する。ＣＰ−ＤＰＩ１４２のメモリ２０３は、ユーザ情報更新処理プログラム２１１及びシグナリングレコード生成処理プログラム２１２を格納する。さらに、ＣＰ−ＤＰＩ１４２のメモリ２０３は、ユーザ情報管理テーブル２２１（図３参照）及びシグナリングレコード出力ファイル２２２（図４参照）を格納する。
【００２５】
ＣＰＵ２０４が実行するプログラムは、リムーバブルメディア（ＣＤ−ＲＯＭ、フラッシュメモリなど）又はネットワークを介してＣＰ−ＤＰＩ１４２に提供され、非一時的記憶媒体である補助記憶装置２０２に格納される。このため、ＣＰ−ＤＰＩ１４２は、リムーバブルメディアからデータを読み込むインタフェースを有するとよい。
【００２６】
ＣＰ−ＤＰＩ１４２は、物理的に一つの計算機上で、又は、論理的又は物理的に複数の計算機上で構成される計算機システムであり、前述したプログラムが、同一の計算機上で別個のスレッドで動作してもよく、複数の物理的計算機資源上に構築された仮想計算機上で動作してもよい。
【００２７】
第一の実施例のＣＰ−ＤＰＩ１４２の特徴の概略を簡単に説明すれば、以下の通りである。すなわち、ＣＰ−ＤＰＩ１４２は、ＭＭＥ１３２に入出力されるシグナリングトラフィックを取得し、ネットワークへの接続を要求するシグナリングを抽出し、シグナリングに関与するＵＥ１０１を特定する。そして、ＣＰ−ＤＰＩ１４２は、接続を要求するＵＥ１０１とシグナリング種別とを含む受信ログであるシグナリングレコードを生成し、生成したシグナリングレコードをトラフィック管理サーバ１４３へ送信する。
【００２８】
図３は、第一の実施例のユーザ情報管理テーブル２２１の構成例を示す図である。
【００２９】
ユーザ情報管理テーブル２２１は、各ＵＥ１０１について、当該ＵＥ１０１を収容するネットワーク機器及び各リファレンスポイントで該当ＵＥ１０１を識別するためのユーザ識別子を格納する。具体的には、ユーザ情報管理テーブル２２１は、ＵＥ１０１を一意に識別するためのＩＭＳＩと、各リファレンスポイントで該当ＵＥ１０１を識別するためのユーザ識別子３０２と、ＤＤＮ受信時刻３０３とを含む。ユーザ識別子３０２は、ＧＵＴＩ、ＭＭＥ  ＵＥ  Ｓ１ＡＰ  ＩＤ、ｅＮＢ  ＵＥ  Ｓ１ＡＰ  ＩＤ、Ｓ１１  ＭＭＥ  Ｆ−ＴＥＩＤ、Ｓ１１  Ｓ−ＧＷ  Ｆ−ＴＥＩＤ、Ｓ１０  ＭＭＥ  Ｆ−ＴＥＩＤ、ＵＥ  ＩＰ  Ａｄｄｒｅｓｓ  ＋  Ｐ−ＧＷ  ＩＰ  Ａｄｄｒｅｓｓ、Ｓ１−Ｕ  Ｓ−ＧＷ  Ｆ−ＴＥＩＤ、Ｓ１−Ｕ  ｅＮＢ  Ｆ−ＴＥＩＤ等である。Ｆ−ＴＥＩＤは、ＩＰアドレスとトンネルの識別子であるＴＥＩＤを含む。ＤＤＮ受信時刻３０３は、該当ＵＥに関してＳ１１で転送されるシグナリング「Ｄｏｗｎｌｉｎｋ  Ｄａｔａ  Ｎｏｔｉｆｉｃａｔｉｏｎ（ＤＤＮ）」を受信した時刻を格納する。
【００３０】
図４は、第一の実施例のシグナリングレコード出力ファイル２２２の構成例を示す図である。
【００３１】
シグナリングレコード出力ファイル２２２は、ＣＰ−ＤＰＩ１４２からトラフィック管理サーバ１４３へ送信するシグナリングレコードに含まれる情報を格納する。具体的には、シグナリングレコード出力ファイル２２２は、時刻４０１と、ＩＭＳＩ４０２と、シグナリング種別４０３と、シグナリング再送数４０４と、Ｕｓｅｒ  Ｌｏｃａｔｉｏｎ４０５と、Ｕ−ＰｌａｎｅユーザＩＤ４０６と、収容ノード（Ｓ−ＧＷ及びＭＭＥのＩＰ  Ａｄｄｒｅｓｓ又は一意に識別するためのＩＤ）とを含む。
【００３２】
シグナリングレコード出力ファイル２２２は、ＵＥ１０１のネットワークへの接続要求に関するシグナリングの受信ログを記録する。時刻４０１は、シグナリング受信時刻を格納する。シグナリング種別４０３は、例えば、ＳＲＭＯ（Ｓｅｒｖｉｃｅ  Ｒｅｑｕｅｓｔ−Ｍｏｂｉｌｅ  Ｏｒｉｇｉｎａｔｅｄ）や、ＳＲＭＴ（Ｓｅｒｖｉｃｅ  Ｒｅｑｕｅｓｔ−Ｍｏｂｉｌｅ  Ｔｅｒｍｉｎａｔｅｄ）、ＥＳＲＭＯ−ＰＳ（Ｅｘｔｅｎｄｅｄ  Ｓｅｒｖｉｃｅ  Ｒｅｑｕｅｓｔ−Ｍｏｂｉｌｅ  Ｏｒｉｇｉｎａｔｅｄ、Ｎｏｎ−ＣＳＦＢ）等を格納する。Ｕｓｅｒ  Ｌｏｃａｔｉｏｎ４０５は、シグナリング送信時のＵＥの位置、例えばＥＣＧＩ、ｅＮＢ  ＩＤ等を格納する。Ｕ−ＰｌａｎｅユーザＩＤ４０６は、ＵＥ  ＩＰ  Ａｄｄｒｅｓｓ（ＰＤＮ  Ａｌｌｏｃａｔｉｏｎ）＋Ｐ−ＧＷ  ＩＰ  Ａｄｄｒｅｓｓ、又は、Ｓ１−Ｕ  Ｆ−ＴＥＩＤ（Ｓ−ＧＷ又はｅＮＢ）を格納する。収容ノード４０７は、該当ＵＥを収容するＳ−ＧＷ及びＭＭＥのＩＰ  Ａｄｄｒｅｓｓ又はＳ−ＧＷ及びＭＭＥを一意に識別するためのＩＤを格納する。
【００３３】
図５は、第一実施例のユーザ情報更新処理のフローチャートである。図５に示すユーザ情報更新処理は、ＣＰ−ＤＰＩ１４２のＣＰＵ２０４がユーザ情報更新処理プログラム２１１を実行することによって行われる。
【００３４】
ユーザ情報更新処理プログラム２１１は、シグナリングを受信すると実行され、ユーザ情報管理テーブル２２１に格納されるユーザ識別子３０２を登録及び更新し、ＤＤＮ受信時にＤＤＮ受信時刻３０３を登録する。
【００３５】
まず、ＣＰ−ＤＰＩ１４２のＣＰＵ２０４は、ユーザ情報管理テーブル２２１を参照して、受信したシグナリングに関連する対象ＵＥ１０１を検索し（ステップ５０１）、検索によってＵＥ１０１を特定できたかを判定する（ステップ５０２）。
【００３６】
ＵＥ１０１がユーザ情報管理テーブル２２１に登録されていない場合、ＵＥ１０１を特定できないと判定し、該当シグナリングでユーザ識別子を登録するかを判定する（ステップ５０３）。ユーザ識別子を登録する場合、ＩＭＳＩ及びユーザ識別子をユーザ情報管理テーブル２２１に登録し（ステップ５０４）、以降の処理（ステップ５２１）を実行する。ステップ５０３において、該当シグナリングでユーザ識別子を登録しない場合、処理を終了する。
【００３７】
ステップ５０２において、ユーザ情報管理テーブル２２１に該当ＵＥ１０１の情報が登録されている場合、ＵＥ１０１を特定できると判定し、該当シグナリングでユーザ識別子を更新するかを判定する（ステップ５１１）。ユーザ識別子を更新する場合、ユーザ情報管理テーブル２２１内の情報を更新し（ステップ５１２）、以降の処理（ステップ５２１）を実行する。
【００３８】
その後、ＤＤＮ受信時刻の更新処理を実行する。すなわち、ステップ５２１で、該当シグナリングがＤＤＮであるか否かを判定する。そして、該当シグナリングがＤＤＮである場合、受信時刻をユーザ情報管理テーブル２２１に格納し（ステップ５２２）、処理を終了する。一方、該当シグナリングがＤＤＮでない場合、処理を終了する。
【００３９】
なお、ユーザ情報の登録及び更新に関するシグナリングとは、ユーザ情報管理テーブル２２１に格納される各識別子の対応関係を更新するためのシグナリングであり、ＡＴＴＡＣＨや、Ｃｒｅａｔｅ  Ｓｅｅｓｉｏｎ  Ｒｅｑｕｅｓｔ等がある。
【００４０】
図６は、第一の実施例のシグナリングレコード生成処理のフローチャートである。図６に示すシグナリングレコード生成処理は、ＣＰ−ＤＰＩ１４２のＣＰＵ２０４がシグナリングレコード生成処理プログラム２１２を実行することによって行われる。
【００４１】
シグナリングレコード生成処理プログラム２１２は、ユーザ情報更新処理プログラム２１１の実行後に実行され、シグナリングの受信ログであるシグナリングレコードを生成する。
【００４２】
まず、ＣＰ−ＤＰＩ１４２のＣＰＵ２０４は、ログ出力対象のシグナリングであるか判定する（ステップ６０１）。シグナリングがログ出力対象でない場合、処理を終了する。一方、シグナリングがログ出力対象である、すなわち、ＳＲ（Ｓｅｒｖｉｃｅ  Ｒｅｑｕｅｓｔ）や、ＥＳＲ（Ｅｘｔｅｎｄｅｄ  Ｓｅｒｖｉｃｅ  Ｒｅｑｕｅｓｔ）等を受信した場合、続いてステップ６０２、６０３、６０４で再送カウントの処理、ステップ６０５でシグナリングレコード生成処理、ステップ６０６でシグナリングレコード出力処理を行う。
【００４３】
具体的には、ステップ６０２で再送タイマが起動中かを判定する。ステップ６０２で用いる再送タイマは、該当ＵＥ１０１の同一シグナリング受信時に起動した（前回のステップ６０４で起動した）タイマであり、再送タイマが起動している場合（ステップ６０２）、再送カウントをカウントアップする（ステップ６０３）。
【００４４】
続いて、ステップ６０４で、再送タイマを起動し、ステップ６０５でユーザ情報管理テーブル２２１等から情報を取得し、シグナリングレコードを生成する。シグナリングレコードの生成では、シグナリング種別を特定する。例えば、ＳＲのシグナリングを受信した場合、ユーザ情報管理テーブル２２１のＤＤＮ受信時刻３０３を参照し、ＤＤＮが所定時間内に発生した場合、ＳＲＭＴである判定する。一方、ＤＤＮが所定時間内に発生していない場合、ＳＲＭＯである判定する。
【００４５】
最後に、ステップ６０６で、シグナリングレコード出力処理を実行し、処理を終了する。ステップ６０６のシグナリングレコード出力処理の詳細は、図７を用いて後述する。
【００４６】
図７は、第一の実施例のレコード出力処理のフローチャートである。図７に示すレコード出力処理は、ＣＰ−ＤＰＩ１４２がシグナリングレコードを出力する際、及び、ＵＰ−ＤＰＩ１４１がセッションレコードを出力する際に、ＣＰ−ＤＰＩ１４２又はＵＰ−ＤＰＩ１４１のＣＰＵ２０４がシグナリングレコード生成処理プログラム２１２を実行することによって行われる。
【００４７】
シグナリングレコードは、ＵＥ１０１を収容するＳ−ＧＷ１３１及びＭＭＥ１３２の組毎に異なるファイルに分けられて管理され、出力される。
【００４８】
具体的には、まず、ＣＰ−ＤＰＩ１４２のＣＰＵ２０４は、シグナリングレコード内に記載されるＳ−ＧＷ及びＭＭＥのＩＰ  Ａｄｄｒｅｓｓ（又は、それぞれのＩＤ）を抽出し（ステップ７０１）、抽出したＳ−ＧＷ及びＭＭＥの組毎にシグナリングレコードを出力するファイルを決定し、シグナリングレコードをファイルへ出力する（ステップ７０２）。そして、Ｓ−ＧＷ及びＭＭＥの組毎に作成したシグナリングレコードファイルを処理するトラフィック管理サーバ１４３を、Ｓ−ＧＷ及びＭＭＥの組をキーとして決定し、決定したトラフィック管理サーバ１４３にシグナリングレコードファイルを転送する（ステップ７０３）。
【００４９】
レコード出力処理は、セッションレコード管理処理プログラム８１１からも呼び出され（図１０の１００９）、ＵＰ−ＤＰＩ１４１のセッションレコードを出力する。この場合、フローチャート中の「シグナリングレコード」を「セッションレコード」と読み替える。
【００５０】
セッションレコードは、ＵＥ１０１を収容するＳ−ＧＷ１３１及びＭＭＥ１３２の組毎に異なるファイルに分けられて管理され、出力される。
【００５１】
具体的には、まず、ＵＰ−ＤＰＩ１４１のＣＰＵ２０４は、セッションレコード内に格納されるＳ−ＧＷ及びＭＭＥのＩＰ  Ａｄｄｒｅｓｓ（又は、それぞれのＩＤ）を抽出し（ステップ７０１）、抽出したＳ−ＧＷ及びＭＭＥの組毎にセッションレコードを出力するファイルを決定し、セッションレコードをファイルへ出力する（ステップ７０２）。そして、Ｓ−ＧＷ及びＭＭＥの組毎に作成したセッションレコードファイルを処理するトラフィック管理サーバ１４３を、Ｓ−ＧＷ及びＭＭＥの組をキーとして決定し、決定したトラフィック管理サーバ１４３にセッションレコードファイルを転送する（ステップ７０３）。
【００５２】
なお、ステップ７０３のファイル転送処理は、周期的に実行すればよく、一定数のレコードを蓄積したタイミングで、所定の時間間隔で、他の条件を満たすタイミングで実行してもよい。また、パケット詳細解析装置１４１、１４２がファイルの蓄積のみを行い、トラフィック管理サーバ１４３がファイルを転送してもよい。
【００５３】
なお、シグナリングレコード及びセッションレコードをＳ−ＧＷ１３１及びＭＭＥ１３２の組毎に異なるファイルに分けて出力する例について説明したが、ＵＰ−ＤＰＩ１４１及びＣＰ−ＤＰＩ１４２が、Ｓ−ＧＷ１３１及びＭＭＥ１３２の組に分けてシグナリングレコード及びセッションレコードを処理できる形式であれば、前述したものと別の形式でシグナリングレコード及びセッションレコードを出力してもよい。
【００５４】
図８は、第一の実施例のパケット詳細解析装置（ＵＰ−ＤＰＩ）１４１の構成を示す図である。
【００５５】
ＵＰ−ＤＰＩ１４１の機能は、一般的なコンピュータの補助記憶装置２０２にプログラム（ソフトウェア）の形で格納され、ＣＰＵ２０４が、補助記憶装置２０２から読み出したプログラムをメモリ上に展開して、実行する。ＵＰ−ＤＰＩ１４１は、ネットワークＩ／Ｆ２０５を介して、各リファレンスポイントで転送されるトラフィックを取得し、トラフィック管理サーバ１４３と通信する。ＵＰ−ＤＰＩ１４１のメモリ２０３は、ユーザ情報更新処理プログラム２１１及びセッションレコード管理処理プログラム８１１を格納する。さらに、ＵＰ−ＤＰＩ１４１のメモリ２０３は、ユーザ情報管理テーブル２２１（図３参照）、セッションレコード管理テーブル８２１（図９参照）及びセッションレコード出力ファイル８２２（図９参照）を格納する。
【００５６】
ＣＰＵ２０４が実行するプログラムは、リムーバブルメディア（ＣＤ−ＲＯＭ、フラッシュメモリなど）又はネットワークを介してＵＰ−ＤＰＩ１４１に提供され、非一時的記憶媒体である補助記憶装置２０２に格納される。このため、ＵＰ−ＤＰＩ１４１は、リムーバブルメディアからデータを読み込むインタフェースを有するとよい。
【００５７】
ＵＰ−ＤＰＩ１４１は、物理的に一つの計算機上で、又は、論理的又は物理的に複数の計算機上で構成される計算機システムであり、前述したプログラムが、同一の計算機上で別個のスレッドで動作してもよく、複数の物理的計算機資源上に構築された仮想計算機上で動作してもよい。
【００５８】
第一の実施例のＵＰ−ＤＰＩ１４１の特徴の概略を簡単に説明すれば、以下の通りである。すなわち、ＵＰ−ＤＰＩ１４１は、Ｓ１−Ｕで転送されるユーザトラフィックを取得し、ユーザトラフィックをＵＥ１０１毎かつセッション毎に分類し、各セッションのアプリケーションを特定し、セッションの情報とＵＥ１０１が収容されるノードの情報とを含むセッションレコードを生成し、生成したセッションレコードをトラフィック管理サーバ１４３へ送信する。
【００５９】
なお、ユーザ情報更新処理プログラム２１１とユーザ情報管理テーブル２２１は、ＣＰ−ＤＰＩに実装されるものと同一である。ただし、ＵＰ−ＤＰＩは、取得するリファレンスポイントがＳ１−ＵとＳ１１であり、ＧＵＴＩやＳ１ＡＰ、Ｓ１０に関する情報を除いた構成をとる。
【００６０】
図９は、第一の実施例において、ＵＰ−ＤＰＩ１４２からトラフィック管理サーバ１４３へ送信されるセッションレコードに含まれる情報を示す図である。すなわち、図９は、セッションレコード管理テーブル８２１及びセッションレコード出力ファイル８２２内に含まれる情報を示す。
【００６１】
セッションレコード管理テーブル８２１は、継続中のセッションに関する情報を保持し、ユーザトラフィックが到着すると、検索及び更新されるテーブルである。セッションレコード出力ファイル８２２は、終了したセッション又はアプリケーション特定済のセッションに関する情報を保持する。
【００６２】
セッションレコードは、ＩＭＳＩ９０１と、該当ＵＥ１０１を収容する収容ノードの情報９０２と、該当ＵＥ１０１が通信したセッションの情報９０３とを含む。収容ノードの情報９０２には、ｅＮＢ、ＭＭＥ及びＳ−ＧＷのＩＰ  Ａｄｄｒｅｓｓ又はＩＤが格納される。セッション情報９０３は、セッションの開始時刻、終了時刻、通信開始向きに関する情報を含む。通信開始向きは、該当セッションのうち最初に受信したパケットの送信元によって、ＵＥ発かサーバ発かを判定して記録する。また、セッション情報９０３は、セッションを識別するための情報として、ＵＥ側のポート番号、サーバ側のＩＰアドレス、もしくはホスト名やドメイン名、サーバ側のポート番号を含む。さらに、セッション情報９０３は、該当セッションのアプリケーションに関する情報（アプリケーションＩＤ、カテゴリ、メタデータ）を含む。他に、セッション情報９０３は、転送パケット数やバイト数等の情報を含んでもよい。
【００６３】
図１０は、第一の実施例のセッションレコード管理処理のフローチャートである。図１０に示すセッションレコード管理処理は、ＵＰ−ＤＰＩ１４１のＣＰＵ２０４がセッションレコード管理処理プログラム８１１を実行することによって行われる。
【００６４】
セッションレコード管理処理プログラム８１１は、Ｓ１−Ｕでユーザパケットを受信すると実行され、セッションレコード管理テーブル８２１のセッションの情報を登録及び更新し、セッション終了時にはセッションレコード出力ファイル８２２へ出力するプログラムである。
【００６５】
まず、ＵＰ−ＤＰＩ１４１のＣＰＵ２０４は、ユーザ情報管理テーブル２２１を参照して、受信したユーザパケットに関連する対象ユーザ（ＩＭＳＩ）を特定し（ステップ１００１）、ＩＭＳＩと、Ｓ１−Ｕのユーザパケットに含まれる５ｔｕｐｌｅ（送信元ＩＰアドレス、宛先ＩＰアドレス、送信元ポート番号、宛先ポート番号、プロトコル番号）とからセッションを特定し、特定されたセッションの情報を用いてセッションレコード管理テーブル８２１を検索する（ステップ１００２）。そして、該当セッションに関する情報がセッションレコード管理テーブル８２１内に含まれているかによって、該当セッションが新規セッションであるかを判定する（ステップ１００３）。
【００６６】
該当セッションの情報を検索できなかった場合、該当セッションが新規セッションであると判定し、セッションを新規に登録する（ステップ１００４）。セッションを新規に登録する処理は、該当セッションの情報をセッションレコード管理テーブル８２１に格納する。具体的には、ユーザ情報管理テーブル２２１から収容ノード情報を取得し、受信したユーザパケットのセッション情報のユーザ情報、サーバ情報、開始向き取得し、取得した情報を格納する。また、パケット取得時刻を開始時刻に格納する。
【００６７】
一方、ステップ１００３で、該当セッションの情報を検索できた場合、該当セッションが新規セッションではないと判定し、セッションの情報を更新する（ステップ１００４）。セッションの情報を更新する処理は、終了時刻のアップデート、転送パケット数・バイト数の加算などである。続いて、ステップ１００６、１００７でアプリケーションを識別する処理を行う。具体的には、アプリケーション情報がセッションレコード管理テーブル８２１に格納されているかによって、アプリケーションが既に識別されているかを判定する（ステップ１００６）。そして、アプリケーション情報がセッションレコード管理テーブル８２１に格納されていない場合、アプリケーションが未識別であると判定し、ユーザパケットを用いてアプリケーションの識別処理を行う（ステップ１００７）。一方、アプリケーション情報がセッションレコード管理テーブル８２１に格納されている場合、ステップ１００６でアプリケーションを識別できるので、識別結果をセッションレコード中のアプリケーション情報に格納する。なお、ステップ１００７のアプリケーション識別処理は、専用のアプリケーション識別プログラムを用いてもよい。
【００６８】
最後に、ステップ１００８、１００９でセッションレコードを出力する処理を行う。ステップ１００８における出力条件は、例えば、アプリケーションが識別済である、ＦＩＮパケット等のセッション終了メッセージを受信済である等の条件がある。また、ステップ１００９のセッションレコード出力処理は、図７にて説明したレコード出力処理である。
【００６９】
図１１は、第一の実施例のトラフィック管理サーバ１４３の構成を示す図である。
【００７０】
トラフィック管理サーバ１４３の機能は、一般的なコンピュータの補助記憶装置２０２にプログラム（ソフトウェア）の形で格納され、ＣＰＵ２０４が、補助記憶装置２０２から読み出したプログラムをメモリ上に展開して、実行する。トラフィック管理サーバ１４３は、ネットワークＩ／Ｆ２０５を介して、ＣＰ−ＤＰＩ１４２及びＵＰ−ＤＰＩ１４１と通信する。トラフィック管理サーバ１４３のメモリ２０３は、レコード関連付け処理プログラム１１０１、統計処理プログラム１１０２及び統計出力表示プログラム１１０３を格納する。さらに、トラフィック管理サーバ１４３のメモリ２０３は、関連付け済レコード管理テーブル１１１１（図１２参照）及び接続アプリ統計レコード管理テーブル１１１２（図１３参照）を格納する。
【００７１】
ＣＰＵ２０４が実行するプログラムは、リムーバブルメディア（ＣＤ−ＲＯＭ、フラッシュメモリなど）又はネットワークを介してトラフィック管理サーバ１４３に提供され、非一時的記憶媒体である補助記憶装置２０２に格納される。このため、トラフィック管理サーバ１４３は、リムーバブルメディアからデータを読み込むインタフェースを有するとよい。
【００７２】
トラフィック管理サーバ１４３は、物理的に一つの計算機上で、又は、論理的又は物理的に複数の計算機上で構成される計算機システムであり、前述したプログラムが、同一の計算機上で別個のスレッドで動作してもよく、複数の物理的計算機資源上に構築された仮想計算機上で動作してもよい。
【００７３】
第一の実施例のトラフィック管理サーバ１４３の特徴の概略を簡単に説明すれば、以下の通りである。すなわち、トラフィック管理サーバ１４３は、ＣＰ−ＤＰＩ１４２からシグナリングレコードを取得し、ＵＰ−ＤＰＩ１４１からセッションレコードを取得し、シグナリングレコードとセッションレコードとを関連付けて統計化することによって、シグナリングを発生させた要因となるアプリケーション情報を可視化する。
【００７４】
図１２は、第一の実施例の関連付け済レコード管理テーブル１１１１の構成例を示す図である。
【００７５】
関連付け済レコード管理テーブル１１１１は、ＩＭＳＩ及び時刻情報を用いて、シグナリングレコード及びセッションレコードをマージしたテーブルである。具体的には、関連付け済レコード管理テーブル１１１１は、シグナリングレコードの情報をシグナリング情報１２０２に格納し、セッションレコードの情報を収容ノード１２０３及びセッション情報１２０４に格納したテーブルである。セッション情報１２０４には、新たに関連付け対象フラグ１２２１を設け、該当セッションに関連付けられるシグナリングがあるか否かを示す情報を格納する。また、セッション情報１２０４は、当該セッションを収容するサーバの情報１２１１及び当該セッションに関連するアプリケーションの情報１２１２を含む。
【００７６】
図１３は、第一の実施例の接続アプリ統計レコード管理テーブル１１１２の構成例を示す図である。
【００７７】
接続アプリ統計レコード管理テーブル１１１２は、関連付け済レコードについて統計処理した結果を格納するテーブルであり、本実施例では、関連付け済レコードから統計集約する項目として、シグナリング情報１３０２から種別及びＵｓｅｒ  Ｌｏｃａｔｉｏｎを、セッション情報１３０３のサーバ情報からドメイン、ホスト、ポート番号を、セッション情報１３０３のアプリケーション情報からカテゴリ、ＩＤ、メタデータを時刻１３０１に関連付けて格納した例を示す。そして、統計集約項目が全て一致するレコードの統計情報を統計情報１３０４へ格納する。なお、統計集約項目は、項目のデータが「任意」でよいことを表す「＊」を含めてもよい。例えば、１行目のエントリでは、所定の時間ｔ（Ｔ１≦ｔ＜Ｔ１＋α）において、アプリケーションＡｐｐ１によって、サーバホストＩＰ１へ接続するために送信されたと推定されるＵＥ発の接続要求（ＳＲＭＯ）が１００回あり、この接続要求のユニークなＵＥ１０１の数は９０であることを示している。ここで、αは統計を集約する期間である。
【００７８】
図１４は、第一の実施例のレコード関連付け処理のフローチャートである。図１４に示すレコード関連付け処理は、トラフィック管理サーバ１４３のＣＰＵ２０４がレコード関連付け処理プログラム１１０１を実行することによって行われる。
【００７９】
レコード関連付け処理プログラム１１０１は、ＣＰ−ＤＰＩ１４１からシグナリングレコードを受信すると、又は、ＵＰ−ＤＰＩ１４２からセッションレコードを受信すると実行される。シグナリングレコード及びセッションレコードは、Ｓ−ＧＷ及びＭＭＥの組毎のファイルとなっているため、Ｓ−ＧＷ及びＭＭＥの組毎にレコードファイルを取得し、関連付け処理を実行する。
【００８０】
具体的には、まず、トラフィック管理サーバ１４３のＣＰＵ２０４は、セッションレコードからエントリを取得し、各エントリについてステップ１４０２からステップ１４０７の処理を繰り返し実行する（ステップ１４０１）。
【００８１】
ループ内では、該当エントリのＩＭＳＩ及びセッション開始時刻を検索キーとして取得し（ステップ１４０２）、取得した検索キーを用いてシグナリングレコードを検索する（ステップ１４０３）。セッション開始時刻の検索フィールドは、シグナリングレコードの「時刻」であり、セッション開始時刻から前後の所定時間の幅を定め、その幅に含まれるシグナリングレコードを検索する。この検索によって、シグナリングレコードが検出された場合（ステップ１４０４）、シグナリングレコードの情報「時刻」、「シグナリング種別」、「シグナリング再送数」、「Ｕｓｅｒ Ｌｏｃａｔｉｏｎ」を該当セッションレコードのエントリにマージし、関連付け対象フラグ１２２１を「１」にセットし（ステップ１４０５）、関連付け済レコード管理テーブル１１１１に登録する（ステップ１４０７）。
【００８２】
一方、ステップ１４０４において、シグナリングレコードが検出されなかった場合、シグナリングレコードの情報はブランクのまま、セッションレコードの関連付け対象フラグ１２２１を「０」にセットし、関連付け済レコード管理テーブル１１１１に登録する（ステップ１４０７）。
【００８３】
そして、全てのセッションレコードのエントリについて処理を実行した後に処理を終了する。
【００８４】
図１５は、第一の実施例の統計処理のフローチャートである。図１５に示す統計処理は、トラフィック管理サーバ１４３のＣＰＵ２０４が統計処理プログラム１１０２を実行することによって行われる。
【００８５】
統計処理プログラム１１０２は、関連付け済レコードを入力とし、定期的に実行され、シグナリングを発生させたアプリケーションの情報を統計化する。統計集約期間はオペレータが任意に設定可能である。統計集約期間内に生成された全てのシグナリングレコードとセッションレコードとを関連付け処理をしたものを、入力する関連付け済レコードとする。なお、統計処理では、処理の実行前に集約項目リスト及び出力条件を設定する。集約項目リストとは、接続アプリ統計レコード管理テーブル１１１２に含まれるフィールドから任意のフィールドを選択した集約項目のリストである。例えば、集約項目Ｘ１（時刻、シグナリング種別、ドメイン、ホスト）、集約項目Ｘ２（時刻、シグナリング種別、ホスト、アプリケーションＩＤ）等となる。出力条件とは、接続アプリ統計レコード管理テーブル１１１２へ出力する条件である。例えば、統計値が一定値以上である、集約項目のあるフィールドが特定の値である、というような条件である。
【００８６】
具体的には、まず、トラフィック管理サーバ１４３のＣＰＵ２０４は、関連付け済レコードを取得し、関連付け対象フラグ１２２１に「１」がセットされているエントリを抽出する（ステップ１５０１）。次に、事前に設定した集約項目Ｘｉのリストを取得する（ステップ１５０２）。なお、ｉは１からＮの整数である。以降の処理は、集約項目Ｘｉ毎に処理する。その後、統計値を取得する。ここでは集約項目で指定した項目が全て一致するレコードの数と、ユニークなＩＭＳＩの数をカウントする（ステップ１５０３）。ステップ１５０４では、集約項目で指定した項目の値と、ステップ１５０３で取得した統計値から接続アプリ統計レコードを作成する（ステップ１５０４）。続いて、ステップ１５０４で作成した接続アプリ統計レコードのうち、出力条件を満たすものを抽出し、接続アプリ統計レコード管理テーブル１１１２に出力する（ステップ１５０５）。
【００８７】
そして、全ての集約項目について処理を実行した後に処理を終了する。
【００８８】
図１６は、第一の実施例の統計出力表示プログラム１１０３により作成される画面の一例を示す図である。
【００８９】
統計出力表示プログラム１１０３は、オペレータからの表示要求に従って実行され、接続アプリ統計レコード管理テーブル１１１２に保持する情報を取得し、接続アプリ統計レコード管理テーブル１１１２の統計情報１３０４をグラフ表示する画面を出力する。図１６（Ａ）〜（Ｃ）は、各々、アプリケーション毎、ドメイン毎、ホスト／ＩＰアドレス毎に表示する画面の例を示す。
【００９０】
例えば、図１６（Ａ）に示すアプリケーション毎の表示画面は、時刻、シグナリング種別及びアプリケーションＩＤを集約項目として集約した統計情報を表示するものであり、ドメイン毎の表示は、集約項目として、（時刻、シグナリング種別、ドメイン）で集約した統計情報について表示する。統計出力表示プログラム１１０３は、表示対象と選択したシグナリング種別のうち発生数が多い上位Ｎのシグナリングと、オペレータが設定した特定の項目とについての統計値を積算グラフで表示する。なお、可視化に際し、接続アプリ統計レコード管理テーブル１１１２の特定のフィールド値を指定し、その条件下で上位となるシグナリングを表示してもよい。また、出力画面は特定の時間を指定し、円グラフで表示してもよい。また、テキスト形式で表示してもよい。複数のトラフィック管理サーバが設置されている場合、各トラフィック管理サーバに格納されている接続アプリ統計レコード管理テーブル１１１２の情報をマージし表示してもよい。
【００９１】
本実施例のＣＰ−ＤＰＩ１４２、ＵＰ−ＤＰＩ１４１及びトラフィック管理サーバ１４３において、前述したプログラム及び情報を一つのコンピュータのメモリ２０３に格納する構成を示した。しかし、これらの情報を補助記憶装置２０２に格納し、プログラムによる処理の都度、これらの情報を補助記憶装置２０２から読み出し、各処理が完了するごとに補助記憶装置２０２に格納してもよい。
【００９２】
あるいは、前記プログラム及び前記情報を複数のコンピュータに分散して格納してもよい。例えば、前記情報をそれぞれリレーショナルデータベースのテーブルとして実装してトラフィック管理サーバ１４３と異なるデータベースサーバに格納し、トラフィック管理サーバ上で実行された前記プログラムがデータベースサーバの前記情報を参照及び更新してもよい。
【００９３】
また、前記情報をトラフィック管理サーバ１４３とは異なる分散型のＫＶＳ（Ｋｅｙ−Ｖａｌｕｅ  Ｓｔｏｒｅ）サーバに格納し、トラフィック管理サーバ１４３で実行された前記プログラムがＫＶＳサーバの前記情報を参照及び更新してもよい。
【００９４】
以上のような情報の格納方法の違いは、本発明の本質には影響を与えない。
【００９５】
以上に説明したように、本発明の第一の実施例によると、シグナリングを発生させるアプリケーションを特定し、統計表示することによって、シグナリングを頻発させるアプリケーション、ホスト、ドメインなどの情報をオペレータへ提示することができる。また、ネットワーク規模の拡大に伴うＵＰ−ＤＰＩ１４１やＣＰ−ＤＰＩ１４２の数の増加に柔軟に対応することができる。
【実施例２】
【００９６】
本発明の第二の実施例について図１７を用いて説明する。第二の実施例は、パケット詳細解析装置ＵＰ−ＤＰＩ１４１、ＣＰ−ＤＰＩ１４２のレコード出力処理が、第一の実施例と異なる。すなわち、第一の実施例では、Ｓ−ＧＷ及びＭＭＥの組毎にファイルを生成し、トラフィック管理サーバ１４３が、Ｓ−ＧＷ及びＭＭＥの組毎に纏められたファイルを用いてレコードを関連付けている。しかし、Ｓ−ＧＷ又はＭＭＥの処理量が増加し、シグナリングレコードやセッションレコードが増加するとトラフィック管理サーバ１４３がレコードを関連付ける際の検索処理の負荷が増加する問題がある。第二の実施例では、前述した第一の実施例との相違点のみを説明し、第一の実施例と同一の構成及び処理は同じ符号を付し、それらの説明を省略する。第二の実施例では、処理を細かく分けることによって、トラフィック管理サーバ１４３における検索処理の負荷を低減し、並列処理数を増加する。
【００９７】
図１７は、第二の実施例のレコード出力処理のフローチャートである。図１７に示すレコード出力処理は、ＣＰ−ＤＰＩ１４２がシグナリングレコードを出力する際、及び、ＵＰ−ＤＰＩ１４１がセッションレコードを出力する際に、ＣＰ−ＤＰＩ１４２又はＵＰ−ＤＰＩ１４１のＣＰＵ２０４がシグナリングレコード生成処理プログラム２１２を実行することによって行われる。
【００９８】
第二の実施例では、シグナリングレコードは、ユーザグループ毎に異なるファイルに分けられて管理され、出力される。ユーザグループは、例えば、ＩＭＳＩの下１桁の値によるグループ分けや、ＩＭＳＩにマッピング関数を適用したグループ分けによって生成することができる。
【００９９】
具体的には、まず、ＣＰ−ＤＰＩ１４２のＣＰＵ２０４は、シグナリングレコード内に記載されるユーザ識別子（ＩＭＳＩ）を抽出し（ステップ１７０１）、抽出したＩＭＳＩから所属するユーザグループを決定する（ステップ１７０２）。そして、ユーザグループ毎にシグナリングレコードを出力するファイルを決定し、シグナリングレコードをファイルへ出力する（ステップ１７０３）。最後に、該当ユーザグループを処理するトラフィック管理サーバ１４３を決定し、決定したトラフィック管理サーバ１４３にユーザグループ毎に作成したシグナリングレコードファイルを転送する（ステップ１７０４）。
【０１００】
レコード出力処理は、セッションレコード管理処理プログラム８１１からも呼び出され（図１０の１００９）、ＵＰ−ＤＰＩ１４１のセッションレコードを出力する。この場合、フローチャート中の「シグナリングレコード」を「セッションレコード」と読み替える。
【０１０１】
セッションレコードは、ＵＥ１０１を収容するＳ−ＧＷ１３１及びＭＭＥ１３２の組毎に異なるファイルに分けられて管理され、出力される。
【０１０２】
具体的には、まず、ＵＰ−ＤＰＩ１４１のＣＰＵ２０４は、セッションレコード内に格納されるＩＭＳＩを抽出し（ステップ１７０１）、抽出したＩＭＳＩから所属するユーザグループを決定する（ステップ１７０２）。そして、ユーザグループ毎にセッションレコードを出力するファイルを決定し、セッションレコードをファイルへ出力する（ステップ１７０３）。最後に、該当ユーザグループを処理するトラフィック管理サーバ１４３を決定し、決定したトラフィック管理サーバ１４３にユーザグループ毎に作成したセッションレコードファイルを転送する（ステップ１７０４）。
【０１０３】
なお、ステップ１７０４のファイル転送処理は、周期的に実行すればよく、一定数のレコードを蓄積したタイミングで、所定の時間間隔で、他の条件を満たすタイミングで実行してもよい。また、パケット詳細解析装置１４１、１４２がファイルの蓄積のみを行い、トラフィック管理サーバ１４３がファイルを転送してもよい。
【０１０４】
第二の実施例では、シグナリングレコード及びセッションレコードをユーザグループ毎に異なるファイルに分けて出力する例について説明したが、ＵＰ−ＤＰＩ１４１が、ユーザグループに分けてシグナリングレコード及びセッションレコードを処理できる形式であれば、前述したものと別の形式でシグナリングレコード及びセッションレコードを出力してもよい。
【０１０５】
以上に説明したように、本発明の第二の実施例によると、処理を細かく分けることによって、トラフィック管理サーバ１４３における検索処理の負荷を低減し、並列処理数を増加することができる。また、ＤＰＩ１４１、１４２の処理負荷を均等化することができる。特に、Ｓ−ＧＷ１３１やＭＭＥ１３２の負荷に偏りがある場合や、Ｓ−ＧＷ１３１とＭＭＥ１３２とがフルメッシュで接続されていない場合でも、ＤＰＩ１４１、１４２の処理負荷を均等化することができる。
【実施例３】
【０１０６】
本発明の第三の実施例について図１８を用いて説明する。第三の実施例は、パケット詳細解析装置ＵＰ−ＤＰＩ１４１、ＣＰ−ＤＰＩ１４２のレコード出力処理が、第一及び第二の実施例と異なる。第三の実施例では、前述した第一及び第二の実施例との相違点のみを説明し、第一及び第二の実施例と同一の構成及び処理は同じ符号を付し、それらの説明を省略する。第三の実施例では、第一及び第二の実施例で説明したファイル分割方法を組み合わせることによって、処理単位を更に細かくし、トラフィック管理サーバ１４３における検索処理の負荷を低減し、並列処理数を増加する。
【０１０７】
図１８は、第三の実施例のレコード出力処理のフローチャートである。図１８に示すレコード出力処理は、ＣＰ−ＤＰＩ１４２がシグナリングレコードを出力する際、及び、ＵＰ−ＤＰＩ１４１がセッションレコードを出力する際に、ＣＰ−ＤＰＩ１４２又はＵＰ−ＤＰＩ１４１のＣＰＵ２０４がシグナリングレコード生成処理プログラム２１２を実行することによって行われる。
【０１０８】
第二の実施例では、シグナリングレコードは、Ｓ−ＧＷ１３１及びＭＭＥ１３２の組をさらにユーザグループ毎に異なるファイルに分けられて管理され、出力される。ユーザグループは、第二実施例で説明した方法で生成することができる。
【０１０９】
具体的には、まず、ＣＰ−ＤＰＩ１４２のＣＰＵ２０４は、シグナリングレコード内に記載されるＳ−ＧＷ１３１及びＭＭＥ１３２のＩＰ  Ａｄｄｒｅｓｓ（又は、それぞれのＩＤ）及びユーザ識別子（ＩＭＳＩ）を抽出し（ステップ１８０１）、抽出したＩＭＳＩから所属するユーザグループを決定する（ステップ１８０２）。そして、Ｓ−ＧＷ１３１、ＭＭＥ１３２及びユーザグループ毎にシグナリングレコードを出力するファイルを決定し、シグナリングレコードをファイルへ出力する（ステップ１８０３）。最後に、Ｓ−ＧＷ１３１、ＭＭＥ１３２及びユーザグループの組毎に作成したシグナリングレコードファイルを処理するトラフィック管理サーバ１４３を決定し、決定したトラフィック管理サーバ１４３にＳ−ＧＷ１３１、ＭＭＥ１３２及びユーザグループの組毎に作成したシグナリングレコードファイルを転送する（ステップ１８０４）。
【０１１０】
レコード出力処理は、セッションレコード管理処理プログラム８１１からも呼び出され（図１０の１００９）、ＵＰ−ＤＰＩ１４１のセッションレコードを出力する。この場合、フローチャート中の「シグナリングレコード」を「セッションレコード」と読み替える。
【０１１１】
セッションレコードは、Ｓ−ＧＷ１３１、ＭＭＥ１３２、ユーザグループの組毎に異なるファイルに分けられて管理され、出力される。
【０１１２】
具体的には、まず、ＵＰ−ＤＰＩ１４１のＣＰＵ２０４は、セッションレコード内に格納されるＳ−ＧＷ及びＭＭＥのＩＰ  Ａｄｄｒｅｓｓ（又は、それぞれのＩＤ）及びユーザ識別子（ＩＭＳＩ）を抽出し（ステップ１８０１）、抽出したＩＭＳＩから所属するユーザグループを決定する（ステップ１８０２）。そして、Ｓ−ＧＷ１３１、ＭＭＥ１３２及びユーザグループの組毎にセッションレコードを出力するファイルを決定し、セッションレコードをファイルへ出力する（ステップ１８０３）。最後に、Ｓ−ＧＷ１３１、ＭＭＥ１３２及びユーザグループの組毎に作成したセッションレコードファイルを処理するトラフィック管理サーバ１４３を決定し、決定したトラフィック管理サーバ１４３にＳ−ＧＷ１３１、ＭＭＥ１３２及びユーザグループの組毎に作成したセッションレコードファイル転送する（ステップ１８０４）。
【０１１３】
なお、ステップ１８０４のファイル転送処理は、周期的に実行すればよく、一定数のレコードを蓄積したタイミングで、所定の時間間隔で、他の条件を満たすタイミングで実行してもよい。また、パケット詳細解析装置１４１、１４２がファイルの蓄積のみを行い、トラフィック管理サーバ１４３がファイルを転送してもよい。
【０１１４】
第三の実施例では、シグナリングレコード及びセッションレコードをＳ−ＧＷ１３１、ＭＭＥ１３２及びユーザグループの組毎に異なるファイルに分けて出力する例について説明したが、ＵＰ−ＤＰＩ１４１及びＣＰ−ＤＰＩ１４２が、Ｓ−ＧＷ１３１、ＭＭＥ１３２及びユーザグループの組に分けてシグナリングレコード及びセッションレコードを処理できる形式であれば、前述したものと別の形式でシグナリングレコード及びセッションレコードを出力してもよい。
【０１１５】
以上に説明したように、本発明の第三の実施例によると、ＤＰＩ１４１、１４２からの出力が更に細分化でき、トラフィック管理サーバ１４３における検索処理の負荷を低減し、並列処理数を増加することができる。
【実施例４】
【０１１６】
本発明の第四の実施例について図１９から図２６を用いて説明する。第四の実施例は、パケット詳細解析装置ＣＰ−ＤＰＩ１４２を省略したシステム構成と、ＵＰ−ＤＰＩ１４１での処理内容とが、第一、第二及び第三の実施例と異なる。第四の実施例では、前述した第一、第二及び第三の実施例との相違点のみを説明し、第一、第二及び第三の実施例と同一の構成及び処理は同じ符号を付し、それらの説明を省略する。第一、第二及び第三の実施例では、シグナリングレコードとセッションレコードとを関連付け、シグナリングの発生要因アプリを特定しているため、要因の特定精度は高いが処理負荷も高い問題がある。第四の実施例では、シグナリングの発生要因アプリを特定する精度の低下を許容できる場合に処理負荷を低減する。
【０１１７】
図１９は、第四の実施例のセルラ通信システムの構成を示す図である。
【０１１８】
第四の実施例のセルラ通信システムは、基地局装置であるｅＮｏｄｅＢ１１１、ゲートウェイ装置であるＳ−ＧＷ１３１、Ｐ−ＧＷ１３３、通信制御装置であるＭＭＥ１３２、パケット詳細解析装置であるＵＰ−ＤＰＩ１４１、及び、トラフィック管理サーバ１４３を有する。ｅＮｏｄｅＢ１１１には、ユーザ端末であるＵＥ１０１が接続される。
【０１１９】
第四の実施例のシステムでは、第一の実施例のシステムと比較して、ＣＰ−ＤＰＩ１４２が設けられていない。トラフィック管理サーバ１４３は、ＵＰ−ＤＰＩ１４１と接続する。本実施例では、ＵＰ−ＤＰＩ１４１はＳ−ＧＷ毎に設置され、リファレンスポイントＳ１−Ｕ及びＳ１１で転送されるトラフィックを取得する。ただし、一つのＵＰ−ＤＰＩ１４１が複数のＳ−ＧＷ１３１を収容してもよいし、複数のＵＰ−ＤＰＩ１４１が一つのＳ−ＧＷ１３１を収容してもよい。
【０１２０】
第四の実施例におけるデータ処理の流れを簡単に説明すれば、以下の通りである。すなわち、ＵＰ−ＤＰＩ１４１が、Ｓ１１のシグナリングを取得し、取得したシグナリングを用いてＵＥ１０１のネットワーク接続状態を推定及び管理し、ネットワークへ接続状態となった直後のセッションレコードにシグナリング発生要因フラグ（関連付け対象フラグ）を付与し、トラフィック管理サーバ１４３へ送信する。トラフィック管理サーバ１４３は、シグナリング発生要因フラグ（関連付け対象フラグ）が設定されているセッションレコードについて統計処理を実行し、可視化する。
【０１２１】
図２０は、第四の実施例のパケット詳細解析装置（ＵＰ−ＤＰＩ）１４１の構成を示す図である。
【０１２２】
第四の実施例のＵＰ−ＤＰＩ１４１は、以下の４点において第一、第二及び第三の実施例と異なる。
（１）ユーザ情報更新処理プログラム２００１：第一の実施例のユーザ情報更新処理プログラム２１１に一部処理を追加
（２）セッションラベリング処理プログラム２００２を追加
（３）ユーザ情報管理テーブル２０１１：第一の実施例のユーザ情報管理テーブル２２１に一部情報を追加
（４）セッションレコード管理テーブル２０１２：第一の実施例のセッションレコードに一部情報を追加
各変更点の詳細については、図２１から図２６を用いて説明する。
【０１２３】
図２１は、第四の実施例のユーザ情報管理テーブル２０１１の構成例を示す図である。
【０１２４】
ユーザ情報管理テーブル２０１１は、ＩＭＳＩ３０１と、ユーザ識別子３０２と、ユーザ接続情報２１０１とを含む。第四の実施例では、ユーザ接続情報２１０１が新たに加えられている。ユーザ接続情報２１０１は、ユーザ接続状態と、接続契機と、接続開始時刻と、出現セッション数と、ＤＤＮ受信時刻と、Ｓ１−Ｕ最終パケット受信時刻とを含む。
【０１２５】
ユーザ接続状態は、該当ＵＥのネットワーク接続状態を格納する。例えば、ユーザ接続状態は、「ＣＯＮＮＥＣＴＥＤ」、「ＩＤＬＥ」、「ＣＡＬＬＩＮＧ」、「ＤＥＴＡＣＨＥＤ」、「ＵＮＫＮＯＷＮ」の状態を含み、主にＳ１１のシグナリング受信に基づいて状態を遷移する。状態遷移の詳細は、図２３を用いて説明する。
【０１２６】
接続契機は、ユーザ接続状態が「ＣＯＮＮＥＣＴＥＤ」となった時の接続契機に関する情報であり、「ユーザ契機」、「ネットワーク契機」、「位置登録契機」、「不明」の四つを含む。第四の実施例では、「ＣＯＮＮＥＣＴＥＤ」に遷移する前の状態から接続契機情報を取得する。
【０１２７】
接続開始時刻は、「ＣＯＮＮＥＣＴＥＤ」に遷移した時刻を格納する。ＤＤＮ受信時刻はＳ１１でＤＤＮ受信時刻を格納する。Ｓ１−Ｕ最終パケット受信時刻はユーザパケットの最終パケット受信時刻を格納する。これらタイムスタンプは随時上書きし、最新の情報を保持する。出現セッション数は、該当ＵＥが送受信したセッション数を格納する。
【０１２８】
図２２は、第四の実施例のセッションレコードの構成例を示す図である。
【０１２９】
セッションレコードは、セッションレコード管理テーブル２０１２及びセッションレコード出力ファイル２０１３内に含まれる情報である。なお、セッションレコード管理テーブル２０１２は、継続中のセッションに関する情報を保持し、ユーザトラフィックが到着すると、検索及び更新を行うテーブルである。セッションレコード出力ファイル２０１３は、終了したセッション又はアプリケーション特定済のセッションに関する情報を保持する。
【０１３０】
第四の実施例では、第一の実施例のセッションレコード（図９）に、接続契機２２０１と、接続開始時刻２２０２と、関連付け対象フラグ２２０３と、出現セッション順位２２０４とが新たに加えられている。接続契機２２０１及び接続開始時刻２２０２は、ユーザ情報管理テーブル２０１１のユーザ接続情報２１０１に格納している情報であり、セッション開始時にユーザ情報管理テーブル２０１１から取得し格納される。関連付け対象フラグ２２０３は、シグナリング発生要因であるか否かを示すフラグ情報を格納する。出現セッション順位２２０４は、接続開始時刻２２０２以降、かつ該当セッションの出現前に、該当ＵＥが送受信したセッション数を格納する。
【０１３１】
図２３は、第四の実施例における、ＵＰ−ＤＰＩ１４１にて管理するユーザの接続状態の遷移図である。
【０１３２】
ユーザの接続状態は、「ＣＯＮＮＥＣＴＥＤ」「ＩＤＬＥ」「ＣＡＬＬＩＮＧ」「ＤＥＴＡＣＨＥＤ」「ＵＮＫＮＯＷＮ」の状態を含み、Ｓ１１のシグナリング受信及びタイムアウトにより状態遷移する。状態遷移に用いるシグナリングは、Ｃｒｅａｔｅ  Ｓｅｓｓｉｏｎ、Ｍｏｄｉｆｙ  Ｂｅａｒｅｒ、Ｄｏｗｎｌｉｎｋ  Ｄａｔａ  Ｎｏｔｉｆｉｃａｔｉｏｎ、Ｒｅｌｅａｓｅ  Ａｃｃｅｓｓ  Ｂｅａｒｅｒ、Ｄｅｌｅｔｅ  ｂｅａｒｅｒ、Ｄｅｌｅｔｅ  Ｓｅｓｓｉｏｎである。
【０１３３】
図２４は、第四の実施例のユーザ情報更新処理のフローチャートである。図２４に示すユーザ情報更新処理は、ＣＰ−ＤＰＩ１４２のＣＰＵ２０４がユーザ情報更新処理プログラム２１１を実行することによって行われる。
【０１３４】
ステップ５０１からステップ５１２までの処理は第一の実施例（図５）と同じであり、ステップ２４２１及びステップ２４２２が第四の実施例で異なる点である。ステップ２４２１及びステップ２４２２は、ユーザ情報管理テーブル２０１１のユーザ接続情報２１０１を更新する。具体的には、ステップ２４２１では、該当ＵＥ１０１の接続状態及び受信したＳ１１のシグナリングから、状態遷移が発生するか否かを判定する。ステップ２４２２では、ユーザ情報管理テーブル２０１１のユーザ接続状態を変更する。さらに、ユーザの接続状態が「ＩＤＬＥ」、「ＣＡＬＬＩＮＧ」、「ＤＥＴＡＣＨＥＤ」、「ＵＮＫＮＯＷＮ」から「ＣＯＮＮＥＣＴＥＤ」へ遷移した場合、接続契機及び接続開始時刻を更新し、出現セッション数を０に設定する。接続契機は、遷移前の状態から「ユーザ契機（１）」、「ネットワーク契機（２）」、「位置登録契機（３）」、「不明（０）」を格納する。また、ＤＤＮ受信時には、ＤＤＮ受信時刻を更新する。
【０１３５】
図２５は、第四の実施例のセッションラベリング処理のフローチャートである。図２５に示すセッションラベリング処理は、ＵＰ−ＤＰＩ１４１のＣＰＵ２０４がセッションラベリング処理プログラム２００２を実行することによって行われる。
【０１３６】
セッションラベリング処理プログラム２００２は、セッションレコード管理処理プログラム８１１中のセッション登録処理（図１０のステップ１００４）で実行されるプログラムであり、セッションレコードに第四の実施例で追加したフィールドを登録する。
【０１３７】
まず、ユーザ情報管理テーブル２０１１から該当ＵＥ１０１の情報を取得し（ステップ２５０１）、取得したＵＥ１０１の情報をセッションレコードに記録する（ステップ２５０２）。次に、ユーザ情報管理テーブル２０１１の出現セッション数をインクリメントする（ステップ２５０３）。そして、ステップ２５０１で作成したセッションレコードがラベリング条件を満たすかを判定する（ステップ２５０４）。ラベリング条件は、例えば、接続開始時刻２２０２とセッション開始時刻との時刻差が一定時間以内である、出現セッション順位２２０４が所定の閾値以下である、等である。この条件は、接続契機毎に用意してもよく、例えば、接続契機が「ネットワーク契機」である場合、出現セッション順位２２０４が「１」以下を設定してもよく、接続契機が「ユーザ契機」である場合、出現セッション順位２２０４が「５」以下等を設定してもよい。ステップ２５０４で、ラベリング条件を満たすと判定された場合、セッションレコード中の関連付け対象フラグを設定し（ステップ２５０５）、セッションレコードを登録する（ステップ２５０６）。
【０１３８】
なお、ＵＰ−ＤＰＩ１４１の処理負荷を低減するため、セッションレコード管理処理（図８）において、関連付け対象フラグがセットされているセッションのみにアプリ識別処理（ステップ１００６、１００７）を実行してもよい。
【０１３９】
第四の実施例において、トラフィック管理サーバ１４３は、レコード関連付け処理を実行せず、ＵＰ−ＤＰＩ１４１の出力であるセッションレコードを統計処理の入力とする。
【０１４０】
なお、第四の本実施例と第一、第二、第三のいずれかの実施例を組み合わせた構成を採用してもよい。すなわち、第一、第二又は第三の実施例のＵＰ−ＤＰＩ１４１に、第四の実施例のＵＰ−ＤＰＩ１４１を適用する。各実施例を組み合わせた構成によると、レコード関連付け処理を行うセッションレコード数を削減することができ、トラフィック管理サーバのレコード関連付け処理の負荷を低減することができる。この場合のトラフィック管理サーバのレコード関連付け処理を、図２６を用いて説明する。
【０１４１】
図２６は、第四の実施例と第一、第二又は第三の実施例とを組合せた構成におけるレコード関連付け処理のフローチャートである。図２６に示すレコード関連付け処理は、トラフィック管理サーバ１４３のＣＰＵ２０４がレコード関連付け処理プログラム１１０１を実行することによって行われる。
【０１４２】
第四の実施例では、第一、第二及び第三の実施例に、セッションレコード取得前にステップ２６０１の処理を実行する。ステップ２６０１では、セッションレコードで関連付け対象フラグがセットされているエントリを抽出する。そして、ステップ２６０２では、図１４で説明したレコード関連付け処理（ステップ１４０１〜１４０７）を実行する。
【０１４３】
以上に説明したように、本発明の第四の実施例によると、「ＣＯＮＮＥＣＴＥＤ」になった時刻から所定の時間内のセッションログのみを選択することができ、トラフィック管理サーバ１４３における検索回数が減少し、シグナリングの発生要因アプリを特定する処理の負荷を低減することができる。
【実施例５】
【０１４４】
本発明の第五の実施例について図２７を用いて説明する。第五の実施例は、第四の実施例において、ＵＰ−ＤＰＩ１４１が出力するセッションレコードを、関連付け対象フラグがセットされているレコードのみとすることによって、データ転送量を削減する。
【０１４５】
図２７は、第五の実施例のレコード出力処理のフローチャートである。図２７に示すレコード出力処理は、ＣＰ−ＤＰＩ１４２がシグナリングレコードを出力する際、及び、ＵＰ−ＤＰＩ１４１がセッションレコードを出力する際に、ＣＰ−ＤＰＩ１４２又はＵＰ−ＤＰＩ１４１のＣＰＵ２０４がシグナリングレコード生成処理プログラム２１２を実行することによって行われる。
【０１４６】
第五の実施例では、第一、第二及び第三の実施例に、レコード出力前にステップ２７０１の処理を実行する。まず、ステップ２７０１では、関連付け対象フラグがセットされているセッションレコードを抽出する。そして、ステップ２７０２では、第一、第二及び第三の実施例で説明したレコード出力処理（図７、図１７、図１８）を実行する。
【０１４７】
以上に説明したように、本発明の第五の実施例によると、ＤＰＩ１４１とトラフィック管理サーバ１４３との間で転送されるデータ量を減らすことができる。
【０１４８】
以上に説明したように、本発明の実施例によると、第一の監視装置（ＣＰ−ＤＰＩ１４２）が、ユーザ端末（ＵＥ１０１）とネットワークとの間の接続要求に関する制御信号を監視し、受信ログを生成し、第二の監視装置（ＵＰ−ＤＰＩ１４１）が、ユーザデータを転送するゲートウェイ装置（Ｓ−ＧＷ１３１）に入出力されるパケットを監視し、前記パケットをセッション毎に分け、セッションを生成するアプリケーションの種別を特定し、前記アプリケーションの種別を含むセッションログを生成し、トラフィック管理サーバ１４３が、ＣＰ−ＤＰＩ１４２が生成した受信ログと、ＵＰ−ＤＰＩ１４１が生成したセッションログとを取得し、前記受信ログの発生時刻、前記セッションログの発生時刻及びＵＥ１０１の識別子を用いて前記受信ログと前記セッションログとを関連付け、前記制御信号を発生させたセッションに関連するアプリケーションを特定するので、シグナリングを発生させるアプリケーションを特定し、統計表示することによって、シグナリングを頻発させるアプリケーション、ホスト、ドメインなどの情報をオペレータへ提示することができる。
【０１４９】
また、ＣＰ−ＤＰＩ１４２は、ＵＥ１０１が属するユーザグループ毎に前記受信ログを分けて出力し、ＵＰ−ＤＰＩ１４１は、ユーザグループ毎に前記セッションログを分けて出力し、前記トラフィック管理サーバは、ユーザグループによって分けられた受信ログ及びセッションログを取得し、ユーザグループに従って前記受信ログと前記セッションログとを関連付けるので、ＤＰＩ１４１、１４３の処理負荷を均等化することができる。特に、Ｓ−ＧＷ１３１及びＭＭＥ１３２の負荷に偏りがある場合や、Ｓ−ＧＷ１３１とＭＭＥ１３２とがフルメッシュで接続されていない場合でも、ＤＰＩ１４１、１４３の処理負荷を均等化することができる。
【０１５０】
また、ＣＰ−ＤＰＩ１４２は、Ｓ−ＧＷ１３１及び通信装置（ＭＭＥ１３２）の組毎に前記受信ログを分けて出力し、ＵＰ−ＤＰＩ１４１は、Ｓ−ＧＷ１３１及びＭＭＥ１３２の組毎に前記セッションログを分けて出力し、トラフィック管理サーバ１４３は、前記ゲートウェイ装置及び前記通信装置の組毎に分けられた受信ログ及びセッションログを取得し、前記ゲートウェイ装置及び前記通信装置の組に従って前記受信ログと前記セッションログとを関連付けるので、ネットワーク規模の拡大に伴うＤＰＩの数の増加に柔軟に対応することができる。
【０１５１】
また、ＣＰ−ＤＰＩ１４２は、Ｓ−ＧＷ１３１、ＭＭＥ１３２及びユーザグループの組毎に分けて受信ログを分けて出力し、ＵＰ−ＤＰＩ１４１は、Ｓ−ＧＷ１３１、ＭＭＥ１３２及びユーザグループの組毎に分けてセッションログを分けて出力し、トラフィック管理サーバ１４３は、Ｓ−ＧＷ１３１、ＭＭＥ１３２及びユーザグループの組毎に分けられた受信ログ及びセッションログを取得し、Ｓ−ＧＷ１３１、ＭＭＥ１３２及びユーザグループの組に従って前記受信ログと前記セッションログとを関連付けるので、ＤＰＩ１４１、１４２からの出力が更に細分化でき、トラフィック管理サーバ１４３における検索処理の負荷を低減し、並列処理数を増加することができる。
【０１５２】
また、ＵＰ−ＤＰＩ１４１は、ＵＥ１０１が送受信する制御信号からＵＥ１０１の接続状態を推定し、接続状態の変化から所定時間内に発生したセッションログにラベルを付けて、出力し、トラフィック管理サーバ１４３は、前記ラベル付けされたセッションログを取得し、前記ラベル付けされたセッションログと前記受信ログとを関連付けるので、「ＣＯＮＮＥＣＴＥＤ」になった時刻から所定の時間内のセッションログのみを選択することができ、トラフィック管理サーバ１４３における検索回数が減少し、シグナリングの発生要因アプリを特定する処理の負荷を低減することができる。
【０１５３】
また、ＵＰ−ＤＰＩ１４１は、ＵＥ１０１が送受信する制御信号からＵＥ１０１の接続状態を推定し、接続状態の変化から所定時間内に発生したセッションログを出力するので、ＤＰＩ１４１とトラフィック管理サーバ１４３との間で転送されるデータ量を減らすことができる。
【０１５４】
なお、本発明は前述した実施例に限定されるものではなく、添付した特許請求の範囲の趣旨内における様々な変形例及び同等の構成が含まれる。例えば、前述した実施例は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに本発明は限定されない。また、ある実施例の構成の一部を他の実施例の構成に置き換えてもよい。また、ある実施例の構成に他の実施例の構成を加えてもよい。また、各実施例の構成の一部について、他の構成の追加・削除・置換をしてもよい。
【０１５５】
また、前述した各構成、機能、処理部、処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等により、ハードウェアで実現してもよく、プロセッサがそれぞれの機能を実現するプログラムを解釈し実行することにより、ソフトウェアで実現してもよい。
【０１５６】
各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリ、ハードディスク、ＳＳＤ（Solid State Drive）等の記憶装置、又は、ＩＣカード、ＳＤカード、ＤＶＤ等の記録媒体に格納することができる。
【０１５７】
また、制御線や情報線は説明上必要と考えられるものを示しており、実装上必要な全ての制御線や情報線を示しているとは限らない。実際には、ほとんど全ての構成が相互に接続されていると考えてよい。
【符号の説明】
【０１５８】
１０１  ユーザ端末（ＵＥ：Ｕｓｅｒ  Ｅｑｕｉｐｍｅｎｔ）
１１１  基地局（ｅＮｏｄｅＢ：Ｅ−ＵＴＲＡＮ  ＮｏｄｅＢ）
１４１  パケット詳細解析装置ＵＰ−ＤＰＩ
１４２  パケット詳細解析装置ＣＰ−ＤＰＩ
１４３  トラフィック管理サーバ
【図１】
2016096415.tif 000003
【図２】
2016096415.tif 000004
【図３】
2016096415.tif 000005
【図４】
2016096415.tif 000006
【図５】
2016096415.tif 000007
【図６】
2016096415.tif 000008
【図７】
2016096415.tif 000009
【図８】
2016096415.tif 000010
【図９】
2016096415.tif 000011
【図１０】
2016096415.tif 000012
【図１１】
2016096415.tif 000013
【図１２】
2016096415.tif 000014
【図１３】
2016096415.tif 000015
【図１４】
2016096415.tif 000016
【図１５】
2016096415.tif 000017
【図１７】
2016096415.tif 000018
【図１８】
2016096415.tif 000019
【図１９】
2016096415.tif 000020
【図２０】
2016096415.tif 000021
【図２１】
2016096415.tif 000022
【図２２】
2016096415.tif 000023
【図２３】
2016096415.tif 000024
【図２４】
2016096415.tif 000025
【図２５】
2016096415.tif 000026
【図２６】
2016096415.tif 000027
【図２７】
2016096415.tif 000028
【図１６】
2016096415.tif 000029