## 2 Architectural Principles
### M2M Gateway for Interoperability  
Interoperability with existing systems and resource constrained embedded devices are usually approached via gateways of some sort. For example, the functional architecture designed by ETSI M2M [57], Cisco [58], AnyBridge [59], Systech [60], Alcatel Lucent [61] and IOT-A relies on the use of a kind of M2M gateway mainly because of challenges related to communication with constrained devices. Such a M2M gateway can handle e.g., the issues related to communicating with a system based on an incompatible communication protocol, low-power devices which are unable to communicate with the rest of the system directly due to limited resources or capabilities, or communication with a domain in which the access is otherwise restricted by some service provider. Thus, the gateway can act as a translating and security element, which can interconnect two systems having different protocols and data formats and perhaps belonging to different security domains. Such gateway component may not be optimal from communication point of view, but it is required in some cases because of interoperability and security. A gateway may also prevent message flooding from devices to the backbone network, enable management of M2M asset devices in groups, make maintenance and configuration smooth, enable usage of unlicensed frequency bands and/or optimized radio technologies for specific M2M asset devices. Typically, a gateway is then connected to a back-end server which is taking care of data storages, management, centralized control and enforcement of security policies. The use of back-end servers have a crucial role in combatting the various scalability and reliability issues found in pure peer-to-peer and ad-hoc -type systems [62, 63, 64]. The role of the M2M gateway as the enabler of interoperation between different M2M systems such as body area network (BAN)/personal area network (PAN), Industrial and Automation and Sport and Wellness systems is visualized in Figure 2. These different M2M systems can establish their own small (local and/or wide area) M2M ecosystem, which can then be connected with the rest of the system via M2M gateways. The overlay communication between the different M2M gateways, M2M asset devices (those that are not behind the M2M gateways) and back-end servers enables establishment of bigger M2M ecosystem with interoperable messaging enabled by the communication overlay. There are multiple communication options for M2M gateways: M2M gateway as an Internet protocol (IP) router, M2M gateway as a service gateway and direct connection to M2M devices without any M2M gateway. When M2M gateway is acting as an IP router, it makes possible to establish end-to-end IP connectivity if M2M asset devices are supporting IP. In that case, the local radio access technology needs to have mapping to IP communication. If M2M asset devices are not supporting IP, then there is need to have M2M service gateway, which is able to act as a bridge/protocol translator between M2M asset network and M2M infrastructure. The service capable M2M gateway is able to make protocol adaptation between proprietary protocol stack, and ETSI M2M SCL. Communication with constrained M2M devices can apply any of the options. However, there are several practical challenges which require optimization within the local M2M asset network. The first challenge is related to application of web services within constrained local M2M asset network. To solve this problem, IETF Constrained Restful Environments (CoRE) working group has specified CoAP standard with the goal of supporting REST-like applications inside constrained environments. The second challenge is related to the sizes of IP packets and headers. To solve this problem, IETF has created the 6 lowPAN, which describes an adaptation layer between IPv6 and a layer 2 protocol, such as (but not limited to) IEEE 802.15.4, to handle maximum  
Figure 2: The M2M Gateway as an enabler of interoperability. transmission unit (MTU) sizes and compress IPv6 headers from 60 bytes to 7 bytes.