GNSS-Treiberanforderungen (Global Navigation Satellite System)

  • Artikel

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- 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 erforderliche Funktionalität für diesen Schnittstellenentwurf bereitstellt. UMDF 2.0 bietet 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 bevorzugen, wenn das frühere Framework auf der Plattform verfügbar ist.

 UMDF 2.0 ist auf allen Plattformen verfügbar, und IHVs werden 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 kann 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 zur GNSS-Treiberfunktion 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, um den Treiber dem Rest der Plattform auszusetzen. 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 letztgenannten Modus ist der GNSS-Treiber nicht auf das Vorhandensein mehrerer paralleler Anwendungssitzungen 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. Die Testanwendung und der GNSS-Adapter sind verschiedene Anwendungen, die an einen einzelnen GNSS-Treiber unterschiedliche Sitzungen gleichzeitig anfordern können. Wenn mehrere Anwendungssitzungen nicht unterstützt werden, muss der GNSS-Treiber entweder mit der Os Location Platform getestet werden, oder andernfalls sollte der Dienst, der die Betriebssystemstandortplattform hostt, beendet werden, um eine Störung der Testanwendung zu vermeiden.

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

    • Mindestens müssen GNSS-Treiber eine einzelne ShotFix-Sitzung unterstützen.

    • Treiber, die entfernungsbasierte Nachverfolgungsfixsitzungen unterstützen, müssen gleichzeitig eine einzelne Shot fix-Sitzung und eine entfernungsbasierte Nachverfolgungsfixsitzung unterstützen.

    • Treiber, die zeitbasierte Nachverfolgungsfixsitzungen unterstützen, müssen gleichzeitig eine einzelne Fixsitzung und eine zeitbasierte Nachverfolgungsfixsitzung unterstützen.

    • Treiber, die entfernungsbasierte Nachverfolgungsfixsitzungen und zeitbasierte Nachverfolgungsfixsitzungen unterstützen, müssen gleichzeitig eine einzelne Shot-Fixsitzung, eine entfernungsbasierte Nachverfolgungsfixsitzung und eine zeitbasierte Nachverfolgungsfixsitzung unterstützen.

    Treiberunterstützung für mehrere gleichzeitige Fixsitzungen.

    Ob der Treiber mehrere gleichzeitige Fixsitzungen unterstützt, wird durch einen klar definierten Treiberfunktionsparameter angegeben. Wenn ein Treiber mehrere parallele Fixsitzungen nicht explizit 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, befindet sich der Onus in der HLOS-Komponente, um sicherzustellen, dass mehrere GNSS-Anforderungen, die von den allgemeinen Anwendungen stammen, multiplext 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 erhalten, sodass IHVs vorerst nicht ermutigt 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 aus den oberen Schichten der Standortplattform zu ermöglichen, anstatt das Sitzungsmultimalxing 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 des Multiplexings zu verarbeiten, die Arbeitsspeicherauslastung im Treiber verringert wird, und der GNSS-Adapter nicht benötigt, um den Fall zu behandeln, in dem der HLOS eine Reihe von Fixsitzungen startet, die größer als vom GNSS-Treiber unterstützt werden. Unterschiedliche Geräteebenen und unterschiedliche Treiber würden eine unterschiedliche Anzahl gleichzeitiger Fixsitzungen unterstützen, sodass dieser Fall behandelt werden muss, was die Komplexität des GNSS-Adapters für alle Fälle erhöhen würde. 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 diese Funktionalität erforderlich ist.

    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. Außerhalb des Kontexts einer Fixsitzung können keine Positionsinformationen vom HLOS abgerufen werden. Der GNSS-Treiber muss die Änderung der Sitzungsparameter im Flug ermöglichen, um den Multiplexvorgang 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 Fixtypen (z. B. Nachverfolgung) unterstützen. Wie bereits erwähnt, bedeutet die Unterstützung zusätzlicher Fixtypen, dass der Treiber auch dann, wenn er mehrere Fixsitzungen desselben Typs nicht unterstützt, gleichzeitig mindestens eine Fixsitzung eines unterstützten Fixtyps 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 eine unerwartete Treiberentladung aufgrund eines Dienstabsturzes auf Benutzerebene erfolgt, 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 behandeln. Der Treiber sollte sich für die WDF_PNPPOWER_EVENT_CALLBACKS registrieren. EvtDeviceD0Entry-Rückruf (wird von WDF ausgelöst, 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 Systemleistungszuständen durchgeführt werden muss, muss entsprechend den Funktionen des GNSS-Geräts angepasst werden (unterstützt es entladene Vorgänge oder nicht), ob tatsächlich entladene Vorgänge aktiv sind und wie die Kommunikation zwischen dem System und dem GNSS-Gerät erfolgt. Im Allgemeinen sind die Erwartungen wie folgt:

    • Das GNSS-Gerät arbeitet unabhängig vom Netzbetriebszustand des Systems im niedrigstmöglichen Energiemodus, wenn keine aktiven Sitzungen oder ausgeladenen Vorgänge vorhanden sind.

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

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

    • Geräte, die den verbundenen Standbymodus unterstützen, haben weiterhin alle ausgeladenen Vorgänge aktiv, wenn das Gerät in den verbundenen Standby wechselt, und es wird erwartet, dass das GNSS-Gerät die Nachverfolgungsvorgänge so effizient wie möglich fortsetzt, und es wird erwartet, dass es Benachrichtigungen an die HLOS bereitstellt, falls die Bedingung eines Geofencetriggers oder eines Aktualisierungsupdates für die Nachverfolgungssitzung relevant ist. Wenn es keine ausgeladenen Vorgänge in einem Gerät gibt, das den verbundenen Standbymodus unterstützt, sollte das GNSS-Gerät in den niedrigsten möglichen Energiezustand wechseln, aber dennoch in der Lage sein, Standortsitzungsanforderungen vom HLOS zu lauschen. Bei 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 Energieverwaltungsverantwortung für Treiber.

  • Machtüberlegung: Der GNSS-Treiberstapel muss den Leistungsbedarf als primäres Entwurfsziel berücksichtigen und die Standard Prozessors so weit wie möglich wach halten. Alle erweiterten Funktionalitätsunterstützungen (z. B. verschiedene Fixtypen) müssen energieeffizient ausgeführt werden, z. B. Standard App-Prozessor nicht mehr aktiv sein muss als erforderlich, und die meisten Verarbeitungen können auf den Chipsatz/Prozessor mit geringer Leistung abgeladen werden. Sofern im HLOS nicht anders angegeben, muss der GNSS-Treiber in der Regel immer den Energieverbrauch als wichtigste Einschränkung behandeln und so konzipiert sein, dass er den normalen Betrieb 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 die erforderlichen energiebezogenen Hinweise zur Optimierung des Energieverbrauchs bereitzustellen. Für die Nachverfolgung, Das Geofencing und andere Funktionen, die eine lange Überwachung der allgegenwärtigen Position erfordern, muss der GNSS-Treiber bzw. die GNSS-Engine hardware/prozessoren mit geringer Leistung nutzen. Wenn eine solche Funktionalität mithilfe eines Brute-Force-Abfragemechanismus im Treiber implementiert werden muss oder im App-Prozessor implementiert werden muss, sollte sich der Treiber nicht für solche Vorgänge deklarieren. Dies ermöglicht es dem HLOS, entweder die Offenlegung solcher Funktionen auf den Rest der Plattform einzuschränken oder eine alternative Implementierung dieser Funktionen basierend auf anderen Plattformdiensten/Grundtypen zu verwenden.

  • Programmiersprache: Die GNSS-Treiberschnittstelle wird als C-Sprachheaderdatei bereitgestellt, die keine C++-spezifischen Sprachgrundsätze 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 einen ausstehenden IRP, der vom HLOS initiiert wird und dem Zweck dient, eine solche unerwünschte Benachrichtigung von der Treiberschicht 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 die 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 eine Zubehörkomponente für den Benutzermodus schreiben, die mit dem GNSS-Treiber über IHV-definierte private IOCTLs 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 der 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 dieser Komponenten und den Interaktionsmechanismus zwischen den IHV-Komponenten für Benutzermodus/Kernelmoduskomponenten nicht. Wenn der GNSS-Treiber als UMDF 2.0-Treiber mit Benutzermodus-IHV-Erweiterungen geschrieben wird, wird nicht empfohlen, da dieses Modell wahrscheinlich mehr Arbeitsspeicherauslastung erfordert.

    Die IHV-Erweiterungen im Benutzermodus müssen die folgenden Regeln erfüllen:

    • 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 beeinträchtigt 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 von Microsoft genehmigten autorisierten Aktivitäten ausführen, ohne dass die Betriebssystemplattform eine solche 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 die Unterstützung zum Ändern von Sitzungsparametern enthalten sein.
Native Unterstützung für entfernungsbasierte Nachverfolgungssitzungen Optional Falls unterstützt, muss die Unterstützung zum Ändern von Sitzungsparametern enthalten sein.
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