IEEE Consumer Electronics Magazine - January/February 2020 - 26

Smart Home

as it handles the gateway-initiated discovery
response message.
On-Boarding, Commissioning, and Device
Binding: An interoperability framework should
provide a mechanism to on-board a device not
only from the perspective of one machineto-machine technology but for all supported network technologies. IoT-Connect maintains a set
of keys to on-board devices on different networks. Moreover, it also maintains the list of network keys used in different available networks.
The purpose of on-boarding and commissioning
in IoT-Connect is to act as a proxy for devices
belonging to different networks and on-board
them on to other available networks. This process gives an impression to the underlying network as if the on-boarded devices belong to the
same network. As one of the goals of IoT-Connect
is to enable the control of devices's resources
through other devices, e.g., turning on the light
controlled by one device using a switch on
another device, which may use a different communication standard, a further purpose of this
module is to create device binding among heterogeneous devices based on different communication standards and protocols. This module
stores the commissioning information in the
commissioned devices register.

Device Information Base
The purpose of introducing the device information base in IoT-Connect is to obtain a uniform representation of resources' URI,
attributes, interfaces, access rights, and security
policies. We use the resource representation
model that is being standardized by oneIoTa.11
The device information base is populated at the
gateway during the resource discovery and onboarding process. The device information base
also stores the following information about any
resource: communication standard, network
layer address, application end point/port number, transport protocol, and application layer
protocol. In IoT-Connect, the device information
base enables the devices to communicate with
devices and applications over the cloud as well.
Hence, due to uniform resource representation
a single application can be used to control or
communicate with different devices over the
Internet as well.

Translation Module
IoT-Connect's translation module comprises
of the following submodules:
1.
2.
3.
4.
5.
6.

URI mapping registers,
message translation logic,
scene/group management,
observer register,
confirmable request register, and
commissioned devices register.

URI Mapping Registers: An interoperability
framework needs to expose a resource in one
kind of network to a device in another kind of
network. Therefore, each discovered resource's
URI needs to be assigned a URI that is unique
and compatible with the URI format supported
by other types of available networks. For this
reason, IoT-Connect maintains URI mapping
registers at the gateway, and there is a separate
register for each communication standard supported by the gateway.
Message Translation Logic: This submodule
deals with mapping one application layer message to another application layer message. Let
us consider that a ZigBee switch based on the
home automation profile sends a command to
turn ON a thread-based light. When the message
arrives at the gateway, the gateway hands over
the application layer message to the translation
module along with the information about the
communication standard used by the switch.
The mapping logic extracts the destination
device's network information, transport protocol information, application layer information,
and real URI by consulting the resource directory and URI mapping register corresponding to
the source device's (switch) communication
standard. Afterwards, it maps the source device
application layer message to the destination
device application layer message. The process
consists of the following steps: convert the
source application message to a common application layer protocol (CoAP12 is a possible candidate for the common application layer protocol)
message, afterwards map the common application layer message to the destination application
layer message.
Observer Register: Let us assume that a CoAPbased resource wants to observe a ZigBee-based
temperature sensor. Therefore, the CoAP-based

IEEE Consumer Electronics Magazine

IEEE Consumer Electronics Magazine - January/February 2020

Table of Contents for the Digital Edition of IEEE Consumer Electronics Magazine - January/February 2020