IP versus CoAP for IoT communications

But, as these numbers grow, how do you get these disparate systems to standardise and seamlessly work together, when the two key challenges related to IoT (the need to run low‑powered networks for years without recharging and frequent data exchanges over lossy networks) means the use of the standard internet protocols (HTTP) is, as Mindtree Research have succinctly put it, “less than ideal and suboptimal”.

In short, IoT is not the web. The web requires an information source to have a definitive origin, with web servers passing the information to the browser. The IoT, however, connects devices to software and services and the end device is (instead of a browser) the sensor or actuator, meaning the traditional web mapping of clients and servers is inverted.

CoAP

The Internet Engineering Task Force (IETF) Constrained RESTful Environments (CoRE) working group is responsible for standardisation work and for defining a REST‑based web transfer protocol for these battery‑power- and processing‑power‑limited IoT/M2M applications. The result is the Constrained Application Protocol (CoAP) - you can see the RFC7252 protocol specification here.

The CoAP protocol is very similar to HTTP and includes several HTTP functionalities, but has been redesigned (and not simply compressed) to account for these devices’ constraints; with the application layer protocol running on top of the UDP/IP transport layer, with the 6LoWPAN network layer and the 802.15.4e link layer. The result is a protocol that uses far‑smaller packets, with a greater simplicity and a smaller footprint. But, importantly, the protocol has also been designed to easily translate to HTTP for simplified integration with the web.

Interchanges over CoAP

Like HTTP, CoAP supports content negotiation with Accept option giving the preferred use of a resource, and the servers responding with a Content‑Type option informing the client. And like HTTP, both client and server are therefore able to evolve separately, without affecting the other.

Unlike HTTP, CoAP deals with these interchanges asynchronously over the UDP transport layer and this is done logically using a layer of messages that supports optional reliability (with exponential back‑off).

The protocol balances QoS and resources by implementing two forms of message requests: “confirmable” and “non‑confirmable”. Confirmable messages must be acknowledged by the receiver with an ack (acknowledgement) packet, whereas non‑confirmable messages are classed simply as “fire and forget”.

In terms of security, while CoAP cannot use SSL/TLS provide security (as this requires the TCP transport layer), the DTLS, Datagram Transport Layer Security standard, which runs over UDP can be used, and this provides the same assurances as TLS. DTLS capable CoAP devices will typically support ECC and AES or RSA and AES.

CoAP adoption

There are already open source libraries and implementations available for CoAP, as well as operating systems and application frameworks - for example, mbed, which is provided by ARM and backed by a large ecosystem of vendors, including u‑blox. Adoption is well underway, notably through the Open Mobile Alliance (OMA) LightWeight M2M (LWM2M) profile, which specifies a set of common interfaces and data models with plug and play interoperability between local or remote services and the the CoAP devices. This provides the necessary device management functions like Over‑The‑Air (OTA) firmware upgrades.

On top of LWM2M, OneM2M (another IoT/M2M standards covering device management and data exchanges between field deployed devices and applications running on the servers in the cloud) has announced provision for the use of CoAP alongside HTTP and the MQTT protocol.

Finally, some cellular network operators have already expressed interest in using LWM2M for applications such as smart metering.

Next steps

CoAP is helping to minimise the cost of cloud–device connections, enabling IoT devices to cost effectively and securely send data over large distances while consuming very little power.

The IETF is currently looking to define additional features such as publish and subscribe facility similar to MQTT, improved security and use of CoAP over TCP as well as UDP that is currently defined.

Advances from industry are also ongoing, with companies complementing the work of the standards groups by opening up their data to the wider development community. Obviously, one of the big challenges is getting this data into a standard, normalised format and there is a need to convert them to common formats, but this is also on track.

And work is already underway to create broadly applicable rules engines and realisation tools.

By Tony Milbourn, Vice President, Corporate Strategy, u-blox.

Courtesy of u-blox.