## 2 Constrained Application Protocol (CoAP)  
Heterogeneity, limitations and vendor lock-in issues have been present for a while in resource-constrained devices. As is mentioned above, the IETF has contributed with many standards to connect these devices to the Internet and reduce the gap between them and powerful ones. Among these standards it should be pointed out 6 LoWPAN and RPL. However, the advances in the media layers are not enough, since the heterogeneity still climbs to the upper layers. Taking note of the expansion of the World Wide Web (WWW) and its standard interconnection mechanisms (web services), the IETF designed, through its CoRE working group, the Constrained Application Protocol. CoAP provides a RESTful architecture similar to current web services, nevertheless it has been adapted to resource-constrained devices. The most notable feature with respect to current RESTful web services is the abolition of the high-consumption protocols involved, such as HTTP and TCP. Handshaking, packet reordering and header characteristics of these protocols suppose a high barrier to devices with limited capabilities and presence in constrained networks. CoAP has adopted UDP as the transport layer, thereby reducing the overhead and requirements of TCP communications. The adoption of UDP brings IP multicast which can improve the control and reduce the number of communications in constrained networks. Due its UDP nature, CoAP provides two types of communications: confirmable and non-confirmable messages. Therefore, CoAP offers the strengths of confirmable messages in TCP while simultaneously providing lightweight communications for environments where confirmations are not necessary (e.g., stream data monitoring). To reduce the number of communications, confirmation responses can also be piggybacked. With a client-sever model, Figure 1 shows two examples of CoAP communications. Concretely, a client sends a GET request with a non-confirmable message to a CoAP server, and the server returns the temperature status (Figure 1a); and the same communication with a confirmable message and a piggybacked response (Figure 1b). Figure 1: CoAP messages. (**a**) Non-confirmable CoAP GET request; (**b**) Request with piggybacked response. Like RESTful web services, CoAP offers operations and objects through resources, which can be accessed with HTTP-style methods (GET, PUT, POST and DELETE). Accessing sensors and actuators can be defined in resources, thereby enabling an HTTP-style access to them. For instance, in Figure 1 a CoAP server contains a temperature sensor resource which is accessed through the '/temperature' URI by CoAP clients. In monitoring systems, it is important to have an up-to-date representation of the interested resources. However, continuous resource polling can drastically affect the devices' performance since communication is one of the most power-consuming tasks on these devices. CoAP supports proxying with caching capabilities, which can reduce the number of communications with final devices. Consider an HTTP-CoAP proxy which translates HTTP requests into CoAP ones. In the latter scenario, HTTP clients can access CoAP resources in the same way as the WWW, enabling the known paradigm of the WoT. However, it does not make an efficient use of these resources. IoT devices have still limitations that they have to address, like sleeping cycles which complicate access by clients. Furthermore, most monitoring systems are not interested in receiving monitoring data, but they are interested in data changes. An extension of CoAP, known as resource observation [10] introduces a mechanism to optimise the interactions with CoAP devices. Resource observation enables a new asynchronous communication model in CoAP where clients can subscribe to resources and receive asynchronous notifications. The observe operation can be configured with a max age option to indicate an age up to resource statuses are acceptable. Resource notifications are also sent when its status changes.