MeshCore Learning

Understanding Regions and Region Scopes

As a MeshCore network grows, flooded messages can travel farther than intended. A neighborhood announcement, a local weather report, or a casual chat can end up occupying airtime across a much larger area. Regions and region scopes give operators and users a way to keep traffic appropriately local.

What Is a Region?

A region is a named label that repeater operators configure on their infrastructure. Common examples include a metro area (sea), a state or province (us-wa or wa), or a broader area (pnw).

Each repeater can belong to multiple regions. A repeater in the western part of a city might carry both the city-wide region and a smaller west-side region. A repeater on the boundary between two areas can carry both. This lets operators create flexible coverage without forcing every message to travel the entire mesh.

What Is a Scope?

A scope is the region label a user (or the app) attaches to a message they send. When you set a scope on a channel, the messages you send on that channel are tagged with that region.

  • Repeaters that have the matching region configured will forward the message.
  • Repeaters that do not have that region will not forward it.
  • You can still receive messages from any region; the scope only affects what you send.

Scopes are saved per channel, so you can keep a local public channel scoped tightly while leaving another channel more open.

Visual Example of Nested Regions

This illustration shows a hierarchical naming style over a landscape. The largest area is labeled us, containing us-pa, which contains us-pa-johnstown, which is further divided into us-pa-johnstown-west and us-pa-johnstown-east. Towers represent repeaters located within (or near the boundaries of) these areas.

Hierarchical region naming example over a landscape with nested areas and repeater towers
A hierarchical naming style (us → us-pa → us-pa-johnstown → local areas) makes the intended geographic scope of each region name easier for people to understand. The protocol itself treats every name as a flat string.

Is the Hierarchy Required?

No. The hierarchy is only for human organization and clarity. It is not required or enforced by MeshCore.

MeshCore region filtering works by exact name matching, not by parent/child relationships:

  • A repeater only forwards a scoped packet if the exact region name on the packet appears in that repeater’s configured region list.
  • There is no automatic inheritance. Configuring a repeater with us-pa does not automatically make it forward packets scoped to us-pa-johnstown or us-pa-johnstown-west.
  • Each region name you want a repeater to handle must be explicitly added (via region put and region allowf).

The hierarchical naming style (us → us-pa → us-pa-johnstown → us-pa-johnstown-west) is simply a convention that makes it easier for people to understand the intended geographic scope of a name. It helps operators and users agree on consistent, readable labels. The protocol itself treats every region name as a flat, unique string.

Practical implication for repeater operators: If you want a repeater to participate in both a broad region and a more specific one, you must add both names to its configuration. Boundary or multi-area repeaters are commonly configured with several explicit region names for this reason.

How This Helps in Practice

  • Reduces unnecessary traffic — Messages stay within the area that needs them, leaving more airtime available for other traffic.
  • Supports different needs — A local channel can stay local while an emergency or wider announcement uses a larger region.
  • Works with hierarchy — Operators can nest regions (city inside state inside broader area) so users can choose the appropriate size for each message.
  • Complements other controls — Regions work alongside hop limits and other traffic management tools.
Main repeaters configured with a broad region and clustered low-profile repeaters limited to a tighter local region
Main repeaters carry a broader region (such as us-pa) and can forward traffic across a larger area. Nearby low-profile repeaters are limited to a tighter local region (such as westside) so they do not rebroadcast unscoped or widely scoped flood messages. This reduces unnecessary airtime while still serving local users.

Getting Started

  1. Check with your local mesh community for the region names already in use. Consistent naming matters; a small difference creates a completely separate region.
  2. In the companion app, use the Discover / Scan feature (when available) or add the relevant region names manually.
  3. On a channel in the companion app, open the menu and choose Set Region Scope (or equivalent). Select the region that matches the intended reach of that channel.
  4. You can change or remove the scope at any time.

Repeater operators can configure regions through the repeater command line (region put, region allowf, region save, and related commands) or through the regions management section available in the repeater’s over-the-air (OTA) settings. Once repeaters in an area are configured, users can begin scoping their messages.

Command-Line Example

Below is a typical sequence for adding a country → state → local hierarchy. The parent region is listed after the child. On many current firmware versions an explicit region allowf is still used (or shown for clarity). Always finish with region save.

> region put us
OK
> region put us-pa us
OK
> region put sce us-pa
OK
> region allowf us
OK
> region allowf us-pa
OK
> region allowf sce
OK
> region save
OK
> region
*^ F
us F
us-pa F
sce F

After saving, the region command confirms the list and shows the F flag next to each region that is allowed to forward flood traffic. The same regions can also be managed in the repeater’s OTA settings.