Protocols for the Internet of Things

Currently, adapting the Internet for the IoT is one of the main priorities for many of the global standardization bodies. 

If your system does not require the features of TCP, and can function with the more limited UDP capabilities, removing the TCP module entirely, greatly helps 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.

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

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

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

• HTTP can be a heavy protocol for an IoT device. It has large messages because they are sent in human-readable format. For IoT devices, payload size is often a constraint. For a large family of devices, reporting and accepting commands can be done more efficiently with a much lighter protocol. MQTT has been proposed as the answer to these problems. MQTT is not an IETF standard, and is driven by IBM and the Eclipse foundation.

  Conclusion

  In the term “Internet of Things” there is Internet. Some may offer devices coined as IoT devices without the use of the Internet Protocol. We should expect this. Today, IoT is such a strong term (some may say hype) that every manufacturer wants to take advantage of the enormous IoT media coverage.

  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 calling for protocol standardization. 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 have yet to 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 positioning for each of the IoT protocols requires a similar questioning. 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 all very different.

  Beyond hardware and software design, however, is the design of IoT data systems. We need to separate the data from the application so that we can do new things with it, things we have not yet imagined. For the typical embedded system developer, thinking specifically about the data the system generates requires a new frame of mind. There is a value in this data. In embedded system design, we understand very well how to architect the Thing, the local network and even the gateway. The processor, sensor, wireless connectivity, gateway, IP network and security are all elements that are well-known to the embedded developer.

  The new challenge for the embedded community is to take advantage of the value inherent in our data by leveraging some type of cloud computing. In order to monetize the embedded system’s data, some type of cloud computing is absolutely required, be it private, outsourced or public. This is a new paradigm for the embedded community.

  Embedded systems hardware technology, software technology, infrastructure, and cloud computing are actively being tested and deployed, fostering the emerging Internet of Things. To be really successful, and realize the 50 billion devices that will be deployed by 2020, we require the same open standards, development and cooperation that supported the creation of the Internet of People (also known as the Web). The IPSO Alliance is promoting the IP standards and uses it to build the reference architectures product developers are looking for.

  IoT for embedded systems is the new industrial revolution. The growth potential for the embedded industry is enormous. To realize this potential, the embedded industry needs to adopt the new IoT paradigm. We now understand what needs to be done. We may not yet have well-defined and established standards for each structural element of future IoT systems like ease of configuration or secure remote firmware upgrade. But this should not stop anyone from building a system that will provide value to their customers.