A novel single-channel edge computing LoRa gateway for real-time confirmed messaging

System architecture

Figure 1 illustrates the system architecture, which comprises various components: a mobile application, management platform, server (either cloud-based server or local server), LoRa gateway, and end nodes. Both the mobile application and management platform enable users to operate the end nodes, monitor their status, and receive uplink messages. The server is a pivotal component of this system, which includes a main server, a LoRaWAN server, a message queuing telemetry transport (MQTT)¹⁸ server, a device management server, and a database. It offers functions such as data storage, processing, network services, and security. The server can be deployed either locally or cloud-based. The MQTT protocol is used to connect the server and the gateway.

The LoRa gateway plays a critical role in the architecture, serving as a central hub for data relay, processing, and security. The gateway and server are connected via Ethernet or 5G. A star network¹⁹ topology with advantages such as easy maintainability, high reliability, and scalability is used between the gateways and the end nodes.

End nodes report data to and execute the control commands from the server. These end nodes include, for instance, smart switches, motion infrared sensors, microwave radar sensors, and magnetic sensors. The versatility of the end nodes makes it suitable for a wide range of applications, including smart homes²⁰, building automation²¹, smart agriculture²², smart cities²³, and environmental monitoring²⁴.

Figure 1

System architecture which comprises: a mobile application, a management platform, a server (cloud-based or local), LoRa gateways, and end nodes. Both the mobile application and management platform enable users to operate the end nodes, monitor their status, and receive messages.

Electronics design

Overall design

We considered various factors during the gateway design, including user-friendliness, ease of installation, debugging, and maintenance, low cost, and low confirmed messaging time. Figure 2 illustrates the hardware design of the gateway. We employed a 12–24 V direct current to direct current (DC-to-DC) converter to provide the power for the gateway. The core control unit is the MTK7688²⁵ module, which enables MQTT communication with the server via an Ethernet connection. The serial peripheral interface (SPI)²⁶ is used to communicate with the SX1278²⁷ module, which provides LoRa connections. Furthermore, the gateway sends debugging information through both the serial and Ethernet ports and illustrates 3 statuses via light-emitting diodes (LEDs), which are power supply, online or offline, and packet transmission and reception. The key is designed for resetting the gateway.

MTK7688 module

For the selection of a core control unit, the primary considerations are high clock frequency, adequate memory (i.e., for edge computing), and ease of use. We have selected the MTK7688 module from LILDA Group²⁸, which is cost-effective at approximately $\$$8. Compared to alternatives like the Raspberry Pi²⁹, which retails for $\$$14, the cost is reduced by $\$$6. Figure 3a shows the module. The core processing unit of the MTK7688 module utilizes an MT7688AN controller which integrates a 580 MHz MIPS®24KEc$^{\text{TM}}$ CPU. Its clock signals are produced by an external 40 MHz crystal oscillator which is shown in Fig. 3b. The Nanya³⁰ NT5TU32M16FG-AC³¹ chip provides 64 MB of double data rate 2 (DDR2) flash memory. For nonvolatile memory, we employed a 16 MB flash memory namely MXIC25L112835FM21-10G³² from Huabang³³.

SX1278 module

The SX1278 module from Nanjing Renyu³⁴ enables a single-channel LoRa communication between the gateway and the end nodes, which is illustrated in Fig. 4. Its radio frequency (RF) circuitry is designed to match a 50 $\Omega $ impedance. Table 1 presents the relevant component pricing from Digikey³⁵, revealing that SX1278 is available at a cost of only $\$$1.5, whereas the conventional multi-channel gateway comprises a digital baseband chip (i.e., SX1301 or SX1302³⁶) with a cost of approximately $\$$18. Additionally, the cost of the two pieces of Multi-PHY mode transceiver (i.e. SX1255) is approximately $\$$16. Therefore, the cost of a SX1278-based single-channel gateway is less than one-twentieth of the multi-channel one. Since our novel gateway targets rapid confirmed messaging, in which an ACK is required for each uplink transmission, using the multi-channel gateway will not benefit the network. In addition, we chose to set the spreading factor, and bandwidth of the network to 7 and 500 kHz to attain the highest data rate, so that the confirmed messaging which involves multiple retransmissions can be completed as soon as possible (i.e. the lowest confirmed messaging time). However, boosting the data rate results shortened communication distance. Accordingly, the number of gateways deployed needs to be increased to retain the LoRa signal coverage compared to the conventional long-range multi-channel gateway. As a result, the cost of rapid confirmed messaging gateway should be substantially reduced to be affordable for practical use.

Ethernet

The Ethernet is used as the communication method between the gateway and the server, which is based on Pulse Electronics’s³⁷ H1102NL physical layer (PHY)³⁸ chip complying with the IEEE 802.3 specification³⁹. This PHY chip employs differential signaling⁴⁰ for the transmissions.

LED

In the context of gateway applications, it is essential to employ LED indicators to provide a clear indication of the gateway’s current status which includes the power-on status, connectivity with the cloud-based server (i.e., online or offline), and the transmission and reception of the LoRa packets. Consequently, we have incorporated four LED indicators for these purposes. The arrangement of the LEDs on the PCB is shown in Fig. 5.

The first red LED signifies the power-on state, indicated by a constant illumination of the LED. The second green LED indicates the connectivity status, with the LED blinking and remaining unlit to denote the online, and offline status, respectively. The third green LED is designated for indicating the LoRa transmission and reception status, with one and two blinks, respectively. Lastly, the fourth green LED has been reserved for potential future use.

Printed circuit board design

Figure 6a,b depict the front and back sides of the circuit layout, respectively. To maintain impedance matching in the RF section and support the differential circuitry for the Ethernet, a four-layer printed circuit board (PCB) design was employed. The front and back layers contain the pads and lines that connect the pins between components, while the middle two layers are the power and ground layers.

Functional design

Overall software design

The block diagram of the software design is shown in Fig. 7. We chose the Openwrt-Linux⁴¹ as the operating system for our gateway, and implemented the hardware driver layer for SX1278, Ethernet, LEDs, and UARTs, and middleware components, such as LoRaWAN MAC and application program interface as shown in the figure. Task scheduling for the entire system was accomplished through four processes:

Fork_core processes the application request data and generates responses to the end nodes according to user’s configurations.
Fork_mqtt is used to connect to the server via MQTT.
Fork_lorapkt manages LoRaWAN communication functions with the end nodes.
Fork_dispatch acts as a message router between the MQTT and LoRaWAN, facilitating message transfers.

At the same time, we employed four main threads:

Thread$\_$up processes packets received from the end nodes.
Thread$\_$down handles the downlink data sent from the cloud-based server.
Thread$\_$jit polls for pending downlink packets originated from the cloud-based server and dispatches them to the end nodes.
insert$\_$queue$\_$thread is responsible for managing the incoming server’s data, processing it, and queuing it for distribution to end devices.

The MQTT protocol is used to connect the gateways and the network server due to its advantages of minimal packet overhead, efficient distribution to multiple clients, and reliable message queuing. However, the adoption of MQTT can not expedite the end-to-end delay for the LoRa confirmed messaging since the acknowledgment is still generated in the cloud-based network server, which results a long round trip time (RTT) for each transmission attempt.

Physical layer settings

The settings for the physical layers of the LoRa transceiver are listed in Table 3. Note that we chose the lowest LoRa spreading factor (i.e., 7) and the widest bandwidth (i.e., 500 kHz) to attain the highest data rate. The uplink receiving frequency of the gateway was set to a fixed frequency. On the contrary, the downlink frequency of the gateway was automatically adjusted according to the device address of the end nodes, which differs from the uplink frequency of the gateway. This arrangement prevents the problem of frequency conflict between the simultaneous downlink and uplink when the same one is used.

Table 3 LoRa physical layer settings.

Edge computing: acknowledging design

In LoRa communications, packet losses between end nodes and gateways sometimes occur. Therefore, a well-planned interaction-timing design can significantly enhance the reliability of LoRa communication. Figure 8 illustrates the timing when the gateway acknowledges the end node. The node initiates the transmission and starts a timer (i.e., $T_\mathrm {reTX\_wait\_time}$) after the end of its transmission.

Upon receiving data, the gateway performs the essential data verification checks and generates an ACK within a predefined $t_\mathrm {transition\_{time}}$. Subsequently, the ACK is transmitted to the node. If the node successfully receives the ACK before the $T_\mathrm {reTX\_wait\_time}$ timer expires, the transmission is completed. If not, the end node will start the first retransmission after the expiration of timer $T_\mathrm {reTX\_wait\_time}$. This process is repeated for up to three attempts. Then, the confirmed messaging is completed whether or not the node receives the ACK.

This approach differs from that of conventional LoRaWAN systems, in which the ACK response function is designed within the cloud-based server. In our design, the ACK response of the node occurs at the gateway. This modification reduces LoRa’s confirmed messaging time. In addition, it reduces the computing load and network bandwidth usage on the servers and thus, improves the scalability of the servers. In addition, the standard LoRaWAN ACK packet format is used in our design, which does not carry any payload if the net server do not have data to send to the end node.

Edge computing: gateway registration and replacement method

The use of quick-response (QR) code⁴² offers a quick, convenient, and secure method for integrating devices into IoT, which however, is not adopted by the conventional LoRaWAN. This approach minimized the risk of human error and expedited deployment processes. We designed 6 bytes to indicate the gateway’s identification (ID). An example of the QR code for the gateway ID 9F1000000001 is shown in Fig. 9. The process of gateway registration to the cloud-based network server is illustrated in Fig. 10. Its ID number is inserted into the gateway database in the server as a new device. After that, an associated node list is created and sent to the gateway when the node list is not vacant.

It is conceivable that gateways inevitably experience malfunction or damage during their operational lifespan for various reasons. The simple way to handle this problem is to replace them with new ones. However, replacing the gateway with edge computing is more complicated than a transparent one (i.e., the conventional LoRaWAN gateway). To address this issue, we designed the gateway replacement function which is shown in Fig. 11. To replace an old gateway, first scan its QR code, then scan the new gateway’s, and finally click the ‘Replace’ button on the dedicated mobile application. With these user operations, the old gateway is substituted by the new one in the database of the network server. In addition, to ensure the seamless continuity of all original edge computing functions, the server transfers the node list associated with the old gateway to the new one once it is powered on and online.

Edge computing: node list synchronization

In conventional LoRaWAN, the application server and the network server keep node information (i.e., a node list) while the gateway does not. Thus, the ACK is generated by the NS and disseminated by the gateway which is chosen by the NS. This will cause the end node to wait for the ACK for a long time after sending confirmed data, and the real-time confirmed messaging is not achievable. Thus, we suggest establishing an association between each end node and a chosen gateway by sending the node information to the gateway so that the ACK can be generated by the gateway directly. Such association is created and managed by the user and the list of associated nodes for each gateway is generated and sent by the network server if a gateway requests the list or the list is modified (i.e., the synchronization of node list between gateways and network server). The synchronization procedure that is shown in Fig. 12 is as follows:

Upon connection to the server, the gateway initiates a request to the server for its node list. Subsequently, the server sends the relevant list to the gateway.
In cases where a node (e.g., Node A) is added by the user, the server notifies the gateway, which then adds Node A to the node list.
If the user removes a node (e.g., Node B) in the network server, the server notifies the gateway to perform the same operation. Then, the gateway conducts the removing and reports the result to the server.
When a replacement operation is initiated by the user (e.g., use Node C to replace Node D), the server issues a replacement command to the gateway. After performing the replacement, the gateway will also report the result to the server.

This list synchronization process ensures that each gateway’s end node list is identical to the one on the network server-side.

Edge computing: security mechanisms

Traditional LoRaWAN devices use a unique device identifier (DevEUI) and a pre-shared key (i.e., AppKey) to authenticate themselves to the network. During the initial join process, the device and the network server perform a mutual authentication process, and the session keys (i.e., NwkSKey and AppSKey) are derived⁴³. The NwkSKey is used for securing messages on the network layer, ensuring the integrity and authenticity of the messages exchanged between the devices and the network server, while AppSKey is used for end-to-end encryption of the payload at the application layer. It ensures that the application data remains confidential between the end device and the application server. In addition to the node list, these two keys are also disseminated to the associated edge computing gateway by the NS, so that the traditional security mechanism can be resumed in our proposed method.

Performance evaluation metrics

The LoRa network performance evaluation metrics include the confirmed messaging time, packet reception ratio (PRR), received signal strength indicator (RSSI), and signal-to-noise ratio (SNR). The performance of the network server which is deployed on AliCloud⁴⁴ is evaluated in terms of CPU and memory utilization, network bandwidth, and system load.

Confirmed messaging time

The confirmed messaging time refers to the time interval between an end node sending confirmed data and receiving ACK from the gateway or vice versa. Numerous factors contribute to the confirmed messaging time for our edge computing gateway:

Time required for parsing, checking, and verifying data after reception by gateway.
Time consumed by other processes or threads on the gateway.
Time taken by the gateway to generate the corresponding ACK.
Parsing and verification of data by the node after receiving ACK.
Packet transmission delay depends on the packet length and LoRa physical layer parameters.

PRR

The PRR is the ratio of the total number of acknowledged packets to the total number of transmitted packets. The PRR quantifies the rate of successful packet reception. It is computed as follows:

$$\begin{aligned} PRR = \dfrac{N_{\text{RX}}}{N_{\text{TX}}} \end{aligned}$$

(1)

where $N_\text{TX}$ is the total number of gateway transmissions, and $N_\text{RX}$ is the total number of returned ACKs.

Numerous factors affect the PRR, including communication distance, obstructions, antenna attenuation, transmitting and receiving antenna gain, and LoRa physical layer parameters of both the nodes and gateways.

LoRa RSSI

Equation (2) defines the RSSI⁴⁵, which is a widely used term in various wireless technologies⁴⁶. In our experiments, the RSSI value is read directly from the LoRa chip’s registers.

$$\begin{aligned} RSSI = 10lgP_\text{rx} \end{aligned}$$

(2)

where $P_\text{rx}$ denotes the received signal power in mW.

SNR

By comparing the signal power to the noise power, the SNR calculates the signal quality⁴⁷. An increased SNR indicates a stronger signal, which improves transmission efficiency and signal quality. The SNR in this paper is computed using the following formula:

$$\begin{aligned} \begin{aligned} SNR = 10lg\frac{P_\text{SP}}{P_\text{NP}} = 20lg(\frac{A_\text{SP}}{A_\text{NP}})^2 \end{aligned} \end{aligned}$$

(3)

where $P_\text{SP}$ and $P_\text{NP}$ are the signal and noise powers, respectively. $A_\text{SP}$ denotes the amplitude of a signal in dBm, and $A_\text{NP}$ is the amplitude of noise.

Network server system load

In addition to the mentioned metrics to evaluate the performance of the network server, we also adopted the system load which is defined as the number of processes running on the server, including the number of processes running and waiting to run. System load can reflect how busy the server is. Specifically, the system load is rated in a range of 0 to 4 with the larger number indicating greater server resource usage. Moreover, instead of the instant system load, we focus on the average system load over a certain period, and we chose 3 periods: 1 min, 5 min, and 15 min. Then, the averaged system load denoted by $L_{t,\, p}$ for period p at the time instant t can be computed as follows:

$$\begin{aligned} L_{t,\, p} = \frac{1}{p}\int _{t}^{t+p}rdt \end{aligned}$$

(4)

where r represents the instant rate of the system load.

Reference

Wanda Parisien

Wanda Parisien is a computing expert who navigates the vast landscape of hardware and software. With a focus on computer technology, software development, and industry trends, Wanda delivers informative content, tutorials, and analyses to keep readers updated on the latest in the world of computing.