Introduction to LoRa

LoRa, coined from “long range”, is a proprietary spread-spectrum modulation developed by Semtech for low data rate, low power, and long range wireless communication. It’s an alternative to other modulations such as FSK and PSK and is tailored for the unique requirements needed by the Internet-of-Things.

LoRaWAN is the wide area network protocol specification for use with LoRa modulation. LoRaWAN is designed for secure bidirectional communication, mobility, and localization services. The LoRaWAN specification is published by the LoRa Alliance. Email LoRa Alliance Administration to request the LoRaWAN Specification and LoRaWAN Regional Parameters.

See also mbed Intro to LoRa

Network Architecture

Public LoRaWAN networks are typically a star-of-stars topology where gateways relay messages between end-devices and a central network server. In this configuration, end-devices communicate via single-hop wireless communication to one or more gateways which in turn are connected to the central network server via standard IP connections. The MultiConnect Conduit Access Point is a gateway for public networks.

In MultiTech’s private LoRaWAN network, the MultiConnect Conduit (with LoRa mCard) functions as both the gateway and the central network server. The Conduit is highly configurable and can publish data to the cloud via an on-board cellular radio or Ethernet connection. Additionally, the Conduit can be configured as a gateway forwarding packets to a remote central network server.

By default, the Conduit is configured in private mode, but it can be configured to operate in public compatibility mode. The differences between public and private are:




Sync word



Join response time

1 & 2 seconds

5 & 6 seconds

US/AU Rx Frequencies

Rx1 and Rx2:
Uplink Channel / 8

Uplink Channel % 8
Rx2: 923.3

EU Rx Frequencies

Uplink Channel
Rx2: 869.525

Uplink Channel
Rx2: 869.525

Network Communication

Communication between LoRa end-devices and a gateway is spread over numerous frequency channels and data rates, so a single gateway can accommodate a large number of end-devices in challenging wireless environments.

Performance wise, you can pick one metric for optimization from among long range, high throughput, and rapid transmitting. Optimizing for one will sacrifice the other two.

Depending on the region of operation, the transmit data rate is configurable from 0.25 kbps to 11 kbps, and affects both range and maximum payload size. Longest range is reached by using the lowest data rate and payload size. Conversely, achieving the highest data rate and payload size results in the shortest range.

Data rate is directly related to spreading factor. Spreading factor determines the amount of redundant data spread across the transmission. A high spreading factor means a large amount of redundant data is transmitted and results in longer range but a lower data rate.

The LoRaWAN specification details an adaptive data rate (ADR) scheme that maximizes end-device battery life and network capacity by dynamically adjusting the data rate for each end-device based on current network conditions.

To confirm packet reception, acknowledgements can be requested from the receiving device, but reduces effective throughput.

End-Device Classes

NOTE: mDot and xDot endpoints version 2.0.14 and later support Class A and C. MultiTech Conduit network server code version 1.0.8 and later support Class A and C. Earlier endpoint and Conduit versions support Class A only. MultiTech will be adding support for Class B in the future.

Class A: Receive Slot After Transmission

Class A end-devices are ideal for minimal power applications where the majority of data is transmitted to the network server with only occasional downlinks. Each uplink transmission is followed by two short downlink receive windows in which only one packet can be received. The second receive window is only opened when a packet is not received within the first window. Downlink communications from the server must wait for the next received uplink.

Class B: Scheduled Receive Slots

Class B end-devices operate according to Class A and additionally open extra receive windows at scheduled times.

Class C: Continuously Listening

Class C end-devices have an always-open receive window except when transmitting.

Differences Between North America & Europe

In essence, longer range is possible in Europe because of a higher permissible spreading factor. However, data throughput is generally higher in North America because of Europe’s duty cycle restriction, but keep in mind that using the highest spreading factor for North America (10) limits payload size to 11 bytes. Whereas in Europe the payload can be 51 bytes at the highest spreading factor (12).


North America


ISM Band

902-928 MHz

863-870 MHz

Regulated by



TX Restriction

400ms tx time

Generally 1% tx duty-cycle

Payload sizes

11 – 242 bytes

51 – 242 bytes

Spreading factors

7 – 10

7 – 12

Data rates

1 – 12.5 kbps

0.3 – 5.5 kbps

Max transmit power

21 dBm

Generally 14 dBm

Spreading Factor & Bandwidth

Data rate

Maximum Payload Size

North America


SF_8 500kHz

12.5 kbps

242 bytes


SF_7 125kHz

5.47 kbps

242 bytes

242 bytes

SF_8 125kHz

3.125 kbps

129 bytes

242 bytes

SF_9 125kHz

1.76 kbps

53 bytes

115 bytes

SF_10 125kHz

0.98 kbps

11 bytes

51 bytes

SF_11 125kHz

0.44 kbps


51 bytes

SF_12 125kHz

0.25 kbps


51 bytes

NOTE: the effective throughput data rate in Europe is generally the transmit data rate divided by 10 after accounting for the duty cycle limitations. Therefore, throughput with SF_12 will be around 25 bps.

Channel Plans

The following table describes the channels plans supported by MultiTech’s DOT library and LoRa Network Server. The minimum firmware/software versions supporting the various channel plans are listed. AT command firmware binaries can be downloaded for mDot or for xDot. The Conduit’s LoRa Network Server can be updated as needed as well.

Channel Plan

Minimum mDot/xDot Library

Minimum LoRa Network Server

US915 (North America)



EU868 (Europe)



AU915 (Australia, LoRaWAN 1.0.1)



AU915 (Australia, LoRaWAN 1.0.2)

[Not Supported Yet]


AS923 (Asia/Pacific)



AS923 (Japan)

[Not Supported Yet]

1.0.26 (without LBT)

KR920 (Korea)

[Not Supported Yet]

1.0.26 (without LBT)

IN865 (India)

[Not Supported Yet]


Adaptive Datarate (ADR)

LoRaWAN provides MAC Commands to support Adaptive Datarate (ADR)

The ADR MAC Commands LinkADRReq and LinkADRAns allow the network server to change a devices Datarate, Tx Power and Repetition settings.

The network server samples the SNR from each packet and computes a possible datarate based on each sample. Six packets must be received by the network server before it will adjust the datarate of a device. Samples for the last 11 packets are maintained and when and LinkADRAns is sent the max datarate that has met a threshold of packets will be sent for the device to change to.

Tx power should be set to maximum for ADR to judge the SNR correctly. Greater power savings are achieved through Highest Power / Highest Datarate than with Lowest Power / Lowest Datarate. Each step in SF/BW will give about 3 dB increase in link budget.

Network Authentication & Security

To participate in a LoRaWAN network, an end-device must be authenticated via an over-the-air join or via offline configuration.

MultiTech mDots are assigned a globally unique 8 byte DevEUI in the factory. In addition to the DevEUI, a network specific 8 byte id (AppEUI) and 16 byte key (AppKey) are required for authentication.

The AppEUI and AppKey are both user defined and must be set in the network server and in each end-device. The AppEUI is transmitted over the air and is used to distinguish between networks. It is comparable to a Wi-Fi SSID. However, the AppKey is never transmitted over the air and is used to independently generate AES-128 encryption keys on the network server and on the end-device. These encryption keys are also never transmitted over the air.

Each end-device has a different set of encryption keys. This ensures the rest of the network remains secure if one set of keys are compromised. After joined, all packets transmitted between the end-device and server are encrypted with these keys.

MultiTech provides a simple interface for setting the AppEUI and AppKey. Instead of creating an 8 and 16 byte hexadecimal keys, you can set strings for the network ID (AppEUI) and the network key (AppKey), and we’ll generate the hexadecimal keys for you.