Recommendations for Creating a Private LoRaWAN Network
Recent studies show how the implementation of IoT technologies is accelerating in organizations. This trend has been confirmed during these last two years of health crisis. IoT solutions have shown their great potential to improve various aspects such as: predictive maintenance, consumption measurement, security, air quality, geolocation, BMS building management systems (Building Management System), etc.
Within these IoT solutions are LPWAN wireless communication technologies. LoRaWAN is the only one among them that allows the deployment of self-managed networks. This allows sensorization and control initiatives of any type of installation, whether industrial or infrastructure. When it comes to implementing a private LoRaWAN network, using an open source network manager (Network Server) may seem like a good option a priori. But a number of factors must be taken into account in order to obtain satisfactory operation.
Not all Private LoRaWAN Networks are the Same
In this context, there are many organizations that are integrating IoT solutions into their operations. However, at this point, one should not rush to make a decision and opt for solutions that may seem easier to implement and with a lower initial investment. This is the case of open source solutions. They may seem adequate under certain circumstances, but a series of prior considerations must be made regarding the deployment of a private LoRaWAN network.
Before going into the detail of these considerations, let’s look at the different elements that make up a LoRaWAN network. The sensors located in the field collect the data and send it to the gateways. These are connected to a centralized network that includes the LoRaWAN network manager (LoRaWAN Network Server, LNS) and the sensor management service. It is the LNS who performs the integration with the external application that needs the field data.
What are the Criteria to Consider?
In order for a LoRaWAN network to be operational, each of the elements mentioned must meet a series of requirements that condition its correct operation. Today, it is considered key that this type of network is flexible, reliable, easy to use and implement, uniform and secure.
Compatibility with Gateways
Network flexibility is understood as the ability of the solution to adapt. In the case of gateways, it means that their choice must be independent of the LNS. The LNS must be compatible with most manufacturers. This avoids dependencies with a single manufacturer and expands the range of solutions to meet new needs, but also to meet changing conditions such as delivery times or prices.
Robust Solution to Improve Reliability
From a reliability point of view, the main objective is to minimize data loss. In most cases, this data loss occurs when there is a loss of connection to the local network (the network between the gateway and the application), regardless of how short it is. To avoid this, the gateways have to store this data or can switch networks automatically. For example, when the local network goes down, the wireless network can take over if the gateways have a SIM card.
Many projects with private LoRaWAN networks start with pilots where the LNS is embedded in the gateway itself. This type of solution deprives the network of a key functionality. A centralized LNS allows gateways to work together to reduce packet loss through redundancy: sensors can communicate with any gateway registered in the network and covering the area where the sensor is located. With the centralized LNS you don’t have to worry about which sensor is connected to which gateway, this allows you to increase the reliability of the network and simplify its management.
Battery Life
The ADR (Adaptative Data Rate) is a parameter that is basically used to optimize data transmission in order to increase battery life. It is a dynamic response to the variable parameters of an environment-sensitive connection. This optimization can reach values of 20 to 30%.
Simplify Management
The next point to consider is the ease of use and deployment of the LoRaWAN network. This includes several points such as the remote and automatic updating of sensors and gateways, to always have the latest version of the protocol. But also the active monitoring of the correct operation of each of the elements that make up the network.
Simplifying also means having the ability to analyze network coverage (Network Survey) or to analyze in detail the “frames” in case of a communication problem.
Ease of operation is also linked to the uniformity of functionalities so that the deployment is independent of the elements that make up the network. Thus, another factor to take into account is the integration between the physical deployment of the equipment and the connection with the main data services in the cloud of the market, such as Azure, AWS, Watson, etc. This integration must allow the decoding of the data (Payloads) of sensors of all types of manufacturers that in most cases are encrypted with proprietary formats.
Often, a pilot that seems to meet the requirements of the project fails when deployed on a larger scale. There are a whole series of challenges from the development of a pilot to the deployment of a fully functional industrial solution. The large number of sensors and a complex environment for wireless communications require extreme care when designing the network necessary to meet the requirements of availability and reliability.
Do you want to deploy your own LoRaWAN network in your industrial installation or infrastructure? Get in touch with us and we will help you define the most suitable solution for your needs.
