共用方式為

全域導覽衛星系統 (GNSS) 驅動程序架構

  • 發行項

提供全域導覽衛星系統 (GNSS) UMDF 2.0 驅動程序架構、I/O 考慮的概觀，並討論數種類型的追蹤和修正會話。

架構概觀

下列高階元件區塊圖顯示全域導覽衛星系統 (GNSS) UMDF 2.0 驅動程式如何與 Windows 10 平臺整合。

顯示使用者模式 gnss 架構的圖表。

圖表中的元件描述如下：

  • LBS 應用程式：使用 Windows 10 平臺位置功能的用戶應用程式

  • 測試應用程式： 用於測試 GNSS 功能的應用程式。

  • GNSS API：IGnssAdapter COM (元件物件模型) 介面，此介面會將 GNSS 裝置的功能公開至位置服務的內部元件，以及測試應用程式。 此 API 的確切形狀超出本檔的範圍。 Windows 元件會針對 IGnssAdapter COM 介面進行程序設計，以使用 GNSS 裝置。 GNSS API 集合是私人 API，僅將平臺元件定位 (，例如，位置服務和位置測試應用程式) ，不適用於其他第一方或第三方應用程式。

  • GNSS 配接器： 這是實作 IGnssAdapter COM 介面的單一 COM 物件。 測試位置服務的應用程式和內部元件具現化此物件，並透過 IGnssAdapter 介面使用 GNSS 裝置。 位置服務的 GNSS 定位引擎元件會實作公開 IGnssAdapter 介面的 COM 類別。 位置服務會公開處理站機制，以測試和其他跨進程應用程式，以具現化位置服務內 GNSS 配接器 COM 類別的單一 COM 物件。 跨進程應用程式會使用 COM 介面指標來針對 GNSS 驅動程式進行程式設計。

    COM 會處理跨進程應用程式的介面指標 Proxy，讓應用程式將 IGnssAdapter 介面指標視為同進程 COM 物件，但呼叫實際上是由位置服務內的單一 GNSS 配接器對象處理。

    GNSS 定位引擎會使用內部 GNSS 配接器物件，為位置服務提供特定位置功能。 GNSS 配接器會使用 CreateFile API 開啟 GNSS 驅動程式的檔案句柄，然後將 GNSS 原生 API 呼叫包裝成適當的 DeviceIoControl 呼叫、使用 GNSS 驅動程式對象維護狀態機器，以及維護來自上層之各種連入要求的狀態。 此元件會透過本文件中定義的公用 GNSS IOCTL 介面，直接與基礎 GNSS 裝置堆疊互動。 GNSS 裝置會以邏輯方式視為獨佔資源，因此單一 GNSS 配接器可控制 GNSS 裝置的所有存取權。

    某些白箱驅動程式測試應用程式也可以直接在非生產環境中使用 GNSS 驅動程式 IOCTL 介面，而不是透過 GNSS 私人 API 使用 GNSS 配接器。 不過，這些測試應用程式必須實作自己的狀態機器和處理，以模擬 GNSS 配接器的特定功能。

  • GNSS 驅動程式： 使用UMDF 2.0實作的IHV傳遞驅動程式。 GNSS 驅動程式透過與實際的 GNSS 硬體互動，支援 GNSS DeviceIoControl API。 GNSS 驅動程式也可作為 SUPL 函式的媒體/整合器。

  • GNSS 裝置/引擎： 這是概念性元件，可封裝 GNSS 裝置的 SoC 和硬體片段。 IHV 可以選擇在此元件內實作大部分的 GNSS 功能，因此 GNSS 驅動程式層非常精簡， (基本上是配接器，以便與 GNSS 裝置) 互動。

支援遵循舊版 Windows 模型的全域導覽衛星系統 (GNSS) 裝置和驅動程式

Windows 10 中的位置平臺支援透過舊版感測器 v1.0 類別驅動程式整合的 GNSS 裝置 (請參閱撰寫位置感測器驅動程式) 或透過 GNSS 驅動程式參考中所述的新 GNSS DDI 整合。

因此，具有與 Windows 7、Windows 8 和 Windows 8.1 中存在感測器 v1.0 類別擴充模型的 GNSS 裝置整合的 Windows 裝置，在不需要進行任何變更的情況下，預期會在 Windows 10 中繼續運作。 強烈建議這些驅動程式 (，以及) 發佈至 Windows Update的任何新驅動程式，以改善使用者的升級程式。

硬體實驗室套件中也會有兩組不同的 GNSS 裝置測試， (HLK) 發出 Windows 10：

  • 一組新的測試，可遵循新的模型來認證驅動程式。

  • 另一組測試，可認證舊模型後面的驅動程式。 這些會是 Windows 8.1 中 WHCK 中提供的相同測試集。

HLK 中的新收集器元件會識別哪兩組測試必須在系統中執行，如果有的話。

顯示 gnss 2.0 驅動程式和配接器通訊的圖表。

全域導覽衛星系統 (GNSS) 裝置共存

在系統中偵測到多個 GNSS 裝置的罕見案例中，位置平臺只會使用一個裝置，主要是減少系統中的整體耗電量。 已考慮下列假設：

  • 使用新 DDI 的裝置可能較新，因此更可能擁有較佳的耗電量、支援更多星座和支援更佳的協助。 因此，如果偵測到使用舊驅動程式型號的裝置，以及使用新驅動程式模型的裝置，後者會是選取的裝置。

  • 如果使用者在內部 GNSS 裝置存在時插入外部 GNSS 裝置，則使用者很可能想要使用此外部裝置。

根據這些假設，位置平台的行為如下：

  • 兩個共存舊版驅動程式的案例：為了避免回溯相容性問題，行為會與在 Windows 8.1 相同，其中兩個 GNSS 裝置同時使用，其中一個回應會與應用程式通訊。

  • 裝置中的一個舊版驅動程式案例和一個新的驅動程式外部插入：會使用外部插入的 GNSS 裝置。

  • 裝置中有一個新的驅動程式和一個新的驅動程式外部插入：會使用外部插入的 GNSS 裝置。

如果選取的 GNSS 裝置支援地理柵欄或其他卸載作業，則會在該裝置使用時完成卸除。 GNSS 配接器不會在多個 GNSS 裝置之間分割功能或會話。

GNSS 配接器與 GNSS 驅動程式之間的互動屬於下列類別：

功能資訊交換

為了在 Windows 平臺上支援 GNSS 堆疊的擴充性和調整性，GNSS 配接器和 GNSS 驅動程式會建立基礎 GNSS 堆疊各種定義完善的功能，以及 Windows 平臺所提供的支援。 Microsoft 已妥善定義功能層面，作為此 GNSS 介面定義的一部分，並隨著 GNSS 空間中的更多創新不斷演進，而且市場會出現各種不同的晶片組/驅動程式。 GNSS 配接器會在初始化時或視需要查詢基礎 GNSS 驅動程式/裝置的各種功能，並據以優化與 GNSS 驅動程式的互動。

GNSS 配接器和 GNSS 驅動程式之間的功能資訊交換是使用控制程式碼 IOCTL_GNSS_SEND_PLATFORM_CAPABILITY 和 IOCTL_GNSS_GET_DEVICE_CAPABILITY來完成。

GNSS 配接器可能會執行 GNSS 驅動程式的一次性設定或定期重新設定。 同樣地，GNSS 配接器可能會透過驅動程式執行特定 GNSS 特定命令。 這可藉由定義驅動程式與高階操作系統之間的命令執行通訊協定來完成， (HLOS) 。 視特定命令類型而定，預期的動作可能會立即生效，或在系統重新啟動之後生效。 與 GNSS 裝置功能資訊類似，GNSS 命令也會由 Microsoft 妥善定義，作為此 GNSS 介面定義的一部分，並持續隨著 GNSS 裝置/驅動程式的未來創新與發展。

裝置命令執行和設定是使用控制程式代碼 IOCTL_GNSS_SEND_DRIVERCOMMAND完成。

位置資訊

這是基礎 GNSS 裝置的主要功能。 以最基本的形式，GNSS 配接器會從 GNSS 驅動程式要求裝置的目前位置。 位置要求的變化包括 (，但不限於) 下列位置會話類型：

  • 裝置目前的位置 (單次修正程式)

  • (時間型追蹤) 的連續定期修正數據流

  • 根據移動閾值的連續修正數據流， (以距離為基礎的追蹤)

每個 GNSS 硬體和 GNSS 驅動程式所需的唯一必要位置會話類型是單次修正會話類型。 在 SOC、GNSS 裝置中實作的原生 (，而不是在 GNSS 驅動程式中，或在應用程式處理器中執行的服務) 、以時間為基礎的追蹤會話，以及以距離為基礎的追蹤會話，可以選擇性地支援。 這兩種類型的原生追蹤會話的主要優點是讓應用程式處理器 (AP) 休眠時間較長，藉由在 SOC 中執行更多處理，並在需要時只報告變更，來節省電力。 原生距離追蹤的支援比原生時間型追蹤會話更具影響力，因為它可以節省更高的電源，而且應用程式會更廣泛地使用。

從 GNSS 驅動程式擷取位置資訊的行為會透過具狀態的唯一修正會話進行，其中包含下列動作：

  1. 啟動修正會話： GNSS 配接器會起始啟動修正會話 (，因為 LBS 應用程式的要求) 。 GNSS 配接器會設定與要求的特定需求和喜好設定關聯，並讓 GNSS 驅動程式啟動引擎以透過發出控制程式代碼 IOCTL_GNSS_START_FIXSESSION來取得修正程式。

  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) 型地理柵欄追蹤引擎;雖然此解決方案不像原生解決方案一樣強大，但經過妥善測試和優化，因此不應由在 API 中實作的對等解決方案取代。

HLOS 的地理柵欄追蹤需要應用程式處理器定期喚醒以偵測地理柵欄缺口，藉此清空電源，即使柵欄未遭到入侵也一般。 因此，此實作會被視為次佳。

當基礎驅動程式因低訊號狀況或其他暫時性錯誤而無法追蹤地理柵欄時，HLOS 也會在從原生地理柵欄追蹤解決方案收到的錯誤通知時，使用 AP 型地理柵欄追蹤作為故障轉移機制。 原生地理柵欄支援只有在地理柵欄追蹤完全卸除至 SoC，且應用程式處理器只會喚醒處理地理柵欄相關事件時，才有説明。 如果硬體不支援原生地理柵欄追蹤，GNSS 驅動程式不得嘗試在驅動程式層實作。

GNSS 引擎也必須公開記載的 IHV 特定微調參數，以在耗電量和用戶體驗之間尋找正確的平衡。 此外，支援的地理柵欄數目應該大於頭檔中定義的 MIN_GEOFENCES_REQUIRED 值。 請注意， MIN_GEOFENCES_REQUIRED 定義於每個應用程式，因為一個應用程式不知道其他應用程式或電信業者所使用的地理柵欄數目。

地理柵欄卸除支援涉及下列需求：

  • HLOS 應該能夠透過 DDI 建立一或多個地理柵欄，而驅動程式會將其傳送至硬體，以開始追蹤它們。

  • HLOS 應該能夠透過 DDI 刪除一或多個先前建立的地理柵欄，而驅動程式會將其傳送至硬體以停止追蹤它們。

  • 在理想情況下，GNSS 硬體應該瞭解每個地理柵欄的初始地理柵欄追蹤狀態，並使用它只報告來自此初始狀態的變更。 如果 GNSS 硬體不支援此功能，則每次建立地理柵欄時，都會向 HLOS 報告初始狀態。

  • GNSS 硬體會以有電源效率的方式追蹤裝置的目前位置，並在裝置進入和/或結束追蹤的地理柵欄時喚醒 AP。 GNSS 驅動程式會將地理柵欄警示傳遞給 HLOS。

  • 在低衛星訊號和其他暫時性錯誤狀況下，GNSS 引擎可能無法可靠地追蹤現有的地理柵欄。 GNSS 引擎應該能夠偵測追蹤中斷，而 GNSS 驅動程式應該會將追蹤狀態錯誤警示傳遞給 HLOS。 HLOS 會切換至預設AP型地理柵欄追蹤，直到 GNSS 硬體能夠再次復原和追蹤地理柵欄為止。

  • GNSS 引擎必須提供通知以指出無法追蹤地理柵欄的確切條件會有所不同，而實作會是 IHV 特定的。 以下是實作的一些指導方針：

    • 如果 GNSS 引擎能夠偵測到使用者未移動，且 GNSS 引擎在 25 公尺內沒有地理柵欄界限，則 GNSS 引擎不需要傳送追蹤錯誤。

    • 如果 GNSS 引擎能夠偵測到使用者未移動，但地理柵欄界限在 25 公尺以下，則 GNSS 引擎必須在一分鐘內傳送追蹤錯誤。

    • 如果 GNSS 引擎偵測到使用者正在移動，而且在 100 公尺以內有地理柵欄界限，GNSS 引擎必須在一分鐘內傳送追蹤錯誤。

    • 如果 GNSS 引擎無法判斷使用者是否移動，而且在 100 公尺內有地理柵欄界限，GNSS 引擎必須在一分鐘內傳送追蹤錯誤。

    • 如果 GNSS 引擎偵測到使用者正在移動，則 GNSS 引擎必須在與估計移動速度與最接近地理柵欄距離成正比的時間傳送追蹤錯誤。 建議在 [ (距離到最接近的柵欄界限 (m) / 估計速度 (m/s) ) - 15s 內傳送錯誤。 GNSS 引擎可能會使用移動偵測指標來判斷應該傳送追蹤錯誤的時間。

    • 如果 GNSS 引擎無法判斷使用者是否正在移動，則 GNSS 引擎必須在與高速移動和最接近地理柵欄距離成正比的時間傳送追蹤錯誤。 建議在 [距離到最接近的柵欄界限 (m) / 343 (m/s) 內傳送錯誤。

  • 在 GNSS 引擎回報地理柵欄追蹤狀態錯誤期間，不應該有任何地理柵欄缺口事件傳送至 HLOS。

  • HLOS 可以透過單一命令刪除所有先前建立的地理柵欄來重設地理柵欄追蹤。

  • 在重新啟動或驅動程式重新啟動時，行動裝置原始地理柵欄不會保存在 GNSS 硬體或驅動程式中。 HLOS 會代表使用者應用程式處理持續性，並視需要建立/刪除地理柵欄。

就支援原生地理柵欄卸除的 GNSS 配接器與 GNSS 引擎之間的互動，在地理柵欄追蹤失敗的情況下，GNSS 配接器會如下所示：

  • 一旦 GNSS 驅動程式傳回無法追蹤，它就會使用 AP 型追蹤。

  • 它會繼續將目前在操作系統層級追蹤的地理柵欄中， (新增/刪除) 的任何更新推送至驅動程式，使其同步處理。這可協助 GNSS 引擎知道操作系統目前正在追蹤哪些地理柵欄，而且它可以根據最新數據來追蹤/無法追蹤判斷。

  • 當 GNSS 驅動程式傳回 SUCCESS 的能力時，它會推送 AP 型追蹤器所決定的地理柵欄狀態變更。

驅動程式通知以取得協助和協助程序數據

GNSS 驅動程式可能需要 GNSS 配接器中的協助資料或協助程式動作。 這包括各種形式的 AGNSS 資料 (時間插入、暫時、初始粗略位置) 、支援網路起始的使用者平面定位的使用者同意快顯等等。

  • GNSS 協助數據可由 GNSS 驅動程式取得，而不需要使用 GNSS 配接器。 不過，建議您使用 GNSS 配接器取得協助數據，並基於數個原因利用 Microsoft 定位服務：

    • Microsoft 位置堆疊會負責建立數據連線，並遵守任何漫遊條件約束、數據喜好設定、網路無訊息模式整合等等。

    • Microsoft 定位服務可以透過伺服器到伺服器後端連線，定期取得 IHV 特定的協助數據，並將它提供給需要的所有裝置，以節省 IHV 部署全球前端協助服務的需求，以符合可用性、延展性和回應性需求。

  • 使用者同意收件匣應用程式的隱私權是由操作系統所擁有。 因此，通知使用者有關網路起始位置要求的任何UI，或是要求使用者同意以響應網路起始位置要求的任何UI，都將由 Microsoft 擁有。 當收到網路起始的位置要求時，GNSS 驅動程式會通知 GNSS 配接器，如有需要，則會等待使用者回應到默認時間，再繼續進行要求。

由於 GNSS 驅動程式無法自行起始對上層的要求，因此 GNSS 配接器可以主動從 GNSS 驅動程式搜尋這類要求，進而一律保留一或多個擱置的 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 驅動程式應該使用 Microsoft 指定的記錄機制來記錄錯誤和其他診斷資訊， (WPP) 如下所述或 ETW。 雖然支援這兩種機制，但建議驅動程式將 WPP 用於記錄用途，而不是 ETW。 建議使用 WPP 的原因之一，是可協助驅動程式偵錯的工具可用性。

除了透過此指定的記錄技術以外，驅動程式不得記錄任何資訊、人類可讀取或其他資訊。 如需詳細資訊，請參閱 WPP 軟體追蹤。

使用 WPP 軟體追蹤記錄訊息類似於使用 Windows 事件記錄服務。 驅動程式會在記錄檔中記錄訊息標識碼和未格式化的二進位數據。 接著，後處理器會將記錄檔中的資訊轉換成人類可讀取的格式。 不過，WPP 軟體追蹤支援比事件記錄服務所支援且更具彈性的訊息格式。 例如，WPP 軟體追蹤具有IP位址、GUID、系統標識碼、時間戳和其他實用數據類型的內建支援。 此外，使用者可以新增與其應用程式相關的自定義數據類型。

電信業者通訊協議支援

需要 IHV 提供的 GNSS 堆疊 (GNSS 驅動程式、GNSS 裝置/引擎) ，才能支援各種電信業者定位通訊協定 (SUPL、UPL、CP 等) 。 無法這麼做表示裝置不會通過電信業者接受，而且會大幅限制裝置可以商業化的位置。

必須支援這些通訊協定，並符合電信業者需求，才能為特定電信業者寄送裝置。 對於大多數非手機平臺而言，電信業者通訊協定的支援可能並不重要，特別是如果平臺不包含行動寬頻 (MBB) 支援。

所有實作片段都會在 IHV 堆疊中抽象化，而 Microsoft HLOS 元件與下列項目無關：

  • 通訊協定的特定實作詳細數據 (例如通訊協議的運作方式、通訊協定訊息的解譯，依此類) 。

  • 例如，實作堆疊的圖形 (，實作可以位於 GNSS 裝置/引擎或 GNSS 驅動程式內，或視需要個別的 HLOS 服務) 。

  • IHV 擁有的 GNSS 堆疊內各種片段之間的互動，以實作通訊協定。 例如，如果 GNSS 驅動程式需要 Wi-Fi 掃描結果以回應特定的 SUPL 通訊協定訊息，則可以藉由讓使用者模式擴充功能透過私人 IOCTL 呼叫將 Wi-Fi 掃描結果插入驅動程式，或讓此部分成為 UMDF 2.0 驅動程式，或在較低層級處理此互動。 Microsoft GNSS HLOS 元件對 IHV GNSS 堆棧元件之間的這類互動很模糊。

總而言之，IHV 或 OEM 必須提供 SUPL 用戶端 (，而且如果系統要出貨到中國) 並與 GNSS 驅動程式內整合，則需要提供 UPL 用戶端。 位置平臺與 SUPL 用戶端的所有互動都會透過 GNSS DDI 來完成。

為了協助實作電信業者通訊協定，並減少使用平臺特定技術的軟體開發負擔，GNSS 配接器會提供 IHV GNSS 堆棧的特定功能。 GNSS 驅動程式會被視為從 HLOS 元件接收這類功能的媒介，例如，GNSS 配接器只會與 GNSS 驅動程式互動，而不會與 IHV GNSS 堆棧的任何其他部分互動。 GNSS 驅動程式 IOCTLs 定義 GNSS 驅動程式與 GNSS 配接器之間這類功能的語法和語意。 GNSS 驅動程式負責路由傳送至實作電信業者通訊協定的特定 IHV 元件。 大致上，GNSS 配接器會為 GNSS 驅動程式提供下列功能：

  1. 配置： 電信業者會使用 OMA 通訊協定標準所加加的設定機制來布建裝置和變更設定。 例如，SUPL 標準需要根據 UICC 和/或使用透過 OMA-DM 或 OMA-CP 取得的 SUPL OMA 組態配置檔資訊來完成 SUPL 設定。

    (OMA-DM 和 OMA CP) ，在 Windows 10 之前，電話中提供的某些功能可用於其他平臺。 從 Windows 10 開始，只要使用新的 GNSS DDI，所有平臺都可以透過 SUPL 設定服務提供者 (CSP) 來支援 SUPL 設定。 透過 CSP 插入的布建可以來自映像本身， (透過 provxml 或 multivariant) ，或透過 OMA-DM 或 OMA-CP 從電信業者取得。 SUPL CSP 定義於 SUPL CSP 中。

    Windows 10 使用設定服務提供者 (CSP) 定義專屬技術、裝置管理，以解譯和擷取設定數據。 Microsoft 提供 CSP 來取用 OMA 設定，並透過 GNSS 配接器將設定推送至 GNSS 驅動程式。

    或者，IHV 也可以撰寫使用者模式元件，以使用手機特定的裝置管理技術來取用電信業者組態規格， (CSP) 。 不過，這會是IHV的額外負擔，不建議這麼做。

    系統中僅支援一個 SUPL 設定，包括雙 SIM 卡裝置的情況。 Microsoft 提供根據 UICC 和 UICC 變更重新設定 SUPL 的功能。 此外，如果是裝置漫遊，HLOS 會將 SUPL 用戶端重新設定為在獨立模式中運作。 本文件定義將這類組態數據推送到各種行動作業通訊協定的 IOCTL， (SUPL 1.0 和 2.0、v2UPL 等等) 。

  2. 處理 NI 要求的使用者同意： 為了符合隱私權需求，某些網路起始的位置要求需要使用者同意。 IHV 不允許撰寫平台元件的UI。 因此，GNSS 配接器會代表 GNSS 驅動程式處理使用者同意的 UI。 GNSS 驅動程式要求 UI 快顯的通知 IOCTLs，以及 GNSS 配接器的 IOCTLs，以傳達這類要求的用戶回應是在 GNSS 驅動程式 IOCTLs 中定義。

為了實作功能完整的 SUPL 用戶端，IHV 堆疊必須使用介面或透過 OS 平臺提供一般功能。 以下是 #D0C389F4CAD6848A6A17FD1412EB1B787 中可用來實作其 SUPL 用戶端的功能清單：

這項功能都不是位置平臺或 GNSS DDI 的一部分，但這裡會包含此功能，以釐清並協助 GNSS 驅動程式開發人員瞭解可從 OS 運用哪些功能來實作 SUPL 功能。

SUPL 用戶端與 GNSS 驅動程式的互動。

  • SMS 路由器： SMS 路由器可讓 SUPL 用戶端訂閱具有 SUPL NI 要求的 SIP 推送訊息的 WAP 推送。

  • 連線管理員 設定哪些連線應用於 SUPL 和 API 來要求這類連線：行動操作員可能需要在專用連線中擁有 SUPL 流量，或只是在與預設因特網連線不同的連線上。 若要這樣做，連線管理員 供應專案：

    • OEM 或行動電信業者可用來設定哪些連線應用於 SUPL 通訊的設定服務提供者。

    • SUPL 用戶端的 API，可查詢 SUPL 連線的連接參數。

    • 用來建立 SUPL 連線的 API，其中包含在上一個步驟中取得的參數。

  • 行動數據連線設定： 若要設定不同行動數據連線的參數，例如 SUPL 連線的參數，OEM 或行動操作員可以使用的設定服務提供者。 然後，此聯機可以在 連線管理員 與 SUPL 用途相關聯。

  • 在 SUPL 連線進行時，要求讓連線保持作用中： 當系統處於連線待命狀態時，SUPL 用戶端可能需要起始與 HSLP 的連線。 這可能是因為 GNSS 裝置需要在設定為使用 Microsoft 型定位時取得協助資訊，或因為行動電信業者傳送 NI 要求。 如果是這種情況，SUPL 用戶端必須起始與 HSLP 的連線，並確定連線在 SUPL 會話完成之前為作用中。

  • 與行動寬頻 (MBB) 模組的互動：在 Windows 10 中，沒有 API 可透過 HLOS 來擷取行動數據測量、知道何時放置緊急電話等等。 任何與 MBB 的互動都必須透過透過 AT 命令或其他專屬方法) 與 MBB (直接整合來完成。

製造測試

OEM 必須在製造時間進行驗證，以及在客戶支援點上，GNSS 硬體和 GNSS 堆疊 (GNSS 驅動程式和 GNSS 裝置/引擎) 正常運作。 IHV 可以提供專屬的機制，讓 OEM 能夠執行這項測試，或可以選擇性地在 DDI 中實作 介面，讓 OEM 起始製造測試並取得結果。

在進行製造測試時，會略過位置架構，因為測試的主要焦點在於硬體驗證或驅動程序驗證。 一般而言，裝置會處於特殊的「安全操作系統模式」，其中會載入最少的元件和服務集。 在此模式中，OEM 可以起始一組將觸發測試案例的測試應用程式。 為了在製造期間有效率與速度，強烈建議在不同元件內支援並行支持測試。

製造測試的介面包含兩種類型的測試：

  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 IOCTLs 都是語意異步 (例如，IOCTL 會觸發驅動程式內的活動，而且結果預期會以異步方式回溯) ，但某些 IOCTL 在語意上是同步的，因此沒有與這類 IOCTLs 相關的邏輯異步動作或活動。 在發出 DeviceIoControl 呼叫之後，在 I/O 作業完成之前封鎖 GNSS 配接器線程，即可達到這些幾個 IOCTL 的同步行為。 因此，GNSS 驅動程式必須一律在處理所有 IOCTL 時完成 IRP 的責任。 GNSS 配接器預期會接受同步呼叫的合約，如果發生錯誤，可能或可能不會重試這些命令。 IHV 驅動程式必須確定它已納入驅動程式端的所有邏輯，然後再傳回錯誤。

對於要求和回應作業，GNSS 配接器一律會保留擱置的 I/O 作業可用，如此一來，當 GNSS 驅動程式有數據作為先前叫用作業的回應時，就可以透過擱置的 IRP 傳送回應。

單次會話

驅動程式單次修正的開始修正要求包含精確度和回應時間值。 GNSS 引擎可以使用這些值來瞭解應用程式要求的意圖，並做出智慧型決策。 驅動程式收到要求后，應該開始傳回引擎所產生的任何中繼修正。 中繼修正是在計算符合正確性需求或最終的修正時，引擎所產生的修正程式。 不會強制執行這些中繼修正的頻率，而且是引擎的實作詳細數據。 GNSS 配接器需要每隔幾秒鐘才會進行修正，而且它們應該與最後一個中繼修正不同。

一旦 GNSS 引擎判斷它無法在目前的訊號狀況下取得更好的修正，它應該會傳回最終的修正程式，而且應該停止執行任何進一步的計算。 最終修正程式符合精確度需求，或指出引擎無法改善目前狀況下提供的精確度。

GNSS 配接器會在兩種情況下，針對單次會話發出停止修正：

  • 它會從驅動程式取得最終修正。

  • 要求的回應時間已達。 在這裡，最後一個中繼修正程式會傳送至應用程式。

下圖說明兩個單次會話：

此圖顯示兩個工作階段的中繼修正。

會話 1： 驅動程式已獲得精確度和回應時間參數。 啟動修正命令之後，驅動程式會開始傳送中繼修正。 經過一段時間后，它判斷無法傳回更精確的修正，因此它會指出最後一個修正程序最後一個。 這發生在達到回應時間限制之前。 配接器會將最終修正傳送至應用程式，併發出停止修正命令。

會話 2： 與上述會話 1 相同，但在此案例中，引擎會持續進行更好的修正，以符合正確性需求，並在兩者之間持續傳送中繼修正程式。 一旦達到會話回應時間限制，配接器就會發出停止修正，應該在驅動程式中關閉此會話。 收到的最後一個中繼修正程式已傳送至應用程式。

實作單次支援時要考慮的一個重要設計層面是，如果不支援以距離為基礎的追蹤會話和以時間為基礎的追蹤會話，GNSS 引擎在收到停止修正命令之後，應該繼續追蹤衛星 3 到 5 秒。 這是因為 GNSS 配接器需要使用單次修正會話來實作仿真的距離追蹤會話和/或以時間為基礎的追蹤會話，而且如果 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. 步驟 6 會重複到 GNSS 驅動程式指出， (收到最終修正程式) ，則不會再進行任何修正。

  8. GNSS 配接器問題 IOCTL_GNSS_STOP_FIXSESSION。 GNSS 驅動程式會執行與原始修正要求相關聯的必要清除作業。

  9. GNSS 配接器會使用 CloseHandle API 關閉 驅動程式檔句柄。

GNSS IOCTLs 和相關聯的數據結構會在 GNSS 驅動程式參考中詳細說明。

以距離為基礎的追蹤會話

使用者應用程式經常會使用以距離為基礎的追蹤會話，因為在過去，它是 .NET API 中唯一可用的會話類型。 距離值為 0 表示 GNSS 引擎應盡可能提供最高速率的修正。

只有在後者指出具有 SupportDistanceTracking 功能時，GNSS 配接器才會使用 GNSS 驅動程式開始距離追蹤會話。

針對距離追蹤會話的驅動程序開始修正要求會包含所需的水準精確度和移動閾值，也就是 GNSS 驅動程式提供位置更新之前，系統應涵蓋的計量中具有餘弦距離。 GNSS 引擎可以使用這些值來瞭解應用程式要求的意圖，並做出智慧型手機決策，例如調整檢查位置的頻率。

驅動程式收到啟動修正要求后，應該開始傳回引擎所產生的任何中繼修正，直到取得最終修正為止。 這會被視為會話的第一個位置。 在此之後，每當 GNSS 引擎偵測到已大約涵蓋的餘弦距離時，應該開始提供修正程式。

例如，如果 GNSS 引擎判斷它無法追蹤裝置 (的位置，例如，如果衛星無法再) ，它應該會將錯誤傳回給 GNSS 配接器，讓位置平臺可以切換回其他機制，以提供位置更新給終端使用者應用程式。 GNSS 配接器應該會在下列時間內提供錯誤：

[ (Distance-remaining-since-last-known-position (m) / estimated speed (m/s) ) – 5 seconds] 或 5 秒，以哪一個為最大。

如果 GNSS 引擎向 GNSS 配接器提供錯誤，但 GNSS 配接器尚未停止追蹤會話，則 GNSS 引擎應該以電源優化的方式繼續檢查，如果可以繼續追蹤位置。 IHV 可以使用優化，以低電量進行這項偵測。 常見的優化技術包括：

  • 漸進式退退

  • 等候指出裝置移動的低成本訊號重新檢查

  • 衛星訊號的低電源檢查

一旦 GNSS 引擎能夠在錯誤狀況之後再次提供最終修正，它應該會將該位置傳送至 GNSS 配接器，表示追蹤已成功繼續。

如果要求追蹤會話的一或多個應用程式已取消要求要求，或新的應用程式要求以距離為基礎的追蹤會話，GNSS 配接器會發出修改修正命令。 在這種情況下，GNSS 配接器會計算多任務處理不同使用中會話所需的新匯總會話參數，並使用這些參數更新 GNSS 驅動程式。

如果下列情況，GNSS 配接器會針對以距離為基礎的追蹤會話發出停止修正命令：

  • 追蹤會話已交給系統中可用的另一個定位引擎。

  • 要求追蹤會話的應用程式已取消要求。

下圖說明兩個以距離為基礎的追蹤會話：

gnss 驅動程式 的內部追蹤。

會話 1： 起始追蹤會話時，GNSS 驅動程式已獲得精確度和移動閾值參數。 啟動修正命令之後，驅動程式會開始傳送中繼修正，直到它取得最終修正或符合正確性需求的修正程序，此時這類修正會提供給 GNSS 配接器，而 GNSS 引擎將會啟動距離追蹤程式。 當會話處於作用中狀態時，GNSS 配接器會傳送要求，以在 T1 和 T2 時修改會話參數。 每次修改參數之後，GNSS 驅動程式會將修正更新傳送至 GNSS 配接器，並繼續使用新參數的距離追蹤會話，直到 GNSS 配接器傳送停止修正命令為止。

會話 2： 會話初始程序類似於上述的工作階段 1，但在指定時間點，GNSS 引擎無法追蹤位置。 在相依於距離和估計移動速度的時間之後，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 配接器，表示追蹤已成功繼續。

如果要求追蹤會話的一或多個應用程式已取消要求，或新應用程式要求以時間為基礎的追蹤會話，GNSS 配接器會發出修改修正命令。 在這種情況下，GNSS 配接器會計算多任務處理不同使用中會話所需的新匯總會話參數，並使用這些參數更新 GNSS 驅動程式。

如果下列情況，GNSS 配接器會針對以時間為基礎的追蹤會話發出停止修正命令：

  • 追蹤會話已交給系統中可用的另一個定位引擎。

  • 要求追蹤會話的應用程式已取消要求。

下圖說明兩個以時間為基礎的追蹤會話。

gnss 驅動程式修正的時間型追蹤圖表。

會話 1： 起始追蹤會話時，GNSS 驅動程式具有精確度和慣用的間隔參數。 啟動修正命令之後，驅動程式應該會開始傳送中繼修正，直到它取得最終修正或修正符合 GNSS 配接器提供這類修正的精確度需求，而 GNSS 引擎將會啟動以時間為基礎的追蹤程式。 當會話處於作用中狀態時，GNSS 配接器會傳送要求，以在 T1 和 T2 時修改會話參數。 每次修改參數之後，GNSS 驅動程式會將修正更新傳送至 GNSS 配接器，並使用新的參數繼續以時間為基礎的追蹤會話，直到 GNSS 配接器傳送停止修正命令為止。

會話 2： 會話初始程序類似於上述第 1 個工作階段中的程式，但在指定的時間點，GNSS 引擎會停止追蹤位置。 當 GNSS 引擎無法在工作階段參數所需間隔的 15 秒內提供修正時，GNSS 驅動程式會傳送錯誤。 當 GNSS 引擎可以復原時，GNSS 引擎會繼續以較低的電源檢查，並在復原時向 GNSS 適配卡傳送新的修正程式，以向 GNSS 適配卡表示。 會話會視需要更新為新的修正程式，直到 GNSS 配接器傳送停止修正命令為止。

當系統處於連線待命狀態時，GNSS 配接器可能會保持作用中或甚至起始以時間為基礎的追蹤會話，而不只是當系統處於作用中狀態時。 這可能會滿足應用程式處理器中背景工作、系統服務、地理柵欄追蹤或其他情況的需求。 GNSS 驅動程式應該能夠將這些工作階段要求傳遞至 GNSS 裝置，並滿足要求，或為 GNSS 配接器提供錯誤。

同時處理不同類型的修正會話

某些進階 GNSS 引擎可能能夠同時處理單一快照會話，以及具有 Distance-Based 和/或 Time-Based 追蹤工作階段。 在理想情況下，獨立會話不應彼此影響，但這可能不一定可行，特別是在同時單次和時間型追蹤會話的情況下。 本節提供 IHV 實作的一些指導方針，以防需要入侵才能處理不同類型的同時會話。

本節使用下列縮略字：

  • SS： 單次會話

  • Dbt： 以距離為基礎的追蹤會話

  • TBT：以時間為基礎的追蹤會話

  • TBF： 修正之間的時間

下表提供一些案例，可同時處理單次和以時間為基礎的追蹤會話：

案例 SS 作用中？ TBT 作用中？ 案例詳細資料 可接受的修正間隔 註解
1 X X SS 會話在 TBT 定期會話開始時持續進行，但剩餘逾時 >= 間隔 與TT間隔相同 SS 工作階段行為：

中繼和最終修正會傳送到逾時為止。

收到停止之後立即關閉會話。

TBT 工作階段行為：

會傳送中繼和最終修正。

根據間隔大約收到修正。

收到停止之後立即關閉會話。
2 X X SS 會話在 TBT 定期工作階段開始時，以剩餘的逾時 < 間隔開始進行 間隔會維持與 SS 逾時相同的狀態，直到滿足 SS 會話為止。
然後，間隔可以更新為與 TBT 間隔相同。		 SS 工作階段行為：

中繼和最終修正會傳送到逾時為止。

收到停止之後立即關閉會話。

TBT 工作階段行為：

傳送中繼和最終修正

根據間隔大約收到修正，但在提供 SS 工作階段時可能會更頻繁。

收到停止之後立即關閉會話。
3 X X SS 工作階段在進行中的 TBT 定期工作階段以逾時 >= 間隔啟動時啟動 與TT間隔相同 SS 工作階段行為：

中繼和最終修正會傳送到逾時為止。

收到停止之後立即關閉會話。

TBT 工作階段行為：

傳送中繼和最終修正

根據間隔大約收到修正。

收到停止之後立即關閉會話。
4 X X SS 會話在進行中的 TBT 定期會話以逾時 < 間隔啟動時啟動 間隔變更為與 SS 逾時相同，直到滿足 SS 會話為止。 然後，間隔可以更新為與 TBT 間隔相同。 SS 工作階段行為：

中繼和最終修正會傳送到逾時為止。

收到停止之後立即關閉會話。

TBT 工作階段行為：

會傳送中繼和最終修正。

根據間隔大約收到修正，但在提供 SS 工作階段時可能會更頻繁。

收到停止之後立即關閉會話。
5 X TBT 定期會話以修改間隔開始 具有數據機的工作階段會更新為與TT間隔相同的新間隔。 如有需要，將會重新啟動數據機會話。 SS 工作階段行為：

不適用

TBT 工作階段行為：

會傳送中繼和最終修正。

根據間隔大約收到修正。

收到停止之後立即關閉會話。
6 X X SS 會話會在進行中的 TBT 定期會話收到間隔變更時進行，剩餘逾時 >= 間隔 與TT間隔相同 SS 工作階段行為：

中繼和最終修正會傳送到逾時為止。

收到停止之後立即關閉會話。

TBT 工作階段行為：

傳送中繼和最終修正

根據間隔大約收到修正。

收到停止之後立即關閉會話。
7 X X SS 會話會在進行中的 TBT 定期會話收到間隔變更時進行，剩餘的逾時 < 間隔 間隔變更為與 SS 剩餘逾時相同，直到滿足 SS 會話為止。 然後，間隔可以更新為與 TBT 間隔相同。 SS 工作階段行為：

中繼和最終修正會傳送到逾時為止。

收到停止后立即關閉會話。/li>
TBT 工作階段行為：

傳送中繼和最終修正

根據間隔大約收到修正，但在提供 SS 工作階段時可能會更頻繁。

收到停止之後立即關閉會話。

如果同時有時間型和以距離為基礎的追蹤會話，則可以將 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，因為它們可供使用。