## 6 Discussion
### Interoperability  
According to the review, it can be seen that there are technologies available for M2M service communications between remote physical objects over the network infrastructures with virtual world services. However, there are still challenges related to adaptability, reliability, performance, security, smartness, interoperability, and cost of development, manual operation and maintenance during the life-cycle of M2M products. 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 [145], Cisco [146], AnyBridge [147], Systech [148], Alcatel Lucent [149] and IOT-A [141] 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. Such a gateway can take care of mapping of protocols to be more applicable for embedded capillary networks and devices, and enable interoperability between various proprietary networks. For example, the M2M gateway (which may also be called a border router) can translate HTTP to CoAP, IPv6 to 6 LowPan, XMPP to Bluetooth Smart and 6 LowPan to Bluetooth Smart messages. In addition, 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 [150; 151; 152]. There seems to be multiple communication options for realization of 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 a need to have an M2M service gateway, which is able to act as a bridge/protocol translator between M2M asset network and M2M infrastructure. There are also multiple options for making protocol translation from WAN connectivity to LAN connectivity in M2M gateways. For example, 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 several options, however, there are several practical challenges which require optimization within the local M2M asset network such as, e.g., application of web services within constrained local M2M asset network, sizes of IP packets and headers, power consumption of radio access protocols,heterogeneity and mobility of M2M devices and local M2M asset networks, and coding and integration of M2M application content.