Objenious Developer Program

Testez, prototypez, concevez vos solutions connectées

Les capteurs

Implémentation

Le protocole LoRaWAN™ est relativement simple pour permettre son implémentation dans une large gamme d’objets ne disposant pas nécessairement d’une puissance de calcul importante et opérant principalement sur pile, de nombreux cas d’usage ayant comme objectif une durée de vie de plusieurs années en émettant seulement quelques messages par jour. Pour cela, le protocole définit notamment trois classes d’objets (A, B et C) qui se distinguent par une latence plus ou moins forte dans la communication descendante (downlink) du réseau vers l’objet. La classe A étant commune à tous les objets, les classes B et C sont des fonctionnalités supplémentaires ajoutées à la classe A.

Classe A :

  • L’émission de messages (uplink) est à l’initiative de l’objet. Une fenêtre d’écoute est ouverte quelques secondes après pour la réception éventuelle d’un downlink.
  • Elle est principalement destinée aux objets sur pile nécessitant de recevoir peu de downlinks ou sans besoin d’une latence faible.

Classe B :

  • Des fenêtres d’écoute périodiques et synchronisées avec le réseau sont ouvertes, même sans l’émission d’un uplink.
  • Elle consomme plus d’énergie et est principalement destinée aux objets nécessitant d’être contrôlés via downlink avec peu de latence.

Classe C :

  • L’objet est en écoute permanente (hormis lorsqu’il émet un uplink).
  • Elle est principalement destinée aux objets alimentés sur secteur et permet de ne pas avoir de latence sur les downlinks.

Méthodes d’activation

Le protocole LoRaWAN™ dispose de deux méthodes d’activation pour autoriser un objet à communiquer sur le réseau.

OTAA : Over-The-Air Activation

C’est la méthode favorisée par Objenious et la seule disponible sur son réseau.

L’activation d’un objet se fait après un premier échange de messages entre l’objet et le réseau (nommés JoinRequest et JoinAccept).

Les clés de session permettant l’authentification et le chiffrement des messages sont générées suite à cet échange, avant d’être stockées dans l’objet.

ABP : Activation By Personalisation

Les clés de session permettant l’authentification et le chiffrement des messages sont stockées dès le départ dans l’objet, au moment de sa fabrication, ou plutôt de sa personnalisation.

Identifiants

Les différents identifiants permettant une activation sur le réseau sont les suivants :

Identifiant Description OTAA ABP
DevEUI Identifiant unique de l’objet Requis Recommandé
AppEUI Identifiant de l’entité pouvant gérer les JoinRequest de l’objet Requis Non requis
AppKey Clé primaire stockée dans l’objet permettant la procédure d’OTAA Requis Non requis
DevAddr Adresse de l’objet sur le réseau Généré Enregistré
NwkSKey Clé permettant de vérifier l’intégrité des messages Généré Enregistré
AppSKey Clé permettant de chiffrer les messages Généré Enregistré