全域導覽衛星系統 (GNSS) 驅動程式需求
描述開發全域導覽衛星系統 (GNSS) 驅動程式以進行 Windows 10 時，需要考慮的需求、假設和條件約束。
一般需求
- 驅動程序架構： GNSS 驅動程式應該以 UMDF 2.0 驅動程式的形式撰寫，此驅動程式是以這個介面定義為基礎，而不是原始 WDM 驅動程式或 KMDF 驅動程式。 不支援UMDF 1.0驅動程式。 GNSS 驅動程式介面定義或 Microsoft 高階作業系統 (HLOS) GNSS 配接器等 GNSS 元件不會區分 WDF、KMDF GNSS 驅動程式和 UMDF 2.0 驅動程式，只要驅動程式根據此介面設計提供所需的功能即可。 UMDF 2.0 提供更高的穩定性、簡單性和彈性，以實作僅需要使用者模式中功能的功能。 一般規則是，當平臺上有前一個架構可用時，IHD 應該偏好使用 UMDF 2.0 到 KMDF。
UMDF 2.0 適用於所有平臺，強烈建議您使用以使用者模式撰寫的驅動程式。
多個應用程式會話： 應用程式會話是一種定位會話，來自直接與 GNSS 驅動程式互動的 HLOS 元件。 GNSS 驅動程式可以選擇以原生方式支援多個應用程式會話，方法是將其狀態變數和功能分割成個別應用程序基礎。 這是驅動程式的選擇性功能，特別透過定義完善的 GNSS 驅動程式功能資訊來指出。 為了支援此選擇性行為，GNSS 驅動程式必須追蹤 HLOS 應用程式在 CreateFile 期間取得的檔案句柄，並將所有後續的 HLOS 作業與應用程式會話特定的檔句柄產生關聯。 GNSS 驅動程式的這個原生支援可讓 HLOS 元件更有彈性，且對於將驅動程式公開至平臺的其餘部分較不嚴格。 支援此功能的 GNSS 驅動程式可能需要以邏輯方式分割及維護每個個別應用程式會話的狀態資訊。 不支援此功能的 GNSS 驅動程式只需要維護所有應用程式會話的全域狀態，而不是邏輯應用程式特定的分割區。 在這個後者模式中，GNSS 驅動程式會忽略多個平行應用程式會話的存在，並將來自 HLOS 的所有要求視為來自相同應用程式會話。
支援多個應用程式會話的 GNSS 驅動程式的優點是讓 HLOS 中的測試應用程式直接與 GNSS 驅動程式互動，同時與 GNSS 適配卡互動。 測試應用程式和 GNSS 配接器是我們認為可以同時要求單一 GNSS 驅動程式不同會話的不同應用程式。 如果不支援多個應用程式會話，則 GNSS 驅動程式必須透過 OS 位置平臺進行測試，否則應該停止裝載 OS 位置平臺的服務，以避免干擾測試應用程式。
修正會話： 從基礎驅動程式取得定位資訊 (單次或追蹤) 的動作會抽象化為修正會話的概念。 驅動程式需要支援每個支援之會話類型的至少一個修正會話。 會話類型定義於 GNSS_FIXSESSIONTYPE 列舉之下。
至少 GNSS 驅動程式必須支援單次修正會話。
支援以距離為基礎的追蹤修正會話的驅動程序必須同時支援單次修正會話和以距離為基礎的追蹤修正會話。
支援以時間為基礎的追蹤修正會話的驅動程序必須同時支援單次修正會話和以時間為基礎的追蹤修正會話。
支援以距離為基礎的追蹤修正會話和以時間為基礎的追蹤修正會話的驅動程式必須同時支援單次修正會話、以距離為基礎的追蹤修正會話和以時間為基礎的追蹤修正會話。
驅動程式是否支援多個同時修正會話，都以定義完善的驅動程式功能參數表示。 如果驅動程式未明確支援多個平行修正會話，如果相同修正類型的會話已啟動且作用中，它必須失敗新的修正會話要求。 如果不存在多個修正會話支援，則 onus 位於 HLOS 元件上，以確保來自高階應用程式的多個 GNSS 要求會多任務處理，並對應至 GNSS 驅動程式的單一修正會話要求。
GNSS 驅動程式不需要支援相同類型的多個平行修正會話。 事實上，在 Windows 10 中，HLOS GNSS 適配卡不支援利用 GNSS 驅動程式功能來擁有相同類型的多個修正會話，因此不建議 IHV 在一段時間內投資這項功能。 在未來的版本中，將考慮讓 GNSS 配接器能夠直接使用 GNSS 驅動程式啟動作業階段，以取得從位置平臺的上層取得的每個修正要求，而不是執行工作階段多任務處理本身。 支援 GNSS 配接器中的多任務修正工作階段可簡化驅動程式實作，因為它不需要處理應用程式或多任務處理相同類型的多個工作階段，它可減少驅動程式中的記憶體使用量，而且不需要 GNSS 配接器來處理 HLOS 啟動數個修正會話大於 GNSS 驅動程式支援的會話案例。 不同層級的裝置和不同的驅動程式可支援不同數目的並行修正會話，因此必須處理此案例，在 GNSS 配接器中引進複雜度來處理所有案例。 因此，在 Windows 10 GNSS 配接器只會實作每個支援類型的單一修正會話，而且會忽略驅動程式的多個修正會話支援，直到我們需要這項功能為止。
每個修正會話都是可設定狀態的，而且必須遵循這個定義完善的順序：
啟動修正會話
取得一或多個修正
視需要修改修正會話
這至少必須等到 GNSS 配接器處理相同類型的修正會話多任務處理，甚至稍後可能需要處理比 GNSS 驅動程式所支援數目更多的同時修正會話案例。
- 停止修正會話
修正會話是由修正會話標識碼唯一識別。 修正會話內容外部的 HLOS 無法擷取任何位置資訊。 GNSS 驅動程式必須允許即時修改會話參數，以便 HLOS 元件進行多任務處理作業，而不需要重新啟動修正會話。
修正類型： GNSS 驅動程式至少必須支援基本單次修正。 此外，驅動程式應該原生支援進階修正類型， (例如追蹤) 。 如先前所述，支援其他修正類型表示即使驅動程式不支援相同類型的多個修正會話，它也必須同時支援支援的修正類型至少一個修正會話。 HLOS 元件不會將不同的修正類型多倍化為單一類型。
裝置介面和 PnP： GNSS 驅動程式應該使用 WdfDeviceCreateDeviceInterface API 公告 Microsoft 定義的裝置介面，讓 HLOS 可以收到 GNSS 驅動程式抵達和離開的通知。 若要在 隨插即用 (PnP) 設定中處理 GNSS 驅動程式，也必須在驅動程式是 UMDF 2.0 驅動程式時，因使用者層級服務損毀而發生非預期的驅動程式卸除的情況。 GNSS 驅動程式應該確保只有在下列硬體能夠支援 HLOS IOCTL 呼叫時，才會公告裝置介面。
裝置電源原則： GNSS 驅動程式應該管理其裝置的電源原則，而且應該處理 OS 所引發的電源管理事件。 驅動程式應該註冊 WDF_PNPPOWER_EVENT_CALLBACKS。當系統進入 D0 狀態) 並WDF_PNPPOWER_EVENT_CALLBACKS時，WDF 所引發的 EvtDeviceD0Entry 回呼 (。當系統從 D0 狀態) 結束時，WDF 所引發的 EvtDeviceD0Exit 回呼 (。 GNSS 驅動程式應該可設定為選擇性地停用電源管理。
必須在不同系統電源狀態的 GNSS 裝置中完成的確切電源管理，必須根據 GNSS 裝置的功能進行調整， (它是否支援卸載作業) 、是否有實際的卸除作業作用中，以及系統與 GNSS 裝置之間的通訊如何完成。 一般而言，預期如下：
不論系統電源狀態為何，GNSS 裝置都可以在沒有作用中會話或卸除作業時，以最低的電源模式運作。
在卸除案例中，不論系統電源狀態為何，GNSS 裝置可能需要檢查不同間隔的位置或接收通知，因此即使連線待命 (這是螢幕關閉的睡眠狀態) ，GNSS 裝置可能需要維持在 D0 狀態，但仍然硬體需要將電源耗用量降到最低。 例如，此模型適用於使用 DMA (直接記憶體取) 或 UART 上的序列埠來與主機通訊的裝置。 但是，透過 USB 總線連線的 GNSS 裝置將會是一項挑戰，在此情況下，裝置的 USB 功能應該在 D2 (在連線待命期間暫停) 裝置電源狀態。 一般而言，透過USB連線的 GNSS 裝置必須能夠在沒有修正工作階段或卸載作業且USB總線介面進入暫停狀態之後，進入低電源 D2 (暫停) 狀態。 所有睡眠和喚醒電源轉換都必須透過USB總線發出訊號。 如果 GNSS 裝置已修正作用中或卸除作業的會話，裝置必須能夠使用頻內、USB 繼續訊號，以從連線待命喚醒 SoC 或核心晶片。 SoC 或核心晶元必須能夠從其最低電源狀態喚醒，以回應來自 GNSS 裝置的頻內 USB 繼續訊號。
不支援連線待命的裝置會在裝置進入新式待命或休眠時取消所有卸載作業。 這包括卸除的地理柵欄、距離追蹤或定期追蹤會話。
當裝置進入連線待命狀態時，支援連線待命的裝置會繼續執行所有卸載作業，而 GNSS 裝置預期會盡可能有效率地繼續追蹤作業，而且當地理柵欄觸發條件或追蹤會話更新相關時，預期會提供通知給 HLOS。 如果裝置中沒有支持連線待命的卸除作業，GNSS 裝置應該會進入可能的最低電源狀態，但仍能夠接聽來自 HLOS 的位置會話要求。 在支援 SUPL 的裝置中，GNSS 裝置和 SUPL 堆疊也必須能夠在連線待命時喚醒 NI 通知。
如需驅動程式電源管理的一般資訊，請參閱 驅動程式的電源管理責任。
電源考慮： GNSS 驅動程式堆疊必須將電源使用量納入考慮，作為主要設計目標，並將主要處理器保持喚醒的可能性降到最低。 所有進階功能都支援 (，例如不同的修正類型) 必須以比主要應用程式處理器更有效率的方式執行，而且大部分的處理都可以卸載至晶元組/低電源處理器。 一般規則是，除非從 HLOS 另有指示，否則 GNSS 驅動程式必須一律將耗電量視為最重要的條件約束，而且必須設計為以最小電力使用量執行正常作業。 GNSS 驅動程式介面是明確設計來允許行動裝置盡可能轉換成低電源模式，並提供 GNSS 驅動程式所需的電源相關提示，以優化電源使用量。 若要追蹤、地理柵欄和其他需要長時間執行之持續性位置監視的功能，GNSS 驅動程式/引擎必須利用低電源硬體/處理器。 如果這類功能必須使用驅動程式中的暴力密碼破解輪詢機制來實作，或需要在應用程式處理器中實作，驅動程式不應該將本身宣告為能夠進行這類作業。 這可讓 HLOS 限制對平臺其餘部分的這類功能暴露，或使用以其他平台服務/基本類型為基礎的這些功能替代實作。
程序設計語言： GNSS 驅動程式介面會以 C 語言頭檔的形式傳遞，不會使用任何 C++ 特定語言基本類型 (，例如結構繼承) 。 這可讓 IHV 在 C 和 C++ 之間進行選擇。 GNSS 介面頭檔會讓選擇開放給 IHV。
篩選驅動程式： GNSS 裝置堆疊不得受限於防止在堆疊中新增未來的篩選驅動程式以支援擴充功能的方式。 IHV 提供的 GNSS 驅動程式不得在驅動程式堆疊的頂端或底部包含自己的篩選驅動程式。
通知和事件： 由於 WDF 驅動程式無法傳送未經請求的通知給 HLOS，因此一律至少有一個擱置的 IRP 起始自 HLOS，用來接收驅動程式層的任何這類未要求通知。 這包括系統處於連線待命狀態的情況。 針對 GNSS 驅動程式，這類未經要求通知包括 (，但不限於) 網路起始的要求、AGNSS 支援的協助數據、其他廠商特定的通知。 HLOS 可確保一律有擱置的 I/O 要求來處理這類通知。
使用者模式 IHV 擴充功能： IHD 可以透過 IHV 定義的私人 IOCTL 撰寫與 GNSS 驅動程式互動的輔助使用者模式元件。 如果 GNSS 驅動程式處於內核模式，則特別需要這項功能，在此情況下，它無法存取使用者模式中獨佔的功能 (例如，Wi-Fi 掃描、連線管理員 API 等等) 。 請注意，在 Windows 10 中使用UMDF 2.0時，UMDF GNSS驅動程式不需要個別的使用者模式元件，不過IHV仍可能會實作個別的使用者模式元件。 這些使用者模式元件只會被視為 GNSS 驅動程式的擴充功能，而且會被視為 IHV 傳遞 BSP 卸除的一部分。 Microsoft 提供的 HLOS 元件會混淆這類元件的確切實作詳細數據，以及 IHV 使用者模式/內核模式元件之間的互動機制。 如果使用使用者模式 IHV 擴充功能將 GNSS 驅動程式寫入為 UMDF 2.0 驅動程式，則不建議使用此模型，因為此模型可能需要更多記憶體使用量。
使用者模式 IHV 延伸模組必須符合下列規則：
公用 GNSS 驅動程式 IOCTLs 的語意和行為必須維持不受影響且不受使用者模式 IHV 延伸模組及其與 GNSS 驅動程式的互動影響。
使用者模式擴充功能必須符合 Windows 10 平臺所加加的安全性、電源和其他平臺基本概念和原則。
使用者模式延伸模組只能執行 Microsoft 核准的授權活動，而不需要在運行時間強制執行/驗證這類授權。
Microsoft 仍然可以強制執行安全策略，並控制這類元件的存留期。 此處的重點在於 IHV 使用者模式元件不應該計入平臺上，以強制執行這類原則，因為擴充元件會被視為受信任的 OS 元件。
IHV 不會新增任意功能，或使用未經授權的OS服務/安全資源。
最低支援需求
有各種不同的全域導覽衛星系統 (GNSS) 裝置，這些裝置可用於 Windows 平臺，以滿足各種裝置層的需求， (低成本、高階、不同的裝置類型等等) 。 為了啟用這類豐富的生態系統，並增加平板電腦、膝上型電腦和其他裝置類型，這些裝置可以低成本包含 GNSS 晶片，Microsoft 不需要所有 GNSS 裝置都支援 GNSS 驅動程式參考中所述的完整功能集。 下表提供不同裝置類型所需的最低功能概略檢視，以及選用或建議的功能。
| 功能 | 所有平臺的需求 | 手機的特定需求 | 備註 |
|---|---|---|---|
| 正確報告GNSS_DEVICE_CAPABILITIES | 強制性 | 最低功能需求 | |
| 支援 MultipleFixSessions | 選擇性 | GNSS 配接器不支援 | |
| 支援 MultipleAppSessions | 建議 | ||
| GNSS 協助支援 (IHV 特定) | 建議 | 強制性 | |
| 透過 Microsoft (使用 Agss_inject IOCTLs) 取得 GNSS 協助支援 | 建議 | ||
| 完整GNSS_FixData結構的支援 | 強制性 | ||
| 單次會話 | 強制性 | ||
| 以時間為基礎的追蹤會話原生支援 | 選擇性 | 如果支援，它必須包含修改會話參數的支援。 | |
| 以距離為基礎的追蹤會話原生支援 | 選擇性 | 如果支援，它必須包含修改會話參數的支援。 | |
| 上次良好的已知會話 | 選擇性 | ||
| 地理柵欄原生支援 | 選擇性 | 建議 | 僅需要且支持的圓形地理柵欄 |
| 提供晶片組Info | 強制性 | 使用 GNSS_ChipsetInfo | |
| 報告錯誤 | 建議 | 使用 GNSS_ErrorInfo | |
| 透過 NMEA 的報告 | 選擇性 | ||
| 製造測試支援 (載波或自我測試) | 選擇性 | ||
| 與 MBB 整合的控制平面位置 | 只有在電信業者需要時才強制 | 強制性 | 行動電信業者通常需要語音支援。 手機幾乎一律需要。 |
| SUPL 1.0 | 只有在電信業者需要時才強制 | 一般而言，由 SUPL 2.0 取代。 包含完整的用戶端符合電信業者需求、透過 DDI 設定、透過 DDI 向 OS 報告 NI 事件，以及與 MBB 整合。 |
|
| SUPL 2.x | 只有在電信業者需要時才強制 | 強制性 | 行動電信業者通常需要語音支援。 手機幾乎一律需要。 包含完整的用戶端符合電信業者需求、透過 DDI 設定、透過 DDI 向 OS 報告 NI 事件，以及與 MBB 整合。 |
| UPL | 只有在電信業者需要時才強制 | 只有在電信業者需要時，才需要支持中國出貨的CDMA裝置。 包含完整的用戶端符合電信業者需求、透過 DDI 設定、透過 DDI 向 OS 報告 NI 事件，以及與 MBB 整合。 |
|
| GNSS_SetLocationServiceEnabled驅動程式命令 | 強制性 | ||
| GNSS_SetLocationNIRequestAllowed驅動程式命令 | 只有在電信業者支援且需要 SUPL 時才強制 | 不再有已知的電信業者需要此專案 | |
| GNSS_ForceSatelliteSystem驅動程式命令 | 建議 | 適合用於測試用途。 某些電信業者或 OEM 可能需要此項目進行測試。 | |
| GNSS_ForceOperationMode驅動程式命令 | 只有在 SUPL 支援時才強制 | 某些電信業者可能需要進行測試。 | |
| GNSS_ResetEngine驅動程式命令 | 強制性 | 供測試之用 | |
| GNSS_ClearAgnssData驅動程式命令 | 強制性 | 供測試之用 | |
| GNSS_SetNMEALogging驅動程式命令 | 選擇性 | 只有在電信業者或 OEM 需要此專案以供測試之用時 | |
| GNSS_SetSuplVersion驅動程式命令 | 只有在 SUPL 支援時才強制 | SUPL 的必要專案 | |
| GNSS_SetUplServerAccessInterval驅動程式命令 | 只有在電信業者支援且需要 SUPL 時才強制 | 只有在電信業者需要時才需要 | |
| GNSS_SetNiTimeoutInterval驅動程式命令 | 只有在電信業者支援且需要 SUPL 時才強制 | 只有在電信業者需要時才需要 | |
| GNSS_ResetGeofencesTracking驅動程式命令 | 只有在支援地理柵欄時才強制 | ||
| GNSS_CustomCommand驅動程式命令 | 選擇性 |