TR-369, également connue sous le nom de User Services Platform(USP), est une norme technique qui décrit le protocole de la couche application et le modèle de données pour la gestion à distance des appareils connectés des particuliers et des entreprises, tant par les fournisseurs que par les utilisateurs finaux. Facile, n'est-ce pas ? Plus facile à dire qu'à faire : trouver une solution qui réponde non seulement aux besoins actuels de l'industrie, mais qui s'intègre également bien dans un environnement de friche industrielle est une tâche ardue.
Il est impossible de parler du protocole TR-369 sans évoquer son prédécesseur : TR-069. Lorsque le Broadband Forum a présenté le CPE WAN Management Protocol (CWMP), également appelé TR-069 d'après le nom de sa spécification technique, il s'agissait de la solution parfaite pour la gestion à distance des modems, des routeurs ou des passerelles. Le fait est que nous étions en 2004 et qu'il est très probable que vous n'ayez qu'un seul PC à la maison, que vous ne puissiez pas regarder de films en streaming sur Netflix et que votre réfrigérateur ne vous avertisse pas à l'avance que vous êtes sur le point de manquer de chou frisé. Tout cela pour dire qu'une connexion bidirectionnelle entre le CPE et le serveur d'autoconfiguration (ACS) qui caractérise la norme TR-069 semblait être une solution raisonnable à l'époque. Quinze ans plus tard, avec l'avènement d'un monde d'appareils connectés, il se peut que le CWMP ne suffise plus lorsque vous déployez des services qui permettent à de multiples utilisateurs finaux de gérer eux-mêmes les appareils qui se multiplient à l'infini.
En 2018, il était clairement temps de faire peau neuve. Compte tenu du succès du CWMP, il n'était pas surprenant que le Broadband Forum l'utilise comme cadre lors de la construction de TR-369, raison pour laquelle il est parfois appelé "next-gen TR-069" ou "TR-069 pour les appareils IoT". En effet, l'idée était de créer un protocole qui permettrait la gestion du cycle de vie des appareils intelligents et IoT tout en garantissant l'interopérabilité entre les fournisseurs. Mais les créateurs du protocole TR-369 ne se sont pas arrêtés là. Il est clair que la force des appareils intelligents réside dans le fait qu'ils sont accessibles et gérables par les utilisateurs finaux, ce qui a joué un rôle important dans le processus de développement. Mais le protocole offre également une valeur incroyable aux fournisseurs de services. Nombreux sont ceux qui considèrent la possibilité de mettre en œuvre des services WiFi gérés, c'est-à-dire une gestion externalisée du réseau WiFi, dans leur offre commerciale comme l'un des principaux avantages du passage à TR-369.
La principale différence entre les deux protocoles est qu'au lieu de clients qui communiquent avec des serveurs d'auto-configuration, vous avez maintenant des agents et des contrôleurs. Ce changement de nomenclature peut sembler superficiel, mais en fait, les agents et les contrôleurs fonctionnent selon un principe différent. Alors qu'avec le CWMP, il n'y a qu'un seul ACS par client, avec le protocole TR-369, plusieurs contrôleurs avec différents paramètres d'autorisation peuvent être souscrits à un agent. Cela ouvre une nouvelle porte à de multiples fournisseurs, vendeurs et même utilisateurs finaux pour interagir avec les dispositifs. Avec une telle flexibilité, les fournisseurs d'applications et de services de réseau peuvent gérer leurs services respectifs pour les mêmes appareils en même temps, ce qui favorise les partenariats entre fournisseurs.
Contrairement à son prédécesseur, la norme TR-369 prend en charge plusieurs protocoles de transport de messages (MTP), et pas seulement HTTP. Il s'agit notamment de Websockets, du protocole CoAP (Constrained Application Protocol), du protocole STOMP (Simple Text-Oriented Messaging Protocol) et du protocole MQTT (Message Queuing Telemetry Transport).
Alors qu'avec le CWMP, la connexion entre le client et l'ACS est toujours initiée par le client dans un but spécifique et optimisée pour être aussi courte que possible, TR-369 est conçu pour une communication directe et permanente. Une fois la connexion établie au démarrage, les sessions Websockets ou STOMP sont ouvertes indéfiniment et les contrôleurs peuvent librement envoyer des messages aux agents.
Ce besoin de réactivité impose à TR-369 d'être léger en retour. La quantité de frais généraux a en effet été considérablement réduite par rapport à son précurseur. Par exemple, les sessions ouvertes mentionnées ci-dessus ont supprimé le besoin de demandes de connexion répétées qui généraient beaucoup d'échanges inutiles. De telles améliorations sont particulièrement importantes pour les déploiements IoT qui reposent sur une faible consommation de données, mais elles ne doivent pas non plus être sous-estimées par les opérateurs de télécommunications. Les opérateurs devaient auparavant trouver un équilibre entre les avantages d'une surveillance fréquente des appareils et l'impact sur le réseau. Le protocole TR-369 étant très efficace, il permet une surveillance plus fréquente et plus précise de l'appareil, garantissant ainsi une meilleure qualité de service pour le client.
La couche d'application du protocole TR-369 est enveloppée dans un tampon de protocole avant d'être encapsulée dans un MTP. Les protobufs, comme on les appelle en abrégé, ressemblent un peu à XML, mais ils ne sont pas lisibles par l'homme après encodage et nécessitent un schéma (un fichier .proto) pour être décodés. L'existence de schémas facilite l'application de la structure des données.
TR-369 offre également une sécurité de pointe. Lemessage USP est enveloppé dans un enregistrement USP qui peut être crypté avec TLS.Le message peut également être sécurisé dans la couche MTP : pour les Websockets avec HTTPS, pour CoAP - DTLS, et pour STOMP - avec TLS. En outre, la fonction d'échange de messages de bout en bout (E2E) permet d'établir un contexte de session qui garantit l'intégrité, la protection et la segmentation des données si le message est trop volumineux pour être transféré.
Le protocole TR-369 s'appuie fortement sur la modélisation des données, en particulier sur le modèle de données Device:2 Root (TR-181) légèrement modifié, dont la version 1 a été appliquée à TR-069. La spécification TR-181 du Broadband Forum le définit comme un ensemble d'objets de données, tels que "les informations de base sur les appareils, la configuration de l'heure du jour, la configuration de l'interface réseau et de la pile de protocoles, la gestion du routage et du pontage, les statistiques de débit et les tests de diagnostic". Les interfaces réseau et les protocoles étant considérés comme des objets, ils peuvent être librement empilés pour correspondre à la configuration de l'appareil.
TR-369 a été conçu pour combler un créneau apparu lorsque le paysage des appareils intelligents a commencé à évoluer rapidement. Cependant, le protocole n'était pas destiné à remplacer son ancêtre, car il existe encore des cas d'utilisation où il est plus que suffisant pour un déploiement, en particulier s'il existe déjà une architecture compatible en place. Malgré tout, TR-069 reste une norme de référence qui a fait ses preuves. Si vous êtes prêt à passer à l'étape suivante, vous devez veiller à ce que votre serveur d'auto-configuration - qu'il soit dans le nuage ou sur site - puisse prendre en charge ces deux protocoles simultanément.Après tout, vous ne mettrez probablement pas à niveau l'ensemble de votre flotte en une seule fois et il est tout à fait possible que vous ne souhaitiez pas mettre à niveau certains appareils.C'est pourquoi il est important que votre plateforme de gestion des appareils soit capable de gérer à la fois TR-069 et TR-369, afin qu'ils puissent coexister dans votre déploiement.
Il y a certainement des arguments en faveur d'une norme émergente développée en tandem avec des experts de l'industrie par un organisme de normalisation bien établi, tel que le Broadband Forum. N'oubliez pas cependant qu'il existe de nombreuses solutions sur le marché à prendre en considération. Et nombre d'entre elles présentent des caractéristiques similaires, comme par exemple LwM2M - une norme également développée en réponse aux besoins du monde de l'IdO en pleine croissance. Comme toujours, il n'y a pas de réponse claire à la question de savoir quelle est la meilleure norme. La seule question à se poser est la suivante : quelle est la meilleure pour votre déploiement ?