全地球航法衛星システム (GNSS) ドライバーのアーキテクチャ

全地球航法衛星システム (GNSS) UMDF 2.0 ドライバーのアーキテクチャの概要、I/O に関する考慮事項、数種類の追跡および修正セッションについて説明します。

アーキテクチャの概要

次の大まかなコンポーネント ブロック図は、全地球航法衛星システム (GNSS) UMDF 2.0 ドライバーが Windows 10 プラットフォームとどのように統合されるのかを示しています。

図の各コンポーネントについて以下に説明します。

• LBS アプリケーション: Windows 10 プラットフォームの位置情報機能を使用するユーザー アプリケーション。

• テスト アプリケーション: GNSS 機能をテストするためのアプリケーション。

• GNSS API: GNSS デバイスの機能を位置情報サービスの内部コンポーネントおよびテスト アプリケーションに公開する IGnssAdapter COM (コンポーネント オブジェクト モデル) インターフェイス。 この API の正確な構造はこのドキュメントの範囲外です。 Windows コンポーネントは、IGnssAdapter COM インターフェイスに対するプログラミングによって GNSS デバイスを使用します。 GNSS API セットは、位置情報プラットフォーム コンポーネント (位置情報サービスや位置情報テスト アプリケーションなど) 限定のプライベート API であり、他のファーストパーティまたはサードパーティ アプリケーションでは使用できません。

• GNSS アダプター: これは、IGnssAdapter COM インターフェイスを実装するシングルトン COM オブジェクトです。 テスト アプリケーションと位置情報サービスの内部コンポーネントは、このオブジェクトをインスタンス化し、IGnssAdapter インターフェイスを介して GNSS デバイスを使用します。 位置情報サービスの GNSS 測位エンジン コンポーネントは、IGnssAdapter インターフェイスを公開する COM クラスを実装します。 位置情報サービスは、位置情報サービス内の GNSS アダプター COM クラスのシングルトン COM オブジェクトをインスタンス化するために、テスト アプリケーションと他のアウトプロセス アプリケーションにファクトリ メカニズムを公開します。 アウトプロセス アプリケーションは、COM インターフェイス ポインターを使用して、GNSS ドライバーに対してプログラミングします。

  アプリケーションが IGnssAdapter インターフェイス ポインターをインプロセス COM オブジェクトとして扱うために、COM ハンドルはインターフェイス ポインターをアウトプロセス アプリケーションにプロキシしますが、呼び出しは実際には位置情報サービス内のシングルトン GNSS アダプター オブジェクトによって処理されます。

  GNSS 測位エンジンでは、位置固有の機能を位置情報サービスに提供するために、内部 GNSS アダプター オブジェクトを使用します。 GNSS アダプターは、CreateFile API を使用して GNSS ドライバーへのファイル ハンドルを開き、GNSS ネイティブ API 呼び出しを適切な DeviceIoControl 呼び出しにラップし、GNSS ドライバー オブジェクトを使用してステート マシンを保持し、上位層からのさまざまな受信要求の状態を保持します。 このコンポーネントは、このドキュメントで定義されているパブリック GNSS IOCTL インターフェイスを介して、基になる GNSS デバイス スタックと直接対話します。 GNSS デバイスは論理的に排他的リソースとして扱われるため、シングルトン GNSS アダプターが GNSS デバイスへのすべてのアクセスを制御します。

  特定のホワイトボックス ドライバー テスト アプリケーションでは、GNSS プライベート API を介して GNSS アダプターを使用する代わりに、非運用環境で GNSS ドライバー IOCTL インターフェイスを直接使用することもできます。 ただし、これらのテスト アプリケーションでは、GNSS アダプターの特定の機能を模倣するために、独自のステート マシンと処理を実装する必要があります。

• GNSS ドライバー: IHV が提供する、UMDF 2.0 を使用して実装されたドライバー。 GNSS ドライバーは、実際の GNSS ハードウェアとのインターフェイスとして機能することで GNSS DeviceIoControl API をサポートします。 GNSS ドライバーは、SUPL 機能のメディエーター/インテグレーターとしても機能します。

• GNSS デバイス/エンジン: これは、GNSS デバイスの SoC とハードウェア部分をカプセル化する概念コンポーネントです。 IHV は GNSS 機能のほとんどをこのコンポーネント内に実装することもできるため、GNSS ドライバー層が非常に薄くなります (基本的には、GNSS デバイスとのインターフェイスとなるアダプター)。

従来の Windows モデルに従う全地球航法衛星システム (GNSS) デバイスおよびドライバーのサポート

Windows 10 の位置情報プラットフォームでは、従来の Sensors v1.0 クラス ドライバー (「位置センサー ドライバーの作成」を参照) を介して統合された GNSS デバイス、または GNSS ドライバー リファレンスに記載されている新しい GNSS DDI を介して統合された GNSS デバイスをサポートしています。

そのため、Windows 7、Windows 8、Windows 8.1 に存在する Sensor v1.0 クラス拡張モデルと統合された GNSS デバイスを搭載する Windows デバイスは、変更を必要とせずに Windows 10 で引き続き動作することが期待されます。 ユーザーのアップグレード プロセスを改善するために、これらのドライバー (および新しいドライバー) を Windows Update に公開することを強くお勧めします。

Windows 10 と共に発行される Hardware Lab Kit (HLK) には、GNSS デバイス用の 2 種類のテスト セットがあります。

• 1 つは、新しいモデルに従うドライバーを認定するための新しいテスト セット。

• もう 1 つは、古いモデルに従うドライバーを認定するためのテスト セット。 これらは、Windows 8.1 の WHCK で使用できるテスト セットと同じです。

HLK の新しい Gatherer コンポーネントは、2 つのテスト セットのうち、システムで実行する必要があるテスト セット (存在する場合) を特定します。

全地球航法衛星システム (GNSS) デバイスの共存

1 つのシステムで複数の GNSS デバイスが検出されるまれなケースでは、位置情報プラットフォームは、主にシステムの全体的な消費電力を削減するために 1 つのデバイスのみを使用します。 次の前提条件が考慮されています。

• 新しい DDI を使用するデバイスの方が新しい可能性があるため、消費電力が改善され、より多くの星座をサポートし、より優れた支援をサポートする可能性が高くなります。 そのため、古いドライバー モデルを使用しているデバイスと新しいドライバー モデルを使用しているデバイスが検出された場合は、後者が選択されます。

• 内部 GNSS デバイスが存在するときにユーザーが外部 GNSS デバイスを接続した場合、そのユーザーがこの外部デバイスを使用することを望んでいる可能性が高くなります。

これらの前提条件に基づく位置情報プラットフォームの動作は、次のようになります。

• 2 つのレガシ ドライバーが共存する場合: 下位互換性の問題を回避するために、動作は Windows 8.1 と同じになります。つまり、両方の GNSS デバイスが同時に使用され、一方の応答がスタックからアプリケーションに伝達されます。

• デバイス内のレガシ ドライバーが 1 つと外部接続された新しいドライバーが 1 つある場合: 外部接続された GNSS デバイスが使用されます。

• デバイス内の新しいドライバーが 1 つと外部接続された新しいドライバーが 1 つある場合: 外部接続された GNSS デバイスが使用されます。

選択された GNSS デバイスがジオフェンシング操作や他のオフロードされた操作をサポートしている場合、そのデバイスの使用中にオフロードが実行されます。 GNSS アダプターが、複数の GNSS デバイス間で機能やセッションを分割することはありません。

全地球航法衛星システム (GNSS) インターフェイスの概要

GNSS アダプターと GNSS ドライバー間の対話は、次のカテゴリに分類されます。

機能情報の交換

Windows プラットフォーム上の GNSS スタックの拡張性と適応性をサポートするために、GNSS アダプターと GNSS ドライバーは、基になる GNSS スタックの明確に定義されたさまざまな機能と、Windows プラットフォームによって提供されるサポートに関する共通理解を確立します。 機能の側面は、この GNSS インターフェイス定義の一部として Microsoft によって明確に定義されており、GNSS 空間でのさらなるイノベーションが続き、多様なチップセット/ドライバーが市場に登場するにつれて進化していきます。 GNSS アダプターは、初期化時または必要に応じて、基になる GNSS ドライバー/デバイスのさまざまな機能を照会し、それに応じて GNSS ドライバーとの対話を最適化します。

GNSS アダプターと GNSS ドライバー間での機能情報の交換は、制御コード IOCTL_GNSS_SEND_PLATFORM_CAPABILITY と IOCTL_GNSS_GET_DEVICE_CAPABILITY を使用して行われます。

全地球航法衛星システム (GNSS) ドライバーのコマンドと構成

GNSS アダプターは、GNSS ドライバーの 1 回限りの構成または定期的な再構成を行うことができます。 同様に、GNSS アダプターはドライバーを介して特定の GNSS 固有のコマンドを実行できます。 これは、ドライバーと高レベル オペレーティング システム (HLOS) 間のコマンド実行プロトコルを定義することによって実現されます。 特定のコマンドの種類に応じて、目的のアクションがすぐに有効になる場合もあれば、システムの再起動後に有効になる場合もあります。 GNSS デバイスの機能情報と同様に、GNSS コマンドもこの GNSS インターフェイス定義の一部として Microsoft によって明確に定義されており、将来のイノベーションと GNSS デバイス/ドライバーの多様化に伴って進化を続けます。

デバイス コマンドの実行と構成は、IOCTL_GNSS_SEND_DRIVERCOMMAND 制御コードを使用して行われます。

位置情報

これは、基になる GNSS デバイスの主要機能です。 最も基本的な形では、GNSS アダプターがデバイスの現在位置を GNSS ドライバーに要求します。 位置要求のバリエーションには、次の位置セッションの種類があります (ただし、これらに限定されるわけではありません)。

• デバイスの現在位置 (シングル ショット修正)

• 定期的な連続修正ストリーム (時間ベースの追跡)

• 移動しきい値に基づく連続修正ストリーム (距離ベースの追跡)

すべての GNSS ハードウェアと GNSS ドライバーに必要な唯一の必須の位置セッションの種類は、シングル ショット修正セッションです。 (SOC、GNSS デバイスに実装され、GNSS ドライバーやアプリケーション プロセッサで実行されているサービスには実装されていない) ネイティブの時間ベースの追跡セッションと距離ベースの追跡セッションは、必要に応じてサポートできます。 この 2 種類のネイティブ追跡セッションの主な利点は、より多くの処理を SOC で行い、必要に応じて変更の報告だけを行って、アプリケーション プロセッサ (AP) を長時間休止状態にしておくことで、電力を節約できる可能性があることです。 ネイティブの距離ベースの追跡は、より多くの電力を節約でき、アプリケーションでより広く使用されるため、この追跡のサポートは、ネイティブの時間ベースの追跡セッションよりも影響が大きくなります。

GNSS ドライバーから位置情報を取得する動作は、ステートフルな独自の修正セッションを通じて実行され、次のアクションで構成されます。

1. 修正セッションの開始: GNSS アダプターは、(LBS アプリケーションからの要求の結果として) 修正開始セッションを開始します。 GNSS アダプターは、特定の要件と基本設定の要求への関連付けを設定し、IOCTL_GNSS_START_FIXSESSION 制御コードを発行して、エンジンを起動して修正を取得するよう GNSS ドライバーに伝えます。

2. デバイスの位置 (修正データ) の取得: 修正セッションが開始されると、GNSS アダプターは IOCTL_GNSS_GET_FIXDATA 制御コードを発行して、ドライバーから返される修正の待機を開始します。 新しい位置情報をエンジンから入手可能になると、GNSS ドライバーはこの保留中の修正取得要求に応答します。

   修正セッションの種類が (現在の修正ではなく) LKG 修正の場合、位置情報はドライバーのキャッシュから取得されます。

   GNSS アダプターは、GNSS ドライバーが修正データ (使用可能な場合) を返すために、非同期 I/O 要求が常に使用可能であることを確認します。 修正の性質に応じて、より多くの修正データが予想される場合、GNSS アダプターは (同じ IOCTL を使用して) 別の I/O 要求を発行します。使用可能なデータがなくなるか、修正セッションが停止されるまで、このシーケンスが続行されます。

3. 修正セッションの変更: GNSS ドライバーが同じ種類の修正セッションの多重化をサポートしていない場合、GNSS アダプターはそのレベルで多重化を行うときに、その修正セッションの種類に対して IOCTL_GNSS_MODIFY_FIXSESSION を発行できます。

4. 修正セッションの停止: 特定の修正セッションに関するそれ以上の位置情報が必要ないか、または期待されない場合、GNSS アダプターは修正停止セッションを発行します。

ジオフェンシングのネイティブ サポート

GNSS DDI では、この仕様で定義されている一連の IOCTL を使用したジオフェンス オフロード シナリオをサポートしています。 ドライバーがこのサポートを示すための特別な機能フラグが定義されています。このフラグは、GNSS スタックがジオフェンシングをネイティブにサポートしている場合 (つまり、アプリケーション プロセッサではなく、GNSS チップにジオフェンシングを実装している場合) にのみ設定する必要があります。 ドライバーがジオフェンスをネイティブにサポートしていない場合、このフラグは設定しないでください。 HLOS では、最適ではないアプリケーション プロセッサ (AP) ベースのジオフェンス追跡エンジンを既にサポートしています。このソリューションはネイティブ ソリューションほど電力に最適化されていませんが、十分にテストされ最適化されているため、AP に実装されている同等のソリューションに置き換える必要はありません。

HLOS によるジオフェンス追跡では、ジオフェンス違反を検出するために、アプリケーション プロセッサがスリープ状態から定期的に復帰する必要があるため、フェンスが侵害されていなくても電力を消費します。 そのため、この実装は最適ではないと見なされます。

また、HLOS では、ネイティブのジオフェンス追跡ソリューションから受信したエラー通知に示された低信号状態や他の一時的なエラーが原因で、基になるドライバーがジオフェンスを追跡できない場合に、フェールオーバー メカニズムとして AP ベースのジオフェンス追跡を使用します。 ジオフェンシングのネイティブ サポートが役立つのは、ジオフェンス追跡が SoC に完全にオフロードされ、ジオフェンス関連のイベントを処理するためだけにアプリケーション プロセッサを復帰させる場合だけです。 ハードウェアがネイティブのジオフェンス追跡をサポートしていない場合、GNSS ドライバーはドライバー層でジオフェンス追跡の実装を試みることはできません。

GNSS エンジンは、消費電力とユーザー エクスペリエンスの適切なバランスを見つけることができるように、文書化された IHV 固有のチューニング パラメーターを公開する必要があります。 さらに、サポートされるジオフェンスの数は、ヘッダー ファイルで定義されている MIN_GEOFENCES_REQUIRED 値を超える必要があります。 アプリケーションには、他のアプリケーションや携帯電話会社が使用するジオフェンスの数がわからないため、MIN_GEOFENCES_REQUIRED はアプリケーションごとに定義されることに注意してください。

ジオフェンシング オフロードのサポートには、次の要件があります。

• HLOS は、DDI を介して 1 つ以上のジオフェンスを作成できる必要があります。ドライバーはそれらをハードウェアに送信して追跡を開始します。

• HLOS は DDI を介して、以前に作成された 1 つ以上のジオフェンスを削除できる必要があります。ドライバーはそれらをハードウェアに送信して追跡を停止します。

• GNSS ハードウェアは、各ジオフェンスの初期ジオフェンス追跡状態を把握し、この初期状態からの変更のみを報告するのが理想的です。 GNSS ハードウェアがこの機能をサポートしていない場合は、ジオフェンスが作成されるたびに初期状態が HLOS に報告されます。

• GNSS ハードウェアは電力効率の高い方法でデバイスの現在位置を追跡し、デバイスが追跡対象のジオフェンスに出入りするたびに AP をスリープ状態から復帰させます。 GNSS ドライバーは、ジオフェンス アラートを HLOS に渡します。

• 低衛星信号状態やその他の一時的なエラー状態では、GNSS エンジンは既存のジオフェンスを確実に追跡できない可能性があります。 GNSS エンジンは追跡の中断を検出できる必要があり、GNSS ドライバーは追跡状態エラー アラートを HLOS に渡す必要があります。 GNSS ハードウェアが回復し、ジオフェンスを再び追跡できるようになるまで、HLOS は既定の AP ベースのジオフェンス追跡に切り替えます。

• GNSS エンジンがジオフェンスが追跡できないことを示す通知を提供する必要がある正確な条件はさまざまであり、実装は IHV 固有のものになります。 実装のガイドラインを次に示します。

  • GNSS エンジンは、ユーザーが移動中ではなく、25 メートル以内にジオフェンス境界がないことを高い信頼度で検出できる場合、追跡エラーを送信する必要はありません。

  • GNSS エンジンは、ユーザーは移動中ではないが、25 メートル以内にジオフェンス境界があることを高い信頼度で検出できる場合、1 分以内に追跡エラーを送信する必要があります。

  • GNSS エンジンは、ユーザーが移動中であり、100 メートル以内にジオフェンス境界があることを検出した場合、1 分以内に追跡エラーを送信する必要があります。

  • GNSS エンジンは、ユーザーが移動中かどうか、100 メートル以内にジオフェンス境界があるかどうかを判断できない場合、1 分以内に追跡エラーを送信する必要があります。

  • GNSS エンジンは、ユーザーが移動中であることを検出した場合、推定移動速度と最も近いジオフェンスまでの距離に比例した時間内に追跡エラーを送信する必要があります。 [(最も近いフェンス境界までの距離 (m) / 推定速度 (m/s)) - 15s] 以内にエラーを送信することが推奨されます。 GNSS エンジンは移動検出の指標を使用して、追跡エラーを送信するタイミングを決定できます。

  • GNSS エンジンは、ユーザーが移動中かどうかを判断できない場合、早い移動速度と最も近いジオフェンスまでの距離に比例した時間内に追跡エラーを送信する必要があります。 [最も近いフェンス境界までの距離 (m) / 343 (m/s)] 以内にエラーを送信することが推奨されます。

• GNSS エンジンがジオフェンス追跡状態エラーを報告した期間中、HLOS に送信されるジオフェンス違反イベントはありません。

• HLOS は、以前に作成されたすべてのジオフェンスを 1 つのコマンドで削除することで、ジオフェンス追跡をリセットできます。

• モバイルで発生したジオフェンスは、再起動またはドライバーの再起動後に GNSS ハードウェアまたはドライバーには保持されません。 HLOS はエンド ユーザー アプリケーションに代わって永続化を処理し、必要に応じてジオフェンスを作成/削除します。

GNSS アダプターとジオフェンシング オフロードをネイティブにサポートする GNSS エンジンの対話に関しては、ジオフェンス追跡が失敗した場合に GNSS アダプターは次のように動作します。

• GNSS ドライバーが追跡の失敗を返すと、AP ベースの追跡を使用します。

• OS レベルで現在追跡されているジオフェンスの更新 (追加/削除) が同期されるように、これらの更新をドライバーにもプッシュし続けます。これにより、GNSS エンジンは、OS によって現在追跡されているジオフェンスを把握することができ、新しいデータに基づいて追跡可能かどうかを判断できます。

• GNSS ドライバーが追跡機能での SUCCESS を返すと、AP ベースのトラッカーによって決定されたジオフェンス状態変更をプッシュします。

支援データとヘルパー データに関するドライバーの通知

GNSS ドライバーは、GNSS アダプターからの支援データやヘルパー アクションを必要とする場合があります。 これには、さまざまな形式の AGNSS データ (時間挿入、天体歴、初期粗位置)、ネットワークによって開始されたユーザー プレーン測位をサポートするためのユーザー同意ポップアップなどが含まれます。

• GNSS 支援データは、GNSS アダプターを使用しなくても GNSS ドライバーが取得できます。 ただし、いくつかの理由から、支援データは、GNSS アダプターを使用し、Microsoft 測位サービスを利用して取得することをお勧めします。

  • Microsoft 位置情報スタックは、データ接続の確立とローミング制約の遵守、データの基本設定、Net Quiet モードの統合などに対応します。

  • Microsoft 測位サービスでは、サーバー間のバックエンド接続を介して IHV に固有の支援データを定期的に取得し、必要なすべてのデバイスにそれを提供できるため、IHV は可用性、拡張性、応答性の要件を満たすフロントエンド支援サービスを世界中に展開する必要がなくなります。

• 受信トレイ アプリケーションのプライバシーに関するユーザーの同意は、オペレーティング システムが所有します。 したがって、ネットワークによって開始された位置情報要求についてユーザーに通知する UI、またはネットワークによって開始された位置情報要求に応答するためにユーザーに同意を求める UI は、Microsoft が所有することになります。 GNSS ドライバーはネットワークによって開始された位置情報要求を受信すると、GNSS アダプターに通知し、必要に応じて、要求の実行に進む前に既定の時間までユーザーからの応答を待ちます。

GNSS ドライバーは上位層への要求を独自に開始することができないため、この種の操作は、GNSS アダプターが GNSS ドライバーからのこのような要求を事前に探すことによって、保留中の 1 つ以上の IRP を常に保持し、GNSS ドライバーがこのような保留中の要求に応答できるようにすることで達成できます。 支援/ヘルパー データの要求を受信すると、GNSS アダプターはデータをフェッチし (または、GNSS ドライバーに代わって特定のアクションを実行し)、その後、別の DeviceIoControl 呼び出しを通じて、必要な情報を GNSS ドライバーに挿入します。

ドライバーからの通知は、共通のイベント モデルを通じて処理されます。 たとえば、GNSS 支援の場合、GNSS アダプターは IOCTL_GNSS_LISTEN_AGNSS 制御コードを使用して、GNSS ドライバーから AGNSS 要求を受信します。 その後、GNSS アダプターは AGNSS 支援データをフェッチし、IOCTL_GNSS_INJECT_AGNSS を発行してデータを GNSS ドライバーにプッシュします。

この通知メカニズムは、ジオフェンス関連のアラート データと状態の更新を受信する際にも使用されます。 アダプターは、IOCTL_GNSS_LISTEN_GEOFENCE_ALERT 制御コードを使用して、個々のジオフェンス アラートを受信し、IOCTL_GNSS_LISTEN_GEOFENCES_TRACKINGSTATUS を使用して、ジオフェンス追跡の全体的な状態の変更を受信します。

全地球航法衛星システム (GNSS) ドライバーのログ記録

診断の目的で、GNSS ドライバーは、以下に説明する Microsoft が規定したログ メカニズム (WPP) または ETW を使用して、エラーや他の診断情報をログに記録する必要があります。 どちらのメカニズムもサポートされていますが、ドライバーではログ記録に ETW ではなく WPP を使用することをお勧めします。 WPP が推奨される理由の 1 つは、ドライバーのデバッグに役立つツールを利用できることです。

ドライバーは、人間が判読できるかどうかに関わらず、この規定のログ記録手法以外の方法で情報をログに記録することはできません。 詳細については、「WPP ソフトウェア トレース」を参照してください。

WPP ソフトウェア トレースを使用したメッセージのログ記録は、Windows イベント ログ サービスの使用と似ています。 ドライバーは、メッセージ ID と書式設定されていないバイナリ データをログ ファイルに記録します。 その後、後処理プログラムはログ ファイル内の情報を人間が判読できる形式に変換します。 ただし、WPP ソフトウェア トレースでは、イベント ログ サービスでサポートされる形式よりも高い能力と柔軟性を備えたメッセージ形式がサポートされています。 たとえば、WPP ソフトウェア トレースには、IP アドレス、GUID、システム ID、タイム スタンプ、およびその他の便利なデータ型が組み込まれています。 さらに、ユーザーはアプリケーションに関連するカスタム データ型を追加できます。

携帯電話会社のプロトコルのサポート

IHV が提供する GNSS スタック (GNSS ドライバー、GNSS デバイス/エンジン) では、携帯電話会社のさまざまな測位プロトコル (SUPL、UPL、CP など) をサポートする必要があります。 そうしないと、そのデバイスは携帯電話会社の承認が得られず、デバイスを商品化できる場所が大幅に制限されます。

特定の携帯電話会社向けのデバイスを出荷するには、これらのプロトコルのサポートと携帯電話会社の要件への準拠が必須となります。 携帯電話以外のほとんどのプラットフォームでは (特に、そのプラットフォームでモバイル ブロードバンド (MBB) がサポートされていない場合)、携帯電話会社のプロトコルのサポートは必須ではない場合があります。

実装のすべての部分は IHV スタックで抽象化され、Microsoft HLOS コンポーネントは以下に依存しません。

• プロトコルの具体的な実装の詳細 (プロトコルのしくみ、プロトコル メッセージの解釈など)。

• 実装スタックの構造 (たとえば、実装は、GNSS デバイス/エンジン、GNSS ドライバー、または必要に応じて別の HLOS サービス内に配置できます)。

• プロトコルを実装するための、IHV 所有の GNSS スタック内のさまざまな要素間の相互作用。 たとえば、GNSS ドライバーが特定の SUPL プロトコル メッセージに応答するために Wi-Fi スキャン結果を必要とする場合は、ユーザーモード拡張機能を使用して、プライベート IOCTL 呼び出しを通じて Wi-Fi スキャン結果をドライバーに挿入するか、これを UMDF 2.0 ドライバーの一部とするか、この相互作用を下位レベルで処理します。 Microsoft GNSS HLOS コンポーネントには、IHV GNSS スタック コンポーネント間のこのような相互作用は認識されません。

要約すると、IHV または OEM は、SUPL クライアント (システムが中国で出荷される場合は、UPL クライアントの可能性もあります) を提供し、それを GNSS ドライバーと統合する必要があります。 位置情報プラットフォームと SUPL クライアントのすべての対話は、GNSS DDI を介して行われます。

携帯電話会社のプロトコルの実装を容易にし、プラットフォーム固有のテクノロジを使用したソフトウェア開発の負担を軽減するために、GNSS アダプターは IHV GNSS スタックに特定の機能を提供します。 GNSS ドライバーは、HLOS コンポーネントからそのような機能を受け取るための仲介役として扱われます。たとえば、GNSS アダプターは GNSS ドライバーとのみ対話し、IHV GNSS スタックのその他の部分とは対話しません。 GNSS ドライバーの IOCTL では、GNSS ドライバーと GNSS アダプター間のこのような機能の構文とセマンティクスを定義します。 GNSS ドライバーは、携帯電話会社のプロトコルを実装する特定の IHV コンポーネントにルーティングする役割を担います。 大まかに言うと、GNSS アダプターは GNSS ドライバーに次の機能を提供します。

1. 構成: 携帯電話会社はデバイスをプロビジョニングし、OMA プロトコル標準によって課される構成メカニズムを使用して構成を変更します。 たとえば、SUPL 標準では、SUPL の構成は、UICC に基づいて行うか、OMA-DM または OMA-CP を介して取得した SUPL OMA 構成プロファイル情報を使用して行うことが求められます。

   構成の目的で携帯電話で使用できる特定の機能 (OMA-DM および OMA CP) は、Windows 10 まで他のプラットフォームでは使用できませんでした。 Windows 10 以降では、新しい GNSS DDI が使用されている限り、すべてのプラットフォームで SUPL 構成サービス プロバイダー (CSP) を介して SUPL 構成をサポートできます。 CSP を介して導入されるプロビジョニングは、(provxml またはマルチバリアントを使用して) イメージ自体から取得することも、OMA-DM または OMA-CP を介して携帯電話会社から取得することもできます。 SUPL CSP は SUPL CSP で定義されています。

   Windows 10 では、構成データを解釈および抽出するために、独自のテクノロジである、構成サービス プロバイダー (CSP) を使用したデバイス管理が定義されています。 Microsoft では、OMA 構成を使用し、GNSS アダプターを介して GNSS ドライバーに構成をプッシュするための CSP を提供しています。

   または、IHV は携帯電話固有のデバイス管理テクノロジ (CSP) を使用して、携帯電話会社の構成仕様を使用するユーザーモード コンポーネントを作成することもできます。 ただし、IHV の負担が増えるため、これは推奨されません。

   デュアル SIM デバイスの場合も含め、システムでサポートされる SUPL 構成は 1 つだけです。 Microsoft では、UICC と UICC の変更に基づいて SUPL を再構成する機能を提供しています。 これに加えて、デバイスのローミングの場合、HLOS はスタンドアロン モードで動作するように SUPL クライアントを再構成します。 このドキュメントでは、さまざまなモバイル操作プロトコル (SUPL 1.0/2.0、v2UPL など) に対してこのような構成データをプッシュするための IOCTL を定義します。

2. NI 要求に対するユーザーの同意の処理: プライバシー要件を満たすために、ネットワークによって開始される特定の測位要求にはユーザーの同意が必要です。 IHV がプラットフォーム コンポーネントの UI を作成することは許可されていません。 そのため、GNSS アダプターが GNSS ドライバーに代わってユーザーの同意のための UI を処理します。 GNSS ドライバーが UI ポップアップを要求するための通知 IOCTL と、GNSS アダプターがこのような要求に対するユーザーの応答を伝えるための IOCTL は、GNSS ドライバーの IOCTL で定義されています。

完全に機能する SUPL クライアントを実装するために、IHV スタックでは、OS プラットフォーム内で、または OS プラットフォームを介して使用できるインターフェイスや一般的な機能を使用する必要があります。 Windows 10 で提供され、IHV が SUPL クライアントを実装するために利用できる機能を次に示します。

この機能はいずれも位置情報プラットフォームまたは GNSS DDI の一部ではありませんが、明確にするためと、GNSS ドライバーの開発者が SUPL 機能を実装するために OS から利用できるものを理解しやすくするために、ここに記載されています。

• SMS ルーター: SMS ルーターにより、SUPL クライアントは SUPL NI 要求を伝える SIP Push メッセージの WAP Push をサブスクライブできます。

• SUPL と API がこのような接続を要求する際に使用すべき接続を構成する接続マネージャー機能: 携帯電話会社は、専用接続、つまり既定のインターネット接続とは異なる接続でのみ SUPL トラフィックを使用することが必要な場合があります。 これを行うために、接続マネージャーは以下を提供します。

  • OEM または携帯電話会社が、SUPL 通信の目的で使用すべき接続を構成するために使用できる構成サービス プロバイダー。

  • SUPL クライアントが SUPL 接続の接続パラメーターを照会するための API。

  • 前の手順で取得したパラメーターを使用して、SUPL 接続を確立する API。

• 携帯電話接続の構成: SUPL 接続のパラメーターなど、さまざまな携帯電話接続のパラメーターを構成するために、OEM または携帯電話会社が使用できる構成サービス プロバイダーがあります。 この接続は、接続マネージャーで SUPL の目的に関連付けることができます。

• SUPL 接続の進行中に接続をアクティブに保つ要求: SUPL クライアントは、システムがコネクト スタンバイ状態の間に、HSLP との接続を開始することが必要な場合があります。 この状況は、GNSS デバイスが Microsoft ベースの測位を使用するように構成されている場合に支援情報を取得する必要があるため、または携帯電話会社が NI 要求を送信したために発生する可能性があります。 その場合、SUPL クライアントは HSLP との接続を開始し、SUPL セッションが完了するまで接続がアクティブであることを保証する必要があります。

• モバイル ブロードバンド (MBB) モジュールとの対話: Windows 10 には、携帯電話の測定値を取得したり、緊急通話がいつ行われたかを把握したりするために、HLOS を介して使用できる API はありません。 MBB との対話は、(AT コマンドまたは他の独自の方法を使用して) MBB との直接統合によって行う必要があります。

製造テスト

OEM は、GNSS ハードウェアと GNSS スタック (GNSS ドライバーと GNSS デバイス/エンジン) が正しく動作していることを、製造時とカスタマー サポート時に検証する方法を用意する必要があります。 IHV は、OEM がこのテストを実行できるようにする独自のメカニズムを提供することも、必要に応じて、OEM が製造テストを開始して結果を取得できるようにするためのインターフェイスを DDI に実装することもできます。

製造テストではハードウェアの検証またはドライバーの検証に重点を置くため、テストの実行時に位置情報フレームワークはバイパスされます。 一般に、デバイスは、コンポーネントとサービスの最小セットが読み込まれる特別な "オペレーティング システム セーフ モード" になります。 このモードでは、OEM はテスト ケースをトリガーする一連のテスト アプリケーションを開始できます。 製造時の効率とスピードを高めるために、さまざまなコンポーネント内でのテストの同時実行をサポートすることが強く望まれます。

製造テストのインターフェイスには、次の 2 種類のテストが含まれています。

1. 搬送波テスト: このテストは、外部接続/アンテナ テストを検証することを目的としています。 このテストでは、GNSS エンジンが CW 信号を検索し、応答で SNR (信号対雑音比または搬送波対雑音比) の測定値を提供する必要があります。 テストでは 10 Hz で応答を返すのが理想的です。

2. 自己テスト: このテストは、GNSS エンジンの基本的な機能を検証することを目的としています。 自己テストでは、エンジンの基本的な問題 (ハードウェアの欠陥、外部信号の挿入を必要としない GNSS ハードウェアの接続不良) を検出できます。 この検証の目的は、デバイスがより包括的でコストのかかるテストを受ける前に、この安価なテストを行い、製造ラインのゲートとして使用することです。 このテストでは、GNSS エンジンとドライバーがピン接続の自己検証を行い、すべて問題ないことまたはエラーが発生したことを示す状態コードを返す必要があります。 エラーのエラー コードで検出されたエラーを示す必要があります。 エラー コードは IHV が設定します。

I/O に関する考慮事項

GNSS 機能は、デバイス ドライバーに対する従来のファイルの読み取り/書き込み要求にはマップされないため、ReadFile 関数と WriteFile 関数は GNSS ドライバー API には使用されません。 すべての GNSS 機能は、明確に定義された GNSS 固有のデバイス I/O 制御 (DeviceIoControl) 要求 (IOCTL とも呼ばれます) を使用して実装されます。

すべての IOCTL で、入力データと出力データの両方のデータ転送メカニズムとして METHOD_BUFFERED が使用されます。 GNSS 関連のデータのサイズは比較的小さいため、余分なバッファー コピーがシステムのパフォーマンスに影響を及ぼすことはありません。

GNSS ドライバーは、CreateFile 関数の FILE_FLAG_OVERLAPPED オプションを使用して開かれます。 そのため、すべての IOCTL は暗黙的に非同期です。 ただし、ほとんどの GNSS IOCTL は意味的には非同期ですが (たとえば、IOCTL がドライバー内のアクティビティをトリガーすると、結果が非同期で返されます)、一部の IOCTL は、それらの IOCTL に関連する論理的な非同期アクションまたはアクティビティが存在しないという意味で意味的には同期です。 これらの一部の IOCTL の同期動作は、DeviceIoControl 呼び出しの発行後、I/O 操作が完了するまで GNSS アダプター スレッドをブロックすることで実現されます。 したがって、GNSS ドライバーが、すべての IOCTL の処理の一環として IRP を常に完了する必要があります。 GNSS アダプターには同期呼び出しのコントラクトを優先することが求められるので、エラーが発生した場合は、これらのコマンドを再試行することもあればしないこともあります。 IHV ドライバーはエラーを返す前に、ドライバー側のすべてのロジックが組み込まれていることを確認する必要があります。

要求操作と応答操作では、GNSS ドライバーに、以前に呼び出された操作への応答として送信するデータがある場合に、保留中の IRP を使用してその応答を送信できるように、GNSS アダプターは保留中の I/O 操作を常に使用可能な状態にしておきます。

シングル ショット セッション

ドライバーに対するシングル ショット修正の修正開始要求には、精度と応答時間の値が含まれます。 GNSS エンジンは、これらの値を使用してアプリケーション要求の意図を理解し、インテリジェントな決定を行うことができます。 ドライバーは要求を受信したら、エンジンによって生成された中間修正を返し始める必要があります。 中間修正は、精度要件を満たす修正または最終的な修正の計算中にエンジンによって生成される修正です。 これらの中間修正の頻度は強制されるものではなく、エンジンの実装の詳細です。 GNSS アダプターでは、修正を数秒ごとに受信することを想定しています。これらの修正は、最後の中間修正とは異なります。

GNSS エンジンは、現在の信号状態ではより適切な修正を取得できないと判断したら、最終修正を返し、それ以上の計算の実行を停止する必要があります。 最終修正は、精度要件を満たしているか、エンジンが現在の条件下で提供される精度を改善できないことを示しています。

GNSS アダプターは、次の 2 つのケースのいずれかでシングル ショット セッションの修正停止を発行します。

• ドライバーから最終修正を取得した場合。

• 要求の応答時間に達した場合。 この場合、最後の中間修正がアプリケーションに送信されます。

次の図は、2 つのシングル ショット セッションを示しています。

セッション 1: ドライバーに精度と応答時間のパラメーターが渡されました。 修正開始コマンドの後、ドライバーは中間修正の送信を開始しました。 しばらくすると、ドライバーはより正確な修正を返すことができないと判断したため、最後の修正を最終として示しました。 これは、応答時間の制限に達する前に行われました。 アダプターは最終修正をアプリケーションに送信し、修正停止コマンドを発行しました。

セッション 2: 上記のセッション 1 と同じですが、この場合、エンジンは精度要件を満たすためにより適切な修正を目指し続け、その間に中間修正を送信し続けました。 セッション応答時間の制限に達すると、アダプターはドライバーでのこのセッションを閉じるために修正停止を発行しました。 最後に受信した中間修正がアプリケーションに送信されました。

シングル ショットのサポートを実装する際に考慮すべき設計の重要な側面の 1 つは、距離ベースの追跡セッションと時間ベースの追跡セッションの両方がサポートされているわけではない場合、GNSS エンジンは修正停止コマンドの受信後も 3 秒から 5 秒間は衛星の追跡を続行しなければならないことです。 これは、GNSS アダプターがシングル ショット修正セッションを使用して、シミュレートされた距離ベースの追跡セッションや時間ベースの追跡セッションを実装する必要があるためです。GNSS エンジンが衛星の追跡をすぐに停止した場合、ほとんどの GNSS デバイスで取得に遅延が発生し、ナビゲーション、実行追跡、またはアプリケーションのマッピングのニーズを満たすシミュレートされた追跡セッションを実装することができなくなります。

GNSS アダプターは、システムがアクティブなときだけでなく、コネクト スタンバイ状態の間も、シングル ショット修正の要求を開始する場合があります。 これは、バックグラウンド タスク、システム サービス、アプリケーション プロセッサでのジオフェンス追跡などのニーズを満たすために行われる可能性があります。 GNSS ドライバーは、これらのセッション要求を GNSS デバイスに渡し、要求を満たすか、GNSS アダプターにエラーを返すことができる必要があります。

次のシーケンス図は、スタンドアロンの GNSS 修正の取得に関連する大まかなアクションを示しています。 これには支援データの要求は含まれていません。

このシーケンスについて以下に説明します。

1. GNSS アダプターは、CreateFile API を使用して GNSS ドライバーを開きます。 WDF/KMDF/UMDF は、GNSS ドライバーに対して必要なオプションのコールバックを実行します。 返されたファイル ハンドルは、以降のすべての操作に使用されます。

2. GNSS アダプターは IOCTL を発行して、さまざまなプラットフォーム機能をドライバーに伝えます。 GNSS ドライバーは I/O 操作を完了します。

3. GNSS アダプターは、デバイス機能を取得するために IOCTL を発行します。 GNSS ドライバーはデバイス機能を返し、I/O 操作を完了します。

4. GNSS アダプターは、ドライバー固有の構成またはコマンドのために IOCTL を発行します。 GNSS ドライバーは必要なアクションを実行し、I/O 操作を完了します。

5. GNSS アダプターは、修正の種類や他の側面を指定したパラメーターと共に、IOCTL_GNSS_START_FIXSESSION を発行します。 この IOCTL を受信すると、GNSS ドライバーは基になるデバイスと対話して修正の受信を開始し、その後、I/O 操作を完了します。

6. GNSS アダプターは IOCTL_GNSS_GET_FIXDATA を発行し、I/O の完了を待ちます。 GNSS ドライバーは、使用可能な中間修正がある場合は常に I/O 操作を完了してデータを返します。

7. GNSS ドライバーがこれ以上修正を期待できないこと (最終修正を受信したこと) を示すまで、手順 6 が繰り返されます。

8. GNSS アダプターは、IOCTL_GNSS_STOP_FIXSESSION を発行します。 GNSS ドライバーは、元の修正要求に関連付けられている必要なクリーンアップ操作を実行します。

9. GNSS アダプターは、CloseHandle API を使用してドライバー ファイル ハンドルを閉じます。

GNSS IOCTL および関連するデータ構造体については、GNSS ドライバー リファレンスで詳しく説明されています。

距離ベースの追跡セッション

距離ベースの追跡セッションは、従来、.NET API で使用できる唯一のセッションの種類であったため、エンド ユーザー アプリケーションで頻繁に使用されます。 距離値 0 は、GNSS エンジンが可能な限り高速で修正を提供する必要があることを示します。

GNSS アダプターは、GNSS ドライバーが SupportDistanceTracking 機能を備えていることを示している場合にのみ、GNSS ドライバーとの距離追跡セッションを開始します。

距離追跡セッションのためのドライバーへの修正開始要求には、必要な水平精度と移動しきい値が含まれます。移動しきい値は、GNSS ドライバーが位置の更新を提供する前にシステムがカバーしなければならない半正矢距離 (メートル単位) です。 GNSS エンジンは、これらの値を使用してアプリケーション要求の意図を理解し、位置を確認する頻度への適応など、インテリジェントな決定を行うことができます。

ドライバーは、修正開始要求を受信したら、最終修正を取得するまで、エンジンによって生成された中間修正を返し始める必要があります。 これがセッションの最初の位置と見なされます。 この後、GNSS エンジンは半正矢距離がほぼカバーされていることを検出するたびに、修正の提供を開始する必要があります。

GNSS エンジンは、デバイスの位置をもう追跡できないと判断した場合 (衛星が視認できなくなった場合など)、位置情報プラットフォームが他のメカニズムにフォールバックして、エンド ユーザー アプリケーションに位置の更新を提供できるように、GNSS アダプターにエラーを返す必要があります。 GNSS アダプターは、次の時間内にエラーを返す必要があります。

[(最後の既知位置からの残りの距離 (m) / 推定速度 (m/s)) – 5 秒] または 5 秒のどちらか大きい方。

GNSS エンジンが GNSS アダプターにエラーを返しても、GNSS アダプターが追跡セッションをまだ停止していない場合、GNSS エンジンは電力に最適化された方法でチェックを続行する必要があります (位置の追跡を再開できる場合)。 IHV は最適化を使用することで、この検出を低電力で行うことができます。 最適化の一般的な手法は次のとおりです。

• プログレッシブ バックオフ

• 再チェックのために、デバイスの動きを示す低コストの信号を待機

• 衛星信号の低電力チェック

GNSS エンジンは、エラー状態の後に最終修正をもう一度提供できるようになると、その位置を GNSS アダプターに送信して、追跡が正常に再開されたことを示します。

追跡セッションを要求していた 1 つ以上のアプリケーションが要求を取り消した場合、または新しいアプリケーションが距離ベースの追跡セッションを要求している場合、GNSS アダプターは距離ベースの追跡セッションの修正変更コマンドを発行します。 このような場合、GNSS アダプターはさまざまなアクティブ セッションを多重化するために必要な新しいセッション集約パラメーターを計算し、これらのパラメーターで GNSS ドライバーを更新します。

次の場合に、GNSS アダプターは距離ベースの追跡セッションの修正停止コマンドを発行します。

• 追跡セッションが、システムで使用可能な別の測位エンジンに引き渡された場合。

• 追跡セッションを要求していたアプリケーションが要求を取り消した場合。

次の図は、2 つの距離ベースの追跡セッションを示しています。

セッション 1: 追跡セッションの開始時に、GNSS ドライバーに精度と移動しきい値のパラメーターが渡されます。 修正開始コマンドの後、ドライバーは最終修正または精度要件を満たす修正を取得するまで中間修正の送信を開始します。このような修正を取得した時点で、修正が GNSS アダプターに提供され、GNSS エンジンは距離追跡プロセスを開始します。 セッションがアクティブな間、GNSS アダプターは T1 および T2 の時点でセッション パラメーターの変更要求を送信します。 パラメーターの変更が行われるたびに、GNSS ドライバーは GNSS アダプターに修正の更新を送信し、GNSS アダプターが修正停止コマンドを送信するまで、新しいパラメーターで距離追跡セッションを再開します。

セッション 2: セッション開始プロセスは上記のセッション 1 に似ていますが、特定の時点で GNSS エンジンは位置を追跡できなくなります。 距離と推定移動速度に応じた時間が経過すると、GNSS ドライバーはエラーを送信します。 GNSS エンジンは、回復可能であれば低電力でチェックを続行し、回復すると、新しい修正を送信して GNSS アダプターにそれを示します。 GNSS アダプターが修正停止コマンドを送信するまで、セッションは必要に応じて新しい修正で更新されます。

GNSS アダプターは、システムがアクティブなときだけでなく、コネクト スタンバイ状態の間も、アクティブな状態を維持したり、距離ベースの追跡セッションを開始したりする場合があります。 これは、バックグラウンド タスク、システム サービス、アプリケーション プロセッサでのジオフェンス追跡などのニーズを満たすために行われる可能性があります。 GNSS ドライバーは、これらのセッション要求を GNSS デバイスに渡し、要求を満たすか、GNSS アダプターにエラーを返すことができる必要があります。

時間ベースの追跡セッション

時間ベースの追跡セッションは、ユーザー インターフェイスを更新するために頻繁かつ定期的な位置の更新を必要とするアプリケーション (マップ、ナビゲーション アプリケーションなど) で使用できます。

GNSS アダプターは、GNSS ドライバーが SupportContinuousTracking 機能を備えていることを示している場合にのみ、GNSS ドライバーとの時間ベースの追跡セッションを開始します。

時間ベースの追跡セッションのためのドライバーへの修正開始要求には、必要な水平精度と GNSS ドライバーが位置の更新を提供する際の優先時間間隔が含まれます。 GNSS エンジンは、これらの値を使用してアプリケーション要求の意図を理解し、インテリジェントな決定 (位置をチェックする頻度に適応する、位置の更新をタイムリーに提供するために間隔の数秒前に衛星の取得を開始するなど) を行うことができます。

ドライバーは、修正開始要求を受信したら、最終修正を取得するまで、エンジンによって生成された中間修正を返し始める必要があります。 これがセッションの最初の位置と見なされます。 この後、GNSS エンジンはセッション パラメーターで要求された間隔で修正の提供を開始する必要があります。 GNSS エンジンは、アプリケーションに必要な頻度で位置を提供できない場合、最大限の速度で修正を提供する必要があります。

GNSS エンジンは、デバイスの位置をもう追跡できないと判断した場合 (衛星が視認できなくなった場合など)、位置情報プラットフォームが他のメカニズムにフォールバックして、エンド ユーザー アプリケーションに位置の更新を提供できるように、GNSS アダプターにエラーを返す必要があります。

GNSS エンジンが GNSS アダプターにエラーを返しても、GNSS アダプターが追跡セッションをまだ停止していない場合、GNSS エンジンは電力に最適化された方法でチェックを続行する必要があります (位置の追跡を再開できる場合)。

前のセクションで説明したように、IHV は最適化を使用することで、この検出を低電力で行うことができます。 GNSS エンジンは、エラー状態の後に最終修正をもう一度提供できるようになると、その位置を GNSS アダプターに送信して、追跡が正常に再開されたことを示します。

追跡セッションを要求していた 1 つ以上のアプリケーションが要求を取り消した場合、または新しいアプリケーションが時間ベースの追跡セッションを要求している場合、GNSS アダプターは時間ベースの追跡セッションの修正変更コマンドを発行します。 このような場合、GNSS アダプターはさまざまなアクティブ セッションを多重化するために必要な新しいセッション集約パラメーターを計算し、これらのパラメーターで GNSS ドライバーを更新します。

次の場合に、GNSS アダプターは時間ベースの追跡セッションの修正停止コマンドを発行します。

• 追跡セッションが、システムで使用可能な別の測位エンジンに引き渡された場合。

• 追跡セッションを要求していたアプリケーションが要求を取り消した場合。

次の図は、2 つの時間ベースの追跡セッションを示しています。

セッション 1: 追跡セッションの開始時に、GNSS ドライバーに精度と優先間隔のパラメーターが渡されます。 修正開始コマンドの後、ドライバーは最終修正または精度要件を満たす修正を取得するまで中間修正の送信を開始する必要があります。このような修正を取得した時点で、修正が GNSS アダプターに提供され、GNSS エンジンは時間ベースの追跡プロセスを開始します。 セッションがアクティブな間、GNSS アダプターは T1 および T2 の時点でセッション パラメーターの変更要求を送信します。 パラメーターの変更が行われるたびに、GNSS ドライバーは GNSS アダプターに修正の更新を送信し、GNSS アダプターが修正停止コマンドを送信するまで、新しいパラメーターで時間ベースの追跡セッションを再開します。

セッション 2: セッション開始プロセスは上記のセッション 1 のプロセスに似ていますが、特定の時点で GNSS エンジンは位置を追跡できなくなります。 GNSS エンジンがセッション パラメーターで要求された 15 秒間隔内に修正を提供できない場合、GNSS ドライバーはエラーを送信します。 GNSS エンジンは、回復可能であれば低電力でチェックを続行し、回復すると、新しい修正を送信して GNSS アダプターにそれを示します。 GNSS アダプターが修正停止コマンドを送信するまで、セッションは必要に応じて新しい修正で更新されます。

GNSS アダプターは、システムがアクティブなときだけでなく、コネクト スタンバイ状態の間も、アクティブな状態を維持したり、時間ベースの追跡セッションを開始したりする場合があります。 これは、バックグラウンド タスク、システム サービス、アプリケーション プロセッサでのジオフェンス追跡などのニーズを満たすために行われる可能性があります。 GNSS ドライバーは、これらのセッション要求を GNSS デバイスに渡し、要求を満たすか、GNSS アダプターにエラーを返すことができる必要があります。

異なる種類の修正セッションの同時処理

一部の高度な GNSS エンジンでは、距離ベースまたは時間ベースの追跡セッションとシングル ショット セッションを同時に処理できる場合があります。 独立したセッションは相互に影響を与えないようにするのが理想的ですが、特にシングル ショット セッションと時間ベースの追跡セッションを同時に実行する場合、これは常に可能であるとは限りません。 このセクションでは、さまざまな種類の同時セッションを処理するために妥協する必要がある場合に備えて、IHV の実装に関するガイドラインを示します。

このセクションでは、次の頭字語を使用します。

• SS: シングル ショット セッション

• DBT: 距離ベースの追跡セッション

• TBT: 時間ベースの追跡セッション

• TBF: 修正間隔

次の表に、シングル ショット セッションと時間ベースの追跡セッションを同時に処理するシナリオをいくつか示します。

ケース	SS はアクティブか?	TBT はアクティブか?	サポート案件の詳細	修正の許容間隔	コメント
1	x	x	タイムアウトの残り時間 >= 間隔の状態で定期的な TBT セッションが開始された時点で SS セッションが進行中	TBT の間隔と同じ	SS セッションの動作: タイムアウトまで中間修正と最終修正が送信されます。 セッションは、停止の受信直後に閉じられます。 TBT セッションの動作: 中間修正と最終修正が送信されます。 ほぼ間隔どおりに修正を受信します。 セッションは、停止の受信直後に閉じられます。
2	x	x	タイムアウトの残り時間 < 間隔の状態で定期的な TBT セッションが開始された時点で SS セッションが進行中	SS セッションが満たされるまで、間隔は SS タイムアウトと同じままになります。 その後、TBT の間隔と同じになるように間隔を更新できます。	SS セッションの動作: タイムアウトまで中間修正と最終修正が送信されます。 セッションは、停止の受信直後に閉じられます。 TBT セッションの動作: 中間修正と最終修正が送信されます。 ほぼ間隔どおりに修正を受信しますが、SS セッションが提供されている間は頻度が増える可能性があります。 セッションは、停止の受信直後に閉じられます。
3	x	x	タイムアウト >= 間隔の状態で開始された定期的な TBT セッションの進行中に SS セッションが開始された	TBT の間隔と同じ	SS セッションの動作: タイムアウトまで中間修正と最終修正が送信されます。 セッションは、停止の受信直後に閉じられます。 TBT セッションの動作: 中間修正と最終修正が送信されます。 ほぼ間隔どおりに修正を受信します。 セッションは、停止の受信直後に閉じられます。
4	x	x	タイムアウト < 間隔の状態で開始された定期的な TBT セッションの進行中に SS セッションが開始された	SS セッションが満たされるまで、SS タイムアウトと同じになるように間隔が変更されます。 その後、TBT の間隔と同じになるように間隔を更新できます。	SS セッションの動作: タイムアウトまで中間修正と最終修正が送信されます。 セッションは、停止の受信直後に閉じられます。 TBT セッションの動作: 中間修正と最終修正が送信されます。 ほぼ間隔どおりに修正を受信しますが、SS セッションが提供されている間は頻度が増える可能性があります。 セッションは、停止の受信直後に閉じられます。
5		x	間隔が変更された状態で、定期的な TBT セッションが開始された	モデムとのセッションは、TBT の間隔と同じになるように新しい間隔に更新されます。 必要に応じて、モデム セッションが再起動されます。	SS セッションの動作: 適用なし TBT セッションの動作: 中間修正と最終修正が送信されます。 ほぼ間隔どおりに修正を受信します。 セッションは、停止の受信直後に閉じられます。
6	x	x	タイムアウトの残り時間 >= 間隔の状態で、進行中の定期的な TBT セッションが間隔の変更を受信した時点で SS セッションが進行中	TBT の間隔と同じ	SS セッションの動作: タイムアウトまで中間修正と最終修正が送信されます。 セッションは、停止の受信直後に閉じられます。 TBT セッションの動作: 中間修正と最終修正が送信されます。 ほぼ間隔どおりに修正を受信します。 セッションは、停止の受信直後に閉じられます。
7	x	x	タイムアウトの残り時間 < 間隔の状態で、進行中の定期的な TBT セッションが間隔の変更を受信した時点で SS セッションが進行中	SS セッションが満たされるまで、SS タイムアウトの残り時間と同じになるように間隔が変更されます。 その後、TBT の間隔と同じになるように間隔を更新できます。	SS セッションの動作: タイムアウトまで中間修正と最終修正が送信されます。 セッションは、停止の受信直後に閉じられます。/li> TBT セッションの動作: 中間修正と最終修正が送信されます。 ほぼ間隔どおりに修正を受信しますが、SS セッションが提供されている間は頻度が増える可能性があります。 セッションは、停止の受信直後に閉じられます。

時間ベースの追跡セッションと距離ベースの追跡セッションの両方が同時に存在する場合は、2 つのうち精度が低い方で動作するように GNSS エンジンの精度追跡を設定できます。 次の表に、シングル ショット セッションと追跡セッションが同時に存在するときに、異なる精度の値が必要な場合のガイドラインを示します。

ケース	SS の精度	DBT または TBT の精度	GNSS エンジン全体の精度	コメント
1	中/低 --> 高	適用なし	中/低 --> 高	SS セッションの動作: 高精度の結果を得るために、GNSS デバイスとのセッションが更新または再起動されます。 中間修正が使用可能になると、HLOS に提供されます。
2	高 --> 中/低	適用なし	高 --> 中/低	SS セッションの動作: 中/低精度の結果を得るために、GNSS デバイスとのセッションが更新または再起動されます。 要件を満たす修正が既に使用可能な場合は、これが最終修正として返されます。 それ以外の場合は、中間修正が使用可能になると、HLOS に提供されます。
3	中/低 --> 高	高	高	SS セッションの動作: DBT または TBT セッションの高精度セッションが既に存在するため、必要な最終精度を取得するか、最終修正を取得するまで、SS セッションで HLOS に中間修正がさらに提供されます。
4	高 --> 中/低	高	高	SS セッションの動作: DBT または TBT セッションの高精度セッションが既に存在するため、必要な最終精度を取得するか、最終修正を取得するまで、SS セッションで HLOS に中間修正がさらに提供されます。
5	中/低 --> 高	中/低	中/低 --> 高の後、SS セッションが完了したら中/低に戻す	SS セッションの動作: 高精度の結果を得るために、GNSS デバイスとのセッションが更新または再起動されます。 中間修正が使用可能になると、HLOS に提供されます。 DBT または TBT セッションの動作: このセッションで高精度の結果を一時的に受け取るのは問題ありません。 ただし、SS セッションが提供された後、このセッションの精度は中/低に戻る必要があります。
6	高 --> 中/低	中/低	高 --> 中/低	SS セッションの動作: 中/低精度の結果を得るために、GNSS デバイスとのセッションが更新または再起動されます。 要件を満たす修正が既に使用可能な場合は、これが最終修正として返されます。 それ以外の場合は、中間修正が使用可能になると、HLOS に提供されます。
7	適用なし	中/低 --> 高	中/低 --> 高	b>DBT または TBT セッションの動作:** 高精度の結果を得るために、GNSS デバイスとのセッションが更新または再起動されます。 中間修正が使用可能になると、HLOS に提供されます。
8	適用なし	高 --> 中/低	高 --> 中/低	DBT または TBT セッションの動作: 中/低精度の結果を得るために、GNSS デバイスとのセッションが更新または再起動されます。 要件を満たす修正が既に使用可能な場合は、これが最終修正として返されます。 それ以外の場合は、中間修正が使用可能になると、HLOS に提供されます。
9	高	中/低 --> 高	高	DBT または TBT セッションの動作: セッションで高精度の修正または中間修正を既に取得しているので変更はありません。
10	高	高 --> 中/低	高の後、SS セッションが完了したら中/低に変更される	DBT または TBT セッションの動作: SS セッションが完了するまで、セッションで高精度の修正または中間修正を取得し続けることができます。 その後、中/低精度の修正に変更されます。
11	中/低<	中/低 --> 高	中/低 --> 高	DBT または TBT セッションの動作: 高精度の結果を得るために、GNSS デバイスとのセッションが更新または再起動されます。 中間修正が使用可能になると、HLOS に提供されます。
12	中/低	高 --> 中/低	高 --> 中/低	DBT または TBT セッションの動作: 中/低精度の結果を得るために、GNSS デバイスとのセッションが更新または再起動されます。 要件を満たす修正が既に使用可能な場合は、これが最終修正として返されます。 それ以外の場合は、中間修正が使用可能になると、HLOS に提供されます。