## 3 Key Building Blocks
### M2M Service Platform
For example, network applications can subscribe to information produced by a sensor (Device application) registered on a reachable GSCL, Figure 8. We presume that the GSCL is registered to the NSCL and that the Device Application is registered to the GSCL. Figure 7: Architecture of ETSI M2M Service Capabilities. Non-ETSI compliant M2M entities (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 [5]. 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. For example, network applications can subscribe to information produced by a sensor (Device application) registered on a reachable GSCL, Figure 8. We presume that the GSCL is registered to the NSCL and that the Device Application is registered to the GSCL. First, the Network application registers to the NSCL (001). Then the Network Application Enablement capability checks if the issuer is authorized to be registered and treats the request (002). The registration information is then stored by the Network Reachability, Addressing and Repository Capability. The Network Application receives a positive answer (003). The Network Application subscribes to the data produced by the desired sensor (Device application) (004). This data can also follow a certain criteria specified by the issue. If the issuer is authorized to subscribe to the given Device Application, the Gateway Reachability, Addressing and Reachability capability treat the request (005). The Network application receives a positive response (006). Device application sends information to the Gateway (007). The Gateway Reachability, Addressing and Repository Capability identify an event that needs to be reported to a subscriber (008). Finally, the GRAR Capability notifies the subscribers (009). Each element of the ETSI M2M architecture is a resource that can be handled through six functions, the Create, Retrieve, Update, Delete, Notify and Execute. Notify is used for reporting a notification to a subscribed resource. Execute for executing a management command/task which is represented by a resource. An example of ETSI resource tree is visualized in Figure 9. Each part of the tree represents a certain capability of the Service Capability Layer. The notation <resourceName> means a placeholder for an identifier of a resource of a certain type. The actual name of the resource is not predetermined. The notation \"attribute\" denotes a placeholder for one or more fixed names. The resources without the delimiters < and > or \"and\", names appearing in boxes are literals for fixed resource names or attributes. The M2M REST resources can be accessed through URIs (see [5] for more information). Figure 8: Sequence diagram for a network application subscription to device data. M2M REST resources of the tree are mapped to HTTP REST resources and Extensible markup language (XML) data structures. The data types can be mapped to equivalent JavaScript Object Notation (JSON) data structures as well. Each normal HTTP REST resource shall have a representation in XML. One M2M resource corresponds to one XML or JSON data structure. The resource representation shall be carried in create requests (POST), update requests (PUT), successful retrieve (GET) responses and notify (POST) requests. When transported in a HTTP request or HTTP response, the resource representation shall be carried in the body. ETSI M2M SCL has been specified to enable generic horizontal service capability layer to be applicable for multiple applications. It assumes that M2M applications know all the details of the device installation and data interpretation.