LPWAN Technologies Explained: LoRaWAN, NB-IoT, LTE-M, and Sigfox

Low-power wide-area networks (LPWANs) connect sensors and other constrained devices across large areas while sending small amounts of data with limited energy. They are useful for meters, trackers, and environmental sensors that cannot rely on nearby Wi-Fi or frequent battery replacement. This guide explains the architecture behind LPWAN, compares LoRaWAN, NB-IoT, LTE-M, and Sigfox, and shows how to evaluate a deployment without relying on advertised range or battery-life claims.

What Is an LPWAN?

An LPWAN is a class of wireless network designed for devices that exchange small, occasional messages over a wide area. The design prioritizes low energy use, coverage, and the ability to connect many simple devices over high throughput. A sensor might send a water-meter reading several times a day, then spend most of its time asleep.

LPWAN is a category, not one radio standard. LoRaWAN and Sigfox generally use unlicensed spectrum and their own network models. NB-IoT and LTE-M are cellular technologies standardized by 3GPP and delivered over licensed spectrum by mobile operators. Their coverage, subscription model, mobility support, payload limits, and power use differ.

LPWAN also describes connectivity, not the complete IoT application. A radio network carries data to a gateway or cellular core; software then authenticates devices, routes readings, stores them, and raises alerts. An application protocol such as MQTT may be used farther along the path, often after a gateway or network service translates the device traffic.

Why LPWAN Exists

Wi-Fi and cellular broadband are convenient, but their power, coverage, cost, or infrastructure requirements can be a poor fit for a sensor that sends a few bytes from a field, basement, utility cabinet, or moving asset. Short-range radios can be efficient but need a nearby phone, access point, or gateway. LPWAN fills the gap for low-volume telemetry where a long communication range and long sleep intervals matter more than speed.

That trade-off is deliberate. LPWAN is generally unsuitable for continuous audio or video, large firmware downloads, or control loops that require frequent low-latency exchanges. A radio’s maximum theoretical range does not guarantee coverage at a particular site: antenna placement, walls, terrain, interference, regional regulations, network density, and device configuration all affect results.

Battery life is similarly conditional. A device’s radio may consume little energy while asleep, but sensor warm-up, network registration, retransmissions, receive windows, weak signal conditions, and firmware behavior can dominate the energy budget. Estimate and measure the complete device workload rather than assuming that choosing an LPWAN standard guarantees years of operation.

How LPWAN Works

An LPWAN deployment usually contains an end device, a radio access point or cellular base station, network infrastructure, and an application service:

sensor or meter
  -> short radio message
  -> LoRaWAN gateway / Sigfox base station / cellular base station
  -> network server or mobile operator core
  -> application integration
  -> storage, alerts, and device-management service

In a LoRaWAN network, an end device sends a radio frame that may be received by one or more gateways. Gateways forward frames over IP to a network server; they usually relay traffic rather than making application decisions. The network server handles network-level functions such as deduplication and routing, while an application service consumes the device data. The LoRa Alliance describes this as a star-of-stars architecture. LoRa is the radio physical layer; LoRaWAN defines the network protocol and related behavior.

NB-IoT and LTE-M instead use an operator’s cellular radio access network and core. A device with a supported modem and SIM or eSIM registers with a mobile network and sends data through the operator’s infrastructure to an application endpoint. Our eSIM remote provisioning architecture guide explains how downloadable profiles are delivered and managed. Power-saving mode (PSM) and extended discontinuous reception (eDRX) can reduce energy use, but their actual behavior depends on the modem, network configuration, coverage, and application traffic.

Sigfox 0G devices send small messages to nearby base stations operated by local service providers. The Sigfox network service then passes the data to the customer’s platform. UnaBiz currently owns the Sigfox 0G technology and works with local providers; availability and service terms therefore need to be checked for the deployment location.

Uplink and downlink capabilities are not always symmetrical. Some LPWAN designs make it practical to send occasional sensor readings but constrain how often a device can listen for commands or receive a large response. A system that requires frequent remote control, acknowledgments, or over-the-air updates must account for those constraints before choosing a radio.

LPWAN Components and Variants

This table describes broad design tendencies, not guaranteed performance. LPWAN throughput, range, latency, and battery life cannot be compared reliably using a single number across regions, devices, and deployments. For LoRaWAN, consult the LoRa Alliance’s overview of the standard and regional parameters before selecting bands or configuring equipment. For cellular technologies, the 3GPP specification series and E-UTRA radio-access specifications are the standards references. The Sigfox 0G overview describes its current service model and message design.

Real-World LPWAN Use Cases

• Utility metering: Water, gas, and electricity meters can send periodic readings without a local broadband connection. Confirm indoor coverage, meter installation constraints, and how frequently the system needs to read or configure a meter.
• Agriculture and environmental monitoring: Soil, weather, and water sensors can report low-volume measurements across fields or remote sites. Plan gateway placement or verify cellular-provider coverage, and retain local data if communications are temporarily unavailable.
• Asset and logistics tracking: A tracker can report status or location-related data at intervals or after an event. Mobility, roaming, battery replacement, message frequency, and the ability to locate an asset indoors may matter more than peak range.
• Building and city infrastructure: Parking, lighting, leak detection, and air-quality sensors can connect over an area without giving every sensor a broadband radio. Dense urban deployments still need a coverage survey and a plan for gateway or provider outages.

In each case, the application should decide what happens when a message is delayed, duplicated, or lost. A reading can often be retried or stored for later delivery; a time-sensitive alarm or command may need a local fallback.

Practical LPWAN Selection and Deployment

Start with measurable requirements before choosing a module or network:

1. Describe the traffic: Record payload size, messages per day, expected bursts, downlink frequency, and the maximum acceptable delay. Include provisioning and firmware-update traffic.
2. Measure the environment: Survey the actual installation points, antenna positions, building materials, terrain, and movement patterns. Confirm provider coverage at the precise sites rather than relying on a nationwide map.
3. Choose the operating model: Decide whether to deploy and maintain gateways, use a community or public network, or buy cellular connectivity from an operator. Include recurring subscriptions, roaming, gateway backhaul, and support in the cost estimate.
4. Check regional and product constraints: Verify permitted frequencies and duty-cycle or channel rules, certified hardware, operator support, device availability, and the expected service lifetime. LoRaWAN regional parameters are not interchangeable between regions.
5. Design for security and recovery: Give each device a unique identity and protect its credentials. Define who can issue downlinks, how data is authenticated, how devices receive verified updates, and how the application behaves during network outages.
6. Test with real hardware: Measure current through sensor startup, network attach, transmission, receive windows, retries, and sleep. Test at weak-signal locations and during provider or gateway outages before scaling.

The following small Python estimate illustrates how message frequency and radio-on time affect a battery budget. It is an optimistic lower-bound model: it excludes sensor current, network attachment, receive windows, retries, self-discharge, and battery-capacity derating.

def ideal_battery_days(
    capacity_mah: float,
    sleep_current_ma: float,
    transmit_current_ma: float,
    transmit_seconds_per_report: float,
    reports_per_day: int,
) -> float:
    if capacity_mah <= 0 or sleep_current_ma < 0 or transmit_current_ma <= 0:
        raise ValueError("Capacity must be positive and currents must be non-negative")
    if transmit_seconds_per_report <= 0 or reports_per_day < 0:
        raise ValueError("Transmit duration must be positive and report count non-negative")

    transmit_hours_per_day = reports_per_day * transmit_seconds_per_report / 3600
    if transmit_hours_per_day > 24:
        raise ValueError("Transmit time cannot exceed 24 hours per day")

    average_current_ma = (
        transmit_current_ma * transmit_hours_per_day
        + sleep_current_ma * (24 - transmit_hours_per_day)
    ) / 24
    if average_current_ma <= 0:
        raise ValueError("Average current must be greater than zero")

    return capacity_mah / average_current_ma / 24


days = ideal_battery_days(
    capacity_mah=2400,
    sleep_current_ma=0.015,
    transmit_current_ma=45,
    transmit_seconds_per_report=5,
    reports_per_day=96,
)
print(f"Idealized estimate: {days:.0f} days")

Use measured values for the selected sensor, modem, antenna, network, and reporting schedule. For a test setup that includes a gateway and local services, see the home-lab hardware guide. The IoT gateway architecture guide explains how gateways bridge device networks to applications, while the IoT data-processing architecture guide covers where to filter and retain readings.

Common LPWAN Misconceptions

• “LPWAN means one protocol.” It is a category that includes different network models, spectrum choices, and service providers.
• “LoRa and LoRaWAN are interchangeable.” LoRa describes a radio modulation; LoRaWAN specifies a network protocol that can use LoRa radios.
• “A published range guarantees coverage.” Field performance depends on antennas, obstacles, interference, radio settings, and infrastructure. Survey the actual site.
• “Every LPWAN device runs for years on one battery.” Battery life depends on the whole workload, including retries, sensor use, downlinks, signal quality, and network registration.
• “Cellular IoT works anywhere a phone works.” NB-IoT and LTE-M support is specific to operators, bands, devices, and locations. Verify current coverage and service commitments.
• “LPWAN is appropriate for every IoT device.” It is designed for small, intermittent exchanges. Applications that need high throughput, frequent control, or substantial data transfer need another link or a hybrid design.
• “Unlicensed spectrum has no operating rules.” Regional frequency plans and radio regulations still apply; the device and network must follow the rules for the deployment location.

Related Articles

• IoT network protocols and how their layers fit together
• How to choose an IoT communication protocol
• IoT gateway architecture and protocol translation
• Edge, fog, and cloud IoT data-processing architectures
• Managing fleets of IoT devices
• Home-lab hardware for testing IoT projects

For primary technical references, see the LoRaWAN standard overview, the LoRa Alliance’s regional parameters, the 3GPP specification series, the 3GPP E-UTRA specification archive, and Sigfox 0G technology documentation.