LoRaWAN versus NB-IoT for Smart Water Metering in a Tier-2 Indian City: A Link-Budget and Field Study

Indian cities are installing smart water meters at scale, and every tender faces the same fork: LoRaWAN, the licence-exempt low-power wide-area technology the utility owns itself, or NB-IoT, the cellular LPWAN that rides on the operator's network. Vendor material asserts one answer; this dissertation measures one.

The use case is fixed first: an automated meter-reading service for a Karnataka Tier-2 city, with 12-byte readings every 15 minutes, a ten-year battery target and meters buried in basements and shafts. The study then combines three kinds of evidence. A campus measurement campaign — a 40-acre engineering-college site standing in for city conditions — walks fixed routes with an ESP32–SX1276 LoRa node logging RSSI and SNR at spreading factors SF7–SF12 through an own-operated ChirpStack gateway, and a SIM7020E NB-IoT breakout logging RSRP, coverage-enhancement level, uplink success and latency on a commercial SIM. Published parameters — Semtech sensitivity curves, 3GPP TR 45.820 coverage targets, the TTN IN865-867 channel plan — anchor a link-budget model. Energy modelling built on measured current profiles (transmit, idle, sleep, PSM) converts each technology's radio behaviour into battery years at 15-minute and hourly reporting, and a cost model amortises gateways against per-SIM data plans.

The output is a weighted decision matrix and a defended recommendation, every number traceable to a log file or a cited datasheet. Written for the VTU M.Tech 2022 Project Work Phase-2 (22SXX41), applying the Computer Networks & IoT Lab (22SCNL17) and Research Methodology & IPR (22RMI16); all tables in this bundle await your own campaign.

A city utility planning smart water meters must commit, for a decade, to a connectivity technology whose field behaviour in Indian urban conditions is not documented in any tender document. LoRaWAN promises ownership, low node cost and multi-year batteries but demands gateway placement, spectrum discipline in a three-channel national plan, and in-house network competence. NB-IoT promises carrier-grade coverage with deep-indoor penetration and no infrastructure to run, but binds the utility to operator pricing, coverage and product roadmaps. Vendor comparisons quote best-case sensitivity and battery numbers under undisclosed assumptions, and academic surveys rarely reflect Indian propagation, Indian regulations or Indian rupee costs.

The engineering problem is: for a 12-byte-every-15-minutes water-metering service, what are the measured link margins, packet-delivery performance, energy per report, battery life and per-node-per-year cost of LoRaWAN and NB-IoT under a single declared protocol — and which technology wins for a Karnataka Tier-2 deployment once the results are combined in a sensitivity-tested decision matrix?

Abstract

Smart water metering is the flagship LPWAN use case in Indian smart-city programmes: millions of low-rate, battery-powered, hard-to-reach meters. This dissertation compares the two technologies competing for it — LoRaWAN in India's licence-exempt 865–867 MHz band and NB-IoT on commercial LTE networks — through a measurement campaign, a link-budget analysis and an energy-and-cost model, ending in a weighted decision matrix for a specific use case rather than a generic verdict.

Introduction

A water meter reports ~12 bytes every 15 minutes, tolerates minutes of latency, must survive basements and meter chambers, and is expected to run ten years on one battery. The network choice decides who owns the infrastructure (utility vs operator), what a node costs per year (gateways amortised vs SIM plans), and whether dead spots can be fixed by the utility at all. India adds a regulatory twist: LoRaWAN operates in the 865–867 MHz de-licensed band with only three standard uplink channels (865.0625, 865.4025, 865.985 MHz), which caps capacity and shapes the comparison.

Existing System

• Vendor white papers compare peak sensitivity and battery life on each side, with unstated assumptions and no Indian propagation data.
• Academic LoRaWAN/NB-IoT surveys (e.g., Adelantado et al. 2017; Mwakwata et al. 2019) are excellent on technology but rarely ground numbers in Indian measurements or rupee costs.
• Utilities choose by habit or by whichever vendor arrives first.

Literature Gap

• Few published studies combine an Indian field campaign with datasheet-anchored link budgets and a per-node-per-year cost model on the same use case.
• Battery-life claims usually quote radio current alone, ignoring retransmissions, ADR behaviour, join overhead and PSM/sleep states — the terms that dominate the energy budget.
• Gap: a declared protocol that measures both technologies on one campus, validates a propagation and energy model against the measurements, extrapolates to city scale with explicit assumptions, and reports a sensitivity-tested decision matrix.

Proposed Work

• A 25-point campus campaign: ≥20 uplinks per point per spreading factor (LoRa) and per coverage condition (NB-IoT), logged with GPS and environment notes.
• Link-budget analysis: measured RSSI versus log-distance and COST-231-Hata predictions; LoRa margins per SF; NB-IoT margins per coverage-enhancement level against the published 164 dB maximum coupling loss target.
• Energy model: measured current profiles per technology converted to energy per report and battery years at 15-minute and hourly cadences, including retransmission costs at measured packet-delivery ratios.
• Cost model and weighted decision matrix with sensitivity analysis on weights, energy results and deployment scale.

Feasibility

LoRa hardware and a Raspberry-Pi gateway cost a few thousand rupees and are stocked by Indian distributors; a single NB-IoT SIM and breakout is similarly affordable; all analysis is Python on a laptop. The campaign needs two people for the walking routes but one is sufficient; the remaining phases are desk work. Total hardware cost stays under a typical lab consumables budget.

In scope

• One use case (automated water-meter reading) and two technologies (LoRaWAN on 865–867 MHz; NB-IoT on a commercial Indian LTE network) studied on one campus plus desk-based city-scale extrapolation.
• Measurement of RSSI/SNR, RSRP, packet-delivery ratio, uplink latency and current profiles; propagation-model fitting; link budgets; energy and battery models; cost models; decision matrix.
• Hardware limited to one LoRa node, one gateway, one NB-IoT breakout, one SIM and a USB power analyser.

Out of scope

• City-wide gateway placement optimisation or drive-test campaigns across the actual Tier-2 city — the campus stands in, with extrapolation assumptions stated explicitly.
• Sigfox, LTE-M, Wi-SUN, proprietary mesh and GSM/GPRS alternatives.
• Multi-gateway LoRaWAN capacity studies beyond a stated theoretical ceiling for the three Indian channels.
• Meter hardware design, billing software and data-analytics back-ends — connectivity is the boundary of this study.
• Security testing beyond standard LoRaWAN 1.0.x join security and NB-IoT carrier SIM behaviour; spectrum-regulation filings.

The research design is a comparative empirical study with model validation: measurements first, models anchored to measurements, extrapolation explicitly flagged. Every rule below was declared before the campaign, in the discipline of the Research Methodology & IPR course (22RMI16).

Declared protocol. (1) Use case fixed first: 12-byte payload, 15-minute and 1-hour reporting cadences, ≥10-year battery target, basement-to-rooftop coverage. (2) Campaign design: 25 fixed points on three route types (line-of-sight corridor, mixed indoor, deep indoor/basement) at 50 m–2 km from the gateway; per point, ≥20 uplinks per spreading factor SF7–SF12 (ADR disabled) for LoRa, and ≥20 uplink attempts per route for NB-IoT; every log row carries GPS, timestamp, RSSI/SNR or RSRP/CE-level, success flag and latency. (3) Fairness: both radios configured at their Indian-regulation maximum output; the same person walks both routes on the same day pair; rainy and dry days both sampled and tagged. (4) Models: log-distance fit per route type with reported R², cross-checked against COST-231-Hata predictions; LoRa link margin per SF against datasheet sensitivity; NB-IoT margin against the published 164 dB MCL design target (3GPP TR 45.820). (5) Energy: current profiles measured with a USB power analyser across TX, idle and sleep/PSM states; energy per report computed at both cadences including measured-PDR retransmissions; battery years for a selected LiSOCl₂ cell from its datasheet, derated for self-discharge. (6) Costs: gateway + antenna + backhaul + server amortised over five years and 10,000/50,000 nodes, versus SIM + data-plan + platform charges; all prices dated and sourced. (7) Decision: weighted matrix over coverage, PDR, battery life, ₹/node/year, latency, scalability and vendor lock-in; weights varied ±50% one at a time in the sensitivity analysis.

Threats to validity: one campus is not one city — the extrapolation chapter carries this limit explicitly; carrier coverage varies by location and is reported as measured, not generalised; weather and foliage effects are tagged and compared rather than averaged away.

The study architecture has two halves: the measurement testbed that produces logs, and the analysis pipeline that converts logs into the decision matrix. Everything between field and figure is scripted, so no number is typed by hand.

flowchart TD
  A["LoRa node: ESP32 + SX1276<br/>SF7-SF12, ADR off"] -->|"865-867 MHz uplinks"| G["Gateway: RAK/RPi<br/>packet forwarder"]
  G --> CS["ChirpStack network server<br/>RSSI, SNR, PDR logs"]
  B["NB-IoT breakout: SIM7020E<br/>commercial SIM"] -->|"UDP uplinks"| OP["Carrier LTE network"]
  OP --> NR["UDP listener: success,<br/>RSRP, CE level, latency"]
  PA["USB power analyser"] -->|"current profiles"| EP["Energy profiler:<br/>TX, idle, sleep, PSM"]
  CS --> DS[("Campaign dataset:<br/>point, GPS, radio, result")]
  NR --> DS
  EP --> DS
  DS --> LB["Propagation fits and<br/>link margins"]
  DS --> EM["Energy and battery model"]
  DS --> CM["Cost model"]
  LB --> DM["Weighted decision matrix<br/>+ sensitivity analysis"]
  EM --> DM
  CM --> DM

The testbed half keeps the two radios strictly symmetric — same routes, same day pairs, same attempt counts — because the comparison's fairness is the study's core claim. The analysis half is a one-way pipeline: the campaign dataset is frozen after the campaign, and the link-budget, energy and cost modules read only the frozen artefacts, mirroring the discipline used in protocol-first studies. The data model is a single tidy table (point × technology × attempt) plus a small parameters table carrying every constant — frequencies, sensitivities, currents, prices — with its source citation, so an examiner can challenge any constant and see exactly where it enters the computation.

• Multi-gateway capacity study: deploy two or three gateways and measure ADR behaviour, downlink reliability and three-channel capacity limits empirically instead of theoretically.
• Second site, second city: repeat the campaign at a dense urban site and a rural site to replace the campus extrapolation with a three-site Indian propagation characterisation.
• Live meter pilot: integrate one commercial smart-water-meter reading head over the winning technology and run a month of real consumption data through the energy model.
• LTE-M and hybrid strategies: add LTE-M to the comparison and study a hybrid policy — LoRaWAN in dense blocks, NB-IoT at the fringe — as an optimisation problem.
• Security and spoofing analysis: measure LoRaWAN join behaviour under replayed frames and study NB-IoT platform authentication overheads, extending the study from connectivity to trust.