GNSS-Treiberanforderungen (Global Navigation Satellite System)

  • Artikel
  • 13 Minuten Lesedauer

Beschreibt Anforderungen, Annahmen und Einschränkungen, die bei der Entwicklung eines GNSS-Treibers (Global Navigation Satellite System) für Windows 10 zu berücksichtigen sind.

Allgemeine Anforderungen

  • Treiberframework: Der GNSS-Treiber sollte als UMDF 2.0-Treiber a basierend auf dieser Schnittstellendefinition geschrieben werden, im Gegensatz zu einem unformatierten WDM-Treiber oder KMDF-Treiber. UMDF 1.0-Treiber werden auch nicht unterstützt. Die Definition der GNSS-Treiberschnittstelle oder die GNSS-Komponenten des Microsoft High Level Operating System (HLOS) wie der GNSS-Adapter unterscheiden nicht zwischen einem WDF-, KMDF-GNSS-Treiber und einem UMDF 2.0-Treiber, solange der Treiber die erforderlichen Funktionen gemäß diesem Schnittstellenentwurf bereitstellt. UMDF 2.0 bietet eine höhere Stabilität, Einfachheit und Flexibilität bei der Implementierung von Features, die funktionen erfordern, die nur im Benutzermodus angeboten werden. In der Regel sollten IHVs UMDF 2.0 gegenüber KMDF vorziehen, wenn das frühere Framework auf der Plattform verfügbar ist.

 UMDF 2.0 ist auf allen Plattformen verfügbar, und IHVs wird dringend empfohlen, den im Benutzermodus geschriebenen Treiber zu verwenden.

  • Mehrere Anwendungssitzungen: Eine Anwendungssitzung ist eine Positionierungssitzung, die von einer HLOS-Komponente stammt, die direkt mit dem GNSS-Treiber interagiert. Der GNSS-Treiber könnte mehrere Anwendungssitzungen nativ unterstützen, indem er seine Zustandsvariablen und Funktionen auf Anwendungsbasis partitioniert. Dies ist eine optionale Funktion des Treibers und wird speziell durch klar definierte Informationen zu GNSS-Treiberfunktionen angegeben. Um dieses optionale Verhalten zu unterstützen, muss der GNSS-Treiber das Dateihandle nachverfolgen, das die HLOS-Anwendungen während createFile erhalten, und alle nachfolgenden HLOS-Vorgänge dem anwendungssitzungsspezifischen Dateihandle zuordnen. Diese native Unterstützung des GNSS-Treibers ermöglicht es den HLOS-Komponenten, flexibler und weniger restriktiv zu sein, den Treiber für den Rest der Plattform verfügbar zu machen. Ein GNSS-Treiber, der diese Funktion unterstützt, muss möglicherweise Zustandsinformationen für jede einzelne Anwendungssitzung logisch partitionieren und verwalten. Ein GNSS-Treiber, der diese Funktion nicht unterstützt, muss anstelle der logischen App-spezifischen Partition nur den globalen Zustand für alle Anwendungssitzungen beibehalten. In diesem zweiten Modus erkennt der GNSS-Treiber nicht, dass mehrere parallele Anwendungssitzungen vorhanden sind, und behandelt alle Anforderungen von HLOS so, als ob sie aus derselben Anwendungssitzung stammen.

    Unterstützung von GNSS-Treibern für mehrere Anwendungssitzungen.

    Die Unterstützung im GNSS-Treiber für mehrere Anwendungssitzungen hat den Vorteil, dass eine Testanwendung im HLOS direkt mit dem GNSS-Treiber gleichzeitig mit dem GNSS-Adapter interagieren kann. Bei der Testanwendung und dem GNSS-Adapter handelt es sich um verschiedene Anwendungen, die gleichzeitig unterschiedliche Sitzungen an einen einzelnen GNSS-Treiber anfordern können. Wenn mehrere Anwendungssitzungen nicht unterstützt werden, muss der GNSS-Treiber entweder mit der Betriebssystemstandortplattform getestet werden, oder andernfalls sollte der Dienst, der die Betriebssystemstandortplattform hostt, beendet werden, um störungen der Testanwendung zu vermeiden.

  • Korrigieren der Sitzung: Der Vorgang des Abrufens von Positionsinformationen vom zugrunde liegenden Treiber (einzeler Schuss oder Verfolgung) wird zu einem Konzept einer Fixsitzung abstrahiert. Treiber müssen mindestens eine Fixsitzung jedes unterstützten Sitzungstyps unterstützen. Die Sitzungstypen werden unter der GNSS_FIXSESSIONTYPE-Enumeration definiert.

    • GNSS-Treiber müssen mindestens eine Einzelne Shot Fix-Sitzung unterstützen.

    • Treiber, die entfernungsbasierte Nachverfolgungskorrektursitzungen unterstützen, müssen gleichzeitig eine einzelne Fixsitzung und eine entfernungsbasierte Nachverfolgungskorrektursitzung unterstützen.

    • Treiber, die zeitbasierte Nachverfolgungs-Fixsitzungen unterstützen, müssen gleichzeitig eine einzelne Fixsitzung und eine zeitbasierte Nachverfolgungssitzung unterstützen.

    • Treiber, die entfernungsbasierte Nachverfolgungs-Fixsitzungen und zeitbasierte Nachverfolgungskorrektursitzungen unterstützen, müssen gleichzeitig eine einzelne Fixsitzung, eine entfernungsbasierte Nachverfolgungskorrektursitzung und eine zeitbasierte Nachverfolgungskorrektursitzung unterstützen.

    Treiberunterstützung für mehrere gleichzeitige Fixsitzungen.

    Ob der Treiber mehrere gleichzeitige Fixsitzungen unterstützt, wird durch einen klar definierten Treiberfunktionsparameter ausgedrückt. Wenn ein Treiber nicht explizit mehrere parallele Fixsitzungen unterstützt, muss eine neue Fixsitzungsanforderung fehlschlagen, wenn eine Sitzung desselben Fixtyps bereits gestartet und aktiv ist. Wenn keine Unterstützung für mehrere Fixsitzungen vorhanden ist, ist die HLOS-Komponente aktiviert, um sicherzustellen, dass mehrere GNSS-Anforderungen, die von den allgemeinen Anwendungen stammen, gemultixt und einer einzelnen Fixsitzungsanforderung an den GNSS-Treiber zugeordnet werden.

    Der GNSS-Treiber ist nicht erforderlich, um mehrere parallele Fixsitzungen desselben Typs zu unterstützen. Tatsächlich unterstützt der HLOS-GNSS-Adapter in Windows 10 die Nutzung der GNSS-Treiberfunktion nicht, um mehrere Fixsitzungen desselben Typs zu verwenden, sodass IHVs vorerst nicht dazu aufgefordert werden, in diese Funktionalität zu investieren. In zukünftigen Releases wird es in Betracht gezogen, dem GNSS-Adapter das direkte Starten von Sitzungen mit dem GNSS-Treiber für jede Fixanforderung zu ermöglichen, die von den oberen Ebenen der Standortplattform abgerufen wird, anstatt das Sitzungsmultixing selbst durchzuführen. Die Unterstützung des Multiplexings von Fixsitzungen im GNSS-Adapter vereinfacht die Treiberimplementierung, da es nicht erforderlich ist, mehrere Sitzungen desselben Typs für eine Anwendung oder Implementierung von Multiplexing zu verarbeiten, reduziert die Speicherauslastung im Treiber, und der GNSS-Adapter muss nicht den Fall behandeln, dass der HLOS eine Reihe von Fixsitzungen startet, die größer sind als vom GNSS-Treiber unterstützt. Unterschiedliche Geräteebenen und verschiedene Treiber würden eine unterschiedliche Anzahl gleichzeitiger Fixsitzungen unterstützen, daher müsste dieser Fall behandelt werden, was zu einer Komplexität im GNSS-Adapter führen würde, um alle Fälle zu verarbeiten. Daher implementiert der GNSS-Adapter in Windows 10 nur die einzelne Fixsitzung jedes unterstützten Typs und ignoriert die Unterstützung mehrerer Fixsitzungen durch den Treiber, bis wir diese Funktionalität benötigen.

    Jede Fixsitzung ist zustandsbehaftet und muss dieser klar definierten Sequenz folgen:

    1. Starten einer Fixsitzung

    2. Abrufen einer oder mehrerer Fixes

    3. Ändern der Fixsitzung bei Bedarf

    Dies ist mindestens erforderlich, bis der GNSS-Adapter das Multiplexing von Fixsitzungen desselben Typs verarbeitet und möglicherweise später sogar erforderlich ist, um den Fall von mehr gleichzeitig aktiven Fixsitzungen als die vom GNSS-Treiber unterstützte Zahl zu behandeln.

    1. Beenden der Fixsitzung

    Fixsitzungen werden durch eine Fixsitzungs-ID eindeutig identifiziert. Vom HLOS können keine Positionsinformationen außerhalb des Kontexts einer Fixsitzung abgerufen werden. Der GNSS-Treiber muss die Änderung der Sitzungsparameter direkt zulassen, um den Multiplexingvorgang durch die HLOS-Komponente zu erleichtern, ohne dass die Fixsitzung neu gestartet werden muss.

    Die Berichtskommunikation zwischen einem GNSS-Treiber und einer Anwendung wird behoben.

  • Korrekturtyp: Der GNSS-Treiber muss mindestens die einfache Single Shot-Fix-Lösung unterstützen. Darüber hinaus sollte der Treiber nativ erweiterte Korrekturtypen (z. B. Nachverfolgung) unterstützen. Wie bereits erwähnt, bedeutet die Unterstützung zusätzlicher Fixtypen, dass der Treiber auch dann, wenn er nicht mehrere Fixsitzungen desselben Typs unterstützt, mindestens eine Fixsitzung eines unterstützten Fixtyps gleichzeitig unterstützen muss. Die HLOS-Komponente multiplext keine verschiedenen Fixtypen in einen einzelnen Typ.

  • Geräteschnittstelle und PnP: Der GNSS-Treiber sollte eine von Microsoft definierte Geräteschnittstelle mithilfe der WdfDeviceCreateDeviceInterface-API ankündigen, damit der HLOS über die Ankunft und Abreise des GNSS-Treibers benachrichtigt werden kann. Dies ist erforderlich, um einen GNSS-Treiber in einer PnP-Einstellung (Plug & Play) zu behandeln, und auch in Fällen, in denen aufgrund eines Dienstabsturzes auf Benutzerebene ein unerwarteter Treiber entladen wird, wenn der Treiber ein UMDF 2.0-Treiber ist. Der GNSS-Treiber sollte sicherstellen, dass die Geräteschnittstelle nur dann angekündigt wird, wenn die darunter liegende Hardware die HLOS-IOCTL-Aufrufe unterstützen kann und nicht davor.

  • Energierichtlinie für Geräte: Der GNSS-Treiber sollte die Energierichtlinie seines Geräts verwalten und die vom Betriebssystem ausgelösten Energieverwaltungsereignisse verarbeiten. Der Treiber sollte sich für die WDF_PNPPOWER_EVENT_CALLBACKS registrieren. EvtDeviceD0Entry-Rückruf (ausgelöst von WDF, wenn das System in den D0-Zustand wechselt) und WDF_PNPPOWER_EVENT_CALLBACKS. EvtDeviceD0Exit-Rückruf (wird von WDF ausgelöst, wenn das System aus dem D0-Zustand beendet wird). Der GNSS-Treiber sollte konfigurierbar sein, um die Energieverwaltung optional zu deaktivieren.

    Die genaue Energieverwaltung, die in einem GNSS-Gerät in den verschiedenen Systemenergiezuständen durchgeführt werden muss, muss entsprechend den Funktionen des GNSS-Geräts (unterstützt es ausgeladene Vorgänge oder nicht), ob tatsächlich ausgeladene Vorgänge aktiv sind und wie die Kommunikation zwischen dem System und dem GNSS-Gerät erfolgt, angepasst werden. Im Allgemeinen sind die Erwartungen wie folgt:

    • Das GNSS-Gerät funktioniert im niedrigsten Energiemodus, der möglich ist, wenn keine aktiven Sitzungen oder ausgeladenen Vorgänge vorhanden sind, unabhängig vom Energiezustand des Systems.

    • Bei ausgeladenen Szenarien muss das GNSS-Gerät möglicherweise unabhängig vom Systemstromzustand die Position in verschiedenen Intervallen überprüfen oder Benachrichtigungen empfangen, sodass das GNSS-Gerät möglicherweise auch während des verbundenen Standbymodus im D0-Zustand bleiben muss (dies ist der Standbyzustand des Bildschirms), aber die Hardware muss den Stromverbrauch auf ein Minimum reduzieren. Dieses Modell funktioniert beispielsweise für Geräte, die DMA (Direct Memory Access) oder einen seriellen Port an einem UART verwenden, um mit dem Host zu kommunizieren. Wird jedoch eine Herausforderung für die GNSS-Geräte sein, die über USB-Bus verbunden sind. In diesem Fall sollte sich die USB-Funktion des Geräts wahrscheinlich im D2-Gerätestromzustand (Anhalten) während des angeschlossenen Standbymodus befinden. Im Allgemeinen müssen GNSS-Geräte, die über USB verbunden sind, in den Zustand D2 (Anhalten) mit niedriger Leistung wechseln können, nachdem sie keine Fixsitzungen oder ausgelagerten Vorgänge ausgeführt haben und die USB-Busschnittstelle in den Anhaltezustand wechselt. Über den USB-Bus müssen alle Energiespar- und Reaktivierungsübergänge signalisiert werden. Wenn das GNSS-Gerät über aktive oder ausgeladene Sitzungen verfügt, muss das Gerät in der Lage sein, die In-Band-, USB-Resume-Signalisierung zu verwenden, um das SoC oder Kern-Silizium aus dem verbundenen Standbymodus zu reaktivieren. Das SoC- oder Kernsilicium muss in der Lage sein, als Reaktion auf das In-Band-, USB-Resume-Signal vom GNSS-Gerät aus dem niedrigsten Leistungszustand zu reaktivieren.

    • Auf Geräten, die den verbundenen Standbymodus nicht unterstützen, werden alle ausgeladenen Vorgänge abgesagt, wenn das Gerät in den modernen Standbymodus oder Ruhezustand wechselt. Dies umfasst ausgeladene Geofences, Entfernungsverfolgung oder regelmäßige Nachverfolgungssitzungen.

    • Geräte, die den verbundenen Standby unterstützen, haben weiterhin alle ausgeladenen Vorgänge aktiv, wenn das Gerät in den verbundenen Standbymodus wechselt, und es wird erwartet, dass das GNSS-Gerät die Nachverfolgungsvorgänge so effizient wie möglich fortsetzt, und es wird erwartet, dass Benachrichtigungen an den HLOS bereitgestellt werden, falls die Bedingung eines Geofencetriggers oder eine Aktualisierung der Überwachungssitzung relevant ist. Wenn keine ausgeladenen Vorgänge in einem Gerät vorhanden sind, das den verbundenen Standbymodus unterstützt, sollte das GNSS-Gerät in den niedrigsten Möglichen Stromzustand wechseln, aber dennoch in der Lage sein, Standortsitzungsanforderungen vom HLOS abzuhören. Auf Geräten, die SUPL unterstützen, muss es auch möglich sein, dass das GNSS-Gerät und der SUPL-Stapel bei NI-Benachrichtigungen im verbundenen Standbymodus aktiviert werden können.

    Allgemeine Informationen zur Energieverwaltung für Treiber finden Sie unter Zuständigkeiten der Energieverwaltung für Treiber.

  • Leistungsüberlegung: Der GNSS-Treiberstapel muss den Stromverbrauch als primäres Entwurfsziel berücksichtigen und die Aktivierung des Hauptprozessors so gering wie möglich halten. Alle erweiterten Funktionen (z. B. verschiedene Korrekturtypen) müssen energieeffizient ausgeführt werden, soweit der Hauptprozessor der App nicht mehr aktiv sein muss als erforderlich, und die meisten Verarbeitungsvorgänge können auf den Chipsatz-/Low-Power-Prozessor ausgelagert werden. In der Regel muss der GNSS-Treiber, sofern vom HLOS nichts anderes angegeben ist, den Stromverbrauch immer als wichtigste Einschränkung behandeln und so konzipiert sein, dass er die normalen Vorgänge mit minimalem Stromverbrauch ausführt. Die GNSS-Treiberschnittstelle ist explizit so konzipiert, dass das mobile Gerät so oft wie möglich in den Energiesparmodus wechseln kann, und um dem GNSS-Treiber erforderliche Energiehinweise zur Optimierung des Stromverbrauchs bereitzustellen. Für die Nachverfolgung, geofencing und andere Funktionen, die eine lang andauernde überwachung der allgegenwärtigen Position erfordern, muss der GNSS-Treiber/-engine hardware/prozessoren mit geringer Leistung nutzen. Wenn eine solche Funktionalität mithilfe eines Brute-Force-Abrufmechanismus im Treiber implementiert werden muss oder wenn sie im App-Prozessor implementiert werden muss, sollte sich der Treiber nicht für solche Vorgänge deklarieren. Dadurch kann der HLOS entweder die Offenlegung solcher Funktionen auf den Rest der Plattform einschränken oder eine alternative Implementierung dieser Funktionen verwenden, die auf anderen Plattformdiensten/Grundtypen basiert.

  • Programmiersprache: Die GNSS-Treiberschnittstelle wird als C-Sprachheaderdatei bereitgestellt, die keine C++-spezifischen Sprachgrundtypen verwendet (z. B. Strukturvererbung). Dadurch kann der IHV zwischen C und C++ wählen. Die Headerdatei der GNSS-Schnittstelle lässt die Auswahl für IHVs offen.

  • Filtertreiber: Der GNSS-Gerätestapel darf nicht so eingeschränkt werden, dass verhindert wird, dass dem Stapel ein zukünftiger Filtertreiber zur Unterstützung erweiterter Funktionen hinzugefügt wird. Der von IHV bereitgestellte GNSS-Treiber darf weder oben noch unten im Treiberstapel einen eigenen Filtertreiber enthalten.

  • Benachrichtigungen und Ereignisse: Da ein WDF-Treiber keine unerwünschte Benachrichtigung an den HLOS senden kann, gibt es immer mindestens ein ausstehendes IRP, das vom HLOS initiiert wird und dem Zweck dient, eine solche nicht angeforderte Benachrichtigung von der Treiberebene zu erhalten. Dies schließt den Fall ein, in dem sich das System im verbundenen Standbymodus befindet. Für den GNSS-Treiber umfassen solche unaufgeforderten Benachrichtigungen netzwerkinitiierte Anforderungen, Unterstützungsdaten für AGNSS-Unterstützung und andere anbieterspezifische Benachrichtigungen. Der HLOS stellt sicher, dass eine ausstehende E/A-Anforderung immer vorhanden ist, um solche Benachrichtigungen zu verarbeiten.

  • Benutzermodus-IHV-Erweiterung: IHVs können zubehörbasierte Benutzermoduskomponente schreiben, die über IHV-definierte private IOCTLs mit dem GNSS-Treiber interagiert. Dies ist insbesondere erforderlich, wenn sich der GNSS-Treiber im Kernelmodus befindet. In diesem Fall hat er keinen Zugriff auf Funktionen, die ausschließlich im Benutzermodus verfügbar sind (z. B. Wi-Fi Scan, Verbindungs-Manager APIs usw.). Beachten Sie, dass mit UMDF 2.0 in Windows 10 ein UMDF-GNSS-Treiber keine separate Benutzermoduskomponente benötigt, obwohl die IHV möglicherweise weiterhin eine separate Benutzermoduskomponente implementiert. Diese Benutzermoduskomponenten werden als reine Erweiterung des GNSS-Treibers behandelt und als Teil des von IHV bereitgestellten BSP-Drops behandelt. Die von Microsoft bereitgestellten HLOS-Komponenten kennen die genauen Implementierungsdetails solcher Komponenten und den Interaktionsmechanismus zwischen den IHV-Komponenten für Den Benutzermodus/Kernelmodus. Wenn der GNSS-Treiber als UMDF 2.0-Treiber mit IHV-Erweiterungen im Benutzermodus geschrieben wird, wird nicht empfohlen, da dieses Modell wahrscheinlich eine größere Speicherauslastung erfordert.

    Die IHV-Erweiterungen im Benutzermodus müssen den folgenden Regeln entsprechen:

    • Die Semantik und das Verhalten der ioCTLs des öffentlichen GNSS-Treibers müssen von der Benutzermodus-IHV-Erweiterung und ihrer Interaktion mit dem GNSS-Treiber nicht beeinflusst und nicht beeinträchtigt werden.

    • Die Benutzermoduserweiterung muss den Sicherheits-, Leistungs- und anderen Plattformgrundlagen und Richtlinien entsprechen, die von der Windows 10-Plattform festgelegt werden.

    • Die Benutzermoduserweiterung darf nur die autorisierten Aktivitäten ausführen, die von Microsoft genehmigt wurden, ohne dass die Betriebssystemplattform diese Autorisierung zur Laufzeit erzwingen/überprüfen muss.

    Microsoft kann weiterhin Sicherheitsrichtlinien erzwingen und die Lebensdauer solcher Komponenten steuern. Der wichtigste Punkt ist hier, dass die IHV-Benutzermoduskomponenten nicht auf die Plattform zählen sollten, um solche Richtlinien zu erzwingen, da die Erweiterungskomponente als vertrauenswürdige Betriebssystemkomponente behandelt wird.

    IHVs fügen keine beliebigen Funktionen hinzu oder verwenden keine nicht autorisierten Betriebssystemdienste/sicheren Ressourcen.

Mindestanforderungen an den Support

Es wird eine Vielzahl von GNSS-Geräten (Global Navigation Satellite System) geben, die für Windows-Plattformen verwendet werden können, um die Anforderungen verschiedener Geräteebenen (niedrige Kosten, High-End, verschiedene Gerätetypen usw.) zu erfüllen. Um ein solch umfangreiches Ökosystem zu ermöglichen und die Anzahl von Tablets, Laptops und anderen Gerätetypen zu erhöhen, die einen GNSS-Chip zu niedrigeren Kosten enthalten können, erfordert Microsoft nicht, dass alle GNSS-Geräte den vollständigen Satz von Features unterstützen, die in der GNSS-Treiberreferenz beschrieben werden. Die folgende Tabelle bietet eine allgemeine Übersicht über die minimale Funktionalität, die für verschiedene Gerätetypen erforderlich ist, und welche Funktionen optional oder empfohlen werden.

Funktionalität Anforderung für alle Plattformen Spezifische Anforderungen für Telefone Hinweise
Genaues Melden des GNSS_DEVICE_CAPABILITIES Obligatorisch. Minimale Funktionalitätsanforderung
Unterstützung für MultipleFixSessions Optional Vom GNSS-Adapter nicht unterstützt
Unterstützung für MultipleAppSessions Empfohlen
Unterstützung für GNSS-Unterstützung (IHV-spezifisch) Empfohlen Obligatorisch.
Anfordern von Unterstützung für GNSS-Unterstützung über Microsoft (Verwendung der Agss_inject IOCTLs) Empfohlen
Unterstützung für die vollständige GNSS_FixData-Struktur Obligatorisch.
Einzelaufnahmesitzung Obligatorisch.
Native Unterstützung für zeitbasierte Nachverfolgungssitzungen Optional Falls unterstützt, muss es Unterstützung zum Ändern von Sitzungsparametern enthalten.
Native Unterstützung für entfernungsbasierte Nachverfolgungssitzungen Optional Falls unterstützt, muss es Unterstützung zum Ändern von Sitzungsparametern enthalten.
Letzte bekannte Sitzung Optional
Native Unterstützung für Geofencing Optional Empfohlen Nur kreisförmige Geofences erforderlich und unterstützt
Bereitstellen von ChipsatzInfo Obligatorisch. Verwenden des GNSS_ChipsetInfo
Melden von Fehlern Empfohlen Verwenden des GNSS_ErrorInfo
Berichte über NMEA Optional
Unterstützung von Fertigungstests (Trägerwelle oder Selbsttest) Optional
Steuern des Standorts der Steuerungsebene mit Integration in MBB Nur obligatorisch, wenn dies vom Mobilfunkanbieter verlangt wird Obligatorisch. Normalerweise von Mobilfunkanbietern in Geräten mit Sprachunterstützung erforderlich. Fast immer für Telefone erforderlich.
SUPL 1.0 Nur obligatorisch, wenn dies vom Mobilfunkanbieter verlangt wird Im Allgemeinen durch SUPL 2.0 ersetzt.

Umfasst die Implementierung des vollständigen Clients, der die Anforderungen des Mobilfunkanbieters erfüllt, die Konfiguration über den DDI, die Meldung von NI-Ereignissen an das Betriebssystem über den DDI und die Integration in MBB.
SUPL 2.x Nur obligatorisch, wenn dies vom Mobilfunkanbieter verlangt wird Obligatorisch. Normalerweise von Mobilfunkanbietern in Geräten mit Sprachunterstützung erforderlich. Fast immer für Telefone erforderlich.

Umfasst die Implementierung des vollständigen Clients, der die Anforderungen des Mobilfunkanbieters erfüllt, die Konfiguration über den DDI, die Meldung von NI-Ereignissen an das Betriebssystem über den DDI und die Integration in MBB.
UPL Nur obligatorisch, wenn dies vom Mobilfunkanbieter verlangt wird Muss nur für diese CDMA-Geräte unterstützt werden, die in China versendet werden, wenn dies vom Mobilfunkanbieter erforderlich ist.

Umfasst die Implementierung des vollständigen Clients, der die Anforderungen des Mobilfunkanbieters erfüllt, die Konfiguration über den DDI, die Meldung von NI-Ereignissen an das Betriebssystem über den DDI und die Integration in MBB.
GNSS_SetLocationServiceEnabled-Treiberbefehl Obligatorisch.
GNSS_SetLocationNIRequestAllowed-Treiberbefehl Nur obligatorisch, wenn SUPL vom Mobilfunkanbieter unterstützt und benötigt wird Das verlangen keine bekannten Mobilfunkanbieter mehr.
GNSS_ForceSatelliteSystem-Treiberbefehl Empfohlen Gut für Testzwecke. Einige Mobilfunkanbieter oder OEMs erfordern dies möglicherweise zum Testen.
GNSS_ForceOperationMode-Treiberbefehl Nur obligatorisch, wenn SUPL unterstützt wird Einige Mobilfunkanbieter müssen möglicherweise zu Testzwecken.
GNSS_ResetEngine-Treiberbefehl Obligatorisch. Zu Testzwecken
GNSS_ClearAgnssData-Treiberbefehl Obligatorisch. Zu Testzwecken
GNSS_SetNMEALogging-Treiberbefehl Optional Nur, wenn dies von Mobilfunkanbietern oder OEMs zu Testzwecken benötigt wird
GNSS_SetSuplVersion-Treiberbefehl Nur obligatorisch, wenn SUPL unterstützt wird Erforderlich für SUPL
GNSS_SetUplServerAccessInterval-Treiberbefehl Nur obligatorisch, wenn SUPL vom Mobilfunkanbieter unterstützt und benötigt wird Nur bei Bedarf des Mobilfunkanbieters
GNSS_SetNiTimeoutInterval-Treiberbefehl Nur obligatorisch, wenn SUPL vom Mobilfunkanbieter unterstützt und benötigt wird Nur bei Bedarf des Mobilfunkanbieters
GNSS_ResetGeofencesTracking Treiberbefehl Nur obligatorisch, wenn Geofencing unterstützt wird
GNSS_CustomCommand Treiberbefehl Optional