Service Platform for Integration of various M2M/IoT system

ASN-AE
Mca
Mcn
Non-oneM2M 
Device Node 
(NoDN)
Mcc 
Mcc
Mcc
Mcc
Mcc
Mcc
Mca
Mca
Mca
Infrastructure domain
To an Infrastructure Node of 
other M2M Service Providers
Field domain
One or 
more AE
Zero or 
more AE
Link out of 
scope
Server/Cloud
Gateway
IoT 
Devices
 Journal of Science & Technology 144 (2020) 017-021 
19 
2.3 Bluetooth and Zigbee technology 
ZigBee [4] is the commercial name of the IEEE 
standard 802.15.4 for low-rate wireless personal area 
network standard (WPANs). It operates in the ISM ra-
dio band, use the 868 MHz band in much of Europe, 
915 MHz in the USA and 2.4 GHz in many other loca-
tions. The speed transmission depends on the used fre-
quency band, but the maximum is 250 Kbps. Alt-
hough, it is slower than other popular wireless technol-
ogies such as Wi-Fi to tradeoff for the lower power 
consumption and low-cost devices. ZigBee is com-
monly used for wireless control and monitoring appli-
cations in wireless sensor networks (WSNs). 
Bluetooth [5] operates at 2.4GHz, the same unli-
censed ISM frequency band where RF protocols like 
ZigBee and Wi-Fi also exist. Bluetooth networks have 
two types of functional devices: master and slave. A 
single master device can be connected with up to seven 
different slave devices, while a slave device is con-
nected to only one single master. Hence, the master can 
send data to any of its slave nodes and request data 
from them as well. Slave nodes are only allowed to 
transmit to and receive from their master. The two 
technologies are both using in various IoT/M2M sys-
tem. 
2.4 Related work 
 To interconnect among different frameworks and 
devices, oneM2M use two ways: protocol binding and 
inter-proxy entity (IPEs). In the former, different ap-
plication protocol data model is mapped to oneM2M 
primitives. In the latter, an additional module is de-
signed and implemented to translate the communica-
tion with other frameworks using their own protocols. 
The two ways are both based on the core oneM2M 
primitives. 
 Protocol binding. If an existing IoT/M2M sys-
tem runs on a certain application protocol, oneM2M 
MN must be installed a mediated module called proto-
col binding to help primitive message mapping to such 
application protocol message. oneM2M presently sup-
port up to three protocol binding: HTTP, CoAP and 
MQTT. While HTTP is used for stable connections 
such as a connection between MN and IN, CoAP and 
MQTT is suitable for connections to resource-con-
strained devices like sensors/actuators. The difficulty 
is the deployment of the mentioned IP-based protocol 
stacks on different network communication technolo-
gies, which leads to heavy load for resource-con-
strained devices. Besides, the message must follow a 
conversation structure of oneM2M standard to make 
changes in data messages of existing network struc-
ture. There are several studies that have been success-
ful with this solution, LoRa based motes (as IoT de-
vices) and gateway as MN, that enable LoRa-based de-
vices to exchange data through MQTT and CoAP pro-
tocol [6]. However, it is costly to integrate IP-based 
application protocols in all technologies/ systems us-
ing Bluetooth, Z-wave. Hence, the following solution 
seems more appropriate. 
Inter-Proxy Entity (IPEs). The other way is to 
develop a plugin entity running in MN. It communi-
cates to other IoT/M2M system and converts its data 
structure into of conversation following oneM2M 
standard. IPE enables to preserve other proprietary 
system and not to change the content of existing pro-
prietary messages. The drawback of IPE is that MN 
needs powerful hardware and plugged with a trans-
ceiver hardware module (e.g. Wi-Fi, Bluetooth, Zigbee 
radio). 
A theoretical design and several hints of imple-
mentation of a system based on IPEs are shown in [7], 
but no detail testbed is described. To enhance the effi-
ciency of IPE, [8] proposed the extension of protocol 
binding approach CFS included. Not only does IPE 
support connection to/from IoT devices or oneM2M 
networks, but it also interworks with others service 
platforms, e.g. building IPEs to bridge oneM2M-based 
system and IoTivity/AllJoyn-based system is pre-
sented in [9]. 
3. Hardware Architecture and Firmware Imple-
mentation for oneM2M-based interconnection 
Our work resolves two main goals. The first is to 
combine various application layer protocols through 
standardized protocol binding. Secondly, we design 
and implement IPEs to integrate the Bluetooth devices 
into the system. To carry out oneM2M services, we use 
Eclipse OM2M project, which is an open source im-
plementation of oneM2M standard, initiated by 
LAAS-CNRS [10]. 
3.1 Hardware architecture 
In the infrastructure, IN node (server) is installed 
in a powerful computer. It enables Internet connectiv-
ity providing an available link with field domain and 
possibly end-users. In the field domain, we have sev-
eral types of hardware: 
i) MN/Gateway works as a multiple-tech gate-
way, which is currently based on a laptop. We make 
use of Network Interface Card (NIC) built-in to con-
nect with IoT devices through Wi-Fi and Bluetooth. To 
offer connectivity with the Zigbee-based devices 
through CoAP on IPv6, the computer also assembles 
Z1 Zolertia node as border-router. 
 Journal of Science & Technology 144 (2020) 017-021 
20 
ii) IoT devices We deploy several types of IoT de-
vices based on various technologies: Wi-Fi-based de-
vice based on ESP8266 NodeMCU acts as a sensor 
node; Zigbee-based device is Z1 Zolertia node consid-
ered as actuator node; Bluetooth-based devices can be 
hand-held devices like smartphones, tablets. 
3.2 Firmware on Gateway 
Firmware on multi-tech gateway (MN node) is a 
crucial component in the system. It has two main func-
tions: to register with IN-CSE to manage devices and 
share CFSs (MN-CSE); all procedures are automati-
cally configured in OM2M-IN and OM2M-MN and to 
create connections with IoT devices which belong to 
various networks and implemented different protocol. 
The gateway firmware needs to be customized and in-
stalled additional plugin. The detailed components we 
have implemented is described below. 
i) Wi-Fi connection: Wi-Fi-based devices con-
nect to gateway via MQTT protocol. Hence, a Mos-
quito broker and MQTT protocol binding plugin must 
be installed on the gateway. MQTT protocol binding 
is responsible for two-way message transportation us-
ing specific publish/subscribe topic defined in [11]. 
Mosquito broker ensures the operation of MQTT 
standard such as send, store and forward. 
ii) ZigBee connection: To communicate across 
ZigBee, we use a border-route for RPL-based network 
of ZigBee-based devices. Since this network is imple-
mented with CoAP as application protocol, our gate-
way needs CoAP protocol binding plugin installation. 
iii) Bluetooth connection: We developed Blue-
tooth IPE using Bluecove library to connect the gate-
way to Bluetooth-based devices. The IPE includes two 
components, Bluetooth OBEX server and oneM2M 
AE. The former manages the pairing with Bluetooth-
based devices and exchange of data through Bluetooth 
interface. The latter is responsible for mapping be-
tween data to/from Bluetooth-based devices and 
oneM2M primitives, creating representative data iden-
tification of the IoT devices in oneM2M MN/IN data-
base and operational procedure interworking. 
3.3 Use case description 
The setup of the testbed is a case study for a typ-
ical monitoring and management IoT application, see 
Fig. 2. The IoT devices consist of sensor/actuator 
nodes and MN-gateway to gather data in the field. The 
gateway also supports the direct access of system man-
ager/admin for operation and maintenance. The center 
of data management locates in OM2M server/IN node 
and support the application access of users through In-
ternet. The testbed deploys Wi-Fi, Zigbee, Bluetooth 
for access technology and MQTT, CoAP, HTTP at the 
application. The interconnection of heterogenous sys-
tem is visualized. 
Fig. 2. The integration of IoT/M2M systems based on 
the common service platform oneM2M. 
In the initial phase, MN-CSE automatically reg-
ister with IN-CSE to make a basic OM2M system. Af-
ter initiating/loading the CoAP protocol binding, 
MQTT protocol binding and Bluetooth IPE module, 
MN is ready to serve connections from IoT devices. 
In the second phase, when IoT devices consisting 
of Wi-Fi-based device and Zigbee-based device are 
turned on, they will establish their resource trees (the 
information of their particular AEs) and their essential 
containers to store their data in MN. The establish-
ment/resource registration with MN is processed 
through the primitives of OM2M. Afterward, the sen-
sor node and actuator nodes start to send their data en-
capsulated in Content Instance (CINs) format to the 
gateway. 
To process the collected data, we use Manager 
ADN loaded in MN gateway. It creates a subscription 
of certain resource to get notifications about the inter-
ested events. After analyzing, MN gateway can detect 
abnormal events and update its database or send con-
trol commands to the actuator ADN. 
In our scenario, sensor node sends luminosity 
data using MQTT protocol on Wi-Fi to the MN-gate-
way every minute. The gateway receives data and 
sends the notification that contains the sensor values to 
a subscriber, the ADN named manager, which is a data 
processing module checking luminosity data to be over 
a specified threshold. If the value is lower, a control 
command “turn LED ON” will be sent to the actuator 
ADN and immediately forwarded to underlying actua-
tor device using CoAP protocol on Zigbee. The actua-
tor receives notification from MN-gateway and turn on 
LED. Hence, the data processing function can reside in 
the MN-gateway to reduce the data sending to IN 
node/OM2M server. 
OM2M 
Gateway
OM2M 
Server
UserSystem 
Admin
Sensor Actuator
 Journal of Science & Technology 144 (2020) 017-021 
21 
The Bluetooth IPE in MN-gateway is setup as a 
Bluetooth server. After the Bluetooth-based device 
paired with the gateway, all resources are automati-
cally created, then temperature data and led status can 
be monitored on user’s smartphone or system admin’s 
smartphone, see Fig. 2. 
4. Discussion 
Numerous IoT devices connected to oneM2M 
system generate large volume of data, which might 
cause server overloaded and increase network latency. 
To solve this problem, edge computing has been pro-
posed to reduce the access bandwidth to core net-
work/cloud and release workload of the cloud servers. 
Currently, oneM2M has already supported some sim-
ple functions to deploy edge computing environment: 
i) Database can be stored in MN; ii) Two MNs can di-
rectly exchange data with each other, without going 
through IN. In our proposed architecture, the pro-
cessing component can reside in MN-gateway instead 
of locating in IN node. It is possible to deploy the data 
processing function for all IoT devices connected with 
up to three MN-gateways. The current limitation is the 
communication among MNs, which is presently point-
to-point. The awareness of link existence is only made 
between two neighboring MNs. To resolve this prob-
lem, a routing protocol need to be added in oneM2M. 
At the current stage of the work, we just use a 
laptop as a gateway platform for implementing the 
connect with IoT devices through Wi-Fi and Blue-
tooth. To offer connectivity with the Zigbee-based de-
vices through CoAP on IPv6, the computer also assem-
bles Z1 Zolertia node as border-router. In the future 
work, we focus on design an multi-platform IoT gate-
way embedding AI/Edge Computing and considering 
the problem of speed adaptation, devices’ self-config-
uration, battery powered and secure. The proposal 
multi-platform IoT gateway aims to be apply for a 
smart on-street parking management system. 
5. Conclusion 
We demonstrate an implementation of oneM2M 
system which operates on Wi-Fi, Zigbee and Bluetooth 
technology and uses three application protocol HTTP, 
CoAP, MQTT. By developing a plugin in the MN-
gateway, we do not need to change the existing sys-
tems. We also deploy a simple data processing func-
tion at the MN-gateway to limit the amount of data 
sending to IN node. The interconnection of different 
systems allows data exchange efficiently and regular 
applications can be applied. In the future work, we plan 
to design stand-alone gateways to replace laptop and 
to design and deploy more function of edge computing 
one numerous gateways for performance evaluation. 
Acknowledgments 
This work is supported by the project T2018-PC-
068 from Hanoi University of Science and Technology 
References 
[1] J. Swetina, G. Lu, P. Jacobs, F. Ennesser, and J. Song, 
“Toward a standardized common M2M service layer 
platform: Introduction to oneM2M,” IEEE Wireless 
Communications, vol. 21, no. 3, pp. 20-26, jun 2014. 
[2] OASIS, “MQTT Version 3.1.1,” p. 81, 2014. [Online]. 
Available:  open.org/mqtt.html 
[3] Z. Shelby, K. Hartke, and C. Bormann, “RFC 7252: The 
Constrained Application Protocol (CoAP),” 2014. 
[Online]. Available: https://tools.ietf.org/html/rfc7252 
[4] ZigBee Alliance, Inc., “ZigBee Specification,” 2012. 
[Online]. Available: 
tent/uploads/2014/11/docs-05-3474-20-0csg-zigbee-
specification.pdf 
[5] "BLUETOOTH SPECIFICATION Version 3.0", 
[Online]. Avaiable: https://www.bluetooth.com/speci-
fications/bluetooth-core-specification/ 
[6] Thanh-Long Nguyen, Simone Patonico, Maite Be-
zunartea Steffen Thielemans, An Braeken and Kris 
Steenhaut, "Horizontal Integration of CoAP and MQTT 
on Internet Protocol - based LoRaMotes" in 2018 IEEE 
29th Annual International Symposium on Personal, In-
door, and Mobile Radio Communica-tions (PIMRC), 
Sept. 2018. 
[7] Žitnik, S., Janković, M., Petrovčič, K., Bajec, M.: "Ar-
chitecture of standard-based, interoperable and extensi-
ble IoT platform" in Proceedings of the 24th Telecom-
munications Forum (TELFOR), Belgrade, pp. 1–4 
(2016). 
[8] J. H. Huh, D. H. Kim, J. Deokkim, "oneM2M: Ex-ten-
sion of protocol binding: Reuse of binding proto-col's 
legacy services", Proceedings of International Confer-
ence on Information Networking (ICDIN), pp. 363-365, 
13–15 Jan. 2016. 
[9] C. W. Wu, F. J. Lin, C. H. Wang, N. Chang, "OneM2M-
based IoT protocol integration", 2017 IEEE Conference 
on Standards for Communications and Networking 
(CSCN), pp. 252-257, 2017. 
[10] “Eclipse OM2M-Open Source platform M2M com-mu-
nication.” [Online]. 
Available:  
[11] “oneM2M Standards for M2M and the Internet of 
Things - Published Specifications.” [Online]. Availa-
ble: 
drafts.