WLAN-Standort: Entfernung mit RTT

Sie können die WLAN-Standortfunktion des Wi-Fi RTT (Round-Trip-Time) API die Entfernung zu RTT-fähigen WLAN-Zugangspunkten in der Nähe und Geräte mit Wi-Fi Aware.

Wenn Sie die Entfernung zu drei oder mehr Zugangspunkten messen, können Sie Multilaterationsalgorithmus ermittle die Geräteposition, die am besten zu diesen Messungen. Das Ergebnis ist in der Regel auf 1 bis 2 Meter genau.

Mit dieser Genauigkeit können Sie detaillierte standortbezogene Dienste entwickeln, z. B. Indoor-Navigation, eine eindeutige Sprachsteuerung (z. B. „Aktivieren Sie diese leicht") und standortbasierten Informationen (z. B. "Gibt es Sonderangebote für für dieses Produkt?“).

Das anfordernde Gerät muss zum Messen keine Verbindung zu den Zugangspunkten herstellen Entfernung mit Wi-Fi RTT. Aus Datenschutzgründen kann nur das Gerät, von dem die Anfrage gesendet wurde, um die Entfernung zum Zugangspunkt zu bestimmen. haben die Zugangspunkte nicht diese Informationen. WLAN-RTT-Vorgänge sind für Apps im Vordergrund unbegrenzt, für Hintergrund-Apps gedrosselt werden.

WLAN-RTT und die damit verbundenen Fine-Time-Measurement (FTM-Funktionen) IEEE 802.11-2016-Standard festgelegt. Für WLAN-RTT wird die genaue Zeit benötigt Messung von FTM, da es die Entfernung zwischen zwei und messen, wie lange ein Paket für einen Umlauf zwischen der und die Zeit mit der Lichtgeschwindigkeit multiplizieren.

Android 15 (API-Level 35) unterstützt jetzt nicht mehr Trigger, IEEE 802.11az (NTB).

Implementierungsunterschiede je nach Android-Version

WLAN-RTT wurde mit Android 9 (API-Level 28) eingeführt. Bei Verwendung dieses Protokolls Zur Bestimmung der Position eines Geräts durch Multilateration bei laufenden Geräten Unter Android 9 benötigst du Zugang zu vordefinierten Zugangspunkten Daten in Ihrer App. Es liegt an Ihnen zu entscheiden, wie diese Daten gespeichert und abgerufen werden.

Auf Geräten mit Android 10 (API-Level 29) und höher können AP-Standortdaten dargestellt als ResponderLocation -Objekte, einschließlich Breitengrad, Längengrad und Höhe. Für WLAN-RTT-ZPs, die support Location Configuration Information/Location Civic Report (LCI/LCR-Daten) gibt das Protokoll während des Vorgangs ein ResponderLocation-Objekt zurück. Bereichsbestimmung.

Mit dieser Funktion können Apps APs direkt nach ihrer Position fragen. und müssen diese Informationen nicht im Voraus speichern. Ihre App kann also AP zu finden und ihre Positionen zu ermitteln, auch wenn diese zuvor nicht bekannt waren. beispielsweise wenn Nutzende ein neues Gebäude betreten.

IEEE 802.11az-NTB-Range-Range-Unterstützung ist auf Geräten mit Android 15 verfügbar (API-Level 35) und höher. Wenn das Gerät also IEEE 802.11az unterstützt, NTB-Antwortmodus (gekennzeichnet durch WifiRttManager.CHARACTERISTICS_KEY_BOOLEAN_STA_RESPONDER) kann Ihre App sowohl IEEE 802.11mc- als auch IEEE 802.11az-fähige APs mit einem einzigen Bereichsanfrage. Die RangingResult API wurde erweitert, um Informationen zur Verfügung zu stellen über den Mindest- und Höchstwert, der für das Intervall zwischen Entfernungsmessungen und behält das genaue Intervall in der Steuerung deiner App über.

Voraussetzungen

  • Auf der Hardware des Geräts, von dem die Entfernungsanfrage gesendet wird, muss Folgendes implementiert werden: 802.11-2016 FTM-Standard oder 802.11az-Standard (nicht Trigger-basierte Bereichserkennung)
  • Auf dem Gerät, das die Entfernungsanfrage sendet, muss Android 9 (API-Level) ausgeführt werden. 28) oder höher. Nicht Triggerbasierte Bereichserkennung gemäß IEEE 802.11az auf Geräten aktiviert mit Android 15 (API-Level 35) oder höher.
  • Auf dem Gerät, von dem die Standortermittlungsanfrage gesendet wird, müssen Standortdienste aktiviert sein die WLAN-Suche aktiviert ist (unter Einstellungen > Standort).
  • Wenn die App, die die Anfrage zur Standortermittlung erstellt, Android 13 (API-Level 33) oder höher benötigen, NEARBY_WIFI_DEVICES Berechtigung. Wenn eine solche App auf eine frühere Android-Version ausgerichtet ist, haben ACCESS_FINE_LOCATION Berechtigung erteilen.
  • Die App muss den Bereich der Zugangspunkte abfragen, während sie sichtbar oder in einen Dienst im Vordergrund. Die App kann nicht auf Standortinformationen aus der Hintergrund.
  • Der Zugangspunkt muss den FTM-Standard IEEE 802.11-2016 oder IEEE implementieren 802.11az-Standard (nicht Trigger-basierte Bereichserkennung)

Einrichten

Führen Sie die folgenden Schritte aus, um Ihre App für die Verwendung von WLAN-RTT einzurichten.

1. Berechtigungen anfordern

Fordern Sie im Manifest Ihrer App die folgenden Berechtigungen an:

<uses-permission android:name="android.permission.ACCESS_WIFI_STATE" />
<uses-permission android:name="android.permission.CHANGE_WIFI_STATE" />
<!-- If your app targets Android 13 (API level 33)
     or higher, you must declare the NEARBY_WIFI_DEVICES permission. -->
<uses-permission android:name="android.permission.NEARBY_WIFI_DEVICES"
                 <!-- If your app derives location information from Wi-Fi APIs,
                      don't include the "usesPermissionFlags" attribute. -->
                 android:usesPermissionFlags="neverForLocation" />
<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION"
                 <!-- If any feature in your app relies on precise location
                      information, don't include the "maxSdkVersion"
                      attribute. -->
                 android:maxSdkVersion="32" />

Die Berechtigungen NEARBY_WIFI_DEVICES und ACCESS_FINE_LOCATION sind gefährlich Berechtigungen erforderlich sind, sodass Sie sie jedes Mal zur Laufzeit anfordern müssen, wenn der Nutzer einen RTT-Suchvorgang. Ihre App muss die Berechtigung des Nutzers anfordern, Berechtigung, wenn die Berechtigung nicht bereits gewährt wurde. Weitere Informationen zu Laufzeitberechtigungen finden Sie unter App-Berechtigungen anfordern

2. Prüfen, ob das Gerät WLAN-RTT unterstützt

Um zu prüfen, ob das Gerät WLAN-RTT unterstützt, verwende die PackageManager API:

Kotlin

context.packageManager.hasSystemFeature(PackageManager.FEATURE_WIFI_RTT)

Java

context.getPackageManager().hasSystemFeature(PackageManager.FEATURE_WIFI_RTT);

3. Verfügbarkeit von WLAN-RTT prüfen

WLAN-RTT ist möglicherweise auf dem Gerät vorhanden, aber nicht verfügbar, weil der Nutzer hat WLAN deaktiviert. Je nach Hardware- und Firmwarefunktion Geräte unterstützen WLAN-RTT möglicherweise nicht, wenn SoftAP oder Tethering verwendet wird. Zur Überprüfung ob WLAN-RTT verfügbar ist: isAvailable()

Die Verfügbarkeit von WLAN-RTT kann sich jederzeit ändern. Deine App sollte eine BroadcastReceiver zum Empfangen von ACTION_WIFI_RTT_STATE_CHANGED die gesendet wird, wenn sich die Verfügbarkeit ändert. Wenn deine App die Übertragung empfängt sollte die App den aktuellen Verfügbarkeitsstatus prüfen und entsprechend reagieren.

Beispiel:

Kotlin

val filter = IntentFilter(WifiRttManager.ACTION_WIFI_RTT_STATE_CHANGED)
val myReceiver = object: BroadcastReceiver() {

    override fun onReceive(context: Context, intent: Intent) {
        if (wifiRttManager.isAvailable) {
            …
        } else {
            …
        }
    }
}
context.registerReceiver(myReceiver, filter)

Java

IntentFilter filter =
    new IntentFilter(WifiRttManager.ACTION_WIFI_RTT_STATE_CHANGED);
BroadcastReceiver myReceiver = new BroadcastReceiver() {
    @Override
    public void onReceive(Context context, Intent intent) {
        if (wifiRttManager.isAvailable()) {
            …
        } else {
            …
        }
    }
};
context.registerReceiver(myReceiver, filter);

Weitere Informationen finden Sie unter Nachrichten an alle.

Bereichsabfrage erstellen

Eine Anfrage zur Bereichserkennung (RangingRequest) wird erstellt. indem Sie eine Liste von ZPs oder Wi-Fi Aware-Peers angeben, zu denen ein Bereich angefordert wird. In einem Anfrage zur Bereichserkennung; werden die Entfernungen zu allen Geräten gemessen und zurückgegeben.

Eine Anfrage kann beispielsweise den Parameter addAccessPoint() , um einen Zugangspunkt anzugeben, zu dem die Entfernung gemessen werden soll:

Kotlin

val req: RangingRequest = RangingRequest.Builder().run {
    addAccessPoint(ap1ScanResult)
    addAccessPoint(ap2ScanResult)
    build()
}

Java

RangingRequest.Builder builder = new RangingRequest.Builder();
builder.addAccessPoint(ap1ScanResult);
builder.addAccessPoint(ap2ScanResult);

RangingRequest req = builder.build();

Ein Zugangspunkt wird durch seine ScanResult-Objekt, bei dem es sich um erhalten durch Aufrufen von WifiManager.getScanResults() Sie können addAccessPoints(List<ScanResult>) um mehrere Zugangspunkte gleichzeitig hinzuzufügen.

ScanResult-Objekte können sowohl IEEE 802.11mc (is80211mcResponder()) als auch Nicht Trigger-basierte Bereichserkennung gemäß IEEE 802.11az (is80211azNtbResponder()) APs. Geräte, die IEEE 802.11az NTB-Bereichsmessung unterstützen, führen entweder 802.11mc oder 802.11az-Bereich, abhängig von den Funktionen des ZP. Der Standardwert ist 802.11az, unterstützt der AP beides. Geräte, die IEEE 802.11az nicht unterstützen, mit dem IEEE 802.11mc-Protokoll.

Genauso kann mit einer Anfrage zur Bereichserkennung ein Wi-Fi Aware-Peer über dessen MAC-Adresse hinzugefügt werden. oder seine PeerHandle-Adresse mit die addWifiAwarePeer(MacAddress peer) und addWifiAwarePeer(PeerHandle peer) . Weitere Informationen zur Suche nach ähnlichen Geräten mit Wi-Fi Aware finden Sie in der Wi-Fi Aware-Dokumentation.

Bereichsauswahl anfordern

Eine Anwendung gibt mithilfe der Methode WifiRttManager.startRanging() und Folgendes angeben: a RangingRequest zum Angeben des wird ein Executor-Vorgang zur Angabe von Callback-Kontext und eine RangingResultCallback. um die Ergebnisse zu erhalten.

Beispiel:

Kotlin

val mgr = context.getSystemService(Context.WIFI_RTT_RANGING_SERVICE) as WifiRttManager
val request: RangingRequest = myRequest
mgr.startRanging(request, executor, object : RangingResultCallback() {

    override fun onRangingResults(results: List<RangingResult>) { … }

    override fun onRangingFailure(code: Int) { … }
})

Java

WifiRttManager mgr =
      (WifiRttManager) Context.getSystemService(Context.WIFI_RTT_RANGING_SERVICE);

RangingRequest request ...;
mgr.startRanging(request, executor, new RangingResultCallback() {

  @Override
  public void onRangingFailure(int code) { … }

  @Override
  public void onRangingResults(List<RangingResult> results) { … }
});

Der Ranging-Vorgang wird asynchron durchgeführt und die Ranging-Ergebnisse werden zurückgegeben, die in einem der RangingResultCallback:

  • Wenn der gesamte Bereichserkennungsvorgang fehlschlägt, onRangingFailure Callback wird mit einem Statuscode ausgelöst, der unter RangingResultCallback Ein solcher Fehler kann auftreten, wenn der Dienst keinen Bereichserkennungsvorgang ausführen kann. aktiviert werden, z. B. weil WLAN deaktiviert ist, weil die Anwendung zu viele Bereichserkennungsvorgänge angefordert und gedrosselt wird. Berechtigungsproblem.
  • Nach Abschluss des Bereichserkennungsvorgangs wird der onRangingResults Callback wird mit einer Liste von Ergebnissen ausgelöst, die mit der Liste der -Anfragen – ein Ergebnis für jede Anfrage. Die Reihenfolge der Ergebnisse unbedingt mit der Reihenfolge der Anfragen übereinstimmen. Beachten Sie, dass der Bereichserkennungsvorgang möglicherweise aber jedes Ergebnis kann immer noch darauf hinweisen, dass zu messen.

Bereichsergebnisse interpretieren

Jedes der Ergebnisse, die vom onRangingResults Callback wird durch einen RangingResult angegeben. -Objekt enthält. Gehen Sie bei jeder Anfrage so vor:

1. Anfrage identifizieren

Identifizieren Sie den Antrag anhand der Informationen, die beim Erstellen des RangingRequest: Meistens eine MAC-Adresse im ScanResult, die einen Zugriff identifiziert Punkt. Die MAC-Adresse kann mithilfe der Methode getMacAddress() .

Die Liste der Bereichsergebnisse kann in einer anderen Reihenfolge als die der Peers sein (Zugriff Punkte) angegeben werden. Verwenden Sie daher die MAC-Adresse und nicht die Reihenfolge der Ergebnisse.

2. Ermitteln, ob die einzelnen Messungen erfolgreich waren

Um festzustellen, ob eine Messung erfolgreich war, verwenden Sie das getStatus() . Alle Werte außer STATUS_SUCCESS zeigt einen Fehler an. Ein Fehler bedeutet, dass alle anderen Felder dieses Ergebnisses (mit Ausnahme der oben genannten Anforderungsidentifikation) ungültig sind und die entsprechenden Die Methode get* schlägt fehl mit: IllegalStateException-Ausnahme.

3. Ergebnisse für jede erfolgreiche Messung abrufen

Für jede erfolgreiche Messung (RangingResult) können Sie Ergebnisse abrufen -Werte durch die entsprechenden get-Methoden an:

Android-Geräte, die WiFi-RTT unterstützen

In den folgenden Tabellen sind einige Smartphones, Zugangspunkte sowie Geräte für den Einzelhandel, die Lagerhaltung und das Distributionszentrum aufgeführt die WLAN-RTT unterstützen. Das ist alles andere als umfangreich. Wir empfehlen Ihnen, wenden Sie sich einfach an uns um Ihre RTT-fähigen Produkte hier aufzulisten.

Zugangspunkte

Hersteller und Modell Supportdatum
Nest Wifi Pro (Wi-Fi 6E) Unterstützt
Compulab WILD AP Unterstützt
Google Wifi Unterstützt
Google Nest WLAN-Router Unterstützt
Google Nest Wifi-Zugangspunkt Unterstützt
Aruba AP-635 Unterstützt
Cisco 9130 Unterstützt
Cisco 9136 Unterstützt
Cisco 9166 Unterstützt
Cisco 9164 Unterstützt
Aruba AP-505 Unterstützt
Aruba AP-515 Unterstützt
Aruba AP-575 Unterstützt
Aruba AP-518 Unterstützt
Aruba AP-505H Unterstützt
Aruba AP-565 Unterstützt
Aruba AP-535 Unterstützt

Smartphones

Hersteller und Modell Android-Version
Pixel 6 9.0+
Pixel 6 Pro 9.0+
Pixel 5 9.0+
Pixel 5a 9.0+
Pixel 5a (5G) 9.0+
Xiaomi Mi 10 Pro 9.0+
Xiaomi Mi 10 9.0+
Xiaomi Redmi Mi 9T Pro 9.0+
Xiaomi Mi 9T 9.0+
Xiaomi Mi 9 9.0+
Xiaomi Mi Note 10 9.0+
Xiaomi Mi Note 10 Lite 9.0+
Xiaomi Redmi Note 9S 9.0+
Xiaomi Redmi Note 9 Pro 9.0+
Xiaomi Redmi Note 8T 9.0+
Xiaomi Redmi Note 8 9.0+
Xiaomi Redmi K30 Pro 9.0+
Xiaomi Redmi K20 Pro 9.0+
Xiaomi Redmi K20 9.0+
Xiaomi Redmi Note 5 Pro 9.0+
Xiaomi Mi CC9 Pro 9.0+
LG G8X ThinQ 9.0+
LG V50S ThinQ 9.0+
LG V60 ThinQ 9.0+
LG V30 9.0+
Samsung Galaxy Note 10+ 5G 9.0+
Samsung Galaxy S20+ 5G 9.0+
Samsung Galaxy S20+ 9.0+
Samsung Galaxy S20 5G 9.0+
Samsung Galaxy S20 Ultra 5G 9.0+
Samsung Galaxy S20 9.0+
Samsung Galaxy Note 10+ 9.0+
Samsung Galaxy Note 10 5G 9.0+
Samsung Galaxy Note 10 9.0+
Samsung A9 Pro 9.0+
Google Pixel 4 XL 9.0+
Google Pixel 4 9.0+
Google Pixel 4a 9.0+
Google Pixel 3 XL 9.0+
Google Pixel 3 9.0+
Google Pixel 3a XL 9.0+
Google Pixel 3a 9.0+
Google Pixel 2 XL 9.0+
Google Pixel 2 9.0+
Google Pixel 1 XL 9.0+
Google Pixel 1 9.0+
Poco X2 9.0+
Sharp Aquos R3 SH-04L 9.0+

Geräte für Einzelhandel, Lagerung und Vertrieb

Hersteller und Modell Android-Version
Zebra PS20 10,0+
Zebra TC52/TC52HC 10,0+
Zebra TC57 10,0+
Zebra TC72 10,0+
Zebra TC77 10,0+
Zebra MC93 10,0+
Zebra TC8300 10,0+
Zebra VC8300 10,0+
Zebra EC30 10,0+
Zebra ET51 10,0+
Zebra ET56 10,0+
Zebra L10 10,0+
Zebra CC600/CC6000 10,0+
Zebra MC3300x 10,0+
Zebra MC330x 10,0+
Zebra TC52x 10,0+
Zebra TC57x 10,0+
Zebra EC50 (LAN und HC) 10,0+
Zebra EC55 (WAN) 10,0+
WT6300 10,0+
Skorpio X5 10,0+