Integrating with Served Agencies
Understanding Served Agency Communication Requirements
Served agencies have specific, often rigid communication requirements driven by their own SOPs, legal obligations, and incident command structures. Understanding these requirements is essential before proposing mesh integration.
Red Cross / American Red Cross
- Needs: shelter population counts, resource requests (cots, meals, water), staff check-ins
- Message traffic: typically short, structured (ICS-213 equivalent), not conversational
- Key concern: accountability - messages must be logged (note mesh delivery is best-effort, so logging cannot assume a message was delivered)
- Staffing: mix of trained volunteers and paid staff; not all are technically sophisticated
- Integration point: mesh node at each shelter feeding position/status to EOC
Hospitals
- Needs: patient counts by severity (START triage), resource status (available beds, O2, blood), evacuation coordination
- Message traffic: mesh is unencrypted by default and best-effort - never transmit protected health information (PHI), including any individually identifiable patient data, over mesh
- Key concern: HIPAA obligations rest with the hospital (the covered entity) and its business associates, not with volunteer mesh operators relaying traffic. Following this page does not make a volunteer's mesh use "HIPAA-compliant." Defer entirely to the hospital's own communications and privacy policies on what, if anything, may be transmitted; this page does not constitute HIPAA compliance guidance.
- Integration point: hospital HAM radio operator or communications officer; mesh for non-PHI status only
Emergency Operations Center (EOC)
- Needs: comprehensive situational awareness; resource tracking; inter-agency coordination
- Message traffic: high volume, multi-agency, documented
- Key concern: integration with existing systems (WebEOC, ICS forms, CAD)
- Integration point: MQTT bridge connecting mesh to EOC dashboard; mesh coordinator assigned at EOC
Fire and EMS
- Needs: incident position, resource status, casualty counts, scene perimeter
- Message traffic: tactical and time-critical; concise
- Key concern: interoperability with CAD and dispatch; not adding cognitive load to incident commanders
- Integration point: mesh as supplemental position tracking, not primary tactical comms
Mesh in the ICS Communications Hierarchy
The Incident Command System (ICS) defines a strict communications structure. Mesh fits into this structure as a supplemental tactical channel, not a command channel.
| ICS Traffic Type | Primary Channel | Mesh Role |
|---|---|---|
| Command (incident command decisions) | Voice (P25, VHF/UHF) | NOT appropriate for mesh - use designated voice channels |
| Tactical (field team coordination) | Voice (simplex or repeater) | Supplemental: short status messages, position updates |
| Logistics (resource requests, supply) | Voice or Winlink email | Supplemental: structured request messages via mesh |
| Situation Awareness (mapping, tracking) | Manual boards, GIS | Primary supplement: GPS position sharing is a natural mesh strength |
| Public Information | Designated PIOs only | NOT appropriate - no public-facing mesh traffic |
What Served Agencies Actually Need
When pitching mesh to served agency coordinators, focus on what they actually want - not the technology:
- Short status messages: "Is the shelter at Lincoln School open and how many people are there?" Mesh can deliver roughly a 230-character answer (~228-237 byte payload; fewer characters if Unicode/emoji are used) without consuming repeater air time. Delivery is best-effort, so confirm anything critical.
- Position data: "Where are my teams right now?" Meshtastic's automatic GPS position broadcast answers this continuously without any operator action.
- No additional training burden: Served agency staff should be able to use mesh with minimal training. A Meshtastic node with a preconfigured channel and a simple phone app meets this bar.
- Continues to function without infrastructure: Mesh keeps working without cellular, internet, or repeaters - but coverage and delivery depend on node density and line of sight, and delivery is best-effort (not guaranteed). Treat this as a useful fallback, not a guarantee of communication.
How to Pitch Mesh to an OES or EOC Coordinator
The Three-Minute Pitch
- Open with their problem: "During the [local event] last year, your shelter coordinators couldn't reach EOC for 4 hours because the repeater was down. LoRa mesh works without repeaters or cell service."
- Show one capability: Hand them a Meshtastic device. Send a message from across the room. Show the position on the map. "This runs on battery for around 3 days depending on configuration."
- Make the ask small: "I'm not asking you to replace anything. I'm asking to run this in parallel at your next exercise so you can see how it works."
Be honest about limits in the pitch: mesh is provided as a supplemental, best-effort capability with no warranty of availability or fitness for any purpose. The served agency remains solely responsible for verifying suitability and must not rely on mesh as a primary or life-safety path. Any installation on agency property should be governed by a written agreement (see below).
Common Objections and Responses
| Objection | Response |
|---|---|
| "We already have radios." | "Absolutely - and mesh doesn't replace them. It adds a text and position data layer so your voice channels stay clear for important calls." |
| "What if it breaks?" | "Mesh is decentralized and can route around a failed node when alternate RF paths exist. In a sparse mesh there can still be effective single points of failure - for example a sole bridging relay - so we keep your existing radio systems as the primary comms and treat mesh as a supplement." |
| "Our staff can't learn new technology during a disaster." | "The basic interface is a phone app most people can learn in 5 minutes. We train before the disaster, not during it. We can include it in your next tabletop exercise." |
| "Is it secure/encrypted?" | "Meshtastic uses AES-256 channel encryption. Note that the default public channel uses a publicly-known key, so it is not confidential out of the box. For served agency use over Part 15, we configure a private channel with a strong, custom key shared only with authorized nodes." |
| "Who maintains it?" | "The ARES group maintains the infrastructure nodes. Each served agency location needs a low-cost device; where it runs unattended on solar power, the solar must be sized to local sunlight and the node's duty cycle, and we follow Meshtastic's guidance against placing private channel keys on unattended nodes (physical key-extraction risk)." |
| "We don't have budget." | "A complete node costs roughly $30 - 80. The ARES group can supply and help maintain pre-positioned nodes - but mesh is provided as a supplemental, best-effort capability with no warranty of availability or fitness, and any installation on your facilities should be covered by a written agreement that allocates maintenance responsibility and liability (see below)." |
Training and Exercise Requirements
The milestones below build familiarity with mesh as a supplemental channel. Mesh is best-effort with no guaranteed delivery; no served agency should rely on it as a primary, sole, or life-safety channel even after completing this training:
- Initial orientation (30 - 60 min): Demonstrate mesh hardware, install Meshtastic app on agency-designated device, configure pre-set channel, send and receive test messages.
- Tabletop exercise integration: Include mesh message traffic in a tabletop exercise scenario. Evaluate whether served agency staff can successfully send and receive mesh messages during a simulated event.
- Field exercise: Deploy mesh nodes at served agency locations during a full field exercise. Test coverage, message delivery, and integration with EOC display systems.
- SOP integration: Served agency communications SOP should reference mesh as a supplemental channel, identify who is responsible for the node at each location, and document how to initiate mesh use during an activation.
- Written agreement / MOU: Before installing nodes on agency property, put a written agreement (MOU) in place that allocates maintenance responsibility and includes limitation-of-liability, indemnification, insurance, and non-reliance clauses (the agency acknowledges mesh is supplemental and best-effort and that it will not rely on it as a primary or life-safety channel). Installation on third-party property requires the owner's authorization, and any AC/mains, grounding (NEC 810), or mast/tower work should be done by a qualified professional following local code.
- Annual verification: Test each served agency node annually. Replace batteries, update firmware, verify channel configuration is current.
Served Agency Integration Checklist
- ☐ Met with served agency communications officer or OES coordinator
- ☐ Demonstrated mesh capability during non-emergency visit
- ☐ Identified served agency mesh liaison (person responsible for the node)
- ☐ Written agreement / MOU in place with liability, indemnification, insurance, and non-reliance clauses; property-owner authorization obtained for any installation
- ☐ Installed and configured mesh node at served agency location (AC/grounding/mast work by a qualified professional per local code)
- ☐ Trained served agency liaison on basic operation (send/receive messages, check battery)
- ☐ Conducted tabletop or field exercise with mesh integration
- ☐ Documented served agency location in ARES mesh node inventory
- ☐ Integrated mesh into served agency communication SOP as a supplemental (not primary) channel
- ☐ Annual maintenance schedule established
- ☐ Backup/spare node available if primary fails