(57)【特許請求の範囲】
【請求項１】
ワイヤレス通信ネットワークの中でのグループ通信における障害を診断するための方法であって、
グループ通信サーバのグループ通信で障害が発生したと判定するステップと、
前記障害に応答してロギングすべきイベントのセットを決定するステップと、を含み、イベントの前記セットが前記障害の種類に応答して一緒にロギングされ、
前記方法が、
イベントの前記セットの第1のイベントがロギングできないと判定されたことに基づいて、イベントの前記セットの第2のイベントをロギングするステップと、
前記第2のイベントのロギングを開始した後で、前記第1のイベントをロギングできると判定するステップと、
前記第1のイベントをロギングするステップと、
前記ロギングの結果をメモリに記憶するステップと
をさらに含む、方法。
【請求項２】
前記ロギングの前記結果を前記グループ通信サーバに送信するステップをさらに含む、請求項1に記載の方法。
【請求項３】
ロギングすべきイベントのセットを決定するステップが、前記ワイヤレス通信ネットワークのコンポーネントの負荷状態に基づく、請求項1に記載の方法。
【請求項４】
ロギングすべきイベントのセットを決定するステップが、key performance indicator (KPI)の値に基づく、請求項1に記載の方法。
【請求項５】
ロギングすべきイベントのセットを決定するステップが、前記障害の発生率に基づく、請求項1に記載の方法。
【請求項６】
ロギングすべきイベントのセットを決定するステップが、前記ワイヤレス通信ネットワークのコンポーネントの負荷の閾値に基づく、請求項1に記載の方法。
【請求項７】
イベントの前記セットがロギングテンプレートに対応する、請求項1に記載の方法。
【請求項８】
ロギングを停止すると決定するステップと、
イベントの前記セットのロギングを停止するステップと
をさらに含む、請求項1に記載の方法。
【請求項９】
ロギングを停止すると決定するステップが、
イベントの終了がロギングされたことに基づいてロギングを停止すると決定するステップ
を含む、請求項8に記載の方法。
【請求項１０】
ロギングを停止すると決定するステップが、
タイマーの満了に基づいてロギングを停止すると決定するステップ
を含む、請求項8に記載の方法。
【請求項１１】
ロギングを停止すると決定するステップが、
前記ワイヤレス通信ネットワークのコンポーネントの負荷の閾値に到達したことに基づいて、ロギングを停止すると決定するステップ
を含む、請求項8に記載の方法。
【請求項１２】
ロギングを停止すると決定するステップが、
ロギングの停止をユーザが望んでいるという指示を受信したことに基づいて、ロギングを停止すると決定するステップ
を含む、請求項8に記載の方法。
【請求項１３】
前記負荷の閾値が、
イベントの発生率
を含む、請求項6に記載の方法。
【請求項１４】
ワイヤレス通信ネットワークの中でのグループ通信サーバを含むグループ通信における障害を診断するための方法であって、前記グループ通信サーバが、通信グループの送信ワイヤレス通信デバイスからの、グループ向けの通信を選択的に受信し、前記通信グループの他のメンバーのワイヤレス通信デバイスに、前記グループ向けのメディアを送信するように構成され、前記方法が、
前記グループ通信サーバのグループ通信で障害が発生したと判定するステップと、
第1のイベントのロギングを開始するための第1の指示を、前記ワイヤレス通信ネットワークの第1のコンポーネントへ、前記グループ通信サーバによって送信するステップと、
第2のイベントのロギングを開始するための第2の指示を、前記ワイヤレス通信ネットワークの第2のコンポーネントへ、前記グループ通信サーバによって送信するステップと、
前記第1のコンポーネントによって実行されたロギングに対応する第1のログを、前記第1のコンポーネントから受信するステップと、
前記第2のコンポーネントによって実行されたロギングに対応する第2のログを、前記第2のコンポーネントから受信するステップと、
前記第1のログおよび前記第2のログを含む第3のログを記憶するステップと
を含む、方法。
【請求項１５】
前記第1のコンポーネントがワイヤレス通信ハンドセットを含む、請求項14に記載の方法。
【請求項１６】
前記第1のコンポーネントによって実行されたロギングに対応する第1のログを、前記第1のコンポーネントから受信するステップが、
前記第1のコンポーネントが前記第1のイベントをロギングできないと前記第1のコンポーネントが判定したことに応答して、前記第1のコンポーネントによって実行された第3のイベントのロギングを含む前記第1のログを、前記第1のコンポーネントから受信するステップ
を含む、請求項14に記載の方法。
【請求項１７】
ワイヤレス通信ネットワークの中でのグループ通信における障害を診断するためのシステムであって、
グループ通信サーバのグループ通信で障害が発生したと判定するための手段と、
前記障害に応答してロギングすべきイベントのセットを決定するための手段と、を含み、イベントの前記セットが前記障害の種類に応答して一緒にロギングされ、
前記システムが、
イベントの前記セットの第1のイベントがロギングできないと判定されたことに基づいて、イベントの前記セットの第2のイベントをロギングするための手段と、
前記第2のイベントのロギングを開始した後で、前記第1のイベントをロギングできると判定するための手段と、
前記第1のイベントをロギングするための手段と、
前記ロギングの結果をメモリに記憶するための手段と
をさらに含む、システム。
【請求項１８】
ワイヤレス通信ネットワークの中でのグループ通信サーバを含むグループ通信における障害を診断するためのシステムであって、前記グループ通信サーバが、通信グループの送信ワイヤレス通信デバイスからの、グループ向けの通信を選択的に受信し、前記通信グループの他のメンバーのワイヤレス通信デバイスに、前記グループ向けのメディアを送信するように構成され、前記システムが、
前記グループ通信サーバのグループ通信で障害が発生したと判定するための手段と、
第1のイベントのロギングを開始するための第1の指示を、前記ワイヤレス通信ネットワークの第1のコンポーネントへ、前記グループ通信サーバによって送信するための手段と
、
第2のイベントのロギングを開始するための第2の指示を、前記ワイヤレス通信ネットワークの第2のコンポーネントへ、前記グループ通信サーバによって送信するための手段と、
前記第1のコンポーネントによって実行されたロギングに対応する第1のログを、前記第1のコンポーネントから受信するための手段と、
前記第2のコンポーネントによって実行されたロギングに対応する第2のログを、前記第2のコンポーネントから受信するための手段と、
前記第1のログおよび前記第2のログを含む第3のログを記憶するための手段と
を含む、システム。
【請求項１９】
前記第1のコンポーネントがワイヤレス通信ハンドセットを含む、請求項18に記載のシステム。
【請求項２０】
前記第1のコンポーネントによって実行されたロギングに対応する第1のログを、前記第1のコンポーネントから受信するための手段が、
前記第1のコンポーネントが前記第1のイベントをロギングできないと前記第1のコンポーネントが判定したことに応答して、前記第1のコンポーネントによって実行された第3のイベントのロギングを含む前記第1のログを、前記第1のコンポーネントから受信するための手段
を含む、請求項18に記載のシステム。
【請求項２１】
ワイヤレス通信ネットワークの中でのグループ通信における障害を診断するためのシステムであって、
プロセッサと、
前記プロセッサと通信可能に結合された、機械可読命令を有する第1のメモリと
を含み、前記機械可読命令が、前記プロセッサ上で実行されると、動作を前記プロセッサに実行させ、
前記動作が、
グループ通信サーバのグループ通信で障害が発生したと判定するステップと、
前記障害に応答してロギングすべきイベントのセットを決定するステップと、を含み、イベントの前記セットが前記障害の種類に応答して一緒にロギングされ、
前記動作が、
イベントの前記セットの第1のイベントがロギングできないと判定されたことに基づいて、イベントの前記セットの第2のイベントをロギングするステップと、
前記第2のイベントのロギングを開始した後で、前記第1のイベントをロギングできると判定するステップと、
前記第1のイベントをロギングするステップと、
前記ロギングの結果を第２のメモリに記憶するステップと
をさらに含む、システム。
【請求項２２】
前記ロギングの前記結果を前記第2のメモリに記憶するステップが、ワイヤレス通信ハンドセットで行われ、前記第1のメモリがさらに機械可読命令を有し、前記機械可読命令が、前記プロセッサ上で実行されると、
前記ロギングの前記結果を前記グループ通信サーバに送信するステップ
を含む動作を前記プロセッサに実行させる、請求項21に記載のシステム。
【請求項２３】
ロギングすべきイベントのセットを決定するステップが、前記ワイヤレス通信ネットワークのコンポーネントの負荷状態に基づく、請求項21に記載のシステム。
【請求項２４】
ロギングすべきイベントのセットを決定するステップが、key performance indicator (KPI)の値に基づく、請求項21に記載のシステム。
【請求項２５】
ロギングすべきイベントのセットを決定するステップが、前記障害の発生率に基づく、請求項21に記載のシステム。
【請求項２６】
ロギングすべきイベントのセットを決定するステップが、前記ワイヤレス通信ネットワークのコンポーネントの負荷の閾値に基づく、請求項21に記載のシステム。
【請求項２７】
イベントの前記セットがロギングテンプレートに対応する、請求項21に記載のシステム。
【請求項２８】
前記第1のメモリがさらに機械可読命令を有し、前記機械可読命令が、前記プロセッサ上で実行されると、
ロギングを停止すると決定するステップと、
イベントの前記セットのロギングを停止するステップと
を含む動作を前記プロセッサに実行させる、請求項21に記載のシステム。
【請求項２９】
ロギングを停止すると決定するステップが、
イベントの終了がロギングされたことに基づいてロギングを停止すると決定するステップ
を含む、請求項28に記載のシステム。
【請求項３０】
ロギングを停止すると決定するステップが、
タイマーの満了に基づいてロギングを停止すると決定するステップ
を含む、請求項28に記載のシステム。
【請求項３１】
ロギングを停止すると決定するステップが、
前記ワイヤレス通信ネットワークのコンポーネントの負荷の閾値に到達したことに基づいて、ロギングを停止すると決定するステップ
を含む、請求項28に記載のシステム。
【請求項３２】
ロギングを停止すると決定するステップが、
ロギングの停止をユーザが望んでいるという指示を受信したことに基づいて、ロギングを停止すると決定するステップ
を含む、請求項28に記載のシステム。
【請求項３３】
前記負荷の閾値が、
イベントの発生率
を含む、請求項26に記載のシステム。
【請求項３４】
前記負荷の閾値が、
key performance indicator (KPI)の値
を含む、請求項26に記載のシステム。
【請求項３５】
ワイヤレス通信ネットワークの中でのグループ通信サーバを含むグループ通信における障害を診断するためのシステムであって、前記グループ通信サーバが、通信グループの送信ワイヤレス通信デバイスから、グループ向けの通信を選択的に受信し、前記通信グループの他のメンバーのワイヤレス通信デバイスに、前記グループ向けのメディアを送信するように構成され、前記システムが、
プロセッサと、
前記プロセッサと通信可能に結合された、機械可読命令を有する第1のメモリと
を含み、前記機械可読命令が、前記プロセッサ上で実行されると、
前記グループ通信サーバのグループ通信で障害が発生したと判定するステップと、
第1のイベントのロギングを開始するための第1の指示を、前記ワイヤレス通信ネットワークの第1のコンポーネントへ、前記グループ通信サーバによって送信するステップと、
第2のイベントのロギングを開始するための第2の指示を、前記ワイヤレス通信ネットワークの第2のコンポーネントへ、前記グループ通信サーバによって送信するステップと、
前記第1のコンポーネントによって実行されたロギングに対応する第1のログを、前記第1のコンポーネントから受信するステップと、
前記第2のコンポーネントによって実行されたロギングに対応する第2のログを、前記第2のコンポーネントから受信するステップと、
前記第1のログおよび前記第2のログを含む第3のログを記憶するステップと
を含む動作を前記プロセッサに実行させる、システム。
【請求項３６】
前記第1のコンポーネントがワイヤレス通信ハンドセットを含む、請求項35に記載のシステム。
【請求項３７】
前記第1のコンポーネントによって実行されたロギングに対応する第1のログを、前記第1のコンポーネントから受信するステップが、
前記第1のコンポーネントが前記第1のイベントをロギングできないと前記第1のコンポーネントが判定したことに応答して、前記第1のコンポーネントによって実行された第3のイベントのロギングを含む前記第1のログを、前記第1のコンポーネントから受信するステップ
を含む、請求項36に記載のシステム。
【請求項３８】
ワイヤレス通信ネットワークの中でのグループ通信における障害を診断するための、コンピュータ可読命令を有するコンピュータ可読記憶媒体であって、前記コンピュータ可読命令が、コンピュータ上で実行されると、動作を前記コンピュータに実行させ、
前記動作が、
グループ通信サーバのグループ通信で障害が発生したと判定するステップと、
前記障害に応答してロギングすべきイベントのセットを決定するステップと、を含み、イベントの前記セットが前記障害の種類に応答して一緒にロギングされ、
前記動作が、
イベントの前記セットの第1のイベントがロギングできないと判定されたことに基づいて、イベントの前記セットの第2のイベントをロギングするステップと、
前記第2のイベントのロギングを開始した後で、前記第1のイベントをロギングできると判定するステップと、
前記第1のイベントをロギングするステップと、
前記ロギングの結果をメモリに記憶するステップと
をさらに含む、コンピュータ可読記憶媒体。
【請求項３９】
前記ロギングの前記結果をメモリに記憶するステップが、ワイヤレス通信ハンドセットで行われ、
前記コンピュータ上で実行されると、
前記ロギングの前記結果を前記グループ通信サーバに送信するステップ
を含む動作を前記コンピュータに実行させるコンピュータ可読命令をさらに有する、請求項38に記載のコンピュータ可読記憶媒体。
【請求項４０】
ロギングすべきイベントのセットを決定するステップが、前記ワイヤレス通信ネットワークのコンポーネントの負荷状態に基づく、請求項38に記載のコンピュータ可読記憶媒体。
【請求項４１】
ロギングすべきイベントのセットを決定するステップが、key performance indicator (KPI)の値に基づく、請求項38に記載のコンピュータ可読記憶媒体。
【請求項４２】
ロギングすべきイベントのセットを決定するステップが、前記障害の発生率に基づく、請求項38に記載のコンピュータ可読記憶媒体。
【請求項４３】
ロギングすべきイベントのセットを決定するステップが、前記ワイヤレス通信ネットワークのコンポーネントの負荷の閾値に基づく、請求項38に記載のコンピュータ可読記憶媒体。
【請求項４４】
イベントの前記セットがロギングテンプレートに対応する、請求項38に記載のコンピュータ可読記憶媒体。
【請求項４５】
前記コンピュータによって実行されると、
ロギングを停止すると決定するステップと、
イベントの前記セットのロギングを停止するステップと
を含む動作を前記コンピュータに実行させるコンピュータ可読命令をさらに有する、請求項38に記載のコンピュータ可読記憶媒体。
【請求項４６】
ロギングを停止すると決定するステップが、
イベントの終了がロギングされたことに基づいてロギングを停止すると決定するステップ
を含む、請求項38に記載のコンピュータ可読記憶媒体。
【請求項４７】
ロギングを停止すると決定するステップが、
タイマーの満了に基づいてロギングを停止すると決定するステップ
を含む、請求項38に記載のコンピュータ可読記憶媒体。
【請求項４８】
ロギングを停止すると決定するステップが、
前記ワイヤレス通信ネットワークのコンポーネントの負荷の閾値に到達したことに基づいて、ロギングを停止すると決定するステップ
を含む、請求項38に記載のコンピュータ可読記憶媒体。
【請求項４９】
ロギングを停止すると決定するステップが、
ロギングの停止をユーザが望んでいるという指示を受信したことに基づいて、ロギングを停止すると決定するステップ
を含む、請求項45に記載のコンピュータ可読記憶媒体。
【請求項５０】
前記負荷の閾値が、
イベントの発生率
を含む、請求項43に記載のコンピュータ可読記憶媒体。
【請求項５１】
前記負荷の閾値が、
key performance indicator (KPI)の値
を含む、請求項43に記載のコンピュータ可読記憶媒体。
【請求項５２】
ワイヤレス通信ネットワークの中でのグループ通信サーバを含むグループ通信における障害を診断するためのコンピュータ可読記憶媒体であって、前記グループ通信サーバが、
通信グループの送信ワイヤレス通信デバイスからの、グループ向けの通信を選択的に受信し、前記通信グループの他のメンバーのワイヤレス通信デバイスに、前記グループ向けのメディアを送信するように構成され、前記コンピュータ可読記憶媒体が、
コンピュータ上で実行されると、
前記グループ通信サーバのグループ通信で障害が発生したと判定するステップと、
第1のイベントのロギングを開始するための第1の指示を、前記ワイヤレス通信ネットワークの第1のコンポーネントへ、前記グループ通信サーバによって送信するステップと、
第2のイベントのロギングを開始するための第2の指示を、前記ワイヤレス通信ネットワークの第2のコンポーネントへ、前記グループ通信サーバによって送信するステップと、
前記第1のコンポーネントによって実行されたロギングに対応する第1のログを、前記第1のコンポーネントから受信するステップと、
前記第2のコンポーネントによって実行されたロギングに対応する第2のログを、前記第2のコンポーネントから受信するステップと、
前記第1のログおよび前記第2のログを含む第3のログを記憶するステップと
を含む動作を前記コンピュータに実行させるコンピュータ可読命令を有する、コンピュータ可読記憶媒体。
【請求項５３】
前記第1のコンポーネントがワイヤレス通信ハンドセットを含む、請求項52に記載のコンピュータ可読記憶媒体。
【請求項５４】
前記第1のコンポーネントによって実行されたロギングに対応する前記第1のログを、前記第1のコンポーネントから受信するステップが、
前記第1のコンポーネントが前記第1のイベントをロギングできないと前記第1のコンポーネントが判定したことに応答して、前記第1のコンポーネントによって実行された第3のイベントのロギングを含む前記第1のログを、前記第1のコンポーネントから受信するステップ
を含む、請求項52に記載のコンピュータ可読記憶媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ワイヤレス通信システムにおけるイベントのロギングに関する。より具体的には、本発明は、システムの利用可能なリソースに基づいて、両方が時間とともに変わり得る、ワイヤレス通信システムのロギングの種類および量と、特定のイベントをロギングする能力とを適応させることに関する。
【背景技術】
【０００２】
ワイヤレス通信システムは、携帯電話、PDA、およびミニラップトップのようなモバイル遠隔通信デバイスによる、他のモバイル遠隔通信デバイスならびにPOTS(「plain ordinary telephone system」)上の有線遠隔通信デバイスとの通信を可能にする。
【０００３】
一般に「プッシュツートーク」(PTT)機能と呼ばれる、1対1または1対多数の高速な通信を実現する、ワイヤレス遠隔通信サービスが存在する。このサービスは、「グループ通信」と呼ばれることがある。通信するモバイルデバイスに対する受信者デバイスの具体的なPTTグループは、通常キャリアによって設定される。PTT通信接続は通常、話者とグループの各メンバーデバイスとの間で半二重リンクをアクティブ化するモバイルデバイス上で、単一のボタンを押下することで開始され、ボタンが離されると、デバイスは着信するPTT送信を受信することができる。PTTまたはグループ通信を確立するための他の方法は、任意の既存のモバイルデバイスを通じたものである可能性があってよい。これらのグループ通信はまた、モバイルデバイスとグループ通信サーバとの間の、全二重通信であってよく、または、半二重通信と全二重通信を遷移するものであってもよい。既存のPTTシステムは、呼設定時間がより高速であり、たとえば、確立に5秒より長くかかり得るセルラー音声チャネルに対して、設定時間が理想的には1秒の範囲内にあるので、従来のセルラーシステムに対して利点がある。一部の構成では、PTTの話者は、話者が話している時には他のグループメンバーが話すことができない、「発言権」を有する。話者がPTTボタンを離すと、グループの任意の他の個々のメンバーはそのPTTボタンを操作することができ、そのメンバーが発言権を有するようになる。一般的に、PTTシステムは、標準的なボイスオーバーインターネットプロトコル(VoIP)技術を使う。音声情報は、IPベースのデータネットワークからデジタルで送られる。PTTの状況では、標準的なセルラーインフラストラクチャを使う代わりに、ネットワーク中の各IPエンドポイント間の、別々のポイントツーポイント接続を組み合わせることによって、呼が形成される。PTTシステムを開始することで、対象デバイスへの呼が生成される。呼の発信者の声は、キャリアのネットワークを通じて、対象のハンドセットに送信され得る。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
PTTシステムのようなワイヤレス通信システムの、効率的でタイムリーなトラブルシューティング能力および診断能力に関する、主要な問題の1つは、報告された問題の診断情報を含むみ問題のトラブルシューティングに必要な、システムが利用可能な診断ログがないことである。大抵の場合、遠隔通信ネットワークは、呼設定失敗が多いこと、呼失敗率が高いこと、または帯域幅が狭いことのような、ネットワークにおける問題を示すために、key performance indicator (「KPI」)またはoperation and maintenance (「O&M」)の測定結果を提供する。しかし、報告された問題または性能の低下を迅速に解決するために、ネットワークエンジニアには、障害の詳細な診断情報を保存する正しいログのセットが必要である。遠隔通信ノードの性質により、帯域幅が限定されているため、かつ/または、たとえばメモリ、CPU利用率などのモバイルデバイスのリソースが制限されているため、詳細な診断情報を継続的に収集するのは不可能である。多くの場合、報告された問題の後、ネットワークの運用管理チームは、最初のトラブルシューティングの結果に基づいて問題のトラブルシューティングを試み、ネットワーク運用チームは、事前に定義されたフィルタまたはテンプレートを使って、詳細な診断ログの収集を開始する。
【０００５】
場合によっては、前に報告された問題が現在は起きていないので、または、前に問題が報告された時と診断ロギングが手動で開始された時との時間差によって、所望のログを収集するのが難しい。また、システムのシステムリソース(通信リンク、サーバまたはモバイルリソースなど)の制限によって、すべての呼がロギングされているとは限らないので、所望のログを収集するのが難しいことがあり、その結果サーバは一部の呼しかロギングせず(たとえば、100回の試行のうちから1つの呼のようなアルゴリズムに基づいて)、所望のログが収集されない。
【０００６】
別の問題は、問題を最良に診断するであろうフィルタで、ロギングを開始しないことであり得る。診断ロギングに関するさらなる問題は、そのようなロギングの実行が消費するシステムリソースと直接関係する。イベントの発生のロギングには、システムの中央演算処理装置(CPU)の負荷のような、システムリソースの使用と、ロギングに利用可能なシステムの記憶空間とを必要とする。ロギングに利用可能なこれらのシステムリソースは、動的に変化し得る。たとえば、これらの利用可能なシステムリソースは、システム中のアクティブな呼の数に従って変化し得る。
【０００７】
利用可能なシステムリソースが変化するに従って、所望のイベントの発生のすべてをロギングするのに利用可能な、十分なシステムリソースが存在しなくなることがある。所望のイベントの発生のすべてのロギングに利用可能なシステムリソースが十分にない場合、従来技術では、ロギングを全く行わなくてもよいとされる。
【０００８】
したがって、エラーイベントの発生を適応的にロギングするための技法を提供するのが有利であり、そのような技法は、利用可能なシステムリソースの量に基づいて、ロギングの量を調整することができる。
【課題を解決するための手段】
【０００９】
簡単に説明すると、本発明は、イベントの発生の適応的なロギングを実現する、システム、方法、およびコンピュータ可読記憶媒体を含む。ある実施形態では、障害の発生に応答して、ワイヤレス通信システムが、ロギングすべき第1のイベントのセットを決定し、その第1のイベントのセットの発生のロギングを開始する。より後の時点で、ワイヤレス通信システムは、システムリソースの使用量が閾値を超えたと判定する。閾値に達したと判定されたことに応答して、ワイヤレス通信システムは次いで、ロギングすべき第2のイベントのセットを決定し、この第2のイベントのセットは第1のイベントのセットとは異なる。ある実施形態では、この第2のイベントのセットは、第1のイベントのセットのサブセットからなる。ワイヤレス通信システムは次いで、第2のイベントのセットの発生のロギングに変更する(または適応する)。
【００１０】
別の実施形態では、障害の発生に応答して、ワイヤレス通信システムは、ロギングされ得る10個のイベントのうちの3個のイベントのロギングを試みる。イベントAは、この障害が発生した時に最もロギングが望まれる、10個のイベントのうちの1つのイベントであるが、イベントAはロギングできないものとする。ワイヤレス通信システムは、イベントB、C、およびDからなる異なるイベントのセット、または、イベントAをロギングできない時にロギングが最も望まれるイベントのセットをロギングするのを開始することによって、適応する。その後、ワイヤレス通信システムは、イベントAを測定できるが、イベントAをイベントB、C、およびDとともにロギングするのに利用可能なシステムリソースが十分存在しないと判定する。それに応じて、ワイヤレス通信システムは、イベントA、C、およびD(ロギングするのに十分なシステムリソースがあるイベントのセット)をロギングし、イベントB、C、およびDの中でロギングが最も望まれないイベントBを取り下げることによって、適応する。十分な量のイベントがロギングされたとワイヤレス通信システムが判定すると、ワイヤレス通信システムはロギング処理を終了する。
【００１１】
したがって、本システム、方法、およびコンピュータ可読記憶媒体は、「ロギングする」および「ロギングしない」よりも詳細度が高い、イベントの発生をロギングする能力を提供することによって、システムの管理者によるシステムの異常の源の判定を可能にするログを得る確率が向上するという点で、有利である。
【００１２】
本発明の他の目的、特徴、および利点は、図面の簡単な説明、発明を実施するための形態、および特許請求の範囲の検討後に明らかになろう。
【図面の簡単な説明】
【００１３】
【図１】ワイヤレスネットワークにわたってグループ通信サーバおよび他のコンピュータデバイスと通信する、ワイヤレス遠隔通信システムの指定されたグループを有する、ワイヤレスネットワークの代表的な図である。
【図２】グループメンバーのワイヤレス遠隔通信デバイス間でのグループ通信サーバ制御通信を有する、共通のセルラー遠隔通信構成におけるワイヤレスネットワークの一実施形態の代表的な図である。
【図３】PTT機能を有するワイヤレス遠隔通信デバイスのコンピュータプラットフォームを示すブロック図である。
【図４】PTTクライアントとグループ向けメディアクライアントとを有する、通信グループアプリケーションのソフトウェア層の一実施形態を示す図である。
【図５】例示的なモバイル通信デバイスを示す図である。
【図６】ワイヤレス通信システムの負荷に基づいた適応型の診断ロギングの、例示的な処理フローを示す図である。
【図７】イベントをロギングする能力の変化に基づく、適応型の診断ロギングの例示的な動作手順を示す図である。
【図８】グループ通信の適応型の診断ロギングの、例示的な呼の流れ図である。
【図９】グループ通信サーバが、グループ通信の適応型の診断ロギングを行う、例示的なワイヤレス通信システムを示す図である。
【発明を実施するための形態】
【００１４】
この説明では、「モバイル通信デバイス」、「通信デバイス」、「ワイヤレスデバイス」、「ワイヤレス通信デバイス」、「PTT通信デバイス」、「ハンドヘルドデバイス」、「モバイルデバイス」、および「ハンドセット」という用語は互換的に使われる。「呼」および「通信」という用語も、互換的に使われる。本明細書で使われる「アプリケーション」という用語は、実行可能なソフトウェアファイルおよび実行不可能なソフトウェアファイル、生データ、統合されたデータ、パッチ、および他のコードセグメントを包含することが意図される。「グループ通信」という用語は、真のもしくは仮想的な半二重チャネルまたは全二重チャネルにわたり、ワイヤレス通信デバイス間で送信される、ポイントツーポイントまたはポイントツーマルチポイントの通信を意味する。「例示的」という用語は、開示する要素または実施形態が例にすぎず、いかなる選好も示さないことを意味する。さらに、同じ番号は、いくつかの図面を通して同じ要素を指し、冠詞「a」および「the」は、本明細書において別段に規定されていない限り、複数への言及を含む。
【００１５】
いくつかの具体的な詳細が、本開示の様々な実施形態の完全な理解をもたらすために、以下の説明および図面において述べられる。コンピューティング技術およびソフトウェア技術と関連付けられることが多い、いくつかのよく知られている詳細は、本開示の様々な実施形態を不必要に曖昧にするのを避けるために、以下の開示では述べられていない。さらに、以下で説明される詳細の1つまたは複数を伴わずに、本開示の他の実施形態を実行できることを、当業者は理解するだろう。最後に、以下の開示においては、様々な方法がステップおよび順序に言及して説明されるが、説明そのものが、本開示の実施形態の明確な実装形態を与えるためのものであり、ステップおよびステップの順序は、本開示の実行に必要であると見なされるべきではない。
【００１６】
本明細書で説明される様々な技法は、ハードウェアもしくはソフトウェアとともに、または適切な場合には、これら両方の組合せで実装され得ることを理解されたい。したがって、本開示の方法および装置、またはその何らかの態様もしくは部分は、フレキシブルディスケット、CD-ROM、ハードドライブ、または任意の他の機械可読記憶媒体のような、有形の媒体に具現化されるプログラムコード(すなわち命令)の形態であってよく、プログラムコードが、コンピュータのような機械にロードされ機械によって実行される場合、その機械は本開示を実行するための装置になる。プログラム可能なコンピュータでプログラムコードを実行する場合、コンピューティングデバイスは一般に、プロセッサ、プロセッサによって読み取ることができる記憶媒体(揮発性メモリおよび非揮発性メモリおよび/または記憶素子を含む)、少なくとも1つの入力デバイス、および少なくとも1つの出力デバイスを含む。1つまたは複数のプログラムは、たとえば、アプリケーションプログラミングインターフェース(API)、再使用可能な制御などの使用を通じて、本開示に関連して説明される処理を実装または利用できる。そのようなプログラムは、好ましくは、コンピュータシステムと通信するために、ハイレベル手続プログラミング言語またはオブジェクト指向プログラミング言語において実装される。しかし、プログラムは、所望であれば、アセンブリ言語または機械言語において実装されてもよい。いずれの場合でも、言語は、コンパイルされる言語または解釈される言語であってよく、ハードウェア実装と組み合わされ得る。
【００１７】
全体にわたって同様の番号が同様の要素を表す図面を参照すると、図1は、1つまたは複数のワイヤレス遠隔通信デバイスを含むシステム10の一実施形態を示す。プッシュツートーク(PTT)グループ12が、1つまたは複数のワイヤレス遠隔通信デバイスの間でグループメディアを共有するために、形成され得る。PTTグループはさらに、ワイヤレスネットワーク20にわたって、電話14、スマートページャ16、および携帯情報端末(PDA)18のようなデバイスとともに、他のワイヤレス遠隔通信デバイスを含み得る。システム10では、各ワイヤレス遠隔通信デバイス14、16、18は、ワイヤレス通信ネットワーク20にわたって、複数のワイヤレス遠隔通信デバイスのうちの、1つまたは複数の他のワイヤレス遠隔通信デバイスの対象セットと、選択的に直接通信できる。たとえば、携帯電話14の対象セットは、ページャ16およびPDA 18のような、通信グループ12または通信グループ12のサブセットの中のすべてのデバイスであってよい。
【００１８】
この実施形態では、ワイヤレス遠隔通信デバイス(携帯電話14のような)は、ここではサーバ32として示されワイヤレスネットワーク20にわたってサーバ側LAN 30上に存在する、グループ通信コンピュータデバイスに、ワイヤレスデバイスがワイヤレスネットワーク20上に存在すること、すなわちアクセス可能であることを知らせる。グループ通信コンピュータデバイス32は、この情報を、第1のワイヤレス遠隔通信デバイスによって指定される対象のワイヤレス遠隔通信デバイスのセットと共有することができ、または、サーバ側LAN 30上に存在する、もしくはワイヤレスネットワーク20にわたってアクセス可能である、他のコンピュータデバイスと共有することができる。グループ通信コンピュータデバイス32は、ワイヤレスデバイスのグループ識別データを記憶するための、付属の、またはアクセス可能なデータベース34を有し得る。ここではファイル管理サーバとして示されるデータ記憶装置36も、サーバ側LAN 30上に存在し得る。サーバ側LAN 30上に、またはワイヤレスネットワーク20(ある実施形態では、インターネットを含む)にわたって存在するコンピュータコンポーネントの数は、限定されないことを理解されたい。
【００１９】
PTT通信のような直接通信は、通信するワイヤレス遠隔通信デバイス14、16、18と、対象セットの1つまたは複数の他のワイヤレス遠隔通信デバイスとの間の、半二重チャネルを通じて確立され得る。また、グループ通信コンピュータデバイス32は、対象セットのワイヤレス遠隔通信デバイスの少なくとも1つが、ワイヤレスネットワーク20上に存在することをグループ通信コンピュータデバイス32に知らせている場合、要求された直接通信を対象セットに橋渡ししようと試みることができる。
【００２０】
グループ通信コンピュータデバイス32はまた、ワイヤレスネットワーク20上での存在をグループ通信コンピュータデバイス32に知らせていない、対象セット12のワイヤレス遠隔通信デバイスがない(または1つしかない)場合、直接通信を対象セット12に橋渡しできないことを、ワイヤレス遠隔通信デバイス14、16、18に知らせることができる。さらに、グループ通信コンピュータデバイス32は、グループ識別データの付属データベース34を有するものとしてここで示されるが、グループ通信コンピュータデバイス32は、その中にグループ識別データが存在していてよく、本明細書で説明されるすべての記憶機能を実行できる。
【００２１】
要約すると、システム10は、ワイヤレス通信ネットワーク20にわたって直接のグループ通信で互いに通信するワイヤレス通信デバイスの通信グループ12のメンバーである、携帯電話14のような少なくとも1つのワイヤレス通信デバイスを含み、少なくとも1つのワイヤレス通信デバイスは、通信グループ12の他のメンバーに、グループ向けの通信を選択的に送るように構成される。少なくとも1つのグループ通信コンピュータデバイスまたはサーバ32は、ワイヤレス通信ネットワーク20上の通信グループ12についての情報を記憶するように構成され、この情報は、1つまたは複数の通信グループの、特定メンバーのワイヤレス通信デバイスの識別情報を含む。グループ通信コンピュータデバイス32はさらに、通信グループ12の、携帯電話14のような送信ワイヤレス通信デバイスから、グループ向けの通信を選択的に受信し、送信ワイヤレス通信デバイスのために、通信グループ12の他のメンバーのワイヤレス通信デバイスにグループ向けのメディアを送信するように構成される。
【００２２】
システム10はさらに、グループ通信コンピュータデバイス32と通信しているデータ記憶装置36を含んでよく、グループ通信コンピュータデバイス32は、データ記憶装置36にグループ向けのメディアを送信するように構成される。データ記憶装置36は、(携帯電話14のような)ワイヤレス通信デバイスからグループ指定のメディアを受信し、グループ向けのメディアの送信先の通信グループ12のメンバーが、ワイヤレス通信ネットワーク20にわたって記憶されたグループ向けのメディアにアクセスするのを、選択的に許可するように構成される。
【００２３】
グループ向けのメディアは、JPEG、TIFなどの形式の写真のようなグラフィックメディア、MP3、MP4、WAVなどのようなオーディオファイルであってよい。メディアはまた、マルチメディアアプリケーション(PowerPoint、MOVファイルなど)のようなストリーミングメディアであってもよい。グループ向けのメディアはまた、ストリーミングメディアであってよく、または、データ記憶装置36でホストされるゲームまたは私的な電子掲示板のような、ワイヤレス通信ネットワーク20上の別のコンピュータデバイスにおける双方向のセッションであってよい。たとえば、ゲームの参加者は、グループ通信を介して、進行中のゲームについてチャットすることができる。また、グループ向けのメディアは、実質的にリアルタイムで、または遅延して、話者の映像が他のグループメンバーにブロードキャストされる、通信グループのメンバー間のビデオ会議であってよい。
【００２４】
本明細書でさらに説明されるように、ワイヤレス通信デバイス14、16、18は、通信グループ12のメンバーのワイヤレス通信デバイスとのグループ通信に関与していてよく、同じ通信セッションでのグループ通信の間に、またはその通信とは独立に、グループ向けのメディアを送信することができる。あるいは、グループ向けのメディアは、グループ通信のセッションとは独立に送信され得る。
【００２５】
図2は、PTTシステム中のセットグループメンバーのワイヤレス通信デバイス(デバイス70、72、74、76)間の通信を制御する一連のグループ通信コンピュータデバイス(グループ通信サーバ)32を有する、共通のセルラー遠隔通信構成におけるワイヤレスネットワークの一実施形態の代表的な図である。このワイヤレスネットワークは、例にすぎず、遠隔モジュールが、互いに、かつ/または、限定はされないが、ワイヤレスネットワークキャリアおよび/もしくはサーバを含むワイヤレスネットワーク20の構成要素との間で、無線で通信するのに使う任意のシステムを含み得る。一連のグループ通信サーバ32は、グループ通信サーバLAN 50に接続される。ワイヤレス電話は、データサービスオプションを使って、グループ通信サーバ32からのパケットデータセッションを要求することができる。
【００２６】
グループ通信サーバ32は、ここではキャリアネットワーク54上に常駐するように示されるパケットデータサービスノード(PDSN)52のような、ワイヤレスサービスプロバイダのPDSNに接続される。各PDSN52は、パケット制御機能(PCF)62によって基地局60の基地局コントローラ64とインターフェースをとることができる。PCF 62は通常、基地局60に位置する。キャリアネットワーク54は、メッセージングサービスコントローラ(「MSC」)58に(一般にデータパケットの形態で)送られるメッセージを制御する。キャリアネットワーク54は、ネットワーク、インターネットおよび/またはPOTS(「plain ordinary telephone system」)によって、MSC 58と通信する。一般に、キャリアネットワーク54とMSC 58との間のネットワーク接続またはインターネット接続はデータを転送し、POTSは音声情報を転送する。MSC 58は、1つまたは複数の基地局60に接続され得る。MSC 58は通常、キャリアネットワークと同様の方法で、データ転送のためのネットワークおよび/またはインターネットと、音声情報のためのPOTSの両方によって、branch-to-source (BTS)66に接続される。BTS 66は、最終的に、携帯電話70、72、74、76のようなワイヤレスデバイスに、かつワイヤレスデバイスから、ショートメッセージングサービス(「SMS」)によって、または当技術分野で知られている他の無線の方法によって、ワイヤレスでメッセージをブロードキャストし、受信する。キャリアの境界および/またはPTT管理者のネットワークの境界は、本明細書で説明されるようなデータの共有を、阻害または妨害するものではないことに留意されたい。
【００２７】
ワイヤレス電話14のような、携帯電話およびモバイル遠隔通信デバイスは、さらなるコンピューティング能力を伴って製造されており、パーソナルコンピュータおよびハンドヘルドPDAと同等になってきている。これらの「スマート」携帯電話によって、ソフトウェア開発者は、ワイヤレスデバイスのプロセッサ上でダウンロード可能かつ実行可能である、ソフトウェアアプリケーションを作成できるようになる。携帯電話14のようなワイヤレスデバイスは、ウェブページ、アプレット、MIDIレット、ゲームおよびデータのような、多くの種類のアプリケーションをダウンロードすることができる。グループ通信12(図1)を指定したワイヤレスデバイスにおいて、ワイヤレス通信デバイスは、グループ通信の他のメンバーと直接接続し、音声およびデータの通信に関与することができる。しかし、すべてのそのような直接の通信は、グループ通信コンピュータデバイス32を通じて、またはその制御下で行われる。デバイスのすべてのデータパケットは、必ずしもグループ通信コンピュータデバイス32自体を通じて転送されなくてもよいが、グループ通信コンピュータデバイス32は、最終的には通信を制御または方向付けできなければならない。それは、グループ通信コンピュータデバイス32が通常、通信グループのメンバーの識別情報を認識し、かつ/または取り出すことができ、または、通信グループ12のメンバーの識別情報を別のコンピュータデバイスに向けられる、唯一のサーバ側30のコンポーネントであるからである。
【００２８】
図3は、デバイスの対象セット、すなわち通信グループ12の他のメンバーへの直接通信を開放する、PTTボタン78を有する、携帯電話14であるワイヤレス遠隔通信デバイスの一実施形態を示すブロック図である。他の実施形態は、携帯電話上で通常利用可能なキーを使って、PTTボタン78と同様の機能を実行することができる。ワイヤレスデバイス14はまた、ワイヤレスデバイス14のユーザに対するグラフィクスディスプレイ80を有するものとして示される。ワイヤレスデバイス14はコンピュータプラットフォーム82を含み、コンピュータプラットフォーム82は、音声およびデータのパケットを扱うことができ、グループ向けのメディアを含めるために、ワイヤレスネットワーク20にわたって送信されるソフトウェアアプリケーションを受信して実行することができる。コンピュータプラットフォーム82は、コンポーネントの中でもとりわけ、特定用途向け集積回路(「ASIC」)84、もしくは他のプロセッサ、マイクロプロセッサ、論理回路、プログラマブルゲートアレイ、または他のデータ処理デバイスを含む。ASIC 84は通常、ワイヤレスデバイスの製造の時点で設置される。ASIC 84または他のプロセッサは通常、アプリケーションプログラミングインターフェース(「API」)層86を実行し、API層86は一般に、常駐するアプリケーション環境を含み、ASIC 84にロードされるオペレーティングシステムを含み得る。常駐するアプリケーション環境は、ワイヤレスデバイスのメモリ88の中の任意の常駐するプログラムとインターフェースをとる。常駐アプリケーション環境の例は、ワイヤレスデバイスプラットフォーム用にQUALCOMM(登録商標)によって開発された「binay runtime environment for wireless」(BREW(登録商標))ソフトウェアである。
【００２９】
ここで示されるように、ワイヤレスデバイスは、携帯電話14であってよいが、当技術分野において知られているように、携帯情報端末(PDA)、グラフィクスディスプレイ80を有するページャ、またはワイヤレス通信ポータルを有しそうでない場合にはネットワークもしくはインターネットへの有線接続を有し得る別個のコンピュータプラットフォーム82のような、コンピュータプラットフォーム82を有する任意のワイヤレスデバイスであってもよい。さらに、メモリ88は、読取り専用メモリまたはランダムアクセスメモリ(RAMおよびROM)、EPROM、EEPROM、フラッシュカード、またはコンピュータプラットフォームに共通の任意のメモリから構成され得る。コンピュータプラットフォーム82は、アクティブに使われていないソフトウェアアプリケーションをメモリ88に記憶するためのローカルデータベース90も含み得る。ローカルデータベース90は、一般に、1つまたは複数のフラッシュメモリセルから構成されるが、磁気メディア、EPROM、EEPROM、光メディア、テープ、またはソフトディスクもしくはハードディスクなど、当技術分野で知られている任意の二次または三次記憶デバイスであってよい。グラフィクスディスプレイ80は、進行中のグループの呼についての情報だけではなく、グループ向けのメディアについての情報も提示して、本明細書でより完全に説明されるようなファイルのプレビューを含めることができる。
【００３０】
ワイヤレスデバイスのこの実施形態では、コンピュータプラットフォーム82はまた、ワイヤレスデバイスからのグループ通信チャネル(通常は半二重)を開放することができる、直接通信インターフェース92を含む。直接通信インターフェース92は、ワイヤレスデバイスとの間で送信される音声およびデータを通常は搬送する、ワイヤレスデバイスのための標準通信インターフェースの一部であってもよい。直接通信インターフェース92は通常、当技術分野において知られているハードウェアから構成される。
【００３１】
図4は、PTT設備とグループ向けメディア設備とを有する、グループアプリケーションクライアントのソフトウェア層の一実施形態の図である。この実施形態では、モバイルデバイス環境中のコンピュータプラットフォーム82は、Mobile Station Modem (MSM)100およびAdvanced Mobile Subscriber Software (AMSS)102の上層のQUALCOMM(登録商標)によって開発された一連のソフトウェア「層」からなり、基礎となるMSMチップセットを駆動し、CDMA2000 1XおよびCDMA2000 1xEV-DOを含むCDMA通信技術一式全体のためのソフトウェアプロトコルスタックを実装する。やはりQUALCOMM(登録商標)によって開発されたBREW(登録商標)であってよい、または任意の他の利用可能なモバイルオペレーティングシステムであってよい、モバイルオペレーティングシステム層104が存在する。モバイルオペレーティングシステム層104は一般に、AMSS100およびコンピュータプラットフォーム上の任意のOEMソフトウェアへの直接の接触をなくす分離層を設けつつ、チップまたはデバイスに固有の操作のためのアプリケーションプログラミングインターフェースを提供する。モバイルオペレーティングシステム層104は、デバイスに固有のソフトウェアの新しいリリースが発表されるたびにアプリケーションを書き直す必要なく、モバイルデバイスの機能を使用するアプリケーション開発を可能にする。
【００３２】
PTTクライアント108は、ここではPTT認識UI 106において示される外部インターフェースを通じて、PTT認識サービスへのアクセスを提供するアプリケーションである。PTTクライアントは、グループメディアアプリケーション112のようなモバイルオペレーティングシステム104のアプリケーションを可能にするのに必要な、すべての機能を含む。PTTサービスへのアクセスをPTTクライアント108に与えるのに加えて、PTTクライアント108は好ましくは、すべてのPTT認識アプリケーションと、グループ通信コンピュータデバイス102へのインターフェースとの間の、分離層として動作する。この実施形態では、PTTクライアント108は、PTTサービスへのアクセスを保持し、グループ通信要求に応答し、PTTサービスに対するすべてのPTT認識モバイルオペレーティングシステムアプリケーションの要求を処理し、すべての外部へのPTT要求を処理し、PTT talk spurtを発信するためのボコーダパケットを収集してパッケージングし、終端したPTT talk spurtのボコーダデータのパケットを解析する。
【００３３】
図5を参照すると、示されているのは、例示的で非限定的なモバイル通信デバイス500と、そのデバイスのユーザインターフェースである。デバイスは通常、LCDディスプレイまたはOLEDディスプレイを含み得る、ディスプレイ505を含む。いくつかの実施形態では、ディスプレイは、タッチスクリーン機能を含み得る。デバイスは、標準的な電話のキーパッドであってよい、または他の実施形態ではQWERTYキーパッドであってよい、キーパッド515を含み得る。デバイスはまた、ディスプレイ505を操作するための、上、下、左、および右キーをさらに含み得る、ナビゲーションボタン510も含み得る。ナビゲーションキーはさらに、特定の機能のユーザの選択または確認応答を示すための、選択キーまたはOKキー550を含み得る。デバイスはまた、たとえば、ソフトキーの近くのディスプレイ505の領域に表示されるような、プログラム可能で機能の選択に使えるソフトキー507を含み得る。
【００３４】
図6は、ワイヤレス通信システムの利用可能なリソースに基づいた適応型の診断ロギングの、例示的な処理フローを示す。「利用可能なリソース」という用語は、本出願では「負荷」と交換可能に用いられる。この処理フローは、たとえば、図2のグループ通信サーバ32またはハンドセット70上で実施され得る。602において、イベントがロギングされるべきであると判定される。たとえば、グループ通信サーバまたはグループ通信サーバのグループ通信において障害が発生したと、グループ通信サーバが判定した結果として、イベントがロギングされるべきであると判定され得る。また、たとえばハンドセットによって、イベントがロギングされるべきであると判定されてもよい。たとえば、ハンドセットは、グループ通信サーバを登録する際にハンドセットに登録エラーがあったと判定したことに基づいて、イベントをロギングすることができる。また、ロギングが全般に進行中の活動である場合に、ワイヤレス通信システムの利用可能なリソースが変化したのでロギングの変更を考えるべきであるとも、判定され得る。したがって、「障害」という用語の使用は、利用可能なリソースの利用率が低下するすべての態様、または、やがてエラー状態につながり得る他の境界状況を包含することが意図される。たとえば、障害は、ワイヤレス通信システム内のグループ通信の異常な動作を含み得る(すなわち、許容される閾値を超える率で発生する、異常に終了したグループ通信)を含み得るが、障害は、ロギングを継続すると進行中の通信動作に対して影響を与え得るような、単なる利用可能なリソースの劣化、または、やがてエラー状態につながり得る他の境界状況であってもよい。
【００３５】
処理フローは、システムの負荷に基づいて、どの程度のロギングが、またはどのロギングが行われてよいかという一連の判定へと、602から進む。どの程度のロギングが行われてよいかという第1の判定は604で行われ、ロギングが行われてもよい最大の閾値(Tmax)を、負荷が超えたかどうかが判定される。最大の閾値(Tmaxとして示される)は、例として、単一の判定であってよく、モバイルデバイスのメモリの制限であってよい。または、閾値Tmaxは、たとえば、メモリ、CPU、およびネットワークの利用率などの、いくつかのリソース利用率の組合せから導出されてもよい。この閾値以上である場合、処理フローは動作612に移動し、そこではロギングが行われない。システムの負荷がTmax以上である場合に、ロギングによるシステムへのさらなる負荷がシステムを飽和させるので、ロギングは行われないということがあり得る。システムの負荷がTmax以上である場合に、ロギングによるシステムへの追加の負荷がシステムを飽和させることはないが、システムの活動が少しでも増加すると飽和に達する可能性があるほど、飽和に近くなるようなシステムへの負荷をもたらすので、ロギングが行われないということがあり得る。システムの負荷がTmax以上である場合に、ロギングによるシステムへの追加の負荷がシステムを飽和させることはないが、ネットワークへの負荷が増大して、ネットワークを使用する他者が、ネットワーク接続の際に不快さを経験し得るので、ロギングが行われないということもあり得る。
【００３６】
処理フローは、612から周期的に620aへ移り得る。620aにおいて、(異なるレベルのロギングが望まれるかどうかを判定するために)閾値に対する負荷を再評価するかどうかが、判定され得る。620aにおいて、負荷を再評価すべきではない場合(たとえば、関連するタイマーがまだ満了していない場合)、処理フローは612に戻る。620aにおいて、負荷を再評価すべきである場合、処理フローは604に戻る。
【００３７】
604において、負荷がTmaxより低いと判定されると、処理フローは606に移る。606において、負荷が閾値の数n-1 (T(n-1))以上であるかどうかが判定される(処理フローは604から来るので、負荷はTmaxよりも小さい)。負荷がT(n-1)以上である場合、処理フローは614に移る。614において、ロギングされるイベントの最小のセットがロギングされる(612では、イベントが全くロギングされないということに留意されたい)。たとえば、負荷を考慮しなければ、1から10まで順番に番号を付けられた10個のイベントをロギングするのが望ましい可能性がある。606で判定されたように、利用可能な負荷が少ない場合には、そうしたイベントのうちの2つ、たとえばイベント3およびイベント7をロギングするのに十分な負荷しかないという可能性があり、イベント3およびイベント7は所与の利用可能な負荷においてロギングが最も望まれ得るイベントである。
【００３８】
異なるイベントのロギングには、異なる量の負荷が必要であり得る。たとえば、呼設定メッセージングについてのすべての情報のロギングは、リアルタイムトランスポートプロトコル(RTP)パケットのロギングよりも多くの負荷を消費し得る。十分な負荷があるのに、ロギングが最も望まれる単一のイベントがロギングされないということもあり得る。たとえば、1つのイベントしかロギングできない場合、イベント2をロギングするのが最も望ましいことがある。しかし、利用可能な負荷があれば、イベント2よりもイベント3およびイベント7をロギングするのが最も望ましくなり得る。それは、そのような組合せが、イベント2の単独のログよりも、組み合わせるとより有用であり得るからである。
【００３９】
614において、イベントのこの最小のセットがロギングされる。したがって、上の例では、この決定の時点では、イベント2のみがロギングされる可能性が最も高い。さらに、処理フローが周期的に612から620aへ移るように、処理フローは周期的に614から620bへ移ってよく、620bにおいて、負荷を再評価するかどうかが判定される。負荷を再評価すべきである場合、処理フローは604に戻る。負荷を再評価すべきではない場合、処理フローは614に戻る。あるいは、614から620bに周期的に変化する代わりに、一実施形態では、ロギングモジュールがリアルタイムのネットワーク状態に基づいて適切な変更を行えるように、負荷状態がいつ変化したかを負荷モジュールがロギングモジュールに通知したことに基づいて、処理をリアルタイムで更新することができる。
【００４０】
606において、負荷がT(n-1)より低いと判定されると、処理フローは608に移る。606と608の間の点線によって示されるように、より多数の閾値を使って負荷と比較してもよく、実装すべきロギングの詳細度を高くすることが可能になる。他の実施形態では、3個(たとえば、多数のイベントをロギングする、少数のイベントをロギングする、ロギングしない)のようなより少数の閾値を使ってもよい。
【００４１】
608において、負荷が第1の閾値(T1)を超えているかどうかが判定される(処理フローは606から来るので、負荷がT(n-1)より低いことは既知である)。負荷がT1以上である場合、処理フローは616に移る。616において、ロギングに利用可能なロードの量がより多いことを理由に、614の場合よりもより大きいイベントのセットがロギングされる。614の「最小のセット」に対する、ここで使われるような「より大きいセット」は、より多数のイベントがロギングされることを必ずしも意味しない。たとえば、一実施形態では、負荷が、少なくともイベント2のログを許容できるが(上記の例のように)、望ましいイベント3および7の組合せは依然として許容できないということがあり得る。しかし、このことで、イベント2のログから、より詳細なロギング情報を得られるようになる可能性がある。加えて、このことは、616でロギングされるイベントのセットが、614でロギングされるイベントのセットよりも大きい負荷を引き起こすという事実を、単に指すものであり得る。
【００４２】
処理フローが612から620cへ周期的に移るように、処理フローは616から620cへ周期的に移る。620cにおいて、負荷が再評価されないと判定される場合、処理フローは616に戻る。620cにおいて、負荷が再評価されると判定される場合、処理フローは604に戻る。
【００４３】
608において、負荷がT1より低いと判定されると、処理フローは610に移る。処理フローが610に移ると、システムイベントのロギングの量および種類に影響を与える最小の負荷の閾値であるT1よりも、負荷が小さいことが知られている。したがって、処理フローは、イベントの完全なまたは最大のセットがロギングされる、618に移る。「より小さいセット」に対する「より大きいセット」の議論におけるように、「最大のセット」は、必ずしも、ロギングされるイベントの数を単純に指すものではないが、たとえば、このより最大セットのすべてのイベントのロギングの、組み合わされた負荷を指し得る。
【００４４】
処理フローが612から620cへ周期的に移るように、処理フローは618から620dへ周期的に移る。620dにおいて、負荷が再評価されないと判定される場合、処理フローは618に戻る。620dにおいて、負荷が再評価されると判定される場合、処理フローは604に戻る。
【００４５】
図6に示されるロギング判定のレベルは4個(またはN個)であるが(604、606、608、および610)、4個よりも多数または少数のレベルが、これらの教示に従って実施形態において実装され得ることが、理解され得る。また、負荷の量を求めるための図示される処理は、様々な方式で(たとえば、負荷が第1の閾値よりも低いかどうかの第1の判定、第1の閾値よりも低くなければ、閾値の数n-1よりも低いかどうかの判定、閾値の数n-1よりも低くなければ、閾値の数n以上であるかどうかの判定のように)実施され得る。
【００４６】
以下では、図6の負荷に基づく適応型のロギングの技法を実施できる、3つの状況を例示する。第1の状況は、呼の負荷と、第2にCPUの負荷と、第3に利用可能な記憶空間(「ディスク負荷」)とに関わる。これらの負荷の組合せに関わる状況も、図6の技法から利益を得られることが、理解され得る。そのような組合せの状況は、たとえば、利用可能なシステムリソースが、呼の負荷とCPUの負荷の両方に基づいて制限される状況に関わり得る。
【００４７】
第1の状況は、適応型のロギングが呼の負荷(アクティブな呼の数)に基づいて行われる、断続的な呼の品質問題の調査に関わる。すべての所望のイベントのロギングに利用可能な負荷が存在する、オフピーク時間の間、グループ通信サーバ32は、すべての呼についての完全な情報(たとえば、呼設定メッセージング、発言権制御メッセージング、メディアなど)を収集する。ピーク時間(通常の業務時間のような)に入るに従って、適応型のロギング技法は、ある状態になると収集されるデータの量を減らす。ピーク時間は、アクティブな呼の数がより多いことに対応し、ある点において、アクティブな呼の第1の閾値に達する。この第1の閾値に達したことに応答して、グループ通信サーバ32は、メディアパケットの収集を停止して、すべてのリアルタイムトランスポートプロトコル(RTP)パケットを収集する代わりに、RTPパケットを10個に1個収集する。負荷が大きくなると、第2の閾値に達する。第2の閾値に達したことに応答して、グループ通信サーバ32は、発言権制御メッセージおよびメディアの収集を完全に停止し、10個に1個の呼のみのための、呼設定情報を収集する。第3の閾値に達するところまで負荷が大きくなると、グループ通信サーバ32はイベントのロギングを完全に停止する。
【００４８】
ピーク時間が終わると(たとえば、平日の終わりにおいて)、負荷は低下し始めて、3つの閾値よりも低くなり得る。負荷が閾値よりも低くなったことに応答して、グループ通信サーバ32は、無効にされたのと逆の順序で、ロギングを再び有効にすることができる。負荷が第3の閾値よりも低くなると、グループ通信サーバ32は、10個に1個の個の呼設定情報の収集を再開する。負荷が低下を続けると、負荷は第2の閾値よりも低くなり、それに応答して、グループ通信サーバ32は、すべての呼設定メッセージ、発言権制御メッセージおよびメディアを含む、すべての呼のデータの収集を再開する。負荷が低下し続けると、負荷は第1の閾値よりも低くなり、それに応答して、グループ通信サーバ32は、すべての呼の完全な情報のロギングを再開する。
【００４９】
この第1の状況では、アクティブな呼の負荷の上昇として受け取られる情報は、少なくなるが、システム性能が低下し得る原因についての詳細情報を依然として提供する。たとえば、閾値に達した後にロギングされた情報から、特定の領域のハンドセットが呼の品質の問題に継続的に直面していること、または、単一のメディアチャネル(MCH)が、決定された呼の品質の問題のすべてに関わっていることが、判定され得る。
【００５０】
第2の状況は、グループ通信サーバ32のCPUの負荷またはグループ通信サーバ32のサブコンポーネントに基づく、適応型のロギングに関わる。この第2の状況では、グループ通信サーバ32と通信可能に接続された、キャリアのプロビジョニングデータベース(ハンドセットのどの特性が現在のネットワーク上で利用され得るかを示すデータベース)から、クライアント登録の一部としてクライアント情報を取り出す、偽のデータエラーに関する問題がある。最初は、問題が、サーバ処理の問題であるか、準備されたデータの問題であるか、キャリアのプロビジョニングデータベースにおけるエラーの問題であるか、または伝送中に破損したデータの問題であるかを、判定できない。
【００５１】
この問題を最初に分析するために、制御され得るすべてのイベント、すなわち、キャリアのプロビジョニングデータベースとの間で送受信されるデータ、登録に関与するサーバコンポーネントとの間で送受信されるデータ、グループ通信サーバ32のサブコンポーネントの高レベルの処理の詳細情報(たとえば、登録ステートマシン、異なるグループ通信サーバ32のサブコンポーネントにおける成功または失敗の状態)、および、グループ通信サーバ32のサブコンポーネントの低レベルの処理の詳細情報(たとえば、機能の開始または終了、および論理比較)の、ロギングを可能にするための、利用可能なCPU負荷が存在し得る。
【００５２】
この最初のロギングは、クライアント登録に関与するすべてのサブコンポーネントによって実行される。CPU負荷(または利用率)がすべての閾値よりも低い間は、グループ通信サーバ32のサブコンポーネントは、上記のイベントのすべてをロギングする。しかし、たとえば、発呼者識別情報(CID、発呼者ID)サブコンポーネントが、クライアント登録と呼設定の両方に関与するので、呼設定の負荷が大きいと、登録に関与する他のサブコンポーネントが低いCPUレベルにとどまっていても、CIDサブコンポーネントのCPU利用率が上がることがある。CIDサブコンポーネントのCPU負荷が、第1の閾値以上に上がると、CIDサブコンポーネントは、登録のための低レベルの処理イベントのロギングを停止するが、送信または受信される登録関連のメッセージのロギングとともに、高レベルの処理イベント(たとえば、CIDサブコンポーネントのキャッシュへの追加またはキャッシュからの削除に成功したクライアント)のロギングを続ける。グループ通信サーバ32の他のサブコンポーネントは、CIDサブコンポーネントの第1の閾値に達する前と同じ程度多くのイベントのロギングを続ける。それは、他のサブコンポーネントは、それらのそれぞれの閾値よりも低いからである。しかし、ワイヤレス通信システムの利用可能なリソースの変化の種類、ならびに遭遇し得るエラーの種類によっては、害を与える可能性のあるサブコンポーネントがより高いレベルでロギングできるように、ロギングのために他のサブコンポーネントが使うリソースを減らすと、決定することができる。さらに、重要な情報を獲得する機会がより多いロギングモジュールが、より詳細にロギングできるように、他のモジュールを本システムで利用してロギングの負荷を緩和することができる。
【００５３】
第1の状況に関して論じられたのと同様に、CIDサブコンポーネントのCPU負荷が上昇すると、さらなる閾値に到達し、イベントのロギングが段階的に少なくなる。CIDサブコンポーネントのCPU負荷が低下すると、負荷は前に到達した閾値よりも低くなり、イベントの多くのロギングが段階的に再開する(または、CPU負荷がすでに少なくとも第1の閾値を上回っていた時点でロギングが開始した場合には、ロギングが初めて行われる)。
【００５４】
複数のサブコンポーネントにおいてデータをロギングすることによって、問題の源をより簡単に特定することができ、問題の源は、エラーが発生した時点での適切なイベントのロギングであり、または複数のエラーが同じ性質で発生した場合には、この源は、エラーが発生した時点での適切なイベントのロギングである。大きな欠陥のあるサブコンポーネント(たとえば、不正確な情報を報告したサブコンポーネント)、または、適応型のロギングが非常に少ない、またはロギングが全く行われないかのいずれかであるほど、負荷が大きいサブコンポーネントの場合、そのサブコンポーネントが負荷を引き起こした結果(すなわち、その特定のサブコンポーネントのログがないこと)として、問題を判定することができる。そのサブコンポーネントの結果として、問題が判定される場合、そのサブコンポーネントとの間で、イベントをロギングしている他のサブコンポーネントによって送受信される情報から、その問題への何らかの見識が収集され得る。
【００５５】
第3の状況は、ロギングの結果の記憶に使う記憶空間(たとえば、ハードディスク、または他の記憶媒体によって提供される)の利用可能性に基づく、適応型のロギングに関わる。この状況では、ワイヤレス通信ネットワークのキャリア課金システムが課金情報を取り出せるようになるまで、課金情報の記憶を担うグループ通信サーバ32のサブコンポーネントである、中央記憶課金ユニット(CSBU)において、情報を収集することが望まれる。前の2つの状況では、実施され得る複数のレベルのロギングが存在する。この状況では、CSBUがロギングするイベントの量は、利用可能な記憶空間に基づいて変動する。利用可能な記憶空間が第1の閾値まで下がると(たとえば、ハードディスクの全体の記憶空間の50%)、ロギングされるものの詳細情報が減らされる。利用可能な記憶空間が第2の閾値まで下がると(たとえば、ハードディスクの全体の記憶空間の40%)、ロギングされるものの詳細情報がさらに減らされる。利用可能な記憶空間が第3の閾値まで下がると(たとえば、ハードディスクの全体の記憶空間の25%)、ロギングが停止される。課金記録が次いでキャリア課金システムに送信され、記憶デバイスから削除され、空間を空けると(たとえば、ハードディスクの全体の記憶空間の80%まで)、CSBUは、第1の閾値に達するまでロギングを続けることができる。この適応型のロギングは、CSBUについての問題を診断する際に価値のある情報を提供するが、ログ収集よりも、売上を生成する課金活動を優先する。
【００５６】
図7は、イベントをロギングする能力の変化に基づく、適応型の診断ロギングの例示的な動作手順を示す。イベントをロギングする能力のこの変化は、たとえば、グループ通信サーバ32がサブコンポーネントと通信できない場合、または、負荷(たとえばアクティブな呼の負荷、またはCPU負荷)が高すぎるために、ロギングが望ましいすべてのイベントをサブコンポーネントがロギングできない場合に、起こり得る。
【００５７】
動作702は、グループ通信サーバのグループ通信で「障害」が発生したと判定することを示す。ある例として、この場合、グループ通信のハンドセットが、ベーストランシーバ基地局(BTS)への通信の範囲内にあるので本来はグループ通信に参加できるべきであるのに、参加できないということのような、グループ通信の異常な動作を、障害は含み得る。この異常な動作が発生していると判定される時、たとえば、グループ通信のハンドセットが、グループ通信サーバ32によってANNOUNCEパケットを送信されたことに応答して、グループ通信サーバ32へACKパケットを送るのに失敗した時に、障害が発生したと判定することができる。また、たとえば、BTSが、許容される閾値を超える数の呼を失敗した時に、障害が発生したと判定することもできる。
【００５８】
動作704は、障害に基づいて、複数のイベントをロギングすると判定することを示す。障害が発生したと判定したことに応答して、障害の性質の分析に使うデータを収集し、問題を解決するための方法を見つけるために、1つまたは複数のイベントのロギングが開始され得る。障害に応答してロギングされるべきイベントは、障害自体に合わせて調整され得る。たとえば、障害がタイプAである場合、ロギングされるべきイベントは、イベントW、X、Y、およびZであり得るが、障害がタイプBである場合、ロギングされるべきイベントは、イベントS、T、U、X、およびZであり得る。この所定の複数のイベントは、特定の種類の障害に応答して一緒にロギングされるイベントのセットである、ロギングテンプレートとして考えることができる。
【００５９】
ロギングテンプレートによって示されるイベントは、それをロギングすると障害の源が特定される可能性が高いと判断される、イベントとして選択され得る。たとえば、障害が、グループ通信の確立の失敗の障害である場合、ロギングされるイベントは、すべての呼設定メッセージングを含み得る。
【００６０】
ある実施形態では、複数のイベントのロギングの決定は、負荷の閾値に基づく。たとえば、複数のイベントが、コンポーネントの負荷が閾値を超えるかどうかに(たとえば604)基づいて選択され得る。ロギングに利用可能な負荷が比較的少ないことを示す閾値を、コンポーネントの負荷が超える場合、そのようなことを示すそのような閾値をコンポーネントの負荷が超えない場合よりも、少数のイベントのセット(またはより少ない負荷を消費するセット)をロギングすると決定することができる。
【００６１】
動作706は、複数のイベントのうちの第1のイベントがロギングできないと判定されたことに基づいて、第2のイベントをロギングすることを示す。第1のイベントが、ハンドセット70のようなグループ通信のハンドセットの信号強度であり、その信号強度を特定するための要求にハンドセットが応答していないということが、あり得る。また、問題のコンポーネントが、(第1の特定のイベントのロギングに関連する追加の負荷によって、コンポーネントの最大の負荷を超えるので)第1のイベントをロギングするための十分な負荷を欠いているということもあり得る。たとえば、グループ通信サーバは、第1のイベント、すなわちすべての呼の完全な情報(呼設定メッセージング、発言権制御メッセージング、およびメディア)のロギングに十分な記憶空間を有さないことがあるので、代わりに、ロギングのための記憶空間をグループ通信サーバが有する第2のイベント、たとえば呼設定メッセージングのみを、ロギングすることができる。第2のイベントは、ここで使われた例である、第1のイベントのサブセット以外であってもよいことに、留意されたい。
【００６２】
動作708は、第2のイベントのロギングを開始した後で、第1のイベントをロギングできると判定することを示す。動作706に関して論じられた例を使って、グループ通信サーバは、第1のイベント(すべての呼の完全な情報)のロギングに十分な記憶空間を今では有すると、判定することができる。
【００６３】
動作710は、第1のイベントのロギングを示す。上では、最初は第1のイベントのロギングが望まれたが、ある理由によって、第1のイベントをロギングできず、代わりに第2のイベントがロギングされた。今回は、ロギングの間に時間が経過し、第1のイベントのロギングが今では可能であると判定され、動作710において、第1のイベントがロギングされる(たとえば、620a参照)。このことは、第2のイベントのロギングを停止すること(たとえば、第1のイベントと第2のイベントの両方をロギングするのに十分な利用可能な負荷はないが、第1のイベントまたは第2のイベントのいずれかをロギングするのに十分な利用可能な負荷はある場合)、第2のイベントの一部をロギングすること、または第2のイベントのロギングを続けることを含み得る。
【００６４】
動作712は、ロギングの結果をメモリに記憶することを示す。ロギングの結果は、イベントをロギングするコンポーネントの記憶媒体に記憶され得る。たとえば、複数のハンドセットが各々信号強度をロギングする場合、信号強度は、各ハンドセットのメモリに記憶され得る。信号強度はまた、集中型の記憶媒体に記憶されてもよい。この複数のハンドセットの例を使って、各ハンドセットは、その信号強度の指標をグループ通信サーバに送信することができ、各指標は、グループ通信サーバの記憶媒体に記憶される。
【００６５】
動作714は、ロギングの停止を決定し、複数のイベントのロギングを停止することを示す。ロギングを停止するこの決定は、障害がメディアの転送に関する問題に関わっていた場合の、グループ通信におけるメディアの転送のような、特定のイベントをロギングすると起こり得る。
【００６６】
ロギングを停止するこの決定は、タイマーが満了すると行われもよい。たとえば、ロギングを開始する時に5分のタイマーを初期化して始動することができ、5分後、すなわちそのタイマーが満了すると、ロギングを停止することができる。
【００６７】
ロギングを停止するこの決定は、負荷の閾値に到達したことに基づいて行われてもよい。たとえば、呼接続の問題は、アクティブな呼の負荷が閾値を超えている時、または、コンポーネントの別の(たとえばCPUの)負荷が別の閾値を超えている時にも、起こり得る。負荷がこの負荷閾値よりも低くなると、ロギングを停止すると決定することができる。
【００６８】
ロギングを停止するこの決定は、ロギングの停止をユーザが望んでいるという指示を受信したことに基づいて、行われてもよい。このことは、ロギングの手動の終了に対応する、現在のシステムとのユーザ対話を示す信号を受信することを含み得る。
【００６９】
図8は、グループ通信の適応型の診断ロギングの、例示的な呼の流れ図を示す。グループ通信サーバ808と通信している、3つのハンドセット802、804、および806がある。ハンドセット802、804、および806の各々は、たとえば、図1のハンドセット70を含み得る。グループ通信サーバ808は、たとえば、図1のグループ通信サーバ32を含み得る。
【００７０】
ハンドセット802は、ハンドセット804および806とのグループ通信の開始を試みる。ハンドセット802は、CALLメッセージをグループ通信サーバ808に送信することによってこれを完遂しようと試み、CALLメッセージは、ハンドセット804および806がこのグループ通信に参加することになることを示す。CALLメッセージを受信したことに応答して、グループ通信サーバ808は、別個のANNOUNCEメッセージを、ハンドセット804およびハンドセット806に送る。ANNOUNCEメッセージがハンドセット804に送られたことに応答して、グループ通信サーバ808は、ACK(確認応答)メッセージをハンドセット804から受信する。しかし、ANNOUNCEメッセージがハンドセット806に送られたことに応答して、グループ通信サーバ808は、ACK REJECTメッセージをハンドセット806から受信する。ハンドセット806は呼を拒否したが、ハンドセット804は呼を受け入れたので、グループの呼の部分的な失敗を含む障害が生じる。
【００７１】
グループの呼の部分的な失敗が、ハンドセット802と、804と、806との間のグループ通信に発生したと判定したことに応答して、グループ通信サーバ808はロギングを開始し得る。ある実施形態では、このロギングは、部分的な呼の失敗を被っているこのグループ通信のハンドセットとの間で送受信される、すべてのメッセージの完全な詳細情報をロギングすることを含み得る。ロギングされるものは、ロギングすべきイベントのテンプレートによって決定され得る。グループ通信サーバ808は、異なる種類の障害に対応する、複数のテンプレートを記憶していてよい。この実施形態では、障害は部分的な呼の失敗であると、グループ通信サーバ808が判定した場合、グループ通信サーバ808は、その複数のテンプレートから、部分的な呼の失敗に対応するテンプレートを選択することができる。ロギングされることになるイベントの利用可能性(たとえば、特定のハンドセットがその信号強度についての情報を現在送信できるかどうか)、または、ロギングに利用可能なリソースの量(たとえば、グループ通信サーバ808が、テンプレートのイベントをロギングするのに十分なリソースを有するかどうか、または、テンプレートのイベントをロギングすることでグループ通信サーバ808が最大の負荷の閾値を超えるかどうか)に基づいて区別される、単一の障害の種類に対応する複数のテンプレートがさらに存在し得る。単一の障害イベントに対応するこれらの複数のテンプレートがある実施形態では、複数のテンプレートのうちのあるテンプレートが、システムの現在の状態に基づいて選択され得る。
【００７２】
ロギングが、部分的な呼の失敗を被っているこのグループ通信のハンドセットとの間で送受信される、すべてのメッセージの完全な詳細情報をロギングすることを含むある実施形態では、グループ通信サーバ808が、これらのイベントをロギングする(ある実施形態では、これらのイベントのいくつかは、ハンドセット802のようなグループ通信の他のコンポーネント上でロギングされ得る)。グループ通信サーバ808は次いで、STATUSメッセージをハンドセット806に送信し、ハンドセット806からSTATUSメッセージを受信して、ネットワーク状態を知る。ここで、GCS 808は、限られたネットワーク状態しか知らないので、障害イベント1に、すなわちグループの呼の部分的な失敗に関連する情報の限られたロギングを開始する。ある実施形態では、グループ通信サーバ808は、ハンドセット806にSTATUSメッセージを送信した後も、ロギングを続ける。ある実施形態では、グループ通信サーバ808はまた、たとえばハンドセット802向けのデータのような、さらなるシステムデータを得るためにロギングを開始する前に、ハンドセット802へSTATUSメッセージを送信することができる。ある実施形態では、グループ通信サーバ808は、たとえば、より多数の部分的な呼の失敗(よって障害の種類についてのできるだけ多くの情報)がロギングされるまで、負荷の閾値に達するまで、または、ユーザがロギングの中断を望んでいるという指示を受信するまで、ロギングすることによって、1つの部分的な呼の失敗を記録した後であっても、これらのイベントのロギングを続けることができる。
【００７３】
そして、第2のグループの呼がハンドセット802から発生し、ACK rejectがハンドセット804から受信される。したがって、GCS 808は障害イベント2およびグループの呼の部分的な失敗を経験し、ハンドセット804に状態を尋ねる。ハンドセット804の状態についてのデータが受信されると、GCS 808は、改善されたシステム状態を知り、障害イベント1のロギングに利用可能なリソースを増やし、障害イベント2に対するデータのロギングを開始する。
【００７４】
そして、第3のグループの呼がハンドセット802から発生し、ACK rejectがハンドセット804および806から受信される。したがって、GCS 808は障害イベント3および完全なグループの呼の失敗を経験し、障害イベント3のロギングを開始する。しかし、第4の呼がハンドセット802から送信され、ACK rejectのみがハンドセット806から受信される。GCS 808は、障害イベント1のロギングを続け、次いで、終了した障害イベント2および3のログを作成し、そうしたイベントに対するデータを記憶する。その後、GCS 808は、ハンドセット808の状態を再び確認し、ネットワーク状態および/またはハンドセット806についてのデータを知ることができる。
【００７５】
図9は、グループ通信サーバが、グループ通信の適応型の診断ロギングを行う、例示的なワイヤレス通信システムを示す。グループ通信サーバ932は、図2のグループ通信サーバ32を含み得る。ハンドセット970、972、および974は、図2のハンドセット70、72、74、または76の1つを含み得る。BTS 966aおよび966bは、図2のBTS 66を含み得る。グループ通信サーバ932、ならびにBTS 966aおよび966bは、通信ネットワーク902を介して互いに通信することができる。
【００７６】
ハンドセット970、972、および974は、グループ通信で通信を試みることができる。このグループ通信の試みの過程で、図8に示される障害のような障害が判定され得る。障害が発生したとグループ通信サーバ932が判定すると、グループ通信サーバ932は適応型のロギングを開始することができる。
【００７７】
グループ通信サーバ932は、ハンドセット970から受信されたCALLメッセージの詳細情報のような、グループ通信サーバ932のところで判定され得るイベントを、それ自体でロギングすることができる。グループ通信サーバ932はまた、ワイヤレス通信システムの他のコンポーネントに指示を送り、局所的なロギングを実行することができる。たとえば、グループ通信サーバ932は、信号強度のロギングを開始し、そのロギングの結果をハンドセット970のメモリにローカルに記憶するように、ハンドセット970に指示することができる。ハンドセット970は、次いで、ハンドセット970上で発生したロギングの結果を、グループ通信サーバ932に送信することができる。別の実施形態では、ハンドセット970は、イベントがロギングされるに従って、ロギングの結果をグループ通信サーバ932に送信することができる。グループ通信サーバ932は最終的に、ロギングの結果のすべてを収集し、ロギングは、グループ通信サーバ932または別のコンポーネントで実行される。そして、ロギングの結果が、グループ通信サーバ932から取り出され、技術者によって分析されて、障害の源と、障害を修復するための適切な改善動作とを判定することができる。
【００７８】
「間接的な」ロギングが実行され得る例は、ボコーダに関わる。ボコーダは、それ自体ではロギングを直接実行できないことがあり得る。それは、ロギングを直接実行すると、負荷が大きくなりすぎ、たとえば、大きくなった負荷によって、符号化すべき音声データの列がオーバーフローし得るからである。ボコーダ上でボコーダによって実行される直接のロギングではなく、ボコーダの間接的なロギングが行われ得る。この間接的なロギングは、ボコーダから送信されるパケットのロギングを含み得る。
【００７９】
ワイヤレス通信システムのコンポーネントのロギングは、そうしたコンポーネントが所与の時間において互いに通信できない場合でも、行われ得る。たとえば、図9に示されるシステムでは、ハンドセット970とハンドセット972の両方が、たとえば、グループ通信サーバ932と通信できないことのような、BTS 966aと通信している時と同様の障害を被ることがある。各ハンドセットは、障害と関連する可能性のあるイベントの適応型のロギングを、独立に開始することができる。その後、ハンドセット970および972は物理的に移動することがあるので、ハンドセット970および972はBTS 966bと通信するようになり、BTS 966bを通じてグループ通信サーバ932と通信できるようになる。この時点では、障害はもはや発生していないので、ハンドセットはロギングを停止し(タイマーの満了などによって、ハンドセットがそれより前にロギングを停止していなければ)、グループ通信サーバ932にロギングの結果をアップロードすることができ、グループ通信サーバ932において、ログを分析して障害の理由を判定する技術者が取り出せるように、ログを収集することができる。
【００８０】
本開示は、好適な態様に関連して説明されてきたが、様々な図面に示されるように、本開示から逸脱することなく、他の同様の態様が使われてよく、または、本開示と同じ機能を実行するために、説明された態様に対する修正および追加を行えることを、理解されたい。したがって、本開示は、単一の態様に何ら限定されるべきではなく、むしろ、添付の特許請求の範囲に従った広さおよび範囲で解釈されるべきである。たとえば、本明細書で説明される様々な手順は、ハードウェアもしくはソフトウェア、または、それら両方の組合せで実施され得る。したがって、開示される実施形態の方法および装置、または、その何らかの態様もしくは部分は、フレキシブルディスケット、CD-ROM、ハードドライブ、または任意の他の機械可読記憶媒体のような、有形の媒体において具現化されるプログラムコード(すなわち命令)の形態であってよい。プログラムコードが、コンピュータのような機械にロードされ、機械によって実行されると、その機械は、開示される実施形態を実行するために構成される装置になる。本明細書で明示的に述べられた具体的な実装形態に加えて、他の態様および実装形態が、開示された本明細書を考慮すれば、当業者には明らかになるであろう。本明細書および例示された実装形態は、単なる例として考えられることが、意図されている。
【符号の説明】
【００８１】
12  プッシュツートークグループ
14  ワイヤレス遠隔通信デバイス
20  ワイヤレス通信ネットワーク
30  サーバ側LAN
32  サーバ
34  データベース
36  データ記憶装置
50  グループ通信サーバLAN
52  パケットデータサービスノード
54  キャリアネットワーク
60  基地局
70  ワイヤレス通信デバイス
80  グラフィカルディスプレイ
82  コンピュータプラットフォーム
100  MSM
102  AMSS
104  モバイルオペレーティングシステム層
106  PTT認識UI
108  PTT認識クライアント
112  グループメディアアプリケーション
【図５】
0005620583.tif 000002
【図１】
0005620583.tif 000003
【図２】
0005620583.tif 000004
【図３】
0005620583.tif 000005
【図４】
0005620583.tif 000006
【図６】
0005620583.tif 000007
【図７】
0005620583.tif 000008
【図８】
0005620583.tif 000009
【図９】
0005620583.tif 000010