In this article, the new Constrained Access Protocol (CoAP) will be introduced and analysed for its fitness for purpose in constrained environments such as wireless sensor nodes. Iain Learmonth a member of the Electronics Research Group at the University of Aberdeen explains the CoAP protocol, for providing representational state transfer (REST) and how wireless sensor node may use these services to send sensor observation data to a data logger or to request configuration updates from a server.
Iain Learmonth
CoAP is a software protocol intended to be used in very simple electronics devices that allows them to communicate interactively over the Internet. It is particularly targeted for small low power sensors, switches, valves and similar components that need to be controlled or supervised remotely, through standard Internet networks.
The first problem it attempts to tackle is removing the overhead and complexity of TCP by operating entirely over UDP and implementing an optional acknowledgements system. This allows for messages to be transmitted with only best-effort and in cases of network congestion, a sensor reading will be lost instead of adding retransmission attempts into the already congested network. For most sensor network applications not related to security, eventual success is good enough.
The second advantage to CoAP over HTTP is the smaller amount of data to be transmitted. TCP requires a three-way handshake before any communication can even begin however this is not necessary with CoAP as data can be sent on the first packet.
In these wireless sensing applications, the client may not require a reply and so does not need to store any state about the connections and can simply discard incoming packets.
The amount of data to be transmitted is further reduced by using a binary header as opposed to the ASCII header used by HTTP. Far more information can be transmitted with the radio being powered for a shorter time frame.
The third advantage to CoAP over HTTP is that it can be used with multicast which would allow sensor nodes to send their updates to a multicast group as opposed to a single server. This can be used for a server to simply listen to a multicast group and auto-discover not require the clients to have prior knowledge of the server.
From the previous analysis of HTTP minimum packet sizes as HTTP has evolved in the first half of this post, it is clear that it is becoming less and less suitable for use in the constrained environments that are found in wireless sensor nodes. It was possible to implement an older version of the protocol in order to submit the observations with smaller payloads on the network packets but this is not a long-term solution as it is likely that at some point, support for the older version of the protocol would be removed from HTTP servers. By using a protocol that is no longer being supported would introduce the same problems as the use of proprietary standards: lack of available libraries, lack of documentation and support and lack of interoperability.
CoAP is still in active development by the CoRE working group of the IETF in the Applications Area although there have only been slight changes between the last two drafts. CoAP is designed to emulate the REST features of HTTP but in a way that is more constrained environment friendly.
The problem that exists with both HTTP and CoAP are that they are based on the request-response model. Constrained platforms may not require a response and in the implementations and may completely ignore them. With HTTP, the wireless sensor must receive the packet containing the response before the TCP connection can be closed and its associated state discarded. This is actually a problem associated with TCP, but as HTTP requires TCP to function it also inherits it.
With CoAP, over UDP, it is possible to disable the reliability features and not store any state about connections. This means that any packets received can simply be discarded and nothing is lost if the radio is disabled immediately after sending the request. Still, it would be considered bad practice to send data across a network when there was never any intention for it to be received by the node it was addressed to.
Given that CoAP allows for these non-confirmable messages, a server could be configured to not send a response to the request. This would not break the CoAP specification as, for a non-confirmable request, no response is guaranteed. This would however require the non-standard configuration of a server which could break its interoperability with other platforms also depending on it.
The CoAP stack is clearly a better solution than the HTTP stack for wireless sensor networks but it seems that there are still places where it has shortcomings. These shortcomings are mainly due to the fact that it aims to maintain interoperability with HTTP systems and so inherits the same models. Where power availability is not constrained, CoAP would be useful for tasks such as pushing configuration updates to nodes and receiving confirmations of completion using a multicast request or having a smart light-switch turn off all the lights in the house but for simply submitting sensor observations there is room for a more lightweight protocol.