Implementation and Performance Analysis of

Interoperable and Heterogeneous IoT-Edge

Gateway for Pervasive Wellness Care

By
Sumitra
 What is interoperability
• Interoperability is basically the ability for systems or components of systems to
communicate with each other, regardless of their manufacturer or technical
specifications.
•  The interoperability issues in IoT can be seen from different perspectives due to
heterogeneity. Heterogeneity is not a new concept nor restricted to a domain.
Even in the physical world there are many types of heterogeneities for example,
people speak dissimilar languages, but they can still communicate with each
other through a translator (human/tools) or by using a common language.
Likewise, the diverse elements comprising IoT (devices, communication, services,
applications, etc.) should seamlessly cooperate and communicate with each
other to realize the full potential of IoT ecosystem.
Types of interoperability
• Device interoperability
• Networking interoperability
• Syntactic interoperability
• Semantic interoperability
• platform interoperability
Structure of the type of interoperability
Device interoperability
• The high-end IoT devices have enough resources and computational
capabilities such as Raspberry Pi and smartphones. On the other hand,
the low-end IoT devices are resource-constrained in terms of energy,
processing power and communication capabilities than typical hosts
such as RFID tags, tiny and low-cost sensors, and actuators, Arduino,
and Open Mote to name a few. How they communicate to each other
• Device interoperability is concerned with (i) the exchange of
information between heterogeneous devices and heterogenous
communication protocols and (ii) the ability to integrate new devices
into any IoT platform.
cont.
• For example, IoT devices such as Smart TV, printers, air conditioners
support traditional ubiquitous Wi-Fi technologies and 3G/4G cellular
communications. Most recent IoT medical devices are based on ANT+
standard; other wearable devices mostly support Bluetooth SMART
and NFC, while the environmental sensors use ZigBee-based on IEEE
802.15.4 standard. Besides these protocols, the standard
communication protocols are utilised for smart devices, sensor, and
actuators (i.e., Z-Wave, ZigBee, and Wireless Hart) as well as the non-
standard proprietary solution (i.e., LoRa, SIGFOX).
• In the absence of a de-facto communication standard(s), not all smart
devices implement all these communication technologies. In some
cases, the devices that want to exchange information may be using
different communication technologies which requires interoperability
between the different types of heterogeneous devices that co-exist in
the IoT ecosystem. 
Network interoperability

• Network level interoperability deals with mechanisms to enable

seamless message exchange between systems through different
networks (networks of networks) for end-to-end communication. To
make systems interoperable, each system should be able to exchange
messages with other systems through various types of networks. Due
to the dynamic and heterogenous network environment in IoT, the
network interoperability level should handle issues such as
addressing, routing, resource optimization, security, QoS, and mobility
support
Syntactical interoperability

• Syntactic interoperability refers to interoperation of the format as well

as the data structure used in any exchanged information or service
between heterogeneous IoT system entities. An interface needs to be
defined for each resource, exposing some structure according to
some schema.
•  Syntactic interoperability problems arise when the sender’s encoding
rules are incompatible with the receiver’s decoding rules, which leads
to mismatching message parse trees.
Platform interoperability
• Platform interoperability issues in IoT arises due to the availability of
diverse operating systems (OSs), programming languages, data
structures, architectures and access mechanisms for things and data.
There are currently many different OSs developed specifically for IoT
devices such as Contiki, RIOT, TinyOS and Open WSN , each with
several versions, to deliver services to users. Besides, the IoT platform
providers such as Apple HomeKit, Google Brillo, Amazon AWS IoT, and
IBM Watson provide different Oss, programming languages, and data
structures. For example, Apple HomeKit supports its own open source
language Swift, Google Brillo uses Weave, and Amazon AWS IoT offers
SKDs for embedded C and NodeJS. This non-uniformity causes
hindrance for application developers to develop cross-platform and
cross-domain IoT applications.
Interoperability handling approaches in IoT

• Adapters/gateways
• Virtual networks/ overlay-based solutions
• Networking technologies
Adapters/gateways
• Gateways or adapters are the class of schemes which address
interoperability through the development of an intermediate tool
sometimes called mediators to improve interoperability between IoT
devices. The objective here to bridge between different specifications,
data, standards, and middleware’s etc. To perform a conversion
between the protocol of the sending device and the protocol of the
receiving device, the gateway can be expanded with the use of plug-ins.
For example, when IoT devices use dissimilar communication
technologies (i.e., Bluetooth and ZigBee) or when they use dissimilar
application layer protocols (i.e., XMPP and MQTT). Gateways can be
dedicated hardware, or the function can be embedded in the firmware
or software of an intelligent device such as a programmable logic
controller (PLC), human-human interface (HMI), or computer. 
Virtual networks/ overlay-based solutions
• Virtual networks or Overlay-based solutions have been proposed in the
“Managed Ecosystems of Networked Objects” (MENO), with the aim to
integrate sensor and actuators and other IP-smart objects seamlessly to
the Internet for end-to-end communication. The main idea behind
MENO is to create a virtual network on top of physical networks and
thereby allow communication with other types of devices, including
sensor nodes. Within each virtual network, end-to-end communication
is possible using different protocols. Once end-to-end communication is
enabled, it becomes possible for application developers to write new
applications that utilize sensors, actuators, and other devices.
 Purpose to this study
• The purpose of this study aims at development of a highly
interoperable and heterogenous tool-set supporting IoT-edge gateway
and respective communicable IoT-edge motes that convert one
protocol-message format into another seamlessly under cost-effective
and resource-constrained environment. Moreover, distributed
consumer’ wellness care applications are developed and tested
against the validation of the deployed
IoT-edge gateway’s efficacy, energy distribution, and appropriateness
toward its proposed goals. In this regard, three popular protocols,
including (i) 2.4 GHz ISM Radio-Frequency (RF), (ii) IEEE 802.11b/g/n,
and (iii) Bluetooth are hereby integrated into a single IoT-gateway
platform to harness the ultimate super-interoperability among these
heterogeneous protocols.
Problems in Existing IoT-Gateways for Wellness
Care
• Most of the existing IoT-gateways have paved support only for the 3G,
Ethernet, Wi-Fi and 4GLTE based communications standards . They
are highly stringent and rigid in terms of their interoperability,
protocol selection, mobility and high cost. None of them supports the
LPWEN protocols thus in-creasing the power consumption aspects.
These gateways are only effective when popular communication
standards and technologies are availed by the consumers. Lack of
interoperability and dependency over proprietary cloud platforms
make those solutions less prominent and attractive for consumer’
wellness care scenarios that certainly needs consumer-centric
flexibility toward sensor-data transmission over the network
Experimental methodology
• Methodology is formulated to include three LPWEN protocols, e.g.,
IEEE 802.11 , RF 2.4 GHz ISM and Bluetooth 2.4 GHz altogether along
with the two virtual mote-protocols for development of an
interoperable IoT-gateway. The proposed IoT-gateway shall provide
the facility to any consumer belonging from any economic class to get
instantaneous consumer’ wellness services by means of low power
consuming infrastructure.
IoT-Gateway Implementation
• The proposed IoT-gateway is developed on a 1.4 GHz 64-bit quad-core
ARM v8 processor. It is meant to be responsible for continuous
reception of sensor-messages, originating from respective LPWEN-IoT
based consumer’ wellness motes. RF 2.4 GHz, Bluetooth and IEEE
802.11b/g/n protocol stacks and libraries are integrated into the IoT-
gateway. We attached a 2.4 GHz ISM antenna with the IoT-gateway
over the General Purpose I/O pins, rest of the protocols are
automatically handled due to the in-built antenna design. The IoT-
gateway initially attempts to establish a local ad-hoc connectivity with
the local IoT-based consumer’ wellness motes that gets disseminated
via the internal MQTT message broker service to specify the actual
source and destination.
Materials Used
• Mote controller unit: RISC-based 328P based on 8-bit microcontroller is used
to host the wellness -motes to sense the vitals and transmit the consumer’
wellness data packets to the IoT-gateway
• Open source WiFi-IoT device
• IoT-gateway controller unit: 1.4 GHz 64-bit quad-core processor is used to
natively support the Ethernet, IEEE 802.11n and Bluetooth 4.0 networking
capabilities.
• IoT-Cloud: Existing IoT wellness care cloud-based Representational State
Transfer (REST)/Constrained Application Protocol (CoAP) application
programming interface (API) to perform healthcare consumer’ wellness data
analytics
Packet Structure Address Mapping
Cont.
How system become Interoperable
• Each IoT-mote in the proposed edge-network uses different wellness
data format transmission protocols so they are physically
incompatible with each other. But the proposed IoT-gateway makes it
possible to relay consumer’ wellness data from one IoT-mote to
another. The IoT-gateway is responsible for transforming the required
wellness data formats and protocols so that the message can be
transmitted between the various motes
Diagram
IoT-Edge Gateway System Data Flow
The process of beginning of data flow sequence is as follows:
(i) RF Mote Handler – for handling the RF aspects of the IoT-gateway,
(ii) BTH Handler – for handling the Bluetooth aspects of the IoT-gateway
(iii) TEST 1 Handler – for handling Test mote 1
(iv) TEST 2 Handler – for handling Test mote 2
(v) Wi-Fi Mote Handler – for handling the Wi-Fi aspects of the IoT-gateway,
(vi) TOPIC DISTRIBUTER – responsible for handling the various motes and
their assigned message topics,
(vii) PACKET ROUTER – starting up the packet router process and (ix) IoT
Handler – for handling IoT cloud communication.
Packet generation flow chart (RF)
Packet generation flow chart (WIFI)
Packet generation flow chart (TS1)
Packet generation flow chart (BTH)
Physical Implementation
2.4 GHz RF and bluetooth modules are attached with the RISC 8-bit
microcontroller for acting like IoT-mote inrespective protocols. Open
source WiFi-IoT device is connected via IEEE 802.11b/g/n protocol with
the IoT-gateway. We did not include RISC 8-bit microcontroller into host
thisWiFi-based module due to its own efficiency in terms of
microcontroller enablement and decision-making process. Physical
health sensors such as, H-Sen1, H-Sen2 and H-Sen5 are used where
generic pulse rate sensor, SPO2 sensor and GSR sensors Whereas, HV-
Sen3 and HV-Sen4 are used as virtual sensors attached with the TS1
and TS2 virtual nodes to simulate the consumer’ wellness care
application that includes virtual pulse rate and SPO2 monitoring,
respectively.
Routing Throughput Analysis
IoT-mote produces1 packet per second. In each mote, the first 500ms
are reserved for consumer’ consumer’ wellness data transmission and
the remaining 500ms are reserved for consumer’ wellness data
reception. Currently there are 5 motes so a total of 5 packets are
generated per second in the network. This implies that in 1 second, 5
packets are routed to their respective destinations.
Routing throughput = 5 packets/second. Estimated time spent by each
packet awaiting routing is (1/5) ∗ 1000ms = 200ms