Toolbox für Gateway-freie IP-Kommunikation

Das Internet der Dinge (Internet of Things, ) ist wie jede technische Netzwerk-Anwendung auf Geräte zur Verbindung, Vermittlung und Übergabe von Signalen angewiesen. Diesen Part übernehmen in der Regel konventionelle Gateways. Der Begriff ist jedoch differenziert zu betrachten: Gemeint sind hier nicht Router, die als Hardwareschnittstelle den Zugang zum Internet ermöglichen. Solche Gateways übersetzen lediglich die Nachrichten, die zwischen zwei Protokollen oberhalb der dritten Schicht des OSI-Referenzmodells (Open Systems Interconnection Model) ausgetauscht werden. Die Router benötigen Informationen über die Netzwerk-Struktur und übermitteln Datenpakete auf Basis ihres IP-Headers – ohne den Inhalt der Pakete verstehen zu müssen.

Bild 1: Die Schichtstruktur von OSI-Modell, TCP/IP und dem Net4more-Protokoll im Vergleich. Tridonic

In diesem Beitrag geht es vielmehr um Application Gateways, die auf der Anwendungsebene operieren, also in Schicht fünf des OSI-Modells oder darüber (Bild 1). Für eine durchgängige Datenkommunikation müssen diese Gateways den Inhalt der Pakete vollumfänglich verstehen und übersetzen. Für Licht-Infrastrukturen bedeutet dies, dass herkömmliche Steuerungsprotokolle wie etwa Dali (Digital Addressable Lighting Interface) zwingend Application Gateways für die Kommunikation benötigen. Denn hier ist die zeitliche Komponente ausschlaggebend: Erfolgt die Antwort auf eine Anfrage nicht innerhalb eines bestimmten Zeitraums, wird die Anfrage nicht weitergeleitet. Eine Übermittlung von Dali-Frames ist dann nur mit Application Gateways möglich, die in der Lage sind, die Paketinhalte zu interpretieren.

Lichtsteuerung mit Dali

Wie funktioniert nun die Lichtsteuerung mit Application Gateways im Dali-Umfeld? Die Applikation muss bei der Lichtsteuerung zum Beispiel die Eigenschaften eines Knopfdrucks, die Anzahl der Ereignisse und ihre Dauer in einen oder mehrere Dali-Frames übersetzen, um spezielle Leuchten entsprechend zu steuern. Es ist nicht ungewöhnlich, dass eine Gruppe Leuchten enthält, die zu unterschiedlichen Dali-Leitungen gehören. In diesem Fall muss Gateway A den Befehl an einen anderen Dali-Controller (Gateway B) über ein unterschiedliches Protokoll weiterleiten, um das Licht einzuschalten. Dadurch wird eine geeignete Anfrage erzeugt und in ein IP-Paket eingebunden. Gateway B erhält nun dieses Paket und veranlasst die Aktivierung der entsprechenden Leuchte. Hierbei übersetzt Gateway B die Nutzeranfrage an Dali und demzufolge auch die Signale auf dem Bus.

Hierfür ist erforderlich, dass die Kommunikation zwischen den beiden Dali-Gateways spezifiziert wird. Wäre Dali das einzige Protokoll und würde das IP-Netzwerk als eine zweckmäßige Basis-Infrastruktur genutzt, wäre die Komplexität der Gateways kein Thema. Probleme können sich aber dann ergeben, wenn die beiden Gateways neben Dali mit weiteren älteren Protokollen arbeiten wie etwa DMX, 1-10V oder dem Protokoll für die Gebäudeautomation KNX. In diesem Fall lässt sich die Übersetzung der Datensignale möglicherweise nicht mehr beherrschen. Es steigt das Risiko, dass ganze Datenpakete verzögert oder aufgrund von Timeout-Problemen oder falscher Adressierung gar nicht übermittelt werden. Bei der Übertragung innerhalb unterschiedlicher Protokolle kann es vorkommen, dass einzelne Anfragen in viele verschiedene Befehle übersetzt werden. Das Gateway muss nun die Befehle passend zur entsprechenden Anfrage korrekt interpretieren, was durchaus eine Herausforderung darstellt. Funktioniert dieser Prozess nicht optimal, können bei der Übersetzung wichtige Informationen verloren gehen, die im Extremfall sogar zu einem totalen Zusammenbruch des Systems führen.

Die mangelnde Synchronisierung hat auch damit zu tun, dass nicht sämtliche Hersteller ihre Gateways mit einer umfassenden Funktionsvielfalt ausstatten können, die alle erdenklichen Protokolle unterstützt. Knackpunkt bei der Ausstattung von marktgängigen Gateways mit bestimmten Features ist häufig, dass es an der nötigen Abstimmung im Prozess von der Entwicklung bis zur Marktreife fehlt. Proprietäre Features erfordern normalerweise eine Funktionalität, die sowohl vom User Input als auch vom Aktor unterstützt wird (also vom Controller beziehungsweise den Leuchten). Im Falle eines veralteten Protokolls müssten diese Features auch von allen Gateways unterstützt werden, die möglicherweise an der Kommunikation beteiligt sind. Dies steht in starkem Gegensatz zu IP-basierenden Architekturen. Dort wird dieses Problem über eine viel komplexere Struktur des Kommunikationsprotokolls gelöst, die keine Gateways erfordert.

Ob und wie sich Gateways im Netzwerk vollständig eliminieren lassen, erfahren Sie auf der folgenden Seite.

Gateways im Netzwerk komplett eliminieren

Aufgrund der genannten Schwierigkeiten ist zu erwägen, ob und wie sich Gateways in vernetzten Infrastrukturen gänzlich eliminieren lassen, wie also eine komplett Gateway-freie Architektur implementiert werden kann. Dies ist dann möglich, wenn Anfragen über andere Geräte übermittelt werden, die den jeweiligen Inhalt nicht zwingend verstehen müssen.

Ein Beispiel, das die Funktionsweise erklärt: Host A erzeugt innerhalb der Anwendungsschicht eine Anfrage, die er an Host C senden möchte. Hierfür übermittelt ersterer die Anfrage zunächst an die Netzwerkschicht. Dort wird sie mit einem Header versehen, der die IPv6-Adresse des Empfängers enthält. Anschließend wird das Paket an die /PHY-Schicht weitergeleitet, wo ein weiterer Header mit der MAC-Adresse des nächsten Hops (Host B) hinzugefügt wird. Host B erhält das Paket, prüft den Header und übermittelt es an die Netzwerkschicht, wo der IP-Header kontrolliert wird.

Dabei legt der Host fest, dass die Zieladresse nicht mit seiner eigenen IP-Adresse übereinstimmt. An diesem Punkt ist es wichtig zu wissen, dass das Header-Format und der Inhalt komplett vom Protokoll der Netzwerkschicht spezifiziert werden. Zudem ist es völlig unabhängig von der Datenmenge. Dadurch weiß der dazwischenliegende Host, dass er die Anfrage an einen anderen Knoten weiterleiten muss und sendet sie an die MAC/PHY-Schicht. Dort wird die MAC-Adresse des nächsten Hops ergänzt und das Paket erneut versendet. Ist dieser Hop der gewünschte Empfänger (Host C), erkennt er sowohl die MAC-Adresse im Paket als auch die IP-Adresse im Header der Netzwerkschicht als seine eigene. Abschließend wird das Paket dann an die Applikation übermittelt, wo es interpretiert und weiterverarbeitet wird.

Dabei ist es nicht von Bedeutung, wie viele dazwischenliegende Knoten die Anfrage passiert. Keiner davon – außer Host A und C – muss den Inhalt des Pakets verstehen. Da nur die Endknoten den Inhalt der Kommunikation verstehen müssen, können sie diese einfach sichern, um sensible Informationen zu schützen oder sie als echte Produkte zu authentifizieren. Im Vergleich dazu kann eine Architektur mit Gateway-Nutzung bei der nur eingeschränkte Sicherheitsstandards gewährleisten.

Auf der folgenden Seite stellt der Beitrag die Toolbox für Gateway-freie Architekturen von Tridonic vor.

Licht-Infrastruktur als Basis für das IoT

Gateway-freie Architekturen bergen entscheidende Vorteile in sich wie etwa die Vermeidung von Übersetzungsproblemen, was letztlich die Sicherheit und Stabilität des Netzwerks erhöht. Das gilt insbesondere für Licht-Infrastrukturen, also die (IP-basierende) digitale Vernetzung von Leuchten. Derartige Netzwerke bieten sich aus verschiedenen Gründen als Träger-Infrastruktur für das IoT an: So sind sie bereits in großer Zahl vorhanden – und zwar überall dort, wo Menschen leben und sich aufhalten, etwa in Gebäuden, auf öffentlichen Plätzen oder an Straßen. Überdies ist in die Lichtsysteme bereits eine eigene Energieversorgung integriert. Damit entfällt die aufwendige Verlegung von Stromleitungen oder der Einsatz von Batterien. Zudem verfügen die Leuchten normalerweise über ausreichend Platz für die Integration von Sensoren – was sie zur perfekten Drehscheibe für die Erfassung und Verbreitung von Daten macht.

Bild 2: Die Net4more-Toolbox besteht unter anderem aus LED-Treibern, Kommunikationsmodulen und Sensoren. Die Box lässt sich komplett in einer Leuchte unterbringen. Tridonic

Insbesondere die lichtbasierenden Infrastrukturen kommen hervorragend ohne Gateways aus. Diese Tatsache hat Tridonic als Spezialist für intelligente, vernetzte Beleuchtungslösungen aufgegriffen und eine entsprechende Hardware- und Softwareplattform entwickelt. Die Toolbox namens Net4more vereint verschiedene Komponenten wie LED-Treiber, Kommunikationsmodule, Schnittstellen, Sensoren, Router, Software und Applikationen zu einer durchdachten Gesamtlösung (Bild 2).

Das Besondere: Die Toolbox bietet als echte IP-to-the-end-node-Lösung erstmalig IP-Kommunikation bis zum Endknoten, also bis zur Leuchte. Diese wird Bestandteil des IoT und kann mit allen anderen Geräten im Netzwerk durchgängig kommunizieren. Dabei ist die Architektur offen, flexibel und hochskalierbar. So basiert die Toolbox auf dem offenen Standard des Internet-Protokolls IPv6 und ermöglicht die drahtlose Kommunikation auf einer Low-Power-Version nach dem Thread-Standard (Bild 3).

Bild 3: Net4more ermöglicht sowohl drahtlose als kabelgebundene Kommunikation in einem System. Eine Cloud-Plattform, Funktionen zum Lichtmanagement sowie Apps zur Bedienung sind Teil der Lösung. Tridonic

Und natürlich erfordert das Konzept keinerlei Gateways zur Vernetzung der lichtbasierenden IoT-Komponenten. Sämtliche Funktionen der Leuchte oder von Sensoren und Beacons lassen sich direkt adressieren. Dadurch reduziert sich der Aufwand für die Einrichtung, den Betrieb und die Erweiterung des Netzwerkes und der Anwendungssoftware deutlich. Zudem nutzt die Standardtechnologien wie /, CoAP, DTLS, LWM2M sowie die Ergebnisse europäischer Forschungsprojekte wie beispielsweise OpenAIS (Open Architectures for Intelligent Solid State Lighting Systems), die von bedeutenden Playern der Branche initiiert wurden.

Dabei handelt es sich um ein unter dem Horizon-2020-Programm teilweise von der europäischen Union finanziertes Projekt. Dessen Ziel ist es, ein offenes Ökosystem für die Implementierung smarter Lichtlösungen zu schaffen. Diese sollen sich einfach an die unterschiedlichen Bedürfnisse und Anforderungen der Menschen anpassen. Als weiteres Ziel verfolgt OpenAIS die effiziente Nutzung von Gebäuden mit hohem Komfort für die Bewohner und deutlich reduzierten Betriebskosten. Hierfür soll das IoT als Basistechnologie für das „Internet des Lichts“ dienen.

(ku)