IOCTL_GNSS_CREATE_GEOFENCE IOCTL (gnssdriver.h)

GNSS 适配器使用 IOCTL_GNSS_CREATE_GEOFENCE 控制代码来创建地理围栏。

适用于 GNSS DDI 版本 2 及更高版本。

主要代码

IRP_MJ_DEVICE_CONTROL

输入缓冲区

指向 GNSS_GEOFENCE_CREATE_PARAM 结构的指针,该结构定义要创建的地理围栏。

输入缓冲区长度

将 设置为 sizeof (GNSS_GEOFENCE_CREATE_PARAM) 。

输出缓冲区

指向 GNSS_GEOFENCE_CREATE_RESPONSE 结构的指针。

输出缓冲区长度

将 设置为 sizeof (GNSS_GEOFENCE_CREATE_RESPONSE) 。

状态块

Irp->如果请求成功,IoStatus.Status 设置为 STATUS_SUCCESS。 否则, 状态 为相应的错误条件作为 NTSTATUS 代码。

注解

GNSS 适配器说明

如果调用成功,GNSS 引擎将注册地理围栏并分配唯一 ID。 GNSS 适配器使用唯一 ID 与驱动程序有关此特定地理围栏的所有交互。

如果调用失败,GNSS 驱动程序必须确保 GNSS 引擎最终不会创建地理围栏并开始跟踪它。 在添加此地理围栏之前,故障应将 GNSS 引擎的状态回滚到以前的状态。

GNSS 适配器不希望驱动程序在驱动程序重启时保留地理围栏。 GNSS 适配器在适当时间通过 GNSS_ResetGeofencesTracking 命令显式清除 GNSS 驱动程序中的所有地理围栏, (初始化、跟踪故障后的状态更改等 ) 。

GNSS 驱动程序说明

如果这是第一个地理围栏,GNSS 驱动程序应启动地理围栏跟踪,继续以高效电源的方式监视设备的当前位置的地理围栏,并在地理围栏被破坏时引发警报。 如果 GNSS 引擎由于信号条件不佳或) 的其他暂时性错误而无法跟踪地理围栏 (,则必须通过 LISTEN_GEOFENCES_TRACKINGSTATUS 事件引发错误状态。

GNSS 引擎必须遵守以下地理围栏跟踪准则:

  • 必须优化设备跟踪操作和漏洞检测,以考虑地理围栏的大小和面积。 如果所有条件都相同,则与较小的地理围栏相比,较大的地理围栏的跟踪力度应该更低。

  • 必须动态优化设备跟踪操作,以考虑到地理围栏相对于当前位置的相对距离。 所有条件均等,与距离较近的地理围栏相比,跟踪距离较远的地理围栏应不那么积极,攻击应随着设备离地理围栏越来越近而增加。

  • 对于进入和退出,漏洞检测机制必须是非对称的。 一般情况下,与确定进入地理围栏的规则相比,确定退出地理围栏的规则应放宽。

  • 漏洞检测机制必须考虑到由于设备位置固有的不准确而导致的潜在误报。 例如,如果设备悬停在地理围栏边缘附近,则次优漏洞检测机制可能会连续生成过多的进入和退出事件,即使设备没有物理移入和移出。非对称退出检测和滞后是避免此类错误的典型措施。

  • GNSS 引擎的设备跟踪操作必须使用所有形式的可用位置更改信号,这些信号要么在 SoC 上可用,要么可以在低功耗下使用。 此类信号可能包括(但不限于)来自加速计和其他传感器的数据、手机网络信号更改、WiFi 连接/断开连接等。

  • 必须在 SoC 上的 GNSS 引擎中完全实现地理围栏跟踪和漏洞检测操作。 应用程序处理器上的 GNSS 驱动程序和任何其他扩展组件都不应唤醒设备跟踪或漏洞检测。

  • GNSS 驱动程序和 GNSS 引擎必须公开记录的特定于 IHV 的优化参数,以促进地理围栏跟踪功能的性能和电源优化。 Microsoft 和 OEM 将使用优化参数,并确定端到端地理围栏体验的服务质量、可靠性和电源成本之间的适当平衡。 可以通过注册表设置或 IHV SoC 配置数据提供优化参数。

要求

要求
Header gnssdriver.h (包括 Gnssdriver.h)

另请参阅

在驱动程序中创建 IOCTL 请求

WdfIoTargetSendInternalIoctlOthersSynchronously

WdfIoTargetSendInternalIoctlSynchronously

WdfIoTargetSendIoctlSynchronously