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

Fornece uma visão geral da arquitetura de driver do UMDF 2.0 do GNSS (Global Navigation Satellite System), considerações de 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 componentes de alto nível a seguir mostra como o driver UMDF 2.0 do Sistema de Navegação Global (GNSS) 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 GNSS.

• API 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 API GNSS é uma API privada apenas para componentes de plataforma de localização (por exemplo, o serviço de localização e aplicativos de teste de localização) e não está disponível para outros aplicativos de terceiros 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 testar e outros aplicativos fora do processo para instanciar um objeto COM singleton da classe COM do adaptador GNSS dentro do serviço de localização. Aplicativos fora do processo usam o ponteiro da interface COM para programar no driver GNSS.

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

  O mecanismo de posicionamento GNSS usa o objeto do adaptador GNSS interno para fornecer funcionalidade específica de localização para o serviço 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 de dispositivos GNSS subjacente por meio da interface IOCTL do GNSS pública definida neste documento. O dispositivo GNSS é tratado logicamente 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 DeviceIoControl do GNSS interfigurando com o hardware GNSS real. O driver GNSS também funciona como um mediador/integrador para as funções SUPL.

• Dispositivo/mecanismo GNSS: Esse é um componente conceitual que encapsula o SoC e as partes de hardware do dispositivo GNSS. Um IHV pode optar por implementar a maior parte da funcionalidade GNSS dentro desse componente, tornando a camada de driver GNSS muito fina (essencialmente um adaptador para interfiguração 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 de classe herdado Sensors v1.0 (consulte Escrevendo um driver de sensor de localização) ou integrados por meio da nova DDI GNSS descrita na referência do driver THR GNSS.

Portanto, os dispositivos Windows com um dispositivo GNSS que se integram ao modelo de extensão de classe Sensor v1.0 que existia no Windows 7, Windows 8 e Windows 8.1 devem continuar funcionando em 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 Windows 10:

• Um novo conjunto de testes para certificar os drivers após o novo modelo.

• Outro conjunto de testes para certificar os drivers 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 um melhor consumo de energia, dão suporte a mais constelações e dão 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 for detectado, este último será o selecionado.

• Se um usuário conectar um dispositivo GNSS externo quando um dispositivo GNSS interno estiver 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 com back, o comportamento será o mesmo que em Windows 8.1, em que ambos os dispositivos GNSS são usados simultaneamente e uma das respostas é comunicada até os aplicativos.

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

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

Se o dispositivo GNSS selecionado der suporte a cercas geográficas 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 funcionalidade

Para dar suporte à extensibilidade e à adaptabilidade da pilha GNSS em plataformas Windows, o adaptador GNSS e o driver GNSS estabelecem uma compreensão comum dos vários recursos bem definidos da pilha GNSS subjacente, bem como o suporte fornecido pela plataforma Windows. Os aspectos de funcionalidade são bem definidos pela Microsoft como parte dessa definição de interface GNSS e evoluirão à medida que mais inovação no espaço GNSS continuar e um conjunto diversificado de chipsets/drivers surgir no mercado. O adaptador GNSS consulta os vários recursos do driver/dispositivo GNSS subjacente no momento da inicialização ou conforme necessário 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 (Sistema de Satélite de Navegação Global)

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. Na forma mais básica, 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 captura única)

• 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 exigido por cada hardware GNSS e o driver GNSS é o tipo de sessão de correção de captura única. Nativo (implementado no SOC, no dispositivo GNSS e não no driver GNSS ou em um serviço em execução no processador do aplicativo), sessões de acompanhamento baseadas em tempo e sessões de acompanhamento baseadas em distância podem ter suporte opcionalmente. O main benefício para esses dois tipos de sessões de acompanhamento nativas são possíveis economias de energia, mantendo o AP (processador de aplicativos) inativo por mais tempo, fazendo mais do 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 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 define os requisitos específicos e a associação de preferências com a solicitação e intima o driver GNSS a iniciar o mecanismo para obter a correção emitindo 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 esperar por 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 de obtenção pendente.

   Se o tipo de sessão de correção for correção 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. Modificar 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 fizer multiplexação em seu nível.

4. Parar a sessão de correção: O adaptador GNSS emite uma sessão de correção de parada 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 definido nessa 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 à cerca geográfica nativamente (ou seja, ela implementa a cerca geográfica no chip GNSS em vez de no processador do aplicativo). Se o driver não der suporte nativo à cerca geográfica, o sinalizador não será definido. O HLOS já dá suporte a um mecanismo de acompanhamento de cerca geográfica baseado em AP (processador de aplicativos) abaixo do ideal; embora essa solução não seja tão otimizada quanto uma solução nativa pode ser, ela é bem testada e otimizada, portanto, não deve ser substituída por uma solução equivalente implementada na AP.

O acompanhamento de cerca geográfica pelo HLOS exige que o processador do aplicativo ative periodicamente para detectar violações de cerca geográfica, drenando assim a 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 nativa de acompanhamento de cerca geográfica. O suporte a geofencing nativo é benéfico somente quando o acompanhamento de cerca geográfica é totalmente desativado para o SoC e o processador do aplicativo é acordado apenas para processar eventos relacionados à cerca geográfica. 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 a localização do equilíbrio certo entre o consumo de energia e a experiência do usuário. Além disso, o número de cercas geográficas 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 ao descarregamento de cerca geográfica envolve os seguintes requisitos:

• O HLOS poderá 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.

• O ideal é que o hardware GNSS entenda o estado inicial de acompanhamento de cerca geográfica para cada cerca geográfica e use-o 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 maneira 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 poderá detectar as interrupções de rastreamento e o driver GNSS passará o alerta de erro status de rastreamento para o HLOS. O HLOS alterna para o acompanhamento de cerca geográfica baseado em AP padrão até que o hardware GNSS seja capaz de recuperar e rastrear 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 controladas 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 nenhum 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 houver 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 para a cerca geográfica mais próxima. Uma recomendação é enviar erros em [(Distance-to-close-fence-boundary(m) / estimated speed (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 para a cerca geográfica mais próxima. Uma recomendação é enviar um erro dentro de [Distance-to-close-fence-boundary(m) / 343(m/s)].

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

• O HLOS pode redefinir o acompanhamento de cerca geográfica excluindo todas as cercas geográficas criadas anteriormente por meio de um único comando.

• As cercas geográficas de origem móvel não são persistentes no hardware ou driver GNSS em reinicializações ou reinicializações de 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 cerca geográfica nativamente, no caso de falha de rastreamento de cercas geográficas, o adaptador GNSS fará o seguinte:

• Ele usará o acompanhamento baseado em AP depois que o driver GNSS retornar falha ao rastrear.

• Ele continuará enviando por push todas as atualizações (adicionar/excluir) nas cercas geográficas que estão sendo rastreadas no nível do sistema operacional para o driver também para que elas estejam em sincronia. Isso ajudará o mecanismo GNSS a saber quais cercas geográficas estão sendo controladas atualmente pelo sistema operacional e pode fazer uma determinação de rastreamento/não é possível acompanhar com base nos dados novos.

• Ele enviará por push as alterações de estado de cerca geográfica conforme determinado pelo rastreador baseado em AP assim que o driver GNSS enviar de volta SUCCESS em 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, efêmero, posição grosseira inicial), pop-up de consentimento do usuário para dar suporte ao posicionamento do plano de usuário iniciado pela rede e assim por diante.

• Os dados de assistência 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 pilha 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 de modo silencioso de rede e assim por diante.

  • O serviço de posicionamento da Microsoft pode obter periodicamente dados de assistência específicos de um IHV via 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 o 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 horário padrão antes de prosseguir para 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 realizada 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 de assistência/data do auxiliar, o adaptador GNSS busca os dados (ou executa a ação específica em nome do driver GNSS) e, posteriormente, injeta as informações necessárias no driver GNSS por meio de outra chamada DeviceIoControl .

A notificação do driver é tratada por meio de um modelo de evento comum. Por exemplo, para assistência GNSS, o adaptador GNSS usa 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 os problemas IOCTL_GNSS_INJECT_AGNSS para enviar os dados por push para o driver GNSS.

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

Registro em log do driver GNSS (Sistema de Satélite de Navegação Global)

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 usem o WPP para fins de registro em log em vez de ETW, embora ambos os mecanismos tenham suporte. Entre os motivos para o WPP ser recomendado está a disponibilidade de ferramentas que podem ajudar na depuração do driver.

O driver não deve registrar nenhuma informação, legível por humanos ou não, além dessa técnica de registro em log prescrita. 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 compatíveis com os serviços de registro em log de eventos. Por exemplo, o rastreamento de software WPP tem suporte interno 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 por IHV (o driver GNSS, o dispositivo/mecanismo GNSS) é necessária para dar suporte aos vários protocolos de posicionamento da operadora 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 para esses protocolos e a conformidade com os requisitos da operadora móvel são obrigatórios 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 específicos da implementação 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 residir no dispositivo/mecanismo 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 no 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 a essas interações entre os componentes de pilha GNSS 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 determinadas funcionalidades para a pilha de GNSS IHV. O driver GNSS é tratado como 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 GNSS IHV. As IOCLs 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 de 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 no UICC e/ou seja feita usando as informações de perfil de configuração OMA DO 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é Windows 10. A partir de Windows 10 todas as plataformas podem dar suporte à configuração de SUPL por meio do CSP (Provedor de Serviços de Configuração de SUPL), no que diz respeito à nova DDI GNSS. 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 em CSP supl.

   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 a configuração de OMA e efetuar push da configuração para o driver GNSS por meio do adaptador GNSS.

   Como alternativa, o IHV também pode gravar 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 trabalhar no modo autônomo. Este documento define as 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. Manipulação 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 gravar a interface do usuário para componentes da plataforma. Portanto, o adaptador GNSS manipula a interface do usuário para 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 as IOCTLs para o adaptador GNSS transmitirem a resposta do usuário a essa solicitação são definidas em IOCTLs do 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 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 mensagens push WAP de PUSH SIP que carregam solicitações DE NI SUPL.

• Gerenciador de Conexões capacidade 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, Gerenciador de Conexões oferece:

  • Um provedor de serviços de configuração que o OEM ou a operadora móvel podem 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 da rede 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 em Gerenciador de Conexões à finalidade SUPL.

• Solicitação para manter as conexões ativas enquanto uma conexão SUPL está 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 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 de Banda Larga Móvel (MBB): Em Windows 10, não há APIs disponíveis por meio do HLOS para recuperar medidas da rede 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, podem implementar a interface na DDI para permitir que o OEM inicie testes de fabricação e obtenha resultados.

A estrutura de localização será ignorada ao fazer o teste de fabricação, considerando que um grande foco do teste está na validação de hardware ou na validação 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 operadora: Esse teste é para validar o teste de conectividade/antena externa. Neste teste, o mecanismo GNSS deve procurar um sinal CW e fornecer as medidas SNRs (sinal para rações de ruído ou portador de racionamento de ruído) na resposta. O ideal é que os testes forneçam respostas de volta 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 exigir 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 auto-validação para conexões de pino e retornar um código 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 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.

Todas as 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 de buffer extra 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, todas as IOCTLs são implicitamente assíncronas. 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 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 desses poucos 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 todas as 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 no 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 a serem enviados como resposta a uma operação invocada anteriormente, a resposta possa ser enviada por meio do IRP pendente.

Sessão de captura única

Uma solicitação de correção inicial para uma única correção de captura 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 de aplicativo e tomar decisões inteligentes. Depois que uma solicitação é recebida pelo driver, ela deve começar a retornar quaisquer 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 sob as 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 obtém 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 captura única:

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 uma correção de parada que deve fechar essa 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 de captura única é que, se as sessões de rastreamento baseadas em distância e as sessões de acompanhamento baseadas em tempo não tiverem suporte, o mecanismo GNSS continuará rastreando satélites por 3 a 5 segundos depois de receber um comando de correção de parada. Isso ocorre porque o adaptador GNSS precisará implementar sessões de rastreamento baseadas em distância simuladas e/ou sessões de acompanhamento baseadas em tempo usando sessões de correção de captura única e, se o mecanismo GNSS parar de rastrear satélites imediatamente, a maioria dos dispositivos GNSS terá um atraso na aquisição, o que torna impossível implementar uma sessão de acompanhamento simulado que atenda às necessidades de navegação, executar aplicativos de rastreamento ou mapeamento.

O adaptador GNSS pode iniciar solicitações para correções de captura única enquanto o sistema está em Espera Conectada, não apenas quando o sistema está ativo. Isso pode atender à necessidade de Tarefas em Segundo Plano, serviços do sistema, acompanhamento de cercas geográficas no processador do aplicativo ou em outros casos. O driver GNSS poderá 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 faz 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 os vários recursos 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 de E/S. Sempre que o driver GNSS tiver uma correção intermediária disponível, ele retornará 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 (correção final recebida).

8. Os problemas do adaptador GNSS 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 de arquivo de driver usando a API CloseHandle .

As IOCTLs GNSS e as estruturas de dados associadas são descritas em detalhes na referência do driver GNSS.

Sessão de acompanhamento baseado em distância

As 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 tem a funcionalidade SupportDistanceTracking.

Uma solicitação de correção inicial 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 marcar para localização.

Depois que uma solicitação de correção de início é recebida pelo driver, ela deve começar a retornar quaisquer 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 coberta.

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

[(Distance-remaining-since-last-known-position (m) / estimated speed (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 marcar, de maneira otimizada para energia, se 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 para 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 baixa energia 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 modify fix 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 acompanhamento 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 rastreamento 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 de 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 stop fix.

Sessão 2: O processo de inicialização da sessão é semelhante à Sessão 1 acima, mas em um determinado ponto o mecanismo GNSS não consegue controlar a posição. Após um tempo que depende da distância e da velocidade estimada de movimento, o driver GNSS envia um erro. O mecanismo GNSS continua a marcar em menor potência 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 stop fix.

O adaptador GNSS pode manter-se ativo ou até mesmo iniciar sessões de acompanhamento baseadas em distância enquanto o sistema está em espera conectado, não apenas quando o sistema está ativo. Isso pode atender à necessidade de tarefas em segundo plano, serviços do sistema, acompanhamento de cercas geográficas no processador do aplicativo 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.

Sessão de acompanhamento 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 posterior indicar que tem a funcionalidade 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 em que marcar para 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 de início é recebida pelo driver, ela deve começar a retornar quaisquer 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 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 possível.

Se o mecanismo GNSS determinar que ele não pode mais rastrear o local do dispositivo (por exemplo, se os satélites não estiverem mais visíveis), ele deverá retornar um erro para o adaptador GNSS para que a plataforma de localização possa voltar para outros mecanismos para fornecer atualizações de posição para o 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 marcar, de maneira otimizada para energia, se puder retomar o local de rastreamento.

O IHV pode usar otimizações para fazer essa detecção com pouca 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 modify fix 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 estiverem 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 acompanhamento 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 correção inicial, 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 no qual essa correção é fornecida ao adaptador GNSS e o mecanismo GNSS iniciará o processo de acompanhamento 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 de 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 stop fix.

Sessão 2: O processo de inicialização da sessão é semelhante ao da Sessão 1 acima, mas em um 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 a marcar em menor potência 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 stop fix.

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 atender à necessidade de tarefas em segundo plano, serviços do sistema, acompanhamento de cerca geográfica no processador de aplicativos 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ão de correção simultaneamente

Alguns mecanismos GNSS avançados podem ser capazes de lidar simultaneamente com uma sessão single shot, com um Distance-Based e/ou uma sessão de acompanhamento de Time-Based. As sessões idealmente independentes não devem influenciar umas às outras, mas isso pode nem sempre ser possível, especialmente no caso de sessões simultâneas de Tiro Único e Acompanhamento Baseado em Tempo. Esta seção fornece algumas diretrizes para a implementação de IHV para o caso de comprometimentos precisarem ser feitos para lidar com sessões simultâneas de diferentes tipos.

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

• SS: Sessão de tiro único

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

• TBT: sessão de acompanhamento baseado em tempo

• TBF: Tempo entre correções

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

Caixa	SS ativo?	TBT ativo?	Detalhes da ocorrência	Intervalo aceitável de correções	Comentários
1	X	X	Sessão SS em andamento no momento da sessão periódica do TBT iniciada com tempo limite >restante = intervalo	O mesmo que o intervalo TBT	Comportamento da sessão SS: Correções intermediárias e finais são enviadas até o tempo limite. Sessão fechada imediatamente após a parada ser recebida. Comportamento da sessão TBT: As correções intermediárias e finais são enviadas. Correções recebidas aproximadamente de acordo com o intervalo. Sessão fechada imediatamente após a parada ser recebida.
2	X	X	Sessão SS em andamento no momento da sessão periódica do TBT iniciada com o intervalo de tempo limite < restante	O intervalo permanece o mesmo que o tempo limite do SS, até que a sessão do SS seja atendida. Em seguida, o intervalo pode ser atualizado para ser o mesmo que o intervalo TBT.	Comportamento da sessão SS: Correções intermediárias e finais são enviadas até o tempo limite. Sessão fechada imediatamente após a parada ser recebida. Comportamento da sessão TBT: Correções intermediárias e finais são enviadas Correções recebidas aproximadamente de acordo com o intervalo, mas podem ser mais frequentes enquanto a sessão SS está sendo atendida. Sessão fechada imediatamente após a parada ser recebida.
3	X	X	Sessão SS iniciada enquanto há uma sessão periódica TBT em andamento iniciada com tempo limite >= intervalo	O mesmo que o intervalo TBT	Comportamento da sessão SS: Correções intermediárias e finais são enviadas até o tempo limite. Sessão fechada imediatamente após a parada ser recebida. Comportamento da sessão TBT: Correções intermediárias e finais são enviadas Correções recebidas aproximadamente de acordo com o intervalo. Sessão fechada imediatamente após a parada ser recebida.
4	X	X	Sessão SS iniciada enquanto há uma sessão periódica de TBT em andamento iniciada com o intervalo de tempo limite <	O intervalo muda para ser o mesmo que o tempo limite do SS até que a sessão do SS seja atendida. Em seguida, o intervalo pode ser atualizado para ser o mesmo que o intervalo TBT.	Comportamento da sessão SS: Correções intermediárias e finais são enviadas até o tempo limite. Sessão fechada imediatamente após a parada ser recebida. Comportamento da sessão TBT: As correções intermediárias e finais são enviadas. Correções recebidas aproximadamente de acordo com o intervalo, mas podem ser mais frequentes enquanto a sessão SS está sendo atendida. Sessão fechada imediatamente após a parada ser recebida.
5		X	Sessão periódica TBT iniciada com intervalo modificado	A sessão com modem é atualizada para o novo intervalo para ser igual ao intervalo TBT. Se necessário, a sessão de modem será reiniciada.	Comportamento da sessão SS: Não aplicável Comportamento da sessão TBT: As correções intermediárias e finais são enviadas. Correções recebidas aproximadamente de acordo com o intervalo. Sessão fechada imediatamente após a parada ser recebida.
6	X	X	Sessão SS em andamento no momento em que uma sessão periódica TBT em andamento recebe uma alteração de intervalo, com tempo limite >restante = intervalo	O mesmo que o intervalo TBT	Comportamento da sessão SS: Correções intermediárias e finais são enviadas até o tempo limite. Sessão fechada imediatamente após a parada ser recebida. Comportamento da sessão TBT: Correções intermediárias e finais são enviadas Correções recebidas aproximadamente de acordo com o intervalo. Sessão fechada imediatamente após a parada ser recebida.
7	X	X	Sessão SS em andamento no momento em que uma sessão periódica TBT em andamento recebe uma alteração de intervalo, com intervalo de tempo limite < restante	O intervalo muda para ser o mesmo que o tempo limite restante do SS, até que a sessão SS seja atendida. Em seguida, o intervalo pode ser atualizado para ser o mesmo que o intervalo TBT.	Comportamento da sessão SS: Correções intermediárias e finais são enviadas até o tempo limite. Sessão fechada imediatamente após a parada ser recebida./li> Comportamento da sessão TBT: Correções intermediárias e finais são enviadas Correções recebidas aproximadamente de acordo com o intervalo, mas podem ser mais frequentes enquanto a sessão SS está sendo atendida. Sessão fechada imediatamente após a parada ser recebida.

Se houver simultaneamente uma sessão de acompanhamento baseada em tempo e distância, o acompanhamento de precisão do mecanismo GNSS poderá ser definido para funcionar 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 captura única e acompanhamento:

Caixa	Precisão do SS	Precisão de DBT ou TBT	Precisão geral do mecanismo GNSS	Comentários
1	Médio/Baixo –> Alto	Não aplicável	Médio/Baixo –> Alto	Comportamento da sessão SS: A sessão com o dispositivo GNSS é atualizada ou reiniciada para obter o resultado de alta precisão. As correções intermediárias são fornecidas ao HLOS conforme elas estão disponíveis.
2	Alto –> Médio/Baixo	Não aplicável	Alto –> Médio/Baixo	Comportamento da sessão SS: A sessão com o dispositivo GNSS é atualizada ou reiniciada para obter o resultado de precisão média/baixa. Se uma correção atender aos requisitos já estiver disponível, ela será retornada como uma correção final. Caso contrário, as correções intermediárias são fornecidas ao HLOS conforme elas estão disponíveis.
3	Médio/Baixo –> Alto	Alto	Alto	Comportamento da sessão SS: Considerando que já existe uma sessão de alta precisão para a sessão DBT ou TBT, a sessão SS apenas fornece correções adicionais intermediárias para o HLOS até que a precisão final desejada seja obtida ou uma correção final seja obtida.
4	Alto –> Médio/Baixo	Alto	Alto	Comportamento da sessão SS: Considerando que já existe uma sessão de alta precisão para a sessão DBT ou TBT, a sessão SS apenas fornece correções adicionais intermediárias para o HLOS até que a precisão final desejada seja obtida ou uma correção final seja obtida.
5	Médio/Baixo –> Alto	Médio/Baixo	Médio/Baixo –> Alto e, em seguida, de volta para Médio/Baixo após a conclusão da sessão SS	Comportamento da sessão SS: A sessão com o dispositivo GNSS é atualizada ou reiniciada para obter um resultado de alta precisão. Correções intermediárias são fornecidas ao HLOS conforme elas estão disponíveis. Comportamento da sessão DBT ou TBT: Não há problema para esta sessão receber temporariamente resultados de alta precisão. No entanto, depois que a sessão SS for atendida, a precisão dessa sessão deverá retornar para Média/Baixa.
6	Alto –> Médio/Baixo	Médio/Baixo	Alto –> Médio/Baixo	Comportamento da sessão SS: A sessão com o dispositivo GNSS é atualizada ou reiniciada para obter o resultado de precisão média/baixa. Se uma correção atender aos requisitos já estiver disponível, isso será retornado como uma correção final. Caso contrário, correções intermediárias são fornecidas ao HLOS conforme elas estão disponíveis.
7	Não aplicável	Médio/Baixo -> Alto	Médio/Baixo -> Alto	b>Comportamento da sessão DBT ou TBT:** A sessão com o dispositivo GNSS é atualizada ou reiniciada para obter resultados de alta precisão. Correções intermediárias são fornecidas ao HLOS conforme elas estão disponíveis.
8	Não aplicável	Alto –> Médio/Baixo	Alto –> Médio/Baixo	Comportamento da sessão DBT ou TBT: A sessão com o dispositivo GNSS é atualizada ou reiniciada para obter o resultado de precisão média/baixa. Se uma correção atender aos requisitos já estiver disponível, isso será retornado como uma correção final. Caso contrário, correções intermediárias são fornecidas ao HLOS conforme elas estão disponíveis.
9	Alto	Médio/Baixo -> Alto	Alto	Comportamento da sessão DBT ou TBT: A sessão já estava recebendo correções de alta precisão ou correções intermediárias, portanto, nenhuma alteração.
10	Alto	Alto –> Médio/Baixo	Alta e, em seguida, muda para Médio/Baixo após a conclusão da sessão do SS	Comportamento da sessão DBT ou TBT: A sessão pode continuar obtendo correções de alta precisão ou correções intermediárias até que a sessão do SS seja concluída. Em seguida, ele será alterado para correções de precisão média/baixa.
11	Médio/Baixo<	Médio/Baixo -> Alto	Médio/Baixo -> Alto	Comportamento da sessão DBT ou TBT: A sessão com o dispositivo GNSS é atualizada ou reiniciada para obter resultados de alta precisão. Correções intermediárias são fornecidas ao HLOS conforme elas estão disponíveis.
12	Médio/Baixo	Alto –> Médio/Baixo	Alto –> Médio/Baixo	Comportamento da sessão DBT ou TBT: A sessão com o dispositivo GNSS é atualizada ou reiniciada para obter o resultado de precisão média/baixa. Se uma correção atender aos requisitos já estiver disponível, isso será retornado como uma correção final. Caso contrário, correções intermediárias são fornecidas ao HLOS conforme elas estão disponíveis.