arXiv:2606.14228v1 [cs.NI] 12 Jun 2026
Selective Field Transmission: Bandwidth Efficient Communication under Standardized Message Schemas David Philipp Klüner
David Murach
Stefan Kowalewski
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]
Alexandru Kampmann Chair of Embedded Software RWTH Aachen University Aachen, Germany [email protected]
Abstract—In this paper, we introduce and evaluate Selective Field Transmission (SFT), a middleware mechanism that decouples transmission content from statically defined message types in publish-subscribe systems. Industrial and robotics developers often face a dilemma: They can follow established best practices and use standard message types, such as in the Robot Operating System 2 (ROS 2) and COVESA projects, to benefit from reusable and interoperable interfaces, or they can introduce proprietary, project-specific message types tailored to receiver requirements to reduce bandwidth. SFT resolves this trade-off by dynamically adapting the transmitted message components to each receiver’s actual needs while preserving unmodified standard interfaces. Receivers declare or automatically derive the required message components, which are communicated to the publisher. The publisher then serializes and transmits only the required component subset per receiver with minimal developer intervention. Our evaluation shows that SFT achieves significant bandwidth reductions without measurable per-message latency overhead, with savings proportional to the number and size of unused fields. Implementation available at https://github.com/ embedded-software-laboratory/SelectiveFieldTransmission. Index Terms—Selective Field Transmission, DDS, Middleware, Standard Interfaces, Publish-Subscribe, Bandwidth
I. I NTRODUCTION Developers of publish-subscribe systems face a recurring trade-off when defining message interfaces. They can adopt standard message types, such as those provided by the ROS 2 or COVESA ecosystems, to benefit from reusable and interoperable interfaces across suppliers and components [1]. Alternatively, they can define project-specific message types tailored to each receiver’s needs, reducing bandwidth at the cost of interoperability and maintainability. This dilemma arises from a fundamental design property of current middleware: message types are defined in an Interface Definition Language (IDL) and compiled into type-support
LiDAR Interface PointCloud2 pcl; pcl.height = 5; pcl.width = 10; pcl.data = [253,…]; publish(pcl);
Cortex A53
Message A { Int a { Field Size PointCloud2 Int b Float height, Int c Float width, D[] } FloatArray data[][]}
Diagnostic Node void callback(pcl){ checkSize(pcl.height); checkSize(pcl.width); }
AMD64 HPC
Fig. 1. Motivating Example: Illustration of fields being unused and unnecessarily transmitted in a ROS 2 publish-subscribe system due to fixed message formats. Message derived from sensor msgs/msg/PointCloud2.
code before deployment [2], [3]. IDLs guarantee type safety but fix the wire format, serialization logic, and subscription interface of every topic at the time of compilation [4]. Once a message type is chosen, every subscriber receives the complete message, regardless of how many fields it actually uses. This rigidity is best illustrated by a motivating example, shown in Figure 1. Consider a software project in which a LiDAR supplier provides a perception node that publishes large sensor_msgs/PointCloud2 messages [5]. During integration, a diagnostic node is added that monitors only the height and width fields of the published message to verify correct function. Under current middleware design, this node must subscribe to the full message and deserialize the complete point cloud, including the raw sensor data, to access two scalar fields. The alternative, optimizing this interface, requires asking the supplier to publish a second, narrower topic carrying only those fields. This involves IDL modification, code regeneration, node recompilation, and ongoing maintenance of a second topic, all to achieve narrower two-field access. Should the diagnostic node later need an additional field, the entire cycle repeats.
© 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.
These limitations are not confined to constructed scenarios, but recur in deployed ROS 2 software, such as the NAV2 navigation stack [6]. The nav2_docking_simple_charging_dock node, discussed in detail in Section V-D, requires a single field from the BatteryState message yet receives all 17. These examples expose a core limitation: subscription granularity is limited to complete message types, forcing developers to choose between standard interfaces and efficient transmission. This paper proposes Selective Field Transmission (SFT), a middleware-level mechanism that resolves this trade-off by enabling field-level adaptation of transmitted messages without recompilation. SFT allows developers to retain existing message types while adapting each transmitted message dynamically to only those fields actually requested by each receiver. Subscribers declare their field requirements to publishers at run time, and publishers selectively serialize only the negotiated fields before transmission, eliminating unnecessary data at the source. The mechanism is realized as an extension of the DDS middleware layer and integrated into the EmbeddedRTPS DDS stack. The contributions of this paper are: 1) The Selective Field Transmission (SFT) concept, comprising an explicit requirements API, an automatic recording mechanism for per-field requirements, a negotiation protocol, and a selective serialization path that encodes only the negotiated fields. 2) An open-source implementation integrated into EmbeddedRTPS 1 . 3) An evaluation of parametric and application-derived workloads quantifying bandwidth reduction and end-toend latency impact. The remainder of this paper covers background (Section II), related work (Section III), the SFT concept (Section IV), and evaluation (Section V). II. BACKGROUND Communication Middleware: Communication middlewares are software frameworks between the Operating System (OS) and user applications that enable inter-process and inter-device communication via IP-based protocols, exposing simplified Application Programming Interfaces (APIs) for common patterns such as publish-subscribe [3], [4], [7]. They typically incorporate runtime discovery, Quality of Service (QoS) policies, and security features [8]. Data Distribution Service (DDS), with its Real-Time Publish-Subscribe Protocol (RTPS) wire-protocol, is one such standard widely used in the industrial and robotics domains [9]. Serialization: For inter-device communication, middlewares transmit serialized byte data in a wire-format to ensure correct interpretation despite differences in endianness, alignment, or compiler behavior [10]. Cyber-Physical System (CPS) middlewares typically rely on a pre-known structure rather than self-describing formats: code generated from IDL files
serializes and deserializes according to the message schema, using frameworks such as FlatBuffers or MicroCDR [11]. III. R ELATED W ORK Existing work explores tailoring transmissions to receiver demands in several domains, although with mechanisms and assumptions that differ from our approach. Sperling et al. [12] propose a request–response mechanism that transmits only regions-of-interest (ROIs) of an image rather than the full frame. Because ROIs typically cover a small fraction of the original image, the method substantially reduces bandwidth and end-to-end latency. In contrast, our method applies to arbitrary message types and does not depend on application-specific preprocessing. Peeck et al. [13] present a middleware protocol for efficient and reliable transmission of large multi-frame data samples over wireless links. The protocol maintains sample-level synchronization, uses framelevel retransmissions, and schedules transmissions according to timing constraints. This design is domain-specific and optimized for wireless environments with strict deadlines, whereas our approach targets general structured message types independent of the transport layer. In the web domain, GraphQL, a query language and runtime for web APIs, provides clients with fine-grained control over which fields a server returns [14]. GraphQL is conceptually related in that clients declare required fields and servers return only those fields, paralleling SFT’s receiver-driven approach. However, GraphQL operates over HTTP in request-response mode, lacks real-time guarantees, and assumes schema introspection at query time, making direct adoption infeasible in CPS publish-subscribe systems. DDS-XTypes provide dynamic message construction at runtime through a type-builder API and automatic type discovery [9]. While XTypes’ TypeObject negotiation can establish type compatibility automatically, reducing transmitted data still requires the developer to define, register, and match a narrower type to a dedicated topic for each distinct set of receiver requirements. Moreover, each XTypes-derived type requires its own topic and writer, incurring discovery and resource costs that scale with the number of distinct receiver requirements. Consequently, for n receivers with distinct field-requirements, up to n additional topics and writers must be maintained, each incurring discovery overhead and requiring recompilation whenever requirements change. In contrast, SFT serves all receivers from a single topic and automates the process from determining field requirements to constructing adapted messages at serialization time, without requiring developermanaged type definitions. IV. S ELECTIVE F IELD T RANSMISSION
Selective Field Transmission introduces a feedback mechanism that enables publishers to adapt outgoing messages to the actual needs of receivers at runtime. We implement SFT as a DDS extension within the EmbeddedRTPS implementation [15], but the concept is in principle applicable to any publishsubscribe system that provides access to the serialization 1 https://github.com/embedded-software-laboratory/SelectiveFieldTransmission layer and per-receiver dispatch at the transport level. Selective
Payload Channel
Payload Publisher
Payload Message with FM: 0b1111 Topic 1
Payload Message with FM: 0b1010
Payload Payload Subscriber Subscriber
SFT Logic
User Callback Field Selection Mechanism
Selective Serialization
Mask generation
SFT Subsystem
SFT Reader Sender
Builtin
Selective Transmission Request: 0b1010
SFT Writer Receiver
Fig. 2. Simplified illustration of the components in our selective field transmission approach. Core components are enumerated in the middle of the figure and explained in order in Section IV.
Field Transmission consists of four components, illustrated in Fig. 2, which together establish and use receiver-side field requirements to decouple transmitted data from message types: 1) Field Requirement Mechanism: SFT first determines which fields of a message are actually used by each receiver. These per-receiver field-requirements form the basis of the approach. In Fig. 2, this step is shown on the receiver side after the user callback. We provide two mechanisms to obtain them, which are described in Section IV-A. 2) SFT Channel: Once field-requirements are known, they must be communicated to the sender. SFT introduces new builtin readers and writers through which receivers send compact requests to the sender. In Fig. 2, this channel spans the illustration from the SFT publisher to the SFT subscriber and is detailed in Section IV-B. 3) Selective Serialization: Given the incoming fieldrequirements the publisher determines how communication should be adapted. SFT adapts the messages by omitting unused fields during serialization for each receiver. This is illustrated in Fig. 2 on the sender side within the SFT logic. For this selective serialization, we extend the underlying serialization toolchain, which is described in Section IV-C. 4) Targeted Transmission: The per-receiver adapted messages must then be distributed to their respective receivers. To accomplish this efficiently, we use a single topic with per-receiver message variants, discussed in Section IV-D. In the following sections, we discuss how we realize these components in order. A. Field Requirement Mechanism SFT requires knowledge of which fields in a message are actually used by each receiver. For message type m ∈ M , we denote the set of fields that are accessed by receiver r ∈ R as Ar,m ⊆ Fm , where Fm = {1, . . . , Km } is the index set of all Km fields in message type m. SFT provides two
complementary mechanisms to establish these receiver-side field-requirements. Requirements API: The explicit requirements API allows user applications to define the field-requirements Ar,m for a message m and receiver r directly. The developer specifies the field mask representation of requirements needed by the receiver. SFT encodes this set into a Selective Transmission Request (STR) without relying on runtime observation, thereby guaranteeing correctness, repeatability, and independence from runtime variability. We represent field-requirements as a bit vector, referred to as the field mask, in which each bit corresponds to a field and indicates whether it is required. We refer to field masks where every field is required as full-mask requirements. Automatic Requirement Recording (ARR): As a userfriendly alternative to explicit specification, ARR determines field-requirements Ar,m automatically at runtime by recording which fields an application accesses while processing messages. Fig. 3 illustrates the method using an example message. When a message is received for the first time, the SFT layer first receives the full message from DDS and forwards it to the user application’s callback function. Field accesses within the callback are performed via generated getter functions. Our modified serialization code-generation tool-chain instruments these functions to record access counts for each field. The generated structures contain counters for each field, which are not part of the wire-representation and incremented by each call to a corresponding getter function. After each callback, SFT extracts the set of accessed fields as a field mask. In our implementation, readers track per-field access counters across callback invocations and automatically re-announce their fieldrequirements via the SFT channel whenever the derived field mask changes. As ARR reflects only observed behavior, it may underestimate requirements when conditional branches access fields not yet triggered at runtime. In such cases, the receiver may currently obtain default-initialized values (zero for numeric types, empty for sequences) for unrequested fields. This behavior places correctness responsibility on the requirement
Time
A B C A B C
Perception A B C
void callback(mes){ Int tmp = mes.A(); tmp += mes.B();
A B C
MsgA A{ { Message Int a A Int Int b B Int Int c Int C Array D[] }
Int res = tmp / mes.C();
}
}
Per-Field Counters
AMD64 HPC Application with Callback
Fig. 3. Illustration of Automatic Requirement Recording. Per-field counters are incremented at runtime when a function is called in the callback to the user-application.
mechanism. The explicit requirements API guarantees complete field-requirements independent of runtime observations and is therefore recommended for most deployments. ARR is best suited for scenarios where field access patterns are stable and where ease-of-use is important. We plan to add a retransmission mechanism to ARR in future work that allows receivers to detect and recover missing fields. B. SFT Channel To communicate the field-requirements Ar,m from receivers r ∈ R to the sender, SFT introduces a secondary feedback channel using new builtin reader and writers, shown in the lower third of Fig. 2. On the receiver side, an SFT writer emits STRs encoding the current field-requirements as a field mask. On the sender side, an SFT reader collects these requests and maintains a perreader field mask, which determines how outgoing messages are serialized for each receiver. Figure 4 illustrates the STRs received from each receiver within a larger example system. Whenever a receiver detects that its field-requirements have changed, i.e., the updated set of accessed fields A′r,m ̸= Ar,m , or when a new receiver joins, it sends a new STR. Until a receiver’s requirements are known, the sender transmits full messages containing all fields Fm to that receiver. In our implementation, the SFT channel is realized through dedicated builtin readers and writers that carry a message containing the field mask and a monotonic sequence number. We announce SFT endpoint presence using a vendor-specific flag in the Simple Participant Discovery Protocol (SPDP) message, so that the additional endpoints incur no extra discovery overhead. C. Selective Serialization Once receiver field-requirements have been exchanged, messages can be adapted according to the per-reader fieldrequirements Ar,m for each receiver r ∈ R and message type m ∈ M . We implement this reduction through a modified serialization toolchain that introduces serialization functions accepting a field mask provided by SFT. The toolchain is based on MicroCDR XRCE Gen and MicroCDR. Using these
functions, the SFT sender omits all fields j ∈ Fm \ Ar,m by skipping their serialization primitives, and serializes only the required subset. The resulting wire-format message therefore contains exactly the fields permitted by the mask. For a receiver r and message type P m with field sizes sm,j , the baseline transmits Bm = s bytes per message, j∈FP m m,j SFT while SFT transmits only Br,m = j∈Ar,m sm,j , yielding perP receiver savings of ∆r,m = j∈Fm \Ar,m sm,j . For variablelength fields such as arrays, sm,j denotes the actual serialized size of field j in a given message instance. Savings from omitting such fields therefore vary per message. When multiple receivers share the same field mask, the sender reuses the same serialized variant. Otherwise, it produces distinct variants for each unique mask. In our implementation, each writer maintains per-reader field masks updated via the SFT channel and serializes outgoing messages individually per reader proxy, defaulting to all fields until requirements are received. A dedicated history cache creates and caches permask serialized message variants. D. Targeted Transmission Once serialized variants have been produced, the adapted messages are transmitted on a single topic using unicast transmissions. The SFT sender stores the current field mask Ar,m for each reader r and, upon transmission, selects the corresponding serialized message variant for each receiver. To transmit the active field mask to the receiving side without additional communication overhead, SFT encodes it into the often-unused RTPS header fields for inlineQoS and extraFlags. Figure 4 illustrates the separate message versions created for each receiver within a larger example system. On reception, the reader extracts this bitmask and performs partial deserialization, reconstructing only the fields in Ar,m . Fields not included in Ar,m are default-initialized on the receiver side. Correctness guarantees depend on the chosen requirement mechanism, as discussed in Section IV-A. The current implementation uses a field mask representation of 32 bits, supporting up to 32 top-level fields. This limit can be extended as needed. SFT currently operates at the granularity of top-level fields only. E. Example Figure 4 illustrates SFT applied to an expanded version of the motivating example with three receivers of varying field-requirements. The PointCloud2 message type has Km = 3 top-level fields, with the data array dominating message size at over 16 kB. The diagnostic node requires only two scalar fields, Adiag,m = {height, width}, the object detector requires only the point cloud, Adet,m = {data}, and the SLAM node requires most fields except height, Aslam,m = Fm \ {height}. Since all three field masks are distinct, the sender produces three serialized variants. The diagnostic node benefits most: omitting the large data field SFT reduces Bdiag,m from more than 16 kB to a few scalar fields, saving significant resources and potentially enabling resourceconstrained devices to participate in communication that would
Payload Topic
PointCloud2 { Float height, Float width, Float data[][]
SFT Request height
Diagnostic Node check(pcl.height,pcl.width);
width
Control Unit B
data
LiDAR Interface Node publish(PointCloud2); Control Unit A
SFT Channel
PointCloud2 { Float height, Float width, Float data[][]
SFT Request
PointCloud2 { Float height, Float width, Float data[][]
SFT Request
height
Object Detector Node detect(pcl.data);
width
Control Unit C
data
height width data
SLAM Node map(pcl.width,pcl.data); Control Unit D
Fig. 4. Example system derived from the motivating example. A LiDAR publisher sends PointCloud2 messages to a diagnostic node (requiring height, width), an object detector (requiring data), and a SLAM node (requiring all fields except height). Each receiver emits an STR (dashed boxes, center right). The sender adapts each transmission accordingly. Grey fields are omitted, white fields are transmitted.
otherwise exceed their capacity. Savings for the object detector and SLAM node are comparably small, as the omitted fields contribute little to the overall message size relative to the data array. In the baseline, all three receivers would each receive the full Bm per message, while SFT transmits only the required subset per receiver, reducing aggregate bandwidth roughly by one third. The evaluation in Section V-E quantifies these reductions with measured data. V. E VALUATION We evaluate our SFT approach using three complementary methods. Our core goal is to validate the SFT concept and quantify its impact on bandwidth, latency, and resource usage: 1) Parametric Study: First, we evaluate system behavior using our implementation. Systematic configurations allow structured measurements of latency, bandwidth, and resource usage. 2) Nav2 Experiments: Next, we assess SFT in robotics scenarios using workloads derived from the ROS 2 Navigation 2 (Nav2) stack. Because synthetic message types and field-requirements may not fully capture real-world scenarios, we apply our method to three real message types within Nav2-derived scenarios. 3) PointCloud2 Case Study: Finally, we evaluate SFT against our motivating example (Fig. 1 and 4), demonstrating SFT’s per-receiver adaptation with heterogeneous field sizes. All evaluation methods rely on a shared set of metrics, as well as parameters summarized in Section V-A. We measure transmission latency (LT ), defined as the time between Selective Field Transmission’s publish() call and the receiver’s user-application callback, network bandwidth (B) between communicating peers. A. Parameters The parameters reflect the communication characteristics reported in robotics and industrial systems [3], [5]:
Field Count (|Fm | ∈ {5, 7}): Number of fields per message, reflecting common robotics message structures [5]. • Field Size (sm,j ∈ {128 B, 256 B and 512 B}): Per-field size, uniform within each configuration. • Receiver Count (|R| ∈ {1, 3}): Topologies are denoted as machines:senders - machines:receivers, e.g., 1:1-3:3 is one sender transmitting to three receivers on separate machines. • Field-requirement probabilities (F RP := P (j ∈ Ar,m ) ∈ [0.5, 1.0] ): Per-field independent and identically distributed probability of being required. Each receiver independently draws its own mask from this distribution, so receivers within the same experiment typically operate under distinct field-requirements served from a single topic. •
B. Experimental Setup We conducted our experiments in a testbed consisting of four Lenovo Thinkcenters M900, each with an Intel Core i56500T processor, 16 GB of DDR4 RAM, and an M.2 SSD. All machines were interconnected through a central switch using 1 Gbit full-duplex Ethernet. We fix the sending frequency to 10 Hz in all experiments to keep the parameter space tractable. We use EmbeddedRTPS [15] and FastDDS 3.4 as the baseline DDS implementation and implement our proposed SFT extensions in an EmbeddedRTPS fork. We used Ubuntu 24.04.3 LTS with a (GNU/Linux 6.17.0-14-generic x86 64) kernel on our hardware. We did not implement additional real-time configuration. Our experiments used TShark for bandwidth recordings, LTTng for tracing, and PTP to ensure time synchronization. C. Parametric Study We evaluated our implementation in 96 experiments in five repeat runs with all configurations derived from parameters outlined in Section V-A. In these experiments, we used regular transmissions of the full payload using EmbeddedRTPS as the direct baseline, since SFT extends it. FastDDS is included
Parametric Study Bandwidth and Latency Measurements 20
800
15
600 10 400 5 200
Rel. Difference (%)
Bandwidth (kbit/s)
1000
0 /7 f 51 2
B
/7 f B 25 6
12 8
B
/5 f
0
Latency [ms]
1
30
1.0
25
0.8
20
0.6
15
0.4
10
0.2
5
Rel. Difference (%)
Message Configuration 1.2
0 f 51 2B /7
f 25 6B /7
12 8B /5
f
0.0
Message Configuration Field-Req. Pr. 50[%]
Field-Req. Pr. 75[%]
Field-Req. Pr. 90[%]
Field-Req. Pr. 100[%]
FastDDS rel. diff. %
FastDDS
EmbeddedRTPS
SFT (ours)
SFT (ours) rel. diff. % 1
Fig. 5. Overview of mean aggregate network bandwidth usage and mean communication latency for our parametric study. Results shown were measured in a topology with three receivers and one sender, with three different message types and four requirement probabilities following the notation presented in Section V-A. Bars show means, error bars indicate one standard deviation.
TABLE I PARAMETRIC S TUDY C OMPARISON Metric
EmbeddedRTPS
SFT (ours)
Mean Bandwidth B [kbit s−1 ] All Exp. 521.8 (−1.5 %) FRP 50 % 521.9 (−1.5 %) FRP 75 % 521.9 (−1.6 %) FRP 90 % 521.8 (−1.6 %) FRP 100 % 521.8 (−1.5 %)
FastDDS
530.0 529.9 530.2 530.0 529.9
425.7 (−19.7 %) 269.7 (−49.1 %) 416.7 (−21.4 %) 485.4 (−8.4 %) 531.0 (0.2 %)
Mean Transmission Latency LT [ms] All Exp. 0.66 (−30.9 %) FRP 50 % 0.66 (−30.2 %) FRP 75 % 0.66 (−30.9 %) FRP 90 % 0.66 (−30.9 %) FRP 100 % 0.66 (−31.4 %)
0.96 0.95 0.96 0.96 0.96
0.95 (−0.3 %) 0.94 (−1.5 %) 0.95 (−0.3 %) 0.96 (0.4 %) 0.96 (0.0 %)
as an independent reference implementation. All experiments used Automatic Requirement Recording (ARR) to derive fieldrequirements. EmbeddedRTPS exhibits slightly higher latency than FastDDS, likely due to its internal thread-pool introducing coordination overhead on both send and receive paths. Experiments derived their field requirements i.i.d based on the given field-requirement probabilities. Results: Our empirical results show that SFT reduces bandwidth in nearly all configurations. Fig. 5 and Table I summarize the observed transmission latencies and bandwidths and report differences compared to baseline. On average, SFT
reduced traffic across all experiments by 19.7 %, with mean reductions reaching 49.1 % at F RP = 50 %. Due to our middleware integration, SFT reduced bandwidth whenever at least one field can be omitted, and in full-mask configurations the bandwidth overhead remained at most 0.2 % compared to EmbeddedRTPS. The magnitude of the bandwidth reduction depends on field sizes and the specific field-requirements of each receiver. The Nav2 case study addresses this by using real message structures with heterogeneous field sizes. In all experiments, SFT introduced no measurable latency overhead compared to EmbeddedRTPS. Due to the middleware-layer implementation, only additional serialization overhead is required to create the adapted messages for each receiver. Regarding the method’s response time, in our experiments a newly derived field-requirement was emitted and received by the sender within 1.3 ms on average, taking effect on the next transmitted message. Figure 6 illustrates one such response time (1.3 ms) for an ARR-induced field requirement change. CPU overhead increased by less than one percent in the mean compared to the EmbeddedRTPS baseline. Memory usage increased on average by 386.7 kB over EmbeddedRTPS’s 39.4 MB baseline, a 1.0 % increase. D. Nav2 Case Studies To complement the parametric study, we derived three case studies from real message types and field-usage patterns in the
∆ = 0.75 ms ∆ = 0.56 ms
2000
1000
0
−1
0
Mask Processing
1
2
3
95.0
97.5
40
300 250
30
200 20
150 100
10
50 0
0
Time [ms]
ate
n rSca Lase
St ttery
Ba
Mask Propagation Mask Application
Rel. Difference (%)
3000
NAV2 Case Studies Bandwidth Measurement Bandwidth (kbit/s)
Payload Size [b]
Response Time Example
Pending Application
id
yGr panc
u
Occ
Message Configuration
Payload Size FastDDS
1
Fig. 6. Representative example showing generation, transmission and application of a new field mask using ARR within an 512 byte 7 field and 50 % FRP experiments. The next send payload message at 10Hz is directly reduced in size, demonstrating response times of 1.3 ms in this case.
EmbeddedRTPS
FastDDS rel. diff. %
SFT (ours)
SFT (ours) rel. diff. % 1
Fig. 7. Overview of aggregate network bandwidth usage for our Nav2 case studies for 1-1 topology. Shown are the three case studies described in Section V-D with decimal field mask representations. Bars show means, error bars indicate one standard deviation.
Nav2 stack [6]:
Results: The Nav2 case studies confirm the results of the parametric study for real world workloads. Whenever messages contain unused fields, bandwidth usage can be reduced and overheads remain minimal and inline with previous results. Fig. 7 shows bandwidth measurements for these experiments. For the LaserScan and BatteryState cases, omitting unused fields reduced network traffic by 43.1 % and 46.5 % respectively. In the case of the LaserScan, the omission of the large intensities array explains the sizeable bandwidth reduction, while the smaller absolute reduction in case of the BatteryState message is due to smaller fields and baseline protocol overhead. In scenarios in which all fields were required, such as the OccupancyGrid case, SFT introduced negligible overhead. Latency results confirmed the parametric study findings: SFT introduced no measurable latency overhead over EmbeddedRTPS across all three case studies. Overall, SFT’s selective serialization achieves bandwidth reductions with no measurable latency overhead and minimal 2 https://github.com/ros-planning/navigation2/blob/main/nav2 amcl/src/ amcl node.cpp 3 https://github.com/ros-navigation/navigation2/blob/main/nav2 docking/ opennav docking/src/simple charging dock.cpp 4 https://github.com/ros-navigation/navigation2/blob/main/nav2 map server /src/map saver/map saver.cpp
resource overhead, providing an effective optimization without manual adaptation of interfaces. E. PointCloud2 Case Study To evaluate SFT with heterogeneous field sizes and distinct field-requirements on a single topic, we consider the system from Section IV-E with three receivers and field-requirements following the example. Results: Fig. 8 shows per-sender-receiver pair bandwidth measurements. SFT reduced aggregate bandwidth by 32.9 % compared to EmbeddedRTPS. This reduction was achieved because the diagnostic node, which requires only two scalar fields, was able to omit the 16 kB data field. The object detector and SLAM node achieved insignificant reductions by omitting single scalar fields, respectively. This case study demonstrates that SFT serves receivers with widely different requirements from a single topic, with savings determined by the size of omitted fields. VI. C ONCLUSION This work introduces Selective Field Transmission (SFT), a middleware-level mechanism that decouples transmission Pointcloud2 Case Studies Bandwidth Measurement Bandwidth (kbit/s)
The nav2_amcl 2 component implements an Adaptive Monte-Carlo Localizer in Nav2. It subscribes to the LaserScan message but does not use the large intensities array in the message which accounts for a large part of the message, all other fields are used. 3 • The simple_charging_dock component implements an example for Nav2’s framework to auto-dock robots and exclusively evaluates the current field out of 17 fields in the BatteryState message. 4 • Nav2 components, such as the map_saver , implementing map saving features, rely on all fields of the OccupancyGrid message, including metadata and the entire occupancy data array. •
2000 1500 1000 500 0
LiDAR → Diagnostic (FM=3)
LiDAR → Detector (FM=4)
LiDAR → SLAM (FM=6)
Writer → Reader Pair FastDDS
EmbeddedRTPS
SFT (ours)
1
Fig. 8. Overview of per-sender-receiver network bandwidth usage for our PointCloud 2 case studies following the example outlined in Section IV-E. Bars show means, error bars indicate one standard deviation.
behavior from static message types in DDS systems. By transmitting only the fields actually required by each receiver, SFT preserves interface compatibility while reducing bandwidth usage without measurable per-message latency overhead. In our parametric study, SFT achieved mean bandwidth reductions of 19.7 %, with mean reductions of 49.1 % at F RP = 50 %. The Nav2 and PointCloud2 case studies confirmed these results for real message structures with heterogeneous field sizes, with per-receiver reductions of up to 46.5 %, while full-mask scenarios introduced negligible overhead. Together, these results show that SFT dissolves the trade-off between standard and project-specific message types in practice, allowing developers to keep reusable message types without paying the bandwidth cost of unused fields. Current limitations include top-level field granularity and potentially incomplete field-requirements under automatic requirement recording. In future work, we plan to extend ARR with a retransmission mechanism and develop the idea of dynamic interfaces further. R EFERENCES [1]
[2]
[3]
[4]
[5]
[6]
[7]
I. Malavolta, G. Lewis, B. Schmerl, P. Lago, and D. Garlan, “How do you architect your robots? state of the practice and guidelines for ROS-based systems,” in Proceedings of the ACM/IEEE 42nd International Conference on Software Engineering: Software Engineering in Practice, ser. ICSE-SEIP ’20, New York, NY, USA: Association for Computing Machinery, 2020, pp. 31–40. J. Henle, M. Stoffel, M. Schindewolf, A.-T. Nagele, and E. Sax, “Architecture platforms for future vehicles: A comparison of ROS2 and Adaptive AUTOSAR,” in 2022 IEEE 25th International Conference on Intelligent Transportation Systems (ITSC), 2022, pp. 3095–3102. D. P. Klüner, L. Hegerath, A. D. Hatib, S. Kowalewski, B. Alrifaee, and A. Kampmann, “Automotive Middleware Performance: Comparison of FastDDS, Zenoh and vSomeIP,” in 2025 IEEE International Conference on Vehicular Electronics and Safety (ICVES), 2025, pp. 1–8. S. Macenski, T. Foote, B. Gerkey, C. Lalancette, and W. Woodall, “Robot Operating System 2: Design, Architecture, and Uses In The Wild,” Science Robotics, vol. 7, no. 66, 2022. T. Wu et al., “Oops! It’s Too Late. Your Autonomous Driving System Needs a Faster Middleware,” IEEE Robotics and Automation Letters, vol. 6, no. 4, pp. 7301–7308, 2021, Conference Name: IEEE Robotics and Automation Letters. S. Macenski, F. Martı́n, R. White, and J. G. Clavero, “The Marathon 2: A Navigation System,” in 2020 IEEE/RSJ International Conference on Intelligent Robots and Systems (IROS), 2020, pp. 2718–2725. W. Wang, K. Guo, W. Cao, H. Zhu, J. Nan, and L. Yu, “Review of Electrical and Electronic Architectures for Autonomous Vehicles: Topologies, Networking and
[8]
[9]
[10]
[11]
[12]
[13]
[14]
[15]
Simulators,” en, Automotive Innovation, vol. 7, no. 1, pp. 82–101, 2024. V. Bode, D. Buettner, T. Preclik, C. Trinitis, and M. Schulz, “Systematic Analysis of DDS Implementations,” en, in Proceedings of the 24th International Middleware Conference on ZZZ, Bologna Italy: ACM, 2023, pp. 234–246. eProsima, 14. XTypes - 3.4.1, Documentation, 2025. Accessed: Dec. 11, 2025. [Online]. Available: https : //fast- dds.docs.eprosima.com/en/3.x/fastdds/xtypes/ xtypes.html A. Wolnikowski, S. Ibanez, J. Stone, C. Kim, R. Manohar, and R. Soulé, “Zerializer: Towards zero-copy serialization,” en, in Proceedings of the Workshop on Hot Topics in Operating Systems, Ann Arbor Michigan: ACM, 2021, pp. 206–212. Google, FlatBuffers Docs, Documentation, 2025. Accessed: Nov. 28, 2025. [Online]. Available: https : / / flatbuffers.dev/ 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), 2024, pp. 1–7. J. Peeck, M. Möstl, T. Ishigooka, and R. Ernst, “A Middleware Protocol for Time-Critical Wireless Communication of Large Data Samples,” in 2021 IEEE RealTime Systems Symposium (RTSS), 2021, pp. 1–13. A. Quiña-Mera, P. Fernandez, J. M. Garcı́a, and A. Ruiz-Cortés, “GraphQL: A Systematic Mapping Study,” ACM Comput. Surv., vol. 55, no. 10, 202:1–202:35, 2023. 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), Auckland, New Zealand: IEEE Press, 2019, pp. 443–448.