Constrained Application Protocol (CoAP) CoAP is an Internet application protocol specified in RFC 7252. The protocol is used for communication of devices ’nodes’, e.g. embedded devices, that consume very little energy (low-power) and operate in networks with increased data loss (lossy networks), for instance IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs). CoAP can also be used within Internet-based networks for mobile communication via SMS. CoAP is primarily used in the context of the Internet of Things (IoT) and Machine-to-Machine (M2M), as device data/sensor data of small size is usually transmitted. Since this type of data is transmitted at regular intervals (cycles), individual (lost) data packets have no significant impact on the processing systems or applications, such as an IoT platform that processes and/or graphically displays the corresponding sensor data (temperature, rotation speed, etc.).

The working group ‘strained RESTful Environments’, abbreviated ‘CoRE’, is planning, among other things, the use of the REST architecture within embedded devices (nodes). Nodes primarily use an 8-bit microcontroller and provide little RAM and ROM storage.

Protocol objectives

  • Creation of a generic protocol so that it can be used in IoT applications, e.g. home automation or in M2M applications
  • Simplification/downsizing of the protocol, which will lead to a reduction of fragmentation
  • built-in discovery
  • multicast support
  • asynchronous message exchanges

Protocol Features

  • Fulfilling M2M requirements within constrained networks
  • [ENG] UDP binding with optional reliability supporting unicast and multicast requests
  • Asynchronous message exchanges
  • Simple header, thereby reducing parsing complexity
  • Support for Uniform Resource Identifier (URI) & content types
  • Proxy and caching support
  • [ENG] A stateless HTTP mapping, allowing proxies to be built providing access to CoAP resources via HTTP in a uniform way or for HTTP simple interfaces to be realized alternatively over CoAP.
  • Datagram Transport Layer Security (DTLS) binding

The CoAP interaction model corresponds to the client/server model from HTTP, i.e. a ‘client’ sends a request to a server and requests a URI. The server then delivers the requested resource. Unlike HTTP, the communication takes place over UDP.

CoAP distinguishes four different types of messages

  1. Confirmable
  2. Non-confirmable
  3. Acknowledgement
  4. Reset

Since CoAP uses the UDP protocol, duplicates or data losses are generally possible. For this reason, the following two mechanisms have been implemented within CoAP:

  • [ENG] Simple stop-and-wait retransmission reliability with exponential back-off for Confirmable messages.
  • Duplicate detection for Confirmable and Non-confirmable messages

CoAP message format

  • Ver (Version): CoAP version number
  • T (Type): Indicates the message type (0-3): Confirmable (0), Non-confirmable (1), Acknowledgement (2), or Reset (3)
  • TKL (Token Length): Indicates the variable length of the token.
  • Code: request (0), success response (2), client error response (4), server error response (5)
  • Message ID: Used for duplicate detection or for message matching
  • Options: Here option numbers can be specified, e.g. Max-Age with number 14 or Proxy-Uri (35). The complete list of option numbers can be found in the specification.
  • Payload

Packet Size The max. packet size for the CoAP header is 1152 bytes and 1024 bytes for the payload. A CoAP packet should not exceed the maximum size, as larger packets can lead to unwanted fragmentation. To avoid IP fragmentation, packet transmission should be done via IPv6. If IPv4 is used, the packet size must be accordingly reduced. The specification offers further details.

Transmission & transmission parameters Transmission takes place similar to HTTP using the request/response semantics, whereas in contrast to HTTP no transmission occurs over an existing or previous connection. CoAP supports the following basic methods, which are already known from HTTPS:

  • GET e.g. GET /status/power
  • POST
  • PUT
  • DELETE

The methods GET, PUT and DELETE are idempotent. POST is NOT idempotent. Responses are based on the request code within the header. The following three response codes are distinguished:

  • Success
  • Client Error
  • Server Error

The protocol provides the following transmission parameters, which the user can configure according to their environment. When modifying the configuration, it should be noted that, for example, reducing ‘ACK_TIMEOUT’ to one second violates the ‘Unicast UDP Usage Guidelines for Application Designers’. Further changes can violate other guidelines. Additionally, changes to the above parameters in certain combinations or configurations have further effects on transmission. For ensuring secure communication, ‘Datagram Transport Layer Security (DTSL)’ is used.

Security CoAP distinguishes the following four security levels (modes):

  1. NoSec
  2. PreSharedKey - symmetric encryption
  3. RawPublicKey - asymmetric encryption
  4. Certificate - asymmetric encryption via X.509 certificate

CoAP URI In CoAP, similar to HTTP, a distinction is made between http (coap) and https (coaps). The CoAP schema is as follows:

  • coap-URI = “coap:” “//” host [ “:” port ] path-abempty [ “?” query ]
  • coaps-URI = “coaps:” “//” host [ “:” port ] path-abempty [ “?” query ]

Service Discovery Service discovery refers to the automatic detection of services in a computer network. Communication protocols are used here to describe how services are found to allow communication with each other. Basically, one distinguishes between two groups of service discovery protocols (SDPs):

  1. Services register with a central service (a registry) and can be found through it.
  2. Services broadcast to the entire network for a specific service, and the requested service or a registry responds. [wikipedia]

After hosting a server by a 6LoWPAN node, the server can be reached over port 5683 and 5684 when using DTSL. Resource discovery is done via a CoAP endpoint. Therefore, an endpoint should support the CoRE link format. The format is described in [RFC6690]. For communication with a server, the CoAP agent Copper (Cu) can be used. https://addons.mozilla.org/en-US/firefox/addon/copper-270430/

[Specification: https://tools.ietf.org/html/rfc7252#section-12.2]

LwM2M Client & Servers Anyone wanting to create their own server or client can use the OMA Lightweight M2M server and client implementation from LESHAN in Java.

Below are a few links to the LESHAN project: https://github.com/eclipse/leshan/blob/master/README.md https://github.com/eclipse/leshan/wiki/Getting-started