¶ LoRaWAN
Most of the information is taking from very well knows sources in the LoRaWAN community including the TTN website. Please also check these sources if you want to know more details.
- The Things Network about LoRaWAN: https://www.thethingsnetwork.org/docs/lorawan
- The LoRaWAN Alliance about LoRaWAN: https://lora-alliance.org/about-lorawan/
¶ Index
- What are LoRa and LoRaWAN
- LoRaWAN Architecture
- Regional Parameters
- Message Types
- Security
- Classes
- End Device Activation
- Spreading Factors
- Adaptive Data Rate
- Limitations
¶ What are LoRa and LoRaWAN
In this section, you’ll learn why LoRaWAN is so awesome, hear about some great LoRaWAN use cases, and learn the difference between LoRa and LoRaWAN.
¶ LoRa
LoRa is a wireless modulation technique derived from Chirp Spread Spectrum (CSS) technology. It encodes information on radio waves using chirp pulses - similar to the way dolphins and bats communicate! LoRa modulated transmission is robust against disturbances and can be received across great distances.
Don’t be alarmed about the complex terms; LoRa modulation and Chirp Spread Spectrum technology are simple to understand in practice. In case you are curious, in this video, Richard Wenner explains how Chirp Spread Spectrum technology works:
LoRa is ideal for applications that transmit small chunks of data with low bit rates. Data can be transmitted at a longer range compared to technologies like WiFi, Bluetooth or ZigBee. These features make LoRa well suited for sensors and actuators that operate in low power mode.
LoRa can be operated on the license free sub-gigahertz bands, for example, 915 MHz, 868 MHz, and 433 MHz. It also can be operated on 2.4 GHz to achieve higher data rates compared to sub-gigahertz bands, at the cost of range. These frequencies fall into ISM bands that are reserved internationally for industrial, scientific, and medical purposes.
¶ LoRaWAN
LoRaWAN is a Media Access Control (MAC) layer protocol built on top of LoRa modulation. It is a software layer which defines how devices use the LoRa hardware, for example when they transmit, and the format of messages.
The LoRaWAN protocol is developed and maintained by the LoRa Alliance. The first LoRaWAN specification was released in January 2015. The table below shows the version history of the LoRaWAN specifications. At the time of this writing the latest specifications are 1.0.4 (in 1.0 series) and 1.1 (1.1 series).
| Version | Release date |
| 1.0 | January 2015 |
| 1.0.1 | February 2016 |
| 1.0.2 | July 2016 |
| 1.1 | October 2017 |
| 1.0.3 | July 2018 |
| 1.0.4 | October 2020 |
¶ Bandwidth vs. Range
LoRaWAN is suitable for transmitting small size payloads (like sensor data) over long distances. LoRa modulation provides a significantly greater communication range with low bandwidths than other competing wireless data transmission technologies. The following figure shows some access technologies that can be used for wireless data transmission and their expected transmission ranges vs. bandwidth.
¶ Why is LoRaWAN so awesome?
- Ultra low power - LoRaWAN end devices are optimized to operate in low power mode and can last up to 10 years on a single coin cell battery.
- Long range - LoRaWAN gateways can transmit and receive signals over a distance of over 10 kilometers in rural areas and up to 3 kilometers in dense urban areas.
- Deep indoor penetration - LoRaWAN networks can provide deep indoor coverage, and easily cover multi floor buildings.
- License free spectrum - You don’t have to pay expensive frequency spectrum license fees to deploy a LoRaWAN network.
- Geolocation- A LoRaWAN network can determine the location of end devices using triangulation without the need for GPS. A LoRa end device can be located if at least three gateways pick up its signal.
- High capacity - LoRaWAN Network Servers handle millions of messages from thousands of gateways.
- Public and private deployments - It is easy to deploy public and private LoRaWAN networks using the same hardware (gateways, end devices, antennas) and software (UDP packet forwarders, Basic Station software, LoRaWAN stacks for end devices).
- End-to-end security- LoRaWAN ensures secure communication between the end device and the application server using AES-128 encryption.
- Firmware updates over the air - You can remotely update firmware (applications and the LoRaWAN stack) for a single end device or group of end devices.
- Roaming- LoRaWAN end devices can perform seamless handovers from one network to another.
- Low cost - Minimal infrastructure, low-cost end nodes and open source software.
- Certification program- The LoRa Alliance certification program certifies end devices and provides end-users with confidence that the devices are reliable and compliant with the LoRaWAN specification.
- Ecosystem- LoRaWAN has a very large ecosystem of device makers, gateway makers, antenna makers, network service providers, and application developers.
¶ LoRaWAN use cases
Here are a few great LoRaWAN use cases provided by Semtech, to give you some insight into how LoRaWAN can be applied:
- Vaccine cold chain monitoring - LoRaWAN sensors are used to ensure vaccines are kept at appropriate temperatures in transit.
- Animal conservation - Tracking sensors manage endangered species such as Black Rhinos and Amur Leopards.
- Dementia patients - Wristband sensors provide fall detection and medication tracking.
- Smart farms- Real time insights into crop soil moisture and optimized irrigation schedule reduce water use up to 30%.
- Water conservation- Identification and faster repair of leaks in a city’s water network.
- Food safety- Temperature monitoring ensures food quality maintenance.
- Smart waste bins - Waste bin level alerts sent to staff optimize the pickup schedule.
- Smart bikes- Bike trackers track bikes in remote areas and dense buildings.
- Airport tracking - GPS-free tracking monitors vehicles, personnel, and luggage.
- Efficient workspaces - Room occupancy, temperature, energy usage and parking availability monitoring.
- Cattle health - Sensors monitor cattle health, detect diseases and forecast calves delivery time.
- LoRa in space - Satellites to provide LoRaWAN-based coverage worldwide.
¶ LoRa Alliance
The LoRa Alliance® is an open, non-profit association established in 2015. It supports development of the LoRaWAN protocol and ensures interoperability of all LoRaWAN products and technologies. Today, the LoRa Alliance has over 500 members around the globe.
The LoRa Alliance provides LoRaWAN certification for end devices. Certified end devices provide users with confidence that the end device is reliable and compliant with the LoRaWAN specification. You can learn more about LoRaWAN certification by visiting the LoRa Alliance website. Certification is only available for device manufacturers that are members of the LoRa Alliance. Once certified, the manufacturer can use the LoRaWAN Certified mark with the product.
¶ LoRaWAN is now an ITU standard.
As announced by the LoRa Alliance® on December 7, 2021, LoRaWAN® is officially approved as a standard for Low Power Wide Area Networking (LPWAN) by the International Telecommunication Union (ITU).
Read the Lora Alliance® Press Release, LoRaWAN® Formally Recognized as ITU International Standard for Low Power Wide Area Networking for more information.
¶ LoRaWAN Architecture
LoRaWAN networks are deployed in a star-of-stars topology.
A typical LoRaWAN network consists of the following elements.
- End Devices - sensors or actuators send LoRa modulated wireless messages to the gateways or receive messages wirelessly back from the gateways. .
- Gateways - receive messages from end devices and forward them to the Network Server.
- Network Server - a piece of software running on a server that manages the entire network.
- Application servers - a piece of software running on a server that is responsible for securely processing application data.
- Join Server - a piece of software running on a server that processes join-request messages sent by end devices (The Join Server is not shown in the above figure).
End devices communicate with nearby gateways and each gateway is connected to the network server. LoRaWAN networks use an ALOHA based protocol, so end devices don’t need to peer with specific gateways. Messages sent from end devices travel through all gateways within range. These messages are received by the Network Server. If the Network Server has received multiple copies of the same message, it keeps a single copy of the message and discards others. This is known as message deduplication.
Let’s examine each element of the LoRaWAN network in detail.
¶ End devices
A LoRaWAN end device can be a sensor, an actuator, or both. They are often battery operated. These end devices are wirelessly connected to the LoRaWAN network through gateways using LoRa RF modulation. The following figure shows an end device that consists of sensors like temperature, humidity, and fall detection.
¶ Gateways
Each gateway is registered (using configuration settings) to a LoRaWAN network server. A gateway receives LoRa messages from end devices and simply forwards them to the LoRaWAN network server. Gateways are connected to the Network Server using a backhaul like Cellular (3G/4G/5G), WiFi, Ethernet, fiber-optic or 2.4 GHz radio links.
¶ Types of LoRaWAN Gateways
LoRaWAN gateways can be categorized into indoor (picocell) and outdoor (macrocell) gateways. Indoor gateways are cost-effective and suitable for providing coverage in places like deep-indoor locations (spaces covered by multiple walls), basements, and multi-floor buildings. These gateways have internal antennas or external ‘pigtail’ antennas. However depending on the indoor physical environment some indoor gateways can receive messages from sensors located several kilometers away.
The following figure shows a Lorank8 gateway.
Outdoor gateways provide a larger coverage than the indoor gateways. They are suitable for providing coverage in both rural and urban areas. These gateways can be mounted on cellular towers, the rooftops of very tall buildings, metal pipes (masts) etc. Usually an outdoor gateway has an external antenna (i.e. Fiberglass antenna) connected using a coaxial cable. If you are good at hacking electronic products, you can convert some indoor gateways to outdoor gateways using water/dust proof enclosures and adding external antennas.
The following figure shows a LoRaWAN outdoor gateway. It has connectors for connecting external LoRaWAN, 3G/4G, and GPS antennas. Can you figure them out?
Usually, the receiver sensitivity of an outdoor gateway is higher than the receiver sensitivity of an indoor gateway.
¶ Network Server
The Network Server manages gateways, end-devices, applications, and users in the entire LoRaWAN network.
A typical LoRaWAN Network Server has the following features.
- Establishing secure 128-bit AES connections for the transport of messages between end-devices and the Application Server (end-to-end security).
- Validating the authenticity of end devices and integrity of messages.
- Deduplicating uplink messages.
- Selecting the best gateway for routing downlink messages.
- Sending ADR commands to optimize the data rate of devices.
- Device address checking.
- Providing acknowledgements of confirmed uplink data messages.
- Forwarding uplink application payloads to the appropriate application servers
- Routing uplink application payloads to the appropriate Application Server.
- Forwarding Join-request and Join-accept messages between the devices and the join server
- Responding to all MAC layer commands.
¶ Application Server
The Application Server processes application-specific data messages received from end devices. It also generates all the application-layer downlink payloads and sends them to the connected end devices through the Network Server. A LoRaWAN network can have more than one Application Server. The collected data can be interpreted by applying techniques like machine learning and artificial intelligence to solve business problems.
¶ Join Server
The Join Server assists in secure device activation, root key storage, and session key generation. The join procedure is initiated by the end device by sending the Join-request message to the Join Server through the Network Server. The Join-server processes the Join-request message, generates session keys, and transfers NwkSKey and AppSKey to the Network server and the Application server respectively. The Join Server was first introduced with LoRaWAN v1.1. It is also availabe in LoRaWAN v1.0.4.
¶ Regional Parameters
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.
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. We call these parameters Other. For The Things Network, they are defined in this GitHub repository.
In some countries, more than one frequency plan may be used. For example, in the Netherlands, both EU868-870 and EU433 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.
In this chapter you will learn in detail about the EU863-870 band and US902-928 ISM band. This chapter also presents some important parameters involved in other frequency plans.
¶ Common Frequency Plans
LoRaWAN operates in the unlicensed ISM (Industrial, Scientific, and Medical) bands. The table below lists the latest frequency plans and their common names.
| Channel Plan | Common Name |
| EU863-870 | EU868 |
| US902-928 | US915 |
| CN779-787 | CN779 |
| EU433 | EU433 |
| AU915-928 | AU915 |
| CN470-510 | CN470 |
| AS923 | AS923 |
| KR920-923 | KR920 |
| IN865-867 | IN865 |
| RU864-870 | RU864 |
Information about specific countries and frequency plans can be found here:
The Things Fundamentals certification expects detailed knowledge about the EU863-870 and US902-928 frequency plans. However, having a basic understanding of other frequency plans is sufficient; for example, you should know that Listen Before Talk (LBT) is used in Japan.
¶ EU863-870 Band
The EU863-870 band can be applied to any region where the radio spectrum use is defined by the ETSI [EN300.220] standard. The EU863-870 band is used in all the European countries, and some countries outside Europe, for example, Bahrain (BH), located in the Middle East. The EU863-870 band implies the frequency band ranges from 863 MHz – 870 MHz but some countries use slightly different frequency ranges. For example, Albania (AL) uses 863-873 MHz.
¶ EU863-870 default channels
The following three default channels must be implemented in every end device that supports the EU863-870 band. These channels are used by the end device to broadcast the Join-request message. The end device randomly selects one of the default channels to send the Join-request message.
| Channel Frequency (MHz) | Bandwidth (kHz) | LoRa data rate | Bit rate |
| 868.10 | 125 | DR0 – DR5 | 0.3 – 5 kbps |
| 868.30 | 125 | DR0 – DR5 | 0.3 – 5 kbps |
| 868.50 | 125 | DR0 – DR5 | 0.3 – 5 kbps |
For devices compliant with LoRaWAN version 1.0.x, these three default channels shall not be modified, but for devices compliant with LoRaWAN version 1.1 and beyond, these channels may be modified through the NewChannelReq command.
The EU863-870 band supports a maximum of 16 channels. During end device activation additional channels may be specified. For example, The Things Network uses the following 5 additional frequencies for uplink.
- 867.1 MHz
- 867.3 MHz
- 867.5 MHz
- 867.7 MHz
- 867.9 MHz
For downlink, The Things Network uses one additional fixed frequency for the RX2 receive slot:
- 869.525 MHz at DR0 (SF12 / 125 kHz).
¶ EU863-870 Duty Cycle
The European Telecommunications Standards Institute (ETSI) sets the maximum duty cycle for the EU863-870 frequency at 1%, which is the maximum amount of time a device may spend communicating.
Let’s have a look at how to calculate the time-on-air allowed per day (24 hours), per end device for some common duty cycles.
| Duty cycle (take the maximum) | Equation: Time-On-Air = number of seconds per day X duty cycle | Maximum allowed Time-On-Air per day, per device |
| 0.1% | 86400 x 0.1% | 86 seconds per day |
| 1% | 86400 x 1% | 864 seconds per day |
| 10% | 86400 x 10% | 8640 seconds per day |
Some network operators (like The Things Network) reduce the duty cycle further than ESTI recommends. These types of restrictions are called ‘Fair Access Policy’. For example, The Things Network’s fair access policy limits the uplink airtime to 30 seconds per day per node and the downlink messages to 10 messages per day per node.
¶ EU863-870 Data Rates
Data rate is the number of bits that are transmitted per unit of time. With LoRa modulation, the data rate depends on a few factors like spreading factor, bandwidth, and the coding rate.
The following table shows the bit rate for each data rate (DR0 - DR6) configured with the spreading factor and the bandwidth.
| Data Rate | Configuration (SF + BW) | Bit rate (bit/s) |
| 0 | LoRa: SF12 / 125 kHz |
250 |
| 1 | LoRa: SF11 / 125 kHz |
440 |
| 2 | LoRa: SF10 / 125 kHz |
980 |
| 3 | LoRa: SF9 / 125 kHz |
1760 |
| 4 | LoRa: SF8 / 125 kHz |
3125 |
| 5 | LoRa: SF7 / 125 kHz |
5470 |
| 6 | LoRa: SF7 / 250 kHz |
11000 |
As you can see, higher spreading factors cause lower bit rates and lower spreading factors cause higher bit rates. However for the same spreading factor, if the bandwidth doubles the data rate also gets doubled. You will learn more about this in the Spreading Factors chapter.
All EU868-870 end devices must support one of the following data rate options.
- DR0 – DR5 – the minimal data rate set supported to obtain the LoRaWAN certification.
- DR0 – DR7
- DR0 – DR11 – all data rates are implemented in the end device
¶ EU863-870 Maximum EIRP / ERP
The Effective Isotropic Radiated Power (EIRP) is the total power radiated by an isotropic antenna in a single direction. The antenna gain is expressed in dBi for isotropic antennas.
The following table shows the list of EIRP values that can be used to transmit data.
| TX Power | EIRP | Calculated value |
| 0 | Max EIRP | +16 dBm |
| 1 | Max EIRP - 2 dB | +16 dBm - 2 dB = +14 dBm |
| 2 | Max EIRP - 4 dB | +16 dBm - 4 dB = +12 dBm |
| 3 | Max EIRP - 6 dB | +16 dBm - 6 dB = +10 dBm |
| 4 | Max EIRP - 8 dB | +16 dBm - 8 dB = +8 dBm |
| 5 | Max EIRP - 10 dB | +16 dBm - 10 dB = +6 dBm |
| 6 | Max EIRP - 12 dB | +16 dBm - 12 dB = +4 dBm |
| 7 | Max EIRP - 14 dB | +16 dBm - 14 dB = +2 dBm |
The Max EIRP for EU863-870 is +16dBm.
The above mentioned EIRP and ERP values can also be expressed in milliwatts (mW). For example:
- +16 dBm = 40 mW
- +14 dBm = 25 mW
- +27 dBm = 500 mW
¶ EU863-870 Maximum Payload Size
The maximum application payload size (length) varies by data rate.
The following table shows the maximum application payload (FRMPayload) size for different data rates.
| Data Rate | Configuration (SF+BW) | Maximum application payload size (bytes) |
| 0 | LoRa: SF12 / 125 kHz |
51 |
| 1 | LoRa: SF11 / 125 kHz |
51 |
| 2 | LoRa: SF10 / 125 kHz |
51 |
| 3 | LoRa: SF9 / 125 kHz |
115 |
| 4 | LoRa: SF8 / 125 kHz |
242 |
| 5 | LoRa: SF7 / 125 kHz |
242 |
| 6 | LoRa: SF7 / 250 kHz |
242 |
¶ EU863-870 Summary
The following table summarizes all the important parameters we have discussed in this section for EU863-870 band.
| Default frequency band | 863-870 MHz |
| Mandatory channel frequencies (join-request) |
868.10 868.30 868.50 |
| Mandatory data rates | 0-5 (minimum set supported for certification) |
| Optional data rates | 6-7 or 6-11 |
| Number of channels |
16 3 default + 5 optional by CFlist These 5 optional channels and the remaining 8 channels can be modified /populated by NewChannelReq command |
| Default channels | 0, 1, 2 |
| Duty cycle | < 1% |
| Dwell time limitation | No |
| Max EIRP / ERP |
+16 dBm (40 mW) / +14 dBm (25 mW) This is the power radiated by the isotropic antenna / half-wave dipole antenna (not the transmitter power) |
| Max antenna gain | 2.15 dBi or 0 dBd |
| Default RX2 data rate | DR0 (SF12 / 125 kHz) |
| Default RX2 frequency | 869.525 MHz |
¶ US902-928 ISM Band
This section describes the regional parameters for the USA, Canada, and all other countries using the 902-928 ISM band.
¶ US902-928 Frequency Plans
The US902-928 ISM band is divided into the following frequency plans as shown in the table below.
| Uplink/Downlink | Channels | range | Frequency range | BW | Data rate |
| Uplink | 64 | 0 - 63 | 902.3 – 914.9 MHz in 200 kHz increments | 125 kHz | DR0 – DR3 |
| Uplink | 8 | 64 - 71 | 903.0 – 914.2 MHz in 1.6 MHz increments | 500 kHz | DR4 |
| Downlink | 8 | 0 - 7 | 923.3 – 927.5 MHz in 600 kHz increments | 500 kHz | DR8 - DR13 |
¶ US902-928 Data Rates
The following table shows the bit rate for each data rate configured with the spreading factor and the bandwidth.
- DR0 - DR4 and DR8 - DR13 are used for LoRa modulation.
- DR4 is identical to DR12.
- DR8 - DR13 are only used for downlink messages.
| Data Rate | Configuration (SF + BW) | Bit rate (bit/s) | Uplink/Downlink? |
| 0 | LoRa: SF10 / 125 kHz |
980 |
Uplink |
| 1 | LoRa: SF9 / 125 kHz |
1760 |
Uplink |
| 2 | LoRa: SF8 / 125 kHz |
3125 |
Uplink |
| 3 | LoRa: SF7 / 125 kHz |
5470 |
Uplink |
| 4 | LoRa: SF8 / 500 kHz |
12500 |
Uplink |
| 5 |
|
||
| 6 |
|
||
| 7 |
|
||
| 8 | LoRa: SF12 / 500 kHz |
980 |
Downlink |
| 9 | LoRa: SF11 / 500 kHz |
1760 |
Downlink |
| 10 | LoRa: SF10 / 500 kHz |
3900 |
Downlink |
| 11 | LoRa: SF9 / 500 kHz |
7000 |
Downlink |
| 12 | LoRa: SF8 / 500 kHz |
12500 |
Downlink |
| 13 | LoRa: SF7 / 500 kHz |
21900 |
Downlink |
| 14 |
|
||
| 15 |
|
All US902-928 end devices shall support one of the following data rate options.
- DR0 – DR4 and DR8 – DR13 – the minimal data rate set required to obtain LoRaWAN certification.
- DR0 – DR13 - all data rates are implemented in the end device
When using Over-The-Air-Activation (OTAA), the end device shall transmit the Join-request message on a randomly selected channel as follows.
- 64 channels (each have 125kHz bandwith) defined using DR0
- 8 channels (each have 500kHz bandwidth) defined using DR4
The end device shall change channels for every transmission.
The maximum radiated output power allowed in the USA is EIRP = +30 dBm but for most devices +20 dBm is sufficient. Under the Federal Communications Commission (FCC) there are no duty cycle limitations but there is a 400 ms maximum dwell time per channel. Dwell time is the amount of time needed for a transmission.
¶ US902-928 Maximum Payload Size
The maximum application payload size (length) varies by data rate (configured with spreading factor and bandwidth).
The following table shows the maximum application payload (FRMPayload) size (N) for different data rates.
| Data rate | Configuration | Maximum application payload size (bytes) |
| 0 | LoRa: SF10 / 125 kHz |
11 |
| 1 | LoRa: SF9 / 125 kHz |
53 |
| 2 | LoRa: SF8 / 125 kHz |
125 |
| 3 | LoRa: SF7 / 125 kHz |
242 |
| 4 | LoRa: SF8 / 500 kHz |
242 |
| 5 |
|
|
| 6 |
|
|
| 7 |
|
|
| 8 | LoRa: SF12 / 500 kHz |
53 |
| 9 | LoRa: SF11 / 500 kHz |
129 |
| 10 | LoRa: SF10 / 500 kHz |
242 |
| 11 | LoRa: SF9 / 500 kHz |
242 |
| 12 | LoRa: SF8 / 500 kHz |
242 |
| 13 | LoRa: SF7 / 500 kHz |
242 |
| 14..15 |
|
¶ US902-928 Summary
The following table summarizes all the important parameters we have discussed in this section for US902-928 band.
| Default frequency band | 902-928 MHz |
| Mandatory channel frequencies for join-request |
Upstream: 64 channels - 902.3 – 914.9 MHz in 200 kHz increments) Upstream: 8 channels - 903.0 – 914.2 MHz in 1.6 MHz increments Downstream: 8 channels - 923.3 – 927.5 MHz in 600 kHz increment |
| Mandatory data rates for join-request | 64 (125kHz channels) using DR0 and 8 (500kHz channels) using DR4 |
| Optional data rates | 5-6 |
| Number of channels |
Upstream: 64 (125kHz) + 8 (500 kHz) Downstream: 8 (500 kHz) |
| Default channels | Ch0 - Ch71 |
| Duty cycle | No limit |
| Dwell time limitation |
Ch0-Ch63: 400 ms Ch64-Ch71: No |
| Max EIRP (default) - TXPower 0 | +30 dBm |
| Default RX2 data rate | DR8 |
| Default RX2 frequency | 923.3 MHz |
¶ Other frequency plans
You should have a basic knowledge about some important parameters that are included in other frequency plans.
- CN779-787: Applies to China. The duty cycle is <1% and there is no dwell time limitation. The default maximum EIRP allowed is +12.15 dBm.
- 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.
- KR920: The regulations in South Korea allow the choice of using either a duty-cycle limitation or Listen Before Talk Adaptive Frequency Agility (LBT AFA) transmission management.
- IN865: Applies to India. The default maximum EIRP allowed is +30 dBm.
¶ 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
¶ Message Types
In this chapter, you will learn about different message types used in LoRaWAN 1.0.x and 1.1. These message types are used to transport MAC commands and application data. The Things Fundamentals Certification exam expects you should have basic knowledge on the following topics with regards to the message types:
- Uplink and downlink messages.
- MAC Message types and their uses.
- Sending MAC commands in the FOpts field.
- Sending MAC commands and application data in the FRMPayload field.
- Keys used to encrypt each field that carries MAC Commands and application data.
- Keys used to calculate the Message Integrity Code (MIC) of each message.
¶ Uplink and Downlink Messages
LoRa messages can be divided into uplink and downlink messages based on the direction they travel.
- Uplink messages - Uplink messages are sent by end devices to the Network Server relayed by one or many gateways. If the uplink message belongs to the Application Server or the Join Server, the Network server forwards it to the correct receiver.
- Downlink messages - Each downlink message is sent by the Network Server to only one end device and is relayed by a single gateway. This includes some messages initiated by the Application Server and the Join Server too.
¶ MAC Message Types
LoRaWAN defines several MAC message types.
The following table presents MAC message types that can be found in LoRaWAN 1.0.x and 1.1.
| LoRaWAN 1.0.x | LoRaWAN 1.1 | Description |
| Join-request | Join-request | An uplink message, used by the over-the-air activation (OTAA) procedure |
| Join-accept | Join-accept | A downlink message, used by the over-the-air activation (OTAA) procedure |
| Unconfirmed Data Up | Unconfirmed Data Up | An uplink data frame, confirmation is not required |
| Unconfirmed Data Down | Unconfirmed Data Down | A downlink data frame, confirmation is not required |
| Confirmed Data Up | Confirmed Data Up | An uplink data frame, confirmation is requested |
| Confirmed Data Down | Confirmed Data Down | A downlink data frame, confirmation is requested |
| RFU | Rejoin-request |
1.0.x - Reserved for Future Usage 1.1 - Uplink over-the-air activation (OTAA) Rejoin-request |
| Proprietary | Proprietary | Used to implement non-standard message formats |
¶ Join-request, Rejoin-request, and Join-accept messages
In LoRaWAN 1.0.x, two MAC message types are used by the Over-The-Air-Activation (OTAA) procedure:
- Join-request
- Join-accept
In LoRaWAN 1.1, three MAC message types are used by the Over-The-Air-Activation (OTAA) procedure and for roaming purposes:
- Join-request
- Join-accept
- Rejoin-request
¶ Join-request
The Join-request message is always initiated by an end device and sent to the Network Server. In LoRaWAN versions earlier than 1.0.4 the Join-request message is forwarded by the Network Server to the Application Server. In LoRaWAN 1.1 and 1.0.4+, the Network Server forwards the Join-request message to the device’s Join Server. The Join-request message is not encrypted.
¶ Join-accept
In LoRaWAN versions earlier than 1.0.4 the Join-accept message is generated by the Application Server. In LoRaWAN 1.1 and 1.0.4+ the Join-accept message is generated by the Join Server. In both cases the message passes through the Network Server. Then the Network Server routes the Join-accept message to the correct end-device. The Join-accept message is encrypted as follows.
- In LoRaWAN 1.0, the Join-accept message is encrypted with the AppKey.
- In LoRaWAN 1.1, the Join-accept message is encrypted with different keys as shown in the table below.
| If triggered by | Encryption Key |
| Join-request | NwkKey |
| Rejoin-request type 0, 1, and 2 | JSEncKey |
¶ Rejoin-request
The Rejoin-request message is always initiated by an end device and sent to the Network Server. There are three types of Rejoin-request messages: Type 0, 1, and 2. These message types are used to initialize the new session context for the end device. For the Rejoin-request message, the network replies with a Join-accept message.
¶ Data Messages
There are 4 data message types used in both LoRaWAN 1.0.x and 1.1. These data message types are used to transport both MAC commands and application data which can be combined together in a single message. Data messages can be confirmed or unconfirmed. Confirmed data messages must be acknowledged by the receiver whereas unconfirmed data messages do not need to be acknowledged by the receiver.
A data message is constructed as shown below:
MAC payload of the data messages consists of a frame header (FHDR) followed by an optional port field (FPort) and an optional frame payload (FRMPayload).
| 7 to 22 bytes | 0 to 1 byte | 0 to N bytes |
| FHDR | FPort | FRMPayload |
The frame header (FHDR) of the MAC payload consists of the following fields.
| 4 bytes | 1 byte | 2 bytes | 0 to 15 bytes |
| DevAddr | FCtrl | FCnt | FOpts |
The maximum length of the MAC Payload field is region and data rate-specific and can be found in the Regional Parameters chapter.
¶ Sending MAC Commands and Application-Specific Data
A data message can contain any sequence of MAC commands. A data message can carry both MAC commands and application data simultaneously in separate fields.
MAC commands can be sent either in the frame options field (FOpts) field or frame payload field (FRMPayload) field of a data message, but not both simultaneously.
Application data can be sent in the frame payload (FRMPayload) field of a data message. The FRMPayload field CAN NOT contain MAC commands and application data simultaneously.
¶ Sending MAC Commands in FOpts Field
MAC commands can be piggybacked in the FOpts field of a data message for sending. The total length of the MAC commands MUST NOT exceed 15 bytes.
- In LoRaWAN 1.0.x, these piggybacked MAC commands are always sent unencrypted.
- In LoRaWAN 1.1, these piggybacked MAC commands are always sent encrypted using the NwkSEncKey.
¶ Sending MAC Commands and Application-specific data in the FRMPayload field
The FRMPayload field can contain MAC Commands or application data. If the FRMPayload field is not empty, the FPort field must be present. If the FPort field is present,
- FPort value
0indicates that the FRMPayload field contains only MAC commands. The total length of the MAC commands MUST NOT exceed the maximum FRMPayload length (region-specific). - FPort value
1-223indicates that the FRMPayload field contains application data.
The following table shows the possible values for the FPort field depending on what it carries.
| FPort Value | Description |
| 0 | MAC commands only |
| 1 to 223 | Application-specific data |
| 224 | LoRaWAN MAC layer test protocol |
| 255 | Reserved for Future Use (RFU) |
If the FRMPaylod field contains MAC commands or application data, the FRMPayload field must be encrypted before the Message Integrity Code (MIC) is calculated. This ensures message confidentiality. The following table shows which key is used to encrypt the FRMPayload field in different LoRaWAN versions.
| FRMPayload | Direction | FPort | 1.0.x | 1.1 |
| MAC Commands | Uplink/Downlink | 0 | NwkSKey | NwkSEncKey |
| Application-specific data | Uplink/Downlink | 1 to 223 | AppSKey | AppSKey |
¶ Calculating the Message Integrity Code (MIC)
The Message Integrity Code (MIC) ensures the integrity and authenticity of a message. The message integrity code is calculated over all the fields in the message and then added to the message itself. The following list shows what fields are used to calculate the MIC for each message type in LoRaWAN 1.0.x and 1.1.
| LoRaWAN version | Message Type | Fields |
| 1.0.x | Join-request | MHDR | AppEUI | DevEUI | DevNonce |
| 1.0.x | Join-accept | MHDR | AppNonce | NetID | DevAddr | DLSettings | RxDelay | CFList |
| 1.0.x | Data messages (up and down) | MHDR | FHDR | FPort | FRMPayload |
| 1.1 | Join-request | MHDR | JoinEUI | DevEUI | DevNonce |
| 1.1 | Join-accept | MHDR | JoinNonce | NetID | DevAddr | DLSettings | RxDelay | CFList |
| 1.1 | Rejoin-request Type 0 and 2 | MHDR | Rejoin Type | NetID | DevEUI | RJcount0 |
| 1.1 | Rejoin-request Type 1 | MHDR | Rejoin Type | JoinEUI | DevEUI | RJcount1 |
| 1.1 | Data messages (up and down) | MHDR | FHDR | FPort | FRMPayload |
The following table presents which key is used to calculate the MIC of each message type in LoRaWAN 1.0.x and 1.1.
| LoRaWAN version | Message Type | Key |
| 1.0.x | Join-request | AppKey |
| 1.0.x | Join-accept | AppKey |
| 1.0.x | Uplink data message | NwkSKey |
| 1.0.x | Downlink data messages | NwkSKey |
| 1.1 | Join-request | NwkKey |
| 1.1 | Join-accept | JSIntKey |
| 1.1 | Rejoin-request Type 0 and 2 | SNwkSIntKey |
| 1.1 | Rejoin-request Type 1 | JSIntKey |
| 1.1 | Uplink data messages | FNwkSIntKey and SNwkSIntKey |
| 1.1 | Downlink data message | SNwkSIntKey |
When a LoRaWAN 1.1 device is provisioned with a LoRaWAN 1.0.x Network Server, the MIC of each message is calculated as shown in the following table.
| Message Type | Key |
| Join-request | NwkKey |
| Join-accept | NwkKey |
| Uplink data messages | FNwkSIntKey |
| Downlink data messages | FNwkSIntKey |
¶ Security
¶ Security Keys
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.
¶ Frame Counters
Because we’re working with a radio protocol, anyone will be able to capture and store messages. It’s not possible to read these messages without the AppSKey, because they’re encrypted. Nor is it possible to tamper with them without the NwkSKey, because this will make the MIC check fail. It is however possible to re-transmit the messages. These so-called replay attacks can be detected and blocked using frame counters.
When a device is activated, these frame counters (FCntUp and FCntDown) are both set to 0. Every time the device transmits an uplink message, the FCntUp is incremented and every time the network sends a downlink message, the FCntDown is incremented. If either the device or the network receives a message with a frame counter that is lower than the last one, the message is ignored.
This security measure has consequences for development devices, which often are statically activated (ABP). When you do this, you should realize that these frame counters reset to 0 every time the device restarts (when you flash the firmware or when you unplug it). As a result, The Things Network will block all messages from the device until the FCntUp becomes higher than the previous FCntUp. Therefore, you should re-register your device in the backend every time you reset it.
¶ Spread Spectrum
Spread Spectrum Radio Transmission was traditionally used, during WW2, to make military communications difficult to monitor - either by using a technique called ‘frequency hopping’ (FHSS) - skipping the transmission frequency around in a prearranged manner, causing the enemy to constantly retune (very rapidly) or ‘direct sequence’ (DSSS) where the digital message is added to a much higher bit-rate, pseudo random (PR) sequence. The code spreads the radio signal over a much wider bandwidth. In fact, so wide that the power may well be dispersed so that the total signal falls down into the background radio noise - and becomes invisible. Recovery is therefore a matter of i) knowing the original radio frequency ii) the pseudo random code and iii) and the PR code bit rate. Knowing these details means that synchronising receivers is not as difficult as may at first appear. The signal will just ‘pop up’ out of the noise when the correct values are achieved. (‘Processing Gain’)
The technique used in LoRa is ‘CHIRP’: Compressed High Intensity Radar Pulse. It is even more complex but simple with current technology. As the name may suggest, the background design requirement, it is not used to hide the radio signal but is employed because of other factors, not just processing gain but interference immunity, channel sharing and resistance to radio reflections (amongst others). It is therefore employed as security against operating conditions not for surveillance resistance. (Hedy Lamarr was a co-inventor and holds a patent for FHSS).
¶ Device Classes
The LoRaWAN specification defines three device types: Class A, Class B, and Class C. All LoRaWAN devices must implement Class A, whereas Class B and Class C are extensions to the specification of Class A devices. All device classes support bi-directional communication (uplink and downlink)
End devices can’t send uplink messages while they receive downlink messages.
¶ Class A
All LoRaWAN end-devices must support Class A implementation. Class A communication is always initiated by the end-device. A device can send an uplink message at any time. Once the uplink transmission is completed the device opens two short receive (downlink) windows. There is a delay between the end of the uplink transmission and the start of the receive windows (RX1 and RX2 respectively. If the network server does not respond during these two receive windows, the next downlink will be after the next uplink transmission.
The server can respond during the first receive window (RX1), or during the second receive window (RX2), but does not use both windows. Let’s consider three situations for downlink messages as illustrated below.
- Case 1: The end device opens both receive windows but it doesn’t receive an downlink message during either receive window.
- Case 2: The end device receives a downlink during the first receive window and therefore it does not open the second receive window.
- Case 3: The end device opens the first receive window but it does not receive a downlink. Therefore it opens the second receive window and it receives a downlink during the second receive window.
Class A end devices:
- are often battery-powered
- have the lowest energy consumption
- spend most of the time in sleep mode
- usually keep long intervals between uplinks
- have high downlink latency (to receive a downlink, the end device must send an uplink)
Some common use cases for Class A end-devices:
- Environmental monitoring
- Animal tracking
- Fire detection
- Water leakage detection
- Earthquake early detection
- Location tracking
¶ Class B
In addition to the class A initiated receive windows, Class B devices open scheduled receive windows for receiving downlink messages from the network server. Using time-synchronized beacons transmitted by the gateway, the devices periodically open receive windows. The time between two beacons is known as the beacon period. The device opens downlink ‘ping slots’ at scheduled times for receiving downlink messages from the network server. Class B devices also open receive windows after sending an uplink, as you can see below:
Class B end devices have lower latency than the Class A end devices, because they are reachable at preconfigured times and do not need to send an uplink to receive a downlink. The battery life is shorter in Class B than Class A, because the device spends more time in active mode, during beacons and ping slots.
Some common use cases for Class B end-devices:
- Utility meters
- Temperature reporting
¶ Class C
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.
Class C end devices:
- are often mains powered
- have no downlink latency - continuous receive window
The following are some common Class C end device applications, but there are more:
- Utility meters with cut-off valves/switches
- Streetlights
¶ End Device Activation
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.
The join procedure for LoRaWAN 1.0.x and 1.1 is slightly different. The following two sections describe the join procedure for LoRaWAN 1.0.x and 1.1 separately.
¶ Over The Air Activation in LoRaWAN 1.0.x
In LoRaWAN 1.0.x, the join procedure requires two MAC messages to be exchanged between the end device and the Network Server:
- Join-request - from end device to the Network Server
- Join-accept - from Network Server to the end device
Before activation, the AppEUI, DevEUI, and AppKey should be stored in the end device. The AppKey is an AES-128 bit secret key known as the root key. The same AppKey should be provisioned onto the network where the end device is going to register. The AppEUI and DevEUI are not secret and are visible to everyone.
The AppKey is never sent over the network.
The following steps describe the Over-The-Air-Activation (OTAA) procedure.
¶ 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.
| 8 bytes | 8 bytes | 2 bytes |
| AppEUI | DevEUI | DevNonce |
- AppEUI – a 64-bit globally unique application identifier in IEEE EUI64 address space that uniquely identifies the entity able to process the Join-req frame.
- DevEUI – a 64-bit globally unique device identifier in IEEE EUI64 address space that uniquely identifies the end-device.
- DevNonce – a unique, random, 2-byte value generated by the end device. The Network Server uses the DevNonce of each end-device to keep track of their join requests. If an end device sends a Join-request with a previously used DevNonce (this situation is known as a replay attack), the Network Server rejects the Join-request and does not allow that end device to register with the network.
The Message Integrity Code (MIC) is calculated over all the fields in the Join-request message using the AppKey. The calculated MIC is then added to the Join-request message.
The AppKey is not sent with the Join-request message, and the Join-request message is not encrypted.
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 processes the Join-request message. The Network Server will generate two session keys (NwkSKey and AppSKey) and the Join-accept message if the end-device is permitted to join a network.
The Join-accept message consists of the following fields.
| 3 bytes | 3 bytes | 4 bytes | 1 bytes | 1 bytes | 16 bytes (optional) |
| AppNonce | NetID | DevAddr | DLSettings | RXDelay | CFList |
- AppNonce – a random value or unique ID provided by the Network Server. The AppNonce is used by the end device to derive the two session keys, AppSKey and NwkSKey.
- NetID – consists of the network identifier (NwkID), the most significant 7 bits.
- 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 the 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 the AppKey. The calculated MIC is then added to the Join-accept message.
The Join-accept message itself is then encrypted with the AppKey. The Network Server uses an AES decrypt operation in ECB mode to encrypt the Join-accept message.
¶ Step 3
The Network Server sends the encrypted Join-accept message back to the end device as a normal downlink.
No response is given to the end-device if the Join-request message is not accepted by the Network Server.
¶ Step 4
The Network Server keeps the NwkSKey and distributes the AppSKey to the Application Server.
¶ Step 5
The end device decrypts the Join-accept message using AES encrypt operation. The end device uses the AppKey and AppNonce to derive the two session keys, the Network Session Key (NwkSKey) and the Application Session Key (AppSKey).
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.
- NwkSKey - the network session key is used by the end device and Network Server to calculate and verify the Message Integrity Code (MIC) of all data messages for ensuring message integrity. The NwkSKey is also used to encrypt and decrypt payloads with MAC commands.
- AppSKey - the application session key is used to encrypt and decrypt application payloads in data messages for ensuring message confidentiality.
¶ 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 AppKey and NwkKey are never sent over the network.
The following steps describe the Over-The-Air-Activation (OTAA) procedure.
¶ 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.
| 8 bytes | 8 bytes | 2 bytes |
| JoinEUI | DevEUI | DevNonce |
- 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.
In LoRaWAN 1.1 AppEUI is replaced with the JoinEUI.
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 NwkKey is not sent with the Join-request message, and the Join-request message is not encrypted but sent as plain text.
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.
No response is given to the end-device if the Join-request is not accepted.
¶ 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.
| 1 byte | 3 bytes | 4 bytes | 1 bytes | 1 bytes | 16 bytes |
| JoinNonce | NetID | DevAddr | DLSettings | RXDelay | CFList |
- 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.
No response is given to the end-device if the Join-request message is not accepted by the Network Server.
¶ 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.
¶ Activation By Personalisation in LoRaWAN 1.0.x
The DevAddr and the two session keys NwkSKey and AppSKey are directly stored into the end-device instead of the DevEUI, AppEUI, and the AppKey. Each end device should have a unique set of NwkSKey and AppSkey. The same DevAddr and NwkSKey should be stored in the Network Server and the AppSKey should be stored in the Application Server
¶ Activation By Personalisation in LoRaWAN 1.1
The DevAddr and the four-session keys FNwkSIntKey, SNwkSIntKey, NwkSEncKey, and AppSKey are directly stored into the end device instead of the DevEUI, JoinEUI, AppKey, and NwkKey. The same DevAddr, FNwkSIntKey, SNwkSIntKey, and NwkSEncKey should be stored in the Network Server and the and AppSKey should be stored in the Application Server.
¶ Spreading Factors
LoRa is based on Chirp Spread Spectrum (CSS) technology, where chirps (also known as symbols) are the carrier of data.
The spreading factor controls the chirp rate, and thus controls the speed of data transmission. Lower spreading factors mean faster chirps and therefore a higher data transmission rate. For every increase in spreading factor, the chirp sweep rate is halved, and so the data transmission rate is halved.
For a visual explanation, see this video on LoRa chirps.
Lower spreading factors reduce the range of LoRa transmissions, because they reduce the processing gain and increase the bit rate. Changing spreading factor allows the network to increase or decrease data rate for each end device at the cost of range.
The network also uses spreading factors to control congestion. Spreading factors are orthogonal, so signals modulated with different spreading factors and transmitted on the same frequency channel at the same time do not interfere with each other.
¶ Influence of Spreading Factors
LoRa modulation has a total of 6 spreading factors from SF7 to SF12. Spreading factors influence data rate, time-on-air, battery life, and receiver sensitivity, as described here.
¶ Data rate
Compared to a higher spreading factor, a lower spreading factor provides a higher bit rate for a fixed bandwidth and coding rate. For example, SF7 provides a higher bit rate than SF12.
Doubling the bandwidth also doubles the bit rate for a fixed spreading factor and coding rate.
The following table presents bit rates calculated with the SF7 and Coding Rate (CR) = 1 for bandwidths, 125, 250, and 500 kHz.
| Spreading Factor | Bandwidth | Bit rate (kbits/s) |
| 7 | 125 | 5.5 |
| 7 | 250 | 10.9 |
| 7 | 500 | 21.9 |
¶ Distance
Larger spreading factors mean larger processing gain, and so a signal modulated with a larger spreading factor can be received with less errors compared to a signal with a lower spreading factor, and therefore travel a longer distance. For example, a signal modulated with the SF12 can travel a longer distance than a signal modulated with the SF7.
¶ Time-On-Air
Compared to a lower spreading factor, sending a fixed amount of data (payload) with a higher Spreading Factor and a fixed bandwidth needs longer time-on-air.
The Things Network’s LoRaWAN airtime calculator can be used to calculate the time-on-air using input bytes (payload size), bandwidth, and spreading factor. TTN’s LoRaWAN airtime calculator can be accessed here.
¶ Receiver Sensitivity
Higher spreading factors provide higher receiver sensitivity. Usually, LoRa uses higher spreading factors when the signal is weak.
The following table shows how spreading factors impact the receiver sensitivity.
| Spreading factor | Receiver sensitivity for bandwidth fixed at 125 kHz |
| SF7 | -123 dBm |
| SF8 | -126 dBm |
| SF9 | -129 dBm |
| SF10 | -132 dBm |
| SF11 | -134.5 dBm |
| SF12 | -137 dBm |
¶ Battery Life
The battery life of an end device is highly dependent on the spreading factor used. Higher spreading factors result in longer active times for the radio transceivers and shorter battery life.
¶ 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.
¶ 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
¶ Sending data from a Node to your Application (uplink)
We want you to create products that are as efficient as possible. This will get the most out of your battery, and doesn’t require you to buy many gateways. If you follow these recommendations, you’ll definitely build an amazing product!
- Payload should be as small as possible. This means that you should not send JSON or plain (ASCII) text, but instead encode your data as binary data. This is made really easy with the Cayenne Low Power Payload format which is fully supported by The Things Network.
- Interval between messages should be in the range of several minutes, so be smart with your data. You could for example transmit a
min|avg|maxevery 5 minutes, or you could only transmit when you sensor value changed more than a certain threshold or have it triggered by motion or another event. - Data Rate should be as fast as possible to minimize your airtime.
SF7BW125is usually a good place to start, as it consumes the least power and airtime. If you need more range, you can slowly increase until you have enough. You can also enable adaptive data rate (ADR), the network will then be able to automatically optimize your data rate.
¶ Sending responses from your Application to your Node (downlink)
We want to be able to handle as many Nodes as possible per Gateway. But as full-duplex radios are not widely available yet, a Gateway is not able to receive transmissions from Nodes while it is transmitting. This means that if a gateway is transmitting 10% of the time, it’s not able to receive anything for that 10% of the time. This is even worse when you realize that a gateway can receive at 8 channels simultaneously. Except when it’s transmitting. So while an idle gateway can receive transmissions from 8 devices, those 8 devices are worthless when the gateway is transmitting.
We want to build a network that offers high reliability. If your device transmits, the gateway should receive it. In order to keep the gateway availability as high as we can, we ask you to follow these recommendations.
- Data Rate should be, just as with uplink, as efficient as possible. The downlink data rate is based on the uplink data rate, so if you send efficient uplinks, the network will respond with efficient downlinks.
- Downlink messages should be avoided if possible, and if you send downlink, keep the payload small.
- Confirmed Uplink is often not necessary. Try to make your application work without confirmations.