LoRaWAN Wireless Sensor Network Protocol

LoRaWAN operates in unlicensed radio spectrum. This means that anyone can use the radio frequencies without having to pay million dollar fees for transmission rights. It is similar to WiFi, which uses the 2.4GHz and 5GHz ISM bands worldwide. Anyone is allowed to set up WiFi routers and transmit WiFi signals without the need for a license or permit. Similarly it's the case for LoRaWAN.

LoRaWAN uses lower radio frequencies with a longer range. The fact that frequencies have a longer range also comes with more restrictions that are often country-specific. This poses a challenge for LoRaWAN, that tries to be as uniform as possible in all different regions of the world. As a result, LoRaWAN is specified for a number of bands for these regions. These bands are similar enough to support a region-agnostic protocol, but have a number of consequences for the implementation of the backend systems.

• LoRaWAN has official regional specifications, called Regional Parameters, that you can download from the LoRa Alliance website.

• These LoRaWAN regional specifications do not specify everything either. They only cover a region by specifying the common denominator. For example, the LoRaWAN regional parameters for Asia only specify a common subset of channels - but there are variations between regulations in Asian countries. Furthermore, each network server operator is free to select additional parameters, such as additional emission channels. 

• In some countries, more than one frequency plan may be used. For example, in the Australia, both AU915 (main option) and AS923 can be used.

• The regional parameters include physical layer parameters such as frequency plans (channel plans), mandatory channel frequencies and data rates for join-request messages. The Regional Parameters also include LoRaWAN layer parameters such as maximum payload size.

• AU915-928: Applies to Australia and all other countries whose band extends from 915 to 928MHz. There is no duty cycle limitation applicable and the dwell time limitation is 400ms. The default maximum EIRP allowed is +30 dBm.
• AS923: Applied for multiple regions (some countries in Asia and Oceania). All end-devices operated in Japan must perform Listen Before Talk (LBT) based on ARIB STD-T108 regulations.

AU915-928 (SB2) Frequency Details 

Uplink:

1. 916.8 - SF7BW125 to SF12BW125
2. 917.0 - SF7BW125 to SF12BW125
3. 917.2 - SF7BW125 to SF12BW125
4. 917.4 - SF7BW125 to SF12BW125
5. 917.6 - SF7BW125 to SF12BW125
6. 917.8 - SF7BW125 to SF12BW125
7. 918.0 - SF7BW125 to SF12BW125
8. 918.2 - SF7BW125 to SF12BW125
9. 917.5 - SF8BW500

Downlink:

1. 923.3 - SF7BW500 to SF12BW500 (RX1)
2. 923.9 - SF7BW500 to SF12BW500 (RX1)
3. 924.5 - SF7BW500 to SF12BW500 (RX1)
4. 925.1 - SF7BW500 to SF12BW500 (RX1)
5. 925.7 - SF7BW500 to SF12BW500 (RX1)
6. 926.3 - SF7BW500 to SF12BW500 (RX1)
7. 926.9 - SF7BW500 to SF12BW500 (RX1)
8. 927.5 - SF7BW500 to SF12BW500 (RX1)
9. 923.3 - SF12BW500 (RX2)

Default Settings for All Regions 

There are a few recommended default settings available that can be applied to all the regions.

• RX1 Delay: 1s
• RX2 Delay: 2s (RX1 Delay + 1s)
• Join Accept 1 Delay: 5s
• Join Accept 2 Delay: 6s

LoRaWAN 1.0 specifies a number of security keys: NwkSKey, AppSKey and AppKey. All keys have a length of 128 bits. The algorithm used for this is AES-128, similar to the algorithm used in the 802.15.4 standard.

Session Keys 

When a device joins the network (this is called a join or activation), an application session key AppSKey and a network session key NwkSKey are generated. The NwkSKey is shared with the network, while the AppSKey is kept private. These session keys will be used for the duration of the session.

The Network Session Key (NwkSKey) is used for interaction between the Node and the Network Server. This key is used to validate the integrity of each message by its Message Integrity Code (MIC check). This MIC is similar to a checksum, except that it prevents intentional tampering with a message. For this, LoRaWAN uses AES-CMAC. In the backend of The Things Network this validation is also used to map a non-unique device address (DevAddr) to a unique DevEUI and AppEUI.

The Application Session Key (AppSKey) is used for encryption and decryption of the payload. The payload is fully encrypted between the Node and the Handler/Application Server component of The Things Network (which you will be able to run on your own server). This means that nobody except you is able to read the contents of messages you send or receive.

These two session keys (NwkSKey and AppSKey) are unique per device, per session. If you dynamically activate your device (OTAA), these keys are re-generated on every activation. If you statically activate your device (ABP), these keys stay the same until you change them.

Application Key 

The application key (AppKey) is only known by the device and by the application. Dynamically activated devices (OTAA) use the Application Key (AppKey) to derive the two session keys during the activation procedure. In The Things Network you can have a default AppKey which will be used to activate all devices, or customize the AppKey per device.

Device Classes

Every end device must be registered with a network before sending and receiving messages. This procedure is known as activation. There are two activation methods available:

• Over-The-Air-Activation (OTAA) - the most secure and recommended activation method for end devices. Devices perform a join procedure with the network, during which a dynamic device address is assigned and security keys are negotiated with the device.
• Activation By Personalization (ABP) - requires hardcoding the device address as well as the security keys in the device. ABP is less secure than OTAA and also has the downside that devices can not switch network providers without manually changing keys in the device.

Over-The-Air-Activation in LoRaWAN 1.1 

In LoRaWAN 1.0.x, the join procedure requires two MAC messages to be exchanged between the end device and the Join Server:

• Join-request - from end device to the Join Server
• Join-accept - from Join Server to the end device

Before activation, the JoinEUI, DevEUI, AppKey, and NwkKey should be stored in the end device. The AppKey and NwkKey are AES-128 bit secret keys known as root keys. The matching AppKey, NwkKey, and DevEUI should be provisioned onto the Join Server that will assist in the processing of the join procedure and session key derivation. The JoinEUI and DevEUI are not secret and visible to everyone.

The following steps describe the Over-The-Air-Activation (OTAA) procedure.

Figure: OTAA message flow in LoRaWAN 1.1

Step 1 

The join procedure is always initiated by the end device. The end device sends the Join-request message to the network that is going to be joined. The Join-request message consists of the following fields.

• JoinEUI – a 64-bit global application identifier in IEEE EUI64 address space that uniquely identifies the Join Server that can assist in the processing of the Join-request and derivation of the session keys.
• DevEUI – a 64-bit global device identifier in IEEE EUI64 address space that uniquely identifies the end-device.
• DevNonce – a 2-byte counter, starting at 0 when the device is initially powered up and incremented with every Join-request. The DevNonce value is used to prevent replay attacks.

The MIC is calculated over all the fields in the Join-request message using the NwkKey. The calculated MIC is then added to the Join-request message.

The Join-request message can be transmitted using any data rate and using one of the region-specific join channels. For example, in Europe an end device can transmit the Join-request message by randomly choosing among 868.10 MHz, 868.30 MHz, or 868.50 MHz. The Join-request message travels through one or more gateways to the Network Server.

Step 2 

The Network Server forwards the Join-request message to the corresponding Join Server.

Step 3 

The Join Server processes the Join-request message. The Join Server will generate all the session keys (AppSKey, FNwkSIntKey, SNwkSIntKey, and NwkSEncKey) if the end-device is permitted to join the network.

Step 4 

If the above step gets success, the Network Server generates the Join-accept message. The Join-accept message consists of the following fields.

• JoinNonce – a device specific counter value provided by the Join Server and used by the end device to derive the session keys, FNwkSIntKey, SNwkSIntKey, NwkSEncKey, and AppSKey.
• NetID – a 24-bit unique network identifier.
• DevAddr – a 32-bit device address assigned by the Network Server to identify the end device within the current network.
• DLSettings – a 1-byte field consisting of downlink settings which the end device should use.
• RxDelay – contains delay between TX and RX
• CFList – an optional list of channel frequencies for the network the end-device is joining. These frequencies are region-specific.

The Message Integrity Code (MIC) is calculated over all the fields in the Join-accept message using NwkKey (for LoRaWAN 1.0 devices) or JSIntKey (for LoRaWAN 1.1 devices) . The calculated MIC is then added to the Join-accept message.

The Join-accept message itself is then encrypted with the NwkKey. The Network Server uses an AES decrypt operation in ECB mode to encrypt the join-accept message.

The Join-accept message is encrypted with the NwkKey (if triggered by Join-request) or JSEncKey (if triggered by Rejoin-request).

Then the Network Server sends the encrypted Join-accept message back to the end device as a normal downlink.

Step 5 

The Join Server sends the AppSKey to the Application Server and the three network session keys (FNwkSIntKey, SNwkSIntKey, and NwkSEncKey) to the Network Server.

Step 6 

The end-device decrypts the Join-accept message using AES encrypt operation. The end device uses AppKey, NwkKey, and JoinNonce to generate session keys.

For LoRaWAN 1.0.x devices,

• AppSKey is derived from the NwkKey.
• FNwkSIntKey, SNwkSIntKey, and NwkSEncKey are derived from the NwkKey.

For LoRaWAN 1.1 devices,

• AppSKey is derived from AppKey.
• FNwkSIntKey, SNwkSIntKey, and NwkSEncKey are derived from the NwkKey.

The end device is now activated on the Network.

After activation, the following additional information is stored in the end device.

• DevAddr - a 32-bit device address assigned by the Network Server to identify the end device within the current network.
• FNwkSIntKey - a network session key that is used by the end device to calculate the MIC (partially) of all uplink data messages for ensuring message integrity.
• SNwkSIntKey - a network session key that is used by the end device to calculate the MIC (partially) of all uplink data messagse and calculate the MIC of all downlink data messages for ensuring message integrity.
• NwkSEncKey - a network session key that is used to encrypt and decrypt the payloads with MAC commands of the uplink and downlink data messages for ensuring message confidentiality.
• AppSKey - a session key used by both the Application Server and the end device to encrypt and decrypt the application data in the data messages for ensuring message confidentiality.

Activation By Personalization 

Activation By Personalization (ABP) directly ties an end-device to a pre-selected network, bypassing the over-the-air-activation procedure. Activation by Personalization is the less secure activation method, and also has the downside that devices can not switch network providers without manually changing keys in the device. A Join Server is not involved in the ABP process.

An end device activated using the ABP method can only work with a single network and keeps the same security session for its entire lifetime.

Adaptive Data Rate

Adaptive Data Rate (ADR) is a mechanism for optimizing data rates, airtime and energy consumption in the network.

The ADR mechanism controls the following transmission parameters of an end device.

• Spreading factor
• Bandwidth
• Transmission power

ADR can optimize device power consumption while ensuring that messages are still received at gateways. When ADR is in use, the network server will indicate to the end device that it should reduce transmission power or increase data rate. End devices which are close to gateways should use a lower spreading factor and higher data rate, while devices further away should use a high spreading factor because they need a higher link budget.

ADR should be enabled whenever an end device has sufficiently stable RF conditions. This means that it can generally be enabled for static devices. If the static end device can determine that RF conditions are unstable (for example, when a car is parked on top of a parking sensor), ADR should (temporarily) be disabled.

Mobile end devices should be able to detect when they are stationary for a longer times, and enable ADR during those times. End devices decide if ADR should be used or not, not the application or the network.

LoRaWAN Limitations

LoRaWAN is not suitable for every use-case, so it is important that you understand the limitations. Here’s a quick overview:

Suitable use-cases for LoRaWAN: 

• Long range - multiple kilometers
• Low power - can last years on a battery
• Low cost - low cost per node, almost no OPEX
• Low bandwidth - (depending on the spreading factor)
• Coverage everywhere - you are the network! Just install your own gateways
• Secure - 128bit end-to-end encrypted

Not Suitable for LoRaWAN: 

• Realtime data - you can only send small packets every couple of minutes
• Phone calls - you can do that with 3G/4G/5G/LTE
• Controlling lights in your house - check out ZigBee or BlueTooth
• Sending photos, watching Netflix - check out WiFi

dB, dBm, dBi and dBd

In this section we briefly discuss some units that are used to measure the performance of transceivers (gateways and end devices) and antennas.

dB (decibel) 

The decibel can be used to express the ratio of two physical quantities such as power, sound intensity, sound pressure, voltage, and current on a logarithmic scale. In LoRaWAN we use decibel to express the ratio between two power levels usually given in watt (W) or milliwatt (mW).

The power ratio, N can be expressed in decibel using the formula,

N = 10 log₁₀ (P_out/P_in) dB

where P_out is the output power and P_in is the input power.

Note:

When we are dealing with the power levels we use 10log units.

For example, if an amplifier turns a 1 W signal into a 1000 W signal, its power ratio can be expressed as:

N = 10 log₁₀ (P_out/P_in) = 10 log₁₀ (1000/1) = 30 dB

Decibel doesn’t provide an absolute value. By looking at the decibel value you can’t say the input and output power of a device or cable etc, but you can say whether it offers a gain or a loss.

A power ratio greater than 0 dB is treated as a gain. For example, if an amplifier turns a 2 W signal into a 10 W signal, the power ratio is:

N = 10 log₁₀ (P_out/P_in) = 10 log₁₀ (10/2) = 10 log₁₀ (5) = 6.9 dB (gain)

A power ratio less than 0 dB is treated as a loss (negative gain or attenuation). For example, if 10 W of power is fed into a cable but only 8 W is measured at the output, the power ratio is:

N = 10 log₁₀ (P_out/P_in) = 10 log₁₀ (8/10) = 10 log₁₀(0.8) = -0.9 dB (loss)

The power ratio of 0 dB means there is no gain or loss.

dBm (decibel per milliwatt) 

If you use the reference input power (P_in) of 1 mW the power ratio, N can be expressed in dBm:

N = 10 log₁₀(P_out / 1) dBm

By using the above formula, P_out can be expressed in mW which is an absolute value.

Antenna gains 

The units dBi and dBd are used to express antenna gains.

dBi (decibel relative to isotropic) 

The gain of an antenna can be measured relative to an isotropic antenna and is expressed in dBi. An isotropic antenna is a hypothetical antenna that radiates power uniformly in all directions. The gain of an isotropic antenna is 0 dB which means it has no gain or loss.

dBd (decibel relative to dipole) 

The gain of an antenna can be measured relative to a reference dipole antenna and is expressed in dBd. A reference dipole antenna offers a fixed 2.15 dB of gain over an isotropic antenna.

The following equation represents the relationship between dBi and dBd:

dBi = dBd + 2.15 dB

Questions: 

1. Convert 5 dBi to dBd.

X_dBd = X_dBi - 2.15 = 5 - 2.15 = 2.85 dBd

2. Convert 2 dBd to dBi.

X_dBi = X_dBd + 2.15 = 2 + 2.15 = 4.15 dBi

RSSI and SNR

In wireless communication, a receiver needs a good signal strength and a signal-to-noise ratio to separate the original signal from the modulated carrier. This section contains information about two most commonly used signal strength indicators - RSSI and SNR.

RSSI 

RSSI (Received Signal Strength Indicator) is a relative measurement that helps you determine if the received signal is strong enough to get a good wireless connection from the transmitter. Since LoRaWAN supports bi-directional communication, RSSI is an important measurement for both gateways and end devices. RSSI is measured in dBm and its value is a negative form. The closer the RSSI value is to zero, the received signal is stronger.

Apart from the output power of the transmitter, the following factors mainly influence the RSSI:

• Path loss
• Antenna gain
• Cable/connector loss

SNR 

SNR (Signal-to-Noise Ratio), often written as S/N, is the ratio of the received signal power to the noise floor. SNR is commonly used to determine the quality of the received signal.

SNR can be calculated using the following formula and is often expressed in decibels (dB):

SNR (dB) = P_{received_signal} (dBm) - P_noise (dBm)

If the RSSI is above the noise floor the receiver can easily demodulate the signal.

Here is a good example of a positive SNR:

Image captured from the YouTube video by Richard Wenner. The x-axis represents the power level in dBm and the y-axis represents the time.

By looking at the above graph you can see that the RSSI is about -65 dBm and the noise floor is about -90 dBm. By using these values you can calculate the SNR as follows:

SNR (dB) = P_{received_signal} (dBm) - P_noise (dBm)

SNR (dB) = -65 dBm -(-90 dBm) = 25 dB

The positive SNR means that the signal power is greater than the noise power, i.e. the receiver will be able to demodulate the signal.

If the RSSI is below the noise floor, it is impossible to demodulate the signal. However, LoRa can demodulate signals that are below the noise floor. The minimum SNR required for demodulation at different spreading factors is shown in the table below:

 

Image captured from Semtech SX1276-7-8-9 Datasheet.

 

Here is a good example of a negative SNR:

Image captured from the YouTube video by Richard Wenner. The x-axis represents the power level in dBm and the y-axis represents the time.

By looking at the above graph you can see that the RSSI is about -120 dBm and the noise floor is about -90 dBm. Now calculate the SNR as follows:

SNR (dB) = P_{received_signal} (dBm) - P_noise (dBm)

SNR (dB) = -120 dBm -(-90 dBm) = -30 dB

The negative SNR means that the signal power is less than the noise power. The value of -30 dB is below the minimum SNR of -20 dBm @ SF12, so it does not guarantee that the receiver will be able to demodulate the signal.