This blog will explain about the IoT messaging protocol CoAP in different aspects, as a continuation of my previous blogs on MQTT and MQTT-SN.


Constrained Application Protocol (CoAP) is a lightweight client-server messaging protocol. It is a REST based web transfer protocol and provides a request-response interaction model between application endpoints. CoAP is a subset of REST common with HTTP, but specially designed to suit constrained devices and constrained networks (6LoWPANs). CoAP also includes in-built mechanisms to discover services and resources. CoAP works on top of UDP. It can also work over transports such as SMS, TCP or SCTP, which is not discussed in detail by CoAP specification. CoAP specification explains different aspects of CoAP considering UDP as the transport protocol.

Operational behaviour

Message flow in a CoAP based solutions is as follows,

  • CoAP clients registers resources with a pre-known CoAP server. CoAP clients can also choose to use multicast service discovery to find servers dynamically, which is most suited to solutions running on a local network. CoAP multicast is not explained well in CoAP specification, but a separate experimental document explains this and it is available here.
  • CoAP clients can find the resources available in a server using resource discovery feature.
  • Smart devices and controllers can both act as CoAP clients and perform required operations by invoking REST based CoAP methods (such as GET, PUT and POST etc) on interested resources.
  • CoAP clients can listen for the changes in an interested resource by using OBSERVE feature of CoAP. This is not well explained in CoAP specification, but a separate proposed standard document explains this and it is available here.
  • CoAP solutions can use proxies and caches for limiting network traffic, improving performance and several other reasons.

Following figure illustrates CoAP’s entities in an example of home automation,

Figure 1 : CoAP entities
Please refer “Credits” section to know credits for image resources used.

In the above example,

  • A smart thermostat in a connected home acts as a CoAP client, registers a thermostat status resource and control resource to a pre-known CoAP server using PUT or POST CoAP methods. It also listens to control messages by observing the changes to control resources using GET method with OBSERVE feature.
  • An application (controller) running in a smart phone acts as a CoAP client, listens to the thermostat status resource using GET method with OBSERVE turned on and posts control resources using POST.
  • CoAP server runs in cloud and performs the actions requested by the thermostat and controller. CoAP server notifies the thermostat when a control resource is updated by controller and notifies the controller when the temperature status resource is updated by thermostat.


CoAP is defined by IETF Constrained RESTful Environments (CoRE) working group to run resource oriented applications on constrained devices and networks. It is not an internet standard yet. It is still a “Proposed standard”, which is an entry-level maturity for the standards track and more information can be found here. UDP port 5683 is registered with IANA for CoAP and UDP port 5684 is registered for DTLS-secured CoAP.

Message format

CoAP defines four methods for the communication between clients and servers such as GET, PUT, POST and DELETE.

Every CoAP message has a fixed header of 4 bytes. It is followed by variable sized (0 to 8 bytes long) token, variable sized options and optional payload. Smallest CoAP message can be of 4 bytes.

As it works on top of UDP, CoAP solutions should carefully pickup message sizes to avoid fragmentation and packet loss. It is recommended to frame a CoAP message  in such a way that it fits a single IP datagram. If nothing about MTU size and header size is known, suggested good upper bounds for message size and payload size are 1152 and 1024 bytes respectively.

Message delivery

CoAP offers two types of message deliveries as stated below,

  • Confirmable messages
    Senders will receive acknowledgements from receivers. Senders will retransmit a message on timing out without an acknowledgement.
  • Non-confirmable messages
    It is a fire and forget message. Senders will not receive any acknowledgements from receivers.

CoAP does not offer “exactly once” QoS (Quality of Service), which is supported in MQTT and MQTT-SN.

Real world implementations

ARM’s mbed client, InterDigital’s oneMPOWER and IOT cloud platform are the known commercial implementations of CoAP listed here. But popular IoT platforms such as Microsoft’s Azure IoT, Amazon’s AWS IoT and IBM’s Watson IoT platforms does not support communication over CoAP.


CoAP defines transport layer security using DTLS. CoAP specifications defines different security modes using DTLS. In addition to transport layer security, CoAP applications can also add security and authentication mechanisms at application level.

Where CoAP fits in IoT ecosystem ?

As CoAP is defined to be a REST based messaging protocol for nodes (constrained devices) in a constrained network, it will be a best fit in IoT solutions which requires a request-response based communication model between battery operated devices, gateways and servers. In generic, CoAP can be used as a messaging protocol in the following cases,

  • Device to Cloud server  and vice versa – In a use case where a smart device should directly communicate with a cloud server, CoAP can be used as a messaging protocol.
  • Gateway to devices and vice versa in a local network – In an ecosystem, where multiple battery operated devices are connected to a IoT gateway in a local network, CoAP can be used for messaging between IoT gateway and battery operated devices.
  • Gateway to Cloud server  and vice versa – In an ecosystem, where multiple battery operated devices are connected to a IoT gateway in a local network, CoAP can be used for messaging between IoT gateway and Cloud server.


  • Easy to integrate with web as it is REST based, subset of HTTP and CoAP methods are easily mappable to HTTP methods.
  • Supports dynamic service discovery using multicast and resource discovery.
  • Supports proxying and caching, which helps in limiting network traffic and improving performance. Cross-protocol proxies can be used to integrate CoAP solutions with HTTP solutions.
  • Supports listening to CoAP resources using OBSERVE option.
  • Supports block-wise transfers. More detail on this can be found here.
  • Open source implementations are available for CoAP and they are listed here.


  • Not supported by popular IoT platforms such as Amazon’s AWS IoT, IBM’s Watson IoT and Microsoft’s Azure IoT platforms.
  • Not an official internet standard yet. It’s still in “Proposed Standard” state, which is an entry level maturity in standards track.
  • CoAP over UDP is not a best fit for IoT solutions which requires ordered delivery of  messages. If CoAP over UDP is used in such cases, explicit mechanisms and message contracts should be defined to maintain the ordered delivery of messages.
  • In CoAP over UDP, CoAP message size should be relatively small to avoid IP fragmentation and packet loss issues.
  • No security mechanism defined at the messaging protocol level.

Follow-up links

Entire content of this series of blogs is available here.


  • RFC 7252, CoAP, IETF proposed standard, Z. Shelby, ARM, K. Hartke, C. Bormann, Universitaet Bremen TZI, Jun 2014.
  • RFC 7390, Group communication for  CoAP, Experimental draft, A. Rahman, Ed., InterDigital Communications, LLC, E. Dijk, Ed., Philips Research, Oct 2014.
  • Blockwise transfers in CoAP draft, IETF draft, C. Bormann, Universitaet Bremen TZI, Z. Shelby, Ed., ARM, March 09, 2015.
  • RFC 7641, Observing resources in CoAP, IETF proposed standard, K. Hartke, Universitaet Bremen TZI, September 2015.
  • Constrained RESTful environments (CoRE), IETF working group.
  • CoAP open source and commercial  implementations.


Resources used in “Figure 1” are downloaded from web as follows,