JP6401537B2 - 予測装置及び予測方法 - Google Patents

Description

本発明は、予測装置及び予測方法に関する。

ケーブルテレビのネットワークにおいて広く用いられているＨＦＣ（Hybrid fiber coaxial）では、ノード配下のユーザ（例えば、５００〜２０００ユーザ）で回線を共有している。これらのユーザには、Ｐ２Ｐアプリケーションによるファイル交換を行うユーザや、動画のアップロード及びダウンロードを行うユーザや、自宅で録画したコンテンツのリモート視聴を行うユーザ等、大量のトラヒックを発生させるユーザも含まれることから、これらのユーザの回線の利用傾向に基づいてネットワークの設計を行うことが重要である。

適切な品質でネットワークサービスを提供するために、ネットワークを流れるトラヒックの量に基づいてネットワークの設計及び制御が行われている。例えば、特許文献１には、ネットワーク上のトラヒック量を監視し、一定時間内のトラヒック量が予め定められた閾値を超えないようにトラヒックを制御することが開示されている。

特開２００５−２０１９４号公報

ＣＡＴＶやスマートテレビにおいては、ＩＰ−ＶＯＤ（Video On Demand）、ネットワークゲーム、ＴＶ電話等のネットワークを利用するサービスは、個々の機能を持ったアプリケーションをインストールすることで実現される。そのため、このアプリケーションの利用状況と、個々のユーザが利用するトラヒックとの間には、密接な関係がある。そのため、新規のアプリケーションをリリースする場合等、そのアプリケーションがどの位導入・利用されるかによって、ノード、コアネットワーク、アプリケーションサーバ等の設計に反映させることが重要である。しかしながら、従来のネットワークの設計・制御方式では、実際に測定したトラヒック量に基づいてノードの分割やトラヒックの制御を行っていることから、サービス導入後にならないと、新規のサービスをどのくらいのユーザが利用し、どのくらいのトラヒックが増加するのか、高精度に予測することができない。このため、実際にサービスを導入した後に、ネットワークの遅延や、サーバの負荷が許容値を超えるといった問題が発生するおそれがあるという問題がある。

本発明はこれらの点に鑑みてなされたものであり、新規アプリケーションの提供前に、当該アプリケーションが、将来、ネットワークやサーバに与える負荷量を高精度に予測することができる予測装置及び予測方法を提供することを目的とする。

本発明の第１の態様に係る予測装置は、通信ネットワークのノードに接続されている端末のトラヒック量を示すトラヒック履歴情報を記憶する履歴情報記憶部と、複数の第１端末におけるトラヒック履歴情報に記憶されているトラヒック量の変化量を特定する変化量特定部と、前記端末の識別情報と、当該端末にインストールされているアプリケーションの識別情報とを関連付けてインストール情報として記憶するインストール情報記憶部と、前記インストール情報記憶部を参照し、前記複数の第１端末のアプリケーションのインストール情報に基づいて、第２端末と傾向が類似する第１端末を特定する類似端末特定部と、前記第２端末におけるトラヒック量を、特定した前記第１端末における前記変化量及び前記トラヒック履歴情報における前記第２端末のトラヒック量に基づいて予測する予測部と、を備える。

前記類似端末特定部は、前記複数の第１端末のアプリケーションのインストール情報と、前記トラヒック履歴情報とに基づいて、前記第２端末と傾向が類似する第１端末を特定してもよい。
前記予測部は、所定のノードに接続されている複数の前記第２端末におけるトラヒック量を予測することで、当該ノードにおけるトラヒック量を予測してもよい。

前記予測部は、アプリケーションに係る新たなサービスの提供の対象となる前記第２端末におけるトラヒック量を予測することで、当該アプリケーションに対応するアプリケーションダウンロードサーバ、及びアプリケーション実行サーバの少なくともいずれかにおける負荷量の増分を予測してもよい。

前記予測装置は、前記予測部において予測された前記ノードにおける前記トラヒック量が所定の閾値を超えたことに応じて、当該ノードにおける帯域制御を行う帯域制御部をさらに備えてもよい。

前記変化量特定部は、第１ノードにおける所定のアプリケーションのリリース後に、当該第１ノードを介して通信する前記複数の第１端末における前記変化量を特定し、前記予測部は、前記第１ノードとは異なる第２ノードにおける前記所定のアプリケーションのリリース前に、当該第２ノードを介して通信する前記第２端末におけるトラヒック量を予測してもよい。

前記予測装置は、それぞれが異なるアプリケーションのインストール傾向に対応する複数のグループのいずれかに前記複数の第１端末を分類する分類部をさらに備え、前記類似端末特定部は、前記第２端末におけるアプリケーションのインストール傾向に対応するグループを特定し、前記予測部は、前記第２端末におけるトラヒック量を、特定した前記グループにおけるトラヒックの変化量及び前記トラヒック履歴情報における前記第２端末のトラヒック量に基づいて予測してもよい。

本発明の第２の態様に掛かる予測方法は、通信ネットワークのノードに接続されている端末のトラヒック量を示すトラヒック履歴情報を参照し、複数の第１端末におけるトラヒックの変化量を特定するステップと、端末の識別情報と、当該端末にインストールされているアプリケーションの識別情報とを関連付けてインストール情報として記憶するインストール情報記憶部を参照し、前記複数の第１端末のアプリケーションのインストール情報に基づいて、第２端末と傾向が類似する第１端末を特定するステップと、前記第２端末におけるトラヒック量を、特定した前記第１端末におけるトラヒックの変化量及び前記トラヒック履歴情報における前記第２端末のトラヒック量に基づいて予測するステップと、を備える。

本発明によれば、新規アプリケーションの提供前に、当該アプリケーションが、将来、ネットワークやサーバに与える負荷量を高精度に予測することができるという効果を奏する。

第１の実施形態に係る予測装置及び当該予測装置の外部環境を示す図である。 第１の実施形態に係るアプリケーションサーバの機能構成図である。 第１の実施形態に係る予測装置の機能構成図である。 インストール情報の一例を示す図である。 トラヒック履歴情報の一例を示す図である。 ノード情報の一例を示す図である。 トラヒックの変化量を示す変化量情報の一例を示す図である。 第１実施形態に係る端末がアプリケーションサーバからアプリケーションをダウンロードする際のシーケンス図である。 第１実施形態に係る予測装置がアプリケーションサーバからダウンロード履歴情報を取得する際のシーケンス図である。 第１実施形態に係る予測装置がケーブルテレビ網における全ての第２ノードのトラヒック量を予測する際のフローチャートである。 第２の実施形態に係る予測装置の機能構成図である。 新規アプリケーションとしてＸアプリがリリースされた後の第１端末におけるアプリケーションのインストール状況及びトラヒック変化量を示す図である。 第２実施形態に係る予測装置が各ノードのトラヒック量を予測する際のフローチャートである。 第３の実施形態に係る予測装置及び当該予測装置の外部環境を示す図である。

以下、本発明の実施形態について説明する。
＜第１の実施形態＞
［予測装置１の概要］
図１は、第１の実施形態に係る予測装置１及び当該予測装置１の外部環境を示す図である。予測装置１は、ケーブルテレビの通信を制御するセンター局に設けられているサーバである。予測装置１は、センター局に設けられており、ケーブルテレビ網をインターネット等のネットワークＮに接続するための装置であるＣＭＴＳ（Cable Modem Termination System）２に接続されている。

ＣＭＴＳ２は、光伝送装置４、ノードアンプ５、及びアンプ６とケーブルテレビ網を構成する。ＣＭＴＳ２は、インターネット等のネットワークＮを介して、例えば、アプリケーションを提供するアプリケーションサーバ３等の外部サーバに接続されている。

光伝送装置４は、光ファイバを介して複数のノードアンプ５と接続されている。光伝送装置４は、センター局に設けられており、ＣＭＴＳ２から供給される電気信号を光信号に変換する。光伝送装置４は、変換した光信号を、光ファイバケーブルを介して複数のノードアンプ５に供給する。光伝送装置４は、複数のノードアンプ５から送信された光信号を電気信号に変換してＣＭＴＳ２に出力する。

ノードアンプ５は、同軸ケーブルを介してアンプ６と接続されている。ノードアンプ５は、光伝送装置４から供給された光信号を電気信号に変換し、同軸ケーブルを介してアンプ６に供給する。ノードアンプ５は、アンプ６から供給された電気信号を光信号に変換し、光ファイバケーブルを介して光伝送装置４に供給する通信機器である。本実施形態において、ノードアンプ５の配下には、５００〜２０００台の端末７が接続されている。以下、一のノードアンプ５の配下の端末を、「通信ネットワークのノードに接続されている端末」ともいう。
アンプ６は、同軸ケーブルを介して端末７に接続されている。アンプ６は、同軸ケーブルを流れる信号を増幅し、増幅した信号を端末７に供給する。

端末７は、ケーブルテレビを利用するユーザの住宅に設けられているＴＶ受信端末であり、例えば、セットトップボックスである。本実施形態において、端末７は、アプリケーションの実行環境を備えている。端末７は、ユーザの操作に応じて、ケーブルテレビ網及びネットワークＮを介して、アプリケーションサーバ３からアプリケーションをダウンロードし、インストールすることができる。新規アプリケーションをネットワーク経由でリリースする際、限定されたユーザを対象とした「トライアル」によって、先行的にアプリケーションをリリースしてテストを行うことが一般的である。また、トライアル以外にも、サービス提供エリアや事業者毎に、アプリケーションのリリース開始日が異なることが多い。本実施形態において、端末７には、新たなアプリケーションがトライアルとして先行リリースされる第１ノードに接続されている第１端末７Ａと、当該アプリケーションが先行リリースの後にリリースされる第２ノードに接続されている第２端末７Ｂとが含まれている。

端末７がダウンロードするアプリケーションの中には、動画視聴用のアプリケーションや、定期的に電子番組表を取得するアプリケーションがある。これらのアプリケーションがリリースされ、多くの端末７にインストールされて実行されると、大量のトラヒックが発生し、ネットワーク輻輳の原因となる。特に、同一のノードの配下の多くの端末７において動画視聴用等のアプリケーションがインストールされると、当該ノード配下のネットワークにおいて輻輳が発生する。

本発明は、このような問題に対応し、先行的にリリースされたエリアでの各ユーザのトラヒック発生状況から、後続的にリリースされるエリアのトラヒックを、ユーザのプロファイルに基づいて高精度に予測するものである。すなわち、予測装置１は、トライアルとして新たなアプリケーションが先行リリースされるノードである第１ノードにおいて、配下の第１端末７Ａにおけるトラヒックの変化量を特定する。そして、予測装置１は、その後、当該アプリケーションが先行リリースに対して遅れてリリースされる第２ノードの配下の第２端末７Ｂについて、アプリケーションのインストール状況に基づいて、当該第２端末７Ｂが新たなアプリケーションをインストールするか否かを予測するとともに、当該第２端末７Ｂのトラヒック量を、予め特定したトラヒックの変化量に基づいて予測する。これにより、センター局では、新たなアプリケーションがリリースされる第２ノード配下のネットワークにおいて輻輳が発生する前に、帯域制御やノードの追加といった対策をとることができる。以下、予測装置１及びアプリケーションサーバ３の機能構成について説明する。

［アプリケーションサーバ３の構成例］
まず、アプリケーションサーバ３の機能構成について説明する。図２は、第１の実施形態に係るアプリケーションサーバ３の機能構成図である。
アプリケーションサーバ３は、記憶部３１と、制御部３２とを備える。

記憶部３１は、例えば、ＲＯＭ及びＲＡＭ等により構成される。記憶部３１は、アプリケーションサーバ３を機能させるための各種プログラムを記憶する。例えば、記憶部３１は、アプリケーションサーバ３の制御部３２を、後述するダウンロード受付部３２１、アプリケーション送信部３２２、履歴管理部３２３及び履歴情報送信部３２４として機能させるプログラムを記憶する。

また、記憶部３１は、端末７がインストールすることができる複数のアプリケーションを記憶する。また、記憶部３１は、ダウンロード履歴情報を格納するダウンロード履歴ＤＢ３１１を記憶する。ダウンロード履歴情報は、アプリケーションサーバ３が送信したアプリケーションを識別するアプリケーションＩＤと、送信先の端末７のユーザを識別するユーザＩＤと、端末７にアプリケーションを送信し、端末７がアプリケーションをダウンロードした日時であるダウンロード日時とを関連付けた情報である。

制御部３２は、例えば、ＣＰＵにより構成される。制御部３２は、記憶部３１に記憶されている各種プログラムを実行することにより、アプリケーションサーバ３に係る機能を統括的に制御する。制御部３２は、ダウンロード受付部３２１と、アプリケーション送信部３２２と、履歴管理部３２３と、履歴情報送信部３２４とを備える。

ダウンロード受付部３２１は、端末７に対して、端末７がダウンロード可能なアプリケーションを紹介するページを送信し、当該端末７からアプリケーションのダウンロードのリクエストを受け付ける。ダウンロードのリクエストには、ユーザＩＤ及びアプリケーションＩＤが含まれている。

アプリケーション送信部３２２は、ダウンロード受付部３２１がダウンロードのリクエストを受け付けたことに応じて、当該リクエストに含まれているアプリケーションＩＤに対応するアプリケーションを記憶部３１から取得する。アプリケーション送信部３２２は、取得したアプリケーションを、リクエストを送信した端末７に送信する。

履歴管理部３２３は、端末７にアプリケーションを送信したことに応じて、ダウンロード履歴情報を生成し、ダウンロード履歴ＤＢ３１１に記憶させる。具体的には、履歴管理部３２３は、ダウンロードのリクエストに含まれているユーザＩＤ及びアプリケーションＩＤと、アプリケーションを送信した日時とを関連付けてダウンロード履歴情報を生成する。履歴管理部３２３は、生成したダウンロード履歴情報をダウンロード履歴ＤＢ３１１に記憶させる。

履歴情報送信部３２４は、ダウンロード履歴ＤＢ３１１に格納されたダウンロード履歴情報を予測装置１に送信する。具体的には、履歴情報送信部３２４は、予測装置１から定期的にダウンロード履歴情報の取得リクエストを受け付ける。履歴情報送信部３２４は、取得リクエストを受け付けると、ダウンロード履歴ＤＢ３１１に格納されているダウンロード履歴情報のうち、予測装置１に送信されていないダウンロード履歴情報を予測装置１に送信する。

［予測装置１の構成例］
続いて、予測装置１の機能構成について説明する。図３は、第１の実施形態に係る予測装置１の機能構成図である。
予測装置１は、記憶部１１と、制御部１２とを備える。

記憶部１１は、例えば、ＲＯＭ及びＲＡＭ等により構成される。記憶部１１は、予測装置１を機能させるための各種プログラムを記憶する。例えば、記憶部１１は、予測装置１の制御部１２を、後述するインストール情報取得部１２１、トラヒック量測定部１２２、変化量特定部１２３、類似端末特定部１２４、予測部１２５及び帯域制御部１２６として機能させる予測プログラムを記憶する。記憶部１１は、外部メモリ等の記憶媒体に記憶されたプログラムを読み取って記憶してもよく、ネットワークＮを介して外部機器からダウンロードされたプログラムを記憶してもよい。

また、記憶部１１は、予測装置１がトラヒック量を予測する際に用いる情報を格納するユーザアプリ情報ＤＢ１１１、トラヒック履歴ＤＢ１１２、ユーザ別トラヒックＤＢ１１３及びユーザＤＢ１１４を記憶する。これらのＤＢについての詳細は後述する。

制御部１２は、例えば、ＣＰＵにより構成される。制御部１２は、記憶部１１に記憶されている各種プログラムを実行することにより、予測装置１に係る機能を統括的に制御する。制御部１２は、インストール情報取得部１２１と、トラヒック量測定部１２２と、変化量特定部１２３と、類似端末特定部１２４と、予測部１２５と、帯域制御部１２６とを備える。

インストール情報取得部１２１は、端末７にインストールされているアプリケーションのアプリケーションＩＤを取得する。具体的には、インストール情報取得部１２１は、アプリケーションサーバ３にダウンロード履歴情報の取得リクエストを定期的に送信し、アプリケーションサーバ３からダウンロード履歴情報を受信する。インストール情報取得部１２１は、受信したダウンロード履歴情報をインストール情報としてユーザアプリ情報ＤＢ１１１に記憶させる。

図４は、ユーザアプリ情報ＤＢ１１１に記憶されたインストール情報の一例を示す図である。記憶部１１のユーザアプリ情報ＤＢ１１１は、インストール情報記憶部として機能し、端末７の識別情報としてのユーザＩＤと、当該端末７にインストールされているアプリケーションのアプリケーションＩＤと、端末７がアプリケーションをインストールした日時を示すインストール日時とを関連付けてインストール情報として記憶する。本実施形態においてインストール日時は、端末７がアプリケーションをダウンロードした日時であり、ダウンロード履歴情報におけるダウンロード日時と同一の情報である。

トラヒック量測定部１２２は、複数の端末７のそれぞれのトラヒック量を測定する。具体的には、トラヒック量測定部１２２は、ＣＭＴＳ２を流れるトラヒックを解析し、複数の端末７のそれぞれのトラヒック量を測定する。トラヒック量測定部１２２は、測定結果を示すトラヒック履歴情報をトラヒック履歴ＤＢ１１２に格納する。

図５は、トラヒック履歴情報の一例を示す図である。トラヒック履歴情報は、ケーブルテレビ網のノードに接続されている複数の端末７それぞれのトラヒック量を示す情報を含んでいる。図５に示すように、トラヒック履歴情報は、端末７のユーザのユーザＩＤと、トラヒックを測定した日時と、トラヒック量とを関連付けた情報である。

変化量特定部１２３は、複数の第１端末７Ａにおけるトラヒック履歴情報に記憶されているトラヒック量に対するトラヒックの変化量を特定する。具体的には、変化量特定部１２３は、ユーザＤＢ１１４に格納されているノード情報を参照し、所定のアプリケーションが先行してリリースされたノードである第１ノードの配下の第１端末７Ａを特定する。ここで、ノード情報は、図６に示すように、ノード（ノードアンプ５）を識別する識別情報としてのノードＩＤと、端末７のユーザのユーザＩＤとを関連付けた情報である。例えば、変化量特定部１２３は、入力部（不図示）を介して第１ノードに対応するノードＩＤを受け付け、ノード情報において、当該ノードＩＤに関連付けられているユーザＩＤを第１端末７Ａと特定する。

続いて、変化量特定部１２３は、例えば、入力部を介して、第１ノードにおいて所定のアプリケーションがリリースされた日時を受け付ける。続いて、変化量特定部１２３は、トラヒック履歴ＤＢ１１２に格納されているトラヒック履歴情報を参照し、第１ノードにおける所定のアプリケーションのリリース後に、当該第１ノードを介して通信する複数の第１端末７Ａそれぞれにおけるトラヒックの変化量を特定する。

変化量特定部１２３は、所定のアプリケーションがインストールされてから所定期間が経過するまでに測定された第１端末７Ａのトラヒック量と、所定のアプリケーションがインストールされる前の所定期間において測定された第１端末７Ａのトラヒック量とに基づいて、第１端末７Ａにおける各時間帯のトラヒックの変化量を特定する。変化量特定部１２３は、トラヒック量の変化量を特定すると、特定した変化量を示す情報をユーザ別トラヒックＤＢ１１３に記憶させる。図７は、変化量情報の一例を示す図である。変化量情報は、図７に示すように、ユーザＩＤと、時間帯を示す時間帯情報と、トラヒックの変化量とが関連付けられている。

ここで、変化量特定部１２３は、各曜日、各時間帯における、インストール前後のトラヒック量の差分を算出するようにしてもよい。例えば、アプリケーションには、所定の曜日の所定の時間帯に外部サーバから大量のデータをダウンロードするものがある。よって、各曜日、各時間帯における、インストール前後のトラヒック量の差分を算出することで、予測装置１は、所定のアプリケーションによって発生するトラヒック量のピークとなる曜日及び時間帯を特定し、ピーク時のトラヒック量の増加量を精度よく予測することができる。

類似端末特定部１２４は、ユーザアプリ情報ＤＢ１１１に格納されているインストール情報を参照し、複数の第１端末７Ａのアプリケーションのインストール情報に基づいて、第２端末７Ｂと傾向が類似する第１端末７Ａを特定する。

具体的には、まず、類似端末特定部１２４は、ノード情報を参照し、トラヒック量を予測する対象の第２ノードの配下の第２端末７Ｂを特定する。そして、類似端末特定部１２４は、ユーザアプリ情報ＤＢ１１１に格納されているインストール情報を参照し、特定した第２端末７Ｂにおけるアプリケーションのインストールの傾向を特定する。

例えば、類似端末特定部１２４は、特定した第２端末７Ｂのそれぞれについて、インストールの傾向の特定に用いる複数のアプリケーションのインストール状況を特定する。ここで、複数のアプリケーションとは、例えば、動画に関するアプリケーションや、ゲームに関するアプリケーションや、ニュースに関するアプリケーションであり、類似端末特定部１２４は、アプリケーションのインストール状況を、ベクトル値で表現する。例えば、類似端末特定部１２４は、５つのアプリケーションのインストール状況について、（１，０，０，１，１）といったように表現する。ここで、インストールされているアプリケーションに対応するベクトル値を１とし、インストールされていないアプリケーションに対応するベクトル値を０とする。

同様に、類似端末特定部１２４は、第１端末７Ａについても、インストールの傾向の特定に用いる複数のアプリケーションのインストール状況をベクトル化する。そして、類似端末特定部１２４は、第２端末７Ｂのベクトル値との一致率が最も高いベクトル値に対応する第１端末７Ａを、第２端末７Ｂと傾向が類似する第１端末７Ａと特定する。なお、類似端末特定部１２４は、協調フィルタリングを用いて、第２端末７Ｂと傾向が類似する第１端末７Ａを特定してもよい。

このように、第２端末７Ｂと傾向が類似する第１端末７Ａを特定することにより、予測装置１は、第１端末７Ａにおける所定のアプリケーションのインストール状況に基づいて、第２端末７Ｂが、所定のアプリケーションをインストールするか否かについて予測することができる。

なお、類似端末特定部１２４は、ユーザアプリ情報ＤＢ１１１及びトラヒック履歴ＤＢ１１２を参照し、複数の第１端末７Ａのアプリケーションのインストール情報と、トラヒック履歴情報とに基づいて、第２端末７Ｂと傾向が類似する第１端末７Ａを特定してもよい。このようにすることで、予測装置１は、アプリケーションのインストール傾向だけではなく、アプリケーションの使用傾向も第２端末７Ｂと類似する第１端末７Ａを特定することができる。

予測部１２５は、第２ノードにおける所定のアプリケーションのリリース前に、当該第２ノードを介して通信する第２端末７Ｂにおけるトラヒック量を、類似端末特定部１２４が特定した第１端末７Ａにおけるトラヒックの変化量、及びトラヒック履歴情報における第２端末７Ｂのトラヒック量に基づいて予測する。

具体的には、予測部１２５は、ユーザ別トラヒックＤＢ１１３に格納されている変化量情報を参照し、特定した第１端末７Ａに対応するトラヒックの変化量を特定する。また、予測部１２５は、トラヒック履歴情報を参照し、第２端末７Ｂのトラヒック量を特定する。続いて、予測部１２５は、特定したトラヒックの変化量と、トラヒック履歴情報を参照して得られたトラヒック量とを加算することにより、第２端末７Ｂにおけるトラヒック量を予測する。

また、予測部１２５は、第２ノードに接続されている複数の第２端末７Ｂにおけるトラヒック量を予測することで、当該第２ノードにおけるトラヒック量を予測する。すなわち、予測部１２５は、第２ノードに接続されている複数の第２端末７Ｂのそれぞれについて予測されたトラヒック量を集計することにより、当該第２ノードにおけるトラヒック量を予測する。

また、予測部１２５は、アプリケーションに係る新たなサービスの提供の対象となる第２端末７Ｂにおけるトラヒック量を予測することで、当該アプリケーションに対応するアプリケーションダウンロードサーバとしてのアプリケーションサーバ３、及びアプリケーション実行サーバの少なくともいずれかにおける負荷量の増分を予測してもよい。例えば、予測部１２５は、予測したトラヒック量に基づいて、アプリケーションサーバ３又はアプリケーション実行サーバにおける負荷量及び当該負荷量が最大となる時間帯を特定する。このようにすることで、サーバの管理者は、サーバにかかる負荷を事前に予測し、サービスが安定して行われるように対処することができる。

帯域制御部１２６は、予測部１２５において予測された第２ノードにおけるトラヒック量が所定の閾値を超えたことに応じて、当該第２ノードにおける帯域制御を行う。例えば、帯域制御部１２６は、あるノードにおいて、所定の時間帯のトラヒック量の予測値が、当該ノードの設計時に遅延なく通信を行うことができると見積もられているトラヒック量を超えている場合に、当該ノードにおいて、所定の時間帯に帯域制御を行う。このように、予測装置１は、予測値に基づいて帯域制御を行うので、ノード配下のネットワークにおける輻輳の発生を事前に予防することができる。

［アプリケーションのダウンロードに係るシーケンス］
続いて、予測装置１及びアプリケーションサーバ３における処理の流れについて説明する。図８は、第１実施形態に係る端末７がアプリケーションサーバ３からアプリケーションをダウンロードする際のシーケンス図である。

まず、端末７は、ケーブルテレビ網及びネットワークＮを介してアプリケーションのダウンロードのリクエストをアプリケーションサーバ３に送信する。
アプリケーションサーバ３のダウンロード受付部３２１がダウンロードのリクエストを受け付けたことに応じて、アプリケーション送信部３２２は、当該リクエストに含まれているアプリケーションＩＤに対応するアプリケーションを端末７に送信する。

その後、履歴管理部３２３は、端末７にアプリケーションを送信したことに応じて、ダウンロード履歴情報を生成し（Ｓ１０）、ダウンロード履歴ＤＢ３１１に記憶させる（Ｓ１１）。

［ダウンロード履歴の取得に係るシーケンス］
続いて、予測装置１が、アプリケーションサーバ３からダウンロード履歴情報を取得する際の処理の流れについて説明する。図９は、第１実施形態に係る予測装置１がアプリケーションサーバ３からダウンロード履歴情報を取得する際のシーケンス図である。

まず、予測装置１のインストール情報取得部１２１は、アプリケーションサーバ３に、ダウンロード履歴情報の取得を要求する取得リクエストを送信する。
アプリケーションサーバ３の履歴情報送信部３２４は、予測装置１からダウンロード履歴情報の取得リクエストを受信すると、ダウンロード履歴ＤＢ３１１に格納されているダウンロード履歴情報のうち、予測装置１に送信していないダウンロード履歴情報を抽出する（Ｓ２０）。続いて、アプリケーションサーバ３の履歴情報送信部３２４は、抽出したダウンロード履歴情報を予測装置１に送信する。

［全ノードのトラヒック量の予測に係るフローチャート］
続いて、予測装置１が、ケーブルテレビ網における全ての第２ノードのトラヒック量を予測する際の処理の流れについて説明する。図１０は、第１実施形態に係る予測装置１がケーブルテレビ網における全ての第２ノードのトラヒック量を予測する際のフローチャートである。本フローチャートの説明において、第２ノードは複数存在するものとする。

まず、変化量特定部１２３は、複数の第１端末７Ａにおけるトラヒック履歴情報に記憶されているトラヒック量に対するトラヒックの変化量を特定する（Ｓ３１）。変化量特定部１２３は、トラヒック量の変化量を特定すると、特定した変化量を示す情報をユーザ別トラヒックＤＢ１１３に記憶させる。

続いて、予測部１２５は、複数の第２ノードから、未だ選択されていない一の第２ノードを選択する（Ｓ３２）。
続いて、予測部１２５は、一の第２ノードに接続されている複数の第２端末７Ｂから、未だ選択されていない一の第２端末７Ｂを選択する（Ｓ３３）。
続いて、類似端末特定部１２４は、第１ノードに接続されている複数の第１端末７Ａから、第２端末７Ｂと類似する第１端末７Ａを特定する（Ｓ３４）。

続いて、予測部１２５は、Ｓ３３において選択された第２端末７Ｂにおける将来のトラヒック量を、Ｓ３４において特定した第１端末７Ａにおけるトラヒックの変化量、及びトラヒック履歴情報における当該第２端末７Ｂのトラヒック量に基づいて予測する（Ｓ３５）。
続いて、予測部１２５は、予測した第２端末７Ｂのトラヒック量を、Ｓ３２において選択された第２ノードのトラヒックの予測量に加算する（Ｓ３６）。

続いて、予測部１２５は、Ｓ３２において選択された第２ノードにおいて、全ての第２端末７Ｂのトラヒック量を予測したか否かを判定する（Ｓ３７）。予測部１２５は、全ての第２端末７Ｂのトラヒック量を予測したと判定した場合（判定がＹＥＳの場合）、Ｓ３２において選択された第２ノードにおけるトラヒックの予測が完了したこととなるので、Ｓ３８に処理を移し、全ての第２端末７Ｂのトラヒック量を予測していないと判定した場合（判定がＮＯの場合）、Ｓ３３に処理を移す。

続いて、予測部１２５は、全ての第２ノードのそれぞれのトラヒック量を予測したか否かを判定する（Ｓ３８）。予測部１２５は、全ての第２ノードのそれぞれのトラヒック量を予測したと判定した場合（判定がＹＥＳの場合）、本フローチャートに係る処理を終了する。また、予測部１２５は、全ての第２ノードのそれぞれのトラヒック量を予測していないと判定した場合（判定がＮＯの場合）、Ｓ３２に処理を移す。

［第１の実施形態における効果］
以上のとおり、第１の実施形態に係る予測装置１は、複数の第１端末７Ａのアプリケーションのインストール情報に基づいて、第２端末７Ｂと傾向が類似する第１端末７Ａを特定する。このようにすることで、予測装置１は、第２端末７Ｂに対する新規アプリケーションの提供前に、第２端末７Ｂと傾向が類似する第１端末７Ａにおける当該アプリケーションのインストール状況に基づいて、当該アプリケーションが第２端末７Ｂにインストールされるか否かを判定することができる。

また、予測装置１は、第２端末７Ｂにおけるトラヒック量を、傾向が類似すると特定した第１端末７Ａにおけるトラヒックの変化量及びトラヒック履歴情報における第２端末７Ｂのトラヒック量に基づいて予測する。このようにすることで、新規アプリケーションの第２端末７Ｂへの提供前に、当該アプリケーションが、将来、第２端末７Ｂが接続されるノードに係るネットワークやサーバに与える負荷量を高精度に予測することができる。
また、本実施例においてインストールされるアプリケーションは、まったく新規にリリースされるアプリケーションに限定されるものでは無い。すなわち、既にインストール済みのアプリケーションがバージョンアップすることによって、当該アプリケーションが利用するトラヒックが増加又は減少する場合も、予測装置１は、本実施例に記載の方法により、バージョンアップによるトラヒックの変化を事前に予測することが可能となる。

＜第２の実施形態＞
［インストール傾向に対応する複数のグループに分類してトラヒック量を予測する］
続いて、第２の実施形態について説明する。第１実施形態では、予測装置１は、第２端末７Ｂとアプリケーションのインストール傾向が類似する第１端末７Ａを特定し、当該第１端末７Ａにおけるトラヒックの変化量に基づいて第２端末７Ｂにおける将来のトラヒック量を予測した。

しかしながら、端末７の台数が多い場合、複数の第２端末７Ｂのそれぞれについて、インストール傾向が類似する第１端末７Ａを特定するのに処理時間がかかるという問題がある。そこで、第２の実施形態では、第２端末７Ｂを、アプリケーションのインストール状況に応じて、インストールの傾向を示す複数のグループのいずれかに分類し、分類されたグループに対応するトラヒックの変化量に基づいて第２端末７Ｂの将来のトラヒック量を予測する。以下、第２の実施形態について図面を参照して説明する。なお、第１の実施形態と同様の構成については同一の符号を付し、詳細な説明を省略する。

図１１は、第２の実施形態に係る予測装置１の機能構成図である。
第２の実施形態に係る予測装置１は、分類部１２７をさらに備える。分類部１２７は、ユーザアプリ情報ＤＢ１１１に記憶されているインストール情報、及びトラヒック履歴ＤＢ１１２に記憶されているトラヒック履歴情報に基づいて、それぞれが異なるアプリケーションのインストール傾向に対応する複数のグループのいずれかに複数の第１端末７Ａを分類する。ここで、分類部１２７は、既存のクラスタリング手法を用いて、複数の第１端末７Ａを複数のグループに分類してもよい。また、分類部１２７は、インストール情報及びトラヒック履歴情報に限らず、第１端末７Ａのユーザの属性（例えば、年齢や性別）に基づいて、第１端末７Ａを複数のグループに分類してもよい。

図１２は、新規アプリケーションとしてＸアプリがリリースされた後の第１端末７Ａにおけるアプリケーションのインストール状況及びトラヒック変化量を示す図である。図１２では、ユーザＩＤが「ＵＳＥＲ＿Ａ」、「ＵＳＥＲ＿Ｂ」、「ＵＳＥＲ＿Ｃ」、「ＵＳＥＲ＿Ｄ」の第１端末７Ａにおけるアプリケーションのインストール状況及びトラヒック変化量を示している。

分類部１２７は、例えば、第１端末７Ａを、主に動画に関するアプリケーションをインストールしている動画グループと、主にゲームに関するアプリケーションをインストールしているゲームグループと、アプリケーションの種別に関係なく多くのアプリケーションをインストールしているヘビーユーザグループと、その他のグループとのいずれかに分類する。分類部１２７は、例えば、「ＵＳＥＲ＿Ａ」、「ＵＳＥＲ＿Ｂ」の第１端末７Ａを動画グループに分類し、「ＵＳＥＲ＿Ｃ」の第１端末７Ａをゲームグループに分類し、「ＵＳＥＲ＿Ｄ」の第１端末７Ａをヘビーユーザグループに分類する。

このグループ化において、分類部１２７は、ユーザのアプリケーションのインストール有無によって、各ユーザ間の類似度を判別する。すなわち、ユーザＡのアプリケーション１のインストール状態をＡＰ_Ａ１、ユーザＡのアプリケーションｉのインストール状態をＡＰ_Ａｉ、ユーザＢのアプリケーション１のインストール状態をＡＰ_Ｂ１、ユーザＢのアプリケーションｉのインストール状態をＡＰ_Ｂｉで表し、ユーザＡがアプリケーションｉをインストールしている状態をＡＰ_Ａｉ＝１、インストールしていない状態をＡＰ_Ａｉ＝０、ユーザＢがアプリケーションｉをインストールしている状態をＡＰ_Ｂｉ＝１、インストールしていない状態をＡＰ_Ｂｉ＝０と定義するとき、ｎ個のアプリケーションのインストール状態に基づく、ＵＳＥＲ＿ＡとＵＳＥＲ＿Ｂの類似度ｄを、以下の式（１）に示すユークリッド距離ｄで定義する。

分類部１２７は、（１）式に基づいてユーザ間の類似度を算出する。分類部１２７は、算出したユーザ間の類似度ｄに基づき、各ユーザをグループ化する。分類部１２７は、グループ化の方法として、例えばｋ−ｍｅａｎｓ法を適用し、以下の手順（１）〜（５）に示される手法によって対応する。

（１）初期グループの中心として、代表的なユーザ（例えば、ゲーム重視ユーザ、アプリ重視ユーザ、ヘビーユーザ、アプリ未使用ユーザ）を設定するグループの数だけ指定する。
（２）サンプルデータについて、前述の代表的なユーザとの距離を用いて、最も近いユーザのグループに所属させ、全てのユーザをグループ分けする。
（３）グループに振り分けられたユーザについて、各アプリケーションのインストール状況の平均値を算出する。すなわち、グループ全員がアプリケーションｉをインストールしている場合、グループのインストール状況ＡＰ_ＡＶＥｉは１、グループの半数がアプリケーションｉをインストールした場合のＡＰ_ＡＶＥｉは０．５となる。
（４）算出されたＡＰ_ＡＶＥｉを、新たな各グループの中心として、各サンプルデータとの距離を再度算出。再グループ分けを実施する。
（５）上記手順を、グループが安定するまで実施する。

分類部１２７は、グループ化が完了すると、各グループのそれぞれのアプリケーションの利用に係るトラヒックの時間毎の推移（アプリケーションのリリース時の増加量）について、トラヒックの平均値を算出する。算出された平均値は、そのグループに属するユーザが、アプリケーションをリリースした際に、どのくらいのトラヒックを使うと期待されるかの予測値となる。

前述のグループ化について、分類部１２７は、ユーザが各アプリケーションをインストールしているか否かという、二値の情報を用いているが、その替わりに、ユーザが各アプリケーションを利用し、発生したトラヒック総量を用いても良い。すなわち、ＵＳＥＲ＿Ａがある一定期間でアプリケーション１を利用した際のトラヒック総量をＤ_Ａ１、アプリケーション２を利用した際のトラヒック総量をＤ_Ａ２とし、同様に、ＵＳＥＲ＿Ｂがアプリケーション１を利用したトラヒック総量をＤ_Ｂ１、アプリケーション２で利用したトラヒック総量をＤ_Ｂ２とする。トラヒック総量は、アプリケーションの利用傾向を示しており、また、類似のユーザは、アプリケーションの利用傾向が似ることから、分類部１２７は、ＵＳＥＲ＿ＡとＵＳＥＲ＿Ｂの類似度ｄを、以下の式（２）に示すユークリッド距離ｄで定義する。ここで、インストールされていないアプリケーションのトラヒック量は０とする。

変化量特定部１２３は、第１端末７Ａが分類された複数のグループのそれぞれについて、トラヒックの変化量を特定する。具体的には、変化量特定部１２３は、グループに属する複数の第１端末７Ａのトラヒックの変化量の平均値を算出することで、当該グループに対応するトラヒックの変化量を特定する。

類似端末特定部１２４は、第２端末７Ｂにおけるアプリケーションのインストール傾向に対応するグループを特定する。このようにすることで、類似端末特定部１２４は、第２端末７Ｂにおけるアプリケーションのインストール傾向と類似する複数の第１端末７Ａを特定することができる。

予測部１２５は、第２端末７Ｂにおける将来のトラヒック量を、特定したグループにおけるトラヒックの変化量、及びトラヒック履歴情報における第２端末７Ｂのトラヒック量に基づいて予測する。

［トラヒック量の予測に係るフローチャート］
続いて、予測装置１が、各ノードのトラヒック量を予測する際の処理の流れについて説明する。図１３は、第２実施形態に係る予測装置１が各ノードのトラヒック量を予測する際のフローチャートである。

まず、分類部１２７は、複数の第１端末７Ａを複数のグループのいずれかに分類する（Ｓ４１）。
続いて、変化量特定部１２３は、複数のグループそれぞれに係るトラヒックの変化量を特定する（Ｓ４２）。

続いて、予測部１２５は、複数の第２ノードから未だ選択されていない一の第２ノードを選択する（Ｓ４３）。
続いて、予測部１２５は、一の第２ノードに接続されている複数の第２端末７Ｂから、未だ選択されていない一の第２端末７Ｂを選択する（Ｓ４４）。
続いて、類似端末特定部１２４は、複数のグループから、第２端末７Ｂにおけるアプリケーションのインストール傾向に対応するグループを特定する（Ｓ４５）。

続いて、予測部１２５は、Ｓ４４において選択された第２端末７Ｂにおけるトラヒック量を、Ｓ４５において特定したグループにおけるトラヒックの変化量、及びトラヒック履歴情報における当該第２端末７Ｂのトラヒック量に基づいて予測する（Ｓ４６）。
続いて、予測部１２５は、予測した第２端末７Ｂのトラヒック量を、Ｓ３２において選択された第２ノードのトラヒックの予測量に加算する（Ｓ４７）。

続いて、予測部１２５は、Ｓ３２において選択された第２ノードにおいて、全ての第２端末７Ｂのトラヒック量を予測したか否かを判定する（Ｓ４８）。予測部１２５は、全ての第２端末７Ｂのトラヒック量を予測したと判定した場合（判定がＹＥＳの場合）、Ｓ４９に処理を移し、全ての第２端末７Ｂのトラヒック量を予測していないと判定した場合（判定がＮＯの場合）、Ｓ４４に処理を移す。

続いて、予測部１２５は、全ての第２ノードのトラヒック量を予測したか否かを判定する（Ｓ４９）。予測部１２５は、全ての第２ノードのトラヒック量を予測したと判定した場合（判定がＹＥＳの場合）、本フローチャートに係る処理を終了する。また、予測部１２５は、全ての第２ノードのトラヒック量を予測していないと判定した場合（判定がＮＯの場合）、Ｓ４３に処理を移す。

［第２の実施形態における効果］
以上のとおり、第２の実施形態に係る予測装置１は、複数の第１端末７Ａを複数のグループのいずれかに分類し、第２端末７Ｂにおけるアプリケーションのインストール傾向に対応するグループを特定し、第２端末７Ｂにおける将来のトラヒック量を、当該第２端末７Ｂにおけるアプリケーションのインストール傾向に対応するグループにおけるトラヒックの変化量、及びトラヒック履歴情報における第２端末７Ｂのトラヒック量に基づいて予測する。

グループの数は、第１端末７Ａの台数よりも少ないことから、予測装置１は、複数の第２端末７Ｂのそれぞれについて、当該第２端末７Ｂのアプリケーションのインストール傾向に対応するグループを特定する処理を、当該第２端末７Ｂのアプリケーションのインストール傾向に対応する第１端末７Ａを特定する処理に比べて低負荷で行うことができる。よって、予測装置１は、トラヒックの予測にかかる負荷を軽減することができる。

＜第３の実施形態＞
［端末７に紐づく端末８におけるアプリケーションも管理する］
続いて、第３の実施形態について説明する。図１４は、第３の実施形態に係る予測装置１及び当該予測装置１の外部環境を示す図である。

第３の実施形態に係る端末７は、例えば、ＷｉＦｉのアクセスポイントとして動作可能であり、図１４に示すように、１台以上の端末８が、端末７及びケーブルテレビ網を介してインターネット上のサーバと通信可能である。ここで、端末８は、例えばスマートフォン等の携帯端末であり、端末７が設置されている家庭における家族がそれぞれ個人的に使用する端末である。端末８は、端末７と同様にアプリケーションサーバ３からアプリケーションをダウンロードすることができる。

ここで、端末７は、例えばＷｉＦｉのアクセスポイントであることから、家庭において共用されることが多い。このため、端末７に対するアプリケーションのインストール傾向やトラヒック量の傾向は、家族構成によって大きく異なる。そこで、本実施形態において予測装置１は、第２端末７Ｂと類似する第１端末７Ａを特定する際に、家族が個人的に使用する端末８におけるアプリケーションのインストール傾向も考慮して、第２端末７Ｂと家族構成も類似する第１端末７Ａを特定する。

第３の実施形態において、ユーザアプリ情報ＤＢ１１１は、インストール情報において、端末７に対応するユーザＩＤに、当該端末７を介して通信を行う端末８にインストールされているアプリケーションＩＤをさらに関連付けて記憶する。

ユーザＩＤは、例えば、一のケーブルテレビの契約に対して通信事業者から一つ付与されるＩＤであり、端末７と、端末８とで共用される。このため、端末７と、当該端末７を介して通信を行う端末８とのそれぞれが、アプリケーションサーバ３に対してアプリケーションのダウンロードのリクエストを送信する際に、当該リクエストには同一のユーザＩＤが含まれている。

これにより、アプリケーションサーバ３のダウンロード履歴ＤＢ３１１に格納されるダウンロード履歴情報では、端末７に対応するユーザＩＤに、当該端末７を介して通信を行う端末８にインストールされているアプリケーションＩＤが関連付けて記憶されている。よって、ダウンロード履歴情報に基づく情報であるインストール情報も、端末７に対応するユーザＩＤに、当該端末７を介して通信を行う端末８にインストールされているアプリケーションＩＤが関連付けて記憶されている。

第３の実施形態に係る類似端末特定部１２４は、第１の実施形態と同様に、ユーザアプリ情報ＤＢ１１１に格納されているインストール情報を参照し、複数の第１端末７Ａのアプリケーションのインストール情報に基づいて、第２端末７Ｂと傾向が類似する第１端末７Ａを特定する。インストール情報では、端末７に対応するユーザＩＤに、端末７にインストールされたアプリケーションの他に、当該端末７を介して通信を行う端末８にインストールされたアプリケーションＩＤも関連付けて記憶されていることから、類似端末特定部１２４は、端末７及び端末８におけるアプリケーションのインストール傾向に基づいて、第１端末７Ａを特定する。

［第３の実施形態における効果］
以上、第３の実施形態の予測装置１は、端末７と、当該端末７を介して通信を行う端末８とにおけるアプリケーションのインストール傾向に基づいて、第２端末７Ｂと類似する第１端末７Ａを特定することから、家族構成も第２端末７Ｂと類似すると推測される第１端末７Ａを特定することができる。このようにすることで、第２端末７Ｂにおける将来のトラヒック量をより高精度に予測することができる。

以上、本発明を実施の形態を用いて説明したが、本発明の技術的範囲は上記実施の形態に記載の範囲には限定されない。上記実施の形態に、多様な変更又は改良を加えることが可能であることが当業者に明らかである。特に、装置の分散・統合の具体的な実施形態は以上に図示するものに限られず、その全部又は一部について、種々の付加等に応じて、又は、機能負荷に応じて、任意の単位で機能的又は物理的に分散・統合して構成することができる。

また、上記実施の形態では、予測装置１は、ケーブルテレビ網におけるノードのトラヒック量を予測したが、これに限らず、ケーブルテレビ網とは異なる通信ネットワークにおけるノードのトラヒック量を予測してもよい。例えば、予測装置１は、トラヒックが通過するポイントである、１台のＬ３スイッチ等の通信機器の配下の端末を、一のノードに接続されている端末とし、当該ノードのトラヒック量を予測してもよい。

また、第３の実施形態では、ユーザＩＤが、端末７と端末８とで共用されるものとして説明を行ったが、これに限らず、ユーザＩＤが、端末７と端末８とで異なるものであってもよい。この場合、例えば、ユーザＤＢ１１４に、端末７のユーザＩＤと、当該端末７を介して通信を行う端末８のユーザＩＤとを関連付けたＩＤ連携情報を記憶しておいてもよい。そして、アプリケーションのインストール情報において、ＩＤ連携情報に基づいて、端末７に対応するユーザＩＤに、当該端末７を介して通信を行う端末８にインストールされているアプリケーションのアプリケーションＩＤをさらに関連付けてもよい。

１・・・予測装置、１１・・・記憶部、１１１・・・ユーザアプリ情報ＤＢ、１１２・・・トラヒック履歴ＤＢ、１１３・・・アプリ別トラヒックＤＢ、１１４・・・ユーザＤＢ、１２・・・制御部、１２１・・・インストール情報取得部、１２２・・・トラヒック量測定部、１２３・・・変化量特定部、１２４・・・類似端末特定部、１２５・・・予測部、１２６・・・帯域制御部、１２７・・・分類部、２・・・ＣＭＴＳ、３・・・アプリケーションサーバ、３１・・・記憶部、３１１・・・ダウンロード履歴ＤＢ、３２・・・制御部、３２１・・・ダウンロード受付部、３２２・・・アプリケーション送信部、３２３・・・履歴管理部、３２４・・・履歴情報送信部、４・・・光伝送装置、５・・・ノードアンプ、６・・・アンプ、７・・・端末、７Ａ・・・第１端末、７Ｂ・・・第２端末、８・・・端末、Ｎ・・・ネットワーク

Claims (8)

1. 通信ネットワークのノードに接続されている端末のトラヒック量を示すトラヒック履歴情報を記憶する履歴情報記憶部と、
   複数の第１端末におけるトラヒック履歴情報に記憶されているトラヒック量の変化量を特定する変化量特定部と、
   前記端末の識別情報と、当該端末にインストールされているアプリケーションの識別情報とを関連付けてインストール情報として記憶するインストール情報記憶部と、
   前記インストール情報記憶部を参照し、前記複数の第１端末のアプリケーションのインストール情報に基づいて、第２端末と傾向が類似する第１端末を特定する類似端末特定部と、
   前記第２端末におけるトラヒック量を、特定した前記第１端末における前記変化量及び前記トラヒック履歴情報における前記第２端末のトラヒック量に基づいて予測する予測部と、
   を備える予測装置。
2. 前記類似端末特定部は、前記複数の第１端末のアプリケーションのインストール情報と、前記トラヒック履歴情報とに基づいて、前記第２端末と傾向が類似する第１端末を特定する、
   請求項１に記載の予測装置。
3. 前記予測部は、所定のノードに接続されている複数の前記第２端末におけるトラヒック量を予測することで、当該ノードにおけるトラヒック量を予測する、
   請求項１又は２に記載の予測装置。
4. 前記予測部において予測された前記ノードにおける前記トラヒック量が所定の閾値を超えたことに応じて、当該ノードにおける帯域制御を行う帯域制御部をさらに備える、
   請求項３に記載の予測装置。
5. 前記予測部は、アプリケーションに係る新たなサービスの提供の対象となる前記第２端末におけるトラヒック量を予測することで、当該アプリケーションに対応するアプリケーションダウンロードサーバ、及びアプリケーション実行サーバの少なくともいずれかにおける負荷量の増分を予測する、
   請求項１から４のいずれか１項に記載の予測装置。
6. 前記変化量特定部は、第１ノードにおける所定のアプリケーションのリリース後に、当該第１ノードを介して通信する前記複数の第１端末における前記変化量を特定し、
   前記予測部は、前記第１ノードとは異なる第２ノードにおける前記所定のアプリケーションのリリース前に、当該第２ノードを介して通信する前記第２端末におけるトラヒック量を予測する、
   請求項１から５のいずれか１項に記載の予測装置。
7. それぞれが異なるアプリケーションのインストール傾向に対応する複数のグループのいずれかに前記複数の第１端末を分類する分類部をさらに備え、
   前記類似端末特定部は、前記第２端末におけるアプリケーションのインストール傾向に対応するグループを特定し、
   前記予測部は、前記第２端末におけるトラヒック量を、特定した前記グループにおけるトラヒックの変化量及び前記トラヒック履歴情報における前記第２端末のトラヒック量に基づいて予測する、
   請求項１から６のいずれか１項に記載の予測装置。
8. 通信ネットワークのノードに接続されている端末のトラヒック量を示すトラヒック履歴情報を参照し、複数の第１端末におけるトラヒックの変化量を特定するステップと、
   端末の識別情報と、当該端末にインストールされているアプリケーションの識別情報とを関連付けてインストール情報として記憶するインストール情報記憶部を参照し、前記複数の第１端末のアプリケーションのインストール情報に基づいて、第２端末と傾向が類似する第１端末を特定するステップと、
   前記第２端末におけるトラヒック量を、特定した前記第１端末におけるトラヒックの変化量及び前記トラヒック履歴情報における前記第２端末のトラヒック量に基づいて予測するステップと、
   を備える予測方法。
   

Images