Download
1 / 22
220 likes | 328 Views
WSNM. Ajay Vyasapeetam Brijesh Shetty Karol Gryczynski. WSNM (Wireless Sensor Network Management). The Problem We would like to observe (and control) the behavior of individual nodes in our sensor network
E N D
WSNM Ajay Vyasapeetam Brijesh Shetty Karol Gryczynski
WSNM (Wireless Sensor Network Management) • The Problem • We would like to observe (and control) the behavior of individual nodes in our sensor network • Aim is to design a protocol for querying that is power efficient, reliable to an extent, and imposes least overhead on the network.
Protocol Requirements • Power : It should consume as little network resources as possible (power & computation). • Should obviously be better than simple broadcast. • Overhead : The overhead for this protocol should be minimal. • Latency :Should be done in fast enough to be interactive with human user. (Different applications can tolerate delays to varying extent) • Reliability
The Protocol • The Base station sends out a query with a sequence number specifying • Which mote to query • Which module to query • Base station broadcasts the query. • Nodes broadcast the query only once • If a node hears query again within a time-interval, it simply discards the query.
Query Forwarding 1 5 Base station 4 2 7 6 3
Response Tree • Based on queries the tree is formed dynamically • Each mote remembers its parent for a fixed amount of time. • It updates its parents as newer queries come. • Thus if a parent or link dies, the tree is still stable
Tree formation 1 5 Base station 4 2 7 6 3
Tree formation(dynamic) 1 5 Base station 4 2 7 6 3
Caching • Each mote has a cache, that store the responses received from other motes. • Motes close to base station (root) may need larger cache. • Cache are fixed size, so it wraps around and overwrites.
Caching 1 5 Base station 4 2 7 6 3
Solution • Wireless Sensor Network Manager • Packets are designed to never exceed a MTU • Efficient encoding of data • End to End retransmission request / Per Hop backups • ACKS would double necessary radio use • Node can remember last several responses • Human can wait a second • To find query we do inexpensive bit & • Same interface to query any component
Simulations • We created loss files for tossim to observe out algorithm work in a realistic setting • We created multiple topologies to see how performance will be effected. • We present readings made on 2 topologies for comparison.
Ideal Tree 0 1 2 3 4 5 6 14 7 8 9 10 11 12 13 15 16 17 18 19
The Real World is more Evil Black: 0% loss Blue: 5% loss Red: 10%loss
Results Time to receive manger query response (in milliseconds):
Time versus num_hops • Time for the response increased with number of hops. • Cached results were returned faster.
Observations • We can see caching: We send the same query [with same sequence number], the cached value returned faster. • Query node 16 • Try #1: (no cached value) 1104, 1210 ms • Try #2: (retreiving cached value) 131, 130 ms
Conclusion • Caching showed clear benefits when there are losses, especially close to the root of the tree. • Also Latency is reduced. • Tree is dynamic, so it adapts to losses. • Queries represented as bit string. So overhead is minimal. • High loss rates resulted in lots of timeouts.
