arXiv CSopen access

The Three Dimensions of ROS 2 Middleware

1

The Three Dimensions of ROS 2 Middleware

arXiv:2607.01304v1 [cs.RO] 1 Jul 2026

Sanghoon Lee, Taehun Kim, Angelo Corsaro and Kyung-Joon Park

Abstract—ROS 2 (Robot Operating System 2) has emerged as the de facto standard for modern robot software development, with middleware implementations such as the Data Distribution Service (DDS) and Zenoh forming the core infrastructure for distributed robotic communication. Despite their architectural flexibility, these middleware systems exhibit structural limitations, particularly under dynamic and resource-constrained wireless environments. This paper presents a systematic survey of ROS 2 middleware and introduces a conceptual framework to examine its architectural limits through three structural dimensions required by distributed robotic systems, namely Space, Time, and State. We first provide a structured analysis of middleware architecture and operational dynamics, including discovery, data exchange, and state management mechanisms. Building on this foundation, we formalize Time as temporal predictability for control loops, Space as spatial abstraction from physical topology to enable modular deployment, and State as contextual continuity despite dynamic node participation and intermittent connectivity. Through a comprehensive review of existing implementations and prior studies, we organize middleware research according to the structural tradeoffs that arise among these dimensions. Under constrained wireless conditions, spatial abstraction can obscure network variability and weaken temporal guarantees, while mechanisms that preserve state continuity introduce computational and network overhead that competes with time-critical communication. These interactions reveal structural trade-offs that characterize the practical limits of contemporary robot middleware. By synthesizing architectural patterns and identifying gaps in current modeling and analysis approaches, this survey outlines a principled research roadmap for robust and scalable robotic middleware architectures. Index Terms—Robot Operating System 2 (ROS 2), middleware, Data Distribution Service (DDS), Zenoh, Distributed robotic systems, Survey, Communication Architecture

I. I NTRODUCTION Robot Operating System 2 (ROS 2) has emerged as the de facto standard for modern robot software development [1], [2]. The growing distribution and modularization of robotic systems has driven this transition, as perception, planning, and control components are deployed across multiple processes, devices, and network domains. As robotic platforms expand toward multi-robot coordination, edge-cloud integration, and wireless deployment, communication increasingly spans heterogeneous and resource-constrained environments [3]–[5]. Within ROS 2, the middleware layer abstracts and manages this complex communication through implementations such as Data Distribution Service (DDS) and Zenoh [6]. These middleware systems constitute the core infrastructure for discovery, data exchange, and state management, thereby playing a central architectural role in determining system scalability, responsiveness, and robustness [7], [8]. Sanghoon Lee, Taehun Kim, and Kyung-Joon Park are with the Daegu Gyeongbuk Institute of Science and Technology (DGIST), Daegu 42988, South Korea. (e-mail: [email protected], [email protected], [email protected]). Angelo Corsaro is with Eclipse Zenoh. (e-mail:[email protected]).

Distributed robotic systems simultaneously require temporal predictability for control loops, spatial abstraction from physical topology to enable modular and scalable deployment, and sustained state continuity despite dynamic node participation and intermittent connectivity. When these requirements are exercised in real deployments, distributed systems frequently exhibit performance degradation [9], [10]. In wireless settings, bandwidth fluctuations and latency variability weaken temporal predictability [11]–[13]. In multi-node and multi-robot systems, dynamic topology changes delay or disrupt discovery and synchronization processes, undermining modular coordination across distributed components [14]. Furthermore, mechanisms intended to preserve state continuity, such as buffering, replication, and session maintenance, introduce additional computational and network overhead that, in long-running deployments, often results in congestion or session instability [15]. A substantial body of research on ROS 2 has concentrated on application utilization and framework development, as well as performance optimization within robotic systems, with particular emphasis on real-time scheduling [16]–[20], executor design [21]–[25], and latency control at the execution and transport layers [26], [27]. Quantitative surveys of ROS 2specific publications indicate that only a very small fraction of the literature explicitly investigates middleware-layer design and analysis, accounting for approximately 3.5% of reported studies [13]. Although interest in ROS 2 middleware has grown in recent years, particularly in areas such as Quality of Service (QoS) policies, network behavior, and analytical modeling, it remains comparatively limited relative to the broader body of application-level and real-time research [2]. Furthermore, existing investigations typically proceed in isolation and lack a unifying architectural framework that systematically captures the cross-dimensional interactions among temporal predictability, spatial abstraction, and state continuity requirements [28], [29]. These observations reveal that current middleware architectures increasingly constrain the performance envelope of distributed robotic systems. As robotics advances toward visionlanguage-action integration, large-scale multi-robot coordination, and persistent autonomous operation, communication and state management can no longer be treated as secondary concerns [5], [11], [30]. The architectural properties of middleware directly influence system-level behavior under realistic deployment conditions, such as dynamic mesh networks and highpayload wireless scenarios. This survey therefore undertakes a systematic examination of middleware design to identify architectural gaps and establish a principled research roadmap for robust and scalable robotic middleware architectures. The contributions of this paper are summarized as follows. • We provide a structured examination of ROS 2 middleware by analyzing its architectural constructs and operational

2

dynamics, including discovery, data exchange, and state propagates these policies, which the underlying middleware management mechanisms. implementation then realizes [37]. The ROS 2 executor • Building on this analysis, we formalize three fundamental coordinates callback dispatch and intra-process scheduling, dimensions required by distributed robotic systems, namely whereas the middleware handles the enforcement of communiSpace, Time, and State, and articulate their architectural cation reliability and transport semantics [38]. Consequently, implications for middleware design. temporal predictability and QoS behavior emerge from the • We systematically reinterpret existing middleware research interaction between application-level execution semantics and through the lens of these dimensions, organizing it according their realization within the middleware. to the structural trade-offs among temporal predictability, B. ROS 2 Middleware spatial abstraction, and state continuity. Standard literature defines middleware as an abstraction layer • Finally, we synthesize the identified structural gaps and positioned between the application layer and the underlying propose a research roadmap to guide the development of operating system (OS), which mediates resource access in robust and scalable robotic middleware architectures. an OS-independent manner and provides service coordination The remainder of this paper is organized as follows. Sec- across distributed components [39]. Among various categories tion II provides background on ROS 2 and its middleware layer. of middleware, communication middleware provides services Section III presents an architectural analysis of ROS 2 mid- such as addressing, message routing, reliability control, dleware constructs and their operational dynamics, including QoS enforcement, and data serialization, thereby shielding discovery, data exchange, and state management mechanisms. applications from low-level socket programming and transportSection IV formalizes the three fundamental dimensions of specific details [40]. In ROS 2, the middleware implementation robot middleware, namely Space, Time, and State, and discusses corresponds specifically to a communication middleware engine. their realization in middleware implementations. Section V It abstracts QoS policies expressed through the RCL API and examines the structural trade-offs that arise among these di- interacts with the ROS 2 executor through the RMW WaitSet mensions and organizes related research within this framework. mechanism, which enables coordinated event notification and Section VI synthesizes the identified architectural gaps and data handling across distributed components [6]. To avoid ambiguity, we use the term RMW to collectively outlines a research roadmap for robust and scalable robotic middleware design. Finally, Section VII concludes the paper. denote the RMW interface layer and its corresponding middleware-specific implementation. We do not interpret RMW as a passive data transport layer. Its internal architectural II. BACKGROUNDS choices directly influence latency characteristics, discovery A. ROS 2 convergence, bandwidth utilization, and state persistence ROS 2 is an open-source software framework designed to across distributed deployments. To understand how these support the development of distributed robotic systems. Unlike architectural choices manifest in practice, we next examine monolithic architectures, ROS 2 enables modular composition the primary middleware implementations supported in ROS 2. of perception, planning, and control components across multiple ROS 2 designates certain middleware implementations as processes and networked devices [31], [32]. Its primary Tier one, which indicates the highest level of support and objective is to provide a standardized software infrastructure compatibility in its ecosystem [41]. These include DDS-based that ensures scalability across heterogeneous deployment envi- implementations such as eProsima Fast DDS, Eclipse Cyclone ronments. At its core, ROS 2 utilizes a common functional base DDS, and RTI Connext DDS, as well as Eclipse Zenoh. In through the ROS Client Library (RCL), which provides consis- this paper, we focus on DDS implementations and Zenoh, tent semantics across language-specific implementations [33]. because they represent the primary communication backends ROS 2 architects communication around the ROS in current ROS 2 deployments. Middleware (RMW) interface, which serves as an abstraction 1) Data Distribution Service (DDS): DDS is a widely and translation layer between the RCL and the underlying adopted communication middleware standardized by the middleware implementation. This design enables various Object Management Group (OMG) and originally developed external implementations, such as eProsima Fast DDS, for mission-critical applications in aerospace, defense, and Eclipse Cyclone DDS, or Zenoh, to integrate seamlessly autonomous systems [6]. DDS serves as the default middleware beneath a uniform application programming interface [34], implementation in ROS 2 and operates based on a data-centric [35]. Unlike ROS 1, which utilized a bespoke and centrally publish-subscribe paradigm in which information is exchanged managed protocol, ROS 2 decouples high-level framework through named topics. In DDS, each ROS 2 context typically logic from low-level mechanisms of discovery, matching, and creates a DomainParticipant to manage the relevant DDS transport [36]. ROS 2 translates application-level abstractions entities, which establishes an entity-centric hierarchy. Explicit through the RMW interface into the primitives of the QoS policies shape communication behavior within this selected middleware implementation. This approach delegates framework [42]. Through these mechanisms, DDS provides connectivity and reliability management to the middleware configurable parameters for reliability, durability, and deadline, while preserving a consistent programming model [37]. which the RMW interface layer exposes to ROS 2 users. Of At the application level, users define communication policies these, only the reliability policy enforces a delivery behavior, such as QoS parameters and callback execution semantics while others, such as deadline and transport_priority, signal within the ROS 2 programming model. The RMW layer or hint rather than enforce.

3

2) Zenoh: Zenoh is a communication middleware designed to enable efficient data exchange across distributed, heterogeneous, and resource-constrained environments [43]. It was developed to operate effectively under unreliable network conditions, including wireless and edge deployments [41], [44]. Beginning with the ROS 2 Kilted Kaiju release in 2025, the community officially designated Zenoh as a Tier one middleware implementation within the ROS 2 ecosystem. Architecturally, Zenoh employs a unified publish-subscribe and query protocol organized around a key/value data model, where hierarchical key expressions express interest and drive the resulting data flows. In Zenoh, the middleware operates through Zenoh sessions, where the specific mode, such as peer, router, and client, determines how they join the network. This design follows a session-centric approach that offers significant flexibility in connectivity and topology [45], [46]. In ROS 2 deployments, users commonly employ a Zenoh router, which facilitates discovery and data forwarding between sessions [47]. 3) Specialized Middleware: In addition to DDS and Zenoh, the ROS 2 ecosystem includes other middleware-related technologies with specialized scopes. For example, iceoryx provides zero-copy shared memory transport to optimize intra-host data exchange [48], while micro-ROS extends ROS 2 to resource-constrained microcontroller environments with limited networking capabilities through an XRCE-DDS-based client-agent architecture [49]. As these technologies target specific deployment contexts rather than general-purpose distributed communication across networked hosts, this study focuses primarily on DDS and Zenoh. III. ROS 2 M IDDLEWARE A RCHITECTURE AND DYNAMICS A. ROS 2 Middleware Architecture At the application level, ROS 2 software is organized into packages as the fundamental deployment units [50]. Each package typically contains executable programs that instantiate one or more nodes at runtime to enable distributed computation. A node represents an independent execution entity within a running executable that encapsulates application logic and communicates through standardized communication abstractions [51]. Rather than interacting directly with network primitives, nodes create publishers, subscriptions, services, and actions through the RCL. The RMW interface layer then maps these abstractions into middleware-level communication constructs to enable typed data exchange [52], [53]. ROS 2 provides three communication abstractions at the RCL layer: Topics, Services, and Actions [54]. Topics implement an asynchronous publish-subscribe communication mechanism, where a publisher sends messages to one or more subscribers without waiting for a request-response exchange. [55]. Services implement synchronous request-response interactions, where a client sends a request and remains blocked until a service server returns a response [56]. Actions extend the request-response pattern, where a client sends a goal to an action server that manages execution, publishes feedback, and returns a result. This mechanism is internally implemented through a combination of topics and services [57]. All data types are defined in ROS 2 interface files, from which language-specific code is generated

at build time and then used in the RCL layer [58] The RMW interface layer does not interpret these abstractions semantically, but maps each RCL entity to middleware-level entities, which operate within specific process and host boundaries [33]. To provide a unified view across middleware implementations, we abstract the ROS 2 communication architecture into five structural entities: Endpoint (E), Topic (T), Message (M), Process (P), and Host (H). Although DDS and Zenoh differ in their internal implementation, these entities can be consistently identified across deployment environments. • Endpoint (E): An endpoint is the fundamental unit of data production or consumption in the middleware layer. At the RCL layer, endpoints correspond to publishers, subscriptions, service clients, and service servers, which the RMW interface layer maps to concrete middleware constructs such as DDS DataWriter/DataReader entities or Zenoh publishers, subscribers, queriers, and queryables. Through this mapping, endpoints function as event-generating entities within the middleware layer, triggering RCL callbacks upon entity readiness propagated via the WaitSet in the RMW layer and thereby enabling reactive execution in ROS 2 applications. Each endpoint is instantiated within a specific OS process and assigned a unique identifier within the middleware domain. The middleware forms logical associations between endpoints based on matching topic names and type definitions. Each endpoint operates under QoS policies that govern reliability, durability, and delivery semantics, and maintains internal state as required to realize these QoS guarantees. • Topic (T): A topic is a logical communication channel identified by a name and an associated data type [59], explicitly formed at the RCL layer. The RMW layer maps each topic to middleware-specific constructs, such as topic names in DDS or hierarchical key expressions in Zenoh. Topics provide the naming and typing context required for endpoint matching across distributed contexts, thereby enabling communication between matching endpoints across process and host boundaries. • Message (M): A message is a concrete data instance conforming to a type defined in ROS 2 interface. At the RCL layer, message structures are generated from interface definitions and instantiated by application logic. At the RMW interface, message instances are serialized into middleware-specific representations for transmission. In DDS, this representation corresponds to a serialized sample, whereas in Zenoh it corresponds to a value payload associated with a key expression. Messages are exchanged between matched endpoints within the scope defined by a topic and may be delivered across process and host boundaries via middleware-managed transport mechanisms. Endpoint-level QoS policies govern the lifetime and delivery behavior of message instances. • Process (P): A process is an OS-level execution unit that serves as the direct counterpart to a participant: each process corresponds to one middleware participant, realized as a DDS DomainParticipant or a Zenoh session. Within a process, one or more ROS 2 nodes are instantiated and share a single ROS 2 context, which is mapped to a single participant. While

4

Fig. 1. Structural abstraction of the ROS 2 communication architecture. For DDS, TCP/IP and SHM (marked with *) are vendor-specific extensions.

most deployments run a single node per process, the node composition mechanism allows multiple nodes to be loaded into the same process, sharing a ROS 2 context and therefore a single participant. Each participant acts as the entry point through which nodes and their endpoints participate in middleware communication, managing the lifecycle of publishers, subscriptions, service clients, and service servers declared within it. Processes on the same host share hardware resources but are allocated distinct OS resources, including network ports and socket descriptors, thereby defining the execution boundary within which middleware participation is maintained and callbacks are scheduled. In advanced configurations, a process may maintain multiple contexts, each mapped to an independent participant, to support scenarios such as domain bridging or multi-domain operation. • Host (H): A host is a distinct computing unit equipped with one or more network interfaces. It provides the physical execution environment within which one or more processes are deployed. Communication between processes on the same host may occur via shared memory or local transport mechanisms, bypassing network contention. In contrast, communication across hosts relies on network interfaces and shared communication media. Although a host is often associated with a single robot, complex robotic platforms commonly comprise multiple networked hosts interconnected through heterogeneous communication links, including Ethernet, wireless, and serial buses [60], [61]. The host, therefore, defines the spatial boundary across

which middleware communication is routed and over which network-level resource constraints are manifested. Middleware implementations can introduce additional components for routing and discovery. For example, Zenoh may employ one or more Zenoh routers, which can be deployed per host or as shared infrastructure within a local network to facilitate discovery and data forwarding. Similarly, certain DDS deployments may utilize discovery servers or routing services, instantiated as dedicated processes on specific hosts [62], [63]. These components introduce intermediary processes that alter the communication topology and influence network behavior, yet they do not redefine the fundamental structural entities introduced above. Instead, they mediate how processes and hosts are interconnected within a given deployment. Fig. 1 illustrates the unified structural abstraction of the ROS 2 communication architecture, organized into a fourtier hierarchy of application, middleware, OS, and physical layers. Within the application layer, nodes instantiate endpoints that exchange messages over topics. These entities are hosted within a ROS 2 context mapped to a single participant in the middleware layer. Two fundamental boundaries govern the system. The process defines the execution boundary within which participation is maintained and callbacks are scheduled, while the host defines the spatial boundary across which processes communicate via local or network transport, including Ethernet, wireless, and serial buses. Together, these structural entities provide a consistent foundation for connecting heterogeneous distributed robotic systems across both highlevel abstractions and physical hardware constraints.

5

B. Middleware Operational Dynamics compatibility within the established communication context. In In practice, middleware communication is governed by DDS, endpoint matching is performed through the Simple three interrelated operational dynamics, namely discovery, Endpoint Discovery Protocol (SEDP), which disseminates data exchange, and state management, that operate over these endpoint metadata via built-in discovery topics [69]. These structural entities during execution. Discovery mechanisms topics convey information such as topic names, data types, determine how participants and endpoints are discovered and and QoS policies. Matching occurs when DomainParticipants logically interconnected across processes and hosts. Data detect compatible name–type pairs and verify that their QoS exchange mechanisms regulate how messages are serialized, policies satisfy the DDS compatibility rules. Only after this transmitted, and received under reliability and QoS constraints. compatibility check do the corresponding entities establish a State management mechanisms maintain and evolve the internal logical association. In Zenoh, endpoint advertisement is performed by announcmiddleware state associated with these entities to preserve ing resource key expressions and subscription interests to continuity under dynamic participation and long-running dedirectly connected sessions and routers. Matching occurs ployment. These dynamics are continuously active rather than when a published key expression satisfies a corresponding sequential stages, and their interactions shape the performance, subscription interest [70]. Unlike DDS, Zenoh does not perform scalability, and robustness of distributed robotic systems. The endpoint-level QoS compatibility checks during the matching following subsections examine how DDS and Zenoh realize phase; instead, QoS settings influence behavior at the data these mechanisms and analyze the structural implications of exchange stage. In router-mediated configurations, a router their respective design choices. collects the key expressions and subscription interests of its 1) Discovery: Discovery mechanisms establish the initial connected sessions and shares them with other routers or with and ongoing spatial structure of a distributed ROS 2 system. sessions not directly connected to one another. Based on this Through discovery, middleware participants become aware of aggregated state, the router constructs and maintains visibility one another, exchange metadata, and construct the logical relationships among its connected sessions, thereby enabling graph over which communication subsequently occurs. Unlike endpoint matching among otherwise isolated sessions. a one-time initialization step, discovery is continuously active, 2) Data Exchange: Data exchange mechanisms determine reacting to dynamic participation, restarts, and network reconfigurations [64]. The discovery process comprises (i) participant how message instances are represented, routed, and delivered across processes or hosts under the underlying transports, discovery and (ii) endpoint matching. routing topology, and required QoS. Data exchange governs the (i) Participant Discovery: Participant discovery refers to runtime behavior of communication after endpoint matching, the mechanism by which DDS DomainParticipants or Zenoh shaping the latency, jitter, and loss characteristics observed sessions become mutually aware of one another. In DDS, by ROS 2 applications. In ROS 2, these behaviors emerge participant discovery is, by default, performed using the from the interaction among (i) serialization and encoding, (ii) Real-Time Publish-Subscribe (RTPS) protocol [65]. More transport mechanisms, and (iii) reliability and delivery control. specifically, DDS employs the Simple Participant Discovery (i) Serialization and Encoding: Before transmission, ROS 2 Protocol (SPDP), a distributed peer-to-peer (P2P) mechanism in which DomainParticipants periodically announce their message instances are serialized into middleware-specific wire presence within a domain. These announcements allow other representations. ROS 2 adopts Common Data Representaparticipants to detect newly joined participants and establish tion (CDR) [71] as its standard serialization format at the mutual awareness. By default, this discovery behavior relies RCL layer, applied consistently regardless of the underlying on multicast communication within the local network scope, middleware implementation. In DDS, the serialized output constitutes a data samenabling direct P2P visibility without requiring centralized ple, which serves as the atomic unit for transmission and coordination [66]. In Zenoh, participant discovery can be implemented caching [72]. DDS may attach inline metadata that carries through multiple independently configurable mechanisms. One RTPS-level information and selected QoS-related parameters mechanism is multicast scouting, in which a session announces required for interpreting or managing the sample at the receiver its presence on the local network so that nearby sessions side. The resulting representation combines the application can detect it directly. Another mechanism is gossip-based payload and protocol metadata into a form suitable for RTPSdiscovery, in which a session propagates discovery information level encapsulation and transport. In Zenoh, the serialized about already known sessions and routers to other connected output is conveyed as a byte payload associated with a key sessions [67]. These mechanisms are not inherently coupled expression [67]. The Zenoh wire protocol encapsulates the and may be enabled or disabled independently. In the default payload with protocol-level metadata, including the wire key configuration of a Zenoh-based RMW interface, multicast expression, encoding information, and optional timestamp. scouting is disabled while gossip-based discovery is enabled. Application-level metadata may additionally be attached on a In this setting, Zenoh routers propagate discovery information per-message basis as key-value pairs via the attachment API, received from locally attached sessions and redistribute it to without requiring re-serialization of the payload. (ii) Transport Mechanisms: Following serialization, the other routers and sessions through gossip messages [68]. middleware selects transport mechanisms to deliver payloads (ii) Endpoint Matching: Following participant discovery, across process and host boundaries. Both DDS and Zenoh middleware systems advertise endpoint metadata and determine

6

support shared-memory transport for intra-host communication, avoiding kernel-network overhead for co-located processes. DDS relies on the RTPS protocol, which defines UDPbased unicast and multicast as its primary transport. Modern DDS implementations support TCP to accommodate network environments where UDP multicast is restricted or unreliable. Zenoh employs a pluggable transport layer that supports multiple protocols, including TCP, UDP, and QUIC [73]. Communication can proceed over direct P2P links or through routermediated forwarding, depending on deployment configuration. Zenoh routers relay data based on link-state information and network visibility, enabling operation across heterogeneous network topologies [74]. (iii) Reliability and Delivery Control: To ensure delivery semantics under loss and contention, middleware can maintain protocol state and apply reliability, congestion, and flow control mechanisms. In DDS, reliable communication is typically realized through stateful RTPS-level mechanisms, such as AckNack exchanges, periodic Heartbeats, and retransmission windows maintained per endpoint [75]. These mechanisms operate in conjunction with reliability and history QoS policies, which define send-queue depth and the persistence of unacknowledged samples. Per-endpoint cache limits and timing parameters that bound Heartbeat and retransmission rates further govern congestion and flow behavior. In Zenoh, each session provides a best-effort channel and a reliable channel by default, with the reliable channel maintaining sequence numbers and acknowledgment state for loss detection and retransmission [76]. When connectionoriented transports such as TCP or QUIC are used, their native ordering and loss recovery supplement these sessionlevel guarantees [4]. Publishers control congestion behavior by selecting a per-message drop or block policy applied along the entire routing path, including Zenoh routers [76]. 3) State Management: State management mechanisms determine how middleware maintains communication state and preserves continuity across process and host boundaries under dynamic conditions and intermittent connectivity. State management governs what information is tracked, cached, retained, and recovered. In ROS 2, these behaviors emerge from the interaction among three aspects: (i) liveliness maintenance, (ii) history restoration, and (iii) resource control. (i) Liveliness Maintenance: Liveliness maintenance determines how middleware monitors the presence and health of contexts across processes and hosts. In DDS, liveliness is maintained through Heartbeat and lease mechanisms at both the participant and endpoint levels. These mechanisms are continuously active, with periodic liveliness assertions refreshing leases while missed assertions trigger liveliness-loss detection. This creates a decentralized monitoring structure in which each DomainParticipant observes the liveliness of others. In Zenoh, liveliness is governed by a session lease and keep-alive mechanism [70]. Any data or protocol message exchanged on a session refreshes the lease, and keep-alive messages are sent only when the session would otherwise be idle. If the lease expires, the session is closed and the associated resources are removed. Zenoh also provides liveliness tokens for

application-level monitoring [77]. These are explicitly declared resources whose presence is observed by peers, and whose loss is signaled when the declaring session is disconnected or the token is undeclared [78]. This design provides session-centric monitoring and avoids continuous P2P polling. (ii) History Restoration: Middleware governs the synchronization of state for entities that rejoin after disruption or appear after messages have already been produced. In DDS, this behavior is localized within the HistoryCache of an endpoint [79]. Under durability QoS settings, a DataWriter replays messages from its runtime cache to newly matched DataReaders [80]. Consequently, in standard ROS 2 deployments, history restoration is limited to data retained in active memory and does not persist across entity restarts without specialized persistent storage services [81]. Zenoh decouples history from the producing endpoint by introducing independent storage managers [82]. These managers act as dedicated peers that store values for specific key expressions, enabling late-joining endpoints to pull historical state via query mechanisms even after the original endpoint is no longer available [67]. This design complements endpointlocal buffering by providing a process-level storage service. (iii) Resource Control: Resource control mechanisms define the constraints and policies that prevent unbounded memory consumption and buffer exhaustion within the middleware. In DDS, these constraints are enforced through the resource limits QoS policy, which bounds HistoryCaches at the individual endpoint level [83]. By defining parameters such as the maximum number of stored samples per endpoint, DDS provides explicit control over the memory allocated to each entity. However, the resulting behavior depends on the preconfigured limits, and insufficient limits may cause message drops or blocking. Zenoh manages resources through transmission queues configurable on sessions and routers [84]. Users can explicitly control queue sizes and the memory allocated to each queue. This makes resource management more path-based than endpoint-based, because available buffering depends on configured queues along the routing path [85]. Compared with DDS, Zenoh distributes resource control across sessions and routers rather than enforcing it at the individual endpoint level. Fig. 2 illustrates a visual synthesis of the three primary operational dynamics in ROS 2 middleware: discovery, data exchange, and state management. These dynamics function as interdependent loops to collectively govern the distributed system. The spatial structure established by discovery directly shapes the routing paths available for data exchange, while the internal state managed by the middleware ensures the continuity of these interactions. This tight coupling implies that any modification to one dynamic inevitably propagates performance implications to the temporal and state-related aspects of the communication stack. To systematically evaluate these inherent trade-offs, Section IV formalizes the three structural dimensions required by ROS 2 middleware: Space, Time, and State. We transition to a unified framework that defines the objectives pursued by ROS 2 middleware within its operational dynamics, grounding each dimension in the previously defined structural entities.

7

Fig. 2. ROS 2 Middleware Operational Dynamics.

IV. T HREE D IMENSIONS OF ROBOT M IDDLEWARE

become unstable. When State is inadequately supported, the system cannot preserve how state is maintained across participation changes, and contextual continuity is lost. By mapping these dimensions to specific key questions and primary objectives, we establish a unified framework for evaluating how middleware supports the complex requirements of modern robotics.

This section formalizes the three structural dimensions essential to distributed robotic systems: Space, Time, and State. These dimensions are not design choices unique to a particular middleware; they are universal structural requirements imposed by the nature of distributed robotic systems. ROS 2 middleware must provide (i) location transparency so that applications TABLE I can interact without knowledge of physical placement, S TRUCTURAL D IMENSIONS OF ROBOT M IDDLEWARE (ii) temporal predictability so that time-sensitive robotic tasks Dimension Key Question Primary Objective receive consistent and bounded communication behavior, and Space Where is the entity located? Location Transparency (iii) contextual continuity so that system state is preserved Time When is the message delivered? Temporal Predictability across dynamic node participation. DDS and Zenoh pursue State How is state preserved? Contextual Continuity identical objectives along each of these dimensions, even though their mechanisms for realizing them differ structurally. A. Space: Location Transparency This section formalizes each dimension as a shared objective Space denotes the structural objective of maintaining a and establishes how it maps to the operational dynamics and coherent logical communication structure that remains indestructural entities defined in the preceding section. pendent of the underlying network and deployment topology. Table I summarizes this mapping by associating each dimenThe core requirement is location transparency, meaning that sion with a key question that captures its operational concern applications must be able to express interaction through data and a primary objective that defines the goal middleware must identifiers and semantic roles rather than physical network pursue to satisfy it. The key question for each dimension is addresses or fixed placements. Without this property, system not merely descriptive but diagnostic: it identifies the class of components cannot be composed, relocated, or scaled across failure that arises when the dimension is insufficiently realized. processes and hosts, as doing so would require rewriting the When Space is inadequately supported, the system cannot application-level logic. This paper treats location transparency answer where an entity is located, and modular deployment at the architectural level, requiring the middleware to sustain a breaks down. When Time is inadequately supported, the system coherent communication structure without operator-specified cannot guarantee when a message is delivered, and control loops routing, intermediary configuration, or protocol bridges.

8

Both DDS and Zenoh pursue this objective through their fundamental trade-off between continuity and resource utilizadiscovery mechanisms, which transform entity participation tion. Mechanisms that extend the temporal reach of retained events into logical visibility relationships. In each case, the data inevitably consume memory and introduce synchronization middleware resolves the question of where an entity is located overhead. The two designs differ in where this cost is located, into an answer that is invisible to the application: a topic with DDS placing it in HistoryCaches bound to the producing subscription matches a publisher not because the application endpoint, and Zenoh assigning it to separate storage managers is aware of its address, but because the middleware has that need not be bound to the application. Bounding these costs constructed and maintained the appropriate logical association. through resource control policies necessarily limits the degree The specific discovery mechanisms used, such as multicast of continuity available to rejoining components. communication, router-mediated scouting, represent distinct implementations of the same spatial abstraction objective. D. Structural Trade-offs of Middleware Design Consequently, the discovery scope, routing topology, and The three structural dimensions, Space, Time, and State, do endpoint matching policies determine which remote entities not operate as independent design concerns. Each dimension are visible and reachable from the application’s perspective. is realized through operational dynamics that share the same execution and spatial boundaries, namely processes and B. Time: Temporal Predictability hosts. As a result, the mechanisms that serve one dimension Time denotes the structural objective of ensuring that inevitably draw upon resources and infrastructure that are middleware communication behavior satisfies the temporal also required by the others. This shared dependency creates requirements of distributed robotic tasks. The core requirement structural coupling among the dimensions, meaning that is temporal predictability, meaning that the middleware must optimizing one dimension under constrained conditions regulate when messages are delivered to provide predictable imposes pressure on the remaining two. and bounded latency under varying network conditions. Without The first coupling connects Space and Time. Location this property, time-sensitive task loops cannot achieve stable transparency relies on discovery mechanisms that continuously operation across process and host boundaries. maintain logical visibility across dynamic participants. Both DDS and Zenoh pursue this objective through their However, this abstraction conceals the physical network state data exchange mechanisms, which govern how messages that temporal performance depends upon, and the concealment are serialized, transported, and delivered. In each case, the itself becomes a source of degradation. In wireless or middleware must ensure that the application receives data bandwidth-constrained environments, this degradation is within a useful time window while internally handling the com- amplified, because the overhead necessary to sustain a plexity of transport heterogeneity and congestion. The specific coherent spatial structure competes directly with the temporal transport layers and queue management strategies represent budget available for latency-sensitive control and sensing distinct implementations of the same temporal objective. These communication, and the middleware possesses no architectural mechanisms also differ in how they treat message priority, mechanism to detect or interrupt the escalation. with the DDS standard defining the transport_priority policy The second coupling connects State and Time. Contextual as a hint whose realization is left to each implementation [86], continuity requires liveliness maintenance, history restoration, and Zenoh providing priority-driven delivery as part of its and resource control that generate persistent background data exchange path. Any modification to these mechanisms, traffic and buffer overhead. In real-time deployments, these even if it does not affect the network topology, shapes the mechanisms do not merely consume residual capacity. temporal envelope available to the robotic application. They interact with the data exchange path through shared queues, lock-contended dispatch threads, and retransmission pathways. When these dynamics are active simultaneously, C. State: Contextual Continuity latency increases and jitter becomes less predictable, directly State denotes the structural objective of preserving state compromising the temporal predictability. coherence across the system lifecycle despite dynamic The third coupling connects Space and State. As the spatial participation and intermittent connectivity of entities. The scale of a deployment grows, the quantity of metadata that must core requirement is contextual continuity, meaning that the be retained and propagated to maintain location transparency middleware must track, retain, and recover internal information increases. Node anonymity withholds the physical identity so that late-joining or recovering components can synchronize information required for lifecycle state tracking, and paththeir state without disrupting the application context. Without blind forwarding withholds the network condition information this property, distributed robotic systems cannot sustain required to prevent buffer saturation. Architectural responses consistent operation across node restarts, network disturbances, to this pressure, such as introducing router intermediaries or or prolonged deployments. centralized discovery servers, reduce the per-participant state Both DDS and Zenoh pursue this objective through their cost but concentrate the system’s visibility graph at a single state management mechanisms, which maintain the internal point of failure for external connectivity. state associated with endpoints, participants, and their routing Taken together, these three couplings reveal structural tradepaths. In each case, the middleware must address the question offs inherent to ROS 2 middleware. Because the mechanisms of how state is preserved across boundaries where continuous required by each dimension compete for the same bounded connectivity can not be assumed. State management involves a

9

execution capacity, network bandwidth, and buffer memory, fully satisfying Space, Time, and State simultaneously under constrained deployment conditions remains structurally constrained under shared resource bounds. Any middleware design must therefore navigate the trade-off surface defined by these three dimensions, accepting partial compromises in at least one dimension to preserve the requirements of the others. These structural trade-offs motivate the systematic review presented in the remainder of this paper. Section V maps 94 middleware-focused studies on ROS 2 middleware onto the trade-off space defined by the three dimensions. Rather than categorizing these works by implementation details or individual performance metrics, we organize them according to the primary dimensional conflict each study addresses and the dimension it prioritizes for optimization. This classification reveals the structural boundaries that contemporary middleware research has encountered and exposes the architectural gaps that remain unresolved in the design space of distributed robotic middleware.

1) Serialization Overhead: Communication across heterogeneous hosts requires the middleware to transform application messages into a standardized wire format that is independent of programming language, endianness, and word size, so that data can traverse process and host boundaries [87]. Serialization is therefore intrinsic to communication that crosses host boundaries, required whether or not location transparency is sought. The Space–Time conflict arises because location transparency renders serialization non-elidable even when physical colocation would permit an intra-host non-serialized path. Under large-payload conditions, this structural cost amplifies and propagates into the broader communication pipeline. Serialization of high-volume messages directly translates into CPU and memory pressure, as each transmission requires allocation, encoding, and subsequent decoding of the full payload. Measurements indicate that, under payloads exceeding a few hundred kilobytes, the dominant fraction of end-to-end communication latency originates in the serialization and memoryhandling stages of the DDS, resulting in measurable CPU saturation [88]. Concurrently, the auxiliary data accompanying packet V. D IMENSIONAL C ONFLICT A NALYSIS encapsulation consumes a disproportionately large share of total The three dimensions in Section IV, namely Space, Time, execution time and available bandwidth, independent of whether and State, are not independent axes but represent structurally the application payload itself is small or large [87]. The internal coupled mechanisms that inherently compete for shared compu- queues maintained to relay messages between the logical and tational and communication resources. This coupling produces physical layers become saturated when transmission volume three structural conflict pairs. First, spatial abstraction imposes exceeds their service rate, blocking the publisher write process unavoidable costs on temporal predictability. Second, state and introducing queuing latency into the delivery path [89]. continuity mechanisms contend for the same resources required The problem escalates structurally as endpoint counts inby time-critical transmissions. Third, the anonymity and full- crease. Analytical modeling of DDS internal queue-processing mesh visibility that location transparency requires withhold the policies demonstrates that buffer saturation produces compoundidentity information that state continuity demands. Crucially, ing delays, where thread batch-processing stalls and queue these conflicts do not arise within a single layer but follow contention interact, causing latency to grow nonlinearly with escalation patterns across the system. load [87]. When multiple publishers simultaneously inject large In this section, we map 94 middleware-focused studies payloads into shared internal queues, the per-message serialonto the three conflict pairs identified above. We organize ization cost accumulates into sustained throughput degradation, them according to the primary dimensional conflict each propagating backpressure upstream toward the application study addresses and the structural mechanism through which callback layer. Under these conditions, the communication that conflict manifests, rather than cataloging these works by pipeline degenerates from a bounded-latency channel into implementation detail or individual performance metric. For a congestion-driven bottleneck, undermining the temporal each conflict pair, we examine the underlying architectural predictability required by closed-loop robotic tasks. assumptions that give rise to the tension, trace how proposed Several approaches have been proposed to reduce this approaches attempt to relieve it, and identify the structural overhead. Alternative message formats such as ROS-SF commonality that recurs across otherwise diverse approaches. preserve the C++ struct memory layout to eliminate encoding and decoding without requiring source modification [90]. A. Space–Time Conflict Zenoh-based architectures such as Meta-ROS reduce Spatial abstraction is the cornerstone of ROS 2, providing serialization overhead by optimizing the encoding pipeline location transparency that decouples applications from their under high data-rate conditions [91]. Partial serialization physical deployment. However, maintaining this abstraction im- schemes such as TZC decompose messages into a control poses an unavoidable structural cost on temporal performance. segment transmitted via socket and a bulk-data segment This conflict is not confined to a single architectural layer; placed in shared memory, avoiding full-payload copying [92]. rather, it forms an escalation structure that originates within the Zero-copy mechanisms such as ROS 2 Agnocast eliminate middleware’s internal logic and propagates toward the physical serialization entirely by mapping the publisher heap into network as the scope of spatial independence widens. This sub- shared memory and employing dedicated smart pointers, section examines this escalation through four manifestations: se- supporting even unsized message types [93]. At the framework rialization overhead at the middleware boundary, latency ampli- level, Flexbot bypasses the DDS middleware for intra-host fication induced by concealed physical Maximum Transmission communication entirely, substituting native FIFO (First In, First Unit (MTU) limits, resource redundancy caused by location- Out) structures and pointer passing to remove serialization, agnostic delivery, and jitter amplification by physical multicast. copying, and fragmentation costs [15]. More fundamentally, the

10

ROS 2 RMW abstraction inherits the strongly typed DataWriter before all fragments arrive, the partially assembled datagram is and DataReader model from DDS, which structurally forecloses discarded and all successfully delivered fragments are wasted. serialization elision. Zenoh performs no serialization when Because the middleware operates above the IP fragmentation transmitting user data placed in Zenoh-managed shared layer, it remains unaware of a message’s existence until all memory, yet this path is unreachable through the ROS 2 API fragments have been reassembled into a complete datagram. because the API always serializes user data [47]. As a result, the middleware repeatedly requests retransmission Each of these mitigations achieves cost reduction by reintro- of the entire message rather than targeting only the missing ducing the locality awareness that spatial abstraction withholds. fragments, generating redundant traffic [99]. Alternative encodings that deviate from canonical CDR restrict Several approaches have been proposed to mitigate interoperability across heterogeneous nodes, narrowing the scope of cross-host communication [94]. Zero-copy and pointer- fragmentation-induced latency. Node composition and passing approaches explicitly exploit the physical co-location zero-copy APIs eliminate serialization and UDP fragmentation of endpoints within the same process or host, making location overhead entirely for intra-host communication paths [100]. transparency conditional on deployment topology. Intra-process Shared-memory pointer-passing architectures such as CyberRT optimizations eliminate boundary crossings by design but resolve large-payload fragmentation by bypassing UDP become inapplicable the moment communicating endpoints transport altogether [101]. Configuring the maximum message are distributed across hosts. Every proposed mitigation thus size to match the network MTU boundary suppresses converges on the same structural outcome. Avoiding serializa- uncontrolled IP-layer fragmentation and constrains the retransmission burden triggered by individual packet loss [102]. tion cost requires partially relinquishing spatial abstraction. Application-layer fragmentation protocols employing bitmap2) Payload Fragmentation: The topic-based publish- based acknowledgment decompose large samples into subscribe model of ROS 2 is designed to completely conceal independently retransmissible fragments, confining the cost of the transmission constraints of the physical network from the individual fragment loss to only the affected unit rather than the application layer. From the application’s perspective, each full message [98]. Subscriber-selective transfer mechanisms message constitutes a single logical unit: the middleware further reduce exposure to fragment loss by allowing accepts an arbitrarily sized payload and assumes responsibility subscribers to request only the message portions relevant to for delivering it to all matched subscribers, irrespective of the their processing context [103]. Transport-level alternatives physical transport characteristics that lie between publisher and such as TCP and QUIC, evaluated in automotive middleware subscriber [6]. This design is a direct expression of location comparisons, absorb fragment loss through connection-oriented transparency; the application is liberated from any knowledge recovery but introduce connection management overhead and of the MTU constraint that governs the largest packet a given head-of-line blocking under congestion [104]. network link can carry [88]. The abstraction is structurally Each of these mitigation strategies achieves its temporal sound in its intent, but it introduces a hidden vulnerability. benefit by partially dismantling the physical-layer independence Large payloads such as camera images and LiDAR point clouds, that spatial abstraction provides. Node composition and sharedwhich are common in robotic perception pipelines, are silently memory approaches eliminate fragmentation by exploiting physdecomposed at the physical layer into hundreds of fragments ical co-location, making them inapplicable to the distributed, of approximately 1400 bytes each [95], without any visibility multi-host deployments [6]. Fragment-aware middleware and of this decomposition being surfaced to the middleware. MTU-aligned configurations must explicitly recognize the The consequence of this concealment is that the reliability of boundaries of the underlying network, which means that transthe entire logical message becomes contingent on the successful port characteristics originally abstracted away must be reintrodelivery of every individual fragment. Under nominal network duced into the middleware’s operational logic. Application-layer conditions this dependency is largely invisible, but in wireless fragmentation schemes require the publisher to reason about or resource-constrained deployments, physical-layer packet loss physical link properties and message partitioning structure, exposes the fragmentation structure that spatial abstraction had directly violating the principle that communicating endpoints concealed. Experimental evaluation under simulated wireless remain agnostic to deployment topology [103]. TCP-based fallconditions confirms that the retransmission process under back constrains transport behavior to a unicast client–server cona reliable QoS profile produces severe latency spikes, and nectivity model that is structurally incompatible with the decouthat repackaging lost data into large retransmission units pled multicast publish-subscribe paradigm [60]. The structural further degrades packet loss rates [96]. Quantitative results conclusion is therefore consistent across all approaches: reducdemonstrate that hierarchical fragmentation amplifies individual ing the temporal cost of fragmentation requires the middleware packet errors into message-level latency inflation, as a single to reintroduce physical-layer awareness into its forwarding path. lost fragment prevents receiver-side reassembly and forces 3) Intra-Host Redundancy: The logical endpoint abstraction retransmission of the affected fragment window [97]. that underlies location transparency in ROS 2 middleware Experiments demonstrate that even a moderate packet error manages each subscriber as an independent logical entity, rate on a wireless channel is sufficient to invalidate entire multifragmented messages, because the loss of a single MAC-layer irrespective of where that subscriber is physically deployed. frame renders the full reassembly attempt unrecoverable [98]. This design guarantees uniform communication semantics If the reassembly timer maintained by the OS kernel expires across all endpoints: a subscriber running on a remote host and

11

a subscriber running on the same host as the publisher receive identical treatment at the middleware layer [105]. Any differentiation based on physical co-location would require the system to expose deployment topology to the middleware layer, violating the independence that spatial abstraction is designed to provide. Absent explicit co-location awareness, the logical endpoint abstraction has no basis for recognizing that multiple subscribers on the same host could share a single physical copy of a message. It instead treats each subscriber as an isolated destination and issues a separate, independent transmission for each, with the number of message copies produced on a single host scaling linearly with the number of locally deployed subscribers [106]. Under inter-host communication, each transmission requires kernel-level copies through the socket buffers, repeated once per subscriber regardless of physical proximity between subscribers. Experiments confirm that unicast-based point-to-point distribution consumes CPU and memory resources that scale linearly with endpoint count, a relationship formally established through complexity analysis [107]. In unicast configurations, publisher-side throughput decreases proportionally as subscriber count grows, because each additional subscriber imposes an independent transmission workload on the same fixed send queue [108]. Even within a single process, the absence of strict smart-pointer optimization causes a distinct copy of the message to be instantiated per subscriber, confirming that the redundancy originates at the logical separation model rather than at the network layer [109]. Across multiple DDS implementations, results show systematically that per-subscriber latency increases by measurable increments with each additional subscriber under one-to-N configurations, a pattern that persists across implementations and payload sizes [110], [111]. As subscriber count increases, the cumulative overhead of redundant intra-host delivery escalates from a localized resource pressure into a system-wide timing constraint. Benchmarks of standard unicast delivery confirm that publisher-side Ethernet bandwidth utilization doubles under two-subscriber configurations and that latency grows proportionally thereafter, with throughput falling inversely with subscriber count [112]. In many-to-one architectures, once node count exceeds a threshold, receiver-side buffer overload drives message update failure rates toward saturation and causes average data age to increase sharply [113]. Analytical modeling of the internal HistoryCache buffers and publisher dispatch thread demonstrates that under high-frequency publication, message accumulation in these queues produces worst-case communication delays that grow with publication rate and subscriber count [87]. In scaled multi-robot deployments, the OS scheduling overhead introduced by independently executing processes further compounds this pressure, consuming over 1400% of available CPU resources under socket-based baseline configurations [114] and producing message loss and latency attributable to the redundant dispatch burden [115]. Several approaches have been proposed to reduce the overhead of intra-host redundancy. Intra-process node composition eliminates serialization and copy overhead for colocated endpoints [100], a principle extended to multi-process environments by zero-copy mechanisms such as Agnocast [93]. Shared memory transport replaces 𝑁 independent socket

transmissions with a single write, with iceoryx-backed deployments demonstrating near-constant latency regardless of message size [116]. DDS-based deployments address the same problem through shared-memory transport and intra-process communication optimizations natively supported within Fast DDS and Cyclone DDS [116], [117]. The Zenoh RMW similarly delivers a single copy to local subscribers through shared-memory transport [47]. Each of these solutions achieves its efficiency gain by introducing explicit physical co-location awareness into the middleware’s forwarding logic, and in doing so, partially relinquishes the location transparency that motivates the logical endpoint abstraction. Shared memory transport requires the middleware to detect whether communicating endpoints reside on the same host and to apply a differentiated delivery path based on that detection, violating uniform communication semantics internally even where the application interface appears unchanged [117]. Intra-process communication concentrates endpoints within a shared process boundary, so that a failure in one node propagates to all co-located nodes, a consequence that is architecturally unacceptable in safety-critical deployments such as autonomous driving [93]. The performance gains are therefore achievable only within deployment configurations explicitly constrained by physical placement, confirming that logical endpoint independence and the elimination of redundant physical delivery have not been simultaneously achieved within the current middleware design space [89]. 4) Inter-Host Redundancy: Inter-host communication faces a structural redundancy problem when a single publisher delivers a message to multiple subscribers across host boundaries. Under naive unicast delivery, the publisher issues separate transmissions per subscriber, so network-level transmission cost scales linearly with the number of remote subscribers. ROS 2 middleware addresses this through two mechanisms at different layers, namely multicast at the network layer and routermediated fan-out at the middleware layer [108]. The OMG DDS specification relies on multicast as the default transport for discovery traffic within a local network domain [118]. Multicast is expected to provide a stable and predictable delivery path regardless of subscriber count, as the network infrastructure absorbs the replication burden without imposing additional cost on the middleware layer. The structural vulnerability of this assumption is that packet replication under multicast is not performed at the logical layer by the middleware but at the physical layer by the network switch. When a multicast packet arrives at a switch, the switch must inspect its group membership state and produce one copy of the packet per outgoing port associated with that multicast group, a process that consumes switch-internal forwarding resources proportional to both the number of destination ports and the rate at which multicast packets arrive. IP multicast forces routers to maintain per-group state that varies over time, imposing scalability and reliability penalties that prevent the mechanism from scaling to large numbers of groups [119]. The middleware has no visibility into this threshold, as the physical replication constraint is precisely the kind of infrastructure

12

detail that spatial abstraction is designed to conceal. In wireless scales linearly with the subscriber count, reproducing at the environments, this concealment carries direct operational con- logical layer the cost that multicast was designed to absorb at sequences, as UDP multicast induces uncontrolled flooding that the physical layer [126]. Router-mediated fan-out shifts the condegrades delivery performance beyond what the middleware centration point from the publisher to the routing intermediary, layer can detect or compensate [118]. relocating the redundancy cost rather than eliminating it [76]. Once the subscriber count crosses the switch’s processing Bridge-based segmentation requires the deployment architect threshold, queuing delays accumulate from the mismatch to partition the logical communication graph according to the between the logical delivery model and the physical infras- physical topology of the underlying network, a dependency tructure’s replication capacity, escalating into network-wide that directly contradicts the physical-layer independence jitter amplification. Because all subscribers in the multicast that location transparency provides [60]. Correct multicast group receive packets from the same switch output queue, a operation therefore requires operators to possess detailed single switch bottleneck degrades the timing behavior of the knowledge of the physical infrastructure rather than treating it entire logical communication graph. Benchmarking studies as an opaque conduit. Recovering temporal predictability under report that delivery latency remains stable below payload- high subscriber counts requires either sacrificing multicast’s size and subscriber-count thresholds but rises exponentially spatial efficiency or accepting infrastructure management costs. once exceeded, with maximum latency spikes approaching Table II summarizes the 42 studies surveyed under the Space– 5000 microseconds observed at specific configurations [120]– Time conflict. The majority target DDS and are evaluated on [122]. The escalation is therefore not a gradual degradation wired or local-host configurations, a distribution that reflects the but a threshold effect, where system-wide timing predictability dominance of controlled testbed environments in the literature collapses abruptly rather than deteriorating incrementally, and and partially explains why the physical-layer consequences the middleware possesses no mechanism for anticipating or of spatial abstraction have been undercharacterized relative to signaling this transition to the application layer [123]. their operational severity. Wireless evaluations are concentrated Several approaches have been proposed to address this inter- in the fragmentation and multicast subgroups, where physicalhost redundancy. Unicast fallback replaces multicast delivery layer variability directly exposes the hidden costs that location with individual per-subscriber transmissions once the subscriber transparency imposes on delivery timing. Modeling studies count exceeds a configured threshold, eliminating switch- remain a minority across all four manifestations, indicating level replication entirely. Experiments demonstrate that beyond that analytical characterization of Space–Time interactions endpoint-count thresholds of approximately 50 to 75 publishers lags behind empirical evaluation. The key approach column and subscribers, unicast communication outperforms multicast reveals that proposed mitigations consistently fall into one in both latency and throughput, providing empirical justification of two structural categories: those that exploit physical cofor dynamic mode switching [124]. Container network interface location, such as shared-memory transport, zero-copy mechplugins such as Kubernetes WeaveNet intercept multicast anisms, and node composition, and those that reintroduce packets and transparently convert them to unicast transmissions network-layer awareness, such as MTU-alignment, bitmapat the physical network layer, preventing flooding without based fragmentation, and domain bridging. This distribution requiring changes to the middleware configuration [108]. reflects the underlying structure of the conflict itself. Regardless Bridge-based domain segmentation approaches such as zenohof which manifestation a study targets, every viable mitigation bridge-ros2dds partition large DDS multicast domains into either narrows the deployment scope to physically constrained isolated logical segments interconnected by unicast gossip configurations or partially dismantles the network independence protocols, resolving infrastructure constraints and topology that spatial abstraction provides, confirming that the Space– limitations that standard multicast cannot traverse [60]. In Time conflict has been navigated at the cost of one or both of swarm deployments of 20 or more robots, standard UDP its constituent guarantees. multicast over Wi-Fi has been found to be entirely unusable in practice, and centralized discovery servers or unicast-based protocol bridges have been proposed as complete replacements B. Time–State Conflict Mechanisms for contextual continuity, including reliability for the multicast-dependent default configuration [125]. Beyond network-layer multicast, middleware-layer router-mediated fan- protocols and liveliness monitoring, ensure logical consistency out provides an alternative absorption point. A Zenoh router on in the face of dynamic participation and intermittent the destination host receives a single message over the network connectivity. Yet, the execution of these mechanisms consumes from the publisher and delivers it to local subscribers via the the same computational and communication resources host’s intra-host mechanisms, decoupling network-level trans- demanded by temporal performance. This conflict initiates at mission cost from the number of remote subscribers [47], [76]. the middleware execution layer and escalates into network-wide Each of these approaches resolves the timing instability by resource competition, occasionally triggering uncontrollable reintroducing physical infrastructure awareness into a system positive feedback loops. The trade-off is structural: the more that spatial abstraction was designed to render infrastructure- strictly a system enforces state consistency, the more resources agnostic. Unicast fallback preserves temporal predictability it consumes for state management. This subsection examines but abandons the spatial efficiency that motivated multicast three manifestations of this escalation. We analyze jitter from adoption in the first place. Unless a routing intermediary internal synchronization, bandwidth erosion by control mesabsorbs the fan-out, publisher-side transmission overhead sages, and congestion arising from reliability-driven recovery.

13

TABLE II TAXONOMY OF L ITERATURE A DDRESSING THE S PACE –T IME C ONFLICT [Ref]

Protocol

Application Domain

Evaluation Platform Wired

[105] [117] [88] [100] [115] [113] [15] [102] [99] [97] [87] [6] [92] [90] [109] [108] [112] [111] [110] [119] [89] [95] [106] [116] [103] [96] [98] [101] [122] [126] [121] [107] [120] [124] [94] [125] [118] [91] [60] [114] [93] [104]

Robotics, Auto.

Workstation

✓

Embedded, Workstation Embedded Simulator ✓ ✓ Robotics Workstation

Network WireLocal less Host ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓

✓ ✓ ✓ ✓ ✓ ✓ ✓

✓ Embedded, Workstation Embedded

✓ ✓

DDS IIoT Workstation

Auto.

Embedded, Workstation Embedded Simulator, Workstation

✓ ✓ ✓ ✓

Simulator (None) Workstation

✓ ✓ ✓

✓ ✓ ✓

Simulator Workstation Simulator, Workstation

✓ ✓

✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓

Embedded, Simulator Robotics, IIoT Both

Robotics Auto.

Embedded, Workstation Workstation Embedded, Workstation Workstation

✓ ✓ ✓

✓

✓ ✓ ✓ ✓

✓ ✓ ✓ ✓

Research Type Key Approach Evalu- System Modelation ing Design ✓ Unicast-baseline ✓ ✓ SHM-orchestration ✓ Serialization-profiling ✓ Node-composition ✓ ✓ Process-overhead ✓ Subscriber-scaling ✓ ✓ Middleware-bypass ✓ ✓ Burst-analysis ✓ ✓ Burst-analysis ✓ ✓ Heartbeat-modeling ✓ ✓ Queue-modeling ✓ P2P-motivation ✓ ✓ Split-transport ✓ ✓ Layout-preserving ✓ Intra-process-copy ✓ Container-overhead ✓ Bandwidth-profiling ✓ ✓ Subscriber-latency ✓ ✓ QoS-profiling ✓ ✓ Multicast-scalability ✓ AutoThrottle ✓ ✓ App-fragmentation ✓ Copy-overhead ✓ ✓ Zero-copy-SHM ✓ ✓ Subscriber-selective ✓ ✓ Wireless-fragment ✓ ✓ Bitmap-fragmentation ✓ SHM-bypass ✓ ✓ Threshold-modeling ✓ ✓ Unicast-fallback ✓ ✓ Unicast-threshold ✓ ✓ Complexity-modeling ✓ ✓ Multicast-spike ✓ Topology-aware ✓ CDR-interoperability ✓ ✓ Swarm-bridging ✓ Protocol-comparison ✓ ✓ Encoding-tuning ✓ ✓ Domain-bridging ✓ ✓ Middleware-bypass ✓ ✓ Heap-zerocopy ✓ Transport-comparison

1) Lock Contention: Guaranteeing the logical ordering of endpoint state structure, all but one must enter a waiting messages and the consistency of shared state in a distributed state until the lock is released by the current holder. The environment is a structural requirement for ROS 2 middleware. duration of each waiting interval is nondeterministically disWithout enforced ordering and synchronized access to internal tributed, as it depends on the scheduling behavior of the data structures, the middleware cannot provide the contextual OS, the execution time of the lock holder, and the number continuity that applications depend upon across dynamic of competing threads. A single-threaded ROS 2 executor participation and concurrent message flows. To satisfy this serializes all subscription callbacks through a fixed pollingrequirement, the middleware imposes synchronization at its point mechanism, causing buffer overflow and message loss internal queue and callback layers, where multiple execution when multiple publishers simultaneously saturate the dispatch threads concurrently access shared endpoint state, message path [128]. In multi-threaded configurations, publishers, flow histories, and dispatch queues. This synchronization is the controllers, and listeners interact through shared pending mechanism by which state consistency is enforced, and its message queues, where contention introduces context-switching presence is proportional to the strength of the consistency overhead and nondeterministic delays [129]. As concurrent guarantee the middleware is required to provide [127]. As callback invocations increase, inter-thread interference at these the continuity requirements intensify, through stricter order- shared structures compounds, degrading timing predictability ing guarantees, deeper history retention, or higher callback across the execution layer [130]. concurrency, the frequency and duration of synchronization operations increase correspondingly. The primary manifestation of this synchronization cost at the execution layer is lock contention. When multiple threads simultaneously attempt to access a shared queue or

14

As system complexity increases, lock contention escalates data loss rather than full state continuity [128]. The structural from isolated execution stalls into a system-wide source of outcome is consistent: achieving temporal predictability in the timing nondeterminism that propagates across middleware, OS, presence of concurrent state access requires either weakenand kernel layers. At the kernel level, FIFO ring buffer pro- ing the consistency guarantees or redistributing consistency cessing and thread scheduling contention have been identified responsibility onto a separate architectural component. as the root cause of end-to-end response time degradation from 2) Control Overhead: Reliable communication in ROS 2 five ms to 122 ms under increasing message load, with jitter middleware requires each entity to continuously exchange scaling directly with publication rate and message size [131]. control messages with its peers, including Heartbeat announceContext switching overhead further amplifies this effect: each ments, AckNack acknowledgments, and session management lock acquisition failure causes the blocked thread to yield its CPU slot, triggering a context switch whose latency adds to messages, to verify liveliness and delivery state. These conthe total waiting time and whose frequency grows with the trol traffic constitute a permanent structural tax on network contention rate. Under high publication rates, the combined capacity. The OMG DDS specification mandates that each effect of lock waiting and context switching causes internal entity continuously signal its alive status within the configured dispatch latency to exceed the inter-message interval. At this lease duration, leaving the middleware no architectural basis point, the callback queue accumulates a backlog. Consequently, for suspending this exchange during periods of low data the delivery timing of subsequent messages becomes correlated activity [86]. Control traffic is a steady-state background load with the processing delays of their predecessors rather than primarily driven by the number of active endpoint relationships, though it remains partially influenced by application data their arrival times [128]. Several research directions have addressed contention and rates. In multi-robot deployments, control messages for datatiming nondeterminism through structural improvements at readiness notifications and keepalive mechanisms accumulate multiple layers. Distributed state synchronization using conflict- under scaled configurations. This accumulation has been free replicated data types and atomic operations eliminates halt- directly measured to cause bandwidth overflow and network ing synchronization from concurrent execution paths without saturation [137]. In DDS, control messages and application messages requiring modification of the middleware internals, a principle demonstrated using Zenoh [132]. Assigning mutually exclusive compete for the same network bandwidth and CPU resources callback groups to dedicated executors separates synchroniza- without priority separation, so Heartbeat and acknowledgment tion concerns from data publication without requiring changes signals directly consume bandwidth otherwise available for to application code [133]. The synchronization burden can latency-sensitive delivery [138]. This contention is further further be removed from the execution path by delegating compounded in containerized environments, where network history retention and state consistency to an independent virtualization plugins introduce additional CPU and bandwidth storage layer, structurally decoupling state management from competition that becomes particularly pronounced at high the latency-critical data exchange pipeline [45]. To resolve this transmission frequencies and small payload sizes [108]. In at the middleware layer, priority-aware executor redesigns in- wireless lossy networks, this interference manifests as local troduce native preemptive scheduling models such as producer- latency spikes under reliable QoS, where lower-layer loss consumer and thread-dispatch variants. These redesigns allow recovery and middleware-level retransmission triggered by high-priority callbacks to predictably preempt lower-priority missed acknowledgments compete directly for the same ones without external OS interventions [134]. Middleware- path [139]. As participant count grows, discovery and integrated QoS resource managers extend this predictability Heartbeat or AckNack retransmission traffic scales linearly further by interfacing directly with the RTOS to enforce budget and saturates the software transmission queue at the data link scheduling and temporal isolation, maintaining correct execu- layer, creating a bottleneck shared with application data [140]. As system scale increases, the bandwidth erosion caused tion semantics during real-time system reconfiguration [135]. Each approach reduces contention overhead by accepting by control traffic escalates from a marginal overhead into a constraints on state consistency or infrastructure. Storage- dominant structural constraint. This erosion is continuous: each based decoupling removes the synchronization burden from active endpoint relationship contributes a persistent stream the execution path but introduces an independent storage of Heartbeat and acknowledgment exchanges that cannot be infrastructure, adding resource and configuration overhead. suspended regardless of application data rate. Prior work Priority-aware executors improve latency predictability for formally proves that the total transfer count in a unicast prioritized callbacks but do not eliminate contention for domain scales as 𝑂 (𝐸 × 𝑃), where 𝐸 and 𝑃 denote the number lower-priority flows [134]. To enable end-to-end timing anal- of endpoints and participants in the domain, respectively, ysis, communication flows must be decoupled, which means exhausting both network resources and memory as the endpoint accepting delayed consistency over immediate processing, population grows [107]. Empirical scaling experiments confirm and strict destination order guarantees must be relaxed to that as the number of ROS 2 nodes increases from two make the system schedulable [136]. Under these relaxed to five, latency spikes sharply and message drop rate rises consistency conditions, when asynchronous publication rates exponentially, demonstrating that this steady-state bandwidth exceed subscription processing rates, message loss cannot be erosion constitutes a systemic bottleneck rather than a localized prevented even under bounded buffer configurations, meaning performance penalty [139]. that temporal predictability can only be preserved by accepting

15

Several approaches have been proposed to reduce the the middleware must reconstruct a correct historical snapshot bandwidth footprint of control traffic without abandoning the before exposing new message to the application [127]. reliability guarantees it supports. Heartbeat period and lease The structural vulnerability of this approach surfaces specifduration tuning reduces the frequency of liveliness announce- ically when the underlying network is already operating ments by adjusting the interval between consecutive control under congestion. Because the reliability mechanism monitors message transmissions, and analytical modeling confirms that endpoint-level sequence state rather than network-level resource the Heartbeat period directly governs the frequency of AckNack availability, it cannot distinguish between isolated packet loss generation and retransmission attempts [97], [141]. DDS param- and symptomatic of link saturation. In both cases, the response eter optimization, including synchronous publish modes and is identical: retransmit immediately. Analytical modeling QoS tuning such as best-effort QoS and keep last history poli- shows that periodic Heartbeat messages broadcast by the cies for small high-frequency packets, has been shown to reduce publisher induce AckNack responses from receivers and trigger communication latency and improve real-time performance in immediate retransmission for every detected sequence gap, distributed robotic control scenarios [142]. At the protocol establishing a structurally unconditional retransmission pathway level, batching and coalescing mechanisms aggregate multiple that operates independently of channel load [141]. Under messages into single message; both DDS implementations and congested conditions, this retransmission injects additional Zenoh’s session protocol employ batching to consolidate control traffic into a channel that is already unable to clear its existing messages and minimize protocol overhead. More fundamentally, load, directly increasing queue occupancy and elevating the transport-level reliability substitution via connection-oriented probability of further loss. The contrast between reliable and protocols such as TCP or QUIC removes the per-endpoint Ack- best-effort QoS makes this dynamic explicit. Reliable QoS Nack exchange from the middleware-visible communication continuously retries every missing sample in the HistoryCache, path entirely. This has been demonstrated using Zenoh [70], and consuming retransmission resources without bound, whereas comparable latency benefits are achievable in DDS deployments best-effort does not attempt recovery and thereby avoids by switching to TCP-based transport configurations [143]. At contributing to congestion [146]. the architectural level, Zenoh assigns a configurable priority to The transition from isolated retransmission events to systemcontrol traffic, allowing an architect to shift this competition wide degradation follows a positive feedback structure. Each between control and application flows rather than eliminate it. retransmission attempt adds traffic to an already-saturated Each mitigation strategy either reduces control traffic at a channel, which induces further packet loss, which in turn cost to contextual continuity, displaces that responsibility onto triggers additional retransmission, forming a self-reinforcing the transport layer, or reorders the contention through priority loop in which the state recovery mechanism itself amplifies assignment without removing it. Heartbeat period tuning and the loss it was designed to correct. Experiments demonstrate batching reduce message frequency but increase the latency that scaling ROS 2 nodes over DDS in a wireless lossy with which liveliness failures are detected, directly weakening network under reliable QoS causes average latency and message the timeliness of contextual continuity maintenance [138]. In drop rate to increase exponentially, reaching communication large-scale multi-robot deployments, sustained state consistency collapse as retransmission attempts overwhelm the available maintenance has been observed to generate excessive data channel capacity [147]. History recovery at reconnection further flows that exhaust communication resources and destabilize compounds this escalation. The middleware floods the channel the network [144]. Experiments further demonstrate that, in with retained samples at the moment of rejoining, competing DDS-based deployments, activating complete security and directly with control messages on the same transport path and reliability guarantees reduces throughput from approximately prolonging the period during which the feedback loop remains 70,000 to 14,000 packets per second and increases latency by active. As system scale grows, the communication cost and a factor of five [142], and that achieving timing determinism computation overhead associated with state synchronization in practice requires adopting best-effort QoS rather than increase concurrently [148], making the system increasingly reliable QoS [145]. The dimensional outcome is consistent: susceptible to retransmission feedback loops. reducing the steady-state cost of control traffic requires either Several approaches have been proposed to interrupt the weakening the state consistency that the traffic exists to positive feedback loop. Time-based filtering mechanisms maintain or accepting degraded temporal predictability [108]. discard intermediate updates under high-volume delivery conditions, preventing channel flooding without disabling the 3) Retransmission Congestion: Reliable communication reliability mechanism entirely [149]. Custom QoS policies in ROS 2 middleware is predicated on the assumption incorporating inter-robot velocity differentials can dynamically that delivery failures must be detected and corrected as adjust transmission window sizes to minimize retransmission quickly as possible to preserve contextual continuity across events [150]. Congestion-aware retransmission control feeds distributed nodes. Under reliable QoS, the DDS specification network congestion signals from the 5G layer back into the requires the middleware to retransmit missing samples and middleware, enabling proactive throttling before saturation replay retained history for reconnecting endpoints, treating is reached [151]. Disabling MAC-layer retransmission and every unacknowledged sample as a deficit to be resolved replacing the AckNack loop with a purpose-built protocol without delay [86], [138]. Consequently, the DDS architecture prevents the collision between lower-layer and middlewareprioritizes state completeness over transmission efficiency, as layer retransmission cycles [98]. Zenoh supports storage-based separation of history recovery from active data exchange. Zenoh

16

provides dedicated storage managers that retain samples for Conversely, attempts to reduce state management overhead specific key expressions and serve them to late joiners via pull- consistently converge toward restricting the scope of spatial based queries, ensuring that history delivery no longer competes abstraction. This conflict forms a paradoxical escalation with ongoing transmissions on the primary data channel [82]. structure: it originates at the endpoint level, extends to DDS can achieve analogous separation through persistent dura- transmission paths, and intensifies at the network level. This bility services. Fundamentally, leveraging the frame replication subsection examines four manifestations of this tension: node within Time-Sensitive Networking (TSN) bypasses middleware- anonymity that obscures lifecycle state, path-blind forwarding level retransmissions entirely by providing lossless redundancy that conceals buffer conditions, the discovery storms that at the network layer [152], but doing so couples the middleware emerge from P2P state growth, and the structural vulnerabilities to a network configuration, introducing a Space–State conflict. introduced by intermediary-dependent state management. These approaches achieve their benefits by accepting a 1) Node Anonymity: Location transparency in ROS 2 constraint on either the timeliness of state recovery or the completeness of delivery guarantees. Congestion-aware throt- middleware is realized through data-centric anonymity: tling introduces delay between loss detection and retransmis- communication is organized around named topics and key sion delivery. Multi-robot results demonstrate that network expressions rather than physical node identities, so that bottlenecks can only be prevented by differentially applying receivers obtain data by declaring interest in a logical channel reliable and transient local QoS to high-priority information without any knowledge of who is producing it or from where. while relegating other data to best-effort and volatile QoS, This design is a deliberate structural principle that allows confirming that complete reliability guarantees and real-time applications to remain indifferent to deployment topology network performance have not been simultaneously achieved in and to interoperate across heterogeneous nodes without prior current deployments [153]. Storage-based decoupling removes coordination [107]. The publish-subscribe model explicitly the reconnection burst but introduces a consistency boundary decouples data sources and data sinks with respect to node between the storage manager and the producing endpoint whose location and temporal requirements, ensuring that applications divergence must be managed as a separate operational concern, require no knowledge of the existence or location of other trading one form of state overhead for another. No mechanism participating entities [154]. The same anonymity, however, simultaneously preserves the immediacy of state recovery and imposes a structural constraint on state management. Because protects temporal performance under congestion; every viable the middleware does not track the physical identity of commuapproach either delays state restoration or redistributes its cost nicating entities, it has no architectural basis for associating the persistent state accumulated during middleware operations onto a separate architectural component. with the specific physical entity that produced it, making Table III summarizes the 34 studies surveyed under the contextual continuity dependent on an identity resolution Time–State conflict. Wireless evaluations account for a notably capability that spatial abstraction structurally withholds. higher proportion than in the Space–Time group, reflecting Under the anonymous endpoint model, the middleware has that retransmission congestion and control overhead manifest no architectural basis for distinguishing a rejoining node from most severely under lossy network conditions where the a newly appeared one across deployment events. Runtime gap between reliability demands and available capacity is endpoint identifiers such as the DDS GUID and the Zenoh widest. Modeling studies are more evenly distributed across session ID can distinguish a reconnecting endpoint from a the three subgroups, indicating that the Time–State interaction first-time connection during the identifier’s lifetime, but they has received comparatively more formal analytical attention, do not survive redeployment or identifier change. The DDS particularly in characterizing Heartbeat periodicity, retransmis- liveliness QoS policy governs whether an entity is still active sion dynamics, and executor contention. The key approach by treating any entity that fails to assert its alive status column reveals that mitigation strategies cluster around two within the configured lease duration as no longer active [86]. structural directions. Those that reduce state enforcement Each participant therefore stores the information of all remote cost by relaxing consistency guarantees, including best-effort- endpoints it has discovered in an internal database, and pertuning, time-filtering, order-relaxation, and policy-selection, and participant memory consumption grows linearly with the total those that relocate state management responsibility away from number of endpoints in the domain [107]. Because DDS the latency-critical path, including state-decoupling, lock-free, operates without a message broker, the burden of tracking and TSN-replication. This distribution mirrors the structural which stored state belongs to which physical entity falls entirely conclusion common to all three subgroups: no proposed on the individual participant [155]. approach simultaneously preserves the immediacy of state The system-level consequences of this identity ambiguity recovery and the predictability of data delivery. escalate along two distinct paths. In the first path, ghost nodes that persist beyond their operational lifetime occupy endpoint C. Space–State Conflict slots in the discovery state and consume liveliness monitoring While spatial abstraction aims to provide location resources as the middleware continues issuing Heartbeat transparency by shielding applications from physical checks to unreachable addresses. In some configurations, newly placement, maintaining this independence either increases joining nodes with matching topic profiles receive stale cached the structural cost of state management or makes state state intended for the original terminated entity. Prior work tracking structurally constrained under shared resource bounds. demonstrates that when a publisher is deleted without calling

17

TABLE III TAXONOMY OF L ITERATURE A DDRESSING THE T IME –S TATE C ONFLICT [Ref]

Protocol

Application Domain

Evaluation Platform Wired

[151] [128] [147] [133] [134] [130]

Robotics, IIoT Robotics, Auto.

Workstation Embedded, Workstation, Simulator

[148] [150] [153] [144] [137] [131] [129] [139] [142] [145] [97] [140] [138] [141] [108] [149] [135] [152] [136] [98] [146] [107] [127] [86] [70] [45] [132] [143]

Workstation, Simulator Workstation, Simulator Simulator

Embedded, Simulator Embedded Robotics

Network WireLocal less Host ✓ ✓ ✓ ✓ ✓ ✓

✓

✓

Sync-scaling

✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓

✓ ✓ ✓

Adaptive-QoS Policy-selection Swarm-overhead Wireless-scaling Kernel-contention Queue-isolation Control-scaling BestEffort-tuning Reliability-cost Heartbeat-modeling Discovery-saturation Control-dependency Retransmit-modeling Container-overhead Time-filtering Budget-scheduling TSN-replication Order-relaxation Bitmap-fragmentation QoS-contrast Complexity-modeling Consistency-model Spec-analysis Transport-replace State-decoupling Lock-free Protocol-comparison

✓ ✓ ✓

IIoT Auto.

Workstation

✓

Embedded, Workstation

✓ ✓

Workstation Embedded, Workstation Embedded Simulator Workstation

(None)

✓

✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓

✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓

Zenoh Both

IIoT

Embedded Workstation

✓ ✓

✓

Robotics, IIoT, Auto. Auto.

Embedded, Workstation

✓

✓

a disconnect service, the tracker continues to register the publisher as active, accumulating stale state that cannot be cleared without explicit lifecycle signaling [115]. In the second path, because the middleware associates endpoints with logical topic identifiers rather than persistent physical identities, a reconnecting node is indistinguishable from a newly arrived entity sharing the same configuration. The middleware has no criterion for determining whether a reconnecting endpoint should receive previously accumulated lifecycle context or be treated as a new lifecycle context. When both paths are active simultaneously, the system must manage an expanding ghost state while attempting to restore contextual continuity for reconnecting nodes. It produces a state management burden whose cost grows with both system scale and the frequency of node lifecycle events. Several structural approaches address the node anonymity problem from different layers. Assigning unique physical identifiers to each robot and creating dedicated per-robot communication channels through topic name suffixing, combined with explicit connection and disconnection service calls, provides a functional approach to dynamic participation management [115]. Purpose-built DDS-based middleware circumvent the anonymity-induced tracking gap through application-level identity enforcement, such as explicit join codes and periodic Heartbeats [156]. A Named Data Networking (NDN) approach combined with a distributed query interface identifies data for

Congestion-throttle Executor-modeling Wireless-scaling Callback-isolation Preemptive-executor Contention-modeling

✓ ✓ ✓ ✓ ✓

Simulator

Key Approach

✓

✓

DDS

Research Type Evalu- System Modelation ing Design ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓

✓ ✓

✓ ✓ ✓ ✓

✓ ✓

✓

✓ ✓ ✓

✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓

✓ ✓ ✓ ✓

✓ ✓

specific key expressions regardless of which physical node originally produced it, allowing a reconnecting node to retrieve its prior state via a pull query without requiring identity resolution at the middleware layer. This addresses state recovery continuity rather than the underlying anonymity constraint, and Zenoh demonstrates the principle in practice [132]. Combining ROS 2 managed nodes with external orchestrator health-check control loops such as Kubernetes binds logical component identities to physical process lifecycles and enables automatic restart management at the deployment level [157]. Each approach resolves the identity-state coupling by partially dismantling the anonymity on which location transparency depends. Storage-based decoupling requires the storage manager to explicitly track which endpoint produces which data and to keep its retained state aligned with that endpoint, a coupling that the fully anonymous publish-subscribe model was designed to render irrelevant [45]. Process-level lifecycle management requires external orchestrators to explicitly track deploymentlevel information that location transparency was designed to render irrelevant [157]. Prior work further establishes that in DDS architectures, state tracking cannot be fully decoupled from physical identity to maintain mutual consistency [127]. The structural outcome is consistent across all approaches: achieving lifecycle state continuity under dynamic node participation requires the system to acquire and use physical identity information that spatial abstraction withholds by design.

18

2) Path-Blind Forwarding: Spatial abstraction in ROS 2 [160]. Building on this, adaptive task execution rate regulation middleware structurally constrains the state that the middleware addresses the injection-consumption mismatch by analyzing is permitted to maintain. Because location transparency requires message consumption capacity at runtime and dynamically the routing path to be treated as an opaque conduit, the adjusting the sensor message sampling and injection rate middleware holds no representation of downstream buffer to match the actual processing bottleneck [161]. Within occupancy, queue depth, or link capacity as part of its state. This the middleware, runtime queue occupancy monitoring with is not an implementation omission but a structural consequence dynamic QoS reconfiguration, including queue depth and timeof spatial abstraction. The middleware accepts a message, based filters, provides a self-adaptive framework for preventing serializes it, and injects it into the socket send buffer without buffer overflow [162]. Configuring DDS history and resource consulting any lower-layer information about the physical path limits QoS policies in proportion to the available link bandwidth connecting sender to receiver [102]. The middleware’s state is prevents both buffer overflow and link saturation [102], [138]. therefore spatially bounded, complete with respect to logical Congestion-aware transmission control introduces a feedback endpoint relationships, but blind to the physical infrastructure path from the network layer to the middleware’s injection logic, over which those relationships are realized. where DDS tracks send window occupancy and Nack volume When network load is low, this state incompleteness proceeds to actively modulate the publication rate under congestion [89]. without visible consequence because downstream buffers drain Each mitigation strategy achieves its benefit through a faster than the middleware fills them. Under saturation, however, different degree of path state awareness, but all share the the kernel socket buffer and switch queues accumulate back- structural consequence of partially undermining the path logged packets at a rate that exceeds their service rate, causing independence that spatial abstraction provides. Socket buffer subsequently injected packets to experience queuing delays resizing defers rather than eliminates saturation, addressing the independent of the physical propagation latency between sender consequence of blind forwarding without resolving its structural and receiver. Results show that when a wireless link outage cause [27]. Congestion-aware control and queue monitoring occurs, ROS 2 applications and the DDS middleware continue require the middleware to actively track physical forwarding accumulating unacknowledged samples in the HistoryCache state [89]. Adaptive injection rate control binds transmission until its capacity limit is reached [99]. Upon link recovery, the behavior to deployment-specific execution characteristics that middleware releases the accumulated backlog in an instanta- location transparency was designed to render irrelevant [161]. neous burst without regulating the transmission rate, while the QoS-based resource bounding requires the operator to configure application continues publishing new messages into the cache limits explicitly calibrated to the physical link’s capacity [102]. at its original rate, compounding the saturation [102]. Because The dimensional outcome is consistent: approaches that prethe middleware maintains no state representing the physical serve path independence defer saturation rather than eliminate path condition, it possesses no mechanism to detect this it, while those that substantively reduce forwarding overhead do accumulation or moderate its injection behavior in response. so by reintroducing physical path awareness, thereby narrowing The escalation from localized buffer saturation to system- the scope of spatial abstraction. wide delivery degradation follows the same positive feedback 3) Discovery Storm: Maintaining location transparency structure identified in Section V-B3. CSMA/CA-based wireless channel contention at the data link layer causes backlog to accu- requires the middleware to continuously construct and update mulate in the software transmission queue, resulting in packet a logical visibility graph in which every participating entity drops and a bottleneck shared across all flows on the affected possesses awareness of every other entity’s existence and interface [140]. This backlog propagates upward. Because metadata. This full-mesh visibility is a structural prerequisite of ROS 2 employs FIFO buffering, end-to-end latency increases location transparency, since without it the middleware cannot linearly with backlog depth when the publisher injection rate guarantee that newly joining entities will be incorporated exceeds the subscriber processing rate [128], so that a single into the communication graph without manual configuration. saturation event corrupts the timing of an extended sequence Prior work establishes that DDS creates and maintains a fully of subsequent messages [115]. When multiple high-frequency connected graph by design, causing all participants, topics, topics share the same physical interface, the saturation of one and services to discover one another mutually and producing 2 topic’s buffer path induces secondary saturation on co-located 𝑂 (𝑁 ) network traffic as a structural consequence [44]. The flows, spreading the impact of a single overload event across coupling between spatial scale and state management cost is therefore not a contingent implementation choice but a the entire communication graph [158]. Several approaches have been proposed to mitigate the necessary consequence of the full mutual visibility that location performance consequences of path-blind forwarding. Socket transparency demands. The total number of DDS discovery messages scales as buffer resizing offers a structurally simpler alternative by 2 raising the saturation threshold, reducing the frequency of 𝑂 (𝑃 ) with participant count, with per-node transmissions on bloat events under transient load spikes without modifying the order of 𝑃 × 𝐸, where 𝐸 is the endpoint count. Memory the injection model [158]. Local cache mechanisms discard consumption at each node is closely correlated with the number redundant data before it enters the middleware buffer, and of endpoints it must store, forcing nodes in large networks mathematical modeling of the relationship between deadline to retain endpoint information entirely unrelated to their own and depth QoS parameters enables balancing optimization that communication context [163]. In UAV swarm environments, the eliminates transmission rate and buffer size mismatches [159], default discovery process generates substantial communication

19

overhead that prevents reliable peer detection between vehicles, approach simultaneously preserves complete mutual visibility with network traffic growing nonlinearly with node count to and eliminates 𝑂 (𝑁 2 ) discovery cost, and every viable reducthe point where the discovery process itself can stall [164]. tion in state management overhead is obtained by accepting The transition from elevated discovery traffic to system- a corresponding reduction in the spatial scope of location wide determinism collapse follows a congestion-driven es- transparency. calation path. The initial burst of DDS discovery traffic 4) Intermediary Dependency: The centralized discovery during simultaneous node startup interacts with the software architectures introduced in the preceding subsection replace the transmission queue’s waiting-time threshold to cause severe flat P2P visibility graph with a hierarchical structure in which network saturation and packet drops. This interaction has contexts no longer maintain direct mutual awareness. Instead, been formally modeled as the root cause of discovery-driven packet loss in multi-robot ROS 2 systems [140]. Experiments each context registers its endpoint state with a central interdemonstrate that latency increases from approximately 5.5 ms mediary, such as a DDS Discovery Server or a Zenoh router, at five nodes to 1309 ms at twenty nodes, and that at twenty- which assumes responsibility for matching and forwarding five nodes the packet loss rate reaches 94.98%, rendering decisions [44]. This restructuring shifts visibility responsibility the network functionally unusable [137]. This escalation is from each context to one or more intermediaries, reducing particularly damaging for latency-sensitive robotic applications, per-participant overhead while concentrating the discovery because the periods of highest discovery load, such as system process at the intermediary tier. When the intermediary tier initialization and dynamic reconfiguration, coincide precisely lacks redundancy, the loss of a router suspends new endpoint with the moments when timely message delivery is most critical discovery and cross-host communication, even though alreadyestablished peer sessions on the same host continue to exchange for system safety and coordination. 2 Several approaches have been proposed to reduce the data directly [169]. Although this resolves the 𝑂 (𝑁 ) scalability discovery state management overhead and prevent discovery problem, it introduces a structural dependency whose failure storm events. Memory-efficient discovery optimization using semantics are categorically different from those of the P2P extended threshold Bloom filter vectors transmits and stores model it replaces. Notably, ROS 2 adopted P2P DDS discovery only compact filter representations of participant endpoint precisely to eliminate the single point of failure inherent in descriptors rather than full metadata records, substantially the ROS 1 centralized name server [6], meaning that the reducing both memory consumption and network transmission centralization adopted for scalability reintroduces a single point volume [165]. Domain segmentation partitions the participant of failure of the kind that P2P discovery was designed to avoid. The failure consequences of these two topologies differ not space into chip-local and vehicle-area network segments, confining discovery traffic within each segment and using merely in degree but in kind. In a flat P2P topology, the failure message bridges to forward data across boundaries, preventing of any single node degrades the visibility graph only locally, cross-segment 𝑂 (𝑁 2 ) growth while preserving inter-segment where the affected node’s endpoints become unreachable but communication [166]. Hierarchical discovery structures replace all remaining participants retain mutual awareness and continue the P2P model with a topology in which sessions register to communicate. In a centralized topology, such as a single with a designated router; measurements show reductions router with all applications in client mode, the broker mediates in discovery overhead of 97% to 99.9% relative to P2P all communication between applications. Its unavailability DDS implementations, with corresponding reductions in CPU therefore halts both endpoint discovery and ongoing data utilization and latency [167], and DDS deployments address exchange, since client-mode applications do not establish the same scalability problem through optional discovery direct sessions with one another [170]. Prior work argues that servers that similarly replace flat multicast discovery with centralized approaches are fundamentally unsuitable for reala star topology [62]. Zenoh-DDS bridges in swarm testbeds time and fault-tolerant applications, as concentrating the true achieve transparent ROS 2 connectivity while substantially values of all data objects on a single computer is architecturally lowering discovery traffic levels and eliminating the multicast unsound [42]. The severity of this vulnerability is compounded by the dependency of flat DDS discovery [125]. Each mitigation strategy reduces discovery state cost by operational position of the intermediary within the system. constraining the scope of mutual visibility, and in doing so The discovery intermediary handles the aggregated discovery partially relinquishes the full-mesh awareness on which location traffic of all contexts and must process endpoint registration and transparency depends. Domain segmentation reduces per- matching requests at a rate that scales with system size, making domain discovery cost but introduces explicit topological bound- it the node most exposed to sustained load. As systems grow, aries that applications must account for, requiring deployment- maintaining availability and throughput requires deploying level knowledge that location transparency was designed to additional intermediaries, with cost, complexity, and latency render unnecessary. Centralized discovery architectures achieve all worsening proportionally [171]. Achieving high availability the most substantial scalability improvement but concentrate further demands non-default redundancy mechanisms that lie the entire system’s visibility state in a single intermediary; outside the standard specification scope [155]. In cloud robotics prior work explicitly notes that if the intermediary fails, the deployments, this structural constraint has been formally charentire system may fail to function [163], [168]. This structural acterized through the LSC theorem, which proves that latency consequence introduces a different conflict examined in the reliability, singleton deployment, and commodity infrastructure following subsection. The structural outcome is consistent: no cannot be simultaneously achieved [172].

20

Several mechanisms have been proposed to mitigate this vulnerability. Multi-level service discovery eliminates central dependency by partitioning communication into local and widearea segments using message bridges, which decentralizes discovery and prevents any localized failures from compromising the entire system [166]. Repository federation allows multiple centralized discovery servers to collaborate, effectively eliminating the single point of failure by ensuring system robustness even if the primary repository becomes unavailable [163]. Redundant router deployment over independent network paths distributes failure risk across replicated intermediaries and allows participants to fall back to an available replica; this approach is supported by both Zenoh’s routed topology [169] and DDS deployment configurations that combine multiple discovery servers [62]. Probabilistic latency-reliability models that replicate requests across independent network interfaces and cloud servers reduce communication failure probability Fig. 3. Structural Trade-off Cycle of ROS 2 Middleware exponentially, providing a quantitative framework for trading one aspect of the anonymity-state or scale-fragility cycle, infrastructure cost against availability guarantees [172]. Each of these responses reveals the same structural cycle confirming that the Space–State conflict has not been resolved that connects this subsection to the preceding one. Intermediary within the current middleware design space. Fig. 3 synthesizes the structural trade-off cycle identified replication reduces failure risk but increases the complexity across the eleven manifestations analyzed in this section. and resource cost of maintaining consistent state across Each directed arc represents an unavoidable cost: location replicas, partially negating the operational simplicity that transparency imposes a temporal cost by concealing physical centralization provided [155]. Hybrid topologies that maintain network state from the middleware, temporal predictability limited cross-group P2P links bound the failure impact but imposes a continuity cost by forcing reliability guarantees to reintroduce partial peer-to-peer state management within be relaxed under real-time constraints, and contextual continuity 2 each group, reproducing a bounded version of the 𝑂 (𝑁 ) imposes a transparency cost by requiring physical identity inforcost that centralization was designed to eliminate [169]. mation that spatial abstraction structurally withholds. Because Automatic P2P fallback preserves communication continuity all three mechanisms draw upon the same bounded shared after intermediary failure but does so by reverting to precisely resources, namely execution capacity, network bandwidth, and the scalability problem that motivated centralization [44]. This buffer memory, fully satisfying one dimension imposes pressure cycle constitutes a structural boundary of the present design on at least one of the others. No architecture within the current space. Eliminating the single point of failure reintroduces middleware design space resolves all three simultaneously; distributed state cost, while eliminating distributed state cost reintroduces the single point of failure. The structural outcome any proposed mitigation navigates the trade-off surface rather is consistent: no architecture within the current middleware than escaping it. This unresolved tension is not an artifact of implementation choices but a structural property of distributed design space resolves both constraints simultaneously [171]. robotic middleware under constrained deployment conditions. Table IV summarizes the 39 studies surveyed under the Section VI addresses this structural boundary at two levels: imSpace–State conflict, the largest of the three groups. Wireless mediate gaps in current middleware practice that can be closed evaluations dominate, consistent with the observation that without architectural redesign, and long-term research direcnode anonymity and path-blind forwarding manifest most tions that require rethinking the foundations of how Space, Time, severely under intermittent connectivity, where the gap between and State are jointly realized in distributed robotic systems. logical endpoint state and physical network reality is widest. A The central finding that emerges from this review is not that notable portion of entries lack a specified evaluation platform, individual solutions are inadequate, but that every proposed concentrated among architectural analyses and specification- mitigation trades one dimensional guarantee for another. Studies level studies that provide the structural foundation for the addressing the Space–Time conflict consistently demonstrate discovery storm and intermediary dependency subgroups. The that reducing serialization cost, fragmentation loss, or multicast key approach column reveals a mitigation landscape that instability requires the middleware to reintroduce physicalis markedly more diverse than in the other two conflict layer awareness that location transparency was designed to pairs, spanning identity enforcement, path-aware congestion conceal. Studies addressing the Time–State conflict reveal that control, Bloom-filter-based discovery, domain segmentation, the control traffic and retransmission mechanisms required to NDN-based querying, and router federation. This diversity is maintain contextual continuity consume the same execution itself a structural observation: unlike the Space–Time conflict, and network resources that temporal predictability depends where mitigations cluster around two recognizable categories, upon, and that relaxing reliability guarantees is the only the Space–State conflict has not converged on a dominant operationally viable path to recovering bounded latency under architectural response. Every proposed approach addresses congestion. Studies addressing the Space–State conflict show

21

TABLE IV TAXONOMY OF L ITERATURE A DDRESSING THE S PACE –S TATE C ONFLICT [Ref]

Protocol

Application Domain

Evaluation Platform Wired

[172] [128] [161] [168] [171]

Robotics, Auto.

Embedded, Workstation Workstation, Simulator Workstation

Robotics, IIoT

-

[148] [159] [160] [27] [137] [115] [156] [140] [138] [102] [99] [6] [162] [154] [149] [89] [165] [163] [42] [155] [166] [158] [107] [86] [127] [169] [132] [125] [164] [167] [170] [44] [157] [143]

Network WireLocal less Host ✓ ✓ ✓

✓

✓

Sync-scaling

Embedded, Workstation

✓ ✓

✓ ✓ ✓ ✓ ✓ ✓ ✓

✓ ✓ ✓

Buffer-modeling Deadline-balancing Path-blind Wireless-scaling Process-overhead Identity-enforce Discovery-saturation Control-dependency Burst-analysis Burst-analysis P2P-motivation Self-adaptive Anonymity-model Time-filtering AutoThrottle Bloom-filter Bloom-filter Centrality-risk Broker-analysis Domain-segment Buffer-sizing Complexity-modeling Spec-analysis Consistency-model Router-federation Lock-free Swarm-bridging UAV-discovery Router-overhead Failure-semantics P2P-cost Lifecycle-mgmt Protocol-comparison

✓ ✓

Simulator

✓ ✓ ✓ ✓ ✓ ✓

Workstation

✓ ✓

✓ ✓ ✓ ✓

✓ Workstation IIoT

✓ ✓ ✓ ✓

✓ ✓ ✓

-

(None) Zenoh

Both

Robotics, IIoT Robotics, IIoT, Auto. Robotics, IIoT Robotics

Embedded Workstation, Simulator Workstation

✓ ✓ ✓

✓ ✓ ✓ ✓

Workstation Embedded, Simulator Embedded, Simulator Embedded

✓ ✓

✓ ✓ ✓

✓

IIoT Auto.

LSC-theorem Executor-modeling Rate-adaptation Intermediary-risk Centrality-cost

✓

Robotics

Auto.

Key Approach

Embedded, Workstation, Simulator

Embedded

DDS

Research Type Evalu- System Modelation ing Design ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓

Embedded, Workstation

that the anonymity and full-mesh visibility on which location transparency relies simultaneously prevent lifecycle state from being tracked and drive discovery overhead that grows with system scale, while the centralized architectures introduced to contain that growth reintroduce a single point of failure of the kind that peer-to-peer discovery was designed to avoid. Across all three pairs, the structural conclusion is the same: proposed solutions navigate the trade-off surface rather than escape it, and the boundaries of that surface are determined by the shared resource constraints under which all three dimensions must be simultaneously realized.

✓ ✓ ✓ ✓ ✓

✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓

✓

✓

✓

✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓

✓ ✓ ✓

✓ ✓

proposes long-term architectural directions that target the root causes of the dimensional conflicts identified in Section V. A. Structural Gaps

VI. S TRUCTURAL G APS AND R ESEARCH ROADMAP

This subsection identifies three structural gaps in current middleware practice, namely QoS semantic loss, evaluation inadequacy, and security overhead. These gaps are not derived from the dimensional conflict analysis but represent independent deficiencies in how middleware is configured, evaluated, and secured in practice. Each admits targeted improvements within the current design space, yet none has been comprehensively resolved in the existing literature.

The dimensional conflict analysis in Section V characterizes the trade-off surface that current middleware architectures must navigate. Navigating this surface effectively, however, depends on resolving practical deficiencies that exist independently of the dimensional conflicts themselves. This section addresses both concerns at two distinct levels. The first level identifies structural gaps in current middleware design and operational practice whose resolution is a prerequisite for reliable deployment under realistic conditions. The second level

1) QoS Semantic Loss: QoS semantic loss refers to the degradation of QoS enforcement at the boundary between the middleware layer and the underlying OS and physical layer. Temporal predictability has repeatedly been undermined because logical QoS configurations are not propagated into OS kernel scheduling or network-level priority mechanisms. This enforcement failure produces priority inversions and unpredictable delivery latency under congested wireless conditions [131], [173]. In wide-area deployments, the absence of a standard mechanism

22

for end-to-end QoS propagation further causes bandwidth 2) Evaluation Inadequacy: Evaluation inadequacy refers and latency violations that the middleware cannot detect or to the failure of current evaluation methodologies to capture compensate [119]. This breakdown has been systematically the emergent degradation that arises under realistic distributed identified as a major deployment obstacle in DDS-based deployment conditions. Isolated component benchmarks consissystems [168]. Its recurrence across wireless deployments, tently fail to surface the latency fluctuations and network saturawide-area networks, and real-time control scenarios confirms tion that characterize operational robotic systems, because they that it is not an isolated tuning problem but a structural gap rely on static payloads or uncongested traffic conditions that in how QoS intent is realized across the communication stack. conceal the architectural costs of spatial abstraction [96], [105], The structural origin of this gap lies in how the middleware [112]. Real-time scheduling and intra-process optimization maps application-level QoS parameters to physical transport studies conducted without realistic network contention produce mechanisms. QoS configurations are treated as isolated per- characterizations that do not transfer to multi-host wireless endpoint attributes rather than cross-layer properties with deployments [178], [179]. This pattern is not attributable to independency chains that span the execution, transport, and dividual experimental choices but reflects a structural deficiency network layers [138]. The strict architectural separation between in how middleware evaluation is currently scoped [180], [181]. the RMW interface and the OS prevents the middleware The structural origin of this gap lies in the disjointed operafrom directly influencing hardware acceleration pipelines or tional domains of physics-based robot simulators and discretenetwork scheduling queues, creating a systematic mismatch event network simulators, which prevents the Perception– between logical intent and physical packet processing [72]. This Action–Communication loop from being evaluated as an mismatch does not require a fundamental redesign of the core integrated whole. Because the two simulation domains advance communication architecture to address, as the enforcement logic time independently and apply different abstraction models and the translation infrastructure surrounding it can be improved to shared events, the emergent interactions among discovery independently within the current design space [136], [151]. traffic, reliability retransmission, and application data exchange Prior work has proposed modeling and validation approaches cannot be faithfully reproduced within either domain alone. that reduce configuration errors and improve semantic consis- This mismatch does not require a redesign of the ROS 2 midtency within the middleware layer. Automated dependency dleware architecture to address, as the evaluation infrastructure validation and QoS capability profiling at design time can surrounding the middleware can be improved independently prevent semantic inconsistencies between component ports within the current design space [150], [182]–[184]. before execution begins [138], [174]. Domain-specific modPrior work has proposed co-simulation and domain adapeling languages and generative frameworks can synthesize tation approaches that improve evaluation fidelity without semantically compatible policy configurations and eliminate modifying the middleware itself. Synchronized co-simulation trial-and-error tuning by producing correct-by-construction frameworks enforce consistent temporal boundaries across parameter sets prior to deployment [175], [176]. Mathematical heterogeneous simulation components, and modular wrappers optimization over conflicting QoS parameters such as publica- around existing robotic and network simulators substantially tion rate and buffer depth provides a further tractable path to improve the fidelity of emulated traffic behavior. Deep learningreducing packet loss and memory pressure without modifying based domain adaptation provides a tractable path to sim-tothe internal data exchange logic of the middleware [177]. These real transfer by aligning estimated network parameters with contributions improve configuration correctness and reduce observed physical behavior, reducing the divergence between semantic inconsistency within the middleware boundary, but simulated evaluation results and operational outcomes [185], they do not resolve the underlying enforcement gap: QoS intent [186]. These contributions improve evaluation fidelity within formulated at the application layer still fails to propagate into individual simulation domains, but they do not resolve the OS kernel scheduling or physical network priority mechanisms. underlying integration gap: the emergent interactions among Narrowing this gap requires a targeted bridging component discovery traffic, reliability retransmission, and application data that connects middleware-level QoS semantics to lower-layer exchange still cannot be characterized as a unified whole under execution and scheduling mechanisms. Rather than redesigning realistic scale and contention. the middleware architecture, this component would either Narrowing this gap requires a targeted integration of robotic translate existing ROS 2 QoS parameters into a form that OS and network simulation environments into unified testbeds schedulers and network interface queues can natively interpret, that reflect the scale and contention characteristics of physical or intercept middleware-level policy expressions and forward deployments. Open multi-robot testbeds capable of exercising them to the appropriate lower-layer primitives such as Linux publish-subscribe middleware under varying traffic densities traffic control, CPU scheduling classes, or hardware offload and node counts would allow the scalability boundaries queues. Such a connector would allow temporal constraints imposed by discovery storms and control traffic overhead formulated at the application layer to be enforced continuously to be quantified before physical deployment [89], [125], down the communication stack without requiring changes to [187]. Memory-efficient discovery protocols and filtered state the RMW interface or the application programming model. propagation mechanisms should be systematically included Developing and standardizing this bridging layer within the in these environments to ensure that state management costs ROS 2 ecosystem represents a concrete and tractable near-term are characterized alongside data exchange performance [163], improvement that does not presuppose a fundamental redesign [165]. Developing and standardizing such integrated evaluation of the core middleware architecture. infrastructure within the ROS 2 ecosystem represents a concrete and tractable near-term improvement that does not presuppose a fundamental redesign of the core middleware architecture.

23

3) Security Overhead: Security overhead refers to the Narrowing this gap requires a targeted mechanism that structural incompatibility between security enforcement and structurally separates security verification from the latencytemporal predictability under realistic deployment conditions. critical communication path. Rather than redesigning the Enabling mandatory security plugins, including encryption and middleware architecture, this mechanism would intercept authentication, introduces latency and throughput degradation authentication and attestation operations and delegate them that directly competes with time-critical data exchange [188], to a dedicated hardware-backed execution context, so that [189]. Heterogeneous implementations further exhibit interop- cryptographic overhead no longer competes with time-sensitive erability failures and disproportionate computational overhead callbacks on shared execution resources. Such a separation when strict security policies are enforced at the transport would allow security guarantees to be maintained continuously boundary [190], [191]. Cryptographic operations do not impose without consuming the bounded execution capacity that a fixed additive cost but instead interact with the same execution real-time data exchange depends upon. Developing and and network resources that temporal predictability depends standardizing this separation mechanism within the ROS 2 upon, compounding timing nondeterminism under load [192]. security architecture represents a concrete and tractable nearThe structural origin of this gap lies in the decoupling of term improvement that does not presuppose a fundamental security verification from the middleware’s core discovery and redesign of the core middleware architecture. state management dynamics. Unprotected discovery services Although each gap arises in a distinct operational doand software-level policy evaluation expose the system to main, they are not independent. QoS semantic loss prevents replay attacks and identity spoofing, and the resulting need for middleware-level policies from being faithfully enforced at the redundant cryptographic checks amplifies resource consumption transport and OS layers, and evaluation inadequacy conceals at precisely the moments when discovery and liveliness traffic the emergent consequences of this enforcement failure under are already competing for shared capacity [193], [194]. The realistic deployment conditions. Evaluation inadequacy further disjointed management of security artifacts further allows ad- prevents security overhead from being accurately characterversarial entities to exploit the gap between logical permissions ized, because isolated benchmarks conducted without realistic and physical execution, bypassing access controls through the traffic contention cannot reproduce the timing nondeterminism same anonymity mechanisms that location transparency relies that cryptographic operations introduce under load. Security upon [195], [196]. This mismatch does not require a redesign overhead compounds both by introducing additional resource of the spatial abstraction layer to address, as the overhead contention that interacts with the same execution and network originates in how cryptographic operations are integrated resources that temporal predictability depends upon. Addressing into the execution path rather than in the communication any one of these gaps in isolation therefore provides incomplete model itself, and the surrounding security infrastructure can be relief; progress toward robust middleware deployment requires improved independently within the current design space [197]. that all three be pursued in parallel. Prior work has proposed policy provisioning and cryptographic execution approaches that reduce overhead without modifying the core middleware architecture. Procedurally B. Research Roadmap The research directions presented in this section target the generated access control policies can eliminate manual misconfigurations and reduce the computational footprint of root cause of the dimensional conflicts, namely the shared exeauthorization checks during endpoint matching, without altering cution boundary and structural coupling among the three dimenthe QoS or discovery mechanisms that govern communication sions that render their simultaneous satisfaction structurally conbehavior [198]. Delegating cryptographic operations to trusted strained under shared resource bounds. Each direction directly execution environments isolates verification workloads from addresses a specific structural conflict identified in Section V, the primary communication pipeline, preventing security en- and together they outline a long-term trajectory toward middleforcement from consuming the execution resources required ware architectures that renegotiate, rather than merely navigate, by latency-sensitive callbacks [199]. Trusted Platform Mod- the trade-off surface defined by Space, Time, and State. ule (TPM)-based remote attestation integrated into the existing 1) Cross-Layer Co-Design: The ROS 2 communication stack handshake protocol further provides continuous hardware- is hierarchically structured across user space, RCL, RMW, backed validation of participant identity, structurally preventing middleware, and the kernel OS, with information flowing spoofing while preserving the location transparency on which strictly in one direction [33]. Upper layers issue configurations spatial abstraction depends [200]. At the architectural level, and commands to lower layers, but the runtime state of these Zenoh adopts a boundary-security model where security is underlying components is never fed back to the application enabled selectively at chosen boundaries rather than uniformly level. The middleware therefore remains unaware of OS-level across all communication, so that the throughput and latency scheduling dynamics and physical network conditions, while cost of cryptographic operations applies only to traffic that applications cannot observe internal middleware states [201], requires it [45]. These contributions reduce the per-operation [202]. This structural unidirectionality is the fundamental cost of security enforcement, but they do not resolve the source of the Space–Time conflict, as QoS parameters lose their underlying coupling gap: cryptographic verification remains semantic enforcement across these decoupled boundaries [203]. structurally entangled with the same execution and network Addressing this limitation requires a cross-layer co-design resources that discovery, liveliness maintenance, and data approach that enables bidirectional interaction across the exchange depend upon.

24

communication stack [204]. The core of this approach is the leaves distributed components unable to reliably cope with the bidirectional integration between the RCL and the middleware intermittent connectivity and fluctuating resource availability via the RMW, so that middleware states are dynamically characteristic of dynamic edge environments [211]. propagated upward while the execution context of the RCL Addressing this limitation without dismantling the benefits actively shapes middleware behavior. The interaction between of spatial abstraction requires an adaptive strategy that captures the kernel OS and the middleware must rely on indirect state physical constraints with minimal latency and computational estimation rather than direct coupling [205]. This strategy overhead. Rather than directly exposing raw physical network allows the middleware to recognize physical infrastructure states to the execution layer, adaptive middleware must conconstraints without compromising the location transparency tinuously estimate underlying link capacity using observable, that the Space dimension requires [206]. This direction focuses lightweight indicators [212]. Monitoring accessible endpoint specifically on the upward surfacing of middleware states and metrics such as acknowledgment timing, message delivery the indirect estimation of lower-layer conditions. age, and internal queue delays allows the system to indirectly Several open problems must be addressed before this infer physical constraints and congestion boundaries without bidirectional paradigm can be realized in operational robotic violating location transparency. Based on these context-aware middleware. Expanding the RMW interface for bidirectional estimations, the middleware can adapt its transmission behavior state exchange must preserve backward compatibility with and failover mechanisms to sustain temporal predictability established application programming models [207]. Estimation without introducing rigid cross-layer dependencies [213]. mechanisms that infer kernel OS conditions without directly Several open problems must be resolved before adaptive exposing low-level system states require principled design middleware can be operationalized in distributed robotic deployand standardization before they can be deployed reliably ments. Achieving a deterministic integration of fault-tolerance across heterogeneous platforms. The continuous monitoring mechanisms with real-time scheduling remains challenging, as and state-sharing processes inherent to bidirectional interaction dynamic recovery procedures frequently disrupt strict temporal impose additional execution and network load, and robust deadlines [214]. Formalizing consistency models that tolerate methodologies are needed to ensure that this overhead does not bounded state divergence without destabilizing closed-loop itself degrade the temporal predictability of time-critical control control remains a further necessity, particularly for deployments loops [208]. Resolving these problems is a prerequisite for mid- where intermittent connectivity prevents liveliness and history dleware infrastructure that structurally closes the unidirectional restoration mechanisms from operating under their design information gap across the ROS 2 communication stack. assumptions [215]. Resolving these problems requires novel The fundamental difficulty of cross-layer co-design lies in cross-dimensional algorithms that quantitatively model the the fact that the unidirectionality it seeks to overcome is not an trade-offs among latency, replication overhead, and network accidental design choice but a deliberate architectural boundary topology, establishing a principled foundation for middleware that preserves modularity, portability, and vendor independence that adapts across the Space, Time, and State dimensions across the ROS 2 ecosystem. Introducing upward state propa- simultaneously rather than optimizing each in isolation. gation through the RMW interface risks exposing middlewareThe core difficulty of adaptive middleware lies in the internal representations to the RCL, creating implicit coupling constraint that physical inference must be performed using between layers that the RMW abstraction was specifically only information that is already visible at the middleware designed to prevent. Similarly, indirect OS state estimation boundary, without penetrating the spatial abstraction that the requires the middleware to maintain persistent runtime models middleware is obligated to preserve. Observable endpoint of lower-layer behavior, which must remain accurate across metrics such as acknowledgment timing and queue delays heterogeneous hardware platforms, OS configurations, and are indirect proxies that reflect physical conditions only under network interface drivers without direct access to the state specific traffic patterns, and their predictive accuracy degrades being estimated. The tension between the architectural openness precisely under the congestion and link variability conditions required for cross-layer feedback and the strict boundary where adaptation is most urgently needed. Furthermore, the enforcement required for middleware portability means that any adaptation logic itself consumes execution resources on the realization of this direction must resolve a structural conflict same threads and queues that carry time-critical callbacks, that is internal to the ROS 2 design philosophy itself. meaning that the overhead of estimating and responding 2) Adaptive Middleware: The structural conflict between to physical constraints competes directly with the temporal predictability it is intended to protect. Any adaptive strategy the Space and Time dimensions isolates logical endpoint must therefore operate within a narrow execution budget abstractions from physical network states, preventing the middleware execution layer from perceiving underlying link that shrinks as network conditions deteriorate, imposing a fluctuations and congestion. Complete decoupling of the appli- self-limiting constraint on the sophistication of the inference cation from the deployment topology removes the opportunity and adaptation mechanisms that can be practically deployed. for the middleware to adapt its transmission behavior to deteriorating network conditions [209]. Attempts to resolve these inefficiencies exclusively at the application layer are structurally insufficient, as the application lacks visibility into lower-level network conditions [210]. This rigid separation

3) Decoupled State Architecture: The Space–State conflict arises because discovery and state management mechanisms are structurally coupled to the same resources required for temporal predictability, preventing spatial scalability and state continuity from being simultaneously sustained within the current architec-

25

ture [216], [217]. Fully meshed peer-to-peer topologies carry an begins from a state of mutual ignorance among nodes that have 𝑂 (𝑁 2 ) metadata exchange cost, while centralized architectures never maintained direct visibility of one another. Reconstructing concentrate the state management burden at a single point sufficient mutual awareness to sustain communication during of failure [218], [219]. The continuous metadata exchange in the fallback phase requires a burst of discovery traffic at distributed topologies directly competes with latency-sensitive precisely the moment when network conditions are most data transmission, whereas centralized intermediaries introduce stressed, reproducing a bounded version of the discovery potential network bottlenecks [220]. This architectural di- storm dynamics identified in Section V. The transition back chotomy establishes a structural tension that remains unresolved to centralized operation introduces a symmetric problem: the within the current middleware design space [221]. broker must reconcile the divergent state accumulated across Addressing this tension without permanently committing distributed participants during the fallback interval, and the to either extreme requires an adaptive hybrid state architecture cost of this reconciliation scales with both the duration of the that maintains a centralized structure for baseline efficiency fallback and the rate of topology change during that period. while falling back to decentralized mechanisms under varying Taken together, these three directions represent a qualitative failure and scaling conditions [222], [223]. During stable departure from the mitigation strategies surveyed in Section V. operation, this approach exploits the low computational Where existing approaches improved one dimension by partially and network overhead of centralized brokers, mitigating the relinquishing another, each roadmap direction attempts to discovery traffic typically associated with dynamic node restructure the underlying mechanism so that both dimensions participation [224], [225]. When the system encounters of the targeted conflict can be addressed without forcing an intermediary broker failures, severe network partitions, or explicit sacrifice. Cross-layer co-design pursues bidirectional abrupt surges in node density, the architecture transitions to a state visibility without dismantling the modularity boundaries peer-to-peer mechanism to preserve contextual continuity [197]. that spatial abstraction depends upon. Adaptive middleware This structural flexibility allows the middleware to combine pursues physical constraint awareness without exposing dethe spatial efficiency of hierarchical control with the fault ployment topology to the application layer. Decoupled state tolerance of distributed state retention [226], [227]. architecture pursues the efficiency of centralization without Several open problems must be addressed before a decoupled permanently surrendering the fault tolerance of distributed state architecture can be operationalized in distributed robotic operation. None of these directions eliminates the structural deployments. Minimizing transition costs and establishing tension identified in Section V; the shared resource bounds that precise criteria for triggering the fallback from centralized to produce dimensional conflict remain a physical reality. What distributed modes remain open design questions [228], [229]. they collectively offer is a principled basis for operating closer Reintegrating the distributed state accumulated during the to the boundary of what those resource bounds permit, rather fallback phase into a unified centralized structure upon recovery than accepting the conservative compromises that characterize requires mechanisms that prevent data conflicts and logical current deployments. Realizing this potential requires sustained inconsistencies [230], [231]. Rapid structural shifts between the research investment across middleware design, OS integration, two operational modes must not disrupt or delay time-critical and distributed systems theory, guided by the evaluation communication sessions already in progress across partitioned infrastructure and cross-layer modeling tools. domains [232]. Resolving these problems requires deeper integration of dynamic reconfiguration logic with underlying VII. C ONCLUSION transport interfaces, so that location transparency is preserved This paper has presented a systematic survey of ROS 2 across volatile network boundaries [233]. middleware through the lens of three structural dimensions, Recent developments illustrate partial progress in this di- namely Space, Time, and State. We first analyzed the arrection. Zenoh introduces a Regions architecture that replaces chitectural constructs and operational dynamics of ROS 2 the fixed router, peer, and client tiers with arbitrary-depth middleware, encompassing discovery, data exchange, and state nested topologies and operator-defined gateways, structurally management mechanisms across DDS and Zenoh. Building on addressing the static-topology dimension of the problem [234]. this foundation, we formalized Space as the requirement for The dynamic case that this direction targets remains open, location transparency, Time as the requirement for temporal since runtime transition between centralized and peer-to-peer predictability, and State as the requirement for contextual operation under broker failure or severe partition still triggers continuity. Through a comprehensive review of 94 middlewarea discovery burst from a state of mutual ignorance, and the focused studies, we mapped the structural trade-offs among divergent state accumulated during the fallback interval must these dimensions into three conflict pairs, Space–Time, Time– still be reconciled on recovery. These are open challenges State, and Space–State, and identified eleven distinct manacross distributed-systems research, not unique to any single ifestations through which these conflicts propagate across middleware. middleware, OS, and physical layers. A central finding of this survey is that there is no silThe core difficulty of the hybrid fallback architecture lies ver bullet for robotic middleware design. Every mitigation in the asymmetry between the two operational modes it must strategy examined across the eleven manifestations improves support. Centralized operation accumulates a globally consistent one dimension by partially relinquishing the guarantees of state view at the broker, but this view is not replicated across another. Location transparency imposes a cost on temporal participants, meaning that a fallback to peer-to-peer mode

26

performance by concealing physical network state from the middleware. Temporal predictability can only be preserved by relaxing the reliability guarantees that contextual continuity depends upon. Contextual continuity, in turn, demands physical identity information that spatial abstraction is designed to withhold. Because all three dimensions compete for the same bounded shared resources, namely execution capacity, network bandwidth, and buffer memory, satisfying any one dimension fully exerts pressure on at least one of the others, and any proposed mitigation navigates the trade-off surface rather than escaping it. Middleware designers and practitioners must therefore accept that deploying a robotic system always entails an explicit or implicit choice of which dimensional guarantee to prioritize and which to partially sacrifice, and this choice should be made deliberately rather than by default. Looking ahead, the primary research challenge is not to escape the trade-off surface but to navigate it more efficiently, by designing middleware architectures that maximize the achievable guarantees across all three dimensions simultaneously within the constraints imposed by shared resources. The roadmap directions proposed in this paper, namely cross-layer co-design, adaptive middleware, and state architecture, each represent a principled step toward shrinking the region of the trade-off space in which current systems operate, rather than merely shifting cost from one dimension to another. This challenge is acquiring renewed urgency in the era of Physical AI, where vision-language-action models, embodied agents, and large-scale multi-robot coordination are driving an unprecedented increase in the volume, heterogeneity, and latencysensitivity of data exchanged over robotic networks. As the communication demands of intelligent robotic systems continue to expand, the architectural choices embedded in middleware design will increasingly determine whether distributed robotic platforms can operate reliably and responsively in the openworld environments they are expected to inhabit. R EFERENCES [1] Open Robotics, “ROS metrics,” [Online]. Available: http://metrics.ros. org/, 2026. [2] K. Scott and T. Foote, “2025 ROS metrics report,” Open Source Robotics Foundation (OSRF), Tech. Rep., 2025. [Online]. Available: https://discourse.openrobotics.org/t/2025-ros-metrics-report/52575 [3] J. Zhang, F. Keramat, X. Yu, D. M. Hernández, J. P. Queralta, and T. Westerlund, “Distributed robotic systems in the edge-cloud continuum with ROS 2: A review on novel architectures and technology readiness,” in Proc. 2022 Seventh Int. Conf. on Fog and Mobile Edge Computing (FMEC). IEEE, 2022, pp. 1–8. [4] L. Fu, G. Kapoor, L. Militano, G. T. Carughi, and T. M. Bohnert, “IoRT ROS 2 applications: Evaluating Zenoh and VPN for robotic networking in the edge-cloud continuum,” in Proc. 2025 IEEE Symp. on Computers and Communications (ISCC). IEEE, 2025, pp. 1–6. [5] X. An, C. Wu, Y. Lin, M. Lin, T. Yoshinaga, and Y. Ji, “Multi-robot systems and cooperative object transport: Communications, platforms, and challenges,” IEEE Open J. of the Computer Society, vol. 4, pp. 23–36, 2023. [6] 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, p. eabm6074, 2022. [7] J. M. Cruz, A. Romero-Garcés, J. P. B. Rubio, R. M. Robles, and A. B. Rubio, “A DDS-based middleware for quality-of-service and high-performance networked robotics,” Concurrency and Computation: Practice and Experience, vol. 24, no. 16, pp. 1940–1952, 2012. [8] B. Al-Madani, S. Hasan, A. Abualhassan, and F. Aliyu, “Integrating Data Distribution Service (DDS) in smart traffic systems: A comprehensive review,” Computer, vol. 58, no. 2, pp. 25–34, 2025.

[9] J.-B. Castillo-Sánchez, E. González-Parada, and J.-M. Cano-García, “A novel testbed for evaluating ROS 2 robot swarm wireless communications,” in Proc. 2024 IEEE 22nd Mediterranean Electrotechnical Conf. (MELECON). IEEE, 2024, pp. 68–73. [10] S. Agarwal, A. Ribeiro, and V. Kumar, “A scalable multi-robot framework for decentralized and asynchronous perception-actioncommunication loops,” arXiv preprint arXiv:2309.10164, 2025. [11] S. Kong, H. Zhang, C. Ye, Y. Xu, and A. Li, “Design of a multimodal control system based on ROS 2: A hierarchical architecture for real-time human-robot collaboration,” in Proc. 2025 7th Int. Conf. on Data-driven Optimization of Complex Systems (DOCS). IEEE, 2025, pp. 441–446. [12] M. Groshev, G. Baldoni, L. Cominardi, A. De La Oliva, and R. Gazda, “Edge robotics: Are we ready? an experimental evaluation of current vision and future directions,” Digital Communications and Networks, vol. 9, no. 1, pp. 166–174, 2023. [13] A. Al-Batati, A. Koubaa, K. Gabr, M. Abdelkader, and H. Aloquaily, “ROS 2 in a nutshell: A survey,” ACM Computing Surveys, 2025. [14] L. Naury, A. Gouguet, G. Lozenguez, and L. Fabresse, “Communication isolation for multi-robot systems using ROS 2,” in Proc. 40th ACM/SIGAPP Symp. on Applied Computing, 2025, pp. 850–858. [15] L. Hietasalo, “Overview and performance analysis of robotic software framework Flexbot,” Master’s thesis, Tampere University, 2024. [16] D. Casini, T. Blaß, I. Lütkebohle, and B. Brandenburg, “Response-time analysis of ROS 2 processing chains under reservation-based scheduling,” in Proc. 31st Euromicro Conf. on Real-Time Systems. Schloss Dagstuhl, 2019, pp. 1–23. [17] H. Teper, T. Betz, M. Günzel, D. Ebner, G. Von Der Brüggen, J. Betz, and J.-J. Chen, “End-to-end timing analysis and optimization of multiexecutor ROS 2 systems,” in Proc. 2024 IEEE 30th Real-Time and Embedded Technology and Applications Symp. (RTAS). IEEE, 2024, pp. 212–224. [18] Y. Tang, N. Guan, X. Jiang, X. Luo, and W. Yi, “Real-time performance analysis of processing systems on ROS 2 executors,” in Proc. 2023 IEEE 29th Real-Time and Embedded Technology and Applications Symp. (RTAS). IEEE, 2023, pp. 80–92. [19] Y. Tang, Z. Feng, N. Guan, X. Jiang, M. Lv, Q. Deng, and W. Yi, “Response time analysis and priority assignment of processing chains on ROS 2 executors,” in Proc. 2020 IEEE Real-Time Systems Symp. (RTSS). IEEE, 2020, pp. 231–243. [20] L. Dust and S. Mubeen, “Dynamic priority scheduling for periodic systems using ROS 2,” in Proc. Int. Conf. on Engineering of ComputerBased Systems. Springer, 2023, pp. 239–243. [21] S. Liu, X. Jiang, N. Guan, Z. Wang, M. Yu, and W. Yi, “RTeX: An efficient and timing-predictable multithreaded executor for ROS 2,” IEEE Trans. on Computer-Aided Design of Integrated Circuits and Systems, vol. 43, no. 9, pp. 2578–2591, 2024. [22] J. Staschulat, I. Lütkebohle, and R. Lange, “The rclc executor: Domainspecific deterministic scheduling mechanisms for ROS applications on microcontrollers: Work-in-progress,” in Proc. 2020 Int. Conf. on Embedded Software (EMSOFT). IEEE, 2020, pp. 18–19. [23] Y. Yang and T. Azumi, “Exploring real-time executor on ROS 2,” in Proc. 2020 IEEE Int. Conf. on Embedded Software and Systems (ICESS). IEEE, 2020, pp. 1–8. [24] D. Enright, Y. Xiang, H. Choi, and H. Kim, “PAAM: A framework for coordinated and priority-driven accelerator management in ROS 2,” in Proc. 2024 IEEE 30th Real-Time and Embedded Technology and Applications Symp. (RTAS). IEEE, 2024. [25] H. Choi, Y. Xiang, and H. Kim, “PiCAS: New design of priority-driven chain-aware scheduling for ROS 2,” in Proc. 2021 IEEE 27th Real-Time and Embedded Technology and Applications Symp. (RTAS). IEEE, 2021, pp. 251–263. [26] T. Xu, X. Chen, C. Wu, J. Wang, R. Zheng, D. Liu, Y. Tan, A. Ren, and J. Li, “3DS: An efficient DPDK-based Data Distribution Service for distributed real-time applications,” in Proc. 2022 IEEE 24th Int. Conf. on High Performance Computing & Communications (HPCC/DSS/SmartCity/DependSys). IEEE, 2022, pp. 1283–1290. [27] T. Blass, A. Hamann, R. Lange, D. Ziegenbein, and B. B. Brandenburg, “Automatic latency management for ROS 2: Benefits, challenges, and open problems,” in Proc. 2021 IEEE 27th Real-Time and Embedded Technology and Applications Symp. (RTAS). IEEE, 2021, pp. 264–277. [28] L. Qi, X. Zhang, H. Tan, H. Chen, and Y. Wang, “A novel open and efficient robot development framework based on Data Distribution Service orchestration for agile manufacturing,” Robotics and ComputerIntegrated Manufacturing, vol. 96, p. 103067, 2025. [29] G. Baldoni, J. Loudet, L. Cominardi, A. Corsaro, and Y. He, “Facilitating distributed data-flow programming with Eclipse Zenoh: The ERDOS

27

case,” in Proc. 1st Workshop on Serverless Mobile Networking for 6G Communications, 2021, pp. 13–18. [30] S. Lee, J. Chae, and K.-J. Park, “Harness engineering for Physical AI: Robot middleware is the harness layer,” arXiv preprint arXiv:2606.09416, 2026. [31] Z. Li, A. Hasegawa, and T. Azumi, “Autoware_Perf: A tracing and performance analysis framework for ROS 2 applications,” J. of Systems Architecture, vol. 123, p. 102341, 2022. [32] A. Bonci, F. Gaudeni, M. C. Giannini, and S. Longhi, “Robot Operating System 2 (ROS 2)-based frameworks for increasing robot autonomy: A survey,” Applied Sciences, vol. 13, no. 23, p. 12796, 2023. [33] Open Robotics, “Internal ROS 2 interfaces,” [Online]. Available: https://docs.ros.org/en/kilted/Concepts/Advanced/ About-Internal-Interfaces.html, accessed: Mar. 28, 2026. [34] ——, “Different ROS 2 middleware vendors,” [Online]. Available: https://docs.ros.org/en/kilted/Concepts/Intermediate/ About-Different-Middleware-Vendors.html, accessed: Mar. 28, 2026. [35] ——, “ROS 2 middleware implementations,” [Online]. Available: https://docs.ros.org/en/kilted/Concepts/Advanced/ About-Middleware-Implementations.html, accessed: Mar. 28, 2026. [36] ——, “Changes between ROS 1 and ROS 2,” [Online]. Available: https://design.ros2.org/articles/changes.html, accessed: Mar. 28, 2026. [37] ——, “Creating an RMW implementation,” [Online]. Available: https://docs.ros.org/en/kilted/Tutorials/Advanced/ Creating-An-RMW-Implementation.html, accessed: Mar. 28, 2026. [38] ——, “Executors,” [Online]. Available: https://docs.ros.org/en/kilted/ Concepts/Intermediate/About-Executors.html, accessed: Mar. 28, 2026. [39] P. A. Bernstein, “Middleware: A model for distributed system services,” Communications of the ACM, vol. 39, no. 2, pp. 86–98, 1996. [40] W. Emmerich, “Software engineering and middleware: A roadmap,” in Proc. Conf. on the Future of Software Engineering, 2000, pp. 117–129. [41] Open Robotics, “ROS 2 Kilted Kaiju released,” [Online]. Available: https://www.openrobotics.org/blog/2025/5/23/ ros-2-kilted-kaiju-released, accessed: Mar. 28, 2026. [42] G. Pardo-Castellote, “OMG Data Distribution Service: Architectural overview,” in Proc. 23rd Int. Conf. on Distributed Computing Systems Workshops. IEEE, 2003, pp. 200–206. [43] ZettaScale Technology, “What is Zenoh?” [Online]. Available: https: //zenoh.io/docs/overview/what-is-zenoh/, accessed: Mar. 28, 2026. [44] Open Robotics, “ROS 2 alternative middleware report,” Open Robotics, Tech. Rep., Sep. 2023, accessed: 2026-03-11. [Online]. Available: https://discourse.ros.org/t/ros-2-alternative-middleware-report/33771 [45] A. Corsaro, L. Cominardi, O. Hecart, G. Baldoni, J. E. P. Avital, J. Loudet, C. Guimares, M. Ilyin, and D. Bannov, “Zenoh: Unifying communication, storage and computation from the cloud to the microcontroller,” in Proc. 2023 26th Euromicro Conf. on Digital System Design (DSD). IEEE, 2023, pp. 422–428. [46] ZettaScale Technology, “Zenoh abstractions,” [Online]. Available: https: //zenoh.io/docs/manual/abstractions/, accessed: Mar. 28, 2026. [47] Open Robotics, “rmw_zenoh,” [Online]. Available: https://github.com/ ros2/rmw_zenoh/tree/kilted, gitHub repository, Accessed: Mar. 28, 2026. [48] M. Pöhnl, C. Eltzschig, and T. Blass, “Shared-memory-based lock-free queues: The key to fast and robust communication on safety-critical edge devices,” in Proc. Cyber-Physical Systems and Internet of Things Week 2023, 2023, pp. 179–184. [49] B. Stadnik and A. Wymysłowski, “Overview analysis of Micro-ROS system as an embedded solution for microcontrollers in automatics and robotics applications,” Przeglad ˛ Elektrotechniczny, vol. 100, 2024. [50] N. Parmar, V. Ranga, and B. Simhachalam Naidu, “Syntactic interoperability in real-time systems, ROS 2, and adaptive AUTOSAR using Data Distribution Services: An approach,” in Inventive Communication and Computational Technologies: Proc. ICICCT 2019. Springer, 2020, pp. 257–274. [51] D. Casini, J.-J. Chen, J. Li, F. Reghenzani, and H. Teper, “A survey of real-time support, analysis, and advancements in ROS 2,” Leibniz Trans. on Embedded Systems (LITES), vol. 11, no. 1, pp. 1:1–1:37, 2026. [52] B. Peng, A. Hasegawa, and T. Azumi, “Scheduling performance evaluation framework for ROS 2 applications,” in Proc. 2022 IEEE 24th Int. Conf. on High Performance Computing & Communications (HPCC/DSS/SmartCity/DependSys). IEEE, 2022, pp. 2031–2038. [53] J. Kouril, B. Schäufele, I. Radusch, and B. Schnor, “Performance evaluation of a ROS 2 based automated driving system,” in Proc. 10th Int. Conf. on Vehicle Technology and Intelligent Transport Systems (VEHITS). SciTePress, 2024, pp. 52–63.

[54] Open Robotics, “Topics vs services vs actions,” [Online]. Available: https://docs.ros.org/en/kilted/How-To-Guides/Topics-Services-Actions. html, accessed: Mar. 28, 2026. [55] ——, “Understanding topics,” [Online]. Available: https://docs.ros.org/ en/kilted/Tutorials/Beginner-CLI-Tools/Understanding-ROS2-Topics/ Understanding-ROS2-Topics.html, accessed: Mar. 28, 2026. [56] ——, “Understanding services,” [Online]. Available: https://docs.ros.org/en/kilted/Tutorials/Beginner-CLI-Tools/ Understanding-ROS2-Services/Understanding-ROS2-Services.html, accessed: Mar. 28, 2026. “Understanding actions,” [Online]. Available: [57] ——, https://docs.ros.org/en/kilted/Tutorials/Beginner-CLI-Tools/ Understanding-ROS2-Actions/Understanding-ROS2-Actions.html, accessed: Mar. 28, 2026. [58] ——, “Interfaces,” [Online]. Available: https://docs.ros.org/en/kilted/ Concepts/Basic/About-Interfaces.html, accessed: Mar. 28, 2026. [59] K. Krinkin, A. Filatov, A. Filatov, O. Kurishev, and A. Lyanguzov, “Data Distribution Services performance evaluation framework,” in Proc. 2018 22nd Conf. of Open Innovations Association (FRUCT). IEEE, 2018, pp. 94–100. [60] F. J. Blanco Romero, “Enhancing communication security in ROS 2,” Master’s thesis, Universidad Miguel Hernández de Elche, 2024. [61] Z. Jiang, Y. Gong, J. Zhai, Y.-P. Wang, W. Liu, H. Wu, and J. Jin, “Message passing optimization in Robot Operating System,” Int. J. of Parallel Programming, vol. 48, no. 1, pp. 119–136, 2020. [62] eProsima, “ROS 2 discovery server — Fast DDS documentation,” [Online]. Available: https://fast-dds.docs.eprosima.com/en/latest/fastdds/ ros2/discovery_server/ros2_discovery_server.html, 2024, accessed: 202604-03. [63] Real-Time Innovations (RTI), “RTI routing service — RTI Connext DDS Professional 7.3.0 documentation,” [Online]. Available: https://community.rti.com/static/documentation/connext-dds/7.3.0/ doc/manuals/connext_dds_professional/services/routing_service/index. html, 2024, accessed: 2026-04-03. [64] H. A. Putra and D.-S. Kim, “Node discovery scheme of DDS for combat management system,” Computer Standards & Interfaces, vol. 37, pp. 20–28, 2015. [65] Object Management Group, The real-time publish-subscribe protocol DDS interoperability wire protocol (DDSI-RTPS) specification, version 2.5, Object Management Group, Apr. 2022, OMG Document Number: formal/2022-04-01. [Online]. Available: https://www.omg.org/spec/ DDSI-RTPS/2.5 [66] F. Maggi, R. Vosseler, M. Cheng, P. Kuo, C. Toyama, T. Yen, and E. B. V. Vilches, “A security analysis of the Data Distribution Service (DDS) protocol,” Trend Micro Research, pp. 15–20, 2022. [67] A. Zanni, “Efficient support for deep sleeping modes in embedded systems: The case of Zenoh-pico,” Master’s thesis, University of Bologna, 2024. [68] G. Caruso, “Autonomous navigation for quadruped robots: Development and optimization on the Unitree Go1 platform,” Ph.D. dissertation, Politecnico di Torino, 2024. [69] M. J. Michaud, T. Dean, and S. P. Leblanc, “Attacking OMG Data Distribution Service (DDS) based real-time mission critical distributed systems,” in Proc. 2018 13th Int. Conf. on Malicious and Unwanted Software (MALWARE). IEEE, 2018, pp. 68–77. [70] M. Baron, L. Diez, M. Zverev, J. R. Juarez, and R. Agüero, “On the performance of Zenoh in industrial IoT scenarios,” Ad Hoc Networks, vol. 170, p. 103784, 2025. [71] H. P. Tijero and J. J. Gutiérrez, “On the schedulability of a data-centric real-time distribution middleware,” Computer Standards & Interfaces, vol. 34, no. 1, pp. 203–211, 2012. [72] C. Scordino, A. G. Mariño, and F. Fons, “Hardware acceleration of Data Distribution Service (DDS) for automotive communication and computing,” IEEE Access, vol. 10, pp. 109 626–109 651, 2022. [73] W.-Y. Liang, Y. Yuan, and H.-J. Lin, “A performance study on the throughput and latency of Zenoh, MQTT, Kafka, and DDS,” arXiv preprint arXiv:2303.09419, 2023. [74] F. Desbiens, “Zenoh: A next-generation protocol for IoT and edge computing,” Presentation at Open Source Summit + Embedded Linux Conf. (OSS + ELC) 2021, Eclipse Foundation, Sep. 2021. [75] A. Hakiri, P. Berthou, A. Gokhale, D. C. Schmidt, and T. Gayraud, “Supporting end-to-end quality of service properties in OMG Data Distribution Service publish/subscribe middleware over wide area networks,” J. of Systems and Software, vol. 86, no. 10, pp. 2574–2593, 2013.

28

[76] A. Corsaro. (2021, Jun.) Zenoh reliability: How it works? [Online]. Available: https://zenoh.io/blog/2021-06-14-zenoh-reliability/. ZettaScale Technology. [77] ZettaScale Technology. (2023, Jun.) Zenoh for ROS 2: Charmander and beyond. [Online]. Available: https://zenoh.io/blog/ 2023-06-05-charmander2/. [78] ——. (2024) Module zenoh::liveliness — Rust documentation. [Online]. Available: https://docs.rs/zenoh/latest/zenoh/liveliness/index.html. Official Rust API Reference. [79] J. Fernandez, B. Allen, P. Thulasiraman, and B. Bingham, “Performance study of the Robot Operating System 2 with QoS and cyber security settings,” in Proc. 2020 IEEE Int. Systems Conf. (SysCon). IEEE, 2020, pp. 1–6. [80] M. Barciś, A. Barciś, and H. Hellwagner, “Information distribution in multi-robot systems: Utility-based evaluation model,” Sensors, vol. 20, no. 3, p. 710, 2020. [81] G. Pardo-Castellote, B. Farabaugh, and R. Warren, “An introduction to DDS and data-centric communications,” Real-Time Innovations, vol. 61, 2005. [82] ZettaScale Technology. (2024) Zenoh plugin storage manager. [Online]. Available: https://zenoh.io/docs/manual/plugin-storage-manager/. Accessed: 2026-03-30. [83] A. Corsaro, “The Data Distribution Service tutorial,” Technical Report 4.0, 2014. [84] ZettaScale Technology. (2024) Module zenoh::session — Rust documentation. [Online]. Available: https://docs.rs/zenoh/latest/zenoh/session/ index.html. Official Rust API Reference. [85] ——. (2024) Zenoh deployment guide. [Online]. Available: https:// zenoh.io/docs/getting-started/deployment/. Accessed: 2026-03-30. [86] Object Management Group, Data Distribution Service (DDS), version 1.4, Object Management Group, Apr. 2015, formal/2015-04-10. [Online]. Available: https://www.omg.org/spec/DDS/1.4 [87] X. Luo, X. Jiang, N. Guan, H. Liang, S. Liu, and W. Yi, “Modeling and analysis of inter-process communication delay in ROS 2,” in Proc. 2023 IEEE Real-Time Systems Symp. (RTSS). IEEE, 2023, pp. 198–209. [88] T. Kronauer, J. Pohlmann, M. Matthé, T. Smejkal, and G. Fettweis, “Latency analysis of ROS 2 multi-node systems,” in Proc. 2021 IEEE Int. Conf. on Multisensor Fusion and Integration for Intelligent Systems (MFI). IEEE, 2021, pp. 1–7. [89] Z. Kang, R. Canady, A. Dubey, A. Gokhale, S. Shekhar, and M. Sedlacek, “A study of publish/subscribe middleware under different IoT traffic conditions,” in Proc. Int. Workshop on Middleware and Applications for the Internet of Things, 2020, pp. 7–12. [90] Y.-P. Wang, Y. Dong, and G. Tan, “ROS-SF: A transparent and efficient ROS middleware using serialization-free message,” in Proc. 23rd ACM/IFIP Int. Middleware Conf., 2022, pp. 82–93. [91] A. Ranjan, A. Damodar, N. Chougule, D. S. Nayak et al., “Meta-ROS: A next-generation middleware architecture for adaptive and scalable robotic systems,” arXiv preprint arXiv:2601.21011, 2026. [92] Y.-P. Wang, W. Tan, X.-Q. Hu, D. Manocha, and S.-M. Hu, “TZC: Efficient inter-process communication for robotics middleware with partial serialization,” in Proc. 2019 IEEE/RSJ Int. Conf. on Intelligent Robots and Systems (IROS). IEEE, 2019, pp. 7805–7812. [93] T. Ishikawa-Aso and S. Kato, “ROS 2 Agnocast: Supporting unsized message types for true zero-copy publish/subscribe IPC,” in Proc. 2025 28th Int. Symp. on Real-Time Distributed Computing (ISORC). IEEE, 2025, pp. 1–10. [94] M. Xiong, J. Parsons, J. Edmondson, H. Nguyen, and D. C. Schmidt, “Evaluating the performance of publish/subscribe platforms for information management in distributed real-time and embedded systems,” omgwiki.org/dds, 2010. [95] C.-T. Lin and H.-J. Lu, “An intelligent product-driven manufacturing system using Data Distribution Service,” IEEE Access, vol. 12, pp. 16 447–16 461, 2024. [96] Z. Chen, “Performance analysis of ROS 2 networks using variable Quality of Service and security constraints for autonomous systems,” Ph.D. dissertation, Naval Postgraduate School, 2019. [97] S. Lee, H.-S. Park, J. Chae, and K.-J. Park, “Probabilistic latency analysis of the Data Distribution Service in ROS 2,” arXiv preprint arXiv:2508.10413, 2025. [98] J. Peeck, M. Möstl, T. Ishigooka, and R. Ernst, “A middleware protocol for time-critical wireless communication of large data samples,” in Proc. 2021 IEEE Real-Time Systems Symp. (RTSS). IEEE, 2021, pp. 1–13. [99] S. Lee, T. Kim, J. Chae, and K.-J. Park, “Poster: How to send large data in ROS 2,” in Proc. 2025 IEEE 33rd Int. Conf. on Network Protocols (ICNP). IEEE, 2025, pp. 1–3.

[100] S. Macenski, A. Soragna, M. Carroll, and Z. Ge, “Impact of ROS 2 node composition in robotic systems,” IEEE Robotics and Automation Letters, vol. 8, no. 7, pp. 3996–4003, 2023. [101] H.-Y. Jung, D.-H. Paek, and S.-H. Kong, “Open-source autonomous driving software platforms: Comparison of Autoware and Apollo,” arXiv preprint arXiv:2501.18942, 2025. [102] S. Lee, T. Kim, J. Chae, and K.-J. Park, “Optimizing ROS 2 communication for wireless robotic systems,” arXiv preprint arXiv:2508.11366, 2025. [103] N. Sperling and R. Ernst, “Low latency communication of large data objects by subscriber-centric selective data transfer,” ACM Trans. on Cyber-Physical Systems, 2026. [104] 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 Proc. 2025 IEEE Int. Conf. on Vehicular Electronics and Safety (ICVES). IEEE, 2025. [105] Y. Maruyama, S. Kato, and T. Azumi, “Exploring the performance of ROS 2,” in Proc. 13th Int. Conf. on Embedded Software, 2016, pp. 1–10. [106] T. Wu, B. Wu, S. Wang, L. Liu, S. Liu, Y. Bao, and W. Shi, “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. [107] K. An, A. Gokhale, D. Schmidt, S. Tambe, P. Pazandak, and G. PardoCastellote, “Content-based filtering discovery protocol (CFDP): Scalable and efficient OMG DDS discovery protocol,” in Proc. 8th ACM Int. Conf. on Distributed Event-Based Systems, 2014, pp. 130–141. [108] Z. Kang, K. An, A. Gokhale, and P. Pazandak, “A comprehensive performance evaluation of different Kubernetes CNI plugins for edgebased and containerized publish/subscribe applications,” in Proc. 2021 IEEE Int. Conf. on Cloud Engineering (IC2E). IEEE, 2021, pp. 31–42. [109] Y. Ye, Z. Nie, X. Liu, F. Xie, Z. Li, and P. Li, “ROS 2 real-time performance optimization and evaluation,” Chinese J. of Mechanical Engineering, vol. 36, no. 1, p. 144, 2023. [110] A.-M. Basem and H. Ali, “Data Distribution Service (DDS) based implementation of smart grid devices using ANSI C12.19 standard,” Procedia Computer Science, vol. 110, pp. 394–401, 2017. [111] B. Almadani, M. N. Bajwa, S.-H. Yang, and A.-W. A. Saif, “Performance evaluation of DDS-based middleware over wireless channel for reconfigurable manufacturing systems,” Int. J. of Distributed Sensor Networks, vol. 11, no. 7, p. 863123, 2015. [112] V. Bode, D. Buettner, T. Preclik, C. Trinitis, and M. Schulz, “Systematic analysis of DDS implementations,” in Proc. 24th Int. Middleware Conf., 2023, pp. 234–246. [113] L. J. Dust, E. Persson, M. Ekström, S. Mubeen, and E. Dean, “Quantitative analysis of communication handling for centralized multiagent robot systems using ROS 2,” in Proc. 2022 IEEE 20th Int. Conf. on Industrial Informatics (INDIN). IEEE, 2022, pp. 624–629. [114] Y. He and W. Shi, “A faster and more reliable middleware for autonomous driving systems,” arXiv preprint arXiv:2510.11448, 2025. [115] L. J. Dust and E. Persson, “Dynamic connection handling for scalable robotic systems using ROS 2,” 2022. [116] M. Pöhnl, A. Tamisier, and T. Blass, “A middleware journey from microcontrollers to microprocessors,” in Proc. 2022 Design, Automation & Test in Europe Conf. & Exhibition (DATE). IEEE, 2022, pp. 282–286. [117] M. De Marchi and N. Bombieri, “Orchestration-aware optimization of ROS 2 communication protocols,” in Proc. 2024 Design, Automation & Test in Europe Conf. & Exhibition (DATE). IEEE, 2024, pp. 1–6. [118] J. Zhang, X. Yu, S. Ha, J. Peña Queralta, and T. Westerlund, “Comparison of middlewares in edge-to-edge and edge-to-cloud communication for distributed ROS 2 systems,” J. of Intelligent & Robotic Systems, vol. 110, no. 4, pp. 1–20, 2024. [119] A. Hakiri, P. Berthou, A. Gokhale, D. C. Schmidt, and T. Gayraud, “Supporting SIP-based end-to-end Data Distribution Service QoS in WANs,” J. of Systems and Software, vol. 95, pp. 100–121, 2014. [120] A. S. Rhoades, G. Schrader, and P. Poulin, “Benchmarking publish/subscribe middleware for radar applications,” in Proc. Eleventh Annual HPEC Workshop, 2007. [121] T. A. Youssef, A. T. Elsayed, and O. A. Mohammed, “DDS-based interoperability framework for smart grid testbed infrastructure,” in Proc. 2015 IEEE 15th Int. Conf. on Environment and Electrical Engineering (EEEIC). IEEE, 2015, pp. 219–224. [122] T. A. Youssef, M. El Hariri, A. T. Elsayed, and O. A. Mohammed, “A DDS-based energy management framework for small microgrid operation and control,” IEEE Trans. on Industrial Informatics, vol. 14, no. 3, pp. 958–968, 2017.

29

[123] K. Peeroo, P. Popov, and V. Stankovic, “A survey on experimental performance evaluation of Data Distribution Service (DDS) implementations,” arXiv preprint arXiv:2310.16630, 2023. [124] ——, “Exploring the effects of multicast communication on DDS performance,” in Proc. Student Forum of the 18th European Dependable Computing Conf. (EDCC), 2022. [125] S. Jones, E. Milner, M. Sooriyabandara, and S. Hauert, “DOTS: An open testbed for industrial swarm robotic solutions,” arXiv preprint arXiv:2203.13809, 2022. [126] K.-h. Lee, C.-k. Kim, K. T. Kim, and W.-t. Kim, “Router design for DDS: Architecture and performance evaluation,” in Proc. 2014 Int. Conf. on Big Data and Smart Computing (BIGCOMP). IEEE, 2014, pp. 250–254. [127] B. Zieba and M. van Sinderen, “Preservation of correctness during system reconfiguration in Data Distribution Service for real-time systems (DDS),” in Proc. 26th IEEE Int. Conf. on Distributed Computing Systems Workshops (ICDCSW). IEEE, 2006, pp. 30–30. [128] H. Teper, T. Betz, G. Von Der Brüggen, K.-H. Chen, J. Betz, and J.-J. Chen, “Timing-aware ROS 2 architecture and system optimization,” in Proc. 2023 IEEE 29th Int. Conf. on Embedded and Real-Time Computing Systems and Applications (RTCSA). IEEE, 2023, pp. 206–215. [129] S. Dehnavi, M. Koedam, A. Nelson, D. Goswami, and K. Goossens, “CompROS: A composable ROS 2 based architecture for real-time embedded robotic development,” in Proc. 2021 IEEE/RSJ Int. Conf. on Intelligent Robots and Systems (IROS). IEEE, 2021, pp. 6449–6455. [130] G. Sciangula, D. Casini, A. Biondi, C. Scordino, M. Di Natale et al., “Bounding the data-delivery latency of DDS messages in real-time applications,” Leibniz Int. Proc. in Informatics, vol. 262, 2023. [131] S. Kim, J. Song, K. Lee, S. Oh, and H. S. Chwa, “CRoS-RT: Cross-layer priority scheduling for predictable inter-process communication in ROS 2,” in Proc. 2025 IEEE 31st Real-Time and Embedded Technology and Applications Symp. (RTAS). IEEE, 2025, pp. 202–214. [132] C.-S. Shih, H.-J. Lin, Y. Yuan, Y.-H. Kuo, and W.-Y. Liang, “Scalable and bounded-time decisions on edge device network using Eclipse Zenoh,” in Proc. 2022 IEEE 28th Int. Conf. on Embedded and RealTime Computing Systems and Applications (RTCSA). IEEE, 2022, pp. 170–179. [133] H. Abaza, D. Roy, B. Trach, W. Chang, S. Saidi, A. Motakis, W. Ren, and Y. Liu, “Managing end-to-end timing jitters in ROS 2 computation chains,” in Proc. 32nd Int. Conf. on Real-Time Networks and Systems, 2024, pp. 229–241. [134] C. Randolph, “Improving the predictability of event chains in ROS 2,” Ph.D. dissertation, Delft Univ. of Technology, 2021. [135] M. G. Valls, I. R. López, and L. F. Villar, “iLAND: An enhanced middleware for real-time reconfiguration of service oriented distributed real-time systems,” IEEE Trans. on Industrial Informatics, vol. 9, no. 1, pp. 228–236, 2012. [136] H. Pérez and J. J. Gutiérrez, “Modeling the QoS parameters of DDS for event-driven real-time applications,” J. of Systems and Software, vol. 104, pp. 126–140, 2015. [137] J.-B. Castillo-Sánchez, E. González-Parada, and J.-M. Cano-García, “Swarm robot communications in ROS 2: An experimental study,” IEEE Access, vol. 12, pp. 142 930–142 943, 2024. [138] S. Lee, J. Kang, and K.-J. Park, “Dependency chain analysis of ROS 2 DDS QoS policies: From lifecycle tutorial to static verification,” arXiv preprint arXiv:2509.03381, 2025. [139] P. Thulasiraman, Z. Chen, B. Allen, and B. Bingham, “Evaluation of the Robot Operating System 2 in lossy unmanned networks,” in Proc. 2020 IEEE Int. Systems Conf. (SysCon). IEEE, 2020, pp. 1–8. [140] T. Kim et al., “Mitigating DDS discovery bursts in ROS 2 multi-robot system,” Ph.D. dissertation, DGIST, 2026. [141] H.-S. Park, S. Lee, D. Um, H. Ryu, and K.-J. Park, “An analytical latency model of the Data Distribution Service in ROS 2,” in Proc. IEEE INFOCOM 2025 – IEEE Conf. on Computer Communications. IEEE, 2025, pp. 1–10. [142] C. Plasberg, H. Nessau, D. Timmermann, C. Eichmann, A. Roennau, and R. Dillmann, “Towards distributed real-time capable robotic control using ROS 2,” in Proc. 2022 IEEE 18th Int. Conf. on Automation Science and Engineering (CASE). IEEE, 2022, pp. 2205–2210. [143] A.-l. Chisălit, ă and A. Korodi, “Stepping towards Zenoh protocol in automotive scenarios,” IEEE Access, 2025. [144] M. F. Ginting, K. Otsu, J. A. Edlund, J. Gao, and A.-A. AghaMohammadi, “CHORD: Distributed data-sharing via hybrid ROS 1 and 2 for multi-robot exploration of large-scale complex environments,” IEEE Robotics and Automation Letters, vol. 6, no. 3, pp. 5064–5071, 2021.

[145] V. DiLuoffo, W. R. Michalson, and B. Sunar, “Robot Operating System 2: The need for a holistic security approach to robotic architectures,” Int. J. of Advanced Robotic Systems, vol. 15, no. 3, pp. 1–11, 2018. [146] B. Al-madani, A. Al-Roubaiey, and T. Al-shehari, “Wireless video streaming over Data Distribution Service middleware,” in Proc. 2012 IEEE Int. Conf. on Computer Science and Automation Engineering. IEEE, 2012, pp. 263–266. [147] P. Thulasiraman, Y. K. D. Cheng, and B. Allen, “Evaluation of the Data Distribution Service for a lossy autonomous hybrid system,” in Proc. 2022 IEEE Int. Systems Conf. (SysCon). IEEE, 2022, pp. 1–8. [148] K. Hu, L. Zou, Z. Chen, J. Jiang, F. Jiang, and X. Tao, “Wireless multi-robot collaboration: Communications, perception, control, and planning,” IEEE Network, vol. 39, no. 4, pp. 302–311, 2024. [149] B. Almadani, M. Alsaeedi, and A. Al-Roubaiey, “QoS-aware scalable video streaming using Data Distribution Service,” Multimedia Tools and Applications, vol. 75, no. 10, pp. 5841–5870, 2016. [150] E. Dey, M. Walczak, M. S. Anwar, N. Roy, J. Freeman, T. Gregory, N. Suri, and C. Busart, “A novel ROS 2 QoS policy-enabled synchronizing middleware for co-simulation of heterogeneous multi-robot systems,” in Proc. 2023 32nd Int. Conf. on Computer Communications and Networks (ICCCN). IEEE, 2023, pp. 1–10. [151] G. Szabó, “Toward the automatic network resource management of Robot Operating System in programmable mobile networks,” IEEE Access, vol. 11, pp. 65 934–65 955, 2023. [152] B. Li, Y. Zhu, Y. Zhao, K. Cui, X. Zhong, and K. Lu, “Fault tolerance DDS communications in Time-Sensitive Networking using IEEE 802.1 CB redundancy mechanisms,” J. of Systems Architecture, p. 103756, 2026. [153] D. Jo and Y. Kwon, “Generation of critical information and sharing mechanism for multi-robot mission success,” IEEE Access, 2025. [154] D. Calisi, F. Fedi, A. Leo, and D. Nardi, “Software development for networked robot systems,” IFAC Proc. Volumes, vol. 43, no. 16, pp. 605–610, 2010. [155] J. Wytr˛ebowicz, K. Cabaj, and J. Krawiec, “Messaging protocols for IoT systems — a pragmatic comparison,” Sensors, vol. 21, no. 20, p. 6904, 2021. [156] S. Asjad, E. Harber, V. Santos, and D. Tyler, “NeuroReality: A Data Distribution Service-based inter-process communication middleware,” in Proc. 2024 IEEE Conf. on Telepresence. IEEE, 2024, pp. 168–171. [157] G. Toffetti, L. Militano, R. Tharaka, and M. Straub, “ROS-based robotic applications orchestration in the compute continuum: Challenges and approaches,” in Proc. IEEE/ACM 16th Int. Conf. on Utility and Cloud Computing, 2023, pp. 1–6. [158] H. Teper, M. Günzel, N. Ueter, G. von der Brüggen, and J.-J. Chen, “End-to-end timing analysis in ROS 2,” in Proc. 2022 IEEE Real-Time Systems Symp. (RTSS). IEEE, 2022, pp. 53–65. [159] A. Jalil and J. Kobayashi, “Efficacy of local cache for performance improvement of reliable data transmission in aggregated robot processing architecture,” in Proc. 2022 22nd Int. Conf. on Control, Automation and Systems (ICCAS). IEEE, 2022, pp. 1339–1344. [160] A. Jalil, J. Kobayashi, and T. Saitoh, “Performance improvement of multi-robot data transmission in aggregated robot processing architecture with caches and QoS balancing optimization,” Robotics, vol. 12, no. 3, p. 87, 2023. [161] R. Li, Z. Song, M. Lv, J.-M. Wu, C. J. Xue, J. Wang, and N. Guan, “ATER: Adaptive task execution rate regulation for enhanced real-time performance in ROS 2,” in Proc. 2025 IEEE 31st Int. Conf. on Embedded and Real-Time Computing Systems and Applications (RTCSA). IEEE, 2025, pp. 90–101. [162] A. Romero-Garcés, J. F. Inglés-Romero, J. Martínez, and C. VicenteChicote, “Self-adaptive quality-of-service in distributed middleware for robotics,” in Proc. Workshop on Recognition and Action for Scene Understanding (REACTS), 2013. [163] J. Sanchez-Monedero, J. Povedano-Molina, J. M. Lopez-Vega, and J. M. Lopez-Soler, “Bloom filter-based discovery protocol for DDS middleware,” J. of Parallel and Distributed Computing, vol. 71, no. 10, pp. 1305–1317, 2011. [164] H. Lee, D. Kim, and S. Moon, “Optimizing Data Distribution Service discovery for swarm unmanned aerial vehicles through preloading and network awareness,” Drones, vol. 9, no. 8, pp. 1–20, 2025. [165] W.-P. Nwadiugwu, D.-S. Kim, W. Ejaz, and A. Anpalagan, “MADDDS: Memory-efficient automatic discovery data distribution service for large-scale distributed control network,” IET Communications, vol. 17, no. 12, pp. 1432–1446, 2023. [166] S. Sang and Y. Ling, “Service discovery-based hybrid network middleware for efficient communication in distributed robotic systems,”

30

in Proc. 2025 IEEE/RSJ Int. Conf. on Intelligent Robots and Systems (IROS). IEEE, 2025, pp. 1357–1364. [167] L. P. Chovet, G. M. Garcia, A. Bera, A. Richard, K. Yoshida, and M. A. Olivares-Mendez, “Performance comparison of ROS 2 middlewares for multi-robot mesh networks in planetary exploration,” J. of Intelligent & Robotic Systems, vol. 111, no. 1, p. 18, 2025. [168] Ö. Köksal and B. Tekinerdogan, “Obstacles in Data Distribution Service middleware: A systematic review,” Future Generation Computer Systems, vol. 68, pp. 191–210, 2017. [169] F. Desbiens, Building enterprise IoT solutions with Eclipse IoT technologies: An open source approach to edge computing. Springer, 2023. [170] D. Portugal, R. P. Rocha, and J. P. Castilho, “Inquiring the Robot Operating System community on the state of adoption of the ROS 2 robotics middleware,” Int. J. of Intelligent Robotics and Applications, vol. 9, no. 2, pp. 454–479, 2025. [171] Real-Time Innovations, “Data-centric middleware: Modular software infrastructure to monitor, control and collect real-time equipment analytics,” Whitepaper. [Online]. Available: https://www.rti.com/hubfs/ docs/RTI_Data_Centric_Middleware.pdf, 2014, accessed: 2026-04-02. [172] K. Chen, N. Tian, C. Juette, T. Qiu, L. Ren, J. Kubiatowicz, and K. Goldberg, “FogROS2-PLR: Probabilistic latency-reliability for cloud robotics,” in Proc. 2025 IEEE Int. Conf. on Robotics and Automation (ICRA). IEEE, 2025, pp. 16 290–16 297. [173] B. Jaiswal, H. Tyagi, A. Gopalan, and V. Sevani, “WiROS: A QoS software solution for ROS 2 in a WiFi network,” in Proc. 2023 15th Int. Conf. on COMmunication Systems & NETworkS (COMSNETS). IEEE, 2023, pp. 216–218. [174] S. Parra, S. Schneider, and N. Hochgeschwender, “Specifying QoS requirements and capabilities for component-based robot software,” in Proc. 2021 IEEE/ACM 3rd Int. Workshop on Robotics Software Engineering (RoSE). IEEE, 2021, pp. 29–36. [175] J. Hoffert, D. Schmidt, and A. Gokhale, “A QoS policy configuration modeling language for publish/subscribe middleware platforms,” in Proc. 2007 Inaugural Int. Conf. on Distributed Event-Based Systems, 2007, pp. 140–145. [176] K. An, T. Kuroda, A. Gokhale, S. Tambe, and A. Sorbini, “Model-driven generative framework for automated OMG DDS performance testing in the cloud,” ACM SIGPLAN Notices, vol. 49, no. 3, pp. 179–182, 2013. [177] A. Jalil, J. Kobayashi, and T. Saitoh, “QoS balancing optimization in aggregated robot processing architecture: Rate and buffer,” J. of Advances in Artificial Life Robotics, vol. 3, no. 4, pp. 209–213, 2023. [178] A. Fasano, “Optimizing inter-process communication for robotics applications,” Ph.D. dissertation, Politecnico di Torino, 2025. [179] C. S. V. Gutiérrez, L. U. S. Juan, I. Z. Ugarte, and V. M. Vilches, “Towards a distributed and real-time framework for robots: Evaluation of ROS 2.0 communications for real-time robotic applications,” arXiv preprint arXiv:1809.02595, 2018. [180] J. Park, R. Delgado, and B. W. Choi, “Real-time characteristics of ROS 2.0 in multiagent robot systems: An empirical study,” IEEE Access, vol. 8, pp. 154 637–154 651, 2020. [181] D. P. Klüner, M. Molz, A. Kampmann, S. Kowalewski, and B. Alrifaee, “Modern middlewares for automated vehicles: A tutorial,” IEEE Intelligent Transportation Systems Magazine, 2026. [182] M. Richart, F. Velázquez, F. Ciuffardi, J. Visca, and J. Baliosian, “CoCoSim: A tool for co-simulation of mobile cooperative robots,” in Proc. Int. Conf. on Software Engineering and Formal Methods. Springer, 2022, pp. 258–268. [183] S. Acharya, A. Bharadwaj, Y. Simmhan, A. Gopalan, P. Parag, and H. Tyagi, “CorNet: A co-simulation middleware for robot networks,” in Proc. 2020 Int. Conf. on COMmunication Systems & NETworkS (COMSNETS). IEEE, 2020, pp. 245–251. [184] S. Moon, J. J. Bird, S. Borenstein, and E. W. Frew, “A Gazebo/ROSbased communication-realistic simulator for networked SUAS,” in Proc. 2020 Int. Conf. on Unmanned Aircraft Systems (ICUAS). IEEE, 2020, pp. 1819–1827. [185] J. Shi, A. Ma, X. Cheng, M. Sha, and P. Xi, “Adapting wireless network configuration from simulation to reality via deep learning-based domain adaptation,” IEEE/ACM Trans. on Networking, vol. 32, no. 3, pp. 1983– 1998, 2023. [186] S. Agarwal, A. Asija, S. K. Kaul, and S. Anand, “Sim-to-real transfer for estimation over wireless networks,” ACM Trans. on Cyber-Physical Systems, vol. 9, no. 4, pp. 1–25, 2025. [187] M. Calvo-Fullana, D. Mox, A. Pyattaev, J. Fink, V. Kumar, and A. Ribeiro, “ROS-NetSim: A framework for the integration of robotic and network simulators,” IEEE Robotics and Automation Letters, vol. 6, no. 2, pp. 1120–1127, 2021.

[188] J. Kim, J. M. Smereka, C. Cheung, S. Nepal, and M. Grobler, “Security and performance considerations in ROS 2: A balancing act,” arXiv preprint arXiv:1809.09566, 2018. [189] S. Sandoval and P. Thulasiraman, “Cyber security assessment of the Robot Operating System 2 for aerial networks,” in Proc. 2019 IEEE Int. Systems Conf. (SysCon). IEEE, 2019, pp. 1–8. [190] M. Aartsen, K. Banga, K. Talko, D. Touw, B. Wisman, D. Meïnsma, and M. Björkqvist, “Analyzing interoperability and security overhead of ROS 2 DDS middleware,” in Proc. 2022 30th Mediterranean Conf. on Control and Automation (MED). IEEE, 2022, pp. 976–981. [191] S. Takemoto, K. Nishida, Y. Nozaki, M. Yoshikawa, S. Honda, and R. Kurachi, “Performance evaluation of CAESAR authenticated encryption on SROS 2,” in Proc. 2019 2nd Artificial Intelligence and Cloud Computing Conf., 2019, pp. 168–172. [192] L. Xia, X. Gao, and W. Shi, “Investigating security threats in multitenant ROS 2 systems,” in Proc. 2025 IEEE Int. Conf. on Robotics and Automation (ICRA). IEEE, 2025, pp. 16 441–16 448. [193] B. Wang, H. Li, and J. Guan, “A formal analysis of Data Distribution Service security,” in Proc. 19th ACM Asia Conf. on Computer and Communications Security, 2024, pp. 716–727. [194] J. Du, C. Gao, and T. Feng, “Formal safety assessment and improvement of DDS protocol for industrial Data Distribution Service,” Future Internet, vol. 15, no. 1, p. 24, 2022. [195] G. Deng, G. Xu, Y. Zhou, T. Zhang, and Y. Liu, “On the (in)security of secure ROS 2,” in Proc. 2022 ACM SIGSAC Conf. on Computer and Communications Security, 2022, pp. 739–753. [196] Y. Patel, P. H. Rughani, and D. Desai, “Analyzing security vulnerability and forensic investigation of ROS 2: A case study,” in Proc. 8th Int. Conf. on Robotics and Artificial Intelligence, 2022, pp. 6–12. [197] L. David, R. Vasconcelos, L. Alves, R. André, and M. Endler, “A DDS-based middleware for scalable tracking, communication and collaboration of mobile nodes,” J. of Internet Services and Applications, vol. 4, no. 1, p. 16, 2013. [198] R. White, H. I. Christensen, G. Caiazza, and A. Cortesi, “Procedurally provisioned access control for robotic systems,” in Proc. 2018 IEEE/RSJ Int. Conf. on Intelligent Robots and Systems (IROS). IEEE, 2018, pp. 1–9. [199] Q. Wang, B. Lee, and Y. Qiao, “Support remote attestation for decentralized Robot Operating System (ROS) using trusted execution environment,” in Proc. 2024 IEEE Int. Conf. on Blockchain and Cryptocurrency (ICBC). IEEE, 2024, pp. 693–695. [200] P. G. Wagner, P. Birnstill, and J. Beyerer, “DDS Security+: Enhancing the Data Distribution Service with TPM-based remote attestation,” in Proc. 19th Int. Conf. on Availability, Reliability and Security, 2024, pp. 1–11. [201] G. Sciangula, D. Casini, A. Biondi, C. Scordino, and M. Di Natale, “End-to-end response-time analysis of DDS-based real-time applications,” Internet of Things, p. 101853, 2025. [202] J. Yu, S. Lee, Y. Choi, and K.-J. Park, “ros2probe: Non-intrusive, kernelselective observability for Robot Operating System 2 middleware,” arXiv preprint arXiv:2606.10746, 2026. [203] A. Hakiri, P. Berthou, S. Slim Abdellatif, M. Diaz, and T. Gayraud, “Supporting end-to-end internet QoS for DDS-based large-scale distributed simulation,” in Proc. 1st ACM SIGSIM Conf. on Principles of Advanced Discrete Simulation, 2013, pp. 397–402. [204] B. Almadani, S. Abudalfa et al., “QoS adaptation for publish/subscribe middleware in real-time dynamic environments,” Int. Arab J. of Information Technology (IAJIT), vol. 14, no. 2, 2017. [205] R. Zhao, G. Yang, J. Fleming, and B. Chen, “Distributed state estimation for discrete-time LTI systems: The design trilemma and a novel framework,” arXiv preprint arXiv:2603.20144, 2026. [206] M. Bosk and J. Ott, “Towards domain-specific time-sensitive information-centric networking architecture,” in Proc. 2024 IFIP Networking Conf. (IFIP Networking). IEEE, 2024, pp. 720–725. [207] J. Hoffert, D. Schmidt, and A. Gokhale, “DQML: A modeling language for configuring distributed publish/subscribe Quality of Service policies,” in Proc. OTM Confederated Int. Conf. on the Move to Meaningful Internet Systems. Springer, 2008, pp. 515–534. [208] J. Hoffert, A. Gokhale, and D. C. Schmidt, “Timely autonomic adaptation of publish/subscribe middleware in dynamic environments,” Int. J. of Adaptive, Resilient and Autonomic Systems (IJARAS), vol. 2, no. 4, pp. 1–24, 2011. [209] P. Garcia Lopez, R. Gracia, M. Espelt, G. Paris, M. Arrufat, and R. Messeguer, “Topology-aware group communication middleware for MANETs,” in Proc. 4th Int. ICST Conf. on COMmunication System softWAre and middlewaRE, 2009, pp. 1–10.

31

[210] G. Szabó, “Enhancing vertical application and network co-design: A solution for multipath channel switching in ROS 2 with 3GPP integration,” IEEE Access, 2025. [211] G. Orsini, D. Bade, and W. Lamersdorf, “CloudAware: A contextadaptive middleware for mobile edge and cloud computing applications,” in Proc. 2016 IEEE 1st Int. Workshops on Foundations and Applications of Self* Systems (FAS*W). IEEE, 2016, pp. 216–221. [212] P. Bellavista, A. Corradi, and C. Giannelli, “Context-aware middleware for reliable multi-hop multi-path connectivity,” in Proc. IFIP Int. Workshop on Software Technologies for Embedded and Ubiquitous Systems. Springer, 2008, pp. 66–78. [213] J. Balasubramanian, S. Tambe, C. Lu, A. Gokhale, C. Gill, and D. C. Schmidt, “Adaptive failover for real-time middleware with passive replication,” in Proc. 2009 15th IEEE Real-Time and Embedded Technology and Applications Symp. IEEE, 2009, pp. 118–127. [214] J. Balasubramanian, A. Gokhale, D. C. Schmidt, and N. Wang, “Towards middleware for fault-tolerance in distributed real-time and embedded systems,” in Proc. IFIP Int. Conf. on Distributed Applications and Interoperable Systems. Springer, 2008, pp. 72–85. [215] E. Pitoura and B. Bhargava, “Data consistency in intermittently connected distributed systems,” IEEE Trans. on Knowledge and Data Engineering, vol. 11, no. 6, pp. 896–915, 2002. [216] S. Paul, D. Lephuoc, and M. Hauswirth, “Performance evaluation of ROS 2–DDS middleware implementations facilitating cooperative driving in autonomous vehicle,” arXiv preprint arXiv:2412.07485, 2024. [217] D. Yoshino, Y. Watanobe, and K. Naruse, “High communication performance Internet of Robotic Things systems based on RT-Middleware,” IEEE Access, vol. 13, pp. 207 527–207 540, 2025. [218] R. Kurte, Z. Salcic, and K. I.-K. Wang, “Decentralised global service discovery for the Internet of Things,” Sensors, vol. 24, no. 7, p. 2196, 2024. [219] S. Ebadi and L. M. Khanli, “A new distributed and hierarchical mechanism for service discovery in a grid environment,” Future Generation Computer Systems, vol. 27, no. 6, pp. 836–842, 2011. [220] P. Detzner, J. Gödeke, L. Tönning, P. Laskowski, M. Hörstrup, O. Stolz, M. Brehler, and S. Kerner, “SOLA: A decentralized communication middleware developed with ns-3,” in Proc. 2023 Workshop on ns-3, 2023, pp. 78–85. [221] J. Jung, S. Lee, N. Kim, and H. Yoon, “Efficient service discovery mechanism for wireless sensor networks,” Computer Communications, vol. 31, no. 14, pp. 3292–3298, 2008. [222] R. Harbird, S. Hailes, and C. Mascolo, “Adaptive resource discovery for ubiquitous computing,” in Proc. 2nd Workshop on Middleware for Pervasive and Ad-Hoc Computing, 2004, pp. 155–160. [223] R. Mokadem, A. Hameurlain, and A. M. Tjoa, “Resource discovery service while minimizing maintenance overhead in hierarchical DHT systems,” in Proc. 12th Int. Conf. on Information Integration and Webbased Applications & Services, 2010, pp. 630–638. [224] W. Tang, L. Wang, and G. Xue, “Design of high availability service discovery for microservices architecture,” in Proc. 2019 3rd Int. Conf. on Management Engineering, Software Engineering and Service Sciences, 2019, pp. 253–257. [225] P. Gomes, E. Cavalcante, T. Rodrigues, T. Batista, F. C. Delicato, and P. F. Pires, “A federated discovery service for the Internet of Things,” in Proc. 2nd Workshop on Middleware for Context-Aware Applications in the IoT, 2015, pp. 25–30. [226] S. Kim, H. Choi, S. Lee, M. Kim, H. Shin, and C. Moon, “A dynamic bridge architecture for efficient interoperability between AUTOSAR adaptive and ROS 2,” Electronics, vol. 14, no. 18, p. 3635, 2025. [227] Open Robotics, “ROS 2 domain bridge design and implementation,” [Online]. Available: https://docs.ros.org/en/kilted/p/domain_bridge/doc/ design.html, 2024, accessed: Apr. 6, 2026. [228] B.-Y. Song and H. Choi, “ROS gateway: Enhancing ROS availability across multiple network environments,” Sensors, vol. 24, no. 19, p. 6297, 2024. [229] W. Sim, B. Song, J. Shin, and T. Kim, “Data Distribution Service converter based on the OPC UA publish–subscribe protocol,” Electronics, vol. 10, no. 20, p. 2524, 2021. [230] M. Boari, E. Lodolo, S. Monti, and S. Pasini, “Middleware for automatic dynamic reconfiguration of context-driven services,” Microprocessors and Microsystems, vol. 32, no. 3, pp. 145–158, 2008. [231] M. Aragão, P. Moreno, and A. Bernardino, “Middleware interoperability for robotics: A ROS–YARP framework,” Frontiers in Robotics and AI, vol. 3, p. 64, 2016. [232] Eclipse Zenoh, “Zenoh bridge for DDS,” [Online]. Available: https: //docs.ros.org/en/kilted/p/zenoh_bridge_dds/, 2024, accessed: Apr. 6, 2026.

[233] B. Song, X. Hu, J. Xiao, G. Zhang, S. Wang, and Q. Zhou, “Integration of Data Distribution Service into partitioned real-time embedded systems,” in Proc. 2020 15th IEEE Conf. on Industrial Electronics and Applications (ICIEA). IEEE, 2020, pp. 1606–1611. [234] Zenoh longwang release. Zenoh. [Online]. Available: https://zenoh.io/ blog/2026-04-16-zenoh-longwang/