envirotrack: towards an environmental computing paradigm for distributed sensor networks –...

EnviroTrack: Towards an Environmental EnviroTrack: Towards an Environmental Computing Paradigm for Distributed Sensor Computing Paradigm for Distributed Sensor

Networks – Abdelzaher Tarek,etc Networks – Abdelzaher Tarek,etc An Entity Maintenance and Connection Service An Entity Maintenance and Connection Service

for Sensor Networks – Brian Blum,etcfor Sensor Networks – Brian Blum,etc

EnviroTrack: Towards an Environmental EnviroTrack: Towards an Environmental Computing Paradigm for Distributed Sensor Computing Paradigm for Distributed Sensor

Networks – Abdelzaher Tarek,etc Networks – Abdelzaher Tarek,etc An Entity Maintenance and Connection Service An Entity Maintenance and Connection Service

for Sensor Networks – Brian Blum,etcfor Sensor Networks – Brian Blum,etc

Presented by Qiuhua CaoPresented by Qiuhua CaoComputer Science DepartmentComputer Science Department

University of VirginiaUniversity of VirginiaNov 3th, 2003Nov 3th, 2003

What is this session for?

Introduce some possible answers to the question “what could or should be the most efficient programming model for wireless sensor networks?”

Programming ParadigmAssembly Language(Z80)Procedure Based (C)Object-Oriented (C++, Java)AspectJComponent Based (NesC)

Abstraction Level

Easier for programming, debugging, testing,…Higher reusability, extendability, etc

Outline

Design GoalsContributionsBasic IdeasCritiques Experimental Results AnalysisExtensionsConclusion

Design GoalsProvide an object-based distributed

middleware system that raise the level of programming abstraction

Provide a middleware architecture for coordination services that facilitates interaction between groups of sensors which monitor different environmental events

Provide higher level abstraction of logical entity semantic from physical location

ContributionsHigher level programming abstraction

(or friend interface to use the middleware service)

Architecture for mobile end-to-end transport-layer connections

Entity Uniqueness MaintenanceSystem Variables Analysis

Example Scenario

What can be hidden from programmer?

Group communicationLocation of the groupAnything else?

Programming Model(1)

Two partsProgramming Language ?Group Communication Middleware

Programming Model(2)Middleware service interface keywordsContext type – the type of context (group

function)Context label – logic address ( or group id)Tracking object – computation unitApplication example:

Whenever some motes’ the magnetic sensor reading greater than the threshold value, they form a group to track the target. And the group reports the target location to the base station every 5ms.

System:

Tinyos (event driven operating system), group communication middleware, remote object communication middleware service

Programming Model(3)begin context tracker

activation: magnetic_sensor_reading()location:

avg(position),confidence=2,freshness=1sbegin object reporter

invocation:TIMER(5s)report_function(){

MySend(pursuer,self.label,location)}

endend context Activation – group creation condition

Aggregation state – location, average,…

Invocation – create instance condition

Object action declaration, user need to provide definition; Object also run on the leader

Create a group named as tracker


AF=avg(position)

Freshness=1s

Critical mess Ne=2??

Object reporter, every 5s,send the entity location to the pursuer

Programming Model(5)Mapping to traditional OO

ObjectState

Function

Object: group

State: confidence, freshness, critical mess

Private function: aggregate function (avg,etc)

Public function: reporter

Any Problem here?


For the same application, if just use NesC, what the programmer needs to do?

Programming Model(7) the nesC

model:– interfaces:

• uses• provides

– components:• modules• configuratio

ns application:=

graph of components

Component A

Component B

ComponentD

Component C

Application

configurationconfigurationComponent

E

ComponentF

Review of NesC


module tracker{provides{

interface StdControl;}uses{

interface MagneticSensor;interface GroupCommunication;

}}

implementation{bool state;command result_t StdControl.init(){

state = FALSE;call MagneticSensor.init(threshold);return SUCCESS;

}command result_t StdControl.start(){

return call MagneticSensor.start();//start sensing}command result_t StdControl.stop(){

return call MagneticSensor.reset();//stop sensingreturn call

GroupCommunication.desolveGroup(…);//desolve}event result_t MagneticSensor.fire(){

if(state){call

GroupCommunication.createGroup(report,timer,location,avg,confident,freshness);

}}

}


Magnetic_sensor_reading() Not use the group middleware

interface directly, but still think a group/entity in mind

Hidden the detailed information of group communication service from the programmer

Programming model is only useful if user needs to use the group communication service

Programmer needs to know NesC and the programming model in paper

MagneticSensor component GroupCommunication

component Hidden the detailed

information of the group communication service from the programmer

Programming model is suitable for all the applications and the system

Programmer only needs to know NesC

EnviroTrack NesC


CritiquesA language??

Not sureFlexibility? (tight a programming

paradigm with an application)A big win?

Not sure

Programming Model(11)CritiquesExport a novel logical address

space in which external environmental objects are the labeled entities

Allow arbitrary data, computation, or actuation to be attached to such logical network address

The benefits are coming from group communication service, or from programming model??

Group Communication Service Architecture

Group membership management service

Inter-group communication service

Intar-group communication service???

Assumptions

Each node has its own locationNode is staticTarget is movingEvents are sparseAnything else?

Entity Management Module(1)

• Entity/Group Management Module– Leader

• Inside sensing area• Win in leader election

– Member• Inside sensing area• Fail in leader election

– Follower• Outside sensing area• Aware of the group

existence

Entity Management Module (2)

Node State Transition Diagram

Entity Timeout Timer

Fail leader timer

Alive counter

Leader handoff

Leader handoff

Entity Management API

join(signature)leave(signature)leader(entity, on_off)store(entity, state)get(entity,state)

Entity UniquenessEvent Speed

Extending awareness horizon Maximum speed = (ah -2sr)/D

Message Loss Alive counter at leader Killing message Min time alive (across same signature

entities) Entity timeout period (free follower)

Node Failure Failed leader timer > heartbeat period

Entity Connection Module(1)

Entity Connection

Entity Connection Module(2)

Connections identified as <Entity ID, Port Num>

Entity RegistrationDirectory Service

very abstract description, no detailed information how it is really achieved

Experimental Results Analysis(1)

Simulation Setup Radius Radio –220meter Network layer –Geographic Forwarding MAC –802.11B Physical Layer – Two-Ray Pathloss model 1400 * 1400 meter field Sensor sampling period – 0.05seconds Each point in the graph is the mean of

10trails

Experimental Result Analysis(2)

Failed leader timer = 2 heartbeat period

Entity timeout period = 1.5 FLT = 3hopRR = 220m

FR = 1400m

Even the speed is 96m/s, it needs 2s to move out the RR. High speed??

Experimental Result Analysis(2)

220nodesThe red line is for speed 96m/s

Heartbeat period = 375ms

Failed leader timeout = 750ms

Entity timeout = 1.5*750ms=1125ms = 1.1s

RR = 220m

Speed = 96m/s

Experimental Result Analysis(2)220nodes

Red line is speed 92m/s

HB =6000ms

Group id =4.5

RR = 220m

1hop =220m

2hop =440m

3hop = 660m

H = 660/92=7s

CritiquesRadius radio vs Sensing rangeHow the group formedHow the two end-to-end mobile entities

communicateWhat is a good entity timeout timerWhat is a good failed leader timerHow to maintain consistent alive counterHow to achieve seamless while leader

handoffWhen the two mobile end-to-end entities

need to communicateHow complex of directory serviceHow complex of leader election

Extension (1)

EnviroTrack Middleware

Tracking Module

Group Management

Module

Report Communication

Module

Aggregation Module

Sensing Module

Localization Module

Routing Module

User Interface

Magnetic Sensor Module

Light Sensor Module

Motion Sensor Module

Configure Module

GenericComm Module

Several slides after this slide are the work is doing in our group currently

Extension(2)Friendly User Interface – simple

EnviroTrack Language and its compilerNew Group Management Algorithm –

Dealing with multiple events, distributed events, crossing events and maintaining unique tracking object labels

Power efficient Inter-object communication support

Extension(3)New Group Management’s

ChallengeChallenge 1: How to keep multiple

object labels when multiple physical targets overlapping each other?

Challenge 2: How to ensure there is no two objects with the same label when multiple objects separate after merging?

Extension(4)

Inter-object CommunicationHow to differentiate objects

throughout the network?most tracking objects are moving

continuously, how to implement mobile-mobile communication?

Moreover, how to implement mobile-mobile communication in a power-efficient way?

Conclusion

Higher abstraction levelFramework for group

communication service

Questions?

Thanks!!!

envirotrack: towards an environmental computing paradigm for distributed sensor networks –...

Documents

group communicationlocation

programming model6for

efficient programming

magnetic sensor

definition object

wireless sensor networks

middleware servicearchitecture

middleware architecture