全球导航卫星系统 (GNSS) 驱动程序需求
介绍开发用于Windows 10的全球导航卫星系统 (GNSS) 驱动程序时要考虑的要求、假设和约束。
一般要求
- 驱动程序框架： GNSS 驱动程序应基于此接口定义编写为 UMDF 2.0 驱动程序 ，而不是原始 WDM 驱动程序或 KMDF 驱动程序。 也不支持 UMDF 1.0 驱动程序。 GNSS 驱动程序接口定义或 Microsoft 高级操作系统 (HLOS) GNSS 组件（如 GNSS 适配器）不区分 WDF、KMDF GNSS 驱动程序和 UMDF 2.0 驱动程序，前提是驱动程序根据此接口设计提供所需的功能。 UMDF 2.0 提供更高的稳定性、简单性和灵活性，以实现仅要求在用户模式下提供的功能的功能。 一般情况下，当以前的框架在平台上可用时，IHV 应首选 UMDF 2.0 而不是 KMDF。
UMDF 2.0 在所有平台上都可用，强烈建议 IHV 使用以用户模式编写的驱动程序。
多个应用程序会话： 应用程序会话是一种定位会话，来自直接与 GNSS 驱动程序交互的 HLOS 组件。 GNSS 驱动程序可以选择通过按应用程序将状态变量和功能分区到本机支持多个应用程序会话。 这是驱动程序的可选功能，通过明确定义的 GNSS 驱动程序功能信息专门指示。 为了支持此可选行为，GNSS 驱动程序需要跟踪 HLOS 应用程序在 CreateFile 期间获取的文件句柄，并将所有后续 HLOS 操作关联到特定于应用程序会话的文件句柄。 GNSS 驱动程序的这种本机支持使 HLOS 组件在向平台的其余部分公开驱动程序时更加灵活和限制更少。 支持此功能的 GNSS 驱动程序可能需要对每个单独的应用程序会话进行逻辑分区和维护状态信息。 不支持此功能的 GNSS 驱动程序只需要维护所有应用程序会话的全局状态，而不是特定于逻辑应用的分区。 在此后一模式下，GNSS 驱动程序将忽略多个并行应用程序会话的存在，并将来自 HLOS 的所有请求视为源自同一应用程序会话。
GNSS 驱动程序中对多个应用程序会话的支持具有使 HLOS 中的测试应用程序能够与 GNSS 适配器同时直接与 GNSS 驱动程序交互的优势。 测试应用程序和 GNSS 适配器是我们可以同时向单个 GNSS 驱动程序请求不同会话的不同应用程序。 如果不支持多个应用程序会话，则需要通过 OS 位置平台测试 GNSS 驱动程序，否则应停止承载 OS 位置平台的服务，以避免干扰测试应用程序。
修复会话： 从基础驱动程序获取定位信息 (单次拍摄或跟踪) 的行为被抽象化为修复会话的概念。 驱动程序需要支持每个受支持会话类型的至少一个修复会话。 会话类型在 GNSS_FIXSESSIONTYPE 枚举下定义。
GNSS 驱动程序必须至少支持单次修复会话。
支持基于距离的跟踪修复会话的驱动程序必须同时支持单次定位会话和基于距离的跟踪修复会话。
支持基于时间的跟踪修复会话的驱动程序必须同时支持单次修复会话和基于时间的跟踪修复会话。
支持基于距离的跟踪修复会话和基于时间的跟踪修复会话的驱动程序必须同时支持单次拍摄修复会话、基于距离的跟踪修复会话和基于时间的跟踪修复会话。
驱动程序是否支持多个同时修复会话由明确定义的驱动程序功能参数表示。 如果驱动程序未显式支持多个并行修复会话，则如果相同修复类型的会话已启动并处于活动状态，则必须使新的修复会话请求失败。 如果不存在多个修复会话支持，则负载位于 HLOS 组件上，以确保来自高级应用程序的多个 GNSS 请求多路复用并映射到对 GNSS 驱动程序的单个修复会话请求。
GNSS 驱动程序不需要支持同一类型的多个并行修复会话。 事实上，在Windows 10中，HLOS GNSS 适配器不支持利用 GNSS 驱动程序功能具有同一类型的多个修复会话，因此暂时不鼓励 IHV 在此功能上进行投资。 在将来的版本中，将考虑使 GNSS 适配器能够针对从位置平台的上层获取的每个修复请求直接启动与 GNSS 驱动程序的会话，而不是自行执行会话多路复用。 支持 GNSS 适配器中的修复会话多路复用可简化驱动程序实现，因为它不需要处理应用程序或多路复用实现的相同类型的多个会话，它减少了驱动程序中的内存使用量，并且不需要 GNSS 适配器来处理 HLOS 启动比 GNSS 驱动程序支持的更多修复会话的情况。 不同层级的设备和不同的驱动程序将支持不同数量的并发修复会话，因此需要处理此情况，这增加了 GNSS 适配器处理所有情况的复杂性。 因此，在Windows 10 GNSS 适配器将仅实现每个受支持类型的单个修复会话，并且将忽略驱动程序的多个修复会话支持，直到我们需要此功能。
每个修复会话都是有状态的，必须遵循以下明确定义的序列：
启动修复会话
获取一个或多个修补程序
根据需要修改修复会话
这至少在 GNSS 适配器处理相同类型的修复会话的多路复用之前是必需的，以后甚至可能需要处理比 GNSS 驱动程序支持的数量更多的同时修复会话的情况。
- 停止修复会话
修复会话由修复会话 ID 唯一标识。 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 设备必须能够进入低功耗 D2 (在没有修复会话或卸载操作且 USB 总线接口进入暂停状态后暂停) 状态。 所有睡眠和唤醒电源转换信号必须通过 USB 总线发出。 如果 GNSS 设备具有修复会话活动或卸载操作，则设备必须能够使用带内 USB 恢复信号将 SoC 或核心芯片从连接待机状态唤醒。 SoC 或核心芯片必须能够从最低功率状态唤醒，以响应来自 GNSS 设备的带内 USB 恢复信号。
不支持连接待机的设备将在设备进入新式待机或休眠状态时取消所有卸载操作。 这包括地理围栏卸载、距离跟踪或定期跟踪会话。
当设备进入连接待机状态时，支持连接待机的设备将继续让所有卸载操作处于活动状态，并且 GNSS 设备应尽可能高效地继续跟踪操作，并应在地理围栏触发条件或跟踪会话更新相关时向 HLOS 提供通知。 如果支持连接待机的设备中没有卸载操作，则 GNSS 设备应尽可能进入最低功率状态，但仍能够侦听来自 HLOS 的位置会话请求。 在支持 SUPL 的设备中，GNSS 设备和 SUPL 堆栈还必须能够在处于连接待机状态时唤醒 NI 通知。
有关驱动程序电源管理的一般信息，请参阅驱动程序的 电源管理责任。
电源注意事项：GNSS 驱动程序堆栈必须将电源占用量作为主要设计目标考虑在内，并尽量减少使main处理器尽可能保持唤醒状态。 所有高级功能都支持 (，例如不同的修复类型) 必须以节能的方式执行，例如，main应用处理器不需要超过所需的活动，并且大多数处理都可以卸载到芯片集/低功耗处理器。 一般情况下，除非 HLOS 另有指示，否则 GNSS 驱动程序必须始终将功耗视为最重要的约束，并且必须设计为以最小的功率占用量执行正常操作。 GNSS 驱动程序接口明确设计为允许移动设备尽可能频繁地转换为低功率模式，并为 GNSS 驱动程序提供必要的电源相关提示以优化电源使用情况。 对于需要长时间运行的普遍位置监视的跟踪、地理围栏和其他功能，GNSS 驱动程序/引擎必须利用低功耗硬件/处理器。 如果此类功能必须在驱动程序中使用暴力轮询机制实现，或者需要在应用处理器中实现，则驱动程序不应将自身声明为能够执行此类操作。 这将允许 HLOS 限制向平台的其余部分公开此类功能，或者基于其他平台服务/基元使用这些功能的替代实现。
编程语言： GNSS 驱动程序接口作为 C 语言头文件交付，该文件不使用任何 C++ 特定语言基元 (例如结构继承) 。 这允许 IHV 在 C 和 C++ 之间进行选择。 GNSS 接口头文件使选择对 IHV 开放。
筛选器驱动程序： 限制 GNSS 设备堆栈的方式不得阻止在堆栈中添加将来的筛选器驱动程序以支持扩展功能。 IHV 提供的 GNSS 驱动程序不得在驱动程序堆栈的顶部或底部包含其自己的筛选器驱动程序。
通知和事件： 由于 WDF 驱动程序无法向 HLOS 发送未经请求的通知，因此始终至少有一个从 HLOS 启动的挂起 IRP，用于接收来自驱动程序层的任何此类未经请求的通知。 这包括系统处于连接待机状态的情况。 对于 GNSS 驱动程序，此类未经请求的通知包括 (但不限于) 网络发起的请求、AGNSS 支持的帮助数据、其他特定于供应商的通知。 HLOS 将确保始终存在挂起的 I/O 请求来处理此类通知。
用户模式 IHV 扩展： IHV 可以编写通过 IHV 定义的专用 IOCTL 与 GNSS 驱动程序交互的附件用户模式组件。 如果 GNSS 驱动程序处于内核模式，则尤其需要此功能，在这种情况下，它无法访问用户模式 (中独占提供的功能，例如，Wi-Fi 扫描、连接管理器 API 等) 。 请注意，对于 Windows 10 中的 UMDF 2.0，UMDF GNSS 驱动程序不需要单独的用户模式组件，尽管 IHV 可能仍可实现单独的用户模式组件。 这些用户模式组件仅被视为 GNSS 驱动程序的扩展，并将被视为 IHV 提供的 BSP 删除的一部分。 Microsoft 提供的 HLOS 组件不了解此类组件的确切实现细节以及 IHV 用户模式/内核模式组件之间的交互机制。 如果 GNSS 驱动程序编写为使用用户模式 IHV 扩展的 UMDF 2.0 驱动程序，则不建议这样做，因为此模型可能需要更多内存使用量。
用户模式 IHV 扩展必须符合以下规则：
公共 GNSS 驱动程序 IOCTL 的语义和行为必须不受用户模式 IHV 扩展及其与 GNSS 驱动程序的交互影响和干扰。
用户模式扩展必须符合Windows 10平台施加的安全、电源和其他平台基础知识和策略。
用户模式扩展必须仅执行 Microsoft 批准的授权活动，而不让 OS 平台在运行时强制/验证此类授权。
Microsoft 仍可以强制实施安全策略并控制此类组件的生存期。 此处的关键是，IHV 用户模式组件不应指望在平台上强制实施此类策略，因为扩展组件被视为受信任的 OS 组件。
IHV 不会添加任意功能或使用未经授权的 OS 服务/安全资源。
最低支持要求
全球导航卫星系统 (GNSS) 设备将大量用于 Windows 平台，以满足不同设备层的需求， (低成本、高端、不同设备类型等) 。 若要启用如此丰富的生态系统并增加平板电脑、笔记本电脑和其他设备类型（可以以较低成本包含 GNSS 芯片）的数量，Microsoft 不需要所有 GNSS 设备都支持 GNSS 驱动程序参考中所述的完整功能集。 下表提供了不同设备类型所需的最低功能以及可选或推荐的功能的高级视图。
| 功能 | 所有平台的要求 | 电话的具体要求 | 备注 |
|---|---|---|---|
| 准确报告GNSS_DEVICE_CAPABILITIES | 必需 | 最低功能要求 | |
| 支持 MultipleFixSessions | 可选 | GNSS 适配器不支持 | |
| 支持 MultipleAppSessions | 建议 | ||
| GNSS 协助支持 (IHV 特定) | 建议 | 必需 | |
| 通过 Microsoft (使用Agss_inject IOCTL) 获取 GNSS 协助支持 | 建议 | ||
| 支持完整的GNSS_FixData结构 | 必需 | ||
| 单次会话 | 必需 | ||
| 基于时间的跟踪会话本机支持 | 可选 | 如果支持，它必须包含修改会话参数的支持。 | |
| 基于距离的跟踪会话本机支持 | 可选 | 如果支持，它必须包含修改会话参数的支持。 | |
| 上次正常的已知会话 | 可选 | ||
| 地理围栏本机支持 | 可选 | 建议 | 仅需要并支持圆形地理围栏 |
| 提供 ChipsetInfo | 必需 | 使用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驱动程序命令 | 可选 |