Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- meshcore:allgemeines:regions [27.01.2026 13:05] – [Regionale Konfiguration der Repeater] josch0
+++ meshcore:allgemeines:regions [27.02.2026 16:35] (aktuell) – [Funktionsprinzip] josch0
@@ Zeile 5: / Zeile 5: @@
 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.
+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 nur mal eben schnell 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__!**
+Ziel ist es, dass irgendwann möglichst alle Nachrichten mit Scope gesendet werden und der Traffic im Netz damit nachhaltig reduziert wird.
+\\
+**:!: MERKE: Sende __möglichst alle__ Nachrichten mit einem Scope. Wähle dabei eine Region nur so groß __wie unbedingt notwendig__!**
 ===== Funktionsprinzip =====
-**Regions** sind die geografischen Festlegungen, die in Repeatern eingetragen werden.
+|< 100% 50% 50% >|
+^ Ohne Region/Scope ^ Mit Region/Scope ^
+| {{ :meshcore:allgemeines:regions:folie1.jpg }} | {{ :meshcore:allgemeines:regions:folie2.jpg }} |
+| **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. (Es sei denn, es ist "denyf *" aktiviert.) \\ 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. ||
-Ein **Scope** ist der geografische Reichweitenwunsch, den der Anwender einer Message zufügt.
+===== Regions definieren und Scopes nutzen =====
-Ein Repeater leitet eine Message weiter, wenn ihr beigefügter Scope in seiner Region-Liste zu finden ist.
+  * Was sind [[meshcore:allgemeines:regions:basis|Basis-Regions]]?
+  * Wie definiert man eigene [[meshcore:allgemeines:regions:definieren|Regionale Regions]]?
+  * Welche Regionalen Regions [[meshcore:allgemeines:regions:reale-regions-in-repeatern|gibt es schon]]?
+  * Wie konfiguriert man Regions in den [[meshcore:allgemeines:regions:cli|Repeatern]]?
+  * Wie [[meshcore:allgemeines:regions:scopes-nutzen|nutzt man Scopes]] bei Nachrichten?
-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.
+===== Diskussion zum Thema =====
-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.)
+In der Telegram-Gruppe [[https://t.me/meshcorede|MeshCore DE]] wurde das Thema Regions/Scopes sehr ausführlich diskutiert. An der Diskussion teilgenommen haben eine Vielzahl MeshCore-Nutzer mit unterschiedlichem Background, sowie Vertreter regionaler Communities. Diskutiert wurden inhaltlich sehr umfangreich dutzende Ideen zum Schnitt und zur Struktur von Regions, Vorteile und Nachteile diverser Sichtweisen, Bedenken etc. Es wurde viel Zeit investiert, manchmal sehr emotional diskutiert, aber gemeinschaftlich ein Ergebnis erarbeitet.
-**Für Regions (und damit auch Scopes) gelten folgende Einschränkungen: **
+Der Konsens aus dieser Diskussion wurde hier im Wiki festgehalten und wurde von einigen Communities auch schon in die Umsetzung gebracht. Es ist natürlich nicht auszuschließen, dass sich dieser Konsens durch neue Features und praktische Erfahrungen nochmal ändern wird. Auch kann es natürlich neue Ideen geben, die man in großer Runde nochmal diskutieren muss. Um sich an der Diskussion zu beteiligen, bitte folgende "Nettiquette" beachten:
-  * Länge maximum 30 bytes (UTF-8).
+  * Fragt gerne erstmal nach, ob Idee XY schon bedacht wurde und wie der Konsens dazu aussieht
-  * Nur Kleinbuchstaben, # (Hash), $ (Dollar) - (Bindestrich)
+  * Bringt gerne Ideen sachlich ein und lasst euch auf eine sachliche und auf Argumenten basierte Diskussion ein
-  * Regions müssen im Netz eindeutig sein.
+  * Akzeptiert, wenn die Mehrheit in der Diskussion anderer Meinung ist
-  * 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.
+  * "ICH will aber" und "ICH finde das ist ne gute Idee" helfen nicht weiter
-  * 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.
+  * Seid nett zueinander
-** Weitere Details und gute Anleitungen findet man hier **
-  * [[https://buymeacoffee.com/ripplebiz/region-filtering|Ripple Blog - Region Filtering]]
-  * [[https://www.youtube.com/watch?v=VlaebfwWUBA|YouTube-Video mit Erklärung/Vorstellung]]
-  * [[meshcore:allgemeines:regions:cli|Übersicht der CLI Befehle]]
-===== Status der Umsetzung =====
-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.
-===== Diskussion =====
-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".
-==== Fazit aus der bisherigen Diskussion ====
-  * Es wird nicht "das eine Schema" geben, was jeder versteht und alle Wünsche/Anforderungen auch regionaler Interessen erfüllt.
-===== Struktur/Schema der Region-Einträge =====
-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.
-==== Basis-Konfiguration der Repeater ====
-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:
-| #de | Deutschland |
-| #de-bw | Baden-Württemberg |
-| #de-by | Bayern |
-| #de-be | Berlin |
-| #de-bb | Brandenburg |
-| #de-hb | Bremen |
-| #de-hh | Hamburg |
-| #de-he | Hessen |
-| #de-mv | Mecklenburg-Vorpommern |
-| #de-ni | Niedersachen |
-| #de-nw | Nordrhein-Westfalen |
-| #de-rp | Rheinland-Pfalz |
-| #de-sl | Saarland |
-| #de-sn | Sachsen |
-| #de-st | Sachen-Anhalt |
-| #de-sh | Schleswig-Holstein |
-| #de-th | Thüringen |
-==== Regionale Konfiguration der Repeater ====
-**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 zusammenfassen, 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:
-| #region-hannover | Region Hannover |
-| #rhein-main | Rhein-Main-Gebiet |
-| #taunus | Landschaft Taunus |
-==== Beispiel ====
-Ein Repeater in Rüdesheim am Rhein (Nahe der Grenze HE/RP) könnte folgende Regionen haben:
-<code>
-#de
-#de-he
-#de-rp
-#taunus
-#rhein-main
-</code>
-==== Reale Regions-Umsetzungen ====
-Auf einer [[meshcore:allgemeines:regions:Reale-Regions-in-Repeatern|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 [[https://umap.openstreetmap.de/de/map/anonymous-edit/122026:q5Zzdc4m5CMARPVFTeGo6OiZWFDMmqiARlvOv7FBIBs|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.
+Wir erreichen das gemeinsame Ziel "stabiles Netz" nur, wenn wir alle an einem Strang ziehen und getroffene Entscheidungen auch von allen Repeater-Admins und Nutzern respektiert und umgesetzt werden. Natürlich ist niemand gezwungen sich an die Entscheidungen zu halten, aber das Netz wird nicht funktionieren, wenn jeder egoistisch seine eigenen Wünsche durchsetzen möchte. Das ist Fakt.

MeshCore Wiki DE

Benutzer-Werkzeuge

Webseiten-Werkzeuge

Unterschiede

Seiten-Werkzeuge