(57)【特許請求の範囲】
【請求項１】
通信トラヒックをフォアグラウンド通信およびバックグラウンド通信のいずれかに識別する通信識別装置において、
ネットワーク上で観測される通信トラヒックを、その送信元情報および宛先情報の組み合わせに固有のSDグループに分類する分類手段と、
SDグループごとにトラヒック特性の時系列変動を分析するトラヒック特性分析手段と、
前記トラヒック特性の時系列変動を単位時間幅のbinごとに離散化してトラヒック特性数列を生成する特性数列生成手段と、
前記トラヒック特性数列の相関特性を計算する相関計算手段と、
前記相関特性に基づいて通信トラヒックを識別する通信識別手段とを具備したことを特徴とする通信識別装置。
【請求項２】
前記相関計算手段は、SDグループごとにトラヒック特性の自己相関を計算する自己相関計算手段を具備し、
前記通信識別手段は、自己相関が所定の第１閾値を超える通信トラヒックをバックグラウンド通信に識別することを特徴とする請求項１に記載の通信識別装置。
【請求項３】
前記相関計算手段は、一のSDグループのトラヒック特性と他の一のSDグループにおいてバックグラウンド通信に識別された通信トラヒックのトラヒック特性との相互相関を計算する相互相関計算手段を具備し、
前記通信識別手段は、相互相関が所定の第２閾値を超える通信トラヒックをバックグラウンド通信に識別することを特徴とする請求項２に記載の通信識別装置。
【請求項４】
前記相関計算手段は、一のSDグループのトラヒック特性とバックグラウンド通信に識別された他の一のSDグループのトラヒック特性との相互相関を計算する相互相関計算手段を具備し、
前記通信識別手段は、トラヒック特性の自己相関が前記第１閾値を超えず、前記バックグラウンド通信に識別された他の一のSDグループのトラヒック特性との相互相関が所定の第２閾値を超える通信トラヒックをバックグラウンド通信に識別することを特徴とする請求項２に記載の通信識別装置。
【請求項５】
前記特性数列生成手段は、ダウンロードの転送データ量、アップロードの転送データ量、ダウンロードとアップロードとの転送データ量の比率、ダウンロードのパケット数、アップロードのパケット数、ダウンロードとアップロードとのパケット数の比率、スループット特性、トラヒック遅延特性、保留時間と応答時間との比率、トラヒック特性の時系列変動傾向およびセッション生起数の少なくとも一つをbinごとに計算して特性数列の時系列要素とすることを特徴とする請求項１ないし４のいずれかに記載の通信識別装置。
【請求項６】
前記通信識別手段は、一のトラヒック特性に基づいてバックグラウンド通信と判定されなかった通信トラヒックに対して他の一のトラヒック特性に基づいて更に判定を行い、予定された複数のトラヒック特性の少なくとも一つに関して、その相関特性が所定の閾値を超えているとバックグラウンド通信と判定することを特徴とする請求項１ないし５のいずれかに記載の通信識別装置。
【請求項７】
前記通信識別手段は、前記予定された複数のトラヒック特性の全てに関してバックグラウンド通信と判定されなかった通信トラヒックをフォアグラウンド通信と判定することを特徴とする請求項６に記載の通信識別装置。
【請求項８】
コンピュータが、通信トラヒックをフォアグラウンド通信およびバックグラウンド通信のいずれかに識別する通信識別方法において、
ネットワーク上で観測される通信トラヒックを、その送信元情報および宛先情報の組み合わせに固有のSDグループに分類する手順と、
SDグループごとにトラヒック特性の時系列変動を分析する手順と、
前記トラヒック特性の時系列変動を単位時間幅のbinごとに離散化してトラヒック特性数列を生成する手順と、
前記トラヒック特性数列の相関特性を計算する手順と、
前記相関特性に基づいて通信トラヒックを識別する手順とを含むことを特徴とする通信識別方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信トラヒックを識別する通信識別方法および装置に係り、特に、通信端末がフォアグラウンド（Foreground）で行う通信とバックグラウンド(Background)で行う通信とを識別する通信識別方法および装置に関する。
【背景技術】
【０００２】
通信端末が実行する通信の内容を識別する技術が研究されている。特許文献１には、通信トラヒック量の時系列変化やデータから、フーリエ変換等を用いて周期性を算出する手法が開示されている。特許文献２には、通信トラヒックをフロー毎に測定・集約し、フロー毎のトラヒック特性から、周波数解析手法であるケプストラム分析を適用することにより、フローからアプリ（通信サービスの種別）を識別する技術が開示されている。
【０００３】
特許文献３には、通信トラヒックをフロー毎に測定・集約し、フロー毎のトラヒック特性から特徴量を算出し、機械学習を適用することにより、フローから通信サービスの種別（アプリケーション）を識別する技術が開示されている。
【０００４】
また、近年におけるモバイル端末の爆発的な普及によりさまざまなサービスが台頭し、端末ユーザの通信要求操作を契機に生起されるフォアグラウンド通信のみならず、端末ユーザの通信要求操作とは無関係に、アプリケーションが自身に都合の良い任意のタイミングでサーバ等と通信するバックグラウンド通信が生起されるようになってきた。
【０００５】
各通信方式は、重要度、緊急度、データサイズ、遅延やジッタに対する許容度、端末ユーザの主観評価に与える影響などが異なるので、各通信方式を識別できれば様々な用途で活用できる。
【０００６】
しかしながら、特許文献１は、目的が異常検知すなわち平常時からの傾向変化検知であり、フォア／バックグラウンド通信を識別できない。特許文献２，３は、アプリケーションや通信サービスの識別を目的とする技術であり、フォア／バックグラウンド通信は識別できない。
【０００７】
このような技術課題に対して、本発明の発明者等は、ネットワーク上で観測される各セッションを、その送信元情報および宛先情報の組み合わせに固有のSDグループに分類すると共に、SDグループごとに各セッションの生起タイミングに関する自己相関を計算し、自己相関係数が高いセッションはバックグラウンド通信に識別する通信識別装置を発明し、特許出願（特許文献４）した。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】特開2010-283668号公報
【特許文献２】特開2012-105043号公報
【特許文献３】特開2013-127504号公報
【特許文献４】特願2014-37083号
【発明の概要】
【発明が解決しようとする課題】
【０００９】
特許文献４によれば、ユーザ由来・主導のフォアグラウンド通信とバックグラウンド通信とを、パッシブなパケットキャプチャにより低コストかつ少数の測定ポイントだけで識別できるようになる。
【００１０】
しかしながら、TCP/HTTPセッションについては、長時間にわたり張り続けられる場合や、ネットワーク状況やユーザ移動等の外乱により不規則、不定期のタイミングで切断されてしまう場合もある。このような場合には、セッション生起時刻や周期性が崩れてしまい、本来の状況を観測できないので、時刻相関（周期性）を検出できない場合がある。
【００１１】
本発明の目的は、上記の技術課題を解決し、通信端末がフォアグラウンドでセッションを確立して行う通信とバックグラウンドでセッションを確立して行う通信とを、ネットワーク状況やユーザ移動等によりセッションの生起時刻の周期性が乱れる場合でも正確に識別できる通信識別方法および装置を提供することにある。
【課題を解決するための手段】
【００１２】
上記の目的を達成するために、本発明は、通信トラヒックをフォアグラウンド通信およびバックグラウンド通信のいずれかに識別する通信識別装置において、以下の構成を具備した点に特徴がある。
【００１３】
(1) ネットワーク上で観測される通信トラヒックをSDグループに分類する手段と、SDグループごとにトラヒック特性の時系列変動を分析する手段と、トラヒック特性の時系列変動の相関を計算する相関計算手段と、トラヒック特性の相関に基づいて通信トラヒックを識別する通信識別手段とを具備した。
【００１４】
(2) 相関計算手段は、SDグループごとにトラヒック特性の自己相関を計算する自己相関計算手段を具備し、通信識別手段は、自己相関が所定の第１閾値を超える通信トラヒックをバックグラウンド通信に識別するようにした。
【００１５】
(3) 相関計算手段は、一のSDグループのトラヒック特性と他の一のSDグループにおいてバックグラウンド通信に識別された通信トラヒックのトラヒック特性との相互相関を計算する相互相関計算手段を具備し、通信識別手段は、相互相関が所定の第２閾値を超える通信トラヒックをバックグラウンド通信に識別するようにした。
【００１６】
(4) トラヒック特性の時系列変動を単位時間幅のbinごとに離散化してトラヒック特性数列を生成する特性数列生成手段を具備し、相関計算手段はトラヒック特性数列の相関特性を計算するようにした。
【００１７】
(5) 通信識別手段は、一のトラヒック特性に基づいてバックグラウンド通信と判定されなかった通信トラヒックに対して他の一のトラヒック特性に基づいて改めて判定を行い、予定された複数のトラヒック特性の少なくとも一つに関して、その相関が所定の閾値を超えている通信トラヒックをバックグラウンド通信と判定するようにした。
【発明の効果】
【００１８】
本発明によれば、以下のような効果が達成される。
(1)通信端末が実行する通信のうち、トラヒック特性の自己相関が高い通信トラヒックは、ユーザ操作とは無関係にOSやアプリケーションが自動的、機械的に実行するバックグラウンド通信に識別されるので、ネットワーク状況やユーザ移動等によりセッションの生起時刻の周期性が乱れる場合でも、ユーザ由来・主導のフォアグラウンド通信とバックグラウンド通信とを、パッシブなパケットキャプチャにより低コストかつ少数の測定ポイントだけで識別できるようになる。
【００１９】
(2)バックグラウンド通信に識別された通信トラヒックとの相互相関が高く、バックグラウンド通信である可能性が高い通信トラヒックはバックグラウンド通信に識別できるので、バックグラウンド通信を確実に識別できるようになる。
【００２０】
(3)自己相関が低くても、相互相関の高い通信トラヒックはバックグラウンド通信に識別されるので、同一のバックグラウンド処理内で複数のサーバとの間に同様の手順でセッションの確立を繰り返す通信については、自己相関にかかわらずバックグラウンド通信に識別できるようになる。
【００２１】
(4) トラヒック特性の時系列を離散化して特性数列化し、その相関を計算するようにしたので、相関係数の定量的な計算が容易になる。
【００２２】
(5) 一のトラヒック特性に関する相関が低くても、他の一のトラヒック特性に関する相関が高ければバックグラウンド通信に識別できるので、一部のトラヒック特性に対してのみ特異的に高い相関を示す通信トラヒックもバックグラウンド通信に識別できるようになる。
【図面の簡単な説明】
【００２３】
【図１】本発明の通信識別方法が適用されるネットワークの構成を示した図である。
【図２】キャプチャ装置の一実施形態の構成を示した機能ブロック図である。
【図３】TCPコネクションにおけるトラヒック特性の測定方法を示した図である。
【図４】HTTPセッションにおけるトラヒック特性の測定方法を示した図である。
【図５】自己相関の計算手順を示したフローチャートである。
【図６】相互相関の計算手順を示したフローチャートである。
【図７】第１の通信識別手順を示したフローチャートである。
【図８】第２の通信識別手順を示したフローチャートである。
【発明を実施するための形態】
【００２４】
以下、図面を参照して本発明の実施の形態について詳細に説明する。図１は、本発明の通信識別方法が適用されるネットワークの構成を示したブロック図である。
【００２５】
サービス提供範囲の各エリアには無線基地局BSが設置され、当該エリア内の無線移動端末MN（例えば、スマートフォンやタブレット端末）は前記各無線基地局BSに収容される。各無線基地局BSは無線アクセス網RANに接続され、前記無線アクセス網RANはコア網のゲートウェイ(GW)に接続される。前記コア網はインターネットエクスチェンジ(IX)においてインターネットと接続される。
【００２６】
前記インターネットには、各MNからの要求に応答してサービスを提供する各種のサーバが接続されている。本実施形態では、各MNと各サーバとの間のトラヒックを集約できる回線として、無線アクセス網RANとコア網とを接続する回線Lに、通信識別装置としてのキャプチャ装置１が接続されている。
【００２７】
図２は、前記キャプチャ装置１の一実施形態の主要部の構成を示した機能ブロック図であり、ここでは、本発明の説明に不要な構成は図示が省略されている。本発明のキャプチャ装置１は、汎用のコンピュータやサーバに各機能を実現するアプリケーション（プログラム）を実装することで構成できる。あるいはアプリケーションの一部がハードウェア化またはROM化された専用機や単能機としても構成できる。
【００２８】
通信トラヒック検知部１０１は、前記回線L上で送受されるパケットをキャプチャして、そのセッション種別（TCP、HTTP、UDPなど）、送信元情報、宛先情報を含む各種のトラヒック情報をログ情報管理部１０２に記録する。
【００２９】
セッション分類部１０３は、各セッションをその送信元情報(S)および宛先情報(D)の組み合わせに基づいていずれかのSDグループに分類する。すなわち、送信元情報(S)および宛先情報(D)のいずれもが同一のセッションは同一のSDグループに分類され、異なるセッションは別のSDグループに分類される。本実施形態では、送信元情報として送信元IPアドレスを採用し、宛先情報として宛先IPアドレスおよびポート番号を採用する。
【００３０】
各セッションの生起タイミングは、HTTPセッションであればHTTP Requestパケットの到着時刻で代表し、TCPセッションであればセッション確立時に実行されるスリーハンドシェイクで送受されるSynパケットの到着時刻で代表し、UDPであれば当該セッションで初めて観測されるパケットの到着時刻で代表する。
【００３１】
トラヒック特性分析部１０４は、ログ情報管理部１０２に蓄積された同一SDグループのトラヒック情報を所定の時間幅（bin）ごとに集計して単位トラヒック特性を計算する。
【００３２】
本実施形態では単位トラヒック特性として、(1) ダウンロード(DL)のデータ転送量またはパケット数、(2) アップロード(UL)のデータ転送量またはパケット数、(3) スループット特性、(4)各種のトラヒック遅延特性（サーバ側RTT遅延、クライアント側RTT遅延、TCP接続遅延など）を採用できる。
【００３３】
また、(5) DL転送データ量とUL転送データ量との比率(DL/UL)や、(6) DLパケット数とULパケット数との比率(DL/UL)も単位トラヒック特性として採用できる。すなわち、ユーザ主導のフォアグラウンド通信では、例えばWeb閲覧であればコンテンツの閲覧といったDLが主体となるのでDL/UL>>１となる。また、ユーザ主導の通信であってもSNSでは画像のアップロードなどが主体となるのでDL/UL<<１となる。これに対して、バックグラウンド通信では、例えば、少量のデータ送受が主体となり、DL/UL≒１となる。したがって、これらのトラヒック特性は識別性の高い指標となり得る。
【００３４】
さらに、(7) 保留時間(HoldTime)と応答時間(RespTime)との比率、(8) 各種トラヒック特性の時系列変動傾向およびその統計量（観測した複数あるいは全てのbin毎の値をまとめた合計や平均、分散、最大値、最小値など）、(9) セッションの生起数を単位トラヒック特性として採用しても良い。すなわち、ユーザ主導のフォアグラウンド通信では、例えばWeb閲覧であれば、接続後のDL時間の方が接続遅延よりも大きいので、保留時間と応答時間との比率(HoldTime／RespTime)は１よりも十分に大きくなる。また、Web閲覧では、多種多様な種類およびサイズのコンテンツがアクセス対象や取得対象となるので、トラヒック特性の時系列変動が大きくなる一方、バックグラウンド通信では少量のデータ送受やPush通知の待ち受け系が主体となるので時系列変動が小さくなる。したがって、これらのトラヒック特性も識別性の高い指標となり得る。
【００３５】
特性数列生成部１０５は、前記binごとに得られた単位トラヒック特性を時系列の要素とする特定数列をSDグループごとに生成する。相関計算部１０６は、SDグループごとに生成されたトラヒック特性数列の自己相関（SDグループ内自己相関係数）を計算する自己相関計算部１０６ａ、および送信元が同一で異なるSDグループごとに生成されたトラヒック特性数列の相互相関（SDグループ間相互相関係数）を計算する相互相関計算部１０６ｂを含む。すなわち、本実施形態における相互相関の計算対象は、送信元ユーザが同一のSDグループ同士となる。
【００３６】
通信識別部１０７は、前記自己相関および相互相関の計算結果を所定の閾値と比較し、各比較結果に基づいて各SDグループのセッションをバックグラウンド通信およびフォアグラウンド通信のいずれかに識別する。
【００３７】
図３は、前記トラヒック特性分析部１０４によるトラヒック特性の分析方法を説明するための図である。ここでは、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ごとに離散化して特性数列化し、その相関係数を求めることにより、フォアグラウンド通信判定およびバックグラウンド通信判定の指標の一つとして利用できる。
【００４７】
図５は、SDグループ内自己相関の計算手順を示したフローチャートであり、主に特性数列生成部１０５および自己相関計算部１０６ａによりSDグループごとに実行される。
【００４８】
ステップＳ１０１では、トラヒック特性の一つが所定幅の周期τ秒で離散化（BIN化）され、各binのトラヒック特性（単位トラヒック特性）を要素とするトラヒック特性数列が生成される。例えば、トラヒック特性としてDLパケット数に着目した場合、各周期τで観測されたDLパケット数を時系列要素とする特性数列が生成される。ステップＳ１０２では、自己相関を算出するためのラグ値（遅れ時間）jとして前記周期と同じτ秒が設定される。
【００４９】
ステップＳ１０３では、今回のラグ値jに対応する自己相関係数AC(j)が次式(1)に基づいて計算される。本実施形態では、同一の特性数列をjずつずらして積の和を算出することで自己相関係数AC(j)が求められる。なお、iは数列の要素識別子、SD(i)は数列のi番目の要素の値、Nは数列長である。
【００５０】
【数１】
0006418638.tif 000002
【００５１】
ステップＳ１０４では、今回の自己相関係数AC(j)の計算結果を、次式(2)に示したように、ラグ値j=0の場合の自己相関係数AC(0)で除すことにより当該自己相関係数AC(j)が正規化される。
【００５２】
【数２】
0006418638.tif 000003
【００５３】
ステップＳ１０５では、ラグ値jが所定の上限値jmaxに達したか否かが判定される。j≧jmaxでなければ、ステップＳ１０６へ進んでラグ値jを周期τ秒だけ延長した後にステップＳ１０３へ戻り、更新後のラグ値jに対応する自己相関係数AC(j)の計算、正規化が繰り返される。
【００５４】
図６は、相互相関の計算手順を示したフローチャートであり、主に特性数列生成部１０５および相互相関計算部１０６ｂにより、送信元情報(S)が同一で宛先情報(D)の異なる全てのSDグループペアについて繰り返される。ここでは、SDグループSD1のトラヒック特性を、宛先情報(D)の異なる他のSDグループSD2のトラヒック特性との関係に基づいて識別する場合を例にして説明する。
【００５５】
ステップＳ２０１では、今回の計算対象となる２つのSDグループSD1，SD2の一のトラヒック特性が所定の周期τで離散化（BIN化）され、各周期で観測されたトラヒック特性が時系列で数列化される。ステップＳ２０２では、相互相関を算出するためのラグ値jにτ秒が設定される。
【００５６】
ステップＳ２０３では、今回のラグ値jに対応する相互相関係数CC(j)が次式(3)に基づいて計算される。本実施形態では、２つの数列をτずつずらして積の和を算出することで相互相関係数が求められる。
【００５７】
【数３】
0006418638.tif 000004
【００５８】
ステップＳ２０４では、今回の相互相関係数CC(j)の計算結果を、次式(4)に示したように、ラグ値j=0の場合の各自己相関係数AC1(0)，AC2(0)の積の平方根で除すことにより、当該相互相関係数CC(j)が正規化される。
【００５９】
【数４】
0006418638.tif 000005
【００６０】
ステップＳ２０５では、ラグ値jが所定の上限値jmaxに達したか否かが判定される。j≧jmaxでなければ、ステップＳ２０６へ進んでラグ値jを周期τ秒だけ延長した後にステップＳ２０３へ戻り、更新後のラグ値jに対応する相互相関係数CC(j)の計算、正規化が繰り返される。このような自己相関係数CC(j)の計算は、送信元情報が同一のSDグループが他にもある場合には、計算対象を他のSDグループに切り替えながら繰り返される。
【００６１】
次いで、前記相関計算部１０６および通信識別部１０７が連携して、各SDグループのセッションをフォアグラウンド通信およびバックグラウンド通信のいずれかに識別する手順について説明する。
【００６２】
図７は、第１の通信識別方法を示したフローチャートであり、ステップＳ３０１では、ネットワークから収集されたトラヒック情報が、前記セッション分類部１０３により、その送信元情報及び宛先情報に基づいてSDグループ化される。ステップS３０２では、トラヒック特性の一つが今回の識別指標として選択される。ここでは、DLパケット数が選択されたものとして説明を続ける。
【００６３】
ステップS３０３では、前記トラヒック特性分析部１０４および特性数列生成部１０５により、DLパケット数がbinごとに収集されて離散化され、各離散値を要素とする特性数列が生成される。ステップS３０４では、前記相関計算部１０６の自己相関計算部１０６ａにより、前記特性数列の自己相関係数ACがラグ値jごとに計算される。
【００６４】
ステップＳ３０５では、ラグ値jごとに計算された各自己相関係数AC(j)が所定のバックグラウンド判定閾値（第１閾値）ACrefと比較される。第１閾値ACrefを超える自己相関係数AC(j)が一つでも存在すればステップＳ３０６へ進み、当該SDグループのセッションがバックグラウンド通信に識別される。
【００６５】
これに対して、第１閾値ACrefを超える自己相関係数AC(j)が一つも存在しなければステップS３０７へ進み、DLパケット数以外の他のトラヒック特性を指標とした判定が完了したか否かが判定される。予定されている全てのトラヒック特性を指標とした判定が完了していなければステップS３０２へ戻り、注目するトラヒック特性を、例えばスループット特性や各種の遅延特性に切り替えて上記の各処理が繰り返される。
【００６６】
このようにして、予定されている各トラヒック特性を指標とする全ての判定が完了しても、依然としてバックグラウンド通信と判定されなければステップS３０８へ進み、注目したSDグループのセッションがフォアグラウンド通信と判定される。
【００６７】
なお、上記に実施形態では、ステップS３０４において自己相関係数ACが計算されるものとして説明したが、本発明はこれのみに限定されるものではなく、予めバックグラウンド通信に識別されているトラヒック特性との相互相関係数CCが計算されるようにしても良い。この場合、ステップS３０４では相互相関係数CCが所定のバックグラウンド判定閾値（第２閾値）CCrefと比較されることになる。
【００６８】
本実施形態によれば、トラヒック特性の自己相関が高いセッションは、ユーザ操作とは無関係にOSやアプリケーションが自動的、機械的に実行するバックグラウンド通信に識別されるので、ネットワーク状況やユーザ移動等によりセッションの生起時刻の周期性が乱れる場合でも、ユーザ由来・主導のフォアグラウンド通信とバックグラウンド通信とを、パッシブなパケットキャプチャにより低コストかつ少数の測定ポイントだけで識別できるようになる。
【００６９】
また、本実施形態によれば、自己相関が低くても、バックグラウンド通信に識別された通信トラヒックの特性数列との相互相関が高く、バックグラウンド通信である可能性が高いセッションはバックグラウンド通信に識別できるので、バックグラウンド通信を確実に識別できるようになる。
【００７０】
さらに、本実施形態によれば、一のトラヒック特性に関する相関が低くても、他の一のトラヒック特性に関する相関が高ければバックグラウンド通信に識別されるので、一部のトラヒック特性に対してのみ特異的に高い相関を示すバックグラウンド通信も確実に識別できるようになる。
【００７１】
図８は、第２の通信識別方法を示したフローチャートであり、ステップＳ４０１では、ネットワークから収集されたトラヒック情報が、前記セッション分類部１０３により、その送信元情報及び宛先情報に基づいてSDグループ化される。ステップS４０２では、トラヒック特性の一つが今回の識別指標として選択される。ここでも、DLパケット数が選択されたものとして説明を続ける。
【００７２】
ステップS４０３では、前記トラヒック特性分析部１０４および特性数列生成部１０５により、DLパケット数がbinごとに収集されて離散化され、各離散値を要素とする特性数列が生成される。ステップS４０４では、前記相関計算部１０６の自己相関計算部１０６ａにより、前記特性数列の自己相関係数ACがラグ値jごとに計算される。
【００７３】
ステップＳ４０５では、ラグ値jごとに計算された各自己相関係数AC(j)が所定のバックグラウンド判定閾値ACrefと比較される。閾値ACrefを超える自己相関係数AC(j)が一つでも存在すればステップＳ４０６へ進み、当該SDグループのセッションがバックグラウンド通信に識別される。
【００７４】
これに対して、閾値ACrefを超える自己相関係数AC(j)が一つも存在しなければステップS４０７へ進み、DLパケット数以外の他のトラヒック特性を指標とした判定が完了したか否かが判定される。予定されている全てのトラヒック特性を指標とした判定が完了していなければステップS４０２へ戻り、注目するトラヒック特性を切り替えて上記の各処理が繰り返される。
【００７５】
このようにして、予定されている各トラヒック特性を指標とする判定が全て完了しても依然としてバックグラウンド通信と判定されなければステップS４０８へ進み、これまでにバックグラウンド通信と判定されたトラヒック特性の一つが注目される。
【００７６】
ステップＳ４０９では、トラヒック特性の一つが今回の識別指標として選択される。ステップS４１０では、前記トラヒック特性分析部１０４および特性数列生成部１０５により、DLパケット数がbinごとに収集されて離散化され、各離散値を要素とする特性数列が生成される。
【００７７】
ステップS４１１では、前記相関計算部１０６において、前記生成された特性数列と前記バックグラウンド通信に識別されている通信トラヒックの特性数列との相互相関係数CC(j)が前記相互相関計算部１０６ｂによりラグ値jごとに計算される。
【００７８】
ステップＳ４１２では、ラグ値jごとに計算された各相互相関係数CC(j)が所定のバックグラウンド判定閾値CCrefと比較される。閾値CCrefを超える相互相関係数CC(j)が一つでも存在すればステップＳ４１４へ進み、当該SDグループのセッションがバックグラウンド通信に識別される。
【００７９】
これに対して、閾値CCrefを超える相互相関係数CC(j)が一つも存在しなければステップS４１３へ進み、DLパケット数以外の他のトラヒック特性を指標とした判定が全て完了したか否かが判定される。未判定の指標が残っていればステップS４０９へ戻り、注目するトラヒック特性を切り替えて上記の各処理が繰り返される。
【００８０】
このようにして、予定されている各トラヒック特性を指標とした判定が全て完了しても依然としてバックグラウンド通信と判定されなければ、ステップS４１５へ進んでフォアグラウンド通信と判定される。
【００８１】
本実施形態によれば、自己相関が低くても、相互相関の高いセッションはバックグラウンド通信に識別されるので、同一のバックグラウンド処理内で複数のサーバとの間に同様の手順でセッションの確立を繰り返す通信については、自己相関にかかわらずバックグラウンド通信に識別できるようになる。
【００８２】
なお、上記の各実施形態ではラグ値jが固定値であるものとして説明したが、本発明はこれのみに限定されるものではなく、自己相関や相互相関が増加する時間幅を適応的に算出し、相関係数が所定の閾値を超える割合が所定量以上となる値を利用しても良いし、あるいは分布値（80%ile値や90%ile値など）や尤度が所定値以上となる値を利用するようにしても良い。
【符号の説明】
【００８３】
１…キャプチャ装置，１０１…通信トラヒック検知部，１０２…ログ情報管理部，１０３…セッション分類部，１０４…トラヒック特性分析部，１０５…特性数列生成部，１０６…相関計算部，１０６ａ…自己相関計算部，１０６ｂ…相互相関計算部，１０７…通信識別部
【図１】
0006418638.tif 000006
【図２】
0006418638.tif 000007
【図３】
0006418638.tif 000008
【図４】
0006418638.tif 000009
【図５】
0006418638.tif 000010
【図６】
0006418638.tif 000011
【図７】
0006418638.tif 000012
【図８】
0006418638.tif 000013