(57)【要約】【課題】　高感度衛星測位システムレシーバのための合成航法データ【解決手段】　ＳＰＳレシーバは、軌道を回る衛星までの擬似距離を測定するための無線受信機と、真のＳＰＳシステム時刻の３秒以内の精度を有するローカルのリアルタイムクロックと、航法データ同報通信の再送信をサーバから受信するための通信チャネルとを有する。そうしたサーバは、ＳＰＳシステムの信頼性のある航法データの復調ができる程度に強い衛星信号を直接受信できる独自の専用航法受信機と関連付けられている。ＳＰＳレシーバは、ローカルのリアルタイムクロックから供給された時間情報と、サーバが同報通信の再送信の中で供給した衛星暦及び軌道暦データとから、独自の航法データを合成する。そのために、このＳＰＳレシーバは、普通では不可能な、信号の弱い環境で動作することができる。【選択図】　　図１
2004109133.tif 000002
【特許請求の範囲】
【請求項１】
　衛星測位システム（ＳＰＳ（satellite positioning system））レシーバであって、
　軌道を回るＳＰＳ衛星から直接受信すると共にそれらの衛星の擬似距離を測定するための航法衛星信号受信機と、
　真のＳＰＳシステム時刻に対して３秒以内の精度をもつリアルタイムクロック（ＲＴＣ（real time clock））と、
　遠隔サーバが得たＳＰＳシステム航法（ＮＡＶ（navigation））データの同報通信の再通信を受信するための通信レシーバと、
　長さにして１２．５秒の完全な合成航法データメッセージを構築するために、リアルタイムクロック及び通信レシーバに接続され、且つ普通では航法衛星信号受信機で直接受信することのできない、そして時間情報をリアルタイムクロックから変換すると共に衛星暦及び軌道暦データを前記ＳＰＳシステムの同報通信の再通信から変換する航法データの再構築を可能にするための航法データ合成器とを有し、
　前記擬似距離及び前記合成航法データメッセージから位置解を導出することができることを特徴とするＳＰＳレシーバ。
【請求項２】
　前記通信レシーバは携帯電話を含み、前記遠隔サーバと無線接続することを特徴とする請求項１に記載のＳＰＳレシーバ。
【請求項３】
　前記通信レシーバはネットワーククライアントを含み、インターネット経由で前記遠隔サーバにログオンすることを特徴とする請求項１に記載のＳＰＳレシーバ。
【請求項４】
　軌道を回る衛星測位システムの衛星から航法データを直接受信するには弱すぎる信号環境でＳＰＳレシーバを動作させる方法であって、
　ローカルの独立時刻基準を維持するステップと、
　衛星測位システムの衛星群までまっすぐに至る擬似距離を測定するステップと、
　基準局から二次通信チャネルで軌道暦及び衛星暦支援情報を受信するステップと、
　前記ローカル独立時刻基準と前記軌道暦及び衛星暦支援情報との組合せから航法データメッセージを再構築するステップと、
　前記航法データメッセージ及び前記擬似距離から位置解を計算するステップとを有することを特徴とする方法。
【請求項５】
　前記維持するステップは、前記ローカル独立時刻基準が真の衛星測位システム時刻に対して３秒以内の精度を実現するようになっていることを特徴とする請求項４に記載の方法。
【請求項６】
　前記測定するステップは、減衰したＳＰＳ衛星送信を読み取るのに相関利得を使用することを特徴とする請求項４に記載の方法。
【請求項７】
　前記軌道暦及び衛星暦支援情報を受信するステップは、前記二次通信チャネルがクライアント及びサーバを有するコンピュータネットワークであることを特徴とする請求項４に記載の方法。
【請求項８】
　前記軌道暦及び衛星暦支援情報を受信するステップは、前記二次通信チャネルがワイヤレス携帯電話システムであることを特徴とする請求項４に記載の方法。
【請求項９】
　前記軌道暦及び衛星暦支援情報を受信するステップは、前記基準局からＺカウントが送られないようになっていることを特徴とする請求項４に記載の方法。
【請求項１０】
　前記軌道暦及び衛星暦支援情報を受信するステップは、前記基準局からタイミング情報が送られないようになっていることを特徴とする請求項４に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
　本発明は、航法衛星受信機に関し、より具体的には、システム時刻情報によって航法受信機の初期化を支援するための方法並びにシステムに関する発明である。
【背景技術】
【０００２】
　全地球測位システム（ＧＰＳ（global positioning system））及び衛星測位システム（ＳＰＳ（satellite positioning system））の受信機は、ユーザの位置や速度及びその他の航法データを判定するために、地球の軌道を回る衛星群の中の幾つかの衛星から受信した信号を用いる。電源を入れたばかりの航法受信機は、その現在位置や水晶発振器にどのくらいの誤差があるかや、現在時刻も分からない。しかしながら、時刻は３秒以内の範囲で、おおよその位置は１００ｋｍ以内の範囲では分かる。衛星かの送信を見い出し捕捉するには正確な時刻と正確な衛星の搬送波周波数が必要なため、あらゆる可能性について探索を行なわなければならない。したがって、探索の必要な範囲を狭めるということは、直接的に、初期化ならびに初期測位の所要時間を短縮することにつながる。初期測位とは、電源投入後最初に行う測位のことである。
【０００３】
　携帯電話と関連付けられたＧＰＳレシーバ、あるいはインターネットで通信可能なＧＰＳレシーバを、すでに衛星を捕捉して追跡している別のＧＰＳレシーバが接続されたネットワークサーバを用いて、いろいろな方法で支援することができる。航法受信機がより素早く初期化できるように、電話やネットワーク通信チャネルを用いて、航法受信機に情報のキービットを提供することができる。本願の発明者の一人Paul McBurney他は、最近、ＧＰＳレシーバクライアント支援に関する幾つかの米国特許出願手続を行なった。それをまとめたのが表１である。これらの特許出願は全て、同じ譲渡人に譲渡されている。これらの特許出願はここに参照することにより本明細書の一部をなすものとする。
【０００４】
【表１】
2004109133.tif 000003
【０００５】
　ＧＰＳ衛星は、１２．５分毎に繰り返す、ビット率５０ｂｐｓの航法（ＮＡＶ（navigation））データメッセージを送信する。このデータメッセージは、十分な数の衛星を信号捕捉し、航法解を得る際にＧＰＳレシーバに不可欠となるシステム時刻、軌道暦情報及び衛星暦情報から構成されている。２５のフレームからなり、各フレームを送るのに３０秒かかる。各フレームは５つのサブフレームからなり、各サブフレームは１０ワードを有する。各サブフレームの始まりのＺカウントは衛星からの送信時間を示す。軌道暦は初めの３つのサブフレームで、サブフレーム４〜５は５０ページに及ぶ衛星暦データである。航法データの一つのデータフレームは長さ１５００ビットで、送信するのに３０秒かかる。
【０００６】
　信号レベルが弱すぎると、航法データの受信や復調の信頼性が低くなる。そのような状況は、屋内や船倉で起きる可能性がある。そこで、現在の航法データを提供する別のチャネルを使った第３者から情報支援を受けるための高感度受信機が必要となる。ローカルレシーバのシステム時刻が分かっていれば、この第三者から得た、他の点では汎用の航法データメッセージにＺカウント情報をプラグインすることができる。
【０００７】
　各データフレームは５つのサブフレーム１〜５に分割され、サブフレームは各々長さ３００ビット、例えば、３０ビットのワード１０個の長さである。３００ビット、１０ワードの各サブフレームを送信するには６秒かかる。サブフレームは必ず３０ビットのテレメトリー（ＴＬＭ（telemetry））ワードから始まり、その次が３０ビットのハンドオーバーワード（ＨＯＷ（hand-over word））となる。両３０ビットワードは共に２４ビットのデータと６ビットのパリティとからなる。サブフレーム毎に８ワードのデータペイロードがある。
【０００８】
　３００ビットのサブフレーム各々の頭にあるＴＬＭワードは８ビットのプリアンブルで始まる。プリアンブルによってサブフレームの始まりが認識され、その後受信機が同期をとるための主要なメカニズムとなる。
【０００９】
　最初の３００ビットフレームで、ＴＬＭワード及びＨＯＷの後に、ＧＰＳ衛星（ＳＶ（satellite vehicle））のクロック修正データが送信される。２番目のサブフレームはＧＰＳ軌道暦の第１部を送信する。３番目のサブフレームはＧＰＳ軌道暦の第２部を送信する。４番目と５番目のサブフレームはシステムデータの別々のページを送るのに使用される。４番目のサブフレームもＴＬＭワード及びＨＯＷで始まり、データペイロードは、電離層、ＵＴＣ（Coordinate Universal Time、協定世界時、協定世界時とは国際原子時と自転をもとにした世界時とのずれを秒で調整した時刻である）、その他のデータについて非常に長い情報を送信するために、１２．５分で一回りする。２５フレーム（１２５のサブフレーム）からなるフレーム集合全体で、１２．５分間で送られる完全航法メッセージ（Navigation Message）が成り立っている。５番目のサブフレームはＴＬＭワード及びＨＯＷで始まり、そのデータペイロードも、どちらかというと大型の衛星暦を送信するために、１２．５分かかって回転する。
【００１０】
　クロックデータパラメータは、ＧＰＳ衛星クロック及びそのＧＰＳ時刻に対する関係を表わしたものである。軌道暦データパラメータは、衛星軌道の短い区分のＧＰＳ衛星軌道を表わしている。普通、受信機は１時間毎に新たな軌道暦データを集めるが、４時間までであれば大きな誤差はなく、古いデータを使用することができる。軌道暦パラメータは、軌道暦パラメータ集合によって表わされた軌道の周期以内で任意の時間のＧＰＳ衛星の位置を計算するアルゴリズムと共に使用される。衛星暦はＧＰＳ衛星全ての近似軌道データパラメータである。１０パラメータの衛星暦は長期にわたるＧＰＳ衛星軌道を説明しており、時には数ヶ月間も有効である。
【００１１】
　立ち上げ時のＧＰＳレシーバの信号捕捉時間は、現在の衛星暦情報を利用することで、かなりスピードアップを図ることができる。近似軌道データは、衛星群に入っている各ＧＰＳ衛星の近似位置及び搬送波ドップラー周波数で受信機をプリセットするために用いられる。
【００１２】
　Norman F. Krasnerは、２００１年５月２９日付けで登録された米国特許6,239,742B1「時間測定に基づく衛星測位システムのための方法及び機器」の中で、搬送波信号レベルが弱すぎて判読できない航法データメッセージに対処する方法を説明している。基地局は航法データメッセージの部分部分を記録し、これらは遠隔ＳＰＳレシーバからの同じようなデータと比較される。遠隔ＳＰＳレシーバは可視衛星から直接、航法データメッセージの部分部分を受信する。基地局が記録する航法データには、正確な時刻同定（time identification）が含まれているので、時間的にオーバーラップした２つの部分を合わせることで遠隔ＳＰＳレシーバが正しいシステム時刻を見つけ出すのを支援することができる。そうした比較は遠隔モバイルレシーバでは行なわれず、むしろ基地局に戻して行なわれる。
【００１３】
【特許文献１】米国再発行特許発明第6,239,742号明細書
【発明の開示】
【発明が解決しようとする課題】
【００１４】
　そこで、本発明の目的は、航法衛星受信機及びＧＰＳやＳＰＳレシーバの受信機の初期化を支援するための方法並びにシステムを提供することである。
【００１５】
　本発明のもう一つの目的は、ＧＰＳやＳＰＳレシーバが初期化するのに必要な時間を短縮するための方法並びにシステムを提供することである。
【００１６】
　本発明の更なる目的は、費用効率の高い航法衛星システムを提供することである。
【課題を解決するための手段】
【００１７】
　本発明の衛星測位システム（ＳＰＳ（satellite positioning system））レシーバは、
　軌道を回るＳＰＳ衛星から直接受信すると共にそれらの衛星の擬似距離を測定するための航法衛星信号受信機と、
　真のＳＰＳシステム時刻に対して３秒以内の精度をもつリアルタイムクロック（ＲＴＣ（real time clock））と、
　遠隔サーバが得たＳＰＳシステム航法（ＮＡＶ（navigation））データの同報通信の再通信を受信するための通信レシーバと、
　長さにして１２．５秒の完全な合成航法データメッセージを構築するために、リアルタイムクロック及び通信レシーバに接続され、且つ普通では航法衛星信号受信機で直接受信することのできない、そして時間情報をリアルタイムクロックから変換すると共に衛星暦及び軌道暦データを前記ＳＰＳシステムの同報通信の再通信から変換する航法データの再構築を可能にするための航法データ合成器とを有し、
　前記擬似距離及び前記合成航法データメッセージから位置解を導出することができることを特徴とする。
【００１８】
　さらに、前記通信レシーバは携帯電話を含み、前記遠隔サーバと無線接続することを特徴とする。
【００１９】
　さらに、前記通信レシーバはネットワーククライアントを含み、インターネット経由で前記遠隔サーバにログオンすることを特徴とする。
【００２０】
　また、本発明の、軌道を回る衛星測位システムの衛星から航法データを直接受信するには弱すぎる信号環境でＳＰＳレシーバを動作させる方法は、
　ローカルの独立時刻基準を維持するステップと、
　衛星測位システムの衛星群までまっすぐに至る擬似距離を測定するステップと、
　基準局から二次通信チャネルで軌道暦及び衛星暦支援情報を受信するステップと、
　前記ローカル独立時刻基準と前記軌道暦及び衛星暦支援情報との組合せから航法データメッセージを再構築するステップと、
　前記航法データメッセージ及び前記擬似距離から位置解を計算するステップとを有することを特徴とする。
【００２１】
　さらに、前記維持するステップは、前記ローカル独立時刻基準が真の衛星測位システム時刻に対して３秒以内の精度を実現するようになっていることを特徴とする。
【００２２】
　さらに、前記測定するステップは、減衰したＳＰＳ衛星送信を読み取るのに相関利得を使用することを特徴とする。
【００２３】
　さらに、前記軌道暦及び衛星暦支援情報を受信するステップは、前記二次通信チャネルがクライアント及びサーバを有するコンピュータネットワークであることを特徴とする。
【００２４】
　さらに、前記軌道暦及び衛星暦支援情報を受信するステップは、前記二次通信チャネルがワイヤレス携帯電話システムであることを特徴とする。
【００２５】
　さらに、前記軌道暦及び衛星暦支援情報を受信するステップは、前記基準局からＺカウントが送られないようになっていることを特徴とする。
【００２６】
　さらに、前記軌道暦及び衛星暦支援情報を受信するステップは、前記基準局からタイミング情報が送られないようになっていることを特徴とする。
【００２７】
　本発明の作用効果は、普通では初期化できない、信号の弱い環境で、ＧＰＳレシーバの初期化を可能にするシステム及び方法を提供していることである。
【００２８】
　本発明のもう一つの作用効果は、モバイル携帯電話と関連付けられる航法衛星受信機のコスト削減を実現するためのシステム及び方法を提供していることである。
【００２９】
　本発明のこれらの及びその他の目的並びに作用効果については、図面に示した好適な実施例に関して以下に述べる説明を読めば、当業者なら容易に分かることは疑いの余地がない。
【発明を実施するための最良の形態】
【００３０】
　大まかに言えば、本発明のＳＰＳレシーバの実施例は、軌道を回るＳＰＳ衛星までの擬似距離を測定するための無線受信機と、真のＳＰＳシステム時刻に対して３秒以内の精度を有するローカルリアルタイムクロックと、サーバから航法データの同報通信の再通信（rebroadcast）を受信するための通信チャネルとを備えている。このようなサーバは、ＳＰＳシステム航法データの信頼性のある復調ができる程度の強度を有する衛星信号を直接受信する独自の航法受信機と関連付けられている。ＳＰＳレシーバは、ローカルリアルタイムクロックが提供する時刻情報及びサーバが提供する衛星暦及び軌道暦データから独自の航法データを合成する。従って、ＳＰＳレシーバは、普通では不可能な、信号の弱い環境でも動作することができる。
【００３１】
　以下、本発明の実施形態を図面に基づいて説明する。
【実施例１】
【００３２】
　図１に、本発明の実施例におけるネットワークシステム１００を示す。ネットワーク１００は、基準局サーバシステム１０２、ユーザクライアントシステム１０４、インターネットなど介在型コンピュータネットワーク１０６を含む。サーバシステム１０２は、航法衛星１０８、１１０、１１２からなる、衛星群を捕捉して追跡している航法衛星受信機を含む。これらの衛星の中にはクライアントシステム１０４から見えるものがあるかもしれない。航法衛星１１４、１１６を含む別の衛星群はクライアントシステム１０４から見ることができる。クライアントシステム１０４は独自の航法衛星受信機を備えているが、航法衛星１１２、１１４、１１６からなる衛星群を未だ捕捉して追跡していないかもしれない。
【００３３】
　サーバシステム１０２は、常に、航法衛星１０８、１１０、１１２からなる衛星群を捕捉して追跡しているはずである。ゆえに、正確な絶対時刻システムを判別することが可能で、現在の軌道暦、対流圏、電離層、その他の情報を、ネットワーククライアントとして接続されている未だ初期化されていない他の航法衛星受信機に提供することもできる。そうした情報は全て初期化時に判定されなければならないので、そのうちのどれでも他のソースから提供（spoon feeding）することができれば、電源投入から航法開始に要する時間（TTFF：time-to-first-fix）を大幅に短縮させることができる。
【００３４】
　サーバシステム１０２は、１２．５分の繰り返し航法データメッセージを保持している。したがって、要求があればその必要な部分をクライアントシステム１０４に転送することができる。そうすると、クライアントサーバ１０４は、保持され転送された航法データと受け取った航法データとのパターンマッチングをすることができる。それによりクライアントシステム１０４は、最初のＴＬＭワードの頭のプリアンブルを受け取る前に、航法データフレームに対して同期をとることができる。
【００３５】
　クライアントシステム１０４は、普通、電源投入されるとゼロからスタートする独自の２４ビットミリ秒クロック（Msec24）を有する。ＧＰＳのＣ／Ａコードの各エポックは１ミリ秒である。サーバシステム１０２はＧＰＳ時刻を知り、Ｚカウントを有する。Ｚカウントは、基本的なＧＰＳ時刻単位を表わす２９ビットの２進数である。上位１０ビットがＧＰＳ週数（GPS week number）を伝え、下位１９ビットが１．５秒単位で週の時刻（ＴＯＷ（time of week））カウントを伝える。受信機が幾つかのＧＰＳ衛星を捕捉してしまえば、システム時刻のはるかに微細な尺度が使用可能になる。先行技術の装置では初期化時のＺカウントの判定に依存してきた。
【００３６】
　クライアントシステム１０４の初期化時に具体的に判定されなければならないのは、ＧＰＳ時刻に合わせるために、クライアントのローカルクロック、例えばMsec24に、どれだけのオフセットを加算しなければならないということである。これによって正しい航法データフレーム同期が決まる。受信したばかりのサブフレームを、サーバシステム１０２が観測しているサブフレームのシーケンシャルな記録を探索するためのテンプレートとして使用すれば、クライアントシステムでそうした同期を達成するのに要する時間が大幅に減る。
【００３７】
　もしくは、ネットワークでのバイトあたりの通信コストが比較的高価な場合は、クライアントシステム１０４が集めた信号のスナップショットをサーバシステム１０２に転送するほうが経済的である。そうすると、パターンマッチを見付け出すのはサーバシステムの仕事となる。その場合、サーバシステムは次に、クライアントが使用する現在の整数ミリ秒を識別するのに役立つデータを送る。
【００３８】
　そのようなケースでは、サーバシステム１０２は基準局が追跡するＧＰＳ衛星毎の航法データサブフレームを保存するのが好ましい。サーバシステムは次に、自らと複数のネットワーククライアント１０４との間に存在するネットワークレイテンシを推定する。これによりクライアント毎のＧＰＳ時刻の推定が可能になる。そうしたＧＰＳ時刻から、航法データサブフレームのどの部分をクライアントで観測すべきか知ることができる。サーバシステムはこれらの航法データサブフレームをコピーし、Ｚカウントを書き換え、さらに、クライアントに送る前にＨＯＷワードにパリティビットを付加する。
【００３９】
　本発明の方法の実施例で、クライアントシステム１０４はサーバシステム１０２から近似のＧＰＳ時刻、例えば、真のＧＰＳ時刻の１、２秒以内の時刻を得る。サーバシステム１０２とクライアントシステムとの間のネットワーク１０６にはいくらかのネットワークパス遅延があることを考慮に入れておかなければならない。
【００４０】
　クライアントシステム１０４は、対象のＧＰＳ時刻、例えば、ある特定のミリ秒区間を指定して、サーバシステム１０２に航法データサブフレームを要求する。サーバシステム１０２はそのデータベースから対応するサブフレームパターン集合をフェッチする。予測されたＺカウントでＨＯＷワードを書き換え、しかるべきパリティビットを付加する。要求されたサブフレームがネットワーク１０６で送られる。
【００４１】
　クライアントシステム１０４は、サーバシステム１０２が供給したサブフレームデータを検査するために３０ビット長の移動時間帯（moving window）を用い、ＧＰＳ衛星から直接受信したばかりのものとの一致を見出そうとする。もし一致するものがなければ、時間帯を１ビットシフトさせ、３０ビットワードが何度も何度も比較される。３０ビットのマッチが見つかれば、その前後のワードについても妥当性がテストされる。一致が見つかるということはフレーム同期が見つかったということを示す。次に、クライアントシステム１０４をＧＰＳ時刻で初期化するために、オフセット時間が計算され、Msec24に付加される。もっと具体的に言えば、航法サブフレームデータの中の現在のＨＯＷワードからＺカウントが抽出される。
【００４２】
　一般的な話として、本発明の実施例はパターンマッチングの技法に基づいている。パターンによっては問題があるので、「ＦＦＦＦＦＦ」、「００００００」、「ＡＡＡＡＡＡ」、「５５５５５５」のような信頼性のないビットパターンを拒絶する必要がある。そうしたパターンは普通、打ち上げられていないＧＰＳ衛星や定義されていない衛星暦のページに出てくる。もう一つのパターンマッチングの問題はビット逆転によって起こる。
【００４３】
　典型的なファームウェアは、時に、信号が弱すぎると、航法データの位相の逆転を検出し損なうことがある。受信機が変化を検出できなかった場合には、変化の後の全てのビットを反転させる必要がある。そのために、何らかのビット位相逆転を予期しておくべきである。観測によれば、３０もの位相逆転が発生し得る。ＴＬＭワードはサブフレームの頭の印となり、３０ビットワード１０語置きに出てくる。ＨＯＷワードがその後に続き、Ｚカウントの上位１７ビットを伝える。１０番目のワードの終わりの前の２ビットはつねに「００」である。これらの領域で航法パターンは非常に類似しているので、探索の時間帯が１０ワードを超えるとＴＬＭパターンとマッチさせることができない。
【００４４】
2004109133.tif 000004
【００４５】
　ネットワーク及びシステムの応答による遅延を考慮に入れて、クライアント１０４に送るのにふさわしいワード長が決められる。次の式を考える。
【００４６】
【数１】
2004109133.tif 000005
【００４７】
　航法データストリームは５０ワード毎の繰り返し、つまり、５つのサブフレーム１〜５の繰り返しである。サーバ１０２が１０ワード以上送る場合、サブフレームの始まりに必ずＴＬＭワードのパターンが繰り返されているから、ＴＬＭワードをマッチングに用いることができない。
【００４８】
　一つの実施例では、フレームを同期させてしまえば、次のＨＯＷワードの終わり及び航法パケットの始まりからビットを数えてＧＰＳ時刻を確定することができる。ＨＯＷワードの終わりから次のサブフレームの始まりまでのオフセットは２４０ビット、例えば、４８００ミリ秒である。そうしたオフセットを次のサブフレームから差し引くと現在のＧＰＳ時刻を得ることができる。例えば、
【００４９】
【数２】
2004109133.tif 000006
【００５０】
　ＧＰＳ衛星と地球の表面との間の正確な送信伝播時間を知るのは難しい。そこで、７０ミリ秒というデフォルト値を手始めに用いると＋／−１０ミリ秒のアンビギュイティとなるので、このデフォルト値は理にかなっていると思われる。
【００５１】
　整数ミリ秒（「intMsec」）は、ユーザの位置とＧＰＳ衛星の位置との間の擬似距離を表わす。第１のＺカウント事象に関するＧＰＳ時刻を計算するにあたり、intMsecを７０ミリ秒と仮定する。msec24の変数とＧＰＳ時刻との間のオフセット時間（「offGpsMsec」）が次に算出される。第１Ｚカウント事象以降、その事象はＧＰＳ時刻調整には適用されず、ただintMsecの計算だけに用いられる。offGpsMsecに基づいて、各ＧＰＳ衛星の整数ミリ秒（intMsec）が次の方程式を用いて解明される。ＧＰＳ時刻及びoffGpsMsecは位置測位ルーチン（position-fix routine）の中の時間バイアスを解明して調整される。例えば、
【００５２】
【数３】
2004109133.tif 000007
【００５３】
　本発明の好適なプリアンブルなしの同期法では、万が一パターンマッチングできなかった場合に備えて、フォールバックＴＬＭプリアンブル同期検出プロセスが含まれている。両スキームとも同期化された位置、例えば、ワードＩＤ、サブフレームＩＤ、ページＩＤ、現在のＺカウントを単に設定するだけである。そのために、２つのスキームが独立して共存することができる。クライアント１０４がサーバ１０２からのサポートを利用できる時は、先ず最初にパターンマッチングの技法を試みる。その次に、同期をとるためにＴＬＭワードプリアンブルの使用を試みる。どちらかのスキームがうまくいったら、受信機はスムーズにデコーディングをシフトさせる。従って、たとえプリアンブルなし同期パターンマッチングに使用可能なふさわしいビットパターンがなくても、一般的には、フレームのエッジを電源投入から６秒以内に同期させることができる。
【００５４】
　基準局サーバ１０２は、ＧＰＳ衛星毎のサブフレームデータを保持して、このようなプリアンブルなし同期パターンマッチングをサポートする。ネットワークレイテンシを推定し、クライアント１０４におけるＧＰＳ時刻を推測する。サーバ１０２は、クライアントＧＰＳ時刻を中心にした対応するサブフレームデータを検索する。ＨＯＷワードの中のＺカウントを書き換え、クライアント１０４に送るパケットに入っているサブフレームデータを符号化する。
【００５５】
　基準局で受信されたこのようなサブフレームデータは各々データベースに保持される。保持されるサブフレームデータは、例えば、下記のような、５，７８０バイトの軌道暦データ及び３０００バイトの衛星暦データを含む。
軌道暦＝３（サブフレーム）×１０（ワード）×２４ビット（パリティなし）×３２（ＧＰＳ衛星）×２（事前／現在のＩＯＤＥ）
アルマナック＝２５（ページ）×２（SF）×１０（ワード）×２４ビット（パリティ付き）×２（事前／現在）
　ＧＰＳ衛星からの航法ストリームは繰り返されるので、全ての航法ビットを保持する必要はない。サブフレームデータの中にはサーバが無視できるものがある。ワードパリティビットについては全て無視することができる。システムの軌道暦が変わると、基準局サーバ１０２及びクライアント１０４が共に新たな軌道暦サブフレームを実際に受信するまで、プリアンブルなしのパターンマッチングはうまくいかない。システムの衛星暦が変わる場合も同じことが言える。時には、全ＧＰＳ衛星からの衛星暦データを新たな衛星暦セットに完全に更新するのに１２時間以上かかることがある。そのために、前の衛星暦セットも現在の衛星暦セットもデータベースに保持されなければならない。
【００５６】
　クライアント１０４は、サーバ１０２から現在のＧＰＳ時刻と一致したサブフレームデータを取得して初期化する。これを行なうために、サーバ１０２はＧＰＳ時刻を近似し、ネットワーク１０６で送られた情報パケットはクライアント１０４で実際に受信される。時刻がどれだけ近似しているかは、サーバがクライアントでのＧＰＳ時刻をどれだけ精度よく推定できるかということと、クライアントに送られるワードデータの大きさとにかかっている。もしサーバがクライアントのＧＰＳ時刻を＋／−３秒以内の範囲で推定できれば、１０データワード、つまり１サブフレーム以内で航法フレームを同期させることが可能である。
【００５７】
　クライアント１０４におけるＧＰＳ時刻を推定した後、サーバ１０２はデータベース内を検索し、その現在のＧＰＳ時刻に対応するしかるべきサブフレームデータを取得する。２セットの軌道暦及び衛星暦があるから、サーバ１０２はＧＰＳ衛星がどのデータセットを使用するべきかを追跡していなければならない。情報のワードを符号化する際、ワード１からのサブフレームデータとＴＬＭワードが必要である。パリティビットは前のワードデータの最終２ビットに依存し、ＨＯＷ及びワード１０両方の最終ビットは「００」である。
【００５８】
　ＨＯＷワードを書き換えることが重要である。サーバは現在のＧＰＳ時刻を知っているから、ＨＯＷワードの中のＺカウントを修正し、関連付けられるパリティビットをフィックスすることができる。サーバ１０２は、開始ワード識別値（ＩＤ）とデータの３０ビットワード１０語を送るのが好ましい。
【００５９】
　図２に本発明のＳＰＳレシーバ及びサポートシステムの実施例を示す。ここでは大まかに参照番号２００で示している。システム２００は、ＳＰＳ衛星からなる頭上の衛星群２０２からマイクロ波信号送信を受信する。信号２０４は伝送中の減衰２０６により、例えば、室内にいる場合、建物によって信号強度が低下する。もっとも、高感度ＳＰＳレシーバ２０８は、高減衰の場合でも、そうした信号に対応することができる。減衰の結果生じることの一つは、５０Ｈｚの航法データメッセージが判別不能になるかあるいはその信頼性がなくなることである。そのために、本発明の全ての実施例では別の手段によって、例えば、基準局２１２から、それを取得しなければならない。
【００６０】
　しかしながら、擬似距離をＳＰＳレシーバによって直接測定することができる。これは、相関処理利得を利用することで長期のサンプル期間を収集及び処理することができるからである。無線受信機２１４がそうした送信にチューニングし、相関プロセッサ２１６が可視衛星までの様々な擬似距離を抽出する。航法プロセッサ２１８は、リアルタイムクロック（ＲＴＣ）２２０から時間情報を、航法データ合成器２２２からＺカウント、軌道暦、及び衛星暦航法データ情報を得る。２００２年２月１９日出願の米国特許出願番号10/079,253に、そうしたＲＴＣの構造及び使用について詳細な説明がある。
【００６１】
　航法データ合成器２２２は本発明の実施例特有のものである。減衰２０６がそれほどまでにひどくなかったならば無線受信機２１４で受信したであろう２５フレームの航法データメッセージを再構築する。遠隔基準局２１２はクライアント２２４に時間情報を提供しない。提供するのは現在の軌道暦及び衛星暦データだけである。遠隔基準局２１２との通信チャネルは概して５０Ｈｚよりはるかに高いバンド幅だから、現在の軌道暦及び衛星暦データを衛星２０２が送信するのに要する通常の１２．５秒よりもはるかに短い時間でデータを転送することができる。
【００６２】
　クライアント２２４が受信するのは、軌道暦及び衛星暦の航法データ情報だけである。Ｚカウント及びタイミング情報は、ＲＴＣ２２０から時刻を読み出して、航法データ合成器２２２によって計算される。航法データ合成器２２２は組合わされた情報を、航法プロセッサ２１８が受理して普通に対応できるメッセージにフォーマットする。
【００６３】
　ここでは、ＲＴＣ２２０が３秒以内の精度であることが重要である。そうでないと、整数アンビギュイティのために、合成された航法データにＺカウントを正しく書き込むことができなくなる。これによって、航法プロセッサ２１８からの位置解出力２２６が可能となる。このことは、本願の発明者が開発した他の発明及び技術と組み合わせた場合、特に言えることである。それらの発明及び技術は参照することによって本明細書に既に組み込まれている。
【００６４】
　遠隔基準局２１２は独自の完全な航法受信機２２８を装備し、それが航法衛星群２０２を日常的且つ継続的に追跡している。航法データメッセージ２３０全体が１２．５メッセージ送信時間をかけて抽出され、その後ローカルメモリに保持される。タイムストリッパ２３２がタイミング情報、例えば、Ｚカウントを取り除く。軌道暦及び衛星暦の航法データ２３４が抽出され、ネットワークサーバ２３６が軌道暦及び衛星暦の航法データ２３４を使用できるようになる。ネットワーク接続２３８によってクライアント２２４が支援を要求できるようになる。それに応答してサーバ２３６は現在の軌道暦及び衛星暦の航法データを送る。
【００６５】
　もしくは、クライアント２２４、ネットワーク２３８、サーバ２３６の代わりに、どのような通信チャネルを用いてもよい。例えば、携帯電話や通信衛星を用いてワイヤレス通信で良い結果を得ることもできる。
【００６６】
　本発明のビジネスモデルの実施例では、ＳＰＳレシーバ２０８の所有者／ユーザは、そうした航法データ支援情報に対して遠隔基準局２１２のオペレータから使用単位で料金を請求されるかあるいは加入料金を請求される。
【００６７】
　上記のように、本発明の実施例は全て、室内や信号レベルが−１４５dbm以下に低下する場所での使用に特に適している。
【００６８】
　本発明を現時点で好適な実施例によって説明してきたが、開示は限定と解釈されるべきでないことが分かるはずである。上記の開示を読めば、当業者ならば、様々な変更並びに修正が明白になることは疑いの余地がない。従って、添付した特許請求の範囲は、発明の「真の」精神及び範囲から逸脱しない限りにおいて、あらゆる変更並びに修正を網羅するものと解釈されるものと考える。
【図面の簡単な説明】
【００６９】
【図１】セルサイトが無線通信チャネルで通信されたドップラー情報でモバイル携帯電話を支援する、本発明のクライアント支援型ドップラー推定システム実施例の機能ブロック図。
【図２】本発明のＳＰＳレシーバ及びシステムの方法実施例の機能ブロック図。
【符号の説明】
【００７０】
１００　　ネットワーク
１０２　　基準局サーバシステム
１０４　　ユーザクライアントシステム
１０６　　コンピュータネットワーク
１０８、１１０，１１２、１１４、１１６　　航法衛星
２０２　　衛星
２０４　　信号
２０８　　ＳＰＳレシーバ
２１２　　遠隔基地局
２１４　　無線受信機
２１６　　相関プロセッサ
２１８　　航法プロセッサ
２２０　　リアルタイムクロック
２２２　　航法データ合成器
２２４　　クライアント
【図１】
2004109133.tif 000008
【図２】
2004109133.tif 000009