IEEE WORLD FORUM ON INTERNET OF THINGS 2014, SEOUL, KOREA 6-8 MARCH 2014.

Sensor Discovery and Configuration Framework for The Internet of Things Paradigm

Charith Perera, Prem Prakash Jayaraman, Arkady Zaslavsky, Peter Christen, Dimitrios Georgakopoulos

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

Background and The Problem

Slide 3 of 20

• 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 theIoT will grow exponentially as the number of connected nodes increases.

Estimated numbers of connected nodes based on different sectors are presented in millions

Challenges and Functional Requirements

Slide 4 of 20

Large number of sensors Heterogeneity: Sensor Outputnumerical, audio, video

Heterogeneity: Communication Sequences

Heterogeneity: Communication Technology (Protocol)

Challenges and Functional Requirements

Slide 5 of 20

Heterogeneity: Sensing Capability (Measurements)

Data Acquisition Methods

Challenges and Functional Requirements

Slide 6 of 20

Dynamicity Context

The Proposed Solution: CADDOT

Slide 7 of 20

• 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

Design Decisions and Applications

Slide 8 of 20

Wall-mounted Devices with a screen powered by Android, capability equals to a modern mobile phone

• 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.

• The strategy (b) is more suitable for situations where WiFi is not available or less dynamic. Smart agriculture can be considered as an example.

Design Decisions and Applications

Slide 9 of 20

• 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 10 of 20

• 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.

Design Decisions and Applications

Slide 11 of 20

• 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, Context-aware 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

Design Decisions and Applications

Slide 12 of 20

• CADDOT uses a plugin architecture to address the challenge of different types of heterogeneity.

• Plugins can be developed, distributed and installed separately to SmartLink.

Implementation and Evaluation

Slide 13 of 20

• We deployed the SmartLinkapplication 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.

Experimentation Results and Discussion

Slide 14 of 20

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

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.

Experimentation Results and Discussion

Slide 15 of 20

• 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).

Conclusion and Future Work

Slide 16 of 20

• 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.

Charith PereraThe Australian National UniversityCSIRO Computational Informaticst +61 2 6216 7135e Charith.Perera@ieee.orgw www.charithperera.net

DECISION AND USER SCIENCE / INFORMATION ENGINEERING LAB

Thank You!