EnviroTrack: Towards an Environmental Computing Paradigm for Distributed Sensor Networks – Abdelzaher Tarek,etc An Entity Maintenance and Connection Service for Sensor Networks – Brian Blum,etc Presented by Qiuhua Cao Computer Science Department University of Virginia Nov 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 Paradigm  Assembly Language(Z80)  Procedure Based (C)  Object-Oriented (C++, Java)  AspectJ  Component Based (NesC) Abstraction Level Easier for programming, debugging, testing,… Higher reusability, extendability, etc

Outline  Design Goals  Contributions  Basic Ideas  Critiques  Experimental Results Analysis  Extensions  Conclusion

Design Goals  Provide 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

Contributions  Higher level programming abstraction (or friend interface to use the middleware service)  Architecture for mobile end-to-end transport-layer connections  Entity Uniqueness Maintenance  System Variables Analysis

Example Scenario

What can be hidden from programmer?  Group communication  Location of the group  Anything else?

Programming Model(1) Two parts  Programming Language ?  Group Communication Middleware

Programming Model(2) Middleware service interface keywords  Context type – the type of context (group function)  Context label – logic address ( or group id)  Tracking object – computation unit Application 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=1s begin object reporter invocation:TIMER(5s) report_function(){ MySend(pursuer,self.label,location) } end end 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

Programming Model(4) AF=avg(position) Freshness=1s Critical mess N e =2?? Object reporter, every 5s, send the entity location to the pursuer

Programming Model(5) Mapping to traditional OO Object State Function Object: group State: confidence, freshness, critical mess Private function: aggregate function (avg,etc) Public function: reporter Any Problem here?

Programming Model(6) 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 Component D Component C Application configuration Component E Component F Review of NesC

Programming Model(9) 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 sensing return call GroupCommunication.desolveGroup(…);//desolve } event result_t MagneticSensor.fire(){ if(state){ call GroupCommunication.createGroup(report,timer,location,avg,confident,fresh ness); }

Programming Model(10)  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

Programming Model(10) Critiques  A language?? Not sure  Flexibility? (tight a programming paradigm with an application)  A big win? Not sure

Programming Model(11) Critiques  Export 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 location  Node is static  Target is moving  Events are sparse  Anything 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

Entity Management Module(3)

Entity Management Module(4)

Entity Management API  join(signature)  leave(signature)  leader(entity, on_off)  store(entity, state)  get(entity,state)

Entity Uniqueness  Event 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 Registration  Directory 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 = 3hop RR = 220m FR = 1400m Even the speed is 96m/s, it needs 2s to move out the RR. High speed??

Experimental Result Analysis(2) 220nodes The red line is for speed 96m/s Heartbeat period = 375ms Failed leader timeout = 750ms Entity timeout = 1.5*750ms=1125 ms = 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

Critiques  Radius radio vs Sensing range  How the group formed  How the two end-to-end mobile entities communicate  What is a good entity timeout timer  What is a good failed leader timer  How to maintain consistent alive counter  How to achieve seamless while leader handoff  When the two mobile end-to-end entities need to communicate  How complex of directory service  How 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 compiler  New 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 Challenge  Challenge 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 Communication  How 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 level  Framework for group communication service

Questions? Thanks!!!