Monitoring wireless sensor network nodes with a low intrusion hybrid monitor

UNIVERSITY POLYTECHNIC OF VALENCIA MASTER DEGREE ON COMPUTER ENGINEERING MASTER FINAL WORK MONITORING WIRELESS SENSOR NETWORK NODES WITH A LOW INTRUSION HYBRID MONITOR Author: Marlon Renné Navia Mendoza Tutors: José Carlos Campelo, Alberto Bonastre Pina Valencia, February 2015 To my family, my support and encouragement. - 2 - Contents Abstract.........................................................................................................................4 1. Introduction...............................................................................................................5 2. Objectives and Justification......................................................................................7 3. Monitoring Tools......................................................................................................8 3.1 Active Monitors..................................................................................................8 3.2 Passive Monitors.................................................................................................9 3.1 Others Monitors Purposes.................................................................................10 4. The Low Intrusion Active Hybrid Monitor.............................................................12 4.1. Architecture of the Monitor.............................................................................12 4.2. Monitor Operation...........................................................................................15 4.3. Monitor Implementation..................................................................................18 5. Evaluation and Results............................................................................................22 5.1. Intrusion on Time.............................................................................................22 5.2. Intrusion on Code.............................................................................................24 5.3. Intrusion on Power Consumption....................................................................25 5.4. Frequency for Event Log Generation..............................................................26 6. Discussion...............................................................................................................28 7. Conclusions.............................................................................................................31 8. Future Work............................................................................................................32 References...................................................................................................................33 - 3 - Abstract Several systems have been proposed to monitor sensor networks— specially Wireless Sensor Networks (WSN)—in order to debug and analyze their operation. These systems are based on hardware and/or software technology, and can be active or passive. Each one of them has pros and cons, but none is complete at all. Active monitors generate a lot of intrusion, passive ones do not collect all relevant information about nodes, and most proposals are far away from real systems or are too hardware dependent. This work presents an active hybrid monitor with low intrusion, to be applied on sensor network nodes, which overcomes most of these drawbacks. Monitor is based in a new purposed open architecture for Monitoring Platforms which provides flexibility, universality, and reutilization. Intrusion caused to the sensor node has been evaluated on three aspects: time, additional code, and power consumption. Low intrusion has been achieved in all three issues. We have evaluated interfaces different from traditional serial transmission proposed by most of similar approaches. It has been proved that the use of parallel interface or Serial Peripheral Interface (SPI) allows a higher frequency of event log generation and low intrusion. Keywords: Monitoring, hybrid monitor, low intrusion, sensor networks. - 4 - 1. Introduction Sensor networks have undergone great research and development in recent years. However their massive deployment has not been too great because sensors networks may experience problems or errors in their operation. Many causes can be identified, such as interferences in the transmission medium, security attacks (especially in WSN [1]), adverse environmental conditions, malfunctioning nodes, and others. The node faults, their sources, and detection approaches are diverse, as it is detailed in [2]. Although during development or implementation of this type of network debugging and operation testing is usually made, when sensors are deployed the conditions can be very different and usually unanticipated events arise. The availability of a suitable sensor network failure diagnostic tool is a key issue in progressing to real-world deployment of WSN. Nowadays there are no standard tools or standard architectures in this area. Most of proposals in monitoring and debugging do not consider enough aspects of sensor networks to be fully useful, or are built for very specific network architectures. There are many challenges in several aspects—architectural, functional, and dynamic—that have to be researched according to [3]. The so called monitoring systems—or simply monitors—are used to evaluate the performance and operation of a sensor network, in controlled conditions or even in a real environment. Monitors can focus on many performance parameters, such as throughput, jitter, response time or reliability, and even to security and intrusion detection in the network, as described in [4]. Monitors usually are built based on one of two possible approaches. Active monitors involve additional hardware and/or software in sensor nodes, interacting with it. In this way, active monitors usually require the modification of the sensor nodes to be monitored. This interferes with its normal operation and measured parameters may vary from unmonitored node. However, the obtained data are more reliable. - 5 - On the other hand, passive monitors rely on the observation of the external behavior of the monitored system without any interference with its normal operation. Usually, behavior algorithms are used to evaluate the presence of errors, undesirable operation or unexpected events. No incidence on monitored nodes performance is caused, but only externally observable variables can be measured. Besides there is another approach for monitors depending if they are based on hardware or software. A software monitor is implemented by means of a specific code, application, or plug-in to the operating system of node, which access to the system status and reports relevant information. Usually, a software monitor has deep information about the system functioning, but it may interfere with the operation of the monitored system. A hardware monitor consists on electronic devices connected to the monitored system, which recollect data from interesting system points. Hardware monitors use to be less intrusive than software monitors, but they implies the use of additional components. Each monitor approach by itself cannot cover all aspects of monitoring tasks, as we will study in the next section. Monitors can also combine both approaches in order to achieve the advantages of both types and obtain a complete vision of the system, trying to keep the interference to the minimum. These are the so called Hybrid monitors [5]. In this work an active hybrid monitor with very low intrusion—based on both hardware and software monitoring methods—is presented. This monitor can record the events which occur in a node of a sensor network and store them in a non-volatile memory for later analysis. Moreover it is capable of being incorporated as a part of a complete monitoring platform that includes other acquisition possibilities, such as passive monitors, as described in [6]. - 6 - 2. Objectives and Justification The main goal is to build a monitor system that lets to combine the advantages of both types of monitors in a single monitoring platform able to monitor the complete system. The hybrid monitor is going to work in a standardized way, by using of standard interfaces and available libraries, but with low intrusion on sensor network nodes. This monitor system allows to register the events and behavior of sensor network nodes, as well as to reconstruct the activity of the network. The generated information can be further analyzed by adequate tools. The architecture used for hybrid monitor development wants to become a standard for monitoring platforms, and allows to monitor provides flexibility, universality, and reutilization. - 7 - 3. Monitoring Tools There are several tools and techniques for monitoring sensor networks, most of them with one approach, and mainly focused to WSN. In [3], an overview and comparison of most of proposed tools are made, not only monitoring tools but also debugging ones. In this section a brief summary of some of the most important and relevant is done. 3.1 Active Monitors SNMS (Sensor Network Management System) [7] is one of the first and best known monitoring systems. SNMS is a complete management system, focused on working with any type of sensor network. It is built on TinyOS—an open source operative system designed for low-power devices [8]—and allows a review of the state of a node and even save information locally. Nevertheless, it generates substantial intrusion—it increases traffic and power consumption—and is oriented rather to management that monitoring. Memento [9] and Lightweight Tracing [10] are both examples of active monitors. Both use short encoding with events and information of sensor node. The first one adds its code protocol to a message that is going to be transmitted by node. Memento can detect problems in a node by basing on the information provided by their neighbors in the sensor network; but for detecting new kinds of failures it requires node reprogramming. In Lightweight Tracing [10] the events are saved by using a very light coding in non-volatile memory for further reconstruction and debugging of node and network behavior. Because both are active monitors, they generate substantial intrusion in nodes operation. Despite its name, Passive Diagnosis for WSN (PAD) [11] is an active monitor system with little intrusion. It is based in a probabilistic diagnosis approach—based on a Belief (or Bayesian) Network—to infer the root causes of abnormal WSN - 8 - operation. This adds a probe in each node that marks the packets with relevant data with very little overhead. . However, PAD has to wait a message transmission to send information and it might not determine when an error has happened. Besides, as far as non-sense nodes, such as router nodes, do not send sensed data, they are not able to send any monitor information to infer possible abnormal operation. 3.2 Passive Monitors Sympathy [12] works as a passive monitor, and can detect and debug pre-and-post deployment errors. It operates by analyzing the data arriving at the sink of a sensor network, applying metrics, and inferring where in the network a fault or failure can be produced. The implementation of this mechanism depends on the knowledge of the network behavior. It also considers the aggregation of a small overhead on the network to increase its accuracy. However, it was not developed for event-driven applications, losing some important information and reducing its accuracy. SNIF (Sensor Network Inspection Framework) [13], Pimoto [14], LiveNet [15], SNDS (Sensor Network Distributed Sniffer) [16], NSSN [17], and EPMOSt (Energyefficient Passive Monitoring SysTem for WSN) [18] are examples of passive monitors. Their approach consist on deploying a network of sniffers—together with the target sensor network—with an interface to capture all transmissions from nodes. The main difference between them is how the captured data is processed. SNIF [13] and Pimoto [14] transmit—via a Bluetooth interface—the captured data to other device in order to process it. In the first case the device that receives the packets—tagged with a timestamp—works as a sink and analyzes information. The analysis tool has been developed by the authors. In Pimoto the device that receives the data—called gateway—is a computer that tag the packets with a timestamp and forwards it, via TCP/IP, to a central server for analysis. Pimoto can also works over more than one sensor network simultaneously. It has a plugin for Wireshark [19]—a traffic analysis tool—in order to analysis data. However, Pimoto may not be practical for monitoring WSN that has too many nodes widely distributed, because it needs more infrastructures. - 9 - shows a scheme of monitor operation. A signal—with information of the event—is sent from sensor node to monitor node when a relevant event—that we want to register—occurs. Figure 4. Hybrid monitor operation scheme. The operation time of the monitor has to be simple in order to reduce the intrusion in the network nodes. Figure 5 shows the data flow and operation of hybrid monitor. Figure 5. Flowchart of hybrid monitor operation. - 16 - Specific functions have been defined to register node events, and they are included in the node. There are two functions added to sensor network node: One can be located where log information required, and the other is activated by an interruption when the ACK is received. When sensor node reaches a software trap, it invokes the Start Send Function in order to make relevant data (contained in TXData[ ] structure) to be sent to the monitor node. This function prepares the data to be transmitted, and then it sends the first part of data to the monitor node, and activates a flag that indicates a transmission process. Then the function returns the control to the main node application. The data sent to the monitor may include additional information with the event code. The way to obtain the additional data depends of the sensor node. This possibility allows increasing the accuracy of obtained information. For example, a log of an error event with an additional code that describes the kind of error may be obtained. It is also possible, when dealing worth retransmission events, to add to the trap part or the entire message, in order to differentiate between messages. Finally, it is also possible add a code to indicate the reason of the wakes up of the node. This is a significant improvement in comparison with other proposals that only register events but cannot handle additional information about them. The monitor node is always waiting for information sent from the sensor node. When data from sensor node is received, monitor node stores it with the appropriated timestamp. This timestamp has to be generated in case of a new event log. Then an ACK message is sent to the sensor node. When the sensor network node receives the ACK the next part of information may be sent if necessary; or transmission flag may be deactivated. This mechanism can be considered semi-blocker and reduces the intrusion for the sensor node. The events are coded in 4 bits. These codes have already been defined earlier in [22] and are shown in Table 1, although this definition can be modified or increased, in order to enhance the accuracy. - 17 - Monitor node stores information with a predefined format. This format includes the timestamp, the log code, and additional information if apply; and it must be easy to analyze with an adequate application. Table 1. Event codes defined by authors in [22]. Code Meaning #define Log_Reset 0x00 //Node Reset/Initialization #define Log_Sense0 0x01 //Read sensor 0 (first/unique) #define Log_Sense1 0x02 //Read sensor 1 (second if it’s) #define Log_Sense2 0x03 //Read sensor 2 (third if it’s) #define Log_Wakeup 0x04 //Wake up from sleep/stop #define Log_RxData 0x05 //Node receives data #define Log_TxData 0x06 //Node sends data #define Log_RxACK 0x07 //Node receives ACK #define Log_RRoute 0x08 //Node reroutes data (if apply) #define Log_Sleep 0x09 //Node goes to sleep mode #define Log_Stop 0x0A //Node goes to stop mode #define Log_LowBat 0x0B //Low battery indication #define Log_SinkRx 0x0C //Sink receives data #define Log_SinkTx 0x0D //Sink sends data #define Log_SinkEr 0x0E //Error in sink #define Log_Error 0x0F //Error in node 4.3. Monitor Implementation The monitor node has been developed on a STM32F051R8T6 ARM Cortex-M0 microcontroller (MCU) [25] implemented on a STM32F0 Discovery Board [26]. This microcontroller is a 32-bits core high performance MCU, and it has these main features: ARM Cortex-M0 core up to 48MHz. Memory: 64KB of flash memory, 8KB of RAM. Several GPIO (General Purpose Input-Output) ports. Connectivity: USART (Universal Synchronous Asynchronous ReceiverTransmitter), SPI, I2C. Control: 3-phase PWM (Pulse-Width Modulation) control timer, PWM timers, basic timer, comparators. - 18 - Real Time Clock onboard or externally supplied. Digital-Analog and Analog-Digital converters. The monitor board has been connected to a SD card through its SPI interface. Figure 6 shows the implementation of the hybrid monitor. The monitor node—at left side—is connected to a sensor node—at right side—that is used for testing. It has attached the SD card used to store data. In case of Figure 6 the SPI interface is also used to connect the monitor node to the sensor node. Figure 6. Picture of a sensor node connected to the monitor node. In order to evaluate the most appropriate communications interface between sensor node and monitor node, three different interfaces implementation—usually found in most of microcontrollers—have been used: SPI, USART, and finally parallel transmission, using 16 GPIO ports. Parallel and SPI data width is 16 bits, and USART data width is 8 bits. Besides, three transmission speeds were evaluated for SPI interface. To compare the performance of each interface, four sizes of transmitted data (common sizes of 16, 32, 64, and 128 bits per trap) have been assumed. . The bigger the data being transmitted, more detailed the information provided in each trap, but higher the interference. A library should be added to the code implementation on sensor node with the instruction sets for initialization and data transmission. As far as the ARM - 19 - architecture may be the most used in sensor node implementation, and in order to provide a standardized level CMSIS (Cortex Microcontroller Software Interface Standard) has been used to create this library. CMSIS is a vendor-independent hardware abstraction layer and can be used on many microcontrollers [27]. This library can be adapted easily for others architectures with the correspondent instructions. As far as the messages sent through the interface between sensor node and monitor node (SPI, USART or Parallel) are the same that previously cited ones, monitor node needs no modification. For evaluation of the monitor node a sensor node based in an ARM Cortex-M0 at 48MHz was used. Every time this sensor node wakes up from sleep mode, it takes a measurement from a temperature sensor, transmits the measurement via wireless, and turns back to sleep mode for 60 seconds again. Traps have been inserted in the program of the sensor node to register three kinds of events: wake up, transmission, and sleep. These codes are sent to the monitor node, which reflects them into ASCII text separated by commas, and stores these data and its timestamp in a SD card. Figure 7 shows part of the information generated by the hybrid monitor and recovered from this SD card. Figure 7. Information recovered from the SD card attached to the monitor node. In case of Figure 7 information includes date, time, microseconds, event code, and additional data. Event codes 04, 06 and 09 (Table 1) have been used for wake up, - 20 - transmission and sleep events, respectively. Additional values for wake up and transmission events—also sent as additional information—indicate the iteration number. All this data can be delivered to the visualization and control subsystem (Figure 1) by using the information layer services. - 21 - 5. Evaluation and Results In order to evaluate the characteristics of the proposed monitor, intrusion analysis is required. Three are the main intrusion aspects that must be considered. Time intrusion deals with the increment of execution time on sensor node caused by the monitor. Taking into account that sensor nodes use to be limited in RAM memory, Code intrusion evaluates how many bytes have to been added to source program of this sensor node. Finally, Power intrusion evaluates the amount of energy that this monitoring technique requires from the sensor node, and thus reducing its battery life. Several experiments have been performed, considering the previously cited interfaces and data sizes, to measure the intrusion of the active hybrid monitor. Obtained results are shown in this section. 5.1. Intrusion on Time Time intrusion was determined by measuring the amount of time needed to fulfill one thousand wake-up iterations in the sensor node without traps (reference time), and then measuring when traps were added. Three interface implementations and four data sizes were combined to provide the table 2. This table shows the difference between the obtained time and the reference time, and thus the time intrusion. Table 2. Intrusion on time for each log event with different interfaces and data sizes (microseconds). Data Size Parallel (16bits) SPI 18mbps SPI 4.5mbps SPI 2.25mbps USART 115.2kHz 16bits 3.80 3.10 3.10 3.20 6.20 32bits 7.30 6.10 6.20 6.20 13.60 64bits 16.50 13.00 13.10 13.10 28.80 128bits 31.90 28.10 28.10 28.20 60.60 As shown, the intrusion time is similar for different interfaces with the same data size, due to the implementation of the monitor code in the sensor node: As far as data transmission through the interface is performed by specific hardware (SPI controller, USART, others), trap routines only write the outgoing data into the interface buffers - 22 - and the sensor node program may continue. These hardware controllers take care of transmission in parallel to this program execution. Parallel interface has no dedicated hardware controller. That is the reason that the time is little bigger than the others. An additional line is used to generate the transmission interruption in the monitor node. As expected, intrusion time increases for larger data sizes. However, values in Table 2 cannot be used as a reference to know the maximum frequency for the event log generation, because it depends on the peripheral using time (communication hardware) and the monitor node hardware. Besides, the times of Table 2 are a sum of non-continue values. Time limitations on SPI controller, USART and parallel ports must also be considered. In case of USART the intrusion time is about double because it only sends 8 bits per transmission and it has to manage twice of interruptions. The processing time in the monitor node was measured too. Each event log has to be processed in one or more data reception interruption, according to data size transmitted from sensor node. The processing time is considered from the arrival of the first data to the receiving of the last piece of information. The timestamp generation takes 15.8 microseconds, and is done when the first piece of data arrives. Table 3 shows the obtained values. Table 3. Processing time in monitor node for each event log (microseconds). Data Size Parallel (16bits) SPI 18mbps SPI 4.5mbps SPI 2.25mbps USART 115.2kHz 16bits 17.80 17.40 17.40 17.40 88.40 32bits 22.90 23.40 25.40 27.80 262.00 64bits 32.90 34.40 40.10 48.20 612.00 128bits 52.80 56.20 69.80 88.00 1300.00 As shown in Table 3, when dealing with 16 bits events the obtained times are similar for every interface, as far as process time depends mainly on timestamp generation. For larger data size the processing time is a bit less when using parallel interface instead of SPI, especially when the SPI speed is low. - 23 - In the case of the USART interface, the processing time is very larger, because its low transmission speed and the fact that it only can send 8 bits at a time, whereas other considered options can send 16 bits at a time. As expected, the processing time increases for larger data sizes. Should be noted, values of Tables 2 and 3 may change in some cases. A monitor node based on a faster microcontroller will reduce the timestamp generation time, hence will reduce the processing time and increase the performance. Besides, the time intrusion and processing time could change depending of sensor network node characteristics, such as core frequency, availability of buffers, architecture, interface to monitor, and others. USART interface has not been considered as an option to be used in our monitor because of its low speed and high processing time—compared with the others interfaces—, which results in low performance. Thus it is not considered in further results. 5.2. Intrusion on Code As far as memory resources are limited for sensor nodes, the evaluation of the intrusion on program code is relevant. Code used in the sensor node was generated by Keil MDK (Microcontroller Development Kit) version 5, a comprehensive software development environment for Cortex-M processor based microcontrollers that includes IDE (Integrated Development Environment), Compiler, and Debugger [28]. Size difference in bytes has been considered between the pure application code and the trap-modified code, in binary compiled program. Main differences between both codes consist on the addition of the port initialization subroutine and several data transmission instructions. Table 4 shows the intrusion in bytes on program code in sensor node. As expected, intrusion is not related to the communication speed, thus this parameter has not been considered. Since transmission code is reused for all the traps, a new event may be monitored by just adding to the code of the sensor node a trap call of 8 bytes. - 24 - Table 4. Intrusion on Code: Initialization and one event log (Bytes). Interface 16bits 32bits 64bits 128bits Parallel 228 252 268 276 SPI 428 452 468 476 Code intrusion (SIntrusion) may be predicted by means of the Equation (1), where Sinit is the initialization value appearing in Table 4, and n is the number of trap calls included in the application code. As expected, for a small number of traps monitored, the code intrusion is mostly determined by the initialization code. SIntrusion=Sinit +8× ( n−1 ) (1) 5.3. Intrusion on Power Consumption Taking into account that sensor nodes usually are powered with batteries or harvesting techniques, power consumption is a key aspect in sensor network nodes. Due the working time is very low—some milliseconds as maximum—power consumption was determined by modifying the application program of the sensor node, avoiding sleep mode and keeping used peripherals enabled. About 7000 samples of sensor node electrical power were taken—18 samples per second—and averaged them. Measurements were taken with an Agilent 34405A Multimeter. This multimeter has a 5.5 digit resolution, with an accuracy of ±(0.05% of reading + 0.015% of range) for our measuring conditions [29]. The obtained results showed that the instantaneous power consumption was the same for all the evaluated communication speeds. Data size was also found to be irrelevant in power consumption. The sensor node electrical current required in clear operation, without monitoring, was found to be 53.4 mA. The total electrical current required when monitoring was performed through each interface and the differences with normal operation are shown in Table 5. - 25 - 8. Future Work Adding the monitor to a passive monitoring system—e.g. a sniffers network like mentioned proposed above—can result in a complete monitoring system that can observe the whole network behavior. Hence, a future work that integrates the active monitor to a passive monitoring network (sniffers) should be developed. For a faster analysis of log data captured by the monitor, a radio interface can be added to the monitor node to transfer the data from memory card to a host. This host can be the same device that works as sniffer. The format of stored data—in the information layer—can be standardized, so it can comply with the main goal of purposed architecture in which the hybrid monitor is based. A practical and easy way to do it is to use an existing standard format or adapt it to this purpose. A model to determinate intrusion is necessary. The considered intrusion aspects of this model must be at least the three covered in this work. The model should define levels and thresholds of intrusion, as well as formulas to calculate these ones. A Program for collected data analysis must be developed. This program can be a plugin for be used with any known network traffic analyzer—e.g. Wireshark—or a new application developed for this goal. - 32 - References 1. Patel, M.; Aggarwal, A. Security Attacks in Wireless Sensor Networks: A Survey. In Proceedings of the IEEE International Conference on Intelligent Systems and Signal Processing (ISSP), Anand, India, 1–2 March 2013; pp. 329– 333. 2. Mahapatro, A.; Khilar, P.M. Fault Diagnosis in Wireless Sensor Networks: A Survey. Communications Surverys & Tutorials, 2013, Vol. 15, No. 4, pp 2000– 2026. 3. Rodrigues, A.; Camilo, T.; Silva, J.S.; Boavida, F. Diagnostic Tools for Wireless Sensor Networks: A Comparative Survey. Journal of Network and Systems Management, 2012, Vol. 21 Iss. 3, pp. 408–452. 4. Rachedi, A. Monitoring Mechanism for Wireless Sensor Networks: Challenges and Solutions. In Wireless Sensor Networks, El Emary, I,; Ramakrishan, S., Eds; CRC Press: Boca Raton, FL, USA, 2013; pp. 595–621. 5. Schoofs, A.; O'Hare, G.M.P.; Ruzzelli, A.G. Debugging Low-Power and Lossy Wireless Networks: A Survey. IEEE Communications Surveys & Tutorials, 2012, Vol. 14, No. 2, pp. 311–321. 6. Piqueras, I.; Campelo, J. C.; Ors, R.; Serrano, J. J. Hybrid monitoring of wireless sensor networks. In Proceedings of the IEEE International Conference on Wireless Information Technology and Systems (ICWITS), Maui, Hl, USA, 11–16 November 2012; pp. 1–4. 7. Tolle, G.; Culler, D. Design of an Application-Cooperative Management System for Wireless Sensor Networks. In Proceedings of 2nd European Workshop on Wireless Sensor Networks (EWSN), Istanbul, Turkey, 31 Jan. –2 February 2005; pp. 121–132. 8. FAQ – TinyOS Wiki. Available online: http://tinyos.stanford.edu/tinyoswiki/index.php/FAQ (accessed on 15 December 2014). 9. Rost, S.; Balakrishnan, H. Memento: A Health Monitoring System for Wireless Sensor Networks. In Proceedings of 3rd Annual IEEE Communications Society on Sensor and Ad Hoc Communications and Networks (SECON), Reston, VA, USA, 25–28 September 2006; Vol. 2, pp. 575–584. 10. Sundaram, V.; Eugster, P.; Zhang, X. Lightweight tracing for wireless sensor networks debugging. In Proceedings of the 4th International Workshop on Middleware Tools, Services and Run-Time Support for Sensor Networks (MidSens 09), Urbana Champaign, Il, USA, 30 Nov. – 4 December 2009; pp. 13–18. - 33 - 11. Liu, Y.; Liu, K.; Li, M. Passive Diagnostics for Wireless Sensor Networks. IEEE/ACM Transactions on Networking, 2010, Vol. 18, No. 4; pp. 1132–1144. 12. Ramanathan, N.; Chang, K.; Kapur, R.; Girod, L.; Kohler, E.; Estrin, D. Sympathy for the Sensor Network Debugger. In Proceedings of 3rd ACM Conference on Embedded Networked Sensor Systems (ACM SenSys 2005), San Diego, CA, USA, 2–4 November 2005; pp. 255–267. 13. Ringwald, M.; Römer, K.; Vialetti, A. SNIF: Sensor Network Inspection Framework. Department of Computer Science, ETH Zurich, Technical Report No. 535; 2006. 14. Awad, A.; Nebel, R.; German, R.; Dressler, F. On the Need for Passive Monitoring in Sensor Networks. In Proceedings of 2008 11th EUROMICRO - Conference on Digital System Design Architectures, Methods and Tools (DSD); Parma, Italy, 3–5 September 2008; pp. 693–699. 15. Chen, B.; Peterson, G.; Mainland, G.; Welsh, M. LiveNet: Using Passive Monitoring to Reconstruct Sensor Network Dynamics. In Proceedings of IEEE Conference on Distributed Computing in Sensor Systems (DCOSS), Santorini Island, Greece, 11–14 June 2008; pp. 79–98. 16. Kuang, X,; Shen, J. SNDS: A Distributed Monitoring and Protocol Analysis System for Wireless Sensor Network. In Proceedings of 2010 Second International Conference on Networks Security, Wireless Communication and Trusted Computing (NSWCTC), Wuhan, China, 24–25 April 2010; pp. 422– 425. 17. Zhonghua, Z.; Huangfu, W.; Linmin, S. NSSN: A Network Monitoring and Packet Sniffing Tool for Wireless Sensor Networks. In Proceedings of 8th International Wireless Communications and Mobile Computing Conference (IWCMC), Limassol, Cyprus, 27–31 August 2012; pp. 537–542. 18. Garcia, F.; Andrade, R.; Oliveira, C.; de Souza J.N. EPMOSt: And EnergyEfficient Passive Monitoring System for Wireless Sensor Networks. Sensors, 2014, 14, pp. 10804–10828. 19. Wireshark. Available online: https://www.wireshark.org/ (accessed on 20 January 2015) 20. Sommer, P.; Kusy, B. Minerva: Distributed Tracing and Debugging in Wireless Sensor Networks. In Proceedings of the 11th ACM Conference on Embedded Networked Sensor Systems (SenSys), Rome, Italy, 11–14 November 2013. 21. Hossain, M.S.; Lee, W.S.; Raghunathan, V. Spi-Nooper: A Hardware-Software Approach for Transparent Network Monitoring in Wireless Sensor Networks. In Proceedings of the 8th IEEE/ACM/IFIP International Conference on Hardware/Software Codesign and Systems Synthesis (CODES+ISSS), Tampere, Finland, 7–12 October 2012; pp. 53–62. - 34 - 22. Navia, M.; Campelo, J.C.; Bonastre, A.; Serrano, J.J. Low Intrusion Active Hybrid Monitor for Nodes of Sensor Networks. In Proceedings of Workshop on Innovation on Information and Communication Technologies (ITACA-WIICT), Valencia, Spain, 4 July 2014; pp. 111–120. 23. Capella, J.V.; Campelo, J.C.; Bonastre, A.; Ors, R. Proposal of a Reference Model for WSN’s Monitoring Platforms. Journal of Network and Computer Applications. Received (under revision.) 24. ISO/IEC. Information Technology – Open Systems Interconnection – Basic Reference Model. International Standard ISO/IEC 7498-1, second edition, 1994. 25. STM32F051R8 ARM Cortex-M0 MCU. Available online: http://www.st.com/web/catalog/mmc/ (accessed on 2 December 2014). 26. STM32F0DISCOVERY Discovery Kit for STM32F051. Available online: http://www.st.com/web/catalog/tools/FM116/SC959/SS1532/PF253215 (accessed on 20 January 2015) 27. CMSIS - Cortex Microcontroller Software Interface Standard. Available online: http://www.arm.com/products/processors/cortex-m/cortex-microcontrollersoftware-interface-standard.php (accessed on 8 December 2014). 28. Keil MDK-ARM Version 5. Available online: http://www2.keil.com/mdk5/ (accessed on 10 January 2015). 29. 34405A Digital Multimeter, 5½ digit | Keysight (Agilent). Available online: http://www.keysight.com/en/pd-686884-pn-34405A/ (accessed on 10 January 2015). 30. Gharghan, S.; Nordin, R.; Ismail, M. Energy-Efficient ZigBee-Based Wireless Sensor Network for Track Bicycle Performance Monitoring. Sensors, 2014, 14, pp. 15573–15592. 31. Molina-Garcia, A.; Fuentes, J.A.; Gómez-Lázaro, E.; Bonastre, A.; Campelo, J.C.; Serrano, J.J. Development and Assessment of a Wireless Sensor and Actuator Network for Heating and Cooling Loads. IEEE Transactions on Smart Grid, 2012, Vol. 3 No. 3, pp. 1992-1202. 32. Lee, D.S.; Liu, Y.H.; Ling, C.R. A Wireless Sensor Enabled by Wireless Power. Sensors, 2012, 12, pp. 16116–16143. - 35 -