Resource Management Based on OCF for Device Self-Registration and Status Detection in IoT Networks

: Recently, there are heterogeneous devices that connect to the Internet to provide ubiquitous and intelligent services based on sensors and actuators in the network of the Internet of Things (IoT). The resources of IoT represent the physical entities on the Internet to expose functions through services. Resource management is necessary to enable a massive amount of IoT-connected devices to be discoverable and accessible in the network of IoT. In this paper, we propose an IoT resource management to provide schemes of device self-registration and status detection for devices based on the Open Connectivity Foundation (OCF) standard. This device self-registration scheme is based on an agent that is proposed for registering devices itself which deployed in the OCF network. The devices host the OCF resources to provide IoT services such as sensing and controlling through the sensors and actuators. For a group of devices, an agent-based self-registration is proposed to register the resources. Through the proposed self-registration, the information of IoT devices is published using proﬁle and saved in the management platform that enables the clients to discover the resources and access the services. For accessing the IoT resources in the OCF network, an interworking proxy is proposed to support the communications between web clients and devices over Hypertext Transfer Protocol (HTTP) and Constrained Application Protocol (CoAP) based on OCF. Furthermore, through the interoperability of the resources using the registered information, a real-time monitoring scheme is proposed based on periodic request and response for the status detection of deployed devices.


Introduction
The Internet of Thing (IoT) is comprised of a massive amount of connected devices that provide smart and ubiquitous services based on sensors and actuators in the heterogeneous network environment. Recently, with the development of IoT technologies including networking, computation, and storage, the number of connected devices is increasing rapidly and will reach 20.4 billion by 2020 [1]. Many IoT devices are developed for the constrained environment using limited power supply, processing and storage capability, and network communication range [2]. In order to interact with these devices through a local network or the Internet, the services need to be available, which are provided by the devices. Through these services, clients can get the sensing data of the environment using sensors and control the actuators to change the environment where the devices are deployed. Although, these devices shall provide seamless services to the users through the system interoperability in IoT networks, such as smart homes, hospitals, and other smart spaces. Nevertheless, the management functionalities are required for the good interoperability of devices using these services, such as monitoring the environment and devices, registering information of devices for The rest of the paper is structured as follows. Section 2 introduces the related works regarding the management schemes in the standard IoT frameworks. Section 3 presents the proposed IoT resource management including self-registration, discovery and access, and status detection scheme. Section 4 presents the implementation results for the proposed IoT network based on OCF. Section 5 presents the performance evaluation based on the implementations for the registration, discovery, service access, and interworking. Finally, this paper is concluded in Section 6.

Related Works
The need for IoT management plays an integral role in the IoT paradigm due to the fact that networks are becoming more and more distributed and thus the deployment of numerous heterogeneous nodes needs to happen ubiquitously. Recently, based on IoT networks, devices have been deployed to provide sensing and actuating services in various industries such as manufacturing, supply chains, energy, healthcare, and the automotive industry [15][16][17]. To manage these IoT devices in the above industries, many platforms are published to standardize the development environment [18]. The traditional management solutions are used for supporting remote control to the specific type of electronic devices, such as surveillance cameras, printers, personal computers, and other network-connected devices [19]. However, for IoT networks, the solutions are not sufficient to support the feature of IoT such as heterogeneity, constraints, and data collection from the environment. In order to support the IoT environment, a number of standards have been published to provide guidance and implementations such as Open Mobile Alliance (OMA), oneM2M, and OCF [20][21][22].
The OMA is an international standard organization for mobile communications that provides a Device Management (DM) specification for managing mobile devices [23]. The implementation of OMA is the Lightweight M2M (LWM2M), which supports the client and server communicate with each other through the LWM2M protocol based on the CoAP for low power and constrained devices [24]. OMA DM is used for management of devices using the request and response transaction model through the client and server in the OMA entity that enables the management commands to be executed on OMA nodes. In the implementation of OMA DM based on LWM2M, the main functions are bootstrap, device discovery and registration, device management and service enablement, and information reporting [25]. International IoT standard organizations, such as the European Telecommunications Standards Institute (ETSI) and oneM2M, have adopted the use of LWM2M as part of their IoT frameworks for the management of the IoT nodes [26,27]. The ETSI M2M functional architecture defines a remote entity management service for the device management based on the OMA DM which supports configuration, performance monitoring, and fault management. The fault management in the ETSI M2M that provides fault-related statistics such as memory failures and unreachable communications. However, the LWM2M is not optimized for a diversity of IoT applications such as limited resources of wireless sensor devices, distributed network environment, massive data collected from a variety of applications based on multiple communication protocols, etc.
The oneM2M is a scalable and interoperable IoT platform that provides functions for data exchange among IoT application in various industries [28]. The discovery function is a fundamental requirement in the oneM2M standard which has proposed discovery as a common service function (CSF) residing in the Common Service Entity (CSE) [29]. The CSE is a component of oneM2M that provides CSFs including communication management, data management, device management, group management, discovery, registration and security. The entities of the oneM2M-based IoT network can request to the CSE for registration. Once the information is registered, the information can be searched including the attributes and resources based on text-matching mechanisms. For interworking with other frameworks, oneM2M enables the features with other local network technologies including legacy deployments of IoT systems. An IoT gateway centric architecture is proposed to provide novel M2M services based on the oneM2M for discovery and interworking proxy with devices [30].
OCF supports a standard framework for developing an IoT network on various software platforms such as Linux, Tizen, Android, Windows, and iOS [31]. OCF is expandable to adopt any transport protocols such as Wi-Fi, Bluetooth, Bluetooth Low Energy (BLE), ZigBee, and Ethernet. According to the core specification, CoAP is the default protocol to provide services based on the REST APIs for communications between OCF entities in an OCF-based IoT network. CoAP is an application protocol based on the User Datagram Protocol (UDP) that is used for Machine to Machine (M2M) communications to support the constrained environment [32]. The IoTivity is an open source framework for the OCF specifications, which can be built as a library to be included in the IoT device application for implementing the role of client and server [33,34]. The functionalities of OCF which are supported through the interactions including messaging, discovery, monitoring, and maintenance based on the fundamental communication ability over the OCF protocol. Device management in OCF that includes functionalities of diagnostics and maintenance. Once diagnostics and maintenance are supported by an OCF device, the resource "/oic/mnt" shall be supported to provide factory reset, reboot, and response of error code. Instead of the resource "/oic/mnt", we present a scheme to enable real-time interaction with a resource to detect the status of an OCF device.
For service management in the SOA-based IoT systems, the Arrowhead framework is proposed to support efficient development and operation of interconnected, cooperative systems [35]. The core services of Arrowhead framework are divided by information assurance services, information infrastructure services, and system management services. Through these services, the framework provides service registration, service discovery, security, authentication, and orchestration of complex services in a local cloud [36,37]. In an IoT network, sensing and actuating services are provided resources within a server of a physical device that is accessible through a wired or wired network. For IoT devices, the Arrowhead framework can provide the device registration through its service registry to enable accessibility of devices [38]. The Arrowhead framework requires every service to be registered to the service registry in a local cloud. The implementation of the service registry is based on a DNS-SD [39]. However, REST APIs are the communication architecture for accessing services including registration, discovery, and interoperability [40]. The interoperability scheme of the Arrowhead framework provides a protocol translation service to support different protocols for information exchange technologies.
Providing interoperability to heterogeneous IoT devices in physical networks is important. In constrained IoT environment, trust management requires keeping the trust information for a huge number of heterogeneous devices [41]. The resource of IoT devices in a network, P2P technology can be used for distributed IoT resource management [42]. In SOA-based IoT systems, each device is a service consumer as well as a service provider through compatible service APIs. OCF is implemented based on CoAP and provides services through RESTful APIs for an SOA-based system. Therefore, interoperability with other solutions can be flexible [43]. For the registration and discovery of OCF devices, a resource directory can be used to provide a consistent interface [44]. A consistent registration scheme enables heterogeneous IoT devices can be registered to the resource directory and discovered by clients for being accessed [45]. The proposed self-registration scheme is used for OCF devices. Nevertheless, the scheme can be applied to other protocol-based devices in a constrained IoT network. Therefore, the resource directory can be a service registry in an SOA based IoT system to provide storage for registering the device and resource information. For the interoperability with the IoT network, Internet clients need the proxy to access these constrained devices [46]. A proxy-based middleware can be used for enabling communications between different protocols [47]. Integrating the proxy to a resource directory can be a suitable solution to manage IoT devices in constrained networks.
For constrained IoT networks, supplying sufficient energy to fulfill the service quality of IoT devices is important. Mostly, the IoT devices are battery powered with limited resources. Therefore, improving the energy efficiency of IoT devices is mandatory. Several methods have been proposed including communication-based energy saving using novel protocols [48,49], applying a sleep-wake schedule to achieve energy saving [50,51] and energy harvesting from ambient sources to increase battery life [52]. In order to enable IoT device sustainably except battery replacement, energy harvesting solutions support sufficient power based on renewable energy resources [53]. Radio frequency is a signal that carries information as well as delivers energy to a device for providing controllable and sustainable power supply [54]. For managing IoT devices, status detection through real-time monitoring is necessary to acquire information about device status in a constrained environment. A management server can be used for detecting the status including power and faults, and based on the detection to apply solutions it can perform other functions such as energy delivering, issue reports, and commands.

Proposed IoT Resource Management Based on OCF
An IoT network is comprised of heterogeneous entities that provide services based on transferring the data through communications. The IoT devices in the network provide services based on sensors and actuators for interacting with the environment where the devices are deployed [55]. Users can monitor the environment through the presented information of resources which are hosted on the devices to provide services. These devices are developed for the constrained environment in the edge of the IoT network to update the environment ubiquitously [56]. In this network, for sufficient computation and storage, the high-performance servers are required to support these constrained devices. The management functionalities shall be implemented on the server to provide the sufficient hardware environment for storing information and presenting information to the mass of users. Figure 1 presents the IoT architecture that includes clients, IoT platform, IoT device, and IoT agent for the proposed resource management. The IoT device and IoT agent are deployed in the local network where can be the smart space for providing user-specific services based on the constrained environment. In this network, IoT devices and IoT agent host the resources to provide IoT services. The IoT devices can be assumed to have the sensors and actuators on the board directly. The IoT agent can be assumed to interact with sensor devices through a network protocol for bridging the sensing data from the sensor devices to clients. From the perspective of clients in the local network, the resources of the IoT device and IoT agent provide transparent access to the sensors and actuators. In order to be discovered in the IoT network, the information of resources needs to be uploaded to the IoT platform. Once the resource information of IoT nodes for the entities of the IoT device and IoT agent from the local network are sent to the IoT platform and saved in the database, the clients can retrieve the information to discover the resources using consistent interface in the Internet. Through the information of discovered resources, clients can access the services not only accessing directly in the same network but also accessing based on the proxy in the IoT platform. The proxy-based request to the IoT nodes is supported by the IoT platform as a function through forwarding the request in this model. For supporting interworking between different networks, the message converter is an important module to translate packets of different protocols.

IoT Resource Self-Registration Using Profile
The proposed IoT network is based on an OCF framework that supports solutions for IoT networks through the integrated specification. As an OCF entity, the IoT device and IoT agent include the OCF client to communicate with the OCF server of IoT server in the IoT platform for publishing the information of devices in the local network. A self-registration scheme is proposed to publish the information of devices for registering to the IoT network. Figure 2 shows the self-registration scheme for registering the IoT devices using profiles which include the information of devices. The IoT platform is a server that provides services to enable the registration of IoT device and IoT agent. The registration service of the IoT platform enables IoT devices to be represented in the IoT network for being discovered by clients through the discovery service. In the IoT network, the devices and agent send the data to the IoT platform. Through the registration interface, the data is uploaded and saved in the storage of the IoT platform. According to the self-registration process, once an IoT device is started, the profile is configured and published to the IoT platform. A profile involves the information of a device including a list of resource details. The profile is formatted by JSON to be stored in a JSON file that can be easily parsed by the software in the IoT server. The profile includes the information of each IoT device that presents the information of resources as well as the device information. Based on the profile, the IoT platform exposes the accessible RESTful APIs to represent the OCF resources in the Internet. The IoT agent is used for registering the devices which only provide services without the ability of registration using OCF client. For example, in a constrained environment, some devices are equipped with sensors and communicate through the BLE. The main task for these devices is collecting sensing data. Therefore, the IoT agent as a bridge to provide the registration function for supporting functionalities of management. Figure 3 presents the model of IoT configuration based on self-registration through an OCF network using the OCF framework. The IoT device is comprised of the IoT device application, profile, and sensors. The sensors are connected to the main board of the IoT device for supporting the sensing data. The application collects the sensing data through the sensor driver to use the data for providing sensing services by the OCF resources in the OCF server. The profile is used for publishing to the IoT server by the OCF client to register the information on the IoT platform. The registered information exposes the specification to the Internet for enabling the clients to access the resources in the IoT device. Additionally, the IoT agent is the device that is used for bridging the sensor devices to the system. The sensor devices can be deployed in the private network; therefore, the accessing to the network is allowed by requesting the OCF resources in the IoT agent. The resources of the IoT agent are mapped to the services which are provided by the sensor devices. Therefore, the profile of the IoT agent includes the information of resources in the IoT agent. However, requesting resources can acquire the sensing data that is provided by the sensor network where the sensor devices are deployed. The IoT platform includes the IoT server and database for the registration of IoT nodes, such as the IoT device and IoT agent which are deployed in the IoT network. The IoT server is a high-performance device which has sufficient computing ability to handle the requests from the clients and IoT nodes. The database is used for saving the information of IoT nodes and sensing data that is collected from the environment. The IoT server application includes the OCF server to handle the OCF request by the resource /oic/rd. The resource handles the request for the registration of the IoT node that involves the profile data in the payload of OCF request. Figure 4 shows the sequence diagram for the proposed self-registration process based on the interaction of IoT node and IoT server. The IoT node has a file for its profile using a JSON format. The file is used for describing the information of endpoints to access by the client in the IoT network based on the OCF framework. In the proposed OCF network, the IoT node is an OCF client for the registration process; the node is required to do self-configuration in the onboard step. The IoT node can be deployed a space and powered by a battery to enable the tasks without human touch. The registration process can also be done by itself through preconfigured rules and parameters in the application. The first step, the IoT node configures the local parameters for the communications and status to understand the current environment. Through the parameters, the node prepares the OCF communication setups, including registering the OCF resource to the OCF server to provide OCF servers and generate the OCF client for requesting the IoT server for publishing profile data. The profile data is saved in profile.json, which is a file in the IoT node. The administrator can manage this file to configure the IoT node in the system. Once the IoT node is started, the node reads the file to generate the OCF payload for publishing to the IoT server. The contents of the profile that may have a big size of data which depends on the count of resources in the OCF server to provide services. The request to the IoT server cannot include contents in the payload that are too big. Therefore, The OCF client needs to send profile data separately. In the proposed registration process, if the size of the contents is bigger than the limited size, then the contents need to be separated and put in the payload with parameters. The publishing request is comprised of the POST method with the OCF message based on CoAP. The separated contents are sent by multiple requests and saved in the temporary value objects in the memory storage until all contents are sent. Once the contents are sent to the IoT server, the IoT server sorts the contents by sequence number and combines the multiple contents to a single profile. If the size is sufficient for the payload, then the contents can be sent by message. The publishing request is comprised of URI coap://{ip:5683}/oic/rd?rt =oic.wk.rdpub, which refers to the OCF specification document. The payload of the request includes the setup parameters which are generated for the separated contents or includes the initial parameters which are generated for the profile data that is sufficient to the limited size. The published profile data shall be inserted to the database and uploaded to the cloud server. Finally, the IoT node gets the acknowledgment for the successful registration process. Figure 5 shows an example of a registration profile that is sent by an IoT node to an IoT server. The profile involves information that is used for representing a physical IoT node to the Internet to be discovered by clients. The structure of profile is based on the OCF core specification that defines a format for registering an OCF node including values of device URI, resource URI, resource type, and resource interface. Through these values, an OCF client can access an OCF resource to acquire sensing data or control an actuator by a handler of the method such as GET, PUT, POST, and DELETE. However, the information of the method is not included in the OCF-suggested profile. The proposed profile includes information which is a minimum requirement for a client to access an IoT node. In the profile, the value of "host" is a device URI that is used with a value of "href" in the JSON list "resourceList". Each item in "resourceList" is used for building an OCF request. Based on the parser, a client application presents the information and functions to a user.

IoT Resource Discovery and Accessing
The IoT resources are registered to the IoT platform that includes the IoT server and database for providing the registration service. The published information of IoT resources is saved in the database that enables the client to discover the IoT nodes and access the services which are provided by these IoT nodes. Through the published information, the IoT server registers the information to the IoT platform for configuring these devices in the system.
The uploaded data from the IoT nodes to the IoT platform, that not only the resource information for discovery but also the monitoring data for the resources and environment where the resources are deployed. Through the monitoring data of devices, the status of devices can be detected. Based on the data, the IoT platform provides services to the administrator clients for supporting the management functions. Also, providing services to the user clients who have the right to access the services in this system through user authentication. For supporting the synchronization of the data on the cloud, the IoT platform has a function to upload the data to the cloud; then the users can assess the information from the cloud. Figure 6 shows the discovery model in the proposed IoT network. For the discovery functionality, the IoT platform includes the database to save the information of IoT nodes such as the IoT device and IoT agent, which are deployed in this network to provide IoT services. The database includes tables for saving information of IoT nodes as well as saving status and sending data. For providing the discovery service to the client in the Internet, the web server includes HTTP-based resources in the HTTP server to provide HTTP services to the HTTP client. The presented IoT network is based on the OCF communication between the IoT platform and IoT nodes. However, most of the clients in the Internet that consume the services are the HTTP-based. Therefore, in detail, a web client with a HTTP client is presented in the proposed discovery model. To provide the HTTP-based service, the IoT platform includes the web server that implements the UI resources and Create, Read, Update, Delete (CRUD) resources. The UI resources provide the interface resources to the client application to display the UI to the user. The interface resources can be an interpretable programing language such as HTML, or a data structure using JSON or XML to present the client interface through the parser of a client application. The CRUD resources provide services for supporting the interaction between clients and the database through the reading and writing the data of the database. Therefore, through the interaction with the database, the clients can access the data that is provided by the IoT nodes.
For supporting the interworking between heterogeneous communication protocol-based networks an interworking proxy is required to be included in the proposed IoT platform. The interworking proxy in the IoT platform that provides the interface to access transparently the IoT nodes in the OCF network for the clients in the Internet. For this purpose, the proxy is required to include the HTTP server and the OCF client. Figure 7 shows the interworking model of the proxy in the IoT platform for accessing the IoT nodes to get real-time sensing data. For providing the interfaces to the HTTP client, the IoT server includes an HTTP server. The HTTP server includes an HTTP resource that needs to support the handler for the method of GET, POST, PUT, and DELETE. The handler receives the request message from an HTTP client and sends the response message to the HTTP client. Once the HTTP request message is received by the IoT server to acquire the sensing data from the OCF network, the message converter converts the HTTP message to an OCF message. For converting to the OCF message, the query parameters, and payload of the HTTP message are required to be handled. Through the converter, the proxy generates an OCF message and sends the message using the OCF client to an IoT node which in the OCF network. The IoT node returns the sensing data to the response handler of OCF client. Through the HTTP payload generator, the HTTP server can get the payload for the HTTP response message and returns the response to the HTTP client. The HTTP request message shall be URI http:// {server URI}/ocf?rt={rt}&if={if}&ocf_uri=coap:// {IP}:5683/{resource}{?query} with a payload. The HTTP handler of IoT platform parses the message and gets the URI for requesting the OCF server and generating the OCF payload. The URI of OCF request shall be coap:// {IP}:5683/{resource}{?query} and the payload is an OCF payload.  For storing the information of IoT nodes in the OCF network, the status of these objects and the collected sensing data, the tables t_node, t_resource, t_rt, t_ep, t_if, and t_data are designed and the database is deployed in the IoT platform regarding the designed ERD.  Table t_data is used for storing the sensing data. The attributes of tables t_node and t_resource are used for detecting the operating status of the device and its resources. Device information includes ID, expire time, device name, and multiple resource information; this is a resource which is used for providing a service from an IoT node. For the OCF devices, resource information includes its URI, resource type, interface, policy, and endpoint information. For presenting the device and its resources, the properties di, ttl, name, and links with properties anchor, href, rt, if, p, and eps with properties ep and pri are included in an OCF device information.

Real-Time Status Detection
Using the registered information of devices and information of its resources, the IoT server can access the services of resources. The process can be programmed to run the function periodically and proceeds the data which are returned from the IoT networks. Through the interoperability between the IoT nodes and platform, the IoT server can detect the status of these devices such as low battery, sensors, and network problems. Using the returned information, the IoT server can make real-time status detection. For example, the continuous sensing data presents useless, then, based on the preconfigured rules, the handler can make the diagnostic decision for the sensor that is related to the resource. Figure 9 shows the real-time IoT resources access for the status detection based on a periodic sensing scheme that collects sensing data and status information from the IoT device and agent in the OCF base IoT network. The IoT server interacts with the database in the IoT platform to retrieve information of registered resources and update the status of devices. The thread pool generates the process to handle the request for accessing the resources of the devices which are electronic devices which interact with the environment and provide the services based on the resources. The thread pool retrieves the information of resources from the database and generates the OCF client to access these resources. Through the OCF client in the process that is generated by the thread pool, the handler of the OCF request gets the sensing data and status information from the devices. Once the data is returned from the OCF network, the handler of the OCF client inserts the data to the database.  Figure 10 illustrates a flowchart of status detection based on real-time IoT resource access. Once the IoT server is started in the IoT platform, the server configures the OCF parameters for enabling the OCF communication with the OCF-based local network. Then the thread pool is enabled that includes functions to access the database and OCF devices. Firstly, the thread pool accesses the database to retrieve the registered device list and based on the device list, to retrieve the resource list. The resource information provides values of parameters to construct the OCF resource object for sending a request to an OCF device. For status detection, the thread pool sends the request to the status resource of an OCF device that returns the status information. If the response body is empty, meaning that the resource of the device is unreachable, the status of the device in the database is updated to be 0, otherwise, the status is updated to 1.

Implementation Results
For implementing the proposed system comprised of an IoT server, web server, device, and agent, we configured the development environment as shown in Table 1. The IoT platform is deployed based on an Ubuntu platform that involves the IoT server and web server to provide services to the clients and nodes from the Internet and the OCF-based IoT network. Both servers are deployed in Ubuntu 14.04 64-bit on a high-performance PC based on sufficient storage and stable networking. The HTTP server is implemented based on the Spring Framework 4.3 using the Spring Tool Suit (STS) 3.9.5 development tool. For providing the OCF-based service interfaces, the IoTivity 1.3.1 x86 Java version is built for the Ubuntu operating system. The user interfaces on the client, which are implemented based on jQuery 3.3.1.min. The IoT device is developed on the Raspberry Pi 3 Model B that is installed the Android Things base on Android OS. For providing sensing services, the BMP 280 is connected that is used for collecting temperature and humidity sensing data from the environment. Body temperature sensor is also supported through the Libelium e-Health Kit. The IoTivity version is 1.3.1 for the armeabi architecture and Android OS that is included in the Android Studio to develop the IoT device. The IoT agent is a smartphone that runs Android 7.0 OS on the Samsung Galaxy S6. The IoTivity version is 1.3.1 for the armeabi architecture and Android OS which is the same library with IoT device.  Figure 11 shows the interaction result for self-registration using the profile. The profile is sent by an OCF device which can be an agent as well as an IoT device. The agent and device are developed based on Android that runs the Android application. The profile is a file based on a JSON format that is deployed with the application in the Android platform. The context of the file is inputted by the administrator who manages the IoT environment. Depending on the implementation of OCF resources and functions in the device, the size of the profile is increased or decreased. The formatted structure supports the parser of IoT server to read the information and configure the resources to be registered in the IoT environment.  Figure 12 presents the experimental environment for interactions in the proposed IoT network that is comprised of IoT device, agent, web client, and IoT platform including IoT server and web server. The IoT device is implemented on Raspberry Pi running an Android Things OS to provide connections with sensors, storage, and communications through wireless and wired modes. In this experiment, Ethernet is used to provide network communication for the IoT devices. The smartphone is an Android phone that communicates with IoT devices and IoT server through the Wi-Fi. The network is provided through the Ethernet and Wi-Fi, which are provided by a network router; therefore, these entities are deployed in the same network. The IoT platform is also deployed in the network; however, the port forwarding is configured to expose services of the web server to the Internet. Therefore, the web client can access the IoT services through the web server. Figure 13 shows network packet capture of device registration and periodic sensing data collecting. The URI for registration is /oic/rd and is shown in Figure 13. For accessing the registration service of the server, the device sends the information using OCF over the CoAP. The CoAP is based on UDP, therefore, the figure shows the communication is done by CoAP and UDP. If the registration information is bigger than a limited size, then the message is sent separately to the server as shown in the figure. The rest part shows the process of periodic sensing data collecting. The communications of collecting sensing data are based on OCF, which are used for accessing services of OCF devices. Figure 14 shows the IoT resource discovery and accessing results on the web client. The web client is provided by the web server that is deployed in the IoT platform. Through the network configuration, the services of web server are exposed in the Internet. The web client provides the user-friendly interface to users. The retrieved device list is displayed in the interface that includes the status of devices in the list. The user can retrieve the resource list of a device by clicking the presented button on the web client. The presented information supports the parameters for the request to the web server for retrieving the resource list of the device. For gathering sensing data, the user can send the request through a button that presented on the web client. The information for gathering a sensing data from a sensor resource, the web client provides the parameters of the request. The information is provided by the discovery interface, and is displayed through the web client in a user-friendly manner.

Performance Evaluation
For the performance evaluation of the proposed management model, the processor, memory, and network of the IoT device are monitored using the Android Profiler of the Android Studio to check the performance of monitoring and registration processes. Moreover, the network packet is captured to present the performance for the interaction between the IoT platform and resources in the OCF-based IoT network. CoAP-based communication shows that the packet size is decreased by 87% compared to the size in the case of HTTP-based communication. Figure 15 shows a monitor of registration and sensing data collecting in the OCF device. Once the device sends the registration message to the registration server, the server needs to save the registration information to the database. Then the client can access the server to retrieve the device. The server includes a function that is used for collecting the sensing data from the registered resources of devices in the OCF network. In Figure 15, first, the network data consumption shows the registration process and, second, it shows the recursive sensing data collecting process. The registration process gives rise to a relatively increased cost that by the sensing data collecting process because in the earlier case the packet size is more than the one in a later case. In the process of monitoring, the sensing data collection almost does not consume network cost because the communication is based on the CoAP for the constrained environment.  Figure 16 shows the interaction model of the experiment for requesting the OCF device through the IoT server. The client and IoT server communicate through the HTTP network, and the IoT server and IoT device communicate through the OCF network that is based on the CoAP. In this interaction, we had measured the message size is 589 bytes for the request from the client to the IoT server, and the message size is 233 bytes for the response from the IoT server to the client. In the OCF network, the message size is much smaller than the HTTP network. After translation from the HTTP to OCF, the request message size is 75 bytes. The response message size is 96 bytes from the IoT device.  Figure 17 shows the network packet capture of requesting the OCF device through the IoT server. The capture is separated into (a), (b), and (c). Figure 17a shows the network communication specification for service accessing time, resource, destination, protocol, and length. The message is sent by the HTTP client that is a web browser for gathering the sensing data from the OCF device through the IoT gateway. Therefore, the communication network specification shows HTTP and CoAP in this communication. Figure 17b shows communication information that includes the request method, URI, and HTTP version of the HTTP request, request type, method, ID, token, and URI for the CoAP request. The size of HTTP request message from the client is 589 bytes, and the size of OCF request message is 75 bytes that is converted from the HTTP request message. The size of OCF response message is 96 bytes, and the size of HTTP response message is 233 bytes that is delivered to the client after converted from the OCF payload to the HTTP payload. The network packet capture of HTTP response message that is captured in the IoT server when the HTTP client sends the request message for gathering sensing data from the OCF device through IoT server. The response message size is 233 bytes, and the other information is displayed in the capture. The HTTP is based on TCP, IP, and Ethernet; therefore, the capture shows the details of those protocols. Figure 18 shows the evaluation results for the IoT device registration Round Trip Time (RTT). In this experiment, the profile size of the IoT device is 1605 bytes. The profile is sent to the IoT server separately three times because the file size is too big. We present the evaluation results through the collection of RTT 20 times. The RTTs for each registration is done by the same hardware and network environment. The RTT is collected in the IoT device through the time difference between the time for sending the first request and the time for receiving the last response. The results illustrate the RTTs are taken by between 368 ms and 580 ms, the average is 443 ms, and the standard deviation is 61 ms. The results are great because of the process of packet combination. In the experiment, a device sends its profile by three separate packets. Therefore, the process time also includes the communication time of packet transfer. However, the proposed self-registration scheme enables a great size of the profile to be published by the constrained devices.

Conclusions
We proposed an IoT resource management to provide device self-registration and status detection based on OCF in this paper. The device self-registration scheme enables devices to be registered to the IoT server by itself to be discovered by web clients from the Internet. Based on the discovered resources, a web client accesses the services which are provided by an IoT device from the OCF-based local network. For accessing the OCF service from the Internet, an interworking proxy is proposed to support the communications between web clients and OCF devices over HTTP and CoAP based on OCF. Through the interoperability with the resources using the proposed management model, real-time status detection is proposed for the awareness device status in the constrained network. According to the performance evaluation based on our implementations, the interactions are monitored for the self-registration and accessing. For self-registration, the RTTs take between 368 ms and 580 ms. The size of the profile is 1650 bytes, which is used for publishing to the IoT server. In the process of registration, the performance result presents the android application consumes more network cost compare to periodic interaction for real-time status detection; other hardware performances are approximately the same. Moreover, using the interworking proxy, the packet of CoAP-based communication is decreased by 87% compared to HTTP-based communication.
Author Contributions: W.J. and D.K. designed the overall system. W.J. implemented the overall system and performed experiments. W.J. and D.K. wrote this paper.