特許 7584519 ドップラー、高度、及び疑似距離の推定のための軌道要素を生成及び配布する方法及び装置

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2024-11-07

(45)【発行日】2024-11-15

(54)【発明の名称】ドップラー、高度、及び疑似距離の推定のための軌道要素を生成及び配布する方法及び装置

(51)【国際特許分類】

   G01S 19/05 20100101AFI20241108BHJP

【ＦＩ】

G01S19/05

【請求項の数】 36

(21)【出願番号】P 2022537236

(86)(22)【出願日】2020-12-07

(65)【公表番号】

(43)【公表日】2023-02-28

(86)【国際出願番号】 US2020063645

(87)【国際公開番号】W WO2021126581

(87)【国際公開日】2021-06-24

【審査請求日】2023-11-09

(31)【優先権主張番号】16/721,658

(32)【優先日】2019-12-19

(33)【優先権主張国・地域又は機関】US

【早期審査対象出願】

(73)【特許権者】

【識別番号】520460904

【氏名又は名称】スター アリー インターナショナル リミテッド

(74)【代理人】

【識別番号】110001379

【氏名又は名称】弁理士法人大島特許事務所

(72)【発明者】

【氏名】フア、ワンシャン

【審査官】渡辺 慶人

(56)【参考文献】

【文献】特表２００４－５２９０３２（ＪＰ，Ａ）

【文献】特開２０１３－０４０７９０（ＪＰ，Ａ）

【文献】特開２００８－１９１１５８（ＪＰ，Ａ）

【文献】特開２００８－００３０９２（ＪＰ，Ａ）

【文献】米国特許出願公開第２００８／０１１１７３８（ＵＳ，Ａ１）

【文献】米国特許出願公開第２００８／０２３８７６５（ＵＳ，Ａ１）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０１Ｓ ５／００ － ５／１４

１９／００ － １９／５５

(57)【特許請求の範囲】

【請求項1】

エフェメリスサーバであって、
プロセッサと、
広域通信ネットワークに接続された第１通信インターフェースと、
第２通信インターフェースと、
リアルタイムデータベースと、を有し、
前記プロセッサは、
（ａ）（ｉ）前記第１通信インターフェースを使用して前記広域通信ネットワーク上のブロードキャスト情報のソースにアクセスすることによってブロードキャストエフェメリス情報を取得し、前記ブロードキャストエフェメリス情報は少なくとも１つのＧＮＳＳの衛星に関連し、（ｉｉ）前記ブロードキャストエフェメリス情報からそれぞれの前記衛星の軌道の軌道情報を抽出し、（ｉｉｉ）抽出された前記軌道情報から前記衛星のそれぞれについて修正された軌道情報を作成して前記リアルタイムデータベースに格納し、
（ｂ）複数の指定時刻のそれぞれにおいて、前記ブロードキャストエフェメリス情報を使用して計算されたパラメータ値と、前記修正された軌道情報を使用して計算されたパラメータ値との間の推定誤差に基づく更新基準が満たされたとき、前記リアルタイムデータベース内の前記修正された軌道情報を更新し、
（ｃ）前記第２通信インターフェースを介して複数のデバイスのそれぞれに対して、更新済の前記修正された軌道情報を提供し、前記デバイスはそれぞれ、前記修正された軌道情報を使用して前記衛星のブロードキャスト信号を処理することができるＧＮＳＳ受信機を有し、
計算された前記パラメータ値が、高度、疑似距離、及びドップラーのうちの１以上である、エフェメリスサーバ。

【請求項2】

前記修正された軌道情報が要求に応じて前記デバイスに提供される、請求項１に記載のエフェメリスサーバ。

【請求項3】

前記第２通信インターフェースは、低電力の広域通信ネットワークにアクセスする、請求項１に記載のエフェメリスサーバ。

【請求項4】

前記低電力の広域通信ネットワークがＬｏＲａベースである、請求項３に記載のエフェメリスサーバ。

【請求項5】

前記更新基準が満たされない場合、前記衛星のそれぞれについての前記修正された軌道情報は更新されない、請求項１に記載のエフェメリスサーバ。

【請求項6】

前記修正された軌道情報は、前記衛星のそれぞれのケプラーエフェメリス情報を含む、請求項１に記載のエフェメリスサーバ。

【請求項7】

前記ケプラーエフェメリス情報は、前記衛星のうちの１つの軌道長半径の推定値を含む、請求項６に記載のエフェメリスサーバ。

【請求項8】

前記軌道長半径は、前記衛星の平均運動を用いて推定される、請求項７に記載のエフェメリスサーバ。

【請求項9】

前記平均運動は、時間の線形関数によってモデル化される、請求項８に記載のエフェメリスサーバ。

【請求項10】

前記ケプラーエフェメリス情報は、前記衛星のうちの１つの軌道の平均近点角に関連するパラメータ値を含む、請求項６に記載のエフェメリスサーバ。

【請求項11】

前記ケプラーエフェメリス情報は、前記衛星のうちの１つの軌道面に関連する昇交点経度の推定値をさらに含む、請求項６に記載のエフェメリスサーバ。

【請求項12】

前記修正された軌道情報は、前記デバイスが未だ所持していない修正された軌道情報のみに関連するビットストリームで、前記デバイスのうちの１つに通信される、請求項１に記載のエフェメリスサーバ。

【請求項13】

前記ビットストリームは、２以上の前記衛星の前記修正された軌道情報を含む、請求項１２に記載のエフェメリスサーバ。

【請求項14】

前記更新基準は第１性能基準及び第２性能基準を含み、（ｉ）それぞれの指定時刻において、前記衛星のうちの少なくとも１つが前記第１性能基準を満たす場合にのみ、前記更新基準が満たされているとみなされ、（ｉｉ）前記更新基準が満たされているとみなされると、前記第２性能基準を満たす前記衛星の軌道情報の前記修正された軌道情報が更新される、請求項１に記載のエフェメリスサーバ。

【請求項15】

前記指定時刻は一定の時間間隔で発生する、請求項１に記載のエフェメリスサーバ。

【請求項16】

様々な時刻における前記リアルタイムデータベースのコピーがエフェメリスサーバから離れた１以上の場所に格納され、それによって前記エフェメリスサーバを以前の状態に復元することを可能にする、請求項１に記載のエフェメリスサーバ。

【請求項17】

前記リアルタイムデータベースを前記以前の状態に続いて所望の状態に復元することを可能にするために、前記修正された軌道情報の作成のそれぞれのフェーズに関連する作成時間を前記リアルタイムデータベースにおいてさらに記録する、請求項１６に記載のエフェメリスサーバ。

【請求項18】

前記修正された軌道情報の参照セットとして選択された以前の時間において現在の前記修正された軌道情報を作成することによって前記リアルタイムデータベースを復元し、前記参照セット内の前記修正された軌道情報は、そのような前記修正された軌道情報が前記選択された以前の時間の後に更新された後にのみ前記デバイスに提供される、請求項１７に記載のエフェメリスサーバ。

【請求項19】

エフェメリスサーバにおいて少なくとも１つのＧＮＳＳからの衛星のエフェメリス情報を提供するための方法であって、
（ａ）（ｉ）広域通信ネットワーク上のブロードキャスト情報のソースにアクセスすることによってブロードキャストエフェメリス情報を取得するステップと、（ｉｉ）前記ブロードキャストエフェメリス情報からそれぞれの前記衛星の軌道の軌道情報を抽出するステップと、（ｉｉｉ）抽出された前記軌道情報から前記衛星のそれぞれについて修正された軌道情報を作成してリアルタイムデータベースに格納するステップと、
（ｂ）複数の指定時刻のそれぞれにおいて、前記ブロードキャストエフェメリス情報を使用して計算されたパラメータ値と、前記修正された軌道情報を使用して計算されたパラメータ値との間の推定誤差に基づく更新基準が満たされたとき、前記リアルタイムデータベース内の前記修正された軌道情報を更新するステップと、
（ｃ）複数のデバイスのそれぞれに対して、更新済の前記修正された軌道情報を提供するステップであって、前記デバイスはそれぞれ、前記修正された軌道情報を使用して前記衛星のブロードキャスト信号を処理することができるＧＮＳＳ受信機を有している、該ステップと、を有し、
計算された前記パラメータ値が、高度、疑似距離、及びドップラーのうちの１以上である方法。

【請求項20】

修正された前記軌道情報が要求に応じて前記デバイスに提供される、請求項１９に記載の方法。

【請求項21】

前記デバイス及び前記エフェメリスサーバは、低電力の広域通信ネットワークを介して通信する、請求項１９に記載の方法。

【請求項22】

前記低電力の広域通信ネットワークがＬｏＲａベースである、請求項２１に記載の方法。

【請求項23】

前記更新基準が満たされない場合、前記衛星のそれぞれについての修正された前記軌道情報は更新されない、請求項１９に記載の方法。

【請求項24】

前記修正された軌道情報は、前記衛星のそれぞれのケプラーエフェメリス情報を含む、請求項１９に記載の方法。

【請求項25】

前記ケプラーエフェメリス情報は、前記衛星のうちの１つの軌道長半径の推定値を含む、請求項２４に記載の方法。

【請求項26】

前記軌道長半径は、前記衛星の平均運動を用いて推定される、請求項２５に記載の方法。

【請求項27】

前記平均運動は、時間の線形関数によってモデル化される、請求項２６に記載の方法。

【請求項28】

前記ケプラーエフェメリス情報は、前記衛星のうちの１つの軌道の平均近点角に関連するパラメータ値を含む、請求項２４に記載の方法。

【請求項29】

前記ケプラーエフェメリス情報は、前記衛星のうちの１つの軌道面に関連する昇交点経度の推定値をさらに含む、請求項２４に記載の方法。

【請求項30】

前記修正された軌道情報は、前記デバイスが未だ所持していない修正された軌道情報のみに関連するビットストリームで、前記デバイスのうちの１つに通信される、請求項１９に記載の方法。

【請求項31】

前記ビットストリームは、２以上の前記衛星の前記修正された軌道情報を含む、請求項３０に記載の方法。

【請求項32】

前記更新基準は第１性能基準及び第２性能基準を含み、（ｉ）それぞれの指定時刻において、前記衛星のうちの少なくとも１つが前記第１性能基準を満たす場合にのみ、前記更新基準が満たされているとみなされ、（ｉｉ）前記更新基準が満たされているとみなされると、前記第２性能基準を満たす前記衛星の軌道情報の前記修正された軌道情報が更新される、請求項１９に記載の方法。

【請求項33】

前記指定時刻は一定の時間間隔で発生する、請求項１９に記載の方法。

【請求項34】

様々な時刻における前記リアルタイムデータベースのコピーが前記エフェメリスサーバから離れた１以上の場所に格納され、それによって前記エフェメリスサーバを以前の状態に復元することを可能にする、請求項１９に記載の方法。

【請求項35】

前記エフェメリスサーバは、前記リアルタイムデータベースを前記以前の状態に続いて所望の状態に復元することを可能にするために、前記修正された軌道情報の作成のそれぞれのフェーズに関連する作成時間を前記リアルタイムデータベースにおいてさらに記録する、請求項２４に記載の方法。

【請求項36】

前記エフェメリスサーバは、前記修正された軌道情報の参照セットとして選択された以前の時間において現在の前記修正された軌道情報を作成することによって前記リアルタイムデータベースを復元し、前記参照セット内の前記修正された軌道情報は、そのような前記修正された軌道情報が前記選択された以前の時間の後に更新された後にのみ前記デバイスに提供される、請求項３５に記載の方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、全球測位衛星システム（ＧＮＳＳ）に関する。本発明は、ＧＮＳＳを使用する位置、速度、及び時間（ＰＶＴ）の決定において使用されるエフェメリスデータの処理及び処理に関する。

【背景技術】

【0002】

取得時間を短縮するために、ＧＮＳＳ受信機には、ＧＮＳＳ内の衛星の軌道に関する事前情報（例えば位置及び速度、すなわち「エフェメリス」）が提供されている。例えば、そのような情報は、地上のソースから、またはＧＮＳＳ内の各衛星によって放送されるナビゲーションメッセージから得られる。衛星のエフェメリスにより、受信機は任意の時刻における衛星の高度、ドップラー、及び疑似距離を推定することができ、これにより、受信機は、衛星が受信機の地平線上に現れたときに、衛星の周波数及び遅延探索空間を狭めることができる。その点において、２００Ｈｚという比較的狭い周波数ビンでは、約１００Ｈｚのドップラー推定誤差が許容される。しかしながら、衛星の軌道は完全には予測できないので、提供されたエフェメリスは時間の経過とともに不正確になる。ＧＮＳＳ受信機の場合、衛星の提供されたエフェメリスの精度が低くなるにつれて、ドップラー、疑似距離、及び高度に起因する推定誤差が増加する。結果として、衛星を取得して追跡するために必要な時間及びエネルギーは、時間の経過とともに大幅に増加し得る。典型的には、ＧＮＳＳは、各衛星のナビゲーションメッセージ（「システム更新」）のブロードキャストエフェメリス情報を１－２時間で更新する。

【0003】

ドップラー、疑似距離、高度の推定と同様に、ＧＮＳＳの典型的な中軌道（「ＭＥＯ」）衛星は、地球の中心を１度飛行するのに約１２０秒かかる（すなわち、衛星の仰角（「高度」）の変化は１分あたり１／２度の単位である）ので、高度の推定誤差は比較的重要ではない。しかしながら、その間、衛星の速度は６０ｍ／秒（すなわち、約１％）変化するので、ドップラー及び疑似距離の両方の推定誤差が大きくなり得る。

【0004】

地心地球固定（ＥＣＥＦ）座標系において衛星の軌道を決定するためには、６つのケプラー軌道要素及び地球自転速度（Ω_ｅ）が必要である。ケプラーの軌道要素は以下の通りである：（ｉ）軌道離心率（ｅ）、（ｉｉ）軌道長半径の長さ（Ａ）、（ｉｉｉ）基準エポックにおける傾斜角（ｉ_０）、（ｉｖ）基準エポックにおける軌道面の昇交点経度（Ω_０）、（ｖ）近地点引数（ω）、及び（ｖｉ）基準エポックにおける平均近点角（Ｍ_０）。

【0005】

ＮＡＶＳＴＡＲ全球測位システム（「ＧＰＳ」）については、刊行物「NAVSTAR GPS Space Segment/Navigation User Segment Interfaces」（ＩＳ－ＧＰＳ－２００Ｄ；「インターフェース仕様」）のセクション２０．３．４における表２０－ＩＩ、２０－ＩＩＩ、及び２０－ＩＶに、エフェメリスパラメータのＥＣＥＦ調整システムの定義、データ形式、及び補正がリストされている。これらのエフェメリスパラメータのほとんどは、ケプラーの軌道パラメータに関連している。ＧＰＳでは、ＥＣＥＦ座標系の補正により、提供されたエフェメリスパラメータ値は、それぞれの特定のフィットインターバルについて最適な軌道のフィットを提供する。

【0006】

インターフェース仕様では、以下の９つのエフェメリスパラメータが追加されている：（ｉ）計算値からの平均運動差（Δｎ）、（ｉｉ）赤経の変化率（Ω）、（ｉｉｉ）傾斜角の変化率（ＩＤＯＴ）、（ｉｖ）緯度引数に対する正弦及び余弦高調波補正項の振幅（ｃ_ｕｓ，ｃ_ｕｃ）、（ｖ）軌道半径に対する正弦及び余弦高調波補正項の振幅（ｃ_ｒｓ，ｃ_ｒｃ）、及び（ｖｉ）傾斜角に対する正弦及び余弦高調波補正項の振幅（ｃ_ｉｓ，ｃ_ｉｃ）。これらの追加のエフェメリスパラメータは、ケプラーパラメータに対する「重力高調波補正項、レート及びレート補正」と呼ばれる。これらの追加のＧＰＳパラメータは、中国の北斗システム（ＢＤＳ）、ヨーロッパのガリレオシステム（ＧＡＬ）、及び日本のＱＺＳＳでも使用されている。ＧＰＳでは、ナビゲーションメッセージの長さは１５００ビット長であり、ナビゲーションメッセージの中で送信されるエフェメリスは、多くの場合、数日以内にのみ有効である。

【0007】

近年、このようなデバイスの位置が関連する小型のモバイルデバイスまたはセンサのための多くのアプリケーションが開発されている。多くのこのようなアプリケーション（例えば、「モノのインターネット」（ＩｏＴ）アプリケーション）では、このようなデバイスの位置は、オンボードのＧＮＳＳ受信機モジュールによって取得される。必然的に、ＩｏＴデバイスはバッテリ電源で動作し、通信は無線通信を使用する。実際、このような多くのアプリケーションでは、ＩｏＴデバイスは非常に低い電力要件で動作し、長距離の、非常に低いデータレートの無線通信システムを使用して通信を行う必要がある。

【発明の概要】

【課題を解決するための手段】

【0008】

本発明の一実施形態によれば、エフェメリスサーバは、少なくとも１つのＧＮＳＳからの衛星のエフェメリス情報を提供するための方法を実行する。本開示による方法は、（ａ）（ｉ）広域通信ネットワーク上のブロードキャスト情報のソースにアクセスすることによってブロードキャストエフェメリス情報を取得するステップと、（ｉｉ）ブロードキャストエフェメリス情報からそれぞれの衛星の軌道の軌道情報を抽出するステップと、（ｉｉｉ）抽出された軌道情報から衛星のそれぞれについて修正された軌道情報を作成してリアルタイムデータベースに格納するステップと、（ｂ）複数の指定時刻のそれぞれにおいて、更新基準の評価に基づいて、リアルタイムデータベース内の修正された軌道情報を更新するステップと、（ｃ）複数のデバイスのそれぞれに対して修正された軌道情報を提供するステップであって、デバイスはそれぞれ、修正された軌道情報を使用して衛星のブロードキャスト信号を処理することができるＧＮＳＳ受信機を有している、該ステップと、を有する。

【0009】

本発明は、以下の詳細な説明及び添付の図面を考慮することにより、よりよく理解される。

【図面の簡単な説明】

【0010】

【図1】本発明の一実施形態による、エフェメリスサーバ１０１と、それぞれがＧＮＳＳ受信機を有するデバイス１０２－１～１０２－ｎとを有するシステム１００を示す図である。

【図2】本発明の一実施形態による、ＬＫエフェメリスの各フィールドを示す表である。

【図3】それぞれ、ストラテジー１、ストラテジー２、または、どちらでもないストラテジー（「現在のストラテジー」）下での様々なシミュレーションの結果から得られた更新数と、ビットストリームあたりの平均長とを示す表である。

【発明を実施するための形態】

【0011】

本発明は、図１のシステム１００によってこの詳細な説明に示されている。図１は、本発明の一実施形態による、エフェメリスサーバ１０１と、それぞれがＧＮＳＳ受信機を有するデバイス１０２－１～１０２－ｎとを有するシステム１００を示している。システム１００では、デバイス１０２－１、１０２－ｎはそれぞれ、そのオンボードのＧＮＳＳ受信機を使用して、衛星航法関連の作業（例えば、位置、速度または時間の決定）、衛星測位関連または他の適切な作業を実行するが、航法関連の作業を容易にするために衛星エフェメリス情報をＧＮＳＳ受信機に提供するべく、エフェメリスサーバ１０１に依存している。例えば、エフェメリスサーバ１０１は、広域ネットワーク１０４（例えば、インターネット）を介して従来のソース１０３（例えば、ＮＡＳＡのＣＤＤＩＳ）からシステム更新にアクセスするか、あるいはシステム更新を受信する。そのいくつかはモバイルデバイス及びセンサであり得るデバイス１０２－１～１０２－ｎは、１以上の広域通信ネットワーク１０５（例えば、ＬｏＲａベースのネットワークなどの低電力の広域ネットワーク（ＬＰＷＡＮ））を介してエフェメリスサーバ１０１と通信する。これらのデバイスでは、省電力及び低帯域幅の効率的な使用が最も重要である。したがって、エフェメリスサーバ１０１によって提供されるエフェメリス情報は頻繁に更新されないことが強く望まれ、各更新メッセージは、実行可能な限り少ないビットを有するべきである。

【0012】

上述したように、システム更新においてエフェメリスが有効であり続ける期間は、衛星のその後の動作に依存する。高性能アプリケーションの場合、システム更新でのエフェメリスの有効寿命は最短で数時間である。本発明は、より長い寿命（「長続きするケプラーエフェメリス」すなわち「ＬＫエフェメリス」）を有するように修正され、システム更新が利用可能な場合は常にではないが、要求に応じて、あるいは１以上の性能基準に基づいてＧＮＳＳ受信機で更新される、デバイスによって選択されるエフェメリスパラメータ値を提供することにより、低電力デバイスのオンボードのＧＮＳＳ受信機で使用される衛星エフェメリスの寿命を延ばす。例えば、エフェメリスサーバ１０１は、最新のシステム更新を使用して得られたドップラーまたは疑似距離の推定値と、ＬＫエフェメリスを使用して得られたドップラーまたは疑似距離との間のドップラーまたは疑似距離の推定誤差を監視する。エフェメリスサーバ１０１は、監視された量が所定の閾値（「更新基準」）を超えた場合にのみ、ＬＫエフェメリスを再評価する。

【0013】

通常、ドップラーの推定誤差の閾値は１００Ｈｚに設定される（つまり、有効なエフェメリスは、±約５０Ｈｚ以内のドップラーの推定誤差を生じると予想される）。通信コストを削減するために、ＬＫエフェメリスにはシステム更新の選択されたエフェメリスパラメータのみが含まれる。エフェメリスサーバ１０１は、効率的な方法によって符号化されたメッセージで、ＬＫエフェメリスを各ＧＮＳＳ受信機に送信する。

【0014】

本発明者らは以下を観察する：
（ｉ）衛星の移動の摂動は、大きなドップラー推定誤差をもたらさないので、高調波項（すなわち、緯度引数（ｃ_ｕｓ，ｃ_ｕｃ）、軌道半径（ｃ_ｒｓ，ｃ_ｒｃ）、及び傾斜角（ｃ_ｉｓ，ｃ_ｉｃ）に対する正弦及び余弦高調波補正項の振幅）をＬＫエフェメリスに含める必要はない。
（ｉｉ）平均運動差Δｎ、赤経の変化率Ω、傾斜角の変化率ＩＤＯＴは関連している。３つの項は、地球の自転速度Ω_ｅ及び傾斜した極軸に大きく依存している。地球の自転速度Ω_ｅは非常にゆっくりと変化するので、衛星の軌道に対する影響は一般的に重要ではない。したがって、送信されるＬＫエフェメリスにこれらの項を含める必要はない。例えば、ＧＰＳ衛星の場合、ＧＮＳＳ受信機は、いくつかのアプリケーションではこれらの項についての適切な推定値であるＩＤＯＴ＝０及びΩ_ｅ＝８．１５ｅ－９．０を使用する。
（ｉｉｉ）軌道偏心率ｅ、基準エポックにおける傾斜角ｉ_０、基準エポックにおける軌道面の昇交点経度Ω_０、近地点引数ω、及び基準エポックにおける平均近点角Ｍ_０は比較的安定したパラメータであるので、これらのエフェメリスパラメータによって更新が必要とされる頻度は低いと予想される。

【0015】

しかしながら、衛星の軌道周期を決定する要因である軌道長半径Ａの推定誤差により、ＬＫエフェメリスの寿命が切れることがある。一般に、衛星の軌道の軌道長半径Ａは、以下の方程式を使用して推定される。

【0016】

【数1】

【0017】

式中、ｎは衛星の平均運動、Δｎは平均運動の推定誤差、μは地球の重力定数である。比較的長い期間（例えば、６０日）であっても、平均運動ｎは、時間の線形関数によってモデル化され得る。平均運動ｎと時間の線形関数との相関が０．５を超える場合、かつ、平均運動ｎに関する少なくとも３０日の履歴データが存在する場合、ｎの推定値ｎ^～は以下の方程式から導出される。

【0018】

【数2】

【0019】

式中、ｋ及びｂは、例えば履歴データの線形回帰から導出可能な値である。平均運動ｎと時間の線形関数との相関が０．５を超えず、かつ、平均運動ｎに関する少なくとも３０日の履歴データが存在する場合、ｎの推定値ｎ^～は以下の方程式から導出される。

【0020】

【数3】

【0021】

推定値ｎ^～は、基準エポックｔ_ｒｅｆにおける衛星の平均近点角Ｍ_０に対する補正ΔＭを以下の方程式によって計算するために使用される。

【0022】

【数4】

【0023】

衛星のクロック誤差の推定値Δｔは、以下の方程式を使用して取得される。

【0024】

【数5】

【0025】

ドップラー推定誤差の推定値Δλは、以下の方程式を使用して取得される。

【0026】

【数6】

【0027】

式中、ａは時刻ｔにおける視線に沿った衛星の加速度であり、ａ_ｍａｘは時刻ｔにおける視線に沿った衛星の最大加速度である。ＧＮＳＳ受信機のドップラーの推定誤差がドップラー閾値（Δλ）_ｍａｘ（例えば、１００Ｈｚ）内にあることを確認するために、推定値ｎ^～は、以下の方程式によって得られる。

【0028】

【数7】

【0029】

式中、ｔ_{ｍａｘΔＭ}は、平均近点角Ｍ_０についての最大推定誤差（ΔＭ）_ｍａｘが発生する時刻である。

【0030】

次に、衛星の軌道の軌道長半径の長さの長期的な推定値Ａ^～は、以下の方程式を使用して取得される。

【0031】

【数8】

【0032】

基準エポックｔ_ｒｅｆにおける長期的な平均近点角Ｍ_０ ^ｔｒｅｆは、以下の方程式によって、最後のシステム更新の指定時刻ｔにおける平均近点角Ｍ_０ ^ｔから導出される。

【0033】

【数9】

【0034】

同様に、軌道面の昇交点の長期的な経度Ω_０ ^ｔｒｅｆは、以下の方程式にしたがって、最後のシステム更新の指定時刻ｔにおける軌道面の昇交点経度Ω_０ ^ｔに関連している。

【0035】

【数10】

【0036】

式中、Ω_ｅは地球自転速度であり、ＷＮ^ｔｒｅｆ及びＷＮ^ｔはそれぞれ、参照エポックのＧＰＳ週及びエフェメリス時間のＧＰＳ週である。

【0037】

本発明の一実施形態によれば、少なくとも１つのＧＮＳＳから取得され、エフェメリスサーバ１０１からのエフェメリス更新で提供されるシステム更新に基づいて、エフェメリスサーバ１０１のプロセッサによって以下のエフェメリスパラメータのみが準備される：（ｉ）システム識別（「システムＩＤ」）、（ｉｉ）衛星識別（「ＰＲＮ ＩＤ」）、（ｉｉｉ）衛星の軌道の軌道長半径の長さの推定値Ａ^～、（ｉｖ）軌道偏心率の推定値ｅ^～、（ｖ）基準エポックにおける推定傾斜角ｉ_０ ^～、（ｖｉ）基準エポックにおける軌道面の昇交点経度の推定経度Ω_０ ^ｔｒｅｆ、（ｖｉｉ）近地点引数の推定値ω^～、及び（ｖｉｉｉ）基準エポックにおける平均近点角Ｍ_０ ^ｔｒｅｆ。項目（ｉｉｉ）－（ｉｖ）は、ＬＫエフェメリスの１つのフェーズを集合的に構成する。以下に示すように、ＧＮＳＳ受信機は、長期間（例えば、数週間）にわたってこれらのＬＫエフェメリスのみを使用して、妥当な所定の閾値（例えば、１００Ｈｚのドップラー閾値及び２５０マイクロ秒の遅延閾値）内で高度、疑似距離、及びドップラーを推定することができるので、ＧＮＳＳ受信機の頻繁な更新を回避することができる。

【0038】

理論的には、基準エポックがエフェメリスサーバ１０１及びＧＮＳＳ受信機の両方において知られている場合には、エフェメリスサーバ１０１は、各ＬＫエフェメリスのエフェメリス時間をＧＮＳＳ受信機に提供する必要はない。しかしながら、実際には、量子化誤差が蓄積するので、基準エポックが明示的に提供されることが好ましい。一実施形態では、エフェメリスサーバ１０１は、少なくとも基準エポックのＧＰＳ週をＧＮＳＳ受信機に提供する。

【0039】

一実施形態では、エフェメリスサーバ１０１は、推定疑似距離ｒ^～を監視してもよい。例えば、ＧＰＳでは、Ｃ／Ａコードは、１ミリ秒にわたって送信される１０２３個のチップを有している。したがって、０．２５ミリ秒という疑似距離予測閾値では、コード遅延は生じ得る１０２３の遅延の１／４に及ぶ範囲内にあることが予想される。一般に、ＭＥＯ衛星の１００Ｈｚドップラー閾値と同様に、０．２５ミリ秒の疑似距離予測閾値は、数ヶ月単位で有効である。このような状況では、本発明の方法によって生成されたＬＫエフェメリスは、適切な疑似距離推定を提供する。しかしながら、疑似距離予測閾値が低い場合（例えば、０．０２ミリ秒）には、有効な期間ははるかに短くなる（例えば、数日単位）。このように有効期間が短縮された場合、軌道長半径の履歴データベースの長さの推定値Ａ^～は不適切であり得る。しかしながら、この場合、最新のシステム更新からのエフェメリスパラメータ√Ａの２乗を長さ推定値Ａ^～としてＬＫエフェメリスで使用してもよい。１０ｋｍ以上の疑似距離推定値には、衛星クロックバイアス（ＡＦ０）及びクロックドリフト（ＡＦ１）の寄与も含めるべきである。

【0040】

ＧＮＳＳ衛星の軌道は完全には予測できないので、ＬＫエフェメリスに基づく高度、疑似距離、及びドップラーの推定の質は、時間の経過とともに必然的に低下する。したがって、本発明の一実施形態によれば、エフェメリスサーバ１０１は、これらの予測を監視する。ドップラーまたは疑似距離の推定誤差が衛星の対応する予め設定された閾値を超えると、エフェメリスサーバ１０１はその衛星のＬＫエフェメリスを更新する。

【0041】

その作業をサポートするために、エフェメリスサーバ１０１は、「スナップショット」として編成されたＬＫエフェメリスのリアルタイムデータベースを維持する。各スナップショットは、エフェメリスサーバ１０１によってサポートされる衛星のために最後に生成されたＬＫエフェメリスのセットに対応する（サポートされる衛星は、複数のＧＮＳＳから選択され得る）。一実施形態では、ＧＮＳＳ受信機は、指定時刻に関連する最後のスナップショットを要求する（指定時刻は、例えばＵＴＣ時刻として表される）。ＧＮＳＳ受信機は、指定されたスナップショット（おそらく、ＧＮＳＳ受信機に現在実装されているスナップショット）から最後のスナップショットへの更新を符号化するビットストリームを要求することもある。

【0042】

一実施形態では、各スナップショットはタイムスタンプによってタグ付けされる。同様に、各ＬＫエフェメリスも、シークエンス番号の形式のタイムスタンプによってタグ付けされる。シークエンス番号は、初期化時（例えば、２０１７年１月１日の００：１５にｔ＝０）から開始して、再評価時間ごとに（例えば、ＵＴＣ時間ごとに）１ずつ増加する整数ｔであってよい。したがって、これらのシークエンス番号は、１ＵＴＣ時間の連続するエポックにラベルを付ける。本明細書では、時刻ｔにおけるスナップショットはｓ（ｔ）で示され、時刻ｔにおいて作成された衛星ｊ（ｊ＝１、・・・、ｎ）のＬＫエフェメリスはｋｅｐｈ（ｊ，ｔ）で示される。最初に、すなわち、初期化時に、エフェメリスサーバ１０１は、監視されているすべての衛星の最後のシステム更新からスナップショットｓ（０）を作成する。したがって、スナップショットｓ（０）には、ＬＫエフェメリスｋｅｐｈ（０，０）、ｋｅｐｈ（１，０）、・・・、ｋｅｐｈ（ｎ，０）が含まれる。

【0043】

次の再評価時刻（すなわち、ｔ＝１）において、エフェメリスサーバ１０１は、スナップショットｓ（０）内のＬＫエフェメリスｋｅｐｈ（０，０）、ｋｅｐｈ（１，０）、・・・、ｋｅｐｈ（ｎ，０）のうちのいずれが、各衛星の更新基準の評価に基づいて更新を必要としているかを判定する。エフェメリスサーバ１０１は、更新基準が満たされた場合にのみ、新たなＬＫエフェメリスを作成する。例えば、時刻ｔ＝１においてＬＫエフェメリスｋｅｐｈ（０，０）及びｋｅｐｈ（２５，０）が更新を必要とする場合、エフェメリスサーバ１０１は、ＬＫエフェメリスｋｅｐｈ（０，１）及びｋｅｐｈ（２５，１）を作成する。エフェメリスサーバ１０１は、少なくとも１つのＬＫエフェメリスが更新を必要とする場合にのみ、再評価時刻において新たなスナップショットを作成する。したがって、スナップショットｓ（１）には、ＬＫエフェメリスｋｅｐｈ（０，１）、ｋｅｐｈ（１，０）、・・・、ｋｅｐｈ（２４，０）、ｋｅｐｈ（２５，１）、ｋｅｐｈ（２６，０）、・・・、ｋｅｐｈ（ｎ，０）が含まれる。スナップショットｓ（０）に長続きするケプラーエフェメリスが存在しない場合、エフェメリスサーバ１０１はスナップショットｓ（１）を作成しない。この一連のアクションは、すべての再評価時刻で繰り返される。この実施形態では、スナップショット及びＬＫエフェメリスの両方が、それぞれの作成時間によってインデックス付けされることに留意されたい。

【0044】

上記のように、更新基準は、最新のシステム更新を使用して取得された推定疑似距離ドップラーまたは高度と、ＬＫエフェメリスを使用して取得された対応する推定疑似距離ドップラーまたは高度との大きさの差異を評価する。差異が予め設定された閾値を超えると、更新基準が満たされる。一実施形態では、各再評価時刻において、エフェメリスサーバ１０１は、世界中に配置された約１００の場所のそれぞれでの監視下にある各衛星について、この更新基準を検査する。衛星の更新基準が１００の場所のうちの１以上で満たされると、衛星の新たなＬＫエフェメリスが作成される。

【0045】

しかしながら、デバイス１０２－１及び１０２－ｎの帯域幅が制限されているので、各デバイスは、エフェメリスサーバ１０１からの更新を要求した場合にのみ、オンボードＬＫエフェメリスに対する更新を受信する。この詳細な説明で使用される用語の数を減らすため、デバイス内のＬＫエフェメリスのコレクションは、「スナップショット」とも呼ばれる。いくつかの実施形態では、エフェメリスサーバとシステム１００内のデバイスとの間で作業が調整されないので（例えば、サーバは、以下で説明するように、いくつかの理由のいずれかのために現在のスナップショットに以前のエフェメリスを復元する）、エフェメリスサーバ上のＬＫエフェメリスのシークエンス番号は、デバイス内の対応するＬＫエフェメリスのシークエンス番号よりも小さいことがある。この場合、エフェメリスサーバ１０１上のスナップショットとデバイス上のスナップショットとが同一のシークエンス番号を有しているとしても、スナップショットは、ＬＫエフェメリスの同一のコレクションを有している必要はない。

【0046】

その更新要求によって、デバイスは、その最後のスナップショットに関連付けられたタイムスタンプ（すなわち、シークエンス番号）をエフェメリスサーバ１０１に送信する。次に、エフェメリスサーバ１０１は、受信したシークエンス番号を、現在のスナップショット内の各ＬＫエフェメリスのシークエンス番号と比較する。受信したシークエンス番号よりも大きいシークエンス番号を有するエフェメリスサーバ１０１の現在のスナップショット内のエフェメリスは、要求された更新のために指定される。この比較に基づいて、エフェメリスサーバ１０１は、それらの指定されたエフェメリスを更新するビットストリームを作成し、要求しているデバイスに送信する。例えば、デバイスのスナップショットｓ（２５）にＬＫエフェメリスｋｅｐｈ（０，２４）、ｋｅｐｈ（１，２４）、・・・、ｋｅｐｈ（２４，２４）、ｋｅｐｈ（２５，２４）、ｋｅｐｈ（２６，２４）、・・・、ｋｅｐｈ（ｎ、２４）が含まれており、エフェメリスサーバ１０１がＬＫエフェメリスｋｅｐｈ（０，２４）、ｋｅｐｈ（１，２４）、・・・、ｋｅｐｈ（２４，２４）、ｋｅｐｈ（２５，２７）、ｋｅｐｈ（２６，２３）、・・・、ｋｅｐｈ（ｎ、２４）を含む現在のスナップショットｓ（２７）を有している場合に、デバイスが時刻ｔ＝２７において更新要求を送信すると仮定する。デバイスの更新要求にはシークエンス番号２５が含まれる。更新要求を受信すると、エフェメリスサーバ１０１は、現在のスナップショットｓ（２７）内のＬＫエフェメリスｋｅｐｈ（２５，２７）のみが更新要求のシークエンス番号より大きいシークエンス番号を有していると判定する。したがって、デバイスには、ＬＫエフェメリスｋｅｐｈ（２５，２４）のみをｋｅｐｈ（２５，２７）に更新するビットストリームが必要である。デバイスは、ビットストリームを使用して、ＬＫエフェメリスｋｅｐｈ（０，２４）、ｋｅｐｈ（１，２４）、・・・、ｋｅｐｈ（２４，２４）、ｋｅｐｈ（２５，２７）、ｋｅｐｈ（２６，２４）、・・・、ｋｅｐｈ（ｎ、２４）が含まれるスナップショットｓ（２７）を作成する。

【0047】

エフェメリスサーバ１０１では、シークエンス番号は、任意の適切なビット長（例えば、ＧＰＳ時間の場合のように、２９ビット）を有していてよい。しかしながら、いくつかの実施形態では、通信帯域幅が限られていること、及び他の理由のために、デバイス１０２－１～１０２－ｎのうちのいくつかのシークエンス番号は、エフェメリスサーバ１０１のシークエンス番号よりも短いビット長で実装され得る。当然、このようなデバイスのシークエンス番号は、エフェメリスサーバ１０１のシークエンス番号よりも頻繁に「ロールオーバー」する。換言すれば、デバイスのシークエンス番号は、ｍｏｄｕｌｏ－２^ｍ（ｍはビット長）として扱う必要がある。スナップショット内のＬＫエフェメリスのシークエンス番号（例えば、Ａ）を更新要求内のシークエンス番号（例えば、Ｂ）と比較する場合、エフェメリスサーバ１０１はＢを０ ｍｏｄｕｌｏ－２^ｍからの有向距離の短い方として表す。具体的には、ＢはＣにマッピングされ、Ｂ＜２^ｍ－１の場合は値Ｂを取り、それ以外の場合は値（２^ｍ－１－Ｂ）を取る。エフェメリスサーバ１０１のスナップショット内のＬＫエフェメリスのシークエンス番号は、（Ａ－Ｃ）＞０の場合、更新要求のシークエンス番号よりも大きくなる。

【0048】

所定の時刻には、エフェメリスサーバ１０１は、処理の中断から回復するためにリセットされる必要がある。回復プロセスでは、新たなサーバを初期化して、すべてのＬＫエフェメリスを再生成し、処理を停止したサーバを置き換える。このようなアプローチは、新たなサーバのスナップショット内の実質的にすべてのＬＫエフェメリスのシークエンス番号が、デバイスのスナップショット内のものよりも大きくなるように、デバイス１０２－１～１０２－ｎのＧＮＳＳ受信機がすべてのスナップショットを更新する結果となるため、実用的ではない。結果として生じる作業負荷は、システム１００の通信帯域幅を圧倒する（通信帯域幅に対して作業負荷が大きすぎる）。

【0049】

本発明は、迅速かつ費用効果の高い回復プロセスを提供する。いくつかの実施形態では、エフェメリスサーバ１０１のリアルタイムデータベースは、サイト外のアーカイブから回復可能である。アーカイブされたデータベースが復元されると、回復プロセスにより、無効になった復元されたＬＫエフェメリスが再生成される。処理の中断が短い場合、デバイス１０２－１～１０２－ｎからのその後の更新要求を処理するために必要な帯域幅は完全に許容可能である。例えば、現在のエポックのスナップショットをアーカイブから復元することができ、かつ次のエポック（すなわち、次のＵＴＣ時間ごとの再評価時刻）の前に復元が完了すると、処理の中断は最小限に抑えられる。

【0050】

本発明の一実施形態によれば、エフェメリスサーバ１０１はまた、そのシステム更新がＬＫエフェメリスを生成するために使用される場合、各システム更新の時間を記録する。このアプローチでは、１以上のスナップショットが失われた場合でも（回復不能であるか、あるいは処理の中断が１以上の再評価時刻に及ぶので）、復元されたスナップショットに続いて、処理の中断前のすべてのスナップショットが再作成され得る。処理の中断中に失われたスナップショットについては、中断中に発生したすべてのシステム更新を使用して再作成することができ、このようなシステム更新は、システム１００の外部のソースから入手することができる。

【0051】

本発明の一実施形態によれば、エフェメリスサーバ１０１はまた、以前のシステム更新（例えば、処理の中断より２４ＵＴＣ時間前における現在のシステム更新）から特別なスナップショット（「参照スナップショット」）を生成することによって回復される。参照スナップショットからのＬＫエフェメリスは、デバイス１０２－１～１０２－ｎのＬＫエフェメリスを更新するためには使用されない。例えば、時刻ｔ＝ｔ＾において、参照スナップショットｓ（＊）は、ＬＫエフェメリスｋｅｐｈ（０，＊）、ｋｅｐｈ（１，＊）、・・・、ｋｅｐｈ（ｎ，＊）を含む以前のシステム更新から作成される。その後、ｔ＝ｔ＾＋ｐ、すなわちｐの再評価時刻においてそれぞれの更新基準を満たし、ＬＫエフェメリスｋｅｐｈ（２５，＊）、ｋｅｐｈ（２６，＊）が更新され、スナップショットｓ（ｔ＾＋ｐ）にはＬＫエフェメリスｋｅｐｈ（０，＊）、ｋｅｐｈ（１，＊）、・・・、ｋｅｐｈ（２４，＊）、ｋｅｐｈ（２５，ｔ＾＋ｐ）、ｋｅｐｈ（２６，ｔ＾＋ｐ）、・・・、ｋｅｐｈ（ｎ，＊）が含まれる。エポックｔ＝ｔ＾＋ｐの間に、エフェメリスで受信された更新要求によって、衛星２５、２６のＬＫエフェメリスが要求デバイスで更新される。残りのＬＫエフェメリスは、その後の再評価時刻におけるそれぞれの更新基準にしたがって通常の過程で置き換えられ、デバイス１０１－１～１０１－ｎの対応するＬＫエフェメリスを更新することができる。このように、処理の回復に起因する制限された帯域幅が圧倒されることはない。いくつかの実施形態では、参照スナップショットのすべてのＬＫエフェメリスについて１つの基準時間で現在のシステム更新を選択するのではなく、異なる基準時間（おそらく、ランダムに選択される）を使用することにより、各衛星のＬＫエフェメリスを生成してもよい。

【0052】

確かに、本発明の回復方法は、デバイス１０２－１～１０２－ｎのいくつかにおいて性能の低下をもたらし得る。例えば、デバイスは、参照スナップショットからの対応するＬＫエフェメリスが通常の過程で置き換えられるまで、期限切れのＬＫエフェメリスを使用する必要がある。しかしながら、本発明の回復方法は、システムが時間とともに体よく回復することを確実にする。

【0053】

本発明の一実施形態によれば、ＬＫエフェメリス更新のためのビットストリームは、ヘッダ部分と本体部分とを有する。ヘッダ部分は、１５ビットの「データ発行エフェメリス（ＩＯＤＥ）」と、ＬＫエフェメリスが更新された衛星を列挙する識別子（ＳＩＤ）とを含む。ＩＯＤＥには、更新のシークエンス番号が含まれている。ＳＩＤには、ＧＰＳ、ＢＤＳ、ＧＡＬ、及びＱＺＳＳを（順番に）表示する４つの１ビットのＧＮＳＳ識別フラグが含まれている。４つのＧＮＳＳ識別フラグのうちの１つのみが設定されている場合、次の８ビットワードは、識別されたコンステレーションの衛星のリストへのインデックスである。それ以外の場合には、ＬＫエフェメリスを含む各ＧＮＳＳの衛星フラグマップが、ＧＮＳＳ識別フラグの順序で続く。ＧＰＳフラグが設定されている場合、その衛星マップには３１のフラグが含まれ、各設定フラグはＬＫエフェメリスが含まれている１つの衛星を表す。衛星は、疑似乱数コードインデックス（「ＰＲＮ ＩＤ」）の順に表される。同様に、ＢＤＳ、ＧＡＬ、及びＱＺＳＳの場合、それぞれの衛星フラグマップは、それぞれ３７ビット、３６ビット、及び８ビットを有している。

【0054】

ビットストリームの本体部分は、ヘッダの衛星フラグマップにおける設定されたフラグの順序にしたがって、ＬＫエフェメリス（すなわち、軌道及びクロックのパラメータ値）の連続したリストである。図２は、本発明の一実施形態による、ＬＫエフェメリスの各フィールドを示す表である。「週フラグ」または「（Ω_ｅ）」フラグが設定されていない場合、対応する「週」フィールドまたは「Ω_ｅ」フィールドはビットストリームに表示されないことに留意されたい。いくつかの実施形態では、識別された衛星のいずれかの軌道タイプ（すなわち、ＭＥＯ、ＧＥＯ、またはＧＳＯ）が既知であるので、「軌道タイプ」フィールドは省略される。

【0055】

いくつかの実施形態では、エフェメリスサーバ１０１は、更新の頻度を制御するために、ＬＫエフェメリスにヘルスフラグを設定するかどうかを決定する。

【0056】

いくつかの実施形態では、現在のスナップショットは、各ＧＮＳＳ受信機が動作可能となる前に、各ＧＮＳＳ受信機に予めインストールされている。現在のスナップショットは、システムにおいて動作を開始したときに各ＧＮＳＳ受信機にインストールされてもよい。

【0057】

各ＬＫエフェメリスの形式（例えば、フィールド及びそれぞれのビット長）は、経験的に決定される。一実施形態によれば、３６５ＵＴＣ（協定世界時）日の実際のシステム更新が収集され、シミュレーションで使用される。最初の７０日間のデータは、ＬＫエフェメリスの各フィールドのビット長を調整するために使用される。例えば、ビット長が長いほど、ケプラーパラメータ値の精度が高くなる。そのケプラーパラメータに対する更新基準の感度が高いほど、より長いビット長が必要になる。ＬＫエフェメリスにはパラメータの数が多いので、ＬＫエフェメリスの形式を調整して望ましいビット長及び高い性能（すなわち、比較的まれにしか更新を必要としない）を取得するためには、相当量の試行錯誤と、知識に基づいた推測とが必要である。

【0058】

望ましいＬＫエフェメリス形式が取得された後、残りの２９５ＵＴＣ日のデータが３１の衛星で使用される。エフェメリスは、上記のように、本発明の一実施形態にしたがって、それらのＬＫエフェメリスを更新する。エフェメリスサーバは、１２００ＵＴＣ秒ごとに、世界中のランダムに選択された１００の場所においてすべての衛星のドップラー更新基準を評価する。このシミュレーションでは、各衛星のドップラー基準は９０Ｈｚの閾値である。評価された更新基準のいずれかで閾値を超えると、次のスナップショットのためにＬＫエフェメリスが生成される。

【0059】

図２のＬＫエフェメリス形式を使用した１つの３６５ＵＴＣ日のシミュレーションでは、いくつかのＬＫエフェメリスは期限切れにならなかった。最も頻繁に更新される衛星には３つの更新があった。シミュレーションの最後の２９５ＵＴＣ日の期間には、合計４１の更新が必要であった。

【0060】

第２のシミュレーションでは、５００ＵＴＣ日のシステム更新及び様々な疑似距離更新基準が使用される。結果は、より狭い疑似距離閾値からより高い更新頻度が生じるという仮説と一致していた（例えば、０．２５ミリ秒対０．０２ミリ秒）。このシミュレーションでは、５０Ｈｚというドップラー閾値が使用されたが、これは疑似距離の性能に実質的な影響を与えるようには見えなかった（すなわち、５０Ｈｚの閾値を増加させても、各疑似距離閾値の下で更新周波数が大幅に低下することはなかった）。

【0061】

一実施形態（「ストラテジー１」）では、エフェメリスサーバ１０１は、ビットストリームに含まれるＬＫエフェメリスの数が所定の数（例えば、５）を超えない限り、更新のためにビットストリームを送信しない。

【0062】

別の実施形態（「ストラテジー２」）では、広い疑似距離閾値と狭い疑似距離閾値とが同時に監視され、狭い疑似距離閾値は、広い疑似距離閾値の積であり、スケールファクタは１．０未満である。このアプローチでは、広い疑似距離閾値に基づく更新基準がいずれかの衛星で満たされると、狭い疑似距離閾値に基づく更新基準を満たしている衛星に対してＬＫエフェメリスが更新される。図３は、それぞれ、ストラテジー１、ストラテジー２、またはいずれでもないストラテジー（「現在のストラテジー」）での様々なシミュレーションの結果からの更新数と、ビットストリームあたりの平均長とを示している。ストラテジー２では、様々なスケールファクタをシミュレーションした。シミュレーションは、ＧＰＳ、ＧＡＬ、ＢＤＳ、及びＱＺＳＳによる５６の衛星からのエフェメリスデータを使用して実施した。

【0063】

上記の詳細な説明は、本発明の特定の実施形態を説明するために提供されており、本発明を限定することを意図するものではない。本発明の範囲内での多数の変形及び修正が可能である。本発明は、添付の特許請求の範囲に記載されている。

【図1】

【図2】

【図3】