Designing for IoT—Part III—Internet Usage and Protocols
The previous two articles in this series (here, and here) described the hardware and software required to build an IoT device. These devices (the “Things” in the Internet of Things) are an essential part of an IoT system. There are two more building blocks to complete our system design.
The Internet
The Internet is the sum of all the 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 to exchange information, and in the last twenty years, we have developed and refined the Web so that ordinary, non-technical people can use the Internet easily and productively. The human interface for the Internet now includes e-mail, search engines, browsers, mobile apps, Facebook and Twitter, and other popular social media.
By comparison, in 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. 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 these new tools and services, and this is one of the reasons why a definition for IoT is difficult to lock down. Many visions about what it can, or could be, collide.
TCP/IP Protocol Stack
The TCP/IP protocol stack is at the heart of the Internet and the Web. It can be represented using the OSI seven-layer reference model, as illustrated in Figure 1. The top three layers are grouped together, which simplifies the model.
Figure 1 The TCP/IP reference model
The following is a quick description of the important layers from the perspective of embedded system integration:
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 so named because it provides connections between networks, between the physical layers. This is where we find the ubiquitous IP address.
Transport Layer
Above IP, we have TCP and UDP, the two transport protocols. Because TCP is used for most of our human interactions with the Web (e-mail, Web browsing, etc.), it is often believed that TCP should be the only protocol used at the transport layer. TCP provides the notion of a logical connection, acknowledgement of packets transmitted, retransmission of packets lost, flow control, all of which are great things. 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 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 and 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 acknowledgement 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 would garble the message.
TCP is sometimes preferred to UDP because it provides a persistent connection. So to do the same thing with UDP, you have to implement this feature yourself in a protocol layer above UDP.
When you are deciding how to move data from the Thing’s 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 MCUs now have an Ethernet controller on chip, which makes this an easier task.
next: The Protocols…
The IoT Protocols
It is certainly possible to build an IoT system with existing Web technologies, even if it is not as efficient as the newer protocols. HTTP(S) and Websockets are common standards, together with 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 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. After all, we don’t want to allow outside machines to have access to the local network where the IoT devices are installed.
WebSocket
WebSocket is a protocol that provides full-duplex communication over a single TCP connection over which messages can be sent 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: See XMPP
XMPP has its roots in instant messaging and presence information, and has expanded into voice and video calls, collaboration, lightweight middleware, content syndication, and generalised routing of XML data. It is a contender for mass scale management of consumer white goods such as washing machines, dryers, refrigerators, and so on.
XMPP strengths are its addressing, security, and scalability. This makes it ideal for consumer-oriented IoT applications.
HTTP, Websocket, and XMPP are just 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 with.
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 of the global standardisation bodies. Table 1 contains of short summary of the current activities.
Table 1 Constrained systems standardisation efforts
If your system does not require the features of TCP, and can function with the more limited UDP capabilities, removing the TCP module entirely helps a lot to reduce the size of the total code footprint of your product. This is what 6LoWPAN (for WSN) and 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 the majority of IoT applications. In July 2013, IETF released the Constrained Application Protocol (CoAP) for use with low-power and lossy (constrained) nodes and networks (LLNs). CoAP, like HTTP, is a RESTful protocol.
It is semantically aligned with HTTP and even has a one-to-one mapping to and from HTTP. Network devices are constrained by smaller microcontrollers with small quantities of flash memory and RAM, while the constraints on local networks such as 6LoWPAN are due to high packet error rates and a low throughput (tens of kilobits per second). CoAP can be a good protocol for devices operating on battery or energy harvesting.
next: CoAP features…
Features of CoAP: CoAP uses UDP
– Because CoAP uses UDP, some of the TCP functionalities are replicated directly in CoAP. For example, CoAP distinguishes between confirmable (requiring an acknowledgement) 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 the protocol overhead. However, this requires the use of a protocol analyser 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 needs for an extremely light protocol and with the nature of a permanent connection. It has semantic familiarity with HTTP and is RESTful (resources, resource identifiers and manipulating those resources via uniform Application Programming Interface (API)). If you have a Web background, using CoAP is relatively easy.
MQTT
MQ Telemetry Transport (MQTT) is an open source protocol that was developed and optimised 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 minimise 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 back-end server on the Internet. It is not designed for device-to-device transfer. It is also not 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.
Comparison of potential IoT protocols
Cisco is at the heart of the Internet; their IP equipment is everywhere. Cisco is now actively participating in the evolution of IoT. It sees the potential for connecting physical objects and getting data from our environment and to process this data to improve our living standards. Table 2 is drawn from Cisco’s work in IoT standards.
Table 2 Some of Cisco’s work on IoT standards, see Reference 1
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.
Figure 2 provides another good summary of the performance benefit that these protocols bring to IoT. The source is Zach Shelby in his presentation “Standards Drive the Internet of Things” (Reference 2).
Figure 2. Comparison of Web and IoT protocol stacks
Conclusion
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 for each of these protocols is similar. With the exception of HTTP, all these 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 to define the system requirements very precisely, and chose the right protocol set to address these requirements.
The Internet Protocol (IP) is a carrier; it can encapsulate just as many protocols for the IoT as it does today for the Web. A lot of industry pundits are asking for protocol standardisation. But if there is such a large number of 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 fairly young, and must demonstrate their reliability. Remember that, when the Internet became a reality, IP version 4 was what made it possible. We are now massively deploying IP version 6, and IoT is the killer application that telecommunication carriers have been waiting for to justify the investment required.
The final article in this series will look at the role of Cloud computing in the Internet of Things.
References
[1] Paul Duffy, April 30 2013, “Beyond MQTT: A Cisco View on IoT Protocols”, https://blogs.cisco.com/ioe/beyond-mqtt-a-cisco-view-on-iot-protocols/
[2]Zach Shelby, Chief Nerd, Sensinode, May 22 2013, “Standards Drive the Internet of Things”, https://www.slideshare.net/zdshelby/standards-drive-the-internet-of-things
About the author
Christian Legare is Executive Vice-President with Micrium, home of uC/OS-II, the real-time kernel.
Christian has a Master’s degree in Electrical Engineering from the University of Sherbrooke, Quebec, Canada. 22 years in the telecom industry, he has been involved in large scale organisations as well as start-ups, mainly in Engineering and R&D, and was in charge of an IP (Internet Protocol) certification program at the International Institute of Telecom (IIT) in Montreal, Canada as their IP systems expert.
If you enjoyed this article, you will like the following ones: don't miss them by subscribing to :
