クライアントシステム、ネットワークシステム及び測位方法
【課題】 ノンプリアンブルフレーム同期
【解決手段】 ナビゲーション衛星受信機は、ネットワークでアクセス可能な基準局を利用してパターンマッチング用のナビゲーションデータサブフレームをネットワーククライアントで保持する。もしくは、バイトあたりの通信コストが高価な場合にはサーバがパターンマッチングを実行する。保持されたナビゲーションデータには３０秒置きに軌道暦情報が、そして１２．５分置きに完全な衛星暦情報が繰り返されている。これにより、クライアントは受信したデータがナビゲーションデータシーケンスの中のどこにあるか即時に認識することができるので、ＴＬＭワードのプリアンブルを待たなくていい。従って、初期定点化時間を高速にする際、貴重な数秒の節約になる。
【解決手段】 ナビゲーション衛星受信機は、ネットワークでアクセス可能な基準局を利用してパターンマッチング用のナビゲーションデータサブフレームをネットワーククライアントで保持する。もしくは、バイトあたりの通信コストが高価な場合にはサーバがパターンマッチングを実行する。保持されたナビゲーションデータには３０秒置きに軌道暦情報が、そして１２．５分置きに完全な衛星暦情報が繰り返されている。これにより、クライアントは受信したデータがナビゲーションデータシーケンスの中のどこにあるか即時に認識することができるので、ＴＬＭワードのプリアンブルを待たなくていい。従って、初期定点化時間を高速にする際、貴重な数秒の節約になる。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はナビゲーション衛星受信機、より具体的には、ネットワークサーバを使用してナビゲーション衛星受信機の初期定点化時間（電源投入から最初の測位までの時間）（ＴＦＦＦ）を向上させる方法並びにシステムに関する発明である。
【背景技術】
【０００２】
全地球測位システム（ＧＰＳ）受信機は、地球の軌道を周回する衛生群の複数の衛星から受け取った信号を用いてユーザの位置や速度及びその他のナビゲーションデータを得る。電源投入直後のナビゲーション受信機は、その現在位置や現在時刻、あるいは水晶発振器の誤差について未だ分かっていない。衛星からの信号を捕らえてロックオンするにはこれらの情報が全て必要となるので、あらゆる可能性について探索がなされる。
【０００３】
各ＧＰＳ衛星（ＳＶ）はナビゲーション（ＮＡＶ）データをビット率５０bpsで送信する。ナビゲーションデータには、軌道暦情報、時間情報、衛星暦情報が含まれる。これらの情報により、ＧＰＳ受信機はその位置、速度、時間を算出することができる。ナビゲーションデータの１フレームは１５００ビット長で、その送信には３０秒かかる。
【０００４】
各フレームは５個のサブフレームに分割され、各サブフレームは３００ビット長で、例えば、３０ビットのワード１０語からなる。従って、３００ビット、すなわち１０語からなるサブフレームを送信するのには６秒必要となる。サブフレームは全て、３０ビットのテレメトリ（ＴＬＭ）ワードで始まり、その後に３０ビットのハンドオーバワード（ＨＯＷ）が続く。ＴＬＭ及びＨＯＷは、共に２４ビットのデータと６ビットのパリティから構成される。そして、各サブフレームは８語分のデータを有する。
【０００５】
３００ビット長のサブフレームの先頭にあるＴＬＭワードは、８ビットのプリアンブルで始まる。このプリアンブルによってサブフレームの始まりを認識することが可能になり、その後、このプリアンブル部が、受信機の同期をとるための主要な機構となる。
【０００６】
最初の３００ビット長のサブフレームは、ＴＬＭワード及びＨＯＷの後に、ＧＰＳ衛星時計補正データを送信する。２番目のサブフレームは、ＧＰＳ衛星軌道暦情報の最初の部分を送信する。３番目のサブフレームはＧＰＳ衛星軌道暦情報の２番目の部分を送信する。サブフレームの４番目と５番目を用いてシステムデータのあるページが送られる。４番目のサブフレームもＴＬＭワード及びＨＯＷで始まり、１２．５分かけて電離層、ＵＴＣ、その他のデータに関する長い情報を送信する。つまり２５フレーム（１２５サブフレーム）で、１セットの完全なナビゲーション情報を構成し、その送信には１２．５分を要する。５番目のサブフレームもＴＬＭワード及びＨＯＷで始まり、そのデータも１２．５分かけてどちらかといえば大きな衛星暦情報を送信する。
【０００７】
時計情報パラメータはＧＰＳ衛星時計及びＧＰＳ衛星時計とＧＰＳ時刻の関係を記述し、軌道暦パラメータは衛星軌道の短い区分のＧＰＳ衛星軌道を記述するものである。通常、受信機は一時間毎に新たな軌道暦情報を収集するが、４時間以内なら古いデータを使用しても大きな誤差にはならない。軌道暦パラメータは、軌道暦パラメータ集合で記述された軌道周期内でれば、任意の時間の間ＧＰＳ衛星の位置を計算するアルゴリズムと共に用いられる。衛星暦は全ＧＰＳ衛星の近似軌道データパラメータである。１０パラメータの衛星暦は長い期間にわたるＧＰＳ衛星軌道を記述し、時には数ヶ月間使用できる。
【０００８】
現在の衛星軌道を利用することによって、起動時にＧＰＳ受信機が信号を捕らえる時間をかなり短くすることができる。この近似軌道データが、衛星群の中のＧＰＳ衛星の概略の位置や搬送ドップラー周波数と共に、受信機をプリセットするのに用いられる。
【０００９】
【特許文献１】米国特許第５，７８１，１５６号
【発明の開示】
【発明が解決しようとする課題】
【００１０】
従って、従来の機器では、受信機のナビゲーションデータに対する同期は、ＴＬＭワードのプリアンブルパターン（８ビット）の検出に依存していた。ＴＬＭワードは６秒毎にしか送信されないので、検出までに３秒以上かかることもある。このような遅延は、ユーザにとって重要な判断基準となる初期定点化時間（電源投入から最初の測位までの時間）（ＴＴＦＦ）性能の低下へつながる。
【課題を解決するための手段】
【００１１】
ゆえに、本発明の目的は、ＴＬＭワードのプリアンブルを実際に受け取らずに処理することができる、ナビゲーション衛星受信及び受信機初期化のための方法並びにシステムを提供することにある。
【００１２】
本発明のもう一つの目的は、ナビゲーション機器の初期化に要する時間を短縮する方法並びにシステムを提供することである。
【００１３】
本発明の更なる目的は、安価な衛星ナビゲーションシステムを提供することである。
【００１４】
簡単に言えば、本発明のナビゲーション衛星受信機の実施例は、基準局にナビゲーションデータサブフレームを持たせ、クライアントでパターンマッチングを行なう。バイト単位の通信費用が高い場合は、サーバでパターンマッチングを行なってもよい。保持されたナビゲーションデータは、３０秒毎に軌道暦情報を、また１２.５分毎に全衛星暦情報を繰り返す。これにより、クライアントは、受信した信号が一連のナビゲーションデータのどこであるかのかを速やかに認識することができるので、ＴＬＭワードのプリアンブルを待たなくていい。これにより、高速な初期定点化時間を実現するのに重要な数秒間を節約することができる。
【００１５】
本発明の効果は、ナビゲーション衛星受信機で初期化時間をより高速にするシステム並びに方法を提供することである。
【００１６】
本発明の上記のそして他の目的及び効果については、以下に述べる、図面に示した好適な実施例の詳細な説明を読めば、当業者には明白になることは疑いの余地がない。
【発明を実施するための最良の形態】
【００１７】
図1に、本発明における実施例のネットワークシステム１００を示す。ネットワークシステム１００は、基準局サーバシステム１０２と、ユーザクライアントシステム１０４、及びインターネットなど介在型のコンピュータネットワーク１０６を備える。サーバシステム１０２はナビゲーション衛星受信機を備え、このナビゲーション衛星受信機がナビゲーション衛星１０８、１１０、１１２からなる衛星群をロックオンして追跡している。これらの衛星のいくつかは、クライアントシステム１０４からも捕らえることができるかもしれない。ナビゲーション衛星１１４、１１６を含む他のナビゲーション衛星群がクライアントシステム１０４から捕らえられる。クライアントシステム１０４は、ナビゲーション衛星受信機を自分で持っているが、その受信機はナビゲーション衛星１１２、１１４、１１６の衛星群をまだロックオンできてなく、追尾していないかもしれない。
【００１８】
サーバシステム１０２は常時電源が供給され、ナビゲーション衛星１０８、１１０、１１２からなる衛星群を追跡している。したがって、正確なシステムの絶対時間を知ることができると共に、現在の軌道暦、対流圏、電離層、その他の情報を、ネットワーククライアントとして接続されている、まだ初期化されていないナビゲーション衛星受信機に提供することもできる。これらの情報は全て初期化の際に確定されなければならないので、これらの情報が他のソースから提供できれば、その情報が何であれ、初期定点化時間（電源投入から最初の測位までの時間）（ＴＦＦＦ）を大幅に改善することができる。
【００１９】
とりわけ、サーバシステム１０２は、１２．５分周期で繰り返すナビゲーションデータメッセージを保持していて、要求があればこの一部分をクライアントシステム１０４に転送する。そうすることにより、クライアントシステム１０４は、保持転送されたナビゲーションデータメッセージに対して、自分が受け取るナビゲーションデータのパターンマッチングを行なうことができるようになる。そのため、クライアントシステム１０４は最初のＴＬＭワードの最初のプリアンブルを受け取る前でもナビゲーションデータフレームに対して同期することができる。
【００２０】
クライアントシステム１０４は、一般に電源が投入されるとゼロからスタートする自身の２４ビットミリ秒クロック（Msec24）を有する。ＧＰＳ Ｃ／Ａコードの周期（epoch）は1ミリ秒である。サーバシステム１０２はＧＰＳ時刻を知り、Ｚカウント数を有する。Ｚカウント数とは２９ビットの２進数で、基本となるＧＰＳ時刻の単位を表わす。上位の１０ビットはＧＰＳ週数を示し、下位の１９ビットは１．５秒単位での週の時刻（ＴＯＷ）数を示す。一旦、受信機がいくつかのＧＰＳ衛星にロックオンすれば、システム時刻のはるかに細かいゲージを利用することができる。従来の方法では、初期化の間にＺカウント数を判定することに依存してきた。
【００２１】
クライアントシステム１０４の初期化中に判定されなければならないのは具体的に何かというと、クライアントがローカルに持つクロック、例えばMesc24を、ＧＰＳ時刻にあわせるためにどれだけのオフセットを付加しなければならないかということである。これにより、正しいナビゲーションデータフレーム同期が決まる。受け取ったばかりのサブフレームを、サーバシステム１０２が観察したサブフレームのシーケンシャルレコードを検索するためのテンプレートとして使用すると、クライアントシステム１０４で同期を取るのに要する時間が大幅に短縮される。
【００２２】
一方、ネットワークで通信するバイトあたりのコストが比較的高価な場合は、クライアントシステム１０４が集めた信号をサーバシステム１０２に転送するのがより経済的である。そうすると、パターンマッチを見つけるのはサーバシステムの仕事となる。そのような場合、サーバシステム１０２は次に、クライアントが、使用する現在の整数ミリ秒を特定するのに役立つデータを送る。
【００２３】
このような状況では、サーバシステム１０２が、基準局が追尾するＧＰＳ衛星毎のナビゲーションデータサブフレームを保存するのが好ましい。サーバシステムは次に、自分と複数のネットワーククライアント１０４との間に存在するネットワークレイテンシを推定する。これにより、クライアント毎のＧＰＳ時刻の推定が可能となる。こうして得られたＧＰＳ時刻は、クライアントが今観察しなければならないナビゲーションデータサブフレームはどの部分かを示す。サーバシステムはこのナビゲーションデータフレームをコピーして、Ｚカウント数を書き換え、クライアントに送る前にＨＯＷにパリティビットを付加する。
【００２４】
本発明における方法の実施例では、クライアントシステム１０４はサーバシステム１０２から近似のＧＰＳ時刻（例えば、真のＧＰＳ時刻の１〜２秒以内）を得る。サーバシステム１０２とクライアントシステム１０４との間のネットワーク１０６上にはいくらかのネットワークパスの遅延がある。そうした遅延を考慮に入れる。
【００２５】
クライアントシステム１０４は、対象としているＧＰＳ時刻（例えば、或る特定のミリ秒間隔）を指定することによって、サーバシステム１０２にナビゲーションデータサブフレームを要求する。サーバシステム１０２はそのデータベースから、対応するサブフレームパターン集合をフェッチする。予想Ｚカウント数と共にＨＯＷを書き換え、適正パリティビットを付加する。要求されたサブフレームがネットワーク１０６を介して送られる。
【００２６】
クライアントシステム１０４は３０ビット長の移動ウィンドウを用いてサーバシステム１０２から提供されたサブフレームデータを検査し、ＧＰＳ衛星から直接今受信したデータと一致するかを調べる。一致しなければ、ウィンドウを1ビットシフトして次の３０ビット、という具合に３０ビットワードの比較を繰り返す。３０ビットの一致が見つかると、検証のためにその前後のワードもテストされる。一致が見つかったということは、フレーム同期が見つかったということである。次に、オフセット時間が計算されMsec24に加算され、クライアントシステム１０４はＧＰＳ時刻で初期化される。より正確には、ナビゲーションサブフレームデータの中の現在のＨＯＷからＺカウント数が抽出される。
【００２７】
概して言えば、本発明の実施例はパターンマッチングの技法に依存している。特定のパターンが問題となるため、「FFFFFF」、「000000」、「AAAAAA」、「555555」のような信頼性のないビットパターンは拒絶しなければならない。そうしたパターンは、打ち上げられていないＧＰＳ衛星や定義されていない軌道暦のページによく現れる。もう一つのパターンマッチングの問題はビット反転が原因で生じる。
【００２８】
典型的な受信機のファームウェアは、信号が弱過ぎると、時としてナビゲーションデータの位相反転を検出できないことがある。受信機が変化を検出し損なうと、その変化以降の全てのビットを逆にしなければならない。ゆえに、ビットの位相反転をある程度予期しておかなければならない。混合ＤＥＭＩモード時の観測によれば、３０もの位相反転が発生する可能性がある。ＴＬＭワードはサブフレームの頭を示しており、３０ビットのワード１０語につき一回現れる。その後にＨＯＷが続く。ＨＯＷはＺカウント数のうちの上位の１７ビットを含む。ワード１０の末尾にある先行２ビットは常に「00」である。これらの領域ではナビゲーションパターンは非常に類似しているので、探索ウィンドウが１０ワードを超えるとＴＬＭパターンとマッチさせることができない。
【００２９】
近似の時間を得ると、クライアント１０４は事前にサーバ１０２にサブフレームデータを要求する。クライアント１０４に戻されたＧＰＳ時刻には、ネットワーク１０６のレイテンシ等による不定の遅延がある。σlatencyの誤差範囲もまた然りである。
【００３０】
一つの実施例では、ナビゲーションパケットが最大で２秒のレイテンシ（例えば、グループナビゲーション間隔（1,000msec）＋最大ナビゲーションパケット長（1,000msec））を有するグループパケットとして送られる。そのために、クライアント１０４は、開始時間＝予想ナビゲーションパケット受信時間−（σlatency＋２sec.）を有するサブフレームを要求しなければならない。
ネットワーク及びシステムの応答のレイテンシを考慮に入れて、クライアント１０４に送られる適正ワード長が決まる。すなわち、
【数１】
【００３１】
ナビゲーションデータのストリームは５０ワードの繰り返し、つまり５つのサブフレーム１〜５の繰り返しである。サーバ１０２が１０ワード以上を送った場合は、ＴＬＭワードをマッチングに使用することはできない。これは、ＴＬＭワードのパターンは、各サブフレームの頭にしかないからである。
【００３２】
一つの実施例では、一旦フレームを同期させたら、次のＨＯＷの終わりからナビゲーションパケットの始まりまでのビットを数えることによってＧＰＳ時刻を判定することができる。ＨＯＷは切捨てられたＺカウント数の１７ビットを示している。ＨＯＷの終わりから次のサブフレームの始まりまでのオフセットは２４０ビット（例えば、4800msec）である。このオフセットを次のサブフレームから減算すると今のＧＰＳ時刻を得ることができる。例えば、
GPSTime(@msec24)＝Zcount×6000−(offset+240)×20−70[msec]
ＧＰＳ衛星と地球の表面との間の正確な送信伝搬時間を知ることは難しいので、７０ミリ秒というデフォルト値が理にかなっているように思われる。なぜならば、それをスタート値として用いると±１０ミリ秒の誤差範囲となる。
【００３３】
整数ミリ秒（intMsec）は、ユーザの位置とＧＰＳ衛星の位置と間の擬似距離を表わす。第１のＺカウント事象のＧＰＳ時刻を計算するとき、intMsecを７０ミリ秒と仮定する。次に、msec24変数とＧＰＳ時刻との間のオフセット時間（offGpsMsec）が計算される。第１のＺカウント事象の後、その事象はＧＰＳ時刻調整には用いないが、intMsec算出のためだけに用いられる。offGpsMsecに基づいて、次の方程式を用いて各ＧＰＳ衛星の整数ミリ秒（intMsec）を解く。ＧＰＳ時刻及びoffGpsMsecは、位置フィックス・ルーチンの中の時間バイアスを解くことによって調整される。
offGpsMsec＝Zcount×6000−{msec24＋(offset＋240)×20}−70[msec]
intMsec＝Zcount×6000−{msec24＋(offset＋240)×20}−offGpsMsec
【００３４】
本発明における好適なノンプリアンブル同期の方法には、パターンマッチングが失敗した場合に備えて、フォールバックＴＬＭプリアンブル同期検出プロセスが入っている。両スキームとも、同期した位置、例えば、ワードＩＤ、サブフレームＩＤ、ページＩＤ、現在のＺカウント数などをセットするだけである。そのために、これらの２つのスキームは、それぞれ独立して共存することができる。クライアント１０４がサーバ１０２からのサポートを利用できるようになると、先ずパターンマッチングを試みる。そして、ＴＬＭワードのプリアンブルを使用して同期を試みる。いずれかのスキームが成功したら、レシーバマネージャは、スムーズにデコーディングにシフトする。従って、適切なビットパターンをノンプリアンブル同期パターンマッチングに利用できない場合でも、フレームエッジはほぼ電源投入から６秒以内に同期することができる。
【００３５】
基準局サーバ１０２は、ＧＰＳ衛星毎のサブフレームデータを保存することによって、このようなノンプリアンブル同期パターンマッチングをサポートする。基準局サーバ１０２は、ネットワークレイテンシを推定してクライアント１０４でのＧＰＳ時刻を推測する。サーバ１０２は、クライアントのＧＰＳ時刻を中心とする、対応するサブフレームデータを検索する。サーバ１０２はＨＯＷの中のＺカウント数を書き換え、クライアント１０４に送るパケットのサブフレームデータを符号化する。
【００３６】
基準局で受信されたサブフレームデータはそれぞれデータベースに保持される。保持の対象となるサブフレームデータには、例えば、下記の、5,780バイトの軌道暦情報と、3,000バイトの衛星暦情報がある。
emphemeris＝3(subframes)*10(words)*24bits(w/o parity)*32(SV)
*2(pre/current IODE);
almanac＝25(pages)*2(SF)*10(words)*24bits(w/ parity)
*2(pre/current)
【００３７】
ＧＰＳ衛星からナビゲーションストリームが繰り返し送られてくるので、全てのナビゲーションビットを保持しなくてもいい。サーバは、いくつかのサブフレームデータあるいは、全てのワードのパリティビットを無視することができる。システムの軌道暦が変わると、基準局サーバ１０２とクライアント１０４が共に新たな軌道暦サブフレームを受信するまでは、ノンプリアンブルパターンマッチングはうまくいかない。システムの衛星暦が変わった場合も同様である。時には、全ＧＰＳ衛星の衛星暦情報が新しい衛星暦情報に完全に更新されるまで12時間以上かかることもある。そのために、前の衛星暦情報及び現在の衛星暦情報の両方をデータベースに保持しておかなけばならない。
【００３８】
クライアント１０４は、サーバ１０２から今のＧＰＳ時刻と一致するサブフレームデータを受け取ることによって初期化する。これを行なうために、サーバ１０２は、ネットワーク１０６で送信された情報パケットをクライアント１０４が実際に受け取るＧＰＳ時刻を近似する。その時間をどれだけ正確に近似できるかは、サーバがクライアントのＧＰＳ時刻をどれだけ正確に推定できるかということと、クライアントに送られるワードデータの大きさとにかかっている。サーバがクライアントＧＰＳ時刻を±３秒以内で推定できれば、ナビゲーションフレームを１０データワード（例えば、１サブフレーム）以内で同期させることが可能である。
【００３９】
クライアント１０４でＧＰＳ時刻を推定した後、サーバ１０２はデータベースを検索して現在のＧＰＳ時刻に対応するサブフレームデータを得る。軌道暦と衛星暦の２つのセットがあるから、サーバ１０２は、どちらのデータセットがＧＰＳ衛星で使用されなければならないかを追跡しなければならない。情報ワードを符号化する際、ワード１からのサブフレームデータとＴＬＭワードとが必要である。パリティビットはその前のワードデータの最後の２ビットによって決まり、ＨＯＷ及びワード１０は共に最後の２ビットが「00」である。
【００４０】
ＨＯＷを書き換えることが重要である。サーバは現在のＧＰＳ時刻を知っているので、ＨＯＷのＺカウント数を変更すると共に関連するパリティビットを修正することができる。サーバ１０２は開始ワードのＩＤと、３０ビットのデータワード１０語を送るのが望ましい。
【００４１】
本発明における方法の実施例を図２に示す。この実施例は、保存ナビゲーションデータフレームを提供できるデータネットワークに接続されたＧＰＳ受信機において、ナビゲーションデータフレーム同期を行なえるようになっている。方法２００はステップ２０２から始まり、まずサーバ（例えば、図１のサーバ１０２）を利用できるかどうかをテストする。サーバを利用できない場合には、ステップ２０４で要求し、ステップ２０６で要求に対する答を待つ。ステップ２１０で同期が見つかったかどうか確認する。見つからない場合は、ステップ２０２に戻る。
【００４２】
サーバデータを利用できる場合は、ノンプリアンブル同期パターンマッチングプロセス２１２が採用される。ステップ２１４で、ＧＰＳ衛星から受信したナビゲーションデータパターンをサーバから提供されたデータにマッチさせてみる。ステップ２１６でパターンマッチが見つかったら、ステップ２１８で整数ミリ秒（intMsec）がセットされる。
【００４３】
パターンマッチングプロセス２１２でマッチするパターンが見つからなかった場合は、フォールバックとしてレガシー同期プロセス２２０が採用される。ステップ２２２で、従来型のＴＬＭワードプリアンブル探索が行なわれる。ステップ２２４で、パターンが見つかったかどうかを確かめる。見つかった場合には、ステップ２２６で整数ミリ秒（「intMsec」）がセットされる。一旦整数ミリ秒変数がセットされたら、ステップ２２８はデコーディング及び位置の解へと処理を進める。
【図面の簡単な説明】
【００４４】
【図１】本発明におけるネットワークシステムの実施例の機能ブロック図。
【図２】本発明の方法実施例のフローチャート。
【符号の説明】
【００４５】
１００ ネットワークシステム、１０２ 基準局サーバシステム、
１０４ ユーザクライアントシステム、１０６ コンピュータネットワーク、
１０８、１１０、１１２、１１４、１１６ ナビゲーション衛星
【技術分野】
【０００１】
本発明はナビゲーション衛星受信機、より具体的には、ネットワークサーバを使用してナビゲーション衛星受信機の初期定点化時間（電源投入から最初の測位までの時間）（ＴＦＦＦ）を向上させる方法並びにシステムに関する発明である。
【背景技術】
【０００２】
全地球測位システム（ＧＰＳ）受信機は、地球の軌道を周回する衛生群の複数の衛星から受け取った信号を用いてユーザの位置や速度及びその他のナビゲーションデータを得る。電源投入直後のナビゲーション受信機は、その現在位置や現在時刻、あるいは水晶発振器の誤差について未だ分かっていない。衛星からの信号を捕らえてロックオンするにはこれらの情報が全て必要となるので、あらゆる可能性について探索がなされる。
【０００３】
各ＧＰＳ衛星（ＳＶ）はナビゲーション（ＮＡＶ）データをビット率５０bpsで送信する。ナビゲーションデータには、軌道暦情報、時間情報、衛星暦情報が含まれる。これらの情報により、ＧＰＳ受信機はその位置、速度、時間を算出することができる。ナビゲーションデータの１フレームは１５００ビット長で、その送信には３０秒かかる。
【０００４】
各フレームは５個のサブフレームに分割され、各サブフレームは３００ビット長で、例えば、３０ビットのワード１０語からなる。従って、３００ビット、すなわち１０語からなるサブフレームを送信するのには６秒必要となる。サブフレームは全て、３０ビットのテレメトリ（ＴＬＭ）ワードで始まり、その後に３０ビットのハンドオーバワード（ＨＯＷ）が続く。ＴＬＭ及びＨＯＷは、共に２４ビットのデータと６ビットのパリティから構成される。そして、各サブフレームは８語分のデータを有する。
【０００５】
３００ビット長のサブフレームの先頭にあるＴＬＭワードは、８ビットのプリアンブルで始まる。このプリアンブルによってサブフレームの始まりを認識することが可能になり、その後、このプリアンブル部が、受信機の同期をとるための主要な機構となる。
【０００６】
最初の３００ビット長のサブフレームは、ＴＬＭワード及びＨＯＷの後に、ＧＰＳ衛星時計補正データを送信する。２番目のサブフレームは、ＧＰＳ衛星軌道暦情報の最初の部分を送信する。３番目のサブフレームはＧＰＳ衛星軌道暦情報の２番目の部分を送信する。サブフレームの４番目と５番目を用いてシステムデータのあるページが送られる。４番目のサブフレームもＴＬＭワード及びＨＯＷで始まり、１２．５分かけて電離層、ＵＴＣ、その他のデータに関する長い情報を送信する。つまり２５フレーム（１２５サブフレーム）で、１セットの完全なナビゲーション情報を構成し、その送信には１２．５分を要する。５番目のサブフレームもＴＬＭワード及びＨＯＷで始まり、そのデータも１２．５分かけてどちらかといえば大きな衛星暦情報を送信する。
【０００７】
時計情報パラメータはＧＰＳ衛星時計及びＧＰＳ衛星時計とＧＰＳ時刻の関係を記述し、軌道暦パラメータは衛星軌道の短い区分のＧＰＳ衛星軌道を記述するものである。通常、受信機は一時間毎に新たな軌道暦情報を収集するが、４時間以内なら古いデータを使用しても大きな誤差にはならない。軌道暦パラメータは、軌道暦パラメータ集合で記述された軌道周期内でれば、任意の時間の間ＧＰＳ衛星の位置を計算するアルゴリズムと共に用いられる。衛星暦は全ＧＰＳ衛星の近似軌道データパラメータである。１０パラメータの衛星暦は長い期間にわたるＧＰＳ衛星軌道を記述し、時には数ヶ月間使用できる。
【０００８】
現在の衛星軌道を利用することによって、起動時にＧＰＳ受信機が信号を捕らえる時間をかなり短くすることができる。この近似軌道データが、衛星群の中のＧＰＳ衛星の概略の位置や搬送ドップラー周波数と共に、受信機をプリセットするのに用いられる。
【０００９】
【特許文献１】米国特許第５，７８１，１５６号
【発明の開示】
【発明が解決しようとする課題】
【００１０】
従って、従来の機器では、受信機のナビゲーションデータに対する同期は、ＴＬＭワードのプリアンブルパターン（８ビット）の検出に依存していた。ＴＬＭワードは６秒毎にしか送信されないので、検出までに３秒以上かかることもある。このような遅延は、ユーザにとって重要な判断基準となる初期定点化時間（電源投入から最初の測位までの時間）（ＴＴＦＦ）性能の低下へつながる。
【課題を解決するための手段】
【００１１】
ゆえに、本発明の目的は、ＴＬＭワードのプリアンブルを実際に受け取らずに処理することができる、ナビゲーション衛星受信及び受信機初期化のための方法並びにシステムを提供することにある。
【００１２】
本発明のもう一つの目的は、ナビゲーション機器の初期化に要する時間を短縮する方法並びにシステムを提供することである。
【００１３】
本発明の更なる目的は、安価な衛星ナビゲーションシステムを提供することである。
【００１４】
簡単に言えば、本発明のナビゲーション衛星受信機の実施例は、基準局にナビゲーションデータサブフレームを持たせ、クライアントでパターンマッチングを行なう。バイト単位の通信費用が高い場合は、サーバでパターンマッチングを行なってもよい。保持されたナビゲーションデータは、３０秒毎に軌道暦情報を、また１２.５分毎に全衛星暦情報を繰り返す。これにより、クライアントは、受信した信号が一連のナビゲーションデータのどこであるかのかを速やかに認識することができるので、ＴＬＭワードのプリアンブルを待たなくていい。これにより、高速な初期定点化時間を実現するのに重要な数秒間を節約することができる。
【００１５】
本発明の効果は、ナビゲーション衛星受信機で初期化時間をより高速にするシステム並びに方法を提供することである。
【００１６】
本発明の上記のそして他の目的及び効果については、以下に述べる、図面に示した好適な実施例の詳細な説明を読めば、当業者には明白になることは疑いの余地がない。
【発明を実施するための最良の形態】
【００１７】
図1に、本発明における実施例のネットワークシステム１００を示す。ネットワークシステム１００は、基準局サーバシステム１０２と、ユーザクライアントシステム１０４、及びインターネットなど介在型のコンピュータネットワーク１０６を備える。サーバシステム１０２はナビゲーション衛星受信機を備え、このナビゲーション衛星受信機がナビゲーション衛星１０８、１１０、１１２からなる衛星群をロックオンして追跡している。これらの衛星のいくつかは、クライアントシステム１０４からも捕らえることができるかもしれない。ナビゲーション衛星１１４、１１６を含む他のナビゲーション衛星群がクライアントシステム１０４から捕らえられる。クライアントシステム１０４は、ナビゲーション衛星受信機を自分で持っているが、その受信機はナビゲーション衛星１１２、１１４、１１６の衛星群をまだロックオンできてなく、追尾していないかもしれない。
【００１８】
サーバシステム１０２は常時電源が供給され、ナビゲーション衛星１０８、１１０、１１２からなる衛星群を追跡している。したがって、正確なシステムの絶対時間を知ることができると共に、現在の軌道暦、対流圏、電離層、その他の情報を、ネットワーククライアントとして接続されている、まだ初期化されていないナビゲーション衛星受信機に提供することもできる。これらの情報は全て初期化の際に確定されなければならないので、これらの情報が他のソースから提供できれば、その情報が何であれ、初期定点化時間（電源投入から最初の測位までの時間）（ＴＦＦＦ）を大幅に改善することができる。
【００１９】
とりわけ、サーバシステム１０２は、１２．５分周期で繰り返すナビゲーションデータメッセージを保持していて、要求があればこの一部分をクライアントシステム１０４に転送する。そうすることにより、クライアントシステム１０４は、保持転送されたナビゲーションデータメッセージに対して、自分が受け取るナビゲーションデータのパターンマッチングを行なうことができるようになる。そのため、クライアントシステム１０４は最初のＴＬＭワードの最初のプリアンブルを受け取る前でもナビゲーションデータフレームに対して同期することができる。
【００２０】
クライアントシステム１０４は、一般に電源が投入されるとゼロからスタートする自身の２４ビットミリ秒クロック（Msec24）を有する。ＧＰＳ Ｃ／Ａコードの周期（epoch）は1ミリ秒である。サーバシステム１０２はＧＰＳ時刻を知り、Ｚカウント数を有する。Ｚカウント数とは２９ビットの２進数で、基本となるＧＰＳ時刻の単位を表わす。上位の１０ビットはＧＰＳ週数を示し、下位の１９ビットは１．５秒単位での週の時刻（ＴＯＷ）数を示す。一旦、受信機がいくつかのＧＰＳ衛星にロックオンすれば、システム時刻のはるかに細かいゲージを利用することができる。従来の方法では、初期化の間にＺカウント数を判定することに依存してきた。
【００２１】
クライアントシステム１０４の初期化中に判定されなければならないのは具体的に何かというと、クライアントがローカルに持つクロック、例えばMesc24を、ＧＰＳ時刻にあわせるためにどれだけのオフセットを付加しなければならないかということである。これにより、正しいナビゲーションデータフレーム同期が決まる。受け取ったばかりのサブフレームを、サーバシステム１０２が観察したサブフレームのシーケンシャルレコードを検索するためのテンプレートとして使用すると、クライアントシステム１０４で同期を取るのに要する時間が大幅に短縮される。
【００２２】
一方、ネットワークで通信するバイトあたりのコストが比較的高価な場合は、クライアントシステム１０４が集めた信号をサーバシステム１０２に転送するのがより経済的である。そうすると、パターンマッチを見つけるのはサーバシステムの仕事となる。そのような場合、サーバシステム１０２は次に、クライアントが、使用する現在の整数ミリ秒を特定するのに役立つデータを送る。
【００２３】
このような状況では、サーバシステム１０２が、基準局が追尾するＧＰＳ衛星毎のナビゲーションデータサブフレームを保存するのが好ましい。サーバシステムは次に、自分と複数のネットワーククライアント１０４との間に存在するネットワークレイテンシを推定する。これにより、クライアント毎のＧＰＳ時刻の推定が可能となる。こうして得られたＧＰＳ時刻は、クライアントが今観察しなければならないナビゲーションデータサブフレームはどの部分かを示す。サーバシステムはこのナビゲーションデータフレームをコピーして、Ｚカウント数を書き換え、クライアントに送る前にＨＯＷにパリティビットを付加する。
【００２４】
本発明における方法の実施例では、クライアントシステム１０４はサーバシステム１０２から近似のＧＰＳ時刻（例えば、真のＧＰＳ時刻の１〜２秒以内）を得る。サーバシステム１０２とクライアントシステム１０４との間のネットワーク１０６上にはいくらかのネットワークパスの遅延がある。そうした遅延を考慮に入れる。
【００２５】
クライアントシステム１０４は、対象としているＧＰＳ時刻（例えば、或る特定のミリ秒間隔）を指定することによって、サーバシステム１０２にナビゲーションデータサブフレームを要求する。サーバシステム１０２はそのデータベースから、対応するサブフレームパターン集合をフェッチする。予想Ｚカウント数と共にＨＯＷを書き換え、適正パリティビットを付加する。要求されたサブフレームがネットワーク１０６を介して送られる。
【００２６】
クライアントシステム１０４は３０ビット長の移動ウィンドウを用いてサーバシステム１０２から提供されたサブフレームデータを検査し、ＧＰＳ衛星から直接今受信したデータと一致するかを調べる。一致しなければ、ウィンドウを1ビットシフトして次の３０ビット、という具合に３０ビットワードの比較を繰り返す。３０ビットの一致が見つかると、検証のためにその前後のワードもテストされる。一致が見つかったということは、フレーム同期が見つかったということである。次に、オフセット時間が計算されMsec24に加算され、クライアントシステム１０４はＧＰＳ時刻で初期化される。より正確には、ナビゲーションサブフレームデータの中の現在のＨＯＷからＺカウント数が抽出される。
【００２７】
概して言えば、本発明の実施例はパターンマッチングの技法に依存している。特定のパターンが問題となるため、「FFFFFF」、「000000」、「AAAAAA」、「555555」のような信頼性のないビットパターンは拒絶しなければならない。そうしたパターンは、打ち上げられていないＧＰＳ衛星や定義されていない軌道暦のページによく現れる。もう一つのパターンマッチングの問題はビット反転が原因で生じる。
【００２８】
典型的な受信機のファームウェアは、信号が弱過ぎると、時としてナビゲーションデータの位相反転を検出できないことがある。受信機が変化を検出し損なうと、その変化以降の全てのビットを逆にしなければならない。ゆえに、ビットの位相反転をある程度予期しておかなければならない。混合ＤＥＭＩモード時の観測によれば、３０もの位相反転が発生する可能性がある。ＴＬＭワードはサブフレームの頭を示しており、３０ビットのワード１０語につき一回現れる。その後にＨＯＷが続く。ＨＯＷはＺカウント数のうちの上位の１７ビットを含む。ワード１０の末尾にある先行２ビットは常に「00」である。これらの領域ではナビゲーションパターンは非常に類似しているので、探索ウィンドウが１０ワードを超えるとＴＬＭパターンとマッチさせることができない。
【００２９】
近似の時間を得ると、クライアント１０４は事前にサーバ１０２にサブフレームデータを要求する。クライアント１０４に戻されたＧＰＳ時刻には、ネットワーク１０６のレイテンシ等による不定の遅延がある。σlatencyの誤差範囲もまた然りである。
【００３０】
一つの実施例では、ナビゲーションパケットが最大で２秒のレイテンシ（例えば、グループナビゲーション間隔（1,000msec）＋最大ナビゲーションパケット長（1,000msec））を有するグループパケットとして送られる。そのために、クライアント１０４は、開始時間＝予想ナビゲーションパケット受信時間−（σlatency＋２sec.）を有するサブフレームを要求しなければならない。
ネットワーク及びシステムの応答のレイテンシを考慮に入れて、クライアント１０４に送られる適正ワード長が決まる。すなわち、
【数１】
【００３１】
ナビゲーションデータのストリームは５０ワードの繰り返し、つまり５つのサブフレーム１〜５の繰り返しである。サーバ１０２が１０ワード以上を送った場合は、ＴＬＭワードをマッチングに使用することはできない。これは、ＴＬＭワードのパターンは、各サブフレームの頭にしかないからである。
【００３２】
一つの実施例では、一旦フレームを同期させたら、次のＨＯＷの終わりからナビゲーションパケットの始まりまでのビットを数えることによってＧＰＳ時刻を判定することができる。ＨＯＷは切捨てられたＺカウント数の１７ビットを示している。ＨＯＷの終わりから次のサブフレームの始まりまでのオフセットは２４０ビット（例えば、4800msec）である。このオフセットを次のサブフレームから減算すると今のＧＰＳ時刻を得ることができる。例えば、
GPSTime(@msec24)＝Zcount×6000−(offset+240)×20−70[msec]
ＧＰＳ衛星と地球の表面との間の正確な送信伝搬時間を知ることは難しいので、７０ミリ秒というデフォルト値が理にかなっているように思われる。なぜならば、それをスタート値として用いると±１０ミリ秒の誤差範囲となる。
【００３３】
整数ミリ秒（intMsec）は、ユーザの位置とＧＰＳ衛星の位置と間の擬似距離を表わす。第１のＺカウント事象のＧＰＳ時刻を計算するとき、intMsecを７０ミリ秒と仮定する。次に、msec24変数とＧＰＳ時刻との間のオフセット時間（offGpsMsec）が計算される。第１のＺカウント事象の後、その事象はＧＰＳ時刻調整には用いないが、intMsec算出のためだけに用いられる。offGpsMsecに基づいて、次の方程式を用いて各ＧＰＳ衛星の整数ミリ秒（intMsec）を解く。ＧＰＳ時刻及びoffGpsMsecは、位置フィックス・ルーチンの中の時間バイアスを解くことによって調整される。
offGpsMsec＝Zcount×6000−{msec24＋(offset＋240)×20}−70[msec]
intMsec＝Zcount×6000−{msec24＋(offset＋240)×20}−offGpsMsec
【００３４】
本発明における好適なノンプリアンブル同期の方法には、パターンマッチングが失敗した場合に備えて、フォールバックＴＬＭプリアンブル同期検出プロセスが入っている。両スキームとも、同期した位置、例えば、ワードＩＤ、サブフレームＩＤ、ページＩＤ、現在のＺカウント数などをセットするだけである。そのために、これらの２つのスキームは、それぞれ独立して共存することができる。クライアント１０４がサーバ１０２からのサポートを利用できるようになると、先ずパターンマッチングを試みる。そして、ＴＬＭワードのプリアンブルを使用して同期を試みる。いずれかのスキームが成功したら、レシーバマネージャは、スムーズにデコーディングにシフトする。従って、適切なビットパターンをノンプリアンブル同期パターンマッチングに利用できない場合でも、フレームエッジはほぼ電源投入から６秒以内に同期することができる。
【００３５】
基準局サーバ１０２は、ＧＰＳ衛星毎のサブフレームデータを保存することによって、このようなノンプリアンブル同期パターンマッチングをサポートする。基準局サーバ１０２は、ネットワークレイテンシを推定してクライアント１０４でのＧＰＳ時刻を推測する。サーバ１０２は、クライアントのＧＰＳ時刻を中心とする、対応するサブフレームデータを検索する。サーバ１０２はＨＯＷの中のＺカウント数を書き換え、クライアント１０４に送るパケットのサブフレームデータを符号化する。
【００３６】
基準局で受信されたサブフレームデータはそれぞれデータベースに保持される。保持の対象となるサブフレームデータには、例えば、下記の、5,780バイトの軌道暦情報と、3,000バイトの衛星暦情報がある。
emphemeris＝3(subframes)*10(words)*24bits(w/o parity)*32(SV)
*2(pre/current IODE);
almanac＝25(pages)*2(SF)*10(words)*24bits(w/ parity)
*2(pre/current)
【００３７】
ＧＰＳ衛星からナビゲーションストリームが繰り返し送られてくるので、全てのナビゲーションビットを保持しなくてもいい。サーバは、いくつかのサブフレームデータあるいは、全てのワードのパリティビットを無視することができる。システムの軌道暦が変わると、基準局サーバ１０２とクライアント１０４が共に新たな軌道暦サブフレームを受信するまでは、ノンプリアンブルパターンマッチングはうまくいかない。システムの衛星暦が変わった場合も同様である。時には、全ＧＰＳ衛星の衛星暦情報が新しい衛星暦情報に完全に更新されるまで12時間以上かかることもある。そのために、前の衛星暦情報及び現在の衛星暦情報の両方をデータベースに保持しておかなけばならない。
【００３８】
クライアント１０４は、サーバ１０２から今のＧＰＳ時刻と一致するサブフレームデータを受け取ることによって初期化する。これを行なうために、サーバ１０２は、ネットワーク１０６で送信された情報パケットをクライアント１０４が実際に受け取るＧＰＳ時刻を近似する。その時間をどれだけ正確に近似できるかは、サーバがクライアントのＧＰＳ時刻をどれだけ正確に推定できるかということと、クライアントに送られるワードデータの大きさとにかかっている。サーバがクライアントＧＰＳ時刻を±３秒以内で推定できれば、ナビゲーションフレームを１０データワード（例えば、１サブフレーム）以内で同期させることが可能である。
【００３９】
クライアント１０４でＧＰＳ時刻を推定した後、サーバ１０２はデータベースを検索して現在のＧＰＳ時刻に対応するサブフレームデータを得る。軌道暦と衛星暦の２つのセットがあるから、サーバ１０２は、どちらのデータセットがＧＰＳ衛星で使用されなければならないかを追跡しなければならない。情報ワードを符号化する際、ワード１からのサブフレームデータとＴＬＭワードとが必要である。パリティビットはその前のワードデータの最後の２ビットによって決まり、ＨＯＷ及びワード１０は共に最後の２ビットが「00」である。
【００４０】
ＨＯＷを書き換えることが重要である。サーバは現在のＧＰＳ時刻を知っているので、ＨＯＷのＺカウント数を変更すると共に関連するパリティビットを修正することができる。サーバ１０２は開始ワードのＩＤと、３０ビットのデータワード１０語を送るのが望ましい。
【００４１】
本発明における方法の実施例を図２に示す。この実施例は、保存ナビゲーションデータフレームを提供できるデータネットワークに接続されたＧＰＳ受信機において、ナビゲーションデータフレーム同期を行なえるようになっている。方法２００はステップ２０２から始まり、まずサーバ（例えば、図１のサーバ１０２）を利用できるかどうかをテストする。サーバを利用できない場合には、ステップ２０４で要求し、ステップ２０６で要求に対する答を待つ。ステップ２１０で同期が見つかったかどうか確認する。見つからない場合は、ステップ２０２に戻る。
【００４２】
サーバデータを利用できる場合は、ノンプリアンブル同期パターンマッチングプロセス２１２が採用される。ステップ２１４で、ＧＰＳ衛星から受信したナビゲーションデータパターンをサーバから提供されたデータにマッチさせてみる。ステップ２１６でパターンマッチが見つかったら、ステップ２１８で整数ミリ秒（intMsec）がセットされる。
【００４３】
パターンマッチングプロセス２１２でマッチするパターンが見つからなかった場合は、フォールバックとしてレガシー同期プロセス２２０が採用される。ステップ２２２で、従来型のＴＬＭワードプリアンブル探索が行なわれる。ステップ２２４で、パターンが見つかったかどうかを確かめる。見つかった場合には、ステップ２２６で整数ミリ秒（「intMsec」）がセットされる。一旦整数ミリ秒変数がセットされたら、ステップ２２８はデコーディング及び位置の解へと処理を進める。
【図面の簡単な説明】
【００４４】
【図１】本発明におけるネットワークシステムの実施例の機能ブロック図。
【図２】本発明の方法実施例のフローチャート。
【符号の説明】
【００４５】
１００ ネットワークシステム、１０２ 基準局サーバシステム、
１０４ ユーザクライアントシステム、１０６ コンピュータネットワーク、
１０８、１１０、１１２、１１４、１１６ ナビゲーション衛星
【特許請求の範囲】
【請求項１】
サーバシステムと通信可能であり、ＧＰＳ衛星からのＧＰＳ衛星信号に基づいて当該ＧＰＳ衛星と自クライアントシステム間の擬似距離を算出して現在位置を測位するクライアントシステムであって、
前記サーバシステムは、
ＧＰＳ衛星から受信したＧＰＳ衛星信号に含まれるサブフレームデータを保持するデータベースと、
ＧＰＳ衛星から受信したＧＰＳ衛星信号に基づいてＧＰＳ時刻を認知して真のＧＰＳ時刻を計時するサーバ側ＧＰＳ時刻計時部と、
前記クライアントシステムと前記サーバシステム間の通信遅延を推定して、当該クライアントシステムでＧＰＳ衛星信号を受信する際の当該ＧＰＳ衛星信号のＧＰＳ時刻を推定し、前記データベースに保持したサブフレームデータをコピーして、該サブフレームデータに記述されているＧＰＳ時刻を当該推定したＧＰＳ時刻に修正して前記クライアントシステムに送信するサブフレームデータ送信部と、
を備えており、
前記クライアントシステムは、
前記サーバシステムとの間で所定の通信処理を行って真のＧＰＳ時刻と必ずしも一致する必要のない真のＧＰＳ時刻に近似するＧＰＳ時刻を取得してＧＰＳ時刻を計時するクライアント側ＧＰＳ時刻計時部と、
前記サーバシステムから受信したサブフレームデータのうちの所定ビット長のデータ部分をずらしつつ、ＧＰＳ衛星から現在受信した前記所定ビット長のデータとの一致を検出するフレーム同期検出部と、
前記検出に応じて、前記サーバシステムから受信したサブフレームデータに記述されているＧＰＳ時刻に基づいて前記クライアント側ＧＰＳ時刻計時部で計時されているＧＰＳ時刻を補正するＧＰＳ時刻補正部と、
ＧＰＳ衛星から受信したＧＰＳ衛星信号に含まれるサブレフレームデータに記述されているＧＰＳ時刻と前記クライアント側ＧＰＳ時刻計時部で計時されている現在のＧＰＳ時刻とのオフセット時間を用いて当該ＧＰＳ衛星とクライアントシステム間の擬似距離を算出する擬似距離算出部と、
を備えたクライアントシステム。
【請求項２】
前記フレーム同期検出部は、前記サーバシステムから受信したサブフレームデータのうちの１ワード分のビット長のデータ部分をずらしつつ、ＧＰＳ衛星から現在受信した前記１ワード分のビット長のデータとの一致を検出する請求項１に記載のクライアントシステム。
【請求項３】
サーバシステムとクライアントシステムとを具備し、前記クライアントシステムがＧＰＳ衛星からのＧＰＳ衛星信号に基づいて当該ＧＰＳ衛星と自クライアントシステム間の擬似距離を算出して現在位置を測位するネットワークシステムであって、
前記サーバシステムは、
ＧＰＳ衛星から受信したＧＰＳ衛星信号に含まれるサブフレームデータを保持するデータベースと、
ＧＰＳ衛星から受信したＧＰＳ衛星信号に基づいてＧＰＳ時刻を認知して真のＧＰＳ時刻を計時するサーバ側ＧＰＳ時刻計時部と、
前記クライアントシステムと前記サーバシステム間の通信遅延を推定して、当該クライアントシステムでＧＰＳ衛星信号を受信する際の当該ＧＰＳ衛星信号のＧＰＳ時刻を推定し、前記データベースに保持したサブフレームデータをコピーして、該サブフレームデータに記述されているＧＰＳ時刻を当該推定したＧＰＳ時刻に修正して前記クライアントシステムに送信するサブフレームデータ送信部と、
を備え、
前記クライアントシステムは、
前記サーバシステムとの間で所定の通信処理を行って真のＧＰＳ時刻と必ずしも一致する必要のない真のＧＰＳ時刻に近似するＧＰＳ時刻を取得してＧＰＳ時刻を計時するクライアント側ＧＰＳ時刻計時部と、
前記サーバシステムから受信したサブフレームデータのうちの所定ビット長のデータ部分をずらしつつ、ＧＰＳ衛星から現在受信した前記所定ビット長のデータとの一致を検出するフレーム同期検出部と、
前記検出に応じて、前記サーバシステムから受信したサブフレームデータに記述されているＧＰＳ時刻に基づいて前記クライアント側ＧＰＳ時刻計時部で計時されているＧＰＳ時刻を補正するＧＰＳ時刻補正部と、
ＧＰＳ衛星から受信したＧＰＳ衛星信号に含まれるサブレフレームデータに記述されているＧＰＳ時刻と前記クライアント側ＧＰＳ時刻計時部で計時されている現在のＧＰＳ時刻とのオフセット時間を用いて当該ＧＰＳ衛星とクライアントシステム間の擬似距離を算出する擬似距離算出部と、
を備えたネットワークシステム。
【請求項４】
サーバシステムとクライアントシステムとを具備し、前記クライアントシステムがＧＰＳ衛星からのＧＰＳ衛星信号に基づいて当該ＧＰＳ衛星と自クライアントシステム間の擬似距離を算出して現在位置を測位するネットワークシステムであって、
サーバシステムと通信可能であり、前記サーバシステムとの間で所定の通信処理を行って真のＧＰＳ時刻と必ずしも一致する必要のない真のＧＰＳ時刻に近似するＧＰＳ時刻を取得してＧＰＳ時刻を計時するクライアント側ＧＰＳ時刻計時部を備えたクライアントシステムが、ＧＰＳ衛星からのＧＰＳ衛星信号に基づいて当該ＧＰＳ衛星と自クライアントシステム間の擬似距離を算出して現在位置を測位する測位方法であって、
前記サーバシステムは、ＧＰＳ衛星から受信したＧＰＳ衛星信号に含まれるサブフレームデータを保持するデータベースと、ＧＰＳ衛星から受信したＧＰＳ衛星信号に基づいてＧＰＳ時刻を認知して真のＧＰＳ時刻を計時するサーバ側ＧＰＳ時刻計時部と、前記クライアントシステムと前記サーバシステム間の通信遅延を推定して、当該クライアントシステムでＧＰＳ衛星信号を受信する際の当該ＧＰＳ衛星信号のＧＰＳ時刻を推定し、前記データベースに保持したサブフレームデータをコピーして、該サブフレームデータに記述されているＧＰＳ時刻を当該推定したＧＰＳ時刻に修正して前記クライアントシステムに送信するサブフレームデータ送信部と、を備えて構成されており、
前記クライアントシステムが、
前記サーバシステムから受信したサブフレームデータのうちの所定ビット長のデータ部分をずらしつつ、ＧＰＳ衛星から現在受信した前記所定ビット長のデータとの一致を検出することと、
前記検出に応じて、前記サーバシステムから受信したサブフレームデータに記述されているＧＰＳ時刻に基づいて前記クライアント側ＧＰＳ時刻計時部で計時されているＧＰＳ時刻を補正することと、
ＧＰＳ衛星から受信したＧＰＳ衛星信号に含まれるサブレフレームデータに記述されているＧＰＳ時刻と前記クライアント側ＧＰＳ時刻計時部で計時されている現在のＧＰＳ時刻とのオフセット時間を用いて当該ＧＰＳ衛星とクライアントシステム間の擬似距離を算出することと、
を含む測位方法。
【請求項１】
サーバシステムと通信可能であり、ＧＰＳ衛星からのＧＰＳ衛星信号に基づいて当該ＧＰＳ衛星と自クライアントシステム間の擬似距離を算出して現在位置を測位するクライアントシステムであって、
前記サーバシステムは、
ＧＰＳ衛星から受信したＧＰＳ衛星信号に含まれるサブフレームデータを保持するデータベースと、
ＧＰＳ衛星から受信したＧＰＳ衛星信号に基づいてＧＰＳ時刻を認知して真のＧＰＳ時刻を計時するサーバ側ＧＰＳ時刻計時部と、
前記クライアントシステムと前記サーバシステム間の通信遅延を推定して、当該クライアントシステムでＧＰＳ衛星信号を受信する際の当該ＧＰＳ衛星信号のＧＰＳ時刻を推定し、前記データベースに保持したサブフレームデータをコピーして、該サブフレームデータに記述されているＧＰＳ時刻を当該推定したＧＰＳ時刻に修正して前記クライアントシステムに送信するサブフレームデータ送信部と、
を備えており、
前記クライアントシステムは、
前記サーバシステムとの間で所定の通信処理を行って真のＧＰＳ時刻と必ずしも一致する必要のない真のＧＰＳ時刻に近似するＧＰＳ時刻を取得してＧＰＳ時刻を計時するクライアント側ＧＰＳ時刻計時部と、
前記サーバシステムから受信したサブフレームデータのうちの所定ビット長のデータ部分をずらしつつ、ＧＰＳ衛星から現在受信した前記所定ビット長のデータとの一致を検出するフレーム同期検出部と、
前記検出に応じて、前記サーバシステムから受信したサブフレームデータに記述されているＧＰＳ時刻に基づいて前記クライアント側ＧＰＳ時刻計時部で計時されているＧＰＳ時刻を補正するＧＰＳ時刻補正部と、
ＧＰＳ衛星から受信したＧＰＳ衛星信号に含まれるサブレフレームデータに記述されているＧＰＳ時刻と前記クライアント側ＧＰＳ時刻計時部で計時されている現在のＧＰＳ時刻とのオフセット時間を用いて当該ＧＰＳ衛星とクライアントシステム間の擬似距離を算出する擬似距離算出部と、
を備えたクライアントシステム。
【請求項２】
前記フレーム同期検出部は、前記サーバシステムから受信したサブフレームデータのうちの１ワード分のビット長のデータ部分をずらしつつ、ＧＰＳ衛星から現在受信した前記１ワード分のビット長のデータとの一致を検出する請求項１に記載のクライアントシステム。
【請求項３】
サーバシステムとクライアントシステムとを具備し、前記クライアントシステムがＧＰＳ衛星からのＧＰＳ衛星信号に基づいて当該ＧＰＳ衛星と自クライアントシステム間の擬似距離を算出して現在位置を測位するネットワークシステムであって、
前記サーバシステムは、
ＧＰＳ衛星から受信したＧＰＳ衛星信号に含まれるサブフレームデータを保持するデータベースと、
ＧＰＳ衛星から受信したＧＰＳ衛星信号に基づいてＧＰＳ時刻を認知して真のＧＰＳ時刻を計時するサーバ側ＧＰＳ時刻計時部と、
前記クライアントシステムと前記サーバシステム間の通信遅延を推定して、当該クライアントシステムでＧＰＳ衛星信号を受信する際の当該ＧＰＳ衛星信号のＧＰＳ時刻を推定し、前記データベースに保持したサブフレームデータをコピーして、該サブフレームデータに記述されているＧＰＳ時刻を当該推定したＧＰＳ時刻に修正して前記クライアントシステムに送信するサブフレームデータ送信部と、
を備え、
前記クライアントシステムは、
前記サーバシステムとの間で所定の通信処理を行って真のＧＰＳ時刻と必ずしも一致する必要のない真のＧＰＳ時刻に近似するＧＰＳ時刻を取得してＧＰＳ時刻を計時するクライアント側ＧＰＳ時刻計時部と、
前記サーバシステムから受信したサブフレームデータのうちの所定ビット長のデータ部分をずらしつつ、ＧＰＳ衛星から現在受信した前記所定ビット長のデータとの一致を検出するフレーム同期検出部と、
前記検出に応じて、前記サーバシステムから受信したサブフレームデータに記述されているＧＰＳ時刻に基づいて前記クライアント側ＧＰＳ時刻計時部で計時されているＧＰＳ時刻を補正するＧＰＳ時刻補正部と、
ＧＰＳ衛星から受信したＧＰＳ衛星信号に含まれるサブレフレームデータに記述されているＧＰＳ時刻と前記クライアント側ＧＰＳ時刻計時部で計時されている現在のＧＰＳ時刻とのオフセット時間を用いて当該ＧＰＳ衛星とクライアントシステム間の擬似距離を算出する擬似距離算出部と、
を備えたネットワークシステム。
【請求項４】
サーバシステムとクライアントシステムとを具備し、前記クライアントシステムがＧＰＳ衛星からのＧＰＳ衛星信号に基づいて当該ＧＰＳ衛星と自クライアントシステム間の擬似距離を算出して現在位置を測位するネットワークシステムであって、
サーバシステムと通信可能であり、前記サーバシステムとの間で所定の通信処理を行って真のＧＰＳ時刻と必ずしも一致する必要のない真のＧＰＳ時刻に近似するＧＰＳ時刻を取得してＧＰＳ時刻を計時するクライアント側ＧＰＳ時刻計時部を備えたクライアントシステムが、ＧＰＳ衛星からのＧＰＳ衛星信号に基づいて当該ＧＰＳ衛星と自クライアントシステム間の擬似距離を算出して現在位置を測位する測位方法であって、
前記サーバシステムは、ＧＰＳ衛星から受信したＧＰＳ衛星信号に含まれるサブフレームデータを保持するデータベースと、ＧＰＳ衛星から受信したＧＰＳ衛星信号に基づいてＧＰＳ時刻を認知して真のＧＰＳ時刻を計時するサーバ側ＧＰＳ時刻計時部と、前記クライアントシステムと前記サーバシステム間の通信遅延を推定して、当該クライアントシステムでＧＰＳ衛星信号を受信する際の当該ＧＰＳ衛星信号のＧＰＳ時刻を推定し、前記データベースに保持したサブフレームデータをコピーして、該サブフレームデータに記述されているＧＰＳ時刻を当該推定したＧＰＳ時刻に修正して前記クライアントシステムに送信するサブフレームデータ送信部と、を備えて構成されており、
前記クライアントシステムが、
前記サーバシステムから受信したサブフレームデータのうちの所定ビット長のデータ部分をずらしつつ、ＧＰＳ衛星から現在受信した前記所定ビット長のデータとの一致を検出することと、
前記検出に応じて、前記サーバシステムから受信したサブフレームデータに記述されているＧＰＳ時刻に基づいて前記クライアント側ＧＰＳ時刻計時部で計時されているＧＰＳ時刻を補正することと、
ＧＰＳ衛星から受信したＧＰＳ衛星信号に含まれるサブレフレームデータに記述されているＧＰＳ時刻と前記クライアント側ＧＰＳ時刻計時部で計時されている現在のＧＰＳ時刻とのオフセット時間を用いて当該ＧＰＳ衛星とクライアントシステム間の擬似距離を算出することと、
を含む測位方法。
【図１】
【図２】
【図２】
【公開番号】特開２００８−２０３２６６（Ｐ２００８−２０３２６６Ａ）
【公開日】平成２０年９月４日（２００８．９．４）
【国際特許分類】
【出願番号】特願２００８−６４７５８（Ｐ２００８−６４７５８）
【出願日】平成２０年３月１３日（２００８．３．１３）
【分割の表示】特願２００３−４１７０１（Ｐ２００３−４１７０１）の分割
【原出願日】平成１５年２月１９日（２００３．２．１９）
【出願人】（０００００２３６９）セイコーエプソン株式会社 (51,324)
【出願人】（５０１３９６０２６）イーライド，インク． (10)
【氏名又は名称原語表記】ｅＲｉｄｅ，Ｉｎｃ．
【住所又は居所原語表記】Ｏｎｅ Ｌｅｔｔｅｒｍａｎ Ｄｒｉｖｅ，Ｂｌｄｇ．Ｃ，Ｓｕｉｔｅ ３１０ Ｔｈｅ Ｐｒｅｓｉｄｉｏ ｏｆ Ｓａｎ Ｆｒａｎｃｉｓｃｏ Ｓａｎ Ｆｒａｎｃｉｓｃｏ，ＣＡ ＵＳＡ
【Ｆターム（参考）】
【公開日】平成２０年９月４日（２００８．９．４）
【国際特許分類】
【出願日】平成２０年３月１３日（２００８．３．１３）
【分割の表示】特願２００３−４１７０１（Ｐ２００３−４１７０１）の分割
【原出願日】平成１５年２月１９日（２００３．２．１９）
【出願人】（０００００２３６９）セイコーエプソン株式会社 (51,324)
【出願人】（５０１３９６０２６）イーライド，インク． (10)
【氏名又は名称原語表記】ｅＲｉｄｅ，Ｉｎｃ．
【住所又は居所原語表記】Ｏｎｅ Ｌｅｔｔｅｒｍａｎ Ｄｒｉｖｅ，Ｂｌｄｇ．Ｃ，Ｓｕｉｔｅ ３１０ Ｔｈｅ Ｐｒｅｓｉｄｉｏ ｏｆ Ｓａｎ Ｆｒａｎｃｉｓｃｏ Ｓａｎ Ｆｒａｎｃｉｓｃｏ，ＣＡ ＵＳＡ
【Ｆターム（参考）】
[ Back to top ]