Machine-to-machine platform architecture for horizontal service integration
© Kim and Youm; licensee Springer. 2013
Received: 31 December 2012
Accepted: 20 February 2013
Published: 20 March 2013
Nowadays, machine-to-machine (M2M) communication is being considered as the most promising solution for revolutionizing the future intelligent pervasive applications. This article presents the design of an M2M service platform architecture and prototype implementation of a home automation system based on the designed M2M platform. The proposed service platform consists of three subsystems: M2M service enablement, M2M device management, and M2M communication management. These subsystems include the essential function blocks and interact with each other to horizontally accommodate various M2M applications. The prototype implementation of the full “smart home automation” system, including the M2M service platform, M2M area network, and user/administrator domains, shows the feasibility of the proposed M2M platform architecture.
KeywordsHorizontal integration Machine-to-machine Prototype implementation Service platform
Machine-to-machine (M2M) communication has emerged as a cutting edge technology for next-generation communications and is considered as the most promising solution for revolutionizing the future intelligent pervasive applications [1–6]. Wireless M2M communication is a form of data transfer that let machines communicate directly with one another with little or no human intervention. It can be used in various applications such as home automation, telemetry, energy management, and transportation, with the objectives of improving the efficiency and reducing the cost. Moreover, it is expected that M2M will play an important role as the infrastructure for a ubiquitous society in the near future.
However, from the perspective of M2M business, service enabler companies, such as mobile network operators, which are able to own their service infrastructure to provide M2M services, face many market and technical challenges, which can be described as follows: due to the long-tail market feature of M2M, most current business cases (i.e., the conventional model) use the vertical integration model, in which the service provider should configure the service infrastructure such as the application server on a case-by-case basis per individual M2M application . Kouji et al.  reported that the horizontal integration model is more desirable than the vertical model to stimulate the market for M2M services and that, in the horizontal model, a common M2M service platform is needed to continue collecting information on various devices and to be able to manage and control them. In addition, the technical challenge is tightly related to the functions or capabilities of this M2M service platform, which includes service enablement, device management, connection management, and M2M application deployment.
Recently, a lot of effort has been put into the standardization of such platforms [9, 10]. For example, the European Telecommunications Standards Institute (ETSI) has launched the M2M Technical Committee with the purpose of developing an end-to-end architecture for M2M communications . To support a wide range of M2M applications, the ETSI TC M2M is defining a set of standardized service capabilities that can be implemented in an M2M platform located in the network domain, in an M2M device (terminal) or M2M gateway. Also, to promote the wireless interconnectivity of the different M2M components, mobile operators around the world have been active in constructing platforms to integrate M2M services by using infrastructure networks and launching M2M projects (e.g., GSM Association’s Embedded Mobile Initiative) . Nevertheless, there is no consensus on the general network and platform architecture to use for M2M communications, and the related challenging issues are still open.
In this article, we first illustrate the network architecture, which is decomposed into three complementary domains: the M2M device/gateway, M2M service platform, and user/administrator. Then, we present a high-level functional architecture for the proposed end-to-end M2M system, while focusing on the detailed functionalities within the M2M service platform. The proposed service platform architecture consists of three subsystems: M2M service enablement (MSE), M2M device management (MDM), and M2M communication management (MCM), which collaboratively support the M2M applications deployed by a service provider, third party, or the general user. In this study, we defined only the essential function blocks for an M2M service platform that is able to horizontally accommodate various applications. In other words, the components related to real business or the integration issues with legacy systems of the mobile network operator are not considered here.
In order to confirm the feasibility of the proposed M2M platform architecture, we established a prototype implementation consisting of a “smart home automation” system, which is divided into three domains, namely, the M2M service platform, M2M area network, and user/administrator domains. First, the M2M service platform is developed using the connected objects operating system (COOS) open source middleware . To set up the M2M area network domain, we used the home miniature test bed, and developed two types of user interface, viz. smart phone application and web browser interfaces for the user/administrator domain. This prototype implementation of the full system shows the feasibility of the proposed M2M platform architecture.
In the following, we describe the design and implementation of this study in detail.
2. System architecture
3. Proposed M2M service platform
3.1. Framework design
As mentioned above, the vertical market feature of M2M business causes the service providers (e.g., mobile network operators) to require a flexible and scalable service enablement solution for M2M. In other words, the M2M service providers wish to consolidate and extend their vertical business in the M2M market regions by introducing a unified horizontal service platform, which can support multiple verticals from a single-code base. To satisfy this requirement, we propose a generic architecture for the M2M service platform. In this section, we describe the proposed M2M service platform and its components.
The MDM subsystem supports the remote management of M2M device/gateway and interacts with the MSE and MCM subsystems. When the configuration policy request arrives from the MSE, the configuration manager block of the MDM sends the configuration command to the MCM. The MCM subsystem maintains the primary functionalities for providing the required connectivity and consists of the following function blocks: Protocol mapper, Identity manager, Message handler, and Access controller. The protocol mapper block plays the role of a mediator for the different protocols or data formats between the M2M application (at the north bound) and M2M device/gateway (at the south bound). For example, at the north bound, it can convert the Java business integration (JBI) protocol to the application protocol or vice versa. At the south bound, this conversion can occur between the JBI and device protocols. The protocol mapper also carries out the data format translation between the device data and service platform data models. The identity manager and access controller blocks manage the IDs of the M2M device/gateway and conduct the authentication and authorization required for their valid usage for the service platform, respectively. The message handler block forwards the message to the appropriate subsystem according to the characteristics of the message. In other words, the sensing data from the end device are directly routed to the MSE subsystem, while the configuration data, such as device fault alarms, are sent to the MDM.
The M2M device/gateway basically includes the device application, connectivity module, one or more sensors, and connection agent. The connection agent plays the role of the connectivity client for the M2M service platform server and also provides the functionality of protocol adaptation layer required to translate the data format between the different protocols.
Note that the proposed service platform, including the three subsystems, MSE, MDM, and MCM, closely interacts with the M2M device/gateway, but is independent of the particular choice of underlying networking technology (WPAN or WLAN).
3.2. Operation scenario examples
In this section, we demonstrate the operation flow based on the primary services, namely remote configuration for the M2M devices and sensing data collection (aggregation)/processing, when applying the proposed platform to the M2M communication business.
➢ The configuration procedure starts when the user asks the system to activate a given policy for the M2M device/gateway via the Portal/API. The request goes to the configuration manager block in the MDM subsystem.
➢ For each device/gateway, the MDM sends a configuration command, including the device identity and parameter set, to the protocol mapper block of the MCM. The protocol mapper block verifies whether the device is online.
➢ If it is online, it simply routes the command to the right connection agent, which deploys the configuration changes to the device via the internal API. Each of the entities involved is provided with the outcome.
➢ In the case where there is no ongoing session, the protocol mapper block retrieves the device’s address from the identity manager and access controller of the MCM subsystem. Using its address, it polls the device by sending an appropriate message, which can be an SMS (specific to the device type and vendor).
➢ The device makes a request to open a session and is challenged to prove its identity. For instance, it can be requested to provide some configuration information as part of its response. Once the authentication process ends, the identity manager and access controller clears the device to the protocol mapper block, which can then proceed with the configuration process.
➢ As the first step, the reporting policy is sent via the API to the event processor block in the MSE subsystem.
➢ This process configures the connection agent to start periodically polling the device.
➢ Once the MSE subsystem receives the data, the event processor block validates it and then forwards it to the “Events” repository for the user-specific business logic.
➢ In addition, the event processor stores all of the raw data in a database, “Raw data”, which can be accessed by the application.
4. Prototype implementation
Our ultimate goal is to design a general purpose M2M service platform rather than a home automation-specific one. In this article, we prototyped the home M2M system to provide insight into the design of the M2M platform architecture. Our future work includes deploying various kinds of M2M applications using our M2M service platform.
This article presents a design for an M2M service platform architecture and a prototype implementation of a home automation system based on the designed M2M platform. In the design of the platform architecture, there exist three collaborating subsystems, namely the MSE, MDM, and MCM subsystems, in which we define the essential function blocks needed to horizontally accommodate various M2M applications. The feasibility of the proposed M2M platform architecture is demonstrated through a full “smart home automation” system, including the M2M service platform, M2M area network, and user/administrator domains.
- Niyato D, Xiao L, Wang P: Machine-to-machine communications for home energy management system in smart grid. IEEE Commun. Mag. 2011, 49(4):53-59.View ArticleGoogle Scholar
- Lu R, Li X, Liang X, Shen X, Lin X: GRS: the green, reliability, and security of emerging machine to machine communications. IEEE Commun. Mag. 2011, 49(4):28-35.View ArticleGoogle Scholar
- Zhang Y, Yu R, Xie S, Yao W, Xiao Y, Guizani M: Home M2M networks: architectures, standards, and QoS improvement. IEEE Commun. Mag. 2011, 49(4):44-52.View ArticleGoogle Scholar
- Fadlullah ZM, Fouda MM, Kato N, Takeuchi A, Iwasaki N, Nozaki Y: Toward intelligent machine-to-machine communications in smart grid. IEEE Commun. Mag. 2011, 49(4):60-65.View ArticleGoogle Scholar
- Wu G, Talwar S, Johnsson K, Himayat N, Johnson KD: M2M: from mobile to embedded internet. IEEE Commun. Mag. 2011, 49(4):36-43.View ArticleGoogle Scholar
- Lien SY, Chen KC, Lin Y: Toward ubiquitous massive accesses in 3GPP machine-to-machine communications. IEEE Commun. Mag. 2011, 49(4):66-74.View ArticleGoogle Scholar
- Gilani S: The promise of M2M: how pervasive connected machines are fueling the next wireless revolution. Embedded Systems White Paper 2009. http://www.mentor.comGoogle Scholar
- Kouji K, Yoshitaro N, Tadashi S: M2M service platform to support carrier cloud. NEC Tech. J. 2010, 5(2):116-121.Google Scholar
- Chang K, Soong A, Tseng M, Xiang Z: Global wireless machine-to-machine standardization. IEEE Internet Comput. 2011, 15(2):64-69.View ArticleGoogle Scholar
- Katsuhiko Y, Hirohisa S: Trends in M2M standardization and NEC’s activities to promote the standardization of remote management technologies. NEC Tech. J. 2011, 6(4):28-32.Google Scholar
- ETSI TS 102 690 v2.0.6, ETSI technical specification, machine-to-machine communications (M2M); functional architecture 2012.http://portal.etsi.org
- GSM Association (GSMA) Embedded Mobile . Accessed 31 Aug 2012 http://www.gsma.com
- Audestad J, Gronbak I, Svaet S: Connected objects platform specification version 1, R&I Research Report, 1-66. 2009.Google Scholar
This article is published under license to BioMed Central Ltd. This is an Open Access article distributed under the terms of the Creative Commons Attribution License (http://creativecommons.org/licenses/by/2.0), which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.