• Save
Comparison of MQTT and DDS as M2M Protocols for the Internet of Things
Upcoming SlideShare
Loading in...5
×
 

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

on

  • 5,592 views

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 ...

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.

Statistics

Views

Total Views
5,592
Views on SlideShare
5,560
Embed Views
32

Actions

Likes
16
Downloads
0
Comments
0

2 Embeds 32

https://twitter.com 31
http://mobilebit.wordpress.com 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • 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

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

  • MQTT and DDS ComparisonDisentangling M2M Messaging Protocols for the IoTDavid Barnett@rtidavidMay 2013© 2013 Real-Time Innovations (RTI)
  • 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
  • Target Different Messaging UsesMQTT• Telemetry: device to server, datacenter, back office, IT cloud• Centralized & server-basedanalytics, business logic andintegrationDDS• Intelligent Systems: within andbetween devices, dedicatedsystems, real-time cloud• Analytics, biz logic & integrationdistributed, embedded, at edge© 2013 Real-Time Innovations (RTI)DeviceApp App AppDevice DeviceBroker / ESBDeviceAppDevice or Dedicated SystemApp App App AppMay 2013 3
  • Typical MQTT Deployment & Apps• At-home patient monitoring• Energy usage monitoring• Supply chain, cargo and inventorytracking (e.g. using RFID)• Remote resource monitoring(e.g. wells, pipelines, environment)• Point of sale and in-casino gamblingdevices• Mobile device to server messaging(e.g. Facebook Messenger)• Automotive telematics© 2013 Real-Time Innovations (RTI)DeviceApp App AppDevice DeviceBroker / ESBMQTT over WANSources: IBM Redbook “Building Smarter Planet Solutions with MQTT and IBM WebSphere MQ Telemetry,” mqtt.orgEnterprise messaging over LANMay 2013 4
  • Typical DDS Deployment & Apps• In-hospital patient monitoring• Medical imaging and surgical devices• Manufacturing (industrialcontrol, testing)• Monitoring and control of powergeneration and grid• Control of robotics and unmannedvehicles• Automotive driver safety andinfotainment• Telecom equipment management• Aerospace and defense controlsystems• High-Performance Computing (HPC)• Latency-sensitive IT(trading, real-time sports betting)© 2013 Real-Time Innovations (RTI)Source: www.rti.com/company/customers.htmlDeviceAppDevice or Dedicated SystemApp App App AppDDS: shmem, bus, LANDDS over LANDDS over WANMay 2013 5DeviceAppDevice or Dedicated SystemApp App App App
  • Apps Have Different RequirementsTelemetry (MQTT) Intelligent Systems (DDS)Network Usually WAN, sometimes LAN Combo of shared memory, bus, LAN, WANAdministration • Some configuration acceptable• IT involved• Often autonomous• Admin should be minimized; may not beavailableMessage rate A few messages/second per device Up to 10,000s messages/second per deviceLatency • 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 dataFault tolerance Brief service interruptions tolerable Service interruptions potentially calamitous“Interoperability” • Protocol level• Between independent clientand broker implementations• Can have centralized integrationlogic (e.g., ESB)• Application and protocol level• Between independently developed apps(explicit data model / interfaces)• Can’t depend on centralized integrationlogic© 2013 Real-Time Innovations (RTI)May 2013 6
  • Fundamental Difference: ArchitectureMQTT• Centralized– All comms route through broker– Typically TCP– Broker queues messages– Some service interruption whenbroker fails over• Administered– Broker itself– Clients configured withbroker/server addressDDS• 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 serviceinterruptions• No admin/config required at deployment– Automatic discovery  plug-and-play– Self-forming and self-healing© 2013 Real-Time Innovations (RTI)DeviceApp App AppDevice DeviceBroker / ESBDeviceAppDevice or Dedicated SystemApp App App AppMay 2013 7
  • Quality of Service (QoS) AddressesDifferent 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
  • ComplexityMQTT• Simpler up front– No explicit data types /interfaces– Minimal QoS• Assumes future:– Integration– Administration• More integration/mediationrequired over timeDDS• Requires up-front investment– Data model– QoS• Minimizes future complexity– Integration– Deployment-time configurationand administration– Evolution© 2013 Real-Time Innovations (RTI)May 2013 9
  • ARCHITECTURES FOR THEINTERNET OF THINGS© 2013 Real-Time Innovations (RTI)May 2013 10
  • DeviceApp App AppDevice GatewayBroker / ESBGateway• Most common approach today• Gateway co-located with deviceor broker– Based on Connext Integrator orApache Camel– RTI currently provides JMS andWeb Service interfaces, adapterSDK© 2013 Real-Time Innovations (RTI)MQTTEnterprise messagingDeviceAppDevice or Dedicated SystemApp App App AppDDS: shmem, bus, LANDDS over LANDDSWeb Service, JMS, MQTT, AMQPMay 2013 11
  • DeviceApp App AppDeviceBroker / ESBIntegrate DDS into the Broker/ESB• Integrate devices using theirnative protocol (DDS orMQTT)• No protocol gateways• (DDS routing services maystill be required, e.g., over aWAN)© 2013 Real-Time Innovations (RTI)DDSEnterprise messagingDeviceAppDevice or Dedicated SystemApp App App AppDDS: shmem, bus, LANDDS over LANMQTTMay 2013 12
  • Dual Clouds© 2013 Real-Time Innovations (RTI)DeviceApp App AppDeviceBroker / ESBEnterprise messagingDevice or Dedicated SystemApp App App AppDDSGatewayMQTTDDSEdgeReal-TimeCloudApp App AppIT CloudGatewayMay 2013 13
  • 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