2 LPWAN Fundamentals
Workload Fit, Radio Evidence, Technology Roles, and Review Records
LPWAN fundamentals, LoRaWAN, NB-IoT, LTE-M, low power wide area networks, IoT networking
2.1 Start Simple
Start with one sleepy device that sends a small reading and then disappears to save battery. If the application can wait, tolerate missed reports, and avoid heavy downlink, the device may be LPWAN-shaped. If it needs video, rapid control, or frequent updates, it is not. This chapter keeps that first fit decision visible before any technology name can make the design sound easier than it is.
Phoebe’s Why
Antenna gain in dBi is a real, honest trade: a directional antenna reshapes a fixed radiated power into a narrower cone, buying extra range in the direction it favors at the cost of the coverage angle it gives up everywhere else. That trade only pays off if the “direction it favors” is where the gateway actually is. This chapter’s own vineyard example scatters 1,200 soil nodes across open rows and pump sheds, mounted by different installers, at different tilts, over a growing season where posts lean and vines change what is nearby. A directional node antenna is a bet that its narrow beam stays pointed at one fixed gateway bearing through all of that – and unlike the gateway, which is deliberately built omnidirectional because it must hear every node, a field node has no such guarantee.
The Derivation
Gain and half-power beamwidth trade against each other for a roughly symmetric beam:
\[\theta \approx \sqrt{\frac{41253}{G}}\ \ (\theta\ \text{in degrees}, G\ \text{linear})\]
EIRP if the beam is aimed correctly:
\[\mathrm{EIRP}_{\mathrm{aimed}}(\mathrm{dBm}) = P_t(\mathrm{dBm}) + G(\mathrm{dBi})\]
EIRP toward the gateway if the beam has drifted off-axis, discounted by the antenna’s front-to-back/sidelobe ratio \(F\) (dB):
\[\mathrm{EIRP}_{\mathrm{mispointed}}(\mathrm{dBm}) = P_t(\mathrm{dBm}) + G(\mathrm{dBi}) - F(\mathrm{dB})\]
Worked Numbers: A 6 dBi Node Antenna, On-Axis vs. Off-Axis
Catalog-typical EU868 node, \(P_t=14\) dBm, comparing a 0 dBi omni reference to a 6 dBi directional patch (\(G=10^{0.6}=3.98\times\)):
- Beamwidth: \(\theta=\sqrt{41253/3.98}=101.8^{\circ}\) – the patch only guarantees full gain across about \(101.8/360=28.3\%\) of a full turn, close to the \(25.1\%\) solid-angle share (\(1/G\)) it covers
- Aimed correctly: \(\mathrm{EIRP}=14+6=20\) dBm – double the range of the omni reference (\(10^{(20-14)/20}=2.00\times\))
- Mispointed (catalog-typical 15 dB front-to-back ratio for a small patch): \(\mathrm{EIRP}=14+6-15=5\) dBm – 9 dB worse than the plain 0 dBi omni’s guaranteed \(14\) dBm in every direction
- Range consequence: \(10^{(5-14)/20}=0.355\), so a mispointed patch covers only about \(35.5\%\) of the omni’s guaranteed range
Gain is range you do not pay for in battery – but only while the antenna stays aimed. For a fixed point-to-point backhaul link that is a safe assumption; for the field node in this chapter’s own fit check, orientation is rarely controlled after installation, which is the physical reason most LPWAN end devices default to omnidirectional antennas and let the gateway, not the node, spend gain on directionality.
Overview: LPWAN Is a Workload Fit, Not a Magic Range Claim
Low-power wide-area networking is useful when devices mostly sleep, send compact messages, tolerate delayed delivery, and need coverage across a larger area than short-range links can conveniently provide. It is not a replacement for streaming, tight control loops, frequent downlink, or routine bulk transfer.
The first LPWAN question is therefore not which technology is best. The first question is whether the workload, region, coverage evidence, power model, downlink behavior, ownership model, and operations record make a wide-area low-power link credible.
For example, a municipal waste team might start with 8,000 fill-level sensors, each sending a 16-byte level, battery voltage, and fault flag every six hours. That is only four routine uplinks per bin per day, and a missed reading can wait until the next route-planning cycle. The same city should not put CCTV clips, real-time traffic-light actuation, or daily firmware images on the same LPWAN path, because those workloads change the payload, latency, and reliability assumptions.
A useful fundamentals record therefore splits the fleet before selecting a radio. Street bins, park-soil probes, and water-vault alarms may all be LPWAN-shaped, but they still need separate notes for antenna placement, enclosure loss, reporting cadence, downlink use, battery replacement window, and who investigates a silent device. The chapter's "fit" decision is a filter that keeps strong candidates moving and routes non-fit traffic to other networking chapters.
If a later requirement adds hourly photos, live actuator supervision, or technician tablet sync, the record should create a separate network path instead of silently stretching the LPWAN assumption.
Good Fit
Compact telemetry, infrequent events, sleep-first endpoints, patient downlink, and an owner for operations evidence.
Weak Fit
Continuous streams, large files, tight control loops, frequent commands, or unsupported gateway and service operations.
Evidence Needed
Workload record, regional profile, link budget, antenna plan, power model, downlink rule, and pilot observations.
Review Habit
Reject fixed claims. Ask what condition makes the statement true and what evidence would falsify it.
Practitioner: Compare Design Forces and Operating Models
LPWAN design is a trade-off among reach, energy, payload, latency, downlink, capacity, compliance, security, and ownership. Improving one dimension can weaken another. A recommendation should name the constraint that matters most and the evidence that supports it.
The technology families also have different operating models. Private LoRaWAN, public LoRaWAN, cellular LPWAN, and other managed narrowband services can all support wide-area IoT workloads, but they move gateway ownership, service dependency, certification, monitoring, keys, and replacement duties to different places.
Take a vineyard co-op with 1,200 soil nodes. If each node sends a 12-byte moisture and temperature sample every 30 minutes during irrigation season, the design has 48 routine uplinks per node per day before retries and alarms. A practitioner record should also state whether frost alarms need faster reporting, whether pump-shed metal roofs require external antennas, and whether commands are rare threshold changes or routine closed-loop control. The answer can change the family shortlist even when every candidate is called "LPWAN."
The operating model is just as concrete. A private-gateway plan needs mast locations, backhaul, gateway spares, keys, monitoring, and a field technician owner. A public-network plan needs service availability, account lifecycle, regional roaming assumptions, outage escalation, and an exit path if coverage changes. Comparing the radio without comparing those operating duties hides the actual deployment risk.
Under the Hood: Non-Fit Signals and Review Records
LPWAN review is strongest when it can say no. High-volume media, tight safety control, repeated large downloads, frequent cloud commands, unsupported operations, and unclear service ownership should route away from the LPWAN path or trigger a redesign.
The final output should be a review record. That record names the workload, region, technology-family candidate, evidence used, weak assumptions, mitigation, owner, and retest trigger. A technology name without that record is not enough for release.
A cold-chain pallet tag shows why the non-fit check matters. A five-minute temperature heartbeat is usually LPWAN-shaped if the payload is compact and delayed arrival is acceptable. The same product becomes a poor fit if it must upload a 250 kB calibration package through the low-rate radio every week. Even before protocol overhead, that download would require thousands of small payload fragments, long receive time, more battery energy, retry handling, and an operational plan for interrupted transfers.
The review record should make that boundary explicit: "temperature telemetry over LPWAN; calibration package over depot Wi-Fi or wired cradle." It should also name the owner for stale gateways, battery model drift, service subscription changes, enclosure revisions, antenna relocation, and region moves. Those triggers stop a valid pilot from becoming an unreviewed production assumption six months later.
A release-ready record also keeps arithmetic close to the decision. If a device normally sends 12 bytes every 15 minutes, the reviewer should record the daily message count, the alarm burst assumption, and the retry budget used in the pilot. If an enclosure swap reduces antenna clearance or a customer asks for ten times more samples, the old pass is no longer valid; the route returns to link budget, capacity, or another access technology before deployment expands.
Record the Claim
State the workload, region, candidate family, path, and design question being answered.
Name the Evidence
Attach measurements, power model, antenna assumptions, downlink rule, service dependency, and owner.
Route the Weakness
Send range claims to link budget, family choice to selection, architecture gaps to ownership review, and operations gaps to readiness checks.
Set the Retest Trigger
Reopen the decision when payload, cadence, region, antenna, endpoint, gateway, service, policy, or operations ownership changes.
2.2 Summary
LPWAN fundamentals are about workload fit and evidence. A good LPWAN design starts from compact, delay-tolerant messages; checks regional, radio, power, downlink, ownership, security, and operations assumptions; and records what would change the recommendation. The fundamentals route prepares you for link-budget, architecture, selection, and LoRaWAN-specific chapters without drifting into unsupported range or battery claims.
2.3 Key Takeaway
Use LPWAN when the workload is small, patient, and evidence-backed; reject or reroute claims that lack radio, power, downlink, ownership, and operations proof.
2.4 See Also
- LPWAN Link Budget and Range turns range claims into bounded radio evidence.
- LPWAN Architectures reviews gateway, network-server, service, and ownership paths.
- LPWAN Technology Selection compares candidate families and decision evidence.
- LoRaWAN Introduction connects LPWAN fundamentals to LoRa and LoRaWAN-specific behavior.