People Internet vs. Device Internet

Not surprisingly, people and embedded devices use the Internet very differently.

People make use of the Internet largely through the World Wide Web — a set of applications that run on the Internet. Of course, the Web is not the entirety of the human interface for the Internet. We also use e-mail, text messages, mobile apps, and bevy of social media tools.

In the Internet of Things, by comparison, autonomous electronic devices exchange information with each other over the Internet. But these devices do not yet have the machine equivalent of Web browsers and social media. We are at the beginning of the development of these new tools and services.

TCP/IP Protocol Stack

The TCP/IP protocol stack is at the heart of the Internet. It can be represented using the OSI seven-layer reference model, as illustrated below. The top three layers are grouped together, which simplifies the model.

Physical and Data Link Layers

The most common physical layer protocols used by embedded systems are:

• Ethernet (10, 100, 1G)
• WiFi (802.11b, g, n)
• Serial with PPP (point-to-point protocol)
• GSM, 3G, LTE, 4G

Network Layer

This is where the Internet lives. The Internet — short for Inter-Network — is named so because it provides connections between networks, between the physical layers. This is where we find the ubiquitous IP address.

Transport Layer

Above the Network layer, we find TCP and UDP, the two transport protocols.

TCP is used for most of our human interactions with the Web (e-mail, Web browsing, and so on). And so many people believe that TCP should be the only protocol used at the Transport layer. TCP provides the concept of a logical connection, acknowledgement of transmitted packets, retransmission of lost packets, and flow control.

But for an embedded system, TCP can be overkill. This is why UDP, even if it has long been relegated to network services such as DNS and DHCP, is now finding a new home in sensor acquisition and remote control.

UDP is also better suited for real-time data applications such as voice and video. The reason is that TCP’s packet acknowledgment and retransmission features are useless overhead for those applications. If a piece of data (such as a bit of spoken audio) does not arrive at its destination in time, there is no point in retransmitting the packet. It would arrive out of sequence and garble the message.

When designing your IoT device, you must consider how you will connect your local network to the Internet. You can do so via a gateway, or you can build this functionality into the device itself. Many MCUs now have an integrated Ethernet controller, which makes this an easier task.

The IoT Protocols

Can you build an IoT system with familiar Web technologies? Yes you can, although the result would not be as efficient as with the newer protocols.

HTTP(S) and Websockets are common existing standards, which can be used to deliver XML or JavaScript Object Notation (JSON) in the payload. JSON provides an abstraction layer for Web developers to create a stateful Web application with a persistent connection to a Web server.

HTTP

HTTP is the foundation of the client-server model used for the Web. The more secure method to implement HTTP is to include only a client in your IoT device, not a server. In other words, it is safer to build an IoT device that can only initiate connections, not receive. After all, you do not want to allow outside access to your local network.

WebSocket

WebSocket is a protocol that provides full-duplex communication over a single TCP connection between client and server. It is part of the HTML 5 specification. The WebSocket standard simplifies much of the complexity around bi-directional Web communication and connection management.

XMPP

XMPP (Extensible Messaging and Presence Protocol) is a good example of an existing Web technology finding new use in the IoT space.

XMPP has its roots in instant messaging and presence information. It has expanded into signaling for VoIP, collaboration, lightweight middleware, content syndication, and generalized routing of XML data. It is a contender for mass scale management of consumer white goods such as washers, dryers, refrigerators, and so on.

CoAP

Although Web protocols are available and usable for IoT devices, they are too heavy for the majority of IoT applications. The Constrained Application Protocol (CoAP) was designed by the IETF for use with low-power and constrained networks. CoAP is a RESTful protocol. It is semantically aligned with HTTP, and even has a one-to-one mapping to and from HTTP.

CoAP is a good choice of protocol for devices operating on battery or energy harvesting. Some features of CoAP:

• CoAP uses UDP.
• Because CoAP uses UDP, some of the TCP functions are reproduced in CoAP. For example, CoAP distinguishes between confirmable (requiring an acknowledgement) and non-confirmable messages.
• Requests and responses are exchanged asynchronously over CoAP messages.
• All the headers, methods and status codes are binary encoded, which reduces the protocol overhead.
• Unlike HTTP, the ability to cache CoAP responses does not depend on the request method, but the Response Code.
• CoAP fully addresses the need for an extremely lightweight protocol and the ability for a permanent connection. And if you have a Web background, using CoAP is relatively easy.

MQTT

MQ Telemetry Transport (MQTT) is an open source protocol for constrained devices and low-bandwidth, high-latency networks. It is a publish/subscribe messaging transport that is extremely lightweight and ideal for connecting small devices to constrained networks.

MQTT is bandwidth efficient, data agnostic, and has continuous session awareness. It helps minimize the resource requirements for your IoT device, while also attempting to ensure reliability and some degree of assurance of delivery with grades of service.

MQTT targets large networks of small devices that need to be monitored or controlled from a back-end server on the Internet. It is not designed for device-to-device transfer. Nor is it designed to “multicast” data to many receivers. MQTT is extremely simple, offering few control options.

Comparing IoT Protocols

The table below contains a summary of the IoT protocol landscape.

Protocol	CoAP	XMPP	RESTful HTTP	MQTT
Transport	UDP	TCP	TCP	TCP
Messaging	Request/Response	Publish/Subscribe Request/Response	Request/Response	Publish/Subscribe Request/Response
2G, 3G, 4G Suitability (1000s nodes)	Excellent	Excellent	Excellent	Excellent
LLN Suitability (1000s nodes)	Excellent	Fair	Fair	Fair
Compute Resources	10Ks RAM/Flash	10Ks RAM/Flash	10Ks RAM/Flash	10Ks RAM/Flash
Success Stories	Utility Field Area Networks	Remote management of consumer white goods	Smart Energy Profile 2 (premise energy management, home services)	Extending enterprise messaging into IoT applications

These Internet-specific IoT protocols have been developed to meet the requirements of devices with small amounts of memory, and networks with low bandwidth and high latency.