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

Artículo
03/22/2023

Proporciona información general sobre la arquitectura del controlador UMDF 2.0 del sistema satélite de navegación global (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 de navegación global (GNSS) con la plataforma Windows 10.

diagrama que muestra la arquitectura de gnss del modo de usuario.

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 de 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 IGnsAdapter 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 privada solo 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 terceros o de terceros.
Adaptador GNSS: Se trata de un objeto COM singleton que implementa la interfaz COM IGnssAdapter . Prueba las aplicaciones y los componentes internos del servicio de ubicación crean instancias de este objeto y usan el dispositivo GNSS a través de la interfaz IGnssAdapter . El componente del motor de posicionamiento de 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 probar y otras aplicaciones fuera de proceso para crear instancias de 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 proxy del puntero de interfaz a las aplicaciones fuera de proceso para que las aplicaciones traten el puntero de interfaz IGnssAdapter como un objeto COM en proceso, pero las llamadas se controlan realmente mediante el objeto de adaptador GNSS singleton dentro del servicio de ubicación.

El motor de posicionamiento de GNSS usa el objeto de adaptador GNSS interno para proporcionar funcionalidad específica de la ubicación al servicio de ubicació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 en las llamadas a DeviceIoControl adecuadas, mantiene el equipo 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 de 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 mediante la interacción con el hardware GNSS real. El controlador GNSS también funciona como mediador o integrador para las funciones DE 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 de controlador GNSS sea muy delgada (básicamente un adaptador para interactuar con el dispositivo GNSS).

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 continúen trabajando 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 Kit de laboratorio de hardware (HLK) emitido con Windows 10:

Un nuevo conjunto de pruebas para certificar controladores después del nuevo modelo.
Otro conjunto de pruebas para certificar los controladores que siguen el modelo anterior. Serán el mismo conjunto de pruebas que estaban disponibles en el WHCK en Windows 8.1.

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

diagrama que muestra la comunicación del adaptador y el controlador gnss 2.0.

En el caso raro de varios dispositivos GNSS detectados en un sistema, la plataforma de ubicación solo usará un dispositivo, principalmente para reducir el consumo de energía general 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 tanto, 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 que usa 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 inversa, el comportamiento será el mismo que en Windows 8.1, en el que ambos dispositivos GNSS se usan simultáneamente y una de las respuestas se comunica a 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 geovallas u otras operaciones descargadas, la descarga se realizará mientras se usa ese dispositivo. El adaptador de GNSS no dividirá la funcionalidad ni las sesiones entre varios dispositivos GNSS.

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

Intercambio de información de funcionalidad

Para admitir la extensibilidad y la incompatibilidad de la pila de GNSS en plataformas Windows, el adaptador de GNSS y el controlador GNSS establecen una comprensión 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 la funcionalidad están bien definidos por Microsoft como parte de esta definición de interfaz de GNSS y evolucionarán a medida que la innovación en el espacio GNSS continúa y un conjunto diverso de conjuntos de conjuntos de chips o controladores emergen en el mercado. El adaptador de 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.

El adaptador de GNSS puede realizar una configuración única o volver a configurar periódicamente el controlador GNSS. Del mismo modo, el adaptador de GNSS puede ejecutar determinados comandos específicos de GNSS a través del controlador. Esto se logra mediante la definición de 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 un reinicio del 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 configuración del comando del dispositivo se realiza 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 de 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 limitados a) los siguientes tipos de sesión 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 la distancia)

El único tipo de sesión de posición obligatoria requerido por cada hardware GNSS y 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 potencial de energía al mantener inactivo el procesador de aplicaciones (AP) durante más tiempo haciendo más tiempo el procesamiento en el SOC y solo notificando los cambios cuando sea necesario. La compatibilidad con el seguimiento basado en distancia nativa es más impactante que las sesiones de seguimiento basadas en tiempo nativas, ya que puede aportar un mayor ahorro de energía y porque las aplicaciones usan más ampliamente.

El acto de recuperar información de posición del controlador GNSS se produce a través de una sesión de corrección única con estado, que consta de las siguientes acciones:

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 indica al controlador GNSS iniciar el motor para obtener la corrección mediante la emisión del código de control IOCTL_GNSS_START_FIXSESSION.
Obtener la posición del dispositivo (corregir datos): Una vez iniciada una sesión de corrección, el adaptador de GNSS emite el 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 GNSS garantiza que una solicitud de E/S asincrónica siempre está disponible para que el controlador GNSS devuelva los datos de corrección cuando estén disponibles. Dependiendo de 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.
Modificar sesión de corrección: Si el controlador GNSS no admite la multiplexación de sesiones de corrección del mismo tipo, el adaptador de GNSS puede emitir un IOCTL_GNSS_MODIFY_FIXSESSION para ese tipo de sesión de corrección cuando realiza multiplexación en su nivel.
Detener la sesión de corrección: El adaptador de GNSS emite una sesión de detención de corrección cuando no se necesita o espera información de posición adicional relativa a una sesión de corrección específica.

Compatibilidad con geovallas nativas

La DDI de GNSS admite escenarios de descarga de geovalla mediante un conjunto de ICTLs 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 la geovalla de forma nativa, no se establecerá la marca. El HLOS ya admite un procesador de aplicaciones poco óptimo (AP) basado en el motor de seguimiento de geovalla; aunque esta solución no está tan optimizada como una solución nativa, está bien probada y optimizada, por lo que no debe reemplazarse por una solución equivalente implementada en el AP.

El seguimiento de geovalla por parte del HLOS requiere que el procesador de aplicaciones se despierte periódicamente para detectar infracciones de geovalla, con lo que se purga la potencia incluso cuando no se infringen las barreras. Por lo tanto, esta implementación se considera poco óptima.

El HLOS también usa el seguimiento de geovalla basado en AP como mecanismo de conmutación por error cuando el controlador subyacente no puede realizar el seguimiento de geovallas debido a condiciones de señal bajas u otros errores transitorios, tras las notificaciones de error recibidas de la solución nativa de seguimiento de geovalla. La compatibilidad con geovalla nativa solo es beneficiosa cuando el seguimiento de geovalla está totalmente desactivado en el SoC y el procesador de aplicaciones solo se activa para procesar eventos relacionados con la geovalla. Si el hardware no admite el seguimiento de geovalla nativa, el controlador GNSS no debe intentar implementarlo en la capa de controlador.

El motor GNSS también debe exponer parámetros de ajuste documentados específicos de IHV 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 geovallas implica los siguientes requisitos:

El HLOS podrá crear una o varias geovallas a través de la DDI y el controlador los envía 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 los envía al hardware para detener su seguimiento.
Lo ideal es que el hardware de GNSS comprenda el estado inicial de seguimiento de geovalla para cada geovalla y úsela para notificar solo los cambios de este estado inicial. Si el hardware de GNSS no admite esta funcionalidad, notificará el estado inicial a 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 geovalla al HLOS.
Bajo la señal satélite baja y otras condiciones de error transitorios, el motor GNSS puede no ser capaz de realizar un seguimiento confiable de las geovallas existentes. El motor GNSS podrá detectar las interrupciones de seguimiento y el controlador GNSS pasará la alerta de error de estado de seguimiento al HLOS. El HLOS cambia al seguimiento de geovalla basado en AP predeterminado hasta que el hardware de GNSS pueda recuperar y realizar un seguimiento de las geovallas de nuevo.
Las condiciones exactas en las que un motor de GNSS necesita proporcionar una notificación para indicar que las geovallas no se pueden realizar el seguimiento variarán y la implementación será específica de IHV. A continuación se muestran algunas directrices para la implementación:
- Si el motor de GNSS es capaz de detectar con alta confianza que el usuario no se mueve y no hay ningún límite de geovalla en 25 metros o menos, el motor de GNSS no necesita enviar un error de seguimiento.
- Si el motor de GNSS es capaz de detectar con alta confianza que el usuario no se mueve, pero hay un límite de geovalla en 25 metros o menos, el motor de GNSS debe enviar un error de seguimiento en un minuto.
- Si el motor de GNSS ha detectado que el usuario se está moviendo y hay un límite de geovallas dentro de 100 metros o menos, el motor de GNSS debe enviar un error de seguimiento en un minuto o menos.
- Si el motor de GNSS no puede determinar si el usuario se mueve y hay un límite de geovallas dentro de 100 metros o menos, el motor de GNSS debe enviar un error de seguimiento en un minuto o menos.
- Si el motor GNSS ha detectado que el usuario se está moviendo, el motor GNSS debe enviar 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 enviar un error dentro de [(Distancia a cerca-límite-límite(m) / 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 GNSS no puede determinar si el usuario se está moviendo, el motor GNSS debe enviar un error de seguimiento en un tiempo proporcional a la alta velocidad de movimiento y la distancia a la geovalla más cercana. Se recomienda enviar un error dentro de [Límites de cerca a más cercano(m) / 343(m/s)].
Durante el período en el que el motor de GNSS ha notificado un error de estado de seguimiento de geovalla, no debe haber ningún evento de infracción de geovalla enviado al HLOS.
El HLOS puede restablecer el seguimiento de geovalla eliminando todas las geovallas creadas anteriormente a través de un único comando.
Las geovallas originadas por dispositivos móviles no se conservan en el hardware o controlador de GNSS en los reinicios o reinicios del controlador. HLOS controla la persistencia en nombre de las aplicaciones del usuario final y crea o elimina geovallas según sea necesario.

En términos de interacciones entre el adaptador GNSS y el motor de GNSS que admite la descarga de geovalla de forma nativa, en el caso de un error de seguimiento de geovallas, el adaptador de GNSS hará lo siguiente:

Usará el seguimiento basado en AP una vez que el controlador GNSS devuelva un error al realizar el seguimiento.
Seguirá insertando las actualizaciones (agregar o eliminar) en las geovallas que se están realizando actualmente en el nivel del sistema operativo en el controlador, de modo que estén sincronizadas. Esto ayudará al motor de GNSS a saber qué geovallas están siendo rastreadas actualmente por el sistema operativo y puede realizar un seguimiento de can/no puede realizar un seguimiento de la determinación en función de los datos actualizados.
Insertará los cambios de estado de geovalla según lo determinado por el rastreador basado en AP una vez que el controlador GNSS devuelva SUCCESS en su capacidad de realizar el seguimiento.

Notificaciones de controladores 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 (inserción de tiempo, ephemeris, posición inicial general), pop-up de consentimiento del usuario para admitir 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. Sin embargo, 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 móviles, 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 la conexión de back-end del servidor y proporcionarlos a todos los dispositivos que necesiten, guardando el IHV la necesidad de implementar el servicio de asistencia de front-end en todo el mundo que cumpla 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 el 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 el momento predeterminado 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 de GNSS puede llevar a cabo 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 asistencia o fecha del asistente, el adaptador GNSS captura los datos (o ejecuta la acción específica en nombre del controlador GNSS) e inserta posteriormente la información necesaria en el controlador GNSS a través de otra llamada DeviceIoControl .

La notificación del controlador se controla a través de un modelo de eventos común. Por ejemplo, para la asistencia de GNSS, el adaptador de GNSS usa código de control IOCTL_GNSS_LISTEN_AGNSS para recibir la solicitud de AGNSS del controlador GNSS. Posteriormente, el adaptador de GNSS captura los datos de asistencia de AGNSS y problemas 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 geovalla.

Para fines de diagnóstico, el controlador GNSS debe registrar errores y otra información de diagnóstico mediante el mecanismo de registro prescrito de Microsoft (WPP) que se describe a continuación o ETW. Se recomienda que los controladores usen WPP con fines de registro en lugar de ETW, aunque se admiten ambos mecanismos. Entre las razones por las que se recomienda WPP se encuentra la disponibilidad de herramientas que pueden ayudar a la depuración de controladores.

El controlador no debe registrar ninguna información, legible por el usuario o de otro modo, aparte de a través de esta técnica de registro prescrito. 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 del 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 el motor de 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 los protocolos de operador de telefonía móvil 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 el Wi-Fi resultados del examen para responder a un mensaje de protocolo SUPL específico, puede hacerlo si tiene una extensión en modo de usuario que inserta los resultados del examen de Wi-Fi en el controlador a través de una llamada IOCTL privada o realiza esta parte del controlador UMDF 2.0 o controla esta interacción en un nivel inferior. Los componentes de HLOS de GNSS de Microsoft son ajenos a estas interacciones entre los componentes de pila de GNSS de IHV.

En resumen, el IHV o OEM debe proporcionar un cliente SUPL (y posiblemente 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 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 esta funcionalidad de los componentes de 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. Las ICTLs del controlador GNSS definen la sintaxis y la semántica de esta funcionalidad entre el controlador GNSS y el adaptador de GNSS. El controlador GNSS es responsable del enrutamiento al componente IHV específico que implementa el protocolo de operador móvil. En términos generales, el adaptador de GNSS proporciona la siguiente funcionalidad al controlador GNSS:

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 de 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), hasta 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. SUPL CSP 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 móvil mediante la tecnología de administración de dispositivos (CSP) específica del teléfono. Sin embargo, esto será una carga adicional en 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 en función de UICC y en el cambio de UICC. 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 las ITL 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.).
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 consentimiento del usuario. Los IHD no pueden escribir la interfaz de usuario para los componentes de la plataforma. Por lo tanto, el adaptador de GNSS controla la interfaz de usuario para el consentimiento del usuario en nombre del controlador GNSS. Las ICTL de notificación del controlador GNSS para solicitar un elemento emergente de la interfaz de usuario y las ICTLs para el adaptador de GNSS para transmitir la respuesta del usuario a dicha solicitud se definen en IOPS del controlador GNSS.

Para implementar un cliente SUPL totalmente funcional, la pila de IHV deberá hacer uso de interfaces o funcionalidades generales disponibles 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 IHD pueden aprovechar para implementar su cliente SUPL:

Ninguna de las funcionalidades de esta funcionalidad forma parte de la plataforma de ubicación o de la 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.

Interacción del cliente SUPL con un controlador GNSS.

Enrutador SMS: El enrutador SMS permite al cliente SUPL suscribirse a la inserción WAP de mensajes de inserción SIP que llevan solicitudes SUPL NI.
Administrador de conexiones capacidad de configurar qué conexión se usará para que la SUPL y las API soliciten 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, Administrador de conexiones ofrece:
- Un 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á con el fin 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 conexión de telefonía 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 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 el 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 tendrá que 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 de banda ancha móvil (MBB): En Windows 10, no hay API disponibles a través del HLOS para recuperar medidas móviles, saber cuándo se ha realizado una llamada de emergencia, etc. Cualquier interacción con MBB debe realizarse mediante la integración directa con el MBB (mediante 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 soporte técnico al cliente que la pila GNSS y el hardware GNSS (el controlador GNSS y el dispositivo o motor GNSS) funcionan correctamente. El IHV puede proporcionar mecanismos propietarios para permitir que los OEM realicen esta prueba o, opcionalmente, pueden implementar la interfaz en la 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 en el que 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 mejorar la eficiencia y la velocidad durante la fabricación, es muy recomendable tener compatibilidad con simultaneidad para pruebas dentro de diferentes componentes.

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

Prueba de onda del operador: Esta prueba consiste en validar la prueba externa de conectividad/antena. En esta prueba, el motor GNSS debe buscar una señal CW y proporcionar las SNR (raciones de señal a ruido o ración de ruido a ración de ruido) en la respuesta. Lo ideal es que las pruebas proporcionen respuestas a 10 Hz.
Prueba automática: Esta prueba es 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 auto-validación para las conexiones de patillas 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 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á con solicitudes de control de E/S de dispositivo (DeviceIoControl) 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á con la opción FILE_FLAG_OVERLAPPED en la función CreateFile . Por lo tanto, todas las ICTL son implícitamente asincrónicas. Sin embargo, aunque la mayoría de los ICTLs de GNSS son semánticamente asincrónicos (por ejemplo, un IOCTL desencadena una actividad dentro del controlador y los resultados se esperan de forma asincrónica), algunos IOCTLs son semánticamente sincrónicos en el sentido de que no hay ninguna acción o actividad asincrónica lógica implicada con tales IOCTLs. El comportamiento sincrónico de estos pocos IOCTLs 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 ICTLs. Se espera que el adaptador GNSS respete el contrato de una llamada sincrónica y, en caso de errores, puede o no reintentar estos comandos. El controlador IHV debe asegurarse de que ha incorporado todas las lógicas en el lado del controlador antes de devolver un error.

En el caso de las operaciones de solicitud y respuesta, el adaptador 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 para una única corrección de capturas 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, debe 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 y es un detalle de implementación del motor. El adaptador 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 otros cálculos. 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 sesión de captura única en cualquiera de los dos casos:

Obtiene una corrección final del controlador.
Se ha alcanzado el tiempo de respuesta de la solicitud. Aquí se enviará la última corrección intermedia a la aplicación.

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

diagrama que muestra correcciones intermedias para dos sesiones.

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ó pasando por una mejor corrección para cumplir el requisito de precisión y siguió enviando correcciones intermedias entre sí. Una vez alcanzado el límite de tiempo de respuesta de la sesión, el adaptador emitió una corrección 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 importante del diseño que se debe tener en cuenta al implementar la compatibilidad con una sola toma es que, si no se admiten sesiones de seguimiento basadas en distancia y sesiones de seguimiento basadas en el tiempo, el motor 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 de GNSS detiene el 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 modo de 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.

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.

diagrama de secuencia para la arquitectura de gnss .

La descripción de la secuencia es la siguiente:

El adaptador de GNSS abre el controlador GNSS mediante la API CreateFile . WDF/KMDF/UMDF hace que las devoluciones de llamada opcionales necesarias se realicen en el controlador GNSS. El identificador de archivo devuelto se usa para todas las operaciones posteriores.
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.
El adaptador de GNSS emite IOCTL para obtener las funcionalidades del dispositivo. El controlador GNSS devuelve las funcionalidades del dispositivo y completa la operación de E/S.
El adaptador de GNSS emite ICTLs 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.
El adaptador GNSS emite una 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.
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.
El paso 6 se repite hasta que el controlador GNSS indica que no se esperan más correcciones (corrección final recibida).
El adaptador de GNSS emite IOCTL_GNSS_STOP_FIXSESSION. El controlador GNSS realiza la operación de limpieza necesaria asociada a la solicitud de corrección original.
El adaptador GNSS cierra el identificador de archivo del controlador mediante la API CloseHandle .

Las ICTL de 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 GNSS iniciará sesiones de seguimiento de distancia con el controlador GNSS, solo si esta última 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 debe cubrir antes de que el controlador GNSS proporcione una actualización de posición. El motor de 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 haya 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 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. 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 GNSS, pero el adaptador GNSS aún no ha detenido la sesión de seguimiento, el motor GNSS debe continuar comprobando, de forma optimizada para energía, si puede reanudar la ubicación de seguimiento. El IHV puede usar optimizaciones para realizar esta detección a baja potencia. Entre las técnicas comunes para la optimización se incluyen las siguientes:

Retroceso progresivo
Esperando señales de bajo costo que indican que los movimientos del dispositivo se vuelven a comprobar
Comprobaciones de energía baja para la señal por satélite

Una vez que el motor GNSS pueda proporcionar una corrección final de nuevo después de una condición de error, debe enviar esa posición al adaptador GNSS como una 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 la 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 la 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:

seguimiento interno del controlador gnss .

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 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 la baja potencia cuando se puede recuperar y cuando se recupera, lo indica al adaptador GNSS mediante el envío de 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 tiempo

Las aplicaciones que requieren una actualización de posición frecuente y regular pueden usar 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 el elemento posterior 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 hacer uso de estos valores para comprender la intención de la solicitud de aplicación y tomar decisiones inteligentes, como adaptar la frecuencia a la que 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 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 revertirse a otros mecanismos para proporcionar actualizaciones de posición a la aplicación del usuario final.

El IHV puede usar optimizaciones para realizar esta detección a baja potencia, como se explica en la sección anterior. Una vez que el motor GNSS pueda proporcionar una corrección final de nuevo después de una condición de error, debe enviar esa posición al adaptador GNSS como una 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.

diagrama de seguimiento basado en tiempo para correcciones de controladores gnss.

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 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 un seguimiento de la posición. Cuando el motor de GNSS no puede proporcionar una corrección en un plazo de 15 segundos a partir del intervalo requerido por los parámetros de sesión, el controlador GNSS envía un error. El motor GNSS continúa comprobando la baja potencia cuando se puede recuperar y cuando se recupera, lo indica al adaptador GNSS mediante el envío de 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 de GNSS puede mantenerse activo o incluso iniciar sesiones de seguimiento basadas en tiempo de espera 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 geovalla 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.

Control de diferentes tipos de sesión de corrección simultáneamente

Algunos motores GNSS avanzados pueden controlar simultáneamente una sesión de captura única, con un Distance-Based o una sesión de seguimiento de Time-Based. Idealmente, las sesiones independientes no deben influir entre sí, pero es posible que esto no siempre sea posible, especialmente en el caso de sesiones simultáneas de seguimiento basado en disparo único y basado en tiempo. En esta sección se proporcionan algunas directrices para la implementación de IHV para en caso de que se deba poner en peligro las 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 basado en distancia
TBT: sesión de seguimiento basado en tiempo
TBF: Tiempo entre correcciones

En la tabla siguiente se proporcionan algunos escenarios para controlar sesiones de seguimiento únicas y basadas en el tiempo simultáneamente:

Caso	¿SS activo?	¿TBT activo?	Detalles del caso	Intervalo aceptable de correcciones	Comentarios
1	X	X	Sesión de SS en curso en el momento de la sesión periódica de TBT iniciada con el tiempo de espera >restante = intervalo	Igual que el intervalo TBT	Comportamiento de la sesión de SS: Las correcciones intermedias y finales se envían hasta el tiempo de espera. Sesión cerrada inmediatamente después de recibir la detención. Comportamiento de la sesión TBT: Se envían correcciones intermedias y finales. Correcciones recibidas aproximadamente según el intervalo. Sesión cerrada inmediatamente después de recibir la detención.
2	X	X	Sesión de SS en curso en el momento de la sesión periódica de TBT iniciada con el intervalo de tiempo de espera < restante	El intervalo sigue siendo el mismo que el tiempo de espera del SS, hasta que se cumpla la sesión de SS. A continuación, el intervalo se puede actualizar para que sea el mismo que el intervalo TBT.	Comportamiento de la sesión de SS: Las correcciones intermedias y finales se envían hasta el tiempo de espera. Sesión cerrada inmediatamente después de recibir la detención. Comportamiento de la sesión TBT: Se envían correcciones intermedias y finales Las correcciones recibidas aproximadamente según el intervalo, pero podrían ser más frecuentes mientras se atiende la sesión de SS. Sesión cerrada inmediatamente después de recibir la detención.
3	X	X	Sesión de SS iniciada mientras hay una sesión periódica de TBT en curso iniciada con el tiempo de espera >= intervalo	Igual que el intervalo TBT	Comportamiento de la sesión de SS: Las correcciones intermedias y finales se envían hasta el tiempo de espera. Sesión cerrada inmediatamente después de recibir la detención. Comportamiento de la sesión TBT: Se envían correcciones intermedias y finales Correcciones recibidas aproximadamente según el intervalo. Sesión cerrada inmediatamente después de recibir la detención.
4	X	X	Sesión de SS iniciada mientras hay una sesión periódica de TBT en curso iniciada con el intervalo de tiempo de espera <	El intervalo cambia para que sea el mismo que el tiempo de espera de SS, hasta que se cumpla la sesión de SS. A continuación, el intervalo se puede actualizar para que sea el mismo que el intervalo TBT.	Comportamiento de la sesión de SS: Las correcciones intermedias y finales se envían hasta el tiempo de espera. Sesión cerrada inmediatamente después de recibir la detención. Comportamiento de la sesión TBT: Se envían correcciones intermedias y finales. Las correcciones recibidas aproximadamente según el intervalo, pero podrían ser más frecuentes mientras se atiende la sesión de SS. Sesión cerrada inmediatamente después de recibir la detención.
5		X	Sesión periódica de TBT iniciada con el intervalo modificado	La sesión con módem se actualiza al nuevo intervalo para que sea el mismo que el intervalo TBT. Si es necesario, se reiniciará la sesión del módem.	Comportamiento de la sesión de SS: No aplicable Comportamiento de la sesión TBT: Se envían correcciones intermedias y finales. Correcciones recibidas aproximadamente según el intervalo. Sesión cerrada inmediatamente después de recibir la detención.
6	X	X	Sesión de SS en curso en el momento en el que una sesión periódica de TBT en curso recibe un cambio de intervalo, con el tiempo de espera >restante = intervalo	Igual que el intervalo TBT	Comportamiento de la sesión de SS: Las correcciones intermedias y finales se envían hasta el tiempo de espera. Sesión cerrada inmediatamente después de recibir la detención. Comportamiento de la sesión TBT: Se envían correcciones intermedias y finales Correcciones recibidas aproximadamente según el intervalo. Sesión cerrada inmediatamente después de recibir la detención.
7	X	X	Sesión de SS en curso en el momento en el que una sesión periódica de TBT en curso recibe un cambio de intervalo, con el intervalo de tiempo de espera < restante	El intervalo cambia para que sea el mismo que el tiempo de espera restante del SS, hasta que se cumpla la sesión de SS. A continuación, el intervalo se puede actualizar para que sea el mismo que el intervalo TBT.	Comportamiento de la sesión de SS: Las correcciones intermedias y finales se envían hasta el tiempo de espera. Sesión cerrada inmediatamente después de recibir la detención./li> Comportamiento de la sesión TBT: Se envían correcciones intermedias y finales Las correcciones recibidas aproximadamente según el intervalo, pero podrían ser más frecuentes mientras se atiende la sesión de SS. Sesión cerrada inmediatamente después de recibir la detención.

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 menor 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:

Caso	Precisión de SS	Precisión de DBT o TBT	Precisión general del motor GNSS	Comentarios
1	Medio/Bajo --> Alto	No aplicable	Medio/Bajo --> Alto	Comportamiento de la sesión de SS: La sesión con el dispositivo GNSS se actualiza o reinicia para obtener un resultado de alta precisión. Las correcciones intermedias se proporcionan al HLOS a medida que están disponibles.
2	Alto--> Medio/Bajo	No aplicable	Alto--> Medio/Bajo	Comportamiento de la sesión de SS: La sesión con el dispositivo GNSS se actualiza o reinicia para obtener el resultado de precisión media/baja. Si ya hay disponible una corrección que cumpla los requisitos, se devuelve como una corrección final. De lo contrario, las correcciones intermedias se proporcionan al HLOS a medida que están disponibles.
3	Medio/Bajo --> Alto	Alto	Alto	Comportamiento de la sesión de SS: Dado que ya existe una sesión de alta precisión para la sesión DBT o TBT, la sesión de SS solo proporciona correcciones intermedias adicionales al HLOS hasta que se obtiene la precisión final deseada o se obtiene una corrección final.
4	Alto--> Medio/Bajo	Alto	Alto	Comportamiento de la sesión de SS: Dado que ya existe una sesión de alta precisión para la sesión DBT o TBT, la sesión de SS solo proporciona correcciones intermedias adicionales al HLOS hasta que se obtiene la precisión final deseada o se obtiene una corrección final.
5	Medio/Bajo --> Alto	Medio/Bajo	Media/Baja:> alta a media/baja después de que se complete la sesión de SS	Comportamiento de la sesión de SS: La sesión con el dispositivo GNSS se actualiza o reinicia para obtener un resultado de alta precisión. Las correcciones intermedias se proporcionan al HLOS a medida que están disponibles. Comportamiento de la sesión de DBT o TBT: Es correcto que esta sesión reciba temporalmente resultados de alta precisión. Sin embargo, después de atender la sesión de SS, la precisión de esta sesión debe volver a Media/Baja.
6	Alto--> Medio/Bajo	Medio/Bajo	Alto--> Medio/Bajo	Comportamiento de la sesión de SS: La sesión con el dispositivo GNSS se actualiza o se reinicia para obtener el resultado de precisión media/baja. Si ya hay disponible una corrección que cumpla los requisitos, se devuelve como una corrección final. De lo contrario, las correcciones intermedias se proporcionan al HLOS a medida que están disponibles.
7	No aplicable	Medio/Bajo --> Alto	Medio/Bajo --> Alto	Comportamiento>de la sesión de DBT o TBT:** La sesión con el dispositivo GNSS se actualiza o reinicia para obtener resultados de alta precisión. Las correcciones intermedias se proporcionan al HLOS a medida que están disponibles.
8	No aplicable	Alto--> Medio/Bajo	Alto--> Medio/Bajo	Comportamiento de la sesión de DBT o TBT: La sesión con el dispositivo GNSS se actualiza o se reinicia para obtener el resultado de precisión media/baja. Si ya hay disponible una corrección que cumpla los requisitos, se devuelve como una corrección final. De lo contrario, las correcciones intermedias se proporcionan al HLOS a medida que están disponibles.
9	Alto	Medio/Bajo --> Alto	Alto	Comportamiento de la sesión de DBT o TBT: La sesión ya estaba obteniendo correcciones de alta precisión o correcciones intermedias, por lo que no hay cambios.
10	Alto	Alto--> Medio/Bajo	Después, los cambios altos a Medio/Bajo una vez completada la sesión de SS	Comportamiento de la sesión de DBT o TBT: La sesión puede seguir obteniendo correcciones de alta precisión o correcciones intermedias, hasta que se complete la sesión de SS. A continuación, cambiará a correcciones de precisión media/baja.
11	Medio/Bajo<	Medio/Bajo --> Alto	Medio/Bajo --> Alto	Comportamiento de la sesión de DBT o TBT: La sesión con el dispositivo GNSS se actualiza o reinicia para obtener resultados de alta precisión. Las correcciones intermedias se proporcionan al HLOS a medida que están disponibles.
12	Medio/Bajo	Alto--> Medio/Bajo	Alto--> Medio/Bajo	Comportamiento de la sesión de DBT o TBT: La sesión con el dispositivo GNSS se actualiza o se reinicia para obtener el resultado de precisión media/baja. Si ya hay disponible una corrección que cumpla los requisitos, se devuelve como una corrección final. De lo contrario, las correcciones intermedias se proporcionan al HLOS a medida que están disponibles.

Compartir a través de

Introducción a la arquitectura

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

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

Información general sobre la interfaz del sistema de navegación global satélite (GNSS)