(57)【特許請求の範囲】
【請求項１】
監視ツールをインストールされたモバイルデバイスを含む通信ネットワークの性能を決定する方法であって、
前記モバイルデバイスから少なくとも１つのサーバにメッセージを送信するステップであり、前記少なくとも１つのサーバが、前記メッセージを前記モバイルデバイスに向けて送り返すように構成された、ステップと、
前記少なくとも１つのサーバのうちの各サーバによって返された前記メッセージを前記モバイルデバイスにおいて受信するステップと、
前記モバイルデバイスが前記メッセージを送信してから、前記少なくとも１つのサーバのうちの各サーバによって返された前記メッセージを前記モバイルデバイスが受信するまでの時間差を計算するステップと、
前記計算された時間差を、前記少なくとも１つのサーバから選択された第１のサーバに、記憶されるように転送するステップと、
を含む方法。
【請求項２】
前記モバイルデバイスによって前記少なくとも１つのサーバのうちの各サーバに送られる前記メッセージが、前記モバイルデバイスの識別番号（ＭＩＮ）を含む、請求項１に記載の方法。
【請求項３】
前記モバイルデバイスの識別番号が前記第１のサーバに登録されている、請求項２に記載の方法。
【請求項４】
前記少なくとも１つのサーバのうちの各サーバが、前記メッセージを前記モバイルデバイスに向けて送り返すときに前記メッセージにタイムスタンプを付加するように構成された、請求項１〜３のいずれか一項に記載の方法。
【請求項５】
計算する前記ステップが、前記メッセージが前記少なくとも１つのサーバのうちの各サーバに到達するための搬送時間を計算するステップをさらに含む、請求項４に記載の方法。
【請求項６】
計算する前記ステップが、前記メッセージが前記少なくとも１つのサーバのうちの各サーバから前記モバイルデバイスに到達するための搬送時間を計算するステップをさらに含む、請求項４又は５に記載の方法。
【請求項７】
前記時間差が前記メッセージの総ラウンドトリップ時間を示す、請求項１〜６のいずれか一項に記載の方法。
【請求項８】
前記メッセージを前記少なくとも１つのサーバに送信する前記ステップが一定の間隔で実施される、請求項１〜７のいずれか一項に記載の方法。
【請求項９】
各送信間の前記間隔が所定の時間に設定される、請求項８に記載の方法。
【請求項１０】
前記少なくとも１つのサーバから選択された第２のサーバが、前記計算された時間差の変動に基づいて前記所定の時間の長さを動的に変えるように構成された、請求項９に記載の方法。
【請求項１１】
前記計算された時間差を第１のサーバに転送する前記ステップが、前記モバイルデバイスのタイプ、前記メッセージの送信に使用されたアプリケーション、前記モバイルデバイスと前記通信ネットワークとの間の接続モード、モバイル加入者のユーザＩＤ、前記モバイルデバイスの識別番号、セル識別、及び前記モバイルが位置するセクタ番号に関する情報を転送することをさらに含む、請求項１〜１０のいずれか一項に記載の方法。
【請求項１２】
前記時間差と、モバイルデバイスの前記タイプ、前記メッセージの送信に使用された前記アプリケーション、前記モバイルデバイスと前記通信ネットワークとの間の前記接続モード、前記モバイル加入者の前記ユーザＩＤ、前記モバイルデバイスの前記識別番号に関する前記情報とに基づいて、前記ネットワーク内の１つ又は複数のセルについての報告を策定するステップをさらに含む、請求項１１に記載の方法。
【請求項１３】
前記モバイルデバイスが前記少なくとも１つのサーバから返送された前記メッセージを受信するための事前設定済み期間が切れたときに、設定済み時間差を前記第１のサーバに転送するステップをさらに含む、請求項１〜１２のいずれか一項に記載の方法。
【請求項１４】
前記第２のサーバが、前記所定の時間の前記変動に従って前記モバイルデバイスが前記少なくとも１つのサーバから返送された前記メッセージを受信するための事前設定済み期間を変えるようにさらに構成された、請求項１０に記載の方法。
【請求項１５】
請求項１〜１４のいずれか一項に記載の方法を実施するための専用アプリケーションを備えるモバイルデバイス。
【請求項１６】
前記専用アプリケーションが前記モバイルデバイス上の１つ又は複数の補助アプリケーションを利用して前記メッセージを前記サーバに送る、請求項１５に記載のモバイルデバイス。
【請求項１７】
前記専用アプリケーションが、前記モバイルデバイス上にインストールされたホストアプリケーション中に組込みアプリケーションとして組み入れられた、請求項１５又は１６に記載のモバイルデバイス。
【請求項１８】
前記ホストアプリケーションがメッセージング機能を備え、前記専用アプリケーションが、前記ホストアプリケーションの前記メッセージング機能を使用して、計算された時間差に関するフィードバックをユーザに提供するように構成された、請求項１７に記載のモバイルデバイス。
【請求項１９】
前記専用アプリケーションを前記少なくとも１つのサーバのうちの各サーバによって非アクティブ化することができる、請求項１５〜１８のいずれか一項に記載のモバイルデバイス。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークの性能を分析するためのシステム及び方法に関する。排他的ではないが特に、本発明は、モバイル遠隔通信システムのためのネットワーク監視ツールの提供に関する。
【背景技術の考察】
【０００２】
モバイルネットワークは、非常に多くのコンポーネントを含み、該コンポーネントは、無線ネットワークコントローラから、多数のファイアウォール、ルータ、及び他のデバイスを備えるゲートウェイＧＰＲＳサポートノード（ＧＧＳＮ）までにわたる。モバイルネットワークを介したデータサービスは、基礎をなす技術が何であろうと、比較的最近の開発にとどまる。このことから、モバイルキャリアは今なお、これらのデータネットワークをモバイルキャリアが監視、調整、及びアップグレードできるようにするための手順及びツールを開発中である。
【０００３】
通常、キャリアは、パケットコアのインフラストラクチャ中への幅広いモニタ及びプローブを実装して、パケットコアの性能を監視することができる。しかし、データネットワークに関する場合、「ユーザ体験」の進行中の監視を提供するための現行方法はない。データサービスのユーザ体験は、場所及び多くの様々な他の要因により、大きく異なる可能性がある。例えば、ネットワークパケットコアは非常によく機能している可能性があるが、セルタワーが正しく整合されていない場合は、特定エリア中の多くのユーザが、低いネットワーク性能を体験する可能性がある。パケットコアを越えた可視性がないとすれば、この環境で一貫したユーザ体験を提供することは問題である。
【０００４】
パケットコアを越えたネットワークの性能に関するデータを提供できる監視ツールを実現することが、明らかに有利であろう。また、キャリアによって供給されるモバイルメッセージングクライアントに、隠されたペイロードとして配置できる監視ツールを提供し、それによりネットワーク全体にわたって大量のテストを実施できるようにすることも有利であろう。
【発明の概要】
【課題を解決するための手段】
【０００５】
本発明の一態様によれば、通信ネットワークの性能を決定する方法が提供され、前記方法は、
モバイルデバイスから、メッセージをモバイルデバイスに向けて送り返すように構成された１つ又は複数のサーバに、メッセージを送信するステップと、
前記１つ又は複数のサーバによって返されたメッセージをモバイルデバイスにおいて受信するステップと、
前記モバイルデバイスがメッセージを送信してから、前記モバイルデバイスが１つ又は複数のサーバによって返されたメッセージを受信するまでの時間差を計算するステップと、
計算された時間差を、前記１つ又は複数のサーバから選択された第１のサーバに、記憶されるように転送するステップと、
を含む。
【０００６】
適切には、モバイルデバイスによって１つ又は複数のサーバに送られるメッセージは、サーバのうちの少なくとも１つに登録された、モバイルデバイスの識別番号（ＭＩＮ）を含む。メッセージは、プロセスをユーザからトランスペアレントに保つために、またユーザ体験に悪影響を及ぼす可能性のある不要なオーバーヘッドを防止するために、十分に小さく維持される。適切には、メッセージは約１００バイト前後である。
【０００７】
好ましくは、各サーバは、メッセージをモバイルデバイスに向けて送り返すときにメッセージにタイムスタンプを付加して、監視ツールがメッセージのラウンドトリップの送出区間及び入来区間についての時間を計算できるようにする。
【０００８】
メッセージを送信するステップは、一定の間隔で実施することができる。適切には、モバイルデバイスのバッテリ寿命に悪影響を及ぼさないために、各メッセージ送信間の間隔は、プロセスにおいて必要とされる電力消費を最小限に維持するように設定される。例えば、各送信間の間隔は、５５〜６１分の期間に設定することができる。第１のサーバは、より詳細なテストデータを得るために、ネットワークチームテスト要件に基づいて、又は現在のネットワーク性能に基づいて動的に、各メッセージ送信間の間隔の長さを変えるようモバイルテストクライアントに命令することができる。
【０００９】
時間差を計算するステップは、各テストメッセージにつき、最初の送信と後続の応答との間の時間を計算するステップをさらに含むことができる。別法として、時間差を計算するステップは、１つ又は複数のサーバのうちの全てのサーバについての結合値／平均値を計算するステップを含むことができる。複数のサーバを利用することで、単一のサーバ特有の問題を除去することができ、また、ネットワークプロバイダが所与のセクタ内の単一の異常にではなくネットワーク特有の問題に的を絞るのを可能にすることができる。
【００１０】
適切には、計算された時間差を第１のサーバに転送するステップは、モバイルデバイスのタイプ、メッセージの送信に使用されたアプリケーション、モバイルデバイスと通信ネットワークとの間の接続モード、モバイル加入者のユーザＩＤ、モバイルデバイスの識別番号等、セル識別、及びモバイルが位置するセクタ番号に関する情報を転送することをさらに含む。
【００１１】
本方法は、時間差と、モバイルデバイスのタイプ、メッセージの送信に使用されたアプリケーション、モバイルデバイスと通信ネットワークとの間の接続モード、モバイル加入者のユーザＩＤ、モバイルデバイスの識別番号等とに基づいて、報告を策定するステップをさらに含むことができる。好ましくは、報告は、毎日２４時間の生データのエクセル抽出の形である。適切には、報告は、ウェブページ、日刊紙、ＳＭＳ、電子メールなどを介して、リアルタイム又はほぼリアルタイムで提供される。好ましくは、報告は、特定のセルサイト及びセルサイトセクタにおける性能問題を識別する情報を含み、それによりキャリアは少ないリソースをターゲットにすることができ、その場合、キャリアは最も高い利益を消費者に提供することができる。
【００１２】
本方法はまた、設定済み時間差を第１のサーバに転送するステップを含むことができる。設定済み時間差は、サーバからの返送メッセージが事前設定済み期間内にモバイルデバイスによって受信されていないといったタイムアウトイベントを示す。好ましくは、事前設定済み期間は最初に１０分に設定されるが、このような事前設定済み期間は、その目的に最適とすることができるような期間に変えることができる。第１のサーバは、所定の期間の変動に従って、事前設定済み期間を変えることができる。別法として、第１のサーバへのトランザクションにおけるコードによって、タイムアウトイベントを示すことができる。
【００１３】
適切には、本方法は、エンドユーザ対話なしで実施することができる。このような場合、モバイルデバイスは、モバイルデバイスから一定の間隔でサーバにメッセージを送らせる専用アプリケーションを備える。このアプリケーションは、第１のサーバと通信し、サーバから送信された命令に応答してサーバへのメッセージ送信の間隔を改変する。別法として、モバイルデバイスのユーザによって、１つ又は複数のユーザ画面を介して手動で監視方法をアクティブ化することができる。
【００１４】
モバイルデバイス上にインストールされた専用アプリケーションを介して本方法が実施される場合、アプリケーションは、モバイルデバイス上の１つ又は複数の補助アプリケーションを利用して、１つ又は複数のサーバにメッセージを送ることができる。第１のサーバは、それ以上の監視が必要とされないときに専用アプリケーションを非アクティブ化することができる。このような場合、サーバは、送信間隔を大きい時間枠、例えば９９９９分に設定することができる。別法として、第１のサーバは、監視を停止するための特定の命令をモバイルクライアントアプリケーションに送ることができる。テストクライアントアプリケーションが、モバイルメッセージングアプリケーションなど別のアプリケーション内に隠されている場合、モバイルネットワークキャリアは、消費者にどんな不都合も帰さないことを保証しなければならない。適切には、このことは、監視ツールの結果として生じるどんなデータ使用に対しても消費者が料金請求されないことを保証することを含むことになる。さらに、バッテリ消費を最小限に抑えるために、又は消費者のモバイル体験に対する他のどんな影響も最小限に抑えるために、テストの量を低レベルに維持しなければならない。
【００１５】
本明細書全体を通して、用語「ｃｏｍｐｒｉｓｉｎｇ（含む、備える）」は、「ｉｎｃｌｕｄｉｎｇ（含む、備える）」と同様の広範な意味を有するものと理解されるべきであり、述べる整数若しくはステップ、又は一群の整数若しくはステップを包含するが、他のどんな整数若しくはステップ、又は一群の整数若しくはステップも排除しないことを含意するものと理解されることになる。この定義は、「ｃｏｍｐｒｉｓｅ」や「ｃｏｍｐｒｉｓｅｓ」など、用語「ｃｏｍｐｒｉｓｉｎｇ」の変形にも当てはまる。
【図面の簡単な説明】
【００１６】
本発明をより容易に理解し実際に実施することができるように、次に添付の図面を参照するが、図面には、本発明の好ましい実施形態を示す。
【図１】本発明の一実施形態による、ネットワーク監視ツールの動作を示す概略図である。
【図２】本発明のさらに別の実施形態による、ネットワーク監視ツールの動作を示す概略図である。
【図３】本発明の一実施形態による、ネットワーク監視ツールについてのトランザクションフローを示す概略図である。
【図４】本発明の別の実施形態による、ネットワーク監視ツールの動作を示す概略図である。
【図５Ａ】本発明の一実施形態による、ネットワーク監視ツール中で使用される一連のユーザ画面を示す図である。
【図５Ｂ】本発明の一実施形態による、ネットワーク監視ツール中で使用される一連のユーザ画面を示す図である。
【図５Ｃ】本発明の一実施形態による、ネットワーク監視ツール中で使用される一連のユーザ画面を示す図である。
【発明の実施形態の説明】
【００１７】
図１を参照すると、本発明の一実施形態による、ネットワーク監視ツールの動作が示されている。この例では、監視ツールは、ネットワーク内でローミングするモバイルデバイス上のアプリケーションとして配置される。図示のように、ネットワーク監視ツールは、モバイルデバイス１０１から、ネットワークに関連するサーバ１０２（接続サーバと呼ばれる）にメッセージ１０４を送らせる。メッセージ１０４は、少なくとも１００バイトであり、接続サーバ１０２に登録されたモバイルデバイス識別番号（ＭＩＮ）を含む。１００バイトなどの妥当なサイズのメッセージを送信することで、監視ツールが、後の分析で考慮に入れることのできるネットワーク性能に対するベースラインをある程度の精度で確立できることが保証される。
【００１８】
メッセージ１０４が受信されると、接続サーバ１０２はすぐにメッセージをモバイルデバイス１０１に送り返す（１０５）。次いで、ネットワーク監視ツールは、モバイルデバイスによって送信メッセージ及び受信メッセージに付加されたタイムスタンプを比較することによりメッセージのラウンドトリップ時間（ＲＴＴ）を計算して、総経過時間を決定する。次いで、ラウンドトリップ時間情報は、ログ及び報告の目的でデータベース１０７に記憶されるように、接続サーバ１０２に転送される（１０６）。
【００１９】
図２に、本発明のさらに別の実施形態による、ネットワーク監視ツールの動作を示す。この特定の例では、ネットワーク監視ツールは、モバイルデバイス１０１から、接続サーバ１０２と、専用ＲＴＴサーバと呼ばれる第２のサーバ２０２とに、メッセージ１０４、２０４を同時に送らせる。メッセージが受信されると、接続サーバ１０２とＲＴＴサーバ２０２の両方は、メッセージをモバイルデバイスに直接に送り返す（１０５、２０５）。返送メッセージが接続サーバ１０２とＲＴＴサーバ２０２の両方から受信されると、次いでモバイルデバイスは、ラウンドトリップ時間の計算に進む。
【００２０】
この場合の計算されたＲＴＴは、実際のＲＴＴの完全に正確なビューではない場合があるが、ネットワークの全般的な健全性の尺度を提供することになり、傾向が確立された後は、ベースラインに対して性能の高い又は低い期間を識別するのに使用することができる。
【００２１】
図３に、本発明の一実施形態による、ＲＴＴ計算及び報告プロセスのトランザクションフローを示す。図示のように、モバイルデバイスはまず、ネットワーク５０１へのＨＴＴＰ接続がまだ開かれていない場合にはモバイルクライアントを介してこの接続を開く（５００）。ネットワーク５０１は、新しいＨＴＴＰ接続のための、必要とされるパケットデータプロトコル（ＰＤＰ）コンテキストを生み出す（５０２）。ＨＴＴＰ接続が確立されると、モバイルクライアントは、ＴＣＰプロトコルを使用して、接続サーバ１０２及びＲＴＴサーバ２０２にメッセージ１０４、２０４の形でＲＴＴテストデータを送る（５０３）。次いでモバイルクライアントは、接続サーバ１０２とＲＴＴサーバ２０２の両方について返信を待機する（５１３）。
【００２２】
接続サーバ１０２は、ＲＴＴテストデータを受信すると（５０４）、メッセージ１０５の形でＲＴＴ返信を送る（５０５）。同様に、ＲＴＴサーバ２０２は、ＲＴＴテストデータを受信すると（５０６）、メッセージ２０５の形でＲＴＴ返信を送る（５０７）。モバイルクライアントは、メッセージ１０５、２０５を受信すると（５０８）、次いでＲＴＴ時間を計算する（５０９）。モバイルクライアントは、ＲＴＴ時間を計算すると、メッセージ１０６を介してＲＴＴ報告をＲＴＴサーバ２０２に送ることに進む（５１０）。次いでＲＴＴサーバ２０２は、報告をデータベースに保存する（５１１）。保存が完了すると、次いでＲＴＴサーバ２０２は、メッセージ１０８を介して返信メッセージをモバイルクライアントに送ることに進むことができる（５１２）。メッセージ１０８はＲＴＴサマリデータを含むことができ、このＲＴＴサマリデータは、次いでモバイルクライアントがモバイルデバイスの画面上に表示することができる（５１４）。
【００２３】
図４に、使用されるネットワーク監視ツールの一例を示す。この場合、ネットワーク監視ツールは、モバイル通信ネットワーク内でローミングする複数のモバイルハンドセット上に配置されるアプリケーションである。記述を明確にするために、以下の考察では、複数のモバイル電話機にサービスする、ネットワーク内の単一のセルについて、ラウンドトリップ時間（ＲＴＴ）を計算することに焦点を合わせる。図示のように、セル３００は、３つのセクタ３０１、３０２、３０３で構成される。セルは、ネットワークコアを介して接続サーバ１０２及びＲＴＴサーバ２０２に結合される。
【００２４】
この例では、セル３００の第１のスロット３０１が、２つのハンドセット１０１ａ、１０１ｂにサービスしており、第２及び第３のスロット３０２、３０３が、それぞれ単一のハンドセット１０１ｃ、１０１ｄにサービスする。図示のように、モバイルデバイス１０１ａ、１０１ｂ、１０１ｃは、それぞれメッセージ１０４ａ、１０４ｂ、１０４ｃを接続サーバ１０２に送り、次いで接続サーバ１０２は、各メッセージ１０５ａ、１０５ｂ、１０５ｃをそれぞれのモバイルデバイス１０１ａ、１０１ｂ、１０１ｃに直接に送り返す。上記の例の場合と同様、モバイルアプリケーションを実行する各モバイルデバイスは同時に、メッセージ２０４ａ、２０４ｂ、２０４ｃをＲＴＴサーバ２０２に送ることができ、ＲＴＴサーバ２０２は、すぐに各メッセージを当該のモバイルデバイス２０５ａ、２０５ｂ、２０５ｃに送り返す。
【００２５】
別法として、ネットワーク監視アプリケーションは、タイマが完了するのを待機した後でＲＴＴサーバ２０２への接続を開くことができる。タイマは所定の時間間隔に設定されるが、この所定の時間間隔の長さは、ネットワーク内でサンプリングされるデバイスの数や、デバイスの電力消費など、いくつかの要因に基づく。タイマは実際、モバイルデバイスからのＲＴＴデータに対するサンプリングレートを制御して、すなわちメッセージ送信時を指示して、ＲＴＴ計算を容易にする。いずれの場合も、採取されるであろうサンプルの潜在的な量を仮定して、且つモバイルデバイスに対する影響を低減するために、サンプリング時間は長く維持される。図４に示す例では、所定の時間間隔は、最初に６１分の期間に設定される。潜在的なネットワーク障害スポットと思われる可能性のあるエリアでは特に、後続の分析に向けてこれらのエリアで入手可能なデータを増加させるために、ＲＴＴサーバが所定の時間間隔を短縮することによってサンプリングレートを動的に上げることができることが提案される。
【００２６】
モニタの目的は、異常なラウンドトリップ時間を識別すること、並びに通常のネットワーク性能を監視することなので、ＲＴＴサーバから返されることになるメッセージのタイムアウトは、ネットワーク制約を仮定して可能な限り長く設定すべきだが、テストとテストとの間の時間よりも長く設定すべきではない（所定期間よりも長く設定すべきではない）。「遅延」状況が確実に捕捉されるようにするためには、適切なタイムアウト値は１０分であろう。１０分のタイムアウト期間は、データ送信がしばらくの間中断する（例えばセル輻輳のせいで）といった典型的な「遅延イベント」を捕捉するのに十分な長さである。タイムアウトがより長ければ、ユーザがデバイスをログアウトしてそれによりサンプルが失われることになる可能性がより高くなる。タイムアウト値は、ＲＴＴサーバから構成可能であるべきだが、ＲＴＴサーバによって設定されたタイムアウトは、現在の所定の間隔時間（サンプリング間隔）よりも長い場合にはモバイルデバイスによってオーバーライドすることができる。タイムアウトに達した場合は、このデータサンプルをタイムアウト時間として報告すべきである。例えば、タイムアウトが１０分であり、この時間間隔に応答が受信されない場合は、ＲＴＴ報告は、このサンプルをラウンドトリップ時間について１０分として示すべきである。
【００２７】
各モバイルデバイス１０１ａ、１０１ｂ、１０１ｃは、関連する返送メッセージをサーバ１０２、２０２から受信すると、ＲＴＴの計算に進む。各モバイルデバイス１０１ａ、１０１ｂ、１０１ｃは、関連するラウンドトリップ時間（ＲＴＴ）を計算し終えると、関連するＲＴＴ情報を含むメッセージ１０６ａ、１０６ｂ、１０６ｃを接続サーバ１０２に転送することに進む。ＲＴＴ情報に加えて、メッセージ１０６ａ、１０６ｂ、１０６ｃはまた、モバイル加入者のユーザＩＤ、テストを行っているデバイスのモバイル識別番号（ＭＩＮ）、モバイルデバイスについての接続詳細（ＧＳＭ／ＵＭＴＳ等、及び使用アプリケーション）、電話機モデルなども含む。メッセージは、サーバからモバイルデバイスへの送出時間、モバイルデバイスからサーバへの入来時間、及び、パケットロス、すなわち再送すべき紛失パケットの数に関する情報をさらに含んでもよい。以下の表１に、ＲＴＴ報告メッセージについての望ましい情報フィールドの短いリストを示す。
【００２８】
最初の報告は、深夜１２：００から深夜までの毎日２４時間の生データのエクセル抽出となる。サーバ結果は、次のように入手可能であるべきである。すなわち、リアルタイムのウェブページを介して、毎日の報告を介して（以下のレイアウト参照）、エクセルフォーマット抽出を介して（以下のレイアウト及びオプション参照）、しきい値が破られたときの、定義されたモバイル番号リストへのリアルタイムアラートＳＭＳを介して、入手可能であるべきである。報告は、セルサイト／セクタによるＲＴＴ時間の分布を示す。したがって、許容可能なＲＴＴ時間よりも長い時間を経験しているサイト又はセクタを識別することが可能である。次いで、これらのサイトを、ネットワークチームによってより詳細に分析するための対象とすべきである。
【表１】
0005534480.tif 000002
【００２９】
サーバは、全てのユーザＩＤ、又は選択されたユーザＩＤに対して、ＲＴＴテストをオフにするオプションを有する。特に、特定のユーザのみに対してツールがオンにされることが可能であるべきである。これは単に、ＲＴＴタイマ間隔を９９９９分に設定することによって達成することができる。
【００３０】
ツールの一反復において、監視クライアントソフトウェアはメッセージングアプリケーションに組み入れられるが、このメッセージングアプリケーションは、シンビアンｓ６０電話機では、「常時オン」としてモバイルインターネットに接続されて動作するように設計される。メッセージングアプリケーションは、メッセージを送受信することと、任意選択でＲＴＴ報告をＥＭタイプのメッセージによってモバイルユーザに提供し返すことと、をサポートするフレームワークをもたらす。ＥＭは、拡張メッセージング（Ｅｘｔｅｎｄｅｄ  Ｍｅｓｓａｇｉｎｇ）を意味し、インターネットベースのインスタントメッセージングのプロプラエタリな一形式である。
【００３１】
ツールの製品バージョンでは、どんなＲＴＴ情報もモバイルクライアントユーザには見えないことになる。しかし、テストバージョンでは、ユーザは、設定メニューからラウンドトリップ時間を選択することができるべきであり、この結果、現在のＲＴＴ情報を要求するトランザクションがサーバに送られることになる。この情報は、ＲＴＴボットからのＥＭタイプの応答において提供される。図５Ａ〜５Ｃに、本発明の一実施形態による、ネットワーク監視ツールのテストバージョンの一連のユーザ画面４００を示す。
【００３２】
図５Ａに示すように、ユーザは、表示画面４００内のオプションメニュー４０１をアクティブ化したところである。テストを開始するために、ユーザは、リスト４０２からオプション「ラウンドトリップ時間」を強調表示させ、選択ボタン４０３を押す。ラウンドトリップ時間が選択されると、図５Ｂに示すように、ＲＴＴ要求が送られたことをユーザに知らせるメッセージ４０５がユーザ画面上に表示される。次いでユーザは、メッセージを消すためにＯＫボタン４０６を選択する。
【００３３】
監視ツールが、返送メッセージから得られた情報からラウンドトリップ時間を計算した後、次いで、関連する情報４０７がユーザに対して表示される（図５Ｃ参照）。図５Ｃの例に示すように、この場合のＲＴＴ報告メッセージは、サンプルが採取された日時、電話機モデル、前回のテストの日時、現在のテストのＲＴＴ（接続ＲＴＴ及び登録ＲＴＴ）、使用アプリケーション、ネットワークアクセスのタイプ（この場合はＧＳＭ）、並びに１日の平均ＲＴＴ（平均接続ＲＴＴ及び平均登録ＲＴＴ）を含む。
【００３４】
前述のように、分析ツールを利用してネットワーク内の遅延イベントを識別することができる。このような場合、別のモバイルへの各メッセージトランザクションが、いくぶん、上に論じたＲＴＴテストデータのように扱われる。
【００３５】
遅延テスト条件の下では、送信側クライアントは、各メッセージを送った時（ｔｓ）を記録してから、確認が受信される時を記録する。次いでクライアントは、元のメッセージが他方のクライアントに送られてからの時間（ｔｄ）を計算することができる。このＲＴＴ時間は、遅延を含むどんな種類のネットワーク問題からも影響を受けることがある。この影響は、送信側デバイスと受信側デバイスとのいずれかである可能性がある。
【００３６】
このようなテスト手法によって取り込まれるデータの量を最適化するために、クライアントは、時間ｔｄを報告しきい値（例えば３分）と比較する。ｔｄがしきい値を超える場合は、送信側クライアントは、記憶及び照合されるよう、ＲＴＴサーバに通知を送信する。適切には、遅延しきい値は、全ての類似するパラメータデータと同様、容易に修正可能であるべきであり、ＲＴＴサーバによって設定することができる。報告は、送信側及び受信側のユーザＩＤ、ｔｄ（実際上は、他方のクライアントへのＲＴＴ）、報告するクライアントのセルサイト（もしわかっていれば）、報告するクライアントの電話機モデル、並びに送信側及び受信側のＭＩＮなどの情報を含むことができる。
【００３７】
遅延テストは接続サーバにおいて実施することもできることは、当業者には理解されるであろう。このようにしてテストを開始することにより、サーバは、あらゆるトランザクションの応答時間を計算すること、並びに、対のうちのどちらの装置が実際に遅延を経験しているかを識別することができるであろう。
【００３８】
以上の実施形態は、本発明の例証としてのみ提供したものであり、当業者には明らかであろう以上の実施形態に対するさらに他の修正及び改良もまた、本明細書に記載の本発明の広範な範囲及び境界の内に入ると見なされることを理解されたい。
【図１】
0005534480.tif 000003
【図２】
0005534480.tif 000004
【図３】
0005534480.tif 000005
【図４】
0005534480.tif 000006
【図５Ａ】
0005534480.tif 000007
【図５Ｂ】
0005534480.tif 000008
【図５Ｃ】
0005534480.tif 000009