Latency Analysis of Push–Pull and Publish–Subscribe Communication Protocols in U-Space Systems ^†

Abstract

In the U-Space environment, seamless communication between key stakeholders—such as U-Space Service Providers (USSP), Common Information Service Providers (CISP), and drone operators—is very important for the safe and efficient management of Unmanned Aerial Vehicle (UAV) operations. A major challenge in this context is minimizing communication latency, which directly affects the performance of time-sensitive services. This study investigates latency issues by evaluating two communication protocols: push–pull (using REST-API and ZeroMQ) and publish–subscribe (using AMQP and MQTT). Through a case study focused on drone detection, the research examines latency across critical operational activities, including conformance monitoring, flight plan confirmation, and the transmission of alerts via the USSP system under varying message intervals and payload sizes. The results indicate that while message interval has a significant influence on latency, message size has a minimal effect. Furthermore, the push–pull protocols consistently deliver lower and more stable latency compared to publish–subscribe protocols under the tested conditions. Both approaches, however, achieve latency levels that align with EASA’s operational requirements for U-Space systems.

1. Introduction

The rising presence of Unmanned Aerial Vehicles (UAVs) in airspace for commercial, public safety, and recreational operations—especially in urban and restricted areas—poses new challenges to airspace security. To ensure safe and reliable drone operations, it is essential to establish efficient communications among UAV operators, U-Space Service Providers (USSPs), and drone detection systems. U-Space refers to the set of services, procedures, and infrastructures that enable the safe integration of drones into civil airspace, encompassing registration, authorization, intrusion detection, and traffic management. In practical terms, mitigating potential harm depends on rapidly identifying intrusions into restricted airspace and immediately transmitting that information to the responsible operator or authority. The AI4HyDrop project [1], for instance, develops automatic drone detection and real-time notification solutions, underscoring the importance of low-latency, highly reliable communication mechanisms in U-Space service chains.

Although there are various studies on secure, low-delay communications in UAV scenarios—including performance analyses of 4G networks for drones [2], elliptic-curve-based cryptographic protocols [3], latency-guaranteed mechanisms for BVLOS operations [4], data-sharing APIs for drone identification [5], and investigations of MQTT in multi-drone scenarios [6]—empirical evaluations that directly compare push–pull protocols and publish–subscribe protocols within U-Space service chains remain lacking. Furthermore, it is unclear whether these approaches satisfy the EASA’s stringent latency requirements for time-sensitive U-Space services. To address this gap, we present a case study measuring the end-to-end latency of four representative protocols (REST-API, ZeroMQ, AMQP, and MQTT) in a realistic intrusion-notification scenario from a drone detection system to a U-Space Service Provider. Our objective is to quantify and compare latency behaviors under realistic conditions and evaluate compliance with EASA delay limits for time-sensitive U-Space services.

The manuscript is organized as follows. Section 2 reviews related work on UAV communications and U-Space latency requirements, followed by studies on latency optimization in distributed systems. Section 3 describes the experimental scenario and latency measurement methodology. Section 4 presents the results, and Section 5 discusses their implications for protocol selection in U-Space services. Finally, Section 6 concludes and suggests future directions.

2. Literature Review

Early studies have emphasized the importance of secure and low-latency communication for UAV systems. Some contributions include analyses of the performance of 4G networks employed in drone communications [2]; proposals of elliptic-curve-based cryptographic protocols to ensure data confidentiality and integrity in UAV networks [3]; investigations into latency-guaranteed mechanisms for aircraft control in beyond-visual-line-of-sight (BVLOS) operations [4]; studies on data sharing via Application Programming Interfaces (APIs) aimed at drone identification [5]; and explorations of the Message Queuing Telemetry Transport (MQTT) protocol in multi-drone communication scenarios [6]. Additionally, decentralized swarm communication algorithms for efficient task allocation and power consumption in swarm robotics [7], hybrid Cellular Potts and Particle Swarm Optimization models for energy and latency optimization in edge computing [8], and peer-to-peer topology optimization in blockchain-based Industrial IoT networks to reduce propagation latency [9] have been investigated in related distributed systems domains.

For distributed communication systems, the Advanced Message Queuing Protocol (AMQP) has proven to be a practical option, particularly in critical industrial settings and Internet of Things (IoT) networks. The protocol’s original purpose was to oversee high-integrity commercial transactions in the banking sector. Its architecture, based on exchanges, queues, and bindings, promotes interoperability and modularity [10]. This structure makes message management scalability and dependability possible, which is especially helpful for systems that require high security and integrity. Its applicability for corporate applications and critical contexts is further supported by recent research that shows its effectiveness in high-density networks and its capacity to manage varying message sizes [11].

Because AMQP can retain messages until they are used, it has proven to be more resilient than MQTT in challenging situations, such as high latency and packet loss. AMQP performs exceptionally well in complicated workloads and activities that value reliability, whereas MQTT is more effective in low-latency situations [12]. In addition to enhancing the protocol’s performance and adaptability in distributed systems, real-world implementations such as RabbitMQ and ActiveMQ facilitate cloud solutions and on-premises settings [13]. These elements make AMQP a wise option for systems that need reliable and secure communication.

The communication protocols employed in communication are critical to the performance and scalability of UAVs and IoT networks, especially in low-latency and high-reliability applications. AMQP, MQTT, and Constrained Application Protocol (CoAP) protocols have been researched extensively due to their varying characteristics. MQTT, for example, is well-known for its simplicity and efficiency on low-bandwidth and high-latency networks and is utilized in Internet of Things applications [14,15]. However, because AMQP offers additional resilience and advanced features to ensure message delivery in critical systems, it stands out when message integrity and storage are critical [16,17]. According to research assessing hybrid scenarios and the shortcomings of individual protocols, the best protocol should be chosen after taking into account the system’s characteristics and the particular message needs [17].

In order to satisfy real-time needs in industrial and Internet of Things systems, recent developments have investigated the integration of new technologies with established protocols. To better adapt to industrial applications that demand transmissions with specified delays, PrioMQTT, a modification of MQTT, for instance, offers message priority features. Simultaneously, the creation of hybrid protocols, like the one suggested for the Internet of Flying Things (IoFT), combines the advantages of Micro Air Vehicle Link (MAVLink) and MQTT to enhance communication in systems involving UAVs, providing notable enhancements in processing time, latency, and network throughput [15]. Furthermore, strategies like extending Apache Pulsar (ePulsar) show how publish/subscribe-based systems may be tailored for geo-distributed edge infrastructures, lowering latency and enhancing performance like drone coordination [18].

In addition to the protocols already discussed, ZeroMQ is a lightweight asynchronous messaging library that supports publish–subscribe, push–pull, and request–reply patterns without a centralized broker. Comparative studies show that this peer-to-peer architecture can markedly reduce latency and increase throughput in high-frequency exchanges, outperforming MQTT and approaching DDS performance when packets are small, or many nodes communicate concurrently [19]. Its simple API and low resource footprint make ZeroMQ an attractive choice for embedded systems—such as the drone-detection sensors examined in this work—yet the lack of built-in persistence and load balancing means that reliability, authentication (e.g., CurveZMQ), and flow control must be provided at higher layers or through additional configuration [20].

Finally, there are unique difficulties when using communication protocols in UAVs managed by cellular networks. Drone telemetry and BVLOS control are now possible thanks to protocols like MQTT that have been modified to function with mobile technologies like 4G and 5G [21]. However, operations’ responsiveness and safety may suffer due to the delay that mobile networks introduce. In addition to suggesting methods to minimize the effects by optimizing protocols and integrating them with modern networks, recent research has looked into techniques to quantify and simulate these delays [21,22]. These advancements are still required to ensure that communication channels satisfy the expanding demands of airspace real-time operations.

In the context of UAV communication requirements, it is useful to juxtapose the four protocols evaluated in this work: REST-API and ZeroMQ, as representatives of push–pull approaches, and AMQP and MQTT, as representatives of publish–subscribe approaches, highlighting their respective strengths and trade-offs.

Table 1. Comparison of protocols used in this study.

Feature	REST-API	ZeroMQ	AMQP	MQTT
Pattern	Push–Pull	Push–Pull	Pub–Sub	Pub–Sub
Technology	HTTP/HTTPS	TCP	TCP	TCP
Broker	No	No	Yes	Yes
Message overhead	High (HTTP headers, handshakes)	Very low (no headers, raw sockets)	Medium to high (framing + broker)	Low (optimized for small payloads)
Process	Synchronous	Asynchronous	Asynchronous	Asynchronous
Security	TLS native	Must add manually	TLS via broker	TLS via broker

provides a concise comparison of these protocols in terms of messaging pattern, underlying transport technology, broker dependency, message overhead, synchronization model, and built-in security support. This overview illustrates how REST-API and ZeroMQ differ in terms of simplicity, latency potential, and infrastructure needs compared to AMQP and MQTT, which offer richer broker-based features and delivery guarantees at the cost of additional overhead. By situating these characteristics side by side, the reader gains immediate insight into why certain protocols may be preferable for specific U-Space functions, such as low-latency onboard command and control versus reliable backend data analysis, thereby motivating the experimental evaluation that follows.

Prior studies have consistently emphasized the critical role of secure and low-latency communication in UAV operations, particularly for beyond-visual-line-of-sight (BVLOS) missions. Early contributions have explored the use of 4G networks for drone communication, introduced elliptic-curve cryptographic protocols for data security, and proposed latency-guaranteed mechanisms for UAV control. Application Programming Interfaces (APIs) have been used for drone identification, while MQTT has been investigated for multi-drone coordination due to its simplicity and suitability for constrained networks. AMQP, originally developed for the financial sector, has demonstrated high reliability and message persistence, making it effective for critical systems and varying message sizes. ZeroMQ has gained attention for its brokerless, low-latency architecture suitable for edge computing and embedded UAV systems, though it lacks native persistence and flow control. Furthermore, hybrid protocol designs—such as MAVLink with MQTT for the Internet of Flying Things (IoFT), PrioMQTT for prioritized messaging, and ePulsar for geo-distributed publish–subscribe systems—have shown improvements in latency, throughput, and scalability. Finally, studies integrating these protocols with mobile networks like 4G and 5G highlight both the potential and limitations of cellular infrastructure in supporting responsive UAV communication.

Despite the advancements, several gaps remain that necessitate further investigation. Most existing studies focus on specific protocols or applications, lacking comparative performance evaluations under uniform conditions, particularly across MQTT, AMQP, ZeroMQ, and REST-API. Moreover, current research does not adequately address communication requirements specific to U-Space environments, such as those involving drone detection, conformance monitoring, and alert dissemination. There is also limited analysis of protocol performance across varying payload sizes and message intervals—factors critical for real-time UAV operations with bursty data patterns. While ZeroMQ shows promise for decentralized sensor systems, the trade-offs between brokered (e.g., AMQP) and brokerless (e.g., ZeroMQ) architectures in UAV detection frameworks remain underexplored. Additionally, few studies evaluate how these communication protocols perform in edge-to-cloud architectures typical of drone detection services, where low latency, high throughput, and message integrity must be balanced across distributed system components. These gaps highlight the need for a systematic analysis of communication protocols tailored for real-time, reliable, and scalable UAV communication in U-Space systems.

3. Methodology

This study centers on analyzing the communication latency of two types of protocols, which are push–pull and publish–subscribe, in delivering warning messages from the drone detection system to the U-Space Service Provider (USSP). Within the AI4HyDrop project, the proposed drone detection framework can identify both cooperative and non-cooperative drones using AI-driven detection algorithms, as illustrated in Figure 1 [1]. The system integrates multiple sensors including cameras, microphone arrays, and radio frequency antennas to gather data on drones operating near restricted airspace. These data serve as input for deep learning algorithms, which require extensive training datasets to accurately detect various drone models.

In this framework, the drone detection service can either be integrated into the USSP’s services or provided by a third-party service linked to the USSP. The USSP, as defined by regulations and described by Barrado et al. (2020), offers essential services to UAS operators to support their flight operations [23]. Additionally, the framework includes the Common Information Service Provider (CISP) as another key U-Space component. In this research, an extended definition of CISP is applied, since current regulations, as noted by EASA (2024), do not yet encompass the capability of managing drone flight plans (U-Plans) under CISP’s responsibilities [24].

Figure 1. Drone detection framework [25].

Figure 1. Drone detection framework [25].

This research identifies three case studies related to drone detection:

a.

Cooperative drones are authorized to fly into restricted airspace.

In this scenario, a drone is detected by sensors flying near a restricted airspace, and its location is estimated. The system receives the broadcast remote ID data, which includes the drone’s ID and position. The detection system then connects to the Extended CISP to retrieve flight plan authorization data. Upon confirming that the drone is authorized to operate within the restricted airspace, the case is considered resolved with no further action needed.

b.

Cooperative drones are not authorized to fly into restricted airspace.

Here, a drone is similarly detected by sensors near restricted airspace, and its location is determined. The system receives its broadcast remote ID data, including the drone ID and location. Upon connecting to the Extended CISP, the detection system finds that the drone is not authorized to enter the restricted airspace. Consequently, a warning level 1 message—containing the drone’s ID and location—is sent to the USSP to alert the operator to avoid the restricted area. If the drone operator commands the drone to return to its planned path, the incident is closed. However, if the drone continues moving closer to the restricted zone, it is then classified as a non-cooperative drone (see case study number c below).

c.

Non-cooperative drones are flying into restricted airspace.

In this case, a drone is detected flying near restricted airspace and its position is estimated, but no broadcast remote ID data are received—either because it is a non-cooperative drone, or it evolved from case number b. A level 2 warning is then issued, which includes the drone’s location. This message is sent to the USSP to alert all nearby operators, initiate any necessary tactical deconfliction measures, and inform security personnel to take appropriate actions.

The push–pull protocol is a request–response model where the client (drone detection system) “pushes” a message to the server (USSP) by initiating a request. The server then “pulls” the data, processes them, and sends a response back to the client [26]. In this study, the REST-API (Representational State Transfer—Application Program Interface) and ZeroMQ protocols are utilized for sending messages in the push–pull protocol because of its wider usage in website or application. The REST-API protocol is based on the universal HTTP (Hypertext Transfer Protocol) protocol, and the information is usually returned in the JSON (JavaScript Object Notation) format that almost all the programming languages can read with the schematic diagram as shown in Figure 2. There are 4 types of possible commands that can be used including GET (retrieve data), POST (create new data), PUT (update data), and DELETE (remove data) [27].

ZeroMQ is a high-performance asynchronous messaging library that enables scalable, brokerless communication through various messaging patterns, including push–pull. In the push–pull pattern, a Ventilator component pushes tasks to multiple Worker nodes using the PUSH socket while each Worker pulls tasks using a PULL socket. This design achieves load-balanced parallel processing, as tasks are distributed evenly across workers, as shown in Figure 3.

Once a Worker processes a task, it sends the result using its PUSH socket to a Sink, which collects results through a PULL socket. This one-way message flow from Ventilator to Workers to Sink eliminates the need for a central broker, reduces latency, and allows for scalable and decoupled task distribution. This pattern is ideal for distributed task processing pipelines where throughput and responsiveness are key [28].

The publish–subscribe protocol is based on an event-driven model where the USSP subscribes to specific events (such as a warning message from the drone detection system). The drone detection system acts as the publisher and publishes the event to the subscribers whenever an event occurs [26]. In this study, the AMQP and MQTT protocols are used to represent the publish–subscribe protocol because of its broad usage in business and commercial applications and its ability to perform message orientation, queuing, switching reliability, and security [29]. The structure of AMQP protocol is shown in Figure 4 which consists of publishers, the broker, and subscribers. Inside the broker, the exchange functions receiving publishers’ messages and adding them to the queue. Then, the queues send messages to subscribers.

MQTT is a lightweight, publish–subscribe protocol designed for low-bandwidth, high-latency, and unreliable networks, making it ideal for IoT, UAV communication, and drone operations. It operates using a broker-based architecture, where publishers send messages to topics and subscribers receive updates from those topics as shown in Figure 5. MQTT supports three Quality of Service (QoS) levels, QoS 0 (fire-and-forget), QoS 1 (at least once delivery), and QoS 2 (exactly once delivery), ensuring reliable communication across various network conditions [30].

In the experiment, the information sender is a computer running a Python script version 3.11.9 at the University of South-Eastern Norway, Kongsberg campus. The information receiver is the DLR U-Space Research Environment (DURE), hosted on Amazon Web Services (AWS) cloud servers in Frankfurt, Germany, and running on an Amazon Linux server instance. In the REST-API experiment, POST command is used to send a message to the server. While for ZeroMQ experiment, PUSH command is used to send a message to the server via NGROK gateway. Similarly, in the AMQP and MQTT experiments, the CloudAMQP with the free “Litle Lemur” plan is used as the broker. The used message format in JSON is shown in Figure 6, which consists of the drone ID of detected drone, timestamp of the event, warning type and warning level of the drone detection, location of detected drone including latitude, longitude, and relative altitude (height), reasoning of the warning, and token for security of connection.

The latency as the dependent variable of experiment is defined as the time taken from the moment the warning message is generated by the drone detection system until it is received by the USSP system. However, since the clocking time between server and computer is not always the same and the latency measurement requires very precise clocking, the latency is calculated by the difference in time when the data are sent, and the acknowledgement is received, then divided by two.

The independent variables are the sending interval (1 s, 0.5 s, 0.1 s, and 0.01 s) to represent the number of drones approaching the restricted area and the message size (small: 325 bytes, medium: 2580 bytes, and large: 4880 bytes) to represent the information quantity that needs to be delivered by multiplying the reasoning text. The test is conducted in a batch of 100 messages for each combination of interval and message sizes to avoid being detected as a cyberattack. In total, there are 10 batches of experiments for each protocol executed during January–April 2025. In total, 48,000 data points are collected.

To assess the distribution of the data, a normality test, such as the Shapiro–Wilk test, is conducted to determine whether the residuals follow a normal distribution. Additionally, a homogeneity of variances test, such as Levene’s test, is performed to evaluate if the variances across groups are equal [31].

Based on these assessment results, the appropriate statistical parameters are selected to represent the data. When the assumptions of normality and homogeneity of variances are confirmed, the mean and standard deviation will be used. Meanwhile, when the assumptions are violated, the median, and interquartile range (IQR), which is the range between the 25th and 75th percentiles, will be used in the analysis because they are not influenced by extreme outliers or skewness of data distribution.

4. Results and Analysis

4.1. Data Distribution Analysis

To check the assumption on the normality of data and the homogeneity of variance, the Shapiro–Wilk test and Levene’s test are conducted, and the results are shown in

Table 2. Result of normality and homogeneity of latency data.

Protocol	Shapiro–Wilk Test		Levene’s Test
	Test Statistic	p-Value	Test Statistic	p-Value
REST-API	0.97193	4.47957 × 10−43	10.36336	8.29229 × 10−7
ZeroMQ	0.08319	3.13331 × 10−118	3.32261	0.01887
AMQP	0.20215	2.77060 × 10−114	8.14282	2.05649 × 10−5
MQTT	0.46216	2.92306 × 10−104	2070.83529	0.0

, where the unit of test statistic and p-values are dimension-less and ranged between 0 and 1. For all the latency data of the REST-API, ZeroMQ, MQTT, and AMQP protocols, the Shapiro–Wilk test resulted in extremely small p-values (significantly below a typical threshold of 0.05), indicating that the residuals for both data do not follow a normal distribution. Similarly, the p-values from Levene’s test were also very small, suggesting that the variances of latency data are not homogeneous, thereby violating the assumption of equal variances. Given these violations of both normality and homogeneity assumptions, the median, and the IQR is analyzed to represent the data. The finding is confirmation from our previous research on the latency of API and AMQP-based protocols [32].

4.2. Latency Analysis

Figure 7, Figure 8, Figure 9 and Figure 10 represent the latency statistics of the REST-API, ZeroMQ, AMQP, and MQTT protocols, respectively, with selected intervals and payload sizes. It shows similar latency for intervals of 100 ms, 500 ms, and 1000 ms. However, a notable increase in latency occurs at the 10 ms interval, indicating that this interval may be nearing the receiver server’s capacity to handle warning messages, leading to performance degradation. Exceptions occur in the ZeroMQ protocol, where there are no significant differences across all message intervals.

The observed latency behavior can be explained by considering how each communication protocol and the used system infrastructure manage message throughput and processing under different conditions. For REST-API, AMQP, and MQTT, the similar latency levels at 100 ms, 500 ms, and 1000 ms intervals suggest that the message rates at these intervals fall within the acceptable handling capacity of the receiver server. These intervals provide sufficient time for the server to process and respond to incoming messages without introducing significant delays.

However, when the message interval is reduced to 10 ms, the system requires the processing of 100 messages per second, which significantly increases the processing load. This higher frequency can lead to message queuing, increased I/O contention, or thread scheduling delays, especially in protocols like REST-API and AMQP, which rely on more resource-intensive mechanisms such as HTTP requests or message broker intermediaries. As a result, the server begins to approach its processing threshold, causing latency to rise sharply due to resource saturation or internal buffer overflows.

In contrast, ZeroMQ demonstrates stable latency across all tested intervals, including 10 ms. This can be attributed to its lightweight, brokerless architecture and asynchronous messaging model, which is designed for high-throughput and low-latency communication. ZeroMQ’s efficiency in handling high-frequency message streams without relying on intermediaries allows it to maintain consistent performance even under increased load, making it less susceptible to the performance degradation observed in the other protocols.

Another finding is that payload size does not significantly affect latency across most protocols, except for MQTT. This behavior is expected in protocols like REST-API, AMQP, and ZeroMQ, which are generally designed to handle variable payload sizes efficiently through mechanisms such as buffering, chunked transfers, or efficient binary serialization. These protocols tend to have a relatively fixed processing overhead, meaning that small increases in payload size do not translate into proportionally higher latency, especially within the modest payload ranges used in this experiment.

However, in the case of MQTT, latency increases with larger payloads. This can be attributed to MQTT’s design as a lightweight publish–subscribe protocol optimized for low-bandwidth, low-power devices. MQTT introduces higher overheads when managing larger payloads due to increased processing time for encoding, transmission, and potential Quality of Service (QoS) mechanisms, especially when using higher QoS levels that require acknowledgments or retry. Additionally, broker-side buffering and client-side message handling can further add to the latency when payload sizes increase.

Also, the boxplot analysis of latency for AMQP reveals a greater number and magnitude of outliers compared to the other protocols. This variability in latency may be caused by AMQP’s complex message queuing and delivery guarantees, which often involve intermediate message brokers, acknowledgments, routing mechanisms, and transactional features. These mechanisms, while useful for ensuring reliable and ordered delivery, introduce variability depending on server load, broker state, and network conditions. Occasional spikes in processing time, thread scheduling delays, or congestion in the message queue can lead to latency outliers, making AMQP appear less consistent in time-sensitive applications.

The statistical values of median and IQR for latency data using the REST-API, ZeroMQ, AMQP, and MQTT protocols are shown in

Table 3. Statistical values of latency in REST-API protocol.

Interval [ms]	Payload Size	Median [ms]	IQR [ms]
10	Large	30.62375	6.315375
	Medium	31.45775	6.40875
	Small	31.53425	6.218625
100	Large	28.63825	4.14925
	Medium	28.729	5.403
	Small	28.72025	4.34875
500	Large	29.24875	4.76925
	Medium	28.905	4.81075
	Small	28.86625	5.125
1000	Large	29.89475	4.6925
	Medium	29.27075	4.01975
	Small	29.44625	4.643625

,

Table 4. Statistical values of latency in ZeroMQ protocol.

Interval [ms]	Payload Size	Median [ms]	IQR [ms]
10	Large	12.44225	0.472375
	Medium	12.49375	0.71125
	Small	12.39725	0.488625
100	Large	13.015	0.809875
	Medium	12.90875	0.80825
	Small	12.94075	0.93325
500	Large	13.05525	0.887125
	Medium	12.9835	0.850375
	Small	12.98275	0.923625
1000	Large	12.732	0.6595
	Medium	12.73775	0.752125
	Small	12.68375	0.657875

,

Table 5. Statistical values of latency in AMQP protocol.

Interval [ms]	Payload Size	Median [ms]	IQR [ms]
10	Large	50.569	12.6585
	Medium	50.51875	12.478
	Small	52.6935	13.77975
100	Large	33.1475	4.251
	Medium	33.415	4.739
	Small	32.868	3.85075
500	Large	33.1405	3.83725
	Medium	32.7955	3.993875
	Small	32.4895	3.49275
1000	Large	33.169	3.261
	Medium	33.1695	3.88675
	Small	33.29825	3.77675

and

Table 6. Statistical values of latency in MQTT protocol.

Interval [ms]	Payload Size	Median [ms]	IQR [ms]
10	Large	495.4235	460.7555
	Medium	140.4	113.407
	Small	30.90525	5.435125
100	Large	26.89975	2.418375
	Medium	18.0635	1.47325
	Small	18.24425	1.488625
500	Large	27.04675	2.12475
	Medium	18.19575	1.3335
	Small	18.10475	1.41675
1000	Large	26.74275	2.43675
	Medium	18.06275	1.56
	Small	18.3065	1.58325

, respectively. The median values that represent the central tendency of data in the ZeroMQ protocol have the smallest values compared to the others. Also, the IQRs that represent the variability of data in the ZeroMQ protocol have the smallest values compared to other protocols. This finding indicates that ZeroMQ is both a faster typical message delivery time and more consistent performance than the other protocols. It can be attributed to its lightweight, brokerless, and asynchronous architecture. In contrast, the REST-API, AMQP, and MQTT protocols introduce additional processing layers, transport overhead, or broker-related delays, resulting in higher and more variable latency.

In terms of the push–pull and pub–sub protocols considered in this study, the push–pull protocols (REST-API and ZeroMQ) tend to have a better latency than the pub–sub protocols (AMQP and MQTT). That push–pull protocols achieve better latency could be because they eliminate the intermediate broker layer, reduce protocol overhead, and maintain tighter communication control between sender and receiver. In contrast, the decoupled and broker-based nature of pub–sub protocols introduces additional latency.

5. Discussion

The first finding from this study reveals that the message interval significantly affects latency. This is in line with the findings from research about the effect of communication latency, overhead, and bandwidth on a wide range of applications that show higher message rates can lead to increased queuing delays, indicating that frequent message intervals can exacerbate latency due to processing overheads, especially in broker-based systems where messages must be managed and forwarded by an intermediary server [33]. An exception is observed in the ZeroMQ protocol, where the message interval does not affect latency, as supported by a study evaluating DDS, MQTT, and ZeroMQ under different IoT traffic conditions. The study shows that the latency for ZeroMQ remained relatively stable across a range of message intervals [19]. The absence of a centralized broker and ZeroMQ’s peer-to-peer architecture, combined with asynchronous communication and minimal message overhead, explains its resilience to changes in message interval.

However, the payload size has no statistically significant effect on latency, as the second finding for REST-API, ZeroMQ, and AMQP. For example, a study on MQTT and ZeroMQ under different IoT traffic conditions found that ZeroMQ’s latency remained relatively stable even as payload sizes increased [19]. Also, another study about AMQP for financial application over different message sizes observed that AMQP’s latency remained consistent across varying payload sizes, suggesting that other factors like broker performance and network conditions play a more significant role in influencing latency [34]. An exception is observed in the MQTT protocol where the payload size significantly affects the latency. This is supported by a study on dimensioning payload size in MQTT under network disconnections, which found that larger payloads led to increased end-to-end communication delays in MQTT, particularly when higher Quality of Service (QoS) levels were used [35]. Similarly, an evaluation study for MQTT under heterogeneous traffic with a combination of different payload sizes observed that MQTT brokers exhibited higher latency with increasing payload sizes, especially under high-load conditions [36]. These results suggest that MQTT’s internal queuing and acknowledgment mechanisms, especially with persistent session settings and QoS 1 or 2, can introduce latency bottlenecks under high data loads.

The third finding in the push–pull protocol is that ZeroMQ has lower latency than REST-API, as supported by a comparative study of gRPC and ZeroMQ in fast communication. This study found that ZeroMQ’s lightweight design and asynchronous messaging capabilities resulted in lower latency compared to protocols that rely on HTTP-based communication, such as REST-API or gRPC [20]. REST-API’s reliance on Transmission Control Protocol (TCP) handshakes and repeated header transmission for each request contributes to added communication delay, especially in bursty or continuous data transmission scenarios.

While in publish–subscribe protocol, MQTT has lower latency than AMQP as the fourth finding, supported by a comparative study of IoT communication in a real photovoltaic system, where MQTT demonstrated the lowest latency among the evaluated protocols (MQTT, AMQP, and HTTP), making it the most suitable choice for applications requiring real-time data transmission [37]. This advantage is largely due to MQTT’s lightweight protocol design, minimal header size, and event-driven architecture. In contrast, AMQP, while offering advanced features like message routing, delivery guarantees, and security, incurs additional overhead that can increase latency in real-time applications.

In general, push–pull protocols such as REST-API and ZeroMQ tend to have lower latency than publish–subscribe protocols such as AMQP and MQTT as the last finding. For example, the analysis of REST-API and RabbitMQ for microservices in Cloud environment mentioned that REST-API has better latency than AMQP [38]. Also, another study of MQTT and ZeroMQ under different IoT traffic conditions found that ZeroMQ exhibited lower latency and higher throughput compared to MQTT, especially in scenarios with high message rates and larger payloads under various IoT traffic scenarios [19].

Furthermore, the latency observed in our analysis for all protocols is considerably lower than the U-Space traffic information distribution requirement, which stated that latency must be under 5 s for at least 99% of the time, as outlined in Article 11 of the Easy Access Rules for U-Space by EASA [24]. This indicates that all protocols mentioned in this study comply with regulatory standards and, therefore, are suitable for supporting drone operations within the U-Space framework. However, the observed differences in latency performance indicate that protocol selection should still consider operational context, data volume, and reliability requirements, particularly in safety-critical drone operations or dense airspace scenarios.

6. Conclusions

This research analyzes the communication latency within U-Space systems, specifically assessing how different protocols impact the timely and accurate exchange of information between drone detection systems and USSPs. An experiment is conducted to measure the communication latency across a range of message intervals and payload sizes using REST-API, ZeroMQ, AMQP, and MQTT protocols. The findings show that message interval significantly affects latency, especially at a 10 ms interval, where the system nears its performance threshold. An exception is observed in the ZeroMQ protocol, where there is no significant effect of message interval in the latency. Conversely, message payload size had minimal effect, likely due to the server’s high processing capacity. Also, an exception is observed in MQTT protocol where payload size affects the latency, especially in the small message interval.

Also, this study reveals that the push–pull protocol consistently outperforms the publish–subscribe protocol in terms of latency value and its variability under the experimental conditions tested. More specifically, ZeroMQ demonstrates superior latency compared to the REST API in the push–pull protocol, and MQTT demonstrates superior latency performance than AMQP. Moreover, all protocols used in this study demonstrate sufficiently low latency to meet EASA’s requirements for drone operations.

Due to the specific requirements of drone operations and the characteristics of various communication protocols, each protocol aligns well with different use cases. Here is the recommendation based on our findings on which communication protocol should be used for specific drone operation applications. REST-API is well-suited for applications such as flight plan submission, geo-awareness, and drone status querying, where real-time constraints are less critical, and the usage is not very frequent. ZeroMQ is ideal for onboard command and control, collision avoidance coordination, network ID, and telemetry transmission, where low-latency communication is essential and the risk of security breaches is relatively low. AMQP is better suited for backend coordination and post-flight data analysis, where reliability and guaranteed message delivery take precedence over low-latency performance. Meanwhile, MQTT is particularly appropriate for real-time alert dissemination, traffic information, and conformance monitoring, where the timely information exchange of relatively small data among U-Space stakeholders is crucial.

Since this study was conducted in a simulated environment, further study could evaluate the performance of communication protocols in a realistic drone operations environment with an industrial grade of equipment and protocols to better understand its performance characteristics. Also, more communication protocols could be considered to be used in drone operations that suit the nature and needs of the applications.