Development of an oneM2M-compliant IoT Platform for Wearable Data Collection

Abstract

Internet of Things (IoT) is commonly referred to as a future internet technology to provide advanced services by interconnecting physical and virtual things, collecting and using many data from them. The IoT platform is a server platform with a common architecture to collect and share the data independent of the IoT devices and services. Recently, oneM2M, the global standards initiative for Machine-to-Machine (M2M) communications and the IoT announced the availability of oneM2M Release 2 specifications. Accordingly, this paper presents a new oneM2M-compliant IoT platform called Mobius 2.0 and proposes its application to collect the biosignal data from wearable IoT devices for emotion recognition. Experimental results show that we can collect various biosignal data seamlessly and extract meaningful features from the biosignal data to recognize two emotions of joy and sadness.

1. Introduction

Internet of Things (IoT) often refers to a convergence technology including devices, networks, platforms and services and also a future internet technology enabling advanced services by interconnecting physical and virtual things, collecting and using a lot of data from them [1]-[4]. Historically, the IoT succeeded the concept of ubiquitous computing initially put forward by Mark Weiser in the early 1990s [5] and its term was first coined by Kevin Ashton, executive director of the Auto-ID center in 1999 [6]. Research on the IoT began in earnest from the end of 2011 since when diverse IoT platforms based on a horizontal model in Fig. 1 have been applied to existing ubiquitous environment [7]. The IoT platform denotes a server platform that connects the IoT devices, collects data from them and provides the collected data with a common interface for a variety of services. In other words, it should have a common platform architecture to collect and share data independent of the devices and services. In the near future, it will be evolved to provide distributed data processing, big data analytics, etc. as shown in Fig. 2. In addition, the Internet Engineering Task Force (IETF) defined an adaptation layer (6LoWPAN-IPv6 over Low-Power Wireless Personal Area Network), routing (ROLL- Routing Over Low power and Lossy networks), and a resource-oriented application protocol (CoRE-Constrained RESTful Environments) for the interconnection of sensors and actuators considered as IoT devices [8].

Fig. 1. Moving from vertical platform model to horizontal platform model

Fig. 2. Functional evolution of IoT platforms

IoT standardization activities have been widely conducted by many organizations including Open Mobile Alliance (OMA), Open Connectivity Foundation (OCF), and oneM2M in [9-11]. Recently, OMA published the Ligntweight Machine to Machine (LwM2M) technical specification version 1.1. The LwM2M is principally a device management protocol, but it is able to transfer service and application data. It also implements the interface between M2M device and M2M Server [9]. OCF published OCF specification 1.3 including core framework, security, bridging, resource type, device, Wi-Fi easy setup, and resource to AllJoyn interface mapping [10]. Its specifications are divided into core specification documents, and vertical profiles specification documents. The core specification documents specify the OCF core architecture, interfaces, protocols and services to enable OCF profiles implementation for IoT usages and ecosystems. The vertical profiles specification documents specify the OCF profiles to enable IoT usages for different market segments such as smart home, industrial, healthcare, and automotive. oneM2M is the global standards initiative for Machine-to-Machine (M2M) communications and the IoT [11], and some IoT platforms based on oneM2M Release 1 specifications have been developed, commercialized, or distributed as open source packages. Recently it published a new landmark set of specifications, Release 2. The oneM2M Release 2 specifications based on contributions from more than 200 member companies enable basic connectivity between applications and devices, and they open up the IoT ecosystem to devices that lack the protocol and enable interworking among systems using the Open Connectivity Foundation and Open Mobile Alliance specifications.

Therefore, this paper presents an oneM2M-compliant IoT platform called Mobius 2.0 and its application to collect the biosignal data from wearable IoT devices for emotion recognition. Compared to the previous work in [12, 13], the proposed application can seamlessly extract meaningful features from various biosignal data. The rest of the paper is organized as follows. In Section 2, we briefly review the state-of-the-art of oneM2M standardization and describe our oneM2M-compliant IoT platform based on oneM2M Release 2 specifications. Section 3 addresses the proposed data collection application of the oneM2M-compliant IoT platform for emotion recognition. The architecture, procedure and resource tree of the oneM2M-compliant IoT platform are described in detail. Section 4 presents experimental results of biosignal data and their correlation analysis to extract major feartures for emotion recognition. In Section 5, the concluding remarks are given.

2. oneM2M-compliant IoT Platform

2.1 Review of oneM2M Standardization

oneM2M is the global organization launched in July 2012 by Eight of the world’s leading standards developing organizations (SDOs) such as ARIB (Japan), ATIS (United States), CCSA (China), ETSI (Europe), TIA (USA), TTA (Korea), TTC (Japan) and TSDSI (India) and it has more than 200 participating partners and members. Its purpose and goal is to develop technical specifications to integrate different service platforms in the field with M2M/IoT-related business domains such as smart home, smart factory, smart car, smart city, etc. to one common M2M service layer platform and provide common service functions as Application Programming Interfaces (APIs). Through oneM2M technical specifications, the M2M/IoT market is expected to be active and expansive by improving compatibility between M2M/IoT products and services.

It announced the minimum deployable version of oneM2M Release 1 specifications in January 2015 and oneM2M Release 2 specifications in August 2016. Currently it is working on oneM2M Release 3 specifications as shown in Fig. 3. Release 1 includes basic functionality such as data management, device management, and basic protocol binding. Release 2 appends interworking, semantics, and web sockets based on Release 1. Release 3 focuses on service domain development, data analysis, and semantic search capabilities.

Fig. 3. Status of oneM2M standardization

Release 1, which was unveiled with the goal of providing a minimum deployable solution as mentioned above, defines the basic functions that the IoT common platform must provide. The basic functions called Common Service Functions (CSFs) are shown in Fig. 4.

Fig. 4. oneM2M common service functions

There are twelve functions: 1) application and service layer management, 2) communication management and delivery handling, 3) data management and repository, 4) device management, 5) discovery, 6) group management, 7) location, 8) network service exposure, service execution and triggering, 9) registration, 10) security, 11) service charging and accounting, and 12) subscription and notification [14]. The common Service Entity (CSE) including the CSFs can be defined differently according to its usage. For example, we call it as an Application Service Node CSE (ASN-CSE) when used as a device, a Middle Node CSE (MN-CSE) when used as a gateway, and an Infrastructure CSE (IN-CSE) when used as a server, respectively. Release 1 also defines common service layer messages as primitives exchanged between a device, a gateway, a service, and a service [15]. The primitives can be mapped to HyperText Transfer Protocol (HTTP), Constrained Application Protocol (CoAP), or Message Queuing Telemetry Transport (MQTT) messages and then they will be sent by the corresponding application layer protocol [16-18]. Through these protocol bindings, the service layer core protocol has no dependency on a specific application layer protocol. Moreover, additional protocol bindings can be supported in the future.

Release 2 was developed with the primary purpose of interworking with various industry standards such as AllJoyn, Open Connectivity Foundation (OCF), and Open Mobile Alliance (OMA) Lightweight M2M (LwM2M). It also defined the configuration of traffic patterns for interworking the 3GPP Release 13 network [19] and added the WebSocket protocol to provide full-duplex communication channels over a Transmission Control Protocol (TCP) connection [20]. It provides end-to-end security for multi-hop communications, while Release 1 provides hop-by-hop security between interconnected entities. Moreover, it provides access control through an external Dynamic Authorization System (DAS) server and access control using Role and Token based on AccessControlPolicy, while Release 1 provides access control based on policy information stored in the platform. Especially, it supports semantic interoperability by adding semantic annotation and query using Resource Description Framework (RDF) or OWL (Web Ontoloty Language). It can support time series data by using timeSeries resources for real-time and high-reliability applications to reflect requirements of the industry domain such as periodic data monitoring, missing data reporting, etc.

Release 3 is under development with the goal of being released in 2018. Under the theme of market adoption to make existing specifications widely deployed, it is preparing a developer’s guide document, a certification program, and a platform function catalog according to each use-case scenario. It is developing new functions including 3GPP Release 13/14 network interworking, Open Platform Communication Unified Architecture (OPC-UA) interworking, Open Service Gateway initiative (OSGi) interworking, Data Distribution Service (DDS) interworking, Modbus interworking, and Proximal IoT interworking. In order to make existing functions more advanced, it is also developing extension of semantic search, authorization in distributed environments, and test specifications related interoperability and security. Since Release 3, OneM2M has been focusing on smart city and industry domains by strengthening linkages and collaboration between related organizations.

2.2 oneM2M-compliant IoT Platform: Mobius 2.0

We developed the Mobius 2.0 platform as an oneM2M-compliant IoT server platform. It has been released as an open source software through a global partnership called OCEAN (Open allianCE for iot stANdard) aiming to promote the development and commercialization of IoT platforms, products, and services [21]. Fig. 5 shows its architecture structured with oneM2M entities and reference points through which any two entities can communicate with each other. It provides Representational State Transfer (REST) APIs for application layer protocols for interconnection between IoT devices and applications as shown in Fig. 6. It should be noted that there are a client platform called &Cube embedded in IoT devices and an interface called Thing Adaptation Software (TAS) between things and IoT devices. The APIs for creation and retrieval of oneM2M resources are provided to simplify the procedures of data management. The Mobius platform was implemented by using Node.js well known as an open-source, cross-platform JavaScript run-time environment and Node.js Express as a web application framework including many useful modules like HTTP, XML etc. Additionally, it provides development environment and APIs for users to develop their own IoT devices and services.

Fig. 5. Functional architecture of the Mobius 2.0 platform as an oneM2M-compilant IoT platform

Fig. 6. Connectivity between IoT devices and applications via Mobius 2.0

The Mobius platform works as a middle bridge to enable communications and interactions between IoT devices and applications as following. 1) The Mobius platform accepts uploaded data from authenticated IoT devices and stores the data into the MySQL DataBase (DB); 2) The authenticated IoT applications can retrieve the data stored in the Mobius platform using Mobius open APIs for monitoring purpose; 3) The authenticated IoT applications are able to control remotely IoT devices that have already registered with the Mobius platform by sending control commands. Then the Mobius platform will execute control commands to the target devices.

As shown in Fig. 7, the Mobius platform consists of four servers and a MySQL DB. The main server is the HTTP server that is internally interworking with other proxy servers such as CoAP, MQTT, and WebSocket. Consequently, the HTTP protocol is used for internal data processing and the Mobius platform has the MQTT broker and proxy server, the CoAP proxy server, and the WebSocket proxy server for protocol conversion. The protocol stack of the Mobius platform is shown in Fig. 8.

Fig. 7. Internal data processing flow of the Mobius 2.0 platform

Fig. 8. Protocol stack of the Mobius 2.0 platform

It can be roughly divided into the requester and the responder components. The requester component especially contains the DB connector and actor for data storage and access related to HTTP request messages. The responder component generates corresponding response messages in data serialization formats such as Extensible Markup Language (XML), JavaScript Object Notation (JSON) or Concise Binary Object Representation (CBOR). In Fig. 9, the Node.js source directory of the Mobius platform is illustrated. The “mobius.js” file initiates the Mobius platform (or server), helps loading main Node.js files, and contains the Mobius configuration parameters such as “defaultbodytype” indicating the data serialization format, “usecsetype” indicating the CSE type (IN-CSE, MN-CSE, ASN-CSE), “usecsebase” indicating the CSEBase name, “usecseid” indicating the CSEID, “usedbhost” indicating the host address, and “usedbpass” indicating the password for MySQL. The “app.js” file acts as a role of flow router running the Mobius platform.

Fig. 9. Node.js source directory of the Mobius 2.0 platform

It handles initial processing of received packets. It initiates the HTTP server with the listening mode to wait for the HTTP requests target to the HTTP server, handles the parsing of Uniform Resource Locator (URL) of packets and evaluates the correctness of the request body resulted of parsing. It then sends the request to “resource.js” to continue the processing if the request is valid one, otherwise throws exceptions. It also implements the server clustering algorithms in order to improve the performance of HTTP server. The “pxy_mqtt.js” file provides the MQTT proxying function to handle MQTT protocol messages in the HTTP protocol manner, the “pxy_coap.js” file does the CoAP proxying function to handle CoAP protocol messages in the HTTP protocol manner, and “pxy_ws.js” does the WebSocket proxying function to handle WebSocket protocol messages in the HTTP protocol manner. The “mobius/resource.js” file is the core source code to process the CREATE, RETRIEVE, UPDATE, DELETE, NOTIFY and DISCOVERY operations for oneM2M resource primitives. It undertakes the processing of parsed request URI and request body received from “app.js” according to the corresponding operation. It converts the data into a format to process the data and connect to the MySQL DB. The MySQL DB is initialized and handled by “db_action.js” and “sql_action.js” modules. The “mobius/responder.js” file is responsible for handling the response process. It receives the processing results from “app.js” and “resource.js” modules and generates responses in the XML, JSON, or CBOR format requested by the originator. In Table 1, we summarize the main features of the Mobius 2.0 platform in terms of oneM2M Release 2 specifications when compared to the Mobius 1.0 platform.

Table 1. Features Summary of the Mobius 2.0 platform

3. Wearable Data Collection Application

In Fig. 10, we present the system architecture of the Mobius 2.0 platform based on oneM2M Release 2 for the proposed data collection application compared to our previous system using the Mobius 1.0 based on oneM2M Release 1 [22].

Fig. 10. System architecture of the Mobius 2.0 platform for data collection application

It includes an Electroencephalography (EEG) headset, a smart band, a smartphone, the Mobius 2.0 platform interworking with a data collection and analysis application. The EEG headset measures five brain waves (Alpha, Beta, Gamma, Delta, and Theta), Attention, and Meditation data, and the smart band measures Skin Temperature (SKT), Galvanic Skin Response (GSR), and Heart Rate (HR) data. All the measured biosignal data from the wearable IoT devices (the EEG headset, the smart band) are transmitted to corresponding Android applications in the smartphone via Bluetooth. Note that the Android applications are modelled as application dedicated node-application entities (ADN-AEs) with capabilities to upload the biosignal data and interact with the Mobius 2.0 platform through a reference point for M2M communication with application entity (Mca) [23]. The software architectures of our Android applications for the smart band and EEG headset are shown in Fig. 11. The smart band application contains the getGSR, getSKT, and getHR methods for the TAS interfaces. It has the xmlBody method for the XML serialization and the HTTP protocol binding. Similarly, the EEG headset application includes the Alpha, Beta, Delta, Gamma, Theta, Attention, and Meditation methods for the TAS interfaces.

Fig. 11. Software acrhitectures of the smart band and the EEG headset applications

Naturally, the Mobius 2.0 platform is modelled as an infrastructure node-common service entity (IN-CSE) to register the ADN-AEs and create their container and content-instance resources. It parses the content-instance resources to obtain the uploaded biosignal data and store them on the MySQL DB. Its operation procedure and resource tree are shown in Fig. 12. The resource tree is constructed with child resources as follows. 1) The ADN-AE1 contains sub-resources of the container named “EEG Headset” and multiple content-instances named Alpha, Beta, Gamma, Delta, Theta, Attention, Meditation, and Eye-blink, and the ADN-AE2 contains sub- resources of the container named “Smartband” and the content-instance named HR, SKT, and GSR. The data collection and analysis application visualizes and analyzes biosignal data stored in the MySQL DB.

Fig. 12. Description of operation procedure and resource tree

4. Experimental Results and Discussion

This section describes some experimental results of the proposed data collection application based on the Mobius 2.0 platform. We considered the commercialized EEG headset and smart band in [24-26] as wearable IoT devices and prepared two movie clips in [27] to recognize two emotions of joy and sadness [28-30]. We collected all biosignal data through the Android applications and the Mobius 2.0 platform while five participants (two women and three men) wearing two wearable IoT devices were watching the movie clips related to joy and sadness emotions. The movie clips were adjusted to 1920×1080 resolution and were presented on a 24-inch LCD screen. Two speakers were used and its volume was adjusted to an appropriate level to keep the participants comfortable. The eyes of the participants were at approximately 1.0 meter from the screen center. Then, the participants were instructed to rest with their eyes open for 10 seconds and their eyes closed for another 10 seconds. After they watched the movie clips, they were instructed to rate their actual feelings on 5-point scales with specific terms (1=not at all, 5=very much).

Fig. 13 graphically represents the biosignal data that were measured by the wearable IoT devices and stored in the MySQL DB of our oneM2M-compliant IoT platform to verify its feasibility of seamless data collection.

Fig. 13. Graphical representation of biosignal data measured by the wearable IoT devices according to two emotions: joy and sadness

In Fig. 14 and Fig. 15, the scatterplot matrices are represented which are a great way to roughly find the linear correlation between all the biosignal data. The elements of scatterplot matrices are derived by the Pearson correlation coefficient. Joy emotion is highly correlated with Theta brain wave, Attention, HR, and GSR data, while sadness emotion is highly correlated with SKT data. In terms of emotion recognition, the Gamma and Beta brain waves, the Meditation data, and the GSR data can be selected as useful features since the differences between their correlation coefficients related joy and sadness emotion are large.

Fig. 14. Heatmap of all the biosignal data from the EEG headset and the smart band according to joy emotion

Fig. 15. Heatmap of all the biosignal data from the EEG headset and the smart band according to sadness emotion

5. Conclusion

In this paper, we presented the oneM2M-compliant IoT platform called Mobius 2.0 developed by using oneM2M Release 2 specifications. After its functional architecture, internal data processing flow, and protocol stack are briefly described, the Node.js source directory of the implemented Mobius 2.0 platform was explained. Furthermore, we proposed a data collection application for emotion recognition that was developed by using the Node.js sources. The system architecture, operation procedure, and resource tree for the data collection application were addressed. Here we considered two commercialized wearable IoT devices and movie clips for emotion recognition of joy and sadness emotions. Through some experimental results, we found meaningful biosignal data of the Gamma and Beta brain waves, the Meditation data, and the GSR data in terms of emotion recognition. The proposed data collection application based on the Mobius 2.0 platform can be successfully applied to emotion recognition because it can collect various biosignal data seamlessly and extract meaningful features from them.