LoRaWAN explained: from sensor to gateway and server

LoRaWAN carries short device messages, such as a temperature reading or tank status, to a central application. A device sends a message using LoRa radio; a gateway receives it and forwards it over a data network to a server. It suits small, occasional reports rather than video, audio or immediate motor control.

Imagine a farm with 20 locations that report temperature every ten minutes. A sensor measures an environmental property such as temperature. The device beside it puts the reading into a message.

LoRa and LoRaWAN do different jobs

A wireless transmitter changes a radio wave to carry information. LoRa is one way of making those changes. LoRaWAN defines rules for device communication and message management, including message structure and joining a network. Two devices can exchange messages directly using LoRa without forming a LoRaWAN network.

A product described as a “LoRa module” therefore does not necessarily provide every part of a LoRaWAN system. A module is a ready-made assembly that handles part of a task; it may supply radio functions while still needing software and protocol support. The Things Network introduction explains the distinction.

What does a gateway actually do?

A gateway connects the radio side to a data network. It receives device messages and typically forwards them to a server using Ethernet, Wi-Fi or a cellular connection. A server is a computer running programs that receive and manage data. It need not be in a distant data centre: it can be within the site's private network.

In the ordinary path described here, devices are not paired to one particular gateway. If two gateways are within reach and hear the same message, both can forward a copy. Reception depends on obstacles, antennas, distance and link conditions; not every report reaches both. The LoRa Alliance backend interface document specifies the gateway's forwarding role.

A basic gateway does not decide whether a pump should start. Some products add a local application or an integrated server; distinguish those extra functions from the gateway role. Similarly, do not assume that an experimental single-channel receiver meets the requirements of the intended LoRaWAN network.

The network server and application have different responsibilities

The network server manages communication among devices and gateways and identifies duplicate copies of a message. The application gives the data meaning for a user: it might decode a value into degrees Celsius and put it on a chart. These roles can run on one computer, but they are different jobs.

If both farm gateways receive report 37 from device 7, the dashboard should not treat it as two independent measurements. Equal report numbers from two different devices do not make their measurements duplicates. Reaching the network server is not the whole task either. The application must understand the format and check whether the measurement is valid. The Things Network architecture guide places these components together.

A worked example: how much data do 20 sensors generate?

Assume each device reports once every ten minutes and carries eight bytes of application data per report. A byte contains eight bits, each a zero or one. Under a defined format, our eight bytes could represent a sample identifier, temperature and error status. This is an illustrative format, not a universal sensor message.

Reports per device per day = 24 × 60 / 10 = 144
Application data per device = 144 × 8 = 1152 bytes/day
Application data for 20 devices = 20 × 1152 = 23040 bytes/day

The total is 23,040 application bytes per day. That looks small, but byte count alone does not establish network capacity. Protocol information accompanies each message, and retries, joins and responses also consume communication resources. None is included in that total.

Airtime is how long a transmitted message occupies the radio channel. For illustration, assume one complete message takes 0.1 seconds; this is a teaching assumption, not a result calculated from radio settings. For one device making 144 transmissions, that is 144 × 0.1 = 14.4 s of daily transmission. Dividing by the 86,400 seconds in a day gives approximately 0.0167%. This ratio is not evidence of regulatory compliance or reliable network capacity.

Actual airtime depends on packet size and radio parameters. One parameter, spreading factor, participates in a trade-off: with bandwidth and other settings fixed, increasing it generally helps reception of weaker signals but lengthens transmission. A higher value is not automatically better. The spreading-factor guide explains the cost.

Why a return command may have to wait

A device-to-network message is an uplink; a network-to-device message is a downlink. In the common Class A mode, a device opens short receive opportunities after sending an uplink. If no reply arrives in those opportunities, the next downlink opportunity depends on another uplink. A device that reports every ten minutes therefore need not receive your command immediately.

Other classes provide different receiving patterns and may use more energy. Select them according to the product's needs. Without appropriate design and testing, none is a guaranteed emergency-stop path or a substitute for fast motor control. The device-class explanation describes the receive timing.

Check connectivity, coverage and security separately

• Gateway-to-server connectivity: If the gateway loses cellular or internet service, receiving a radio packet does not guarantee that the application sees it. Storage and later forwarding are not guaranteed features of every gateway; check the product. A local private server may work without the public internet but still needs its local network path.
• Coverage: Buildings, terrain, antenna installation and interference change the result. The name LoRaWAN cannot guarantee a distance. Check actual locations and the least favourable installation conditions.
• Regional settings: Frequency, power and transmission limits must match the installation's regulations and network plan. A module with the wrong band or antenna is not fixed by renaming a software setting. The illustrative airtime percentage above does not replace a regulatory check.
• Data protection: LoRaWAN includes encryption and message-integrity mechanisms, but secret keys and management systems still need protection. Match protocol version and device activation to the implementation documentation. Long range does not make communication anonymous or impossible to intercept.

The duty-cycle guide introduces transmission occupancy and regulatory considerations; its regional examples must not be applied to every country. The TTN LoRaWAN 1.0 security explanation is version-specific; do not carry its key details into version 1.1 without checking.

A useful check before choosing hardware

Trace one report on paper: was the measurement valid, did the device send it, did a gateway hear it, did the server receive it, and did the application decode it? Give each stage an observable sign, such as the report number and receive time. This separates a radio failure from a data-format problem when the chart is empty.

For the farm example, do not send a zero temperature as a valid reading when measurement has failed; include a separate error status. If two gateways log the same message from one device while the application records one measurement, deduplication may be working correctly. When reports reach the chart late, distinguish measurement time from receive time.

Continue with the sensor introduction for choosing an appropriate measurement, or the embedded systems learning path for how sensing, software and testing fit into a device. These examples are hypothetical calculations; no range measurement, battery test or radio transmission was performed for them.