To compensate for resource-inhibited and low-power devices, developers can choose Constrained Application Protocol (CoAP) as their IoT protocol to more efficiently communicate between two peers.
Not all connected devices are made equal. While some are more powerful and technologically advanced, others are simple sensors and home automation devices with limited energy, memory, computational power and bandwidth. To compensate for such resource-inhibited and low-power devices, developers can choose Constrained Application Protocol (CoAP) as their IoT protocol to more efficiently communicate between two peers.
This lightweight RESTful protocol is specially optimized for deployments with a high number of end devices within the network. CoAP is able to create and manage resources on devices, publish and subscribe data, manage multicast of data, provide device description when requested, and give mechanisms to tell if a device is powered or not — all while conserving energy and simplifying communication between client and device. Better yet, the infrastructural similarities between CoAP and HTTP REST enable designers to leverage their understanding of RESTful patterns into their IoT solutions.
Let’s explore the what and the why of this unique request/response communication type.
CoAP at a glance
Just like HTTP is used to transport data and commands between a client and a server, CoAP allows the same command transmission features but without needing the same amount of resources, making it ideal for today’s internet of things (IoT) devices.
Designed by the Internet Engineering Task Force (IETF), the service layer protocol enables simple devices to join the IoT even through constrained networks with low bandwidth.
From a developer perspective, CoAP feels very much like HTTP. Obtaining a value from a sensor is not much different from obtaining a value from a Web API. The similarity between the two protocols greatly simplifies development as device developers can use well-known patterns from traditional client/server HTTP REST services in their infrastructure. Further, since HTTP and CoAP share the REST model, they can easily be connected using application-agnostic cross-protocol proxies. This is a major advantage when it comes to CoAP vs MQTT, for example, as the latter is not RESTful based.
Faster communication, better batteries
CoAP is designed to meet specialized requirements such as multicast support, low overhead, and simplicity, three important elements for IoT devices which are deeply embedded and have much less memory and power supply than traditional internet devices. Efficiency, therefore, is integral, and exactly what CoAP delivers.
Due to its low overhead and simplicity, for example, CoAP offers reduced power requirements. The protocol operates, for instance, over UDP and BLE which require minimal overhead for communications and allow faster wake up times and extended sleepy states. Taken together, this means batteries last longer. Moreover, the smaller packet sizes offered made possible by UDP and BLE lead to faster communication cycles, again allowing batteries to last longer.
In practice, faster communication cycles and longer-lasting batteries are excellent benefits when it comes to controlling smart home devices. CoAP allows direct interaction with, for example, a smart lock, alarm, or heating system, like it would be when exposed in a traditional HTTP REST service. Likewise, industrial device users benefit from the ability to send control commands, query registers, and change configurations.
A note on remote access
At the same time, however, device designers must be aware of the limitations of CoAP.
CoAP itself does not deliver remote access, so users will not be able to reach their device if the connection is behind a firewall. Thus, since there is no secure transport in CoAP per the standard, users will need to bring their own.
The answer here could be HTTPS, TLS, DTLS, or a third-party platform. But, whatever the choice, it is integral that device users and designers acknowledge this limitation and prepare accordingly. Also, do not ignore access control in this equation. Users must be very sure of who they are letting in when traversing any firewall, therefore it is incumbent upon the user to ensure the data transfer is between the correct client and device. Alternatively, they can select a third-party remote access platform with built-in secure transport and access control.
It’s all about the nodes
As sensor numbers grow month by month, it is clear that connecting IoT’s billions of nodes will need to be simultaneously inexpensive and efficient. Achieving this is one of the most exciting elements of CoAP as the protocol has been designed to work on microcontrollers with as low as 10 kibibyte (KiB) of RAM and 100 KiB of code space.
In its essence, CoAP takes the best elements of HTTP REST and downsizes them. REST is primarily run over HTTP and commonly used in Web APIs. Applications based on the REST architecture conform to several guiding principles and constraints, with the resulting protocol performing well and being highly scalable, simple, and easy to modify and extend. Since CoAP is REST-based but with a focus on keeping the size of the protocol down, it is the perfect solution for small devices and designers who are familiar with the RESTful pattern.
Again, it is integral that device and network designers consider access and security, with the implementation of third-party platforms which enable peer-to-peer (P2P) remote connections likely their best bet. Overall, CoAP is helping to minimize the cost of cloud–device connections by enabling IoT devices to cost-effectively and securely send data over large distances while consuming very little power. For designers, meanwhile, the similarity to HTTP REST makes any device transition to CoAP all the more tempting in 2021.
Carsten Rhod Gregersen is CEO and founder of Nabto, a P2P IoT connectivity provider that enables remote control of devices with secure end-to-end encryption.