Certification LoRaWAN : 9 étapes, tests LCTT et labos ATL
Guide - Certification LoRaWAN
La certification LoRaWAN se déroule en 9 étapes auprès de la LoRa Alliance : adhésion Adopter, choix de la stack et du module, de la version (1.0.4 ou 1.1), des classes et des packs régionaux, pré-tests avec l'outil LCTT, puis campagne dans un Authorized Test Lab avant émission du certificat. Ce programme prive d'interopérabilité et de marque s'ajoute, sans s'y substituer, aux obligations réglementaires radio applicables a un objet sans fil. Il couvre le comportement de la couche MAC LoRaWAN, la conformité aux parametres régionaux et l'interopérabilité avec les serveurs de réseau, mais ne traite ni de la modulation LoRa elle-même (propriété intellectuelle de Semtech) ni des exigences spectrales nationales. Cette page expose les principes du programme, les niveaux d'adhésion, les versions de spécification et leurs ruptures, les classes d'objet, les outils d'essai et les pieges classiques d'une commercialisation incomplete.
En résumé :
- 9 étapes : adhésion LoRa Alliance (Adopter au minimum), choix de version, de classes et de packs régionaux, pré-tests LCTT, campagne ATL, revue par l'Alliance, certificat et logo.
- Le LCTT (LoRaWAN Certification Test Tool) vérifie l'activation (OTAA/ABP), le comportement des classes A/B/C, les paramètres régionaux, les commandes MAC et la sécurité des clés.
- Le certificat porte une portée explicite : version 1.0.4 ou 1.1, classes, packs régionaux (EU868, US915, AS923 avec ses sous-bandes).
- LoRaWAN Certified ne remplace jamais la certification radio : EN 300 220 (RED) et FCC Part 15.247 restent des dossiers séparés.
Pourquoi une certification distincte de la radio
Section intitulée « Pourquoi une certification distincte de la radio »La LoRa Alliance, constituée en 2015, federe les acteurs du LoRaWAN : opérateurs de réseaux publics (Actility ThingPark, Senet, Orange, Bouygues...), fabricants de gateways, intégrateurs et fabricants d'objets. L'Alliance maintient les spécifications LoRaWAN, les parametres régionaux et le programme de certification end device. Elle détient les marques LoRaWAN et LoRaWAN Certified, et licencie leur usage a ses membres dans le cadre du programme.
L'Alliance n'est pas un regulateur. Les obligations radio (puissance, duty cycle, bande, harmoniques, méthode de mesure) relèvent des autorités nationales : autorités de spectre européennes via la directive RED, FCC aux Etats-Unis, ANATEL au Bresil, MIC au Japon, etc. La certification LoRaWAN intervient apres la conformité radio : elle ne libere d'aucune obligation réglementaire et ne se substitue a aucun rapport d'essai radio.
Deux objectifs cohabitent dans le programme :
- Interoperabilite réseau. Garantir qu'un objet certifie communique correctement avec n'importe quel serveur de réseau LoRaWAN conforme a la même spécification, sans personnalisation client.
- Protection de marque. Assurer que la mention LoRaWAN Certified et son logo ne sont apposes que sur des produits ayant passe les essais de l'Alliance.
L'enjeu commercial est important : la plupart des opérateurs de réseaux publics LoRaWAN exigent la certification Alliance comme condition d'admission sur leur infrastructure. Un objet non certifie peut techniquement fonctionner sur un réseau prive monte autour de Chirpstack ou The Things Network communautaire, mais sera généralement refuse par les opérateurs commerciaux.
LoRa, couche physique versus LoRaWAN, couche MAC
Section intitulée « LoRa, couche physique versus LoRaWAN, couche MAC »Une confusion frequente confond la modulation LoRa et le protocole LoRaWAN. Les deux relèvent de régimes de propriété et de gouvernance differents.
| Couche | Nom | Detenteur | Statut |
|---|---|---|---|
| PHY (radio) | LoRa | Semtech Corporation | Propriete intellectuelle privée, licence via achat de transceivers SX12xx |
| MAC (accès) | LoRaWAN | LoRa Alliance | Specification ouverte aux membres, maintenue par l'Alliance |
| Logo / marque | LoRaWAN Certified | LoRa Alliance | Programme de certification end device |
Tout objet LoRaWAN integre un transceiver Semtech ou un derive sous licence (Murata Type ABZ, STMicro STM32WL avec sous-systeme radio Semtech, Nordic nRF Sidewalk LoRa, etc.). La modulation est protégée par brevet ; il n'existe pas, fin 2025, d'implémentation libre de droits de LoRa au niveau physique. La spécification LoRaWAN, en revanche, peut être obtenue gratuitement par tout membre Adopter de l'Alliance et implémentée en logiciel ouvert (LMIC, LoRaMac-node de Semtech, stack ST sur STM32WL).
Cette distinction structure l'effort de développement : pas de marge sur la modulation, le composant LoRa est impose par le choix du transceiver ; en revanche, le logiciel LoRaWAN peut être integre depuis une stack reference, ce qui rend la certification accessible même aux petites equipes.
Trois régimes a articuler
Section intitulée « Trois régimes a articuler »Un objet LoRaWAN commercialise en Europe ou aux Etats-Unis doit donc satisfaire trois régimes empiles :
| Aspect | Couche radio (RED / FCC) | Couche modulation (LoRa) | Couche MAC (LoRaWAN) |
|---|---|---|---|
| Nature | Cadre réglementaire public | Choix de composant (brevet Semtech) | Programme prive de l'Alliance |
| Emetteur | Autorites de spectre nationales | Semtech via le transceiver | LoRa Alliance |
| Objet | Spectre, puissance, duty cycle, harmoniques | Modulation chirp étalée | Comportement MAC, régions, interopérabilité |
| Reference | EN 300 220, FCC Part 15.247, Part 15.249 | Datasheets SX1261 / SX1262 / SX1276 / SX1303 | LoRaWAN L2 1.0.4 ou 1.1, RP002 |
| Documents | DoC RED, FCC ID, rapports d'essai | Specification de composant | Certificat LoRaWAN Certified |
| Sanction | Interdiction de mise sur le marche | N/A (decoule du choix matière) | Retrait de la marque, refus opérateurs |
Pour le régime radio européen, voir RED, pilier et normes RED applicables. Pour le régime FCC, voir FCC, pilier. Pour un programme combine, voir EU + US, double certification.
Niveaux d'adhésion
Section intitulée « Niveaux d'adhésion »L'accès au programme de certification suppose une adhésion a la LoRa Alliance. L'Alliance propose quatre niveaux principaux.
Niveau d'entrée avec une cotisation annuelle moderee. L'Adopter peut soumettre des objets a la certification, accede aux spécifications publiées et aux parametres régionaux, et utilise le logo LoRaWAN Certified sur les produits certifies. Il ne participe pas a l'élaboration des futures spécifications.
Contributor
Section intitulée « Contributor »Niveau intermediaire. Le Contributor accede aux groupes de travail techniques (Technical Committee, Regulatory Committee, Certification Committee...), participe a la rédaction des futures versions et a la définition des parametres régionaux. Cotisation annuelle supérieure a l'Adopter.
Niveau premium. Le Sponsor dispose d'un siege au Board of Directors, oriente la stratégie globale de l'Alliance, beneficie d'une visibilité commerciale (sponsoring evenements, mention prioritaire). Adopte par les opérateurs majeurs et les silicon vendors strategiques.
Institutional
Section intitulée « Institutional »Niveau dedie aux organismes académiques, autorités publiques, organisations a but non lucratif. Conditions spécifiques, sans vocation commerciale.
| Tier | Vote | Working groups | Certification produit | Board |
|---|---|---|---|---|
| Adopter | Non | Non | Oui | Non |
| Contributor | Sur certains comites | Oui | Oui | Non |
| Sponsor | Plein | Oui | Oui | Oui |
| Institutional | Variable selon accord | Selon accord | Selon accord | Non |
Pour un fabricant d'objet intégrant un module precertifie et utilisant la stack reference Semtech, le statut Adopter est généralement suffisant. La montée a Contributor se justifie quand l'entreprise developpe sa propre stack, contribue a la spécification ou souhaite influer sur les futurs parametres régionaux.
Versions de spécification
Section intitulée « Versions de spécification »La spécification LoRaWAN a connu deux lignées principales, avec des ruptures techniques significatives.
| Version | Apport principal | Compatibilite |
|---|---|---|
| 1.0.0 | Premiere version stable, classes A/B/C définies | Historique |
| 1.0.1 | Corrections, parametres régionaux initiaux | Compatible 1.0.x |
| 1.0.2 | Ajustements, régions étendues | Compatible 1.0.x |
| 1.0.3 | Classe B affinée, régions complétées | Compatible 1.0.x |
| 1.0.4 | Compatibilite rétroactive avec la branche 1.0, dernière révision 1.0 | Compatible 1.0.x |
| 1.1 | Nouveau schéma de dérivation de clés (AppSKey / FNwkSIntKey / SNwkSIntKey / NwkSEncKey), sécurité renforcée, séparation rôles serveur d'application et serveur de réseau | Non compatible 1.0.x sans rekey |
La rupture 1.0.x vers 1.1 porte principalement sur la sécurité et la séparation des clés. En 1.0.x, l'objet derive une cle de session réseau (NwkSKey) et une cle de session application (AppSKey) a partir d'une cle racine (AppKey). En 1.1, le modele se complexifie : une cle racine réseau (NwkKey) et une cle racine application (AppKey) sont distinctes, et le serveur de réseau peut être opérationnellement separe du serveur d'application sans partage de clés d'application en clair.
La conséquence pratique : un objet 1.0.x ne peut pas joindre un réseau 1.1 dans le mode 1.1, et un objet 1.1 doit être configure en compatibilité descendante pour fonctionner sur un réseau 1.0.x. Le passage d'une famille a l'autre impose une mise a jour de stack, voire une re-certification.
La spécification reference au certificat est explicitement mentionnée dans le dossier : un certificat LoRaWAN 1.0.4 et un certificat 1.1 ne sont pas interchangeables.
Classes d'objet A, B, C
Section intitulée « Classes d'objet A, B, C »LoRaWAN définit trois classes de comportement pour les objets terminaux. Toutes les fins d'objet certifies LoRaWAN supportent la classe A ; les classes B et C sont optionnelles et soumises a des essais supplementaires.
| Classe | Mode | Initiative | Reception | Consommation typique |
|---|---|---|---|---|
| Class A | Uplink initie par l'objet | Objet | Deux fenetres apres chaque émission (RX1, RX2) | Tres basse, compatible alimentation pile années |
| Class B | Uplink + réception programmée | Objet pour uplink, gateway pour beacon | Fenetres synchronisées sur beacon (gateway émet un beacon multicast) | Intermediaire, pile mais latence réduite |
| Class C | Continue | Objet pour uplink, réseau pour downlink | Reception ouverte en permanence hors émission | Elevee, généralement secteur ou batterie haute capacité |
Le choix de la classe dépend du cas d'usage. Un capteur d'humidité agricole avec remontée horaire reste en classe A. Une vanne d'eau commandée a distance avec latence acceptable de quelques secondes peut adopter la classe B. Une serrure connectée ou un actionneur industriel commande en temps réel demande la classe C, avec son coût energetique.
La classe déclarée dans le certificat conditionne les essais executes par le laboratoire : un objet certifie classe A uniquement ne peut être commercialise comme classe B ou C, même si le firmware le supporte techniquement.
Parametres régionaux
Section intitulée « Parametres régionaux »Le document RP002 (Regional Parameters) de la LoRa Alliance specifie, pour chaque région du monde, les bandes utilisables, les plans de fréquences, les puissances maximales, les data rates autorises et les contraintes opérationnelles (duty cycle ou listen-before-talk).
| Pack | Region typique | Bande | Particularite |
|---|---|---|---|
| EU868 | Union européenne | 863-870 MHz | Duty cycle réglementaire (1 % sur la plupart des canaux) |
| US915 | Etats-Unis, Canada | 902-928 MHz | 64 canaux uplink, 8 canaux downlink |
| AS923 | Singapour, Japon, Indonesie, Bresil, Phillipines selon sous-bande | ~920-925 MHz selon plan national | Variantes AS923-1, -2, -3, -4, plans nationaux distincts |
| AU915 | Australie, Nouvelle-Zelande | 915-928 MHz | Plan derive de US915 avec ajustements |
| IN865 | Inde | 865-867 MHz | Bande restreinte, puissance limitée |
| CN470 | Chine continentale | 470-510 MHz | Plan spécifique, contraintes locales |
| RU864 | Russie | 864-870 MHz | Plan local, allocation spécifique |
Le certificat LoRaWAN porte la liste explicite des packs régionaux supportes par l'objet. Un produit certifie EU868 seul ne peut être vendu aux Etats-Unis sous le logo LoRaWAN Certified sans certification additionnelle US915. Les fabricants visant le monde entier soumettent généralement plusieurs configurations, ou un firmware multi-bandes sélectionnable, et déclarent l'ensemble des packs supportes.
A noter le cas AS923 : la mention AS923 dans un certificat peut être ambiguë si elle ne precise pas la sous-bande. La sous-bande AS923-1 (Singapour, Japon dans certains usages, Hong Kong) n'est pas identique a AS923-2 (Brésil pour certains déploiements) ou AS923-3. Lire le certificat dans son détail.
Que couvre l'outil de test LCTT ?
Section intitulée « Que couvre l'outil de test LCTT ? »La certification end device passe par un Authorized Test Lab (ATL) accredite par la LoRa Alliance. La liste publique est maintenue sur le site de l'Alliance. Les ATL sont distincts des laboratoires de certification radio classiques (même s'ils peuvent être operes par la même entité) : leur accréditation porte sur le programme LoRaWAN, pas sur les normes radio.
L'outil de reference des essais est le LoRaWAN Certification Test Tool (LCTT). Il s'agit d'un environnement de test automatise, capable de jouer une séquence de cas de test définis par l'Alliance pour chaque version de spécification, chaque classe et chaque pack regional. Le LCTT communique avec l'objet sous test via un gateway dedie et un simulateur de réseau.
La portée des essais LCTT couvre :
- Activation. Procedures OTAA (Over-The-Air Activation) et ABP (Activation By Personalization) selon la version.
- Comportement de classe. Respect des fenetres RX1, RX2 pour la classe A ; synchronisation beacon pour la classe B ; réception continue pour la classe C.
- Parametres régionaux. Conformite aux plans de fréquence, aux data rates, aux puissances et aux contraintes duty cycle ou LBT du pack declare.
- Commandes MAC. Reponses aux commandes serveur (LinkADRReq, DutyCycleReq, RXParamSetupReq, DevStatusReq, NewChannelReq, RXTimingSetupReq, etc.).
- Securite. Derivation correcte des clés selon la version, intégrité des messages, gestion du compteur de frame.
Le rapport LCTT, accompagne d'un dossier descriptif (Test Application Note, fiche produit, identifiants), est soumis a la LoRa Alliance qui prononce la certification.
Reutilisation de modules precertifies
Section intitulée « Reutilisation de modules precertifies »L'écosystème LoRaWAN a developpe une offre dense de modules precertifies, qui simplifie significativement l'effort. Le principe est analogue a celui des modules Bluetooth qualifies : un fabricant de module obtient une certification de reference, et les intégrateurs s'en servent comme base pour leurs produits.
Exemples typiques :
- Murata Type ABZ. Module intégrant un STM32L0 et un transceiver SX1276, stack LoRaWAN ST/Semtech, certifie pour plusieurs régions.
- STMicro STM32WL series. SoC combinant un Cortex-M4 et un sous-systeme radio Semtech, stack LoRaWAN officielle ST.
- Nordic / Semtech reference designs. Configurations validées pour accélération de développement.
- Modules tiers (RAK, Seeed, Pycom, etc.). Modules avec stack et certification de base, généralement EU868 et US915 au minimum.
L'intégration d'un module precertifie réduit la portée des essais LCTT, mais ne dispense pas de soumettre le produit fini :
- Si la stack n'est pas modifiée et que le module est utilise tel quel (mêmes parametres LoRaWAN, même version), le fabricant peut s'appuyer sur le certificat parent et soumettre un dossier réduit, principalement administratif et de configuration.
- Si la stack est modifiée (commandes MAC personnalisées, gestion d'énergie ajustant les RX timings, profil regional ajoute), des essais LCTT additionnels sont necessaires.
- Si la radio est modifiée (antenne externe a gain different, etage RF retravaille), la certification radio nationale (RED ou FCC) est impactée mais la certification LoRaWAN reste valable tant que la couche MAC est inchangee.
Le choix d'un module precertifie est généralement le bon compromis pour une première génération de produit, hors cas d'optimisation poussée de consommation ou de coût sur volumes importants.
Quelles sont les 9 étapes de la certification LoRaWAN ?
Section intitulée « Quelles sont les 9 étapes de la certification LoRaWAN ? »- Adhesion a la LoRa Alliance. Souscrire en tant qu'Adopter au minimum. Accès au portail membre, aux spécifications et au LCTT.
- Choix de la stack et du module. Decider entre intégration d'un module precertifie et développement sur transceiver Semtech avec stack reference. Cette décision impacte fortement l'effort de certification.
- Choix de la version et de la classe. Selectionner la version LoRaWAN cible (1.0.4 ou 1.1) et les classes supportées (A obligatoire, B et C optionnelles). Cette décision conditionne les cas de test executes.
- Choix des packs régionaux. Lister les régions de commercialisation. Chaque pack ajoute des essais et doit être cohérent avec la certification radio nationale correspondante.
- Pre-tests internes. Utiliser le LCTT en mode développement pour valider le comportement avant essais formels. Étape critique pour éviter les écarts coûteux en laboratoire externe.
- Soumission a un ATL. Confier la campagne d'essai a un Authorized Test Lab agree LoRa Alliance. Les rapports doivent suivre le format LoRa Alliance.
- Revue par l'Alliance. L'Alliance examine le rapport LCTT et le dossier descriptif. Demandes de complément possibles.
- Emission du certificat. Le produit est publie dans la base LoRaWAN Certified et peut afficher le logo. La portée precise (version, classes, packs) figure sur le certificat.
- Maintenance. Toute modification de la stack LoRaWAN ou de la configuration régionale impose un avenant, voire une nouvelle certification.
Ce processus se deroule en parallèle, et non en remplacement, de la certification radio. Le rapport EN 300 220 en Europe et le rapport Part 15.247 ou Part 15.249 aux Etats-Unis sont produits séparément, voir RED, tests et FCC, pilier.
Pieges fréquents
Section intitulée « Pieges fréquents »Confondre LoRa et LoRaWAN
Section intitulée « Confondre LoRa et LoRaWAN »L'erreur conceptuelle la plus repandue. La modulation LoRa est un composant matière, achete a Semtech par le biais du transceiver. Le protocole LoRaWAN est une couche logicielle, certifiable par l'Alliance. Affirmer qu'un produit est compatible LoRa n'a aucune valeur d'interopérabilité réseau ; seul un certificat LoRaWAN Certified atteste de cette compatibilité.
Assumer qu'un objet 1.0.x fonctionne sur un réseau 1.1
Section intitulée « Assumer qu'un objet 1.0.x fonctionne sur un réseau 1.1 »Le schéma de dérivation de clés change entre les deux familles. Un objet 1.0.x peut joindre un réseau 1.1 si ce dernier accepte le mode de compatibilité descendante, mais ne beneficie alors pas des propriétés de sécurité de la 1.1. Pour fonctionner pleinement en 1.1, une mise a jour de stack et un rekey sont necessaires. Cette migration doit être tracée dans le dossier de certification.
Oublier le pack regional cible
Section intitulée « Oublier le pack regional cible »La certification LoRaWAN ne couvre que les packs declares. Un objet certifie EU868 seul, expedie aux Etats-Unis, ne peut afficher LoRaWAN Certified pour le marche US915 sans une certification additionnelle. De plus, la conformité radio FCC est indépendante : même avec un firmware US915 certifie LoRaWAN, l'objet doit obtenir un FCC ID propre.
Negliger la sous-bande AS923
Section intitulée « Negliger la sous-bande AS923 »Le pack AS923 est decline en plusieurs sous-bandes selon les allocations nationales. Une certification AS923-1 ne couvre pas AS923-2 ou AS923-3. Lire le certificat en détail, et l'aligner sur les marches cibles. Un produit destine au marche brésilien sous AS923-2 doit être certifie pour cette sous-bande.
Modifier la stack LoRaWAN livrée par le module maker
Section intitulée « Modifier la stack LoRaWAN livrée par le module maker »Un module precertifie repose sur une stack figee. Tout patch interne (gestion de retransmission personnalisée, commandes MAC custom, timings ajustes) invalide l'hypothèse de réutilisation et impose des essais LCTT additionnels. La modification doit être tracée et soumise.
Croire que la certification LoRaWAN couvre la radio
Section intitulée « Croire que la certification LoRaWAN couvre la radio »Erreur recurrente. L'Alliance n'est pas un regulateur. Aucun rapport LCTT ne couvre EN 300 220, Part 15.247 ou Part 15.249. Les deux dossiers doivent être constitues en parallèle. Le calendrier produit doit en tenir compte des la phase de conception.
Sauter la classe déclarée
Section intitulée « Sauter la classe déclarée »Un firmware peut supporter techniquement la classe C sans que le certificat ne la mentionne. Activer la classe C sur un objet non certifie classe C ne respecte pas la portée du certificat et expose le fabricant a un retrait du logo, sans parler des incohérences potentielles avec les contraintes radio (duty cycle EU868 en classe C devient délicat).
Sous-estimer la pre-validation interne
Section intitulée « Sous-estimer la pre-validation interne »Le LCTT est un outil exigeant. Un dossier soumis a un ATL sans pre-validation interne aboutit fréquemment a des écarts coûteux. L'investissement dans une instance LCTT en interne, même pour une seule campagne, paie généralement vite.
Renvois et accompagnement
Section intitulée « Renvois et accompagnement »Voir également glossaire pour les définitions OTAA, ABP, classe A/B/C, ADR, et les guides normes RED, FCC, pilier ainsi que EU + US, double certification pour un programme dual.
Sources & références
- LoRa Alliance , LoRa Alliance lora-alliance.org/
- LoRaWAN spécifications, 1.0.4 and 1.1 , LoRa Alliance lora-alliance.org/resource_hub/lorawan-specifications/
- LoRaWAN regional parameters RP002-1.0.3 , LoRa Alliance lora-alliance.org/resource_hub/rp002-1-0-3-lorawan-regional-parameters/
- LoRaWAN certification programme , LoRa Alliance lora-alliance.org/lorawan-certification/
- ETSI EN 300 220, short range devices in the 25 MHz to 1000 MHz range , ETSI www.etsi.org/deliver/etsi_en/300200_300299/30022002/
- 47 CFR Part 15.247, operation in 902-928 MHz, 2400-2483.5 MHz and 5725-5850 MHz bands , FCC www.ecfr.gov/current/title-47/chapter-I/subchapter-A/part-15/subpart-C/section-15.247
Questions fréquentes
- La certification LoRaWAN remplace-t-elle la certification radio RED ou FCC ?
- Non. La certification LoRa Alliance est un programme prive de marque et d'interopérabilité. Elle ne se substitue jamais a la certification radio nationale. Un objet LoRaWAN doit obtenir a la fois la LoRaWAN Certification de l'Alliance (pour le logo et l'admission sur les réseaux publics) et la conformité RED en Union européenne (typiquement EN 300 220 pour la sous-bande 868 MHz) ou FCC Part 15.247 / Part 15.249 aux Etats-Unis (sous-bande 902-928 MHz).
- Quelle est la différence entre LoRa et LoRaWAN ?
- LoRa designe la modulation de couche physique, technique propriété intellectuelle de Semtech, mise en oeuvre dans les transceivers SX12xx. LoRaWAN designe le protocole de couche MAC défini et maintenu par la LoRa Alliance, qui s'appuie sur LoRa au niveau radio. Un objet certifie LoRaWAN integre nécessairement un transceiver LoRa Semtech ou un derive sous licence, mais la certification Alliance porte sur le comportement MAC et réseau, pas sur la modulation.
- Faut-il être membre de la LoRa Alliance pour certifier un objet ?
- Oui. Tout fabricant souhaitant soumettre un produit a la LoRaWAN Certification doit adhérer a la LoRa Alliance, au minimum en tant qu'Adopter. Les niveaux supérieurs (Contributor, Sponsor) donnent accès aux groupes de travail techniques et a la gouvernance, mais le statut Adopter suffit pour soumettre un dossier de certification end device.
- Que recouvrent les classes A, B et C des objets LoRaWAN ?
- La classe A est le mode de base : l'objet émet sur initiative propre, puis ouvre deux fenetres de réception courtes apres chaque émission. La classe B ajoute des fenetres de réception programmées, synchronisées sur un beacon de gateway. La classe C maintient la réception ouverte en permanence, hors émission. Toutes les fins d'objet LoRaWAN supportent A, mais B et C sont optionnelles et impactent la consommation.
- Un module precertifie LoRaWAN dispense-t-il de la certification du produit fini ?
- Partiellement. Un module precertifie (par exemple base sur Murata Type ABZ, Nordic, STMicro avec stack LoRaWAN) réduit la portée des essais a refaire mais ne dispense pas de soumettre le produit fini a la LoRa Alliance. Le fabricant doit déclarer l'objet, exécuter les essais LCTT applicables a sa configuration régionale et obtenir un certificat propre au produit fini.
- Pourquoi un objet certifie LoRaWAN 1.0.x ne fonctionne-t-il pas toujours sur un réseau 1.1 ?
- Les spécifications 1.0.x et 1.1 utilisent des schémas de dérivation de clés distincts. La 1.0.4, dernière révision de la branche 1.0, reste interopérable avec les réseaux 1.0.x. La 1.1 introduit une séparation entre clés d'application et clés de session réseau (AppSKey, FNwkSIntKey, SNwkSIntKey, NwkSEncKey) qu'un objet 1.0.x ne sait pas negocier. Un rekey ou une mise a jour de stack est nécessaire pour passer d'une famille a l'autre.
- Pourquoi un objet AS923 declare ne fonctionne-t-il pas dans tous les pays AS923 ?
- Le pack de parametres régionaux AS923 admet plusieurs sous-bandes (AS923-1, AS923-2, AS923-3, AS923-4) selon les allocations nationales. Un objet certifie AS923 doit déclarer la ou les sous-bandes supportées. Un produit certifie AS923-1 (Singapour) ne respectera pas nécessairement les plans de fréquence d'AS923-2 (Brésil, Indonesie) ou AS923-3 (Phillipines). La distinction doit être tracée dans le dossier de certification et la documentation produit.