One Radio Technology for 6,000 Water Meters across Basement Pits and Open Suburbs
A municipal utility is deploying 6,000 smart water meters and wants one radio technology for the whole city. Area A is the dense old town: meters sit in concrete pits roughly 2 m below grade, field measurements show RSRP around -128 dBm and SINR of -6 dB at pit level, and there is no mains power at the pits. Area B is a new suburb where meters sit in outdoor plastic boxes at RSRP around -95 dBm. Each meter must send one 200-byte reading per day at midnight, and billing also needs an on-demand read for disputed accounts to complete within 24 hours. Meters run on a 3.6 V, 3.6 Ah A-size Li-SOCl2 cell and the tender promises eight years of life. One hilltop site can cover Area B with a LoRaWAN gateway, but covering Area A with LoRa would need about 14 gateway sites with backhaul. Utility IT will not open any inbound port into its data centre; all data must terminate in a cloud IoT platform.
1. Recommend a radio technology per area and support the choice with link-budget and total-cost reasoning rather than product preference.
Read the worked answer
Area B is easy: both options work, so decide on operational cost. LoRa is attractive because one hilltop gateway covers it and there is no subscription, but the utility then owns a gateway, its backhaul, its power and its failure response, and the unlicensed band imposes duty-cycle limits on downlink. NB-IoT removes all of that and terminates directly in the operator network, feeding a cloud platform without opening any inbound port at utility IT. At -95 dBm the link is comfortable, so choose NB-IoT for Area B on lifecycle simplicity, with LoRa as a fallback only if the operator's coverage claim fails at survey.
Area A is the real decision. LoRa there means 14 sites with backhaul and power, a permanent capex and maintenance footprint, for 5% of the city. NB-IoT's advantage is coverage enhancement: narrowband operation in 180 kHz, repetition-based uplink and a maximum coupling loss around 164 dB, roughly 20 dB better than GPRS, which is exactly the margin a 2 m concrete pit demands. At -128 dBm with -6 dB SINR, expect coverage enhancement level 2 or 3 with many repetitions.
So the defensible answer is NB-IoT city-wide, but conditional: trial 30 pits first, measure achieved repetition counts and energy per uplink, and route an external antenna to the pit lid before committing 2,000 units. Keep LoRa as a documented fallback for the worst few percent.
2. Build the eight-year energy budget and state what it implies about repetitions and battery life in Area A.
Read the worked answer
Eight years is 70,080 hours. 3.6 Ah over that period allows 3,600,000 uAh / 70,080 h, about 51 uA average. That is the entire budget, including sleep leakage.
Now price one daily uplink. Attach plus a 200-byte message might take 6 s at 90 mA: 540 mAs, or 0.15 mAh. Add 2 s of tail and a few retries, call it 0.25 mAh/day. Over 8 years: 0.25 x 365 x 8 = 730 mAh, about 20% of the cell. Most of the remaining budget is therefore sleep current, not radio traffic. The module's power-saving-mode leakage plus MCU quiescent current must sit in the low single-digit microamps; anything above about 20 uA in sleep destroys the guarantee regardless of how clever the uplink is.
The same arithmetic destroys Area A if repetitions are unbounded. At coverage enhancement level 2 or 3 an uplink can stretch to 20 or 30 s at 100 mA: about 0.8 mAh/day, which is 2,300 mAh over eight years, plus retries. That, not the cell, is what breaks the tender.
The engineering conclusion is to cap repetitions, prefer multi-tone 15 kHz uplink where the link allows, avoid daily downlink entirely, and promise eight years only where measured repetition counts stay low. In the deepest pits, quote five years or specify a larger cell rather than signing a number the physics will not honour.
3. How do you deliver a 24-hour on-demand read when the meters use power-saving mode, and how does data reach a cloud platform with no inbound ports?
Read the worked answer
Power-saving mode makes the meter unreachable except during its tracking-area-update wake-ups. If the periodic TAU is 24 hours, a read requested one minute after a wake-up waits almost a full day and just barely meets the promise, with zero margin. Three options:
- Shorten TAU to 6 hours for all meters. Simple, but every meter pays the attach cost four times a day forever, for a feature used a few times a month.
- Enable extended discontinuous reception with a paging cycle of tens of seconds alongside power-saving mode. The network can then page the meter within a minute or two. It costs more listening energy and requires operator support in the subscription profile.
- Use the uplink as an open window. When the meter reports at midnight it stays awake for 30 to 60 s; the platform queues the read and delivers it in that window. This is free when the request arrives near the report, and useless otherwise.
The pragmatic design combines 2 and 3: extended DRX enabled in the subscription, a short post-uplink receive window, and a queued request model in the platform so the billing team sees pending rather than an error.
For transport with no inbound ports: the meter is always the initiator. Use CoAP or LwM2M over DTLS to the platform or to the operator's exposure endpoint, with the platform pushing commands as queued resources or desired-state properties that the meter reads on its next contact. Never design around the platform dialling the meter.