LoRa vs NB-IoT vs WiFi: Choosing the Right IoT Network for Your Project

Choosing the radio for an IoT project is the one decision that shapes everything else — the battery life, the range, the monthly cost, and whether your device works at all at the deployment site. Three technologies cover nearly every student IoT build: LoRa for long-range, low-power field sensing; NB-IoT for long-range cellular connectivity where a mobile network reaches; and WiFi for rich, frequent data near infrastructure. This guide compares them on range, power, data rate, latency, and cost, works through the airtime math that decides LoRa battery life, and gives you a decision framework you can apply to any project — with the Indian network reality (what is actually available here) spelled out honestly.

If you have not picked a controller yet, read this alongside ESP32 vs Arduino vs Raspberry Pi: the IoT-projects comparison — the controller and the radio are the two big hardware calls, and they interact. And if your device will run on a battery, the radio choice feeds directly into the power budget worked out in the ESP32 low-power battery design guide.

The short answer: which network for what

Your situation	The network to pick	Why
Sensor nodes spread over fields, a campus, or a village — no WiFi, sending small readings every few minutes	LoRa (point-to-point or LoRaWAN)	Kilometre range, ~100 mA transmit bursts of under a second, no SIM or monthly fee if you run your own gateway
A handful of devices in a city or along roads where 4G coverage exists, sending small readings hourly or daily	NB-IoT	Uses the mobile network — no gateway to install; deep-sleep modes (PSM/eDRX) give multi-year battery life on paper
A device within 30–50 m of a router — home, lab, workshop — sending frequent or rich data (dashboards, images, audio)	WiFi	Megabits of bandwidth, no gateway, no SIM; the ESP32 already has it

The trap to avoid: picking WiFi because the lab has WiFi, then discovering at deployment that a farm sensor network sits 3 km from the nearest access point. Always decide the network from the deployment site, not the bench.

The comparison table, quantified

Figures below are the ones you can verify in datasheets or compute yourself — typical/anchor values, not guarantees, because antennas, buildings, and interference move real-world numbers.

Parameter	LoRa (sub-GHz, e.g. SX1276/SX1278)	NB-IoT (cellular, e.g. SIM7020/SIM7080)	WiFi (2.4 GHz, e.g. ESP32)
Typical practical range	2–10 km rural line-of-sight; 0.5–2 km urban	Same as the carrier's 4G/LTE footprint	30–100 m line-of-sight; far less through walls
Frequency band (India)	865–867 MHz licence-free ISM	Licensed LTE bands via carrier (Jio/Airtel)	2.4 GHz licence-free
Raw/max data rate	~0.3–50 kbps depending on spreading factor	~20–60 kbps downlink, up to ~100+ kbps in good conditions (3GPP targets; real cells vary)	10s of Mbps practical
Typical latency	Seconds (airtime + gateway)	Seconds to tens of seconds (network paging)	Milliseconds
Transmit current	~20–120 mA depending on TX power setting (~100 mA typical at +17 dBm)	~100–300 mA during network attach/transmit bursts	~160–260 mA (ESP32 datasheet TX)
Sleep current	~0.2 µA module sleep	~3–5 µA in PSM (module datasheet typical)	~10 µA ESP32 deep sleep (chip only; board draws more)
Infrastructure	Your own gateway (or community LoRaWAN coverage)	Carrier network + SIM per device	Access point you control or can join
Recurring cost	Zero if you run the gateway; gateway hardware is a one-time ~₹5k–15k	SIM data plan per device (small IoT plans from a few tens of rupees/month)	Zero (uses existing internet)
Suited for	Field sensors, farms, flood/river monitoring, air-quality grids	City-wide sparse sensors, asset trackers, utility metering	Dashboards, cameras, dense telemetry near power and WiFi

Three things to read out of this table that students often miss:

1. LoRa and NB-IoT are both "low data rate, long range, low power" — the difference is who owns the infrastructure. LoRa: you (or a community) run gateways. NB-IoT: a telecom runs the towers and you pay per SIM. A college can put one LoRa gateway on a hostel roof and cover the whole campus; NB-IoT needs nothing on the roof but a SIM in every node.
2. WiFi is not a long-range technology, no matter how good the antenna. Antenna gain helps, but 2.4 GHz is absorbed by walls, trees, and rain. If your sensor is more than ~100 m from the router with obstacles between, WiFi is the wrong answer.
3. "Low power" means different things. LoRa sips power because each transmission lasts under a second and the module sleeps at microamps. NB-IoT sips power because of PSM (Power Saving Mode — the module negotiates long sleep windows with the tower). WiFi's power problem is not the transmit current, it is the association overhead: joining the network and getting an IP can take 3–8 seconds at 160+ mA before a single byte of your data moves.

LoRa in depth: the field-sensor workhorse

LoRa (the physical-layer modulation, chirp spread spectrum) plus LoRaWAN (the network protocol on top) is the most common student choice for anything outdoors and battery-powered — and for good reason. A LoRa weather station sending temperature and humidity from a rooftop 4 km away is the canonical demo, and it works.

The three knobs: spreading factor, bandwidth, coding rate

Every LoRa transmission is configured with three parameters, and they trade range against airtime (time on air — how long the radio transmits):

• Spreading factor (SF7–SF12): higher SF = longer range but much longer airtime. SF12 takes roughly 32× the airtime of SF7 for the same payload. This is the single most important setting for battery life.
• Bandwidth (typically 125 kHz in India): wider = faster = shorter airtime, but less range and more noise susceptibility.
• Coding rate (4/5 to 4/8): more redundancy = more robust, longer airtime.

The practical rule: use the lowest spreading factor that still reaches your gateway reliably. Students who leave the module at SF12 "for maximum range" burn ~32× the energy per packet of SF7 for no benefit when the gateway is 500 m away.

Airtime: the worked example that decides your battery

LoRa airtime determines both battery drain and regulatory duty-cycle compliance. A rough but useful formula for symbol time:

Symbol time Ts = 2^SF / BW

For SF7 at 125 kHz: Ts = 128 / 125000 ≈ 1.024 ms per symbol. A 20-byte payload at SF7/125 kHz/4-5 takes on the order of ~60 ms of airtime. The same payload at SF12 takes roughly 1.5–2 seconds.

Now the battery math, using a realistic node: transmit at ~100 mA, sleep at ~10 µA (including a good regulator — see the low-power design guide for why board-level sleep current matters more than chip specs):

Setting	Airtime per packet	Energy per hourly packet	Battery impact (18650, 2400 mAh usable)
SF7, 20-byte payload	~60 ms	100 mA × 0.06 s ≈ 1.7 µAh	negligible — sleep dominates
SF10, 20-byte payload	~370 ms	100 mA × 0.37 s ≈ 10 µAh	still small
SF12, 20-byte payload	~1.5 s	100 mA × 1.5 s ≈ 42 µAh	~1 mAh/day at hourly reports — still fine, but 25× SF7

The conclusion: at hourly reporting intervals, even SF12 is affordable on a single 18650 — the sleep current is what kills batteries, not LoRa airtime. Where SF bites is at frequent reporting (every minute) or with large payloads. Keep payloads tiny: a temperature/humidity/soil-moisture reading fits in 8–12 bytes with simple binary packing. Sending JSON strings over LoRa is a classic beginner waste — "{"temp":28.5}" is 13 bytes where 2 bytes suffice.

LoRa vs LoRaWAN: know which one you are building

• Point-to-point LoRa (two modules talking directly, e.g. with the RadioHead or LoRa library): simplest. One node sends, one receiver (often an ESP32 with a LoRa module acting as gateway) forwards to the cloud. Fine for a handful of nodes and a final-year demo.
• LoRaWAN (nodes → gateways → network server like The Things Network): the proper multi-node architecture with encryption, adaptive data rate, and device management. Heavier to set up but the right answer for a real sensor grid.

For a final-year project, point-to-point is usually the pragmatic choice — a LoRaWAN stack is a project in itself. Name which one you built in your report; examiners do notice the difference.

India specifics: band, duty cycle, gateways

• Band: 865–867 MHz is the licence-free ISM allocation in India. Buy modules specified for 865 MHz (or 868 MHz tunable down — the SX1276 covers 862–1020 MHz, so it is fine; check your module's antenna is actually cut for 865 MHz, not 433 MHz, or range collapses).
• Duty cycle: India's 865–867 MHz rules expect low duty-cycle use (the commonly cited planning figure is around 1% in practice for shared ISM use). At hourly reports you are at ~0.005% — nowhere near any limit. It only matters if you stream continuously.
• Gateways: a single-channel "gateway" (really a LoRa receiver on an ESP32, ~₹2.5k–4k in parts) covers a demo. A proper 8-channel LoRaWAN gateway (RAK, Dragino) is ~₹12k–20k. One gateway on a tall campus building covers several kilometres — this is the architecture behind farm sensor networks and long-range weather telemetry.
• Community coverage: The Things Network has community gateways in some Indian cities. Check TTN Mapper for your city before assuming coverage — do not assume it exists.

NB-IoT in depth: cellular range without the gateway

NB-IoT (Narrowband IoT) is a 3GPP cellular standard designed for exactly the "a few bytes, occasionally, for years on a battery" use case. The module (common student choices: SIM7020E, SIM7080G, Quectel BC66/BC95) attaches to the LTE network like a phone, sends its data, and negotiates long sleep windows with the tower.

Why students consider it — and the honest caveats

The pitch is compelling: no gateway to build, coverage wherever the carrier has it, and a SIM plan instead of hardware infrastructure. The caveats, specific to India, are equally real:

• Coverage is carrier- and area-dependent. Both Jio and Airtel have NB-IoT offerings, but NB-IoT is not the same as "4G works here." A spot can have full phone bars and no NB-IoT cell. Before buying modules, verify NB-IoT availability at the actual deployment location with the carrier — ideally with a test SIM and the module in hand. This single check kills more NB-IoT projects than any technical issue.
• Module and SIM logistics. NB-IoT modules cost more than LoRa modules (~₹1.5k–3.5k vs ~₹600–1.2k for a LoRa module), need a proper LTE antenna, and each device needs its own SIM with an IoT data plan. For a 3-node student project this is manageable; for a 50-node grid the SIM management becomes the project.
• Power is good but not magic. PSM (Power Saving Mode) lets the module sleep at a few microamps between negotiated wake windows — but the network attach itself can draw 100–300 mA for seconds, and a failed attach in weak coverage retries and burns the battery. Budget for the attach cost in your power math, not just the transmit cost.
• Latency is not real-time. Waking from PSM and delivering a packet can take seconds to tens of seconds. Fine for hourly soil data; wrong for an alarm that must fire in under a second.

When NB-IoT beats LoRa

• Deployments spread across a city where you cannot install your own gateway (utility poles, rented sites, roadsides).
• Projects where the "no infrastructure" story matters for the report — asset tracking across a district, for example.
• Situations where LoRa gateway backhaul is the problem: a LoRa gateway still needs internet (WiFi/Ethernet/4G) to forward data. If the gateway site has no backhaul either, NB-IoT's direct-to-tower path wins.

A rough decision rule: fewer than ~10 nodes in one area → LoRa with your own gateway is cheaper and simpler. Nodes scattered where you cannot place gateways → NB-IoT.

WiFi in depth: the default that deserves respect

WiFi (on the ESP32, the radio you already have) is the right answer more often than IoT purists admit — provided the device lives near infrastructure. Its strengths are bandwidth and zero extra hardware: an IoT weather station with a mobile dashboard or a smart street-light controller pushing rich telemetry every few seconds is a WiFi-shaped problem.

The failure modes are all about the gap between bench and field:

• Enterprise/captive-portal WiFi. Campus and hostel networks often use WPA2-Enterprise (username/password) or captive portals. The ESP32 Arduino core handles WPA2-Enterprise with some effort; captive portals are effectively unusable for headless devices. Test on the actual network, not your home router. Many student projects die at the hostel gate for this reason.
• The association tax. Every wake-from-deep-sleep costs a WiFi join: 3–8 seconds typical, 160–260 mA. Static IP, stored BSSID/channel, and short payloads cut this dramatically — the low-power guide works the numbers.
• 2.4 GHz congestion. Hostels and apartment blocks are RF soup. If the device must work in a dense building, test throughput and retry rates on site; a device that works in your room may starve two floors up.
• Range honesty. The ESP32's PCB antenna reaches ~50–100 m line-of-sight in practice. Through two concrete walls, expect tens of metres. Plan repeater placement (or switch to LoRa) from measurements, not hope.

ESP32 + WiFi + MQTT: the standard stack

For WiFi devices, the canonical pipeline is ESP32 → MQTT → broker → dashboard, covered in the practical MQTT guide and the cloud-connection guide. A ThingsBoard dashboard on ESP32 is a good reference build for what this stack looks like finished. Learn this stack once and it serves every WiFi project you will ever build.

Cost comparison: a realistic 5-node, 1-year budget (India, indicative)

Student budgets decide projects, so here is an honest side-by-side for five sensor nodes reporting hourly for a year. Treat the rupee figures as indicative street prices, not quotes — they move.

Cost head	LoRa (own gateway)	NB-IoT (5 SIMs)	WiFi (ESP32, existing APs)
Radio hardware	5 × ~₹800 LoRa modules ≈ ₹4,000	5 × ~₹2,500 NB-IoT modules ≈ ₹12,500	₹0 (ESP32 has WiFi)
Infrastructure	1 gateway ~₹4,000 (single-channel build) to ~₹15,000 (8-channel)	₹0	₹0 (uses existing routers)
Recurring/year	₹0	5 SIMs × ~₹50–150/month IoT plan ≈ ₹3,000–9,000/yr	₹0
Antennas/cables	~₹1,000 (proper 865 MHz antennas matter)	~₹1,500 (LTE antennas)	₹0
Indicative 1-year total	~₹9,000–20,000	~₹16,000–23,000	~₹0 extra

Read it correctly: WiFi is cheapest where WiFi exists. LoRa's gateway is a one-time cost that amortises over every node you add — node 6 through 50 cost only the module. NB-IoT's per-SIM cost scales linearly forever. For a final-year project with 3–5 nodes, LoRa-with-own-gateway and WiFi are the budget-friendly answers; NB-IoT earns its keep when the deployment geography forbids gateways.

The decision framework: answer these five questions in order

1. Where will the device physically live, and what networks exist there? Walk the site. Note WiFi SSIDs and their signal at the exact mounting spots, check NB-IoT with a test SIM, and eyeball line-of-sight for LoRa gateway placement. This one site survey answers 80% of the decision.
2. How much data, how often, how fast? A few bytes hourly → LoRa or NB-IoT. Rich telemetry every 10 seconds → WiFi. Anything with images or audio → WiFi, no contest.
3. How many nodes, and who maintains the infrastructure? One gateway you control + many nodes → LoRa. Scattered nodes, no gateway sites → NB-IoT. Near existing routers → WiFi.
4. What is the power source? Battery for months with no mains → LoRa or NB-IoT (both sleep at microamps). Mains or solar nearby → WiFi is fine. Size the battery from the radio's actual duty cycle — the battery design guide has the worked math.
5. What does the report need to show? A LoRa link budget and airtime calculation, an NB-IoT attach-current measurement, or a WiFi association-time optimisation are all solid engineering content for a final-year report. Pick the network whose analysis you can do well, not just the one that is fashionable.

Security: the part students skip

• LoRa point-to-point: raw LoRa has no encryption — anyone with a matching module can listen. At minimum, encrypt payloads (AES on the ESP32 before transmitting) and do not send anything sensitive in the clear. LoRaWAN gives you AES-128 session keys properly; another reason to prefer it for real deployments.
• NB-IoT: inherits LTE's link-layer security, which is decent — but use TLS to your cloud endpoint anyway for anything internet-facing.
• WiFi: WPA2 is the floor, not the ceiling. Use TLS (mqtts://, https://) for cloud traffic; the ESP32 handles it, at the cost of a 2–4 second handshake per connection — another reason to keep connections persistent or batch transmissions.

Diagnosis table: when the radio misbehaves

Symptom	Likely cause	Check
LoRa: works at 200 m, dead at 1 km	Wrong antenna (433 MHz antenna on 865 MHz module), or SF too low for the path, or gateway antenna indoors	Verify antenna marking; raise SF step by step; move gateway antenna outdoors and high
LoRa: packets arrive corrupted intermittently	Another ISM user on the channel, or marginal link at low SF	Try a different channel; raise SF; check RSSI/SNR values the receiver reports
NB-IoT: module never attaches (keeps searching)	No NB-IoT coverage at that spot, wrong APN, or SIM not provisioned for NB-IoT	Confirm coverage with carrier; check APN string character by character; test the SIM in a phone for basic data
NB-IoT: attaches but battery dies in days	Attach retries in weak signal, or PSM not actually negotiated	Log attach duration; confirm PSM/eDRX settings took effect with AT commands
WiFi: works at home, fails at the deployment site	Captive portal / WPA2-Enterprise, or wrong credentials baked into firmware	Test on the actual network early; add a BLE/WiFi-manager provisioning path
WiFi: connects but publish takes 30+ seconds	DHCP + DNS + TLS on every wake; weak signal causing retries	Static IP, persistent MQTT session, hard timeout with store-and-retry on failure

Pre-build checklist

• Site survey done: WiFi signal at mounting spots, NB-IoT checked with a test SIM if relevant, LoRa line-of-sight eyeballed for gateway placement.
• Payload sized: binary-packed, under ~20 bytes for LoRa/NB-IoT; JSON only where bandwidth is free (WiFi).
• Spreading factor chosen by measurement (lowest SF with reliable delivery), not left at the library default.
• Antennas matched to the band (865 MHz for LoRa in India; proper LTE antenna for NB-IoT) — not whatever came in the parts bin.
• Power budget computed from the radio's duty cycle with measured sleep current, per the low-power design guide.
• Encryption/TLS decided before the first packet, not after the demo.
• The report names the network and the analysis: link budget, airtime math, attach measurements, or association optimisation.

Putting it together

There is no "right" IoT network in the abstract — only the right network for a site, a payload, and a budget. LoRa owns the field-sensor space where you can place a gateway; NB-IoT owns scattered deployments inside carrier coverage; WiFi owns everything near infrastructure with rich data needs. Do the site survey first, size the payload second, and let the comparison table above settle the rest.

Builds that put this guide into practice: a LoRa farm sensor network for the LoRa path, long-range LoRa weather telemetry for the link-budget exercise, an air-quality monitoring station for the sensor-plus-radio integration, and the IoT & Embedded branch hub for more buildable concepts in this space.