(57)【要約】パフォーマンス監視システムであって、当該システムでは、テスト装置が非リアルタイムメッセージングサービスのテストメッセージを送る。該テストメッセージは、定められた対話型アプリケーションサービスのためにフォーマットされている。該テスト装置は、予期される応答メッセージの内容を特定し；予期される応答メッセージの内容とテストメッセージの内容との関係は、前記の定められた対話型アプリケーションサービスのサービス論理に直接的に対応している。該テスト装置は、非リアルタイムメッセージングサービスの受け取られたメッセージの内容を、予期される応答メッセージの内容と比較するために、予め定められたマッチング基準を用い、該マッチング基準が満たされる場合、受け取られたメッセージを関連メッセージとして識別する。該関連メッセージは、定められた対話型アプリケーションサービスの現在の全体的なパフォーマンスのための評価の測定指標を生成するために用いられる。【選択図】図２
2014523671.tif 000002
【特許請求の範囲】
【請求項１】
テスト装置のための方法であって、当該方法は:
非リアルタイムメッセージングサービスのテストメッセージを送ることを有し、該テストメッセージは、前記非リアルタイムメッセージングサービスに実装された、定められた対話型アプリケーションサービスのためにフォーマットされており；
予期される応答メッセージの内容を特定することを有し、該予期される応答メッセージの内容と前記テストメッセージの内容との関係は、前記定められた対話型アプリケーションサービスのサービス論理に直接的に対応しており；
前記非リアルタイムメッセージングサービスの、受け取られたメッセージの内容を、前記予期される応答メッセージの内容と比較するために、予め定められたマッチング基準を用いることを有し；
前記マッチング基準が満たされた場合に、受け取られたメッセージを関連メッセージとして識別することを有し；
前記関連メッセージを使用して、前記定められた対話型アプリケーションサービスの現在の全体的なパフォーマンスを評価するための測定指標を生成することを有する；
前記方法。
【請求項２】
当該方法が、テストイベントを実行することを特徴とし、該テストイベントは、１つ以上のテストタスクを有し、１つのテストタスクが、テストメッセージを送ること、および、その関連メッセージに基づいて測定指標を生成することを含んでおり；
当該方法が、前記テストイベント中に生成された測定指標を、制御ノードへ送ることを特徴とする、
請求項１記載の方法。
【請求項３】
上記制御ノードからのトリガリングメッセージに応答して、上記テストイベントを実行することを特徴とする、請求項２記載の方法。
【請求項４】
上記制御ノードからテストメッセージのための内容データブロックを受け取ることを特徴とする、請求項３記載の方法。
【請求項５】
上記対話型アプリケーションサービスのサービス論理を記憶すること；
上記制御ノードからの上記トリガリングメッセージに応答して、テストメッセージのための内容データブロックを生成すること；
を特徴とする、請求項３記載の方法。
【請求項６】
上記測定イベントが、定められた期間を持ち、かつ、テストイベントの測定指標を持ち、該測定指標は、少なくとも１つの関連メッセージが、前記の定められた期間内で、上記テストメッセージのために識別されたかどうかを示すものであること、
を特徴とする、請求項２〜５のいずれかに記載の方法。
【請求項７】
関連メッセージが識別されたテストメッセージの数と、送信されたテストメッセージの数との比率を、テストイベントのために特定すること；
上記の定められた対話型アプリケーションサービスの現在の全体的なパフォーマンスの評価のために比率を使用すること；
を特徴とする、請求項６記載の方法。
【請求項８】
上記テストメッセージのタイムスタンプを抽出すること；
上記関連メッセージのタイムスタンプを抽出すること；
上記テストメッセージの前記タイムスタンプと上記関連メッセージの前記タイムスタンプとの間の期間を示す測定指標を生成すること；
を特徴とする、請求項２〜７のいずれかに記載の方法。
【請求項９】
２つのセットのデータブロック同士の間の適合のレベルを特定するために適用可能な、第二のマッチング基準を記憶すること；
上記テストメッセージの内容データブロックを抽出すること；
上記関連メッセージの内容データブロックを抽出すること；
前記のテストメッセージの内容データブロックと、前記の関連メッセージの内容データブロックとの間の適合のレベルを特定するために、前記の第二のマッチング基準を使用すること；
前記の特定された適合のレベルを示す測定指標を生成すること；
を特徴とする、請求項２〜７のいずれかに記載の方法。
【請求項１０】
対応するデータブロック同士の間の上記の適合のレベルが、該データブロック内に担持された情報のタイプに基いて変化することを特徴とする、請求項９記載の方法。
【請求項１１】
上記測定指標において、現在のテストタスクに関連するメタデータを含むことを特徴とする、請求項２〜７のいずれかに記載の方法。
【請求項１２】
テスト装置であって、当該テスト装置は、
非リアルタイムメッセージングサービスで通信するためのインターフェースユニットと、処理ユニットとを有し、請求項１〜１１の方法のいずれかの工程を実行するための手段を提供するように構成されている、
前記テスト装置。
【請求項１３】
制御装置であって、当該制御装置は、１つ以上の端末ノードと通信するためのインターフェースを有し、以下の事項を行うための手段を提供するように構成されており、該事項が：
情報が非リアルタイムメッセージングサービスでやり取りされる定められた対話型アプリケーションサービスの、現在の全体的なパフォーマンスを測定するためのリクエストを、第一の端末ノードで受け取ること；
前記受け取られたリクエストに対応するテストイベントを生成することであって、テスト、テストイベントは、１つ以上のテストタスクを有し、１つのテストタスクは、テストメッセージを送ることと、前記テストメッセージに関連付けられた応答メッセージに基づいた測定指標の生成とを含み；
トリガリングメッセージを第二の端末ノードへと送信することによって前記テストイベントを開始すること；
前記第二の端末ノードから１つ以上の測定指標を受け取ること；
前記測定指標を用いて測定結果を生成すること；
前記測定結果を、前記第一の端末ノードへ送ること；
である、前記制御装置。
【請求項１４】
以下の事項を行うための手段を提供するように構成されていることを特徴とし、該事項が：
上記テストイベントのテストメッセージの内容を特定すること；
予期される応答メッセージの内容を特定することであって、該予期される応答メッセージの内容と、前記テストメッセージの内容との間の関係は、上記の定められた対話型アプリケーションサービスのサービス論理に直接的に対応しており；
前記の特定された内容をトリガリングメッセージに含めること；
である、請求項１３記載の制御装置。
【請求項１５】
システムであって、
請求項１２記載のテスト装置と、請求項１３または１４記載の制御装置とを有する、
前記システム。
【請求項１６】
コンピュータープログラム製品であって、当該コンピュータープログラム製品は、
コンピューターによって読み取り可能であり、かつ、請求項１〜１１のいずれかの方法を実行するための命令をコード化するものである、
前記コンピュータープログラム製品。
【発明の詳細な説明】
【技術分野】
【０００１】
発明の分野
本発明は、通信に関し、特には、独立請求項１、１２、１３、１５および１６の先行文に定められるような、対話型アプリケーションサービスの全体的(overall)なパフォーマンスを評価するための方法、テスト装置、制御装置、システム、および、コンピュータープログラム製品に関する。
【背景技術】
【０００２】
発明の背景
通信では、システムはプロトコルを適用し、該プロトコルはメッセージのやりとりのための所定のフォーマットを提供する。プロトコルの使用の意味は、送信するピアエンティティ(transmitting peer entity)からの各メッセージが、識別可能な意味を持ち、かつ、受信するピアエンティティ(receiving peer entity)において、定められた応答を引き起こすように意図されている、ということである。
【０００３】
ピアエンティティ(peer entities)同士の間の情報交換の成功は、第一のピアエンティティから第二のピアエンティティへのメッセージの送達(delivery)の成功を必要とし、第二のピアエンティティから第一のピアエンティティへの応答メッセージ送達の成功を必要とする。プロトコルベースの送信においては、第一のメッセージと第二のメッセージとの間のインタラクションが即時であるか、または、少なくとも応答メカニズムが正確に定められている。このため、第一のメッセージの送信と第二のメッセージの受け取りとの間の遅延が、正しく見積られ、その結果、そのような情報交換の成功または失敗が、容易に監視され得る。遅延が見積られた遅延よりも長い場合、明らかに送達に問題があり、失敗を表示することができる。
【０００４】
しかしながら、いくつかのメッセージ送達メカニズムでは、第一のメッセージの送信と第二のメッセージの受け取りとの間の遅延は、単に、メッセージを送達するエンティティのパフォーマンスに依存するわけではない。いくつかのメッセージ送達サービスには、送信されたメッセージが記憶され得る中間ノードが関与し、特定の転送条件が満たされるときだけ、メッセージは受け取りエンドポイントに転送される。例えば、モバイル通信ネットワークにおけるショートメッセージの送達には、中間ショートメッセージサービスセンターが関与し、該サービスセンターには、受け取り加入者がメッセージを受け取りできるまでメッセージが記憶される。従って、第一のメッセージの送信と第二のメッセージの受け取りとの間の遅延は、通信に対する加入者の可用性(availability、利用可能であること)に依存する。そのような状況下では、送信の遅延だけに基づいて情報やりとりの成功または失敗を測定することは、正しくないであろう。このようにして生じた測定結果は、主に加入者の行動に依存することになり、サービスのパフォーマンス自体には依存しない。
【０００５】
ここでは、対話型アプリケーションサービスとは、１つ以上の通信インターフェースを介して他のノードにアクセス可能な通信ノードにおいてホストとなっているデータ処理サービスをいう。対話型アプリケーションサービスの作動では、１つのノードは、対話型アプリケーションサービスのために特有のサービス論理(service logic)を実装するためのリソースを提供するサービングノード(serving node)として作動し、もう１つのノードは、サーブされるノード(served node)として作動する。サーブされるノードは、第一の情報を含む第一のメッセージをサービングネットワークノードに送り、サービングノードは、サービス論理に従って第一の情報を処理する。第一の情報をサービス論理で処理することが、サービングノードが第二のメッセージ内に含んでいる第二の情報を生成し、サーブされるノードへと送り返す。
【０００６】
対話型アプリケーションサービスの全体的なパフォーマンスとは、該対話型アプリケーションサービスの提供に関与する全要素が、対話型アプリケーションサービスのために定められた技術的特徴に従って一緒に動作するための性能のことをいう。技術的特徴は、第一のメッセージと第二のメッセージとの間の技術的手段で構成され得る特徴であり、全体的なパフォーマンスに関連する技術的特徴は、第一のメッセージおよび第二のメッセージのプロパティに基づいて特定できる。対話型アプリケーションサービスのために定められ得る技術的特徴の例として、サービスの往復送達時間、および、第二のメッセージが対話型アプリケーションサービスの所定のサービス論理に適合する範囲が挙げられる。技術的特徴には、対話型アプリケーションの内容についてのユーザーによる認識自体は関与しない。例えば、毎日の星占いまたは賭け(betting tips)がどれだけユーザーの主観的な期待に応えるかということについての個人的意見は、技術的特徴ではない。そして、前記星占いや賭けは、該星占いおよび賭け事情報を提供する対話型アプリケーションサービスの全体的なパフォーマンスを評価するのに適用可能ではない。
【０００７】
情報のやりとりに中間ノードが関与し、かつ、該ノードが、メッセージの送達に予測できない遅延要因を追加するメッセージング技術において、対話型アプリケーションサービスは実装され得る。加えて、メッセージングサービスのプロトコルによって提供される確認メッセージは、通常、送信ノードでのみ利用可能である。双方向の通信の成功または失敗を測定するには、両方の通信エンドポイントからの確認メッセージが１つのエンドポイントについて利用可能でなければならない。このため、このタイプの対話型アプリケーションサービスのパフォーマンスを効果的に監視することが不可能であった。これまでは、それらは、ユーザーの意見を収集することと、ランダムな手作業チェックを行うこととによって監視および評価されてきた。しかしながら、このような、測定情報の収集、および、収集した結果を手作業で処理することは、あらゆる工業的に実施可能なアプリケーションについて、あまりにも労力を要するものであり、費用がかかる。
【発明の概要】
【０００８】
発明の簡単な説明
本発明の目的は、先行技術の欠点の少なくともいくつかを克服するための方法および装置を提供することである。本発明の目的は、請求項１の特徴部分による方法で達成される。本発明の目的は、さらに、請求項１２、１３の特徴部分による装置と、請求項１６の特徴部分によるコンピュータープログラム製品とで達成される。
【０００９】
本発明の好ましい実施形態は、従属請求項において開示されている。
【００１０】
本発明は、専用(special-purpose、特殊目的)のテストエージェント(test agent)を用いて測定を行うという着想に基づいており、該テストエージェントは、測定された対話型サービスアプリケーションにテストメッセージを送り、かつ、該サービスによる予期された応答メッセージの内容を認識している。受信メッセージは、その内容が予期される応答メッセージの内容とマッチする場合、テストメッセージに関連付けられる。該関連付けられたメッセージは、次に、対話型アプリケーションサービスの全体的なパフォーマンスに関する評価に直接的に好適な測定指標を特定するために用いられる。
【００１１】
１つの対話型アプリケーションサービスがシステムの１つのエンドポイントだけにおいて動作できる場合でも、本発明は、それが対話型アプリケーションサービスの現在の全体的なパフォーマンスの評価を可能にするという利点を持つ。
【００１２】
以下に、好ましい実施形態に関して、添付の図面を参照しながら、本発明をより詳細に説明する。
【図面の簡単な説明】
【００１３】
【図１】図１は、非リアルタイムメッセージングサービスのエンティティを図示している。
【図２】図２は、対話型アプリケーションサービスの全体的なシステムパフォーマンスの評価のためのシステム構成を図示している。
【図３】図３は、テストエージェントに実装される方法の工程を図解している。
【図４】図４は、例示的な装置の構成を図解している。
【発明を実施するための形態】
【００１４】
詳細な説明
以下の実施形態は、例示的なものである。本明細書は、「或る(an)」、「１つの(one)」、または、「いくつかの(some)」実施形態(複数)に言及しているかもしれないが、これは必ずしも、そのような言及のそれぞれが、同じ実施形態(複数)を指していることも意味しないし、その特徴が単一の実施形態だけに適用されることも意味しない。様々な実施形態の単一の特徴が、さらなる実施形態を提供するべく、組み合わせられ得る。
【００１５】
本発明の特徴を、本発明の様々な実施形態が実装され得るシステムアーキテクチャーの単純な例で説明する。実施形態を図解するのに関連する要素だけを詳細に説明する。発明された方法およびデバイスの様々な実装は、当業者に一般的に知られる要素を有しており、ここでは、具体的には記載しない。
【００１６】
実施形態(embodiments)では、対話型アプリケーションサービスの第一および第二のメッセージは、非リアルタイムメッセージングサービスを使って伝達される。図１のブロックチャートは、非リアルタイムメッセージングサービスのエンティティと、これらエンティティ間のメッセージの送達を図示している。ここでは、非リアルタイムメッセージサービスとは、第一のノード１０から第二のノード１２へのメッセージの送達が中間ノード１４を介して２個の別々の行程(leg、区間)において行われるメッセージングサービスのことをいう。第一の行程では、第一のメッセージは、第一のノード１０から中間ノード１４へと送信され、そこで記憶される。第二のノード１２がメッセージを受け取ることができるとき、第一のメッセージは、第二の行程において、中間ノード１４から第二のノード１２へと転送される。
【００１７】
メッセージを受け取る作動可能状態(readiness)は、メッセージ送信に適用される非リアルタイムメッセージングサービスのタイプに従って、様々な形で現れる。本発明の実施形態の記載では、非リアルタイムメッセージングサービスの例として、ショートメッセージサービス(Short Message Service)（ＳＭＳ）、および、マルチメディアメッセージングサービス(Multimedia Messaging Service)（ＭＭＳ）を使用している。こうした技術は両方とも、広範に実証され、当業者によってよく知られている。しかしながら、なお、保護の範囲は、これらの例示的なメッセージングサービスに限定されず、上述のような中間ノードを介したメッセージの送達が起こるあらゆる現在および将来のメッセージングサービス技術をカバーする。
【００１８】
ＧＳＭ（Global System for Mobile Communications、モバイル通信用グローバールシステム））に従ったＳＭＳによって、ターミナルエンドポイントＮ１およびＮ２の間で、ショートテキストメッセージのやりとりが可能になる。ＳＭＳでは、第二のノード１２がメッセージを受け取る作動可能状態は、該ターミナルエンドポイントＮ２の可用性(availability)に関連している。発信(originating)エンドポイントＮ１ １０は、中間ノード１４として機能するショートメッセージサービスセンター(Short Message Service Centre)（ＳＭＳＣ）のアドレスを記憶する。Ｎ１がショートメッセージを他のノードＮ２に送るとき、Ｎ１は、記憶されたＳＭＳＣのアドレスをショートメッセージにも含み、ショートメッセージは、行先アドレスに直接的に送達されるのではなく、ＳＭＳＣに送達される。送達が成功すれば、これに続く送達のために、ショートメッセージがＳＭＳＣに記憶される。
【００１９】
ＳＭＳＣは、ショートメッセージをその送り先へと送達するために、Ｎ２のルーティング情報を獲得する。この過程において、Ｎ２が呼び出され(paged)、呼び出しが成功すれば、ＳＭＳＣはショートメッセージをＮ２へ送る。送達が成功すれば、送達されたメッセージは、ＳＭＳＣの蓄積転送式の処理から取り除かれ、送達がＮ１に確認されることになる。呼び出しまたは送達が失敗すれば、ＳＭＳＣは、ショートメッセージを送達するさらなる試みを定期的に行う再試行プロシージャ(retry procedure)を呼び出す。
【００２０】
加えて、適用されたネットワークのモビリティ・マネジメント・プロシージャ(mobility management procedure)が、警告リンク１６を提供することによって、ショートメッセージを受け取るためのＮ２の作動可能状態が監視され得る。ＳＭＳＣは、Ｎ２が再び利用可能になったときにＮ２のホームロケーションレジスタ(home location register)（ＨＬＲ）に通知するようリクエストし得る。ＳＭＳＣリクエストに応じて、ＨＬＲはＮ２アカウントに対して、Ｎ２がショートメッセージの送達ができない状態であることを示すフラグを設定し、ＳＭＳＣを有するアドレスをＮ２のためのメッセージウェイティングデータ(Massage Waiting Data)（ＭＷＤ）リストに記憶する。ショートメッセージの送達が利用可能であるかどうかについての指標(indication、指示表示)は、問題のフラグに従って、様々な形でＨＬＲに到達し得る。Ｎ２がネットワークから外された場合、ＨＬＲはＮ２の場所更新の試みについて知らされる。一方、Ｎ２が通達範囲外(out of coverage)にある場合、それは、ビジターロケーションレジスターによる呼び出しの試みには回答しない。Ｎ２が通達範囲に戻ると、それは、ＶＬＲの呼び出しに応答し、ＶＬＲがこれについてＨＬＲに知らせる。Ｎ２が、そのメモリがいっぱいであるがために、ショートメッセージの送達が利用不可能(unavailable)である場合、ＶＬＲはこの状況を監視し、メモリ容量を超えなくなったときにＨＬＲに知らせる。Ｎ２がショートメッセージを受け取ることができるという指標を受け取ると、ＨＬＲは、ＭＷＤ内のＳＭＳＣに知らせ、知らせを受けたＳＭＳＣは、再度、ショートメッセージを送達しようと試みる。
【００２１】
該マルチメディアメッセージングサービス（ＭＭＳ）により、マルチメディアコンテンツを含むメッセージの送達が可能になる。ＳＭＳとは異なり、ＭＭＳにおいては、メッセージを受け取る作動可能状態は、受信エンドポイントＮ２によって明確に表示される。マルチメディアメッセージがＮ１において作成される；バイナリＭＭＳメッセージファイルのフォーマットは、オープンモバイルアライアンス(Open Mobile Alliance)（ＯＭＡ）によって公開されているＭＭＳカプセル化プロトコル仕様(MMS Encapsulation Protocol specification)に従っている。コード化(encoded、エンコード)されたバイナリＭＭＳメッセージファイルは、中間ノード１４として機能する蓄積転送式のウェブサーバーＭＭＳＣに送達される。バイナリＭＭＳヘッダのサブセットが、ＭＭＳ通知メッセージとして、ＳＭＳを介して、完成したメッセージの場所を指すＵＲＬポインタとともにＮ２へと送られる。このＭＭＳ通知メッセージがＮ２によって受け取られると、それは、ＭＭＳメッセージの内容をダウンロードするためにゲートウェイ接続を自動的に開始する。Ｎ２がＭＭＳ対応でない場合、メッセージは通常、ウェブベースのサービスへと送達され、該サービスから、内容が通常のインターネットブラウザから閲覧できる。
【００２２】
従って、非リアルタイムメッセージングサービスを適用する対話型アプリケーションサービスの全体的なパフォーマンスは、基本的に、互いに同期していない４個の行程の結果である。Ｎ１が第一のメッセージをＮ２に送り、Ｎ２が第二のメッセージをＮ１に送信することによって応答するＳＭＳベースの対話型アプリケーションサービスについて考えよう。第一および第二のメッセージは、Ｎ２において実装されたサービス論理によって関連付けられているだけであり、それらをリンクさせるプロトコルがない。第一のメッセージがＩＮおよびＮ２に送達されると、ＳＭＳサービスのプロトコルがＮ１に知らせ、それに対応して、第二のメッセージがＩＮおよびＮ１に送達されると、Ｎ２が知らされる。しかしながら、対話型アプリケーションサービスの全体的なパフォーマンスは、これら両方のメッセージの送達の成功および／または失敗、ならびに、商品としてのサービスの販売を正当化するサービス論理を実行するＮ２の性能に基づいている。これらの従来のメッセージ送達の確認プロシージャに基づいた全体的なパフォーマンスの評価には、両方のエンドポイントにおいて、メッセージおよび信号に対して、完全(full)な可用性(availability)が必要となるであろう。
【００２３】
図２は、対話型アプリケーションサービスのシステムパフォーマンス全体の効果的な評価を促すシステム構成を図示している。当該システムは、テストエージェント２０と、アプリケーションノード２１と、制御要素(control element)２２とを有する。なお、図２に示される要素は、１つ以上の動作的に相互接続された物理的ユニットに実装され得るグループ化された機能を表す論理要素(logical elements)である。
【００２４】
テストエージェント２０は、専用のコンピューター装置であって、非リアルタイムメッセージングサービスのメッセージでアプリケーションノード２１と通信するためのメッセージングインターフェースを有する。従って、該テストエージェント２０は、アプリケーションノード２１によって提供される対話型アプリケーションサービスの、サーブされるノード(served node)として動作し得る。該テストエージェント２０はまた、制御要素２２と通信するための制御インターフェースを有する。テストエージェントおよび制御ノードは、１つの物理的デバイス内で共存し得るか、または、テストエージェントは、リモートデバイスであり得る。テストエージェントおよび制御デバイスが同じ物理的デバイス内に実装される場合、制御インターフェースは、デバイスの１つ以上の内部インターフェースを有する。遠隔(remote)のテストエージェントは、１つ以上の定められた、固定の、またはモバイル式のネットワークで通信されるよう構成され得る。遠隔のテストエージェントのメッセージングインターフェースおよび制御インターフェースは、適用された構成に従って、同じまたは異なる技術を適用し得る。
【００２５】
１つの興味深い観察された局面は、対話型アプリケーションサービスの全体的なパフォーマンスにおける結果に対する、サーブされるノードの場所の影響である。従って、以下に、ＳＭＳベースのアプリケーションサービスの全体的なパフォーマンスを監視するモバイルテストエージェントの例示的な実施形態をより詳細に記載する。しかしながら、本発明の実施形態は、他のタイプのテストエージェントおよび非リアルタイムサービスを適用し得る。
【００２６】
アプリケーションノード２１は、非リアルタイムメッセージングサービスで外部ノードと通信するためのメッセージングインターフェースを有するコンピューター装置である。アプリケーションノードは、メッセージングインターフェースを介して情報を入力し、結果情報を生成するために入力情報を特定のアプリケーション論理で処理して、メッセージングインターフェースを介して外部ノードに転送される結果情報を出力するよう構成されている。
【００２７】
制御ノード２２はまた、テストエージェント２０と通信するための制御インターフェースを有するコンピューター装置である。制御ノード２２はまた、測定をリクエストする当事者と通信するためのオペレーターインターフェース２３を有する。オペレーターインターフェースは、複数の外部ノードにアクセス可能なウェブページであり得る。代替的には、制御ノードへのアクセスは、制御ノードの中間オペレータユニット（外部ノードから受け取るリクエストの結果として、測定イベントを生成しかつ認証する）によって加減されてもよい。
【００２８】
測定イベント(measurement event)は、１つの対話型アプリケーションサービスに関連し、多くの測定タスクを有し得る。例として、問題の対話型アプリケーションサービスが、オートマチックな番号案内サービス(directory enquiry service)だと仮定しよう。この例では、１つのディレクトリのレコードが、少なくとも、１人の加入者の加入者番号(subscriber number)データおよび加入者識別(subscriber identification)データを含んでいる。サービス論理(service logic)によると、サーブされるノードが、レコードのデータフィールドのいずれかにマッチする情報を含むショートメッセージを送るとき、サービングノードは、そのレコードの加入者番号データおよび加入者識別データを持つメッセージを生成し、サーブされるノードへと戻す。
【００２９】
実施形態において、制御要素２２は、オペレーターインターフェース２３を介して番号案内サービスの全体的なパフォーマンスを測定するリクエストを受け取る（工程２−１）。リクエストは、測定されたサービスを識別し、有利には、測定の実行を制御する他のパラメータ、例えば、測定期間、テストが行われるべきエリアなどを含む。制御要素は、測定イベントを作成するリクエストにおける情報を使用する。測定イベントは、測定に使用されることになる、一連の定められたテストメッセージを有する。
【００３０】
テストメッセージおよび／または予期(expected)される応答メッセージのための情報は、制御要素２２において、または、テストエージェント２０において生成され得る。これは、測定された対話型アプリケーションサービスのサービス論理の知識と、そこで使用されるショートメッセージのフォーマットとを、どの要素が持っているかに従って行なわれる。例えば、番号案内サービスの場合、サービス論理は、制御ノード２２には知られていてよいが、テストエージェント２０には知られない。この場合、テストメッセージと、これに対応する予期される応答メッセージの内容との情報が制御要素２２において生成され、測定イベントがトリガーされると、テストエージェント２０へと転送される。その一方で、サービス論理が、テストエージェント２０に対して利用可能となることによって、それが、テストメッセージに含まれることになる情報を受け取ると、予期される応答メッセージの内容を独立して特定することができるようになっていてもよい。代替的には、テストエージェントは、テストメッセージに含まれることになるテスト情報を生成し、かつ、予期される応答メッセージの内容を特定するように構成されてもよい。
【００３１】
例示的な番号案内サービスのケースにおいて、外部者が、定められたエリアにおける、定められた期間での、サービスの全体的なパフォーマンスについての測定された情報をリクエストすると仮定しよう。また、外部者がウェブページ内のフォームを介してリクエストを送信し、フォームを完成することによってサービスの測定イベントを生成すると仮定しよう。この例では、テストエージェントは、モバイル式であり、かつ、サービス論理とテストメッセージの生成、および、予期される応答メッセージの内容の生成は、制御ノードにおいて行われる。制御ノードは、トリガリング情報(triggering information、トリガー情報)を測定イベントを開始するテストエージェントに提供する（工程２−２）。トリガリング情報は、テストメッセージに含まれることになる加入者データブロックのグループの形態でテストデータを有する。トリガリング情報はまた、テストデータとマッチするレコードのディレクトリのエントリーの内容を有する。加えて、トリガリング情報はまた、測定された対話型アプリケーションサービスを識別するための情報を有する。他の測定パラメータもまた、制御ノードによって提供され得る。
【００３２】
この例では、テストエージェントは、実際のテストメッセージを生成する。各テストメッセージは、対話型アプリケーションサービスのために具体的にフォーマットされ得る。テストメッセージの行先アドレスは通常、対話型アプリケーションサービスのプロバイダーを識別し、サービス自体は、テストメッセージの内容において識別され得る。例えば、番号案内サービスは、数字「123456」でアドレス指定されるアプリケーションノードによって提供されるサービスの集まり(cluster)における１つのサービスとなり得る。サービス関連のデータは、テストメッセージの内容に含まれてよく、様々なタイプの情報が、ショートメッセージの内容の適切なフォーマット化によって互いから離れていてよい。例えば、電話番号案内サービスは、テストメッセージの内容の始めにおいて、定められたテキスト文字列「search」で識別されてよく、検索およびマッチングに使用される１つ以上のデータブロックは、テキスト文字列からスペースによって離れていてよい。従って、電話番号案内サービスの全体的なパフォーマンスを測定するためのテストイベントは、テストタスクを有することができ、つまり、番号「123456」宛であり、かつ、ペイロード(payload)「search john doe helsinki」を持つテストメッセージの送達を有することができる。その場合、サービス論理に従って、これに対応する、予期される応答メッセージのペイロードは、識別データフィールドがテキスト文字列「john」、「doe」、および「helsinki」を有する加入者に関連するディレクトリ情報を有することになる。例として、予期される応答メッセージが、第一のディレクトリのエントリー「John Doe、Isopaankatu 3B、00567 Helsinki、+358-9-999999」を有すると考えよう。１つのテストメッセージはまた、さらなる予期される応答メッセージに対応し得るため、予期される応答メッセージもまた、第二のディレクトリのエントリー「John Doe、Harsokatu 3B、00765 Helsinki、+358-9-999999」を有すると仮定しよう。
【００３３】
テストタスクは、テストエージェントからアプリケーションノードへのテストメッセージの送達（工程２−３）、アプリケーションノードからテストエージェントへの１つ以上の予期される応答メッセージの送達（工程２−４）、および、テストエージェントにおける１つ以上の関連メッセージ(associated messages、関連付けられたメッセージ)の検出を含んでいる。関連メッセージは、受け取られたテストメッセージに応答して、サービングノードによって送られた応答メッセージである。前に述べたように、テストメッセージと応答メッセージは、サービス論理によって関連付けられているが、送信プロトコルの観点からは、テストメッセージと応答メッセージは、互いに対する明確なポインタを持たない独立したエンティティである。この対話型アプリケーションサービスの非同期な性質のため、テストエージェントは、受信応答メッセージを特定のテストメッセージに関連付けるための特別な構成を必要とする。本実施形態では、これは、受信メッセージの内容に適用される予め定められたマッチング基準(matching criterion)を用いて達成される。受信メッセージの内容が該マッチング基準を満たす場合、受信メッセージは、関連メッセージであるとみなされる。
【００３４】
該マッチング基準は、受信メッセージが、テストメッセージに対する真の応答であるかどうかを示すため、テストとして使用される。最初のケースでは、４つの行程(legs)毎の送信が完全に成功し、アプリケーションノードが第二の情報を完全に特定した。しかしながら、常にこうなるわけではない。テストエージェントによって受け取られたメッセージは、以前または後に送られたテストメッセージに対する応答メッセージであり得る。アプリケーションノードへの行程の１つにおいて送信エラーが起こったことによって、アプリケーションノードによって受け取られたテストデータブロックが、テストエージェントによって送られたテストデータブロックとは異なっている可能性もある。そのようなケースにおいては、応答は、予期される情報をもはや持たない。メッセージの内容を歪める送信エラーもまた、戻り行程において起こる恐れがある。加えて、アプリケーションノードが適切に動作しないがために、受信メッセージがサービス論理に従った情報を持たない可能性がある。
【００３５】
マッチング基準は、あらゆるテストメッセージに関連して適用され得る規則である。テストメッセージの関連メッセージを検出するために、テストエージェントは、予期される応答メッセージの内容を特定(determine、確定）し、それを受け取られたメッセージの内容と比較する。マッチング基準が満たされれば、受信メッセージは関連メッセージとみなされる。例えば、電話番号案内サービスの場合、受信メッセージが加入者識別データブロック「John」、「Doe」の両方を有する場合、マッチング基準は満たされたとみなされ得る。「Helsinki」といった、他のフィールドとのマッチングは、基準を満たさない。従って、「リクエストされた検索語「john doe helsinki」のデータエントリが見つかりませんでした」のような情報を持つ受信メッセージは、受信メッセージの内容が文字通り予期される結果に対応しなくても、テストメッセージに関連づけられ得る。一方、完全に歪んだメッセージは、テストメッセージには関連付けられず、失敗した送信として現れるであろう。
【００３６】
通常、マッチング基準は、サービス特有(service-specific)であり、サービス論理に直接的にマッチする。典型的には、要素は、サービス論理についての知識を持ち、かつ、テストデータブロックを生成し、また、関連メッセージの検出のためのマッチング基準を提供する。
【００３７】
次に、検出された関連メッセージは、対話型アプリケーションサービスの現在の全体的なパフォーマンスの評価を可能にする測定指標(measurement indication)を特定するために使用され得る。該測定指標を特定するために使用される関連メッセージの特徴は、アプリケーションによって変わり得る。例えば、サービスリクエストに回答があるか、または依然として回答がないかについての情報が、全体的なパフォーマンスの関連する指標を提供する。測定イベントは、一連のテストメッセージを送ることと、テストエージェントにおいて検出された関連メッセージをカウントすることとによって、実行できる。検出された関連メッセージの数と送信されたテストメッセージの数との比率が、対話型アプリケーションサービスの全体的なパフォーマンスを評価するために使用できる。
【００３８】
他の測定指標は、テストイベントの継続時間(duration)に基づいてもよい。そのような測定指標は、テストメッセージおよびその関連メッセージからタイムスタンプを抽出することによって生成され得る。これらのタイムスタンプ同士の間の時間間隔（タイムインターバル）は、対話型アプリケーションサービスの往復(round-trip)の送達時間の測定指標を提供する。
【００３９】
より情報量の多い測定指標は、関連メッセージの内容と、予測される応答メッセージの内容との間の適合(compliance、コンプライアンス）のレベルをより詳細に分析することによって提供され得る。テストエージェントは、関連メッセージの内容と予期される応答メッセージの内容とのさらなる比較に適用される、第二のマッチング基準を有し得る。例えば、番号案内サービスの場合には、第二のマッチング基準は、予期される応答メッセージのデータブロックのいくつが、関連メッセージに含まれるかをテストし得る。我々の例示的なテストタスクでは、応答メッセージは、次の情報を運搬していると予期された：
「John Doe, Isopaankatu 3B, 00567 Helsinki, +358-9-999999」
その場合、予期される応答メッセージのデータブロックは、次のものを有することになる：
［first name］［surname］［streetaddress］［postcode］［city］
受信メッセージが次の情報
「John Doe, Isopaankatu 3B, 00567 Helsinki, +358-9-998999」
を持つ場合、それは、関連メッセージとして検出され、簡易な分析においては、テストタスク成功として現れることになる。しかしながら、ユーザーの観点からすると、返された電話番号が間違っているため、サービスは実際、全くパフォーマンスが良くなかった。より詳細な分析では、予期される応答メッセージのデータブロックは、１つ１つ比較でき、完全に適合するデータブロックの数が、対話型アプリケーションサービスの全体的なパフォーマンスの測定指標として使用できる。
【００４０】
予期される応答メッセージにおけるデータブロックそれぞれについて、位置ベースの指標［１１１１０］を使用することによって、よりいっそう詳細な指標が提供され得る。これによって、失敗した内容の性質が評価において識別でき、異なるタイプの失敗が、異なるように重み付けをされ得る。例えば、例示的な場合では、加入者のファーストネームの失敗は、加入者の電話番号の失敗ほど悪影響がないとみなされてもよい。従って、関連メッセージ「John Doe, Isopaankatu 3B, 00567 Helsinki, +358-9-998999」についての測定指標［１１１１０］は、重みＦＡＩＬ＊４を持ったＦＡＩＬを指し示すと考えることができるが、関連メッセージ「Joe Doe, Isopaankatu 3B, 00567 Helsinki, +358-9-999999」についての測定指標［０１１１１］は、重みＦＡＩＬ＊１だけを持ったＦＡＩＬを指し示すとみなすことができる。
【００４１】
なお、これらの例が例示的なだけであり、保護の範囲から逸脱することなく、様々なマッチング基準が、上述の記載に基づいて、様々なタイプの対話型アプリケーションサービスについて開発され得る。例えば、アプリケーションノードは、サーブされるノードが、データブロック「［value］［converted from］［converted to］」を持つメッセージを送ることによって換算リクエストを提供するモバイル通貨換算サービスを提供し得る。受信メッセージの［converted from］フィールドおよび［converted to］フィールドにおけるデータフィールドが、予期される応答メッセージと両方同じ情報を有する場合、マッチング基準は、満たされたとみなされ得る。基本的な測定指標は、ここでも、通貨換算リクエストと関連応答との比率に基づき得る。より詳細な評価のために、測定指標は、関連メッセージおよび予期される応答メッセージの［value］データクロックにおける値間の差異をさらに示し得る。
【００４２】
テストエージェントはまた、測定指標を測定に関係付けられた(measurement-related)メタデータで補い得る。例えば、テストエージェントは、それがテストメッセージを送るとき、かつ／または、それが関連メッセージを受け取るとき、そのポジションを記録してよいし、これらの記録されたポジションを測定指標に加えてもよい。この測定に関連付けられたメタデータは、対話型サービスのさらなる局面と依存度とを分析するために適用され得る。例えば、位置ベースのメタデータは、対話型アプリケーションサービスの全体的なパフォーマンスの、サーブされるノードの場所に対する依存度を分析することを可能にする。タイムスタンプ、サービングセル識別情報(serving cell identity)などのような、他のタイプのメタデータが適用され得る。
【００４３】
本実施形態では、テストエージェントは、生成された測定指標を制御ノードに提供する（工程２−５）。制御ノードは、測定指標を、測定をリクエストした外部ノードへと直接的に提供し得る（工程２−６）。制御ノードはまた、受け取られた情報をさらに処理してもよく、処理された形式で、結果をリクエスタに提供してよい。
【００４４】
提案されるプロシージャによって、対話型アプリケーションサービスの現在の全体的なパフォーマンスの評価を可能にする具体的な測定指標を自動的に生成することが可能であって、それは、たとえ１つのものだけが、システムのサーブされるノードエンドにおいて動作できる場合であってもである。これは、対話型アプリケーションサービスの動的な全体的なパフォーマンス監視を促進するが、そうしたことは、送達処理の非同期な性質のため、以前は可能ではなかった。テストイベントおよび測定指標の両方は、評価の詳細レベルを高めるべく、容易に増強され得る形式で生成される。
【００４５】
図３は、図２に記載されるシステムのテストエージェントにおいて実装される方法の工程(steps)を図示している。該工程は、１つのテストタスクの実装に関する。これらの工程は、当業者によって増やされ、そのような一連のテストタスクで形成されたテストイベントの実装となり得る。
【００４６】
テストエージェントがスイッチオンされ、アプリケーションノードとの接続を持つと、プロシージャが開始する。テストエージェントは、受け取られたか、または生成されたテストデータブロックを持っており、これらはテストタスクにおいて使用される。テストエージェントは、非リアルタイムメッセージングサービスのメッセージ内にテストデータブロックを含む。これは、ペイロードとしてデータブロックを持ち、非リアルタイムメッセージングサービスでの送達のためにフォーマットされるテストメッセージＴＭである。テストエージェントは、テストメッセージＴＭをアプリケーションノードへ送る（工程３０）。
【００４７】
テストメッセージの送信前、送信時または送信後、テストエージェントは、予期される応答メッセージＥＲＭの内容を特定する（工程３１）。予期される応答メッセージの内容と、テストメッセージの内容との関連性は、定められたアプリケーションサービスのサービス論理に直接的に対応している。
【００４８】
テストメッセージの送信後、テストエージェントは、受信応答メッセージＩＲＭｉを監視し始め、それらのうちの１つが、テストメッセージに応答して、アプリケーションサーバーによって送信される応答メッセージとなり得るかどうかをチェックする。明らかに無関係のメッセージは、非リアルタイムメッセージングサービスのプロトコルによって提供される情報によってフィルタにかけられ取り除かれ得る。例えば、アプリケーションノード以外のアドレスからの受信メッセージが、フィルタにかけられ取り除かれ得る。潜在的応答メッセージは、非リアルタイムメッセージングサービスの受け取られたメッセージの内容を、予期される応答メッセージの内容と比較することによって識別される（工程３２）。評価された対話型アプリケーションサービスに特有のマッチング基準は、内容間のマッチレベルをテストするために使用され得る。
【００４９】
基準が満たされれば（工程３３）、受け取られたメッセージは関連メッセージとして識別されるが（工程３４）、それは、受け取られたメッセージが、先に送信されたテストメッセージに応答して受け取りに成功した応答メッセージとみなされるということを意味する。
【００５０】
次に、関連メッセージは、定められたアプリケーションサービスの現在の全体的なパフォーマンスの評価について測定指標ＭＩを特定するために使用され得る（工程３５）。関連メッセージの特徴は、測定指標のベースとして使用できる。例えば、関連メッセージの存在は、応答が受け取られ、従って、双方向の情報のやり取りの実行が成功しているという指標として使用され得る。対話型サービスアプリケーションの全体的なパフォーマンスの様々な側面を評価するために、プロトコルデータユニット、または関連メッセージの内容もまた、対応する要素、テストメッセージまたは予期される応答メッセージとより詳細に比較され得る。
【００５１】
次に、１つ以上の特定された測定指標ＭＩは、測定イベントをリクエストした当事者に送達をするために制御ノードに転送され得る（工程３６）。
【００５２】
本発明の実施形態は、テストエージェントとして、または、制御ノードとして適用可能な装置を有し、該装置は、上述の方法を実装するための手段を提供するものである。図４は、その目的のための例示的な装置の構成を図示するブロック図を示している。なお、保護の範囲から逸脱することなく、任意のタイプのユーザー端末が適用され得ることに留意されたい。
【００５３】
該装置は、データに対する演算をシステマチックに実行するためのプロセッサユニット４０を有する。プロセッサユニット４０は、１つ以上の算術論理ユニット、多数の特殊レジスタおよび制御回路を本質的に有する要素である。メモリユニット４１は、コンピューター可読データもしくはプログラム、またはユーザーデータが記憶できるデータ媒体を提供する。メモリユニットは、プロセッサユニット４０に接続されている。典型的には、メモリユニット４１は、揮発性または非揮発性のメモリ、例えば、ＥＥＰＲＯＭ、ＲＯＭ、ＰＲＯＭ、ＲＡＭ、ＤＲＡＭ、ＳＲＡＭ、ファームウェア、プログラマブル論理等を有する。装置はまた、装置の内部処理にデータを入力するための少なくとも１つの入力ユニットと、装置の内部処理からデータを出力するための少なくとも１つの出力ユニットとを有するインターフェースユニット４２とを有する。
【００５４】
回線インターフェースが適用される場合、インターフェースユニット４２は、通常、その外部接続ポイントに送達される情報のためと、その外部接続ポイントに接続される回線に供給される情報のためとのゲートウェイの役割をするプラグインユニットを有する。無線インターフェースが適用される場合、インターフェースユニット４２は、典型的には、無線トランシーバーユニットを有し、該無線トランシーバーユニットは、トランスミッタおよびレシーバーを含み、かつ、処理ユニット(processing unit、処理装置)４０に電気的に接続されている。無線トランシーバーユニットのトランスミッタは、処理ユニット４０からビットストリームを受け取り、それをアンテナによって送信用の無線信号に変換する。それに対応して、アンテナが受け取った無線信号は、無線トランシーバーユニットのレシーバーへと導かれ、それが無線信号をビットストリームへと変換し、該ビットストリームは、処理ユニット４０へと、さらなる処理のために転送される。異なる無線インターフェースが１つの無線トランシーバーユニットで実装され得るか、または、別々の無線トランシーバーユニットが異なる無線インターフェースのために設けられ得る。
【００５５】
当該装置のインターフェースユニット４２は、また、キーパッド、タッチスクリーン、マイク、および、データを入力するための同等物、ならびに、スクリーン、タッチスクリーン、スピーカー、および、データを出力するための同等物、を持ったユーザーインターフェースを有していてもよい。所定の、本質的にプログラムされた装置の処理に従って、受け取られ、かつ／または記憶されたデータに対して演算をシステマチックに実行するための手段を提供するため、プロセッサユニット４０、メモリユニット４１、およびインターフェースユニット４２は、電気的に相互接続されている。これらの演算は、制御ノードおよびテストエージェントのために記載されたプロシージャを有する。
【００５６】
概して、装置の様々な実施形態は、ハードウェアもしくは専用回路、ソフトウェア、論理またはそれらの任意の組み合わせにおいて実装され得る。いくつかの態様がハードウェアにおいて実装され得るが、いくつかの他の態様が、コントローラ、マイクロプロセッサまたは他の計算装置によって実行され得るファームウェアまたはソフトウェアにおいて実装され得る。ソフトウェアルーチンは、プログラム製品とも呼ばれ、製造物であり、任意の装置が読めるデータ記憶媒体に記憶でき、またソフトウェアルーチンは、特定のタスクを実行するプログラム命令を含む。本発明の例示的な実施形態はまた、コンピューターで読み取り可能であり、かつ、図４の装置における対話型アプリケーションサービスの全体的なパフォーマンスを測定するための処理を実行するための命令をコード化するコンピュータープログラム製品を提供する。
【００５７】
本発明の様々な態様が、ブロック図、メッセージ流れ図、フローチャートおよび論理流れ図で、または、他のいくつかの図的表現を使って図解され、説明され得るが、図解されるユニット、ブロック、装置、システム要素、プロシージャおよび方法は、例えば、ハードウェア、ソフトウェア、ファームウェア、専用の回路もしくは論理、計算装置、または、それらのいくつかの組み合わせにおいて実装され得るということがよく理解される。
【００５８】
技術が進歩すると、本発明の基本的な着想が様々な形で実装できることが、当業者には明白である。従って、本発明およびその実施形態は、上記の例に限定されず、請求項の範囲内で変わり得る。
【図１】
2014523671.tif 000003
【図２】
2014523671.tif 000004
【図３】
2014523671.tif 000005
【図４】
2014523671.tif 000006
【国際調査報告】
2014523671.tif 000007
2014523671.tif 000008