(57)【特許請求の範囲】
【請求項１】
通信トラヒックの時系列データから確率的な状態遷移モデルを所定のタイミング毎に作成する状態遷移モデル生成手段と、
前記状態遷移モデル生成手段で作成された、２つのタイミングにおける状態遷移モデルに所定以上の差があり、かつ、ネットワークの通信状態が所定の条件を満たす場合に、状態遷移モデルを更新する状態遷移モデル更新手段と、
更新した状態遷移モデルを用いてアプリケーションの種別及び状態を推定するアプリケーション種別及び状態推定手段と、
を備える通信トラヒック分析装置。
【請求項２】
前記状態遷移モデル生成手段は、前記アプリケーション種別及び状態推定手段が第１スレッドにおいて第１状態遷移モデルを用いてアプリケーションの種別及び状態を推定する間に、第２スレッドにおいて、通信トラヒックの時系列データから確率的な第２状態遷移モデルを新たに作成する請求項１に記載の通信トラヒック分析装置。
【請求項３】
前記アプリケーション種別及び状態推定手段により推定したアプリケーション種別及び状態に基づいてネットワークの通信制御を実施する通信トラヒック制御手段
をさらに備える請求項１又は２に記載の通信トラヒック分析装置。
【請求項４】
前記状態遷移モデルを用いて、過去の確率的な状態遷移パターンと、状態の継続時間の確率的な分布を利用して、将来方向に状態確率を計算し、将来から現在方向にどの状態が選択されるかを計算して将来の所定タイミングまでのアプリケーション状態の変動パターンを予測する、将来アプリケーション状態変動予測手段
をさらに備える請求項１乃至３のいずれかに記載の通信トラヒック分析装置。
【請求項５】
通信トラヒックの時系列データから確率的な状態遷移モデルを所定のタイミング毎に作成することと、
作成された、２つのタイミングにおける状態遷移モデルに所定以上の差があり、かつ、ネットワークの通信状態が所定の条件を満たす場合に、状態遷移モデルを更新することと、
更新した状態遷移モデルを用いてアプリケーションの種別及び状態を推定することと、
を含む通信トラヒック分析方法。
【請求項６】
第１スレッドにおいて第１状態遷移モデルを用いてアプリケーションの種別及び状態を推定する間に、第２スレッドにおいて、通信トラヒックの時系列データから確率的な第２状態遷移モデルを新たに作成する請求項５に記載の通信トラヒック分析方法。
【請求項７】
推定したアプリケーション種別及び状態に基づいてネットワークの通信制御を実施すること
をさらに含む請求項６に記載の通信トラヒック分析方法。
【請求項８】
前記状態遷移モデルを用いて、過去の確率的な状態遷移パターンと、状態の継続時間の確率的な分布を利用して、将来方向に状態確率を計算し、将来から現在方向にどの状態が選択されるかを計算して将来の所定タイミングまでのアプリケーション状態の変動パターンを予測すること
をさらに含む請求項５乃至７のいずれかに記載の通信トラヒック分析方法。
【請求項９】
通信トラヒックの時系列データから確率的な状態遷移モデルを所定のタイミング毎に作成することと、
作成された、２つのタイミングにおける状態遷移モデルに所定以上の差があり、かつ、ネットワークの通信状態が所定の条件を満たす場合に、状態遷移モデルを更新することと、
更新した状態遷移モデルを用いてアプリケーションの種別及び状態を推定することと、
をプロセッサに実行させるためのプログラム。
【請求項１０】
通信トラヒックの時系列データから確率的な状態遷移モデルを所定のタイミング毎に作成することと、
作成された、２つのタイミングにおける状態遷移モデルに所定以上の差があり、かつ、ネットワークの通信状態が所定の条件を満たす場合に、状態遷移モデルを更新することと、
更新した状態遷移モデルを用いてアプリケーションの種別及び状態を推定することと、
をプロセッサに実行させるためのプログラムを記録したコンピュータに読み取り可能な非一時的記録媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信トラヒック分析装置、通信トラヒック分析方法、プログラム及び記録媒体に関する。
【背景技術】
【０００２】
通信サービスの高度化により、通信事業者の性能指標（例えば主要性能指標（Key Performance Indicator）：ＫＰＩ）は、例えば通信品質（Quality of Service：ＱｏＳ）から、人やモノを対象としたアプリケーション品質（例えば、Quality of Experience（ＱｏＥ）やQuality of Control（ＱｏＣ））に移行しつつある。一例として、ＩＴＵ−Ｔ（International Telecommunication Union Telecommunication Standardization Sector）では、Ｗｅｂ閲覧（Web-browsing）／動画のＱｏＥが策定されている（Recommendation ITU-T G.1031）。【０００３】
今後、アプリケーション品質に基づくネットワーク制御やネットワーク設計が重要視されることが想定される。例えば、人を対象とするアプリケーション品質では、ＩＴＵ−Ｔにおいて、Ｗｅｂアクセス（ITU-TRecommendation 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）のＱｏＥが定義されている。モノを対象としたアプリケーション品質では、機械制御の世界でネットワーク越しの制御（ネットワーク化システム）の検討が進んでいる。例えばネットワーク越しでの機械制御のパフォーマンスの指標の議論が進むものと思料される（ＱｏＰ：Quality of Performance、ＱｏＣ：Quality of Control）。【０００４】
近年、例えば、モノがインターネットにつながるＩｏＴ（Internet of Things）等の普及に伴い、通信利用者側の通信品質に対するニーズも高度化している。例えばＩｏＴ等では（及びＩｏＴ以外のアプリケーションの場合にも）、アプリケーションの動作状態が変わる場合がある。例えば、ＩｏＴのアプリケーションとして、ＩｏＴセンサカメラ（車載カメラ等）が撮像した映像（動画）データを、例えばナビゲーションデータ等とともに、ネットワークを介してサーバ（クラウド）等に送信し、サーバ側で受信データをリアルタイムに分析し、分析結果に基づき遠隔制御や遠隔支援（例えば車の自動運転や走行支援）等を行うアプリケーションでは、ネットワークのスループット等の変動に応じた映像配信（リアルタイム映像配信）を行うようにしてもよい。また、ウェアラブルカメラ等を用いた物体認識アプリケーションでは、該ウェアラブルカメラからの映像データを受け取ったサーバとウェアラブルカメラとが協調して物体認識を行う場合と、ウェアラブルカメラ単体で対象物体を追尾する場合とでは、必要なスループットは異なる。さらに、ＩｏＴデバイスとしてドローン搭載カメラによる空撮映像をリアルタイム中継する場合、ドローンからの映像配信やドローンのフライト情報（位置情報、高度、加速度情報等）の送信、ドローンへのコマンド設定等の各動作モードで、必要なスループットは異なる。なお、ネットワーク（例えば無線網、コアネットワーク、ＷＡＮ（Wide Area Network）等）では、電子メールや、静止画、動画（映像）、音声（通話）等、様々な通信トラヒックが、例えば同一ネットワーク上を流れることになるが、これらの通信トラヒックは、通信サービス毎に異なる特性を持つことが知られている。【０００５】
また、特許文献１には、パケットの挙動を推定するための数理モデルを特定するモデル特定装置が開示されている。特許文献１において、数理モデルとして隠れマルコフモデルが用いられている。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】国際公開第２０１１／１５８４２１号
【発明の概要】
【発明が解決しようとする課題】
【０００７】
通信事業者が、「刻々と変わる利用条件（アプリケーション種別及び状態）に応じて最適な通信品質」を提供し、通信利用者の満足度（ＱｏＥ: Quality of Experience）を高めるためには、きめ細やかな通信制御が必要とされる。【０００８】
しかし、前述した通信事業者の提供するネットワークを構成するネットワーク機器は、通信利用者（例えば端末）がどのようなアプリケーションを使っているのか、そのアプリケーションが、いかなる状態で動作しているのかを、直接知る術がない。【０００９】
また、通信トラヒックの時系列データからモデルを用いてアプリケーション種別及び状態を推定する際に、先行技術では処理時間を考慮していないため、観測した通信トラヒックの時系列データに対するリアルタイムな推定が困難である。【００１０】
本発明の目的は、通信トラヒックの時系列データからアプリケーション種別及び状態を推定する際に、リアルタイムな推定を実現することである。
【課題を解決するための手段】
【００１１】
本発明の一態様によれば、通信トラヒック分析装置は、通信トラヒックの時系列データから確率的な状態遷移モデルを所定のタイミング毎に作成する状態遷移モデル生成部と、状態遷移モデル作成部で作成された、２つのタイミングにおける状態遷移モデルに所定以上の差があり、かつ、ネットワークの通信状態が所定の条件を満たす場合に、状態遷移モデルを更新する状態遷移モデル更新部と、更新した状態遷移モデルを用いてアプリケーションの種別及び状態を推定するアプリケーション種別及び状態推定部と、を備える。【００１２】
本発明の一態様によれば、通信トラヒック分析方法は、通信トラヒックの時系列データから確率的な状態遷移モデルを所定のタイミング毎に作成することと、作成された、２つのタイミングにおける状態遷移モデルに所定以上の差があり、かつ、ネットワークの通信状態が所定の条件を満たす場合に、状態遷移モデルを更新することと、更新した状態遷移モデルを用いてアプリケーションの種別及び状態を推定することと、を含む。【００１３】
本発明の一態様によれば、プログラムは、通信トラヒックの時系列データから確率的な状態遷移モデルを所定のタイミング毎に作成することと、作成された、２つのタイミングにおける状態遷移モデルに所定以上の差があり、かつ、ネットワークの通信状態が所定の条件を満たす場合に、状態遷移モデルを更新することと、更新した状態遷移モデルを用いてアプリケーションの種別及び状態を推定することと、をプロセッサに実行させる。【００１４】
本発明の一態様によれば、記録媒体は、通信トラヒックの時系列データから確率的な状態遷移モデルを所定のタイミング毎に作成することと、作成された、２つのタイミングにおける状態遷移モデルに所定以上の差があり、かつ、ネットワークの通信状態が所定の条件を満たす場合に、状態遷移モデルを更新することと、更新した状態遷移モデルを用いてアプリケーションの種別及び状態を推定することと、をプロセッサに実行させるためのプログラムを記録したコンピュータに読み取り可能な非一時的記録媒体である。
【発明の効果】
【００１５】
本発明によれば、通信トラヒックの時系列データからアプリケーション種別及び状態を推定する際に、リアルタイムな推定を実現することが可能になる。なお、本発明により、当該効果の代わりに、又は当該効果とともに、他の効果が奏されてもよい。
【図面の簡単な説明】
【００１６】
【図１】本発明の第１の実施形態に係るシステムの概略的な構成の一例を示す説明図である。
【図２】第１の実施形態に係る通信トラヒック分析装置の構成の例を示すブロック図である。
【図３】第１の実施形態に係るモデル更新の動作フローの例を説明するためのフローチャートである。
【図４】本実施の形態における２つのスレッドを用いたリアルタイムなアプリケーション種別及び状態の推定の説明図である。
【図５】第２の実施形態に係る通信トラヒック分析装置の構成の例を示すブロック図である。
【図６】前向き確率算出フェーズの説明図である。
【図７】後向き状態遷移パターン算出フェーズの説明図である。
【図８】第３の実施形態に係る通信トラヒック分析装置の構成の例を示すブロック図である。
【図９】本発明の各実施形態の変形例に係るシステムの概略的な構成の一例を示す説明図である。
【発明を実施するための形態】
【００１７】
以下、添付の図面を参照して本発明の実施形態を詳細に説明する。なお、本明細書及び図面において、同様に説明されることが可能な要素については、同一の符号を付することにより重複説明が省略され得る。
【００１８】
説明は、以下の順序で行われる。
１．関連技術
２．本発明の実施形態の概要
３．本発明の実施形態に係るシステムの構成
４．第１の実施形態
４．１．通信トラヒック分析装置の構成
４．２．技術的特徴
４．３．まとめ
５．第２の実施形態
５．１．通信トラヒック分析装置の構成
５．２．技術的特徴
５．３．まとめ
６．第３の実施形態
６．１．通信トラヒック分析装置の構成
６．２．技術的特徴
６．３．まとめ
７．各実施形態の変形例
８．他の形態
【００１９】
＜＜１．関連技術＞＞
上述のような通信サービスを取り巻く背景のもと、今後の通信事業者には、
−  通信利用者の通信品質に対するニーズの高度化、
−  アプリケーション単位の要件に応じた通信、
−  刻々と変わるアプリケーションの利用状況等に応じた通信サービスの提供等が
求められることになる。このため、通信事業者では、アプリケーション種別及び状態の変化を把握することが課題となる。
【００２０】
通信事業者が、「刻々と変わる利用条件（アプリケーション種別及び状態）に応じて最適な通信品質」を提供し、通信利用者の満足度（ＱｏＥ: Quality of Experience）を高めるためには、きめ細やかな通信制御が必要とされる。この場合、例えば以下の点も課題になる。
−  制御対象パラメータ数の増加（通信帯域、伝送遅延の揺らぎ（ジッタ）等）など）
−  細かな制御周期。
【００２１】
しかしながら、通信事業者（通信事業者が提供するネットワーク機器等）で取得できる情報には制限がある。例えば、ネットワークを流れる暗号化された通信トラヒックの増大、通信トラヒック多様化により、通信トラヒックの中身を覗くDeep Packet Inspection（ＤＰＩ）の手法には限界がある。また、個人保護法の観点により、ＤＰＩそのものが使えなくなる可能性もある。暗号化やプライバシーの観点で通信データの中身をみることはできない。
【００２２】
取得できる情報は、５タプル（5-tuple（例えば、送信元／宛先のＩＰ（Internet Protocol）アドレス／ポート、プロトコル）と通信トラヒックパターン（例えば、スループット、パケットサイズ、パケット送信間隔等）である。
【００２３】
通信トラヒックフローは、ＩＰヘッダフィールド内に同一の情報を持つパケットのグループ（宛先ＩＰアドレスとポート番号、送信元ＩＰアドレスとポート番号が等しいパケットの集合）で構成される。ＩＰヘッダフィールドは、通信トラヒック発信元のアドレス（source address）、通信トラヒックの宛先アドレス（destination address）、発信元ポート、宛先ポート、プロトコル番号）を含む。ＩＰＱｏＳでは、これらのフィールドを「５タプル」と呼ぶ。
【００２４】
前述した通信事業者の提供するネットワークを構成するネットワーク機器は、通信利用者（例えば端末）がどのようなアプリケーションを使っているのか、そのアプリケーションが、いかなる状態で動作しているのかを、直接知る術がない。
【００２５】
そこで、関連技術１では、階層構造を持つ確率的な状態遷移モデル（確率的な状態遷移モデルは、例えば、隠れマルコフモデル）で観測した通信トラヒックの時系列データをモデル化し、アプリケーション種別及び状態を推定することで、通信網の可用帯域の変動などの時系列的な変化がある環境においてもアプリケーション種別及び状態の誤検知を防ぐことができる。
【００２６】
アプリケーション種別及び状態に応じた通信制御を実現するためにはリアルタイムにアプリケーション種別及び状態を推定することが重要である。関連技術１では、一定区間長の通信トラヒックの時系列データをバッチ処理的に分析し、階層型の確率的な状態遷移モデルのパラメータを学習し、学習に用いた区間の通信トラヒックの時系列データに対するアプリケーション種別及び状態を推定する。
【００２７】
＜＜２．本発明の実施形態の概要＞＞
（１）技術的課題
隠れマルコフモデルのような状態遷移モデルのパラメータを学習する際には一定期間の学習時間を要する。したがって、一定区間長の通信トラヒックの時系列データが溜まった後に確率的な状態遷移モデルを生成し、その一定区間長のアプリケーション種別及び状態を推定する方式では、分析処理時間経過後にしかアプリケーション種別及び状態を推定することができないため、リアルタイムにアプリケーション種別及び状態を推定することは困難である。
【００２８】
通信トラヒックの時系列データからアプリケーション種別及び状態を推定する際に、先行技術では処理時間を考慮していないため、観測した通信トラヒックの時系列データに対するリアルタイムな推定が困難である。
【００２９】
本発明の実施形態の目的は、通信トラヒックの時系列データからアプリケーション種別及び状態を推定する際に、リアルタイムな推定を実現可能にすることである。
【００３０】
（２）技術的特徴
本発明の実施形態によれば、通信トラヒック分析装置は、例えば、通信トラヒックの時系列データから確率的な状態遷移モデルを所定のタイミング毎に作成する状態遷移モデル生成部と、状態遷移モデル作成部で作成された、２つのタイミングにおける状態遷移モデルに所定以上の差があり、かつ、ネットワークの通信状態が所定の条件を満たす場合に、状態遷移モデルを更新する状態遷移モデル更新部と、更新した状態遷移モデルを用いてアプリケーションの種別及び状態を推定するアプリケーション種別及び状態推定部と、を備える。
【００３１】
これにより、例えば、通信トラヒックの時系列データからアプリケーション種別及び状態を推定する際に、リアルタイムな推定を実現することが可能になる。
【００３２】
なお、上述した技術的特徴は本発明の実施形態の具体的な一例であり、当然ながら、本実施形態は上述した技術的特徴に限定されない。
【００３３】
＜＜３．本発明の実施形態に係るシステムの構成＞＞
図１は、本発明の各実施形態に係るシステム１の概略的な構成の一例を示す説明図である。
【００３４】
システム１は、パケットキャプチャ１０と、通信ネットワーク５０を構成するネットワークノード２０と、端末装置３０と、サーバ４０と、通信トラヒック分析装置１００とを備える。
【００３５】
パケットキャプチャ１０は、通信ネットワーク５０を流れるプロトコルデータ単位（Protocol Data Unit：ＰＤＵ）であるパケットをキャプチャ（捕捉）する。パケットキャプチャ１０は、各パケットのヘッダ等を解析し、例えばパケットの送信元アドレス、送信先アドレス、ポート、パケットサイズ、単位時間当たりのパケット個数、及びパケット送信時間間隔等を解析する。パケットキャプチャ１０は、通信ネットワーク５０内に配置されたネットワークノード２０（例えばルータ等の中継装置）等に接続され、通信ネットワーク５０上に流れるパケット、例えば端末装置３０とサーバ４０間で送信及び受信されるパケットをキャプチャする。
【００３６】
ネットワークノード２０は、コアネットワーク内のゲートウェイ・ノード、又は無線アクセスネットワークの基地局等であってもよい。
【００３７】
端末装置３０は、例えばネットワークノード２０を介してサーバ４０とパケットを送受信してもよい。また、端末装置３０は、ネットワークノード２０を介して他の端末装置３０とパケットを送受信してもよい。サーバ４０は、例えばネットワークノード２０を介して端末装置３０とパケットを送受信してもよい。図１には、ネットワークノード２０、端末装置３０及びサーバ４０は１つずつ図示しているが、それぞれ複数備えても良い。
【００３８】
通信トラヒック分析装置１００は、パケットキャプチャ１０で算出された、端末装置３０とサーバ４０間又は複数の端末装置３０間の通信トラヒック（スループット）の時系列データを取得し、トラヒックの解析を行う。通信トラヒック分析装置１００を、通信ネットワーク５０を介して接続する不図示のクラウドサーバ等に実装するようにしてもよい。
【００３９】
＜＜４．第１の実施形態＞＞
＜４．１．通信トラヒック分析装置の構成＞
まず、図２を参照して、第１の実施形態に係る通信トラヒック分析装置１００の構成の例を説明する。図２は、第１の実施形態に係る通信トラヒック分析装置１００の構成の例を示すブロック図である。図２を参照すると、通信トラヒック分析装置１００は、ネットワーク通信部１１０、記憶部１２０及び処理部１３０を備える。通信トラヒック分析装置１００は、通信トラヒックの時系列データの変動波形（変動頻度、変動の大きさ）から推定したアプリケーション種別及び状態の遷移を確率的に算出するように構成される。
【００４０】
（１）ネットワーク通信部１１０
ネットワーク通信部１１０は、ネットワークから信号を受信し、ネットワークへ信号を送信する。
【００４１】
（２）記憶部１２０
記憶部１２０は、通信トラヒック分析装置１００の動作のためのプログラム及びパラメータ、並びに様々なデータを、一時的に又は恒久的に記憶する。
【００４２】
（３）処理部１３０
処理部１３０は、通信トラヒック分析装置１００の様々な機能を提供する。処理部１３０は、通信トラヒック取得部１３１、状態遷移モデル生成部１３２、状態遷移モデル更新部１３３、オンラインアプリケーション種別及び状態推定部１３４、及び通信トラヒック制御部１３５を含む。なお、処理部１３０は、これらの構成要素以外の他の構成要素をさらに含み得る。すなわち、処理部１３０は、これらの構成要素の動作以外の動作も行い得る。例えば、処理部１３０（不図示の通信処理部）は、ネットワーク通信部２１０を介して他のノードと通信し得る。通信トラヒック取得部１３１、状態遷移モデル生成部１３２、状態遷移モデル更新部１３３、オンラインアプリケーション種別及び状態推定部１３４、及び通信トラヒック制御部１３５の具体的な動作は、後に詳細に説明する。
【００４３】
（４）通信トラヒック取得部１３１
通信トラヒック取得部１３１は、パケットキャプチャ１０から解析対象の通信トラヒックをリアルタイムで取得する。解析対象の通信トラヒックは予め定めることができる。
【００４４】
（５）状態遷移モデル生成部１３２
状態遷移モデル生成部１３２は、通信トラヒックの時系列データの変動波形からアプリケーション種別及び状態を確率的に推定するための状態遷移モデルを生成する。例えば、状態遷移モデル生成部１３２は、通信トラヒックの時系列データから確率的な状態遷移モデルを所定のタイミング毎に作成する。状態遷移モデルの生成手法については既知の手法を用いることができる。
【００４５】
（６）状態遷移モデル更新部１３３
状態遷移モデル更新部１３３は、オンラインアプリケーション種別及び状態推定部で利用する状態遷移モデルのパラメータを更新するタイミングを決定する。なお、状態遷移モデルのパラメータは状態遷移モデル生成部１３２によって生成される。状態遷移モデル更新部１３３は、例えば、状態遷移モデル生成部１３２で作成された、２つのタイミングにおける状態遷移モデルに所定以上の差があり、かつ、ネットワークの通信状態が所定の条件（例えば、通信制御に与える影響が少ないこと）を満たす場合に、状態遷移モデルを更新する。状態遷移モデル更新部１３３は、本実施の形態の特徴の１つである。詳細な動作については、以下の動作の説明の欄で記述する。
【００４６】
（７）オンラインアプリケーション種別及び状態推定部１３４
オンラインアプリケーション種別及び状態推定部１３４は、通信トラヒック取得部１３１で観測した通信トラヒックをリアルタイムに分析し、観測したタイミングのアプリケーション種別及び状態を推定する。例えば、オンラインアプリケーション種別及び状態推定部１３４は、状態遷移モデル更新部１３３が更新した状態遷移モデルを用いてアプリケーションの種別及び状態を推定する。アプリケーション種別及び状態推定部オンラインアプリケーション種別及び状態推定部１３４も、本実施形態の特徴の１つである。詳細な動作については、以下の動作の説明の欄で記述する。
【００４７】
（８）通信トラヒック制御部１３５
通信トラヒック制御部１３５は、例えば通信トラヒックを分析した結果を用いて、通信トラヒックを制御する。例えば、通信トラヒック制御部１３５は、オンラインアプリケーション種別及び状態推定部１３４により推定したアプリケーション種別及び状態に基づいてネットワークの通信制御を実施する。通信トラヒック制御部１３５は、直接、通信制御等を行うようにしてもよいし、又は、ネットワークノード（Ｌ３スイッチ（Layer 3スイッチ）、基地局、ゲートウェイ等）に対して通信制御の指示を送信するようにしてもよい。
【００４８】
（９）実装例
ネットワーク通信部１１０は、ネットワークアダプタ又はネットワークインタフェースカード等により実装されてもよい。記憶部１２０は、メモリ（例えば、不揮発性メモリ及び／若しくは揮発性メモリ）並びに／又はハードディスク等により実装されてもよい。処理部１３０は、プロセッサ等により実装されてもよい。通信トラヒック取得部１３１、状態遷移モデル生成部１３２、状態遷移モデル更新部１３３、オンラインアプリケーション種別及び状態推定部１３４、及び通信トラヒック制御部１３５は、これらの複数又は全てが同一のプロセッサにより実装されてもよく、それぞれ別々に異なるプロセッサにより実装されてもよい。上記メモリ（記憶部１２０）は、このようなプロセッサ（チップ）内に含まれてもよい。
【００４９】
通信トラヒック分析装置１００は、プログラムを記憶するメモリと、当該プログラムを実行可能な１つ以上のプロセッサとを含んでもよく、当該１つ以上のプロセッサは、処理部１３０の動作（通信トラヒック取得部１３１、状態遷移モデル生成部１３２、状態遷移モデル更新部１３３、オンラインアプリケーション種別及び状態推定部１３４、及び通信トラヒック制御部１３５の動作）を行ってもよい。上記プログラムは、処理部１３０の動作（通信トラヒック取得部１３１、状態遷移モデル生成部１３２、状態遷移モデル更新部１３３、オンラインアプリケーション種別及び状態推定部１３４、及び通信トラヒック制御部１３５の動作）をプロセッサに実行させるためのプログラムであってもよい。
【００５０】
＜４．２．技術的特徴＞
（１）ネットワーク制御
ネットワーク制御として、通信トラヒック制御部１３５は、アプリケーション種別及び状態に応じて、トラヒックシェーピング、フィルタリングを制御するようにしてもよい。なお、トラヒックシェーピングは、パケット送信時の速度（送信間隔）を調整しトラヒックを一定のレートとする、帯域確保、帯域制限及び優先制御等の制御等を行う。フィルタリングは、トラヒックを検査し指定したフィルタリングルールに基づいて個々のネットワーク接続が許可または拒否する。
【００５１】
ネットワークノードが基地局の場合や基地局機能を含む場合、又は、モバイルエッジコンピューティング装置に実装される場合、無線品質に応じた無線チャネルの割り当てにあたり、該緊急度の高い移動局（端末）に対して、優先的に無線チャネルを割り当る等の無線スケジューリングを行うようにしてもよい。
【００５２】
或いは、通信トラヒック分析装置１００を、キャリアネットワークのトラヒック・ディテクション・ファンクション（ＴＤＦ）として実装してもよい。この場合、通信トラヒック分析装置１００は、通信トラヒックとアプリケーション種別及び状態との関係を解析し、トラヒックに対応するアプリケーションを認識し、ＰＣＲＦ（Policy and Charging Rules Function）が制御ルールを決定する。そして、ＰＣＥＦ（Policy and Charging Rules Enforcement）により帯域制御、経路変更等の制御を行うようにしてもよい。
【００５３】
また、アプリケーション種別及び状態に応じた通信制御として、通信のタイミング（パケットデータの送信時刻、送信間隔等）、送信元、中継局（トランスコーダ）等における不図示のエンコーダ（符号化部）の圧縮符号化（圧縮符号化方式、符号化レート、フレームレート、解像度等）を制御するようにしてもよい。
【００５４】
（２）処理の流れ
次に、第１の実施形態に係る処理の流れの例を説明する。
【００５５】
アプリケーション種別及び状態が時々刻々と変化するような通信トラヒックをリアルタイムに分析するために、本実施形態では、特にモデル更新機能とオンラインでのアプリケーション種別及び状態推定機能を提供する。
【００５６】
動作フローは大きく２つに分割できる。１つ目は、状態遷移モデル更新部１３３の動作フローであり、観測した通信トラヒックの時系列データからモデルを作成し、最新のモデルに更新する。２つ目は、オンラインアプリケーション種別及び状態推定部１３４の動作フローであり、最新の状態遷移モデルを用いてオンラインでアプリケーション種別及び状態を推定する。以下、順に説明する。
【００５７】
（フロー１：モデル更新機能）
本実施形態においては、状態遷移モデル更新部１３３は、モデル更新のタイミングの適切さを考慮してモデル更新を実施する。モデル更新タイミングの適切さとは、例えば以下の２点ある。
【００５８】
１点目は、モデル更新による通信制御への影響度合いである。最もシンプルなモデル更新タイミングは、定期的にモデル作成しモデルを更新することである。ただし、通信制御のタイミングとの兼ね合いが重要である。例えば、通信発生中にモデルを更新すると、通信断などのアプリケーション品質の劣化を招く可能性がある。したがって、本実施の形態では、通信制御への影響度合いが小さいタイミングにモデル更新を行う。具体例は後述する。
【００５９】
２点目は、モデルの変化度合いである。モデルの変化度合いは以前のモデルと最新のモデルとの差分が小さければ、モデル更新の必要が無い（又は必要性が小さい）ため、モデルを更新しない。一方で、モデルの変化度合いが大きければ、モデルを更新する。モデルの変化度合いは、例えば、新たにモデルを作成した結果、アプリケーション種別及び状態数の変化があった際に変化度合いが大きいと設定する、などの条件を予め定めておくことができる。
【００６０】
図３は、第１の実施形態に係るモデル更新の動作フローの例を説明するためのフローチャートである。
【００６１】
まず、処理部１３０（状態遷移モデル生成部１３２）は、予め定められたタイミングで（周期的でもよい）。蓄積した通信トラヒックデータから状態遷移モデルを生成する（Ｓ１０１）。次に、処理部１３０（状態遷移モデル更新部１３３）は、通信状態をモニタリングし、モデルを更新しても通信への影響が小さいか否かを判定する（Ｓ１０３）。例えば、処理部１３０（状態遷移モデル更新部１３３）は、通信トラヒックが発生していないとき（又は通信トラヒックが所定量以下のとき）、又は重要度の低いアプリケーション種別及び状態の通信時に、モデルを更新しても影響が小さいと判定し、モデル更新可能フラグを立て、ステップＳ１０５の処理へ移る。一方、処理部１３０（状態遷移モデル更新部１３３）は、これら以外の場合、ステップＳ１０１に戻り、次の処理タイミングでステップＳ１０１以降の処理を再度実行する。
【００６２】
ステップＳ１０５では、処理部１３０（状態遷移モデル更新部１３３）は、モデル更新可能フラグが立っていることを確認し（すなわち、モデルを更新しても通信への影響が小さい）、モデルの変化度合いを評価する（Ｓ１０５）。モデルの変化度合いは、ステップＳ１０１で生成した状態遷移モデルと、既存の（例えば、使用中の）状態遷移モデルの差分をとる。処理部１３０（状態遷移モデル更新部１３３）は、変化度合いが予め定められた基準（例えば閾値）より大きい場合はモデルを更新する（Ｓ１０７）。より具体的には、処理部１３０（状態遷移モデル更新部１３３）は、使用中の状態遷移モデルを、ステップＳ１０１で生成した状態遷移モデルに置き換える。
【００６３】
（リアルタイムなアプリケーション種別及び状態の推定）
次に、リアルタイムなアプリケーション種別及び状態の推定について説明する。図４は、本実施の形態における２つのスレッドを用いたリアルタイムなアプリケーション種別及び状態の推定の説明図である。
【００６４】
例えば、図４に示すようにスレッドを２つ用意し、分析開始タイミングではスレッド１（第１スレッド）のみが動作する。スレッド１では、所定区間長の観測データを利用してモデル作成を開始する。モデル作成が完了次第、作成したモデルを利用してオンラインでのアプリケーション種別及び状態推定を実施する。
【００６５】
また、スレッド１のモデル作成開始のタイミングからスレッド２（第２スレッド）を起動する。スレッド２では、スレッド１の動作中に所定区間長の観測データを蓄積し、モデルを作成する。その後、スレッド１でのオンライン推定を停止し、スレッド２でのオンライン推定を実施する。例えば、図３を参照して説明したモデルを更新するタイミングで、オンライン推定をスレッド１からスレッド２に切り替えることができる。
【００６６】
このように、オンラインアプリケーション種別及び状態推定部１３４が第１スレッドにおいて第１状態遷移モデルを用いてアプリケーションの種別及び状態を推定する間に、状態遷移モデル生成部１３２は、第２スレッドにおいて、通信トラヒックの時系列データから確率的な第２状態遷移モデルを新たに作成する。
【００６７】
このように２つのスレッドを用いてモデル更新とオンライン推定を実施することで、常にリアルタイムな推定を実現できる。ただし、スレッドの動作内容は、上述の例に限定されない。スレッド１ではモデル作成のみを実施し、スレッド２ではオンライン推定のみを実施する構成にしてもよい。また、スレッド数は２つに限定されず、３つ以上でもよい。
【００６８】
以上より、本実施の形態においては、通信トラヒック取得部１３１で通信状態を監視し、通信トラヒックが発生していないとき、又は重要度の低いアプリケーション種別及び状態の通信時に、モデル更新可能フラグを立てる。モデル更新可能フラグが立っているときに、モデルの変化度合いを算出し、モデルの変化度合いが大きいときにモデル更新を実施する。上述のように、モデル更新が適切なタイミングで実施されることで、より正確なアプリケーション種別及び状態の推定が可能になる。
【００６９】
（フロー２：オンラインアプリケーション種別及び状態推定）
オンラインアプリケーション種別及び状態推定部１３４では、最新のモデルを用いて、観測した通信トラヒックからアプリケーション種別及び状態を推定する。アプリケーション種別及び状態を推定する方法の一例を以下に示す。
【００７０】
まず、処理部１３０(状態遷移モデル生成部１３２)が、パラメータを定義する。本実施形態の文中では、アプリケーション種別及び状態のことを、単に状態と記述する。Ｎを状態数、ｏｔを時刻ｔにおけるｄ次元の観測データ、ｓｔを時刻ｔにおける状態とする。このときの、ｎ階層の確率的な状態遷移モデルのモデルパラメータを次のように定義する。
【００７１】
【数１】
0006927417.tif 000002
【００７２】
ここで、ａｉｊは状態ｉからｊに遷移する確率、ｂｉ（ｏｔ）は状態ｉにおいてｏｔが観測される確率、πｉは時刻ｔ＝０において状態がｉである確率、ｐｉ（τ）は、状態ｉがτ時間継続する確率を示す。
【００７３】
まず、オンラインアプリケーション推定では、処理部１３０（オンラインアプリケーション種別及び状態推定部１３４）は、一層目の状態遷移モデルの状態推定値を算出する。状態推定値を算出するために、現時刻ｔで状態がｉである確率αｔ１（ｉ）を以下の（１）式で計算する。なお、αｔ１（ｉ）の１とｔは同じ列に並ぶが、入力の都合上左記のように記載する。他のパラメータの表記についても同様である。
【００７４】
【数２】
0006927417.tif 000003
【００７５】
次に、処理部１３０（オンラインアプリケーション種別及び状態推定部１３４）は、以下の（２）式で状態推定値を計算する。
【００７６】
【数３】
0006927417.tif 000004
【００７７】
上記の（２）式の推定結果が一層目の状態遷移モデルの状態推定値となる。二層目以降については、処理部１３０（オンラインアプリケーション種別及び状態推定部１３４）は、（１）式のｏｔにｎ−１層の状態推定値ｓｔ＾（ｎ−１）を入力することで、一層目と同様に（１）式と（２）式より状態推定値を算出できる。処理部１３０（オンラインアプリケーション種別及び状態推定部１３４）は、ｎ層まで繰り返し計算する。
【００７８】
以上より、フロー１とフロー２を並列実行することで、状態遷移モデルを最新の状態に保ちつつ、観測した通信トラヒックの時系列データに対してリアルタイムにアプリケーション種別及び状態推定が可能となる。
【００７９】
＜４．３．まとめ＞
以上、第１の実施形態を説明した。第１の実施形態によれば、通信トラヒックの時系列データからアプリケーション種別及び状態を推定する際に、リアルタイムな推定を実現することが可能になる。また、時々刻々と変化するアプリケーション種別及び状態の変化に対してリアルタイムに追従し、アプリケーション品質を満足する通信制御を実現する。
【００８０】
＜＜５．第２の実施形態＞＞
続いて、図５〜図７を参照して、本発明の第２の実施形態を説明する。
【００８１】
＜５．１．通信トラヒック分析装置の構成＞
図５を参照して、第２の実施形態に係る通信トラヒック分析装置２００の構成の例を説明する。図５は、第２の実施形態に係る通信トラヒック分析装置２００の構成の例を示すブロック図である。図５を参照すると、通信トラヒック分析装置２００は、第１の実施形態の通信トラヒック分析装置１００に加えて、処理部２３０に将来アプリケーション種別及び状態予測部１３６をさらに有する。
【００８２】
（１）将来アプリケーション種別及び状態予測部１３６
将来アプリケーション種別及び状態予測部１３６は、観測した通信トラヒックの時系列データと、状態遷移モデルパラメータとを用いて、将来のアプリケーション種別及び状態の遷移パターンを予測する。
【００８３】
他の構成は、上述の第１の実施形態の各構成と同様であるので説明を省略する。
【００８４】
＜５．２．技術的特徴＞
本実施形態においる将来予測の目的のひとつは、将来のアプリケーション種別及び状態の変化パターンを予め算出することで、先回りの通信制御を実現することである。
【００８５】
確率的な状態遷移モデルを用いて将来予測をする場合、予測した状態が頻繁に切り替わる現象が発生し得る。したがって、予測したアプリケーション種別及び状態が頻繁に切り替わる場合、予測したアプリケーション種別及び状態は通信制御においては意味をもたない。
【００８６】
そこで、本実施形態では、確率的な状態遷移モデルを用いて、長期先のアプリケーション種別及び状態遷移パターンを予測する方法を説明する。なお、本実施形態の文中では、アプリケーション種別及び状態のことを、単に状態と記述する。
【００８７】
予測方法の要点は例えば２つである。１つ目は、現在時刻から将来予測したいＴ期先（例えばＴ秒先）まで、どの状態がどれくらいの確率で発生するのかを算出する（以下、前向き確率算出フェーズと称する）。２つ目は、Ｔ期先から、確率の高い状態を選択して、状態遷移パターンを算出する（以下、後向き状態遷移パターン算出フェーズと称する）。
【００８８】
まず、パラメータとして、第１の実施形態で用いたパラメータと同様のパラメータを用いる。また、予測のために、最後に状態が変化してから時刻tまでの状態滞在時間をτｔ（ｉ）とおく。さらに、今回予測をしたいものはアプリケーション種別及び状態の遷移パターンであるため、n階層目の状態遷移モデルだけに着目する。
【００８９】
（前向き確率算出フェーズ）
確率を格納するためのパラメータとして、状態遷移モデルλが与えられたときに時刻ｔ−１で状態がｉ、時刻ｔで状態がｊとなる確率αｔ（ｉ，ｊ）を、以下のように定義する。
【００９０】
【数４】
0006927417.tif 000005
【００９１】
このとき、時刻ｔで状態が遷移する確率は、以下の（３）式で計算できる。
【００９２】
【数５】
0006927417.tif 000006
【００９３】
また、時刻ｔで状態が維持する確率は、以下の（４）式で計算できる。
【００９４】
【数６】
0006927417.tif 000007
【００９５】
換言すると、将来アプリケーション種別及び状態予測部１３６は、状態遷移モデルを用いて、過去の確率的な状態遷移パターン（例：上式のαｔ-τ（ｉ））と、状態の継続時間の確率的な分布（例：上式のｐｊ）を利用して、将来方向に状態確率を計算する。
【００９６】
したがって、以下の（５）式で定義される、時刻ｔで状態がｉである確率は、以下の（６）式で算出できる。
【００９７】
【数７】
0006927417.tif 000008
【００９８】
また、時刻ｔで状態ｉとなるときの時刻ｔ−１での状態は、以下の式で計算できる。
【００９９】
【数８】
0006927417.tif 000009
【０１００】
図６は、前向き確率算出フェーズの説明図である。前向き確率算出フェーズの要点のひとつは、確率計算の開始ポイントである。処理部２３０（将来アプリケーション種別及び状態予測部１３６）は、ある時刻の確率を計算する際に、直近で状態遷移が発生した時刻から、上述の（３）式と（４）式を用いて確率の計算を実施する。処理部２３０（将来アプリケーション種別及び状態予測部１３６）は、上述の（３）式と（４）式を用いて将来の時刻において状態がｉ（又はｊ）である確率を順次計算する。処理部２３０（将来アプリケーション種別及び状態予測部１３６）は、算出した確率を時刻及び状態と対応づけて記憶部１２０に記憶する。
【０１０１】
（後向き状態遷移パターン算出フェーズ）
後向き状態遷移パターン算出フェーズでは、将来の時刻ｔｃ＋Ｔから現時刻ｔｃに向かって、どの状態が選択されるかを以下の（７）式で算出する。
【０１０２】
【数９】
0006927417.tif 000010
【０１０３】
換言すると、将来アプリケーション種別及び状態予測部１３６は、将来から現在方向にどの状態が選択されるかを計算して将来の所定タイミングまでのアプリケーション状態の変動パターンを予測する。
【０１０４】
図７は、後向き状態遷移パターン算出フェーズの説明図である。処理部２３０（将来アプリケーション種別及び状態予測部１３６）は、時刻ｔｃ＋Ｔにおいて、前向き確率の値が大きな状態を選択する。これらの確率及び状態は、上述の前向き確率算出フェーズにおいて、記憶部１２０に記憶されている。その後、処理部２３０（将来アプリケーション種別及び状態予測部１３６）は、現在時刻ｔｃ方向に、確率の大きな状態を選択することで後向きに状態遷移パターンが取得できる。
【０１０５】
以上より、状態遷移パターンの予測値が一意に決定される。処理部２３０（将来アプリケーション種別及び状態予測部１３６）は、予測された状態遷移パターン及び中間結果を表示してもよいし、適宜の外部装置へ出力してもよい。また、処理部２３０（通信トラヒック制御部１３５）は、予測された状態遷移パターンを用いて通信制御を行ってもよい。
【０１０６】
＜５．３．まとめ＞
以上、第２の実施形態を説明した。第２の実施形態によれば、通信トラヒックの時系列データからアプリケーション種別及び状態を推定する際に、リアルタイムな推定を実現することが可能になる。また、第２の実施形態によれば、将来のアプリケーション種別及び状態の変化パターンを予め算出することができる。
【０１０７】
＜＜６．第３の実施形態＞＞
続いて、図８を参照して、本発明の第３の実施形態を説明する。上述した第１及び第２の実施形態は、具体的な実施形態であるが、第３の実施形態は、より一般化された実施形態である。
【０１０８】
＜６．１．通信トラヒック分析装置の構成＞
まず、図８を参照して、第３の実施形態に係る通信トラヒック分析装置３００の構成の例を説明する。図８は、第３の実施形態に係る通信トラヒック分析装置３００の構成の例を示すブロック図である。図８を参照すると、通信トラヒック分析装置３００は、状態遷移モデル生成部３３２、状態遷移モデル更新部３３３及びオンラインアプリケーション種別及び状態推定部３３４を有する。
【０１０９】
（１）状態遷移モデル生成部３３２
状態遷移モデル生成部３３２は、通信トラヒックの時系列データの変動波形からアプリケーション種別及び状態を確率的に推定するための状態遷移モデルを生成する。例えば、状態遷移モデル生成部３３２は、通信トラヒックの時系列データから確率的な状態遷移モデルを所定のタイミング毎に作成する。状態遷移モデルの生成手法については既知の手法を用いることができる。
【０１１０】
（２）状態遷移モデル更新部３３３
状態遷移モデル更新部３３３は、オンラインアプリケーション種別及び状態推定部で利用する状態遷移モデルのパラメータを更新するタイミングを決定する。なお、状態遷移モデルのパラメータは状態遷移モデル生成部３３２によって生成される。状態遷移モデル更新部３３３は、例えば、状態遷移モデル生成部３３２で作成された、２つのタイミングにおける状態遷移モデルに所定以上の差があり、かつ、ネットワークの通信状態が所定の条件（例えば、通信制御に与える影響が少ないこと）を満たす場合に、状態遷移モデルを更新する。
【０１１１】
（３）オンラインアプリケーション種別及び状態推定部３３４
オンラインアプリケーション種別及び状態推定部３３４は、観測した通信トラヒックをリアルタイムに分析し、観測したタイミングのアプリケーション種別及び状態を推定する。例えば、オンラインアプリケーション種別及び状態推定部３３４は、状態遷移モデル更新部３３３が更新した状態遷移モデルを用いてアプリケーションの種別及び状態を推定する。
【０１１２】
（４）実装例
状態遷移モデル生成部３３２、状態遷移モデル更新部３３３、及びオンラインアプリケーション種別及び状態推定部３３４は、これらの複数又は全てが同一のプロセッサにより実装されてもよく、それぞれ別々に異なるプロセッサにより実装されてもよい。上記メモリ（記憶部２２０）は、このようなプロセッサ（チップ）内に含まれてもよい。
【０１１３】
通信トラヒック分析装置１００は、プログラムを記憶するメモリと、当該プログラムを実行可能な１つ以上のプロセッサとを含んでもよく、当該１つ以上のプロセッサは、処理部１３０の動作（状態遷移モデル生成部３３２、状態遷移モデル更新部３３３、及びオンラインアプリケーション種別及び状態推定部３３４の動作）を行ってもよい。上記プログラムは、処理部１３０の動作（状態遷移モデル生成部３３２、状態遷移モデル更新部３３３、及びオンラインアプリケーション種別及び状態推定部３３４の動作）をプロセッサに実行させるためのプログラムであってもよい。
【０１１４】
＜６．２．技術的特徴＞
第３の実施形態に係る処理の流れは、第１の実施形態におけるこれらについての説明と同じである。よって、ここでは重複する説明を省略する。
【０１１５】
＜６．３．まとめ＞
以上、第３の実施形態を説明した。第３の実施形態によれば、通信トラヒックの時系列データからアプリケーション種別及び状態を推定する際に、リアルタイムな推定を実現することが可能になる。
【０１１６】
＜＜７．各実施形態の変形例＞＞
次に、図９を参照して、上述の各実施形態の変形例を説明する。図９は、本発明の各実施形態の変形例に係るシステム２、３の概略的な構成の一例を示す説明図である。
【０１１７】
上述の各実施形態では、図１に示すように通信トラヒック分析装置１００はパケットキャプチャ１０とは別の装置として実装される例を説明した。
【０１１８】
図９（ａ）に示すように、通信トラヒック分析装置内に、図１のパケットキャプチャ１０を実装し、パケットキャプチャ１０と通信トラヒック分析装置を一体に実装した構成（通信トラヒック分析装置４００）としてもよい。また、図９（ｂ）に示すように、パケットキャプチャ及び通信トラヒック分析装置を、通信ネットワーク５０のノード（例えばルータ等の中継装置、無線基地局やＭＥＣ（Mobile Edge Computing）サーバ等、コアネットワーク上のゲートウェイやサーバ等）と一体に実装した構成（通信トラヒック分析装置５００）としてもよい。また、通信トラヒック分析装置を、端末装置３０の内部に実装する構成にしてもよい。
【０１１９】
＜＜８．他の形態＞＞
以上、本発明の実施形態を説明したが、本発明はこれらの実施形態に限定されるものではない。これらの実施形態は例示にすぎないということ、及び、本発明のスコープ及び精神から逸脱することなく様々な変形が可能であるということは、当業者に理解されるであろう。
【０１２０】
また、本明細書において説明した通信トラヒック分析装置の構成要素（例えば、状態遷移モデル生成部、状態遷移モデル更新部及び／又はアプリケーション種別及び状態推定部など）を備える装置（例えば、通信トラヒック分析装置のためのモジュール）が提供されてもよい。また、上記構成要素の処理を含む方法が提供されてもよく、上記構成要素の処理をプロセッサに実行させるためのプログラムが提供されてもよい。また、当該プログラムを記録したコンピュータに読み取り可能な非一時的記録媒体（Non-transitory computer readable medium）が提供されてもよい。当然ながら、このような装置、方法、プログラム、及びコンピュータに読み取り可能な非一時的記録媒体も本発明に含まれる。
【０１２１】
上記実施形態の一部又は全部は、以下の付記のようにも記載され得るが、以下には限られない。
【０１２２】
（付記１）
通信トラヒックの時系列データから確率的な状態遷移モデルを所定のタイミング毎に作成する状態遷移モデル生成部と、
前記状態遷移モデル生成部で作成された、２つのタイミングにおける状態遷移モデルに所定以上の差があり、かつ、ネットワークの通信状態が所定の条件を満たす場合に、状態遷移モデルを更新する状態遷移モデル更新部と、
更新した状態遷移モデルを用いてアプリケーションの種別及び状態を推定するアプリケーション種別及び状態推定部と、
を備える通信トラヒック分析装置。
【０１２３】
（付記２）
前記状態遷移モデル生成部は、前記アプリケーション種別及び状態推定部が第１スレッドにおいて第１状態遷移モデルを用いてアプリケーションの種別及び状態を推定する間に、第２スレッドにおいて、通信トラヒックの時系列データから確率的な第２状態遷移モデルを新たに作成する付記１に記載の通信トラヒック分析装置。
【０１２４】
（付記３）
前記アプリケーション種別及び状態推定部により推定したアプリケーション種別及び状態に基づいてネットワークの通信制御を実施する通信トラヒック制御部
をさらに備える付記１又は２に記載の通信トラヒック分析装置。
【０１２５】
（付記４）
前記状態遷移モデルを用いて、過去の確率的な状態遷移パターンと、状態の継続時間の確率的な分布を利用して、将来方向に状態確率を計算し、将来から現在方向にどの状態が選択されるかを計算して将来の所定タイミングまでのアプリケーション状態の変動パターンを予測する、将来アプリケーション状態変動予測部
をさらに備える付記１乃至３のいずれかに記載の通信トラヒック分析装置。
【０１２６】
（付記５）
通信トラヒックの時系列データから確率的な状態遷移モデルを所定のタイミング毎に作成することと、
作成された、２つのタイミングにおける状態遷移モデルに所定以上の差があり、かつ、ネットワークの通信状態が所定の条件を満たす場合に、状態遷移モデルを更新することと、
更新した状態遷移モデルを用いてアプリケーションの種別及び状態を推定することと、
を含む通信トラヒック分析方法。
【０１２７】
（付記６）
第１スレッドにおいて第１状態遷移モデルを用いてアプリケーションの種別及び状態を推定する間に、第２スレッドにおいて、通信トラヒックの時系列データから確率的な第２状態遷移モデルを新たに作成する付記５に記載の通信トラヒック分析方法。
【０１２８】
（付記７）
推定したアプリケーション種別及び状態に基づいてネットワークの通信制御を実施すること
をさらに含む付記６に記載の通信トラヒック分析方法。
【０１２９】
（付記８）
前記状態遷移モデルを用いて、過去の確率的な状態遷移パターンと、状態の継続時間の確率的な分布を利用して、将来方向に状態確率を計算し、将来から現在方向にどの状態が選択されるかを計算して将来の所定タイミングまでのアプリケーション状態の変動パターンを予測すること
をさらに含む付記５乃至７のいずれかに記載の通信トラヒック分析方法。
【０１３０】
（付記９）
通信トラヒックの時系列データから確率的な状態遷移モデルを所定のタイミング毎に作成することと、
作成された、２つのタイミングにおける状態遷移モデルに所定以上の差があり、かつ、ネットワークの通信状態が所定の条件を満たす場合に、状態遷移モデルを更新することと、
更新した状態遷移モデルを用いてアプリケーションの種別及び状態を推定することと、
をプロセッサに実行させるためのプログラム。
【０１３１】
（付記１０）
通信トラヒックの時系列データから確率的な状態遷移モデルを所定のタイミング毎に作成することと、
作成された、２つのタイミングにおける状態遷移モデルに所定以上の差があり、かつ、ネットワークの通信状態が所定の条件を満たす場合に、状態遷移モデルを更新することと、
更新した状態遷移モデルを用いてアプリケーションの種別及び状態を推定することと、
をプロセッサに実行させるためのプログラムを記録したコンピュータに読み取り可能な非一時的記録媒体。
【０１３２】
この出願は、２０１８年３月２９日に出願された日本出願特願２０１８−０６３５９８を基礎とする優先権を主張し、その開示の全てをここに取り込む。
【産業上の利用可能性】
【０１３３】
本発明の目的は、通信トラヒックの時系列データからアプリケーション種別及び状態を推定する際に、リアルタイムな推定を実現することができる。
【符号の説明】
【０１３４】
１、２、３、４  システム
１０  パケットキャプチャ
２０  ネットワークノード
３０  端末装置
４０  サーバ
５０  通信ネットワーク
１００、２００、３００、４００、５００  通信トラヒック分析装置
１３０  処理部
１３１  通信トラヒック取得部
１３２  状態遷移モデル生成部
１３３  状態遷移モデル更新部
１３４  オンラインアプリケーション種別及び状態推定部
１３５  通信トラヒック制御部
１３６  将来アプリケーション種別及び状態予測部
【図１】
0006927417.tif 000011
【図２】
0006927417.tif 000012
【図３】
0006927417.tif 000013
【図４】
0006927417.tif 000014
【図５】
0006927417.tif 000015
【図６】
0006927417.tif 000016
【図７】
0006927417.tif 000017
【図８】
0006927417.tif 000018
【図９】
0006927417.tif 000019