Datenstau im Blackout: Warum lokale „Scopes“ bei MeshCore über die krisensichere Kommunikation entscheiden
Stellen Sie sich vor: Es ist ein eiskalter Samstagmorgen im Januar. Plötzlich erlischt das Licht. Die Heizung schaltet sich ab, der Kühlschrank verstummt, das Festnetz bricht zusammen. Und nur wenig später verabschiedet sich das Mobilfunknetz, weil die Pufferbatterien der Sendemasten leerlaufen. Ein großflächiger Blackout ist Realität geworden.
Genau das passierte am 3. Januar 2026 im Berliner Südwesten (Zehlendorf, Lichterfelde, Wannsee und Nikolassee) für bis zu viereinhalb Tage und im Februar 2019 im Bezirk Köpenick für über 31 Stunden.
In solchen Momenten schlägt die Stunde von dezentralen Funknetzen wie MeshCore. Während die kommerzielle Infrastruktur schweigt, bauen Repeater-Betreiber und engagierte Bürger ein autarkes, lokales Kommunikationsnetz auf.
Doch ein funktionierendes Mesh-Netzwerk ist kein Selbstläufer. Ohne die richtige Struktur droht dem digitalen Rettungsanker im Ernstfall der schnelle Kollaps durch Datenüberlastung. Der Schlüssel zur Rettung heißt: Geografische Scopes.
Das Problem der Großstadt: Wenn das Netz im eigenen Erfolg ertrinkt
MeshCore basiert auf einem dezentralen Routing-Prinzip. Feste, strategisch platzierte Repeater leiten Datenpakete weiter, während mobile Endgeräte (Companions) Nachrichten senden und empfangen.
In einer dünn besiedelten Region funktioniert das hervorragend. In einer Metropole wie Berlin stoßen „flache“, unstrukturierte Funknetze jedoch schnell an ihre physikalischen Grenzen. Das liegt an der Natur der genutzten LoRa-Technologie (meist auf dem lizenzfreien 868-MHz-Band).
Wenn in einem Bezirk wie Steglitz-Zehlendorf der Strom ausfällt, passiert Folgendes:
- Einige Dutzend bis wenige hundert Bürger aktivieren ihre Mesh-Geräte, um Informationen zu erhalten.
- Es entsteht ein akutes, plötzliches Aufkommen an Nachrichten: Fragen nach der Ursache, der voraussichtlichen Dauer, der Erreichbarkeit von Apotheken oder dem Zustand von Angehörigen. Wo sonst kaum Traffic herrscht, werden nun in kurzer Zeit hunderte Nachrichten abgesetzt.
- Ohne Begrenzung versucht nun jeder Repeater im System, jede dieser Nachrichten an alle erreichbaren Nachbarknoten weiterzuleiten – vom dicht bebauten Steglitz über das grünere Zehlendorf bis nach Spandau, Pankow, Neukölln und weit hinein ins Brandenburger Umland.
Die Folge ist ein sogenannter Broadcast-Storm (Datensturm). Die physikalischen Grenzen des Netzes sind hier gnadenlos.
Die Physik dahinter: Warum schon 100 Nutzer das Netz lahmlegen können
Ein weit verbreiteter Irrglaube ist, dass erst tausende Nutzer ein Netz überlasten. Bei LoRa-basiertem Mesh-Funk reichen dafür schon weit geringere Zahlen. Das hat zwei physikalische Gründe:
1. Die Sendezeit (Airtime) und Paketkollisionen
Eine einzige LoRa-Nachricht benötigt je nach Spreizfaktor (Spreading Factor) und Paketgröße zwischen 100 und 500 Millisekunden Sendezeit. Während dieser Zeit ist der Kanal für alle anderen blockiert. Senden nur 50 Nutzer gleichzeitig im selben Einzugsgebiet, steigt die Wahrscheinlichkeit von Paketkollisionen (wenn zwei Nodes gleichzeitig senden) dramatisch an. Nachrichten löschen sich gegenseitig aus und müssen neu gesendet werden – eine Abwärtsspirale beginnt.
2. Die gesetzliche Sendezeitbegrenzung (Duty Cycle)
Im 868-MHz-Band gilt in Europa eine gesetzliche Sendezeitbegrenzung (Duty Cycle) von meist 1 %. Das bedeutet: Ein Repeater darf pro Stunde insgesamt nur 36 Sekunden lang senden. Wenn ein zentraler Repeater jede lokale Nachricht aus Zehlendorf ungefiltert an die gesamte Stadt weiterleiten muss, hat er sein Sendezeitbudget nach nur wenigen Dutzend retransmittierten Nachrichten für diese Stunde komplett aufgebraucht und muss gesetzlich bedingt abschalten. Das Netz bricht genau dann zusammen, wenn es am dringendsten gebraucht wird.
Die Lösung: Geografische Datenhygiene durch „Scopes“
Um dieses Szenario zu verhindern, nutzt MeshCore ein hierarchisches Routing-Modell, das auf geografischen Scopes(Gültigkeitsbereichen) basiert. Ein Scope definiert, wie weit eine Nachricht transportiert werden darf, bevor ein Repeater sie ignoriert.
In der Praxis sieht diese Hierarchie für unsere Region wie folgt aus:
de: Bundesweite oder überregionale Backbone-Ebene (nur für absolut kritische, globale Systemdaten).de-bebb: Metropolregion Berlin-Brandenburg.de-be: Das gesamte Stadtgebiet von Berlin.de-be-sw: Spezifisch der Südwesten Berlins (Zehlendorf, Steglitz, Dahlem, Wannsee).
Durch diese Strukturierung bleibt der Traffic dort, wo er hingehört. Wenn in Steglitz-Zehlendorf der Strom ausfällt, müssen die Lageberichte aus Wannsee nicht in Marzahn oder Potsdam empfangen werden. Sie verbleiben im Scope de-be-sw. Das entlastet das gesamte restliche Berliner Netz und sichert die maximale, physikalisch verfügbare Bandbreite im eigentlichen Schadensgebiet.
Warum Vorbereitung alles ist: Regeln definieren, bevor das Licht ausgeht
Im Moment einer Krise ist es zu spät für Konfigurationen. Wenn der Strom weg ist, gibt es kein Internet mehr, um Anleitungen zu lesen, Firmware-Updates einzuspielen oder Routing-Tabellen abzugleichen. Jeder Repeater muss vorhergenau wissen, wie er mit lokalen Scopes umzugehen hat.
Das erfordert zwei wesentliche Säulen:
1. Predefined Rules (Vorab-Definitionen) für Betreiber
Als Repeater-Betreiber trägst du die Verantwortung für die Infrastruktur. Es reicht nicht, einfach nur mit maximaler Sendeleistung alles weiterzuleiten, was empfangen wird („Dumb Repeating“). Ein gut konfigurierter Repeater muss so eingestellt sein, dass er lokale Scopes wie de-be-sw sauber isoliert und filtert. Er muss lokalen Chat-Traffic auf die dafür vorgesehenen geografischen Grenzen beschränken, um die überregionalen Kanäle freizuhalten.
2. Der „T-Day“: Warum regelmäßige Stresstests Leben retten
Ein Netz, das nie unter Last getestet wurde, wird im Ernstfall versagen. Genau hier kommt der T-Day ins Spiel. An diesen regelmäßigen Aktionstagen simulieren Betreiber und Nutzer gezielt ein erhöhtes Nachrichtenaufkommen. Es ist die perfekte Gelegenheit, um:
- Die tatsächliche Reichweite lokaler Scopes (wie
de-be-swauf dem kanal#berlin-sw) unter realistischen Bedingungen zu vermessen. - Die Auslastung des Frequenzbandes bei einem simulierten Aufkommen von beispielsweise 100 Testnachrichten pro Stunde zu analysieren.
- Fehlkonfigurationen an Repeatern aufzudecken, die fälschlicherweise lokalen Traffic „lecken“ lassen und so Nachbarbezirke belasten.
Fazit: Verantwortung auf beiden Seiten
Krisenvorsorge im Mesh-Netz ist Teamarbeit zwischen Infrastruktur-Betreibern und Endanwendern.
- An die Repeater-Betreiber: Konfiguriert eure Nodes diszipliniert. Nutzt die Scopes gezielt und beteiligt euch an den regelmäßigen T-Days, um eure Filterregeln zu überprüfen. Eure Konfiguration entscheidet darüber, ob das Netz im Ernstfall 10 oder 100 Nutzer gleichzeitig verkraftet.
- An die Anwender (Companions): Macht euch schon heute mit der Kanalstruktur vertraut. Wenn der Ernstfall eintritt, wechselt gezielt auf den lokalen Kanal
#berlin-swim Scopede-be-sw. Haltet eure Nachrichten kurz und präzise.
Nur durch gemeinsame Funkdisziplin und sauber konfigurierte Filter schaffen wir ein Netz, das auch dann noch steht, wenn alles andere dunkel bleibt.
Hast du deinen Companion oder Repeater schon für den nächsten T-Day vorbereitet? Diskutiere mit uns im netzweiten Kanal #t-day oder teile deine Erfahrungen in den Kommentaren!
Siehe auch:
T-Day HQ – Zehlendorf – MeshCore Repeater in Zehlendorf (Autark – Solarbetrieben)