LoRaWAN Network Technical Overview
The Internet of Things (IoT) encompasses a network of interconnected hardware and software that communicates wirelessly to collect, analyze, and share data. This smart, responsive digital intelligence is pivotal in monitoring and control systems across various applications, environments, and industries.
How LoRaWAN Works in IoT Systems
The Internet of Things (IoT) is a network of connected hardware and software that wirelessly transmits data to and from the internet. This allows information to be collected, analysed, and shared in real-time, enabling smarter, more responsive systems. IoT is widely used across industries for monitoring, automation, and control in diverse environments.
LoRaWAN, short for Long Range Wide Area Network, is a wireless communication protocol built for low-power and low-cost IoT deployments. It enables two-way communication between sensors (end-devices) and network servers through gateways. While the gateway connects to the server via standard IP methods like Ethernet, Wi-Fi, or 4G, it communicates with end-devices using a radio frequency (RF) link known as LoRa. Essentially, the gateway acts as a translator, converting RF packets from devices into IP packets for cloud transmission and vice versa.
Understanding LoRaWAN Network Topology
LoRaWAN uses a star-to-star network topology, where each end-device communicates with any gateway in range via a single-hop radio link. This efficient architecture enhances coverage and redundancy. The RF communication protocol—LoRa—was developed by Semtech using Chirp Spread Spectrum (CSS) modulation to support low-power, long-range transmissions. In Australia, LoRa operates on 72 channels: 64 uplink channels spaced at 200kHz with 125kHz or 500kHz bandwidth, and 8 downlink channels spaced at 1.6MHz with 500kHz bandwidth. This setup allows for robust, energy-efficient communication over distances exceeding 10km in rural areas, with excellent noise immunity. See below for a detailed table of Australian frequency allocations.
AU915 LoRaWAN Frequency Configuration
Telemetry2U configures end-devices and gateways to operate on channels 8 to 15 of the AU915 LoRaWAN frequency plan. While frequency allocations vary globally, all hardware shipped by Telemetry2U is preconfigured and tested for your region, ensuring devices connect to the network immediately upon power-up—no manual setup required.
LoRaWAN Device Class Modes
LoRaWAN nodes can operate in three classes: A, B, and C. Telemetry2U supports Class A and Class C only.
Class A
Class A enables bi-directional communication initiated by the end-device. After every uplink, two receive windows open at one and two seconds respectively. A single downlink message—either a confirmation or a control command—can be delivered. The device returns to low power mode after the windows close. Although commands can be queued at any time, only one can be delivered per uplink. This is the most common and energy-efficient class.
Class B
Class B uses synchronised beacons to open additional scheduled receive windows between uplinks, offering more chances to deliver downlinks. Telemetry2U does not currently support this class.
Class C
Class C keeps the receive window open continuously, except when the end-device is transmitting. This results in low-latency control but significantly higher power usage. It is not suitable for battery-powered devices. Telemetry2U recommends Class C only for externally powered devices like the LT22222L I/O Controller and RS485LN.
Understanding LoRaWAN Data Rates (DR)
LoRaWAN Data Rates (DR) are determined by two key parameters: spreading factor (SF) and bandwidth. Bandwidth indicates how much data can be sent per second, while the spreading factor defines the chirp duration used to transmit that data. SF ranges from SF7 (shortest chirp) to SF12 (longest chirp), with each step up doubling airtime. Higher data rates mean shorter airtime, reduced power use, and less range; lower data rates offer longer range at the cost of power efficiency.
In Australia’s AU915 band, the maximum transmit power is +30 dBm, although +20 dBm is sufficient for most scenarios. Uplink airtime is generally capped at 400 ms per packet, but Telemetry2U disables this restriction through a server-side command, ensuring uninterrupted communication even for longer packets.
There are 13 total DRs available on the AU915 plan. DR0–DR7 are used for uplinks and operate at 125 kHz bandwidth (except DR6 at 500 kHz). DR8–DR13 are uplink-only and all use 500 kHz. Downlink DR is chosen to match the spreading factor of the uplink. For instance, DR3 uplinks (SF9) receive downlinks via DR11 (also SF9). An exception is DR6, which uses DR13 for downlink, the same as DR5.
LoRaWAN Adaptive Data Rate (ADR)
Telemetry2U makes use of LoRaWAN’s Adaptive Data Rate (ADR) feature to optimise network efficiency. When enabled, the server automatically adjusts the Data Rate (DR) and Transmit Power (TXP) over roughly 20 transmission cycles, based on factors such as packet length, packet loss, signal strength (RSSI), and gateway load.
ADR increases network capacity since different DRs are nearly orthogonal—allowing multiple devices to transmit on the same channel without interference. In some scenarios, the server may reduce the DR while also lowering transmit power to balance network usage and conserve energy.
For mobile applications, like GPS trackers on moving vehicles, ADR can become inefficient due to rapidly changing conditions. In such cases, fixing the DR manually is recommended. With Dragino nodes, this also forces transmit power to its maximum.
Even when the network isn't at full capacity, adding more gateways can enhance system performance. It improves downlink reliability and enables higher data rates, which reduces retries and saves power—extending battery life and reducing long-term costs.
LoRaWAN End-to-End Security
All LoRaWAN end-devices are programmed with a 64-bit Device EUI (DevEUI) and a 128-bit Application Key (AppKey). These must be registered in the Telemetry2U network server before an Over-The-Air Activation (OTAA) can occur. Once joined, the device is assigned a Device Address (DevAddr), a Network Session Key (NwkSKey), and an Application Session Key (AppSKey).
The 32-bit DevAddr is assigned by the server and reflects the region and network settings. The NwkSKey is used for message integrity validation via a Message Integrity Check (MIC), which functions similarly to a checksum and helps prevent tampering.
The AppSKey is kept private and handles end-to-end encryption and decryption of payload data between the device and the server. These keys are session-based and regenerated with each new OTAA connection.
Although LoRaWAN transmissions can be intercepted, without the session keys, messages cannot be decoded or altered. Telemetry2U also prevents replay attacks by monitoring frame counters. These counters reset upon joining and increment with each transmission. Any message received with a lower frame count is automatically rejected.
Understanding LoRaWAN Power Cycles
Estimating battery life for IoT devices can be complex due to varying power states and timing patterns. Most power considerations focus on Class A and B end-devices, as Class C units are typically externally powered. Since Telemetry2U does not support Class B, all power consumption estimates are based on Class A operation.
Sample Time
Power use during sampling varies by the sensors attached. Some sensors need a longer delay to stabilise readings. During sampling, the microcontroller and sensors are active, usually drawing between 1–20mA.
Transmit Time
This period covers data transmission to the gateway and varies based on Data Rate (DR), transmit power (TXP), and payload size. With Adaptive Data Rate (ADR) enabled, Telemetry2U dynamically adjusts DR and TXP for optimal performance. If ADR is disabled, maximum transmit power is always used. After transmission, the device enters sleep mode for one second before opening the Rx1 window.
Receive Windows (Rx1 and Rx2)
Class A devices open Rx1 and Rx2 at one and two seconds after each uplink. These are used for downlink confirmations and control commands. Power usage during these windows is approximately 20mA. Rx1's duration depends on the DR used in the uplink, while Rx2 always uses DR8. Telemetry2U typically enables confirmations to ensure data integrity. If no confirmation is received, the device retries up to 8 times, adjusting DR and TXP.
Receive Window Outcomes
1. No Confirmation Received: When confirmations are off (CFM=0) and no command is queued, the device times out after 10–100ms. Lost messages will not be resent.
2. Confirmation in Rx1: The server responds during Rx1 with a 13-byte MAC header. Response time depends on DR. If missed, the device opens Rx2.
3. Confirmation in Rx2: If Rx1 fails, Rx2 opens after 2 seconds, using DR8 for maximum airtime to improve success rate.
Sleep Mode and Sensor Considerations
When idle, Dragino devices draw under 5µA. Sensors like DS18B20 draw 1µA in sleep and their active power adds to total sampling power.
Power Timing Benchmarks for LoRaWAN Devices
Figure 7 – Measurements Without Confirmations (CFM=0)
These measurements were taken with a Dragino LSN50v2 and DS18B20 sensor. They closely match Dragino’s official documentation. Figure 7 compares Rx timing at DR0 and DR5 for an 11-byte uplink without confirmations (CFM=0). Rx1 and Rx2 total 120ms at DR0 and 85ms at DR5.
Figure 8 – Confirmations Enabled (CFM=1)
Figure 8 shows the same set-up with confirmations enabled (CFM=1). Rx1 alone receives the MAC header, taking 288ms on DR0 and under 15ms on DR5. Using higher DRs with confirmations reduces on-time and increases battery efficiency.
Benefits of Additional Gateways
Adding more gateways enhances network performance, reduces retry attempts, and extends battery life across connected end-devices.