Lorawan-stack: Liens descendants rejetés par les passerelles pour certaines puissances TX

Une erreur semble se produire avec Lora-net/packet_forwarder . Code pertinent: https://github.com/Lora-net/packet_forwarder/blob/master/lora_pkt_fwd/src/lora_pkt_fwd.c#L2517 -L2527

Avec les configurations de passerelle qui ont été distribuées via TTN (https://github.com/TheThingsNetwork/gateway-conf/), les puissances TX suivantes sont acceptées par les passerelles:

-6 , -3 , 0 , 3 , 6 , 10 , 11 , 12 , 13 , 14 , 16 , 20 , 23 , 25 , 26 , 27

Dans The Things Stack, nous utilisons la même liste lorsque nous construisons la configuration dynamique pour les passerelles: https://github.com/TheThingsNetwork/lorawan-stack/blob/master/pkg/pfconfig/shared/shared.go#L259 -L276

Cela signifie que le _ERROR: Packet REJECTED, alimentation RF non prise en charge pour TX-11_ est juste une mauvaise configuration de la passerelle, mais les autres rapports sont valides.

Je soupçonne que ceux-ci sont causés par un serveur de passerelle v3 envoyant une valeur de puissance TX non prise en charge. Nous devons nous assurer que le GS n'envoie les valeurs de puissance TX aux passerelles UDP que si elles figurent dans la liste des puissances TX prises en charge.

Des mises à jour ou des informations récentes à ce sujet?

Pouvez-vous s'il vous plaît ajouter un rapport à https://status.thethings.network/ ? Merci!

https://status.thethings.network/ est destiné aux incidents réseau. Ce n'est pas le bon endroit pour ça. Nous publierons une nouvelle mise à jour où le serveur vérifiera la puissance TX prise en charge avant l'envoi.

Salut Kirshna,

Pouvez-vous être un peu plus précis quand cette mise à jour sera publiée? De nombreuses personnes attendent ce correctif.

Au fait, que voulez-vous dire par "vérifiera la puissance TX prise en charge avant d'envoyer"? Le serveur s'assurera-t-il que la puissance d'émission est «standard» ou abandonnera-t-il le paquet?

Merci pour ton aide

https://status.thethings.network/ est destiné aux incidents réseau.

Juste pour exprimer que je pense que c'est très rigide. C'est un problème opérationnel pour certains, non? Au moins pour certains utilisateurs, les appareils passent à SF12 car ils ne reçoivent pas de liaisons descendantes ADR, et d'autres voient soudainement l'échec de l'OTAA. Sans accès à un journal de passerelle, ils ignorent la cause, d'autant plus que tout fonctionnait bien jusqu'à récemment, quelque chose a été changé pour le routage du trafic V2. (Ou quelque chose comme ça; il n'y a pas non plus de communication claire sur ces changements.)

@avbentem : Cela ne serait pas classé comme un problème opérationnel car il est lié au comportement du logiciel et non à la connectivité / débit / disponibilité, etc. Cependant, je comprends qu'il est important de le corriger. Vous pouvez vous attendre à un correctif dans les prochains jours.
PS: Vous avez tout à fait raison. Ce changement n'a pas été communiqué correctement.

Ce changement n'a pas été communiqué correctement.

À part: il n'est jamais trop tard pour au moins résoudre ce problème? Je ne sais pas du tout ce qui a changé, et quand, et si les gens devraient regarder V2 ou V3 lors du débogage des problèmes,

Je suis très heureux, disons, d'un message sur le forum ou quelque chose sur https://www.thethingsnetwork.org/updates à propos de ce changement et des changements futurs. Merci!

Nous venons de déployer un correctif qui devrait inverser le comportement. J'attendrai quelques commentaires avant de terminer.

Merci Krishna!
Pouvez-vous nous donner quelques détails sur ce qui a été corrigé? Ne blâmer personne, simplement parce que cela nous aiderait à mieux comprendre les problèmes que nous avions avec nos passerelles et nos transitaires et à nous assurer que le comportement que nous avons observé était causé par ce changement.

Le changement était essentiellement le suivant:

assurez-vous que le GS n'envoie les valeurs de puissance TX aux passerelles UDP que si elles figurent dans la liste des puissances TX prises en charge

https://github.com/TheThingsNetwork/lorawan-stack/issues/2106#issuecomment -596502171

En plus de ce changement, nous avons découvert que la conversion de la puissance TX dans les liaisons descendantes reçues des systèmes v2 n'était pas effectuée correctement, entraînant une différence de 3 dBm (11 aurait dû être 14; 17 aurait dû être 20 et 24 aurait dû être 27). Cela a également été corrigé.

Merci pour les détails, "_24 aurait dû être 27_" est exactement ce qui a causé nos problèmes. En connaissant ce détail, nous n'avons plus besoin de déboguer le GW sur site.

Je n'ai plus pu reproduire le problème de mon côté. Merci pour la mise à jour!

Merci, @htdvisser et @KrishnaIyer. Puisque cela est en quelque sorte lié à la connexion de V2 et V3: pouvez-vous s'il vous plaît documenter quelque part comment les choses sont connectées de nos jours, pour le réseau communautaire?

Apparemment, comme cela a été brièvement annoncé lors de la conférence de fin janvier 2020, le trafic des passerelles qui ont été configurées dans V2 est acheminé via V3? Peut-être que j'ai manqué quelque chose, mais je ne sais vraiment pas quels composants de V2 sont encore utilisés et ce qui est maintenant délégué à V3. De plus, on ne sait pas quand les modifications ont été apportées.

(Comme: le réseau communautaire utilise toujours la console V2 TTN, et cela fonctionne bien. Je suppose également que l'ADR est toujours géré par V2, car https://github.com/TheThingsNetwork/ttn/issues/767 est toujours signalé pour Appareils OTAA qui ont rejoint avant octobre 2019. Mais étant donné que le problème ci-dessus a été résolu dans la V3, quelque chose est également fait par la V3? Savoir quand les choses ont changé pourrait aider le débogage futur.)

@dermatthias

nous n'avons plus besoin de déboguer le GW sur site

Notez que cela peut toujours être une bonne idée de corriger également le côté de la passerelle, d'implémenter un mécanisme de secours pour les modifications futures ou pour une utilisation future de la V3? Je ne suis pas sûr ; voir quelques commentaires de Slack sur https://www.thethingsnetwork.org/forum/t/error-packet-rejected-unsupported-rf-power-for-tx-24/34833/14

Je ne vois pas comment cela a résolu le problème lorsque quelqu'un a (par exemple) une antenne 5dBi sur sa passerelle. S'ils laissent le gain d'antenne dans le fichier de configuration à 0 dBi, ils dépasseront la puissance de transmission maximale légale et s'ils modifient le fichier de configuration à 5 dBi, il y aura des cas où le paquet sera rejeté par la passerelle.

répondez à @avbentem :

Étant donné que nos grappes de réseaux communautaires ont toutes une apparence différente et que les choses changent constamment, cela nous coûterait trop de temps pour maintenir une vue d'ensemble à jour de la façon dont les choses sont connectées dans chaque région.

Dans l'image ci-dessous, vous verrez comment les passerelles peuvent se connecter à un réseau v2. L'ancienne situation (jaune) sera lentement migrée vers la nouvelle situation (verte). Pour ce faire, nous acheminons d'abord un petit pourcentage du trafic pour un protocole de passerelle donné via les nouveaux composants et augmentons lentement ce pourcentage. Idem pour les autres protocoles de passerelle.

Comme @johanstokking l'a mentionné lors de sa présentation à la conférence, de nombreuses passerelles de réseau communautaire se connectent déjà via un serveur de passerelle v3, et nous connectons lentement plus de passerelles via des serveurs de passerelle v3 au fil du temps.

En dehors de ces serveurs de passerelle, l'ensemble du réseau communautaire public exécute toujours des composants v2.

répondez à @ tonysmith55 :

Ce n'est pas le cas. Cela change simplement le comportement de ce qu'il était avant. Oui, il est (et sera toujours) possible que les passerelles dépassent la puissance de transmission maximale légale si ces passerelles n'ont pas été correctement configurées par leurs propriétaires.

J'espère que cela répond à vos questions. Puisque nous allons un peu hors sujet ici, et que ce problème est maintenant confirmé pour être résolu, je vais maintenant fermer le problème.