1. Ajay Vyasapeetam Brijesh Shetty Karol Gryczynski
WSNM
Ajay Vyasapeetam
Brijesh Shetty
Karol Gryczynski

2. 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.

3. 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

4. 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.

5. Query Forwarding 1 5
Base
station 4 2 7 6 3

6. 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

7. Tree formation 1 5
Base
station 4 2 7 6 3

8. Tree formation(dynamic)1 5
Base
station 4 2 7 6 3

9. 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.

10. Caching 1 5
Base
station 4 2 7 6 3

11. 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

12. State Diagram

13. Zoomed in on Manager

14. 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.

15. Ideal Tree 1 2 3 4 5 6 14 7 8 9 10 11 12 13 15 16 17 18 19

16. The Real World is more Evil
Black: 0% loss
Blue: 5% loss
Red: 10%loss

17. Results Node# (as in tree) Ideal Example Evil Example 1 146 149 2 148
Time to receive manger query response (in milliseconds):
Node# (as in tree)
Ideal Example
Evil Example 1
146
149 2
148
151 4
660 10
1140
131[80 cache] 12
1010
3TO+521 [130] 15
1190
Poor 17
1160 19
1297

18. Time versus num_hops
Time for the response increased with number of hops.
Cached results were returned faster.

19. 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) , 1210 ms
Try #2: (retreiving cached value) 131, 130 ms

20. 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.

21. Questions!

22. Thank you 