Article Preview
Top1. Introduction
Machine-to-Machine (M2M) communications allow intelligent objects, which are uniquely identified, to capture data from or to control the environment, and to exchange information without human intervention (Pireira, 2014); Ratasuk, 2015). It is expected that M2M communications will change the businesses like intelligent transport systems (Mehmood, 2016), city automation (Honarvar, 2016), energy efficiency (Al-Naima, 2014; Vardakas, 2015), and healthcare applications (Shakhakarmi, 2015). It is expected that by 2020, 95% of devices will be connected to the network by a wireless technology. The increased amount of connected devices and M2M applications becomes business and technical challenges for network operators.
One of the main challenges standing in the way of M2M technologies is the fragmentation of solutions. Most of the solutions developed and implemented to date address specific application requirements which results in heterogeneous forms of technologies, platforms, and data models (Kim, 2014). There is a lack of interoperability. Horizontal service platforms have to be used to provide M2M value-added services and to enable reusable, modular and scalable M2M application environment (Latvakoski, 2014; Barki, 2016; Fysarakis, 2016).
As to functional architecture of M2M communications (ETSI TS 102 690, 2011), service capabilities are software modules that are exposed to M2M applications through the use of application programming interfaces (APIs). The Web Services (WS) model is based on the assumption that communications are like invocation of remote services whose nature can be ignored (Bendekkoum, 2016). But this model is not suitable for M2M applications, as M2M devices possess constrained computing capabilities. REST (REpresentational State Transfer) is adopted as a method for M2M modelling and implementation. In REST, each physical or logical entity is represented as a resource which has particular state. The resource can be addressed through HTTP Uniform Resource Identifier (URI) and its states can be retrieved and updated. Resources can be created and destroyed respectively. For constrained devices with limited memory and processing capacity, the Constrained Application Protocol (CoAP) is defined. Like HTTP, CoAP is based on REST. It is designed to use minimal resources on the device and on the network, supporting a fixed header and compact encoding. The protocol uses UDP as a transport protocol and provides strong security (Choi, 2016; Rahman, 2016).