sensors

Article
Device Identification Interoperability in
Heterogeneous IoT Platforms †
Jahoon Koo, Se-Ra Oh and Young-Gab Kim *
Department of Computer and Information Security, Sejong University, Seoul 05006, Korea;
sigmao91@sju.ac.kr (J.K.); terious551@sju.ac.kr (S.-R.O.)
* Correspondence: alwaysgabi@sejong.ac.kr
† This paper is an extended version of conference paper: Interoperable Device Identification System for IoT
Sensors. In Proceeding of the I3S 2018, Kenting, Taiwan, 6–8 August 2018.




Received: 31 January 2019; Accepted: 21 March 2019; Published: 23 March 2019


Abstract: With the continuous improvement of Internet of Things (IoT) technologies, various IoT
platforms are under development. However, each IoT platform is developed based on its own
device identification system. That is, it is challenging to identify each sensor device between
heterogeneous IoT platforms owing to the resource request format (e.g., device identifier) varying
between platforms. Moreover, despite the considerable research focusing on resource interoperability
between heterogeneous IoT platforms, little attention is given to sensor device identification systems
in diverse IoT platforms. In order to overcome this problem, the current work proposes an IoT device
name system (DNS) architecture based on the comparative analysis of heterogeneous IoT platforms
(i.e., oneM2M, GS1 ‘Oliot’, IBM ‘Watson IoT’, OCF ‘IoTivity’, FIWARE). The proposed IoT DNS
analyzes and translates the identification system of the device and resource request format. In this
process, resource requests between heterogeneous IoT platforms can be reconfigured appropriately
for the resources and services requested by the user, and as a result, users can use heterogeneous
IoT services. Furthermore, in order to illustrate the aim of the proposed architecture, the proposed
IoT DNS is implemented and tested on a microcomputer. The experimental results show that
a oneM2M-based device successfully performs a resource request to a Watson IoT and FIWARE
sensor devices.

Keywords: Internet of Things; device identification; interoperability; IoT platform

1. Introduction
Recently, the Internet of Things (IoT) has attracted significant social attention globally.
Consequently, the research focusing on combining IoT technologies is ongoing in various fields
such as smart home, smart car, smart grid, and healthcare. With the continuous improvement of
IoT technologies, various IoT platforms are under development including oneM2M, OCF ‘IoTivity’,
Apple ‘HomeKit’, Samsung ‘ARTIK’, Google ‘Brillo/Weave’, AllSeen Alliance ‘AllJoyn’, IBM ‘Watson
IoT’, GS1 ‘Oliot’, and FIWARE. IoT Platforms are software that connect various devices, including
a variety of sensors, access points, and data networks. Therefore, it is indispensable to provide
interoperable services relevant to a diverse set of IoT platforms. However, most of the current IoT
platforms share common limitations. Each IoT platform is developed with its own device identification
(ID) system. That is, each IoT platform has a different request format for using services or resources
provided by the device. Moreover, the device identifiers used in these request formats that also differ
in format. Therefore, interworking between heterogeneous IoT platforms is challenging and deserve
consideration. For example, in smart home environments, IoT devices are connected through a smart
home hub. Consequently, these IoT devices must use the same ID system for interworking. Using

Sensors 2019, 19, 1433; doi:10.3390/s19061433 www.mdpi.com/journal/sensors

Sensors 2019, 19, 1433 2 of 16

only devices based on the same standard is a considerable limitation for the users as it cannot fulfill
the goal of creating an IoT that connects every object. Moreover, despite the considerable research
related to resource interoperability between heterogeneous IoT platforms, little attention has been
given to sensor device ID systems in diverse IoT platforms. However, most of the IoT platforms use
resource request statements that include the device identifier. In this study, we analyze resource and
device ID systems of the representative IoT platforms (i.e., oneM2M; global standard 1 (GS1) ‘Oliot’;
IBM ‘Watson IoT’; open connectivity foundation (OCF) ‘IoTivity’; and future internet ware (FIWARE)).
Furthermore, we propose and implement an IoT device name system (DNS) architecture that converts
resource requests into the respective format of each IoT platform. In order to implement this IoT DNS,
we create a scenario in which a oneM2M device requests resources and services from a Watson IoT
sensor device. The IoT DNS checks the request to identify the platform of the selected resource sent by
the oneM2M client. Based on this result, the IoT DNS generates the request statement for the other
platforms using the value stored when the device was registered. Our results show that the oneM2M
client can transmit its request to the Watson IoT and FIWARE sensor device via Root DNS and control
the latter’s LED sensor.
This paper is organized as follows. Section 2 analyzes the related work found in the literature
dealing with the interworking between heterogeneous IoT platforms and provides a background on
resource request formats of the four considered IoT platforms. Section 3 proposes the architecture
and the algorithm of the IoT DNS. In Section 4, we implement a proof of concept of the IoT DNS and
demonstrate its working principle on an example scenario. Section 5 concludes our work.

2. Background
This study selected five IoT platforms (i.e., oneM2M, GS1 ‘Oliot’, IBM ‘Watson IoT’, OCF ‘IoTivity’,
and FIWARE) because these five platforms are well-known and make an important contribution to
the IoT industrial environment. For example, these organizations provide relevant standards and
solutions. Also, Watson IoT is being developed based on cloud computing and other selected platforms
are being developed as open source projects.
oneM2M is an international organization working on machine-to-machine (M2M) standards and
provides object communication requirements for IoT systems, architectures, application programming
interface (API) specifications, and security solutions. GS1 is a private international organization aiming
for standardization. It focuses on the standardization of product ID barcodes, electronic documents,
electronic catalogs, etc., used in all industries including distribution and logistics. IBM Corporation
is a global leader in information technology services and consulting, accounting for nearly 50% of
the global computer market. The OCF is an organization that provides interoperability guidelines,
standards development, and certification programs for the IoT industry. FIWARE is a smart city service
platform developed and distributed by FI-PPP (public–private partnership) of European Union (EU)
with 23 countries. FIWARE provides OpenStack-based cloud environments, open APIs, easy IoT
connectivity, big data analysis, real-time media processing, and advanced features for user interaction.
FIWARE also adopts the use of next generation services interface (NGSI) that unifies the representation
of information. NGSI is a protocol developed by open mobile alliance (OMA) to manage context
information. It is a simple RESTful API enabling to perform updates, queries, or subscribe to changes
on context information.

2.1. Device Identification System of Various IoT Platforms

While the interworking between heterogeneous IoT platforms is an important issue, currently
no solution is being clearly addressed. To solve this interworking problem, we analyzed the device
ID systems used in each IoT platform [1] in our previous work. The device ID systems of the four
considered IoT platforms are summarized in Table 1. It represents the feature and ID system format of
selected IoT platforms.
Sensors 2019, 19, x FOR PEER REVIEW 3 of 16

Table 1. Comparison of four Internet of Things (IoT) platforms’ identification systems.

Platform
Sensors 2019, 19, 1433 Feature Identification Format 3 of 16
OID (Higher Arc)
oneM2M OID-based
ManufacturerID.DeviceTypeID.DeviceSerialNo
Table 1. Comparison of four Internet of Things (IoT) platforms’ identification systems.
GS1 Oliot OID-based GS1 OID({2.51}).ID Keys(1).[ID Key Type], Value
Platform Feature Identification Format
IBM
Client ID d:orgID:deviceType:deviceID
OID (Higher Arc)
Watson
oneM2M IoT OID-based
ManufacturerID.DeviceTypeID.DeviceSerialNo
GS1IoTivity
Oliot Resource Type,
OID-based GS1 OID({2.51}).ID Keys(1).[ID Key Type], Value
OCF [di], rt:oic.wk.d,oic.d.[*]
IBM Watson IoT Device
Client IDID d:orgID:deviceType:deviceID
OCF IoTivity Resource Type,Type,
Entity Device ID [di], rt:oic.wk.d,oic.d.[*]
No specific restriction except some characters (e.g.,
FIWARE
FIWARE Entity Type, Entity ID No specific restriction except some characters (e.g., <, >, etc.)
Entity ID <, >, etc.)

The oneM2M
The oneM2M uses uses object
object identifiers
identifiers (OID)
(OID) toto identify
identify devices. The OID
devices. The OID are
are object
object identifiers
identifiers
organized into tree structures specified by the abstract syntax notation (ANS.1) and jointly
organized into tree structures specified by the abstract syntax notation (ANS.1) and jointly developed developed
by ITU-T
by ITU-T and
andISO/IEC,
ISO/IEC, as as shown
shownin inFigure
Figure1.1.The
Theinternational
internationalOIDOIDtree is referred
tree to as
is referred to the
as thehigher arc
higher
andand
arc is used as a as
is used prefix for the
a prefix fordevice ID system
the device of oneM2M.
ID system As depicted
of oneM2M. in Figure
As depicted 2, the2,
in Figure higher arc is
the higher
followed by ‘x’, ‘y’, ‘z’, where ‘x’ is the device manufacturer, ‘y’ is the device type, and ‘z’ is
arc is followed by ‘x’, ‘y’, ‘z’, where ‘x’ is the device manufacturer, ‘y’ is the device type, and ‘z’ is the the device
serial number
device [2].
serial number [2].

Figure
Figure 1.
1. International
International OID
OID tree.
tree.

oneM2M standard object identifiers (OID).

Figure 2. oneM2M

The GS1
The GS1 ‘Oliot’
‘Oliot’ also
also uses
uses anan OID-based
OID-based ID ID key
key (namely
(namely the the GS1)
GS1) toto identify
identify devices
devices andand events.
events.
The
The OID assigned to GS1 is {2.51}. The first arc (2) contains the organization/institution code that
OID assigned to GS1 is {2.51}. The first arc (2) contains the organization/institution code that
represents the
represents the joint
joint with
with ITU-T
ITU-T andand ISO.
ISO. The
The second
second arcarc (51)
(51) represents
represents the the GS1. {2.51} is
GS1. {2.51} is followed
followed by by
GS1 ID keys (1), GS1 supplementary data (2), GS1 business data (3), and GS1 technical
GS1 ID keys (1), GS1 supplementary data (2), GS1 business data (3), and GS1 technical data (4) as data (4) as child
nodes.nodes.
child GS1 IDGS1 keys
ID (1)
keysare(1)
used
are as
useddevice identifiers
as device in thein
identifiers GS1,
the where the OID
GS1, where theisOID
{2.51.1}. The child
is {2.51.1}. The
nodes of {2.51.1} can have 10 key types, which are shown in
child nodes of {2.51.1} can have 10 key types, which are shown in Table 2. Table 2.
GS1 ID
GS1 ID keys
keys have
have various
various types
types depending
depending on on their
their usages,
usages, such
such asas the
the global
global trade
trade item
item number
number
(GTIN)
(GTIN) and
and serial shipping container
serial shipping container code
code (SSCC).
(SSCC). TheThe GS1
GS1 ID key types
ID key types can
can be
be identified
identified by by the
the field
field
or application of the device. Individual devices can be identified through additional
or application of the device. Individual devices can be identified through additional values. These values. These GS1
ID key
GS1 ID values include
key values the company
include prefix,
the company serialserial
prefix, number, etc., as
number, shown
etc., in Figure
as shown 3 [3–6].
in Figure 3 [3–6].
Sensors 2019, 19, x FOR PEER REVIEW 4 of 16
Sensors 2019, 19, 1433 4 of 16

Table 2. GS1 identification key type.

Table 2. GS1 identification key type.
OID ID Key Type Name
2.51.1.1OID GTIN
ID Key Type Global Trade
Name Item Number
2.51.1.2
2.51.1.1 SSCC
GTIN Serial
Global Trade ItemContainer
Shipping Number Code
2.51.1.3
2.51.1.2 GLN
SSCC SerialGlobal
ShippingLocation
Container Number
Code
2.51.1.3
2.51.1.4 GLN
GRAI Global
Global Location Number
Returnable Asset Identifier
2.51.1.4 GRAI Global Returnable Asset Identifier
2.51.1.5 GIAI Global Individual Asset Identifier
2.51.1.5 GIAI Global Individual Asset Identifier
2.51.1.6
2.51.1.6 GDTI
GDTI Global
Global Document
Document Type Type Identifier
Identifier
2.51.1.7
2.51.1.7 GSRN
GSRN Global
Global Service
Service Relation
Relation Number
Number
2.51.1.8
2.51.1.8 GSIN
GSIN Global
Global Shipment
Shipment Identification Number
Identification Number
2.51.1.9
2.51.1.9 GINC
GINC Global Identification Number for Consignment
Global Identification Number for Consignment
2.51.1.10 GCN Global Coupon Number
2.51.1.10 GCN Global Coupon Number

Figure 3.
Figure 3. GS1
GS1 ID
ID key
key value.
value.

The
The ID system
system ofofthe
theIBM
IBM‘Watson
‘WatsonIoT’ IoT’identifies
identifies individual
individual devices
devices withwith unique
unique client
client IDs. IDs.
The
The client
client IDs IDs
are are formatted
formatted by by
thethe client
client type.The
type. Theclient
clienttype
typeisis divided
divided into application, expandable
expandable
application, device,and
application, device, andgateway.
gateway.The Theformat
format of of each
each client
client ID ID is shown
is shown in Table
in Table 3. client
3. The The client ID
ID used
used to identify
to identify each device
each device has thehas the following
following format:format: d:orgID:deviceType:deviceID.
d:orgID:deviceType:deviceID. In this orgID
In this format, format,is
orgID is the
the user’s user’s
own own organization
organization ID. In
ID. In order order tothe
to register register
device theondevice on Watson
the IBM the IBM IoT
Watson IoT platform,
platform, the user
the user
needs hisneeds his own organization.
own organization. IBM providesIBM provides
the orgIDthe orgID
when the when the userhis
user registers registers his ownGenerally,
own account. account.
Generally,
IBM assigns IBM assignssix-digits-long
a random a random six-digits-long
string to everystring
user.to The
every user. The is
deviceType deviceType
the type orismodel
the type or
of the
model
device.ofThethedeviceID
device. The deviceID
is the is the serial
serial number of thenumber
device [7].of the device [7].

Table 3. Type
Table 3. Type of
of Watson
WatsonIoT
IoTclient
clientID.
ID.

ClientType
Client Type ID
IDFormat
Format
Application
Application a:orgID:appID
a:orgID:appID
Expanded Application
Expanded Application A:orgID:appID
A:orgID:appID
Device
Device d:orgID:deviceType:deviceID
d:orgID:deviceType:deviceID
Gateway g:orgID:typeID:deviceID
Gateway g:orgID:typeID:deviceID

The
The OCFOCF ‘IoTivity’
‘IoTivity’ identifies
identifies all
all resources,
resources, including
including the the device,
device, resource,
resource, etc.,
etc., with
with the the value
value of of
the resource type (‘rt’). Among them, the device is identified by using the
the resource type (‘rt’). Among them, the device is identified by using the ‘rt’ and an additional value ‘rt’ and an additional value
referred
referred to to as
as the
the device
device identifier
identifier (‘di’).
(‘di’). The
The ‘rt’
‘rt’ value
value can
can have
have anan ‘oic.wk.d’
‘oic.wk.d’ oror ‘oic.d.[*]’.
‘oic.d.[*]’. TheThe ‘oic.d.[*]’
‘oic.d.[*]’
represents
represents the the specified
specifieddevice deviceattribute.
attribute.Currently,
Currently, thethe
‘rt’‘rt’ value
value is assigned
is assigned the the device
device typetype
of theoffield
the
field for smart home applications and health
for smart home applications and health care applications [8–12]. care applications [8–12].
The
The device
device ID ID system
system of of FIWARE
FIWARE is is based
based on on NGSI
NGSI standard.
standard. FIWARE
FIWARE uses uses ‘entity
‘entity id’id’ and
and ‘entity
‘entity
type’ to identify a specific entity. These entities also include each device
type’ to identify a specific entity. These entities also include each device connected to FIWARE, and connected to FIWARE, and the
device ID and device type that identify each device can be set to ‘entity
the device ID and device type that identify each device can be set to ‘entity id’ and ‘entity type’. id’ and ‘entity type’. ‘Entity id’
and ‘entity type’ can be set freely by the user at the time of creation. There
‘Entity id’ and ‘entity type’ can be set freely by the user at the time of creation. There is no specific is no specific restriction on
the format,on
restriction butthe‘entity
format,id’ should be unique
but ‘entity within
id’ should the APIwithin
be unique and some the elements
API and some (i.e., <, >, “, ‘, =,(i.e.,
elements ;, (, <,
))
are forbidden [13].
>, “, ‘, =, ;, (, )) are forbidden [13].
As
As shown
shown in in Table
Table 4, 4, we
we analyzed
analyzed the the four
four platforms
platforms and and created
created aa mapping
mapping table table to to compare
compare
them.
them. The attribution in this table is based on the oneM2M OID structure because our study focuses
The attribution in this table is based on the oneM2M OID structure because our study focuses
on the oneM2M platform. All elements in the device ID of the GS1 Oliot are mapped to the oneM2M
Sensors 2019, 19, 1433 5 of 16

on the oneM2M platform. All elements in the device ID of the GS1 Oliot are mapped to the oneM2M
OID. However, the device IDs of the IBM Watson IoT, OCF IoTivity, and FIWARE do not use the device
Sensors 2019, 19, x FOR PEER REVIEW 5 of 16
manufacturer and an expanded ID. Consequently, these values are mapped to n/a values.
OID. However, the device IDs of the IBM Watson IoT, OCF IoTivity, and FIWARE do not use the
4. Mapping
Tableand
device manufacturer tableID.
an expanded forConsequently,
the device IDsthese
of various
valuesIoT
areplatforms.
mapped to n/a values.

Platform X Y Z
Table 4. Mapping table for the device IDs of various IoT platforms.
a
oneM2M Manufacturer ID Model ID Serial No ID Expanded ID
Platform
GS1 Oliot CompanyX Prefix Y No
Reference Z No
Serial a No
Extension
IBMoneM2M
Watson IoT Manufacturer
n/a ID Model ID
Device Type Serial
DeviceNoIDID Expanded
n/a ID
GS1IoTivity
OCF Oliot Company
n/a Prefix Reference No
rt: oic.d.[*] Serial
di No Extension
n/a No
IBMFIWARE
Watson IoT n/a
n/a Device Type
Entity Type DeviceID
Entity ID n/a
n/a
OCF IoTivity n/a rt: oic.d.[*] di n/a
FIWARE n/a Entity Type Entity ID n/a
2.2. Resource Identification System of the Various IoT Platforms
Most IoT platforms
2.2. Resource useSystem
Identification the device ID inIoT
of the Various thePlatforms
request statement. The subsection analyzes the
resource request
Most IoTformat of each
platforms use heterogeneous
the device ID inIoTthe platform.
request statement. The subsection analyzes the
resource request format of each heterogeneous IoT platform.
2.2.1. oneM2M
2.2.1.resource
The oneM2M architecture of oneM2M is shown in Figure 4. This architecture consists of an
infrastructure node (IN),
The resource middle of
architecture node (MN),is application
oneM2M service
shown in Figure node
4. This (ASN), and
architecture an application
consists of an
infrastructure
dedicated node (IN),
node (ADN). middle
Except nodeADN,
for the (MN),every
application
other service node
node has (ASN), and
a common an application
service entity (CSE).
dedicated
The CSE node (ADN).
has a resource Exceptwith
structure for the ADN,
a tree everyIn
format. other node has ainfrastructure,
the oneM2M common service entity
each (CSE). has a
resource
resource ID and resource name. The latter two are used to request resources. For example, in has
The CSE has a resource structure with a tree format. In the oneM2M infrastructure, each resource order to
a resource ID and resource name. The latter two are used to request resources. For example, in order
request the ASN-AE with a specific resource ID (i.e., 006) and resource name (i.e., dev02), the path
to request the ASN-AE with a specific resource ID (i.e., 006) and resource name (i.e., dev02), the path
format is ‘server01/gateway01/asn01/dev02’. Currently, the oneM2M standard does not use the
format is ‘server01/gateway01/asn01/dev02’. Currently, the oneM2M standard does not use the
device ID when
device it requests
ID when resources
it requests resourcesand
andservices
services [2].
[2].

Figure4.4.oneM2M
Figure oneM2M resource
resourcestructure.
structure.

2.2.2.2.2.2.
GS1 GS1 ‘Oliot’
‘Oliot’
GS1 GS1 Oliot
Oliot usesuses
thethe electronicproduct
electronic productcode
code information
information services (EPCIS)
services to store
(EPCIS) and and
to store manage
manage
devices and resources in an event format. In order to identify and request these devices and resources,
devices and resources in an event format. In order to identify and request these devices and resources,
the following ID formats are used: ‘urn:epc:id:sgtin:[GS1 ID key]’. This format contains the type and
the following ID formats are used: ‘urn:epc:id:sgtin:[GS1 ID key]’. This format contains the type and
value of the GS1 ID key.
value of the GS1 ID key.
Sensors 2019, 19, 1433 6 of 16

2.2.3. IBM ‘Watson IoT’

IBM
SensorsWatson
2019, 19, xIoT
FORuses
PEER the request format as shown in Table 5. It supports the appropriate
REVIEW 6 of format
16
according to the type of the protocol, e.g., hyper-text transfer protocol (HTTP) or message queuing
2.2.3.transport
telemetry IBM ‘Watson IoT’ In both formats, {typeID}, {deviceID}, and {logicalInterfaceId} are used as
(MQTT).
identifiers.IBMThe latter IoT
Watson three have
uses the expressions
the request format as shown inTable
shown in Table5.6It[7].
supports the appropriate format
according to the type of the protocol, e.g., hyper-text transfer protocol (HTTP) or message queuing
telemetry transport (MQTT). Table 5. Watson
In both IoT
formats, resource{deviceID},
{typeID}, request format.
and {logicalInterfaceId} are used
as identifiers. The latter three have the expressions shown in Table 6 [7].
Protocol Format
MQTT Table 5. Watson IoT resource request format.
iot-2/type/${typeId}/id/${deviceId}/intf/${logicalInterfaceId}/evt/state
HTTP GET/device/types/{typeId}/devices/{deviceId}/state/{logicalInterfaceId}
Protocol Format
MQTT iot-2/type/${typeId}/id/${deviceId}/intf/${logicalInterfaceId}/evt/state
HTTP Table 6. Request identifier parameter.
GET /device/types/{typeId}/devices/{deviceId}/state/{logicalInterfaceId}
Parameter Description
Table 6. Request identifier parameter.
typeID The device type identifier.
deviceID Parameter Description
The device identifier.
typeID
logicalInterfacedID or Thelogical
alias The identifier created for the deviceinterface
type identifier.
or the user-specified alias name.
deviceID The device identifier.
logicalInterfacedID The identifier created for the logical interface or the
2.2.4. OCF ‘IoTivity’
or alias user-specified alias name.
The resource request format used by the OCF IoTivity is ‘ocf://<authority>/<path>?<Query>‘.
2.2.4.
In this OCF ‘IoTivity’
format, the ‘di’ value is used for the authority. The ‘di’ value uses the universally unique
identifier The
(UUID) and
resource has 36
request characters.
format used by theFor
OCFexample,
IoTivity is if the request of the OCF IoTivity
‘ocf://<authority>/<path>?<Query>‘. In is
‘GET this
ocf://<di> /a/room/1?if=oic.if.ll’, the resource path is ‘/a/room/1’ and follows the
format, the ‘di’ value is used for the authority. The ‘di’ value uses the universally unique query
statement [11].(UUID) and has 36 characters. For example, if the request of the OCF IoTivity is ‘GET
identifier
ocf://<di> /a/room/1?if=oic.if.ll’, the resource path is ‘/a/room/1’ and follows the query statement [11].
2.2.5. FIWARE
2.2.5. FIWARE
The resource request format of FIWARE is different from each IoT agent. The IoT agent is a
component Thethat
resource request
mediates format aofset
between FIWARE is different
of devices using from
theireach
ownIoT agent.
native The IoT agent
protocols and anis aNGSI
component that mediates between a set of devices using their own native protocols and an NGSI
compliant context provider. In FIWARE, the intelligence data advanced solution (IDAS) generic
compliant context provider. In FIWARE, the intelligence data advanced solution (IDAS) generic
enabler (GE) offers a wide range of IoT agents making it easier to interface with devices using the most
enabler (GE) offers a wide range of IoT agents making it easier to interface with devices using the
widely used
most IoT protocols
widely (e.g., lightweight
used IoT protocols M2M (LWM2M)
(e.g., lightweight over constrained
M2M (LWM2M) application
over constrained protocol
application
(CoAP), javascript object notation (JSON), UltraLight over HTTP/MQTT, or OPC unified
protocol (CoAP), javascript object notation (JSON), UltraLight over HTTP/MQTT, or OPC unified architecture
(OPC-UA)) as shown
architecture in Figure
(OPC-UA)) 5. in Figure 5.
as shown

Figure
Figure 5. Interaction
5. Interaction between
between Orioncontext
Orion contextbroker
broker and
and intelligence
intelligencedata
dataadvanced solution
advanced (IDAS)
solution (IDAS)
generic
generic enablers
enablers (GEs).
(GEs).
Sensors 2019, 19, 1433 7 of 16
Sensors 2019, 19, x FOR PEER REVIEW 7 of 16

In
In this
this research,
research, wewe use
use the
the NGSI-based
NGSI-based HTTP HTTP resource
resource request
request format
format and
and implement
implement it it in
in the
the
testbed.
testbed. The HTTP request format of FIWARE is {ip address}: 1026 / v2 / entities / {id}. {Ip address}
/ v2 / entities / {id}. {Ip address} is
is
thethe
IPIPofofthe
thedevice
devicereceiving
receivingthetherequest,
request,and
andFIWARE
FIWARE Orion
Orion uses
uses port number 1026. {Id} is the the
identifier
identifier of
of the
the entity,
entity, and
and the
the attribution
attribution value
value isis added
added to to the
the format
format when
when users
users get
get or
or update the
specific
specific state
stateinformation
informationof ofthe
theentity.
entity.TheTheformat
formatfor forgetting
gettingororupdating
updating specific
specificstatus information
status information is
{ip address}:
is {ip address}: 1026 / v2
1026 / entities
/ v2 / entities/ /{id}
{id}// attrs / {attrsName} [13].
/ {attrsName} [13].

2.3.
2.3. Related
Related Work
Work
oneM2M
oneM2M is is an
an under-development
under-developmentinterworking
interworking proxy
proxy entity
entity (IPE)(IPE) focusing
focusing on interworking
on interworking with
with OCF. IPE converts the resources of OCF IoTivity into the oneM2M resource
OCF. IPE converts the resources of OCF IoTivity into the oneM2M resource format and generates the format and generates
the resources
resources in the
in the gateway.
gateway. TheTheOCF OCF IoTivity-based
IoTivity-based device
device connected
connected to theto the oneM2M
oneM2M gateway
gateway givesgives
the
the resource
resource discovery
discovery results
results to the
to the gateway
gateway at regular
at regular intervals.
intervals. TheThe gateway
gateway converts
converts the the results
results to
to the
the oneM2M resource tree structure and stores it in the gateway. A oneM2M
oneM2M resource tree structure and stores it in the gateway. A oneM2M device can request the OCF device can request the
OCF IoTivity
IoTivity resources
resources that converted
that were were converted to the oneM2M
to the oneM2M resourceresource tree structure
tree structure in the oneM2M
in the oneM2M gateway
gateway
[14]. [14].
Wu
Wu et
et al.
al. [15]
[15] presented
presented an an example
example for for OCF
OCF IoTivity
IoTivity resource
resource mapping
mapping to to the
the oneM2M
oneM2M resource
resource
structure,
structure, asas shown
shown in in Figure
Figure 6. In this
6. In this example,
example, ‘di’‘di’ is
is mapped
mapped to to AE
AE and and ‘oic’
‘oic’ is
is mapped
mapped to to the
the
container under the MN-CSE tree. However, IPE converts resources in
container under the MN-CSE tree. However, IPE converts resources in heterogeneous platforms to theheterogeneous platforms to
the oneM2M resource structures and, in addition, creates resources in the gateways.
oneM2M resource structures and, in addition, creates resources in the gateways. Hence, it is not efficient Hence, it is not
efficient memory-wise
memory-wise at the gateways
at the gateways owing owing
to the to the resources
resources beingbeing
newlynewly createdcreated by only
by only changing
changing the
the
structure. If large amounts of resources are created in the gateway, IPE requires a large amount of
structure. If large amounts of resources are created in the gateway, IPE requires a large amount of
memory.
memory. Memory
Memory capacity
capacity isis limited
limited in in the
the gateway
gatewayand andre-registering
re-registeringall allresources
resourcesisisnotnotefficient.
efficient.

Figure 6.
Figure 6. IoTivity resource mapping
IoTivity resource mapping to
to oneM2M
oneM2M resource
resource structure.
structure.

Kang
Kang etet al. [16] proposed an ontology-based IoT framework
framework that is based on the oneM2M standardstandard
to ensure the interoperability of heterogeneous
to ensure the interoperability of heterogeneous IoT platforms. When
platforms. When a device is connected
connected to the the
network,
network, the
the IoT server registers the device as a oneM2M resource. For For managing
managing devices
devices dynamically,
dynamically,
the
the IoT
IoT server
server performs
performs aa health-check
health-check mechanism
mechanism of the the device.
device. The data
data generated
generated by the
the device
device
registered
registered isis integrated
integrated into the oneM2M resource
resource through
through monitoring.
monitoring. Moreover,
Moreover, thethe event
event about
about the the
data
data generated
generated by the the middleware
middleware is is reported.
reported. However,
However, thethe ontology-based
ontology-based IoT IoT environment
environment should
should
be
be changed
changed andand rebuilt
rebuilt when
when the
the service
service requirements
requirements areare changed
changed oror out
out of
of the
the set
set domain.
domain. ItIt is
is also
also
difficult
difficult to extract context information
information based
basedon
onstate
stateinformation.
information.
Tao
Tao et
et al.
al. [17,18]
[17,18] built
built and
and managed
managed aa public
public cloud
cloud ofofprivate
private cloud-based
cloud-based platforms
platforms for
for each
each
organization
organization into a centralized cloud environment.
a centralized cloud environment. These also aim to satisfy interoperability between
aim to satisfy interoperability between
heterogeneous
heterogeneous platforms by applying applying ontology-based
ontology-based representation
representation in in public
public cloud.
cloud. However,
currently not all IoT platforms use the cloud and getting the information they need from a cloud-based
Sensors 2019, 19, 1433 8 of 16

currently not all IoT platforms use the cloud and getting the information they need from a cloud-based
platform is challenge. Further, additional research is required because there are many limitations in
building cloud-based IoT environments.
Currently, interoperability between heterogeneous IoT platforms is under development by
various research groups. However, most interoperability studies do not focus on device identifiers.
As described previously, many related studies propose a solution by applying the IPE method specified
by the oneM2M standard organization. The IPE, which is under development and is implemented on
the oneM2M platform, creates and uses the resources of the heterogeneous platform by converting
the format to the oneM2M resource format in the gateway. If large amounts of resources are created
in the gateway, IPE requires a large amount of memory. Memory capacity is limited in the gateway
and re-registering all resources is not efficient. In this study, we proposed a solution to these problems.
We analyzed the resource request formats and device ID systems used in heterogeneous IoT platforms
and selected several IoT platforms, such as the oneM2M, GS1 ‘Oliot’, IBM ‘Watson IoT’, OCF ‘IoTivity’,
and FIWARE for analysis. Each IoT platform uses a different ID system, including both device
identifier and resource request format. However, the IoT DNS proposed in this work does not
re-register resources of the heterogeneous platforms in the oneM2M format. It stores and manages
the request format aimed at the database in the gateway. Therefore, the gateway is less dependent on
device capabilities and the memory usage of the IoT DNS is far less significant than that of the IPE.

3. IoT Device Name System Architecture

Currently, the five IoT platforms selected in this paper use different standards. Consequently,
identifying devices and resources belonging to the various platforms is challenging. Therefore,
this study proposes an IoT DNS architecture to solve these challenges. In Section 3, an algorithm and
corresponding pseudo code of the proposed IoT DNS is presented.
The IoT platform is divided into two types: One that provides cloud services, and one that builds
its own servers. We suppose that the local DNS 1 is part of an Oliot platform, the local DNS 2 is
part of a oneM2M platform, the local DNS 3 is part of an IoTivity platform, and the local DNS 4 is
part of an FIWARE. Each Local DNS performs resource discovery in regular intervals and sends the
resource discovery results to the root DNS. The root DNS integrates, stores, and manages the resource
discovery results received from each local DNS in a single database. In addition, the integrated
resource discovery results are transmitted to each local DNS at regular intervals. The integrated
resource discovery results are provided to the client with only limited information. An example of a
database managed by the root DNS and an example of the interface provided by local DNS to the client
is as follows. The interface provided by the local DNS to the client includes three columns such as
‘Number’, ‘Resource’, and ‘IP’. ‘Number’ is the resource number in the database managed by the root
DNS. It is used whenever a user selects that specific resource. ‘Resource’ is the resource or service name.
‘IP’ is the IP address or physical location of the device. It helps the user to identify the resource in more
detail. The database managed by the root DNS includes seven columns: ‘Resource Number’, ‘Platform
Number’, ‘Resource Name’, ‘Device ID’, ‘Resource Path’, ‘Use-Token-Auth’, and ‘IP’. The ‘Resource
Number’, ‘Resource Name’, and ‘IP’ values are the same as the ones of the interface provided by the
local DNS. The ‘Platform Number’ is the type of the IoT platform. In this study, we suppose that
the platform number 1 refers to oneM2M, 2 refers to GS1, 3 refers to Watson IoT, 4 refers to IoTivity,
and 5 refers to FIWARE. ‘Device ID’ is the identifier of the resource’s device. ‘Resource Path’ is the
logical location of the resource. It is used whenever the IoT DNS generates a new request statement.
‘Use-Token-Auth’ is the token value used by the Watson IoT platform. If the IoT DNS generates
a request statement for the Watson IoT platform, it uses the ‘Token-Auth’ value for authentication.
Local DNS processes make requests for devices of the same platform. The root DNS generates the
appropriate request statements for devices from heterogeneous platforms.
Figure 7 shows the algorithms of the IoT DNS. A local DNS receives a user request from a client.
If this request is compatible with the local system, the local DNS processes the request on the same
 Sensors 2019, 19, 1433 9 of 16

Sensors
Sensors 2019,
platform.
2019, 19, x FOR
19,Otherwise,
x FOR PEER
PEER REVIEW
i.e.,
REVIEW 9 of
if the request is not compatible with the local system, the local DNS sends
9 of 16
16the
request to the root DNS. The root DNS checks the platform and generates the request statements for
for
thethe
forthe heterogeneous
heterogeneous
heterogeneous platform.
platform.
platform. AA
A pseudopseudo
pseudocode code
code
of of of
the thethe
root root
root
DNS DNS
DNS
and and
aand a local
a DNS
local local DNS
for DNS for
thefor thethe above-
above-
above-described
described
described
algorithm algorithm
algorithm is
is shownisin shown
shown
Figure in Figure
in8.Figure 8. 8.

Figure
Figure
Figure 7. IoT
7. IoTIoT device
device
device name
name
name system
system
system (DNS)
(DNS)
(DNS) algorithm.
algorithm.

Figure
Figure
Figure 8.
8. IoT
8. IoT IoT
DNSDNS
DNS architecture.
architecture.
architecture.

4. Proof
4. Proof of of Concept
Concept
4. Proof of Concept
In this
this section,
section, in
in order
order to
to illustrate
illustrate the
the aim
aim of
of the proposed
proposed IoT DNSDNS architecture,
architecture, the
the proposed
proposed
In In
this section, in order to illustrate the aim of thethe
proposed IoTIoT DNS architecture, the proposed
IoT DNS is implemented and tested on a microcomputer. Furthermore, we show two scenarios (i.e.,
IoTIoT
DNSDNS is implemented
is implemented andand tested
tested onon a microcomputer.
a microcomputer. Furthermore,
Furthermore, wewe show
show two
two scenarios
scenarios (i.e.,
(i.e.,
in scenario 1, the oneM2M device requests a service to the Watson IoT and, in scenario 2, the oneM2M
in in scenario
scenario 1, the
1, the oneM2M
oneM2M device
device requests
requests a service
a service to to
thethe Watson
Watson IoTIoT and,
and, in in scenario
scenario 2, the
2, the oneM2M
oneM2M
device requests
device requests aa service
service to
to the
the FIWARE)
FIWARE) which
which show
show how how the
the proposed
proposed architecture
architecture works
works between
between
device requests a service to the FIWARE) which show how the proposed architecture works between
diverse
diverse IoT platforms. A more detailed description will be explained in the following subsections.
diverse IoTIoT platforms.
platforms. AA more
more detailed
detailed description
description will
will bebe explained
explained in in
thethe following
following subsections.
subsections.
4.1. Implementation
Implementation Environments
Environments
4.1.4.1.
Implementation Environments
This subsection
This subsection describes
describes the implementation environment of the IoT DNS, which is is
specified in
This subsection describes thethe implementation
implementation environment
environment of of
thethe
IoTIoT DNS,
DNS, which
which specified
is specified
Table 7. The scenario presented in this study consists of the root DNS, a oneM2M server, a oneM2M
in in Table
Table 7. The
7. The scenario
scenario presented
presented in in this
this study
study consists
consists of of
thethe root
root DNS,
DNS, a oneM2M
a oneM2M server,
server, a oneM2M
a oneM2M
client,
client, a sensor
a sensor device
device based
based on the Watson IoT platform, a FIWARE broker, and a sensor device based
client, a sensor device based ononthethe Watson
Watson IoTIoT platform,
platform, a FIWARE
a FIWARE broker,
broker, and and a sensor
a sensor device
device
on
basedthe FIWARE platform.
based onon
thethe FIWARE
FIWARE platform.
platform.
Sensors 2019, 19, x1433
FOR PEER REVIEW 1010of
of 16
16

Table 7. Specifications of the implementation environment.

Table 7. Specifications of the implementation environment.
oneM2M
Root oneM2M oneM2M
oneM2M Server Watson IoTWatson IoTFIWARE
FIWARE FIWARE
FIWARE
Root DNS Server
DNS Client ClientSensor Sensor Broker Sensor
(Local DNS) Broker Sensor
(Local DNS)
SourceLanguage
Source Python Python Python Python
Python Javascript n/a
Python
Python Python
Python
Python Javascriptn/a C++ C++
Language Javascript Javascript C++ C++
Python
Python requestmodule:
request module:Python
Python requests
requests version:
version:2.12.4
2.12.4
Used MySQL connectormodule:
module: PyMySQL
PyMySQL version:
Used Module & MySQL connector version:0.9.3
0.9.3
Module &
Tool Node- Node.js Node.js Node.js & Orion
Orion Context
Tool Node-RED MobiusNode.js Mobius Node-RED Node-RED Broker Context Orion-Client
Orion-Client
RED &Cube Cube
Broker
Name Raspberry Pi 3 Model B+
Name Raspberry Pi 3 Model B+
Device CPU 1.4GHz ARM Cortex-A53 MP4
Device OS CPU Raspbian Stretch with desktop 1.4 version:
GHz ARM Cortex-A53
Nov. 2018 MP4 Ubuntu MATE 16.04.2
Additional OS Raspbian Stretch with desktop version: Nov. 2018 Ubuntu MATE 16.04.2
n/a n/a n/a LED sensor n/a LED sensor
Device
Additional LED
n/a n/a n/a LED sensor n/a
Device sensor

The root DNS, the oneM2M server, and the oneM2M client use python. In addition, javascript is
used Thefor root DNS, the oneM2M
the oneM2M environmentserver, and the oneM2M
implementation. Thisclient use python.
javascript In addition,
source is used tojavascript is
build the
used for the oneM2M environment implementation. This javascript source
Mobius server named ‘yellow turtle’ and the oneM2M client named ‘&Cube’. Mobius was developed is used to build the Mobius
server
by named
Korea ‘yellow turtle’
Electronics and theInstitute
Technology oneM2M(KETI).client named
It is a‘&Cube’.
platformMobiusbasedwas
on developed
oneM2M.&Cube by Korea
is
Electronics Technology Institute (KETI). It is a platform based on
developed by KETI and it is a oneM2M-based client software. The present work uses MobiusoneM2M.&Cube is developed by
KETI and it
following is example
the a oneM2M-based client software.
documentation published Thebypresent
KETI. Aworkpythonusesrequests
Mobiusmodule
following the example
is used, which
documentation published by KETI. A python requests module is used,
sends the requests in python. It uses a MySQL connector module named PyMySQL, which connects which sends the requests in
python. It uses
MySQL and python. a MySQL connector module named PyMySQL, which connects MySQL and python.
In order
In order totouse usethe Watson
the WatsonIoTIoT
services, we registered
services, a useraaccount
we registered with IBM
user account andIBM
with wereand assigned
were
assigned a cloud. The Watson IoT-based sensor device receives requests through the IBM cloud.have
a cloud. The Watson IoT-based sensor device receives requests through the IBM cloud. We We
donedone
have the node configuration
the node using
configuration Node-RED
using Node-RED in ain
Watson
a Watson IoTIoT
sensor device,
sensor as as
device, shown
shown inin
Figure
Figure9.
Node-RED
9. Node-RED is is
a aflow-based
flow-baseddevelopment
developmenttool toolforforvision
visionprogramming
programming developed
developed by by IBM
IBM toto wire
wire
hardware devices, APIs, and online services as parts of the IoT. As shown
hardware devices, APIs, and online services as parts of the IoT. As shown in Figure 9, the device in Figure 9, the device
receives the
receives the request
requestwithwitha asatisfactory
satisfactorydevice
device ID IDandand
event named
event namedas blink. When
as blink. setting
When up theupnode,
setting the
the user is authenticated using the API key registered by the
node, the user is authenticated using the API key registered by the IBM cloud. IBM cloud.

Figure
Figure 9.
9. Node-RED
Node-RED configuration
configuration of
of the
the Watson
Watson sensor
sensor device.
device.

In order to build the FIWARE environment, we use the Orion context broker that the user can
register and
and manage
managethe thecontext
contextelements
elements through
through queries.
queries. AsAs shown
shown in Figure
in Figure 10, created
10, we we created the
the LED
LED
entityentity thatstatus
that ‘id’ ‘id’ status is FI_LED_1.
is FI_LED_1. This
This LED LEDinformation
entity entity information is synchronized
is synchronized to FIWARE to FIWARE
broker at
broker
regularatintervals.
regular intervals.
Sensors 2019, 19, 1433 11 of 16
Sensors 2019, 19, x FOR PEER REVIEW 11 of 16

Figure 10. Implementation

Implementation testbed.

Some elements
elementsininthis implementation
this implementation (i.e.,(i.e.,
the root DNS,DNS,
the root oneM2M server,server,
oneM2M oneM2M client, Watson
oneM2M client,
IoT sensor)
Watson IoT are constructed
sensor) using a raspberry
are constructed Pi 3 Model
using a raspberry Pi b+, running
3 Model b+,the Raspbian
running stretch operating
the Raspbian stretch
system, desktop
operating system,version
desktop Nov. 2018.Nov.
version Other elements
2018. Other(i.e., FIWARE
elements (i.e.,broker
FIWAREandbroker
FIWARE andsensor)
FIWARE are
running the Ubuntu MATE 16.04.2. The implementation testbed is shown in Figure
sensor) are running the Ubuntu MATE 16.04.2. The implementation testbed is shown in Figure 11. 11.

Figure 11. Implementation

Implementation testbed.

4.2. Scenario
4.2. Scenario
This subsection
This subsection describes
describes the
the implemented
implemented scenario
scenario ofof the
the IoT
IoT DNS.DNS. The The scenario supposes
scenario supposes
interworking between
interworking between heterogeneous
heterogeneousIoT IoTplatforms.
platforms.As Asa acase
case study,
study, it it
is is supposed
supposed that
that thethe user
user of
of the oneM2M client requests and controls the sensor (i.e., Watson IoT
the oneM2M client requests and controls the sensor (i.e., Watson IoT and FIWARE LED service). Inand FIWARE LED service).
In advance,
advance, thethe oneM2M
oneM2M server
server (i.e.,
(i.e., thethe local
local DNS)
DNS) receives
receives a alist
listofofallallresources
resourcesfromfromthe
theroot
rootDNS.
DNS.
When
When thethe oneM2M
oneM2M server
server and
and the
the client
client start
start communicating,
communicating, the the oneM2M
oneM2M server provides the
server provides user
the user
with a list of every resource. Scenario 1 (oneM2M device requests a service
with a list of every resource. Scenario 1 (oneM2M device requests a service to Watson IoT sensor to Watson IoT sensor
device) is
device) is shown
shown in in Figure
Figure 1212 and
and scenario
scenario 22 (oneM2M
(oneM2M device
device requests
requests aa service
service to
to FIWARE
FIWARE sensor
sensor
device) is
device) is shown
shown in in Figure
Figure 13.
13. The
The detailed
detailed description
description of
of the
the scenario
scenario is is as
as follows:
follows:
1. Theuser
1. The userof
of the
the oneM2M
oneM2M client
client selects
selectsthe
therequired
requiredresource named
resource named ‘LED:on’
‘LED:on’from thethe
from resource list.
resource
2. list.
The oneM2M server checks the resource selected by the user in the database. The oneM2M server
confirms
2. The oneM2Mthatserver
it is not a request
checks to a oneM2M-based
the resource selected by the device
userand sends
in the the request
database. to the rootserver
The oneM2M DNS.
3. confirms
The rootthat
DNS checks the request received from the oneM2M server.
it is not a request to a oneM2M-based device and sends the request to the root DNS.
4. The
3. Theroot
rootDNS
DNSchecks
identifies whetherreceived
the request the request
from is the
for Watson
oneM2M IoT-based
server. device or a FIWARE-based
device.
4. The root DNS identifies whether the request is for Watson IoT-based device or a FIWARE-based
5. device.
The root DNS creates and sends a new request statement using the values in the database.
5. The root DNS creates and sends a new request statement using the values in the database.
Sensors 2019, 19, x FOR PEER REVIEW 12 of 16

Sensors 2019, 19, 1433 12 of 16

Sensors 2019,
Sensors 2019, 19,
19, xx FOR
FOR PEER
PEER REVIEW
REVIEW 12 of
12 of 16
16

Figure 12. Scenario 1: A oneM2M request to a Watson IoT.

Figure12.
Figure
Figure 12.Scenario
12. Scenario1:
Scenario 1: A
1: A oneM2M
A oneM2M request
request to
requesttotoaaaWatson
Watson IoT.
WatsonIoT.
IoT.

Figure
Figure13.
Figure 13.Scenario
13. Scenario2:2:
Scenario 2:A AoneM2M
A
A oneM2M request
oneM2M
oneM2M request
request toaaaFIWARE.
to
requestto FIWARE.
FIWARE.

4.3.4.3.
4.3. Implementation
4.3. Implementation
Implementation
Implementation
This
This subsection
This subsectionshows
subsection
This subsection shows
shows the
showsthe theIoT
the IoTDNS
IoT
IoT DNStesting
DNS
DNS testing based
testing
testing based on
based
based on the
on the scenario
the scenario described
described
scenariodescribed
scenario describedabove.above.
above.
above.WhenWhen
When
When thethe
thethe
oneM2M
oneM2M
oneM2M
oneM2M client
client is
client
client connected
is connected
is isconnected to the
to
connectedtotothe oneM2M
the oneM2M
theoneM2M server, the
server,
oneM2M server, user
the is provided
user
server, the user is
user is with
provided
is provided a list
with
providedwith ofa resources
list
witha alist of available
resources
listofofresources
resources
available
to the
availableuser.
available to
to to the
Figure
thethe user.
user.
user. Figure14
14Figure
shows
Figure 14shows
an
14 showsan
example
shows anof
an example ofinterface.
a clientof
example
example aa client
client interface. The
The example
client interface.
interface. example
provides
Theexample
The provides
exampleprovides thethe
the resource
provides the
resource
number,
resource
resource number,
resource name,
number,resource
number, resource
and IPname,
resourcename,
name,and and
address.
andIP IP
When address.
the
IP address. When
user the
selects
address. When the user
the
the user selects
required
user selects the required
service,
selectsthe the
therequired service,
oneM2M
requiredservice, thethe
client
the
service,
oneM2M
transmits
oneM2M client
theclient
requesttransmits
to the
transmits the request
connected
the to the
oneM2M
requesttoto connected oneM2M
server.oneM2M
theconnected
connected server.
oneM2M server.
oneM2M client transmits the request the server.

Figure 14.
Figure 14. Example
Example of
of the
the oneM2M
oneM2M client
client interface.
interface.
Figure 14. Example of the oneM2M client interface.
Sensors 2019, 19, 1433 13 of 16
Sensors 2019,
Sensors 2019, 19,
19, xx FOR
FOR PEER
PEER REVIEW
REVIEW of 16
13 of
13 16

The oneM2M server compares the received resource number with the database and checks if it is
The oneM2M
The oneM2M server
server compares
compares thethe received
received resource
resource number
number with
with the
the database
database and
and checks
checks if
if it
it
a request to a oneM2M device. The first column in the database table, as shown in Figure 15, represents
is aa request
is request toto aa oneM2M
oneM2M device.
device. The
The first
first column
column in in the
the database
database table,
table, as
as shown
shown inin Figure
Figure 15,
15,
the resource number. The present study uses a configuration in which platform number 1 refers to the
represents the resource number. The present study uses a configuration in which platform number 11
represents the resource number. The present study uses a configuration in which platform number
oneM2M platform, number 3 refers to the Watson IoT platform, and number 5 refers to the FIWARE
refers
refers to the
to the oneM2M
oneM2M platform,
platform, number
number 33 refers
refers to
to the
the Watson
Watson IoT
IoT platform,
platform, and
and number
number 55 refers
refers to
to
platform.
the FIWARE Since all
FIWARE platform. services
platform. Since registered
Since all in
all servicesthe example
services registered table
registered inin the belong to
the example number
example table 3 and
table belong number
belong to
to number5 without
number 33 and
and
the
number 51,without
number the oneM2Mnumberserver
1, sends
the a request
oneM2M to the
server roota DNS.
sends request to the root DNS.
number 5 without number 1, the oneM2M server sends a request to the root DNS.

Figure 15.
Figure 15.
Figure IoT DNS
IoT DNS
15. IoT database
DNS database example.
database example.
example.

The root
The root DNS
rootDNS identifies
DNSidentifies the
identifiesthe request
the from
request
request thethe
from
from the oneM2M
oneM2M
oneM2M server. In scenario
server.
server. In scenario 1, since
since1,it
In scenario
1, itsince
is aa request
is request
it is a
to aa Watson
Watson
request
to IoT
to aIoT device,
Watson thedevice,
IoT
device, the root DNS
root DNS generates
root DNSaagenerates
thegenerates request statement
request statement
a request used by the
the Watson
statement
used by Watson
used by IoT
IoTtheplatform.
Watson
platform.
Figure
IoT 16 shows
platform. the
Figure code
16 that
shows generates
the codethe request
that statement
generates the using
request the Watson
statement IoT
using resource
the
Figure 16 shows the code that generates the request statement using the Watson IoT resource request Watsonrequest
IoT
format.
resource
format. request format.

Figure 16.
Figure
Figure 16. Requests
16. Requests code
code for
for LED on/off.
LED on/off.
on/off.

If the
If the root DNS successfully
root DNS generates and
successfully generates
generates and sends
and sends the
sends the request
the request to
request to the
to the Watson
the Watson IoT,
Watson the user
IoT, the user can
can
control the LED sensor. As shown in Figure 17, if a request is successfully
control the LED sensor. As shown in Figure 17, if a request is successfully generated, it is presented generated, it is presented
through the
through the Node-RED
Node-RED console console window
console window of
window of the
the sensor
sensor device.
device. As As shown
As shown in
shown in Figure
Figure 18a,
18a, the
the user can
user can
check if the requests were successfully authenticated and received
check if the requests were successfully authenticated and received using the dashboard provided byusing the dashboard provided by
the IBM
the IBM cloud.
cloud. If If the
the rootroot DNS
DNS uses
uses an invalid value
an invalid value (e.g.,
(e.g., device
device ID,
ID, path,
path, token
token value),
value), thethe user
user isis
presented with an ‘invalid value’ message, as
presented with an ‘invalid value’ message, as shown in Figure 18b. shown
shown in
in Figure
Figure 18b.
18b.
In scenario
In scenario 2, 2, ifif the
the root
root DNS
DNS identifies
identifies the
the request
request fromfrom the the oneM2M
oneM2M server,
server, since
since it
it is
is aa request
request
to aa FIWARE
to FIWARE
FIWAREdevice, device,the
device, theroot
the rootDNS
root DNSgenerates
DNS generatesa arequest
generates a request
request statement
statement
statement used
used
usedbyby thethe
by FIWARE
the FIWARE
FIWARE platform.
platform.
platform.If the
If
If
root
the DNS
root DNS successfully
successfully generates
generates andandsends
sends thetherequest
request to tothe
theFIWARE,
FIWARE,
the root DNS successfully generates and sends the request to the FIWARE, the user can get and update the
the user
user can
can get
get and
and update
thestatus
the statusof
status ofLED
of LEDsensor.
LED sensor.
sensor. Then,
Then,
Then, if the
if the
if the user
useruser selects
selects
selects the LED:on,
the LED:on,
the LED:on, the DNS
the root
the root root gets
DNS DNS gets
gets the
the the of
status
status status
LEDof
of LED LED
sensor
sensor
sensor
and
and andthe
sends
sends sends
the the update
update
update requestrequest
request that LED
that thatstatus
LED LED status
status ‘on’isto
is ‘on’
is to‘on’ to FIWARE.
FIWARE.
FIWARE. Next,Next,
Next, as shown
as shown
as shown in Figure
in Figure
in Figure if19,
19, if
19, aa
if a request
request is
request is successfully
is successfully
successfully generated, generated,
generated, the the result
the result
result is is presented
is presented
presented through through
through the the console
the console window
console window
window of of the
of the sensor
the sensor
sensor
oneM2M client. The user also can check the current status
oneM2M client. The user also can check the current status and changed status. and changed status.

Figure
Figure 17.
Figure 17. Success
17. Success message
Success message of
message of the
of the LED
the LED request
LED request in
request in Node-RED.
in Node-RED.
Node-RED.
 Sensors 2019, 19, x FOR PEER REVIEW 14 of 16
Sensors 2019, 19,
Sensors 2019, 19, 1433
x FOR PEER REVIEW 14 of
14 of 16

(a) Success message (b) Invalid message

(a) Success message (b) Invalid message
Figure18.
Figure 18.LED
LEDrequest
requestmessage
messageininIBM
IBMcloud.
cloud.
Figure 18. LED request message in IBM cloud.

Figure19.
Figure 19.Status
Statusinformation
informationof
ofthe
theFIWARE.
FIWARE.
Figure 19. Status information of the FIWARE.
5.5.Conclusion
Conclusionand andFuture
FutureWorks Works
5. Conclusion and Future Works
Currently,
Currently,there thereisisno noclear
clearsolution
solutionfor forthetheinterworking
interworkingofofdevices devicesbelonging
belongingtotoheterogeneous
heterogeneous
IoT Currently, there is work,
no clear solution for the interworking of devices belonging to heterogeneous
IoT platforms. In this work, we proposed a solution to these problems, named
platforms. In this we proposed a solution to these problems, named IoT IoTDNS,DNS,whichwhich
IoT platforms.
converts In this work, we proposed a solution to these problems, named IoT DNS, which
convertsrequests
requestsfrom fromaaoneM2M oneM2Mdevice deviceto tothe
theappropriate
appropriaterequest requestformat
formatfor forinterworking
interworkingbetween between
converts
heterogeneous requests from a oneM2Manalyzed device to the resource appropriate request format fordevice interworking between
heterogeneousIoT IoTplatforms.
platforms.We We analyzedthe the resourcerequest requestformats
formatsand and deviceID IDsystems
systemsused used
heterogeneous
in IoT platforms. We analyzed the resource request formats and deviceOliot, ID systems used
inheterogeneous
heterogeneousIoT IoTplatforms
platformsand andselected
selectedseveralseveralIoT IoTplatforms
platforms (i.e.,
(i.e., oneM2M,
oneM2M, Oliot, Watson Watson IoT, IoT,
in heterogeneous
IoTivity, and IoT platforms
FIWARE). Furthermore, and selected
we created several IoT platforms
scenarios of (i.e., oneM2M,
implementation and Oliot,
carried Watson
out IoT,
testing
IoTivity, and FIWARE). Furthermore, we created scenarios of implementation and carried out testing
IoTivity,
based and FIWARE). Furthermore, we created scenarios of implementation and carried out testing
basedon onthese
thesescenarios.
scenarios.The Thescenarios
scenariosincluded
included aauser userwithwithaaoneM2M
oneM2Mdevice deviceusing usingaaWatsonWatsonIoT IoT
based
and on these
FIWARE scenarios.
service. The The
testingscenarios
results included
show that aauser with a oneM2M
oneM2M-based device device using a performed
successfully Watson IoT a
and FIWARE service. The testing results show that a oneM2M-based device successfully performed
and FIWARE
resource service.
requests The
to atoWatson testing
IoTIoT results
andand show
FIWARE that
sensora oneM2M-based
devices. device successfully performed
a resource requests a Watson FIWARE sensor devices.
a resource
Most requestsstudiesto a Watson IoT aand FIWARE sensor devices.
Most related studies propose a solution based onthe
related propose solution based on theIPEIPEmethod
methodspecified
specifiedby bythe theoneM2M
oneM2M
Most
standard related studies propose a solution based on the IPE method specified by the oneM2M
standardorganization.
organization.IPE IPEconverts
convertsresources
resourcesin inheterogeneous
heterogeneousplatforms platformsto tothe
theoneM2M
oneM2Mresource resource
standard
structures organization.
and, in addition, IPE creates
convertsresources
resources in in
theheterogeneous
gateways. platforms
Hence, it is to efficient
not the oneM2M resource
memory-wise
structures and, in addition, creates resources in the gateways. Hence, it is not efficient memory-wise
structures
atatthe and, in addition, creates resources in the gateways. Hence,changing
it is not efficient memory-wise
thegateways
gatewaysowing owingtotothe theresources
resourcesbeing beingnewly newlycreated
createdby byonly
only changingthe thestructure.
structure.On Onthe the
at the
contrary,gateways
the IoT owing
DNS to the
stores resources
only the being
logical newly created
location of by
the only changing
resources, not the
the structure.
entire On
resource,the
contrary, the IoT DNS stores only the logical location of the resources, not the entire resource, and
contrary,
and directlythe requests
IoT DNSthe stores only the
resource logicalthislocation of theneeded.
resources, not the entire resource, and
directly requests the resource usingusingthis value value needed.
when when Therefore, Therefore,
the memory the memory
usage of the usage IoT
directly
of the IoTrequests
DNS is the
far resource
less using this
significant than value
that when
of the needed. Therefore, the memory usage of the IoT
IPE.
DNS is far less significant than that of the IPE.
DNSIn is far less significant than that fiveof the IPE. and presented a demonstration scenario involving
Inthis
this work,
work, we analyzed
we analyzed five platforms
platforms and presented a demonstration scenario involving the
the In this work,
oneM2M, Watson we analyzed five platforms and presented a demonstration scenario involving the
oneM2M, Watson IoT,IoT,andand FIWARE
FIWARE platforms.
platforms. However,
However, in order
in order to add
to add a newa new IoTIoT platform,
platform, we
oneM2M,
we should Watson
manually IoT, and
register FIWARE platforms. However, in order to add a new IoT platform, we
should manually register its its
ID ID system
system in IoT in IoT
DNS. DNS. Moreover,
Moreover, cloud-based
cloud-based IoT IoT platform
platform (i.e., (i.e.,
IBM
should
IBM manually
Watson register its ID functionality
system in IoT DNS. Moreover,IoT cloud-based IoT platform (i.e., IBM
Watson IoT) IoT)
havehave limited limited
functionality in theinproposed the proposed IoT DNS becauseDNS because we arewe notare ablenotto able
directlyto
Watson
directly IoT)
modify haveit. limited
Furthermore,functionality
security in issues
the proposed
should IoT
be DNS because
considered in we IoT
the are DNS.
not able For toexample,
directly
modify it. Furthermore, security issues should be considered in the IoT DNS. For example, devices
modify
devices it. Furthermore, security issues should be considered inshould
the IoTbeDNS. For example, devices
or usersorthat userswant
that to want usetoservices
use services
in other in other platforms
platforms should identified,
be identified, authenticated,
authenticated, and
or
and users that
authorized want
in to
advance. use services
That is, in
security other platforms
policies for should
secure be
access identified,
to resources authenticated,
in heterogeneous and
authorized in advance. That is, security policies for secure access to resources in heterogeneous IoT
authorized
IoT platforms in advance.
should That is, security policies for secure
futureaccess
work,to resources in heterogeneous IoT
platforms should be be defined.
defined. Therefore,
Therefore, in inour ourfuture work, we
we will expand
will expand the IoT
the IoT DNSDNS toto
platforms
automatically should be defined. Therefore, in our future work, we will expand the IoT DNS to
automaticallystore storethe therequest
requestformatformatof ofworldwide
worldwideIoT IoTplatforms
platformsand anduse usethethefunction
functionprovided
providedby by
automatically store the request format of worldwide IoT platforms and use the function provided by
Sensors 2019, 19, 1433 15 of 16

the cloud-based platform. In addition, our work will be extended by adding device authentication and
authorization to the supported resource request processes. Consequently, these security policies will
be properly applied to the IoT DNS to limit unauthorized access.

Author Contributions: The authors contribute of this paper as follow: J.K. wrote this article, analyzed the
heterogeneous platforms, and performed implementation; S.-R.O. performed and coordinated the implementation;
Y.-G.K. supervised and coordinated the investigation .
Funding: This research was supported by a grant of the Korea Health Technology R&D Project through the Korea
Health Industry Development Institute (KHIDI), funded by the Ministry of Health & Welfare, Republic of Korea
(grant number: HI18C1140).
Conflicts of Interest: The authors declare no conflict of interest.

References
1. Koo, J.H.; Kim, Y.G. Interoperability of device identification in heterogeneous IoT platforms. In Proceeding
of the IEEE International Computer Engineering Conference (ICENCO), Cairo, Egypt, 27–28 December 2017.
2. oneM2M Partner Transpositions. Functional Architecture (TS-0001-V2.18.1). Available online: http://www.
onem2m.org/images/files/deliverables/Release2A/TS-0001-Functional_Architecture-v_2_18_1.pdf
(accessed on 10 January 2019).
3. GS1 Standards: Internet of Things. GS1 and the Internet of Things. Available online: https://www.gs1.org/
sites/default/files/images/standards/internet-of-things/gs1-and-the-internet-of-things-iot.pdf (accessed
on 10 January 2019).
4. GS1. GS1 Standards and IDMP IDMP and GS1 Standards. Available online: https://www.gs1.org/sites/
default/files/docs/events/2016/berlin/breakout_hospital_pharmacyandfmd.pdf (accessed on 10 January
2019).
5. Kim, D.Y.; Jung, S.K.; Kim, S.T.; Byun, J.U.; Woo, S.P.; Kwon, K.W.; Yoon, Y.D.; Heo, S.H.; Im, J.G.; Jun, T.J.
GS1 international standard for fusion of global IoT based on data. J. Korean Inst. Commun. Sci. 2016, 34,
41–56.
6. OID Repository. Available online: http://www.oid-info.com/ (accessed on 10 January 2019).
7. IBM Cloud Docs. IoT (Watson IoT Platform). Available online: https://console.bluemix.net/docs/services/
IoT/devices/device_dev_index.html#device_dev_index (accessed on 13 January 2019).
8. OIC. Introduction of OIC Standard. Available online: https://openconnectivity.org/wp-content/uploads/
2016/01/OIC_Specification_Overview_201501131.pdf (accessed on 13 January 2019).
9. IoTivity Wiki. Common Resource. Available online: https://wiki.iotivity.org/common_resources (accessed
on 13 January 2019).
10. OCF Specification. OCF Core Specification Version 2.0. Available online: https://openconnectivity.org/
specs/OCF_Core_Specification_v2.0.0.pdf (accessed on 10 January 2019).
11. OCF Specification. OCF Security Specification Version 2.0. Available online: https://openconnectivity.org/
specs/OCF_Security_Specification_v2.0.0.pdf (accessed on 10 January 2019).
12. OCF Specification. OCF Device Specification Version 2.0. Available online: https://openconnectivity.org/
specs/OCF_Device_Specification_v2.0.0.pdf (accessed on 10 January 2019).
13. FIWARE-ORION DOCS. Available online: https://fiware-orion.readthedocs.io/en/1.4.0/index.html
(accessed on 9 March 2019).
14. oneM2M Partner Transpositions. OIC Interworking (TS-0024-V2.0.2). Available online: http://www.
onem2m.org/images/files/deliverables/Release2A/TS-0024-OIC_Interworking-v_2_0_2.pdf (accessed on
13 January 2019).
15. Wu, C.W.; Lin, F.J.; Wang, C.H.; Chang, N. OneM2M-based IoT Protocol Integration. In Proceeding
of the IEEE Conference on Standards for Communications and Networking (CSCN), Helsinki, Finland,
18–20 September 2017.
16. Kang, S.; Chung, K. IoT Framework for Interworking and Autonomous Interaction Between Heterogeneous
IoT Platforms. In Proceeding of the International Conference on Smart Computing and Communication
(SmartCom), Tokyo, Japan, 10–12 December 2018.
Sensors 2019, 19, 1433 16 of 16

17. Tao, M.; Ota, K.; Dong, M. Ontology-based data semantic management and application in IoT- and
cloud-enabled smart homes. Future Gener. Comput. Syst. 2017, 76, 528–539. [CrossRef]
18. Tao, M.; Zuo, J.; Liu, Z.; Castiglione, A.; Palmieri, F. Multi-layer cloud architectural model and ontology-based
security service framework for IoT-based smart homes. Future Gener. Comput. Syst. 2018, 78, 1040–1051.
[CrossRef]

© 2019 by the authors. Licensee MDPI, Basel, Switzerland. This article is an open access
article distributed under the terms and conditions of the Creative Commons Attribution
(CC BY) license (http://creativecommons.org/licenses/by/4.0/).