GNSS-Treiberarchitektur (Global Navigation Satellite System)

Artikel
03/22/2023

Bietet eine Übersicht über die UMDF 2.0-Treiberarchitektur des globalen Navigationssatellitensystems (GNSS), E/A-Überlegungen und erläutert verschiedene Arten von Nachverfolgungs- und Korrektursitzungen.

Übersicht über die Architektur

Das folgende allgemeine Komponentenblockdiagramm zeigt die Integration des UMDF 2.0-Treibers (Global Navigation Satellite System, GNSS) in die Windows 10-Plattform.

Diagramm der GNSS-Architektur des Benutzermodus.

Die Komponenten im Diagramm werden hier beschrieben:

LBS-Anwendung: Eine Benutzeranwendung, die die Standortfunktionalität der Windows 10-Plattform verwendet
Testanwendung: Eine Anwendung zum Testen der GNSS-Funktionalität.
GNSS-API: Die IGnssAdapter COM-Schnittstelle (Component Object Model), die die Funktionalität des GNSS-Geräts den internen Komponenten des Standortdiensts sowie zum Testen von Anwendungen verfügbar macht. Die genaue Form dieser API liegt außerhalb des Geltungsbereichs dieses Dokuments. Die Windows-Komponenten verwenden das GNSS-Gerät, indem sie mit der COM-Schnittstelle IGnssAdapter programmieren. Der GNSS-API-Satz ist eine private API für nur Standortplattformkomponenten (z. B. Standortdienst und Standorttestanwendungen) und steht nicht für andere Erstanbieter- oder Drittanbieteranwendungen zur Verfügung.
GNSS-Adapter: Dies ist ein Singleton-COM-Objekt, das die IGNSSAdapter-COM-Schnittstelle implementiert. Testanwendungen und interne Komponenten des Standortdiensts instanziieren dieses Objekt und verwenden das GNSS-Gerät über die IGNSSAdapter-Schnittstelle . Die Komponente der GNSS-Positionierungs-Engine des Standortdiensts implementiert die COM-Klasse, die die IGNSSAdapter-Schnittstelle verfügbar macht. Der Standortdienst macht einen Factorymechanismus für Tests und andere Out-of-Process-Anwendungen zum Instanziieren eines Singleton-COM-Objekts der COM-Klasse des GNSS-Adapters innerhalb des Standortdiensts verfügbar. Out-of-Process-Anwendungen verwenden den COM-Schnittstellenzeiger, um mit dem GNSS-Treiber zu programmieren.

COM verarbeitet den Schnittstellenzeiger als Proxy auf die Out-of-Process-Anwendungen, sodass die Anwendungen den IGNSSAdapter-Schnittstellenzeiger als prozessinternes COM-Objekt behandeln, die Aufrufe jedoch tatsächlich vom Singleton-GNSS-Adapterobjekt innerhalb des Standortdiensts verarbeitet werden.

Die GNSS-Positionierungs-Engine verwendet das interne GNSS-Adapterobjekt, um dem Standortdienst standortspezifische Funktionen bereitzustellen. Der GNSS-Adapter öffnet mithilfe der CreateFile-API ein Dateihandle für den GNSS-Treiber, umschließt dann die nativen GNSS-APIs-Aufrufe in entsprechende DeviceIoControl-Aufrufe , verwaltet den Zustandscomputer mit dem GNSS-Treiberobjekt und behält den Zustand der verschiedenen eingehenden Anforderungen aus den oberen Ebenen bei. Diese Komponente interagiert direkt mit dem zugrunde liegenden GNSS-Gerätestapel über die öffentliche GNSS-IOCTL-Schnittstelle, die in diesem Dokument definiert ist. Das GNSS-Gerät wird logisch als exklusive Ressource behandelt, und daher steuert der Singleton-GNSS-Adapter den gesamten Zugriff auf das GNSS-Gerät.

Bestimmte Whitebox-Treibertestanwendungen können die IOCTL-Schnittstelle des GNSS-Treibers auch direkt in einer Nichtproduktionsumgebung verwenden, anstatt den GNSS-Adapter über die privaten GNSS-APIs zu verwenden. Diese Testanwendungen müssen jedoch einen eigenen Zustandscomputer und eine eigene Verarbeitung implementieren, um bestimmte Funktionen des GNSS-Adapters nachzuahmen.
GNSS-Treiber: Ein von IHV bereitgestellter Treiber, der mithilfe von UMDF 2.0 implementiert wird. Der GNSS-Treiber unterstützt die GNSS DeviceIoControl-APIs , indem er mit der tatsächlichen GNSS-Hardware interfaciert. Der GNSS-Treiber arbeitet auch als Mediator/Integrator für die SUPL-Funktionen.
GNSS-Gerät/-Engine: Dies ist eine konzeptionelle Komponente, die die SoC- und Hardwareteile des GNSS-Geräts kapselt. Ein IHV kann den Größten Teil der GNSS-Funktionalität innerhalb dieser Komponente implementieren, wodurch die GNSS-Treiberschicht sehr dünn wird (im Wesentlichen ein Adapter für die Verbindung mit dem GNSS-Gerät).

Die Standortplattform in Windows 10 unterstützt GNSS-Geräte, die über den Legacytreiber Sensors v1.0-Klasse integriert sind (siehe Schreiben eines Standortsensortreibers) oder über das neue GNSS DDI integriert werden, das in der Referenz zu GNSS-Treibern beschrieben wird.

Daher wird erwartet, dass Windows-Geräte mit einem GNSS-Gerät, das in das Sensor v1.0-Klassenerweiterungsmodell integriert ist, das in Windows 7, Windows 8 und Windows 8.1 vorhanden war, weiterhin in Windows 10 arbeiten, ohne dass Änderungen erforderlich sind. Es wird dringend empfohlen, diese Treiber (und alle neuen Treiber) in Windows Update zu veröffentlichen, um den Upgradeprozess für unsere Benutzer zu verbessern.

Es gibt auch zwei verschiedene Tests für GNSS-Geräte im Hardware Lab Kit (HLK), das mit Windows 10 ausgestellt wurde:

Eine neue Reihe von Tests, um Treiber nach dem neuen Modell zu zertifizieren.
Eine weitere Reihe von Tests, um die Treiber nach dem alten Modell zu zertifizieren. Dabei handelt es sich um dieselben Tests, die im WHCK in Windows 8.1 verfügbar waren.

Eine neue Gathererkomponente im HLK identifiziert, welche der beiden Tests in einem System ausgeführt werden muss, falls vorhanden.

Diagramm, das die Kommunikation zwischen GNSS 2.0-Treibern und Adaptern zeigt.

Im seltenen Fall von mehreren GNSS-Geräten, die in einem System erkannt werden, verwendet die Standortplattform nur ein Gerät, vor allem, um den Gesamtenergieverbrauch im System zu reduzieren. Folgende Annahmen wurden berücksichtigt:

Geräte, die den neuen DDI verwenden, sind wahrscheinlich neuer und daher wahrscheinlicher, dass sie einen besseren Stromverbrauch haben, mehr Konstellationen unterstützen und eine bessere Unterstützung unterstützen. Wenn also ein Gerät, das das alte Treibermodell verwendet, und ein Gerät mit dem neuen Treibermodell erkannt werden, wird letzteres ausgewählt.
Wenn ein Benutzer ein externes GNSS-Gerät ansteckt, wenn ein internes GNSS-Gerät vorhanden ist, möchte der Benutzer höchstwahrscheinlich dieses externe Gerät verwenden.

Das Verhalten der Standortplattform basiert auf diesen Annahmen wie folgt:

Fall von zwei parallel vorhandenen Legacytreibern: Um Rückkompatibilitätsprobleme zu vermeiden, ist das Verhalten das gleiche wie in Windows 8.1, bei dem beide GNSS-Geräte gleichzeitig verwendet werden und eine der Antworten im Stapel an Anwendungen übermittelt wird.
Fall eines Legacytreibers im Gerät und eines neuen Treibers, der extern angeschlossen ist: Das extern angeschlossene GNSS-Gerät wird verwendet.
Fall eines neuen Treibers im Gerät und eines neuen Treibers, der extern angeschlossen ist: Das extern angeschlossene GNSS-Gerät wird verwendet.

Wenn das ausgewählte GNSS-Gerät Geofencing oder andere ausgeladene Vorgänge unterstützt, erfolgt die Auslagerung, während dieses Gerät verwendet wird. Der GNSS-Adapter teilt die Funktionen oder Sitzungen nicht auf mehrere GNSS-Geräte auf.

Die Interaktion zwischen dem GNSS-Adapter und dem GNSS-Treiber fällt unter die folgenden Kategorien:

Austausch von Funktionsinformationen

Um die Erweiterbarkeit und Anpassungsfähigkeit des GNSS-Stapels auf Windows-Plattformen zu unterstützen, schaffen der GNSS-Adapter und der GNSS-Treiber ein gemeinsames Verständnis der verschiedenen genau definierten Funktionen des zugrunde liegenden GNSS-Stapels sowie der Unterstützung durch die Windows-Plattform. Die Funktionsaspekte werden von Microsoft im Rahmen dieser Definition der GNSS-Schnittstelle gut definiert und werden sich weiterentwickeln, wenn weitere Innovationen im GNSS-Bereich fortgesetzt werden und eine Vielzahl von Chipsätzen/Treibern auf dem Markt entstehen. Der GNSS-Adapter fragt die verschiedenen Funktionen des zugrunde liegenden GNSS-Treibers/Geräts zum Zeitpunkt der Initialisierung oder nach Bedarf ab und optimiert entsprechend die Interaktion mit dem GNSS-Treiber.

Der Austausch von Funktionsinformationen zwischen dem GNSS-Adapter und dem GNSS-Treiber erfolgt mithilfe der Steuercodes IOCTL_GNSS_SEND_PLATFORM_CAPABILITY und IOCTL_GNSS_GET_DEVICE_CAPABILITY.

Der GNSS-Adapter kann eine einmalige Konfiguration oder eine regelmäßige Neukonfiguration des GNSS-Treibers ausführen. Ebenso kann der GNSS-Adapter bestimmte GNSS-spezifische Befehle über den Treiber ausführen. Dies wird erreicht, indem ein Befehlsausführungsprotokoll zwischen dem Treiber und dem High Level Operating System (HLOS) definiert wird. Abhängig vom jeweiligen Befehlstyp wird die beabsichtigte Aktion möglicherweise sofort oder nach einem Systemneustart wirksam. Ähnlich wie informationen zur GNSS-Gerätefunktion werden auch die GNSS-Befehle von Microsoft im Rahmen dieser Definition der GNSS-Schnittstelle gut definiert und werden sich mit zukünftigen Innovationen und der Diversifizierung von GNSS-Geräten/-Treibern weiterentwickeln.

Die Ausführung und Konfiguration von Gerätebefehlen erfolgt mithilfe des Steuerungscodes IOCTL_GNSS_SEND_DRIVERCOMMAND.

Positionsinformationen

Dies ist die primäre Funktion des zugrunde liegenden GNSS-Geräts. In der einfachsten Form fordert der GNSS-Adapter die aktuelle Position des Geräts vom GNSS-Treiber an. Variationen der Positionsanforderung umfassen (sind aber nicht beschränkt auf) die folgenden Positionssitzungstypen:

Aktuelle Position des Geräts (Single Shot Fix)
Fortlaufender regelmäßiger Stream von Fixes (zeitbasierte Nachverfolgung)
Fortlaufender Stream von Fixes basierend auf dem Bewegungsschwellenwert (entfernungsbasierte Nachverfolgung)

Der einzige obligatorische Positionssitzungstyp, der von jeder GNSS-Hardware und jedem GNSS-Treiber benötigt wird, ist der Sitzungstyp single shot fix. Native (implementiert im SOC, im GNSS-Gerät und nicht im GNSS-Treiber oder in einem Dienst, der im Anwendungsprozessor ausgeführt wird), zeitbasierte Nachverfolgungssitzungen und entfernungsbasierte Nachverfolgungssitzungen können optional unterstützt werden. Der Standard Vorteil für diese beiden Arten von nativen Nachverfolgungssitzungen sind potenzielle Energieeinsparungen, da der Anwendungsprozessor (Application Processor, AP) länger ruhen lässt, indem mehr Verarbeitung im SOC ausgeführt wird und Änderungen nur bei Bedarf gemeldet werden. Die Unterstützung der nativen entfernungsbasierten Nachverfolgung ist effektiver als native zeitbasierte Nachverfolgungssitzungen, da dies zu höheren Energieeinsparungen führen kann und von Anwendungen im Allgemeinen verwendet wird.

Der Vorgang des Abrufens von Positionsinformationen vom GNSS-Treiber erfolgt über eine zustandsbehaftete, eindeutige Fixsitzung, die aus den folgenden Aktionen besteht:

Fixsitzung starten: Der GNSS-Adapter initiiert eine Startfixsitzung (als Ergebnis einer Anforderung von einer LBS-Anwendung). Der GNSS-Adapter legt die spezifischen Anforderungen und Einstellungen fest, die der Anforderung zugeordnet sind, und gibt den GNSS-Treiber an, um die Engine zu starten, um den Fix zu erhalten, indem er Steuercode IOCTL_GNSS_START_FIXSESSION ausgibt.
Abrufen der Geräteposition (Fixdaten): Sobald eine Fixsitzung gestartet wurde, gibt der GNSS-Adapter Steuerungscode aus, IOCTL_GNSS_GET_FIXDATA , um auf eine Korrektur vom Treiber zu warten. Wenn eine neue Positionsinformation über die Engine verfügbar ist, antwortet der GNSS-Treiber auf diese ausstehende Anforderung zum Abrufen von Korrekturen.

Wenn der Fixsitzungstyp LKG-Fix (statt aktueller Fix) ist, stammen die Positionsinformationen aus dem Cache des Treibers.

Der GNSS-Adapter stellt sicher, dass immer eine asynchrone E/A-Anforderung für den GNSS-Treiber verfügbar ist, um die Fixdaten zurückzugeben, sofern verfügbar. Wenn weitere Fixdaten erwartet werden, gibt der GNSS-Adapter je nach Art des Fixs eine weitere E/A-Anforderung aus (mit derselben IOCTL), und diese Sequenz wird fortgesetzt, bis keine weiteren Daten verfügbar sind oder die Fixsitzung beendet wird.
Ändern der Fixsitzung: Wenn der GNSS-Treiber das Multiplexing von Fixsitzungen desselben Typs nicht unterstützt, stellt der GNSS-Adapter möglicherweise eine IOCTL_GNSS_MODIFY_FIXSESSION für diesen Fixsitzungstyp aus, wenn er Multiplexing auf seiner Ebene ausführt.
Fixsitzung beenden: Der GNSS-Adapter gibt eine Stop Fix-Sitzung aus, wenn keine weiteren Positionsinformationen zu einer bestimmten Fixsitzung erforderlich oder erwartet werden.

Native Geofencing-Unterstützung

Das GNSS-DDI unterstützt Geofence-Auslagerungsszenarien mithilfe einer Reihe von IOCTLs, die in dieser Spezifikation definiert sind. Für den Treiber wird ein spezielles Funktionsflag definiert, um diese Unterstützung anzugeben. Dieses Flag darf nur festgelegt werden, wenn der GNSS-Stapel Geofencing nativ unterstützt (d. a. er implementiert Geofencing im GNSS-Chip und nicht im Anwendungsprozessor). Wenn der Treiber Geofence nicht nativ unterstützt, darf das Flag nicht festgelegt werden. Der HLOS unterstützt bereits eine suboptimale AP-basierte Geofence-Tracking-Engine. Diese Lösung ist zwar nicht so energieoptimiert wie eine native Lösung, ist aber gut getestet und optimiert, sodass sie nicht durch eine gleichwertige Lösung ersetzt werden sollte, die im AP implementiert ist.

Die Geofence-Nachverfolgung durch das HLOS erfordert, dass der Anwendungsprozessor regelmäßig aufwacht, um Geofenceverletzungen zu erkennen, wodurch die Energie entwässert wird, auch wenn Zäune nicht verletzt werden. Daher gilt diese Implementierung als suboptimal.

Das HLOS verwendet auch die AP-basierte Geofence-Nachverfolgung als Failovermechanismus, wenn der zugrunde liegende Treiber geofences aufgrund niedriger Signalbedingungen oder anderer vorübergehender Fehler nicht nachverfolgen kann, wenn Fehlerbenachrichtigungen von der nativen Geofence-Tracking-Lösung empfangen wurden. Die native Geofencing-Unterstützung ist nur dann von Vorteil, wenn die Geofencenachverfolgung vollständig in den SoC ausgelastet ist und der Anwendungsprozessor nur für die Verarbeitung geofencebezogener Ereignisse aktiviert wird. Wenn die Hardware keine native Geofencenachverfolgung unterstützt, darf der GNSS-Treiber nicht versuchen, sie auf der Treiberebene zu implementieren.

Die GNSS-Engine muss außerdem dokumentierte IHV-spezifische Optimierungsparameter verfügbar machen, um das richtige Gleichgewicht zwischen Energieverbrauch und Benutzerfreundlichkeit zu finden. Darüber hinaus sollte die Anzahl der unterstützten Geofences mehr als der MIN_GEOFENCES_REQUIRED Wert sein, der in der Headerdatei definiert ist. Beachten Sie, dass die MIN_GEOFENCES_REQUIRED pro Anwendung definiert ist, da eine Anwendung keine Kenntnis von der Anzahl von Geofences hat, die von anderen Anwendungen oder vom Mobilfunkanbieter verwendet werden.

Die Geofencing-Auslagerungsunterstützung umfasst die folgenden Anforderungen:

Der HLOS muss in der Lage sein, einen oder mehrere Geofences über den DDI zu erstellen, und der Treiber sendet sie an die Hardware, um sie zu verfolgen.
Der HLOS muss in der Lage sein, einen oder mehrere zuvor erstellte Geofences über den DDI zu löschen, und der Treiber sendet sie an die Hardware, um die Nachverfolgung zu beenden.
Im Idealfall sollte die GNSS-Hardware den anfänglichen Geofence-Tracking-Zustand für jeden Geofence verstehen und ihn verwenden, um nur Änderungen aus diesem Anfangszustand zu melden. Wenn die GNSS-Hardware diese Funktionalität nicht unterstützt, meldet sie den Anfangszustand jedes Mal an den HLOS, wenn ein Geofence erstellt wird.
Die GNSS-Hardware verfolgt die aktuelle Position des Geräts energieeffizient nach und aktiviert den AP, wenn das Gerät einen nachverfolgten Geofence eingegeben und/oder beendet hat. Der GNSS-Treiber übergibt die Geofencewarnungen an den HLOS.
Bei geringem Satellitensignal und anderen vorübergehenden Fehlerbedingungen kann die GNSS-Engine die vorhandenen Geofences möglicherweise nicht zuverlässig nachverfolgen. Die GNSS-Engine muss in der Lage sein, die Nachverfolgungsunterbrechungen zu erkennen, und der GNSS-Treiber übergibt die Nachverfolgung status Fehlerwarnung an den HLOS. Der HLOS wechselt zur standardmäßigen AP-basierten Geofence-Nachverfolgung, bis die GNSS-Hardware geofences wiederherstellen und nachverfolgen kann.
Die genauen Bedingungen, unter denen eine GNSS-Engine eine Benachrichtigung bereitstellen muss, um anzugeben, dass Geofences nicht nachverfolgt werden können, variieren, und die Implementierung ist IHV-spezifisch. Im Folgenden sind einige Richtlinien für die Implementierung aufgeführt:
- Wenn die GNSS-Engine mit hoher Zuverlässigkeit erkennen kann, dass sich der Benutzer nicht bewegt und keine Geofencegrenze in 25 Metern oder weniger vorhanden ist, muss die GNSS-Engine keinen Nachverfolgungsfehler senden.
- Wenn die GNSS-Engine mit hoher Zuverlässigkeit erkennen kann, dass sich der Benutzer nicht bewegt, aber eine Geofencegrenze in 25 Metern oder weniger vorhanden ist, muss die GNSS-Engine innerhalb einer Minute einen Nachverfolgungsfehler senden.
- Wenn die GNSS-Engine erkannt hat, dass sich der Benutzer bewegt und eine Geofences-Grenze innerhalb von 100 Metern oder weniger vorhanden ist, muss die GNSS-Engine innerhalb einer Minute oder weniger einen Nachverfolgungsfehler senden.
- Wenn die GNSS-Engine nicht feststellen kann, ob sich der Benutzer bewegt und eine Geofences-Grenze innerhalb von 100 Metern oder weniger vorhanden ist, muss die GNSS-Engine innerhalb einer Minute oder weniger einen Nachverfolgungsfehler senden.
- Wenn die GNSS-Engine erkannt hat, dass sich der Benutzer bewegt, muss die GNSS-Engine einen Nachverfolgungsfehler in einer Zeit senden, die proportional zur geschätzten Bewegungsgeschwindigkeit und dem Abstand zum nächstgelegenen Geofence ist. Eine Empfehlung besteht darin, einen Fehler innerhalb von [(Distance-to-closest-fence-boundary(m) / geschätzte Geschwindigkeit (m/s)) - 15s] zu senden. Die GNSS-Engine kann Indikatoren für die Bewegungserkennung verwenden, um den Zeitpunkt zu bestimmen, in dem der Nachverfolgungsfehler gesendet werden soll.
- Wenn die GNSS-Engine nicht feststellen kann, ob sich der Benutzer bewegt, muss die GNSS-Engine einen Nachverfolgungsfehler in einer Zeit senden, die proportional zur hohen Bewegungsgeschwindigkeit und der Entfernung zum nächstgelegenen Geofence ist. Eine Empfehlung besteht darin, einen Fehler innerhalb von [Distance-to-closest-fence-boundary(m) / 343(m/s)] zu senden.
Während des Zeitraums, in dem die GNSS-Engine geofence tracking status Fehler gemeldet hat, sollten keine Geofenceverletzungsereignisse an den HLOS gesendet werden.
Der HLOS kann die Geofence-Nachverfolgung zurücksetzen, indem alle zuvor erstellten Geofences über einen einzigen Befehl gelöscht werden.
Die mobilen Geofences werden bei Neustarts oder Treiberneustarts nicht in der GNSS-Hardware oder dem GNSS-Treiber beibehalten. Das HLOS verarbeitet die Persistenz im Auftrag der Endbenutzeranwendungen und erstellt/löscht nach Bedarf Geofences.

In Bezug auf die Interaktionen zwischen dem GNSS-Adapter und der GNSS-Engine, die die native Entladung von Geofencing unterstützt, führt der GNSS-Adapter im Falle eines Fehlers der Geofences-Nachverfolgung folgendes aus:

Es wird die AP-basierte Nachverfolgung verwendet, sobald der GNSS-Treiber einen Fehler bei der Nachverfolgung zurückgibt.
Alle Updates (Add/Delete) in den Geofences, die derzeit auf Betriebssystemebene nachverfolgt werden, werden weiterhin auf den Treiber übertragen, sodass sie synchronisiert sind. Dies hilft der GNSS-Engine, zu wissen, welche Geofences derzeit vom Betriebssystem nachverfolgt werden, und es kann die Ermittlung anhand der neuen Daten nachverfolgen/nicht nachverfolgen.
Die vom AP-basierten Tracker ermittelten Geofencestatusänderungen werden pushen, sobald der GNSS-Treiber SUCCESS in seiner Fähigkeit zum Nachverfolgen zurücksendet.

Treiberbenachrichtigungen für Unterstützungs- und Hilfsdaten

Von Zeit zu Zeit benötigt der GNSS-Treiber möglicherweise Unterstützungsdaten oder Hilfsaktionen vom GNSS-Adapter. Dies umfasst die verschiedenen Formen von AGNSS-Daten (Zeiteinschleusung, Kurzlebigkeit, anfängliche grobe Position), Benutzereinwilligungs-Popup für die Unterstützung der netzwerkinitiierte Positionierung der Benutzerebene usw.

GNSS-Unterstützungsdaten könnten vom GNSS-Treiber abgerufen werden, ohne den GNSS-Adapter zu verwenden. Dennoch wird empfohlen, die Unterstützungsdaten mithilfe des GNSS-Adapters und der Nutzung des Microsoft-Positionierungsdiensts aus mehreren Gründen zu erhalten:
- Der Microsoft-Standortstapel kümmert sich um das Einrichten der Datenverbindungen und die Einhaltung aller Roamingeinschränkungen, Dateneinstellungen, Integration des ruhenden Modus im Netzwerk usw.
- Der Microsoft-Positionierungsdienst kann regelmäßig Supportdaten abrufen, die für eine IHV über eine Server-zu-Server-Back-End-Verbindung spezifisch sind, und diese für alle Geräte bereitstellen, die benötigt werden, sodass der IHV die Notwendigkeit für die Bereitstellung eines Front-End-Unterstützungsdiensts auf der ganzen Welt ersparen muss, der Die Anforderungen an Verfügbarkeit, Skalierbarkeit und Reaktionsfähigkeit erfüllt.
Die Zustimmung der Benutzer zum Datenschutz für Posteingangsanwendungen ist eigentum des Betriebssystems. Daher ist jede Benutzeroberfläche zum Benachrichtigen des Benutzers über eine netzwerkinitiierte Standortanforderung oder eine beliebige Benutzeroberfläche, um die Zustimmung des Benutzers zur Beantwortung einer netzwerkinitiierte Standortanforderung anzufordern, im Besitz von Microsoft. Der GNSS-Treiber benachrichtigt den GNSS-Adapter, wenn eine netzwerkinitiierte Standortanforderung empfangen wird, und wartet bei Bedarf bis zur Standardzeit auf die Antwort des Benutzers, bevor er mit der Erfüllung der Anforderung fortfahren kann.

Da der GNSS-Treiber keine Anforderung an die obere Ebene selbst initiieren kann, kann diese Art von Vorgängen durch den GNSS-Adapter ausgeführt werden, der eine solche Anforderung proaktiv vom GNSS-Treiber sucht und dabei immer einen oder mehrere ausstehende IRPs behält, damit der GNSS-Treiber auf solche ausstehenden Anforderungen reagieren kann. Nach Erhalt der Anfrage zur Unterstützung/des Hilfsdatums ruft der GNSS-Adapter die Daten ab (oder führt die spezifische Aktion im Namen des GNSS-Treibers aus) und fügt anschließend die erforderlichen Informationen über einen anderen DeviceIoControl-Aufruf an den GNSS-Treiber ein.

Die Benachrichtigung vom Treiber wird über ein allgemeines Ereignismodell verarbeitet. Für die GNSS-Unterstützung verwendet der GNSS-Adapter beispielsweise Steuercode IOCTL_GNSS_LISTEN_AGNSS , um die AGNSS-Anforderung vom GNSS-Treiber zu empfangen. Anschließend ruft der GNSS-Adapter die AGNSS-Unterstützungsdaten ab und gibt IOCTL_GNSS_INJECT_AGNSS aus, um die Daten in den GNSS-Treiber zu übertragen.

Dieser Benachrichtigungsmechanismus wird auch zum Empfangen geofencebezogener Warnungsdaten und status Updates verwendet. Der Adapter verwendet Steuerungscode IOCTL_GNSS_LISTEN_GEOFENCE_ALERT zum Empfangen einzelner Geofencewarnungen und IOCTL_GNSS_LISTEN_GEOFENCES_TRACKINGSTATUS für den Empfang von Änderungen im gesamt status der Geofencenachverfolgung.

Zu Diagnosezwecken sollte der GNSS-Treiber Fehler und andere Diagnoseinformationen mithilfe des von Microsoft beschriebenen vorgeschriebenen Protokollierungsmechanismus (WPP) oder ETW protokollieren. Es wird empfohlen, dass Treiber WPP für Protokollierungszwecke anstelle von ETW verwenden, obwohl beide Mechanismen unterstützt werden. Zu den Gründen, warum WPP empfohlen wird, ist die Verfügbarkeit von Tools, die das Debuggen von Treibern unterstützen können.

Der Treiber darf keine Informationen protokollieren, die für Menschen lesbar oder anderweitig sind, außer durch diese vorgeschriebene Protokollierungstechnik. Weitere Informationen finden Sie unter WPP-Softwareablaufverfolgung.

Die Protokollierung von Nachrichten mit der WPP-Softwareablaufverfolgung ähnelt der Verwendung von Windows-Ereignisprotokollierungsdiensten. Der Treiber protokolliert eine Nachrichten-ID und unformatierte Binärdaten in einer Protokolldatei. Anschließend konvertiert ein Postprozessor die Informationen in der Protokolldatei in ein lesbares Formular. Die WPP-Softwareablaufverfolgung unterstützt jedoch Nachrichtenformate, die leistungsfähiger und flexibler sind als die von den Ereignisprotokollierungsdiensts unterstützten. Die WPP-Softwareablaufverfolgung bietet beispielsweise integrierte Unterstützung für IP-Adressen, GUIDs, System-IDs, Zeitstempel und andere nützliche Datentypen. Darüber hinaus können Benutzer benutzerdefinierte Datentypen hinzufügen, die für ihre Anwendung relevant sind.

Unterstützung des Mobilfunkanbieterprotokolls

Der von IHV bereitgestellte GNSS-Stapel (der GNSS-Treiber, das GNSS-Gerät/die GNSS-Engine) ist erforderlich, um die verschiedenen Positionsprotokolle des Mobilfunkbetreibers (SUPL, UPL, CP usw.) zu unterstützen. Wenn dies nicht der Fall ist, wird das Gerät die Akzeptanz von Mobilfunkanbietern nicht übergeben und es wird erheblich eingeschränkt, wo das Gerät kommerzialisiert werden kann.

Die Unterstützung für diese Protokolle und die Einhaltung der Anforderungen des Mobilfunkanbieters sind obligatorisch, um Geräte für bestimmte Mobilfunkanbieter zu versenden. Die Unterstützung für Mobilfunkanbieterprotokolle ist für die meisten Nicht-Telefonplattformen möglicherweise nicht unerlässlich, insbesondere dann, wenn die Plattform keine Unterstützung für mobiles Breitband (Mobile Broadband, MBB) enthält.

Alle Implementierungselemente werden im IHV-Stapel abstrahiert, und die Microsoft HLOS-Komponenten sind unabhängig von:

Die spezifischen Implementierungsdetails der Protokolle (z. B. wie die Protokolle funktionieren, die Interpretation der Protokollmeldungen usw.).
Die Form des Implementierungsstapels (z. B. kann sich die Implementierung innerhalb des GNSS-Geräts/der -Engine oder des GNSS-Treibers oder bei Bedarf in einem separaten HLOS-Dienst befinden).
Interaktion zwischen den verschiedenen Teilen innerhalb des IHV-eigenen GNSS-Stapels für die Implementierung der Protokolle. Wenn der GNSS-Treiber beispielsweise die Wi-Fi Scanergebnisse für die Reaktion auf eine bestimmte SUPL-Protokollnachricht benötigt, kann er dies tun, indem eine Benutzermoduserweiterung die Wi-Fi Scanergebnisse über einen privaten IOCTL-Aufruf in den Treiber einschleust oder diesen Teil des UMDF 2.0-Treibers macht oder diese Interaktion auf niedrigerer Ebene behandelt. Die Microsoft-GNSS-HLOS-Komponenten sind solche Interaktionen zwischen den IHV-GNSS-Stapelkomponenten nicht zu vergessen.

Zusammenfassend muss der IHV oder OEM einen SUPL-Client (und möglicherweise einen UPL-Client bereitstellen, wenn das System in China ausgeliefert werden soll) und ihn in/in den GNSS-Treiber integrieren. Alle Interaktionen der Standortplattform mit dem SUPL-Client erfolgen über den GNSS-DDI.

Um die Implementierung der Mobilfunkanbieterprotokolle zu erleichtern und die Last der Softwareentwicklung mithilfe plattformspezifischer Technologien zu verringern, stellt der GNSS-Adapter bestimmte Funktionen für den IHV-GNSS-Stapel bereit. Der GNSS-Treiber wird als Vermittler für den Empfang solcher Funktionen von den HLOS-Komponenten behandelt, z. B. interagiert der GNSS-Adapter nur mit dem GNSS-Treiber und nicht mit einem anderen Teil des IHV-GNSS-Stapels. Die IOCTLs des GNSS-Treibers definieren die Syntax und Semantik dieser Funktionalität zwischen dem GNSS-Treiber und dem GNSS-Adapter. Der GNSS-Treiber ist für das Routing an die spezifische IHV-Komponente verantwortlich, die das Mobilfunkanbieterprotokoll implementiert. Im Großen und Ganzen bietet der GNSS-Adapter die folgenden Funktionen für den GNSS-Treiber:

Konfiguration: Die Mobilfunkanbieter stellen das Gerät bereit und ändern die Konfiguration mithilfe des Konfigurationsmechanismus, der von den OMA-Protokollstandards vorgeschrieben ist. Der SUPL-Standard erfordert beispielsweise, dass die SUPL-Konfiguration basierend auf dem UICC und/oder mithilfe der SUPL-OMA-Konfigurationsprofilinformationen erfolgt, die über OMA-DM oder OMA-CP abgerufen wurden.

Bestimmte Funktionen, die im Telefon für Konfigurationszwecke verfügbar sind (OMA-DM und OMA CP), waren auf anderen Plattformen erst Windows 10 verfügbar. Ab Windows 10 können alle Plattformen die SUPL-Konfiguration über den SUPL-Konfigurationsdienstanbieter (SUPL Configuration Service Provider, CSP) unterstützen, sofern das neue GNSS DDI verwendet wird. Die Bereitstellung, die über den CSP eingefügt wird, kann vom Image selbst (über provxml oder multivariant) oder vom Mobilfunkanbieter über OMA-DM oder OMA-CP stammen. SUPL CSP ist in SUPL CSP definiert.

Windows 10 definiert eine proprietäre Technologie, die Geräteverwaltung mithilfe eines Konfigurationsdienstanbieters (Configuration Service Provider, CSP), zum Interpretieren und Extrahieren der Konfigurationsdaten. Microsoft bietet einen CSP zum Nutzen der OMA-Konfiguration und zum Pushen der Konfiguration an den GNSS-Treiber über den GNSS-Adapter.

Alternativ kann der IHV auch eine Komponente im Benutzermodus schreiben, um die Konfigurationsspezifikation des Mobilfunkanbieters mithilfe der telefonspezifischen Geräteverwaltungstechnologie (Device Management Technology, CSPs) zu nutzen. Dies ist jedoch eine zusätzliche Belastung für die IHV und wird nicht empfohlen.

Nur eine SUPL-Konfiguration wird in einem System unterstützt, einschließlich in Fällen von Dual-SIM-Geräten. Microsoft bietet die Funktionalität, SUPL basierend auf UICC und UICC-Änderungen neu zu konfigurieren. Darüber hinaus konfiguriert der HLOS im Fall des Geräteroamings den SUPL-Client neu, um im eigenständigen Modus zu arbeiten. In diesem Dokument werden die IOCTLs zum Pushen solcher Konfigurationsdaten für eine Vielzahl mobiler Betriebsprotokolle (SUPL 1.0 und 2.0, v2UPL usw.) definiert.
Behandlung der Zustimmung des Benutzers für NI-Anforderungen: Um die Datenschutzanforderungen zu erfüllen, benötigen bestimmte netzwerkinitiierte Positionierungsanforderungen die Zustimmung des Benutzers. IHVs dürfen keine Benutzeroberfläche für Plattformkomponenten schreiben. Daher verarbeitet der GNSS-Adapter die Benutzeroberfläche für die Benutzergenehmigung im Auftrag des GNSS-Treibers. Die Benachrichtigungs-IOCTLs für den GNSS-Treiber zum Anfordern eines Ui-Popups und die IOCTLs für den GNSS-Adapter, um die Benutzerantwort auf eine solche Anforderung zu übermitteln, sind in GNSS-Treiber-IOCTLs definiert.

Um einen voll funktionsfähigen SUPL-Client zu implementieren, muss der IHV-Stapel Schnittstellen oder allgemeine Funktionen nutzen, die in/über die Betriebssystemplattform verfügbar sind. Im Folgenden finden Sie die Liste der in Windows 10 verfügbaren Funktionen, die IHVs für die Implementierung ihres SUPL-Clients nutzen können:

Keine dieser Funktionen ist Teil der Standortplattform oder des GNSS-DDI, aber sie ist hier enthalten, um Dies zu klären und GNSS-Treiberentwicklern zu helfen, zu verstehen, was vom Betriebssystem zum Implementieren der SUPL-Funktionalität genutzt werden kann.

SUPL-Clientinteraktion mit einem GNSS-Treiber.

SMS-Router: Mit dem SMS-Router kann der SUPL-Client WAP-Push von SIP-Pushnachrichten abonnieren, die SUPL NI-Anforderungen enthalten.
Verbindungs-Manager Möglichkeit, zu konfigurieren, welche Verbindung für SUPL und APIs verwendet werden soll, um eine solche Verbindung anzufordern: Mobilfunkbetreiber müssen den SUPL-Datenverkehr möglicherweise in einer dedizierten Verbindung oder einfach über eine Verbindung verfügen, die sich von der Standard-Internetverbindung unterscheidet. Dazu bietet Verbindungs-Manager Folgendes:
- Ein Konfigurationsdienstanbieter, mit dem der OEM oder der Mobilfunkanbieter konfigurieren kann, welche Verbindung für die SUPL-Kommunikation verwendet werden soll.
- Eine API für den SUPL-Client, um die Verbindungsparameter der SUPL-Verbindung abzufragen.
- Eine API zum Herstellen der SUPL-Verbindung mit den parametern, die im vorherigen Schritt abgerufen wurden.
Mobilfunkverbindungskonfiguration: Um die Parameter verschiedener Mobilfunkverbindungen zu konfigurieren, z. B. die Parameter für eine SUPL-Verbindung, gibt es einen Konfigurationsdienstanbieter, den der OEM oder der Mobilfunkanbieter verwenden kann. Anschließend kann diese Verbindung in Verbindungs-Manager dem SUPL-Zweck zugeordnet werden.
Anforderung, die Verbindungen aktiv zu halten, während eine SUPL-Verbindung ausgeführt wird: Der SUPL-Client muss möglicherweise Verbindungen mit dem HSLP initiieren, während sich das System im verbundenen Standby befindet. Dies kann vorkommen, weil das GNSS-Gerät Unterstützungsinformationen erhalten muss, wenn es für die Verwendung der Microsoft-basierten Positionierung konfiguriert ist oder weil der Mobilfunkanbieter eine NI-Anforderung gesendet hat. In diesem Fall muss der SUPL-Client eine Verbindung mit dem HSLP initiieren und sicherstellen, dass die Verbindung aktiv ist, bis die SUPL-Sitzung abgeschlossen ist.
Interaktionen mit dem Modul Mobile Broadband (MBB): In Windows 10 sind keine APIs über das HLOS verfügbar, um Mobilfunkmessungen abzurufen, zu wissen, wann ein Notruf erfolgt ist usw. Jede Interaktion mit dem MBB muss über die direkte Integration mit dem MBB (über AT-Befehle oder eine andere proprietäre Methode) erfolgen.

Fertigungstests

OEMs müssen eine Möglichkeit haben, zur Herstellungszeit und auch an den Supportpunkten des Kunden zu überprüfen, ob die GNSS-Hardware und der GNSS-Stapel (der GNSS-Treiber und das GNSS-Gerät/die GNSS-Engine) ordnungsgemäß funktionieren. Der IHV kann proprietäre Mechanismen bereitstellen, um OEMs die Durchführung dieser Tests zu ermöglichen, oder optional die Schnittstelle im DDI implementieren, damit der OEM Fertigungstests initiieren und Ergebnisse erhalten kann.

Das Standortframework wird beim Ausführen der Fertigungstests umgangen, da ein großer Schwerpunkt der Tests auf der Hardwarevalidierung oder Treibervalidierung liegt. Im Allgemeinen befindet sich das Gerät in einem speziellen "sicheren Betriebssystemmodus", in dem der minimale Satz von Komponenten und Diensten geladen wird. In diesem Modus kann der OEM eine Reihe von Testanwendungen initiieren, die Testfälle auslösen. Aus Gründen der Effizienz und Geschwindigkeit während der Fertigung ist es dringend erwünscht, Parallelitätsunterstützung für Tests in verschiedenen Komponenten zu haben.

Die Schnittstelle für Fertigungstests umfasst zwei Arten von Tests:

Carrier Wave Test: Bei diesem Test wird der externe Konnektivitäts-/Antennentest überprüft. Bei diesem Test muss die GNSS-Engine nach einem CW-Signal suchen und die SNRs-Messungen (Signal to Noise Rations oder Carrier to Noise Ration) in der Antwort bereitstellen. Im Idealfall sollten die Tests Antworten zurück bei 10 Hz liefern.
Selbsttest: Bei diesem Test wird die grundlegende Funktionalität der GNSS-Engine überprüft. Der Selbsttest sollte in der Lage sein, grundlegende Probleme in der Engine zu erkennen (fehlerhafte Hardware, schlechte Verbindungen in der GNSS-Hardware, ohne dass ein externes Signal eingespritzt werden muss. Das Ziel dieser Validierung ist es, diesen kostengünstigen Test durchzuführen und als Tor in der Produktionsstraße zu verwenden, bevor das Gerät ausführlichere und teurere Tests durchläuft. In diesem Test führen die GNSS-Engine und der Treiber eine Selbstüberprüfung für Pinverbindungen durch und geben einen status Code zurück, der angibt, dass alles in Ordnung ist oder dass ein Fehler aufgetreten ist. Der Fehlercode für Fehler muss den erkannten Fehler angeben. Fehlercodes werden vom IHV festgelegt.

E/A-Überlegungen

Da die GNSS-Funktionalität nicht herkömmlichen Dateilese- und Schreibanforderungen an Gerätetreiber zugeordnet ist, werden die Funktionen ReadFile und WriteFile nicht für die GNSS-Treiber-APIs verwendet. Alle GNSS-Funktionen werden mithilfe von gut definierten GNSS-spezifischen Geräte-E/A-Steuerungsanforderungen (DeviceIoControl) implementiert, die auch als IOCTLs bezeichnet werden.

Alle IOCTLs verwenden METHOD_BUFFERED als Datenübertragungsmechanismus für Eingabe- und Ausgabedaten. Da die Größe der GNSS-bezogenen Daten relativ klein ist, sollte sich die zusätzliche Pufferkopie nicht auf die Systemleistung auswirken.

Der GNSS-Treiber wird mit der Option FILE_FLAG_OVERLAPPED in der CreateFile-Funktion geöffnet. Daher sind alle IOCTLs implizit asynchron. Während die meisten GNSS-IOCTLs jedoch semantisch asynchron sind (z. B. löst eine IOCTL eine Aktivität innerhalb des Treibers aus, und die Ergebnisse werden asynchron wieder erwartet), sind einige IOCTLs semantisch synchron in dem Sinne, dass keine logische asynchrone Aktion oder Aktivität mit solchen IOCTLs verbunden ist. Das synchrone Verhalten dieser wenigen IOCTLs wird erreicht, indem der GNSS-Adapterthread blockiert wird, nachdem der DeviceIoControl-Aufruf ausgegeben wurde, bis der E/A-Vorgang abgeschlossen ist. Daher liegt es in der Verantwortung des GNSS-Treibers, die IRP im Rahmen der Verarbeitung aller IOCTLs immer abzuschließen. Es wird erwartet, dass der GNSS-Adapter den Vertrag eines synchronen Aufrufs erfüllt und im Falle von Fehlern diese Befehle wiederholen oder nicht. Der IHV-Treiber muss sicherstellen, dass er alle Logiken auf der Treiberseite integriert hat, bevor er einen Fehler zurückgibt.

Für Anforderungs- und Antwortvorgänge hält der GNSS-Adapter immer einen ausstehenden E/A-Vorgang zur Verfügung, sodass die Antwort über die ausstehende IRP gesendet werden kann, wenn der GNSS-Treiber Daten als Antwort auf einen zuvor aufgerufenen Vorgang senden kann.

Einzelaufnahmesitzung

Eine Startfixanforderung für eine einzelne Shot-Korrektur an den Treiber enthält Genauigkeits- und Antwortzeitwerte. Die GNSS-Engine kann diese Werte verwenden, um die Absicht der Anwendungsanforderung zu verstehen und intelligente Entscheidungen zu treffen. Sobald eine Anforderung vom Treiber empfangen wurde, sollten alle vom Modul generierten Zwischenfixes zurückgegeben werden. Zwischenfixes sind Korrekturen, die vom Modul beim Berechnen eines Fixs generiert werden, der die Genauigkeitsanforderungen erfüllt oder endgültig ist. Die Häufigkeit dieser Zwischenfixes wird nicht erzwungen und ist ein Implementierungsdetails der Engine. Der GNSS-Adapter erwartet, dass die Korrekturen alle paar Sekunden kommen, und sie sollten sich von der letzten Zwischenbehebung unterscheiden.

Sobald die GNSS-Engine festgestellt hat, dass sie unter den aktuellen Signalbedingungen keinen besseren Fix erhalten kann, sollte sie einen endgültigen Fix zurückgeben und alle weiteren Berechnungen beenden. Die endgültige Korrektur erfüllt entweder die Genauigkeitsanforderung oder gibt an, dass der Motor die unter den aktuellen Bedingungen bereitgestellte Genauigkeit nicht verbessern kann.

Der GNSS-Adapter gibt in einem der beiden Fälle eine Stoppkorrektur für eine einzelne Aufnahmesitzung aus:

Es erhält eine endgültige Korrektur vom Treiber.
Die Antwortzeit für die Anforderung ist erreicht. Hier wird der letzte Zwischenfix an die Anwendung gesendet.

Die folgende Abbildung veranschaulicht zwei Einzelaufnahmensitzungen:

Diagramm mit zwischengeschalteten Korrekturen für zwei Sitzungen

Sitzung 1: Dem Treiber wurden Genauigkeits- und Antwortzeitparameter angegeben. Nach dem Befehl start fix hat der Treiber mit dem Senden von zwischengeschalteten Korrekturen begonnen. Nach einer Weile wurde festgestellt, dass keine genauere Korrektur zurückgegeben werden konnte, sodass der letzte Fix als endgültig angegeben wurde. Dies geschah, bevor das Antwortzeitlimit erreicht wurde. Der Adapter hat den endgültigen Fix an die Anwendung gesendet und einen Befehl zum Beenden des Fixs ausgegeben.

Sitzung 2: Dasselbe wie in Sitzung 1 oben, aber in diesem Fall hat die Engine eine bessere Korrektur durchgeführt, um die Genauigkeitsanforderung zu erfüllen, und sendete zwischengeschaltete Korrekturen. Nachdem das Zeitlimit für die Sitzungsantwort erreicht wurde, hat der Adapter eine Stoppkorrektur ausgegeben, die diese Sitzung im Treiber schließen sollte. Der letzte empfangene Zwischenfix wurde an die Anwendung gesendet.

Ein wichtiger Entwurfsaspekt, der bei der Implementierung der Single Shot-Unterstützung zu berücksichtigen ist, besteht darin, dass die GNSS-Engine Nachverfolgungssitzungen für 3 bis 5 Sekunden nach dem Empfang eines Stop Fix-Befehls weiterhin Satelliten nachverfolgen muss, wenn entfernungsbasierte Nachverfolgungssitzungen und zeitbasierte Nachverfolgungssitzungen nicht beide unterstützt werden. Dies liegt daran, dass der GNSS-Adapter simulierte entfernungsbasierte Nachverfolgungssitzungen und/oder zeitbasierte Nachverfolgungssitzungen mithilfe von Single Shot Fix-Sitzungen implementieren muss, und wenn die GNSS-Engine die Nachverfolgung von Satelliten sofort beendet, haben die meisten GNSS-Geräte eine Verzögerung bei der Erfassung, was die Implementierung einer simulierten Nachverfolgungssitzung unmöglich macht, die den Anforderungen der Navigation entspricht. Führen Sie Nachverfolgungs- oder Zuordnungsanwendungen aus.

Der GNSS-Adapter kann Anforderungen für Single Shot-Korrekturen initiieren, während sich das System im verbundenen Standby befindet, nicht nur, wenn das System aktiv ist. Dies kann vorkommen, um die Notwendigkeit von Hintergrundaufgaben, Systemdiensten, Geofences-Nachverfolgung im Anwendungsprozessor oder in anderen Fällen zu erfüllen. Der GNSS-Treiber muss in der Lage sein, diese Sitzungsanforderungen an das GNSS-Gerät zu übergeben und entweder die Anforderung zu erfüllen oder einen Fehler an den GNSS-Adapter zu senden.

Das folgende Sequenzdiagramm veranschaulicht die allgemeinen Aktionen im Zusammenhang mit dem Abrufen eines eigenständigen GNSS-Fixs. Dies schließt keine Anforderung von Unterstützungsdaten ein.

Sequenzdiagramm für die GNSS-Architektur .

Die Sequenzbeschreibung lautet wie folgt:

Der GNSS-Adapter öffnet den GNSS-Treiber mithilfe der CreateFile-API . WDF/KMDF/UMDF führt die erforderlichen optionalen Rückrufe für den GNSS-Treiber aus. Das zurückgegebene Dateihandle wird für alle nachfolgenden Vorgänge verwendet.
Der GNSS-Adapter gibt ein IOCTL aus, um die verschiedenen Plattformfunktionen an den Treiber zu kommunizieren. Der GNSS-Treiber schließt den E/A-Vorgang ab.
Der GNSS-Adapter stellt IOCTL zum Abrufen der Gerätefunktionen aus. Der GNSS-Treiber gibt die Gerätefunktionen zurück und schließt den E/A-Vorgang ab.
Der GNSS-Adapter stellt IOCTLs für alle treiberspezifischen Konfigurationen oder Befehle aus. Der GNSS-Treiber führt die erforderliche Aktion aus und schließt den E/A-Vorgang ab.
Der GNSS-Adapter gibt eine IOCTL_GNSS_START_FIXSESSION zusammen mit den Parametern aus, die den Typ und andere Aspekte der Korrektur angeben. Nach Erhalt dieser IOCTL interagiert der GNSS-Treiber mit dem zugrunde liegenden Gerät, um Korrekturen zu erhalten, und schließt anschließend den E/A-Vorgang ab.
Der GNSS-Adapter gibt eine IOCTL_GNSS_GET_FIXDATA aus und wartet auf die E/A-Fertigstellung. Wenn der GNSS-Treiber über einen zwischengeschalteten Fix verfügt, gibt er die Daten zurück, indem der E/A-Vorgang abgeschlossen wird.
Schritt 6 wird wiederholt, bis der GNSS-Treiber angibt, dass keine weiteren Korrekturen erwartet werden (endgültiger Fix erhalten).
Der GNSS-Adapter gibt IOCTL_GNSS_STOP_FIXSESSION aus. Der GNSS-Treiber führt den erforderlichen Bereinigungsvorgang aus, der der ursprünglichen Fixanforderung zugeordnet ist.
Der GNSS-Adapter schließt das Dateihandle des Treibers mithilfe der CloseHandle-API .

Die GNSS-IOCTLs und die zugehörigen Datenstrukturen werden in der Referenz zu GNSS-Treibern ausführlich beschrieben.

Entfernungsbasierte Nachverfolgungssitzung

Entfernungsbasierte Nachverfolgungssitzungen werden häufig von Endbenutzeranwendungen verwendet, da dies in der Vergangenheit der einzige Sitzungstyp war, der in den .NET-APIs verfügbar war. Der Entfernungswert 0 gibt an, dass die GNSS-Engine Korrekturen mit der höchstmöglichen Rate bereitstellen muss.

Der GNSS-Adapter startet Entfernungsverfolgungssitzungen mit dem GNSS-Treiber nur, wenn dieser angibt, dass er über die Funktion SupportDistanceTracking verfügt.

Eine Startfixanforderung an den Fahrer für eine Entfernungsverfolgungssitzung umfasst die gewünschte horizontale Genauigkeit und den Bewegungsschwellenwert, d. h. die Haversine-Entfernung in Metern, die das System abdecken muss, bevor der GNSS-Treiber eine Positionsaktualisierung bereitstellt. Die GNSS-Engine kann diese Werte verwenden, um die Absicht der Anwendungsanforderung zu verstehen und intelligente Entscheidungen zu treffen, z. B. die Häufigkeit der Standortüberprüfung anpassen.

Sobald eine Startfixanforderung vom Treiber empfangen wurde, sollte er damit beginnen, alle vom Modul generierten Zwischenfixe zurückzugeben, bis er einen endgültigen Fix erhält. Dies wird als erste Position der Sitzung betrachtet. Danach beginnt die GNSS-Engine mit der Bereitstellung von Korrekturen, wenn sie erkennt, dass die Haversine-Entfernung ungefähr zurückgelegt wurde.

Wenn die GNSS-Engine feststellt, dass sie den Standort des Geräts nicht mehr nachverfolgen kann (z. B. wenn Satelliten nicht mehr sichtbar sind), sollte sie einen Fehler an den GNSS-Adapter zurückgeben, damit die Standortplattform auf andere Mechanismen zurückgreifen kann, um Positionsupdates für die Endbenutzeranwendung bereitzustellen. Der GNSS-Adapter muss innerhalb des folgenden Zeitraums einen Fehler bereitstellen:

[(Distance-remaining-since-last-known-position (m) / geschätzte Geschwindigkeit (m/s)) – 5 Sekunden] oder 5 Sekunden, je nachdem, welcher Wert am größten ist.

Wenn die GNSS-Engine einen Fehler für den GNSS-Adapter bereitgestellt hat, der GNSS-Adapter die Nachverfolgungssitzung jedoch noch nicht beendet hat, sollte die GNSS-Engine weiterhin auf stromoptimierte Weise überprüfen, ob sie den Ort der Nachverfolgung fortsetzen kann. Der IHV kann Optimierungen verwenden, um diese Erkennung bei geringer Leistung zu ermöglichen. Zu den gängigen Verfahren zur Optimierung gehören:

Progressives Back-Off
Warten auf kostengünstige Signale, die auf Gerätebewegungen hinweisen, erneut überprüft werden
Leistungsüberprüfungen für Satellitensignal

Sobald die GNSS-Engine nach einer Fehlerbedingung erneut einen endgültigen Fix bereitstellen kann, sollte sie diese Position an den GNSS-Adapter senden, um anzuzeigen, dass die Nachverfolgung erfolgreich fortgesetzt wurde.

Der GNSS-Adapter gibt einen Änderungsfixbefehl für eine entfernungsbasierte Nachverfolgungssitzung aus, wenn eine oder mehrere Anwendungen, die die Nachverfolgungssitzung angefordert haben, die Anforderung abgebrochen haben oder wenn neue Anwendungen eine entfernungsbasierte Nachverfolgungssitzung anfordern. In diesem Fall berechnet der GNSS-Adapter die neuen aggregierten Sitzungsparameter, die zum Multiplexen der verschiedenen aktiven Sitzungen erforderlich sind, und aktualisiert den GNSS-Treiber mit diesen Parametern.

Der GNSS-Adapter gibt einen Stop Fix-Befehl für eine entfernungsbasierte Nachverfolgungssitzung aus, wenn:

Die Tracking-Sitzung wurde an eine andere im System verfügbare Positionierungs-Engine übergeben.
Anwendungen, die die Nachverfolgungssitzung angefordert haben, haben die Anforderung abgebrochen.

Die folgende Abbildung veranschaulicht zwei entfernungsbasierte Nachverfolgungssitzungen:

interne Nachverfolgung für den GNSS-Treiber .

Sitzung 1: Der GNSS-Treiber erhielt beim Initiieren der Nachverfolgungssitzung Genauigkeits- und Bewegungsschwellenwerte. Nach dem Befehl start fix beginnt der Treiber mit dem Senden von Zwischenfixes, bis er einen endgültigen Fix oder einen Fix erhält, der die Genauigkeitsanforderung erfüllt, an dem dieser Fix für den GNSS-Adapter bereitgestellt wird, und die GNSS-Engine startet den Entfernungsverfolgungsprozess. Während die Sitzung aktiv ist, sendet der GNSS-Adapter eine Anforderung zum Ändern der Sitzungsparameter zuweilen T1 und T2. Nach jeder Änderung der Parameter sendet der GNSS-Treiber ein Fixupdate an den GNSS-Adapter und setzt die Entfernungsverfolgungssitzung mit den neuen Parametern fort, bis der GNSS-Adapter einen Stop Fix-Befehl sendet.

Sitzung 2: Der Sitzungsinitiierungsprozess ähnelt der obigen Sitzung 1, aber zu einem bestimmten Punkt kann die GNSS-Engine die Position nicht nachverfolgen. Nach einer Zeit, die von der Entfernung und der geschätzten Bewegungsgeschwindigkeit abhängig ist, sendet der GNSS-Treiber einen Fehler. Das GNSS-Modul überprüft weiterhin bei geringerer Leistung, wenn es wiederhergestellt werden kann, und wenn es wiederhergestellt wird, gibt es dies an den GNSS-Adapter an, indem es einen neuen Fix sendet. Die Sitzung wird nach Bedarf mit neuen Korrekturen aktualisiert, bis der GNSS-Adapter den Befehl stop fix sendet.

Der GNSS-Adapter kann aktiv bleiben oder sogar entfernungsbasierte Nachverfolgungssitzungen initiieren, während sich das System im verbundenen Standby befindet, nicht nur, wenn das System aktiv ist. Dies kann vorkommen, um die Notwendigkeit von Hintergrundaufgaben, Systemdiensten, Geofences-Nachverfolgung im Anwendungsprozessor oder in anderen Fällen zu erfüllen. Der GNSS-Treiber muss in der Lage sein, diese Sitzungsanforderungen an das GNSS-Gerät zu übergeben und entweder die Anforderung zu erfüllen oder einen Fehler an den GNSS-Adapter zu senden.

Zeitbasierte Nachverfolgungssitzung

Zeitbasierte Nachverfolgungssitzungen können von Anwendungen verwendet werden, die eine häufige und regelmäßige Positionsaktualisierung erfordern, um die Benutzeroberfläche zu aktualisieren (z. B. Karten, Navigationsanwendungen usw.).

Der GNSS-Adapter startet zeitbasierte Nachverfolgungssitzungen mit dem GNSS-Treiber nur, wenn er später angibt, dass er über die Funktion SupportContinuousTracking verfügt.

Eine Startfixanforderung an den Treiber für eine zeitbasierte Nachverfolgungssitzung enthält die gewünschte horizontale Genauigkeit und das bevorzugte Zeitintervall, in dem der GNSS-Treiber eine Positionsaktualisierung bereitstellen soll. Die GNSS-Engine kann diese Werte verwenden, um die Absicht der Anwendungsanforderung zu verstehen und intelligente Entscheidungen zu treffen, z. B. die Häufigkeit anpassen, mit der nach Standort gesucht werden soll, und einige Sekunden vor dem Intervall mit der Erfassung von Satelliten beginnen, um eine Positionsaktualisierung rechtzeitig bereitzustellen usw.

Sobald eine Startfixanforderung vom Treiber empfangen wurde, sollte er damit beginnen, alle vom Modul generierten Zwischenfixe zurückzugeben, bis er einen endgültigen Fix erhält. Dies wird als erste Position der Sitzung betrachtet. Danach beginnt die GNSS-Engine mit der Bereitstellung von Korrekturen in dem für die Sitzungsparameter erforderlichen Intervall. Wenn die GNSS-Engine keine Positionen in der von der Anwendung benötigten Häufigkeit bereitstellen kann, sollte sie Korrekturen mit der maximal zulässigen Rate bereitstellen.

Der IHV kann Optimierungen verwenden, um diese Erkennung mit geringer Leistung zu ermöglichen, wie im vorherigen Abschnitt erläutert. Sobald die GNSS-Engine nach einer Fehlerbedingung erneut einen endgültigen Fix bereitstellen kann, sollte sie diese Position an den GNSS-Adapter senden, um anzuzeigen, dass die Nachverfolgung erfolgreich fortgesetzt wurde.

Der GNSS-Adapter gibt den Befehl modify fix für eine zeitbasierte Nachverfolgungssitzung aus, wenn eine oder mehrere Anwendungen, die die Nachverfolgungssitzung angefordert haben, die Anforderung abgebrochen haben oder wenn neue Anwendungen eine zeitbasierte Nachverfolgungssitzung anfordern. In diesem Fall berechnet der GNSS-Adapter die neuen aggregierten Sitzungsparameter, die zum Multiplexen der verschiedenen aktiven Sitzungen erforderlich sind, und aktualisiert den GNSS-Treiber mit diesen Parametern.

Der GNSS-Adapter gibt den Befehl stop fix für eine zeitbasierte Nachverfolgungssitzung aus, wenn:

Die Tracking-Sitzung wurde an eine andere im System verfügbare Positionierungs-Engine übergeben.
Anwendungen, die die Nachverfolgungssitzung angefordert haben, haben die Anforderung abgebrochen.

Die folgende Abbildung veranschaulicht zwei zeitbasierte Nachverfolgungssitzungen.

Zeitbasiertes Nachverfolgungsdiagramm für Korrekturen des GNSS-Treibers.

Sitzung 1: Der GNSS-Treiber erhielt beim Initiieren der Nachverfolgungssitzung Genauigkeit und einen bevorzugten Intervallparameter. Nach dem Befehl start fix beginnt der Treiber mit dem Senden von Zwischenfixes, bis er einen endgültigen Fix oder einen Fix erhält, der die Genauigkeitsanforderung erfüllt, an dem dieser Fix für den GNSS-Adapter bereitgestellt wird, und die GNSS-Engine startet den zeitbasierten Nachverfolgungsprozess. Während die Sitzung aktiv ist, sendet der GNSS-Adapter eine Anforderung zum Ändern der Sitzungsparameter zuweilen T1 und T2. Nach jeder Änderung von Parametern sendet der GNSS-Treiber ein Fixupdate an den GNSS-Adapter und setzt die zeitbasierte Nachverfolgungssitzung mit den neuen Parametern fort, bis der GNSS-Adapter einen Befehl zum Fix beenden sendet.

Sitzung 2: Der Sitzungsinitiierungsprozess ähnelt dem in Sitzung 1 oben, aber zu einem bestimmten Zeitpunkt kann die GNSS-Engine die Position nicht mehr nachverfolgen. Wenn die GNSS-Engine innerhalb von 15 Sekunden nach dem für die Sitzungsparameter erforderlichen Intervall keine Korrektur bereitstellen kann, sendet der GNSS-Treiber einen Fehler. Das GNSS-Modul überprüft weiterhin bei geringerer Leistung, wenn es wiederhergestellt werden kann, und wenn es wiederhergestellt wird, gibt es dies an den GNSS-Adapter an, indem es einen neuen Fix sendet. Die Sitzung wird nach Bedarf mit neuen Korrekturen aktualisiert, bis der GNSS-Adapter den Befehl stop fix sendet.

Der GNSS-Adapter kann aktiv bleiben oder sogar zeitbasierte Nachverfolgungssitzungen initiieren, während sich das System im verbundenen Standby befindet, nicht nur, wenn das System aktiv ist. Dies kann vorkommen, um die Notwendigkeit von Hintergrundaufgaben, Systemdiensten, Geofence-Tracking im Anwendungsprozessor oder anderen Fällen zu erfüllen. Der GNSS-Treiber muss in der Lage sein, diese Sitzungsanforderungen an das GNSS-Gerät zu übergeben und entweder die Anforderung zu erfüllen oder einen Fehler an den GNSS-Adapter zu senden.

Gleichzeitiges Behandeln verschiedener Arten von Fixsitzungen

Einige erweiterte GNSS-Engines können eine Single Shot-Sitzung mit einer Distance-Based und/oder einer Time-Based-Nachverfolgungssitzung gleichzeitig verarbeiten. Im Idealfall sollten sich unabhängige Sitzungen nicht gegenseitig beeinflussen, aber dies ist möglicherweise nicht immer möglich, insbesondere bei gleichzeitigen Single Shot- und Time Based Tracking-Sitzungen. Dieser Abschnitt enthält einige Richtlinien für die IHV-Implementierung für den Fall, dass Kompromisse gemacht werden müssen, um gleichzeitige Sitzungen verschiedener Typen zu behandeln.

In diesem Abschnitt werden die folgenden Akronyme verwendet:

SS: Single Shot-Sitzung
DBT: Entfernungsbasierte Nachverfolgungssitzung
TBT: Sitzung zur zeitbasierten Nachverfolgung
TBF: Zeit zwischen Korrekturen

Die folgende Tabelle enthält einige Szenarien zum gleichzeitigen Verarbeiten von Einzelaufnahmen und zeitbasierten Nachverfolgungssitzungen:

Fall	SS aktiv?	TBT aktiv?	Details zur Anfrage	Akzeptables Intervall der Korrekturen	Kommentare
1	X	X	SS-Sitzung, die zum Zeitpunkt der regelmäßigen TBT-Sitzung mit verbleibendem Timeout >= Intervall gestartet wurde	Identisch mit TBT-Intervall	SS-Sitzungsverhalten: Zwischene und endgültige Korrekturen werden bis zum Timeout gesendet. Die Sitzung wurde unmittelbar nach dem Empfang des Stopps geschlossen. TBT-Sitzungsverhalten: Zwischene und endgültige Korrekturen werden gesendet. Korrekturen wurden ungefähr gemäß dem Intervall empfangen. Die Sitzung wurde unmittelbar nach dem Empfang des Stopps geschlossen.
2	X	X	SS-Sitzung, die zum Zeitpunkt der regelmäßigen TBT-Sitzung mit verbleibendem Timeoutintervall < gestartet wurde	Das Intervall bleibt mit dem SS-Timeout identisch, bis die SS-Sitzung erfüllt ist. Anschließend kann das Intervall so aktualisiert werden, dass es dem TBT-Intervall entspricht.	SS-Sitzungsverhalten: Zwischene und endgültige Korrekturen werden bis zum Timeout gesendet. Die Sitzung wurde unmittelbar nach dem Empfang des Stopps geschlossen. TBT-Sitzungsverhalten: Zwischene und endgültige Korrekturen werden gesendet. Korrekturen wurden ungefähr gemäß dem Intervall empfangen, können jedoch häufiger auftreten, während die SS-Sitzung bedient wird. Die Sitzung wird unmittelbar nach dem Empfang des Stopps geschlossen.
3	X	X	SS-Sitzung gestartet, während eine fortlaufende regelmäßige TBT-Sitzung mit Timeout >= Intervall gestartet wird	Identisch mit TBT-Intervall	SS-Sitzungsverhalten: Zwischene und endgültige Korrekturen werden bis zum Timeout gesendet. Die Sitzung wird unmittelbar nach dem Empfang des Stopps geschlossen. TBT-Sitzungsverhalten: Zwischene und endgültige Korrekturen werden gesendet. Korrekturen, die ungefähr gemäß dem Intervall empfangen werden. Die Sitzung wird unmittelbar nach dem Empfang des Stopps geschlossen.
4	X	X	SS-Sitzung gestartet, während eine fortlaufende regelmäßige TBT-Sitzung mit Timeoutintervall < gestartet wird	Das Intervall ändert sich so, dass es dem SS-Timeout entspricht, bis die SS-Sitzung erfüllt ist. Anschließend kann das Intervall so aktualisiert werden, dass es dem TBT-Intervall entspricht.	SS-Sitzungsverhalten: Zwischene und endgültige Korrekturen werden bis zum Timeout gesendet. Die Sitzung wird unmittelbar nach dem Empfang des Stopps geschlossen. TBT-Sitzungsverhalten: Zwischene und endgültige Korrekturen werden gesendet. Korrekturen, die ungefähr gemäß dem Intervall empfangen werden, können aber häufiger sein, während die SS-Sitzung bedient wird. Die Sitzung wird unmittelbar nach dem Empfang des Stopps geschlossen.
5		X	Regelmäßige TBT-Sitzung gestartet mit geändertem Intervall	Sitzung mit Modem wird auf das neue Intervall aktualisiert und entspricht dem TBT-Intervall. Bei Bedarf wird die Modemsitzung neu gestartet.	SS-Sitzungsverhalten: Nicht zutreffend TBT-Sitzungsverhalten: Zwischene und endgültige Korrekturen werden gesendet. Korrekturen, die ungefähr gemäß dem Intervall empfangen werden. Die Sitzung wird unmittelbar nach dem Empfang des Stopps geschlossen.
6	X	X	SS-Sitzung, die zu dem Zeitpunkt ausgeführt wird, zu dem eine laufende regelmäßige TBT-Sitzung eine Änderung des Intervalls erhält, mit verbleibendem Timeout >= Intervall	Identisch mit TBT-Intervall	SS-Sitzungsverhalten: Zwischene und endgültige Korrekturen werden bis zum Timeout gesendet. Die Sitzung wird unmittelbar nach dem Empfang des Stopps geschlossen. TBT-Sitzungsverhalten: Zwischene und endgültige Korrekturen werden gesendet. Korrekturen, die ungefähr gemäß dem Intervall empfangen werden. Die Sitzung wird unmittelbar nach dem Empfang des Stopps geschlossen.
7	X	X	SS-Sitzung, die zu dem Zeitpunkt ausgeführt wird, zu dem eine fortlaufende regelmäßige TBT-Sitzung eine Änderung des Intervalls erhält, mit verbleibendem Timeoutintervall <	Das Intervall ändert sich so, dass es dem SS-Timeout entspricht, bis die SS-Sitzung erfüllt ist. Anschließend kann das Intervall so aktualisiert werden, dass es dem TBT-Intervall entspricht.	SS-Sitzungsverhalten: Zwischene und endgültige Korrekturen werden bis zum Timeout gesendet. Die Sitzung wurde unmittelbar nach Dem Empfang des Stopps geschlossen./li> TBT-Sitzungsverhalten: Zwischene und endgültige Korrekturen werden gesendet. Korrekturen, die ungefähr gemäß dem Intervall empfangen werden, können aber häufiger sein, während die SS-Sitzung bedient wird. Die Sitzung wird unmittelbar nach dem Empfang des Stopps geschlossen.

Wenn gleichzeitig eine zeitbasierte und eine entfernungsbasierte Nachverfolgungssitzung vorhanden sind, kann die Genauigkeitsnachverfolgung der GNSS-Engine so festgelegt werden, dass sie mit der kleinsten der beiden Funktioniert. Die folgende Tabelle enthält auch einige Richtlinien für den Fall unterschiedlicher Werte für die erforderliche Genauigkeit, wenn gleichzeitig einzelne Aufnahme- und Nachverfolgungssitzungen vorhanden sind:

Fall	SS-Genauigkeit	DBT- oder TBT-Genauigkeit	Gesamtgenauigkeit der GNSS-Engine	Kommentare
1	Mittel/Niedrig –> Hoch	Nicht zutreffend	Mittel/Niedrig –> Hoch	SS-Sitzungsverhalten: Die Sitzung mit dem GNSS-Gerät wird aktualisiert oder neu gestartet, um ein ergebnis mit hoher Genauigkeit zu erhalten. Zwischenzeitliche Fehlerbehebungen werden für den HLOS bereitgestellt, sobald sie verfügbar sind.
2	Hoch --> Mittel/Niedrig	Nicht zutreffend	Hoch --> Mittel/Niedrig	SS-Sitzungsverhalten: Die Sitzung mit dem GNSS-Gerät wird aktualisiert oder neu gestartet, um ein Ergebnis mit mittlerer/niedriger Genauigkeit zu erhalten. Wenn eine Korrektur, die die Anforderungen erfüllt, bereits verfügbar ist, wird dies als endgültige Korrektur zurückgegeben. Andernfalls werden zwischengeschaltete Fehlerbehebungen für den HLOS bereitgestellt, sobald sie verfügbar sind.
3	Mittel/Niedrig –> Hoch	High	High	SS-Sitzungsverhalten: Da bereits eine Sitzung mit hoher Genauigkeit für die DBT- oder TBT-Sitzung vorhanden ist, stellt die SS-Sitzung nur zwischengeschaltete weitere Korrekturen für den HLOS bereit, bis die endgültige gewünschte Genauigkeit erreicht ist oder eine endgültige Korrektur abgerufen wird.
4	Hoch --> Mittel/Niedrig	High	High	SS-Sitzungsverhalten: Da bereits eine Sitzung mit hoher Genauigkeit für die DBT- oder TBT-Sitzung vorhanden ist, stellt die SS-Sitzung nur zwischengeschaltete weitere Korrekturen für den HLOS bereit, bis die endgültige gewünschte Genauigkeit erreicht ist oder eine endgültige Korrektur abgerufen wird.
5	Mittel/Niedrig –> Hoch	Mittel/Niedrig	Mittel/Niedrig –> Hoch, dann wieder mittel/niedrig, nachdem die SS-Sitzung abgeschlossen ist	SS-Sitzungsverhalten: Die Sitzung mit dem GNSS-Gerät wird aktualisiert oder neu gestartet, um ein Ergebnis mit hoher Genauigkeit zu erhalten. Zwischenfixes werden dem HLOS bereitgestellt, sobald sie verfügbar sind. DBT- oder TBT-Sitzungsverhalten: Es ist in Ordnung, dass diese Sitzung vorübergehend Ergebnisse mit hoher Genauigkeit erhält. Nachdem die SS-Sitzung jedoch bedient wurde, sollte die Genauigkeit dieser Sitzung auf Mittel/Niedrig zurückkehren.
6	Hoch –-> Mittel/Niedrig	Mittel/Niedrig	Hoch –-> Mittel/Niedrig	SS-Sitzungsverhalten: Die Sitzung mit dem GNSS-Gerät wird aktualisiert oder neu gestartet, um ergebnisse mit mittlerer/niedriger Genauigkeit zu erhalten. Wenn ein Fix, der die Anforderungen erfüllt, bereits verfügbar ist, wird dies als endgültiger Fix zurückgegeben. Andernfalls werden dem HLOS Zwischenfixes bereitgestellt, sobald sie verfügbar sind.
7	Nicht zutreffend	Mittel/Niedrig –> Hoch	Mittel/Niedrig –> Hoch	b>DBT- oder TBT-Sitzungsverhalten:** Die Sitzung mit dem GNSS-Gerät wird aktualisiert oder neu gestartet, um Ergebnisse mit hoher Genauigkeit zu erhalten. Zwischenfixes werden dem HLOS bereitgestellt, sobald sie verfügbar sind.
8	Nicht zutreffend	Hoch –-> Mittel/Niedrig	Hoch –-> Mittel/Niedrig	DBT- oder TBT-Sitzungsverhalten: Die Sitzung mit dem GNSS-Gerät wird aktualisiert oder neu gestartet, um ergebnisse mit mittlerer/niedriger Genauigkeit zu erhalten. Wenn ein Fix, der die Anforderungen erfüllt, bereits verfügbar ist, wird dies als endgültiger Fix zurückgegeben. Andernfalls werden dem HLOS Zwischenfixes bereitgestellt, sobald sie verfügbar sind.
9	High	Mittel/Niedrig –> Hoch	High	DBT- oder TBT-Sitzungsverhalten: Die Sitzung hat bereits Korrekturen mit hoher Genauigkeit oder Zwischenfixes erhalten, also keine Änderungen.
10	High	Hoch –-> Mittel/Niedrig	Hoch, dann ändert sich nach Abschluss der SS-Sitzung in Mittel/Niedrig	DBT- oder TBT-Sitzungsverhalten: Die Sitzung kann weiterhin Korrekturen mit hoher Genauigkeit oder Zwischenfixes erhalten, bis die SS-Sitzung abgeschlossen ist. Anschließend muss es zu Korrekturen mit mittlerer/niedriger Genauigkeit geändert werden.
11	Mittel/Niedrig<	Mittel/Niedrig –> Hoch	Mittel/Niedrig –> Hoch	DBT- oder TBT-Sitzungsverhalten: Die Sitzung mit dem GNSS-Gerät wird aktualisiert oder neu gestartet, um Ergebnisse mit hoher Genauigkeit zu erhalten. Zwischenfixes werden dem HLOS bereitgestellt, sobald sie verfügbar sind.
12	Mittel/Niedrig	Hoch –-> Mittel/Niedrig	Hoch –-> Mittel/Niedrig	DBT- oder TBT-Sitzungsverhalten: Die Sitzung mit dem GNSS-Gerät wird aktualisiert oder neu gestartet, um ergebnisse mit mittlerer/niedriger Genauigkeit zu erhalten. Wenn ein Fix, der die Anforderungen erfüllt, bereits verfügbar ist, wird dies als endgültiger Fix zurückgegeben. Andernfalls werden dem HLOS Zwischenfixes bereitgestellt, sobald sie verfügbar sind.

Übersicht über die Architektur

Unterstützung für GNSS-Geräte (Global Navigation Satellite System) und Treiber, die dem älteren Windows-Modell folgen

Koexistenz von GNSS-Geräten (Global Navigation Satellite System)

Übersicht über die Schnittstelle des Global Navigation Satellite System (GNSS)