MeshCore/Regions

---

NOTE - A Regional Framework was implemented in the ScotMesh MeshCore Mesh at the beginning of April 2026. This was out of sheer necessity as our mesh was dying under the flood traffic from England (24,000 flood packets & 600+ messages daily). This saved our mesh from descending into a chaotic, unusable mess of incoherent rambles and frustrated messaging failures. This is why an understanding of regions is imperative to understanding where we are today.

---

This guide is for repeater owners.

The aim is simple: keep the scheme readable, predictable, and usable as the network grows.

Why regions are needed

MeshCore messages travel through repeaters for onward routing. Whilst this is the core function, if every repeater carries every message everywhere, the network becomes noisy, inefficient and flooded with unnecessary traffic.

Regions help us:

1. Keep local traffic local — In the future, a message that only matters in one area won't always need to be repeated across every part of Scotland.
2. Reduce unnecessary radio traffic — LoRa is subject to a finite airtime cycle per hour (compared with Wi-Fi or mobile data), so every avoidable repeat uses valuable airtime.
3. Improve reliability — Less unnecessary repeating leaves more room for useful messages.
4. Make planning clearer — Regions make repeater deployment easier to map, identify needs, plan future expansion and ease of ongoing mesh maintenance.
5. Support controlled peering — Strategic repeaters can deliberately carry neighbouring traffic, such as the IOI peering agreement between Scotland and the Island of Ireland.

Regions and scopes

There are two related concepts: regions and scopes.

Term	Meaning	Example
Region	A label configured on a repeater to describe the area it serves.	An Edinburgh-area repeater includes edi.
Scope	A label applied to messages or channels to describe which area (or region) the traffic is intended to travel.	The #glasgow channel might use gla when traffic should stay in that area.

In a densely populated mesh, a repeater should only carry scoped traffic for regions it genuinely serves. In new or embryonic meshes, this requirement will be a future need but best practise planning mandates introducing regions as early as is practical.

Wildcard forwarding is not allowed (see info box at top of this document for context).

The wildcard marker is:

*

The important rule is: * will appear as a root parent in the region tree, but wildcard forwarding must be denied.

In other words, region put sco * is correct, but must be preceded by region denyf * .

The Scottish MeshCore setup does not allow wildcard forwarding. Repeater owners must deny wildcard forwarding with:

region denyf *

You may still see * as the root parent when defining the region tree, for example region put sco *. That is different from allowing wildcard forwarding.

For channel names and suggested scopes, see Channels.

Scottish region code approach

For Scotland, we use simple three-letter lowercase codes.

We are not part of any UK wide mesh (for context see comment box at the top of this document) Therefore, we are not using any long prefixed names

We use short codes such as:

sco
cen
fal

Other countries and communities may use ISO-style hierarchical codes. That is valid for them, but the Scottish convention is designed to be short and easy to read in apps, analyser tools, and community discussions.

Agreed region codes

Code	Area
sco	Scotland — the default scope, carried by every Scottish repeater
sco-admin	Scotland-only, for bots and utilities. Never peered out.
cen	Central Scotland
edi	Edinburgh area
gla	Glasgow area
fal	Falkirk area
sti	Stirling area (proposed)
fif	Fife
tay	Tayside
dun	Dundee area
per	Perth area
hig	Highlands (Inverness area)
ioi	Island of Ireland — peering root beside sco
wls	Wales — peering root beside sco
eng-ne	North East England — peering root beside sco

IOI peering agreement

The Scottish and Irish MeshCore communities maintain a peering agreement: scoped traffic is carried on the other network only where both sides configure for it.

Under that agreement, Scottish repeaters add the ioi region alongside sco where the Scottish baseline applies, and Island of Ireland repeaters add sco alongside their own region codes in the same spirit. Messages with matching scopes can then move between the two networks predictably, without relying on wildcard forwarding. For example channel names and typical scopes, see Channels.

The ioi code is not a Scottish local region. It marks repeaters and traffic that deliberately participate in that peering.

Do not use:

ioi-sco

Use:

ioi

Peering with Scotland (other regions)

If another region wants to peer with Scotland in a similar way, they should already have the following in place:

1. Wildcard flooding disallowed on their repeaters (the same principle as the Scottish setup: deny wildcard forwarding with region denyf *; see Wildcard forwarding is not allowed).
2. Appropriate regions on their repeaters so traffic is not forwarded wider than intended, and Scottish repeaters are not flooded with scoped traffic they did not agree to carry.
3. Neighbouring Scotland in RF terms so equipment can directly peer, rather than assuming long unofficial relay chains.

When that fits your situation, contact the Scottish Mesh community on Discord so we can discuss scope names, boundaries, and a safe rollout.

Recommended hierarchy

Although the hierarchy is not written into the code itself, it can be thought of like this:

sco
  cen
    edi
    gla
    fal
    sti   (proposed)
  fif
  tay
    dun
    per
  hig
sco-admin
ioi
wls
eng-ne

In plain English:

• sco is for Scotland-wide traffic, and sco-admin is a Scotland-only root for bots and utilities.
• cen, tay, fif and hig are Scottish sub regions.
• edi, gla, fal, sti, dun and per are local areas.
• ioi (Island of Ireland), wls (Wales) and eng-ne (North East England) are peering roots beside sco.

Suggested repeater configuration policy

A Scottish repeater should normally be configured with:

1. The country code sco, and sco-admin for Scotland-only utility traffic.
2. The peering roots ioi, wls and eng-ne.
3. The relevant regional code.
4. The relevant local code, if appropriate.
5. Any neighbouring codes that the repeater genuinely serves.

Do not allow wildcard forwarding.

In command line interface (CLI) examples, this means using region denyf *

Falkirk / Central Scotland repeater

A repeater covering the Falkirk area would usually have:

sco
cen
fal
sco-admin
ioi
wls
eng-ne

Edinburgh-facing Central Scotland repeater

A repeater that mainly serves Central Scotland but has strong coverage towards Edinburgh might use:

sco
cen
edi
sco-admin
ioi
wls
eng-ne

Fife repeater

A Fife repeater would usually have:

sco
fif
sco-admin
ioi
wls
eng-ne

If it genuinely provides useful Central Scotland coverage, it may also include:

cen

Scottish repeaters and ioi

Scottish repeaters carry the peering roots ioi, wls and eng-ne alongside sco and sco-admin — these are included in every repeater script:

sco
sco-admin
ioi
wls
eng-ne

That keeps peering-capable forwarding available where the Scottish baseline is configured. It does not make ioi a Scottish local region.

Good practice for repeater owners

Use lowercase region codes. Do not use mixed case such as SCO, Cen, or FAL.

Use agreed codes. For example, use edi for the Edinburgh area, not edn, edinburgh, or gb-edi.

Add only the areas your repeater genuinely serves. A high-site repeater may reasonably serve several areas, but a repeater should not claim every region just because it can occasionally hear distant nodes.

Coordinate before adding new codes. If a new area needs a code, discuss it publicly before using it so that the community does not end up with competing names for the same place.

Suggested command examples

The exact method may vary depending on firmware version and whether you are using the app, web configurator, USB serial, or remote administration. The upstream reference is the MeshCore CLI Commands documentation, especially the region management commands.

New to repeater setup?

Start with Repeater Quick Setup, then come back here for the fuller detail.

On current firmware (1.16+) the whole region tree goes in one region def line, followed by region denyf * and the standard set commands. The easiest way to get the exact script for your area is the ScotMesh repeater builder; the examples below show what it produces.

For a Central Scotland / Falkirk repeater:

region def sco cen fal|* sco-admin|* ioi|* wls|* eng-ne
region denyf *
set flood.advert.interval 24
set multi.acks 1
set path.hash.mode 2
region default sco
region save

Then check the result with:

region

For a Tayside / Dundee repeater:

region def sco tay dun|* sco-admin|* ioi|* wls|* eng-ne
region denyf *
set flood.advert.interval 24
set multi.acks 1
set path.hash.mode 2
region default sco
region save

For a Glasgow-area repeater:

region def sco cen gla|* sco-admin|* ioi|* wls|* eng-ne
region denyf *
set flood.advert.interval 24
set multi.acks 1
set path.hash.mode 2
region default sco
region save

For a repeater that serves Scotland, Central Scotland, Glasgow, Edinburgh, and IOI peering (ioi):

region def sco cen|* gla|cen edi|cen sco-admin|* ioi|* wls|* eng-ne
region denyf *
set flood.advert.interval 24
set multi.acks 1
set path.hash.mode 2
region default sco
region save

Set region default sco on your repeater.

Without a default scope, adverts sent by your repeater go out unscoped. Because the Scottish network uses region denyf *, other repeaters will reject those unscoped adverts and will never learn your repeater exists. Setting the default scope to sco ensures your adverts are carried normally across the mesh.

This is separate from flood forwarding permissions. For more detail, see Default Scope Region.

Always check for an OK response where applicable, and remember to save the configuration so it survives a reboot.

Firmware and app version notes

Region and scope support depends on MeshCore firmware and app support.

Use the latest stable MeshCore firmware and app available for your device. Older firmware may still pass some traffic, but region management and scope handling may not behave as expected.

MeshCore region filtering was introduced across firmware and app releases, and default scope support was added later. The MeshCore posts Region Filtering and Default Scope Region are useful background when checking version behaviour.

Naming and publishing new region codes

When a new Scottish area needs a code, use these rules:

1. Use three lowercase letters.
2. Make the code obvious to local users.
3. Avoid clashing with existing agreed codes.
4. Avoid overly small areas unless there is a real need.
5. Discuss the code with the local MeshCore community before publishing it.

Examples of possible future codes might include:

sti = Stirling
liv = Livingston
abe = Aberdeen
inv = Inverness
ayr = Ayrshire
bor = Borders

These are examples only and should not be treated as agreed until the community confirms them.

Common questions

Do regions replace normal MeshCore messaging?

No. Regions help control where scoped traffic is repeated.

Should every Scottish repeater have the same baseline?

Yes. Every Scottish repeater carries sco, plus sco-admin and the peering roots ioi, wls and eng-ne — these are included in every repeater script.

Should every repeater have every Scottish region?

No. That would defeat the purpose of regions. Repeaters should only list the areas they genuinely serve.

Should we use gb-sco instead of sco?

Not for this Scottish scheme. Some wider UK or international guides use ISO-style codes, but the local Scottish agreement is to use short three-letter codes.

Can a repeater be in more than one region?

Yes. That is useful for high sites, border areas, or repeaters that genuinely link neighbouring areas.

Can we allow * for compatibility?

No. The Scottish MeshCore setup does not allow wildcard forwarding. Use the correct region scope instead.

Summary

Regions give the Scottish MeshCore community a simple way to organise the network as it grows.

Our agreed approach is:

• Use three-letter lowercase codes.
• Use sco for Scotland.
• Carry sco-admin and the peering roots ioi, wls and eng-ne alongside sco on every repeater.
• Use cen, tay, gla, and fif for major regions where they match coverage.
• Use fal, edi, gla, dun, and per for local areas.
• Use ioi for Island of Ireland traffic under the IOI peering agreement.
• Deny wildcard forwarding with region denyf *.
• Do not use long prefixes such as gb-sco or sco-fal in this local scheme.

This gives us a clean, readable, and expandable foundation for building a coordinated Scottish MeshCore network.