通过

全球导航卫星系统 (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 处理代理指向进程外应用程序的接口指针，以便应用程序将 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 设备) 接口。

支持全球导航卫星系统 (GNSS) 遵循旧版 Windows 模型的设备和驱动程序

Windows 10 中的位置平台支持通过旧版 Sensors v1.0 类驱动程序集成的 GNSS 设备 (请参阅编写位置传感器驱动程序) 或通过 GNSS 驱动程序参考中所述的新 GNSS DDI 集成。

因此，具有与 Windows 7、Windows 8 和 Windows 8.1 中存在的传感器 v1.0 类扩展模型集成的 GNSS 设备的 Windows 设备应继续在Windows 10中工作，而无需进行任何更改。 强烈建议将这些驱动程序 (和任何新驱动程序) 发布到Windows 更新，以改善用户的升级过程。

硬件实验室工具包 (HLK) 中还会发布两组不同的 GNSS 设备测试，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 平台提供的支持建立了共识。 作为此 GNSS 接口定义的一部分，Microsoft 对功能方面进行了明确定义，并且随着 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 驱动程序中或在应用程序处理器) 、基于时间的跟踪会话和基于距离的跟踪会话中运行的服务中实现。 这两种类型的本机跟踪会话main好处是，通过在 SOC 中执行更多处理，仅在需要时报告更改，使应用程序处理器 (AP) 休眠更长时间，从而可能节省电源。 与基于本机时间的跟踪会话相比，对基于本机距离的跟踪的支持更具影响力，因为它可以节省更高的功率，并且应用程序使用范围更广。

从 GNSS 驱动程序检索位置信息的行为通过有状态的唯一修复会话执行，其中包括以下操作：

  1. 启动修复会话： 由于 LBS 应用程序) 发出请求，GNSS 适配器 (启动修复会话。 GNSS 适配器设置与请求的特定要求和首选项关联，并通过发出控制代码 IOCTL_GNSS_START_FIXSESSION使 GNSS 驱动程序启动引擎以获取修补程序。

  2. 获取设备位置 (修复数据) ： 启动修复会话后，GNSS 适配器会发出控制代码 IOCTL_GNSS_GET_FIXDATA 开始等待驱动程序的修复。 当引擎提供新的位置信息时，GNSS 驱动程序会响应此挂起的获取修复请求。

    如果修复会话类型是 LKG 修复 (而不是当前修复) ，则位置信息来自驱动程序的缓存。

    GNSS 适配器确保异步 I/O 请求始终可供 GNSS 驱动程序使用，以便在可用时返回修复数据。 根据修复的性质，如果预期有更多修复数据，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 创建一个或多个地理围栏，驱动程序应将其发送到硬件以开始跟踪它们。

  • HLOS 应能够通过 DDI 删除一个或多个以前创建的地理围栏，驱动程序应将其发送到硬件以停止跟踪它们。

  • 理想情况下，GNSS 硬件应了解每个地理围栏的初始地理围栏跟踪状态，并使用它来仅报告此初始状态的更改。 如果 GNSS 硬件不支持此功能，则每次创建地理围栏时，它都会向 HLOS 报告初始状态。

  • GNSS 硬件以节能方式跟踪设备的当前位置，并在设备进入和/或退出跟踪的地理围栏时唤醒 AP。 GNSS 驱动程序将地理围栏警报传递给 HLOS。

  • 在低卫星信号和其他暂时性错误条件下，GNSS 引擎可能无法可靠地跟踪现有的地理围栏。 GNSS 引擎应能够检测跟踪中断，GNSS 驱动程序应将跟踪状态错误警报传递给 HLOS。 HLOS 将切换到基于 AP 的默认地理围栏跟踪，直到 GNSS 硬件能够恢复并再次跟踪地理围栏。

  • GNSS 引擎需要提供通知以指示无法跟踪地理围栏的确切条件将有所不同，实现将特定于 IHV。 下面是实现的一些准则：

    • 如果 GNSS 引擎能够高置信度地检测到用户未移动，并且 25 米或更短时间没有地理围栏边界，则 GNSS 引擎无需发送跟踪错误。

    • 如果 GNSS 引擎能够高置信度地检测到用户未移动，但地理围栏边界在 25 米或更短，则 GNSS 引擎需要在一分钟内发送跟踪错误。

    • 如果 GNSS 引擎已检测到用户正在移动，并且 100 米或更短范围内有地理围栏边界，则 GNSS 引擎需要在一分钟或更短时间内发送跟踪错误。

    • 如果 GNSS 引擎无法确定用户是否移动，并且 100 米或更短范围内有地理围栏边界，则 GNSS 引擎需要在一分钟或更短时间内发送跟踪错误。

    • 如果 GNSS 引擎一直在检测到用户正在移动，则 GNSS 引擎需要在一段时间内发送跟踪错误，该错误的时间与估计的移动速度和到最近的地理围栏的距离成正比。 建议在 [ (距离到最近围栏边界 (m) /估计速度 (m/s) ) - 15 秒内发送错误。 GNSS 引擎可以使用移动检测指示器来确定应发送跟踪错误的时间。

    • 如果 GNSS 引擎无法确定用户是否在移动，则 GNSS 引擎需要在与高速移动以及距离最近的地理围栏的距离成正比的时间内发送跟踪错误。 建议在 [距离最近的围栏边界 (m) / 343 (m/s) ] 内发送错误。

  • 在 GNSS 引擎报告地理围栏跟踪状态错误的期间，不应向 HLOS 发送地理围栏违规事件。

  • HLOS 可以通过单个命令删除以前创建的所有地理围栏来重置地理围栏跟踪。

  • 重新启动或驱动程序重启后，移动发起的地理围栏不会保留在 GNSS 硬件或驱动程序中。 HLOS 代表最终用户应用程序处理持久性，并根据需要创建/删除地理围栏。

就 GNSS 适配器与支持本机地理围栏卸载的 GNSS 引擎之间的交互而言，如果地理围栏跟踪失败，GNSS 适配器将执行以下操作：

  • 一旦 GNSS 驱动程序返回跟踪失败，它将使用基于 AP 的跟踪。

  • 它将继续将当前在 OS 级别跟踪的地理围栏 (添加/删除) 的任何更新推送到驱动程序，以便它们同步。这将帮助 GNSS 引擎知道操作系统当前正在跟踪哪些地理围栏，并且它可以使 可以根据最新数据跟踪/无法跟踪确定。

  • 一旦 GNSS 驱动程序发送回 SUCCESS 以跟踪功能，它将推送基于 AP 的跟踪器确定的地理围栏状态更改。

有关帮助和帮助程序数据的驱动程序通知

GNSS 驱动程序有时可能需要 GNSS 适配器的帮助数据或帮助程序操作。 这包括各种形式的 AGNSS 数据 (时间注入、星历、初始粗糙位置) 、支持网络启动的用户平面定位的用户同意弹出窗口等。

  • GNSS 驱动程序可以在不使用 GNSS 适配器的情况下获取 GNSS 协助数据。 不过，出于以下几个原因，建议使用 GNSS 适配器和利用 Microsoft 定位服务获取帮助数据：

    • Microsoft 位置堆栈将负责建立数据连接并遵守任何漫游约束、数据首选项、网络安静模式集成等。

    • Microsoft 定位服务可以通过服务器到服务器后端连接定期获取特定于 IHV 的协助数据，并将其提供给需要的所有设备，从而节省 IHV 在全球部署满足可用性、可伸缩性和响应性要求的前端协助服务的需求。

  • 用户对收件箱应用程序隐私的许可归操作系统所有。 因此，通知用户有关网络发起的位置请求的任何 UI 或任何 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 事件日志记录服务。 驱动程序在日志文件中记录消息 ID 和未格式化的二进制数据。 随后，后处理器将日志文件中的信息转换为用户可读的形式。 但是，WPP 软件跟踪支持比事件日志记录服务支持的消息格式更强大、更灵活。 例如，WPP 软件跟踪具有对 IP 地址、GUID、系统 ID、时间戳和其他有用数据类型的内置支持。 此外，用户可以添加与其应用程序相关的自定义数据类型。

移动运营商协议支持

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 客户端 (，并可能提供 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 标准要求基于 UICC 和/或使用通过 OMA-DM 或 OMA-CP 获取的 SUPL OMA 配置文件信息完成 SUPL 配置。

    (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 提供了一个 CSP，用于使用 OMA 配置并通过 GNSS 适配器将配置推送到 GNSS 驱动程序。

    或者，IHV 还可以编写用户模式组件，以使用手机特定的设备管理技术 (CSP) 使用移动运营商配置规范。 但是，这将给 IHV 带来额外的负担，不建议这样做。

    一个系统中仅支持一个 SUPL 配置，包括双 SIM 卡设备的情况。 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 平台提供的接口或常规功能。 下面是 IHV 可以利用其实现其 SUPL 客户端Windows 10中可用的功能列表：

此功能都不是定位平台或 GNSS DDI 的一部分，但此处包含此功能是为了澄清和帮助 GNSS 驱动程序开发人员了解可从 OS 中利用哪些功能来实现 SUPL 功能。

SUPL 客户端与 GNSS 驱动程序的交互。

  • 短信路由器： SMS 路由器使 SUPL 客户端能够订阅承载 SUPL NI 请求的 SIP 推送消息的 WAP 推送。

  • 连接管理器配置 SUPL 和 API 应使用哪个连接来请求此类连接的功能：移动运营商可能需要将 SUPL 流量设置为专用连接，或者仅在与默认 Internet 连接不同的连接上。 为此，连接管理器提供：

    • OEM 或移动运营商可用于配置应用于 SUPL 通信的连接的配置服务提供商。

    • 供 SUPL 客户端查询 SUPL 连接的连接参数的 API。

    • 使用上一步中获取的参数建立 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 信号，并在响应中提供信噪比 (信号或载波到噪声配给) 测量值。 理想情况下，测试应提供 10 Hz 的响应。

  2. 自测试： 此测试用于验证 GNSS 引擎的基本功能。 自测试应该能够检测引擎中的基本问题， (硬件有缺陷、GNSS 硬件中的错误连接，而无需注入任何外部信号。 此验证的目标是在设备经过更详尽且更昂贵的测试之前，执行这种廉价的测试，并将其用作生产线中的入口。 在此测试中，GNSS 引擎和驱动程序应对引脚连接执行自验证，并返回指示一切正常或发生故障的状态代码。 失败的错误代码必须指示检测到的错误。 错误代码由 IHV 设置。

I/O 注意事项

由于 GNSS 功能不会映射到对设备驱动程序的传统文件读取和写入请求， 因此 ReadFile 和 WriteFile 函数不会用于 GNSS 驱动程序 API。 所有 GNSS 功能都将使用明确定义的特定于 GNSS 的设备 I/O 控制 (DeviceIoControl) 请求（也称为 IOCTL）来实现。

所有 IOCTL 都将使用 METHOD_BUFFERED 作为输入和输出数据的数据传输机制。 由于 GNSS 相关数据的大小相对较小，因此额外的缓冲区副本不应影响系统性能。

将使用 CreateFile 函数中的 FILE_FLAG_OVERLAPPED 选项打开 GNSS 驱动程序。 因此，所有 IOCTL 都是隐式异步的。 但是，尽管大多数 GNSS IOCTL 在语义上是异步的 (例如，IOCTL 会触发驱动程序中的活动，并且预期结果会异步返回) ，但某些 IOCTL 在语义上是同步的，也就是说，此类 IOCTL 没有涉及逻辑异步操作或活动。 通过发出 DeviceIoControl 调用后阻止 GNSS 适配器线程，直到 I/O 操作完成，可以实现这几个 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 驱动程序参考中详细介绍了 GNSS IOCTL 和关联的数据结构。

基于距离的跟踪会话

基于距离的跟踪会话经常被最终用户应用程序使用，因为以前，它是 .NET API 中唯一可用的会话类型。 距离值为 0 表示 GNSS 引擎应以可能的最高速率提供修复。

仅当 GNSS 驱动程序指示其具有 SupportDistanceTracking 功能时，GNSS 适配器才会启动与 GNSS 驱动程序的距离跟踪会话。

针对距离跟踪会话向驱动程序发送的开始修复请求将包括所需的水平精度和移动阈值，即系统在 GNSS 驱动程序提供位置更新之前应覆盖的以米为单位的正向距离。 GNSS 引擎可以使用这些值来了解应用程序请求的意图并做出智能决策，例如调整检查位置的频率。

驱动程序收到启动修复请求后，它应开始返回引擎生成的任何中间修补程序，直到获得最终修补程序。 这将被视为会话的第一个位置。 在此之后，GNSS 引擎应开始提供修复，只要它检测到已经大致覆盖了长距离。

如果 GNSS 引擎确定它无法再跟踪设备 (的位置，例如，如果卫星在) 不再可见，它应向 GNSS 适配器返回错误，以便位置平台可以回退到其他机制，以便为最终用户应用程序提供位置更新。 GNSS 适配器应在以下时间内提供错误：

[ (保持距离-自上次已知位置 (m) /估计速度 (m/s) ) – 5 秒]或 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 适配器指示其具有 SupportContinuousTracking 功能时，GNSS 适配器才会启动与 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 引擎可能能够同时处理单次拍摄会话，具有 Distance-Based 和/或 Time-Based 跟踪会话。 理想情况下，独立会话不应相互影响，但这并非始终可行，特别是在同时单次拍摄和基于时间的跟踪会话的情况下。 本部分提供有关 IHV 实现的一些准则，以防需要入侵来处理不同类型的同时会话。

本部分使用以下首字母缩略词：

  • SS： 单次拍摄会话

  • Dbt： 基于距离的跟踪会话

  • TBT：基于时间的跟踪会话

  • TBF： 修复之间的时间

下表提供了一些用于同时处理单次拍摄和基于时间的跟踪会话的方案：

案例 SS 处于活动状态？ TBT 处于活动状态？ 案例详细信息 可接受的修复间隔 注释
1 X X SS 会话在 TBT 定期会话开始时持续，剩余超时 >= 间隔 与 TBT 间隔相同 SS 会话行为：

将发送中间和最终修复，直到超时。

会话在收到停止后立即关闭。

TBT 会话行为：

发送中间和最终修复。

大约根据间隔接收的修补程序。

会话在收到停止后立即关闭。
2 X X 在 TBT 定期会话以剩余超时 < 间隔启动时，SS 会话仍在进行 间隔与 SS 超时相同，直到满足 SS 会话。
然后，可将间隔更新为与 TBT 间隔相同。		 SS 会话行为：

将发送中间和最终修复，直到超时。

会话在收到停止后立即关闭。

TBT 会话行为：

发送中间和最终修复

根据间隔接收的修补程序大致为 ，但在提供 SS 会话时可能会更频繁。

会话在收到停止后立即关闭。
3 X X SS 会话在持续 TBT 定期会话以超时 >= 间隔启动时启动 与 TBT 间隔相同 SS 会话行为：

将发送中间和最终修复，直到超时。

会话在收到停止后立即关闭。

TBT 会话行为：

发送中间和最终修复

大约根据间隔接收的修补程序。

会话在收到停止后立即关闭。
4 X X SS 会话在持续 TBT 定期会话以超时 < 间隔启动时启动 在满足 SS 会话之前，间隔更改与 SS 超时相同。 然后，可将间隔更新为与 TBT 间隔相同。 SS 会话行为：

将发送中间和最终修复，直到超时。

会话在收到停止后立即关闭。

TBT 会话行为：

发送中间和最终修复。

根据间隔接收的修补程序大致为 ，但在提供 SS 会话时可能会更频繁。

会话在收到停止后立即关闭。
5 X TBT 定期会话以修改间隔启动 使用调制解调器的会话将更新为与 TBT 间隔相同的新间隔。 如果需要，将重启调制解调器会话。 SS 会话行为：

不适用

TBT 会话行为：

发送中间和最终修复。

大约根据间隔接收的修补程序。

会话在收到停止后立即关闭。
6 X X SS 会话在正在进行的 TBT 定期会话收到间隔更改时进行，剩余超时 >= 间隔 与 TBT 间隔相同 SS 会话行为：

将发送中间和最终修复，直到超时。

会话在收到停止后立即关闭。

TBT 会话行为：

发送中间和最终修复

大约根据间隔接收的修补程序。

会话在收到停止后立即关闭。
7 X X SS 会话在正在进行的 TBT 定期会话收到间隔更改时进行，剩余超时 < 间隔 间隔更改与 SS 剩余超时相同，直到满足 SS 会话。 然后，可将间隔更新为与 TBT 间隔相同。 SS 会话行为：

将发送中间和最终修复，直到超时。

会话在收到停止后立即关闭。/li>
TBT 会话行为：

发送中间和最终修复

根据间隔接收的修补程序大致为 ，但在提供 SS 会话时可能会更频繁。

会话在收到停止后立即关闭。

如果同时存在基于时间的跟踪会话和基于距离的跟踪会话，则可以将 GNSS 引擎精度跟踪设置为使用这两个会话中的最小一个。 下表还提供了一些关于不同值的情况的一些准则，以便在同时进行单次拍摄和跟踪会话时所需的准确性：

案例 SS 准确度 DBT 或 TBT 准确性 总体 GNSS 引擎准确性 注释
1 中/低 --> 高 不适用 中/低 --> 高 SS 会话行为：

使用 GNSS 设备的会话会刷新或重启，以获得高准确度结果。 在 HLOS 可用时，会向 HLOS 提供中间修补程序。
2 高 --> 中/低 不适用 高 --> 中/低 SS 会话行为：

使用 GNSS 设备的会话将刷新或重启，以获取中/低准确度结果。 如果满足要求的修补程序已可用，则会将其作为最终修复返回。 否则，中间修补程序会提供给 HLOS，因为它们可用。
3 中/低 --> 高 高 高 SS 会话行为：

鉴于 DBT 或 TBT 会话已存在高准确度会话，SS 会话只是为 HLOS 提供中间的进一步修复，直到获得所需的最终准确性或获得最终修补程序。
4 高 --> 中/低 高 高 SS 会话行为：

鉴于 DBT 或 TBT 会话已存在高准确度会话，SS 会话只是为 HLOS 提供中间的进一步修复，直到获得所需的最终准确性或获得最终修补程序。
5 中/低 --> 高 中/低 中/低 --> SS 会话完成后，高然后返回到中/低 SS 会话行为：

刷新或重启与 GNSS 设备的会话以获取高精度结果。 在 HLOS 可用时，会向 HLOS 提供中间修补程序。

DBT 或 TBT 会话行为：

此会话可以暂时接收高准确度结果。 但是，在提供 SS 会话后，此会话的准确性应返回中/低。
6 高 --> 中/低 中/低 高 --> 中/低 SS 会话行为：

与 GNSS 设备的会话将刷新或重启，以获得中/低精度结果。 如果满足要求的修补程序已可用，则会作为最终修补程序返回。 否则，会向 HLOS 提供中间修补程序，因为它们可用。
7 不适用 中/低 --> 高 中/低 --> 高 b>DBT 或 TBT 会话行为：** 刷新或重启 GNSS 设备的会话以获取高精度结果。 在 HLOS 可用时，会向 HLOS 提供中间修补程序。
8 不适用 高 --> 中/低 高 --> 中/低 DBT 或 TBT 会话行为：

与 GNSS 设备的会话将刷新或重启，以获得中/低精度结果。 如果满足要求的修补程序已可用，则会作为最终修补程序返回。 否则，会向 HLOS 提供中间修补程序，因为它们可用。
9 高 中/低 --> 高 高 DBT 或 TBT 会话行为：

会话已获得高精度修复或中间修复，因此没有变化。
10 高 高 --> 中/低 SS 会话完成后，高则更改为中/低 DBT 或 TBT 会话行为：

会话可以继续获取高精度修补程序或中间修复，直到 SS 会话完成。 然后，它将更改为中/低精度修复。
11 中/低< 中/低 --> 高 中/低 --> 高 DBT 或 TBT 会话行为：

刷新或重启与 GNSS 设备的会话以获取高精度结果。 在 HLOS 可用时，会向 HLOS 提供中间修补程序。
12 中/低 高 --> 中/低 高 --> 中/低 DBT 或 TBT 会话行为：

与 GNSS 设备的会话将刷新或重启，以获得中/低精度结果。 如果满足要求的修补程序已可用，则会作为最终修补程序返回。 否则，会向 HLOS 提供中间修补程序，因为它们可用。