aus dem Netzwerk Insider August 2025
Irgendwie assoziiere ich den Begriff mit Komponenten in meinem Heizungskeller. Aber das meine ich nicht. WiLo (mit großem „L“) wird in [1] vorgestellt. Der Begriff steht für „Wi-Fi to LoRa“.
Über Wi-Fi bzw. WLAN wurde im Netzwerk Insider schon viel geschrieben und auch über LoRaWAN in [3]. Letzteres ist eine bekannte Funktechnik zur Vernetzung von Sensoren und Aktuatoren. Es holt seine Leistungsfähigkeit aus dem Frequenzbereich unter 1 GHz und aus der LoRa-Modulation. Mit geringsten Leistungen ist kilometerweite Datenübertagung möglich. Darüber hinaus bietet LoRaWAN ein Ökosystem aus verschiedenen Servern, das die Nutzung verschiedenster Endgeräte und Anwendungen überhaupt erst möglich macht.
Im genannten Artikel [1] geht es um Cross-Technology Communication (CTC). Das ist ein neues Forschungsfeld, das sich der Frage widmet, wie man ein Funkmodul für eine Funktechnik zum Empfangen und Senden von Daten einer anderen Funktechnik nutzen kann. In [1] geht es um den Empfang von LoRa-Daten mit handelsüblichen WLAN-Adaptern. Wenn Sie mehr über CTC erfahren wollen, lege ich Ihnen die Veröffentlichung [2] ans Herz.
Wozu könnte das gut sein? Die Autoren von [1] nennen als Beispiel eine abgeschiedene Umgebung, die per WLAN-Videokameras überwacht wird und in der zusätzlich verschiedene LoRaWAN-Sensoren vorhanden sind. Man braucht dort neben der WLAN-Infrastruktur auch ein LoRa-Gateway. Das könne man einsparen, wenn stattdessen die WLAN-APs die LoRa-Signale senden und empfangen könnten.
Damit eine CTC zwischen LoRaWAN und WLAN funktioniert, muss LoRa die WLAN-Frequenzen nutzen. Tatsächlich gibt es bereits seit 2017 mit dem LoRa Chip SX1280 von Semtech ein passendes Produkt. Im Gegensatz zu Lora unter 1 GHz unterstützt er Bandbreiten von bis zu 1625 kHz im 2,4-GHz-Band.
Wie lassen sich mit einem WLAN-Adapter LoRa-Signale erzeugen und aussenden? Hierzu versuche ich in meinen Worten zu erläutern, was ich aus der Lektüre von [1] verstanden habe.
Die LoRa-Modulation basiert auf sogenannten Chirps. Der Sender vergrößert während eines Chirps seine Frequenz kontinuierlich und linear. Dabei wird die gesamte zur Verfügung stehende Bandbreite – hier 1625 kHz – überstrichen. Sobald das obere Bandende erreicht ist, springt die Sendefrequenz an das untere Bandende. Je nachdem, bei welcher Frequenz ein Chirp beginnt, handelt es sich um eine binäre „0“ oder um eine „1“. Dies habe ich in Abbildung 1 anschaulich darzustellen versucht.
Die Unterträger eines OFDM-Signals lassen sich offensichtlich so modulieren, dass die sich aus ihrer Überlagerung ergebende Wellenform der eines Lora-Chirps entspricht. Dies gilt natürlich nur für die Nutzlast. Die Präambel des WLAN-Pakets lässt sich nicht beeinflussen. Sie wird vom LoRa-Empfänger als Rauschen interpretiert.
Der WLAN-Sender kann im Gegensatz zu einem LoRa-Sender keinen kontinuierlichen Chirp erzeugen. Stattdessen wird der Chirp aus vielen kurzen OFDM-Symbolen zusammengesetzt. Jedes Symbol wird so moduliert, dass jeweils nur ein Unterträger aktiv ist. Dies ist möglich, da sich jeder Unterträger dank Quadratur-Amplituden-Modulation (QAM) bezüglich Stärke und Phasenlage für die Dauer des Symbols individuell einstellen lässt.
Ein Symbol bei IEEE 802.11g dauert 4 µs (inklusive Guard-Intervall von 0,8 µs). Um ein LoRa-Symbol von 79 µs Dauer zu emulieren, muss der WLAN-Sender 20 OFDM-Symbole aussenden, wie in Abbildung 1 rechts angedeutet.

Abbildung 1: Vergleich LoRa zur mittels WLAN emulierten LoRa-Modulation
Immerhin konnten die Autoren von [1] die so emulierten LoRa-Signale in einer Entfernung von 500 Metern mit brauchbarer Qualität empfangen. Leider beschreibt die Arbeit nur diese Richtung. Die Gegenrichtung, also der Empfang von LoRa-Signalen mit WLAN-Adaptern, ist offensichtlich nicht möglich. Er würde bereits daran scheitern, dass man den LoRa-Chirp wohl kaum so modifizieren könnte, dass ein WLAN-Adapter ihn als Präambel erkennt.
In der Tat haben findige Forscher auch hierzu eine Lösung gefunden. Sie nennen es XFi [5]. Ihr Trick besteht darin, dass sie warten, bis ein LoRa-Frame mit einem WLAN-Paket kollidiert. Der WLAN-Adapter wird das durch die Kollision zerstörte WLAN-Paket verwerfen. Die aus Sicht von WLAN unlesbaren Daten befinden sich jedoch noch im Adapter und lassen sich auf andere Weise auswerten.
Das alles hat das Forschungs-Stadium bislang nicht verlassen. Und darüber hinaus wären noch viele andere Probleme zu lösen. So spricht ein LoRa-Endgerät kein IP; es kann letztlich nur über die LoRa-Infrastruktur kommunizieren (vgl. [3]), die man irgendwie mit dem WLAN verbinden müsste.
Viel einfacher ist es, ein passendes LoRa-Gateway aufzubauen. Damit lässt sich bidirektional kommunizieren, und die Performance ist deutlich besser, da Original-LoRa-Hardware zum Einsatz kommt. Darüber hinaus sind wir froh darüber, dass die marktgängigen LoRaWANs den Frequenzbereich bei 868 MHz nutzen und eben mit WLAN das Band teilen.
Fazit
WiLo scheint mir die Lösung für ein Problem zu sein, das noch zu suchen wäre. Sollten Sie am Ende tatsächlich auf dieses Problem stoßen, schauen Sie doch mal nach Produkten zu Wi-Fi HaLow [4].
Verweise
[1] „WiLo: Long-Range Cross-Technology Communication from Wi-Fi to LoRa“, Demin Gao et al., IEEE Transactions on Communications, September 2024, abgerufen unter: https://www.researchgate.net/publication/383692369_WiLo_Long-Range_Cross-Technology_Communication_From_Wi-Fi_to_LoRa
[2] „Cross-Technology Communication for the Internet of Things: A Survey“, Yuan He et al., ACM Comput. Surv. 55, 5, Article 89, Dezember 2022, abgerufen unter https://doi.org/10.1145/3530049
[3] „Schonmal was von LoRaWAN gehört?“. Sascha Förster, David Feuser, ComConsult GmbH, Netzwerk Insider August 2022, abgerufen unter: https://www.comconsult.com/schonmal-was-von-lorawan-gehoert/
[4] „Was gibt es Neues zu Wi-Fi HaLow?“, Dr. Joachim Wetzlar, ComConsult GmbH, Netzwerk Insider August 2024, abgerufen unter: https://www.comconsult.com/was-gibt-es-neues-zu-wi-fi-halow/
[5] „XFi: Cross-technology IoT Data Collection via Commodity WiFi“, R. Liu, Z. Yin, W. Jiang, T. He, 2020 IEEE 28th International Conference on Network Protocols (ICNP), Madrid, abgerufen unter: https://ieeexplore.ieee.org/document/9259363





