JP7184125B2 - トラヒック分析装置、方法及びプログラム - Google Patents

Description

（関連出願についての記載）
本発明は、日本国特許出願：特願２０１８－０４７２７９号（２０１８年３月１４日出願）の優先権主張に基づくものであり、同出願の全記載内容は引用をもって本書に組み込み記載されているものとする。
本発明は、トラヒック分析装置、方法及びプログラムに関する。

通信サービスの高度化により、通信事業者の性能指標（例えば主要性能指標（Key Performance Indicator）：KPI）は、例えば通信品質（Quality of Service：QoS）から、アプリ品質（例えば、Quality of Experience (QoE)やQuality of control (QoC)）に移行しつつある。一例として、ITU-T（International Telecommunication Union Telecommunication Standardization Sector）では、Web閲覧（Web-browsing）/動画のQoEが策定されている（Recommendation ITU-T G.1031）。

今後、アプリ品質に基づくネットワーク制御やネットワーク設計が重要視されることが想定される。例えばITU-Tにおいて、Webアクセス（ITU-T Recommendation G.1030：Estimating end-to-end performance in IP networks for data applications）、動画配信（Recommendation ITU-T P.1203:Parametric bitstream-based quality assessment of progressive download and adaptive audiovisual streaming services over reliable transport）のQoEが定義されている。機械制御の世界でもネットワーク越しの制御（ネットワーク化システム）の検討が進んでいる。例えばネットワーク越しでの機械制御のパフォーマンスの指標（QoP：Quality of PerformanceやQoC）の議論が進むものと思料される。

近時、例えば、モノがインターネットにつながるIoT（Internet of Things）等の普及に伴い、通信利用者側の通信品質に対するニーズも高度化している。例えばIoT等では（IoT以外のアプリケーションの場合も含む）、アプリケーションの動作状態が変わる場合がある。IoTのアプリケーションとして、IoTセンサカメラ（車載カメラ等）が撮像した映像（動画）データを、例えばナビゲーションデータ等とともに、ネットワークを介してサーバ（クラウド）等に送信し、サーバ側で受信データをリアルタイムに分析し、分析結果に基づき遠隔制御や遠隔支援（例えば車の自動運転や走行支援）等を行うアプリケーションでは、ネットワークのスループット等の変動に応じた映像配信（リアルタイム映像配信）を行うようにしてもよい。また、ウェアラブルカメラ等を用いた物体認識アプリケーションでは、該ウェアラブルカメラからの映像データを受け取ったサーバとウェアラブルカメラとが協調して物体認識を行う場合と、ウェアラブルカメラ単体で対象物体を追尾する場合とでは、必要なスループットは異なる。さらに、IoTデバイスとしてドローン搭載カメラによる空撮映像をリアルタイム中継する場合、ドローンからの映像配信やドローンのフライト情報（位置情報、高度、加速度情報等）の送信、ドローンへのコマンド設定等の各動作モードで、必要なスループットは異なる。なお、ネットワーク（例えば無線網、コアネットワーク、WAN（Wide Area Network）等）では、電子メールや、静止画、動画（映像）、音声（通話）等、様々な通信トラヒックが、例えば同一ネットワーク上を流れることになるが、これらの通信トラヒックは、通信サービス毎に異なる特性を持つことが知られている。

今後、通信事業者には、
・ 通信利用者の通信品質に対するニーズの高度化、
・ アプリ単位の要件に応じた通信、
・ 刻々と変わるアプリケーションの利用状況等に応じた通信サービスの提供等、
が求められることになる。このため、通信事業者では、通信サービスやトラヒックに関わるアプリケーション状態の変化の把握が課題となる。

通信事業者が、「刻々と変わる利用条件 (アプリケーション状態) に応じて最適な通信品質」を提供し、通信利用者の満足度(QoE: Quality of Experience) を高めるためには、きめ細やかな通信制御が必要とされる。このため、例えば、
・ 制御対象パラメータの増加（通信帯域、伝送遅延の揺らぎ（ジッタ等）など）、
・ 細かな制御周期、
が必要とされる。

しかしながら、通信事業者（通信事業者が提供するネットワーク機器等）で取得できる情報には制限がある。

例えば、ネットワークを流れる暗号化トラヒックの増大、トラヒック多様化により、トラヒックの中身を覗くDeep Packet Inspection（DPI）の手法には限界がある。また、個人保護法の観点により、DPIそのものが使えなくなる可能性もある。暗号化やプライバシーの観点で通信データの中身をみることはできない。

ネットワークを流れるトラヒックから取得できる情報は、
・ 5タプル（5-tuple (例えば、送信元/宛先のIP（Internet Protocol）アドレス/ポート、プロトコル)と、
・ トラヒックパターン(例えば、スループット、パケットサイズ、パケット送信間隔（到着間隔）等)などである。

ここで、トラヒックのスループットは単位時間あたりのデータ転送量（bits per second）をいう。なお、RFC(Request for Comments: IETF（Internet Engineering Task Force）による仕様等) 1242の3.17では、スループットは、"The maximum rate at which none of the offered frames are dropped by the device."(その機器によって送信フレームが損失しない最大レート)と定義されているが、基本的にこの定義から逸脱しない。

トラヒックフローは、IPヘッダフィールド内に同一の情報を持つパケットのグループ（宛先IPアドレスとポート番号、送信元IPアドレスとポート番号が等しいパケットの集合）で構成される。トラヒック発信元のアドレス（source address）、トラヒックの宛先アドレス（destination address）、発信元ポート、宛先ポート、プロトコル番号は「5タプル」とも称せられる。

前述した通信事業者の提供するネットワークを構成するネットワーク機器は、通信利用者（例えば端末）がどのようなアプリケーションを使っているのか、そのアプリケーションが、いかなる状態で動作しているのかを、直接知る術がない。

機械学習ベースのトラヒック分析では、トラヒックノイズによる誤検知が高いことが知られている。なお、機械学習ベースのトラヒック分析の一例として、例えば非特許文献２には、教師有り単純ベイズ分類器（Supervised naive Bayesian classifier）を用いてアプリケーションカテゴリごとにトラヒック(Transmission Control Protocol(TCP）コネクション単位)を分類する。入力として、終端したTCPコネクションから得られる特徴量（Flow duration(フロー継続時間)、TCP port（TCPポート）、Packet inter-arrival time(パケット到着時間)(平均、分散等)、Payload size（ペイロードサイズ）(平均、分散等)、Effective Bandwidth based upon entropy（エントロピーに基づく有効帯域幅）、Fourier Transform of the Packet inter-arrival time（パケット到着時間のフーリエ変換））と、当該TCPコネクションで行われていた通信のカテゴリ情報が用いられる。出力として、例えば以下のアプリケーションカテゴリごとの分類結果(各カテゴリに割り当てられたネットワークトラヒック)が得られる。非特許文献２の開示は、フロー（TCPコネクション）の継続時間（Flow duration）を利用しているため、コネクションが終端していることが必須である。

松原靖子、 櫻井保志、Christos Faloutsos、"大規模時系列データの特徴自動抽出（Fully Automatic Mining of Large Time-series Datasets）"情報処理学会論文誌:データベース, Vol. 7, No. 2, pp. 37-50, 2014, 6月 Andrew W. Moore, Denis Zuev, "Internet Traffic Classification Using Bayesian Analysis Techniques," SIGMETRICS'05 (Proceedings of the 2005 ACM SIGMETRICS international conference on Measurement and modeling of computer systems), June 6-10, 2005, Banff, Alberta, Canada Richman, Moorman, "Physiological time-series analysis using approximate entropy and sample entropy," American Journal of Physiology, 2000 June

前述したように、通信事業者（通信機器）で取得できる情報には制限がある。通信トラヒックを覗くことなく、アプリケーション品質（「アプリ品質」とも略記される）を満たす通信サービスの提供を実現可能とするシステムが望まれる。

例えば、ネットワーク上に流れるトラヒックのスループットから、アプリケーション状態を推定する場合、様々な複合的な要因から予測不能に時系列データが変動する。例えば急なスループットの落ち込み等があると、その時系列データの変動を誤認識してしまい、アプリケーション状態の推定精度が上がらないことが本願発明者らにより確認されている。

アプリケーション状態の推定精度を上げるために、通信トラヒックの複数の時系列データ（例えばタイミング同期している）を用いて推定する場合、逆に、推定精度が低下する場合がある。

図１において、時系列データ（波形）１１ａ、１１ｂ、１１ｃは、通信トラヒックのスループット、パケットのデータサイズ、パケット到着間隔等の時系列データ（各時系列データはタイミング同期している）の例を模式的に示す図である。時系列データ１１ａ、１１ｂは同一のタイミングｔ_ｋで状態の遷移が検出されるが、時系列データ１１ｃは、どの時点で状態が切り替わっているのか明確でない波形パターンであり、該タイミングｔ_ｋ等において、状態遷移が認められない。

このような三つ組み波形に基づき、アプリケーション状態を推定する場合、時系列データ１１ａ、１１ｂでは、アプリケーション状態の遷移は推定されるが、時系列データ１１ｃではアプリケーション状態の遷移が検出されないことから、時系列データ１１ａ、１１ｂ、１１ｃの全体では、状態遷移の基準を満たさず、時刻ｔ_ｋにおいてアプリケーション状態の遷移と判定されない場合がある。この場合、推定精度が劣化し、通信トラヒックからアプリケーション状態の学習モデルを作成する場合において、モデルの精度等も劣化する。

また、アプリケーション状態の推定に用いる時系列データの数に対して、モデル作成のための計算量（ステップ数）は線形に増加する。

本発明の目的は、通信トラヒックの時系列データについて、計算量の増大を抑制しながら、時系列データからの状態の推定精度を確保可能とする装置、方法、プログラムを提供することにある。

本発明の一形態によれば、通信トラヒックに関する複数の時系列データのそれぞれの情報量を計算する情報量計算部と、前記複数の時系列データの情報量に基づき、前記複数の時系列データの中から、分析対象とする少なくとも１つの時系列データを選択する入力情報選択部と、を備えたトラヒック分析装置が提供される。

本発明の一形態によれば、通信トラヒックに関する複数の時系列データのそれぞれの情報量を計算し、前記複数の時系列データの情報量に基づき、前記複数の時系列データの中から、分析対象とする少なくとも１つの時系列データを選択するトラヒック分析方法が提供される。

本発明の一形態によれば、通信トラヒックに関する複数の時系列データのそれぞれの情報量を計算する情報量計算処理と、前記複数の時系列データの情報量に基づき、少なくとも１つの時系列データを選択する入力情報選択処理と、をコンピュータに実行させるプログラムが提供される。

本発明によれば、上記プログラムを記録した非一時的なコンピュータ可読可能な媒体（a non-transitory computer readable medium）（例えばRAM(Random Access Memory)、ROM(Read Only Memory)、EEPROM(Electrically Erasable and Programmable ROM)等の半導体メモリやHDD(Hard Disk Drive)、CD(Compact Disc)、DVD(Digital Versatile Disc)）が提供される。

本発明によれば、通信トラヒックの時系列データについて、計算量の増大を抑制しながら、時系列データからの状態の推定精度を確保可能としている。

時系列データの例を説明する図である。 本発明の例示的な実施形態１の構成例を説明する図である。 本発明の例示的な実施形態１の処理手順を説明する流れ図である。 （Ａ）乃至（Ｃ）は実施形態のシステム構成例を説明する図である。 （Ａ）は時系列データのエントロピー、（Ｂ）は時系列データのサンプルエントロピーを説明する図である。 時系列データのサンプルエントロピーを説明する図である。 （Ａ）サンプルエントロピーとアプリケーション状態の推定精度の関係を示す図である。（Ｂ）、（Ｃ）は、時系列データのサンプルエントロピーとアプリケーション状態の推定精度を示す図である。 （Ａ）はシナリオ毎の比較例と実施形態の推定精度を示す図である。（Ｂ）は（Ａ）の実施形態の推定精度から比較例の推定精度を差し引いた差分（改善量）を示す図である。 本発明の例示的な実施形態２の構成例を説明する図である。 （Ａ）、（Ｂ）は、入力情報生成部へ入力される時系列データと、入力情報生成部から出力される時系列データの一例を模式的に示す図である。 （Ａ）、（Ｂ）は、入力情報生成部へ入力される時系列データと、入力情報生成部から出力される時系列データの一例を模式的に示す図である。 本発明の例示的な実施形態３の構成例を説明する図である。 連続混合型HMMを模式的に説明する図である。 （Ａ）は通信トラヒックの時系列データと分布、（Ｂ）は連続HMMの状態（出力確率分布）と状態遷移確率、（Ｃ）は推定された状態シーケンスをそれぞれ模式的に説明する図である。 （Ａ）は、HMM、（Ｂ）は階層ＨＨＭを説明する図である。 （Ａ）は時系列データについて連続HMMから得られた状態シーケンスを説明する図である。（Ｂ）は（Ａ）の状態の推移に対する離散HMMを説明する図である。（Ｃ）は推定された状態シーケンスをそれぞれ模式的に説明する図である。 本発明の例示的な実施形態４を説明する図である。 本発明の例示的な実施形態４のアプリケーション状態判定部の処理を説明する図である。 本発明の例示的な実施形態４の作用効果を説明する図である。 本発明の例示的な実施形態５を説明する図である。 本発明の例示的な実施形態６を説明する図である。 本発明の例示的な実施形態７を説明する図である。 本発明の例示的な実施形態７を説明する図である。 本発明の例示的な実施形態８を説明する図である。 本発明の例示的な実施形態９を説明する図である。 本発明の例示的な実施形態１０を説明する図である。 本発明の例示的な実施形態１１を説明する図である。 本発明の基本的な一形態を説明する図である。

本発明の実施形態について説明する。本発明の一形態によれば、通信トラヒックに関する複数の時系列データの情報量を算出し、前記情報量に基づき、前記複数の時系列データの中から、分析対象の時系列データを選択する。図２８を参照すると、本発明の一形態において、トラヒック分析装置１００は、通信トラヒックに関する複数の時系列データのそれぞれの情報量を計算する情報量計算部１０２と、前記複数の時系列データの情報量に基づき、前記複数の時系列データの中から、分析対象として、少なくとも１つの時系列データを選択する入力情報選択部１０３と、を備えている。

本発明の一形態において、通信トラヒックに関する複数の時系列データは、時間軸を共通とした複数の属性の時系列データであってもよい。複数の属性の時系列データは複数種の時系列データとも称される。

本発明の一形態において、情報量として、通信トラヒックの時系列データにおける変化点（状態の遷移点）等、時系列データの特徴的なパターンの抽出の適合性を示す指標(criteria)となる情報量が用いられる。

本発明の一形態において、トラヒック分析装置１００は、入力情報選択部１０３で選択された通信トラヒックの時系列データに基づき、前記時系列データのパターンとその遷移を表現するための確率的な状態遷移モデルを作成するモデル作成部（後述される図２の１０４等)を備えるようにしてもよい。

本発明の一形態において、トラヒック分析装置１００では、
・ 入力情報選択部１０３で選択された通信トラヒックの時系列データでの状態（アプリケーション状態）の推移を、隠れマルコフモデルによる状態遷移モデルでモデル化し、
・ 前記時系列データにおいて類似する変動パターンに対応する複数の隠れマルコフ状態を一まとめにし、
・ 一まとめとした複数の隠れマルコフ状態を、前記隠れマルコフモデルの１つ上位の層の隠れマルコフモデルの１つの状態で表す階層モデルを作成するようにしてもよい。

本発明の一形態によれば、例えば通信トラヒックのソースとなるアプリケーション状態の推定に用いる時系列データの数を、特徴的パターンを抽出し易い時系列データに絞り込むことによって、モデル作成のための計算量（ステップ数）の増大を抑制可能とし、さらにアプリケーション状態の推定精度の向上に貢献する。

＜実施形態１＞
図２は、本発明の例示的な実施形態１を説明する図である。実施形態１のトラヒック分析装置１００は、通信トラヒックの複数種の時系列データの中から、特徴（状態）を抽出し易い時系列データを検出することで、モデル作成にあたり、余計な時系列データを入力せず、アプリケーション状態の推定精度を向上させる。図２を参照すると、トラヒック分析装置１００は、通信トラヒック観測部１０１と、情報量計算部１０２、入力情報選択部１０３と、モデル作成部１０４を備えている。

通信トラヒック観測部１０１は、ネットワーク上に流れる通信トラヒック（解析対象の通信トラヒック）をモニタし、スループット、パケット到着間隔、パケットサイズ等、複数種の時系列データを取得する。

情報量計算部１０２は、時系列データがどれくらい特徴的なパターンの抽出に適合しているかを示す指標となる情報量を計算する。

入力情報選択部１０３は、各時系列データの情報量に基づき、１つ又は複数の時系列データを選択する。

モデル作成部１０４は、入力情報選択部１０３で選択された前記通信トラヒックの時系列データを分析し、前記時系列データのパターンとその遷移を表現するための確率的な状態遷移モデルを作成（学習）する。なお、トラヒック分析装置１００の各部はそれぞれ通信手段を介して接続する分散ユニットとして構成してもよい。

図３は、実施形態１に係るトラヒック分析方法を説明する流れ図である。なお、図３は、図２のトラヒック分析装置１００における処理動作を説明する図でもある。

通信トラヒックを観測し該観測対象の通信トラヒックに関して、時間軸を共通とした複数（互いに属性の異なる複数種）の時系列データを取得する（Ｓ１１）。時間軸を共通とした複数の時系列データとは、サンプリング時刻、サンプリング周期を同一とするか、時系列データの各サンプルデータが各時間窓での平均値等である場合、該時間窓の開始時点及び長さは複数の時系列データで共通としてもよい。時間窓は、所定時間単位で時間軸をスライドさせる移動窓であってもよい。時間窓（移動窓）の長さは、予め定められた単位時間であってもよい。

通信トラヒックの複数の時系列データの情報量（時系列データの特徴的パターンの抽出し易さを示す指標となる）を取得する（Ｓ１２）。

通信トラヒックの時系列データの情報量に基づき、分析対象となる、少なくとも１つの時系列データを選択する（Ｓ１３）。

選択された前記通信トラヒックの時系列データを分析し、前記時系列データのパターンとその遷移を表現するための確率的な状態遷移モデルを作成（学習）する（Ｓ１４）。

次に、図２の各部について説明する。

＜通信トラヒック観測部＞
通信トラヒック観測部１０１は、通信トラヒックの時系列データとして、
・ スループット[bps（bit per second）]、
・ 単位時間当たりのパケット到着間隔（平均値）[sec]、
・ 単位時間当たりの平均パケットサイズ（平均値）[bytes]、
・ 単位時間当たりのパケット数等を取得してもよい。あるいは、例えばIoT向けの時系列入力情報（例えば、加速度の時系列情報や無線品質の変化等）の時系列データであってもよい。

通信トラヒックのスループット時系列データx={x(1),…,x(N)}、パケットサイズ時系列データy={y(1),…,y(N)}、パケット送信間隔（受信間隔）の時系列データz={z(1),…,z(N)}は、タイミング同期しているものとする。すなわち、i番目の要素x(i), y(i) ,z(i)は同一のタイミング（又は期間）でサンプリング（又は、該期間で平均化等、統計処理）されたスループット、パケットサイズ、パケット送信（受信）間隔とする。

通信トラヒック観測部１０１は、ネットワークを流れるプロトコルデータ単位（Protocol Data Unit：PDU）であるパケット（フレーム）をキャプチャし、各パケットのヘッダ等を解析し、例えばパケットの送信元アドレス、送信先アドレスや、ポート、長さ（パケットサイズ）、パケット頻度、パケット送信時間（パケット受信時間間隔）間隔等を解析するパケットキャプチャ（パケットモニタ）で構成してもよい。なお、PDUは、ISO（International Organization for Standardization）のOSI（Open Systems Interconnection）参照モデルのデータリンク層（レイヤ２（L2））では「フレーム」、ネットワーク層（レイヤ３（L3））では「パケット」という。

図４は、トラヒック分析装置１００を備えた通信システムを例示する図である。図４（Ａ）に示すように、パケットキャプチャ１０（「パケットモニタ」ともいう）は、通信ネットワーク５０内に配置されたネットワークノード２０（例えばルータ（L3スイッチ）等の中継装置）等に接続し、通信ネットワーク５０上に流れるパケット、例えば端末３０とサーバ４０間で送信・受信されるパケットをキャプチャする。ネットワークノード２０において、モニタ対象の１つ又は複数のポート（複製元ポート）をパケットキャプチャ１０が接続するポート（複製先ポート）にミラーリングすることで、パケットキャプチャ１０は、ネットワークノード（スイッチ）２０の該１つ又は複数のポート（複製元ポート）を通過する全てのパケット（送信パケット、受信パケット）をモニタすることができる。パケットキャプチャ１０では、ネットワークインタフェースカード（NIC）をプロミスキャスモード（promiscuous mode）に設定し、自分宛のデータパケットでない信号も取り込むようにする。パケットキャプチャ１０は、パケットの宛先、送信元のIPアドレス等を参照するだけでよい。このため、リクエストヘッダ等を含めて通信トラヒックは暗号化されていてもよい。

なお、図４（Ａ）において、ネットワークノード２０は、コアネットワーク内のゲートウェイ・ノード、あるいは、無線アクセスネットワークの基地局等であってもよい。トラヒック分析装置１００は、パケットキャプチャ１０で算出された、端末－サーバ間、又は端末―端末間の通信トラヒック（スループット）の時系列データを取得し、トラヒックの解析を行う。トラヒック分析装置１００を、通信ネットワーク５０を介して接続する不図示のクラウドサーバ等に実装するようにしてもよい。図４（Ｂ）には、トラヒック分析装置１００内に、図４（Ａ）のパケットキャプチャ１０を実装し、パケットキャプチャ１０とトラヒック分析装置１００を一体に実装した構成が示されている。あるいは、図４（Ｃ）に示すように、パケットキャプチャ１０、トラヒック分析装置１００を、通信ネットワーク５０のノード（例えばルータ等の中継装置、無線基地局やMEC（Mobile Edge Computing）サーバ等、コアネットワーク上のゲートウェイやサーバ等）に実装する構成としてもよい。あるいは、端末３０、又は、端末３０と通信するサーバ４０等に実装することで、端末３０に流れてくるパケット、又は端末３０からサーバ４０に送信されるパケットをキャプチャしトラヒックを解析するようにしてもよい。なお、図４（Ａ）乃至図４（Ｃ）において、通信ネットワーク５０は、端末・サーバ間の通信に制限されるものでなく、端末間の音声通話サービス（Voice Over IP等）を提供するものであってもよい。

＜情報量計算部＞
情報量計算部１０２は、通信トラヒック観測部１０１でモニタされた通信トラヒックのスループット時系列データx={x(1),…,x(N)}、パケットサイズ時系列データy={y(1),…,y(N)}、パケット送信間隔（受信間隔）の時系列データz={z(1),…,z(N)}に関して、情報量を計算する。

図５（Ａ）の時系列データ１２ａにおいて、変化点の検出、すなわち、どこが状態の遷移時点であるかを検出することは、困難である。図５（Ａ）の時系列データ１２ｂでは、時刻t_ｃでパターンが変化しており、どこが状態の遷移時点（区切り目）であるかは明らかであるといえる。

時系列データの複雑さが増加すればするほど、アプリケーション状態の区切り目がわからず、アプリケーション状態の推定が困難になる。図５（Ａ）の時系列データ１２ａは、パターンの変化点が抽出し難く、アプリケーション状態の推定として選択したくない時系列データである。

一方、図５（Ａ）の時系列データ１２ｂは、パターンの変化点が抽出し易く、アプリケーション状態の推定として選択したい時系列データである。

エントロピーは情報理論でデータ圧縮のし易さ=マイニングのし易さの指標として用いられる。確率分布Pが与えられたとき、各事象A∈Ωの選択情報量：-log₂P(A)の期待値：

(1)
をPの平均情報量 （エントロピー）という。

有限集合{x₁,…,x_N}上の値をとる確率変数Xが確率分布Pに従う場合には、XのエントロピーH(X)は、次式で与えられる。

(2)

上記エントロピーH(X)は、時系列データ（例えば時間的に特徴が変化するデータ）の選択に向いていない。

図５（Ａ）の時系列データ１２ａと１２ｂにおいて、それぞれのエントロピーH(X)が等しくなるか、差があってもわずかである場合がある。例えば、図５（Ａ）の時系列データ１２ａと１２ｂにおいて、状態を２値s0、s1と仮定する。この場合、時系列データ１２ａ（タイミングt₁～t_Nのサンプルデータ{x₁,…,ｘ_N}）では、ほぼ交互に、状態s0とs1に対応する値をとる。すなわち、状態s0とs1の頻度はほぼ同じであることから、s0の生起確率p(s0)は1/2、s1の生起確率p(s1)は1/2となる。したがって、
H(X)＝-(1/2)log₂(1/2)-(1/2)log₂(1/2)=log₂(2)=1 (3)
となる。

一方、時系列データ１２b（タイミングt₁～t_Nのサンプルデータ{y₁,…,y_N}）では、タイミングt₁～t_c（t_c:状態変化時点、1<ｃ<N）のデータは状態s0と、タイミングt_cからｔ_Nのデータは状態s1に対応している。
s0の生起確率p(s0)はp(s0)＝c/N、
s1の生起確率p(s1)=1-c/Nとなる。したがって、エントロピーは、
H(X）＝-(c/N)log₂(c/N)-(1-c/N)log₂(1-c/N) (4)

ここで、c/N≒1/2とすると、時系列データ１２bのエントロピー：H（X）≒１となる。時系列データ１２a、１２bのエントロピーH（X）は同一となるか、差はあってもわずかである場合がある。このため、エントロピーH(X)では、時系列データ１２ａと１２ｂの間にあるパターンの相違点を有効に検出することができない。

本実施形態では、時系列データ内の類似パターンの発生量（頻度）を定量的に評価するために、類似パターンが多く出現する場合、値が小さくなり、類似パターンが出現しにくい場合、値が大きくなるサンプルエントロピー（Sample Entropy：SampEn）を用いる。サンプルエントロピーは、時系列の複雑度を評価する指標として用いられる。

図５（Ｂ）の時系列データ１２ａと１２ｂは、図５（Ａ）の時系列データ１２ａと１２ｂと同一である。時系列データ１２ａのサンプルエントロピー（SampEn）は大、時系列データ１２ｂのサンプルエントロピー（SampEn）は小となる。入力情報選択部１０３では、サンプルエントロピー（SampEn）が小さい時系列データ１２ｂを選択する。

図６は、サンプルエントロピー（SampEn）を説明する図である。観測された時系列データに対して、移動窓（sliding window）を用いて、類似パターンがどれくらいの回数繰り返し発生しているかを示す指標を計算する。なお、図６は、移動窓（sliding window）の長さは固定（ｍ）としている。移動窓（sliding window）は予め定められた時間ステップ（単位時間も含み得る）で時間軸上を移動される。

＜ステップ１＞
窓iと窓jの時系列データ（「テンプレートベクトル」ともいう）を次式（5）、（6）とする。

(5)

(6)
なお、各要素は一定時間τでサンプルされるものとする。

これらのチェビシェフ距離（Chebyshev distance）：

(7)
を計算する。

チェビシェフ距離は以下で与えられる。

(8)

ただし、距離はチェビシェフ距離に制限されるものでなく、ユークリッド距離：

(9)

であってもよい。

＜ステップ２＞

(10)
となる回数（テンプレートベクトル対の個数）をカウントする（ｒは類似していると判定するための閾値）。ステップ１、２を長さm+1とmで試行する。

(11)
となる回数（テンプレートベクトル対の個数）をAとし、

(12)
となる回数（テンプレートベクトル対の個数）をBとする。

サンプルエントロピーは、次式(13)で与えられる。

(13)

Ａの定義から、AはBよりも小さいか等しい。したがって、SampEnの値は、非負値（０か正値）となる。SampEnの値が小さいことは、時系列データの自己相似性（self-similarity）が高いか、ノイズが小さいことを示している。なお、時系列データが自己相似的であるとは、変動パターンが時間スケールに応じた周期性を多重に畳み込んだ構造をいう。ｒは、例えば、時系列データの標準偏差（standard deviation）等に基づき決定される。

＜入力情報選択部＞
図２の入力情報選択部１０３は、通信トラヒック観測部１０１で取得された複数の時系列データのうち、情報量計算部１０２で計算されたサンプルエントロピー（SampEn）の値の最も小さい時系列データを選択するようにしてもよい。

あるいは、入力情報選択部１０３は、通信トラヒック観測部１０１で取得された複数の時系列データのうち、情報量計算部１０２で計算されたサンプルエントロピー（SampEn）の値が最小の時系列データ、及び、次に小さい時系列データ等、複数個の時系列データを選択するようにしてもよい。

あるいは、入力情報選択部１０３は、通信トラヒック観測部１０１で取得された複数の時系列データのうち、情報量計算部１０２で計算されたサンプルエントロピー（SampEn）の値が予め定められた閾値以下のサンプルエントロピーを持つ時系列データをすべて選択するようにしてもよい。

あるいは、入力情報選択部１０３は、通信トラヒック観測部１０１で取得された複数の時系列データのうち、特定の時系列データは常に選択するものとし、少なくとも他の１つの時系列データとして、複数の時系列データの中から、サンプルエントロピー（SampEn）の値が最小の時系列を選択するようにしてもよい。

例えば図１において、時系列データ１１ａのスループットは常に選択するものとし、パケットのデータサイズ、パケット到着間隔の時系列データのサンプルエントロピーを計算し、入力情報選択部１０３では、サンプルエントロピーが閾値よりも大きなパケット到着間隔の時系列データを外し、スループットとパケットのデータサイズを選択するようにしてもよい。

＜モデル作成部＞
図２のモデル作成部１０４は、入力情報選択部１０３で選択された時系列データを分析し、前記時系列データのパターンとその遷移を表現するための確率的な状態遷移モデルを作成し、記憶部１０５に格納する。作成されたモデルは、入力情報選択部１０３で選択された通信トラヒックの時系列データに基づき、該通信トラヒックのアプリケーション状態の推移の推測等に用いられる。通信トラヒックに関わるアプリケーションは、該通信トラヒックの送信元であってもよい（あるいは、送信側と連携し該送信側から転送される通信トラヒックの受信に関わるアプリケーションであってもよい）。

確率的な状態遷移モデルは、後述される隠れマルコフモデル（Hidden Markov Model）であってもよい。モデル作成部１０４は、入力情報選択部１０３で選択された通信トラヒックの時系列データの状態の推移を、隠れマルコフモデル（Hidden Markov Model：HMM）による状態遷移モデルでモデル化し、その際、前記時系列データの類似する変動パターンに対応する複数の隠れマルコフ状態を一まとめにして、前記隠れマルコフモデルの１つ上位の層の隠れマルコフモデルの１つの隠れ状態として表した階層モデルを構成するようにしてもよい。

階層モデルは、連続HMMと、１つ上位の層の離散HMM（出力は離散値）を含む構成としてもよい。

モデル作成部１０４において、連続HMMの複数の隠れマルコフ状態を一まとめにした離散HMMのある隠れ状態の出力確率（例えば、0.0から1.0までのいずれかの値をとる）によって、連続HMMで一まとめにした複数の隠れマルコフ状態の出力を表現する階層モデルを生成するようにしてもよい。すなわち、該階層モデルでは、離散HMMの当該ある隠れ状態の自己遷移確率と出力確率によって、連続HMMで一まとめにした複数の隠れマルコフ状態の出力の推移を表すようにしてもよい。

図７（Ａ）は、サンプルエントロピー（SampEn）とアプリケーション状態の推定精度の関係を説明する図である。図７（Ａ）の散布図（scatter-plot）において、横軸はサンプルエントロピー、縦軸はアプリケーション状態推定精度（％）である。

図７（Ｂ）は、時系列データ（Data）（サンプルエントロピー（SampEn）＝0.09、アプリケーション状態の推定精度＝82.6％）を例示する図である。図７（C）は、別の時系列データ（Data）（サンプルエントロピー＝2.82、アプリケーション状態の推定精度：41.3%）を例示する図である。以上から、サンプルエントロピーの値の小さい時系列データの方がアプリケーション状態の推定精度が高いことが確認された。

アプリケーション状態の推定精度の計算は、後の実施形態の説明で参照される図１８に示すように、予め登録された状態の推移が既知のアプリケーションにおける遷移のシーケンス７０３と、既知のアプリケーション状態に対応する通信トラヒックの時系列データ７０１に対して、階層HMM等に基づき、推測されたアプリケーション状態の遷移のシーケンス７０２の相互相関関数（類似度）を計算することで、計算するようにしてもよい。相互相関係数＝１、すなわち、完全一致の場合、推定精度は１００％となる。

図８（Ａ）は、本発明の実施形態と比較例における、通信トラヒックからのアプリケーション状態の推定精度を対比して示す図である。この比較例は、図２の情報量計算部１０２、入力情報選択部１０３を備えず、通信トラヒック観測部１０１で取得された複数（種）の時系列データに基づきモデルを作成する。なお、図８（Ａ）では、通信トラヒックからのアプリケーション状態の推定精度を、複数の異なるシナリオ（ユースケース）１～３５のそれぞれについて実施形態と比較例の推定精度が図示されている。図８（Ａ）において、横軸は、シナリオ（ユースケース）番号、縦軸はアプリケーション推定精度である。各シナリオに関して、左側（例えばシナリオ１２の８０２）が比較例のアプリケーション推定精度、右側（例えばシナリオ１２の８０１）が本発明の実施形態のアプリケーション推定精度である。なお、シナリオ（ユースケース）は、スマートフォン、IoTデバイス等のアプリケーションに基づき、区分されている。

図８（Ｂ）は、図８（Ａ）における本発明の実施形態のアプリケーション推定精度（８０１）から比較例のアプリケーション推定精度を差し引いた値を示す図である。図８（Ｂ）のシナリオ１２は、図８（Ａ）の８０１から８０２を差し引いた値に対応する。図８（Ｂ）から、３５のシナリオのうちのほとんどにおいて、本発明の実施形態のアプリケーション推定精度が優っており、５０％以上、上回っているケースも、７シナリオ以上ある。以上から、通信トラヒックからのアプリケーション推定における、本発明の有効性が確認された。

＜実施形態２＞
図９は、本発明の例示的な実施形態２を説明する図である。図９を参照すると、図２の構成に加えて、入力情報生成部１０６を備えている。他の構成は、図２の実施形態１と同様であるため、以下では、入力情報生成部１０６について説明する。

入力情報生成部１０６は、通信トラヒック観測部１０１で取得した通信トラヒックの時系列データ（スループットなど）を利用して新たな入力データを生成し、情報量計算部１０２に供給する。通信トラヒックの時系列データをX={x(1), x(2),…, x(T)}とする。入力情報生成部１０６で生成した時系列データを Z={z(1), z(2),…, z(T)}とする。入力情報生成部１０６では、時系列データZを通信トラヒックの時系列データXの差分に基づき生成してもよい。

(14)

図１０（Ｂ）は、τ＝１として、図１０（Ａ）の時系列データXの隣り合うデータの差分を計算した時系列データZの一例を示す図である。

(15)

これは、差分フィルタ（ハイパスフィルタ）であり、直流（DC：Direct Current）成分等をカットオフする。なお、τ＝2として、時系列データXの１つ隣り合うデータの差分を計算した時系列データZとしてもよい。

図１０（Ａ）に示す時系列データ１００１では、サンプル時刻t_kのデータx(k)とサンプル時刻t_k+1のデータx(k+1)間に、オフセット差＝Δがある。このため、モデル作成部１０４では、図１０（Ａ）の時系列データ１００１において、時刻t_kまでの区間をアプリケーション状態A、時刻t_k+1からt_qまでの区間を状態B、時刻tqからの区間を状態Cと推定し、状態A→B→Cと遷移する状態遷移モデルを作成する。

しかしながら、図１０（Ａ）の状態Aと推定された時系列パターンａ（直流オフセットを除去した時系列データの変動パターン）は、図１０（Ａ）の状態Cと推定された時系列パターンａ（直流オフセットを除去した時系列データの変動パターン）と同一である。モデル作成部１０４において、図１０（Ａ）の時系列データ１００１に基づき、アプリケーション状態の推定に用いるモデルを作成すると、時系列パターンａに固有の状態を正しく推定することができない。

そこで、式(14)において、例えばτ＝１として、時系列データXの各データの差分をとると、図１０（Ｂ）に示すように、図１０（Ａ）の時系列データ１００１において、状態Aと状態Cの間の直流レベルのオフセットDは除去（eliminate）される。図１０（Ｂ）の時系列データ１００２は、図１０（Ａ）の時系列データ１００１の状態Aと状態Cの間のオフセットDを除去したものである。この結果、時系列データ１００２において、時刻t_kまでの区間は状態A、時刻t_k+1からt_qまでの区間は状態B'、時刻t_qからの区間は状態Aと推定され、モデル作成部１０４では、状態A→B’→Aと遷移する状態遷移モデルを作成する。なお、図１０（Ｂ）において、時刻t_kとt_k+1のサンプル値の差分z(tk+1)=x(tk+1)-x(tk)＝D（オフセット差）は、時刻t_k+1でのZの値D（ひげ（グリッチ）状の瞬時的パルス）として表されている。このため、モデル作成部１０４では、時刻t_k+1からt_qまでの区間を、図１０（Ａ）の状態Bとは異なる状態B’と推定している。図１０（Ｂ）の状態B’において、時刻t_k+1のサンプル値D（瞬時的パルスの振幅（波高値））は、時刻t_kとt_k+1で時系列データの直流レベルにDの変動があることを表している。図１０（Ｂ）の時系列データZは、例えば時系列データの変動パターンのうち交流変動パターン（振動パターン）の特徴抽出を行う応用例等に有効である。

入力情報生成部１０６では、時系列データ１００１に対して、移動窓を用いて、窓内統計量（平均、分散など）を計算してもよい。例えば図１１（Ａ）に示すように、窓幅をｗとして、移動平均：

(16)
を計算する。これはローパスフィルタ(平滑フィルタ)である。図１１（Ｂ）の時系列データ１１０２は、図１１（Ａ）の時系列データ１１０１に対して移動窓による移動平均を計算した結果の一例を示す図である。なお、図１１（Ａ）では、説明の簡単のため、時系列パターンａ（振動パターン）の区間の振幅平均を０とし、図１１（Ｂ）では、式(16)の値を０としている。図１１（Ａ）の時刻t_k+1における直流レベルの遷移を、図１１（Ｂ）では、矩形波の立ち上がりエッジとして１次のローパスフィルタの出力波形として模式的に示している。

図１１（Ｂ）に示すように、図１１（Ａ）の時系列パターンａはカットされ、直流レベルの変動が抽出される。トラヒック分析処理において、時系列パターンのうち、直流レベルの変動等、変動の特徴が重要であり、交流変動やランダム雑音等を除去する応用例等に有効である。

入力情報生成部１０６は、通信トラヒック観測部１０１で取得した通信トラヒックの時系列データ（スループットなど）の通信ノイズ（グリッチ状のノイズ等）を除去するフィルタとして機能させるようにしてもよい。

入力情報生成部１０６は、分析対象のトラヒックのネットワーク環境に対して、対応するネットワーク環境のノイズ特性パラメータを予め取得するようにしてもよい。例えば、分析対象のトラヒックのネットワーク環境は、図４（Ａ）、図４（Ｂ）のネットワークノード２０から取得してもよい。例えばネットワークノード２０が基地局であれば無線網、コアネットワークノードであれば、携帯電話網、また光ルータ等の場合、固定回線（固定網）となる。入力情報生成部１０６は、ノイズ特性パラメータに基づき、ノイズ波形（時系列データ）を生成し、通信トラヒックの時系列データからノイズ波形（時系列データ）を差し引いた時系列データを生成し、情報量計算部１０２に供給する構成としてもよい。

＜実施形態３＞
図１２は、本発明の例示的な実施形態３のトラヒック分析装置１００の構成を例示する図である。図１２を参照すると、トラヒック分析装置１００は、図９の実施形態２の構成に加えて、アプリケーション情報観測部１０７と、原因分析部１０８を備えている。図１２において、入力情報生成部１０６は、通信トラヒック観測部１０１で取得した通信トラヒック情報に加えて、アプリケーション情報観測部１０７からアプリケーション情報を入力することで、アプリケーション状態の分析をアプリケーションレベルで可能としている。

アプリケーション情報観測部１０７では、アプリケーションレベルに関連する情報として、例えば車載のセンサ（加速度を検出する加速度センサや車体の姿勢等を検出するジャイロセンサ等）から、走行中（運転中）か停止中か、走行中の場合、走行モード（アイドリング、加速、定速、減速）、さらに、直進、左折、右折等のステアリング状況等を取得するようにしてもよい。

入力情報生成部１０６は、必要な時系列データの時間区間等を抽出し、情報量計算部１０２に供給する。例えば、車の自動運転支援システム等において、通信トラヒックが、車載カメラで取得した映像情報（動画）をサーバに送信するものであるとする。この場合、当該車が駐車又は停車している場合、当該駐車、停車期間における通信トラヒックの時系列データの全ては、サーバにおいて、安全運転・自動運転支援の制御のために必要でない場合がある。この場合、アプリケーション情報観測部１０７からのアプリケーション情報（駐車又は停車中等）に基づき、入力情報生成部１０６は、通信トラヒックの時系列データを所定時間間隔で間引くか、通信トラヒックの時系列データを所定時間間隔の移動窓での平均化処理を行い、情報量計算部１０２に供給するようにしてもよい。一方、車が走行中の場合、動画の品質を確保するために、入力情報生成部１０６は、通信トラヒックのスループット等の時系列データをそのまま情報量計算部１０２に供給するようにしてもよい。

あるいは、アプリケーション情報観測部１０７では、例えば、アプリケーション品質であるQoE（Quality of Experience）を計算（評価）するようにしてもよい（例：Web QoE、動画QoE等）。QoEは、Webページ、動画の配信先のノード（端末、サーバ等）側で測定したQoEを収集し、アプリケーション状態に関連付けて記憶保持しておき、通信トラヒック観測部１０１で取得した通信トラヒック（スループット）や、アプリケーション状態に対応するQoEを求めるようにしてもよい。アプリケーション情報観測部１０７では、動画（カメラで撮像された動画）アプリQoEでは、例えば、
・動画が途切れない、
・高画質等の場合、QoEは「良い」（5段階の4）と評価する。QoEでは、例えば、非常に良い、良い、普通、悪い、非常に悪い等の５段階評価が用いられる。なお、映像の場合、評価対象の映像のMOS（Mean Opinion Score）から基準映像のMOSを差し引いたDMOS（Differential Mean Opinion Score）を用いるようにしてもよい。評価対象の映像のMOSから基準映像のMOSを差し引き、これに５を加えるようにしてもよい（ACR(Absolute Category Rating)-HRR（Hidden Reference Removal））。

アプリケーション情報観測部１０７で取得されたアプリケーション品質等の時系列データを、入力情報生成部１０６、情報量計算部１０２を介してモデル作成部１０４に供給するようにしてもよい。この場合、モデル作成部１０４では、アプリケーション品質等の時系列データも考慮した状態遷移モデルを生成することができる。

あるいは、アプリケーション情報観測部１０７で取得されたアプリケーション情報（アプリケーション品質）を入力した入力情報生成部１０６では、アプリケーション品質に基づき、アプリケーション品質に対応する通信トラヒックの時系列データ（例えばスループット等）を演算処理し、情報量計算部１０２に供給するようにしてもよい。例えば、通信トラヒック観測部１０１からの通信トラヒックのスループットの時系列データを解析しなくても、アプリケーション情報観測部１０７で取得されたアプリケーション情報に基づき、例えば、アプリケーション状態は映像送信（動画送信）である、とわかる場合がある。このとき、動画（カメラ）アプリQoEにおいて、動画が途切れ途切れである場合（QoE：悪い）、その間のスループットが低下していると判断される。この場合、入力情報生成部１０６では、通信トラヒック観測部１０１からの通信トラヒックのスループットの時系列データのうち、ある時間区間（動画の途切れる時間区間）を間引いて、情報量計算部１０２に供給するようにしてもよい。

原因分析部１０８は、アプリケーション状態が「Ａ」と推定される場合、その原因を分析する。アプリケーション状態が「Ａ」（例えば、映像送信）であるが、動画が途切れ、スループットは動画配信の通常レベルよりも大幅に低いと推定された場合、該当するアプリケーション情報が、車両の「停車」等である場合、動画の途切れやスループットの低下は、停車中の車両の車載カメラから、リアルタイム動画送信ではなく、比較的長い間隔（例えば30秒）での間欠写真記録モードでの動画送信が行われていることが、原因として挙げられる。

本実施形態によれば、アプリケーション情報の観測結果に基づき、アプリケーション状態の推定を行うことで、アプリケーション状態の推定精度を向上する。また、選択された時系列データに基づき推定されたアプリケーション状態が、ある状態にあることの原因を、観測されたアプリケーション情報等に基づき、分析を可能としている。

次に、実施形態１－３に共通のモデル作成部１０４について説明する。モデル作成部１０４では、通信トラヒックの時系列データの状態遷移の確率モデルとして連続HMMと、離散HMMの階層モデルを生成する。

連続HMMは、シンボル出力確率を確率密度関数（probability density function (p.d.f.):例えばガウス分布（Gaussian p.d.f.））で表現したものであり、各状態の出力は、確率密度関数にしたがったd次元実数値ベクトル(dは所定の正整数)である。

図１３は、連続HMMを説明するための模式図である。図１３を参照すると、連続HMMでは、各状態の出力は、出力空間（d次元空間）の部分空間を構成する。連続混合型HMMの各状態の出力確率は以下で与えられる。

観測値列（シーケンス）Ｏは、系列長Tの時系列データからなるものとする。

・・・(17)

ただし、o_ｔは以下のd次元列ベクトルで与えられる(d≧１)。

・・・(18)
肩のTは転置演算子である。

例えば図１の３つの時系列データを用いる場合、dは3となる。

状態ｊ（隠れ状態）での出力確率分布b_j(o_t)は、以下で与えられる。

・・・(19)

Kは連続混合HMMの混合数である（K≧１）。N（）は多次元（d次元）正規分布である。

・・・(20)

式(20)において、μ_ijは平均、Σ_jkはdxdの分散共分散行列である。

連続混合HMMのモデルパラメータを

・・・(21)
とする。

式(21)において、Nは状態の数、Kは混合数である。

π_iは最初にどの状態にあるかを表す初期状態確率である。

a_iｊは時刻t-1に状態iに存在し時刻ｔに状態jに遷移する遷移確率である。

c_jkは状態ｊのｋ番目の確率分布の混合比である。

θ_jkは状態ｊのｋ番目の確率分布のパラメータ（平均ベクトルμ_jk, 分散共分散行列Σ_jk）である。すなわち、
θ_jk={μ_jk,Σ_jk}
・・・(22)

モデル作成部１０４では、例えばEM（Expectation-Maximization）アルゴリズムに基づき、モデルパラメータを求める。

出力（観測データ）をｘ、非観測データ（欠けているデータ）（HMMでは状態列）をｙ、モデルパラメータをΘとし、観測値列の対数尤度を、Ｅ（Expectation）ステップとＭ（Maximization）ステップの繰り返しにより最大化するため、以下の１～３のステップを含む。

＜ステップ１＞
初期パラメータΘを設定する(時刻ｔ＝0)。

＜ステップ２＞
現在推定されているパラメータの分布Θ^tのもとで、尤度関数の条件付き確率P（y｜x,Θ^t） に関する期待値を計算する（Ｅステップ）。

・・・(23)

＜ステップ３＞
Ｅステップで求まった尤度の期待値Q(Θ｜Θ^t)を最大化するようなパラメータ

・・・(24)
を求める（Ｍステップ）。

このＭステップで求められたパラメータΘ^*をΘ^{（t＋１）}として時刻を更新し（t＝t+1）、次のＥステップで使われる潜在変数の分布を決定するために用いる期待値が収束する（増大しなくなる）まで上記ステップ２と３を繰り返す。

図１４（Ａ）乃至図１４（Ｃ）は、モデル作成部１０４の動作例を説明する図である。連続HMM（Hidden Markov Model）では、図１４（Ａ）に模式的に示すように、通信トラヒック（例えばスループット）の時系列データ２０１（区間２０１－１、２０１－２、２０１－３）の振幅値（図１３（Ａ）の縦軸）の分布を、それぞれ正規分布２１１－１、２１１－２、２１１－３で表している（ただし、正規分布２１１－１、２１１－３は等しい）。時系列データの区間２０１－１、２０１－３の振幅値の分布に関して、その平均はμ₁、標準偏差はσ₁、時系列データの区間２０１－２の振幅値の分布に関して、その平均はμ₂、標準偏差はσ₂である。

図１４（Ｂ）は、１つの正規分布が１つの状態に対応する場合の連続HMMを模式的に図解している。図１４（Ａ）の通信トラヒックの時系列データが正規分布から生成されたと仮定し、生成元の正規分布を隠れ状態とみなしている。隠れ状態#1の出力確率分布b1(ot)（正規分布）３１２－１、隠れ状態#2の出力確率分布b2(ot)（正規分布）３１２－２となる。なお、図１４（Ｂ）では簡単のため、各隠れ状態の出力確率分布３１２－１、３１２－２を、１次元の正規分布で表している。

図１４（Ｃ）は、図１４（Ａ）の通信トラヒックに対して、連続HMMを用いて推定した状態シーケンスを示している。時系列データを正規分布で量子化し（時系列データがどの正規分布から得られる確率が最も高いか推定し、生成元の正規分布に対応する状態番号（状態名）で離散化)、アプリケーションの種別/状態ごとの変動パターンを離散値で表現する。

図１４（Ｃ）では、通信トラヒック（例えばスループット）の時系列データ２０１（区間２０１－１、２０１－２、２０１－３）に対して、連続HMMを用いて推定した状態の時間推移を、時系列データの時間軸に合わせて図示している。図１４（Ａ）において、例えば、通信トラヒックの時系列データの区間２０１－１、２０１－３の振幅の分布は、同一の正規分布２１１－１の範囲に収まる。このため、時系列データ２０１の区間２０１－１、２０１－３は同一の状態#１とみなすことができる。

一方、通信トラヒックの時系列データ２０１の変動（振幅変動）が大きく、例えば時系列データの区間２０１－１の分布が例えば正規分布２１１－１の範囲内に収まらず、正規分布２１１－２の範囲に跨って振動する場合、推定された状態が変動する。通信トラヒックの時系列データの変動振幅や変動回数が大きくなると、通信トラヒックの時系列データに対して、連続HMMを用いて推定した状態のシーケンス（例えばViterbiアルゴリズムで求めた通信トラヒック（スループット）に対応する最適状態の遷移シーケンス）も激しく変動する（ばたつく）ことになる。

状態#1は、アプリケーション状態（映像送信）（例えばカメラからの映像送信）、状態＃2は、アプリケーション状態（音声通話）（例えば端末間の音声通話）とする。なお、通信トラヒックに関わるアプリケーション状態は、アプリケーションの種別（例えば映像送信、音声通話等）に制限されるものでないことは勿論である。例えばカメラからの映像送信等同一アプリケーションにおける動作モード（例えば、間欠写真記録モード又はリアルタイム動画送信モード）の相違を別の状態として扱う構成としてもよい。

なお、モデル作成には、
・スループット[bps（bit per second）]、
・単位時間当たりのパケット到着間隔（平均値）[sec]、
・単位時間当たりの平均パケットサイズ（平均値）[bytes]、
・単位時間当たりのパケット数、
等の中から入力情報選択部１０３で選択された時系列データを利用するようにしてもよい。あるいは、オプションとして、アプリケーション情報観測部１０７からのアプリケーション情報（例えばIoTからの時系列入力情報（加速度の時系列情報や、無線品質の変化）も、情報量計算部１０２での計算結果に基づき、モデル作成に利用してもよい。

モデル作成部１０４では、HMMを用いて推定される状態のばたつきを抑制するために、図９、図１２の入力情報生成部１０６により、通信トラヒックの時系列データから、通信ノイズ量を算出して除去するようにしてもよい。通信トラヒックの時系列データから通信ノイズ量を除去した時系列データに対して、HMMを用いて、状態シーケンスを抽出するようにしてもよい。

モデル作成部１０４では、通信トラヒックの時系列データに対して連続HMMで推定した状態シーケンスに対して、離散HMMにより、状態遷移が類似するパターンを検出し、類似するパターンに対応する連続HMMの状態を、上位層のHMMの１つの隠れマルコフ状態とするようにしてもよい。例えば通信トラヒックが乱高下する状況を一まとめにして上位層のHMMの１つの隠れマルコフ状態にまとめることができる。

図１５（Ａ）、図１５（Ｂ）はHMM（Hidden Markov Model）のモデル構造を説明する図である。図１５（Ａ）の３０１は通常のHMMのモデル構造を模式的に例示し、図１５（Ｂ）の３０２は、HMMの階層モデルのモデル構造を模式的に例示している。なお、階層モデル３０２には、２つのグループ１、２（３０３、３０４）を含む例が示されているが、グループは２つに制限されるものでなく、３つ以上であってもよいことは勿論である。なお、図１５（Ｂ）の階層モデル３０２は、非特許文献１では、「多階層連鎖モデル」とも称され、各グループは「レジーム」とも称される。なお、グループ１、２では、単に簡易化のため、状態遷移モデルの状態数を２としている。グループは２つに制限されるものでなく、状態遷移モデルの状態数は２つに制限されるものでないことは勿論である。

各グループは内部に状態間の遷移行列Ａ１、Ａ２（それぞれの（i,j）要素は状態遷移確率：a_１;ij、a_2;ij （i,j=1,2））を保持し、さらに、グループ（レジーム）間の２×２の遷移行列Δ（(u,v)要素は、状態遷移確率：δ_uv (u,v=1,2)）を保有する。例えばグループのモデルパラメータ｛θ_１、θ_２、Δ｝に基づき、シーケンスの変化点を検出する。非特許文献１によれば、変化点によって分割された部分シーケンスは「セグメント」とも称せられる。セグメントをグループ化したものが、時系列の類似パターンである。なお、図１５（Ｂ）において、各グループ１、２のHMMは、連続HMM又は連続階層HMMであってもよいし、離散HMM、離散階層HMMであってもよい。

図１６（Ａ）乃至図１６（Ｃ）は、階層HMMモデルによる状態の推定を説明する図である。図１６（Ａ）は、通信トラヒックに対して連続HMMを用いて推定した状態シーケンスを例示したものである。なお、特に制限されないが、図１６（Ａ）の状態シーケンスにおいて、状態#1を０とし、状態#2を１としている。

連続HMMから得られた状態シーケンス（状態推移）から（図１６（Ａ））、例えば状態#1、#2間で、類似した変動が繰り返し生じている変動パターンの時間区間４０２－２を発見し、該変動パターンを１つのグループ（図１５（Ｂ）の３０３、３０４等に対応）にまとめ、離散HMMにより一つの状態でモデル化している。図１６（A）において、時間区間４０２－２の連続HMMの状態#1と状態#2間でばたつく変動パターン（図１６（Ａ）では、類似した変動が繰り返される時間区間４０２－２において、類似した変動パターンの１つを模式的に一つの三角波で表している）は、図１６（Ｂ）の離散HMMの状態s2で表されている。特に制限されないが、図１６（Ｂ）の離散HMMの例では、
隠れ状態s1の出力確率は、
・ 番号1（図１６（Ａ）の状態#1に対応）を出力する確率＝0.1、
・ 番号2（図１６（Ａ）の状態#2に対応）を出力する確率＝0.9、
隠れ状態s2の出力確率は、
・ 番号1（図１６（Ａ）の状態#1に対応）を出力する確率＝0.6、
・ 番号2（図１６（Ａ）の状態#2に対応）を出力する確率＝0.4、
である。

図１６（Ｃ）は、図１６（Ａ）の時系列データから連続HMMから得られた状態シーケンスのうち状態変動が類似するパターンの時間区間４０２－２について、連続HMMによる複数の状態を１つのグループでまとめ、離散HMMの状態でモデル化した一例を示している。すなわち、図１６（Ａ）では、状態は、離散HMMの状態s1、s2とされる。図１６（Ａ）の時系列データの４０２－２の時間区間は、離散HMMの１つの状態（隠れ状態）s2としてモデル化している。

前述したように、図１６（Ｂ）の離散HMMの状態s2（隠れ状態）において、番号１、番号２（図１６（Ａ）の状態#1、状態#2）を出力する割合（出力確率の値0.６と0.4の比）は３：２である。

図１６（Ａ）の４０２－２の時間区間における状態#1、状態#2の時間推移（変動パターン）は、これら連続HMMの複数の隠れ状態を１つにまとめ、離散HMMの１つの隠れ状態s₂が自己遷移確率δ₂₂で自己遷移し、その都度、隠れ状態s₂の出力確率に応じて、状態#1、状態#2間で遷移しているとみなすことができる。図１６（Ａ）の４０２－２の時間区間の前後の期間４０２－１、４０２－３における状態#2は、例えば、離散HMMによる隠れ状態s₁（自己遷移確率δ₁₁）でモデル化されている。

図１６（Ｃ）の状態のシーケンスは、離散HMMを用いて、図１６（Ａ）の状態４０２（連続HMMを用いて推定した状態）のシーケンスにおける４０２－２の時間区間の通信ノイズ（状態#1と状態#2間でのばたつき）を除去することが可能であることを例示している。

モデル作成部１０４で作成された階層モデル（連続HMMのモデル＋上位層の離散HMMのモデル）を記憶する記憶部１０５は、例えば半導体メモリ（RAM（Random Access Memory）、EEPROM(Electrically Erasable Programmable Read-Only Memory)）やHDD（Hard Disk Drive）等であってもよい。なお、階層モデルは、例えば、サンプルトラヒックを流し、モデル作成部１０４で通信トラヒックの時系列を分析しモデルパラメータを、よく知られたＥＭ（Expectation-Maximization algorithm）アルゴリズム等を用いて設定し、状態間のばたつき等の通信ノイズを除去できた階層数を、階層モデルの階層数として設定するようにしてもよい。

＜実施形態４＞
図１７は、本発明の例示的な実施形態４の構成を例示する図である。図１７は、図２の実施形態１の構成に、アプリケーション状態推定部１０９、アプリケーション状態判定部１１０と、アプリケーション特性（例えば通信トラヒックの変動特性）を記憶した記憶部１１１を備えている。

アプリケーション状態推定部１０９は、入力情報選択部１０３で選択された通信トラヒックの時系列データに対して、記憶部１０５に記憶された階層モデル（連続HMM＋離散HMM）を用いて、アプリケーション状態の推移を推定する。なお、アプリケーション状態推定部１０９が入力情報選択部１０３から受け取る通信トラヒックの時系列データは、モデル作成時に、入力情報選択部１０３が選択してモデル作成部１０４に供給した時系列データであってよい。すなわち、モデル作成部１０４がモデル生成のために用いた通信トラヒックの時系列データと同一（同種）の時系列データを用いて、アプリケーション状態を推定する場合、情報量計算部１０２による時系列データの情報量の計算は省略してもよい。あるいは、アプリケーション状態を推定する場合にも、情報量計算部１０２による時系列データの情報量を計算し、入力情報選択部１０３が情報量に基づき時系列データを選択して、アプリケーション状態推定部１０９に供給するようにしてもよい。

図１８は、アプリケーション状態判定部１１０の動作を説明する図である。アプリケーション状態判定部１１０は、アプリケーション状態推定部１０９で推定されたアプリケーション状態の遷移のシーケンス７０２と、記憶部１１１に事前に登録されているアプリケーション特性７０３（破線）との類似度を算出し、該当する時間区間の状態が、どのアプリケーション状態に対応するかを判定する。アプリケーション特性７０３は状態の推移が既知のアプリケーションにおける状態の遷移シーケンスである。アプリケーション状態判定部１１０は、通信トラヒックの時系列データ７０１に対して、記憶部１０５に記憶されたモデル（階層HMM等）に基づき、推測されたアプリケーション状態の遷移のシーケンス７０２と、アプリケーション特性７０３との相互相関関数を計算することで、類似度を計算するようにしてもよい。あるいは、相互相関関数のかわりに、動的タイムワーピング（Dynamic Time Warping：DTW）等を用いて、アプリケーション状態の類似度を計算し、推定精度を求めるようにしてもよい。これは、同一アプリケーション状態の推移に対して、通信トラヒックの時系列データの時間軸が異なる場合等における判別に有効である。

なお、アプリケーション状態判定部１１０において、アプリケーション状態推定部１０９を一体のユニットとしてもよい。

上記した実施形態２、３についても、アプリケーション状態推定部１０９、アプリケーション状態判定部１１０、アプリケーション特性を記憶した記憶部１１１を備えた構成としてもよい（重複を回避するため、説明は省略する）。

図１９（Ａ）は、実施形態４の作用効果の一例を説明する図である。図１９（Ａ）において、４０１は、通信トラヒック（スループット）の時系列データである。４２１は、モデル作成部１０４において、連続HMM（HMM層＃１）で推定した状態シーケンスである。すなわち、通信トラヒック（スループット）４０１の時系列データに関して、連続HMMモデル（HMM層#1）により推定した状態シーケンスである。通信トラヒック（スループット）４０１の時系列データの変動（変動頻度、変動の大きさ）に応じて、連続HMMで推定した状態シーケンス４２１も激しく変動する（ばたつく）ことになる。モデル作成部１０４は、連続HMMで推定した状態のシーケンス４２１に対して、状態間の遷移が類似するパターンを検出して、１つのグループにまとめ、上位層である離散HMMの１つの隠れ状態で表し、離散HMMによる状態のシーケンスを出力する。図１９（Ａ）の４２２（HMM層#2）は、連続HMMモデルによる状態シーケンス４２１に対して、類似パターンを、離散HMMに基づき１つの状態にまとめた結果の離散HMMによる状態のシーケンスを示している。すなわち、連続HMMモデルによる状態のシーケンス４２１において、例えば高頻度、高振幅で激しく遷移する状態の遷移パターンをまとめ、例えば離散HMMの１つの隠れ状態として表すことができる。図１９（Ｃ）は、図１９（Ｂ）の離散HMMによる状態（出力は０、１の２値）のシーケンスを示している。

なお、HMMの階層モデルの階層数は２に制限されるものでないことは勿論である。例えばサンプルトラヒックを用いて階層モデルをEMアルゴリズム等を用いて学習する場合に、スループットの小刻みな変動（通信ノイズ）を除去できた階層数を階層モデルの階層数として設定するようにしてもよい。

図１９（Ｂ）の４３３は、通信トラヒック（スループット）の時系列データ４０１に対する実際のアプリケーション状態のシーケンスを示す図である。図１９（Ａ）の状態４２３の値１が、図１９（Ｂ）の４３３のアプリケーション状態Ａ（映像配信）、図１９（Ａ）の状態４２３の値０が、図１９（Ｂ）の４２３のアプリケーション状態Ｂ（音声通話）に対応している。

実施形態４によれば、変動の大きな通信トラヒックの特徴量に対して、アプリケーション状態を正確に推定可能とするモデルを作成することができる。

実施形態４によれば、通信トラフヒックパターンに基づき、アプリケーション状態の推移を、通信ノイズ（変動パターン）等の影響を回避して推定可能とし、推定精度を向上可能としている。なお、情報量計算部１０２に入力される通信トラヒックの時系列データは、スループット、パケットサイズ、パケット送信間隔、パケット頻度（例えば平均値、分散、最大値、最小値等の少なくともいずれか）等であってもよい。

アプリケーション状態推定部１０９及びアプリケーション状態判定部１１０では、通信トラヒック（スループット）の時系列データを解析して、
・ 通信の周期、
・ 通信期間、
・ 非通信期間、
・ 最大スループット
などの特徴量を抽出し、抽出した特徴量を、記憶部１１１に記憶されたアプリケーションの特性（通信周期、通信期間、非通信期間、最大スループット等）と比較し、比較結果に基づき、アプリケーション状態の判定を行うようにしてもよい。

また、アプリケーション状態推定部１０９及びアプリケーション状態判定部１１０では、時間軸を共通とした複数の属性の時系列データからアプリケーション（種別、状態、動作モード等）を判別するようにしてもよい。すなわち、アプリケーション状態Ａ（映像配信）、アプリケーション状態Ｂ（音声通話）はアプリケーションの種別に対応しているが、アプリの種別に制限されるものでなく、アプリケーション状態は、同一のアプリケーションの通信モードあるいは動作モード（例えばコントロールプレーンデータとユーザプレーンデータの転送モード、すなわち、ノード間での制御動作、データ転送動作等）であってもよい。

アプリケーション状態推定部１０９及びアプリケーション状態判定部１１０では、トレーニングデータとして、アプリケーション状態の通信トラヒックの時系列データを解析して、通信周期、通信期間、非通信期間、最大スループットなどの特徴量（属性値）を抽出し、正解ラベル（アプリケーション状態）と、データ（例えば、通信トラヒックの特徴量の平均値、分散、最大値、最小値等の少なくともいずれか）に基づき、機械学習により、アプリケーション状態を判別するための分類器（分類モデル）を生成するようにしてもよい。評価時に、評価対象の通信トラヒックから抽出した特徴量に対して、学習済みの分類器（分類モデル）を用いてアプリケーション状態を識別するようにしてもよい。特に制限されないが、アプリケーション状態推定部１０９及びアプリケーション状態判定部１１０では、教師あり学習(supervised learning)の分類器として、決定木（木構造の分類器）を用いてもよい。あるいは、決定木を複数作成し多数決で識別するランダムフォレスを用いてもよい。この場合、決定木、ランダムフォレスト等の分類器に、通信トラヒックの時系列データを入力し、同一アプリケーション状態（アプリケーション種別）における動作モードを識別するようにしてもよい。なお、分類器は、決定木、ランダムフォレスト等に制限されるものでなく、サポートベクターマシン、ナイーブ（単純）ベイズ推定器（Naive Bayes classifier）や、ニューラルネットワーク等を用いてもよい。

＜実施形態５＞
図２０は、本発明の例示的な実施形態５を説明する図である。図２０は、図２、図９、図１２、図１７等のモデル作成部１０４が扱う階層モデルの変形例を説明する図である。通信トラヒックの時系列データのばたつき等のノイズ除去手段として、モデル作成部１０４では、HMMとして、状態滞在時間を考慮したHMMを用いている。アプリケーション状態と通信ノイズの特性の相違点として、例えばIoT（Internet of Things）デバイスのカメラからの映像などは、長時間同一の状態（トラヒック特性、スループット）を継続する。カメラで取得した画像を圧縮符号化するエンコーダの符号化レートが所定時間の間一定の場合、カメラからの通信トラヒックのスループットは一定となる。一方、通信ノイズは瞬間的に発生する。

実施形態５では、状態が一定時間変わらないことを想定している状態滞在時間分布を考慮したHMM（Explicit-Duration HMM:EDHMM）を利用し、例えば図２０に示すように、瞬間的に発生している通信ノイズを除去するようにしてもよい。この場合、隠れ状態ztは、状態stと残り持続時間rttで与えられる。

zt={st,rt}

入力値がある一定時間変わらない場合を想定したモデルパラメータ（連続混合HMMのモデルパラメータ）に加えて、状態iに固有の持続時間分布F_ｒのパラメータλ_iが加えられる。

状態シーケンス：s=(s₁,…, s_T)、残り持続時間のシーケンス：r=(r₁,…, r_T)とする。

EDHMMでは、
r_t＝０でなければ、現在の残り持続時間が１つカウントダウンされ、状態はｓ_ｔのまま変わらない。

r_t＝０であれば、s_t以外の状態ｓ_m（m≠t）に、遷移する。

本実施形態によれば、図２０において、階層モデルとして、連続HMMとEDHMM（Explicit-Duration）型離散HMMを用いている。例えば状態#1(アプリケーション：リアルタイム映像配信)において、当該状態に遷移後、残り持続時間が０となるまでの間に発生した通信トラヒック（スループット）の変動（通信ノイズ）の影響は受けず、当該状態に留まることになる（図２０の持続時間r（Duration-Time）参照）。このため、図２０の４２４に示す状態のシ－ケンスのように、通信ノイズの影響を受けることはない。図２０の４２４のHMM層#2（連続HMM＋離散HMM）は、図１９（A）の４２２のHMM層#2に対応させることができる。アプリケーション状態判定部１１０は、図２０の４２５のHMM層#2に示すような状態シーケンスを出力する。図２０の４２５は、連続HMMにより推定された状態シーケンスに対して、状態滞在時間を考慮した離散HMMを用いて推定した状態シーケンスを示している。

なお、図２０の例では、アプリケーション状態(リアルタイム映像配信)では、状態が一定時間変わらないことを想定しているため、状態のシーケンス：s=(s₁,…, s_T)において、アプリケーション状態(映像)（４２５の状態#1）の各状態の持続時間（Duration time）ｒ（モデルパラメータ）は一定としている。

状態１の持続時間rが、アプリケーション(例えば同一のリアルタイム映像配信)の動作モードによって、相違する場合等、通信トラヒック（スループット）の変動（通信ノイズ）の影響を受けることも考慮して、図１７のアプリケーション状態推定部１０９では、持続時間rをHMMモデルに基づき推定するようにしてもよいことは勿論である。なお、連続HMMをEDHMMで構成してもよいことは勿論である。

実施形態５によれば、持続時間のモデルパラメータの設定等をさらに必要とするが、前記実施形態１と同様の作用効果を奏する。

＜実施形態６＞
本発明の例示的な実施形態６について説明する。実施形態１－５等において、モデル作成部１０４は、リアルタイムでモデルを更新するようにしてもよい。モデル作成部１０４は、トラヒック源であるアプリケーション状態の特性の変化に追従するため、階層モデルを更新する。階層モデルの更新方法としては、例えばバッチ処理と、オンライン処理とに大別してもよい。このうち、バッチ処理は、図２１（Ａ）に模式的に示すように、適当なデータブロック長（入力データの長さ）単位で最新の通信トラヒックの時系列データ２１０１を分析し、該データブロックの分析結果に基づき階層モデルを更新する。階層HMMモデルの推定は前述の実施形態１と同様である。データブロック長は、固定であっても可変であってもよい。

モデル作成部１０４において、データブロック長を可変とする場合、例えば、
・ データブロック内の状態の数が１つの場合（同一状態が長期間続く場合）、データブロック長を伸ばし、
・ 状態の数が複数の場合、データブロック長を短くするようにしてもよい。

モデル作成部１０４で更新するモデルパラメータとして、前述した連続混合HMMのモデルパラメータ及び、上層HMMのモデルのグループ毎のモデルパラメータθ_１、θ_２と、グループ間の遷移確率Δ（状態遷移確率：δ_uv (u,v=1,2)）（図１５（Ｂ）参照）の少なくとも１つを含む。

オンライン処理では、データブロックの階層モデルの推定にあたり、図２１（Ｂ）に示すように、通信トラヒックの時系列データ２１０２において、過去に分析したデータブロック#1のモデルパラメータと、現在の（新たに得た）データブロック#2から階層モデルを推定するようにしてもよい。モデル作成部１０４では、現在のデータブロックに対して、過去の複数のデータブロックのモデルパラメータを用いて階層モデルを更新するようにしてもよい。インクリメンタルにモデル推定を行うことで計算量を削減し、オンライン処理でクリティカルに要求されるTiming Budgetを満たすことが可能となる。階層モデルの推定処理は、前記した実施形態と同様としてもよい。

実施形態６によれば、階層モデルをアプリケーション状態の特性の変化に応じて更新するように構成したことで、アプリケーション状態の特性の変化に追従可能とし、通信トラヒックからのアプリケーション状態の推定精度をさらに向上可能としている。

＜実施形態７＞
図２２は、本発明の例示的な実施形態７を説明する図である。図２２を参照すると、実施形態７では、図１７の構成に加え、アプリケーション状態予測部１１２をさらに備えている。アプリケーション状態予測部１１２は、アプリケーション状態判定部１１０で判定されたアプリケーション状態を用いて、将来のアプリケーション状態の遷移パターンを予測する。アプリケーション状態予測部１１２における予測方法として、図２３に模式的に例示するように、点予測、あるいは区間予測を用いてもよい。推定したアプリケーション状態シーケンスに対して、例えば自己相関を計算し、将来発生する状態シーケンスを予測するようにしてもよい。図２３において、破線は、将来発生するアプリケーション状態Ａの発生シーケンスである。

あるいは、アプリケーション状態予測部１１２は、確率的予測１（シミュレーション）を行ってもよい。HMMを用いて推定したパラメータを利用して、例えばマルコフ連鎖モンテカルロMCMC（Markov Chain Monte Carlo）法で、将来の予測を行うようにしてもよい。MCMCはサンプル点を直前に取り出したサンプルに依存して新しいサンプルを取得する。メトロポリス-ヘイスティングス（Metropolis-Hastings：MH）アルゴリズム、ギブス（Gibbs）サンプリング等がある。このうち、MHアルゴリズムは、提案分布q(y|x)と呼ばれる確率分布から次の候補となる値を発生し採択棄却αという値にしたがって採択するか棄却するか決める。

すなわち、
ステップ１：
初期値ｘ^（０）を決める。

ステップ２以降、t=0、1、・・・に対して、以下を行う。
yを提案分布ｑ(y|x^(t))から生成し、
uを一様分布から発生させ、
uがα(x^(t),y)以下のとき、
x^(t+1) = y、
他の場合、
x^(t+1) = x(t)
・・・(25)
とする。

ただし、α(x^(t),y) = min{1, π(y)q(x|y)/(π(x)q(y|x))}
・・・(26)

MHアルゴリズムで生成される（x⁽⁰⁾,x⁽¹⁾,…）はマルコフ連鎖をなしマルコフ連鎖は不変分布（invariant distribution）をもち、既約性（irreducibility）、非周期性を有する。大きなｍ以降のサンプル（x^(m+1),x^(m+2),…）は目標分布π（x）からサンプルされたものとみなすことができる。

一方、ギブスサンプルでは、
ステップ１：
確率変数ｘをｋ個のブロックx=(x1,…,xk)に分割し、
ステップ２以降、t=0,1,…に対して、以下を繰りかえす。
各x_i ^(t+1)を条件付き確率
ｐ（x_ｊ｜x₁ ^(t), x_j-1 ^(t), x_j+1 ^(t),…,x_k ^(t)）
・・・(27)
からサンプリングする。

確率的予測２（解析）として、フォアワードアルゴリズム等の動的計画法により、将来の各状態における状態確率を計算するようにしてもよい。前述したフォアワードアルゴリズムは、モデルパラメータと観測系列が与えられたとき、系列の最後における隠れ変数の状態の確率分布を求める。

実施形態７によれば、これまでに判定したアプリ状態から将来のアプリ状態を予測可能としている。

実施形態７の変形例として、アプリケーション状態予測部１１２では、さらに、アプリケーション状態の予測結果を利用して、通信トラヒック（例えばスループット等）を予測するようにしてもよい。すなわち、アプリケーション状態予測部と通信トラヒック予測部を一体化した構成としてもよい。あるいは、アプリケーション状態予測部と通信トラヒック予測部を別のユニットとしてもよい。将来の通信トラヒック（例えばスループット）の予測方法として、時系列的予測を行うようにしてもよい。

アプリケーション状態予測部１１２では、例えば、アプリケーション状態ごとに、通信トラヒックのAR（Auto Regressive:自己回帰）モデル等の時系列モデルを構築する。ARモデル（AR(ｐ)）は、出力ｙ_tが過去のp個の出力にのみ依存し、
y_ｔ＝－Σ<i=1,p>y_(t-i)+ε_t
・・・(28)
ε_tがN（０、Σ）である（ガウス性白色雑音）。

アプリケーション状態予測部１１２は、予測した将来のアプリケーション状態に該当する時系列モデルを選択する。

アプリケーション状態予測部１１２は、該選択した時系列モデルから、例えば式(28）にしたがって将来の通信トラヒック（例えばスループット）を予測する。

アプリケーション状態予測部１１２における将来の通信トラヒック（スループット）予測の別の方法として、HMMのモデルパラメータから予測してもよい。階層モデルを作成する際に、どのような分布から通信トラヒック（スループット）が生成されているかを出力確率で表現するようにしてもよい。アプリケーション状態予測部１１２は、予測したアプリケーション状態に該当する出力確率を選択することで、将来の通信トラヒック（例えばスループット）を予測するようにしてもよい。

＜実施形態８＞
図２４は、本発明の例示的な実施形態８を説明する図である。図２４を参照すると、実施形態８では、図２２の構成に加えて、推定されたアプリケーション状態に応じた通信制御等を行う制御部１１３をさらに備えている。

制御部１１３は、直接、通信制御等を行うようにしてもよいし、あるいは、図４（Ａ）、図４（Ｂ）のネットワークノード２０（L3スイッチ、基地局、ゲートウェイ等）に対して通信制御の指示を送信するようにしてもよい。図４（Ｃ）の場合、制御部１１３は、例えば端末３０―サーバ４０間の通信制御を直接行う。

図４（Ａ）、図４（Ｂ）のネットワークノード２０がルータ（エッジルータ等）の場合、又は、図４（Ｃ）において、トラヒック分析装置１００がルータ機能を含む場合、ネットワーク制御として、制御部１１３は、アプリケーション状態に応じて、トラヒックシェーピングやフィルタリングを制御するようにしてもよい。トラヒックシェーピングでは、パケット送信時の速度（送信間隔）等を調整し、通信トラヒックを一定のレートとする制御が行われる（例えば、帯域確保、帯域制限、優先制御等の制御を行うようにしてもよい）。また、フィルタリングでは、例えば、通信トラヒックを検査し、指定したフィルタリングルールに基づいて個々のネットワーク接続を許可または拒否する制御等を行うようにしてもよい。

図４（Ａ）、図４（Ｂ）のネットワークノード２０が基地局の場合、又は、図４（Ｃ）において、トラヒック分析装置１００が基地局機能を含む場合、又は、トラヒック分析装置１００がモバイルエッジコンピューティング装置に実装される場合、無線品質に応じた無線チャネルの割り当てにあたり、緊急度の高い移動局（端末）に対して、優先的に無線チャネルを割り当てる等の無線スケジューリングを行うようにしてもよい。

あるいは、トラヒック分析装置１００を、キャリアネットワークのトラヒック・ディテクション・ファンクション（Traffic Detection Function: TDF）として実装してもよい。この場合、トラヒック分析装置１００では、トラヒックとアプリケーション状態との関係を解析して該トラヒックに対応するアプリケーションを認識し、コアネットワーク（Evolved Packet Core: EPC）のPCRF（Policy and Charging Rules Function）が制御ルールを決定し、PCEF（Policy and Charging Enforcement Function）等により帯域制御、経路変更等の制御を行うようにしてもよい。

また、制御部１１３は、アプリケーション状態に応じた通信制御として、通信のタイミング（パケットデータの送信時刻、送信間隔等）、送信元、中継局（トランスコーダ）等における不図示のエンコーダ（符号化部）の圧縮符号化（圧縮符号化方式、符号化レート、フレームレート、解像度等）を制御するようにしてもよい。

実施形態８によれば、アプリケーション状態に応じて、ネットワーク制御、通信制御等を行うことができる。

＜実施形態９＞
図２５は、本発明の例示的な実施形態９を説明する図である。図２５を参照すると、実施形態９では、図２２の構成に加えて、QoE計算部１１４をさらに備えている。QoE計算部１１４は、推定したアプリ状態ごとに、どれくらいの通信品質を提供できているかを分析し、アプリケーション品質であるQoE（Quality of Experience）を計算（評価）する（例：Web QoE、動画QoE等）。QoEは、Webページ、動画の配信先のノード（端末、サーバ等）側で測定したQoEを収集し、アプリ状態に関連付けて記憶保持しておき、QoE計算部１１４は、通信トラヒック（スループット）やアプリケーション状態判定部１１０で判定されたアプリ状態に対応するQoEを求めるようにしてもよい。

QoE計算部１１４は、
WebアプリQoEでは、例えば、
・ クリックしてから表示完了が早い場合、
QoEは「良い」と判断するようにしてもよい。

QoE計算部１１４は、例えば、
遠隔機械制御（ドローン、工作機械、自動車等）のQoEでは、
・ 外部から制御コマンドを入力して、機器にコマンドを到達するまでが早い、または、
・ 遅延が一定の場合、
QoEは「良い」と評価するようにしてもよい。

QoE計算部１１４は、
ファイル転送アプリのQoEでは、例えば、
・ 転送開始から送信完了までが早い、
・ 転送に失敗しない等の場合、
QoEを高く評価するようにしてもよい。

実施形態９によれば、判定されたアプリ状態に対応するQoEを判定可能としている。

＜実施形態１０＞
図２６は、本発明の例示的な実施形態１０の構成を説明する図である。図２６を参照すると、実施形態１０は、図２５の構成に加えて、制御部１１５を備えている。制御部１１５は、QoE計算部１１４で算出（評価）したアプリ品質（QoE）に基づき、通信事業者等が提供するアプリケーションの制御を行う。なお、実施形態１０において、図２２等のアプリケーション状態予測部１１２を備え、QoE計算部１１４は、予測した将来のアプリケーション状態に対応するQoEを計算するようにしてもよい。

特に制限されないが、制御部１１５は、QoE計算部１１４で計算したQoEが悪い方の当該アプリケーションを優先し、ネットワーク制御・通信制御を実行するようにしてもよい。こうすることで、システム全体のQoEを向上し平滑化（平準化）を実現する。

あるいは、制御部１１５は、QoEが悪い方の閾値を超えたら（例えば５段階の「悪い」（２）を下回ると）、当該アプリケーションの優先度を下げるように、ネットワーク制御・通信制御を実行するようにしてもよい。こうすることで、所定のアプリ品質（QoE）を維持できないアプリケーションの優先度を下げることにより、優先度の高い方のアプリの品質を確保することができる。

制御部１１５は、QoE計算部１１４で計算したQoEが良すぎる場合、当該アプリケーションの優先度を下げるネットワーク制御・通信制御を実行するようにしてもよい。

なお、QoE計算部１１４は、現在までのQoEとアプリケーション状態に基づき、アプリケーション状態に対応するQoEの予測値も含んでもよい。この場合、制御部１１５は、将来のQoEの予測値に基づき、アプリケーションの優先度を制御することができる。

実施形態１０によれば、判定したQoE、又は将来のQoEの予測値に基づき、ネットワーク制御・通信制御を行うことで、アプリケーションに関する優先制御を実現できる。

＜実施形態１１＞
図２７は、本発明の例示的な実施形態１１として、トラヒック分析装置１００を、コンピュータ装置６０で実現した構成を例示する図である。図２７を参照すると、コンピュータ装置６０は、プロセッサ（CPU(Central Processing Unit)）６１、記憶装置（メモリ）６２、表示装置６３、通信インタフェース６４を備える。記憶装置６２は、例えばＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ等の半導体ストレージ、ＨＤＤ、ＣＤ、ＤＶＤ等を含む構成であってもよい。記憶装置６２は、プロセッサ６１で実行されるプログラム（命令群、データ等）を格納する。プロセッサ６１は、記憶装置６２に格納されたプログラムを実行することで、前記各実施形態のトラヒック分析装置１００の機能を実現する。通信インタフェース６４は、図４（Ａ）、図４（Ｂ）のネットワークノード２０との通信接続を制御するインタフェースである。通信インタフェース６４は、図４（Ｃ）において通信ネットワーク５０に流れるパケット（例えば端末３０とサーバ４０間のパケット）を転送するネットワークインタフェースとして機能してもよい。プロセッサ６１で実行されるプログラム（ソフトウェア）は、通信トラヒックに関する複数の時系列データの情報量を計算する情報量計算処理と、前記複数の時系列データの情報量に基づき、少なくとも１つの時系列データを選択する入力情報選択処理と含む。また、プロセッサ６１で実行されるプログラム（ソフトウェア）は前記実施形態１－１０として説明したトラヒック分析装置１００の機能を実現する処理ステップを含んでもよい。

なお、上記非特許文献１－３の各開示を、本書に引用をもって繰り込むものとする。本発明の全開示（請求の範囲を含む）の枠内において、さらにその基本的技術思想に基づいて、実施形態ないし実施例の変更・調整が可能である。また、本発明の請求の範囲の枠内において種々の開示要素（各請求項の各要素、各実施例の各要素、各図面の各要素等を含む）の多様な組み合わせ乃至選択が可能である。すなわち、本発明は、請求の範囲を含む全開示、技術的思想にしたがって当業者であればなし得るであろう各種変形、修正を含むことは勿論である。

上記した実施形態は例えば以下のように付記される（ただし、以下に制限されない）。

(付記１）
通信トラヒックに関する複数の時系列データのそれぞれの情報量を計算する情報量計算部と、
前記複数の時系列データの情報量に基づき、前記複数の時系列データの中から、分析対象とする少なくとも１つの時系列データを選択する入力情報選択部と、
を備えた、ことを特徴とするトラヒック分析装置。

(付記２）
前記通信トラヒックに関する複数の時系列データは、同一通信トラヒックに関する、時間軸を共通とした、複数の属性の時系列データである、ことを特徴とする付記１に記載のトラヒック分析装置。

(付記３）
前記情報量計算部は、前記情報量として、前記通信トラヒックの時系列データの特徴的なパターンの抽出の適合性を示す指標となる情報量を計算する、ことを特徴とする付記１又は２に記載のトラヒック分析装置。

(付記４）
前記情報量計算部は、前記情報量として、前記通信トラヒックの時系列データのサンプルエントロピーを計算する、ことを特徴とする付記１乃至３のいずれかに記載のトラヒック分析装置。

(付記５）
前記入力情報選択部は、前記サンプルエントロピーの大小に基づき、１つ又は複数の時系列データを選択する、ことを特徴とする付記４に記載のトラヒック分析装置。

(付記６）
前記通信トラヒックの時系列データに対して演算処理を施した時系列データを生成し、前記情報量計算部に供給する入力情報生成部をさらに備えた、ことを特徴とする付記１乃至５のいずれかに記載のトラヒック分析装置。

(付記７）
前記通信トラヒックに関わるアプリケーションの情報を取得し、前記入力情報生成部に供給するアプリケーション情報観測部をさらに備えた、ことを特徴とする付記６に記載のトラヒック分析装置。

(付記８）
前記入力情報選択部で選択された時系列データに基づき推定されたアプリケーション状態について、前記状態にあることの原因を分析する原因分析部をさらに備えた、ことを特徴とする付記７に記載のトラヒック分析装置。

(付記９）
前記入力情報選択部で選択された前記通信トラヒックの時系列データに基づき、前記時系列データのパターンとその遷移を表現するための確率的な状態遷移モデルを作成するモデル作成部をさらに備えた、ことを特徴とする付記１乃至８のいずれかに記載のトラヒック分析装置。

(付記１０）
前記モデル作成部は、前記入力情報選択部で選択された通信トラヒックの時系列データの状態の推移を、隠れマルコフモデルによる状態遷移モデルでモデル化し、
前記時系列データにおいて類似した変動が繰り返され前記隠れマルコフモデルの複数の隠れ状態でモデル化された時間区間について、前記複数の隠れ状態を一まとめにして、前記隠れマルコフモデルの１つ上位の層の隠れマルコフモデルの１つの隠れ状態でモデル化する、ことを特徴とする付記９に記載のトラヒック分析装置。

(付記１１）
前記モデル作成部は、前記入力情報選択部で選択された通信トラヒックの時系列データの状態の推移を連続隠れマルコフモデルでモデル化し、
前記連続隠れマルコフモデルの前記１つ上位の層の隠れマルコフモデルを離散隠れマルコフモデルとし、
前記離散隠れマルコフモデルの隠れ状態の出力確率及び遷移確率によって、一まとめにされた前記連続隠れマルコフモデルの複数の隠れ状態の出力の推移をモデル化した階層モデルを生成する、ことを特徴とする付記１０に記載のトラヒック分析装置。

(付記１２）
前記入力情報選択部で選択された時系列データに対して、前記モデルに基づき、前記時系列データに対応するアプリケーション状態を推定するアプリケーション状態推定部と、
推定された前記アプリケーション状態と、予め登録されているアプリケーション特性とに基づき、前記時系列データに対応するアプリケーション状態を判別するアプリケーション状態判別部と、
をさらに備えた、ことを特徴とする付記９乃至１１のいずれかに記載のトラヒック分析装置。

(付記１３）
前記アプリケーション状態判別部は、前記推定された前記アプリケーション状態のシーケンスと、予め登録されたアプリケーション特性のシーケンスの類似度に基づき、アプリケーション状態を判別する、ことを特徴とする付記１２に記載のトラヒック分析装置。

(付記１４）
前記アプリケーション状態に基づき、アプリケーション品質（ＱｏＥ）を判別するＱｏＥ計算部を備えた、ことを特徴とする付記１２又は１３に記載のトラヒック分析装置。

(付記１５）
前記アプリケーション状態、又は、前記アプリケーション状態に基づき計算したアプリケーション品質（ＱｏＥ）、又は、将来のアプリケーション状態の予測結果に基づき、ネットワーク制御と通信制御の少なくとも一方を行う制御部をさらに備えた、ことを特徴とする付記１２乃至１４のいずれかに記載のトラヒック分析装置。

(付記１６）
通信トラヒックに関する複数の時系列データのそれぞれの情報量を計算し、
前記複数の時系列データの情報量に基づき、少なくとも１つの時系列データを選択する、ことを特徴とするトラヒック分析方法。

(付記１７）
前記通信トラヒックに関する複数の時系列データは、同一通信トラヒックに関する時間軸を共通とした複数の属性の時系列データである、ことを特徴とする付記１６に記載のトラヒック分析方法。

(付記１８）
前記情報量として、前記通信トラヒックの時系列データの特徴的なパターンの抽出の適合性を示す指標となる情報量を計算する、ことを特徴とする付記１６又は１７に記載のトラヒック分析方法。

(付記１９）
前記情報量として、前記通信トラヒックの時系列データのサンプルエントロピーを計算する、ことを特徴とする付記１６乃至１８のいずれかに記載のトラヒック分析方法。

(付記２０）
前記サンプルエントロピーの大小に基づき、１つ又は複数の時系列データを選択する、ことを特徴とする付記１９に記載のトラヒック分析方法。

(付記２１）
前記通信トラヒックの時系列データに対して演算処理を施した時系列データを生成し、生成した前記時系列データの前記情報量の計算処理に供給する、ことを特徴とする付記１６乃至２０のいずれかに記載のトラヒック分析方法。

(付記２２）
前記通信トラヒックに関わるアプリケーションの情報を取得する、ことを特徴とする付記２１に記載のトラヒック分析方法。

(付記２３）
選択された前記時系列データに基づき推定されたアプリケーション状態について、前記状態にあることの原因を分析する、ことを特徴とする付記２２に記載のトラヒック分析方法。

(付記２４）
選択された前記通信トラヒックの時系列データに基づき、前記時系列データのパターンとその遷移を表現するための確率的な状態遷移モデルを作成する、ことを特徴とする付記１６乃至２３のいずれかに記載のトラヒック分析方法。

(付記２５）
選択された通信トラヒックの時系列データの状態の推移を、隠れマルコフモデルによる状態遷移モデルでモデル化し、
前記時系列データにおいて類似した変動が繰り返され前記隠れマルコフモデルの複数の隠れ状態でモデル化された時間区間について、前記複数の隠れ状態を一まとめにして、前記隠れマルコフモデルの１つ上位の層の隠れマルコフモデルの１つの隠れ状態でモデル化する、ことを特徴とする付記２４に記載のトラヒック分析方法。

(付記２６）
選択された通信トラヒックの時系列データの状態の推移を連続隠れマルコフモデルでモデル化し、
前記連続隠れマルコフモデルの前記１つ上位の層の隠れマルコフモデルを離散隠れマルコフモデルとし、
前記離散隠れマルコフモデルの隠れ状態の出力確率及び遷移確率によって、一まとめにされた前記連続隠れマルコフモデルの複数の隠れ状態の出力の推移をモデル化した階層モデルを生成する、ことを特徴とする付記２５に記載のトラヒック分析方法。

(付記２７）
選択された時系列データに対して、前記モデルに基づき、前記時系列データに対応するアプリケーション状態を推定し、
推定された前記アプリケーション状態と、予め登録されているアプリケーション特性とに基づき、前記時系列データに対応するアプリケーション状態を判別する、ことを特徴とする付記２４乃至２６のいずれかに記載のトラヒック分析方法。

(付記２８）
前記推定された前記アプリケーション状態のシーケンスと、予め登録されたアプリケーション特性のシーケンスの類似度に基づき、アプリケーション状態を判別する、ことを特徴とする付記２７に記載のトラヒック分析方法。

(付記２９）
前記アプリケーション状態に基づき、アプリケーション品質（Quality of Experience: QoE）を判別する、ことを特徴とする付記２７又は２８に記載のトラヒック分析方法。

(付記３０）
前記アプリケーション状態、又は、前記アプリケーション状態に基づき計算したアプリケーション品質（QoE）、又は、将来のアプリケーション状態の予測結果に基づき、ネットワーク制御と通信制御の少なくとも一方を行う、ことを特徴とする付記１６乃至２９のいずれかに記載のトラヒック分析方法。

(付記３１）
通信トラヒックに関する複数の時系列データのそれぞれの情報量を計算する情報量計算処理と、
前記複数の時系列データの情報量に基づき、少なくとも１つの時系列データを選択する入力情報選択処理と、
をコンピュータに実行させるプログラム。

(付記３２）
前記通信トラヒックに関する複数の時系列データは、同一通信トラヒックに関する、時間軸を共通とした、複数の属性の時系列データである、付記３１に記載のプログラム。

(付記３３）
前記情報量計算処理は、前記情報量として、前記通信トラヒックの時系列データの特徴的なパターンの抽出の適合性を示す指標となる情報量を計算する、付記３１又は３２に記載のプログラム。

(付記３４）
前記情報量計算処理は、前記情報量として、前記通信トラヒックの時系列データのサンプルエントロピーを計算する、付記３１乃至３３のいずれかに記載のプログラム。

(付記３５）
前記入力情報選択処理は、前記サンプルエントロピーの大小に基づき、１つ又は複数の時系列データを選択する、付記３４に記載のプログラム。

(付記３６）
前記通信トラヒックの時系列データに対して演算処理を施した時系列データを生成し、前記情報量計算部に供給する入力情報生成処理を前記コンピュータに実行させる、付記３１乃至３５のいずれかに記載のプログラム。

(付記３７）
前記通信トラヒックに関わるアプリケーションの情報を取得し、前記入力情報生成部に供給するアプリケーション情報観測処理を前記コンピュータに実行させる、付記３１乃至３６のいずれかに記載のプログラム。

(付記３８）
選択された前記時系列データに基づき推定されたアプリケーション状態について、前記状態にあることの原因を分析する原因分析処理を前記コンピュータに実行させる、付記３７に記載のプログラム。

(付記３９）
前記入力情報選択処理で選択された前記通信トラヒックの時系列データに基づき、前記時系列データのパターンとその遷移を表現するための確率的な状態遷移モデルを作成するモデル作成処理を前記コンピュータに実行させる、付記３１乃至３８のいずれかに記載のプログラム。

(付記４０）
前記モデル作成処理は、前記入力情報選択処理で選択された通信トラヒックの時系列データの状態の推移を、隠れマルコフモデルによる状態遷移モデルでモデル化し、
前記時系列データにおいて類似した変動が繰り返され前記隠れマルコフモデルの複数の隠れ状態でモデル化された時間区間について、前記複数の隠れ状態を一まとめにして、前記隠れマルコフモデルの１つ上位の層の隠れマルコフモデルの１つの隠れ状態でモデル化する、付記３９に記載のプログラム。

(付記４１）
前記モデル作成処理は、前記入力情報選択部で選択された通信トラヒックの時系列データの状態の推移を連続隠れマルコフモデルでモデル化し、
前記連続隠れマルコフモデルの前記１つ上位の層の隠れマルコフモデルを離散隠れマルコフモデルとし、
前記離散隠れマルコフモデルの隠れ状態の出力確率及び遷移確率によって、一まとめにされた前記連続隠れマルコフモデルの複数の隠れ状態の出力の推移をモデル化した階層モデルを生成する、付記４０に記載のプログラム。

(付記４２）
前記入力情報選択処理で選択された時系列データに対して、前記モデルに基づき、前記時系列データに対応するアプリケーション状態を推定するアプリケーション状態推定処理と、
推定された前記アプリケーション状態と、予め登録されているアプリケーション特性とに基づき、前記時系列データに対応するアプリケーション状態を判別するアプリケーション状態判別処理を前記コンピュータに実行させる、付記３９乃至４１のいずれかに記載のプログラム。

(付記４３）
前記アプリケーション状態判別処理は、前記推定された前記アプリケーション状態のシーケンスと、予め登録されたアプリケーション特性のシーケンスの類似度に基づき、アプリケーション状態を判別する、付記４２に記載のプログラム。

(付記４４）
前記アプリケーション状態に基づき、アプリケーション品質（ＱｏＥ）を判別するＱｏＥ計算処理を前記コンピュータに実行させる、付記４２又は４３に記載のプログラム。

(付記４５）
前記アプリケーション状態、又は、前記アプリケーション状態に基づき計算したアプリケーション品質（ＱｏＥ）、又は、将来のアプリケーション状態の予測結果に基づき、ネットワーク制御と通信制御の少なくとも一方を行う処理を前記コンピュータに実行させる、付記４２乃至４４のいずれかに記載のプログラム。

１０ パケットキャプチャ
２０ ネットワークノード
３０ 端末
４０ サーバ
５０ 通信ネットワーク
６０ コンピュータ装置
６１ プロセッサ
６２ 記憶装置
６３ 表示装置(モニタ)
６４ 通信インタフェース
１００ トラヒック分析装置
１０１ 通信トラヒック観測部
１０２ 情報量計算部
１０３ 入力情報選択部
１０４ モデル作成部
１０５ 記憶部（階層モデル記憶部）
１０６ 入力情報生成部
１０７ アプリケーション情報観測部
１０８ 原因分析部
１０９ アプリケーション状態推定部
１１０ アプリケーション状態判定部
１１１ 記憶部（アプリケーション特性記憶部）
１１２ アプリケーション状態予測部
１１３、１１５ 制御部
１１４ QoE計算部
２０１、４０１ 通信トラヒック（スループットの時系列データ)
２１１－１、２１１－２、２１１－３ 正規分布
３０１ HMM
３０２ 階層HMM
３０３ グループ１
３０４ グループ２
３１１、３１１－１、３１１－２ 隠れ状態
３１２、３１２－１、３１２－２ 混合GAUSS分布（混合正規分布）
３１３ d次元GAUSS分布（正規分布）
３１４ 出力確率
３１５ 観測値
４０２ 状態（HMM層#1の出力）
４０２－１～４０２－３ 時間区間
４０３ モデルパラメータ
４０４ 状態（正規化された状態のシーケンス、HMM層#2の出力）
４０４Ａ 状態#1の時間推移
４０４Ｂ 状態#2の時間推移
４２１、４２４ HMM#1状態
４２２、４２５ HMM#2状態
４２３、４３３ アプリケーション状態のシーケンス
４２６ アプリケーション状態A
７０１ 通信トラヒック（スループット）
７０２ 推測されたアプリケーション状態
７０３ アプリケーション特性
１００１、１００２、１１０１、１１０２、２１０１、２１０２ 時系列データ

Claims (6)

1. 通信トラヒックに関する複数の時系列データの情報量を計算する手段と、
   前記複数の時系列データの情報量に基づき、少なくとも１つの時系列データを選択する手段と、
   前記選択された時系列データに対して、前記時系列データのパターンとその遷移を表現するための確率的な状態遷移モデルを用いて、アプリケーション状態の推移を推定する手段と、
   前記状態遷移モデルに基づいて、前記推定されたアプリケーション状態の遷移のシーケンスと、予め登録されたアプリケーションにおける遷移のシーケンスとの類似度を計算する手段と、
   を備えるサーバ装置。
2. 通信トラヒックに関する複数の時系列データの情報量を計算し、
   前記複数の時系列データの情報量に基づき、少なくとも１つの時系列データを選択し、
   前記選択された時系列データに対して、前記時系列データのパターンとその遷移を表現するための確率的な状態遷移モデルを用いて、アプリケーション状態の推移を推定し、
   前記状態遷移モデルに基づいて、前記推定されたアプリケーション状態の遷移のシーケンスと、予め登録されたアプリケーションにおける遷移のシーケンスとの類似度を計算する、サーバ装置の方法。
3. 前記類似度に基づいて、前記通信トラヒックのアプリケーションの種別、状態、動作モードのいずれかを判別する手段をさらに備える、
   請求項１に記載のサーバ装置。
4. 前記確率的な状態遷移モデルは、隠れマルコフモデルを含む、
   請求項１または３に記載のサーバ装置。
5. 前記類似度に基づいて、前記通信トラヒックのアプリケーションの種別、状態、動作モードのいずれかを判別する、
   請求項２に記載のサーバ装置の方法。
6. 前記確率的な状態遷移モデルは、隠れマルコフモデルを含む、
   請求項２または５に記載のサーバ装置の方法。

Images