LoRa vs Cellular vs Wi-Fi: Choosing Connectivity Like an Operator, Not an Engineer

Author: Srihari Maddula  •  Founder & Technical Lead, Eurth Techtronics Pvt Ltd

Category: Connectivity (BLE, Wi-Fi, LoRa)  •  Estimated Reading Time: 18–20 minutes

Published: April 2025

The Wrong Starting Point

Most connectivity decisions in embedded IoT development begin in the wrong place. They begin with the engineer's familiarity. The team has shipped three products with a cellular module. They reach for cellular again. A developer has spent two weeks getting a LoRa gateway running on a previous project. LoRa goes on the shortlist before the deployment requirements are written. The Wi-Fi stack is already in the microcontroller. Why not use it?

This is not negligence. It is a natural consequence of how engineering decisions are made under time pressure — with cognitive resources allocated to the hard problems, and with connectivity treated as a solved problem because it was solved before. The result is a connectivity choice that is defensible in terms of engineering familiarity, and frequently indefensible in terms of what the deployment actually requires.

Operators — the businesses and individuals who deploy, maintain, and pay for IoT systems in the field — evaluate connectivity differently from engineers. They do not think in terms of protocol specifications, modulation schemes, or gateway throughput. They think in terms of monthly recurring cost per node, maintenance burden per site visit, system uptime across their geography, and the total number of years before the system needs to be replaced. These are the dimensions that determine whether an IoT deployment survives its first year of operation and scales to its intended footprint.

This article builds a decision framework that bridges both perspectives — the engineer's need for protocol-level understanding and the operator's requirement that the system work economically in the real world. It defines the eight dimensions that should govern any connectivity decision, maps each of the three major protocols against those dimensions, and provides a scorecard that applies the framework to concrete deployment conditions. The goal is not to declare a winner. It is to give engineers the vocabulary and structure to make the correct choice for each deployment — rather than the most familiar one.

Section 1: Why 'Which Protocol Is Best?' Is the Wrong Question

1.1 — The Protocol Is a Consequence, Not a Starting Point

The question 'which connectivity protocol should we use?' assumes that connectivity is a variable to be optimised in isolation. It is not. Connectivity is one element of a system whose constraints are defined by the deployment environment, the application requirements, the operational model, and the economic structure of the deployment. The correct protocol is the one that satisfies those constraints most effectively — and that answer is different for different deployments, sometimes dramatically so.

A sparse agricultural sensor network covering fifty square kilometres of rural terrain, with five hundred nodes running on primary batteries, transmitting twelve bytes of sensor data every fifteen minutes, operated by a team of two field technicians, is a completely different system from a dense industrial monitoring network in a single building, with eighty nodes on mains power, transmitting vibration data every ten seconds, maintained by an on-site engineering team. Both are IoT systems. They require different connectivity protocols, and applying the same protocol to both because it worked on a previous project is a category error.

The framework in this article starts not with the protocol, but with the deployment. It asks eight questions about the deployment before any protocol is discussed. The protocol selection follows from those answers — as a consequence, not as a starting assumption.

1.2 — The Operator's Cost Model

Engineers think about connectivity in terms of technical performance: range, bandwidth, latency, power consumption. Operators think about connectivity in terms of cost: the capital cost of deploying the network, the recurring cost of operating it, and the cost of maintaining it when things fail.

These are not independent. Every technical characteristic of a protocol has a cost consequence. Long range means fewer gateways, which is a lower capital cost. Low power means longer battery life, which is a lower maintenance cost. High bandwidth means more data, which is higher recurring data plan cost if the protocol uses a metered network. The engineer who understands how technical characteristics translate into operator cost structure can make connectivity decisions that are not just technically sound but economically viable.

The single most common connectivity mismatch in IoT deployments is the use of a cellular modem in a deployment where the recurring data cost per node exceeds the value the node delivers. This is not a hypothetical. It occurs regularly in agricultural IoT, environmental monitoring, and asset tracking applications where the data payload is small, the transmission frequency is low, and the application value is modest — but the cellular data plan is priced for general-purpose connectivity rather than for the specific low-data, low-frequency IoT use case.

WARNING  A ₹200/month SIM plan on a sensor node that delivers ₹150/month of measurable value to the operator is not a connectivity choice. It is a guarantee that the deployment will not scale. Calculate the value-to-connectivity-cost ratio before the protocol is selected, not after the system is deployed.

Section 2: The Eight Decision Dimensions

Before any protocol comparison, a connectivity decision requires a clear answer to eight deployment-specific questions. These questions do not have universal answers. They are properties of the specific deployment being designed for. The framework uses the answers to these eight questions to evaluate protocols — not the other way around.

Dimension	The Question to Ask	Why It Matters
1. Node Density	How many devices per km²?	Drives gateway count and topology
2. Payload Size	How many bytes per uplink?	Determines if low-power protocols are viable
3. Uplink Frequency	How often does each node transmit?	Dominates power budget and duty cycle planning
4. Latency Tolerance	Can the application wait seconds, minutes, or days?	Eliminates protocols if real-time response is required
5. Power Source	Mains, solar, or primary battery?	Often the single most constraining dimension
6. Coverage Geography	Urban, rural, indoor, outdoor, mixed?	Determines which protocols are physically viable
7. Operational Lifetime	Months, years, or decades?	Affects OTA update strategy and protocol longevity risk
8. TCO Sensitivity	Who pays recurring costs — capex or opex model?	Determines how heavily to weight infrastructure vs SIM cost

Working through these eight dimensions before opening a protocol datasheet is the single most effective practice for avoiding connectivity mismatches. In most deployments, three or four of the eight dimensions will be strongly constraining — they will eliminate one or two protocols from consideration before any detailed comparison is needed. The remaining analysis can then focus on the protocols that survive the initial filter.

INSIGHT  In practice, Power Source and Coverage Geography together eliminate the incorrect protocol choice in the majority of IoT deployments. A battery-powered node covering rural terrain longer than 500 metres has already answered its connectivity question before the detailed analysis begins.

Section 3: Protocol Profiles — What Each Technology Actually Delivers

With the eight decision dimensions established, the protocol profiles below describe what each technology actually delivers in deployed conditions — not in ideal laboratory conditions or marketing materials. The comparison matrix that follows is followed by a detailed profile of each protocol's strengths, weaknesses, and the deployment conditions under which it excels.

Dimension	LoRa / LoRaWAN	Cellular (2G–4G)	Wi-Fi (802.11)
Typical Range	1–15 km rural	100–1000 m indoors	20–150 m
Node Density Ceiling	Moderate (duty cycle limited)	High	High (infrastructure-bound)
Payload per Uplink	Up to ~50 bytes typical	Kilobytes to megabytes	Megabytes unconstrained
Uplink Latency	Seconds (Class A/C)	Milliseconds to seconds	Milliseconds
Typical Node Rx Power	~1–100 mW peak TX	200–900 mW peak TX	150–400 mW peak TX
Sleep Current (node)	< 5 µA achievable	3–10 mA (modem standby)	150–300 µA (typical)
Infrastructure Cost	Gateway: ₹15k–60k once	SIM: ₹50–300/node/month	AP: ₹3k–20k, dense coverage needed
Recurring Cost	Network server (low)	Data plan per node	Power + maintenance of APs
Coverage Dependency	Self-deployable	Operator network required	Self-deployable, dense
OTA Update Viability	Challenging (payload limit)	Natural fit	Natural fit
Roaming / Mobility	Fixed nodes preferred	Full mobility support	Limited to AP coverage cell
Regulatory Spectrum	Unlicensed ISM band	Licensed spectrum	Unlicensed 2.4/5 GHz
Strongest Use Case	Sparse, low-power, large-area sensor nets	Mobile assets, high-data nodes	Dense indoor, high-throughput nodes

3.1 — LoRa / LoRaWAN: The Long-Range Low-Power Specialist

LoRa's physical layer modulation — a chirp spread spectrum technique operating in unlicensed sub-GHz bands — delivers a combination of range and receiver sensitivity that no other widely-available protocol matches at comparable transmit power. In open terrain, a single gateway can serve nodes at distances of five to fifteen kilometres. In dense urban environments, the range contracts to one to three kilometres, but still substantially exceeds Wi-Fi and competes with cellular for coverage per gateway.

The power characteristics of LoRa are genuinely exceptional when the application's duty cycle is compatible with the protocol's constraints. A node that wakes every fifteen minutes, takes a sensor reading, transmits a small payload, and returns to deep sleep can achieve three to seven years of battery life from a modest primary cell. This is not achievable with cellular or Wi-Fi under any reasonable configuration, and it is the primary reason LoRa dominates large-scale agricultural and environmental sensing deployments where the alternative is manual data collection or frequent battery maintenance.

The constraint that governs LoRa's applicability is the duty cycle limitation imposed by regulatory requirements in unlicensed ISM bands. In most jurisdictions, nodes are restricted to transmitting for no more than one percent of the time in a given sub-band. At the data rates typical of LoRa deployments, this limits usable uplink to a few hundred bytes per hour per node, and imposes real constraints on how frequently a node can transmit, how large a payload it can send, and how a gateway can serve a dense node population without congestion. Applications that require frequent, high-volume data transmission are not well served by LoRa regardless of how attractive its range and power characteristics appear.

The infrastructure model of LoRaWAN deserves particular attention for operator-facing deployments. LoRa gateways are self-deployable, typically requiring a power source and a backhaul internet connection. The capital cost of a gateway ranges from approximately fifteen thousand to sixty thousand rupees depending on form factor, environmental rating, and backhaul interface. Once deployed, the recurring cost is limited to the network server subscription — which for self-hosted open-source options like ChirpStack is effectively zero beyond infrastructure. For deployments with a large number of nodes spread across a defined geography, the economics of a self-owned LoRa network are frequently significantly better than per-node SIM costs across the same deployment lifetime.

PRINCIPLE  LoRa is the correct default for battery-powered deployments with small payloads, low transmission frequency, and geography that can be served by a manageable number of self-deployed gateways. It is the wrong default for any application that requires payload sizes above 50 bytes per message, transmission rates above a few times per hour, or mobility across unpredictable geography.

3.2 — Cellular: The Universal Connector With a Recurring Price

Cellular connectivity — encompassing 2G, 3G, 4G LTE, and the IoT-specific variants NB-IoT and LTE-M — offers the coverage geography that no self-deployed protocol can match. A cellular-connected node operates wherever a network operator has coverage, which across urban and suburban India is essentially everywhere, and increasingly across rural areas as network operators continue rural expansion.

This coverage universality is cellular's primary advantage, and it is a genuine one. Mobile assets — vehicles, livestock, equipment that moves across unpredictable geography — cannot be served by a fixed-infrastructure protocol. Deployments that span multiple districts with heterogeneous terrain, where self-deploying gateways at every required coverage point would be operationally impractical, may find that cellular's recurring cost is justified by the coverage it delivers without infrastructure investment.

The payload capacity and latency characteristics of cellular are unmatched by either LoRa or Wi-Fi in the context of mobile or geographically distributed deployments. A cellular node can transmit kilobytes to megabytes of data per uplink, can support real-time bidirectional communication, and can receive firmware updates over the air without the careful protocol engineering that LoRa OTA demands. For applications that generate substantial data — video, audio, high-frequency vibration waveforms, imaging — cellular is not one option among several. It is the only viable wireless option.

The economic constraint of cellular is the per-node recurring cost of SIM and data plan. In the Indian market, IoT SIM plans range from approximately fifty rupees per month for very low data volumes to several hundred rupees per month for general-purpose connectivity. Across a deployment of five hundred nodes, a two-hundred-rupee monthly SIM cost accumulates to one lakh rupees per month — twelve lakh rupees per year — in pure connectivity cost, before any hardware, installation, or maintenance is considered. For deployments where this recurring cost cannot be justified by the value delivered per node, cellular's technical advantages are economically irrelevant.

WARNING  The cellular connectivity decision must include a ten-year total recurring cost calculation before the hardware is designed. The SIM plan cost at deployment scale is frequently the single largest cost in the system's operating lifetime, and it is also the cost most consistently omitted from initial deployment budgets.

3.3 — Wi-Fi: The High-Performance Indoor Specialist

Wi-Fi's role in IoT connectivity is frequently misunderstood in both directions — overestimated in outdoor and long-range applications where its range is fundamentally limited, and underestimated in indoor and campus environments where its combination of high bandwidth, low latency, and ubiquitous infrastructure makes it the most practical choice available.

In controlled indoor environments — manufacturing facilities, cold storage warehouses, logistics centres, hospital buildings, campus networks — Wi-Fi infrastructure is already deployed for general networking purposes. Adding IoT nodes to an existing Wi-Fi network requires no additional gateway infrastructure investment, provides high-bandwidth, low-latency connectivity, and simplifies network management by consolidating IoT and enterprise traffic onto a shared infrastructure. For these deployments, the argument for a separate LoRa or cellular overlay is difficult to sustain against the operational simplicity and zero additional infrastructure cost of Wi-Fi.

The power constraint of Wi-Fi is genuine and significant. The Wi-Fi radio's association, scanning, and transmission overhead creates a minimum power envelope that is substantially higher than LoRa's deep-sleep-to-transmit cycle. Battery-powered Wi-Fi nodes are possible — the protocol supports power-saving modes that can substantially reduce average current draw — but the achievable battery life is measured in months rather than years, and requires careful firmware power management that is more complex than the equivalent LoRa implementation. For any deployment where annual or better battery life is a requirement, Wi-Fi is not a strong candidate regardless of its other characteristics.

The range limitation of Wi-Fi is physical and not addressable in firmware. In open outdoor environments, a standard Wi-Fi access point provides reliable coverage to approximately fifty to one hundred metres. Extending coverage requires additional access point density, which is both a capital cost and an operational maintenance burden. Outdoor Wi-Fi deployments — where the access points must themselves be weatherproofed, powered, and connected via backhaul — frequently approach the cost of a LoRa gateway deployment while delivering substantially less range per unit of infrastructure.

INSIGHT  Wi-Fi is most powerful when treated as an integration protocol rather than a field deployment protocol. In deployments where nodes are in fixed indoor locations with reliable mains power, high data throughput requirements, and existing Wi-Fi infrastructure, it is frequently the lowest-total-cost option. In outdoor, battery-powered, or geographically distributed deployments, it is rarely the right choice.

Section 4: Applying the Framework — A Deployment Scorecard

The decision framework is most useful when applied to specific deployment conditions rather than discussed in the abstract. The scorecard below maps concrete deployment conditions to protocol verdicts derived from the eight-dimension framework. Each verdict is a starting recommendation, not a final answer — real deployments often involve hybrid solutions where different nodes in the same system use different protocols based on their specific function and location.

Deployment Condition	Framework Verdict
Battery-powered nodes required?	Yes → LoRa or careful Cellular (NB-IoT class); Wi-Fi last resort
Coverage area > 500 m per gateway?	Yes → LoRa; Cellular if no gateway budget; Wi-Fi cannot serve
Payload > 1 KB per message?	Yes → Cellular; LoRa unsuitable; Wi-Fi if infrastructure exists
Mobile or roaming assets?	Yes → Cellular; LoRa and Wi-Fi both struggle
Latency < 1 second required?	Yes → Cellular or Wi-Fi; LoRa Class A unsuitable
No SIM/data recurring cost acceptable?	Yes → LoRa or Wi-Fi; Cellular difficult to justify
Indoor, dense, < 50 m node spacing?	Yes → Wi-Fi competitive; LoRa over-range; Cellular viable
OTA firmware update is critical?	Cellular or Wi-Fi strongly preferred; LoRa requires careful design
Infrastructure ownership preferred?	Yes → LoRa or Wi-Fi (self-hosted); Cellular is operator-dependent
Sub-₹500/node/year connectivity cost?	LoRa with owned gateway amortised; Cellular rarely achieves this

The scorecard reveals a pattern that holds across the majority of IoT deployments: the correct protocol choice is usually deterministic once the deployment conditions are specified honestly. The ambiguous cases — where two protocols appear comparably suited — are the exception, not the rule. When genuine ambiguity exists after working through the scorecard, the tiebreaker is almost always total cost of connectivity over the expected deployment lifetime.

4.1 — Hybrid Deployments: When the Answer Is More Than One Protocol

Some deployment architectures benefit from combining protocols, with different nodes using different connectivity based on their function, location, or power profile. A large agricultural deployment might use LoRa for the majority of field sensor nodes — which are battery-powered, transmit small payloads infrequently, and are distributed across large areas — while using cellular for the gateway backhaul and for a small number of mobile monitoring units that follow farm equipment.

This hybrid approach is architecturally valid but carries a cost: it multiplies the firmware development effort, the hardware variants, and the operational complexity of the deployment. A team managing two radio technologies, two network stacks, and two sets of gateway infrastructure is a more complex operation than a team managing one. The additional complexity is worth it when the deployment requirements genuinely cannot be served by a single protocol. It is not worth it when the hybrid is adopted because the team is avoiding a clear decision rather than responding to a real constraint.

PRINCIPLE  A hybrid connectivity architecture should be adopted only when a specific, named deployment requirement cannot be met by either protocol alone. 'We want the flexibility' is not a sufficient justification for hybrid complexity. 'The mobile monitoring units cannot be served by our LoRa gateway topology' is.

4.2 — The Protocol Migration Problem

Connectivity decisions made at product design time are difficult and expensive to reverse in the field. A deployment of five hundred cellular nodes that proves economically unviable at recurring cost cannot easily be converted to LoRa — the hardware is different, the firmware is different, and the gateway infrastructure does not exist. This irreversibility means that connectivity decisions carry a disproportionate long-term consequence relative to most other design decisions.

The correct response to this irreversibility is not to choose the most flexible protocol, but to invest adequate time in the deployment analysis before the hardware is designed. Working through the eight decision dimensions, building the ten-year total connectivity cost model, and stress-testing the protocol choice against the worst-case deployment conditions takes two to four days for a competent engineering team. That investment is cheap insurance against a connectivity mismatch that will cost multiples of that time to diagnose and is essentially impossible to fix without a hardware revision.

Section 5: Reading the Deployment Through the Operator's Lens

The final step in the connectivity decision framework is to review the chosen protocol from the operator's perspective — not as an engineering choice, but as an operational commitment. This review asks three questions that engineers frequently skip because they are not comfortable engineering questions. They are business and operational questions, and in IoT deployments, getting them wrong is as consequential as getting the protocol specification wrong.

5.1 — Who Maintains the Infrastructure?

Every connectivity protocol requires infrastructure — gateways, SIM management, network servers, access points. The question of who maintains that infrastructure across the deployment lifetime is not a minor operational detail. It is a fundamental design constraint that affects which protocol is viable.

A LoRa deployment with self-owned gateways gives the operator full control over infrastructure but full responsibility for its maintenance. Gateway failures, backhaul connectivity issues, and software updates are the operator's problem. If the operator has the technical capacity to manage this, self-owned infrastructure is often the most economical choice. If the operator does not — if the deployment is being handed to a farming cooperative or an agriculture department without embedded systems expertise — the maintenance burden of self-owned infrastructure may exceed its economic advantage.

Cellular connectivity shifts infrastructure maintenance entirely to the network operator, at the cost of recurring SIM charges. The operator of the IoT system is not responsible for tower maintenance, coverage planning, or network uptime. This is a genuine operational simplification that has real value for deployments where the end operator cannot maintain radio infrastructure — and a real cost that must be weighed against that value.

5.2 — What Happens When the Network Changes?

Connectivity infrastructure changes over time in ways that are outside the control of the IoT system designer. Cellular network operators retire 2G and 3G spectrum, rendering existing modems inoperable. LoRa network server software undergoes breaking changes that require gateway firmware updates. Unlicensed spectrum regulations change across jurisdictions. Wi-Fi standards evolve, and legacy devices eventually lose support from network management systems.

A connectivity decision that does not include an assessment of technology longevity risk is incomplete. The question to ask is: what happens to this deployment if the connectivity infrastructure changes materially within the expected product lifetime? For cellular deployments using 2G modules, this question has already been answered in many markets — 2G shutdown has stranded deployed hardware at significant replacement cost. For LoRa deployments using standardised LoRaWAN, the protocol stability and the availability of multiple independent gateway and network server implementations provides reasonable longevity assurance. For Wi-Fi deployments on existing enterprise infrastructure, the longevity question is inherited from the enterprise IT roadmap, which may or may not align with the IoT deployment timeline.

5.3 — Does the System Explain Itself When Something Goes Wrong?

The final operator-lens question is about failure transparency. When a node goes offline, when a gateway loses backhaul, when SIM connectivity drops across a cluster of nodes — how does the operator know, how quickly do they know, and what do they know about why?

This question is not answered by the connectivity protocol. It is answered by the system design. But the connectivity protocol determines what diagnostic information is available. A LoRa system that only knows a node failed to deliver an uplink in the expected window provides less diagnostic information than a cellular system that can receive an explicit disconnect event from the network. The firmware engineer who understands the protocol's failure signalling characteristics can design a monitoring system that gives the operator the right information at the right level of detail — rather than a system that surfaces raw protocol events that require engineering interpretation to act on.

PRINCIPLE  Design the connectivity monitoring and alerting system from the operator's perspective, not the engineer's. The operator's question is not 'what is the RSSI of node 247?'. It is 'which nodes have not reported in the last two hours and where are they on the map?'. These require different data, different aggregation, and different presentation — and the firmware engineer who understands the operator's model builds both the connectivity and the monitoring system correctly from the start.

Closing: The Framework as a Communication Tool

The eight-dimension framework in this article is not just a decision tool for the engineering team. It is a communication tool between engineers and the operators who commission and maintain IoT deployments.

When an engineering team can present a connectivity recommendation in terms of deployment conditions, ten-year total cost, infrastructure maintenance model, and longevity risk — rather than in terms of modulation schemes, spreading factors, and link budgets — the conversation with an operator becomes productive rather than one-directional. The operator can validate the deployment conditions that the engineer used as inputs. They can correct assumptions about the maintenance model. They can flag coverage requirements that the engineer did not know about. The framework creates a shared vocabulary for a decision that affects both parties across the lifetime of the deployment.

The engineer who chooses LoRa because it is familiar, cellular because it is reliable, or Wi-Fi because it is already in the chip — without working through the deployment conditions — is making a private technical decision about a shared operational commitment. The engineer who works through the eight dimensions, builds the cost model, and presents the recommendation in operator terms is doing something more valuable: treating the connectivity decision as the long-term operational choice it actually is, and giving the deployment the best available chance of surviving contact with the real world.

About the Author

Srihari Maddula is the Founder and Technical Lead of Eurth Techtronics Pvt Ltd, an electronics product design and IoT engineering company based in Hyderabad, India. EurthTech has delivered many embedded systems products across industrial, agricultural, medical, and strategic applications. This blog series shares frameworks and principles from real product development practice — without compromising client confidentiality.

Eurth Techtronics Pvt Ltd  •  www.eurthtech.com  •  Hyderabad, India