Nouvelles fonctionnalités

Cette page cumule toutes les nouvelles fonctionnalités de ThingPark Enterprise apportées par les différentes versions 8.0.x du logiciel. Consultez le journal des modifications 8.0 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é.

Configuration enrichie des connexions HTTPS de base RDTP-11863

Les améliorations suivantes sont ajoutées aux types de connexions HTTPS de base vers les serveurs d'applications externes :

• Chaque connexion peut être configurée avec plusieurs URL de destination. Lorsque c'est le cas, la stratégie de routage peut être définie selon l'une des options suivantes :

  • Séquentiel : Le paquet est transmis à la première destination de la liste ordonnée, puis tenté sur les URL suivantes uniquement en cas d'échec de la transmission sur l'URL précédente de la liste ordonnée.
  • Exploser : chaque paquet uplink est envoyé à toutes les URL de destination.

• Support du routage basé sur les ports, permettant de router le trafic uplink en fonction du Fport LoRaWAN inclus dans le paquet uplink. Cette fonctionnalité offre un routage/traitement séparé du trafic LoRaWAN par de multiples applications.

• L'écart maximum du timestamp pour l'authentification de l'interface tunnel est désormais configurable dans l'interface utilisateur. Ce paramètre définit l'écart maximum autorisé entre l'horodatage défini par l'application lorsque la demande de lien downlink est générée, et l'heure de réception de la demande de lien downlink par le network server.

• L'URL utilisée pour envoyer des paquets downlink à cette connexion est maintenant affichée dans la page détaillée de chaque connexion HTTPS de base.

Plus de détails

Principaux avantages pour les clients

Expérience utilisateur améliorée + flexibilité supplémentaire lors de l'utilisation des connexions HTTPS.

Activation de la fonctionnalité

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

Les connexions HTTPS créées à partir de versions précédentes restent inchangées après la mise à niveau. Il appartient au gestionnaire de Connexion de modifier manuellement les détails de la Connexion s'il souhaite ajouter plusieurs destinations ou supporter le routage basé sur les ports.

Limitations de la fonctionnalité

Non applicable.

Amélioration de la surveillance de l'historique de la batterie des capteurs RDTP-17339

Avant la version 8.0 : l'interface utilisateur n'affiche que le dernier niveau de batterie signalé pour chaque capteur LoRaWAN.

À partir de la version 8.0 : en plus du dernier niveau de batterie signalé, les informations suivantes sont disponibles dans l'interface utilisateur pour les capteurs LoRaWAN alimentés par batterie :

• Le délai estimé jusqu'à ce que la batterie doive être rechargée/remplacée.

  

• La date à laquelle la batterie a été rechargée/remplacée.

• Les graphiques de l'historique de consommation de la batterie sur les 3 mois, 6 mois et 1 an derniers.

Plus de détails

Avantages clés pour les clients

Amélioration de la surveillance des capteurs alimentés par batterie, y compris la capacité d'estimer la durée de vie restante de la batterie en extrapolant l'historique des niveaux de batterie signalés.

Activation de la fonctionnalité

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

Limitations de la fonctionnalité

Non applicable.

Améliorations de l'UI/UX de la gestion des capteurs RDTP-16304

La version 8.0 apporte les améliorations UI/UX suivantes concernant la gestion des capteurs :

• Ajout de capteurs sans connexions : Il est désormais possible d'ajouter de nouveaux capteurs ou groupes multicast sans les associer à une connexion.

• Améliorations liées à l'envoi de paquets downlink : Il est maintenant possible d'envoyer des payloads downlink chiffrés, ce qui est pertinent pour les capteurs configurés avec le mode de chiffrement de bout en bout et dont AppSKey est uniquement connu du serveur d'application. Dans ce cas, le compteur de trames downlink doit être saisi par l'utilisateur en plus du payload chiffré et du port trame.

  De plus, la fonctionnalité "Envoyer downlink" est améliorée pour permettre l'envoi de paquets downlink en mode confirmé (c'est-à-dire, en demandant un acquittement du capteur) ainsi que la vidange de la file d'attente downlink pour les capteurs de classe A.

  

• Groupes multicast : AppSKey est désormais optionnel lors de l'ajout de nouveaux groupes multicast.

Plus de détails

Principaux avantages pour les clients

Amélioration de l'expérience utilisateur et de l'efficacité opérationnelle :

• Des capteurs de test peuvent être ajoutés au système sans les associer à une connexion. Cette amélioration supprime le besoin de créer une connexion fictive si le capteur est temporairement dissocié de toutes les connexions réelles.

• Des options supplémentaires sont désormais supportées lorsque les utilisateurs envoient des paquets de downlink via l'interface utilisateur.

Activation de la fonctionnalité

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

Limitations de la fonctionnalité

Il n'est actuellement pas possible d'envoyer des payloads downlink chiffrés à un groupe multicast créé sans AppSKey.

Permettre de gérer les domaines, les comptes d'utilisateurs et les comptes de service via l'API RDTP-19650

Avant la version 8.0 : la gestion des domaines, des comptes d'utilisateur et des comptes de service n'est possible qu'à partir de l'interface utilisateur.

À partir de la version 8.0 : en plus de l'interface utilisateur, il est maintenant possible de gérer les domaines, les comptes d'utilisateur et les comptes de service via l'API OSS.
Pour en savoir plus sur la nouvelle API, consultez Administration des abonnés.

Plus de détails

Principaux avantages clients

Cette fonctionnalité offre les avantages suivants aux administrateurs de ThingPark Enterprise :

• Meilleure intégration avec les applications métier du client.
• Meilleure expérience, permettant la gestion en masse via des scripts API.

Activation de la fonctionnalité

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

Limitations de la fonctionnalité

Non applicable.

Utilisation de conteneurs distroless RDTP-22478

Les conteneurs distroless sont une approche minimaliste de la construction de conteneurs Docker, où seuls les fichiers essentiels nécessaires à l'exécution d'une application sont inclus. Cela contraste avec les conteneurs traditionnels qui incluent souvent une distribution Linux complète avec de nombreux paquets et utilitaires supplémentaires.

Plus de détails

Avantages clés pour les clients

L'utilisation de conteneurs distroless offre une large gamme d'avantages :

• Sécurité améliorée : avec moins de composants et de bibliothèques, la surface d'attaque du conteneur est considérablement réduite, limitant les vulnérabilités potentielles qui pourraient être exploitées par des attaquants. Cela améliore la sécurité car il y a moins d'opportunités pour que des vulnérabilités se trouvent dans l'image, réduisant le risque d'injection de code malveillant ou de failles de sécurité. Avec moins de composants, il y a moins à maintenir ou à mettre à jour dans le conteneur, et donc moins de paquets devant être corrigés pour les vulnérabilités de sécurité.

• Taille de l'image réduite, en supprimant les bibliothèques, binaires et outils inutiles trouvés dans une distribution Linux complète. Cela signifie des temps de pull et de push plus rapides, des besoins de stockage réduits et une utilisation plus efficace de la bande passante.

• Optimisation des performances : en réduisant tout ce qui est superflu sauf ce qui est nécessaire pour l'application, la consommation de ressources est minimisée. Ainsi, les conteneurs deviennent plus efficaces, nécessitant moins de mémoire et de CPU et offrant des temps de démarrage plus rapides.

Activation de la fonctionnalité

Cette fonctionnalité est automatiquement disponible dans ThingPark 8.0.

Limitations de la fonction

Dans la version 8.0, les applications qui ne pouvaient pas utiliser le mode distroless pour des contraintes techniques quelles qu'elles soient utilisent à la place le mode debian-slim, qui est toujours meilleur que le mode conteneur traditionnel.

Personnalisation du mot de passe de support LRR depuis l'interface graphique RDTP-22321

Avant la version 8.0 :

• Le mot de passe par défaut du compte de support LRR ne peut être changé que depuis la console locale (également connue sous le nom de Suplog), pour la version 2.8.39 du LRR.

• Si le mot de passe de support est changé localement via Suplog, l'utilisateur est invité à entrer son nouveau mot de passe chaque fois qu'il souhaite ouvrir une session à distance vers le LRR depuis l'interface utilisateur de ThingPark.

À partir de la version 8.0 :

• Le gestionnaire BS peut personnaliser le mot de passe de support lors de l'étape de provisionnement du BS via l'interface utilisateur :

  

• De plus, le gestionnaire BS peut changer le mot de passe de support actuel à tout moment, soit par API, soit depuis l'onglet Avancé de la page détaillée de la passerelle :

  

• Chaque fois que le mot de passe est changé depuis l'interface de gestion BS (ou par API), le nouveau mot de passe est automatiquement stocké par le back-office pour que l'utilisateur n'ait pas à le saisir de nouveau à chaque fois qu'une nouvelle session à distance est initiée.

Plus de détails

Avantages clés pour les clients

En plus de l'amélioration de la sécurité apportée par la capacité de personnaliser le mot de passe par défaut du compte de support LRR, cette fonctionnalité apporte des gains opérationnels aux gestionnaires de passerelles ThingPark :

• Les utilisateurs peuvent changer les mots de passe en masse pour toutes leurs passerelles, via des scripts API.
• Le mot de passe personnalisé est mémorisé par le système, améliorant l'expérience utilisateur globale lors de l'accès à distance.

Activation de la fonction

Cette fonctionnalité est automatiquement supportée pour les passerelles exécutant le packet forwarder LRR à partir de la version 2.8.39. Cette fonctionnalité n'est pas supportée pour les passerelles exécutant le packet forwarder Basics Station.

Limitations de la fonctionnalité

Lors de la restauration d'une sauvegarde LRR, le mot de passe de support en vigueur au moment de la sauvegarde est restauré. Dans ce cas, le mot de passe stocké sur le serveur peut ne plus être valide et doit être saisi manuellement par l'utilisateur lors de l'ouverture d'une session à distance depuis l'interface utilisateur.

Mécanisme anti-bagotement des alarmes de passerelle RDTP-18707

Pour minimiser la volatilité et réduire les occurrences de basculement, la mise en œuvre des alarmes de passerelle a été totalement retravaillée dans la version 8.0.

Statut de connexion de la passerelle (alarme #102):

Pour améliorer sa pertinence et atténuer les occurrences de basculement dues à des micro-déconnexions, les conditions de déclenchement et de rétablissement ont été optimisées dans ThingPark 8.0 comme suit :

• L'alarme est activée uniquement si la connexion Backhaul est interrompue pendant au moins X secondes (X étant configurable au niveau de la passerelle, il est défini à 30 secondes par défaut). De plus, la gravité de l'alarme est configurable (défini par défaut en critique).

  

• L'alarme est effacée uniquement lorsque la connexion de liaison arrière est rétablie et stable pendant au moins 10 minutes.

Les conditions de déclenchement et de rétablissement d'autres alarmes BS ont également été retravaillées, pour étendre la fenêtre d'observation ou augmenter l'hystérésis, comme détaillé ci-dessous :

Plus de détails

Niveau anormalement élevé d'invalidité physique CRC uplink (alarm n°104):

• La condition de déclenchement est améliorée en évaluant le ratio d'erreurs CRC sur 4 heures consécutives au lieu d'une seule heure.
• La condition de rétablissement est également améliorée en évaluant le ratio d'erreurs CRC sur 4 heures tout en considérant une hystérésis de 20% au lieu de 10%.

Le taux de trames en downlink dépasse la capacité de la cellule RF (alarm n°105)

• La condition de déclenchement est améliorée pour lancer l'alarme lorsque le ratio de trames DL perdues (en raison d'un modem radio occupé) dépasse 5 % dans la dernière heure ; au lieu de lancer l'alarme dès la première trame DL perdue auparavant.
• La condition de suppression s'est également améliorée : l'alarme est effacée lorsque le taux de paquets perdus en downlink passe sous 2 % au cours de la dernière heure.

Niveau d'utilisation du CPU anormalement élevé (alarm n°106)

• Pour simplification, la gravité « avertissement » est retirée, seul un niveau de gravité (majeur par défaut) est conservé.
• L'alarme est déclenchée lorsque l'utilisation moyenne du CPU (évaluée durant la dernière heure) dépasse 90 %, contrairement à l'évaluation toutes les 5 minutes lors des versions précédentes.
• L'alarme est effacée lorsque l'utilisation moyenne du processeur (également évaluée au cours de la dernière heure) passe sous 80 %, avec une hystérésis de 10 %.

Niveau d'utilisation de la RAM anormalement élevé (alarm n°107)

• Pour simplification, la gravité « avertissement » est retirée, seul un niveau de gravité (majeur par défaut) est conservé.
• L'alarme est déclenchée lorsque l'utilisation moyenne de la RAM (évaluée durant la dernière heure) dépasse 90 %, contrairement à l'évaluation toutes les 5 minutes lors des versions précédentes.
• L'alarme est effacée lorsque l'utilisation moyenne de la RAM (également évaluée au cours de la dernière heure) passe sous 75 %, avec une hystérésis de 15 %.

Niveau d'utilisation du système de fichiers anormalement élevé (alarm n°107)

• Pour simplification, la gravité « avertissement » est retirée, seul un niveau de gravité (majeur par défaut) est conservé.
• L'alarme est déclenchée lorsque l'utilisation moyenne du système de fichiers (évaluée durant la dernière heure) dépasse 95 %, contrairement à l'évaluation toutes les 5 minutes lors des versions précédentes.
• L'alarme est effacée lorsque l'utilisation moyenne du système de fichiers (également évaluée au cours de la dernière heure) passe sous 85 %, avec une hystérésis de 10 %.

Perte de la synchronisation temporelle (alarm n°109)

• Les conditions de déclenchement et d'annulation sont améliorées en évaluant le statut de synchronisation temporelle pendant les 15 dernières minutes au lieu des 5 dernières minutes dans les versions précédentes.

Panne de courant détectée (alarm n°110)

• Les conditions de déclenchement et d'annulation sont améliorées en évaluant le statut d'alimentation pendant les 15 dernières minutes au lieu des 5 dernières minutes dans les versions précédentes.

Échec de la transmission du beacon (alarm n°111)

• La condition de déclenchement est améliorée pour lancer l'alarme lorsque le ratio d'échecs de transmission de beacons dépasse 25 % au cours de la dernière heure ; au lieu de lancer l'alarme précédemment en fonction du statut de livraison de la dernière beacon.
• La condition de suppression s'est également améliorée : l'alarme est effacée lorsque le taux d'échec du signal de beacon en downlink passe sous 10 % au cours de la dernière heure, avec une hystérésis de 15 %.

Statut de l'interface réseau de backhaul (alarm n°121)

• Les conditions de déclenchement et d'annulation sont améliorées en évaluant le statut de l'interface pendant les 15 dernières minutes au lieu des 5 dernières minutes dans les versions précédentes.

Échec de verrouillage GPS détecté (alarm n°122)

• Les conditions de déclenchement et d'annulation sont améliorées en évaluant le statut du GPS au cours des 15 dernières minutes au lieu des 5 dernières minutes dans les versions précédentes.

Principaux avantages pour les clients

Grâce à cette fonctionnalité, les alarmes de passerelles deviennent plus pertinentes pour les gestionnaires, réduisant leur volatilité et leur occurrence de chatoiement.

Activation de la fonctionnalité

Cette fonctionnalité est activée automatiquement. En fonction de l'alarme, les paramètres par défaut peuvent être configurables au niveau de la passerelle (comme les alarmes n°102 et n°103) ou à l'échelle de l'opérateur.

Limitations de la fonctionnalité

Non applicable.