LoRaWAN Gateway: the key element of the network

In other entries on this same blog, we have explained how differential LoRaWAN is with respect to other technologies and the wide range of possibilities it offers in industry, in outdoor equipment, in warehouses, …

In this specific entry, we will talk about the most important element in a LoRaWAN network, the Gateway. For those who do not yet know it, we remind you that a LoRaWAN network is mainly composed of nodes, Gateways and the Network Server.

The function of a Gateway is to generate the LoRaWAN wireless network to provide coverage to the nodes, communicate with the nodes to receive the information they send or to transmit the relevant commands to them and, finally, communicate with the Network Server upstream. For this last step, a TCP/IP communication is already used.

In summary, the Gateway is the equipment capable of integrating the distributed equipment (sensors, actuators, instrumentation, …) with the Network Server that manages the network and sends the information to the higher applications.

While it is true that this architecture is very clear in large LoRaWAN networks, with several Gateways that cover a large area – a city, for example – for private networks with a single Gateway the system may vary. If the network must control a space of hundreds of meters or with a few kilometers between the Gateway and the nodes, a single Gateway may be sufficient to cover the entire network. In these cases, it is possible to set up an architecture where a dedicated Network Server is not necessary, but rather this function is performed by the equipment itself.

It is not common, but there are Gateways capable of fulfilling all the functions that we mentioned, but in turn, have the ability to translate the Payload to a protocol that the applications can already understand.

From our experience, for self-managed private networks, we believe that this architecture is, without a doubt, the most practical. The fact of not needing dedicated software to translate the messages and that the Gateway does it directly, allows us to build a system much more similar to the one we are all used to, where the SCADA or control application is capable of reading and writing using its own communication drivers instead of having to integrate with a third-party API.

In our specific case, our LoRaWAN Gateways are capable of serving the information they acquire from the nodes in MQTT. Why MQTT? Because this protocol is used by both IoT platforms – AWS, Azure IoT Hub, Google IoT Core, … – as well as the most industrial SCADAs and control applications.

Using Gateways with these functionalities allows a much faster deployment of the network since the integration with the rest of the control systems is much more comfortable. Not only that, but all of us who come from the industrial control or infrastructure sector are much more accustomed to this type of hierarchy than to integration via APIs, in short, we know better how to set up this communication and how to use it.

However, it is evident that for more complex networks, where several Gateways are necessary, there is mobility in the nodes, redundancy in communications is required, etc. it will always be necessary a Network Server capable of performing all these functions so that the network works as expected.

On the other hand, if your data application is not capable of acquiring information by MQTT, you can always use tools such as KEPServerEX (link to ) or OPC Router to be able to perform the integration using other protocols such as OPC, REST or through intermediate databases.

Are you interested in setting up a LoRaWAN network capable of communicating with your SCADA or control application directly and without needing intermediate APIs? If you want to use this technology without having to set up a large infrastructure and maintaining the architecture and system hierarchy of your installation, do not hesitate to contact us.