Embedded systems using sensors and connectivity are not new to developers. However, using these elements with multiple additional Internet technologies is. Internet protocols (IPs) are not new, but dedicated IPs for the Internet of Things (IoT) are, and they are used to help shape system capabilities. There are multiple IP application layer protocols above TCP/IP sockets. Each one has its advantages and constraints. Knowing them helps developers make the best design choices for a product. Bandwidth requirements, real-time performance, and memory footprint are some of the main criteria when selecting an IoT protocol. Many IoT projects are being driven by chief information officers (CIOs) and IT departments, who are pushing developers to use the technologies and protocols that they know in IoT devices. Nevertheless, IoT devices are often closer to operational technology (OT), and pushing IT technology into the OT domain is often not an optimal choice.

Developers need to be educated that there are better protocol options for IoT devices than IT technologies.

There are multiple categories of IP:

• Consumer versus industrial
• Web services
• IoT services
• Publish/subscribe
• Request/response

These categories must be considered when designing a new system. Let’s look at IPs for the IoT and define the selection criteria.

The Internet

The Internet is the sum of all network equipment used to route IP packets from a source to a destination. The World Wide Web, by comparison, is an application system that runs on the Internet. The Web is a tool built for people on which to exchange information, and in the last 20 years the web has been developed and refined so that ordinary, non-technical people can use the Internet easily and productively. For example, the human interface for the Internet now includes email, search engines, browsers, mobile apps, Facebook, and Twitter, as well as other popular social media.

By comparison, in the IoT, the idea is for electronic devices to exchange information over the Internet. But these devices don’t yet have the machine equivalent of browsers and social media to facilitate communication. The IoT is also different from the Web because of the speeds, scales, and capabilities that IoT devices require in order to work together. These requirements are far beyond what people need or use. We are at the beginning of the development of new tools and services for these systems, and this is one of the reasons a definition of IoT is difficult to lock down. Many visions about what it can, could, or should be, collide.

TCP/IP protocol stack

The TCP/IP protocol stack is at the heart of both the Internet and Web. It can be represented using the seven-layer Open Systems Interconnection (OSI) reference model, illustrated below (Figure 1). The top three layers are grouped together, which simplifies the model.

[Figure 1 | Seven-layer OSI reference model.]

The following is a quick description of important OSI layers from an embedded systems integration perspective:

1. Physical and Data Link Layers

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

• Ethernet (10 Mbps, 100 Mbps, 1 Gbps)
• Wi-Fi (802.11b/g/n)
• Serial point-to-point protocol (PPP)
• GSM, 3G, 4G, LTE

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

3. Transport Layer

Above IP, we have the Transmission Control Protocol (TCP) and User Datagram Protocol (UDP), the two transport protocols. Because TCP is used for most of our human interactions with the Web (email, web browsing, etc.), it is widely believed that TCP should be the only protocol used at the transport layer. TCP provides the notion of a logical connection, acknowledgment of packets transmitted, retransmission of packets lost, and flow control – all of which are great things. But for an embedded system, TCP can be overkill. Therefore, UDP, even if it has long been relegated to network services such as Domain Name Servers (DNS) and the Dynamic Host Configuration Protocol (DHCP), is now finding its place in the domains of sensor acquisition and remote control. If you need some type of management of your data, you can even write your own lightweight protocol on top of UDP to avoid the overhead imposed by TCP.

UDP is also better suited than TCP 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 as it would arrive out of sequence and garble the message.

TCP is sometimes preferred to UDP because it provides a persistent connection. To enable the same with UDP, you must implement this feature in a protocol layer above UDP.

When you are deciding how to move data from the “things” local network onto an IP network, you have several choices. Because the technologies used are familiar and available from a wide range of sources, you can link the two networks via a gateway or you can build this functionality into the “thing” itself. Many microcontrollers (MCUs) now have an Ethernet controller on-chip, which makes this an easier task.

IoT protocols

It is possible to build an IoT system with existing web technologies, even if it is not as efficient as the newer protocols. Hypertext Transfer Protocol/Secure (HTTP/S) and WebSockets are common standards, together with the eXtensible Markup Language (XML) or JavaScript Object Notation (JSON) in the payload. When using a standard web browser (HTTP client), JSON provides an abstraction layer for Web developers to create a stateful Web application with a persistent duplex connection to a Web server (HTTP server) by holding two HTTP connections open.

HTTP

HTTP is the foundation of the client-server model used for the Web. The safest method with which to implement HTTP in your IoT device is to include only a client, not a server. In other words, it is safer when the IoT device can initiate connections to a web server but is not able to receive connection requests; we don’t want to allow outside machines access to the local network where IoT devices are installed.

WebSocket

WebSocket is a protocol that provides full-duplex communication over a single TCP connection through which messages can be sent between client and server. It is part of the Hypertext Markup Language 5 (HTML5) specification. The WebSocket standard simplifies much of the complexity around bi-directional Web communications and connection management.

XMPP

Extensible messaging and presence protocol (XMPP) 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, and has expanded into voice and video calls, 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.

XMPP’s strengths are its addressing, security, and scalability. This makes it ideal for consumer-oriented IoT applications.

HTTP, WebSocket, and XMPP are examples of technologies being pressed into service for IoT. Other groups are also working furiously to develop solutions for the new challenges IoT is presenting us.

Wannabe generic protocols

Many IoT experts refer to IoT devices as constrained systems because they believe IoT devices should be as inexpensive as possible and use the smallest MCUs available while still running a communication stack.

Currently, adapting the Internet for the IoT is one of the main priorities for many global standardization bodies. Table 1 contains a short summary of current activities.

[Table 1 | Constrained systems standardization work.]

If your system does not require the features of TCP and can function with the more limited UDP capabilities, removing the TCP module significantly helps reduce the size of the total code footprint of your product. This is what IP version 6 (IPv6) for Low-power Wireless Personal-Area Networks (6LoWPAN) for wireless sensor networks (WSNs) and the Constrained Application Protocol (CoAP) light Internet protocol bring to the IoT universe.

CoAP

Although the Web infrastructure is available and usable for IoT devices, it is too heavy for most IoT applications. In July 2013, the Internet Engineering Task Forcce (IETF) released CoAP for use with low-power and lossy nodes and networks (LLNs). CoAP, like HTTP, is a RESTful (the ability to manipulate resources and resource identifiers via a uniform application programming interface (API)) protocol.

CoAP is semantically aligned with HTTP, and even has one-to-one mapping to and from HTTP. Network devices are constrained by smaller MCUs with small quantities of flash memory and RAM, while the constraints on local networks are due to high packet error rates and a low throughput (tens of kbps). CoAP can be a good protocol for devices operating on a battery or energy harvesting.

Features of CoAP:

• Because CoAP uses UDP, some of the TCP functionalities are replicated directly in CoAP. For example, CoAP distinguishes between confirmable (requiring acknowledgment) and non-confirmable messages.
• Requests and responses are exchanged asynchronously over CoAP messages (unlike HTTP, where an existing TCP connection is used).
• All the headers, methods, and status codes are binary encoded, which reduces protocol overhead. However, this requires the use of a protocol analyzer to troubleshoot network issues.
• 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 light protocol exhibiting a behavior similar to a permanent connection. It has semantic familiarity with HTTP and is RESTful. If you have a web background, using CoAP is relatively easy.

MQTT

Message Queue Telemetry Transport (MQTT) is an open source protocol that was developed and optimized for constrained devices and low-bandwidth, high-latency, or unreliable networks. It is a publish/subscribe messaging transport that is extremely lightweight and ideal for connecting small devices to networks with minimal bandwidth. MQTT is bandwidth efficient, data agnostic, and has continuous session awareness, as it uses TCP. It is intended to minimize device resource requirements 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 backend 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 simple, offering few control options. Applications using MQTT are generally slow in the sense that the definition of “real time” in this case is typically measured in seconds.

MQTT vs. CoAP

MQTT publish/subscribe scales well, and the advantages of this architecture have been demonstrated. In the latest IETF requests for comment (RFCs), CoAP has introduced support for publish/subscribe.

CoAP’s light payload is well-suited for wireless sensor networks. MQTT for Sensor Networks (MQTT-SN) has taken that idea and reproduced it.

The two main dedicated IoT protocols are borrowing ideas from each other. Will these two protocols remain mainstream? We believe so, for at least five to 10 years.

Comparison of potential IoT protocols

Cisco is at the heart of the Internet; its IP equipment is everywhere. Cisco is actively participating in the evolution of IoT, and sees the potential of connecting physical objects, getting data from our environment, and processing this data to improve our standard of living (Table 2).

[Table 2 | Cisco’s work in IoT standards.]

The Internet-specific IoT protocols shown in Table 2 have been developed to meet the requirements of devices with small amounts of memory and networks with low bandwidth and high latency. Figure 2 provides another good summary of the performance benefit that these protocols bring to IoT.

[Figure 2 | Comparison of web and IoT protocols. Source: Zach Shelby, Micro:bit Foundation[1].]

Choosing the right IoT protocol

Connecting sensors and objects opens up an entirely new world of possible use cases – and it’s precisely those use cases that will determine when to use the right protocols for the right applications.

The high-level positioning of each of these protocols is similar. Apart from HTTP, all of the mentioned protocols are positioned as real-time publish/subscribe IoT protocols with support for millions of devices. Depending on how you define “real time” (seconds, milliseconds, or microseconds) and “things” (WSN node, multimedia device, personal wearable device, medical scanner, engine control, etc.) the protocol selection for your product is critical. Fundamentally, these protocols are very different.

Today, the Web runs on hundreds of protocols. The IoT will support hundreds more. What you need to do when designing your system is define the system requirements very precisely and chose the right protocol set to address them. The Internet protocol is a carrier; it can encapsulate just as many protocols for the IoT as it does today for the Web.

Many industry pundits are asking for protocol standardization But if there are so many protocols for the web, why wouldn’t there be just as many for the IoT? You choose the protocols that meet your requirements. The only difference is that the IoT protocols are still young and must demonstrate their reliability. Remember that when the Internet became a reality, IP version 4 (IPv4) was what made it possible. We are now massively deploying IPv6, and IoT is the killer application that telecommunication carriers have been waiting for to justify the investment required.

Christian Légaré is Vice President and Chief Technology Officer for Micrium, part of the Silicon Laboratories Portfolio

Micrium

www.micrium.com

@micrium

LinkedIn: www.linkedin.com/company/micrium-inc-

YouTube: www.youtube.com/micrium

Silicon Laboratories

www.silabs.com

@siliconlabs

LinkedIn: www.linkedin.com/company-beta/165971/

Facebook: www.facebook.com/siliconlabs

Google+: plus.google.com/117130120420400445098

YouTube: www.youtube.com/user/ViralSilabs

References:

1. Zdshelby Follow. “Standards Drive the Internet of Things.” LinkedIn SlideShare. May 22, 2013. Accessed April 11, 2017. https://www.slideshare.net/zdshelby/standards-drive-the-internet-of-things.