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.
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.
The most common physical layer protocols used by embedded systems are:
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.
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.
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 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 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 (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.
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:
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.
The table below contains a summary of the IoT protocol landscape.
|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.
The illustration below provides another good summary of the performance benefit that these protocols bring to IoT. From Zach Shelby's presentation “Standards Drive the Internet of Things.”
On the left, the protocol stack for Web applications can easily produce a data overhead of hundreds or thousands of bytes. By comparison, IoT protocols are optimized for constrained devices and networks, and produce a much smaller data overhead of tens of bytes.