LR-FHSS in LoRaWAN: Frequenzsprünge, Netzkapazität und regionale Datenraten
LR-FHSS taucht in Datenblättern häufig neben LoRa und FSK auf. Der Name klingt nach einer neuen Netzart, tatsächlich ist Long Range Frequency Hopping Spread Spectrum eine zusätzliche Modulation innerhalb der LoRaWAN Regional Parameters. Ein Endgerät kann damit bestimmte Uplinks über viele schmale Frequenzabschnitte verteilen. Network Server, Join, Schlüssel, MAC-Frames und Anwendungen bleiben Teil derselben LoRaWAN-Architektur.
Der wichtigste Nutzen liegt nicht in einer pauschal größeren Reichweite, sondern in der Uplink-Kapazität und Störfestigkeit bestimmter Netze. Viele schwer erreichbare Geräte können mit wenigen Gateways besser skalieren, weil Kollisionen nicht mehr zwangsläufig ein vollständiges Paket zerstören. Dafür sind die Datenraten niedrig, die Airtime bleibt relevant und jede beteiligte Komponente muss LR-FHSS tatsächlich unterstützen.
Kurz zusammengefasst: LR-FHSS ist eine optionale LoRaWAN-Uplink-Modulation. Das Paket springt während der Übertragung über pseudozufällig gewählte schmale Frequenzen. Das kann Kapazität und Robustheit in großen, uplinklastigen Netzen verbessern. Downlinks verwenden weiterhin die standardmäßigen LoRaWAN-Datenraten; ein LR-FHSS-fähiges Endgerät allein genügt nicht für einen funktionierenden Rollout.
LoRa und LR-FHSS gehören zur selben LoRaWAN-Familie
| Merkmal | LoRa CSS | LR-FHSS in LoRaWAN |
|---|---|---|
| Funkprinzip | Chirp Spread Spectrum | schnelles Frequency Hopping mit schmalen Teilübertragungen |
| Frequenz während eines Pakets | bleibt im gewählten LoRa-Kanal | wechselt nach pseudozufälliger Folge |
| Richtung | Uplink und Downlink | aktuell als Uplink-Datenrate verwendet |
| Stärke | bewährte Reichweite und variable Datenraten | hohe Spektrumeffizienz und Kollisionsrobustheit bei niedriger Rate |
| Typischer Engpass | lange Airtime bei hohen Spreading Factors | lange Uplinkdauer und erforderliche Ende-zu-Ende-Unterstützung |
Die LoRa Alliance führte LR-FHSS-Datenraten mit RP2-1.0.2 zunächst für EU868, US915 und AU915 ein. Die damalige Veröffentlichung zu den neuen Regional Parameters stellt ausdrücklich klar, dass LR-FHSS nur im Uplink eingesetzt wird und der Downlink die üblichen Datenraten nutzt. Die Funktion war optional, sodass ältere Geräte und Netze weiterarbeiten konnten.
Für ein aktuelles Projekt ist die historische Einführung nur der Ausgangspunkt. Maßgeblich sind die aktuellen Regional Parameters RP002-1.0.5 und das tatsächlich implementierte Regionalprofil von Gerät, Gateway und Network Server. Datenratenindizes, Kanalraster und zulässige Leistung unterscheiden sich regional. Eine DR-Nummer ohne Regionsangabe ist deshalb unvollständig.
Wie ein LR-FHSS-Uplink aufgebaut ist
Ein LR-FHSS-Paket besteht aus einem robust übertragenen Physical Header und einer in Fragmente aufgeteilten Nutzlast. Header und Payload wechseln nach einer vom Gerät pseudozufällig gewählten Folge ihre Trägerfrequenz innerhalb der für die Datenrate definierten Bandbreite. Der Header teilt dem Empfänger unter anderem die nötigen Parameter für die Rekonstruktion mit. Mehrere Headerkopien erhöhen die Chance, dass mindestens eine davon erkannt wird.
Die offizielle RP002-1.0.3-Fassung mit der LR-FHSS-PHY-Beschreibung nennt für die implementierten niedrigen Raten 162 und 325 Bit pro Sekunde sowie Coding Rates von 1/3 beziehungsweise 2/3. Payload-Fragmente wechseln dort alle 102,4 Millisekunden die Frequenz, Headerteile alle 233,472 Millisekunden. Diese Werte erklären das Prinzip, ersetzen für eine neue Planung aber nicht die Prüfung der aktuellen regionalen Fassung.
Frequency Hopping verteilt das Kollisionsrisiko
Bei einem herkömmlichen Paket auf einer Frequenz kann ein starker zeitgleicher Störer einen großen Teil der Übertragung überdecken. LR-FHSS verteilt Header und Nutzlast über viele schmale Frequenzabschnitte. Eine Kollision betrifft dadurch häufig nur einzelne Teile. Vorwärtsfehlerkorrektur und wiederholte Headerinformationen können dem Empfänger ermöglichen, das Paket trotz solcher Verluste zu rekonstruieren.
Das ist kein Schutz gegen jede Störung. Breitbandiges Rauschen, ein zu schwaches Signal, ungünstige Antennen oder ein überlasteter Empfänger bleiben problematisch. Auch mehrere LR-FHSS-Pakete können sich in Teilen überschneiden. Der Vorteil ist statistisch: In einem großen Netz verteilt sich die Wahrscheinlichkeit schädlicher Vollkollisionen anders als bei langen Übertragungen auf einem einzigen Kanal.
LR-FHSS passt besonders gut zu
- großen Flotten mit überwiegend kleinen oder mittleren Uplinks
- schwer erreichbaren Geräten bei geringer Gatewaydichte
- Netzen, in denen niedrige LoRa-Datenraten viel Kanalzeit belegen
- Regionen mit Dwell-Time-Vorgaben und passenden LR-FHSS-Profilen
- terrestrischen oder nicht-terrestrischen Architekturen mit langer Uplinkstrecke
Reichweite und Kapazität sind zwei verschiedene Aussagen
Die technische LR-FHSS-Übersicht der LoRa Alliance beschreibt eine zum LoRa-Uplink vergleichbare Reichweite und hebt hohe Spektrumeffizienz sowie Kapazität bei wenigen Gateways und vielen schwer erreichbaren Geräten hervor. Daraus folgt nicht, dass LR-FHSS an jedem Standort weiter reicht als jeder LoRa-Spreading-Factor. Linkbudget, Empfänger, Antenne, Störung und Region bleiben maßgeblich.
Kapazität beschreibt, wie viele Übertragungen ein Netz unter festgelegten Annahmen verarbeiten kann. Reichweite beschreibt, ob eine einzelne Verbindung genügend Linkmarge besitzt. LR-FHSS kann die Kapazität in einem kollisionsgeprägten Uplink-Szenario deutlich verbessern, während ein konkretes Gerät am Rand der Abdeckung trotzdem keine stabile Verbindung hat. Beide Größen müssen getrennt gemessen werden.
Die zwei niedrigen Bitraten haben unterschiedliche Robustheit
Bei 162 Bit pro Sekunde wird die Nutzlast stärker redundant codiert als bei 325 Bit pro Sekunde. Das erhöht die Robustheit, verlängert aber die Übertragung. Die schnellere Variante reduziert Airtime, benötigt jedoch bessere Empfangsbedingungen. Auch die Zahl der Headerwiederholungen ist mit der Coding Rate verknüpft. Die Auswahl ist deshalb ein Link- und Kapazitätskompromiss, kein einfacher Qualitätsregler.
Die nominelle Bitrate darf nicht mit dem effektiven Anwendungssatz verwechselt werden. Physical Header, Fehlerkorrektur, Frequenzwechsel, LoRaWAN MAC Header und mögliche Wiederholungen verbrauchen ebenfalls Zeit. Für Batteriekalkulation und Netzlast zählt die gemessene Sendedauer eines realen Frames mit der vorgesehenen Nutzlast.
Der Downlink bleibt ein eigener Engpass
LR-FHSS erhöht die Uplinkoptionen, schafft aber keinen LR-FHSS-Downlink. Antworten, MAC-Kommandos, bestätigte Frames und Konfigurationen müssen über die normalen LoRaWAN-Empfangsfenster und Downlinkdatenraten zurück. Ein stark uplinklastiges Messnetz kann davon profitieren; ein Steuerungssystem mit vielen Downlinks gewinnt wesentlich weniger.
Auch bestätigte Uplinks sollten sparsam eingesetzt werden. Wenn jedes erfolgreiche LR-FHSS-Paket ein Gateway-ACK erzwingt, kann die neue Uplinkkapazität an regulatorischen Sendegrenzen oder Gatewaykonflikten im Downlink enden. Die Wahl der Geräteklasse A, B oder C verändert die Empfangsgelegenheiten, aber nicht die verfügbare Funkzeit des Gateways.
Hardwareunterstützung muss durchgängig vorhanden sein
- Endgeräte-Funkchip und Firmware erzeugen die regional korrekten LR-FHSS-Frames
- Gateway-Concentrator oder Baseband demoduliert gleichzeitige LR-FHSS-Übertragungen
- Packet Forwarder übermittelt Modulation und Metadaten korrekt
- Network Server kennt die LR-FHSS-Datenraten des Regionalprofils
- Geräteprofil, ADR und Monitoring stellen die Modulation verständlich dar
- Testwerkzeuge und Paketaufzeichnung können LR-FHSS-Ereignisse unterscheiden
Ein modernes Gatewaygehäuse oder eine aktuelle Serverversion beweist diese Kette nicht. Bei manchen Installationen benötigt der Concentrator eine bestimmte Hardwaregeneration oder Firmware. Auch ein Netzwerkserver kann Frames verwerfen, wenn das Geräteprofil die Datenrate nicht kennt. Für die Abnahme ist daher ein echter Uplink vom Zielgerät bis zur Anwendung erforderlich.
Die LoRa-Gateway-Grundlagen erläutern die Rolle des Gateways als Funkbrücke. Bei LR-FHSS kommt hinzu, dass der Empfänger die verteilten Teilübertragungen demodulieren und zusammenführen muss. Ein einfacher RF-Repeater oder ein Gateway ohne passenden Baseband-Support kann diese Aufgabe nicht nachträglich im Server ersetzen.
ADR kann LR-FHSS auswählen, wenn die gesamte Kette es kennt
Adaptive Data Rate verwaltet einen Datenratenindex und Sendeleistung, keine abstrakte Modulationspräferenz. Ist LR-FHSS im regionalen Profil und in beiden Endpunkten unterstützt, kann ein Network Server passende Datenraten anweisen. Er benötigt dafür eine belastbare Linkhistorie und muss wissen, wie Übergänge zwischen LoRa und LR-FHSS umgesetzt werden.
Der LoRaWAN-ADR-Algorithmus ist serverseitig nicht vollständig normiert. Ein Produkt kann LR-FHSS daher unterstützen, ohne es automatisch sinnvoll auszuwählen. Für mobile Geräte, selten sendende Sensoren oder neue Gateways sind feste Startregeln und ein Rückweg zu einer bekannten LoRa-Datenrate häufig ebenso wichtig wie die Optimierung.
LR-FHSS ändert den MAC-Frame nicht
Oberhalb der physischen Übertragung bleibt der LoRaWAN PHYPayload mit MHDR, MACPayload und MIC erhalten. Schlüssel, Frame Counter, FPort und Anwendungsverschlüsselung folgen dem verwendeten LoRaWAN-Profil. LR-FHSS ist damit keine Abkürzung um die MAC-Schicht und schafft auch keinen zusätzlichen Anwendungskanal.
Diese Trennung erleichtert die Integration: Eine Anwendung kann denselben Payload-Codec verwenden, egal ob ein Uplink per LoRa oder LR-FHSS ankam. Im Betrieb sollten Modulation, Datenrate, Frequenzfolge und Gatewayempfang trotzdem als Metadaten verfügbar sein. Der Artikel zur LoRaWAN-Frame-Struktur zeigt die unveränderten MAC-Bestandteile.
Energiebedarf muss am realen Gerät gemessen werden
LR-FHSS bewahrt die grundsätzliche Low-Power-Ausrichtung, doch die niedrige Bitrate führt zu langen Sendephasen. Ob die Gesamtenergie besser oder schlechter als bei LoRa ausfällt, hängt von Nutzlast, Sendeleistung, erfolgreicher Erstübertragung, Wiederholungen und benötigter Linkmarge ab. Eine theoretische Airtime-Tabelle ersetzt keine Strommessung am Zielmodul.
Relevant sind außerdem Spitzenstrom und Spannungsabfall. Batterien mit hoher Innenimpedanz können bei einer langen Hochleistungsübertragung stärker einbrechen als im kurzen Labortest. Temperatur und Batterialterung gehören deshalb in die Messreihe. Für Energy-Harvesting-Geräte muss die maximale Folge mehrerer Uplinks betrachtet werden, nicht nur der Durchschnitt eines Tages.
FUOTA profitiert nicht automatisch von LR-FHSS
Firmwareverteilung besteht überwiegend aus Downlinks. Weil LR-FHSS in LoRaWAN aktuell nur für den Uplink verwendet wird, beschleunigt es die eigentlichen Firmwarefragmente nicht. Es kann allenfalls Statusmeldungen oder andere Uplinks in einem gemischten Netz effizienter übertragen. Die Planung von LoRaWAN FUOTA bleibt durch Multicast-Datenrate, Gateway-Sendezeit und Geräteklasse bestimmt.
Dasselbe gilt für Aktorik: Ein dichter Sensorschwarm kann seine Messwerte effizienter hochladen, aber Befehle an viele Geräte bleiben Downlinkverkehr. Eine Bewertung sollte daher Uplink- und Downlinkanteil getrennt angeben, statt aus einer allgemeinen Paketanzahl auf den Nutzen zu schließen.
Netzplanung mit mehreren Gerätegruppen
| Gruppe | Mögliche Ausgangsstrategie | Begründung |
|---|---|---|
| gute Abdeckung, kurze Uplinks | schnelle LoRa-Datenrate | kurze Airtime und breite Geräteunterstützung |
| tiefe Indoor-Lage, viele Geräte | LR-FHSS-Pilot | Kapazität und Teilkollisionsrobustheit prüfen |
| seltene mobile Uplinks | konservative Startdatenrate | Linkhistorie für automatische Auswahl ist begrenzt |
| viele Downlinks oder Steuerbefehle | Downlink zuerst dimensionieren | LR-FHSS löst den dominanten Engpass nicht |
| ältere Gateways | LoRa beibehalten oder Hardware erneuern | Serverupdate allein ergänzt keine Demodulation |
Eine Flotte muss nicht einheitlich umgestellt werden. Gute Links können auf schnellen LoRa-Datenraten bleiben, während eine klar definierte Randgruppe LR-FHSS nutzt. Diese Segmentierung verhindert, dass eine neue Modulation zum Selbstzweck wird. Sie erleichtert außerdem den Vergleich von Paketquote, Airtime, Energie und Gatewayauslastung unter denselben Standortbedingungen.
So wird LR-FHSS im Feld geprüft
- Regionalprofil und darin verfügbare LR-FHSS-Datenraten festlegen
- Support von Funkchip, Firmware, Gateway-Baseband, Forwarder und Server nachweisen
- repräsentative Geräte mit LoRa und LR-FHSS am selben Standort messen
- Paketquote, Linkmarge, Airtime, Strom und Gateway-Demodulationslast vergleichen
- gleichzeitige Übertragungen und schmal- sowie breitbandige Störungen untersuchen
- Downlinkantworten, MAC-Kommandos und Rückfall auf LoRa testen
- Pilotgruppe über Batterie-, Temperatur- und Lastzyklen beobachten
Ein erfolgreicher Einzel-Uplink beweist nur Kompatibilität. Für die Kapazitätsaussage braucht es viele zeitlich überlappende Geräte und realistische Verkehrsprofile. Für die Reichweitenaussage braucht es Randstandorte, Wetter- oder Gebäudeeinflüsse und wiederholte Messungen. Erst beide Versuche zusammen zeigen, ob LR-FHSS das konkrete Netz verbessert.
Wann klassische LoRa-Datenraten besser passen
Bei wenigen Geräten, guter Abdeckung und kurzen Uplinks ist eine schnelle LoRa-Datenrate oft einfacher und energieeffizient. Dasselbe gilt, wenn vorhandene Gateways LR-FHSS nicht demodulieren, Interoperabilität mit älteren Netzen wichtig ist oder die Anwendung viele Downlinks benötigt. Zusätzliche Optionen sind nur dann wertvoll, wenn sie einen gemessenen Engpass lösen.
LR-FHSS erweitert LoRaWAN sinnvoll für massive, uplinkgeprägte Netze und anspruchsvolle Funkstrecken. Die robuste Entscheidung lautet aber nicht ’neuer ist besser‘. Sie lautet: Region prüfen, komplette Signalkette nachweisen, Uplink- und Downlinklast trennen und den Gewinn mit realen Geräten messen.
Häufige Fragen
Ist LR-FHSS ein eigenes Funknetz neben LoRaWAN?
Nein. LR-FHSS ist eine optionale physische Uplink-Modulation innerhalb regionaler LoRaWAN-Profile. MAC, Network Server und Anwendung bleiben LoRaWAN.
Funktioniert LR-FHSS auch im LoRaWAN-Downlink?
Die in den Regional Parameters eingeführten LR-FHSS-Datenraten werden für den Uplink verwendet. Downlinks nutzen weiterhin die üblichen LoRaWAN-Datenraten.
Erhöht LR-FHSS immer die Reichweite?
Nein. Es kann eine zum LoRa-Uplink vergleichbare Reichweite und hohe Robustheit bieten, doch das konkrete Ergebnis hängt von Region, Linkbudget, Antennen, Störung und Empfänger ab.
Kann jedes vorhandene LoRaWAN-Gateway LR-FHSS empfangen?
Nein. Concentrator, Baseband, Firmware, Packet Forwarder und Network Server müssen die Modulation und regionalen Datenraten unterstützen.
Beschleunigt LR-FHSS Firmware-Updates?
Nicht die eigentliche Verteilung: FUOTA-Fragmente sind überwiegend Downlinks. LR-FHSS kann Uplinkstatus übertragen, beseitigt aber den Downlinkengpass nicht.