Damit das MeshCore-Netz langfristig zuverlässig funktioniert, müssen wir gemeinsam ein Auge darauf haben die Menge der übermittelten Datenpakete „OnAir“ so gering wie möglich zu halten. Je mehr Traffic herrscht, desto eher kommt es zu Paket-Kollisionen und zu überforderten Repeatern. Die Folge davon sind verlorene Datenpakete und damit unzuverlässige Kommunikation. Besonders die „Flood-Pakete“ (Nachrichten in Channels und Repeater-Adverts) stehen hier im Fokus.

Standardmäßig werden Flood-Pakete in MeshCore von den Repeatern über 64 Hops weitergeleitet. Die Erfahrung zeigt, dass man bereits mit unter 20 Hops mehrere hundert Kilometer Entfernung zurücklegen kann. Das ist oftmals gar nicht notwendig, wenn man mit seiner regionalen Community kommunizieren möchte.

Hier kommen Regions ins Spiel: Mit Regions lassen sich geografische Bereiche definieren, in deren Grenzen die Repeater die Nachrichten weiterleiten. Unabhängig der Anzahl der Hops. Damit lässt sich ein „unkontrolliertes“ Flooding der Nachrichten sinnvoll begrenzen und das Netz entlasten.

MERKE: Sende so viele Nachrichten wie möglich mit einem Scope. Wähle dabei eine Region nur so groß wie unbedingt notwendig!

Regions sind die geografischen Festlegungen, die in Repeatern eingetragen werden.

Ein Scope ist der geografische Reichweitenwunsch, den der Anwender einer Message zufügt.

Ein Repeater leitet eine Message weiter, wenn ihr beigefügter Scope in seiner Region-Liste zu finden ist.

Auf jedem Repeater ist standardmäßig die Wildcard-Region * (Stern) hinterlegt und aktiviert. Diese sorgt dafür, dass Pakete OHNE Scope auf jeden Fall weitergeleitet werden.

Das Matching des Scopes auf die Region geschieht über einen 1:1 Vergleich eines vom Namen der Region abgeleiteten Keys. Es findet kein „String-Matching“ statt und auch kein Teilstring-Matching. (Scope #de-he ist NICHT in Region #de enthalten.)

Für Regions (und damit auch Scopes) gelten folgende Einschränkungen:

• Länge maximum 30 bytes (UTF-8).
• Nur Kleinbuchstaben, # (Hash), $ (Dollar) - (Bindestrich)
• Regions müssen im Netz eindeutig sein.
• Regions und Scopes matchen nur exakt (1:1), es gibt kein „Teilmatch“ anhand des Namens. Hierarchische Strukturen müssen über jeweils eigene Regions abgebildet werden.
• Die Anzahl der Regions auf dem Repeater ist auf 32 begrenzt, ABER: Beim Auto-Discover der Regions können nur 172 Zeichen übertragen werden. Alles Weitere wird abgeschnitten. Es ist daher sehr zu empfehlen, die Anzahl der Regions und deren Namen so klein wie möglich zu halten. Die abgeschnittenen Regions sind im Repeater trotzdem aktiv. Wenn der Nutzer diese kennt, kann er sie trotzdem nutzen. Sie werden lediglich nicht im Auto-Discover angezeigt.

Weitere Details und gute Anleitungen findet man hier

• Ripple Blog - Region Filtering
• YouTube-Video mit Erklärung/Vorstellung
• Übersicht der CLI Befehle

Mit Version 1.10.0 sind Regions/Scopes in der Firmware enthalten (sowohl Repeater, als auch Companions).

WICHTIG: Repeater mit Firmware älter als 1.10.0 leiten alle Pakete weiter, unabhängig ob diese einen Scope gesetzt haben oder nicht. Dementsprechend müssen diese Repeater aktualisiert werden damit die Verwendung von Scopes/Regions sinnvoll funktioniert.

Mit App-Version 1.38.0 können in den Channels nun auch Scopes angegeben werden.

Zukünftig (vermutlich Firmware 1.12.0):

• Die Repeater unterstützen ein Auto-Discover der Regions. Die App sendet dazu ein Request per ZeroHop an die Repeater im Umkreis, die dann mit ihrer Region-Liste antworten. So kann der Nutzer in der App komfortabel einen passenden Scope auswählen. (siehe Blog)
• Es wird wohl neben den „HashTag-Regions“ mit abgeleitetem Key auch private Regions (beginnend mit $) geben. Der genaue Zweck und die Nutzung ist noch unklar, hier warten wir auf ein Update im Blog.
• Die „Hashtag-Regions“ müssen nicht mehr mit einem # beginnen. Alle Regions ohne $ werden automatisch intern als Hashtag-Regions behandelt.

Die Diskussion in der deutschen Telegram-Gruppe (Link hier einfügen) brachte einige wiederkehrende Erkenntnisse zu Tage:

• Eine zu feingranulare Aufteilung der Regions (runter zu Stadt/Ortsteil) macht keinen Sinn, weil
  • … zum Weiterleiten der Nachrichten dann auch entsprechende Repeater mit genau diesen Regions (z.B. im Ortsteil) vorhanden sein müssen
  • … die Konfiguration der Repeater exorbitanten Aufwand erzeugen würde, den JEDER Repeater-Betreiber tun müsste

• Eine Nutzung vorhandener geografischer Klassifizierungen ist sinnvoll, die Auswahl der passenden und einzig Richtigen aber schwierig. Besprochen wurden:
  • PLZ → Kann sich jeder was drunter vorstellen. Alle 5 Stellen sind zu feingranular, eine Beschränkung auf die ersten beiden Stellen als „Zone“ wäre ausreichend. Es gibt aber auch Städte, die in mehreren Zonen liegen. Es ist schwer abzuschätzen, welche Reichweite die Zone z.B. „84“ hat.
  • ISO → Geht nur bis Bundesland. Ein einheitlicher Code für Landkreise gibt es nicht.
  • Landkreis → Es gibt kein einheitliches Namensschema für Landkreise. Zudem ist fraglich, ob es Sinnvoll ist, pauschal alle Landkreise in Deutschland als eigene Region zu definieren.
  • KFZ-Kennzeichen → Da es inzwischen pro LK mehrere mögliche Kennzeichen gibt, gibt es hier keine Eindeutigkeit.
  • IATA-Code → Zu grob und zu ungleichmäßig über DE verteilt. Kennt außerdem kaum jemand.
  • EBU-Code → Sehr unbekannt.
  • Locator → Eher nur bei den Funkamateuren gebräuchlich. Lässt sich schwer abschätzen, welche Reichweite der Locator z.B. „JO40“ hat.
  • AGS (Gemeindeschlüssel) → Eher unbekannt

• Regionen mit lokaler Bedeutung lassen sich über diese Schemata meist nicht abbilden. Z.B. „Region Hannover“ oder „Rhein-Main“.

• Es wird nicht „das eine Schema“ geben, was jeder versteht und alle Wünsche/Anforderungen auch regionaler Interessen erfüllt.

Folgender Vorschlag wurde mehrfach in der Diskussion angebracht und mehrheitlich für gut befunden.

WICHTIG: Mit Firmware ⇐ 1.11.0 und App 1.38.0 ist der Hashtag # vor dem Namen zwingend erforderlich. Mit der kommenden Firmware/App wird diese Einschränkung aufgehoben. Diese Wiki-Seite geht erstmal davon aus, dass der Hashtag weiterhin genutzt wird. Ob wir nach Veröffentlichung der neuen Firmware den Hashtag generell aus den Namen entfernen muss noch abgestimmt werden.

Um eine grundlegende geografische Eingrenzung des Flood-Verhaltens zu erreichen, werden die Ebenen „Land“ und „Bundesland“ in jedem Repeater als Regions konfiguriert. Das Namensschema folgt der ISO 3166-2. Wenn jeder Repeater in Deutschland diese Basis-Regionen konfiguriert hat, können die Nutzer einigermaßen sicher und nach immer gleichem Schema ihre Nachrichten zumindest auf Deutschland und das jeweilige Bundesland einschränken. Alleine das würde Flood-Nachrichten nachhaltig verringern.

Die Regions würden gemäß ISO folgendermaßen lauten:

Zusätzlich zur Basis-Konfiguration können regional weitere Regions erstellt werden. Das Namensschema und die Information an die Repeater-Betreiber unterliegt dann den regionalen Communities. Sinnvoll ist es hier, sprechende und eindeutige Namen zu nutzen, die jeder Nutzer sofort versteht.

Bei der Definition von regionalen Regions gilt zu beachten, dass diese möglichst eine Menge Menschen zusammenfasst, die ein gemeinsames Interesse daran haben miteinander zu kommunizieren. Landschaften (z.B. #westerwald) oder Metropolregionen/Ballungsgebiete (z.B. #region-stuttgart) bieten sich hier an, da diese oftmals eine gemeinsame Kultur und starke Identifikationswirkung haben. Weniger geeignet sind starre Verwaltungsgrenzen wie z.B. Landkreise.

Ebenso gilt zu beachten, dass „zu kleine“ Regions kontraproduktiv sind. Zum Einen ist die Gefahr groß, dass die Menschen die man erreichen will genau kurz hinter der Region sitzen, zum Anderen braucht es passende Repeater in dieser Region, die die Nachrichten auch weiterleiten. Zudem wächst der Konfigurationsaufwand für alle Repeater-Betreiber mit jeder zusätzlichen Region. Es darf nicht unterschätzt werden, dass es eine organisatorisch herausfordernde Aufgabe ist, alle Repeater in einer Region richtig zu konfigurieren.

Möglich wären dann z.B. folgende Regions:

Ein Repeater in Rüdesheim am Rhein (Nahe der Grenze HE/RP) könnte folgende Regionen haben:

#de
#de-he
#de-rp
#taunus
#rhein-main

Auf einer eigenen Seite sind reale Region-Einstellungen von Repeatern zu finden. Dies soll ein Nachschlagewerk für User in den betreffenden Regionen werden.

Zusätzlich gibt es die Regions Karte Deutschland, auf der man alle bekannten regionalen Regionen auf der Karte nachvollziehen kann. Somit sieht der Repeater-Admin auf einen Blick, welche Regions er an seinem Standort konfigurieren muss.