DDS Protocol Architecture Basics

This page covers the fundamentals of DDS (Data Distribution Service) protocol architecture, focusing on its brokerless approach within the context of the Internet of Things (IoT).

DDS stands for Data Distribution Service.

• It’s an IoT protocol specifically designed for Machine-to-Machine (M2M) communication, developed by the Object Management Group (OMG).
• It facilitates data exchange through a publish-subscribe model.
• Unlike MQTT and CoAP protocols, DDS employs a brokerless architecture.
• It leverages multicasting to ensure high Quality of Service (QoS) for applications.
• The DDS protocol is versatile, suitable for deployment on devices ranging from low-footprint embedded systems to cloud environments.

Figure-1: DDS Protocol Stack

DDS V1.2 API standard is language, operating system, and hardware architecture independent.

Figure 1 illustrates the DDS protocol stack. It consists of two primary layers:

• DCPS (Data Centric Publish Subscribe) layer: This layer handles the delivery of information to subscribers. The DCPS is a standard API for data-centric, topic-based, real-time publish/subscribe operations.
• DLRL (Data Local Reconstruction Layer): The DLRL provides an interface to DCPS functionalities. It allows for the sharing of distributed data among IoT-enabled devices. The DLRL is a standard API for creating object views from a collection of topics.

DDSI/RTPS V2.1 is a standard wire protocol, ensuring interoperability between different implementations of the DDS standard.

Figure-2: DDS Protocol Architecture

Figure 2 illustrates the DDS protocol architecture. DDS operates as a fully distributed Global Data Space (GDS).

GDS specifications make it fully distributed in order to avoid introduction of single point of failure or bottleneck.

• Within the DDS protocol architecture, applications can autonomously and asynchronously read/write data within the GDS.
• Publishers and subscribers can dynamically join or leave the GDS at any time, thanks to a dynamic discovery mechanism.
• Publishers and subscribers declare their intent to produce or consume specific data types, referred to as “topics”.
• Subscriptions are matched based on these topics, along with details such as name, data type, and QoS requirements.
• These subscriptions are dynamically matched. Data then flows directly from publishers to subscribers.