DIFFERENT PROTOCOLS Several specialized messaging / data-sharing protocols are often considered for IoT applications , including :
WHY CHOOSE DDS ?
• 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 .
|
Transport Paradigm Scope Discovery
Content Awareness
|
Data Centricity |
Security |
Data Prioritization |
Fault Tolerance |
AMQP |
TCP / IP |
Point-to-Point Message Exchange |
D2D D2C C2C |
No |
None |
Encoding |
TLS |
None |
Impl . Specific |
CoAP |
UDP / IP |
Request / Reply ( REST ) |
D2D |
Yes |
None |
Encoding |
DTLS |
None |
Decentralized |
DDS |
UDP / IP ( unicast + mcast ) TCP / IP |
Publish / Subscribe Request / Reply |
D2D D2C C2C |
Yes |
Content- Based Routing , Queries |
Encoding Declaration |
TLS , DTLS , DDS Security |
Transport Priorities |
Decentralized |
MQTT |
TCP / IP |
Publish / Subscribe |
D2C |
No |
None |
Undefined |
TLS |
None |
Broker is the SPoF |
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
DDS : THE RIGHT CHOICE
Qualitative Comparison of IoT Standards
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