Arquitectura del controlador del sistema satélite de navegación global (GNSS)

Proporciona información general sobre la arquitectura del controlador UMDF 2.0 del sistema de navegación global satélite (GNSS), consideraciones de E/S y describe varios tipos de sesiones de seguimiento y corrección.

Introducción a la arquitectura

En el siguiente diagrama de bloques de componentes de alto nivel se muestra cómo se integra el controlador UMDF 2.0 del sistema satélite de navegación global (GNSS) con la plataforma Windows 10.

Los componentes del diagrama se describen aquí:

• Aplicación LBS: Una aplicación de usuario que usa la funcionalidad de ubicación de la plataforma Windows 10

• Aplicación de prueba: Una aplicación para probar la funcionalidad de GNSS.

• API de GNSS: La interfaz COM (Modelo de objetos componentes) de IGnssAdapter que expone la funcionalidad del dispositivo GNSS a los componentes internos del servicio de ubicación, así como para probar aplicaciones. La forma exacta de esta API está fuera del ámbito de este documento. Los componentes de Windows usan el dispositivo GNSS mediante la programación en la interfaz COM de IGnssAdapter . El conjunto de API de GNSS es una API exclusiva para los componentes de la plataforma de ubicación (por ejemplo, el servicio de ubicación y las aplicaciones de prueba de ubicación) y no está disponible para otras aplicaciones de primera parte o de terceros.

• Adaptador GNSS: Se trata de un objeto COM singleton que implementa la interfaz COM IGnssAdapter . Las aplicaciones de prueba y los componentes internos del servicio de ubicación crean una instancia de este objeto y utilizan el dispositivo GNSS a través de la interfaz IGnssAdapter. El componente del motor de posicionamiento GNSS del servicio de ubicación implementa la clase COM que expone la interfaz IGnssAdapter . El servicio de ubicación expone un mecanismo de fábrica para las pruebas y otras aplicaciones fuera de proceso, lo que permite instanciar un objeto COM singleton de la clase COM del adaptador GNSS dentro del servicio de ubicación. Las aplicaciones fuera de proceso usan el puntero de interfaz COM para programar con el controlador GNSS.

  COM controla el puntero de interfaz mediante el proxy hacia las aplicaciones fuera de proceso, para que las aplicaciones puedan tratar el puntero de interfaz IGnssAdapter como un objeto COM en proceso; sin embargo, las llamadas se controlan realmente mediante el objeto adaptador GNSS singleton dentro del servicio de ubicación.

  El motor de localización GNSS utiliza el objeto de adaptador GNSS interno para proporcionar funcionalidad específica para la localización al servicio de localización. El adaptador de GNSS abre un identificador de archivo para el controlador GNSS mediante la API CreateFile y, a continuación, ajusta las llamadas de las API nativas de GNSS a las llamadas DeviceIoControl adecuadas, mantiene la máquina de estado con el objeto de controlador GNSS y mantiene el estado de las distintas solicitudes entrantes de las capas superiores. Este componente interactúa directamente con la pila de dispositivos GNSS subyacente a través de la interfaz IOCTL de GNSS pública definida en este documento. El dispositivo GNSS se trata lógicamente como un recurso exclusivo y, por tanto, el adaptador de GNSS singleton controla todo el acceso al dispositivo GNSS.

  Algunas aplicaciones de prueba de controladores de caja blanca también pueden usar la interfaz IOCTL del controlador GNSS directamente en un entorno de no producción en lugar de usar el adaptador GNSS a través de las API privadas de GNSS. Sin embargo, estas aplicaciones de prueba tendrán que implementar su propia máquina de estado y procesamiento para imitar ciertas funcionalidades del adaptador GNSS.

• Controlador GNSS: Un controlador entregado por IHV implementado mediante UMDF 2.0. El controlador GNSS admite las API DeviceIoControl de GNSS al interactuar con el hardware GNSS real. El controlador GNSS también funciona como mediador o integrador para las funciones SUPL.

• Dispositivo o motor de GNSS: Se trata de un componente conceptual que encapsula las partes de soC y hardware del dispositivo GNSS. Un IHV puede optar por implementar la mayor parte de la funcionalidad de GNSS dentro de este componente, lo que hace que la capa del controlador GNSS sea muy delgada (básicamente un adaptador para interactuar con el dispositivo GNSS).

Compatibilidad con dispositivos y controladores del sistema satélite de navegación global (GNSS) que siguen el modelo heredado de Windows

La plataforma de ubicación de Windows 10 admite dispositivos GNSS integrados a través del controlador de clase Sensors v1.0 heredado (consulte Escritura de un controlador de sensor de ubicación) o integrado a través de la nueva DDI de GNSS descrita en la referencia del controlador GNSS.

Por lo tanto, se espera que los dispositivos Windows con un dispositivo GNSS que se integren con el modelo de extensión de clase Sensor v1.0 que existía en Windows 7, Windows 8 y Windows 8.1 seguirán funcionando en Windows 10 sin necesidad de realizar ningún cambio. Se recomienda encarecidamente que estos controladores (y los nuevos controladores) se publiquen en Windows Update para mejorar el proceso de actualización para nuestros usuarios.

También habrá dos conjuntos diferentes de pruebas para dispositivos GNSS en el Hardware Lab Kit (HLK) emitido con Windows 10:

• Un nuevo conjunto de pruebas para certificar controladores de acuerdo con el nuevo modelo.

• Otro conjunto de pruebas para certificar los controladores siguiendo el modelo anterior. Serán el mismo conjunto de pruebas que estaban disponibles en WHCK en Windows 8.1.

Un nuevo componente del recopilador en el HLK identifica cuál de los dos conjuntos de pruebas debe ejecutarse en un sistema, si existe.

Coexistencia de dispositivos del sistema satélite de navegación global (GNSS)

En el caso poco frecuente de varios dispositivos GNSS detectados en un sistema, la plataforma de ubicación solo usará un dispositivo, principalmente para reducir el consumo general de energía en el sistema. Se han considerado las siguientes suposiciones:

• Es probable que los dispositivos que usen la nueva DDI sean más recientes y, por lo tanto, es más probable que tengan un mejor consumo de energía, admitan más constelaciones y admitan una mejor asistencia. Por lo tanto, si se detecta un dispositivo que usa el modelo de controlador antiguo y un dispositivo mediante el nuevo modelo de controlador, este último sería el seleccionado.

• Si un usuario conecta un dispositivo GNSS externo cuando hay un dispositivo GNSS interno, es más probable que el usuario quiera que se use este dispositivo externo.

El comportamiento de la plataforma de ubicación, en función de estas suposiciones será el siguiente:

• Caso de dos controladores heredados coexistentes: para evitar problemas de compatibilidad con versiones anteriores, el comportamiento será el mismo que en Windows 8.1, en el que los dispositivos GNSS se usan simultáneamente y una de las respuestas se comunica en la pila a las aplicaciones.

• Caso de un controlador heredado en el dispositivo y un nuevo controlador conectado externamente: se usa el dispositivo GNSS conectado externamente.

• Caso de un nuevo controlador en el dispositivo y un nuevo controlador conectado externamente: se usa el dispositivo GNSS conectado externamente.

Si el dispositivo GNSS seleccionado admite geocercas u otras operaciones delegadas, la descarga se realizará mientras se usa ese dispositivo. El adaptador de GNSS no dividirá la funcionalidad ni las sesiones entre varios dispositivos GNSS.

Introducción a la interfaz del sistema satélite de navegación global (GNSS)

La interacción entre el adaptador GNSS y el controlador GNSS se encuentra en las siguientes categorías:

Intercambio de información de funcionalidad

Para admitir la extensibilidad y la adaptación de la pila de GNSS en plataformas Windows, el adaptador GNSS y el controlador GNSS establecen un conocimiento común de las diversas funcionalidades bien definidas de la pila GNSS subyacente, así como la compatibilidad proporcionada por la plataforma Windows. Los aspectos de las capacidades están bien definidos por Microsoft como parte de esta definición de interfaz GNSS y evolucionarán a medida que más innovación continúe en el espacio GNSS y surja un conjunto diverso de conjuntos de chips o controladores en el mercado. El adaptador GNSS consulta las distintas funcionalidades del controlador o dispositivo GNSS subyacente en el momento de la inicialización o según sea necesario y, en consecuencia, optimiza la interacción con el controlador GNSS.

El intercambio de información de funcionalidad entre el adaptador GNSS y el controlador GNSS se realiza mediante los códigos de control IOCTL_GNSS_SEND_PLATFORM_CAPABILITY y IOCTL_GNSS_GET_DEVICE_CAPABILITY.

Comando y configuración del controlador del sistema satélite de navegación global (GNSS)

El adaptador GNSS puede realizar una configuración única o volver a configurar periódicamente el controlador GNSS. Del mismo modo, el adaptador GNSS puede ejecutar determinados comandos específicos de GNSS a través del controlador. Esto se logra definiendo un protocolo de ejecución de comandos entre el controlador y el sistema operativo de alto nivel (HLOS). Dependiendo del tipo de comando específico, la acción prevista puede surtir efecto inmediatamente o después de reiniciar el sistema. De forma similar a la información de funcionalidad del dispositivo GNSS, los comandos GNSS también están bien definidos por Microsoft como parte de esta definición de interfaz GNSS y seguirá evolucionando con futuras innovaciones y diversificación de dispositivos o controladores GNSS.

La ejecución y la configuración del comando del dispositivo se realizan mediante el código de control IOCTL_GNSS_SEND_DRIVERCOMMAND.

Información de posición

Esta es la función principal del dispositivo GNSS subyacente. En el formato más básico, el adaptador GNSS solicita la posición actual del dispositivo desde el controlador GNSS. Las variaciones de la solicitud de posición incluyen (pero no están limitadas a) los siguientes tipos de sesiones de posición:

• Posición actual del dispositivo (corrección de captura única)

• Flujo periódico continuo de correcciones (seguimiento basado en tiempo)

• Flujo continuo de correcciones en función del umbral de movimiento (seguimiento basado en distancia)

El único tipo de sesión de posición obligatoria requerido por cada hardware GNSS y el controlador GNSS es el tipo de sesión de corrección de captura única. Nativo (implementado en el SOC, en el dispositivo GNSS y no en el controlador GNSS o en un servicio que se ejecuta en el procesador de aplicaciones), las sesiones de seguimiento basadas en el tiempo y las sesiones de seguimiento basadas en distancia se pueden admitir opcionalmente. La principal ventaja para estos dos tipos de sesiones de seguimiento nativas es un ahorro de energía potencial al mantener inactivo el procesador de aplicaciones (AP) durante más tiempo haciendo más del procesamiento en el SOC y notificando solo los cambios cuando sea necesario. La compatibilidad con el seguimiento nativo basado en distancia es más significativa que las sesiones de seguimiento nativo basadas en tiempo, ya que puede aportar un mayor ahorro de energía y porque las aplicaciones lo usan de manera más generalizada.

La acción de recuperar información de posición del driver GNSS se produce a través de una sesión de fijación única de estado, compuesta por las siguientes acciones:

1. Iniciar sesión de corrección: El adaptador de GNSS inicia una sesión de corrección de inicio (como resultado de una solicitud de una aplicación LBS). El adaptador GNSS establece los requisitos y preferencias específicos que se asocian con la solicitud, e intima al controlador GNSS para iniciar el motor para obtener la corrección mediante la emisión del código de control IOCTL_GNSS_START_FIXSESSION.

2. Obtener la posición del dispositivo (corregir datos): Una vez iniciada una sesión de corrección, el adaptador de GNSS emite código de control IOCTL_GNSS_GET_FIXDATA empezar a esperar una corrección del controlador. Cuando hay disponible una nueva información de posición en el motor, el controlador GNSS responde a esta solicitud de corrección de obtención pendiente.

   Si el tipo de sesión de corrección es la corrección LKG (en lugar de la corrección actual), la información de posición procede de la memoria caché del controlador.

   El adaptador de GNSS garantiza que una solicitud de E/S asincrónica esté siempre disponible para que el controlador GNSS devuelva los datos de corrección cuando estén disponibles. Según la naturaleza de la corrección, si se esperan más datos de corrección, el adaptador de GNSS emite otra solicitud de E/S (con el mismo IOCTL) y esta secuencia continúa hasta que no haya más datos disponibles o se detenga la sesión de corrección.

3. Modificar sesión de corrección: Si el controlador GNSS no admite multiplexación de sesiones de corrección del mismo tipo, el adaptador GNSS puede emitir un IOCTL_GNSS_MODIFY_FIXSESSION para ese tipo de sesión de corrección cuando realiza multiplexación en su nivel.

4. Detener la sesión de corrección: El adaptador de GNSS emite una finalización de la sesión de corrección cuando no se necesita ni se espera ninguna información de posición adicional relativa a una sesión de corrección específica.

Compatibilidad con geovallas nativas

El DDI de GNSS admite escenarios de descarga de geocercas utilizando un conjunto de IOCTLs definidos en esta especificación. Se define una marca de funcionalidad especial para que el controlador indique esta compatibilidad; esta marca solo debe establecerse si la pila de GNSS admite geovalla de forma nativa (es decir, implementa geovalla en el chip GNSS en lugar de en el procesador de aplicaciones). Si el controlador no admite geovallas de forma nativa, no se establecerá el indicador. El HLOS ya admite un motor de seguimiento de geovalla basado en un procesador de aplicaciones (AP) subóptimo; aunque esta solución no está tan optimizada en consumo energético como una solución nativa podría estarlo, está bien probada y optimizada, por lo tanto, no debe reemplazarse por una solución equivalente implementada en el AP.

El seguimiento de geocerca por parte del HLOS requiere que el procesador de aplicaciones se despierte periódicamente para detectar infracciones de la geocerca, lo que consume energía incluso cuando no se infringen las cercas. Por lo tanto, esta implementación se considera poco óptima.

El HLOS también utiliza el seguimiento de geocerca basado en AP como un mecanismo de respaldo cuando el controlador subyacente no puede realizar un seguimiento de las geocercas debido a condiciones de señal bajas u otros errores transitorios, al recibir notificaciones de error de la solución nativa de seguimiento de geocerca. La compatibilidad con geovalla nativa solo es beneficiosa cuando el seguimiento de las geovallas se delega completamente al SoC y el procesador de aplicaciones se activa solo para procesar eventos relacionados con las geovallas. Si el hardware no admite el seguimiento de geocerca nativa, el controlador GNSS no debe intentar implementarlo en la capa de controlador.

El motor GNSS también debe exponer parámetros de ajuste específicos de IHV documentados para permitir encontrar el equilibrio adecuado entre el consumo de energía y la experiencia del usuario. Además, el número de geofences admitidos debe ser mayor que el valor de MIN_GEOFENCES_REQUIRED que se define en el archivo de encabezado. Tenga en cuenta que el MIN_GEOFENCES_REQUIRED se define por aplicación, ya que una aplicación no tiene conocimiento del número de geovallas usadas por otras aplicaciones o por el operador de telefonía móvil.

La compatibilidad con la descarga de geovalla implica los siguientes requisitos:

• El HLOS podrá crear una o varias geovallas a través del DDI, y el controlador las enviará al hardware para empezar a realizar el seguimiento.

• El HLOS podrá eliminar una o varias geovallas creadas previamente a través de la DDI y el controlador las enviará al hardware para dejar de rastrearlas.

• Lo ideal es que el hardware de GNSS comprenda el estado inicial de seguimiento de geovalla para cada geovalla y lo use para informar solo los cambios desde este estado inicial. Si el hardware de GNSS no admite esta funcionalidad, notificará el estado inicial al HLOS cada vez que se cree una geovalla.

• El hardware GNSS realiza un seguimiento de la posición actual del dispositivo de forma eficaz y activa el AP siempre que el dispositivo haya entrado o salga de una geovalla rastreada. El controlador GNSS pasa las alertas de geocerca al HLOS.

• Bajo una señal de satélite débil y otras condiciones de error transitorias, es posible que el motor GNSS no pueda seguir de manera confiable las geovallas actuales. El motor GNSS podrá detectar las interrupciones de seguimiento y el controlador GNSS pasará la alerta de error de estado de seguimiento al HLOS. HLOS cambia al seguimiento de geovallas basado en el punto de acceso (AP) predeterminado hasta que el hardware de GNSS pueda recuperar y seguir las geovallas nuevamente.

• Las condiciones exactas en las que un motor GNSS necesita proporcionar una notificación para indicar que las geovallas no pueden seguirse variarán, y la implementación será específica de la IHV. A continuación se muestran algunas directrices para la implementación:

  • Si el motor GNSS es capaz de detectar con alta confianza que el usuario no se mueve y no hay ningún límite de geovalla a 25 metros o menos, el motor GNSS no necesita enviar un error de seguimiento.

  • Si el motor de GNSS puede detectar con gran confianza que el usuario no se mueve, pero hay una geocerca a 25 metros o menos, el motor de GNSS debe enviar un error de rastreo en un minuto.

  • Si el motor GNSS ha detectado que el usuario se está moviendo y hay límites de geocercas a 100 metros o menos, el motor GNSS debe notificar un error de seguimiento en un minuto o menos.

  • Si el motor GNSS no puede determinar si el usuario se mueve y hay un límite de geovallas dentro de 100 metros o menos, el motor GNSS debe enviar un error de seguimiento en menos de un minuto.

  • Si el motor GNSS ha detectado que el usuario se está moviendo, el motor GNSS debe reportar un error de seguimiento en un tiempo proporcional a la velocidad estimada de movimiento y la distancia a la geovalla más cercana. Una recomendación es notificar un error dentro de [(Distancia al límite más cercano(m) / la velocidad estimada (m/s)) - 15s]. El motor GNSS puede usar indicadores de detección de movimiento para determinar el tiempo en el que se debe enviar el error de seguimiento.

  • Si el motor del GNSS no puede determinar si el usuario se está moviendo, el motor del GNSS debe enviar un error de seguimiento en un tiempo que sea proporcional a la alta velocidad del movimiento y la distancia a la geovalla más cercana. Se recomienda enviar un error dentro de [Distancia-al-límite-de-la-cerca-más-cercana(m) / 343(m/s)].

• Durante el período en el que el motor GNSS ha notificado un error en el estado del seguimiento de geocercas, no deben enviarse eventos de violación de geocercas al HLOS.

• El HLOS puede restablecer el seguimiento de geocercas eliminando todas las geocercas creadas anteriormente mediante un único comando.

• Las geovallas originadas por dispositivos móviles no se conservan en el hardware o en el controlador de GNSS durante los reinicios del sistema o los reinicios del controlador. HLOS controla la persistencia en nombre de las aplicaciones del usuario final y crea o elimina geocercas según sea necesario.

En términos de las interacciones entre el adaptador GNSS y el motor GNSS, que tiene compatibilidad nativa con la descarga de geocercas, en caso de un error en el seguimiento de geocercas, el adaptador GNSS hará lo siguiente:

• Usará el seguimiento basado en AP una vez que el controlador GNSS devuelva un error al realizar el seguimiento.

• Seguirá aplicando las actualizaciones (agregar/eliminar) en las geozonas que están siendo rastreadas actualmente a nivel del sistema operativo al controlador para que estén sincronizadas. Esto ayudará al motor de GNSS a saber qué geozonas están siendo rastreadas actualmente por el sistema operativo y a tomar una decisión de seguimiento o no seguimiento basada en los datos nuevos.

• Enviará los cambios de estado del geovalla según lo determinado por el rastreador basado en AP una vez que el controlador GNSS devuelva ÉXITO en su capacidad de realizar el seguimiento.

Notificaciones del controlador para obtener ayuda y datos auxiliares

De vez en cuando, el controlador GNSS puede necesitar datos de asistencia o acciones auxiliares del adaptador de GNSS. Esto incluye las distintas formas de datos de AGNSS (inyección de tiempo, efemérides, posición general inicial), ventana emergente de consentimiento del usuario para permitir el posicionamiento del plano de usuario iniciado por la red, etc.

• El controlador GNSS podría obtener datos de asistencia de GNSS sin usar el adaptador GNSS. No obstante, se recomienda obtener los datos de asistencia mediante el adaptador GNSS y aprovechar el servicio de posicionamiento de Microsoft por varias razones:

  • La pila de ubicaciones de Microsoft se encargará de establecer las conexiones de datos y cumplir con las restricciones de itinerancia, las preferencias de datos, la integración del modo silencioso de red, etc.

  • El servicio de posicionamiento de Microsoft puede obtener periódicamente datos de asistencia específicos de un IHV a través de una conexión de servidor a servidor back-end y proporcionárselos a todos los dispositivos que lo necesiten, ahorrando al IHV la necesidad de implementar un servicio de asistencia front-end en todo el mundo que cumpla con los requisitos de disponibilidad, escalabilidad y capacidad de respuesta.

• Los consentimientos del usuario para la privacidad de las aplicaciones de bandeja de entrada son propiedad del sistema operativo. Por lo tanto, cualquier interfaz de usuario para notificar al usuario sobre una solicitud de ubicación iniciada por la red o cualquier interfaz de usuario para solicitar consentimiento del usuario para responder a una solicitud de ubicación iniciada por la red, será propiedad de Microsoft. El controlador GNSS notificará al adaptador GNSS cuando se reciba una solicitud de ubicación iniciada por la red y, si es necesario, esperará la respuesta del usuario hasta la hora predeterminada antes de continuar con la solicitud.

Dado que el controlador GNSS no puede iniciar una solicitud a la capa superior por sí mismo, el adaptador GNSS puede realizar este tipo de operaciones de forma proactiva buscando dicha solicitud desde el controlador GNSS y, por tanto, mantener siempre uno o varios IRP pendientes para que el controlador GNSS pueda responder de nuevo en dichas solicitudes pendientes. Al recibir la solicitud de fecha de asistencia o asistente, el adaptador de GNSS recupera los datos (o ejecuta la acción específica en nombre del controlador GNSS) y luego inyecta la información necesaria en el controlador GNSS a través de otra llamada DeviceIoControl.

La notificación del controlador se gestiona a través de un modelo de eventos común. Por ejemplo, para la asistencia de GNSS, el adaptador GNSS usa código de control IOCTL_GNSS_LISTEN_AGNSS para recibir la solicitud de AGNSS del controlador GNSS. Posteriormente, el adaptador GNSS captura los datos de asistencia de AGNSS y emite IOCTL_GNSS_INJECT_AGNSS para insertar los datos en el controlador GNSS.

Este mecanismo de notificación también se usa para recibir actualizaciones de estado y datos de alerta relacionados con la geovalla. El adaptador usa el código de control IOCTL_GNSS_LISTEN_GEOFENCE_ALERT para recibir alertas de geovalla individuales y IOCTL_GNSS_LISTEN_GEOFENCES_TRACKINGSTATUS para recibir cambios en el estado general del seguimiento de geovallas.

Registro de controladores del sistema satélite de navegación global (GNSS)

Para fines de diagnóstico, el controlador GNSS debe registrar errores y otra información de diagnóstico mediante el mecanismo de registro prescrito (WPP) de Microsoft descrito a continuación o ETW. Se recomienda que los conductores usen WPP para fines de registro en lugar de ETW, aunque ambos mecanismos son compatibles. Se recomienda WPP debido a la disponibilidad de herramientas que pueden ayudar en la depuración de controladores.

El controlador no debe registrar ninguna información, legible o de otro modo, excepto mediante esta técnica de registro prescrita. Para obtener más información, vea Seguimiento de software de WPP.

El registro de mensajes con seguimiento de software de WPP es similar al uso de los servicios de registro de eventos de Windows. El controlador registra un identificador de mensaje y datos binarios sin formato en un archivo de registro. Posteriormente, un postprocesador convierte la información del archivo de registro en un formulario legible. Sin embargo, el seguimiento de software de WPP admite formatos de mensaje más capaces y flexibles que los que admiten los servicios de registro de eventos. Por ejemplo, el seguimiento de software de WPP tiene compatibilidad integrada con direcciones IP, GUID, identificadores de sistema, marcas de tiempo y otros tipos de datos útiles. Además, los usuarios pueden agregar tipos de datos personalizados relevantes para su aplicación.

Compatibilidad con el protocolo de operador móvil

La pila de GNSS proporcionada por IHV (el controlador GNSS, el dispositivo o motor GNSS) es necesario para admitir los distintos protocolos de posicionamiento de operadores móviles (SUPL, UPL, CP, etc.). Si no lo hace, significa que el dispositivo no pasará la aceptación de los operadores móviles y limitará significativamente dónde se puede comercializar el dispositivo.

La compatibilidad con estos protocolos y el cumplimiento de los requisitos del operador de telefonía móvil es obligatorio para enviar dispositivos para determinados operadores móviles. Es posible que la compatibilidad con protocolos de operadores móviles no sea esencial para la mayoría de las plataformas que no son de teléfono, especialmente si la plataforma no incluye compatibilidad con banda ancha móvil (MBB).

Todas las partes de implementación se abstraen en la pila de IHV y los componentes de Microsoft HLOS son independientes de:

• Detalles de implementación específicos de los protocolos (por ejemplo, cómo funcionan los protocolos, la interpretación de los mensajes de protocolo, etc.).

• La forma de la pila de implementación (por ejemplo, la implementación puede residir en el dispositivo o motor de GNSS, o en el controlador GNSS, o si es necesario, un servicio HLOS independiente).

• Interacción entre las distintas partes dentro de la pila de GNSS propiedad de IHV para implementar los protocolos. Por ejemplo, si el controlador GNSS requiere los resultados del examen Wi-Fi para responder a un mensaje de protocolo SUPL específico, puede hacerlo teniendo una extensión en modo de usuario que inyecte los resultados del examen Wi-Fi al controlador a través de una llamada IOCTL privada. También podría integrar esta funcionalidad en el controlador UMDF 2.0, o gestionar esta interacción en un nivel más bajo. Los componentes de HLOS de GNSS de Microsoft son ajenos a estas interacciones entre los componentes de la pila de GNSS de IHV.

En resumen, el IHV o OEM debe proporcionar un cliente SUPL (y potencialmente un cliente UPL si el sistema se va a enviar en China) e integrarlo con o dentro del controlador GNSS. Todas las interacciones de la plataforma de ubicación con el cliente SUPL se realizarán a través de la DDI de GNSS.

Para facilitar la implementación de los protocolos de operador de telefonía móvil y reducir la carga del desarrollo de software mediante tecnologías específicas de la plataforma, el adaptador GNSS proporciona cierta funcionalidad a la pila de GNSS de IHV. El controlador GNSS se trata como intermediario para recibir dicha funcionalidad de los componentes HLOS, por ejemplo, el adaptador GNSS interactúa solo con el controlador GNSS y no con ninguna otra parte de la pila de GNSS de IHV. Los ICTLs del controlador GNSS definen la sintaxis y la semántica de dicha funcionalidad entre el controlador GNSS y el adaptador GNSS. El controlador GNSS es responsable del enrutamiento al componente IHV específico que implementa el protocolo de operador de telefonía móvil. En términos generales, el adaptador GNSS proporciona la siguiente funcionalidad al controlador GNSS:

1. Configuración: Los operadores móviles aprovisionan el dispositivo y cambian la configuración mediante el mecanismo de configuración impuesto por los estándares del protocolo OMA. Por ejemplo, el estándar SUPL requiere que la configuración de SUPL se realice en función del UICC o que se realice mediante la información del perfil de configuración de SUPL OMA obtenida a través de OMA-DM o OMA-CP.

   Cierta funcionalidad disponible en el teléfono con fines de configuración (OMA-DM y OMA CP) no estaba disponible en otras plataformas hasta Windows 10. A partir de Windows 10, todas las plataformas pueden admitir la configuración de SUPL a través del proveedor de servicios de configuración de SUPL (CSP), en la medida en que se use la nueva DDI de GNSS. El aprovisionamiento insertado a través del CSP puede provenir de la propia imagen (a través de provxml o multivariante) o del operador móvil a través de OMA-DM o OMA-CP. CSP de SUPL se define en SUPL CSP.

   Windows 10 define una tecnología propietaria, la administración de dispositivos mediante un proveedor de servicios de configuración (CSP) para interpretar y extraer los datos de configuración. Microsoft proporciona un CSP para consumir la configuración de OMA e insertar la configuración en el controlador GNSS a través del adaptador de GNSS.

   Como alternativa, el IHV también puede escribir componente en modo de usuario para consumir la especificación de configuración del operador de telefonía móvil mediante la tecnología de administración de dispositivos (CSP) específica del teléfono. Sin embargo, esto será una carga adicional para IHV y no se recomienda.

   Solo se admite una configuración de SUPL en un sistema, incluidos en los casos de dispositivos SIM duales. Microsoft proporciona la funcionalidad para volver a configurar SUPL dependiendo del UICC y su cambio. Además de esto, en el caso de la itinerancia del dispositivo, HLOS vuelve a configurar el cliente SUPL para que funcione en modo independiente. En este documento se definen los ICTL para insertar estos datos de configuración para una variedad de protocolos de operación móvil (SUPL 1.0 y 2.0, v2UPL, etc.).

2. Control del consentimiento del usuario para las solicitudes de NI: Para cumplir los requisitos de privacidad, determinadas solicitudes de posicionamiento iniciadas por la red necesitan el consentimiento del usuario. Los IHD no pueden escribir la interfaz de usuario para los componentes de la plataforma. Por lo tanto, el adaptador GNSS controla la interfaz de usuario para el consentimiento del usuario en nombre del controlador GNSS. Las IOCTLs de notificación para el controlador GNSS, que sirven para solicitar un elemento emergente de la interfaz de usuario, y las IOCTLs para que el adaptador GNSS transmita la respuesta del usuario a dicha solicitud se definen en GNSS driver IOCTLs.

Para implementar un cliente SUPL totalmente funcional, la pila de IHV deberá hacer uso de interfaces o funcionalidad general disponible en o a través de la plataforma del sistema operativo. A continuación se muestra la lista de funcionalidades disponibles en Windows 10 que los IMV pueden aprovechar para implementar su cliente SUPL:

Ninguna de las funciones de esta funcionalidad forma parte de la plataforma de ubicación o del DDI de GNSS, pero se incluye aquí para aclarar y ayudar a los desarrolladores de controladores de GNSS a comprender lo que se puede aprovechar del sistema operativo para implementar la funcionalidad de SUPL.

• Enrutador SMS: El Enrutador SMS permite al cliente SUPL suscribirse al empuje WAP de mensajes SIP Push que contienen solicitudes de SUPL NI.

• Capacidad del Administrador de conexiones para configurar qué conexión se usará para SUPL y LAS API para solicitar dicha conexión: Es posible que los operadores móviles necesiten tener el tráfico SUPL en una conexión dedicada o simplemente en una conexión diferente de la conexión a Internet predeterminada. Para ello, Connection Manager ofrece:

  • Proveedor de servicios de configuración que el OEM o el operador de telefonía móvil pueden usar para configurar qué conexión se usará para el propósito de las comunicaciones SUPL.

  • Una API para que el cliente SUPL consulte los parámetros de conexión de la conexión SUPL.

  • Una API para establecer la conexión SUPL, con los parámetros obtenidos en el paso anterior.

• Configuración de la conexión móvil: Para configurar los parámetros de diferentes conexiones móviles, por ejemplo, los parámetros de una conexión SUPL, hay un proveedor de servicios de configuración que el OEM o el operador de telefonía móvil pueden usar. A continuación, esta conexión se puede asociar en el Administrador de conexiones al propósito de SUPL.

• Solicitud para mantener activas las conexiones mientras una conexión SUPL está en curso: Es posible que el cliente SUPL tenga que iniciar conexiones con HSLP mientras el sistema está en espera conectado. Esto puede ocurrir porque el dispositivo GNSS necesita obtener información de asistencia cuando está configurado para usar el posicionamiento basado en Microsoft o porque el operador de telefonía móvil envió una solicitud de NI. Si es así, el cliente SUPL deberá iniciar una conexión con HSLP y asegurarse de que la conexión esté activa hasta que se complete la sesión de SUPL.

• Interacciones con el módulo banda ancha móvil (MBB): En Windows 10, no hay API disponibles a través de HLOS para recuperar medidas de telefonía móvil, saber cuándo se ha realizado una llamada de emergencia, etc. Cualquier interacción con el MBB debe realizarse a través de la integración directa con el MBB (a través de comandos AT u otro método propietario).

Pruebas de fabricación

Los OEM deben tener una manera de validar en tiempo de fabricación y también en los puntos de atención al cliente que la pila GNSS y el hardware GNSS (el controlador GNSS y el motor de GNSS) funcionan correctamente. El IHV puede proporcionar mecanismos propietarios para permitir que los OEM realicen esta prueba o, opcionalmente, pueden implementar la interfaz en DDI para permitir que el OEM inicie pruebas de fabricación y obtenga resultados.

El marco de ubicación se omitirá al realizar las pruebas de fabricación, dado que un gran enfoque de las pruebas se centra en la validación de hardware o en la validación de controladores. En general, el dispositivo estará en un "modo de sistema operativo seguro" especial donde se cargará el conjunto mínimo de componentes y servicios. En este modo, el OEM puede iniciar un conjunto de aplicaciones de prueba que desencadenarán casos de prueba. Para lograr eficiencia y velocidad durante la fabricación, es muy recomendable tener compatibilidad con simultaneidad para pruebas dentro de diferentes componentes.

La interfaz para pruebas de fabricación incluye dos tipos de pruebas:

1. Prueba de onda portadora: Esta prueba consiste en validar la prueba externa de conectividad o antena. En esta prueba, el motor GNSS debe buscar una señal CW y proporcionar las relaciones señal a ruido (SNR) o relación de portadora a ruido en la respuesta. Lo ideal es que las pruebas proporcionen respuestas a 10 Hz.

2. Prueba automática: Esta prueba consiste en validar la funcionalidad básica del motor GNSS. La prueba automática debe ser capaz de detectar problemas básicos en el motor (hardware defectuoso, conexiones incorrectas en el hardware GNSS sin necesidad de insertar ninguna señal externa. El objetivo de esta validación es realizar esta prueba barata y usarla como puerta en la línea de producción, antes de que el dispositivo pase por pruebas más exhaustivas y costosas. En esta prueba, el motor y el controlador GNSS realizarán la validación automática para las conexiones de anclaje y devolverán un código de estado que indique que todo es correcto o que se produjo un error. El código de error de los errores debe indicar el error detectado. El IHV establece los códigos de error.

Consideraciones de E/S

Dado que la funcionalidad de GNSS no se asigna a las solicitudes tradicionales de lectura y escritura de archivos a controladores de dispositivo, las funciones ReadFile y WriteFile no se usarán para las API del controlador GNSS. Toda la funcionalidad de GNSS se implementará mediante solicitudes de control de E/S de dispositivo (DeviceIoControl) específicas de GNSS bien definidas, también conocidas como IOCTLs.

Todas las ICTL usarán METHOD_BUFFERED como mecanismo de transferencia de datos para los datos de entrada y salida. Dado que el tamaño de los datos relacionados con GNSS es relativamente pequeño, la copia adicional del búfer no debería afectar al rendimiento del sistema.

El controlador GNSS se abrirá mediante la opción FILE_FLAG_OVERLAPPED en la función CreateFile . Por lo tanto, todos los IOCTLs son implícitamente asincrónicos. Sin embargo, aunque la mayoría de los ICTL de GNSS son semánticamente asincrónicos (por ejemplo, un IOCTL desencadena una actividad dentro del controlador y los resultados se esperan de nuevo de forma asincrónica), algunos ICTL son semánticamente sincrónicos en el sentido de que no hay ninguna acción o actividad asincrónica lógica implicada con tales ICTL. El comportamiento sincrónico de estos pocos ICTLs se logrará bloqueando el subproceso del adaptador GNSS después de emitir la llamada DeviceIoControl hasta que se complete la operación de E/S. Por lo tanto, es responsabilidad del controlador GNSS completar siempre el IRP como parte del procesamiento de todos los IOCTL. Se espera que el adaptador GNSS respete el contrato de una llamada sincrónica y, en caso de errores, puede reintentar estos comandos o no. El controlador IHV debe asegurarse de que ha incorporado todas las lógicas del lado del controlador antes de devolver un error.

Para las operaciones de solicitud y respuesta, el adaptador de GNSS siempre mantendrá disponible una operación de E/S pendiente para que cuando el controlador GNSS tenga datos para enviar como respuesta a una operación invocada previamente, la respuesta se puede enviar a través del IRP pendiente.

Sesión de captura única

Una solicitud de corrección de inicio puntual para el controlador incluye valores de precisión y tiempo de respuesta. El motor GNSS puede usar estos valores para comprender la intención de la solicitud de aplicación y tomar decisiones inteligentes. Una vez que el controlador recibe una solicitud, debería empezar a devolver las correcciones intermedias generadas por el motor. Las correcciones intermedias son correcciones generadas por el motor mientras calcula una corrección que cumple los requisitos de precisión o es final. La frecuencia de estas correcciones intermedias no se aplica de manera estricta y es un detalle de la implementación del motor. El adaptador de GNSS espera que las correcciones lleguen cada pocos segundos y deben ser diferentes de la última corrección intermedia.

Una vez que el motor GNSS determina que no puede obtener una mejor corrección en las condiciones de señal actuales, debe devolver una corrección final y debe dejar de realizar cálculos adicionales. La corrección final cumple el requisito de precisión o indica que el motor no puede mejorar la precisión proporcionada en las condiciones actuales.

El adaptador de GNSS emite una corrección de detención para una sola sesión de captura en cualquiera de los dos casos:

• Obtiene una corrección final del controlador.

• El tiempo de respuesta de la solicitud ha expirado. Aquí se enviará la última corrección intermedia a la aplicación.

En la ilustración siguiente se muestran dos sesiones de captura única:

Sesión 1: El controlador recibió parámetros de precisión y tiempo de respuesta. Después del comando start fix, el controlador comenzó a enviar correcciones intermedias. Después de un tiempo, determinó que no pudo devolver una corrección más precisa, por lo que indicó la última corrección como final. Esto ocurrió antes de alcanzar el límite de tiempo de respuesta. El adaptador envió la corrección final a la aplicación y emitió un comando stop fix.

Sesión 2: Igual que en la sesión 1 anterior, pero en este caso el motor siguió funcionando para lograr una mejor corrección que cumpliera con el requisito de precisión y siguió enviando correcciones intermedias. Una vez alcanzado el límite de tiempo de respuesta de la sesión, el adaptador emitió un comando de detención que debería cerrar esta sesión en el controlador. La última corrección intermedia recibida se envió a la aplicación.

Un aspecto de diseño importante que se debe tener en cuenta al implementar la compatibilidad con captura única es que, si no se admiten sesiones de seguimiento basadas en distancia y sesiones de seguimiento basadas en el tiempo, el motor de GNSS seguirá realizando el seguimiento de satélites durante 3 a 5 segundos después de recibir un comando stop fix. Esto se debe a que el adaptador de GNSS tendrá que implementar sesiones de seguimiento basadas en distancia simuladas o sesiones de seguimiento basadas en tiempo mediante sesiones de corrección de captura única y, si el motor GNSS deja de realizar un seguimiento de satélites inmediatamente, la mayoría de los dispositivos GNSS tendrán un retraso en la adquisición, lo que hace imposible implementar una sesión de seguimiento simulada que satisfaga las necesidades de navegación, ejecutar aplicaciones de seguimiento o asignación.

El adaptador GNSS puede iniciar solicitudes de correcciones de captura única mientras el sistema está en espera conectada, no solo cuando el sistema está activo. Esto puede ocurrir para satisfacer la necesidad de tareas en segundo plano, servicios del sistema, seguimiento de geovallas en el procesador de aplicaciones o en otros casos. El controlador GNSS podrá pasar estas solicitudes de sesión al dispositivo GNSS y satisfacer la solicitud o proporcionar un error al adaptador GNSS.

En el diagrama de secuencia siguiente se muestran las acciones de alto nivel relacionadas con la obtención de una corrección de GNSS independiente. Esto no incluye ninguna solicitud de datos de asistencia.

La descripción de la secuencia es la siguiente:

1. El adaptador GNSS abre el controlador GNSS mediante createFile API. WDF/KMDF/UMDF efectúa las necesarias devoluciones de llamada opcionales al controlador GNSS. El identificador de archivo devuelto se usa para todas las operaciones posteriores.

2. El adaptador de GNSS emite un IOCTL para comunicar las distintas funcionalidades de la plataforma al controlador. El controlador GNSS completa la operación de E/S.

3. El adaptador de GNSS emite el IOCTL para obtener las funcionalidades del dispositivo. El controlador GNSS devuelve las funcionalidades del dispositivo y completa la operación de E/S.

4. El adaptador de GNSS emite IOCTLs para cualquier configuración o comandos específicos del controlador. El controlador GNSS realiza la acción necesaria y completa la operación de E/S.

5. El adaptador de GNSS emite un IOCTL_GNSS_START_FIXSESSION, junto con los parámetros que especifican el tipo y otros aspectos de la corrección. Al recibir este IOCTL, el controlador GNSS interactúa con el dispositivo subyacente para empezar a recibir correcciones y, posteriormente, completa la operación de E/S.

6. El adaptador de GNSS emite una IOCTL_GNSS_GET_FIXDATA y espera la finalización de E/S. Cada vez que el controlador GNSS tiene una corrección intermedia disponible, devuelve los datos completando la operación de E/S.

7. El paso 6 se repite hasta que el controlador GNSS indica que no se esperan más correcciones (corrección final recibida).

8. El adaptador GNSS emite IOCTL_GNSS_STOP_FIXSESSION. El controlador GNSS realiza la operación de limpieza necesaria asociada a la solicitud de corrección original.

9. El adaptador GNSS cierra el identificador de archivo del controlador mediante la API CloseHandle.

Las IOCTLs GNSS y las estructuras de datos asociadas se describen en detalle en la referencia del controlador GNSS.

Sesión de seguimiento basada en distancia

Las aplicaciones de usuario final usan con frecuencia las sesiones de seguimiento basadas en distancia, como históricamente, era el único tipo de sesión disponible en las API de .NET. Un valor de distancia de 0 indica que el motor GNSS proporcionará correcciones a la velocidad más alta posible.

El adaptador de GNSS iniciará sesiones de seguimiento de distancia con el controlador GNSS, solo si este último indica que tiene la funcionalidad SupportDistanceTracking.

Una solicitud de corrección de inicio al controlador para una sesión de seguimiento de distancia incluirá la precisión horizontal deseada y el umbral de movimiento, que es la distancia haversine en metros que el sistema cubrirá antes de que el controlador GNSS proporcione una actualización de posición. El motor GNSS puede usar estos valores para comprender la intención de la solicitud de aplicación y tomar decisiones inteligentes, como adaptar la frecuencia a la que se va a comprobar la ubicación.

Una vez que el controlador recibe una solicitud de corrección de inicio, debe empezar a devolver las correcciones intermedias generadas por el motor, hasta que obtenga una corrección final. Se considerará la primera posición de la sesión. Después de ello, el motor GNSS comenzará a proporcionar correcciones siempre que detecte que la distancia de la haversina se ha cubierto aproximadamente.

Si el motor GNSS determina que ya no puede realizar un seguimiento de la ubicación del dispositivo (por ejemplo, si los satélites ya no son visibles), debe devolver un error al adaptador de GNSS para que la plataforma de ubicación pueda revertir a otros mecanismos para proporcionar actualizaciones de posición a la aplicación del usuario final. El adaptador de GNSS proporcionará un error en el plazo siguiente:

[(Distancia restante desde la última posición conocida (m) / velocidad estimada (m/s)) – 5 segundos] o 5 segundos, lo que sea mayor.

Si el motor GNSS proporcionó un error al adaptador de GNSS, pero el adaptador de GNSS aún no ha detenido la sesión de seguimiento, el motor de GNSS debe seguir comprobando, de una manera optimizada para energía, si puede reanudar la ubicación de seguimiento. El IHV puede usar optimizaciones para realizar esta detección en baja potencia. Entre las técnicas comunes para la optimización se incluyen:

• Retroceso progresivo

• Esperando señales de bajo costo que indican los movimientos del dispositivo para volver a comprobar

• Comprobaciones de energía baja para la señal satélite

Una vez que el motor de GNSS puede proporcionar una corrección final de nuevo después de una condición de error, debe enviar esa posición al adaptador GNSS como indicación de que el seguimiento se reanudó correctamente.

El adaptador de GNSS emite un comando modify fix para una sesión de seguimiento basada en distancia si una o varias aplicaciones que solicitaron la sesión de seguimiento han cancelado la solicitud o si las nuevas aplicaciones solicitan una sesión de seguimiento basada en distancia. En tal caso, el adaptador GNSS calcula los nuevos parámetros de sesión agregados necesarios para multiplexar las distintas sesiones activas y actualiza el controlador GNSS con estos parámetros.

El adaptador de GNSS emite un comando stop fix para una sesión de seguimiento basada en distancia si:

• La sesión de seguimiento se entregó a otro motor de posicionamiento disponible en el sistema.

• Las aplicaciones que solicitaron la sesión de seguimiento han cancelado la solicitud.

En la ilustración siguiente se muestran dos sesiones de seguimiento basadas en distancia:

Sesión 1: El controlador GNSS recibió parámetros de precisión y umbral de movimiento al iniciar la sesión de seguimiento. Después del comando start fix, el controlador comienza a enviar correcciones intermedias hasta que obtiene una corrección final o una corrección que cumple el requisito de precisión en el que se proporciona dicha corrección al adaptador GNSS y el motor GNSS iniciará el proceso de seguimiento de distancia. Mientras la sesión está activa, el adaptador de GNSS envía una solicitud para modificar los parámetros de sesión a veces T1 y T2. Después de cada modificación de parámetros, el controlador GNSS enviará una actualización de corrección al adaptador GNSS y reanudará la sesión de seguimiento de distancia con los nuevos parámetros, hasta que el adaptador de GNSS envíe un comando stop fix.

Sesión 2: El proceso de inicio de sesión es similar a la sesión 1 anterior, pero en un momento dado el motor de GNSS no puede realizar el seguimiento de la posición. Después de un tiempo que depende de la distancia y la velocidad estimada del movimiento, el controlador GNSS envía un error. El motor GNSS continúa comprobando a menor potencia cuando puede recuperarse y, cuando se recupera, indica esto al adaptador GNSS enviando una nueva corrección. La sesión se actualiza con nuevas correcciones según sea necesario hasta que el adaptador de GNSS envíe un comando stop fix.

El adaptador GNSS puede mantenerse activo o incluso iniciar sesiones de seguimiento basadas en distancia mientras el sistema está en espera conectado, no solo cuando el sistema está activo. Esto puede ocurrir para satisfacer la necesidad de tareas en segundo plano, servicios del sistema, seguimiento de geovallas en el procesador de aplicaciones u otros casos. El controlador GNSS podrá pasar estas solicitudes de sesión al dispositivo GNSS y satisfacer la solicitud o proporcionar un error al adaptador GNSS.

Sesión de seguimiento basada en el tiempo

Las aplicaciones que requieren una actualización de posición frecuente y regular pueden usar las sesiones de seguimiento basadas en el tiempo para actualizar la interfaz de usuario (por ejemplo, mapas, aplicaciones de navegación, etc.).

El adaptador de GNSS iniciará sesiones de seguimiento basadas en el tiempo con el controlador GNSS, solo si este último indica que tiene la funcionalidad SupportContinuousTracking.

Una solicitud de corrección de inicio al controlador para una sesión de seguimiento basada en el tiempo incluirá la precisión horizontal deseada y el intervalo de tiempo preferido en el que el controlador GNSS debe proporcionar una actualización de posición. El motor GNSS puede usar estos valores para comprender la intención de la solicitud de aplicación y tomar decisiones inteligentes, como adaptar la frecuencia a la que se va a comprobar la ubicación, empezar a adquirir satélites unos segundos antes del intervalo para proporcionar una actualización de posición oportuna, etc.

Una vez que el controlador recibe una solicitud de corrección de inicio, debe empezar a devolver las correcciones intermedias generadas por el motor, hasta que obtenga una corrección final. Se considerará la primera posición de la sesión. Después de esto, el motor GNSS comenzará a proporcionar correcciones en el intervalo requerido por los parámetros de sesión. Si el motor de GNSS no puede proporcionar posiciones con la frecuencia requerida por la aplicación, debe proporcionar correcciones a la velocidad máxima que pueda.

Si el motor de GNSS determina que ya no puede realizar un seguimiento de la ubicación del dispositivo (por ejemplo, si los satélites ya no están visibles), debe devolver un error al adaptador de GNSS para que la plataforma de ubicación pueda revertir a otros mecanismos para proporcionar actualizaciones de posición a la aplicación del usuario final.

Si el motor GNSS proporcionó un error al adaptador de GNSS, pero el adaptador de GNSS aún no ha detenido la sesión de seguimiento, el motor de GNSS debe seguir comprobando, de una manera optimizada para energía, si puede reanudar la ubicación de seguimiento.

El IHV puede usar optimizaciones para realizar esta detección en baja potencia, como se explica en la sección anterior. Una vez que el motor de GNSS puede proporcionar una corrección final de nuevo después de una condición de error, debe enviar esa posición al adaptador GNSS como indicación de que el seguimiento se reanudó correctamente.

El adaptador de GNSS emite un comando modify fix para una sesión de seguimiento basada en el tiempo si una o varias aplicaciones que solicitaron la sesión de seguimiento han cancelado la solicitud o si las nuevas aplicaciones solicitan una sesión de seguimiento basada en el tiempo. En tal caso, el adaptador GNSS calcula los nuevos parámetros de sesión agregados necesarios para multiplexar las distintas sesiones activas y actualiza el controlador GNSS con estos parámetros.

El adaptador de GNSS emite un comando stop fix para una sesión de seguimiento basada en el tiempo si:

• La sesión de seguimiento se entregó a otro motor de posicionamiento disponible en el sistema.

• Las aplicaciones que solicitaron la sesión de seguimiento han cancelado la solicitud.

En la ilustración siguiente se muestran dos sesiones de seguimiento basadas en tiempo.

Sesión 1: El controlador GNSS recibió precisión y un parámetro de intervalo preferido al iniciar la sesión de seguimiento. Después del comando start fix, el controlador comenzará a enviar correcciones intermedias hasta que obtenga una corrección final o una corrección que cumpla el requisito de precisión en el que se proporciona dicha corrección al adaptador GNSS y el motor GNSS iniciará el proceso de seguimiento basado en el tiempo. Mientras la sesión está activa, el adaptador de GNSS envía una solicitud para modificar los parámetros de sesión a veces T1 y T2. Después de cada modificación de parámetros, el controlador GNSS enviará una actualización de corrección al adaptador de GNSS y reanudará la sesión de seguimiento basada en el tiempo, con los nuevos parámetros, hasta que el adaptador de GNSS envíe un comando stop fix.

Sesión 2: El proceso de inicio de sesión es similar al de la sesión 1 anterior, pero en un momento dado el motor GNSS deja de ser capaz de realizar el seguimiento de la posición. Cuando el motor GNSS no puede proporcionar una corrección en un plazo de 15 segundos del intervalo requerido por los parámetros de sesión, el controlador GNSS envía un error. El motor GNSS continúa verificando a menor potencia cuando puede recuperarse, y cuando se recupera, lo indica al adaptador de GNSS enviando una nueva corrección. La sesión se actualiza con nuevas correcciones según sea necesario hasta que el adaptador de GNSS envíe un comando stop fix.

El adaptador GNSS puede mantenerse activo o incluso iniciar sesiones de seguimiento basadas en el tiempo mientras el sistema está en espera conectado, no solo cuando el sistema está activo. Esto puede ocurrir para satisfacer la necesidad de tareas en segundo plano, servicios del sistema, seguimiento de geocercas en el procesador de aplicaciones u otros casos. El controlador GNSS podrá pasar estas solicitudes de sesión al dispositivo GNSS y satisfacer la solicitud o proporcionar un error al adaptador GNSS.

** Gestión de diferentes tipos de sesiones FIX de forma simultánea

Algunos motores de GNSS avanzados pueden manejar simultáneamente una sesión de un solo disparo, junto con una sesión de seguimiento de Distance-Based y/o Time-Based. Idealmente, las sesiones independientes no deben influir entre sí, pero esto puede no ser siempre posible, especialmente en el caso de sesiones simultáneas de seguimiento basado en un solo disparo y en el tiempo. En esta sección se proporcionan algunas directrices para la implementación de IHV en caso de que se necesite llegar a compromisos para gestionar sesiones simultáneas de diferentes tipos.

En esta sección se usan los acrónimos siguientes:

• SS: Sesión de captura única

• DBT: Sesión de seguimiento basada en la distancia

• TBT: sesión de seguimiento basada en el tiempo

• TBF: Tiempo entre correcciones

En la tabla siguiente se proporcionan algunos escenarios para gestionar simultáneamente sesiones de seguimiento instantáneas y basadas en tiempo.

Si hay simultáneamente una sesión de seguimiento basada en el tiempo y una sesión de seguimiento basada en la distancia, el seguimiento de precisión del motor GNSS se puede establecer para que funcione con el más pequeño de los dos. En la tabla siguiente también se proporcionan algunas directrices para el caso de valores dispares para la precisión necesaria cuando hay sesiones simultáneas de captura única y seguimiento: