How I built on-device machine learning into a BLE mesh network — no cloud, no connectivity, no compromise.
The Problem Nobody Talks About
Every major disaster follows the same pattern. The earthquake hits. The hurricane makes landfall. The wildfire jumps the firebreak. And within minutes — sometimes seconds — the cell towers go down.
Not because they're damaged. Because 50,000 people are all trying to call their families at the same time.
First responders pull out their phones. Nothing. Rescue coordinators open their apps. No signal. Meanwhile, somewhere in the rubble, someone is typing "trapped under debris, 3rd floor, need help" into a mesh messaging app — and that message is sitting in a queue behind a hundred check-ins, status updates, and "is everyone okay?" messages from people who are fine.
This is the information overload problem. And until now, nobody had solved it for offline mesh networks.
Mesh Networking Works. Triage Doesn't.
Apps like Meshtastic and BitChat have proven that device-to-device mesh communication works without internet infrastructure. Your phone talks to my phone via Bluetooth. My phone relays to the next phone. Messages hop across a network of humans — no towers, no servers, no connectivity required.
The problem is that these systems treat every message equally. A cardiac arrest report and a "checking in, all good" message arrive with identical priority. In a network serving hundreds of nodes during an active disaster, a rescue coordinator might receive dozens of messages per minute with zero mechanism to distinguish life-threatening signals from ambient traffic.
The result is cognitive overload at precisely the moment when a human being needs to make fast, accurate decisions.
We needed AI. But we had a constraint: the internet was gone.
On-Device AI: The Only Option That Actually Works
Cloud NLP is off the table the moment infrastructure fails. You cannot call an API when there is no network. You cannot run inference on a remote server when that server is unreachable. This rules out GPT, Claude, Gemini, and every other large language model that lives in a data center.
What you can do is run a small, fast, quantized neural model directly on a commodity Android smartphone — no connectivity required, no cloud dependency, no specialized hardware.
This is the core insight behind ResQMesh AI Platform: an open-source Android platform that integrates on-device machine learning directly into the BLE mesh communication stack.
The entire AI layer runs locally. Always. Even when every tower in a 50-mile radius is dark.
How the Classification Pipeline Works
The heart of the system is a two-stage composite classifier I call M1.
Stage 1: Keyword Classifier
Before any neural inference runs, every incoming message passes through a deterministic rule engine covering approximately 90 lexical patterns derived from FEMA Incident Command System guidelines. Patterns like "trapped inside," "can't breathe," "water rising," "cardiac arrest."
If a CRITICAL or HIGH pattern matches, the message is tagged and surfaced immediately — no neural model invocation required. This guarantees sub-millisecond classification for the most time-sensitive messages, and it works on any Android device regardless of hardware capability.
Stage 2: Neural Classifier
Messages that don't match any keyword pattern go to a quantized Conv1D TensorFlow Lite model. The architecture is deliberately lightweight: an embedding layer, a single Conv1D layer with global max pooling, a dense layer with dropout, and a 10-class softmax output.
The model classifies into nine emergency categories — Medical, Collapse, Fire, Flood, Security, Weather, Missing Person, Infrastructure, Resource Request — plus a Non-Emergency class. Each category maps to one of four priority tiers: CRITICAL, HIGH, NORMAL, or LOW.
Total model size: 420KB. Inference time on mid-range hardware: single-digit milliseconds.
A confidence threshold of τ = 0.25 filters out uncertain predictions. Messages shorter than three tokens skip neural classification entirely.
The composite pipeline runs Stage 1 first. Stage 2 only runs on a keyword miss. If the TFLite model asset is absent, the system falls back gracefully to keyword-only mode.
The Part That Surprised Us: The BLE Priority Queue
Classification is only half the problem. The other half is radio-layer delivery.
I replaced the FIFO broadcaster with a java.util.PriorityQueue protected by a Mutex, driven by a CONFLATED signal actor. Every outgoing packet gets a priority field assigned synchronously by the classifier before enqueuing. CRITICAL packets preempt everything else at the radio layer.
The benchmark result: 1001× reduction in delivery latency for CRITICAL messages under simulated mesh load — 1,000 packets queued at 100µs intervals.
One thousand and one times faster delivery for the message that says someone is dying.
What Else the Platform Does
M2 — Offline Speech Recognition via Vosk Android. Voice-to-text that works completely offline, powered by a deep neural acoustic model.
M3 — FEMA ICS-213 Report Generator. Automatically aggregates classified messages into ICS-213-compatible situation reports — rendered as HTML, printable via Android's PrintManager — without any coordinator needing to type a single form field manually.
M4 — Energy Optimizer. A battery-aware relay policy engine that adapts packet forwarding probability based on device power state. When your phone is at 8% battery in hour six of a disaster, it shouldn't be relaying every low-priority packet. But it should always relay CRITICAL traffic. M4 enforces this guarantee with 21 unit tests.
The Architecture Decision That Made Everything Possible
All four modules live in a self-contained Gradle library module — :resqmesh-ai — with zero dependency on the application module. The entire AI layer can be unit tested independently of the Android UI, imported into other projects, and validated without running the full app.
Why This Matters Beyond Disaster Response
The pattern I've built — lightweight on-device neural classification combined with deterministic rule-based fallback, running over an encrypted peer-to-peer mesh, with radio-layer priority preemption — is generalizable.
Anywhere connectivity is unreliable or absent. Rural areas. Underground facilities. Ships at sea. Any environment where "just use the cloud" is not an answer.
A 420KB quantized Conv1D model running on a mid-range Android phone can classify emergency messages faster than a human can read them. You don't need a data center. You don't need an API key. You don't need internet.
You need a charged phone and the right software.
Open Source and What's Next
ResQMesh AI Platform is released under GPL-3.0. The source
code is available at:
github.com/AleksPlekhov/ai-mesh-emergency-communication-platform
Planned next steps include federated learning for in-field model improvement, a real-time situational awareness map on offline OpenStreetMap tiles, adaptive BLE/Wi-Fi Direct switching, and bridging to FEMA IPAWS when connectivity is restored.
If you're working on offline communication, emergency response systems, or on-device ML for constrained environments - open an issue or start a discussion on GitHub.