Un appareil OTAA doit s’enregistrer (join) avant que le serveur réseau n’accepte ses données. Cette page suit une demande de join à travers chaque contrôle, afin que vous puissiez voir, à partir de l’état du join ou du journal des trames, à quel endroit un join en échec s’arrête.
Les étapes
- L’appareil envoie une demande de join. Elle contient le JoinEUI, le DevEUI, un DevNonce (un nombre choisi par l’appareil) et un code d’intégrité (MIC) calculé avec l’AppKey.
- Les passerelles la transmettent. Les copies provenant de plusieurs passerelles sont fusionnées, comme pour toute trame montante.
- Le DevEUI est recherché. Le serveur réseau recherche le DevEUI dans l’annuaire à l’échelle de la plateforme.
- Non enregistré nulle part : si l’un de vos profils est en mode appairage et que la demande correspond à sa clé AppKey partagée, l’appairage prend le relais (voir Mode appairage). Sinon, la demande est rejetée avec DevEUI inconnu.
- Enregistré dans une autre organisation : rejeté avec Appareil d’un autre réseau. Vous n’en apprenez rien de plus.
- L’enregistrement de l’appareil est vérifié.
- Un appareil ABP qui envoie une demande de join est refusé (Appareil ABP a envoyé une demande de join).
- Un appareil retenu par le mode appairage est refusé (En attente d’approbation).
- Un appareil sans clé est refusé (Aucune AppKey enregistrée).
- Le JoinEUI est comparé à celui enregistré, sauf si l’appareil accepte n’importe quel JoinEUI. Un JoinEUI différent est refusé (Join refusé : autre JoinEUI).
- Le code d’intégrité est vérifié avec l’AppKey (celle de l’appareil, ou la clé partagée du profil pour les appareils ajoutés par appairage). Une non-concordance est refusée (Join refusé : mauvaise AppKey ?).
- Le DevNonce est vérifié (voir ci-dessous). Un DevNonce déjà utilisé est refusé (Join refusé : DevNonce déjà utilisé).
- Une session est créée. Le serveur réseau choisit une adresse d’appareil (DevAddr) libre dans son réseau, dérive les deux clés de session et les stocke chiffrées. La nouvelle session reste en attente jusqu’à la première trame montante de l’appareil.
- La réponse de join est envoyée. Elle passe par la meilleure passerelle capable encore d’atteindre l’appareil : 5 secondes après la demande (RX1, même canal) ou 6 secondes après (RX2, 869,525 MHz, DR0). La réponse indique à l’appareil son adresse, le délai RX1 de son profil (5 s par défaut), le décalage de débit RX1, le débit RX2 et cinq canaux EU868 supplémentaires.
- L’appareil envoie sa première trame montante avec la nouvelle session. À partir de là, ses trames sont acceptées.
Lorsque tous les contrôles sont réussis, le badge de join de l’appareil indique Joined, et son appareil reçoit les attributs lora.devAddr et lora.joinedAt.
Si aucune passerelle ne peut utiliser l’une des deux fenêtres (toutes hors ligne, désactivées ou à court de budget de duty-cycle), la session est créée mais la réponse n’est pas envoyée. Le badge de join indique alors Réponse de join non envoyée (aucune passerelle à temps) et l’appareil réessaiera.
Un appareil refusé ne reçoit jamais de réponse. LoRaWAN n’a pas de message « join rejeté » : l’appareil réessaie simplement plus tard.
Règles du DevNonce
Le DevNonce empêche quiconque de rejouer une ancienne demande de join.
| Version LoRaWAN | Règle |
|---|---|
| 1.0.4 | Chaque DevNonce doit être supérieur au dernier accepté. |
| 1.0.2 et 1.0.3 | Un DevNonce ne doit pas avoir été utilisé auparavant. Les 256 dernières valeurs sont mémorisées. |
Un appareil qui redémarre et recommence son DevNonce à 0 (1.0.4), ou choisit une valeur déjà utilisée (1.0.2, 1.0.3), est refusé jusqu’à ce qu’il utilise une nouvelle valeur. Définir une nouvelle AppKey pour l’appareil efface son historique de DevNonce.
États du join
L’onglet LoRaWAN de l’appareil affiche un badge de join :
| Badge | Signification |
|---|---|
| Pas encore joint | Aucun join enregistré et aucune session. |
| Joined | Le dernier join a été accepté, ou l’appareil dispose d’une session active. |
| Join refusé : mauvaise AppKey ? | Le contrôle d’intégrité a échoué. |
| Join refusé : DevNonce déjà utilisé | La protection contre le rejeu a refusé le DevNonce. |
| Join refusé : autre JoinEUI | Le JoinEUI diffère de celui enregistré. |
| Réponse de join non envoyée (aucune passerelle à temps) | Tous les contrôles ont réussi, mais aucune passerelle n’a pu envoyer la réponse. |
| Aucune AppKey enregistrée | L’appareil n’a pas de clé pour effectuer la vérification. |
| En attente d’approbation | Ajouté par le mode appairage, pas encore approuvé. |
| Appareil ABP : il ne fait pas de join | Un appareil ABP a envoyé une demande de join. |
| Join refusé (motif) | Tout autre refus, avec son code. |
Via l’API, la liste des appareils accepte le filtre joinState avec joined, refused ou never.
Réinitialiser la session
Réinitialiser la session dans l’onglet LoRaWAN de l’appareil met fin à la session en cours de l’appareil. Ses trames montantes sont refusées tant qu’il ne rejoint pas à nouveau.
Utilisez-la après une réinitialisation de l’appareil aux paramètres d’usine, ou après avoir modifié ses clés, afin qu’aucune ancienne session ne subsiste. Confirmez Réinitialiser la session : « L’appareil doit rejoindre à nouveau avant que ses trames montantes soient acceptées. Utilisez-la après une réinitialisation de l’appareil ou la modification de ses clés. »
Réinitialiser la session ne fait pas rejoindre l’appareil : celui-ci doit lancer lui-même un join (redémarrage, ou bouton de join). Cette action n’est pas disponible pour les appareils ABP. Chaque réinitialisation est journalisée sous iot_lorawan.device.session_reset.