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. See the LoRa Alliance website for the latest 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. LoRaWAN operations such as Multicast Messaging and FOTA updates of mDot end devices are available on the Conduit.

By default, the device is configured in Public LoRaWAN mode, where the radio is able to receive packets intended for a large wide area network with a central network server. But it can be configured to operate in Private LoRaWAN mode to filter public network packets at the radio.

Private MTS mode is the legacy default mode for Multitech end-devices before v3.1, the join delay was shortened to 1 second, to be used with a local join server, and the US/AU downlink frequencies are set according to Frequency Sub Band (uplink / 8) rather than according to LoRaWAN (uplink % 8). This mode is provided for backwards compatibility with existing end-device firmware. It is designed for an 8 channel LoRaWAN network. If support for more than 8 channels or a cloud join server is required or may be in the future Public or Private LoRaWAN modes should be used.

The differences between Private LoRaWAN, Public LoRaWAN and Private MTS are:

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 uplink 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).

Channel Plans

The following table describes the channel 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.

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 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.

The end-device should follow the LoRaWAN protocol behavior and reduce datarate if the network responses are not received when to the Link ACK Request bit is set. Specific end-device behavior will depend on the LoRaWAN protocol version implemented and if uplink confirmation is enabled. The protocol prior to release 1.0.4 instructs the device sending confirmed uplink to reduce datarate after two uplinks are sent without receiving and ACK from the network, otherwise the device should follow the LinkAdrLimit and LinkAdrDelay settings.

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 DOTs 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 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.