Assessing the Adequacy of MQTT and ZeroMQ for 5G-Enabled V2X Networks ^†

Abstract

The advent of fifth-generation (5G) networks has enabled cellular vehicle-to-everything (C-V2X) communication, requiring the efficient delivery of large volumes of real-time vehicular data under stringent latency and reliability constraints. At the application layer, Message Queuing Telemetry Transport (MQTT) and ZeroMQ have emerged as candidate protocols; however, their comparative performance in vehicular networking contexts remains insufficiently examined. This work presents a simulation-based evaluation of MQTT and ZeroMQ using OMNeT++, integrating INET for protocol modeling, Veins for vehicular mobility, and Simu5G for cellular network operations. We developed custom protocol modules and assessed them under diverse traffic conditions, analyzing key metrics such as end-to-end latency, message overhead, and scalability. Our results reveal that ZeroMQ achieves lower latency in moderate traffic scenarios, whereas MQTT demonstrates superior reliability and efficiency under high traffic loads, offering valuable insights for selecting application-layer protocols in C-V2X environments.

1. Introduction

The exponential growth of data within the Internet of Things (IoT) realm requires increasingly sophisticated communication infrastructures to enable real-time, low-latency communication among devices [1]. Existing communication infrastructures, typified by 4G/Long-Term Evolution (LTE) networks, struggle to provide the required speed, latency, bandwidth, and throughput requirements [2]. In this context, 5G networks have emerged as a transformative solution, offering ultra-low latency, high data throughput, and massive device connectivity [3]. By employing advanced techniques like Network Slicing, multiple-input-multiple-output (MIMO), millimeter-wave (mmWave) spectrum utilization, Coordinated Multipoint Processing (CoMP), Device-to-Device (D2D) communications [1,3], centralized radio access network (C-RAN), Software-Defined Wireless Sensor Networking (SD-WSN), Network Function Virtualization (NFV) [4,5], and Cognitive Radios (CRs), 5G promises to fulfill the demands of the exponentially growing IoT ecosystem [1].

Furthermore, 5G-enabled V2X communication falls under the automobile domain of the broader Internet of Things ecosystem. By exploiting the capabilities of the 5G networks, vehicles can seamlessly communicate with each other (V2V), with the infrastructure (V2I), with pedestrians (V2P), and with other networks (V2N), achieving what is collectively known as Vehicle-to-Everything (V2X) communications. The latter holds the potential to revolutionize transportation systems by enhancing road safety, improving traffic efficiency, and enabling emerging applications such as autonomous driving.

Despite these advances, achieving dependable and efficient message dissemination in highly dynamic vehicular environments remains challenging. The performance of the system largely depends on the choice of application-layer messaging protocols, which govern how information is exchanged between entities. In this regard, Message Queuing Telemetry Transport (MQTT) and ZeroMQ have emerged as lightweight, scalable protocols that are promising for real-time communication in C-V2X systems. However, their comparative evaluation within 5G-enabled vehicular contexts has received limited attention in existing literature, particularly under diverse traffic and network load conditions.

Research Contribution

To achieve our research goals, we present a simulation-driven evaluation framework designed to analyze the performance of MQTT and ZeroMQ in 5G-enabled vehicular networks. The primary objective is to provide an empirical understanding of how these protocols behave under varying network topologies, mobility patterns, and traffic conditions. This work contributes to:

• Design and implement a unified simulation environment integrating Veins, Simu5G, and INET to support realistic C-V2X communication modeling.
• Develop and extend protocol modules for MQTT and ZeroMQ within the OMNeT++ framework to enable comparative analysis under identical conditions.
• Evaluate and analyze the performance of both protocols in terms of latency, throughput, scalability, and reliability across multiple vehicular mobility scenarios.

Through this framework, we aim to bridge the current gap in the literature by offering a comprehensive performance comparison of application-layer communication mechanisms within 5G-enabled C-V2X ecosystems.

The remainder of this paper is organized as follows. Section 2 presents the existing literature related to various V2X use cases and their 5G enabling technologies; it also outlines some of the work done on the use of MQTT and ZeroMQ for V2X. Afterwards, Section 3 provides a walk-through of the steps taken to design and implement the simulation scenarios necessary for the evaluation of both MQTT and ZeroMQ protocols. The simulation setup is detailed in Section 4. The results of the simulation and their detailed analysis are then presented in Section 5. Finally, Section 6 concludes the paper and refers to future work.

2. Theoretical Background and the Literature Review

2.1. Related Work

The evolution of 5G networks has introduced several key enhancements, including improved support for massive multiple input multiple output (MIMO) systems, ultra-low latency through edge computing, and dynamic resource allocation through network slicing [6]. These technological advancements have been pivotal in the increasing adoption of C-V2X, as they address some of the limitations associated with Dedicated Short Range Communication (DSRC), such as limited range and scalability. C-V2X operates using two main communication interfaces: the Uu interface, which utilizes existing cellular infrastructure for wide-area coverage, and the PC5 interface, which enables direct peer-to-peer communication between vehicles and other intelligent transport systems [7,8].

Authors in [9] conducted a comprehensive trial of C-V2X communication in LTE networks, utilizing both the 3GPP PC5 (sidelink) and Uu (cellular) interfaces to evaluate performance under real-world conditions. The study demonstrated the feasibility of C-V2X communication in high-speed vehicular scenarios, confirming successful data exchange even at relative speeds of up to 220 km/h. For direct V2V communication over the PC5 interface, the trial observed a packet error rate (PER) of less than 10% for distances up to 1200 m. Furthermore, the median end-to-end latency between two test vehicles was measured to be under 20 ms, indicating reliable low-latency performance critical for safety applications.

In addition to sidelink communication, the trial assessed the Uu interface, which enables V2N communication through cellular infrastructure. Testing conducted over the NTT DOCOMO commercial LTE network during the connected state revealed a median end-to-end latency of approximately 50 ms. Even at the 95th percentile, the end-to-end latency remained below 60 ms, demonstrating the potential for C-V2X to support a wide range of vehicular applications, including cooperative driving and traffic management.

Several studies [8,10,11] have explored the integration of 5G cellular infrastructure into V2X communication, analyzing both the potential benefits and challenges associated with its deployment. The 5GAA has been instrumental in promoting the use of 5G for V2X applications, providing standardization documents and insights into stakeholder support. Notably, the 5GAA C-V2X use case document [12] outlines various mobility scenarios where the low-latency capabilities of 5G networks play a crucial role in enabling reliable and efficient V2X communication. Vieira et al. [13] proposed a hybrid roadside and cloud-based vehicular communication framework that integrates MQTT brokers for cooperative intelligent transport services (C-ITS). Their architecture highlights the balance between edge and cloud layers in achieving scalable, low-latency vehicular data exchange within 5G-based C-V2X systems. Similarly, Coll-Perales et al. [14] investigated 5G enabled V2N2V architectures that support cross-stakeholder information sharing for cooperative driving, highlighting the role of network slicing and multi-operator coordination in future V2X ecosystems.

A critical consideration in deploying V2X communication over cellular networks is the selection of an appropriate application layer protocol capable of scaling with increasing vehicular data demands. MQTT, a lightweight publish–subscribe messaging protocol originally designed for IoT applications, has emerged as a promising candidate for V2X communication [15]. Extensive research has been conducted to evaluate MQTT’s suitability for vehicular applications, particularly in handling telemetry data transmission. Studies such as [15,16,17] analyze MQTT-based publish–subscribe architectures for transmitting vehicle telemetry data, often formatted in standardized message formats such as Cooperative Awareness Messages (CAM). Additionally, security considerations are a significant aspect of V2X communication, and research efforts like [18,19] explore methods to enhance MQTT security, ensuring safe and reliable transmission of critical vehicular data over open 5G networks.

While MQTT has been widely adopted for its lightweight publish/subscribe model, security remains a critical consideration, especially in vehicular networks where message integrity and confidentiality are paramount. To address these challenges, the incorporation of Transport Layer Security (TLS) has been investigated to enhance MQTT-based communication reliability and privacy. Gavriilidis et al. [20] conducted an empirical evaluation of TLS-enhanced MQTT implementations on IoT devices for V2X scenarios, demonstrating improved data protection with moderate computational overhead. Furthermore, Hmissi and Ouni [21] proposed TD-MQTT, a distributed multi-broker MQTT framework designed to improve scalability and fault tolerance—features that could be beneficial for large-scale vehicular communication systems with high data volume.

The integration of edge computing with 5G-based V2X is another area of active research, as edge-assisted solutions have been shown to significantly improve the performance of vehicular networks. Studies such as [22,23] investigate techniques that leverage Multi-Access Edge Computing (MEC) to facilitate low-latency data transmission in critical vehicular scenarios. Notably, [22] reported an 80% improvement in end-to-end latency when utilizing MEC hosts compared to conventional network architectures. These findings highlight the potential of edge computing in mitigating network congestion and ensuring faster response times for time-sensitive V2X applications.

Nguyen et al. [23] conducted an evaluation of the MQTT protocol in a simulated LTE network environment, focusing on its performance in vehicle-to-cloud communication. Their study involved testing a real cloud platform while handling highly scaled vehicle data generated from simulations. To assess system resilience and efficiency, they subjected the platform to extreme load conditions, simulating large-scale vehicular deployments with high message throughput. The evaluation aimed to measure key performance indicators such as message latency, packet loss, and scalability under heavy network and computational loads. Their findings provide insights into the feasibility of using MQTT for large-scale vehicular applications, particularly in scenarios requiring real-time data exchange between connected vehicles and cloud-based services.

ZeroMQ is widely adopted in industry due to its high performance and flexible messaging patterns. However, ZeroMQ has not received much attention in research works related to IoT and V2X communication. Most existing research focuses on well-established protocols like MQTT, CoAP, or REST-based architectures. While some works have explored ZeroMQ’s potential in simulation frameworks, industrial automation, and general-purpose asynchronous messaging [24,25], its performance, reliability, and resource efficiency in vehicular environments remain underexplored. Pilz [26] introduced the vehicleCAPTAIN middleware, which employs ZeroMQ as its core communication layer, demonstrating the viability of brokerless architectures for multi-interface vehicular communication and simulation frameworks.

2.2. Theoretical Background

While various research efforts have evaluated C-V2X performance at the physical (PHY) and sub-MAC layers [27,28], there remains a notable gap in studies focusing on the performance of application layer protocols like MQTT and ZeroMQ. MQTT has been widely used in IoT applications, whereas ZeroMQ has been extensively used in distributed computing systems. However, these protocols have not been sufficiently explored in V2X environments, particularly in terms of performance, scalability, and efficiency over 5G networks. Figure 1 presents the integration of V2X communication with MQTT and ZeroMQ over 5G network infrastructure.

2.2.1. 5G-Enabled Vehicle-to-Everything (V2X) Communication

5G, the latest leap in cellular technology, offers faster, more reliable, and low-latency connections than 4G/LTE, making it ideal for high-speed mobility scenarios. Although 6G research has begun, 5G deployment is still expanding worldwide. Its capabilities are crucial for Connected and Autonomous Vehicles (CAVs), allowing onboard units to maintain stable, high-speed connections and share vital traffic data in real time [29].

While LTE-V2X, introduced in 3GPP Release 14 and 15, marked a significant step in enabling direct and network-based vehicular communications, it offers some limitations in terms of latency, scalability, and QoS support [30]. In contrast, 5G-NR-V2X, introduced in 3GPP Release 16, offers enhanced capabilities such as QoS-aware resource allocation and advanced sidelink communication modes, providing up to 20% improvement in communication reliability and reducing power consumption by up to 95% compared to full-sensing approaches [31]. These improvements are crucial in ensuring safe and low-latency communication for connected and automated vehicles.

Table 1 lists the basic 5G parameters that aid V2X communication (Figure 2). Key 5G features enabling C-V2X include:

• Low Latency: essential for real-time communication.
• Massive MIMO: allows multiple vehicles to communicate simultaneously.
• Multi-access Edge Computing (MEC): improves response times by processing data near the edge.
• URLLC: ensures reliable and near-instantaneous communication.
• Network Slicing: creates dedicated virtual networks for V2X applications.
• Enhanced Security Mechanisms: encryption, authentication, and intrusion detection.
• AI/ML Integration: for predictive traffic management and anomaly detection.
• Seamless 6G Evolution: future integration with THz communication, AI-powered analytics, and quantum-secured networks [32].

Figure 2. V2X communication.

Figure 2. V2X communication.

With these 5G capabilities, modern vehicles equipped with radar, LiDAR, ultrasonic sensors, and cameras can exchange real-time data for safe and efficient operation.

Among the key technologies enabling V2X are DSRC (IEEE 802.11p) [33] and C-V2X). DSRC provides short-range low-latency communication, whereas C-V2X leverages cellular infrastructure for ultra-low latency, larger coverage, and high-speed mobility support [34,35]. Direct C-V2X includes V2V and V2I communication, while C-V2X also supports V2N communications over licensed spectrum [36,37].

Table 1. Key 5G parameters [38].

Parameters	Threshold Value
Latency in the air link	<1 ms
Latency in end-to-end (device to core)	<10 ms
Connection density	$100\times$ vs. 4G LTE
Area capacity density	1 (Tbits/s)/km2
System spectral efficiency	10 (bit/s)/Hz/cell
Peak throughput	10 Gbit/s
Energy efficiency	>90% improvement over LTE

Table 1. Key 5G parameters [38].

Parameters	Threshold Value
Latency in the air link	<1 ms
Latency in end-to-end (device to core)	<10 ms
Connection density	$100\times$ vs. 4G LTE
Area capacity density	1 (Tbits/s)/km2
System spectral efficiency	10 (bit/s)/Hz/cell
Peak throughput	10 Gbit/s
Energy efficiency	>90% improvement over LTE

2.2.2. MQTT Overview

To efficiently transmit the massive data generated by connected vehicles, lightweight messaging protocols such as MQTT are employed. MQTT is particularly well-suited for IoT and V2X environments, where bandwidth may be limited and network reliability can fluctuate [39]. It uses a broker-based architecture with a publish/subscribe model, enabling multiple subscribers to receive messages from publishing clients simultaneously. Figure 3 shows MQTT communication for V2X where each vehicle represents the MQTT client. These clients publish messages to the broker, and also subscribe to particular topics to receive messages.

MQTT uses Transmission Control Protocol (TCP), Quick UDP Internet Connections (QUIC), or WebSockets for reliable, secure communication. Clients publish to brokers under specific topics, and subscribers receive messages accordingly. To support real-time, low-latency updates, brokers avoid message storage. MQTT’s persistent sessions, QoS levels, and publish/subscribe model make it ideal for V2X applications, allowing infrastructure nodes to broadcast messages to multiple vehicles efficiently while ensuring reliable delivery [40].

2.2.3. ZeroMQ ($\varphi$MQ)

ZeroMQ is a high-performance asynchronous messaging library designed for building distributed or concurrent applications. It abstracts away low-level networking complexities, enabling developers to focus on application logic without worrying about socket management or network transport details. Figure 4 presents the work-flow of ZeroMQ. ZeroMQ is lightweight, highly efficient, and supports various messaging patterns, including Request-Reply, Publish-Subscribe, Push-Pull, Exclusive Pair, Pipeline, and Survey-Response. These patterns facilitate different communication scenarios, such as synchronous request-reply interactions, asynchronous message broadcasting, load balancing, direct point-to-point communication, processing pipelines, and gathering feedback from multiple participants [41].

ZeroMQ supports multiple transport protocols, including TCP, Inter-Process Communication (IPC), Pragmatic General multi-cast (PGM), and inter-thread communication, providing flexibility for different system architectures. Additionally, ZeroMQ offers built-in message queuing, automatic reconnection, and fault tolerance, ensuring robust communication even in unreliable network conditions. Its efficient design minimizes latency, making it well-suited for real-time applications such as financial trading, distributed logging, sensor networks, and parallel processing.

While messaging protocols like ZeroMQ provide efficient application-layer communication, the success of vehicular applications also depends on the underlying wireless communication standards. V2X communication has evolved significantly with the development of cellular technologies. Early vehicular communication research focused on DSRC, based on the IEEE 802.11p standard [33]. This stack, including IEEE 1609.x and SAE J2735 [43] was designed to support safety-critical V2V/V2I applications with low latency [34].

2.3. Comparative Studies on MQTT and ZeroMQ

Several studies have examined the performance of lightweight messaging protocols in IoT and vehicular communication environments, but direct comparisons between MQTT and ZeroMQ remain limited. A notable distinction is that, unlike MQTT, ZeroMQ does not require the presence of a broker, as it follows a decentralized approach. Gokhale et al. [44] evaluated Data Distribution Service (DDS), MQTT, and ZeroMQ under diverse IoT traffic conditions and found that while ZeroMQ achieved significantly lower latency and higher throughput, MQTT offered better reliability due to its broker-managed architecture. Similarly, Cleland et al. [45] analyzed multiple communication protocols, including MQTT, Advanced Message Queuing Protocol (AMQP) and ZMTP (the ZeroMQ transport layer) in edge-based federated learning settings and highlighted the trade-off between ZeroMQ’s low latency design and MQTT’s built-in delivery guarantees. Khalil et al. [46] provided a broader comparison of messaging protocols for IoT systems, concluding that ZeroMQ’s brokerless flexibility improves scalability in well-connected environments, while MQTT remains advantageous where ordered, reliable delivery is critical. However, despite these valuable insights, few works have explored MQTT and ZeroMQ within a unified 5G-enabled V2X simulation framework.

3. Methodology

To evaluate the performance of MQTT and ZeroMQ for V2X communication over 5G networks, we designed a simulation framework using the OMNeT++ network simulator. Figure 5 illustrates the overall system created for the simulation. The components and parameters depicted in Figure 5 are discussed in the subsequent sections. This section outlines the evaluation metrics employed, the designed scenarios, the tools used, and the implementation details of the protocols.

The presented framework illustrates simulation-based methods for V2X communication over a 5G network environment. It integrates two systems—MQTT-based and ZeroMQ-based—to evaluate communication performance among connected vehicles. In the MQTT system, vehicle nodes exchange data through a broker using the publish/subscribe mechanism, while the ZeroMQ system employs a direct PUB/SUB model for faster, broker-less communication. Both systems operate within a Simu5G network infrastructure, featuring multiple base stations (gNodeBs) and a 5G core with defined parameters for path loss, handover, and scheduling. SUMO traffic simulation models real-world vehicle mobility in the Erlangen urban environment, and an interface has been defined to integrate it with OMNeT++. The framework measures latency, throughput, and protocol overhead to compare the efficiency and reliability of both communication protocols under identical network and traffic conditions.

3.1. Defining the Evaluation Metrics

We defined several crucial metrics to evaluate the performance of the protocols. Below is a description of these metrics and their significance in evaluating overall performance.

• Latency: Latency refers to the measure of end-to-end delay of messages. For real-time communication, the system’s latency should be as low as possible. In experiments conducted with MQTT, latency was measured as client-to-server and server-to-client delay, where the server acts as the broker for the protocol. For ZeroMQ, end-to-end delay was measured as the round-trip latency from when a message was sent from the transmitting vehicle’s application layer until an acknowledgment was received from the receiving vehicle, encompassing network transmission, processing delays, and protocol overhead.
• Scalability: Measured as the rate of performance degradation when vehicle density increases from 10 to 80 vehicles. Specific metrics include: (i) the percentage of latency increase as the network load grows, (ii) the packet growth scaling factor (how many times more packets are generated), and (iii) the variation of communication delay under different densities. This quantifies each protocol’s ability to maintain performance under increasing network load.
• Protocol Efficiency: The efficiency of protocol overhead versus useful data transmission. As the number of vehicles increases, minimizing unnecessary control packets becomes critical for bandwidth-constrained vehicular networks. Protocol efficiency was analyzed by examining the growth patterns of total packets and identifying the overhead introduced by each protocol’s architecture.
• Reliability: The reliability of the system is defined by the number of successful message transfers under challenging network conditions. A reliable system exhibits greater efficiency even when facing packet errors and network impairments. The success rate of message delivery was monitored under the configured error rates.

3.2. Tools Used

To evaluate the performance of V2X communication over 5G networks, we utilized a simulation-based approach leveraging several established tools. The combination of these tools enables realistic modeling of vehicular mobility, network communication, and wireless channel characteristics. Below, we describe each tool used, its role in our research, and the specific version employed.

• OMNeT++ [47]: In this study, we employed OMNeT++ v6.0.3 as the primary simulation engine, coordinating the execution of various network components and enabling the integration of additional frameworks such as INET, Veins, and Simu5G.
• INET [48]: In this study, we employed INET v4.4.0 to model fundamental networking components, including IPv4/IPv6 communication, mobility management, and network-layer packet handling for V2X communications.
• Veins [49]: In our simulation setup, we employed Veins v5.2 to integrate vehicular mobility data from SUMO into the network simulation environment, ensuring accurate representation of vehicle movements and dynamic topology changes in V2X scenarios.
• Simu5G [50]: For this study, Simu5G v1.2.1 was used to simulate 5G connectivity for V2X communication. It provides comprehensive implementations of key 5G-specific features such as radio resource management, scheduling, beamforming, QoS handling, and mobility support.
• SUMO [51]: In this study, we used SUMO v1.8.0 to generate realistic vehicular mobility traces, which are then imported into OMNeT++ via Veins. SUMO provides microscopic and macroscopic mobility models that can be used to study traffic flow, congestion, and vehicle interactions.

By integrating these tools, our simulation framework enables a comprehensive analysis of V2X communication in 5G networks, considering both vehicular mobility and wireless network performance in realistic conditions. Figure 6 shows the integrated schematic of frameworks used for simulation.

3.3. Scenario Design and Simulation

The simulation environment is based on a realistic urban environment featuring buildings and heterogeneous road characteristics. We adapted the Erlangen city map, which is provided as part of Veins examples [49]. The scenario incorporates eight base stations, whose locations correspond to real GPS coordinates of the base stations in the simulation map [52].

Figure 7 shows the OpenStreetMap (OSM) representation of a portion of Erlangen city that was used for simulation. The SUMO traffic simulation tool converted the OSM data into a SUMO-compatible format. In the SUMO representation of the Erlangen map, shown in Figure 8, roads are represented by black lines, red markers indicate buildings, and blue markers indicate unknown landmarks. These red and blue infrastructures are responsible for the attenuation of signals.

3.4. Protocol Library Implementation

For the simulation of the two IoT protocols within the OMNeT++ environment, we implemented the protocols from scratch over the TCP/IP stack provided by the INET framework. The OMNeT++/INET simulation framework supports the creation of arbitrary application layer apps through its NED modules, the functionality of which is programmed in the C++ language. The basic implementation details for these protocols are described below.

3.4.1. MQTT Implementation

The MQTT library was implemented by following the approach taken in [53], which implements a similar protocol called MQTT-SN. The MQTT works on a broker-based architecture where a centralized broker acts as the layer of information from the message-generating source to the interested clients. Figure 9 shows the implementation structure of the MQTT library. The library follows the inheritance model, whereby the MqttApp base class contains functionalities common to both the client and the broker. The MqttBroker and MqttClient classes both inherit from the base class and implement their specific functionalities. Specifically, the MqttClient class implements two functionalities: Publisher and Subscriber. As a Publisher, the client sends Publish messages to the broker, whereas as a Subscriber, it sends subscription messages to the broker, and then receives the relevant published messages from the broker. The MqttClient also sends periodic Ping messages to the broker, which are required by the MQTT standard [54] as a form of keep-alive message.

3.4.2. ZeroMQ Implementation

The ZeroMQ protocol supports multiple messaging architectures. In our case, the library has been implemented over INET’s UDP sockets with a broker-less multicast messaging system. This design was chosen because it enables direct peer-to-peer data dissemination among vehicles, which aligns with the decentralized and latency-sensitive nature of V2X communication. The multicast-based publish–subscribe model allows multiple receivers to obtain relevant data simultaneously, without the need for a centralized broker, which reduces transmission delay.

Since there is no broker, the library is implemented with a single module (ZMQVehicleApp) running on the clients (car nodes). The module, upon initialization, joins a multicast group and subscribes to relevant topics. When messages are published on the multicast group by a client, every other client in the same group looks at that message and decides whether it is relevant or not based on its own subscription list. The ZeroMQ protocol defines no specific message format, only that messages consist of atomic frames. Each frame holds arbitrary data, along with a flag indicating if more frames follow. The pseudocode below outlines this structure.

• ZmqFrame {
•   bool more;
•   std::string data;
• };
• ZmqMessage {
•   std::vector<ZmqFrame> frames;
• }

3.5. Algorithmic View of the Work

Algorithm 1 outlines the methodology followed during the research. For each protocol, simulations were conducted under different vehicle densities. Algorithm 1 depicts the activities that have been done during each simulation.

The overall computational complexity of the simulation framework primarily depends on the number of vehicles (N) and simulation iterations (T). Each vehicle periodically exchanges messages with its neighbors, resulting in a communication overhead proportional to the average number of neighbors (k). Hence, the total time complexity can be approximated as:

$$\mathcal{O}(T\times N\times k)$$

Assuming an average neighborhood size that grows linearly with vehicle density, the complexity becomes $\mathcal{O}(T\times N^2)$ in the worst case. Memory consumption is dominated by message buffers and vehicle state data, leading to a space complexity of $\mathcal{O}\left(N\right)$.

Algorithm 1: V2X Performance Evaluation Framework

4. Experimental Setup

This section presents the experimental framework used to evaluate the performance of MQTT- and ZeroMQ-based V2X communication over a 5G network. The experiments aim to analyze the impact of different messaging protocols on network latency, throughput, and reliability under realistic vehicular mobility scenarios. The simulation framework integrates traffic modeling, wireless network simulation, and messaging protocols, allowing a comprehensive evaluation of protocol efficiency and system performance.

4.1. System Design Overview

The overall system architecture consists of two primary subsystems: the network simulation and the traffic simulation. The network simulation is implemented in OMNeT++ with Simu5G to emulate the 5G core network, including vehicle nodes, a standard host, and communication channels. The traffic simulation uses SUMO to model realistic vehicle mobility patterns. Synchronization between the network and traffic simulations is achieved via the TraCI interface, ensuring real-time updates of vehicle positions and network conditions.

4.1.1. MQTT System Design

The overall system design framework is presented in Figure 10. The system evaluates MQTT-based V2X communication over a 5G network by integrating network and traffic simulations. Each vehicle is equipped with an MQTT client, while a centralized broker manages the publish–subscribe messaging. Vehicle nodes communicate through the 5G core network, enabling message exchange with low latency and standardized payloads.

Traffic dynamics are modeled with SUMO, providing realistic mobility patterns. Synchronization between network and traffic simulations is achieved through TraCI, ensuring that vehicle movements influence network conditions and vice versa. This design allows the experiment to capture the impact of mobility on protocol performance under realistic V2X scenarios.

4.1.2. ZeroMQ System Design

The ZeroMQ setup mirrors the MQTT design but replaces the broker-based architecture with a brokerless, direct vehicle-to-vehicle messaging approach using multicast communication. Each vehicle runs the ZmqVehicleApp, exchanging messages directly over the 5G network.

The traffic simulation and synchronization with TraCI remain identical to the MQTT setup. This parallel design ensures a fair comparison, allowing us to evaluate protocol efficiency, latency, and scalability differences between MQTT and ZeroMQ in a controlled 5G V2X environment.

4.2. Simulation Parameters and Scenario Design

This section outlines the comprehensive simulation framework used to evaluate MQTT and ZeroMQ for V2X communication over 5G. The setup replicates a realistic urban scenario and includes accurate modeling of the wireless channel, mobility, and communication protocols. The overall ZeroMQ system design framewrok is presented in Figure 11.

4.2.1. Network Infrastructure and Topology

A 3000 m × 3000 m × 50 m urban area (Erlangen) is modeled with 8 gNodeBs and a full 5G core network, including strategic handover and broadcast support. Figure 12 represents the network topology with the base station in the respective positions. The network topology parameters, including core 5G parameters that were simulated, are listed in

Table 2. Network infrastructure and topology.

Component	Configuration Details
Base Stations	8 gNodeBs (urban coverage)
Core Network	5G Core: Server, Router, UPF
Backhaul Links	Eth10G (10 Gbps)
X2 Interface	Full mesh (28 links)
Handover Support	Enabled, 50 ms latency
Cell Broadcast	Every 1 s

. The 50 m represents the simulation space height but does not affect propagation calculations. OMNeT++ INET’s Log Normal Shadowing model operates in 2D based on horizontal distances. The vertical dimension serves primarily for coordinate system definition and node placement boundaries.

4.2.2. Wireless Channel Configuration

The simulation adopts a realistic mid-band 5G channel model with omnidirectional signal propagation and urban-specific path loss parameters. The mid-band spectrum is selected because it provides a balance between coverage and data rate, ensuring reliable communication in dense urban environments. Omnidirectional antennas are used to realistically emulate V2V and V2I communications, where signals propagate in multiple directions and are affected by multipath and reflections. Urban-specific path loss parameters account for the attenuation caused by buildings, vehicles, and other obstacles, making the simulation representative of real-world scenarios. 

Table 3. Wireless channel configuration.

Parameter	Value
Carrier Frequency	3.5 GHz (n78 band)
Bandwidth	100 MHz
Resource Blocks	25
Scheduling Algorithm	MAXCI
Propagation Model	Log Normal Shadowing Model
Path Loss Exponent	3
Signal Threshold	−90 dBm
UE Tx Power	26 dBm
gNodeB Tx Power	46 dBm
Antenna Pattern	Omnidirectional (360°)

lists out all the wireless channel configurations that were adopted for simulation purposes.

4.2.3. Vehicular Traffic Configuration

Vehicle mobility is driven by SUMO and Veins-INET using Erlangen’s road layout, realistic driving behavior, and per-vehicle routing. We simulated the microscopic model of the traffic flow, which is the default for SUMO [51]. The cars used in the simulation are User Equipment (UE) wrapped under the Veins framework, which adds the vehicular property to the UE. Also, the route and trips followed by each car are generated randomly using the script provided by SUMO [51]. The main configurations and parameters used for vehicular traffic are listed in

Table 4. Vehicular traffic configuration.

Parameter	Value
Vehicle Count	10, 40, 80
Mobility Model	Veins-INET + SUMO (microscopic)
Position Update Interval	0.1 s
Speed Distribution	30–50 km/h
Route Assignment	Randomly assigned by SUMO (unique paths)
Vehicle Behavior	Realistic acceleration/deceleration

.

4.2.4. MQTT Protocol Configuration

The MQTT protocol was implemented using a lightweight configuration for real-time V2X communication. Each vehicle in the simulation was assigned an MQTT client. The communication was conducted over the QoS 0 (“at-most-once”) delivery mode as defined in the MQTT v5.0 specification [54]. QoS 0 was selected because it represents the lowest-latency configuration with minimal protocol overhead—critical for real-time V2X applications. Under QoS 0, messages are transmitted once without acknowledgment or retransmission. This design choice allows a direct comparison of the brokered (MQTT) versus brokerless (ZeroMQ) architectures under identical low-latency conditions. The implications of higher QoS levels, which introduce acknowledgment and retransmission mechanisms, are discussed as future extensions in Section 6.

Furthermore, we implemented example topics such as hello, temp, and other. Standardized message payloads and topic structures were used across all vehicles. A channel error rate of 0.1 was introduced using the channelControl.packetBER parameter of OMNeT++ INET to simulate real-world channel effects, resulting in 10% error rate for transmitted packets. The persistent session with a 30-s keep-alive interval ensures that intermittent connectivity does not result in message loss while maintaining protocol efficiency. The publication and subscription intervals were set to 1 s to reflect typical telemetry reporting rates for cooperative awareness messages in real vehicular networks. Each message payload was limited to 100 bytes, and each vehicle handled three distinct topics, keeping communication lightweight and manageable even in dense urban traffic conditions. The reconnection and retransmission settings were configured to ensure robustness against temporary network disruptions. This setup allows a thorough evaluation of MQTT’s performance and resilience under practical V2X scenarios. Major configurations for the MQTT protocol are listed in

Table 5. MQTT protocol configuration.

Parameter	Value
Server Capacity	100 clients
Server Port	8000
Client Deployment	One per vehicle
Keep-Alive Interval	30 s
Session Type	Persistent (CleanSession = false)
Reconnection Interval	5 s
Publication Interval	1 s
Subscription Interval	1 s
Unsubscription Interval	10 s
QoS Level	0 (at-most-once)
Retransmission Attempts	3
Retransmission Interval	10 s
Payload Size	100 bytes
Topics per Vehicle	3
Topic Names	“hello”, “temp”, “other”
Publication Rate	1 message/sec
Channel Error Rate	0.1

.

4.2.5. ZeroMQ Protocol Configuration

Table 6. ZMQ protocol configuration parameters.

Parameter	Value
Client Deployment	One per vehicle
Destination Address	224.0.0.10
Destination Port	2000
Local Port	3000+index
Publish Interval	1 s
Publish Data Size	100 bytes
Subscribe Topics	“vehicle,sample”
D2D CQI Level	7
AMC Mode	D2D
CQI Reporting	Disabled

lists all the configurations used for the ZeroMQ vehicle. The same payload with the same size as for the MQTT protocol was used to maintain the consistency in the evaluation.

4.2.6. Simulation Control Parameters

To ensure reliability and statistical robustness, each simulation runs for 100 s with three random seeds.

Table 7. Simulation control parameters.

Parameter	Value
Simulation Duration	100 s
Random Seeds	0, 1, 2
Warm-up Period	Implicit
Metrics Collected	Latency, Throughput, Delivery Ratio
Data Recording	Vector and Scalar formats

defined the simulation control parameters.

5. Results and Analysis

In this section, we present the simulation results obtained from evaluating MQTT- and ZeroMQ-based V2X communication over a 5G network. We begin by analyzing MQTT performance, followed by ZeroMQ, and then provide a comparative discussion highlighting the trade-offs between brokered and brokerless communication in vehicular networks. The results are intended to uncover insights into latency, packet overhead, and overall protocol efficiency, which are critical for designing scalable and low-latency V2X systems.

5.1. MQTT Simulation Results

We first analyze the MQTT-based communication performance, focusing on packet transmission, size, and latency across different vehicle densities. MQTT, being a broker-based protocol, is expected to produce higher protocol overhead, which we aim to quantify through our simulation.

5.1.1. Packets Sent

Table 8. Average number of MQTT packets sent per vehicle.

Packet Type	10 Veh.	40 Veh.	80 Veh.
Subscribe Packets	3	3	3
Ping Packets	3.7	3.7	3.39
Publish Packets	90.1	89	83.15
Connect Packets	1	1	1

represents the different MQTT packets sent during the simulation period for different numbers of vehicles. The number of subscribed packets remains constant at three because we implemented three different examples of topics hello, temp, and other. The trips used in the simulation are generated randomly using the script provided by SUMO [51], which can cause the vehicles to reach the destination before the simulation time has been completed. That is why the number of Ping and Publish packets varies randomly. Also, one average connect packet is used to establish the connection, which also implies that there has been no connection breakdown in the simulation.

5.1.2. Packet Size

Table 9. Size of different MQTT packets used in simulation.

Metric (Bytes)	10 Veh.	40 Veh.	80 Veh.
Average Subscribe Packet Size	9.66667	9.66667	9.66667
Average Ping Packet Size	2	2	2
Publish Packet Size (Min)	108	108	108
Publish Packet Size (Max)	109	109	109
Average Connect Packet Size	26.7	22.85	24.518519

lists the size of different packets used in the MQTT simulation. The average size of the Subscribe Packet observed is 9.67 bytes. It can be calculated theoretically by subscribing to three different topics (hello and other with a size of 5 bytes and temp with a size of 4 bytes. The MQTT Subscribe packet contains a 2-byte fixed header, a 2-byte packet identifier, and for each subscribed topic: a 2-byte topic length field, the topic name, and a 1-byte QoS field. This results in 9 bytes (2 + 2 + 4 + 1) for the temp topic and 10 bytes (2 + 2 + 5 + 1) for each of the hello and other topics. The complete Subscribe packet totals 23 bytes (2 + 2 + 9 + 10 + 10) for all three topic subscriptions. On averaging the total size (10 + 10 + 9)/3 results in an average size of 9.67 bytes for MQTT subscribe packets. The Ping Packet has a size of 2 bytes as per the MQTT standard.

We implemented MQTT with the payload size of 100 bytes, mentioned in Table 5, and 3 topics (hello and other have a size 9 bytes, and temp has a size 8 bytes). That is why the minimum size is 108 bytes, and the maximum size is 109 bytes for the Publish Packet. With QoS 0, Publish packets do not include a packet identifier, so the structure consists of a 2-byte fixed header, 2-byte topic length field, the topic name (4 bytes for temp or 5 bytes for hello/other each), and the 100-byte payload, totaling 108 bytes for temp and 109 bytes for the other topics (hello and other each).

5.1.3. Latency Measurement

The value of client-to-server and server-to-client latency observed during simulation is listed in

Table 10. Latency metrics for different vehicle densities (MQTT).

Metric (s)	10 Veh.	40 Veh.	80 Veh.
Client-to-Server Latency (s)	0.01727	0.01721	0.01730
Server-to-Client Avg Latency (s)	0.01634	0.01933	0.02034

. The server-to-client latency trend is increasing with the number of vehicles being increased, while the client-to-server latency almost remains the same. Variations due to the wireless channel fading model can occasionally produce outlier latencies by causing packet errors or slower transmission rates. Additionally, higher vehicle density leads to increased network congestion and longer broker processing times, further increasing the latency.

5.1.4. Total Packets Exchanged

The total packets exchanged between the client and server are listed below in

Table 11. Total packets exchanged for different vehicle densities (MQTT).

Metric	10 Veh.	40 Veh.	80 Veh.
Total Client Packets	897	3533	6673
Server Packets Total Sent	8302	129,117	461,221

. The trend is expected to increase as the increase in the number of vehicles will lead to an increase in the data exchanged to be increased.

5.2. ZeroMQ Simulation Results

Table 12. ZeroMQ Performance metrics for different vehicle densities.

Metric	10 Veh.	40 Veh.	80 Veh.
Total Packets Sent	1314	10,289	43,257
Average Latency (s)	0.00958	0.01484	0.01678

represents the metrics that were observed in the ZeroMQ simulation results. The average latency is increasing with the number of vehicles; however, several factors other than vehicle densities, like the randomly created trips and destinations for the cars in the simulation, may influence the latency measured.

5.3. Comparative Analysis

After evaluating MQTT and ZeroMQ individually, we now present a comparative analysis to understand the relative strengths and weaknesses of brokered versus brokerless V2X communication. By systematically comparing these protocols across increasing vehicle densities, we aim to uncover how each approach scales, how network load influences performance, and which protocol is more suitable for low-latency, high-density vehicular environments. The results provide actionable insights for selecting messaging architectures tailored to specific V2X applications.

5.3.1. Delay Analysis

Figure 13 presents a comparison of communication delays between MQTT and ZeroMQ for 10, 40, and 80 vehicles. ZeroMQ consistently shows lower average delay across all densities, with approximately 61.8% lower latency compared to MQTT.

The MQTT delay increases markedly with an increase in vehicle density, especially on the server-to-client path. This indicates the broker-side processing overhead. In contrast, ZeroMQ delay appears to be more stable and asymmetric. This might be because of ZeroMQ’s broker-less architecture, which overcomes the processing overhead as in MQTT.

This comparison highlights ZeroMQ’s suitability for low-latency, real-time V2X applications, whereas MQTT, despite its reliability and structured communication, may introduce higher delays under dense network conditions.

5.3.2. End-to-End Latency Analysis

Figure 14 illustrates the end-to-end latency trends for MQTT and ZeroMQ across increasing vehicle densities (10, 40, 80 vehicles). The results show that MQTT experiences a moderate performance degradation of around 12.0%, while ZeroMQ shows a more significant increase in latency, degrading by approximately 75.2%.

Despite this, ZeroMQ still maintains lower absolute latency values at each data point, confirming its efficiency in light-load scenarios. However, the steep increase in ZeroMQ’s latency suggests scalability limitations under high vehicle counts, whereas MQTT exhibits more stable latency growth.

This comparison indicates that while ZeroMQ is ideal for low-latency use cases in smaller networks, MQTT may offer better consistency and resilience in large-scale vehicular systems.

5.3.3. Packet Overhead Analysis

Figure 15 compares the growth in the total number of packets exchanged by MQTT and ZeroMQ as the number of vehicles increases. MQTT exhibits exponential packet growth, scaling by 55.6 times, while ZeroMQ grows more linearly, scaling only by 32.9 times.

This indicates that MQTT generates significantly more overhead, which is associated with MQTT’s different control packets and its broker-based architecture. In contrast, ZeroMQ demonstrates better scalability, with 1.7 times more efficient growth in packet volume.

In general, ZeroMQ is found to be lighter and more bandwidth-efficient. This helps light-weight, bandwidth-efficient V2X systems, where minimizing network load is critical.

5.3.4. Protocol Efficiency Analysis

Figure 16 presents a comparative analysis of total packet transmission for MQTT and ZeroMQ across different vehicle densities. While MQTT shows higher total packet counts (7687 packets/sec at 80 vehicles vs. 721 for ZeroMQ), this difference primarily reflects protocol overhead rather than superior performance.

As demonstrated in our packet overhead analysis (Figure 15), MQTT exhibits exponential packet growth (55.6× scaling) due to its broker-based architecture requiring extensive control packets (connect, subscribe, ping). In contrast, ZeroMQ’s broker-less design results in more linear growth (32.9× scaling) with minimal protocol overhead.

The higher packet counts for MQTT correlate with the increased communication delays observed in Figure 13, where ZeroMQ maintains 61.8% lower latency. This indicates that MQTT’s additional packets represent overhead rather than useful data transmission.

These findings suggest that ZeroMQ provides a more efficient communication mechanism, particularly in bandwidth-constrained V2X scenarios where minimizing protocol overhead is essential for reliable and low-latency performance. The results underscore the importance of selecting protocol architectures aligned with the operational requirements of vehicular networks.

5.3.5. Overall Comparative Summary

The overall results indicate that MQTT offers better reliability and message delivery assurance due to its broker-based architecture, making it suitable for safety-critical V2X applications. In contrast, ZeroMQ achieves lower latency and higher scalability through its broker-less design, performing better in delay-sensitive and high-load scenarios. In summary:

• MQTT: Higher reliability, moderate latency, limited scalability.
• ZeroMQ: Lower latency, high scalability, less built-in reliability.

The choice between MQTT and ZeroMQ depends on application needs—MQTT for dependable delivery, ZeroMQ for real-time responsiveness.

6. Conclusions and Future Work

As we move towards sophisticated vehicular application scenarios, solid communications support is an essential requirement to enable all sorts of services. In this context, the C-V2X paradigm, enabled by 5G technology, emerges as the most current and best-performing approach. Yet, in these contexts, a high volume of real-time vehicle data must be transmitted through the network as efficiently as possible, and it is unclear which messaging architecture is more suitable.

Hence, in this work, we focus on the performance of the message distribution layer, a topic that has remained mostly untackled in the literature. To this end, we developed a full simulation framework embracing multiple components to perform simulations in realistic vehicular environments, specifically in urban scenarios. We developed and integrated both MQTT and ZeroMQ protocols in our vehicular framework and assessed their performance under different scenarios. Experiments showed that the ZeroMQ protocol can deliver messages with much less end-to-end latency. This can be attributed to the fact that it uses a broker-less architecture, whereby published messages go directly to the interested clients instead of going through a middleman (broker). Furthermore, the protocol overhead of ZeroMQ is minimal in comparison to MQTT.

Limitations and Future Recommendations

However, because of its broker-less architecture, it is difficult to scale the ZeroMQ protocol with a higher number of vehicles. Since every vehicle joins a common multi-cast domain, the packets for irrelevant messages will also be delivered to them, and the clients have to filter out relevant messages themselves. This creates unnecessary congestion in the network. This phenomenon can be somewhat avoided by using a different multi-cast address for different topics, which again raises further scalability concerns. Overall, with a small number of vehicles, the ZeroMQ protocol appears to be superior, as it can facilitate low-latency communication. However, as the number of vehicles increases, the MQTT protocol can be used to scale up the system, even though it suffers from latency issues. Another solution that can be applied is to use IPv6 addressing, which provides a much larger multi-cast address space than IPv4. With this, the ZeroMQ multi-cast domains can be mapped to unique publish topics without scalability issues. Future deployments could leverage Multi-access Edge Computing (MEC) nodes to reduce MQTT broker latency by distributing processing closer to vehicles. MEC-enabled MQTT architectures could potentially bridge the performance gap observed in this study while maintaining centralized coordination benefits.

This research work lacks the implementation of QoS levels other than QoS-0 for MQTT protocols. While communication protocols are studied, the impact of MEC and distributed intelligence on CAV performance is not deeply analyzed. Future work can extend the simulation framework to incorporate 6G networks, leveraging terahertz (THz) communications, AI-driven networking, and ultra-reliable low-latency communication (urLLC) for enhanced V2X performance.