TR-369, auch bekannt als User Services Platform(USP), ist ein technischer Standard, der das Protokoll der Anwendungsschicht und das Datenmodell für die Fernverwaltung von angeschlossenen Verbraucher- und Unternehmensgeräten durch Anbieter und Endnutzer gleichermaßen beschreibt. Einfach, oder? Leichter gesagt als getan - eine Lösung zu finden, die nicht nur den aktuellen Anforderungen der Branche entspricht, sondern sich auch gut in eine Industriebrache einfügt, ist eine schwierige Aufgabe.
Es ist unmöglich, das TR-369-Protokoll zu diskutieren, ohne seinen Vorgänger zu erwähnen: TR-069. Als das Broadband Forum das CPE WAN Management Protocol (CWMP) vorstellte, das nach dem Namen seiner technischen Spezifikation auch TR-069 genannt wurde, war es die perfekte Lösung für die Fernverwaltung von Modems, Routern oder Gateways. Aber wir schreiben das Jahr 2004, und es ist sehr wahrscheinlich, dass Sie nur einen PC zu Hause hatten, keine Filme auf Netflix streamen konnten und Ihr Kühlschrank Ihnen nicht anzeigte, dass der Grünkohl bald ausgeht. All dies bedeutet, dass eine bidirektionale Verbindung zwischen dem CPE und dem Autokonfigurations-Server (ACS), der für TR-069 charakteristisch ist, damals eine vernünftige Lösung zu sein schien. 15 Jahre später, in einer Welt voller vernetzter Geräte, könnte sich herausstellen, dass CWMP nicht mehr ausreicht, wenn man Dienste bereitstellt, die es mehreren Endbenutzern ermöglichen, die ständig neu entstehenden Geräte selbst zu verwalten.
Im Jahr 2018 war es eindeutig Zeit für eine Überarbeitung. In Anbetracht des Erfolgs von CWMP war es keine große Überraschung, dass das Broadband Forum es bei der Entwicklung von TR-369 als Rahmenwerk verwenden würde, weshalb es manchmal auch als "TR-069 der nächsten Generation" oder "TR-069 für IoT-Geräte" bezeichnet wird. Die Idee war, ein Protokoll zu entwickeln, das das Lebenszyklusmanagement von intelligenten und IoT-Geräten ermöglicht und gleichzeitig die Interoperabilität zwischen den Anbietern gewährleistet. Aber die Schöpfer des TR-369-Protokolls haben sich nicht damit begnügt. Die Stärke intelligenter Geräte liegt eindeutig darin, dass sie für den Endnutzer zugänglich und verwaltbar sind, was bei der Entwicklung eine große Rolle spielte. Aber auch für Dienstanbieter bietet das Protokoll einen unglaublichen Wert. Viele betrachten die Möglichkeit, verwaltete WiFi-Dienste, d. h. die ausgelagerte Verwaltung von WiFi-Netzwerken, in ihr Geschäftsangebot aufzunehmen, als einen der Hauptvorteile der Umstellung auf TR-369.
Der Hauptunterschied zwischen den beiden Protokollen besteht darin, dass anstelle von Clients, die mit Autokonfigurations-Servern kommunizieren, jetzt Agenten und Controller eingesetzt werden. Es mag wie eine spielerische Änderung der Nomenklatur erscheinen, aber tatsächlich arbeiten Agenten und Controller nach einem anderen Prinzip. Während es bei CWMP nur einen ACS pro Client gibt, können beim TR-369-Protokoll mehrere Controller mit unterschiedlichen Berechtigungseinstellungen bei einem Agenten abonniert werden. Dies eröffnet mehreren Anbietern, Herstellern und sogar Endnutzern neue Möglichkeiten der Interaktion mit den Geräten. Dank dieser Flexibilität können sowohl Anwendungs- als auch Netzwerkdienstleister ihre jeweiligen Dienste für dieselben Geräte gleichzeitig verwalten, was Partnerschaften mit Anbietern begünstigt.
Im Gegensatz zu seinem Vorgänger unterstützt TR-369 mehrere Nachrichtentransportprotokolle (MTPs), nicht nur HTTP. Dazu gehören Websockets, Constrained Application Protocol (CoAP), Simple Text-Oriented Messaging Protocol (STOMP) und Message Queuing Telemetry Transport (MQTT).
Während bei CWMP die Verbindung zwischen dem Client und dem ACS immer vom Client für einen bestimmten Zweck initiiert und auf eine möglichst kurze Dauer optimiert wird, ist TR-369 für eine ständig aktive, direkte Kommunikation ausgelegt. Sobald die Verbindung beim Start aufgebaut ist, sind Websockets oder STOMP-Sitzungen unbegrenzt offen und die Controller können frei Nachrichten an Agenten senden.
Die Notwendigkeit, reaktionsschnell zu sein, erfordert, dass TR-369 im Gegenzug leichtgewichtig ist. In der Tat wurde der Overhead im Vergleich zu seinem Vorläufer deutlich reduziert. Durch die oben erwähnten offenen Sitzungen entfällt beispielsweise die Notwendigkeit wiederholter Verbindungsanfragen, die eine Menge unnötiges Handshaking erzeugen. Verbesserungen wie diese sind besonders wichtig für IoT-Implementierungen, die auf einen geringen Datenverbrauch angewiesen sind, dürfen aber auch von den Telekommunikationsunternehmen nicht unterschätzt werden. Bisher mussten die Betreiber die Vorteile einer häufigen Geräteüberwachung mit den Auswirkungen auf das Netz abwägen. Da das TR-369-Protokoll so effizient ist, ermöglicht es eine häufigere und präzisere Überwachung des Geräts und gewährleistet so eine bessere Dienstqualität für den Kunden.
Die Anwendungsschicht in TR-369 wird in einen Protokollpuffer eingepackt, bevor sie in ein MTP eingekapselt wird. Protobufs, wie sie kurz genannt werden, sind ähnlich wie XML, allerdings sind sie nach der Kodierung nicht für Menschen lesbar und benötigen ein Schema (eine .proto-Datei), um dekodiert zu werden. Das Vorhandensein von Schemata erleichtert die Anwendung der Datenstruktur.
TR-369 bietet auch modernste Sicherheit:Die USP-Nachricht wird in einen USP-Datensatz verpackt, der mit TLS verschlüsselt werden kann.Die Nachricht kann auch in der MTP-Schicht gesichert werden: für Websockets mit HTTPS, für CoAP - DTLS, und für STOMP - mit TLS. Darüber hinaus ermöglicht die Funktion des End-to-End-Nachrichtenaustauschs (E2E) die Einrichtung eines Sitzungskontexts, der die Integrität, den Schutz und die Segmentierung der Daten gewährleistet, wenn die Nachricht für die Übertragung zu groß ist.
Das TR-369-Protokoll stützt sich in hohem Maße auf die Datenmodellierung, insbesondere auf das leicht modifizierte Datenmodell Device:2 Root (TR-181), dessen Version 1 für TR-069 verwendet wurde. Die TR-181-Spezifikation des Broadband Forum definiert es als eine Reihe von Datenobjekten, wie z. B. "grundlegende Geräteinformationen, Tageszeitkonfiguration, Netzwerkschnittstellen- und Protokollstapelkonfiguration, Routing- und Bridging-Management, Durchsatzstatistiken und Diagnosetests". Da Netzwerkschnittstellen und -protokolle als Objekte betrachtet werden, können sie frei gestapelt werden, um der Gerätekonfiguration zu entsprechen.
TR-369 wurde entwickelt, um eine Nische zu füllen, die entstand, als sich die Landschaft der intelligenten Geräte schnell zu verändern begann. Das Protokoll sollte jedoch nicht in jedem Fall seinen Vorgänger ersetzen, da es immer noch Anwendungsfälle gibt, in denen es für einen Einsatz mehr als ausreichend ist, insbesondere wenn bereits eine kompatible Architektur vorhanden ist. Trotz allem bleibt TR-069 ein Standard, der sich in vielen Fällen bewährt hat. Wenn Sie bereit sind, den nächsten Schritt zu tun, sollten Sie jedoch darauf achten, dass Ihr Autokonfigurationsserver - ob in der Cloud oder vor Ort - beide Protokolle gleichzeitig unterstützen kann.Schließlich werden Sie wahrscheinlich nicht Ihre gesamte Flotte auf einmal aufrüsten, und es ist durchaus möglich, dass Sie einige Geräte überhaupt nicht aufrüsten möchten.Deshalb ist es wichtig, dass Ihre Gerätemanagementplattform sowohl TR-069 als auch TR-369 verarbeiten kann, damit sie in Ihrer Bereitstellung nebeneinander bestehen können.
Es gibt sicherlich Argumente für eine aufstrebende Norm, die in Zusammenarbeit mit Branchenexperten von einem etablierten Normungsgremium wie dem Broadband Forum entwickelt wurde. Bedenken Sie jedoch, dass es auf dem Markt eine Vielzahl von Lösungen gibt, die Sie in Betracht ziehen sollten. Und viele haben ähnliche Referenzen, wie zum Beispiel LwM2M - ein Standard, der ebenfalls als Antwort auf die Bedürfnisse der wachsenden IoT-Welt entwickelt wurde. Wie immer gibt es keine eindeutige Antwort auf die Frage, welcher Standard der beste ist. Sie können nur fragen: Welcher ist der beste für Ihren Einsatz?