What this planner does
Community mesh networks provide decentralized connectivity by linking many small nodes (often rooftop or window-mounted radios) into a cooperative network. Two questions come up in almost every deployment: (1) will the shared backhaul be large enough during peak usage, and (2) will the network stay online when the grid is unreliable? This single-page planner estimates peak demand, backhaul utilization, effective uptime with battery/solar support, and a simple latency risk signal. Use it for early-stage sizing, grant narratives, and “what-if” conversations with node hosts and partners.
How to use the calculator
- Enter your current network size: set Active mesh nodes and Households served per node to estimate total households served.
- Estimate peak demand: enter Average bandwidth per household during peak (Mbps). This is a planning value (not a speed test). If you have no data, start with 3–8 Mbps per household for peak-hour planning and refine later.
- Enter shared backhaul capacity: add up the usable capacity of your uplinks (fiber, fixed wireless, microwave). If capacity is bursty or shared with other services, use a conservative number.
- Model reliability: set Average node uptime without backup (%), then add Battery backup hours, Solar-assisted hours per day, and Projected grid outage days per year.
- Plan for adoption: enter Expected household growth over three years (%) to see how quickly utilization can exceed capacity.
- Check latency risk: set a Target latency (ms) and Average added latency per mesh hop (ms). The model approximates hop count as √(nodes) to represent a moderately connected mesh.
- Click “Evaluate Network Resilience” to generate a plain-language summary you can paste into planning notes.
Units matter: bandwidth is in Mbps, time is in hours and days, and uptime is a percentage. All inputs must be zero or positive numbers; baseline uptime cannot exceed 100%.
Model overview (what the script calculates)
The calculator treats peak demand as simultaneous household usage (a conservative assumption). It compares that demand to your shared backhaul to estimate utilization. For uptime, it starts with baseline uptime and then adds a backup contribution based on how many outage hours can be covered by batteries and solar. For latency, it estimates a representative hop count and multiplies by your per-hop latency. The output is intentionally readable: it highlights congestion risk, growth pressure, backup coverage, and whether latency meets your target.
Formulas used (planning-level)
- Total households: Households = Nodes × HouseholdsPerNode
- Peak demand (Mbps): PeakDemand = Households × DemandPerHousehold
- Backhaul utilization: Utilization = PeakDemand ÷ BackhaulCapacity
- Outage hours per year: OutageHours = OutageDays × 24
- Backup coverage hours (simplified): BatteryCoverage = Events × BatteryHours; SolarCoverage = OutageDays × SolarHours; BackupCoverage = BatteryCoverage + SolarCoverage
- Adjusted uptime (%): AdjustedUptime = min(100, BaseUptime + (BackupCoverage ÷ OutageHours) × 100)
- Latency estimate (ms): AverageHops ≈ √(Nodes); EstimatedLatency = AverageHops × HopLatency
Worked example (using the default inputs)
With 24 nodes and 18 households per node, the network serves about 432 households. At 6.5 Mbps peak demand per household, peak demand is roughly 2,808 Mbps. If shared backhaul is 950 Mbps, utilization is about 295%, meaning the backhaul will be saturated during peak periods unless you add uplinks or manage demand.
For reliability, baseline uptime is 93.5%. With 7 outage days per year, that’s 168 outage hours. The script approximates outage events as round(outageDays) (minimum 1 when outageDays > 0), then adds battery coverage (6 hours per event) plus solar coverage (4 hours/day during outages). It converts that coverage into an added uptime percentage and caps the result at 100%.
For latency, √24 ≈ 4.9 hops. At 8 ms per hop, estimated latency is about 39 ms. With a 60 ms target, the model indicates you have headroom—though real-world latency can rise with congestion.
Reference tables (illustrative scenarios)
The tables below are examples to help teams discuss tradeoffs. They are not directly tied to the live calculation output, but they reflect common planning patterns. Use them as conversation starters when comparing backhaul upgrades, demand management, and backup power investments.
Comparison table: network sizing snapshots
| Network scenario | Active nodes | Households/node | Backhaul capacity (Mbps) | Effective uptime (%) | Bandwidth headroom (Mbps) | Estimated latency (ms) |
|---|---|---|---|---|---|---|
| Small community | 12 | 15 | 600 | 95 | 150 | 50 |
| Medium community (example) | 24 | 18 | 950 | 94 | -1858 | 84 |
| Large community | 40 | 20 | 2000 | 92 | 400 | 100 |
Scenario table: bandwidth strategies
| Scenario | Backhaul (Mbps) | Peak demand (Mbps) | Utilization | Action |
|---|---|---|---|---|
| Current state | 950 | 2,808 | 295% | Add uplinks urgently |
| Fiber partnership | 2,400 | 2,808 | 117% | Still limit bandwidth |
| Bandwidth management | 950 | 1,728 | 182% | Implement quality-of-service |
| Full upgrade | 3,600 | 2,808 | 78% | Future-proofed |
Power resilience table: backup coverage options
| Backup strategy | Battery hours | Solar hours | Outage coverage | Notes |
|---|---|---|---|---|
| Baseline | 6 | 4 | 31% | Matches example |
| Battery swap program | 10 | 4 | 44% | Requires volunteer rotation |
| Solar microgrid | 6 | 10 | 47% | Pairs with resilience hubs |
| Combined upgrade | 10 | 10 | 60% | Approaches full coverage |
Limitations and assumptions
- Peak demand is conservative: the model assumes simultaneous household usage at the entered peak Mbps. Real usage varies by time of day and application mix.
- Backhaul is treated as a single pool: it does not model per-uplink routing, contention, or failover behavior.
- Radio performance is not simulated: interference, modulation rate changes, antenna alignment, foliage, and weather can reduce throughput.
- Latency is simplified: per-hop latency can change with congestion, routing protocol behavior, encryption overhead, and queueing.
- Backup power is simplified: battery degradation, inverter losses, temperature effects, and solar variability are not modeled.
- Outage “events” are approximated: the script uses a rounded outage-day count to estimate how many times batteries are needed. This is a planning shortcut.
- Use as a starting point: validate with field measurements, monitoring data, and site surveys before procurement or final engineering decisions.
Frequently asked questions
How can I improve network uptime?
Increase battery backup duration, add solar-assisted hours, and reduce grid outage impact by prioritizing critical nodes (gateways, relay sites, and resilience hubs). Preventive maintenance and reliable hardware also matter.
What does negative bandwidth headroom mean?
It means peak demand exceeds backhaul capacity. Users may see buffering, slow downloads, and unstable video calls. Options include adding uplinks, shaping traffic, or lowering the assumed peak Mbps per household if your real measurements support it.
How does household growth affect the network?
Growth increases peak demand and can push utilization above 100% even if the network feels “fine” today. Planning for growth helps avoid emergency upgrades and improves reliability during community events or disasters.
Why is latency important in mesh networks?
Latency affects interactive applications like voice, video, telehealth, and remote learning. Even if bandwidth is adequate, high latency can make the network feel unresponsive.
Can I use this planner for commercial networks?
It’s designed for community mesh planning and intentionally simplifies many engineering details. Commercial deployments typically require RF planning, redundancy modeling, and SLA-driven capacity design.
How accurate are the uptime estimates?
They depend on your inputs and the simplified backup model. Treat the result as a directional estimate and refine it with outage logs, battery tests, and monitoring data.
Related tools for community infrastructure planning: resilience hub backup power coverage calculator, mutual aid fund runway calculator, community solar allocation balancer, community EV carshare reserve calculator.