Real Time Monitoring of Wireless Sensor Networks

1. Real Time Monitoring of Wireless Sensor Networks Kaushal Mehta 993940184

2. Motivation • A large class of wireless sensor networks are designed and used for monitoring and surveillance. • The single most important mechanism underlying such systems is the monitoring of the network itself, that is, the control center needs to be constantly made aware of the existence/health of all the sensors in the network. • Sensor motes are unreliable small devices with limited energy supply, and sensors may run out of power or fail over time. • Hence monitoring of sensor motes status, link status and power status of network is of absolute relevance.

3. Monitoring Parameters • Link Quality. • We are trying to estimate the link quality. • Predict if link has failed completely (cannot transfer even a single packet). • Mote Status. • We are trying to predict node failure. • Power Status. • We are trying to estimate the lifetime of the sensor mote.

4. Components of the System • Monitor • Helper

5. Integration with Ayushman

6. Assumptions of the System • The ‘monitor’ is capable of receiving the messages sent from the sensor mote to stargate. Thus, enabling the system to work unobtrusively of the existing system. • The ‘monitor’ is placed very near to the stargate, so that we can assume that the link between stargate and sensor mote is same as that of ‘monitor’ and sensor mote. • Each sensor mote is assigned a unique ID to identify them. • The sensor motes are each assigned a frequency ‘f’ to communicate with the stargate device. But they will have different transmit times so that their messages do not collide. • Each sensor mote is transmitting the sensor reading periodically with frequency ‘f’. • Real-time means that we would provide the correct system status within reasonable time after the event has occurred. • Battery has linear characteristic.

7. Why Link Quality ? • We are dealing with medical data, thus communicating sensor data to stargate in correct form, without any loss is necessary. • Wireless links are unreliable. • Many more…….. Ways to self-heal the link suffering for low quality • We could dynamically change the route of the node, thereby avoiding a weak link.

8. Link Quality Monitoring Link Quality = Actual No. of Transmission Expected No. of Transmission Sensor Mote Thus, Link Quality = 5 5 Link Quality = 1 Thus, Link Quality = 4 5 Link Quality = .8 Monitor

9. Why Mote Status ? • Ayushman is designed as a health care system. • The sensor motes are placed at important locations in the body that require continuous monitoring. Some may even be embedded in the body (maybe in future). • Failure of any mote can be disastrous and can lead to fatal damage. Eg. Failure of heart beat rate sensor mote. • Thus, continuous real time monitoring of mote is necessary.

10. Mote Status Monitoring • Monitoring node status in real time is not possible. • So, we are bound to have some delay in predicting node failure. • Predicting node failure in real time may lead to error because • When node does not seem to be responding, there are chances that link might have failed for that particular transmission. • So, its not possible to predict in real time, whether it was node failure or link failure. • So, we assume that there will be some delay in predicting node failure. • Steps to be taken to predict node failure • If the ‘monitor’ does not receive packet for 3 continuous clock period, we start to investigate about the possibility of node failure. • Step 1 : ‘Monitor’ sends a broadcast packet to the node This packet will instruct the node to change its route to ‘monitor’, via some intermediate node. So, now the node will send the data to the monitor in 2 hops. • Step 2 : Node will now send the packet via the intermediate node to the monitor. • Step 3 : Still if the ‘monitor’ does not receive the packet from the node, the system will repeat the Step 1 to Step 3 for 2 more times before announcing the failure of the node.

11. Mote Status Monitoring Sensor Mote 1 Sensor Mote 2 Route via 1 Since, monitor receives packet via Sensor 1, there is problem with link and mote has not failed. If, this message would not have received, we would have concluded that mote has failed. Count : 1 Count : 2 Count : 3 Monitor

12. Power Status • Estimation of battery life. • Very difficult problem. • Many factors like temperature, humidity, non-linear characteristics of the battery, etc affect the life of the battery. • Presence of threshold level, below which battery fails immediately. Usually 1.8V for mica2 motes. MICA2 AA Battery Pack Service Life Test

13. Power Status From Mica2 Data sheet

14. Power Status

15. Power Status • Calculating mA-hr • We are taking into consideration the current drawn from the following • Processor • Radio • Sensor Board • Since we are not using Logger Memory, we are not taking it into consideration. • As recently published by Crossbow • Processor requires 8mA current in full operation mode and 8uA current in sleep mode • Radio requires 8mA current in receive mode, 12mA in transmit mode (assuming) and 2uA in sleep mode. • Sensor board requires 5mA in full operation mode and 5uA in sleep mode. • These details are found in the data sheet. • Assuming a sample application with duty cycle 1:99 (awake : sleep) • Processor would consume 0.0879 mA-hr • Radio would consume 0.0920 mA-hr • Sensor board would consume 0.055 mA-hr • Thus, total current (mA-hr) used is 0.2349 mA-hr

16. Power Status • Thus, knowing the capacity of the battery, we can estimate the lifetime of the mote. • Eg. Battery Capacity ( mA-hr ) Battery Life ( months ) 250 1.45 1000 5.78 3000 17.35 Problem with this approach Need to measure the current drawn accurately. Need to know the duty cycle accurately. • Test Results • We compared one sample application that had no sleep mode, • Using new set of batteries (3000mA-hr), we were able to run the application on mote for 5-6 days approximately in the impact lab. • Using the above method we were able to calculate 5.94 days as an approximate answer. (using 3000mA-hr as reference)

17. Current Status • Completed implementation of Link Quality Monitoring. • Completed implementation of Estimation of Battery Life. • Working on Node Status Monitoring.

18. Future Work • The monitoring systems needs to be tested in the real application environment. • Need to come up with some technique to predict node status in real time, with less delay in detection of node failure. • Fine tuning the battery estimation model to estimate the battery life as accurate as possible. • And a lot more……………

19. Thank You Questions ?

20. References • MPR-MIB Users Manual, Revision B, June 2006. PN: 7430-0021-07. • MICA2 AA Battery Pack Service Life Test, Crossbow. • A Factor Graph Approach to Link Loss Monitoring in Wireless Sensor Networks (2005) , Yongyi Mao, Frank R. Kschischang, Baochun Li, Subbarayan Pasupathy. • An Environment for Runtime Power Monitoring of Wireless Sensor Network Platforms, Proceedings of the 37th IEEE Southeastern Symposium on System Theory (SSST'05), Tuskegee, AL, March 2005, Aleksandar Milenkovic, Milena Milenkovic, Emil Jovanov, Dennis Hite, Dejan Raskovic. • Residual Energy Scan for Monitoring Sensor Networks (2002), Jerry Zhao, Ramesh Govindan, Deborah Estrin. • Efficient Tracing of Failed Nodes in Sensor Networks, ACM WSNA’02, Atlanta, GA, September 2002. J. Staddon, D. Balfanz, and G. Durfee,, pp. 122-130.