5 LPWAN Technology Selection
A remote tank reports its level four times a day, but a falling-level alarm may lead staff to close an inlet valve. Technology selection must separate the small routine reading from that return command. A low average traffic count can hide the harder requirement.
5.1 Start Simple
LoRaWAN is a low-power radio system for small messages over long paths. A payload is the useful data inside a message. Picture a farm tank that sends its level four times a day and an alarm only when the level falls fast.
Start with the job, not the brand. Write down the message size, send rate, distance, power source, reply need, and service owner. These facts remove choices that cannot meet the job before a sales claim enters the discussion.
Then test the hard case. Hills, walls, movement, local radio rules, weak return paths, and missing service can all defeat a good paper choice. A low send rate may save energy, yet it can also delay an urgent update.
This tank story cannot select a network for every site. It does not prove coverage, battery life, device supply, fees, or support. Those claims need a field test and a named owner.
Use the Practitioner sections to build the choice record and compare real options. Use Under the Hood for link limits, message timing, and power cost. The deeper work qualifies the first shortlist; it does not undo the need-first rule.
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.
The mathematical gist. The chapter’s 14 dBm transmitter is 25.12 mW. A 6 dBi antenna is 3.98× linear gain, producing a 20 dBm (100 mW) ideal EIRP screen while concentrating the favoured response into 3.16 sr, or 25.12% of a sphere. The same 2.00× ideal range from transmit power alone would require about 100 mW conducted power—74.9 mW more than the radio supplies. Geometry saves battery only when aim and regulation permit it.
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.
Pause before applying the “requirements”–“gate” decision, then inspect Figure 5.1. It places “requirements” against “Gate”, exposing the evidence behind this claim: A durable selection moves from requirements to evidence before it becomes a recommendation.
Notice how Figure 5.1 separates “requirements” from “Gate”. Now move to “hard” and finish at “constraints”; that second step reveals why A durable selection moves from requirements to evidence before it becomes a recommendation. Apply the distinction when “constraints” closes the record for the “requirements”–“gate” decision.
Start the evidence review for the “record”–“workload” decision: inspect Figure 5.2. Two labels deserve attention—“record” and “Workload”—because they bound The requirement record keeps workload, environment, power, mobility, ownership, and evidence visible before a technology name is chosen.
Read Figure 5.2 with “record” as the anchor; treat “Workload” as the first comparison. Then connect “payload, cadence, bursts” with “Environment”. Those labels make The requirement record keeps workload, environment, power, mobility, ownership, and evidence visible before a technology name is chosen a traceable part of the “record”–“workload” decision, not an unsupported assertion.
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.
Do not accept Hard gates prevent a comparison matrix from hiding a candidate that cannot meet the requirement as “region and service” prose alone. Look at Figure 5.3 before the “region and service”–“traffic” decision, where “region and service” is explicitly distinguished from “Traffic”.
Rather than scanning Figure 5.3, use “region and service” as the start. Relate it to “Traffic”, then carry “payload and cadence” toward “Downlink”. The labelled route demonstrates Hard gates prevent a comparison matrix from hiding a candidate that cannot meet the requirement and returns the result to the “region and service”–“traffic” decision.
Gate Sequence
"Region is fine" is not evidence for the Availability gate; the regional ISM band and its duty-cycle limit are. LoRaWAN's unlicensed band assignment is geography-specific: Europe uses 863-870 MHz (with a separate 433 MHz allocation in some deployments), the United States uses 902-928 MHz, Australia uses 915-928 MHz, and China splits across 779-787 MHz and 470-510 MHz. Only the region that matches the installed device's radio and channel plan is a valid candidate. Europe's 868 MHz band also carries a duty-cycle limit -- commonly 0.1% or 1% depending on the sub-band -- that caps how much airtime a device may use per hour; the US 915 MHz band uses a dwell-time limit instead of a duty cycle. A selection record should name the region, the exact band, and the applicable airtime limit, not just "the coverage map includes this site."
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.
Start the evidence review for the “candidates”–“private lorawan” decision: inspect Figure 5.4. Two labels deserve attention—“Candidates” and “Private LoRaWAN”—because they bound The matrix is strongest when every comparison cell points to evidence or an explicit assumption.
Read Figure 5.4 with “Candidates” as the anchor; treat “Private LoRaWAN” as the first comparison. Then connect “Public LoRaWAN” with “Cellular LPWAN”. Those labels make The matrix is strongest when every comparison cell points to evidence or an explicit assumption a traceable part of the “candidates”–“private lorawan” decision, not an unsupported assertion.
Evidence Fields to Inspect
Before carrying Pilot evidence should target the failure modes that matter to the chosen operating model into the “Coverage logs” design record, view Figure 5.5. It makes “Coverage logs” and “representative places and antenna positions” separate, inspectable parts of the “coverage logs”–“representative places and antenna positions” decision.
Notice how Figure 5.5 separates “Coverage logs” from “representative places and antenna positions”. Now move to “Delivery data” and finish at “routine, burst, retry, and outage behavior”; that second step reveals why Pilot evidence should target the failure modes that matter to the chosen operating model. Apply the distinction when “routine, burst, retry, and outage behavior” closes the record for the “coverage logs”–“representative places and antenna positions” decision.
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 Reject the Tank Link That Cannot Return the Command
Assume each level report carries 20 useful bytes. Four reports produce 80 bytes per day before transport and radio overhead. The selection record also requires a 12-byte valve command to arrive within 60 s. Selection must reject a six-hour receive schedule for that command, unless a separately tested mechanism supplies earlier opportunities.
For the worst scheduled wait, take a command arriving 1 s after the last receive opportunity. Six hours contain 21,600 s, so the next scheduled opportunity is about 21,599 s away. This is a workload assumption used to reject that operating policy. It is not a universal timing claim about every product using the technology.
Read Figure 5.3 from region and service through traffic and downlink. The selection should stop at a failed command requirement before assigning price scores. The same candidate might remain suitable for a tank that only logs level, because that is a different service promise.
Now compare a technology with a tested 30 s receive schedule. That schedule leaves at most about 30 s of waiting under normal operation, but the remaining deadline must cover transfer, queueing and application handling. Selection therefore needs an end-to-end command test and a clear loss response, not merely a shorter timer in a table.
Predict whether a high battery-life score can compensate for the missed valve deadline. Technology selection cannot trade a missed hard requirement for battery savings. Next, suppose the site has no supported service for the otherwise suitable technology. Selection stays blocked for that candidate until the missing infrastructure and operating responsibility are resolved.
A sound selection may separate sensing from control, add a local safe action or revise the product promise. State which choice is actually being tested. The module’s wider comparison becomes useful only after these constraints remove impossible options. Antenna gain, payload limits and operating cost then help compare the survivors rather than disguising a link that cannot perform the tank’s essential task.
5.3 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.4 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.