Startertutorials Blog
Tutorials and articles related to programming, computer science, technology and others.
Subscribe to Startertutorials.com's YouTube channel for different tutorial and lecture videos.

Categories: Internet of Things. No Comments on Constrained Application Protocol

In this article we will look at Constrained Application Protocol (CoAP), which is one of the widely used protocols in IoT.

 

Introduction

CoAP stands for Constrained Application Protocol, and it is defined in RFC 7252. CoAP is a simple protocol with low overhead specifically designed for constrained devices (such as microcontrollers) and constrained networks. This protocol is used in M2M data exchange and is very similar to HTTP. The main features of CoAP protocols are:

  • Web protocol used in M2M with constrained requirements
  • Asynchronous message exchange
  • Low overhead and very simple to parse
  • URI and content-type support
  • Proxy and caching capabilities

 

CoAP Architecture

The architecture of CoAP is as shown below.

 

Constrained Application Protocol Architecture

 

There are two different layers that make CoAP protocol: Messages and Request/Response. The Messages layer deals with UDP and with asynchronous messages. The Request/Response layer manages request/response interaction based on request/response messages. CoAP supports four different message types:

  • Confirmable
  • Non-confirmable
  • Acknowledgment
  • Reset

 

Messages Layer

This is the lowest layer of CoAP. This layer deals with UDP exchanging messages between endpoints. Each CoAP message has a unique ID; this is useful to detect message duplicates. A CoAP message is built by these parts:

  • A binary header
  • Compact options
  • Payload

 

As said before, the CoAP protocol uses two kinds of messages: 1) Confirmable message, 2) Non-confirmable message. A confirmable message is a reliable message. Using this kind of message, the client can be sure that the message will arrive at the server. A Confirmable message is sent again and again until the other party sends an acknowledge message (ACK) as shown below. The ACK message contains the same ID of the confirmable message

 

CoAP Communication 1

 

If the server has troubles managing the incoming request, it can send back a Rest message (RST) instead of the Acknowledge message (ACK) as shown below.

 

CoAP Communication 2

 

The other message category is the Non-confirmable (NON) messages. These are messages that don’t require an Acknowledge by the server. They are unreliable messages or in other words messages that do not contain critical information that must be delivered to the server. To this category belongs messages that contain values read from sensors. Even if these messages are unreliable, they have a unique ID as shown below.

 

CoAP Communication 3

 

Request-Response Layer

The CoAP Request/Response is the second layer in the CoAP abstraction layer. The request is sent using a Confirmable (CON) or Non-Confirmable (NON) message. There are several scenarios depending on if the server can answer immediately to the client request or the answer if not available. If the server can answer immediately to the client request, then if the request is carried using a Confirmable message (CON), the server sends back to the client an Acknowledge message containing the response or the error code as shown below.

 

CoAP Communication 4

 

As you can notice in the CoAP message, there is a Token. The Token is different from the Message-ID and it is used to match the request and the response. If the server can’t answer to the request coming from the client immediately, then it sends an Acknowledge message with an empty response. As soon as the response is available, then the server sends a new Confirmable message to the client containing the response. At this point, the client sends back an Acknowledge message as shown below. If the request coming from the client is carried using a NON-confirmable message, then the server answers using a NON-confirmable message.

 

CoAP Communication 5

 

CoAP Security

As stated before, CoAP uses UDP to transport information. CoAP relies on UDP security aspects to protect the information. As HTTP uses TLS over TCP, CoAP uses Datagram TLS over UDP. DTLS supports RSA, AES, and so on. Anyway, we should consider that in some constrained devices some of DTLS cipher suits may not be available.

 

CoAP and MQTT

Similarities between MQTT and CoAP are:

  • Are open standards
  • Are better suited to constrained environments than HTTP
  • Provide mechanisms for asynchronous communication
  • Run on IP
  • Have a range of implementations

 

Differences between MQTT and CoAP are:

Differences between coap and mqtt

 

How useful was this post?

Click on a star to rate it!

We are sorry that this post was not useful for you!

Let us improve this post!

Tell us how we can improve this post?

Suryateja Pericherla

Suryateja Pericherla, at present is a Research Scholar (full-time Ph.D.) in the Dept. of Computer Science & Systems Engineering at Andhra University, Visakhapatnam. Previously worked as an Associate Professor in the Dept. of CSE at Vishnu Institute of Technology, India.

He has 11+ years of teaching experience and is an individual researcher whose research interests are Cloud Computing, Internet of Things, Computer Security, Network Security and Blockchain.

He is a member of professional societies like IEEE, ACM, CSI and ISCA. He published several research papers which are indexed by SCIE, WoS, Scopus, Springer and others.

Leave a Reply

Your email address will not be published. Required fields are marked *