BBS-samaram

8/3/2019 BBS-samaram

1/20

Presented by

samaram


2/20

Introduction

Keywords

Bubble Sensing

Implementation Challenges

Conclusion


3/20

Bubble Sensing System acts as a to support

the persistent sensing of a particular

location, as required by user requests.

We adopt a two tier architecture comprising

the bubble sever on the back end , and

sensor enabled mobile phones as the front

end which perform actions like initiatingbubbles, maintaining bubbles sampling and

reporting sensed data.


4/20

Bubble Creator-device whose user initiates the sensing

request that leads to creation of the sensingbubble.

Bubble Anchor

-keeps the bubble in the region of interestby broadcasting the sensing request.

Sensing Node-perceives the bubble by listening to the

broadcasts , takes samples according torequest and upload the results t the bubbleserver.


5/20

Keywords

Bubble Carrier

-helps to restore a bubble if all

the bubble anchors are lost.

Bubble Server

-binds the results to the bubble,

which can be queried by the bubblecreator at any time.


6/20

Sensing task are created and maintained in the

bubble-sensing system through the interaction

of number of virtual roles.

Sensing Task

Action DurationRegion

location radius


7/20

Bubble Creation

Bubble Maintenance

Location-based

Mobility-based

Bubble Restoration


8/20

Bubble creator is a mobile device at

location of interest with an short range

for local peer interaction.

Creator broadcasts the sensing task.

Bubble Creation

mobile Bubble Server


9/20

If the creator has localization capability, it

populates the region field of the task definition and

the sensing bubble is created with its center at this

location.

Otherwise the region field of the task def. is left

blank until sensing bubble is created with its at

current location of the creator where the area of

bubble is determined by its radio transmission range.

Nodes that receive the task broadcast & meet the h/w

and context requirements for sensing task can then

sense in support of the task and will later upload

sensed data to bubble server in either a delay-tolerant

or real time manner.


10/20

Reason for maintaining the bubble is:

Uncontrolled mobility of the creator.

the creator leaves the bubble location

while the task is still active.

Effect of this, is that no longerappropriate for creator to broadcast the task

since recipients will not be in target bubble

location.

Solution is to anchor the bubble to

location of interest is needed and the node which

takes this role should be relatively stationary at

target location of the task.


11/20

Two variants for bubble anchor selection are: requires localization capability on all nodes

Uses inference from an accelerometer for mobility

detection. All sensing nodes that are able to hear the

broadcast messages are called potential

anchors.


12/20

Location based:

In this location based maintenance , thebubbles are maintained based on the location of

the bubble created.

Each candidate anchor backs off a time

proportional to its mobility in terms of location

fixes.

Mobility based:

In this mobility based maintenance , the

bubbles are maintained based on the radio rangeof the mobile phones.

Each candidate anchor backs off a time

proportional to its mobility in terms of data

collected by its accelerometer


13/20

Due to node mobility, it may happen that no

nodes are available to anchor the bubble to

desired location and bubble may temporarily

disappear.

We can overcome this scenario by using

bubble restoration through the actions of

the bubble carrier nodes.

Mobile phones filling this role require

localization capability and a connection to

backend bubble server.


14/20

Bubble carriers periodically contact thebubble server, update their location, and

request any active sensing bubbles in thecurrent region.

I f a bubble carrier visits location ofone of these bubbles and doesn't hear anytask broadcasts , it attempts to restore thebubble by broadcasting task withoutspecial anchor field set.

As result ,it either be restored with a newanchor node and takes over bubble

maintenance or restoration fails and theprocess continues via bubble carrier untilbubble expires.


15/20


16/20

Programming Language The programming language needed is PYS60.

PYS60 not only supports the python languageand it support the symbian platform.

Communication

For communication we can use GPRS,3G,Bluetooth and Wi-Fi.

It uses Ad-Hoc mode when interacting locallywith peers, and infrastructure mode toconnect to the bubble server.


17/20

Increased Bubble Sizes

Bubble DriftAnchor moves

can be reduced timeout to the probabilistic

limit the bubble drift is limited to desired level.

Mobility based maintenance

slow moving anchors in the bubble takes over

the role.


18/20

to support persistent location-specific task

in a wireless sensor network composed of

mobile phones.

Mobile sensor nodes collaborate and sharesensing and communication resources with

each other in a cooperative sensing

environment.

virtual roles nodes can assume in support ofbubble-sensing, including the required local

and backend communication.


19/20


20/20

Date post:	06-Apr-2018
Category:	Documents
Upload:	sam-ram
View:	213 times
Download:	0 times

BBS-samaram

Documents