JP3948403B2 - 遠距離通信システムのための順方向リンクベース救済チャンネル方法および装置 - Google Patents
遠距離通信システムのための順方向リンクベース救済チャンネル方法および装置 Download PDFInfo
- Publication number
- JP3948403B2 JP3948403B2 JP2002536850A JP2002536850A JP3948403B2 JP 3948403 B2 JP3948403 B2 JP 3948403B2 JP 2002536850 A JP2002536850 A JP 2002536850A JP 2002536850 A JP2002536850 A JP 2002536850A JP 3948403 B2 JP3948403 B2 JP 3948403B2
- Authority
- JP
- Japan
- Prior art keywords
- sectors
- network
- mobile station
- potential failed
- failed connection
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W16/00—Network planning, e.g. coverage or traffic planning tools; Network deployment, e.g. resource partitioning or cells structures
- H04W16/02—Resource partitioning among network components, e.g. reuse partitioning
- H04W16/06—Hybrid resource partitioning, e.g. channel borrowing
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Mobile Radio Communication Systems (AREA)
Description
（関連出願に対するクロスリファレンス）
本発明の実施態様は、２０００年１０月１７日に出願された米国仮特許出願第６０／２４１，２６８号の「Forward Rescue Procedure (順方向救済手続き)」および２０００年１１月１４日に出願された米国仮特許出願第６０／２４８，９００号の「Improvement to Rescue Channels Using Dynamic Active Set During Rescue （救済の間における動的アクティブセットを使用する救済チャンネルに対する改良）」からの優先権を主張するものであり、その内容が、あらゆる目的に関して、参照によりここに援用される。
【０００１】
（発明の分野）
本発明は、通信ネットワーク管理に関し、特に、一実施態様においては、セルラまたはＰＣＳ電話等の移動局と、無線通信基盤（ネットワーク）の間の、信号落ちならびに接続の打ち切りを防止するための方法および装置に関する。
【０００２】
（関連技術の説明）
（序論）
緊急通信のための手段を単に提供するというより、セルラ電話は、急速に、今日的社会における通信の主要な形態になりつつある。セルラ電話の使用が普及するに従って、セルラ電話ネットワークがますます優勢になり、消費者の要求を満たすべく、より大きなエリアにわたる利用範囲を提供するようになっている。図１は、無線セクタＡ１４およびＢ１６を伴う第１の基地局（ＢＳ）１２、およびセクタＣ２０を伴う第２のＢＳ１８を含む無線通信基盤またはネットワークによってサービスされる地理的エリア内を動き回るモバイルユーザによって操作される移動局（ＭＳ）１０の例を図示している。そのような動き回りの中で、ＭＳ１０は、位置Ａから位置Ｂへ、さらに位置Ｃへと移動し、当然のことながら、コンタクトしているＢＳ（１ないしは複数）に関連付けされている順方向リンクの信号強度ならびに信号品質における変動を経験することになる。信号の強度ならびに品質は、たとえばＭＳ１０がセクタＡ１４の破線によって画定されるエリアからセクタＢ１６の破線によって画定されるエリアへ、あるいはセクタＢ１６からセクタＣ２０へ移動するときのように、セクタの境界近傍では特に信頼性の低いものとなることがある。接続の打ち切りは、この種の遷移エリアをはじめ、そのほかの信号強度の弱い、もしくは品質の低いエリアにおいて生じやすい。なお、ここで述べられている接続には、限定する意図ではないが、音声、マルチメディアビデオまたはオーディオのストリーミング、パケット交換データおよび回路交換データ接続、ショートメッセージシーケンスまたはデータバースト、およびページングが含まれる。
【０００３】
接続の打ち切りは、セルラ電話ユーザが単に困る程度のものから大きな打撃を与えるものまで広い範囲にわたる可能性がある。たとえば、緊急の９１１接続が打ち切られた場合、それは、決定的、さらには致命的となることさえある。接続の打ち切りは、サービスプロバイダを変更させる充分ないらだちを消費者にもたらすこともある。したがって、接続の打ち切りを防止することは、セルラネットワークプロバイダにとっての主要な重要課題である。
【０００４】
（セルラ電話ネットワーク）
図２は、ＭＳ２４とＢＳ２６の間における一例の通信リンク２２を表している。ＢＳ２６からＭＳ２４への通信は順方向リンクと呼ばれ、ＭＳ２４からＢＳ２６への通信は逆方向リンクと呼ばれる。ＢＳ２６は、通常、複数のセクタを包含し、一般にはそれが３個である。各セクタは、個別の送信機および、それぞれが異なる方向を指向するアンテナ（トランシーバ）を含む。ＢＳという用語が、しばしば、広くトランシーバと同義に使用されることから、ここでは用語ＢＳおよびセクタがある意味で相互交換可能に使用されることを理解する必要がある。順方向および逆方向のリンクは、多数の順方向および逆方向のチャンネルを使用する。たとえば、ＢＳ２６は、複数の順方向チャンネル上において一斉送信を行う。これらの順方向チャンネルには、限定する意図ではないが、１ないしは複数のパイロットチャンネル、同期チャンネル、１ないしは複数のページングチャンネル、複数の順方向トラフィックチャンネルを含めることができる。パイロット、同期、およびページングチャンネルは、ＢＳ２６がすべてのＭＳに対する通信にそれらのチャンネルを使用することから共通チャンネルと呼ばれている。概して、これらの共通チャンネルは、データの搬送には使用されず、一斉送信ならびに共通情報の配信に使用される。これに対して、複数存在する順方向トラフィックチャンネルは、各順方向トラフィックチャンネルが特定のＭＳ２４に向けられていることから専用チャンネルと呼ばれており、データを搬送することができる。
【０００５】
ＢＳ２６内の各セクタは、そのセクタを識別し、かつＭＳ２４が容易にデコードできるパイロットチャンネルを一斉送信する。セクタおよびパイロットチャンネルは、いずれも擬似ノイズ（ＰＮ）オフセットによって区別される。用語「パイロット」は、パイロットチャンネルがセクタを識別することから、用語「セクタ」とほとんど相互交換可能に使用される。
【０００６】
パイロットチャンネルは、ＭＳに対して黙示的にタイミング情報を提供し、コヒーレントな復調にそれが使用されるが、そのほかは通常、いかなるデータも含んでいない。ＭＳは、最初に立ち上げられたとき、パイロットチャンネルのサーチを開始する。ＭＳがパイロットチャンネルを獲得すると（それが復調できると）、パイロットチャンネル内の黙示的なタイミング情報によってＭＳは、迅速かつ容易に、ネットワークによって送信されている同期チャンネルを復調することができる。
【０００７】
同期チャンネルには、より詳細なタイミング情報が含まれていることから、ＭＳが同期チャンネルを獲得した後は、ＭＳは、パイロットチャンネルを送信している同一のＢＳによって送信されているページングチャンネルを獲得することができる。その種のＢＳは、アクティブＢＳと呼ばれる。
【０００８】
セルラネットワークが特定のＢＳを介してＭＳとの通信の開始を試みているとき、そのＢＳのページングチャンネル上において、そのＭＳに対して「ページ」が送信される。従って、ＭＳが、一旦、特定のＢＳのページングチャンネルを復調できるようになった後は、そのＭＳがアイドル状態にあり、到来接続または到来メッセージを待機している間、そのページングチャンネルをモニタすることができる。
【０００９】
概して、各ＢＳは、すべてのＭＳが共通に受信する、１つのパイロットチャンネル、１つの同期チャンネル、および１つのページングチャンネルを使用する。しかしながら、１つのページングチャンネルを使用して同時にページング可能なＭＳの数に実用上の制限があることから、中には複数のページングチャンネルを使用するＢＳもある。
【００１０】
逆方向チャンネルは、アクセスチャンネル、１ないしは複数の逆方向トラフィックチャンネルを含むことができる。ＭＳが到来「ページ」をＢＳから受信した後は、ＭＳは、一部においてアクセスチャンネルを使用して接続のセットアップを開始することになる。
【００１１】
前述したチャンネルは、各種のコード化の手法を使用することができる。時分割多元アクセス（ＴＤＭＡ）では、複数のチャンネルが一定の時間ウインドウ内において特定の周波数で通信されることが可能であり、そのウインドウ内の異なるタイミングを用いてそれらが送信される。つまり、たとえばチャンネルＸは、時間スロットの１セットを使用し、チャンネルＹは、時間スロットの別のセットを使用する。周波数分割多元アクセス（ＦＤＭＡ）では、一定の周波数ウインドウ内において特定の時間に複数のチャンネルが通信されることが可能であり、そのウインドウ内の異なる周波数を用いてそれらが送信される。符号分割多元アクセス（ＣＤＭＡ）では、周波数および時間の空間が与えられ、特定のウォルシュコードまたは擬似直交関数（ＱＯＦ）に従って各チャンネルに各種の周波数および各種の時間が割り当てられる。このコードは、特定のチャンネルが周波数および時間に関してどのように変化するかを定義することになる。ダイレクトシーケンスＣＤＭＡにおいては、各チャンネルからのデータがウォルシュコードまたはＱＯＦを使用してコード化され、その後、１つの合成信号に組み合わせられる。この合成信号が、特定の時間において広い周波数範囲にわたって拡散される。この合成信号を、オリジナルデータのコード化に用いられたのと同一のコードを使用してデコードすれば、オリジナルデータを抽出することができる。ウォルシュコードおよびＱＯＦは、組み合わされた時に互いに干渉しないコード化データを生成し、その結果、後の時点において各種のチャンネル上でその情報を回復するようにデータを拡散することができるので、このようなオリジナルデータの回復が可能になる。言い換えると、データの２つのコード化済みシーケンスが互いに加算されて第３のシーケンスを生成するとき、その第３のシーケンスをオリジナルのコードと相関させることによって、オリジナルのシーケンスを回復することができる。特定のコードを用いて復調するときは、ほかのコードの知識が必要とはならない。しかしながらノイズおよび混信によって、何が実際に送信されたかについての決定を行うためにエラー修正が必要となることがある。
【００１２】
例示のみを目的としてさらにＣＤＭＡについて述べると、ウォルシュコードまたはＱＯＦは、特定のチャンネルのコード化に使用される。したがって、前述したように、パイロットチャンネルをデコードするための単純な形は、すべてが１にコード化されたＷ０ウォルシュコードとすることができる。同様に、同期チャンネルは、交番極性のＷ３２ウォルシュコードを使用することが可能であり、これらのコードは一定かつ既知である。
【００１３】
各ＭＳは、チャンネルを各種のセットにグループ化し、それには、限定を意図するわけではないが、アクティブセット、近隣セット、候補セット、および残余セットを含むことができる。
【００１４】
ＭＳアクティブセットは、任意の時点においてＭＳが使用しているパイロットまたはＰＮオフセット識別子を含んでいる。すなわち、ＭＳがアイドル状態にあるが、ページングおよびオーバーヘッドの更新のために単一のＢＳをモニタしているとき、そのＭＳに関するアクティブセットは、その唯一のメンバとしてそのＢＳのパイロットまたはＰＮオフセット識別子を含むことになる。
【００１５】
しかしながら、ＭＳが１つのＢＳまたはセクタからほかへハンドオフされている時、このハンドオフの間は、同時に複数のＢＳまたはセクタと実際に通信していることがある。このような状況が生じると、アクティブセット内に、同時に複数のアクティブパイロットが存在することになる。たとえば、「ソフトハンドオフ」においては、ＢＳ「Ａ」と通信しているＭＳが、最初にＢＳ「Ａ」を削除することなくＢＳ「Ｂ」との通信を開始し、その結果としてＢＳ「Ａ」およびＢＳ「Ｂ」がともにアクティブセット内に存在することになる。「ソフターハンドオフ」においては、ＢＳ「Ａ」内のセクタ「Ａ」と通信しているＭＳが、最初にセクタ「Ａ」を削除することなくＢＳ「Ａ」内のセクタ「Ｂ」との通信を開始し、その結果としてセクタ「Ａ」およびセクタ「Ｂ」がともにアクティブセット内に存在することになる。しかしながら、「ハードハンドオフ」においては、ＢＳ「Ａ」と通信しているＭＳが、最初にＢＳ「Ａ」を削除した後に限ってＢＳ「Ｂ」との通信を開始し、その結果として任意の時点においてアクティブセット内には、ＢＳ「Ａ」または「Ｂ」のいずれかが存在し、両方ともに存在することはない。
【００１６】
ＭＳが複数のＢＳと通信を行っている間は、そのＭＳがレーキ受信機のフィンガを１ないしは複数のセクタからの複数のチャンネルに同時に割り当てる。ＭＳが同時に複数のＢＳと通信を行っているときは、ＭＳは、それらのＢＳのそれぞれから同一のデータを受信している必要がある。しかしながら、データが同一であっても、チャンネルが異なるために、異なるＢＳからそれが異なって伝達される可能性もある。そのためレーキ受信機は、異なるチャンネル上において異なるセクタからのエンコード済みデータを受信し、それらのセクタを独立に復調し、その後それらのデータを結合する。データが結合されるときには、弱いチャンネルからのデータ、すなわちより多くのエラーを有する可能性のあるデータより、強いチャンネルからのデータに、より重い重み付けがなされる。このように、最終結果の生成においては、正しいとする公算がより高いデータに対して、より高い重み付けが与えられる。
【００１７】
ＭＳがアイドル状態の間は、共通チャンネル上において、アクティブＢＳの近隣となるＢＳを含む近隣セットがそのＭＳによって受信される。しかしながら、ＭＳがアクティブであり、トラフィックチャンネルを介してＢＳと通信を行っているときには、トラフィックチャンネル上において近隣セットが更新される。
【００１８】
そのほかの、ネットワーク内のアクティブセット、近隣セット、または候補セット（後述）内に含まれていないＢＳは、残余セットを構成する。図３に示されているように、ＭＳがアイドルかアクティブかによらず、ネットワークは、ＭＳに対してオーバーヘッドメッセージ３０、３２、および３４を繰り返し送信する。これらのオーバーヘッドメッセージは、ネットワークの構成に関する情報を含んでいる。たとえば、拡張された近隣のリストのオーバーヘッドメッセージ３４は、ＭＳに対して、存在する近隣およびそれらを探す場所について知らせる。これらの近隣識別子は、少なくとも一時的にＭＳのメモリ内に記憶される。
【００１９】
候補セットは、ＭＳがそのアクティブセットの一部として要求したが、まだアクティブセットに昇格されていないＢＳのセットである。これらの候補ＢＳは、ネットワークが、まだＭＳからのメッセージに応答してハンドオフ指示メッセージ（ＨＤＭ）を、すなわちそのＭＳにそれらのＢＳを含めるべくアクティブセットを変更する指示を送信していないために昇格されていない。通常、その種のメッセージの交換は、後述するように、ハンドオフプロセスの一部として生じる。
【００２０】
図４は、無線通信基盤５６の一般的な構造を図示している。クライアントＭＳ３６は、継続的に、ＢＳ３８等の近隣ＢＳから受信しているパイロットチャンネルの強度をモニタし、「パイロット追加スレッショルド値」より充分に強いパイロットをサーチする。近隣パイロットチャンネル情報、つまりこの分野において「近隣セット」として知られている情報は、セルクラスタ４２をコントロールすることが可能なＢＳコントローラ（ＢＳＣ）４０あるいは移動交換センタ（ＭＳＣ）４４を含むネットワーク基盤統一体を介してＭＳに伝達することができる。ここで理解しておく必要があるが、ＭＳおよび１つもしくは複数のネットワーク基盤統一体は、ＭＳおよびネットワークの機能をコントロールするための１ないしは複数のプロセッサを備えている。これらのプロセッサは、当業者であれば熟知しているメモリおよびそのほかの周辺装置を備える。１つのＢＳ３８によってサービスされている領域から別の領域へＭＳ３６が移動するとき、ＭＳ３６は、特定のパイロットを「近隣セット」から「候補セット」に昇格させ、ＢＳ３８または複数のＢＳに対して、「パイロット強度測定メッセージ」（ＰＳＭＭ）を介して、当該特定のパイロットの「近隣セット」から「候補セット」への昇格を通知する。またこのＰＳＭＭは、受信したパイロット信号の強度に関する情報も含んでいる。ＢＳ３８は、この「パイロット強度測定メッセージ」に従ってＢＳまたはネットワークの「アクティブセット」を決定し、ＨＤＭを介して新しい「アクティブセット」をＭＳ３６に通知することができる。しかしながら、ここで注意が必要であるが、処理しなければならないＢＳリソース問題をネットワークが有していることもあるため、新しいアクティブセットは、必ずしも常にＭＳの要求に正確に応じたものになるとは限らない。
【００２１】
ＭＳ３６は、古いＢＳ３８および新しいＢＳの両者との通信を、各ＢＳのパイロットの強度が「パイロット削除スレッショルド値」を超えている限り、維持することができる。１つのパイロットがこのパイロット削除スレッショルド値より弱くなると、ＭＳ３６は、その変化をＢＳに通知する。それによりＢＳは、新しい「アクティブセット」を決定し、ＭＳ３６に対してその新しい「アクティブセット」を通知する。ＢＳによる通知があると、ＭＳ３６は弱くなったパイロットを「近隣セット」に降格する。これは、ハンドオフのシナリオの一例である。接続が失敗したときに、ＭＳ３６がハンドオフを開始し、あるいはハンドオフのプロセスに入ることは一般的である。セルの境界近傍、パイロットの汚染のあるエリア、あるいはセルのブリージングによって著しく影響を受けているエリアには、一般にカバレッジが不充分かまたは信号の弱い環境が存在することからこの種のことが予測され、それらについてはすべて、この分野においてよく知られている。
【００２２】
接続の打ち切りは、いくつかの形で明らかになる。図５は、この分野においてＣＤＭＡ無線ネットワークに関する「レイヤ２確認応答障害」として知られる状況を示している。図５に示した例においては、ＭＳがＰＳＭＭ４８を送信してＢＳによる確認応答を要求している。ＢＳは、それを正確に受信できているが、図５に示したケースにおいては、そのＢＳの確認応答（ＡＣＫ）４６をＭＳが受信していない。ＭＳは、再送信カウンタに従ってメッセージをＮ１ｍ（＝９）回再送した後、接続を終了する（打ち切る）。「レイヤ２確認応答障害」が生じたメッセージがＰＳＭＭ４８である場合、つまりＭＳが接続を維持するために必要とするパイロットに関する要求を含むメッセージである場合に、このタイプの障害が生じることは一般的である。
【００２３】
図６は、ＣＤＭＡ無線ネットワークにおいて本発明を使用して回復が可能な第２の状況を示している。この状況は、この分野においては「順方向リンクフェード障害」として知られている。フェードは、受信信号パワーの減衰の期間である。この状況では、ＭＳがＮ２ｍ（＝１２）個の連続する不良フレーム５０を受信し、それに対する応答として、その送信機５２を停止させる。その後、Ｎ３ｍ（＝２）個の連続する良好フレームを、Ｔ５ｍ（＝５）秒後にフェードタイマがタイムアウトする前までに受信できなければ、ＭＳは、接続５４を打ち切る。ＭＳがパイロットを候補セットに昇格し、ＰＳＭＭの送信を必要としている期間、あるいはＭＳがＰＳＭＭを送信したが、まだハンドオフ指示メッセージを受信していない期間に、このタイプの障害が生じることは一般的である。
【００２４】
「レイヤ２確認応答障害」および「順方向リンクフェード障害」は、過剰に高いフレームエラーレートまたは爆発的なエラーレートに起因して生じることがある。図７に図示されているように、チャンネル５８は、通常は持続時間が８０ミリ秒のスロット６０、つまりスーパーフレームに分割することができる。各スロットは、３つのフェーズ６２に分けることができる。これらのフェーズには、０、１、および２の番号が付されている。それらのフェーズの上にオーバーラップする形で４つのフレーム６４がある。これら４つのフレームは、スーパーフレームの境界で３つのフェーズとそろえられる。したがって各フレーム６４は、通常、２０ミリ秒の長さになる。各フレーム６４内には、ヘッダエリア６６、何らかの信号情報６８、およびおそらくは何らかのデータ７０が含まれている。ここで、フレーム６４が、異なる内容を持つことを理解する必要がある。あるフレームが信号およびデータを含み、別のフレームが信号のみを含み、さらに別のフレームがデータのみを含むということもある。各フレーム６４が異なるデータレートを有することも許容され、データレートは、フレームごとを基準に変更することができる。例示のいくつかの通信標準においては、４つのレートが存在する：すなわち、１／１、１／２、１／４、および１／８である。したがって、たとえば音声アクティビティがない場合には、１／８フレームレートを用いて情報を送信することができ、これは、より遅いレートを用いて情報を伝達すれば必要な電力または帯域幅がより低く抑えられることから有利である。
【００２５】
実用的な通信ネットワークにおいては、ゼロパーセントのエラーレート（つまり、すべてのフレームが適正に受信されること）を目標とすることが現実的でも、また望ましいことでもない。むしろ、たとえば１パーセントのエラーレートが目標とされる。パワーコントロールループは、実際にこのフレームエラーレートをコントロールしている。この例の場合、フレームエラーレートが上昇して１パーセントを超えると、パワーコントロールループが、ＭＳによって送信される信号のパワーを増加し、その結果、フレームエラーレートが約１パーセントまで減少する。これに対して、フレームエラーレートが１パーセントより小さい場合には、パワーコントロールループが、送信パワーを下げて電力を節約し、フレームエラーレートが１パーセントまで上昇することを許容する。したがってＢＳは、ＭＳが特定のエリア内を移動する間、あるいは他のタイプの混信が発生または終了するとき、コンフィグレーションメッセージ内のパワーコントロールビットを介して継続的に、エラーレートを約１パーセントに維持するため種々のパワーレベルにおいて送信するようにＭＳに対して指示を与える。ＭＳは、通常、ＢＳによって推奨されているパワーレベルを尊守する。それに加えて、ＢＳが、特定のチャンネルに関するその送信パワーを変更することもできる。つまり、ＢＳおよびＭＳはともに、継続的に、他方のパワーレベルを変更するために互いにフィードバックを与えることができる。しかしながら、ＢＳが、ＭＳからのフィードバックに基づいて、その送信機のパワーレベルの変更を必ずしも行う必要はない。
【００２６】
上記のパワーコントロールループにもかかわらず、セルラネットワーク内をＭＳが動き回り、物理的な障害、隣接チャンネルからの混信、およびセクタのエッジ近傍の場所に起因する信号強度ならびに信号品質における変動を経験しているときには、エラーレートを約１％にコントロールできなくなることがあり、エラーレートが許容不能なレベルに上昇すれば、接続の打ち切りが問題化する。そのため、打ち切りの危機にある接続を救済するメカニズムが必要とされている。
【００２７】
逆方向リンクを基礎とする救済手続または接続の再スタートは、以前からすでに提案されている。通常の逆方向リンクを基礎とする救済手続においては、ＭＳが救済チャンネルを送信し、その一方でネットワークが、１ないしは複数のセクタを使用して救済チャンネルの復調を試みる。しかしながら、提案されている接続の再スタートを基礎とする救済手続は、アクセスチャンネルを使用し、ＭＳがプロービングを行うことから多くの電力を必要とするだけでなく、大量の混信を導く。それに加えて、提案されている逆方向リンクを基礎とする救済手続は、順方向フェード状態の間に限って起動され、ＢＳに先行してＭＳが送信することから不完全であり、後に説明する理由から効率も低い。
【００２８】
（発明の要約）
ここでは、包括的に「順方向救済手続」（ＦＲＰ）と呼んでいる本発明の一実施態様は、セルラまたはＰＣＳ電話等のＭＳと、通信基盤またはネットワークとの間における信号落ちならびに接続の打ち切りを防止するための方法および装置に関するものである。ＦＲＰを使用して克服可能な障害シナリオの例には、順方向リンクのレイヤ２（Ｌ２）確認応答障害および、スレッショルド値を超える時間間隔にわたる信号落ちをもたらすフェードに起因する順方向リンク信号落ちが挙げられる。本発明の例として示す一実施態様は、ＭＳが、通信基盤から電波放射されている１ないしは複数のＢＳパイロットチャンネルを、打ち切りの危機にある接続を保存するために、ＭＳのアクティブセットに追加する機能を含む。このＢＳパイロットチャンネルは、「順方向リンク救済チャンネル」として知られており、ここでは「仮コードチャンネル」（ＡＣＣ）と呼ぶものとする。同時に、ネットワーク基盤が、ＦＲＰの間にＭＳによってモニタされる可能性の高い代替順方向リンクチャンネル上において送信を開始する。同じチャンネルがＭＳによってモニタされ、ネットワーク基盤によって送信に用いられるのであれば、打ち切りの危機にある接続を救済することが可能になる。このＡＣＣという用語は、特定のウォルシュコードまたは擬似直交関数によってチャンネルが定義される符号分割多元アクセス通信プロトコルへの適用にもっとも適しているが、用語ＡＣＣが、ここでの定義として、ＴＤＭＡにおける時間スロットもしくはＦＤＭＡにおける周波数スロット等の、チャンネルを定義するための任意のスキームを包含することに注意する必要がある。より詳細に述べるのであれば、符号分割多元アクセス（ＣＤＭＡ）無線通信システムにおける、本発明の実行や使用は好ましい実施態様である。ＣＤＭＡ無線通信システムは下記の標準によって十分に詳しく説明されており、その全ては TELECOMMUNICATIONS INDUSTRY ASSOCIATION, Standards & Technology Department, 2500 Wilson Blvd., Arlington, VA 22201 によって公表されており、それらの全てが参照によりここに援用される： TIA/EIA-95B (１９９９年２月１日公表)；TIA/EIA/IS-2000 ，Volumes1-5, Release A, (２０００年３月１日公表)。本発明のこのほかの実施態様は、「好ましい実施態様の詳細な説明」という項目名を付した項目に説明されている。そのほかのメッセージプロトコルならびにデータ構造および通信システムを用いて本発明の別の実施態様を実施することは、当業者にとって簡単であろう。
【００２９】
（好ましい実施態様の詳細な説明）
以下、本出願の一部をなすとともに、本発明が実用化されえる特定の実施形態を図示した添付図面を参照しつつ、好ましい実施態様についての説明を行う。ここで理解される必要があるが、本発明の好ましい実施態様の範囲から逸脱することなく、そのほかの実施態様が使用され、あるいは構造的な変更がなされることは可能である。さらに理解されたいことは、ここで述べられる説明は、説明のみを目的として基本的にＣＤＭＡ通信プロトコルに言及しているが、本発明の実施態様は、そのほかの通信プロトコルならびにディジタル無線技術に広く適用可能であるということであり、限定する意図ではないが、それにはＣＤＭＡ、ＴＤＭＡ、ＦＤＭＡ、ＧＳＭ、ＧＰＲＳ等も含まれる。
【００３０】
（順方向救済手続の要約）
本発明は、通信ネットワークにおけるＭＳと通信基盤との間の信号落ちならびに接続の打ち切りを防止するための方法および装置を包含する。ここで言う接続は、限定する意図ではないが、音声、マルチメディアビデオおよびオーディオストリーミング、パケット交換データおよび回路交換データコール、ショートメッセージシーケンスまたはデータバースト、およびページングを含む。ここでは包括的に「順方向救済手続」（ＦＲＰ）と呼んでいる本発明は、ＭＳまたはＢＳにおいて、回復しなければ接続の打ち切りを招くことになる障害からのシステムの回復を可能にする。ＦＲＰを使用して克服可能な障害のシナリオの例には、順方向リンクのレイヤ２（Ｌ２）確認応答障害およびスレッショルド値を超える時間間隔にわたって信号落ちをもたらすフェードに起因する順方向リンク信号落ちが挙げられる。潜在的な接続の打ち切りの状況に応答して、ＭＳは、打ち切りの危険にある接続を救済するために、自主的に、そのレーキ受信機のアクティブセットにＢＳパイロットチャンネルを追加する。同時に、ネットワーク通信基盤は、ＦＲＰの間にＭＳによってモニタされる可能性の高い代替順方向リンクチャンネル上において送信を開始する。同じチャンネルがＭＳによってモニタされ、通信基盤によって送信に用いられるのであれば、打ち切りの危機にある接続を救済することが可能になる。
【００３１】
本発明の実施態様に従った一般的なＦＲＰには、ＭＳＦＲＰが含まれ、またインフラストラクチャ（通信基盤）ＦＲＰを含めることもできる。
【００３２】
図８は、典型的な接続救済におけるＭＳＦＲＰおよび通信基盤ＦＲＰの時間列の一例を示している。前述したようにＭＳＦＲＰがすべての救済の中心となり、インフラストラクチャＦＲＰは、推奨されるが厳密に必要とはされない。
【００３３】
ＭＳＦＲＰのトリガは、発生する障害の種類に依存する。レイヤ２障害の場合であれば、ＦＲＰが、確認応答を求めるメッセージの、多数回にわたる再送信の失敗に応答して起動される。順方向リンクフェード障害の場合には、スレッショルド値を超える時間間隔にわたって信号落ちが存在するときＦＲＰが起動される（参照番号７２を参照）。
【００３４】
救済の試行が開始される時点においては、ＭＳがＦＲＰタイマをスタートする（参照番号７４を参照）。救済が完了する前にＦＲＰタイマがタイムアウトすると、接続が打ち切られる。それに加えてＭＳは、救済の試行が開始された時点において、その送信機をオフにし、新しいアクティブセットを選択する（参照番号７４を参照）。この実施態様においては、事実上ＭＳが、それが送信したＰＳＭＭ（１ないしは複数）に基づいてハンドオフ指示を仮定する（そのＰＳＭＭが実際に送信されたか否か、送信に成功したか否か、あるいは確認応答があったか否かによらない）。言い換えると、ＭＳは、ハンドオフ指示なしに自発的にパイロットを「アクティブセット」に昇格させる（つまり、新しいアクティブセットは、古いアクティブセットと自発的に昇格させたアクティブパイロットの和集合になる：Ｓ”＝Ｓ Ｕ Ｓ’）（参照番号７６を参照）。その後ＭＳは、救済チャンネルをサーチするために、この新しい「アクティブセット」内の循環を開始する。前述したように、救済チャンネルという用語は、各種の通信プロトコルによって使用されるチャンネルを定義するための各種スキームを包含しているが、開示の簡素化を目的として、ここでは救済チャンネルを、「仮コードチャンネル」（ＡＣＣ）（参照番号７８を参照）と同一視する。
【００３５】
すでに述べたが、インフラストラクチャＦＲＰは、推奨されてはいるが、ネットワーク内の各ＢＳに厳密に必要とされてはいない。インフラストラクチャＦＲＰが実行される場合には（参照番号８０を参照）、通信基盤（ネットワーク）は、ＡＣＣを送信することになるセクタを選択する。
【００３６】
本発明の一実施態様においては、救済の間にわたりＡＣＣを介してゼロ（ブランク）データが送信される。そのほかの実施態様においては、ＡＣＣを介してデータが伝達されることもあるが、ＭＳは、実際にそのＡＣＣを見つけて復調に成功する場合にもそのデータのヒアリングのみを行う。
【００３７】
ある時点においてＭＳが、Ｎ３Ｍ個のＡＣＣの良好なフレームを見つけてその復調を行うと（参照番号８２を参照）、その送信機をオンにし、ＢＳに対する送信を開始する。ＭＳおよびＢＳがともにあらかじめ決定された数の良好なフレームを受信すると、救済が完了し（参照番号８４を参照）、ＢＳは、そのＭＳをより永続的なチャンネルに割り当てし直す。それに加えて、ネットワークが、たとえばオーバーヘッドを介してＡＣＣの再割り当てを行うこともできる。さらにＢＳは、「救済完了ハンドオフ」メッセージ８６を送信することによって、ＭＳのアクティブセットの再割り当てを行い、救済後のクリーンアップを行うことができるが、そのメッセージには、「汎用」または「ユニバーサルハンドオフ指示」メッセージ等のすでに存在するハンドオフメッセージを再使用することが可能である。
【００３８】
次に、ＦＲＰの詳細について説明する。
【００３９】
（救済に先行するネットワーク機能）
前述したように、ＭＳは、切迫する接続の打ち切りの検出に先行して、ネットワークのコンフィグレーションパラメータを記憶している。一実施態様においては、これらのパラメータが、ＭＳによって単純に記憶される一定値である。それらのパラメータが前もってＭＳに既知であり、またそれらが変更されないことから、オーバーヘッドメッセージがこれらのパラメータを含んでいる必要はない。別の実施態様においては、これらのコンフィグレーションパラメータの変更が許容されており、そのためネットワークは、オーバーヘッド内においてそのコンフィグレーションをＭＳに送信しなければならない。
【００４０】
図３のオーバーヘッドメッセージ３０、３２、および３４に示されているコンフィグレーションパラメータの対応部は、ＭＳがアイドルのときに送信することができる。アイドル状態のＭＳについては、すべてのアイドル状態のＭＳが同一の情報を受信する必要があることから、コンフィグレーションパラメータの伝達に共通チャンネルを使用することができる。
【００４１】
（ＭＳの順方向救済手続き）
図９は、接続の打ち切りが切迫していることを検出し、かつその接続を救済するための、本発明の一実施態様に従ったＭＳの手続きを示したフローチャートである。
【００４２】
接続が切れかかり始めると、ディジタルセルラ電話のユーザに聞こえる会話が、とぎれとぎれの部分的なものとなるか、あるいはデータ接続の場合であればデータの遅れまたは喪失を経験するようになる。図５に示した「レイヤ２障害」が生じている「順方向／逆方向不平衡」の場合において（図９の参照番号８８を参照）、本発明の一実施態様におけるＭＳは、ＭＳの送信したメッセージに対する適正な確認応答をＭＳが受信せず、その後、Ｎ１ｍ（＝９）回にわたって適正な確認応答を受信することなくメッセージの再送信に失敗すると、接続の打ち切りが切迫しているものと判断する。一実施態様の場合には、これが、「パイロット強度測定メッセージ」（ＰＳＭＭ）もしくはその派生上において失敗した確認応答に関してのみ生じる。ここで注意が必要であるが、変数Ｎ１ｍおよびここで参照しているそのほかの類似の識別済みの変数は、前述した通信標準に定義されている変数である。しかしながら本発明の実施態様は、当該標準に定義されているとおりの変数の値に限定されることはない。
【００４３】
Ｎ１ｍ（＝９）回にわたる再送の後にＭＳが適正な確認応答を受信していない場合には、本発明を除いて、ＭＳは、最終的にあきらめてＢＳに対してリリースメッセージを送信する。このリリースメッセージは、事実上の接続の打ち切りである。ここで注意が必要であるが、図５に示されているＢＳからＭＳに対する最後のリリースメッセージは、ＭＳからＢＳに対するリリースメッセージがそれまでにＢＳによって受信されたか否かに依存して、送信されることもあれば、送信されないこともある。ＢＳがリリースメッセージを受信し、リリースメッセージをＭＳに返すことがあっても、ＭＳがそれを受信することはない。しかしながら、図９に示した本発明の一実施態様に従えば、ＭＳが、Ｎ１ｍ（＝９）回にわたる再送の後に適正な確認応答を受信していないならば、リリースメッセージの送信に代えて、ＭＳＦＲＰが起動され（参照番号９２を参照）、ＦＲＰタイムアウト期間をカウントするためにＦＲＰタイマがスタートされ（参照番号９６を参照）、さらにＭＳは、その後のＬ２障害を一時的に無視する。換言すると、ＭＳは、特定の時間間隔の後に接続の打ち切りを行わないことによって接続の維持を一時中断する。救済が完了する前にＦＲＰタイマがタイムアウトすると、そのとき接続が打ち切られる。それに加えて、ＭＳは、救済の試行を開始した時点において、確認応答に失敗したメッセージおよびそのほかの保留されているメッセージの再送信を一時中断し（参照番号９０を参照）、送信機をオフにする（参照番号９２を参照）。ＭＳの送信機がオフにされると、ほかのユーザには、そのＭＳから何も聞こえてこなくなる。しかしながらＭＳは、トラフィックチャンネルの状態は維持している。ＭＳは、アクティブ状態に関連付けされた、そのほかのすべての活動を継続する（参照番号９４を参照）。ここで注意が必要であるが、前述したようにＭＳの「レイヤ２障害」の検出は、逆方向ベースの救済手続きにも同様に適用することができる。
【００４４】
「順方向リンクフェード障害」の場合においては、スレッショルド値を超える時間間隔にわたって信号の喪失（Ｎ２ｍ個の不良フレーム）が存在するとき、接続の打ち切りが切迫していると考えられる。この状態が検出されたとき（参照番号９８を参照）、ＭＳは送信機をオフにし、順方向ＭＳフェードタイマ（Ｔ５ｍ）がスタートされる。しかしながらＭＳは、トラフィック（アクティブ）状態を維持する。本発明を除けば、Ｎ３Ｍ個の良好なフレームの受信前にフェードタイマがタイムアウトすると、接続が打ち切られる。一方、フェードタイマがタイムアウトする前に、連続するＮ３ｍ個の良好なフレームをＭＳが受信すると、ＭＳは送信機をオンに戻し、フェードタイマをリセットする。本発明の一実施態様においては、フェードタイマがタイムアウトする前の特定の時期、またはフェードタイマがタイムアウトしたときに、ＭＳＦＲＰが起動されて、ＦＲＰタイマがスタートされる（参照番号９６を参照）。ここで理解される必要があるが、ＦＲＰタイマはＭＳＦＲＰが起動されるのと同時にスタートしてもよく、また所定の遅延の後にスタートしてもよい。ＦＲＰタイマは、順方向ＭＳフェードタイマと等しく、あるいは類似してセットすることができる。その後のフェードタイマは、無視され（参照番号１００を参照）、ＭＳは、続くフェード障害を一時的に無視する。言い換えるとＭＳは、特定の時間間隔の後に接続の打ち切りを行わないことによって接続の維持を一時中断する。ＭＳＦＲＰの起動をフェードタイマのタイムアウトの直前まで遅延させることは可能であるが、フェードタイマのタイムアウトより早期に救済を開始する１つの理由として、ユーザが通信の失敗を経験する時間が長すぎると、ユーザがＭＳをオフにして手動で新しい接続を開始する可能性があり、それによって救済が排除されることが挙げられる。
【００４５】
ここで理解されたいことは、上記のＭＳＦＲＰを開始するための条件は単なる例示にすぎないということであり、本発明のほかの実施態様においては、ＭＳＦＲＰを開始するための条件が異なることもある。
【００４６】
ＭＳＦＲＰが開始された後、本発明の実施態様においては、ＭＳが最新のＰＳＭＭ（および可能性としては、それ以前のＰＳＭＭ）を検査し（参照番号１０２を参照）、アクティブセットへの昇格が指定されていたか、あるいはアクティブセットに維持することが指定されていたＰＳＭＭ（１ないしは複数）内のすべてのパイロットを追加（昇格）する。ここで注意が必要であるが、ＭＳはいかなる追加のＰＳＭＭもＢＳに送信しておらず、またいかなるハンドオフ指示を待機してもいないのであるから、ＭＳは、この時点において自発的に動作している。このパイロットのセットは、「仮ハンドオフ指示」（ＡＨＤ）を構成する（参照番号１０４を参照）。ここで、このＡＨＤが、送信もしくは受信が行われないことから、実際のメッセージではないことに注意する必要がある。むしろＡＨＤは、救済手続きの間にＭＳが行うアクティブセットに対する変更を記述するための用語にすぎないと言える。ここで注意しなければならないが、正常動作の間は、アクティブセットが特定の最大サイズに制限されるが、本発明の一実施態様においては、最大アクティブセットサイズが、救済の間に追加されるパイロットを収容するために一時的に拡張される。
【００４７】
ＡＨＤ内のパイロットのセットが決定された後、ＭＳＦＲＰは、そのＡＨＤ内の各パイロットの中でＭＳがサーチする１ないしは複数の「仮コードチャンネル」（ＡＣＣ）を決定しなければならない。救済コードが、このＡＣＣを定義する。ここでは、ＭＳがＡＣＣのためのパイロットをサーチするとき、そのパイロットがウォルシュコードまたはＱＯＦによって定義されたＡＣＣを送信しているものとＭＳが仮定することから「仮」という用語が使用されている。
【００４８】
ＭＳＦＲＰは、何らかのメカニズムによって事前にＡＣＣが既知となっている限り、インフラストラクチャＦＲＰに頼ることなく実行することができる。必ずしも相互に排他的でないＡＣＣを決定する方法は多数ある。ＡＣＣのデフォルトを、標準の中で指定された固定の値とすることができる。すべてのハンドオフを、初期的にデフォルトのＡＣＣに対するものとし、その後の確認応答に続いて、第２のハンドオフがＭＳに非ＡＣＣチャンネルを指示することができる。
【００４９】
ＡＣＣを、ＢＳ、セクタ、ネットワーク、またはシステムごとにオーバーヘッド内において指定することもできる。基本的にこのパラメータは、近隣ごとの近隣リストにおいて、あるいはグローバルに送信することができる。またグローバル、あるいはセクタ固有のＦＲＰＡＣＣとして、パラメータメッセージ（アクティブまたはアイドル）の１つにおいて送信することも可能である。ＡＣＣは、専用メッセージまたは命令において指定し、あるいはＭＳの「電子シリアル番号」（ＥＳＮ）もしくはそのほかのパラメータとＢＳパラメータ（１ないしは複数）の寄せ集め（ハッシュ）となるようにあらかじめアレンジして、ＭＳを異なるチャンネルに擬似ランダム分布させることもできる。
【００５０】
本発明の別の実施態様においては、ＭＳＦＲＰがリソースのソフト指定もサポートしている。すでに説明したように、オーバーヘッドメッセージが、特定のパラメータをＭＳに送信するために使用される。オーバーヘッドメッセージ内において送信されるパラメータの１つに、ＢＳごとに指定済みのＡＣＣを識別するウォルシュコードまたは擬似直交関数がある。このＡＣＣは、正常トラフィックチャンネルとは異なる。ソフト指定は、ＡＣＣの動的な変更が可能であることを意味する。これは、任意の時点においていずれのチャンネルを救済に使用可能とするか、あるいはＡＣＣの定義にいずれのウォルシュコードを使用するかについて、ネットワークがより効率的に決定することを可能にする。
【００５１】
複数のＡＣＣを救済用に指定することもできる。ＭＳが、たとえば異なるチャンネルに対してハッシュするようにしても良い。しかしながら、その種のチャンネルは、一時的な使用のみに関して、より少なく指定することが推奨される（好ましくは１つだけ）。救済完了のハンドオフは、厳密に求められているわけではいない。代替ＡＣＣを使用するか、あるいは他の救済を遅延することもできる。
【００５２】
「指定」チャンネルは、たとえば正常な順方向リソースとして別に必要とはならないとき、救済のためだけに使用されるので、指定リソースは、この特徴の厳密な必要条件ではない。救済機能が一時的に延期されることを除けば、不利益な影響が生じることもない。
【００５３】
ＡＣＣが決定された後、ＭＳは、関連するコードチャンネルを、新しいアクティブセット内の各アクティブパイロット用の「仮コードチャンネル」（ＡＣＣ）にセットする（参照番号１０６を参照）。本発明の一実施態様においては、続いてＭＳが、良好なＡＣＣの復調を試行するために、パイロット信号のサーチを行い、レーキ受信機のフィンガを割り当てることによって、新しいアクティブセットの復調ならびに監視を試行する（参照番号１０８を参照）。ここで、この時点において、ＭＳはまったく送信を行わないに注意すべきである。ＭＳは、「ＦＲＰタイマ」がタイムアウトするまで（参照番号１１０を参照）もしくはあらかじめ決定された数の連続する良好なフレームが受信されるまで（参照番号１１２を参照）、新しいアクティブセットの復調を継続的に試行する。
【００５４】
本発明の一実施態様においては、良好なＡＣＣのサーチを実行する間に、ＭＳが、レーキ受信機の能力に依存して、一度に１つのセクタだけを試すことや、あるいは一度に複数のセクタを試すことができる。ＭＳは、各セクタにおいて、設定済みの時間間隔にわたって良好なＡＣＣの復調を試行した後、次のセクタに移動することができる。図１０に示されている例においては、セクタＣ、Ｄ、およびＥだけが新しいアクティブセットの一部を構成するセクタであり、したがってＭＳは、これらのセクタを循環して良好なＡＣＣを捜す（参照番号１１４、１１６、および１１８を参照）。
【００５５】
本発明の一実施態様においては、ＭＳが新しいアクティブセットから良好なＡＣＣの復調を試行する間に、ＭＳがレーキ受信機のフィンガを複数のパイロットに割り当てることになる。しかしながら、救済の間は、ＭＳが、いずれのフィンガが良好なフレームを受信したかを決定することが困難なことがある。いずれのチャンネルが良好なＡＣＣを提供しているかを決定する際の困難性が、次の例に従って説明される。ここで、当初ＭＳが、Ａ、Ｂ、およびＣの３つのＢＳからなるネットワーク内において、ＣのＢＳと通信していたが、接続の打ち切りが切迫していることを検出し、ＭＳが、ＭＳＦＲＰを開始したと仮定する。さらに、当該ネットワークもまた、切迫している接続の打ち切りを検出し、したがってＢのＢＳにおいてＡＣＣを送信したものと仮定する。ＭＳは、いずれのＢＳがＡＣＣを送信しているかについて知らないことから、ＡおよびＢの両方のＢＳからのＡＣＣを復調するための試行において、ＭＳのレーキ受信機のフィンガを割り当てる。その後、ＭＳは、この復調した情報を結合してフレームを生成する。
【００５６】
結果として得られたフレームが不良である場合には、それがＢのＢＳからのチャンネルが良好に受信されなかったか、あるいはＡのＢＳによって復調後のデータが改ざんされたか、あるいはそのほかの理由に起因する可能性がある。結果として得られたフレームが良好な場合であっても、ＭＳは、いずれのＢＳが良好なＡＣＣを送信したかについて知ることができない。その場合においては、ＭＳが、いずれのＢＳが良好なＡＣＣを提供したかについて決定することができる追加の情報を得るために、一度に１つのＢＳを試さなければならない。この困難性のため、ＭＳＦＲＰの代替実施態様においては、ＭＳがレーキ受信機のフィンガを一度に単一のチャンネルおよびセクタだけに割り当て、それによって、良好なＡＣＣが見つかった場合には、ＭＳはどのＢＳが良好なＡＣＣを提供したかを決定することができる。
【００５７】
再度図９を参照するが、ＦＲＰタイマがタイムアウトする前に、ＭＳが、あらかじめ決定された数の連続する良好なフレーム（たとえば、Ｎ３ｍ（＝２フレーム））を受信できた場合には、送信機をオンし（参照番号１２０を参照）、新しいアクティブセット上における接続を継続し（参照番号１２２を参照）、それによって、成功した救済を完了する（参照番号１２４を参照）。受信が成功しなかったセクタに関する、新しく仮定したアクティブパイロットは、混信を招くだけであることから、ＭＳは、救済の完了後直ちにそれらを降格する必要がある。ＭＳは、信号強度の観察、記号コンバイナの重み付け、異なるチャンネルの復調における試行、あるいは基地局からの応答（つまり、ＨＤＭ）に基づいて降格するパイロットを選択することができる。
【００５８】
またＭＳは、現在のパイロット状態に基づいてＰＳＭＭの再構成および送信を行い、再送信カウンタおよび／またはフェードタイマをリセットすることもできる（参照番号１２６を参照）。ＢＳが、回復の完了およびアクティブセットの確認のためのハンドオフ指示の確認を送信することもあれば送信しないこともある（参照番号１２８を参照）。ＢＳがハンドオフ指示を送信する場合に、ＭＳは、それに応じてそのアクティブセットを更新する必要がある。ＦＲＰタイマがタイムアウトする前に、ＭＳが、あらかじめ決定された数の連続する良好なフレーム（たとえば、Ｎ３ｍ（＝２フレーム））を受信しなかった場合には（参照番号１１０を参照）、接続が終了する（打ち切られる）（参照番号１３０を参照）。
【００５９】
本発明の一実施態様においては、ＭＳが良好なＡＣＣの復調を試行する間に、ＭＳは、自律的かつ動的にそのアクティブセットを変更する。図１１は、動的アクティブセットを使用するＭＳＦＲＰのフローチャートを示している。この手続きは、図９に類似であるが、復調を試行するセクタのセットをＭＳが変更できる点が異なる。これは、救済の間における信号状態の変化に適応するため、および異なるセクタ上において救済を試行し、救済を成功させる機会を増加するために行われる。ＭＳが新しいアクティブセットの復調を試行している間であるが（参照番号１３２を参照）、ＦＲＰタイマがタイムアウトする前に（参照番号１３４を参照）、救済のための新しいセクタを捜しだすための試行において別のパイロットの強度をモニタする（参照番号１３６を参照）。充分な受信強度を伴ったパイロットが捜し出され、それが現在のアクティブセット内に含まれていなければ（参照番号１３８を参照）、ＭＳは、その新しいパイロットをＡＨＤに追加（昇格）する（参照番号１４０を参照）。またＭＳは、パイロットの強度が低下したとき、あるいは新しいパイロットのための空きを作るためにＡＨＤからパイロットを削除（降格）することもできる。たとえば、図１２に示されているように、ＭＳＦＲＰの一部として、パイロット信号Ａ、Ｂ、Ｃ、およびＤが、その信号強度に関してモニタされているとする。あるパイロットが、スレッショルドＴ＿ＡＤＤを超える信号強度を達成すると、ＭＳは、自律的にそのパイロットを候補セットおよびアクティブセットの両方に昇格する（例えば参照番号１４２を参照）。ＭＳは、充分な強度を持ったパイロットを自律的にアクティブセットに昇格することによって、新しいアクティブセットを作成することになる。
【００６０】
図１１に戻るが、その後ＭＳは、新しいＡＨＤに関連付けされたコードチャンネルを、各個別のセクタ用のＡＣＣにセットし（参照番号１４４を参照）、さらに新しいアクティブセットの復調を試行する（参照番号１３２を参照）。新しいパイロットが捜し出せなかった場合（つまり、パイロットの変更がない場合）には、ＭＳは、引き続き変更していないアクティブセットの復調を試行する（参照番号１３２を参照）。２つのパイロットが同一信号強度を有している場合には、ＭＳは、順番に両方とも試す決定を行うことができる。本発明の実施態様においては、任意数の、当業者間によく知られている方法論またはインテリジェントサーチアルゴリズムをＭＳＦＲＰに使用して、ＭＳにＡＣＣのサーチを行わせることができる。
【００６１】
最初は、ＭＳのオリジナルのアクティブセット内のパイロットが、切迫した接続の打ち切りを生じたが、最終的にこれらオリジナルのパイロットの１つが、救済のための最良のチャンネルを提供する可能性もあることから、良好なＡＣＣを捜すとき、ＭＳは、これらオリジナルのパイロットにおいてＡＣＣを捜し出す試行を行うこともできる。本発明の変形実施態様においては、古いメンバも含めて新しいアクティブセット内のすべてのメンバを同一の方法で扱うことも可能であり、あるいは古いアクティブセットのメンバを新しいアクティブセットの新しいメンバと異なる扱いにすることもできる。
【００６２】
動的アクティブセットを特徴とする変形実施態様においては、救済の間に、ＭＳがそのアクティブセットを変更するごとに、ＭＳが新しいＰＳＭＭメッセージを送信することができる。順方向ベースの救済においては、これにより、このＰＳＭＭを送信するのに合わせて、ＭＳが短時間の間その送信機をオンにする必要が生じることになるが、逆方向ベースの救済においては、単にＰＳＭＭが送信されることになる。ＭＳには、ＢＳが新しいアクティブセットを伴うこのＰＳＭＭを受信した否かが確実にわからないが、ＢＳがそのメッセージを受信した場合には、ＡＣＣの調整にそれが役立つことになる。
【００６３】
ここで理解する必要があるが、この動的アクティブセットは、順方向ベースおよび逆方向ベースの救済手続きの両方に適用することができる。
【００６４】
（インフラストラクチャの順方向救済手続き）
ＭＳＦＲＰだけを実行することによっても接続の救済を行うことは可能であるが、本発明の別の実施態様においては、インフラストラクチャＦＲＰを実行することもできる。これらの実施態様においては、救済の試行の間に、ＭＳおよびインフラストラクチャが継続的にパイロットの状態をモニタし、必要に応じて新しいＢＳ／セクタとそれぞれのアクティブセットの再シードを行うことができる。前述したように、ＭＳは、現存の、あるいは新しい候補を継続的にモニタし、別のＡＨＤを使用してアクティブセットにそれらを昇格することができる。同様にインフラストラクチャもまた、後述するように、状態またはＭＳの位置を継続的にモニタし、ＭＳに対して新しく適用可能なセクタに関するＡＣＣを指示することができる。本発明の一実施態様においては、ＭＳＦＲＰおよびインフラストラクチャＦＲＰが、２０ミリ秒内またはそれぞれの１フレーム内に起動される。
【００６５】
図１３は、本発明の一実施態様に従ったインフラストラクチャ（ネットワーク）ＦＲＰのフローチャートを示している。インフラストラクチャＦＲＰは、レイヤ２障害および順方向フェード障害の両方に対して類似している。インフラストラクチャＦＲＰは、複数のインフラストラクチャコンポーネントによる実行が可能であり、そのコンポーネントには、限定を意図するわけではないがＢＳ、ＢＳコントローラ、および移動交換センタが含まれる。しかしながら、明確化のために、ここでは単一のＢＳによって実行されるものとしてインフラストラクチャＦＲＰを説明する。
【００６６】
インフラストラクチャＦＲＰは、ＭＳが切迫した接続の打ち切りに遭遇していることをＢＳが間接的に検出する必要があることから、ＭＳＦＲＰとは異なる。「レイヤ２確認応答障害」の場合には、異常がまったくＢＳにわからないことからフェード状態の検出よりも困難になる。たとえばＢＳが、それに向けてＭＳが送信したすべてのＰＳＭＭメッセージを受信しており、それらのメッセージに対して確認応答メッセージをもって応答していることが考えられる。しかしながら、ＢＳは、ＭＳのメッセージに対して確認応答を続けているにもかかわらず、ＭＳが同一メッセージの再送信を継続していることに気付く。このことから、ＢＳは、順方向／逆方向不平衡状態、すなわちＭＳの送信または受信に問題が生じている状態を推測することができる。したがってＢＳは、それぞれに確認応答を行った後に、「ＦＲＰ反復受信スレッショルド」回数にわたりＭＳから同一のＰＳＭＭメッセージ（またはその均等メッセージ）を受信したことに基づいて、インフラストラクチャＦＲＰをトリガすることができる（参照番号１４６を参照）。ここで注意が必要であるが、ＢＳによるこの「レイヤ２障害」の検出は、前述したように、逆方向ベースの救済手続きに対しても適用することができる。
【００６７】
ＢＳが、切迫した接続の打ち切りを検出することができる別の方法は、ＭＳから受信しているメッセージがどのような種類のものであるかを決定することによってなしえる。たとえば、ＢＳがＭＳから繰り返しＰＳＭＭを受信する場合には、ＢＳは、それらを調べて、ＭＳが、それが有している以外のＢＳもしくはセクタを必要としていると判断することができる。このＰＳＭＭメッセージが、そのＭＳによって繰り返し送信される場合には、それが、ＢＳに対対して救済が有用であるというしるしになる。
【００６８】
ＭＳがフェード状態のために救済を必要としていることは、ＢＳが、フェードタイマの期間にわたって、あらかじめ決定された数の有効なフレームをそのＭＳからＢＳが受信したか否かをモニタすることによって検出できる（参照番号１４８を参照）。言い換えると、順方向フェードにおいては、ＭＳが送信を停止することから、ＢＳは、所定期間の後にそれを検出することが可能になる。インフラストラクチャＦＲＰの起動は、ＢＳが（１）ＰＳＭＭを受信し、ハンドオフ指示を送信したか、あるいは（２）フェードの間に確認応答を送信したいずれかの場合に好適となり得る。いずれの場合においても（参照番号１４６または１４８を参照）、図１３に示されているように、ＢＳがトラフィック（アクティブ）状態を維持し（参照番号１５０を参照）、ＢＳにおけるＦＲＰタイマをスタートする（参照番号１５２を参照）。
【００６９】
ＭＳＦＲＰの「フェードタイマ」の先行した起動と同様に、「レイヤ２確認応答」障害の場合に、起動のためのスレッショルドとして、Ｌ２ＡＣＫカウント（＝９）から減数されるカウントを供給することによって、オプションとして、インフラストラクチャＦＲＰを先行して起動するようにすることができる。それに加えて、インフラストラクチャＦＲＰの試行期間は、フェードのタイムアウトによって制限されると考えることもできる。たとえば、インフラストラクチャＦＲＰを、フェードの後半部分の間においてのみ開始できる。
【００７０】
すでに述べたように、動的アクティブセットを特徴とする変形実施態様においては、救済の間にＭＳは、ＭＳがそのアクティブセットを変更するごとに新しいＰＳＭＭメッセージを送信することができる。ＢＳによってＰＳＭＭが受信された場合には（参照番号１５４を参照）、ＢＳは、受信したＰＳＭＭの検討を行う（参照番号１５６を参照）。そのＰＳＭＭ内の、アクティブセットへの昇格が指定されているか、維持が指定されているすべてのパイロットは、それに続いて新しいアクティブセット内に含められる。
【００７１】
ＰＳＭＭがまったく受信されない場合には、近隣ＢＳのサブセットが新しいアクティブセットに追加すべきものとして選択される（参照番号１５８を参照）。ＢＳコントローラまたはインフラストラクチャ要素は、救済の開始前に何がそのＭＳ用のアクティブセットであったかを知っており、この時点においては、接続を救済するためにアクティブセットに追加するための追加的なＢＳまたはセクタを決定しなければならない。追加されるＢＳまたはセクタは、多数の要因に依存し、それには、限定する意図ではないが、最後にわかっているＭＳのアクティブセット、ＭＳの位置、ＭＳにもっとも近いセクタ、そのＭＳに関する以前のアクティブセット、そのＭＳのそのほかの履歴ならびに統計、およびＭＳが要求していた新しいパイロット等が含まれる。ここで注意が必要であるが、ＰＳＭＭを伴うＬ２確認応答障害の場合においては、ネットワークがそのＰＳＭＭを受信できたのであれば、すでにそのＰＳＭＭメッセージからＭＳが要求しているセクタを知ることができるため、ネットワークは、ＭＳがどのセクタを必要としているかを評価する必要がない。しかしながら、この情報が利用できない場合には、ネットワークは、上記の要因のすべてを使用して、ＭＳが救済のために必要としている可能性のあるセクタを評価する。ネットワークは、いずれのセクタ内にＭＳが存在するかを知っていることだけからそのＭＳの位置を決定できるのではなく、ＭＳがＧＰＳ機能を有している可能性、もしくはインフラストラクチャがネットワークベースのポジションの特定機能を有している可能性、あるいはシステムがネットワークによって補助されるポジションの特定機能を有している可能性からもそれが可能であることに注意する必要がある。
【００７２】
本発明のさらに別の実施態様においては、接続の救済のためにアクティブセットに追加されるための追加的なＢＳまたはセクタを決定するプロセスの間に、ネットワークが、救済が可能であり、かつ望ましいかを決定することになる。救済が望ましくないとされる理由はいくつか考えられる。たとえば、救済に必要とされているセクタが最大能力に達しており、帯域幅が不足することがある。言い換えると、インフラストラクチャＦＲＰが、接続を救済するためにはほかのチャンネルを持ち出す必要があるが、それを行うことによってそのセクタを使用する別の接続に順方向フェード障害を招くことになるポイントまでそのセクタにおける電力および混信が増加されるとすれば、そのＦＲＰはまったく利益をもたらさないことになる。むしろ、１つの接続と別の接続を単に交換したにすぎない。別の理由としては、ＡＣＣに割り当てるコードがそのセクタに不足していることが挙げられる。すでに述べたように、新しいチャンネルを開くときにはウォルシュコードまたは擬似直交関数が使用される。１つのセクタ内においてこれらのコードがすべて使用されていれば、新しいチャンネルを開くことができない。
【００７３】
上記の例は、逆方向ベースの救済手続きに代えてＦＲＰを使用することの１つの利点を示している。ＦＲＰにおいては、ＢＳが接続の救済を試行するか否かを決定し、それゆえ、救済がほかの接続に影響を与えないと判断した場合に、新しいチャンネルを開き、救済を試みる。これに対して逆方向ベースの救済手続きにおいては、ＭＳが、その救済の試行が現存するほかの接続に影響を与えるか否かについて知らずに、送信を開始し、追加的な電力消費および混信をもたらすことになる。
【００７４】
新しいアクティブセット内のパイロットのセットが決定された後、インフラストラクチャＦＲＰは、新しいアクティブセット内のＢＳが、新しいアクティブセット内の各パイロットから送信することになる１ないしは複数のＡＣＣを決定しなければならない。前述したようにウォルシュコードまたはＱＯＦがＡＣＣを定義する。
【００７５】
本発明の一実施態様においては、必ずしも相互に排他的である必要のないＡＣＣを決定するためのオプションが多数存在する。ＡＣＣのデフォルトを、標準の中に指定された固定の値とすることができる（つまり、ＡＣＣによって使用されるものとして確保された順方向ウォルシュコードを選択する）。ＡＣＣを、ＢＳ、セクタ、ネットワーク、またはシステムごとにオーバーヘッド内において指定することもできる。基本的にこのパラメータは、近隣ごとの近隣リスト内において、あるいはグローバルに送信することができる。またグローバルとして、あるいははセクタ固有のＦＲＰＡＣＣとしてパラメータメッセージ（アクティブまたはアイドル）の１つにおいて送信することも可能である。ＡＣＣを専用メッセージまたは命令において指定することもできる。
【００７６】
本発明の別の実施態様においては、インフラストラクチャＦＲＰがリソースのソフト指定もサポートしている。すでに説明したように、オーバーヘッドメッセージが、特定のパラメータをＭＳに送信するために使用される。オーバーヘッドメッセージ内において送信が可能なパラメータの１つに、指定済みＡＣＣを識別するウォルシュコードまたは擬似直交関数がある。このＡＣＣは、正常トラフィックチャンネルとは異なることになる。ソフト指定は、ＡＣＣの動的な変更が可能であることを意味する。これは、任意の時点においていずれのチャンネルを救済に使用可能とするか、あるいはＡＣＣの定義にいずれのウォルシュコードを使用するかについて、ネットワークがより効率的に決定することを可能にする。
【００７７】
複数のＡＣＣを救済用に指定することもできる。しかしながら、その種のチャンネルは、一時的な使用のみに関して、より少なく指定することが推奨される（好ましくは１つだけ）。救済完了のハンドオフは、厳密に求められているわけではない。代替ＡＣＣを使用するか、あるいはほかの救済を遅延することもできる。
【００７８】
「指定」チャンネルは、たとえば正常な順方向リソースとして別に必要とはならないとき、救済のためだけに使用されるので、指定リソースは、この特徴の厳密な必要条件ではない。救済機能が一時的に延期されることを除けば、不利益な影響が生じることもない。
【００７９】
新しいアクティブセットおよびＡＣＣが決定されると、その新しいアクティブセット内のＢＳは、関連する（符合した）ＡＣＣ（１ないしは複数）を使用してＭＳに順方向リンクを送信する（参照番号１６０を参照）。言い換えると、ＭＳがソフトハンドオフを行うために追加的なＡＣＣが使用可能になる。これらのＡＣＣは、接続が最初に失敗しつつあったときにそのＭＳが有していなかった１ないしは複数のセクタ上において送信される。
【００８０】
本発明の一実施態様においては、任意の時点において１つのセクタだけがＡＣＣの送信を行う。１つのセクタだけから送信を行うことには、順方向救済においては、ネットワークがそのトラフィックならびに能力を知っており、その中でＡＣＣを送信する場所および時期について調整可能であることから、救済による能力的な影響を最小化できるという利点がある。図１４の例に示されているように、ネットワークによるセクタのセット内の循環に従って、あるセクタが、設定された時間間隔１６２だけＡＣＣの送信を行って停止し、続いて別のセクタが送信を行うという形がとられる。
【００８１】
しかしながら、別の実施態様においては複数のセクタまたは複数のＢＳが同時にＡＣＣの送信を行うことができる。図１５は、ＡＣＣの送信が行われるセクタの動的選択を含むインフラストラクチャＦＲＰを示したフローチャートである。インフラストラクチャは、信号状態の変化、ＭＳの反応、または救済のためのセクタの異なる組み合わせの試行に依存して異なるＢＳセクタを選択することができる（参照番号１６４を参照）。セクタの再選択は、ＢＳがあらかじめ決定された数の連続する良好なフレームを受信しなかった場合（参照番号１６６を参照）であって、ＦＲＰタイマがタイムアウトしていない場合（参照番号１６８を参照）に実行される。ネットワークは、セクタ間を交換してリソースの使用を最小化しつつ、ＭＳを救済する機会を最大化することができる。
【００８２】
オプションとしてＢＳは、スロット化またはバースト／断続モードでＡＣＣを運用することが可能であり、それにおいては、任意の「ＦＲＰタイマ」（値の）期間内に、少なくともあらかじめ決定された数（Ｎ３ｍ）個の順方向フレームが送信され、その結果、ＭＳが救済される機会を持つことになる。同時にこれは、混信を最小化し、能力を最大化する。ＡＣＣは、危険な状態にある（つまり、弱い信号または近隣のＢＳ／セクタ上の高い電力に近づいている）接続が顕在化していないとき、オフにすることもできる。
【００８３】
ＢＳが新しい救済トラフィックチャンネルを起動した後、ＢＳは、ＭＳからのアップリンクの受信を試行する（参照番号１７０を参照）。セクタからの送信が最初になることから、ＭＳは、ＢＳが救済を試行していることを認識した後に限って送信を行うことになり、それが電力ならびに混信を最小化する。
【００８４】
前述したように、ＭＳＦＲＰにおいては、ＭＳが最新のＰＳＭＭ（および可能性としては、それ以前のＰＳＭＭ）を検査し、昇格が指定されていたか、あるいは維持が指定されていたＰＳＭＭ（１ないしは複数）内のすべてのパイロットをアクティブセットに追加（昇格）する。同様にインフラストラクチャＦＲＰは、受信済みのＰＳＭＭを使用して、そのアクティブセットに追加すべきパイロットを決定することが可能であり、また信号強度を基礎としてその決定を行うこともできる。それに加えて、インフラストラクチャＦＲＰが起動される場合には、近隣ＢＳを、インフラストラクチャによって維持されているアクティブセットに追加することができる。ここで注意が必要なことは、ＭＳおよびインフラストラクチャのＦＲＰのいずれもが、この時点において自発的に動作しており、したがっていずれも他方の新しいアクティブセットについて知らないことである。この状況の下に、図１６に例示されている本発明の実施態様においては、ＭＳＦＲＰが、その新しいアクティブセット内のパイロット間を循環して（参照番号１８０を参照）それらのパイロット内のＡＣＣのサーチを行うことになる。同時にインフラストラクチャＦＲＰは、その新しいアクティブセット内のパイロット間を循環して（参照番号１８２を参照）、それらのパイロット上においてＡＣＣを送信することになる。図１７は、救済手続き期間における自発的なパイロットの復調ならびに送信に関するいくつかの手法の例を示している。ＭＳおよびインフラストラクチャのＦＲＰによるパイロットの循環は、その手法の特定のセットに従って好ましく調整されており、少なくともＮ３ｍ個のフレームにわたっていくつかの送信がオーバーラップすること、したがって救済が可能になることが保証されている。この、送信がオーバーラップする期間においては、ＭＳが特定のセクタからのＡＣＣの復調を試行しているとき、同時にネットワークがそのセクタ上においてＡＣＣの送信を行っていることになる。
【００８５】
再度図１５を参照するが、ＢＳは、アップリンク上において、ＦＲＰタイマがタイムアウトする前に（参照番号１６８を参照）あらかじめ決定された数の連続する良好なフレームを受信できた場合には、ＭＳに対して「救済完了ハンドオフ」（ＲＣＨ）メッセージを送信し（参照番号１７２および１７４を参照）、救済を確認し、完了することができる（参照番号１７６を参照）。このＲＣＨは、そのＭＳを、そのＢＳに対して異なるコードチャンネルに割り当てるものであり、その結果、別のＭＳの救済にそのＡＣＣを再使用することが可能になる。ＢＳは、ＭＳに対してこのメッセージを、可能な限り迅速に送信する。その後ネットワークは、ＭＳによって送信されたアクティブセットに従ってそのアクティブセットを更新し、接続を継続することができる。
【００８６】
ＢＳが、アップリンク上において、ＦＲＰタイマがタイムアウトする前にあらかじめ決定された数の連続する良好なフレームを受信しなかった場合には、接続が終了する（打ち切られる）（参照番号１７８を参照）。
【００８７】
（順方向救済手続きの適用）
これまでは、一例としてＣＤＭＡセルラネットワークを使用する一般的なＦＲＰについて説明してきたが、この一般的なＦＲＰにおいて説明した打ち切りの危機にある接続の救済、順方向および複数の逆方向リンク、オーバーヘッドメッセージ、専用および共通チャンネル、およびＡＣＣといった基本的なコンセプトは、別のワイヤレスプロトコルならびに技術、たとえばページングシステム、衛星通信システム、コードレス電話システム、フリート通信システム等に適用可能であり、もしくは拡張可能である。たとえば、ＣＤＭＡおよびＴＤＭＡは、ともにチャンネルの概念を利用する。ここで説明したＢＳの概念は、中継機または各種のアンテナのダイバーシティスキーム、コードレスの基地、衛星またはそのほかの電話等を包含している。ここで説明したＭＳの概念は、ページャ、衛星電話、コードレス電話、フリート無線等を包含している。
【００８８】
ＦＲＰのキーとなる構成ブロックには、（１）失敗接続を有する危機にあるか、それを有している１ないしは複数の端末、（２）端末（１ないしは複数）が救済に関するリスニングを行う間、送信によって救済を開始する、１ないしは複数の端末に対して何らかのコントロールを行う実体物、および（３）その実体物からの送信の受信が成功したときにそれらの端末が行う、実体物に向けて返す送信の開始、が含まれる。
【００８９】
端末は、商用、軍事、またはその他の用途に使用される無線機とすることが可能であり、それには水中での使用、宇宙での使用、またはGlobalstarTMまたはIridiumTMタイプのシステムのような衛星と地上局または端末の間における使用が含まれる。また端末は、Ethernet（登録商標）等の共有有線を介して実体物に接続することも可能である。この場合、失敗しつつある接続を有している端末が、送信を停止し、実体物からそれに向けられた救済送信を受信するまで待機する。
【００９０】
より広い用途においては、制御を行なう実体物が、端末を救済すべき時期および救済すべき端末を決定できることから、救済に関するコントロールを有する。この意味においては、手続きが集約化され、したがって非集約化手続きに関連付けされる効率、遅延、および電力コントロールといったタイプの問題が克服される。
【００９１】
以上、本発明について、添付図面を参照し、その実施態様との関連において十分に説明してきたが、当業者にとっては各種の変更ならびに修正が明らかであることに注意が必要である。その種の変更ならびに修正は、付随する特許請求の範囲によって定義される本発明の範囲内に含まれると理解するべきである。
【図面の簡単な説明】
【図１】 無線通信システム内のセクタ間にわたり、異なる位置の間を動き回る移動局を図示している。
【図２】 無線通信システム内における移動局と基地局の間の通信リンクの一例を図示している。
【図３】 無線通信システム内において基地局から移動局へ通信されるオーバーヘッドメッセージを図示している。
【図４】 動き回っている移動局と通信する無線通信インフラストラクチャを図示している。
【図５】 「レイヤ２確認応答障害」に起因して通信の打ち切りを招くことになる移動局と基地局の間におけるメッセージシーケンスを図示している。
【図６】 無線通信ネットワーク内において順方向リンクのフェードからもたらされる接続の打ち切りを表したタイムラインである。
【図７】 無線通信ネットワーク内における使用のための、３つのフェーズおよび４つのフレームに分割されるスロットまたはスーパーフレームのタイムラインである。
【図８】 「順方向救済手続き」が起動されて接続の打ち切りが回避された、本発明の一実施態様のタイムラインである。
【図９】 本発明の一実施態様に従った移動局の手続きに関するフローチャートである。
【図１０】 本発明の一実施態様に従った良好な順方向仮コードチャンネルの復調の試行において３つのセクタを循環する移動局を示したタイムラインである。
【図１１】 本発明の一実施態様に従った動的アクティブセットを含む移動局の手続きに関するフローチャートである。
【図１２】 本発明の一実施態様に従って、スレッショルドを超えて信号強度が上昇したときにパイロットを自発的にアクティブセットに昇格する移動局を示した説明図である。
【図１３】 本発明の一実施態様に従ったインフラストラクチャの手続きに関するフローチャートである。
【図１４】 本発明の一実施態様に従って、３つのセクタ間を循環しつつ、各セクタから順方向仮コードチャンネル上において送信を行う基地局を示したタイムラインである。
【図１５】 本発明の一実施態様に従った動的セクタ選択を含むインフラストラクチャの手続きに関するフローチャートである。
【図１６】 本発明の一実施態様に従って、移動局アクティブセット内のパイロット間を循環しつつそれらのパイロット内のＡＣＣをサーチする移動局、およびその一方において基地局アクティブセット内のパイロット間を循環しつつそれらのパイロット上でＡＣＣを送信する基地局を示したタイムラインである。
【図１７】 本発明の一実施態様に従った救済手続き期間における自発的なパイロットの復調に関するいくつかの手法を図示するものである。
本発明の実施態様は、２０００年１０月１７日に出願された米国仮特許出願第６０／２４１，２６８号の「Forward Rescue Procedure (順方向救済手続き)」および２０００年１１月１４日に出願された米国仮特許出願第６０／２４８，９００号の「Improvement to Rescue Channels Using Dynamic Active Set During Rescue （救済の間における動的アクティブセットを使用する救済チャンネルに対する改良）」からの優先権を主張するものであり、その内容が、あらゆる目的に関して、参照によりここに援用される。
【０００１】
（発明の分野）
本発明は、通信ネットワーク管理に関し、特に、一実施態様においては、セルラまたはＰＣＳ電話等の移動局と、無線通信基盤（ネットワーク）の間の、信号落ちならびに接続の打ち切りを防止するための方法および装置に関する。
【０００２】
（関連技術の説明）
（序論）
緊急通信のための手段を単に提供するというより、セルラ電話は、急速に、今日的社会における通信の主要な形態になりつつある。セルラ電話の使用が普及するに従って、セルラ電話ネットワークがますます優勢になり、消費者の要求を満たすべく、より大きなエリアにわたる利用範囲を提供するようになっている。図１は、無線セクタＡ１４およびＢ１６を伴う第１の基地局（ＢＳ）１２、およびセクタＣ２０を伴う第２のＢＳ１８を含む無線通信基盤またはネットワークによってサービスされる地理的エリア内を動き回るモバイルユーザによって操作される移動局（ＭＳ）１０の例を図示している。そのような動き回りの中で、ＭＳ１０は、位置Ａから位置Ｂへ、さらに位置Ｃへと移動し、当然のことながら、コンタクトしているＢＳ（１ないしは複数）に関連付けされている順方向リンクの信号強度ならびに信号品質における変動を経験することになる。信号の強度ならびに品質は、たとえばＭＳ１０がセクタＡ１４の破線によって画定されるエリアからセクタＢ１６の破線によって画定されるエリアへ、あるいはセクタＢ１６からセクタＣ２０へ移動するときのように、セクタの境界近傍では特に信頼性の低いものとなることがある。接続の打ち切りは、この種の遷移エリアをはじめ、そのほかの信号強度の弱い、もしくは品質の低いエリアにおいて生じやすい。なお、ここで述べられている接続には、限定する意図ではないが、音声、マルチメディアビデオまたはオーディオのストリーミング、パケット交換データおよび回路交換データ接続、ショートメッセージシーケンスまたはデータバースト、およびページングが含まれる。
【０００３】
接続の打ち切りは、セルラ電話ユーザが単に困る程度のものから大きな打撃を与えるものまで広い範囲にわたる可能性がある。たとえば、緊急の９１１接続が打ち切られた場合、それは、決定的、さらには致命的となることさえある。接続の打ち切りは、サービスプロバイダを変更させる充分ないらだちを消費者にもたらすこともある。したがって、接続の打ち切りを防止することは、セルラネットワークプロバイダにとっての主要な重要課題である。
【０００４】
（セルラ電話ネットワーク）
図２は、ＭＳ２４とＢＳ２６の間における一例の通信リンク２２を表している。ＢＳ２６からＭＳ２４への通信は順方向リンクと呼ばれ、ＭＳ２４からＢＳ２６への通信は逆方向リンクと呼ばれる。ＢＳ２６は、通常、複数のセクタを包含し、一般にはそれが３個である。各セクタは、個別の送信機および、それぞれが異なる方向を指向するアンテナ（トランシーバ）を含む。ＢＳという用語が、しばしば、広くトランシーバと同義に使用されることから、ここでは用語ＢＳおよびセクタがある意味で相互交換可能に使用されることを理解する必要がある。順方向および逆方向のリンクは、多数の順方向および逆方向のチャンネルを使用する。たとえば、ＢＳ２６は、複数の順方向チャンネル上において一斉送信を行う。これらの順方向チャンネルには、限定する意図ではないが、１ないしは複数のパイロットチャンネル、同期チャンネル、１ないしは複数のページングチャンネル、複数の順方向トラフィックチャンネルを含めることができる。パイロット、同期、およびページングチャンネルは、ＢＳ２６がすべてのＭＳに対する通信にそれらのチャンネルを使用することから共通チャンネルと呼ばれている。概して、これらの共通チャンネルは、データの搬送には使用されず、一斉送信ならびに共通情報の配信に使用される。これに対して、複数存在する順方向トラフィックチャンネルは、各順方向トラフィックチャンネルが特定のＭＳ２４に向けられていることから専用チャンネルと呼ばれており、データを搬送することができる。
【０００５】
ＢＳ２６内の各セクタは、そのセクタを識別し、かつＭＳ２４が容易にデコードできるパイロットチャンネルを一斉送信する。セクタおよびパイロットチャンネルは、いずれも擬似ノイズ（ＰＮ）オフセットによって区別される。用語「パイロット」は、パイロットチャンネルがセクタを識別することから、用語「セクタ」とほとんど相互交換可能に使用される。
【０００６】
パイロットチャンネルは、ＭＳに対して黙示的にタイミング情報を提供し、コヒーレントな復調にそれが使用されるが、そのほかは通常、いかなるデータも含んでいない。ＭＳは、最初に立ち上げられたとき、パイロットチャンネルのサーチを開始する。ＭＳがパイロットチャンネルを獲得すると（それが復調できると）、パイロットチャンネル内の黙示的なタイミング情報によってＭＳは、迅速かつ容易に、ネットワークによって送信されている同期チャンネルを復調することができる。
【０００７】
同期チャンネルには、より詳細なタイミング情報が含まれていることから、ＭＳが同期チャンネルを獲得した後は、ＭＳは、パイロットチャンネルを送信している同一のＢＳによって送信されているページングチャンネルを獲得することができる。その種のＢＳは、アクティブＢＳと呼ばれる。
【０００８】
セルラネットワークが特定のＢＳを介してＭＳとの通信の開始を試みているとき、そのＢＳのページングチャンネル上において、そのＭＳに対して「ページ」が送信される。従って、ＭＳが、一旦、特定のＢＳのページングチャンネルを復調できるようになった後は、そのＭＳがアイドル状態にあり、到来接続または到来メッセージを待機している間、そのページングチャンネルをモニタすることができる。
【０００９】
概して、各ＢＳは、すべてのＭＳが共通に受信する、１つのパイロットチャンネル、１つの同期チャンネル、および１つのページングチャンネルを使用する。しかしながら、１つのページングチャンネルを使用して同時にページング可能なＭＳの数に実用上の制限があることから、中には複数のページングチャンネルを使用するＢＳもある。
【００１０】
逆方向チャンネルは、アクセスチャンネル、１ないしは複数の逆方向トラフィックチャンネルを含むことができる。ＭＳが到来「ページ」をＢＳから受信した後は、ＭＳは、一部においてアクセスチャンネルを使用して接続のセットアップを開始することになる。
【００１１】
前述したチャンネルは、各種のコード化の手法を使用することができる。時分割多元アクセス（ＴＤＭＡ）では、複数のチャンネルが一定の時間ウインドウ内において特定の周波数で通信されることが可能であり、そのウインドウ内の異なるタイミングを用いてそれらが送信される。つまり、たとえばチャンネルＸは、時間スロットの１セットを使用し、チャンネルＹは、時間スロットの別のセットを使用する。周波数分割多元アクセス（ＦＤＭＡ）では、一定の周波数ウインドウ内において特定の時間に複数のチャンネルが通信されることが可能であり、そのウインドウ内の異なる周波数を用いてそれらが送信される。符号分割多元アクセス（ＣＤＭＡ）では、周波数および時間の空間が与えられ、特定のウォルシュコードまたは擬似直交関数（ＱＯＦ）に従って各チャンネルに各種の周波数および各種の時間が割り当てられる。このコードは、特定のチャンネルが周波数および時間に関してどのように変化するかを定義することになる。ダイレクトシーケンスＣＤＭＡにおいては、各チャンネルからのデータがウォルシュコードまたはＱＯＦを使用してコード化され、その後、１つの合成信号に組み合わせられる。この合成信号が、特定の時間において広い周波数範囲にわたって拡散される。この合成信号を、オリジナルデータのコード化に用いられたのと同一のコードを使用してデコードすれば、オリジナルデータを抽出することができる。ウォルシュコードおよびＱＯＦは、組み合わされた時に互いに干渉しないコード化データを生成し、その結果、後の時点において各種のチャンネル上でその情報を回復するようにデータを拡散することができるので、このようなオリジナルデータの回復が可能になる。言い換えると、データの２つのコード化済みシーケンスが互いに加算されて第３のシーケンスを生成するとき、その第３のシーケンスをオリジナルのコードと相関させることによって、オリジナルのシーケンスを回復することができる。特定のコードを用いて復調するときは、ほかのコードの知識が必要とはならない。しかしながらノイズおよび混信によって、何が実際に送信されたかについての決定を行うためにエラー修正が必要となることがある。
【００１２】
例示のみを目的としてさらにＣＤＭＡについて述べると、ウォルシュコードまたはＱＯＦは、特定のチャンネルのコード化に使用される。したがって、前述したように、パイロットチャンネルをデコードするための単純な形は、すべてが１にコード化されたＷ０ウォルシュコードとすることができる。同様に、同期チャンネルは、交番極性のＷ３２ウォルシュコードを使用することが可能であり、これらのコードは一定かつ既知である。
【００１３】
各ＭＳは、チャンネルを各種のセットにグループ化し、それには、限定を意図するわけではないが、アクティブセット、近隣セット、候補セット、および残余セットを含むことができる。
【００１４】
ＭＳアクティブセットは、任意の時点においてＭＳが使用しているパイロットまたはＰＮオフセット識別子を含んでいる。すなわち、ＭＳがアイドル状態にあるが、ページングおよびオーバーヘッドの更新のために単一のＢＳをモニタしているとき、そのＭＳに関するアクティブセットは、その唯一のメンバとしてそのＢＳのパイロットまたはＰＮオフセット識別子を含むことになる。
【００１５】
しかしながら、ＭＳが１つのＢＳまたはセクタからほかへハンドオフされている時、このハンドオフの間は、同時に複数のＢＳまたはセクタと実際に通信していることがある。このような状況が生じると、アクティブセット内に、同時に複数のアクティブパイロットが存在することになる。たとえば、「ソフトハンドオフ」においては、ＢＳ「Ａ」と通信しているＭＳが、最初にＢＳ「Ａ」を削除することなくＢＳ「Ｂ」との通信を開始し、その結果としてＢＳ「Ａ」およびＢＳ「Ｂ」がともにアクティブセット内に存在することになる。「ソフターハンドオフ」においては、ＢＳ「Ａ」内のセクタ「Ａ」と通信しているＭＳが、最初にセクタ「Ａ」を削除することなくＢＳ「Ａ」内のセクタ「Ｂ」との通信を開始し、その結果としてセクタ「Ａ」およびセクタ「Ｂ」がともにアクティブセット内に存在することになる。しかしながら、「ハードハンドオフ」においては、ＢＳ「Ａ」と通信しているＭＳが、最初にＢＳ「Ａ」を削除した後に限ってＢＳ「Ｂ」との通信を開始し、その結果として任意の時点においてアクティブセット内には、ＢＳ「Ａ」または「Ｂ」のいずれかが存在し、両方ともに存在することはない。
【００１６】
ＭＳが複数のＢＳと通信を行っている間は、そのＭＳがレーキ受信機のフィンガを１ないしは複数のセクタからの複数のチャンネルに同時に割り当てる。ＭＳが同時に複数のＢＳと通信を行っているときは、ＭＳは、それらのＢＳのそれぞれから同一のデータを受信している必要がある。しかしながら、データが同一であっても、チャンネルが異なるために、異なるＢＳからそれが異なって伝達される可能性もある。そのためレーキ受信機は、異なるチャンネル上において異なるセクタからのエンコード済みデータを受信し、それらのセクタを独立に復調し、その後それらのデータを結合する。データが結合されるときには、弱いチャンネルからのデータ、すなわちより多くのエラーを有する可能性のあるデータより、強いチャンネルからのデータに、より重い重み付けがなされる。このように、最終結果の生成においては、正しいとする公算がより高いデータに対して、より高い重み付けが与えられる。
【００１７】
ＭＳがアイドル状態の間は、共通チャンネル上において、アクティブＢＳの近隣となるＢＳを含む近隣セットがそのＭＳによって受信される。しかしながら、ＭＳがアクティブであり、トラフィックチャンネルを介してＢＳと通信を行っているときには、トラフィックチャンネル上において近隣セットが更新される。
【００１８】
そのほかの、ネットワーク内のアクティブセット、近隣セット、または候補セット（後述）内に含まれていないＢＳは、残余セットを構成する。図３に示されているように、ＭＳがアイドルかアクティブかによらず、ネットワークは、ＭＳに対してオーバーヘッドメッセージ３０、３２、および３４を繰り返し送信する。これらのオーバーヘッドメッセージは、ネットワークの構成に関する情報を含んでいる。たとえば、拡張された近隣のリストのオーバーヘッドメッセージ３４は、ＭＳに対して、存在する近隣およびそれらを探す場所について知らせる。これらの近隣識別子は、少なくとも一時的にＭＳのメモリ内に記憶される。
【００１９】
候補セットは、ＭＳがそのアクティブセットの一部として要求したが、まだアクティブセットに昇格されていないＢＳのセットである。これらの候補ＢＳは、ネットワークが、まだＭＳからのメッセージに応答してハンドオフ指示メッセージ（ＨＤＭ）を、すなわちそのＭＳにそれらのＢＳを含めるべくアクティブセットを変更する指示を送信していないために昇格されていない。通常、その種のメッセージの交換は、後述するように、ハンドオフプロセスの一部として生じる。
【００２０】
図４は、無線通信基盤５６の一般的な構造を図示している。クライアントＭＳ３６は、継続的に、ＢＳ３８等の近隣ＢＳから受信しているパイロットチャンネルの強度をモニタし、「パイロット追加スレッショルド値」より充分に強いパイロットをサーチする。近隣パイロットチャンネル情報、つまりこの分野において「近隣セット」として知られている情報は、セルクラスタ４２をコントロールすることが可能なＢＳコントローラ（ＢＳＣ）４０あるいは移動交換センタ（ＭＳＣ）４４を含むネットワーク基盤統一体を介してＭＳに伝達することができる。ここで理解しておく必要があるが、ＭＳおよび１つもしくは複数のネットワーク基盤統一体は、ＭＳおよびネットワークの機能をコントロールするための１ないしは複数のプロセッサを備えている。これらのプロセッサは、当業者であれば熟知しているメモリおよびそのほかの周辺装置を備える。１つのＢＳ３８によってサービスされている領域から別の領域へＭＳ３６が移動するとき、ＭＳ３６は、特定のパイロットを「近隣セット」から「候補セット」に昇格させ、ＢＳ３８または複数のＢＳに対して、「パイロット強度測定メッセージ」（ＰＳＭＭ）を介して、当該特定のパイロットの「近隣セット」から「候補セット」への昇格を通知する。またこのＰＳＭＭは、受信したパイロット信号の強度に関する情報も含んでいる。ＢＳ３８は、この「パイロット強度測定メッセージ」に従ってＢＳまたはネットワークの「アクティブセット」を決定し、ＨＤＭを介して新しい「アクティブセット」をＭＳ３６に通知することができる。しかしながら、ここで注意が必要であるが、処理しなければならないＢＳリソース問題をネットワークが有していることもあるため、新しいアクティブセットは、必ずしも常にＭＳの要求に正確に応じたものになるとは限らない。
【００２１】
ＭＳ３６は、古いＢＳ３８および新しいＢＳの両者との通信を、各ＢＳのパイロットの強度が「パイロット削除スレッショルド値」を超えている限り、維持することができる。１つのパイロットがこのパイロット削除スレッショルド値より弱くなると、ＭＳ３６は、その変化をＢＳに通知する。それによりＢＳは、新しい「アクティブセット」を決定し、ＭＳ３６に対してその新しい「アクティブセット」を通知する。ＢＳによる通知があると、ＭＳ３６は弱くなったパイロットを「近隣セット」に降格する。これは、ハンドオフのシナリオの一例である。接続が失敗したときに、ＭＳ３６がハンドオフを開始し、あるいはハンドオフのプロセスに入ることは一般的である。セルの境界近傍、パイロットの汚染のあるエリア、あるいはセルのブリージングによって著しく影響を受けているエリアには、一般にカバレッジが不充分かまたは信号の弱い環境が存在することからこの種のことが予測され、それらについてはすべて、この分野においてよく知られている。
【００２２】
接続の打ち切りは、いくつかの形で明らかになる。図５は、この分野においてＣＤＭＡ無線ネットワークに関する「レイヤ２確認応答障害」として知られる状況を示している。図５に示した例においては、ＭＳがＰＳＭＭ４８を送信してＢＳによる確認応答を要求している。ＢＳは、それを正確に受信できているが、図５に示したケースにおいては、そのＢＳの確認応答（ＡＣＫ）４６をＭＳが受信していない。ＭＳは、再送信カウンタに従ってメッセージをＮ１ｍ（＝９）回再送した後、接続を終了する（打ち切る）。「レイヤ２確認応答障害」が生じたメッセージがＰＳＭＭ４８である場合、つまりＭＳが接続を維持するために必要とするパイロットに関する要求を含むメッセージである場合に、このタイプの障害が生じることは一般的である。
【００２３】
図６は、ＣＤＭＡ無線ネットワークにおいて本発明を使用して回復が可能な第２の状況を示している。この状況は、この分野においては「順方向リンクフェード障害」として知られている。フェードは、受信信号パワーの減衰の期間である。この状況では、ＭＳがＮ２ｍ（＝１２）個の連続する不良フレーム５０を受信し、それに対する応答として、その送信機５２を停止させる。その後、Ｎ３ｍ（＝２）個の連続する良好フレームを、Ｔ５ｍ（＝５）秒後にフェードタイマがタイムアウトする前までに受信できなければ、ＭＳは、接続５４を打ち切る。ＭＳがパイロットを候補セットに昇格し、ＰＳＭＭの送信を必要としている期間、あるいはＭＳがＰＳＭＭを送信したが、まだハンドオフ指示メッセージを受信していない期間に、このタイプの障害が生じることは一般的である。
【００２４】
「レイヤ２確認応答障害」および「順方向リンクフェード障害」は、過剰に高いフレームエラーレートまたは爆発的なエラーレートに起因して生じることがある。図７に図示されているように、チャンネル５８は、通常は持続時間が８０ミリ秒のスロット６０、つまりスーパーフレームに分割することができる。各スロットは、３つのフェーズ６２に分けることができる。これらのフェーズには、０、１、および２の番号が付されている。それらのフェーズの上にオーバーラップする形で４つのフレーム６４がある。これら４つのフレームは、スーパーフレームの境界で３つのフェーズとそろえられる。したがって各フレーム６４は、通常、２０ミリ秒の長さになる。各フレーム６４内には、ヘッダエリア６６、何らかの信号情報６８、およびおそらくは何らかのデータ７０が含まれている。ここで、フレーム６４が、異なる内容を持つことを理解する必要がある。あるフレームが信号およびデータを含み、別のフレームが信号のみを含み、さらに別のフレームがデータのみを含むということもある。各フレーム６４が異なるデータレートを有することも許容され、データレートは、フレームごとを基準に変更することができる。例示のいくつかの通信標準においては、４つのレートが存在する：すなわち、１／１、１／２、１／４、および１／８である。したがって、たとえば音声アクティビティがない場合には、１／８フレームレートを用いて情報を送信することができ、これは、より遅いレートを用いて情報を伝達すれば必要な電力または帯域幅がより低く抑えられることから有利である。
【００２５】
実用的な通信ネットワークにおいては、ゼロパーセントのエラーレート（つまり、すべてのフレームが適正に受信されること）を目標とすることが現実的でも、また望ましいことでもない。むしろ、たとえば１パーセントのエラーレートが目標とされる。パワーコントロールループは、実際にこのフレームエラーレートをコントロールしている。この例の場合、フレームエラーレートが上昇して１パーセントを超えると、パワーコントロールループが、ＭＳによって送信される信号のパワーを増加し、その結果、フレームエラーレートが約１パーセントまで減少する。これに対して、フレームエラーレートが１パーセントより小さい場合には、パワーコントロールループが、送信パワーを下げて電力を節約し、フレームエラーレートが１パーセントまで上昇することを許容する。したがってＢＳは、ＭＳが特定のエリア内を移動する間、あるいは他のタイプの混信が発生または終了するとき、コンフィグレーションメッセージ内のパワーコントロールビットを介して継続的に、エラーレートを約１パーセントに維持するため種々のパワーレベルにおいて送信するようにＭＳに対して指示を与える。ＭＳは、通常、ＢＳによって推奨されているパワーレベルを尊守する。それに加えて、ＢＳが、特定のチャンネルに関するその送信パワーを変更することもできる。つまり、ＢＳおよびＭＳはともに、継続的に、他方のパワーレベルを変更するために互いにフィードバックを与えることができる。しかしながら、ＢＳが、ＭＳからのフィードバックに基づいて、その送信機のパワーレベルの変更を必ずしも行う必要はない。
【００２６】
上記のパワーコントロールループにもかかわらず、セルラネットワーク内をＭＳが動き回り、物理的な障害、隣接チャンネルからの混信、およびセクタのエッジ近傍の場所に起因する信号強度ならびに信号品質における変動を経験しているときには、エラーレートを約１％にコントロールできなくなることがあり、エラーレートが許容不能なレベルに上昇すれば、接続の打ち切りが問題化する。そのため、打ち切りの危機にある接続を救済するメカニズムが必要とされている。
【００２７】
逆方向リンクを基礎とする救済手続または接続の再スタートは、以前からすでに提案されている。通常の逆方向リンクを基礎とする救済手続においては、ＭＳが救済チャンネルを送信し、その一方でネットワークが、１ないしは複数のセクタを使用して救済チャンネルの復調を試みる。しかしながら、提案されている接続の再スタートを基礎とする救済手続は、アクセスチャンネルを使用し、ＭＳがプロービングを行うことから多くの電力を必要とするだけでなく、大量の混信を導く。それに加えて、提案されている逆方向リンクを基礎とする救済手続は、順方向フェード状態の間に限って起動され、ＢＳに先行してＭＳが送信することから不完全であり、後に説明する理由から効率も低い。
【００２８】
（発明の要約）
ここでは、包括的に「順方向救済手続」（ＦＲＰ）と呼んでいる本発明の一実施態様は、セルラまたはＰＣＳ電話等のＭＳと、通信基盤またはネットワークとの間における信号落ちならびに接続の打ち切りを防止するための方法および装置に関するものである。ＦＲＰを使用して克服可能な障害シナリオの例には、順方向リンクのレイヤ２（Ｌ２）確認応答障害および、スレッショルド値を超える時間間隔にわたる信号落ちをもたらすフェードに起因する順方向リンク信号落ちが挙げられる。本発明の例として示す一実施態様は、ＭＳが、通信基盤から電波放射されている１ないしは複数のＢＳパイロットチャンネルを、打ち切りの危機にある接続を保存するために、ＭＳのアクティブセットに追加する機能を含む。このＢＳパイロットチャンネルは、「順方向リンク救済チャンネル」として知られており、ここでは「仮コードチャンネル」（ＡＣＣ）と呼ぶものとする。同時に、ネットワーク基盤が、ＦＲＰの間にＭＳによってモニタされる可能性の高い代替順方向リンクチャンネル上において送信を開始する。同じチャンネルがＭＳによってモニタされ、ネットワーク基盤によって送信に用いられるのであれば、打ち切りの危機にある接続を救済することが可能になる。このＡＣＣという用語は、特定のウォルシュコードまたは擬似直交関数によってチャンネルが定義される符号分割多元アクセス通信プロトコルへの適用にもっとも適しているが、用語ＡＣＣが、ここでの定義として、ＴＤＭＡにおける時間スロットもしくはＦＤＭＡにおける周波数スロット等の、チャンネルを定義するための任意のスキームを包含することに注意する必要がある。より詳細に述べるのであれば、符号分割多元アクセス（ＣＤＭＡ）無線通信システムにおける、本発明の実行や使用は好ましい実施態様である。ＣＤＭＡ無線通信システムは下記の標準によって十分に詳しく説明されており、その全ては TELECOMMUNICATIONS INDUSTRY ASSOCIATION, Standards & Technology Department, 2500 Wilson Blvd., Arlington, VA 22201 によって公表されており、それらの全てが参照によりここに援用される： TIA/EIA-95B (１９９９年２月１日公表)；TIA/EIA/IS-2000 ，Volumes1-5, Release A, (２０００年３月１日公表)。本発明のこのほかの実施態様は、「好ましい実施態様の詳細な説明」という項目名を付した項目に説明されている。そのほかのメッセージプロトコルならびにデータ構造および通信システムを用いて本発明の別の実施態様を実施することは、当業者にとって簡単であろう。
【００２９】
（好ましい実施態様の詳細な説明）
以下、本出願の一部をなすとともに、本発明が実用化されえる特定の実施形態を図示した添付図面を参照しつつ、好ましい実施態様についての説明を行う。ここで理解される必要があるが、本発明の好ましい実施態様の範囲から逸脱することなく、そのほかの実施態様が使用され、あるいは構造的な変更がなされることは可能である。さらに理解されたいことは、ここで述べられる説明は、説明のみを目的として基本的にＣＤＭＡ通信プロトコルに言及しているが、本発明の実施態様は、そのほかの通信プロトコルならびにディジタル無線技術に広く適用可能であるということであり、限定する意図ではないが、それにはＣＤＭＡ、ＴＤＭＡ、ＦＤＭＡ、ＧＳＭ、ＧＰＲＳ等も含まれる。
【００３０】
（順方向救済手続の要約）
本発明は、通信ネットワークにおけるＭＳと通信基盤との間の信号落ちならびに接続の打ち切りを防止するための方法および装置を包含する。ここで言う接続は、限定する意図ではないが、音声、マルチメディアビデオおよびオーディオストリーミング、パケット交換データおよび回路交換データコール、ショートメッセージシーケンスまたはデータバースト、およびページングを含む。ここでは包括的に「順方向救済手続」（ＦＲＰ）と呼んでいる本発明は、ＭＳまたはＢＳにおいて、回復しなければ接続の打ち切りを招くことになる障害からのシステムの回復を可能にする。ＦＲＰを使用して克服可能な障害のシナリオの例には、順方向リンクのレイヤ２（Ｌ２）確認応答障害およびスレッショルド値を超える時間間隔にわたって信号落ちをもたらすフェードに起因する順方向リンク信号落ちが挙げられる。潜在的な接続の打ち切りの状況に応答して、ＭＳは、打ち切りの危険にある接続を救済するために、自主的に、そのレーキ受信機のアクティブセットにＢＳパイロットチャンネルを追加する。同時に、ネットワーク通信基盤は、ＦＲＰの間にＭＳによってモニタされる可能性の高い代替順方向リンクチャンネル上において送信を開始する。同じチャンネルがＭＳによってモニタされ、通信基盤によって送信に用いられるのであれば、打ち切りの危機にある接続を救済することが可能になる。
【００３１】
本発明の実施態様に従った一般的なＦＲＰには、ＭＳＦＲＰが含まれ、またインフラストラクチャ（通信基盤）ＦＲＰを含めることもできる。
【００３２】
図８は、典型的な接続救済におけるＭＳＦＲＰおよび通信基盤ＦＲＰの時間列の一例を示している。前述したようにＭＳＦＲＰがすべての救済の中心となり、インフラストラクチャＦＲＰは、推奨されるが厳密に必要とはされない。
【００３３】
ＭＳＦＲＰのトリガは、発生する障害の種類に依存する。レイヤ２障害の場合であれば、ＦＲＰが、確認応答を求めるメッセージの、多数回にわたる再送信の失敗に応答して起動される。順方向リンクフェード障害の場合には、スレッショルド値を超える時間間隔にわたって信号落ちが存在するときＦＲＰが起動される（参照番号７２を参照）。
【００３４】
救済の試行が開始される時点においては、ＭＳがＦＲＰタイマをスタートする（参照番号７４を参照）。救済が完了する前にＦＲＰタイマがタイムアウトすると、接続が打ち切られる。それに加えてＭＳは、救済の試行が開始された時点において、その送信機をオフにし、新しいアクティブセットを選択する（参照番号７４を参照）。この実施態様においては、事実上ＭＳが、それが送信したＰＳＭＭ（１ないしは複数）に基づいてハンドオフ指示を仮定する（そのＰＳＭＭが実際に送信されたか否か、送信に成功したか否か、あるいは確認応答があったか否かによらない）。言い換えると、ＭＳは、ハンドオフ指示なしに自発的にパイロットを「アクティブセット」に昇格させる（つまり、新しいアクティブセットは、古いアクティブセットと自発的に昇格させたアクティブパイロットの和集合になる：Ｓ”＝Ｓ Ｕ Ｓ’）（参照番号７６を参照）。その後ＭＳは、救済チャンネルをサーチするために、この新しい「アクティブセット」内の循環を開始する。前述したように、救済チャンネルという用語は、各種の通信プロトコルによって使用されるチャンネルを定義するための各種スキームを包含しているが、開示の簡素化を目的として、ここでは救済チャンネルを、「仮コードチャンネル」（ＡＣＣ）（参照番号７８を参照）と同一視する。
【００３５】
すでに述べたが、インフラストラクチャＦＲＰは、推奨されてはいるが、ネットワーク内の各ＢＳに厳密に必要とされてはいない。インフラストラクチャＦＲＰが実行される場合には（参照番号８０を参照）、通信基盤（ネットワーク）は、ＡＣＣを送信することになるセクタを選択する。
【００３６】
本発明の一実施態様においては、救済の間にわたりＡＣＣを介してゼロ（ブランク）データが送信される。そのほかの実施態様においては、ＡＣＣを介してデータが伝達されることもあるが、ＭＳは、実際にそのＡＣＣを見つけて復調に成功する場合にもそのデータのヒアリングのみを行う。
【００３７】
ある時点においてＭＳが、Ｎ３Ｍ個のＡＣＣの良好なフレームを見つけてその復調を行うと（参照番号８２を参照）、その送信機をオンにし、ＢＳに対する送信を開始する。ＭＳおよびＢＳがともにあらかじめ決定された数の良好なフレームを受信すると、救済が完了し（参照番号８４を参照）、ＢＳは、そのＭＳをより永続的なチャンネルに割り当てし直す。それに加えて、ネットワークが、たとえばオーバーヘッドを介してＡＣＣの再割り当てを行うこともできる。さらにＢＳは、「救済完了ハンドオフ」メッセージ８６を送信することによって、ＭＳのアクティブセットの再割り当てを行い、救済後のクリーンアップを行うことができるが、そのメッセージには、「汎用」または「ユニバーサルハンドオフ指示」メッセージ等のすでに存在するハンドオフメッセージを再使用することが可能である。
【００３８】
次に、ＦＲＰの詳細について説明する。
【００３９】
（救済に先行するネットワーク機能）
前述したように、ＭＳは、切迫する接続の打ち切りの検出に先行して、ネットワークのコンフィグレーションパラメータを記憶している。一実施態様においては、これらのパラメータが、ＭＳによって単純に記憶される一定値である。それらのパラメータが前もってＭＳに既知であり、またそれらが変更されないことから、オーバーヘッドメッセージがこれらのパラメータを含んでいる必要はない。別の実施態様においては、これらのコンフィグレーションパラメータの変更が許容されており、そのためネットワークは、オーバーヘッド内においてそのコンフィグレーションをＭＳに送信しなければならない。
【００４０】
図３のオーバーヘッドメッセージ３０、３２、および３４に示されているコンフィグレーションパラメータの対応部は、ＭＳがアイドルのときに送信することができる。アイドル状態のＭＳについては、すべてのアイドル状態のＭＳが同一の情報を受信する必要があることから、コンフィグレーションパラメータの伝達に共通チャンネルを使用することができる。
【００４１】
（ＭＳの順方向救済手続き）
図９は、接続の打ち切りが切迫していることを検出し、かつその接続を救済するための、本発明の一実施態様に従ったＭＳの手続きを示したフローチャートである。
【００４２】
接続が切れかかり始めると、ディジタルセルラ電話のユーザに聞こえる会話が、とぎれとぎれの部分的なものとなるか、あるいはデータ接続の場合であればデータの遅れまたは喪失を経験するようになる。図５に示した「レイヤ２障害」が生じている「順方向／逆方向不平衡」の場合において（図９の参照番号８８を参照）、本発明の一実施態様におけるＭＳは、ＭＳの送信したメッセージに対する適正な確認応答をＭＳが受信せず、その後、Ｎ１ｍ（＝９）回にわたって適正な確認応答を受信することなくメッセージの再送信に失敗すると、接続の打ち切りが切迫しているものと判断する。一実施態様の場合には、これが、「パイロット強度測定メッセージ」（ＰＳＭＭ）もしくはその派生上において失敗した確認応答に関してのみ生じる。ここで注意が必要であるが、変数Ｎ１ｍおよびここで参照しているそのほかの類似の識別済みの変数は、前述した通信標準に定義されている変数である。しかしながら本発明の実施態様は、当該標準に定義されているとおりの変数の値に限定されることはない。
【００４３】
Ｎ１ｍ（＝９）回にわたる再送の後にＭＳが適正な確認応答を受信していない場合には、本発明を除いて、ＭＳは、最終的にあきらめてＢＳに対してリリースメッセージを送信する。このリリースメッセージは、事実上の接続の打ち切りである。ここで注意が必要であるが、図５に示されているＢＳからＭＳに対する最後のリリースメッセージは、ＭＳからＢＳに対するリリースメッセージがそれまでにＢＳによって受信されたか否かに依存して、送信されることもあれば、送信されないこともある。ＢＳがリリースメッセージを受信し、リリースメッセージをＭＳに返すことがあっても、ＭＳがそれを受信することはない。しかしながら、図９に示した本発明の一実施態様に従えば、ＭＳが、Ｎ１ｍ（＝９）回にわたる再送の後に適正な確認応答を受信していないならば、リリースメッセージの送信に代えて、ＭＳＦＲＰが起動され（参照番号９２を参照）、ＦＲＰタイムアウト期間をカウントするためにＦＲＰタイマがスタートされ（参照番号９６を参照）、さらにＭＳは、その後のＬ２障害を一時的に無視する。換言すると、ＭＳは、特定の時間間隔の後に接続の打ち切りを行わないことによって接続の維持を一時中断する。救済が完了する前にＦＲＰタイマがタイムアウトすると、そのとき接続が打ち切られる。それに加えて、ＭＳは、救済の試行を開始した時点において、確認応答に失敗したメッセージおよびそのほかの保留されているメッセージの再送信を一時中断し（参照番号９０を参照）、送信機をオフにする（参照番号９２を参照）。ＭＳの送信機がオフにされると、ほかのユーザには、そのＭＳから何も聞こえてこなくなる。しかしながらＭＳは、トラフィックチャンネルの状態は維持している。ＭＳは、アクティブ状態に関連付けされた、そのほかのすべての活動を継続する（参照番号９４を参照）。ここで注意が必要であるが、前述したようにＭＳの「レイヤ２障害」の検出は、逆方向ベースの救済手続きにも同様に適用することができる。
【００４４】
「順方向リンクフェード障害」の場合においては、スレッショルド値を超える時間間隔にわたって信号の喪失（Ｎ２ｍ個の不良フレーム）が存在するとき、接続の打ち切りが切迫していると考えられる。この状態が検出されたとき（参照番号９８を参照）、ＭＳは送信機をオフにし、順方向ＭＳフェードタイマ（Ｔ５ｍ）がスタートされる。しかしながらＭＳは、トラフィック（アクティブ）状態を維持する。本発明を除けば、Ｎ３Ｍ個の良好なフレームの受信前にフェードタイマがタイムアウトすると、接続が打ち切られる。一方、フェードタイマがタイムアウトする前に、連続するＮ３ｍ個の良好なフレームをＭＳが受信すると、ＭＳは送信機をオンに戻し、フェードタイマをリセットする。本発明の一実施態様においては、フェードタイマがタイムアウトする前の特定の時期、またはフェードタイマがタイムアウトしたときに、ＭＳＦＲＰが起動されて、ＦＲＰタイマがスタートされる（参照番号９６を参照）。ここで理解される必要があるが、ＦＲＰタイマはＭＳＦＲＰが起動されるのと同時にスタートしてもよく、また所定の遅延の後にスタートしてもよい。ＦＲＰタイマは、順方向ＭＳフェードタイマと等しく、あるいは類似してセットすることができる。その後のフェードタイマは、無視され（参照番号１００を参照）、ＭＳは、続くフェード障害を一時的に無視する。言い換えるとＭＳは、特定の時間間隔の後に接続の打ち切りを行わないことによって接続の維持を一時中断する。ＭＳＦＲＰの起動をフェードタイマのタイムアウトの直前まで遅延させることは可能であるが、フェードタイマのタイムアウトより早期に救済を開始する１つの理由として、ユーザが通信の失敗を経験する時間が長すぎると、ユーザがＭＳをオフにして手動で新しい接続を開始する可能性があり、それによって救済が排除されることが挙げられる。
【００４５】
ここで理解されたいことは、上記のＭＳＦＲＰを開始するための条件は単なる例示にすぎないということであり、本発明のほかの実施態様においては、ＭＳＦＲＰを開始するための条件が異なることもある。
【００４６】
ＭＳＦＲＰが開始された後、本発明の実施態様においては、ＭＳが最新のＰＳＭＭ（および可能性としては、それ以前のＰＳＭＭ）を検査し（参照番号１０２を参照）、アクティブセットへの昇格が指定されていたか、あるいはアクティブセットに維持することが指定されていたＰＳＭＭ（１ないしは複数）内のすべてのパイロットを追加（昇格）する。ここで注意が必要であるが、ＭＳはいかなる追加のＰＳＭＭもＢＳに送信しておらず、またいかなるハンドオフ指示を待機してもいないのであるから、ＭＳは、この時点において自発的に動作している。このパイロットのセットは、「仮ハンドオフ指示」（ＡＨＤ）を構成する（参照番号１０４を参照）。ここで、このＡＨＤが、送信もしくは受信が行われないことから、実際のメッセージではないことに注意する必要がある。むしろＡＨＤは、救済手続きの間にＭＳが行うアクティブセットに対する変更を記述するための用語にすぎないと言える。ここで注意しなければならないが、正常動作の間は、アクティブセットが特定の最大サイズに制限されるが、本発明の一実施態様においては、最大アクティブセットサイズが、救済の間に追加されるパイロットを収容するために一時的に拡張される。
【００４７】
ＡＨＤ内のパイロットのセットが決定された後、ＭＳＦＲＰは、そのＡＨＤ内の各パイロットの中でＭＳがサーチする１ないしは複数の「仮コードチャンネル」（ＡＣＣ）を決定しなければならない。救済コードが、このＡＣＣを定義する。ここでは、ＭＳがＡＣＣのためのパイロットをサーチするとき、そのパイロットがウォルシュコードまたはＱＯＦによって定義されたＡＣＣを送信しているものとＭＳが仮定することから「仮」という用語が使用されている。
【００４８】
ＭＳＦＲＰは、何らかのメカニズムによって事前にＡＣＣが既知となっている限り、インフラストラクチャＦＲＰに頼ることなく実行することができる。必ずしも相互に排他的でないＡＣＣを決定する方法は多数ある。ＡＣＣのデフォルトを、標準の中で指定された固定の値とすることができる。すべてのハンドオフを、初期的にデフォルトのＡＣＣに対するものとし、その後の確認応答に続いて、第２のハンドオフがＭＳに非ＡＣＣチャンネルを指示することができる。
【００４９】
ＡＣＣを、ＢＳ、セクタ、ネットワーク、またはシステムごとにオーバーヘッド内において指定することもできる。基本的にこのパラメータは、近隣ごとの近隣リストにおいて、あるいはグローバルに送信することができる。またグローバル、あるいはセクタ固有のＦＲＰＡＣＣとして、パラメータメッセージ（アクティブまたはアイドル）の１つにおいて送信することも可能である。ＡＣＣは、専用メッセージまたは命令において指定し、あるいはＭＳの「電子シリアル番号」（ＥＳＮ）もしくはそのほかのパラメータとＢＳパラメータ（１ないしは複数）の寄せ集め（ハッシュ）となるようにあらかじめアレンジして、ＭＳを異なるチャンネルに擬似ランダム分布させることもできる。
【００５０】
本発明の別の実施態様においては、ＭＳＦＲＰがリソースのソフト指定もサポートしている。すでに説明したように、オーバーヘッドメッセージが、特定のパラメータをＭＳに送信するために使用される。オーバーヘッドメッセージ内において送信されるパラメータの１つに、ＢＳごとに指定済みのＡＣＣを識別するウォルシュコードまたは擬似直交関数がある。このＡＣＣは、正常トラフィックチャンネルとは異なる。ソフト指定は、ＡＣＣの動的な変更が可能であることを意味する。これは、任意の時点においていずれのチャンネルを救済に使用可能とするか、あるいはＡＣＣの定義にいずれのウォルシュコードを使用するかについて、ネットワークがより効率的に決定することを可能にする。
【００５１】
複数のＡＣＣを救済用に指定することもできる。ＭＳが、たとえば異なるチャンネルに対してハッシュするようにしても良い。しかしながら、その種のチャンネルは、一時的な使用のみに関して、より少なく指定することが推奨される（好ましくは１つだけ）。救済完了のハンドオフは、厳密に求められているわけではいない。代替ＡＣＣを使用するか、あるいは他の救済を遅延することもできる。
【００５２】
「指定」チャンネルは、たとえば正常な順方向リソースとして別に必要とはならないとき、救済のためだけに使用されるので、指定リソースは、この特徴の厳密な必要条件ではない。救済機能が一時的に延期されることを除けば、不利益な影響が生じることもない。
【００５３】
ＡＣＣが決定された後、ＭＳは、関連するコードチャンネルを、新しいアクティブセット内の各アクティブパイロット用の「仮コードチャンネル」（ＡＣＣ）にセットする（参照番号１０６を参照）。本発明の一実施態様においては、続いてＭＳが、良好なＡＣＣの復調を試行するために、パイロット信号のサーチを行い、レーキ受信機のフィンガを割り当てることによって、新しいアクティブセットの復調ならびに監視を試行する（参照番号１０８を参照）。ここで、この時点において、ＭＳはまったく送信を行わないに注意すべきである。ＭＳは、「ＦＲＰタイマ」がタイムアウトするまで（参照番号１１０を参照）もしくはあらかじめ決定された数の連続する良好なフレームが受信されるまで（参照番号１１２を参照）、新しいアクティブセットの復調を継続的に試行する。
【００５４】
本発明の一実施態様においては、良好なＡＣＣのサーチを実行する間に、ＭＳが、レーキ受信機の能力に依存して、一度に１つのセクタだけを試すことや、あるいは一度に複数のセクタを試すことができる。ＭＳは、各セクタにおいて、設定済みの時間間隔にわたって良好なＡＣＣの復調を試行した後、次のセクタに移動することができる。図１０に示されている例においては、セクタＣ、Ｄ、およびＥだけが新しいアクティブセットの一部を構成するセクタであり、したがってＭＳは、これらのセクタを循環して良好なＡＣＣを捜す（参照番号１１４、１１６、および１１８を参照）。
【００５５】
本発明の一実施態様においては、ＭＳが新しいアクティブセットから良好なＡＣＣの復調を試行する間に、ＭＳがレーキ受信機のフィンガを複数のパイロットに割り当てることになる。しかしながら、救済の間は、ＭＳが、いずれのフィンガが良好なフレームを受信したかを決定することが困難なことがある。いずれのチャンネルが良好なＡＣＣを提供しているかを決定する際の困難性が、次の例に従って説明される。ここで、当初ＭＳが、Ａ、Ｂ、およびＣの３つのＢＳからなるネットワーク内において、ＣのＢＳと通信していたが、接続の打ち切りが切迫していることを検出し、ＭＳが、ＭＳＦＲＰを開始したと仮定する。さらに、当該ネットワークもまた、切迫している接続の打ち切りを検出し、したがってＢのＢＳにおいてＡＣＣを送信したものと仮定する。ＭＳは、いずれのＢＳがＡＣＣを送信しているかについて知らないことから、ＡおよびＢの両方のＢＳからのＡＣＣを復調するための試行において、ＭＳのレーキ受信機のフィンガを割り当てる。その後、ＭＳは、この復調した情報を結合してフレームを生成する。
【００５６】
結果として得られたフレームが不良である場合には、それがＢのＢＳからのチャンネルが良好に受信されなかったか、あるいはＡのＢＳによって復調後のデータが改ざんされたか、あるいはそのほかの理由に起因する可能性がある。結果として得られたフレームが良好な場合であっても、ＭＳは、いずれのＢＳが良好なＡＣＣを送信したかについて知ることができない。その場合においては、ＭＳが、いずれのＢＳが良好なＡＣＣを提供したかについて決定することができる追加の情報を得るために、一度に１つのＢＳを試さなければならない。この困難性のため、ＭＳＦＲＰの代替実施態様においては、ＭＳがレーキ受信機のフィンガを一度に単一のチャンネルおよびセクタだけに割り当て、それによって、良好なＡＣＣが見つかった場合には、ＭＳはどのＢＳが良好なＡＣＣを提供したかを決定することができる。
【００５７】
再度図９を参照するが、ＦＲＰタイマがタイムアウトする前に、ＭＳが、あらかじめ決定された数の連続する良好なフレーム（たとえば、Ｎ３ｍ（＝２フレーム））を受信できた場合には、送信機をオンし（参照番号１２０を参照）、新しいアクティブセット上における接続を継続し（参照番号１２２を参照）、それによって、成功した救済を完了する（参照番号１２４を参照）。受信が成功しなかったセクタに関する、新しく仮定したアクティブパイロットは、混信を招くだけであることから、ＭＳは、救済の完了後直ちにそれらを降格する必要がある。ＭＳは、信号強度の観察、記号コンバイナの重み付け、異なるチャンネルの復調における試行、あるいは基地局からの応答（つまり、ＨＤＭ）に基づいて降格するパイロットを選択することができる。
【００５８】
またＭＳは、現在のパイロット状態に基づいてＰＳＭＭの再構成および送信を行い、再送信カウンタおよび／またはフェードタイマをリセットすることもできる（参照番号１２６を参照）。ＢＳが、回復の完了およびアクティブセットの確認のためのハンドオフ指示の確認を送信することもあれば送信しないこともある（参照番号１２８を参照）。ＢＳがハンドオフ指示を送信する場合に、ＭＳは、それに応じてそのアクティブセットを更新する必要がある。ＦＲＰタイマがタイムアウトする前に、ＭＳが、あらかじめ決定された数の連続する良好なフレーム（たとえば、Ｎ３ｍ（＝２フレーム））を受信しなかった場合には（参照番号１１０を参照）、接続が終了する（打ち切られる）（参照番号１３０を参照）。
【００５９】
本発明の一実施態様においては、ＭＳが良好なＡＣＣの復調を試行する間に、ＭＳは、自律的かつ動的にそのアクティブセットを変更する。図１１は、動的アクティブセットを使用するＭＳＦＲＰのフローチャートを示している。この手続きは、図９に類似であるが、復調を試行するセクタのセットをＭＳが変更できる点が異なる。これは、救済の間における信号状態の変化に適応するため、および異なるセクタ上において救済を試行し、救済を成功させる機会を増加するために行われる。ＭＳが新しいアクティブセットの復調を試行している間であるが（参照番号１３２を参照）、ＦＲＰタイマがタイムアウトする前に（参照番号１３４を参照）、救済のための新しいセクタを捜しだすための試行において別のパイロットの強度をモニタする（参照番号１３６を参照）。充分な受信強度を伴ったパイロットが捜し出され、それが現在のアクティブセット内に含まれていなければ（参照番号１３８を参照）、ＭＳは、その新しいパイロットをＡＨＤに追加（昇格）する（参照番号１４０を参照）。またＭＳは、パイロットの強度が低下したとき、あるいは新しいパイロットのための空きを作るためにＡＨＤからパイロットを削除（降格）することもできる。たとえば、図１２に示されているように、ＭＳＦＲＰの一部として、パイロット信号Ａ、Ｂ、Ｃ、およびＤが、その信号強度に関してモニタされているとする。あるパイロットが、スレッショルドＴ＿ＡＤＤを超える信号強度を達成すると、ＭＳは、自律的にそのパイロットを候補セットおよびアクティブセットの両方に昇格する（例えば参照番号１４２を参照）。ＭＳは、充分な強度を持ったパイロットを自律的にアクティブセットに昇格することによって、新しいアクティブセットを作成することになる。
【００６０】
図１１に戻るが、その後ＭＳは、新しいＡＨＤに関連付けされたコードチャンネルを、各個別のセクタ用のＡＣＣにセットし（参照番号１４４を参照）、さらに新しいアクティブセットの復調を試行する（参照番号１３２を参照）。新しいパイロットが捜し出せなかった場合（つまり、パイロットの変更がない場合）には、ＭＳは、引き続き変更していないアクティブセットの復調を試行する（参照番号１３２を参照）。２つのパイロットが同一信号強度を有している場合には、ＭＳは、順番に両方とも試す決定を行うことができる。本発明の実施態様においては、任意数の、当業者間によく知られている方法論またはインテリジェントサーチアルゴリズムをＭＳＦＲＰに使用して、ＭＳにＡＣＣのサーチを行わせることができる。
【００６１】
最初は、ＭＳのオリジナルのアクティブセット内のパイロットが、切迫した接続の打ち切りを生じたが、最終的にこれらオリジナルのパイロットの１つが、救済のための最良のチャンネルを提供する可能性もあることから、良好なＡＣＣを捜すとき、ＭＳは、これらオリジナルのパイロットにおいてＡＣＣを捜し出す試行を行うこともできる。本発明の変形実施態様においては、古いメンバも含めて新しいアクティブセット内のすべてのメンバを同一の方法で扱うことも可能であり、あるいは古いアクティブセットのメンバを新しいアクティブセットの新しいメンバと異なる扱いにすることもできる。
【００６２】
動的アクティブセットを特徴とする変形実施態様においては、救済の間に、ＭＳがそのアクティブセットを変更するごとに、ＭＳが新しいＰＳＭＭメッセージを送信することができる。順方向ベースの救済においては、これにより、このＰＳＭＭを送信するのに合わせて、ＭＳが短時間の間その送信機をオンにする必要が生じることになるが、逆方向ベースの救済においては、単にＰＳＭＭが送信されることになる。ＭＳには、ＢＳが新しいアクティブセットを伴うこのＰＳＭＭを受信した否かが確実にわからないが、ＢＳがそのメッセージを受信した場合には、ＡＣＣの調整にそれが役立つことになる。
【００６３】
ここで理解する必要があるが、この動的アクティブセットは、順方向ベースおよび逆方向ベースの救済手続きの両方に適用することができる。
【００６４】
（インフラストラクチャの順方向救済手続き）
ＭＳＦＲＰだけを実行することによっても接続の救済を行うことは可能であるが、本発明の別の実施態様においては、インフラストラクチャＦＲＰを実行することもできる。これらの実施態様においては、救済の試行の間に、ＭＳおよびインフラストラクチャが継続的にパイロットの状態をモニタし、必要に応じて新しいＢＳ／セクタとそれぞれのアクティブセットの再シードを行うことができる。前述したように、ＭＳは、現存の、あるいは新しい候補を継続的にモニタし、別のＡＨＤを使用してアクティブセットにそれらを昇格することができる。同様にインフラストラクチャもまた、後述するように、状態またはＭＳの位置を継続的にモニタし、ＭＳに対して新しく適用可能なセクタに関するＡＣＣを指示することができる。本発明の一実施態様においては、ＭＳＦＲＰおよびインフラストラクチャＦＲＰが、２０ミリ秒内またはそれぞれの１フレーム内に起動される。
【００６５】
図１３は、本発明の一実施態様に従ったインフラストラクチャ（ネットワーク）ＦＲＰのフローチャートを示している。インフラストラクチャＦＲＰは、レイヤ２障害および順方向フェード障害の両方に対して類似している。インフラストラクチャＦＲＰは、複数のインフラストラクチャコンポーネントによる実行が可能であり、そのコンポーネントには、限定を意図するわけではないがＢＳ、ＢＳコントローラ、および移動交換センタが含まれる。しかしながら、明確化のために、ここでは単一のＢＳによって実行されるものとしてインフラストラクチャＦＲＰを説明する。
【００６６】
インフラストラクチャＦＲＰは、ＭＳが切迫した接続の打ち切りに遭遇していることをＢＳが間接的に検出する必要があることから、ＭＳＦＲＰとは異なる。「レイヤ２確認応答障害」の場合には、異常がまったくＢＳにわからないことからフェード状態の検出よりも困難になる。たとえばＢＳが、それに向けてＭＳが送信したすべてのＰＳＭＭメッセージを受信しており、それらのメッセージに対して確認応答メッセージをもって応答していることが考えられる。しかしながら、ＢＳは、ＭＳのメッセージに対して確認応答を続けているにもかかわらず、ＭＳが同一メッセージの再送信を継続していることに気付く。このことから、ＢＳは、順方向／逆方向不平衡状態、すなわちＭＳの送信または受信に問題が生じている状態を推測することができる。したがってＢＳは、それぞれに確認応答を行った後に、「ＦＲＰ反復受信スレッショルド」回数にわたりＭＳから同一のＰＳＭＭメッセージ（またはその均等メッセージ）を受信したことに基づいて、インフラストラクチャＦＲＰをトリガすることができる（参照番号１４６を参照）。ここで注意が必要であるが、ＢＳによるこの「レイヤ２障害」の検出は、前述したように、逆方向ベースの救済手続きに対しても適用することができる。
【００６７】
ＢＳが、切迫した接続の打ち切りを検出することができる別の方法は、ＭＳから受信しているメッセージがどのような種類のものであるかを決定することによってなしえる。たとえば、ＢＳがＭＳから繰り返しＰＳＭＭを受信する場合には、ＢＳは、それらを調べて、ＭＳが、それが有している以外のＢＳもしくはセクタを必要としていると判断することができる。このＰＳＭＭメッセージが、そのＭＳによって繰り返し送信される場合には、それが、ＢＳに対対して救済が有用であるというしるしになる。
【００６８】
ＭＳがフェード状態のために救済を必要としていることは、ＢＳが、フェードタイマの期間にわたって、あらかじめ決定された数の有効なフレームをそのＭＳからＢＳが受信したか否かをモニタすることによって検出できる（参照番号１４８を参照）。言い換えると、順方向フェードにおいては、ＭＳが送信を停止することから、ＢＳは、所定期間の後にそれを検出することが可能になる。インフラストラクチャＦＲＰの起動は、ＢＳが（１）ＰＳＭＭを受信し、ハンドオフ指示を送信したか、あるいは（２）フェードの間に確認応答を送信したいずれかの場合に好適となり得る。いずれの場合においても（参照番号１４６または１４８を参照）、図１３に示されているように、ＢＳがトラフィック（アクティブ）状態を維持し（参照番号１５０を参照）、ＢＳにおけるＦＲＰタイマをスタートする（参照番号１５２を参照）。
【００６９】
ＭＳＦＲＰの「フェードタイマ」の先行した起動と同様に、「レイヤ２確認応答」障害の場合に、起動のためのスレッショルドとして、Ｌ２ＡＣＫカウント（＝９）から減数されるカウントを供給することによって、オプションとして、インフラストラクチャＦＲＰを先行して起動するようにすることができる。それに加えて、インフラストラクチャＦＲＰの試行期間は、フェードのタイムアウトによって制限されると考えることもできる。たとえば、インフラストラクチャＦＲＰを、フェードの後半部分の間においてのみ開始できる。
【００７０】
すでに述べたように、動的アクティブセットを特徴とする変形実施態様においては、救済の間にＭＳは、ＭＳがそのアクティブセットを変更するごとに新しいＰＳＭＭメッセージを送信することができる。ＢＳによってＰＳＭＭが受信された場合には（参照番号１５４を参照）、ＢＳは、受信したＰＳＭＭの検討を行う（参照番号１５６を参照）。そのＰＳＭＭ内の、アクティブセットへの昇格が指定されているか、維持が指定されているすべてのパイロットは、それに続いて新しいアクティブセット内に含められる。
【００７１】
ＰＳＭＭがまったく受信されない場合には、近隣ＢＳのサブセットが新しいアクティブセットに追加すべきものとして選択される（参照番号１５８を参照）。ＢＳコントローラまたはインフラストラクチャ要素は、救済の開始前に何がそのＭＳ用のアクティブセットであったかを知っており、この時点においては、接続を救済するためにアクティブセットに追加するための追加的なＢＳまたはセクタを決定しなければならない。追加されるＢＳまたはセクタは、多数の要因に依存し、それには、限定する意図ではないが、最後にわかっているＭＳのアクティブセット、ＭＳの位置、ＭＳにもっとも近いセクタ、そのＭＳに関する以前のアクティブセット、そのＭＳのそのほかの履歴ならびに統計、およびＭＳが要求していた新しいパイロット等が含まれる。ここで注意が必要であるが、ＰＳＭＭを伴うＬ２確認応答障害の場合においては、ネットワークがそのＰＳＭＭを受信できたのであれば、すでにそのＰＳＭＭメッセージからＭＳが要求しているセクタを知ることができるため、ネットワークは、ＭＳがどのセクタを必要としているかを評価する必要がない。しかしながら、この情報が利用できない場合には、ネットワークは、上記の要因のすべてを使用して、ＭＳが救済のために必要としている可能性のあるセクタを評価する。ネットワークは、いずれのセクタ内にＭＳが存在するかを知っていることだけからそのＭＳの位置を決定できるのではなく、ＭＳがＧＰＳ機能を有している可能性、もしくはインフラストラクチャがネットワークベースのポジションの特定機能を有している可能性、あるいはシステムがネットワークによって補助されるポジションの特定機能を有している可能性からもそれが可能であることに注意する必要がある。
【００７２】
本発明のさらに別の実施態様においては、接続の救済のためにアクティブセットに追加されるための追加的なＢＳまたはセクタを決定するプロセスの間に、ネットワークが、救済が可能であり、かつ望ましいかを決定することになる。救済が望ましくないとされる理由はいくつか考えられる。たとえば、救済に必要とされているセクタが最大能力に達しており、帯域幅が不足することがある。言い換えると、インフラストラクチャＦＲＰが、接続を救済するためにはほかのチャンネルを持ち出す必要があるが、それを行うことによってそのセクタを使用する別の接続に順方向フェード障害を招くことになるポイントまでそのセクタにおける電力および混信が増加されるとすれば、そのＦＲＰはまったく利益をもたらさないことになる。むしろ、１つの接続と別の接続を単に交換したにすぎない。別の理由としては、ＡＣＣに割り当てるコードがそのセクタに不足していることが挙げられる。すでに述べたように、新しいチャンネルを開くときにはウォルシュコードまたは擬似直交関数が使用される。１つのセクタ内においてこれらのコードがすべて使用されていれば、新しいチャンネルを開くことができない。
【００７３】
上記の例は、逆方向ベースの救済手続きに代えてＦＲＰを使用することの１つの利点を示している。ＦＲＰにおいては、ＢＳが接続の救済を試行するか否かを決定し、それゆえ、救済がほかの接続に影響を与えないと判断した場合に、新しいチャンネルを開き、救済を試みる。これに対して逆方向ベースの救済手続きにおいては、ＭＳが、その救済の試行が現存するほかの接続に影響を与えるか否かについて知らずに、送信を開始し、追加的な電力消費および混信をもたらすことになる。
【００７４】
新しいアクティブセット内のパイロットのセットが決定された後、インフラストラクチャＦＲＰは、新しいアクティブセット内のＢＳが、新しいアクティブセット内の各パイロットから送信することになる１ないしは複数のＡＣＣを決定しなければならない。前述したようにウォルシュコードまたはＱＯＦがＡＣＣを定義する。
【００７５】
本発明の一実施態様においては、必ずしも相互に排他的である必要のないＡＣＣを決定するためのオプションが多数存在する。ＡＣＣのデフォルトを、標準の中に指定された固定の値とすることができる（つまり、ＡＣＣによって使用されるものとして確保された順方向ウォルシュコードを選択する）。ＡＣＣを、ＢＳ、セクタ、ネットワーク、またはシステムごとにオーバーヘッド内において指定することもできる。基本的にこのパラメータは、近隣ごとの近隣リスト内において、あるいはグローバルに送信することができる。またグローバルとして、あるいははセクタ固有のＦＲＰＡＣＣとしてパラメータメッセージ（アクティブまたはアイドル）の１つにおいて送信することも可能である。ＡＣＣを専用メッセージまたは命令において指定することもできる。
【００７６】
本発明の別の実施態様においては、インフラストラクチャＦＲＰがリソースのソフト指定もサポートしている。すでに説明したように、オーバーヘッドメッセージが、特定のパラメータをＭＳに送信するために使用される。オーバーヘッドメッセージ内において送信が可能なパラメータの１つに、指定済みＡＣＣを識別するウォルシュコードまたは擬似直交関数がある。このＡＣＣは、正常トラフィックチャンネルとは異なることになる。ソフト指定は、ＡＣＣの動的な変更が可能であることを意味する。これは、任意の時点においていずれのチャンネルを救済に使用可能とするか、あるいはＡＣＣの定義にいずれのウォルシュコードを使用するかについて、ネットワークがより効率的に決定することを可能にする。
【００７７】
複数のＡＣＣを救済用に指定することもできる。しかしながら、その種のチャンネルは、一時的な使用のみに関して、より少なく指定することが推奨される（好ましくは１つだけ）。救済完了のハンドオフは、厳密に求められているわけではない。代替ＡＣＣを使用するか、あるいはほかの救済を遅延することもできる。
【００７８】
「指定」チャンネルは、たとえば正常な順方向リソースとして別に必要とはならないとき、救済のためだけに使用されるので、指定リソースは、この特徴の厳密な必要条件ではない。救済機能が一時的に延期されることを除けば、不利益な影響が生じることもない。
【００７９】
新しいアクティブセットおよびＡＣＣが決定されると、その新しいアクティブセット内のＢＳは、関連する（符合した）ＡＣＣ（１ないしは複数）を使用してＭＳに順方向リンクを送信する（参照番号１６０を参照）。言い換えると、ＭＳがソフトハンドオフを行うために追加的なＡＣＣが使用可能になる。これらのＡＣＣは、接続が最初に失敗しつつあったときにそのＭＳが有していなかった１ないしは複数のセクタ上において送信される。
【００８０】
本発明の一実施態様においては、任意の時点において１つのセクタだけがＡＣＣの送信を行う。１つのセクタだけから送信を行うことには、順方向救済においては、ネットワークがそのトラフィックならびに能力を知っており、その中でＡＣＣを送信する場所および時期について調整可能であることから、救済による能力的な影響を最小化できるという利点がある。図１４の例に示されているように、ネットワークによるセクタのセット内の循環に従って、あるセクタが、設定された時間間隔１６２だけＡＣＣの送信を行って停止し、続いて別のセクタが送信を行うという形がとられる。
【００８１】
しかしながら、別の実施態様においては複数のセクタまたは複数のＢＳが同時にＡＣＣの送信を行うことができる。図１５は、ＡＣＣの送信が行われるセクタの動的選択を含むインフラストラクチャＦＲＰを示したフローチャートである。インフラストラクチャは、信号状態の変化、ＭＳの反応、または救済のためのセクタの異なる組み合わせの試行に依存して異なるＢＳセクタを選択することができる（参照番号１６４を参照）。セクタの再選択は、ＢＳがあらかじめ決定された数の連続する良好なフレームを受信しなかった場合（参照番号１６６を参照）であって、ＦＲＰタイマがタイムアウトしていない場合（参照番号１６８を参照）に実行される。ネットワークは、セクタ間を交換してリソースの使用を最小化しつつ、ＭＳを救済する機会を最大化することができる。
【００８２】
オプションとしてＢＳは、スロット化またはバースト／断続モードでＡＣＣを運用することが可能であり、それにおいては、任意の「ＦＲＰタイマ」（値の）期間内に、少なくともあらかじめ決定された数（Ｎ３ｍ）個の順方向フレームが送信され、その結果、ＭＳが救済される機会を持つことになる。同時にこれは、混信を最小化し、能力を最大化する。ＡＣＣは、危険な状態にある（つまり、弱い信号または近隣のＢＳ／セクタ上の高い電力に近づいている）接続が顕在化していないとき、オフにすることもできる。
【００８３】
ＢＳが新しい救済トラフィックチャンネルを起動した後、ＢＳは、ＭＳからのアップリンクの受信を試行する（参照番号１７０を参照）。セクタからの送信が最初になることから、ＭＳは、ＢＳが救済を試行していることを認識した後に限って送信を行うことになり、それが電力ならびに混信を最小化する。
【００８４】
前述したように、ＭＳＦＲＰにおいては、ＭＳが最新のＰＳＭＭ（および可能性としては、それ以前のＰＳＭＭ）を検査し、昇格が指定されていたか、あるいは維持が指定されていたＰＳＭＭ（１ないしは複数）内のすべてのパイロットをアクティブセットに追加（昇格）する。同様にインフラストラクチャＦＲＰは、受信済みのＰＳＭＭを使用して、そのアクティブセットに追加すべきパイロットを決定することが可能であり、また信号強度を基礎としてその決定を行うこともできる。それに加えて、インフラストラクチャＦＲＰが起動される場合には、近隣ＢＳを、インフラストラクチャによって維持されているアクティブセットに追加することができる。ここで注意が必要なことは、ＭＳおよびインフラストラクチャのＦＲＰのいずれもが、この時点において自発的に動作しており、したがっていずれも他方の新しいアクティブセットについて知らないことである。この状況の下に、図１６に例示されている本発明の実施態様においては、ＭＳＦＲＰが、その新しいアクティブセット内のパイロット間を循環して（参照番号１８０を参照）それらのパイロット内のＡＣＣのサーチを行うことになる。同時にインフラストラクチャＦＲＰは、その新しいアクティブセット内のパイロット間を循環して（参照番号１８２を参照）、それらのパイロット上においてＡＣＣを送信することになる。図１７は、救済手続き期間における自発的なパイロットの復調ならびに送信に関するいくつかの手法の例を示している。ＭＳおよびインフラストラクチャのＦＲＰによるパイロットの循環は、その手法の特定のセットに従って好ましく調整されており、少なくともＮ３ｍ個のフレームにわたっていくつかの送信がオーバーラップすること、したがって救済が可能になることが保証されている。この、送信がオーバーラップする期間においては、ＭＳが特定のセクタからのＡＣＣの復調を試行しているとき、同時にネットワークがそのセクタ上においてＡＣＣの送信を行っていることになる。
【００８５】
再度図１５を参照するが、ＢＳは、アップリンク上において、ＦＲＰタイマがタイムアウトする前に（参照番号１６８を参照）あらかじめ決定された数の連続する良好なフレームを受信できた場合には、ＭＳに対して「救済完了ハンドオフ」（ＲＣＨ）メッセージを送信し（参照番号１７２および１７４を参照）、救済を確認し、完了することができる（参照番号１７６を参照）。このＲＣＨは、そのＭＳを、そのＢＳに対して異なるコードチャンネルに割り当てるものであり、その結果、別のＭＳの救済にそのＡＣＣを再使用することが可能になる。ＢＳは、ＭＳに対してこのメッセージを、可能な限り迅速に送信する。その後ネットワークは、ＭＳによって送信されたアクティブセットに従ってそのアクティブセットを更新し、接続を継続することができる。
【００８６】
ＢＳが、アップリンク上において、ＦＲＰタイマがタイムアウトする前にあらかじめ決定された数の連続する良好なフレームを受信しなかった場合には、接続が終了する（打ち切られる）（参照番号１７８を参照）。
【００８７】
（順方向救済手続きの適用）
これまでは、一例としてＣＤＭＡセルラネットワークを使用する一般的なＦＲＰについて説明してきたが、この一般的なＦＲＰにおいて説明した打ち切りの危機にある接続の救済、順方向および複数の逆方向リンク、オーバーヘッドメッセージ、専用および共通チャンネル、およびＡＣＣといった基本的なコンセプトは、別のワイヤレスプロトコルならびに技術、たとえばページングシステム、衛星通信システム、コードレス電話システム、フリート通信システム等に適用可能であり、もしくは拡張可能である。たとえば、ＣＤＭＡおよびＴＤＭＡは、ともにチャンネルの概念を利用する。ここで説明したＢＳの概念は、中継機または各種のアンテナのダイバーシティスキーム、コードレスの基地、衛星またはそのほかの電話等を包含している。ここで説明したＭＳの概念は、ページャ、衛星電話、コードレス電話、フリート無線等を包含している。
【００８８】
ＦＲＰのキーとなる構成ブロックには、（１）失敗接続を有する危機にあるか、それを有している１ないしは複数の端末、（２）端末（１ないしは複数）が救済に関するリスニングを行う間、送信によって救済を開始する、１ないしは複数の端末に対して何らかのコントロールを行う実体物、および（３）その実体物からの送信の受信が成功したときにそれらの端末が行う、実体物に向けて返す送信の開始、が含まれる。
【００８９】
端末は、商用、軍事、またはその他の用途に使用される無線機とすることが可能であり、それには水中での使用、宇宙での使用、またはGlobalstarTMまたはIridiumTMタイプのシステムのような衛星と地上局または端末の間における使用が含まれる。また端末は、Ethernet（登録商標）等の共有有線を介して実体物に接続することも可能である。この場合、失敗しつつある接続を有している端末が、送信を停止し、実体物からそれに向けられた救済送信を受信するまで待機する。
【００９０】
より広い用途においては、制御を行なう実体物が、端末を救済すべき時期および救済すべき端末を決定できることから、救済に関するコントロールを有する。この意味においては、手続きが集約化され、したがって非集約化手続きに関連付けされる効率、遅延、および電力コントロールといったタイプの問題が克服される。
【００９１】
以上、本発明について、添付図面を参照し、その実施態様との関連において十分に説明してきたが、当業者にとっては各種の変更ならびに修正が明らかであることに注意が必要である。その種の変更ならびに修正は、付随する特許請求の範囲によって定義される本発明の範囲内に含まれると理解するべきである。
【図面の簡単な説明】
【図１】 無線通信システム内のセクタ間にわたり、異なる位置の間を動き回る移動局を図示している。
【図２】 無線通信システム内における移動局と基地局の間の通信リンクの一例を図示している。
【図３】 無線通信システム内において基地局から移動局へ通信されるオーバーヘッドメッセージを図示している。
【図４】 動き回っている移動局と通信する無線通信インフラストラクチャを図示している。
【図５】 「レイヤ２確認応答障害」に起因して通信の打ち切りを招くことになる移動局と基地局の間におけるメッセージシーケンスを図示している。
【図６】 無線通信ネットワーク内において順方向リンクのフェードからもたらされる接続の打ち切りを表したタイムラインである。
【図７】 無線通信ネットワーク内における使用のための、３つのフェーズおよび４つのフレームに分割されるスロットまたはスーパーフレームのタイムラインである。
【図８】 「順方向救済手続き」が起動されて接続の打ち切りが回避された、本発明の一実施態様のタイムラインである。
【図９】 本発明の一実施態様に従った移動局の手続きに関するフローチャートである。
【図１０】 本発明の一実施態様に従った良好な順方向仮コードチャンネルの復調の試行において３つのセクタを循環する移動局を示したタイムラインである。
【図１１】 本発明の一実施態様に従った動的アクティブセットを含む移動局の手続きに関するフローチャートである。
【図１２】 本発明の一実施態様に従って、スレッショルドを超えて信号強度が上昇したときにパイロットを自発的にアクティブセットに昇格する移動局を示した説明図である。
【図１３】 本発明の一実施態様に従ったインフラストラクチャの手続きに関するフローチャートである。
【図１４】 本発明の一実施態様に従って、３つのセクタ間を循環しつつ、各セクタから順方向仮コードチャンネル上において送信を行う基地局を示したタイムラインである。
【図１５】 本発明の一実施態様に従った動的セクタ選択を含むインフラストラクチャの手続きに関するフローチャートである。
【図１６】 本発明の一実施態様に従って、移動局アクティブセット内のパイロット間を循環しつつそれらのパイロット内のＡＣＣをサーチする移動局、およびその一方において基地局アクティブセット内のパイロット間を循環しつつそれらのパイロット上でＡＣＣを送信する基地局を示したタイムラインである。
【図１７】 本発明の一実施態様に従った救済手続き期間における自発的なパイロットの復調に関するいくつかの手法を図示するものである。
Claims (91)
- 複数のセクタおよび潜在的な失敗接続を有する移動局（ＭＳ）を備え、前記移動局（ＭＳ）がＭＳアクティブセットを有する通信ネットワークにおいて、潜在的な失敗接続を救済するための方法であって、
潜在的な失敗接続を検出し、
１ないしは複数のパイロットであって、各々が前記複数のセクタの１つに対応するパイロットを前記ＭＳアクティブセットに追加し、
救済に使用するための１ないしは複数の仮コードチャンネル（ＡＣＣ）を決定し、
前記複数のセクタの少なくとも１つから前記仮コードチャンネル（ＡＣＣ）の１つを送信し、
前記移動局（ＭＳ）において、前記ＭＳアクティブセット内の前記パイロットに対応するセクタからの１ないしは複数の仮コードチャンネル（ＡＣＣ）をサーチし、
前記移動局（ＭＳ）において、前記複数のセクタの少なくとも１つから１ないしは複数の仮コードチャンネル（ＡＣＣ）が受信可能であることを発見し、および、
前記１ないしは複数の受信可能な仮コードチャンネル（ＡＣＣ）を発見した時に、前記移動局（ＭＳ）において接続を継続することを含む潜在的な失敗接続を救済する方法。 - 前記移動局（ＭＳ）における１ないしは複数の受信可能な仮コードチャンネル（ＡＣＣ）の発見が、前記複数のセクタの少なくとも１つから、前記仮コードチャンネル（ＡＣＣ）の、あらかじめ定められた数の連続する良好なフレームを受信することを含み、
前記１ないしは複数の受信可能な仮コードチャンネル（ＡＣＣ）を発見した時に前記移動局（ＭＳ）において接続を継続することが、前記移動局（ＭＳ）によってあらかじめ定められた数の連続する良好なフレームが受信された時に、前記移動局（ＭＳ）において前記接続を継続することを含む請求項１記載の方法。 - 前記移動局（ＭＳ）が、前記潜在的な失敗接続を検出する以前に１ないしは複数のパイロット強度測定メッセージ（ＰＳＭＭ）を送信するものであり、さらに、前記１ないしは複数のパイロット強度測定メッセージ（ＰＳＭＭ）内に含まれている情報に基づいて１ないしは複数のパイロットを前記ＭＳアクティブセットに追加することを含む請求項１記載の方法。
- 前記移動局（ＭＳ）が、前記潜在的な失敗接続を検出する以前に前記仮コードチャンネル（ＡＣＣ）に関する情報を含む１ないしは複数のオーバーヘッドメッセージを受信するものであり、さらに、前記１ないしは複数のオーバーヘッドメッセージ内に含まれている情報に基づいて前記救済に使用するための１ないしは複数の仮コードチャンネル（ＡＣＣ）を決定することを含む請求項１記載の方法。
- さらに、前記潜在的な失敗接続を検出した後に前記移動局（ＭＳ）からの送信を停止し、および、
前記移動局（ＭＳ）において、前記１ないしは複数のセクタから、前記仮コードチャンネル（ＡＣＣ）のあらかじめ定められた数の連続する良好なフレームを受信したとき、前記移動局（ＭＳ）からの送信を再開することを含む請求項１記載の方法。 - さらに、前記潜在的な失敗接続を検出した後に救済タイマをスタートし、および、
前記移動局（ＭＳ）においてネットワークからのダウンリンクが受信される前に前記救済タイマがタイムアウトすると、前記潜在的な失敗接続を終了することを含む請求項１記載の方法。 - さらに、前記救済の間に前記移動局（ＭＳ）によって測定されたパイロット信号強度情報に基づいて前記ＭＳアクティブセットを動的に変更することを含む請求項３記載の方法。
- さらに、前記ＭＳアクティブセットが自律的に変更されるごとに前記移動局（ＭＳ）からパイロット強度測定メッセージ（ＰＳＭＭ）を送信することを含む請求項７記載の方法。
- さらに、前記移動局（ＭＳ）において「レイヤ２確認応答障害」によって生じた前記潜在的な失敗接続を検出することを含む請求項１記載の方法。
- さらに、前記移動局（ＭＳ）によって送信されたメッセージに対する確認応答を前記移動局（ＭＳ）が受信していないとの決定を、前記移動局（ＭＳ）による前記メッセージの、あらかじめ定められた数の再送信の後に行うことによって、前記移動局（ＭＳ）において「レイヤ２確認応答障害」によって生じた前記潜在的な失敗接続を検出することを含む請求項９記載の方法。
- さらに、前記移動局（ＭＳ）において「順方向リンクフェード障害」によって生じた前記潜在的な失敗接続を検出することを含む請求項１記載の方法。
- さらに、前記移動局（ＭＳ）においてあらかじめ定められた数の連続する不良フレームを受信することによって、前記移動局（ＭＳ）において「順方向リンクフェード障害」によって生じた前記潜在的な失敗接続を検出することを含む請求項１１記載の方法。
- 前記ネットワークがネットワークアクティブセットを備え、さらに、
前記ネットワークアクティブセットに１ないしは複数のセクタを追加し、および、
前記ネットワークアクティブセットから、前記仮コードチャンネル（ＡＣＣ）の１つを送信する１ないしは複数のセクタを選択することを含む請求項１記載の方法。 - 前記接続を継続することが、さらに、
前記ネットワークが、前記移動局（ＭＳ）からあらかじめ定められた数の連続する良好なフレームを受信し、および、
前記ネットワークによって、前記あらかじめ定められた数の連続する良好なフレームが受信されると、前記ネットワークにおいて接続を継続することを含む請求項１３記載の方法。 - さらに、前記潜在的な失敗接続を検出した後に救済タイマをスタートし、および、
前記ネットワークにおいて前記移動局（ＭＳ）からのアップリンクが受信される前に前記救済タイマがタイムアウトすると、前記潜在的な失敗接続を終了することを含む請求項１３記載の方法。 - さらに、前記ネットワークにおいて「レイヤ２確認応答障害」によって生じた前記潜在的な失敗接続を検出することを含む請求項１３記載の方法。
- さらに、あらかじめ定められた数の再送信されたメッセージを前記移動局（ＭＳ）から前記ネットワークが受信した旨の決定を、あらかじめ定められた数の前記メッセージに対する確認応答が前記ネットワークによって送信された後に行うことによって、前記ネットワークにおいて「レイヤ２確認応答障害」によって生じた前記潜在的な失敗接続を検出することを含む請求項１６記載の方法。
- さらに、前記ネットワークにおいて「順方向リンクフェード障害」によって生じた前記潜在的な失敗接続を検出することを含む請求項１３記載の方法。
- さらに、あらかじめ定められた数の有効なフレームを前記移動局（ＭＳ）から前記ネットワークが受信していないことを検出することによって、前記ネットワークにおいて「順方向リンクフェード障害」によって生じた前記潜在的な失敗接続を検出することを含む請求項１８記載の方法。
- さらに、前記複数のセクタの少なくとも１つから前記仮コードチャンネル（ＡＣＣ）の１つを送信する前に、前記救済を試みるべきか否かを決定することを含む請求項１３記載の方法。
- さらに、前記ネットワークアクティブセットに１ないしは複数のセクタを、それらの位置、方位、システムまたは帯域に基づいて追加することを含む請求項１３記載の方法。
- さらに、前記ネットワークにおいて、前記移動局（ＭＳ）から１ないしは複数のパイロット強度測定メッセージ（ＰＳＭＭ）を受信し、および、
前記１ないしは複数のパイロット強度測定メッセージ（ＰＳＭＭ）内に含まれている情報に基づいて前記ネットワークアクティブセットに１ないしは複数のセクタを追加することを含む請求項１３記載の方法。 - さらに、前記救済において使用するための１ないしは複数の仮コードチャンネル（ＡＣＣ）を動的に変更することを含む請求項１３記載の方法。
- 複数のセクタ、および「Ｌ２確認応答障害」によって生じた前記セクタの１つとの潜在的な失敗接続を有する１ないしは複数の移動局（ＭＳ）を備えた通信ネットワークにおいて、その潜在的な失敗接続を救済するための方法であって：
前記「Ｌ２確認応答障害」によって生じた潜在的な失敗接続を検出し、
少なくとも１つの救済チャンネルを送信し、
前記複数のセクタの少なくとも１つによって前記救済チャンネルの送信が行われた場合には、前記救済チャンネルに関して前記複数のセクタの１ないしは複数をモニタし、
前記１ないしは複数の移動局（ＭＳ）によって前記救済チャンネルの送信が行われた場合には、前記救済チャンネルに関して前記移動局（ＭＳ）の１ないしは複数をモニタし、
１ないしは複数の救済チャンネルが受信可能であることを発見し、および、
１ないしは複数の受信可能な救済チャンネルが発見された時に前記接続を継続することを含む潜在的な失敗接続を救済するための方法。 - さらに、あらかじめ定められた数の再送信されたメッセージを前記移動局（ＭＳ）から前記ネットワークが受信したことの決定を、あらかじめ定められた数の前記メッセージに対する確認応答が前記ネットワークによって送信された後に行うことによって、前記ネットワークにおいて「レイヤ２確認応答障害」によって生じた前記潜在的な失敗接続を検出することを含む請求項２４記載の方法。
- さらに、前記移動局（ＭＳ）によって送信されたメッセージに対する確認応答を前記移動局（ＭＳ）が受信していない旨の決定を、前記移動局（ＭＳ）による前記メッセージの、あらかじめ定められた数の再送信の後に行うことによって、前記移動局（ＭＳ）において「レイヤ２確認応答障害」によって生じた前記潜在的な失敗接続を検出することを含む請求項２４記載の方法。
- 複数のセクタ、および潜在的な失敗接続を有する１ないしは複数の移動局（ＭＳ）を備える通信ネットワークにおいて、その潜在的な失敗接続を救済するための方法であって、
潜在的な失敗接続を検出し、
前記複数のセクタの少なくとも１つから、少なくとも１つの救済チャンネルの送信を行い、
前記救済チャンネルに関して前記複数のセクタの１ないしは複数をモニタするとともに、モニタされるセクタが動的に選択され、
１ないしは複数の救済チャンネルが受信可能であることを発見し、および、
前記１ないしは複数の受信可能な救済チャンネルが発見された時に前記接続を継続することを含む潜在的な失敗接続を救済するための方法。 - 複数のセクタ、および潜在的な失敗接続を有する１ないしは複数の移動局（ＭＳ）を備える通信ネットワークにおいて、その潜在的な失敗接続を救済するための方法であって、
潜在的な失敗接続を検出し、
動的に選択される１ないしは複数のターゲットセクタに向けて前記１ないしは複数の移動局（ＭＳ）から少なくとも１つの救済チャンネルを送信し、
前記少なくとも１つの救済チャンネルに関して前記１ないしは複数の移動局（ＭＳ）をモニタし、
少なくとも１つの救済チャンネルが受信可能であることを発見し、および、
前記少なくとも１つの受信可能な救済チャンネルが発見された時に前記接続を継続することを含む潜在的な失敗接続を救済するための方法。 - 複数のセクタ、および潜在的な失敗接続を有する１ないしは複数の移動局（ＭＳ）を備える通信ネットワークにおいて、その潜在的な失敗接続を救済するための方法であって、
潜在的な失敗接続を検出し、
前記複数のセクタの少なくとも１つから、少なくとも１つの救済チャンネルの送信を行うとともに、送信を行うセクタが動的に選択され、
前記救済チャンネルに関して前記複数のセクタの１ないしは複数をモニタし、
１ないしは複数の救済チャンネルが受信可能であることを発見し、および、
前記１ないしは複数の受信可能な救済チャンネルが発見された時に前記接続を継続することを含む潜在的な失敗接続を救済するための方法。 - 複数のセクタ、および潜在的な失敗接続を有する１ないしは複数の移動局（ＭＳ）を備える通信ネットワークにおいて、その潜在的な失敗接続を救済するための方法であって、
潜在的な失敗接続を検出し、
前記１ないしは複数の移動局（ＭＳ）から少なくとも１つの救済チャンネルを送信し、
前記複数のセクタの１ないしは複数から、前記少なくとも１つの救済チャンネルに関して前記１ないしは複数の移動局（ＭＳ）をモニタするとともに、前記複数のセクタの１ないしは複数が動的に選択され、
少なくとも１つの救済チャンネルが受信可能であることを発見し、および、
前記少なくとも１つの受信可能な救済チャンネルが発見された時に前記接続を継続することを含む潜在的な失敗接続を救済するための方法。 - 複数のセクタを備え、移動局（ＭＳ）との通信を可能にするための通信ネットワークであり、前記移動局（ＭＳ）は、潜在的な失敗接続を有し、かつ仮コードチャンネル（ＡＣＣ）の受信および前記潜在的な失敗接続の救済が可能であるネットワークにおいて、その潜在的な失敗接続の救済を補助する前記ネットワークの運用方法であって、
潜在的な失敗接続を検出し、
前記救済における使用のために１ないしは複数の仮コードチャンネル（ＡＣＣ）を決定し、および、
前記複数のセクタの少なくとも１つから前記仮コードチャンネル（ＡＣＣ）の１つを送信することを含む潜在的な失敗接続の救済を補助する前記ネットワークの運用方法。 - さらに、前記ネットワークにおいて「レイヤ２確認応答障害」によって生じた潜在的な失敗接続を検出することを含む請求項３１記載の方法。
- さらに、あらかじめ定められた数の再送信されたメッセージを前記移動局（ＭＳ）から前記ネットワークが受信した旨の決定を、あらかじめ定められた数の前記メッセージの確認応答が前記ネットワークによって送信された後に行うことによって、前記ネットワークにおいて前記「レイヤ２確認応答障害」によって生じた前記潜在的な失敗接続を検出することを含む請求項３２記載の方法。
- さらに、前記ネットワークにおいて「順方向リンクフェード障害」によって生じた前記潜在的な失敗接続を検出することを含む請求項３１記載の方法。
- さらに、あらかじめ定められた数の有効なフレームを前記移動局（ＭＳ）から前記ネットワークが受信していないことを検出することによって、前記ネットワークにおいて「順方向リンクフェード障害」によって生じた前記潜在的な失敗接続を検出することを含む請求項３４記載の方法。
- 前記ネットワークがネットワークアクティブセットを有し、さらに、
前記ネットワークアクティブセットに１ないしは複数のセクタを追加し、および、
前記ネットワークアクティブセットから、前記仮コードチャンネル（ＡＣＣ）の１つを送信する１ないしは複数のセクタを選択することを含む請求項３１記載の方法。 - さらに、前記潜在的な失敗接続を検出した後に救済タイマをスタートし、および、
前記ネットワークにおいて前記移動局（ＭＳ）からのアップリンクが受信される前に前記救済タイマがタイムアウトすると、前記潜在的な失敗接続を終了することを含む請求項３６記載の方法。 - さらに、前記複数のセクタの少なくとも１つから前記仮コードチャンネル（ＡＣＣ）の１つを送信する前に、前記救済を試みるべきか否かを決定することを含む請求項３１記載の方法。
- さらに、前記ネットワークアクティブセットに１ないしは複数のセクタを、それらの位置に基づいて追加することを含む請求項３６記載の方法。
- さらに、前記ネットワークにおいて、前記移動局（ＭＳ）から１ないしは複数のパイロット強度測定メッセージ（ＰＳＭＭ）を受信し、および、
前記１ないしは複数のパイロット強度測定メッセージ（ＰＳＭＭ）内に含まれている情報に基づいて前記ネットワークアクティブセットに１ないしは複数のセクタを追加することを含む請求項３６記載の方法。 - さらに、前記救済において使用するための１ないしは複数の仮コードチャンネル（ＡＣＣ）を動的に変更することを含む請求項３６記載の方法。
- 複数のセクタを備え、移動局（ＭＳ）との通信を可能にするための通信ネットワークであり、前記移動局（ＭＳ）は、「Ｌ２確認応答障害」によって生じた前記セクタの１つとの潜在的な失敗接続を有し、かつ救済チャンネルを送信して前記潜在的な失敗接続の救済が可能である通信ネットワークにおいて、前記潜在的な失敗接続の救済を補助する前記ネットワークの運用方法であって：
前記「Ｌ２確認応答障害」によって生じた潜在的な失敗接続を検出し、
前記救済チャンネルに関して前記移動局（ＭＳ）をモニタし、
前記救済チャンネルが受信可能であることを発見し、および、
受信可能な救済チャンネルが発見された時に前記接続を継続することを含む潜在的な失敗接続の救済を補助する前記ネットワークの運用方法。 - さらに、あらかじめ定められた数の再送信されたメッセージを前記移動局（ＭＳ）から前記ネットワークが受信した旨の決定を、あらかじめ定められた数の前記メッセージの確認応答が前記ネットワークによって送信された後に行うことによって、前記「レイヤ２確認応答障害」によって生じた前記潜在的な失敗接続を検出することを含む請求項４２記載の方法。
- 複数のセクタを備え、移動局（ＭＳ）との通信を可能にするための通信ネットワークであり、前記移動局（ＭＳ）は、前記セクタの１つとの潜在的な失敗接続を有し、かつ１ないしは複数のターゲットセクタに向けて救済チャンネルを送信し、前記潜在的な失敗接続を救済することが可能である通信ネットワークにおいて、前記潜在的な失敗接続の救済を補助する前記ネットワークの運用方法であって、
潜在的な失敗接続を検出し、
前記救済チャンネルに関して前記ターゲットセクタをモニタするとともに、前記ターゲットセクタが動的に選択され、
前記救済チャンネルが受信可能であることを発見し、および、
受信可能な救済チャンネルが発見された時に前記接続を継続することを含む潜在的な失敗接続の救済を補助する前記ネットワークの運用方法。 - 移動局（ＭＳ）と、複数のセクタを有する通信ネットワークの間の潜在的な失敗接続の救済を補助する移動局（ＭＳ）の運用方法であり、前記移動局（ＭＳ）はＭＳアクティブセットを有し、前記ネットワークは前記複数のセクタの少なくとも１つから１ないしは複数の仮コードチャンネル（ＡＣＣ）を送信することが可能であるものにおいて、
潜在的な失敗接続を検出し、
１ないしは複数のパイロットであって、各々が前記複数のセクタの１つに対応するパイロットを前記ＭＳアクティブセットに追加し、
前記ＭＳアクティブセット内の前記パイロットに対応するセクタからの１ないしは複数の仮コードチャンネル（ＡＣＣ）をサーチし、
前記複数のセクタの少なくとも１つから１ないしは複数の仮コードチャンネル（ＡＣＣ）が受信可能であることを発見し、および、
前記１ないしは複数の受信可能な仮コードチャンネル（ＡＣＣ）が発見された時に接続を継続することを含む潜在的な失敗接続の救済を補助する移動局の運用方法。 - 前記１ないしは複数の受信可能な仮コードチャンネル（ＡＣＣ）の発見が、前記複数のセクタの少なくとも１つから、前記仮コードチャンネル（ＡＣＣ）のあらかじめ定められた数の連続する良好なフレームを受信することを含み、かつ、
前記１ないしは複数の受信可能な仮コードチャンネル（ＡＣＣ）が発見された時に接続を継続することが、あらかじめ定められた数の連続する良好なフレームが受信された時に、前記接続を継続することを含む請求項４５記載の方法。 - 前記移動局（ＭＳ）が、前記潜在的な失敗接続を検出する以前に１ないしは複数のパイロット強度測定メッセージ（ＰＳＭＭ）を送信し、さらに、前記１ないしは複数のパイロット強度測定メッセージ（ＰＳＭＭ）内に含まれている情報に基づいて１ないしは複数のパイロットを前記ＭＳアクティブセットに追加することを含む請求項４５記載の方法。
- 前記移動局（ＭＳ）が、前記潜在的な失敗接続を検出する以前に前記仮コードチャンネル（ＡＣＣ）に関する情報を含む１ないしは複数のオーバーヘッドメッセージを受信し、さらに、前記１ないしは複数のオーバーヘッドメッセージ内に含まれている情報に基づいて前記救済に使用するための１ないしは複数の仮コードチャンネル（ＡＣＣ）を決定することを含む請求項４５記載の方法。
- さらに、前記潜在的な失敗接続を検出した後に前記移動局（ＭＳ）からの送信を停止し、および、
前記１ないしは複数のセクタから、前記仮コードチャンネルのあらかじめ定められた数の連続する良好なフレームを受信すると、前記移動局（ＭＳ）からの送信を再開することを含む請求項４５記載の方法。 - さらに、前記潜在的な失敗接続を検出した後に救済タイマをスタートし、および、
前記ネットワークからのダウンリンクが受信される前に前記救済タイマがタイムアウトすると、前記潜在的な失敗接続を終了することを含む請求項４５記載の方法。 - さらに、前記救済の間に前記移動局（ＭＳ）によって受信されたパイロット信号強度情報に基づいて前記ＭＳアクティブセットを動的に変更することを含む請求項４７記載の方法。
- さらに、前記ＭＳアクティブセットが動的に変更されるごとに前記移動局（ＭＳ）からパイロット強度測定メッセージ（ＰＳＭＭ）が送信されることを含む請求項５１記載の方法。
- さらに、「レイヤ２確認応答障害」によって生じた前記潜在的な失敗接続を検出することを含む請求項４５記載の方法。
- さらに、前記移動局（ＭＳ）によって送信されたメッセージに対する確認応答を前記移動局（ＭＳ）が受信していない旨の決定を、前記移動局（ＭＳ）による前記メッセージの、あらかじめ定められた数の再送信の後に行うことによって、「レイヤ２確認応答障害」によって生じた前記潜在的な失敗接続を検出することを含む請求項５３記載の方法。
- さらに、「順方向リンクフェード障害」によって生じた前記潜在的な失敗接続を検出することを含む請求項４５記載の方法。
- さらに、あらかじめ定められた数の連続する不良フレームを受信することによって、「順方向リンクフェード障害」によって生じた前記潜在的な失敗接続を検出することを含む請求項５５記載の方法。
- 移動局（ＭＳ）と、複数のセクタを備えた通信ネットワークの間の潜在的な失敗接続の救済を補助する移動局（ＭＳ）の運用方法であり、前記潜在的な失敗接続は「Ｌ２確認応答障害」によって生じるものであり、前記ネットワークは救済チャンネルに関して前記移動局（ＭＳ）をモニタし、かつ前記救済チャンネルを受信して前記潜在的な失敗接続を救済するものにおいて、
前記「Ｌ２確認応答障害」によって生じた潜在的な失敗接続を検出し、および、
前記複数のセクタの１ないしは複数に対して救済チャンネルを送信することを含む潜在的な失敗接続の救済を補助する移動局の運用方法。 - さらに、前記移動局（ＭＳ）によって送信されたメッセージに対する確認応答を前記移動局（ＭＳ）が受信していない旨の決定を、前記移動局（ＭＳ）による前記メッセージの、あらかじめ定められた数の再送信の後に行うことによって、前記「レイヤ２確認応答障害」によって生じた前記潜在的な失敗接続を検出することを含む請求項５７記載の方法。
- モバイルユーザとの通信を可能にするため、およびモバイルユーザとの潜在的な失敗接続を救済するための通信システムであって、
ネットワークプロセッサおよび信号の送信および受信のための複数のセクタを有し、前記ネットワークプロセッサは潜在的な失敗接続を検出するようにプログラムされているネットワーク、および、
ＭＳプロセッサおよび前記複数のセクタの１ないしは複数から信号を受信し、かつそこへ信号を送信するためのＭＳアクティブセットを有し、前記ＭＳプロセッサは前記複数のセクタの１ないしは複数との潜在的な失敗接続を検出するようにプログラムされている移動局（ＭＳ）を備え、
前記ネットワークプロセッサが、さらに、前記潜在的な失敗接続を検出した場合には、前記救済における使用のために１ないしは複数の仮コードチャンネル（ＡＣＣ）を決定し、かつ前記複数のセクタの少なくとも１つから前記仮コードチャンネル（ＡＣＣ）を送信するようにプログラムされており、
前記ＭＳプロセッサが、さらに、前記潜在的な失敗接続を検出した場合には、前記ＭＳアクティブセットに、各々が前記複数のセクタの１つに対応する１ないしは複数のパイロットを追加し、前記ＭＳアクティブセット内の前記パイロットに対応するセクタからの１ないしは複数の仮コードチャンネル（ＡＣＣ）をサーチし、前記複数のセクタの少なくとも１つから１ないしは複数の仮コードチャンネル（ＡＣＣ）が受信可能であることを発見し、および前記１ないしは複数の受信可能な仮コードチャンネル（ＡＣＣ）を発見した時に接続を継続するようにプログラムされている通信システム。 - 前記ＭＳプロセッサが、さらに、
前記潜在的な失敗接続を検出する以前に１ないしは複数のパイロット強度測定メッセージ（ＰＳＭＭ）を前記ネットワークに向けて送信し、および、
前記ＭＳプロセッサが潜在的な失敗接続を検出した場合には、前記１ないしは複数のパイロット強度測定メッセージ（ＰＳＭＭ）内に含まれている情報に基づいて１ないしは複数のパイロットを前記ＭＳアクティブセットに追加するようにプログラムされている請求項５９記載のシステム。 - 前記ＭＳプロセッサが、さらに、前記潜在的な失敗接続を検出した場合には、前記救済の間に前記移動局（ＭＳ）によって測定されたパイロット信号強度情報に基づいて前記ＭＳアクティブセットを自律的に変更するようにプログラムされている請求項５９記載のシステム。
- 前記ＭＳプロセッサが、さらに、「レイヤ２確認応答障害」によって生じた前記潜在的な失敗接続を検出するようにプログラムされている請求項５９記載のシステム。
- 前記ＭＳプロセッサが、さらに、「順方向リンクフェード障害」によって生じた前記潜在的な失敗接続を検出するようにプログラムされている請求項５９記載のシステム。
- 前記ネットワークがネットワークアクティブセットを備え、前記ネットワークプロセッサが、さらに、前記潜在的な失敗接続を検出した場合には、前記ネットワークアクティブセットに１ないしは複数のセクタを追加し、および前記ネットワークアクティブセットから、前記仮コードチャンネル（ＡＣＣ）の１つを送信する１ないしは複数のセクタを選択するようにプログラムされている請求項５９記載のシステム。
- 前記ネットワークプロセッサが、さらに、「レイヤ２確認応答障害」によって生じた前記潜在的な失敗接続を検出するようにプログラムされている請求項５９記載のシステム。
- 前記ネットワークプロセッサが、さらに、「順方向リンクフェード障害」によって生じた前記潜在的な失敗接続を検出するようにプログラムされている請求項５９記載のシステム。
- 前記ネットワークプロセッサが、さらに、前記救済における使用のための前記１ないしは複数の仮コードチャンネル（ＡＣＣ）を動的に変更するようにプログラムされている請求項５９記載のシステム。
- モバイルユーザとの通信を可能にするため、およびモバイルユーザとの、「Ｌ２確認応答障害」によって生じた潜在的な失敗接続を救済するための通信システムであって、
ネットワークプロセッサおよび信号の送信および受信のための複数のセクタを有し、前記ネットワークプロセッサは、「Ｌ２確認応答障害」によって生じた潜在的な失敗接続を検出するようにプログラムされているネットワーク、および、
ＭＳプロセッサおよび前記複数のセクタの１ないしは複数から信号を受信し、かつそこへ信号を送信するためのＭＳアクティブセットを有し、前記ＭＳプロセッサは、前記ネットワーク内の１ないしは複数の前記セクタとの、「Ｌ２確認応答障害」によって生じた潜在的な失敗接続を検出するようにプログラムされている移動局（ＭＳ）を備え、
前記ネットワークプロセッサが、さらに、前記潜在的な失敗接続を検出した場合には、前記複数のセクタの少なくとも１つから少なくとも１つの救済チャンネルを送信するようにプログラムされており、
前記ＭＳプロセッサが、さらに、前記潜在的な失敗接続を検出した場合には、前記救済チャンネルに関して前記複数のセクタの１ないしは複数をモニタし、１ないしは複数の救済チャンネルが受信可能であることを発見し、および前記１ないしは複数の受信可能な救済チャンネルを発見した時に前記接続を継続するようにプログラムされている通信システム。 - モバイルユーザとの通信を可能にするため、およびモバイルユーザとの、「Ｌ２確認応答障害」によって生じた潜在的な失敗接続を救済するための通信システムであって、
ネットワークプロセッサおよび信号の送信および受信のための複数のセクタを有し、前記ネットワークプロセッサは、「Ｌ２確認応答障害」によって生じた潜在的な失敗接続を検出するようにプログラムされているネットワーク、および、
ＭＳプロセッサおよび前記複数のセクタの１ないしは複数から信号を受信し、かつそこへ信号を送信するためのＭＳアクティブセットを有し、前記ＭＳプロセッサは、前記ネットワーク内の１ないしは複数の前記セクタとの、「Ｌ２確認応答障害」によって生じた潜在的な失敗接続を検出するようにプログラムされている移動局（ＭＳ）を備え、
前記ＭＳプロセッサが、さらに、前記潜在的な失敗接続を検出した場合には、救済チャンネルを送信するようにプログラムされており、
前記ネットワークプロセッサが、さらに、前記潜在的な失敗接続を検出した場合には、前記救済チャンネルに関して前記移動局（ＭＳ）をモニタし、１ないしは複数の救済チャンネルが受信可能であることを発見し、および前記１ないしは複数の受信可能な救済チャンネルを発見した時に前記接続を継続するようにプログラムされている通信システム。 - モバイルユーザとの通信を可能にするため、およびモバイルユーザとの潜在的な失敗接続を救済するための通信システムであって、
ネットワークプロセッサおよび信号の送信および受信のための複数のセクタを有し、前記ネットワークプロセッサは潜在的な失敗接続を検出するようにプログラムされているネットワーク、および、
ＭＳプロセッサおよび前記複数のセクタの１ないしは複数から信号を受信し、かつそこへ信号を送信するためのＭＳアクティブセットを有し、前記ＭＳプロセッサは１ないしは複数のセクタとの潜在的な失敗接続を検出するようにプログラムされている移動局（ＭＳ）を備え、
前記ネットワークプロセッサが、さらに、前記潜在的な失敗接続を検出した場合には、前記複数のセクタの少なくとも１つから少なくとも１つの救済チャンネルを送信するようにプログラムされており、
前記ＭＳプロセッサが、さらに、前記潜在的な失敗接続を検出した場合には、前記少なくとも１つの救済チャンネルに関して、動的に選択される前記複数のセクタの１ないしは複数をモニタし、１ないしは複数の救済チャンネルが受信可能であることを発見し、および前記１ないしは複数の受信可能な救済チャンネルを発見した時に前記接続を継続するようにプログラムされている通信システム。 - モバイルユーザとの通信を可能にするため、およびモバイルユーザとの潜在的な失敗接続を救済するための通信システムであって、
ネットワークプロセッサおよび信号の送信および受信のための複数のセクタを有し、前記ネットワークプロセッサは潜在的な失敗接続を検出するようにプログラムされているネットワーク、および、
ＭＳプロセッサおよび前記複数のセクタの１ないしは複数から信号を受信し、かつそこへ信号を送信するためのＭＳアクティブセットを有し、前記ＭＳプロセッサは１ないしは複数のセクタとの潜在的な失敗接続を検出するようにプログラムされている移動局（ＭＳ）を備え、
前記ＭＳプロセッサが、さらに、前記潜在的な失敗接続を検出した場合には、少なくとも１つの救済チャンネルを、１ないしは複数のターゲットセクタであって動的に選択されるターゲットセクタに向けて送信するようにプログラムされており、
前記ネットワークプロセッサが、さらに、前記潜在的な失敗接続を検出した場合には、前記少なくとも１つの救済チャンネルに関して前記移動局（ＭＳ）をモニタし、少なくとも１つの救済チャンネルが受信可能であることを発見し、および前記少なくとも１つの受信可能な救済チャンネルを発見した時に前記接続を継続するようにプログラムされている通信システム。 - モバイルユーザとの通信を可能にするため、およびモバイルユーザとの潜在的な失敗接続を救済するための通信システムであって、：
ネットワークプロセッサおよび信号の送信および受信のための複数のセクタを有し、前記ネットワークプロセッサは潜在的な失敗接続を検出するようにプログラムされているネットワーク、および、
ＭＳプロセッサおよび前記複数のセクタの１ないしは複数から信号を受信し、かつそこへ信号を送信するためのＭＳアクティブセットを有し、前記ＭＳプロセッサは前記１ないしは複数のセクタとの潜在的な失敗接続を検出するようにプログラムされている移動局（ＭＳ）を備え、
前記ネットワークプロセッサが、さらに、前記潜在的な失敗接続を検出した場合には、前記複数のセクタの少なくとも１つであって、動的に選択されるセクタから少なくとも１つの救済チャンネルを送信するようにプログラムされており、
前記ＭＳプロセッサが、さらに、前記潜在的な失敗接続を検出した場合には、前記少なくとも１つの救済チャンネルに関して前記複数のセクタの１ないしは複数をモニタし、１ないしは複数の救済チャンネルが受信可能であることを発見し、および前記１ないしは複数の受信可能な救済チャンネルを発見した時に前記接続を継続するようにプログラムされている通信システム。 - モバイルユーザとの通信を可能にするため、およびモバイルユーザとの潜在的な失敗接続を救済するための通信システムであって、
ネットワークプロセッサおよび信号の送信および受信のための複数のセクタを有し、前記ネットワークプロセッサは潜在的な失敗接続を検出するようにプログラムされているネットワーク、および、
ＭＳプロセッサおよび前記複数のセクタの１ないしは複数から信号を受信し、かつそこへ信号を送信するためのＭＳアクティブセットを有し、前記ＭＳプロセッサは前記１ないしは複数のセクタとの潜在的な失敗接続を検出するようにプログラムされている移動局（ＭＳ）を備え、
前記ＭＳプロセッサが、さらに、前記潜在的な失敗接続を検出した場合には、救済チャンネルを送信するようにプログラムされており、
前記ネットワークプロセッサが、さらに、前記潜在的な失敗接続を検出した場合には、動的に選択される前記複数のセクタの１ないしは複数から、前記救済チャンネルに関して前記移動局（ＭＳ）をモニタし、少なくとも１つの救済チャンネルが受信可能であることを発見し、および少なくとも１つの受信可能な救済チャンネルを発見した時に前記接続を継続するようにプログラムされている通信システム。 - 移動局（ＭＳ）との潜在的な失敗接続の救済を補助する通信システムであって、前記移動局（ＭＳ）は仮コード・チャンネル（ＡＣＣ）の受信および前記潜在的な失敗接続の救済が可能であるものにおいて、
ネットワークプロセッサおよび信号の送信および受信のための複数のセクタを有し、前記ネットワークプロセッサは前記潜在的な失敗接続を検出し、前記救済における使用のために１ないしは複数の仮コードチャンネル（ＡＣＣ）を決定し、および前記複数のセクタの少なくとも１つから前記仮コードチャンネル（ＡＣＣ）の１つを送信するようにプログラムされているネットワークを備える通信システム。 - 前記ネットワークプロセッサが、さらに「レイヤ２確認応答障害」によって生じた前記潜在的な失敗接続を検出するようにプログラムされている請求項７４記載のシステム。
- 前記ネットワークプロセッサが、さらに「順方向リンクフェード障害」によって生じた前記潜在的な失敗接続を検出するようにプログラムされている請求項７４記載のシステム。
- 前記ネットワークがネットワークアクティブセットを有し、前記ネットワークプロセッサが、さらに、前記ネットワークアクティブセットに１ないしは複数のセクタを追加し、かつ、前記ネットワークアクティブセットから、前記仮コードチャンネル（ＡＣＣ）の１つを送信する１ないしは複数のセクタを選択するようにプログラムされている請求項７４記載のシステム。
- 前記ネットワークプロセッサが、さらに、前記救済における使用のために１ないしは複数の仮コードチャンネル（ＡＣＣ）を動的に変更するようにプログラムされている請求項７７記載のシステム。
- 移動局（ＭＳ）との、「Ｌ２確認応答障害」によって生じた潜在的な失敗接続の救済を補助する通信システムであって、前記移動局（ＭＳ）は、前記移動局（ＭＳ）が前記潜在的な失敗接続を検出した場合に、前記システムに救済チャンネルを送信することが可能であるものにおいて、
ネットワークプロセッサおよび信号の送信および受信のための複数のセクタを有するネットワークを備え、
前記ネットワークプロセッサは前記「Ｌ２確認応答障害」によって生じた潜在的な失敗接続を検出し、前記救済チャンネルに関して前記移動局（ＭＳ）をモニタし、前記救済チャンネルが受信可能であることを発見し、および前記受信可能な救済チャンネルを発見した時に前記接続を継続するようにプログラムされている通信システム。 - 移動局（ＭＳ）との潜在的な失敗接続の救済を補助する通信システムであって、前記移動局（ＭＳ）は、前記移動局（ＭＳ）が前記潜在的な失敗接続を検出した場合に、前記システムに救済チャンネルを送信することが可能であるものにおいて、
ネットワークプロセッサおよび信号の送信および受信のための複数のセクタを有するネットワークを備え、
前記ネットワークプロセッサは前記潜在的な失敗接続を検出し、前記救済チャンネルに関して、１ないしは複数のターゲットセクタであり動的に選択されるターゲットセクタから前記移動局（ＭＳ）をモニタし、前記救済チャンネルが受信可能であることを発見し、および前記受信可能な救済チャンネルを発見した時に前記接続を継続するようにプログラムされている通信システム。 - ネットワークとの潜在的な失敗接続の救済を補助する移動局（ＭＳ）であって、前記ネットワークは前記潜在的な失敗接続の救済に使用されるための１ないしは複数の仮コードチャンネル（ＡＣＣ）を送信することができる複数のセクタを有するものにおいて、
ＭＳアクティブセット、および、
前記潜在的な失敗接続を検出し、前記ＭＳアクティブセットに、各々が前記複数のセクタの１つに対応する１ないしは複数のパイロットを追加し、前記ＭＳアクティブセット内の前記パイロットに対応するセクタからの１ないしは複数の仮コードチャンネル（ＡＣＣ）をサーチし、前記複数のセクタの少なくとも１つから受信可能な１ないしは複数の仮コードチャンネル（ＡＣＣ）を発見し、および前記１ないしは複数の受信可能な仮コードチャンネル（ＡＣＣ）を発見した時に接続を継続するようにプログラムされているＭＳプロセッサとを備える移動局。 - 前記ＭＳプロセッサが、さらに、前記潜在的な失敗接続を検出する以前に１ないしは複数のパイロット強度測定メッセージ（ＰＳＭＭ）を送信し、および前記ＭＳプロセッサが潜在的な失敗接続を検出した場合には、前記１ないしは複数のパイロット強度測定メッセージ（ＰＳＭＭ）内に含まれている情報に基づいて１ないしは複数のパイロットを前記ＭＳアクティブセットに追加するようにプログラムされている請求項８１記載の移動局。
- 前記ＭＳプロセッサが、さらに、前記潜在的な失敗接続を検出した場合には、前記救済の間に前記移動局（ＭＳ）によって受信されたパイロット信号強度情報に基づいて前記ＭＳアクティブセットを動的に変更するようにプログラムされている請求項８１記載の移動局。
- 前記ＭＳプロセッサが、さらに、「レイヤ２確認応答障害」によって生じた前記潜在的な失敗接続を検出するようにプログラムされている請求項８１記載の移動局。
- 前記ＭＳプロセッサが、さらに、「順方向リンクフェード障害」によって生じた前記潜在的な失敗接続を検出するようにプログラムされている請求項８１記載の移動局。
- 通信ネットワークとの「レイヤ２確認応答障害」によって生じた潜在的な失敗接続の救済を補助する移動局（ＭＳ）であって、前記通信ネットワークは救済チャンネルの受信および前記潜在的な失敗接続の救済が可能な複数のセクタを有するものにおいて、
前記「Ｌ２確認応答障害」によって生じた潜在的な失敗接続を検出し、および前記複数のセクタの１ないしは複数に前記救済チャンネルを送信するようにプログラムされているＭＳプロセッサを備える移動局。 - モバイルユーザとの通信を可能にするため、およびモバイルユーザとの潜在的な失敗接続を救済するための通信システムであって、
信号の送信および受信のための複数のセクタを有し、潜在的な失敗接続を検出するための第１の手段、および、
前記複数のセクタの１ないしは複数から信号を受信し、かつそこへ信号を送信するためのＭＳアクティブセットを有し、前記複数のセクタの１ないしは複数との潜在的な失敗接続を検出するための第２の手段を備え、
前記第１の手段が、前記潜在的な失敗接続を検出した場合に、前記救済に使用するために１ないしは複数の仮コードチャンネル（ＡＣＣ）を決定し、および前記複数のセクタの少なくとも１つから仮コードチャンネル（ＡＣＣ）を送信するためのものであり、
前記第２の手段が、前記潜在的な失敗接続を検出した場合に、前記ＭＳアクティブセットに、各々が前記複数のセクタの１つに対応する１ないしは複数のパイロットを追加し、前記ＭＳアクティブセット内の前記パイロットに対応するセクタからの１ないしは複数の仮コードチャンネル（ＡＣＣ）をサーチし、前記複数のセクタの少なくとも１つから１ないしは複数の仮コードチャンネル（ＡＣＣ）が受信可能であることを発見し、および前記１ないしは複数の受信可能な仮コードチャンネル（ＡＣＣ）を発見した時に接続を継続するためのものである通信システム。 - 前記第１の手段がネットワークアクティブセットを備え、前記第１の手段が、前記潜在的な失敗接続を検出した場合に、前記ネットワークアクティブセットに１ないしは複数のセクタを追加し、および前記ネットワークアクティブセットから、前記ＡＣＣの１つを送信する１ないしは複数のセクタを選択するためのものである請求項８７記載のシステム。
- 移動局（ＭＳ）との潜在的な失敗接続の救済を補助する通信システムであって、前記移動局（ＭＳ）は仮コードチャンネル（ＡＣＣ）の受信および前記潜在的な失敗接続の救済が可能であるものにおいて、
信号の送信および受信のための複数のセクタを有し、前記潜在的な失敗接続を検出し、前記救済に使用するために１ないしは複数の仮コードチャンネル（ＡＣＣ）を決定し、および前記複数のセクタの少なくとも１つから前記仮コードチャンネル（ＡＣＣ）の１つを送信するための手段を備える通信システム。 - 前記手段がネットワークアクティブセットを備え、前記手段が、前記ネットワークアクティブセットに１ないしは複数のセクタを追加し、および、
前記ネットワークアクティブセットから、前記仮コードチャンネル（ＡＣＣ）の１つを送信する１ないしは複数のセクタを選択するためのものである請求項８９記載のシステム。 - ネットワークとの潜在的な失敗接続の救済を補助するための移動局（ＭＳ）であって、前記ネットワークは前記潜在的な失敗接続の救済に使用するために１ないしは複数の仮コードチャンネル（ＡＣＣ）を送信することができる複数のセクタを有するものにおいて、
ＭＳアクティブセット、および、
前記潜在的な失敗接続を検出し、前記ＭＳアクティブセットに、各々が前記複数のセクタの１つに対応する１ないしは複数のパイロットを追加し、前記ＭＳアクティブセット内の前記パイロットに対応するセクタからの１ないしは複数の仮コードチャンネル（ＡＣＣ）をサーチし、前記複数のセクタの少なくとも１つから受信可能である１ないしは複数の仮コードチャンネル（ＡＣＣ）を発見し、および前記１ないしは複数の受信可能な仮コードチャンネル（ＡＣＣ）を発見した時に接続を継続するための手段を備える移動局。
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US24126800P | 2000-10-17 | 2000-10-17 | |
| US24890000P | 2000-11-14 | 2000-11-14 | |
| PCT/US2001/032464 WO2002033982A2 (en) | 2000-10-17 | 2001-10-16 | Forward link based rescue channel method and apparatus for telecommunication systems |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2004524720A JP2004524720A (ja) | 2004-08-12 |
| JP3948403B2 true JP3948403B2 (ja) | 2007-07-25 |
Family
ID=26934138
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2002536850A Expired - Fee Related JP3948403B2 (ja) | 2000-10-17 | 2001-10-16 | 遠距離通信システムのための順方向リンクベース救済チャンネル方法および装置 |
Country Status (6)
| Country | Link |
|---|---|
| US (2) | US7133675B2 (ja) |
| JP (1) | JP3948403B2 (ja) |
| KR (1) | KR100593866B1 (ja) |
| CN (1) | CN1265655C (ja) |
| AU (1) | AU2002215376A1 (ja) |
| WO (1) | WO2002033982A2 (ja) |
Families Citing this family (36)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7945266B2 (en) * | 2000-12-05 | 2011-05-17 | Qualcomm Incorporated | Method and apparatus for call recovery in a wireless communication system |
| US7567781B2 (en) | 2001-01-05 | 2009-07-28 | Qualcomm, Incorporated | Method and apparatus for power level adjustment in a wireless communication system |
| US7340017B1 (en) * | 2002-07-30 | 2008-03-04 | National Semiconductor Corporation | System and method for finger management in a rake receiver |
| KR20040061790A (ko) * | 2002-12-31 | 2004-07-07 | 에스케이 텔레콤주식회사 | Ｅｖ-ｄｏ 시스템의 핸드오프 실패를 복구하는 방법 및시스템 |
| CN1229937C (zh) * | 2003-05-28 | 2005-11-30 | 大唐移动通信设备有限公司 | 无线通信系统中多用户码道激活检测的方法和装置 |
| US7469146B2 (en) * | 2003-07-10 | 2008-12-23 | Telefonaktiebolaget Lm Ericsson (Publ) | Radio link management based on retransmission request performance |
| US7299047B2 (en) * | 2003-08-19 | 2007-11-20 | Lucent Technologies Inc. | Wireless communication system enhanced call recovery |
| US7813746B2 (en) * | 2003-10-24 | 2010-10-12 | Samsung Electronics Co., Ltd. | Wireless network using shared traffic channel mode of operation for broadcast services |
| FR2875077B1 (fr) * | 2004-09-09 | 2006-12-08 | Nortel Networks Ltd | Procede et dispositif de controle de la puissance d'emission d'un terminal mobile dans un systeme radio cellulaire, et terminal adapte a la mise en oeuvre du procede |
| DE102005031898B4 (de) * | 2005-07-07 | 2007-04-19 | Siemens Ag | Ermitteln der Ursache für einen Gesprächsabbruch bei einer Mobilfunkkommunikation |
| US7509150B1 (en) * | 2005-08-02 | 2009-03-24 | Itt Manufacturing Enterprises, Inc. | Reducing power consumption in a radio device by early receiver shut down |
| GB2431073B (en) * | 2005-10-10 | 2008-05-14 | Ipwireless Inc | Cellular communication system and method for co-existence of dissimilar systems |
| US7821996B2 (en) * | 2005-10-27 | 2010-10-26 | Motorola Mobility, Inc. | Mobility enhancement for real time service over high speed downlink packet access (HSDPA) |
| KR100994285B1 (ko) * | 2005-11-04 | 2010-11-15 | 엘지전자 주식회사 | 주파수분할 다중접속 시스템을 위한 랜덤 액세스 채널 호핑 |
| KR100848637B1 (ko) * | 2006-11-20 | 2008-07-28 | 에스케이 텔레콤주식회사 | 위치 측위를 위한 ｐｓｍｍ 수집 호 처리 방법 및 시스템 |
| US8290524B2 (en) | 2007-01-17 | 2012-10-16 | Qualcomm Incorporated | Systems and methods for maintaining a transmission during a channel fade |
| JP5003195B2 (ja) * | 2007-02-19 | 2012-08-15 | 沖電気工業株式会社 | 引率支援方法、引率支援システム及び引率支援装置 |
| JP4921590B2 (ja) * | 2007-06-11 | 2012-04-25 | テレフオンアクチーボラゲット エル エム エリクソン（パブル） | アップリンク−ダウンリンク間の不平衡を示すパラメータに基づく無線リソース管理 |
| US8391872B1 (en) * | 2007-07-17 | 2013-03-05 | Sprint Spectrum L.P. | Use of call drop and re-origination data to trigger handoff |
| US20090116422A1 (en) * | 2007-11-02 | 2009-05-07 | Chia-Chin Chong | Method and system for opportunistic hybrid relay selection scheme for downlink transmission |
| US20090116419A1 (en) * | 2007-11-05 | 2009-05-07 | Chia-Chin Chong | Method and system of threshold selection for reliable relay stations grouping for downlink transmission |
| US8472921B2 (en) * | 2009-02-13 | 2013-06-25 | Via Telecom, Inc. | Apparatus, method and system for reduced active set management |
| US20110194630A1 (en) * | 2010-02-10 | 2011-08-11 | Yang Hua-Lung | Systems and methods for reporting radio link failure |
| US8743681B2 (en) * | 2010-07-19 | 2014-06-03 | Verizon Patent And Licensing Inc. | Fault-tolerance and resource management in a network |
| JP5633568B2 (ja) * | 2010-09-17 | 2014-12-03 | 富士通株式会社 | 無線通信システム、リレー局、端末及び無線通信方法 |
| US8718627B1 (en) * | 2010-10-08 | 2014-05-06 | Sprint Spectrum L.P. | Method of transmitting reverse link signals from multiple mobile stations to improve reception quality |
| WO2012097467A1 (en) * | 2011-01-17 | 2012-07-26 | Telefonaktiebolaget L M Ericsson (Publ) | Method of allocating walsh codes and quasi-orthogonal functional codes in a cdma network |
| US8908504B2 (en) | 2011-07-01 | 2014-12-09 | Qualcomm Incorporated | Pre-agreed radio link failure recovery channel sequence |
| US9191862B2 (en) * | 2011-09-06 | 2015-11-17 | Qualcomm Incorporated | Method and apparatus for adjusting TCP RTO when transiting zones of high wireless connectivity |
| GB2509322A (en) * | 2012-12-28 | 2014-07-02 | Securenvoy Plc | Time-based two factor authentication |
| US8942708B2 (en) | 2013-01-30 | 2015-01-27 | Sprint Spectrum L.P. | Management of radio connection assignment in coverage area correlated with geographic region |
| US8983461B1 (en) * | 2013-02-11 | 2015-03-17 | Sprint Spectrum L.P. | Methods and systems for managing boomer sectors |
| CN105406950A (zh) | 2014-08-07 | 2016-03-16 | 索尼公司 | 用于无线通信的装置和方法、电子设备及其方法 |
| CN112218291B (zh) * | 2019-07-12 | 2023-12-19 | 海能达通信股份有限公司 | 语音通信方法、基站、移动终端及计算机可读存储介质 |
| US11343729B1 (en) | 2020-05-27 | 2022-05-24 | Sprint Spectrum L.P. | Dynamic air-interface reconfiguration based on predicted movement toward location where dual-connectivity tends to be lost |
| KR102377474B1 (ko) * | 2020-11-13 | 2022-03-23 | 이화여자대학교 산학협력단 | 파라미터 전이 lstm을 이용한 손실 데이터 복구 방법 및 장치 |
Family Cites Families (45)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US2002004A (en) * | 1933-08-07 | 1935-05-21 | Union Oil Co | Process for treating oil |
| SE460941B (sv) * | 1988-04-26 | 1989-12-04 | Ericsson Telefon Ab L M | Foerfarande i ett cellindelat mobiltelefonsystem att reducera spaerr vid oeverflyttning av samtal |
| US5301356A (en) | 1991-12-10 | 1994-04-05 | Telefonaktiebolaget L M Ericsson | Prioritization between handoff and new call requests in a cellular communications system |
| US5267261A (en) * | 1992-03-05 | 1993-11-30 | Qualcomm Incorporated | Mobile station assisted soft handoff in a CDMA cellular communications system |
| US5353332A (en) | 1992-09-16 | 1994-10-04 | Ericsson Ge Mobile Communications Inc. | Method and apparatus for communication control in a radiotelephone system |
| MX9307243A (es) | 1992-11-24 | 1994-05-31 | Ericsson Telefon Ab L M | Reintento analogico. |
| US5530912A (en) | 1994-06-29 | 1996-06-25 | At&T Corp. | Traffic driven channel reservation system for handovers in cellular networks |
| US5548812A (en) * | 1994-07-21 | 1996-08-20 | Qualcomm Incorporated | Method and apparatus for balancing the forward link handoff boundary to the reverse link handoff boundary in a cellular communication system |
| MY114291A (en) | 1995-01-31 | 2002-09-30 | Qualcomm Inc | Concentrated subscriber system for wireless local loop |
| US5673259A (en) | 1995-05-17 | 1997-09-30 | Qualcomm Incorporated | Random access communications channel for data services |
| US5729826A (en) | 1996-07-26 | 1998-03-17 | Gavrilovich; Charles D. | Mobile communication system with moving base station |
| US6021122A (en) * | 1996-06-07 | 2000-02-01 | Qualcomm Incorporated | Method and apparatus for performing idle handoff in a multiple access communication system |
| US5884174A (en) | 1996-06-07 | 1999-03-16 | Lucent Technologies Inc. | Call admission control for wireless networks |
| US5937019A (en) * | 1996-08-07 | 1999-08-10 | Qualcomm Incorporated | Method and apparatus for reliable intersystem handoff in a CDMA system |
| US6236365B1 (en) * | 1996-09-09 | 2001-05-22 | Tracbeam, Llc | Location of a mobile station using a plurality of commercial wireless infrastructures |
| JP3369063B2 (ja) * | 1996-10-18 | 2003-01-20 | 松下電器産業株式会社 | 移動通信端末 |
| US6061337A (en) * | 1996-12-02 | 2000-05-09 | Lucent Technologies Inc. | System and method for CDMA handoff using telemetry to determine the need for handoff and to select the destination cell site |
| US5913167A (en) | 1997-02-28 | 1999-06-15 | Motorola, Inc. | Method for transferring a communication link in a wireless communication system |
| US6519457B1 (en) * | 1997-04-09 | 2003-02-11 | Nortel Networks Limited | Methods and systems for standardizing interbase station communications |
| US6052594A (en) * | 1997-04-30 | 2000-04-18 | At&T Corp. | System and method for dynamically assigning channels for wireless packet communications |
| KR100277101B1 (ko) * | 1998-02-17 | 2001-01-15 | 윤종용 | 코드분할다중접속네트워크내의교환국간하드핸드오프수행방법 |
| FR2778303B1 (fr) | 1998-05-04 | 2000-06-02 | Alsthom Cge Alcatel | Procede de transfert d'une communication entre deux relais d'une cellule d'un systeme de radio-communication numerique cellulaire |
| US6246872B1 (en) * | 1998-05-06 | 2001-06-12 | Nortel Networks Limited | Mobile switching centre and method for handling a dropped connection between a mobile station and a basestation transceiver |
| US6104927A (en) * | 1998-05-28 | 2000-08-15 | Motorola, Inc. | Communication system, mobile station, and method for mobile station registration |
| KR20000014143A (ko) * | 1998-08-14 | 2000-03-06 | 서평원 | 통신시스템에서파일럿수신감도측정메시지의개선된전송방법 |
| US6360100B1 (en) | 1998-09-22 | 2002-03-19 | Qualcomm Incorporated | Method for robust handoff in wireless communication system |
| US6321090B1 (en) * | 1998-11-06 | 2001-11-20 | Samir S. Soliman | Mobile communication system with position detection to facilitate hard handoff |
| JP3150115B2 (ja) * | 1998-11-12 | 2001-03-26 | 埼玉日本電気株式会社 | Ｃｄｍａ開ループ制御における上りチャネル干渉補正方法及びそのシステム |
| US6567666B2 (en) * | 1998-12-02 | 2003-05-20 | Infineon Technologies North America Corp. | Forward link inter-generation soft handoff between 2G and 3G CDMA systems |
| KR100277131B1 (ko) * | 1998-12-03 | 2001-01-15 | 윤종용 | 이동통신시스템에서의호장애시호자동재접속방법 |
| CA2294698A1 (en) | 1999-01-29 | 2000-07-29 | Lucent Technologies Inc. | Open loop power control for wireless mobile stations |
| US6496496B1 (en) * | 1999-04-22 | 2002-12-17 | Nortel Networks Limited | Crucial control message transmission method and systems |
| EP1056258A1 (en) * | 1999-05-27 | 2000-11-29 | TELEFONAKTIEBOLAGET L M ERICSSON (publ) | Data unit sending means and control method in wireless networks |
| US6434367B1 (en) * | 1999-06-11 | 2002-08-13 | Lucent Technologies Inc. | Using decoupled power control sub-channel to control reverse-link channel power |
| US6253083B1 (en) * | 1999-07-21 | 2001-06-26 | Lucent Technologies Inc. | Mobile switching center for providing wireless access Ho |
| US6445918B1 (en) * | 1999-11-01 | 2002-09-03 | Telefonaktiebolaget L M Ericsson (Publ) | Method and system for saving dropped calls |
| US6430414B1 (en) * | 1999-12-29 | 2002-08-06 | Qualcomm Incorporated | Soft handoff algorithm and wireless communication system for third generation CDMA systems |
| US6438117B1 (en) * | 2000-01-07 | 2002-08-20 | Qualcomm Incorporated | Base station synchronization for handover in a hybrid GSM/CDMA network |
| US6603797B1 (en) * | 2000-03-22 | 2003-08-05 | Interdigital Technology Corporation | Outer loop/weighted open loop power control in a time division duplex communication system |
| US6542744B1 (en) * | 2000-06-20 | 2003-04-01 | Motorola, Inc. | Handoff in a cellular network |
| US6337983B1 (en) | 2000-06-21 | 2002-01-08 | Motorola, Inc. | Method for autonomous handoff in a wireless communication system |
| US6512927B2 (en) * | 2000-11-14 | 2003-01-28 | Denso Corporation | Method and apparatus for simultaneous rescue of multiple connections in telecommunication systems |
| US6829468B2 (en) | 2001-03-05 | 2004-12-07 | Lucent Technologies Inc. | Reverse-link power control overshoot considering mobile station transmission limitations |
| US7082303B2 (en) * | 2001-06-12 | 2006-07-25 | Motorola, Inc. | Method for supporting rescue channels in a communications system |
| US20040166865A1 (en) * | 2002-12-06 | 2004-08-26 | Soong Anthony C.K. | Call recovery using multiple access call recovery channel |
-
2001
- 2001-10-16 AU AU2002215376A patent/AU2002215376A1/en not_active Abandoned
- 2001-10-16 JP JP2002536850A patent/JP3948403B2/ja not_active Expired - Fee Related
- 2001-10-16 CN CN01817519.8A patent/CN1265655C/zh not_active Expired - Lifetime
- 2001-10-16 US US09/978,974 patent/US7133675B2/en not_active Expired - Lifetime
- 2001-10-16 WO PCT/US2001/032464 patent/WO2002033982A2/en active IP Right Grant
- 2001-10-16 KR KR1020037005354A patent/KR100593866B1/ko not_active IP Right Cessation
-
2006
- 2006-09-21 US US11/525,341 patent/US20070015512A1/en not_active Abandoned
Also Published As
| Publication number | Publication date |
|---|---|
| KR20030057539A (ko) | 2003-07-04 |
| US20020045443A1 (en) | 2002-04-18 |
| US7133675B2 (en) | 2006-11-07 |
| WO2002033982A2 (en) | 2002-04-25 |
| US20070015512A1 (en) | 2007-01-18 |
| AU2002215376A1 (en) | 2002-04-29 |
| KR100593866B1 (ko) | 2006-06-30 |
| WO2002033982A3 (en) | 2003-05-15 |
| CN1470136A (zh) | 2004-01-21 |
| CN1265655C (zh) | 2006-07-19 |
| JP2004524720A (ja) | 2004-08-12 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3948403B2 (ja) | 遠距離通信システムのための順方向リンクベース救済チャンネル方法および装置 | |
| JP4544269B2 (ja) | 通信障害に起因する打ち切りから接続を救済する方法 | |
| US7006821B2 (en) | Method and apparatus for dynamically determining a mobile station's active set during a connection rescue procedure | |
| US6996391B2 (en) | Forward-link rescue synchronization method and apparatus | |
| JP4713601B2 (ja) | 無線通信システムにおける呼復旧のための方法および装置 | |
| US6512927B2 (en) | Method and apparatus for simultaneous rescue of multiple connections in telecommunication systems | |
| JP4108759B2 (ja) | 移動局との通信が途絶えることを回避するための方法と装置 | |
| US6928285B2 (en) | Minimum interference multiple-access method and system for connection rescue | |
| US7082303B2 (en) | Method for supporting rescue channels in a communications system | |
| US6968186B2 (en) | System and method for preventing dropped calls | |
| AU2002217922A1 (en) | Method and apparatus for call recovery in a wireless communication system | |
| JP4089432B2 (ja) | 遠距離通信システムにおける複数の接続の同時救済のための方法 | |
| WO2002045386A2 (en) | Retry limits for connection rescue procedures in telecommunication systems | |
| WO2002041605A2 (en) | System for rescuing multiple mobile station connections | |
| UA73813C2 (en) | Method (variants) and device for transmitter reinitialization in a wireless communication system |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20041007 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20070327 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20070409 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100427 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110427 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120427 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120427 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130427 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130427 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140427 Year of fee payment: 7 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| LAPS | Cancellation because of no payment of annual fees |