5 LPWAN Technology Selection
Requirements, Hard Constraints, Operating Models, Evidence, and Recommendation Records
LPWAN technology selection, LoRaWAN selection, NB-IoT selection, LTE-M selection, LPWAN requirements, selection evidence
5.1 Start Simple
Begin with the job, not the radio label. A soil probe, a moving trailer, and a basement alarm may all need low-power wide-area service, but they do not create the same evidence problem. Write down the payload, cadence, mobility, power source, downlink need, coverage proof, and operating owner first. Only then does the shortlist become a review decision instead of a preference contest.
Phoebe’s Why
An isotropic antenna is a bookkeeping fiction: it spreads a transmitter’s power evenly over the full sphere around it, \(4\pi\) steradians of coverage, and nothing real quite does that. A directional antenna instead reshapes the same total power into a narrower cone, so whatever solid angle it gives up in coverage, it gives back as extra power density inside the cone it keeps – that is what a gain number in dBi is quoting. EIRP folds transmit power and antenna gain into a single number because a receiver a kilometer away cannot tell whether it is being reached by a strong radio with a plain antenna or a weaker radio with a well-aimed one. That equivalence is also a battery lever: gain is range you get from geometry, not from current draw.
The Derivation
Isotropic power density at distance \(d\):
\[S_{iso} = \frac{P_t}{4\pi d^2}\]
A gain antenna concentrates the same power into a smaller solid angle \(\Omega\), related to gain by:
\[G = \frac{4\pi}{\Omega}\]
so the power density becomes:
\[S = \frac{P_t G}{4\pi d^2}\]
Effective isotropic radiated power, and its dB form:
\[\mathrm{EIRP} = P_t \times G \qquad \mathrm{EIRP}_{dBm} = P_{t,dBm} + G_{dBi}\]
Because path loss falls as \(1/d^2\), range scales with the square root of gain at fixed sensitivity and fixed \(P_t\):
\[d \propto \sqrt{G}\]
Worked Numbers: EU868 Power Budget
- Catalog-typical EU868 default: \(P_t=14\) dBm \(=10^{1.4}=25.1\) mW conducted, dipole antenna \(G=2.15\) dBi \(=10^{0.215}=1.64\times\). EIRP \(=14+2.15=16.15\) dBm \(=41.2\) mW – this lines up with the region’s familiar 25 mW ERP limit, since ERP and EIRP differ by exactly the 2.15 dB dipole reference.
- Gain-for-range, same \(P_t\): swap the dipole for a 6 dBi sector antenna. \(G=10^{0.6}=3.98\times\), so range grows by \(\sqrt{3.98}=1.995\times\) (about double) while the covered solid angle shrinks to \(1/3.98=25.1\%\) of the sphere – the trade the brief names directly.
- Tie to battery/energy physics: reaching that same 2.00x range by raising transmit power instead would need \(4\times P_t = 4\times25.1=100\) mW \(=20.0\) dBm – a battery-draining jump in conducted power. The antenna-gain route buys the identical range without asking the battery for a single extra milliwatt; only the antenna and its aim change.
Overview: Selection Is an Evidence Record
LPWAN technology selection should not start with a favorite network name. It should start with a short record of the device workload, placement, power target, mobility pattern, ownership model, security boundary, lifecycle need, and evidence available for the real deployment.
The useful question is not "Which LPWAN is best?" The useful question is "Which candidate can satisfy this requirement, in this region, under this operating model, with evidence that another reviewer can inspect later?"
For example, an irrigation district may have three device groups that look similar at first glance: canal-gate level sensors, concrete-vault pressure alarms, and mobile maintenance trailers. The level sensors may tolerate delayed uplinks and no routine downlink. The pressure alarms may need stronger indoor evidence and a support owner who can inspect missed reports. The trailers may need mobility and service continuity outside the private-gateway footprint. A useful selection record splits those groups before scoring technologies, because a single "LPWAN" label can hide different ownership, coverage, battery, and downlink constraints.
The overview record should also preserve the rejected paths. If private LoRaWAN is kept, the record should say who owns gateways, backhaul, server operations, and field diagnostics. If NB-IoT or LTE-M stays in the shortlist, it should name operator availability, identity management, power-mode proof, and subscription risk. If a non-LPWAN path is removed, the record should explain whether the blocker was power, cost, mobility, data volume, local infrastructure, or support burden. That evidence makes the later recommendation auditable rather than personal preference.
Requirement
Record payload size, reporting cadence, burst behavior, downlink need, placement, antenna limits, battery access, and expected service life.
Constraint
Remove candidates that cannot satisfy region, coverage, mobility, power, payload, duty, certification, or operations boundaries.
Operating Model
Compare owned gateways, shared LoRaWAN service, operator-managed narrowband service, cellular IoT, satellite, local aggregation, or non-LPWAN paths.
Recommendation
Name the chosen path, rejected paths, evidence, assumptions, risks, pilot checks, owner, and change triggers.
A selection is weak if it says only "long range," "low power," "cellular," or "cheap." It is stronger when the record names the requirement and the evidence that removes or keeps each candidate.
Practitioner: Gate the Shortlist Before Scoring
A practitioner should separate hard constraints from preferences. A candidate that cannot operate in the required region, cannot meet the practical traffic model, cannot support the downlink behavior, or has no credible coverage evidence should not survive just because it looks familiar in a comparison table.
After the hard gate, compare the remaining choices by operating responsibility. Private LoRaWAN asks the organization to own gateway placement, backhaul, network-server operations, monitoring, and incident response. Public or community LoRaWAN depends on service terms and coverage evidence. NB-IoT and LTE-M depend on operator service, device support, subscription terms, and the behavior required by the workload.
Gate Sequence
Under the Hood: The Matrix Is a Trace, Not a Score
Under the hood, a selection matrix is useful only when each row has evidence, an assumption, a risk, and a validation check. A numeric score without those fields can make a weak decision look precise while hiding the condition that will break the deployment.
The matrix should show why each candidate remains, why each rejected path was removed, and what pilot evidence must be collected before the recommendation can scale. It should also name the trigger that reopens the decision when the region, operator, firmware, payload, enclosure, gateway plan, fleet size, or maintenance model changes.
Evidence Fields to Inspect
One successful farthest-point uplink does not prove coverage, capacity, downlink behavior, battery life, key handling, service continuity, or operations readiness.
Recommendation Record
- Name the selected path, region, operating model, device or service boundary, and owner.
- Record rejected paths with the evidence or hard gate that removed each one.
- Link the chosen path to pilot evidence, source documents, service terms, and device behavior.
- State assumptions about coverage, power, downlink, mobility, lifecycle, security, and support.
- List risks, mitigations, rollout gate, owner, and change triggers that reopen the selection.
5.2 Summary
- LPWAN technology selection starts with the deployment requirement, not a favorite network name.
- Hard gates remove candidates that fail availability, workload, field, power, downlink, mobility, security, or operations constraints.
- Operating model matters: owned gateways, shared LoRaWAN, operator-managed service, cellular IoT, satellite, local aggregation, and non-LPWAN paths create different responsibilities.
- A matrix is useful only when every comparison is tied to evidence, assumptions, risks, mitigations, and validation checks.
- A recommendation should record the chosen path, rejected paths, pilot evidence, owner, rollout gate, and change triggers.
5.3 Key Takeaway
Select an LPWAN path only after the requirement, hard constraints, operating owner, pilot evidence, rejected options, and retest triggers are visible in the record.