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

Abstract

【課題】将来のトラヒック量を高精度に予測する。【解決手段】予測装置１は、通信ネットワークのノードのトラヒック量を示すトラヒック履歴情報を記憶する記憶部１１と、所定のアプリケーションに対応するトラヒック量を示す個別トラヒック量を特定するトラヒック量特定部１２３と、前記ノードに接続されている複数の端末のうち、前記所定のアプリケーションがインストールされた端末の台数を特定する台数特定部１２４と、特定した前記端末の台数と、前記個別トラヒック量と、前記ノードのトラヒック量とに基づいて、前記ノードにおけるトラヒック量を予測する予測部１２５とを備える。【選択図】図３

Description

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

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

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

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

ところで、近年、ＯＴＴ（Over The Top）事業者が提供するＶＯＤ（Video On Demand）サービスや、オンラインゲーム、ソーシャルゲーム、ウイルス対策アプリケーションといった、インターネットを利用するサービスによるトラヒックの急激な増加が問題となっている。従来、これらのサービスはパソコンに対して提供されていたが、近年は、アプリケーションの実行環境を備えたＴＶ受信端末や、携帯端末に対しても提供されており、ケーブルテレビのネットワーク上においてもこのトラヒックの急激な増加が問題となっている。

ＨＦＣでは、一部のユーザがトラヒックの増加の原因となる上述のサービスを利用することにより、当該ユーザの端末の接続先のノードにおけるトラヒックが増加して回線が輻輳する。すると、当該ノード配下の他のユーザも快適にネットワークを利用することができないという問題が発生する。

これに対し、従来のネットワークの設計・制御方式では、実際に測定したトラヒック量に基づいてノードの分割やトラヒックの制御を行っている。そのため、新規アプリケーションのリリース時等も、実際に当該アプリケーションの利用が拡大し、トラヒックが増加してから、初めてネットワーク輻輳への対策を取るべきノードがわかるため、輻輳の発生を事前に防ぐことが難しいという問題がある。

このような問題に対して、個々のユーザのトラヒックの増加傾向に基づいて、将来のトラヒック量を予測することが考えられる。しかしながら、ケーブルテレビを利用するユーザは、数十万〜数百万存在することから、これらのユーザに対して、個々のトラヒック増加傾向を予測することは、量的に難しいという問題がある。

本発明はこれらの点に鑑みてなされたものであり、将来のトラヒック量を高精度に予測することができる予測装置及び予測方法を提供することを目的とする。

本発明の第１の態様に係る予測装置は、通信ネットワークのノードのトラヒック量を記憶する記憶部と、所定のアプリケーションに対応するトラヒック量を示す個別トラヒック量を特定するトラヒック量特定部と、前記ノードに接続されている複数の端末のうち、前記所定のアプリケーションがインストールされた端末の台数を特定する台数特定部と、特定した前記端末の台数と、前記個別トラヒック量と、前記ノードのトラヒック量とに基づいて、前記ノードにおけるトラヒック量を予測する予測部とを備える。

前記記憶部は、前記ノードに接続されている複数の端末それぞれのトラヒック量を示すトラヒック履歴情報を記憶し、前記予測部は、特定した前記端末の台数と、前記個別トラヒック量と、前記複数の端末それぞれの前記トラヒック履歴情報が示すトラヒック量とに基づいて、前記ノードにおけるトラヒック量を予測してもよい。

前記予測装置は、前記複数の端末それぞれのトラヒック量を測定するトラヒック測定部と、前記所定のアプリケーションのインストール、アンインストール及びバージョンアップの少なくともいずれかが行われ、インストール状態が変化した所定端末を特定する端末特定部とをさらに備え、前記トラヒック量特定部は、前記インストール状態が変化してから所定期間が経過するまでに測定された前記所定端末のトラヒック量と、前記インストール状態が変化する前の前記所定期間において測定された前記所定端末のトラヒック量とに基づいて、前記所定期間における前記個別トラヒック量を特定してもよい。

前記予測装置は、前記端末における通信の監視を行い、前記端末特定部は、端末から送信されたリクエストに含まれる通信先のアドレスが前記所定のアプリケーションを提供するサーバのアドレスである場合に、当該端末において、前記所定のアプリケーションがインストールされたと特定してもよい。

前記トラヒック量特定部は、前記所定のアプリケーションにて発生すると予測されるトラヒック予測量を前記個別トラヒック量として受け付けることで、前記個別トラヒック量を特定してもよい。

前記記憶部は、前記端末が接続されているノードの識別情報と、前記端末のユーザのユーザＩＤとを関連付けてノード情報として記憶し、前記台数特定部は、前記所定のアプリケーションを提供するサーバから、前記所定のアプリケーションを新たにダウンロードした端末に対応するユーザＩＤを取得し、前記ノード情報及び取得したユーザＩＤに基づいて、前記ノードにおいて前記所定のアプリケーションをインストールした端末の台数を特定してもよい。

前記予測装置は、前記予測部において予測された前記ノードにおける前記トラヒック量が所定の閾値を超えたことに応じて、当該ノードにおける帯域制御を行う帯域制御部をさらに備えてもよい。
前記予測部は、予測された前記トラヒック量から、前記所定のアプリケーションに対応するアプリケーション実行サーバにおける負荷量の増分を予測してもよい。

本発明の第２の態様に係る予測方法は、所定のアプリケーションに対応するトラヒック量を示す個別トラヒック量を特定するステップと、通信ネットワークのノードに接続されている複数の端末のうち、前記所定のアプリケーションがインストールされた端末の台数を特定するステップと、特定した前記端末の台数と、前記個別トラヒック量と、前記ノードのトラヒック量とに基づいて、前記ノードにおけるトラヒック量を予測するステップと、を備える。

本発明によれば、将来のトラヒック量を高精度に予測することができるという効果を奏する。

第１の実施形態に係る予測装置及び当該予測装置の外部環境を示す図である。 第１の実施形態に係るアプリケーションサーバの機能構成図である。 第１の実施形態に係る予測装置の機能構成図である。 インストール情報の一例を示す図である。 トラヒック履歴情報の一例を示す図である。 個別トラヒック情報の一例を示す図である。 ノード情報の一例を示す図である。 第１実施形態に係る端末がアプリケーションサーバからアプリケーションをダウンロードする際のシーケンス図である。 第１実施形態に係る予測装置がアプリケーションサーバからダウンロード履歴情報を取得する際のシーケンス図である。 第１実施形態に係る予測装置が所定のアプリケーションに対応するトラヒック増加量を特定する際のシーケンス図である。 第１実施形態に係る予測装置がケーブルテレビ網における全ノードのそれぞれについて、トラヒック量を予測する際のフローチャートである。 第１の実施形態に係る予測装置及び当該予測装置の外部環境を示す図である。

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

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

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

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

端末７は、ケーブルテレビを利用するユーザの住宅に設けられているＴＶ受信端末であり、例えば、セットトップボックスである。本実施形態において、端末７は、アプリケーションの実行環境を備えている。端末７は、ユーザの操作に応じて、ケーブルテレビ網及びネットワークＮを介して、アプリケーションサーバ３からアプリケーションをダウンロードし、インストールすることができる。

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

これに対して、予測装置１は、アプリケーションサーバ３において新たにリリースされるアプリケーションが端末７にインストールされることによって、当該端末７で増加するトラヒック量を予測する。そして、予測装置１は、当該トラヒック量に基づいて、各ノードにおけるトラヒック量を予測する。これにより、センター局では、各ネットワークの輻輳が発生する前に、帯域制御やノードの追加といった対策をとることができる。以下、予測装置１及びアプリケーションサーバ３の機能構成について説明する。

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

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

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

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

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

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

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

履歴情報送信部３２４は、予測装置１からダウンロード履歴情報の取得リクエストを受け付ける。この取得リクエストには、現在時刻から第１期間（例えば、１月）内にリリースされた所定のアプリケーションのアプリケーションＩＤが含まれている。ここで、第１期間内にリリースされた所定のアプリケーションには、新規にリリースされたアプリケーションに限らず、既にリリースされているアプリケーションのうち、新たなバージョンでリリースされたアプリケーションも含まれるものとする。履歴情報送信部３２４は、取得リクエストを受け付けると、ダウンロード履歴ＤＢ３１１に格納されているダウンロード履歴情報のうち、取得リクエストに含まれるアプリケーションＩＤに対応し、現在時刻から所定期間（例えば、１週間）内に格納されたダウンロード履歴情報を抽出して予測装置１に送信する。

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

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

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

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

端末特定部１２１は、所定のアプリケーションのインストール及びバージョンアップの少なくともいずれかが行われ、インストール状態が変化した端末７を特定する。具体的には、端末特定部１２１は、アプリケーションサーバ３から、所定のアプリケーションがインストールされた端末７に対応するダウンロード履歴情報を取得することで、所定のアプリケーションがインストールされた端末７を特定する。

より具体的には、端末特定部１２１は、第１期間内にリリースされた所定のアプリケーションに対応するダウンロード履歴情報の取得を要求する取得リクエストをアプリケーションサーバ３に送信し、アプリケーションサーバ３からダウンロード履歴情報を受信する。ここで、取得リクエストには、所定のアプリケーションを特定するためのアプリケーションＩＤが含まれている。なお、取得リクエストには、複数のアプリケーションＩＤが含まれていてもよい。端末特定部１２１は、受信したダウンロード履歴情報をインストール情報としてユーザアプリ情報ＤＢ１１１に記憶させる。

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

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

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

トラヒック量特定部１２３は、所定のアプリケーションに対応するトラヒック量を示す個別トラヒック量を特定する。個別トラヒック量は、端末７が所定のアプリケーションを実行した結果、端末７において所定期間（例えば、１週間）で発生するトラヒック量である。個別トラヒック量は、端末７において所定のアプリケーションをインストールした後に増加したトラヒック量を算出することで求められる。

トラヒック量特定部１２３は、所定のアプリケーションのインストール状態が変化してから所定期間が経過するまでに測定された端末７のトラヒック量と、所定のアプリケーションのインストール状態が変化する前の所定期間において測定された端末７のトラヒック量とに基づいて、所定期間における個別トラヒック量を特定する。

具体的には、まずトラヒック量特定部１２３は、ユーザアプリ情報ＤＢ１１１に格納されているインストール情報を参照し、現在時刻から第２期間（例えば、２週間）以前に所定のアプリケーションをインストールした端末７のユーザＩＤを特定する。例えば、トラヒック量特定部１２３は、現在時刻よりも第２期間以前であって、第２期間から第３期間（例えば、１週間）以内に所定のアプリケーションをインストールした端末７のユーザＩＤを特定する。このようにすることで、所定のアプリケーションのインストール後に増加したトラヒック量を精度よく特定することができる。なお、トラヒック量特定部１２３は、所定のアプリケーションがインストールされてから所定期間が経過するまでに測定された端末７のトラヒック量を算出することから、第２期間は、所定期間よりも長いものとする。

続いて、トラヒック量特定部１２３は、トラヒック履歴ＤＢ１１２に格納されているトラヒック履歴情報から、特定したユーザＩＤに対応する端末７に対応するトラヒック履歴情報を抽出する。そして、トラヒック量特定部１２３は、抽出したトラヒック履歴情報を参照し、所定のアプリケーションがインストールされてから所定期間が経過するまでに測定された端末７のトラヒック量と、所定のアプリケーションがインストールされる前の所定期間において測定された端末７のトラヒック量との、各時間帯のそれぞれにおける差分を算出することで個別トラヒック量を特定する。トラヒック量特定部１２３は、所定のアプリケーションのアプリケーションＩＤと、時間帯を示す時間帯情報と、個別トラヒック量とを関連付けて個別トラヒック情報としてアプリ別トラヒックＤＢ１１３に格納する。

図６は、個別トラヒック情報の一例を示す図である。個別トラヒック情報は、図６に示すように、所定のアプリケーションのアプリケーションＩＤと、時間帯を示す時間帯情報と、個別トラヒック量とが関連付けられている。

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

台数特定部１２４は、ノードに接続されている複数の端末７のうち、所定のアプリケーションが新たにインストールされた端末７の台数を特定する。具体的には、台数特定部１２４は、ユーザＤＢ１１４に格納されているノード情報と、ユーザアプリ情報ＤＢ１１１に格納されているインストール情報とを参照し、複数のノードのそれぞれについて、第３期間（例えば、１週間）以内に所定のアプリケーションをインストールした端末７の台数を特定する。

ここで、ノード情報は、複数のノードそれぞれの配下の端末７のユーザＩＤを管理する情報である。図７は、ノード情報の一例を示す図である。図７に示すように、ノード情報は、ノード（ノードアンプ５）を識別する識別情報としてのノードＩＤと、端末７のユーザのユーザＩＤとを関連付けた情報である。

より具体的には、台数特定部１２４は、アプリケーションサーバ３から取得したダウンロード履歴情報を参照し、所定のアプリケーションを新たにダウンロードした端末に対応するユーザＩＤを特定する。そして、台数特定部１２４は、ノード情報及び特定されたユーザＩＤに基づいて、複数のノードのそれぞれにおいて所定のアプリケーションを新たにインストールした端末７の台数を特定する。

予測部１２５は、台数特定部１２４が特定した端末７の台数と、個別トラヒック量と、ノードのトラヒック量とに基づいて、複数のノードのそれぞれにおけるトラヒック量を予測する。具体的には、予測部１２５は、複数のノードのそれぞれについて以下の処理を行うことで、複数のノードのそれぞれにおけるトラヒック量を予測する。

まず、予測部１２５は、特定した端末７の台数に、各時間帯に対応する個別トラヒック量を乗算することで、各時間帯のそれぞれにおける所定のアプリケーションに起因したトラヒックの増加量を算出する。また、予測部１２５は、複数の端末７のそれぞれのトラヒック履歴情報が示す複数の端末７のトラヒック量及びノード情報に基づいて、ノードにおける、各時間帯のトラヒック量を算出する。ここで、予測部１２５は、トラヒック履歴情報が示す複数の端末７のトラヒック量及びノード情報に基づいて、ノードにおける各時間帯のトラヒック量を算出したが、これに限らない。例えば、トラヒック量測定部１２２が、各ノードの各時間帯のトラヒック量を測定し、測定したトラヒック量をノードＩＤと関連付けて記憶部１１に記憶させてもよい。そして、予測部１２５は、記憶部１１を参照し、各ノードそれぞれにおける、各時間帯のトラヒック量を取得してもよい。続いて、予測部１２５は、ノードごとに算出した各時間帯のトラヒック量に、所定のアプリケーションに起因した各時間帯のトラヒックの増加量を加算することで、各時間帯におけるトラヒック量を予測する。

また、予測部１２５は、予測したトラヒック量から、所定のアプリケーションに対応するアプリケーション実行サーバにおける負荷量の増分を予測してもよい。例えば、予測部１２５は、予測したトラヒック量に基づいて、アプリケーション実行サーバにおける負荷量及び当該負荷量が最大となる時間帯を特定する。このようにすることで、サーバの管理者は、サーバにかかる負荷を事前に予測し、サービスが安定して行われるように対処することができる。

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

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

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

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

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

まず、予測装置１の端末特定部１２１は、アプリケーションサーバ３に、第１期間内にリリースされた所定のアプリケーションに対応するダウンロード履歴情報の取得を要求する取得リクエストを送信する。

アプリケーションサーバ３の履歴情報送信部３２４は、予測装置１からダウンロード履歴情報の取得リクエストを受信すると、ダウンロード履歴ＤＢ３１１に格納されているダウンロード履歴情報のうち、取得リクエストに含まれるアプリケーションＩＤに対応し、現在時刻から第１期間内に格納されたダウンロード履歴情報を抽出する（Ｓ２０）。続いて、アプリケーションサーバ３の履歴情報送信部３２４は、抽出したダウンロード履歴情報を予測装置１に送信する。

［所定のアプリケーションに対応するトラヒック増加量の特定に係るフローチャート］
続いて、予測装置１が、所定のアプリケーションに対応するトラヒック増加量を特定する際の処理の流れについて説明する。図１０は、第１実施形態に係る予測装置１が所定のアプリケーションに対応するトラヒック増加量を特定する際のフローチャートである。

まず、トラヒック量特定部１２３は、第１期間内にリリースされた所定のアプリケーションを特定する（Ｓ３１）。
続いて、トラヒック量特定部１２３は、特定された所定のアプリケーションが複数ある場合に、一つの所定のアプリケーションを選択する（Ｓ３２）。

続いて、トラヒック量特定部１２３は、第２期間以前にインストールした端末７を特定する（Ｓ３３）。ここで、トラヒック量特定部１２３は、現在時刻よりも第２期間以前であって、第２期間から第３期間以内に所定のアプリケーションをインストールした端末７のユーザＩＤを特定する。

続いて、トラヒック量特定部１２３は、特定したユーザＩＤに対応する端末７のトラヒック量の変化量を算出する（Ｓ３４）。トラヒック量特定部１２３は、所定のアプリケーションがインストールされてから所定期間が経過するまでに測定された端末７のトラヒック量から、所定のアプリケーションがインストールされる前の所定期間において測定された端末７のトラヒック量を減算することにより、所定期間におけるトラヒックの変化量（個別トラヒック量）を特定する。ここで、個別トラヒック量は、時間帯別に算出される。トラヒック量特定部１２３は、特定したユーザＩＤが複数存在する場合には、複数のユーザＩＤのそれぞれに対応する端末７の個別トラヒック量を算出する。

続いて、トラヒック量特定部１２３は、時間帯別に、複数の端末７において算出されたトラヒックの変化量の平均を算出する（Ｓ３５）。
続いて、トラヒック量特定部１２３は、全ての所定のアプリケーションのトラヒックの変化量を算出したか否かを判定する（Ｓ３６）。トラヒック量特定部１２３は、全ての所定のアプリケーションのトラヒックの変化量を算出したと判定した場合（判定がＹＥＳの場合）、本フローチャートの処理を終了する。また、トラヒック量特定部１２３は、全ての所定のアプリケーションのトラヒックの変化量を算出していないと判定した場合（判定がＮＯの場合）、他の所定のアプリケーションを選択するため、Ｓ３２に処理を移す。

［全ノードのトラヒック量の予測に係るフローチャート］
続いて、予測装置１が、ケーブルテレビ網における全ノードのそれぞれについてトラヒック量を予測する際の処理の流れについて説明する。図１１は、第１実施形態に係る予測装置１がケーブルテレビ網における全ノードのそれぞれについてトラヒック量を予測する際のフローチャートである。ここで、所定のアプリケーションは１以上存在しているものとする。

まず、予測部１２５は、ケーブルテレビ網の複数のノードのうち、一のノードを選択する（Ｓ４１）。
続いて、予測部１２５は、各ノードのトラヒック量の予測において、未だ選択されていない所定のアプリケーションから、一の所定のアプリケーションを選択する（Ｓ４２）。

続いて、台数特定部１２４は、アプリケーションサーバ３から取得したダウンロード履歴情報を参照し、選択された所定のアプリケーションを現在時刻から第３期間以内にダウンロードした端末７の台数を特定する（Ｓ４３）。

続いて、予測部１２５は、各時間帯の個別トラヒック量に、特定された端末７の台数を乗算して、選択された所定のアプリケーションに対応する各時間帯のトラヒックの増加予測量を算出する（Ｓ４４）。

続いて、予測部１２５は、各時間帯の増加予測量の総量に、Ｓ４４において算出された増加予測量を加算する（Ｓ４５）。ここで、各時間帯の増加予測量の総量とは、複数の所定のアプリケーションのそれぞれに対応する各時間帯の増加予測量を合計したトラヒック量である。

続いて、予測部１２５は、全ての所定のアプリケーションで増加予測量を算出したか否かを判定する（Ｓ４６）。予測部１２５は、全ての所定のアプリケーションで増加予測量を算出したと判定した場合（判定がＹＥＳの場合）、Ｓ４７に処理を移し、算出していないと判定した場合（判定がＮＯの場合）、Ｓ４２に処理を移す。

続いて、予測部１２５は、複数の端末７のそれぞれのトラヒック履歴情報が示すトラヒック量及びノード情報に基づいて、ノードにおける、各時間帯の従来のトラヒックの総量を算出する（Ｓ４７）。
続いて、予測部１２５は、各時間帯における従来のトラヒックの総量に、各時間帯における増加予測量の総量を加算する（Ｓ４８）。これにより、ノードにおける各時間帯のトラヒックの予測量が算出される。

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

［第１の実施形態における効果］
以上のとおり、第１の実施形態に係る予測装置１は、所定のアプリケーションを新たにインストールした端末７の台数と、当該所定のアプリケーションの個別トラヒック量とに基づいて、当該端末７における所定のアプリケーションのインストールに伴うトラヒック増加量を考慮したトラヒック量を高精度に予測することができる。

なお、本実施例において、予測装置１は、アプリケーションがインストール又はバージョンアップされた場合にトラヒック量を予測したが、これに限定されるものではない。例えば、予測装置１は、アプリケーションがアンインストールされた場合に、トラヒック量を予測してもよい。この場合、例えば、端末７においてアプリケーションがインストールされた場合に、端末７が、アンインストールを示す情報をアプリケーションサーバ３に送信し、アプリケーションサーバ３において、アンインストール情報として管理する。そして、予測装置１は、アンインストール情報を取得し、当該アンインストール情報に基づいてトラヒック量を予測する。このようにすることで、既にインストール済みのアプリケーションがアンインストールされ、当該アプリケーションが利用するトラヒックが減少する場合も、予測装置１は、トラヒックの変化を事前に予測することが可能となる。

＜第２の実施形態＞
［所定のアプリケーションのトラヒック予測量を受け付ける］
続いて、第２の実施形態について説明する。第１実施形態では、所定のアプリケーションに対応する個別トラヒック量を、所定アプリケーションのインストール前のトラヒック量とインストール後のトラヒック量との差分を算出することにより特定した。

このようにして個別トラヒック量を特定する場合、いずれかの端末７において所定のアプリケーションがインストールされている必要がある。このため、例えば、多くの端末７が一斉に所定のアプリケーションをインストールした場合、所定のアプリケーションに対応する個別トラヒック量を特定する前にノードのトラヒック量が急激に増加する場合がある。

そこで、第２の実施形態では、トラヒック量特定部１２３は、所定のアプリケーションにて発生すると予測されるトラヒック予測量を個別トラヒック量として受け付けることで、個別トラヒック量を特定する。例えば、トラヒック量特定部１２３は、所定のアプリケーションのプロバイダから、所定のアプリケーションがリリースされる前に、各時間帯における個別トラヒック量の予測情報を受信することによって、所定のアプリケーションの個別トラヒック量を受け付ける。

［第２の実施形態における効果］
以上、第２の実施形態の予測装置１は、所定のアプリケーションがリリースされる前に所定のアプリケーションのトラヒック予測量を個別トラヒック量として受け付ける。このようにすることで、所定のアプリケーションのリリース直後に、当該所定のアプリケーションが多くの端末７にインストールされた場合であっても、トラヒック量を精度よく予測することができ、ケーブルテレビの運営者は、帯域制御やノードの増設等の対策を施すことができる。

＜第３の実施形態＞
［端末からのリクエストを解析してアプリケーションのインストールを特定する］
続いて、第３の実施形態について説明する。図１２は、第３の実施形態に係る予測装置１及び当該予測装置１の外部環境を示す図である。

第３の実施形態に係る端末７は、例えば、ＷｉＦｉのアクセスポイントとして動作可能であり、図１２に示すように、１台以上の端末８が端末７及びケーブルテレビ網を介してインターネット上のサーバとの通信が可能である。ここで、端末８は、例えばスマートフォンであり、サードパーティが運営するアプリケーションサーバ３からアプリケーションをダウンロードすることができる。この場合、サードパーティの運営方針によっては、予測装置１がダウンロード履歴情報をアプリケーションサーバ３から取得できないことがある。

そこで、第３の実施形態では、予測装置１が、端末７及び端末８における、ケーブルテレビ網を介した通信の監視を行い、端末７及び端末８において所定のアプリケーションがインストールされたことを特定する。そして、予測装置１が、所定のアプリケーションがインストールされた端末７及び端末８の台数に基づいてノードのトラヒック量を予測する。第３の実施形態は、これらの点で、第１の実施形態と異なり、その他の点では第１の実施形態と同じである。

第３の実施形態において、端末特定部１２１は、端末７又は端末８から送信されたリクエストに含まれる通信先のアドレスが所定のアプリケーションを提供するサーバのアドレスである場合に、当該端末において、所定のアプリケーションがインストールされたと特定する。

具体的には、記憶部１１に、アプリケーションの提供を行う主要なサイトにおける所定のアプリケーションのダウンロード先のＵＲＬを、当該アプリケーションのアプリケーションＩＤと関連付けてＵＲＬ情報として記憶しておく。端末特定部１２１は、端末７又は端末８から送信されたリクエストを監視し、当該リクエストに含まれる通信先のアドレスが、ＵＲＬ情報に含まれている場合に、当該端末において、所定のアプリケーションがインストールされたと特定する。

端末特定部１２１は、特定した日時を、所定のアプリケーションが端末７又は端末８にインストールされた日時を示すインストール日時とする。そして、端末特定部１２１は、例えば、リクエストを送信した端末７の識別情報（例えば、ＩＰアドレスやユーザＩＤ）と、所定のアプリケーションのアプリケーションＩＤと、インストール日時とを関連付けてインストール情報としてユーザアプリ情報ＤＢ１１１に記憶させる。

台数特定部１２４は、ノードに接続されている複数の端末７及び端末８のうち、所定のアプリケーションが新たにインストールされた端末７及び端末８の台数を特定する。具体的には、台数特定部１２４は、ユーザＤＢ１１４に格納されているノード情報と、ユーザアプリ情報ＤＢ１１１に格納されているインストール情報とを参照し、複数のノードのそれぞれについて、第３期間以内に所定のアプリケーションをインストールした端末７及び端末８の台数を特定する。
予測部１２５は、台数特定部１２４が特定した端末７及び端末８の台数と、個別トラヒック量と、ノードのトラヒック量とに基づいて、複数のノードのそれぞれにおけるトラヒック量を予測する。

［第３の実施形態における効果］
以上、第３の実施形態の予測装置１は、端末７及び端末８からのリクエストを解析してアプリケーションのインストールを特定するので、アプリケーションサーバ３の運営先がサードパーティ等であり、ダウンロード履歴情報が提供されない場合であっても所定のアプリケーションがインストールされたことを特定することができる。

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

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

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

Claims (9)

1. 通信ネットワークのノードのトラヒック量を記憶する記憶部と、
   所定のアプリケーションに対応するトラヒック量を示す個別トラヒック量を特定するトラヒック量特定部と、
   前記ノードに接続されている複数の端末のうち、前記所定のアプリケーションがインストールされた端末の台数を特定する台数特定部と、
   特定した前記端末の台数と、前記個別トラヒック量と、前記ノードのトラヒック量とに基づいて、前記ノードにおけるトラヒック量を予測する予測部と、
   を備える予測装置。
2. 前記記憶部は、前記ノードに接続されている複数の端末それぞれのトラヒック量を示すトラヒック履歴情報を記憶し、
   前記予測部は、特定した前記端末の台数と、前記個別トラヒック量と、前記複数の端末それぞれの前記トラヒック履歴情報が示すトラヒック量とに基づいて、前記ノードにおけるトラヒック量を予測する、
   請求項１に記載の予測装置。
3. 前記複数の端末それぞれのトラヒック量を測定するトラヒック測定部と、
   前記所定のアプリケーションのインストール、アンインストール及びバージョンアップの少なくともいずれかが行われ、インストール状態が変化した所定端末を特定する端末特定部とをさらに備え、
   前記トラヒック量特定部は、前記インストール状態が変化してから所定期間が経過するまでに測定された前記所定端末のトラヒック量と、前記インストール状態が変化する前の前記所定期間において測定された前記所定端末のトラヒック量とに基づいて、前記所定期間における前記個別トラヒック量を特定する、
   請求項１又は２に記載の予測装置。
4. 前記予測装置は、前記端末における通信の監視を行い、
   前記端末特定部は、端末から送信されたリクエストに含まれる通信先のアドレスが前記所定のアプリケーションを提供するサーバのアドレスである場合に、当該端末において、前記所定のアプリケーションがインストールされたと特定する、
   請求項３に記載の予測装置。
5. 前記トラヒック量特定部は、前記所定のアプリケーションにて発生すると予測されるトラヒック予測量を前記個別トラヒック量として受け付けることで、前記個別トラヒック量を特定する、
   請求項１又は２に記載の予測装置。
6. 前記記憶部は、前記端末が接続されているノードの識別情報と、前記端末のユーザのユーザＩＤとを関連付けてノード情報として記憶し、
   前記台数特定部は、前記所定のアプリケーションを提供するサーバから、前記所定のアプリケーションを新たにダウンロードした端末に対応するユーザＩＤを取得し、前記ノード情報及び取得したユーザＩＤに基づいて、前記ノードにおいて前記所定のアプリケーションをインストールした端末の台数を特定する、
   請求項１から５のいずれか１項に記載の予測装置。
7. 前記予測部において予測された前記ノードにおける前記トラヒック量が所定の閾値を超えたことに応じて、当該ノードにおける帯域制御を行う帯域制御部をさらに備える、
   請求項１から６のいずれか１項に記載の予測装置。
8. 前記予測部は、予測された前記トラヒック量から、前記所定のアプリケーションに対応するアプリケーション実行サーバにおける負荷量の増分を予測する、
   請求項１から７のいずれか１項に記載の予測装置。
9. 所定のアプリケーションに対応するトラヒック量を示す個別トラヒック量を特定するステップと、
   通信ネットワークのノードに接続されている複数の端末のうち、前記所定のアプリケーションがインストールされた端末の台数を特定するステップと、
   特定した前記端末の台数と、前記個別トラヒック量と、前記ノードのトラヒック量とに基づいて、前記ノードにおけるトラヒック量を予測するステップと、
   を備える予測方法。
   

Images