# Deployment and Operations

# Deploying Mesh Networks in Disaster Scenarios

## Overview

Deploying a LoRa mesh network during an active disaster differs significantly from a planned exercise. Speed, improvisation, and integration with an active ICS structure are paramount. This page walks through the complete deployment sequence from pre-event staging through live operations.

<div id="bkmrk-mesh-supplement-not-lifeline" style="background:#f8d7da;border-left:4px solid #dc3545;padding:12px 16px;margin:16px 0;"> **Mesh is a supplement, not a lifeline.** LoRa mesh (Meshtastic/MeshCore) is **best-effort with no guaranteed delivery**: messages can silently fail to arrive, the shared half-duplex channel saturates under heavy load, and coverage depends on powered relay nodes being in range. It is not a replacement for 911, NWS alerts, or licensed amateur/voice nets. For any life-threatening emergency, use 911/voice with confirmed receipt first; use mesh as a fallback when those are unavailable, and treat mesh status/position as supplementary. </div>## Pre-Event Staging

The most effective disaster mesh deployments begin well before the event. Pre-staging includes:

- **Fixed relay nodes at key sites**: EOC, hospitals, Red Cross shelters, CERT caches, and strategic high-elevation points (water towers, fire stations) should have permanently installed relay nodes maintained on standby power.
- **Go kit pre-positioning**: Portable node kits stored at ARES/RACES deployment caches, pre-configured with the operational channel and node names.
- **Firmware and configuration freeze**: Two weeks before a forecast event (hurricane, wildfire season), freeze firmware versions and push final channel configurations. Do not update during an active event.
- **Battery maintenance**: Store lithium cells (including LiFePO4) at approximately 40-60% state of charge during standby to limit calendar aging; top up to full only in the 24-48 hours before expected deployment. Never charge any lithium chemistry, including LiFePO4, below 0 °C (32 °F).

## Rapid Deployment Sequence

1. **Receive activation order** from COML or ARES EC. Confirm assigned tactical node name, channel plan, and check-in frequency and interval.
2. **Travel to assigned position** with go kit. Log departure time in ICS 214.
3. **Conduct site survey**: Identify best antenna elevation point. Note any obstructions (buildings, terrain, foliage).
4. **Deploy antenna**: Elevate to maximum practical height. Secure coax and weatherproof connections.
5. **Power up node**: Allow 2-5 minutes for GPS cold fix. Confirm node name and channel in [Meshtastic app](https://wiki.meshamerica.com/books/hardware-guide/page/meshtastic-app).
6. **Test connectivity**: Send a check-in message to EOC-MAIN. A green checkmark in Meshtastic confirms a protocol ACK for a direct message (best-effort, not a guaranteed end-to-end delivery and not proof a human read it). For anything life-safety, confirm with a human reply before relying on it.
7. **Report to COML**: Via voice radio or mesh message - node name, location (GPS coordinates or address), battery level, estimated endurance, node count visible.
8. **Begin ICS 214 log**: Record activation time, location, initial node count, and all subsequent events.

## Antenna Elevation Strategies

In disaster environments, traditional antenna mounting points may be unavailable or unsafe. Practical options:

- **Vehicle rooftop**: Magnetic mount antenna on a metal vehicle roof is fast to deploy and provides 2-4 meters of elevation above grade. Most effective in flat terrain or when working in a parking lot staging area.
- **Temporary mast**: A 3-6 meter telescoping fiberglass push-up mast (e.g., MFJ-1910 or equivalent) with a ground stake can be deployed in under 5 minutes by one person. Provides significant elevation advantage.
- **Existing structure attachment**: In urban rubble environments, attaching a whip antenna to any surviving elevated structure (fence post, utility pole stub, intact second-floor window frame) can provide 3-6 meters of elevation with minimal equipment.
- **Balloon lift**: For extended fixed relay in flat terrain, a helium balloon can lift a lightweight node and antenna to 10-30 meters. Requires tether management and calm wind conditions. Tethered/moored balloons may be subject to FAA rules (14 CFR Part 101), including height, marking, and notification requirements, and pose hazards near power lines and aircraft - check FAA requirements and local conditions before deploying.

## Frequency Coordination with Served Agency

Confirm that your LoRa channel center frequency does not conflict with LoRaWAN sensors already deployed by the served agency (e.g., flood sensors on 915.2 MHz). The Meshtastic default US channel preset should be checked against the agency sensor inventory. Document the agreed channel in ICS 205.

## Mesh Topology for Disaster Environments

Meshtastic always uses managed flood routing - it does not offer selectable star/mesh/chain routing modes. The patterns below describe how you physically *place* nodes to approximate these shapes; the protocol underneath is the same flood-based mesh in every case.

<table id="bkmrk-topologydescriptionw"> <thead><tr><th>Placement pattern</th><th>Description</th><th>When to Use</th></tr></thead> <tbody> <tr><td>Star (hub-and-spoke)</td><td>Field nodes are placed within direct range of one well-elevated central relay, so most traffic reaches the hub in a single hop.</td><td>Open flat terrain; EOC has excellent elevation; small node count (fewer than 10).</td></tr> <tr><td>Mesh (distributed)</td><td>Nodes are spread so each is in range of several neighbors; the flood routing relays messages through multiple nodes to reach the destination.</td><td>Urban rubble; blocked line-of-sight; large geographic area; many nodes.</td></tr> <tr><td>Chain (linear relay)</td><td>Nodes placed in a line to extend range along a corridor (road, valley, ridge), each within range of the next.</td><td>Evacuation corridor monitoring; search teams moving along a defined route.</td></tr> </tbody></table>

**Key insight**: In obstructed environments, additional well-placed relay nodes can extend coverage through obstructions where a direct link cannot - but each extra hop adds latency and consumes shared airtime, so add relays deliberately rather than maximizing hop count. Do not over-rely on this for search-and-rescue: RF into rubble or below grade is highly unreliable, so a relayed link to a hard-to-reach receiver may or may not get through and must not be treated as a dependable way to reach a trapped or buried person. Each hop re-transmits at the node's normal certified Part 15 power (maximum 1 W / 30 dBm conducted under 47 CFR §15.247) - there is no emergency exception allowing higher power on unlicensed ISM equipment. Meshtastic's default hop limit is **3** (maximum 7); raising the hop limit increases airtime and congestion. Do not reduce the maximum hop count below 3 in disaster deployments.

## Interface with ICS Structure

The mesh network is a resource managed by the Communications Unit within the Logistics Section (Service Branch), led by the Communications Unit Leader (COML). In most ICS deployments, significant operational changes (channel reassignment, node redeployment, shutdown) should be coordinated with and authorized by the COML. Field mesh operators report to the COML, not directly to Operations. When Operations Section needs to reach a field team via mesh, the request flows: Operations Chief to COML to mesh operator to field node. This chain maintains ICS unity of command and ensures communications changes are coordinated.

# Net Control Operations for Mesh Networks

## Mesh vs. Voice Net Control: A Fundamental Difference

In a traditional amateur radio voice net, the Net Control Station (NCS) is the technical and operational hub of all communications - every transmission must be directed through or acknowledged by NCS. LoRa mesh networks operate on a fundamentally different principle: they are peer-to-peer systems with no central controller. Nodes contend for a shared, half-duplex channel (listen-before-talk, with airtime and duty-cycle limits), so they do not transmit arbitrarily at any time; the mesh routes messages on a best-effort basis without a central controller.

Despite this, the operational role of a net control function remains valuable and is recommended for any mesh network supporting an ICS activation. The difference is that mesh net control is a human coordination role, not a technical gatekeeping role.

## Responsibilities of Mesh Net Control

- **Node inventory management**: Maintain a current list of all active nodes (name, operator, location, battery endurance). Update at each operational period change and whenever a node is added or goes offline.
- **Coverage verification**: Confirm that all assigned positions have mesh connectivity, either directly or via relayed path. Nodes that cannot reach any other node are isolated and may need repositioning.
- **Channel discipline**: Monitor for excessive traffic (bulk test messages, repeated retransmissions) that degrades bandwidth for others. Coordinate with the COML to address violations.
- **Liaison to COML**: Translate mesh network status into ICS-compatible status reports for inclusion in the Incident Action Plan.
- **Escalation to voice radio**: When mesh connectivity fails between critical nodes, escalate to the voice radio net for the affected link. This is recommended SOP precisely because LoRa mesh is best-effort with no guaranteed delivery - do not wait for the mesh to self-heal if the message is time-sensitive.

## Structured Check-In Procedure

At the start of each operational period (operational periods in ICS are typically 12 to 24 hours), mesh net control should conduct a structured check-in:

1. Net control sends a broadcast message to all nodes: \[OPPERIOD-2 CHECK-IN\] All nodes reply with status. EOC-MAIN standing by.
2. Each node replies with a short status message: SHELTER-A: ONLINE, 85% battery, 4 nodes visible, 12 persons checked in.
3. Net control logs each reply in the ICS 214 activity log, noting time of receipt and node status.
4. Nodes that do not reply within 5 minutes (a configurable local threshold, not a fixed standard) are flagged as missing. Net control attempts contact via voice radio before recording the node offline on the ICS 214 activity log or incident status board. (Note: the ICS 217A is a pre-incident Communications Resource Availability Worksheet that feeds the ICS 205 comms plan - it is not a live node-status log, so do not record real-time outages there.)

## Tracking Node Count and Coverage

Meshtastic provides a node list in the app showing all nodes heard (directly or via mesh). Net control should maintain a separate paper or spreadsheet log that includes:

<table id="bkmrk-node-nameoperatorloc"> <thead><tr><th>Node Name</th><th>Operator</th><th>Location</th><th>Last Heard</th><th>Battery %</th><th>Status</th></tr></thead> <tbody> <tr><td>EOC-MAIN</td><td>W6XYZ</td><td>City EOC Rooftop</td><td>Continuous</td><td>AC Power</td><td>ONLINE</td></tr> <tr><td>SHELTER-A</td><td>KD9ABC</td><td>Franklin HS Gym</td><td>14:32</td><td>78%</td><td>ONLINE</td></tr> <tr><td>DIV-B-RELAY</td><td>N7DEF</td><td>Oak Ave Water Tower</td><td>14:28</td><td>62%</td><td>ONLINE</td></tr> <tr><td>SEARCH-1</td><td>KG5GHI</td><td>Mobile (Grid 4)</td><td>14:05</td><td>45%</td><td>MONITOR</td></tr> </tbody></table>

## Handling Message Relay Requests

Although the mesh automatically routes messages, operators at field positions may request manual relay assistance when:

- A message requires positive confirmation of delivery. The mesh delivers best-effort; Meshtastic does show an ACK/Delivered status per message, but those ACKs are not guaranteed, so a human relay provides positive confirmation when delivery is critical.
- The message contains sensitive information not suitable for broadcast (use the DM/direct message channel in Meshtastic).
- An ICS 213 form needs to be transcribed to paper at the EOC.

Net control should acknowledge all relay requests and provide confirmation to the originating node when a reply is received from the intended party. Absent a reply, assume the message did not arrive and escalate to voice.

## Escalation to Voice Radio

Mesh net control must be prepared to escalate to voice radio immediately when:

- A node has been offline for more than 10 minutes without explanation.
- A critical message (MCI report, EOC request, shelter closure) has not been acknowledged within 5 minutes.
- The mesh channel appears to be experiencing congestion or RF interference (excessive retransmissions, failed acknowledgments).
- Any node reports battery below 20% without a relief operator on the way.

The voice radio escalation path should be pre-coordinated: establish the tactical frequency and call sign of the COML before the operational period begins, and ensure mesh net control has a radio capable of reaching EOC. Note that if the escalation path is an amateur (Part 97) frequency, only licensed amateurs may transmit on it, with call-sign identification every 10 minutes and at the end of communication per 47 CFR 97.119. Ensure the designated escalation operator is licensed, or use a license-appropriate service (GMRS with its own license, FRS, or business radio) suited to the users.

## Log Keeping

Net control must maintain a continuous ICS 214 activity log throughout the operational period. Minimum entries:

- Activation and deactivation times for each node.
- All check-in responses and any non-responding nodes.
- Channel changes, configuration updates, or firmware actions taken.
- All message relay confirmations for ICS 213 traffic.
- Battery status at each check-in interval.
- All voice radio escalations and outcomes.

Mesh operations themselves are managed by the Communications Unit (COML) in the Logistics Section. At the end of each operational period, the completed ICS 214 is - like all unit logs - forwarded to the Documentation Unit in the Planning Section for inclusion in the incident file. (Forwarding logs to Planning's Documentation Unit does not make mesh a Planning-Section function; operational control remains with the COML in Logistics.)

# Integration with Winlink and APRS

## The Complementary Stack

No single communications technology is sufficient for all emergency communications scenarios. The most resilient deployments combine multiple systems that complement each other's strengths. The three-layer stack of LoRa mesh plus Winlink plus APRS provides digital messaging, store-and-forward email, and position tracking - covering the primary data needs of an ICS-integrated emergency communications response.

## Winlink Overview

Winlink is a worldwide radio email system that allows licensed amateur operators (and, under certain authorizations, non-amateur stations) to send and receive email messages via radio. Amateur-band Winlink requires an amateur radio license; separate Winlink networks exist for MARS and authorized government/EmComm stations operating under their own licensing (e.g., Part 80/government allocations) — these are not open to unlicensed users on amateur frequencies. Key components:

- **Winlink Common Message Server (CMS)**: The cloud-based message store operated by the Winlink Development Team. Messages are held until retrieved by the recipient.
- **Radio Message Server (RMS)**: A gateway station (typically a licensed operator's station with a TNC and radio) that provides radio access to the CMS. RMS gateways exist on HF (Pactor, VARA HF, ARDOP, Robust Packet) and VHF/UHF (Packet, VARA FM). Note: LoRa is not an official Winlink RMS access mode — third-party experiments bridge LoRa mesh to Winlink, but there is no LoRa RMS mode in Winlink's supported-mode list.
- **Client software**: Winlink Express (Windows) or Pat Winlink (cross-platform, open source) are used by operators to compose messages and connect to RMS gateways.

## Building a Winlink Gateway for ICS Form Delivery

A Winlink RMS gateway co-located with a mesh EOC node creates a powerful hybrid: field operators compose ICS 213 messages on a mesh-connected device, and those messages are forwarded to the EOC node which relays them into the Winlink system for delivery to served agency email addresses.

> **⚠️ Legal boundary — plaintext only, licensed operator.** Winlink rides licensed amateur RF, where 47 CFR §97.113(a)(4) prohibits transmitting messages encoded to obscure their meaning. Meshtastic payloads are AES-256 encrypted by default, so the gateway must present **plaintext (decrypted) content** on the amateur Winlink leg, and a **licensed amateur** must operate that leg. Encrypted Meshtastic payloads cannot lawfully be transmitted on amateur frequencies.

### Hardware Required for a VHF/VARA FM Gateway

- VHF FM transceiver (e.g., Icom IC-7100, Kenwood TM-D710)
- Sound card interface or VARA FM modem (e.g., Digirig Mobile)
- Windows PC or Raspberry Pi running Winlink Express or Pat
- Internet connection to CMS (for a full gateway); or peer-to-peer mode for offline operation

### Configuration Steps (VARA FM)

1. Install VARA FM modem software and configure audio levels to the transceiver.
2. Install Winlink Express. Configure station call sign, grid square, and VARA FM as the primary radio mode.
3. Enable RMS Relay mode in Winlink Express to accept connections from client stations.
4. Register the gateway with the Winlink network (requires licensed callsign and internet access at least once for initial registration).
5. Test by connecting with a second station using Pat or Winlink Express in client mode.

ICS 213 forms composed in Winlink Express are transmitted as structured email attachments. Served agencies with standard email can receive these forms without any special software.

## APRS as a Parallel Position Tracking Layer

Automatic Packet Reporting System (APRS) operates on 144.390 MHz (North America) and provides real-time position reporting, weather data, and short messaging via a nationwide network of digipeaters and I-gates (internet gateways). APRS operates under Part 97 and requires an amateur radio license to transmit: a mesh-to-APRS position bridge must be operated by a licensed amateur, and unlicensed users may not transmit on 144.390 MHz. APRS complements Meshtastic mesh in the following ways:

<table id="bkmrk-featuremeshtastic-me"> <thead><tr><th>Feature</th><th>Meshtastic Mesh</th><th>APRS</th></tr></thead> <tbody> <tr><td>Position tracking</td><td>Yes (GPS, within mesh coverage)</td><td>Yes (GPS, nationwide via digipeaters)</td></tr> <tr><td>Text messaging</td><td>Yes (multi-hop; payload encrypted, but the default channel uses the public AQ== key — meaningful confidentiality requires setting a custom key)</td><td>Limited (unencrypted, short messages)</td></tr> <tr><td>Internet connectivity required</td><td>No (self-contained mesh)</td><td>No for local; yes for APRS-IS</td></tr> <tr><td>License required</td><td>No (ISM band)</td><td>Yes (Technician or higher)</td></tr> <tr><td>Nationwide coverage</td><td>Only where mesh nodes exist</td><td>Yes (existing infrastructure)</td></tr> <tr><td>Typical range per hop</td><td>2-15 km</td><td>10-100 km via digipeater</td></tr> </tbody></table>

**Note:** Mesh text/position transport is best-effort with no guaranteed delivery. Where a message must be confirmed delivered or archived, use Winlink rather than mesh.

A field operator equipped with both a Meshtastic device and a VHF APRS tracker (e.g., Mobilinkd TNC with a handheld radio, or a Kenwood TH-D74) provides redundant position visibility: the EOC can track them on the local mesh map AND on aprs.fi via APRS-IS.

## Mesh + Winlink + APRS: The Complete Stack

When all three systems are operational, the complementary roles are:

- **LoRa Mesh (Meshtastic)**: Short-range text messaging (payload encrypted, but the default channel uses the public AQ== key — set a custom key for real confidentiality), welfare check-ins, ICS 213 relay within the incident area, GPS position sharing among mesh-equipped operators.
- **Winlink**: Store-and-forward email delivery for ICS forms to served agency recipients, long-haul message delivery via HF when VHF infrastructure is unavailable, formal record of messages (timestamped, archived).
- **APRS**: Nationwide position tracking for mobile operators outside mesh coverage, real-time map display on aprs.fi for remote coordination, weather object broadcasting.

## Tools and Software

<table id="bkmrk-toolplatformpurpose-"> <thead><tr><th>Tool</th><th>Platform</th><th>Purpose</th></tr></thead> <tbody> <tr><td>[Meshtastic app](https://wiki.meshamerica.com/books/hardware-guide/page/meshtastic-app)</td><td>iOS / Android / Web</td><td>Mesh node control, messaging, map view</td></tr> <tr><td>Winlink Express</td><td>Windows</td><td>Winlink client and gateway software; ICS form templates included</td></tr> <tr><td>Pat Winlink</td><td>Linux / macOS / Windows / Raspberry Pi</td><td>Open-source Winlink client; CLI and web UI; ideal for headless gateway builds</td></tr> <tr><td>Direwolf</td><td>Linux / Windows</td><td>Software TNC for APRS and Winlink Packet; runs on Raspberry Pi</td></tr> <tr><td>YAAC / APRSdroid</td><td>Java (desktop) / Android</td><td>APRS client for tracking and messaging</td></tr> <tr><td>atak-forwarder</td><td>Android (ATAK plugin)</td><td>Forwards Meshtastic positions into ATAK/WinTAK for ICS TAK server integration</td></tr> </tbody></table>

## Practical Integration Workflow

1. Pre-event: Configure all mesh nodes on the agreed channel. Pre-load ICS 213 message templates on devices used by served agency liaisons.
2. At EOC: Stand up Winlink gateway on VHF. Confirm Pat or Winlink Express can reach a CMS. Test ICS 213 form delivery to served agency email.
3. At EOC: Enable APRS I-gate (via Direwolf and VHF radio) to provide internet-visible position tracking for all APRS-equipped operators.
4. Operations: Field operators use Meshtastic for local comms. When a message must reach a served agency email (hospital, county OES), it is forwarded to the EOC mesh node and injected into Winlink for delivery. The EOC gateway must hand **plaintext (decrypted)** content to a **licensed amateur**'s Winlink station — encrypted mesh traffic cannot be transmitted over amateur Winlink (47 CFR §97.113(a)(4)).
5. Position tracking: EOC staff monitor both the Meshtastic map (local) and aprs.fi (wide area) to maintain situational awareness of all resources.