Inhalt dieses Guides
IRL-Bonding systematisch diagnostizieren: einzelne WANs testen, Loss und RTT vergleichen, Datenlimit, Tunnel, Cloud-Gegenstelle und Stromversorgung prüfen.
Die mobile Übertragung als Gesamtkette
Zwischen Kamera und Plattform können Strom, Funk, Encoder und Transport getrennt ausfallen.
- Uplink unter Last prüfen
- Latenzreserve planen
- Failover unter Realbedingungen testen
Prüfe die Stationen nacheinander.
Hier werden keine Messwerte erhoben. Du prüfst lokal und dokumentierst die Ergebnisse selbst.
Mobilfunk
Ein einzelner Speedtest sagt wenig über Schwankungen während Bewegung und Funkzellenwechsel.
Upload und Stabilität entlang der tatsächlichen Route wiederholt unter Streaminglast prüfen.
Starke Einbrüche? Bitrate reduzieren, Reserve oder alternative Funkstrecke planen.
Transport / Latenz
SRT-Puffer und Netzwerkpfad beeinflussen Glitches und Verzögerung gemeinsam.
RTT, Verlust und Transportlatenz beobachten; Teststream mit Bewegung und Handover durchführen.
Puffer unzureichend? Latenz anhand reproduzierbarer Verlustsituationen justieren.
Strom / Failover
Stromwechsel und Modemausfall müssen den gesamten Stream überstehen, nicht nur einen Teil.
Unter sicheren Bedingungen Powerbankwechsel, Backup-Uplink und automatische Wiederaufnahme testen.
Abbruch? Aufbau vereinfachen und Ausfallpfad vor dem nächsten Außeneinsatz testen.
Fortschritt bleibt auf diesem Gerät und wird nicht übertragen.
IRL-Arbeitsmodus
IRL ist ein Gesamtsystem aus Funk, Transport, Strom, Thermik und Audio. Teste diese Ebenen getrennt.
Welche Ebene ist aktuell am schwächsten?
Peak-Speed allein reicht nicht. Stabilität, Handover und Zelllast bestimmen den Livebetrieb.
Transportprotokoll und Redundanz müssen zum Verhalten deiner Mobilfunkpfade passen.
Ein perfekter Uplink hilft nicht, wenn Smartphone, Hub, Mikrofon oder Stromversorgung ausfallen.
Ein Bonding-Setup mit zwei oder drei Mobilfunkverbindungen kann schlechter laufen als ein einzelner sauberer Link, wenn ein Pfad stark schwankt, der Tunnel falsch dimensioniert ist oder die Gegenstelle zum Engpass wird. Deshalb muss Fehlersuche jeden WAN-Pfad einzeln betrachten.
1. Jeden Mobilfunklink isoliert testen
Deaktiviere alle bis auf eine Verbindung und sende einen Teststream. Protokolliere Upload, RTT, Paketverlust und Dropouts. Wiederhole das für jede SIM. So erkennst du, ob ein einzelner problematischer Pfad das Gesamtsystem belastet.
2. Provider und Funkzelle prüfen
Zwei SIMs sind nur dann echte Diversität, wenn sie ausreichend unabhängige Netze nutzen. Bei gleichem Provider können beide Modems denselben Zellengpass sehen. Auch unterschiedliche Provider können in derselben Location gleichzeitig schwach sein.
3. Tunnel-Gegenstelle messen
Bonding benötigt eine Server- oder Cloud-Gegenstelle. Ist sie geografisch ungünstig, überlastet oder über einen schlechten Peering-Pfad angebunden, steigt die RTT aller Links. Teste einen anderen Standort, wenn der Dienst das erlaubt.
4. Smoothing/Duplizierung kontrollieren
Redundante Paketübertragung verbessert Robustheit, erhöht aber Bandbreite und Datenverbrauch. Wenn der Mobilfunktarif gedrosselt wird oder die Links ohnehin knapp sind, kann aggressive Duplizierung kontraproduktiv sein.
5. Strom und USB prüfen
Mehrere Modems ziehen gleichzeitig Leistung. Unterdimensionierte USB-Hubs oder Powerbanks können Geräte kurz trennen oder in einen langsameren Modus fallen lassen. Prüfe Kabel, USB-PD-Profile und Spannungsversorgung unter echter Last.
6. MTU und lokale Netzpfade
VPN-/Bonding-Tunnel fügen Header hinzu. Bei ungewöhnlichen Fragmentierungsproblemen kann die MTU relevant werden. Ändere solche Werte aber nicht blind; bestätige das Problem zuerst mit Logs und Paketstatistiken.
7. Ein definiertes Fallback behalten
Wenn Bonding selbst ausfällt, sollte klar sein, ob ein einzelner Link den Stream übernehmen kann oder ob lokal weiter aufgenommen wird. Ein komplexes Setup ohne Fallback ist nur komplizierter, nicht robuster.
Grundlagen: Bonding vs. Failover und Dual-SIM.
Änderungen einzeln testen
Bonding-Systeme besitzen viele Stellschrauben: Priorität, Weighting, Smoothing, Failover-Schwellen und Serverregion. Ändere immer nur einen Parameter pro Testlauf und protokolliere das Ergebnis. Wenn mehrere Dinge gleichzeitig angepasst werden, ist später nicht mehr erkennbar, welche Änderung die Stabilität verbessert oder verschlechtert hat.
