Constrained Application Protocol : IOT Part 32

IoT devices have very limited resources like they have embedded processors or controllers, limited RAM and ROM and they need to operate on battery without replacement for weeks, months or even years. Even they have to communicate data swiftly though small in amount but on limited network bandwidth. Bringing the web to constrained devices that lack the capabilities of computer and smart phones require special sort of IoT protocol. The Constraint Application Protocol (CoAP) is one of such protocols designed to fit this requirement.

Constrained Application Protocol (aka CoAP) is a specialized web transfer protocol for use with constrained nodes (low power sensors and actuators) and constrained networks (low power, lossy network). It enables those nodes to be able to talk with other constrained nodes over Internet. The protocol is specifically designed for M2M applications such as smart energy, home automation and many Industrial applications.

Fig. 1: Overview of CoAP Protocol for Constraint Devices

CoAP protocol is necessary because traditional protocols such as TCP/IP are considered “too heavy” for IoT applications that involves constrained devices. CoAP protocol runs on devices that support UDP protocol. In UDP protocol, client and server communicate through connectionless datagrams.

Fig. 2: Image showing CoAP Protocol Stack

As it is a web transfer protocol, it is based on RESTful architecture which provides a request/response interaction model between application endpoints and supports built-in discovery of services and resources. Like HTTP, Servers make resources under URL and clients access those resources using methods such as GET, PUT, POST and DELETE.

The CoAP protocol has the following features –

1) It provides M2M communication in constrained environment.

2) It provides security of data by datagram transportation layer security (DTLS).

3) Asynchronous message exchange.

4) Low header overhead and parsing complexity

5) URI and content type support

6) UDP binding with optional reliability supporting unicast and multicast requests.

The CoAP is different from other protocols. When compared with HTTP, CoAP is implemented for IoT and M2M environment to send messages over UDP protocol. To compensate for the unreliability of UDP protocol, CoAP defines a retransmission mechanism and provides resource discovery mechanism with resource description.

The MQTT and CoAP, both are designed to consider the long term vision that they need to be used in lightweight environments. Both works well with low power and network constrained devices. So the choice really depends on the application. If a M2M network has to be created where messages must publish from one node to multiple interested nodes, the best choice will be to use MQTT protocol. But if a M2M network has to be created where commands must be sent to among nodes, CoAP will be the best choice for that. For example to control an AC from the smart phone, CoAP would be the smarter choice.

CoAP should be on priority for the following three factors –

• Quality of service with confirmable message

• When multicast support is needed

• Very low overhead and simplicity.

RESTful Architecture –

CoAP follows a client-server communication model. Client makes request to the server and the server sends back the responses to the client. Client can GET, PUT, POST or DELETE the resources on network. CoAP improves the HTTP request model with the ability to observe a resource. In HTTP, the server needs to do polling again and again to check where there is any state changes to the client or not. Whereas in CoAP, the observe flag is set on the CoAP GET request, the server continues to reply after the initial document has been transferred. This allows servers to stream the state changes to clients as they occur. Any end can stop the observation.

The CoAP defines a standard mechanism for resource discovery. Servers provide a list of their resources, along with metadata about them, at /.well-known/core. For Quality of Service (QoS), Requests and response messages may be marked as confirmable or non-confirmable. Confirmable messages must be acknowledged by the receiver. Non-confirmable messages are “fire and forget” type.

CoAP Protocol Security –

The main concern from security point of view is to provide Data Integrity, Data Authentication and Data Confidentiality. The CoAP provides security over Datagram Transportation Layer Security in Application layer. As CoAP runs over UDP protocol stack, there are chances of data loss or data disordering. But with DTLS security, these two problems can be solved. DTLS security adds three implementations to CoAP –

1) Packet retransmission

2) Assigning sequence number within handshake

3) Replay detection

The security is designed to prevent eavesdropping, tampering or data forgery at any cost. Unlike network layer security protocols, DTLS in application layer protect end-to-end communication. DTLS also avoids cryptographic overhead problems that occur in lower layer security protocols.

Fig. 3: Image showing CoAP Protocol at Application Layer in Network Architecture

There is a Secured Handshake Mechanism in DTLS as shown in image below –

Fig. 4: Image showing DTLS Secured Handshake Mechanism for CoAP

The CoAP can also be implemented over TCP and over TLS. Check out the following official documentation for CoAP implementation over TCP and TLS.

TCP and TLS Transport for the Constrained Application Protocol (CoAP)

In the next tutorial – Client Server Communication over CoAP Protocol, an ESP8266 module is configured as server and a Browser on a laptop is configured as Client. The CoAP Client sends some data to the server and the server acknowledges it by switching an LED on.