# A Smart Parking Solution Architecture Based on LoRaWAN and Kubernetes
## 4 Proposed Solution
### Sensing Infrastructure  
As discussed before, sensing infrastructure should be able to communicate over kilometers as smart parking solutions are intended to cover wide areas. In this sense, the usage of LPWAN protocols/technologies such as LoRaWAN which allows to communicate over long-range distances with low power consumption could be suitable. The proposed solution has used LoRaWAN because of its openness which allows to the developer to implement all the components of its architecture which is composed of end-devices, gateway, network server and application server (see Figure 3). As an additional information, it is important to indicate that the proposed architecture is based on the specification 1.0.2 of LoRaWAN. The components within the architecture perform specific tasks. For example, smart parking sensors are in charge of sensing vehicle presence and passing such data to the gateway over LoRaWAN network. The gateway transforms LoRa payloads into TCP/IP packets which are delivered to the network and application servers.  
For the implementation of the proposed solution, we have used sensors manufactured by Libelium which support SigFox and LoRaWAN protocols. These devices use magnetic sensors for detecting the presence of a car and they are IP68 compliant, which means that are dust-resistant and water-resistant (up to 1.5 m deep). Their operation frequency is rated between 863 MHz to 923 MHz which is an unlicensed ISM specter. For this implementation, the US902-918 MHz frequency was selected as recommended by the manufacturer according to the region of implementation. It is also important to indicate that these sensors hold a power autonomy of 4-6 years according to the manufacturer's specifications.  
On the other hand, the proposed solution used the MultiTech Conduit IP67 Base Station for implementing the LoRaWAN Gateway. It supports public and private LoRa network deployments working at 868 MHz and 915 MHz ISM bands, and it is designed for outdoor deployments. The main task performed by this device is to convert Radio Frequency (LoRa) packets into IP packets and vice versa; in other word, this device routes the uplink and downlink packets. An uplink packet is a packet sent from to the sensor to an application whilst a downlink packet is packet sent from an application to a sensor. The Gateway used in the proposed solution has a network server embedded. This server is in charge of routing uplink packets to the respective application server or route downlink packets  
Figure 3: Smart parking sensing infrastructure based on LoRaWAN.  
to a particular sensor through the gateway. In addition, the Conduit Gateway is able to provide an application server to forward packets via MQTT protocol to a third-party application server.  
Security within the Sensing Infrastructure  
In terms of security, LoRaWAN supports two joining methods. Activation by Personalization (ABP) and Over The Air Activation (OTAA). For the present solution, the OTAA method was configured in the end-nodes, network and application server. For OTAA mode, the following parameters and keys have to be pre-configured and shared: **DeveUI (Device Unique Identifier), AppEUI (Application Unique Identifier)** and **AppKey (Application Root Key)**. The LoRaWAN specification 1.0.2 specifies that the **AppKey** is an AES-128 bits key. This key is used to derive two other keys used to cipher the payloads. Those keys are AES-128 bits keys and are **Network Session Key (NwkSKey)** and **Application Session Key (AppSKey)**. Each key is used by each server so that the **Network Session Key (NwkSKey)** is used between the end-device and the network server to validate the integrity of the messages (MIC fields). The **AppSKey** is used between the end-device and the application server to encrypt the payloads providing confidentiality [26].