JP7136300B2 - トラヒック分析装置、システム、方法及びプログラム - 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）アドレス/ポート、プロトコル）)と、
- トラヒックパターン(例えば、スループット、パケットサイズ、パケット送信間隔等)等である。

トラヒックフローは、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．

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

例えば、ネットワーク上に流れるトラヒックのスループットから、当該トラヒックに対応するアプリの状態を推定する場合、推定精度が低いことを、本願発明者等は確認している。

ここで、トラヒックのスループットは単位時間あたりのデータ転送量（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."(その機器によって送信フレームが損失しない最大レート)と定義されているが、基本的にこの定義から逸脱しない。

アプリケーションの状態を推定する場合、様々な複合的な要因から予測不能に時系列データが変動するため（例えば急なスループットの落ち込み等）、その時系列データの変動を誤認識してしまい、推定精度が低いことが確認されている。

図１は、この点を説明する図である。図１は、本発明者らによるシミュレーション結果を示している。スループットは、様々な要因により変動する。例えば、
- ネットワーク上で発生する無線品質の変動、
- トラヒック量の変動、
- 符号化方式、圧縮レート等（アプリケーション側からトラヒック制御）。

図１において、２０１で示す波形は、ネットワークのインタフェース（Network Interface Card: NIC）上を流れるパケットをキャプチャし、例えば同一送信元（又は宛先）IPアドレスのパケットを抽出して測定した通信トラヒック（例えばスループット等）の測定結果（時系列データ）をプロットした図である。図１において、２０１の横軸は時間（例えば２０１の始端から終端まではほぼ1200秒）、縦軸はスループット（例えば、Mega bits per second: Mbps）である。２０２は、通信トラヒック（例えばスループット）の時系列データ２０１から、当該通信トラヒックにて提供されるアプリケーションサービス（通信サービス）であるアプリ状態（例えば映像配信、通話等）を推定した結果の一例を模式的に例示する図である。２０２で示す波形において、横軸は、２０１と共通の時間である。また特に制限されないが、２０２の縦軸の状態０は、アプリケーション状態Ａ（映像）、状態１はアプリケーション状態Ｂ（通話）とする（アプリケーション状態は「アプリ状態」とも略記される）。なお、２０３は、参考として、２０１のスループットの時系列データに対して矢印で示したアプリ状態のシーケンス（本来の状態のシーケンス）、すなわち、アプリ状態Ａ（映像配信）、アプリ状態Ｂ（音声通話）の時系列パターンを表している。

図１の２０２において、２０２ａ、２０２ｂ、２０２ｃ等では、通信トラヒック（例えばスループット）の変動（通信ノイズ）により、状態を誤って推定している。なお、図１における状態の誤推定の原因等については、以下で詳細な分析が行われる。

本発明の目的は、通信トラヒックからアプリケーション状態を推定するにあたり、誤推定を抑制し推定精度の向上を図るシステム、装置、方法を提供することにある。

本発明の一つの側面によれば、通信トラヒックの時系列データに対して隠れマルコフモデルに基づき、状態のシーケンスを推定し、前記状態のシーケンスから状態遷移が類似するパターンをひとまとめにして１つの状態とみなして状態のシーケンスを抽出する第１手段（第１のユニット）と、前記第１の手段（第１のユニット）で抽出された前記状態のシーケンスと、予め定められたアプリケーション特性とに基づき、前記時系列データに対応するアプリケーションを判別する第２の手段（第２のユニット）と、トラヒック分析装置が提供される。

本発明の一つの側面によれば、通信トラヒックの時系列データに対して隠れマルコフモデルに基づき、状態のシーケンスを推定し、前記状態のシーケンスから状態遷移が類似するパターンをひとまとめにして１つの状態とみなして状態のシーケンスを抽出し、
前記抽出された前記状態のシーケンスと、予め定められたアプリケーション特性とに基づき、前記時系列データに対応するアプリケーションを判別するトラヒック分析方法が提供される。

本発明の一つの側面によれば、通信トラヒックの時系列データに対して隠れマルコフモデルに基づき、状態のシーケンスを推定し、前記状態のシーケンスに対して状態遷移が類似するパターンをひとまとめにして１つの状態とみなし、状態のシーケンスを抽出する処理と、
前記抽出された前記状態のシーケンスと、予め定められたアプリケーション特性とに基づき、前記時系列データに対応するアプリケーションを判別する処理と、をコンピュータに実行させるプログラムが提供される。

本発明によれば、上記プログラムを記録した非一時的なコンピュータ可読可能な媒体（a non-transitory computer readable medium）（例えばＲＡＭ（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を模式的に説明する図である。 （A）は通信トラヒックの時系列データと分布、（B）は連続HMMの状態（出力確率分布）と状態遷移確率、（C）は推定された状態シーケンスをそれぞれ模式的に説明する図である。 本発明の一形態の階層モデルを説明する図である。 本発明の一形態を説明する図である。（A）は通信トラヒックの時系列、（B）は離散HMM、（C）は推定された状態シーケンスをそれぞれ模式的に説明する図である。 本発明の一形態の階層モデルの処理を説明する図である。 本発明の一形態における処理手順を説明する流れ図である。 （A）乃至（C）は本発明の一形態のシステム構成の一例を説明する図である。 本発明の例示的な実施形態１のトラヒック分析装置の構成例を説明する図である。 通信ノイズによる誤判定の発生を説明する図である。 （A）乃至（C）は、本発明の例示的な実施形態１の通信ノイズ算出部を説明する図である。 本発明の例示的な実施形態１の時系列データ正規化部を説明する図である。 時系列データ正規化部において図１２の処理で適用される階層モデルを模式的に説明する図である。 本発明の例示的な実施形態１のアプリ状態判定部の処理を説明する図である。 本発明の例示的な実施形態１のアプリ状態判定部の処理を説明する図である。 本発明の例示的な実施形態１のアプリ状態判定部の変形例１を説明する図である。 （A）、（B）は本発明の例示的な実施形態１のアプリ状態判定部の変形例２を説明する図である。 本発明の例示的な実施形態１の作用効果をプロトタイプ（比較例）と対比して説明する図である。 本発明の例示的な実施形態２のトラヒック分析装置の構成例を説明する図である。 本発明の例示的な実施形態２を説明する図である。 本発明の例示的な実施形態３を説明する図である。 本発明の例示的な実施形態４のトラヒック分析装置の構成例を説明する図である。 （A）、（B）は本発明の例示的な実施形態４を説明する図である。 本発明の例示的な実施形態５のトラヒック分析装置の構成例を説明する図である。 本発明の例示的な実施形態５を説明する図である。 本発明の例示的な実施形態６を説明する図である。 本発明の例示的な実施形態７を説明する図である。 本発明の例示的な実施形態８を説明する図である。 本発明の例示的な実施形態９を説明する図である。 本発明の例示的な実施形態１０を説明する図である。 本発明の基本的な一形態を説明する図である。

本発明の実施形態について説明する。図３１を参照すると、本発明の一形態のトラヒック分析装置１は、通信トラヒックの時系列データに対して、階層隠れマルコフモデル（Hierarchical Hidden Markov Model）４に基づき、状態のシーケンスを推定し、前記状態のシーケンスから類似するパターンをひとまとめにして(１つのグループにグループ化して)１つの状態とみなした上で、状態のシーケンスを抽出する第１手段（第１のユニット）２と、前記第１の手段（第１のユニット）２で抽出された前記状態のシーケンスと、予め記憶部に記憶（登録）されたアプリケーション特性（アプリ特性）５と、を照合し、前記時系列データに対応するアプリケーション状態を判別する第２の手段（第２のユニット）３と、を備える。かかる構成を備えた本発明の一形態のトラヒック分析装置１によれば、通信トラヒックの時系列データからアプリケーション状態（アプリケーションの種別やアプリケーションの動作モード（状態）等）を推定するにあたり、誤推定（図１の２０２ａ、２０２ｂ、２０２ｃ）の発生を抑制し、推定精度の向上を図ることができる。

ここで、発明の前提技術でもあるHMM（Hidden Markov Model）について概説しておく。連続HMM（「連続分布型HMM」とも称せられる）は、シンボル出力確率を確率密度関数（probability density function (p.d.f.):例えばガウス分布（Gaussian p.d.f.））で表現したものであり、各状態の出力は、確率密度関数にしたがったd次元実数値ベクトル(dは所定の正整数)である。

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

観測値列（シーケンス）Ｏ（図１では通信トラヒック）は、系列長Tの時系列データからなるものとする。

・・・(1)

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

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

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

・・・(3)

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

・・・(4)

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

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

・・・(5)
とする。

式(5)において、Nは状態の数、Kは混合数である。
π_iは最初にどの状態にあるかを表す初期状態確率である。
a_iｊは時刻t-1に状態iに存在し時刻ｔに状態jに遷移する遷移確率である。
c_jkは状態ｊのｋ番目の確率分布の混合比である。
θ_jkは状態ｊのｋ番目の確率分布のパラメータ（平均ベクトルμ_jk, 分散共分散行列Σ_jk）である。すなわち、
θ_jk={μ_jk,Σ_jk}
・・・(6)

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

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

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

・・・(7)

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

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

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

観測値列Ｏに対する未知の状態シーケンスS=｛s₁, s₂,… s_T｝ただし、状態s_t∈｛1,…,N｝、及び、観測値系列Ｏの未知の確率密度分布系列（分布系列）M=｛m₁, m₂,… m_T｝、ただし、m_t∈｛1,…,K｝とすると、状態系列Sと分布系列Mは、EMアルゴリズムの非観測データ（欠けているデータ）ｙに対応する。完全データの対数尤度は、観測データO、非観測データY、パラメータΘに関して、

・・・(9)

期待値は、

・・・(10)

モデルパラメータΘ^(t-1)と観測値列Oが与えられたとき、時刻ｔ-1では状態iに存在し、時刻ｔで状態ｊに遷移する事後遷移確率分布をξ_ij(t)としてフォアワードアルゴリズム、バックワードアルゴリズムを用いて書き直すと、

・・・(11)

時刻ｔに状態jに存在する事後確率分布をζ_j(t)として

・・・(12)

時刻ｔに状態jのｋ番目の分布に存在する分布の事後確率分布をγ_jk(t)として

・・・(13)

上記Q関数を各パラメータに関して最大化することにより、初期状態確率π_i、状態遷移確率aij、混合比cjk,θ_jk={μ_jk,Σ_jk}等は、例えば以下のように導出される（導出は良く知られている）。

・・・(14)

・・・(15)

・・・(16)

・・・(17)

・・・(18)

＜フォアワードアルゴリズム＞
なお、モデルΘと観測値列Ｏが与えられたとき、時刻ｔまでに部分観測値列o₁,o₂,…, o_tを出力し、時刻ｔに状態ｉに存在する確率分布は、

・・・(19)
として定義される。

このα_i(t)は、良く知られているように、例えば以下のフォアワードアルゴリズムによって計算される。

・・・(20)

・・・(21)

時刻ｔでo₁,o₂,…,o_tを観測し、現在状態iにいる確率分布は

・・・(22)
で与えられる。

＜バックワードアルゴリズム＞
バックワード変数β（t）はモデルΘが与えられた時、時刻t+1から時刻Tまでの観測列ｏ_t+1，ｏ_t+2,…, ｏ_Tが生成される確率分布

・・・(23)
として定義される。

・・・(24)

式(24)において、Fは最終状態の集合、N_Fは最終状態の状態数である。

図１の例では、サンプルトラヒックをネットワーク上に流し、パケットモニタ装置（パケットキャプチャ）で通信トラヒック（例えばスループット：１秒当たりの転送データ量）を測定し、通信トラヒック（スループット）の時系列データを観測値列として、上記したEMアルゴリズムを用いて、連続混合HMMのパラメータ

・・・(25)

を推定する（HMMモデルパラメータの学習）。

Viterbiアルゴリズムは、HMMにおいて与えられた出力列を出力した尤度が最も高い状態遷移系列を計算する。観測値列O＝o₁,o₂,…,o_Tを生成したモデルMにおいて最適な状態系列S=s¹,s²,…,s^Tを求めるために、最適状態確率δ_i(t)を定義する。

δ_i(t)=max <s₁,s₂,…,s_t-1> p(s₁,s₂,…,s_t =i, o₁,o₂,…,o_T |Θ)
・・・(26)

時刻tにおける最適状態の確率は、以下のように再帰的に計算することができる。
δ_j(t) = max<i> [δ_i(t-1)a_ij]b_j(o_t)
・・・(27)

<Viterbiアルゴリズム>
ステップ1.
各状態i=1,…,N に対して、変数の初期化を行う。
δ₁(i)= π_i×b_i(o₁),
ψ₁(i)=0 (1≦i≦N)
・・・(28)

ステップ2.
各時刻t=1,…,T-1, 各状態j=1,…,N について、再帰計算を実行する。
δ_t+1(j) = max(1≦i≦N)[δ_t(i)a_ij]b_ij(o_t+1)
ψt+1(j) = argmax(1≦i≦N) [δ_t(i) a_ij ]
・・・(29)

ステップ3.
再帰計算の終了(時刻t=Tにおける最大の確率値Pと状態遷移系列qの計算)。
^P= max(1≦i≦N) [δ_T(i)]
^q^T = argmax(1≦i≦N) [ψ_T(i)]
・・・(30)

ステップ4.
バックトラックによる最適状態遷移系列の復元。
各時刻t=T-1, …,1に対して、
^q^t = ψ_t+1(^q^t+1) ・・・(31)
を実行する。

図１に示す例では、上記した連続混合型HMMを用いて、与えられた観測系列（２０１：通信トラヒック（スループット））の時系列データを出力した尤度が最も高い状態遷移系列(２０２：状態シーケンス)を計算している。

なお、連続混合型HMMに階層型HMM（Hierarchical HMM：HHMM）を用いてもよい。階層型HMMに関して、例えば特許文献１、非特許文献２等が参照される。

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

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

図３（C）は、図３(A)の通信トラヒックに対して、連続HMMを用いて推定した状態シーケンスを示している。時系列データを正規分布で量子化し（時系列データがどの正規分布から得られる確率が最も高いか推定し、生成元の正規分布に対応する状態番号（状態名）で離散化）、アプリケーションの種別/状態（アプリ状態A:映像配信、アプリ状態B:音声通話等）ごとの変動パターンを離散値で表現する。図３（C）では、通信トラヒック（例えばスループット）の時系列データ２０１（区間２０１－１、２０１－２、２０１－３）に対して、連続HMMを用いて推定した状態の時間推移を、時系列データの時間軸に合わせて図示している。図３（A）において、例えば、通信トラヒックの時系列データの区間２０１－１、２０１－３の振幅の分布は同一の正規分布２１１－１の範囲に収まる。このため、時系列データ２０１の区間２０１－１、２０１－３は同一の状態#１とみなすことができる。

一方、通信トラヒックの時系列データ２０１の変動（振幅変動）が大きく、例えば時系列データの区間２０１－１の分布が正規分布２１１－１の範囲内に収まらず、正規分布２１１－２の範囲に跨って振動する場合、推定された状態が変動する。通信トラヒックの時系列データの変動振幅や変動回数が大きくなると、通信トラヒックの時系列データに対して、連続HMMを用いて推定した状態のシーケンス（例えばViterbiアルゴリズムで求めた通信トラヒック（スループット）に対応する最適状態の遷移シーケンス）も激しく変化する（ばたつく）ことになる。図１に示す例では、状態２０２の値０がアプリ状態（映像）（例えばカメラからの映像送信）、状態２０２の値１がアプリ状態（通話）（例えば端末間の音声通話）であるが、２０２ａ、２０２ｂ、２０２ｃの時間区間の状態は、本来、状態２０３に示すように、アプリ状態A（値＝０）であるべきところ、通信ノイズの影響等により、アプリ状態B（値１）の時間区間が含まれる。また、２０２a、２０２ｂ、２０２ｃではスパイク状のノイズも含まれる。

なお、通信トラヒックの時系列データとして、スループット[bps（bit per second）]の時系列データを例示しているが、スループットに制限されるものでなく、例えば、
・単位時間当たりのパケット到着間隔（平均値）[sec]、
・単位時間当たりの平均パケットサイズ（平均値）[bytes]、
・単位時間当たりのパケット数等であってもよい。あるいは、オプションとして、例えばIoT向けの時系列入力情報（加速度の時系列情報や、無線品質の変化）も入力情報として利用してもよい。

本発明によれば、HMMを用いて推定される状態のばたつきを抑制するために、まず、通信トラヒックの時系列データから通信ノイズ量を算出して除去するようにしてもよい。通信トラヒックの時系列データから通信ノイズ量を除去した時系列データに対して、HMMを用いて、状態シーケンスを抽出するようにしてもよい。

本発明によれば、通信トラヒックの時系列データに対して連続HMMで推定した状態シーケンスに対して、離散HMMにより、類似した状態遷移が繰り返される変動パターンを検出し、該状態遷移が類似する変動パターンを離散HMMの１つの状態とする。このため、例えば通信トラヒックが乱高下する状況を、上層層（離散HMM）の１つの状態としてまとめることができる。

図４（A）、図４（B）は、本発明で用いるHMMのモデル構造を説明する図である。なお、図４（A)の３０１は通常のHMMのモデル構造を模式的に例示し、図４（B）の３０２は階層モデルのモデル構造を模式的に例示している。階層モデル３０２には、２つのグループ１、２（３０３、３０４）を含む例が示されているが、グループは２つに制限されるものでなく、３つ以上であってもよいことは勿論である。

なお、図４（B）の階層モデル３０２は、非特許文献１では、「多階層連鎖モデル」とも称され、各グループは「レジーム」とも称される。なお、グループ１、２では、単に簡易化のため、状態遷移モデルの状態数を２としている。グループは２つに制限されるものでなく、状態遷移モデルの状態数は２つに制限されるものでないことは勿論である。

各グループは内部に状態間の遷移行列Ａ１、Ａ２（それぞれの（i,j）要素は状態遷移確率：a１;ij、a2;ij （i,j=1,2））を保持し、さらに、グループ（レジーム）間の２×２の遷移行列Δ（(u,v)要素は、状態遷移確率：δuv (u,v=1,2)）を保有する。

例えばグループのモデルパラメータ｛θ_１、θ_２、Δ｝に基づき、シーケンスの変化点を検出する。非特許文献１によれば、変化点によって分割された部分シーケンスは「セグメント」とも称せられる。セグメントをグループ化したものが、類似時系列パターンである。なお、図４において、各グループ１、２のHMMは、連続HMM又は連続階層HMMであってもよいし、離散HMM、離散階層HMMであってもよい。

また、非特許文献１に開示されるように、コスト関数に基づき、最適なセグメントの数、グループ（レジーム）の数を算出するようにしてもよい。

図５（A）乃至図５（C）は、本発明を説明する図である。図５（A）は、通信トラヒックに対して連続HMMを用いて推定した状態シーケンスを例示したものであり、図３（C）の状態シーケンスに対応する。なお、特に制限されないが、図５（A）の状態シーケンスにおいて、状態#1を０、状態#2を１としている。

図５（B）は、図５（A）の状態シーケンス（連続HMMに基づき推定された状態シーケンス）に離散HMMを適用し、類似するパターンを発見し、該類似するパターンを１つのグループ（図４（B）の３０３、３０４等に対応）にまとめ、離散HMMの一つの隠れ状態でモデル化している。特に制限されないが、図５(B)の例では、
隠れ状態s1の出力確率は、
- 番号1（図５(A)の状態#1に対応）を出力する確率＝0.1、
- 番号2（図５(A)の状態#2に対応）を出力する確率＝0.9、
隠れ状態s2の出力確率は、
- 番号1（図５(A)の状態#1に対応）を出力する確率＝0.6、
- 番号2（図５(A)の状態#2に対応）を出力する確率＝0.4、
である。δ_ij（i,j=1,2）は状態s_iから状態s_jへの遷移確率である。

図５（C）は、図５（A）の離散値（状態の番号）の時系列データから、状態の変動が類似するパターンを、離散HMMにより１つのグループ（状態）にまとめた一例を示している。すなわち、図５（C）の例では、図５（A）の４０２－１の時間区間の状態のシーケンスの類似する変動パターン（状態#1と状態#2間でのばたつき（状態#1->状態#2->状態#1と同じような状態遷移の５つの変動パターン）を模式的に５つの三角波で表している）をひとまとめにグループ化して、離散HMMの状態s2としてモデル化している。前述したように、状態s2において、番号１、番号２（状態#1、状態#2）を出力する割合（出力確率の値の比）は３：２である。図５（A）の４０２－１の時間区間の状態#1、#2間の遷移パターンは、１つにまとめた状態s2が、例えば自己遷移し、その都度、状態s2の出力確率に応じて番号1、2を出力することに対応し、状態#1、状態#2間での遷移とみなすことができる。

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

図６は、上記した本発明の一形態を説明する図である。グループ数ｒ＝２、区間（セグメント）数ｍ＝７とした場合を示す図である。ここで、セグメントは、例えば非特許文献１に従い、時系列データのパターンの変化点で区画される区間とする。ｆ_１＝２はセグメントの第１のメンバ（第１セグメント）がグループ（レジーム）２であることを表している。通信トラヒック（例えばスループット）４０１は、図１の通信トラヒック２０１と同一の時系列データである。４０２は、通信トラヒック（スループット）の時系列データ４０１に対して連続ＨＭＭを用いて推定した状態のシーケンスである。図６のモデルパラメータ４０３（グループ１、２のモデルパラメータ）は、図４（B）の３０２に対応し、
θ_１＝｛π_１、Ａ_１、Ｂ_１｝、
θ_２＝｛π_２、Ａ_２、Ｂ_２｝
・・・(32)
で与えられる。ここで、π_i（i=1,2）は初期確率、Ａ_i（i=1,2）は遷移確率、Ｂ_i（i=1,2）は出力確率である。４０４は推定された状態の時間推移を示している。状態４０４の値０はアプリ状態Ａ（映像）、値１はアプリ状態Ｂ（通話）であり、図１の状態２０３と同一の時間推移であり、正しくアプリ状態が推定されていることが分かる。

なお、図６では、通信トラヒックの時系列データとして、スループットの時系列データが示されているが、同一の通信トラヒックに関して、同一時間軸上で、スループット、パケットサイズ、パケット頻度、パケット送信間隔等、属性の異なる複数の時系列データ（例えば４種の時系列データ）に対して、階層モデルを用いて、各セグメントでのアプリケーション状態を推定するようにしてもよい。

図７は、本発明の一形態のトラヒック分析装置の動作例を説明する流れ図である。

解析対象の通信トラヒックの情報（例えばスループット等の特徴量）を取得する（ステップＳ１１）。前述したように、通信トラヒックの情報は、単位時間当たりのパケット到着間隔（平均値）[sec]、単位時間当たりの平均パケットサイズ（平均値）[bytes]、単位時間当たりのパケット数等であってもよい。

通信トラヒック（例えばスループット等の特徴量）の時系列データから通信ノイズを算出し除去する（ステップＳ１２）。

階層ＨＭＭに基づき、通信トラヒック（スループット）の時系列データから状態シーケンスを抽出し、類似パターンを１つの状態にまとめ、状態シーケンスの正規化処理を行う（ステップＳ１３）。

正規化した状態シーケンスを、予め記憶されているアプリケーション特性と照合し、通信トラヒック（スループット）の時系列データに対応するアプリ状態を判定する（ステップＳ１４）。

以上、本発明の一形態の典型的な動作原理の一例を説明した。次に、本発明の例示的な一実施形態について説明する。

図８（Ａ）乃至図８（Ｃ）は、本発明の実施形態に係るシステム構成例を説明する図である。図８（Ａ）において、パケットキャプチャ（パケットモニタ）１０は、ネットワークを流れるプロトコルデータ単位（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等）を提供するものであってもよい。

＜実施形態１＞
図９は、図８（A）乃至図８（C）を参照して説明したトラヒック分析装置１００の構成の一例を示す図である。トラヒック分析装置１００は、通信トラヒックの時系列データの変動波形（変動頻度、変動の大きさ）から推定された状態の変動を確率的に算出し、不要な変動パターンを除去するように、時系列データの抽象度を上げ、状態シーケンスとアプリケーション特性とに基づき、アプリケーションを判定するように構成される。なお、図９の構成は、トラヒック分析装置１００の機能構成（処理モジュール）を例示したものであり、物理構成を規定したものではない。物理構成は、通信機能を備え、メモリに接続する１つ又は複数のプロセッサ装置で命令群を実行することで各機能（処理）を実現するようにしてもよい。

＜通信トラヒック取得部＞
図９において、通信トラヒック取得部１０１は、図８（Ａ）に示すように、パケットキャプチャ１０から解析対象の通信トラヒックをリアルタイムで取得する。前述したように、通信トラヒック取得部１０１は、図８（Ｂ）、図８（Ｃ）に示すように、パケットキャプチャを含む構成としてもよい。

＜通信ノイズ算出部＞
通信ノイズ算出部１０２は、通信トラヒックの時系列データの変動（例えば変動頻度、変動の大きさ）から通信ノイズ量を確率的に算出する。通信トラヒックは、無線環境の変動やアプリケーションの送信パターンの変化等による影響（本明細書では、「通信ノイズ」と呼ぶ）を受け、トラヒックパターンが変動する。

図１０は、通信トラヒックの時系列データ４０１として、リアルタイム映像配信時の通信トラヒック（スループット）の時系列データを示している。４０２は、通信トラヒック（スループット）の時系列データ４０１に対して連続ＨＭＭを用いて推定した状態のシーケンスである。図１０において、状態のシーケンスにおいて時間区間４１１では、通信ノイズによる通信トラヒック（スループット）の変動の影響によって、アプリ状態を誤って推定している。通信ノイズは短時間に急激な変化をする場合がある。一方で、ある一定時間、トラヒックパターンが変わらないアプリケーションもある。例えば動画閲覧は数１０秒～数分、通信トラヒック（スループット）等のトラヒックパターンは変わらない。本発明によれば、変動時間粒度の違いを利用して、通信ノイズによる誤判定を抑制するようにしてもよい。

特に制限されないが、固定網（固定回線）、無線網（例えばWi-Fi（Wi-Fi Allianceの登録商標）等）、携帯電話網（例えばE-UTRAN（Evolved Universal Terrestrial Radio Access Network）、EPC（Evolved Packet Core）等のコアネットワーク）等のネットワーク環境のタイプと、対応する変動波形（変動頻度、変動の大きさ）の関係は、予め記憶装置等に設定されているものとする。例えば、事前に、ネットワーク環境（固定網、無線網、携帯電話網）において、特定の転送速度のトラヒック（例えば映像等のアプリケーション）を定常的に流し、通信トラヒック（スループット）の時系列波形データを取得し、その変動頻度や変動の大きさを決定するようにしてもよい。

図１１（Ａ）は、ネットワーク環境（特に制限されないが、例えば固定網、無線網、携帯電話網等）における通信トラヒック（例えばスループット）の変動頻度や変動の大きさを記憶する記憶部１０２１を説明する図である。記憶部１０２１は、通信ノイズ算出部１０２内に備えてもよいし、外部に備えてもよい。なお、記憶部１０２１の変動頻度は単位時間当たりの変動発生数である。

例えば、通信トラヒック（スループット）の変動（通信ノイズ）の瞬時振幅値（変動の大きさ）は確率的に正規分布に従うものとすると、変動の大きさの特性を表すパラメータは、例えば、変動振幅の最大値（A₁）、平均（μ_１）、標準偏差（σ_１）としてもよい。

通信ノイズ算出部１０２は、分析対象のトラヒックのネットワーク環境に対して、対応するネットワーク環境のノイズ特性パラメータを予め取得するようにしてもよい。例えば、分析対象のトラヒックのネットワーク環境は、図８（Ａ）、図８（Ｂ）のネットワークノード２０から取得してもよい。例えばネットワークノード２０が基地局であれば無線網、コアネットワークノードであれば、携帯電話網、また光ルータ等の場合、固定回線（固定網）となる。

通信ノイズ算出部１０２は、ノイズ特性パラメータに基づき、ノイズ波形（時系列データ）を生成する構成としてもよい。図１１（C）の４０５ａ、４０５ｂ、４０５ｃは生成されたノイズ波形（通信ノイズ）を模式的に示している。

瞬時振幅値（変動の大きさ）が正規分布等、確率密度関数ｆ（x）（xは振幅（確率変数））に従う場合、図１１（B）に示すように、０と振幅最大値（例えば図１１（A）のA1）の範囲の一様乱数を生成し（１０２２）、確率密度関数ｆ（x）の累積分布関数F（x）の逆関数F^-1（x）１０２３に、生成した一様乱数を入力する。逆関数F^-1（x）１０２３の出力として、正規分布等の確率密度関数ｆ（x）に従う確率変数x（乱数）が生成される（この手法は「逆関数法」とも称せられる）。逆関数法で生成した乱数を、時間軸上に順番に配列してノイズ波形（時系列データ）を生成してもよい（この場合、ノイズ波形は前後で激しく変動する）。あるいは、逆関数法で生成した生成された乱数を、例えば大きさの順にソートし、ソート結果を展開し、時間軸上での整列（１０２４）を行い、１０２５として示すように、時間軸上で、ある幅を持ったノイズ波形を生成するようにしてもよい。

ノイズ波形１０２５の時間軸上の配置は、例えば元の通信トラヒック（スループット）４０１（図１１（C））における通信ノイズの発生位置に対応させて配置するようにしてもよい。図１１（C）では、通信トラヒック（スループット）４０１における通信ノイズの発生位置に対応させてノイズを配置した例を、４０５ａ、４０５ｂ、４０５ｃとして模式的に示している。４０５ａ、４０５ｂ、４０５ｃの各々は、逆関数法で生成した乱数を、時間軸上、順番に配列してノイズ波形であってもよい。あるいは、図１１（B）のノイズ波形１０２５を複数合成したものであってもよい。変動頻度情報（単位時間当たりの変動発生数）に基づき、１／（変動頻度）の時間分、離間させてノイズ波形を合成するようにしてもよい。

通信ノイズ算出部１０２では、確率的に算出した通信ノイズを通信トラヒック（スループット）から時間軸上で差し引くことで通信ノイズを除去するようにしてもよい。図１１（C）において、４０６は、元の通信トラヒック（スループット）４０１の時系列データから、通信ノイズ４０５ａ、４０５ｂ、４０５ｃを時間軸上で差し引いた時系列データの波形である。

通信ノイズ算出部１０２では、生成した通信ノイズ（図１１（B）のノイズ波形１０２５）の時系列データのｍ個の列ベクトルをｇ₁ ^->、…ｇ_m ^->とする。通信トラヒック（スループット）から４０１の時系列データを要素ｎのベクトルy^->＝（y₁,y₂,…y_n）^T（Tは転置演算子）とし、生成したｍ個のノイズ波形ベクトルｇ₁ ^->、…ｇ_m ^->に対して、例えば、誤差
ε＝｜y^->－(β₁・ｇ₁ ^->+β₂・ｇ₂ ^->+…+β_m・ｇ_m ^->+ｃ^->)|
・・・(33)
の２乗を最小化する係数ベクトルβ^->=（β₁, β₂,…, β_m）とオフセットベクトルｃ^->を求めるようにしてもよい（最小２乗規範）。その際、β₁, β₂,…, β_m>=0という条件を付した制約付きの最小２乗法を用いてもよい。なお、生成した複数（２つ）のノイズ波形の時系列データのベクトルｇ_i ^->、ｇ_j ^->(隣接する場合、ｊ＝i+1)が時間軸上で互いに重なるときは、例えば、
大きい方の値max(ｇ_i ^->、ｇ_j ^->)、又は、
小さい方の値
min(ｇ_i ^->、ｇ_j ^->)
を該当する該時間の値としてもよい。３つ以上のノイズ波形（時系列データ）が時間軸上で互いに重なるときも、上記と同様に扱うようにしてもよい。

誤差εの２乗を最小化する係数(β₁, β₂,…, β_m）及びオフセットc^->を用いて、
y^->－(β₁・ｇ₁ ^->+β₂・ｇ₂ ^->+…+β_m・ｇ_m ^->+ｃ^->）
・・・(34)
を、図１１（C）の通信トラヒック（スループット）４０６の時系列データ(通信ノイズ除去済みの時系列データ)としてもよい。

＜時系列データ正規化部＞
次に、図９の時系列データ正規化部１０３の処理について説明する。図１２は、時系列データ正規化部１０３の処理の一例を模式的に説明するための図である。図１２の４０６は、通信ノイズ算出部１０２において、通信トラヒック（スループット）の時系列データ４０１から通信ノイズ（波形）を減算した時系列データである（図１１（C）の４０６に対応）。

時系列データ正規化部１０３は、例えば連続HMMに基づき、状態のシーケンス４０７を推定する。４０７では、ノイズを除去した時系列データ４０６から推定されたアプリ状態Ａ（図２の２０１参照）に対応する状態を状態＃１、アプリ状態Ｂ（図２の２０１参照）に対応する状態を状態＃２としている。

時系列データ正規化部１０３では、状態のシーケンス４０７に対して、階層隠れマルコフモデルの上位層(離散HMM)を適用し、状態のシーケンス４０７のうち、状態遷移のパターンが類似する時間区間の連続HMMの状態（隠れ状態）をグループ化して、上位層(離散HMM)の１つの状態（隠れ状態）にまとめる。

図１２の例では、時系列データ正規化部１０３は、連続HMMにより推定された状態４０７のシーケンスに対して、離散HMMを適用し、状態遷移のパターン（状態#1->状態#2->状態#1）の状態#1、状態#2を１つにまとめてグループ#1とする。時系列データ正規化部１０３では、状態４０７のシーケンスにおいて状態#2をグループ#2とする。そして、グループ#1を、上位層である離散HMMの状態s1、グループ#2を離散HMMの状態s2として、状態シーケンス４０４を抽出する。グループ#1に対応する隠れ状態s1は、それぞれ所定の出力確率で例えば番号1（４０７の状態#1に対応）、番号2（４０７の状態#2に対応）を出力するものとする（例えば自己遷移する度に、隠れ状態s1の出力確率に応じて番号1、2を出力する）。グループ#2に対応する隠れ状態s2は、例えば番号1（４０７の状態#1に対応）の出力確率は０とする。

抽出された状態４０４のシーケンスは、通信トラヒック（スループット）の時系列データ４０１を隠れ状態に基づき、本来の状態のシーケンスに復元（reconstruct）したものである。なお、状態４０４のシーケンスにおいて、状態s1、状態s2の値をそれぞれ１、０としているが、他の値であってもよい。

図１３は、図９の時系列データ正規化部１０３における状態遷移の類似パターンを検出する処理を説明する図であり、３０２は、図４（B）の３０２に対応している。図１３を参照すると、グループ#1は、状態#1と状態#2を含み、モデルθ_１は、初期状態確率、状態遷移確率、出力確率（混合ガウス分布のモデルパラメータ）を含む。グループ#2は、状態#2を含み、モデルθ_２は、初期状態確率、状態遷移確率、出力確率を含む。上層HMMのモデルΘは、モデルθ_１、θ_２と、グループ間の遷移確率Δを含む。

なお、図１２において、４０４Aは、状態シーケンス４０４について状態s1の時間遷移(推移)を抽出したものである。状態s1のある時間区間を値１、状態s1以外のとき、０とする。４０４Bは、状態シーケンス４０４について状態s2の時間遷移（推移）を抽出したものである。状態s2の時間区間を値１、状態s2以外のとき０とする。図１２において、状態のシーケンス４０４Aは、通信トラヒック（スループット）４０１の元となったアプリケーション状態(図１のアプリ状態A)のシーケンスを復元したものということもできる。

このように、時系列データ正規化部１０３では、通信ノイズ抽出部１０２により通信ノイズが除去された通信トラヒック（スループット）の時系列データに対して階層HMMを適用し、最適な状態シーケンスを推定する。時系列データ正規化部１０３の処理は、通信トラヒック（スループット）の時系列データの変動（ノイズ）が除去されるように、時系列データの抽象度を上げることに対応する。階層HMMの階層数が深くなるにつれて、状態の変化は、時間軸上で小刻みな変化から大まかな変化になる。

時系列データ正規化部１０３では、通信トラヒック（スループット）の変動（通信ノイズ：例えば小刻みな変動）が除去できた段階でのHMMモデルの階層数を階層モデルの階層数として設定するようにしてもよい。

図１２において、通信ノイズが除去された通信トラヒック（スループット）４０６を正規化された時系列データと称してもよい。この場合、復元された状態４０４のシーケンスにおける状態s1の時間区間と、４０６の通信トラヒック（スループット）の時系列データとの比較から、４０６a、４０６ｂ、４０６ｃの各時間区間は、状態#1に対応する通信トラヒック（スループット）が、通信ノイズ等の影響で低下し、連続HMMにより状態#2と推定される時間区間であることがわかる。

時系列データ正規化部１０３は、例えば図１２の状態４０４A（４０４B）のシーケンスを、正規化された時系列データとして出力するようにしてもよい。

あるいは、時系列データ正規化部１０３は、正規化された時系列データとして、図１２の通信トラヒック（スループット）４０６の時系列データを併せて出力するようにしてもよい。

＜アプリ状態判定部＞
次に、図９のアプリ状態判定部１０５について説明する。アプリ状態判定部１０５は、正規化した状態シーケンスと、記憶部１０６に事前に登録されているアプリケーション特性（例えば通信トラヒックの変動特性）との類似度を算出し、該当する時間区間の状態がどのアプリ状態に対応するかを判定する。

図１４、図１５は、図９のアプリ状態判定部１０５を説明する図である。図１４を参照すると、アプリ状態判定部１０５は、時系列データ正規化部１０３で正規化された時系列データ（アプリ状態Ａ）４０８と、予め記憶部１０６に記憶されているアプリケーション１の特性（図１４の破線４０９）との類似度を算出する。

２つの波形（時系列データ）の間の類似度として相互相関関数を用いてもよい。時系列データ正規化部１０３で正規化された時系列データ（アプリ状態A）４０８は、通信トラヒック（スループット）４０１から通信ノイズを除去した時系列データを、時系列データ正規化部１０３で抽出された状態#１（アプリ状態A）のシーケンス（図１２の４０４A）の値１の時間区間でゲーティングした波形データとしてもよい。

図１４の例では、正規化された時系列データ４０８とアプリ１の通信トラヒック（スループット）特性４０９との相関値（相互相関値）が０．９であり、正規化された時系列データ４０８とアプリ２の通信トラヒック（スループット）特性４１０との相互相関値が０．１である。このため、アプリ状態判定部１０５では、正規化された時系列データ４０８は、アプリ１（アプリ状態Ａ）の通信トラヒック（スループット）特性に対応するものと判断する。

なお、アプリ状態判定部１０５は、時系列データ正規化部１０３から出力される状態のシーケンス（例えば図１２の４０４A）のパターンと、アプリ１、２の状態シーケンスのパターンとを照合して類似度（例えば相互相関値）を求め、どのアプリ状態に対応するかを判定するようにしてもよい。

図１５を参照すると、アプリ状態判定部１０５は、時系列データ正規化部１０３で正規化された時系列データ（アプリ状態Ｂ）４１１に対して、予め記憶部１０６に記憶されているアプリ１の特性（図１５の破線４０９）との相互相関値（０．０１）と、アプリ２の特性（図１５の４１０）との相互相関値（０．８）を計算する。なお、図１５において、正規化された時系列データ４１１とアプリ２の特性４１０とは、線を同一として重ねせて図示すると、判別が困難となることから、正規化された時系列データ４１１とアプリ２の特性４１０は時間軸は共通としながら別々に示されている。時系列データ正規化部１０３で正規化された時系列データ（アプリ状態Ｂ）４１１は、通信トラヒック（スループット）４０１から通信ノイズを除去した時系列データを、時系列データ正規化部１０３で抽出された状態#2（アプリ状態B）のシーケンス（図１２の４０４Ｂ）の値１の時間区間でゲーティングした波形データとしてもよい。

アプリ状態判定部１０５では、正規化された時系列データ４１１は、アプリ２の通信トラヒック（スループット）波形であると判定する。図１５において、正規化された時系列データ４１１は通話状態のスループットの時系列データであり、縦軸（bps）を、正規化された時系列データ（アプリ状態A）４０８（図１４）と同一スケールとしているため、微小振幅波形として表されているが、４１１の最大値を例えばフルスケール等に設定することで、前述したノイズ除去の手法で、スループットから通信ノイズ等を除去することは可能である。

なお、アプリ状態判定部１０５は、通信トラヒック取得部１０１で取得した通信トラヒック（スループット）の全時間区間に対応する状態シーケンス４０４（正規化された時系列データ）を、アプリ１、２の特性波形と比較して相関値（相互相関値）を算出するかわりに、各ブロック（時間区間）（図９では、例えば２００秒毎）に分割し、ブロックごとに、時系列データ正規化部１０３で正規化された時系列データと、対応するブロック（時間区間）のアプリ１、２との特性の類似度（相互相関値）を算出するようにしてもよい。また、例えば図１４、図１５において、例えば所定長さの各時間区間について、各ブロックの類似度の合計（総和）を、正規化された時系列データと、アプリ１、２の特性（通信トラヒック特性）との類似度として算出するようにしてもよい。

アプリ状態判定部１０５では、正規化された時系列データと、予め記憶部１０６に記憶されているアプリケーションの通信トラヒック特性（時系列データ）との類似度を、コサイン距離やユークリッド距離等を用いて計算してもよい。

また、アプリ状態判定部１０５では、時系列データ正規化部１０３で抽出された状態シーケンスと、アプリケーションの状態シーケンスのパターンとの類似度に基づき、アプリ状態を判定するようにしてもよい。この場合、ある時間区間の状態が当該アプリケーション状態のとき、１、当該アプリケーション状態でないとき、０とした場合（例えば図１２の４０４Ａ）、状態シーケンスは２値時系列データ（状態ベクトル）で表される。このため、状態ベクトルに対して、予め記憶部１０６に記憶されているアプリケーションの状態ベクトルとの類似度を、ハミング距離等を用いて算出してもよい。この場合、ハミング距離が所定値以下である場合、類似とみなす。

＜アプリ状態判定部：変形例１＞
あるいは、アプリ状態判定部１０５は、通信トラヒック（スループット）の時系列データを解析して、通信の周期、通信期間、非通信期間、最大スループットなどの特徴量を抽出し、抽出した特徴量を、記憶部１０６に記憶されたアプリケーションの特性（通信周期、通信期間、非通信期間、最大スループット等）と比較し、比較結果に基づき、アプリ状態の判定を行うようにしてもよい。あるいは、アプリ状態判定部１０５は、通信トラヒック（スループット）の時系列データを解析し、パケットサイズ（例えば平均値）、パケット送信間隔（到着間隔）（例えば平均値）、パケット頻度（例えば平均値）等をアプリケーションの各々と比較するようにしてもよい。

例えば、図１６（Ｂ）に示すように、正規化された時系列データ４０８の通信特徴量が、通信周期：300s(second)、通信期間：270s、非通信期間：30s、最大bps：5mega bpsの場合（通信周期、通信期間、非通信期間は図１６（A）に示す）、 記憶部１０６に記憶されたアプリ１の特性（通信特徴量）とアプリ２の特性（通信特徴量）（図１６（B）の４１２参照）を照合し、カテゴライスしてアプリ状態１と判定する。記憶部１０６に記憶されたアプリケーションの特性（通信の周期、通信期間、非通信期間、最大スループット等）と比較することでアプリ状態の判定を行うようにしてもよい。あるいは、アプリ状態判定部１０５は、通信トラヒック（スループット）の時系列データを解析し、パケットサイズ（例えば平均値）、パケット送信間隔（到着間隔）（例えば平均値）、パケット頻度（例えば平均値）等をアプリケーションの各々と比較するようにしてもよい。

＜アプリ状態判定部：変形例２＞
あるいは、アプリ状態判定部１０５は、トレーニングデータとして、アプリケーション状態の通信トラヒックの時系列データを解析して、通信周期、通信期間、非通信期間、最大スループットなどの特徴量（属性値）を抽出し、正解ラベル（アプリケーション状態）と、データ（例えば、通信トラヒックの特徴量の平均値、分散、最大値、最小値等の少なくともいずれか）に基づき、機械学習により、アプリケーション状態を判別するための分類器（分類モデル）を生成するようにしてもよい。アプリ状態判定部１０５は、評価時に、評価対象の通信トラヒックから抽出した特徴量に対して、学習済みの分類器（分類モデル）を用いてアプリケーション状態を識別するようにしてもよい。特に制限されないが、アプリ状態判定部１０５は、教師あり学習(supervised learning)の分類器として、図１７（Ａ）に示すように、決定木５００（木構造の分類器）を用いてもよい。

あるいは、アプリ状態判定部１０５は、図１７（Ｂ）に示すように、決定木を複数作成し多数決で識別するランダムフォレスト５１０を用いてもよい。アプリ状態判定部１０５は、学習時には、例えば、
- サンプルデータからランダムに複数組のサブサンプルを生成し、
- サブサンプルをトレーニングデータとして、複数組の決定木を作成し、
- トレーニングデータの属性（説明変数）（例えば図１７（Ｂ）の通信周期、通信間隔、パケットサイズ等）をランダムに所定個選択し、トレーニングデータの分類結果と属性閾値を用いて、決定木５１１～５１ｎの各ノードでの分岐条件を決定し、モデルを生成する。

アプリ状態判定部１０５は、評価時には、通信トラヒックから抽出した特徴量をランダムフォレスト５１０に入力し、各決定木の出力（リーフノードのクラス）の多数決をとるようにしてもよい。なお、図１７（Ｂ）の決定木５１１～５１ｎの各ノード内の説明変数（属性）は模式的な例示である。各説明変数は、通信トラヒックの特徴量の平均値、分散、最大値、最小値等の少なくともいずれかであってもよい。

図１７（Ｂ）のランダムフォレスト５１０の決定木５１１～５１ｎにおけるリーフノードのクラスA、B等は、アプリケーションの状態（アプリ状態A、アプリ状態B、例えばアプリケーションの種別）であってもよい。

あるいは、図１７（Ｂ）のランダムフォレスト５１０の決定木５１１～５１ｎにおけるリーフノードのクラスA、B等は、アプリケーション状態の動作モード等（同一アプリケーションにおける動作モード、通信モード等）であってもよい。アプリ状態判定部１０５は、決定木、ランダムフォレスト５１０あるいは決定木５００の分類器に、通信トラヒック（スループット）の時系列データを入力し、同一アプリケーション状態（アプリケーション種別）における動作モードを識別するようにしてもよい。例えば、解析対象の通信トラヒックのスループットが同一アプリケーション（例えばドローンアプリケーション）の複数の動作モードのうちのいずれの動作モードであるかを識別するようにしてもよい。

なお、アプリ状態判定部１０５において、分類器は、決定木、ランダムフォレスト等に制限されるものでなく、サポートベクターマシン、ベイズ推定器（Naive Bayes classifier）や、ニューラルネットワーク等を用いてもよい。

図１８は、実施形態１の作用効果を説明する図である。図１８において、２０１、２０２は、図１の通信トラヒック（スループット）と推定した状態シーケンス（プロトタイプ）である。４１３は、通信トラヒック（スループット）に対して、実施形態１により推定した状態シーケンスである。

図１８からも明らかなように、実施形態１によれば、プロトタイプと比較して、アプリ状態の推定を向上している。このように、実施形態１によれば、変動の大きな通信トラヒックの特徴量（スループット）に対して、アプリ状態を正確に推定することができる。実施形態１によれば通信トラヒックパケットの5タプルのうち送信元、宛先アドレス（ポート）とスループット等の通信トラフヒックパタンに基づき、アプリケーションの状態の推移を、通信トラヒック（スループット等）パターンの変動（通信ノイズ）等の影響を回避して推定可能とし、推定精度を向上可能としている。なお、前述したように、実施形態１において、評価対象（解析対象）の通信トラヒックの時系列データとして、スループットに制限されるものでなく、パケットサイズ、パケット送信間隔、パケット頻度（例えば平均値、分散、最大値、最小値等の少なくともいずれか）等であってもよく、時間軸を共通とした複数の属性の時系列データからアプリケーション（種別、状態、動作モード等）を判別するようにしてもよい。すなわち、アプリ状態A（映像配信）、アプリ状態B（音声通話）はアプリケーションの種別に対応しているが、アプリ状態は、同一のアプリケーションの通信モードあるいは動作モード（例えばコントロールプレーンデータとユーザプレーンデータの転送モード、すなわち、ノード間での制御動作、データ転送動作等）であってもよい。

＜実施形態２＞
図１９は、例示的な実施形態２を説明する図である。前記実施形態１では、通信トラヒック（スループット）の時系列データから通信ノイズを除去した時系列データを取得するにあたり、通信トラヒック（スループット）の時系列データからノイズ波形を差し引いて求めている。実施形態２では、通信トラヒック（スループット）の時系列データから通信ノイズを除去する通信ノイズの除去手段として、時系列データ正規化部１０３を用いている。この場合、図９の実施形態１の通信ノイズ算出部１０２を削除することも可能である（たたし、図９と同様、通信ノイズ算出部１０２を備えた構成としてもよい）。

時系列データ正規化部１０３は、連続HMMで推定した状態シーケンスに対して、状態の遷移のパターンが類似するパターンを検出するために、連続HMMの上位階層として機能する離散HMMを用いて、類似する状態遷移パターンを１つのグループ（上位層の１つの状態）にグループ化する。

図２０は、図１９の時系列データ正規化部１０３の処理を、時系列データ正規化部１０３で行う場合の動作を説明する図である。図２０において、通信トラヒック（スループット）４０１の時系列データは、図６の通信トラヒック４０１と同一である。４２１は、連続HMM（HMM層#1）で推定した状態シーケンスである。すなわち、通信トラヒック（スループット）４０１の時系列データを入力とする時系列データ正規化部１０３において、連続HMMから出力された状態シーケンスである。通信トラヒック（スループット）４０１の時系列データの変動（変動頻度、変動の大きさ）に応じて、連続HMMで推定した状態シーケンス４２１も激しく変化する（ばたつく）ことになる。

時系列データ正規化部１０３は、連続HMMで推定した状態のシーケンスに対して、離散HMM（HMM層#2）を用いて、状態間の遷移が類似するパターンを検出して１つのグループ（上位層の１つの状態）にまとめ、上位層の状態のシーケンスを出力する。このため、高頻度、高振幅で激しく遷移する状態シーケンスを例えば１つの状態としてまとめることができる。４２２は、状態シーケンス４２１に対して離散HMMに基づき類似パターンを１つの状態にまとめた結果の状態のシーケンスである。状態シーケンス４２２は、図１の状態のシーケンス２０３と一致していることがわかる。なお、階層HMMの階層数は２に制限されるものでないことは勿論である。例えばサンプルトラヒックを用いて階層モデルをEMアルゴリズム等を用いて学習する場合に、スループットの小刻みな変動（通信ノイズ）を除去できた階層数を階層モデルの階層数として設定するようにしてもよい。

時系列データ正規化部１０３で用いる階層モデル（例えば連続HMMのモデルと上位層の離散HMMのモデル）として、記憶部１０４に記憶される。記憶部１０４はRAM、HDD等であってもよい。階層モデルは、サンプルトラヒックを流し、得られたスループットの時系列を階層モデルで分析し、モデルパラメータを設定し、通信ノイズを除去できた階層数を、階層モデルの階層数として設定するようにしてもよい。

＜実施形態３＞
次に、本発明の例示的な実施形態３について説明する。実施形態３のトラヒック分析装置１００の構成は、図１５と実施形態２と同様に、図７の通信ノイズ算出部１０２を削除することが可能である（ただし、図９の実施形態１と同様、通信ノイズ算出部１０２を備えた構成であってもよい）。

実施形態２との相違点は、実施形態３では、通信ノイズ除去手段として、時系列データ正規化部１０３において、HMMとして、状態滞在時間を考慮したHMMを用いている。アプリ状態と通信ノイズの特性の相違点として、IoT（Internet of Things）デバイスのカメラからの映像などは、長時間同一の状態（トラヒック特性、スループット）を継続する。カメラで取得した画像を圧縮符号化するエンコーダの符号化レートが所定時間の間一定の場合、カメラからの通信トラヒックのスループットは一定となる。一方、通信ノイズは瞬間的に発生する。

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

入力値がある一定時間変わらない場合を想定したモデルパラメータ（連続混合HMMのモデルパラメータ）として、

に加えて、状態iに固有の持続時間分布F_ｒのパラメータλiが加えられる。

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

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

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

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

なお、図２１の例では、アプリ状態(リアルタイム映像配信)では、状態が一定時間変わらないことを想定しているため、状態のシーケンス：s=(s1,…, s_T)において、アプリ状態(映像)（４２５の状態#1）の各状態の持続時間（Duration time）ｒ（モデルパラメータ）は一定としている。
状態１の持続時間rが、アプリケーション(例えば同一のリアルタイム映像配信)の動作モードによって、相違する場合等、通信トラヒック（スループット）の変動（通信ノイズ）の影響を受けることも考慮して、時系列データ正規化部１０３では、持続時間rをHMMモデルに基づき推定するようにしてもよいことは勿論である。なお、連続HMMをEDHMMで構成してもよいことは勿論である。

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

＜実施形態４＞
図２２は、本発明の例示的な実施形態４のトラヒック分析装置１００の構成を例示する図である。図２２を参照すると、図９の実施形態１のトラヒック分析装置１００の構成に加え、記憶部１０４の階層モデルを更新する階層モデル更新部１０７を備えている。階層モデル更新部１０７は、トラヒック源であるアプリケーション状態の特性の変化に追従するため、階層モデルを更新する。

階層モデルの更新方法としては、例えばバッチ処理と、オンライン処理とに大別してもよい。このうち、バッチ処理は、図２３（Ａ）に模式的に示すように、適当なデータブロック長（入力データの長さ）単位で最新のスループットデータを分析し、その分析結果に基づき階層モデルを更新する。階層HMMモデルの推定は前述の実施形態１と同様である。データブロック長は、固定であっても可変であってもよい。

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

階層モデル更新部１０７で更新するモデルパラメータとして、前述した連続混合HMMのモデルパラメータ

及び、上層HMMのモデルのグループ毎のモデルθ１、θ２と、グループ間の遷移確率Δの少なくとも１つを含む。

オンライン処理では、図２３（Ｂ）に示すように、過去に分析したモデルパラメータと新たに得たデータブロックから階層モデルを推定するようにしてもよい。インクリメンタルにモデル推定を行うことで計算量を削減し、オンライン処理でクリティカルに要求されるTiming Budgetを満たすことが可能となる。モデル推定は実施形態１と同様である。

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

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

あるいは、アプリ状態予測部１０８は、確率的予測１（シミュレーション）を行ってもよい。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)
・・・(35)
とする。

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

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

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

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

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

＜実施形態６＞
図２６は、本発明の例示的な実施形態６を説明する図である。実施形態６では、実施形態５のアプリ状態予測部１０８に変えて、アプリ状態の予測結果を利用して、通信トラヒック（例えばスループット）を予測するアプリ状態・通信トラヒック予測部１０９をさらに備えている。アプリ状態・通信トラヒック予測部１０９は、アプリ状態予測部と通信トラヒック予測部を一体化したものである。アプリ状態・通信トラヒック予測部１０９におけるアプリ状態の予測は、アプリ状態予測部１０８における予測方法と同一である。

アプリ状態・通信トラヒック予測部１０９における将来の通信トラヒック（例えばスループット）の予測方法として、時系列的予測を行うようにしてもよい。

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

アプリ状態・通信トラヒック予測部１０９は、アプリ状態の予測部で、予測した将来のアプリ状態に該当する時系列モデルを選択する。

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

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

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

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

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

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

あるいは、トラヒック分析装置１００を、キャリアネットワークのトラヒック・ディテクション・ファンクション（TDF）として実装し、トラヒックとアプリ状態との関係を解析しトラヒックに対応するアプリケーションを認識し、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計算部１１１は、
動画（カメラ）アプリQoEでは、例えば、
- 動画が途切れない、
- 高画質等の場合、
QoEは「良い」（５段階の４）と評価する。なお、QoEは、非常に良い、良い、普通、悪い、非常に悪い等の５段階評価が用いられる。なお、映像の場合、評価対象の映像のMOS（Mean Opinion Score）から基準映像のMOSを差し引いたDMOS（Differential Mean Opinion Score）を用いるようにしてもよい。評価対象の映像のMOSから基準映像のMOSを差し引き、これに５を加えるようにしてもよい（ACR(Absolute Category Rating)-HRR（Hidden Reference Removal））。

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)）６１、記憶装置（メモリ）６２、表示装置６３、通信インタフェース６４を備える。記憶装置６２は、例えばＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ等の半導体ストレージ、ＨＤＤ、ＣＤ、ＤＶＤ等であってもよい。記憶装置６２は、プロセッサ６１で実行されるプログラム（命令群、データ等）を格納する。プロセッサ６１は、記憶装置６２に格納されたプログラムを実行することで、前記各実施形態のトラヒック分析装置１００の機能を実現する。通信インタフェース６４は、図８（Ａ）、図８（Ｂ）のネットワークノード２０との通信接続を制御するインタフェースである。通信インタフェース６４は、図８（Ｃ）において通信ネットワーク５０に流れるパケット（例えば端末３０とサーバ４０間のパケット）を転送するネットワークインタフェースとして機能してもよい。

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

特に制限されないが、上記した実施形態は以下のように付記される。

(付記１）
通信トラヒックの時系列データに対して隠れマルコフモデルに基づき、状態のシーケンスを推定し、前記状態のシーケンスから状態遷移が類似するパターンをひとまとめにして１つの状態とみなして状態のシーケンスを抽出する第１の手段と、
前記第１の手段で抽出された前記状態のシーケンスと、予め定められたアプリケーション特性とに基づき、前記時系列データに対応するアプリケーション状態を判別する第２の手段と、
を備えた、ことを特徴とするトラヒック分析装置。

(付記２）
前記通信トラヒックが流れるネットワークのタイプに対応したノイズ特性パラメータに基づき、通信ノイズを生成し、前記通信トラヒックの時系列データから前記通信ノイズを除去する第３の手段を備えた、ことを特徴とする付記１に記載のトラヒック分析装置。

(付記３）
前記第１の手段は、階層隠れマルコフモデルを前記時系列データに適用し、前記階層隠れマルコフモデルの下位層に基づき推定した状態のシーケンスに対して前記階層隠れマルコフモデルの上位層を適用し、前記状態のシーケンスのうち状態遷移のパターンが類似する区間の前記状態を１つのグループにまとめ前記上位層の１つの状態とする、ことを特徴とする付記１又は２に記載のトラヒック分析装置。

(付記４）
前記階層隠れマルコフモデルは、連続隠れマルコフモデルを前記下位層とし、離散隠れマルコフモデルを前記上位層として含む、ことを特徴とする付記３に記載のトラヒック分析装置。

(付記５）
前記階層隠れマルコフモデルを更新する手段を備えた、ことを特徴とする付記３又は４に記載のトラヒック分析装置。

(付記６）
前記第２の手段は、前記第１の手段で抽出された状態のシーケンスに対応する前記通信トラヒックの時系列データと、予め登録されたアプリケーション状態に対応する前記通信トラヒックの類似度に基づき、アプリケーション状態を判別する、ことを特徴とする付記１乃至４のいずれか一に記載のトラヒック分析装置。

(付記７）
前記第２の手段は、前記第１の手段で抽出された状態のシーケンスと、予め登録されたアプリケーション状態のシーケンスの類似度に基づき、アプリケーション状態を判別する、ことを特徴とする付記１乃至４のいずれか一に記載のトラヒック分析装置。

(付記８）
前記第２の手段は、前記通信トラヒックの特徴量を抽出し、前記特徴量と予め登録されたアプリケーションの特徴量とを照合し、アプリケーション状態を判別する、ことを特徴とする付記１乃至４のいずれか一に記載のトラヒック分析装置。

(付記９）
前記第２の手段は、アプリケーションの通信トラヒックの特徴量を、教師データとして、アプリケーションを判別する分類モデルを機械学習し、
評価対象の通信トラヒックの時系列データに対して前記分類モデルを用いてアプリケーション状態を判別する、ことを特徴とする付記１乃至４のいずれか一に記載のトラヒック分析装置。

(付記１０）
前記第１の手段は、状態滞在時間分布を考慮したHMM（Explicit-Duration HMM）モデルを用いて通信ノイズを除去する、ことを特徴とする付記１乃至９のいずれか一に記載のトラヒック分析装置。

(付記１１）
現時点までに判定したいくつかのアプリケーション状態を用いて、将来のアプリケーション状態を予測する手段を備えた、ことを特徴とする付記１乃至１０のいずれか一に記載のトラヒック分析装置。

(付記１２）
現時点までに判定したいくつかのアプリケーション状態を用いて、将来の通信トラヒックを予測する手段を備えた、ことを特徴とする付記１乃至１０のいずれか一に記載のトラヒック分析装置。

(付記１３）
推定したアプリケーション状態に基づき、ネットワーク制御と通信制御の少なくとも一方を行う手段を備えた、ことを特徴とする付記１乃至１２のいずれか一に記載のトラヒック分析装置。

(付記１４）
前記アプリケーション状態に基づき、アプリケーション品質（QoE）を判別する手段を備えた、ことを特徴とする付記１乃至１３のいずれか一に記載のトラヒック分析装置。

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

(付記１６）
通信トラヒックの時系列データに対して隠れマルコフモデルに基づき、状態のシーケンスを推定し、前記状態のシーケンスから状態遷移が類似するパターンをひとまとめにして１つの状態とみなして状態のシーケンスを抽出し、
前記抽出された前記状態のシーケンスと、予め定められたアプリケーション特性とに基づき、前記時系列データに対応するアプリケーションを判別する、ことを特徴とするトラヒック分析方法。

(付記１７）
前記通信トラヒックが流れるネットワークのタイプに対応したノイズ特性パラメータに基づき、通信ノイズを生成し、前記通信トラヒックの時系列データから前記通信ノイズを除去する、ことを特徴とする付記１６に記載のトラヒック分析方法。

(付記１８）
階層隠れマルコフモデルを前記時系列データに適用し、前記階層隠れマルコフモデルの下位層に基づき推定した状態のシーケンスに対して前記階層隠れマルコフモデルの上位層を適用し、前記状態のシーケンスのうち状態遷移のパターンが類似する区間の前記状態を１つのグループにまとめ前記上位層の１つの状態とする、ことを特徴とする付記１６又は１７に記載のトラヒック分析方法。

(付記１９）
前記階層隠れマルコフモデルは、連続隠れマルコフモデルを前記下位層とし、離散隠れマルコフモデルを前記上位層として含む、ことを特徴とする付記１８に記載のトラヒック分析方法。

(付記２０）
前記階層隠れマルコフモデルを更新する、ことを特徴とする付記１８又は１９に記載のトラヒック分析方法。

(付記２１）
前記抽出された状態のシーケンスに対応する前記通信トラヒックの時系列データと、予め登録されたアプリケーション状態に対応する前記通信トラヒックの類似度に基づき、アプリケーション状態を判別する、ことを特徴とする付記１６乃至１９のいずれか一に記載のトラヒック分析方法。

(付記２２）
前記抽出された状態のシーケンスと、予め登録されたアプリケーション状態のシーケンスの類似度に基づき、アプリケーション状態を判別する、ことを特徴とする付記１６乃至１９のいずれか一に記載のトラヒック分析方法。

(付記２３）
前記通信トラヒックの特徴量を抽出し、前記特徴量と予め登録されたアプリケーションの特徴量とを照合し、アプリケーション状態を判別する、ことを特徴とする付記１６乃至１９のいずれか一に記載のトラヒック分析方法。

(付記２４）
アプリケーションの通信トラヒックの特徴量を、教師データとして、アプリケーションを判別する分類モデルを機械学習し、
評価対象の通信トラヒックの時系列データに対して前記分類モデルを用いてアプリケーション状態を判別する、ことを特徴とする付記１６乃至１９のいずれか一に記載のトラヒック分析方法。

(付記２５）
状態滞在時間分布を考慮したHMM（Explicit-Duration HMM）モデルを用いて通信ノイズを除去する、ことを特徴とする付記１６乃至２４のいずれか一に記載のトラヒック分析方法。

(付記２６）
現時点までに判定したいくつかのアプリケーション状態を用いて、将来のアプリケーション状態を予測する手段を備えた、ことを特徴とする付記１６乃至２５のいずれか一に記載のトラヒック分析方法。

(付記２７）
現時点までに判定したいくつかのアプリケーション状態を用いて、将来の通信トラヒックを予測する手段を備えた、ことを特徴とする付記１６乃至２５のいずれか一に記載のトラヒック分析方法。

(付記２８）
推定したアプリケーション状態に基づき、ネットワーク制御と通信制御の少なくとも一方を行う手段を備えた、ことを特徴とする付記１６乃至２７のいずれか一に記載のトラヒック分析方法。

(付記２９）
前記アプリケーション状態に基づき、アプリケーション品質（QoE）を判別する手段を備えた、ことを特徴とする付記１６乃至２８のいずれか一に記載のトラヒック分析方法。

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

(付記３１）
通信トラヒックの時系列データに対して隠れマルコフモデルに基づき、状態のシーケンスを推定し、前記状態のシーケンスから状態遷移が類似するパターンをひとまとめにして１つの状態とみなして状態のシーケンスを抽出する第１の処理と、
前記抽出された前記状態のシーケンスと、予め定められたアプリケーション特性とに基づき、前記時系列データに対応するアプリケーションを判別する第２の処理と、
をコンピュータに実行させるプログラム。

(付記３２）
前記通信トラヒックが流れるネットワークのタイプに対応したノイズ特性パラメータに基づき、通信ノイズを生成し、前記通信トラヒックの時系列データから前記通信ノイズを除去する第３の処理を前記コンピュータに実行させる付記３１に記載のプログラム。

(付記３３）
前記第１の処理は、階層隠れマルコフモデルを前記時系列データに適用し、前記階層隠れマルコフモデルの下位層に基づき推定した状態のシーケンスに対して前記階層隠れマルコフモデルの上位層を適用し、前記状態のシーケンスのうち状態遷移のパターンが類似する区間の前記状態を１つのグループにまとめ前記上位層の１つの状態とする、ことを特徴とする付記３１又は３２に記載のプログラム。

(付記３４）
前記階層隠れマルコフモデルは、連続隠れマルコフモデルを前記下位層とし、離散隠れマルコフモデルを前記上位層として含む、付記３３に記載のプログラム。

(付記３５）
前記階層隠れマルコフモデルを更新する処理を前記コンピュータに実行させる付記３３又は３４に記載のプログラム。

(付記３６）
前記第２の処理は、前記第１の処理で抽出された状態のシーケンスに対応する前記通信トラヒックの時系列データと、予め登録されたアプリケーション状態に対応する前記通信トラヒックの類似度に基づき、アプリケーション状態を判別する、付記３１乃至３４のいずれか一に記載のプログラム。

(付記３７）
前記第２の処理は、前記第１の処理で抽出された状態のシーケンスと、予め登録されたアプリケーション状態のシーケンスの類似度に基づき、アプリケーション状態を判別する、付記３１乃至３４のいずれか一に記載のプログラム。

(付記３８）
前記第２の処理は、前記通信トラヒックの特徴量を抽出し、前記特徴量と予め登録されたアプリケーションの特徴量とを照合し、アプリケーション状態を判別する、付記３１乃至３４のいずれか一に記載のプログラム。
(付記３９）
前記第２の処理は、アプリケーションの通信トラヒックの特徴量を、教師データとして、アプリケーションを判別する分類モデルを機械学習し、
評価対象の通信トラヒックの時系列データに対して前記分類モデルを用いてアプリケーション状態を判別する、付記３１乃至３４のいずれか一に記載のプログラム。

(付記４０）
前記第１の処理は、状態滞在時間分布を考慮したHMM（Explicit-Duration HMM）モデルを用いて通信ノイズを除去する、付記３１乃至３９のいずれか一に記載のプログラム。

(付記４１）
現時点までに判定したいくつかのアプリケーション状態を用いて、将来のアプリケーション状態を予測する処理を、前記コンピュータに実行させる付記３１乃至４０のいずれか一に記載のプログラム。

(付記４２）
現時点までに判定したいくつかのアプリケーション状態を用いて、将来の通信トラヒックを予測する処理を、前記コンピュータに実行させる付記３１乃至４０のいずれか一に記載のプログラム。

(付記４３）
推定したアプリケーション状態に基づき、ネットワーク制御と通信制御の少なくとも一方を行う処理を、前記コンピュータに実行させる付記３１乃至４２のいずれか一に記載のプログラム。

(付記４４）
前記アプリケーション状態に基づき、アプリケーション品質（QoE）を判別する処理を前記コンピュータに実行させる付記３１乃至４３のいずれか一に記載のプログラム。

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

１ トラヒック分析装置
２ 第１の処理（第１のユニット）
３ 第２の処理（第２のユニット）
４ 階層モデル
５ アプリ特性
１０ パケットキャプチャ
２０ ネットワークノード
３０ 端末
４０ サーバ
５０ 通信ネットワーク
６０ コンピュータ装置
６１ プロセッサ
６２ 記憶装置
６３ 表示装置(モニタ)
６４ 通信インタフェース
１００ トラヒック分析装置
１０１ 通信トラヒック取得部
１０２ 通信ノイズ算出部
１０３ 状態シーケンス正規化部（時系列データ正規化部）
１０４ 記憶部（階層モデル記憶部）
１０５ アプリ状態判定部
１０６ 記憶部（アプリ特性記憶部）
１０７ 階層モデル更新部
１０８ アプリ状態予測部
１０９ アプリ状態・通信トラヒック予測部
１１０、１１２ 制御部
１１１ QoE計算部
２０１、４０１ 通信トラヒック（スループットの時系列データ)
２０２ 状態
２０２ａ、２０２ｂ、２０２ｃ 状態（誤推定の時間区間）
２０３ 状態（本来の状態）
２１１－１、２１１－２、２１１－３ 正規分布
３０１ HMM
３０２ 階層HMM
３０３ グループ１
３０４ グループ２
３１１、３１１－１、３１１－２ 隠れ状態
３１２、３１２－１、３１２－２ 混合GAUSS分布（混合正規分布）
３１３ d次元GAUSS分布（正規分布）
３１４ 出力確率
３１５ 観測値
４０２ 状態（HMM層#1の出力）
４０３ モデルパラメータ
４０４ 状態（正規化された状態のシーケンス、HMM層#2の出力）
４０４Ａ 状態#1の時間推移
４０４Ｂ 状態#2の時間推移
４０５ａ－４０５ｃ 通信ノイズ
４０６ 通信トラヒック（通信ノイズ除去後）
４０６ａ－４０７ｃ 通信トラヒックの時間区間
４０７ 状態
４０８、４１１ 正規化された時系列データ
４０９ アプリ１の特性
４１０ アプリ２の特性
４１２、４１３ 状態
４２１、４２４ HMM#1状態
４２２、４２５ HMM#2状態
４２３ 状態（正規化された状態シーケンス）
４２６ アプリ状態Aの時間推移
５００、５１１－５１ｎ 決定木
５１０ ランダムフォレスト
１０２１ 記憶部（内容）
１０２２ 一様乱数（生成部）
１０２３ 逆関数（累積分布関数の逆関数演算部）
１０２４ 整列部（ソート）
１０２５ ノイズ波形

Claims (5)

1. 通信トラヒックを取得する手段と、
   前記通信トラヒックの時系列データから、隠れマルコフモデルに基づき、アプリケーションの状態シーケンスを抽出する手段と、
   前記アプリケーションの状態シーケンスから類似するパターンをグループ化する手段と、
   前記グループ化したアプリケーションの状態シーケンスを、予め記憶されているアプリケーション特性と照合する手段と、
   前記通信トラヒックの時系列データに対応するアプリケーションの状態を判定する手段と、
   を備える通信装置。
2. 前記通信トラヒックの時系列データから通信ノイズを除去する手段を、さらに備え、
   前記通信ノイズが除去された前記通信トラヒックの時系列データから、隠れマルコフモデルに基づき、アプリケーションの状態シーケンスを抽出する、請求項１に記載の通信装置。
3. 前記通信装置は、中継装置、無線基地局、ＭＥＣ（Ｍｏｂｉｌｅ Ｅｄｇｅ Ｃｏｍｐｕｔｉｎｇ）サーバ、ゲートウェイ装置、サーバ装置のいずれかである請求項１または２に記載の通信装置。
4. 通信トラヒックを取得し、
   前記通信トラヒックの時系列データから、隠れマルコフモデルに基づき、アプリケーションの状態シーケンスを抽出し、
   前記アプリケーションの状態シーケンスから類似するパターンをグループ化し、
   前記グループ化したアプリケーションの状態シーケンスを、予め記憶されているアプリケーション特性と照合し、
   前記通信トラヒックの時系列データに対応するアプリケーションの状態を判定する、
   通信トラヒックを判定する方法。
5. 前記通信トラヒックの時系列データから、隠れマルコフモデルに基づき、アプリケーションの状態シーケンスを抽出する前に、前記通信トラヒックの時系列データから通信ノイズを除去する、請求項４に記載の通信トラヒックを判定する方法。

Images