Community Resilient Network

Guiding Developer: allytag
Project model: Open-source, hardware-backed community communications network
Primary objective: Maintain local communications and distribute available external connectivity across a geographic area during a total cellular or ISP blackout.
Contributor objective: Split the system into independently buildable hardware, firmware, networking, backend, Android, monitoring, and deployment modules.

---

1. Architecture

Satellite Backhaul A ───────────┐
                                │
Long-Range RF Backhaul B ───────┼── Edge Gateway Layer
                                │          │
Independent Backhaul C ─────────┘          │
                                           ▼
                              Routed Rooftop Backbone
                                  │        │        │
                                  ▼        ▼        ▼
                           District A  District B  District C
                                  │        │        │
                                  ▼        ▼        ▼
                             Wi-Fi APs  Wi-Fi APs  Wi-Fi APs
                                  │        │        │
                                  └──── Community Users ────┘

Additional planes:

Rooftop Backbone ── Local DNS / Messaging / Maps / Voice / Content Cache
LoRa Network ────── SOS / Text / Coordinates / Network Control
Phone DTN ───────── Store-Carry-Forward for disconnected local edges

The network is divided into five functional planes:

1. Backhaul plane — brings external connectivity into the area.
2. Backbone plane — moves traffic between rooftop and district nodes.
3. Access plane — provides standard Wi-Fi to user devices.
4. Local-service plane — keeps essential services available inside the network.
5. Emergency plane — carries small, high-priority messages over LoRa and delay-tolerant phone links.

---

Part I — Backhaul Plane

2. Multi-Gateway Design

Do not use one central Genesis Node. Deploy multiple active gateways at physically separated sites.

Gateway A: Satellite terminal at Site 1
Gateway B: Directional RF bridge at Site 2
Gateway C: Independent satellite, fibre, microwave, or other backhaul at Site 3

Each gateway contains:

• Backhaul modem or radio.
• Edge router.
• Local service replica.
• Routing daemon.
• Real connectivity health checker.
• Traffic-shaping service.
• Monitoring agent.
• Independent battery and power subsystem.

2.1 Backhaul Availability

For independent backhauls with individual availability $A_i$:

$$ A_{\text{backhaul}}

1-\prod_{i=1}^{n}(1-A_i) $$

For two backhauls with 95% availability:

$$ A_{\text{backhaul}}

1-(1-0.95)^2

99.75% $$

To account for a shared-site failure probability $q$:

$$ A_{\text{real}}

(1-q) \left[ 1-\prod_{i=1}^{n}(1-A_i) \right] $$

For:

$$ A_1=A_2=0.95,\qquad q=0.02 $$

$$ A_{\text{real}}

0.98\times0.9975

97.755% $$

The engineering implication is direct:

Backhaul diversity without site diversity is incomplete.

2.2 Active-Active Routing

All healthy gateways should advertise usable routes simultaneously.

A gateway route weight can be calculated as:

$$ W_g

\frac{ C_g \cdot R_g \cdot B_g }{ 1+\alpha L_g+\beta J_g+\gamma P_g } $$

where:

• $C_g$ = measured available capacity.
• $R_g$ = recent success ratio.
• $B_g$ = battery and power-health multiplier.
• $L_g$ = latency.
• $J_g$ = jitter.
• $P_g$ = packet-loss ratio.
• $\alpha,\beta,\gamma$ = tuning coefficients.

Traffic allocation across $k$ healthy gateways:

$$ x_g

\frac{W_g}{\sum_{i=1}^{k}W_i} $$

where $x_g$ is the fraction of new traffic assigned to gateway $g$.

2.3 Backhaul State Machine

Connectivity must not be represented as a Boolean.

DOWN
CAPTIVE
CONTROL_ONLY
DEGRADED
USABLE
SATURATED

A gateway becomes USABLE only after completing:

1. An authenticated control request.
2. A real upload probe.
3. A real download probe.
4. A server acknowledgement.
5. A latency and packet-loss measurement.

Suggested probe sizes:

Control probe: 256–1,024 bytes
Upload probe:  32–128 KB
Download probe: 32–128 KB

2.4 Route Withdrawal and Restoration

Withdraw a route when:

$$ F \geq F_{\max} $$

where $F$ is the number of consecutive failed authenticated probes.

Restore it only when:

$$ S \geq S_{\text{restore}} $$

and:

$$ t_{\text{healthy}}\geq T_{\text{hold}} $$

This hysteresis prevents route flapping.

Suggested initial values:

Probe interval:          5 seconds
Failure threshold:       3 consecutive failures
Restore threshold:       5 consecutive successes
Minimum healthy hold:   20 seconds

---

3. Long-Range Directional RF Bridge

A neighbouring area with connectivity can feed the network using a point-to-point directional radio bridge.

3.1 Free-Space Path Loss

For distance $d$ in kilometres and frequency $f$ in GHz:

$$ FSPL = 92.45+ 20\log_{10}(d_{\text{km}}) + 20\log_{10}(f_{\text{GHz}}) $$

For a 30 km link at 5.8 GHz:

$$ FSPL

92.45+ 20\log_{10}(30)+ 20\log_{10}(5.8) \approx137.3\text{ dB} $$

3.2 Link Budget

$$ P_{RX}

P_{TX} + G_{TX} + G_{RX}

FSPL

L $$

Example:

Transmit power:         23 dBm
Transmit antenna gain:  30 dBi
Receive antenna gain:   30 dBi
Cable/system losses:     4 dB

$$ P_{RX}

23+30+30-137.3-4

-58.3\text{ dBm} $$

Link margin:

$$ M=P_{RX}-S_{\text{required}} $$

If the selected modulation requires $-72\text{ dBm}$:

$$ M=-58.3-(-72)=13.7\text{ dB} $$

The project should define a minimum accepted fade margin before a link is commissioned.

Suggested target:

Minimum design margin: 15–25 dB

3.3 Fresnel Clearance

The first Fresnel-zone radius is:

$$ r_1 = 17.32 \sqrt{ \frac{d_1d_2}{fd} } $$

For:

$$ d_1=d_2=15\text{ km},\qquad d=30\text{ km},\qquad f=5.8\text{ GHz} $$

$$ r_1\approx19.7\text{ m} $$

Targeting 60% clearance:

$$ 0.6r_1\approx11.8\text{ m} $$

A deployment planner should generate:

• Terrain profile.
• Rooftop and tower-height requirement.
• Fresnel clearance plot.
• Estimated receive level.
• Estimated modulation.
• Fade margin.
• Expected usable throughput.

3.4 RF Bridge Commissioning Test

A link passes commissioning only when it meets all selected thresholds:

RSSI within design range
SNR above modulation threshold
Packet loss below threshold
Latency stable under load
Upload and download capacity verified
48-hour burn-in completed
Automatic failover tested

---

Part II — Rooftop Backbone

4. Hierarchical Routing

Do not place the entire city in one Layer-2 broadcast domain.

Use a hierarchy:

Layer 1: External backhaul sites
Layer 2: Directional rooftop backbone
Layer 3: District distribution nodes
Layer 4: Standard Wi-Fi access points

Recommended protocol split:

Between districts:       Layer-3 routing using Babel, OSPF, or IS-IS
Inside a small pod:      802.11s or batman-adv
User access:             Standard Wi-Fi AP mode
Emergency application:  Encrypted overlay

4.1 District Pod

A district pod is a bounded local mesh containing approximately:

3–20 rooftop nodes
1–3 local service replicas
1 or more district uplinks
Multiple user access points

Each pod should have its own:

• IP prefix.
• Routing area or metric boundary.
• DHCP service.
• Local DNS cache.
• Monitoring namespace.
• Traffic quota.
• Failure-isolation policy.

4.2 Rooftop Node Hardware

Preferred three-radio design:

Radio 1: Directional primary backbone
Radio 2: Alternate backbone or secondary path
Radio 3: Local user access

Recommended components:

• OpenWrt-capable router or small x86/ARM computer.
• Managed PoE switch.
• Directional backbone radios.
• Separate Wi-Fi access radio.
• Battery monitor.
• Solar or mains charge controller.
• Temperature sensor.
• Encrypted management interface.
• Weatherproof enclosure.
• Surge protection.
• Remote reset controller.

---

5. Backbone Capacity Mathematics

5.1 Same-Channel Multi-Hop Capacity

For physical goodput $R$ and $h$ interfering half-duplex hops:

$$ C_{\text{end-to-end}} \lesssim \frac{R}{h} $$

For:

$$ R=300\text{ Mbps},\qquad h=4 $$

$$ C_{\text{end-to-end}} \lesssim75\text{ Mbps} $$

Separate radios, directional antennas, separate channels, and spatial reuse are therefore primary design requirements.

5.2 Link Capacity Requirement

For every backbone link $l$:

$$ C_l \geq \Gamma \sum_{u\in D(l)} d_u $$

where:

• $D(l)$ = users or downstream nodes whose traffic crosses link $l$.
• $d_u$ = design bandwidth assigned to user or node $u$.
• $\Gamma$ = overhead and growth factor.

Suggested starting range:

$$ 1.3\leq\Gamma\leq2.0 $$

Links close to edge gateways must be provisioned for aggregate traffic from multiple districts.

5.3 Network Flow Model

Model the backbone as a directed graph:

$$ G=(V,E) $$

Each edge $e\in E$ has capacity $c_e$, latency $l_e$, and reliability $r_e$.

For each traffic demand $k$:

$$ 0\leq f_{k,e}\leq c_e $$

The aggregate capacity constraint is:

$$ \sum_k f_{k,e}\leq c_e $$

A contributor-built planning tool should solve:

• Shortest reliable path.
• Maximum flow.
• Link overload detection.
• Failure rerouting.
• Gateway balancing.
• District isolation.
• Capacity forecasting.

5.4 Routing Metric

A composite routing cost:

$$ M_e

a\frac{1}{c_e} + b l_e + c p_e + d j_e + e q_e $$

where:

• $c_e$ = usable link capacity.
• $l_e$ = latency.
• $p_e$ = packet-loss ratio.
• $j_e$ = jitter.
• $q_e$ = queue occupancy.
• $a,b,c,d,e$ = configurable weights.

---

Part III — Access Plane

6. User Wi-Fi

Users should connect through standard Wi-Fi without requiring a special mesh application.

Each access node should provide:

• Community SSID.
• Emergency-only SSID.
• Optional contributor/maintenance SSID.
• Client isolation where required.
• Rate limits.
• Captive information portal.
• Local service discovery.
• Automatic roaming support.

6.1 Capacity Planning

If total working external backhaul is $B$ and $N$ users are simultaneously active:

$$ \bar C_{\text{user}} \leq \frac{B}{N} $$

For:

$$ B=300\text{ Mbps},\qquad N=1{,}000 $$

$$ \bar C_{\text{user}}\leq300\text{ kbps} $$

A fair scheduler should allocate traffic by class rather than by unrestricted first-come-first-served demand.

6.2 Traffic Classes

Priority 1: SOS, emergency coordination, routing control
Priority 2: Text, critical APIs, authentication, signalling
Priority 3: Compressed photos, documents, maps
Priority 4: Ordinary web access
Priority 5: Large downloads and video

Suggested weighted scheduler:

$$ w_1>w_2>w_3>w_4>w_5 $$

Example weights:

Priority 1: 100
Priority 2:  50
Priority 3:  20
Priority 4:   5
Priority 5:   1

6.3 Per-User Rate Allocation

Let:

• $B_c$ = capacity assigned to class $c$.
• $N_c$ = active users in class $c$.

Then:

$$ R_{u,c}

\min \left( R_{c,\max}, \frac{B_c}{N_c} \right) $$

This protects emergency services while retaining predictable access for ordinary users.

---

Part IV — Local-Service Plane

7. Services Available Inside the Network

Deploy local replicas so common traffic remains inside the community network.

Required services:

• Local DNS resolver.
• Emergency information portal.
• Local messaging server.
• Offline map server.
• File and document exchange.
• Content cache.
• Local authentication.
• Local status dashboard.
• Voice or push-to-talk signalling.
• Device and node update mirror.
• Monitoring and alerting.

7.1 Local DNS

Each district should operate a recursive or caching resolver.

Recommended design:

Client
  │
  ▼
District DNS Cache
  │
  ├── Local service zone
  ├── Cached public records
  └── Upstream resolver through any healthy gateway

Local service names should resolve independently of external DNS.

Example:

portal.community
maps.community
chat.community
status.community
voice.community
files.community

7.2 Local Service Replication

For service $s$, place replicas in multiple districts.

A basic replica placement score:

$$ R_{s,v}

aD_v + bC_v + cP_v + dN_v $$

where:

• $D_v$ = demand near node $v$.
• $C_v$ = compute and storage capacity.
• $P_v$ = power availability.
• $N_v$ = network centrality.

Select nodes with the highest score while enforcing physical separation.

7.3 Data Synchronization

Use eventual consistency for non-transactional community services.

Recommended model:

Local writes
→ append-only event log
→ replicated between district servers
→ conflict resolution
→ compressed backhaul synchronization

Every event should contain:

Event ID
Origin node
Logical timestamp
Object type
Operation type
Content hash
Encrypted payload
Signature
Expiry policy

---

Part V — LoRa Emergency Plane

8. Purpose

LoRa is used for:

• SOS messages.
• Short text.
• GPS coordinates.
• Node-health reports.
• Network-control alerts.
• Backhaul-status summaries.
• Store-and-forward emergency communication.

It is not used for normal web traffic or media transfer.

8.1 Geometric Coverage Estimate

For city area $A$ and reliable effective radius $r$:

$$ N_{\min} \geq \frac{A}{\pi r^2} $$

For:

$$ A=300\text{ km}^2,\qquad r=1\text{ km} $$

$$ N_{\min} \geq \frac{300}{\pi} \approx96 $$

Introduce a deployment multiplier $k$ for overlap, terrain, indoor coverage, and node redundancy:

$$ N_{\text{deploy}}

kN_{\min} $$

Suggested planning range:

$$ 2\leq k\leq4 $$

Therefore:

$$ 192\leq N_{\text{deploy}}\leq384 $$

for the example planning assumptions.

8.2 Airtime Budget

For an airtime allowance $D$ per hour and packet airtime $t_p$:

$$ N_{\text{tx}} \leq \frac{D}{t_p} $$

For a 1% airtime budget:

$$ D=36\text{ seconds/hour} $$

Example packet airtime:

SF7:  approximately 61 ms
SF10: approximately 371 ms

Then:

$$ N_{\text{SF7}} \leq \frac{36}{0.061} \approx590 $$

$$ N_{\text{SF10}} \leq \frac{36}{0.371} \approx97 $$

These values must be reduced for:

• Acknowledgements.
• Retransmissions.
• Routing overhead.
• Collisions.
• Longer payloads.
• Control packets.

8.3 Controlled Replication

If every message is forwarded by $m$ relay nodes:

$$ N_{\text{delivered}} \lesssim \frac{N_{\text{radio}}}{m+1} $$

Use controlled replication instead of universal flooding.

Recommended controls:

• Unique message IDs.
• Duplicate suppression.
• Hop limits.
• Expiry time.
• Priority queues.
• Selective acknowledgements.
• Relay quotas.
• Neighbour-quality scoring.
• Scheduled transmission windows.
• Store-carry-forward.

8.4 LoRa Packet Format

Version                 1 byte
Message type            1 byte
Flags                    1 byte
Sender ID                4 bytes
Sequence number          3 bytes
Timestamp                4 bytes
Latitude/longitude       8 bytes
Hop count                1 byte
Expiry                    2 bytes
Payload                  24–64 bytes
Authentication tag       8–16 bytes

Typical packet size:

$$ 57\text{ to }105\text{ bytes} $$

8.5 Message Classes

0x01  SOS
0x02  Position update
0x03  Short text
0x04  Network status
0x05  Node health
0x06  Gateway availability
0x07  Acknowledgement
0x08  District announcement

8.6 Relay Score

For relay candidate $v$:

$$ S_v

aQ_v + bE_v + cH_v

dL_v

eU_v $$

where:

• $Q_v$ = link quality.
• $E_v$ = remaining energy.
• $H_v$ = estimated progress toward destination.
• $L_v$ = recent packet loss.
• $U_v$ = channel utilization.

Only the highest-scoring eligible relays should forward a packet.

---

Part VI — Phone Delay-Tolerant Network

9. Phone Role

Phones can extend connectivity beyond fixed nodes through:

• Wi-Fi Aware.
• Nearby Connections.
• Bluetooth Low Energy discovery.
• Store-carry-forward.
• Local SOS.
• Opportunistic synchronization.

The phone network is an edge extension, not the principal backbone.

9.1 DTN Message Envelope

{
  "messageId": "256-bit-random-id",
  "senderPublicKey": "base64-key",
  "destination": "user-or-channel",
  "createdAt": 1784540000,
  "expiresAt": 1784543600,
  "priority": 1,
  "hopLimit": 8,
  "contentHash": "sha256",
  "payload": "encrypted-data",
  "signature": "digital-signature"
}

9.2 Store-Carry-Forward Exchange

When two phones connect:

1. Exchange protocol versions.
2. Exchange compact inventories of message IDs.
3. Identify missing messages.
4. Prioritize SOS and control messages.
5. Transfer encrypted payloads.
6. Verify hashes and signatures.
7. Store valid messages.
8. Forward according to replication budget.
9. Delete expired content.

9.3 Spray-and-Wait

Each message receives a replication budget $L$.

Binary spray:

$$ L_{\text{sender}}\rightarrow \left\lfloor\frac{L}{2}\right\rfloor + \left\lceil\frac{L}{2}\right\rceil $$

When a node has one remaining copy, it waits for:

• The destination.
• A fixed access point.
• A verified internet gateway.
• An authorized collector.

9.4 Media Chunking

For a file of size $F$ and chunk size $c$:

$$ n= \left\lceil \frac{F}{c} \right\rceil $$

Each chunk contains:

File ID
Chunk index
Total chunks
Chunk hash
File root hash
Payload

Chunk size should satisfy:

$$ c \leq \eta G t_c $$

where:

• $G$ = measured local-link goodput.
• $t_c$ = conservative contact duration.
• $\eta$ = safety factor.

9.5 Erasure Coding

For an $(n,k)$ erasure code, any $k$ valid shards reconstruct the file.

Decode probability:

$$ P_{\text{decode}}

\sum_{i=k}^{n} \binom{n}{i} p^i(1-p)^{n-i} $$

where $p$ is the estimated independent shard-arrival probability.

The encoder should dynamically choose $n$ and $k$ from:

• Contact reliability.
• Number of available peers.
• File priority.
• Storage budget.
• Delivery deadline.
• Network congestion.

---

Part VII — Power System

10. Rooftop Power Mathematics

Assume:

Router and CPU:         8 W
Backbone radio:         8 W
Access radio:           6 W
Losses and auxiliaries: 3 W
Total:                 25 W

Daily energy:

$$ E_d

25\times24

600\text{ Wh/day} $$

For two days of battery autonomy and 80% usable depth:

$$ E_b

\frac{600\times2}{0.8}

1{,}500\text{ Wh} $$

With four peak-sun-hours and 70% total system efficiency:

$$ P_{\text{solar}} \geq \frac{600}{4\times0.7} \approx214\text{ W} $$

Suggested initial node design:

Solar panel:       250–300 W
Battery:           1.5–2.0 kWh
Charge controller: MPPT
Power output:      Regulated PoE
Protection:        Low-voltage cutoff
Monitoring:        Voltage, current, temperature, state of charge

10.1 Power-Aware Routing

Let:

• $b_v$ = battery state of charge.
• $s_v$ = solar charging state.
• $p_v$ = node power draw.

Power-health multiplier:

$$ H_v

w_b b_v + w_s s_v

w_p p_v $$

A node with low projected runtime should gradually increase its routing cost before shutdown.

Estimated runtime:

$$ T_v

\frac{E_{\text{remaining}}}{P_{\text{average}}} $$

---

Part VIII — Security Architecture

11. Identity

Every infrastructure node has:

• A unique node ID.
• A long-term signing key.
• A transport encryption key.
• A hardware or encrypted-software key store.
• A certificate signed by the community root.
• A revocation status.

11.1 Trust Layers

Root authority
  ├── Infrastructure-node certificates
  ├── Operator certificates
  ├── Service certificates
  └── Emergency-authority signing certificates

11.2 Message Protection

Use:

• Authenticated encryption for payload confidentiality and integrity.
• Digital signatures for authority announcements.
• Replay protection using sequence numbers and timestamps.
• Content hashes for chunks and files.
• Key rotation.
• Certificate revocation.
• Rate limiting per identity.
• Device enrollment with approval.

11.3 Routing Protection

Routing updates should include:

Origin node
Sequence number
Timestamp
Route metric
Expiry
Signature

Nodes must reject:

• Invalid signatures.
• Old sequence numbers.
• Expired advertisements.
• Impossible metric jumps.
• Duplicate route updates.
• Unknown infrastructure identities.

---

Part IX — Monitoring and Operations

12. Metrics

Every infrastructure node should export:

CPU and memory
Device temperature
Battery voltage
Battery current
State of charge
Solar input
Backhaul state
Upload goodput
Download goodput
Latency
Jitter
Packet loss
Queue depth
Connected clients
Per-class bandwidth
Routing neighbours
Route changes
LoRa airtime
LoRa retries
Local-service health
Storage usage

12.1 Gateway Quality

A conservative gateway score:

$$ U_g

p_g^- \cdot \frac{\log(1+G_g)} {(1+r_g/r_0)(1+l_g)} \cdot e^{-\lambda_a a_g} \cdot B_g $$

where:

• $p_g^-$ = conservative lower bound on probe success.
• $G_g$ = measured goodput.
• $r_g$ = round-trip latency.
• $l_g$ = loss ratio.
• $a_g$ = age of last successful test.
• $B_g$ = power-health multiplier.

12.2 Alert Classes

Critical: no district route, local service failure, battery near shutdown
High: backhaul degraded, backbone link loss, storage nearly full
Medium: rising packet loss, gateway saturation, elevated temperature
Low: software update available, capacity trend warning

12.3 Network Dashboard

The dashboard should display:

• Topology graph.
• Healthy and unhealthy links.
• Active gateway capacities.
• District user counts.
• Traffic by priority.
• Battery-runtime estimates.
• LoRa utilization.
• Local-service status.
• Historical reliability.
• Predicted capacity shortfalls.

---

Part X — Open-Source Project Structure

13. Repository Layout

community-resilient-network/
├── README.md
├── LICENSE
├── CONTRIBUTING.md
├── CODE_OF_CONDUCT.md
├── SECURITY.md
├── docs/
│   ├── architecture.md
│   ├── deployment-guide.md
│   ├── radio-planning.md
│   ├── power-planning.md
│   ├── routing.md
│   ├── security-model.md
│   ├── testing.md
│   └── bill-of-materials.md
├── firmware/
│   ├── openwrt/
│   ├── lora-node/
│   └── power-controller/
├── routing/
│   ├── gateway-health/
│   ├── route-controller/
│   ├── babel-config/
│   └── district-planner/
├── services/
│   ├── local-dns/
│   ├── emergency-portal/
│   ├── messaging/
│   ├── maps/
│   ├── voice/
│   └── content-cache/
├── mobile/
│   └── android-dtn/
├── backend/
│   ├── probe-server/
│   ├── synchronization/
│   └── identity/
├── monitoring/
│   ├── exporters/
│   ├── dashboards/
│   └── alerts/
├── simulation/
│   ├── topology/
│   ├── capacity/
│   ├── lora-airtime/
│   └── availability/
├── hardware/
│   ├── rooftop-node/
│   ├── gateway-site/
│   ├── lora-node/
│   └── power-system/
└── tests/
    ├── laboratory/
    ├── field/
    ├── failover/
    └── performance/

---

14. Contributor Workstreams

Workstream A — Gateway Health Engine

Build:

• Authenticated upload/download probes.
• Gateway state machine.
• Route withdrawal API.
• Route restoration hysteresis.
• Capacity and reliability scoring.
• Active-active traffic weights.

Acceptance criteria:

• Detects a failed path within the configured threshold.
• Does not mark a network healthy from ping alone.
• Withdraws unusable routes.
• Restores routes without rapid flapping.
• Exposes machine-readable metrics.

Workstream B — RF Planning Tool

Build a tool that accepts:

Site coordinates
Site elevations
Tower heights
Frequency
Transmit power
Antenna gains
Cable losses
Receiver sensitivity
Required fade margin

Outputs:

• Distance.
• FSPL.
• Fresnel-zone radius.
• Required clearance.
• Estimated receive level.
• Link margin.
• Pass/fail result.
• Human-readable report.

Workstream C — Rooftop Routing Image

Build an OpenWrt image containing:

• Babel or OSPF.
• 802.11s or batman-adv for local pods.
• VLAN support.
• Traffic shaping.
• Health monitoring.
• Secure remote management.
• Automatic configuration backup.
• Signed update support.

Workstream D — District Services

Build containerized local services:

• DNS.
• Emergency portal.
• Messaging.
• Offline maps.
• File exchange.
• Status dashboard.
• Voice signalling.

Each service should run without external internet access.

Workstream E — LoRa Emergency Network

Build:

• Compact binary packet protocol.
• Duplicate suppression.
• Controlled relay selection.
• Hop limits.
• Priority queues.
• Acknowledgements.
• Node-health telemetry.
• Phone-to-radio Bluetooth interface.
• Gateway bridge to local messaging.

Workstream F — Android DTN Application

Build:

• Wi-Fi Aware transport.
• Nearby Connections fallback.
• BLE discovery fallback.
• Store-carry-forward database.
• Message signing and encryption.
• Spray-and-Wait routing.
• Chunked media transfer.
• Fixed-node synchronization.
• Local SOS workflow.

Workstream G — Power Controller

Build firmware and hardware interfaces for:

• Battery voltage.
• Battery current.
• Solar current.
• Temperature.
• State-of-charge estimation.
• Low-voltage cutoff.
• Remote power cycling.
• Routing-cost adjustment based on runtime.

Workstream H — Network Simulator

Build a simulator that models:

• Geographic node placement.
• Backbone capacities.
• Gateway availability.
• District demand.
• Link failures.
• Multi-path rerouting.
• LoRa airtime.
• Battery runtime.
• Phone mobility.
• DTN message delivery probability.

---

Part XI — Development Milestones

15. Phase 0 — Specification

Deliverables:

• Architecture document.
• Packet formats.
• Routing interfaces.
• Gateway health API.
• Security model.
• Initial bill of materials.
• Simulation assumptions.
• Contributor guidelines.

16. Phase 1 — Laboratory Network

Build:

2 edge gateways
4 rooftop nodes
2 district pods
4 Wi-Fi access points
5 LoRa nodes
3 Android test phones
1 local-service server

Tests:

• Gateway failover.
• Route reconvergence.
• Local DNS continuity.
• Priority traffic shaping.
• LoRa text delivery.
• DTN message exchange.
• Battery telemetry.

17. Phase 2 — Neighbourhood Pilot

Build:

2 physically separated backhauls
10–20 rooftop nodes
3–5 district pods
20–50 LoRa nodes
Local service replicas
Public test access

Measure:

• Coverage.
• Capacity.
• Latency.
• Packet loss.
• User concurrency.
• Gateway balancing.
• Power runtime.
• Route stability.
• LoRa airtime.
• DTN delivery delay.

18. Phase 3 — Multi-District Deployment

Add:

• Hierarchical Layer-3 routing.
• Multiple service replicas.
• Automated provisioning.
• Central and district monitoring.
• Signed software updates.
• Capacity forecasting.
• RF planning automation.
• Contributor deployment toolkit.

19. Phase 4 — Reproducible Community Kit

Publish:

• Hardware reference designs.
• OpenWrt images.
• LoRa firmware.
• Android application.
• Deployment calculator.
• Power-sizing calculator.
• RF link calculator.
• Network simulation templates.
• Test procedures.
• Operator handbook.
• Contributor onboarding guide.

---

Part XII — Testing Matrix

20. Functional Tests

Test	Expected Result
One gateway becomes unavailable	New flows use remaining gateways
One rooftop link fails	Routing converges to an alternate path
One district loses external routes	Local district services remain reachable
External DNS is unavailable	Local community names continue resolving
Backhaul becomes saturated	Priority traffic remains responsive
Access point restarts	Clients reconnect to overlapping coverage
LoRa relay disappears	Alternate relays deliver eligible messages
Phone disconnects mid-transfer	Chunk transfer resumes from verified state
Battery state falls	Node routing cost increases before shutdown
Local server restarts	Replicated services restore state

21. Performance Tests

Measure:

Backhaul goodput
Backbone goodput
Per-hop capacity
Routing convergence time
Gateway failover time
Wi-Fi client capacity
Latency by traffic class
LoRa packet delivery ratio
LoRa airtime consumption
DTN delivery probability
Media reconstruction probability
Battery runtime
Solar recharge time

22. Acceptance Targets

Initial targets for the pilot:

Gateway failure detection:       ≤ 20 seconds
Backbone route reconvergence:    ≤ 10 seconds
Local DNS response:              ≤ 100 ms
Local messaging response:        ≤ 500 ms
Priority-1 packet queue delay:   ≤ 1 second under planned load
LoRa SOS delivery probability:   ≥ 95% within the pilot coverage model
Service replica recovery:        ≤ 60 seconds
Node battery autonomy:           ≥ 48 hours at planned load
Monitoring visibility:           100% of infrastructure nodes

Targets should be configured by deployment profile and verified through reproducible tests.

---

Part XIII — Contributor Interfaces

23. Gateway Health API

Example response:

{
  "gatewayId": "gw-site-01",
  "state": "USABLE",
  "capacityDownMbps": 180.5,
  "capacityUpMbps": 35.2,
  "latencyMs": 84,
  "jitterMs": 12,
  "packetLoss": 0.008,
  "batteryPercent": 86,
  "estimatedRuntimeMinutes": 1320,
  "routeWeight": 0.74,
  "lastValidatedAt": "2026-07-20T10:30:00Z"
}

24. Node Health API

{
  "nodeId": "roof-district-a-07",
  "neighbours": 3,
  "clientCount": 42,
  "cpuPercent": 27,
  "temperatureC": 54,
  "batteryPercent": 78,
  "solarWatts": 148,
  "routes": 18,
  "queueDepth": {
    "priority1": 2,
    "priority2": 6,
    "priority3": 14,
    "priority4": 30,
    "priority5": 9
  }
}

25. LoRa Message Schema

message_version
message_type
message_id
sender_id
sequence_number
created_at
expires_at
priority
hop_limit
payload
authentication_tag

26. Android Transport Interface

interface MeshTransport {
    suspend fun startDiscovery()
    suspend fun stopDiscovery()
    suspend fun connect(peerId: String)
    suspend fun disconnect(peerId: String)
    suspend fun send(peerId: String, payload: ByteArray): TransferResult
    fun observePeers(): kotlinx.coroutines.flow.Flow<List<MeshPeer>>
    fun observeIncoming(): kotlinx.coroutines.flow.Flow<IncomingPacket>
}

Implementations:

WifiAwareTransport
NearbyConnectionsTransport
BleDiscoveryTransport
FixedAccessPointTransport

---

Part XIV — Build Principles

27. Engineering Rules

1. Every critical service must have more than one eligible host.
2. Every external route must be actively verified.
3. User access and backbone transport should use separate radios.
4. City-scale routing should be Layer 3.
5. Layer-2 mesh domains should remain bounded.
6. Local services should continue without external connectivity.
7. Emergency traffic must have explicit priority.
8. LoRa forwarding must be controlled.
9. Phone DTN messages must be encrypted, signed, deduplicated, and expiring.
10. Power state must influence routing.
11. Monitoring must be designed before field deployment.
12. Every module must have reproducible tests.
13. Hardware profiles must be replaceable.
14. Protocols and data formats must be publicly documented.
15. Contributor work should remain modular and interoperable.

---

28. Recommended Initial Technology Stack

Rooftop firmware:       OpenWrt
District routing:       Babel or OSPF
Local pod mesh:         802.11s or batman-adv
Service runtime:        Containers on Linux
Monitoring:             Prometheus-compatible metrics
Dashboards:             Grafana-compatible dashboards
Backend services:       Go, Rust, Java/Kotlin, or TypeScript
Android application:    Kotlin
Local database:         SQLite/Room
Cryptography:           Well-reviewed modern libraries
LoRa firmware:          C/C++ or Rust
Simulation:             Python plus graph/network libraries
Configuration:          YAML or JSON with schema validation
Automation:             Ansible or equivalent reproducible provisioning

---

29. Project Leadership

allytag acts as the guiding Developer for the project.

The guiding Developer is responsible for:

• Maintaining the reference architecture.
• Defining stable protocol interfaces.
• Reviewing major design changes.
• Coordinating contributor workstreams.
• Approving compatibility requirements.
• Maintaining milestone priorities.
• Ensuring modules remain independently testable.
• Publishing reference deployments.
• Keeping build and deployment documentation current.

Contributors can independently own:

• Firmware.
• Hardware design.
• Routing.
• Android development.
• Backend services.
• LoRa networking.
• Security.
• Monitoring.
• Simulation.
• Documentation.
• Field testing.
• Deployment automation.

---

30. First Contributor Tasks

Good first issues:

1. Implement the FSPL and Fresnel calculator.
2. Define the gateway health JSON schema.
3. Build a mock authenticated probe server.
4. Create an OpenWrt package list for a rooftop node.
5. Build a topology simulator for ten nodes.
6. Define the compact LoRa packet serializer.
7. Implement message-ID duplicate suppression.
8. Create the Android MeshTransport interface.
9. Build a battery-runtime calculator.
10. Create a local emergency portal prototype.
11. Define Prometheus metrics for gateways.
12. Write the laboratory failover test procedure.
13. Create a reproducible bill-of-materials template.
14. Build a district IP-address planning tool.
15. Write contribution and code-review guidelines.

---

31. Project Success Definition

The open-source project succeeds when an independent contributor group can reproduce a pilot network from public documentation and demonstrate:

Multiple active backhauls
Automatic gateway selection
Automatic route withdrawal and restoration
Routed rooftop connectivity
Standard Wi-Fi user access
Local services
Priority traffic handling
LoRa emergency messaging
Phone-based DTN exchange
Battery and solar telemetry
Live network monitoring
Documented reproducible tests

---

32. Summary Architecture

2–3 independent backhauls
+ physically separated gateway sites
+ active-active route selection
+ directional multi-radio Layer-3 rooftop backbone
+ bounded 802.11s or batman-adv district pods
+ standard Wi-Fi access for phones
+ local DNS, messaging, maps, voice, and content services
+ controlled low-bandwidth LoRa emergency plane
+ solar and battery-powered infrastructure
+ optional Android delay-tolerant edge mesh
+ monitoring, simulation, and reproducible deployment tooling

This document is the contributor-facing technical blueprint for the Community Resilient Network guided by allytag.