## 3 Key Building Blocks
### M2M Gateway with Constrained Devices  
Communication with embedded M2M asset devices requires usually protocol conversions and special router/gateway arrangements, because of limited power sources in devices. For example, conversion of HTTP to/from CoAP, conversion of XMPP message content to be transferred via Bluetooth Smart, and conversion of IPv6 messages to 6 LowPan, and 6 LowPan to Bluetooth Smart. The IETF CoRE working group [7] has defined the CoAP standard with the goal of supporting REST-like applications inside constrained environments. It defines a binary message structure between CoAP endpoints as well the interaction protocol. By following REST architectural principles [68], 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 [8] at a specific Uniform Resource Identifier (URI). UDP will be used instead of TCP, because TCP is inefficient in terms of network resource usage in wireless environment. In order to meet eventual Quality of Service (QoS) requirements, 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  
Figure 11: Server to server interdomain communication. 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 reducing the overall consumption of an energy-constrained network by reducing the number of wireless transmissions required for collecting data. CoAP has been designed for low-power networks and is not applicable for wide-area networks, which mostly rely on HTTP for distributed application. HC (HTTP/CoAP) proxies provides the interworking functionalities for application spanning across low-power networks (potentially running CoAP/UDP/IPv6/IEEE 802.15.4 protocol stack) and the Internet (HTTP/TCP/IPv6). CoAP base specifications identify DTLS [11] and IPsec [12] as mechanisms to offer data origin authentication, integrity and replay protection, and encryption for the CoAP messages. In addition to these, an alternative [13] to IPsec and DTLS has been presented. IPv6 brings some outstanding benefits such as an addressing scheme which allows identifying billions of devices and the support for point-to-point communications between a device and a PC connected to Internet.