gb

1. viii
DESIGN AND IMPLEMENTATION OF INTERNET OF THINGS (IoT) TESTBED
FRAMEWORK- A PERFORMANCE ENHANCED APPROACH
This Dissertation is submitted to the university of [University Name] to fulfil the Partial
Requirements for the Degree of [Degree Name]
Awarded to:
[Student Name]
[Date]

2. viii
ABSTRACT
Internet of Things (IoT) is a technology which aims at connecting all the devices in the
world to create a real global village. It has led to a digital ecosystem that surrounds around
the data that these devices generate and the decisions that can be madewith the help of this
data. Building reliable IoT based technology solutions and services that can be deployed at
scale require adequate experimentation environments. Gartner’s predictions and other
literature reviews clearly indicate the need to design and implement heterogeneous test bed
that uses a virtualized environment. The need for a heterogeneous test bed comes into the
picture due to the existence of both analog and digital sensors, and also due to huge range of
micro controllers that are available in themarket these days.
The focal point of the thesis is to design a utility based open IoT testbed cum
development framework accessible locally and over the internet that targets developers and
data engineers to create and test IoT applications and perform analytics on the datagenerated
respectively. If the end user wishes so, the data being archived in the database can be
downloaded to his/her workstation either is a CSV, JSON or XML format as demanded.
Distributable (Application Programming Interface) API’s are provided to developers to
develop IoT Applications. This API contains custom built libraries that have functions to
retrieve the data from the sensor or publish command to the actuator.This is achieved by the
API publishing the command to the actuator or subscribing to the broker only once and once
the required data is received from the sensor, the method disconnects from the broker. This
API can run on any machine that is connected to the internet. Also the required experimental
setup and needed algorithms are deployed andits impact on utilization, performance and time
is studied. This research work aims at

3. ix
providing solutions for the challenges behind the proprietary vendor lock in, insufficient
control, lack of concurrency and diminished reusability.
There are four main objectives of this research. Primarily investigate the
characteristics, technologies and methodologies of existing testbeds, identify the gaps and to
design and implement a utility based open IoT testbed cum development framework
architecture with appropriate maneuvering at physical and logical dimensions. Secondly
develop, load and test necessary platform independent API’s to achieve utility based service
model. Third objective is to develop a control plane driven model with number based service
mapping and appropriate algorithms for dynamic resource discovery, orchestration and
conflict resolve. Next objective is proposing an event collaboration model of sensor service,
instance based actuator service, OTA platform service with appropriate algorithms and API’s
and to admire the enhancement in performance as well as reduction in response time. Finally,
to develop a feedback based ranking model, aiming towards better utilization, reliability and
performance. Also, use appropriate tools and methods to understand the mostly used
services, most demanded cluster of services and user usage pattern.
This research work to demonstrate the proof of concept will be focusing on micro-
controllers variants from Arduino which supports analog devices and Raspberry Pi, a
microcomputer that can run a full-fledged operating system, to account for this heterogeneity
of devices and controllers. The test bed will also host a range of sensors like temperature,
humidity, pressure, light intensity, rainfall, gas sensors. These sensors are going to be
virtualized into containers that represent the Things in Internet of Things. These containers
are going to represent what the object oriented paradigm calls objects. The objects represented
in OOPS are only digital or a simulation of the real world objects at the very best, but with
IoT these objects are going to represent almost

4. xxi
every “thing” in the real world. These containers will also add modularity to the system, and
also allows the end user to develop applications that use only a subset of the sensors
provided. These containers will be accessed over the Internet by the end user and it
provides the data and the functionality of the sensors, actuators, platform as a service over
the internet enabling them to develop IoT applications that can be hosted on the cloud.
In nutshell, this research work is an attempt towards product based research, still
with its performance metrics intact, as against usual analysis or simulation only studies.

5. xxii

6. xxiii
LIST OF ABBREVIATIONS & SYMBOLS
ABBREVIATIONS
IoT - Internet of Things
WSN - Wireless Sensor Network
WSAN - Wireless Sensor Actuator network
LED - Light Emitting Diode
LM - Linear Monolithic
DHT - Digital Humidity Temperature
LDR - Light Dependent Resistor
MQTT - Message Queuing Telemetry and Transport
GSN - Global Sensor Network
SSW - Semantic Sensor Web
IrisNet - Internet-scale Resource-Intensive Sensor Network
Services
LoWPAN - Low-Rate Wireless Personal Area Networks
Minos - Message Identification and Online Storage
Desthino - Distributed Embedded Systems Online
IPSO - IP Smart Objects
CoAP - Constrained Application Protocol
FIT - Future Internet Testing
IoT-GSI - Global Standards Initiative on Internet of Things
PWM - Pulse Width Modulation
HTTP - Hyper Text Transfer Protocol
HTTPS - Hyper Text Transfer Protocol Secure

7. xxiv
FTP File Transfer Protocol
IETF - Internet Engineering Task Force
IBM - International Business Machines
UDP - User Datagram Protocol
TCP - Transmission Control Protocol
DTLS - Datagram Transport Layer Security
TLS - Transport Layer Security
SSL - Secure Socket Layer
XML - Extensible Markup Language
JSON - JavaScript Object Notation
CSV - Comma Separated Variable
REST - REpresentational State Transfer
GSM - Global System for Mobile
RGB - Red Green Blue
ID - Identification
OS - Operating System
UI - User Interface
PHP - Personal Home Page
DB - Database
XAMPP - Cross-Platform Apache MySQL PHP Perl
IP - Internet Protocol
DNS - Domain Name System
ESP - Espresiff Systems
SMS - Short Message Service
USB - Universal Serial Bus
IPv4 - Internet Protocol Version 4

8. xxv
IPv6 - Internet Protocol Version 6
QoS - Quality of Service
CPU - Central Processing Unit
LCD - Liquid Crystal Display
SIM - Subscriber Identification Module
IDE - Integrated Development Environment
POSIX - Portable Operating System Interface
ASPI -
Advanced Small Computer System Interface
Programming Interface
MBPS
µIP
µIPv6
- Mega Bits Per Second
Micro Internet Protocol
Micro Internet Protocol version 6
ith sensor service, i ∈ 1 to n
jth parameter of each sensor, j ∈ 1 to m
ith Actuator, i ∈ 1 to n
jth
instance of Ai, j ∈ 1 to m
ith Platform, i ∈ 1 to n
Time between failures
Time to restore
At least one successful resource
Failure with degrading or nil available resource
Number of platforms offered for service
Academician, i ∈ 1 to n
Industrialist, i ∈ 1 to n
SYMBOLS
Si -
Pj -
Ai -
Kj -
Pli -
ti -
tj -
S -
F -
N -
Aci
-
Ii -

9. 1
Di - Data analyst, i ∈ 1 to n
Ri - Researcher, i ∈ 1 to n
Ni - Novice user, i ∈ 1 to n
R - Reliability
P′ - Performance
L - Low
M - Medium
H - High
P(R=ri,P′
=Pi
′
) - Probability that R takes ri and P′
takes pi
′
, i=l,m,h
P(ri,pi
′
) - Probability mass function, i=l,m,h
PR(ri) - Marginal probability function of reliability R, i=l,m,h
(ri,pio) - Marginal distribution of reliability
(rio,p′i) - Marginal distribution of performance
PP
′
(pi
′
) - Marginal probability function of performance, i=l,m,h
f(R,P′)/f(P′=low) - Conditional distribution of reliability, P′=low
f(R,P′)/f(P′=medium) - Conditional distribution of reliability P′=medium
Tl - f(P′
=low)
Tm - f(P′
=medium)

10. 1
xvi
LIST OF TABLES
TABLE NO. TITLE PAGE NO.
3.1 Difference Between CoAP And MQTT Protocols 28
3.2 Proposed service mapping scheme 36
4.1
Example of CSV, JSON & XML data generated by
the interface 49
4.2 Sample set of 10 consecutive reading 57
4.3 Scenario based comparison table 58
4.4 Message receiving and updation rate 64
6.1 Services vs. users feedback matrix 97
6.2 Confusion matrix 98
6.3
Joint probability function of the discrete random
variables R(Reliability) and P′(Performance) 99
6.4 Sample set of performance measure of services 101
6.5 Sample set of most demanded services 102

11. 1
LIST OF FIGURES
FIGURE NO. TITLE PAGE NO.
1.1 LED 3
1.2 Buzzer 3
1.3 LM35- Analog temperature sensor 4
1.4 DHT11- Digital temperature sensor 4
1.5 Light Dependent Resistor (LDR) 5
1.6 IR LED and IR photodiode 5
1.7 Organization of thesis 16
2.1 Comparison chart of proposed vs. existing testbeds 24
3.1 A typical information processing system 26
3.2 Basic IoT architecture 29
3.3 Proposed testbed architecture 30
3.4a Functional architecture of the proposed open
IoT architectural framework
31
3.4b Detailed architecture of the proposed open
IoT architectural framework
32
3.5 Consolidated service set 36
3.6a Boards discovered as resources 37
3.6b Screenshot of sensor resource discovery 37
3.7 Screenshot of database updates 37
3.8a Sensor/actuator clients detection time 38

12. 1
3.8b Sensor/actuator detection time 38
3.8c Disconnected sensor/actuator time 39
3.9 User request hit ratio 39
4.1 Sample record database displayed in the Web UI 47
4.2 Visualization of DHT11’s temperature data 48
4.3 Visualization of DHT11’s humidity data 48
4.4 Experimental prototype for sensor client 51
4.5 Communication model for sensor client 52
4.6 Conversation flow between the protocol broker, message
broker and the database
54
4.7 Structure of the table for sensors with single
parameter
58
4.8a Structure of the table for sensors (DHT11) with
multiple parameters
58
4.8b Structure of the table for sensors (color) with
multiple parameter 58
4.9 Experimental setup of the proposed system
(sensors interfaced with sensor client and connected
to the Router)
59
4.10 Event collaboration model vs. traditional request
response model
60
4.11 Comparison on updation time: Approach 4 outperforms 61
4.12 Gas sensor table updation time 62
4.13 Sensor database entries 63

13. 1
4.14 Snapshot of the database showing the table content
for DHT11 sensor 65
5.1 Actuator Client-an experimental prototype 72
5.2 Request response of actuator client 73
5.3 Resource access through the resource requisition algorithm 75
5.4 Acquiring lock through getLock API 78
5.5 Release lock through releaseLock API 79
5.6 Platform as a service- an experimental prototype 81
5.7 A module of experimental set up for platform as service 82
5.8 Slot based interaction between user and the web UI 83
5.9 WebUI interface 83
5.10 Illustration of a sample API function call 85
5.11 Snapshot demonstrating API package download 86
5.12 Snapshot to demonstrate the use of sample API functions 86
5.13 API for sensors and actuators 87
5.14a-5.14b API Execution time for sensors and actuators
accessed locally 88
5.14c-5.14d API Execution time for sensors and actuators
accessed from remote
89
5.15 Snapshot of API call and response 90
5.16 Compilation and upload time comparison between
Arduino IDE and the proposed testbed service
91
6.1 Allocation decision tree 95
6.2a State machine for testbed service 96

14. 1
6.2b State transition graph for testbed service 96
6.3 Service usage pattern and the utilization
(successful access) rate
103
6.4 User usage rate of the proposed testbed 104
6.5a Novice user usage pattern 104
6.5b Academic user usage pattern 105
6.5c Industrial user usage pattern 105
6.5d Data analyst usage pattern 106
6.5e Researcher usage pattern 107

15. 1
CHAPTER 1:
INTRODUCTION
Testbed is a real experimental set up which helps researchers, industrialists and
students to test and validate their research findings or protocols or algorithms
developed. There are two kinds of result validation: simulation and real experimental
testbeds. The testbeds are broadly classified based on their field say industrial or
research. Furthermore, it gets its name based on the field it is associated with say
wireless sensor network testbeds, sensor testbeds, actuator testbeds etc.,
There are so many new technologies coming up, but when investigated, all of
them had roots from the previous technologies. For instance, Cloud had its roots from
web services, big data from databases. Similarly, one another popular technology
Internet of Things (IoT) has its roots deep in sensor and actuator networks or in simple
to say, Wireless Sensor Actuator Networks (WSAN) [1]. IoT is predicted to be the web
4.0 version or in other words the “future internet” [2].
Research work in the field of Wireless Sensor Networks (WSN) [3] is very
exhaustive and deep because of the scope for many new sensor-based developments [4]
and their challenges [5] associated because of its constrained nature [6]. The nature of
operation of WSN is unique in the sense; it is constrained on energy, computation and
memory. Research has been carried out in energy optimization techniques at various
level including routing aspects [7]. But the interesting fact is most of the research
validations were performed on simulators as against real testbeds. The reasons being:
heavy infrastructure cost, lack of reusability, lack of interoperability, proprietorship [8]
and many more. Still there were few research proposals validated on experimental
testbeds.
As IoT was considered extension of WSN in most cases, any research proposal
of IoT was also validated on WSN testbeds. Though there are similarities in features like

16. 2
constrained on memory, energy etc., but there are some prominent differences too [9].
This demands an exclusive testbed model for IoT system as such. This chapter will
introduce the basics of IoT, its features, its ingredients, its challenges and the
justification for the need for an open source IoT testbed [10] against its proprietary
counterparts in WSN.
1.1 INTERNET OF THINGS
IoT [11] is all about connecting anything, anytime and anywhere in the world.
It is estimated that the number of internet connected things in the world would rise to
50 billion by 2020 [12]. The IoT is an emerging topic of technical, social, and economic
significance. Consumer products, durable goods, cars and trucks, industrial and utility
components, sensors, and other everyday objects are being combined with internet
connectivity and powerful data analytic capabilities, that promise to transform the way
we work, live, and play. Projections for the impact of IoT on the Internet and economy
are impressive, with some anticipating as many as 100 billion connected IoT devices
and a global economic impact of more than $11 trillion by 2025 [13].
1.2 INGREDIENTS OF IoT
IoT is a technology aiming at interconnecting everything in the world via the
internet backbone to achieve seamless connectivity. It uses IPv6 to uniquely identify
everything/device which it encounters. The whole idea of interconnection is to exploit
services across boundaries. Various existing technologies were able to provide efficient
solutions but in silos. Thus, IoT attempts to bridge the gaps be it across devices or
application or network or communication medium. IoT is a culmination of embedded
systems, sensors, actuators, cloud communicated via wired or wireless means toachieve
smart solution [14] to various fields be it smart home, smart irrigation, smart electricity,
smart cities [15], smart “X” (X can be substituted with almost any word, that is the
power of IoT solutions). There are many components which are very

17. 3
important in the building up of an IoT solution [16], but sensors and actuators take the
front seat. Sensors and Actuators are explained in the following topic.
1.2.1 Sensors and Actuators
Sensors are input devices. The sensors are capable of sensing parameters like
temperature, humidity, pressure, acceleration etc., Actuators are output devices capable
of reacting to commands. Testbeds comprises of exhaustive set of input and output
devices. Examples for actuators can be LED, buzzers, relays etc.,
 LED: Light Emitting Diode (LED) the most basic way of representing the
output. Long legs (+ve) connected to output pin and short legs (-ve) connected
to ground. When the value in the output pin goes high, LED Glows. Figure 1.1
is the image of an LED.
Figure 1.1 LED
 Buzzer: It is usually a piezo electric buzzer. Connect as the same way as an
LED. The +ve goes to output pin and –ve goes to ground. Figure 1.2 is the
image of a Buzzer.
Figure 1.2 Buzzer

18. 4
 LM35: Linear Monolithic (LM35) is an analog temperature sensor. The
conversion formula between analog reading and temperature in celsius
temperature = value/9.31, where value is the analog reading received from the
LM35. This is much suitable for microcontroller boards which support analog
pins, e.g. Arduino. Figure 1.3 is the image of LM35.
Figure 1.3 LM35- Analog temperature sensor
 DHT11: Digital Humidity Temperature (DHT11) is a digital temperature
sensor. This sensor is suitable to measure temperature and humidity. They
can provide 20 to 80% humidity readings and 0 to 50 degrees temperature
readings with 5% and (+/-) 2% accuracy respectively. The input voltage ranges
between 3 to 5 volts. Their pins can be configured as input or output as needed.
Figure 1.4 is the image of DHT11.
Figure 1.4 DHT11-Digital temperature sensor
 LDR: Light Dependent Resistor (LDR) is also known as photocell or photo
resistor. It is made of high resistance semiconductor. The name signify their
way of working. The resistance varies based on light incident on it. The

19. 5
resistance decreases on increased light intensity (few hundred ohms) and the
resistance increases on diminished light intensity (MΩ). This phenomenon is
called as photoconductivity. They can be employed in variety of applications
like detector and switching circuits. Figure 1.5 is the image of LDR.
Figure 1.5 Light Dependent Resistor(LDR)
 IR PAIR: Infra- Red (IR) pair has an IR LED and IR photodiode. The IR LED
transmits infrared light and the IR photo diode is a photo resister sensitive to IR
light. The IR photodiode is basically reverse biased, so care to be taken during
connection. Also, the combination of IR pair can be used replicate a proximity
sensor. Figure 1.6 is the image of IR pair.
Figure 1.6 IR LED and IR photodiode
1.3 FEATURES OF IoT
IoT [17] have very interesting features when compared to other counterparts
who took their places in Gartner’s prediction like Big Data, Cloud, Quantum

20. 6
Computing, and Smart Robots. IoT has spared no technological field left to collaborate
with. All the technologies listed here have distinctive boundaries which is not the case
with IoT. Thus, one could see overlapping features and every domain expert would feel
connected in collaboration with IoT with much ease.
1.3.1 Sensing and Actuating
Sensors, Actuators are the important components as far as IoT is concerned.
Sensors are basic input devices which help sense various environmental parameters like
temperature, humidity, pressure and many more. With the collected readings necessary
actions can be taken using output devices, the actuators. The actuator can be as simple
as a LED or as complex as a robotic arm [18].
1.3.2 Communication
Communication is considered very important in the transportation of data
measured at one end to reach the other. IoT works comfortable with any communication
technologies. For instance, wireless (Wi-Fi), wired (Ethernet), IR, zigbee, etc.,
1.3.3 Processing, Assimilation and DecisionMaking
The data collected from the sensors before sent to the actuators will encounter
processing based on the application demand. The processing can basically happen at
three levels: low, middle and high. Low level processing is technically called as edge
computing as it happens locally within the device or in the premises of measurement.
Middle is the processing which happens at the level of gateway. Normally this is named
as Fog computing [19]. It gets its name as it is above ground and below the cloud. High
level processing mostly happens remotely. Cloud computing is the technology deployed
to do this kind of processing.
1.3.4 Storage
Data storage is very vital in the context of IoT. The data accumulated for a long
period of time eventually contributes to legacy data sets which can be the inputs for
data analysts and data scientists. Depending on the infrastructure and nature of the data,

21. 7
it can be stored at three different levels. They can be stored at the device, gateway or
cloud [20].
1.4 CHARACTERISTICS OF IoT
It becomes extremely difficult to bring out the characteristics of IoT, for the
reason it is tricky to draw finite boundaries for IoT as a technology. Given any
technology for that matter, IoT has a root manifested or its branches spread out.
However, attempts have been made to justify agreeable characteristics for IoT namely
heterogeneity, dynamicity, scalability, interoperability, energy requirements, smartness
and data centricity. As it is already discussed, name any domain or technology, there
will be a role and relationship to IoT. However, recent observations have categorized
few of them based on its priorities as important characters for an IoT system.
1.4.1 Heterogeneity
The variety of sensors and actuators with which an IoT system has to interact is
so vast that it is inevitable that it supports heterogeneity. Thus, an IoT system has to
work across all verticals for seamless interconnection and communication thereby [21].
1.4.2 Dynamicity
IoT comprises of things or devices which need to react or respond to events or
environmental changes. The primary objective of an IoT system is much more than
mere automation, which demands smartness. Thus, dynamicity becomes an inevitable
quality for an IoT system.
1.4.3 Scalability
The IoT system comprises of components which are energy constrained. This
brings in situation wherein the nodes or devices may fail. In those cases, the system
should be able to cope up failure and also accept new nodes to match the loss of few of
them. Sometimes it becomes the need of the hour to expand horizontally the existing

22. 8
infrastructure to support growing demands. IoT does this gracefully to grow or shrink
in its network size making scalability a feature.
1.4.4 Interoperability
Having said heterogeneity is the quality of an IoT system, it is natural that it has
to support interoperability. IoT achieves it via standard data exchange formats and
standardized protocols to an extent possible. But, Gartner’s prediction [22] confirms
IoT at its peak of inflation and notifies that it may take a few more years for a highly
reliable standard. Till then it would be managed with adaptation layers or middleware
systems [23] or gateways [24]. According to researchers it is considered too early to
talk about standard hardware or software or protocol for an IoT system. As of now every
company or industry is working to create their version of IoT to suit their requirements
in their respective fields [25].
1.4.5 Energy Requirements
IoT systems have their applications in all the important fields including
wearable and portable devices. Some IoT devices will be deployed in remote areas like
forest, volcanoes, mountain peaks etc., adding up problem to the already energy
constraint nature of these systems. Recent innovations have started incorporating energy
harvesting mechanisms as part of IoT devices. IoT have penetrated in to medical field
[26], which requires more of energy efficient and portable devices. IBM have come up
with IBM Watson IoT based Health solution [27]. The advent of IoT is transforming
every field to its next dimension, particularly health sector which is the basic necessity
for every human being [28] [29] [30]. Thoughtful research has startedof late in medical
industry to design IoT based medical devices tailor made based on the needs of the
patient, disease and the treatment [31]. Also, Samsung have developed an IoT based
medical platform to prove the importance of IoT in the field of health care[32].
1.4.6 Smartness
IoT is smartness. Every IoT system default prefixes the word “smart” to any of
its application. Examples can be smart house, smart grid, smart city etc., The challenge

23. 9
is how to add smartness factor in to these dumb things. Artificial Intelligence and
Machine Learning experts are working very close with IoT systems to add the needed
smartness. Researchers are also discussing the transition of M2M towards IoT [33].
1.4.7 Data Centric vs. Address Centric
Personal computers can be reached with the help of IP address. They are more
of an address centric system. Simple WSN’s are mostly looked for their data and not
interested in which sensor provides it. But, IoT in other hand needs to identify as well
communicate the data. This makes IoT a special category neither traditional computer
systems nor mere sensor networks. IoT is best of both worlds. Thus IoT is a data cum
address centric system. Example can be a user needs to know the temperature of a room
(data centric) and/or to update a firmware (address centric) as well.
1.4.8 Connectivity and Availability
As the main aim of an IoT system is to interconnect the various system outputs
as inputs to other systems, connectivity becomes an important feature. Connectivity
promises round the clock availability of services to varied users. Example, the weather
forecast station can feed its predictions about rain to the sensors in the garden to decide
about switching on or off the sprinkler. This needs uninterrupted connectivity. This is
the reason why IoT relies on the solid backbone of connectivity, the internet, though
there are other mediums to communicate. IoT systems do include features like fault
tolerance, resilience and to some extent redundancy.
1.4.9 Ease of Use
Everything developed has one undeniable goal, help solve problems thus serve
humankind directly or indirectly. Any system deployed, if demands huge learning curve
would not really solve instead complicate. Thus, it is very important for IoT systems to
have a rich user interface developed with meticulous design.
1.4.10 Security
IoT systems so far focused mostly on making things smarter, expansion of
services and ease of usage. Iota of work has gone in the security aspect of an IoT system

24. 10
[34]. Though there are security at all levels at which an IoT system interacts, forgetting
the very point of the vulnerability of the IoT end device. The security compromised at
the device level is definitely a deadly breach, sometimes fatal. Researchers have started
taking the area of security in the context of IoT in its serious consideration [35]. There
exist effective security algorithms, but the challenge being they cannot be applied to
IoT systems as they are energy and memory constrained in most cases [36].
1.5 NEED FOR OPEN SOURCE IoT TESTBEDS
Testbeds as already highlighted plays a very important role in the field of
research. It becomes inevitable to subject the research model for testing and validation
through some kind of standard testing tool. Research proposals which need to converted
to a product or deployed in any real time environment or real time device is strongly
recommended to validate on these kinds of real testbeds as against traditional
simulators. Thus, it makes research on testbeds even more vital and meaningful.
Most of the existing testbeds are not indigenous or in other words from the
scratch IoT testbeds [35]. 90% of the existing testbeds which are used for testing IoT
systems are basically designed with WSN in mind [37]. Most of them have homogenous
devices [38]. Even if they are heterogeneous, they are proprietary. This complicates
scaling and switch over farther more reachable. Interoperability and reusability have
become questionable [39].
This paved the way for this research to come up with open source heterogeneous
IoT testbed framework with enhanced algorithms to improve reusability, scalability and
utilization factor. Utilization factor is usually defined as how much time a system is
really accessible for usage against its total availability.
1.6 MOTIVATION AND PROBLEM STATEMENT
The applications of IoT, the breakthrough technology, are countless and its
development involves various people of different knowledge bases and different skill

25. 11
sets [40]. The amount of sensors, actuators and devices which goes in the making of
IoT is so huge, that one can realize that there is under exploitation when compared to
the enormous cost invested in the sensor and actuator infrastructure. Also, an
extraordinary amount of data will be generated from these applications [41] [28] on
which a large amount of analytics can be done by data analysts [42]. These analysts
consider the data to be the end product of IoT systems and work on the same. A
considerable amount of time is spent by them in developing or implementing the IoT
systems that generate this data [43]. At the same time, the IoT raises significant
challenges that could stand in the way of realizing its potential benefits like
proprietorship, interoperability issues, demand for heterogeneity, difficulty in switch
over or migration, vendor lock-in etc.,
This research work attempts to design, develop and implement a performance
enhanced heterogeneous, open source IoT testbed which can be offered as service to
users irrespective of their level of skill set. Thus, this work proposes a solution
mitigating the existing problems, by providing a testbed as well as a development
environment as a serviceover the internet to end users and developers. The end users
are thus abstracted from the underlying complexities involved in developing the IoT
system, allowing them to focus on what they do best.
1.7 OBJECTIVES AND SCOPE OF THE WORK
The main objective of the dissertation is to design a utility based open IoT
testbed cum development framework and study its impact on utilization, performance
and time. The focal point of this dissertation is providing solutions for the challenges
behind the proprietary vendor lock in, insufficient control, lack of concurrency and
diminished reusability. In nutshell the objectives can be listed as:
1. Investigate the characteristics, technologies and methodologies of existing
testbeds, identify the gaps and to design and implement a utility based open
IoT testbed cum development framework architecture with appropriate
maneuvering at physical and logical dimensions.

26. 12
2. Develop, load and test necessary platform independent (Application
Programming Interface) API’s to achieve utility based service model
3. Develop a control plane driven model with number-based service mapping
and appropriate algorithms for dynamic resource discovery, orchestration
and conflict resolve
4. Proposing an event collaboration model of sensor service, instance-based
actuator service, OTA platform service with appropriate algorithms and
API’s and to achieve the enhancement in performance as well as reduction
in response time
5. Finally, to develop a feedback based ranking model, aiming towards better
utilization, reliability and performance. Also, appropriate tool is employed
to understand the mostly used services, most demanded cluster of services
and user usage pattern
1.7.1 DevelopOpen IoT Testbed as a Service Utility
Utility computing means 'on-demand computing' that follows a pay-as-you-go
model. You pay only when you need them or use only when you need them. Utility
comprises of services, but can offer in a metered or controlled manner. This research
contribution proposes a framework/model that can enable the same. The advantages of
this framework are, the utility enhances resource utilization through virtualization and
reduces CAPEX and OPEX. In order to offer testbed as a utility this research work have
designed algorithms to offer sensors, actuators and platforms as service.
The proposed testbed is developed with open-source boards to achieve
interoperability and heterogeneity which also overcomes the challenges of vendor lock-
in namely: fear of obsolescence, shifting or migration issues, deters innovation and
dynamicity, lack of interoperability, lack of standardization and lack of open-source
entities. The proposed framework is realized with a live experimental set up which
provides a better orchestration of services through software defined control plane,
enhanced concurrency and improved reusability through virtualization of sensors,
actuators and platforms.

27. 13
1.7.2 DevelopAPI’s to Achieve Utility BasedModels/Services
Message Queuing Telemetry and Transport (MQTT) an application layer
protocol (publisher/subscriber model) is very supportive for API development. This
standard protocol can be used to aggregate data from different sensors/actuators and
given to the user in a format they request. MQTT interoperability in different platforms
is the challenge here. This is resolved by deploying open-source boards with various
MQTT clients.
1.7.3 Achieve Concurrency on Actuator and Platform
Since an actuator may be connected to multiple platforms (Raspberry
Pi/Arduino etc.,) simultaneous requests across platforms must be streamlined based on
access policy. The virtual plane is designed which comprises of one virtual object for
each instance and each instance is assigned a unique topic name as against the existing
models which have provided one topic per actuator.
1.7.4 Develop a Control Plane to Achieve Resource/Service Discovery and
Orchestration and Conflict Resolve
The proposed framework encompasses a control plane which can receive the
user commands, and will initiate discovery of resources and update the details with the
database for future reference or legacy data or for data analysts to work on. Also,
orchestration of resources based on demand is achieved.
To resolve interference at hardware level (actuators) in case of there is only one
instance available and still there many users willing to book. Here simultaneous access
of the same actuator should be streamlined. This again, is taken care of by a separate
module in the control plane which uses the proposed Acquire/Release lock model to
achieve reusability in a time-sharing model by booking their slots.
Thus, this research work has envisioned a control plane that can discover the
sensors and actuators in the network and identify the services they offer, orchestrate
and resolve conflict if any.

28. 14
The achieved results have proved improvement in performance and thereby
enhancing reusability but with negligible trade-offs.
1.7.5 Event Collaboration BasedSensor Data as Service
Sensors are data sources. Since sensors are virtualized (same sensor shared with
multiple users), data from different sensor instances should be sent to respective users
using MQTT [Publisher (sensor)-Subscriber (user) model], also taking care of
concurrency (multiple subscribe requests at the same time).
The above model is available in existing frameworks. The difference brought in
the proposed research framework is detailed as given below.
1. Parameterized topic is proposed as against sensor-based topic.
2. Sensor level storage proposed as against sensor client level storage. This
provides less overhead, enhanced performance and reduced access time.
3. Dynamic data formats based on user choice (PDF, CSV, JSON, XML or to
store in other databases) as against fixed standard formats.
1.7.6 Instance BasedActuator as Service
The proposed framework comprises of an algorithm formulated to offer actuator
as a service. Usually there are two issues which are overlooked in current models:
1. Multiple commands to a single actuator
2. Commands to many actuators’ instances
There were many models that have provided only data as service [44] [45] [46].
Minimal research has been carried out on this genre. Even if provided, there is vendor
lock in or no third-party support (plug and play) or demands domain expertise or
sufficient skill set. There is still issue in resolving conflicts on multiple requests and on
the aspect of mapping commands among multiple actuator instances (concurrency). The
proposed framework overcomes all the above-mentioned challenges and accepts
commands initiated through the API’s designed and implemented in this research

29. 15
model. A novel algorithm is proposed to resolve multi actuator conflict at the control
plane level and have proved improvement through performance graphs with negligible
overhead.
1.7.7 OTA Platform as Service
This will allow developers to deploy their code using OTA (Over The Air)
programming. This provides remote access to the proposed testbed and one can use the
testbed for the period the user will need.
1.7.8 Platform Independent API as Service
The proposed framework incorporates indigenous APIs for all the sensors and
actuators. If anyone needs more sensors and actuators, dynamic demand-based creation
of APIs is a possibility. Scalability is a possibility through this approach. This research
work clearly demonstrates the difference in time accessing locally and remotely using
API’s. Though there is little more time needed when accessed remotely, but it is very
much acceptable when compared to utilization and reusability factor. The needed
graphs are provided to prove and substantiate the proposal.
1.7.9 Feedback Ranking BasedTestbed Utilization Analysis
A ranking model [47] is formulated to provide the best resources to users,
analyze the utilization factor of the testbed through performance-based feedback and
failure model. The categorization is done based on Academician, Industrialist, Data
analyst, Researcher and Novice user. A script is developed to analyze local network log
with the feedback scores, whose results proved that the testbed was considerably
reliable irrespective of reported failure rates. It was observed from the log that there at
times network failure at the client end have resulted in low scores (False negative). A
discriminative analysis is carried out to find the mostly used services and factor analysis
to conclude which set of services is mostly used by which set of users. These results
gave an idea of the prospective research domains and deployment extensions for future.

30. 17
1.8 OVERVIEW OF THE DISSERTATION
The purpose of this work is to design and implement an IoT testbed framework
with enhanced performance. Figure 1.7 represents organization of dissertation. Thus,
the chapters for the dissertation are formulated:
Figure 1.7 Organization of
dissertation
as such, Chapter 1 is dedicated for introduction to IoT, testbeds and motivation behind
this research which lead to the problem statement. Chapter 2 elaborates about state-of-
the-art research in the area IoT testbeds and the service models. Chapter 3, Chapter 4,
Chapter 5 and Chapter 6 highlights the research contributions through the proposed
solutions, implementation and experimental results. Chapter 7 concludes the research
work followed by list of references and the research publications of the proposed
research work.

31. 18
CHAPTER 2: LITERATURE SURVEY
The main objective of any researcher or a developer is to design and implement
a system successfully. During the process of developing any algorithm or a protocol or
any component for that matter has to be well tested before it is deployed in to a product
or a process. This is usually achieved through some kind of testing and validation
techniques. They can be broadly classified as simulation based or experimental based.
Though there are many testing mechanisms, most of them are simulation based [48]
[49], which lacks accuracy when deployed in real environments. Few experimental
testbeds exist, but due to their huge infrastructural cost and their insufficiency to cater
new needs and requirements demanded by technologies such as IoT, Big data, there is
still prospective for developments. Thus, this chapter attempts to survey the existing
testbeds on various kinds, identify their merits and lags, which led to the motivation for
this research.
2.1 SURVEY ON TESTBEDS
Till 2009, the developed applications [28] or algorithms or protocols are mostly
tested on simulation [50] tools. Very few researchers tested their models on
experimental setups. From the year 2010, testing the results on the experimental
testbeds took off except for the year 2011 (for which the reasons are not clear). The
rationale behind was the availability of low cost hardware units, which led to reduced
infrastructural cost [51].
The proposed research work is to design, develop, and deploy an open IoT
testbed cum development utility which offers sensor data, actuators, platforms and API
as service with enhanced performance and utilization factor. Thus this research requires

32. 19
literature review at two levels. There is a need to understand the existing testbed
frameworks, their purpose, the services, challenges or issues. Secondly to investigate
the way each service is offered, their methodology, the merits, challenges or issues.
Community oriented platforms like IrisNet [52], SensorBase [53], SenseWeb
[43], Global Sensor Network (GSN) [54], and Semantic Sensor Web (SSW) [55] have
been established which allowed users to share the data from heterogeneous data
sources.
IrisNet [52] (Internet-scale Resource-Intensive Sensor Network Services) aims
at providing a sensor web which can be accessed from anywhere, anytime fulfilling the
requirement of an IoT based system. This attempt provided multitude of sensors openly
accessible to users from all walks of life.
SensorBase [53] is centralized data storage to log sensor network data in a blog
style.
SenseWeb, a Microsoft’s creation [43] provides a generic platform to share,
query and visualize sensor data.
GSN [54] offers a general-purpose infrastructure which can be programmed
based on user needs as against usual collection only model from a central repository.
SSW [55] enables interoperability and advanced analytics for situation
awareness and other advanced applications from heterogeneous sensors. But the lack
of integration and interconnection between these networks have left the most important
data isolated and have aggravated the current problem “too much data but not enough
knowledge” furthermore. Authors D. Sakumari and H. Zhang have discussed the
essential requirements in designing a basic testbed along with the overall comparison
of existing testbeds [56].
The word testbed was almost synonymous to WSN Testbed [57] and most of
the boards used are proprietary which led to interoperability problems. Many
application-based projects were deployed using these wireless sensor-based
frameworks [58] [59] [60] [61]. K. Langendoen, A. Baggio, and O. Visser [62] have
shared their failures which include lack of strenuous testing, lethargy towards software

33. 20
engineering practices, insufficient API support and lessons learnt from their
experiences like design for the worst with much more valid assumptions (including
expectations for packet error rates more than 10%), more than one node failure per
week and likely more node mobility. Most of the research papers discussed so far, have
used Low-Rate Wireless Personal Area Networks (LoWPAN) [63] to demonstrate their
applications.
Silvia Santini and Daniel Rauch proposed Minos (Message Identification and
Online Storage) a generic tool for sensor data acquisition and storage as part of Desthino
(Distributed Embedded Systems Online) project [64]. Though the tool is developed
using java, it is capable of interacting only with sensor nodes running TinyOS which
makes it platform dependent.
Way back in 2008 the idea of testbed was incorporated in the field of education
[65]. P. D. Godoy, R. Cayssials and C. G. Garino have highlighted the importance of
simulated and real experimental testbeds. A WSN extended IoT based testbed have also
been developed to support teaching [66].
Sensor Data Service defaults in Windows 10 delivers data from a variety of
sensors [67] , but this service has to be started manually by the users but is based on a
proprietary operating system Windows 10.
KanseiGenei testbed exists since 2007 and still available for public use [68]. It
uses a 3-tier architecture comprising of wireless sensor nodes wired to a gateway.
M. Zorzi, A. Gluhak, S. Lange, A. Bassi [69] have attempted to provide an
architectural framework to overcome the current fragmentation and limitation of
solutions, where many “Intranets” of Things exist, towards a true “Internet” of Things,
where all devices will be part of a globally integrated system. The authors have realized
it early, the need for a unified approach for IoT when many of them were still busy
developing single applications in silos. They have admitted the agony of only small
group of enthusiasts from academia, industry and public institutions working to bring
up a unified model for IoT. They have emphasized the dire need for standardization and
ETSI have made some notable contributions.

34. 21
Few researchers worked on realizing things as smart objects, there by achieving
intelligence in the system by interconnecting them [70]. This idea helps IoT systems
achieve their real purpose of smartness [71].
The facilities needed for an experimental testbed is discussed and the need for
experimental real time testbeds [37] is well established. SenseLab- a very large scale
opens Wireless Sensor Network Testbed [72] is a generic testbed which allows
experimental research of protocols used for communication and algorithms at
application level.
WISEBED was initially started in 2010 [73], later evolved to include concepts
of virtualization to the existing testbed architecture. It uses a generic XML-based
language (WiseML) to describe about the experimental setting up and for result
storage.
A federated platform for mobile data centric service development and sharing
has been developed as an attempt to address interoperability through virtualization [46].
This model requires the developer or user to write a script which is capable of parsing
the received data to suit his/her needs.
M. Nati, A. Gluhak, H. Abangar, W. Headley claims that many of the existing
IoT technologies are still tested in lab-based testbeds [74] and emphasizes the need for
realism [75] in external environment and the importance of real end users in the loop.
They have created an infrastructure to support smart building-based experimentation
with using TelosB motes.
Control Cube is a work presented at IPSO challenge, it is a device (both software
and hardware) that enables every-day, conventional appliances and automations to join
the IoT vision using IPv6, CoAP and the IPSO Application Framework [76]. It
highlights the mammoth task involved in developing new type of resources to support
varied devices and the CoAP implementation of TinyOS has to be greatly extended.
Moreover, severe hardware limitations demand work on careful resource optimization
(especially memory constraints) when developing firmware.

35. 22
In order to ensure, reliability of wireless communication in IoT based systems
which is spread across distributed locations, enhanced lifetime through safe and proper
utilization of energy and judicious memory utilization of resource constrained devices,
A. S. Tonneau, N. Mitton, J. Vandaele have studied the existing experimental setups,
various hardware’s they support and the flavor of services they offer [77]. They have
attempted to define the requirements of an IoT experimental testbed based on survey
of existing facilities, their purpose and functionality they offer. Researchers have also
attempted survey based on relevant technologies, protocols and applications for IoT
[78] [13]. L. Belli has attempted to bring in web interface to access experimental
testbeds with the idea of web of things with the underlying backbone being the internet
[79]. D. Guinard, V. Trifa and E. Wilde have proposed service-oriented architecture for
web of things [80].
FIT IoT-LAB provides a very large-scale infrastructure suitable for testing
small wireless sensor devices and heterogeneous communicating objects. The project
is an extension of SenseLab testbed set up [81]. FIT is Future Internet of Testbeds was
the abbreviation. The title was changed to Future IoT in 2017 and recently they have
changed it to Future Internet Testing facility. Research has been carried out with FIT
IoT-LAB for various experimentation needs [82] [39].
The possible benefits of collaboration between simulation tools and real
physical testbeds, their trade-offs and the role of simulation tools in bridging scalability
issues is highlighted in the paper [83].
A new application genre for IoT, IoT-based E-Learning testbed [84] capable of
stimulating the learner's motivation by using implemented smart box, microwave
sensor module and decision tree is discussed.
Most of the existing experimental testbeds are extrapolation of wireless sensor
networks [1] which are made of proprietary motes leading to interoperability issues
claims L. Mainetti, L. Patrono, and A. Vilei. The authors G. Z. Papadopoulos, J.
Beaudaux, A. Gallais, T. Noel and G. Schreiner have emphasized the importance of
experimental testbeds compared to simulation models but the setup used comprises of
motes leading to vendor lock in and difficulty in migration or scaling [9].

36. 23
There are some commercially available services such as ThingSpeak, Ubidots,
etc., that provide a way to send the data from IoT systems to the cloud. The authors A.
I. Abdul-Rahman, C. A. Graves have exploited the existing ThingSpeak Cloud and
Service science to achieve reusability by sharing data collected and stored [85]. Earlier
these services used the HTTP application layer protocol and have started to support
MQTT recently. However, these services still require the application generating the
data to be developed by the user and then the data will be available to use over the
internet. This provides a way of ensuring that the data is available from anywhere but
does not reduce the burden on the analyst of having to develop or implement the system
that generates the data.
There are publicly available channels in ThingSpeak [86], used by other
application developers but these channels do not categorize the data on the basis of
sensors. Those channels are also not maintained by the service provider to ensure
constant availability of data in them.
Moreover, ThingSpeak allows only one update every 15 seconds, when
uploading data to an API [87], but there are few applications which need more frequent
updates or on a specific change in the event in other words data.
The author has described that IoT will be the driving force for data as a service
[45]. In line with previous discussions, IoT is all about communication and cooperation
between objects to implement the task at hand. A. Jimenez-Gonzalez, J.R.M.D. Dios,
A. Ollero have explored the possibilities of cooperative perception of sensors in an
integrated Testbed [88]. J. R. Martinez-de Dios, A. Jimenez-Gonzalez, A. De San
Bernabe, A. Ollero emphasize the importance of integration of heterogeneous objects
and technologies to achieve modularity and ease of access of testbeds [89]. All these
frameworks offer sensor data as service in wide variety of ways, but the point most of
the approaches missed was IoT perspective of the data, standardized data formats to
enhance reusability, optimized methods of data collection [90], storage and measures
on erroneous data.
G. Z. Papadopoulos, A. Gallais, G. Schreiner, E. Jou have reviewed 674 papers,
out of which 596 papers belong to IoT, WSN and Ad hoc networks [38]. 561 papers
have provided theoretical results for their study under consideration. 284 papers out of

37. 24
596 have embraced simulation and 392 papers on experimental testing. But among the
392 papers most of them belong to the category of WSN or Ad hoc. Even if the paper
was related to IoT, it was tested on an extrapolated WSN testbed, but not on an
exclusive IoT testbed [91].
Though the testing on experimental testbed has considerably risen, but there are
challenges which need addressing. It requires frequent flashing, reboot after flash, and
reload the firmware, debug, sooner or later to retrieve measurements. The most
importantly requires undeniable dedicated skill set and prior knowledge of the set up.
Setting up is equally difficult and time consuming. Also mobilize human resources
other than researchers is equivalently tough. [88]
In order to overcome these challenges, there is inclination towards simulations
[49] based testing grounds. But these advantages come with a cost. Simulations [92]
[93] usually hide the limitations or constraints imposed by actual components in the
name of abstraction. For example, provide unlimited memory, powerful computation
resource. Having said that, the probability of node failure and energy drains are never
taken in to consideration. This makes the realism of test results questionable. Also it
complicates by underestimating the complexity of their contribution, leading to false
promising results.
Some of the experimental frameworks provided on-demand resource sharing
[94] and facility for developing value added services but the issue of proprietorship and
interoperability was not addressed in depth.
IETF have come up with internet draft that describes about importance of
resource discovery and its benefits. This draft emphasizes the importance of resource
sharing and the benefits of dynamic discovery. It is in its infancy in the field of IoT.
The underlying protocol to identify the resources can be chosen from available pool.
The most deployed protocols are CoAP [95] and MQTT among others.
P. Fremantle has provided architecture [96] level detailing of IoT. J. H. Huh,
D. H. Kim and K. Jong-Deok have proposed a similar such model named as NEWS, N:
Neutrality, E: Ease, W: Web, S: Shareable and [97] have provided a top level discussion
and they are yet to evolve the experimental results.

38. 25
M. Chernyshev, Z. Baig, O. Bello, S. Zeadally in 2018 have provided a
comparative analysis and open research challenges of existing IoT based simulation
tools [48] grouped in the capacity of exposure of the IoT architecture layers.
Of late IoT related events [98], consortium having been formulated to discuss
the issues and formulate solutions keeping in mind the need for standardization.
2.2 COMPREHENSIVE COMPARSIONOF PROPOSED VS.
EXISTINGTESTBEDS
Thus, this research work is an attempt to address all the above-mentioned issues
and there by achieve an open-source heterogeneous testbed utility considering
interoperability [99] among open-source devices. Figure 2.1 provides the
comprehensive comparison of the proposed system against existing testbed
frameworks.
Figure 2.1 Comparison chart of proposedvs. existing
testbeds

39. 26
Thus, the list of gaps or research challenges to address is:
 Sensors and Actuators are mere input and output not as service/utility
 Vendor lock-in- Proprietary
 Fear of obsolescence
 Shifting an issue
 Deters innovation and dynamicity
 Lack of interoperability
 Lack of standardization
 Lack of open-source entities
 Insufficient control
 Lack of conflict resolve/concurrency (Actuators)
 Obtaining the data will be useless, if the data is in a proprietary format
 Simulation based environments
 WSN extrapolated frameworks
This research work also exploits the benefits of publish-subscribe model where
each device subscribes to central broker if it is interested in a specific topic without
worrying about details of its co-existing nodes. The research work highlights
improvised methodology, not only to achieve sensor data as service, but also actuator
as service, platform as service and API as service. The optimized ways of achieving the
same is also dealt. The proposed research work also gives insight of how the message
is packed, flexibility in intervals of data collection and mode, error handling and
providing appropriate visualization for each sensor data. Moreover, the proposed
testbed framework have reduced the learning curve the data analysts have to undergo,
provided categorization based on sensors granulated at parameter level, better
visualization, and had removed the dependency of any coding skills or hardware
knowledge required to create the application that generates the data. The ranking and
testbed utilization model is also developed to prove the reliability and performance of
the proposed framework.

40. 27
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).

41. 28
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

42. 29
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

43. 30
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.

44. 31
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

45. 32
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

46. 33
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
architecturalframework

47. 34
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

48. 35
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

49. 36
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.

50. 37
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

51. 38
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

52. 39
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.
0.009
0.008
0.007
0.006
0.005
0.004
0.003
0.002
0.001
0
0 20 40 Trial 60 80 100
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.
Time (s)
3.00
2.50
2.00
Time (s)
0.50
20 40 Trial 60 80 100 120
Time
(s)
Time
(s)

53. 40
Figure 3.8b: Sensor/actuator detection time

54. 41
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.007
0.006
0.005
0.004
Time (s)
0.001
20 40 60 80 100
Trial
120%
100%
80%
Hit Ratio (without
Lock_Release)
Hit Ratio (With
Lock_Release)
40%
20%
25 50 75 100
Trial (User Request)
Time
(s)
Response
Rate
(%)

55. 41
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 ofwhich 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 thevirtualization, 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.

56. 42

57. 43
CHAPTER 4
EVENT COLLABORATION BASED SENSOR DATA
ASSERVICE
Any IoT system basically comprises of input, output and a processing unit. The
input spectrum comprises of many sensors that are used to measure various
environmental parameters such as temperature, humidity, pressure, noise, leak and
many more. The sensors can be digital or analog as already introduced, as in the case
of a DHT11, a Digital Temperature and Humidity sensor, and can also be analog, such
as LM35 temperature sensors.
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.
A typical IoT system contains multiple sensors and actuators. There is a large
amount of data that is being generated from these IoT systems. This data can be used
in multiple ways such as simple monitoring, or different types of analytics can be
performed such as pattern recognition, prediction, to name a few. These analytics can
be performed by data scientists, data engineers, data analysts from around the world.
The learning curve involved to exploit these systems is too high as they need to enhance
their skills beyond their domain expertise. This learning curve would consist of learning
about the sensors required, how they work and interface with a microcontroller, learning
about the microcontroller and writing the microcontroller code that runs on it, learning
about the protocols involved in IoT and the implementation of the same to create the
application that generates the required data [44].
This research work provides a solution for this problem by providing the data
generated from these sensors as a service to all end users of the said data locally as well

58. 44
as remote. This would provide the analysts an abstracted source of data, free from the
complexities of the underlying infrastructure, thus letting them focus on what they do
best, i.e. working with the data. Also the dynamic resource discovery and orchestration
via control plane will help us achieve sensor being offered as service with enhanced
availability and reliability.
4.1 BACKGROUND
The basic objective behind every IoT system is to leverage the available local
data at a global scale. The availability of local data through small and cheap sensing
devices capable of sensing, monitoring variety of environmental factors like
temperature, humidity, air pollution, road traffic has been underexploited due to lack of
interoperability and reusability patterns. The advent of IoT, cloud and big data has
opened new possibilities which were never imagined since then. Every object
monitored can be made smarter and connected to cloud and offered as service to the
end users or developers or data analyst. The idea was to provide web interface through
which users can query the needed data stored in cloud like storage. As already discussed
in literature survey many commercial services exist that supports data transfer from IoT
devices to the cloud framework. Reseaches have been reported on exploiting services
like ThingSpeak and Service Science to provide the sharing of the collected data. Of
late, ThingSpeak have started support for MQTT protocol along with traditional HTTP.
But, the limitation is the user has to have skill in developing his/her application to push
the data to the cloud and thereafter it would be available for shared access. There is no
support of application support reusable API. Though this provides access to data from
anywhere, this is still a scope for improvement whereby reducing burden on analyst.
The proposed research work attempts to resolve this with service offering through
downloadable APIs. This relieves analyst and other users from burden of developing or
implementing a system from scratch.
Moreover cloud offerings like ThingSpeak operate with help of channels, but
the channels do not categorize based on sensors, but based on fields. For example, a
channel contains data from multiple sensors, like DHT11 which measures humidity and
temperature, Gas Sensor which detects gas leakage, etc., Then the data is categorized

59. 45
as temperature, humidity and gas leakage being the fields and are provided individually
or the entire data is provided as a whole, without the categorization based on the type
of sensor like DHT11 and Gas Sensor's data. Hence the analyst would again be forced
to develop his/her own system for the generation of the required data, or hire someone.
The management of channels is offloaded to the client side i.e. the service provider does
not guarantee the constant availability. The proposed research ensures categorization
based on sensors as well as fields, which eliminates the existing limitation. Also the
management of data is taken care of from the server side through the time stamped
history database update algorithm.
Most of the services including ThingSpeak updates data every 15 seconds [28].
This may not be a dynamic or an optimized model. There are some applications which
will require more frequent updates, while others sparse updates. The proposed research
work has addressed this and has overcome by updating the data only when there is a
change involved. This gives us an optimized approach on either ways of demand
requirements.
Though it is not a serious drawback but many frameworks provide only spline
charts, which is addressed in the proposed work to provide customized visualization
through line charts as well as pie charts, depending upon the type of sensor.
Also, many of the existing open source IoT platforms or API’s will demand a
minimal coding knowledge, which is eradicated in this proposed research work by
providing the data needed to the end user directly. Many of the open source IoT
frameworks often do not reveal how long the data is being stored in the servers. But the
proposed research work have achieved transparency in this regard by providing thedata
from the point at which the system was deployed and provide a timestamp for every
record so that the analyst knows when the data was added.
Many more community oriented platforms like SenseWeb [17], Global Sensor
Network, SensorBase [19], IrisNet [20] and Semantic Sensor Web [21] have been
established which allowed users to share the data from varied data sources. But these
platforms are not developed with IoT in mind.

60. 46
SenseWeb, a Microsoft’s creation [17] provides a generic platform to share,
query and visualize sensor data. SenseWeb provides various tools for data owners and
data users to publish and subscribe the data respectively. SensorMap is a geographical
web interface provided by SenseWeb to query the needed data and get the visualization
of the same.
Global Sensor Network (GSN) [18] offers a general-purpose infrastructure
which can be programmed based on user needs as against usual collection only model
from a central repository. The GSN middleware infrastructure attempts to address
heterogeneity by integrating heterogeneous sensor networks and this is achieved by
deploying the GSN middleware on any computer which is interested in interacting with
one or more sensor networks.
SensorBase [19] is centralized data storage to log sensor network data in a blog
style. SensorBase not only provides way to store and access data consistently to users
but also maintains. It is also referred as “slogging data” to denote sensor log and to
provide a blog like structure.
IrisNet [20] (Internet-scale Resource-Intensive Sensor Network Services) aims
at providing a sensor web which can be accessed from anywhere, anytime fulfilling the
requirement of an IoT based system. This attempt provided multitude of sensors openly
accessible to users from all walks of life. But, this module suffers the constraint of
proprietorship.
Semantic Sensor Web (SSW) [21] enables interoperability and advanced
analytics for situation awareness and other advanced applications from heterogeneous
sensors. The sensor networks these days can measure almost everything on earth. The
unaddressed gaps between various proprietary heterogeneous networks have created a
new problem of “data isolation”. Though everything is available, but because of the
lack of open framework standards, the fullest exploitation has not happened at its best.
This has lead to reinventing the wheel by various sectors, which need to be
addressed. SSW achieves interoperability by providing meta-data along with the
contextual information essential for situational knowledge. It achieves interoperability

61. 47
more suitable for heavyweight internet based systems and its implications with resource
constrained devices are not explored to its depth.
All of the above-mentioned frameworks provided on-demand resource sharing
and facility for developing value added services but the issue of interoperability was
not addressed fully. Semantic Sensor Web is an exception which addresses
interoperability, but employs additional metadata to achieve it adding a bit more
complexity to an already constrained system. Hence this research work attempts to
achieve interoperability in simpler terms by using topic registration model, abstracting
the complexities about the co-existing nodes/devices. Zhang J et al. developed a
federated platform for mobile data centric service development and sharing as an
attempt to address interoperability through virtualization [22]. The issue in their
proposal is they have abstracted the virtual sensors or nodes either to represent an
average or group of sensors as temperature, humidity and noise. This approach has
drawbacks like it would indulge more cost during sending if the readings of any one of
it changes very rarely or if any one of the reading is faulty then the whole set has to be
resent. Also, this model requires the developer or user to write a script which is capable
of parsing the received data to suit his/her needs.
Silvia Santini and Daniel Rauch proposed Minos (Message Identification and
Online Storage) - a generic tool for sensor data acquisition and storage as part of
Desthino (Distributed Embedded Systems Online) project [23]. It is a java based
software tool hence it is lightweight and portable. The limitation is that it can interact
only with TinyOS supported motes making it platform dependent. The user apart from
mentioning the message type the tool should listen to, he or she is also expected to
provide the java class representing the incoming messages. This java class generation
again needs MGI (Message Generating Interface) a TinyOS utility.
Sensor Data Service defaults in Windows 10 [24] delivers data from a variety
of sensors, but this service has to started manually by the users but is based on a
proprietary operating system Windows 10.
Having described all these frameworks and APIs capable of offering sensor data
as service in wide variety of ways, the point most of the approaches missed was to
justify on optimized ways of reaping data from billions of sensors. Collecting and then

62. 48
creating solutions from data is nothing new. What is important is defining rules of
optimized retrieval and ease of access. Hence this research proposal not only discusses
methodology to achieve sensor data as service, but also highlights optimized ways of
achieving it and also highlighting scenarios to describe who can use and how much
benefits it can offer. This research proposal gives insight of how the message is packed,
period of data collection, error handling and providing appropriate visualizations for
each sensor data.
Thus, this proposed research work attempts to address all the aforementioned
issues as to reduce the learning curve the data analysts or other users have to undergo,
to provide categorization based on sensors, better visualization and removing the
dependency of any coding skills or hardware knowledge required to create the
application that generates the data.
4.2 PROPOSED MODEL
This research work realizes the need for a bridge between the worlds of apps to
world of devices. This is achieved in existing systems through request-response model.
But this model is handicapped in many instances when the network is down or
specifically suffers in IoT based scenarios where there is need for data to
communication whenever a change happens. Hence this research work aims to propose
event collaboration model as against existing request response model implemented in
testbeds. The user who is interested in sensor service needs to request the proposed
testbed in order to access the sensor they are concerned. The idea formulated here is
data as service as against sensor as service in literal sense, for the fact that sensor is all
about data. Hence the user requests for service from the testbed. The existing testbeds
data is not up to date, unless queried, in other words it needs continuous polling. So the
users request is mapped to a query and it is targeted towards the interested sensor and
the data is sent back as response. This adds up complexity considerably enough on
inclusion of more interconnected services. This is followed in existing testbeds, but
what this proposed research work intend is event collaboration model whereby the event
is triggered only when there is a change in the data and the data is stored in the database
which can be queried up on. In other words, event collaboration is a model

63. 49
which does not require being provoked to speak (i.e. send data), it will speak
automatically when there is something new to convey (i.e. any change). For instance,
whenever there is change in temperature sensor, the data is pushed to, irrespective of
the need for request. Thus when a user demands, the query need not travel all the way
till sensor, update to database server and return back the response to user, but instead
read directly the already ready existing data. But in case of issue in the network
connectivity, there is chance of working with stale data. The issue also exists in REST,
where the query fails, but this needs to be addressed. Hence, there is a watchdog timer
set to a threshold to initiate a check message, in case of no event reported on prolonged
time.
The proposed system will contain a number of sensors and the data generated
from them will be stored in a database. The system is meant to be maintained by the
service provider to ensure a constant source of data. The analyst would only have to log
in to the system with his credentials, and can use the data generated from the sensors
via the interface. The sample update from the sensor is shown in Figure 4.1 and
visualizations of the data generated from the sensors in the form of graphs are shown
in Figure 4.2 and Figure 4.3.
Figure 4.1 Sample record database displayed in the Web UI

64. 50
Figure 4.2 Visualization of DHT11’s temperature data
Figure 4.3 Visualization of DHT11’s humidity data
The interface will also let the end users download the entire history of data
generated by the sensor in CSV (Comma Separated Variable), JSON (JavaScript Object
Notation) and XML (Extensible Markup Language) formats as shown in Table 4.1

65. 51
Table 4.1 Example of CSV, JSON & XML data
generated by the interface
Format Example
CSV "timestamp","celsius","fahrenheit","kelvin", "humidity"
"2018-10-22 20:24:44.844621","23","73","296","60"
"2018-10-22 20:24:54.753128","22","71","295","50"
.
.
.
"2018-10-22 23:23:35.697389","23","73","296","60"
JSON [{"timestamp":"2018-10-22
20:24:44.844621","celsius":"23","fahrenheit":"73","kelvin":"296","hum
idity":"60"},
{"timestamp":"2018-10-22
20:24:54.753128","celsius":"22","fahrenheit":"71","kelvin":"295","hum
idity":"50"},
.
.
.
{"timestamp":"2018-10-22
23:23:35.697389","celsius":"23","fahrenheit":"73","kelvin":"296","hum
idity":"60"}]
XML <?xml version="1.0"?>
<dht11>
<row>
<timestamp>2018-10-22 20:24:44.844621</timestamp>
<celsius>23</celsius>
<fahrenheit>73</fahrenheit>
<kelvin>296</kelvin>
<humidity>60</humidity>
</row>
<row>
<timestamp>2018-10-22 20:24:54.753128</timestamp>
<celsius>22</celsius>
<fahrenheit>71</fahrenheit>
<kelvin>295</kelvin>
<humidity>50</humidity>
</row>
.
.
.

66. 52
<row>
<timestamp>2018-10-22 23:23:35.697389</timestamp>
<celsius>23</celsius>
<fahrenheit>73</fahrenheit>
<kelvin>296</kelvin>
<humidity>60</humidity>
</row>
</dht11>
4.2.1 Sensors
The implemented system uses, but is not limited to the following sensors. A
DHT11 Digital Humidity and Temperature sensor was used for measure the humidity
and the temperature of the environment. A rainfall sensor is used to categorize rain
falling on it into “No rainfall”, “rainfall” and “Drenching rainfall”. A MQ-2 gas sensor
is used to detect the presence of any flammable gases in the environment. A color sensor
is used to determine the color of the light incident on the surface of the sensor.
4.2.2 Sensor Clients
Sensor clients are open source boards to which sensor units are hosted. The
sensor client was implemented using open source boards like Arduino Uno R3, and the
MQTT client code is uploaded onto it which will implement the proposed algorithm for
the sensor client. More sensor clients can be added to the system and more sensors can
be interfaced with the same to increase the variety of sensors for which the data is
provided to the end user. An option is available in the user interface which will allow
the end user to request the addition of any sensors that are not currently available in this
system. The proposed system consists of multiple sensor clients. Each sensor clients
consist of multiple sensors interfaced to a microcontroller. For every sensor Si ∈{S | 1
≤i ≤n}, an MQTT topic of the format “data/Si ” is assigned. The reading from the sensor
is sent as the payload of the message on this topic. There are some sensors, such as a
MQ2 gas sensor, which will measure only one parameter, and there are also sensors
which can detect multiple parameters, such as a DHT11 Digital Humidity and
Temperature sensor. The DHT11 temperature can detect two parameters temperature
and humidity.

67. 53
Figure 4.4 Experimental prototype for sensor client.
In such cases the value of both parameters will be sent on the same payload and
the message broker will receive the message and parse the payload to extract the value
of the individual parameters. The microcontroller runs a MQTT client code that
publishes the sensor data on the appropriate topics to the MQTT protocol broker. The
experimental prototype for sensor client is shown in Figure 4.4.
4.2.2.1 Algorithm for Sensor Client
Let S be a set of sensors and P be a set of Parameters for every sensor. For every
sensor Si ∈{S | 1 ≤i ≤n} there exists a Parameter Pj ∈{P | 1 ≤ j ≤ m) }. The proposed
algorithm for sensor client module is provided herewith. Figure 4.5 illustrates the
communication model for sensor client.

68. 54
For every sensor 𝑺𝒊 ∈ {S𝑖(1, 𝑛)} 𝑡ℎ𝑒𝑟𝑒 𝑒𝑥𝑖𝑠𝑡𝑠 𝑎 𝑃𝑎𝑟𝑎𝑚𝑒𝑡𝑒𝑟 𝑷𝒋 ∈ {Pj(1, 𝑚)}
Figure 4.5 Communication model for sensor client