特許第5836425号(P5836425)IP Force 特許公報掲載プロジェクト 2015.5.11 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ 株式会社日立製作所の特許一覧
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】5836425
(24)【登録日】2015年11月13日
(45)【発行日】2015年12月24日
(54)【発明の名称】評価装置、評価方法および通信システム
(51)【国際特許分類】
   H04M 3/00 20060101AFI20151203BHJP
   H04L 12/70 20130101ALI20151203BHJP
   H04W 24/08 20090101ALI20151203BHJP
   H04W 88/08 20090101ALI20151203BHJP
【FI】
   H04M3/00 E
   H04L12/70 100Z
   H04W24/08
   H04W88/08
【請求項の数】14
【全頁数】23
(21)【出願番号】特願2014-84183(P2014-84183)
(22)【出願日】2014年4月16日
(62)【分割の表示】特願2010-210949(P2010-210949)の分割
【原出願日】2010年9月21日
(65)【公開番号】特開2014-209732(P2014-209732A)
(43)【公開日】2014年11月6日
【審査請求日】2014年4月16日
(73)【特許権者】
【識別番号】000005108
【氏名又は名称】株式会社日立製作所
(74)【代理人】
【識別番号】110001689
【氏名又は名称】青稜特許業務法人
(74)【代理人】
【識別番号】110000350
【氏名又は名称】ポレール特許業務法人
(72)【発明者】
【氏名】水谷 美加
(72)【発明者】
【氏名】林 慎一郎
【審査官】 永田 義仁
(56)【参考文献】
【文献】 国際公開第2010/014961(WO,A2)
【文献】 特開2010−124374(JP,A)
【文献】 特開2001−195285(JP,A)
【文献】 特開2010−183376(JP,A)
【文献】 特開2006−067090(JP,A)
【文献】 特開2010−130650(JP,A)
【文献】 特開2004−145536(JP,A)
【文献】 特開2003−218868(JP,A)
【文献】 特開2010−166176(JP,A)
(58)【調査した分野】(Int.Cl.,DB名)
H04B 7/24− 7/26
H04L 12/00−12/26
H04L 12/50−12/955
H04M 3/00
H04M 3/08− 3/58
H04M 7/00− 7/16
H04M 11/00−11/10
H04Q 1/20− 1/26
H04W 4/00−99/00
(57)【特許請求の範囲】
【請求項1】
予め定めたアプリケーションフロー選別基準に従って、第1の装置と第2の装置との間のパケットより、アプリケーションフローの選別を行うアプリケーションフロー選別機能と、
予め定めたアプリケーションフロー性能評価基準に従って、前記アプリケーションフローの種別ごとに、前記選別されたアプリケーションフローの性能評価を行うアプリケーションフロー性能評価機能と、
前記アプリケーションフローの種別ごとに、前記第1の装置における単位時間あたりの前記アプリケーションフローの利用情報を算出し、前記算出した利用情報と前記性能評価結果から、予め定めた利用情報に対応する装置性能評価基準に従って、前記第1の装置の性能評価を行う装置性能評価機能と、を備えることを特徴とする評価装置。
【請求項2】
予め定めたアプリケーションフロー選別基準に従って、第1の装置と第2の装置との間のパケットより、アプリケーションフローの選別を行うアプリケーションフロー選別機能と、
予め定めたアプリケーションフロー性能評価基準に従って、前記アプリケーションフローの種別ごとに、前記選別されたアプリケーションフローの性能評価を行うアプリケーションフロー性能評価機能と、
予め定めた装置性能評価基準に従って、前記アプリケーションフローの種別ごとの前記アプリケーションフローの性能評価結果を用いて、前記第1の装置の性能評価を行う装置性能評価機能と、を備え
前記装置性能評価基準は、性能劣化基準であり、
前記アプリケーションフロー性能評価機能は、前記アプリケーションフローの性能評価として、前記選別されたアプリケーションフローに性能劣化が発生しているかどうかを判断し、
前記装置性能評価機能は、前記第1の装置の性能評価を行う場合に、前記アプリケーションフローの種別ごとに、前記性能劣化が発生したアプリケーションフローが単位時間当たりに占める性能劣化比率を算出し、前記算出した性能劣化比率と予め定めた前記性能劣化基準とに基づいて、前記性能劣化が前記第1の装置全体に及んでいるかどうかを判断することを特徴とする評価装置。
【請求項3】
請求項に記載の評価装置であって、
前記性能劣化基準は、単位時間あたりの前記アプリケーションフローの利用比率に対応し、
前記装置性能評価機能は、前記性能劣化が前記第1の装置全体に及んでいるかどうかを判断する場合に、前記アプリケーションフローの種別ごとに、前記第1の装置における単位時間あたりの前記アプリケーションフローの利用比率をアプリケーションフロー数とデータ量から算出し、前記算出した利用比率と前記性能劣化比率から、予め定めた利用比率に対応する前記性能劣化基準に従って、前記性能劣化が前記第1の装置全体に及んでいるかどうかを判断することを特徴とする評価装置。
【請求項4】
請求項1乃至の何れかに記載の評価装置であって、
前記第1の装置は基地局であって、前記第2の装置はゲートウェイであることを特徴とする評価装置。
【請求項5】
請求項1乃至の何れかに記載の評価装置であって、
前記装置性能評価機能が、前記第1の装置の性能評価の結果、性能劣化が前記第1の装置全体に及んでいると判断した場合、前記性能劣化の要因を分析する要因分析機能と、
前記第1の装置における性能劣化有無と前記性能劣化の要因を出力する出力機能と、
をさらに備えることを特徴とする評価装置。
【請求項6】
請求項1乃至の何れかに記載の評価装置であって、
前記装置性能評価機能は、前記第1の装置の性能評価を行う場合に、前記アプリケーションフローの種別ごとに、前記第1の装置における単位時間あたりの前記アプリケーションフローの利用比率を前記アプリケーションフロー数とデータ量から算出し、
前記評価装置は、前記アプリケーションフローの利用比率が変化した場合、トラヒック流入制御を行うための通知を行う機能を備えることを特徴とする評価装置。
【請求項7】
評価装置における評価方法であって、
第1の装置と第2の装置との間のパケットを監視し、予め定めたアプリケーションフロー選別基準に従って、前記パケットよりアプリケーションフローの選別を行うステップと、
予め定めたアプリケーションフロー性能評価基準に従って、前記アプリケーションフローの種別ごとに、前記選別されたアプリケーションフローの性能評価を行うステップと、
前記アプリケーションフローの種別ごとに、前記第1の装置における単位時間あたりの前記アプリケーションフローの利用情報を算出し、前記算出した利用情報と前記性能評価結果から、予め定めた利用情報に対応する装置性能評価基準に従って、前記第1の装置の性能評価を行うステップと、を備えることを特徴とする評価方法。
【請求項8】
評価装置における評価方法であって、
第1の装置と第2の装置との間のパケットを監視し、予め定めたアプリケーションフロー選別基準に従って、前記パケットよりアプリケーションフローの選別を行うステップと、
予め定めたアプリケーションフロー性能評価基準に従って、前記アプリケーションフローの種別ごとに、前記選別されたアプリケーションフローの性能評価を行うステップと、
予め定めた装置性能評価基準に従って、前記アプリケーションフローの種別ごとの前記アプリケーションフローの性能評価結果を用いて、前記第1の装置の性能評価を行うステップと、を備え
前記装置性能評価基準は、性能劣化基準であり、
前記アプリケーションフローの性能評価を行うステップにおいて、前記アプリケーションフローの性能評価として、前記選別されたアプリケーションフローに性能劣化が発生しているかどうかを判断し、
前記第1の装置の性能評価を行うステップにおいて、前記アプリケーションフローの種別ごとに、前記性能劣化が発生したアプリケーションフローが単位時間当たりに占める性能劣化比率を算出し、前記算出した性能劣化比率と予め定めた前記性能劣化基準とに基づいて、前記性能劣化が前記第1の装置全体に及んでいるかどうかを判断することを特徴とする評価方法。
【請求項9】
請求項に記載の評価方法であって、
前記性能劣化基準は、単位時間あたりの前記アプリケーションフローの利用比率に対応し、
前記第1の装置の性能評価を行うステップにおいて、前記性能劣化が前記第1の装置全体に及んでいるかどうかを判断する場合に、前記アプリケーションフローの種別ごとに、前記第1の装置における単位時間あたりの前記アプリケーションフローの利用比率をアプリケーションフロー数とデータ量から算出し、前記算出した利用比率と前記性能劣化比率から、予め定めた利用比率に対応する前記性能劣化基準に従って、前記性能劣化が前記第1の装置全体に及んでいるかどうかを判断することを特徴とする評価方法。
【請求項10】
請求項乃至の何れかに記載の評価方法であって、
前記第1の装置は基地局であって、前記第2の装置はゲートウェイであることを特徴とする評価方法。
【請求項11】
請求項乃至10の何れかに記載の評価方法であって、
前記第1の装置の性能評価を行うステップにおいて、前記第1の装置の性能評価の結果、性能劣化が前記第1の装置全体に及んでいると判断した場合、前記性能劣化の要因を分析するステップと、
前記第1の装置における性能劣化有無と前記性能劣化の要因を表示するステップと、
をさらに備えることを特徴とする評価方法。
【請求項12】
請求項乃至11の何れかに記載の評価方法であって、
前記第1の装置の性能評価を行うステップにおいて、前記アプリケーションフローの種別ごとに、前記第1の装置における単位時間あたりの前記アプリケーションフローの利用比率を前記アプリケーションフロー数とデータ量から算出し、
前記評価方法は、
前記アプリケーションフローの利用比率が変化した場合に通知を行うステップと、
前記通知を受信するとトラヒック流入制御を行うステップと、
をさらに備えることを特徴とする評価方法。
【請求項13】
端末と通信を行う基地局と、
前記基地局と接続されるゲートウェイと、
前記基地局と前記ゲートウェイとの間のパケットを監視するパケット監視装置と、
前記パケット監視装置に接続される評価装置と、を備え、
前記評価装置は、
予め定めたアプリケーションフロー選別基準に従って、前記パケットより、アプリケーションフローの選別を行うアプリケーションフロー選別機能と、
予め定めたアプリケーションフロー性能評価基準に従って、前記アプリケーションフローの種別ごとに、前記選別されたアプリケーションフローの性能評価を行うアプリケーションフロー性能評価機能と、
前記アプリケーションフローの種別ごとに、前記基地局における単位時間あたりの前記アプリケーションフローの利用情報を算出し、前記算出した利用情報と前記性能評価結果から、予め定めた利用情報に対応する装置性能評価基準に従って、前記基地局の性能評価を行う装置性能評価機能と、を備えることを特徴とする通信システム。
【請求項14】
請求項13に記載の通信システムであって、
前記評価装置は、前記装置性能評価機能が、前記基地局の性能評価の結果、性能劣化が前記基地局全体に及んでいると判断した場合、前記性能劣化の要因を分析する要因分析機能をさらに備え、
前記通信システムは、前記基地局における性能劣化有無と前記性能劣化の要因を表示するオペレータ端末をさらに備えることを特徴とする通信システム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、移動体通信システム上で利用されるアプリケーション性能評価とその性能劣化検出方法に係り、特に基地局におけるアプリケーション性能劣化要因の検出方法、評価装置および移動体通信システムに関する。
【背景技術】
【0002】
モバイルデータトラヒックは、著しく増加すると予測されている。これは、WiMAX(Worldwide Interoperability for Microwave Access)およびLTE(Long Term Evolution)と呼ばれるモバイルブロードバンド環境が整備されていくことによる。モバイルブロードバンド環境の普及により、アプリケーションは、モバイル事業者が提供していた携帯電話に特化したメール、Webアクセス、音楽などのダウンロードサービスなどから、通常のインターネットサービスであるWebアクセス、ビデオオンデマンド、VoIP(Voice over IP)さらには個人による動画放送サービスなどへと広がりをみせている。
【0003】
移動体通信システムの運用では、利用者からの性能に対するクレームが来る前に問題を検出し、先手で対策を実施していくことが、ユーザ満足度向上のために必要である。アプリケーションを利用しているユーザが、その品質が悪化していると感じる場合、その要因の多くは、アプリケーションの通信性能の劣化によるものである。例えば、ユーザがダウンロードを遅いと感じている場合、アプリケーションの通信性能として、スループットが低下している。VoIPで瞬断を感じる場合、アプリケーションの通信性能として、遅延が大きくなっている。
【0004】
移動体通信システムにおいて、利用できるアプリケーションが広がりを見せていることから、単に基地局のトータル性能の監視だけで状態を判断するのではなく、アプリケーションの品質の観点での監視が必要である。このため、基地局における様々なアプリケーション利用の状態を把握し、アプリケーションにおける性能劣化の有無を判断し、その要因が基地局におけるリソース不足であるのか、端末の移動や位置における影響であるのかなど、性能劣化の原因を把握することが、移動体通信システムの最適化では重要になってきている。
【0005】
一方、移動体通信システムにおいて、アプリケーション性能劣化の要因の一つとして、基地局への膨大なトラヒック流入がある。これを防ぐため、基地局への流入制御が行なわれている。特許文献1で示されている流入制御は、基地局において、トラヒック量を監視し、閾値との比較を行なう。特許文献1は、閾値を超えたトラヒックに対して流入制御を行なうものである。さらに、特許文献2で示されている流入制御は、通信ネットワークおいて、アプリケーションのトラヒック種別を判別する。各アプリケーションのトラヒック量を監視し、各アプリケーションのトラヒックに対応した流入制御を行なう。これにより、利用上で問題の要因となっているアプリケーションのみ制御の対象とする。対象外のアプリケーションに関しては、ネットワークにおけるQoS(Quality of Service)を保持する。
【0006】
また、通信ネットワークにおいて、アプリケーションの性能劣化に対して柔軟に制御を行なうために、または要因切り分けのために、アプリケーション性能を監視することが一般的になっている。また、特許文献3は、アプリケーションサーバ性能とネットワーク性能の相関関係から、アプリケーションサーバ、管理対象ネットワーク、非管理対象ネットワークのいずれかに要因を切り分ける。すなわち、対象とするアプリケーショントラヒックと対象外のアプリケーショントラヒック比率の相関関係から、いずれのアプリケーションが性能劣化要因であるかを切り分ける。
【先行技術文献】
【特許文献】
【0007】
【特許文献1】特開平10−336734号公報
【特許文献2】特開2007−053465号公報
【特許文献3】特開2001−195285号公報
【発明の概要】
【発明が解決しようとする課題】
【0008】
移動体通信システムにおいて、アプリケーション性能は、基地局におけるトラヒック量による影響、同時に利用する多種のアプリケーションの影響、個々の端末の位置や移動状況の影響などを受ける。
【0009】
移動体通信システムにおける無線リソースは、複数の端末で共有して利用する。また、アプリケーションによって、パケット長およびパケット送信周期が異なる。この結果、アプリケーションの組合せによって、基地局における最大性能が変わる。また、無線帯域では、端末における基準電力の受信時の大きさにより、通信時の変調符号化方式を選択する。この結果、端末の受信状態、位置や移動状況により、送信スループットに差がでる。さらに、移動体通信システムは、無線帯域における効率良いデータ転送のため、小さいデータのパッキング機能を備えている。このため、一部のアプリケーションにパケットロスや破棄が集中する可能性が高い。また、TCP(Transmission Control Protocol)を用いた通信では、パケットロスなどが集中すると、著しく性能が劣化し、性能が元に戻るまでに非常に時間がかかる。
【0010】
よって、移動体通信は、上述したような影響を考慮して、アプリケーション性能劣化を検出すると共にその要因を分析する必要がある。また、アプリケーション性能劣化が、基地局全体のアプリケーションに波及する要因であるのか、個々アプリケーションフローにだけ出ている要因であるのかを切り分けることも必要である。
【0011】
特許文献1、特許文献2に示す流入制御では、基地局全体のトラヒック量、あるいは通信システムにおける個々のアプリのトラヒック量のみに着目している。その結果、トラヒック量以外の上述した移動体通信システム特有の影響を考慮できない。
【0012】
特許文献3に示すアプリケーション性能劣化要因の分析は、アプリケーションを意識している。しかし、有線におけるトラヒック量に着目した性能劣化要因の判断であり、上述した移動体通信システム特有の影響を考慮していない。
【0013】
本発明の目的は、移動体通信システムにおいて、上述した課題を解決し、多様なアプリケーションを利用している端末を収容している基地局において、アプリケーション性能劣化の有無を判断し、基地局全体に及んだ問題であるのか、個々のアプリケーションのフローの問題であるのかを切り分けることである。
【0014】
さらに他の目的は、アプリケーション性能劣化の要因を輻輳状態であるのか、端末の移動が多いことによるのか、端末の位置に問題があるのか、基地局以外に問題あるのかを切り分けを行ない、検出した結果として、基地局毎のアプリケーション利用状況、アプリケーション性能状態、劣化要因、保守員に求める対処の表示を提供することである。
さらに他の目的は、アプリケーション利用状況を考慮した流入制御を提供することである。
【課題を解決するための手段】
【0015】
上述した課題は、基地局とゲートウェイ間のパケットを監視し、パケットより、予め定めたアプリケーション選別基準に従い、アプリケーションフローの選別を行ない、単位時間当たりに個々のアプリケーションフロー対応に性能劣化が発生しているかどうかを判断し、各アプリケーションの種別ごとに、性能劣化が発生したアプリケーションフローの占める性能劣化比率を求め、基地局における単位時間当たりの各アプリケーションの利用比率を各アプリケーションフロー数とデータ量から求め、求めた利用比率と各アプリケーションにおける性能劣化比率から、予め定めたアプリケーション種別対応の利用比率と性能劣化基準に従い、基地局において性能劣化が発生しているかどうかを判断するアプリケーション性能劣化を検出するアプリケーション評価方法により、達成できる。
【0016】
また、基地局においてアプリケーション性能劣化が発生していると判断した場合、基地局における単位時間当たりのトータルスループットを、予め定めたアプリケーションの利用比率に応じた基地局における最低保証スループットと比較し、トータルスループットが最低保証スループットより大きい場合、トラヒック輻輳要因による性能劣化と判断し、トータルスループットが最低保証スループットより小さい場合、基地局におけるハンドオーバ実施回数を予め定めたハンドオーバ実施回数基準値と比較し、その基準値より大きい場合、移動要因による性能劣化と判断し、さらに、基地局における変調符号化方式対応の単位時間当たりの送信データ長から各変調符号化方式の利用比率を求め、求めた変調符号化方式の利用比率と予め定めた変調符号化方式の基準利用比率と比較し、利用比率が異なる場合、端末配置要因による性能劣化と判断するアプリケーション性能劣化要因を検出するアプリケーション評価方法により、達成できる。
【0017】
また、基地局とゲートウェイ間のパケットより、予め定めたアプリケーション選別基準に従い、アプリケーションフローの選別機能と、単位時間当たりに個々のアプリケーションフロー対応に性能劣化が発生しているかどうかを判断し、各アプリケーションの種別ごとに、性能劣化が発生したアプリケーションフローの占める性能劣化比率を求めるアプリケーションフロー性能評価機能と、基地局における単位時間当たりの各アプリケーションの利用比率を各アプリケーションフロー数とデータ量から求め、求めたアプリケーションの利用比率と各アプリケーションの性能劣化比率から、予め定めたアプリケーション種別対応の利用比率と性能劣化基準に従い、基地局において性能劣化が発生しているかどうかを判断する基地局のアプリ性能評価機能と、性能劣化が発生していると判断した場合、基地局における単位時間当たりのトータルスループットを、予め定めたアプリケーションの利用比率に応じた基地局における最低保証スループットと比較し、トータルスループットが最低保証スループットより大きい場合、トラヒック輻輳容易運による性能劣化と判断する機能と、トータルスループットが最低保証スループットより小さい場合、基地局におけるハンドオーバ実施回数を予め定めたハンドオーバ実施回数基準値と比較し、その基準値より大きい場合、移動要因による性能劣化と判断し、さらに、基地局における変調符号化方式対応の単位時間当たりの送信データ長から各変調符号化方式の利用比率を求め、求めた変調符号化方式の利用比率と予め定めた変調符号化方式の基準利用比率と比較し、利用比率が異なる場合、端末配置要因による性能劣化と判断する基地局の要因分析機能と、前期機能により検出したアプリケーション利用状況と基地局における性能劣化有無とその要因を結果として表示する結果表示機能とを備える評価装置より、達成できる。
【0018】
また、音声あるいは映像のデコード処理を行なう端末において、再生時刻における再生フレームなし、あるいは再生フレーム破棄のいずれかを検出した場合、その発生時刻と位置情報を記憶し、端末監視装置に通知し、端末監視装置において、収集した情報からアプリケーション性能劣化が発生していると判断した場合、評価装置に通知し、評価装置において、該当する基地局を求め、上述したアプリケーション性能劣化要因の検出する移動体運用システムにより、達成できる。
【0019】
また、基地局とゲートウェイ間のパケットより予め定めたアプリケーション選別基準に従い、アプリケーションの選別を行ない、基地局における単位時間当たりの各アプリケーションの利用比率を各アプリケーションフロー数とデータ量から求め、記憶し、アプリケーション利用比率が以前記憶した利用比率と異なる場合、求めたアプリケーション利用比率を基地局あるいはゲートウェイに通知し、基地局あるいはゲートウェイにおいて、予めアプリケーション利用率対応に定めたトラヒック流量に従い、基地局あるいはゲートウェイにおいてトラヒック流入制御を行なうトラヒック監視方法により、達成できる。
【0020】
また、計算した単位時間当たりのアプリケーション利用比率を、予め定めたアプリケーション利用組合せパターンのいずれかに分類し、そのパターンを記憶し、記憶しているパターンから変化した場合、求めたアプリケーション利用組合せパターンを基地局あるいはゲートウェイに通知し、基地局あるいはゲートウェイにおいて、予めアプリケーション利用組合せパターン対応に定めたトラヒック流量に従い、基地局あるいはGWにおいてトラヒック流入制御を行なうトラヒック監視方法により、達成できる。
【0021】
また、基地局とゲートウェイ間のパケットを監視するパケット監視装置と、パケット監視装置が抽出したパケットより、予め定めたアプリケーション選別基準に従い、アプリケーションフローの選別を行ない、単位時間当たりに個々のアプリケーションフロー対応に性能劣化が発生しているかどうかを判断するアプリフロー選別・性能評価機能と、各アプリケーションの種別ごとに、性能劣化が発生したアプリケーションフローの占める性能劣化比率を求め、基地局における単位時間当たりの各アプリケーションの利用比率を各アプリケーションフロー数とデータ量から求め、求めた利用比率と各アプリケーションにおける性能劣化比率から、予め定めたアプリケーション種別対応の利用比率と性能劣化基準に従い、基地局において性能劣化が発生しているかどうかを判断する基地局アプリ評価機能と、基地局における単位時間当たりのトータルスループットを、予め定めた利用比率に応じた基地局における最低保証スループットと比較し、トータルスループットが最低保証スループットより大きい場合、トラヒック輻輳要因による性能劣化と判断し、トータルスループットが最低保証スループットより小さい場合、基地局におけるハンドオーバ実施回数を予め定めたハンドオーバ実施回数基準値と比較し、その基準値より大きい場合、移動要因による性能劣化と判断し、さらに、基地局における変調符号化方式対応の単位時間当たりの送信データ長から各変調符号化方式の利用比率を求め、求めた変調符号化方式の利用比率と予め定めた変調符号化方式の基準利用比率と比較し、利用比率が異なる場合、端末配置要因による性能劣化と判断する基地局の要因分析機能とからなるアプリケーション評価機能を備えた評価装置と、移動体通信システム内の機器を管理制御する管理装置、移動体通信システム内の機器からの統計情報を格納するストレージおよび保守員の操作するオペレータ端末とから構成する移動体運用システムより、達成できる。
【0022】
また、パケット監視装置、アプリケーション評価装置、管理装置、ストレージ、オペレータ端末および端末からマルチメディア再生における性能劣化情報を収集する端末性能監視サーバとから構成する移動体運用システムにより、達成できる。
【発明の効果】
【0023】
移動体通信システムにおいて、多様なアプリケーションを利用している端末を収容している基地局におけるアプリケーション性能劣化とその要因を分析し、表示することにより、保守員における問題の把握と無線エリアの最適化を容易に実現できる環境を提供できる。
【図面の簡単な説明】
【0024】
図1】移動体通信システムとその運用管理システムの構成図である。
図2】評価装置の機能ブロック図である。
図3】端末の機能ブロック図である。
図4】端末監視装置の機能ブロック図である。
図5】アプリケーション評価処理の流れを示す図である。
図6】パケット監視装置におけるパケット監視処理の処理フローである。
図7】オペレータポリシであるアプリフロー選別基準の構成を示すテーブルである。
図8】オペレータポリシであるアプリフロー性能劣化基準の構成を示すテーブルである。
図9】評価装置が実施するアプリフロー選別・性能評価処理の処理フローである。
図10】評価結果エントリの構成を示すテーブルである。
図11】オペレータポリシである基地局のアプリ比率パターンの構成を示すテーブルである。
図12】オペレータポリシである基地局の性能劣化基準の構成を示すテーブルである。
図13】評価装置が実施する基地局の性能評価処理の処理フローである。
図14】オペレータポリシである基地局の最低保証スループットの構成を示すテーブルである。
図15】基地局統計情報の構成を示すテーブルである。
図16】オペレータポリシである基地局の無線帯域利用基準の構成を示すテーブルである。
図17】評価装置が実施する基地局の要因分析処理を示す処理フローである。
図18】評価装置が実施する要因分析案検討処理の処理フローである。
図19】アプリケーション評価処理のマップ表示結果である。
図20】基地局のアプリ利用状況を表示した結果である。
図21】基地局のアプリ性能劣化と要因分析結果を表示した結果である。
図22】端末が実施するデコード処理の処理フローである。
図23】端末監視装置における端末監視処理の処理フローである。
【発明を実施するための形態】
【0025】
以下、本発明の実施の形態について、実施例を用い図面を参照しながら、詳細に説明する。なお、実質同一部位には同じ参照番号を振り、説明は繰り返さない。
【0026】
図1を参照して、移動体通信システムとその運用管理システム100の構成を説明する。図1において、移動体通信システムは、端末600と、基地局109と、ネットワークスイッチ(以下SW)115と、サービングゲートウェイ(以下S−GW)110、と、認証サーバ111と、ホームエージェント(以下HA)112とから構成されている。
【0027】
基地局109(109A、109B)は、複数の端末600を無線で接続し収容する。S−GW110は、複数基地局109と接続し、ハンドオーバ管理などを行なう。認証サーバ111は、端末との認証を行なう。HA112は、異種移動体通信システムや事業者の異なる移動体通信システムとの移動管理を行なう。SW115(115A〜115B)は、各機器を接続する。
【0028】
移動体通信システムは、パケットゲートウェイ(以下P−GW)113を介して、オペレータの固定IPネットワーク114に接続している。
移動体管理システムの運用管理システム100は、エレメントマネージメントシステム(以下EMS)105(105A、105B)と、ネットワークエレメントマネジャー(以下NEM)106と、ストレージ104と、端末監視装置103と、パケット監視装置102と、評価装置700と、SW115Cと、オペレータ端末107とから構成されている。
【0029】
EMS105は、基地局109およびS−GW110から統計情報を収集し、各機器へのパラメータを設定するなどの管理機能を提供する。NEM106は、複数EMS105を統括管理する。ストレージ104は、収集した統計情報を格納する。端末監視装置103は、端末600からのアプリケーション性能劣化情報を収集する。パケット監視装置102は、基地局109とS−GW110間のトラヒックを監視する。評価装置700は、アプリケーション性能を評価する。オペレータ端末107は、運用管理システム100内の各機器にアクセスするための保守員が操作する。
【0030】
図2を参照して、評価装置700の構成を説明する。図2において、評価装置700は、制御部116と、記憶部117と、ネットワークインタフェース部118とから構成されている。制御部116は、記憶部117に格納されているプログラムであるアプリフロー選別・性能評価処理210、基地局のアプリ性能評価処理220、基地局の要因分析処理230、要因分析案提示処理240、結果表示処理119を実行する。記憶部117には、プログラムに加えて、評価結果エントリ120と、オペレータポリシ125とを記憶する。
【0031】
評価結果エントリ120は、処理に用いる。オペレータポリシ125は、基準値である。オペレータポリシ125は、アプリフロー選別基準140、アプリフロー性能劣化基準150、基地局のアプリ性能劣化基準160、基地局のアプリ比率パターン170、基地局の最低保証スループット180、基地局の無線帯域利用基準190を持つ。
【0032】
図3を参照して、端末600の構成を説明する。図3において、端末600は、制御部610と、記憶部620と、ネットワークインタフェース部630と、ユーザ入力インタフェース部640と、表示ディスプレイ650とで構成されている。制御部610は、記憶部620に格納されているプログラムであるデコード処理611を実行する。記憶部620は、プログラムに加えて、再生コンテンツ621、アプリ品質情報622を記憶する。ネットワークインタフェース部630は、基地局109とのインタフェース部である。
【0033】
図4を参照して、端末監視装置103の構成を説明する。図4において、端末監視装置103は、制御部710と、記憶部720と、ネットワークインタフェース部730とから構成されている。制御部710は、記憶部720に格納されているプログラムである端末監視処理711を実行する。記憶部720は、プログラムに加えて、アプリ品質情報721を記憶する。
【0034】
図5を参照して、評価装置700が実施するアプリケーション評価処理200を説明する。図5において、評価装置700は、パケット監視装置102が実施するパケット監視処理250と、端末監視装置103が実施する端末監視処理280を受けて、アプリケーション評価処理200を実行する。評価装置700において、アプリケーション評価処理200は、以下のステップで処理を行なう。評価装置700は、第1のステップのアプリフロー選別・性能評価処理210として、パケット監視装置102から通知されたパケットから、アプリケーション選別と個々のアプリケーションの性能評価を行なう。評価装置700は、第2ステップの基地局109のアプリ評価処理220として、アプリケーション性能劣化が、処理フローに個々依存しているものであるのか、基地局109全体に及んだ問題であるのかの切り分けを行なう。評価装置700は、第3ステップの基地局の要因分析処理230として、基地局109においてトラヒック輻輳要因によりアプリケーション性能劣化が発生しているかどうか、さらに基地局109における端末600の移動要因、あるいは端末600の配置要因によりアプリケーションの性能劣化が発生しているかどうかを確認する。評価装置700は、第4ステップの要因分析案検討処理240として、第3ステップで要因が明らかにならなかった場合、保守員が対応すべき行動推奨案を検討する。評価装置700は、第5ステップの結果表示処理119において、各ステップで得た結果を表示する。保守員は、この結果を見て解析を行ない、基地局設定変更や基地局増設などを検討し、システムの最適化を実施する。
【0035】
以下、各処理の詳細について説明していく。
図6を参照して、パケット監視装置102におけるパケット監視処理250の処理フローを説明する。図6において、パケット監視装置102は、第1ステップとして、S−GW110と基地局109間を通過するパケットをキャプチャし、キャプチャした時刻をタイムスタンプとして記憶する(S251)。パケット監視装置102は、第2ステップとして、キャプチャしたパケットから、IPパケットを抽出し、Source IPアドレスとポート番号、Destination IPアドレスとポート番号、IPパケットからIPヘッダを除いたデータ長、トランスポートプロトコル種別、タイムスタンプ、S−GW110と基地局109間のパス識別子、S−GW110と基地局109間のパケット通信方向といった情報をパケットエントリとして記憶する(S252)。パケット監視装置102は、第3ステップとして、単位時間が経過しているかどうかを確認する(S253)。経過していなければ(NO)、パケット監視装置102は、ステップ251に戻って、このパケットキャプチャとパケットエントリ作成処理を単位時間の間実施する。ステップ253で単位時間が経過していれば(YES)、パケット監視装置102は、第4のステップとして、記憶したパケットエントリをアプリケーション評価装置に転送して(S254)、終了する。なお、パケットエントリの情報は、ストレージ104を介して、パケット監視装置102と評価装置700で共有してもよい。
【0036】
以下、評価装置700が実施するアプリフロー選別・性能評価処理210の詳細について説明する。
【0037】
図7を参照して、アプリフロー選別・性能評価処理210を実施する際に利用するオペレータポリシとして、事前に定めておくアプリフロー選別基準140の構成を説明する。図7において、アプリフロー選別基準140のテーブルは、アプリフロー種別141、トランスポートプロトコル種別142、通信方向143、分類条件144から構成されている。
【0038】
トランスポートプロトコル種別142は、TCPあるいはUDPを表示する。通信方向143は、S−GW110から基地局109方向のダウンリンク(以下DL)または基地局109からS−GW方向のアップリンク(UL)を示す。分類条件144は、パケットからアプリを選別する際の分類条件である。ここでは、アプリフロー種別141は、VoIPタイプ、動画タイプ、ダウンロードタイプ、アップロードタイプ、制御タイプを、分類条件144は、データ長とパケット間隔として示している。
【0039】
図8を参照して、アプリフロー選別・性能評価処理210を実施する際に利用するオペレータポリシとして、事前に定めておくアプリフロー性能劣化基準150の構成を説明する。図8において、アプリフロー性能劣化基準150は、アプリフロー種別151と性能劣化基準152から構成する。ここでは、性能劣化基準152は、パケット間隔とその発生頻度および平均スループットとして示している。
【0040】
図9を参照して、評価装置700が実施するアプリフロー選別・性能評価処理210の処理フローを説明する。図9において、評価装置700は、第1ステップとして、パケット監視装置102から通知されたパケットエントリを読出す(S211)。評価装置700は、第2ステップとして、読み出したパケットエントリの情報から、アプリケフロー選別基準140に従って、アプリケーションの選別を行なう(S212)。さらに、評価装置700は、第3ステップとして、各アプリフローにおいて、アプリケーションの性能劣化が発生しているかを確認するため、周期的にパケットをやり取りするVoIPタイプと動画タイプであるかを確認する(S213)。VoIPタイプあるいは動画タイプである場合(YES)、評価装置700は、第4ステップとして、アプリフロー性能劣化基準150に従って、パケット間隔が基準値よりも大きいかどうかをチェックし、大きい場合パケット受信間隔違反回数として、アプリフロー毎に記憶する(S213)。さらに、評価装置700は、第5ステップとして、単位時間当りのパケットエントリの処理が完了しているかどうかを確認する(S215)。完了していなければ、評価装置700は、ステップ211に遷移する。ステップ215で完了していれば、評価装置700は、第6ステップとして、アプリフロー毎にパケット受信間各違反の頻度、平均スループットを求め、アプリフロー性能劣化基準150の基準値と比較し、アプリフロー毎に性能劣化が発生しているかを判断し、その結果をアプリフロー毎に記憶する(S216)。評価装置700は、第7ステップとして、評価結果エントリ120を作成して(S217)、終了する。なお、ステップ213でNOのとき、ステップ214をジャンプする。
【0041】
図10を参照して、単位時間毎に評価装置700がアプリフロー選別、性能評価処理210のステップ217で作成する評価結果エントリ120の構成を説明する。図10において、評価結果エントリ120は、時刻121、単位時間当たりのダウンリンクとアップリンクのそれぞれのトータルデータ長122(122A、122B)、アプリケーション種別と通信方向対応に纏めるアプリケーション情報エリア130(130A、130B)と、選別できなかったアプリである非選別アプリのデータ量比率123および「基地局における性能劣化」時の要因を記録するエリア124から構成する。アプリケーション情報エリア130は、同一種類、同一通信方向のアプリフロー別に、アプリフロー種別131、トータルデータ長132、該当アプリフロー数133、通信方向134、単位時間当たりのアプリケーション利用比率を示すアプリフロー比率135、アプリデータ量比率136、プリフロー毎に性能劣化と判断したアプリフローの総数を示すアプリフロー数137およびそのアプリフロー識別情報138、アプリフローにおける性能劣化要因を記録するエリア139から構成する。
【0042】
次に評価装置700で行なう基地局の性能評価処理220の詳細について説明する。
図11を参照して、基地局の性能評価処理220を実施する際に利用するオペレータポリシとして、事前に定めておく基地局のアプリ比率パターン170の構成を説明する。図11において、基地局700のアプリ比率パターン170は、アプリ比率パターン171対応にアプリ比率172を定めているものであり、アプリ比率172のエリアとしては、通信方向とアプリフロー種別のアプリ比率から構成する。
【0043】
図12を参照して、基地局の性能評価処理220を実施する際に利用するオペレータポリシとして、事前に定めておく基地局のアプリ性能劣化基準160の構成を説明する。図12において、基地局のアプリ性能劣化基準160は、アプリフロー種別161対応のアプリケーション性能劣化基準162を定めたものである。アプリケーション性能劣化基準162は、アプリ比率とそのアプリ比率を満たしている場合の性能劣化基準として、各アプリ種別161における性能劣化検出したアプリフローの割合として性能劣化比率を示す。
【0044】
図13を参照して、評価装置700で行なう基地局の性能評価処理220の処理フローを説明する。図13において、評価装置700は、第1ステップとして、評価結果エントリ120の合計データ長122と各アプリケーション情報エリア130の合計データ長132から(式1)を用いて、アプリフロー別のアプリデータ量比率を求める(S221)。
【0045】
(アプリフロー別データ量比率)=(アプリケーション情報エリアの合計データ長)/(評価結果エントリの合計データ長)
…(式1)
評価装置700は、第2ステップとして、求めたデータ比率を、評価エントリ120のアプリケーション情報エリア130のアプリデータ量比率136として格納する(S222)。評価装置700は、第3ステップとして、アプリフローを選別できなかったアプリデータ量比率を(式2)から求め、評価結果エントリ120の非アプリ選別のデータ量比率123に格納する(S223)。
【0046】
(非アプリ選別のデータ量比率)=1−Σ(アプリフロー別データ量比率) …(式2)
評価装置700は、第4ステップとして、各アプリケーション情報エリア130のアプリフロー数133から(式3)を用いてアプリフロー率を求める(S224)。
【0047】
(アプリフロー率)=(アプリケーション情報のアプリフロー数)/Σ(アプリケーション情報のアプリフロー数)
…(式3)
評価装置700は、第5ステップとして、各アプリフロー率と非アプリ選別のデータ量比率から(式4)を用いて、アプリフロー比率を求め、評価結果エントリ120のアプリケーション情報エリア130のアプリフロー比率137として格納する(S225)。
【0048】
(アプリフロー比率)=(1−(非アプリ選別のデータ量比率))*(アプリフロー率) …(式4)
評価装置700は、第6ステップとして、求めたアプリデータ量比率136とアプリフロー比率137から、基地局のアプリ比率パターン170に従って、対応するパターンを検出する(S226)。評価装置700は、第7ステップとして、前回の評価処理時に検出したパターンと変化しているか判定する(S227)。変化している場合(YES)、評価装置700は、第8ステップとして、該基地局109とその基地局109に接続しているS−GW110に対して検出したアプリ比率パターンを通知する(S228)。
【0049】
ステップ227でNOのとき、またはステップ228の後、評価装置700は、第9ステップとして、基地局のアプリ性能劣化基準160に従って、アプリ種別対応に性能劣化が基地局109全体に及んでいるかどうかを、アプリ種別対応に性能劣化を検出したアプリフロー数から求める性能劣化比率と基地局のアプリ性能劣化基準160の性能劣化基準値と比較して確認して(S229)、終了する。ステップ229により、性能劣化が基地局109全体に及んでいないと判断した場合、評価装置700は、評価結果エントリ120のアプリケーション情報エリア130の要因139に「アプリフローによる」と記録する。基地局109における性能劣化が発生していると判断した場合、評価装置700は、評価結果エントリ120のアプリケーション情報エリア130の要因139に「基地局における性能劣化」を記録する。
【0050】
ステップ228において、アプリ比率パターンを通知された基地局109またはS−GW110は、予め定められているアプリ比率パターン対応に定められているトラヒック制御を実施するアプリフロー対応の閾値を参照して、トラヒック流入制御を行なう。さらに、ステップ228において、アプリ比率パターンを通知された基地局109は、端末600に対して、現状のネットワーク利用状況として、アプリ比率パターンと各アプリケーションのトラヒックと閾値との関係を通知し、端末600において通知された情報を図示して表示してもよい。
【0051】
以下、ステップ229において、基地局109において性能劣化が発生していると確認した場合、つまり評価結果エントリ120のアプリケーション情報エリア130の要因139に「基地局における性能劣化」と記録した場合、評価装置700が行なう基地局の要因分析処理230の詳細について説明する。
【0052】
図14を参照して、評価装置700が基地局の要因分析処理230を実施する際に利用するオペレータポリシとして、事前に定めておく基地局の最低保証スループット180の構成を説明する。図14において、基地局の最低保証スループット180は、図11で定めたアプリ比率パターン181と、それに対応した基地局対応の最低保証スループット182から構成する。この基準は、その後、基地局の特徴を反映してもよい。この場合、基地局ごと異なる基準を持つことになる。ここで、基地局の特徴とは、基地局ベンダーごとの実装の違い、ビルが多いまたは見晴らしがよい等の電波環境の違い等である。
【0053】
図15を参照して、基地局109からEMS105を介してNEM106に周期的に収集され、ストレージ104に保存された基地局統計情報290の構成を説明する。図15において、基地局統計情報290は、基地局識別子291、取得時刻292、ハンドオーバ293、変調符号化方式294から構成されている。ハンドオーバ293は、ハンドオーバ実施数とハンドオーバ成功数とからなる。変調符号化方式294は、変調符号化方式対応のデータ長の情報である。
【0054】
図16を参照して、評価装置700が劣化要因分析処理を実施する際に利用するオペレータポリシとして、事前に定めておく基地局の無線帯域利用基準190の構成を説明する。図16において、基地局の無線帯域利用基準190は、基地局の置局時に想定したハンドオーバ実施回数191、一様に端末が配置していると想定した場合の各変調符号化方式の利用比率192から構成する。この基準は、その後、基地局における特徴を反映して変更してもよい。この場合、基地局ごとに異なる基準を持つことになる。
【0055】
図17を参照して、評価装置700が行なう基地局の要因分析処理230を示す処理フローを説明する。図17において、評価装置700は、第1のステップとして、基地局109の最低保証スループットに従って、アプリ比率パターンに対応した最低保証スループットと、評価結果エントリ120のトータルデータ長122から計算したスループットを比較する(S231)。計算したスループットが最低保証スループットより大きい場合(NO)、評価装置700は、性能劣化要因をトラヒック輻輳とし,評価結果エントリ120の要因エリア124に記録して(S232)、終了する。ステップ231で小さい場合(YES)、評価装置700は、第2のステップとして、基地局の無線帯域利用基準190のハンドオーバ実施回数191と、基地局統計情報290のハンドオーバ実施数293と比較する(S233)。ハンドオーバ実施数が基地局の無線帯域利用基準190のハンドオーバ実施回数より多い場合(YES)、性能劣化要因をハンドオーバ多発とし,評価結果エントリ120の要因エリア124に記録する(S234)。ステップ233でNOのとき、またはステップ234の後で、さらに、評価装置700は、第3のステップとして、基地局統計情報290の変調符号化方式294のそれぞれのデータ長から、それぞれの利用率を求め、基地局の無線帯域利用基準190の変調符号化利用比率192と比較する(S235)。比率が異なる場合(YES)、評価装置700は、性能劣化要因を端末配置として,評価結果エントリ120の要因エリア124に記録して(S236)、終了する。ステップ235でNOのとき、評価装置700は、評価結果エントリ120の要因エリア124に要因不明を記録し,終了する。
【0056】
次に評価装置700は、基地局の要因分析処理230で要因が検出できていない場合、要因分析案検討処理240を行なう。
図18を参照して、評価装置700が行なう要因分析案検討処理240の処理フローを説明する。図18において、評価装置700は、第1ステップとして、評価結果エントリ120の非選別アプリのデータ量比率123が50%を超えているかどうかを確認する(S241)。超えている場合(YES)、評価装置700は、第2ステップとして、性能劣化要因として、アプリフロー選別基準見直し要とトラヒック再分析要とし,評価結果エントリ120の要因エリア124に記録して(S242)、終了する。ここでは、評価装置700は、保守員によるパケットの詳細分析により、新たなアプリケーション利用が増えていないかどうかを確認することを推奨する。
【0057】
次に、ステップ241で超えていない場合(NO)、評価装置700は、アプリフロー毎にアプリケーションの性能劣化を検出したアプリフローの通信先の同一率が50%以上かを確認する(S243)。以上の場合、評価装置700は、第4ステップとして、性能劣化要因をサーバ側負荷確認要とし,評価結果エントリ120の要因エリア124に記録して(S244)、終了する。ここでは、評価装置700は、アプリケーションサーバ側の負荷が高い可能性があるので、サーバ側の負荷を確認するように推奨する。
【0058】
次に、ステップ243でNOのとき、評価装置700は、第5ステップとして、性能劣化要因が解析できていない状況が連続しているかを確認する(S245)。続いている場合(YES)、評価装置700は、第6ステップとして、性能劣化要因をアプリ性能劣化要因不明連続発生として(S246)、終了する。ここでは、評価装置700は、保守員に対して、基地局状態、ネットワーク状態の確認を推奨し、原因の究明を進める。ステップ245でNOのとき、評価装置700は、そのまま終了する。
【0059】
以下、評価装置700において、結果表示処理119において作成する、オペレータ端末107に表示する表示結果について説明する。
図19を参照して、アプリケーション評価処理結果300を説明する。図19において、アプリケーション評価処理結果300は、アイコン301と、マップ表示結果302と、解析結果303とからなる。アイコン301は、表示期間を選択する。マップ表示結果302は、選択した表示期間の基地局における性能劣化要因をマップ表示する。表示期間301は、マップ表示結果302と解析結果303を表示する日時と期間を選択するものである。図19では、期間は、3時間単位、1日単位、1週間単位で可能である。マップ表示結果302は、基地局109対応に表示期間301で指定された期間において、性能劣化要因ごとにマップ上に表示するものである。2つ以上の性能劣化要因がある場合は、重複した発生がわかるように表示する。図19では、トラヒック輻輳とハンドオーバの性能劣化要因が重複発生している基地局109を示している。解析結果303は、マップ表示結果302の性能劣化要因を示すとともに、保守員に対して推奨する行動を示す。
【0060】
トラヒック輻輳発生の場合、基地局109におけるトラヒック量の確認および周囲の基地局109のロードバランスの確認を推奨する。この結果として、トラヒック量に耐えられないエリアであると判断した場合、保守員は基地局109におけるハンドオーバ閾値のパラメータを変更や、基地局増設の実施を検討することになる。ハンドオーバが多発している場合、基地局のロードバランスの確認および周囲の基地局109がカバーしている範囲の変更検討を推奨する。この結果として、保守員は基地局109におけるハンドオーバ閾値のパラメータ変更やアンテナチルドの変更の実施を検討することになる。端末配置不均等発生の場合、周囲の基地局109のロードバランスの確認および基地局109に想定している処理性能の見直しを推奨する。この結果、保守員は基地局109におけるハンドオーバ閾値のパラメータ変更や、アンテナチルドの変更、基地局109に接続する端末600の配置を考慮した基地局109の許容トラヒックを以前より小さく設定するように基地局関連の制御パラメータを設定の実施を検討することになる。アプリ選別がきていないトラヒック多発する場合、新たなアプリケーションの利用により、新たなトラヒックが発生している可能性があることから、トラヒック分析を行なうことを推奨する。保守員によるトラヒック分析により、新たなアプリケーションが利用されているようであれば、オペレータポリシにアプリフローとして追加する。アプリ性能劣化要因不明連続発生の場合、基地局状態とネットワーク状態を確認することを推奨する。保守員は、基地局109にアプリケーション評価処理200では見つけられてない問題、例えばハードの不調や、ネットワーク内での輻輳発生など、他の問題と関連付けて原因を究明する必要がある。
【0061】
図20を参照して、保守員の上述した作業を補助するための基地局毎のアプリ利用状況の表示結果304を説明する。図20において、表示情報は、日か週で選択する表示期間306、ダウンロードとアップロードのアプリフローごとのスループット変動と、アプリ比率変動305からなる。この結果より、保守員が日々のユーザのアプリケーション利用傾向を把握することを助ける。
【0062】
図21を参照して、保守員の作業を補助するための基地局におけるアプリ性能劣化と要因分析結果307を説明する。図21において、基地局におけるアプリ性能劣化と要因分析結果307の表示情報は、アップロードとダウンロードのトラヒック選択アイコン308と、1週間の結果を日単位に、ダウンロードとアップロードを別のアプリフロー別のトラヒック変動309(309A、309B)からなる。トラヒック変動の結果上にアプリケーション性能評価により検出したアプリケーション性能劣化ポイントと分析した要因を表示する。日単位の結果を同時に表示することにより、保守員が日々の傾向を把握することを助ける。
【0063】
以下、端末600におけるアプリケーション性能劣化検出方法について説明する。
図22を参照して、端末600におけるアプリケーションの品質劣化を検出するデコード処理260の処理フローを説明する。図22において、デコード処理260は、端末600がVoIPや映像の再生といったアプリケーションを使用している場合、音声フレームや映像フレームのデコード処理中に品質劣化を検出する処理である。デコード処理260において、端末600は、第1ステップとして、デコード処理停止あるいは一定時間が経過しているかを確認する(S261)。デコード処理停止や一定時間経過していない場合(NO)、端末600は、第2ステップとして、音声フレームや映像フレームの再生時刻となっているかを確認する(S262)。再生時刻となっている場合(YES)、端末600は、第3ステップとして、再生フレームの有無を確認する(S263)。再生フレームがある場合、端末600は、第4ステップとして、再生時刻が再生フレームの持つ再生時刻より前か判定する(S264)。NOのとき、端末600は、再生時刻と再生フレームの持つ再生時刻が一致していることを確認する(S265)。YESのとき、端末600は、第5ステップとして、デコード処理を行なって(S266)、ステップ261に遷移する。
【0064】
再生フレームが無かった場合(S263:NO)、または再生時刻よりも先を示す再生時刻持つ再生フレームの場合(S264:YES)、端末は600、第6ステップとして、要因をフレーム無し、発生時刻、発生場所をアプリ品質情報として記録して(S267)、ステップ261に遷移する。
【0065】
ステップ265でNOのとき、端末600は、第7ステップとして、再生時刻よりも以前の再生時刻を持つ再生フレームを破棄する(S268)。端末600は、第8ステップとして、要因をフレーム破棄、発生時刻、発生場所をアプリ品質情報として記録して(S269)、ステップ261に遷移する。
【0066】
ステップ261でYESのとき、端末600は、第9ステップとして、保存してあるアプリ品質情報を端末監視装置に通知する(S270)。端末600は、デコード処理を停止するか判定する(S271)。停止するとき、端末600は、終了する。ステップ271で停止しないとき(NO)、端末600は、ステップ261に遷移する。
このように、端末600は、デコード処理中の再生フレームの有無と破棄を監視し、それが発生した時刻と発生場所を記憶し、端末監視装置103に通知する。
【0067】
図23を参照して、アプリ品質情報を受け付けた端末監視装置103における端末監視処理280の処理フローを説明する。図23において、端末監視装置103は、第1ステップとして、報告されたアプリ品質情報から発生頻度を求め、アプリ性能劣化が発生しているかどうかを、予め定めたフレームロス発生頻度基準と比較して判定する(S281)。アプリ性能劣化を検出した場合(YES)、端末監視装置103は、第2ステップとして、アプリ品質情報の発生場所と発生時刻から、ストレージ104に格納している基地局600を設置した置局情報と端末統計情報に含まれる接続基地局の情報を利用して、端末600が接続していた基地局109を抽出する(S282)。端末監視装置103は、第3ステップとして、アプリ品質情報の発生場所を基地局の情報に置き換える(S283)。端末監視装置103は、第4ステップとして、アプリ性能劣化を検出した対象のアプリ品質情報を評価装置700へ転送して(S284)、終了する。ステップ281でNOのとき、端末監視装置103は、そのまま終了する。
【0068】
評価装置700は、端末監視装置103からのアプリ品質情報を受信した後、上述したようにアプリケーション評価処理200における基地局の性能評価処理220、基地局の要因分析処理230、要因分析案検討処理240、結果表示処理119を行なう。評価装置700は、アプリケーションの性能劣化とその要因の解析結果を保守員に表示する。これにより、評価装置700は、アプリケーション性能劣化の対応を推奨するとともに、最適化の実施を導いていく。
【符号の説明】
【0069】
100…運用管理システム、102…パケット監視装置、103…端末監視装置、104…ストレージ、107…オペレータ端末、109…基地局、110…S−GW、600…端末、700…評価装置。
図1
図2
図3
図4
図5
図6
図7
図8
図9
図10
図11
図12
図13
図14
図15
図16
図17
図18
図19
図20
図21
図22
図23