JP6037987B2 - モバイルネットワークシステム - Google Patents

Description

本発明は、モバイルネットワークシステムに関し、特にネットワーク上で発生するバーストトラヒックを検出し、制御する技術に関する。

ネットワーク上を流れるトラヒックを制御する方法としてロードバランスやシェーピング機能がある。これらの技術はスループットが一定以上のユーザに対して一律に抑制したり、特定のアプリケーションを利用しているユーザに対して規制をかける技術が一般的である。これらの手法では事前にユーザやアプリケーションを特定する必要があり、未知のアプリケーションに対して規制を行うことが困難であった。

例えば、特許文献１には、トラヒックをサンプリングすることによってハイレートトラヒックを抽出する技術が開示されている。また、特許文献２には、リアルタイムにパケットを取得し、分析、制御するシステムが開示されているが、異常トラヒックの特定に関する記述がなく、異常と判定する根拠が不明瞭である。

特開２０１２−２３６２９号公報 特開２０１２−１０９９０５号公報

スマートフォンの普及に伴い、スマートフォンやタブレット端末で利用するアプリケーションのうちほとんどのアプリケーションは、従来のオペレータが管理していたモバイルネットワークで配布されるモバイルオペレータの独自ネットワークサービスのアプリケーションとは異なる。そのため、オペレータが管理することができないアプリケーションによる通信がモバイルネットワーク上を流れることになる。オペレータはこのようなトラヒックを制御をすることができず、ネットワーク上でバーストトラヒックを発生させることがある。これらのアプリケーションによって引き起こされるバーストトラヒックはモバイルネットワーク全体に負荷を与え、重大なシステム障害を引き起こす可能性がある。オペレータはバーストトラヒックを規制、制御することを課題として捉えている。

一方、全てのアプリケーションの振る舞いやアップデートのスケジュールをオペレータが把握することは困難である。ネットワーク上のすべての装置からパケットをキャプチャーし、流れているパケットを分析することができれば、世間で使用しているすべてのアプリケーションを分類し制御することも可能であるが、そのようなシステムを構築することは費用対効果が非常に悪いシステムとなってしまう。実際のネットワークに影響を及ぼす可能性があるアプリケーションは全体のアプリケーションの一部であり、それらをアプリケーションをどのように抽出し制御するかが課題である。

このように、アプリケーションによるバーストトラヒックを制御するためにはどのアプリケーションに対していつ制御するかが課題である。すべての装置もしくは装置間にバーストを抑止／制御する装置を置き、常時すべてのアプリケーションを監視していれば制御することも可能であるが、費用対効果の悪いシステムになってしまう。そこで、いかにして、制御するアプリケーションを検出し、必要なときに制御するかが重要になる。

上記の課題を解決するために、本発明では、モバイルネットワークで使用されるアプリケーションの更新状況を監視する端末と、基地局と、アプリケーションによるトラフィックを解析する解析サーバとを含むモバイルネットワークシステムであって、端末は、アップデートが行われる更新アプリケーションの情報を管理する第１管理部と、更新アプリケーションの情報を解析サーバに送信する送信部と、を有し、解析サーバは、更新アプリケーションのアクセス数を管理する第２管理部と、更新アプリケーションのアクセス数に基づいて、更新アプリケーションによるトラフィックがバーストトラフィックであるかを判定する判定部と、判定部により、バーストトラフィックであると判定された更新アプリケーションのトラフィックを制御するように警報を発令する制御部と、を有するモバイルネットワークシステムを提供する。

本発明によれば、アプリケーションによるバーストトラヒックを制御する効率よく制御することが可能となる。

無線線端末がアプリケーションを更新する処理を示すシーケンス図である。 本実施形態におけるシステム構成例である。 アプリケーション更新確認端末の構成を示すブロック図である。 アプリケーション管理テーブルの一例を示す図である。 更新アプリケーション管理テーブルの一例を示す図である。 ＤＰＩ装置の構成を示すブロック図である。 呼処理信号パケットのパケットフォーマット例を示す図である。 ユーザーデータパケットのパケットフォーマット例を示す図である。 アプリケーションテーブルの例を示す図である。 ＤＰＩログの例を示す図である。 解析サーバの構成を示すブロック図である。 更新アプリケーション管理テーブル例を示す図である。 通常アプリケーション管理テーブル例を示す図である。 バーストを判定するフローチャート（１）である。 バーストを判定するフローチャート（２）である。 バーストを判定するフローチャート（３）である。 バーストを判定するフローチャート（４）である。 バーストを判定するフローチャート（５）である。

図２は、本実施例においてバーストトラヒックを検出し、制御するシステムの構成例を示す図である。無線端末１０１はユーザーが使用する端末で、実際モバイルネットワークでサービスを受ける。無線端末１０１は当該無線端末１０１でアプリケーション等を利用してサービスを受ける場合、基地局２０１を通じて、ユーザーデータを送受信するセッションを確立するために呼処理制御装置２０２に接続する。基地局２０１は無線通信／有線通信を切り替え、無線端末１０１と無線で通信するための装置である。呼処理制御装置２０２は無線端末１０１との認証等を行い、ユーザーデータを送受信するためのセッションを確立する装置である。ユーザーデータを送受信するセッションが確立されたのち、ユーザーデータが送受信されるが、インターネット２０４とモバイルネットワークの接続点が、ユーザーデータ制御装置２０３である。ユーザーデータ制御装置２０３でモバイルネットワーク向けのパケットをインターネット向けのパケットへ変換する。分岐装置２０５はモバイルネットワークを流れるパケットをコピーしＤＰＩ（Ｄｅｅｐ Ｐａｃｋｅｔ Ｉｎｓｐｅｃｔｉｏｎ）装置２０７へ転送する装置である。ＤＰＩ装置２０７はモバイルネットワークを流れる、呼処理信号のパケットとユーザーデータのパケットを紐付けることにより、当該ユーザーのスループット等の統計情報を計算する装置である。解析サーバ２０８は、ＤＰＩ装置２０７によって紐付けられたＤＰＩログを解析し、モバイルネットワークのトラヒック量を最適に制御する装置である。解析サーバ２０８によって解析された結果をもとに基地局２０１、呼処理制御装置２０２、ユーザーデータ制御装置２０３、トラヒック制御装置２０９はトラヒックを制御しネットワークを最適な状態にする。トラヒック制御装置２０９はモバイルネットワーク上流れるパケットに対して即時的に遮断、遅延処理を施す等の制御を行う装置である。

また、本実施形態におけるアプリケーション更新確認端末は２０６は、無線端末１０１と類似の機能を有し、無線端末１０１で使用されているアプリケーションの更新情報を収集するとともに、実際に解析サーバによって制御されている結果の妥当性を評価する機能を有する。インターネット２０４に接続されているアプリケーション提供サーバ１０２は無線端末１０１で使用するアプリケーションを蓄積しているサーバで、アプリケーション／ＩＤ管理サーバ１０３は当該アプリケーションのバージョン情報、使用ユーザ数等を管理しているサーバである。アプリケーション提供サーバ１０２ならびにアプリケーション／ＩＤ管理サーバは同一サーバにて運用することも可能である。

無線端末１０１にはユーザーが使用しているアプリケーションが複数実装されている。当該アプリケーションはアプリケーションの機能追加もしくは不具合対処として管理されているバージョンが更新されることがある。無線端末１０１に搭載されているアプリケーションが更新されるとき、通常２通りの方法が考えられる。一つは、ユーザーが自律的にアプリケーションを更新する場合、もう一つは、アプリケーションを管理しているサーバから当該無線端末１０１に対してアプリケーションの更新を通知し、その後アプリケーションが自律的に更新を行うかもしくは一つ目の方法と同様ユーザーが自律的に行う方法である。

図２に示すシステムにおいて、基地局２０１に具備されたアプリケーション更新確認端末２０６によってにおいてアプリケーションの更新を監視し、アプリケーションが更新された場合、当該アプリケーションのアップデートに起因するトラヒックを監視している。アプリケーション更新端末２０６は基地局２０１の内部機能として具備することも、通常の端末のように基地局２０１とは別装置として具備することも可能である。

アプリケーション更新確認端末２０６は更新されたアプリケーションの管理監視を行うだけではなく、当該アプリケーションのアップデートを一定時間ごとに、例えば１時間ごとに実行し、当該アプリケーションをアップデートした際のネットワークの状態、例えば、アプリケーションアップデート開始から終了までの通信時間や送受信パケット数を集計することにより、当該アプリケーションがネットワークに与える影響を把握することができる。また、トラヒック制御装置２０９等により当該アプリケーションが制御対象になっている場合には、上述の定期的なアップデートにより、当該アプリケーションの規制動作を確認することも可能である。

図１は、無線線端末１０１がアプリケーションを更新する処理を示すシーケンス図である。通常アプリケーションをアップデートするときには、端末からアプリケーション提供サーバに対して現在使用しているアプリケーションのバージョンの確認を行う。端末から行われるバージョン確認は、端末内で管理されているアプリケーション管理リストに対して一斉に行われる場合と、個々のアプリケーションに対してのみ行われる場合がある。また、アプリケーション／ＩＤ管理サーバからプッシュ方式で端末に対してバージョンアップを通知する場合もある。

図１において、無線端末１０１がアプリケーションを更新する場合、アプリケーション提供サーバ１０２に無線端末１０１が所有しているアプリケーションリスト（１０１１）を送信する。アプリケーション提供サーバ１０２は定期的にアプリケーション／ＩＤ管理サーバ１０３から最新のアプリケーションのバージョン情報を確認し、当該情報を管理している。アプリケーション提供サーバ１０２ならびにアプリケーション／ＩＤ管理サーバ１０３は別々のサーバとして記載しているが、同一サーバにおいて管理実装することも可能である。無線端末１０１からアプリケーションリストを受信したアプリケーション提供サーバ１０２はアプリケーションＩＤ／管理サーバ１０３に確認したアプリケーションバージョン情報を元に、無線端末１０１から送信されたアプリケーションリスト内にバージョンが更新されているアプリケーションの有無を確認し、更新されたアプリケーションが存在すれば、無線端末１０１に更新されたアプリケーションならびにそのバージョンを通知する（１０１２）。アプリケーションの更新を確認した無線端末１０１は、ユーザー自律もしくはアプリケーション自律によってアプリケーションアップデートリクエスト（１０１３）をアプリケーション提供サーバ１０２に送信し、アプリケーションの更新を行う。

図２に示すシステム例は、アプリケーション提供サーバ１０２の管理しているアプリケーションのリストならびにアプリケーションアップデートリクエスト（１０１３）を捉えることにより、アプリケーションの更新によるシグナリングバーストを検知制御するシステムである。

無線端末１０１とアプリケーション提供サーバ１０２間の通信は、始めにセッションを確立するために呼処理制御装置２０２と通信する。セッションが確立されたのちに、図１に示すアプリケーションリストの更新のシーケンスが流れる。アプリケーションの更新シーケンスは無線端末１０１〜基地局２０１〜ユーザーデータ制御装置２０３〜インターネット２０４を経由して行われる。

アプリケーションの更新状況はアプリケーション提供サーバ１０２ならびにアプリケーション／ＩＤ管理サーバにて管理されているため、モバイルネットワークの装置ならびにオペレータがアプリケショーンの更新状況を把握することは難しい。そこで、アプリケーション更新確認端末２０６により定期的にアプリケーションの更新状況を確認する機能を具備する。アプリケーション更新確認端末２０６は通常の無線端末１０１と同等であり、無線端末１０１と同じ端末を併設もしくは同等の機能を基地局２０１に具備する。

アプリケーション更新確認端末２０６は無線端末１０１がアプリケーションを更新する場合と同様に図１に示すシーケンスに従って最新のアプリケーションの情報を入手、管理する。最新のアプリケーション更新情報は、定期的に解析サーバ２０８に転送される。解析サーバ２０８は当該アプリケーション更新情報を元に、実際のパケットから当該アプリケーションに関わるトラヒックを分析し、制御を行う。解析サーバ２０８はアプリケーション更新確認端末２０６から送信されたアプリケーション更新情報に差分がある場合に各トラヒック制御装置２０９ならびに基地局２０１、呼処理制御装置２０２、ユーザーデータ制御装置２０３に対してアプリケーションの更新情報を通知（注意報）する。注意報を受信した各装置は、バースト発生警報を受信するかもしくは注意報が解除されるまで当該アプリケーションによる通信を監視する。

一方、モバイルネットワーク上を流れるパケットは分岐装置２０５によってコピーされ、ＤＰＩ装置２０７へ転送される。基地局２０１ならびに呼処理制御装置２０２間のデータ（呼処理信号パケット）にはセッションを確立するための呼処理情報が含まれており、当該パケットにユーザ情報が含まれている。また基地局２０１ならびユーザーデータ制御装置２０３間のデータ（ユーザーデータパケット）には、実際アプリケーションサーバ間の通信であり、使用しているサービスやアプリケーション等の情報が含まれている。分岐装置２０５は、これらのパケットのコピーをＤＰＩ装置へ転送し、ＤＰＩ装置２０７は、ユーザーが実際どのアプリケーションを用いて通信しているかを分析する。

ＤＰＩ装置２０７によってユーザが使用しているアプリケーションを特定した後に解析サーバ２０８にて当該アプリケーションが更新されたアプリケーションによるトラヒックかもしくはさらに、アプリケーションが更新され、バーストを発生させているトラヒックか、アプリケーションの更新に関係なくバーストが発生しているかを判定する。解析サーバ２０８によってバーストが発生していると判定されたアプリケーションは、解析サーバ２０８により各トラヒック制御装置２０９ならびに基地局２０１、呼処理制御装置２０２、ユーザーデータ制御装置２０３に対してバーストが発生している通知（警報）を送信する。警報を受信した各装置は、当該アプリ−ションの通信を遮断する等の制御を行う。警報発令後は、解析サーバ２０８より解除の通知が行われるまで、当該アプリケーションの通信は制御され続ける。

図３は、アプリケーション更新確認端末２０６の構成を示すブロック図である。アプリケーション更新確認端末２０６はアプリケーション管理テーブル３０１ならびに更新アプリケーション管理テーブル３０２を具備している。また、アップデート対象アプリケーションの動作を確認するためのアプリケーションダウンロード動作部３０３ならびにアップデート対象アプリケーションをダウンロードした際に実行ログを格納するためのアプリケーションダウンロードログ格納部３０６を具備している。

アプリケーション管理テーブル３０１は、モバイルオペレータが管理したいアプリケーションの一覧である。アプリケーション管理テーブル３０１は、ＤＰＩ装置２０７で管理しているアプリケーションテーブル６０２２の一部であり、モバイルオペレータが任意に作成することも可能である。また、解析サーバの結果により生成された人気アプリケーションテーブル１１０３２を利用することも可能である。

アプリケーション管理テーブル３０１に示されているアプリケーションはアプリケーション更新確認端末にはインストールされておらず、当該アプリケーションを実際使用することはできないが、当該アプリケーションがインストールされている状態を擬似している。つまりアプリケーション名とバージョン情報等アップデートに必要な情報を管理している。実際当該アプリケーションがアップデートされていた場合、当該アプリケーションの動作を確認するために、定期的に、例えば１時間ごとにアプリケーションダウンロード動作部３０３よりアプリケーションのダウンロードを実行する。実行後ダウンロードしたファイルは削除し、ダウンロード時間、パケット数等の情報をアプリケーションダウンロードログ格納部に格納する。

図４は、アプリケーション管理テーブル３０１の一例を示す図である。アプリケーション管理テーブル３０１には当該アプリケーションを登録された日付４０１１、アプリケーション名４０１２，当該アプリケーションのバージョン４０１３を含んでいる。当該情報を元に、アプリケーション提供サーバ１０２の応答と比較し、更新アプリケーションテーブル３０２を作成する。

アプリケーション更新確認端末２０６はアプリケーション管理テーブル３０１を出力部３０４を経由して定期的にアプリケーション提供サーバ１０２へ送信する。アプリケーション提供サーバ１０２は、受信したアプリケーション管理テーブル３０１に示されているアプリケーションの内、更新されているアプリケーションが存在すれば、当該アプリケーションのみをアプリケーション更新確認端末２０６へ送信する。アプリケーション提供サーバ１０２から送信されたアプリケーションリストはアプリケーション更新確認端末２０６の入力部３０５を経由して、更新アプリケーション管理テーブル３０２に格納される。

更新アプリケーション管理テーブル３０２は定期的に、例えば１０秒毎もしくは１分ごとに出力部３０４を経由して解析サーバ２０８に転送される。

図５は、更新アプリケーション管理テーブル３０２の一例を示す図である。更新アプリケーション管理テーブル３０２には、更新日５０１１、更新アプリケーション情報受信時刻５０１２、アプリケーション名５０１３、バージョン５０１４、ならびに想定ダウンロード数５０１５が含まれる。当該アプリケーションを利用しているユーザー数を想定ダウンロード数５０１５として考えることとする。想定ダウンロード数５０１５はアプリケーション提供サーバ１０２にてダウンロードしたユーザ数を数えることにより管理している。更新アプリケーション管理テーブル３０２は当該情報をアプリケーション提供サーバ１０２より入手する。実際、ダウンロードしたユーザ数は具体的な数字ではなく、例えば１，０００万人以上という形式で与えられている。そのため、当該数値と次のレンジの数値とによって、想定ダウンロード数を決める。

アプリケーション更新確認端末２０６にて、アプリケーションの更新が判明した場合、当該アプリケーションを検出する必要がある。当該アプリケーションを検出する装置がＤＰＩ装置２０７である。

図６は、ＤＰＩ装置２０７の構成を示すブロック図である。ＤＰＩ装置２０７はパケット解析部６０１、アプリケーション解析部６０２ならびに出力部６０３が含まれている。パケット解析部６０１は、分岐装置２０５にてコピーされた基地局２０１〜呼処理制御装置２０２間の呼処理信号パケットならびに基地局２０１〜ユーザーデータ制御装置２０４間のユーザーデータパケットを元に、ユーザーＩＤ抽出部６０１１にて基地局２０１〜呼処理制御装置２０２間の呼処理信号パケットからユーザＩＤ等の情報を抽出し、ユーザーデータ抽出部６０１２にて基地局２０１〜ユーザーデータ制御装置２０３間のユーザーデータパケットから使用しているアプリケーション等の情報を抽出し、両者のパケットを紐づける識別子によって当該情報を紐づける。

基地局２０１〜呼処理制御装置２０２間からＤＰＩ装置２０７に転送された呼処理信号パケットのパケットフォーマット例を図７に、基地局２０１〜ユーザーデータ制御装置２０３間からＤＰＩ装置２０７に転送されたユーザーデータパケットのパケットフォーマット例を図８に示す。ＤＰＩ装置２０７は図７ならびに図８に示すパケットから基地局ＩＤ７０２、８０２、端末ＩＤ７０３、機種ＩＤ７０４、共通識別子７０５、８０３ならびにアプリケーションに関する情報８０４を抽出する。共通識別子７０５ならびに８０３は基地局２０１のＩＰアドレスやトンネルＩＤ等が使われることが一般的である。呼処理信号パケットとユーザーデータパケットを紐付けることにより、当該アプリケーションによるアップデートが実行された際、呼処理信号に与える影響を把握することができる。

紐づけられた情報はアプリケーション解析部６０２に実装されているアプリケション判定部６０２１において、アプリケーションテーブル６０２２に格納されているアプリケーション情報を元にて当該パケットがどのようなサービス／アプリケーションであるかを判定する。

図９は、アプリケーションテーブル６０２２の例を示す図である。アプリケーションテーブル６０２２にはアプリケーション名、バージョン情報の他に当該アプリケーションを使用することよって提供されるサービスが記載されている。ＤＰＩ装置２０７によって抽出されたデータとアプリケーションテーブル６０２２を比較し当該パケットがどのようなアプリケーションでどのようなサービスを提供されているかを知ることができる。本実施例においては、アプリケーションテーブル６０２２に記載されているアプリケーションアップデートサービスに該当するか否かを判定し、アプリケーションアップデートサービスに該当した場合はアプリケーション更新フラグをたてる。例えば、ＤＰＩ装置２０７が受信したユーザーデータパケットに含まれるアプリケーションに関する情報８０４を参照し、当該ユーザーデータパケットがアプリケーションアップデートサービスに関するパケットであると判断した場合に、ＤＰＩログにアプリケーション更新フラグをたてる。その結果をＤＰＩログとして出力部６０３を経由して解析サーバ２０８へ転送される。ＤＰＩ装置２０７から解析サーバ２０８へ転送されるＤＰＩログは当該アプリケーションのサービスに応じて生じる一連のセッションをひとつのＤＰＩログとして生成される。セッションは無線端末１０１〜基地局２０１〜呼処理制御装置２０２もしくはユーザーデータ制御装置２０３間で送受信される複数のパケットによって生成され、当該セッションを元に当該ＤＰＩログが生成される。セッションはモバイルネットワークシステムにより異なり、当該モバイルネットワークシステムごとに生成されるＤＰＩログは異なる。

図１０は、ＤＰＩ装置２０７から解析サーバ２０８へ転送されるＤＰＩログの例を示す図である。ＤＰＩログには、ログ生成時刻、基地局ＩＤ、端末ＩＤ、機種ＩＤ、呼処理情報、アプリケーション名、アプリケーション更新フラグが含まれる。ＤＰＩログを受信した解析サーバ２０８が当該アプリケーション更新フラグを参照して、更新アプリケーションに関するＤＰＩログであるか否かを判断することも可能である。

図１１は、解析サーバ２０８の構成を示すブロック図である。解析サーバ２０８には、アプリケーション集計部１１０１、アプリケーション制御部１１０２ならびにアプリケーション管理テーブル１１０３が含まれている。

解析サーバ２０８はアプリケーション更新確認端末２０６より更新アプリケーション管理テーブル３０２の情報を受信する。受信した更新アプリケーション情報は、一定時間内、たとえば１日、１時間、１０分以内に更新したアプリケーションのリストとなる。当該情報を入手した解析サーバ２０８は当該情報を解析サーバ２０８内に具備しているアプリケーション管理テーブル１１０３の更新アプリケーション管理テーブル１１０３１に格納し、アプリケーション制御部１１０２の注意報発令部１１０２１によって注意アプリケーションと認識され、制御部１１０２３によって基地局２０１、呼処理制御装置２０２、ユーザーデータ制御装置２０３、ならびにトラヒック制御装置２０９に当該アプリケーションに関して更新が行われたことを通知する。

アプリケーション更新通知を受信した基地局２０１、呼処理制御装置２０２、ユーザーデータ制御装置２０３、ならびにトラヒック制御装置２０９は、解析サーバ２０８より警報（バースト発生警報）が発令通知されるかもしくは注意報解除通知が通知されるまで当該アプリケーションの監視を行い、監視状態下において、急激なトラヒック量の変化が生じた場合は、トラヒック制御装置２０９にて当該アプリケーションに伴う通信を遮断する。

解析サーバ２０８は，アプリケーション更新確認端末２０６より送信された更新アプリケーション情報を元に、実際のトラヒックの解析を行う。解析サーバ２０８はＤＰＩ装置２０７より転送されたＤＰＩログに含まれるアプリケーションの情報に対して、アプリケーション集計部１１０１内の更新アプリケーション判定部１１０１１において更新アプリケーションテーブル１１０３１に含まれているかを判定する。

ＤＰＩ装置２０７から転送されるＤＰＩログには２つのパターンが存在する。更新アプリケーションに該当するＤＰＩログと更新アプリケーション以外に該当するＤＰＩログである。当該ＤＰＩログがＤＰＩ装置２０７から解析サーバ２０８へ転送されるたびに、解析サーバでアクセス数がカウントされる。つまり、更新アプリケーションのＤＰＩログの数が当該アプリケーションを更新しているユーザーの数に相当する。またＤＰＩログの数が当該アプリケーションにおけるアクセス数となる。同様に更新アプリケーション以外のＤＰＩログの数が当該アプリケーションによってサービスをうけているユーザーの数に相当し、当該アプリケーションのアクセス数となる。更新アプリケーションのアクセス数と更新アプリケーション以外のアクセス数の合計が、当該システムにおけるアプリケーションのアクセス総数となる。

ＤＰＩ装置２０７よりＤＰＩログが送信される度に、当該データに含まれるアクセス数の総数ならびに更新アプリケーションのアクセス数、更新アプリケーション以外のアクセス数を集計する。（集計結果は更新アプリケーションテーブル１１０３１ならびに通常アプリケーションテーブル１１０３２に格納する。

ＤＰＩ装置２０７から転送されるＤＰＩログに示されるアプリケーションが更新アプリケーションテーブル１１０３１に含まれている場合には、当該アプリケーションのトラヒック量、例えばアクセス数、ならびに当該アプリケーションによって起因した呼処理信号のトラヒック量、例えばアクセス数を単位時間あたりに加算し、更新アプリケーションテーブル１１０３１を更新する。このときアプリケーション集計部１１０１は更新アプリケーションテーブル１１０３１の情報を元に、人気アプリケーション判定部１１０１２にてバーストしているか否かを判定する。

ＤＰＩ装置２０７から転送されるＤＰＩログに示されるアプリケーションが更新アプリケーションテーブル１１０３１に含まれていない場合は、更新アプリケーションテーブル１１０３１の更新は行わず、通常アプリケーション管理テーブル１１０３２に当該アプリケーションのトラヒック量（例えば、アクセス数）を記録し、格納する。次に、アプリケーション集計部１１０１は通常アプリケーション管理テーブル１１０３２に記載されている当該アプリケーションのバーストを人気アプリケーション判定部１１０１２にて判定する。

図１２に更新アプリケーション管理テーブル１１０３１の一例を、図１３に通常アプリケーション管理テーブル１１０３２の一例を示す。

図１２に示す更新アプリケーション管理テーブルは、アクセス数管理テーブル１２０１と個別更新アプリケーション管理テーブル１２０２〜１２０５から構成される。アクセス数管理テーブル１２０１には、測定時間における単位時間での全てのアプリケーションのアクセス総数ならびに更新されたアプリケーションのアクセス総数が含まれている。本例は、１３：００：００から１３：００：０５までの５秒間のすべてのアプリケーションのアクセス総数と更新されたアプリケーションのアクセス総数１２０１１〜１２０１５を示している。

個別アプリケーション管理テーブル１２０２〜１２０５はアプリケーション更新確認端末２０６より転送された更新アプリケーションリストの情報を元に各アプリケーション毎に作成される。当該テーブルにはアプリケーション名、バージョン、想定ダウンロード数ならびに単位時間あたりのアクセス数と当該時刻以降想定される予想残ダウンロード数が含まれる。アプリケーション名、バージョン、想定ダウンロード数はアプリケーション更新確認端末２０６より転送された更新アプリケーションリストの情報を元に作成する。想定ダウンロード数は図５に示すようにレンジで記録されているが、その上限値を想定ダウンロード数と定義する。ただし、上限値が規定されていない場合、頻度分布の最も大きいレンジ（５，０００万以上として書かれていない場合）においては、その下限値を想定ダウンロード数とする。図５の例では、アプリケーションＡ，Ｂ，Ｃ，Ｄのそれぞれの想定ダウンロード数は、３，０００万、１，０００万、５，０００万、１００万となる。

アクセス数はＤＰＩ装置２０７によって実際モバイルネットワークを流れているトラヒックから当該アプリケーションに関するトラヒックを抽出することにより計算される。予想残ダウンロード数は想定ダウンロード数から当該時刻におけるアクセス数を減算した値を示している。

解析サーバ２０８の人気アプリケーション判定部１１０１２では、個別アプリケーション管理テーブル１２０２〜１２０５を元にバーストトラヒックの判定を行う。バーストトラヒックの判定は以下に示す３つの条件のいずれかに該当した場合にバーストトラヒックと判定する。
・条件（１）測定時刻において、前時刻の測定結果（アクセス数）と比較し、前時刻の測定結果のα倍（α＞１）以上となる。
・条件（２）更新アプリケーションのアクセス総数を母集団とし、その母集団において当該アプリケーションのアクセス数の割合がβ（β＜１）以上となる。
・条件（３）全てのアプリケーションのアクセス総数を母集団とし、その母集団において当該アプリケーションのアクセス数の割合がγ（γ≦β＜１）以上となる。

例えば、図１２に示す個別アプリケーション管理テーブル１２０２〜１２０５において、α＝１０、β＝０．６、γ＝０．２とすると、バーストトラヒック判定条件（１）に該当し、バーストトラヒックと判定されるのは、アプリケーションＢの場合（１２０３）の１３：００：０４（１２０３４）の場合である。１２０３において、１３：００：０３でのアクセス数が１,２００であったが、１３：００：０４においてアクセス数が約１７倍の２０，０００になっている。

バーストトラヒック判定条件（２）に該当し、バーストトラヒックと判定されるのは、アプリケーションＣの場合（１２０４）の１３：００：０１（１２０４１）〜１３：００：０４（１２０４４）の場合である。このとき、更新アクセスアプリケーション総数は、
１３：００：０１で１，００２，１００
１３：００：０２で１，５０２，４２０
１３：００：０３で２０１，８１０
１３：００：０４で１２１，１００
１３：００：０５で６５，８８０
となっている。そのうちアプリケーションＣのアクセス数が占める割合は、
１３：００：０１で１，０００，０００／１，００２，１００＝０．９９８
１３：００：０２で１，５００，０００／１，５０２，４２０＝０．９９８
１３：００：０３で２００，０００／２０１，８１０＝０．９９１
１３：００：０４で１００，０００／１２１，１００＝０．８２６
１３：００：０５で３０，０００／６５，８８０＝０．４５５
となる。よって、βを０．６とすると、１３：００：０１〜１３：００：０４の区間においてアプリケーションＣはバーストが発生していると判定される。

バーストトラヒック判定条件（３）に該当し、バーストトラヒックと判定されるのは、アプリケーションＢの場合（１２０３）の１３：００：０５（１２０３５）の場合である。
このとき、更新アプリケーションと通常アプリケーションの合計を示すアクセス総数は、
１３：００：０１で１，００６，１００
１３：００：０２で１，５０７，２２０
１３：００：０３で２３４，８１０
１３：００：０４で１７１，１００
１３：００：０５で１７０，１８０
となっている。このときアプリケーションＢのアクセス数が占める割合は
１３：００：０１で１，０００／１，００６，１００＝０．００１
１３：００：０２で１，５００／１，５０７，２２０＝０．００１
１３：００：０３で１，２００／２３４，８１０＝０．００５
１３：００：０４で２０，０００／１７１，１００＝０．１１７
１３：００：０５で３５，０００／１７０,１８０＝０．２０５
となる。よって、１２０３において１３：００：０５では全てのアプリケーションのアクセス総数のうち、アプリケーションＢのアクセス数が２０．５％を占めている。

図１３に示す通常アプリケーション管理テーブル１１０３２にも同様に、アクセス数管理テーブル１３０１と個別アプリケーション管理テーブル１３０２ならびに１３０３から構成される。

アクセス数管理テーブル１３０１には、測定時間における単位時間での全てのアプリケーションのアクセス総数ならびに更新されたアプリケーションのアクセス総数が含まれている。本例は、１３：００：００から１３：０００５までの５秒間のすべてのアプリケーションのアクセス総数と、アプリケーション更新確認端末２０６から送信された更新アプリケーションリストに記載されていなかったアプリケーション（通常アプリケーション）のアクセス数１３０１１〜１３０１５を示している。

個別アプリケーション管理テーブル１３０２ならびに１３０３は、アプリケーション名、当該アプリケーションのバージョンならびに単位時間当たりのアクセス数が含まれる。アクセス数はＤＰＩ装置２０７によって実際モバイルネットワークを流れているトラヒックから当該アプリケーションに関するトラヒックを抽出することにより計算される。

図１３に示す個別アプリケーション管理テーブル１３０２ならび１３０３に関しても同様に上述のバースト判定（条件（１）〜（３））を適用する。パラメータα、βならびにγは上述と同じ値、つまり、α＝１０、β＝０．６、γ＝０．２とする。このとき、アプリケーションＥ（１３０２）の時刻１３：００：０３に前時点１３：００：０２と比較してアクセス数がα（α＝１０）倍を超え（１３０２３）、バーストが発生していると判定される。次に通常アプリケーションのアクセス数を母集団として、その母集団内で６０％（β＝０．６）を超えているアプリケーションがあれば当該アプリケーションによる通信はバーストであると判定される。つまり、通常アプリケーションの場合は、上述した条件（２）で記載した「更新アプリケーション」を「通常アプリケーション」と読み替えて適用する。図１３の例においては、１３：００：０１〜１３：００：０２（１３０３１〜１３０３２）ではアプリケーションＦにおいてバーストが発生していると判定し、１３：００：０３〜１３：００：０５（１３０３３〜１３０３５）ではアプリケーションＥにおいてバーストが発生していると判定される。図１３の例では、１３：００：０５においてアプリケーションＥが上記判定条件の（３）に適合するが、すでに上記判定条件（２）によってバーストが発生していると判断されているため、判定条件（３）で改めてバーストが発生していると判定されない。なお、本例におけるパラメータα、βならびにγは任意に決めることができる。

人気アプリケーション判定部１１０１２においてバーストトラヒックと判定されると、アプリケーション制御部１１０２の警報発令部１１０２２により、バーストが発生していると判断されたアプリケーションに対するバースト発生警報が発令される。バースト発生警報が発令された後に、制御部１１０２３より、基地局２０１、呼処理制御装置２０２、ユーザーデータ制御装置２０３ならびにトラヒック制御装置２０９にバースト発生警報が通知される。バースト発生警報を受信した基地局２０１、呼処理制御装置２０２、ユーザーデータ制御装置２０３ならびにトラヒック制御装置２０９は当該アプリケーションのトラヒックを遮断する等の制御を行い、ネットワーク障害を予防する。

更新アプリケーションのバースト発生警報は以下２つのいずれかの条件を満たしたときに解除される。
・条件（１）更新アプリケーションのアクセス数を母集団とし、その母集団において当該アプリケーションの割合がβ（β＜１）未満となる。
・条件（２）全てのアプリケーションのアクセス数を母集団とし、その母集団において当該アプリケーションの割合がγ（γ≦β＜１）未満となる。

図１２に示す例においてはアプリケーションＣにおける１３：００：０５（１２０４５）において全てのアプリケーションのアクセス数に対するアプリケーションＣのアクセス数が約１８％となるので、当該時刻において当該アプリケーションのバースト発生警報は解除される。また、図１３において、アプリケーションＦにおける１３：００：０３（１３０３４）において更新対象のアプリケーション以外のアプリケーションのアクセス数に対する当該アプリケーションのアクセス数が約１０％でとなるので当該時刻において当該アプリケーションのバースト発生警報は解除される。通常アプリケーションの場合は、上記条件（１）の「更新アプリケーション」を「通常アプリケーション」と読み替えて適用する。

人気アプリケーション判定部１１０１２によってバースト発生警報が解除されると、警報発令部１１０２２によりバースト発生警報解除が発令され、制御部１１０２３より基地局２０１、呼処理制御装置２０２、ユーザーデータ制御装置２０３ならびにトラヒック制御装置２０９にバースト発生警報解除が通知される。このとき、当該アプリケーションが更新対象のアプリケーションである場合、バースト発生警報解除を通知された基地局２０１、呼処理制御装置２０２、ユーザーデータ制御装置２０３ならびにトラヒック制御装置２０９はバースト発生注意報状態になり、引き続き、当該アプリケーションの監視を行う。また、バースト発生警報解除の対象となるアプリケーションが更新対象のアプリケーションではない場合、当該アプリケーションに対する制御が解除される。このとき、バースト発生注意報状態にはならない。

バースト発生注意報は以下の条件（１）を満たすときに解除される。
・条件（１）予想残ダウンロード数が想定ダウンロード数の１％未満になる。

図１２において、アプリケーションＤ（１１０５）における、１３：００：０２（１１０５２）のときに予想残ダウンロード数が想定ダウンロード数の１％未満になるので、バースト発生注意報は解除となる。更新アプリケーション判定部１１０１１において、当該条件を満たした場合、バースト発生注意報解除と判定され、注意報発令部１１０２１によって当該アプリケーションに対するバースト発生注意報解除の通知が制御部１１０２３より基地局２０１、呼処理制御装置２０２、ユーザーデータ制御装置２０３ならびにトラヒック制御装置２０９に通知される。このとき基地局２０１、呼処理制御装置２０２、ユーザーデータ制御装置２０３ならびにトラヒック制御装置２０９はバースト発生注意報を解除し、当該アプリケーションの監視を解除する。

なお、図３、図６、図１１で説明したアプリケーション更新確認端末２０６、ＤＰＩ装置２０７、解析サーバ２０８はいずれも一般的なサーバ装置で実現されており、図示していないが、ＣＰＵやメモリ、ハードディスク、他装置と通信するための通信インタフェース等を備えている。アプリケーションダウンロード動作部３０３、パケット解析部６０１、アプリケーション集計部１１０１などの各機能部は、例えばメモリに格納されているプログラムをＣＰＵが実行することにより実現される。また、アプリケーション管理テーブル３０１、アプリケーションテーブル６０２２、更新アプリケーション管理テーブル１１０３１などは、例えばハードディスクやメモリにより実現される。

図１４〜図１８は、本実施例の解析サーバ２０８におけるバースト判定フローチャートである。
初期設定として判定を開始する時刻Ｔならびに観測周期Δｔを設定する（１４０１）。初期設定後ＤＰＩログを入力データとして入力し（１４０２）、通常アプリケーション管理テーブル１１０３２と更新アプリケーション管理テーブル１１０３１を読み込む（１４０３）。次に当該ＤＰＩログのアクセス数の時間分布を作成するために、判定する時間幅を決める。区間幅の下限値をＴ０、上限値をＴ１とし、Ｔ０＝Ｔ、Ｔ１＝Ｔ＋Δｔと定義する。Ｔ０の初期値は判定を開始する時刻とする（１４０４）。入力データとして入力されたＤＰＩログが、１４０４に定められた時間内にあればカウンター更新フローへ推移し、１４０４に定められた区間外ならば、管理テーブル更新フローへ推移する（１４０５）。

図１４、１５に管理テーブル更新フローを示す。図１６にカウンター更新フローを示す。管理テーブル更新フローにおいて、始めに観測時刻を更新する。１４０４における上限値Ｔ１をＴ０へ、そして新しい上限値をＴ１＋Δｔとする（１４０６）。時刻更新後、更新対象アプリケーションか否かを判定し（１５０１）、更新対象アプリケーションならば１５０２〜１５０９のフローで、更新対象アプリケーションでなければ、１５０８〜１５１５のフローで処理する。

更新対象アプリケーションである場合、更新アプリケーション管理テーブル１１０３１で管理されている全てのアプリケーションに対して（本フローにおいてはＫ種類のアプリケーションを管理している）、当該アプリケーションのアクセス数ならびに予想残ダウンロード数を更新する（１５０２）。予想残ダウンロード数は前時点における予想残ダウンロード数から当該アプリケーションのアクセス数を減算することによって計算される（１５０３）。同時に、当該時間区間における更新アプリケーションアクセス総数Ｎ_UPを計算する（１５０３）。このとき、予想残ダウンロード数が想定ダウンロード数の１％未満になっている場合はバースト注意報を解除する（１５０４、１５０５）。注意報判定終了後、更新アプリケーション管理テーブルのアクセス総数Ｎ、更新アプリケーションアクセス数Ｎ_{UP_j}、予想残ダウンロード数Ｎ_{LA_j}を更新する（１５０６）。全ての更新対象アプリケーションに対して更新アプリケーション管理テーブルを更新したのち、更新アプリケーションアクセス数カウンターを初期化する（１５０７）。１５０３〜１５０７の処理を全ての更新対象アプリケーションに対して行う（１５０８）。最後に、更新アプリケーション管理テーブルの更新アプリケーションアクセス総数Ｎ_UPを更新する（１５０９）。 通常アプリケーション管理テーブルの更新も同様に処理されるが、通常アプリケーション管理テーブルには予想残ダウンロード数の項目がないため、当該処理は行われない。更新対象アプリケーションではないと判定された場合、通常アプリケーション管理テーブルにて管理されている全てのアプリケーションに対して（本フローにおいてはＭ種類のアプリケーションを管理している）、当該アプリケーションのアクセス数を更新する（１５１０）。まず、通常アプリケーションアクセス総数Ｎ_NOの計算を行う（１５１１）。次に、通常アプリケーション管理テーブルはアクセス総数Ｎならびに通常アプリケーションアクセス数Ｎ_{NO_l}を更新する（１５１２）。全てのアプリケーションに対して通常アプリケーション管理テーブルを更新したのち、通常アプリケーションアクセス数カウンターを初期化する（１５１３）。１５１１〜１５１３の処理を全ての対象アプリケーションに対して行う（１５１４）。全ての通常アプリケーションの処理終了後に、通常アプリケーション管理テーブルの通常アプリケーションアクセス総数Ｎ_NOを更新する（１５１５）。

最後に、アクセス総数カウンターＮ、更新アプリケーションアクセス総数Ｎ_UP、通常アプリケーションアクセス総数Ｎ_NOを初期化する（１５１６）。

図１４の１４０５にてＤＰＩログが観測時間内に含まれている場合、カウンター更新フローへ推移する。図１６のカウンター更新フローにおいて、アクセス総数Ｎを加算する（１６０１）。ＤＰＩログに記載されているアプリケーションが更新対象アプリケーションであるか否かを判定する（１６０２）。更新対象アプリケーションであれば、１６０３〜１６０６のフローを実行し、更新対象アプリケーションでなければ１６０７〜１６１０のフローを実行する。図１７、１８にて処理されるバースト判定処理は更新アプリケーション、通常アプリケーションいずれも同様のため登録アプリケーション数を同じ変数Ｒに格納する（１６０３、１６０７）。更新対象アプリケーションの場合、更新アプリケーション管理テーブルに登録されているアプリケーションに一致しているかを判定し（１６０５）、一致していれば、更新アプリケーションアクセス数カウンターＮ_{UP_j}を加算する（１６０６）、更新対象アプリケーションでない場合、通常アプリケーション管理テーブルに登録されているアプリケーションに一致しているかを判定し（１６０９）、一致していれば、通常アプリケーションアクセス数カウンターＮ_{NO_l}を加算する（１６１０）。

更新アプリケーション管理テーブルならびに通常アプリケーション管理テーブルのアプリケーションに一致していなければ（ステップ１６０５またはステップ１６０９でＮｏの場合）、カウンターの加算ならびにバースト判定フローを行わず、次のアプリケーションに遷移する（図１８のステップ１８０６へ遷移）。１６０２〜１６１０、１７０１〜１７０６、１８０１〜１８０６の処理を全てのアプリケーションに対しておこなう。

図１７は、バースト発生警報が発令される処理を示すフローチャートである。バースト発生警報の判定は、前時点のアクセス数と現時点のアクセス数を比較して現時点のアクセス数が前時点のアクセス数のα倍（α＞１）以上になっている（１７０１）、または更新アプリケーションもしくは通常アプリケーションのアクセス数が更新アプリケーションもしくは通常アプリケーション各々のアクセス数の総和の一定割合β（β＜１）以上になっている（１７０２）、または当該アプリケーションのアクセス数（更新の有無は無関係）が全てのアプリケーションのアクセス数の総和の一定割合γ（γ＜１）以上になっている（１７０３）であり、いずれかに該当した場合はバーストが発生していると判定する。このとき、判定対象のアプリケーションが更新対象アプリケーションに該当している場合は当該アプリケーションに対しては既に更新アプリケーション注意報が発令されている。そこで、更新対象アプリケーションに該当する場合は（１７０４）、当該アプリケーションに対する更新対象アプリケーション注意報を解除し（１７０５）、バースト発生警報を発令する（１７０６）。当該アプリケーションが更新対象アプリケーションに該当してない場合はバースト発生警報のみを発令する（１７０６）。

図１８は、バースト発生警報が発令されている状態を解除する処理を示すフローチャートである。バースト発生警報を解除する判定条件は、更新アプリケーションもしくは通常アプリケーションのアクセス数が更新アプリケーションもしくは通常アプリケーション各々のアクセス数の総和の一定割合β（β＜１）未満になっている（１８０１）、または当該アプリケーションのアクセス数（更新の有無は無関係）が全てのアプリケーションのアクセス数の総和の一定割合γ（γ＜１）未満になっている（１８０２）であり、いずれかに該当した場合はバースト状態ではないと判定する。このとき判定対象となるアプリケーションが更新対象アプリケーションに該当する場合は（１８０３）、更新アプリケーション注意報を再度発令し（１８０４）、バースト発生警報を解除する（１８０５）。更新対象アプリケーションに該当しない場合は、バースト発生警報を解除する（１８０５）。更新アプリケーションの判定からバースト発生の判定を更新アプリケーション管理テーブルならびに通常アプリケーション管理テーブルに登録されているすべてのアプリケーションに対して処理する（１８０６）。以上で判定プロセスが終了する。

以上説明したように、本実施形態によれば、ネットワーク上を流れるパケットをコピーし分析することにより、特定のアプリケーションに関わるパケットや特定のサーバからの通信のみを抽出し、その頻度を積み上げる。そして、その頻度が一定数を超えた場合に警報をあげ、当該アプリケーションもしくはサーバからのトラヒックを規制する制御を行うことが可能となる。

本発明を用いることにより、ネットワーク上で発生し、ネットワークに重大な影響を与える可能性があるバーストトラヒックを抑止することが可能になり、システム障害を防ぐことが可能になる。また、ユーザに対しても不必要な規制がかけられることもなく、その時々で最良の通信状況で通信を行うことができる。また、ネットワークに影響を及ぼす可能性があるアプリケーションを抽出することにより、ネットワーク上のトラフィックを制御するポイントを絞り込むことができる。

１０１：無線端末、１０２：アプリケーション提供サーバ、１０３：アプリケーション／ＩＤ管理サーバ、２０１：基地局、２０２：呼処理制御装置、２０３：ユーザーデータ制御装置、２０４：インターネット網、２０５：分岐装置、２０６：アプリケーション更新確認端末、２０７：ＤＰＩ装置、２０８：解析サーバ、２０９：トラヒック制御装置、３０１：アプリケーション管理テーブル、３０２：更新アプリケーション管理テーブル、３０３：アプリケーションダウンロード動作部、３０４：出力部、３０５：入力部、３０６：アプリケーションダウンロードログ格納部、６０１：パケット解析部、６０１１：ユーザーＩＤ抽出部、６０１２：ユーザーデータ抽出部、６０２：アプリケーション解析部、６０２１：アプリケーション判定部、６０２２：アプリケーションテーブル、６０３：出力部、１１０１：アプリケーション集計部、１１０１１：更新アプリケーション判定部、１１０１２：人気アプリケーション判定部、１１０２：アプリケーション制御部、１１０２１：注意報発令部、１１０２２：警報発令部、１１０２３制御部、１１０３アプリケーション管理テーブル、１１０３１更新アプリケーション管理テーブル、１１０３２通常アプリケーション管理テーブル

Claims (7)

1. モバイルネットワークで使用されるアプリケーションの更新状況を監視する端末と、基地局と、前記アプリケーションによるトラフィックを解析する解析サーバとを含むモバイルネットワークシステムであって、
   前記端末は、
   アップデートが行われる更新アプリケーションの情報を管理する第１管理部と、
   前記更新アプリケーションの情報を前記解析サーバに送信する送信部と、を有し、
   前記解析サーバは、
   前記更新アプリケーションのアクセス数を管理する第２管理部と、
   前記更新アプリケーションのアクセス数に基づいて、前記更新アプリケーションによるトラフィックがバーストトラフィックであるかを判定する判定部と、
   前記判定部により、バーストトラフィックであると判定された前記更新アプリケーションのトラフィックを制御するように警報を発令する制御部と、
   を有することを特徴とするモバイルネットワークシステム。
2. 請求項１に記載のモバイルネットワークシステムであって、
   前記モバイルネットワークシステムは更にＤＰＩ装置を含み、
   前記ＤＰＩ装置は、
   前記アプリケーションが送受信するパケットのコピーを受信し、前記パケットのコピーから前記アプリケーションの情報を取得してＤＰＩログを作成する処理部と、
   前記ＤＰＩログを前記解析サーバに送信する送信部と、
   を有し、
   前記第２管理部は、前記ＤＰＩログのうち、前記端末から送信された前記更新アプリケーションについてのＤＰＩログに基づいて、前記更新アプリケーションのアクセス数を計算することを特徴とするモバイルネットワークシステム。
3. 請求項２に記載のモバイルネットワークシステムであって、
   前記判定部は、単位時間あたりの前記更新アプリケーションのアクセス数が、前記単位時間よりも前の単位時間あたりの更新アプリケーションのアクセス数の所定数倍以上である場合に、前記更新アプリケーションによるトラフィックがバーストトラフィックであると判定することを特徴とするモバイルネットワークシステム。
4. 請求項２または請求項３に記載のモバイルネットワークシステムであって、
   前記第２管理部は、複数の更新アプリケーション毎のアクセス数と、前記複数の更新アプリケーションの総アクセス数とを管理しており、
   前記判定部は、単位時間あたりの前記更新アプリケーションのアクセス数が、前記単位時間あたりの前記複数の更新アプリケーションの総アクセス数の所定割合以上である場合に、前記更新アプリケーションによるトラフィックがバーストトラフィックであると判定することを特徴とするモバイルネットワークシステム。
5. 請求項４に記載のモバイルネットワークシステムであって、
   前記第２管理部は、前記ＤＰＩログのうち、前記端末から送信された前記更新アプリケーション以外の通常アプリケーションについてのＤＰＩログに基づいて、前記通常アプリケーションのアクセス数を計算し、複数の前記通常アプリケーション毎のアクセス数と、前記複数の通常アプリケーションの総アクセス数と、前記複数の更新アプリケーションおよび前記複数の通常アプリケーションを含む全アプリケーションの総アクセス数とを管理しており、
   前記判定部は、単位時間あたりの前記更新アプリケーションのアクセス数が、前記単位時間あたりの前記全アプリケーションの総アクセス数の所定割合以上である場合に、前記更新アプリケーションによるトラフィックがバーストトラフィックであると判定することを特徴とするモバイルネットワークシステム。
6. 請求項１から請求項５のいずれかに記載のモバイルネットワークシステムであって、
   前記モバイルネットワークシステムは更にアプリケーションを提供するサーバを含み、
   前記端末は、
   アプリケーション名とバージョン情報とを保持して前記アプリケーションがインストールされている状態を擬似し、前記アプリケーション名と前記バージョン情報を前記サーバへ送信して前記アプリケーションがアップデートされる更新アプリケーションであるかを問い合わせる処理部を有することを特徴とするモバイルネットワークシステム。
7. 請求項１から請求項６のいずれかに記載のモバイルネットワークシステムであって、
   前記モバイルネットワークシステムは前記基地局が送受信するトラフィックを制御する制御装置を含み、
   前記制御装置は、前記制御部から前記警報を発令されると、前記更新アプリケーションのトラフィックを遅延もしくは遮断することを特徴とするモバイルネットワークシステム。

Images