LoRaWAN fundamentals

This article is about Wattsense LoRaWAN architecture.

Basic LoRaWAN communication :

Once the sensors have performed a pairing process known as JOIN, they proceed to transmit their data to the Wattsense Boxes using the LoRaWAN protocol.
Our Tower/Bridge are equiped with an embedded LoRaWAN server, designed to decode locally and interpret the valuable information originating from the sensors.
Once the data has been successfully decoded, it is transmitted either to our backend system, should the device in question be a Tower, or to the dedicated Local server, in the case of a Bridge or a Tower.

This intelligent routing mechanism ensures that the data flows smoothly and is delivered to the appropriate destination for further processing and analysis.

The Wattsense LoRaWAN architecture can be explained as follows :

Glossary :

End Devices : Sensors or actuators transmit wireless messages using LoRaWAN to the Wattsense gateway (Tower or Bridge). They can also wirelessly receive messages from the gateways.

Wattsense LoraWAN Gateway : Our gateways receive messages from end devices and forward them to our backend in case of a Tower or a local server in case of a Bridge.

If you need any additional information, please contact us here.

What is the ADR?

The LoRaWAN server employs an Adaptive Data Rate (ADR) mechanism, which is a crucial component of the LoRaWAN Stack, to dynamically adjust the spreading factor based on certain rules. According to Semtech documentation, the ADR mechanism simplifies the process of changing the data rate by following guidelines:

1. If the link budget, which represents the overall signal quality and strength, is high, the data rate can be increased by increasing the spreading factor (SF).
2. Conversely, if the link budget is low, the data rate can be lowered by reducing the spreading factor (SF).

By tailoring the data rate to the available link budget, the ADR mechanism ensures optimal performance for each end device within the LoRaWAN network. The network server utilizes the Received Signal Strength Indicator (RSSI) of the received messages from an end device to assess the proximity of the device to the nearest gateway(s).
This information enables the network server to select the most suitable settings for each specific end device.

The benefits of utilizing ADR are twofold: it helps preserve the battery life of end devices and reduces interference, thus increasing the communication performance for all devices within the network.

To fine-tune the data rate adjustments, our LoRaWAN server employs a strategy. It establishes an average using the data from the 10 most recent frames.
Additionally, it waits for 10 successive frames with stable sensor data rate before initiating any ADR requests.
For example: if the server observes 8 successive frames at SF8, and the sensor subsequently switches to SF10 for any reason, the server will reset the waiting period and require 10 successive frames at SF10 before sending an ADR request. This approach ensures stability and reliability in adjusting the data rate of the end devices.

Other benefits:

In addition, there are other notable advantages to consider having correct (low) SF:

1. Increased Sensor Capacity: The choice of spreading factor directly influences the number of sensors that can be connected to your Wattsense product. Opting for a lower spreading factor allows for a higher density of sensor connections within your project.

2. Reduced Uplink Time Delays: When the LoRaWAN server receives uplinks modulated with SF12, it needs to accommodate longer time delays compared to receiving uplinks in SF7. This consideration is important for optimizing the overall efficiency and responsiveness of the network.

By carefully managing the spreading factor and considering these benefits, you can effectively enhance the scalability and performance of your LoRaWAN project.

Here is a theoretical schematic:

We can easily see that using a better SF, the LoRaWAN server will be able to deal with more uplinks in the same period of time.

This article is about good practice for LoRaWAN projects.

LoRaWAN may not be suitable for all use cases, so it's crucial to understand its limitations. Here's a brief summary of the best practices to follow when building a LoraWAN project :

Suitable use-cases for LoRaWAN :

• Long-range communication
• Low power consumption: Devices can operate for years on a single battery.
• Low bandwidth requirement
• Wide coverage: Users can establish their own network by installing gateways.
• Secure : End-to-end encryption with 128-bit security.

Not suitable for LoRaWAN :

• Real-time data transmission : Large amounts of data cannot be sent frequently ; small packets can be sent every few minutes.
• Phone calls : For voice communication, other technologies like GPRS/3G/LTE should be used.
• High-bandwidth tasks like sending photos or streaming videos: WiFi is recommended for these purposes.

Hardware installation good practice :

Box antenna placement :

An antenna's placement and configuration can significantly impact the performance and range of LoRaWAN devices. We'll dive into the essential considerations and best practices for correct antenna installation in LoRaWAN networks.

A crucial step is to determine the optimal placement for your LoRaWAN antenna. Here are some considerations :

• Height : Mount your antenna as high as possible to reduce obstructions and increase line-of-sight communication with the sensors. 
• Line of Sight : Minimize obstacles between the LoRaWAN device and the gateway. Buildings, trees, and other structures can attenuate the signal and reduce range. Whenever possible, choose a location with a clear line of sight to the Box.
• Cable Length : Keep the cable length between the LoRaWAN device and the antenna as short as possible to minimize signal loss. Use low-loss coaxial cables for longer cable lengths. The cable should not exceed 10m.

Sensor placement : 

Please be sure to read the manufacturers' documentation, as they usually have recommendations for sensor placement.

Perform a radio-mapping :

Performing a LoraWAN radio mapping will allow you to evaluate you LoraWAN network quality and help you to find the best location for your Box and sensors.

To run that kind of process you'll need a LoraWAN network fieldtest (Adeunis tester available in our database).

Sensors configuration good practice :

When configuring a LoRaWAN sensor (uplink), it is important to consider the following aspects :

1. Optimal Uplink Frequency : Take care to adjust the number of uplinks sent per day to strike a balance between conserving battery power and maximizing the potential for connecting a larger number of sensors. By finding the right frequency, you can ensure efficient data transmission while prolonging the battery life of your sensor. Carefully analyze the requirements of your application and strike a suitable balance to achieve the desired performance.
2. Leveraging Redundancy : Whenever possible, make use of redundancy features provided by the LoRaWAN network. Redundancy helps enhance the reliability of data transmission and reception, leading to a more robust and fault-tolerant system. By leveraging redundancy, you not only improve the chances of successful data delivery but also contribute to conserving battery power by reducing the need for retransmissions.
3. Optimizing Spreading Factor : Consider utilizing the SF7 (Spreading Factor 7) as the primary choice for your sensor's data transmission. SF7 offers advantages such as better bandwidth optimization within the LoRaWAN server.

By taking these factors into account during the configuration process, you can fine-tune your LoRaWAN sensor setup for optimal performance, efficient battery usage, and effective utilization of the LoRaWAN network's capabilities.

When sending responses from your application to the sensor (downlink), consider the following recommendations :

Our goal is to maximize the number of Nodes that can be handled per Box. However, due to the limited availability of full-duplex radios, a Box cannot receive transmissions from Nodes (sensors) while it is transmitting. This means that during the 10% of the time when a Box is transmitting, it is unable to receive any data.

To ensure a highly reliable network, it is essential that the Box successfully receives transmissions from all devices. In order to maintain optimal Box availability, we kindly request that you adhere to the following recommendations :

1. Data Rate efficiency : Similar to the uplink, strive for maximum efficiency in the downlink data rate. The efficiency of your uplink transmissions will determine the efficiency of the network's response in the form of downlinks.
2. Minimize Downlink messages: Whenever possible, avoid using downlink messages. If downlink transmission is necessary, keep the payload size small to minimize the impact on the network.
3. Consider the necessity of Confirmed Uplink: Confirmed Uplink is often not essential for most applications. It is advised to design your application to function effectively without the need for confirmations.

By adhering to these recommendations, we aim to establish a network with high reliability and improved performance.

This article is about LoRaWAN message types.

LoRaWan messages can be categorized into two types: uplink and downlink messages, depending on their direction of travel.

Uplink messages

Uplink messages are transmitted by end devices and received by the Network Server, often through multiple gateways. In the case where the uplink message is intended for the Application Server or the Join Server, the Network Server forwards it to the appropriate recipient for further processing.
The LoRaWAN server integrated into Wattsense products demonstrates the capability to simultaneously receive data across 8 channels. In theory, we can represent this capability through the following schematic.

Note : Uplinks are randomly distributed among the 8 communication channels of the Lorawan server.

Downlink messages:

On the other hand, downlink messages are sent by the Network Server to individual end devices. This includes messages initiated by both the Application Server and the Join Server, ensuring targeted communication with specific devices.

Upon receiving a downlink command from the console, the Tower/Bridge (user, PLC, etc.) within the LoRaWAN network will enqueue it into a device-specific queue. The timing of when the downlink command is sent varies depending on the class of the end device:

For Class A devices

The downlink command will be transmitted after the LoRaWAN server receives an uplink message from the sensor. This class follows a scheduled communication model in which downlink messages are transmitted only after an uplink transmission.

Practical case :

In this practical case, we want to control the temperature setpoint of a thermostatic valve that has a data transmission period of every 15 minutes using an on-site controller.

Here is the schematic diagram to follow for high-quality control :

For Class A devices, if you program 2 downlinks one after the other and if the sensor has not sent an uplink (that would have triggered the first downlink). The latest downlink will overwrite the first one.

Here is the resulting diagram :

We have noticed that the 20°C temperature setpoint has been overwritten by the 22°C one. You should therefore schedule your setpoints to be sent after a period of more than 15 minutes to avoid downlink deletion.

In the logs, you'll see a "Downlink Lost" message informing you that a downlink has been deleted.

For Class C devices

The downlink command is sent directly by the LoRaWAN server upon receipt of the command. In this class, downlink messages can be sent at any time, even without waiting for an uplink transmission.

Practical case :

In this case, we want to control a single connected thermostat by modifying its temperature setpoint. This thermostat has a transmission period of every 15 minutes.

Here is the basic diagram to understand when controlling a Class C sensor :

Note that unlike class A, the downlink is sent immediately to the thermostat.

It is important to understand that with the Lorawan protocol, you cannot receive uplinks and send downlinks at the same time. This is why, when using Class C sensors and you want to control multiple devices (for example, multiple thermostats), we add a delay between each of the programmed downlinks. This delay is set to 14 seconds. This allows alternating periods between transmission and reception.

Here is the principle diagram when you send instructions to several class C sensors (in this example the thermostats) via your PLC :

In this case, all the instructions have therefore changed to 20°C and will have taken approximately 14*2s = 28s to be sent.

To avoid creating a queue that grows "infinitely," be sure to wait for the scheduled mass mailing to end before sending a new one. Otherwise, the instructions you send could be sent with a "lag" due to sending too frequently.

If you need any additional information, please contact us here.