# Empirical Evaluation of TLS-Enhanced MQTT on IoT Devices for V2X Use Cases
## 5 Performance Evaluation
### TLS Handshake Evaluation  
The TLS handshake consists of three steps that work together to establish secure parameters between the clients and the broker. The measurements of connection costs, in million CPU cycles for each phase, appear in Table 2, where key exchange (Phase 1), server authentication (Phase 2) and client authentication (Phase 3) are compared to a baseline without TLS. The no-TLS connection shows minimal CPU overhead, averaging 321 Mcycles for the publisher, 362 Mcycles for the subscriber, and 19 Mcycles for the broker. The publisher experiences an 18.2% increase to 379.3 Mcycles when ECDHE using curve 25519 (Phase 1) is enabled, and the subscriber reaches 411.3 Mcycles (\(+\)13.6%). The key exchange phase has minimal impact on the broker, who remains at approximately 19.77 Mcycles. The addition of server-side certificate validation in Phase 2 leads to a small increase in overhead over the first phase, which causes the publisher to reach 381.8 Mcycles and the subscriber 422.9 Mcycles. This shows the minimal additional cost that ECC-based authentication adds to the IoT devices. The broker's latency stays consistent, which confirms its lightweight nature during the handshake. This process becomes the most resource-demanding when we activate mutual authentication, i.e., Phase 3, where the client-side certificate is introduced. The publisher's measurements increase to 439.6 Mcycles, which represents a 37% increase from the baseline and a 15.1% increase from server-only authentication. The subscriber requires 426 Mcycles to complete the handshake, which represent a 17.7% increase compared with the no-TLS scenario. The broker operates at 20.2 Mcycles, because it runs the Mosquito service, which is a lightweight, event-driven \(C\) application optimized for minimal resource usage. In contrast, the publisher and subscriber execute Python scripts that use higher-level MQTT libraries, with dynamic memory management, interpreter overhead, and extensive I/O operations. The CPU cycle counts remain high, and memory usage remains elevated, which are reflected further ahead by the maximum RSS values. Python's runtime environment resource intensity through garbage collection, message queue buffering, and dynamic memory management are reflected by the extensive difference in hardware overhead that the broker has compared with the publisher and subscriber. The TLS handshake stages produce measurable overhead in execution time and energy consumption compared with baseline (no-TLS) communication, which affects the publisher, subscriber, and broker roles differently. The publisher execution time grows from 0.234 s (no-TLS) to 0.248 s (\(+\)6%) during ECDHE key exchange and reaches 0.255 s (\(+\)9%) in Ed25519 server authentication before maximizing at 0.289 s (\(+\)23.5%) during client authentication. The energy consumption increases from 0.554 J to 0.588 J (\(+\)6.1%), 0.604 J (\(+\)9%), and 0.685 J (\(+\)23.7%) for each TLS phase, respectively. The execution time of the subscriber increases from 0.267 s to 0.286 s (\(+\)7.1%), and energy usage increases from 0.633 J to 0.678 J (\(+\)7.1%) during the complete TLS handshake process. The broker shows minimal overhead, with execution time increasing by only 2.5% from 0.0118 s to 0.0121 s and energy consumption growing by 2.7% from 0.0222 J to 0.0228 J. The TLS phases, specifically client authentication,