LoRaWAN-Klassen A, B, C im Überblick 2026: ein DACH-Leitfaden für IoT-Architekten und LPWAN-Integratoren

LoRaWAN definiert drei Klassen von Endgeräten (engl. *device classes*), nicht drei verschiedene Funkprotokolle. Alle Klassen teilen die identische LoRa-PHY-Schicht (Chirp-Spread-Spectrum-Modulation, Spreading Factor SF7 bis SF12, 125-kHz-Bandbreite in EU868) und denselben Network Server (LNS). Sie unterscheiden sich ausschließlich in der Art, wie das Endgerät Downlink-Nachrichten empfängt, und damit in der Balance zwischen Energieeffizienz und Latenz.

Die zugrundeliegende physikalische Realität

Ein LoRa-Funkmodul verbraucht im Empfangsmodus typisch 10-15 mA, im Sendemodus 30-130 mA und im Tiefschlaf (Sleep) unter 1 µA. Eine 3 V Lithium-Thionylchlorid-Zelle mit 19 Ah liefert rein rechnerisch knapp 100 Tage Dauerempfang — oder fünfzehn Jahre Tiefschlaf mit kurzen Aufweck-Phasen. Genau diese Spanne treibt die Klassendefinition.

Der LoRaWAN-Klassenkompromiss

• Klasse A minimiert den Energieverbrauch, indem das Endgerät nur nach einem Uplink kurz auf Downlink-Nachrichten lauscht. Latenz vom Server zum Endgerät: Sekunden bis Stunden.
• Klasse B ergänzt geplante Ping-Slots, synchronisiert über einen Gateway-Beacon, sodass der Server zu vorhersehbaren Zeitpunkten Downlink-Nachrichten zustellen kann. Latenz: typisch unter 5 Sekunden, Energieverbrauch deutlich höher als Klasse A.
• Klasse C lässt das Empfangsfenster permanent offen (außer beim eigenen Senden), Latenz unter 1 Sekunde, Energieverbrauch praktisch nicht batteriebetreibbar.

Regionale Funkbedingungen in DACH

In Deutschland, Österreich, der Schweiz und Liechtenstein gilt das EU868-Band der LoRa Alliance: 8 Kanäle im Bereich 863-870 MHz, ETSI-EN-300-220-Konformität, maximal 14 dBm ERP-Sendeleistung und eine harte Duty-Cycle-Beschränkung von 1 % pro Stunde im Sub-Band g1. Diese Duty-Cycle-Regel ist regulatorisch fix und gilt für jeden Funknetzteilnehmer — sie ist ein zentraler Grund, warum Klasse-C-Geräte für Downlink-intensive Anwendungen separat geplant werden müssen: Auch ein dauerhaft empfangsbereites Endgerät schöpft die Downlink-Kapazität des Gateways aus dessen Sende-Duty-Cycle.

Wer wählt was?

Im DACH-Raum verteilt sich die installierte Basis 2026 nach Schätzungen von ZENNER und Diehl Metering wie folgt: rund 90-95 % aller produktiv betriebenen LoRaWAN-Endgeräte sind Klasse A, 4-8 % Klasse C (vor allem Smart-Lighting-Controller und Bewässerungsventile), und unter 1 % Klasse B (Spezialprojekte mit privatem Gateway-Park und GPS-Synchronisation). Diese Verteilung ist seit drei Jahren stabil und wird sich bis 2027 nicht wesentlich verändern.

Klasse A ist die verpflichtende Grundklasse, die jedes LoRaWAN-zertifizierte Endgerät beherrschen muss. Alle Klasse-B- und Klasse-C-Geräte sind gleichzeitig auch Klasse-A-fähig und fallen bei Bedarf darauf zurück.

Funktionsweise

Ein Klasse-A-Endgerät sendet einen Uplink zu einem beliebigen, vom Endgerät bestimmten Zeitpunkt (z. B. einmal pro Stunde, einmal pro Tag oder bei einem Schwellwert-Ereignis). Direkt nach dem Uplink öffnet das Gerät zwei kurze Empfangsfenster:

• RX1 öffnet typisch eine Sekunde (RECEIVE_DELAY1) nach dem Ende des Uplinks. Sendefrequenz und Data Rate von RX1 werden vom Uplink-Kanal abgeleitet (in EU868 standardmäßig identisch).
• RX2 öffnet eine weitere Sekunde später (RECEIVE_DELAY2) auf einer festen Frequenz (in EU868: 869,525 MHz) und mit einer festen Data Rate (in EU868: DR0 = SF12 / 125 kHz).

Nach RX2 schließt das Gerät das Funkmodul und kehrt in den Tiefschlaf zurück. Bis zum nächsten geplanten Uplink ist es funkstill und für den Server praktisch unerreichbar.

Energiebilanz und Batterielaufzeit

Die Energiebilanz ist optimal: Bei einem Uplink-Intervall von einer Stunde und einer mittleren Payload-Größe von 12 Byte bei SF7 in EU868 verbraucht ein Klasse-A-Sensor rund 50-80 µAh pro Tag. Mit einer 19-Ah-Lithium-Thionylchlorid-Zelle ergibt das eine rechnerische Batterielaufzeit von 8-15 Jahren — in der Praxis ausgewiesen z. B. von Diehl Metering Hydrus, Itron Cyble, Hydrometer Sharky und ZENNER edonio Wasserzählern.

Latenz und ihre Konsequenzen

Der Preis für die Energieeffizienz ist eine variable Downlink-Latenz, die zwischen wenigen Sekunden (zufällig direkt nach einem Uplink) und dem gesamten Uplink-Intervall (im Extremfall mehrere Stunden) liegen kann. Konfigurationsänderungen, Firmware-Update-Trigger oder ADR-Anpassungen erreichen das Gerät also nur zeitverzögert und nur dann, wenn der Server die Downlink-Nachricht in der LNS-Warteschlange für den nächsten Uplink bereithält.

Typische Klasse-A-Anwendungen in DACH 2026

• Wasser-Smart-Meter (Diehl Metering Hydrus / Hydrocenter, Itron Cyble, Hydrometer Sharky, ZENNER edonio) — Stadtwerke Berlin, München SWM, Wien Energie, Salzburg AG, EWZ Zürich rollen seit Jahren in Klasse A aus.
• Gas-Smart-Meter (Itron Gallus G4 LoRa, Diehl Metering Aquila) — kommunale Versorger, sukzessive Migration der Gaszählerablesung.
• Asset-Tracker (Abeeway Master Tracker, TIS Tracker, Digital Matter Oyster) — Logistik, Mautanhänger, Containertracking.
• Parkraumsensoren (Bosch Parking Lot Sensor, Nwave, Smart Parking) — Stuttgart, Frankfurt, Hamburg kommunale Pilotprojekte.
• Mülltonnen-Füllstandsensoren (Sutco RecyclingTechnik, Veolia DE, Sensoneo) — Veolia Deutschland und ARA Österreich.
• Umweltsensorik — Feinstaub, Lärm, Temperatur, Bodenfeuchte für Smart-Agri- und Smart-City-Anwendungen.

Für alle diese Anwendungen ist die zeitverzögerte Downlink-Zustellung unproblematisch, weil weder Konfigurationsänderungen noch Aktor-Befehle in Echtzeit erfolgen müssen.

Klasse B versucht, den Kompromiss zwischen Batterielaufzeit (Klasse A) und permanenter Erreichbarkeit (Klasse C) durch geplante, vorhersehbare Empfangsfenster zu lösen. In der Theorie elegant, in der DACH-Praxis 2026 nahezu unbedeutend.

Funktionsweise

Klasse-B-Endgeräte synchronisieren sich auf einen Beacon, den das Gateway in regelmäßigen Abständen aussendet — typisch alle 128 Sekunden. Der Beacon enthält einen Zeitstempel (abgeleitet aus der GPS-Zeit des Gateways) und erlaubt dem Endgerät, Ping-Slots zu öffnen: kurze Empfangsfenster zu vereinbarten Zeitpunkten zwischen den Beacons. Typische Konfiguration: 8, 16, 32, 64 oder bis zu 128 Ping-Slots pro Beacon-Periode, einstellbar je nach geforderter Latenz.

Mit 32 Ping-Slots pro Beacon-Periode liegt die mittlere Downlink-Latenz bei rund 2 Sekunden — deutlich besser als Klasse A, deutlich schlechter als Klasse C, aber bei moderatem Energieverbrauch (rund 5-10x höher als Klasse A, abhängig von der Ping-Slot-Dichte).

Warum Klasse B in der Praxis kaum vorkommt

Drei Gründe halten Klasse B seit Jahren in der Nische:

• GPS-Synchronisationskomplexität der Gateways. Jedes Gateway, das Klasse-B-Endgeräte versorgen soll, benötigt einen GPS-Empfänger mit verlässlicher Zeitreferenz. Indoor-Gateways oder Gateways in dichter Bebauung verlieren regelmäßig GPS-Fix und damit die Synchronisationsfähigkeit. Viele Stadtwerke-Gateways haben keinen GPS-Empfänger oder schalten ihn aus Energiegründen ab.
• Limitierte Betreiber-Unterstützung. Vodafone IoT, Telekom T-IoT und Telefónica IoT bieten Klasse B in DACH 2026 nicht als unterstützten Service an. ZENNER und Diehl Metering unterstützen Klasse B nur in Sonderverträgen mit dediziertem Gateway-Park. Nur wenige Stadtwerke-LoRaWAN-Netze (vereinzelt Stadtwerke München SWM für Pilotprojekte) haben Klasse B testweise aktiviert.
• Mehrgateway-Synchronisationsproblem. In einem Mehrgateway-Netz (jeder LoRaWAN-Uplink wird typisch von 2-5 Gateways empfangen) muss der Network Server entscheiden, welches Gateway den Beacon und die Ping-Slot-Downlinks sendet. Diese Koordination ist im Standard definiert, in der Praxis aber von wenigen LNS-Implementierungen (ChirpStack v4, The Things Stack Enterprise, Actility ThingPark Enterprise) sauber umgesetzt.

Wann Klasse B trotzdem sinnvoll sein kann

Klasse B kommt in Frage, wenn (a) ein privater Gateway-Park mit GPS-Sync zur Verfügung steht (etwa in einem geschlossenen Industriegelände, einem Fernwärmenetz oder einer großen landwirtschaftlichen Betriebsfläche), (b) die geforderte Downlink-Latenz im Bereich 2-10 Sekunden liegt und (c) Klasse C aus Energiegründen ausscheidet (Batteriebetrieb erforderlich, aber Netzversorgung nicht garantiert).

In DACH 2026 sind solche Konstellationen Einzelfälle. Die Empfehlung für 95 % aller Projektverantwortlichen lautet daher: Klasse B aktiv meiden und stattdessen je nach Latenzanforderung Klasse A (langsam) oder Klasse C (schnell) wählen.

Klasse C ist das Gegenstück zu Klasse A: Latenz auf Kosten der Energieeffizienz. Ein Klasse-C-Endgerät hat sein Empfangsfenster permanent offen — das Gerät befindet sich praktisch dauerhaft im RX2-Modus und wechselt nur zum eigenen Senden kurz auf TX und unmittelbar danach auf RX1.

Funktionsweise

Nach einem Uplink öffnet das Klasse-C-Gerät — wie ein Klasse-A-Gerät — zunächst RX1 und RX2. Anders als Klasse A schließt es jedoch RX2 nach Ablauf des regulären Fensters nicht, sondern lässt das Empfangsteil dauerhaft auf der RX2-Frequenz und mit der RX2-Data-Rate aktiv (in EU868: 869,525 MHz, DR0). Der Network Server kann jederzeit eine Downlink-Nachricht senden und das Gerät empfängt sie mit einer Latenz unter einer Sekunde.

Energieverbrauch und Stromversorgung

Der Dauerempfang verbraucht 10-15 mA — bei 24/7-Betrieb sind das rund 300 mAh pro Tag oder mehr als 100 Ah pro Jahr. Mit einer haushaltsüblichen Lithium-Batterie ist das nicht darstellbar. Klasse C setzt Netzversorgung praktisch voraus — entweder direkt aus dem 230-V-Netz (Smart-Lighting-Controller, MID-Stromzähler) oder aus einem 12/24-V-Niederspannungsnetz mit Pufferakku (Bewässerungssteuerungen, Industrieaktoren).

Typische Klasse-C-Anwendungen in DACH 2026

• Straßenbeleuchtungs-Steuerung kommunal — Trilux Lichtmanagement, Schreder DE, Signify Interact City. Stadtwerke München SWM, Wien Energie, Stadtwerke Stuttgart und mehr als 100 kommunale Versorger steuern LED-Leuchten in Klasse C mit Latenz unter 5 Sekunden (Dimmprofile, Wartungsbefehle, Defektmeldungen).
• Bewässerungsventile in der Smart Agriculture — Netafim Connected Farm, Sentek Sensor Technologies, RAESA. Tagsüber Netzversorgung über kleines Solarpanel + Pufferakku, nachts Tiefschlaf-Fallback auf Klasse A.
• MID-Stromzähler mit Schaltbefehl — EnBW, EWE, Stadtwerke Mannheim für Direktabschaltung im KRITIS-Szenario gemäß § 14a EnWG.
• Industrieaktoren für Bosch IoT Suite und Siemens Insights Hub mit garantierter Reaktionszeit unter 2 Sekunden.
• Notruf- und Brandschutz-Auslöser mit Bestätigungspfad — bei sicherheitsrelevanten Aktoren wird Klasse C zwingend gefordert.

Praktische Einschränkungen

Drei Punkte müssen Projektverantwortliche bei Klasse C beachten:

• Duty-Cycle-Limit am Gateway. Auch wenn das Endgerät permanent empfangsbereit ist, gilt am Gateway die 1 %-Duty-Cycle-Regel pro Stunde im EU868 g1-Subband. Ein Gateway kann nur rund 36 Sekunden pro Stunde aktiv senden — bei vielen Klasse-C-Endgeräten pro Gateway wird das schnell zum Engpass.
• Funklochresistenz. Permanente Empfangsbereitschaft heißt nicht garantierter Empfang. Bei Gateway-Ausfall oder lokaler Funkstörung erreicht die Downlink-Nachricht das Gerät trotzdem nicht. Klasse C reduziert nur die Latenz im Normalbetrieb.
• Netzversorgungsabhängigkeit. Beim Stromausfall fällt das Klasse-C-Gerät komplett aus. Für sicherheitskritische Anwendungen ist eine USV oder ein Pufferakku obligatorisch.

Die folgende Übersicht fasst die drei Klassen in den fünf für die Klassenwahl entscheidenden Dimensionen zusammen.

Dimension 1 — Energieeffizienz und Batterielaufzeit

• Klasse A: 5-15 Jahre Batterielaufzeit bei stündlichem Uplink. Beste Wahl für nicht-netzgebundene Sensorik. Mittlerer Tagesverbrauch typisch 50-100 µAh.
• Klasse B: 1-3 Jahre Batterielaufzeit bei moderater Ping-Slot-Dichte. Tagesverbrauch 0,5-2 mAh.
• Klasse C: Nicht batteriebetreibbar im Dauerbetrieb. Netzversorgung obligatorisch. Tagesverbrauch 300-400 mAh.

Dimension 2 — Downlink-Latenz

• Klasse A: Sekunden bis Stunden, abhängig vom Uplink-Intervall. Mittlere Latenz = halbes Uplink-Intervall.
• Klasse B: Typisch 1-10 Sekunden, deterministisch über Ping-Slot-Dichte einstellbar.
• Klasse C: Unter 1 Sekunde, beschränkt nur durch Gateway-Duty-Cycle.

Dimension 3 — Payload-Größe (Nutzlast)

Die Payload-Größe ist nicht klassenabhängig, sondern hängt vom Spreading Factor und der zugehörigen Data Rate ab. In EU868 gelten folgende maximale Anwendungs-Payload-Größen (nach Abzug von MAC-Header und FRMPayload-Overhead):

• DR0 (SF12) — 51 Byte
• DR1 (SF11) — 51 Byte
• DR2 (SF10) — 51 Byte
• DR3 (SF9) — 115 Byte
• DR4 (SF8) — 222 Byte
• DR5 (SF7) — 222 Byte

Bei SF12 (DR0) für Geräte am Funknetzrand reduziert sich die nutzbare Payload auf 51 Byte — eine harte Designgrenze, die jeden Anwendungsfall zwingt, sein Datenmodell knapp zu halten (binärkodiert, nicht JSON).

Dimension 4 — Sicherheit (LoRaWAN 1.0.4 vs 1.1)

• LoRaWAN 1.0.4 (aktuell verbreitet): Ein einziger 128-Bit-AppSKey für sowohl Anwendungsverschlüsselung als auch Netzwerk-Integrität. OTAA (Over-the-Air Activation) ist Pflicht-Empfehlung der LoRa Alliance, ABP (Activation By Personalization) gilt als unsicher und wird in Audits beanstandet.
• LoRaWAN 1.1 (Migrationsphase 2025-2027): Getrennte AppSKey (Anwendung) und NwkSKey (Netzwerk) erlauben Roaming zwischen Network Servern ohne Offenlegung der Anwendungsdaten. MIC (Message Integrity Code) härter gegen Replay-Angriffe. BSI fordert ab Q4 2026 in KRITIS-Ausschreibungen LoRaWAN 1.1 + OTAA + ADR aktiv.
• Identifikatoren: DevEUI (eindeutige 64-Bit-Geräte-ID), JoinEUI (vormals AppEUI, 64-Bit-Identifier des Join-Servers), DevAddr (32-Bit dynamische Netzadresse nach Join).

Dimension 5 — Betreiber-Unterstützung in DACH 2026

• Klasse A: Vodafone IoT, Telekom T-IoT, Telefónica IoT, ZENNER, Diehl Metering, alle Stadtwerke-LoRaWAN-Netze — vollständig unterstützt.
• Klasse B: Praktisch nicht unterstützt durch öffentliche Anbieter. Nur in privaten ChirpStack- oder The-Things-Stack-Enterprise-Deployments.
• Klasse C: Vollständig unterstützt durch alle öffentlichen DACH-LoRaWAN-Anbieter. ZENNER und Diehl Metering bieten Klasse-C-Tarife mit garantierter Downlink-Latenz unter 2 Sekunden.

Die Klassenwahl folgt einer einfachen Entscheidungslogik, die jeder LPWAN-Integrator in DACH binnen drei Fragen abarbeiten kann.

Frage 1 — Wie schnell muss der Downlink ankommen?

• Antwort: Stunden bis Tage akzeptabel → Klasse A. Trifft auf die übergroße Mehrheit aller Sensoranwendungen zu: Wasser- und Gaszähler, Umweltsensorik, Asset-Tracking, Parkraum, Mülltonnen, Bodenfeuchte.
• Antwort: wenige Sekunden gefordert → Klasse C, sofern Netzversorgung verfügbar; sonst kritische Bewertung von Klasse B.
• Antwort: deterministisch unter 5 Sekunden, aber Batteriebetrieb → Klasse B im engen Spezialfall mit privatem GPS-synchronem Gateway-Park.

Frage 2 — Ist Netzversorgung garantiert?

• Ja → Klasse C wird zur Option, sobald die Latenzanforderung sie rechtfertigt.
• Nein → Klasse A bleibt die einzig realistische Wahl. Klasse C kommt nur bei extrem kurzem Einsatzhorizont (< 1 Jahr) und großzügig dimensionierter Batterie in Frage.

Frage 3 — Welche Gateway-Last erzeugt der Downlink-Verkehr?

Klasse C bindet das Gateway-Duty-Cycle (1 % pro Stunde im EU868 g1) für alle Endgeräte gemeinsam. Bei mehr als rund 50-100 Klasse-C-Endgeräten pro Gateway wird der Downlink-Verkehr eng. Bei dichten Smart-Lighting-Installationen müssen Stadtwerke entweder die Gateway-Dichte erhöhen oder die Schaltbefehle zeitlich entzerren (z. B. Dimmprofile in Batches statt einzelnen Befehlen pro Leuchte).

Konkrete Anwendungsfälle und ihre richtige Klassenwahl

• Wasserzählerablesung (Stadtwerke Berlin BWB, Diehl Metering Hydrus): Klasse A, Uplink alle 6-24 Stunden, Batterie 12-15 Jahre.
• Gas-Smart-Meter (Itron Gallus G4 LoRa für Open Grid Europe): Klasse A, sicherheitsrelevante Schaltbefehle sind selten und tolerieren Stundenlatenz.
• Parkraumsensorik (Bosch, Nwave, Smart Parking): Klasse A, Uplink-Triggermodell auf Belegungswechsel.
• Asset-Tracker (Abeeway, TIS, Digital Matter): Klasse A mit GPS-Aktivierung nur bei Bewegung — kombinierte LoRa+GPS-Energiebilanz erfordert striktes Klasse-A-Verhalten.
• Smart-Lighting-Controller kommunal (Trilux, Schreder, Signify): Klasse C, Netzversorgung über die Lampenfassung, Latenz unter 2 Sekunden für Dimmprofile.
• Bewässerungsventile (Netafim, Sentek, RAESA): Klasse C tagsüber (Solar-Pufferakku), Klasse A in der Nacht (Fallback). Die LoRa Alliance erlaubt explizit den Klassenwechsel zur Laufzeit per MAC-Befehl.
• MID-Stromzähler-Dispatch (EnBW § 14a EnWG): Klasse C, Netzversorgung aus dem Zähler selbst, garantierte Abschaltreaktion unter 2 Sekunden.
• Industrieaktoren (Bosch IoT, Siemens MindSphere): Klasse C, Netzversorgung gegeben, Latenz < 2 Sekunden für SCADA-äquivalenten Komfort.
• Mülltonnen-Füllstand (Sutco, Veolia DE, Sensoneo): Klasse A, Uplink einmal täglich genügt für Routenoptimierung.
• Feinstaub- und Lärmsensorik (Smart-City-München, Wien, Zürich): Klasse A, 10-Minuten- bis Stunden-Intervall.

ADR (Adaptive Data Rate) ist ein Mechanismus auf der MAC-Schicht der LoRaWAN-Spezifikation, der die Data Rate (Spreading Factor und damit Reichweite/Robustheit) jedes Endgeräts dynamisch an die tatsächlichen Funkbedingungen anpasst. ADR wirkt in allen drei Klassen identisch — die Klassenwahl ändert nichts an der ADR-Logik, aber ADR beeinflusst die Energiebilanz dramatisch.

Wie ADR funktioniert

Der Network Server analysiert die letzten 20 Uplinks eines Endgeräts (genauer: deren RSSI und SNR auf den empfangenden Gateways) und berechnet die optimale Kombination aus Spreading Factor und Sendeleistung. Findet er, dass ein Gerät mit SF11 sendet, dort aber +10 dB Margin hat, sendet er per MAC-Befehl LinkADRReq die Aufforderung, auf SF7 herunterzugehen und ggf. die Sendeleistung zu reduzieren. Das Endgerät bestätigt mit LinkADRAns und übernimmt die neue Konfiguration.

Energieeffekt von ADR

Der Sprung von SF12 auf SF7 bedeutet rund Faktor 32 kürzere Sendezeit (Time-on-Air) bei gleicher Payload. Bei einem Wasserzähler, der täglich 16 Byte sendet, reduziert ADR die Funk-Energiebilanz um eine Größenordnung. In der Praxis verlängert aktives ADR die Batterielaufzeit eines Klasse-A-Geräts von 5 Jahren (Worst Case Dauer-SF12) auf 12-15 Jahre (typischer SF7-SF9-Mix).

ADR und Klasse A

Für Klasse-A-Geräte ist ADR der wichtigste Energieeffizienz-Hebel überhaupt. Die LoRa Alliance und die BSI-Empfehlung SYS.4.5 fordern ADR aktiv (Bit ADRBit = 1 im FCtrl-Header). Stationäre Geräte (Wasserzähler im Keller, Parkraumsensor im Boden) profitieren maximal von ADR, weil die Funkbedingungen über die Lebensdauer stabil sind.

ADR und Klasse B

Klasse B nutzt ADR auf den Uplinks regulär. Die Ping-Slot-Empfangsleistung ist davon unabhängig, weil Ping-Slots auf der konfigurierten Beacon-Data-Rate erfolgen.

ADR und Klasse C

Klasse C profitiert von ADR ausschließlich auf der Uplink-Seite — der Empfangsdauerstrom ist unverändert. Da Klasse C ohnehin netzversorgt ist, ist die Energieersparnis durch ADR hier zweitrangig, aber die Reduktion der Time-on-Air entlastet die Gateway-Kapazität im Sub-Band.

ADR bei mobilen Geräten

Für bewegliche Endgeräte (Asset-Tracker, Tiergesundheitssensoren in der Landwirtschaft, Logistikcontainer) ist ADR problematisch: Die Funkbedingungen ändern sich permanent, die ADR-Adaptionslogik mit 20-Uplink-Fenster hinkt hinterher. Hier wird ADR deaktiviert (ADRBit = 0) und die Geräte senden mit einem konservativen Festwert (typisch SF9-SF10), um auch in schwierigen Funklagen zuverlässig erreichbar zu bleiben. Diese Entscheidung ist im Anwendungsfall-Profil zu dokumentieren und in BSI-konformen KRITIS-Audits zu begründen.

Die DACH-LoRaWAN-Landschaft 2026 ist deutlich heterogener als die französische oder britische. Stadtwerke, Energieversorger und private Betreiber konkurrieren mit den klassischen Mobilfunk-Operatoren um die Sensorflotten. Vier Anwendungsfelder dominieren.

Smart City — Parkraum, Mülldienste, Beleuchtung, Umwelt

• Stadtwerke München SWM betreibt seit 2019 ein eigenes LoRaWAN-Netz mit über 200 Gateways, eingebunden in den SWM Smart City Hub. Parkraumsensorik (Klasse A), Mülltonnen-Füllstand (Klasse A), Trilux-Straßenbeleuchtung (Klasse C).
• Berliner Stadtwerke / BWB rollen Wasserzähler in Klasse A in einer Partnerschaft mit Diehl Metering und ZENNER aus.
• Wien Energie und Salzburg AG betreiben kommunale LoRaWAN-Netze für Wasserablesung, Fernwärmezähler und Smart-Lighting.
• EWZ Zürich und IWB Basel mit eigenständigen LoRaWAN-Initiativen.
• Bundesweit: Vodafone IoT und Telekom T-IoT bieten öffentliche LoRaWAN-Roaming-Tarife mit Klasse A und Klasse C, die für Smart-City-Projekte mit verteilter Geografie attraktiver sind als ein eigenes Stadtwerke-Netz.

Wasser- und Gaszählerablesung

Der mit Abstand größte Anwendungsfall im DACH-Raum. Diehl Metering (Anspach, DE) und Hydrometer (Ansbach, DE) sind die Marktführer für Wasserzähler; Itron für Gaszähler. Alle Geräte sind Klasse A, OTAA, ADR aktiv. ZENNER (Saarbrücken, DE) betreibt ein bundesweites LoRaWAN-Netz, das vorrangig auf Energieversorger-Auslesung ausgelegt ist und mit dem ZENNER MoneyHive-Backend integriert.

Smart Agriculture — Bodenfeuchte, Bewässerung, Tierhaltung

In Süddeutschland (Baden-Württemberg, Bayern), Österreich (Niederösterreich, Burgenland) und der Schweiz (Wallis) wachsen Smart-Agri-Pilotprojekte. Anwendungsstack: Bodenfeuchtesensoren (Sentek Drill & Drop, Decentlab DL-SMTP) in Klasse A, Bewässerungsventile (Netafim NMC, RAESA) in Klasse C tagsüber / Klasse A nachts, Wettersensoren in Klasse A. Förderprogramme: BMEL-Förderung Digitale Landwirtschaft, GAP-2-Förderung digitale Innovation, Innosuisse Smart Farming Switzerland.

Industrie 4.0 — Bosch IoT, Siemens MindSphere, BMW Connected Factory

Im industriellen Kontext ist LoRaWAN zwar nicht der dominante Funkstandard (Konkurrenz von WiFi 6, 5G LAN, Bluetooth Mesh, OPC UA over TSN), aber in Nebenfunktionen weit verbreitet: Hallen-Temperaturüberwachung, Druckluftleckage-Erkennung, Materiallager-Füllstand, mobile Werkzeug-Tracker. Bosch IoT Suite und Siemens Insights Hub bieten native LoRaWAN-Konnektoren. Klassenwahl: meist Klasse A, vereinzelt Klasse C für sicherheitsrelevante Aktoren.

Marktzahlen DACH 2026

Nach Schätzungen von Bitkom, eco-Verband und Berg Insight liegt die installierte LoRaWAN-Basis in DACH Ende 2026 bei rund 18-22 Millionen Endgeräten, davon etwa 14-16 Mio. Wasser- und Gaszähler, 2-3 Mio. Smart-City-Sensorik, rund 1 Mio. Smart-Agri- und Smart-Building-Geräte, und unter 500 000 Klasse-C-Geräte (Smart Lighting, MID-Stromzähler, Industrieaktoren). Wachstumsrate 2025-2027: rund 25-30 % p.a., getrieben durch die Pflicht-Smart-Meter-Rollouts (Messstellenbetriebsgesetz) und die EU NIS2 / KRITIS-Modernisierung.

Das BSI IT-Grundschutz-Kompendium, Baustein SYS.4.5 (Funkverbindungen IoT), ist seit der Edition 2023 die zentrale Referenz für KRITIS-Betreiber, Stadtwerke und Energieversorger in Deutschland — und wird in der Schweiz (NCSC) und Österreich (NIS-Behörde) als De-facto-Standard übernommen. Ab Q4 2026 verlangt es in allen KRITIS-Ausschreibungen LoRaWAN 1.1, OTAA und aktives ADR.

Was SYS.4.5 für LoRaWAN konkret fordert

• OTAA statt ABP. Die Aktivierung muss Over-the-Air erfolgen, mit dynamisch ausgehandelter DevAddr. ABP-Geräte gelten als unsicher, weil Sitzungsschlüssel im Klartext im Endgerät hinterlegt sind und sich nicht rotieren lassen.
• LoRaWAN 1.1 mit getrennten Schlüsseln. AppSKey und NwkSKey müssen unabhängig sein, sodass der Network-Server-Betreiber keinen Zugriff auf die Anwendungsdaten hat. Diese Trennung ist insbesondere bei der Nutzung öffentlicher Netze (Vodafone IoT, Telekom T-IoT) sicherheitsrelevant.
• MIC-Validierung. Der Message Integrity Code (MIC) muss serverseitig verifiziert werden; Replay-Angriffe werden über einen Frame-Counter (FCntUp / FCntDown) erkannt und blockiert.
• ADR aktiv. Reduktion der Time-on-Air dient nicht nur der Energieeffizienz, sondern auch der Reduktion der Funkangriffsfläche.
• Schlüsselrotation. Empfehlung der LoRa Alliance: AppKey/NwkKey nach jedem Join-Vorgang, mindestens jährlich. Bei LoRaWAN 1.1 mit Join-Server ist das automatisierbar.
• DevEUI- und JoinEUI-Whitelist am Network Server. Unbekannte Geräte werden im Join-Prozess abgewiesen.
• Physische Sicherheit der Schlüssel. AppKey und NwkKey müssen im Endgerät in einem Secure Element (z. B. STMicroelectronics STSAFE-A100, NXP SE050, Microchip ATECC608) gespeichert werden, nicht in unverschlüsseltem Flash-Speicher. Dies wird ab 2026 zur Pflicht in BSI-konformen Endgeräten.

Welche Geräte halten SYS.4.5 ein?

Die marktführenden DACH-Hersteller — Diehl Metering, Hydrometer, ZENNER, Itron — haben ihre Wasserzähler-, Gas- und Wärmemengenzähler-Linien seit 2024 sukzessive auf LoRaWAN 1.1 + Secure Element umgestellt. Neue Ausschreibungen ab 2026 fordern dies typisch als Mindestanforderung. Bei Smart-Lighting-Controllern und Industrieaktoren (Klasse C) liegt der Anteil LoRaWAN-1.1-konformer Geräte 2026 erst bei rund 40-50 %; die Migration zieht sich bis 2028.

NIS2 und KRITIS-Schnittstelle

Die EU-Richtlinie NIS2 (umgesetzt durch das deutsche NIS2UmsuCG und das österreichische NISG 2024) erweitert den KRITIS-Kreis erheblich (u.a. Wasserwirtschaft, Energie, Verkehr, kommunale Dienstleister). Für all diese Akteure wird BSI IT-Grundschutz SYS.4.5 zur faktischen Compliance-Vorgabe. Projektverantwortliche sollten in 2026er-Ausschreibungen darauf achten, dass die ausgewählte LoRaWAN-Plattform (Network Server, Application Server, Endgeräte) gemeinsam SYS.4.5-konform ist, nicht nur einzelne Komponenten.

Redaktionelle Empfehlung 2026

Für 90-95 % aller DACH-LoRaWAN-Projekte ist die optimale Konfiguration: Klasse A + OTAA + LoRaWAN 1.1 + ADR aktiv + Payload binär kodiert unter 51 Byte bei SF11 EU868 + Secure Element im Endgerät. Klasse C nur wenn Latenz unter 5 Sekunden gefordert UND Netzversorgung gesichert ist (Smart Lighting kommunal, MID-Stromzähler-Dispatch, Industrieaktoren). Klasse B aktiv vermeiden, außer im engen Spezialfall eines privaten GPS-synchronen Gateway-Parks bei ZENNER oder Diehl Metering. Diese Empfehlung bleibt bis mindestens 2028 stabil — auch nach erwarteten kleineren Spezifikationsupdates der LoRa Alliance.