Insight

Building an IoT ecosystem leveraging LoRaWAN? Learn what factors to consider early-on for the highest success.

Published April 7, 2022

Contributers to this article include Mike Schaaf, Mohamed Ismail, and Riyadth Al-Kazily.

‍

The LoRaWAN protocol is frequently discussed as part of the Internet of Things (IoT, aka “Information of Things”) products, however, this protocol has many specific characteristics that can make or break a successful IoT implementation.

In this post, we describe some of the LoRaWAN characteristics and identify implementation considerations that should be addressed early on when architecting an IoT ecosystem leveraging LoRaWAN:

LoRaWAN ecosystem components overview
Radio frequencies & regulations
LoRaWAN coverage & gateways
LoRaWAN collisions & message loss
LoRa bands’ existing usage
LoRaWAN modulation – data rate – spreading factor
Device class and power consumption
Security – device identification – provisioning
Joining a logical network instance
Over-the-air firmware updates
Device localization
LoRaWAN platform options

‍

Key takeaway:

LoRaWAN is a very efficient and flexible communication technology, applicable to use cases that have well-defined deployment topologies and where some data loss is tolerable.

The target user experience & service level expectations should be carefully defined before selecting LoRaWAN as a communication technology to ensure applicability. Additionally, complex optimization of numerous interrelated parameters should be expected to ensure the best ecosystem outcome.

‍

LoRaWAN ecosystem components overview

LoRaWAN is a cloud-based medium access control (MAC) layer protocol standard (OSI layer 3), maintained by the LoRa Alliance, and characterized by wireless broadcast, low throughput, low data rate, and long-range.
‍

Here is an overview of the main components of a LoRaWAN ecosystem:

A device is a sensor or an actuator that is wirelessly connected to a LoRaWAN network through radio gateways using the LoRa physical layer modulation technique (OSI layer 1). Many devices can broadcast to a single gateway within a range of up to 10 miles in a clear line of sight. When they are being manufactured, LoRaWAN devices are assigned several unique identifiers.
A gateway receives LoRa modulated RF messages from any device in range, converts LoRaWAN packets into IP packets, and forwards these data messages to the LoRaWAN Network Server. The gateway only performs an integrity check before forwarding the message.
The LoRaWAN Network Server (LNS) ensures the authenticity of every sensor on the network, the integrity & deduplication of every message, and manages the entire network with dynamically control such as adaptive data rate (ADR) mechanisms.
The Join Server manages the over-the-air activation process for end devices to be added to the logical network.
The Application Server is responsible for securely handling, managing, and interpreting sensor application data. It also generates all the application-layer downlink payloads to the connected end devices.
The Information Processing component represents the additional processing logic and presentation typically needed to generate the added value pertinent to the use cases.

‍

Radio frequencies & regulations

Even though LoRaWAN leverages a license-free sub-gigahertz radio frequency, operations are regulated and constrained to geography-specific radio bands (902-928 MHz in the US, 863-870/873 MHz in Europe, etc.)

The broadcast duty cycle is also regulated in some geographies (for example limited to 1% for some bands in Europe, see RP002-1.0.2).

Implementation success factors

Because the radio bands are locally regulated, target deployment geographies must be known to select the appropriate band(s).
Some radio modules may enforce the duty cycle limits, so a detailed payload and topology model should be built prior to selecting physical components.
Time-on-Air is a function of the payload size, so the desired information and end-user experience should drive the LoRaWAN technology applicability assessment.
Duty cycle regulations apply to both sensors and gateways, so downlink payloads should also be modeled.

‍

LoRaWAN coverage & gateways

LoRaWAN gateways must be deployed in addition to the sensors. Gateways require continuous power and network connectivity, wired or wireless. Some harsh environments may require ingress protection and/or inclement weather capabilities. Some LoRaWAN providers own the gateways and their deployment.

Adding gateways to a LoRaWAN network provides:

Increased geographical coverage.
Increased sensor volume coverage.
Increased message payload capacity.
Increase message delivery success rate.

Implementation success factors

Walls and structures can block line-of-sight, significantly decreasing communication range so theoretical ranges may not apply and a site analysis may be needed for deployments associated with strict service level agreements.
To avoid coverage blind spots, the gateway topology may need to be designed to include sufficient overlap.
Redundant gateways may need to be added to the deployment topology to increase the message delivery success rate.
A shorter distance between sensor and gateway means longer battery life and lower spreading factor.
The gateway density is correlated to many of the other parameters of a LoRaWAN deployment and should be designed as part of the payload and topology model.
In the total-cost-of-ownership estimation of a LoRaWAN deployment, either gateway procurement with installation costs or deployed network provider costs need to be factored in.
Messages received by multiple gateways and messages transmitted multiple times are deduplicated by the Network Server component.
Duplicate messages increase the load on the network connection between the gateway and the Network Server component and on the Network Server component itself.

‍

LoRaWAN collisions & message loss

LoRaWAN theoretical message delivery success rate is seldomly reached:

A gateway with 8 channels should theoretically support several hundred thousand messages per day, or 10k devices if each transmits 10 messages per day.
Studies and actual deployments have identified higher message failure rates than in the theoretical models, in part because devices may broadcast simultaneously increasing the likelihood of collisions.

Implementation success factors

Some LoRaWAN gateway manufacturers and platform providers recommend much lower sensor densities per gateway (e.g., 100 maximum and only 20 if messages are broadcasted every 60 seconds), so it is important to tailor the payload and topology model to the considered providers.
The probability of message delivery failure depends on the use case and the deployment topology; message collision rates and duty cycle limitations imply a tolerance for data loss that should be formalized into a service level agreement to ensure alignment of all stakeholders.
Message retransmission and/or deduplication may increase data latency that should also be formalized into a service level agreement.
Message acknowledgment increases the delivery success rate by triggering retransmission but also increases the load on the network and costs of platforms that include a per-message charge.

‍

LoRa bands existing usage

LoRaWAN shares bandwidth with all the deployments within range:

Typical existing urban environment deployments include utilities smart meters, smart parking, etc.
Provider networks may offer only partial coverage.

Implementation success factors

Other networks sharing the same protocols and network type (public/private) may also increase the collision rate, so the target deployment areas should be scanned for these potential interferences, especially in urban environments.
The physical layer preamble sync word can only differentiate public from private networks, allowing gateways to mostly keep packets of the selected network type. However, all packets of the same network type –including packets of unrelated LoRaWAN providers- are transmitted by the gateway to the Network Server, so metered backhaul network connection costs and additional load on the Network Server may need to be analyzed as part of the total-cost-of-ownership.
An increase in LoRaWAN deployments may overtime increase collisions and message loss, so ongoing operations should include monitoring of bands usage and message delivery success rate; additionally, a custom packet filtering may need to be deployed on the gateways, increasing the corresponding costs.
Provider networks typically have coverage limitations, so the target deployment areas should be mapped against the providers’ coverage.

‍

LoRaWAN modulation – data rate – spreading factor

LoRa uses a proprietary spread-spectrum modulation technique derived from existing Chirp Spread Spectrum (CSS) technology.

LoRa offers a trade-off between sensitivity and data rate while operating in a fixed-bandwidth channel.
LoRa modulation spreading factors are orthogonal: signals modulated with different spreading factors and transmitted on the same frequency channel at the same time do not interfere with each other.
Spreading factors optimize power levels to the distance between the devices (sensors) and the gateway.
The Adaptive Data Rate mechanism controls transmission parameters of an end device: spreading factor, bandwidth, transmission power.
Acknowledgment mode can trigger retransmission, increasing the successful transmission rate but decreasing the network capacity and increasing the gateway duty cycle.

Implementation success factors

An adaptive data rate (ADR) mechanism is essential to minimize the power consumption of LoRaWAN end-nodes by having end-nodes closest to a gateway transmit using the lowest spreading factor, thereby minimizing their time on air. However, the specific ADR mechanism should be designed to address the specific target deployment areas and service level agreement. The ADR mechanism is deployed in the Network Server component.
Optimizations can significantly improve the data transmission success rate in the target deployment areas to meet the defined service level agreement. So, such optimization effort should be undertaken after the target deployment areas and service level agreement have been defined.
Message acknowledgment may require increasing gateway density, with the associated costs, to comply with duty cycle regulations.

‍

Device class and power consumption

Devices in a LoRaWAN network come in three classes: Class A, Class B, and Class C. Devices can broadcast messages “uplinks” at any time; however, the device’s class determines when it can receive downlinks. The class also determines a device’s energy efficiency.

Class A devices (“Aloha”): communications are triggered by events (e.g., change in sensor reading) or by a timer. After the device sends a message, it listens for a message from the network at 1 second and at 2 seconds after the send. The rest of the time the device is sleeping. Class A devices are the most energy-efficient.
Class B devices: in addition to class A communications, the device also periodically listens for a message from the network.
Class C devices (“Continuous”): these devices never go to sleep and constantly listen for messages from the network (except when sending messages).

Implementation success factors

Because the power requirements are very different, the specific ecosystem requirements should drive the device class selection.
Frequent downlink transmission to class C devices may increase the gateway duty cycle, potentially requiring a higher gateway density.

‍

Security – device identification – provisioning

LoRaWAN message payload is encrypted end-to-end between the device and the Application Server, using multiple 128bit encryption keys.

Network Session Key (NwkSKey) between the device and the Network Server for integrity.
Application Session Key (AppSKey) for encryption and decryption of the payload for confidentiality.
Application Key (AppKey) is used to generate the session keys for the device and by the application.

‍

LoRaWAN devices use a combination of identifiers:

Device Unique Identifier (DevEUI) that globally uniquely identifies the device and is assigned by the manufacturer.
Join Server Unique Identifier (JoinEUI) that indicates who manages the security and authorizes the device.
Device Address (DevAddr) that uniquely identifies the end-device within the current logical network.

Implementation success factors

LoRaWAN is secure when implemented and deployed properly, so reported attack vulnerabilities and misconfigurations should be frequently analyzed and quickly addressed.
It may also be beneficial to seek certification by the LoRa Alliance to demonstrate due diligence.
To create DevEUI (EUI-64) identifiers, the manufacturer/assignor must first have an Organizationally Unique Identifier (OUI) from the IEEE Registration Authority.
It may be useful to allocate and track DevEUI identifiers in a structured fashion early in a new product lifecycle to support prototyping and testing activities.

‍

Joining a logical network instance

LoRaWAN deployments group devices, gateways, and network server instances in logical “networks”.

The join process receive windows allow only two opportunities to receive the join acknowledgment after the device transmits the join request; the timing of these windows is specific to each region.
Devices that are activated in batches may try to join the network in a short period of time; join frequencies may be specific to some regions while others may leave the frequencies open to the available spectrum.

Implementation success factors

The process of joining a network should be designed to support the target number of concurrent devices activation while also consuming the smallest amount of power in the process and in compliance with the deployment regions’ specifications as duty cycle regulations also apply to join frequencies.
Join requests will take more time on-air than uplink messages and have a higher chance of interfering with other join attempts and with uplink message traffic from other devices.

‍

Over-the-air firmware updates

LoRaWAN supports broadcast over-the-air firmware updates:

LoRaWAN has a radio multicast capability, broadcasting packets of the firmware update to many devices, addressing the low bit rate and duty cycle limitations.
Devices receiving a multicast firmware update must have their receivers active at the same time.

Implementation success factors

Duty cycle limitations may prevent the gateway from transmitting some firmware update packets, so the OTA update may require some retransmissions.
Time synchronization on the devices requires trade-offs between power consumption, application requirements, and timing precision.
LoRaWAN deployments should identify early on the frequency and volume of firmware updates as those may impact the long-term operations of the ecosystem.

‍

Device localization

LoRaWAN provides localization of devices:

Within approximately 50 meters without additional hardware modules such as GPS and without additional power consumption.
A device location is approximated from radio metadata: time difference of arrival (TDOA) and/or RSSI/SNR information.

Implementation success factors

Geolocation accuracy requirements should be defined early on to assess technology compatibility.
Gateways would typically need to support high-resolution time-stamping for TDOA.
LoRaWAN based localization may require configuration changes on the Network Server or Application Server components.
Multiple localization technologies can be implemented in hybrid devices, but with an increase in product and operation costs, and with an increase in power consumption.

‍

LoRaWAN platform options

LoRaWAN is a cloud-based protocol and implementation platforms typically contain:

Cloud-based software: Network Server, Application Server, Join Server, and sometimes other components, such as localization service, depending on the specific provider.
These components typically need to comply with specific versions of the LoRaWAN standard.
Implementation of the cloud-based software should include defined service level agreements, disaster recovery, security audits, certification, etc.
Gateway: may be manufactured by the platform provider or rely on compatible and/or certified partners.
Gateways typically need to comply with specific versions of the LoRaWAN standard, target geographic areas regulations, and with the corresponding cloud-based software.
Device: may be manufactured by the platform provider or rely on compatible and/or certified partners.
Devices typically need to comply with specific versions of the LoRaWAN standard, target geographic areas regulations, and with the corresponding cloud-based software.

Implementation success factors

Typical LoRaWAN deployments will involve multiple partners for ongoing operations, so long-term viability and product roadmap compatibility should be evaluated early during the ecosystem architecture phase.
Providers may support new LoRaWAN standard versions at different paces so there may be an interdependency between technical features, providers, and schedule.
Some providers may only service specific geographic areas and frequency bands.
Gateways and sensors may need to be certified in the target geographic areas.
In most cases, implementers must also design, deploy, and operate the specific information processing logic and digital user experience pertinent to their use cases.

‍

Conclusion

LoRaWAN is a very efficient and flexible communication technology, applicable to use cases that have well-defined deployment topologies and where some data loss is tolerable.

The target user experience & service level expectations should be carefully defined prior to selecting LoRaWAN as a communication technology to ensure applicability. Additionally, complex optimization of numerous interrelated parameters should be expected to ensure the best ecosystem outcome.

Examples of applicable use cases for LoRaWAN:

Smart agriculture: long line-of-sight range, limited or no power outlets, low LoRaWAN packet density since it is a rural area, some data loss should be tolerable (though data loss tolerance should be evaluated).
Utility metering: medium line-of-sight range (so more gateways should be expected), limited or no power outlets, some data loss should be tolerable (though this may need to be balanced with higher transmission rates). However, a medium to high LoRaWAN packet density in an urban area should be expected, which may have to be mitigated through custom packet filtering on the gateway.
Smart environment: long to medium line-of-sight range (so more gateways could be expected), limited or no power outlets, some data loss should be tolerable (provided that coarse information and trends are sufficient). LoRaWAN packet density may vary from low in rural areas to medium or high in urban areas so custom packet filtering on the gateway may be needed.

‍

Are you interested in finding out how these LoRaWAN considerations may apply to your context? Contact us to schedule a discussion tailored to your specific needs.

‍

Further readings:

Semtech LoRaWAN documentation: https://lora-developers.semtech.com/documentation/tech-papers-and-guides/

LoRa Alliance specifiations: https://resources.lora-alliance.org/technical-specifications