Menu
Menu
Menu
Blogpost – Paris, France – 22 April 2022. Read here (in French) the original article by independent analysts.
Before installing an LNS (LoRaWAN Network Server), it is necessary to ask the right questions. While the prospect of an open-source network may seem appealing, the various factors of satisfactory operability are sometimes not all considered. However, it is not recommended to neglect any of the many aspects that shape it.
Recent studies tell us that IoT adoption tends to accelerate in the enterprise. This has been confirmed during the past two years of health crisis. IoT solutions have once again demonstrated their interest with a strong potential to improve these services on many points. This is the case for predictive maintenance, energy sub-metering, security, tracking, air quality, radio extension of factory SCADA, building BMS, etc. The choice of LoRaWAN network remains a key point in the success of an LP-WAN IoT project.
It is thus entirely advisable for manufacturers to take the plunge and integrate an IoT solution into their operations. However, we can only recommend not to rush into this decision, especially, not to go towards the semblance of ease and lower cost that some solutions can offer. This is the case for solutions based on open-source servers. If they are suitable in certain circumstances, it is imperative to consider all aspects of the deployment of a LoRaWAN network. These are numerous.
There are therefore a whole series of questions that need to be asked when setting up a LoRaWAN network. Before that, we can recall the different elements that make it up. The sensors, at the very end of the chain, communicate the information they collect to gateways. These are connected to a centralized network that includes a Join server, a sensor management service and a LoRaWAN Network Server (LNS). This centralized network interfaces with external application servers that route sensor data.
For the LoRaWAN network to be operational, each of the elements mentioned must meet key expectations that condition its proper functioning. Today, the essential notions that these network solutions must integrate are flexibility, reliability, ease of use, uniformity and security.
Flexibility means that the solution must be highly adaptable. This is the case for gateways, which must be agnostic to the choice of LoRaWAN core network. The LNS must be compatible with as many manufacturers as possible. This allows us not to be locked into a relationship with a single manufacturer, even if this may seem more convenient and allow a theoretical time saving. Such openness allows for rapid adaptation to changing conditions such as price, which often cannot be predicted, and to all types of needs (Macro, Nano, Pico, external, internal gateway).
For the LoRaWAN network to be operational, each of the elements mentioned must meet key expectations that condition its proper functioning. Today, the essential notions that these network solutions must integrate are flexibility, reliability, ease of use, uniformity and security.
From the point of view of reliability, the primary goal is to reduce data loss as much as possible. Data loss occurs most of the time when there is a break in the network connection, no matter how short it is. To remedy this, gateways must store data in a queue, or automatically switch between networks. For example, the cellular network can take over when the local network goes down.
Many IoT projects start via LoRAWAN LNS network cores embedded in gateways. This type of topology deprives the network of a key function: “micro diversity”. This essential function of the LoRaWAN MAC layer allows the gateways to work together to reduce packet loss through redundancy, thus increasing network reliability and simplifying network administration. With this type of centralized LNS, you don’t have to worry about which gateway the sensor is connected to when setting up, unlike LNS embedded in gateways…
For critical applications, the LNS must provide redundant hot standby in case of a data center outage.
The ADR, or Adaptive Data Rate, basically optimizes the data transmission rate to play with power consumption and thus increases battery life. It is a dynamic response to the fluctuating parameters of an environment-sensitive connection. But not all algorithmic implementations of ADR in LNS are equal. It can result in a reduction of the battery life of 20 to 30%!
Next comes the simplicity of use, but also of deployment of this LoRaWAN network. This implies various elements such as remote and automatic updating, without on-site intervention, of sensors (FOTA) and gateways, to always be on the latest version of the protocol. But also, active monitoring of the proper functioning of each network component.
Simplifying also means looking at the related tools attached to the LNS. The possibility for example to analyze the coverage of its network (Network Survey) or to analyze the frames in detail in case of radio problems.
A close link between the physical deployment and the connection in the cloud should not be overlooked. A LoRAWAN private network must not only connect to the main clouds on the market, such as Microsoft (Azure), Amazon (AWS), or PTC (ThingWorx). It must also allow decoding and exposing data (Payloads) from all brands of sensors, which are mostly encrypted in a proprietary format, in order to be able to exploit the data in IoT Dashboards and business applications.
This ease of operation goes hand in hand with uniformity of functionality so that deployment is independent of the various elements that make it up, such as gateways. Everything must be able to benefit from universal support.
Finally, in terms of security, we note that companies unfortunately tend to neglect this point. However, the news often reports on attacks and the many vulnerabilities that are exploited, affecting many players, both large and small. This has become even more evident during the current health and geostrategic crisis, in the generalized context of remote work. The advantage of an industrial LoRaWAN is that it recognizes this problem and is already providing concrete solutions.
Choosing an LNS means not neglecting the services that accompany your project. A very important aspect at Actility is the presence of a support offered by professionals listening 24/7 and internationally if necessary and the size of its R&D.
In addition, you should have a proactive interlocutor within the LoRa Alliance, among its many members and that he is active in the technical committees. Actility is a founding & permanent BoD member of LoRa Alliance, chairing the Technical Committee. with multiple WG/TFs; to note, Actility is the member with the most contributions to the standard and first to implement latest standards (Class B, FUOTA, public-private-satellite roaming, hub, etc.) Thus, we can only advise studying the different offers proposed by professionals for the installation of an LNS. Preferably a LoRaWAN network that meets all these criteria.
In a recent webinar, we covered these issues point by point and allow manufacturers to see more clearly in the deployment of an LNS:
How to deploy a reliable network from day one? What are the main caveats and pitfalls? What are the differences between Open Source and professionally supported LNS solutions? The journey from proof of concept to fully functional industrial use case is full of pitfalls. The very high density of sensors and harsh radio environment require extreme care in the network design to meet the stringent requirements for high availability and low packet-error rate.
In this webinar, Actility experts will highlight the critical elements of a LoRaWAN network and provide architecture recommendations as well as detailed checklists to de-risk industrial IoT projects and prevent vendor lock-in.
Often, PoCs which seem to work fine in the lab fail during the scale-up or run phase because the complexity of LoRaWAN ADR, the critical importance of macro-diversity, and the cost of regression testing when upgrading live networks have been overlooked. In this context, the webinar will explain how industrial LPWAN platforms address specifically these issues and help bridge the gap from lab-tests to zero downtime mass upgrades in the field without generating high overhead costs. Such overheads rapidly become prohibitive when trying to build industrial HA and non-regression testing programs on top of simple open-source network servers.
In this video you will also learn about Actility’s platform. ThingPark Enterprise is a LoRaWAN IoT connectivity management platform that helps customers build network infrastructure by managing LoRaWAN gateways, add new LoRaWAN devices, monitor network operations, and control the flow of data to application servers. ThingPark Enterprise is specifically designed for enterprises: it’s simple, scalable and easy way to operate, and offers a unique low power IoT communication infrastructure to enable an infinite number of industrial use cases.
Learn more about the LoRaWAN technology by downloading the Actility “What is LoRaWAN” white paper
