feasibility of the simulation of sensor databases with a generic network simulator - supervisor :...

Feasibility of the simulation of sensor databases with a generic network simulator

- Supervisor : Hoben Ralf- Student : Jaballi Walid

- Date : January 22nd , 2007

- MICS 3- Winter Semester, 2006/2007- Technical Systems Modeling and Simulation - Prof. Dr. Jürgen Sachau

http://www.uni.lu/

Hoben Ralf & Jaballi Walid22/01/2007 2

Overview

– What is a Sensor Network?

– Some Sensor Network applications

– Characteristics of Sensor Networks

– Network Sensor Query Processing

– Sensor Network Architecture

– Platform:Hardware, Operating Systems,Middleware,Programming languages,Simulators

– Simulation environment:TinyOS,TinyDB,TinyDB,OMNeT++

– Simulation : Solution

– Study case : Sensor database

– Difficulties encountered during simulation

– Conclusion

– References

http://www.uni.lu/


What is a Sensor Network?

• Many simple nodes with sensors deployed throughout an environment

http://www.uni.lu/


What can be a node?

http://www.uni.lu/


redwood forestmicroclimate monitoring

structural integrity

Some Sensor Network applications

Traditional monitoring apparatus.

http://www.uni.lu/


Vehicle detection: sensors along a road, collect data about passing vehicles

smart coolingin data centers(hp/intel)

http://www.hpl.hp.com/research/dca/smart_cooling/

And More…

• Homeland security• Container monitoring

• Mobile environmental apps• Bird tracking • Zebranet

• Home automation

Some Sensor Network applications

http://www.uni.lu/


Characteristics of Sensor Networks

• Small-scale sensor nodes • Limited power they can harvest or store • Harsh environmental conditions • Node failures • Mobility of nodes • Dynamic network topology • Heterogeneity of nodes • Large scale of deployment • Unattended operation • Errors are common.

– Wireless communication– Noisy measurements– Node failures are to be expected

http://www.uni.lu/


Sensor nodeID: 2

Sink nodeID: 0

Server

Sensor nodeID: 4

Sensor nodeID: 3

Sensor nodeID: 1

System overview

http://www.uni.lu/


Querying The Network

http://www.uni.lu/


Response Retrieval

http://www.uni.lu/


• Manage sensor networks using database approach – , TinyDB

• Process SQL-style queries in network– Data collection

• “SELECT temperature FROM sensors SAMPLE INTERVAL ”

– Data aggregation• “SELECT AVG (light) FROM sensors SAMPLE INTERVAL ”

Network Sensor Query Processing

http://www.uni.lu/


TinyDB GUI

TinyDB Client APIDBMS

Sensor network

tinyOS

TinyDB query processor

0

4

1

5

2

6

3

7

Mote sidePC side

Sensor Network Architecture

http://www.uni.lu/


Platform

Hardware:

• The main challenge is to produce – Low cost– tiny sensor nodes

• Standards– ZigBee : http://www.answers.com/topic/zigbee

– 6lowpan :http://www.answers.com/topic/6lowpan

http://www.uni.lu/


Platform

Operating Systems:

• Bertha (pushpin computing platform) • BTnut Nut/OS • Contiki • CORMOS: A Communication

Oriented Runtime System for Sensor Networks

• eCos • EYESOS

• MANTIS (MultimodAl NeTworks In-situ Sensors)

• SenOS • SOS • TinyOS • t-Kernel • LiteOS • MagnetOS

http://www.uni.lu/


Platform

Middleware:• There is a need and considerable research efforts currently invested in the design of

middleware for WSN's

• There are various research efforts in developing middleware for wireless sensor networks. http://www.answers.com/topic/wireless-sensor-network#wp-_note-hadim2006]

• Centralized middleware

• Distributed Middleware: can be classified into distributed database, mobile agents, and event-based http://www.answers.com/topic/wireless-sensor-network#wp-_note-04]

http://www.uni.lu/


Platform

Programming languages:

• Programming the sensor nodes is difficult when compared to the normal computer systems.

• The resource constrained nature of these nodes gives rise to new programming models.– DCL (Distributed Compositional Language) – galsC : work with tinyOS– nesC : extension of C language– Protothreads – SNACK ; Sensor Network Application Construction Kit over tinyOs

– SQTL : Sensor Query and Tasking language

http://www.uni.lu/


Platform

Simulators:

• Network simulators– OPNET, ns-2, Monarch (based on ns-2), GloMoSim, OMNET++

• Sensor network wireless protocol simulators– UCLA SensorSim, GeorgiaTech SensorSimII, QSQ

• Sensor node simulators– TOSSIM (for TinyOS), TOSSF (based on SWAN)

• Application-oriented simulators– SENS, Siesta, EmStar

http://www.uni.lu/


Platform

Simulators:

• Network simulators

– OPNET, ns-2, Monarch (based on ns-2), GloMoSim, OMNET++

• Sensor network wireless protocol simulators– UCLA SensorSim, GeorgiaTech SensorSimII, QSQ

• Sensor node simulators

– TOSSIM (for TinyOS), TOSSF (based on SWAN)

• Application-oriented simulators– SENS, Siesta, EmStar

http://www.uni.lu/


Platform

www.answers.com/topic/wireless-sensor-networkSimulators:

• There are platforms specifically designed to simulate Wireless Sensor Networks,

– TOSSIM, which is a part of TinyOS. – Traditional network simulators like ns-2 have also been used.

http://www.uni.lu/


Platform

Simulators:

• Network simulators– OPNET, ns-2, Monarch (based on ns-2), GloMoSim, OMNET++

• Sensor network wireless protocol simulators

– UCLA SensorSim, GeorgiaTech SensorSimII, QSQ• Sensor node simulators

– TOSSIM (for TinyOS), TOSSF (based on SWAN)• Application-oriented simulators

– SENS, Siesta, EmStar

http://www.uni.lu/


• QSQ: tool that introduces Query Processing and Dissemination Protocol For Wireless Sensor Networks developed on TinyOS operating system, tested on Mica2 sensor motes.

• Operating Systems – Linux – Tiny OS – Windows NT, 2000, XP

• Simulation Tools – Glomosim – TOSSIM – NS-2

Simulation : QSQ

http://cse.yeditepe.edu.tr/tnl/wisent/htmls/hw-sw.htmlSimulators:

http://www.uni.lu/


Simulation environment

• Operating System : TinyOS• Middleware: TinyDB• Simulator : OMNET++• Example of simulation: Application using QSQ

http://www.uni.lu/


• Operating system from David Culler’s group at Berkeley

• C-like programming environment

• Provides messaging layer, abstractions for major hardware components

Hill, Szewczyk, Woo, Culler, & Pister. “Systems Architecture Directions for Networked Sensors.” ASPLOS 2000. http://webs.cs.berkeley.edu/tos

TinyOS

http://www.uni.lu/


• A distributed query processor for networks of Mica motes

• Goal: Eliminate the need to write C code for most TinyOS users

• Features– Declarative queries– Temporal + spatial operations– Multihop routing

TinyDB

http://www.uni.lu/


• Continuous variant of SQL : TinySQL

• Power and data-acquisition based in-network optimization framework

• Extensible interface for aggregates, new types of sensors

TinyDB Query Engine

http://www.uni.lu/


OMNeT++

http://www.uni.lu/


• Simulator designed for fixed, wired, distributed systems (such as: computer networks, multiprocessor systems…)

• Discrete time simulator• It is compatible with: DOS, UNIX, WINDOWS (uses

C++ and Tcl/Tk)• Several graphical interfaces allows debugging and

variables inspection• Offers support for parallel execution

OMNeT++ Features

http://www.uni.lu/


• Simulated objects are represented by modules– Modules can be simple or composed (depth of module

nesting is not limited)– Modules communicate by messages (sent directly or via

gates)– One module description consists of:

• Interface description (.NED file)• Behavior description (C++ class)

• Modules, gates and links can be created:– Statically - at the beginning of the simulation (NED file)– Dynamically – during the simulation

OMNeT++ Features

http://www.uni.lu/


• Support is offered for:– Recording data vectors and scalars in output files– Random numbers (also from several distributions)

with different starting seeds– Tracing and debugging aids (displaying info about the

module’s activity, snapshots, breakpoints)• Simulations are easy to configure using .ini file• Batch execution of the same simulation for different

parameters is also included

OMNeT++ Features

http://www.uni.lu/


• What is missing or not working as wanted:– Mobile entities and wireless communication between them are not

included– Static data types not allowed

• For storing data needed by all the modules a central manager has to be created

• Communication with this entity goes by messages (slow!)• Using pointers to it is not always good idea (parallel execution)

– Execution goes very slow with the increase of the number of messages and when using parameters

– Very slow 2D graphical interface made in Tk

OMNeT++ Features

http://www.uni.lu/


Nesct : translating language

Simulation : Solution

• NesCT allows running TinyOS programs in OMNeT++ by translating the code into C++ with OMNeT++ calls

• NesCT focuses on parsing nesc source code and creating OMNeT++ compatible components

• It may be accepted as a plugin for existing frameworks.

http://www.uni.lu/


Study case : Sensor database

• The sensor nodes are assumed to be deployed in an ad hoc network

• Sensor nodes give information about temperature

• A reverse multicast tree is constructed among the nodes

• The sink node disseminates a query Responses are collected through the reverse multicast tree

http://www.uni.lu/


Radio communication: sensor network

Simulation Controller: OMNET++

Application

OS Physical Interface

Node

Middleware

Routing protocol

Network

OS

Physical Interface

Node

Middleware

Nesct translator

TinyOS Physical Interface

Node

tinyDB

QSQ

Network

tinyOS

Physical Interface

Node

tinyDB

Application: Sensor database

Study case : Architecture

http://www.uni.lu/


Node Configuration

• #include omnetpp.h• #include tinyOSPkt_m.h• #Include tinyOSMain.h• #include "gen/csmRouterTest_TinyOSModule.h"

#include "gen/csmRouterTest_Main.h“• ...

Study case : Sensor database

http://www.uni.lu/


Code Generation

• NesCT build all the classes in a separate directory :[root@jaballi tictoc]# ./nesct.exe Application.nc

• It create new Makefile for your environment :[root@jaballi tictoc]# opp_makemake -c config –f

• Make the program : [root@jaballi tictoc]# make

Study case : translating the code : nesct

http://www.uni.lu/


Step 1:• Edit omnetpp.ini file and change wait-for-sf to true. After enabling this

option, the simulation will wait 10 seconds before starting to allow sf to connect:

• [root@jaballi tictoc]# ./bin/sf_sim

Listening to tossim-serial SF enabled, 0 clients, 0 packets read, 0 packets written

Study case : Running the program

http://www.uni.lu/


Step 2:• Run java driver in other console

[root@jaballi tictoc]#java driver.Driver Created server socket Thread starting to wait for mote to pc connection

• [root@jaballi bin]# export DBG=usr1,usr2,usr3[root@jaballi bin]# ./Program


http://www.uni.lu/



http://www.uni.lu/


Output before Message injection

u16 local_node_id = 0;u16 destionation_id = 0;u16 message_type = SETUP_MESSAGE;u16 region_id = 1;u16 hop_count = 0;u16 flooding_degree = 20;u16 query_timeout_type = SEMA_SECOND;u16 query_timeout_value = 60;u16 concatenate_flag = 0;u16 acknowledge_flag = 0;u16 continuous_flag = 1;

u16 query_type = SENSING_RELATED;u16 query_frequency_type = SEMA_SECOND;u16 query_frequency_value = 5;u16 subquery_count = 1;

u16 subquery_type = SENSING_RELATED;u16 subquery_sensor_type = TEMPERATURE_SENSOR;u16 subquery_sample_count = 1;u16 subquery_compilation_function = LOWER;u16 subquery_compilation_data = 65535;

http://www.uni.lu/


• By default all the sensor nodes are in sleep mode with radio interfaces enabled

• Whenever a sensor node receives a radio message, that node wakes up and starts to process the message

• None of the nodes will do anything until injection of a message from the pc

Study case : Message injection

http://www.uni.lu/


Study case : Message injection

Step 3:• "inject_listener" injects a message to the network and dumps the

incoming messages on the console window

• Inject_listener reads the query paramers from a file named "params.in". It can be changed

[root@jaballi bin]# inject_listener.exe

http://www.uni.lu/


src_id 65533dest_id 65535message_type 0region_id 5hop_count 0flooding_degree 20query_timeout_type 2query_timeout_value 60concatenate_flag 0acknowledge_flag 0continuous_flag 1query_frequency_type 2query_frequency_value 5subquery_count 1subquery_type 0subquery_sensor_type 2subquery_sample_count 1

Output after running inject_listener

subquery_compilation_function 7subquery_compilation_data 65535 subquery_type_2 0subquery_sensor_type_2 0subquery_sample_count_2 0subquery_compilation_function_2 0subquery_compilation_data_2 0subquery_type_3 0subquery_sensor_type_3 0subquery_sample_count_3 0subquery_compilation_function_3 0subquery_compilation_data_3 0subquery_type_4 0subquery_sensor_type_4 0subquery_sample_count_4 0subquery_compilation_function_4 0subquery_compilation_data_4 0

http://www.uni.lu/


Output after running inject_listener

http://www.uni.lu/


Study case : params.in

http://www.uni.lu/


• This message says that a querying network has to be constructed that's going to last for 60 seconds : query_time_out_value

• The setup message needs to propagate to a maximum of 20 hops. The sensor node will poll the sensing interface every 5 seconds and return the results each timer: flooding_degree

• therefore we'll receive 12 messages from each node at the pc side.

• other querying types are in available smTypes.h

Study case : params.in

http://www.uni.lu/


Difficulties encountered during simulation

• Omnet++ installation and configuration under Linux– Compiling the source code– Source code modification– Many bugs– No compatibility between old and new versions (tcl/tk, bison, c++

compiler…)– Shared librairies– …

http://www.uni.lu/



• IBMJava2-JAVACOMM-142.tgz

• IBMJava2-SDK-142.tgz

• dlmgr.pro

• avarice-2.0.20030825cvs-1.i386.rpm

• avr-binutils-2.13.2.1-1.i386.rpm

• avr-gcc-3.3tinyos-1.i386.rpm

• avr-insight-pre6.0cvs.tinyos-1.3.i386.rpm

• avr-libc-20030512cvs-1.i386.rpm

• graphviz-1.10-1.i386.rpm

• avr-gcc-3.3tinyos-1.i386.rpm

• avr-insight-pre6.0cvs.tinyos-1.3.i386.rpm

• avr-libc-20030512cvs-1.i386.rpm

• graphviz-1.10-1.i386.rpm

• make-3.80tinyos-1.i386.rpm

• nesc-1.1.2b-1.i386.rpm

• tinyos-tools-1.1.0-1.i386.rpm

tinyos-1.1.0-1.noarch.rpm

• Programs written wiyh tinyOS language– tinyOS installation (it needs more than 10 tools installed before)

http://www.uni.lu/



• Integration of Omnet++ and Nesct– Compilation errors– New language used: nesc– Using of MPI (distributed computing and communication)

• SQS protocol

http://www.uni.lu/



• No documentation

http://www.uni.lu/


Conclusion

• Sensor Networks: a hot topic– One of emerging technologies that will change the world

Technology Review– Startup companies

• Crossbow, Dust, Ember, Sensicast, Moteiv, etc.

– New conferences

• ACM SenSys, IEEE IPSN, etc.

– Many applications

http://www.uni.lu/


Conclusion

• New industrial research lab projects– Intel, PARC, MSR, HP, Accenture, etc.

• New university courses and research– Routing protocol– Simulation– New tools– …Feasibility of the simulation of sensor databases with a generic network

simulator

Sensor databases can be simulated with the generic network simulator OMNET++

http://www.uni.lu/


• The TinyOS home page:– http://webs.cs.berkeley.edu/tinyos

• TinyDB home page:– http://telegraph.cs.berkeley.edu/tinydb

• Crossbow (motes & stargates):– http://www.xbow.com

• Moteiv (motes)– http://www.moteiv.com

• OMNeT++ website.– http://whale.hit.bme.hu/omnetpp/

• EYES project.– http://eyes.eu.org.

• Simulation template website.– http://wwwhome.cs.utwente.nl/ dulman/tools.htm.

• SENS: A Sensor, Environment and Network SimulatorSameer Sundresh, Wooyoung Kim and Gul AghaUniversity of Illinois at Urbana-Champaign

Presented at ANSS 37, April 21, 2004– http://osl.cs.uiuc.edu

References

http://www.uni.lu/

feasibility of the simulation of sensor databases with a generic network simulator - supervisor :...

Documents

sensor databasedifficulties

wireless sensor networks

simulation of sensor

hoben ralf student

jaballi walid date

simple nodes

developing middleware

design of middleware