xxx

1. 26
CHAPTER 3
OPEN IoT TESTBED- UTILITY
IoT is a system of interconnected things that can communicate with each other
to interact and exchange data. IoT aims at connecting anything, anytime and anywhere
in the world. In 2013, the Global Standards Initiative on Internet of Things (IoT-GSI)
defined the IoT as "the infrastructure of the information society" [100].
A typical information processing system of today’s world consists of one or
more inputs, an application to process the input into the output of the system, and can
also communicate with other such systems. Figure 3.1 is a typical information
processing system.
Figure 3.1 A typical information processing system
A core component of an IoT system is the underlying embedded system/device.
These embedded systems include sensors that are used to measure physical parameters
of the environment such as temperature, light intensity, humidity, etc., or user
interactive inputs such as push buttons or potentiometers, etc., The sensors can be
digital or analog. Outputs include actuators, devices that can perform physical actions
such as emitting light as in the case of a LED, or producing wind as in the case of a fan,
etc., The actuators usually digital, but many of them do support analog operations via
Pulse Width Modulation (PWM).

2. 27
3.1 BACKGROUND
The processing unit of these systems is microcontrollers. The sensors, actuators
and the communication devices are interfaced with the microcontrollers and the
application code is flashed onto the microcontroller. The entire processing can be done
by the microcontroller itself or it can simply send data to an aggregator, which gets the
data from multiple sources, and the application is deployed on the aggregator. The
aggregator is usually a high-powered microcontroller or a microcomputer. One
important fact to keep in mind is that these microcontrollers are highly resource
constrained devices. Resources such as the computational power, the memory, etc., are
constrained on these microcontrollers. They can be in the form of motes, which are
proprietary and user/owner specific, or they can be open source platforms such as the
Arduino [101], which are not proprietary. The open source platforms benefit from a
large community support and are preferred over the proprietary boards. They have
libraries being developed for different sensors, actuators and communication devices.
SimpleDHT.h, LiquidCrystal.h and Ethernet.h are a few of the many libraries available
to use, developed for the Arduino platform.
IoT systems use a range of communication protocols. The systems can
communicate with each other via protocols such as Ethernet [102], Wi-Fi [103],
Bluetooth Low Energy [104], ZigBee [63], Radio Waves, to name a few. Typical
application protocols developed for the internet include HTTP [105], HTTPS [106],
FTP [107], Telnet [108], etc., These protocols are highly resource intensive and are not
best suited for resource constrained devices which are usually used in IoT systems.
There are several application level protocols developed for IoT systems, two
major protocols are Constrained Application Protocol (CoAP) [109] and Message
Queuing Telemetry and Transport (MQTT) [110]. CoAP works on a client server model
and is thus synchronous in nature. MQTT works on a publish subscribe model and the
communication is thus asynchronous in nature. Differences between the two protocols
are tabulated in Table 3.1.
The architecture proposed in this research work uses the MQTT protocol for
data transfer. This protocol requires a protocol broker to manage the data transfer
between the clients. Multiple clients can publish data to a MQTT protocol broker at a

3. 28
time and multiple clients can subscribe to the broker for the same data at the same time.
The protocol uses topics, a client will publish a message on a topic and all the clients
that are subscribed to the same topic will receive the message at the same time.
Table 3.1 Difference between CoAP And MQTT protocols
CoAP MQTT
Model Request/Response
(Synchronous)
Publish/Subscribe
(Asynchronous)
Creator IETF IBM
Abbreviation Constrained Application
Protocol
Message Queue Telemetry
Transport
Transport Layer UDP TCP
Security DTLS TLS/SSL
Mode of operation Client should request for an
update to the server
The client receive updates
automatically on those topics
to which it is subscribed with
the broker
Merits Light weight (due to UDP).
Less overhead is required
for reliability
Lower network bandwidth
utilization.
Less message processing,
saving battery life.
Security achieved through
username/password at broker
via TLS/SSL
Less packet loss achieved by
TCP retransmission
Demerits No native security.
Likely more loss of packets.
Some overhead due to the
underlying TCP protocol
Figure 3.2 shows a basic IoT architecture. P. Fremantle has provided similar
architecture [96] level detailing of IoT. A typical IoT system comprises of many input
and output devices. The input devices can be of analog or digital. The system has to do

4. 29
necessary conversions if there is incompatibility in its support. It becomes pretty
obvious, that having connected with so many input devices, the amount of data that
pool in exceedingly high. Mechanisms need to be incorporated to handle such
scenarios. With the advent of technologies like big data and cloud in collaboration with
IoT is becoming a reality. There can be varied mechanisms with which a researcher or
academician or industrialist would handle or process the data. The goal is to reduce
his/her burden to understand the underlying infrastructure and provide it abstracted as
he or she can focus on the research/business logic at hand. Even if they did develop and
implement these systems on their own, they would have to repeat it for different
locations or different scenarios and this would result in an unnecessary learning curve
that they would have to go through.
Figure 3.2 Basic IoT architecture
This proposal provides a solution for this problem by providing the dynamic
sensor data as service, resolves actuator conflicts through the proposed algorithm, offers
dynamic resource discovery and mapping through control plane driven architecture.

5. 30
3.2 PROPOSED OPEN IoT ARCHITECTURAL FRAMEWORK
Building reliable IoT based technology solutions and services that can be
deployed at scale require adequate experimentation environments. Testbeds are
preferred tools to validate research contributions and to provide platform for
development. They provide remote access to test technological solutions and there by
validate. Most of the existing IoT testbeds are extension attempt towards IoT, not native
IoT testbeds.
Figure 3.3 Proposed testbed architecture
Most of the existing testbeds are local and proprietary testbeds, which are used
by industries [111] for their product testing purposes. The academics do have testbeds
for their testing on new protocols they develop, but they too are localized. Few testbeds
are available which can be accessed remotely, but they are platform and language
dependent, free style third party development not available. Most importantly all that

6. 31
which are available are made with tech-savvy or developers in mind, what if an end
user wants a small modified application to be deployed and tested, such a simplified
composition layer is still missing. Free available APIs which can be used by everyone
irrespective of their skill sets is yet in its infancy and also the modality (methodology
used to communicate like: HTTP, TCP model) used favors much of a traditional
systems, which will definitely be heavy on constrained things which is addressed in
IoT. In order to address the above issues, this research work proposes an open IoT
testbed cum development environment with a control plane capable of discovering
resources/services, orchestrate based on user demands, communicate through pub-sub
model, resolve conflicts and interference through lock release model. Figure 3.3 is the
architectural framework of the proposed testbed.
3.2.1 Implementation of Solution
Figure 3.4a Functional architecture of the proposed open IoT architectural
framework
A utility is a composition of services which are offered in controlled manner.
The proposed research work is to design a control plane which is capable of

7. 32
resource/service discovery, orchestration and resolving conflict. Figure 3.4a illustrates
the functional architecture of the proposed open IoT architectural framework.
Resources refer to boards and the sensors and actuators connected to it. These
underlying resources are discovered and the data generated from them or their
functionality is offered as service. Once the above phase of discovery is over, the system
is ready to accept and cater user demands at run time.
Figure 3.4b Detailed architecture of the proposed open IoT architectural
framework

8. 33
The needed user interface is designed which receives user demands and
communicates to the underlying control plane orchestration service to decide on the
availability mapping. Virtualizing actuator is never the same as sensor. A sensor can be
virtualized and the data can be shared to all without due interference. Such is not the
case with actuators. In case of actuators, they can receive commands, what if multiple
users issue multiple commands to a single actuator. This needs to be resolved. This is
resolved by the control plane’s conflict resolve module. This proposed framework is
designed along with an API capable of reserving and releasing locks. The proposed
system has shown better utilization after the incorporation of this API at the control
plane.
The detailed architecture of the proposed architectural framework in Figure 3.4b
provides with particulars dissected at each layer. The users have been broadly classified
as academician, naive user, industrialist, analyst and researcher. The classification is
arrived based on the most probable clients of the testbed. The services provided can be
used by each user depending on their application needs and requirements. The services
offered can be categorized as sensor, actuator, platform and API. The operations that
can be performed on or using each of the services vary based on the potential and
capability offered by the service. For instance, read from sensor, write command on to
actuator, read, write and execute on a platform and API can be downloaded,
incorporated and executed. Now having said this, there should be a module that
discovers the available services, maps it appropriately with demands of the users,
resolve conflict if needed. Thus to achieve this, the control plane offers three main
services discovery, orchestrate and conflict resolve. This is achieved using underlying
blocks namely registration, provisioning, conflict resolve, persistence and application
data transmission. Service discovery involves two phases namely registration of
services in the testbed and provisioning. This is achieved using an automated polling
model to develop a look up table of available services. Then the provisioning model
inspects the user requests and maps appropriately with the available services. If the
service demanded is actuator, then the same procedure is followed along with the
conflict resolve which determines, the service to be offered to one among many requests
using lock and release model. In case of sensor as service, it is proposed to optimize the
service based on time stamping and change capture. The database queried is updated
only on change as to reduce the unnecessary traffic and the sensor is not queried every

9. 34
time a request arises. This provides substantial performance improvement compared to
query every request model. This is taken care of by the persistence block. The
application data transmission takes care of data being retrieved and offered to user in
the data format demanded by the user. There are logical layers that do the magical
integration between the user end and the control plane blocks. The status reflects the
availability to the user of the underlying services, time slot booking etc., Also there is
a parameter block which comes handy in case of double service offered by single sensor
say humidity and temperature measured from a single DHT11. In this proposed
research, it is not addressed as a single service instead as two independent services for
optimized performance.
3.2.1.1 Resource Discovery
Resource/Service discovery: Resources refer to boards and the sensors and
actuators connected to it. These underlying resources are discovered and the data
generated from them or their functionality is offered as service. In existing systems
there is fixed set up of resources which user has to access from the user interface portal
[112]. No research has reported yet on automated resource/service discovery on the
dynamic addition of sensors/ actuators. The resource discovery layer in the proposed
architecture is capable of finding the resources newly added and update without human
intervention to the user interface. This has improved the overall performance and
availability of the proposed testbed in the user’s point of view.
3.2.1.2 Orchestration
After the completion of discovery phase, the system is ready to accept requests
from users. The interface behaves as a communication link between the user commands
and the underlying resources. The interface talks to the underlying orchestration control
plane which does the final availability check and mapping. The orchestrator is a script
which runs every time the user request reaches the interface. The sole purpose of
orchestrator is to avoid unnecessary requests reaching the underlying layers. If not taken
care of, there will be wastage of precious computational resource and energy. An
empirical result showed that a device can generate around 18000 requests per second.
The point to be noted is that the ratio of availability vs. requests is alarmingly less. Thus
this proposed orchestrator layer will provide optimized mapping eliminating or in other

10. 35
words filtering out unnecessary requests to travel down the other layers.
3.2.1.3 Resource Conflict
Virtualizing the actuator is a bit challenging when compared to virtualizing the
sensors. The reading from the sensor can be shared across multiple users without the
issue of interference. The only concern would be the format of data demanded by the
user. In this research work, appropriate scripts have been developed and incorporated
which is capable of converting to any standard format needed for transfer. XML, JSON,
CSV are the available data formats, a user can choose from. The case with actuator is
being an output device, it receives commands from outside. The real challenge is when
multiple commands are targeted to available actuators. There are decisions needed as
how many actuators are available, which command to be given to which actuator etc.,
Half of this problem is already addressed by the resource discovery and orchestration
layer as to provide availability and instances. Moreover, an actuator under use and the
time it is available for next usage also needs to be known. This research proposal also
proposes API’s exclusively for lock and release. This keeps track of which user, which
actuator and when it is released. This history also helps to filter out unnecessary
requests to the same actuator, thereby resolving conflict. The proposed system has
shown improved performance after the incorporation of this API at the control plane.
3.3 RESULTS AND DISCUSSION
The resource discovery provides the available resources in the testbed. The
resources can be accessed through the service list provided in Figure 3.5. The
underlying protocol adopted is MQTT with Mosquito as the protocol broker. It follows
publish- subscribe model which works with topics. But in the proposed system, a
mapping scheme is created as shown in Table 3.2.

11. 36
Figure 3.5 Consolidated service set
Table 3.2 Proposed service mapping scheme
Category ID Resource Sub-Resource ID
Instance
ID
REST Mapping
ID
(Hex)
Data 1 Sensor Temperature 1 NA GET 0001
Humidity 2 NA GET 0001
Gas leakage 3 NA GET 0001
Rainfall detection 4 NA GET 0001
Color 5 NA GET 0001
Actuation 2 Actuator Buzzer 1 1…n GET/POST 0101
LCD Display 2 1…n GET/POST 0101
Fan 3 1…n GET/POST 0101
GSM 4 1…n GET/POST 0101
RGB LED 5 1…n GET/POST 0101
Code port 3 Platform Arduino 1 1…n GET/PUT/POST 0111
Galileo 2 1…n GET/PUT/POST 0111
Pi 3 1…n GET/PUT/POST 0111
Software 4 API Sensor 1…n NA GET/PUT/POST/
DOWNLOAD
1111
Actuator 1…n NA GET/PUT/POST/
DOWNLOAD
1111

12. 37
This scheme provides saving in memory when compared to the traditional string
based approach. Thus for instance the topic iottestbed/dht11/+/humidity will reduce to
<~/1.1.1.2>. The “+” is the service specific ID which helps identify the root of the
parameter. Thus the proposed mapping scheme takes far less memory compared to the
generic topic based approach. The reason being obvious with string stored in heap and
integer stored right at stack along with the memory allotted for each character makes
the string based topic more memory hungry compared to the proposed approach. Thus
this approach takes 8 bytes, whereas string delegated as character array may occupy
~27 to 30 bytes neglecting the language specific details like class pointers, flags, locks,
hash, offset and size.
Thus, Pc=(Be-Bp)/Be*100=~70%,
where, Pc is percentage change in memory requirement, Be is bytes for existing
models, Bp is bytes for proposed model.
Figure 3.6a is the output showing the boards discovered. Figure 3.6b is the
screen shot showing the result of the script exposing the gas, rainfall and temperature
sensors being active and ready to be offered as service to users/developers/analysts.
Figure 3.6a-3.6b: Boards discovered as resources; Screenshot of sensor resource
discovery
The details acquired are updated in the database for orchestrator to map based
on user needs and resource availability. The screen shot in Figure 3.7 shows the status
of gas sensor on two respective boards.
Figure 3.7 Screenshot of database update

13. 38
The time taken by the resource/service discovery module to explore the
underlying sensor/actuator clients, sensors/actuators is provided in Figure 3.8a-3.8c.
Figure 3.8a illustrates that the time involved to detect the sensor/actuator clients
resource is not greater than 8ms. Though this is an overhead, this helps to achieve
efficient resource discovery and orchestration in the proposed research claim. The
experiment was conducted with 100 trials.
Figure 3.8a: Sensor/actuator clients detection time
Figure 3.8b significantly illustrates the time taken to detect the underlying
sensor/actuator resource is not greater than 2.5s. This is the extra cost incurred in order
to achieve efficient resource discovery and mapping. The experiment was conducted
with 100 trials.
Figure 3.8b: Sensor/actuator detection time
0
0.001
0.002
0.003
0.004
0.005
0.006
0.007
0.008
0.009
0 20 40 60 80 100
Time
(s)
Trial
Time (s)
0.00
0.50
1.00
1.50
2.00
2.50
3.00
0 20 40 60 80 100 120
Time
(s)
Trial
Time (s)

14. 39
Figure 3.8c signifies the time taken to detect the disconnected sensor/actuator
resource. The time measured is not more than 6ms. This cost is tradeoff with
unnecessary requests aimed at a non-existing service. The experiment was conducted
with 100 trials.
Figure 3.8c: Disconnected sensor/actuator time
Figure 3.9 shows the user request hit ratio. The system is tested with and without
lock of actuator instances. The graph clearly illustrates that proposed system
outperforms in the request hit ratio compared to the systems without dynamic update
of resources using lock and release in which case there is a clear degradation of hit ratio
on increasing request rates.
Figure 3.9: User request hit ratio
0
0.001
0.002
0.003
0.004
0.005
0.006
0.007
0 20 40 60 80 100
Time
(s)
Trial
Time (s)
0%
20%
40%
60%
80%
100%
120%
0 25 50 75 100
Response
Rate
(%)
Trial (User Request)
Hit Ratio (without
Lock_Release)
Hit Ratio (With
Lock_Release)

15. 40
The reason for the degradation of hit ratio can be justified with an example.
Assume there is one actuator service. There is no way in existing systems the user is
updated of the available and under use service, due to which there will be n requests of
which only one gets served. This is mitigated in this work, through lock acquire and
update, based on which no unwanted requests are initiated thereby. The results
demonstrate the improvement in utilization and reusability through the inclusion of the
virtualization, concurrency enabled and orchestrated control plane.
3.4 CONCLUSION
This research work proposes an open IoT testbed framework as a utility. The
existing testbeds are extrapolation of wireless sensor motes and in most cases the
prevailing testbeds are proprietary [13] [37] [48] [82]. As already stated most of
experimental results are tested and verified using simulation tools which lag real time
accuracy. Unexpected device failure due to various reasons like fault, wear/tear, and
energy drains where never considered on real grounds. This proposed framework has
sorted the issues through the resource detection via control plane orchestration and the
heterogeneity is achieved through various board and component variants. The open
source boards are deployed to overcome vendor lock in and proprietorship.
The proposed framework is also incorporated with resource/service discovery,
orchestration and conflicts resolve. The newly added boards/sensors/actuators can be
discovered at runtime through the resource discovery/service discovery algorithm
eliminating the existing static models. The orchestration algorithm dynamically maps
the request with the availability status arrived with resource discovery algorithm. The
resource conflict algorithm eliminates the excessive request initiation as against the
availability status. This provides the needed optimization and performance
enhancement in terms of time and service utilization as depicted in the results section.