Internet of Things requires communication to devices that are either actuators or sensors. Each actuator and sensor has an identity. Each actuator and sensor may be either directly connected to the world wide web or indirectly connected via a type of gateway. Communication to these devices needs to be reliable. Therefore each device may implement their most suitable communication protocol. This deck describes the main common protocols and their usage for the Internet of Things Charles Gibbons apicrazy.com

1. +
Internet of Things Protocols
Charles Gibbons
Enterprise Architect @ apicrazy.com
6th October 2014

2. +
Protocols
 There are many different usable protocols for communication with M2M
devices for the Internet of Things
 Specific protocols are more appropriate for different devices (e.g. memory &
power profiles)
 Specific protocols are more appropriate for different communication needs
(e.g. State Transfer Model & Event Based Model)
 The most usable protocols are:
 HTTP/HTTPS & WebSockets (and RESTful approaches on those)
 MQTT 3.1 / 3.1.1
 MQTT -SN
 Constrained Application Protocol (CoAP)
 XMPP

3. +
Intro: Protocols & Devices
•Devices are independent &
distributed
•Communications involve
complex Networking and
Addressing
• Selecting the correct
protocol is important
• One size does not fit all
Communications: Protocols,
Networking & Addressing
HTTP
Web
Sockets
Devices: Independent &
Distributed
SRF and P2P
Radio Links
UART /
Coax /
Serial
Lines
Home
Hubs &
Gateways
TCP UDP
MQTT
MQTT-SN
CoAP
XMPP

4. +
HTTP / HTTPS & WebSockets (and
RESTful approaches)
 Small devices (8-bit controllers) can only partially support the protocol (e.g.
POST / GET)
 HTTP Polling inefficient & costly in terms of network traffic & power usage.
 Use HTTP WebSocket: allows a two-way connection that acts as a socket
channel (similar to a pure TCP channel) between the server and client. Once
that has been established, it is up to the system to choose an ongoing
protocol to tunnel over the connection.
 Can use MQTT over WebSockets (firewall-friendly) & can support pure
browser/JavaScript clients using the same protocol.
 Note: WebSockets would utilise most of the available space on a typical 8-bit
device so more suitable protocol for 32-bit devices

5. +
MQTT: https://www.oasis-open.org/committees/mqtt/
 MQTT is a publish/subscribe messaging protocol designed for lightweight
M2M communications. Originally developed by IBM & now open standard.
 MQTT has a client/server model, where every sensor is a client and connects
to a server, known as a broker, over TCP.
 MQTT is message oriented. Every message is a discrete chunk of data,
opaque to the broker.
 Every message is published to an address, known as a topic. Clients may
subscribe to multiple topics. Every client subscribed to a topic receives every
message published to the topic.
 MQTT supports three quality of service levels, “Fire and forget”, “delivered
at least once” and “delivered exactly once”.

6. +
MQTT-SN: http://mqtt.org
 MQTT-SN is a variation of the main protocol aimed at embedded devices on
non-TCP/IP networks, such as Zigbee
 Even though MQTT is designed to be lightweight, it has two drawbacks for
very constrained devices:
1. Every MQTT client must support TCP and will typically hold a connection open to
the broker at all times. For some environments where packet loss is high or
computing resources are scarce, this is a problem.
2. MQTT topic names are often long strings which make them impractical for
802.15.4.
 Both of these shortcomings are addressed by the MQTT-SN protocol, which
defines a UDP mapping of MQTT and adds broker support for indexing topic
names.

7. +
COAP: http://tools.ietf.org/html/draft-ietf-core-coap-18
 CoAP is designed for the needs of constrained devices. CoAP packets are
much smaller than HTTP TCP flows. Packets are simple to generate and can
be parsed in place without consuming extra RAM in constrained devices.
 CoAP runs over UDP, not TCP. Clients and servers communicate through
connectionless datagrams. Retries and reordering are implemented in the
application stack. CoAP allows UDP broadcast and multicast to be used for
addressing.
 CoAP follows a client/server model. Clients make requests to servers, servers
send back responses. Clients may GET, PUT, POST and DELETE resources.
CoAP is designed to interoperate with HTTP and the RESTful web at large
through simple proxies.
 Requests and response messages may be marked as “confirmable” or
“nonconfirmable”.

8. +
MQTT & CoAP Comparison
Both protocols have pros and cons, choosing the right one depends on
your application & device
 MQTT is a many-to-many communication
protocol for passing messages between
multiple clients through a central broker.
 Suited to messaging for live data.
 MQTT clients make a long-lived outgoing
TCP connection to a broker.
 MQTT provides no support for labelling
messages with types or other metadata to
help clients understand it. MQTT messages
can be used for any purpose, but all clients
must know the message formats up-front to
allow communication.
 CoAP is a one-to-one protocol for
transferring state information between
client and server.
 Suited to a state transfer model, not purely
event based.
 CoAP clients and servers both send and
receive UDP packets. In NAT environments,
tunnelling or port forwarding can be used to
allow CoAP, or devices may first initiate a
connection to the head-end as in LWM2M
 CoAP provides inbuilt support for content
negotiation and discovery allowing devices
to probe each other to find ways of
exchanging data.

9. +
XMPP: http://wiki.xmpp.org/web/Tech_pages/IoT_systems
 Extensible Messaging and Presence Protocol (XMPP) is an open
communications protocol for message oriented middleware based on XML
 Originally named Jabber
 Text based
 XMPP features such as federation across domains, publish/subscribe,
authentication and its security even for mobile endpoints are being used to
implement IoT
 XMPP works over TCP or via HTTP using a WebSocket implementation
 Custom functionality can be built on top of XMPP to provide M2M
communications and Identity Services

10. +
Further Reading: MQTT
 Community website: http://mqtt.org/
 Specification:
 http://www.ibm.com/developerworks/webservices/library/ws-mqtt/index.html
 Open source implementations:
 http://www.eclipse.org/paho/
 http://mosquitto.org/
 https://github.com/adamvr/MQTT.js/
 Standards working group:
 https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=mqtt

11. +
Further Reading: COAP
 IP for Smart Objects Alliance: http://www.ipso-alliance.org/
 Specification:
 http://tools.ietf.org/html/draft-ietf-core-coap
 Open source implementations:
 http://sourceforge.net/projects/libcoap/
 https://github.com/morkai/h5.coap
 http://www.contiki-os.org/
 Browser plugin:
 https://addons.mozilla.org/en-US/firefox/addon/copper-270430/
 REST: http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm
 Standards working group: http://tools.ietf.org/wg/core/