Enhanced Interoperating Mechanism Between OneM2M and OCF Platform Based on Rules Engine and Interworking Proxy in Heterogeneous IoT Networks

In recent years, the Internet of Things (IoT) is growing rapidly and is being applied in a variety of industries including healthcare, smart homes, and smart cities. Many standard IoT platforms are proposed to connect and communicate with IoT devices easily and securely such as oneM2M, Google Weave and Apple HomeKit. However, this makes IoT application development difficult as it requires IoT devices and applications to support multiple protocols to connect different IoT platforms. Therefore, it is necessary to provide a consistent schema to support interoperability in heterogeneous IoT networks. In this paper, we propose how to design and implement interoperating schema between two edge servers oneM2M and Open Connectivity Foundation (OCF) with heterogeneous IoT devices. Specifically, we build proxies for bridging oneM2M Mobius edge server and OCF IoTivity edge server. The sensor data is collected from various IoT devices and sent to an edge server with a compatible platform. Next, the data stored in each server will be exchanged with the other server through a proposed interworking proxy. We also use a rules engine to automatically identify registered devices to support edge server interaction within the same domain and across domains. In addition, we build a web application in each edge server to provide friendly IoT services (data visualization) to clients from different environments. In order to evaluate our system, we collect the delay time of each process in the edge servers. The results show that our proposal is completely applicable in practice.


I. INTRODUCTION
The term ''Internet of Things'', which Ashton first introduced in 1999, refers to a technical innovation that will change how computers and communications operate in the future [1]. With the advancements in wireless networking The associate editor coordinating the review of this manuscript and approving it for publication was Chien-Ming Chen .
(Wifi, Bluetooth, etc), cellular networks, and the increase in the number of electronic devices (smartphones, etc), objects all over the world can now interact with one another and share information about their data, status, and environment information and allowing the objects to collaborate and carry out common tasks without the need for human intervention [2]. Recently, IoT technology has garnered a lot of social attention on a global scale and is the trend in ICT (Information and Communications Technology) [3]. Many proposed IoT platforms enable developers and producers to build innovative products and intelligent services to improve human life [4]. IoT Platforms are software based on standards from organizations to connect various devices (e.g. sensors, access points, data networks) [5]. They enable easy management, development, and operation of IoT applications. Some commonly used IoT platforms are oneM2M [6], OCF [7], and AllSeen Alliance [8], etc.
In 2012, a standards collaboration project called oneM2M was established by standards development organizations from many countries [9]. The main objective of oneM2M is to provide a standardized framework to connect and interact with different IoT devices and provide intelligent services to users, such as Healthcare [10], Smart Home [11], [12], and Smart Car [13]. In order to provide interoperability, oneM2M plays as a distributed Operating System for IoT. It proposes common service functions between applications and connectivity transport [14]. Applications and IoT devices can access oneM2M's common service functions through RESTful APIs [15]. Besides, semantic technologies on the Web (Semantic Web of Things) are developed to describe and analyze the oneM2M resources [16]. Currently, popular platform software resources that developers can access to try out and build end-to-end IoT systems using oneM2M standards such as OCEAN [17], ACME [18], OASIS SI [19].
The OCF standard is developed by Open Connectivity Foundation which is one of the largest IoT standard organizations with over 500 members [20]. Similarly to oneM2M, the target of the OCF standard is to build a common service platform to make it easier for developers to deal with the complexity of IoT connectivity. It ensures interoperability trust and secure communication between IP-connected IoT devices and services. Besides, the OCF standard also supports various transport protocols (e.g. Wi-Fi, Bluetooth, ZigBee) to interconnect different IoT devices and provides a common resource model that developers can use to interface with all IoT devices and data [21]. Additionally, OCF supports both IPv4 and IPv6. In the core functions in OCF, it uses CoAP [22] protocol to message and discovery in combination with RESTful design and API expose [23]. CoAP is an application protocol created by Internet Engineering Task Force (IETF) that is used for supporting constrained devices. Some popular open source platforms implement OCF standard such as IoTivity [24], plgd [25].
As described before, there are now many platforms with various standards to support interaction with devices in IoT networks. However, each platform has its own way of managing and communicating with IoT devices. Furthermore, with the increasing number of devices in different environments, some devices only conform to certain standards. The connection and interaction with heterogeneous devices and platforms become a challenge in IoT systems [26]. For example, sensors are often placed in the edge environment (usually embedded inside low-power, wireless nodes). They gather data from their immediate environment and produce usable information for IoT services. However, because most IoT businesses use proprietary systems, it can be challenging for an IoT system in a certain industry (like smart homes) to gain sensor data from other fields (e.g. smart healthcare). Therefore, it is important to identify each sensor device and communicate and share data between different IoT platforms [27]. To solve this, it is important to provide a consistent schema to support interoperability in heterogeneous IoT networks.
In this paper, we propose a schema for interoperating between two edge servers (with oneM2M and OCF platforms). Specifically, we build an IoT proxy with the rules engine in each edge server as a bridge to recognize different IoT platforms and exchange data between platforms and devices. Edge servers are built on top of Mobius and IoTivity which are frameworks developed according to oneM2M and OCF standards respectively. Edge servers are connected to IoT devices with compatible platforms to collect data from sensors (temperature, humidity, and dust sensors). Then, the proxy in each server will process, and create a message to deliver data to the other server. In addition, we also build a Django-based web application that allows users to view the data collected from sensors in edge servers. Our proposed system's contribution can be summarized as follows: 1) Developing a mechanism to connect edge servers with IoT devices based on oneM2M and OCF standards. 2) Designing and implementing interoperating system between oneM2M Mobius and OCF IoTivity edge servers. 3) Deploying a web application in each edge server that allows users to monitor the historical data of sensors through visualization. The remainder of this paper is structured as follows. In Section II, we introduce related works including oneM2M Mobius and OCF IoTivity platform, rules engine, proxy, and studies of interoperability in heterogeneous IoT networks. Section III describes our proposed system and detail the components in each edge server. In Section IV, we introduce the environment and the implementation of our proposed system. The performance evaluation for delay time in each process and comparing them in two edge servers are presented in Section V. Finally, Section VI concludes this paper and presents our future works.

II. RELATED WORK
IoT Platforms based on standards enable developers to distribute applications, connect and manage securely sensor devices from the environment in many industries [28]. OCEAN is one of the IoT platforms based on oneM2M standards. It provides two versions for supporting servers and devices, Mobius and nCube respectively [4]. As oneM2M specifies, Mobius acts as a middleware server platform that provides common services functions and connects diverse IoT devices including oneM2M and non-oneM2M devices [29]. nCube is a device platform based on oneM2M VOLUME 11, 2023 standard for supporting interworking between device and server. Implementing Java language, it can run on most embedded devices through Java runtime virtual machine. Besides, nCube is suitable for resource-limited devices or devices in heterogeneous environments [30]. Mobius and nCube are popular oneM2M platforms for servers and devices that have been extensively researched, developed, and applied in many industries. In [31], Yun et al. developed middleware software based on the nCube platform to support different sensors and actuators. Sensor values and actuator commands are transformed into oneM2M resources by the nCube platform. Thereby, the authors developed an Android application that can access and control sensors and actuators through REST APIs based on the oneM2M standard. Lee et al. [32] proposed an architecture to integrate Hololens, a Mixed Reality device into the Mobius platform. In this way, it gives users an intuitive and simple experience without major configuration changes in different domains. In [33], the authors implemented an IoT system based on Mobius for interacting with old consumer products (Nest thermostat, Withings blood pressure monitor, etc). By mapping device information to oneM2M resource tree, an IoT application can access and control legacy devices even if they are non-oneM2M devices. In [34], Choi et al. proposed a real-time data distribution system with oneM2M platform using Mobius to be implemented in the management system of UAVs. According to experimental results, this system enhances delay performance across a range of network environments. In [35], the authors developed wearable IoT Android software based on Mobius to gather biosignal data. The resulting biosignal data will be used to analyze and predict emotions (recognize two emotions of joy and sadness). Um et al. [36] proposed a containerbased smart factory system with oneM2M standard. It provides a common standard environment that helps manufacturers reduce errors between different devices. Besides, it offers the benefit of easy version control and is simple to distribute and apply via the Docker registry.
As for the OCF standard, IoTivity [24] is the most popular platform developed by the OCF organization itself. As an open-source project, it provides intelligent functions to support device-to-device and device-to-server connectivity. It supports many different connections (e.g. Ethernet, NFC, Wifi) and can run on various OS (e.g. Windows, Linux, Arduino, and so on). In order to design, deploy, and control IoT systems based on the IoTivity platform, a lot of research was conducted. In [37], Lee et al. developed an IoTivity application to collect data from healthcare sensors on the human body. Data is sent to the server via Bluetooth Low Energy (BLE) and organized to the resource model of the OCF standard. Mandza and Raji [38] designed a home energy management system using the IoTivity-Lite platform (a lighter version of IoTivity for constrained devices). It is suitable for older devices and it is cost-effective and easy to scalability. In [39], Doan et al. developed a software called RES-Hub based on the IoTivity framework to maintain services to IoT home devices when the connection between cloud and home devices is unavailable. With IoTivity, RES-Hub ensures secure access and control of devices. In [40], the authors designed a smart farm system using the IoTivity framework. Sensor data and actuator commands are aggregated to the edge server via CoAP. The edge server will analyze sensor data and give the actuators the next action.
The rules engine in IoT is a system to analyze collected data and takes specific action if they satisfy a necessary condition. It first receives data from IoT devices. It then runs logical analyzes formatted as an ''if-then'' statement and takes further action based on the results of the analysis. It can make it easy to model the logic of complex systems and help users to adjust the logic of the system without any coding experience [41]. The rules engine helps IoT systems automatically make decisions and control the flow when receiving enormous amounts of data from sensors or actuators. Nowadays, there are many tools that support the rules engine in IoT platforms: Drools [42], eKuiper [43], Jess [44], etc. Drools is a rules engine tool that implements knowledge-based systems using the rule-based methodology. The knowledge-based systems are systems that use knowledge representation to perform complex tasks in different environments. Users can build rules through DRL (Drools Rule Languages) files. DRL files contain rules defined by conditions (with the ''when'' keyword) and actions (with the ''then'' keyword). In [45], Luo et al. designed a Drools-based rules engine system that can perform large-scale triggeraction tasks in IoT environments. Besides, they designed an algorithm to find and delete conflicted rules registered by users. The results demonstrated that their method is optimal in terms of energy consumption and system delay time. In [46], the authors implemented a tool called TrigGen to optimize the number of rules in Drools. Experiments showed that TrigGen has optimized more than 80% of the rules written by users.
According to the previous section, it is challenging to recognize each heterogeneous IoT device or communicate and share data between different IoT platforms. Tao et al. [47] proposed to manage data from different IoT platforms using the public cloud. They design a data management system for heterogeneous devices by utilizing ontology representation in the public cloud. However, not most platforms can use the cloud, and constant retrieval of the cloud is also a challenge for constrained devices. Koo and Kim [48] focused on device ID interoperability in IoT platforms. They proposed a device ID translator to translate diverse types of ID into oneM2M format. It can easily translate the IDs of the platforms that have a similar structure to the oneM2M ID format. However, with other formats like OCF IoTivity, it will cause a lack of necessary parts in the oneM2M format. In this [49], the authors proposed an IoT Smart Hub to aggregate data from heterogenous devices and map data format into a predefined common resource format. Thus, applications can access and interact with data through a common resource format.  However, it requires a predefined format suitable for all resource formats of different platforms.
Previous related works have often studied interactions between heterogeneous devices and servers or end-user applications. In our research, we focus on studying the interworking between two heterogeneous edge servers (oneM2M and OCF servers) as well as designing the interaction mechanism between the server and the IoT devices. The details of our proposed method are described in section III.

III. PROPOSED INTEROPERATING MECHANISM BETWEEN oneM2M AND OCF PLATFORM BASED ON RULES ENGINE AND PROXY
In this section, we introduce our proposed architecture based on the interworking proxy and rules engine and discuss the details components of each edge server.
A. PROPOSAL ARCHITECTURE FOR IoT SYSTEM Figure 1 depicts our proposed architecture to provide interoperability between IoT devices, edge servers, and clients. The proposal comprises three sensors (dust sensor SDS011, humidity sensor DHT11, and temperature sensor BMP280). They are connected to two IoT devices to measure in two different places. IoT devices are deployed in the local environment and based on nCube and IoTivity platforms. IoT devices collect data from sensors through web services. Specifically, we build a Flask application in each device to collect data from sensors. Each device is linked to each compatible edge server. The oneM2M edge server connects to nCube device whereas the OCF edge server connects to IoTivity device.
The main components of edge servers include an IoT platform (Mobius for oneM2M server and IoTivity for OCF server), interworking proxy, rules engine, and web services. The nCube device sends data to Mobius in oneM2M edge server through HTTP protocol and IoTivity device sends data to OCF edge server through CoAP protocol. The rules engine in each edge server provides inference ability based on registered rules to perform different actions when receiving data from different sources. Proxy support to translate messages and deliver them to the other server via HTTP and CoAP protocol. As shown in figure 1, the oneM2M edge server uses a proxy to translate messages containing data collected from the nCube device and send them to the OCF edge server via CoAP. Proxy in OCF edge server works with similar functions. Finally, web services in each edge server allow clients to access and track the environmental data.
From figure 1, we have two directions of data flow for each edge server. Figure 2 shows a sequence diagram for getting dust and humidity data from nCube device and distributing them to edge servers. Firstly, nCube device gets data from the dust sensor and humidity sensor through the Flask application. Then, the nCube device acts as MQTT Publisher and sends data to Mobius by HTTP Protocol. Sensors data will be stored in MySQL database and the message will be sent to the rules engine in oneM2M edge server. Based on registered rules, action will be triggered and it will send a request to oneM2M proxy. OneM2M proxy will create an OCF message with sensor data and send it to the OCF edge server via CoAP protocol. With registered rules, the OCF edge server will verify data and store it in the MySQL database.
Similarly, figure 3 depicts a sequence diagram for getting temperature data from the IoTivity device and distributing them to oneM2M and OCF edge servers. Firstly, the IoTivity device will get data from the temperature sensor and send it to the OCF edge server through the CoAP protocol. Next, the OCF edge server will store it in the MySQL database. Then, it will create an oneM2M message and send temperature data to Mobius in the oneM2M edge server via HTTP protocol. Mobius will store data to MySQL database in oneM2M edge server.   In the device layer, IoT devices collect sensor data from the local environment. Event management is used to create events (including data and device information) and publish them to the edge server. Built from IoT platforms, IoT resources provide services for communicating to edge servers secure, easy to manage, and track in real-time.
The edge layer contains oneM2M and OCF edge servers that are used for receiving and distributing sensor data. Each edge server includes a database for data storage and retrieval. An interworking proxy is in the edge server for connecting and sharing sensor data with other edge servers. The rules engine in the edge server is used to make automatic rules for recognizing IoT devices and handling sensor data.  Besides, each edge server provides client service to allow clients can access and track data.
The client service in the client layer is used to provide historical data to the clients through web applications. Web client service includes User Interface (UI) and data visualization. Using UI, data visualization is provided to display updated and historical values from the sensor.

B. ONEM2M EDGE SERVER ARCHITECTURE ANALYSIS
The oneM2M edge server includes Mobius platform, Droolsbased rules engine, oneM2M proxy, and web application. Figure 5 depicts in detail the main components of Mobius, rules engine, and proxy in oneM2M edge server and data distribution from nCube device.
Mobius provides internal servers to support various data transfer protocols including HTTP, CoAP, MQTT, and Web-Socket. In order to communicate with nCube device, we use an HTTP Mobius server with the default HTTP protocol in our design. Moreover, the MQTT proxy is used to convert HTTP to MQTT protocol for Publish/Subscribe (Pub/Sub) messaging. After receiving the message from nCube device, HTTP Mobius server will handle and store sensor data to the MySQL database. At the same time, the MQTT proxy will translate the message to MQTT protocol. After that, MQTT message will be published to MQTT Broker server. MQTT Broker will filter messages based on topic and then distribute them to subscribers. With Pub/Sub messaging, it announces event notifications quickly for distributed applications. The rules engine in oneM2M edge server is developed by Drools framework. In our system, the rules engine subscribes to all topics in MQTT Broker. Therefore, it receives all event messages whenever MQTT Broker publishes them. The Drools rules engine uses rules to take action when data is delivered from different sources. If data comes from nCube device, it needs to be shared with OCF edge server. After confirming the data is coming from the nCube device, the event handler component in the rules engine will handle the MQTT message and send it to the action handler in oneM2M proxy.
OneM2M proxy consists of two main components rule deployer and action handler. The action handler receives the message from the rules engine and translates message from HTTP to CoAP protocol.
Drools rule deployer in proxy is used for registering and updating rules from client. Figure 6 presents the rules registration process from client. When the event message is VOLUME 11, 2023 delivered from client, the rule deployer will handle, transfer message to Drools format and send it to rule engines. Rule controller will get profile of new rules and extract object ID and command ID based on rule template in Drools configuration. Then, the rule controller updates objects and command IDs for condition and action. In our system, the rule will check if the message is coming from nCube device (humidity and dust data) or coming from OCF server (temperature data). Figure 7 depicts detailed components in the OCF edge server and data distribution from the IoTivity device. The main parts of the OCF rule proxy include:

C. OCF EDGE SERVER ARCHITECTURE ANALYSIS
• OCF Rule Deployer: Updates rules from the client. • OCF Rule Server: Stores rules, receives OCF requests and checks requests with the updated rule.
• Action Handler: Do action if the rule is satisfied. Different from oneM2M edge server, we use the rules engine that is integrated with the IoTivity platform. In the OCF rules engine, a rule is divided into components and stored in different resources (i.e. Expression, Action resources). They are linked together to become a complete rule. Similar to oneM2M edge server, the rules in the OCF edge server will check if the message is coming from IoTivity device (temperature data) or coming from oneM2M server (humidity and dust data).
When the OCF edge server receives any messages through the CoAP protocol, OCF Post Handler will handle this message to get the main factors. After that, based on the registered rules in rule resources, Rule Evaluator will evaluate and decide the next action. If the message comes from oneM2M server, it will be stored database directly. Otherwise, if the IoTivity device sends the message, rules will be triggered and Action Handler will handle, convert the message to oneM2M format and send it to the oneM2M edge server. Figure 8 presents the rules registration process from the client to OCF rules engine. Rule information will be split and stored in Rule Expression and Rule Action resources. Rule Expression Resource (with resource type id ''oic.r.rule.expression'') contains logical expressions which evaluate a boolean value. Rule Action Resource (with resource type id ''oic.r.rule.action'') contains the action to be taken. When a message with sensor data arrives, the Rule Evaluator will trigger actions in the Rule Action Resource if the logical expressions in the Rule Expression Resource return true. Table 1 shows the detailed development specification of the environment in edge servers. In our proposed solution, both edge servers (oneM2M and OCF servers) use the same hardware configuration. We use the Ubuntu 20.04 with 100GB hard disk, 8GB memory, and an Intel core i5-9500 CPU desktop for each edge server. To build the web application, we use the Django framework with Python, HTML5, CSS3, and JavaScript. JQuery and Bootstrap libraries are used to design the front-end of the website. We use Java with Spring Boot framework to implement proxy and rules engine. The oneM2M server uses Mobius based on the oneM2M standard and the OCF server uses IoTivity based on the OCF standard and both of them use the MySQL database. Drools framework is used in oneM2M server to provide rules-based service scenarios whereas the OCF server uses rules resources in IoTivity. Table 2 shows the development environment in IoT devices. We use Raspberry Pi 4 with Ubuntu 20.04 64-bit, Quad Core 15GHz 64-bit CPU, 4GB Memory, and 32GB MicroSD Card as the IoT device to collect data. Both devices use Python with Flask framework to connect to sensors.    We use Visual Studio Code to develop applications. One device uses the IoTivity framework (called IoTivity device) to connect to the OCF edge server and the other uses the nCube framework (called nCube device) to connect to the oneM2M edge server. Figure 9 presents the photos of sensors; (a) dust sensor (SDS011), (b) temperature/pressure sensor (BMP280) and (c) temperature/humidity sensor (DHT11). Table 3 shows output of sensors in our implementation. Figure 10 describes IoT devices with sensors in our implementation work; (a) nCube device connects to humidity and   Figure 11 shows the device information config in nCube device to register to oneM2M server. The oneM2M standard APIs used a resource-based data model to perform CRUD request operations on the target resource. This figure shows the resource structure of oneM2M services. Common Service Entity (<CSE>) has multiple <AE> (application entity), but one <AE> has to be under one. A <CSEBase> resource represents a CSE and serves as the root resource for all resources that are residing in the CSE. An <AE> resource represents an Application Entity that is registered to a CSE. An <AE> resource supports attributes such as identifiers, contact information, status, and capabilities of the Application Entity. Each <AE> can have multiple <container> indicating the data inside that <AE>. Containers describe attributes of the data and child resources. Each <container> has one <contentInstance> which represents a data instance and one <subscription> contains subscription information for its ''subscribed-to'' resource. In our work, we use Common Service Entity (<CSE>) as the Mobius server. Application object (<AE>) is the name of nCube device is ''device01''. The application data resource is collected from sensors. VOLUME 11, 2023 Figure 12 shows the registered rule in the oneM2M server from the client. The Drools rule profile is stored in a rule controller in the rules engine. When receiving data from nCube device (device name is ''device01''), send data to the Action method. The Action method will create an OCF message and send data to OCF edge server. If the rule is not satisfied (device name is not ''device01'') and the device is registered, data will be stored in the MySQL database and not trigger the Action method. Figure 13 presents rule registration in the OCF edge server. Rule Evaluator evaluates received messages, and identifies key elements in the message (i.e. device name, data). The logical expression in the Rule Expression Resource includes checking whether the message is coming from the IoTivity device (''device02'') or coming from the oneM2M edge server (''server01'') and checking if the data is available. Action in the Rule Action Resource includes the address to send data to Action Handler to perform the next step. Figure 14 depicts the simplified flow of a web request from a visitor's browser to the Django service in the edge server and back. Both edge servers use the same template and design for web services. Clients send a request to the web server through the interface in the web browser. Then, the web server will access to MySQL database and respond to client history sensor data. Figure 15 presents the interface of web service in the oneM2M edge server (the same interface in the OCF edge server). It provides the data visualization function when customers want to monitor the data collected from sensors.

V. PERFORMANCE EVALUATION
In order to evaluate the performance of our proposed system, we collected the time delay of all processes between devices,   edge servers, and clients including sending data from IoT devices, exchanging data between two servers, and accessing data visualization through the Web application. Figure 17 presents 6 testing scenarios in our experiment (3 testing processes in each server). Each process is tested 30 times and recorded. Figures 18 and 19 show the results of evaluating the network communication time delay of sending data from devices to edge servers. In Figure 18, the time delay when sending sensor data from the nCube device to the oneM2M edge server range from 52 ms to 65.4 ms. Whereas, figure 19 shows that the connection time delays between the IoTivity device and the OCF edge server are between 70 ms to 90 ms. Figures 20 and 21 present the results of evaluating the time delays of exchanging data between two edge servers. When sharing data from the oneM2M edge server to the OCF edge server, the time delays are between 12 ms and 38 ms as shown in figure 20. In figure 21, the delays range from 10 ms to 33 ms in sharing data from OCF edge server to oneM2M edge server. Figures 22 and 23 present the results of evaluating the network communication time delays for accessing data visualization through the oneM2M Web service and OCF    Web service. Figure 22 shows the delays in accessing oneM2M Web service are between 122.43 ms to 166.42 ms. Whereas, the time delays of accessing OCF Web service are between 117.39 ms and 172.08 ms in figure 23. Figure 24 describes the average time delay comparisons between the oneM2M edge server and the OCF edge server. The average time delays of oneM2M in each process are 65.4 ms, 20.04 ms, and 145.63 ms while the results of OCF sever are 80.07 ms, 20.01 ms, and 144.46 ms respectively. We can see that the time delays in the processes of the two edge servers are almost the same.

VI. CONCLUSION
Nowadays, with the development of IoT technologies, there are numerous IoT platforms in development. However, each platform has its own way of managing and communicating with IoT devices. In this paper, we propose a schema for interoperating between oneM2M Mobius and OCF IoTivity platform. The goal is that they can connect and exchange sensor data with each other. To solve this, we use a proxy with the rules engine to operate the process. Edge servers are connected to IoT devices with compatible platforms to collect data from sensors. Then, the proxy in each server will process, and create a message to exchange data with the other server. Besides, we also built a Django web application to provide services that allow clients can view sensor data (dust, temperature, and humidity sensors). Our experimental results show proposed system is suitable for real-world applications.
In the future, we plan to extend our research to integrate other IoT platforms such as AllJoyn, Google Weave, and Apple HomeKit. In addition, we will research to improve delay time when exchanging data between platforms.