Wie System 5 funktioniert

Das große Bild

Jedes Routing-Protokoll beantwortet eine Frage: Wenn Knoten A eine Nachricht an Knoten Z senden will, welche Zwischenknoten sollen sie weiterleiten?

Das aktuelle Meshtastic verwendet Managed Flooding: Jeder Knoten sendet jede Nachricht weiter, in der Hoffnung, dass sie das Ziel erreicht. Das funktioniert für kleine Netzwerke, erzeugt aber eine Bandbreitenexplosion bei Skalierung — 100 Knoten bedeuten ~100 Übertragungen pro Nachricht.

System 5 verfolgt einen grundlegend anderen Ansatz: Knoten organisieren sich selbst in geografische Cluster, entdecken Multi-Hop-Routen und senden jede Nachricht über einen spezifisch berechneten Pfad. Die Kosten pro Nachricht sind proportional zur Anzahl der Hops, nicht zur Anzahl der Knoten.

Die folgenden Abschnitte erklären jeden Schritt im Detail.

Schritt 1: Start — Was passiert, wenn ein Knoten eingeschaltet wird

Wenn ein System 5-Knoten hochfährt, weiß er noch nichts über das Netzwerk. Hier ist die genaue Abfolge:

1. Hardware-Initialisierung: Das LoRa-Funkmodul beginnt auf der konfigurierten Frequenz zu lauschen (EU 868MHz). Das GPS-Modul beginnt mit der Satellitenerfassung (falls vorhanden).
2. Positionsbestimmung: Der Knoten versucht drei Methoden in dieser Reihenfolge:
   • Echtes GPS — beste Option, genau auf ~5m (T-Beam, RAK4631 mit GPS-Modul)
   • RSSI-Triangulation — falls kein GPS, aber 3+ Nachbarn mit bekannten Positionen, wird die Position aus der Signalstärke geschätzt
   • Cluster-Übernahme — falls beides nicht funktioniert, wird die Cluster-ID des stärksten Nachbarn übernommen
3. Geohash-Berechnung: GPS-Koordinaten werden in einen Geohash-String umgewandelt (z.B. "u33d"). Die ersten 4 Zeichen definieren den Cluster des Knotens. Knoten mit dem gleichen 4-Zeichen-Präfix befinden sich im selben Cluster.
4. OGM-Broadcast: Der Knoten sendet seine erste Originator Message (OGM) — ein kleines Paket das verkündet: „Ich existiere, hier sind meine Position, mein Batteriestand und meine Cluster-ID."

Schritt 2: Nachbarerkennung via OGM

Alle 30 Sekunden sendet jeder Knoten eine OGM (Originator Message). Das ist ein kompaktes Paket (~20 Bytes) mit folgendem Inhalt:

Wenn ein Knoten eine OGM empfängt, geschieht Folgendes:

1. RSSI/SNR messen des empfangenen Signals → bestimmt die Verbindungsqualität zum Sender
2. Sender in die Nachbartabelle eintragen/aktualisieren (max. 16 Nachbarn pro Knoten)
3. Cluster-ID vermerken — falls der Sender in einem anderen Cluster ist, könnte dieser Knoten ein Border Node sein

Verbindungsqualität ist asymmetrisch

Ein kritisches Detail: Die Verbindung von A→B kann eine andere Qualität haben als B→A. Ein Berggipfel-Knoten mit freier Sichtlinie sendet möglicherweise mit Qualität 0,95 zum Talknoten, aber der Talknoten (umgeben von Gebäuden) kann nur mit Qualität 0,3 zurücksenden. System 5 verfolgt beide Richtungen unabhängig.

Schritt 3: Geo-Clustering — Selbstorganisierende Geografie

Nach einigen OGM-Runden (~1–2 Minuten) haben die Knoten ihre Nachbarn entdeckt. Nun organisiert sich das Netzwerk selbst in geografische Cluster.

Wie Clustering funktioniert

Es gibt keinen zentralen Koordinator. Jeder Knoten handelt unabhängig:

1. Berechnet seinen Geohash aus seiner GPS-Position
2. Nimmt die ersten 4 Zeichen als seine Cluster-ID
3. Knoten mit dem gleichen 4-Zeichen-Präfix sind automatisch im selben Cluster

Das ist komplett dezentral — kein Knoten muss das gesamte Netzwerk „kennen". Wenn ein neuer Knoten in München eingeschaltet wird, berechnet er seinen Geohash ("u281") und ist automatisch Teil des München-Clusters. Er braucht keine Genehmigung und keine Koordination.

Border Nodes — Die Brücken zwischen Clustern

Ein Border Node ist jeder Knoten, der Nachbarn in einem anderen Cluster hat. Border Nodes sind entscheidend — sie sind die Brücken für das clusterübergreifende Routing.

System 5 begrenzt Brückenverbindungen auf 2 pro Clusterpaar, um eine Routenexplosion zu verhindern. Die zwei stärksten Verbindungen zwischen jedem Paar benachbarter Cluster werden ausgewählt.

Warum das skaliert

Jeder Knoten muss nur Folgendes kennen:

• Vollständige Topologie innerhalb seines eigenen Clusters (direkte Nachbarkenntnis, ~20–50 Knoten)
• Border Nodes zu benachbarten Clustern (2 pro Paar × ~8 Nachbarcluster = 16 Knoten)
• Cluster-Level-Routen für entfernte Cluster (abstrakt — „um Cluster u33e zu erreichen, gehe über Border Node E")

Ein Knoten in San Francisco muss nicht jeden einzelnen Knoten in Oakland kennen. Er muss nur wissen: „Um Oakland zu erreichen, route über Border Node #47 auf dem Bay Bridge-Kamm."

Schritt 4: Routenberechnung — Mehrere Pfade finden

Sobald Cluster und Border Nodes bekannt sind, berechnet jeder Knoten bis zu 5 Routen zu jedem Ziel, das er erreichen möchte.

Der Algorithmus: BFS mit progressivem Ausschluss

1. Kürzesten Pfad finden via Breadth-First Search (BFS) von Quelle zu Ziel
2. Zwischenknoten aufzeichnen dieses Pfades
3. Diese Zwischenknoten ausschließen und den nächstkürzesten Pfad finden (erzwingt eine andere Route)
4. Bis zu 5 Mal wiederholen — jeder neue Pfad muss mindestens einen anderen Zwischenknoten verwenden

Routenqualitätsberechnung

Für jede Route ist die Qualität das Produkt aller Verbindungsqualitäten entlang des Pfades:

Wenn eine einzelne Verbindung Qualität 0,5 hat, sinkt die Gesamtroutenqualität erheblich. Das bestraft natürlich lange Pfade und Pfade mit schwachen Verbindungen.

Lazy vs. Eager Berechnung

• Kleine Netzwerke (<200 Knoten): Routen werden beim Start für alle Paare vorberechnet (Eager-Modus)
• Große Netzwerke (>200 Knoten): Routen werden bei Bedarf berechnet, wenn eine Nachricht gesendet werden muss (Lazy-Modus). Einmal berechnet, werden sie gecacht.

Schritt 5: Eine Nachricht senden — Gewichtete Routenauswahl

Wenn Knoten A eine Nachricht an Knoten Z senden will, ist dies der genaue Entscheidungsprozess:

Ist die Priorität dieser Nachricht hoch genug für den aktuellen Netzwerkzustand? (Siehe Schritt 6)

Alle gecachten Routen zum Ziel Z nachschlagen. Typischerweise 2–5 Routen.

Routen entfernen, bei denen ein Zwischenknoten ausgefallen ist (Batterie = 0) oder eine Verbindung unterbrochen ist.

Für jede verbleibende Route wird ein Gewicht berechnet, das drei Faktoren ausbalanciert:

Dies ist eine kritische Designentscheidung. System 5 wählt nicht immer die beste Route. Es wählt Routen probabilistisch, proportional zu ihrem Gewicht:

Beispiel: Wenn Route 1 Gewicht 0,8 und Route 2 Gewicht 0,4 hat:

• Route 1 wird ~67% der Zeit gewählt (0,8 / 1,2)
• Route 2 wird ~33% der Zeit gewählt (0,4 / 1,2)

Das hält sekundäre Routen „warm" — gelegentlich fließt Verkehr durch sie, sodass das Netzwerk weiß, dass sie noch funktionieren. Wenn Route 1 ausfällt, ist Route 2 sofort mit aktuellen Qualitätsdaten verfügbar.

Die Nachricht wird entlang des gewählten Pfades gesendet, ein Hop nach dem anderen:

1. A sendet an B (erster Hop im Pfad)
2. Wenn B empfängt → B leitet an D weiter (nächster Hop)
3. Wenn B nicht empfängt → A wiederholt (bis zu 3 Mal bei guten Verbindungen, 5 bei schlechten)
4. Wenn alle Wiederholungen scheitern → nächste gecachte Route versuchen (bis zu 5 Routenversuche)
5. Wenn alle Routen scheitern → Fallback auf begrenztes Cluster-Flooding

Backpressure — Automatische Stau-Vermeidung

Wenn die Warteschlange eines Zwischenknotens sich füllt, wendet System 5 graduellen Gegendruck an:

Das verhindert kaskadierende Überlastung: Wenn ein Knoten beginnt, überlastet zu werden, verteilt sich der Verkehr natürlich auf andere Pfade, bevor der Knoten Pakete verwirft.

Schritt 6: QoS — Priorisierung unter Druck

Nicht alle Nachrichten sind gleich. System 5 verwendet einen Network Health Score (NHS) pro Cluster, um niedrig priorisierten Verkehr zu drosseln, wenn das Netzwerk belastet ist.

NHS-Berechnung

NHS ist ein Wert von 0,0 bis 1,0, der den Gesundheitszustand des Clusters repräsentiert, basierend auf:

• Durchschnittliche Verbindungsqualität über alle Verbindungen im Cluster
• Anzahl aktiver (lebender) Knoten vs. erwartete Knoten
• Durchschnittliche Warteschlangenauslastung der Cluster-Mitglieder

Prioritäts-Gating

Priorität 0 = SOS/Notfall — kommt immer durch, unabhängig vom Netzwerkzustand. Das stellt sicher, dass in einem Katastrophenszenario kritische Nachrichten niemals durch routinemäßige Telemetrie blockiert werden.

Schritt 7: Fallback — Wenn alle Routen versagen

Wenn alle 5 gecachten Routen versagen (nach Wiederholungen auf jeder einzelnen), gibt System 5 nicht auf. Es fällt zurück auf begrenztes Cluster-Flooding — eine gezielte Mini-Flut entlang des Korridors zwischen Quelle und Ziel.

Wie begrenztes Flooding funktioniert

1. Cluster-Level-Pfad finden: BFS auf dem Cluster-Nachbarschaftsgraphen vom Quell-Cluster zum Ziel-Cluster
2. Korridor definieren: Quell-Cluster + Ziel-Cluster + alle Border Nodes entlang des Cluster-Pfads
3. Nur innerhalb des Korridors fluten: Nachricht wird nur an Knoten im Korridor gesendet — nicht ans gesamte Netzwerk

Das ist dramatisch günstiger als netzwerkweites Flooding. In einem 500-Knoten-Netzwerk mit 10 Clustern betrifft ein vollständiges Flooding alle 500 Knoten. Ein begrenztes Korridor-Flooding betrifft ~100 Knoten (2 vollständige Cluster + Border Nodes).

Schritt 8: Selbstwartung — Routen aktuell halten

Netzwerke ändern sich ständig: Knoten bewegen sich, Batterien entleeren sich, Verbindungen verschlechtern sich. System 5 wartet sich durch mehrere Mechanismen selbst:

Routenqualitäts-Abklingung (Pheromon-Modell)

Inspiriert von der Ameisenkolonie-Optimierung: Alle 30 Sekunden klingen alle gecachten Routenqualitäten um 5% ab:

Routen, die tatsächlich genutzt werden, erhalten ihre Qualität aktualisiert aus realen Verbindungsmessungen. Routen, die nie genutzt werden, verblassen allmählich auf null und werden schließlich ersetzt. Das stellt sicher, dass die Routing-Tabelle immer die aktuellen Netzwerkbedingungen widerspiegelt, nicht veraltete historische Daten.

Routen-Feedback

Nach jedem Nachrichtenzustellungsversuch:

• Erfolg: Routenqualität um 5% erhöht (gedeckelt bei 1,0). Fehlerzähler auf 0 zurückgesetzt.
• Misserfolg: Routenqualität halbiert. Fehlerzähler erhöht. Nach 3 Fehlschlägen wird die Route bis zur Aktualisierung durch die nächste OGM-Runde von der Auswahl ausgeschlossen.

Nachbar-Verdrängung

Wenn ein Knoten einen neuen Nachbarn entdeckt, aber seine Tabelle voll ist (16 Einträge), wird der Nachbar mit der niedrigsten Verbindungsqualität verdrängt. Das stellt sicher, dass die Routing-Tabelle immer die besten verfügbaren Verbindungen enthält.

Dynamisches Hop-Limit

Anders als Meshtastics festes 3–7 Hop-Limit verwendet System 5 ein dynamisches Limit, das mit der Netzwerkgröße skaliert:

Für ein 100-Knoten-Netzwerk: max_hops = √100 × 3 = 30. Für ein 1000-Knoten-Netzwerk: max_hops = 40 (gedeckelt). Das ermöglicht Nachrichten, große Netzwerke zu durchqueren, ohne künstliche Grenzen, und verhindert gleichzeitig Endlosschleifen.

Das Half-Duplex-Problem (Bay Area-Entdeckung)

Dies ist die wichtigste reale Beschränkung, die Simulatoren typischerweise ignorieren. LoRa-Funkmodule sind Half-Duplex: Ein Knoten kann nicht senden, während er empfängt.

Warum das für Flooding wichtig ist

Betrachten wir einen Berggipfel-Router auf 600m Höhe, der 100 Knoten hören kann. Wenn eine Nachricht durch das Netzwerk flutet:

1. Knoten A sendet eine Nachricht. Der Berggipfel hört sie (jetzt im RX-Zustand).
2. 10 Dachknoten nahe A hören sie ebenfalls und senden gleichzeitig weiter.
3. Der Berggipfel empfängt noch diese 10 Weitersendungen — er kann nicht senden.
4. 4 Langstrecken-Router senden ebenfalls weiter. Der Berggipfel steckt immer noch im RX-Zustand fest.
5. Bis der Berggipfel senden kann, ist der Timer des Managed-Flooding-Algorithmus abgelaufen — er sendet entweder weiter (verursacht weitere Kollisionen) oder unterdrückt (Nachricht stirbt).

Ergebnis: 5% tatsächliche Nutzung wird zu 50% Kanalauslastung am Berggipfel, und Nachrichten schaffen es nicht über den ersten Hop hinaus.

Warum System 5 Half-Duplex überlebt

Mit gerichtetem Routing empfängt der Berggipfel-Knoten ein gezieltes Paket (nicht 14 gleichzeitige Weitersendungen). Er verarbeitet es, wartet auf ein freies TX-Fenster und leitet an den nächsten Hop weiter. Die Funk-Zustandsmaschine ist einfach:

Simulationsergebnisse

Wir haben eine Bay Area-artige Simulation mit 235 Knoten in 3 Höhenstufen und Half-Duplex-Funkmodellierung erstellt. Die Ergebnisse bestätigen die realen Beobachtungen:

Half-Duplex lässt Flooding von 87,5% → 6% Zustellung zusammenbrechen. System 5 hält bei 77,5%. Probiere das Bay Area-Szenario im Live-Simulator →

Speicherbedarf — Läuft das auf dem nRF52?

Reale Mesh-Geräte haben enge Speichergrenzen. Der nRF52840 (verwendet im RAK4631 Solar-Router) hat 256KB RAM, mit ~64KB verfügbar nach BLE- und LoRa-Stacks.

Datenstrukturen

Skalierung mit Netzwerkgröße

Die Kernidee: Geo-Clustering bedeutet, dass ein Knoten nur seinen eigenen Cluster + Grenzrouten verfolgt. Ein 10.000-Knoten-Netzwerk bedeutet nicht 10.000 Routeneinträge — es bedeutet ~200 Einträge (eigene Cluster-Mitglieder + Border Nodes zu benachbarten Clustern).

nRF52-Optimierung

Für speicherbeschränkte Geräte können diese Firmware-Konstanten reduziert werden:

• S5_MAX_ROUTES: 5 → 2 (spart 60% Speicher)
• S5_MAX_PATH_LEN: 15 → 8 (reduziert Routengröße um 47%)
• Lazy-Routenberechnung verwenden (nur Routen zu kürzlich kontaktierten Zielen cachen)
• Ergebnis: ~15 KB für 200-Ziel-Ansicht → passt komfortabel auf den nRF52

Bay Area-Topologie — Der Praxistest unter Extrembedingungen

Basierend auf Feedback von Bay Area Mesh-Betreibern haben wir eine Simulation erstellt, die die tatsächliche Netzwerkstruktur modelliert:

Drei-Stufen-Höhenmodell

Was dieses Szenario schwierig macht

• Extreme Asymmetrie: Berg→Tal Qualität ~1,0 (freie Sichtlinie), Tal→Berg Qualität ~0 (urbanes Gelände + Distanz)
• Half-Duplex-Blockierung: Bergknoten hören jede Übertragung im 45km-Radius — sie sind während des Floodings permanent im RX-Zustand
• Kollisionskaskade: 10+ Knoten senden gleichzeitig am Berggipfel → Capture Effect hilft nur, wenn ein Signal 6dB stärker ist
• Hidden Terminal: Zwei Talknoten können sich gegenseitig nicht hören, senden aber beide gleichzeitig an denselben Berggipfel

Probiere dieses Szenario im Live-Simulator → — wähle „Bay Area Mesh (235 nodes, 3-tier elevation)" aus dem Dropdown.

Lies die vollständige Q&A mit der Bay Area Mesh-Community →

Node Silencing — Redundante Knoten stummschalten

Eines der wirkungsvollsten v2.0-Features, inspiriert durch Feedback der Bay Area Mesh-Community. Die Kernerkenntnis: In einem 235-Knoten-Netzwerk sind die meisten Talknoten redundant — ihre Nachbarn können alle über andere Pfade erreicht werden. Jedes Mal, wenn diese redundanten Knoten weitersenden, fügen sie Kollisionsrauschen an Berggipfel-Empfängern hinzu, ohne zur Nachrichtenzustellung beizutragen.

Wie es funktioniert

1. Redundanz-Bewertung: Für jeden Knoten wird jeder Nachbar geprüft — kann dieser Nachbar von mindestens 2 anderen lebenden Knoten erreicht werden? Falls ja, ist diese Nachbarverbindung „redundant". Der Redundanzwert des Knotens = Anteil redundanter Nachbarverbindungen (0,0 = kritisch, 1,0 = vollständig ersetzbar).
2. Schutz kritischer Brücken: Border Nodes mit wenigen Alternativen (≤3 andere Brücken zum selben Clusterpaar) werden stark abgewertet. Bergknoten und essentielle Hügelknoten werden nie stummgeschaltet.
3. Batteriegewichtete Priorität: silence_priority = redundancy × 0.6 + (1 - battery) × 0.4. Knoten mit niedrigem Akkustand werden zuerst stummgeschaltet. Solarknoten (immer 100%) bleiben am längsten aktiv.
4. Anwendung pro Cluster: Innerhalb jedes Clusters werden die oberen 60% der Kandidaten (nach Priorität) stummgeschaltet. Mindestens 2 Knoten bleiben pro Cluster immer aktiv.

Was stummgeschaltete Knoten tun (und nicht tun)

Batteriefaire Rotation

Dieselben Knoten können nicht für immer stummgeschaltet sein — ihre Batterien würden länger halten, aber die aktiven Knoten würden schneller entladen. System 5 rotiert die stille Gruppe alle 10 Minuten:

1. Alle abgelaufenen Stummschaltungen werden aufgehoben
2. Redundanzwerte werden neu berechnet (Knoten können sich bewegt haben, ausgefallen sein oder ihre Last geändert haben)
3. Eine neue Gruppe von Knoten wird zur Stummschaltung ausgewählt, gewichtet nach aktuellem Batteriestand

Ergebnis: Jeder Knoten verbringt ungefähr gleich viel Zeit aktiv und still. Der Batterieverbrauch wird gleichmäßig über das Netzwerk verteilt.

Ergebnisse

Notfall-Umleitung — Letzter Ausweg vor Flooding

Wenn alle 5 gecachten Routen versagen (jeder Hop wurde mit Wiederholungen versucht), löste das ursprüngliche System 5 sofort begrenztes Korridor-Flooding aus. Das war teuer — im Bay Area-Szenario lösten 73 von 200 Nachrichten Fallback-Floods aus.

Die v2.0-Verbesserung fügt einen weiteren Schritt vor dem Flooding hinzu:

1. Alle Zwischenknoten der gescheiterten Routen in eine failed_nodes-Menge sammeln
2. Eine neue BFS von Quelle zu Ziel durchführen, unter Ausschluss aller gescheiterten Knoten
3. Wenn ein neuer Pfad gefunden wird, einmal versuchen (gerichtet, kein Flooding)
4. Nur wenn auch dieser Notfallpfad scheitert → Korridor-Flooding auslösen

Das ist günstig (eine BFS-Berechnung, keine zusätzlichen TX außer der Pfad funktioniert) und oft erfolgreich, weil die gescheiterten Knoten das eigentliche Problem waren — der Rest des Netzwerks hat möglicherweise einwandfreie Pfade.

Sequenznummern — Fehlende Nachrichten erkennen

Multi-Pfad-Routing kann Nachrichten in falscher Reihenfolge zustellen. Wenn Nachrichten A, B, C über drei verschiedene Pfade mit unterschiedlichen Latenzen gesendet werden, könnte der Empfänger C, B, A sehen — oder schlimmer, C, A (B auf einem gescheiterten Pfad verloren).

Das v2.0-Übertragungsprotokoll fügt einen 2-Byte-Sequenzzähler (uint16_t seq) pro (Quelle, Ziel)-Paar hinzu:

• Der Sender erhöht seq für jede Nachricht an ein bestimmtes Ziel
• Der Empfänger verfolgt die zuletzt gesehene Sequenznummer pro Quelle
• Lücken sind erkennbar: „seq 3 empfangen, dann seq 5 — seq 4 fehlt"
• Falsche Reihenfolge ist erkennbar: „seq 5 empfangen, dann seq 4 — Umsortierung"

Die Sequenzzähler werden effizient in der Firmware gespeichert: Nachbar-indiziertes Array für bekannte Nachbarn (32 Bytes) + LRU-Cache für andere (96 Bytes) = insgesamt 128 Bytes, unabhängig von der Netzwerkgröße.

Paketformat — Was über den Äther geht

Jedes System 5-Paket hat einen 22-Byte-Header:

System 5 vs. alles andere

* Next-Hop funktioniert nur für Direktnachrichten nach einem lernenden Flood. Die erste Nachricht flutet trotzdem.
** GPS erforderlich für Clustering, aber RSSI-Triangulation und Cluster-Übernahme bieten Fallbacks.