Successfully reported this slideshow.
Your SlideShare is downloading. ×

Comparison of MQTT and DDS as M2M Protocols for the Internet of Things

Ad

MQTT and DDS Comparison
Disentangling M2M Messaging Protocols for the IoT
David Barnett
@rtidavid
May 2013
© 2013 Real-Tim...

Ad

MQTT & DDS: Cause for Confusion
• Support Machine-to-Machine (M2M)
– Internet of Things (IoT)
– Real-time monitoring and c...

Ad

Target Different Messaging Uses
MQTT
• Telemetry: device to server, data
center, back office, IT cloud
• Centralized & ser...

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Check these out next

1 of 14 Ad
1 of 14 Ad

Comparison of MQTT and DDS as M2M Protocols for the Internet of Things

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.

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.

More Related Content

Slideshows for you (19)

Similar to Comparison of MQTT and DDS as M2M Protocols for the Internet of Things (20)

More from Real-Time Innovations (RTI) (20)

Comparison of MQTT and DDS as M2M Protocols for the Internet of Things

  1. 1. MQTT and DDS Comparison Disentangling M2M Messaging Protocols for the IoT David Barnett @rtidavid May 2013 © 2013 Real-Time Innovations (RTI)
  2. 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. 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. 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. 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. 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. 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. 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. 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. 10. ARCHITECTURES FOR THE INTERNET OF THINGS © 2013 Real-Time Innovations (RTI)May 2013 10
  11. 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. 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. 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. 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

Editor's Notes

  • 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 requirements.
  • Devices are typically geographically distributed. Broker and apps are co-located, e.g., in a data center.
  • ReliabilityLifespanDurabilityHistoryPresentation (ordering)DeadlineLiveliness (presence fidelity)Ownership and strength (failover)Time-based filterResource limits
  • More integration/mediation required over time = complexity creep
  • ExamplesHospitalEdge: PatientReal-time:Care unit (e.g., association of patient with monitoring)IT: EMR / Billing systems / Analytics / loggingIndustrial:Sensors and actuatorsSCADAERPAvionics:Sensors and actuatorsIMA(No IT)Automotive:Edge and R-T cloud: in the vehicle (driver safety, infotainment)IT cloud: telematics, directory services / discoveryDefense:SensorsTrack managementC2, CEC

×