## 3 Key Building Blocks
### M2M Service Platform  
The ETSI M2M architecture is based on a set of horizontal service capability layers that can be applied to several vertical M2M application domains. These service capability layers are composed of a set of generic services and are deployed in M2M Servers, M2M gateways and smart M2M devices. The different service layers are distinguished by the role they provide in the architecture. Two domains are defined by the ETSI: a local domain with M2M device and gateways called _Device and Gateway domain_, and a WAN domain with M2M servers, core network access, M2M applications and  
Figure 5: The ontology model of the Autonomic M2M manager [66]. management functions called _Network domain,_ Figure 6. Data exchange between the different M2M entities in the different domains is done through 3 standardized communication interfaces: dla, mId and mla. * _dla_ interfaces devices applications and Gateway or Device Service Capability Layer;
* _mId_ interfaces the M2M Gateway or Device Service Capability Layer and the M2M Network Service Capability Layer;
* _mIa_ interfaces backend M2M Applications and the M2M Network Service Capability Layer. These interfaces aim to be applicable to a wide range of network technology and they are application and access independent [17]. The ETSI has adopted a Restful [68] architecture style for the M2M Applications and/or M2M SCL information exchange [16]. The main advantage of the Restful architecture style is that it's deployed above the transport layer, so the service capability layer is independent from the underlying networks. Each SCL is comprised of several services groups (Figure 7): Application Enablement Capability (AEC) for providing M2M point of contact for using the M2M applications of the corresponding SCL; Generic Communication Capability (GCC) for interfacing between the different SCL available on a given M2M Network; Reachability, Addressing and Repository Capability (RARC) for managing events relative subscriptions and notifications as well as for handling applications registration data and information storage; Communication Selection Capability (CSC) for network selection and alternative communication service selection after a communication failure; Remote Entity Management Capability (REM) for remote provisioning; Security Capability (SECC); History and Data Retention for archiving data (HDR); and Interworking Proxy (IP) for integrating non ETSI compliant systems. Figure 6: A view to ETSI M2M System. The communication interfaces provided by the ETSI platform allow the following methods: register, deregister, invoke, subscribe and data publish/subscribe. Registered M2M applications/devices can provide their services in two different ways:  
* Synchronized: Whenever a new value is available, the M2M application shall publish it on the corresponding data resource. This is ideal for a service that only publishes data (a temperature for example);
* Retargeted: All the operation on the given resource will be retargeted to the corresponding device/application. This is ideal for invocation services such as actuators. The platform also provides a publish/subscribe mechanism, which can be used to subscribe to data from other applications or to discover other applications (when they register for example). An M2M application can subscribe to one or more ETSI M2M entities. Non-ETSI compliant M2M entities (e.g., existing systems and devices) can be integrated to the architecture using the specified integration points (Interworking Proxy) on the Gateway and Network Service Capability Layers [16]. In the local domain the M2M Gateway acts as a proxy for M2M devices available in the same local area network. Once M2M devices applications are registered, they become available to other registered SCLs and M2M applications; according to the acquired access rights.