Peer to Peer Overlay Network for Sensor net

Peer to Peer Overlay Network for Sensor net

Eng. Husam Alzaq Computer Engineering Department

Islamic University of [email protected]

1

mailto:[email protected]

Peer to Peer Overlay Netzwerk für SensorennetzeHusam Alzaq

AgendaConclusionDesign & EvaluationBackgroundIntroduction

Introduction Background on

Wireless Sensor Network Peer to Peer Systems

Concept Implementation Results Conclusion

2/31


What are Wireless Sensor Nodes?ConclusionDesign & EvaluationBackgroundIntroduction

They are small electronic components capable of sensing many types of information from the environment.

They are equipped with a certain amount of computational power, communication, storage and often actuation resources.

3/31


What is WSN?ConclusionDesign & EvaluationBackgroundIntroduction

It is a network that has multiple nodes connected to each other wirelessly

Sensor Network is distributed and is not structured.

4/31


Constraints/ChallangesConclusionDesign & EvaluationBackgroundIntroduction

Hardware Power Consumption

Software Issues to be addresses:

Lifetime maximization Robustness and fault tolerance Self-configuration

Algorithms Design of energy-aware algorithms

5/31


MotivationConclusionDesign & EvaluationBackgroundIntroduction

Motivation Home/Office Observing

–How can a user connect to Wireless Sensor Network over Internet?

–How can a user retrieve the sensor data?

What is the temperature

at lab146??

6/31


MotivationConclusionDesign & EvaluationBackgroundIntroduction

Solution Peer to Peer Systems provide an

overlay network that is able to connect a user to a Wireless Sensor Network.

Declarative Query would serve as a way to express user’s requests.

7/31


A Middleware for Sensor NetworksConclusionDesign & EvaluationBackgroundIntroduction

A middleware for sensor networks supports the development, maintenance, deployment, and execution of sensing-based applications.

Building a Peer to Peer application on existing WSN is important. The complexity of accessing different sensor

nodes must be hidden. Many services can be offered.

– Discovering Sensor gateway– Obtaining sensor data

Distributed Wireless Sensor Networks (WSNs) can be observed.

8/31


Peer to Peer SystemsConclusionDesign & EvaluationBackgroundIntroduction

A Peer to Peer system is defined as a class of systems and applications that employs distributed resources to perform a critical function in a decentralized manner.

The resources encompass computing power, data, network bandwidth ...etc.

The critical function can be distributed computing, data/content sharing, communication and collaboration, or platform services.

9/31


Peer to Peer CharacteristicsConclusionDesign & EvaluationBackgroundIntroduction

Symmetry Decentralization Scalability Fault tolerant Self-Organization Resources Sharing Fast Resource Location to determine where to find the

resource

10/31


Peer to Peer ClassificationConclusionDesign & EvaluationBackgroundIntroduction

11/31


Peer to Peer ClassificationConclusionDesign & EvaluationBackgroundIntroduction

Un stru ctu re d Pe e r to Pe e rStructure d Pe e r to

Pe e r

Hyb rid Pu re (fu llyde ce ntralize d)

Su p e r-p e e rmo d e l

Distribute d Ha shTa ble (DHT)-Ba se d

1 . C en tra l pee r isnecessa ry top rov ide these rv ice .2 . C en tra l pee r isused to indexpee rs in fo rma tion .Examp le :Napste r

1 . A ll pa rtic ipan tsa re equa l.2 . Any pee r can beremoved withou tloss o f functiona lity3 . No cen tra l pee r.Examp le : F reene t

1 . T wo d iffe ren tpee rs.2 . Any pee r can beremoved withou tloss o f functiona lity3 . D ynamic cen tra lpee r.Examp le :Jx ta ,Kaz aa

1 . Sea rch ing ise ffective .2 . Manag ingnodes a reexpensive .3 . C onnections inthe ove r lay a re“fixed ” Examp les:C ho rd , C AN

P eer

P eer

le af no d e

S u p e r -n o d e

12/31


Why Jxta?ConclusionDesign & EvaluationBackgroundIntroduction

Jxta is a generic overlay network system. It consists of a set of protocols that are language,

platform and network independent. Java based and C implementation

It connects devices on the network ranging from embedded system and cellular phones to PCs and servers.

13/31


Application OverviewConclusionDesign & EvaluationBackgroundIntroduction

14/31


RequirementsConclusionDesign & EvaluationBackgroundIntroduction

Application Requirements Detect sensor gateways. Express user‘s requests in a SQL

language. Filter sensor data according to user

request.

Technical Requirements. Scalability. Interoperability.

15/31


Conceptual Design - ArchitectureConclusionDesign & EvaluationBackgroundIntroduction

Jxta Layer Governs the connection between a gateway and user

agents, and the overlay network. Ensures the interoperability between a gateway and

user agents.

16/31


Conceptual Design - ArchitectureConclusionDesign & EvaluationBackgroundIntroduction

Sensor Gateway Layers Sensor Network Interface Layer.

– Extracts data from a sensor UDP packet and hands it to the Sensor Application layer.

Sensor Application Layer. – Manages all interactions between users and sensor nodes

such as filtering data.

User Agents Layers User Interface Layer. WSN Application Layer.

– Handles all user queries.– Handles all messages.

17/31


Conceptual DesignConclusionDesign & EvaluationBackgroundIntroduction

Block Diagram

User Agent Sensor Gateway

18/31


Publishing & Discovery ProcessConclusionDesign & EvaluationBackgroundIntroduction

1. Sensor Gateway publishes Advertisements on sensor nodes.

2. Jxta Overlay Network indexes these advertisements.3. User Agent searches for advertisements.

Each advertisement includes Set of properties that describe the sensor gateway

– Name– Location– Description

Set of attributes that are provided by each sensor node. – types of data that the specified sensor can measure i.e.

temperature, light ... etc. and their units.

19/31


Message HandlerConclusionDesign & EvaluationBackgroundIntroduction

A gateway and a user agents exchange a Jxta XML messages over a Jxta pipe.

Messages are used to Create a new filter Remove a filter Send the filter results

20/31


Distributed Query ProcessConclusionDesign & EvaluationBackgroundIntroduction

Requests are expressed in a SQL-like query language to retrieve sensor data.

User query consists of SELECT clause: specifies attributes, in which user is

interested in. FROM clause: specifies the name of the sensor

gateway. WHERE clause: filters sensor records by a predicate. DURATION clause: is the period of time, which

specifies how long the query should be run before terminated and removed from the filter list.

(Select * From lab146.ibr.cs.tu-bs.de where Temperature < 20 duration = 600)

21/31


Distributed Query ProcessConclusionDesign & EvaluationBackgroundIntroduction

Query is distributively processed as follows:

1. The gateway name is extracted from the user query (specified in FROM) in order to establish a connection with the gateway.

2. The WHERE clause is encapsulated in a Query XML-based message.

3. The Query message is sent out to the gateway.

4. After that, the received results are displayed according to SELECT clause.

5. Query is terminated either by user or by gateway.

22/31


Filter ProcessConclusionDesign & EvaluationBackgroundIntroduction

Filter process is a way to suppress sensor tuples from randomly propagation and hand them in graceful manner to all interested users

Sensor tuples are a discrete raw of data generated at discrete time not stored in a data warehouse.

Filter is created by a user query. Filter is activated for each received tuples. Filter is only deleted in two cases

by user -> explicitly or implicitly time is up

23/31


Filter ProcessConclusionDesign & EvaluationBackgroundIntroduction

Filter mechanism is based on attributes, which are described by key-value-operator. Key indicates the semantics of the attribute Operator describes how attributes will match when two

attributes are compared (<, >, =, ... etc.). . Typical attributes values

– Sensor reading includes, temperature, voltage, light ....etc.– Meta-data encompasses general information about a

sensor node e.g. sensor ID. – Internal state is any information that is not related to

sensor reading, such as timestamps.

24/31


ImplementationConclusionDesign & EvaluationBackgroundIntroduction

A Sensor Gateway implements the basic functionality of the sensor agent.

The implementation is based on Jxta-C (version 2.5).

A User Agent prototype implements a user interface for JMSN, which is able to • discover advertisements• access any available sensor

network.

The implementation is based on Jxta J2SE platform.

A prototype for a sensor application over a Peer to Peer System is named as Jxta Middleware for Sensor Network (JMSN). It consists of:

25/31


User Agent, GUIConclusionDesign & EvaluationBackgroundIntroduction

26/31


EvaluationConclusionDesign & EvaluationBackgroundIntroduction

Test-bed Equipments Tests ware performed at the Workstation pool of IBR,

where twelve machines of identical hardware are used. They are equipped with

– Intel Pentium(r) D CPU 3.2GHz

– 2.00 GB of RAM

– Fast Ethernet card. Half of them run Windows XP and the other run Debian

GNU/Linux distribution.

27/31


Evaluation - Memory PerformanceConclusionDesign & EvaluationBackgroundIntroduction

This memory footprint is mainly due to the Apache Runtime (APR), which is embedded in the Jxta-C implementation.

It is observed that 8 threads are created (using DDD - Data Display Debugger)

Summary of memory consumption tests.

28/31


Evaluation – Filter OverheadConclusionDesign & EvaluationBackgroundIntroduction

Constant message size Time is linear in n with a slope of

210.4 ms/filter operation. The overhead of each filter

process includes the time to process the filter searching for user

PipeAdvertisement establishing a connection sending the message.

– TCP transport is using blocking I/O.

29/31

0

500

1000

1500

2000

2500

0 2 4 6 8 10 12

Number of Filters

Ave

rage

Tim

e ( m

s )


ConclusionConclusionDesign & EvaluationBackgroundIntroduction

Peer to Peer Systems provide a decentralized approach that does not require any costly infrastructure.

Jxta was selected among other systems since it is a generic overlay network that connects devices on the network.

The design of “Peer to Peer overlay network for sensornets” combines a peer service discovery with a distributed query processing.

JMSN design doesn‘t come without cost. Results showed that the current implementation of Jxta-C consumes memory, which is not efficient for embedded system with limited memory.

30/31


Future WorkConclusionDesign & EvaluationBackgroundIntroduction

It is essential to extend the current version of Jxta-C implementation to cope with the limited memory devices.

It is necessary to enhance the user agent with complex query searching by partial names and attributes such as Location.

Aggregate function such as Average, Max, Count ...etc.

31/31


ConclusionDesign & EvaluationBackgroundIntroduction

الستماعكم :; شكرًَاThanks for your attention

32/31

Documents

Peer to Peer Overlay Network for Sensor net