Charith Perera, Prem Prakash Jayaraman, Arkady Zaslavsky, Peter Christen, Dimitrios Georgakopoulos, Sensor Discovery and Configuration Framework for the Internet of Things Paradigm, Proceedings of the IEEE World Forum on Internet of Things (WF-IoT), Seoul, Korea, March, 2014

1. Sensor Discovery and Configuration Framework
for The Internet of Things Paradigm
Charith Perera, Prem Prakash Jayaraman, Arkady Zaslavsky, Peter Christen, Dimitrios Georgakopoulos
IEEE WORLD FORUM ON INTERNET OF THINGS 2014, SEOUL, KOREA 6-8 MARCH 2014.

2. Agenda
• Background and The Problem
• Challenges and Functional Requirements
• The Proposed Solution: CADDOT
• Design Decisions and Applications
• Implementation and Evaluation
• Experimentation Results and Discussion
• Conclusion and Future Work
Slide 2 of 20

3. Background and The Problem
• Internet of Things (IoT) will comprise billions of devices that can sense, communicate,
compute and potentially actuate.
• The data generated by the Internet of ‘Things’ are valuable and have the potential to
drive innovative and novel applications.
• The challenging task before collecting and processing data from these devices is for
systems to discover and configure the sensors and the associated data streams
(a) Big Data comprises six
categories of data
(b) Data generated from the
IoT will grow exponentially as the
number of connected nodes
increases.
Estimated numbers of connected nodes
based on different sectors are presented in
millions
Slide 3 of 20

4. Challenges and Functional Requirements
Large number of sensors
Heterogeneity: Communication
Sequences
Slide 4 of 20
Heterogeneity: Sensor Output
numerical, audio, video
Heterogeneity: Communication
Technology (Protocol)

5. Challenges and Functional Requirements
Heterogeneity: Sensing Capability (Measurements)
Data Acquisition Methods
Slide 5 of 20

6. Challenges and Functional Requirements
Dynamicity
Slide 6 of 20
Context

7. The Proposed Solution: CADDOT
• Phases in CADDOT model: The proposed model consists of eight phases: detect,
extract, identify, find, retrieve, register, reason, and configure.
• To support this model, we developed a tool called SmartLink
Slide 7 of 20

8. Design Decisions and Applications
• In strategy (a), a Raspberry Pi (raspberrypi.org) is
acting as the SmartLink tool. This strategy is mostly
suitable for smart home and office environments
where WiFi is available.
Wall-mounted Devices with a screen
powered by Android, capability
equals to a modern mobile phone
Slide 8 of 20
• The strategy (b) is more suitable for situations
where WiFi is not available or less dynamic. Smart
agriculture can be considered as an example.

9. Design Decisions and Applications
• A simple sensor-level program design (SPD) that sends and transmits data to the cloud.
• The main problem in this program design is that there is no way to configure (i.e.
sampling rate, communication frequency, data acquisition method) the sensor after
deployment other than by re-programming (e.g. Over the Air Programming).
• Such re-programming approaches are complex, labour-intensive and time consuming.
Slide 9 of 20

10. • We designed, Configurable Program Design
(CPD), a sensor-level program that supports a
comprehensive set of configuration
functionalities
• To standardize the communication, we also
defined a number of command formats.
• These messaging formats do not need to be
followed by the developers as long as they
share common standardised command formats
between their own sensor-level program and
the corresponding plugin.
• This program is designed into a tree structure
where we carefully manage the breath and
depth to minimize travel time through IF-ELSE
statements.
Slide 10 of 20

11. Design Decisions and Applications
• The first segment of every
command (Not the messages
sent out) contains only three
letters which makes it easy to
process. The commands can
be sent using frames or plain
strings.
•
For Details Please refer to Charith Perera, Prem Jayaraman, Arkady Zaslavsky, Peter Christen, and Dimitrios Georgakopoulos, Contextaware Dynamic Discovery and Configuration of `Things' in Smart Environments, In Book Big Data and Internet of Things: A Roadmap for
Smart Environments, Studies in Computational Intelligence book series, Springer Berlin Heidelberg, accepted, to be published in 2014
Slide 11 of 20

12. Design Decisions and Applications
• CADDOT uses a plugin architecture to address the challenge of different types of
heterogeneity.
• Plugins can be developed, distributed and installed separately to SmartLink.
Slide 12 of 20

13. Implementation and Evaluation
• We deployed the SmartLink
application in a Google Nexus 4
mobile phone (Qualcomm
Snapdragon S4 Pro CPU and 2 GB
RAM), which runs the Android
platform 4.2.2 (Jelly Bean).
• Libelium Sensors are used for this
Experimentation.
• SmartLink supports sensor
discovery and configuration using
both WiFi and Bluetooth.
• In order to simulate the heterogeneity of the sensors (in terms of communication
sequence), we programmed each sensor to behave and respond differently.
• As a result, each sensor can only communicate with a plugin that supports the same
communication sequence.
Slide 13 of 20

14. Experimentation Results and Discussion
Time taken (y-axis) to
discover and
configure a sensor
step-by-step (x-axis).
The experiments
were conducted using
three protocols: TCP,
UDP, and Bluetooth.
Time taken to
(1) set up the sensor, (2) initiate connection between the sensor and SmartLink,
(3) initiate communication between sensor and SmartLink,
(4) extract sensor identification information, (5) retrieve the complete profile of the
sensor, (6) configure the sampling rate, (7) configure the communication frequency,
(8) configure the sensing schedule, (9) configure the network and authentication details
(10) connect to the secure network using the provided authentication details..
Slide 14 of 20

15. Experimentation Results and Discussion
• The actual configuration tasks take less that one second.
• There is a slight variation in completion time in configuration step (4) - (9). This is due to
storage access and differences in processing of configuration commands.
• Sensors takes comparatively longer time to connect to a network as well as to discover
and connect to SmartLink
• Bluetooth takes much longer to scan for devices in a given environment before it
discovers and connects to SmartLink.
• Configuration is slightly faster when using TCP in comparison to UDP and Bluetooth.
However, the time differences are negligible.
• FTP can take 15-25 seconds to retrieve a scheduling file.
• When using WiFi, a sensor may takes up to 4.5 seconds to connect to a secure network
(e.g. WPA2). Sensors can connect to open access point in less than 4 seconds.
• Despite the protocol we use, sensors take 5 to 15 seconds to boot and setup
themselves. The setup stage consists of activities such as reading default configuration from files, and switching necessary
modules and components (communication modules, real-time clock, SD card, sensor broads and so on).
Slide 15 of 20

16. Conclusion and Future Work
• We explored the barriers in deploying IoT solutions in order to build
smart environments and understood that sensor discovery
configuration is one of the major challenges.
• CADDOT also encourages non-technical users to adopt IoT solutions
with ease towards building their own smart environments.
• We proposed the CADDOT model by considering key factors such as
growing number of sensors, heterogeneity, on-demand schedules,
and sampling rates, data acquisition methods, and dynamicity.
• In the future, we will explore the possibilities of developing an
efficient technique to identify a given sensor using context
information and probabilistic techniques in circumstances where
information extracted in step 2 in CADDOT model is not adequate.
Slide 16 of 20

17. Thank You!
Charith Perera
The Australian National University
CSIRO Computational Informatics
t +61 2 6216 7135
e Charith.Perera@ieee.org
w www.charithperera.net
DECISION AND USER SCIENCE / INFORMATION ENGINEERING LAB