Den optimalen Kommunikationspfad zwischen LoRa-Mesh-Geräten finden — bevor ein einziges Byte Nutzdaten übertragen wird.
von Clemens Simon
Das aktuelle Meshtastic-Flooding verschwendet 92–100% der Bandbreite in kleinen bis mittleren Netzwerken und scheitert bei der Zustellung bereits ab 100 Knoten (nur 27% mit Halbduplex). System 5 kombiniert Geo-Clustering, Multi-Pfad-Routing und adaptives QoS zu einem selbstheilenden Protokoll. Für kleine Netzwerke (20 Knoten): 100% Zustellung bei 99%+ weniger Bandbreite. Ab 500+ Knoten: 76% vs. 3% für Managed Flooding, bei 1000 Knoten 46% vs. 0%. Halbduplex-Kollisionen und Hop-Limits — die größten Skalierungsengpässe — werden irrelevant: Jeder Hop kostet ~1 Übertragung statt n.
Meshtastic nutzt Flooding: Jeder Knoten sendet jedes Paket weiter, in der Hoffnung, dass es das Ziel erreicht. Dieses Design war in Ordnung, als Mesh-Netzwerke 10–30 Knoten hatten. Aber wenn Communitys wie Bay Area Mesh, NYC Mesh und europäische Freifunk-Netze auf Hunderte oder Tausende Geräte wachsen, bricht der Ansatz in fünf grundlegenden Bereichen zusammen.
Jede Nachricht wird von jedem Knoten weitergesendet, der sie empfängt. Eine einzelne Nachricht an einen Empfänger erzeugt n Übertragungen im gesamten Netzwerk.
1–50 kbps Bandbreite. 1% Duty Cycle (EU-Recht). Halbduplex-Funk. Jedes Paket benötigt 50ms–2s Sendezeit. Budget: ~36–720 Pakete/Stunde/Knoten.
Jeder Knoten sendet bei jeder Nachricht — selbst Knoten, die weit vom beabsichtigten Pfad entfernt sind. Batteriebetriebene Geräte sind in Stunden leer statt in Wochen.
Mehrere Knoten senden gleichzeitig weiter. LoRa ist Halbduplex — Kollisionen zerstören Pakete und lösen weitere Neuübertragungen aus. Ein Teufelskreis.
Meshtastic begrenzt Hops auf 3–7, um Flood-Stürme zu verhindern. Aber das begrenzt die Reichweite: Eine Nachricht kann Knoten jenseits des Limits nicht erreichen. Jeder zusätzliche Hop multipliziert die Übertragungen mit n — das Limit kann also nicht erhöht werden, ohne das Netzwerk zu überfluten.
Im Folgenden vergleichen wir vier Routing-Strategien auf derselben 15-Knoten-Netzwerktopologie. Jede Animation läuft live in Ihrem Browser — beachten Sie den TX-Zähler in jedem Panel. Er zählt, wie viele Funkübertragungen für die Zustellung einer einzelnen Nachricht benötigt werden. Weniger TX = weniger Sendezeit, weniger Kollisionen, längere Batterielebensdauer. Der Unterschied ist dramatisch: von ~100 TX (Naives Flooding) zu ~2 TX (System 5).
Der theoretische Worst Case — jeder Knoten sendet jedes Paket genau einmal weiter. Meshtastic nutzt dies nicht wirklich (es verwendet das unten beschriebene Managed Flooding), aber diese Baseline zeigt die fundamentalen Kosten des Floodings: Bei n Knoten kostet eine einzelne Nachricht immer n Übertragungen, unabhängig von der Entfernung.
Die Quelle sendet ein Paket. Jeder empfangende Knoten sendet es einmal weiter. Das gesamte Netzwerk ist an jeder Nachricht beteiligt.
TX = n (einer pro Knoten)
Das ist, was Meshtastic heute tatsächlich verwendet (v2.6/2.7). Es ist bereits ziemlich clever: Bevor ein Knoten weitersendet, hört er kurz zu. Wenn er hört, dass ein Nachbar das Paket bereits weitergeleitet hat, bleibt er still (Unterdrückung). Knoten weit vom Sender senden zuerst weiter (sie haben niedrigeres SNR = kürzere Contention-Fenster), während nahe Knoten warten und oft unterdrücken. Knoten mit der ROUTER-Rolle senden immer weiter, um die Backbone-Abdeckung zu garantieren. Das reduziert Übertragungen um ca. 40–60% im Vergleich zu naivem Flooding — eine echte Verbesserung, aber die Kosten skalieren weiterhin linear mit der Netzwerkgröße.
Bevor ein Knoten weitersendet, hört er kurz zu. Wenn er hört, dass ein anderer Knoten bereits weitergesendet hat, unterdrückt er seine eigene Übertragung. Entfernte Knoten (niedriges SNR) bekommen kürzere Verzögerungen und senden zuerst weiter. Nahe Knoten warten und unterdrücken oft.
Knoten mit der ROUTER-Rolle (markiert mit R) überschreiben die Unterdrückung — sie senden immer weiter, um die Backbone-Abdeckung sicherzustellen.
TX ≈ 0,4n – 0,6n (~50% Unterdrückung)
Neu in Meshtastic v2.6 — ein bedeutender Schritt hin zu gerichtetem Routing, aber nur für Direktnachrichten (Unicast). Beim ersten Mal, wenn Sie jemanden anschreiben, wird normal geflutet. Das System beobachtet, welcher Relay-Knoten das Paket erfolgreich zugestellt hat, und speichert diesen Relay als „Next Hop“. Nachfolgende Nachrichten gehen nur über diesen einen Relay-Knoten — eine enorme TX-Reduktion. Aber es gibt keinen Multi-Pfad-Fallback: Wenn dieser Relay ausfällt, wird wieder geflutet. Und alle Broadcasts (Positions-Beacons, Kanal-Nachrichten) nutzen weiterhin Managed Flooding.
Phase 1: Die erste Nachricht nutzt Managed Flooding. Das System verfolgt, welcher Knoten erfolgreich weitergeleitet hat.
Phase 2: Nachfolgende Nachrichten gehen nur über den gelernten Next-Hop-Knoten (markiert NH). Ein Relay statt des ganzen Netzwerks.
Phase 3: Wenn der Next-Hop ausfällt, fällt das System auf Managed Flooding zurück und lernt einen neuen Relay.
Funktioniert nur für Direktnachrichten (Unicast). Broadcasts nutzen weiterhin Managed Flooding. Lernt nur einen Hop — keinen vollständigen Pfad.
Unser Vorschlag: ein fundamental anderer Ansatz, der sechs bewährte Netzwerk-Konzepte in einem Protokoll vereint. Knoten organisieren sich selbst in geografische Cluster anhand von GPS-Geohashes. Innerhalb eines Clusters kennt jeder Knoten die vollständige Topologie. Zwischen Clustern fungieren Grenzknoten als Brücken. Für jedes Ziel werden bis zu 5 unabhängige Routen vorberechnet und gecacht. Der Verkehr wird proportional zu einer Gewichtungsfunktion über diese Routen verteilt, die Linkqualität, Knotenlast und Batteriestand berücksichtigt. Wenn das Netzwerk unter Stress steht, drosselt ein adaptives QoS-Gate niederprioren Verkehr, um Notfallnachrichten zu schützen. Das Ergebnis: ~1 TX pro Hop für alle Nachrichtentypen — Unicast und Broadcast.
W(r) = α·Q(r) × β·(1−Load(r)) × γ·Batt(r)
Anteil(r) = W(r) / Σ W(alle)
Managed Flooding unterdrückt ~50% der Weiterleitungen, skaliert aber weiterhin mit O(n). System 5 routet entlang spezifischer Pfade — Kosten skalieren mit der Hop-Anzahl, nicht der Netzwerkgröße. Bei 100 Knoten: Managed Flood = ~1.500 TX pro Nachricht, System 5 = ~2 TX.
Next-Hop lernt einen einzelnen Relay-Knoten für Direktnachrichten. System 5 pflegt 2–3 vollständige Pfade mit gewichteter Lastverteilung für alle Verkehrsarten. Wenn ein Pfad ausfällt, aktiviert sich der nächste gecachte Pfad sofort — kein Flooding-Fallback nötig.
Die Intuition sagt „weniger Flooding = besser“, aber wie viel besser? Die folgenden Formeln zeigen die exakten TX-Kosten pro Nachricht für jeden Ansatz. Die Schlüsselvariable ist n (Netzwerkgröße): Flooding-basierte Ansätze skalieren mit n, während gerichtetes Routing mit d (Hop-Distanz) skaliert. Unter den Formeln bewerten wir jeden Ansatz anhand von 7 gewichteten Kriterien — von TX-Effizienz bis Broadcast-Unterstützung — für einen fairen Gesamtvergleich.
Jeder Knoten sendet einmal weiter. Bei n=100: 100 Übertragungen pro Nachricht. Die Kosten wachsen linear mit der Netzwerkgröße.
S = Unterdrückungsrate (Anteil der Knoten, die eine Weiterleitung hören und still bleiben). Abhängig von Dichte und SNR-Verteilung. Bei n=100 mit S=0,5: ~50 Übertragungen. Weiterhin O(n), aber ~50% günstiger als naiv.
Die erste Nachricht flutet (managed). Nach dem Lernen: d = Hop-Anzahl zum Ziel über den gecachten Relay. Amortisierte Kosten hängen von der Cache-Trefferquote ab. Broadcasts nutzen weiterhin Managed Flooding.
Jede Nachricht — Unicast und Broadcast — folgt einem vorberechneten Pfad. Kosten = Hop-Anzahl, unabhängig von der Netzwerkgröße. Bei n=100, d=2: 2 Übertragungen. Mit Fallback: begrenztes Cluster-Flooding fügt im schlimmsten Fall O(Clustergröße) hinzu.
Q = Linkqualität (OGM-Empfangsrate), Load = Warteschlangendruck, Batt = minimaler Batteriestand entlang der Route.
Verkehrsanteil: Anteil(r) = W(r) / Σ W(alle). Tuning: α=0,4, β=0,35, γ=0,25
| Kriterium (Gewichtung) | Naives Flood | Managed Flood | Next-Hop | System 5 |
|---|---|---|---|---|
| TX-Kosten pro Nachricht (20%) | 1 | 4 | 5 | 10 |
| Zustellzuverlässigkeit (20%) | 9 | 9 | 8 | 9 |
| Skalierbarkeit (15%) | 1 | 3 | 4 | 9 |
| Fehlertoleranz (15%) | 8 | 8 | 7 | 9 |
| Hop-Limit-Freiheit (10%) | 1 | 2 | 3 | 10 |
| Energieeffizienz (10%) | 1 | 3 | 5 | 8 |
| Broadcast-Unterstützung (10%) | 10 | 10 | 3 | 9 |
| GEWICHTETE GESAMTPUNKTZAHL | 4,3 | 5,5 | 5,1 | 9,2 |
Meshtastics Managed Flooding ist clever — aber weiterhin O(n). Wir haben keine neue Theorie erfunden. Stattdessen übernimmt System 5 sechs bewährte, praxiserprobte Konzepte aus Jahrzehnten der Netzwerkforschung und passt sie an die einzigartigen Einschränkungen von LoRa an (geringe Bandbreite, Halbduplex, 1% Duty Cycle, begrenzter RAM). Jedes Konzept löst ein bestimmtes Teilproblem:
Knoten organisieren sich selbst nach Geohash-Präfix. Vollständige Topologie innerhalb des Clusters, zusammengefasste Routen dazwischen. Skaliert von 10 bis 10.000+ Knoten.
Periodische Originator-Nachrichten. Empfangsrate pro Nachbar zählen. Keine komplexe Berechnung — einfach zählen, wie viele ankommen.
Verkehr wird proportional zum Routengewicht verteilt. Gute Pfade bekommen mehr Verkehr, aber nie allen. Kein einzelner Flaschenhals-Knoten.
Überlastete Knoten melden Warteschlangendruck. Verkehr meidet natürlich überlastete Pfade — wie Wasser, das um Steine fließt.
Erfolgreiche Zustellungen stärken eine Route. Timeouts schwächen sie. Unbenutzte Routen verblassen natürlich. Das Netzwerk lernt.
Wo ist der Zielknoten? Erst lokal fragen, dann Cluster, dann Region. Antworten werden gecacht. Begrenztes Flooding nur als letzter Ausweg.
Feedback von Bay Area Mesh-Betreibern deckte kritische Lücken im ursprünglichen Design auf. Ihre Berggipfel-Router (SUNL, Mt Diablo) zeigten, dass die Halbduplex-Funkphysik — nicht Routing-Algorithmen — der wahre Skalierungsengpass ist. Fünf Features wurden als direkte Antwort entwickelt.
Das Netzwerk identifiziert redundante Knoten (deren Nachbarn alle über andere Pfade erreichbar sind) und schaltet sie stumm. Stummgeschaltete Knoten hören weiterhin zu — sie empfangen Nachrichten, das Netzwerk weiß dass sie existieren — aber sie senden nicht weiter. Das entfernt das Kollisionsrauschen an Berggipfeln. Batteriefreundliche Rotation alle 10 Minuten. Ergebnis: TX halbiert, nur 3% weniger Zustellung.
LoRa-Funkgeräte sind Halbduplex: Ein Knoten kann nicht senden während er empfängt. Wenn ein Berggipfel 10 Weiterleitungen hört, ist er 10–20 Sekunden lang am Weiterleiten blockiert. Unser Simulator modelliert jetzt diesen pro-Knoten Funkzustand (IDLE/TX/RX). Ergebnis: Flooding bricht von 87,5% → 6% Zustellung ein. System 5 hält bei 77,5%.
Multi-Pfad-Routing kann Nachrichten in falscher Reihenfolge zustellen (A,B,C → C,B,A über 3 Pfade). Ein 2-Byte-Sequenzzähler pro (Quelle, Ziel)-Paar im Paket-Header lässt die App Lücken erkennen: „Seq 3 und 5 erhalten, 4 fehlt.“ Null zusätzliche TX-Kosten — nur 2 Bytes zum bestehenden Header hinzugefügt.
Wenn alle 5 gecachten Routen fehlschlagen, berechnet System 5 jetzt einen frischen BFS-Pfad unter Ausschluss fehlgeschlagener Knoten, bevor es Korridor-Flooding auslöst. Das gibt dem Protokoll einen weiteren gerichteten Versuch — und reduziert die teuren Fallback-Floods erheblich, die im Bay Area-Szenario dominierten.
Eine neue Bay Area-Simulation modelliert die tatsächliche Netzwerkstruktur: 7 Berggipfel-Knoten (45km Reichweite), 35 Hügel-/Dach-Knoten (10km), 193 Tal-/Indoor-Knoten (2,5km). Asymmetrische Verbindungen, Halbduplex, Capture-Effekt. Vier Bay Area-Szenarien testen Normal-, Stress-, Silencing- und kombinierte Bedingungen. Jetzt live ausprobieren →
| Szenario | Flood Zust. | S5 Zust. | S5 TX | Stumm |
| Bay Area (ohne Halbduplex) | 87,5% | 80,5% | 47K | — |
| Bay Area (Halbduplex) | 6,0% | 77,5% | 541K | 0% |
| Bay Area + Silencing | 6,0% | 74,5% | 268K | 57% |
| Bay Area + Stress | 4,0% | 52,0% | 302K | 0% |
| Bay Area + Silencing + Stress | 4,0% | 51,0% | 155K | 57% |
Kernerkenntniss: Halbduplex zerstört Flooding (87,5% → 6%), aber System 5 hält bei 77,5%. Node Silencing halbiert die TX-Kosten (541K → 268K) bei nur 3% weniger Zustellung. 128 von 193 Tal-Knoten werden stummgeschaltet — alle 7 Berggipfel-Knoten bleiben aktiv.
Beim Flooding multipliziert jeder Hop die Übertragungen über das gesamte Netzwerk. Bei System 5 kostet jeder Hop genau eine Übertragung. Diese einzige Änderung ermöglicht alles.
Jeder Knoten sendet bei jedem Hop weiter. Bei 100 Knoten und 5 Hops erzeugt eine einzelne Nachricht über 330.000 Übertragungen. Das Hop-Limit (Standard 3) ist ein Überlebensmechanismus — ohne es ertrinkt das Netzwerk.
Nur der weiterleitende Knoten sendet. Bei 100 Knoten und 5 Hops erzeugt eine einzelne Nachricht 5 Übertragungen. Kein Hop-Limit nötig — 20 Hops kosten dasselbe wie Flooding für 1 Hop.
| Szenario | Knoten | 3-Hop Zust. | 5-Hop Zust. | 7-Hop Zust. | Sys5 Zust. | Sys5 TX |
| Klein Lokal | 20 | 87% | 87% | 87% | 100% | 115 |
| Mittlere Stadt | 100 | 27% | 27% | 27% | 100% | 402 |
| Groß Regional | 500 | 3% | 3% | 3% | 76% | 412k |
| 1000 Knoten | 1000 | 0% | 0% | 0% | 46% | 182k* |
| 1500 Knoten | 1500 | 1% | 1% | 1% | 44% | 197k* |
* Bei 1000+ Knoten verbraucht System 5 mehr Gesamt-TX als Managed Flooding — liefert aber als einziges Protokoll überhaupt Nachrichten aus (46% vs. 0% bei 1000 Knoten). Managed Flooding liefert mit Halbduplex bei dieser Größe keine einzige Nachricht.
Kritische Erkenntnis: Mit Halbduplex und Kollisionen zerstört Managed Flooding die Zustellung bei Skalierung vollständig. Bei 100 Knoten kommen nur 27% an, bei 1000 Knoten 0% — unabhängig vom Hop-Limit. System 5 liefert 46% bei 1000 Knoten. Das Hop-Limit und die Halbduplex-Kollisionen machen große Netzwerke grundsätzlich unzuverlässig.
Keine künstlichen Hop-Limits mehr. Nachrichten können 20, 30 oder 50 Hops zum gleichen Pro-Hop-Preis durchlaufen. Die Reichweite des Netzwerks wird nur durch die Knotendichte begrenzt, nicht durch Protokoll-Einschränkungen.
Nur der weiterleitende Knoten sendet pro Hop — nicht jeder Knoten in Reichweite. Knoten abseits des Pfads schlafen durch. Die Batterielaufzeit steigt von Stunden auf Wochen.
Mit günstigen Hops funktioniert SHORT_FAST mit mehr Hops genauso gut wie LONG_SLOW mit weniger Hops — bei höheren Datenraten. Wählen Sie das Preset für Ihre lokalen Bedingungen, nicht für das Reichweiten-Limit des Netzwerks.
Kein zentraler Server, keine Konfiguration, keine Koordination. Wenn Knoten eingeschaltet werden, entdecken sie selbstständig Nachbarn über OGM-Beacons (alle 30 Sekunden), berechnen ihren geografischen Cluster aus GPS, identifizieren Grenzknoten als Cluster-Brücken und bauen Multi-Pfad-Routing-Tabellen auf — alles automatisch. Klicken Sie unten auf „Nächster Schritt“, um diesen Prozess zu beobachten. Jeder Schritt zeigt genau, was in der Firmware passiert. Für den vollständigen technischen Deep-Dive, siehe So funktioniert's →
Diese Animation zeigt, wie sich ein System 5 Mesh-Netzwerk von eingeschalteten Knoten zu einem vollständig gerouteten, lastverteilten Mesh selbst organisiert.
Mesh-Netzwerke existieren nicht im Vakuum — sie reichen von einem Dutzend Handfunkgeräten in einer Nachbarschaft bis zu Tausenden von Geräten über Kontinente hinweg. Die Geo-Clustering-Architektur von System 5 passt sich natürlich an: Ein einzelner Cluster verarbeitet lokalen Verkehr effizient, während Inter-Cluster-Routing über Grenzknoten auf beliebig große Netzwerke skaliert. Die drei Live-Simulationen unten zeigen, wie dasselbe Protokoll Nachbarschafts-, Kontinental- und globale Skalierung bewältigt. Beachten Sie die Knoten-Aktivitätslogs rechts — sie zeigen Echtzeit-Routing-Entscheidungen, OGM-Beacons und Failover-Ereignisse.
12 Knoten innerhalb von ~3km. Direkte LoRa-Verbindungen. Einzelner Geo-Cluster. Vollständige interne Topologie allen Knoten bekannt. Multi-Pfad-Routing mit Lastverteilung.
Cluster in Großstädten verbunden über MQTT-Gateways und Langstrecken-Relays. Grenzknoten überbrücken Cluster. DNS-ähnlicher Cache löst Knotenpositionen auf.
Kontinentale Super-Cluster verbunden über Internet-Backbone (MQTT). Hierarchische Geohash-Adressierung. Kaskadierende DNS-Caches für Knotenerkennung.
Ein Routing-Protokoll, das nur unter perfekten Bedingungen funktioniert, ist wertlos. In der realen Welt fallen Knoten aus (Batterien, Hardware), GPS-Signale brechen ab, Internet-Verbindungen fallen aus, und ganze Regionen werden dunkel. System 5 ist darauf ausgelegt, sich elegant zu verschlechtern: Multi-Pfad-Routing bietet sofortiges Failover (0ms — die nächste gecachte Route ist bereits bekannt), begrenztes Korridor-Flooding ist das Sicherheitsnetz, und das adaptive QoS-Gate stellt sicher, dass Notfallnachrichten auch bei einem kollabierenden Netzwerk immer durchkommen. Klicken Sie unten auf Knoten oder Verbindungen, um Ausfälle zu simulieren und das Netzwerk in Echtzeit reagieren zu sehen.
Ein Knoten fällt aus (Batterie, Hardware). Seine Routen brechen sofort. System 5 wechselt zu gecachten Backup-Routen in 0ms. Fällt ein Grenzknoten aus, übernimmt der zweite Grenzknoten. Fallen alle Grenzknoten aus, fällt der Cluster auf Flooding zurück.
GPS-Modul fällt aus oder verliert Signal. Der Knoten kann seinen Geohash nicht berechnen. Fallback: Nachbar-Konsensus — wenn 4 von 5 Nachbarn „u0x8“ sagen, übernimmt der Knoten diesen Cluster. Wenn keine Nachbarn GPS haben: „Heimatloser“ Modus mit lokalem Flooding.
Internetbasierte MQTT-Verbindungen zwischen Städten fallen aus. Das LoRa-Relay-Subnetz aktiviert sich — eine Kette kleiner Relay-Knoten überbrückt Cluster über reinen Funk. Langsamer (mehr Hops) aber funktional. Die grüne Kette unter den Clustern ist dieser Backup-Pfad.
Wenn der Network Health Score (NHS) sinkt, wird niederpriorer Verkehr automatisch blockiert. SOS (P0) kommt immer durch, selbst bei 1% Netzwerkgesundheit. Firmware-Updates (P7) nur wenn das Netzwerk perfekt ist. Das Netzwerk atmet: Weniger Verkehr unter Stress = Selbstheilung.
Behauptungen sind nur so gut wie ihre Beweise. Wir haben einen Python-Simulator gebaut, der EU 868MHz LoRa-Physik modelliert (Pfadverlust, Gelände, Duty Cycle, Kollisionen, Halbduplex-Funk) und 6 Router auf identischen Netzwerken betreibt: Naives Flood, Managed Flood bei 3/5/7 Hop-Limits, Next-Hop und System 5. Jedes Szenario sendet 100–300 zufällige Nachrichten und misst Zustellrate, Gesamtübertragungen und Pro-Knoten-Last. Die folgenden Ergebnisse stammen aus 26 Szenarien mit 20–1500 Knoten — einschließlich realistischer Umgebungen (ländlich, maritim, indoor, Autobahn-Konvoi) und Stresstests (Knotenausfall, Verbindungsverschlechterung, Duty-Cycle-Durchsetzung). Den interaktiven Simulator ausprobieren →
| Szenario | Knoten | Naiv TX | Managed TX | Next-Hop TX | Sys5 TX | S5 Zustell. | S5 vs. Managed |
|---|
Klicken Sie auf den Button, um zwischen Log- und Linearskala umzuschalten
System 5 hält hohe Zustellung auch unter Ausfällen aufrecht
Wie viel der am stärksten belastete Knoten senden muss — weniger ist besser
Hochpriorer Verkehr kommt auch bei verschlechtertem Netzwerk durch
Mit Halbduplex-Funk und Kollisionen verschwendet Managed Flooding nicht nur Bandbreite — es scheitert bei der Zustellung. Bei 100 Knoten kommen nur 27% der Nachrichten an. Bei 500 Knoten nur 3%, bei 1000 Knoten 0%. System 5 liefert 76% bei 500 Knoten und 46% bei 1000 Knoten. Halbduplex-Kollisionen und Hop-Limits sind die primären Skalierungsbarrieren, die große Mesh-Netzwerke grundsätzlich unzuverlässig machen.
Mesh-Netzwerke umfassen Funktechnik, Graphentheorie und Protokolldesign. Hier ist eine Kurzreferenz für die in dieser Präsentation verwendeten Fachbegriffe — von LoRa-Grundlagen bis zu den protokollspezifischen Konzepten, die System 5 einführt.
Halbduplex-Funk und Kollisionen zerstören Managed Flooding bereits bei mittleren Netzwerken — bei 100 Knoten nur 27% Zustellung, bei 500 Knoten 3%, bei 1000 Knoten 0%. Die Bay Area Mesh-Erfahrung bestätigt dies: Halbduplex-Einschränkungen lassen Flooding auf nur 6% Zustellung zusammenbrechen. System 5 durchbricht diese Barrieren mit gerichtetem Routing bei ~1 TX pro Hop und übersteht sowohl die Halbduplex-Kollisionskaskade als auch die Hop-Limit-Mauer. Über 26 Szenarien hinweg (alle mit Halbduplex und Kollisionen) dominiert System 5 kleine bis mittlere Netzwerke und liefert bei Skalierung deutlich mehr — obwohl sehr große, dünn besetzte Netzwerke für jedes Protokoll herausfordernd bleiben. Das Protokoll ist vollständig spezifiziert, ein funktionierender ESP32-Firmware-Prototyp existiert für drei Board-Typen, und der vollständige Quellcode ist unter MIT-Lizenz verfügbar.
Komplette Analyse mit Problemstellung, allen fünf bewerteten Ansätzen, mathematischer Bewertung, Resilienz-Design, QoS-Architektur und Projekt-Roadmap.