+

Internet of Things Protocols

Charles Gibbons

Enterprise Architect @ apicrazy.com

6th October 2014

+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

+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

Devices: Independent &

Distributed

SRF and P2P Radio Links

UART / Coax / Serial Lines

Home Hubs & Gateways

TCP UDP

MQTTMQTT-

SNCoAP

HTTP

Web

Sockets

XMPP

+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

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

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

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

+MQTT & CoAP ComparisonBoth 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.

+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

+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

+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/