David Philipp Klüner
Stefan Kowalewski
Alexandru Kampmann
Chair of Embedded Software RWTH Aachen University Aachen, Germany [email protected]
Chair of Embedded Software RWTH Aachen University Aachen, Germany [email protected]
Chair of Embedded Software RWTH Aachen University Aachen, Germany [email protected]
I. I NTRODUCTION Communication protocols, such as TCP or QUIC, commonly prepend a header to every transmitted unit of payload [1], [2]. Such headers typically carry metadata including sequence numbers, address information, and fields to verify transmission correctness. Although essential for reliable and structured communication, these headers impose a constant per-packet overhead, decreasing bandwidth efficiency [3]. This overhead is pronounced in RTPS, the protocol underlying the widely used DDS standard. The header of RTPS is largely static and contains substantial redundant information in successive packets of the same data stream. For small payloads, in particular, the cumulative header cost can dominate the total transmission size and lead to low bandwidth efficiencies. Modern middlewares, such as Zenoh, possess more compact wire formats [4], [5]. We compared two RTPS implementations (FastDDS and EmbeddedRTPS) to Zenoh with identical payloads and measured the total bandwidth of each. As shown in Fig. 1, both RTPS implementations incur higher overhead than Zenoh across all payload sizes. Specifically in
30
200
20 150
10 0
100
−10
50
−20 16 B
64 B
0
−30
Percentual Difference (%)
Mean Bandwidth Comparison
25 6B
Abstract—In this paper, we propose three extensions to the Real-Time Publish Subscribe wire protocol, on which Data Distribution Service (DDS) is based, to improve bandwidth efficiency. First, a stream negotiation mechanism exchanges static header information during discovery, replacing the full RTPS header at runtime with a compact 2 B identifier. Second, a payload aggregation scheme aggregates samples for the same locator into single UDP packets, reducing IP and UDP header costs. Third, a predictive heartbeat suppression strategy reduces control traffic by omitting heartbeats for periodic communication patterns, falling back upon detected loss or timing violations. All three mechanisms preserve Real-Time Publish Subscribe (RTPS) compatibility by extending DDS discovery to activate these features when supported. Experimental results show that stream headers reduce bandwidth consumption by up to 27.9 % compared to conventional RTPS under best-effort transport, and that heartbeat suppression yields a further 22.7 % reduction on top of stream headers under reliable transport, while preserving transmission latency in both cases. Implementation available at https://github.com/ embedded-software-laboratory/StreamRTPS. Index Terms—DDS, RTPS, Protocol Headers, Bandwidth, Overhead, Communication Middlewares
Bandwidth (kbit/s)
arXiv:2606.14214v1 [cs.NI] 12 Jun 2026
StreamRTPS: Increasing DDS Bandwidth Efficiency by Reducing Protocol Overhead
Message Configuration EmbeddedRTPS (BE)
StreamRTPS (BE)
StreamRTPS (BE) %
Zenoh %
Zenoh
FastDDS
FastDDS %
1
Fig. 1: Results comparing FastDDS, StreamRTPS, EmbeddedRTPS and Zenoh in a 4:2-4:2 topology with two senders and two receivers, two topics per sender at 25 Hz. Error bars denote one standard deviation. bandwidth-constrained networks, such as industrial, automotive, or robotics, in which DDS is often employed, bandwidth efficiency is an important factor. With increasing bandwidth demands of applications, wasting bandwidth on unnecessary header transmissions is not desirable in IoT, automotive or robotics applications [5], [6]. To address this inefficiency, we propose a backwardcompatible extension to the RTPS wire protocol, termed StreamRTPS (SRTPS). StreamRTPS is guided by three objectives: First, moving static header information to a single handshake ahead of communication instead of repeating them in every packet. Second, aggregating packets meant for the same locator to reduce transport layer overhead of multiple small transmissions. Third, reducing control traffic in reliable transport, where possible, without loss of reliability. Consequently, the main contributions of this paper are: 1) Presentation of our StreamRTPS method to reduce RTPS header overhead, message aggregation techniques, and control-traffic reduction. 2) An open-source implementation integrated into EmbeddedRTPS. 3) Evaluation and Interpretation of performance and latency characteristics for varying packet sizes, and data rates.
© 2026 IEEE. Personal use of this material is permitted. Permission from IEEE must be obtained for all other uses, in any current or future media, including reprinting/republishing this material for advertising or promotional purposes, creating new collective works, for resale or redistribution to servers or lists, or reuse of any copyrighted component of this work in other works.
The paper is structured as follows: Section II presents other research on DDS middleware related to the protocol. Section III provides an introduction to middleware and distributed systems. Section IV presents our approach to reduce bandwidth-overhead in RTPS transmissions. Section V describes our experimental setup and parametrization. In Section VI, we present the results of our experiments and interpret them. Finally, Section VII presents our conclusion and the applicability of our method. II. R ELATED W ORK Header overhead reduction is a known problem in networking. Protocols such as ROHC [3] negotiate shared context during setup and transmit compressed headers at runtime. However, these approaches rely on per-packet compression and decompression, introducing variable processing latency in contrast to our approach. We therefore review related work along two axes: alternative middlewares with compact wire formats, and DDS-specific optimization efforts. A. Middlewares Our work addresses issues relative to two middlewares whose compact wire formats motivate the overhead reduction targeted in this paper. Zenoh is a publish/subscribe/query protocol by Corsaro et al. [7] that unifies data in motion, data at rest, and computations. All operations reduce to three primitives (put, delete, get) over key/value resources. Zenoh can operate on OSI Layer 2 with approximately 5 B overhead per message, targeting devices down to 8-bit microcontrollers. MQTT is a broker-centric publish/subscribe protocol standardized by OASIS for IoT [8]. Clients communicate through a central broker over TCP/IP with a 2 B fixed header. Three Quality of Service (QoS) levels provide at-most-once, at-leastonce, and exactly-once delivery. B. DDS Despite widespread deployment of DDS in robotics, automotive, and defense, research directly addressing the RTPS wire protocol remains sparse. Several studies target Simple Participant Discovery Protocol (SPDP)/Simple Endpoint Discovery Protocol (SEDP) efficiency. Bloom-filter-based discovery was proposed by Sanchez-Monedero et al. [9] and extended with dynamic filters by Khaefi et al. [10]. These reduce discovery traffic but leave the data transmission path unchanged. Application-level optimizations have been proposed primarily for Vehicle-to-Everything. Peeck et al. [11] propose an efficient fragment retransmission scheme for lossy channels. Sperling et al. [12] took a subscriber-centric approach, distributing only relevant parts of an image to each receiver. These works operate on top of an unmodified RTPS wire protocol. Bode et al. [13] introduced user-space networking for DDS via DPDK and XDP extensions, based on a systematic implementation evaluation [14]. While this accelerates packet processing, it does not reduce the data transmitted on the wire.
To our knowledge, no prior work has modified the RTPS wire format itself. Our approach provides an alternative data path that supersedes the standard message format for the majority of transmission cases. In contrast to existing header reduction techniques, integrating directly with RTPS promises maximum efficiency while preserving RTPS’s real-time properties, important for its application domains. III. BACKGROUND DDS is an Object Management Group (OMG) middleware standard for distributed real-time publish-subscribe communication. Data is organized into typed topics to which publishers write samples and subscribers register interest. DDS is the default middleware in Robot Operating System 2 (ROS 2) and widely adopted in robotics and automotive systems. At the transport level, it relies on the RTPS wire protocol over User Datagram Protocol (UDP), Transmission Control Protocol (TCP), or shared memory, and provides configurable QoS policies for reliability, history, and resource limits. RTPS is the interoperability wire protocol of DDS, governing discovery and data transmission. Discovery proceeds in two multicast stages. The SPDP advertises participant presence through periodic announcements. Subsequently, the SEDP exchanges endpoint metadata (topic names, types, QoS) between discovered participants, establishing matched communication pairs. User data is carried in RTPS messages consisting of a fixed header followed by one or more submessages. Data submessages carry samples with sequence numbers for ordering, and a single message may bundle submessages for different readers. Reliable delivery is achieved through Heartbeat submessages, in which writers advertise available sequence number ranges, and AckNack submessages, in which readers request retransmission of missing samples. IV. M ETHODOLOGY We propose three extensions to the Real-Time PublishSubscribe (RTPS) wire protocol aimed at improving bandwidth efficiency: First, a stream negotiation mechanism that reduces per-packet header overhead by establishing shared context between endpoints. Second, a deadline-aware message aggregation scheme that amortizes IP and UDP header costs across multiple samples. Third, a predictive heartbeat suppression strategy that reduces control traffic for periodic communication patterns. A. Stream-based Transport Currently, the unmodified RTPS message and submessage headers introduce a combined fixed overhead of 44 B per packet, as shown in Fig. 2. However, the majority of these header fields, such as the protocol identifier, version, vendor ID and GUID prefix, remain static throughout the lifetime of a communication session. We exploit this observation by exchanging this static header information during discovery and replacing the full RTPS header with a compact stream header at runtime. The stream header encodes only strictly necessary runtime-dynamic information and is presented with its negotiation procedure in the next paragraph.
Unmodified RTPS 0
78
StreamRTPS (ours) 31
23 24
15 16
Protocol Name Version
RTPS Header
0
78
15 16
23 24
StreamID Offset (optional) SequenceNumber High (optional) SequenceNumber Low (optional)
VendorID
31 Stream Header
GUID Prefix
SubMsg Header
SubMsg ID
Flags ID
Extra Flags Data SubMsg Header
Message Offset
inlineQos Reader Entity ID Writer Entity ID SequenceNumber High
Omitted Overhead
Padding
SequenceNumber Low Data
Data
Payload
Payload
Fig. 2: Illustration of an unmodified RTPS packet and our StreamRTPS packet. In the Simple format only the StreamID is required for transmission, while the Standard and Reliable formats add the offset field for packet aggregation and sequence numbers for reliable transmissions.
Stream Header: The proposed stream header exists in three formats of increasing capability, each a prefix of the next: • Simple (2 B): Contains only the StreamID (uint16), a reader-unique identifier referencing the full header context negotiated during discovery. Used for best-effort streams without aggregation. • Standard (4 B): Adds an Offset field (uint16), a byte offset to the next stream packet within the same UDP datagram. Enables aggregating messages from different writers destined for the same locator, serving a role similar to the existing submessage mechanism with less overhead. • Reliable (12 B): Adds a SequenceNumber (8 B), re-
P2
Participant 1 PDP
P3
Announce Presenc e Multicast
P1: Multicast
EDP
n nt-Informatio Send Endpoi P2:
Unicast
P3:
Writer-to-Rea der Handshak e
Stream Negotiation
ack Stream AckN 5 StreamID:
Endpoint Information:
Unicast Unicast
Stream Support:
Fig. 3: Illustration of our SPDP, SEDP and our new stream negotiation handshake. In this handshake, transmission parameters and the resulting StreamID are exchanged.
quired for reliable communication to preserve sample ordering and enable retransmission. Receivers distinguish stream packets from standard RTPS messages by checking whether the first four bytes match the RTPS protocol identifier, stream packets do not carry this prefix. Stream Negotiation: To establish stream sessions, we introduce an additional pair of built-in endpoints and a perparticipant handler: the Stream Negotiation (STNE) writer, reader, and handler. The negotiation procedure, shown in Fig. 3, is initiated conditionally after the standard Simple Endpoint Discovery Protocol (SEDP) phase has completed. We extended SEDP-exchanged writer and reader information to include flags indicating support for streams and message aggregation. If these flags are present and set, the stream negotiation proceeds as follows. The writer selects a stream header format based on the mutually supported capabilities: if both endpoints support only streams, the Simple format is used. If both additionally support aggregation, the Standard format is selected. Reliable writers always use the Reliable format. The writer transmits its static header information together with the chosen format to the corresponding STNE handler on the reader side. The reader’s STNE handler validates the request, assigns a StreamID, and responds with an acknowledgment containing this identifier. StreamIDs are unique per reader of a receiving participant to ensure that the receiving socket can distinguish which topic the packet belongs to. The current version does not support multicast delivery, as a single packet cannot carry distinct StreamIDs for multiple readers. Multicast traffic therefore falls back to standard RTPS. Future work will extend the mechanism with shared StreamIDs in a separate address range for multicast communication. Subsequent data transmissions then use the negotiated StreamID in place of the full RTPS header, reducing wire overhead per message from 44 B to 2 B (Simple), 4 B (Standard), or 12 B (Reliable). If the STNE handler denies
the request or does not respond within 3 retries over 20 ms, the writer falls back to regular RTPS communication, retaining compatibility with the RTPS standard. B. Cross-Writer Payload Aggregation In standard RTPS, each payload is typically transmitted as a separate UDP datagram, incurring the full cost of IP and UDP headers per sample. On bandwidth-constrained networks, this per-packet overhead can represent a significant fraction of the total traffic, particularly for small, high-frequency signals common in fast control loops. We mitigate IP and UDP header overhead by aggregating multiple samples destined for the same transport locator into a single UDP datagram, distributing the header cost across all bundled samples. Within the proposed stream header format (Section IV-A), the Offset field allows for the chaining of several packets within an aggregated datagram so that the receiver can distinguish them. Since writers on distinct topics may produce samples at different rates, a fixed time window risks either delaying latencysensitive samples or flushing too early. We therefore tie the aggregation window to the QoS deadlines of pending samples, as illustrated in Fig. 4. When a sample arrives, it is appended to a per-locator buffer. A dedicated send loop flushes the buffer at the earliest deadline among all pending samples, bundling everything that arrived in the interim into a single datagram. If a new sample arrives with a deadline earlier than the currently scheduled flush time, the buffer is flushed immediately. This ensures that deadlines are never violated while maximizing aggregation, at the cost of increasing transmission latency up to the configured deadline. C. Heartbeat Suppression Standard RTPS reliability requires writers to send periodic heartbeats so that readers can detect missing samples. For periodic writers, these heartbeats are redundant, as receivers can infer loss from a gap in the expected arrival pattern. Instead of waiting for a heartbeat to verify that a message was lost, the reader can detect loss directly when receiving
Participant 1 Writers
Participant 2 P2
Aggregator
Deadline Aggregation Unicast
Deadline Aggregation
Sample Deadline
Unicast
Fig. 4: Illustration of Deadline-based Payload Aggregation. Samples are aggregated to the earliest deadline of a given sample, then sent and the buffer emptied.
Algorithm 1 Heartbeat Suppression State: mode m ← ACQUIRE, interval ring buffer I, period T ← T0 , NACK streak c ← 0 1: procedure O N N EW C HANGE 2: push (tnow − tprev ) into I 2 3: if |I| ≥ Nmin and Var(I) < σmax then 4: m ← I MPLICIT; T ← Timpl 5: else 6: m ← E XPLICIT; T ← µ(I) · M
// suppress
7: end if 8: end procedure
9: procedure O NACK NACK(hadNacks) 10: if not hadNacks then 11: c←0
12: else if c+1 ≥ K then 13: m ← ACQUIRE; reset I; T ← T0 14: else 15: c += 1; T ← T /2; m ← E XPLICIT 16: end if 17: end procedure 18: procedure S HOULD S END 19: return tnow − tlastHB ≥ T 20: end procedure
the next message. We exploit this with a new heartbeat mode for periodic communication in which the reader monitors the arrival pattern and the writer can in turn suspend or significantly delay heartbeat transmission. The algorithm for this is shown in Algorithm 1, with parameters listed in Tab. I. Writer-side heartbeat suppression: To initially detect the current send pattern, each writer maintains a ring buffer I of recent inter-sample intervals and a mode m ∈ {ACQUIRE, E XPLICIT, I MPLICIT}. Initially, the writer begins operation in ACQUIRE mode. On every new sample, O N N EW C HANGE pushes the latest interval into I and, once at least Nmin intervals are collected, evaluates periodicity. 2 threshold, the When the variance Var(I) is below the σmax writer enters I MPLICIT mode, extending the heartbeat period to Timpl . If the variance exceeds the threshold, E XPLICIT mode sets the period to µ(I) · M , where µ(I) is the sample mean and M a target messages-per-heartbeat count, spacing heartbeats proportionally to the observed rate. In I MPLICIT, a fallback heartbeat is emitted in Timpl as a backup. On Negative Acknowledgements (NACKs), O NACK NACK halves the period to respond to detected loss and after K consecutive NACKs resets to ACQUIRE. Reader-side proactive loss detection: Suppression maintains safety because the reader independently rate-locks onto the sample stream using the same periodicity criterion. Once locked, if the gap since the last sample exceeds α · µ(I), the reader fires a proactive NACK immediately. For a 10 ms sam-
TABLE I: Heartbeat suppression parameters for Algorithm 1. Parameter
Symbol
Value
Window size Max. variance Implicit heartbeat period Standard heartbeat period NACK streak threshold Messages per heartbeat Proactive NACK multiplier
Nmin 2 σmax Timpl T0 K M α
5 400 µs2 2000 ms 250 ms 3 5 3
ple period, this detects loss within approximately 30 ms, well before the suppressed heartbeat at Timpl = 2000 ms, resulting in faster loss detection than the standard implementation. Note that proactive detection is faster than the standard heartbeat period T0 only when α · µ(I) < T0 for sample periods below T0 /α ≈ 83 ms with our parameters. V. E VALUATION We evaluated the three proposed extensions in separate experiments: 1) StreamRTPS: Compares standard RTPS with StreamRTPS to quantify stream header overhead reduction. 2) Payload Aggregation: Measures the effect of deadlineaware aggregation on bandwidth and latency. 3) Heartbeat Suppression: Evaluates heartbeat suppression under reliable transport, including loss recovery. A. Hardware and Software Setup Our testbed consists of four Lenovo ThinkCentre M900 small-form factor machines, each with an Intel Core i56500T processor, 16 GB of DDR4 RAM and an M.2 SSD, connected via a central switch over 1 Gbit s−1 full-duplex Ethernet. The machines run Ubuntu 24.04.3 LTS with the GNU/Linux 6.17.0-14-generic x86 64 kernel. No additional real-time configuration was applied to the Linux installation. As baselines we use EmbeddedRTPS [15] and FastDDS v3.4. We also included Zenoh v1.1.0 for our motivating example. Our proposed StreamRTPS extensions are implemented as a fork of EmbeddedRTPS. Bandwidth was captured with TShark, covering both unicast traffic between testbed machines and multicast traffic. All bandwidth values are reported as the per-sender egress rate captured at the sender’s NIC. We used LTTng for kernel and userspace tracing, and PTP for clock synchronization with a measured accuracy better than 25 µs. B. Experiment Parametrization We conducted all experiments by measuring 500 steadystate samples at 25 Hz send rate across five separate executions. Experiments for Stream transport and message aggregation are conducted with best-effort (BE) reliability, while experiments modifying heartbeats are conducted with reliable transport (RL). Unless specified, experiments use 2 sender machines and 2 receiver machines in total with two subscribers or two publishers per machine, denoted as 4:2-4:2 with each subscriber-publisher pair using a single topic. We vary the message sizes between seven payload sizes: 16 B, 32 B, 64 B,
128 B, 256 B, 512 B, and 1024 B. For aggregation experiments, the timing of samples and their deadlines is important. Consequently, we divide each transmission period into four equal time slots. For aggregation experiments, the notation n1 -n2 -n3 -n4 indicates the number of publishers transmitting in each slot. For example, 1-1-1-0 at 25 Hz (40 ms period) indicates three publish events separated by 10 ms. When payload aggregation is enabled, the aggregation deadline is specified in each figure. VI. R ESULTS Since StreamRTPS is implemented as an extension of EmbeddedRTPS, we report all bandwidth and latency reductions relative to unmodified EmbeddedRTPS as the primary baseline. FastDDS numbers are included for reference. We note that EmbeddedRTPS exhibits higher absolute transmission latencies than FastDDS across all payload sizes, likely due to architectural differences in EmbeddedRTPS’s internal thread pool on the sender and receiver side. StreamRTPS does not increase latency relative to EmbeddedRTPS, confirming that the overhead stems from the baseline implementation, not from our extensions. The relative bandwidth savings reported in this section are a function of the payload-to-header ratio on the wire, which is governed by the RTPS message and submessage layout and is therefore independent of a specific RTPS implementation. Because FastDDS, EmbeddedRTPS, and other compliant implementations all emit the same 44 B of RTPS header per packet, we expect the header-driven savings to transfer to other implementations. A. Stream-based transport Using our stream transport, we achieved a maximum bandwidth reduction of 27.9 % compared to EmbeddedRTPS for 16 B messages. As noted in Section I, small payloads amplify the relative cost of header overhead, which is apparent in this result. The reduction decreases with payload size, reaching 4.4 % for 1024 B messages. Fig. 5 presents the measured bandwidths and transmission latencies. In the evaluated topologies, discovery uses multicast while user data is delivered via unicast between matched endpoints. Consequently, 100 % of data-path bytes, which dominate steady-state traffic, use stream headers. Deployments relying on multicast data distribution (e.g., 1-to-many broadcast topics) would retain standard RTPS for those flows. Compared to EmbeddedRTPS, the transmission latency is not adversely affected by the stream mechanism. Although miTABLE II: StreamRTPS bandwidth vs. send frequency for 128 B payloads in a 4:2-4:2 topology. Frequency
EmbeddedRTPS
SRTPS
Mean Bandwidth B [kbit s−1 ] 10 Hz 25 Hz 50 Hz 75 Hz 100 Hz
75.3 96.7 131.3 164.5 193.9
66.7 (−11.4 %) 82.6 (−14.5 %) 108.7 (−17.3 %) 133.6 (−18.8 %) 156.1 (−19.5 %)
StreamRTPS Bandwidth Measurements 600
Payload
20 400 10 300
0
B
64
8B 12
25
51
24 10
16
−30
B
0 32
−20
B
100
6B
−10
2B
200
B
Bandwidth (kbit/s)
500
Percentual Difference (%)
30
Message Configuration
EmbeddedRTPS (BE)
FastDDS
FastDDS %
StreamRTPS (BE)
EmbeddedRTPS
SRTPS
Mean Bandwidth B [kbit s−1 ] 16 B 83.5 ± 28.1 (33.8 %) 32 B 88.9 ± 28.5 (30.8 %) 64 B 100.0 ± 32.7 (26.8 %) 128 B 120.9 ± 37.5 (19.9 %) 256 B 164.7 ± 53.3 (13.8 %) 512 B 253.4 ± 84.6 (9.2 %) 1024 B 428.2 ± 152.3 (4.7 %)
FastDDS
62.4 ± 18.6 68.0 ± 20.3 78.9 ± 24.6 100.9 ± 33.2 144.8 ± 49.7 232.0 ± 82.8 409.0 ± 149.5
45.0 ± 11.0 (−27.9 %) 50.1 ± 13.6 (−26.3 %) 61.2 ± 17.5 (−22.4 %) 83.2 ± 25.6 (−17.5 %) 127.6 ± 42.4 (−11.8 %) 215.9 ± 74.9 (−7.0 %) 391.0 ± 143.5 (−4.4 %)
Mean Transmission Latency LT [ms] 16 B 0.53 ± 0.09 (−21.1 %) 32 B 0.54 ± 0.10 (−18.9 %) 64 B 0.52 ± 0.10 (−24.0 %) 128 B 0.52 ± 0.10 (−22.3 %) 256 B 0.52 ± 0.10 (−24.2 %) 512 B 0.52 ± 0.11 (−25.0 %) 1024 B 0.55 ± 0.10 (−21.6 %)
0.67 ± 0.12 0.66 ± 0.12 0.68 ± 0.10 0.66 ± 0.11 0.68 ± 0.12 0.69 ± 0.16 0.70 ± 0.14
0.69 ± 0.19 (3.0 %) 0.66 ± 0.17 (−0.1 %) 0.67 ± 0.10 (−1.3 %) 0.68 ± 0.10 (3.1 %) 0.69 ± 0.11 (0.4 %) 0.66 ± 0.17 (−5.2 %) 0.68 ± 0.09 (−3.0 %)
StreamRTPS (BE) %
1
Fig. 5: Table and illustration showing mean bandwidth and transmission latency for StreamRTPS, FastDDS and EmbeddedRTPS. Error bars in the figure and error margins in the table denote one standard deviation. StreamRTPS Payload Aggregation Measurements Deadline
EmbeddedRTPS
SRTPS
Payload Aggregation Measurements for varying Deadlines SRTPS Payload Aggregation
SRTPS Aggregation
25
320
226.4 ± 82.7 (−30 %) 226.1 ± 81.9 (−30 %) 211.9 ± 75.6 (−35 %) 211.4 ± 76.9 (−35 %) 206.8 ± 75.3 (−36 %)
Mean Transmission Latency LT [ms] 2 ms 0.70 ± 0.09 0.66 ± 0.10 (−3 %) 8 ms 0.69 ± 0.10 0.67 ± 0.14 (−3 %) 12 ms 0.66 ± 0.09 0.72 ± 0.16 (5 %) 18 ms 0.67 ± 0.09 0.71 ± 0.17 (3 %) 22 ms 0.68 ± 0.10 0.67 ± 0.10 (−3 %)
2.96 ± 0.38 (330 %) 8.94 ± 0.42 (1201 %) 8.05 ± 4.92 (1070 %) 13.67 ± 4.93 (1888 %) 13.18 ± 7.96 (1818 %)
20
300 280
15
260 10 240
Latency (ms)
Mean Bandwidth B [kbit s ] 2 ms 323.2 ± 119.2 252.2 ± 92.2 (−22 %) 8 ms 323.4 ± 120.0 252.7 ± 91.9 (−22 %) 12 ms 323.7 ± 119.1 252.2 ± 91.6 (−22 %) 18 ms 323.5 ± 119.4 252.5 ± 91.8 (−22 %) 22 ms 323.3 ± 119.0 252.6 ± 92.7 (−22 %)
Bandwidth (kbit/s)
−1
5 220 0 5
10
15
20
25
Deadline (ms) EmbeddedRTPS (BE)
StreamRTPS (BE)
Mean Bandwidth
Latency Mean
SRTPS Aggregation (BE) Latency P95
1
Fig. 6: Table and illustration showing the absolute bandwidth and transmission latency for our payload aggregation approach with 128 byte transmissions in a 8:1-8:1 topology and 10 ms inter-sample spacing per writer pair (2-2-2-2) and varying persample deadlines. Error margins denote one standard deviation.
nor variations of a few percent are observed, these fall within measurement uncertainty. Stream negotiation adds one additional round-trip to the discovery phase. In our measurements, this overhead remains within the variance of EmbeddedRTPS’s standard SPDP/SEDP discovery procedure and could not be isolated as a distinct latency contribution. To examine the effect of send rate, we additionally swept the transmission frequency from 10 Hz to 100 Hz for 128 B payloads, as shown in Tab. II. The bandwidth reduction increases with frequency, from 11.4 % at 10 Hz to 19.5 % at 100 Hz. This is expected as at higher send rates, more packets per second are transmitted, each benefiting from the reduced stream header, so the absolute header savings scale linearly with frequency. These results are measured under best-effort transport. For reliable transport, the relative savings are lower: the Reliable stream header (12 B vs. 2 B Simple) reduces per-packet sav-
ings, and control traffic such as heartbeats and NACKs is unaffected by stream headers, limiting the overall reduction. This motivates our heartbeat suppression mechanism (Section VI-C), which targets this remaining control overhead. Overall, StreamRTPS achieves increased bandwidth efficiency at no latency cost, with savings that scale with send frequency. CPU and memory usage remained within measurement noise of EmbeddedRTPS across all payload sizes (mean CPU delta −0.55 %, mean RAM delta −0.53 %), confirming no measurable host-side resource overhead. B. Cross-Writer Aggregation Aggregating messages yielded another increase in bandwidth efficiency at predictable latency cost. We evaluated our aggregation approach in an 8:1-8:1 topology to increase the count of co-located publishers. This topology allows us to examine scaling behavior of our aggregation approach
Heartbeat Suppression Bandwidth
Time-to-Retransmission under 1 % Loss 500
400
−10
300
−15
200
−20 −25
100 −30 16 B
32 B
64 B
12 8B
25 6B
51 2B
10
24
B
0
StreamRTPS (RL)
StreamRTPS (RL) %
400
300
200
100
0 S RTP
)
(RL
Str
SRTPS HB Suppression (RL)
SRTPS HB Suppression (RL) %
sion
s pre
eam
Message Configuration
EmbeddedRTPS (RL)
Time to Retransmission (ms)
Bandwidth (kbit/s)
−5
Percentual Difference (%)
0 500
PS SRT
up BS
(RL
)
S RTP ded
)
(RL
ed mb
E
H
Reactive bound (HB period) Proactive bound
HB period (250 ms)
1
Fig. 7: Bandwidth with heartbeat suppression for varying payload sizes in a 4:2-4:2 topology with reliable transport. Error bars denote one standard deviation.
1
Fig. 8: Time-to-retransmission distribution under 1 % induced packet loss for 256 B payloads.
when aggregating increasing message counts. We configured a transmission timing of 2-2-2-2, resulting in 2 publishers per machine sending samples each 10 ms within the 40 ms transmission window given by the 25 Hz transmission frequency. Fig. 6 illustrates measured results in relation to the configured per-sample deadline. Aggregation for a 2 ms deadline resulted in a bandwidth reduction of 10.2 % for 128 B samples compared to StreamRTPS and 30 % compared to EmbeddedRTPS.
configurations, while aggregation reduced mean CPU usage by 8.5 % relative to EmbeddedRTPS due to reduced per-packet networking overhead.
For a 2 ms deadline, the transmission latency increased to 2.95 ms and allowed the aggregation of the first two samples. The significant latency increase is expected, as our aggregation approach holds the sample with the earliest deadline until deadline expiration. Consequently, a 2 ms deadline per-sample leads to at least one sample with more than two milliseconds transmission delay, also shown in Fig. 6 through the linearly increasing maximum latencies in relation to their deadline. The mean varies non-monotonically because the remaining samples within the aggregation window arrive at intermediate offsets and shift the average. In future work we plan to consider other approaches, which use system knowledge to remove the need to hold samples to deadline. Additional bandwidth efficiency gains occurred when more samples could be aggregated, specifically when crossing the 10 ms and 20 ms thresholds. At each 10 ms increment another two messages can be added to the aggregation window. These thresholds reduced bandwidth usage by an additional 4.6 % and 1.5 % respectively, indicating diminishing returns for higher sample aggregations. In conclusion, aggregation of a small number of samples with similar release times and short deadlines appears to be effective. However, aggregating beyond two samples in our case with deadlines exceeding 10 ms is not realistic and yields diminishing bandwidth returns at disproportionate latency costs. RAM usage remained unchanged across all
C. Heartbeat Suppression We evaluated heartbeat suppression in a 4:2-4:2 topology using reliable transport using the larger StreamHeader, including sequence numbers. Fig. 7 shows bandwidth across payload sizes: suppression yielded a 22.7 % reduction for 16 B messages and 19.7 % for 128 B compared to StreamRTPS. As this mechanism only modifies the reliability control path, transmission latency was not affected, and CPU and RAM usage remained indistinguishable from both EmbeddedRTPS and StreamRTPS across all payload sizes. To validate loss recovery, we introduced 1 % i.i.d. packet loss at the UDP transport level for 256 B payloads. All affected samples were recovered through retransmission and none failed to be delivered to the application. Fig. 8 shows the time to retransmission, which we define as the interval from original send to retransmission after loss detection. With heartbeat suppression, the mean time to retransmission was 124.1 ms, compared to 148.6 ms for EmbeddedRTPS and 149.8 ms for StreamRTPS without suppression. Rather than degrading loss recovery, suppression improves it: the reader’s proactive loss detection (Section IV-C) fires at 120 ms, well before the standard heartbeat period of 250 ms. The parameters in Tab. I were selected to balance suppres2 sion against safety margin: σmax = 400 µs2 (corresponding to a standard deviation of 20 µs) rejects sample streams with excessive jitter. Heartbeat suppression thus offers significant bandwidth savings while simultaneously improving loss recovery latency for periodic transmissions, making it well-suited for DDS deployments using reliable transport with periodic transmission.
VII. C ONCLUSION This paper presented three backward-compatible extensions to the RTPS wire protocol: stream-based header replacement, deadline-aware message aggregation, and predictive heartbeat suppression. Experimental evaluation demonstrates that stream headers alone reduce bandwidth consumption by up to 27.9 % for small payloads and 11.8 % for 256 B messages compared to EmbeddedRTPS, without introducing measurable latency penalties. As shown in Fig. 1, our extensions achieve competitive bandwidth efficiency with compact wire formats while preserving RTPS interoperability. StreamRTPS is particularly relevant to any DDS deployment with small or high-rate messages, especially periodic control traffic and small sensor samples. Heartbeat suppression also yields reductions for reliable transport of up to 22.7 %, and is effective for the periodic traffic patterns prevalent in industrial and control workloads. Message aggregation offers additional savings at the cost of deadline-dependent increased transmission latency and should be used selectively in suitable network environments. Current limitations include the restriction to unicast for stream transport and the requirement for QoS deadlines to drive aggregation, which precludes its use for traffic without configured deadlines. Future work will address these limitations. R EFERENCES [1]
[2]
[3]
[4]
[5]
[6]
[7]
S. Floyd, “TCP and explicit congestion notification,” SIGCOMM Comput. Commun. Rev., vol. 24, no. 5, pp. 8–23, 1994. A. Langley et al., “The QUIC Transport Protocol: Design and Internet-Scale Deployment,” in Proceedings of the Conference of the ACM Special Interest Group on Data Communication, ser. SIGCOMM ’17, New York, NY, USA: Association for Computing Machinery, 2017, pp. 183–196. C. Bormann et al., “RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed,” 2001, Number: rfc3095. A.-I. Chisăliţă and A. Korodi, “Stepping Toward Zenoh Protocol in Automotive Scenarios,” IEEE Access, vol. 13, pp. 166 167–166 180, 2025. M. Barón, L. Diez, M. Zverev, J. R. Juárez, and R. Agüero, “On the performance of Zenoh in Industrial IoT Scenarios,” Ad Hoc Networks, vol. 170, p. 103 784, 2025. H. Zhu, W. Zhou, Z. Li, L. Li, and T. Huang, “Requirements-Driven Automotive Electrical/Electronic Architecture: A Survey and Prospective Trends,” IEEE Access, vol. 9, pp. 100 096–100 112, 2021. A. Corsaro et al., “Zenoh: Unifying Communication, Storage and Computation from the Cloud to the Microcontroller,” in 2023 26th Euromicro Conference on Digital System Design (DSD), ISSN: 2771-2508, 2023, pp. 422–428.
[8]
[9]
[10]
[11]
[12]
[13]
[14]
[15]
C. Sengul and A. Kirby, “Message Queuing Telemetry Transport (MQTT) and Transport Layer Security (TLS) Profile of Authentication and Authorization for Constrained Environments (ACE) Framework,” Internet Engineering Task Force, Request for Comments RFC 9431, 2023, Num Pages: 33. J. Sanchez-Monedero, J. Povedano-Molina, J. M. Lopez-Vega, and J. M. Lopez-Soler, “Bloom filter-based discovery protocol for DDS middleware,” Journal of Parallel and Distributed Computing, vol. 71, no. 10, pp. 1305–1317, 2011. M. R. Khaefi and D.-S. Kim, “Node discovery scheme of DDS using dynamic bloom filters,” in Proceedings of the 2014 IEEE Emerging Technology and Factory Automation (ETFA), ISSN: 1946-0759, 2014, pp. 1–4. J. Peeck, M. Möstl, T. Ishigooka, and R. Ernst, “A Protocol for Reliable Real-Time Wireless Communication of Large Data Samples,” IEEE Transactions on Vehicular Technology, vol. 72, no. 10, pp. 13 146–13 161, 2023. N. Sperling and R. Ernst, “Reducing Communication Cost and Latency in Autonomous Vehicles with Subscriber-centric Selective Data Distribution,” in 2024 IEEE 99th Vehicular Technology Conference (VTC2024-Spring), ISSN: 2577-2465, 2024, pp. 1–7. V. Bode, C. Trinitis, M. Schulz, D. Buettner, and T. Preclik, “Adopting User-Space Networking for DDS Message-Oriented Middleware,” in 2024 IEEE International Conference on Pervasive Computing and Communications (PerCom), ISSN: 2474-249X, 2024, pp. 36–46. V. Bode, C. Trinitis, M. Schulz, D. Buettner, and T. Preclik, “DDS Implementations as Real-Time Middleware – A Systematic Evaluation,” in 2023 IEEE 29th International Conference on Embedded and Real-Time Computing Systems and Applications (RTCSA), ISSN: 2325-1301, 2023, pp. 186–195. A. Kampmann, A. Wüstenberg, B. Alrifaee, and S. Kowalewski, “A Portable Implementation of the RealTime Publish-Subscribe Protocol for Microcontrollers in Distributed Robotic Applications,” in 2019 IEEE Intelligent Transportation Systems Conference (ITSC), 2019, pp. 443–448.