(57)【要約】本実施形態は、ローカル無線デバイス（１２２）の無線リンク（１１２）に障害が発生する場合にリモート通信デバイス（１２４／１２６）に通知を行なう。一の方法では、無線接続（１１２）に障害が発生する時点を第１通信デバイス（１２２）によって検出し、第１デバイスと通信している第２通信デバイス（１２４／１２６）を特定し、そして第２デバイスにリンク障害を通知する。リンク障害に関する通知は、本方法がバッチ接続を行なっている間に送信される。ローカルデバイスの無線接続に障害が発生する場合にリモートデバイスに対する通知が行なわれる音声通信を提供することができる。第２デバイスは、サーバ（１５０）にクエリーを出すことによって求めることができる。通知する操作では、帯域内トーンを転送し、そして／またはリアルタイムプロトコルパケットを生成することができる。リンク障害は無線接続ネットワーク（１３４）、パケット制御機能（１３２）、及び／又はモバイルスイッチングセンター（ＭＳＣ）を通して検出される。
2008508795.tif 000002
【特許請求の範囲】
【請求項１】
無線通信を提供するために使用される方法であって、
第１通信デバイスとの無線通信接続を提供する無線リンクの障害を検出すること、
第１通信デバイスの通信先であった第２通信デバイスを決定すること、
第２通信デバイスに無線リンク障害を通知すること、
を備える方法。
【請求項２】
請求項１に記載の方法であって、更に、
バッチ接続を第１通信デバイスと第２通信デバイスとの間に確立すること、
を備える方法。
【請求項３】
請求項１に記載の方法であって、更に、
障害発生無線リンクが意図的に切断されたかどうかを判断すること、
障害発生無線リンクが意図的に切断された場合に、第２通信デバイスへの通知を行なわないこと、
を備える方法。
【請求項４】
請求項１に記載の方法であって、更に、
音声通信を第１通信デバイスと第２通信デバイスとの間に確立すること、
を備える方法。
【請求項５】
ユーザに無線接続に障害が発生していることを通知するために使用される方法であって、
通信接続を第１通信デバイスと第２通信デバイスとの間に通信ネットワークを通して確立して、第１通信デバイスが第２通信デバイスと少なくとも第１無線リンクを通して無線通信するようにすること、
第１通信デバイスとの第１無線リンクに障害が発生していることを検出すること、
第２通信デバイスに、第１通信デバイスとの接続に障害が発生していることを通知すること、
を備える方法。
【請求項６】
請求項５に記載の方法において、前記検出することは、無線リンクに障害が発生していることをパケット制御機能（ＰＣＦ）を使用して検出することを含み、
前記通知することは、通知をＰＣＦによって生成し、該通知を第２通信デバイスとの接続を経由する通信に載せることを含む、方法。
【請求項７】
請求項６に記載の方法であって、更に、
ＰＣＦがサーバに第１通信デバイスとの無線リンクに障害が検出されたことを通知すること、
第２通信デバイスの識別情報をサーバから受信して、ＰＣＦが通知を第２通信デバイスに正確に転送するようにすること、
を備える方法。
【請求項８】
無線通信を提供するために使用されるシステムであって、
第１通信デバイスと無線リンクを通して無線通信する基地局と、
基地局に接続される無線接続ネットワーク（ＲＡＮ）と、
第１通信デバイスに少なくともＲＡＮを通して通信接続される第２通信デバイスと、
を備え、ＲＡＮは無線リンクに障害が発生していることを検出し、通知を生成し、該通知を第２通信デバイスに転送して、第２通信デバイスに無線リンクに障害が発生していることを通知する、システム。
【請求項９】
請求項８に記載のシステムであって、更に、
ＲＡＮに接続され、更に分散ネットワークにも接続されて、第２通信デバイスが第１通信デバイスに少なくともＲＡＮ、ＰＤＳＮ、及び分散ネットワークを通して通信接続されるようになるパケットデータ提供ノード（ＰＤＳＮ）、を備えるシステム。
【請求項１０】
請求項８に記載のシステムであって、更に、
ＲＡＮに通信接続されるサーバ、
を備え、ＲＡＮはサーバにクエリーを出して、通知を転送する前に第２通信デバイスを特定する、システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は概して移動体通信システムに関し、特に無線接続障害をモニタリングする移動体通信システムに関する。
【背景技術】
【０００２】
無線通信の利用は爆発的に増えている。その結果、個人が無線通信に費やす時間も劇的に長くなっている。従って、当事者間の接続障害に関連するコストが一層膨らんでいる。
無線通信を使用する当事者は無線接続障害にあう場合がある。通信に参加している他方の当事者は多くの場合、少なくとも一時的に接続障害に気が付かない。その結果、多くの場合、相当長い時間をユーザが無駄に費やして応答を待つ、そして／または通信の別の当事者が接続障害に会っているかどうかを知ろうとする。これらのユーザは多くの場合、通信の別の当事者が接続障害に会っていても通話し続ける、または情報を送信し続ける恐れがある。
【発明の開示】
【発明が解決しようとする課題】
【０００３】
この無駄に使用される時間はユーザにとって非常に不愉快であり、かつユーザに与える印象を非常に悪くするように作用してしまう。
【課題を解決するための手段】
【０００４】
上述の要求は、無線接続障害に関連するコストを低減するために使用される方法、装置、及び／又はシステムを提供することにより、少なくとも部分的に満たされ、この方法、装置、及び／又はシステムについては、以下の詳細な説明の中に、特に図に関連付けながら分析される形で記載される。
【０００５】
該当する参照記号は該当する構成要素をこれらの図の幾つかの図の全体を通じて指している。当業者であれば、これらの図の構成要素が説明を簡単かつ明瞭にするために示され、そして必ずしも寸法通りには描かれていないことが分かるであろう。例えば、これらの図における幾つかの構成要素の寸法を他の構成要素に対して誇張して描いて本発明の種々の実施形態を理解し易くしている。また、商業的に実現可能な実施形態に有用な、または必要な一般的、かつ公知の構成要素は、本発明のこれらの種々の実施形態を描いた図の邪魔にならず、これらの図を分かり易くするために示されない場合が多い。ここで、本明細書において使用する用語及び表現は、特定の意味が他の用法として本明細書において示される場合を除き、これらの用語及び表現がその該当するそれぞれの調査研究分野において使用されるような普通の意味を持つことも理解されたい。
【０００６】
本実施形態は、第１ローカル無線通信デバイスに無線通信接続障害または無線通信リンク障害が発生したときに第２リモート通信デバイスに対して通知を行なうために使用される装置、方法、及びシステムを提供する。この通知を行なわない場合には、第２リモート通信デバイスのユーザは、第１通信デバイスにリンク障害が発生していることに気付かず、そして第２ユーザは知らずに長い時間に渡って通信しようと試み、そして／または応答を待とうとする。これは第２ユーザにとって時間の無駄であり、かつ当該ユーザを非常に不快にする。従って、本実施形態は、リモートユーザに対して、ローカルユーザが彼／彼女の無線リンク障害に会っているときに通知を行なう。本実施形態が行なう迅速な通知によってユーザの印象が良くなり、かつユーザ満足度が高くなる。
【０００７】
或る実施形態は無線通信を提供するために使用される方法を提供する。これらの方法では、ローカル無線通信接続をモニタリングし、そして第１通信デバイスとの無線通信接続に障害が発生する時点を検出する。第１通信デバイスの通信先であった第２通信デバイスを求め、そして本方法では、第２通信デバイスに対して無線接続障害を通知する。或る実施形態では、第２通信デバイスを、サーバにクエリーを出して第２通信デバイスに関する情報を取得することにより求める。或る実施形態においては、通知を行なう方法では、帯域内トーンを第２通信デバイスに転送し、そして／またはリアルタイムプロトコル（ＲＴＰ）パケットを生成し、そして転送する。或る実施形態では、無線リンク障害は無線接続ネットワーク（ＲＡＮ）、パケット制御機能（ＰＣＦ）、及び／又はモバイルスイッチングセンター（ＭＳＣ）を通して検出される。
【０００８】
更に別の実施形態は、ユーザに無線接続障害を通知するために使用される方法を提供する。これらの方法では、通信接続を第１通信デバイスと第２通信デバイスとの間に、第１通信デバイスが第２通信デバイスと少なくとも第１無線リンクを通して無線通信する通信ネットワークを通して確立する。第１通信デバイスとの第１無線リンクに障害が発生していることが検出されると、これらの方法では、第２通信デバイスに第１通信デバイスとの接続に障害が発生していることを通知する。障害の検出では、無線リンク障害をＰＣＦを使用して検出し、そして通知では、通知をＰＣＦが生成し、そして通知を、第２通信デバイスとの接続を行なう通信に載せることができる。或る実施形態では、ＰＣＦはサーバに第１通信デバイスとの無線リンクに障害が検出されたことを通知し、そして第２通信デバイスの識別情報をサーバから受信して、ＰＣＦが通知を第２通信デバイスに正確に転送するようにする。
【０００９】
無線通信を提供するために使用されるシステムが或る実施形態において提供される。これらのシステムは、第１通信デバイスと無線リンクを通して無線通信する基地局と、基地局に接続される無線接続ネットワーク（ＲＡＮ）と、そして第１通信デバイスに少なくともＲＡＮを通して通信接続される第２通信デバイスと、を備えることが好ましい。ＲＡＮは無線リンクの障害を検出し、そして通知を生成し、更にこの通知を第２通信デバイスに転送して第２通信デバイスに、無線リンクに障害が発生していることを通知する。或る実施形態では、ＲＡＮは無線リンクの障害を検出するＰＣＦを含む。システムは更に、ＲＡＮに接続され、更には分散ネットワークにも接続されるパケットデータ提供ノード（ＰＤＳＮ）を備えることができるので、第２通信デバイスは第１通信デバイスに少なくともＲＡＮ、ＰＤＳＮ、及び分散ネットワークを通して通信接続されるようになる。
【００１０】
本実施形態の動作によって、ユーザの印象が良くなり、そして第１ユーザが第２ユーザと無線通信しており、かつ第１ユーザが無線リンク障害に会っている場合に無駄に費やされる時間を大幅に短くすることができる。既存の通信ネットワークでは、無線接続の第１当事者が障害にあうと、第１当事者との関係が中途半端な状態になっている第２当事者は第１当事者が或る期間に渡って無線接続障害に会っていることに気付かないままの状態になる。この状態は、障害が発生している通信デバイスが通信リンク障害及び／又は切断を通知することができない場合に特に関連する。
【００１１】
例えば、第１当事者が無線リンクを通して、無線接続または有線接続を通して通信している第２当事者と通信しており、更に第１当事者が無線リンク障害にあう場合、第２当事者は第１当事者が無線リンク障害に会っていることに気付かない。或る無線デバイスは、無線デバイスに接続障害が発生しているときにローカルユーザに直接通知を行なうことができるが、遠く離れた場所で通信に参加している他の当事者または当事者群は障害に気付かない。第２ユーザまたはリモートユーザは通知されないままであり、更に通信をしようと待っている。第２ユーザは、第１当事者が通話状態になっていないことに気付く前の５，８，１０秒、またはそれ以上の時間だけ待つ恐れがある。この状態は特に、第１当事者が接続障害に会っているときに第２当事者が通話している、または通信を送信している場合にはっきりと現われる。第２当事者は、第１ユーザが接続状態になっていないことに気付く前に、数秒（例えば、１０秒以上）に渡って通話を続ける恐れがある。この状態は時間の多大な浪費であり、かつユーザを極めて不快にする。多くの場合、何を送受信していたか、そして第１ユーザが何を受信できなかったかを知ることが困難になる。
【００１２】
本実施形態は、通知が行なわれないというこの問題を、ユーザに、通信に参加している別の当事者が無線接続障害にあう、または別の当事者の無線接続が切断される時点で、当該事実を知らせる、そして／または通知することにより有利な形で解決する。障害は、無線接続障害（例えば、無線周波数（ＲＦ）接続時の干渉による障害、例えばリソースを利用することができないことに起因するハンドオフ失敗など）、電力遮断（例えば、携帯電話機のバッテリ切れ）に起因する障害、移動体機器の損壊（例えば、ユーザが彼／彼女の携帯電話機を落とすことによる）、及び接続障害が発生する他の同様の事象により起こり得る。
【００１３】
或る通信システム及び／又はネットワークでは、システムはデータ通信を音声通信に対して、そして／またはディスパッチ通信をテレフォニー通信に対して区別する。通常、音声通信及び／又はサービスはリアルタイムアプリケーションである。更に、これらのシステムは、ベーストランシーバ基地局（ＢＴＳ）のような送信局に対してどこに位置しているかに関係なく、一様なサービスを全てのユーザに提供しようとする。更に、音声通信では通常、大量のデータが伝送されることがないので、通信システムは通常、高品質音声サービスを提供しながら比較的低い、または遅いデータレートを割り当てる。
【００１４】
別の構成として、ディスパッチ通信または直接接続通信を行なうシステムは、システムを通して授受されるデータの量を最大にしようとする。通常、ユーザは異なるデータレートを必要とする。データレートを最大にするために、システムは各ユーザにユーザが受け容れることができる最大データレートを割り当てる。この割り当ては通常、通信チャネル、チャネルへの干渉、ユーザが必要とするデータ帯域幅、及び他のこのような条件によっても制限される。データ通信またはディスパッチ通信では音声データを送受信することもできる。例えば、データ通信は、データ通信として処理されるプッシュツートーク通信を含み、これにより通信リンク、ボイスオーバーインターネット、及び他のこのような通信を専用に使用する必要を無くす。或る量の音声データを含むデータ通信を用いることにより、音声を分散し、最適ルートを通して送信し、そして再合成して出力音声メッセージを生成することができる。更に、データ通信は通常、共有リソースを通して行なわれ、この場合、パケットは種々の異なる接続手段を通して送信することができ、そして所望の受信者に対する最終送信が行なわれる前に再合成することができる。
【００１５】
ディスパッチ通信または直接接続通信を行なう際の構造及びアプリケーションは音声通信とは異なるので、本実施形態の内の多くの実施形態は或る形態では、データ通信及び音声通信を区別する。
【００１６】
一般的に、ディスパッチ通信を行なうために、第１当事者は第２当事者の専用識別子を認識し、そして当該識別子を使用してディスパッチコールを第２当事者に対して行なう。一旦、第１当事者がディスパッチコールを開始すると、通信システムは迅速に呼を設定し、そしてメッセージを第１当事者の通信デバイスに送信する。メッセージを受信すると、第１当事者の無線機は可聴警告を作動させて第１当事者に通話を開始すべき時間、及び／又はデータを送信すべき時間を知らせる。別の実施形態では、話し手はこのフィードバックを受け取る前に通話の開始を許可される。第２当事者の通信デバイスは音声信号またはデータ信号を受信し、そして当該データを再生する、または第２当事者が当該データを受信することができるようにし、第２当事者が必ず何らかのアクションを起こすという必要が全くない。
【００１７】
しかしながら、ディスパッチ通信の性質によって、一方の当事者が、当該当事者が彼／彼女の無線接続に障害が発生している状態になっているかどうか、そして障害に会っている時点を判断することが非常に難しくなる。通信を送信している第１当事者と第１当事者に応答している第２当事者との間に長い沈黙が生じ得るので、第１当事者は第２ユーザが接続障害に会っていることに恐らく長時間に渡って気付かない。更に、ディスパッチ通信は通常、半二重チャネルを通して行なわれる。従って、１度に一方のユーザしか通信することができないので、話し手ユーザは通信に参加している他方の当事者が接続障害に会っていることに気付かない。従って、話し手ユーザは、他方のユーザが接続不能の状態になっていることを知らずに話し続け、かつ他方のユーザがもはや接続状態になっていないことが判明する前に非常に長い時間に渡って待つ恐れがある。
【００１８】
本実施形態は、通信の一人以上の当事者が、無線接続が切断された状態になっている、または無線接続障害の状態になっている時点を特定する方法及びシステムを提供する。本方法及びシステムは、通信の他方の当事者または当事者群に、ユーザが彼／彼女の接続に障害が発生している状態になっていることを迅速に通知する。これにより、接続が切断された状態になっていない当事者が、他方のユーザがもはや接続状態になっていないことが判明する前に、非常に長い時間に渡って待つという現象を防止することができる。
【発明を実施するための最良の形態】
【００１９】
図１は、或る実施形態による通信システムまたはネットワーク１１０の簡易ブロック図を示し、第１無線デバイスまたは移動局１２２がネットワーク１１０経由でディスパッチ通信（例えば、プッシュツートーク（ＰＰＴ））を使用して第２無線デバイス１２４及び／又は有線デバイス１２６と通信する。これらの無線デバイスは、ディスパッチ通信を行なうことができるほぼ全ての無線デバイスとすることができ、これらの無線デバイスとして、無線電話機、ページャ、携帯情報端末、デスクトップコンピュータ、ラップトップコンピュータ、及び他のこのような無線通信デバイスを挙げることができる。多くの場合、ディスパッチコールはモバイルツーモバイル（Ｍ−Ｍ）通信であるが、本実施形態はモバイルツーワイヤド（mobile-to-wired ：移動体−有線）コールまたはモバイルツーランド（mobile-to-land（Ｍ−Ｌ）：移動体−陸上）コールだけでなく、ランドツーモバイル（land-to-mobile（Ｌ−Ｍ）：陸上−移動体）コールにも適用することができる。更に、本実施形態は、いずれの関連無線通信技術によっても利用することができ、これらの無線通信技術として、これらには制限されないが、符号分割多重接続（ＣＤＭＡ）、ＣＤＭＡ２０００，全地球測位システム（global system for mobile communications ：ＧＳＭ）、汎用パケット無線サービス（General Packet Radio Service：ＧＰＲＳ）、ユニバーサル移動体通信システム（ＵＭＴＳ）（第３世代３Ｇ  ＵＭＴＳを含む）、及び他のこのような無線通信技術を挙げることができる。
【００２０】
第１無線デバイス１２２は通信を、無線リンク１１２を通して、ベーストランシーバ基地局（ＢＴＳ）１３０及び／又は高効率基地局トランシーバシステム（ＥＢＴＳ）のような基地局との間で送受信する。ＢＴＳはデータを、パケット制御機能（ＰＣＦ）１３２に転送し、そしてＰＣＦ１３２から受信する。ＢＴＳ１３０及び／又はＰＣＦ１３２は或る実施形態では、無線接続ネットワーク（ＲＡＮ）１３４に組み込まれる。ＲＡＮは、無線デバイス、例えば無線デバイス１２２への通信、及び無線デバイス１２２からの通信の制御及びルーティングを行なう。
【００２１】
ＲＡＮ１３４は、モバイルスイッチングセンター（ＭＳＣ）１３６との接続を行なう。ＭＳＣはシステムまたはネットワーク１１０の内部で通信（例えば、通話）を切り替え、そして公衆交換電話網（Public Switched Telephone Network ：ＰＳＴＮ）１６０との接続の切り替えも行なって、無線通信デバイス１２６及び他のネットワーク構成要素との接続を可能にする。ＭＳＣ１３６はＲＡＮ１３４とのインターフェース接続を行なって呼設定及び呼解除、及び呼処理のような種々の機能、及び補助サービス関連機能を実行する。
【００２２】
ＲＡＮのＲＣＦ１３２は更に、パケットデータ提供ノード（ＰＤＳＮ）１３８との接続を行ない、そしてデータパケット群をＰＤＳＮ１３８に転送する。ＰＤＳＮは、無線システムと、イントラネット、インターネット、及び他のこのような分散ネットワーク１４０のような公衆データネットワーク（ＰＤＮ）１４０との間の接続機能及びゲートウェイ機能を提供するので、第１モバイル通信デバイス１２２は音声及び／又はデータコンテンツをネットワークの他の通信デバイス（例えば、第２モバイルデバイス１２４及び／又は有線デバイス１２６）との間で送受信して、公衆データネットワークのデータ及び／又はコンテンツにアクセスし、ｅｍａｉｌのような他のアクティビティ、及び他の同様な機能及び動作を実行することができる。或る実施形態では、システムはコンファレンスデバイス、コンファレンスブリッジ、及び／又はコンファレンスサービス１７０を含む、そして／またはこれらのコンファレンス関連要素と連携動作する。これらのコンファレンスブリッジによって当事者達はコンファレンスコールを、ユーザがブリッジ１７０との接続を行なうことにより設定することができる。通常、ユーザ１２２，１２４，１２６はコンファレンスブリッジ１７０との接続を、分散ネットワーク１４０または１６０を通して行なう。
【００２３】
動作状態では、ＲＡＮ１３４は無線リンク１１２をモニタリングして正確な通信を確保する。例えば、ＲＡＮは無線デバイス１２２に指示して他のＢＴＳとの接続を行なわせることができ、送信電力レベルを上げる、そして／または下げることができ、そして他の制御情報を無線デバイスに提供することができる。或る実施形態では、ＲＡＮは更に、無線デバイス１２２の障害、及び／又は無線リンク１１２の障害を検出することができる。以下に更に完全な形で説明するように、無線デバイス１２２の障害を検出すると、ＲＡＮ１３４はＰＣＦ１３２に通知して、第１通信デバイスと現時点で通信している他のユーザ及び／又はデバイスに対する通知を開始させる。
【００２４】
更に図１によれば、或る実施形態では、システムまたはネットワーク１１０は追加する形で、そして／または別の方法として、基地局コントローラ（ＢＳＣ）１８０を通過する通信経路を提供することができる。第３無線デバイスまたは移動局１２８は第２無線デバイス１２４及び／又は有線デバイス１２６とＢＳＣを通して通信することができる。第３無線デバイス１２８は通信を、無線リンク１１２を通してＢＴＳ１３０との間で送受信することができる。ＢＴＳはＢＳＣ１８０との接続を行なう。ＢＳＣは、確実にパケット群が順番に受信され、そして転送されるように機能し、無線リンク１１２を通して第３無線デバイス１２８とＢＴＳ１３０との間で行なわれる再送信の状態をほぼ制御する。更に、ＢＳＣ１８０はＰＣＦ１３２及びセレクタ切替ユニット（selector distributor unit ：ＳＤＵ）１８２を含む。ＳＤＵは、１つの無線デバイス１２８を複数のＢＴＳによって受け持つことができる場合に、信号を合成する。ＰＣＦ１３２は更に、ＳＤＵ１８２に関するパケットデータを或る形で一時保存する機能を提供する。
【００２５】
ＢＳＣ１８０は通常、ＭＳＣ１３６に接続される。上述のように、ＭＳＣは呼の切り替えを、ＰＳＴＮ１６０及び／又は他のネットワークを通して行なう。ＭＳＣ１３６はＢＳＣ１８０とのインターフェース接続を行なって呼設定及び呼解除、及び呼処理のような種々の機能、及び補助サービス関連機能を実行する。ＢＳＣ１８０は或る実施形態では更に、ＰＤＳＮ１３８との接続を行ない、そしてデータパケット群をＰＤＳＮ１３８に転送して、通信をネットワーク１４０を通して確立する。ＢＳＣのＰＣＦ１３２は第３無線デバイス１２８との無線リンクをモニタリングする。ＰＣＦが第１無線デバイスの障害を検出すると、ＰＣＦは、第１通信デバイスと現時点で通信している他のデバイスに通知を行なう。
【００２６】
或る実施形態では、ＰＤＳＮ１３８はアドレスを含むヘッダ情報を追加して、パケット群をネットワーク１４０を通して送信することができるようにする。宛先となるモバイル通信デバイス（例えば、第２無線デバイス１２４）がネットワーク１１０の異なる領域に位置する場合、ＰＤＳＮはデータパケット群をネットワークを通して第２のＰＤＳＮ（図示せず）に転送して、アドレスを含むヘッダ情報を消去し、そしてパケット群を、宛先となる無線デバイス１２４に転送することができる。
【００２７】
通信ネットワーク１１０によって、データ通信またはディスパッチ通信がネットワークの複数のデバイスの間で可能になる。例えば、第１無線デバイス１２２は第２無線デバイス１２４と、プッシュツートーク（ＰＴＴ）機能、Voice-over-IP 機能、及び他のバッチ接続及び／又はデータ通信経路を利用して通信することができる。ＰＴＴを利用して、システムは、例えば第１無線デバイス１２２に関するリクエストを受信して、データ通信を第１無線デバイス１２２と第２無線デバイス１２４との間に確立する。上に議論したように、第１ユーザは、例えば第２ユーザを特定し、そして第１無線デバイスのボタンを押下して通信を起動する、または開始する。第２デバイスとの通信が確立すると、システムは第１デバイスに接続が確立されていることを通知する（これによって、例えば第１無線デバイスに可聴トーンを鳴動させ、ビープまたは他のトーンの聴覚コードを含むパケットを生成させ、表示を行なわせ、光または他のこのような信号を点灯させる）。従って、第１及び第２ユーザは互いに喋りながら交互に通話することができる。通常、一方の通信デバイスのみが所定の時間に通信し、そして２つの無線デバイスの間の通信は２つの無線デバイスの間の接続を交互に制御することにより行なわれる。更に、システムは通常、半二重チャネルを提供し、この場合、通信デバイス群はチャネルを、当該チャネルを一度に制御する一つのデバイスと共有する。
【００２８】
或る好適な実施形態では、ＲＡＮ１３４及び／又はＰＣＦ１３２は接続無線デバイスの無線リンクをモニタリングする。例えば、ＲＡＮ１３４またはＰＣＦ１３２は第１無線デバイス１２２との無線リンク１１２をモニタリングし、そして／またはＰＣＦ１３２は第３無線デバイス１２８とのリンクをモニタリングする。ＲＡＮ１３４及び／又はＰＣＦ１３２が、リンク１１２がアクティブになっていないことを検出すると、ＰＣＦは、第１無線デバイス１２２（または、第３デバイス１２８）のリンクがアクティブになっていないという通知を生成する。或る実施形態では、ＰＣＦは通知を生成し、この通知が第１ユーザと現時点で通信している第２ユーザ（例えば、無線デバイス１２４を通して通信しているユーザ）に転送される。通知は、第１無線デバイス１２２の無線接続１１２に障害が発生していることを示す。例えば、ＰＣＦ１３２は簡単なリアルタイムプロトコル（ＲＴＰ）パケットを生成し、そして第２デバイスとの通信に載せることができる。リアルタイムプロトコルパケットは第２ユーザに、第１ユーザの無線リンク１１２に障害が発生していることを通知する。通知によって、第２通信デバイス１２４に可聴トーンを鳴動させ、メッセージを表示させ、光を点灯させる、または点滅させ、トーンの聴覚コードを含むパケットを生成させ、そして／または第２ユーザにリンク障害を通知する他の同様の機能を行なわせることができる。或る実施形態では、ＰＣＦは追加する形で、そして／または別の方法として、サーバ１５０に通信リンク障害を通知する。従って、サーバは、障害が発生している無線デバイス、及び／又は他のシステム構成要素と通信している一人以上のユーザとの通信に通知を載せる、そして／またはこれらのユーザに通知を送出することができる。
【００２９】
ＲＡＮ１３４及び／又はＰＣＦ１３２に無線リンク１１２をモニタリングさせることにより、システム１１０は障害を迅速に検出する。その結果、第２ユーザには、第１ユーザが接続障害に会っていることが迅速に通知され、そして第２ユーザは適切な処置（例えば、再接続の試行、切断、及び他の同様の行動）を採ることができ、第１ユーザが未だ接続状態になっているかどうかについて知ろうとするために長い時間に渡って待つ必要がない。
【００３０】
図２は、システム１１０の複数のコンポーネントの間の通信の論理的なフロー２１０を簡易図で示している。第１及び第２通信デバイスが連携動作した後に、かつ一旦、発信当事者（例えば、第１移動局（ＭＳ）１２２）が、宛先当事者（例えば、第２移動局（ＭＳ２）１２４）が接続され、そして音声データを受信することができるという通知を受信すると、ＲＡＮ１３４は無線リンク１１２をステップ２３０においてモニタリングする。一旦、ＲＡＮがリンクに障害が発生していることを認識すると、ＲＡＮは解除命令をステップ２３２において第１ＭＳ１２２に対して発行する。
【００３１】
接続障害または接続切断は多数の状態、すなわち信号及び／又はデータの欠落、及び他のこのような情報によって認識することができ、これらの情報として、これらには制限されないが、良品フレームの受信が逆方向リンクで所定期間に渡って不能になっている状態、逆方向専用のパイロット通信、パワーコントロールビット、チャネル品質情報の受信が不能になっている状態、閾値を超える誤差を含む信号を受信している状態、無線デバイスから受信する信号または信号群が所定の品質を下回り、そして／または所定期間に渡って所定の品質を下回る場合に所定期間に渡って欠陥フレーム及び／又は不良フレームを受信している状態、及び他のこのような兆候及び／又はこれらの兆候の組み合わせを挙げることができる。一般的に、システムが、システムに無線デバイスがアクティブであることを通知する情報を所定の期間、及び／又は不当に長い期間に渡って受信することができない場合、ＲＡＮ及び／又はＰＣＦはリンクにＲＦ障害が発生していると認識する。ＲＦ障害は幾つかの他の理由により生じ得る。例えば、切断は、呼が既に存在している、または使用対象のリソースが既に使用されている、またはリソースが利用できないことにより呼が切断される場合に起こり（通常、これらの切断は低優先度の呼に関して起こる）、呼の切断は、通信デバイス群の内の一方のデバイスの動作時間が短く（例えば、ユーザがプリペイド電話機で通話していて、わずかな時間で時間切れになってしまう）、そして他方のデバイスの接続が切断される場合にも起こり得る。
【００３２】
ステップ２３４では、ＲＡＮは、ＭＳＣ１３６にリンク障害を通知するクリアリクエストを生成する。ステップ２３６では、ＲＡＮはＰＣＦ１３２へのＡ９−解除−Ａ８メッセージを生成して、ＲＣＦに障害を通知する。ステップ２４０では、ＲＣＦ１３２は第２移動局ＭＳ２への障害通知を生成し、そして第２移動局ＭＳ２との通信に載せ、この時点で、第２ユーザはリンク障害に気付き、そして第１ユーザが未だ接続状態になっているかどうかを判断するために待つということがなくなる。通知は多数の異なる技術によって生成することができる。例えば、ＰＣＦは、他の通信デバイス（例えば、デバイス１２４及び／又は１２６）へのオーディオ信号及び／又はＲＴＰパケットのようなメッセージを生成し、そして当該通信デバイスとの通信に載せることができ、ＰＣＦはセッション開始プロトコル（ＳＩＰ）メッセージを生成することができ、そして／またはＰＣＦはこの技術分野で公知のように、他の同様の通知、または複数の通知の組み合わせを生成することができる。
【００３３】
ステップ２４２では、ＰＣＦ１３２は、エアリンク接続停止リクエスト（stop airlink request）を含むＡ１１登録リクエストメッセージをＰＤＳＮ１３８に送信し、そしてセッションにリクエストを渡してセッションを休止させる。ＰＤＳＮはそれに応じてシステムデータを更新する。ステップ２４４では、ＭＳＣ１３６はクリアリクエストをＲＡＮ１３４から受信すると、クリアコマンドをＲＡＮに対して発行する。ステップ２５０では、ＰＤＳＮ１３８は登録リクエストに対して、ＰＣＦ１３２へのＡ１１登録応答メッセージで応答する。ステップ２５２では、今度はＰＣＦがＡ９−解除−Ａ８−完了アクノリッジメントをＲＡＮ１３４に対して発行する。ステップ２５４では、ＲＡＮは、ＭＳＣ１３６へのクリア完了アクノリッジメントを生成し、そして転送する。
【００３４】
図２の論理フロー２１０の実施形態では、第２移動局１２４、従って第２ユーザはプロセス２１０の非常に早い時点で通知を受け取る。これにより、第２ユーザは大量の時間を節約することができ、第２ユーザの不快感を軽減することができ、ネットワークリソースを節約することができ、そして上に説明したように、かつ以下に更に完全な形で説明するように他の利点がもたらされる。更に、本実施形態は、システムコンポーネント間の規格及び通信規格に変更を加えることなく実行することができる。或る好適な実施形態では、機器障害Ａ９−解除−Ａ８信号（equipment failure A9-Release-A8 signal）は突発的な呼損失として解釈されるので、ＰＣＦは他のユーザ（群）に接続障害の通知を開始する。
【００３５】
図３は、図２のステップ２４０における通知に関する或る実施形態による通信の論理的なフロー３１０の詳細図を表わしており、ＰＣＦは通知をリモートユーザとの通信に載せ、ローカルユーザとの無線リンクに障害が発生していることを通知する。ＲＡＮはローカル無線通信デバイス（例えば、デバイス１２２）とのリンクに障害が発生していることを図２のステップ２３０において検出し、そしてＰＣＦ１３２への機器障害通知（Ａ９−解除−Ａ８メッセージ）を生成して、ＰＣＦに障害をステップ２３６で通知する。図３によれば、ステップ３２２では、ＰＣＦは、宛先であるリモート通信デバイス（例えば、有線デバイス１２６）に向けられる障害通知を生成し、そして送付対象の当該通知をリモートデバイスに転送する。通知は、上に説明したように、トーン、テキストメッセージ、コマンドとすることができ、これによってリモートデバイスにトーンを鳴動させる、または光を点灯させる。或る実施形態では、ＰＣＦは事前の、または所定のＲＴＰオーディオファイルを利用して、ＲＦリンク障害通知をリモートデバイスに送信することができる。ＲＴＰパケットまたはパケット群はＰＤＳＮ１３８に転送することができる。
【００３６】
ステップ３２４では、ＰＤＳＮ１３８は通知をＰＣＦから受信し、そして通知をフォーマットし、そして分散ネットワーク１４０を通して送信して、第２リモートＰＤＳＮ３１２が受信する。ステップ３２６では、リモートＰＤＳＮはフォーマットされた通知を変換し、そして通知をＡ１０通信として第２リモートＰＣＦ３１４に転送する。ステップ３３０では、リモートＰＣＦは通知をリモート通信デバイス１２６に転送する。ステップ３３２では、リモート通信デバイスは第２ユーザに、例えばＲＴＰパケット（群）によって定義される可聴トーンを鳴動させることにより通知する。
【００３７】
或る実施形態では、ＲＡＮ１３４及び／又はＰＣＦ１３２は第１通信デバイス１２２との無線リンク１１２に障害が発生していることを検出する。しかしながら多くの場合、ＰＣＦは第２通信デバイスの識別情報に気付かない、または当該情報を認識しない、または通知を第２通信デバイスにどのようにしてルーティングするかについて判断することができない。或る実施形態では、ＰＣＦはリモートユーザを通信タイプ、通信内のアドレス（例えば、ＩＰアドレス）、及び他のこのようなデータを利用して判断しようとする、または推定しようとする。追加する形で、そして／または別の構成として、或る実施形態では、ＰＣＦ１３２はリンクに障害が発生していることを検出すると、サーバ１５０との接続を行なって第２通信デバイスを特定する。
【００３８】
サーバ１５０は通信タイプ、障害発生ユーザ、通信内のアドレス、ルックアップテーブル、及び他のこのような情報に従って特定することができる。或る実施形態では、ＰＣＦ１３２及び／又はＲＡＮ１３４は特別に指定されたサーバ（例えば、第１ネットワークサーバ、何故なら、当該サーバは特定の無線通信事業者が指定するサーバであるからである）との接続を行なう。他の実施形態では、ＰＣＦ／ＲＡＮはサーバを、通信タイプ、障害発生ユーザ、及び／又は通信内のアドレス（例えば、ＩＰアドレス、及び／又は他のこのようなアドレス）に基づいて特定する。例えば、或る実施形態では、ＰＣＦ／ＲＡＮ（または、他のネットワークコンポーネント）は、通信接続を開始するとユーザのＩＰアドレスを保存することができる。保存されるＩＰアドレスは、もし接続障害が生じた場合に、後の時点で使用することができる。サーバは、分散ネットワーク１４０，１６０に接続されるＭＳＣ１３６、ＰＤＳＮ１３８、別のサーバ１５０の位置に配置することができ、かつＰＤＳＮ、ＭＳＣ、及び／又はＰＣＦ／ＲＡＮとの接続を行なうように構成することができ、更には順方向音声ストリームを通信デバイス（例えば、異なるＰＣＦ／ＲＡＮを通して接続することができる、ＰＴＴを用いる一つ以上の無線デバイス）に配信する呼処理フローを実行し、ユーザ課金及び他のこのようなサービスを追跡するように構成することができる。サーバ１５０は、システム１１０のプロバイダ、無線通信サービスを提供する他の会社（例えば、ＮｅｘｔｅｌＴＭ，ＳｐｒｉｎｔＴＭ，ＶｅｒｉｓｏｎＴＭ，ＡＴＴＴＭ、及び他のこのような無線サービスプロバイダ）などが運用することができる。
【００３９】
追加する形で、そして／または別の構成として、或る実施形態は、コンファレンスブリッジ１７０を用いて通信の当事者間の通信をモニタリングする。複数の当事者が通信接続を、コンファレンスブリッジ１７０との接続を行なうことにより確立する。コンファレンスブリッジは、一人以上のユーザが障害に会っていることを検出することができる。一旦、障害が検出されると、ブリッジ１７０は当該情報を使用してコンファレンスステータスを更新し、サーバ１５０及び／又はＭＳＣ１３６に対する通知を行ない、通信に参加している他の当事者に対する通知を行ない、そして／またはサーバまたはＭＳＣによる通知の生成を可能にする。
【００４０】
更に、或る実施形態では、ＰＣＦ，ＲＡＮ、及び／又はサーバは更に、第１無線デバイス１２２が実際に一人以上の他の当事者との通信に参加していたことを検証することができる。一旦、検証されると、ＰＣＦ及び／又はＲＡＮは手続きを開始して一人以上の他の当事者に、第１無線デバイスの無線リンク１１２に障害が発生していることを通知する。更に、或る実施形態では、システムは更に、障害が、ユーザによる通信の終了、またはネットワークが意図的に接続を切断する処理（例えば、呼を中断する、別の動作モードを選択する、無線デバイスにサービスを提供することができないセルとの再接続を行なう、呼が既に存在している、リソースを利用することができない、プリペイド通話時間が過ぎて時間切れになってしまう、そして他のこのような状態）のような故意のアクションに起因するものであったか、または障害が偶発的に生じたものかどうかについて判断する。
【００４１】
図４は、或る実施形態によるプロセス４１０の簡易フロー図を示し、この実施形態では、無線周波数（ＲＦ）リンク障害がＰＣＦによって検出され、そしてＰＣＦが通知を生成する。ステップ４２０では、ＰＣＦはリンク障害を検出する。上に説明したように、ＰＣＦはリンク障害を直接検出することができ、そして／またはＲＡＮから障害について信号を受信することができる。ステップ４２２では、ＰＣＦは、ローカル通信デバイスがアクティブな状態で通信に参加していたかどうか（例えば、ＭＳへの、またはＭＳからのＰＴＴ（プッシュツートーク）の間、またはＰＴＴ「コール」の間；ＴＨＯＬＤを例えば６秒に等しいとすると、いずれかの当事者からのＰＴＴが過去のＴＨＯＬＤ秒以内に行なわれたかどうか）について判断する。ローカルデバイスがアクティブな状態で通信に参加しているということがなかった場合、プロセス４１０は終了する。これとは異なり、ローカルデバイスがアクティブな状態で通信に参加していた場合、プロセスはステップ４２４に進み、このステップにおいて、ＰＣＦは障害が意図的な、または正常な接続切断（例えば、呼が中断される；別の動作モードが選択される；無線デバイスにサービスを提供することができないセルと再接続する；そして他のこのような行動）に起因したものであるかどうかについて判断する。障害が意図的な切断に起因する場合、ＰＣＴはリモートデバイスへの通知を行なわず、プロセス４１０を終了させる。
【００４２】
通信障害が、予測される正常な切断に起因するものではないとステップ４２４において判断される場合、プロセスはステップ４２６に進む。偶発的な切断によって生じる障害は、多数の現象及び／又は状態によって生じ得るものであり、これらの現象及び／又は状態として、ローカルデバイスが無線信号を遮断するトンネルまたは他のエリアに移動する場合、デバイスへの電力供給が遮断される（例えば、バッテリとの接続が遮断される）場合、デバイスが損壊する（例えば、ユーザがデバイスを下に落とす、或る物体がデバイスに衝突する、またはデバイスに圧し掛かる）場合、及び他のこのような状態を挙げることができる。ステップ４２６では、ＰＣＦはサーバ１５０及び／又はローカルＭＳＣ１３６との接続を行なってアクティブな状態で障害発生ローカルデバイスとの通信に参加している一つ以上の更に別の宛先通信デバイスを特定する。ステップ４３０では、サーバまたはＭＳＣは一つ以上の宛先デバイスを特定する。ステップ４３２では、ＰＣＦは通知を生成し、そして当該通知を一つ以上の宛先デバイスに送信する。通知は、ほとんどどのような関連通知とすることもでき、これらの関連通知として、これらには制限されないが、セッション開始プロトコル（ＳＩＰ）メッセージ、一つ以上のＲＴＰパケット、及び他のこのような通知を挙げることができる。
【００４３】
本実施形態によって更に、２人よりも多くのユーザとのグループコールまたはコンファレンスコールの間の接続に障害が発生している一人以上のユーザに対する通知が可能になる。グループコールの間、グループコールの各当事者に接続されるＰＣＦ１３２及び／又はＲＡＮ１３４システムは、グループコールに参加しているこれらの当事者の該当する無線デバイスの無線リンクをモニタリングする。障害が検出される場合、接続ＰＣＦ及び／又はＲＡＮは通知を生成し、そして当該通知を通信に参加しているユーザの内の一人以上のユーザとの通信に載せる。或る実施形態では、ＰＣＦ及び／又はＲＡＮは通知を他の参加者の各々に対して行なう。例えば、ＰＣＦはサーバにクエリーを出して、参加当事者の各々を特定し、そしてこれらの当事者の各々へのルーティングを行なう。次に、ＰＣＦは通知を生成し、そして当該通知を帯域内通信（例えば、２５０ｍｓトーン）に載せることができる。
【００４４】
或る好適な実施形態では、一人以上の当事者への通知は、通知がグループコールに干渉することがないように、またはグループコールとの干渉が最小限に抑えられるように行なわれる。例えば、通知はテキストメッセージまたは表示メッセージとして送信することができるので、受信側の通信デバイスは通知を表示することができる。追加する形で、そして／または別の構成として、通知によって受信側の通信デバイスは可聴トーンを鳴動させることができる。しかしながら、トーンは通常、単一ユーザに送信されるトーンよりも弱いので、微弱トーンはグループコールでは耳障りにはならない。或る別の実施形態では、通知はグループコールの発信者にのみ転送される、または現時点でグループコールを制御しているユーザに対してのみ通知が行なわれる。
【００４５】
この技術分野では公知であるが、プッシュツートークを使用するグループコールでは通常、現時点で通話しているユーザがグループ通信を独占する権利を有する、またはグループ通信を「制御（control ）」する。或る実施形態では更に、ユーザが障害に会っている場合に障害発生ユーザが話し手ユーザまたは制御ユーザであるかどうかを判断する。一旦、障害発生ユーザが制御ユーザであったことが判明すると、ＰＣＦはＭＳＣに、障害発生ユーザが制御ユーザであったことを通知する。ＭＳＣは、障害発生ユーザに割り当てられていたリソースを解除し、更に独占的制御を解除して、障害発生ユーザがこれよりも先は、グループコールの通話において「発言権を持つ（has the floor ）」ことがなく、かつこの時点でグループ通信における発言権が開放される（open floor）ようにする。例えば、ＭＳＣはＳＩＰメッセージを発行してグループコールの制御を解除する。これにより、グループの別のユーザが、例えば通信デバイスのプッシュツートークボタンを選択することにより、グループを制御することができる。
【００４６】
図５は、グループ通信の一人以上の当事者が障害に会っていることを検出し、そしてグループ通信に参加している一人以上の他の当事者に対して通知を行なうプロセス５１０の簡易フロー図を示している。ステップ５１２では、プロセスは、第１ユーザの無線接続が切断されたことを検出する。この検出は上に説明したように、ＰＣＦ，ＲＡＮを通して、そして／またはＭＳＣを通して行なうことができる。障害発生ユーザを検出すると、プロセスはステップ５１４に進み、このステップにおいて、第１ユーザがアクティブな状態で通信にシステムを通して参加していたことが判断される、そして／または検証される。第１ユーザであることが確認されない場合、プロセスは終了し、そして他のユーザに対する更なる通知は行なわれない。これとは異なり、第１ユーザであることが確認される場合、ステップ５１６に進み、このステップにおいて、第１ユーザがグループ通信の構成員であるかどうかが判断される。第１ユーザがグループ通信の構成員ではない場合、ステップ５２０に進み、このステップにおいて、通信の他のユーザに対して通知を行なう。或る実施形態では、ステップ５２０は、上に説明し、かつ図２に示したプロセス２１０のような別のプロセスを通して行なわれる。
【００４７】
ステップ５１６において、第１ユーザがグループ通信の構成員であったと判断される場合、ステップ５３０に進み、このステップにおいて、グループ通信に参加している他のユーザを特定する。或る実施形態では、ＰＣＦがＭＳＣにクエリーを出して他のユーザを特定する。ステップ５３２では、ＰＣＦは或る通知を他のユーザとの通信に載せる。上に議論したように、当該通知は帯域内通信及び／又は他の参加ユーザの各々に向けられるトーンによって行なうことができる。例えば、ＰＣＦは他のユーザへのＲＴＰパケットのようなオーディオデータ、及び／又はＳＩＰメッセージを送信することができる。或る実施形態では、プロセスはステップ５３４に進み、このステップにおいて、グループ通信に参加している他のユーザの数を求め、そしてＰＣＦは帯域内通信の量を、グループ通信に参加している残りのユーザの数に従って調整する。
【００４８】
図５を参照し続けると、ステップ５４０では、プロセスは障害発生第１ユーザが制御ユーザであったかどうかを判断する。例えば、ＰＣＦはＭＳＣにクエリーを出して第１ユーザが話し手当事者、または制御当事者としてアクティブな状態であったと認識されたかどうかについて判断する。第１ユーザが制御当事者ではなかったと判断される場合、プロセス５１０は終了する。逆に、第１ユーザが制御当事者であったと判断される場合、ステップ５４２に進み、このステップにおいて、ＭＳＣは、例えばグループコールの制御を解除するＳＩＰメッセージを発行することにより第１ユーザによる制御を解除する。
【００４９】
本実施形態は同じようにして、ディスクトップディスパッチ通信及び／又はデータ通信において動作させることができる。本実施形態は更に、ディスクトップ、例えばデジタル加入者線をデータ通信に使用するディスクトップとの接続に発生する障害を特定する機能を備える。接続障害が検出されると、通信の一人以上の他の当事者には障害が通知されるので、一人以上の他の当事者は、ディスクトップが接続状態になっているかどうかを判断しようとするために時間を無駄に費やす必要がない。
【００５０】
無線ディスパッチ通信に参加している障害発生ディスクトップが話し手通信デバイス、または制御通信デバイスである状況においては、ディスパッチメッセージの終了をディスクトップデバイスから受信することができない。或る実施形態では、ＰＣＦ１３２及び／又はＲＡＮ１３４は無線接続をモニタリングする。通信の終了をディスクトップから所定期間に渡って、または閾値期間に渡って受信することがない場合、ＰＣＦ及び／又はＲＡＮは、ディスクトップにリンク障害が発生していると判断し、そして上に説明したように他のユーザに対する通知を生成する。追加する形で、そして／または別の構成として、ＰＣＦ及び／又はＲＡＮは更に、ディスクトップから受信するＲＴＰ／ユーザデータグラムプロトコル（Use Datagram Protocol ：ＵＤＰ）パケットをモニタリングすることができる。ＲＴＰ／ＵＤＰパケットをディスクトップから所定期間に渡って受信することがない場合、ＲＣＦ／ＲＡＮは、ディスクトップに障害が発生していると判断し、そして通知を生成する。ディスクトップ通信に関する本実施形態は、セルラーネットワーク、ローカルエリアネットワーク、衛星通信ネットワーク、これらのネットワークの組み合わせ、及び他のこのようなネットワークに用いることができる。
【００５１】
無線リンク１１２の障害は、多数の要因によって生じ得るものであり、これらの要因として、無線デバイス１２２の電源に障害が発生する（例えば、バッテリが外れる、そして／またはバッテリが切れる）現象、リンクが諸原因（例えば、呼の中断、別の動作モードの選択、火災による終了、無線デバイスにサービスを提供することができないセルとの再接続）によって解放される現象、そして解放に関する他のこのような原因を挙げることができる。これらの例では、本実施形態は上に説明したように、電源障害及び他の異常なリンク解放に起因してリンクから解放または切断される無線デバイスと通信している一人以上の他のユーザに対して同様の通知を生成する。或る例では、無線デバイスは異常なリンク解放が生じようとしていることを検出し、そしてシステムに通知を行なって、システムが、障害が発生している無線デバイスと現時点で通信している他のユーザ（群）への通知を生成することができるようにする。通知は音声通知、テキスト通知、通信デバイスを起動して通知（可聴トーン、光の点灯）を生成させるコマンド、及び他の通知とすることができる。或る実施形態では、音声通知は音声アナウンス、例えば「呼損失」、「呼切断」を読み上げる音声メッセージ、または他のこのようなアナウンスとすることができる。通知では更に、リンク障害と、バッテリ故障または他の原因による障害とを明確に区別することができる。例えば、トーンまたは低音ビープを生成して呼損失がバッテリ故障に起因するものであることを通知するのに対し、「呼損失」を読み上げる短い可聴アナウンスによって通信リンク障害に起因する障害を識別することができる。
【００５２】
或る実施形態では、リンク障害が検出されるとサーバ（例えば、サーバ１５０）に対する通知を生成する。サーバは通知を利用して障害発生デバイスとの通信に参加している他の一人以上の他のユーザが誰であるかを判断する。次に、サーバは障害の通知を生成し、そして当該通知を全ての関連当事者に送信する。追加する形で、そして／または別の構成として、切断発生ユーザに関する通知（例えば、ＰＣＦからの通知）を受信すると、通信デバイス（例えば、無線デバイス１２４）はサーバにクエリーを出して、どの当事者または当事者群が切断されたのか、そして／または障害に会ったのかについて特定することができる。
【００５３】
本実施形態では通知を、ショートメッセージサービス（テキスト及び／又は型付きメッセージ（typed message ））を利用して通信しているユーザに送付する。ショートメッセージサービスによって、メッセージを第１ユーザから第２ユーザに転送することができ、そして第２ユーザはタイプ入力を行ない、そして追跡応答を転送することができる。これらのテキスト通信は、ユーザ間で無制限の通信を行なうことにより継続することができる。或る実施形態では、テキストメッセージングは一つ以上のトラフィックチャネルを通して行なわれる。トラフィックチャネルを通してのテキストメッセージングを利用するために、本実施形態では、ユーザ群の内の一人のユーザがリンク障害に会っている時点を検出する。リンク障害が検出されると、システムは、残りのユーザ（群）に対する通知（例えば、トーン）及び／又はテキストメッセージを差し挟む。テキストメッセージまたは他の通知は、上に説明したように、ＰＣＦまたは他のシステムコンポーネントが生成することができる。
【００５４】
更に、本実施形態によってユーザに与える印象が平均的に良くなり、そして／またはネットワーク容量が大きくなるという利点がもたらされる。ユーザは所定のレベルのサービス品質を、提供される無線ネットワークに対して期待し、当該レベルのサービス品質がユーザに与える印象として現われる。サービスがユーザにとって悪く、ばらつき、そして／または苦痛を伴うものである場合（例えば、呼損失の発生回数が多い）、ユーザに与える印象が悪くなり、そして／またはシステムに対する不満足度が高くなる。多くのシステムが、ユーザに与える印象を所望のレベルにするために定義される或る固定感度での動作を行なおうとしている。例えば、或るシステムは固定割合（例えば、１％、２％、または他の或る割合）の接続障害を許容する。
【００５５】
本実施形態では、ユーザに迅速に接続障害を通知し、他のユーザが未だ接続状態になっているかどうかが不確かな期間が長くなるのを防止し、そしてリンク障害による精神的苦痛を低減することによりユーザの不快感を軽減する。通知を迅速に行なうことにより、ユーザに与える印象が極めて良くなり、かつユーザ満足度が高くなる。
【００５６】
更に、ユーザは、高くなった割合の呼損失に対して、少なくともこれまでの満足度で満足する状態を維持する可能性もある、というのは、本実施形態では、ユーザに接続障害を通知するからである。これにより、同じシステムを高い容量で動作させることができる。高い容量で動作させることにより、接続障害及び／又は呼損失が多くなる恐れがあるが、ユーザは接続障害に対して前よりも寛大になる、というのは、ユーザに対する通知が迅速に行なわれるからである。従って、システムは容量を、ユーザ満足度を下げることなく増やすことができる。
【００５７】
例えば、或るシステムは、ユーザに与える印象を同じレベルに少なくとも維持し続けながら、接続障害に関するこれらのシステムの許容固定割合を１％、３％、またはそれ以上の割合だけ高くすることができる。或るシステムは、例えばユーザが、接続障害が１％から５％に増加する現象を許容する場合、１．２５倍以上の負荷に耐えることができる。或る実施形態では、シミュレーションを行なって、ユーザに与える印象を同じレベルに維持しながら許容される接続障害の増加割合を推定する。これらのシミュレーションによって、接続障害の増加割合を、システム容量の増加割合に基づいて推定する。例えば、システム容量が１０％だけ増える場合、シミュレーションでは、ＲＦ障害確率が約２〜３％だけ増えるものとして定義することができる。本実施形態では通知を行なうので、ユーザは３％の接続障害増加を許容する可能性がある。従って、作業能力の観点から、シミュレーションによって約１０％の容量増加を決定することができる。ＲＦ障害確率と容量増加との比はシステム、システムのコンポーネント、通信可能エリアにおける干渉の大きさ、及び他のこのような要素によって変わる。しかしながら、シミュレーションでは、これらのパラメータを考慮に入れ、そして容量負荷の正確な推定を行なおうとする。
【００５８】
本実施形態はユーザに与える印象を、同じシステム容量及び／又はシステム容量の増加によって良くする。追加する形で、そして／または別の構成として、本実施形態によってユーザは接続障害の増加を許容するのでシステムはシステム容量を増やすことができる（例えば、システムは、ユーザが１％ではなく５％の接続障害を許容する場合、１．２５倍までの大きさの負荷に耐えることができる）。
【００５９】
本実施形態は更に、或る形態においては、通信リンク障害が検出されるとネットワークリソースを解除することができる。ＲＡＮ及び／又はＰＣＦは通知をリモートユーザに転送することができ、更にＭＳＣ、サーバ、及び／又は他のシステムコントローラ及びコンポーネントに通知を行なうことができる。ＭＳＣ及び／又はサーバはネットワークリソースの解除を開始することができる。システムのＭＳＣ及び／又は他のコンポーネントに通知を行なうことによって、リソースを、或る形態では、通知を行なわない場合にリソースが開放されるよりも迅速に開放することができる。従って、開放されたシステムリソースを他の通信に利用することができる。更に、これまでのシステムは通常、切断されなかったユーザに関するユーザデータ（例えば、オーディオデータ）のアップロードを継続していた。このアップロードデータは通常、特にデータが一時的に保存されることがない（例えば、即座に送信される）場合に単純に消去される。
【００６０】
或る実施形態では別の構成として、授受データ（音声またはデータに関係なく）を一時的に保存する、または保存する。保存されるデータの量はどのような数のパラメータによっても定義することができ、パラメータとして、これらには制限されないが、或るユーザが会話を中止する場合に第２ユーザから確認または受領通知を受け取るまでの期間、及び他のこのようなパラメータを挙げることができる。第１ユーザが会話しており、かつ通信の他のユーザが接続障害に会っている場合、第１ユーザは、通知を受信するまで、そして／または通知を受信した後に会話を続ける恐れがある。一時的な保存によって同様にして、この通信データの或る部分を、または全てを保存することができる。或る実施形態では、システムはこの保存データを第２ユーザに後の時点で、そして／または異なる無線周波数技術を使用して、または他の通信媒体を通して転送することができる（例えば、音声付ｅｍａｉｌとして送信されるボイスメール、または別の手段を使用して）。
【００６１】
更に、会話中の第１ユーザが接続障害にあう場合、一時保存データを保存することができる。この保存データは接続障害に会ったユーザ、及び／又は他のユーザが後の時点で取り出すことができるので、ユーザ（群）は、会話中に障害が発生した時点、及びどの情報が送信され、そしてどの情報が送信されなかったかについて特定することができる。
【００６２】
本実施形態では、バッチ接続またはデータ通信以外の他のタイプの通信に関する接続障害の通知が行なわれる。例えば、或る実施形態では、追加する形で、そして／または別の構成として、障害に会っている当事者についての通知を無線相互接続の間に、または標準の双方向音声通信の間に行なう。或る音声相互接続を使用することによってデータを送受信することもできるが、主として、音声経路によって２人以上のユーザの間で、セルラー通信などのような音声通信が可能になる。
【００６３】
上に説明したように、或る無線デバイスは、これらのデバイス自体の接続障害を検出することができる。従って、これらの無線デバイスはローカルユーザに障害を通知することができる。例えば、第１無線デバイスは第２無線通信デバイスと無線通信することができる。第１無線デバイスが基地局との通信リンク（例えば、ＲＦリンク）の障害を検出する場合、第１無線デバイスはビープ音を生成して第１無線デバイスのローカルユーザに、無線リンクに障害が発生したことを通知する。しかしながら、第１無線デバイス及び無線通信システムは、通信に参加している第２無線デバイスに対する通知を行なう、または通知を開始する機能を持たない。
【００６４】
第２ユーザは障害に気付かない。従って、第２ユーザは通常、会話を続ける、そして／または第１ユーザからの更に別のコメントを待つ。第２ユーザは、第１ユーザが何故会話しなくなったのかについて知ることがないので、第２ユーザは、第１ユーザがもはや接続状態にはなっていないと判断する前に長い時間に渡って待つ恐れがある。更に、第２ユーザは、何故第１ユーザが切断されたのかについて知ることがない。この待つ状態は、大きな時間の無駄であり、かつユーザを特に不快にする。更に、第２ユーザの接続を維持するためのリソースは、他のユーザが利用することができたであろうと考えられる、無駄になる貴重なリソースである。接続障害が生じているかどうかが判別し難いという不明瞭さは、障害が発生している無線デバイスのユーザがスピーカホンを使用している場合に特に顕著になる。
【００６５】
本実施形態では、リンク障害を第１無線通信デバイスによって検出し、そして第１無線デバイスに無線リンク障害が発生しているという通知を一つ以上の他の通信デバイスに対して行なう。この通知によって、他のユーザ（群）が第１ユーザのために待って無駄に浪費する時間を大幅に減らす、そして／または他のユーザ（群）が時間を無駄に浪費する現象を回避することができる。更に、或る実施形態では、一旦、通知が他のユーザ（群）に転送されてしまうと、通信システムリソースが解除され、これらのリソースが他の通信に対して開放される。更に、他の通信デバイスの内の一つ以上のデバイスを遮断し、そして／または一つ以上のデバイスに指示して半休止状態またはＲＳＣＩ状態にして電力を節約することができる。
【００６６】
図６は音声通信を音声経路を通して提供する通信システムまたはネットワーク６１０の簡易ブロック図を示している。第１無線デバイス６２２は無線リンク６１２を通してＲＡＮ６３４の第１基地局またはＢＴＳ６３０と無線通信する。第１ＲＡＮは更に、第１ＭＳＣ６３６との接続を行なう。
【００６７】
第１ＭＳＣ６３６は通信チャネルを、通常ＰＳＴＮ６５２を通して一つ以上の無線デバイス６７２、及び／又は他の有線デバイス６２６との間で確立する。例えば、第１ＭＳＣは第２ＭＳＣ６６０との接続をＰＳＴＮ６５２を通して行なうことができる。第２ＭＳＣ６６０は、第２ＢＴＳ６６４を含む第２ＲＡＮ６６２との接続を行なう。ＢＴＳ６６４は第２無線リンク６７０を通して第２無線デバイス６７２と無線通信する。
【００６８】
図７は、本実施形態を用いない音声通信システムによる通信システムのコンポーネント間の信号授受の様子を表わす時系列論理フロー７１０の簡易図を示している。まず、ステップ７２０では、第１ＭＳのような第１無線デバイス６２２と、ＢＴＳ６３０のような送信機との間で、無線通信リンクに障害が発生し、そして／または無線通信リンクが切断される。第１ＭＳ６２２との通信リンク６１２に接続されるローカルＲＡＮ６３４またはローカルＭＳＣ６３６が障害をステップ７２２で検出する。ＭＳＣはステップ７２４で、第２ＭＳのような第２通信デバイス６７２への通信経路及び／又はチャネルの解除を指示する。第２ＭＳには通知が行なわれず、そして第２ＭＳは第１ＭＳとの接続に障害が発生していることを長時間７４０に渡って気付かない。これにより、第２ユーザは無駄な時間を浪費する。
【００６９】
図８は、音声通信経路を提供し、かつ本実施形態に従って無線リンク障害の通知を行なうシステム６１０のような通信システムのコンポーネント間の信号授受の様子を表わす時系列論理フロー８１０の簡易図を示している。ステップ８２０では、第１ＭＳ６２２とＢＴＳ６３０との間で、無線通信リンクに障害が発生し、そして／または無線通信リンクが切断される。第１ＭＳ６２２との通信リンク６１２に接続されるローカルＲＡＮ６３４またはローカルＭＳＣ６３６が障害をステップ８２２で検出する。ＭＳＣまたはＲＡＮはステップ８２４で、通知を生成し、そして当該通知を、リンク障害が発生している第２ＭＳ６７２との通信に載せる。ステップ８２６では、第２ユーザは通知を受信する。通知は、第２ＭＳに転送されるトーンまたは他の音声通知、第２ＭＳにトーンを鳴動させる命令、または他のこのような通知とすることができる。通知を通知先との通信に載せた後、ＭＳＣは命令をステップ８３０において発行して、第２ＭＳへの通信経路及び／又はチャネルを解除する。通知が早期に行なわれるので、第２ユーザはユーザ自身のかなり長い時間８４０を節約することができる。例えば、通知が行なわれない場合には、ユーザは接続障害に気付かず、そして５〜１０秒、またはそれ以上の時間に渡ってそのままの状態を継続する、そして／または接続状態であるとして会話を継続する恐れがある。別の構成として、或る実施形態では、残りの一人以上のユーザに対する障害発生通知を１秒未満で生成する。これにより、ユーザは長い時間を節約することができ、かつユーザの不快感が軽減される。
【００７０】
本実施形態では、通常、ＲＡＮ６３４及び／又はＰＣＦは無線通信デバイス（例えば、通信デバイス６２２）との無線リンクに障害が発生していることを検出する。ＲＡＮはＭＳＣ６３６にリンク障害を通知する。或る実施形態では、ＲＡＮは通知を生成し、そして当該通知を第２通信デバイス（例えば、通信デバイス６７２）との通信に載せる。ＭＳＣは、ＲＡＮが通知を転送した後に、第２通信デバイスとの通信チャネルを解除する。或る実施形態では、ＲＡＮが通知を転送した後に、ＲＡＮがＭＳＣにリンク障害を通知する。一例として、ＭＳＣは通常、トランク（無線通信路）解除を約１．５秒の内に行なうことができる。通知は通常、約０．２秒の内に生成し、そして転送する（ＲＡＮまたはＭＳＣによって）ことができる。従って、通知は、通信トランクが解除される前の約１．３秒の時点で第２デバイスによって受信される。従って、本実施形態においては、ユーザが通信チャネルの解除に気付くことができる例ではユーザは少なくとも約１．３秒だけ節約することができ、そして通常、ユーザは非常に長い時間（例えば、或る例では５秒以上）を節約することができる、というのは、ユーザは通常、チャネルが解除されてしまっていることを検出する手段を持たず、そして接続不能状態で会話を継続する恐れがあるからである。
【００７１】
図９は、サービス提供ＰＣＦまたはローカルＰＣＦが障害発生ユーザに関する通知を行なう場合、音声通信を音声通信経路を通して提供するシステム６１０のコンポーネント間の通信の論理的なフロー９１０の簡易図を示している。プロセス９１０では、第１ＭＳＣ６３６は接続障害に関する通知を生成し、そして転送する。ステップ９２０では、第１ローカルＲＡＮ６３４は、ＢＴＳと第１ＭＳ６２２との間の無線リンク６１２に障害が発生していることを検出する。ステップ９２２では、第１ローカルＲＡＮは解除命令を第１ＭＳに発行する。ステップ９２４では、第１ＲＡＮはクリア要求を第１ローカルＭＳＣ６３６に発行する。ステップ９２６では、第１ＭＳＣはクリアコマンドを返す形で送出する。
【００７２】
ステップ９３０では、第１ローカルＭＳＣ６３６は、第１ＭＳに接続障害が発生したという通知を生成し、そして当該通知を第２リモートＭＳ６７２との通信に載せる。この時点で、第２ユーザは第１ユーザが障害に会っていることを認識し、そして第１ユーザが接続状態になっているかどうかについて判断するためにこれ以上待つ必要がない。
【００７３】
第１ＭＳＣは更に、統合サービスデジタルネットワーク（ＩＳＤＮ）ユーザ部プロトコル（ＩＳＵＰ）リクエストをステップ９３２において発行してＰＳＴＮ６５２との通信チャネルを解除する。ステップ９３４では、ＰＳＴＮはＩＳＵＰ解除リクエストを第２リモートＭＳＣ６６０に転送する。第２ＭＳＣはクリアコマンドを作成し、そして当該クリアコマンドをステップ９３６において第２リモートＲＡＮ６６２に転送する。ステップ９４０では、第２ＲＡＮは解除命令を第２ＭＳ６７２に転送して無線リンク６７０を解除する。ステップ９４２では、第２ＭＳは解除命令を確認した旨を返送する。ステップ９４４では、第２ＲＡＮはクリア完了通知を第２ＭＳＣに転送する。
【００７４】
或る実施形態では、プロセス９１０は更に別の任意のステップ９５０を含むことができ、このステップはステップ９４２及び解除命令の確認の前に行なわれる。ステップ９５０では、第２ＭＳは通信を一つ以上のサーバ（例えば、サーバ６５０）に転送して、サーバに、第１ＭＳに接続障害が発生していることを通知する。これにより、サーバはリソースを解除し、そしてトランザクション統計を記録する（例えば、通信時間に対する課金の停止）ことができる。音声経路を通しての通信が行なわれる場合、ＲＡＮ及び／又はＭＳＣがサーバにリンク障害を通知することが困難である場合が多い。しかしながら、エンドポイント（すなわち、ＭＳ群）は普通、接続障害に気付いている、または気付くようになる。これらのエンドポイントは同じ通信グループに属し、通信を互いに送受する。その結果、第２ＭＳは、オーバーヘッドを追加することなくサーバへの通知を開始することができる。
【００７５】
任意のステップ９５０は多くの状況において利点をもたらすことができる。例えば、グループコールが行なわれていて、話し手ユーザの音声経路に障害（ＲＦ障害）が発生する場合、サーバは話し手ユーザが接続状態ではなくなっていることを認識しない。ステップ９４０では、コンファレンスコールに参加している他の通信デバイスの内の一つ以上のデバイス（例えば、６７２及び／又は６２６）には、話し手ユーザの音声経路に障害が発生していることが通知される。ステップ９５０により、一つ以上の他の通信デバイスはサーバに通知することができるので、サーバはリソースを解除する、そして／または制御を他のユーザに対して開放することができる。
【００７６】
或る別の実施形態では、ローカルＲＡＮ６３４は、無線リンク障害が発生している第１無線デバイスとの通信に参加している一人以上の他の当事者に対する通知を生成する。図１０は、サービス提供ＲＡＮまたはローカルＲＡＮが障害発生ユーザに関する通知を行なう場合、音声通信を音声通信経路を通して提供するシステム６１０のコンポーネント間の通信の論理的なフロー１０１０の簡易図を示している。ステップ１０２０では、第１ローカルＲＡＮは第１ＭＳ６２２との無線リンク６１２に障害が発生していることを検出する。ステップ１０２２では、第１ＲＡＮは解除命令を第１ＭＳに発行する。ステップ１０２４では、第１ローカルＲＡＮ６３４は通知を生成し、そして当該通知を第２リモートＭＳ６７２に転送する。この時点で、第２ユーザは第１ＭＳの障害に気付き、障害が発生している無線との接続を継続しない。
【００７７】
ステップ１０２６では、第１ＲＡＮはクリアリクエストを第１ローカルＭＳＣ６３６に発行する。ステップ１０３０では、第１ＭＳＣはクリアコマンドを返す形で送出する。ステップ１０３２では、第１ローカルＭＳＣ６３６はＩＳＵＰリクエストを生成してＰＳＴＮ６５０との通信チャネルを解除する。ＰＳＴＮはＩＳＵＰ解除リクエストをステップ１０３４において第２リモートＭＳＣ６６０に転送する。ステップ１０３６では、第２ＭＳＣはクリアコマンドを第２リモートＲＡＮ６６２に転送する。ステップ１０４０では、第２ＲＡＮは解除コマンドを第２ＭＳ６７２に発行して無線リンク６７０を解除する。ステップ１０４２では、第２ＭＳは解除命令を確認した旨の返事を出す。ステップ１０４４では、第２ＲＡＮはクリア完了通知を第２ＭＳＣに転送する。
【００７８】
プロセス１０１０の実施形態では、ステップ１０２６及び１０３０のそれぞれにおける、第１ＲＡＮと第１ＭＳＣとの間におけるクリアリクエスト及びクリアコマンドの作成に関連する遅延を防止する。従って、或る実施形態では、プロセス１０１０を実施して、第２ユーザが障害が発生しているリンクと通信する恐れのある時間の量を更に減らすことができる。
【００７９】
本実施形態は、ユーザに与える印象を平均的に良くし、そして／またはネットワーク容量を増やすことができるという利点をもたらす。ユーザに接続障害を通知することにより、ユーザの不快感を軽減し、かつユーザに与える印象を良くすることができる。更に、不快感が軽減されるので、ユーザは接続障害の回数が増えても我慢できる可能性が高くなる。その結果、本発明による或るシステムによって、ユーザの満足度を維持し続けながらシステム容量を増やすことができる。例えば、或る実施形態では、システムは、ユーザが約１％までの割合だけ増える接続障害（例えば、接続障害が２％から３％に増える場合）を我慢できる場合、約１．１倍までの大きさの負荷に耐えることができる。
【００８０】
更に、システムは接続障害を検出するので、或る実施形態ではシステムリソースの使用を短い時間の内に終了させる。システムリソースを解除することにより、これらのリソースが他の接続に対して開放されるので、システム容量を増やすことができる。
【００８１】
図１１は、システムまたはネットワークが本実施形態を実行して無線リンク障害を検出し、そして一人以上の他のユーザに障害を通知するかどうかを判断するために使用されるプロセス１１１０の簡易フロー図を示している。ステップ１１２０では、通信が第１無線デバイスと少なくとも一つの第２デバイス（無線または有線）との間で開始される。通信はディスパッチ通信（例えば、ＰＰＴ通信、ボイスオーバーＩＰ通信、及び他のこのようなディスパッチ通信）または音声通信（例えば、携帯電話音声通話）とすることができる。ステップ１１２２では、プロセスによって第１デバイスとの無線通信リンクに障害を発生させる。例えば、信号経路を切断する、無線デバイスにＲＦ障害を発生させる、無線デバイスへの電源を切断する（バッテリ故障）、そして／または他のこのような原因の接続障害を発生させることができる。
【００８２】
ステップ１１２４では、第２通信デバイスへの命令及び／又は通信がモニタリングされる。ステップ１１２６では、第２デバイスが障害発生通知を受信するかどうかが判断される。通知が検出されない場合、プロセスは終了する。或る実施形態では、通知が検出されない場合、任意であるがプロセスはステップ１１３２に進む。通知が検出される場合、ステップ１１３０に進み、このステップにおいて、プロセスはシステムが本実施形態を用いているとして認識する。
【００８３】
或る実施形態では、任意のステップ１１３２を取り入れ、このステップにおいて、システムが第２通信デバイスに関する接続解除命令を生成するかどうかを判断する。解除命令が受信されない場合、プロセスは終了する。解除命令が受信される場合、プロセスはシステムが本実施形態を用いているとして認識する。或る実施形態では、接続解除命令が検出された旨を所定期間内に受信してプロセスに、システムが本実施形態を用いていることを通知させるようにする。
【００８４】
或る実施形態では、プロセス１１１０は更に、第２通信を第１デバイスと第２デバイスとの間で開始する。次に、通信は、第１デバイスが正常な終了を行なうことにより終了させることができる（例えば、第１デバイスの受話器が正常に下ろされる）。次に、プロセスは第２通信デバイスをモニタリングして、終了が異なっているかどうか、そして／または第２デバイスが通知を受信するかどうかについて判断する。
【００８５】
或る実施形態では、別のユーザが接続障害にあう、または意図的に接続を切断する（例えば、受話器を下ろす）場合に、通知を更に一人以上のユーザに転送することができる。ユーザが意図的に接続を切断する場合の通知は、接続障害が検出される場合に転送される通知とは異なる通知とすることができる。例えば、意図的な切断に関する通知は、異なるトーン、異なる音声メッセージ、異なるテキストメッセージ表示、及び／又は他のこのような通知、或いは通知の組合せとすることができる。
【００８６】
容量が増えることにより更に、システム及び／又は通信サービスプロバイダは収入を増加させることができる。システム容量が増えることにより、接続障害の回数を増やしてもよいことになる。本実施形態によって可能になる早期通知及びリソースの早期解除に起因して、従量課金することができなくなることによる損失は、システム容量及び／又はユーザ満足度が大きくなり、顧客の増大につながることにより得られる利益に比べると微々たるものである。例えば、バッチ接続（例えば、ＰＴＴ通信）を行なうシステム容量が２５％だけ増加すると、接続障害または接続切断の増加は約２％としてもよいことになる。ＰＴＴ送信の平均所要時間は約５秒以内である。上に議論したように、障害に会っていない当事者への通知によって、ユーザがシステムにおいて消費する時間が約３秒だけ短くなるので、接続障害１回当たり３秒の時間だけ課金することができないことによる損失が生じる。３秒の時間だけ課金することができないことによる損失は収入の約１％の減少にしか相当しない（（２％＊〜３）／５＝〜１％）。別の構成として、本実施形態によって、或る実施形態では、システム容量を２５％だけ大きくすることができる。従って、システム容量の２５％の増加は、従量課金することができないことによる約１％の損失よりもずっと大きい利益をもたらす。
【００８７】
本明細書に開示される本発明について、本発明の特定の実施形態及び適用形態を用いて説明してきたが、この技術分野の当業者であれば、多数の変形及び変更を本発明に、請求項に示される本発明の技術範囲から逸脱しない範囲において加え得るであろう。
【図面の簡単な説明】
【００８８】
【図１】或る実施形態による通信システムまたはネットワークの簡易ブロック図を示す。
【図２】図１のシステムのコンポーネント間の通信における論理フローを表わす簡易図を示す。
【図３】図２のプロセスにおける通知ステップに関する或る実施形態による通信における論理フローを表わす詳細図を示す。
【図４】無線周波数（ＲＦ）リンク障害がパケットプロトコル機能（ＰＶＦ）によって検出され、そしてＰＣＦが通知を生成する構成の或る実施形態によるプロセスの簡易フロー図を示す。
【図５】グループ通信の一人以上の当事者が障害に会っていることを検出し、そしてグループ通信に参加している一人以上の他の当事者に通知を行なうプロセスの簡易フロー図を示す。
【図６】音声通信を音声経路を通して提供する通信システムまたはネットワークの簡易ブロック図を示す。
【図７】本実施形態を用いない音声通信システムによる通信システムのコンポーネント間の信号授受の論理フローを時系列で表わす簡易図を示す。
【図８】本実施形態による、無線リンク障害の通知を行なう通信システムのコンポーネント間の信号授受の論理フローを時系列で表わす簡易図を示す。
【図９】図６のシステムのようなシステムのコンポーネント間の通信における論理フローを表わす簡易図を示し、システムが、モバイルスイッチングセンタ（ＭＳＣ）が無線リンク障害の通知を行なう音声通信経路を通して音声通信を提供する様子を示している。
【図１０】図６のシステムのようなシステムのコンポーネント間の通信における論理フロー１０１０を表わす簡易図を示し、システムが、無線接続ネットワーク（ＲＡＮ）が無線リンク障害の通知を行なう音声通信経路を通して音声通信を提供する様子を示している。
【図１１】システムまたはネットワークが本実施形態を使用して無線リンク障害を検出し、そして一人以上の他のユーザに障害を通知するかどうかを判断するために使用されるプロセスの簡易フロー図を示す。
【図１】
2008508795.tif 000003
【図２】
2008508795.tif 000004
【図３】
2008508795.tif 000005
【図４】
2008508795.tif 000006
【図５】
2008508795.tif 000007
【図６】
2008508795.tif 000008
【図７】
2008508795.tif 000009
【図８】
2008508795.tif 000010
【図９】
2008508795.tif 000011
【図１０】
2008508795.tif 000012
【図１１】
2008508795.tif 000013
【国際調査報告】
2008508795.tif 000014