# A Smart Parking Solution Architecture Based on LoRaWAN and Kubernetes
## 6 Discussion  
People looking for a parking spot is a source of traffic and air pollution, because of the additional time and fuel people must spend until they find an available spot. A solution for this problem is a smart parking system that comprises deploying sensors on parking lots, processing the retrieved data and making the information available for people looking for a parking spot. Several smart parking solutions are proposed with completely different architectures and technologies. With the aim of improving the existing solutions, a new architecture is proposed using state of the art technologies and solve the parking search problem. The solution proposed in this paper manages information through a message broker, this is a crucial part of the infrastructure since it reduces the processing load to the rest of the system. Another advantage of using a message broker is sending only the necessary information to the rest of the system. This prevents the inclusion of unnecessary data generated by most communication protocols. In this solution it is only required to know whether a slot is empty or occupied. From the results obtained in the previous section, graphs have been generated from the previous results that show the behavior of our components based on Kubernetes vs. deployments in VMs. These tables show the maximum, average and minimum times obtained during the test rounds. First of all, the entry point of our proposed architecture is the Mosquitto Server. This component is in charge of collecting payloads received from the gateway. From the test performed, we figured out that this particular component could worked very similar on both deployment scenarios. Mosquitto is 1 ms in average slower in the Kubernetes deployment; however, this is not as significant as expected since it represents 1% approximately. Anyhow, this component could be tuned up to improve the response times and probably that time could be reduced. In the proposed scenario this component showed a good performance for being the entry point of the data. The results summarized for this component are shown in Figure 15.  
Figure 15: Mosquitto Kubernetes vs. virtual machine (VM) summarized times. Another important component of the backend infrastructure is the Rabbit MQ server. Their main tasks are to collect raw payloads, enrich them and let them ready to be stored in the NoSQL repository. From the results obtained (see Figure 16), it could be clearly seen that the component in our approach has a considerable better performance than the approach based on VM deployment. The inclusion of this component in Kubernetes environment has shown that our approach is in average approximately 22% faster than the VM approach. Considering that this component will have to process data several times, it is important to have good response times to prevent delays in the delivery of information. These results show that Rabbit MQ performs much better in this environment in spite of having less hardware resources than a virtual machine. Therefore, the proposed approach improves the performance of the system. Finally, the last component of our backend infrastructure is the NoSQL repository which will store all the enriched payloads delivered by Rabbit MQ. From the results shown in Figure 17, it could be seen that the deployment based on Kubernetes if faster in terms of response time, it is in average 10.5% better than the VM approach. Considering that the repository will have to provide and store information at the same time, the obtained response time is very adequate and would help to have a better performance in general. Anyhow, the times obtained within the VM approach are not bad at all and could work for a basic implementation. However, the approach proposed in this architecture could work for medium or complex systems. The use of Kubernetes, has helped to resource the amount of resources required to deploy an instance of a particular component.