¶ NOTE - A Regional Framework was impelemented 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 understaning 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.
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 uneccessary traffic.
Regions help us:
Keep local traffic local
In the future, a message that only matters in one area wont always need to be repeated across every part of Scotland.
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.
Improve reliability
Less unnecessary repeating leaves more room for useful messages.
Make planning clearer
Regions make repeater deployment easier to map, identify needs, plan future expansion and ease of ongoing mesh maintenance.
Support controlled peering
Strategic repeaters can deliberately carry neighbouring traffic, such as the IOI peering agreement between Scotland and the Island of Ireland.
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 requirment will be a future need but best practise planning mandates introducing regions as early as is practical.
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 preceeded byregion 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.
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 documnet) 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.
| Code | Area |
|---|---|
sco |
Scotland |
cen |
Central Scotland |
fif |
Fife |
tay |
Tayside |
gla |
Glasgow area |
edi |
Edinburgh area |
fal |
Falkirk area |
dun |
Dundee area |
per |
Perth area |
ang |
Angus area |
ioi |
Island of Ireland (ioi) — IOI peering |
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
If another region wants to peer with Scotland in a similar way, they should already have the following in place:
region denyf *; see Wildcard forwarding is not allowed).When that fits your situation, contact the Scottish Mesh community on Discord so we can discuss scope names, boundaries, and a safe rollout.
Although the hierarchy is not written into the code itself, it can be thought of like this:
sco
cen
fal
edi
gla
fif
tay
dun
per
ang
ioi
In plain English:
sco is for Scotland-wide traffic.tay, cen, and fif are Scottish sub regions.fal, edi, gla, dun, per and ang are local areas.ioi is for the Island of Ireland under the IOI peering agreement.A Scottish repeater should normally be configured with:
sco.ioi code for IOI peering.Do not allow wildcard forwarding.
In command line interface (CLI) examples, this means using
region denyf *
A repeater covering the Falkirk area would usually have:
sco
ioi
cen
fal
A repeater that mainly serves Central Scotland but has strong coverage towards Edinburgh might use:
sco
ioi
cen
edi
A Fife repeater would usually have:
sco
ioi
fif
If it genuinely provides useful Central Scotland coverage, it may also include:
cen
ioiScottish repeaters should normally include ioi alongside sco as part of the IOI peering agreement:
sco
ioi
That keeps peering-capable forwarding available where the Scottish baseline is configured. It does not make ioi a Scottish local region.
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.
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.
For a Central Scotland / Falkirk repeater, the setup may look conceptually like this:
region put sco *
region put ioi *
region put cen sco
region put fal cen
region allowf sco
region allowf ioi
region allowf cen
region allowf fal
region denyf *
region default sco
region save
Then check the result with:
region
For a Tayside / Dundee repeater:
region put sco *
region put ioi *
region put tay sco
region put dun tay
region allowf sco
region allowf ioi
region allowf tay
region allowf dun
region denyf *
region default sco
region save
For a Glasgow-area repeater:
region put sco *
region put ioi *
region put gla sco
region allowf sco
region allowf ioi
region allowf gla
region denyf *
region default sco
region save
For a repeater that serves Scotland, Central Scotland, Glasgow, Edinburgh, and IOI peering (ioi):
region put sco *
region put cen sco
region put gla cen
region put edi cen
region put ioi *
region allowf sco
region allowf cen
region allowf gla
region allowf edi
region allowf ioi
region denyf *
region default sco
region save
On firmware that supports default scope, repeater and room server administrators should also set the default scope for packets that originate from that node:
region default sco
Set
region default scoon 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 toscoensures 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.
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.
When a new Scottish area needs a code, use these rules:
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.
No. Regions help control where scoped traffic is repeated.
sco and ioi?Yes, that is the recommended baseline for Scottish repeaters. Use sco for Scotland and add ioi alongside it for the IOI peering agreement.
No. That would defeat the purpose of regions. Repeaters should only list the areas they genuinely serve.
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.
Yes. That is useful for high sites, border areas, or repeaters that genuinely link neighbouring areas.
* for compatibility?No. The Scottish MeshCore setup does not allow wildcard forwarding. Use the correct region scope instead.
Regions give the Scottish MeshCore community a simple way to organise the network as it grows.
Our agreed approach is:
sco for Scotland.ioi wherever the Scottish baseline sco is configured (IOI peering).cen, tay, gla, and fif for major regions where they match coverage.fal, edi, gla, dun, and per for local areas.ioi for Island of Ireland traffic under the IOI peering agreement.region denyf *.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.