LoRaWAN class A vs B vs C : tout comprendre en 2026

La spécification LoRaWAN ne décrit pas un seul mode de fonctionnement radio, mais trois profils complémentaires de gestion de la fenêtre de réception (RX window). Ce découpage répond à un compromis physique fondamental des LPWAN : on ne peut pas simultanément offrir une autonomie batterie de dix ans, une latence sub-seconde et un débit modeste sur bande sub-GHz ISM. Le radio modem SX1276 / SX1303 de Semtech, brique matérielle dominante, doit alterner entre veille profonde, transmission (TX) et réception (RX), chacun de ces états ayant un coût énergétique d'ordre de grandeur différent.

Le compromis radio fondamental

Un modem LoRa consomme typiquement 1,5 µA en veille deep-sleep, 10-15 mA en RX, 20-120 mA en TX selon la puissance (jusqu'à 14 dBm ERP en EU868). Garder le récepteur ouvert en permanence (Class C) coûte donc ~10 000 fois plus d'énergie que de l'éteindre. À l'inverse, ne l'ouvrir que brièvement après un uplink (Class A) impose au serveur d'attendre que l'objet parle pour pouvoir lui répondre — la latence downlink dépend alors du pacing applicatif de l'end-device.

Le rôle de la spec 1.0.x et 1.1

La LoRaWAN Specification 1.0.4 (juin 2020, durcie ensuite) consolide les trois classes et les régions (EU868, US915, AU915, AS923, IN865, KR920, RU864). La 1.1 (octobre 2017, déploiement progressif) ajoute la séparation NwkSKey / AppSKey (donc une isolation cryptographique réseau-applicatif), la gestion OTAA durcie avec JoinEUI (anciennement AppEUI) et un mécanisme Rejoin plus robuste. En 2026, la quasi-totalité des stacks production en France tournent en 1.0.4 avec migration ciblée vers 1.1 sur les déploiements neufs (Actility ThingPark, Chirpstack, TTI Stack v3).

Toutes les classes partagent l'uplink

Point capital : toutes les end-devices LoRaWAN sont, par défaut, Class A. C'est le mode obligatoire défini par la spec. Class B et Class C sont des extensions optionnelles que le device peut activer par MAC command (`DeviceModeInd`) après le Join. L'uplink reste rigoureusement identique : modulation CSS (Chirp Spread Spectrum), Spreading Factor SF7 à SF12, DR0 à DR7 en EU868, contrainte ETSI de duty cycle 1 % par sous-bande horaire dans 868-868.6 MHz, MIC (Message Integrity Code) AES-CMAC de 4 octets.

La Class A est le mode de référence — celui qu'utilisent en 2026 environ 95 % des end-devices déployés sur les réseaux publics et privés français. Elle est obligatoire : tout device LoRaWAN certifié supporte Class A, et c'est le seul mode garanti par la quasi-totalité des opérateurs (Bouygues Telecom IoT, Helium, TTN public).

Mécanisme RX1 / RX2

Un end-device Class A est endormi par défaut. Il se réveille selon un pacing applicatif (mesure de température toutes les 15 min, relève de compteur eau toutes les heures, etc.), envoie son uplink, puis ouvre deux fenêtres de réception :

• RX1 : 1 seconde après la fin de l'uplink (configurable via `RxDelay`, 1-15 s), sur la même fréquence et même DR que l'uplink (paramétrable via `Rx1DROffset`).
• RX2 : 2 secondes après RX1, sur une fréquence et un DR fixes définis par la région — en EU868, par défaut 869,525 MHz à DR0 (SF12).

Si un downlink est en attente côté Network Server, il est délivré dans RX1 ou RX2. Sinon, le device se rendort immédiatement après RX2 — quelques millisecondes de récepteur ouvert seulement.

Autonomie batterie : 5 à 15 ans

Un compteur eau ou un capteur de température en Class A avec une pile lithium ER14505 AA (2,4 Ah) ou ER34615 D (19 Ah) tient typiquement 5 à 15 ans. Les datasheets Sagemcom Siconia, Sensing Labs Senlab, Adeunis Field Test ou Birdz parlent couramment de 10 ans à 1 uplink/heure SF12 ou 15 ans à 1 uplink/jour SF7. C'est cette autonomie qui rend possible le déploiement massif sans maintenance — un technicien Veolia ou Suez ne peut pas changer la batterie de 200 000 compteurs eau enterrés tous les 18 mois.

La contrepartie : latence downlink imprévisible

Un serveur applicatif qui veut commander un Class A (changer un seuil, déclencher un firmware update FUOTA, demander un reboot) doit attendre que le device parle. Si le pacing est d'un uplink par 24 h, la latence downlink moyenne est 12 heures, le pire cas 24 heures. Cette propriété disqualifie Class A pour tout cas d'usage acteur (commande d'éclairage, vanne, relais).

Cas d'usage typiques

• Compteurs eau, gaz, électricité (relève horaire ou journalière) — Birdz, Suez Aquadvanced, GRDF compteur Gazpar évolution LoRaWAN.
• Sondes T° / hygrométrie bâtiment ou cold chain (1 uplink / 15 min).
• Capteurs de niveau cuve, débitmètres agricoles, sondes humidité sol.
• Trackers GPS bétail ou containers (1-4 uplinks / jour).
• Détecteurs de présence parking (Indigo, PayByPhone, ZenPark) — uplink événementiel sur changement d'état.

La Class B est, sur le papier, le compromis élégant : offrir des fenêtres de réception programmées à intervalles réguliers, sans devoir attendre un uplink, tout en gardant une consommation modérée. En pratique, c'est la classe la moins déployée en 2026 — une curiosité technique plus qu'une option production.

Mécanisme : beacon GPS + ping slots

Le principe repose sur deux briques :

• Le gateway émet un beacon synchronisé GPS toutes les 128 secondes sur une fréquence dédiée (869,525 MHz en EU868). Ce beacon contient un timestamp GPS précis (à la microseconde).
• L'end-device Class B, après avoir capté le beacon, calcule l'instant exact de ses ping slots — fenêtres de réception courtes (~30 ms) à intervalles configurables (`PingSlotPeriod` : 1, 2, 4, 8, 16, 32, 64 ou 128 secondes).

Le serveur applicatif peut donc programmer un downlink à n'importe quel ping slot, avec une latence maximale égale à la période du ping slot (ex. 8 s pour PingSlotPeriod = 8 s).

Pourquoi Class B reste marginal en 2026

Quatre raisons cumulatives expliquent son faible déploiement en production :

• Coût matériel gateway : un beacon synchronisé GPS exige un module GNSS précis et une antenne GPS supplémentaire. La plupart des gateways publics Orange/Objenious (avant l'arrêt 2024), Bouygues Telecom IoT ou TTN community ne diffusent pas de beacon Class B en standard.
• Synchronisation fragile : perte de signal GPS = perte de synchro = device qui passe en mode dégradé (typiquement bascule en Class A). En intérieur ou en cave (cas typique d'un compteur eau), c'est rédhibitoire.
• Surconsommation modérée : un ping slot toutes les 8 secondes consomme 5 à 20 fois plus qu'un device Class A standard, divisant l'autonomie de 10 ans à 1-2 ans.
• Class C est disponible si l'on a du secteur : pour les cas où une latence courte est requise, Class C sur alim secteur est plus simple et plus prévisible.

Cas d'usage théoriques

La Class B reste pertinente pour des trackers GPS ou smart-meter mobiles sur batterie longue durée nécessitant un downlink à latence connue (configuration, geofencing, OTA partial). En pratique, en France en 2026, on la rencontre quasi exclusivement sur des déploiements privés ThingPark Enterprise d'Actility où l'intégrateur maîtrise la flotte de gateways. À éviter sauf cahier des charges très spécifique.

La Class C est le mode récepteur quasi-permanent. Le device garde sa RX window ouverte en continu, sauf pendant les périodes de transmission (TX). C'est le seul mode LoRaWAN qui offre une latence downlink inférieure à la seconde, comparable à un protocole IP filaire.

Mécanisme : RX2 étendu

Un device Class C ouvre toujours RX1 (comme Class A) après un uplink, puis bascule sur RX2 étendu : la fenêtre RX2 reste ouverte en permanence sur 869,525 MHz à DR0 (SF12) par défaut en EU868. Le serveur peut envoyer un downlink à tout moment, qui est reçu en quelques dizaines de millisecondes.

La contrainte : alimentation secteur quasi obligatoire

Le récepteur LoRa ouvert en continu consomme ~10-15 mA en permanence. Sur une pile lithium AA (2,4 Ah), cela donne une autonomie théorique de 200 heures, soit 8 jours. Inutilisable en production sur batterie.

Class C exige donc :

• Alimentation secteur 230 V AC ou PoE (Power over Ethernet).
• Ou alternativement une alim secourue par batterie (panneau solaire + LiFePO4) calibrée pour 24/7, ce qui multiplie par 5-10 le coût matériel et la maintenance.

Cas d'usage légitimes en France

• Éclairage public connecté — lampadaires LED smart pilotables à distance, où la latence d'allumage doit être < 5 s. Acteurs : Citelum (Engie), Schréder Light, Engie Solutions Smart City, Lacroix City. Le lampadaire est par définition alimenté en secteur.
• Vannes actionneur d'irrigation smart-agri sur secteur ou alim solaire dimensionnée — déclenchement à distance d'un cycle d'arrosage depuis une plateforme agronomique.
• Smart-meter de station-service ou télémétrie temps quasi-réel sur infrastructure carburant, distribution gaz industrielle.
• Compteurs MID (Mesures et Instruments Directive) sur applications légalement chronométrées (preuve de mesure à intervalle court).

Le piège marketing

Certains fournisseurs de modules end-device vendent un firmware « Class A/B/C dynamique » qui bascule à la demande. C'est techniquement possible (commande MAC `DeviceModeInd`), mais le bilan énergétique est dominé par le mode actif le plus gourmand : un device qui passe en Class C 1 heure par jour pour FUOTA consomme déjà 1/24 d'une autonomie Class C continue. À auditer dans le cahier des charges.

Synthèse 2026 sur EU868 (paramètres par défaut, SF7-SF12, payload type 20 octets).

Consommation et autonomie

• Class A — Veille deep-sleep 1,5 µA, TX/RX seulement à la demande applicative. Autonomie typique 5-15 ans sur pile lithium ER14505 ou ER34615.
• Class B — Surconsommation ping slots de ×5 à ×20 par rapport à Class A selon `PingSlotPeriod`. Autonomie typique 1-3 ans sur pile lithium.
• Class C — RX ouvert permanent, ~10-15 mA continu. Autonomie batterie quelques jours. Secteur 230 V AC ou PoE quasi obligatoire.

Latence downlink

• Class A — Variable, dépend du pacing uplink. Médiane = demi-période d'uplink, pire cas = période complète (typiquement quelques minutes à 24 heures).
• Class B — Borné par `PingSlotPeriod`, typiquement 1 à 128 secondes.
• Class C — < 1 seconde en pratique (jitter radio inclus).

Débit (payload utile)

Identique entre les trois classes — le débit dépend du DR (Data Rate) et du SF (Spreading Factor), pas de la classe.

• DR0 / SF12 : ~250 bit/s utile, payload max 51 octets en EU868.
• DR5 / SF7 : ~5,5 kbit/s, payload max 242 octets.
• DR6 / SF7 BW250 et DR7 / FSK 50 kbit/s : usages spécifiques, payload max 242 octets.

ADR (voir section dédiée) optimise dynamiquement le DR selon le RSSI/SNR.

Sécurité (identique entre classes)

• AES-128 sur la couche MAC (intégrité + chiffrement payload).
• OTAA (Over-The-Air Activation) recommandé en production — Join Procedure avec DevEUI (identifiant unique device), JoinEUI (anciennement AppEUI), AppKey (root key) ; génération à la volée de NwkSKey et AppSKey.
• ABP (Activation By Personalization) — clés statiques flashées en usine, à proscrire en 2026 sauf banc de test.
• MIC (Message Integrity Code) AES-CMAC 4 octets sur chaque trame.
• LoRaWAN 1.1 sépare NwkSKey (réseau) et AppSKey (applicatif) — clause cahier des charges depuis fin 2025.

Régions et duty cycle

EU868 : 14 dBm ERP max, duty cycle ETSI 1 % par 1 heure dans 868-868.6 MHz, 10 % dans 869,4-869,65 MHz (sous-bande downlink Class B/C beacon). US915 : 30 dBm, dwell time 400 ms, pas de duty cycle. AS923 et AU915 selon réglementation locale.

Recommandations 2026 pour un chef de projet IoT en France, par ordre de priorité.

Règle par défaut : Class A + ADR + OTAA

C'est le réglage par défaut de tout déploiement public ou privé, et celui supporté nativement par tous les opérateurs et stacks (Bouygues Telecom IoT, Actility ThingPark, Chirpstack, TTN/TTI Stack v3, Helium, Senet). Caractéristiques visées :

• Class A activée (mode par défaut).
• ADR activé côté Network Server.
• OTAA avec AppKey unique par device (jamais réutilisée), JoinEUI identifiant l'application backend.
• Payload < 51 octets pour rester compatible SF12 en cas de basculement ADR.
• LoRaWAN 1.1 privilégié sur les déploiements neufs.

Ce profil convient à 95 % des cas : capteurs de température, hygrométrie, niveau, présence, compteurs, trackers, etc.

Class C uniquement si latence < 5 s exigée ET secteur disponible

À sélectionner UNIQUEMENT si les deux conditions sont réunies :

• Cahier des charges impose une latence downlink < 5 secondes (commande d'actionneur, allumage lampadaire, vanne d'irrigation).
• Alimentation secteur 230 V AC ou PoE garantie sur toute la durée de vie du device.

Class C avec alimentation batterie seule = projet à reprendre en revue de conception.

Class B : à éviter sauf déploiement privé maîtrisé

Class B est défendable uniquement si :

• Vous déployez vos propres gateways (typiquement Actility ThingPark Enterprise ou Multitech / Kerlink en privé), tous équipés et configurés en beacon GPS.
• Vous avez un cas d'usage trackers mobiles batterie longue nécessitant une latence downlink bornée connue (configuration, geofencing OTA).
• Vous acceptez une autonomie 5-10 fois moindre qu'en Class A.

Sur réseau public (Bouygues, Helium, TTN), Class B est en pratique inutilisable.

Mixer A et C ? Oui, dans un même réseau

Un même Network Server (Actility ThingPark, Chirpstack, TTI Stack v3) gère sans difficulté des devices Class A (compteurs, capteurs) et Class C (actionneurs) sur la même flotte de gateways. La classe est une propriété du end-device, pas du réseau. Architecturer ainsi sa flotte = approche standard 2026.

ADR (Adaptive Data Rate) est le mécanisme par lequel le Network Server ajuste dynamiquement le DR, le SF et la puissance TX d'un end-device selon la qualité radio mesurée (RSSI, SNR). C'est l'un des leviers de performance les plus mal compris des intégrateurs LoRaWAN.

Principe ADR

Le device active ADR en positionnant le bit `ADR=1` dans l'en-tête FCtrl. Le Network Server analyse alors les 20 derniers uplinks et calcule le meilleur compromis SF / puissance :

• Si SNR confortable (≥ -7,5 dB en SF7), le serveur descend en SF (SF7 plus rapide, payload max 242 octets, time-on-air ~50 ms) et baisse la puissance.
• Si SNR dégradé (capteur enterré, propagation difficile), le serveur monte en SF (SF12 plus robuste, payload max 51 octets, time-on-air ~1,5 s) et augmente la puissance.

L'ADR optimise simultanément autonomie batterie, portée radio et capacité réseau (un SF7 consomme 30× moins de spectre qu'un SF12 sur duty cycle 1 %).

Impact sur la classe

ADR est indépendant de la classe — il fonctionne en Class A, B et C. Mais ses effets diffèrent :

• Class A : ADR maximise l'autonomie. Un device passé de SF12 à SF7 gagne ~5-7 ans de batterie sur 10 ans nominal.
• Class B : ADR aide aussi sur la consommation moyenne, mais les ping slots restent dominants dans le bilan énergétique.
• Class C : ADR optimise surtout le temps d'occupation TX et donc l'usage du duty cycle EU868 (puisque la consommation RX est dominante et incompressible).

Pièges ADR fréquents

• Devices mobiles : ADR sur un tracker GPS bétail ou un container mobile = catastrophique (le SF s'ajuste à la position précédente, puis ne capte plus en mouvement). Désactiver ADR ou utiliser l'extension ADR Mobile spécifique.
• Payload variable : si le payload dépasse 51 octets à SF12 (capteur multi-mesures), la trame est rejetée. Plafonner les payloads et tester en SF12 en pré-prod.
• Confluence ADR + Class C : un device Class C basculé sur SF7 par ADR garde RX2 ouvert à... SF12 par défaut, sauf reconfiguration `RXParamSetupReq`. Audit obligatoire.

Recommandation 2026

ADR activé par défaut sur tous les déploiements stationnaires (capteurs fixes, compteurs, sondes). ADR désactivé ou en mode statique sur les mobiles (trackers, flottes, géolocalisation). Documenter le mode ADR dans le DSC (Dossier de Spécifications de Conception) du projet, au même titre que la classe et la version de spec.

En 2026, le marché LoRaWAN français est structuré autour de quelques opérateurs et intégrateurs majeurs, après la consolidation Objenious / Bouygues Telecom et l'arrêt de l'offre Orange grand public LoRaWAN en 2024 (réseau repris par Bouygues Telecom IoT).

Smart-city : éclairage, parking, déchets

• Éclairage public connecté (Class C) — Citelum (filiale EDF), Schréder Light, Engie Solutions Smart City, Lacroix City équipent les communes de lampadaires LED LoRaWAN. Latence < 5 s pour allumage, alim secteur intégrée mât. Déploiement majeur Bordeaux Métropole, Dijon On Dijon, Angers Territoire Intelligent.
• Parking smart (Class A) — capteurs de présence enterrés ou en surface (Bosch, Smart Parking, PNI Place Pod) remontent l'occupation toutes les 5-15 min. Opérateurs : Indigo, PayByPhone, ZenPark.
• Poubelles connectées (Class A) — capteurs ultrasoniques de niveau (Bigbelly, Sigrenea, Smart Up) pour optimiser les tournées de collecte. Citelum, Suez Recyclage et Veolia déploient en France.
• Qualité de l'air urbain (Class A) — micro-stations (Atmotrack, Atmotube Pro, Adeunis Comfort O2) sur mobilier urbain.

Smart-agri : irrigation, élevage, climat

• Sondes humidité sol et station météo (Class A) — Sencrop, Weenat, Sentek Drill & Drop sur LoRaWAN privé (gateway ferme) ou public Bouygues IoT.
• Vannes irrigation actionneur (Class C) — alim solaire LiFePO4 dimensionnée pour 24/7, télécommande depuis plateforme agronomique (Smag, Agriscope, Polyfarming).
• Trackers bétail (Class A) — Cowlar, Moocall, Yoann Track sur LoRaWAN privé fermier ou réseau régional (ex. Réseau Open Agro porté par certaines coopératives).

Smart-building : compteurs, GTB, confort

• Compteurs eau / gaz / chaleur (Class A) — Birdz (Veolia), Diehl Metering, Sagemcom Siconia, Itron. Relève horaire ou journalière sur 10-15 ans de batterie. GRDF teste l'évolution LoRaWAN du Gazpar sur certains parcs.
• Sondes T° / hygro / CO₂ bureaux (Class A) — Adeunis Comfort, Elsys ERS-CO2, Milesight EM300-MCS sur GTB tertiaire. Souvent connectés à un broker MQTT pour ingestion dans une supervision (Codra Panorama, Schneider EBO).
• Détection fuites eau (Class A) — sondes Adeunis ARF8170BA ou Watteco TempoBinary, déclenchement événementiel.

Opérateurs et stacks dominants

• Bouygues Telecom IoT (ex-Objenious) — couverture nationale, offre IoT Hub.
• Actility ThingPark (Lannion, FR) — leader européen Network Server, déploie ThingPark Enterprise (privé) et opère ThingPark Wireless.
• TTN / TTI Stack v3 (The Things Network / The Things Industries) — communautaire et SaaS, très utilisé en POC et déploiements régionaux.
• Helium IoT Network — couverture LoRaWAN décentralisée, encore minoritaire en FR.
• Chirpstack (open source, ex-LoRaServer) — pour déploiements privés autonomes.

En synthèse 2026 : Class A domine (compteurs, capteurs, parkings), Class C s'impose en smart-lighting et actionneurs, Class B reste marginale.