An Environmental Sensing Experiment Using IEEE 802.15.4 Radio Hop of the WSN TelosB Motes

Yusnaidi Md Yusof1, A.K.M. Muzahidul Islam2, Sabariah Baharun3,

Mohd Ghazali Hamza4, Kamarul Ariffin Abdul Basit5, Noor Azurati Ahmad6

1,2,3MJIIT, 1,6AIS, 4Razak School of Engineering Universiti Teknologi Malaysia (UTM)

Kuala Lumpur, Malaysia

{yusnaidi.kl, muzahidul, sabariahb, azurati}@utm.my ehkmohamed2@live.utm.my

5Faculty of Computer & Mathematical Sciences Universiti Teknologi MARA (UiTM)

Shah Alam, Malaysia

k_rol@fskm.uitm.edu.my

Abstract—Wireless Sensor Networks (WSN) is a key technology to the pervasive monitoring and wireless surveillance. As part of the Internet of Things (IoT) and the Wireless Embedded Internet, WSN has shown a significant contribution to the remote control and monitoring of the environmental condition such as temperature, humidity, light, and acceleration detection. A sensor node or mote is a tiny-scaled electronic device with very limited power, memory, and bandwidth capable to sense, process, and transmit environmental data to the remote observer. This paper demonstrates the experience explored and the observation of temperature sensing using the IEEE 802.15.4 information hopping from a sensing mote to the base station. The environmental readings are furthered reprocessed and displayed on the base station screen for analysis. The study outcome and the experience gathered from the experiment are important to help the researchers to incorporate the information display, with the use of Wireless Embedded Internet’s IPv6 and 6LoWPAN standard, to be globally accessible anywhere and at anytime.

Keywords—WSNs; WSN data gathering; WSN data sensing; wireless information processing

I. INTRODUCTION A Wireless Sensor Network (WS) is a group of

specialized autonomous sensor nodes with a communication infrastructure to monitor environmental conditions such as temperature, humidity, light, acceleration, vibration, etc. The sensor nodes work cooperatively and are usually kept at the place or area in which data is expected to be sensed for monitoring and tracking purposes. The collected data is then passed to nearby neighbor sensor nodes in the same network until it arrived at the base station. The base station will have the opportunity to view all collected data and later converted them into understandable information so the observer would use it to make monitoring or any other decisions [1], [2].

A common architecture of WSN consists of three components: (1) sensor nodes, (2) sink node or base station, (3) personal computer [3]. A sensor node (mote) is a node in a sensor network which has a capability to perform

processing, gathering sensory information as well as communicating with other connected nodes in the network. Among the main components of a sensor node are microcontroller, transceiver, memory, power source, and sensors [1]. The sensors in a sensor node is used to capture data from their environment. Many of the latest sensor node products implant the sensor chipset inside the sensor board itself. The sensor componets measure response to a change in a physical condition such as temperature or pressure. The captured data is communicated to a microcontroller component in the same sensor node for data processing. The microcontroller is able to process the data and controls the functionality of other components in the sensor node. The microcontroller are hardwired with the transceiver in the sensor board first to process and second to send the captured data to other neighboring sensor nodes [4], [5].

The sink node or also known as base station is a node responsibles to gather all sensed data coming from other nodes in the communication medium; and relay them to the observer whose can be located either local to the base station or at other remote area in which the connection has to go through the Internet [6], [7]. In a very naked understanding, the base station merely the same sensor node but with different functionality and is attached to the monitoring computer [2].

The personal computer to which the base station is attached to is the machine that used by the observer to monitor the sensing information coming from the base station. It can be located either locally to the sensing area or remotely at other location far from the sensing area where accessing this computer need an Internet connection. In a tsunami monitoring application for example, a bunch of thousand of thousands of sensor nodes are deployed in the deep ocean where the tsunami is predicted to originate. As the pressure level information are gathered about the the tsunami, these informations are wirelessly hopped-out from one node to another towards the base station. As the information reached the observer from the base station, an alarm action can be made to deal with the tsunami fenomena or threat. Other life-threatened events such as flight crash [8],[9],[10], habitat tracking [11],[12], healthcare monitoring

[13],[14], infrastructure monitoring [15],[16], and environmental monitoring [17],[18], to name a few, are all depends on how fast and how accurate the information can get to the human attention so the action can be made impromptu before the incidents happen. The above requirements are bigger required especially when human dealing with realtime data that need to be timely monitored [19].

As we can see the importance of the data capturing and monitoring, therefore the sensitivity of the captured data is at a paramount need. False translation and interpretation of data or unacceptable delay of data delivery at the observer site could threat human life in a bigger danger. The data gathered also need to pass to the observer at a faster rate (expecially when passing realtime data through the web) so the decision on the events can be made quicker.

This paper describes our works to demonstrate environmental data sensing and collection from autonomous sensor nodes and being readable with meaningful information on the observer screen.

The following sections describe the study in details. Section II defines standard and basic radio concept of data transmission in wireless sensor node. In Section III, we demonstrate the conducted experiment with results analysis. Finally, we envisage future works and some concluding remarks in Section IV.

II. IEEE 802.15.4 RADIO COMMUNICATION IEEE 802.15.4 is the IEEE radio protocol standard for the

communication of the ultra-low rate, ultra-low power consumption, and ultra-low bandwidth, and low cost devices and suitable for communication of sensor nodes in the WSN. It specifies the Medium Access Control (MAC) sublayer and physical layer for Low-Rate Wireless Private Area Networks (LR-WPAN) [20].

The features of low-cost, low-power of the IEEE 802.15.4 are intended to enable the promotion and deployment of WSN with the capability to live years on battery power together with mass deployment because of the very low cost of sensing devices [21]. The standard is optimized for low data throughput such as 250 kbps as in the low-bandwidth TelosB mote.

III. IMPLEMENTATION In this section we present the environmental data sensing

experiment using the IEEE 802.15.4 radio. The experiment is conducted in an office room of an eleven floor building.

A. Experiment Background The experiment is conducted in an office room equipped

with a standalone unit of air conditioner. The aim of the experiment is to sense the temperature of the room using the TelosB motes and monitor the reading at the screen of a computer where the base station is attached to.

The base station is installed with a TinyOS application which let the mote to relay any data coming from nearby

motes to the computer either using serial or radio transmission. The application is called Basetation and is made available by the TinyOS [22].

We develop an application using the TinyOS nesC codes to be used on the sensing mote. The application has several features to enable and aid the mote in making a sensing task such as sensing the temperature of the room, hopping the sensed data to the base station, led indicator to signal the environmental data are being collected, and also a simple analysis program to display the sensed data on the base station computer screen.

Apart from the above mentioned characteristics, we also make used of the internal TinyOS tools and programs to display the collected data on the computer screen, namely ‘Listen’ and ‘PrintfClient’. The Listen java tool is used to display the raw sensing data together with the serial packet header bytes, while the PrintfClient java tool is used to display character strings of the temperature program output we made on the sensing mote.

In brief, our main aim of the experiment is to sense the temperature readings, hopping the data using the IEEE 802.15.4 ZigBee radio from the sensing mote to the base station, and viewing the readings on the computer screen to where the base station is attached. The communication between the sensing mote to the base station is through wireless radio while the communication between the base station and the observing computer is using serial cable transmission.

B. Hardware Setup In the study, we use TelosB motes to gather temperature

data and display the readings on the computer screen. TelosB mote is a ‘tiny form factor computer’ consists of microprocessor for processing, memory for data storage, and a number of sensors for data sensing. It has a dimension of 8cm x 3cm, capable of transmitting data at 250 kbps, has an integrated on-board antenna, and is IEEE 802.15.4 compliant. TelosB mote using the 8MHz TI MSP430 Microcontroller with a 48K bytes flash memory and 10K bytes RAM. It is an open source platform with a 16K bytes configurable EEPROM that allow programming and data collection via a built-in USB [23], [24], [25].

TelosB mote has an integrated Sensirion SHT11 temperature and humidity sensors [26], and also the Hamamatsu S1087 visible light and visible to IR sensors. The Sensirion SHT11 temperature sensor has a documented reading range of -40°C to 123.8°C with an accuracy of ±0.5°C, and sensing resolution of 0.01°C. Apart from that, the computer we are using is a 1.6 GHz Intel Core i5, 8 GB 1600 MHz RAM, and running OS X EI Capitan version 10.11.3.

We conduct the experiment by considering the following motes setup: fix and stationary mote, use IEEE 802.15.4 channel 26 with an assumption of no signal interference with any nearby wireless devices, motes are located within the 2.4 GHZ ISM band communication range with full transmission power of 0dBm, the sensing mote is equipped with new full

power 3.0V AA Alkaline batteries, and both motes are not contained in any container for weather and environment protection purposes.

C. Software Settings In this experiment, we programmed the TelosB motes

using the TinyOS 2.1.1 nesC codes running on a 32-bit Ubuntu 14 OS. The Ubuntu Linux is running on the Parallels Desktop virtual machine version 11.1.3 on an OS X EI Capitan version 10.11.3 computer.

D. Systems Wiring In nesC, the connection among components involved in

the systems is called ‘wiring’. nesC codes wiring occurs when connecting between the interface of the user that used the component to the provider of the interface. In other words, the interface’s user is connected to or make requests (by calling commands) on the interface’s provider (the provider makes callbacks to the interface’s user by signaling events) [27], [28], [29].

In our case of reading the temperature, the sensing application component (called module) is a user of the Read interface (Read) provided by the SensirionSht11C component (called configuration); where the readDone event is a callback signaled when the sensor component finished sensing the temperature. The wiring between these components are shown below:

components new SensirionSht11C() as TempSensor; TempSenseRadioC.Read -> TempSensor.Temperature;

The operator ‘->’ infers that the TempSenseRadioC module uses the Read interface provided by the SensirionSht11C components (as the TempSensor instance). Here, TempSenseRadioC is the user while SensirionSht11C is the provider. The ‘->’ operator also denotes the wiring between the TempSenseRadioC module and the SensirionSht11C components. The definition of our sensing application module in the nesC program code is:

module TempSenseRadioC { uses { interface Read; } }

A call to the interface Read is done by calling the read() function provided by the SensirionSht11C component. The function call denotes by: call Read.read(). We set this function call in an event of a timer being fired (event void MilliTimer.fired()), which is at every one second; each second the timer fired, the SensirionSht11C sensor component on the TelosB mote sense the temperature in the area of sensing.

As a user of the Read interface, the TempSenseRadioC module also must implement any events issued by the provided components (SensirionSht11C), where in this case is the readDone event and denotes by the below code. event void Read.readDone(error_t result, uint16_t data)

While receiving this signal callbacks, we program our sensing application to read the message structure of the received temperature readings (of a size of 14-bit readings read in an unsigned 16-bit data type), calibrate the readings based on the calibration formula stated in the sensor datasheet, and display the meaningful readings on the base station computer screen (shown in next section).

In particular, our sensing application module is named TempSenseRadioC while the configuration application that wire the TempSenseRadioC to the TinyOS services is named TempSenseRadioAppC. The TempSenseRadioAppC configuration are details as below:

configuration TempSenseRadioAppC {} implementation { components MainC, LedsC, TempSenseRadioC; components new AMSenderC(AM_SENSE_MSG); components new AMReceiverC(AM_SENSE_MSG); components new TimerMilliC(); components ActiveMessageC; components new SensirionSht11C() as TempSensor; TempSenseRadioC.Boot -> MainC.Boot; TempSenseRadioC.Read -> TempSensor.Read;

… … }

This denotes that the TempSenseRadioAppC configuration is built out of several components (modules or configurations) namely, MainC (system boot), LedsC (LED control), TempSenseRadioC (our sensing module), AMSenderC (radio control), AMReceiverC (radio control), TimerMilliC (timer control), ActiveMessageC (TinyOS’s messaging system), and SensirionSht11C (temperature sensor control). TempSenseRadioAppC explicitly specifies the connection (or wiring) between interface provided and used by these components. Fig. 1 demonstrate the wiring diagram of our TempSenseRadioC sensing application.

Fig. 1 Wiring diagram for TempSenseRadio application. The connecting arrows show Interfaces from the use module (TempSenseRadio) to the provider components.

E. System Configuration The objective of the experiment is to send temperature

readings using wireless transmission from the sensing mote to the base station, where the connection between the sensing mote to the base station is via 2.4 GHz radio and the connection between the base station and the attached

computer is using a USB connector. Fig. 2 shows the connection setup.

Fig. 2 Logical connection of the sensing mote (node) and the base station mote. The sensing mote connects to the base station using 2.4 GHz radiowave while the base station connects to the monitoring computer using USB-to-serial port.

We built the sensing application in TinyOS using nesC codes. The application is installed on the sensing mote to sense the temperature of a room. Each time the mote done with each of the sensing, it triggers its led component (the yellow led) to blink, as an indicator to the observer that data has being sensed at that particular period of time. We set the periodic sensing task to be at every 1024 millitime or equivalent to 1 second.

As soon as the mote boots up, it powers on the radio component to begin the transmission. This is also the time the periodic timer starts ticking its clock for periodic data sensing. As been indicated, the sensing mote Timer keeps ticking for every second which also indicates the mote to be sensing the temperature readings for every second. The nesC codes to start the radio as the mote booted up and starting the periodic timer are as follows:

event void Boot.booted() { call AMControl.start(); } event void AMControl.startDone(error_t err) { if (err == SUCCESS) { call MilliTimer.startPeriodic(1024); }else { call AMControl.start(); } }

Similarly, the yellow led (led1) of the mote is blinking

(toggling) synchronically with the sensing of the temperature, and at the same time the mote is sending the sensed data to the base station through its radio transceiver.

event void MilliTimer.fired() { sense_count_msg_t* scm = (sense_count_msg_t*)call Packet.getPayload(&packet, sizeof(sense_count_msg_t)); call Read.read();

call Leds.led1Toggle(); if (scm == NULL) { return; } if (call AMSend.send(AM_BROADCAST_ADDR, &packet, sizeof(sense_count_msg_t)) == SUCCESS) {} }

In short, as the radio started, three events occur: periodic timer starts ticking, data being sensed, and the sensed data is transmitted to the base station. All these events occur once at a time in one clock tick.

The sensing task consists of two processes. First, the data sensing that occurs at every one second during the clock tick. Second task occurs particularly after the sensing finished. During this time, the sensed data are read and stored in the packet structure before transmitting to the base station. It is actually during at the second task, the raw sensed data are interpreted, processed, and the readings are calibrated before it can understandably be viewed to the human eyes.

Calibrating the sensor reading during the second process of the read event, need to apply the formula given from the developer specification manual. For example, to convert a 14-bit temperature reading with mote power of 3.0 Volt to temperature Celsius and Fahrenheit, we use the following formula [26]:

TC = -39.6 + 0.01 * TR

TF = -39.3 + 0.018 * TR

where TC is temperature in Celcius, TF is temperature in Fahrenheit, and TR is the sensed temperature. In order to view the resulted temperature on the screen, we make use of the printf function available from the printf.h library provided by TinyOS. Since the temperature data structure is of a type of unsigned integer (uint16_t), we have to use the ‘%u’ operator to correctly print and view the calibrated temperature. The snippet codes below show the nesC codes of these events.

event void Read.readDone(error_t result, uint16_t data) { uint16_t tempCelc; uint16_t tempFah; sense_count_msg_t* scm = (sense_count_msg_t*)call Packet.getPayload(&packet, sizeof(sense_count_msg_t)); if (result == !SUCCESS) { data = 0xffff; }else{ scm->tempReading = data; tempCelc = -39.6+0.01*scm->tempReading; tempFah = -39.3+0.018*scm->tempReading; printf("Reading: 0x%x (Hex) / %u (Dec)\n", scm->tempReading, scm->tempReading); printf("Temperature: %u (C) / %u (F)\n",tempCelc, tempFah); printfflush(); } }

To view the temperature on the computer screen, we simply use the built-in java tool of TinyOS called PrintfClient by hitting a command below. The sample output of the readings is shown in Fig. 3.

$java net.tinyos.tools.PrintfClient –comm serial@/dev/ttyUSBx:telosb

Fig. 3 Temperature sensor readings in Celcius (C) and the equivalent Fahrenheit (F) after applying the calibration formula.

Part of the experiment also dealt with the hopping of the sensed readings from the sensing mote to the base station. Act as a ‘communicating bridge’, the base station relays any serial or radio data it receives via its serial port or radio transceiver to the attached computer. In our experiment, we view the readings in a form of bytes containing the packet header together with the sensor readings. We use the TinyOS’s built-in ‘Listen’ java tool by issuing $java net.tinyos.tools.Listen –comm serial@/dev/ttyUSBx:telosb to display these data. Fig. 4 shows the resulting screen output.

Fig. 4 Temperature sensor readings (two bytes from right) in raw byte format shown by issuing the TinyOS’s Listen java tool at the base station mote.

The output shows a complete TinyOS’s ActiveMessage packet with the payload of the packet is at the last two bytes of the packet (little endian notation), the rest are the packet header. Therefore, by examining each line (packet) of the output, the temperature readings are byte number shown as ’19 6D’, ’19 6E’, ’19 6C’, etcetera. By translating to the Celcius / Fahrenheit equivalent, these readings represent a temperature of 25°C / 77°F.

In conclusion, the sensor readings can be viewed either using the PrintfClient or the Listen java tool, with a simple calibration on the received readings. To aid the translation of the readings using the Listen tool, we had created a simple C programs to display similar output as shown in Fig. 3. Fig. 5 shows a snapshot of the main function of the program.

Fig. 5 The C main program to calibrate and convert the TelosB’s Sensirion SHT11 sensor readings to their Celsius and Fahrenheit equivalent.

IV. CONCLUSION AND FUTURE WORKS In this study, we demonstrate the application of

environmental sensing and the basic science of data sensing, data processing, and data display using the TinyOS TelosB motes. The experiment setup is simple: sensing temperature using one mote, calibrate the sensed data, hop the data to the base station, and display them on the screen for monitoring. The significance of the study is twofold: the basic knowledge on sensor data capturing we gather in this experiment is valuable to open up a further research on integrating the IPv6, 6LoWPAN, and CoAP protocol in order to view the sensed data globally through different networks in the World Wide Web; and the basic knowledge we gather on hopping the sensed data through the radio communication would eventually important for us to research on the energy-efficient techniques of data passing from one node to another in a networked multihopping fashion.

It is therefore, our future works may reserve to investigate the integration of the Internet of Things technology in sensor data monitoring, and the energy-efficiency mechanisms on information passing in the networked of sensors.

ACKNOWLEDGMENT This work is partially supported by the Ministry of

Education Malaysia and the Encouragement Grant with Reference No. Q.K130000.2638.11J47 of Universiti Teknologi Malaysia (UTM).

REFERENCES [1] I. F. Akyildiz, W. Su, Y. Sankarasubramaniam, and E. Cayirci, “A

survey on sensor networks,” IEEE Commun. Mag., vol. 40, no. 8, pp. 102–105, 2002.

[2] S. R. Wankhade and N. A. Chavhan, “A review on data collection method with sink node in wireless sensor networks,” Int. J. Distrib. Parallel Syst., vol. 4, no. 1, pp. 67–74, 2013.

[3] R. Gao, H. Zhou, and G. Su, “A wireless sensor network environment monitoring system based on TinyOS,” 2011 Int. Conf. Electron. Optoelectron. (ICEOE 2011), pp. 497–501, 2011.

[4] B. Krishnamachari, Networking wireless sensors. Cambridge: Cambridge University Press, 2005.

[5] J. Barros, “Sensor networks: An overview,” in Learning from data

streams, New York, USA: Springer Berlin Heidelberg, 2007, pp. 9–22.

[6] H. Karl and A. Willig, Protocols and architectures for wireless sensor networks. West Sussex, England: John Wiley & Sons, 2007.

[7] P. Sanyal, S. Das, S. S. Bhunia, S. Roy, and N. Mukherjee, “An experience of implementing IPv6 based data retrieval system for Wireless Sensor Networks,” 2012 Int. Conf. Recent Adv. Comput. Softw. Syst., pp. 154–157, 2012.

[8] H. Kaplan and T. Ozkul, “A novel smart fatigue damage sensor for structural health monitoring of critical components of structures,” Int. Conf. Ind. Informatics Comput. Syst., pp. 1–5, 2016.

[9] A. Somov, Z. J. Chew, T. Ruan, Q. Li, and M. Zhu, “Poster abstract : Piezoelectric energy harvesting powered WSN for aircraft structural health monitoring,” 15th ACM/IEEE Int. Conf. Inf. Process. Sens. Networks, pp. 1–2, 2016.

[10] N. Hendrarini and Ema, “Artificial immune wireless intelligent sensor and actuator network (WISAN) for more electrical aircraft performance monitoring system (study case: 80 passenger aircraft),” 1st Int. Conf. Wirel. Telemat., pp. 1–8, 2015.

[11] I. E. Radoi, J. Mann, and D. K. Arvind, “Tracking and monitoring horses in the wild using wireless sensor networks,” 11th Int. Conf. Wirel. Mob. Comput. Netw. Commun., pp. 732–739, 2015.

[12] F. Dressler, S. Ripperger, M. Hierold, T. Nowak, C. Eibel, B. Cassens, F. Mayer, K. Meyer-wegener, and A. Kölpin, “From radio telemetry to ultra-low-power sensor networks : tracking bats in the wild,” IEEE Commun. Mag., no. January, pp. 129–135, 2016.

[13] L. Mertz, “Convergence revolution comes to wearables: multiple advances are taking biosensor networks to the next level in health care,” IEEE Pulse, vol. 7, no. 1, pp. 13–17, 2016.

[14] P. Gope and T. Hwang, “BSN-Care: A secure IoT-based modern healthcare system using body sensor network,” vol. 16, no. 5, pp. 1368–1376, 2016.

[15] A. Al-Radaideh, A. R. Al-Ali, S. Bheiry, and S. Alawnah, “A wireless sensor network monitoring system for highway bridges,” 1st Int. Conf. Electr. Inf. Technol., pp. 119–124, 2015.

[16] H. Karvonen, J. Suhonen, J. Petajajarvi, M. Hamalainen, M. Hannikainen, and A. Pouttu, “Hierarchical architecture for multi-technology wireless sensor networks for critical infrastructure protection,” Wirel. Pers. Commun., vol. 76, no. 2, pp. 209–229, 2014.

[17] M. Srbinovska, C. Gavrovski, V. Dimcev, A. Krkoleva, and V. Borozan, “Environmental parameters monitoring in precision agriculture using wireless sensor networks,” J. Clean. Prod., vol. 88, pp. 297–307, 2015.

[18] T. Ma, Y. Liu, J. Fu, and Y. Jing, “Forest fire monitoring based on mixed wireless sensor networks,” Int. J. Smart Home, vol. 9, no. 3, pp. 169–184, 2015.

[19] F. Wang and J. Liu, “Networked wireless sensor data collection: issues, challenges, and approaches,” IEEE Commun. Surv. Tutorials, vol. 13, no. 4, pp. 673–687, 2011.

[20] IEEE Standard, “IEEE standard for information technology-telecommunications and information exchange between systems-local and metropolitan area networks-specific requirements-Part 15 . 4 : Wireless Medium Access Control ( MAC ) and Physical Layer ( PHY ) Specifications ,” IEEE Std 802.15.4-2006, pp. 1–26, 2006.

[21] F. Zhao and L. Guibas, Wireless sensor networks: An information processing approach. San Jose, CA, California: Elsevier, 2004.

[22] TinyOS, “Mote-mote radio communication.” [Online]. Available: http://tinyos.stanford.edu/tinyos-wiki/index.php/Mote-mote_radio_communication. [Accessed: 20-Jun-2003].

[23] MEMSIC Inc., “TelosB datasheet: Document Part Number: 6020-0094-02 Rev B.” San Jose, CA, California, 2003.

[24] T. Instruments, “CC2420 datasheet: 2.4 GHz IEEE 802.15.4/ZigBee-ready RF transceiver: Document SWRS041B.” Dallas, Texas, pp. 1–89, 2010.

[25] J. Polastre, R. Szewczyk, and D. Culler, “Telos: Enabling ultra-low power wireless research,” 2005 4th Int. Symp. Inf. Process. Sens. Networks, IPSN 2005, pp. 364–369, 2005.

[26] Sensirion, “Datasheet SHT1x (SHT10, SHT11, SHT15) Humidity and Temperature Sensor,” no. September. pp. 1–11, 2008.

[27] D. Gay, P. Levis, R. von Behren, M. Welsh, E. Brewer, and D.

Culler, “The nesC language : A holistic approach to networked embedded systems,” Proc. ACM SIGPLAN 2003 Conf. Program. Lang. Des. Implement., vol. 38, no. 5, pp. 1–11, 2003.

[28] P. Levis and D. Gay, TinyOS Programming, vol. 1st. Ed. 2009. [29] P. Levis, S. Madden, J. Polastre, R. Szewczyk, K. Whitehouse, A.

Woo, D. Gay, J. Hill, M. Welsh, E. Brewer, and D. Culler, “TinyOS: An operating system for wireless sensor networks,” in Ambient Intelligence, Springer-Verlag, 2005, pp. 115–148.