How the planner decides
The volume calculation is deliberately simple: sites × reports per day × payload bytes × 30 ÷ 1,000,000 gives raw decimal megabytes per 30-day month. Protocol headers, retries, health payloads, backfill and encryption overhead are not included, so use the result for order-of-magnitude planning rather than a carrier bill.
The selector gives field-proven cellular LPWA first consideration because it avoids owning private radio infrastructure. If cellular is unknown or poor and sites are clustered, it recommends testing private LoRaWAN plus gateway/backhaul. Dispersed sites with no proven terrestrial path move toward satellite or store-and-forward evaluation. Alert latency changes how aggressively to evaluate wide-area real-time paths versus delayed collection.
| Input | Meaning | What it does not prove |
|---|---|---|
| Sites / reports / bytes | Raw application volume | Carrier payload accounting or energy use |
| Topology | Whether shared gateways may be efficient | Radio line-of-sight or exact gateway count |
| Cellular field state | Whether installed end-to-end cellular has been tested | Future operator coverage or roaming |
| Alert delay | Operational latency requirement | Response staffing or repair SLA |
Use the result as a pilot brief
Take the recommendation to representative strong, median and difficult sites. Test the complete installed path: antenna inside the final enclosure, device firmware and network profile, backend ingest and alert delivery. Record delivery latency as a distribution rather than one successful packet, then force a communications outage to verify buffering and recovery.
For private LoRaWAN, include gateway power, placement and backhaul in the same acceptance test. For cellular, verify the exact band/profile/SIM arrangement and weak-signal retry behavior. For satellite, include sky view, antenna constraints, energy per message and payload/latency cost in the comparison.
- Save the calculated raw monthly volume and add an explicit overhead/retry factor for commercial estimates.
- Pilot at least one difficult site rather than validating only the easiest location.
- Record who owns shared infrastructure such as gateways, backhaul and SIM/eSIM lifecycle.
- Do not call a technology “available” until the installed device has delivered data end-to-end.
Method, assumptions and limitations
Version: 2026-08-23. The logic is a transparent planning heuristic derived from common remote-monitoring architecture constraints and current GSMA/LoRaWAN deployment guidance; it is not a vendor ranking. Local spectrum rules, operator support, tariffs, terrain, antenna design, payload overhead and equipment certifications can change the correct answer.
No values leave the browser. The calculator runs entirely in this page and asks for no personal or site-identifying information. Refresh the page to reset it.
Sources and limits
Use these references to verify the underlying guidance. Local regulations, operator coverage and manufacturer instructions can change the correct implementation.
- GSMA Mobile IoT Deployment Guidelines (2026)GSMA highlights network configuration, interoperability, roaming, coverage and power-saving features such as PSM and eDRX for NB-IoT and LTE-M deployments.
- GSMA Mobile IoT Deployment Map (updated 2026)A current map for checking commercial NB-IoT and LTE-M availability by country before field design.
- LoRa Alliance: LoRaWAN for utilitiesLoRaWAN utility deployments illustrate the private-gateway model for low-power sensor fleets, including water metering use cases.
- 3GPP standards for IoT overview3GPP introduced NB-IoT and related cellular IoT features for low data-rate, extended-coverage and low-power applications; real deployment details still need operator-specific validation.