JP2003315436A - 高感度化及び低頻度使用のサーバー - Google Patents

Abstract

(57)【要約】 【課題】 サーバの高感度低頻度使用 【解決手段】 ナビゲーション衛星受信機は、初期化に
必要となるキー情報を時折提供するためにネットワーク
サーバに依存する。ナビゲーション衛星受信機はその位
置の不確定さsigmaPosを１５０ｋｍ以下に保つことが重
要である。従って、少なくとも５分置きに、ナビゲーシ
ョン衛星受信機はネットワーク接続を用いて作動中のＧ
ＰＳ衛星全ての全軌道暦情報をダウンロードする。パワ
ーオフ時間の不確定さsigmaTimeは、ソフトウェア補償
型水晶発振器を基準とするリアルタイムクロックを走行
させることにより１ミリ秒以下に保たれる。受信機の信
号レベルが最強のＧＰＳ衛星の場合でも−１５０ｋｍ以
下になったとき最初の測位を生じるのに必要な時間を減
らすためにそうした情報がパワーアップ時に即時利用可
能となる。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明はナビゲーション衛星
受信機に関し、より具体的には、コンピュータネットワ
ークで普通は完全に自律型のクライアントを、必要に応
じサポートするための方法並びにシステムに関する発明
である。

【０００２】

【従来の技術】全地球測位システム（ＧＰＳ）は、米国
防省が１３兆億ドル以上をかけて構築し運営している、
衛星をベースにした無線ナビゲーションシステムであ
る。２４機の衛星が高度２０,２００kmで地球を周回
し、６つの衛星で構成される最小衛星群がどのユーザに
いつでも見えるような間隔で軌道に配置されている。各
衛星は、原子時計を基準にした正確な時刻及び位置の信
号を送信する。典型的なＧＰＳ受信機はこの原子時計を
先ず捕捉して、その後、到着する信号の時間遅延を非常
に正確に測定することで、受信機と衛星間の距離が算出
される。少なくとも４つの衛星からの測定値により、Ｇ
ＰＳ受信機はその位置、速度、高度、時刻を算出するこ
とができる。

【０００３】高感度ＧＰＳ受信機は、初期の時刻又は周
波数の不確定性が大きいと問題になる。信号のエネルギ
ーが極めて弱いときにその信号のエネルギーを見つける
には、ステップを小さくして各ステップにより長い時間
留まっていなければならない。そのために、ローカルの
基準発振器の初期推定値が優れているとそれだけ初期定
点化時間（電源投入から最初の位置測位までの時間（Ｔ
ＴＦＦ））が短くなる。

【０００４】−１４５ｄｂｍ以上の信号レベルを有する
ＧＰＳ受信機は、強いＧＰＳ衛星（ＳＶ）を容易に捕捉
してナビゲーション（ＮＡＶ）データを解読することが
できる。そうしてＧＰＳ衛星の軌道暦及び位置を得る。
その後、ハードウェアのコード位相から全擬似距離を形
成しなければならない。従来のＧＰＳ受信機は整数ミリ
秒及びいわゆるＺカウントを判定する。

【０００５】大まかに言って信号レベルが−１４５ｄｂ
ｍから−１５０ｄｂｍよりも低い時に、実用的な高感度
ＧＰＳ受信機ではエニウェア測位（anywhere fix）を行
なうためにパターンマッチングを工夫してＺカウント又
は整数ミリ秒を得ることができる。

【０００６】

【特許文献１】米国特許第５,781,156号

【０００７】

【発明が解決しようとする課題】そこで、本発明の目的
は−１５０ｄｂｍ以下の信号レベルで動作することがで
きる高感度ＧＰＳ受信機を提供することである。

【０００８】

【課題を解決するための手段】簡単に言えば、本発明に
おけるナビゲーション衛星受信機の実施例は、初期化の
ときに必要なキーとなる情報を時折提供するネットワー
クサーバに依存している。ナビゲーション衛星受信機は
その位置の不確定性sigmaPosを１５０ｋｍ以下に維持す
ることが非常に重要である。従って、少なくとも５分置
きに、ナビゲーション衛星受信機は動作しているＧＰＳ
衛星の全ての軌道暦情報をネットワーク接続を用いてダ
ウンロードしている。パワーオフ時間の不確定性sigmaT
imeは、ソフトウェア補償型水晶発振器基準値でリアル
タイムクロックを走行させることにより１ミリ秒以下に
保たれる。そうした情報はパワーアップ時直ちに利用し
て、受信機の信号レベルが、最も強力なＧＰＳ衛星−１
５０ｄｂｍ以下のとき初期フィックスするのに必要な時
間を短縮することができる。

【０００９】

【発明の実施の形態】図１に、本発明の実施例における
ネットワークサーバ１００を示す。ネットワークサーバ
１００は、サーバシステム１０２と、ＧＰＳ測定プラッ
トフォーム１０４、及びインターネットなど介在型コン
ピュータネットワーク１０６を備える。サーバシステム
１０２はナビゲーション衛星受信機を備え、ナビゲーシ
ョン衛星受信機はナビゲーションＧＰＳ衛星（ＳＶ）１
０８、１１０、１１２からなる衛星群を捕捉して追跡し
ている。これらの衛星の中にはＧＰＳプラットフォーム
１０４から捉えられるのもある。ナビゲーション衛星１
１４、１１６を含む他のナビゲーション衛星群はクライ
アントシステム１０４から捉えられる。クライアントシ
ステム１０４は、ナビゲーション衛星受信機を自分で持
っているが、その受信機はナビゲーション衛星１１２、
１１４、１１６の衛星群をまだ捕捉することができてな
く、追跡していないかもしれない。

【００１０】概して言えば、本発明では４つのタイプの
ＧＰＳ測定プラットフォームの実施例がある。それら
は、サーバとどれだけ独立で動作できるかによって分類
される。自律型クライアントは、例えば、ディファレン
シャル補正データなどサーバから最小限度の支援だけで
機能し、ナビゲーション解を提供することができる。デ
ミクライアントは、例えば、軌道暦及び時間のバイアス
計算を簡単にする多項式モデルなどもう少し支援を必要
とする。シンクライアントは、ほとんど全てのナビゲー
ション計算をサーバ１０６に頼り、基本的にＧＰＳ衛星
群に対する自分の視点からの観察測定値を提供するだけ
である。ユーザがそこにいてナビゲーション解を見たけ
れば、ローカル表示できるように解が返送される。

【００１１】第４のタイプのクライアントはクライアン
ト１０４として接続された高感度ＧＰＳ受信機である
が、本明細書ではＯＭＮＩと称する。そうした第４のタ
イプが本願の対象である。

【００１２】図２に、本発明のＯＭＮＩクライアントナ
ビゲーション衛星受信機ネットワークの実施例を示す。
また、本明細書で、参照番号２００はＯＭＮＩクライア
ントナビゲーション衛星受信機ネットワークを指す。Ｏ
ＭＮＩクライアントナビゲーション衛星受信機ネットワ
ークは、ネットワークサーバ２０４によってサポートさ
れた少なくとも一つのナビゲーションプラットフォーム
２０２を備える。

【００１３】ＧＰＳ測定プラットフォーム２０２はそれ
ぞれ、ＧＰＳアンテナ２０６と、低雑音増幅器（ＬＮ
Ａ）２０８、ＧＰＳ弾性表面波（ＳＡＷ）フィルタ２１
０、中間周波数（ＩＦ）ＳＡＷフィルタ２１４を有する
無線周波数（ＲＦ）用専用集積回路（ＡＳＩＣ）２１
２、ディジタル信号処理プロセッサ（ＤＳＰ）２１６、
基準水晶２１８、及び基準水晶温度センサ２２０を備え
るのが一般的である。

【００１４】自律型クライアント２２２は、サーバ２０
４からのほんのわずかな支援だけで機能し、ユーザにナ
ビゲーション解を提供することができる。デミクライア
ント２２４は、軌道暦及び時間のバイアス計算を簡単に
する多項式モデルなどの支援を必要とする。シンクライ
アント２２６は、ナビゲーション解の処理の負担をロー
カルのホストにかけない。ほとんど全てのナビゲーショ
ン計算をサーバ２０４に頼り、基本的に自分の視点から
のＧＰＳ衛星群の観察測定を行なうだけである。ユーザ
がそこにいてナビゲーション解を見たければ、ローカル
で表示するためにナビゲーション解が返送される。シン
クライアント２２６において、ＤＳＰは何か他の非ＧＰ
Ｓアプリケーションとの共有部分である。そのために、
クライアントではマルチスレッド型のアプリケーション
プログラムは不要で、単純なプログラムループだけが実
行される。

【００１５】ＯＭＮＩクライアント２２７はほぼ完全自
律で動作するが、コンピュータネットワークを介して軌
道暦の完全セットを定期的に収集する。ＯＭＮＩクライ
アント２２７は、パワーオフ時にも動作し、電源が再投
入されたときに位置の不確定性sigmaPosを１５０ｋｍ以
下に保つ。このような条件が高感度オペレーションを可
能にし、高感度オペレーションでは信号パワーを見出す
のにはるかに微細な探索ステップを用い、ステップ毎に
留まる時間（dwell）が長い。また、ＯＭＮＩクライア
ント２２７は、水晶発振器２１８が温度センサ２２０の
温度測定を使用するソフトウェア補償型である場合は、
大きく恩恵を受ける。リアルタイムクロックは、ナビゲ
ーションプラットフォーム２０２がパワーアップされる
毎に真の時刻の１ミリ秒より優れた精度で走行し続け
る。

【００１６】ローカル基準発振器の水晶２１８は、温度
の関数として変化する周波数ドリフト誤差を有する。基
準水晶温度センサ２２０は、ローカル基準発振器水晶２
１８の温度を測定する。ナビゲーションプラットフォー
ム２０２が初期化されてＧＰＳ衛星を追跡しているとき
に、データを集めて製造時の校正曲線を構築するために
先ず使用される。次に、ナビゲーションプラットフォー
ム２０２が初期化しながら最初のＧＰＳ衛星を捕捉しよ
うとする間に、保持された係数から９次の多項式を計算
できるように指針を提供するために使用される。

【００１７】サーバ２０４は、通常、ＧＰＳ信号を基準
局マネージャ２３２に入力する多数の基準局アンテナ２
２８、２３０を備える。ロケーションサーバ２３４は、
初期定点化時間（ＴＴＦＦ）と位置解の質が向上するよ
うに、デミクライアント２２４、シンクライアント２２
６、ＯＭＮＩクライアント２２７にサポート情報を提供
することができる。高感度モードで動作するＯＭＮＩク
ライアント２２７の場合は、サーバ２０４が収集して転
送した軌道暦情報によってＧＰＳ衛星からの信号レベル
が−１５０ｄｂｍ以下でもエニウェア測位（anywhere f
ix）が可能になる。

【００１８】本発明における方法の実施例では、いつ、
どのようにしてサーバ２０４にＯＭＮＩクライアント、
例えば、クライアント１０４及びナビゲーションプラッ
トフォーム２０２が接続するかを判定する。バイトあた
りの通信費用が高い場合や、ネットワークが周期的にし
かアクセスできない場合は、サーバへの接続は頻度を低
くし、多くの場合最低限度にしなければならない。

【００１９】信号強度が高いときには、ＮＡＶデータを
収集することによってＺカウント及びＢＴＴが実際に測
定される。ＢＴＴはコード位相のロールオーバをクリー
ンアップするのに用いられる。概して、２０ミリ秒以下
（sub-20msec）の部分は一致するべきである。Ｚカウン
トよりもＢＴＴのほうが少しだけ雑音が多い。しかし、
Ｚカウントはコード位相がロールオーバする付近の短時
間に１ミリ秒ずれる可能性がある。

【００２０】ＯＭＮＩクライアントは、sigmaTimeを１
ミリ秒以下に抑えるために優れた時間ソースを必要とす
る。パターンマッチを行なって間接的に時刻を見出すの
に５０ＨｚのＮＡＶデータを用いることができる。それ
は、Ｚカウントを復調できないとき、十分にＧＰＳ受信
機の時間ソースとなる。パターンマッチに十分な信頼度
があれば、ＧＰＳ衛星に対する整数ミリ秒intMsを判定
することもできる。

【００２１】開始時刻の不確定性sigmaTimeが＋／−１
０ミリ秒よりも大きい場合は、ソリューションフィック
スにいわゆる大デルタＴ項（ＤＴ）を使用しなければな
らない。そうすると、必要なＧＰＳ衛星の数が一つ増え
る。位置の不確定性sigmaPosが１５０ｋｍ以下で且つＧ
ＰＳ衛星のintMsを利用できないときには、gridFix方法
を活用することができる。sigmaTimeが１０ミリ秒以上
のときは非Ｚ測位タイプを採用することができる。

【００２２】全ＧＰＳ衛星の衛星暦よりもむしろサーバ
から完全なＧＰＳ衛星暦highAccAlmが軌道暦と共に送ら
れる。もう一つの完全なＧＰＳ衛星暦mixAccAlmをサー
バから送ることができ、それにはいま追跡していないＧ
ＰＳ衛星の古い軌道暦が含まれている。

【００２３】完全なＧＰＳ衛星群を連続観測する能力を
有するWWserverサーバが実現されるのが好ましい。同じ
時刻に世界中で全てのＧＰＳ衛星を見ることができる程
度に空間的に離れた十分な数の基準局がある。サーバ２
０４は、ローカルサーバLAserverを表わしている。ロー
カルサーバは完全なＧＰＳ衛星群の部分集合しか観測し
ない一つ以上の基準局を有する。従って、LAserverはhi
ghAccAlmを提供することはできず、mixAccAlmしか提供
できない。

【００２４】電源投入後、衛星暦は実際は衛星暦である
軌道暦を含んでいる。１２時間サイクルが一回終わる
と、衛星暦の中のいくつかは軌道暦に基づいた衛星暦で
置き換えられる。

【００２５】ＧＰＳ衛星からのＮＡＶデータを−１４５
ｄｂｍの低信号レベルまで直接収集することができる。
従って、軌道暦、Ｚカウント、ＢＴＴをこのレベルで導
出することができる。このレベルのＧＰＳ衛星はサーバ
とは独立で動作することができるし、開始位置の精度を
問わない測位、例えば、エニウェア（anywhere）測位に
使用することもできる。−１４５ｄｂｍからパターンマ
ッチングが必要になり、低いところで−１５０ｄｂｍま
で続行することができる。それにより、Ｚカウント又は
intMsを得ることができるので、ＧＰＳ衛星をエニウェ
ア測位に使用できる。しかしながら、そうした信号レベ
ルでは、サーバ１０２か又は他のソースからネットワー
ク１０６で軌道暦を得なければならない。信号レベルが
−１５０ｄｂｍ以下になると、ＮＡＶデータはパターン
マッチに使用できるほどの信頼度がない。ＮＡＶデータ
をサーバ１０２又は２０４から得なければならないし、
そうした弱い信号を有するＧＰＳ衛星は、不確定性が１
５０ｋｍ以下のときしか測位に加担できない。

【００２６】ＧＰＳ衛星の初期捕捉中、軌道暦レベルは
正確でなくてもいい。プレポジションに必要なデータを
予測するには衛星暦、もしくはダウングレードされた軌
道暦で十分である。測位するために軌道暦レベルの精度
は要らない。測位のために軌道暦エージ（age）のタイ
ムアウトが定義される。そうしたしきい値を緩和して
も、時間の関数として精度の劣化が正しくモデル化され
ていればかなりの精度の測位を維持することができる。
エージ（age）のしきい値は制御可能なパラメータだか
ら、顧客は望ましい性能レベルを選択することができ
る。

【００２７】初期測位又は設定時刻にはサーバ１０２か
らのＮＡＶデータのサブフレームデータが必要である。
その後、クライアント１０４はsubFrameを二度と要求し
ない。クライアント１０４が解読したＮＡＶデータはサ
ーバがパターンマッチングを行なえるようにサーバ１０
２に送られる。

【００２８】ＧＰＳ衛星が３つ以上あり、その全てが−
１４５ｄｂｍよりも良好な信号レベルを有するときに
は、ＯＭＮＩクライアント１０４はサーバ接続不要であ
る。軌道暦を収集しなければならない場合には初期定点
化時間（電源投入から最初の測位までの時間）（ＴＴＦ
Ｆ）が長くなる。場合によっては、前に収集した軌道暦
を使用することができる。

【００２９】ＧＰＳ衛星の前に収集した軌道暦が手元に
あってsigmaPosが１５０ｋｍ以下のときには、ＯＭＮＩ
クライアント１０４はサーバ接続不要である。必要な最
低限度のＧＰＳ衛星の数はsigmaTimeによって決まる。
そうした時刻の不確定性は、温度ドリフトをソフトウェ
ア補償することのできるリアルタイムクロック（ＲＴ
Ｃ）によって抑えることができる。そのために、ＲＴＣ
を用いる場合は３つのＧＰＳ衛星が、ＲＴＣを用いない
場合には４つのＧＰＳ衛星が必要である。

【００３０】さもなければ、測位の解を見出すのにＯＭ
ＮＩクライアント１０４はサーバ１０２に接続して特定
の情報を要求しなければならない。ＧＰＳ衛星の信号が
−１４５ｄｂｍから−１５０ｄｂｍで且つsigmaPos >
１５０ｋｍの場合、ＮＡＶデータサブフレームが必要で
ある。これらのＧＰＳ衛星が初期測位に加担するにはそ
のintMsが必要となる。−１４５ｄｂｍ以下のＧＰＳ衛
星が３つしか利用できなくて、しかも正確な時刻のいい
手立てが他にない場合には、パターンマッチングを採用
することができる。そのときは、４つのＧＰＳ衛星によ
るいわゆる非Ｚ−カウント測位（n-z fix）を用いる。

【００３１】ＧＰＳ信号が−１４５ｄｂｍ以下でしかも
その軌道暦にタイムアウトがあると、軌道暦を要求しな
ければならない。そうした場合、可能な限り最高速のＴ
ＴＦＦが望ましい。

【００３２】主のプログラムアプリケーションがＧＰＳ
受信機を周期的にオンにして測位を得る。そのようにし
て、受信機が最後の測位からどれだけ遠くに移動してい
るかを判定し、或いは単にＧＰＳ受信機が予め定められ
たゾーンを出たかどうかを決定する。sigmaPosを１５０
ｋｍ以内に保つように測位間の時間間隔が選択されるの
で、−１４５ｄｂｍ以下の弱いＧＰＳ衛星ではintMsは
要らない。そうすることにより、サーバ接続してＮＡＶ
データsubFrameを要求しなくても高感度測位を保持する
能力が延びる。サーバ要求のタイミングは適応性があ
る。これは変動の少ないクライアント／サーバ接続なし
に変動の少ないクライアント／サーバ接続を十分な性能
があるときに実現するのに必要である。

【００３３】ＯＭＮＩクライアントは手持ちのデータ、
そのデータのエージ（age）、及び捕捉成功の可能性
（例えば、ＧＰＳ衛星の数及び信号レベル）を評価しな
ければならない。ＯＭＮＩクライアントは次に、接続す
べきかどうか、またどのデータを要求すべきかを決定す
る。適応性をディセーブルにすることができるし、コマ
ンドを出すことによってサーバ接続を行なうことができ
る。マスタアプリケーションは一時間置きにサーバ接続
するように決定するかもしれない。従って、５分置きに
行なわれる測位では、１２番目の測位でサーバ接続が行
なわれる。

【００３４】放送形軌道暦サービスを使用することがで
きる。放送形軌道暦サービスではマスタアプリケーショ
ンが先ずデータを収集してそれを汎用のＡＰＩでクライ
アントに送り出す。クライアントはセッション中いつで
もサーバ接続することができる。

【００３５】図３に、いくつかのステップを有するＯＭ
ＮＩクライアントの方法の実施例を示す。本明細書では
参照番号３００でこの方法を示す。先ず、ステップ３０
２で、軌道暦が利用可能かどうか分析し、測位に使用可
能な軌道暦を有するhigh-NのＧＰＳ衛星がいくつあるか
判定される。そこから、サーバの衛星暦ServerAlmがhig
h-Nを十分に得ることができ且つ正確なprePosになる程
度のものであると仮定する。

【００３６】ステップ３０４で、ＧＰＳ衛星は、受信し
た信号の強さによって「Ｇ１」（−１４５ｄｂｍ以
上）、「Ｇ２］（−１４５ｄｂｍから−１５０ｄｂｍの
範囲）、又は「Ｇ３］（−１５０ｄｂｍ以下）に分類さ
れる。

【００３７】ステップ３０６で、捕捉したＧＰＳ衛星数
を数え、sigmaTime及びsigmaPosを用いて測位が可能か
どうかの判定を行なう。

【００３８】ステップ３０８で、信号のレベルと、sigm
aTime、及びsimgaPosに基づいてＮＡＶデータサブフレ
ームを必要とするＧＰＳ衛星数を数える。初期測位を得
るのにこれらのＧＰＳ衛星が必要かどうか。

【００３９】ステップ３１０で、サーバ接続を要求する
かどうかの決定が行なわれる。要求しない場合には、ス
テップ３１２が実行される。サーバ接続が必要な場合に
は、ネットワークのデータトラフィックを最小限にす
る、及び無制限にするという２つの選択がある。

【００４０】ステップ３１４でサーバに最小限のデータ
を要求する。例えば、手元にある軌道暦が新しいもので
この先もまだしばらく使用できる場合は、今のセッショ
ンで軌道暦を求めるサーバ要求は不要である。

【００４１】ステップ３１６でサーバに最大限のデータ
を要求する。しかしながら、普通、極力はるか先まで使
用できる、できるだけ多量のデータを要求する。そうす
るのは、サーバ接続数を最低限度の抑えなければならな
い場合には、妥当なことである。しかし、一旦サーバセ
ッションに入ってしまえば、極力多量のデータを要求す
ることができる。

【００４２】ステップ３１８で測位の計算が行なわれ
る。

【００４３】本発明の実施例の中には、クライアント対
サーバのハンドシェイクを制御可能及び選択可能にする
例がある。（ａ）軌道暦の年齢と今のhigh-NにあるＧＰ
Ｓ衛星の中にタイムアウトしたものがあるか、（ｂ）Ｇ
ＰＳ衛星の追跡をＧ１，Ｇ２，Ｇ３に分類とＧＰＳ衛星
ごとにサブフレームが必要かどうか、（ｃ）sigmaTime
及びsigmaPos、を示すステータスメッセージがマスタア
プリケーションに送られる。

【００４４】追跡しているＧＰＳ衛星の軌道暦を利用で
きる限り屋内の高感度動作を維持することができるの
で、位置の不確定性は１５０ｋｍ以下となり、Ｚカウン
トなしに測位を得ることができる。非Ｚカウント（no-z
count）方法ではＧＰＳ衛星の数が一つ増えるので、リ
アルタイムクロック（ＲＴＣ）など正確な時間ソースが
好ましい。例えば、３次元測位では５つのＧＰＳ衛星、
２次元測位では４つのＧＰＳ衛星。普通では５０ｂｐｓ
のＧＰＳナビゲーションデータストリームを復調するに
は弱すぎる信号測定値を用いて位置測位を計算すること
ができる。

【００４５】妥当な初期定点化時間（電源投入から最初
の測位までの時間）（ＴＴＦＦ）にするにはソフトウェ
ア補償型水晶発振器（ＳＣＸＯ）を備えるべきである。
ＴＴＦＦがさほど重要でない場合には、周波数探索の時
間帯を延長して大きな周波数エラーを見つけ出すことが
できる。信号が受信機でデータを信頼性の問題なく復調
できる程度の強さを有する場合には、位置の範囲は１５
０ｋｍを超えて拡がることが可能である。

【００４６】ＲＴＣは、クライアントアプリケーション
が動作していないときでも、前の測位からミリ秒レベル
の精度を得ることができる。スリープモードの電力消費
がわずかにコストアップになるだけである。

【００４７】本発明の実施例では、信号が十分に強けれ
ば、ナビゲーションデータを個別に復調することができ
る。そうすることは、今のＳＴＩ又はグローバルロケー
ト設計では従来の追尾機能を追加しない限り、可能では
ない。

【００４８】サーバを使用しない場合、高感度位置フィ
ックスは屋外のような信号を最近（例えば、ここ４時間
以内）観測した場合に限って実現することができる。な
ぜならば、可視衛星が常に変わり、前のＧＰＳ衛星の軌
道からの軌道暦の精度が低下するからである。軌道毎の
劣化レベルは重要な問題である。衛星クロックの軌道だ
けでなく宇宙船の軌道も正確にモデル化されなければな
らない。今までのモデリングの中には軌道暦の使用可能
性を１２〜１６時間の範囲に延長することができるもの
があった。そうすると、性能がいくぶん向上するが、フ
ィックスの精度は相変わらず予測困難である。

【００４９】従来の高感度受信機は常時サーバに接続し
ていることが必要であった。これらの方法では、ネット
ワークから周波数を導出し、そのハードウェアには軌道
暦を収集することはできない。そうした絶え間ないなサ
ーバ通信は維持するのにコストがかかる。

【００５０】実際問題として、サーバから時々支援を受
けることなく常時高感度ＧＰＳナビゲーションを維持す
るのは非常に困難である。サーバはこれより先の軌道暦
と、時間ソースとしてパターンマッチング用のサブフレ
ームを提供する。従って、いくらかの電力消費を節約す
るために測位と測位との間にＲＴＣを使用しないことは
可能かもしれないが、電力の節約は比較的小さい。最後
の測位から時間が数日たっている場合、ＲＴＣの精度が
劣化し始める可能性があるので、別の時間ソースとして
サブフレームが必要となる。

【００５１】ＧＰＳ受信機がその使用可能なデータを問
い合わせする場合、サーバの更新と更新の間の時間を最
小限に抑えることができる。次の場合に限ってサーバに
対して呼び出しが行なわれる：軌道暦データの有効期限
が過ぎている場合、信号が弱い場合、最後の測位からの
経過時間がリミットを過ぎている場合。ＧＰＳ受信機が
強いＧＰＳ衛星を追跡している場合、軌道暦を収集して
測位計算できるかどうか確認するためにサーバ呼び出し
は延期される。

【００５２】ＮＡＶデータを収集することによってＺカ
ウント及びＢＴＴが測定される。ＯＭＮＩクライアント
はコード位相のロールオーバをクリーンアップするのに
ＢＴＴを用いる。概して、２０ミリ秒以下の部分は一致
するべきである。ＢＴＴにはＺカウントよりもわずかに
雑音が多い。しかしながら、Ｚカウントは、コード位相
がロールオーバする付近の短い時間に１ミリ秒ずれるす
る可能性がある。

【００５３】パターンマッチには５０ＨｚでのＮＡＶデ
ータサブフレームが必要となる。それは、ＯＭＮＩクラ
イアントがＺカウントを復調することができないとき受
信機の時間ソースとなる。パターンマッチを十分に信頼
できる場合は、ＧＰＳ衛星に対して整数ミリ秒を提供す
ることも潜在的に可能である。ＯＭＮＩクライアント
は、この信頼性をもたらすパターンマッチの条件を定義
しなければならない。

【００５４】整数ミリ秒（intMs）は、Ｚカウントを復
調する、或いは信頼度の高いパターンマッチ、のどちら
かによってＯＭＮＩクライアントによって導出される。
sigmaPosは開始位置の不確定性である。sigmaTimeは開
始時刻の不確定性である。＋／−１０ミリ秒より大きい
とき、ＯＭＮＩクライアントはフィックスに大デルタＴ
項（ＤＴ）を含まなければならない。それにより、必要
なＧＰＳ衛星の数が一つだけを増える。gridFix cance
l b：sigmaPosが１５０ｋｍより小さく、ＯＭＮＩクラ
イアントがＧＰＳ衛星に対してintMsを有していないと
きに用いられる測位方法。 no-Z fix：これはsigmaTimeが１０ミリ秒より大きいと
きの測位タイプである。ＯＭＮＩクライアントは測位の
中で大デルタ項（ＤＴ）を解く。 highAccAlm：これはサーバから送られる完全なＧＰＳ衛
星暦だが、全てのＧＰＳ衛星に関する衛星暦よりむしろ
軌道暦を有する。 mixAccAlm：これはサーバから送られる完全なＧＰＳ衛
星暦で、いま追跡していないＧＰＳ衛星に関する古い軌
道暦を有する。 WWserver：これは、同時に全てのＧＰＳ衛星を見ること
ができるくらいに空間的に離れた十分な数の基準局を有
しているので、完全なＧＰＳ衛星群の連続観測可能性を
有するサーバである。 LAserver：これは、完全なＧＰＳ衛星群の部分集合だけ
を観測することができる一つ以上の基準局を有するロー
カルサーバである。LAserverはhighAccAlmを処理するこ
とはできない。mixAccAlmしか処理できない。電源投入
後、衛星暦は軌道暦を有する衛星暦と、実際の衛星暦と
を含む。１２時間サイクルが一回終わると、衛星暦の中
には軌道暦をベースにした衛星暦で置き換えられるもの
がある。 ServerAlm：これは、完全な衛星暦で、ＯＭＮＩクライ
アントがWWserverを有するかLAserverを有するかによっ
てhighAccAlmか又はmixAccAlmのどちらかになる。 ダウングレードされた軌道暦：軌道暦Ｔｏｅ（軌道暦時
間time of ephemeris）に対して或る所定のエージ（ag
e）以降、ＯＭＮＩクライアントは軌道暦のサインカー
ブ項を無視し、衛星暦の精度を衛星暦の有効精度までモ
ードを落とす。

【００５５】捕捉には、ＯＭＮＩクライアントは軌道暦
レベルの精度は要らない。プレポジションに必要なデー
タを予測するには衛星暦（もしくはダウングレードされ
た軌道暦）で十分である。

【００５６】測位には、ＯＭＮＩクライアントは軌道暦
レベルの精度が必要である。ＯＭＮＩクライアントは測
位のための軌道暦のエージ（age）のタイムアウトを現
時点で定義する。ＯＭＮＩクライアントが時間の関数と
して精度の質の低下を正しくモデル化できれば、ＯＭＮ
Ｉクライアントはこのしきい値を緩和しても相変わらず
かなりの精度の測位を維持することができる。顧客が望
ましい性能レベルを選択することができるように、ＯＭ
ＮＩクライアントはエージ（age）しきい値を制御可能
なパラメータにすることもできる。

【００５７】最初の測位又は設定時間の場合、パターン
マッチをするために、サーバからのサブフレームデータ
が必要になることがある。しかしながら、その時点以
降、ＯＭＮＩクライアントはsubFrameを要求し続けなく
ていい。

【００５８】ＯＭＮＩクライアントは、復号化されたＮ
ＡＶデータをサーバに送ることを考え、サーバにパター
ンマッチをさせてその結果を返送させることを考えるべ
きである。そうするとデータがはるかに少なくなる。Ｏ
ＭＮＩクライアントは、デミクライアントのためにもサ
ーバのプロジェクトとしてこの作業を予定するよう要求
すべきである。ＯＭＮＩクライアントはまた、融通がき
くように両方のアプローチを保持すべきである。

【００５９】上記の条件が満たされない場合には、ＯＭ
ＮＩクライアントは測位を得るためにサーバに接続しな
ければならない。ＯＭＮＩクライアントは、その後、要
求しなければならないデータは何かを定義する。

【００６０】マスタアプリケーションは、受信機の電源
を投入して測位を得るのを周期的に決定することができ
る。概して、マスタアプリケーションは、最後の測位か
ら受信機がどれだけ遠くに移動したか、或いは所定のゾ
ーン外にでたかどうかを決定しようとする。

【００６１】ＯＭＮＩクライアントが弱いＧＰＳ衛星
（Ｇ２，Ｇ３）に対してintMsを必要としないように測
位と測位との間の時間間隔はsigmaPosを１５０ｋｍの範
囲内に保つように選択される。そうすると、subFrames
を要求するサーバ接続をしなくても高感度測位を保持す
る能力を延長することができる。

【００６２】サーバリクエストを適応型にする。これ
は、変動の少ないクライアント／サーバ接続なしに変動
の少ないクライアント／サーバ接続を十分な性能がある
ときに実現するのに必要である。それはすなわち、クラ
イアントは、手持ちのデータ、データのエージ（ag
e）、及び捕捉成功（ＧＰＳ衛星数及び信号レベル）を
評価しなければならないということである。このデータ
に基づいて、次に、接続を実行するかどうか、また、ど
のデータを要求するかの決定が行なわれる。

【００６３】適応性をディセーブルにして、コマンドを
出すことによってサーバ接続を行なうようにすることが
できる。マスタアプリケーションは一時間置きにサーバ
接続を行なうように決めることができる。従って、ＯＭ
ＮＩクライアントは５分置きに測位を行なうことができ
るので、１２番目の測位でサーバ接続が行なわれる。

【００６４】ＯＭＮＩクライアントは放送形軌道暦サー
ビスを実行することができる。放送形軌道暦サービスで
はマスタアプリケーションがデータを先ず収集して、そ
のデータを汎用のＡＰＩでクライアントに送り出す。

【００６５】ＯＭＮＩクライアントはまた、セッション
中いつでもサーバ接続するようにすることもできる。

【００６６】位置のシグマが１５０ｋｍ以上に大きくな
った場合、整数ミリ秒を計算するのにパターンマッチン
グを用いることができる。ＯＭＮＩクライアントは、整
数ミリ秒を計算するために、次のデータをアルゴリズム
の中に組み入れる。パターンマッチのオフセットは、復
調後のデータビットをサーバから供給されたサブフレー
ムデータと相関するのに間に合った探索の結果である。
ＯＭＮＩクライアントは、推定量の中で繰り返し出てく
る結果を用いる。ＯＭＮＩクライアントがパターンマッ
チを得るたびにパターンマッチ良好ビットカウントが出
てくる。ＯＭＮＩクライアントはいくつのビットが一致
したか調べることができる。ＯＭＮＩクライアントは各
パターンマッチの信頼度に加重値を与えるのにこれを用
いる。ＯＭＮＩクライアントは、次に、総体的な推定を
行なうためにこの結果を組み合わせる。

【００６７】ＢＴＴの結果及びＢＴＴステータスはＴＳ
Ｍヒストグラムから形成される。ＢＴＴは整数ミリ秒の
中の２０ミリ秒以下の部分の推定値である。これは、パ
ターンマッチを用いて計算されたintMSをフィルタ処理
するために或いは独立検証子として用いることができ
る。ＯＭＮＩクライアントは、ロールオーバを探すため
にコード位相をモニタすることができる。整数ミリ秒が
１ミリ秒変わるのを可能にするためにＯＭＮＩクライア
ントはこれが要る。ＯＭＮＩクライアントは整数ミリ秒
の変化の方向を検証するのにドップラーを用いることが
できる。

【００６８】ＯＭＮＩクライアントは、sigmaPos ＞１
５０ｋｍのとき、次の戦略をとる。

【００６９】ＯＭＮＩクライアントは先ず最初に、Ｚカ
ウントを測定できる軌道暦を有する強いＧＰＳ衛星を十
分な数有しているかどうか調べる。ＯＭＮＩクライアン
トはこれを−１４５まで行なうことができる。ＯＭＮＩ
クライアントがこれらのＧＰＳ衛星を十分に有していれ
ば、そのＯＭＮＩクライアントはサーバリクエストを行
なわない。

【００７０】ＯＭＮＩクライアントが強いＧＰＳ衛星
（−１４５ｄｂｍ以上）を十分な数有しておらず且つそ
のＯＭＮＩクライアントがより弱いＧＰＳ衛星を追跡し
ている場合には、パターンマッチング方法がＯＭＮＩク
ライアントがintMsを計算するのに使える唯一の方法だ
から、ＯＭＮＩクライアントはサーバリクエストを行な
わなければならない。ＯＭＮＩクライアントはsigmaPos
が１５０ｋｍ以下のとき次の戦略をとる。

【００７１】ＯＭＮＩクライアントが本発明の時間ソー
スに基づいてＧＰＳ衛星を十分な数有し、しかもその軌
道暦が新しければ、ＯＭＮＩクライアントはサーバリク
エストを行なわない。

【００７２】ＯＭＮＩクライアントが強いＧＰＳ衛星を
有して軌道暦を収集することができる場合には、そのＯ
ＭＮＩクライアントはサーバリクエストをしない。そう
するとＴＴＦＦをスローダウンさせることになる。従っ
て、ＯＭＮＩクライアントはこれをオーバライドして、
ＴＴＦＦのスピードアップを図るためいつでも軌道暦を
要求することができる。

【００７３】ＯＭＮＩクライアントは先ず最初に最小間
隔（OMNIminRequestInterval）を定義するので、ＯＭＮ
Ｉクライアントはこの期間よりも速くデータを要求する
ことはない。これは同じセッションについてだけ言え
る。セッション間のリクエストを制限するには周期的な
測位スレートを用いるべきである。

【００７４】ＯＭＮＩクライアントは、自分が追跡して
いるＧＰＳ衛星のステータスを判定する。ＯＭＮＩクラ
イアントは新しい軌道暦を有するＧＰＳ衛星及び有して
いないＧＰＳ衛星の数を数える。ＯＭＮＩクライアント
はまた、そのＧＰＳ衛星が良好なＮＡＶデータを収集で
きる程度に強い信号を有しているかどうかに基づいて数
を数える。

【００７５】ＯＭＮＩクライアントは、ＲＴＣが新しい
か否かを判定する。ＲＴＣが新しく且つsigmaPosが１５
０ｋｍ以下の場合には、ＯＭＮＩクライアントが測位に
必要とするＧＰＳ衛星数が減る。

【００７６】ＯＭＮＩクライアントは、ＯＭＮＩにとっ
て２次元測位でいいかどうか調べる。そのように構成さ
れている場合には、ＯＭＮＩクライアントは自分が必要
とするＧＰＳ衛星数を減らし、サーバトラフィックを最
低限に抑えることが可能である。しかしながら、顧客が
受信機を操作している地形により位置の精度が低下する
可能性がある。

【００７７】sigmaPosが１５０ｋｍ以下ならば、ＯＭＮ
Ｉクライアントは必要なＧＰＳ衛星数を計算する。

【００７８】軌道暦を有するＧＰＳ衛星の数が十分なら
ば、ＯＭＮＩクライアントはサーバに接続しない。

【００７９】ＯＭＮＩクライアントが強いＧＰＳ衛星を
十分な数有している場合には、ＯＭＮＩクライアントは
データを収集するのを待ち、サーバに接続しない。より
高速なＴＴＦＦが要求される場合には、noServerIfStro
ngビットは設定されず、ＯＭＮＩクライアントは軌道暦
を収集するのを待たないで軌道暦を要求する。

【００８０】ＯＭＮＩクライアントが使用可能なＧＰＳ
衛星を十分な数有していない場合には、ＯＭＮＩクライ
アントは、確実に探索を完了できる時間を与えられるよ
うに或る期間先ず待機する。待機した後、ＯＭＮＩクラ
イアントはロジックを続行する。

【００８１】ＯＭＮＩクライアントは、いま、サーバか
らいくらかデータをもらわなければフィックスできない
と判定している。サーバ通信により確実にＯＭＮＩクラ
イアントが測位を実行できるように、追跡しているＧＰ
Ｓ衛星が十分な数ある場合に限って、ＯＭＮＩクライア
ントはサーバと接続する。しかしながら、ＯＭＮＩクラ
イアントが１つか２つのＧＰＳ衛星しか追跡していない
場合には、サーバ接続は何の役にも立たないので、ＯＭ
ＮＩクライアントは状況が変わるまで単に待つ。

【００８２】ＯＭＮＩクライアントが追跡している新し
い軌道暦を有するＧＰＳ衛星とＯＭＮＩクライアントが
追跡しているけれど新しい軌道暦を有していないＧＰＳ
衛星との組合せで十分に測位を得ることができる場合に
は、ＯＭＮＩクライアントはサーバに接続する決定をす
る。ＯＭＮＩクライアントは次にどのデータを収集する
か決定する。

【００８３】一つのオプションは全ての軌道暦を要求こ
とである。そうすることにより今後の測位時間が最適化
されるとともに、ＯＭＮＩクライアントがすぐ後にもう
一度要求する可能性を最低限に抑えることができる。第
２のオプションは、新しくない軌道暦だけを全て、すな
わち、３２から全ての軌道暦を要求することである。そ
うするとサーバトラフィックを軽減することになるけれ
ども、新たなＧＰＳ衛星が見えるようになるとまたすぐ
にＯＭＮＩクライアントは選択しなければならないとい
うことになる可能性がある。

【００８４】第３のオプションは、新しくない、今見え
ているＧＰＳ衛星だけを要求することである。そうする
とサーバトラフィックをさらに軽減することになるけれ
ども、ＯＭＮＩクライアントはすぐにデータを要求する
ことになる。

【００８５】次に、ＯＭＮＩクライアントはサブフレー
ムデータが要るかどうかを決める。ＯＭＮＩクライアン
トは、sigmaPosが１５０ｋｍ以下のときだけ適用する次
のオプションを有する。

【００８６】ＯＭＮＩクライアントがＲＴＣを有し且つ
ＯＭＮＩクライアントはＲＴＣが良好なときにサブフレ
ームを要求しないような構成になっている場合には、Ｏ
ＭＮＩクライアントはサブフレームを要求しない。それ
をsubframeRequestConfigのビットnosubframeWithFresh
RTCを用いて選択する。ＯＭＮＩクライアントが強いＧ
ＰＳ衛星を有している場合には、ＯＭＮＩクライアント
がsubframeRequestConfigのビットnoSubframeWaitForZc
ountを設定すればＯＭＮＩクライアントはＺカウントを
受け取るのを待つことができる。

【００８７】ＯＭＮＩクライアントが５つのＧＰＳ衛星
を有している場合には、subframeRequestConfigのビッ
トnoZfuxInsteadOfPatternMatchが設定されていれば、
非Ｚカウント測位を強制して、サブフレームを要求しな
いことができる。

【００８８】ＯＭＮＩクライアントは、subframeReques
tConfigのビットnoSubframesEverを決してサブフレーム
を要求しないように設定することもできる。

【００８９】ＯＭＮＩクライアントは、良好な３次元測
位を有した後、この時点以降intMsを測定する必要がな
いので、決してsubFramesを要求しない。

【００９０】ＯＭＮＩクライアントがサブフレームの収
集を決めた場合には、次のオプションがある。subframe
RequestConfigの中のallHighNsubframesビットを用いて
全サブフレームに対してサブフレームを要求する。

【００９１】ビットonlyStrongestSVを用いて最強のＧ
ＰＳ衛星のサブフレームだけを要求する。sigmaPosが１
５０ｋｍ以下のときにだけそうすることは容易に分か
る。

【００９２】ビットonlyAboveThreshを用いて指定され
たＥＭＵ範囲を有するＧＰＳ衛星に対するサブフレーム
を要求する。そうすることは役立つ。というのは、ＴＴ
ＦＦのスピードアップを図るとき以外、ＯＭＮＩクライ
アントは強力なＧＰＳ衛星に対するサブフレームは要ら
ないから。そのために、ＯＭＮＩクライアントはサーバ
トラフィックを軽減することができる。

【００９３】sigmaPos ＞１５０ｋｍならば、大きな違
いはＯＭＮＩクライアントが最初のフィックスに入って
いる衛星に対する整数ミリ秒を必要とすることである。
ＯＭＮＩクライアントは、信号の強いＧＰＳ衛星のＺカ
ウントを解読するか、或いは貧弱なＧＰＳ衛星のための
専用のパターンマッチアルゴリズムか、どちらかによっ
てこれを得る。従って、貧弱なＧＰＳ衛星が多すぎる場
合には、つまり、信号の強い衛星が十分な数ない場合に
は、ＯＭＮＩクライアントはサーバと通信するしかな
い。

【００９４】ＯＭＮＩクライアントは必要なＧＰＳ衛星
数を２次元ビットfix2Dokayに基づいて計算する。ＯＭ
ＮＩクライアントは非Ｚカウント測位をしていないの
で、３次元測位を行なうのに４つのＧＰＳ衛星が、或い
は２次元測位を行なうには３つのＧＰＳ衛星があればい
い。

【００９５】ＯＭＮＩクライアントが強いＧＰＳ衛星を
十分な数有し且つOMNIconfigのビットnoServerIfStrong
が設定されている場合には、ＯＭＮＩクライアントはサ
ーバなしで測位を行なうことができる。

【００９６】そうでなければ、ＯＭＮＩクライアントは
サーバに接続しなければならない。しかしながら、sigm
aPosが１５０ｋｍ以下の場合と同様に、ＯＭＮＩクライ
アントは、十分な数のＧＰＳ衛星を追跡しているので、
接続すれば測位を得られそうなときにだけ接続する。Ｏ
ＭＮＩクライアントが使用可能ＧＰＳ衛星を十分な数有
していない場合には、確実に探索を完了できる時間を与
えられるように或る期間先ず待機する。待機後、ＯＭＮ
Ｉクライアントはロジックを続行する。

【００９７】ＯＭＮＩクライアントは今では既に測位を
行なえないと判定している。追跡しているＧＰＳ衛星が
十分な数あるのでサーバ通信により確実にＯＭＮＩクラ
イアントが測位を行なえる場合に限って、ＯＭＮＩクラ
イアントはサーバと接続する。しかしながら、ＯＭＮＩ
クライアントが１つか２つのＧＰＳ衛星しか追跡してい
ない場合には、サーバ接続は何の役にも立たないので、
ＯＭＮＩクライアントは状況が変化するまで単に待機す
る。

【００９８】追跡しているＧＰＳ衛星で、軌道暦を有し
ていない衛星の数と、軌道暦を有する衛星の数が測位す
るのに十分な数であれば、ＯＭＮＩクライアントはサー
バと接続する。そうでなければ、ＯＭＮＩクライアント
は待機する。

【００９９】十分な数ならば、ＯＭＮＩクライアントは
自分が必要とするのはどの軌道暦か先ず調べる。ＯＭＮ
Ｉクライアントは、１５０ｋｍ以下のケースにおいて説
明したように、requestAllEphem、requestAllNotFres
h、requestTrackNotFreshに対して選択された調整を行
なうためにビットマスクを用いる。

【０１００】ＯＭＮＩクライアントが測位作業を行なっ
ていなければ、ＯＭＮＩクライアントは弱いＧＰＳ衛星
に対してサブフレームをいくつか収集しなければならな
い。ＯＭＮＩクライアントは、このアプリケーションの
調整を決めるのに２ビットのマスク（allHighNsubframe
s、onlyAboveThresh）を用いる。

【０１０１】ＯＭＮＩクライアントはコンフィギュレー
ションを調べて、例えば、ＯＭＮＩクライアントにおけ
るＤＧＰＳフィックスを得るなど、補正モデルを要求す
る方法を探す。ＯＭＮＩクライアントには３つのコンフ
ィギュレーションがある。

【０１０２】ＯＭＮＩクライアントが軌道暦或いはサブ
フレームを求めてサーバに接続しないと決めた場合で
も、ＯＭＮＩクライアントはいつでもcorrectionsReque
stCongfigバイトの中のビットDGPSalwaysによって補正
値を要求する。

【０１０３】もしくは、ＯＭＮＩクライアントが軌道暦
又はＮＡＶデータを求めてサーバ接続を行なうと既に決
めた場合に限ってDGPSnormalビットによってＤＰＧＳ補
正値を要求することができる。

【０１０４】OMNIconfigビットの中のrequestSPV及びre
questASPVに基づくＳＰＶ及びＡＳＰＶデータ。

【０１０５】以下の擬似デコードは、４つの異なるレベ
ル（ＡＵＴＯ，ＤＥＭＩ，ＴＨＩＮ，ＯＭＮＩ）でサー
バを使用できるクライアントを記述している。

【０１０６】本発明を現時点で好適な実施例として説明
してきたが、この開示を限定と解釈すべきではないこと
が理解できる。当業者なら、上記の開示を読めば、様々
な変形及び変更が明白になることは疑いの余地がない。
従って、発明の「真の」精神並びに範囲から逸脱しない
限りにおいて、添付した特許請求の範囲はあらゆる変形
並びに変更にも及ぶものと解釈されるものである。

【０１０７】

【発明の効果】本発明の効果は、ナビゲーション衛星受
信機をより速やかに初期化できるシステム並びに方法を
提供することにある。

【０１０８】本発明のもう一つの効果は、ナビゲーショ
ン衛星受信機の感度を向上させるためのシステム並びに
方法を提供することにある。

【図面の簡単な説明】

【図１】 本発明におけるネットワークシステムの実施
例の機能ブロック図。

【図２】 本発明におけるナビゲーションプラットフォ
ームの実施例の機能ブロック図。

【図３】 本発明における高感度受信方法のフローチャ
ート。

【符号の説明】

１００ ネットワークサーバ １０２、２０４ サーバ １０４ ＧＰＳ測定プラットフォーム １０６ コンピュータネットワーク １０８、１１０、１１２、１１４、１１６ ＧＰＳ衛星 ２００ ＯＭＮＩクライアントナビゲーション衛星受信
機 ２０２ ナビゲーションプラットフォーム ２０６、２２８、２３０ アンテナ ２０８ 低雑音増幅器 ２１０、２１４ 弾性表面波フィルタ ２１２、２１６ ＡＳＩＣ ２１８ 基準水晶 ２２０ 温度センサ ２２２ 自立型クライアント ２２４ デミクライアント ２２６ シンクライアント ２２７ ＯＭＮＩクライアント ２３２ 基準局マネージャ ２３４ ロケーションサーバ

─────────────────────────────────────────────────────

【手続補正書】

【提出日】平成１５年６月２５日（２００３．６．２
５）

【手続補正１】

【補正対象書類名】明細書

【補正対象項目名】０１０５

【補正方法】変更

【補正内容】

【０１０５】以下の擬似デコードは、４つの異なるレベ
ル（ＡＵＴＯ，ＤＥＭＩ，ＴＨＩＮ，ＯＭＮＩ）でサー
バを使用できるクライアントを記述している。

───────────────────────────────────────────────────── フロントページの続き (71)出願人 501396026 イーライド，インク. ｅＲｉｄｅ，Ｉｎｃ. アメリカ合衆国 カリフォルニア州，サン フランシスコ カリフォルニア ストリー ト 3450 3450 Ｃａｌｉｆｏｒｎｉａ Ｓｔｒｅｅ ｔ Ｓａｎ Ｆｒａｎｃｉｓｃｏ，Ｃａｌ ｉｆ ｏｒｎｉａ 94118−1837，Ｕｎｉ ｔｅｄ Ｓｔａｔｅｓ ｏｆ Ａｍｅｒｉ ｃａ (72)発明者 ポール ダブル マクバーニー アメリカ合衆国 カリフォルニア州 サン フランシスコ セカンド アベニュー 571 (72)発明者 ケネス ユー ビクタ アメリカ合衆国 カリフォルニア州 サン フランシスコ バーチウッド コート 1404 Ｆターム(参考） 5J062 AA02 BB01 BB05 CC07 DD22 FF01 5K067 BB36 DD20 JJ52 JJ56

Claims (7)

【特許請求の範囲】
1. 【請求項１】 ネットワークでサーバに接続できるナビ
   ゲーション衛星受信機の高感度操作の方法であって、当
   該方法は、 各衛星（ＧＰＳ衛星）の受信した信号の強さを測定する
   ステップと、 測定されたＧＰＳ衛星信号の強さを強、中、弱に分類す
   るステップと、 前記ＧＰＳ衛星の信号の強さが強と分類された場合に
   は、軌道暦、Ｚカウント、ＢＴＴを収集するために対応
   するＧＰＳ衛星からＮＡＶデータをダウンロードするス
   テップと、 前記ＧＰＳ衛星の信号の強さが中と分類された場合に
   は、Ｚカウント又は整数ミリ秒を得るために、ＮＡＶデ
   ータパターンマッチを使用し、そしてサーバから対応す
   る軌道暦をフェッチするステップと、 前記ＧＰＳ衛星の信号の強さが弱と分類された場合に
   は、前記サーバからＮＡＶデータ並びに軌道暦をフェッ
   チするステップと、 位置測位を計算するステップとを備えることを特徴とす
   る方法。
2. 【請求項２】 分類のステップは、強が−１４５ｄｂｍ
   を超える信号の強さとして定義されるようになっている
   ことを特徴とする請求項１に記載の方法。
3. 【請求項３】 分類のステップは、中が−１４５ｄｂｍ
   から−１５０ｄｂｍの範囲の信号の強さとして定義され
   るようになっていることを特徴とする請求項１に記載の
   方法。
4. 【請求項４】 分類のステップは、弱が−１５０ｄｂｍ
   未満の信号の強さとして定義されるようになっているこ
   とを特徴とする請求項１に記載の方法。
5. 【請求項５】 軌道暦情報が不足しているステップと、 衛星暦又はダウングレードされた軌道暦を用いてＧＰＳ
   衛星の捕捉のプレポジションを計算するステップとをさ
   らに備えることを特徴とする請求項１に記載の方法。
6. 【請求項６】 測位計算する前に使用できる軌道暦情報
   のエージ（age）を制限するステップをさらに備えるこ
   とを特徴とする請求項１に記載の方法。
7. 【請求項７】 低頻度及び最低限のサーバ接続によって
   高感度ナビゲーション位置測位を行なう方法であって、
   当該方法は、 軌道暦の使用可能性を分析するステップと、 受信した信号の強さによってＧＰＳ衛星を「Ｇ１」（−
   １４５ｄｂｍより良好）、「Ｇ２」（−１４５ｄｂｍか
   ら−１５０ｄｂｍの範囲）、又は「Ｇ３」（−１５０ｄ
   ｂｍ未満）に分類するステップと、 測位が可能かどうか判定するためにsigmaTime及びsigma
   Posを用いて、捕捉したＧＰＳ衛星数を数えるステップ
   と、 信号のレベル、sigmaTime、及びsigmaPosに基づいてＮ
   ＡＶデータを必要とするＧＰＳ衛星数を数えるステップ
   と、 サーバ接続を要求するかどうか、当該サーバ接続により
   最低限のデータを要求するかどうか、或いはサーバに最
   大限のデータを要求するかどうかを決定するステップ
   と、 取得したデータから位置測位計算するステップとを有す
   ることを特徴とする。