LoRa vs LoRaWAN

LoRa & LoRaWAN are sometimes used interchangably, but they are very different. LoRa is a modulation technique, whereas LoRaWAN is a protocol that uses LoRa as the physical layer when communicating over air between gateways and end devices.

LoRa is sometimes thought of as a protocol and compared to NB-IOT. This is absolutely not correct – the equivalent for LTE and NB-IOT is know as OFDM/SC-FDMA modulation.

LoRa operates at the Physical (or PHY) layer of the OSI stack – it simply transmits bits over the air. It knows nothing about the contents or format of the data, encryption, or anything else.

LoRaWAN is a MAC layer protocol and is part of a group of technologies known as LPWAN – Low Power Wide Area Network technologies.

The diagram below shows how LoRa & LoRaWAN work together:

LoRa

LoRa is a proprietary spread-spectrum modulation technique derived from Chirp Spread Spectrum (CSS) technology. The technology is owned an implemented by Semtech, and all LoRa devices contain Semtech technology.

The term LoRa is derived from Long Range, which is it’s key advantage. The world record for a successfully stands at an incredible 832km! To put this in to text context, LTE cell towers have a range of around 16 kilometres.

However, before we get too excited, it’s worth noting that in the real world – in a built up urban environment, you are probably more likely to get a range of a few kilometres from LoRa. However, this is at very low power and very low cost when compared to traditional LTE.

Spread Spectrum

The key to LoRa’s low cost long range transmission capability is the Chirp spread spectrum modulation technique. The data signal is multiplied with a spreading code which transmits different parts of the data signal at different frequencies. The resulting waveform looks like this:

This operation means that LoRa requires far less energy to transmit data – or with the same energy as a narrow band signal, data can be transmitted much further.

In any wireless communications system, the difference between power of the transmitter and the sensitivity of the receiver is known as the link budget. On the way from the transmitter to the receiver, the link budget is used up – in free space, it’s used slowly, in an urban area it would be used much more quickly. A higher link budget therefore means that longer range, and LoRa has a very high link budget due to it requiring a very low receiver sensitivity.

LoRa is so efficient that data can still be transmitted when the the signal is below the noise level (negative SNR). The diagram compares a narrowband spectral waveform with a spread spectrum waveform. If the narrow band waveform shown was below the noise level, it would simply be lost in the noise. With spread spectrum, this doesn’t happen.

Spreading Factor

As noted above “the data signal is multiplied with a spreading code which transmits different parts of the data signal at different frequencies”. This code is known as the spreading factor, and different spreading factors can be used to transmit.

In summary:

• Higher Spreading Factor => Longer range, lower data rate
• Lower Spreading Factor => Shorter range, higher data rate.

Spread spectrum isn’t new – it’s been used in communications applications for many years – especially in long range military and space applications. What is special about LoRa is that the inventors were the first to use it for low cost, long range transmission for consumer products. Their original aim was to create a communication technology that could read electricity meters without visiting each house – the original smart meters.

So a higher spreading factor means longer range, and a lower spreading factor means a higher data rate. And importantly, a higher data rate means less time transmitting and thus extended battery life. So ideally, the system need to operate at the highest possible data rate given the environment (especially the distance between the gateway and device). The solution is Adaptive Data Rate – this is LoRaWAN function, and is described below.

LoRaWAN

Overview

LoRaWAN is an open standard protocol which sits above the physical layer modulation scheme LoRa.

It is known as a Layer 2 MAC (Data link) layer protocol, but it also covers Layer 3 Network layer functions (i.e. it provides similar functions to IP).

The LoRaWAN network architecture is as below. It consists of the Home Network Server (hNS), the Join Server (JS) and the Application Server (AS).

The LoRaWAN protocol transits data between the LoRaWAN end device and the LoRaWAN Network/Join Servers (via the LoRaWAN gateway and any backhaul network).

It provides the following functions:

• Assigns each device to a frequency, spreading code, data rate
• Eliminates duplicate receptions
• Schedules acknowledgments
• Adapts data rates
• Security

The LoRaWAN specification documents are developed and maintained by the LoRa Alliance.

Use cases & 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 – less than 20€ CAPEX per node, almost no OPEX
• Low bandwidth – between 250bit/s and 11kbit/s in Europe using LoRa modulation (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 GPRS/3G/LTE
• Controlling lights in your house – check out ZigBee or BlueTooth
• Sending photos, watching Netflix – check out WiFi

Also note that when a gateway is transmitting (downlink to the end device), it cannot receive any data on any channel from any device. Therefore downlink tranmissions should be used with care.

LoRaWAN Message types and Frame formats

The LoRaWAN frame format is shown below. Note the LoRa modulation scheme frame structure at the Physical layer. This is defined in the LoRaWAN standard, but the LoRaWAN protocol begins at the MAC layer.

Frequency Plans & Regional parameters

LoRa operates in unlicensed spectrum, and different regions of the world allocate different frequencies as unlicensed ISM bands.

Some of the bands used in the EU (868MHz), US (915MHz) and Asia Pacific (430MHz).

For a full list of all bands in all regions, click here.

Class A, B & C communications

The LoRaWAN specification defines three modes – or classes of communication.

All LoRaWAN devices must implement Class A, whereas Class B and Class C are optional.

Class A

Class A devices support bi-directional communication between a device and a gateway. Uplink messages (from the device to the server) can be sent at any time (randomly). The device then opens two receive windows at specified times (1s and 2s) after an uplink transmission – Downlink messages from the network server (via the gateway) must be scheduled and sent within one of these windows.

If the server does not respond in either of these receive windows (situation 1 in the figure), the next opportunity will be after the next uplink transmission from the device.

The server can respond either in the first receive window, or in the second receive window, but should not use both windows.

Class B (Beacon)

Class B devices extend Class A by adding scheduled receive windows for downlink messages from the server. Using time-synchronized beacons transmitted by the gateway, the devices periodically open receive windows.

Class C (Continuous)

Class C devices extend Class A by keeping the receive windows open unless they are transmitting, as shown in the figure below. This allows for low-latency communication but is many times more energy consuming than Class A devices.

Reference: https://www.thethingsnetwork.org/docs/lorawan/classes.html

Addressing

The following fields are defined by LoRaWAN. For further information, click here.

AppEUI (or Join EUI)

A unique 64-bit identifier for an application.

DevEUI

A unique 64-bit identifier for an end device. This is generally provided by your Semtech LoRa module (i.e. the device is pre-programmed with it).

Gateway EUI (Gateway ID)

A unique identifier for your gateway. This is similar to the DevEUI, but for a gateway rather than and end device.

DevAddr

A 32-bit non-unique identifier for an end device that is used during communication between device and the network server. This is assigned dynamically when using OTAA, but is hard-coded in the device when using ABP.

AppKey (or App Root Key)

A value that is used for secure communication between device and the Network Server. The AppKey is a ‘shared secret’. It is known by the application, the end device and the Join Server. As with a password, it should not be shared. Each device has a different Application Key.

Device Addresses – DevAddr & DevEUI

Note that the 32-bit DevAddr (rather than the 64-bit DevEUI is used for data messages. This is to save over air transmission time. The same DevAddr may be used for many nodes. The DevAddr is converted to and from the DevEUI at the network server.

Activation

Over-the-Air Activation (OTAA)

Over-the-Air Activation (OTAA) is the preferred and most secure way to connect with the Network Server. Devices perform a join-procedure with the network, during which a dynamic DevAddr is assigned and security keys are negotiated with the device.

Activation by Personalization (ABP)

In some cases you might need to hardcode the DevAddr as well as the security keys in the device. This means activating a device by personalization (ABP). This strategy might seem simpler, because you skip the join procedure, but it has some downsides related to security.

Data Rate

LoRaWAN defines Data Rates which map directly to LoRa spreading factors. Data Rate 0 is the lowest data rate.

The mapping between spreading factors and data rates differs depending on the region – for the EU, the mapping is as below.

For more details and a summary of other regional data rates, click here, or refer to the LoRaWAN specification referenced above.

Adaptive Data Rate (ADR)

Every use case for every end node needs to be optimised depending on it’s location (relative to the gateway) and environment so that the data rate is maximised without reducing the range to the point where the transmissions fail. Also, if a new gateway is added which is closer, or the current gateway fails and the backup gateway is further away, then then spreading factor needs to change so that the optimum signal is still used.

The answer is Adaptive Data Rate. LoRaWAN uses an algorithm based on signal to noise ratio, link quality and transmission success to determine the lowest possible spreading factor (and thus the highest possible data rate). If these factors change, LoRaWAN will recalculate the spreading factor to ensure that it’s always optimised for the current environment.

The use of ADR means that more gateways leads to higher data rates and longer device battery life:

For moving devices we can use Blind ADR (or Application Driven ADR). Blind ADR refers to the method where the application defines several data rates, used over time. For example, a bike tracking application that sends 1 uplink using SF7 every 30 minutes, 1uplink at SF10 every 6 hours and 1 uplink at SF12 every day.

Duty Cycle & Dwell time

To avoid network congestion, certain limitations are put on how often LoRaWAN devices can transmit. The limitations depend on the region.

In the EU, the duty cycle of a device is limited (to <1% for the most common EU868MHz band). The duty cycle is the percentage of time that a device can be transmitting on one channel. Note that devices ‘frequency hop’ to transmit more often on multiple channels.

https://www.thethingsnetwork.org/docs/lorawan/duty-cycle.html

Other regions have different limitations which achieve a similar result.

For US915, no legal maximum duty cycles between transmissions are defined, but a 400 ms dwell time applies that limits the length of each transmission itself.

Security

There are two layers of cryptography in LoRaWAN – network layer and application layer.

The network layer security ensures Authenticity and Integrity, while the application layer encryption provides user data confidentiality. For an overview of these terms and general IoT security concepts, see our overview.

Both layers use AES 128 open standard, and both use the Application Root key (AppKey) to generate the session keys NwkSKey and AppSKey.

For more information, see the link below:

LoRaWAN® Is Secure (but Implementation Matters)

The description above covers LoRaWAN 1.0.x specifications. LoRaWAN 1.1 significantly enhances security. Click the image below for an excellent video on the changes introduced in version 1.1 of the specification.

Message Types

LoRaWAN defines the following message types:

For further information, refer to the LoRaWAN specification (section 4.2).