(57)【特許請求の範囲】
【請求項１】
通信端末が通信相手との間に確立したセッションをフォアグラウンド通信およびバックグラウンド通信のいずれかに識別する通信識別装置において、
各セッションを送信元情報および宛先情報の組み合わせに固有のSDグループに分類するセッション分類手段と、
送信元情報が同一で宛先情報の異なる複数のSDグループを、各セッションのトラヒック特性の類似度に基づいて集約するセッション集約手段と、
SDグループごとにセッションの生起タイミング特性を計算する手段と、
前記セッションの生起タイミング特性に基づいて各SDグループのセッションを識別する通信識別手段と、を具備するとともに、
前記セッション集約手段は、送信元情報が同一で宛先情報の異なるSDグループ間でトラヒック特性の相互相関を計算する手段を具備し、相互相関が所定の閾値を超えるSDグループ同士を一のSDグループに集約し、
前記セッション集約手段は、トラヒック特性の時系列変動を単位時間幅のbinごとに離散化してトラヒック特性数列を生成する特性数列生成手段を具備し、前記相互相関を計算する手段は、前記トラヒック特性数列の相互相関を計算する
ことを特徴とする通信識別装置。
【請求項２】
前記特性数列生成手段は、ダウンロードの転送データ量、アップロードの転送データ量、ダウンロードとアップロードとの転送データ量の比率、ダウンロードのパケット数、アップロードのパケット数、ダウンロードとアップロードとのパケット数の比率、スループット特性、トラヒック遅延特性、保留時間と応答時間との比率、トラヒック特性の時系列変動傾向およびセッション生起数の少なくとも一つをbinごとに計算して特性数列の時系列要素とすることを特徴とする請求項１に記載の通信識別装置。
【請求項３】
前記生起タイミング特性を計算する手段は、SDグループごとに各セッションの生起タイミングに関する自己相関を計算し、
前記通信識別手段は、自己相関が所定の閾値を超えるSDグループのセッションをバックグラウンド通信に識別することを特徴とする請求項１に記載の通信識別装置。
【請求項４】
前記生起タイミング特性を計算する手段は、
SDグループごとに各セッションの生起タイミングを所定の時間幅を有するbinの位置で代表し、当該bin位置を要素とする生起タイミングベクトルを生成する手段と、
前記生起タイミングベクトルの異なる要素の組み合わせごとに差分を計算する手段と、
前記差分が同一となる組み合わせの要素集合ごとに、当該差分がセッションの生起周期である信頼度を計算する手段とを具備し、
前記通信識別手段は、各生起周期の信頼度に基づいてセッションを識別することを特徴とする請求項１に記載の通信識別装置。
【請求項５】
前記生起タイミングベクトルを生成する手段は、binごとにセッションの生起タイミングであるか否かを示すビット数列を生成する手段を具備し、
前記ビット数列の開始binから各生起タイミングのbinまでのbin数の時系列を生起タイミングベクトルの要素とすることを特徴とする請求項４に記載の通信識別装置。
【請求項６】
前記信頼度を計算する手段は、所定の監視期間内において、セッションの生起タイミングを検知されることが期待されるbin数に対する、セッションの生起タイミングを検知されたbin数に基づいて信頼度を計算することを特徴とする請求項４または５に記載の通信識別装置。
【請求項７】
前記信頼度を計算する手段は、差分が生起タイミングのサンプリング期間の略半分以上となる組み合わせの要素集合を信頼度の計算対象としないことを特徴とする請求項４ないし６のいずれかに記載の通信識別装置。
【請求項８】
前記生起タイミングベクトルを生成する手段は、各binの前後方向に所定の幅で付加期間を設定し、当該付加期間を含めたbin幅内で検知された生起タイミングに基づいて生起タイミングベクトルを生成することを特徴とする請求項４ないし７のいずれかに記載の通信識別装置。
【請求項９】
通信端末が通信相手との間に確立したセッションをコンピュータがフォアグラウンド通信およびバックグラウンド通信のいずれかに識別する通信識別方法において、
各セッションを送信元情報および宛先情報の組み合わせに固有のSDグループに分類する手順と、
送信元情報が同一で宛先情報の異なる複数のSDグループを、各セッションのトラヒック特性の類似度に基づいて集約する手順と、
SDグループごとにセッションの生起タイミング特性を計算する手順と、
前記セッションの生起タイミング特性に基づいて各SDグループのセッションを識別する手順と、
送信元情報が同一で宛先情報の異なるSDグループ間でトラヒック特性の相互相関を計算する手段を具備して、相互相関が所定の閾値を超えるSDグループ同士を一のSDグループに集約する手順と、
トラヒック特性の時系列変動を単位時間幅のbinごとに離散化してトラヒック特性数列を生成し、前記相互相関を計算する手段により前記トラヒック特性数列の相互相関を計算する手順と、
を含むことを特徴とする通信識別方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信識別方法および装置に係り、特に、通信端末がフォアグラウンド（Foreground）で行う通信とバックグラウンド(Background)で行う通信とを識別する通信識別方法および装置に関する。
【背景技術】
【０００２】
通信端末が実行する通信の内容を識別する技術が研究されている。特許文献１には、通信トラヒック量の時系列変化やデータから、フーリエ変換等を用いて周期性を算出する手法が開示されている。
【０００３】
特許文献２には、通信トラヒックをフロー毎に測定・集約し、フロー毎の通信トラヒック特性から、周波数解析手法であるケプストラム分析を適用することにより、フローからアプリ（通信サービスの種別）を識別する技術が開示されている。
【０００４】
特許文献３には、通信トラヒックをフロー毎に測定・集約し、フロー毎の通信トラヒック特性から特徴量を算出し、機械学習を適用することにより、フローから通信サービスの種別（アプリケーション）を識別する技術が開示されている。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開2010-283668号公報
【特許文献２】特開2012-105043号公報
【特許文献３】特開2013-127504号公報
【特許文献４】特願2014-037083号
【発明の概要】
【発明が解決しようとする課題】
【０００６】
近年におけるモバイル端末の爆発的な普及によりさまざまなサービスが台頭し、端末ユーザの通信要求操作を契機に生起されるフォアグラウンド通信のみならず、端末ユーザの通信要求操作とは無関係に、アプリケーションが自身に都合の良い任意のタイミングでサーバ等と通信するバックグラウンド通信が生起されるようになってきた。
【０００７】
各通信方式は、重要度、緊急度、データサイズ、遅延やジッタに対する許容度、端末ユーザの主観評価に与える影響などが異なるので、各通信方式を識別できれば様々な用途で活用できる。
【０００８】
しかしながら、特許文献１は、目的が異常検知すなわち平常時からの傾向変化検知であり、フォア／バックグラウンド通信を識別できない。特許文献２，３は、アプリケーションや通信サービスの識別を目的とする技術であり、フォア／バックグラウンド通信は識別できない。
【０００９】
一方、このような技術課題に対して、本発明の発明者等は、ネットワーク上で観測される各セッションを、その送信元情報および宛先情報の組み合わせに固有のSDグループに分類すると共に、SDグループごとに各セッションの生起タイミングに関する自己相関を計算し、自己相関係数が高いセッションはバックグラウンド通信に識別する通信識別装置を発明し、特許出願（特許文献４）した。
【００１０】
しかしながら、Webコンテンツをインターネット経由で配信するために最適化されたCDN(Contents Delivery Network)や、Google社が提供するクラウドサービスでは、コンテンツを複数のサーバに分散配置したり、コンテンツの配信元をユーザ端末の位置に応じて動的に変更、最適化したりすることがある。
【００１１】
このような場合、送信元（クライアント・ユーザ端末）が同一であり、かつ同一のサービスやアプリケーションに係るセッションでありながら、宛先が異なるために別々のSDグループに分類されてしまうので、各セッションの関連性に基づいて通信種別を識別することができなかった。
【００１２】
本発明の目的は、上記の技術課題を解決し、宛先情報が異なるセッション同士であっても、送信元情報が同一であって、トラヒック特性が類似あるいは高い相関を示すセッションは、同一のサービスまたはアプリケーションに係るセッションとして扱うことで、フォアグラウンド通信またはバックグラウンド通信に識別できる通信識別方法および装置を提供することにある。
【課題を解決するための手段】
【００１３】
上記の目的を達成するために、本発明は、通信端末が通信相手との間に確立したセッションをフォアグラウンド通信およびバックグラウンド通信のいずれかに識別する通信識別装置において、以下の構成を具備した点に特徴がある。
【００１４】
(1) 各セッションを送信元情報および宛先情報の組み合わせに固有のSDグループに分類する手段と、送信元情報が同一で宛先情報の異なる複数のSDグループを、各セッションのトラヒック特性の相関関係に基づいて集約する手段と、SDグループごとにセッションの生起タイミング特性を計算する手段と、セッションの生起タイミング特性に基づいてSDグループのセッションを識別する手段とを具備した。
【００１５】
(2) 生起タイミング特性を計算する手段が、SDグループごとに各セッションの生起タイミングに関する自己相関を計算し、自己相関が所定の閾値を超えるSDグループのセッションをバックグラウンド通信に識別するようにした。
【００１６】
(3) 生起タイミング特性を計算する手段が、SDグループごとに各セッションの生起タイミングを所定の時間幅を有するbinの位置で代表して当該bin位置を要素とする生起タイミングベクトルを生成する手段と、生起タイミングベクトルの異なる要素の組み合わせごとに差分を計算する手段と、前記差分が同一となる組み合わせの要素集合ごとに当該差分がセッションの生起周期である信頼度を計算する手段とを具備し、各生起周期の信頼度に基づいてセッションを識別するようにした。
(4) セッション集約手段が、送信元情報が同一で宛先情報の異なるSDグループ間でトラヒック特性の相互相関を計算する手段を具備し、相互相関が所定の閾値を超えるSDグループ同士を一のSDグループに集約するようにした。
また、セッション集約手段が、トラヒック特性の時系列変動を単位時間幅のbinごとに離散化してトラヒック特性数列を生成する特性数列生成手段を具備し、前記相互相関を計算する手段は、前記トラヒック特性数列の相互相関を計算するようにした。
【発明の効果】
【００１７】
本発明によれば、以下のような効果が達成される。
(1) 宛先情報が異なるセッションであっても、送信元情報が同一であり、かつセッションのトラヒック特性が類似あるいは高い相関を示すセッションは、同一のサービスまたはアプリケーションに係るセッションとして同一のSDグループに集約され、セッションの生起タイミング特性に基づく通信種別の判定対象とされる。
【００１８】
したがって、コンテンツが複数のサーバに分散配置されたり、コンテンツの配信元がユーザ端末の位置に応じて動的に変更、最適化されたりするサービスやアプリケーションに係るセッションであっても、ユーザ由来・主導のフォアグラウンド通信とバックグラウンド通信とを正確に判別できるようになる。
【００１９】
(2) 通信端末が実行する通信のうち、生起タイミングの自己相関が高いセッションは、ユーザ操作とは無関係にOSやアプリケーションが自動的、機械的に実行するバックグラウンド通信である可能性が高いので、生起タイミングの自己相関係数を計算することで、フォアグラウンド通信とバックグラウンド通信とを正確に判別できるようになる。
【００２０】
(3) バックグラウンド通信に係るセッションの生起タイミングのように、極めて疎なデータ列を評価する際、疎の区間に対応して多数の「０」を連続して含むビット数列Tではなく、このビット数列Tから生成した生起タイミングベクトルを対象に信頼度計算を行うので、射影後の数列長を短くすることができ、計算量を大幅に減じることが可能となる。
【図面の簡単な説明】
【００２１】
【図１】本発明の通信識別方法が適用されるネットワークの構成を示した図である。
【図２】キャプチャ装置の主要部の構成を示した機能ブロック図である。
【図３】宛先のみが異なるSDグループを集約する方法を模式的に表現した図である。
【図４】TCPコネクションにおけるトラヒック特性の測定方法を示した図である。
【図５】HTTPセッションにおけるトラヒック特性の測定方法を示した図である。
【図６】自己相関係数の計算方法を示したフローチャートである。
【図７】本発明の第１実施形態に係るキャプチャ装置の機能ブロック図である。
【図８】相互相関係数の計算方法を示したフローチャートである。
【図９】本発明の第２実施形態に係るキャプチャ装置の機能ブロック図である。
【図１０】ビット数列生成部１０５B1の機能を説明するための図である。
【図１１】差分計算部１０５C1の機能を説明するための図である。
【図１２】要素集合表生成部１０５C2の機能を説明するための図である。
【図１３】信頼度計算部１０５C3の動作を示したフローチャートである。
【発明を実施するための形態】
【００２２】
以下、図面を参照して本発明の実施の形態について詳細に説明する。図１は、本発明の通信識別方法が適用されるネットワークの構成を示したブロック図である。
【００２３】
サービス提供範囲の各エリアには無線基地局BSが設置され、当該エリア内の無線移動端末MN（例えば、スマートフォンやタブレット端末）は前記各無線基地局BSに収容される。各無線基地局BSは無線アクセス網RANに接続され、前記無線アクセス網RANはコア網のゲートウェイ(GW)に接続される。前記コア網はインターネットエクスチェンジ(IX)においてインターネットと接続される。
【００２４】
前記インターネットには、各MNからの要求に応答してサービスを提供する各種のサーバが接続されている。本実施形態では、各MNと各サーバとの間のトラヒックを集約できる回線として、無線アクセス網RANとコア網とを接続する回線Lに、通信識別装置としてのキャプチャ装置１が接続されている。
【００２５】
図２は、前記キャプチャ装置１の主要部の構成を示した機能ブロック図であり、ここでは、本発明の説明に不要な構成は図示が省略されている。本発明のキャプチャ装置１は、汎用のコンピュータやサーバに各機能を実現するアプリケーション（プログラム）を実装することで構成できる。あるいはアプリケーションの一部がハードウェア化またはROM化された専用機や単能機としても構成できる。
【００２６】
通信トラヒック測定部１０１は、前記回線L上で送受されるパケットをキャプチャして、そのセッション種別（TCP、HTTP、UDPなど）、生起タイミング、送信元情報および宛先情報を含む各種の情報をログ情報管理部１０２に記録する。
【００２７】
セッション分類部１０３は、各セッションをその送信元情報(S)および宛先情報(D)の組み合わせに基づいていずれかのSDグループに分類する。すなわち、送信元情報および宛先情報のいずれもが同一のセッションは同一のSDグループに分類され、異なるセッションは別のSDグループに分類される。
【００２８】
本実施形態では、送信元情報として送信元IPアドレスを採用し、宛先情報として宛先IPアドレスおよびポート番号を採用する。各セッションの生起タイミングは、HTTPセッションであればHTTP Requestパケットの到着時刻で代表し、TCPセッションであればセッション確立時に実行されるスリーハンドシェイクで送受されるSynパケットの到着時刻で代表する。また、UDPであれば当該セッションで初めて観測されるパケットの到着時刻で代表する。
【００２９】
セッション集約部１０４は、送信元情報が同一で宛先情報の異なるSDグループを対象に、各セッションのトラヒック特性のパターン（トラヒックパターン）の分析結果に基づいて、同一のサービスまたはアプリケーションに係る複数のSDグループを一のSDグループに集約する。
【００３０】
図３は、セッション集約部１０４が、宛先のみ異なるSDグループ間でトラヒックパターンの類似度を算出し、トラヒックパターンが類似する複数のSDグループを集約する方法を模式的に表現した図である。
【００３１】
ここでは、SDグループ#iについて時刻t1で生起したセッションに関連して一連のトラヒックパターンP1が観測されている。同様に、宛先のみが異なるSDグループ#i+1について時刻t2で生起したセッションに関連して一連のトラヒックパターンP2が観測され、同じく宛先のみが異なるSDグループ#i+2について時刻t3で生起したセッションに関連して一連のトラヒックパターンP3が観測されている。
【００３２】
セッション集約部１０４は、各トラヒックパターンP1，P2，P3の類似度を評価する。トラヒックパターンの類似度は、NaiveBayesやクラスタリング等の学習・判別アルゴリズムを用いた分類結果を指標として評価できる。あるいは後に図６を参照して説明するように、トラヒック特性の相互相関の計算結果に基づいて評価するようにしても良い。
【００３３】
その結果、類似度が十分に高いと評価できれば、３つのSDグループ#i，#i+1，#i+2が集約され、各トラヒックパターンP1，P2，P3の出現時刻パターンの算術和（論理和）が求められて集約後のトラヒックパターンとされる。
【００３４】
図示の例では、トラヒックパターンP1の出現時刻パターンが[1/0/0/0/0]であり、これと同一の時間軸上でのトラヒックパターンP2，P3の出現時刻パターンが、それぞれ[0/0/1/0/0]，[0/0/0/0/1]なので、集約後の出現時刻パターンは[1/0/1/0/1]となる。
【００３５】
集約後の出現時刻パターン[1/0/1/0/1]は、後述するセッション生起タイミング特性計算部１０５による自己相関の計算とされ、自己相関が所定の閾値を超えるSDグループのセッションがバックグラウンド通信に識別されることになる。
【００３６】
本実施形態では、各SDグループのトラヒックパターンの類似度を、トラヒック特性の相互相関に基づいて評価すべく、前記セッション集約部１０４は、トラヒック特性分析部１０４ａ，特性数列生成部１０４ｂおよび相関計算部１０４ｃを備える。
【００３７】
トラヒック特性分析部１０４ａは、前記ログ情報管理部１０２に蓄積され、送信元情報が同一で宛先情報の異なるSDグループを対象に、それぞれのトラヒック情報を所定の時間幅（bin）ごとに集計して単位トラヒック特性を計算する。
【００３８】
本実施形態では単位トラヒック特性として、(1) ダウンロード(DL)のデータ転送量またはパケット数、(2) アップロード(UL)のデータ転送量またはパケット数、(3) スループット特性、(4)各種のトラヒック遅延特性（サーバ側RTT遅延、クライアント側RTT遅延、TCP接続遅延など）、(5)パケット間の到着間隔を採用できる。
【００３９】
さらに、(6) DL転送データ量とUL転送データ量との比率(DL/UL)や、(7) DLパケット数とULパケット数との比率(DL/UL)も単位トラヒック特性として採用できる。すなわち、ユーザ主導のフォアグラウンド通信では、例えばWeb閲覧であればコンテンツの閲覧といったDLが主体となるのでDL/UL>>１となる。また、ユーザ主導の通信であってもSNSでは画像のアップロードなどが主体となるのでDL/UL<<１となる。これに対して、バックグラウンド通信では、例えば、少量のデータ送受が主体となり、DL/UL≒１となる。したがって、これらのトラヒック特性は識別性の高い指標となり得る。
【００４０】
さらに、(8) 保留時間(HoldTime)と応答時間(RespTime)との比率、(9) 各種トラヒック特性の時系列変動傾向およびその統計量（観測した複数あるいは全てのbin毎の値をまとめた合計や平均、分散、最大値、最小値など）、(10) セッションの生起数を単位トラヒック特性として採用しても良い。
【００４１】
すなわち、ユーザ主導のフォアグラウンド通信では、例えばWeb閲覧であれば、接続後のDL時間の方が接続遅延よりも大きいので、保留時間と応答時間との比率(HoldTime／RespTime)は１よりも十分に大きくなる。また、Web閲覧では、多種多様な種類およびサイズのコンテンツがアクセス対象や取得対象となるので、トラヒック特性の時系列変動が大きくなる一方、バックグラウンド通信では少量のデータ送受やPush通知の待ち受け系が主体となるので時系列変動が小さくなる。したがって、これらのトラヒック特性も識別性の高い指標となり得る。
【００４２】
図４は、前記トラヒック特性分析部１０４ａによるトラヒック特性の分析方法を説明するための図である。ここでは、TCPコネクションの確立時にクライアント／サーバ間で実行されるTCP_3wayハンドシェークのSYNパケットからキャプチャできたコネクションを例にして説明する。
【００４３】
TCPコネクションについては、端末MHからサーバへ最初に送信されたSYNパケットの到着時刻（コネクション生起時刻）t1と、サーバから端末MHへ返信されたSYN+ACKパケットの到着時刻t2との差分(t2-t1)に基づいてサーバ側RTT（往復）遅延が算出される。
【００４４】
また、前記SYN+ACKパケットの到着時刻t2と端末MHからサーバへ最後に送信されたACKパケットの到着時刻t3との差分(t3-t2)に基づいて、クライアント側RTT遅延が算出される。さらに、前記最初のSYNパケットの到着時刻t1と前記3wayハンドシェーク後に端末MHからサーバへ最初に送信されデータパケットの到着時刻t4との差分(t4-t1)に基づいて、TCP接続遅延が算出される。このような遅延特性は、binごとに離散化して特性数列化し、その相関係数を求めることにより、フォアグラウンド通信判定およびバックグラウンド通信判定の指標の一つとして利用できる。
【００４５】
また、3wayハンドシェーク後に端末MHから最初に送信されるデータの到着時刻t4からFINまたはRSTパケットの到着時刻t5までの差分(t5-t4)、および当該差分時間内にキャプチャされた送受信データ量に基づいて、TCPコネクションのスループット特性が算出される。
【００４６】
このようなスループット特性も、所定幅のbinごとに離散化して特性数列化し、その相関係数を求めることにより、フォアグラウンド通信判定およびバックグラウンド通信判定の指標の一つとして利用できる。
【００４７】
また、前記データの到着時刻t4からFINまたはRSTパケットの到着時刻t5までに観測されたDLまたはULの転送データ量、パケット数あるいはDLとULとの比率も、所定幅のbinごとに離散化して特性数列化し、その相関係数を求めることにより、フォアグラウンド通信判定およびバックグラウンド通信判定の指標の一つとして利用できる。ここで、トラヒック特性の指標として採用する転送データ量やパケット数は、上記のようなペイロードデータに限定ものではなく、各種の制御パケットを含む全転送データ量または全パケット数であっても良い。
【００４８】
なお、パケットのキャプチャがコネクションの途中から開始されているような場合には、得られた到着時刻から可能な分析のみが選択的に行われる。例えば、キャプチャがSYN+ACKパケットから開始されていれば、その到着時刻t2からACKパケットの到着時刻t3までの差分(t3-t2)に基づいて、クライアント側RTT遅延のみが算出される。
【００４９】
また、前記TCPコネクションのスループット特性やTCP接続所要時間は、クライアント側の遅延のみならずサーバが側の遅延にも依存するので、サーバ側遅延が大きいときに算出されたこれらの特性等は、クライアント側の通信品質を正確に代表できない。したがって、前記サーバ側RTT遅延が所定の閾値を超えているとき、あるいはサーバ側遅延を代表できるデータやACKなどのパケット到着間隔が所定の閾値を越えているときに算出されたスループット特性やTCP接続所要時間は、品質分析の対象から除外することが望ましい。
【００５０】
図５は、HTTPセッションを対象とした品質特性の測定方法を説明するためのシーケンスフローであり、HTTPリクエスト(#1)パケットの到着時刻t1と、このリクエストに対して返信されるHTTPレスポンス(#1)パケットの到着時刻t2との時間差(t2-t1)がHTTPレスポンス遅延(RespTime)とされる。また、最初のHTTPリクエスト(#1)パケットの到着時刻t1と最後のHTTPレスポンス(#1)パケットの到着時刻t3との時間差(t3-t1)がHTTP保留時間(HoldTime)とされる。このようなRespTimeとHoldTimeとの比率も、binごとに離散化して特性数列化し、その相関係数を求めることにより、フォアグラウンド通信判定およびバックグラウンド通信判定の指標の一つとして利用できる。
【００５１】
また、最初のHTTPレスポンス(#1)パケットの到着時刻t2と最後のHTTPレスポンス(#1)パケットの到着時刻t3との時間差(t2-t1)がHTTPレスポンス保留時間とされ、その間にダウンロードされた総データ量がHTTP通信データ量とされる。さらに、最初のHTTPリクエスト(#2)パケットの到着時刻t4と最後のHTTPリクエスト(#2)パケットの到着時刻t5との時間差(t5-t4)がHTTPリクエスト保留時間とされ、その間のデータ量がHTTPリクエストデータ量とされる。このようなHTTP通信データ量やHTTPリクエストデータ量も、binごとに離散化して特性数列化し、その相関係数を求めることにより、フォアグラウンド通信判定およびバックグラウンド通信判定の指標の一つとして利用できる。
【００５２】
図２へ戻り、特性数列生成部１０４ｂは、前記binごとに得られた単位トラヒック特性を時系列の要素とする特定数列をSDグループごとに生成する。相関計算部１０４ｃは、送信元情報が同一で宛先情報の異なるSDグループ間で、トラヒック特性の相互相関に基づいて、当該SDグループを一のSDグループに集約するか否かを判定する。
【００５３】
図６は、各SDグループのトラヒックパターンの類似度を、トラヒック特性の相互相関に基づいて評価する方法を示したフローチャートであり、送信元情報が同一で宛先情報の異なる全てのSDグループペアについて繰り返される。
【００５４】
ステップＳ１０１では、宛先情報の異なる２つのSDグループSD1，SD2の一のトラヒック特性が所定の周期τで離散化（BIN化）され、各周期で観測されたトラヒック特性が時系列で数列化される。ステップＳ１０２では、相互相関を算出するためのラグ値jにτ秒が設定される。
【００５５】
ステップＳ１０３では、今回のラグ値jに対応する相互相関係数CC(j)が次式(1)に基づいて計算される。本実施形態では、２つの数列をτずつずらして積の和を算出することで相互相関係数が求められる。
【００５６】
【数１】
0006410309.tif 000002
【００５７】
ステップＳ１０４では、今回の相互相関係数CC(j)の計算結果を、次式(2)に示したように、ラグ値j=0の場合の各自己相関係数AC1(0)，AC2(0)の積の平方根で除すことにより、当該相互相関係数CC(j)が正規化される。
【００５８】
【数２】
0006410309.tif 000003
【００５９】
ステップＳ１０５では、ラグ値jが所定の上限値jmaxに達したか否かが判定される。j≧jmaxでなければ、ステップＳ１０６へ進んでラグ値jを周期τ秒だけ延長した後にステップＳ１０３へ戻り、更新後のラグ値jに対応する相互相関係数CC(j)の計算、正規化が繰り返される。
【００６０】
このような相互相関係数CC(j)の計算は、送信元情報が同一で宛先情報の異なるSDグループが他にもある場合には、計算対象を他のSDグループに切り替えながら繰り返される。
【００６１】
本実施形態では、トラヒック特性の相互相関が所定の閾値を超えるSDグループ同士は、そのトラヒックパターンが類似していると判断し、これらのSDグループが一のSDグループに集約される。
【００６２】
図２へ戻り、セッション生起タイミング特性計算部１０５は、前記分類または集約されたSDグループごとに、後に詳述するように、セッションの生起タイミングに関する特性を計算する。通信識別部１０６は、前記セッションの生起タイミング特性に基づいて当該SDグループのセッションを、フォアグラウンド通信またはバックグラウンド通信に識別する。
【００６３】
[第１実施例]
図７は、本発明の第１実施形態に係るキャプチャ装置の主要部の構成を示した図であり、前記と同一の符号は同一または同等部分を表しているので、その説明は省略する。本実施形態では、前記セッション生起タイミング特性計算部１０５として、SDグループごとに、同一グループに分類または集約された各セッションの生起タイミングに関する自己相関を計算する自己相関計算部１０５Aを採用した点に特徴がある。
【００６４】
図８は、前記自己相関計算部１０５AによるSDグループ内自己相関の計算手順を示したフローチャートであり、全てのSDグループを対象に繰り返される。
【００６５】
ステップＳ２０１では、今回の識別対象となるSDグループ(SD1)に分類されている各セッションの生起タイミングが所定の周期τ秒で離散化（BIN化）され、各周期τ内で生起したセッション数が時系列で数列化される。
【００６６】
ステップＳ２０２では、前記自己相関を算出するためのラグ値（遅れ時間）jとして前記周期と同じτ秒が設定される。ステップＳ２０３では、今回のラグ値jに対応する自己相関係数AC(j)が次式(3)に基づいて計算される。本実施形態では、同一の数列をjずつずらして積の和を算出することで自己相関係数AC(j)が求められる。なお、iは数列の要素識別子、SD(i)は数列のi番目の要素の値、Nは数列長である。
【００６７】
【数３】
0006410309.tif 000004
【００６８】
ステップＳ２０４では、今回の自己相関係数AC(j)の計算結果を、次式(4)に示したように、ラグ値j=0の場合の自己相関係数AC(0)で除すことにより当該自己相関係数AC(j)が正規化される。
【００６９】
【数４】
0006410309.tif 000005
【００７０】
ステップＳ２０５では、ラグ値jが所定の上限値jmaxに達したか否かが判定される。j≧jmaxでなければ、ステップＳ２０６へ進んでラグ値jを周期τ秒だけ延長した後にステップＳ２０３へ戻り、更新後のラグ値jに対応する自己相関係数AC(j)の計算、正規化が繰り返される。
【００７１】
本実施形態によれば、宛先情報が異なるセッションであっても、送信元情報が同一であり、かつセッションのトラヒック特性が類似あるいは高い相関を示すセッションは、同一のサービスまたはアプリケーションに係るセッションとして同一のSDグループに集約され、セッションの生起タイミング特性に基づく通信種別の判定対象とすることができる。
【００７２】
したがって、コンテンツが複数のサーバに分散配置されたり、コンテンツの配信元がユーザ端末の位置に応じて動的に変更、最適化されたりするサービスやアプリケーションに係るセッションであっても、その生起タイミングに関する自己相関性を分析することにより、ユーザ由来・主導のフォアグラウンド通信とバックグラウンド通信とを正確に識別できるようになる。
【００７３】
また、本実施形態によれば、フォアグラウンド通信とバックグラウンド通信とをパッシブなパケットキャプチャにより低コストかつ少数の測定ポイントだけで識別できるようになる。
【００７４】
[第２実施例]
図９は、本発明の第２実施形態に係るキャプチャ装置１の主要部の構成を示した機能ブロック図であり、前記と同一の符号は同一または同等部分を表しているので、その説明は省略する。本実施形態では、前記セッション生起タイミング特性計算部１０５を、生起タイミングベクトル生成部１０５Bおよび周期性評価部１０５Cにより構成した点に特徴がある。
【００７５】
前記生起タイミングベクトル生成部１０５Bはビット数列生成部１０５B1を含み、SDグループごとに各セッションの生起タイミングを、所定の時間幅を有するbinの位置で代表し、これを要素とする生起タイミングベクトルを生成する。
【００７６】
図１０は、前記ビット数列生成部１０５B1の機能を説明するための図であり、セッションが生起したか否かを監視する時間軸上のbin幅をΔt、監視期間をn×Δtとし、例えば第1，2，5，8，9，11，12，14番目の各binでセッションの生起が検知されると、次式(5)のように、セッションの生起が検知されたbinには「1」、セッションの生起が検知されなかったbinには「0」、のセットされたビット数列Tを生成され、その長さはnとなる。
【００７７】
【数５】
0006410309.tif 000006
【００７８】
前記生起タイミングベクトル生成部１０５Bは、ビット数列Tにおいてビットがセットされた各binを、周期の起点とみなす開始binからの距離（bin数）で表現し、これを時系列の要素とする生起タイミングベクトルOCV(occurrence vector)を生成する。開始binを第１番目のbinとすれば、上式(5)のビット数列Tから、次式(6)の生起タイミングベクトルOCV (occurrence vector) が生成され、その長さmは「8」となる。
【００７９】
【数６】
0006410309.tif 000007
【００８０】
周期性評価部１０５Cにおいて、差分計算部１０５C1は、前記生起タイミングベクトルOCVの各要素の組み合わせごとに差分を計算する。
【００８１】
図１１は、前記差分計算部１０C1の機能を説明するための図であり、本実施形態では、生起タイミングベクトルOCVの各要素iを行列(x，y)方向に時系列で配置し、行列の交差欄に各要素の差分を登録してマトリックス表を導出する。
【００８２】
このとき、同一要素の差分は計算不要なので、マトリックス表において対角線上の組み合わせは計算対象から除外される。また、x番目のベクトル要素とy番目のベクトル要素との差分が求まれば、y番目のベクトル要素とx番目のベクトル要素との差分は計算不要なので、対角線よりも下側の組み合わせも全て計算対象から除外される。
【００８３】
さらに、監視期間がbinのn倍すなわちビット数列Tのビット長がnであれば、その半分のn/2を超える生起タイミング周期は判別できないので、ここでは8ビット以上の周期は計算対象から除外される。本実施形態では、以上の各徐外処理を事前に実施し、差分計算の対象を減じることで、計算量の削減が可能になる。
【００８４】
図９へ戻り、要素集合表生成部１０５C2は、差分が同一となる組み合わせの要素集合の表を生成する。
【００８５】
図１２は、前記要素集合表生成部１０C2の機能を説明するための図であり、本実施形態では、差分が同一となる組み合わせの要素集合が予め構築される。例えば、差分「2」に関して図１１のマトリックス表を参照すると、第9ビットと第11ビットとの間隔および第12ビットと第14ビットとの間隔がいずれも「2」なので、差分「2」の要素集合は｛9，11，12，14｝となる。
【００８６】
同様に、差分「3」に関してマトリックス表を参照すると、第2ビットと第5ビットとの間隔、第5ビットと第8ビットとの間隔、第9ビットと第12ビットとの間隔および第11ビットと第14ビットとの間隔がいずれも「3」なので、差分「3」の要素集合は｛2，5，8，9，11，12，14｝となる。以下同様に、差分「4」，「5」，「6」，「7」に関してもマトリックス表を参照して要素集合が構築され、図１２に示したような要素集合表が完成する。
【００８７】
信頼度計算部１０５C3は、前記差分ごとに求められた要素集合に基づいて、当該差分をセッションの生起周期とみなした場合の信頼度を計算する。通信識別部１０６は、各セッションを、その生起タイミングの信頼度に基づいて、フォアグラウンド通信およびバックグラウンド通信のいずれかに識別する。
【００８８】
図１３は、前記信頼度計算部１０５C3による信頼度の計算手順を示したフローチャートであり、本実施形態では、差分Δdごとに得られるベクトル要素列を対象に、開始binを切り替えながら、セッション生起が差分Δdごとに検知されている割合に基づいて信頼度が計算される。
【００８９】
ステップS３０１では、要素数が最大の要素集合が選択される。本実施形態では、差分Δdを「3」として抽出された要素集合｛2，5，8，9，11，12，14｝の要素数が「7」で最多となるので、この要素集合が選択される。ステップS３０２では、セッションの生起周期の起点とみなす開始binに初期値の「1」がセットされる。
【００９０】
ステップS３０３では、前記選択された要素集合｛2，5，8，9，11，12，14｝について、今回の開始binの要素に差分Δdを順次に加算することで期待要素列が求められる。ここでは開始binが「1」なので、時系列で１番目の要素「2」に差分「3」を順次に加算して期待要素列｛2，5，8，11，14｝が求められる。
【００９１】
ステップＳ３０４では、前記選択された要素集合｛2，5，8，9，11，12，14｝と前記期待要素列｛2，5，8，11，14｝とが比較され、期待要素列の各要素が要素集合の各要素と一致するか否かを示す一致数列OCV'が求められる。ここでは、期待要素列｛2，5，8，11，14｝の全ての要素が要素集合｛2，5，8，9，11，12，14｝のいずれかの要素と一致するので、一致数列OCV'として[11111]が得られる。ステップS５では、次式(7)に基づいて、差分「3」の開始bin「1」における信頼度cが算出される。
【００９２】
【数７】
0006410309.tif 000008
【００９３】
ここで、ΠΔd,l (OCV')は一致数列OCV'の長さ（ビット長）であり、上記の例では「5」となる。また、zは生起タイミングが検知されるべきbinでありながら実際には検知されなかったbinの合計数、すなわち一致数列OCV'における「0」の個数である。したがって、上式(7)のzを含む項の値は、数列OCV'が「0」を含めばその個数であり、「0」を含まなければ0となる。上記のように、一致数列OCV'が[11111]であれば「0」を含まないので、上式(7)のzを含む項の値は0となる。したがって、周期「3」の開始bin「1」における信頼度cは、(5-1-0)/(5-1)となって100%となる。
【００９４】
なお、図１２の差分が「2」の要素集合｛9，11，12，14｝について開始binを「1」とした場合を例にして説明すれば、ステップＳ３０３では、時系列で１番目の要素「9」に差分「2」を順次に加算して期待要素列｛9，11，13，15｝が求められる。
【００９５】
ステップＳ３０４では、前記選択された要素集合｛9，11，12，14｝と期待要素列｛9，11，13，15｝とが比較され、ここでは要素「9」，「11」が一致し、「12」，「14」が不一致となるので一致数列OCV'として[1100]が得られ、zが「2」となる。ステップS３０５では、これらを上式(7)に適用することで、開始bin「1」における周期「2」の信頼度cが、(4-1-2)/(4-1)となって33%となる。
【００９６】
このように、本実施形態では通信のバックグラウンドで周期的に確立されるセッションの生起タイミングのように、極めて疎なデータ列を評価するにあたり、疎の区間に対応して多数の「0」を連続して含むビット数列Tではなく、このビット数列Tから生成した生起タイミングベクトルOCV及びOCV'を対象に信頼度計算を行うので、射影後の数列長を短くすることができ、計算量を大幅に減じることが可能となる。
【００９７】
すなわち、分析対象であるビット数列Tの長さが「n」であれば、自己相関や相互相関はこのビット数列Tを対象に算出されるので、その計算量は単純アルゴリズムであればO(n2)、FFT等により高速化してもO(n log n)となる。
【００９８】
これに対して、本実施形態ではOCVの算出において、長さnのビット数列Tに対してn個の要素を一旦全て探索するので、その計算量はO(n)となる。ここで、通信トラヒックを分析対象としてセッションの生起時刻を基に算出したベクトルでは、通信トラヒックデータ全体の大きさ・長さnに対して、生起する時刻が少ないので要素数mが少なくなって疎となり、n＞＞mとなる。
【００９９】
OCVを扱う全ての計算は要素数mに対する計算・処理であり、計算量はO(m2)またはO(m)となる。ここで、n＞＞mなので、O(m2)やO(m)は、O(n2)やO(n log n)よりも極めて小さい。したがって、本実施形態によれば、特にビット数列Tが疎の場合に計算量がO(m)となり、その計算量を他の手法による場合に比べて極めて少なくできる。
【０１００】
図１３へ戻り、ステップS３０６では、開始binがインクリメントされる。ステップS３０７では、開始binが所定の上限位置を超えたか否かが判断され、上限位置に達していなければステップS３０３へ戻り、更新後の開始bin（ここでは、「2」）に関して上記の各処理が繰り返される。
【０１０１】
これに対して、開始binが上限値に達したと判断されるとステップS３０８へ進み、開始binごとに得られた信頼度の中の最高値が信頼度として採用される。
【０１０２】
なお、本実施形態のように開始binが初期値「1」のときに、その信頼度が100%となれば、その後の計算は不要となるので、その時点で信頼度を100%として当該処理を終了するようにしても良い。
【０１０３】
また、開始binを変更しながら信頼度計算を繰り返しても所定の閾値を超える信頼度が得られない場合にはステップS１へ戻り、要素数が次に大きな要素集合を選択して上記の処理を繰り返すようにしても良い。
【０１０４】
前記通信識別部１０６は、算出された信頼度に基づいて、各SDグループのセッションをバックグラウンド通信およびフォアグラウンド通信のいずれかに識別する。本実施形態では、信頼度に例えば80%程度の閾値を設定し、信頼度が当該閾値を超える周期が存在すれば、当該SDグループの注目セッションをバックグラウンド通信に識別し、それ以外であればフォアグラウンド通信に識別する。あるいは、SDグループごとに求まる多数の信頼度を母数として、その90％ile値を閾値としても良いし、尤度判定を採用しても良い。
【０１０５】
なお、上記の第２実施形態では各bin幅を厳密に固定し、bin幅内で生起タイミングが検知されたbinに対してのみ「1」をセットするものとして説明したが、本発明はこれのみに限定されるものではなく、各bin幅は維持したまま、その前後方向に所定の幅で付加期間を設定し、当該付加期間を含めたbin幅内で生起タイミングが検知されたbinに対して「1」をセットするようにしても良い。
【０１０６】
このようにすれば、ネットワークに遅延やジッタが発生し、セッションの生起タイミングがずれて、算出される数列やその周期、信頼度が低くなってしまう場合でも、このような外乱に関わらず安定した周期判定が可能になり、ひいてはフォアグラウンド通信およびバックグラウンド通信の識別を正確に行えるようになる。
【０１０７】
本実施形態によれば、宛先情報が異なるセッションであっても、送信元情報が同一であり、かつセッションのトラヒック特性が類似あるいは高い相関を示すセッションは、同一のサービスまたはアプリケーションに係るセッションとして同一のSDグループに集約され、セッションの生起タイミング特性に基づく通信種別の判定対象とすることができる。
【０１０８】
したがって、コンテンツが複数のサーバに分散配置されたり、コンテンツの配信元がユーザ端末の位置に応じて動的に変更、最適化されたりするサービスやアプリケーションに係るセッションであっても、その生起タイミングに関する周期性を分析することにより、フォアグラウンド通信またはバックグラウンド通信に識別できるようになる。
【０１０９】
また、本実施形態によれば、バックグラウンド通信に係るセッションの生起タイミングのように、極めて疎なデータ列を評価する際、疎の区間に対応して多数の「０」を連続して含むビット数列Tではなく、このビット数列Tから生成した生起タイミングベクトルOCVを対象に信頼度計算を行うので、射影後の数列長を短くすることができ、計算量を大幅に減じることが可能となる。
【０１１０】
さらに、本実施形態によれば、フォアグラウンド通信とバックグラウンド通信とをパッシブなパケットキャプチャにより低コストかつ少数の測定ポイントだけで識別できるようになる。
【符号の説明】
【０１１１】
１０１…通信トラヒック測定部，１０２…ログ情報管理部，１０３…セッション分類部，１０４…セッション集約部，１０４ａ…トラヒック特性分析部，１０４ｂ…特性数列生成部，１０４ｃ…相関計算部，１０５…セッション生起タイミング特性計算部，１０５A…自己相関計算部，１０５B…生起タイミングベクトル生成部，１０５C…周期性評価部，１０６…通信識別部
【図１】
0006410309.tif 000009
【図２】
0006410309.tif 000010
【図３】
0006410309.tif 000011
【図４】
0006410309.tif 000012
【図５】
0006410309.tif 000013
【図６】
0006410309.tif 000014
【図７】
0006410309.tif 000015
【図８】
0006410309.tif 000016
【図９】
0006410309.tif 000017
【図１０】
0006410309.tif 000018
【図１１】
0006410309.tif 000019
【図１２】
0006410309.tif 000020
【図１３】
0006410309.tif 000021