# Empirical Evaluation of TLS-Enhanced MQTT on IoT Devices for V2X Use Cases
## 5 Performance Evaluation
### Symmetric Encryption Evaluation
For the broker, \(1000\times 100\) B is more than four and seven times slower than \(100\times 1000\) B and \(10\times 10\),000 B, respectively. While \(100\times 1000\) B is only about 1.7 times slower than \(10\times 10\),000 B. The differences between message packaging execution times, while being greater, follow the same pattern in the WiFi setup. An interesting observation is that depending on the message packaging, the wireless setup is progressively faster in relation to the wired setup, as the message size grows bigger and the number of messages diminishes. For instance, \(1000\times 100\) B WiFi is about 8.2 times slower than Ethernet for the publisher and subscriber in both Chacha20_Poly1305 and AES_256_GCM, while for the broker, this falls to 7.7. Correspondingly, for \(100\times 1000\) B, the wireless setup is 5.2 times slower for Chacha20_Poly1305 and 5.4 times slower for AES_256_GCM for the publisher and subscriber, while it is 4.1 and 4.3 times slower for the broker. The lowest difference occurs in the \(10\times 10\),000 B message packaging, where the publisher and subscriber are approximately 2.5 times slower for both algorithms. For the broker, this drops to 1.8 times, with AES_256_GCM being a bit slower than Chacha20_Poly1305. An additional piece of information extracted from the execution time tables is the fact that the execution time of the broker corresponds to the end-to-end latency, as it covers the time-frame from payload publication to reception. This constitutes a fundamental metric for assessing responsiveness in V2X scenarios. \begin{table}
\begin{tabular}{l l c c c c c} \hline \hline  & **Role** & \multicolumn{3}{c}{**ChaCha20**} & \multicolumn{3}{c}{**AES-GCM**} \\ \cline{3-7}  & & **1000 x 100 B** & **100 x 1000 B** & **100 x 1000 B** & **100 x 1000 B** & **100 x 1000 B** & **10 x 1000 B** \\ \hline \multirow{3}{*}{
\begin{tabular}{l} **mini** \\ **mini**  
In addition to the execution time, we calculated the energy consumption requirements for all experimental combinations of symmetric encryption, as it is depicted in Table 6. The power measured on the publisher and subscriber nodes is similar and higher than the one found for the broker. Although the trends follow those of execution time, we observe that the broker consumes less energy than the publisher and subscriber nodes. This is counter-intuitive considering that its execution time is higher than that of both nodes. The reason is that the power measured on the publisher and subscriber is about 26% higher than the broker's. This highlights the overhead introduced by the use of Python implementations compared with C. These findings can serve as a reference point for future work, since full C-based implementation would deserve further investigation. Overall, the CPU cycle usage, execution time, and energy consumption of Chacha20 remain lower than those of AES_256_GCM for every system role and every message size. The maximum performance differences occur in the wireless setup. When processing \(1000\times 100\) B messages, the AES_256_GCM publisher requires 6% more CPU cycles. For the \(100\times 1000\) B message packaging, we measure, for the subscriber, the largest overhead of 5.2% in execution time and energy consumption. Additionally, our results show that the overhead for both ciphers decreases significantly when a larger message packaging is used, highlighting the importance of message pattern selection in a resource-constrained and time-dependent V2X environment. The comparison between CPU cycle usage for low- (100 KB), medium- (1 MB), and large-volume (100 MB) transmission payload in Table 7 highlights how encryption overhead scales with the increase in data volume. The results reveal a non-linear growth in CPU usage. Indicatively, in Chacha20_Poly1305, from the low to medium scales, we have increases of 5.3% and 6.6% for Ethernet and 6.4% and 7.1% for WiFi for the publisher and