As you may have guessed, IoT systems send data over the internet to communicate with Things and other connected devices. But what determines the rules and format for the type of data that gets sent? In the next segment of our eBook, we take a deep dive into the world of internet protocols.
Why Aren’t the Existing Internet Protocols “Good Enough?”
There are a few reasons the traditional internet design is not sufficient. For starters, it cannot accommodate the major power constraints of some IoT devices. The connection may not always be stable or may have limited memory. Finally, not all IoT applications require guaranteed data delivery, data protection, or message acknowledgment. These capabilities may be beneficial, but the data overhead and power cost may not be worth it.
MQTT and CoAP are the two most prominent IoT internet protocols
For example, take the overhead ratio of a standard TCP/IP datagram. (Overhead Ratio% = Overhead/Total Bytes). If considering an IP Datagram (over IPv6) of 1280 bytes. TCP overhead is 20 bytes. The overhead ratio would be 1.6% (20/1280). For CoAP, overhead is at least 4 bytes, resulting in an overhead ratio of 0.3% (4/1280). Not much of an improvement!
Now consider an IoT application. The data could include device temperature (4 bytes), GPS position (16 bytes), and time (10 bytes). Byte consumption amount totals 30 bytes, plus overhead. In this case, the TCP overhead ratio would be 40% (20/50) and the CoAP overhead ratio would be 11.8% (4/34). Use of this data format is almost 4 times more efficient, resulting in power savings. Of course, there are benefits of TCP such as sequencing and acknowledgment. However, the application may not need these capabilities or these challenges could be addressed higher up in the stack.
IoT-Friendly Internet Protocols
MQTT and CoAP. While there are other IoT friendly protocols in development and in use, these two are the most common. MQTT is an older standard. It was originally used in satellite applications but has evolved to handle today’s range of IoT applications. CoAP, on the other hand, is somewhat new and has been gaining traction. Both are lightweight protocols that meet the requirements of IoT devices and applications: low cost, limited memory, low power operation, scalable with end node addressability in unique applications, and security support.
MQTT Overview
IBM invented MQTT for use in satellite communications with oil field equipment. At its core, MQTT is reliable and requires little power. Thus, it makes sense to use 
this protocol in IoT networks. The MQTT standard is an open standard that has evolved to address a broader set of IoT applications.
MQTT uses a “publish/subscribe” message transport model. This model is lightweight and ideal for connecting small devices to constrained networks. A many-to-many protocol requires a central MQTT broker to receive, manage, and route messages among its nodes. The broker is also responsible for the authentication and authorization of clients. The MQTT “publish/subscribe” model scales well and can be power efficient. Brokers and nodes publish information, and others subscribe per the message content, type, or subject. Generally, the broker subscribes to all messages and then manages information flow to its nodes.
MQTT’s publish/subscribe model offers several specific benefits outlined below:
- Independent Operation
While a node and the broker need to have each other’s IP address, nodes function independently of one another. Without any knowledge of each other, nodes can publish information and subscribe to other nodes’ published information. Reason being: Everything goes through the broker.
- Time and Synchronization Independence
A node can publish its information independent of a target node being active or not. The target node then can receive the published information from the broker once active. This allows nodes to self-manage low power sleep states, while still supporting interoperation.
- Security Flexibility
MQTT uses Transmission Control Protocol (TCP) for its transport layer, enabling certain TCP security capabilities. The protocol can leverage TLS/SSL security for encrypting traffic, but this can be resource-intensive. Another option is to encrypt only the packet payload (data in transit). This is a better approach for networks that consider power management a higher priority than security.
- Varied levels of Guaranteed Delivery
MQTT offers three quality of service (QoS) levels. QoS is an important feature of MQTT because it guarantees message delivery, regardless of how unreliable the network is. The minimal level is QoS 0, often referred to as “fire and forget.” This level makes a single effort, or transmit burst, with no guarantee of message arrival. QoS 1 attempts to guarantee the message is received, at least once. Finally, the slowest and safest level is QoS 2. This level guarantees the message is received, only once, and is also decoded.
- Last Will and Testament (LWT)
MQTT also sends a “last will and testament (LWT)” message. The broker then stores the LWT message in the event a node unexpectedly disconnects from the network. If the node disappears, the broker notifies all subscribers of the node’s LWT. And if the node returns, the broker notifies it of its prior state. This a beneficial feature when on unreliable networks.
The MQTT protocol offers great benefits for IoT applications, but there are some negative trade offs to consider. These include:
- Need for a Central Broker
At the core of any publish/subscribe protocol is a central broker. This can be a drawback for some IoT applications. Being the central hub for every message, it is important for the broker to be scalable, open to integration, and failure-resistant. This can require overhead in the form of additional resources, software, and complexity that are not core to the end-node function. However, if the appropriate measures are not taken, the broker can make an entire network vulnerable.
- TCP Protocol Implications
As previously mentioned, MQTT uses TCP for its transport layer. This provides for a reliable, ordered, and error-checked solution. However, these benefits come with additional overhead which may or may not be a worthwhile.
Recently, a new version of MQTT was designed to address some of these challenges. MQTT for Sensor Networks (MQTT-SN) operates using the user datagram protocol (UDP) in place of TCP. This provides broker support for indexing topics (topic ID versus topic name). Because this protocol is still under definition, it is not well-supported.
CoAP Overview
With the growing importance of the IoT, the Internet Engineering Task Force (IETF) defined CoAP as one of the most accesible internet protocols for “use with constrained nodes and constrained networks.” Like MQTT, CoAP is commercially supported 
and growing rapidly among IoT providers.
CoAP is a client/server protocol and provides a one-to-one “request/report” interaction model. The IETF has specified CoAP from the outset to support IoT with lightweight messaging. CoAP is a RESTful protocol designed to be interoperable with HTTP and the RESTful Web through simple proxies, making it natively compatible to the Internet.
The CoAP approach offers several specific benefits outlined below:
- Use of the User Datagram Protocol (UDP) for Transport
CoAP runs over UDP, which uses a simpler approach to TCP with less overhead. It is inherently and intentionally less reliable than TCP. Instead of maintaining persistent connections, it depends upon repetitive messaging for reliability. UDP’s connectionless datagrams enable faster wake-up and transmit cycles, as well as smaller packets with less overhead. This allows IoT devices to remain in a sleep state for longer periods, thus conserving power.
- Possibility of Multicast Support
CoAP is inherently a one-to-one protocol. However, built on IPv6 addressing, it also supports one-to-many, or many-to-many multi-cast requirements.
- Security
CoAP uses Datagram Transport Layer Security (DTLS) on top of its UDP transport protocol. Like TCP, UDP is unencrypted, but can be augmented with DTLS where needed. CoAP leverages DTLS, but since DTLS works over datagrams, data can be lost, duplicated, or received in the wrong order. Therefore, some end-to-end aspects of securing the data are not available.
- Resource/Service Discovery
CoAP uses a Uniform Resource Identifier (URI) to share capability and interaction expectations with network nodes. This allows a degree of autonomy in the message packets, since the target node’s capabilities are partly understood by its URI details. A mapping between CoAP and HTTP is also defined. Enabling the build of proxies provides access to CoAP resources in a uniform way through HTTP.
- Asynchronous Communications
The CoAP protocol uses the request/report model to exchange messages asynchronously. CoAP has a simplified “observe” mechanism (like MQTT’s publisher/subscribe), that enables nodes to observe others without actively engaging them. [Note: CoAP does not have a broker requirement, therefore it cannot hold or queue messages for observers.]
- Web Friendly Protocol
CoAP has many similarities to HTTP. For users with a web development background, this may make developing with CoAP relatively easy.
Like MQTT, the benefits CoAP offers IoT applications also come with negative trade offs:
- CoAP Standard Maturity
Although CoAP is gaining market momentum, the protocol is less mature and less stable than MQTT. For now, designers should acknowledge that the standard is evolving, which could present interoperability challenges down the road.
- Message Reliability
CoAP uses a simple approach for “confirmable” messages and “non-con- firmable” messages. Like MQTT, the non-confirmable messages use a “fire and forget” approach. The confirmable message receives an acknowledgment message (ACK) from the intended recipient. This confirms the message got to where it needed to go, but it does not confirm the correct decoding of its contents.
- Dependence upon Application Layer
Unlike MQTT which uses TCP for its transport, CoAP uses UDP. This requires the protocol’s application layer to take on tasks usually handled by TCP. These include packet delivery, data ordering, caching, and retransmission. This increases your dependence on the application layer.
Read more about the IoT Technical Stack in “A Reference Guide to IoT” eBook.
Fill out our contact form if you have questions about IoT. We may not have all the answers but with our cross-disciplined IoT network, we certainly can get you the help you need.
About the Author: This is an excerpt from our eBook co-authored by Bridgera LLC and RIoT.
Bridgera LLC is a Raleigh, NC based software company specializing in IoT software solutions with Bridgera IoT, not just another IoT Platform but Custom Software-as-a-Service for the Internet of Things.
RIoT is a registered trademark of the Wireless Research Center of North Carolina. RIoT represents a network of technologists, engineers, business leaders, academics, policy makers, and entrepreneurs, all of whom have a stake in the Internet of Things industry.
