# Research and Design of a Decentralized Edge-Computing-Assisted LoRa Gateway
## 4 Experiments  
### Experimental Setup  
The LoRa gateway was built on an FPGA-based embedded hardware system using the industrially specialized Xilinx Zynq CPU board and Cortex-A9 SoC. With this gear, edge computing is feasible. In the central cloud, our system comprised four LoRa gateways and two network servers. Many customizable client applications were deployed on the server that could make direct connections to the LoRa gateway. The end devices were deployed for experimental testing using the SX1278-based LoRa communication module. The end device can typically connect multiple sensors for data collection and upload the collected data to the LoRa gateway. In Experiment 1 (test join requests from end devices), 100-2200 simulated end devices submitted join requests continually to the LoRa gateway. Each LoRa gateway controlled between 25 and 550 end devices. Each end device operated at random intervals ranging between 10 min and 2 h. If the end device received a join request and accepted the message, the join operation was deemed successful. After 300 s, if no application had been received, the join request failed. The registration messages for end devices are usually very short, and a large number of device accesses can create pressure on the edge computing system in terms of registration information parsing. In Experiment 1, the evaluation metric used to reflect the real-time performance of the gateway during the registration of a large number of devices was the time it takes for the end node to register with the network service. Experiment 2 (test application data upload of end devices) emulated between 100 and 2000 end devices. Each LoRa gateway could support between 25 and 400 end devices. Allsteps for end device assembly were completed. Therefore, the end devices could perform data uploading normally. Each end device was able to select a time interval of 15-20 s for continuous data reporting. The network server sent an ACK to each package to signal that the uplink data were received properly. If the end device did not receive an ACK within 30 s after the upload, the transmission of the application data package was deemed unsuccessful. After the time interval or a failure, the endpoint continued to transmit. A large number of end device data packets were transmitted with a full load (payload 255 bytes), and by adopting the design proposed in this paper, the performance of the edge gateway was fully utilized. Experimental metric 2 utilized two performance indicators: system throughput and CPU utilization. System throughput refers to the number of successfully transmitted data in a unit of time by network devices or ports (the maximum data rate that devices can receive and forward without dropping frames). It is an actual value used to measure network performance. CPU utilization is the percentage of CPU resources occupied by running programs, representing the status of the machine running programs at a specific time. Throughput and CPU utilization at their limits can assess whether the utilization of a LoRa network's overall processing and forwarding capabilities has reached its maximum, and whether the fairness of network transmission is ensured. Experiment 3 (testing the EC-assisted LoRa gateway versus the traditional LoRa gateway) simulated the operation of 100-2200 end devices. During the experiment, four LoRa gateways were deployed to provide data processing services for the end devices. Each LoRa gateway could interact with the end devices in the coverage area and obtain the application information reported by the end devices. Then, a comparative experiment was carried out using the conventional LoRa system technique. In a traditional LoRa gateway system, the JS and NC modules are deployed in a central cloud implementation. As seen in Figure 4, the central cloud must thus handle all application packages. Our comparison demonstrated the enhanced performance of the LoRa gateway with EC-assisted support.