Running a Mesh-Enabled EMCOMM Exercise

Why Combined Voice + Mesh Exercises?

Training separately on voice and mesh produces operators who can use each system independently. Combined exercises reveal how the systems interact, where they complement each other, and - critically - where operators might accidentally rely on mesh when they should use voice or vice versa. Combined exercises also let you measure mesh performance in realistic field conditions before relying on it in an actual emergency.

Scenario Design

Scenario Elements That Benefit from Mesh

• Multiple geographically dispersed field teams that need to track each other's positions
• Served agency location (shelter, hospital, EOC staging area) that needs to report resource status periodically
• Net control station that needs to track field team positions without consuming voice net time for position reports
• A simulated infrastructure failure (repeater "goes down" at a pre-planned time mid-exercise) to test mesh as a fallback

Sample Scenario: Earthquake Response, Day 1

SCENARIO: 6.2 magnitude earthquake, 0730 local time.
Infrastructure status: Cell towers out, internet out, primary repeater unknown (simulate partial coverage).
ARES activation: County EC activates all available operators.
Objectives: - Establish EOC comms link (primary: voice on simplex; supplemental: mesh) - Assess four pre-designated shelter sites (teams of 2 per site) - Report shelter status (capacity, occupancy, needs) every 30 minutes - Track all field team positions continuously - Pass a minimum of 10 formal ICS-213 messages via mesh

Inject at T+60 min: Primary simplex frequency congested; shift mesh position reporting
to free up voice channel for priority traffic.

Inject at T+90 min: Shelter #3 reports mass casualty event; all traffic deprioritized
except medical coordination. Because mesh is best-effort, the MCI report and the
medical-coordination traffic that follows are life-safety messages and the
life-safety channel is voice with confirmed receipt - mesh is supplementary only.

Inject at T+95 min (mesh failure test): The Shelter #3 MCI report sent over mesh is
NOT acknowledged within 2 minutes. Evaluate whether the operator detects the
non-delivery and escalates to voice. The exercise must validate the confirmed-receipt
voice fallback for life-safety traffic, not assume the mesh delivers it.

Pre-Positioning Infrastructure

Infrastructure Checklist (T-7 days before exercise)

• ☐ Identify all exercise areas and map expected operating locations
• ☐ Identify elevated relay sites within exercise area (hilltops, buildings, repeater sites)
• ☐ Deploy solar relay nodes at 1 - 3 elevated sites at least 24 hours before exercise
• ☐ Verify relay node solar charging is functioning (check battery voltage)
• ☐ Test message delivery from all expected field team operating areas to EOC node
• ☐ Configure all nodes with exercise channel (separate from operational channel)
• ☐ Assign node names following naming convention (e.g., RELAY-HILLTOP-1, FIELD-TEAM-A)
• ☐ Verify all field team nodes have GPS lock in outdoor test
• ☐ Brief all participants on channel configuration before exercise day
• ☐ Assign backup power (charged batteries or power banks) to all deployed nodes

Assigning Mesh Roles to Participants

Evaluating Performance: Key Metrics

Message Delivery Rate

The primary mesh performance metric is the percentage of sent messages that were received by the intended recipient within an acceptable latency window. Calculate separately for:

• Direct node-to-node (single hop) delivery rate
• Multi-hop delivery rate (messages relayed through 2+ hops)
• Delivery rate under different field conditions (urban, rural, elevated)

Latency Measurement

Record the timestamp when each message is sent and the timestamp when it is confirmed received at the destination. Meshtastic's message log provides send time; the receiving node's log provides receive time. The figures below are suggested local benchmarks, not standards - they are not sourced from a published specification. LoRa airtime and therefore latency depend heavily on the modem preset (spreading factor / bandwidth) and on load, so tie any benchmark to a stated preset. The values below assume a fast/medium preset and a lightly loaded mesh; long-range (high spreading factor) presets and congestion legitimately increase latency:

These targets apply to a lightly loaded mesh. Under disaster-level traffic, airtime saturation and retries can push latency far higher and reduce delivery. Treat the table as best-case illustrative benchmarks tied to your stated preset - not pass/fail standards. A slow message has not necessarily failed (it may still arrive), and a fast one is not proof of delivery, so confirm critical messages explicitly rather than inferring delivery from expected latency. When scoring an exercise, do not flag a normal long-range or congested link as "failing" just because it exceeds these numbers.

Net Efficiency Comparison

Record the number of voice net transmissions consumed for position reports and status updates before mesh was deployed vs. after. A well-integrated mesh can meaningfully reduce voice net traffic for routine status/position reporting by offloading it from the voice channel - but the actual reduction depends entirely on your traffic mix, operators, and coverage. Measure it for your own group from this exercise rather than relying on a generic percentage; any figure you cite should come from your own documented after-action data.

Post-Exercise Debrief Template