Multiple protocols have been positioned as “the” application-layer messaging protocol for the Internet of Things (IoT) and Machine-to-Machine (M2M) communication. In fact, these protocols address different aspects of IoT messaging and are complementary more than competitive (other than for mindshare). This presentation compares two of these protocols, MQTT and DDS, and shows how they are designed and optimized for different communication requirements.

1. MQTT and DDS Comparison
Disentangling M2M Messaging Protocols for the IoT
David Barnett
@rtidavid
May 2013
© 2013 Real-Time Innovations (RTI)

2. MQTT & DDS: Cause for Confusion
• Support Machine-to-Machine (M2M)
– Internet of Things (IoT)
– Real-time monitoring and control*
– Analytics for predictive maintenance,
resource optimization, asset tracking
• Provide interoperability*
• Publish/subscribe
• Address some common technical requirements
– Memory, CPU and network constraints
– Support for mobile, embedded and real-time OS
© 2013 Real-Time Innovations (RTI)
*But different meanings of “real time” and “interoperability”
May 2013 2

3. Target Different Messaging Uses
MQTT
• Telemetry: device to server, data
center, back office, IT cloud
• Centralized & server-based
analytics, business logic and
integration
DDS
• Intelligent Systems: within and
between devices, dedicated
systems, real-time cloud
• Analytics, biz logic & integration
distributed, embedded, at edge
© 2013 Real-Time Innovations (RTI)
Device
App App App
Device Device
Broker / ESB
Device
App
Device or Dedicated System
App App App App
May 2013 3

4. Typical MQTT Deployment & Apps
• At-home patient monitoring
• Energy usage monitoring
• Supply chain, cargo and inventory
tracking (e.g. using RFID)
• Remote resource monitoring
(e.g. wells, pipelines, environment)
• Point of sale and in-casino gambling
devices
• Mobile device to server messaging
(e.g. Facebook Messenger)
• Automotive telematics
© 2013 Real-Time Innovations (RTI)
Device
App App App
Device Device
Broker / ESB
MQTT over WAN
Sources: IBM Redbook “Building Smarter Planet Solutions with MQTT and IBM WebSphere MQ Telemetry,” mqtt.org
Enterprise messaging over LAN
May 2013 4

5. Typical DDS Deployment & Apps
• In-hospital patient monitoring
• Medical imaging and surgical devices
• Manufacturing (industrial
control, testing)
• Monitoring and control of power
generation and grid
• Control of robotics and unmanned
vehicles
• Automotive driver safety and
infotainment
• Telecom equipment management
• Aerospace and defense control
systems
• High-Performance Computing (HPC)
• Latency-sensitive IT
(trading, real-time sports betting)
© 2013 Real-Time Innovations (RTI)
Source: www.rti.com/company/customers.html
Device
App
Device or Dedicated System
App App App App
DDS: shmem, bus, LAN
DDS over LAN
DDS over WAN
May 2013 5
Device
App
Device or Dedicated System
App App App App

6. Apps Have Different Requirements
Telemetry (MQTT) Intelligent Systems (DDS)
Network Usually WAN, sometimes LAN Combo of shared memory, bus, LAN, WAN
Administration • Some configuration acceptable
• IT involved
• Often autonomous
• Admin should be minimized; may not be
available
Message rate A few messages/second per device Up to 10,000s messages/second per device
Latency • 100s ms to seconds
• Can queue messages under load
• 100s μs to milliseconds
• Often most critical when load increases
“Real-time” • As responsive as possible
• Timing not stringent
• Physical processes (deterministic)
• Must keep up with data
Fault tolerance Brief service interruptions tolerable Service interruptions potentially calamitous
“Interoperability” • Protocol level
• Between independent client
and broker implementations
• Can have centralized integration
logic (e.g., ESB)
• Application and protocol level
• Between independently developed apps
(explicit data model / interfaces)
• Can’t depend on centralized integration
logic
© 2013 Real-Time Innovations (RTI)May 2013 6

7. Fundamental Difference: Architecture
MQTT
• Centralized
– All comms route through broker
– Typically TCP
– Broker queues messages
– Some service interruption when
broker fails over
• Administered
– Broker itself
– Clients configured with
broker/server address
DDS
• Decentralized
– Peer-to-peer communication
– Typically UDP; multicast for one-to-many
– Fully embeddable: no external s/w
– Keeps latency and jitter low:
no intermediary, bottleneck
– No single point of failure or service
interruptions
• No admin/config required at deployment
– Automatic discovery  plug-and-play
– Self-forming and self-healing
© 2013 Real-Time Innovations (RTI)
Device
App App App
Device Device
Broker / ESB
Device
App
Device or Dedicated System
App App App App
May 2013 7

8. Quality of Service (QoS) Addresses
Different Requirements
• MQTT: focused on message delivery
– At most once, at least once, exactly once
• DDS: timing, loose coupling and fault tolerance
– Reliability – resend lost messages?
– Lifespan – how long to keep data (validity)
– Durability – keep/deliver data for late joiners?
– History – amount of data to keep/deliver to late joiners, retain in cache
– Presentation – order in which to deliver data
– Deadline – control notifications of missed data
– Liveliness – presence fidelity
– Ownership and Strength – failover
– Time-based filter – control how frequently to receive data
– Content filter – control which data to receive based on content
– Resource limits – constrain memory usage
© 2013 Real-Time Innovations (RTI)May 2013 8

9. Complexity
MQTT
• Simpler up front
– No explicit data types /
interfaces
– Minimal QoS
• Assumes future:
– Integration
– Administration
• More integration/mediation
required over time
DDS
• Requires up-front investment
– Data model
– QoS
• Minimizes future complexity
– Integration
– Deployment-time configuration
and administration
– Evolution
© 2013 Real-Time Innovations (RTI)May 2013 9

10. ARCHITECTURES FOR THE
INTERNET OF THINGS
© 2013 Real-Time Innovations (RTI)May 2013 10

11. Device
App App App
Device Gateway
Broker / ESB
Gateway
• Most common approach today
• Gateway co-located with device
or broker
– Based on Connext Integrator or
Apache Camel
– RTI currently provides JMS and
Web Service interfaces, adapter
SDK
© 2013 Real-Time Innovations (RTI)
MQTT
Enterprise messaging
Device
App
Device or Dedicated System
App App App App
DDS: shmem, bus, LAN
DDS over LAN
DDS
Web Service, JMS, MQTT, AMQP
May 2013 11

12. Device
App App App
Device
Broker / ESB
Integrate DDS into the Broker/ESB
• Integrate devices using their
native protocol (DDS or
MQTT)
• No protocol gateways
• (DDS routing services may
still be required, e.g., over a
WAN)
© 2013 Real-Time Innovations (RTI)
DDS
Enterprise messaging
Device
App
Device or Dedicated System
App App App App
DDS: shmem, bus, LAN
DDS over LAN
MQTT
May 2013 12

13. Dual Clouds
© 2013 Real-Time Innovations (RTI)
Device
App App App
Device
Broker / ESB
Enterprise messaging
Device or Dedicated System
App App App App
DDS
Gateway
MQTT
DDS
Edge
Real-Time
Cloud
App App App
IT Cloud
Gateway
May 2013 13

14. MQTT and DDS Summary
• Easy to confuse
– Address M2M, IoT, common business drivers
– Some common capabilities
• Optimized for different applications
– MQTT: telemetry
– DDS: communication within Intelligent Systems
– Little practical overlap other than mindshare
• More complementary than competitive
© 2013 Real-Time Innovations (RTI)May 2013 14