# Empirical Evaluation of TLS-Enhanced MQTT on IoT Devices for V2X Use Cases
## 5 Performance Evaluation
### Symmetric Encryption Evaluation
It is essential to highlight the fact that low- to medium-volume time requirements over WiFi are only marginally higher compared with the payload size difference of 10 times. This, can be leveraged by non-time-critical V2X applications to share extra data with low overhead. Energy consumption follows a similar pattern to the execution time, in accordance with the measured data presented in Table 9. The impact of message packaging selection is represented in the comparison of 1000 \(\times\) 100 B and 1000 \(\times\) 1000 B, where for WiFi, we have 12% and 14.5% increases for Chacha20_Poly1305 and AES_256_GCM, respectively. In \begin{table}
\begin{tabular}{c c c c c c c c} \hline \hline  & & \multicolumn{3}{c}{**Chacha20**} & \multicolumn{3}{c}{**AES-GCM**} \\ \cline{3-8}  & **Role** & **100 KB** & **1 MB** & **100 MB** & **100 KB** & **1 MB** & **100 MB** \\  & & **(1000 \(\times\) 100 B)** & **(1000 \(\times\) 1000 B)** & **(10,000 \(\times\) 10,000 B)** & **(1000 \(\times\) 100 B)** & **(1000 \(\times\) 1000 B)** & **(10,000 \(\times\) 10,000 B)** \\ \hline \multirow{3}{*}{**CETET**} & Publisher & 1386.6 \(\pm\) 9.2 & 1460.4 \(\pm\) 16.1 & 10,071 \(\pm\) 84.7 & 1436.2 \(\pm\) 32.9 & 1504 \(\pm\) 15.5 & 10,170.3 \(\pm\) 95.5 \\  & Subscriber & 1093.1 \(\pm\) 14.3 & 1165.8 \(\pm\) 14.1 & 13,325.3 \(\pm\) 294.7 & 1095.3 \(\pm\) 10.7 & 1176 \(\pm\) 16.6 & 13,333.3 \(\pm\) 349.6 \\  & Broker & 126.4 \(\pm\) 0.3 & 195.2 \(\pm\) 3.9 & 8090.2 \(\pm\) 27.3 & 126.4 \(\pm\) 0.2 & 195.2 \(\pm\) 2 & 8096 \(\pm\) 25 \\ \hline \multirow{3}{*}{**CET**} & Publisher & 1386.6 \(\pm\) 28.2 & 1476 \(\pm\) 17.6 & 10,534.9 \(\pm\) 77.9 & 1470.1 \(\pm\) 13 & 1486.1 \(\pm\) 9.5 & 10,656.2 \(\pm\) 163.4 \\  & Subscriber & 1114.8 \(\pm\) 15.4 & 1194.1 \(\pm\) 13.6 & 13,486 \(\pm\) 64.2 & 1123.9 \(\pm\) 16.7 & 1212.9 \(\pm\) 26.6 & 13,495.3 \(\pm\) 59.9 \\  & Broker & 161.7 \(\pm\) 6.6 & 223.4 \(\pm\) 6.8 & 8092.9 \(\pm\) 20.2 & 161.9 \(\pm\) 4.9 & 225.4 \(\pm\) 6.3 & 8096.5 \(\pm\) 22.8 \\ \hline \hline \end{tabular}
\end{table} 
Table 7: CPU usage (MCycles) during TLS Phase 4 (data encryption): Chacha20 vs. AES-GCM for low- (100 KB), medium- (1 MB), and high-volume (100 MB) payload transmission over both Ethernet and WiFi. \begin{table}
\begin{tabular}{c c c c c c c c} \hline \hline  & & \multicolumn{3}{c}{**ChaCha20**} & \multicolumn{3}{c}{**AES-GCM**} \\ \cline{3-8}  & **Role** & **100 KB** & **1 MB** & **100 MB** & **100 KB** & **1 MB** & **100 MB** \\  & & **(1000 \(\times\) 100 B)** & **(1000 \(\times\) 1000 B)** & **(10,000 \(\times\) 10,000 B)** & **(1000 \(\times\) 100 B)** & **(1000 \(\times\) 100 B)** & **(10,000 \(\times\) 10,000 B)** \\ \hline \a resource-constrained environment, this small-scale message packaging should be avoided, as it is the least cost-effective among all tested. Once more, the broker energy consumption is less than that of the publisher and subscriber, as these consume about 25% more energy  
The maximum RSS values reported in Table 10 indicate only marginal increases from non-TLS to TLS encryption modes. The maximum RSS values of publishers and subscribers increase from 26.1 MB to 27.5 MB for all message sizes and role configurations. The broker maintains a lightweight memory footprint, with RSS increasing from 7.3 MB to 8.5 MB, despite handling both incoming and outgoing encrypted traffic. These findings suggest that while TLS encryption introduces noticeable CPU overhead, its impact on memory consumption remains minimal, reinforcing the suitability of MQTT over TLS for constrained IoT platforms. In IoT-based V2X scenarios where communication speed is critical, measurements on effective throughput (goodput) are valuable. To this end, our experiments include an evaluation of the goodput introduced by symmetric encryption in both client-to-broker and broker-to-client directions, for all (five) message packagings and both Ethernet and WiFi for Chacha20_Poly1305 (Table 11) and AES_256_GCM (Table 12).