## 2 Architectural Principles  
### Horizontal M2M  
M2M service networks are inherently multiple stakeholder systems. Some parts of the system are highly dependent on the application domain, and some parts can be evolving in different timescales. For example, the generations of cellular radio systems may evolve 10 years, while novel M2M applications may born even every month. However, the M2M service system lifecycles are required to be even longer than 20 years. If a part of the system is dependent on a single provider, then it is a strong risk for system being operational for such a long lifecycle. Therefore, the system shall be based on open standards, and horizontal layering shall be kept clear. If autonomic M2M solutions are developed for the system where horizontal layers are mixed, the challenge with such solutions is that their application likely to be limited to the special case only. Therefore, the following high level architectural principles for horizontal M2M system have here been defined (see Figure 1, in which the main principles are visualized):  
1. Application domain specific part shall be separated from application domain independent parts;
2. The system horizontal layers, evolving in different timescales shall be clearly separated from each other;
3. Each system horizontal layers, shall be possible to have multiple providers;
4. The system interfaces shall apply open and standard based technologies;The functions of the horizontal layers shall not be mixed. A single technology shall focus only into its' basic functions in a single horizontal layer. For example:  
1. M2M Information layer shall focus only for the information and its meaning;
2. M2M service platform shall focus only to enabling the service capabilities, and it should be transparent for the (a);
3. M2M communication shall focus only to transport of messages/data between entities, and being transparent for (a) and (b);
4. M2M radio accesses shall focus only to enabling communication links over the media, and being transparent for the (a), (b) and (c);
5. Creation of trust between entities shall be transparent for (a), (b), (c) and (d). Based on the resulting security credentials, end to end security between M2M applications and encryption/decryption in each of (a), (b), (c) and (d) can be done;
6. Each of (a), (b), (c), (d) and (e) shall provide management and service interface to be used by upper layer and/or M2M applications. The key provided building blocks, capable to enable the referred principles, selected for the evaluation are the following autonomic M2M manager, ETSI M2M service capabilities, M2M messaging over XMPP, M2M gateways capable for making protocol mapping towards constrained M2M devices and creation of trust to enable end-to-end security for M2M applications, Figure 1, These selections and enablers are shortly clarified in the following. The selected approach for handling the M2M system complexity is making the decisions in information abstraction layer with the aid of autonomic manager. Such autonomic manager is able to monitor the system in information level, analyze the situation, plan the required actions, and execute the control events towards the system automatically or at least semi-automatically. European Telecommunication Standards Institute (ETSI) M2M service capability layer (SCL) assumes that  
Figure 1: Machine to Machine (M2M) architecture principles. M2M applications know all details of the device installation and data interpretation. This is challenging for M2M application developers, and therefore, autonomic service capabilities are being created for SCL, to connect it smoothly with autonomic manager and information management. ETSI M2M SCL has been specified to work with Representational State Transfer (REST) style of transport, such as Hypertext Transfer Protocol (HTTP). However, usually, M2M applications are based on messaging with M2M devices. Traditionally, such messaging is done with short message service (SMS) or Email systems.