IAB-5039 : MQTT: A Protocol for the Internet of Things (InterConnect 2015)

© 2015 IBM Corporation
IAB 5039
MQTT: – A protocol for the
Internet of Things
Peter Niblett
IBM Senior Technical Staff Member
IBM Internet of Things Foundation
peter_niblett@uk.ibm.com

Source:http://www.digitalcommunities.com/articles/FutureStructure-The-New-Framework-for-Communities.html
The Internet of Things is the next Internet Frontier

Try this URL
2
http://bit.ly/ibmwb

What is MQTT?
What is it for?
How does it compare with HTTP?
What is the new OASIS Standard version?
What you need to develop with MQTT
MQTT Servers
MQTT Clients and API’s
The IBM Internet of Things Foundation
How does it use MQTT?

Lossy or
Constrained
Network
Monitoring &
Analytics
Server
Real-World Aware Business Processing
High volumes of data/events
IT Systems
In this arena, open source and standards are essential
1999 Invented by Dr. Andy Stanford-Clark (IBM),
Arlen Nipper (now Cirrus Link Solutions)
2011 - Eclipse PAHO MQTT
open source project
2004 MQTT.org open community
2014 – MQTT 3.1.1 Standard
is Ratified
Axway, Blackberry, Cimetrics, Cisco,
Cognizant, dc-Square, Eclipse,
Emerson, Eurotech, IBM, Kaazing,
M2MI, Red Hat, Solace, Software
AG, Telit, TIBCO, VMware, WSO2
Evolution of an open technology
MQTT is a lightweight publish/subscribe protocol
with reliable bi-directional message delivery

Sense and ControlVisualise and Respond
Mobile
Web
Intelligence
and Analytics
Interconnect with IBM MessageSight,
Internet of Things Foundation or MQ
Traditional
Backend Systems BigData
Sensor Area Network
Home Area Network
Personal Area Network
Vehicle Area Network
Sensors Actuators
Applications
MQTT
Edge Gateway
MQTT – Wide Area Network protocol for Internet of Things

You need to connect using more than just HTTP
The HTTP standard revolutionized how we consume data
• A single simple model: Send a request, read the response
• Available via any tablet, laptop, phone, PC etc.
Mobile and the Internet of Things applications have
additional challenges:
• HTTP remains ideal for requesting data from a known source
– e.g. a mobile user requesting information
• MQTT adds an event-oriented paradigm:
– Emitting information one to many
– Listening for events whenever they happen
– Distributing minimal packets of data in huge volumes
– Pushing information over unreliable networks
– Reliably completing mobile business transactions

Guiding Principles behind MQTT
MQTT was designed with the following primary intentions
• Minimize the “on-the-wire” footprint
• Expect frequent network disruptions
• Deal with slow, poor quality or expensive networks
• Expect client applications to have limited processing resources
available
• Exploit publish/subscribe
• Provide several qualities of service
• Support secure connections
– Utilise TLS-provided authentication and encryption
• Provide an open published protocol
– ease of adoption by device vendors and third-party client
software
• Simple API for quick development

Central
Systems
Monitoring
- temp, pressure...
Control
- valves…
4000 devices integrated, needed to add 8000 more BUT:
• Satellite network was saturated due to polling of devices
• Monitoring system CPU was running at 100%
• Other applications needed access to data ("SCADA prison")
Proprietary polling protocol
Billing
Maintenance
SCADA
low-bandwidth,
expensive comms
Real Life Example – Before MQTT

Central
Systems
Billing
Maintenance
SCADA
low-bandwidth,
expensive comms
Scalability for whole pipeline!
Network traffic much lower - events pushed to/from devices and report by exception
Network cost reduced
Lower CPU utilization
Broken out of the SCADA prison – data accessible to other applications
Message Broker
pub sub
transformation
Enterprise MessagingMQTT
20 Field
Devices to 1
Concentrator
Enterprise to physical world solution with MQTT

A producer publishes a message (publication) on a Topic
A consumer subscribes (makes a subscription) for messages on a Topic
A message server matches publications to subscriptions
If none of them match the message is discarded
If one or more matches the message is delivered to each matching consumer
Publish / Subscribe has three important characteristics:
1. It decouples message senders and receivers, allowing for more flexible applications
2. It can take a single message and distribute it to many consumers
3. This collection of consumers can change over time
Publish / Subscribe Messaging (One to Many)

 MQTT protocol control packets:
• Fixed header (2 bytes)
• Variable header (optional, length varies)
• Message payload (optional, length encoded, up to 256MB)
 Fixed header indicates the packet type, the length of the
payload and Quality of Service
 Variable header contents depend on packet type
• Message ID, Topic name, client identifier and so on.
Fixed Variable Payload
MQTT Protocol Details - Headers

 Each bit in each byte is important!
 Disconnect and Pings include
only the 2 byte fixed header
 Remaining Length allows for a
256MB payload
• Uses 1 byte for up to 127 bytes,
• 2 bytes for up to 16383 bytes
• Max. 4 bytes = 256MB
A 2 byte packet? What can you do with that?!

 Most control packets have a
corresponding acknowledgment
• e.g. CONNECT/CONNACK
 CONNECT
• Can restart a previous session
• Can specify a “Last Will and Testament”
message and topic
 SUBSCRIBE can specify multiple topics
 PUBLISH flows
• Sent from client → server to publish a
message, or Server → client to send
messages
• Flow depends on QoS level
Connection
Management
CONNECT
CONNACK
DISCONNECT
PINGREQ
PINGRESP
Subscription
Management
SUBSCRIBE
SUBACK
UNSUBSCRIBE
UNSUBACK
Message
Delivery
PUBLISH
PUBACK
PUBREC
PUBREL
PUBCOMP
MQTT protocol flows

MQTT server
CONNECT
SUBACK
SUBSCRIBE
PINGREQ
CONNACK
PINGRESP
Has a subscriber
connected on a topic
Is connected, and
is awaiting
messages
Is the connection
still active? Yes!
The life of an MQTT client
MQTT
client

MQTT Server
PUBLISH
PUBLISH
PUBREC
Send some important
messages (QoS 2)
Send some low
importance messages
(QoS 0)
PUBREL
PUBCOMP
DISCONNECTI'm done!
The life of a MQTT client (2)

QoS 0: At most once delivery (non-persistent)
– No retry semantics are defined in the protocol.
– The message arrives either once or not at all.
QoS 1: At least once delivery (persistent,
duplicates are possible)
– Sender sends message with Message ID in the message header
– Receiver acknowledges with a PUBACK control packet
– Message is resent with DUP bit set if the PUBACK is not received
QoS 2: Exactly once delivery (persistent)
– Two stage process to ensure that message is not duplicated
– Server acknowledges with a PUBREC control packet
– Client releases message with a PUBREL control packet
– Server acknowledges completion with a PUBCOMP control packet
MQTT Qualities of Service

 Every message is published to a Topic
 Topic names are arranged in a Topic hierarchy
• Levels separated by “/”
• Implementations can pre-define individual
Topics, prescribe a scheme for Topic names, or
allow free rein to publishers or subscribers
 Subscriptions can use wildcarded topic strings
• Single-level wildcards “+” can appear anywhere
in the topic string
• Multi-level wildcards “#” can only appear at the
end of the string
• Wildcards must be next to a “/” separator
 MQTT topic strings can be 64KB long
Fruit
Grape
Red White
Fruit/#
Fruit/Grape/+
Fruit/+/Red
MQTT Topics

 MQTT provides a way for client and server to detect failed
connections
• At connection time, a keep alive interval can be specified
 If the server does receive a regular PINGREQ request (or other
packet) it assumes the connection (or the client) has failed.
 A client can also use PINGREQ to test the connection to the
server. If it does not receive a PINGRESP it can assume that the
connection (or server) has failed.
 The maximum keep alive interval is 18 hours.
• Can specify a value of 0 to disable keep alive
?
MQTT Keep Alive

 During connection, a Will message and topic can be
specified
• Abnormal disconnections will cause the server to publish the
message
• Clean disconnects will not cause the message to publish
 The client can set the Will message as retained
• New subscribers then get the message (if it was published)
 This can be used to report the connection status of the
client
• Will message is a retained “down”
• Upon connecting, client publishes a retained “up” message.
MQTT Last Will & Testament

MQTT server
CONNECT
SUBACK
SUBSCRIBE
CONNACK
Authentication and Authorization
MQTT
client
ClientId, username, password
(password could be an OAuth or
other kind of token)
PUBLISH
Topic name
Topic expression
Authorize this user’s attempt to
publish to this Topic
Authorize this user’s attempt to
subscribe to the Topic(s)
Authenticate, Identify and
Authorize the user
Authenticated
TCP/IP
connection

MQTT – Key things to remember
• Capabilities
• One-many publish / Subscribe
• Reliable store+forward
• Bidirectional communications
• Long-running connections
• Decoupling
• Easy to add new message producers or consumers
• Simplicity
• Small protocol, small clients (kBytes)
• Implementable on low power devices
• Network efficiency
• Small headers
• Avoids polling
• Event-orientation
• Near real-time notification of events

MQTT 3.1.1 – what has changed?
• New protocol name and version number in the CONNECT packet
• Indicates that the client wants to use 3.1.1 rather than 3.1
• Client Identifiers are now permitted to have more than 23 characters, and
can include Unicode characters
• Password field can now be either binary or character based
• “Will Message” can now be binary or character
• CONNACK now informs the client if it was holding state or not
• SUBACK can now indicate the failure of a Subscribe request
• Standardised the way of carrying MQTT over a Websocket transport
• Numerous clarifications, including
• Message ordering
• Message retry
• Unicode characters
• Overlapping subscriptions
• Error handling and “reserved bits”
• More precise language in the specification document itself
• Numbered conformance statements
• Specification is owned by the OASIS standards development organization

- MQTT Clients and API’s
- MQTT Servers
What you need to
develop with MQTT

Sense and ControlVisualise and Respond
MQTT Server
(on-premises or cloud)
Sensor Area Network
Home Area Network
Personal Area Network
Vehicle Area Network
Sensors
Actuators
MQTT
Edge Gateway
MQTT Clients and Servers
Web MQTT
client
Mobile
MQTT client
Embedded
MQTT client
MQTT client
or satellite
server

Client libraries provide some or all of the following capabilities:
• Functions to build and parse the MQTT protocol control packets
• Threads to handle receipt of incoming control packets
• QoS 1 and QoS 2 delivery using a local persistence store
• KeepAlive handling
• Simple API for developers to use
 Open Source clients available in Eclipse Paho project
• C, C++, C# (.Net), Java, JavaScript, Python and Go
 Clients for other languages are available, see mqtt.org/software
• E.g. Delphi, Erlang, .Net, Objective-C, PERL, PHP, Ruby
Not all of the client libraries listed on mqtt.org are current. Some are at an early or experimental stage of
development, whilst others are stable and mature.
You can develop an MQTT client application by programming directly to the MQTT
protocol specification, however it is more convenient to use a prebuilt client
MQTT Clients and APIs

Eclipse Paho clients
• C / C++
• C Client for Posix and Windows
• C++ Client for Posix and Windows
• C Client for embedded systems
• Java
• J2SE Client
• Android Service
• Others
• JavaScript Client (for browser and hybrid applications)
• Python Client
• Go Client
• C# .Net and WinRT Client
• Visit http://www.eclipse.org/paho/#downloads

Paho C Client libraries
• Linux (Posix) or Windows
• Full featured clients providing an MQTT api with QoS1, QoS2 and
keepAlive handling
• Synchronous client (fully synchronous mode)
– Connect, Disconnect, Publish, Subscribe and Unsubscribe calls block until they
receive a response from the server
– Applications use mqtt_receive() to read inbound messages
– Client library runs entirely on the calling application’s thread
• Synchronous client (asynchronous mode)
– Selected by registering a messageReceived, messageDelivered or
connectionLost callback.
– Library starts a separate thread to handle these callbacks
• Asynchronous (use MqttAsynch )
– All API calls are processed asynchronously and invoke a callback when complete
• Embedded Client (device environment)
• Limited to the construction and parsing of MQTT control packets
• Client runs entirely on the calling application’s thread
• Intended for embedded devices that don’t run Linux (e.g. ARM mbed)

Commercial
• IBM (MQ and MessageSight Appliance)
• Software AG (webMethods Nirvana Messaging)
• dcSquare (HiveMQ)
Open Source or Free download
• Mosquitto (mosquitto.org -> Eclipse)
• RSMB (IBM developerWorks -> Mosquitto)
• ActiveMQ (Apache)
• Apollo (Apache)
• JoramMQ
• Moquette
• Mosca (node.js)
• RabbitMQ (Pivotal)
• mqtt.js , eMQTT (GitHub)
Cloud-hosted
• IBM Internet of Things Foundation (available via Bluemix)
• Eclipse Sandbox (implemented using Mosquitto)
• Eurotech Everywhere Device Cloud
• Litmus Automation Loop
• m2m.io
• Xively
MQTT Servers (information from mqtt.org)

MQTT Server Overview
IBM MessageSight Physical Appliance for on-premise / DMZ or
Virtual Edition for Cloud deployment
-Secure (tamper-proof)
-High Volume
-High availability
-Quick and easy to deploy and manage
WebSphere MQ Traditional enterprise messaging server,
includes optional MQTT feature
IBM Internet of Things
Foundation
Cloud based server, uses MQTT to
communicate with devices and applications
RSMB / Mosquitto Small footprint MQTT server designed for
edge of network / satellite location:
-Bridge SAN to WAN
-Multiplex multiple devices over single
connection to data centre
-Autonomous messaging for satellite location
-Open source
MQTT Servers from IBM

Eclipse Java client APIs
• MqttClient - “Synchronous” or “blocking” API
• This was the original API
• Some processing is done on background threads, but most
calls block until their processing is complete
• Slightly simpler to program to than the Asynch API
• MqttAsyncClient – New “Asynchronous” API
• Better fit to asynchronous environments, e.g. Android
• All significant processing is done on background threads
• The synchronous client is actually implemented as a thin layer
on top of the Asynchronous one
• Both interfaces are included in the same Jar file
• org.eclipse.paho.client.mqttv3.jar

Eclipse JavaScript API
client = new Messaging.Client(host,
port_number, clientid);
client.connect({onSuccess:onConnect,
keepAliveInterval:0});
function onConnect() {
client.subscribe(topic);
};
Example code
The JavaScript API for MQTT is fully asynchronous.
Its functions return their completion status via onSuccess and onFailure callbacks

Demo: Internet of Things JavaScript API
client = new Paho.MQTT.Client("quickstart.messaging.internetofthings.ibmcloud.com",
1883,"a:quickstart:PetersClientId");
client.onConnectionLost = onConnectionLost;
client.connect({onSuccess:onConnect, keepAliveInterval:0});
function onConnectionLost(responseObject) {
if (responseObject.errorCode !== 0)
console.log("onConnectionLost:"+responseObject.errorMessage);
else
console.log("Disconnected");
};
console.log("Connected");
};
1. Example code: Connect to MQTT Server

Demo: Internet of Things JavaScript API
client = new Paho.MQTT.Client("quickstart.messaging.internetofthings.ibmcloud.com",
1883,"a:quickstart:PetersClientId");
client.onConnectionLost = onConnectionLost;
client.connect({onSuccess:onConnect, keepAliveInterval:0});
function onConnectionLost(responseObject) {
if (responseObject.errorCode !== 0)
console.log("onConnectionLost:"+responseObject.errorMessage);
else
console.log("Disconnected");
};
console.log("Connected");
};
// Once a connection has been made, make a subscription to receive data
console.log("onConnect");
// subscribe to a specific device
client.subscribe(" iot-2/type/+/id/<device-id>/evt/+/fmt/+");
};
client.onMessageArrived = onMessageArrived;
function onMessageArrived(message) {
console.log("onMessageArrived:"+message.destinationName + " " +
message.payloadString);
};
2. Example code: Subscribes and displays messages received

- How does it use MQTT?
The IBM Internet of
Things Foundation

Industry-specific Solutions
Design &
Engineer Operate Manage
Analyze and Optimize
IBM Internet of Things Foundation: What is it?
Products,
Assets,
Infrastructure
Protocols & Gateways
Secure
Connect, Collect and Store
A new cloud offering within IBM’s Bluemix PaaS offering that allows
Internet-connected devices to be integrated directly into Bluemix solutions
Connect, Collect and Store
information from a range of
things with range of volume,
variety and velocity

IBM Internet of Things Foundation
Secure + Connect
(Messaging)
Store Data
(Historian)
Manage Connections
(IoTF Portal)
1b
Assemble
Analytics
IBM IoT
Foundation
IBM Bluemix
Mobile
1. Real-time data API
2. Management API
3. Historical data API
2
3
1a

APIs to the IoT Foundation cloud
1. Real-time data APIs
a) Device API
– Lets a device connect and send real-time data, and lets it receive commands
– This interface uses MQTT, but with some constraints on its use
– Documented at https://developer.ibm.com/iot/recipes/improvise-registered-devices/
b) Application API
– Lets you subscribe to receive live streams of data from devices, and lets you send
commands to devices
– This interface uses MQTT, but with some constraints on its use
– Documented at https://developer.ibm.com/iot/recipes/improvise-application-development/
2. Management Interface
 Lets you register or deregister devices, and view details of your IoTF organization
 REST-like HTTP interface
 Documented at https://developer.ibm.com/iot/recipes/api-documentation/
3. Historical data API
 Lets you query the historical data store to retrieve data sent from devices in the past
 REST-like HTTP interface
 Documented at https://developer.ibm.com/iot/recipes/api-documentation/

IoT Foundation – MQTT details
Devices
• Devices connect using a clientID of the form d:<org-
id>:<type-id>:<device-id>.
• Each device is given its own topic space and
cannot access topics outside that space.
• In order to connect to the regular service a Device
must be registered with an organization and
authenticate itself with a token provided as part of
the registration process
• A registered device can publish to event topics
of the form iot-2/type/+/id/+/evt/+/fmt/+ (such
topics get auto-created if necessary)
• It can auto-create command topics of the form
iot-2/type/+/id/+/cmd/+/fmt/+
• DeviceType and ID are omitted from the topic
strings that are used by the Device code, e.g.
iot-2/evt/<event-type-id>/fmt/<format>
(the IOTF inserts the device information itself)
• A Device connecting to the Quickstart service must
supply “quickstart” as the <org-id> part of the
clientID
• It does not perform any kind of authentication
• It is not able to make subscriptions
• It can only publish to topics of the form
iot-2/evt/+/fmt/json
Applications
• Applications connect using a clientID of the form
a:<org-id>:<app-id> (the app is free to choose
the app-id but it must not clash with any other
app that is running in the organization)
• Unlike Devices, Applications have access to all
topics within their organization. These topics
include the Device Type and Device ID
• In order to connect to the regular service an
Application must authenticate with an API Key.
Any member of an organization can create an
API key for that organization
• Applications can publish or subscribe to
any event or command topic in their
organization, whether or not they
correspond to registered devices. These
topics get auto-created if required.
• They can subscribe to any status topic for
their organization, but not publish to them
• An Application connecting to the Quickstart
service must supply “quickstart” as the <org-id>
part of the clientID
• It can publish messages to any Quickstart
event topic (including formats other than
JSON), auto-creating the topic if necessary
• It can subscribe to any device or status
event topic

MQTT
Messaging optimized for mobile, smart sensors and telemetry devices
Enables intelligent decision-making based on remote real-world events
Management of static or moving assets, people, locations
Simple APIs for Java, JavaScript and other languages reduce the
burden for application developers
An open protocol with Industry leadership & mindshare
• MQTT Protocol and client code contributed to open source
• see MQTT.org and Eclipse Paho
• Open licence allows development communities to provide further client
code & device support
• 16+ MQTT servers and 40+ MQTT clients
• Version 3.1.1 is now a ratified OASIS standard
Summary

 MQTT information
 http://mqtt.org
 MQTT 3.1.1 Specification
 http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.doc
 RSMB (server implementation)
 http://www.alphaworks.ibm.com/tech/rsmb/
 IBM Internet of Things Foundation
 https://internetofthings.ibmcloud.com
 Eclipse Paho project
 http://www.eclipse.org/paho
 Eclipse IoT Industry Working Group
 http://iot.eclipse.org
 OASIS MQTT Technical Committee
 https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=mqtt
Useful links

Notices and Disclaimers
Copyright © 2015 by International Business Machines Corporation (IBM). No part of this document may be reproduced or
transmitted in any form without written permission from IBM.
U.S. Government Users Restricted Rights - Use, duplication or disclosure restricted by GSA ADP Schedule Contract with
IBM.
Information in these presentations (including information relating to products that have not yet been announced by IBM) has been
reviewed for accuracy as of the date of initial publication and could include unintentional technical or typographical errors. IBM
shall have no responsibility to update this information. THIS DOCUMENT IS DISTRIBUTED "AS IS" WITHOUT ANY WARRANTY,
EITHER EXPRESS OR IMPLIED. IN NO EVENT SHALL IBM BE LIABLE FOR ANY DAMAGE ARISING FROM THE USE OF
THIS INFORMATION, INCLUDING BUT NOT LIMITED TO, LOSS OF DATA, BUSINESS INTERRUPTION, LOSS OF PROFIT
OR LOSS OF OPPORTUNITY. IBM products and services are warranted according to the terms and conditions of the
agreements under which they are provided.
Any statements regarding IBM's future direction, intent or product plans are subject to change or withdrawal without
notice.
Performance data contained herein was generally obtained in a controlled, isolated environments. Customer examples are
presented as illustrations of how those customers have used IBM products and the results they may have achieved. Actual
performance, cost, savings or other results in other operating environments may vary.
References in this document to IBM products, programs, or services does not imply that IBM intends to make such products,
programs or services available in all countries in which IBM operates or does business.
Workshops, sessions and associated materials may have been prepared by independent session speakers, and do not
necessarily reflect the views of IBM. All materials and discussions are provided for informational purposes only, and are neither
intended to, nor shall constitute legal or other guidance or advice to any individual participant or their specific situation.
It is the customer’s responsibility to insure its own compliance with legal requirements and to obtain advice of competent legal
counsel as to the identification and interpretation of any relevant laws and regulatory requirements that may affect the customer’s
business and any actions the customer may need to take to comply with such laws. IBM does not provide legal advice or
represent or warrant that its services or products will ensure that the customer is in compliance with any law.

Notices and Disclaimers (con’t)
Information concerning non-IBM products was obtained from the suppliers of those products, their published
announcements or other publicly available sources. IBM has not tested those products in connection with this
publication and cannot confirm the accuracy of performance, compatibility or any other claims related to non-IBM
products. Questions on the capabilities of non-IBM products should be addressed to the suppliers of those products.
IBM does not warrant the quality of any third-party products, or the ability of any such third-party products to
interoperate with IBM’s products. IBM EXPRESSLY DISCLAIMS ALL WARRANTIES, EXPRESSED OR IMPLIED,
INCLUDING BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
PARTICULAR PURPOSE.
The provision of the information contained herein is not intended to, and does not, grant any right or license under any
IBM patents, copyrights, trademarks or other intellectual property right.
• IBM, the IBM logo, ibm.com, Bluemix, Blueworks Live, CICS, Clearcase, DOORS®, Enterprise Document
Management System™, Global Business Services ®, Global Technology Services ®, Information on Demand,
ILOG, Maximo®, MQIntegrator®, MQSeries®, Netcool®, OMEGAMON, OpenPower, PureAnalytics™,
PureApplication®, pureCluster™, PureCoverage®, PureData®, PureExperience®, PureFlex®, pureQuery®,
pureScale®, PureSystems®, QRadar®, Rational®, Rhapsody®, SoDA, SPSS, StoredIQ, Tivoli®, Trusteer®,
urban{code}®, Watson, WebSphere®, Worklight®, X-Force® and System z® Z/OS, are trademarks of
International Business Machines Corporation, registered in many jurisdictions worldwide. Other product and
service names might be trademarks of IBM or other companies. A current list of IBM trademarks is available on
the Web at "Copyright and trademark information" at: www.ibm.com/legal/copytrade.shtml.

Thank You
Your Feedback is
Important!
Access the InterConnect 2015
Conference CONNECT Attendee
Portal to complete your session
surveys from your smartphone,
laptop or conference kiosk.

IAB-5039 : MQTT: A Protocol for the Internet of Things (InterConnect 2015)

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (19)

Similar to IAB-5039 : MQTT: A Protocol for the Internet of Things (InterConnect 2015)

Similar to IAB-5039 : MQTT: A Protocol for the Internet of Things (InterConnect 2015) (20)

Recently uploaded

Recently uploaded (20)

IAB-5039 : MQTT: A Protocol for the Internet of Things (InterConnect 2015)