250 likes | 333 Views
eScan implementation on TinyOS. Jisu Oh May 8, 2006 CS 580S Project Presentation. Problems – Do you need energy-aware sensor network systems?. The requirement of ENERGY EFFICIENCY pervades all aspects of the sensor network system design.
E N D
eScan implementation on TinyOS Jisu Oh May 8, 2006 CS 580S Project Presentation
Problems – Do you need energy-aware sensor network systems? • The requirement of ENERGY EFFICIENCY pervades all aspects of the sensor network system design. - Sensor nodes have only finite energy reserves from a battery - Necessary to detect hazardous conditions such as node death or unpredictable network change in advance - For routing, wireless communication, query processing, security etc. Residual Energy Level is one of the most significant sensor network resources!
Problems – Do you need energy-aware sensor network systems? (cont.) • Unattended and ad-hoc nature - Sensor nodes might be autonomously deployed in an unplanned fashion Drop from an airplane, any changes due to harsh environment Continuously updating the sensor network health indications is critical
Solutions – Residual Energy Scan (eScan) • eScan proposed by Zhao et al (WCNC ’02) to monitor and display abstracted view of energy resource distribution in sensor networks - Simulation using C++ packet - Need to see how eScan works at a real sensor network • Goal of this project - Learn TinyOS and implementation techniques on real sensor motes - Implementation of the eScan
Today’s talk • eScan overview • eScan implementation
eScan challenges • Severe constraints in wireless sensor networks -Limited energy - Limited memory - Limited bandwidth Impractical to extract residual energy level of each individual node Resources for eScan should be minimized since eScan works under other applications
eScan approaches • A residual energy scan, eScan, depicts the remaining energy levels of sensor nodes • Using in-network lossy aggregation • trading-off system lifetime and data accuracy An example of residual energy map
eScan Key ideas • eScan tuple -<value, coverage> - value: (min, max) residual energy level in coverage area e.g. (35%, 37%) - coverage: a polygon region described by value, which is the locations of boundary nodes e.g. {(3,3), (3,2), (2,2)} eScan A eScan B eScan C
eScan Key ideas – Constructing eScans • 1. Determining local eScans - Each sensor generates a local eScan tuple. e.g., Let node A have battery power v at location (x,y) Local eScan of A is <(v, v) {(x, y)}> • 2. Only disseminates when the energy level drop significantly since last reported its eScan eScan B Value: (v_b, v_b) Coverage: (x_b, y_b) eScan A Value: (v_a, v_a) Coverage: (x_a, y_a) eScan C Value: (v_c, v_c) Coverage: (x_c, y_c)
eScan Key ideas – Constructing eScans (cont.) • 3. Aggregating eScans - At an intermediate node, received eScans are combined into one aggregated eScan based on value similarity and spatial adjacency. - Aggregate two eScan A and B when - Tolerance T is the maximum allowed relative error of residual energy value by aggregation - Resolution R is a spatial adjacency threshold
eScan Key ideas – Constructing eScans (cont.) • New eScan C is defined as C.min = min{A.min, B.min} C.max = max{A.max, B.max} ∴size(C) < size(A) + size(B) C.Coverage = Merge(A, B, R) eScan A v: (35%, 37%) eScan C v: (35%, 37%) eScan B v: (35%, 36%)
Why eScan is important • Data aggregation from completely new angle - Aggregation of informative data instead of sensed data from environment - Nofity to users when additional sensors should be deplyed due to serious energy depletion or abnormal working - Auto-scaled by varying their resolutions - Incremental updates when its local state has changed significantly
eScan implementation • Project progress - Installation TinyOS - Study TinyOS architecture and components and NesC fundamentals - Use TOSSIM to test/debug - Measure residual power at each sensor node - Route those readings via geographic forwarding - Aggregate eScans at intermediate node - Download app into MICA2 motes to run an experiment - Visualize eScans (not yet impelmented)
eScan packet format – Escan.h • <type, srcAddr, destAddr, min, max, x1, x2, y1, y2> - type: local or aggregate - srcAddr, destAddr: source/destination node location - min, max: minimum/maximum remaining battery voltage - x1, x2, y1, y2: (x1, y1) is a left bottom location and (x2, y2) is a right upper location of aggregated eScans coverage - Note: coverage is boundary locations of a combined polygon in the original paper. But here, I use square representation in order to simplify.
Key components – Escan.nc, EscanM.nc • Battery voltage - interface BatteryADC - Read battery voltage reference from ADC7 channel at every second - Convert it into voltage value using (refer TinyOs Tutorial : Lesson 8) Vout = Vref * ADC_FS / ADC_output Vref = 1.223V (battery Vcc voltage) ADC_FS = 1024 ADC_output = reading from ADC channel 7 - Generate a local eScan <local, myAddr, destAddr, v, v, x, x, y, y>
Key components – Escan.nc, EscanM.nc (cont.) • Battery voltage event result_t BatteryADC.dataReady(uint16_t data){ Convert raw reading into battery voltage; Update if voltage value is droped more than Tolerance; if(isQNull) insert a local escan into a queue else post agg_escan(); }
Key components – Escan.nc, EscanM.nc • Receive eScan from other nodes event TOS_MsgPtr Radio.Receive.receive(TOS_MsgPtr data){ if(isQNULL) insert received escan into a queue; else post agg_escans(); } • Aggregate eScans - Same manner as one at original paper - Aggregate updated local eScan or newly received eScans with queued eScans (max queue size = 10) - At every 10 seconds, disseminate queued eScans
Key components – Escan.nc, EscanM.nc • Aggregate eScans • task void agg_escans(){ • if( inT(escan X, q[i]) && inR(escan X, q[i]) ) • then new eScan Y = aggregate(escan X, q[i]); • else { • if(isQFull && local_escan) • then call RadioSend.send(); • else if(isQFull && received_escan) • then Drop received eScan; • } • }
Multi-hop routing – Geographic forwarding • Geographic Forwarding - Original paper constructs a typical spanning tree as an aggregate tree ∙ Base station floods INTEREST message ∙ Once sensor node x receives the message from node y, x indicates y as a parent. - Since eScan transmit location associated packet, a location-based protocol would be work more appropiately. - Thus I choose GF in this implementation
Multi-hop routing – Geographic forwarding (cont.) • Assumptions - Each node already knows its own location - Parent is a node which is closest to base station among one-hop neighbors - Implementing routing protocol is beyond of this project so I don’t present more detail about routing now.
Experiment • eScan v.s. Without aggregation - #node: 9 - Tolerance: 20% - Resolution: 2 - TinyViz
Experiment (cont.) • eScan v.s. Without aggregation - #node: 9 - Tolerance: 20% - Resolution: 2
Future work • Visual representation of eScan • Conduct experiment to wee the performance of the energy consumption • Compare the experiment with C++ simulation results • Embed as a complementary to other sensor network application to identify particular network problems within particular region
Summary • Monitoring energy level of each sensor node is important in wireless sensor network • In-network processing could do it in energy-efficient manner • eScan is very simple and efficient aggregation to monitor the residual energy resource distribution within a sensor field