LoRaWAN Networks

LoRaWAN is a long-range, low-power networking standard built for sensors, meters, trackers, alarms, and other Internet of Things devices. It allows small amounts of data to travel over several kilometres while a battery-powered device may continue operating for months or years.

Although LoRaWAN and Meshtastic both use LoRa radio modulation, they are different systems designed for different jobs. LoRaWAN connects devices to gateways and online applications. Meshtastic connects people and nodes directly through a peer-to-peer mesh. A LoRaWAN gateway cannot relay Meshtastic messages, and a normal Meshtastic node does not become part of a LoRaWAN network.

This section introduces the main parts of the LoRaWAN ecosystem: public and community gateways, network servers and communities, practical sensor deployments, and the choice between LoRaWAN and Meshtastic.

What is LoRaWAN?

LoRa is the radio modulation used to carry a signal over the air. LoRaWAN is a standardized communication protocol and network architecture built on top of LoRa. The distinction matters: devices can use the same type of radio chip while speaking completely different protocols.

A typical LoRaWAN message follows this path:

An end device, such as a soil-moisture sensor, transmits a short LoRaWAN packet.
Every compatible gateway within range may receive the same packet.
The gateways forward it over Ethernet, Wi-Fi, or cellular internet to a network server.
The network server removes duplicate copies, checks the LoRaWAN network information, manages radio parameters, and routes the message.
An application server decodes the sensor payload and delivers useful data to a dashboard, database, alerting system, or another application.

The LoRa Alliance describes LoRaWAN as a star-of-stars architecture. End devices normally communicate in a single radio hop with one or more gateways. Gateways connect through IP to central network services. This is not a radio mesh in which ordinary devices relay one another’s packets.

The main parts of a LoRaWAN network

Part	What it does	Example
End device	Measures, tracks, detects, or controls something and exchanges short radio messages.	Water meter, weather sensor, livestock tracker, valve controller
Gateway	Receives LoRaWAN radio packets and forwards them to the internet; it can also transmit scheduled downlinks.	Outdoor multi-channel gateway on a roof or tower
Network server	Manages the LoRaWAN network layer, duplicate packets, device sessions, radio parameters, and downlink selection.	The Things Stack, ChirpStack
Application server	Decodes application payloads and connects the data to software and users.	Farm dashboard, asset-tracking platform, flood alert system

A gateway is therefore closer to a radio-to-internet bridge than to a Meshtastic router. It does not need to understand the temperature, position, or meter reading contained in the application payload. The The Things Stack architecture guide provides a useful introduction to this division of responsibilities.

Public and community LoRaWAN gateways

You do not always need to install your own gateway. Public and community networks let individuals, universities, municipalities, companies, and volunteer groups contribute coverage that other registered devices may use under the network’s rules.

The Things Network is a well-known community LoRaWAN ecosystem. Helium IoT uses independently operated hotspots and an incentive-based model. Organizations can also build local or regional networks with open-source software such as ChirpStack.

Coverage maps are useful for discovering gateways, but a marker does not guarantee that your device can join a network or receive reliable service at ground level. Buildings, hills, vegetation, antenna height, gateway availability, regional frequency plans, and network access policies all matter.

Read Public and Community LoRaWAN Gateways for gateway maps, hardware, realistic range, operating costs, and community responsibilities.

Network servers and communities

The network server is the coordinating intelligence behind a LoRaWAN deployment. If several gateways hear one uplink, the server recognizes the duplicate copies rather than presenting several sensor readings. It also manages device sessions, adaptive data rate, MAC commands, regional parameters, and the choice of gateway for a downlink. The The Things Stack network-server documentation explains these responsibilities in greater technical detail.

There is no single universal LoRaWAN network. A device must be registered with a network server and provisioned with the correct identifiers and cryptographic keys. A nearby gateway may belong to TTN, Helium, a private ChirpStack installation, or a commercial operator. Networks can sometimes exchange traffic through roaming or packet-broker arrangements, but this should never be assumed merely because a gateway is nearby.

Community participation can provide shared coverage and local expertise. Private networks offer more control over data, gateway placement, service levels, integrations, and maintenance. The right choice depends on whether the project is an experiment, a community service, or infrastructure on which a business or public-safety process will depend.

Continue with LoRaWAN Network Servers and Communities for a comparison of community, commercial, and self-hosted approaches.

Sensor and IoT deployments

LoRaWAN works best when devices need to send small, occasional messages over a long distance while using very little energy. Common deployments include:

soil moisture, weather, irrigation, and livestock monitoring;
water, electricity, gas, and heat metering;
parking, waste-bin, street-light, and environmental sensors;
building temperature, leakage, occupancy, and equipment monitoring;
asset location, condition reports, and geofence alerts;
flood, wildfire, landslide, and infrastructure-warning sensors.

It is not intended for video, audio streaming, large files, rapid remote control, or continuous location updates. LoRaWAN has a small radio-data budget, and downlinks are more constrained than uplinks. A good deployment sends compact measurements only when needed and performs as much filtering as practical on the device.

Successful projects require more than radio range. They need appropriate sensors, battery calculations, weatherproof enclosures, installation planning, device provisioning, data decoding, monitoring, alerts, security, and a maintenance strategy. Read LoRaWAN Sensor and IoT Deployments for practical examples and deployment planning.

LoRaWAN vs. Meshtastic

Question	LoRaWAN	Meshtastic
Main purpose	Connect sensors and actuators to applications	Off-grid messaging, location sharing, and telemetry between mesh nodes
Radio topology	Single-hop devices to gateways; star-of-stars backend	Peer-to-peer mesh with packet rebroadcasting
Internet dependency	Normally required between gateways and servers	Not required; MQTT bridging is optional
Infrastructure	Gateway, network server, application integration, and registered devices	Meshtastic-compatible nodes; phones or computers are optional clients
Best fit	Managed fleets of low-data IoT devices	Human communication and small independent community meshes
Interoperability	They do not communicate directly, even when operating in the same frequency band.

Choose LoRaWAN when many managed sensors must deliver structured data to a server or application. Choose Meshtastic when people or portable nodes need direct, infrastructure-independent communication. Some projects may use both systems side by side, but that requires separate radio protocols and an application-level integration if data must cross between them.

The official Meshtastic FAQ confirms that Meshtastic uses LoRa peer-to-peer communication rather than LoRaWAN. Read LoRaWAN vs. Meshtastic: Which to Choose and When for a fuller decision guide.

Worldwide frequency plans and regulations

LoRaWAN is worldwide, but its radio settings are not universal. Europe commonly uses the EU868 plan, the United States uses US915, Australia commonly uses AU915, and other countries use plans such as AS923, IN865, KR920, or region-specific variants. Channel plans, duty-cycle limits, permitted power, dwell-time rules, and certification requirements differ by country.

A device, gateway, and antenna must support the correct local frequency range and regional LoRaWAN parameters. Hardware labelled only “868 MHz” should not be assumed suitable for a 915 MHz deployment, and a US915 device is not automatically legal or functional in Europe. Consult the current LoRaWAN Regional Parameters and the national radio regulator for the installation location before buying or configuring equipment.

Where to begin

If you want to experiment using existing coverage, first identify the network and gateways available near you. Then confirm that your device supports the correct regional plan and can be registered on that network. If coverage is absent or the application requires guaranteed control, evaluate a private gateway and network server.

If your goal is off-grid text communication rather than sensor-to-cloud connectivity, begin with What Is Meshtastic and How It Works. If your goal is a long-lived sensor fleet, continue through the four LoRaWAN guides in this section before selecting hardware.