# Empirical Evaluation of TLS-Enhanced MQTT on IoT Devices for V2X Use Cases
## 6 Discussion and Future Work Directions  
The performance evaluation presented in this work provides meaningful insights into how TLS-secured MQTT communication behaves under varying message packaging strategies, encryption algorithms, and network configurations, with direct implications for V2X scenarios. Our results reveal that the system's responsiveness and resource consumption are highly sensitive to the way payloads are structured, particularly in constrained IoT environments. TLS Overhead and Cipher ComparisonRegarding RQ 1, we quantified the resource demands introduced by TLS 1.3 handshake and encrypted data exchange. For the complete TLS handshake (Phases 1-3), we observed increases in CPU usage, execution time, and energy consumption of up to 37%, 23.5%, and 23.7%, respectively, on the publisher side, highlighting the measurable impact of secure communication even in low-data-volume interactions. In Phase 4, ChaCha20. Poly1305 consistently outperformed AES_256_GCM across all metrics, particularly in wireless scenarios where CPU constraints and power efficiency are more profound. This confirms its suitability for resource-constrained IoT deployment with stringent latency requirements. Message Packaging Trade-offsWith respect to RQ 2, we systematically evaluated how the composition of message batches (i.e., number and size of individual messages for a fixed payload) influences performance. We found that reducing the number of messages (e.g., 10 \(\times\) 10,000 B) minimizes per-message overhead and results in lower execution time, latency, and energy usage compared with higher message counts (e.g., 1000 \(\times\) 100 B), where system calls, buffer handling, and acknowledgment overhead accumulate significantly. This effect was amplified in WiFi scenarios, where higher packet frequency increases channel contention and buffer overflows, negatively affecting goodput and reliability. Application-Aware ConfigurationsOur findings address RQ3 by linking performance observations to practical V2X use cases. For time-critical applications like hazard alerts or  
\begin{table}
\begin{tabular}{c c c c c c c} \hline \hline  & **Direction** & \multicolumn{3}{c}{**100 KB**} & \multicolumn{2}{c}{**1 MB**} & \multicolumn{2}{c}{**100 MB**} \\ \cline{3-6}  & **Direction** & **1000 x 100 B** & **100 x 1000 B** & **10 x 10,000 B** & **1000 x 1000 B** & **10,000 x 10,000 B** \\ \hline \multirow{2}{*}{
\begin{tabular}{c} **mini** \\ **mini**  
pedestrian warnings, configurations like 10 \(\times\) 10,000 B optimize for low latency and fast delivery. Conversely, scenarios requiring high-volume data transmission (e.g., over-the-air updates or complex situational analysis) are better served by bulk transmissions with larger payload sizes (e.g., \(10,000\times 10\),000 B), which achieve higher goodput and minimize energy per byte. These insights provide actionable guidance for tailoring communication strategies to the constraints and demands of specific applications. _Comparison with Prior Work._ Our results are consistent with [PERSON] et al. [7], who observed similar performance trends under TLS-secured MQTT; however, our study offers a more comprehensive and realistic evaluation. While [PERSON] et al. conducted their experiments using containerized virtual machines on server-grade hardware, our testbed utilizes physical IoT devices (Raspberry Pi 4_B_), leading to naturally higher resource usage. Moreover, our experiments employ exclusively the more demanding AES_256_GCM cipher instead of AES_128_GCM, which is used by [PERSON] et al., contributing to the observed overhead. Importantly, our work introduces novel insights by benchmarking ChaCha20_Poly1305, integrating energy measurements, and assessing message packaging strategies aligned with standardized V2X formats--a perspective not explored in prior studies. Thus, our findings extend the existing literature by addressing practical deployment considerations in edge environments.