## 4 M2M Communication
### Constrained Application Protocol (CoAP)  
The IETF CoRE (Constrained RESTful Environments) working group [111] has defined the Constrained Application Protocol (CoAP) standard with the goal of supporting REST-like applications inside constrained environments like those identified by the RoLL [112] and 6 lowPAN working groups. Application domains include LLNs and more generally M2M communications, and span over a large range of business use cases such as smart energy or building automation. The specification defines a binary message structure between CoAP endpoints as well as the interaction protocol. By following REST architectural principles [71], CoAP exposes a representation of the information available on a constrained device as a set of identifiable resources. This way, any CoAP endpoint may interact with it remotely using the interaction methods used by the HTTP protocol: GET, POST, PUT, and DELETE. In order to make the resources discoverable, the CoAP protocol standard advises to expose CoAP endpoint's resource metadata using the CoRE Link Format [113] at a specific URI. CoAP messages rely on the UDP transport protocol between endpoints. This is to accommodate the potentially unreliable and lossy wireless environments that render the TCP protocol inefficient in terms of network resource usage. In order to meet eventual QoS requirements, since UDP is natively unreliable, CoAP has introduced the use of confirmation messages, which correspond to an acknowledgement that a CoAP message has been received. Collection of data from a CoAP-enabled device is achieved by sending a CoAP request message (GET method) to the CoAP server hosted on the device: as soon as the CoAP server receives such a request, it replies with a CoAP response with data requested by the CoAP client or notifies that the response will be sent in a separate response. Another interaction scheme supported by the CoAP protocol is the publish/subscribe paradigm. Instead of sending periodical requests to a CoAP server to be kept updated on the status of a resource, the CoAP client may subscribe, through specific exposed end-points, to a CoAP server, which will be in charge of periodical updating all the subscribed clients of the status of a given resource. RESTful architectures make caching of the data possible within the network. Caching is supported by CoAP and makes it possible to optimize the data delivery over potentially constrained wireless links. For each CoAP observed value a lifetime is defined; if two consecutive requests are received by a CoAP server or proxy in a period of time smaller than that defined by the lifetime parameter, the former request will be sent querying the resource, whereas the latter will be served using the cached value. Using caching, some optimizations can be easily foreseeable for M2M communications. By serving fresh information from a cache instead of querying the endpoint itself, one could experience a shorter delay or a better QoS on a particular request. Also, caching may help reduce the overall consumption of an energy-constrained network by reducing the number of wireless transmissions required for collecting data. A low-power version of CoAP has been implemented for Contiki [114]. The implementation leverages the ContikiMAC low-power duty cycling mechanism to provide power efficiency. Based on the results of the CoAP request/response, cycles are most energy-efficient when each message fits into a single 802.15.4 frame. When messages are bigger than frames, the interoperation of information models, data encoding/decoding, and segmentation/reassembly with constrained M2M capillary networks and M2M asset devices need to be carefully considered. HC (HTTP/CoAP) proxies provide the interworking functionalities for application spanning across LLNs (potentially running CoAP/UDP/IPv6/IEEE 802.15.4 protocol stack) and the Internet (HTTP/TCP/IPv6).