# Rapidly Deployable IoT Architecture with Data Security: Implementation and Experimental Evaluation
## 5 Results and Discussion
This clearly demonstrates that light weight encryption algorithms are much more practical in 8-bit microprocessor based IoT applications. As seen from Tables 4 and 5, XTEA requires less code space and RAM than AES SW and is almost on par with AES HW in terms of execution time and energy. While it is clear from the evaluations that AES HW was most efficient, majority 8-bit microcontrollers that are implemented in low-power IoT applications do not have this peripheral feature. As timing and energy performance of XTEA is close to that of hardware accelerated AES, it would be practical to implement XTEA on resource constraint IoT systems, with the understanding that data is encrypted at a basic level unlike with the AES algorithm. Figure 12(a),b presents the comparison of AES implemented in 32-bit MCU with a hardware accelerator and XTEA implemented on an 8-bit microcontroller. Although the XTEA took longer to execute and as a result spent more energy, it is very close to the execution time and consumed energy by the 32-bit MCU while running hardware accelerated AES. Therefore, AES-256 is suitable for applications that handle very sensitive data and the need for security is highly critical. AES-256 can be  
Figure 11. Comparative metrics for a 32-bit MCU: (**a**) Execution time; (**b**) Energy consumption. Figure 12. Comparative metrics for an 8-bit MCU: (**a**) Execution time; (**b**) Energy consumption. employed in devices that have hardware accelerators or memory large enough so that the software implementation leaves enough room for the application firmware. Optimizing the security required by a specific IoT application within constrained resources is a challenge as one needs to consider the temporal relevance of the data being protected for the encryption algorithm to be feasible in an application. After obtaining insight from the performance evaluation of encryption algorithms, their impact on performance of three applications in Section 4 was tested as in Table 6. Due to security risks involved when raw data is transmitted from the wireless transceiver layer to the internet gateway layer, the data needs to be encrypted prior to being transmitted to the wireless transceiver. This ensures that privacy and security are not sacrificed even if the wireless transceiver does not have any built-in security features. Continuing with the modular architecture of the LiB system, security was added by encrypting the sensor data with XTEA and AES algorithms. Comparisons in Table 6 indicate a very small increase in energy consumption as each byte read from the sensors is encrypted and transmitted to the central gateway, which then submits the data to the cloud services. Although the energy consumption has not been affected significantly by the addition of encryption, the delay and overhead in data introduced during the encryption stage results in additional energy consumption and can deplete batteries sooner than expected. Software implementation of AES-256 consumed the most energy, followed by XTEA, in occupancy monitoring LiB and indoor environmental LiB. Finally, the hardware accelerated AES-256 consumed the least energy as seen from the data obtained from fall detection LiB. Figure 14 depicts the average energy distribution graph for the three IoT applications. The energy distribution graph spans from data collection from the sensor, data interpretation and encryption at the microcontroller, sending the data packet through the wireless transceiver to the gateway, waiting for an acknowledgement receipt, and going to sleep. It is evident that most energy is consumed during transmission and acknowledgement of receipt from the internet gateway. Adding data encryption