DDS™ - The Proven Data Connectivity Standard for IoT™ Nov. 2016 | Page 12
DIFFERENT PROTOCOLS
WHY CHOOSE DDS?
Several specialized messaging/data-sharing protocols are often considered for IoT applications, including:
• Message Queue Telemetry Transport (MQTT), a broker-reliant publish/subscribe messaging protocol
designed to be used with TCP/IP
• Advanced Message Queuing Protocol (AMQP), which defines an efficient, binary, peer-to-peer protocol for transporting messages between two network processes (usually a client and a broker)
• Constrained Application Protocol (CoAP) is a software protocol that was designed to support the
connectivity of simple low power electronic devices (e.g. wireless sensors) with Internet-based systems
The following table provides a comparison of the technologies listed above. A number of these IoT protocols were designed for simplicity and as such can support only a very limited set of use cases. DDS on the
other hand, is a feature-rich standard that transparently handles much of an IoT system’s data connectivity
complexity, therefore, easing developer efforts.
Content
Awareness
Data
Centricity
Security
Data
Prioritization
Fault
Tolerance
No
None
Encoding
TLS
None
Impl. Specific
Yes
None
Encoding
DTLS
None
Decentralized
D2D
D2C
C2C
Yes
ContentBased
Routing,
Queries
Encoding
Declaration
TLS, DTLS,
DDS
Security
Transport
Priorities
Decentralized
D2C
No
None
Undefined
TLS
None
Broker is the
SPoF
Transport
Paradigm
AMQP
TCP/IP
Point-to-Point
Message
Exchange
D2D
D2C
C2C
CoAP
UDP/IP
Request/
Reply
(REST)
D2D
Publish/
Subscribe
Request/
Reply
Publish/
Subscribe
UDP/IP
DDS
(unicast + mcast)
MQTT
TCP/IP
TCP/IP
Scope Discovery
TCP: Transmission Control Protocol IP: Internet Protocol D2D: Device-to-Device D2C: Device-to-Cloud C2C: Cloud-to-Cloud
TLS: Transport Layer Security DTLS: Datagram Transport Layer Security
Qualitative Comparison of IoT Standards
DDS: THE RIGHT CHOICE
Many real systems include devices, servers, mobile nodes, and more. They have diverse communication
needs, but it’s better—and easier—to use a single communication paradigm when possible. System designers should determine which of the protocols meets the primary challenge of their intended applications.
Then, if possible, extend that primary choice to all aspects of the system.
For example, inter-device data use is a different use case from device data collection. Requirements for
turning on your light switch (best with CoAP) are much different than the requirements for managing the
generation of that power (best with DDS), monitoring the transmission lines (best with MQTT), or communicating power usage within the data center (best with AMQP).
DDS is the most versatile of these protocols. It can manage tiny devices, connect large, high-performance
sensor networks and close time-critical control loops. It can also send and receive data from the cloud.
DDS communication is peer-to-peer. Elimination of message brokers and servers simplifies deployment,
minimizes latency, maximizes scalability, increases reliability, and reduces cost and complexity. Using DDS
does require building a data model and understanding data-centric principles. It is ideal for IoT applications
that require a lasting, reliable, high-performance architecture.
12