Arquitetura de driver do Sistema Global de Navegação por Satélite (GNSS)

Fornece uma visão geral da arquitetura do driver umdf 2.0 do GNSS (Global Navigation Satellite System), considerações sobre E/S e discute vários tipos de sessões de acompanhamento e correção.

Visão geral da arquitetura

O diagrama de bloco de componente de alto nível a seguir mostra como o driver GNSS (Global Navigation Satellite System) UMDF 2.0 se integra à plataforma Windows 10.

Os componentes no diagrama são descritos aqui:

• Aplicativo LBS: Um aplicativo de usuário que usa a funcionalidade de localização da plataforma Windows 10

• Aplicativo de teste: Um aplicativo para testar a funcionalidade do GNSS.

• API do GNSS: A interface IGnssAdapter COM (Component Object Model) que expõe a funcionalidade do dispositivo GNSS para os componentes internos do serviço de localização, bem como para testar aplicativos. A forma exata dessa API está fora do escopo deste documento. Os componentes do Windows usam o dispositivo GNSS programando na interface COM IGnssAdapter . O conjunto de APIs GNSS é uma API privada destinada somente aos componentes da plataforma de localização (por exemplo, o serviço de localização e as aplicações de teste de localização) e não está disponível para outras aplicações de primeira ou de terceiros.

• Adaptador GNSS: Este é um objeto COM singleton que implementa a interface COM IGnssAdapter . Os aplicativos de teste e os componentes internos do serviço de localização instanciam esse objeto e usam o dispositivo GNSS por meio da interface IGnssAdapter . O componente do mecanismo de posicionamento GNSS do serviço de localização implementa a classe COM que expõe a interface IGnssAdapter . O serviço de localização expõe um mecanismo de fábrica para aplicações de teste e outros aplicativos fora de processo, permitindo a instanciação de um objeto COM singleton da classe COM do adaptador GNSS dentro do próprio serviço de localização. Aplicativos fora de processo usam o ponteiro da interface COM para programar com o driver GNSS.

  O COM manipula o proxy do ponteiro da interface para os aplicativos fora de processo, de modo que os aplicativos tratem o ponteiro da interface IGnssAdapter como um objeto COM em processo, mas, na verdade, as chamadas são tratadas pelo adaptador GNSS singleton dentro do serviço de localização.

  O motor de posicionamento GNSS usa o objeto do adaptador GNSS interno para fornecer ao serviço de localização uma funcionalidade específica de localização. O adaptador GNSS abre um identificador de arquivo para o driver GNSS usando a API CreateFile e, em seguida, encapsula as chamadas de APIs nativas do GNSS em chamadas DeviceIoControl apropriadas, mantém o computador de estado com o objeto de driver GNSS e mantém o estado das várias solicitações de entrada das camadas superiores. Esse componente interage diretamente com a pilha subjacente de dispositivos GNSS por meio da interface pública GNSS IOCTL definida neste documento. O dispositivo GNSS é logicamente tratado como um recurso exclusivo e, portanto, o adaptador GNSS singleton controla todo o acesso ao dispositivo GNSS.

  Determinados aplicativos de teste de driver de caixa branca também podem usar a interface IOCTL do driver GNSS diretamente em um ambiente de não produção em vez de usar o adaptador GNSS por meio das APIs privadas do GNSS. No entanto, esses aplicativos de teste terão que implementar seu próprio computador de estado e processamento para imitar determinadas funcionalidades do adaptador GNSS.

• Driver GNSS: Um driver entregue por IHV implementado usando o UMDF 2.0. O driver GNSS dá suporte às APIs de DeviceIoControl do GNSS ao interagir com o hardware GNSS real. O driver GNSS também funciona como mediador/integrador para as funções SUPL.

• Dispositivo/mecanismo GNSS: Esse é um componente conceitual que encapsula as partes de soc e hardware do dispositivo GNSS. Um IHV pode optar por implementar a maior parte da funcionalidade do GNSS neste componente, tornando a camada de driver do GNSS muito fina (essencialmente um adaptador para interface com o dispositivo GNSS).

Suporte para dispositivos GNSS (Global Navigation Satellite System) e drivers que seguem o modelo herdado do Windows

A plataforma de localização no Windows 10 dá suporte a dispositivos GNSS integrados por meio do driver da classe de sensores v1.0 herdado (consulte como escrever um driver de sensor de localização) ou integrados por meio da nova DDI GNSS descrita na referência do driver GNSS.

Portanto, os dispositivos Windows com um dispositivo GNSS que se integram ao modelo de extensão da classe Sensor v1.0 que existia no Windows 7, Windows 8 e Windows 8.1 devem continuar funcionando no Windows 10 sem a necessidade de alterações. É altamente recomendável que esses drivers (e quaisquer novos drivers) sejam publicados no Windows Update para melhorar o processo de atualização para nossos usuários.

Também haverá dois conjuntos diferentes de testes para dispositivos GNSS no HLK (Hardware Lab Kit) emitidos com o Windows 10:

• Um novo conjunto de testes para certificar drivers seguindo o novo modelo.

• Outro conjunto de testes para certificar os motoristas que seguem o modelo antigo. Eles serão o mesmo conjunto de testes que estavam disponíveis no WHCK no Windows 8.1.

Um novo componente coletor no HLK identifica qual dos dois conjuntos de testes precisa ser executado em um sistema, se houver.

Coexistência de dispositivos GNSS (Global Navigation Satellite System)

No raro caso de vários dispositivos GNSS detectados em um sistema, a plataforma de localização usará apenas um dispositivo, principalmente para reduzir o consumo geral de energia no sistema. As seguintes suposições foram consideradas:

• Os dispositivos que usam a nova DDI provavelmente serão mais recentes e, portanto, mais propensos a ter melhor consumo de energia, dar suporte a mais constelações e dar suporte a uma melhor assistência. Portanto, se um dispositivo que usa o modelo de driver antigo e um dispositivo que usa o novo modelo de driver forem detectados, este último será o selecionado.

• Se um usuário conecta um dispositivo GNSS externo quando um dispositivo GNSS interno está presente, é mais provável que o usuário queira que esse dispositivo externo seja usado.

O comportamento da plataforma de localização, com base nessas suposições, será o seguinte:

• Caso de dois drivers herdados coexistentes: para evitar problemas de compatibilidade retroativa, o comportamento será o mesmo do Windows 8.1, no qual ambos os dispositivos GNSS são usados simultaneamente e uma das respostas é comunicada ao longo da pilha para aplicativos.

• Caso de um driver herdado no dispositivo e um novo driver externamente conectado: o dispositivo GNSS externamente conectado é usado.

• Caso haja um novo driver no dispositivo e um novo driver conectado externamente, o dispositivo GNSS conectado externamente é utilizado.

Se o dispositivo GNSS selecionado der suporte a geofencing ou outras operações descarregadas, o descarregamento será feito enquanto esse dispositivo for usado. O adaptador GNSS não dividirá a funcionalidade ou as sessões entre vários dispositivos GNSS.

Visão geral da interface GNSS (Global Navigation Satellite System)

A interação entre o adaptador GNSS e o driver GNSS se enquadra nas seguintes categorias:

Troca de informações de capacidade

Para dar suporte à extensibilidade e à adaptabilidade da pilha GNSS em plataformas Windows, o adaptador GNSS e o driver GNSS estabelecem uma compreensão comum das várias funcionalidades bem definidas da pilha GNSS subjacente, bem como o suporte fornecido pela plataforma Windows. Os aspectos de capacidade são bem definidos pela Microsoft como parte dessa definição de interface GNSS e evoluirão à medida que mais inovação continuar a ocorrer no espaço GNSS e um conjunto diversificado de chipsets/drivers surgir no mercado. O adaptador GNSS consulta as várias funcionalidades do driver/dispositivo GNSS subjacente no momento da inicialização ou na base necessária e otimiza adequadamente a interação com o driver GNSS.

A troca de informações de funcionalidade entre o adaptador GNSS e o driver GNSS é feita usando os códigos de controle IOCTL_GNSS_SEND_PLATFORM_CAPABILITY e IOCTL_GNSS_GET_DEVICE_CAPABILITY.

Configuração e comando do driver GNSS (Global Navigation Satellite System)

O adaptador GNSS pode executar configuração única ou configuração periódica do driver GNSS. Da mesma forma, o adaptador GNSS pode executar determinados comandos específicos do GNSS por meio do driver. Isso é feito definindo um protocolo de execução de comando entre o driver e o HLOS (sistema operacional de alto nível). Dependendo do tipo de comando específico, a ação pretendida pode entrar em vigor imediatamente ou após uma reinicialização do sistema. Semelhantes às informações de funcionalidade do dispositivo GNSS, os comandos GNSS também são bem definidos pela Microsoft como parte dessa definição de interface GNSS e continuarão evoluindo com inovações futuras e diversificação de dispositivos/drivers GNSS.

A execução e a configuração do comando do dispositivo são feitas usando o código de controle IOCTL_GNSS_SEND_DRIVERCOMMAND.

Informações de posição

Essa é a função primária do dispositivo GNSS subjacente. No formulário mais básico, o adaptador GNSS solicita a posição atual do dispositivo do driver GNSS. As variações da solicitação de posição incluem (mas não se limitam a) os seguintes tipos de sessão de posição:

• Posição atual do dispositivo (correção de tiro único)

• Fluxo periódico contínuo de correções (acompanhamento baseado em tempo)

• Fluxo contínuo de correções com base no limite de movimento (acompanhamento baseado em distância)

O único tipo de sessão de posição obrigatória exigida por cada hardware GNSS e driver GNSS é o tipo de sessão de correção de posição instantânea. Nativo (implementado no SOC, no dispositivo GNSS e não no driver GNSS ou em um serviço em execução no processador de aplicativos), sessões de acompanhamento baseadas em tempo e sessões de acompanhamento baseadas em distância podem ter suporte opcionalmente. O principal benefício desses dois tipos de sessões de acompanhamento nativas é a economia de energia potencial mantendo o AP (processador de aplicativos) inativo por mais tempo, fazendo mais processamento no SOC e relatando apenas alterações quando necessário. O suporte para o acompanhamento baseado em distância nativo é mais impactante do que as sessões de acompanhamento baseadas em tempo nativas, pois pode trazer maior economia de energia e porque é mais amplamente usado por aplicativos.

O ato de recuperar informações de posição do driver GNSS ocorre por meio de uma sessão de correção exclusiva e com estado, que consiste nas seguintes ações:

1. Iniciar a sessão de correção: O adaptador GNSS inicia uma sessão de correção inicial (como resultado de uma solicitação de um aplicativo LBS). O adaptador GNSS estabelece os requisitos específicos e as preferências associadas à solicitação, e instrui o driver GNSS a iniciar o processo para obter a correção emitindo o código de controle IOCTL_GNSS_START_FIXSESSION.

2. Obter posição do dispositivo (corrigir dados): Depois que uma sessão de correção é iniciada, o adaptador GNSS emite o código de controle IOCTL_GNSS_GET_FIXDATA para começar a aguardar uma correção do driver. Quando uma nova informação de posição está disponível no mecanismo, o driver GNSS responde a essa solicitação de correção pendente.

   Se o tipo de sessão de correção for LKG (em vez da correção atual), as informações de posição virão do cache do driver.

   O adaptador GNSS garante que uma solicitação de E/S assíncrona esteja sempre disponível para o driver GNSS retornar os dados de correção quando disponível. Dependendo da natureza da correção, se mais dados de correção forem esperados, o adaptador GNSS emitirá outra solicitação de E/S (usando o mesmo IOCTL) e essa sequência continuará até que não haja mais dados disponíveis ou a sessão de correção seja interrompida.

3. Modifique a sessão de correção: Se o driver GNSS não der suporte à multiplexação de sessões de correção do mesmo tipo, o adaptador GNSS poderá emitir um IOCTL_GNSS_MODIFY_FIXSESSION para esse tipo de sessão de correção quando ele faz multiplexação em seu nível.

4. Interromper a sessão de correção: O adaptador GNSS emite uma sessão de parada de correção quando nenhuma outra informação de posição relativa a uma sessão de correção específica é necessária ou esperada.

Suporte a geofencing nativo

A DDI do GNSS dá suporte a cenários de descarregamento de cerca geográfica usando um conjunto de IOCTLs definidos nesta especificação. Um sinalizador de funcionalidade especial é definido para que o driver indique esse suporte, esse sinalizador só deve ser definido se a pilha GNSS der suporte a geofencing nativamente (ou seja, ele implementa o geofencing no chip GNSS em vez de no processador de aplicativos). Se o driver não oferecer suporte nativo a geofencing, a flag não deverá ser definida. O HLOS já dá suporte a um mecanismo de rastreamento de geofence baseado em AP (processador de aplicativos) subótimo; embora essa solução não seja tão otimizada quanto uma solução nativa poderia ser, ela é bem testada e otimizada, portanto, não deve ser substituída por uma solução equivalente implementada no AP.

O acompanhamento de cerca geográfica pelo HLOS requer que o processador de aplicação desperte periodicamente para detectar violações de cerca geográfica, consumindo energia mesmo quando as cercas não são violadas. Portanto, essa implementação é considerada abaixo do ideal.

O HLOS também usa o acompanhamento de cerca geográfica baseado em AP como um mecanismo de failover quando o driver subjacente não consegue rastrear cercas geográficas devido a condições de sinal baixo ou outros erros transitórios, após notificações de erro recebidas da solução de acompanhamento de cerca geográfica nativa. O suporte nativo a geofencing é mais benéfico somente quando o monitoramento de geocerca é totalmente delegado ao SoC e o processador de aplicativos é ativado apenas para processar eventos relacionados à geocerca. Se o hardware não der suporte ao rastreamento de cerca geográfica nativo, o driver GNSS não deverá tentar implementá-lo na camada de driver.

O mecanismo GNSS também deve expor parâmetros de ajuste específicos de IHV documentados para permitir encontrar o equilíbrio certo entre o consumo de energia e a experiência do usuário. Além disso, o número de geofences com suporte deve ser maior do que o valor MIN_GEOFENCES_REQUIRED definido no arquivo de cabeçalho. Observe que o MIN_GEOFENCES_REQUIRED é definido por aplicativo, pois um aplicativo não tem conhecimento do número de cercas geográficas usadas por outros aplicativos ou pela operadora móvel.

O suporte de descarregamento de geofencing envolve os seguintes requisitos:

• O HLOS deve ser capaz de criar uma ou mais cercas geográficas por meio da DDI e o driver as envia para o hardware para começar a rastreá-las.

• O HLOS poderá excluir uma ou mais cercas geográficas criadas anteriormente por meio da DDI e o driver as envia para o hardware para parar de rastreá-las.

• Idealmente, o hardware GNSS deve compreender o estado inicial de monitoramento de cerca geográfica para cada cerca geográfica e usá-lo para relatar apenas as alterações desse estado inicial. Se o hardware GNSS não der suporte a essa funcionalidade, ele relatará o estado inicial ao HLOS sempre que uma cerca geográfica for criada.

• O hardware GNSS rastreia a posição atual do dispositivo de forma eficiente e ativa a AP sempre que o dispositivo inseriu e/ou saiu de uma cerca geográfica controlada. O driver GNSS passa os alertas de cerca geográfica para o HLOS.

• Em sinal de satélite baixo e outras condições de erro transitórias, o mecanismo GNSS pode não conseguir acompanhar de forma confiável as cercas geográficas existentes. O mecanismo GNSS deve ser capaz de detectar as interrupções de rastreamento e o driver GNSS deve passar o alerta de erro de status de rastreamento para o HLOS. O HLOS alterna para o controle de cerca geográfica baseado em AP padrão até que o hardware GNSS seja capaz de recuperar e acompanhar as cercas geográficas novamente.

• As condições exatas nas quais um mecanismo GNSS precisa fornecer uma notificação para indicar que as cercas geográficas não podem ser rastreadas variarão e a implementação será específica do IHV. A seguir estão algumas diretrizes para a implementação:

  • Se o mecanismo GNSS for capaz de detectar com alta confiança que o usuário não está se movendo e não houver limite de cerca geográfica em 25 metros ou menos, o mecanismo GNSS não precisará enviar um erro de rastreamento.

  • Se o mecanismo GNSS for capaz de detectar com alta confiança que o usuário não está se movendo, mas há um limite de cerca geográfica em 25 metros ou menos, o mecanismo GNSS precisa enviar um erro de rastreamento dentro de um minuto.

  • Se o mecanismo GNSS estiver detectando que o usuário está se movendo e há um limite de cercas geográficas dentro de 100 metros ou menos, o mecanismo GNSS precisará enviar um erro de rastreamento dentro de um minuto ou menos.

  • Se o mecanismo GNSS não conseguir determinar se o usuário está se movendo e há um limite de cercas geográficas dentro de 100 metros ou menos, o mecanismo GNSS precisa enviar um erro de rastreamento dentro de um minuto ou menos.

  • Se o mecanismo GNSS estiver detectando que o usuário está se movendo, o mecanismo GNSS precisará enviar um erro de rastreamento em um tempo proporcional à velocidade estimada de movimento e à distância da cerca geográfica mais próxima. Uma recomendação é enviar um erro em [(Distância até o limite mais próximo da cerca (m) / velocidade estimada (m/s)) - 15s]. O mecanismo GNSS pode usar indicadores de detecção de movimento para determinar o tempo no qual o erro de rastreamento deve ser enviado.

  • Se o mecanismo GNSS não conseguir determinar se o usuário está se movendo, o mecanismo GNSS precisará enviar um erro de rastreamento em um tempo proporcional à alta velocidade de movimento e à distância da cerca geográfica mais próxima. Uma recomendação é enviar um erro dentro de [Distância até a borda mais próxima da cerca (m) / 343(m/s)].

• Durante o período em que o motor GNSS relatou um erro no status de rastreamento de cerca geográfica, não deve haver eventos de violação de cerca geográfica enviados ao HLOS.

• O HLOS pode redefinir o rastreamento de geocerca excluindo todas as geocercas criadas anteriormente por meio de um único comando.

• Os geofences de origem móvel não são mantidos no hardware ou driver GNSS em reinicializações do sistema ou do driver. O HLOS manipula a persistência em nome dos aplicativos do usuário final e cria/exclui cercas geográficas conforme necessário.

Em termos de interações entre o adaptador GNSS e o mecanismo GNSS que dá suporte ao descarregamento de isolamento geográfico nativamente, no caso de falhas de controle de cercas geográficas, o adaptador GNSS fará o seguinte:

• Ele usará o rastreamento baseado em AP quando o driver GNSS falhar no rastreamento.

• Ele continuará enviando atualizações por push (adicionar/excluir) nas cercas geográficas que estão sendo rastreadas no nível do sistema operacional para o driver, também para que estejam em sincronia. Isso ajudará o mecanismo GNSS a identificar quais cercas geográficas estão sendo rastreadas pelo sistema operacional no momento, e pode determinar se pode ou não rastrear com base nos novos dados.

• Ele enviará as alterações de estado de cerca geográfica conforme determinado pelo rastreador baseado em AP assim que o driver GNSS enviar de volta o sucesso na sua capacidade de rastrear.

Notificações de driver para obter assistência e dados auxiliares

De tempos em tempos, o driver GNSS pode precisar de dados de assistência ou ações auxiliares do adaptador GNSS. Isso inclui as várias formas de dados do AGNSS (injeção de tempo, efemérides, posição inicial aproximada), pop-up de consentimento do usuário para dar suporte ao posicionamento do user plane iniciado pela rede e assim por diante.

• Os dados de assistência do GNSS podem ser obtidos pelo driver GNSS sem usar o adaptador GNSS. No entanto, é recomendável que os dados de assistência sejam obtidos usando o adaptador GNSS e aproveitando o serviço de posicionamento da Microsoft por vários motivos:

  • A stack de localização da Microsoft cuidará de estabelecer as conexões de dados e aderir a quaisquer restrições de roaming, preferências de dados, integração do modo silencioso da rede e assim por diante.

  • O serviço de posicionamento da Microsoft pode obter periodicamente dados de assistência específicos para um IHV por meio de conexão de back-end de servidor para servidor e fornecê-los a todos os dispositivos que precisam, salvando o IHV da necessidade de implantar o serviço de assistência de front-end em todo o mundo que atenda aos requisitos de disponibilidade, escalabilidade e capacidade de resposta.

• Os consentimentos do usuário para privacidade para aplicativos de caixa de entrada pertencem ao sistema operacional. Portanto, qualquer interface do usuário para notificar o usuário sobre uma solicitação de local iniciada pela rede ou qualquer interface do usuário para solicitar consentimento do usuário para responder a uma solicitação de local iniciada pela rede pertencerá à Microsoft. O driver GNSS notificará o adaptador GNSS quando uma solicitação de local iniciada pela rede for recebida e, se necessário, aguardará a resposta do usuário até o tempo padrão antes de continuar a atender à solicitação.

Como o driver GNSS não consegue iniciar uma solicitação para a camada superior por conta própria, esse tipo de operação pode ser realizado pelo adaptador GNSS buscando proativamente essa solicitação do driver GNSS e, assim, sempre mantendo um ou mais IRPs pendentes para que o driver GNSS possa responder a essas solicitações pendentes. Ao receber a solicitação para data de assistência/ajudante, o adaptador GNSS busca os dados (ou executa a ação específica em nome do driver GNSS) e, em seguida, injeta as informações necessárias no driver GNSS por meio de outra chamada DeviceIoControl.

A notificação do driver é manipulada por meio de um modelo de eventos comum. Por exemplo, para obter assistência GNSS, o adaptador GNSS usa o código de controle IOCTL_GNSS_LISTEN_AGNSS para receber a solicitação AGNSS do driver GNSS. Posteriormente, o adaptador GNSS busca os dados de assistência do AGNSS e emite IOCTL_GNSS_INJECT_AGNSS para enviar os dados ao driver GNSS.

Esse mecanismo de notificação também é usado para receber dados de alerta relacionados à cerca geográfica e atualizações de status. O adaptador usa o código de controle IOCTL_GNSS_LISTEN_GEOFENCE_ALERT para receber alertas de cerca geográfica individuais e IOCTL_GNSS_LISTEN_GEOFENCES_TRACKINGSTATUS para receber alterações no status geral do acompanhamento de cerca geográfica.

Registro em log de driver do GNSS (Global Navigation Satellite System)

Para fins de diagnóstico, o driver GNSS deve registrar erros e outras informações de diagnóstico usando o WPP (mecanismo de registro em log) prescrito pela Microsoft descrito abaixo ou ETW. É recomendável que os drivers utilizem o WPP para fins de registro em log em vez de ETW, embora ambos os mecanismos tenham suporte. Entre os motivos para se recomendar o WPP está a disponibilidade de ferramentas que podem ajudar na depuração de drivers.

O driver não deve registrar nenhuma informação, legível por humanos ou não, exceto através da técnica de registro em log especificada. Para obter mais informações, consulte Rastreamento de Software WPP.

Registrar mensagens com rastreamento de software WPP é semelhante ao uso de serviços de log de eventos do Windows. O driver registra uma ID de mensagem e dados binários não formatados em um arquivo de log. Posteriormente, um pós-processador converte as informações no arquivo de log em um formulário legível por humanos. No entanto, o rastreamento de software WPP dá suporte a formatos de mensagem mais capazes e flexíveis do que os suportados pelos serviços de log de eventos. Por exemplo, o rastreamento de software WPP tem suporte nativo para endereços IP, GUIDs, IDs do sistema, carimbos de data/hora e outros tipos de dados úteis. Além disso, os usuários podem adicionar tipos de dados personalizados relevantes ao aplicativo.

Suporte ao protocolo da operadora móvel

A pilha GNSS fornecida pelo IHV (o driver GNSS, o dispositivo/mecanismo GNSS) é necessária para dar suporte aos vários protocolos de posicionamento de operador móvel (SUPL, UPL, CP e assim por diante). Não fazer isso significa que o dispositivo não passará pela aceitação das operadoras móveis e limitará significativamente onde o dispositivo pode ser comercializado.

O suporte a esses protocolos e à conformidade com os requisitos da operadora móvel é obrigatório para enviar dispositivos para determinadas operadoras móveis. O suporte para protocolos de operadora móvel pode não ser essencial para a maioria das plataformas que não são de telefonia, especialmente se a plataforma não incluir suporte de banda larga móvel (MBB).

Todas as partes de implementação são abstraídas na pilha IHV e os componentes do Microsoft HLOS são independentes de:

• Os detalhes de implementação específicos dos protocolos (por exemplo, como os protocolos funcionam, a interpretação das mensagens de protocolo e assim por diante).

• A forma da pilha de implementação (por exemplo, a implementação pode estar localizada no dispositivo/motor GNSS, ou no driver GNSS, ou, se necessário, em um serviço HLOS separado).

• Interação entre as várias partes dentro da pilha GNSS de propriedade IHV para implementar os protocolos. Por exemplo, se o driver GNSS exigir os resultados da verificação Wi-Fi para responder a uma mensagem de protocolo SUPL específica, ele poderá fazer isso fazendo com que uma extensão de modo de usuário injete os resultados da verificação Wi-Fi ao driver por meio de uma chamada IOCTL privada ou faça essa parte do driver UMDF 2.0 ou manipule essa interação em um nível inferior. Os componentes HLOS do Microsoft GNSS estão alheios às interações entre os componentes da estrutura de GNSS do IHV.

Em resumo, o IHV ou OEM precisa fornecer um cliente SUPL (e potencialmente um cliente UPL se o sistema for enviado na China) e integrá-lo com/dentro do driver GNSS. Todas as interações da plataforma de localização com o cliente SUPL serão feitas por meio da DDI do GNSS.

Para facilitar a implementação dos protocolos da operadora móvel e reduzir a carga do desenvolvimento de software usando tecnologias específicas da plataforma, o adaptador GNSS fornece determinada funcionalidade para a pilha de GNSS IHV. O driver GNSS é tratado como o intermediário para receber essa funcionalidade dos componentes HLOS, por exemplo, o adaptador GNSS interage apenas com o driver GNSS e não com nenhuma outra parte da pilha de GNSS IHV. As IOCTLs do driver GNSS definem a sintaxe e a semântica dessa funcionalidade entre o driver GNSS e o adaptador GNSS. O driver GNSS é responsável pelo roteamento para o componente IHV específico que implementa o protocolo da operadora móvel. Em geral, o adaptador GNSS fornece a seguinte funcionalidade para o driver GNSS:

1. Configuração: As operadoras móveis provisionam o dispositivo e alteram a configuração usando o mecanismo de configuração imposto pelos padrões de protocolo OMA. Por exemplo, o padrão SUPL requer que a configuração SUPL seja feita com base na UICC e/ou seja feita usando as informações de perfil de configuração OMA SUPL obtidas por meio de OMA-DM ou OMA-CP.

   Determinadas funcionalidades disponíveis no telefone para fins de configuração (OMA-DM e OMA CP) não estavam disponíveis em outras plataformas até o Windows 10. A partir do Windows 10, todas as plataformas podem dar suporte à configuração SUPL por meio do CSP (Provedor de Serviços de Configuração SUPL), desde que a nova DDI GNSS seja utilizada. O provisionamento injetado por meio do CSP pode vir da própria imagem (por meio de provxml ou multivariante) ou da operadora móvel por meio de OMA-DM ou OMA-CP. O SUPL CSP é definido no SUPL CSP.

   O Windows 10 define uma tecnologia proprietária, o gerenciamento de dispositivos usando um CSP (Provedor de Serviços de Configuração), para interpretar e extrair os dados de configuração. A Microsoft fornece um CSP para consumir as configurações do OMA e transmitir essas configurações para o driver GNSS por meio do adaptador GNSS.

   Como alternativa, o IHV também pode escrever o componente do modo de usuário para consumir a especificação de configuração da operadora móvel usando a tecnologia de gerenciamento de dispositivos (CSPs) específica do telefone. No entanto, isso será um fardo adicional para o IHV e não é recomendado.

   Há suporte apenas para uma configuração SUPL em um sistema, inclusive em casos de dispositivos SIM duplos. A Microsoft fornece a funcionalidade para reconfigurar o SUPL com base na UICC e na alteração da UICC. Além disso, no caso do roaming do dispositivo, o HLOS configura novamente o cliente SUPL para funcionar no modo autônomo. Este documento define os IOCTLs para enviar esses dados de configuração por push para uma variedade de protocolos de operação móvel (SUPL 1.0 e 2.0, v2UPL e assim por diante).

2. Tratamento do consentimento do usuário para solicitações de NI: Para atender aos requisitos de privacidade, determinadas solicitações de posicionamento iniciadas pela rede precisam de consentimento do usuário. Os IHVs não têm permissão para desenvolver a interface do usuário para componentes da plataforma. Portanto, o adaptador GNSS gerencia a interface do usuário para obter o consentimento do usuário em nome do driver GNSS. As IOCTLs de notificação para que o driver GNSS solicite um pop-up de interface do usuário e os IOCTLs do adaptador GNSS para transmitir a resposta do usuário a essa solicitação são definidos em IOCTLs de driver GNSS.

Para implementar um cliente SUPL totalmente funcional, a pilha IHV precisará usar interfaces ou funcionalidades gerais disponíveis na plataforma do sistema operacional. Veja a seguir a lista de funcionalidades disponíveis no Windows 10 que os IHVs podem aproveitar para implementar seu cliente SUPL:

Nenhuma dessas funcionalidades faz parte da plataforma de localização ou da DDI do GNSS, mas ela está incluída aqui para esclarecimentos e para ajudar os desenvolvedores de driver do GNSS a entender o que pode ser aproveitado do sistema operacional para implementar a funcionalidade SUPL.

• Roteador SMS: O Roteador SMS permite que o cliente SUPL assine ao WAP Push de mensagens SIP Push que carregam solicitações de NI SUPL.

• Capacidade do Gerenciador de Conexões de configurar qual conexão deve ser usada para SUPL e APIs para solicitar essa conexão: As operadoras móveis podem precisar ter o tráfego SUPL em uma conexão dedicada ou simplesmente em uma conexão diferente da conexão de Internet padrão. Para fazer isso, o Gerenciador de Conexões oferece:

  • Um provedor de serviços de configuração que o OEM ou a operadora móvel pode usar para configurar qual conexão deve ser usada para fins de comunicações SUPL.

  • Uma API para o cliente SUPL consultar os parâmetros de conexão da conexão SUPL.

  • Uma API para estabelecer a conexão SUPL, com os parâmetros obtidos na etapa anterior.

• Configuração de conexão de celular: Para configurar os parâmetros de diferentes conexões celulares, por exemplo, os parâmetros para uma conexão SUPL, há um provedor de serviços de configuração que o OEM ou a operadora móvel podem usar. Em seguida, essa conexão pode ser associada no Gerenciador de Conexões à finalidade SUPL.

• Solicite para manter as conexões ativas enquanto uma conexão SUPL estiver em andamento: O cliente SUPL pode precisar iniciar conexões com o HSLP enquanto o sistema está em espera conectado. Isso pode acontecer porque o dispositivo GNSS precisa obter informações de assistência quando configurado para usar o posicionamento baseado na Microsoft ou porque a operadora móvel enviou uma solicitação de NI. Se esse for o caso, o cliente SUPL precisará iniciar uma conexão com o HSLP e garantir que a conexão esteja ativa até que a sessão SUPL seja concluída.

• Interações com o módulo MBB (Banda Larga Móvel): No Windows 10, não há APIs disponíveis por meio do HLOS para recuperar medidas de celular, saber quando uma chamada de emergência foi feita e assim por diante. Qualquer interação com o MBB precisa ser feita por meio da integração direta com o MBB (por meio de comandos AT ou outro método proprietário).

Teste de fabricação

Os OEMs precisam ter uma maneira de validar no momento da fabricação e também nos pontos de suporte ao cliente que o hardware GNSS e a pilha GNSS (o driver GNSS e o dispositivo/mecanismo GNSS) estão operando corretamente. O IHV pode fornecer mecanismos proprietários para permitir que os OEMs façam esse teste ou, opcionalmente, pode implementar a interface na DDI para permitir que o OEM inicie testes de fabricação e obtenha resultados.

A estrutura de localização será contornada ao realizar o teste de fabricação, visto que o foco principal do teste está na validação do hardware ou do driver. Em geral, o dispositivo estará em um "modo de sistema operacional seguro" especial em que o conjunto mínimo de componentes e serviços será carregado. Nesse modo, o OEM pode iniciar um conjunto de aplicativos de teste que dispararão casos de teste. Para eficiência e velocidade durante a fabricação, é altamente desejado ter suporte de simultaneidade para testes em diferentes componentes.

A interface para testes de fabricação inclui dois tipos de testes:

1. Teste de onda de transportadora: Esse teste é para validar o teste de conectividade/antena externa. Neste teste, o mecanismo GNSS deve procurar um sinal CW e fornecer as medidas de SNRs (relações sinal-ruído ou relação portadora-ruído) na resposta. Idealmente, os testes devem fornecer respostas a 10 Hz.

2. Auto-teste: Esse teste é para validar a funcionalidade básica do mecanismo GNSS. O autotendimento deve ser capaz de detectar problemas básicos no mecanismo (hardware defeituoso, conexões incorretas no hardware GNSS sem a necessidade de nenhum sinal externo injetado. O objetivo dessa validação é fazer esse teste barato e usá-lo como um portão na linha de produção, antes que o dispositivo passe por testes mais exaustivos e caros. Neste teste, o mecanismo e o driver GNSS devem fazer a auto-validação para conexões de pino e retornar um código de status indicando que tudo está ok ou que ocorreu uma falha. O código de erro para falhas deve indicar a falha detectada. Os códigos de erro são definidos pelo IHV.

Considerações de E/S

Como a funcionalidade do GNSS não é mapeada para solicitações tradicionais de leitura e gravação de arquivos para drivers de dispositivo, as funções ReadFile e WriteFile não serão usadas para as APIs de driver GNSS. Todas as funcionalidades de GNSS serão implementadas usando solicitações de controle de E/S de dispositivo específicas do GNSS (DeviceIoControl), também conhecidas como IOCTLs.

Todos os IOCTLs usarão METHOD_BUFFERED como o mecanismo de transferência de dados para dados de entrada e saída. Como o tamanho dos dados relacionados ao GNSS é relativamente pequeno, a cópia extra do buffer não deve afetar o desempenho do sistema.

O driver GNSS será aberto usando a opção FILE_FLAG_OVERLAPPED na função CreateFile . Portanto, todos os IOCTLs são implicitamente assíncronos. No entanto, embora a maioria dos IOCTLs GNSS sejam semanticamente assíncronos (por exemplo, um IOCTL dispara uma atividade dentro do driver e os resultados são esperados de volta de forma assíncrona), alguns IOCTLs são semanticamente síncronos no sentido de que não há nenhuma ação ou atividade assíncrona lógica envolvida com tais IOCTLs. O comportamento síncrono dessas poucas IOCTLs será alcançado bloqueando o thread do adaptador GNSS depois de emitir a chamada DeviceIoControl até que a operação de E/S seja concluída. Portanto, é responsabilidade do driver GNSS sempre concluir o IRP como parte do processamento de todos os IOCTLs. Espera-se que o adaptador GNSS cumpra o contrato de uma chamada síncrona e, em caso de erros, pode ou não repetir esses comandos. O driver IHV precisa ter certeza de que incorporou todas as lógicas necessárias do lado do driver antes de retornar um erro.

Para operações de solicitação e resposta, o adaptador GNSS sempre manterá uma operação de E/S pendente disponível para que, quando o driver GNSS tiver dados para enviar como resposta a uma operação invocada anteriormente, a resposta possa ser enviada por meio do IRP pendente.

Sessão de tiro único

Uma solicitação de ajuste inicial para uma correção única no driver inclui valores de precisão e tempo de resposta. O mecanismo GNSS pode usar esses valores para entender a intenção da solicitação do aplicativo e tomar decisões inteligentes. Depois que uma solicitação é recebida pelo driver, ela deve começar a retornar as correções intermediárias geradas pelo mecanismo. Correções intermediárias são correções geradas pelo mecanismo durante a computação de uma correção que atende aos requisitos de precisão ou é final. A frequência dessas correções intermediárias não é imposta e é um detalhe de implementação do mecanismo. O adaptador GNSS espera que as correções venham a cada poucos segundos e elas devem ser diferentes da última correção intermediária.

Depois que o mecanismo GNSS determinar que ele não pode obter uma correção melhor nas condições de sinal atuais, ele deve retornar uma correção final e deve parar de fazer mais cálculos. A correção final atende ao requisito de precisão ou indica que o mecanismo não pode melhorar a precisão fornecida nas condições atuais.

O adaptador GNSS emite uma correção de parada para uma única sessão de captura em um dos dois casos:

• Ele recebe uma correção final do driver.

• O tempo de resposta da solicitação foi atingido. Aqui, a última correção intermediária será enviada ao aplicativo.

A figura a seguir ilustra duas sessões de tiro único:

Sessão 1: O driver recebeu parâmetros de Precisão e Tempo de Resposta. Após o comando iniciar correção, o driver começou a enviar correções intermediárias. Depois de um tempo, ele determinou que não poderia retornar uma correção mais precisa, portanto, indicou a última correção como final. Isso aconteceu antes do limite de tempo de resposta ser atingido. O adaptador enviou a correção final para o aplicativo e emitiu um comando stop fix.

Sessão 2: O mesmo que na Sessão 1 acima, mas nesse caso o mecanismo continuou buscando uma correção melhor para atender ao requisito de precisão e continuou enviando correções intermediárias no meio. Depois que o limite de tempo de resposta da sessão foi atingido, o adaptador emitiu um comando de parada que deve fechar esta sessão no driver. A última correção intermediária recebida foi enviada ao aplicativo.

Um aspecto de design importante a ser considerado ao implementar o suporte para disparo único é que, se as sessões de rastreamento baseadas em distância e sessões de rastreamento baseadas em tempo não tiverem suporte, o mecanismo GNSS continuará rastreando satélites por 3 a 5 segundos após receber um comando para encerrar o rastreamento. Isso ocorre porque o adaptador GNSS precisará implementar sessões de acompanhamento baseadas em distância simuladas e/ou sessões de acompanhamento baseadas em tempo usando sessões de correção de tiro único e, se o mecanismo GNSS parar de rastrear satélites imediatamente, a maioria dos dispositivos GNSS terá um atraso na aquisição, o que impossibilitará a implementação de uma sessão de acompanhamento simulada que atenda às necessidades de navegação, executar aplicativos de rastreamento ou mapeamento.

O adaptador GNSS pode iniciar solicitações para correções pontuais enquanto o sistema está em Espera Conectada, não apenas quando o sistema está ativo. Isso pode ocorrer para satisfazer a necessidade de Tarefas em Segundo Plano, serviços do sistema, controle de cercas geográficas no processador de aplicativos ou em outros casos. O driver GNSS deve ser capaz de passar essas solicitações de sessão para o dispositivo GNSS e atender à solicitação ou fornecer um erro ao adaptador GNSS.

O diagrama de sequência a seguir ilustra as ações de alto nível relacionadas à obtenção de uma correção GNSS autônoma. Isso não inclui nenhuma solicitação de dados de assistência.

A descrição da sequência é a seguinte:

1. O adaptador GNSS abre o driver GNSS usando a API CreateFile . O WDF/KMDF/UMDF executa os retornos de chamada opcionais necessários para o driver GNSS. O identificador de arquivo retornado é usado para todas as operações subsequentes.

2. O adaptador GNSS emite um IOCTL para comunicar as várias funcionalidades de plataforma ao driver. O driver GNSS conclui a operação de E/S.

3. O adaptador GNSS emite IOCTL para obter os recursos do dispositivo. O driver GNSS retorna os recursos do dispositivo e conclui a operação de E/S.

4. O adaptador GNSS emite IOCTLs para qualquer configuração ou comando específico do driver. O driver GNSS executa a ação necessária e conclui a operação de E/S.

5. O adaptador GNSS emite um IOCTL_GNSS_START_FIXSESSION, juntamente com os parâmetros que especificam o tipo e outros aspectos da correção. Ao receber esse IOCTL, o driver GNSS interage com o dispositivo subjacente para começar a receber correções e, posteriormente, conclui a operação de E/S.

6. O adaptador GNSS emite um IOCTL_GNSS_GET_FIXDATA e aguarda a conclusão da E/S. Sempre que o driver GNSS tem uma correção intermediária disponível, ele retorna os dados concluindo a operação de E/S.

7. A etapa 6 é repetida até que o driver GNSS indique que não são esperadas mais correções (final da correção recebida).

8. O adaptador GNSS emite IOCTL_GNSS_STOP_FIXSESSION. O driver GNSS faz a operação de limpeza necessária associada à solicitação de correção original.

9. O adaptador GNSS fecha o identificador do arquivo de driver utilizando a API CloseHandle.

Os IOCTLs GNSS e as estruturas de dados associadas são descritas detalhadamente na referência do driver GNSS.

Sessão de acompanhamento baseada em distância

Sessões de acompanhamento baseadas em distância são usadas com frequência por aplicativos de usuário final, como historicamente, era o único tipo de sessão disponível nas APIs do .NET. Um valor de distância de 0 indica que o mecanismo GNSS deve fornecer correções na taxa mais alta possível.

O adaptador GNSS iniciará sessões de acompanhamento de distância com o driver GNSS, somente se o último indicar que ele tem a funcionalidade SupportDistanceTracking.

Uma solicitação de correção de início para o driver para uma sessão de acompanhamento de distância incluirá a precisão horizontal desejada e o limite de movimento, que é a distância haversine em metros que o sistema deve cobrir antes que o driver GNSS forneça uma atualização de posição. O mecanismo GNSS pode usar esses valores para entender a intenção da solicitação do aplicativo e tomar decisões inteligentes, como adaptar a frequência na qual verificar a localização.

Depois que uma solicitação de correção inicial é recebida pelo driver, ela deve começar a retornar as correções intermediárias geradas pelo mecanismo, até obter uma correção final. Essa será considerada a primeira posição da sessão. Depois disso, o mecanismo GNSS deve começar a fornecer correções sempre que detectar que a distância haversine foi aproximadamente percorrida.

Se o mecanismo GNSS determinar que não pode mais rastrear a localização do dispositivo (por exemplo, se os satélites não estiverem visíveis por mais tempo), ele deverá retornar um erro ao adaptador GNSS para que a plataforma de localização possa voltar para outros mecanismos para fornecer atualizações de posição ao aplicativo de usuário final. O adaptador GNSS deve apresentar um erro no período de tempo a seguir:

[(Distância-restante-desde-a-última-posição-conhecida (m) / velocidade estimada (m/s)) – 5 segundos] ou 5 segundos, o que for maior.

Se o mecanismo GNSS forneceu um erro ao adaptador GNSS, mas o adaptador GNSS ainda não interrompeu a sessão de rastreamento, o mecanismo GNSS deve continuar a verificar, de forma otimizada para energia, se ele puder retomar o local de rastreamento. O IHV pode usar otimizações para fazer essa detecção com baixa potência. As técnicas comuns de otimização incluem:

• Retirada progressiva

• Aguardando sinais de baixo custo que são indicativos de movimentações de dispositivo para verificar novamente

• Verificações de energia baixa para sinal de satélite

Depois que o mecanismo GNSS for capaz de fornecer uma correção final novamente após uma condição de erro, ele deverá enviar essa posição para o adaptador GNSS como uma indicação de que o acompanhamento foi retomado com êxito.

O adaptador GNSS emite um comando de correção de modificação para uma sessão de acompanhamento baseada em distância se um ou mais aplicativos que solicitaram a sessão de acompanhamento cancelaram a solicitação ou se novos aplicativos estiverem solicitando uma sessão de acompanhamento baseada em distância. Nesse caso, o adaptador GNSS calcula os novos parâmetros de sessão agregados necessários para multiplexar as diferentes sessões ativas e atualiza o driver GNSS com esses parâmetros.

O adaptador GNSS emite um comando stop fix para uma sessão de acompanhamento baseada em distância se:

• A sessão de rastreamento foi entregue a outro mecanismo de posicionamento disponível no sistema.

• Os aplicativos que solicitaram a sessão de acompanhamento cancelaram a solicitação.

A figura a seguir ilustra duas sessões de acompanhamento baseadas em distância:

Sessão 1: O driver GNSS recebeu parâmetros de precisão e limite de movimento ao iniciar a sessão de rastreamento. Após o comando de correção inicial, o driver começa a enviar correções intermediárias até obter uma correção final ou uma correção que atenda ao requisito de precisão no qual essa correção é fornecida ao adaptador GNSS e o mecanismo GNSS iniciará o processo de acompanhamento de distância. Enquanto a sessão está ativa, o adaptador GNSS envia uma solicitação para modificar os parâmetros de sessão às vezes T1 e T2. Após cada modificação dos parâmetros, o driver GNSS enviará uma atualização de correção para o adaptador GNSS e retomará a sessão de acompanhamento de distância com os novos parâmetros, até que o adaptador GNSS envie um comando de correção de parada.

Sessão 2: O processo de iniciação da sessão é semelhante à Sessão 1 acima, mas em um determinado ponto o mecanismo GNSS não consegue acompanhar a posição. Depois de um tempo que depende da distância e da velocidade estimada de movimento, o driver GNSS envia um erro. O mecanismo GNSS continua operando em baixa potência quando pode se recuperar e, quando isso acontece, indica ao adaptador GNSS enviando uma nova correção. A sessão é atualizada com novas correções conforme necessário, até que o adaptador GNSS envie um comando para parar a correção.

O adaptador GNSS pode manter-se ativo ou até mesmo iniciar sessões de acompanhamento baseadas em distância enquanto o sistema estiver em espera conectado, não apenas quando o sistema estiver ativo. Isso pode acontecer para satisfazer a necessidade de tarefas em segundo plano, serviços do sistema, rastreamento de geofences no processador de aplicações ou outros casos. O driver GNSS deve ser capaz de passar essas solicitações de sessão para o dispositivo GNSS e atender à solicitação ou fornecer um erro ao adaptador GNSS.

Sessão de rastreamento baseada em tempo

As sessões de acompanhamento baseadas em tempo podem ser usadas por aplicativos que exigem uma atualização de posição frequente e regular para atualizar a interface do usuário (por exemplo, mapas, aplicativos de navegação e assim por diante).

O adaptador GNSS iniciará sessões de acompanhamento baseadas em tempo com o driver GNSS, somente se o último indicar que ele tem a capacidade SupportContinuousTracking.

Uma solicitação de correção inicial para o driver para uma sessão de acompanhamento baseada em tempo incluirá a precisão horizontal desejada e o intervalo de tempo preferencial no qual o driver GNSS deve fornecer uma atualização de posição. O mecanismo GNSS pode usar esses valores para entender a intenção da solicitação do aplicativo e tomar decisões inteligentes, como adaptar a frequência na qual verificar a localização, começar a adquirir satélites alguns segundos antes do intervalo para fornecer uma atualização de posição em tempo hábil e assim por diante.

Depois que uma solicitação de correção inicial é recebida pelo driver, ela deve começar a retornar as correções intermediárias geradas pelo mecanismo, até obter uma correção final. Essa será considerada a primeira posição da sessão. Depois disso, o mecanismo GNSS começará a fornecer correções no intervalo exigido pelos parâmetros de sessão. Se o mecanismo GNSS não puder fornecer posições na frequência exigida pelo aplicativo, ele deverá fornecer correções na taxa máxima que puder.

Se o mecanismo GNSS determinar que não pode mais rastrear a localização do dispositivo (por exemplo, se os satélites não estiverem mais visíveis), ele deverá retornar um erro ao adaptador GNSS para que a plataforma de localização possa voltar para outros mecanismos para fornecer atualizações de posição ao aplicativo do usuário final.

Se o mecanismo GNSS forneceu um erro ao adaptador GNSS, mas o adaptador GNSS ainda não interrompeu a sessão de rastreamento, o mecanismo GNSS deve continuar a verificar, de forma otimizada para energia, se ele puder retomar o local de rastreamento.

O IHV pode usar otimizações para fazer essa detecção com baixa potência, conforme explicado na seção anterior. Depois que o mecanismo GNSS for capaz de fornecer uma correção final novamente após uma condição de erro, ele deverá enviar essa posição para o adaptador GNSS como uma indicação de que o acompanhamento foi retomado com êxito.

O adaptador GNSS emite um comando de correção de modificação para uma sessão de acompanhamento baseada em tempo se um ou mais aplicativos que solicitaram a sessão de acompanhamento cancelaram a solicitação ou se novos aplicativos estão solicitando uma sessão de acompanhamento baseada em tempo. Nesse caso, o adaptador GNSS calcula os novos parâmetros de sessão agregados necessários para multiplexar as diferentes sessões ativas e atualiza o driver GNSS com esses parâmetros.

O adaptador GNSS emite um comando stop fix para uma sessão de acompanhamento baseada em tempo se:

• A sessão de rastreamento foi entregue a outro mecanismo de posicionamento disponível no sistema.

• Os aplicativos que solicitaram a sessão de acompanhamento cancelaram a solicitação.

A figura a seguir ilustra duas sessões de acompanhamento baseadas em tempo.

Sessão 1: O driver GNSS recebeu precisão e um parâmetro de intervalo preferencial ao iniciar a sessão de rastreamento. Após o comando de início de correção, o driver deve começar a enviar correções intermediárias até obter uma correção final ou uma correção que atenda ao requisito de precisão; nesse ponto, essa correção é fornecida ao adaptador GNSS e o mecanismo GNSS iniciará o processo de rastreamento baseado em tempo. Enquanto a sessão está ativa, o adaptador GNSS envia uma solicitação para modificar os parâmetros de sessão às vezes T1 e T2. Após cada modificação dos parâmetros, o driver GNSS enviará uma atualização de correção para o adaptador GNSS e retomará a sessão de acompanhamento baseada em tempo, com os novos parâmetros, até que o adaptador GNSS envie um comando de correção de parada.

Sessão 2: O processo de iniciação da sessão é semelhante ao da Sessão 1 acima, mas em determinado ponto o mecanismo GNSS deixa de ser capaz de acompanhar a posição. Quando o mecanismo GNSS não consegue fornecer uma correção dentro de 15 segundos do intervalo exigido pelos parâmetros de sessão, o driver GNSS envia um erro. O mecanismo GNSS continua verificando a potência mais baixa quando pode se recuperar e, quando ele recupera, indica isso para o adaptador GNSS enviando uma nova correção. A sessão é atualizada com novas correções conforme necessário até que o adaptador GNSS envie um comando de parada de correção.

O adaptador GNSS pode manter-se ativo ou até mesmo iniciar sessões de acompanhamento baseadas em tempo enquanto o sistema está em espera conectado, não apenas quando o sistema está ativo. Isso pode acontecer para atender à necessidade de tarefas em segundo plano, serviços do sistema, rastreamento de cerca geográfica no processador de aplicações ou outros casos. O driver GNSS deve ser capaz de passar essas solicitações de sessão para o dispositivo GNSS e atender à solicitação ou fornecer um erro ao adaptador GNSS.

Manipular diferentes tipos de sessões FIX simultaneamente

Alguns mecanismos GNSS avançados podem ser capazes de lidar simultaneamente com uma sessão "Single Shot", com uma sessão de rastreamento Distance-Based e/ou uma sessão de rastreamento Time-Based. Idealmente, sessões independentes não devem influenciar umas às outras, mas isso pode não ser sempre possível, especialmente no caso de sessões simultâneas de Single Shot e Rastreamento Baseado em Tempo. Esta seção oferece algumas diretrizes para a implementação de IHV no caso de ser necessário fazer compromissos para gerenciar sessões simultâneas de diferentes tipos.

Os seguintes acrônimos são usados nesta seção:

• ß: Sessão de Tiro Único

• DBT: Sessão de rastreamento baseado em distância

• TBT: Sessão de monitoramento baseada em tempo

• TBF: Tempo entre correções

A tabela a seguir fornece alguns cenários para lidar com uma única captura e sessões de acompanhamento baseadas em tempo simultaneamente:

Se houver simultaneamente uma sessão de rastreamento baseada em tempo e de distância, o controle de precisão do mecanismo GNSS poderá ser ajustado para trabalhar com o menor dos dois. A tabela a seguir também fornece algumas diretrizes para o caso de valores diferentes para a precisão necessária quando há sessões simultâneas de tiro único e acompanhamento: