Nouvelles fonctionnalités

Cette page regroupe toutes les nouvelles fonctionnalités de ThingPark Enterprise apportées par les différentes versions logicielles 8.1.x. Consultez le changelog 8.1 pour en savoir plus sur la répartition de ces fonctionnalités par version de maintenance.

Les fonctionnalités décrites sur cette page sont communes aux produits SaaS et TPE auto-hébergé.

Intégrer une sonde de capteur virtuel dans les passerelles RDTP-3399

À partir de la version 8.1, les gestionnaires de passerelles peuvent activer des sondes RF sur leurs passerelles. Une sonde RF agit comme un capteur virtuel intégré à une passerelle, faisant que la passerelle se comporte comme un capteur et envoie des trames uplink périodiques reçues par les passerelles environnantes.

Le but de ces trames uplink est de tester la qualité RF du réseau LoRaWAN et de détecter tout dysfonctionnement RF éventuel sur la passerelle émettrice ou réceptrice. La nature déterministe du trafic des sondes RF facilite l'identification des problèmes radio sans être affecté par l'aléa du trafic LoRaWAN généré par de vrais capteurs.

Les détails de la sonde RF sont visibles dans l'interface utilisateur, dans l'onglet RF probe des détails de la passerelle.

De plus, le trafic des sondes RF est visible dans Wireless Logger en sélectionnant LoRaWAN RF probes en haut à droite de l'écran.

Plus de détails

• L'abonné voit le trafic envoyé par ses sondes RF, reçu par n'importe quelle passerelle LoRaWAN sans aucune restriction. Si l'utilisateur authentifié a des restrictions de domaine, le trafic n'est visible que pour les sondes RF correspondant à ses restrictions de domaine.

• L'abonné ne voit pas le trafic des sondes RF provenant de passerelles étrangères, même lorsqu'il est reçu sur ses propres passerelles.

Les sondes RF présentent les caractéristiques suivantes :

• Le capteur virtuel associé à chaque sonde RF utilise le mode ABP en classe A sans aucun trafic Downlink et sans commandes MAC.

• Le DevEUI, le DevAddr et les clés de sécurité de chaque sonde sont assignés automatiquement par ThingPark.

  note

  Pour identifier facilement le DevEUI correspondant à chaque passerelle, le DevEUI de la sonde est préfixé par F0-3D-29-01 suivi du LRR-ID de la passerelle.

  Exemple : Pour une passerelle ayant LRR-ID 10-00-47-30, le DevEUI de la sonde est F0-3D-29-01-10-00-47-30.

• Le trafic Uplink utilise le mode non confirmé. Le payload de la trame inclut le LRR-ID de la passerelle émettrice.

• Aspects des paquets Uplink envoyés par chaque sonde RF (configurables au niveau de la RF Region) :

  Aspect	Paramètre RF Region	Paramètre par défaut
  Périodicité	probeInterval	1 paquet toutes les 24 heures
  Puissance Tx	probeTxPower	réglée sur l'EIRP maximal autorisé pour le capteur dans le pays d'exploitation (par exemple 16 dBm en EU868)
  Débit	La plage de SF est configurable via probeSFmin et probeSFmax	sélection aléatoire parmi les débits autorisés (spreading factors) utilisés par l'ADR de ThingPark
  Canaux logiques	Le Channel Mask est configurable via probeChannelMask	sélection aléatoire dans la liste des canaux RF activés
  FPort LoRaWAN	probeFPort	1

  note

  Lorsque la Passerelle dispose de plusieurs antennes RF, les paquets sont envoyés sur les différentes antennes en utilisant un algorithme round-robin.

Principaux avantages pour les clients

Grâce à cette fonctionnalité, les gestionnaires de passerelles peuvent vérifier de façon proactive la qualité de transmission/réception RF de leur réseau LoRaWAN sans déployer de sondes RF physiques.

1. Détecter les problèmes RF

   • Identifier les problèmes de transmission RF sur une passerelle donnée, lorsque la qualité de réception de ses propres sondes par l'ensemble des passerelles voisines se détériore.

   • Identifier les problèmes de réception RF sur une passerelle donnée, lorsque la qualité de réception de toutes les sondes RF transmises par ses passerelles voisines se détériore.

   Dans les deux cas, la dégradation peut être soudaine (par exemple due à une panne matérielle) ou progressive (par exemple due à des facteurs environnementaux ou à l'usure).

2. Évaluer et améliorer la précision de la géolocalisation du réseau

   L'envoi périodique de paquets Uplink depuis des emplacements géographiques connus permet d'évaluer la précision de la fonctionnalité de géolocalisation du réseau, en comparant la localisation dérivée (estimée par le réseau) avec la localisation réelle de la passerelle émettrice ; puis d'ajuster en conséquence l'algorithme de géolocalisation.

3. Dépannage approfondi du réseau

   Les sondes RF aident à diagnostiquer les problèmes de connectivité entre les passerelles et le cœur de réseau ThingPark. Par exemple, si une passerelle est déconnectée du cœur de réseau mais continue d'envoyer des sondes RF bien reçues par ses voisines, cela indique que l'application LRR fonctionne toujours correctement sur la passerelle, écartant les pannes d'alimentation ou les défaillances matérielles et indiquant très probablement un problème de connexion backhaul.

Activation de la fonctionnalité

Cette fonctionnalité est désactivée par défaut.

Pour activer la sonde RF sur une passerelle donnée, allez sur la page détaillée de la passerelle, puis l'onglet RF probe puis cliquez sur ENABLE RF PROBE.

Une fois activée, le gestionnaire de la passerelle peut associer la sonde RF à une ou plusieurs Connexions vers lesquelles les paquets Uplink doivent être envoyés vers des serveurs d'application externes.

Limitations de la fonctionnalité

Cette fonctionnalité est supportée uniquement pour les passerelles utilisant le packet forwarder ThingPark LRR (version LRR 2.8.36 ou supérieure). Cette fonctionnalité n'est pas supportée pour les passerelles exécutant le packet forwarder Basics Station.

Journaux d'actions utilisateur (audit trail) RDTP-15326 RDTP-24685

Les journaux d'actions utilisateur (également appelés audit trail) sont générés pour toutes les opérations d'écriture et les opérations de connexion/déconnexion effectuées par les comptes utilisateur et les comptes de service associés à l'abonnement. Ils permettent de suivre les actions suivantes sur l'ensemble des ressources ThingPark concernées :

• Connexion/déconnexion, y compris les erreurs
• Création de ressources, y compris les commandes administratives créées sur des ressources existantes, telles que le redémarrage ou la mise à jour d'une passerelle ou la mise à jour de sa RF Region
• Mise à jour de ressource
• Suppression de ressource

Une ressource peut être un Capteur, une Passerelle, une Connexion, un Groupe Multicast, une Configuration d'abonnement (par exemple un Domaine), un compte utilisateur ou un compte de service. La nature exacte de l'action de création/mise à jour est décrite dans la colonne httpRequestContent du fichier csv exporté.

note

Les comptes utilisateur sont identifiés par leur adresse e-mail, tandis que les comptes de service sont identifiés par leur Client ID.

Les journaux d'actions utilisateur sont accessibles uniquement aux utilisateurs ayant le rôle d'Administrateur. Ils peuvent être téléchargés directement depuis l'interface utilisateur, sous le menu Administration.

Plus de détails

Avantages clés pour les clients

Cette fonctionnalité renforce à la fois la sécurité et l'opérabilité de ThingPark Enterprise.

1. Sécurité et conformité

   • Suivre le comportement des utilisateurs : aide à détecter les accès non autorisés ou les activités suspectes.
   • Soutient la conformité : respecte les exigences réglementaires (par ex. GDPR, HIPAA, ISO 27001).
   • Responsabilité : attribue clairement les actions à des utilisateurs ou à des Capteurs spécifiques.

2. Transparence opérationnelle

   • Historique clair des modifications : voir qui a fait quoi, quand et comment — à travers les Capteurs ou les systèmes.
   • Débuggage et dépannage : simplifie l'analyse des causes racines en cas d'incident.
   • Réduit les temps d'arrêt : diagnostic plus rapide des pannes système ou des erreurs de configuration.

3. Amélioration du produit et Support

   • Meilleur support client : les journaux aident à reproduire et résoudre les problèmes signalés par les utilisateurs.
   • Assurance de l'intégrité des données : les journaux peuvent démontrer que le système s'est comporté correctement dans des scénarios clés.

Activation de la fonctionnalité

Cette fonctionnalité est automatiquement disponible dans la version 8.1.

Pour exporter les journaux d'actions utilisateur depuis l'interface, cliquez sur Administration dans le menu de gauche, puis Control Panel, puis allez au widget USER ACTION LOG. Optionnellement, définissez vos filtres pour restreindre les journaux exportés selon vos besoins.

Limitations de la fonctionnalité

Les actions suivantes ne sont pas journalisées dans la version actuelle :

• Opérations d'écriture sur les ressources TPX IoT-Flow
• Création de tokens via l'ancienne API DX-ADMIN

Améliorations UI/UX du widget "Last 10 packets" du Capteur RDTP-19954 RDTP-24390 RDTP-13714

Le widget "Last 10 packets", disponible sur la page détaillée de chaque Capteur, est significativement amélioré dans la version 8.1. Il s'appelle désormais Packet History.

• Les 10 dernières commandes MAC deviennent accessibles dans ce widget, même si elles ne font pas partie des 10 paquets les plus récents. Elles sont affichées au format décodé.

  

• L'en-tête MAC de chaque paquet est affiché au format décodé, permettant de vérifier facilement les indicateurs Acquittement (ACK) et ADR (entre autres). Des détails supplémentaires sur chaque paquet sont également disponibles, tels que le canal logique, la fréquence RF et le statut de livraison Downlink.

  

• Mises à jour en direct avec rafraîchissement automatique toutes les 10 secondes, supprimant le besoin de rafraîchissement manuel.

  

• Cliquer sur Show more envoie directement l'utilisateur vers WLogger avec le filtre DevEUI approprié.

Plus de détails

Principaux avantages pour les clients

Expérience utilisateur améliorée pour la surveillance et le dépannage des performances des Capteurs.

Activation de la fonctionnalité

Ces améliorations sont automatiquement disponibles après la mise à niveau vers la version 8.1.

Limitations de la fonctionnalité

Non applicable.

Enrichir la liste des passerelles avec la RF Region de chaque passerelle RDTP-23646

À partir de la version 8.1, la RF Region de chaque passerelle est disponible en tant que nouvelle colonne de la vue liste et est également présente dans le fichier csv exportable.

Plus de détails

Principaux avantages clients

UI/UX améliorée, permettant aux gestionnaires de passerelles d'auditer facilement le paramètre RF Region de leurs passerelles et d'identifier rapidement toute potentielle mauvaise configuration.

Cette fonctionnalité peut être particulièrement intéressante pour des déploiements impliquant plusieurs bandes ISM ou des déploiements ayant un mélange de passerelles 8-canaux et 16-canaux.

Activation de la fonctionnalité

La nouvelle colonne est masquée par défaut pour limiter la taille du tableau. Pour afficher la colonne RF Region, l'utilisateur doit cocher la case RF Region comme illustré ci-dessous :

Le choix des colonnes à afficher est stocké dans le cache du navigateur, de sorte que l'utilisateur n'a pas besoin de définir sa préférence à chaque connexion.

Limitations de la fonctionnalité

Non applicable.

Afficher le nombre de licences restantes pour les Capteurs/Passerelles dans le Dashboard RDTP-21133

Pour permettre aux non-administrateurs de savoir combien de crédits device et/ou passerelle restent dans la licence en cours, le décompte des Capteurs et passerelles restants est désormais affiché dans le Dashboard principal, comme illustré dans l'exemple suivant :

Plus de détails

Avantages clés pour les clients

Expérience utilisateur améliorée pour les non-administrateurs qui ne peuvent pas accéder aux détails de la licence dans la page Control Panel.

Activation de la fonctionnalité

Cette fonctionnalité est activée automatiquement dans la version 8.1.

Limitations de la fonction

Non applicable.

Prise en charge de la répétition de paquets Downlink en mode Multicast RDTP-24172

Pour améliorer le taux de réussite de réception des paquets multicast Downlink, le serveur d'application peut avoir besoin d'envoyer une payload multicast donnée plusieurs fois avec le même compteur de trame.

Cette capacité est possible à partir de la version 8.1, par laquelle l'AS peut définir un nouveau paramètre de requête repeated dans l'API downlink de l'interface tunnel LRC-AS. Lorsque repeated =1 dans la requête POST Downlink pour un groupe multicast, le network server envoie le paquet Downlink avec le même compteur de trame qui a été utilisé lors de la transmission précédente à ce groupe multicast.

note

Il appartient à l'AS de répéter les trames multicast via des requêtes POST individuelles, le network server ne déclenche pas automatiquement de telles répétitions.

Plus de détails

Principaux bénéfices pour les clients

Grâce à cette fonctionnalité, les serveurs d'application envoyant des paquets multicast via l'interface tunnel LRC-AS peuvent tirer parti de la répétition de trames pour maximiser les chances de transmettre leur payload aux Capteurs participant à un groupe multicast. Comme les différentes copies d'une même payload multicast sont associées au même compteur de trame LoRaWAN, les Capteurs doivent pouvoir rejeter facilement les trames dupliquées.

Activation de la fonction

Cette fonctionnalité est automatiquement disponible dans la version 8.1, mais les répétitions multicast sont désactivées par défaut. La répétition est explicitement demandée par l'AS en définissant le paramètre de requête repeated à 1 (valeur par défaut = 0).

Pour en savoir plus sur l'utilisation de cette fonctionnalité dans l'API de l'interface tunnel LRC-AS, voir Downlink API V2.

Limitations de la fonction

Cette fonctionnalité n'est prise en charge que via l'API V2 de l'interface tunnel LRC-AS : l'envoi de paquets multicast Downlink depuis l'interface utilisateur ou via des connexions TPX IoT Flow ne prend pas actuellement en charge les répétitions.