Startseite > Netzwerke & IT-Infrastruktur > Fernzugriff mit Weltraum-Latenz

Steuern via Satelliten-Internet - Teil 1

Fernzugriff mit Weltraum-Latenz

21. Dezember 2020, 7:00 Uhr | Dr. Johannes Wiele/jos

Fortsetzung des Artikels von Teil 1

Das Test-Setup

Um den Test für möglichst viele Leser nützlich zu gestalten, wurde die Testinfrastruktur so ausgerichtet, dass sie unterschiedliche professionelle Anwendungsmodelle spiegeln kann: Zugriff auf Lokationen einer Ferienhauskette, Fernüberwachung einer Baustelle im Nirgendwo, Überwachung technischer Einrichtungen wie etwa Messstationen, abgelegene Veranstaltungsorte und temporäre „Pop-up Locations“, außergewöhnliche Arbeitsstätten und so weiter.
Als Parameter sind festgelegt:

Aufbau nach dem Fliegende-Bauten-Prinzip: Die gesamte Infrastruktur sollte aus Standardteilen schnell eingerichtet und genauso schnell wieder abgebaut und zum nächsten Einsatzort gebracht werden können.
Technisch offene Architektur: Beispielsweise IP-Kameras und Messgeräte beliebiger Hersteller sollten je nach aktuellem Bedarf leicht eingebunden und über eine Konsole zugänglich gemacht werden können.
Möglichst wenig Programmierung, Konfigurationsarbeit und Bit-Fummelei. Jeder Administrator, gleich welchen Fachgebiets, sollte die Anlage in kurzer Zeit implementieren und steuern können, ohne lange an Codes und Anpassungen herumfeilen zu müssen.

Angesichts dieses Anforderungskatalogs haben wir uns schweren Herzens gegen dasjenige Modell entschieden, das vielen Technik-Freaks jetzt wahrscheinlich zuerst einfällt und dass sie vermutlich ins Schwärmen bringen würde: Hinter dem Modem ein Router und dann ein Zoo an perfekt getrimmten Raspberry-Pis und Sensoren, mit FHEM oder einer vergleichbaren Smart-Building-Steuerzentrale als Kernanwendung.

Man mag mich korrigieren – aber allein die Tatsache, dass längst nicht jede IP-Kamera mit FHEM oder ähnlichen Plattformen funktioniert, und dass die Einbindung in offene Smart-Environment-Umgebungen nur selten in den Handbüchern der Gerätehersteller beschrieben ist und stattdessen viel Experimentierfreude, Forenstudium und enge Vertrautheit mit den Systemen voraussetzt, macht das Modell für das hier angestrebte offene „Quick and Dirty“-Konzept nicht zur ersten Wahl.
In unserem Fall sollte man zum Beispiel Kameras nach ihrer Abbildungsleistung wählen können und nicht nach ihrer Integrierbarkeit mit einer speziellen Software. Das heißt jedoch nicht, dass ins Konzept nicht auch der eine oder andere Mess-
Raspberry mit speziellen Schnittstellen passt.

Unsere Zielinfrastruktur sieht folgende Elemente vor:

Der Satellitenanbieter stellt Verbindung, Schüssel und SAT-Modem, und
hinter dem SAT-Modem ist ein Standard-WLAN-Router angeordnet. Bei Bedarf kommen weitere Access-Points oder auch Repeater dazu,
das Netz ist so weit wie möglich drahtlos betrieben, um Verkabelungen zu vermeiden. Das ist nicht nur beim angedachten temporären Baustellen-Use-Case von Vorteil, sondern auch dann, wenn alte Gemäuer und gegebenenfalls ein größeres offenes Gelände abzudecken sind,
Kern-Server ist ein Mini-PC nach Intel-NUC-Art, Kernanwendung dessen ganz normale Windows- oder Linux-Benutzeroberfläche,
für den Fernzugriff kommt ein verbreitetes Administrationswerkzeug wie Anydesk oder Teamviewer zu Einsatz. Immerhin ist ja unklar, ob sich für die oben genannten Einsatzzwecke stets ohne Probleme eine feste IP-Adresse beziehen lässt,
über die Tools wird jeweils genau eine verschlüsselte Verbindung an den Zielort aufgebaut, deren Stabilität und Sicherheit einschätzbar ist. Im Haus steuert der Server die Kameras und Sensoren an. Es darf nicht etwa für jede Kamera und andere Geräte ein separater App-Zugriff mit Routing über Fernost oder Süd- und Nordamerika existieren, wie es bei billiger Smart-Home-Technik oft der Fall ist,
Hochverfügbarkeitslösungen sollten bei Bedarf machbar sein, etwa ein Weiterfunktionieren oder Wiederanlaufen nach oder bei Stromausfall und ein Ersatzrechner für den Fall, dass die Steuerzentrale versagt. Messen, aufnehmen und steuern sollte die Technik vor Ort auch autonom können, wenn die Verbindung einmal abgerissen ist, und
die Kommunikationsstrategie mit dem Zielort sollte die Latenzproblematik und möglicherweise geringe Bandbreiten oder Zeiten schlechter Verbindungswerte ausgleichen können. Kameras etwa sollten in der Lage sein, bei entdeckten Bewegungen Warnungen und Schnappschüsse auch über einen langsamen E-Mail-Kanal auf den Weg zu bringen, weil nicht davon auszugehen ist, dass permanent ungestörtes Streaming stattfinden kann.

Schreckgespenst Latenz

Bevor es an den ersten „Proof of Concept“ geht, sei noch kurz auf den Anlass zum Test eingegangen: das Latenzproblem. Der eigentliche Datei-Transfer via Satellit, etwa beim Download oder beim Streaming, kann so schnell sein wie über eine feste Leitung, aber die Reaktionsgeschwindigkeit in der Verbindung ist geringer. Es läuft wie bei einem Wasserschlauch, den man neu anschließt: Bis das Wasser vom Anfang bis zum Ende gekommen ist, dauert es, aber dann fließt es dort so schnell heraus wie durch den Hahn hinein. Dreht man ihn wieder ab, geht es hinten noch eine Weile weiter.

Jeder Mausklick und jedes Steuersignal muss zuerst in den Weltraum und von dort zurück auf die Erde gelangen und die Reaktion dann auch. Wie groß die Verzögerung genau ist, steht in den weiteren Folgen noch zur Diskussion. Wir wussten zu Beginn jedoch schon, dass das Satelliten-Internet aus diesem Grund für Online-Spieler untauglich ist. Herausfinden wollten wir, wie sich auf diese Weise zum Beispiel Messanlagen, Server oder Kameras fernsteuern lassen.