Nouvelles fonctionnalités communes à ThingPark Enterprise SaaS et TPE auto-hébergé

Gestion de la passerelle: améliorations UI/UX

La version 7.1 de TPE apporte des améliorations significatives de l'UI/UX pour les Administrateurs Réseau de TPE et les Gestionnaires de Passerelle.

Plus de détails

Les principales améliorations sont énumérées ci-après :

• Meilleure organisation des widgets de la passerelle en onglets, avec l'onglet Vue de Base rassemblant toutes les informations nécessaires concernant la passerelle : ses informations de provisionnement, indicateurs de statut, emplacement, principaux graphiques radio et backhaul, indicateurs de charge système...

• Enrichissement des statistiques RF RDTP-12943

  • L'onglet Vue de Base inclut le widget principal RF "Historique du Trafic Radio". D'autres statistiques détaillées sont désormais affichées dans un onglet séparé Statistiques RF.

  • L'Historique du Trafic Radio affiche désormais le volume des trames uplink tardives (c.-à-d. en attente dans la passerelle en raison d'une déconnexion du backhaul)

  • Nouveau graphique de série temporelle pour la Puissance du Signal Évalué (ESP), dans le widget Force du Signal et Bruit.

    note

    ESP est une estimation de la puissance du signal utile LoRaWAN® reçue par la passerelle, en excluant le bruit de fond, tandis que RSSI regroupe la puissance reçue à la fois du signal utile et du bruit de fond.

  • Affichage de la portée/usage de chaque canal logique RF, c'est-à-dire s'il est utilisé pour uplink, downlink RX1 ou RX2, beacon de classe B ou pingslot.

  • Un nouveau widget dédié pour les statistiques du rapport cyclique.

  • Compteurs bruts agrégeant des événements spécifiques liés à la réception uplink, à la transmission downlink ainsi qu'aux événements du modem LoRa. Ces compteurs sont agrégés sur une période de mesure contrôlée par l'utilisateur (c'est-à-dire que la période de mesure peut être réinitialisée à tout moment depuis l'interface graphique de TPE, via le bouton "Réinitialiser les indicateurs").

    

• Enrichissement des statistiques de backhaul RDTP-12573:

  • L'onglet Vue de Base inclut les principaux widgets backhaul "Interfaces" (précédemment appelé "Réseaux") + "Trafic de backhaul avec le Network Server". D'autres statistiques détaillées sont désormais affichées dans un onglet séparé Statistiques de Backhaul.

  • De nouveaux widgets ont été ajoutés pour les indicateurs détaillés de chaque interface réseau (débit TX/RX, volume de trafic, délai aller-retour...) ainsi que les statistiques de backhaul entre la passerelle et chaque nœud du Network Server :

    

    

    note

    Les statistiques sont agrégées sur la période de rapport, cette période peut être réinitialisée par l'utilisateur en cliquant sur l'icône "Réinitialiser les indicateurs".

    

    

    

    

• Gestion avancée des antennes RDTP-12577:

  • Selon le nombre d'antennes configurées dans le profil de la passerelle, l'utilisateur peut configurer les détails des antennes dans un nouvel onglet Antennes.

  • De plus, les utilisateurs de TPE peuvent désormais configurer le gain d'antenne et l'atténuation du câble directement depuis l'interface graphique, sous les détails de l'antenne.

  • Parmi les détails d'antenne disponibles pour chaque antenne, l'utilisateur peut compléter des informations administratives supplémentaires qui pourraient être utiles pour débugger d'éventuels problèmes RF, comme la distance entre l'antenne RF LoRaWAN® et les antennes environnantes au cas où plusieurs antennes de technologies différentes seraient collocalisées. L'utilisateur peut également ajouter des images illustrant l'environnement d'installation et le positionnement de l'antenne.

• Administration/configuration avancée de la passerelle RDTP-12949:

  • Les widgets "Sécurité" et "Paramètres d'alarme pour faible activité Uplink" sont déplacés vers l'onglet Avancé, ensemble avec les

  • Nouvelles commandes administratives :

    • Redémarrer le Processus LRR : redémarre uniquement le packet forwarder applicatif, ce qui est plus rapide qu'un redémarrage complet de la passerelle

    • Démarrer/Arrêter le Downlink, pour activer/désactiver le mode de transmission du downlink.

  • Configuration avancée :

    • Nouvelle option pour activer/désactiver la fonctionnalité "Optimisation RX2", qui permet une sélection intelligente de la slot RX du downlink (RX1 ou RX2) pour maximiser la probabilité de réception du downlink et optimiser la capacité radio du downlink de la passerelle.

      note

      Cette fonctionnalité était activée par défaut avant la version 7.1.

    • Les paramètres de clé de déchiffrement de l'horodatage fin sont désormais gérés dans l'onglet Avancé. Cette configuration est uniquement requise lorsque la fonctionnalité de géolocalisation réseau TDoA est activée.

• Améliorations de l'analyse RF RDTP-12951:

  • Possibilité de définir les modalités d'analyse RF au cas où les paramètres par défaut ne répondent pas aux attentes de l'utilisateur. Les paramètres configurables incluent les fréquences de début/fin et le pas de l'analyse.

• Afficher les "Capteurs Servis" de chaque Passerelle RDTP-13716:

  • Objectif : afficher et exporter la liste des capteurs servis par chaque Passerelle, soit comme leur meilleure passerelle, soit parmi les trois meilleurs serveurs.

    Cette information est affichée dans un nouveau widget "Capteurs Servis" disponible dans l'onglet Vue de Base.

    note

    Les capteurs en itinérance (c'est-à-dire étrangers) ne sont pas répertoriés dans ce nouveau widget.

  • Les capteurs sont également affichés sur la carte s'ils ont des coordonnées valides.

    

• Mise à jour de l'indicateur Passerelle sur la carte RDTP-16386:

  • Une Passerelle est désormais représentée par un �A!�A�A indicateur.

  • La couleur de l'indicateur reflète l'état de santé de la passerelle.

• Présentation améliorée de la page détaillée de la passerelle :

  • Le nom de la passerelle est affiché dans le titre de la page, accompagné d'une icône indiquant l'auteur et la date de la dernière mise à jour sur cette Passerelle.

  • Nouvelle icône ajoutée en haut à droite de la page pour dupliquer une passerelle.

  • Le bouton "Supprimer la passerelle" existant dans les versions précédentes est désormais remplacé par l'icône en haut à droite .

  • Le lien pour télécharger l'image de la passerelle est maintenant présenté par l'icône en haut à droite de la page.

  • Modification plus facile des champs éditables, en cliquant directement sur le champ au lieu de cliquer sur un bouton . Les champs éditables sont affichés avec un fond gris.

Principaux avantages pour les clients

La fonctionnalité apporte une amélioration significative pour les Administrateurs Réseau de ThingPark Enterprise et les Gestionnaires de Passerelle. L'amélioration va bien au-delà de l'interface utilisateur pour améliorer l'expérience utilisateur globale et offrir des fonctionnalités enrichies liées aux tâches de supervision et de maintenance quotidiennes.

Davantage de détails sur les améliorations sont décrits dans la section "Description des Fonctionnalités".

Activation de la fonctionnalité

Les améliorations énumérées ci-dessus sont activées par défaut, elles ne peuvent pas être désactivées.

Limitations de la fonctionnalité

Aucune.

Gestion des capteurs : améliorations UI/UX

À partir de la version 7.1, la page détaillée du capteur est améliorée comme suit :

• Le nom du capteur est affiché dans le titre de la page, accompagné d'une icône indiquant l'auteur et la date de la dernière mise à jour sur ce capteur.

• Nouvelle icône ajoutée en haut à droite de la page pour dupliquer une passerelle.

• Le bouton "Supprimer le capteur" existant dans les versions précédentes est désormais remplacé par l'icône en haut à droite .

• Le bouton "Envoyer Downlink" existant dans les versions précédentes est maintenant remplacé par l'icône en haut à droite de la page.

• Le Capteur est désormais représenté par un indicateur sur la carte. La couleur de l'indicateur reflète l'état de santé de la passerelle.

• Modification plus facile des champs éditables, en cliquant directement sur le champ au lieu de cliquer sur un bouton . Les champs éditables sont affichés avec un fond gris.

Plus de détails

Avantages clés pour les clients

Amélioration de l'expérience utilisateur, assurant la cohérence entre l'ergonomie UI du capteur et de la passerelle.

Activation de la fonctionnalité

Les améliorations énumérées ci-dessus sont activées par défaut, elles ne peuvent pas être désactivées.

Limitations de la fonctionnalité

Aucune.

Enrichissement de la liste des Connecteurs IoT Flow TPX

ThingPark Enterprise 7.1 est livré avec une nouvelle version de ThingPark-X IoT Flow v1.6.

Cette nouvelle version d'IoT Flow apporte des connecteurs supplémentaires :

• Ginjer, permettant aux capteurs d'utiliser la plateforme d'application https://www.ginjer.io. Pour en savoir plus, consultez la documentation du connecteur Ginjer.

• Azure Event Hubs, permettant d'envoyer des uplinks vers Azure Event Hubs sans utiliser Azure IoT Hub.

• Microsoft Teams, cela permet d'envoyer des uplinks vers Microsoft Teams. L'utilisateur doit fournir son Webhook, et les uplinks sont affichés sur son canal.

• ThingsBoard, permettant aux capteurs d'utiliser la plateforme d'application https://www.ThingsBoard.io.

• Modbus (TPE auto-hébergé uniquement), ce nouveau connecteur supporte l'utilisation de Modbus en implémentant un esclave Modbus intégré, collectant les trames uplink et mappant les valeurs de Payload de l'application vers des registres conformément aux règles configurées. Pour en savoir plus, consultez la documentation du connecteur Modbus.

  note

  Pour supporter le mode serveur Modbus sur un TPE auto-hébergé, les flux entrants doivent autoriser en liste blanche les ports 502-507 lorsque le service TPX Iot-Flow est exécuté sur le TPE auto-hébergé.

• OPC-UA (TPE auto-hébergé uniquement), ce nouveau connecteur supporte OPC-UA en implémentant un serveur OPC-UA intégré, collectant les trames uplink et mappant les valeurs de Payload de l'application vers les registres configurés. Les états des capteurs et des passerelles sont également exposés sur ce serveur OPC-UA. Pour en savoir plus, consultez la documentation du connecteur OPC-UA.

  note

  Pour supporter le connecteur OPC-UA sur un TPE auto-hébergé, les flux entrants doivent autoriser en liste blanche les ports 4840-4845 lorsque le service TPX Iot-Flow est exécuté sur le TPE auto-hébergé.

Plus de détails

Principaux avantages pour les clients

Les nouveaux connecteurs offrent une intégration plus riche et sans faille avec de plus en plus de plateformes d'application IoT (telles que Ginjer et ThingsBoard).

De plus, le support des connecteurs Modbus et OPC-UA - largement utilisés dans les déploiements IoT industriels – ouvre des cas d'utilisation supplémentaires pour l'intégration dans le marché de l'IoT industriel et réduit le coût global de l'intégration TPE avec les applications métier dans de tels scénarios.

Activation de la fonctionnalité

Les nouveaux connecteurs sont directement disponibles lors de la migration de la plateforme ThingPark Enterprise vers la version 7.1.

Limitations de la fonctionnalité

Les connecteurs Modbus et OPC-UA sont disponibles uniquement pour TPE auto-hébergé, non pertinent pour TPE SaaS. De plus, ces deux connecteurs sont publiés en version bêta, en attendant des retours d'expériences consolidés des premiers adoptants.

Support du packet forwarder Basics Station de Semtech RDTP-9946 RDTP-16927

Avant la version 7.1, seules les passerelles utilisant le packet forwarder LRR pouvaient se connecter au réseau central de ThingPark.

À partir de la version 7.1, outre les passerelles utilisant LRR, toute passerelle utilisant Basics Station peut se connecter au réseau central de ThingPark.

Plus de détails

Pour en savoir plus sur le packet forwarder Basics Station, consultez la documentation de LoRa Basics™ Station.

L'intégration de ThingPark avec Basics Station ajoute deux nouveaux composants à l'infrastructure ThingPark :

• LNS bridge : médiateur entre le protocole Basics Station et le réseau central LRC.

• Serveur de configuration et de mise à jour, également connu sous le nom de CUPS.

note

La mise en œuvre de ce protocole dans la version 7.1 de ThingPark est limitée à l'accès initial et à la configuration. La mise à jour du logiciel Basics Station via CUPS est en dehors du cadre de cette version.

Le lien de backhaul BS vers le réseau central est sécurisé via TLS.

Principaux avantages clients

Grâce à cette nouvelle fonctionnalité, les utilisateurs de ThingPark peuvent facilement connecter leurs passerelles à la plateforme ThingPark sans attendre que les fabricants correspondants intègrent avec le Relais Longue Portée ThingPark (LRR).

Bien que le réexpéditeur de paquets avancé de LRR soit largement supérieur à Basics Station (ce dernier n'offrant que les fonctions de base, comme son nom l'indique), la capacité de ThingPark à s'intégrer ouvertement avec tous les modèles de passerelles sans exclusion supprime toute barrière potentielle à l'adoption de ThingPark.

Ainsi, les utilisateurs de ThingPark peuvent lancer leur parcours ThingPark avec n'importe quel modèle de passerelle utilisant LRR ou Basics Station, puis passer au réexpéditeur de paquets LRR pour leur déploiement industriel. Pour en savoir plus sur autres limitations de Basics Station, voir la section "Limitations de la fonctionnalité".

Activation de la fonctionnalité

Pour connecter une passerelle utilisant Basics Station à ThingPark, les étapes suivantes sont requises :

1. Installez le paquet de réexpéditeur Basics Station sur la passerelle si il n'est pas déjà présent.

2. Configurez les interfaces réseau de votre passerelle.

note

Contrairement à LRR's SUPLOG qui offre une interface GUI pour configurer vos interfaces réseau, Basics Station ne propose aucune interface terminale native, vous devez donc vous fier aux commandes CLI fournies par le fabricant de la passerelle pour réaliser cette configuration.

1. Configurer Basics Station : trois fichiers doivent être configurés :

   • cups.uri, il s'agit d'un fichier texte contenant l'adresse du serveur CUPS. La configuration dépend de la plateforme ThingPark cible. Par exemple, pour la plateforme communautaire, réglez sur https://community.thingpark.io:443.

   • cups.trust, il s'agit d'un fichier binaire contenant le certificat de l'autorité de certification pour le serveur CUPS au format DER. La configuration dépend de la plateforme ThingPark cible. Par exemple, pour la plateforme communautaire, réglé sur :

     # wget https://www.amazontrust.com/repository/AmazonRootCA1.cer
     # mv ./AmazonRootCA1.cer cups.trust

   • station.conf, il s'agit d'un fichier texte au format JSON, il contient les paramètres de configuration de Basics Station. La majorité du contenu du fichier devrait être fourni par le fabricant de la passerelle, mais vous devez au moins mettre à jour les paramètres de gain d'antenne et de niveau de journal (ce dernier devrait être configuré sur CRITICAL si vos journaux sont stockés sur SSD).

2. Provisionez votre passerelle dans l'interface ThingPark Enterprise :

   • Utilisez le Fabricant Générique

     

   • Ensuite, sélectionnez le modèle "Basics Station packet forwarder"

   • Définissez le LRR-UUID comme 0016C0-xxxxxxxxxxxxxxxx

     • xxxxxxxxxxxxxxxx étant l'ID de la passerelle fourni par le fabricant, souvent basé sur une référence matérielle comme l'adresse MAC.

     • Pour récupérer l'ID de la passerelle, vous pouvez obtenir le EUI de la station à partir des logs : il s'agit d'un ID6 (voir https://doc.sm.tc/station/glossary.html)

     • Dans l'exemple suivant :

       

       • station EUI: 8:ff:fe4a:bc32

       • 4 groupes de blocs de 16 bits : 0008:00ff:fe4a:bc32

       • ID de passerelle : 000800FFFE4ABC32

       • LRR-UUID : 0016C0-000800FFFE4ABC32

   • IPSec (X509) doit être activé, cela générera des certificats qui seront fournis par le serveur CUPS à la passerelle pour se connecter au cœur de réseau ThingPark.

   • Définissez la RF Region cible en fonction de votre bande ISM et du plan de canal cible, comme pour toute passerelle conventionnelle utilisant le LRR paquet forwarder.

     

Une fois que la passerelle a récupéré avec succès son certificat de sécurité, elle doit se connecter au réseau central de ThingPark, et l'état de la connexion doit être reflété dans l'interface TPE.

Limitations de la fonctionnalité

Le réexpéditeur de paquets Basics Station présente les limitations suivantes par rapport à Relais Longue Portée ThingPark (LRR) :

• Basics Station utilise un encodage de données JSON, qui n'est pas efficace du point de vue de la consommation de données pour les cas d'utilisation de backhaul cellulaire et satellite. ThingPark LRR utilise un protocole d'encodage binaire efficace, de sorte qu'il est considérablement plus compact/plus économe en bande passante.

• Les paquets uplink mis en tampon par la Station Basics pendant une déconnexion du réseau central backhaul BS ne sont pas marqués "Late", donc il n'y a pas de moyen simple pour les identifier par rapport aux paquets uplink signalés à temps, surtout si le BS n'est pas correctement synchronisé à temps.

• Basics Station ne fournit aucun support natif pour les fonctionnalités d'interfaces réseau telles que les mécanismes de basculement automatique des interfaces. Ces mécanismes sont supportés nativement par LRR.

• Basics Station ne fournit pas d'indication de transmission avec une cause d'erreur appropriée en cas d'échec de transmission d'un paquet downlink. Ainsi, une cause d'erreur générique « A6 : « Timeout de transmission » » est signalée par ThingPark lorsqu'une transmission DL échoue sur une passerelle utilisant le réexpéditeur de paquets Basics Station.

  note

  LRR fournit un large éventail de causes d'erreurs de transmission (LBT, modem occupé, dépassement de délai de transmission...).

• Contrairement à LRR, Basics Station ne fournit pas de rapports périodiques radio/backhaul/system vers le réseau central. En raison de cette limitation, les widgets du Network Manager suivants n'affichent aucune donnée pour les passerelles utilisant le transpondeur de paquets Basics Station :

  • Les widgets "Interfaces", "Backhaul Traffic with Network Server" et "System Load" sous l'onglet Basic View.

  • Widget "Compteurs" sous l'onglet Statistiques RF.

  • Tous les widgets de l'onglet Statistiques Backhaul, sauf les informations d'état de connexion.

• Basics Station ne prend pas en charge les commandes d'administration & de maintenance telles que redémarrage/redémarrage, accès à distance, démarrage/arrêt radio, sauvegarde/restauration. En conséquence, toutes les commandes administratives présentes dans l'onglet Advanced de l'application Network Manager ne peuvent pas être utilisées pour Basics Station (toutes sont supportées par LRR).

• Basics Station ne supporte aucune commande permettant de définir à distance le gain d'antenne et la perte de câble ; ces informations doivent donc être définies directement par l'administrateur de la passerelle dans le fichier local station.conf du logiciel Basics Station.

• Basics Station ne signale pas la position GPS de la passerelle, alors que LRR le fait. Par conséquent, seul le mode de localisation administratif est supporté pour les BS exécutant le packet forwarder Basics Station.

• Basics Station ne signale que des métadonnées uplink limitées, par exemple, il ne signale ni l'état/ la précision de l'horodatage fin ni l'écart de fréquence. Ces métadonnées sont intéressantes pour la géolocalisation de réseau TDoA, elles sont toutes signalées par le réexpéditeur de paquets LRR.

• Basics Station ne supporte pas IPSec, seul TLS est supporté. LRR supporte à la fois les modes de sécurité IPSec et TLS.

Bien que Basics Station prenne en charge le mode de classe B de LoRaWAN®, l'intégration actuelle avec ThingPark couvre uniquement le mode unicast pour les capteurs des classes A et C. De plus, les passerelles utilisant le design de référence v2 sont hors du périmètre de la version actuelle.

note

Cette fonctionnalité est actuellement disponible uniquement pour TPE SaaS, elle est actuellement en restriction pour TPE auto-hébergé. Cette limitation sera levée dès que les retours PoC sur SaaS seront consolidés.

Notification améliorée des alarmes par email

Avant la version 7.1, les utilisateurs TPE s'abonnent pour recevoir des alertes de capteur et/ou de passerelle par email. Une fois abonnés, ils étaient notifiés de toutes les alarmes actives levées indépendamment de leur état de gravité, c'est-à-dire, ils ne pouvaient pas demander de notification par email que pour les alarmes critiques.

À partir de la version 7.1, la configuration des notifications par email est améliorée pour permettre aux utilisateurs TPE de s'abonner uniquement aux alarmes ≥ un état de gravité spécifique N.

note

N fait référence à l'état de gravité minimum, cela peut être "Critical", "Major", "Minor", "Warning" ou "Indeterminate".

Plus de détails

Avec cette amélioration dans TPE 7.1, lorsqu'ils s'abonnent à l'état N, l'utilisateur reçoit une notification par email dans l'un des cas suivants :

• Une alarme est créée avec un état ≥ N.

• L'état d'une alarme (reconnue ou non) augmente et le nouvel état ≥ N.

• L’état d’une alarme non acquittée diminue et l’état initial state ≥ N (par exemple, l'alarme a été effacée).

Exemple Lorsque l'utilisateur s'abonne à l'état d'alarme "Major", une notification par email est envoyée pour toute alarme créée/mise à jour avec un état ≥ Major, c'est-à-dire que les alarmes en état Critical (ou les alarmes non reconnues modifiant leurs états de mineur à critique) sont également notifiées sans nécessiter l'abonnement explicite de l'utilisateur/admin.

Impact sur l'interface TPE

La nouvelle configuration peut être effectuée directement depuis l'interface TPE, via le panneau Settings dans le menu de gauche > widget Alarms :

Avantages clés pour les clients

Flexibilité accrue dans la configuration de la notification par email des alarmes, permettant aux utilisateurs TPE de se concentrer uniquement sur les alarmes de haute gravité si nécessaire.

Activation de la fonctionnalité

Cette amélioration est automatiquement disponible après la mise à niveau à la version 7.1.

Dans un souci de compatibilité ascendante, pour toutes les abonnements TPE déjà configurés avec une notification par email dans leur compte, toutes les destinations email configurées sont désormais associées à l'état Indeterminate afin que les utilisateurs continuent à recevoir notifications pour toutes les alarmes quelle que soit leur gravité.

Limitations de la fonction

Aucune.

Support d'en-têtes HTTP personnalisés pour les connexions Basic HTTP RDTP-7558

Cette fonctionnalité permet la personnalisation des en-têtes HTTP dans les requêtes de LRC vers AS sur l'interface de tunnel, également connue sous le nom de type de connexions HTTP de base :

• À partir de la version 7.1, les utilisateurs ThingPark peuvent définir jusqu'à 5 en-têtes HTTP personnalisés pour leurs connexions HTTP de base.

• Chaque en-tête HTTP personnalisé est statiquement défini dans l'administration GUI de TPE, en tant que chaîne de caractères (par ex., Authorization: Bearer AbCdEf123456).

• Lorsque de tels en-têtes HTTP personnalisés sont définis dans la configuration de la Connection, le LRC network server rapporte ces en-têtes HTTP personnalisés dans toutes les requêtes HTTP sortantes via l'interface tunnel LRC-AS vers des Application Servers externes utilisant le protocole HTTP.

  

note

Un maximum de 5 en-têtes HTTP personnalisés peut être défini. La longueur maximale d'un en-tête HTTP (nom + valeur) est de 510 caractères.

Plus de détails

Chaque en-tête HTTP personnalisé est composé de deux champs :

1. Nom de l'en-tête :

   • Regex est aligné avec RFC 7230 : \^(\[!#\$%&'\*+\\-.\^\|~\w])+$`

   • Noms interdits : "Accept", "Host", "User-Agent", "Content-Length", "Content-Type", "Expect" et "Proxy-Authorization".

   • Un nom d'en-tête donné, ne peut être configuré qu'une seule fois (insensible à la casse).

2. Valeur de l'en-tête : le Regex est aligné avec RFC 7230, c'est-à-dire, \^(\[\x21-\x7e\]((\[ \t\])+\[\x21-\x7e\])?)+\$

Considération spécifique pour l'en-tête "Authorization" :

• L'en-tête "Authorization" peut être explicitement défini comme un en-tête HTTP personnalisé, mais il peut également être généré implicitement par le LRC lorsque l'URL de destination contient un login/mot de passe (par exemple : http://username:password@application.com).

• Lorsque les deux sont définis, le LRC donne la priorité au login/mot de passe défini dans l'URL.

Avantages clés pour les clients

Cette fonctionnalité offre une flexibilité supplémentaire aux développeurs d'applications, permettant une intégration plus facile avec les serveurs d'applications tiers utilisant le protocole HTTPS.

Grâce à cette fonctionnalité, les abonnés ThingPark peuvent ajouter des champs personnalisés à l'en-tête HTTP envoyé par le LRC Network Server aux Application Servers externes. Les en-têtes personnalisés peuvent être utiles dans de nombreux cas d'utilisation tels que sécurité/authentification supplémentaire, via l'en-tête "Authorization".

Activation de la fonctionnalité

Cette fonctionnalité est directement disponible après que la plateforme TPE soit mise à niveau vers la version 7.1.

Pour activer l'utilisation des en-têtes HTTP personnalisés, l'utilisateur doit les définir explicitement dans l'interface TPE.

Limitations de la fonctionnalité

Seuls les en-têtes statiques sont supportés. De plus, les en-têtes ne peuvent pas être personnalisés pour chaque capteur, c'est-à-dire que le même en-tête est utilisé pour tous les capteurs associés à une connexion AS donnée.

[ADRv3]: Sauver rapidement le bilan de liaison en cas de dégradation soudaine RDTP-848

À partir de la version 7.1, dès que le LRC Network Server détecte une augmentation du taux d'erreur de paquets instantané du capteur (également appelé short-term PER) au-delà d'un seuil configurable, il déclenche un nouveau mode "rescue" (ou de récupération) afin d'appliquer une combinaison conservatrice de :

• TxPower (typiquement la puissance maximale autorisée par la réglementation locale et la capacité matérielle du capteur)

• + Facteur d'étalement (généralement SF10 ou supérieur, pour maximiser les chances de la passerelle de démoduler avec succès les trames uplink, grâce à la meilleure sensibilité Rx des débits de données plus bas/FP plus élevés)

• + nombre de répétitions (pour offrir à la fois une diversité de fréquence et de temps).

Plus de détails

Exemple LRC reçoit FCntUp # 50 d'un capteur donné, puis la prochaine trame uplink reçue a FCntUp # 60 -> taux d'erreur de paquet instantané = 9/11 (c'est-à-dire 9 perdus sur 11 envoyés par le capteur) = 0,8181 (81,81 %) > Max_Short_Term_PER (0,8 par défaut) -> déclenche le mode de secours ADR -> LRC envoie LinkADRReq avec :

• TxPower=0 (c'est-à-dire, puissance max/EIRP)

• DataRate = 0 (SF12)

• NbTrans= 3 (3 transmissions par trame UL individuelle).

note

La récupération TxPower/SF/NbTrans est configurable dans la RF Region, comme décrit dans la section "Activation des fonctions".

Après que le capteur applique la commande de récupération ADR, les machines d'état normal ADRv3 restent applicables, essayant de trouver la meilleure combinaison de TxPower/SF/NbTrans pour ce capteur en fonction de ses conditions de réception RF actuelles, plutôt que de rester en permanence à la puissance TxMax, SFMax et 3 transmissions par paquet uplink.

Principaux bénéfices pour les clients

Meilleure réactivité en cas de dégradation soudaine des conditions de réception RF, par exemple, dans les situations suivantes :

• Panne temporaire de la meilleure passerelle desservant le capteur, entraînant une forte dégradation du bilan de liaison RF et une perte de chemin accrue pour atteindre des passerelles plus éloignées.

• Un capteur a été déplacé d'un endroit à un autre sans réinitialiser l'ADR-bit à 0 dans l'en-tête MAC LoRaWAN® des paquets uplink, avec des conditions de réception uplink plus difficiles dans le nouvel emplacement.

Activation de la fonction

Cette amélioration est automatiquement disponible dans la version 7.1.

De nouveaux paramètres de RF Region sont ajoutés pour contrôler ce nouveau comportement :

• Max_Short_Term_PER : Ce paramètre définit le taux maximum d'erreur de paquets instantané/à court terme détecté par le LRC Network Server avant de déclencher le mécanisme de sauvetage RF.

  • Par défaut = 0,8 (c'est-à-dire 80 %), ce qui signifie que le mécanisme de secours est déclenché dès que plus de 8 trames uplink consécutives sont perdues pour un capteur donné.

• RecoverySF : Facteur d'étalement demandé par ADRv3 pour accélérer le processus de récupération RF, il est notifié dans la commande de secours LinkADRReq MAC envoyée au capteur.

  • Valeur par défaut : SF12.

  • Il doit être explicitement réglé ≤ SF10 dans les bandes ISM qui ne prennent pas en charge SF11/SF12, par exemple les RF regions US915 ou les pays AS923 qui imposent un uplink dwell time = 400 ms.

    note

    C'est déjà le cas pour le catalogue RF Region depuis la version v1.5.0.

• RecoveryNbTrans : nombre de copies de transmission de chaque compteur de trame uplink demandé par ADRv3 pour accélérer le processus de récupération RF, il est notifié dans la commande de secours LinkADRReq MAC envoyée au capteur.

  • Valeur par défaut : 3.

• RecoveryTxPower : puissance de transmission du capteur demandée par ADRv3 pour accélérer le processus de récupération RF, elle est notifiée dans la commande de secours LinkADRReq MAC envoyée au capteur.

  • Valeur par défaut : égale à MaxEIRP/MaxPower.

note

RecoverySF, RecoveryNbTrans et RecoveryTxPower sont également utilisés par la fonctionnalité Support mobile base stations providing temporary RF coverage RDTP-13613.

Limitations de la fonction

Aucune.

Supporter les passerelles mobiles fournissant une couverture RF temporaire RDTP-13613

À partir de la version 7.1, une passerelle peut être associée à l'un des trois types suivants de couverture RF :

• Permanent (réglage par défaut) : la PS fournit une couverture RF permanente aux capteurs environnants. En conséquence :

  • La réception des paquets uplink via cette PS est prise en compte dans les décisions ADR.

  • Cette PS peut être utilisée pour router les paquets downlink pour toutes les classes de capteurs A/B/C, avec le même algorithme que les versions précédentes.

    note

    C'est le paramètre utilisé pour toutes les passerelles après la mise à jour vers TP7.1, dans un souci de compatibilité avec les versions précédentes.

• Temporaire et mobile : la passerelle n'a pas d'emplacement fixe; elle assure une couverture RF temporaire aux capteurs environnants. C'est généralement utilisé pour les cas d'utilisation "walk-by" ou "drive-by". En conséquence :

  • Si le même paquet uplink est reçu à la fois par des passerelles permanentes et temporaires, la réception via la PS temporaire n'impacte pas les décisions ADR. La PS temporaire n'est pas non plus éligible pour router le trafic DL.

  • Sinon, si le paquet uplink est reçu uniquement par la PS temporaire, le capteur est supposé être hors couverture des passerelles permanentes avec son débit de données actuel/TxPower/nombre de répétitions. Ainsi, le réseau déclenche le mode de récupération RF pour ce capteur, en envoyant une commande LinkADRReq MAC demandant au capteur d'utiliser le RecoverySF (défini par défaut à la plus haute SF autorisée), le RecoveryTxPower (défini par défaut à la puissance Tx maximale autorisée) et le RecoveryNbTrans (défini à 3 transmissions par défaut).

    note

    Les algorithmes ADR nominaux sont désactivés pendant ce mode de récupération.

  • Cette PS peut être utilisée pour router les paquets downlink uniquement pour les capteurs de classe A, car il n'est pas garanti que cette PS mobile reste à proximité du capteur en modes classe B/C.

• Temporaire et stationnaire : la passerelle a une localisation statique pour une période de plusieurs jours, jusqu'à quelques semaines, mais elle ne fournit pas de couverture RF permanente. C'est généralement le cas des passerelles saisonnières déployées pour augmenter temporairement la couverture/capacité RF lors d'événements spécifiques.

  • Le même traitement UL/DL décrit en mode "temporaire et mobile" s'applique à ce mode "temporaire et stationnaire", avec une seule différence : Cette PS peut être utilisée pour router les paquets downlink pour les capteurs de classe B/C en plus des classes A.

    note

    Cette passerelle doit être passée en "temporaire et mobile" une fois qu'elle quitte son emplacement temporaire, pour éviter la perte des paquets de classe B/C en DL.

Plus de détails

Avantages clés pour les clients

Grâce à cette fonctionnalité, les administrateurs du réseau d'accès radio (RAN) peuvent déployer des passerelles fournissant une couverture RF temporaire sans compromettre le fonctionnement radio à long terme des capteurs environnants.

• Cela est particulièrement utile pour les cas d'utilisation "drive-by" ou "walk-by" pour récupérer des mesures de capteurs dans des endroits difficiles à couvrir, tels que les compteurs d'eau situés dans des sous-sols.

• De plus, dans des scénarios de déploiement spéciaux où la couverture LoRaWAN® est manquante ou très médiocre, une couverture temporaire serait établie en levant une passerelle dans les airs avec un drone.

• De plus, des passerelles mobiles pourraient être utilisées pour secourir la couverture RF des capteurs qui utilisent initialement des réglages ADR agressifs (par exemple, SF7 avec réduction de puissance) tandis que la configuration RAN actuelle exige que ces capteurs utilisent des valeurs plus élevées de SF/TxPower.

  Exemple La meilleure passerelle servant certains capteurs tombe en panne tandis que ces capteurs utilisent actuellement SF7. Pour permettre aux passerelles environnantes de desservir ces capteurs, l'administrateur RAN peut déployer une PS temporaire pour capturer le trafic SF7 de ces capteurs tout en les basculant vers des SF/TxPower/NbTrans plus élevés via le mode de récupération RF.

Activation de la fonction

Cette fonctionnalité est automatiquement disponible après la mise à niveau de la plateforme vers la version 7.1.

Après la mise à jour, toutes les passerelles sont automatiquement configurées avec le type de couverture RF "permanent".

Un nouveau paramètre est ajouté dans l'interface d'administration TPE pour indiquer le type de couverture RF de chaque passerelle. L'administrateur de la passerelle peut changer le type de couverture RF à tout moment, dans le tableau de bord détaillé de la passerelle > onglet Avancé > widget Configuration.

Le mode de récupération RF décrit dans la section "Description des fonctions" est contrôlé par trois paramètres de RF Region :

• RecoverySF : facteur d'étalement demandé par le réseau lorsque le capteur n'est joignable que par des passerelles temporaires. Cela est notifié dans la commande MAC LinkADRReq de secours envoyée au capteur via la PS temporaire.

  • Valeur par défaut : SF12.

  • Il doit être explicitement réglé ≤ SF10 dans les bandes ISM qui ne prennent pas en charge SF11/SF12, par exemple les RF regions US915 ou les pays AS923 qui imposent un uplink dwell time = 400 ms.

    note

    C'est déjà le cas pour le catalogue RF Region depuis la version v1.5.0.

• RecoveryNbTrans : nombre de copies de transmission de chaque trame uplink, demandé par le réseau lorsque le capteur n'est joignable que par des passerelles temporaires. Cela est notifié dans la commande MAC de secours LinkADRReq envoyée au capteur via la PS temporaire.

  • Valeur par défaut : 3.

• RecoveryTxPower : puissance de transmission du capteur demandée par le réseau lorsque le capteur n'est joignable que par des passerelles temporaires. Cela est notifié dans la commande MAC LinkADRReq de secours envoyée au capteur via la PS temporaire.

  • Valeur par défaut : égale à MaxEIRP/MaxPower.

note

RecoverySF, RecoveryNbTrans et RecoveryTxPower sont également utilisés par la fonctionnalité [ADRv3]: récupérer rapidement le déficit de liaison en cas de dégradation soudaine RDTP-848.

Limitations de la fonctionnalité

Les passerelles associées aux types "Temporaire et mobile" ou "Temporaire et stationnaire" ne peuvent pas contribuer à l'itinérance passive. Cette limitation est due à l'absence de la notion de "PS temporaire" dans la spécification des Interfaces Backend LoRaWAN®.

Mettre à jour les priorités de planification des downlinks selon LoRaWAN® 1.0.4 RDTP-16249

Avant la version 7.1, lorsque la taille maximale du payload MAC downlink ne permettait pas d'intégrer à la fois le payload applicatif et les commandes MAC, la priorité était donnée au payload applicatif.

À partir de la version 7.1, et conformément à la spécification LoRaWAN® 1.0.4, la priorité est donnée aux commandes DL MAC sur le payload applicatif DL, selon l'ordre de priorité suivant extrait de la spécification LoRaWAN® 1.0.4 (tableau 15) :

Plus de détails

Pour en savoir plus sur la spécification LoRaWAN® 1.0.4, consultez le site de ressources de l'Alliance LoRa.

Principaux bénéfices pour les clients

• Alignement complet avec la dernière specification LoRaWAN®.

• Transmission plus rapide des commandes MAC cruciales requises pour le fonctionnement optimal de la couche MAC du capteur, par exemple, configurer les paramètres de temps de séjour pour AS923, mettre à jour le masque de canal pour US915, passer le capteur à un débit de données inférieur avec l'algorithme ADR pour atténuer la perte de paquets...

Activation de la fonctionnalité

Cette fonctionnalité est automatiquement activée pour tous les capteurs LoRaWAN® dans la version 7.1, elle ne peut pas être désactivée.

Limites des fonctionnalités

Aucune.