Empirical Evaluation of TLS-Enhanced MQTT on IoT Devices for V2X Use Cases

Abstract

The rapid growth of Internet of Things (IoT) deployment has led to an unprecedented volume of interconnected, resource-constrained devices. Securing their communication is essential, especially in vehicular environments, where sensitive data exchange requires robust authentication, integrity, and confidentiality guarantees. In this paper, we present an empirical evaluation of TLS (Transport Layer Security)-enhanced MQTT (Message Queuing Telemetry Transport) on low-cost, quad-core Cortex-A72 ARMv8 boards, specifically the Raspberry Pi 4B, commonly used as prototyping platforms for On-Board Units (OBUs) and Road-Side Units (RSUs). Three MQTT entities, namely, the broker, the publisher, and the subscriber, are deployed, utilizing Elliptic Curve Cryptography (ECC) for key exchange and authentication and employing the AES_256_GCM and ChaCha20_Poly1305 ciphers for confidentiality via appropriately selected libraries. We quantify resource consumption in terms of CPU utilization, execution time, energy usage, memory footprint, and goodput across TLS phases, cipher suites, message packaging strategies, and both Ethernet and WiFi interfaces. Our results show that (i) TLS 1.3-enhanced MQTT is feasible on Raspberry Pi 4B devices, though it introduces non-negligible resource overheads; (ii) batching messages into fewer, larger packets reduces transmission cost and latency; and (iii) ChaCha20_Poly1305 outperforms AES_256_GCM, particularly in wireless scenarios, making it the preferred choice for resource- and latency-sensitive V2X applications. These findings provide actionable recommendations for deploying secure MQTT communication on an IoT platform.

1. Introduction

The Internet of Things (IoT) has grown rapidly in various sectors, including smart healthcare, precision agriculture, and Vehicle-to-Everything (V2X) communication, resulting in a sharp increase in the number of interconnected devices. A 2023 study estimated that IoT systems would have transmitted approximately 79.4 ZB of sensitive data over the following five years [1]. However, this scale also expands the potential attack surface, introducing new vulnerabilities that must be addressed.

The need for security in IoT-based systems is particularly essential in smart vehicular ecosystems, where vehicles continuously exchange sensitive data with other vehicles, infrastructure elements such as Road-Side Units (RSUs), pedestrians, and cloud services. In such a context, the establishment of well-defined security specifications and the satisfaction of authentication, integrity, and confidentiality are critical to the development of real-world applications. For example, in scenarios involving hazard alerts notifications, synchronized (platooned) driving, and dissemination of information, security mechanisms and cryptographic primitives can ensure that only authorized entities can transmit messages (authentication) and that messages remain unmodified (integrity) while sensitive information stays shielded from unauthorized entities (confidentiality). These requirements highlight the need for security solutions that can be deployed in resource-constrained IoT environments, particularly within V2X communications.

At the application layer of the IoT, lightweight messaging protocols such as MQTT (Message Queuing Telemetry Transport), CoAP (Constrained Application Protocol), and MQTT-SN (MQTT for Sensor Networks) have gained significant adoption in resource-constrained environments. Among these, MQTT is particularly favored for its efficiency, scalability, and minimal footprint [2]. Unlike CoAP, which operates over UDP (User Datagram Protocol) in a request–response model, MQTT leverages TCP (Transmission Control Protocol) and allows for asynchronous, decoupled interactions between publishers, brokers, and subscribers [3], a design that is particularly well suited to dynamic V2X environments, where network stability varies over time.

A notable advantage of MQTT is its support for three levels of Quality of Service (QoS): QoS 0 (at most once delivery), QoS 1 (at least once delivery), and QoS 2 (exactly once delivery) [4,5]. These QoS levels offer tunable trade-offs among latency, bandwidth usage, and delivery reliability, allowing applications to tailor their communication strategy based on message criticality. For example, routine telemetry or sensor data may use QoS 0 to minimize overhead, while mission-critical messages related to safety or coordination between vehicles may require the higher guarantees provided by QoS 1 or QoS 2. This flexibility is essential in V2X systems, where communication reliability requirements vary across message types.

Several empirical studies further support the suitability of MQTT for secure and constrained deployment. Thangavel et al. [5] compared MQTT and CoAP and observed that MQTT messages experience lower delays compared with CoAP messages when the packet loss rate is low, while when the message size is large and the packet loss rate is high, MQTT generates less overhead compared with CoAP, as TCP retransmits only the lost segments rather than the entire message. Moreover, Seoane et al. [4] examined both protocols under secure configurations (TLS for MQTT and DTLS for CoAP) and concluded that MQTT achieves lower message latency and more reliable delivery under wireless conditions. According to Çorak et al. [6], MQTT creates packets faster, and its transmission time is shorter compared with CoAP.

Building on this foundation and considering the computational limitations of IoT platforms, our work focuses on the secure deployment of MQTT using Transport Layer Security (TLS). In the bibliography, Dimov et al. [7] evaluated MQTT over TLS using server nodes that host virtual machines (VMs). Within these VMs, they deployed MQTT entities: the broker, coordinating message exchange; the publisher, publishing messages to specific topics; and the subscriber, receiving messages from subscribed topics. Their objective was to measure resource consumption on different TLS cipher suites offering 128-bit security. Inspired by their study, our current work moves beyond virtualization to implement TLS-based MQTT communication and evaluate its performance on physical IoT hardware. Testing with real IoT devices is motivated by the recognition that simulation and analytical modeling are inherently limited in capturing real-world physical characteristics and network dynamics [8]. Recent works highlight that the deployment of experimental IoT setups using actual devices and real data traffic not only increases the realism of the testing environment but also enhances the credibility and repeatability of results, making it a widely accepted research practice to validate IoT protocols and systems [8,9].

In particular, in our experimental setup, all the main MQTT entities i.e., the broker, the publisher, and the subscriber, are deployed on quad-core Cortex-A72 ARMv8 boards, specifically the Raspberry Pi 4B platform, as illustrated in Figure 1. The Raspberry Pi 4B is a lightweight, low-cost IoT platform whose processing capabilities have been shown to be representative of the hardware commonly used in real-world On-Board Units (OBUs) and Road-Side Units (RSUs) for V2X deployment. Indicatively, recent work by Farina et al. [10] demonstrates that Raspberry Pi devices can effectively serve as the computational core for Cooperative-Intelligent Transport System (C-ITS) stations, validating their suitability for both prototyping and operational use in real vehicular environments. However, their constrained resources necessitate a careful examination of how TLS-enhanced protocols perform on them. Regarding TLS cipher suites, we employ Elliptic Curve Diffie–Hellman Ephemeral (ECDHE) using curve 25519 for key exchange and the Edwards Digital Signature Algorithm $Ed25519$ for server–client authentication i.e., the TLS authentication mechanism over the MQTT protocol. For encryption, we use the symmetric ciphers AES_256_GCM and Chacha20_Poly1305, chosen for their strong security guarantees, performance efficiency, and quantum-resistant properties [11], laying the groundwork for future all-quantum-resistant MQTT deployment. Along these lines, we advocate that such an architecture can support V2X use cases such as road hazard alerting, platooning control, and secure dissemination of traffic information.

Our objective is to address three main research questions: Feasibility of Secure MQTT (RQ 1): Can constrained IoT devices, such as Raspberry Pi 4B boards, running MQTT with QoS 1, effectively support TLS 1.3 security without compromising performance under realistic V2X message workloads? Resource-–Payload Trade–Offs (RQ 2): How do different message packaging strategies (e.g., number and size of messages) and network interfaces (Ethernet and WiFi) affect resource requirements including CPU cycles, latency, energy consumption, and goodput during TLS-secured MQTT communication? Cipher Suite Performance (RQ 3): What are the real-world performance differences between ChaCha20_Poly1305 and AES_256_GCM on ARMv8-based IoT hardware, and which cipher is better suited for resource-constrained V2X and IoT environments in terms of end-to-end latency, execution time, and energy efficiency?

The contribution of this paper can be summarized as follows:

• End-to-end implementation and evaluation on physical IoT hardware: We deploy all MQTT roles, i.e., broker, publisher, and subscriber, on separate Raspberry Pi 4B boards, leveraging Paho-MQTT, Mosquitto, and OpenSSL for TLS 1.3. This provides an empirical edge-device testbed, moving beyond prior VM- or simulation-based studies and enabling direct measurement of resource demands under realistic hardware constraints.
• Comprehensive profiling of TLS-secured MQTT: We systematically benchmark the impact of TLS 1.3 on MQTT performance, quantifying CPU cycles, execution time, energy consumption, memory usage, and goodput for each MQTT role and each phase of the TLS protocol, over both Ethernet and WiFi. We provide a direct, side-by-side comparison of the ChaCha20_Poly1305 and AES_256_GCM cipher suites, highlighting their suitability for constrained V2X and IoT deployment.
• Standard-driven analysis of message packaging strategies: We evaluate the effect of five distinct message size/count configurations, mapped to V2X-relevant standards, on system performance and resource consumption. This analysis provides actionable insights into the trade-offs among batching, latency, goodput, and energy efficiency, guiding application-specific protocol configuration.
• Empirical foundation for real-world deployment: Our results synthesize practical recommendations for selecting secure communication parameters, optimizing for both performance and energy efficiency in real-world, resource-constrained vehicular and IoT environments.

The remainder of the paper is organized as follows: Section 2 reviews related work, while Section 3 provides a concise overview of the MQTT protocol and highlights representative V2X use cases that motivate the need for robust security. Section 4 details our system implementation and experimental methodology. Section 5 presents and analyzes the results of our performance evaluation. Section 6 synthesizes the key findings, discusses their implications, and outlines future work directions. Finally, Section 7 offers concluding remarks.

2. Related Work

2.1. Lightweight Cryptographic Protocols and IoT

A substantial body of research has addressed security and privacy challenges in the IoT, with a particular focus on the feasibility of lightweight cryptographic primitives. Rana et al. [12] recommend Elliptic Curve Cryptography (ECC) and symmetric ciphers as suitable solutions for resource-constrained IoT networks. In line with this, our work employs ECC for key exchange and symmetric cryptography for data encryption between MQTT entities. However, the study does not integrate or analyze the role of application-layer protocols such as MQTT or CoAP. Thabit et al. [13] compare classic algorithms (e.g., RSA, AES, and Triple DES), but their focus remains on cryptographic performance, without reference to communication protocols. In contrast, our study couples lightweight cryptographic mechanisms with a specific application-layer communication protocol.

Other works, such as Mandal et al. [14], examine the practicality of public-key cryptography in Wireless Sensor Networks (WSNs), while Ambrosin et al. [15] evaluate Attribute-Based Encryption (ABE) for IoT access control. Furthermore, our earlier works [16,17] explore certificateless Identity-Based Cryptography (IBC) in embedded deployment. Nevertheless, all these contributions overlook the integration of cryptographic schemes within secure IoT messaging protocols. Addressing this gap, our work evaluates TLS-secured MQTT, experimentally characterizing the cost of integrating standard TLS 1.3 into real IoT platforms, such as Raspberry Pi 4B boards.

2.2. Lightweight IoT Protocols and V2X

At the application layer, CoAP and MQTT remain the most prevalent protocols for IoT communication due to their lightweight architecture [2,18,19]. CoAP, following a RESTful request–response model and operating over UDP, is designed for environments demanding low power consumption and reduced latency. MQTT, by contrast, uses a brokered publish/subscribe model over TCP/IP, which naturally supports asynchronous and decoupled communication.

Table 1. Comparison of CoAP and MQTT.

	CoAP	MQTT
Delay reduction	✓	✕
Minimized power consumption	✓	✕
Higher sleep time	✓	✕
Reliability	✕	✓
QoS flexibility	✕	✓
Congestion control	✕	✓
Client simplicity	✕	✓

summarizes key differences, showing that MQTT natively offers features such as reliability, Quality of Service (QoS) control, and decoupling between senders and receivers that counterbalance the advantages of CoAP [2]. Furthermore, its ability to handle larger payloads makes it highly suitable for dynamic vehicular networks, where complex or aggregated data need to be exchanged reliably.

The literature confirms the suitability of MQTT across various domains. De Oliveira et al. [20] analyze broker performance on Raspberry Pi in smart city contexts, but their subscriber is a standard PC. Ebleme et al. [21] conduct performance testing on constrained nodes but use a powerful broker machine (i7 computer with 2.4 GHz processor and 8 GB RAM). Similarly, Katsikeas et al. [22] evaluate MQTT in industrial IoT, running brokers in virtual machine (VM) environments. In contrast, our setup uses three Raspberry Pi 4 B boards as publisher, broker, and subscriber, representing full IoT deployment on uniform, mid-class hardware. Michaelides et al. [23] explore security extensions such as Authentication and Authorization in Constrained Environments (ACE), showing feasibility on moderately constrained devices. However, these rely on authorization servers that do not reflect resource-constrained computing settings. Similarly, Ferrari et al. [24] highlight how MQTT can support low-latency services within Industry 4.0 settings through its lightweight design. However, the authors use Cloud Servers, which are powerful in nature. In our work, we examine the use of MQTT in mid-power devices, such as Raspberry Pi 4B, covering security issues of TLS, in full IoT deployment, where all the participants of the MQTT protocol are instances of IoT devices.

Yadav [25] demonstrates that broker-based MQTT can lower end-to-end latency and improve horizontal scalability in connected vehicles, while Reiher et al. [26] present a generic MQTT interface that streams LiDAR detection from vehicles with sub-millisecond delays over 5G links. Both studies confirm MQTT’s performance benefits for V2X, yet neither considers the confidentiality or authenticity of safety-critical payloads. Gupta and Nayak [27] take a first step toward secure messaging by proposing encrypted and authenticated MQTT dissemination of emergency alerts in Cellular V2X (C-V2X) networks, but they leave open the question of how such security measures affect resource-constrained vehicular hardware.

More recent works further underscore MQTT’s versatility in vehicular contexts. Chen et al. [28] introduce the MIN-MQTT framework, which leverages network identifiers to enhance packet forwarding and mobility support in vehicular networks, adding data integrity through signature verification, whereas Raslan et al. [29] deploy an MQTT broker within an Advanced Driver Assistance System (ADAS) to enable real-time collision avoidance. Viterbo et al. [30] and Oliva et al. [31] employ MQTT to protect vulnerable road users and manage intelligent intersections, respectively, both relying on road-side infrastructure and multiple high-end nodes. AJ and Kaythri [32] couple MQTT with the lightweight cipher ASCON for secure fleet coordination. These architectures typically assume powerful brokers or dense RSU deployment; by contrast, our study evaluates TLS 1.3-secured MQTT on three homogeneous Raspberry Pi 4 devices, offering an end-to-end assessment of latency, goodput, and resource requirements when all MQTT entities run on mid-power IoT hardware—an arrangement directly applicable to infrastructure-light V2X scenarios.

2.3. TLS-Secured MQTT and IoT

Dimov et al. [7] benchmark TLS-secured MQTT using virtualized nodes and report comparative costs across cipher suites. However, their results apply primarily to simulated environments. Our work builds upon this by experimentally deploying TLS 1.3-secured MQTT on real devices, capturing power and performance metrics in a physical setting reflective of real-world embedded deployment.

In addressing both application-layer communication and security under resource constraints, our work fills a critical area in the existing literature. It builds upon prior studies on lightweight cryptography and MQTT-based V2X systems while also integrating an empirical evaluation of TLS overhead on real IoT devices. By combining standard-compliant security mechanisms with practical deployment scenarios, our study responds directly to the call for updated, rigorous, and grounded assessments of secure communication in constrained V2X environments.

3. MQTT and V2X Use Cases

MQTT is a lightweight publish/subscribe application-layer protocol widely adopted in vehicular networks and the broader IoT landscape, due to its efficiency in wireless environments with limited bandwidth, high latency, or unreliable links. Operating over TCP/IP (Transmission Control Protocol/Internet Protocol) and supporting TLS and MQTT ensures secure, connection-oriented message delivery. Its support for encryption, authentication, and configurable QoS levels makes it well suited for V2X scenarios, where data integrity, confidentiality, and reliability are essential. In this context, MQTT messages can include vehicle status updates (e.g., location, speed, and direction), hazard alerts (e.g., accident or obstacle warnings), or traffic light states broadcast by infrastructure units.

Designed for machine-to-machine (M2M) communication, the protocol defines three core roles, as shown in Figure 2: the publisher, the subscriber and the broker. The publisher generates messages tagged with specific topics and transmits them to the broker. For example, an ambulance serving as a publisher can transmit real-time data such as speed, location, or emergency alerts. Subscribers express their interest in one or more topics and receive messages matching their subscription criteria. There is no direct communication between subscribers and publishers, but instead they rely on the broker to forward relevant messages. For example, nearby vehicles or pedestrians may subscribe to receive hazard notifications. The broker acts as the central coordinator, receiving messages from publishers, filtering them by topic, and forwarding them to matching subscribers. In smart V2X environments, the publisher and subscriber roles can be adopted by vehicles, infrastructure components (e.g., traffic lights), or other IoT devices, while the broker is typically but not exclusively an RSU.

Vehicle to Everything encompasses subdomains such as Vehicle to Infrastructure (V2I), Vehicle to Vehicle (V2V), Vehicle to Network (V2N), and Vehicle to Pedestrian (V2P). In V2I use cases, MQTT enables low-latency, topic-based publish/subscribe communication between vehicles and infrastructure nodes. Infrastructure elements, such as traffic lights and RSUs, typically act as publishers, broadcasting data such as Signal Phase and Timing (SPaT), while vehicles operate as subscribers, receiving this information via an MQTT broker that orchestrates message dissemination and topic filtering. Conversely, vehicles may operate as publishers, transmitting real-time telemetry such as speed and GPS (Global Positioning System) coordinates. In this case, RSUs or traffic control centers are subscribed to these streams for adaptive control or analytics via an MQTT broker. Only authenticated entities publish or subscribe, and all message payloads must be protected against tampering and eavesdropping to preserve data integrity and confidentiality [33].

MQTT also supports event-driven use cases, such as hazard alerting and vehicle prioritization, in V2I contexts. For example, when an RSU or On-Board Unit detects a hazardous road condition (e.g., icy surface and construction zones), it acts as a publisher, transmitting alerts to specific MQTT topics. The RSU, serving as the broker, regulates message dissemination and enforces topic-based access control. Nearby vehicles subscribe to these topics and receive real-time alerts that enhance driver awareness and road safety [27]. Similarly, emergency vehicle priority systems demonstrate the suitability of MQTT for time-critical applications. The approach described by Palos-Angulo et al. [34] presents a case study in which C-V2X (Cellular V2X) is used to transmit emergency alerts. In this scenario, vehicles near an incident (e.g., accident) act as publishers, sending alerts to a central authority (such as police, ambulance, and fire department), serving as the broker, which then relays the message to nearby vehicles potentially affected by the incident and functioning as subscribers. It is important to mention that the message requirements will depend on the type of emergency. That is to say, within the message payload, the alert message varies, where it can symbolize any type of emergency alert, from an object on the road to an accident requiring immediate intervention. In such latency-sensitive contexts, maintaining message authenticity, integrity, and confidentiality is critical to preventing spoofing, false signal injection, or data leakage.

In V2V (Vehicle-to-Vehicle) communication, MQTT facilitates peer-level data exchange. Each vehicle may simultaneously act as a publisher and a subscriber, sharing and consuming information on proximity-based topics through an MQTT broker, which could be an in-network unit like an RSU or even a vehicle acting in a temporary broker role. This setup supports coordinated actions like synchronized driving, where consistent and trusted communication is essential [25]. In structured V2V paradigms like platooning [35,36], multiple vehicles coordinate their movements in real time, which can include merging, lane changes, intersection crossing, or cooperative adaptive cruise control. Each vehicle may transmit telemetry, speed, and braking status as a publisher while also subscribing to others’ data. A designated lead vehicle can operate as the MQTT broker, managing message flow and maintaining group coherence. Vehicles adjust their behavior based on this broker-managed data stream whose integrity is essential. All participating nodes must be authenticated and messages must be signed and encrypted to ensure origin authenticity and integrity.

In V2N use cases, MQTT enables long-range communication over cellular or 5G networks. For example, RSUs can operate as publishers, transmitting congestion data, traffic incidents, or routing recommendations. These are relayed through a centralized cloud-based MQTT broker, to which vehicles subscribe dynamically based on their geographic location [37]. The same architecture supports upstream data flows, where vehicles act as publishers, continuously streaming telemetry (e.g., engine diagnostics, sensor payloads, or driving behavior metrics) to the cloud. Cloud-based services act as subscribers, consuming this information through the broker to enable functions such as monitoring or predictive maintenance [38]. To maintain trust in such environments, information dissemination plays a pivotal role. Robust identity management is necessary, data consistency must be preserved in transmission, and private diagnostics should not be exposed beyond authorized systems.

V2P scenarios provide another example of the usefulness of MQTT in safety-critical, low-latency interactions. LiDAR or vision-based sensors installed near crosswalks or urban corners act as publishers, broadcasting pedestrian detection events on predefined MQTT topics. These alerts are routed through an MQTT broker, typically deployed on edge computing elements co-located with RSUs. Vehicles entering the sensor coverage zone operate as subscribers, receiving real-time pedestrian presence updates through the broker [25]. Given the time-sensitive and safety-critical nature of V2P interactions, the MQTT communication framework must enforce strict publisher authentication, ensuring that only certified sensor nodes are allowed to publish, messages are not be modified during their transmission, and personal information is adequately protected from third-party access.

Figure 2 provides an illustrative representation of V2X communication enabled by MQTT, demonstrating the simultaneous operation of V2I, V2V, V2N, and V2P scenarios within a unified, event-driven messaging architecture. The lightweight MQTT publish/subscribe paradigm facilitates asynchronous data exchange across vehicular and infrastructure nodes. By explicitly defining the roles of publishers, subscribers, and brokers and incorporating essential security mechanisms for authentication, message integrity, and confidentiality, MQTT enables both reliable and secure communication in the dynamic and latency-sensitive environment of connected and autonomous vehicle systems.

4. Implementation and Methodology Overview

This section details the experimental framework and benchmarking methodology used to evaluate the performance and energy consumption of TLS 1.3-secured MQTT communication over both Ethernet and WiFi in an IoT setup. TLS is leveraged to provide the fundamental security properties of confidentiality, authentication, and integrity through four sequential connection phases, namely, key exchange, server authentication, client authentication, and symmetric encryption. For clarity, we refer to these as Phase 1, Phase 2, Phase 3, and Phase 4, respectively. The first three phases constitute the TLS handshake, where Phase 1 is mandatory, and Phases 2 and 3 may be optionally omitted based on the chosen authentication scheme. Phase 4 involves symmetric encryption of application-layer data, thereby ensuring the confidentiality of MQTT payloads during transmission.

In our experimental setup, depicted in Figure 3, each of the three primary MQTT roles, i.e., publisher, subscriber, and broker, is statically mapped to a dedicated IoT device. Configuring each device to operate in only one role throughout the experiment enables the precise attribution of resource usage to each role. For our evaluation, we systematically isolate and quantify the computational, energy, and communication overhead introduced by each TLS phase, providing a granular analysis of their impact on all MQTT entities within realistic IoT deployment.

4.1. Experimental Setup and Metrics

For consistency and experimental reproducibility, a dedicated testbed supporting both wired (Ethernet) and wireless (WiFi) configurations was designed. As illustrated in Figure 3, all experiments were conducted exclusively on Raspberry Pi 4 devices (quad-core ARM Cortex-A72, 64 bit, 1.5 GHz) running Raspberry Pi OS Lite (64 bit). Each device was statically assigned a single MQTT role, publisher, subscriber, or broker, with strict role isolation and was continuously connected to a power meter throughout the experiments, enabling the direct measurement of energy consumption for each test scenario.

Depending on the configuration, the devices were interconnected via either a Layer2 switch (Ethernet; Figure 3a) or a dedicated WiFi access point (Figure 3b). The wired configuration eliminates wireless channel variability, facilitating accurate baseline measurements, while the wireless setup reflects real-world conditions. Consequently, metrics such as CPU utilization, execution time, energy consumption, and goodput are subject to the influence of the communication channel, whereas memory requirements remain largely unaffected by channel conditions.

The MQTT broker, implemented using the Eclipse Mosquitto server, operates as a relay node for message exchange, coordinating communication between clients. The broker settings were adjusted across phases to reflect both TLS 1.3-secured and plaintext sessions. Custom Python 3.11 scripts were developed for the publisher and subscriber roles to allow for the precise specification of payload size, TLS version (1.3), cryptographic primitives (i.e., ECDHE using X25519, Ed25519), and cipher suites (i.e., AES_256_GCM and Chacha20_Poly1305). System orchestration and performance monitoring were automated with shell-based wrapper scripts, invoking external profiling tools such as perf for CPU measurements, and total wall-clock duration and /usr/bin/time -v for resource usage statistics. The metrics used include CPU utilization, peak Resident Set Size (RSS) memory, and client-to-broker and broker-to-client goodput.

Each experimental scenario was carefully designed to isolate the performance impact of individual TLS phases on a per-role basis. To ensure measurement fidelity, custom message patterns were generated and synchronized across devices, minimizing external interference. The methodology for each TLS phase and the corresponding message pattern details are described in the following sections.

4.2. Libraries

The implementation of TLS was performed via OpenSSL 3.0.16, which is the default cryptographic backend for both the Mosquitto broker and Python-based MQTT clients such as Paho MQTT utilized in our experiments. To ensure modern cipher suite support, the protocol was limited to TLS 1.3, which allowed for the consistent benchmarking of all phases. Cryptographic operations were conducted in the transport layer without applying application-layer encryption. In Phase 1, ECDHE using the elliptic curve 25519 was selected to establish forward secrecy between the clients and the broker. In Phases 2 and 3, authentication was achieved by presenting Certificate Authority (CA)-signed certificates. In Phase 4, AES_256_GCM or Chacha20_Poly1305 were selected from the TLS algorithm options, to secure the payload.

OpenSSL generated TLS certificates and provided them to all clients, as well as to the server. All entities shared a common root CA certificate in order to verify the identities of the peers. Depending on the MQTT configuration, data transmission is possible with no authentication, server-only authentication, or mutual authentication. These settings allowed us to quantify the computational and network overhead that each phase introduces.

4.3. Benchmarking Strategy

The benchmarking process is carefully structured to measure, on realistic IoT hardware, the impact of each TLS 1.3 phase during MQTT communication. To ensure accuracy and reproducibility, all scenarios are fully automated using shell scripts that coordinate, monitor, and collect data for each run. Each reported value is the mean of twenty experimental cycles, while for metrics such as CPU utilization and execution time during encryption, the standard deviation is also reported whenever non-negligible.

For each test case, a fixed number of MQTT messages of the same size are transmitted from the publisher to the subscriber through the broker. Each phase uses different Mosquitto configurations to achieve the corresponding measurement isolation. For the first three phases, a single one-byte message is exchanged in order to ensure the handshake completion and at the same time minimize the introduced payload distortion. This approach is also used in the No-TLS (plaintext) experiment, offering the control baseline. In contrast, Phase 4 (data exchange) is benchmarked using three payload sizes corresponding to low- (100 KB), medium- (1 MB), and high-volume (100 MB) data transfer and five different configurations of message count and size, for both AES_256_GCM and Chacha20_Poly1305.

The isolation of the TLS phases is handled differently for handshake (Phases 1–3) and data exchange (Phase 4). For the handshake, we adopt a step-wise additive method: each experimental Mosquitto configuration sequentially enables one additional TLS handshake phase, and the incremental overhead is attributed to the specific phase under test. For Phase 4 precise start- and stop-time measurements, complemented, for the broker, by three introduced MQTT control topics, precisely mark the productive time-frames in which all measurements for all payload and cipher suite combinations are conducted.

Further elaborating on Phase 4, the scenarios executed are designed to systematically evaluate how varying demands of the application layer affect the performance of TLS 1.3-secured MQTT. Specifically, we benchmark three message size configurations for a fixed total payload of 100 KB: 1000 × 100 B, 100 × 1000 B, and 10 × 10,000 B. These configurations reflect typical V2X message types specified in standards such as ETSI EN 302 637-2 (Cooperative Awareness Messages (CAMs) and Decentralized Environmental Notification Messages (DENMs)) [39], SAE J2735 (Basic Safety Messages (BSMs) and Signal Phase and Timing (SPaT/MAP)) [40], and 3GPP TR 22.886 [41]. The first configuration corresponds to routine status updates, e.g., vehicle position, speed, and heading, found in CAMs or BSMs, while the second represents medium-sized safety alerts and environmental warnings, such as DENMs or SPaT data. The third configuration reflects large payloads relevant to localized map segments or partial firmware transmissions.

In addition to the 100 KB scenarios, we include the medium-volume payload of 1 MB configured as 1000 × 1000 B to represent more intensive sensing or vehicular data exchange. Finally, a high-volume stress scenario with a payload of 100 MB, configured as 10,000 × 10,000 B, corresponds to intensive operations such as advanced driving and over-the-air (OTA) firmware or map database updates aligned with the use cases described in ETSI TS 122 186 [42], SAE J3151 [43], and 3GPP TR 22.886 [41]. All payloads are generated deterministically to ensure repeatability, and packet capture is synchronized with message transmission and reception, enabling precise measurement of latency, goodput, and resource utilization. These standard-aligned payload configurations allow for a comprehensive and realistic evaluation of TLS-enhanced MQTT in V2X contexts.

Execution time and CPU cycle measurements for the handshake phases are collected using the perf stat tool, which wraps the relevant process from start to finish. For the broker, perf monitors the entire Mosquitto process to capture handshake duration passively, while for publisher and subscriber, it wraps the Python process encompassing connection, message exchange, and disconnection.

For Phase 4, each run begins with the broker launching the MQTT server, followed by the launch of the subscriber. The publisher is started after a short delay to ensure that both the broker and subscriber are fully initialized and subscribed to the relevant control topics. To monitor execution timing, a dedicated Bash script runs on the broker side, capturing timestamps with millisecond precision using the command /bin/date +%s.%N triggered upon the reception of control messages. The broker marks its start time upon receiving the control/start signal from the publisher. Two key time intervals are computed: the first measures the duration required to receive all messages from the publisher, while the second spans from the reception of the first message to the arrival of the final PUBACK from the subscriber. These intervals allow us to compute (i) the client-to-broker goodput and (ii) the end-to-end latency, defined as the total time required to transmit the complete payload from publisher to subscriber via the broker.

Upon completion of message publishing, the publisher script sends a message to the control/pubdone topic to indicate that all messages have been transmitted. This enables the subscriber-side benchmark controller to accurately compute the total elapsed time between the control/start and control/pubdone messages, with millisecond-level granularity. Once the subscriber receives the final message and sends the corresponding PUBACK to the broker, it issues a message to the control/stop topic to confirm that the payload has been fully received. On publisher and subscriber devices, wall-clock time for sending and receiving is measured in Python using time.perf_counter() to ensure high-resolution, monotonic timing. For the publisher, the clock starts immediately before the first payload message is sent and stops after the final publication. For the subscriber, timing begins upon receipt of the first payload message and ends after the last message is received. This event-driven synchronization strategy eliminates the need for cross-device clock alignment and ensures deterministic, reproducible latency and goodput calculations.

In our experiments, the term actual messages refers to the payload messages that are measured and analyzed. Prior to each benchmark run, we introduce a warm-up phase in which a number of preliminary messages are transmitted to avoid cold-start effects and stabilize system behavior. The number of warm-up messages is determined by the formula $warmup\_count=\left(min\right(int(count\times 0.2),200\left)\right)$, where warmup_count denotes the number of actual messages in the given experiment. This approach ensures that the warm-up phase is proportionally significant in smaller experiments, without introducing excessive overhead in larger ones. After each run, a short grace period is included to allow for the flushing of logs, the completion of background processes, and the delivery of any remaining messages. Additionally, the termination of the experiment is deliberately delayed to guarantee that all timestamps, performance metrics, and output data are consistently and deterministically recorded.

In each experimental run, goodput is computed by dividing the total size of the transmitted payload (in bytes) by the corresponding execution time. This metric reflects the effective application-layer throughput, excluding protocol overhead, retransmissions, and control messages. The selected measurement approach offers reliable and accurate insights into real data delivery performance. In our setup, goodput was found to be more representative than raw throughput measurements, particularly because tools like tshark introduced significant processing overhead on resource-constrained devices that led to latency spikes, packet loss, and inconsistent measurements. The same methodology is applied to both broker and subscriber roles to ensure fair client-to-broker and broker-to-client comparison.

For power consumption measurements, external power meters were installed in line with the power supply of each Raspberry Pi device. These meters recorded real-time voltage and current values throughout the entire duration of the experiments. The publisher and subscriber draw 2.369 W (5.15 V, 460 mA), while the broker operates at 1.881 W (4.95 V, 380 mA). The observed values show negligible variance across trials and are treated as constants for energy estimation. Energy consumption per run was computed by multiplying the measured power (in W) by the execution time (in sec) for each device role, yielding the total energy in Joules (J). This method provides a reliable and repeatable approximation of the energy profile for each MQTT entity (publisher, subscriber, and broker) across all experimental configurations.

5. Performance Evaluation

This section quantifies the resource requirements associated with TLS phases, over both Ethernet and WiFi. For the handshake phase, we focus on measurements of CPU cycles, execution time, energy consumption, and maximum Resident Set Size (RSS), all conducted over Ethernet. WiFi measurements were not performed at this stage, as the low volume and short duration of handshake message exchanges minimize the influence of the underlying network medium. Consequently, the Ethernet-based results are considered a reliable proxy for wireless performance in the handshake phase. In contrast, for the data exchange phase, we systematically evaluate the impact of five distinct message packaging scenarios on CPU cycles, execution time, end-to-end latency, energy consumption, maximum RSS, and goodput—using both Ethernet and WiFi interfaces and for both the Chacha20_Poly1305 and AES_256_GCM cipher suites. These metrics collectively provide insights into the resource and performance implications of different application-layer architectural choices.

5.1. 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. TLS handshake evaluation: CPU usage, time requirements, and energy consumption.

	CPU (Mcycles)				Execution Time (s)				Energy (J)
Role	no-TLS	Key Exch. (ECDHE)	Server Auth (Ed25519)	Client Auth (Ed25519)	no-TLS	Key Exch. (ECDHE)	Server Auth (Ed25519)	Client Auth (Ed25519)	no-TLS	Key Exch. (ECDHE)	Server Auth (Ed25519)	Client Auth (Ed25519)
Publisher	321	$379.3$	$381.8$	$439.6$	$0.234$	$0.248$	$0.255$	$0.289$	$0.554$	$0.588$	$0.604$	$0.685$
Subscriber	362	$411.3$	$422.9$	426	$0.267$	$0.268$	$0.283$	$0.286$	$0.633$	$0.635$	$0.670$	$0.678$
Broker	19	$19.8$	$19.8$	$20.2$	$0.0118$	$0.0119$	$0.0121$	$0.0121$	$0.0222$	$0.0224$	$0.0228$	$0.0228$

, 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 Mosquitto 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, introduce a measurable increase in execution time and energy usage for the publisher and subscriber, yet the impact on the broker remains minimal.

The handshake process did not result in any significant changes in memory usage throughout all TLS phases. The maximum RSS remains constant at 21,400 KB for both the publisher and subscriber and at 11,600 KB for the broker, which shows that TLS handshake complexity affects latency more than memory usage. These findings demonstrate the trade-offs which occur when deploying MQTT securely. TLS 1.3 proves to be suitable for constrained IoT environments due to the fact that it introduces manageable handshake overhead while keeping memory usage minimal.

Our results presented in this section follow the same general trend as those reported in [7]. Specifically, we observe a consistent increase in CPU usage across all roles as we move from no-TLS to the progressive integration of TLS Phases 1, 2, and 3. Similarly, as in their study, the maximum RSS remains stable on the client side, even when TLS is activated. However, a key distinction lies in the experimental environment: whereas Dimov et al. [7] conducted their evaluation using virtual machines hosted on server infrastructure, our measurements are derived from execution on real IoT devices, specifically Raspberry Pi 4B boards, over Ethernet.

5.2. Symmetric Encryption Evaluation

The symmetric encryption evaluation focuses on quantifying and comparing the impact of AES_256_GCM and ChaCha20_Poly1305 on MQTT communication under TLS 1.3. We begin with a direct comparison of the raw encryption speed that both algorithms achieved in an isolated environment. Subsequently, we assess key system metrics on the Raspberry Pi 4B platform, including CPU utilization, execution time, end-to-end latency, energy consumption, memory usage (maximum RSS), and application-layer goodput—across all defined message packaging scenarios. In particular, we examine performance for the payload of 100 KB under three different message configurations, as well as more demanding configurations with total payloads of 1 MB and 100 MB. This methodology enables a realistic and standard-aligned assessment of symmetric cipher performance in constrained, security-critical V2X environments.

The OpenSSL speed benchmark shows the results for standalone cipher throughput as a function of block size in

Table 3. Cipher speed (MB/s) per block size.

	Bytes	16 B	64 B	256 B	1 KB	8 KB
Cipher
AES_256_GCM (MB/s)		$44.6$	$53.8$	$65.3$	$68.6$	$70.6$
Chacha20_Poly1305 (MB/s)		$80.6$	140	$253.7$	$311.6$	$322.3$

. AES_256_GCM does not achieve the performance level of Chacha20_Poly1305 when processing small payload sizes. Chacha20_Poly1305 reaches a speed of 80.6 MB/s at 16 B block sizes, while AES_256_GCM operates at 44.6 MB/s speed. The speed difference between Chacha20_Poly1305 and AES_256_GCM broadens significantly as the block sizes increase, where Chacha20_Poly1305 reaches 322.3 MB/s at 8192 B, while AES_256_GCM reaches only 70.6 MB/s resulting in a performance difference of approximately 4.5 times. This trend is also observed in [7], where for a block size equal to 8192 B, we notice the maximum performance difference, while Chacha20_Poly1305 is approximately 3.3× faster than AES_128_GCM. This difference between our observations is due to the fact that we are testing the more demanding AES_256_GCM.

The system-level performance evaluation measures CPU cycle consumption throughout all message patterns, for the same overall payload, and roles according to

Table 4. CPU usage (MCycles) during TLS Phase 4 (data encryption): ChaCha20 vs. AES-GCM for 100 KB payload under different message packaging configurations over both Ethernet and WiFi.

Role		ChaCha20			AES-GCM
		1000 × 100 B	100 × 1000 B	10 × 10,000 B	1000 × 100 B	100 × 1000 B	10 × 10,000 B
ETH	Publisher	$1386.6\pm 9.2$	$764.3\pm 6$	$707\pm 6.2$	$1436.2\pm 32.9$	$768.6\pm 6.3$	$707\pm 6$
	Subscriber	$1093.1\pm 14.3$	$717.1\pm 20.2$	$670.9\pm 23.2$	$1095.3\pm 10.7$	$726.2\pm 22$	$677\pm 19.7$
	Broker	$126.4\pm 0.3$	$18.5\pm 0.3$	$8.7\pm 0.4$	$126.4\pm 0.2$	$18.7\pm 0.7$	$8.8\pm 0.4$
WIFI	Publisher	$1386.6\pm 28.2$	$766.9\pm 4.8$	$709.5\pm 9.8$	$1470.1\pm 13$	$769.4\pm 7.9$	$710.2\pm 10$
	Subscriber	$1114.8\pm 15.4$	$718.1\pm 18$	$678\pm 23$	$1123.9\pm 16.7$	$727.3\pm 18.2$	$678.6\pm 17.5$
	Broker	$161.7\pm 6.6$	$23.1\pm 1.1$	$8.9\pm 0.4$	$161.9\pm 4.9$	$23.4\pm 0.9$	$9\pm 0.4$

. We observe that the selection of the combination of the number of messages and message size in MQTT communication heavily affects the overhead applied in the IoT device, which aligns with the findings of [7], where all roles are implemented in VMs. We observe that for publisher and subscriber, the differences between Ethernet and WiFi are minimal. In addition, AES_256_GCM is more demanding than Chacha20_Poly1305 across all experimentation, with the biggest overhead being introduced in the publisher for the 1000 × 100 B message packaging. Indicatively the publisher needs 1386.6 Mcycles to complete transmission for Chacha20_Poly1305, in both wired and wireless setups, which increases to 1436.2 Mcycles-ETH ($+3.6\%$) and 1470.1 Mcycles-WiFi ($+6\%$) for AES_256_GCM. For 100 × 1000 B, it requires approximately 765 Mcycles for both algorithms and interfaces, which drops further for the 10 × 10,000 B experiment, where 710 Mcycles are required. Both the subscriber and broker follow similar patterns, whilst the broker exhibits the highest overhead ($+28\%$) when executed on the wireless setup with the 1000 × 100 B message packaging.

As presented in

Table 5. Execution time (sec) during TLS Phase 4 (data encryption): ChaCha20 vs. AES-GCM for 100 KB payload under different message packaging configurations over both Ethernet and WiFi.

Role		ChaCha20			AES-GCM
		1000 × 100 B	100 × 1000 B	10 × 10,000 B	1000 × 100 B	100 × 1000 B	10 × 10,000 B
ETH	Publisher	$0.590\pm 0.022$	$0.108\pm 0.003$	$0.040\pm 0.004$	$0.594\pm 0.022$	$0.109\pm 0.003$	$0.040\pm 0.002$
	Subscriber	$0.589\pm 0.022$	$0.106\pm 0.004$	$0.036\pm 0.003$	$0.593\pm 0.022$	$0.107\pm 0.003$	$0.036\pm 0.002$
	Broker	$0.634\pm 0.021$	$0.150\pm 0.004$	$0.087\pm 0.007$	$0.638\pm 0.023$	$0.150\pm 0.004$	$0.089\pm 0.005$
WIFI	Publisher	$4.853\pm 0.095$	$0.561\pm 0.020$	$0.104\pm 0.004$	$4.899\pm 0.155$	$0.589\pm 0.032$	$0.108\pm 0.005$
	Subscriber	$4.847\pm 0.094$	$0.554\pm 0.022$	$0.091\pm 0.004$	$4.893\pm 0.155$	$0.583\pm 0.032$	$0.095\pm 0.005$
	Broker	$4.910\pm 0.097$	$0.616\pm 0.020$	$0.158\pm 0.006$	$4.956\pm 0.155$	$0.647\pm 0.032$	$0.163\pm 0.006$

, the execution time of 1000 × 100 B for the Ethernet setup, for both publisher and subscriber on Chacha20_Poly1305 and AES_256_GCM, is about 5.5 times slower than 100 × 1000 B. This grows further to about 14.8 and 16.5 times for publisher and subscriber, respectively, compared with 10 × 10,000 B. Furthermore, 1000 × 100 B is more than 2.5 times slower to execute than 10 × 10,000 B. For the broker, 1000 × 100 B is more than four and seven times slower than 100 × 1000 B and 10 × 10,000 B, respectively. While 100 × 1000 B is only about 1.7 times slower than 10 × 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 × 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 × 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 × 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.

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. Energy consumption (J) during TLS Phase 4 (data encryption): ChaCha20 vs. AES-GCM for 100 KB payload under different message packaging configurations over both Ethernet and WiFi.

Role		ChaCha20			AES-GCM
		1000 × 100 B	100 × 1000 B	10 × 10,000 B	1000 × 100 B	100 × 1000 B	10 × 10,000 B
ETH	Publisher	$1.398$	$0.256$	$0.095$	$1.407$	$0.258$	$0.095$
	Subscriber	$1.395$	$0.251$	$0.085$	$1.405$	$0.253$	$0.085$
	Broker	$1.193$	$0.282$	$0.164$	$1.2$	$0.282$	$0.167$
WIFI	Publisher	$11.497$	$1.329$	$0.246$	$11.606$	$1.395$	$0.256$
	Subscriber	$11.483$	$1.312$	$0.216$	$11.592$	$1.381$	$0.225$
	Broker	$9.236$	$1.159$	$0.297$	$9.322$	$1.217$	$0.307$

. 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 × 100 B messages, the AES_256_GCM publisher requires 6% more CPU cycles. For the 100 × 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. 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.

Role		Chacha20			AES-GCM
		100 KB (1000 × 100 B)	1 MB (1000 × 1000 B)	100 MB (10,000 × 10,000 B)	100 KB (1000 × 100 B)	1 MB (1000 × 1000 B)	100 MB (10,000 × 10,000 B)
ETH	Publisher	$1386.6\pm 9.2$	$1460.4\pm 16.1$	10,071 ± 84.7	$1436.2\pm 32.9$	$1504\pm 15.5$	10,170.3 ± 95.5
	Subscriber	$1093.1\pm 14.3$	$1165.8\pm 14.1$	13,325.3 ± 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$
WIFI	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$

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 subscriber, respectively. In contrast, broker CPU usage exhibits $54.4\%$ and $38.1\%$ increases in the wired and wireless setups. As expected, the large-scale set requires the most cycles. The publisher is from $6.9$ to $7.6$ times more demanding than the small and medium test’s publisher and subscriber in both the wired and wireless setups, while for the broker, we have increases of 64 and $41.4$ times for Ethernet and 50 and $36.2$ times for WiFi, on the low and medium scales, respectively. AES_256_GCM follows the same trends while remaining heavier throughout the entirety of the experimentation. The maximum overhead is for the 1000 × 100 B message packaging, on WiFi, where we observe a $6\%$ increase. Furthermore, we note that as we scale from low- and medium- to high-scale experiments, wireless communication affects the nodes differently. For 100 KB and 1 MB, the broker is mainly affected, while for 100 MB, the publisher is.

From

Table 8. Execution time (sec) 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.

Role		ChaCha20			AES-GCM
		100 KB (1000 × 100 B)	1 MB (1000 × 1000 B)	100 MB (10,000 × 10,000 B)	100 KB (1000 × 100 B)	1 MB (1000 × 1000 B)	100 MB (10,000 × 10,000 B)
ETH	Publisher	$0.590\pm 0.02$	$0.871\pm 0.03$	$35.807\pm 2.04$	$0.594\pm 0.02$	$0.894\pm 0.04$	$36.150\pm 2.03$
	Subscriber	$0.589\pm 0.02$	$0.870\pm 0.03$	$35.803\pm 2.04$	$0.593\pm 0.02$	$0.893\pm 0.04$	$36.147\pm 2.03$
	Broker	$0.634\pm 0.02$	$0.915\pm 0.03$	$35.851\pm 2.04$	$0.638\pm 0.02$	$0.938\pm 0.04$	$36.194\pm 2.03$
WIFI	Publisher	$4.853\pm 0.10$	$5.434\pm 0.28$	$98.658\pm 1.90$	$4.899\pm 0.16$	$5.621\pm 0.32$	$101.320\pm 2.29$
	Subscriber	$4.847\pm 0.09$	$5.428\pm 0.28$	$98.645\pm 1.90$	$4.893\pm 0.16$	$5.615\pm 0.32$	$101.307\pm 2.29$
	Broker	$4.910\pm 0.10$	$5.491\pm 0.28$	$98.714\pm 1.90$	$4.956\pm 0.16$	$5.678\pm 0.33$	$101.379\pm 2.29$

we infer that AES_256_GCM remains $0.6\%$ to $3.3\%$ slower than Chacha20_Poly1305. In addition, we have uniform overhead in all roles when comparing across scales. For instance, from low to medium scales, we have increases $44.3\%$ to $50.6\%$ for Ethernet and $11.8\%$ to $14.8\%$ for WiFi. The high-volume experiment requires the most time for execution, as it is 55 to 60 times slower than the low-volume one for the wired setup and about 19 times slower for the wireless setup. As has been demonstrated previously, we deduce the end-to-end payload latency from the broker’s execution time. 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. Energy consumption (J) 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.

Role		ChaCha20			AES-GCM
		100 KB (1000 × 100 B)	1 MB (1000 × 1000 B)	100 MB (10,000 × 10,000 B)	100 KB (1000 × 100 B)	1 MB (1000 × 1000 B)	100 MB (10,000 × 10,000 B)
ETH	Publisher	$1.398$	$2.063$	$84.827$	$1.407$	$2.118$	$85.639$
	Subscriber	$1.395$	$2.061$	$84.817$	$1.405$	$2.116$	$85.632$
	Broker	$1.193$	$1.721$	$67.436$	$1.200$	$1.764$	$68.081$
WIFI	Publisher	$11.497$	$12.873$	$233.721$	$11.606$	$13.316$	$240.027$
	Subscriber	$11.483$	$12.859$	$233.690$	$11.592$	$13.302$	$239.996$
	Broker	$9.236$	$10.329$	$185.681$	$9.322$	$10.680$	$190.694$

. The impact of message packaging selection is represented in the comparison of 1000 × 100 B and 1000 × 1000 B, where for WiFi, we have $12\%$ and $14.5\%$ increases for Chacha20_Poly1305 and AES_256_GCM, respectively. In 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. Maximum RSS for data transmission (MB).

Role	Non-TLS	TLS
Publisher	$26.1$	$27.5$
Subscriber	$26.1$	$27.6$
Broker	$7.3$	$8.5$

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. Measured goodput (KB/sec) in TLS Phase 4 for low- (100 KB), medium- (1 MB), and high-volume (100 MB) payloads transmitted with ChaCha20 over Ethernet and WiFi.

Direction		100 KB			1 MB	100 MB
		1000 × 100 B	100 × 1000 B	10 × 10,000 B	1000 × 1000 B	10,000 × 10,000 B
ETH	Client → Broker	$165.7\pm 5.7$	$919\pm 25$	$2415.8\pm 265.9$	$1122.8\pm 39.4$	$2736.3\pm 159$
	Broker → Client	$166\pm 5.8$	$922.5\pm 32$	$2743.8\pm 288.1$	$1124.2\pm 39.1$	$2736.6\pm 159.1$
WIFI	Client → Broker	$20.1\pm 0.4$	$172.9\pm 6.2$	$916.3\pm 37.7$	$179.9\pm 7.9$	$990.2\pm 18.6$
	Broker → Client	$20.2\pm 0.4$	$176.6\pm 6.8$	$1074.3\pm 47.3$	$180.3\pm 7.9$	$990.3\pm 18.6$

) and AES_256_GCM (

Table 12. Measured goodput (KB/sec) in TLS Phase 4 for low- (100 KB), medium- (1 MB), and high-volume (100 MB) payloads transmitted with AES-GCM over Ethernet and WiFi.

Direction		100 KB			1 MB	100 MB
		1000 × 100 B	100 × 1000 B	10 × 10,000 B	1000 × 1000 B	10,000 × 10,000 B
ETH	Client → Broker	$164.7\pm 5.8$	$913.6\pm 20.8$	$2339.4\pm 116.2$	$1094.2\pm 40.0$	$2710.1\pm 155.7$
	Broker → Client	$164.9\pm 5.8$	$913.5\pm 24.5$	$2705.9\pm 140.5$	$1095.5\pm 39.9$	$2710.4\pm 155.7$
WIFI	Client → Broker	$19.9\pm 0.6$	$164.6\pm 8.4$	$874.9\pm 39.5$	$174.0\pm 8.3$	$964.3\pm 21.6$
	Broker → Client	$20.0\pm 0.6$	$168.1\pm 8.8$	$1030.9\pm 51.5$	$174.4\pm 8.3$	$964.4\pm 21.6$

). We observe that the combination of message count and individual message size significantly influences this metric, underscoring the importance of optimized message packaging strategies for efficient and reliable communication.

Overall, Chacha20_Poly1305 produces better results than AES_256_GCM, making it a better choice for time-critical V2X applications. In that regard, among the 100 KB message packagings, a significant goodput surge is observed over WiFi from 1000 × 100 B to 10 × 10,000 B, where the latter’s measurements are more than 40 times for client-to-broker communication and more than 50 times higher for broker-to-client communication for both encryption algorithms. These drops to 5 and 6 times higher, respectively, compared with 100 × 1000 B. Additionally, for 1 MB and 100 MB, we infer that they have comparable results to 100 × 1000 B and 10 × 10,000 B, respectively. This is a strong indication that goodput is greatly influenced by the size and not the number of messages selected.

The findings presented in this section are of great importance in order to develop and maintain V2X solutions with package configurations, which primarily serve the applications needs and at the same time address the resource constrains encountered in the IoT environment.

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 Comparison. Regarding 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-offs. With 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 × 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 × 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 Configurations. Our findings address RQ3 by linking performance observations to practical V2X use cases. For time-critical applications like hazard alerts or pedestrian warnings, configurations like 10 × 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 × 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 Dimov et al. [7], who observed similar performance trends under TLS-secured MQTT; however, our study offers a more comprehensive and realistic evaluation. While Dimov et al. conducted their experiments using containerized virtual machines on server-grade hardware, our testbed utilizes physical IoT devices (Raspberry Pi 4B), 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 Dimov 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.

Implications and Future Work Directions. This work demonstrates that TLS-secured MQTT communication is viable on IoT-class hardware when carefully configured, even under high-throughput or time-sensitive V2X scenarios. The interplay between cipher selection, network interface, and message composition reveals trade-offs among security, performance, and energy efficiency. Building on these insights, interesting future work directions emerge:

• Quality of Service (QoS) analysis under load and mobility: Although the current study focused on MQTT QoS level 1, further research could explore the performance implications of QoS levels 0 and 2 under different traffic intensities and mobility patterns. Evaluating packet delivery guarantees, retransmission overhead, and latency under WiFi and 5G mobility scenarios could offer critical insights for QoS selection in highly dynamic V2X contexts.
• Feasibility in Ultra-Constrained Platforms (ESP32, ARM Cortex-M, etc.): It would be worthwhile to assess the feasibility of TLS $1.3$-secured MQTT on highly constrained platforms, such as ESP32 or ARM Cortex-M microcontrollers, which are common in low-power embedded deployment. Benchmarking these devices in terms of handshake execution time, memory usage, and cipher suite performance could help define minimum operational thresholds for secure communication in the most resource-limited environments.
• Wireless Network Dynamics and TLS Session Robustness: Wireless environments are prone to jitter, handoffs, and dynamic IP address changes, all of which may affect the stability of TLS sessions. Investigating how these dynamics influence session persistence, reconnection latency, and throughput degradation, particularly in realistic multi-hop WiFi or 5G networks, would provide valuable evidence for secure session design in mobile IoT applications.
• MQTT and CoAP Comparison in V2X Contexts: Another promising direction would be a comparative analysis of MQTT over TLS and DTLS-secured CoAP in realistic V2X environments. Such a study could examine key performance metrics, such as end-to-end latency, bandwidth efficiency, fault tolerance, and energy consumption, to determine the suitability of each protocol for time- and safety-critical applications such as hazard notifications or vehicular telemetry. Additional focus could be placed on the protocol behavior under network congestion and retransmission conditions.
• Post-Quantum Cryptography on Resource-Constrained Devices: Finally, as TLS 1.3 evolves to support quantum-resistant cryptographic primitives, it would be interesting to investigate the feasibility of the Kyber, Dilithium, and SPHINCS+ algorithms [44,45], recently standardized by NIST, on ARMv8-based IoT platforms. These schemes introduce larger keys and higher computational demands, raising questions about their impact on handshake latency, energy consumption, and memory usage. Future studies could explore both Key Encapsulation Mechanisms (e.g., Kyber-KEM) and Digital Signature Algorithms (e.g., Dilithium and SPHINCS+) in real-world IoT hardware, extending earlier simulation-based assessments such as those by Opilka et al. [11].

In summary, these future directions aim to build a comprehensive empirical framework to optimize secure and efficient communication across diverse V2X and IoT scenarios, while ensuring adaptability to emerging cryptographic standards and resilience to the threats of both the classical and quantum eras.

7. Conclusions

This study provides a comprehensive empirical assessment of TLS-secured MQTT communication on resource-constrained IoT hardware, with a focus on V2X-relevant message workloads. Our experimental results yield several key findings. First, we demonstrate that constrained devices such as Raspberry Pi 4B boards can effectively support TLS 1.3 in MQTT-based deployment, but the introduction of security comes with measurable resource overheads: we observe up to $37\%$ higher CPU utilization, $23.5\%$ longer execution times, and $23.7\%$ increased energy consumption during the handshake phase. Second, our results reveal that the selection of message packaging strategies significantly influences both performance and efficiency; e.g., batching payloads into fewer, larger messages consistently reduces latency and energy cost per byte while minimizing protocol overhead. Third, the choice of the cipher suite is shown to be critical: ChaCha20_Poly1305 outperforms AES_256_GCM in all examined scenarios, especially in wireless settings, making it better suited for time-sensitive and energy-constrained V2X applications.

Despite these findings, the study has certain limitations. Our evaluation is restricted to Cortex-A72 ARMv8 boards and does not yet cover more constrained microcontrollers, such as ESP32 or ARM Cortex-M, which may face additional challenges. In addition, while our wireless experiments employed realistic WiFi conditions, they did not fully explore the impact of real-world wireless conditions, e.g., jitter and mobility. These aspects may further influence protocol performance and robustness in real-world deployment.

Future work should address these open issues. A promising direction is to systematically evaluate all MQTT Quality of Service (QoS) levels under various network loads and mobility patterns to understand the trade-offs in reliability, latency, and resource usage. Additionally, we plan to conduct a rigorous comparison between MQTT over TLS and DTLS-secured CoAP in V2X settings, assessing protocol suitability in terms of latency, bandwidth, energy consumption, and resilience.