SignalRC braucht LTE

LTE, das im Sprachgebrauch bekannter ist als seine ausgeschriebene Variante Long Term Evolution, bezeichnet die Datenübertragungstechnologie innerhalb des 4G-Netzes. Damit ist es Teil der vierten Entwicklungsstufe unserer gängigen Mobilfunkstandards. Es löst das bis dahin führende 3G ab, das an seine technischen Grenzen gestoßen war. Dadurch wurde es Zeit für eine vollständige Neuentwicklung.

LTE baut auf ein IP-basiertes Mehrantennennetz auf. Das Netz ist so aufgebaut, dass die Endgeräte automatisch erkennen, wenn Antennen mit besserem Empfang in der Nähe sind. Die Empfangsdaten werden vom Endgerät in das Netz zurückgespeist. So erfährt das Netz, wann es einen Handover machen muss.

Im Idealfall bleiben bei einem Handover die Adresse des Endgeräts und die bestehenden Verbindungen bestehen. Der Handover dauert auch im Normalfall nur wenige Millisekunden, sodass laufende Verbindungen davon im Regelfall nicht betroffen sein sollten. Das funktioniert aber nur so lange reibungslos, wie die Antennen solche vom gleichen Netzbetreiber sind und mindestens eine Antenne noch guten Empfang hat.

Warum braucht man das?

LTE lässt sich als riesengroßes WLAN verstehen. Dadurch bleiben unsere Geräte dauerhaft verbunden. Genau das ist der Grund, warum SignalRC darauf aufbaut. Denn es liefert uns die Grundlage, auf der wir einen nahezu unendlichen Senderadius für die Kamerasignale und die Funkfernsteuerung unseres DDC-Trucks haben, den wir im Artikel „SignalRC – in Echtzeit ans Steuer“ [1] ausführlich vorgestellt haben. Und das alles auch noch, ohne eine riesige Sendeanlage mitzunehmen. Da die Module für Smartphones entwickelt wurden sind sie lächerlich klein und verbrauchen nahezu keinen Strom (wenn man es im Gesamtsystem eine RC-Autos betrachtet).

Welche Limitierungen gibt es?

Die grundsätzlichen Limitierungen bei LTE sind folgende:

• Bandbreite: Das obere Limit von LTE liegt bei einigen 100 Mbit. Damit ist es für die meisten Anwendungen, für die es gedacht ist, wie zum Beispiel Live-Video, vollkommen ausreichend.
• Latenz: Die Latenz ist schon eher ein Thema, das einem bei Echtzeitaufgaben zu schaffen machen kann. Diese liegt bei ab 20 ms, kann bei schlechterem Empfang aber auch schnell bei jenseits der 100 ms liegen.
• Kapazität der Antennen: Die Kapazität der Antennen wird erwartungsgemäß unter allen verbundenen Geräten aufgeteilt. Das kann dann schon mal dazu führen, dass die Bandbreite einbricht.
• Häufige Handovers: Wenn man sich zu schnell zwischen den Antennen bewegt, kann es dazu kommen, dass die Handovers sich überholen. Dann reißt die Verbindung ab und muss komplett neu aufgebaut werden.
• Netzabdeckung: Über das Netz und seine Verfügbarkeit in Deutschland brauche ich wohl niemandem berichten.
• Vertragliches: Seitdem das Internet mobil geworden ist, gibt es eigentlich keine echten Flatrates mehr. Die Einschränkung auf das Datenvolumen mit anschließender Drosselung (nennen wir es ehrlichkeitshalber „Abschalten“) ist wohl mittlerweile jedem hinlänglich bekannt.
• Nur ausgehende Verbindungen: Auf die Clients kann keine Verbindung aufgebaut werden. Sie können also nicht wie andere Server auf eingehende Verbindungen warten (Ports öffnen). Für viele Anwendungen ist das eher ein Feature.

Was davon betrifft uns?

Die schlimmsten Begrenzungen in Bezug auf unser SignalRC-Car sind die Latenz und das Vertragliche. Um alles andere kann man recht einfach herumarbeiten.

Die Latenz ist entscheidend, denn sie ändert direkt, wann unsere Steuerbefehle und Videos ankommen. Je mehr Latenz, desto weiter sind unser gesehenes Bild und die Realität voneinander entfernt. Hier kann man nur versuchen, keine weitere Zeit zusätzlich verlieren.

Die Einschränkung auf eine vorgegebene Gesamtdatenmenge ist auch ein Aspekt, aufgrund dessen wir uns zwischen Fahrzeit und Videodetails entscheiden müssen. Alternativ gäbe es auch die Möglichkeit, einen größeres Datenvolumen zu kaufen, was dann aber auch mit höheren monatlichen Kosten verbunden ist.

Wie bekommen wir das jetzt in unser Projekt?

Für meinen Aufbau habe ich mich für ein USB-LTE-Modul entschieden. Das hat meiner Meinung nach den entscheidenden Vorteil, dass es direkt vom USB-Port versorgt wird, sofern die Stromversorgung vom Raspberry Pi stabil ist. Weiterhin ist es im User Interface des Pi im Network Manager recht schnell eingerichtet. Ich habe der Einfachheit halber die PIN der SIM entfernt, damit sie nicht bei jedem Start neu eingegeben werden muss. So kann der Pi vollkommen autonom die Verbindung herstellen.

Welche Workarounds haben wir?

• Bandbreite und Antennenkapazität: Wenn sich die Bandbreite ändert, ist die größte Herausforderung, das Bild ruckelfrei und zeitnah zu übertragen. Hier bringt WebRTC glücklicherweise schon einiges mit, um das Bild stabil zu halten, auch wenn die Verbindung schlechter wird. Weiterhin können die Auflösung und die Bitrate angepasst werden. Dadurch wird der Stream weniger Bedarf an Bandbreite haben. Dazu bald mehr.
• Latenz: Wie bereits angesprochen wurde, ist an der Latenz nicht allzu viel zu verbessern, da auch die LTE-eigene Latenz es schon schwierig machen kann. Der einzige Hebel aus der Applikation heraus ist, an den Größen der Pakete und der Verarbeitungszeit zu sparen.
• Handovers: Die Handovers sollten keine Probleme ergeben, denn diese sind bei der geringen Geschwindigkeit des Fahrzeugs eher vernachlässigbar. Relevant werden diese erst, wenn das gesteuerte Fahrzeug die 200 km/h deutlich überschreitet. Solche Geschwindigkeiten wären aber schon angesichts der Latenz keine gute Idee.
• Eingehende Verbindungen: Dass die Fernbedienung keine eingehende Verbindung zum Raspberry Pi aufbauen kann, ist ein Nachteil gegenüber einer gewöhnlichen Fernbedienung. Diese pusht ständig den neuen Zielwert für die einzelnen Kanäle. Da der Empfänger nun aber nicht aktiv etwas annehmen kann, muss ein kleiner Umweg geschaffen werden. Der Server muss als zentraler Vermittler in die Mitte geschaltet werden. Glücklicherweise ergibt sich das schon von alleine dadurch, dass auch das Web-UI von irgendwoher geladen werden muss. So braucht es nur ein paar Funktionen und keine eigenen Anwendungen extra. Die nun eingehenden Verbindungen am Server zu verwalten ist mit SignalR glücklicherweise ebenfalls einfach.

Fazit

LTE bringt zwar seine Schwächen mit und wird in der Öffentlichkeit auch gerne mal dem Spott ausgesetzt. Dass es sich aber, wenn es erst einmal eingerichtet ist, wie ein riesiges WLAN bedienen lässt, macht es sehr stark. Nicht umsonst sind alle gängigen Smartphones damit ausgerüstet. Die nahezu endlose Reichweite ohne viel Extra-Aufwand macht es zum perfekten Transportmittel für alles, was das Projekt an Daten zu versenden hat.

Über die wenigen unschönen Nebenaspekte kann ohne Weiteres hinweggesehen werden. Die Vorteile überwiegen für diese Projekt definitiv. Vor allem gilt das für die Reichweite, die Sparsamkeit und die Einfachheit.

Exkurs

An dieser Stelle möchte ich auch noch eine Nachfrage von der DDC beantworten: Wäre LoRaWAN nicht eine Lösung, die man in Betracht ziehen kann?

Die Antwort lautet: Nein, das kann nicht funktionieren. Auch wenn die geringe Stromaufnahme ein grandioser Pluspunkt wäre, so sind die Datenraten (maximal 50 kbit/s) vollkommen ungeeignet für dieses Projekt, denn das wird selbst nur mit den Signalen der Remote Control schon sehr eng. Wir brauchen aber auch noch das Video.  

Wofür es Einsatz finden könnte, wäre als Backup der GPS-Übertragung. Beispielsweise könnte man das RC-Fahrzeug in einen Hibernate/Stromspar-Modus versetzen, wenn es gar kein Netz mehr hat. So könnte man es zumindest immer orten und andere Telemetriedaten erhalten, wenn auch langsam. 

[1] Georg Poweleit, SignalRC – in Echtzeit ans Steuer, dotnetpro 10-11/2025, Seite 46 ff.