アプリケーション性能評価方法、評価装置および移動体通信システム
【目的】基地局におけるアプリケーションの性能劣化検出とその要因分析を行ない結果を表示する。
【解決手段】基地局とゲートウェイ間のパケットを監視し、予め定めたアプリケーション選別基準に従い、パケットよりアプリケーションフローの選別を行なう。単位時間当たりに個々のアプリケーションフロー対応に性能劣化が発生しているかどうかを判断するアプリケーションフロー選別・性能評価機能と、各アプリケーションの種別ごとに、性能劣化が発生したアプリケーションフローの占める性能劣化比率を求め、基地局における単位時間当たりの各アプリケーションの利用比率を各アプリケーションフロー数とデータ量から求め、求めた利用比率と各アプリケーションにおける性能劣化比率から、予め定めたアプリケーション種別対応の利用比率と性能劣化基準に従い、性能劣化が基地局全体におよんでいるかを判断する。
【解決手段】基地局とゲートウェイ間のパケットを監視し、予め定めたアプリケーション選別基準に従い、パケットよりアプリケーションフローの選別を行なう。単位時間当たりに個々のアプリケーションフロー対応に性能劣化が発生しているかどうかを判断するアプリケーションフロー選別・性能評価機能と、各アプリケーションの種別ごとに、性能劣化が発生したアプリケーションフローの占める性能劣化比率を求め、基地局における単位時間当たりの各アプリケーションの利用比率を各アプリケーションフロー数とデータ量から求め、求めた利用比率と各アプリケーションにおける性能劣化比率から、予め定めたアプリケーション種別対応の利用比率と性能劣化基準に従い、性能劣化が基地局全体におよんでいるかを判断する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、移動体通信システム上で利用されるアプリケーション性能評価とその性能劣化検出方法に係り、特に基地局におけるアプリケーション性能劣化要因の検出方法、評価装置および移動体通信システムに関する。
【背景技術】
【０００２】
モバイルデータトラヒックは、著しく増加すると予測されている。これは、ＷｉＭＡＸ（Worldwide Interoperability for Microwave Access）およびＬＴＥ（Long Term Evolution）と呼ばれるモバイルブロードバンド環境が整備されていくことによる。モバイルブロードバンド環境の普及により、アプリケーションは、モバイル事業者が提供していた携帯電話に特化したメール、Ｗｅｂアクセス、音楽などのダウンロードサービスなどから、通常のインターネットサービスであるＷｅｂアクセス、ビデオオンデマンド、ＶｏＩＰ（Voice over IP）さらには個人による動画放送サービスなどへと広がりをみせている。
【０００３】
移動体通信システムの運用では、利用者からの性能に対するクレームが来る前に問題を検出し、先手で対策を実施していくことが、ユーザ満足度向上のために必要である。アプリケーションを利用しているユーザが、その品質が悪化していると感じる場合、その要因の多くは、アプリケーションの通信性能の劣化によるものである。例えば、ユーザがダウンロードを遅いと感じている場合、アプリケーションの通信性能として、スループットが低下している。ＶｏＩＰで瞬断を感じる場合、アプリケーションの通信性能として、遅延が大きくなっている。
【０００４】
移動体通信システムにおいて、利用できるアプリケーションが広がりを見せていることから、単に基地局のトータル性能の監視だけで状態を判断するのではなく、アプリケーションの品質の観点での監視が必要である。このため、基地局における様々なアプリケーション利用の状態を把握し、アプリケーションにおける性能劣化の有無を判断し、その要因が基地局におけるリソース不足であるのか、端末の移動や位置における影響であるのかなど、性能劣化の原因を把握することが、移動体通信システムの最適化では重要になってきている。
【０００５】
一方、移動体通信システムにおいて、アプリケーション性能劣化の要因の一つとして、基地局への膨大なトラヒック流入がある。これを防ぐため、基地局への流入制御が行なわれている。特許文献１で示されている流入制御は、基地局において、トラヒック量を監視し、閾値との比較を行なう。特許文献１は、閾値を超えたトラヒックに対して流入制御を行なうものである。さらに、特許文献２で示されている流入制御は、通信ネットワークおいて、アプリケーションのトラヒック種別を判別する。各アプリケーションのトラヒック量を監視し、各アプリケーションのトラヒックに対応した流入制御を行なう。これにより、利用上で問題の要因となっているアプリケーションのみ制御の対象とする。対象外のアプリケーションに関しては、ネットワークにおけるＱｏＳ（Quality of Service）を保持する。
【０００６】
また、通信ネットワークにおいて、アプリケーションの性能劣化に対して柔軟に制御を行なうために、または要因切り分けのために、アプリケーション性能を監視することが一般的になっている。また、特許文献３は、アプリケーションサーバ性能とネットワーク性能の相関関係から、アプリケーションサーバ、管理対象ネットワーク、非管理対象ネットワークのいずれかに要因を切り分ける。すなわち、対象とするアプリケーショントラヒックと対象外のアプリケーショントラヒック比率の相関関係から、いずれのアプリケーションが性能劣化要因であるかを切り分ける。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開平１０−３３６７３４号公報
【特許文献２】特開２００７−０５３４６５号公報
【特許文献３】特開２００１−１９５２８５号公報
【発明の概要】
【発明が解決しようとする課題】
【０００８】
移動体通信システムにおいて、アプリケーション性能は、基地局におけるトラヒック量による影響、同時に利用する多種のアプリケーションの影響、個々の端末の位置や移動状況の影響などを受ける。
【０００９】
移動体通信システムにおける無線リソースは、複数の端末で共有して利用する。また、アプリケーションによって、パケット長およびパケット送信周期が異なる。この結果、アプリケーションの組合せによって、基地局における最大性能が変わる。また、無線帯域では、端末における基準電力の受信時の大きさにより、通信時の変調符号化方式を選択する。この結果、端末の受信状態、位置や移動状況により、送信スループットに差がでる。さらに、移動体通信システムは、無線帯域における効率良いデータ転送のため、小さいデータのパッキング機能を備えている。このため、一部のアプリケーションにパケットロスや破棄が集中する可能性が高い。また、ＴＣＰ（Transmission Control Protocol）を用いた通信では、パケットロスなどが集中すると、著しく性能が劣化し、性能が元に戻るまでに非常に時間がかかる。
【００１０】
よって、移動体通信は、上述したような影響を考慮して、アプリケーション性能劣化を検出すると共にその要因を分析する必要がある。また、アプリケーション性能劣化が、基地局全体のアプリケーションに波及する要因であるのか、個々アプリケーションフローにだけ出ている要因であるのかを切り分けることも必要である。
【００１１】
特許文献１、特許文献２に示す流入制御では、基地局全体のトラヒック量、あるいは通信システムにおける個々のアプリのトラヒック量のみに着目している。その結果、トラヒック量以外の上述した移動体通信システム特有の影響を考慮できない。
【００１２】
特許文献３に示すアプリケーション性能劣化要因の分析は、アプリケーションを意識している。しかし、有線におけるトラヒック量に着目した性能劣化要因の判断であり、上述した移動体通信システム特有の影響を考慮していない。
【００１３】
本発明の目的は、移動体通信システムにおいて、上述した課題を解決し、多様なアプリケーションを利用している端末を収容している基地局において、アプリケーション性能劣化の有無を判断し、基地局全体に及んだ問題であるのか、個々のアプリケーションのフローの問題であるのかを切り分けることである。
【００１４】
さらに他の目的は、アプリケーション性能劣化の要因を輻輳状態であるのか、端末の移動が多いことによるのか、端末の位置に問題があるのか、基地局以外に問題あるのかを切り分けを行ない、検出した結果として、基地局毎のアプリケーション利用状況、アプリケーション性能状態、劣化要因、保守員に求める対処の表示を提供することである。
さらに他の目的は、アプリケーション利用状況を考慮した流入制御を提供することである。
【課題を解決するための手段】
【００１５】
上述した課題は、基地局とゲートウェイ間のパケットを監視し、パケットより、予め定めたアプリケーション選別基準に従い、アプリケーションフローの選別を行ない、単位時間当たりに個々のアプリケーションフロー対応に性能劣化が発生しているかどうかを判断し、各アプリケーションの種別ごとに、性能劣化が発生したアプリケーションフローの占める性能劣化比率を求め、基地局における単位時間当たりの各アプリケーションの利用比率を各アプリケーションフロー数とデータ量から求め、求めた利用比率と各アプリケーションにおける性能劣化比率から、予め定めたアプリケーション種別対応の利用比率と性能劣化基準に従い、基地局において性能劣化が発生しているかどうかを判断するアプリケーション性能劣化を検出するアプリケーション評価方法により、達成できる。
【００１６】
また、基地局においてアプリケーション性能劣化が発生していると判断した場合、基地局における単位時間当たりのトータルスループットを、予め定めたアプリケーションの利用比率に応じた基地局における最低保証スループットと比較し、トータルスループットが最低保証スループットより大きい場合、トラヒック輻輳要因による性能劣化と判断し、トータルスループットが最低保証スループットより小さい場合、基地局におけるハンドオーバ実施回数を予め定めたハンドオーバ実施回数基準値と比較し、その基準値より大きい場合、移動要因による性能劣化と判断し、さらに、基地局における変調符号化方式対応の単位時間当たりの送信データ長から各変調符号化方式の利用比率を求め、求めた変調符号化方式の利用比率と予め定めた変調符号化方式の基準利用比率と比較し、利用比率が異なる場合、端末配置要因による性能劣化と判断するアプリケーション性能劣化要因を検出するアプリケーション評価方法により、達成できる。
【００１７】
また、基地局とゲートウェイ間のパケットより、予め定めたアプリケーション選別基準に従い、アプリケーションフローの選別機能と、単位時間当たりに個々のアプリケーションフロー対応に性能劣化が発生しているかどうかを判断し、各アプリケーションの種別ごとに、性能劣化が発生したアプリケーションフローの占める性能劣化比率を求めるアプリケーションフロー性能評価機能と、基地局における単位時間当たりの各アプリケーションの利用比率を各アプリケーションフロー数とデータ量から求め、求めたアプリケーションの利用比率と各アプリケーションの性能劣化比率から、予め定めたアプリケーション種別対応の利用比率と性能劣化基準に従い、基地局において性能劣化が発生しているかどうかを判断する基地局のアプリ性能評価機能と、性能劣化が発生していると判断した場合、基地局における単位時間当たりのトータルスループットを、予め定めたアプリケーションの利用比率に応じた基地局における最低保証スループットと比較し、トータルスループットが最低保証スループットより大きい場合、トラヒック輻輳容易運による性能劣化と判断する機能と、トータルスループットが最低保証スループットより小さい場合、基地局におけるハンドオーバ実施回数を予め定めたハンドオーバ実施回数基準値と比較し、その基準値より大きい場合、移動要因による性能劣化と判断し、さらに、基地局における変調符号化方式対応の単位時間当たりの送信データ長から各変調符号化方式の利用比率を求め、求めた変調符号化方式の利用比率と予め定めた変調符号化方式の基準利用比率と比較し、利用比率が異なる場合、端末配置要因による性能劣化と判断する基地局の要因分析機能と、前期機能により検出したアプリケーション利用状況と基地局における性能劣化有無とその要因を結果として表示する結果表示機能とを備える評価装置より、達成できる。
【００１８】
また、音声あるいは映像のデコード処理を行なう端末において、再生時刻における再生フレームなし、あるいは再生フレーム破棄のいずれかを検出した場合、その発生時刻と位置情報を記憶し、端末監視装置に通知し、端末監視装置において、収集した情報からアプリケーション性能劣化が発生していると判断した場合、評価装置に通知し、評価装置において、該当する基地局を求め、上述したアプリケーション性能劣化要因の検出する移動体運用システムにより、達成できる。
【００１９】
また、基地局とゲートウェイ間のパケットより予め定めたアプリケーション選別基準に従い、アプリケーションの選別を行ない、基地局における単位時間当たりの各アプリケーションの利用比率を各アプリケーションフロー数とデータ量から求め、記憶し、アプリケーション利用比率が以前記憶した利用比率と異なる場合、求めたアプリケーション利用比率を基地局あるいはゲートウェイに通知し、基地局あるいはゲートウェイにおいて、予めアプリケーション利用率対応に定めたトラヒック流量に従い、基地局あるいはゲートウェイにおいてトラヒック流入制御を行なうトラヒック監視方法により、達成できる。
【００２０】
また、計算した単位時間当たりのアプリケーション利用比率を、予め定めたアプリケーション利用組合せパターンのいずれかに分類し、そのパターンを記憶し、記憶しているパターンから変化した場合、求めたアプリケーション利用組合せパターンを基地局あるいはゲートウェイに通知し、基地局あるいはゲートウェイにおいて、予めアプリケーション利用組合せパターン対応に定めたトラヒック流量に従い、基地局あるいはＧＷにおいてトラヒック流入制御を行なうトラヒック監視方法により、達成できる。
【００２１】
また、基地局とゲートウェイ間のパケットを監視するパケット監視装置と、パケット監視装置が抽出したパケットより、予め定めたアプリケーション選別基準に従い、アプリケーションフローの選別を行ない、単位時間当たりに個々のアプリケーションフロー対応に性能劣化が発生しているかどうかを判断するアプリフロー選別・性能評価機能と、各アプリケーションの種別ごとに、性能劣化が発生したアプリケーションフローの占める性能劣化比率を求め、基地局における単位時間当たりの各アプリケーションの利用比率を各アプリケーションフロー数とデータ量から求め、求めた利用比率と各アプリケーションにおける性能劣化比率から、予め定めたアプリケーション種別対応の利用比率と性能劣化基準に従い、基地局において性能劣化が発生しているかどうかを判断する基地局アプリ評価機能と、基地局における単位時間当たりのトータルスループットを、予め定めた利用比率に応じた基地局における最低保証スループットと比較し、トータルスループットが最低保証スループットより大きい場合、トラヒック輻輳要因による性能劣化と判断し、トータルスループットが最低保証スループットより小さい場合、基地局におけるハンドオーバ実施回数を予め定めたハンドオーバ実施回数基準値と比較し、その基準値より大きい場合、移動要因による性能劣化と判断し、さらに、基地局における変調符号化方式対応の単位時間当たりの送信データ長から各変調符号化方式の利用比率を求め、求めた変調符号化方式の利用比率と予め定めた変調符号化方式の基準利用比率と比較し、利用比率が異なる場合、端末配置要因による性能劣化と判断する基地局の要因分析機能とからなるアプリケーション評価機能を備えた評価装置と、移動体通信システム内の機器を管理制御する管理装置、移動体通信システム内の機器からの統計情報を格納するストレージおよび保守員の操作するオペレータ端末とから構成する移動体運用システムより、達成できる。
【００２２】
また、パケット監視装置、アプリケーション評価装置、管理装置、ストレージ、オペレータ端末および端末からマルチメディア再生における性能劣化情報を収集する端末性能監視サーバとから構成する移動体運用システムにより、達成できる。
【発明の効果】
【００２３】
移動体通信システムにおいて、多様なアプリケーションを利用している端末を収容している基地局におけるアプリケーション性能劣化とその要因を分析し、表示することにより、保守員における問題の把握と無線エリアの最適化を容易に実現できる環境を提供できる。
【図面の簡単な説明】
【００２４】
【図１】移動体通信システムとその運用管理システムの構成図である。
【図２】評価装置の機能ブロック図である。
【図３】端末の機能ブロック図である。
【図４】端末監視装置の機能ブロック図である。
【図５】アプリケーション評価処理の流れを示す図である。
【図６】パケット監視装置におけるパケット監視処理の処理フローである。
【図７】オペレータポリシであるアプリフロー選別基準の構成を示すテーブルである。
【図８】オペレータポリシであるアプリフロー性能劣化基準の構成を示すテーブルである。
【図９】評価装置が実施するアプリフロー選別・性能評価処理の処理フローである。
【図１０】評価結果エントリの構成を示すテーブルである。
【図１１】オペレータポリシである基地局のアプリ比率パターンの構成を示すテーブルである。
【図１２】オペレータポリシである基地局の性能劣化基準の構成を示すテーブルである。
【図１３】評価装置が実施する基地局の性能評価処理の処理フローである。
【図１４】オペレータポリシである基地局の最低保証スループットの構成を示すテーブルである。
【図１５】基地局統計情報の構成を示すテーブルである。
【図１６】オペレータポリシである基地局の無線帯域利用基準の構成を示すテーブルである。
【図１７】評価装置が実施する基地局の要因分析処理を示す処理フローである。
【図１８】評価装置が実施する要因分析案検討処理の処理フローである。
【図１９】アプリケーション評価処理のマップ表示結果である。
【図２０】基地局のアプリ利用状況を表示した結果である。
【図２１】基地局のアプリ性能劣化と要因分析結果を表示した結果である。
【図２２】端末が実施するデコード処理の処理フローである。
【図２３】端末監視装置における端末監視処理の処理フローである。
【発明を実施するための形態】
【００２５】
以下、本発明の実施の形態について、実施例を用い図面を参照しながら、詳細に説明する。なお、実質同一部位には同じ参照番号を振り、説明は繰り返さない。
【００２６】
図１を参照して、移動体通信システムとその運用管理システム１００の構成を説明する。図１において、移動体通信システムは、端末６００と、基地局１０９と、ネットワークスイッチ（以下ＳＷ）１１５と、サービングゲートウェイ（以下Ｓ−ＧＷ）１１０、と、認証サーバ１１１と、ホームエージェント（以下ＨＡ）１１２とから構成されている。
【００２７】
基地局１０９（１０９Ａ、１０９Ｂ）は、複数の端末６００を無線で接続し収容する。Ｓ−ＧＷ１１０は、複数基地局１０９と接続し、ハンドオーバ管理などを行なう。認証サーバ１１１、端末との認証を行なう。ＨＡ１１２は、異種移動体通信システムや事業者の異なる移動体通信システムとの移動管理を行なう。ＳＷ１１５（１１５Ａ〜１１５Ｂ）は、各機器を接続する。
【００２８】
移動体通信システムは、パケットゲートウェイ（以下Ｐ−ＧＷ）１１３を介して、オペレータの固定ＩＰネットワーク１１４に接続している。
移動体管理システムの運用管理システム１００は、エレメントマネージメントシステム（以下ＥＭＳ）１０５（１０５Ａ、１０５Ｂ）と、ネットワークエレメントマネジャー（以下ＮＥＭ）１０６と、ストレージ１０４と、端末監視装置１０３と、パケット監視装置１０２と、評価装置７００と、ＳＷ１１５Ｃと、オペレータ端末１０７とから構成されている。
【００２９】
ＥＭＳ１０５は、基地局１０９およびＳ−ＧＷ１１０から統計情報を収集し、各機器へのパラメータを設定するなどの管理機能を提供する。ＮＥＭ１０６は、複数ＥＭＳを統括管理する。ストレージ１０４は、収集した統計情報を格納する。端末監視装置１０３は、端末６００からのアプリケーション性能劣化情報を収集する。パケット監視装置１０２は、基地局１０９とＳ−ＧＷ１１０間のトラヒックを監視する。評価装置７００は、アプリケーション性能を評価する。オペレータ端末１０７は、運用管理システム１００内の各機器にアクセスするための保守員が操作する。
【００３０】
図２を参照して、評価装置７００の構成を説明する。図２において、評価装置７００は、制御部１１６と、記憶部１１７と、ネットワークインタフェース部１１８とから構成されている。制御部１１６は、記憶部１１７に格納されているプログラムであるアプリフロー選別・性能評価処理２１０、基地局のアプリ性能評価処理２２０、基地局の要因分析処理２３０、要因分析案提示処理２４０、結果表示処理１１９を実行する。記憶部１１７には、プログラムに加えて、評価結果エントリ１２０と、オペレータポリシ１２５とを記憶する。
【００３１】
評価結果エントリ１２０は、処理に用いる。オペレータポリシ１２５は、基準値である。オペレータポリシ１２５は、アプリフロー選別基準１４０、アプリフロー性能劣化基準１５０、基地局のアプリ性能劣化基準１６０、基地局のアプリ比率パターン１７０、基地局の最低保証スループット１８０、基地局の無線帯域利用基準１９０を持つ。
【００３２】
図３を参照して、端末６００の構成を説明する。図３において、端末６００は、制御部６１０と、記憶部６２０と、ネットワークインタフェース部６３０と、ユーザ入力インタフェース部６４０と、表示ディスプレイ６５０とで構成されている。制御部６１０は、記憶部６２０に格納されているプログラムであるコード処理６１１を実行する。記憶部６２０は、プログラムに加えて、再生コンテンツ６２１、アプリ品質情報６２２を記憶する。ネットワークインタフェース部６３０は、基地局１０９とのインタフェース部である。
【００３３】
図４を参照して、端末監視装置７００の構成を説明する。図４において、端末監視装置７００は、制御部７１０と、記憶部７２０と、ネットワークインタフェース部７３０とから構成されている。制御部７１０は、記憶部７２０に格納されているプログラムである端末監視処理７１１を実行する。記憶部７２０は、プログラムに加えて、アプリ品質情報７２１を記憶する。
【００３４】
図５を参照して、評価装置７００が実施するアプリケーション評価処理２００を説明する。図５において、評価装置７００は、パケット監視装置１０２が実施するパケット監視処理２５０と、端末監視装置１０３が実施する端末監視処理２８０を受けて、アプリケーション評価処理２００を実行する。評価装置７００において、アプリケーション評価処理２００は、以下のステップで処理を行なう。評価装置７００は、第１のステップのアプリフロー選別・性能評価処理２１０として、パケット監視装置１０２から通知されたパケットから、アプリケーション選別と個々のアプリケーションの性能評価を行なう。評価装置７００は、第２ステップの基地局１０９のアプリ評価処理２２０として、アプリケーション性能劣化が、処理フローに個々依存しているものであるのか、基地局１０９全体に及んだ問題であるのかの切り分けを行なう。評価装置７００は、第３ステップの基地局の要因分析処理２３０として、基地局１０９においてトラヒック輻輳要因によりアプリケーション性能劣化が発生しているかどうか、さらに基地局１０９における端末６００の移動要因、あるいは端末６００の配置要因によりアプリケーションの性能劣化が発生しているかどうかを確認する。評価装置７００は、第４ステップの要因分析案検討処理２４０として、第３ステップで要因が明らかにならなかった場合、保守員が対応すべき行動推奨案を検討する。評価装置７００は、第５ステップの結果表示処理１１９において、各ステップで得た結果を表示する。保守員は、この結果を見て解析を行ない、基地局設定変更や基地局増設などを検討し、システムの最適化を実施する。
【００３５】
以下、各処理の詳細について説明していく。
図６を参照して、パケット監視装置１０２におけるパケット監視処理２５０の処理フローを説明する。図６において、パケット監視装置１０２は、第１ステップとして、Ｓ−ＧＷ１１０と基地局間１０９を通過するパケットをキャプチャし、キャプチャした時刻をタイムスタンプとして記憶する（Ｓ２５１）。パケット監視装置１０２は、第２ステップとして、キャプチャしたパケットから、ＩＰパケットを抽出し、Ｓｏｕｒｃｅ ＩＰアドレスとポート番号、Ｄｅｓｔｉｎａｔｉｏｎ ＩＰアドレスとポート番号、ＩＰパケットからＩＰヘッダを除いたデータ長、トランスポートプロトコル種別、タイムスタンプ、Ｓ−ＧＷ１１０と基地局間１０９のパス識別子、Ｓ−ＧＷ１１０と基地局１０９間のパケット通信方向といった情報をパケットエントリとして記憶する（Ｓ２５２）。パケット監視装置１０２は、第３ステップとして、単位時間が経過しているかどうかを確認する（Ｓ２５３）。経過していなければ（ＮＯ）、パケット監視装置１０２は、ステップ２５１に戻って、このパケットキャプチャとパケットエントリ作成処理を単位時間の間実施する。ステップ２５３で単位時間が経過していれば（ＹＥＳ）、パケット監視装置１０２は、第４のステップとして、記憶したパケットエントリをアプリケーション評価装置に転送して（Ｓ２５４）、終了する。なお、パケットエントリの情報は、ストレージ１０４を介して、パケット監視装置１０２と評価装置７００で共有してもよい。
【００３６】
以下、評価装置７００が実施するアプリフロー選別・性能評価処理２００の詳細について説明する。
【００３７】
図７を参照して、アプリフロー選別・性能評価処理２１０を実施する際に利用するオペレータポリシとして、事前に定めておくアプリフロー選別基準１４０の構成を説明する。図７において、アプリフロー選別基準１４０のテーブルは、アプリフロー種別１４１、トランスポートプロトコル種別１４２、通信方向１４３、分類条件１４４から構成されている。
【００３８】
トランスポートプロトコル種別１４２は、ＴＣＰあるいはＵＤＰを表示する。通信方向１４３は、Ｓ−ＧＷ１１０から基地局１０９方向のダウンリンク（以下ＤＬ）または基地局１０９からＳ−ＧＷ方向のアップリンク（ＵＬ）を示す。分類条件１４４は、パケットからアプリを選別する際の分類条件である。ここでは、アプリフロー種別１４１は、ＶｏＩＰタイプ、動画タイプ、ダウンロードタイプ、アップロードタイプ、制御タイプを、分類条件１４４は、データ長とパケット間隔として示している。
【００３９】
図８を参照して、アプリフロー選別・性能評価処理２１０を実施する際に利用するオペレータポリシとして、事前に定めておくアプリフロー性能劣化基準１５０の構成を説明する。図８において、アプリフロー性能劣化基準１５０は、アプリフロー種別１５１と性能劣化基準１５２から構成する。ここでは、性能劣化基準１５２は、パケット間隔とその発生頻度および平均スループットとして示している。
【００４０】
図９を参照して、評価装置７００が実施するアプリフロー選別・性能評価処理２１０の処理フローを説明する。図９において、評価装置７００は、第１ステップとして、パケット監視装置１０２から通知されたパケットエントリを読出す（Ｓ２１１）。評価装置７００は、第２ステップとして、読み出したパケットエントリの情報から、アプリケフロー選別基準１４０に従って、アプリケーションの選別を行なう（Ｓ２１２）。さらに、評価装置７００は、第３ステップとして、各アプリフローにおいて、アプリケーションの性能劣化が発生しているかを確認するため、周期的にパケットをやり取りするＶｏＩＰタイプと動画タイプであるかを確認する（Ｓ２１３）。ＶｏＩＰタイプあるいは動画タイプである場合（ＹＥＳ）、評価装置７００は、第４ステップとして、アプリフロー性能劣化基準１５０に従って、パケット間隔が基準値よりも大きいかどうかをチェックし、大きい場合パケット受信間隔違反回数として、アプリフロー毎に記憶する（Ｓ２１３）。さらに、評価装置７００は、第５ステップとして、単位時間当りのパケットエントリの処理が完了しているかどうかを確認する（Ｓ２１５）。完了していなければ、評価装置７００は、ステップ２１１に遷移する。ステップ２１５で完了していれば、評価装置７００は、第６ステップとして、アプリフロー毎にパケット受信間各違反の頻度、平均スループットを求め、アプリフロー性能劣化基準１５０の基準値と比較し、アプリフロー毎に性能劣化が発生しているかを判断し、その結果をアプリフロー毎に記憶する（Ｓ２１６）。評価装置７００は、第７ステップとして、評価結果エントリ１２０を作成して（Ｓ２１７）、終了する。なお、ステップ２１３でＮＯのとき、ステップ２１４をジャンプする。
【００４１】
図１０を参照して、単位時間毎に評価装置７００がアプリフロー選別、性能評価処理２１０のステップ２１７で作成する評価結果エントリ１２０の構成を説明する。図１０において、評価結果エントリ１２０は、時刻１２１、単位時間当たりのダウンリンクとアップリンクのそれぞれのトータルデータ長１２２（１２２Ａ、１２２Ｂ）、アプリケーション種別と通信方向対応に纏めるアプリケーション情報エリア１３０（１３０Ａ、１３０Ｂ）と、選別できなかったアプリである非選別アプリのデータ量比率１２３および「基地局における性能劣化」時の要因を記録するエリア１２４から構成する。アプリケーション情報エリア１３０は、同一種類、同一通信方向のアプリフロー別に、アプリフロー種別１３１、トータルデータ長１３２、該当アプリフロー数１３３、通信方向１３４、単位時間当たりのアプリケーション利用比率を示すアプリフロー比率１３５、アプリデータ量比率１３６、プリフロー毎に性能劣化と判断したアプリフローの総数を示すアプリフロー数１３７およびそのアプリフロー識別情報１３８、アプリフローにおける性能劣化要因を記録するエリア１３９から構成する。
【００４２】
次に評価装置７００で行なう基地局の性能評価処理２２０の詳細について説明する。
図１１を参照して、基地局の性能評価処理２２０を実施する際に利用するオペレータポリシとして、事前に定めておく基地局のアプリ比率パターン１７０の構成を説明する。図１１において、基地局７００のアプリ比率パターン１７０は、アプリ比率パターン１７１対応にアプリ比率１７２を定めているものであり、アプリ比率１７２のエリアとしては、通信方向とアプリフロー種別のアプリ比率から構成する。
【００４３】
図１２を参照して、基地局の性能評価処理２２０を実施する際に利用するオペレータポリシとして、事前に定めておく基地局のアプリ性能劣化基準１６０の構成を説明する。図１２において、基地局のアプリ性能劣化基準１６０は、アプリフロー種別１６１対応のアプリケーション性能劣化基準１６２を定めたものである。アプリケーション性能劣化基準１６２は、アプリ比率とそのアプリ比率を満たしている場合の性能劣化基準として、各アプリ種別１６１における性能劣化検出したアプリフローの割合として性能劣化比率を示す。
【００４４】
図１３を参照して、評価装置７００で行なう基地局の性能評価処理２２０の処理フローを説明する。図１３において、評価装置７００は、第１ステップとして、評価結果エントリ１２０の合計データ長１２２と各アプリケーション情報エリア１３０の合計データ長１３２から（式１）を用いて、アプリフロー別のアプリデータ量比率を求める（Ｓ２２１）。
【００４５】
(アプリフロー別データ量比率)
＝(アプリケーション情報エリアの合計データ長)/(評価結果エントリの合計データ長)
…(式１)
評価装置７００は、第２ステップとして、求めたデータ比率を、評価エントリ１２０のアプリケーション情報エリア１３０のアプリデータ量比率１３６として格納する（Ｓ２２２）。評価装置７００は、第３ステップとして、アプリフローを選別できなかったアプリデータ量比率を（式２）から求め、評価結果エントリ１２０の非アプリ選別のデータ量比率１２３に格納する（Ｓ２２３）。
【００４６】
(非アプリ選別のデータ量比率)＝１−Σ(アプリフロー別データ量比率) …(式２)
評価装置７００は、第４ステップとして、各アプリケーション情報エリア１３０のアプリフロー数１３３から（式３）を用いてアプリフロー率を求める（Ｓ２２４）。
【００４７】
(アプリフロー率)
=(アプリケーション情報のアプリフロー数)/Σ(アプリケーション情報のアプリフロー数)
…(式３)
評価装置７００は、第５ステップとして、各アプリフロー率と非アプリ選別のデータ量比率から（式４）を用いて、アプリフロー比率を求め、評価結果エントリ１２０のアプリケーション情報エリア１３０のアプリフロー比率１３７として格納する（Ｓ２２５）。
【００４８】
(アプリフロー比率)
＝(１−(非アプリ選別のデータ量比率))＊(アプリフロー率) …(式４)
評価装置７００は、第６ステップとして、求めたアプリデータ量比率１３６とアプリフロー比率１３７から、基地局のアプリ比率パターン１７０に従って、対応するパターンを検出する（Ｓ２２６）。評価装置７００は、第７ステップとして、前回の評価処理時に検出したパターンと変化しているか判定する（Ｓ２２７）。変化している場合（ＹＥＳ）、評価装置７００は、第８ステップとして、該基地局１０９とその基地局１０９に接続しているＳ−ＧＷ１１０に対して検出したアプリ比率パターンを通知する（Ｓ２２８）。
【００４９】
ステップ２２７でＮＯのとき、またはステップ２２８の後、評価装置７００は、第９ステップとして、基地局のアプリ性能劣化基準１６０に従って、アプリ種別対応に性能劣化が基地局１０９全体に及んでいるかどうかを、アプリ種別対応に性能劣化を検出したアプリフロー数から求める性能劣化比率と基地局のアプリ性能劣化基準１６０の性能劣化基準値と比較して確認して（Ｓ２２９）、終了する。ステップ２２９により、性能劣化が基地局１０９全体に及んでいないと判断した場合、評価装置７００は、評価結果エントリ１２０のアプリケーション情報エリア１３０の要因１３９に「アプリフローによる」と記録する。基地局１０９における性能劣化が発生していると判断した場合、評価装置７００は、評価結果エントリ１２０のアプリケーション情報エリア１３０の要因１３９に「基地局における性能劣化」を記録する。
【００５０】
ステップ２２８において、アプリ比率パターンを通知された基地局１０９またはＳ−ＧＷ１１０は、予め定められているアプリ比率パターン対応に定められているトラヒック制御を実施するアプリフロー対応の閾値を参照して、トラヒック流入制御を行なう。さらに、ステップ２２８において、アプリ比率パターンを通知された基地局１０９は、端末６００に対して、現状のネットワーク利用状況として、アプリ比率パターンと各アプリケーションのトラヒックと閾値との関係を通知し、端末６００において通知された情報を図示して表示してもよい。
【００５１】
以下、ステップ２２９において、基地局１０９において性能劣化が発生していると確認した場合、つまり評価結果エントリ１２０のアプリケーション情報エリア１３０の要因１３９に「基地局における性能劣化」と記録した場合、評価装置７００が行なう基地局の要因分析処理２３０の詳細について説明する。
【００５２】
図１４を参照して、評価装置７００が基地局の要因分析処理２３０を実施する際に利用するオペレータポリシとして、事前に定めておく基地局の最低保証スループット１８０の構成を説明する。図１４において、基地局の最低保証スループット１８０は、図１１で定めたアプリ比率パターン１８１と、それに対応した基地局対応の最低保証スループット１８２から構成する。この基準は、その後、基地局の特徴を反映してもよい。この場合、基地局ごと異なる基準を持つことになる。ここで、基地局の特徴とは、基地局ベンダーごとの実装の違い、ビルが多いまたは見晴らしがよい等の電波環境の違い等である。
【００５３】
図１５を参照して、基地局１０９からＥＭＳ１０５を介してＮＥＭ１０６に周期的に収集され、ストレージ１０４に保存された基地局統計情報２９０の構成を説明する。図１５において、基地局統計情報２９０は、基地局識別子２９１、取得時刻２９２、ハンドオーバ２９３、変調符号化方式２９４から構成されている。ハンドオーバ２９３は、ハンドオーバ実施数とハンドオーバ成功数とからなる。変調符号化方式２９４は、変調符号化方式対応のデータ長の情報である。
【００５４】
図１６を参照して、評価装置７００が劣化要因分析処理を実施する際に利用するオペレータポリシとして、事前に定めておく基地局の無線帯域利用基準１９０の構成を説明する。図１６において、基地局の無線帯域利用基準１９０は、基地局の置局時に想定したハンドオーバ実施回数１９１、一様に端末が配置していると想定した場合の各変調符号化方式の利用比率１９２から構成する。この基準は、その後、基地局における特徴を反映して変更してもよい。この場合、基地局ごとに異なる基準を持つことになる。
【００５５】
図１７を参照して、評価装置７００が行なう基地局の要因分析処理２３０を示す処理フローを説明する。図１７において、評価装置７００は、第１のステップとして、基地局１０９の最低保証スループットに従って、アプリ比率パターンに対応した最低保証スループットと、評価結果エントリ１２０のトータルデータ長１２２から計算したスループットを比較する（Ｓ２３１）。計算したスループットが最低保証スループットより大きい場合（ＮＯ）、評価装置７００は、性能劣化要因をトラヒック輻輳とし，評価結果エントリ１２０の要因エリア１２４に記録して（Ｓ２３２）、終了する。ステップ２３１で小さい場合（ＹＥＳ）、評価装置７００は、第２のステップとして、基地局の無線帯域利用基準１９０のハンドオーバ実施回数１９１と、基地局統計情報２９０のハンドオーバ実施数２９３と比較する（Ｓ２３３）。ハンドオーバ実施数が基地局の無線帯域利用基準１９０のハンドオーバ実施回数より多い場合（ＹＥＳ）、性能劣化要因をハンドオーバ多発とし，評価結果エントリ１２０の要因エリア１２４に記録してする（Ｓ２３４）。ステップ２３３でＹＥＳのとき、またはステップ２３４の後で、さらに、評価装置７００は、第３のステップとして、基地局統計情報２９０の変調符号化方式２９４のそれぞれのデータ長から、それぞれの利用率を求め、基地局の無線帯域利用基準１９０の変調符号化利用比率１９２と比較する（Ｓ２３５）。比率が異なる場合（ＹＥＳ）、評価装置７００は、性能劣化要因を端末配置として，評価結果エントリ１２０の要因エリア１２４に記録して（Ｓ２３６）、終了する。ステップ２３５でＮＯのとき、評価装置７００は、評価結果エントリ１２０の要因エリア１２４に要因不明を記録し，終了する。
【００５６】
次に評価装置７００は、基地局の要因分析処理２３０で要因が検出できていない場合、要因分析案検討処理２４０を行なう。
図１８を参照して、評価装置７００が行なう要因分析案検討処理２４０の処理フローを説明する。図１８において、評価装置７００は、第１ステップとして、評価結果エントリ１２０の非選別アプリのデータ量比率１２３が５０％を超えているかどうかを確認する（Ｓ２４１）。超えている場合（ＹＥＳ）、評価装置７００は、第２ステップとして、性能劣化要因として、アプリフロー選別基準見直し要とトラヒック再分析要とし，評価結果エントリ１２０の要因エリア１２４に記録して（Ｓ２４２）、終了する。ここでは、評価装置７００は、保守員によるパケットの詳細分析により、新たなアプリケーション利用が増えていないかどうかを確認することを推奨する。
【００５７】
次に、ステップ２４１で超えていない場合（ＮＯ）、評価装置７００は、アプリフロー毎にアプリケーションの性能劣化を検出したアプリフローの通信先の同一率が５０％を越えているかどうかを確認する（Ｓ２４３）。超えている場合、評価装置７００は、第４ステップとして、性能劣化要因をサーバ側負荷確認要とし，評価結果エントリ１２０の要因エリア１２４に記録して（Ｓ２４４）、終了する。ここでは、評価装置７００は、アプリケーションサーバ側の負荷が高い可能性があるので、サーバ側の負荷を確認するように推奨する。
【００５８】
次に、ステップ２４３でＮＯのとき、評価装置７００は、第５ステップとして、性能劣化要因が解析できていない状況が連続しているかを確認する（Ｓ２４５）。続いている場合（ＹＥＳ）、評価装置７００は、第６ステップとして、性能劣化要因をアプリ性能劣化要因不明連続発生として（Ｓ２４６）、終了する。ここでは、評価装置７００は、保守員に対して、基地局状態、ネットワーク状態の確認を推奨し、原因の究明を進める。ステップ２４５でＮＯのとき、評価装置７００は、そのまま終了する。
【００５９】
以下、評価装置７００において、結果表示処理１１９において作成する、オペレータ端末１０７に表示する表示結果について説明する。
図１９を参照して、アプリケーション評価処理結果３００を説明する。図１９において、アプリケーション評価処理結果３００は、アイコン３０１と、マップ表示結果３０２と、解析結果３０３とからなる。アイコン３０１は、表示期間を選択する。マップ表示結果３０２は、選択した表示期間の基地局における性能劣化要因をマップ表示する。表示期間３０１は、マップ表示結果３０２と解析結果３０３を表示する日時と期間を選択するものである。図１９では、期間は、３時間単位、１日単位、１週間単位で可能である。マップ表示結果３０２は、基地局１０９対応に表示期間３０１で指定された期間において、性能劣化要因ごとにマップ上に表示するものである。２つ以上の性能劣化要因がある場合は、重複した発生がわかるように表示する。図１９では、トラヒック輻輳とハンドオーバの性能劣化要因が重複発生している基地局１０９を示している。解析結果３０３は、マップ表示結果３０２の性能劣化要因を示すとともに、保守員に対して推奨する行動を示す。
【００６０】
トラヒック輻輳発生の場合、基地局１０９におけるトラヒック量の確認および周囲の基地局１０９のロードバランスの確認を推奨する。この結果として、トラヒック量に耐えられないエリアであると判断した場合、保守員は基地局１０９におけるハンドオーバ閾値のパラメータを変更や、基地局増設の実施を検討することになる。ハンドオーバが多発している場合、基地局のロードバランスの確認および周囲の基地局１０９がカバーしている範囲の変更検討を推奨する。この結果として、保守員は基地局１０９におけるハンドオーバ閾値のパラメータ変更やアンテナチルドの変更の実施を検討することになる。端末配置不均等発生の場合、周囲の基地局１０９のロードバランスの確認および基地局１０９に想定している処理性能の見直しを推奨する。この結果、保守員は基地局１０９におけるハンドオーバ閾値のパラメータ変更や、アンテナチルドの変更、基地局１０９に接続する端末６００の配置を考慮した基地局１０９の許容トラヒックを以前より小さく設定するように基地局関連の制御パラメータを設定の実施を検討することになる。アプリ選別がきていないトラヒック多発する場合、新たなアプリケーションの利用により、新たなトラヒックが発生している可能性があることから、トラヒック分析を行なうことを推奨する。保守員によるトラヒック分析により、新たなアプリケーションが利用されているようであれば、オペレータポリシにアプリフローとして追加する。アプリ性能劣化要因不明連続発生の場合、基地局状態とネットワーク状態を確認することを推奨する。保守員は、基地局１０９にアプリケーション評価処理２００では見つけられてない問題、例えばハードの不調や、ネットワーク内での輻輳発生など、他の問題と関連付けて原因を究明する必要がある。
【００６１】
図２０を参照して、保守員の上述した作業を補助するための基地局毎のアプリ利用状況の表示結果３０４を説明する。図２０において、表示情報は、日か週で選択する表示期間３０６、ダウンロードとアップロードのアプリフローごとのスループット変動と、アプリ比率変動３０５からなる。この結果より、保守員が日々のユーザのアプリケーション利用傾向を把握することを助ける。
【００６２】
図２１を参照して、保守員の作業を補助するための基地局におけるアプリ性能劣化と要因分析結果３０７を説明する。図２１において、基地局におけるアプリ性能劣化と要因分析結果３０７の表示情報は、アップロードとダウンロードのトラヒック選択アイコン３０８と、１週間の結果を日単位に、ダウンロードとアップロードを別のアプリフロー別のトラヒック変動３０９（３０９Ａ、３０９Ｂ）からなる。トラヒック変動の結果上にアプリケーション性能評価により検出したアプリケーション性能劣化ポイントと分析した要因を表示する。日単位の結果を同時に表示することにより、保守員が日々の傾向を把握することを助ける。
【００６３】
以下、端末６００におけるアプリケーション性能劣化検出方法について説明する。
図２２を参照して、端末６００におけるアプリケーションの品質劣化を検出するデコード処理２６０の処理フローを説明する。図２２において、デコード処理２６０は、端末６００がＶｏＩＰや映像の再生といったアプリケーションを使用している場合、音声フレームや映像フレームのデコード処理中に品質劣化を検出する処理である。デコード処理２６０において、端末６００は、第１ステップとして、デコード処理停止あるいは一定時間が経過しているかを確認する（Ｓ２６１）。デコード処理停止や一定時間経過していない場合（ＮＯ）、端末６００は、第２ステップとして、音声フレームや映像フレームの再生時刻となっているかを確認する（Ｓ２６２）。再生時刻となっている場合（ＹＥＳ）、端末６００は、第３ステップとして、再生フレームの有無を確認する（Ｓ２６３）。再生フレームがある場合、端末６００は、第４ステップとして、再生時刻が再生フレームの持つ再生時刻より前か判定する（Ｓ２６４）。ＮＯのとき、端末６００は、再生時刻と再生フレームの持つ再生時刻が一致していることを確認する（Ｓ２６５）。ＹＥＳのとき、端末６００は、第５ステップとして、デコード処理を行なって（Ｓ２６６）、ステップ２６１に遷移する。
【００６４】
再生フレームが無かった場合（Ｓ２６３：ＮＯ）、または再生時刻よりも先を示す再生時刻持つ再生フレームの場合（Ｓ２６４：ＹＥＳ）、端末は６００、第６ステップとして、要因をフレーム無し、発生時刻、発生場所をアプリ品質情報として記録して（Ｓ２６７）、ステップ２６１に遷移する。
【００６５】
ステップ２６５でＮＯのとき、端末６００は、第７ステップとして、再生時刻よりも以前の再生時刻を持つ再生フレームを破棄する（Ｓ２６８）。端末６００は、第８ステップとして、要因をフレーム破棄、発生時刻、発生場所をアプリ品質情報として記録して（Ｓ２６９）、ステップ２６１に遷移する。
【００６６】
ステップ２６１でＹＥＳのとき、端末６００は、第９ステップとして、保存してあるアプリ品質情報を端末監視装置に通知する（Ｓ２７０）。端末６００は、デコード処理を停止するか判定する（Ｓ２７１）。停止するとき、端末６００は、終了する。ステップ２７１で停止しないとき（ＮＯ）、端末６００は、ステップ２６１に遷移する。
このように、端末６００は、デコード処理中の再生フレームの有無と破棄を監視し、それが発生した時刻と発生場所を記憶し、端末監視装置１０３に通知する。
【００６７】
図２３を参照して、アプリ品質情報を受け付けた端末監視装置１０３における端末監視処理２８０の処理フローを説明する。図２３において、端末監視装置１０３は、第１ステップとして、報告されたアプリ品質情報から発生頻度を求め、アプリ性能劣化が発生しているかどうかを、予め定めたフレームロス発生頻度基準と比較して判定する（Ｓ２８１）。アプリ性能劣化を検出した場合（ＹＥＳ）、端末監視装置１０３は、第２ステップとして、アプリ品質情報の発生場所と発生時刻から、ストレージ１０４に格納している基地局６００を設置した置局情報と端末統計情報に含まれる接続基地局の情報を利用して、端末６００が接続していた基地局１０９を抽出する（Ｓ２８２）。端末監視装置１０３は、第３ステップとして、アプリ品質情報の発生場所を基地局の情報に置き換える（Ｓ２８３）。端末監視装置１０３は、第４ステップとして、アプリ性能劣化を検出した対象のアプリ品質情報を評価装置７００へ転送して（Ｓ２８４）、終了する。ステップ２８１でＮＯのとき、端末監視装置１０３は、そのまま終了する。
【００６８】
評価装置７００は、端末監視装置１０３からのアプリ品質情報を受信した後、上述したようにアプリケーション評価処理２００における基地局の性能評価処理２２０、基地局の要因分析処理２３０、要因分析案検討処理２４０、結果表示処理１１９を行なう。評価装置７００は、アプリケーションの性能劣化とその要因の解析結果を保守員に表示する。これにより、評価装置７００は、アプリケーション性能劣化の対応を推奨するとともに、最適化の実施を導いていく。
【符号の説明】
【００６９】
１００…運用管理システム、１０２…パケット監視装置、１０３…端末監視装置、１０４…ストレージ、１０７…オペレータ端末、１０９…基地局、１１０…Ｓ−ＧＷ、６００…端末、７００…評価装置。
【技術分野】
【０００１】
本発明は、移動体通信システム上で利用されるアプリケーション性能評価とその性能劣化検出方法に係り、特に基地局におけるアプリケーション性能劣化要因の検出方法、評価装置および移動体通信システムに関する。
【背景技術】
【０００２】
モバイルデータトラヒックは、著しく増加すると予測されている。これは、ＷｉＭＡＸ（Worldwide Interoperability for Microwave Access）およびＬＴＥ（Long Term Evolution）と呼ばれるモバイルブロードバンド環境が整備されていくことによる。モバイルブロードバンド環境の普及により、アプリケーションは、モバイル事業者が提供していた携帯電話に特化したメール、Ｗｅｂアクセス、音楽などのダウンロードサービスなどから、通常のインターネットサービスであるＷｅｂアクセス、ビデオオンデマンド、ＶｏＩＰ（Voice over IP）さらには個人による動画放送サービスなどへと広がりをみせている。
【０００３】
移動体通信システムの運用では、利用者からの性能に対するクレームが来る前に問題を検出し、先手で対策を実施していくことが、ユーザ満足度向上のために必要である。アプリケーションを利用しているユーザが、その品質が悪化していると感じる場合、その要因の多くは、アプリケーションの通信性能の劣化によるものである。例えば、ユーザがダウンロードを遅いと感じている場合、アプリケーションの通信性能として、スループットが低下している。ＶｏＩＰで瞬断を感じる場合、アプリケーションの通信性能として、遅延が大きくなっている。
【０００４】
移動体通信システムにおいて、利用できるアプリケーションが広がりを見せていることから、単に基地局のトータル性能の監視だけで状態を判断するのではなく、アプリケーションの品質の観点での監視が必要である。このため、基地局における様々なアプリケーション利用の状態を把握し、アプリケーションにおける性能劣化の有無を判断し、その要因が基地局におけるリソース不足であるのか、端末の移動や位置における影響であるのかなど、性能劣化の原因を把握することが、移動体通信システムの最適化では重要になってきている。
【０００５】
一方、移動体通信システムにおいて、アプリケーション性能劣化の要因の一つとして、基地局への膨大なトラヒック流入がある。これを防ぐため、基地局への流入制御が行なわれている。特許文献１で示されている流入制御は、基地局において、トラヒック量を監視し、閾値との比較を行なう。特許文献１は、閾値を超えたトラヒックに対して流入制御を行なうものである。さらに、特許文献２で示されている流入制御は、通信ネットワークおいて、アプリケーションのトラヒック種別を判別する。各アプリケーションのトラヒック量を監視し、各アプリケーションのトラヒックに対応した流入制御を行なう。これにより、利用上で問題の要因となっているアプリケーションのみ制御の対象とする。対象外のアプリケーションに関しては、ネットワークにおけるＱｏＳ（Quality of Service）を保持する。
【０００６】
また、通信ネットワークにおいて、アプリケーションの性能劣化に対して柔軟に制御を行なうために、または要因切り分けのために、アプリケーション性能を監視することが一般的になっている。また、特許文献３は、アプリケーションサーバ性能とネットワーク性能の相関関係から、アプリケーションサーバ、管理対象ネットワーク、非管理対象ネットワークのいずれかに要因を切り分ける。すなわち、対象とするアプリケーショントラヒックと対象外のアプリケーショントラヒック比率の相関関係から、いずれのアプリケーションが性能劣化要因であるかを切り分ける。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開平１０−３３６７３４号公報
【特許文献２】特開２００７−０５３４６５号公報
【特許文献３】特開２００１−１９５２８５号公報
【発明の概要】
【発明が解決しようとする課題】
【０００８】
移動体通信システムにおいて、アプリケーション性能は、基地局におけるトラヒック量による影響、同時に利用する多種のアプリケーションの影響、個々の端末の位置や移動状況の影響などを受ける。
【０００９】
移動体通信システムにおける無線リソースは、複数の端末で共有して利用する。また、アプリケーションによって、パケット長およびパケット送信周期が異なる。この結果、アプリケーションの組合せによって、基地局における最大性能が変わる。また、無線帯域では、端末における基準電力の受信時の大きさにより、通信時の変調符号化方式を選択する。この結果、端末の受信状態、位置や移動状況により、送信スループットに差がでる。さらに、移動体通信システムは、無線帯域における効率良いデータ転送のため、小さいデータのパッキング機能を備えている。このため、一部のアプリケーションにパケットロスや破棄が集中する可能性が高い。また、ＴＣＰ（Transmission Control Protocol）を用いた通信では、パケットロスなどが集中すると、著しく性能が劣化し、性能が元に戻るまでに非常に時間がかかる。
【００１０】
よって、移動体通信は、上述したような影響を考慮して、アプリケーション性能劣化を検出すると共にその要因を分析する必要がある。また、アプリケーション性能劣化が、基地局全体のアプリケーションに波及する要因であるのか、個々アプリケーションフローにだけ出ている要因であるのかを切り分けることも必要である。
【００１１】
特許文献１、特許文献２に示す流入制御では、基地局全体のトラヒック量、あるいは通信システムにおける個々のアプリのトラヒック量のみに着目している。その結果、トラヒック量以外の上述した移動体通信システム特有の影響を考慮できない。
【００１２】
特許文献３に示すアプリケーション性能劣化要因の分析は、アプリケーションを意識している。しかし、有線におけるトラヒック量に着目した性能劣化要因の判断であり、上述した移動体通信システム特有の影響を考慮していない。
【００１３】
本発明の目的は、移動体通信システムにおいて、上述した課題を解決し、多様なアプリケーションを利用している端末を収容している基地局において、アプリケーション性能劣化の有無を判断し、基地局全体に及んだ問題であるのか、個々のアプリケーションのフローの問題であるのかを切り分けることである。
【００１４】
さらに他の目的は、アプリケーション性能劣化の要因を輻輳状態であるのか、端末の移動が多いことによるのか、端末の位置に問題があるのか、基地局以外に問題あるのかを切り分けを行ない、検出した結果として、基地局毎のアプリケーション利用状況、アプリケーション性能状態、劣化要因、保守員に求める対処の表示を提供することである。
さらに他の目的は、アプリケーション利用状況を考慮した流入制御を提供することである。
【課題を解決するための手段】
【００１５】
上述した課題は、基地局とゲートウェイ間のパケットを監視し、パケットより、予め定めたアプリケーション選別基準に従い、アプリケーションフローの選別を行ない、単位時間当たりに個々のアプリケーションフロー対応に性能劣化が発生しているかどうかを判断し、各アプリケーションの種別ごとに、性能劣化が発生したアプリケーションフローの占める性能劣化比率を求め、基地局における単位時間当たりの各アプリケーションの利用比率を各アプリケーションフロー数とデータ量から求め、求めた利用比率と各アプリケーションにおける性能劣化比率から、予め定めたアプリケーション種別対応の利用比率と性能劣化基準に従い、基地局において性能劣化が発生しているかどうかを判断するアプリケーション性能劣化を検出するアプリケーション評価方法により、達成できる。
【００１６】
また、基地局においてアプリケーション性能劣化が発生していると判断した場合、基地局における単位時間当たりのトータルスループットを、予め定めたアプリケーションの利用比率に応じた基地局における最低保証スループットと比較し、トータルスループットが最低保証スループットより大きい場合、トラヒック輻輳要因による性能劣化と判断し、トータルスループットが最低保証スループットより小さい場合、基地局におけるハンドオーバ実施回数を予め定めたハンドオーバ実施回数基準値と比較し、その基準値より大きい場合、移動要因による性能劣化と判断し、さらに、基地局における変調符号化方式対応の単位時間当たりの送信データ長から各変調符号化方式の利用比率を求め、求めた変調符号化方式の利用比率と予め定めた変調符号化方式の基準利用比率と比較し、利用比率が異なる場合、端末配置要因による性能劣化と判断するアプリケーション性能劣化要因を検出するアプリケーション評価方法により、達成できる。
【００１７】
また、基地局とゲートウェイ間のパケットより、予め定めたアプリケーション選別基準に従い、アプリケーションフローの選別機能と、単位時間当たりに個々のアプリケーションフロー対応に性能劣化が発生しているかどうかを判断し、各アプリケーションの種別ごとに、性能劣化が発生したアプリケーションフローの占める性能劣化比率を求めるアプリケーションフロー性能評価機能と、基地局における単位時間当たりの各アプリケーションの利用比率を各アプリケーションフロー数とデータ量から求め、求めたアプリケーションの利用比率と各アプリケーションの性能劣化比率から、予め定めたアプリケーション種別対応の利用比率と性能劣化基準に従い、基地局において性能劣化が発生しているかどうかを判断する基地局のアプリ性能評価機能と、性能劣化が発生していると判断した場合、基地局における単位時間当たりのトータルスループットを、予め定めたアプリケーションの利用比率に応じた基地局における最低保証スループットと比較し、トータルスループットが最低保証スループットより大きい場合、トラヒック輻輳容易運による性能劣化と判断する機能と、トータルスループットが最低保証スループットより小さい場合、基地局におけるハンドオーバ実施回数を予め定めたハンドオーバ実施回数基準値と比較し、その基準値より大きい場合、移動要因による性能劣化と判断し、さらに、基地局における変調符号化方式対応の単位時間当たりの送信データ長から各変調符号化方式の利用比率を求め、求めた変調符号化方式の利用比率と予め定めた変調符号化方式の基準利用比率と比較し、利用比率が異なる場合、端末配置要因による性能劣化と判断する基地局の要因分析機能と、前期機能により検出したアプリケーション利用状況と基地局における性能劣化有無とその要因を結果として表示する結果表示機能とを備える評価装置より、達成できる。
【００１８】
また、音声あるいは映像のデコード処理を行なう端末において、再生時刻における再生フレームなし、あるいは再生フレーム破棄のいずれかを検出した場合、その発生時刻と位置情報を記憶し、端末監視装置に通知し、端末監視装置において、収集した情報からアプリケーション性能劣化が発生していると判断した場合、評価装置に通知し、評価装置において、該当する基地局を求め、上述したアプリケーション性能劣化要因の検出する移動体運用システムにより、達成できる。
【００１９】
また、基地局とゲートウェイ間のパケットより予め定めたアプリケーション選別基準に従い、アプリケーションの選別を行ない、基地局における単位時間当たりの各アプリケーションの利用比率を各アプリケーションフロー数とデータ量から求め、記憶し、アプリケーション利用比率が以前記憶した利用比率と異なる場合、求めたアプリケーション利用比率を基地局あるいはゲートウェイに通知し、基地局あるいはゲートウェイにおいて、予めアプリケーション利用率対応に定めたトラヒック流量に従い、基地局あるいはゲートウェイにおいてトラヒック流入制御を行なうトラヒック監視方法により、達成できる。
【００２０】
また、計算した単位時間当たりのアプリケーション利用比率を、予め定めたアプリケーション利用組合せパターンのいずれかに分類し、そのパターンを記憶し、記憶しているパターンから変化した場合、求めたアプリケーション利用組合せパターンを基地局あるいはゲートウェイに通知し、基地局あるいはゲートウェイにおいて、予めアプリケーション利用組合せパターン対応に定めたトラヒック流量に従い、基地局あるいはＧＷにおいてトラヒック流入制御を行なうトラヒック監視方法により、達成できる。
【００２１】
また、基地局とゲートウェイ間のパケットを監視するパケット監視装置と、パケット監視装置が抽出したパケットより、予め定めたアプリケーション選別基準に従い、アプリケーションフローの選別を行ない、単位時間当たりに個々のアプリケーションフロー対応に性能劣化が発生しているかどうかを判断するアプリフロー選別・性能評価機能と、各アプリケーションの種別ごとに、性能劣化が発生したアプリケーションフローの占める性能劣化比率を求め、基地局における単位時間当たりの各アプリケーションの利用比率を各アプリケーションフロー数とデータ量から求め、求めた利用比率と各アプリケーションにおける性能劣化比率から、予め定めたアプリケーション種別対応の利用比率と性能劣化基準に従い、基地局において性能劣化が発生しているかどうかを判断する基地局アプリ評価機能と、基地局における単位時間当たりのトータルスループットを、予め定めた利用比率に応じた基地局における最低保証スループットと比較し、トータルスループットが最低保証スループットより大きい場合、トラヒック輻輳要因による性能劣化と判断し、トータルスループットが最低保証スループットより小さい場合、基地局におけるハンドオーバ実施回数を予め定めたハンドオーバ実施回数基準値と比較し、その基準値より大きい場合、移動要因による性能劣化と判断し、さらに、基地局における変調符号化方式対応の単位時間当たりの送信データ長から各変調符号化方式の利用比率を求め、求めた変調符号化方式の利用比率と予め定めた変調符号化方式の基準利用比率と比較し、利用比率が異なる場合、端末配置要因による性能劣化と判断する基地局の要因分析機能とからなるアプリケーション評価機能を備えた評価装置と、移動体通信システム内の機器を管理制御する管理装置、移動体通信システム内の機器からの統計情報を格納するストレージおよび保守員の操作するオペレータ端末とから構成する移動体運用システムより、達成できる。
【００２２】
また、パケット監視装置、アプリケーション評価装置、管理装置、ストレージ、オペレータ端末および端末からマルチメディア再生における性能劣化情報を収集する端末性能監視サーバとから構成する移動体運用システムにより、達成できる。
【発明の効果】
【００２３】
移動体通信システムにおいて、多様なアプリケーションを利用している端末を収容している基地局におけるアプリケーション性能劣化とその要因を分析し、表示することにより、保守員における問題の把握と無線エリアの最適化を容易に実現できる環境を提供できる。
【図面の簡単な説明】
【００２４】
【図１】移動体通信システムとその運用管理システムの構成図である。
【図２】評価装置の機能ブロック図である。
【図３】端末の機能ブロック図である。
【図４】端末監視装置の機能ブロック図である。
【図５】アプリケーション評価処理の流れを示す図である。
【図６】パケット監視装置におけるパケット監視処理の処理フローである。
【図７】オペレータポリシであるアプリフロー選別基準の構成を示すテーブルである。
【図８】オペレータポリシであるアプリフロー性能劣化基準の構成を示すテーブルである。
【図９】評価装置が実施するアプリフロー選別・性能評価処理の処理フローである。
【図１０】評価結果エントリの構成を示すテーブルである。
【図１１】オペレータポリシである基地局のアプリ比率パターンの構成を示すテーブルである。
【図１２】オペレータポリシである基地局の性能劣化基準の構成を示すテーブルである。
【図１３】評価装置が実施する基地局の性能評価処理の処理フローである。
【図１４】オペレータポリシである基地局の最低保証スループットの構成を示すテーブルである。
【図１５】基地局統計情報の構成を示すテーブルである。
【図１６】オペレータポリシである基地局の無線帯域利用基準の構成を示すテーブルである。
【図１７】評価装置が実施する基地局の要因分析処理を示す処理フローである。
【図１８】評価装置が実施する要因分析案検討処理の処理フローである。
【図１９】アプリケーション評価処理のマップ表示結果である。
【図２０】基地局のアプリ利用状況を表示した結果である。
【図２１】基地局のアプリ性能劣化と要因分析結果を表示した結果である。
【図２２】端末が実施するデコード処理の処理フローである。
【図２３】端末監視装置における端末監視処理の処理フローである。
【発明を実施するための形態】
【００２５】
以下、本発明の実施の形態について、実施例を用い図面を参照しながら、詳細に説明する。なお、実質同一部位には同じ参照番号を振り、説明は繰り返さない。
【００２６】
図１を参照して、移動体通信システムとその運用管理システム１００の構成を説明する。図１において、移動体通信システムは、端末６００と、基地局１０９と、ネットワークスイッチ（以下ＳＷ）１１５と、サービングゲートウェイ（以下Ｓ−ＧＷ）１１０、と、認証サーバ１１１と、ホームエージェント（以下ＨＡ）１１２とから構成されている。
【００２７】
基地局１０９（１０９Ａ、１０９Ｂ）は、複数の端末６００を無線で接続し収容する。Ｓ−ＧＷ１１０は、複数基地局１０９と接続し、ハンドオーバ管理などを行なう。認証サーバ１１１、端末との認証を行なう。ＨＡ１１２は、異種移動体通信システムや事業者の異なる移動体通信システムとの移動管理を行なう。ＳＷ１１５（１１５Ａ〜１１５Ｂ）は、各機器を接続する。
【００２８】
移動体通信システムは、パケットゲートウェイ（以下Ｐ−ＧＷ）１１３を介して、オペレータの固定ＩＰネットワーク１１４に接続している。
移動体管理システムの運用管理システム１００は、エレメントマネージメントシステム（以下ＥＭＳ）１０５（１０５Ａ、１０５Ｂ）と、ネットワークエレメントマネジャー（以下ＮＥＭ）１０６と、ストレージ１０４と、端末監視装置１０３と、パケット監視装置１０２と、評価装置７００と、ＳＷ１１５Ｃと、オペレータ端末１０７とから構成されている。
【００２９】
ＥＭＳ１０５は、基地局１０９およびＳ−ＧＷ１１０から統計情報を収集し、各機器へのパラメータを設定するなどの管理機能を提供する。ＮＥＭ１０６は、複数ＥＭＳを統括管理する。ストレージ１０４は、収集した統計情報を格納する。端末監視装置１０３は、端末６００からのアプリケーション性能劣化情報を収集する。パケット監視装置１０２は、基地局１０９とＳ−ＧＷ１１０間のトラヒックを監視する。評価装置７００は、アプリケーション性能を評価する。オペレータ端末１０７は、運用管理システム１００内の各機器にアクセスするための保守員が操作する。
【００３０】
図２を参照して、評価装置７００の構成を説明する。図２において、評価装置７００は、制御部１１６と、記憶部１１７と、ネットワークインタフェース部１１８とから構成されている。制御部１１６は、記憶部１１７に格納されているプログラムであるアプリフロー選別・性能評価処理２１０、基地局のアプリ性能評価処理２２０、基地局の要因分析処理２３０、要因分析案提示処理２４０、結果表示処理１１９を実行する。記憶部１１７には、プログラムに加えて、評価結果エントリ１２０と、オペレータポリシ１２５とを記憶する。
【００３１】
評価結果エントリ１２０は、処理に用いる。オペレータポリシ１２５は、基準値である。オペレータポリシ１２５は、アプリフロー選別基準１４０、アプリフロー性能劣化基準１５０、基地局のアプリ性能劣化基準１６０、基地局のアプリ比率パターン１７０、基地局の最低保証スループット１８０、基地局の無線帯域利用基準１９０を持つ。
【００３２】
図３を参照して、端末６００の構成を説明する。図３において、端末６００は、制御部６１０と、記憶部６２０と、ネットワークインタフェース部６３０と、ユーザ入力インタフェース部６４０と、表示ディスプレイ６５０とで構成されている。制御部６１０は、記憶部６２０に格納されているプログラムであるコード処理６１１を実行する。記憶部６２０は、プログラムに加えて、再生コンテンツ６２１、アプリ品質情報６２２を記憶する。ネットワークインタフェース部６３０は、基地局１０９とのインタフェース部である。
【００３３】
図４を参照して、端末監視装置７００の構成を説明する。図４において、端末監視装置７００は、制御部７１０と、記憶部７２０と、ネットワークインタフェース部７３０とから構成されている。制御部７１０は、記憶部７２０に格納されているプログラムである端末監視処理７１１を実行する。記憶部７２０は、プログラムに加えて、アプリ品質情報７２１を記憶する。
【００３４】
図５を参照して、評価装置７００が実施するアプリケーション評価処理２００を説明する。図５において、評価装置７００は、パケット監視装置１０２が実施するパケット監視処理２５０と、端末監視装置１０３が実施する端末監視処理２８０を受けて、アプリケーション評価処理２００を実行する。評価装置７００において、アプリケーション評価処理２００は、以下のステップで処理を行なう。評価装置７００は、第１のステップのアプリフロー選別・性能評価処理２１０として、パケット監視装置１０２から通知されたパケットから、アプリケーション選別と個々のアプリケーションの性能評価を行なう。評価装置７００は、第２ステップの基地局１０９のアプリ評価処理２２０として、アプリケーション性能劣化が、処理フローに個々依存しているものであるのか、基地局１０９全体に及んだ問題であるのかの切り分けを行なう。評価装置７００は、第３ステップの基地局の要因分析処理２３０として、基地局１０９においてトラヒック輻輳要因によりアプリケーション性能劣化が発生しているかどうか、さらに基地局１０９における端末６００の移動要因、あるいは端末６００の配置要因によりアプリケーションの性能劣化が発生しているかどうかを確認する。評価装置７００は、第４ステップの要因分析案検討処理２４０として、第３ステップで要因が明らかにならなかった場合、保守員が対応すべき行動推奨案を検討する。評価装置７００は、第５ステップの結果表示処理１１９において、各ステップで得た結果を表示する。保守員は、この結果を見て解析を行ない、基地局設定変更や基地局増設などを検討し、システムの最適化を実施する。
【００３５】
以下、各処理の詳細について説明していく。
図６を参照して、パケット監視装置１０２におけるパケット監視処理２５０の処理フローを説明する。図６において、パケット監視装置１０２は、第１ステップとして、Ｓ−ＧＷ１１０と基地局間１０９を通過するパケットをキャプチャし、キャプチャした時刻をタイムスタンプとして記憶する（Ｓ２５１）。パケット監視装置１０２は、第２ステップとして、キャプチャしたパケットから、ＩＰパケットを抽出し、Ｓｏｕｒｃｅ ＩＰアドレスとポート番号、Ｄｅｓｔｉｎａｔｉｏｎ ＩＰアドレスとポート番号、ＩＰパケットからＩＰヘッダを除いたデータ長、トランスポートプロトコル種別、タイムスタンプ、Ｓ−ＧＷ１１０と基地局間１０９のパス識別子、Ｓ−ＧＷ１１０と基地局１０９間のパケット通信方向といった情報をパケットエントリとして記憶する（Ｓ２５２）。パケット監視装置１０２は、第３ステップとして、単位時間が経過しているかどうかを確認する（Ｓ２５３）。経過していなければ（ＮＯ）、パケット監視装置１０２は、ステップ２５１に戻って、このパケットキャプチャとパケットエントリ作成処理を単位時間の間実施する。ステップ２５３で単位時間が経過していれば（ＹＥＳ）、パケット監視装置１０２は、第４のステップとして、記憶したパケットエントリをアプリケーション評価装置に転送して（Ｓ２５４）、終了する。なお、パケットエントリの情報は、ストレージ１０４を介して、パケット監視装置１０２と評価装置７００で共有してもよい。
【００３６】
以下、評価装置７００が実施するアプリフロー選別・性能評価処理２００の詳細について説明する。
【００３７】
図７を参照して、アプリフロー選別・性能評価処理２１０を実施する際に利用するオペレータポリシとして、事前に定めておくアプリフロー選別基準１４０の構成を説明する。図７において、アプリフロー選別基準１４０のテーブルは、アプリフロー種別１４１、トランスポートプロトコル種別１４２、通信方向１４３、分類条件１４４から構成されている。
【００３８】
トランスポートプロトコル種別１４２は、ＴＣＰあるいはＵＤＰを表示する。通信方向１４３は、Ｓ−ＧＷ１１０から基地局１０９方向のダウンリンク（以下ＤＬ）または基地局１０９からＳ−ＧＷ方向のアップリンク（ＵＬ）を示す。分類条件１４４は、パケットからアプリを選別する際の分類条件である。ここでは、アプリフロー種別１４１は、ＶｏＩＰタイプ、動画タイプ、ダウンロードタイプ、アップロードタイプ、制御タイプを、分類条件１４４は、データ長とパケット間隔として示している。
【００３９】
図８を参照して、アプリフロー選別・性能評価処理２１０を実施する際に利用するオペレータポリシとして、事前に定めておくアプリフロー性能劣化基準１５０の構成を説明する。図８において、アプリフロー性能劣化基準１５０は、アプリフロー種別１５１と性能劣化基準１５２から構成する。ここでは、性能劣化基準１５２は、パケット間隔とその発生頻度および平均スループットとして示している。
【００４０】
図９を参照して、評価装置７００が実施するアプリフロー選別・性能評価処理２１０の処理フローを説明する。図９において、評価装置７００は、第１ステップとして、パケット監視装置１０２から通知されたパケットエントリを読出す（Ｓ２１１）。評価装置７００は、第２ステップとして、読み出したパケットエントリの情報から、アプリケフロー選別基準１４０に従って、アプリケーションの選別を行なう（Ｓ２１２）。さらに、評価装置７００は、第３ステップとして、各アプリフローにおいて、アプリケーションの性能劣化が発生しているかを確認するため、周期的にパケットをやり取りするＶｏＩＰタイプと動画タイプであるかを確認する（Ｓ２１３）。ＶｏＩＰタイプあるいは動画タイプである場合（ＹＥＳ）、評価装置７００は、第４ステップとして、アプリフロー性能劣化基準１５０に従って、パケット間隔が基準値よりも大きいかどうかをチェックし、大きい場合パケット受信間隔違反回数として、アプリフロー毎に記憶する（Ｓ２１３）。さらに、評価装置７００は、第５ステップとして、単位時間当りのパケットエントリの処理が完了しているかどうかを確認する（Ｓ２１５）。完了していなければ、評価装置７００は、ステップ２１１に遷移する。ステップ２１５で完了していれば、評価装置７００は、第６ステップとして、アプリフロー毎にパケット受信間各違反の頻度、平均スループットを求め、アプリフロー性能劣化基準１５０の基準値と比較し、アプリフロー毎に性能劣化が発生しているかを判断し、その結果をアプリフロー毎に記憶する（Ｓ２１６）。評価装置７００は、第７ステップとして、評価結果エントリ１２０を作成して（Ｓ２１７）、終了する。なお、ステップ２１３でＮＯのとき、ステップ２１４をジャンプする。
【００４１】
図１０を参照して、単位時間毎に評価装置７００がアプリフロー選別、性能評価処理２１０のステップ２１７で作成する評価結果エントリ１２０の構成を説明する。図１０において、評価結果エントリ１２０は、時刻１２１、単位時間当たりのダウンリンクとアップリンクのそれぞれのトータルデータ長１２２（１２２Ａ、１２２Ｂ）、アプリケーション種別と通信方向対応に纏めるアプリケーション情報エリア１３０（１３０Ａ、１３０Ｂ）と、選別できなかったアプリである非選別アプリのデータ量比率１２３および「基地局における性能劣化」時の要因を記録するエリア１２４から構成する。アプリケーション情報エリア１３０は、同一種類、同一通信方向のアプリフロー別に、アプリフロー種別１３１、トータルデータ長１３２、該当アプリフロー数１３３、通信方向１３４、単位時間当たりのアプリケーション利用比率を示すアプリフロー比率１３５、アプリデータ量比率１３６、プリフロー毎に性能劣化と判断したアプリフローの総数を示すアプリフロー数１３７およびそのアプリフロー識別情報１３８、アプリフローにおける性能劣化要因を記録するエリア１３９から構成する。
【００４２】
次に評価装置７００で行なう基地局の性能評価処理２２０の詳細について説明する。
図１１を参照して、基地局の性能評価処理２２０を実施する際に利用するオペレータポリシとして、事前に定めておく基地局のアプリ比率パターン１７０の構成を説明する。図１１において、基地局７００のアプリ比率パターン１７０は、アプリ比率パターン１７１対応にアプリ比率１７２を定めているものであり、アプリ比率１７２のエリアとしては、通信方向とアプリフロー種別のアプリ比率から構成する。
【００４３】
図１２を参照して、基地局の性能評価処理２２０を実施する際に利用するオペレータポリシとして、事前に定めておく基地局のアプリ性能劣化基準１６０の構成を説明する。図１２において、基地局のアプリ性能劣化基準１６０は、アプリフロー種別１６１対応のアプリケーション性能劣化基準１６２を定めたものである。アプリケーション性能劣化基準１６２は、アプリ比率とそのアプリ比率を満たしている場合の性能劣化基準として、各アプリ種別１６１における性能劣化検出したアプリフローの割合として性能劣化比率を示す。
【００４４】
図１３を参照して、評価装置７００で行なう基地局の性能評価処理２２０の処理フローを説明する。図１３において、評価装置７００は、第１ステップとして、評価結果エントリ１２０の合計データ長１２２と各アプリケーション情報エリア１３０の合計データ長１３２から（式１）を用いて、アプリフロー別のアプリデータ量比率を求める（Ｓ２２１）。
【００４５】
(アプリフロー別データ量比率)
＝(アプリケーション情報エリアの合計データ長)/(評価結果エントリの合計データ長)
…(式１)
評価装置７００は、第２ステップとして、求めたデータ比率を、評価エントリ１２０のアプリケーション情報エリア１３０のアプリデータ量比率１３６として格納する（Ｓ２２２）。評価装置７００は、第３ステップとして、アプリフローを選別できなかったアプリデータ量比率を（式２）から求め、評価結果エントリ１２０の非アプリ選別のデータ量比率１２３に格納する（Ｓ２２３）。
【００４６】
(非アプリ選別のデータ量比率)＝１−Σ(アプリフロー別データ量比率) …(式２)
評価装置７００は、第４ステップとして、各アプリケーション情報エリア１３０のアプリフロー数１３３から（式３）を用いてアプリフロー率を求める（Ｓ２２４）。
【００４７】
(アプリフロー率)
=(アプリケーション情報のアプリフロー数)/Σ(アプリケーション情報のアプリフロー数)
…(式３)
評価装置７００は、第５ステップとして、各アプリフロー率と非アプリ選別のデータ量比率から（式４）を用いて、アプリフロー比率を求め、評価結果エントリ１２０のアプリケーション情報エリア１３０のアプリフロー比率１３７として格納する（Ｓ２２５）。
【００４８】
(アプリフロー比率)
＝(１−(非アプリ選別のデータ量比率))＊(アプリフロー率) …(式４)
評価装置７００は、第６ステップとして、求めたアプリデータ量比率１３６とアプリフロー比率１３７から、基地局のアプリ比率パターン１７０に従って、対応するパターンを検出する（Ｓ２２６）。評価装置７００は、第７ステップとして、前回の評価処理時に検出したパターンと変化しているか判定する（Ｓ２２７）。変化している場合（ＹＥＳ）、評価装置７００は、第８ステップとして、該基地局１０９とその基地局１０９に接続しているＳ−ＧＷ１１０に対して検出したアプリ比率パターンを通知する（Ｓ２２８）。
【００４９】
ステップ２２７でＮＯのとき、またはステップ２２８の後、評価装置７００は、第９ステップとして、基地局のアプリ性能劣化基準１６０に従って、アプリ種別対応に性能劣化が基地局１０９全体に及んでいるかどうかを、アプリ種別対応に性能劣化を検出したアプリフロー数から求める性能劣化比率と基地局のアプリ性能劣化基準１６０の性能劣化基準値と比較して確認して（Ｓ２２９）、終了する。ステップ２２９により、性能劣化が基地局１０９全体に及んでいないと判断した場合、評価装置７００は、評価結果エントリ１２０のアプリケーション情報エリア１３０の要因１３９に「アプリフローによる」と記録する。基地局１０９における性能劣化が発生していると判断した場合、評価装置７００は、評価結果エントリ１２０のアプリケーション情報エリア１３０の要因１３９に「基地局における性能劣化」を記録する。
【００５０】
ステップ２２８において、アプリ比率パターンを通知された基地局１０９またはＳ−ＧＷ１１０は、予め定められているアプリ比率パターン対応に定められているトラヒック制御を実施するアプリフロー対応の閾値を参照して、トラヒック流入制御を行なう。さらに、ステップ２２８において、アプリ比率パターンを通知された基地局１０９は、端末６００に対して、現状のネットワーク利用状況として、アプリ比率パターンと各アプリケーションのトラヒックと閾値との関係を通知し、端末６００において通知された情報を図示して表示してもよい。
【００５１】
以下、ステップ２２９において、基地局１０９において性能劣化が発生していると確認した場合、つまり評価結果エントリ１２０のアプリケーション情報エリア１３０の要因１３９に「基地局における性能劣化」と記録した場合、評価装置７００が行なう基地局の要因分析処理２３０の詳細について説明する。
【００５２】
図１４を参照して、評価装置７００が基地局の要因分析処理２３０を実施する際に利用するオペレータポリシとして、事前に定めておく基地局の最低保証スループット１８０の構成を説明する。図１４において、基地局の最低保証スループット１８０は、図１１で定めたアプリ比率パターン１８１と、それに対応した基地局対応の最低保証スループット１８２から構成する。この基準は、その後、基地局の特徴を反映してもよい。この場合、基地局ごと異なる基準を持つことになる。ここで、基地局の特徴とは、基地局ベンダーごとの実装の違い、ビルが多いまたは見晴らしがよい等の電波環境の違い等である。
【００５３】
図１５を参照して、基地局１０９からＥＭＳ１０５を介してＮＥＭ１０６に周期的に収集され、ストレージ１０４に保存された基地局統計情報２９０の構成を説明する。図１５において、基地局統計情報２９０は、基地局識別子２９１、取得時刻２９２、ハンドオーバ２９３、変調符号化方式２９４から構成されている。ハンドオーバ２９３は、ハンドオーバ実施数とハンドオーバ成功数とからなる。変調符号化方式２９４は、変調符号化方式対応のデータ長の情報である。
【００５４】
図１６を参照して、評価装置７００が劣化要因分析処理を実施する際に利用するオペレータポリシとして、事前に定めておく基地局の無線帯域利用基準１９０の構成を説明する。図１６において、基地局の無線帯域利用基準１９０は、基地局の置局時に想定したハンドオーバ実施回数１９１、一様に端末が配置していると想定した場合の各変調符号化方式の利用比率１９２から構成する。この基準は、その後、基地局における特徴を反映して変更してもよい。この場合、基地局ごとに異なる基準を持つことになる。
【００５５】
図１７を参照して、評価装置７００が行なう基地局の要因分析処理２３０を示す処理フローを説明する。図１７において、評価装置７００は、第１のステップとして、基地局１０９の最低保証スループットに従って、アプリ比率パターンに対応した最低保証スループットと、評価結果エントリ１２０のトータルデータ長１２２から計算したスループットを比較する（Ｓ２３１）。計算したスループットが最低保証スループットより大きい場合（ＮＯ）、評価装置７００は、性能劣化要因をトラヒック輻輳とし，評価結果エントリ１２０の要因エリア１２４に記録して（Ｓ２３２）、終了する。ステップ２３１で小さい場合（ＹＥＳ）、評価装置７００は、第２のステップとして、基地局の無線帯域利用基準１９０のハンドオーバ実施回数１９１と、基地局統計情報２９０のハンドオーバ実施数２９３と比較する（Ｓ２３３）。ハンドオーバ実施数が基地局の無線帯域利用基準１９０のハンドオーバ実施回数より多い場合（ＹＥＳ）、性能劣化要因をハンドオーバ多発とし，評価結果エントリ１２０の要因エリア１２４に記録してする（Ｓ２３４）。ステップ２３３でＹＥＳのとき、またはステップ２３４の後で、さらに、評価装置７００は、第３のステップとして、基地局統計情報２９０の変調符号化方式２９４のそれぞれのデータ長から、それぞれの利用率を求め、基地局の無線帯域利用基準１９０の変調符号化利用比率１９２と比較する（Ｓ２３５）。比率が異なる場合（ＹＥＳ）、評価装置７００は、性能劣化要因を端末配置として，評価結果エントリ１２０の要因エリア１２４に記録して（Ｓ２３６）、終了する。ステップ２３５でＮＯのとき、評価装置７００は、評価結果エントリ１２０の要因エリア１２４に要因不明を記録し，終了する。
【００５６】
次に評価装置７００は、基地局の要因分析処理２３０で要因が検出できていない場合、要因分析案検討処理２４０を行なう。
図１８を参照して、評価装置７００が行なう要因分析案検討処理２４０の処理フローを説明する。図１８において、評価装置７００は、第１ステップとして、評価結果エントリ１２０の非選別アプリのデータ量比率１２３が５０％を超えているかどうかを確認する（Ｓ２４１）。超えている場合（ＹＥＳ）、評価装置７００は、第２ステップとして、性能劣化要因として、アプリフロー選別基準見直し要とトラヒック再分析要とし，評価結果エントリ１２０の要因エリア１２４に記録して（Ｓ２４２）、終了する。ここでは、評価装置７００は、保守員によるパケットの詳細分析により、新たなアプリケーション利用が増えていないかどうかを確認することを推奨する。
【００５７】
次に、ステップ２４１で超えていない場合（ＮＯ）、評価装置７００は、アプリフロー毎にアプリケーションの性能劣化を検出したアプリフローの通信先の同一率が５０％を越えているかどうかを確認する（Ｓ２４３）。超えている場合、評価装置７００は、第４ステップとして、性能劣化要因をサーバ側負荷確認要とし，評価結果エントリ１２０の要因エリア１２４に記録して（Ｓ２４４）、終了する。ここでは、評価装置７００は、アプリケーションサーバ側の負荷が高い可能性があるので、サーバ側の負荷を確認するように推奨する。
【００５８】
次に、ステップ２４３でＮＯのとき、評価装置７００は、第５ステップとして、性能劣化要因が解析できていない状況が連続しているかを確認する（Ｓ２４５）。続いている場合（ＹＥＳ）、評価装置７００は、第６ステップとして、性能劣化要因をアプリ性能劣化要因不明連続発生として（Ｓ２４６）、終了する。ここでは、評価装置７００は、保守員に対して、基地局状態、ネットワーク状態の確認を推奨し、原因の究明を進める。ステップ２４５でＮＯのとき、評価装置７００は、そのまま終了する。
【００５９】
以下、評価装置７００において、結果表示処理１１９において作成する、オペレータ端末１０７に表示する表示結果について説明する。
図１９を参照して、アプリケーション評価処理結果３００を説明する。図１９において、アプリケーション評価処理結果３００は、アイコン３０１と、マップ表示結果３０２と、解析結果３０３とからなる。アイコン３０１は、表示期間を選択する。マップ表示結果３０２は、選択した表示期間の基地局における性能劣化要因をマップ表示する。表示期間３０１は、マップ表示結果３０２と解析結果３０３を表示する日時と期間を選択するものである。図１９では、期間は、３時間単位、１日単位、１週間単位で可能である。マップ表示結果３０２は、基地局１０９対応に表示期間３０１で指定された期間において、性能劣化要因ごとにマップ上に表示するものである。２つ以上の性能劣化要因がある場合は、重複した発生がわかるように表示する。図１９では、トラヒック輻輳とハンドオーバの性能劣化要因が重複発生している基地局１０９を示している。解析結果３０３は、マップ表示結果３０２の性能劣化要因を示すとともに、保守員に対して推奨する行動を示す。
【００６０】
トラヒック輻輳発生の場合、基地局１０９におけるトラヒック量の確認および周囲の基地局１０９のロードバランスの確認を推奨する。この結果として、トラヒック量に耐えられないエリアであると判断した場合、保守員は基地局１０９におけるハンドオーバ閾値のパラメータを変更や、基地局増設の実施を検討することになる。ハンドオーバが多発している場合、基地局のロードバランスの確認および周囲の基地局１０９がカバーしている範囲の変更検討を推奨する。この結果として、保守員は基地局１０９におけるハンドオーバ閾値のパラメータ変更やアンテナチルドの変更の実施を検討することになる。端末配置不均等発生の場合、周囲の基地局１０９のロードバランスの確認および基地局１０９に想定している処理性能の見直しを推奨する。この結果、保守員は基地局１０９におけるハンドオーバ閾値のパラメータ変更や、アンテナチルドの変更、基地局１０９に接続する端末６００の配置を考慮した基地局１０９の許容トラヒックを以前より小さく設定するように基地局関連の制御パラメータを設定の実施を検討することになる。アプリ選別がきていないトラヒック多発する場合、新たなアプリケーションの利用により、新たなトラヒックが発生している可能性があることから、トラヒック分析を行なうことを推奨する。保守員によるトラヒック分析により、新たなアプリケーションが利用されているようであれば、オペレータポリシにアプリフローとして追加する。アプリ性能劣化要因不明連続発生の場合、基地局状態とネットワーク状態を確認することを推奨する。保守員は、基地局１０９にアプリケーション評価処理２００では見つけられてない問題、例えばハードの不調や、ネットワーク内での輻輳発生など、他の問題と関連付けて原因を究明する必要がある。
【００６１】
図２０を参照して、保守員の上述した作業を補助するための基地局毎のアプリ利用状況の表示結果３０４を説明する。図２０において、表示情報は、日か週で選択する表示期間３０６、ダウンロードとアップロードのアプリフローごとのスループット変動と、アプリ比率変動３０５からなる。この結果より、保守員が日々のユーザのアプリケーション利用傾向を把握することを助ける。
【００６２】
図２１を参照して、保守員の作業を補助するための基地局におけるアプリ性能劣化と要因分析結果３０７を説明する。図２１において、基地局におけるアプリ性能劣化と要因分析結果３０７の表示情報は、アップロードとダウンロードのトラヒック選択アイコン３０８と、１週間の結果を日単位に、ダウンロードとアップロードを別のアプリフロー別のトラヒック変動３０９（３０９Ａ、３０９Ｂ）からなる。トラヒック変動の結果上にアプリケーション性能評価により検出したアプリケーション性能劣化ポイントと分析した要因を表示する。日単位の結果を同時に表示することにより、保守員が日々の傾向を把握することを助ける。
【００６３】
以下、端末６００におけるアプリケーション性能劣化検出方法について説明する。
図２２を参照して、端末６００におけるアプリケーションの品質劣化を検出するデコード処理２６０の処理フローを説明する。図２２において、デコード処理２６０は、端末６００がＶｏＩＰや映像の再生といったアプリケーションを使用している場合、音声フレームや映像フレームのデコード処理中に品質劣化を検出する処理である。デコード処理２６０において、端末６００は、第１ステップとして、デコード処理停止あるいは一定時間が経過しているかを確認する（Ｓ２６１）。デコード処理停止や一定時間経過していない場合（ＮＯ）、端末６００は、第２ステップとして、音声フレームや映像フレームの再生時刻となっているかを確認する（Ｓ２６２）。再生時刻となっている場合（ＹＥＳ）、端末６００は、第３ステップとして、再生フレームの有無を確認する（Ｓ２６３）。再生フレームがある場合、端末６００は、第４ステップとして、再生時刻が再生フレームの持つ再生時刻より前か判定する（Ｓ２６４）。ＮＯのとき、端末６００は、再生時刻と再生フレームの持つ再生時刻が一致していることを確認する（Ｓ２６５）。ＹＥＳのとき、端末６００は、第５ステップとして、デコード処理を行なって（Ｓ２６６）、ステップ２６１に遷移する。
【００６４】
再生フレームが無かった場合（Ｓ２６３：ＮＯ）、または再生時刻よりも先を示す再生時刻持つ再生フレームの場合（Ｓ２６４：ＹＥＳ）、端末は６００、第６ステップとして、要因をフレーム無し、発生時刻、発生場所をアプリ品質情報として記録して（Ｓ２６７）、ステップ２６１に遷移する。
【００６５】
ステップ２６５でＮＯのとき、端末６００は、第７ステップとして、再生時刻よりも以前の再生時刻を持つ再生フレームを破棄する（Ｓ２６８）。端末６００は、第８ステップとして、要因をフレーム破棄、発生時刻、発生場所をアプリ品質情報として記録して（Ｓ２６９）、ステップ２６１に遷移する。
【００６６】
ステップ２６１でＹＥＳのとき、端末６００は、第９ステップとして、保存してあるアプリ品質情報を端末監視装置に通知する（Ｓ２７０）。端末６００は、デコード処理を停止するか判定する（Ｓ２７１）。停止するとき、端末６００は、終了する。ステップ２７１で停止しないとき（ＮＯ）、端末６００は、ステップ２６１に遷移する。
このように、端末６００は、デコード処理中の再生フレームの有無と破棄を監視し、それが発生した時刻と発生場所を記憶し、端末監視装置１０３に通知する。
【００６７】
図２３を参照して、アプリ品質情報を受け付けた端末監視装置１０３における端末監視処理２８０の処理フローを説明する。図２３において、端末監視装置１０３は、第１ステップとして、報告されたアプリ品質情報から発生頻度を求め、アプリ性能劣化が発生しているかどうかを、予め定めたフレームロス発生頻度基準と比較して判定する（Ｓ２８１）。アプリ性能劣化を検出した場合（ＹＥＳ）、端末監視装置１０３は、第２ステップとして、アプリ品質情報の発生場所と発生時刻から、ストレージ１０４に格納している基地局６００を設置した置局情報と端末統計情報に含まれる接続基地局の情報を利用して、端末６００が接続していた基地局１０９を抽出する（Ｓ２８２）。端末監視装置１０３は、第３ステップとして、アプリ品質情報の発生場所を基地局の情報に置き換える（Ｓ２８３）。端末監視装置１０３は、第４ステップとして、アプリ性能劣化を検出した対象のアプリ品質情報を評価装置７００へ転送して（Ｓ２８４）、終了する。ステップ２８１でＮＯのとき、端末監視装置１０３は、そのまま終了する。
【００６８】
評価装置７００は、端末監視装置１０３からのアプリ品質情報を受信した後、上述したようにアプリケーション評価処理２００における基地局の性能評価処理２２０、基地局の要因分析処理２３０、要因分析案検討処理２４０、結果表示処理１１９を行なう。評価装置７００は、アプリケーションの性能劣化とその要因の解析結果を保守員に表示する。これにより、評価装置７００は、アプリケーション性能劣化の対応を推奨するとともに、最適化の実施を導いていく。
【符号の説明】
【００６９】
１００…運用管理システム、１０２…パケット監視装置、１０３…端末監視装置、１０４…ストレージ、１０７…オペレータ端末、１０９…基地局、１１０…Ｓ−ＧＷ、６００…端末、７００…評価装置。
【特許請求の範囲】
【請求項１】
基地局とゲートウェイ間のパケットを監視し、予め定めたアプリケーション選別基準に従い、パケットよりアプリケーションフローの選別を行なうステップと、
単位時間当たりに個々のアプリケーションフロー対応に性能劣化が発生しているかどうかを判断し、各アプリケーションの種別ごとに、性能劣化が発生したアプリケーションフローの占める性能劣化比率を求めるステップと、
前記基地局における単位時間当たりの各アプリケーションの利用比率を各アプリケーションフロー数とデータ量とから求めるステップと、
求めた利用比率と各アプリケーションにおける性能劣化比率とから、予め定めたアプリケーション種別対応の利用比率と性能劣化基準とに従い、性能劣化が基地局全体に及んでいるかどうかを判断するステップと、を含むアプリケーション性能評価方法。
【請求項２】
請求項１に記載のアプリケーション性能評価方法であって、
基地局においてアプリケーション性能劣化が発生していると判断した場合、基地局における単位時間当たりのトータルスループットを、予め定めたアプリケーションの利用比率に応じた基地局における最低保証スループットと比較し、トータルスループットが最低保証スループットより大きい場合、トラヒック輻輳要因による性能劣化と判断するステップと、
トータルスループットが最低保証スループットより小さい場合、基地局におけるハンドオーバ実施回数を予め定めたハンドオーバ実施回数基準値と比較し、その基準値より大きい場合、移動要因による性能劣化と判断するステップと、基地局における変調符号化方式対応の単位時間当たりの送信データ長から各変調符号化方式の利用比率を求め、求めた変調符号化方式の利用比率と予め定めた変調符号化方式の基準利用比率と比較し、利用比率が異なる場合、端末配置要因による性能劣化と判断するステップと、を含むアプリケーション性能評価方法。
【請求項３】
請求項１に記載のアプリケーション性能評価方法であって、
基地局とゲートウェイと間のパケットを監視し、パケットより、予め定めたオペレータポリシであるアプリケーション選別基準に従い、アプリケーションフローの選別を行なうステップと、
単位時間当たりに個々のアプリケーションフロー対応に性能劣化が発生しているかどうかを判断し、各アプリケーションの種別ごとに、性能劣化が発生したアプリケーションフローの占める性能劣化比率を求めるステップと、
基地局における単位時間当たりの各アプリケーションの利用比率を各アプリケーションフロー数とデータ量から求めるステップと、
求めた利用比率と各アプリケーションにおける性能劣化比率から、予め定めたアプリケーション種別対応の利用比率と性能劣化基準に従い、性能劣化が基地局全体に及んでいるかどうかを判断するステップと、
基地局における単位時間当たりのトータルスループットを、予め定めたアプリケーションの利用比率に応じた基地局における最低保証スループットと比較し、トータルスループットが最低保証スループットより大きい場合、トラヒック輻輳要因による性能劣化と判断するステップと、
基地局におけるハンドオーバ実施回数を予め定めたハンドオーバ実施回数基準値と比較し、その基準値より大きい場合、移動要因による性能劣化と判断するステップと、
基地局における変調符号化方式対応の単位時間当たりの送信データ長から各変調符号化方式の利用比率を求め、求めた変調符号化方式の利用比率と予め定めた変調符号化方式の基準利用比率と比較し、利用比率が異なる場合、端末配置要因による性能劣化と判断するステップと、を含むアプリケーション性能評価方法。
【請求項４】
請求項３に記載のアプリケーション性能劣化検出方法であって、
性能劣化と判断する要因が検出できなかった場合、非選別アプリケーションのデータ量比率より、アプリフロー選別基準見直しが必要であり、かつパケット再分析が必要であると判断するステップと、
アプリケーションフロー毎にアプリケーションの性能劣化を検出したアプリケーションフローの通信先を調べ、求めた同一の通信先の比率より、サーバ側がの負荷の確認が必要であると判断するステップと、
性能劣化と判断する要因が一定期間連続して検出できていないことを判断するステップと、を含むアプリケーション性能評価方法。
【請求項５】
請求項１に記載のアプリケーション性能評価方法であって、
音声あるいは映像のデコード処理において、再生時刻における再生フレームなし、あるいは再生フレーム破棄のいずれかを検出した場合、その発生時刻と位置情報を記憶するステップと、記憶した情報より検出頻度を求め、予め定めたフレームロス発生頻度基準と比較し、アプリケーション性能劣化が発生しているかどうかを判断するステップとを含むアプリケーション性能評価方法。
【請求項６】
基地局とゲートウェイ間のパケットより、予め定めたアプリケーション選別基準に従い、アプリケーション種別毎にフローを選別するアプリケーションフロー選別機能と、単位時間当たりに個々のアプリケーションフロー対応に性能劣化が発生しているかどうかを判断するアプリケーションフロー性能評価機能と、各アプリケーションの種別ごとに、性能劣化が発生したアプリケーションフローの占める性能劣化比率を求め、基地局における単位時間当たりの各アプリケーションの利用比率を各アプリケーションフロー数とデータ量から求め、求めたアプリケーションの利用比率と各アプリケーションの性能劣化比率から、予め定めたアプリケーション種別対応の利用比率と性能劣化基準に従い、性能劣化が基地局全体に及んでいるかどうかを判断する基地局アプリ性能評価機能と、性能劣化が発生していると判断した場合、基地局における単位時間当たりのトータルスループットを、予め定めたアプリケーションの利用比率に応じた基地局における最低保証スループットと比較し、トータルスループットが最低保証スループットより大きい場合、トラヒック輻輳要因による性能劣化と判断し、基地局におけるハンドオーバ実施回数を予め定めたハンドオーバ実施回数基準値と比較し、その基準値より大きい場合、移動要因による性能劣化と判断し、さらに、基地局における変調符号化方式対応の単位時間当たりの送信データ長から各変調符号化方式の利用比率を求め、求めた変調符号化方式の利用比率と予め定めた変調符号化方式の基準利用比率と比較し、利用比率が異なる場合、端末配置要因による性能劣化と判断する基地局の要因分析機能と、基地局対応に単位時間当りのアプリケーション利用比率と基地局における性能劣化有無と性能劣化の要因を表示する表示機能とを備える評価装置。
【請求項７】
請求項６に記載の評価装置であって、
端末で移動体通信システムを介して受信しながら実行する音声あるいは映像のデコード処理で再生フレームなし、あるいは再生フレーム破棄を検出した時点で、その現象と検出時刻と位置情報からなるアプリ品質情報より、フレームロス発生率を求め、予め定めたフレームロス発生頻度基準と比較し、アプリケーション性能劣化が発生しているかどうかを判断する機能を備える評価装置。
【請求項８】
請求項６に記載の評価装置であって、
単位時間当たりの求めた各アプリケーションの利用比率を記憶し、前の単位時間当りの記憶したアプリケーション利用比率と比較する機能と、アプリケーション利用比率が変化していた場合、求めたアプリケーション利用比率を基地局あるいはゲートウェイに通知する機能とを備える評価装置。
【請求項９】
基地局とゲートウェイ間のパケットを監視するパケット監視装置と、
パケット監視装置が抽出したパケットより、予め定めたアプリケーション選別基準に従い、アプリケーションフローの選別を行なう機能と、単位時間当たりに個々のアプリケーションフロー対応に性能劣化が発生しているかどうかを判断するアプリケーションフロー性能評価機能と、各アプリケーションの種別ごとに、性能劣化が発生したアプリケーションフローの占める性能劣化比率を求め、基地局における単位時間当たりの各アプリケーションの利用比率を各アプリケーションフロー数とデータ量から求め、求めた利用比率と各アプリケーションにおける性能劣化比率から、予め定めたアプリケーション種別対応の利用比率と性能劣化基準に従い、性能劣化が基地局全体に及んでいるかどうかを判断する基地局のアプリケーション性能劣化検出機能と、基地局における単位時間当たりのトータルスループットを、予め定めた利用比率に応じた基地局における最低保証スループットと比較し、トータルスループットが最低保証スループットより大きい場合、トラヒック輻輳要因による性能劣化と判断し、基地局におけるハンドオーバ実施回数を予め定めたハンドオーバ実施回数基準値と比較し、その基準値より大きい場合、移動要因による性能劣化と判断し、さらに、基地局における変調符号化方式対応の単位時間当たりの送信データ長から各変調符号化方式の利用比率を求め、求めた変調符号化方式の利用比率と予め定めた変調符号化方式の基準利用比率と比較し、利用比率が異なる場合、端末配置要因による性能劣化と判断する基地局の要因分析機能と、基地局対応に単位時間当りのアプリケーション利用比率と基地局における性能劣化有無と性能劣化の要因を表示する表示機能とを備えた評価装置と、
移動体通信システム内の構成機器を管理制御する管理装置、前記構成機器からの統計情報を格納するストレージおよび保守員の操作するオペレータ端末とから構成する移動体通信システム。
【請求項１０】
請求項９に記載の移動体通信システムであって、
移動体通信システムで受信している音声あるいは映像のデコード処理で再生フレームなし、あるいは再生フレーム破棄を検出した時点で、その現象と検出時刻と位置情報からなるアプリ品質情報を生成する端末と、端末が生成したアプリ品質情報を収集し、フレームロス発生率を求め、予め定めたフレームロス発生頻度基準と比較し、アプリケーション性能劣化が発生しているかどうかを判断する機能と、前記アプリ品質情報の位置情報を該当する基地局識別子に置き換えたアプリ品質情報を生成し、評価装置に通知する端末監視装置と、アプリ品質情報を受けて、前記アプリケーション性能劣化検出機能とアプリケーション性能劣化要因検出機能を実施する評価装置とから構成する移動体通信システム。
【請求項１１】
請求項９または請求項１０に記載の移動体通信システムであって、
単位時間当たりの求めた各アプリケーションの利用比率を記憶し、前の単位時間当りの記憶したアプリケーション利用比率と比較する機能と、アプリケーション利用比率が変化していた場合、求めたアプリケーション利用比率を基地局あるいはゲートウェイに通知する機能とを備える評価装置、アプリケーション利用比率を受けて、予めアプリケーション利用比率対応に定めたトラヒック流量に従い、トラヒック流入制御を行なう基地局あるいはゲートウェイとから構成する移動体通信システム。
【請求項１】
基地局とゲートウェイ間のパケットを監視し、予め定めたアプリケーション選別基準に従い、パケットよりアプリケーションフローの選別を行なうステップと、
単位時間当たりに個々のアプリケーションフロー対応に性能劣化が発生しているかどうかを判断し、各アプリケーションの種別ごとに、性能劣化が発生したアプリケーションフローの占める性能劣化比率を求めるステップと、
前記基地局における単位時間当たりの各アプリケーションの利用比率を各アプリケーションフロー数とデータ量とから求めるステップと、
求めた利用比率と各アプリケーションにおける性能劣化比率とから、予め定めたアプリケーション種別対応の利用比率と性能劣化基準とに従い、性能劣化が基地局全体に及んでいるかどうかを判断するステップと、を含むアプリケーション性能評価方法。
【請求項２】
請求項１に記載のアプリケーション性能評価方法であって、
基地局においてアプリケーション性能劣化が発生していると判断した場合、基地局における単位時間当たりのトータルスループットを、予め定めたアプリケーションの利用比率に応じた基地局における最低保証スループットと比較し、トータルスループットが最低保証スループットより大きい場合、トラヒック輻輳要因による性能劣化と判断するステップと、
トータルスループットが最低保証スループットより小さい場合、基地局におけるハンドオーバ実施回数を予め定めたハンドオーバ実施回数基準値と比較し、その基準値より大きい場合、移動要因による性能劣化と判断するステップと、基地局における変調符号化方式対応の単位時間当たりの送信データ長から各変調符号化方式の利用比率を求め、求めた変調符号化方式の利用比率と予め定めた変調符号化方式の基準利用比率と比較し、利用比率が異なる場合、端末配置要因による性能劣化と判断するステップと、を含むアプリケーション性能評価方法。
【請求項３】
請求項１に記載のアプリケーション性能評価方法であって、
基地局とゲートウェイと間のパケットを監視し、パケットより、予め定めたオペレータポリシであるアプリケーション選別基準に従い、アプリケーションフローの選別を行なうステップと、
単位時間当たりに個々のアプリケーションフロー対応に性能劣化が発生しているかどうかを判断し、各アプリケーションの種別ごとに、性能劣化が発生したアプリケーションフローの占める性能劣化比率を求めるステップと、
基地局における単位時間当たりの各アプリケーションの利用比率を各アプリケーションフロー数とデータ量から求めるステップと、
求めた利用比率と各アプリケーションにおける性能劣化比率から、予め定めたアプリケーション種別対応の利用比率と性能劣化基準に従い、性能劣化が基地局全体に及んでいるかどうかを判断するステップと、
基地局における単位時間当たりのトータルスループットを、予め定めたアプリケーションの利用比率に応じた基地局における最低保証スループットと比較し、トータルスループットが最低保証スループットより大きい場合、トラヒック輻輳要因による性能劣化と判断するステップと、
基地局におけるハンドオーバ実施回数を予め定めたハンドオーバ実施回数基準値と比較し、その基準値より大きい場合、移動要因による性能劣化と判断するステップと、
基地局における変調符号化方式対応の単位時間当たりの送信データ長から各変調符号化方式の利用比率を求め、求めた変調符号化方式の利用比率と予め定めた変調符号化方式の基準利用比率と比較し、利用比率が異なる場合、端末配置要因による性能劣化と判断するステップと、を含むアプリケーション性能評価方法。
【請求項４】
請求項３に記載のアプリケーション性能劣化検出方法であって、
性能劣化と判断する要因が検出できなかった場合、非選別アプリケーションのデータ量比率より、アプリフロー選別基準見直しが必要であり、かつパケット再分析が必要であると判断するステップと、
アプリケーションフロー毎にアプリケーションの性能劣化を検出したアプリケーションフローの通信先を調べ、求めた同一の通信先の比率より、サーバ側がの負荷の確認が必要であると判断するステップと、
性能劣化と判断する要因が一定期間連続して検出できていないことを判断するステップと、を含むアプリケーション性能評価方法。
【請求項５】
請求項１に記載のアプリケーション性能評価方法であって、
音声あるいは映像のデコード処理において、再生時刻における再生フレームなし、あるいは再生フレーム破棄のいずれかを検出した場合、その発生時刻と位置情報を記憶するステップと、記憶した情報より検出頻度を求め、予め定めたフレームロス発生頻度基準と比較し、アプリケーション性能劣化が発生しているかどうかを判断するステップとを含むアプリケーション性能評価方法。
【請求項６】
基地局とゲートウェイ間のパケットより、予め定めたアプリケーション選別基準に従い、アプリケーション種別毎にフローを選別するアプリケーションフロー選別機能と、単位時間当たりに個々のアプリケーションフロー対応に性能劣化が発生しているかどうかを判断するアプリケーションフロー性能評価機能と、各アプリケーションの種別ごとに、性能劣化が発生したアプリケーションフローの占める性能劣化比率を求め、基地局における単位時間当たりの各アプリケーションの利用比率を各アプリケーションフロー数とデータ量から求め、求めたアプリケーションの利用比率と各アプリケーションの性能劣化比率から、予め定めたアプリケーション種別対応の利用比率と性能劣化基準に従い、性能劣化が基地局全体に及んでいるかどうかを判断する基地局アプリ性能評価機能と、性能劣化が発生していると判断した場合、基地局における単位時間当たりのトータルスループットを、予め定めたアプリケーションの利用比率に応じた基地局における最低保証スループットと比較し、トータルスループットが最低保証スループットより大きい場合、トラヒック輻輳要因による性能劣化と判断し、基地局におけるハンドオーバ実施回数を予め定めたハンドオーバ実施回数基準値と比較し、その基準値より大きい場合、移動要因による性能劣化と判断し、さらに、基地局における変調符号化方式対応の単位時間当たりの送信データ長から各変調符号化方式の利用比率を求め、求めた変調符号化方式の利用比率と予め定めた変調符号化方式の基準利用比率と比較し、利用比率が異なる場合、端末配置要因による性能劣化と判断する基地局の要因分析機能と、基地局対応に単位時間当りのアプリケーション利用比率と基地局における性能劣化有無と性能劣化の要因を表示する表示機能とを備える評価装置。
【請求項７】
請求項６に記載の評価装置であって、
端末で移動体通信システムを介して受信しながら実行する音声あるいは映像のデコード処理で再生フレームなし、あるいは再生フレーム破棄を検出した時点で、その現象と検出時刻と位置情報からなるアプリ品質情報より、フレームロス発生率を求め、予め定めたフレームロス発生頻度基準と比較し、アプリケーション性能劣化が発生しているかどうかを判断する機能を備える評価装置。
【請求項８】
請求項６に記載の評価装置であって、
単位時間当たりの求めた各アプリケーションの利用比率を記憶し、前の単位時間当りの記憶したアプリケーション利用比率と比較する機能と、アプリケーション利用比率が変化していた場合、求めたアプリケーション利用比率を基地局あるいはゲートウェイに通知する機能とを備える評価装置。
【請求項９】
基地局とゲートウェイ間のパケットを監視するパケット監視装置と、
パケット監視装置が抽出したパケットより、予め定めたアプリケーション選別基準に従い、アプリケーションフローの選別を行なう機能と、単位時間当たりに個々のアプリケーションフロー対応に性能劣化が発生しているかどうかを判断するアプリケーションフロー性能評価機能と、各アプリケーションの種別ごとに、性能劣化が発生したアプリケーションフローの占める性能劣化比率を求め、基地局における単位時間当たりの各アプリケーションの利用比率を各アプリケーションフロー数とデータ量から求め、求めた利用比率と各アプリケーションにおける性能劣化比率から、予め定めたアプリケーション種別対応の利用比率と性能劣化基準に従い、性能劣化が基地局全体に及んでいるかどうかを判断する基地局のアプリケーション性能劣化検出機能と、基地局における単位時間当たりのトータルスループットを、予め定めた利用比率に応じた基地局における最低保証スループットと比較し、トータルスループットが最低保証スループットより大きい場合、トラヒック輻輳要因による性能劣化と判断し、基地局におけるハンドオーバ実施回数を予め定めたハンドオーバ実施回数基準値と比較し、その基準値より大きい場合、移動要因による性能劣化と判断し、さらに、基地局における変調符号化方式対応の単位時間当たりの送信データ長から各変調符号化方式の利用比率を求め、求めた変調符号化方式の利用比率と予め定めた変調符号化方式の基準利用比率と比較し、利用比率が異なる場合、端末配置要因による性能劣化と判断する基地局の要因分析機能と、基地局対応に単位時間当りのアプリケーション利用比率と基地局における性能劣化有無と性能劣化の要因を表示する表示機能とを備えた評価装置と、
移動体通信システム内の構成機器を管理制御する管理装置、前記構成機器からの統計情報を格納するストレージおよび保守員の操作するオペレータ端末とから構成する移動体通信システム。
【請求項１０】
請求項９に記載の移動体通信システムであって、
移動体通信システムで受信している音声あるいは映像のデコード処理で再生フレームなし、あるいは再生フレーム破棄を検出した時点で、その現象と検出時刻と位置情報からなるアプリ品質情報を生成する端末と、端末が生成したアプリ品質情報を収集し、フレームロス発生率を求め、予め定めたフレームロス発生頻度基準と比較し、アプリケーション性能劣化が発生しているかどうかを判断する機能と、前記アプリ品質情報の位置情報を該当する基地局識別子に置き換えたアプリ品質情報を生成し、評価装置に通知する端末監視装置と、アプリ品質情報を受けて、前記アプリケーション性能劣化検出機能とアプリケーション性能劣化要因検出機能を実施する評価装置とから構成する移動体通信システム。
【請求項１１】
請求項９または請求項１０に記載の移動体通信システムであって、
単位時間当たりの求めた各アプリケーションの利用比率を記憶し、前の単位時間当りの記憶したアプリケーション利用比率と比較する機能と、アプリケーション利用比率が変化していた場合、求めたアプリケーション利用比率を基地局あるいはゲートウェイに通知する機能とを備える評価装置、アプリケーション利用比率を受けて、予めアプリケーション利用比率対応に定めたトラヒック流量に従い、トラヒック流入制御を行なう基地局あるいはゲートウェイとから構成する移動体通信システム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【公開番号】特開２０１２−７００６７（Ｐ２０１２−７００６７Ａ）
【公開日】平成２４年４月５日（２０１２．４．５）
【国際特許分類】
【出願番号】特願２０１０−２１０９４９（Ｐ２０１０−２１０９４９）
【出願日】平成２２年９月２１日（２０１０．９．２１）
【出願人】（０００００５１０８）株式会社日立製作所 (27,607)
【Ｆターム（参考）】
【公開日】平成２４年４月５日（２０１２．４．５）
【国際特許分類】
【出願日】平成２２年９月２１日（２０１０．９．２１）
【出願人】（０００００５１０８）株式会社日立製作所 (27,607)
【Ｆターム（参考）】
[ Back to top ]