Header image

Field-Ready Emergency Ad-Hoc Networks for Real-World Deployments

October 2025

Research on emergency ad hoc networks (MANETs) accelerated in the early 2000s with the promise that devices would self-organize when cellular and wired infrastructure failed. Prototypes spanned reflashed home routers, laptop relays, Android routing daemons, and aerial repeaters. Despite protocol diversity—AODV, OLSR, BATMAN, DYMO—the approach rarely reached population scale.

The binding constraint is deployment feasibility: who can operate the system, with what hardware and permissions, under outage conditions. Many studies proved radios can self-organize; far fewer produced systems ordinary residents can use without preparation. Platform realities block most laboratory assumptions: stock smartphones do not expose IBSS/802.11s1 2 to apps, and vendor router firmware often removes mesh modes unless replaced with OpenWrt or a full Linux stack3. Designs that depend on pre-installed apps, rooted phones, or pre-flashed gear fail when the intended users are unprepared.

IBSS is 802.11 ad-hoc mode; 802.11s adds standardized mesh with HWMP routing in the Wi-Fi MAC. Stock phone APIs generally don't expose either to apps.

This article distills lessons from that history and offers a five-axis feasibility lens—App Needed, Proprietary, Browser Access, Self-Deployable, Long Range—that favors a minimal mesh substrate speaking HTTP to any phone via a captive portal. Standards now document how networks signal and present captive pages; every modern OS implements the interaction.4 5

Conceptually, each node behaves like a pocket Wi-Fi router: phones must be nearby and connect normally, while the nodes themselves communicate long-range with each other over a separate, low-bandwidth radio.

Captive portal (capport) is the OS-triggered mini-browser that opens on Wi-Fi join using DHCP/RA hints; content can be served entirely by the local node.

Why technical success often fails in deployment

Phone networking stacks are closed for multi-hop. Android exposes Wi-Fi Direct (P2P) for nearby links but not general IBSS/802.11s to third-party apps; multi-group relaying works only through app-level gateways with added overhead. iOS provides Multipeer Connectivity for nearby sharing, not multi-hop routing.2 6 Empirical reviews note that production Android images rarely ship kernels with 802.11s enabled.1

Mesh works on routers you control. 802.11s is standardized and implemented in Linux/mac80211; OpenWrt exposes it on compatible chipsets. That shifts effort from protocol design to logistics: provisioning, power, and placement.3

Radio physics penalize Wi-Fi at scale. Indoors and street canyons limit 2.4/5 GHz range to tens of meters per hop; single-radio meshes lose effective throughput each hop due to airtime contention. Sub-GHz links trade throughput for reach and link budget, which aligns with text and telemetry traffic rather than images or voice.7 8

User onboarding is the missing layer. In an outage, residents must connect in under a minute using a stock phone. The only universal affordance is the browser triggered by a captive-portal flow; OS vendors and the IETF have standardized this pathway.4 9 10 5

A five-axis lens for feasibility

App Needed. If use depends on a pre-installed app, adoption collapses at the moment of need. Browser-served interfaces from local nodes avoid app stores, background restrictions, and OS updates.4 9 5

Proprietary. Closed radios and protocols may serve a single agency but hinder repair, auditing, and volunteer augmentation. Favor documented standards (802.11s/HWMP) and open drivers on commodity hardware.3

Browser Access. A recognizable SSID that triggers a captive portal is the shortest path to participation. The local page can provide text board, SOS, check-ins, and status without Internet connectivity.4 9 10 5

Self-Deployable. Hardware should be buildable from shelf parts (Raspberry Pi/OpenWrt class, or LPWAN modules), powerable by USB/solar, and configurable offline. Nodes must auto-discover peers and present the portal with no operator steps.

Long Range. Sparse coverage requires sub-GHz backhaul. LoRa-class links deliver ~0.3-50 kbps with high sensitivity; urban studies report kilometer-scale reach under realistic conditions. Treat images/voice as optional and local; prioritize store-and-forward text.11 7 8

"LoRa-class" refers to sub-GHz CSS radios with ~0.3-50 kbps payload rates and high link budget; suited to delay-tolerant text/telemetry, not real-time media.

Systems that score well on these axes tend to survive outside the lab. Systems that fail on the first three rarely reach users.

The browser-first mesh substrate

A practical architecture centers the phone browser and hides complexity behind it:

  • Backhaul radio. Sub-GHz (e.g., LoRa/LoRa-class) for robust, long-range store-and-forward of small packets. Expect seconds-to-minutes latency and duty-cycle limits; design message sizes and cadence accordingly.11 8
  • Access edge. Each node also runs a 2.4 GHz Wi-Fi AP (e.g., SSID “Emergency-Local”). On association, the node advertises a captive portal and serves a minimal single-page app: bulletin board, short messages, SOS, and local status. Phones stay in ordinary client mode.4 9 5
  • Intra-mesh capacity where possible. Between fixed nodes, use Ethernet or 802.11s for higher-rate local backhaul if you control firmware and drivers.3
  • Routing discipline. Prefer simple, partition-tolerant patterns (acknowledged store-and-forward, delay-tolerant queues). Avoid dependencies on phone OS relaying; treat phones as clients, not mesh routers.2 6
  • Operations. Publish printable instructions; pre-position a handful of nodes in public buildings; enable volunteers to assemble additional units from a BOM.
"Store-and-forward / delay-tolerant" means nodes queue messages and relay them opportunistically with acknowledgments and retries. Designed for partitions and minutes-scale latency, not real-time voice or video.

This approach accepts durable platform constraints—phones won’t expose general mesh modes to apps—and exploits a universally learned interaction: the captive-portal browser.

Evidence that guides design choices

  • Smartphone OS limits are stable. Android’s public APIs are scoped to Wi-Fi Direct; multi-hop requires application gateways and incurs overhead. iOS Multipeer is similarly scoped to nearby exchange.2 6
  • Mesh on routers is mature when you own the stack. Linux/mac80211 implements 802.11s (HWMP); OpenWrt surfaces it on supported chipsets.3
  • Captive-portal UX is standardized. RFC 8952 defines the architecture; RFC 8910 and related capport work specify DHCP/RA signaling; OS documentation describes captive portal detection and user flows.4 9 10 5
  • Sub-GHz tradeoffs are consistent across studies. Vendor papers and peer-reviewed measurements converge on kilometer-class urban reach with very low throughput—well matched to short texts and telemetry.11 7 8

Recommendations for planners and builders

Design for zero install at the edge; keep phones as clients; align payloads with sub-GHz envelopes; budget for power and placement; publish open images/BOMs so communities can self-deploy. Measure success by time-to-first-message for an untrained resident on a stock phone.

  1. Soares, E., et al. Experimentation with MANETs of Smartphones. Wireless Days 2017, extended version (PDF). https://www.dcc.fc.up.pt/~rprior/homepage/pubs/WirelessDays2017.pdf  ↩︎ ↩︎

  2. Android Developers. Wi-Fi Direct (P2P) overview/APIs. https://developer.android.com/develop/connectivity/wifi/wifip2p  ↩︎ ↩︎ ↩︎ ↩︎

  3. Linux Wireless docs. IEEE 802.11s — mac80211 implementation (HWMP). https://wireless.docs.kernel.org/en/latest/en/developers/documentation/ieee80211/802.11s.html  ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

  4. RFC 8952. Captive Portal Architecture. RFC Editor. https://www.rfc-editor.org/rfc/rfc8952  ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

  5. Microsoft Learn. Captive Portal Detection and User Experience in Windows. https://learn.microsoft.com/en-us/windows-hardware/drivers/mobilebroadband/captive-portals  ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

  6. Funai, C., Tapparello, C., Heinzelman, W. Enabling Multi-hop Ad Hoc Networks Through Wi-Fi Direct Multi-Group Networking. IEEE ICNC 2017 (PDF). https://www.hajim.rochester.edu/ece/sites/tapparello/papers/Tapparello_ICNC2017.pdf  ↩︎ ↩︎ ↩︎

  7. Griva, A. I., et al. LoRa-Based IoT Network Assessment in Rural and Urban Scenarios. Sensors 23(3):1695 (2023). https://www.mdpi.com/1424-8220/23/3/1695  ↩︎ ↩︎ ↩︎

  8. Semtech. Predicting LoRaWAN Capacity (technical note, PDF). https://www.semtech.com/uploads/technology/LoRa/predicting-lorawan-capacity.pdf  ↩︎ ↩︎ ↩︎ ↩︎

  9. RFC 8910. Captive-Portal Identification in DHCP and Router Advertisements. RFC Editor. https://www.rfc-editor.org/rfc/rfc8910  ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

  10. IETF CAPPORT Working Group. Documents and status (includes RFC 8908, 8910, 8952). https://datatracker.ietf.org/group/capport/  ↩︎ ↩︎ ↩︎

  11. Semtech. LoRa® and LoRaWAN® (white paper, PDF). https://www.semtech.com/uploads/technology/LoRa/lora-and-lorawan.pdf  ↩︎ ↩︎ ↩︎