wireless sensor networks seminar

Wireless Sensor Networks Seminar Summer Term 2014

Iliya Gurov, Tao Li, Prof. Dr. Silvia Santini, Prof. A. Buchmann, PhD

28/04/2014 | TU Darmstadt | Wireless Sensor Networks Seminar| SS 2014 | 1

WSN Seminar Registration


... not enough supervisors §  Max. 12 participating students i.e., 6 groups in total §  We will apply FCFS policy

§  You have to be here today §  You have to register your group as fast as possible

§  Registration starting today at

§  Email to: [email protected] §  Subject: WSN Seminar Registration §  Two group members §  List of topic preferences

Historical Perspective

Smart Dust

Bell’s law

© Mark Weiser, XEROX PARC

18 -

16 -

14 -

12 -

10 -

8 -

6 -

4 -

2 -

0 -

1940

-

1945

-

1950

-

1955

-

1960

-

1965

-

1970

-

1975

-

1980

-

1985

-

1990

-

1995

-

2000

-

2005

-

2010

-

many people, one computer one person, one computer one person, many computers

Trends in Computing

Mark Weiser


Meet the Family

WeC [1999]

“Smart Rock”

§  Small microcontroller §  8 KB Program §  512 B Data

§  32 KB EEPROM §  Simple, low-power radio

§  10 kbps ASK §  Simple sensors §  Active power: 15 mW

1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012


Meet the Family

WeC [1999]

“Smart Rock”

§  Designed for experimentation:

§  sensor boards §  power boards

§  Active power: 8 mW

1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012

Rene [11/2000]


Meet the Family

WeC [1999]

“Smart Rock”

Dot [9/2001]

1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012

§  Demonstrate scale

Rene [11/2000]


Meet the Family

WeC [1999]

“Smart Rock”

Dot [9/2001]

Mica [1/2002]

§  NEST open exp. platform §  128 KB code §  4 KB data

§  40 kbps OOK/ASK radio §  512 KB Flash

1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012

Rene [11/2000]


Meet the Family

WeC [1999]

“Smart Rock”

Dot [9/2001]

Mica [1/2002]

Mica2 [12/2002]

§  Commercial platform §  128 KB code §  4 KB data

§  512 KB Flash §  38.4 kbps FSK radio §  Active power: 33 mW

1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012

Rene [11/2000]


Meet the Family

WeC [1999]

“Smart Rock”

Dot [9/2001]

Mica [1/2002]

Mica2 [12/2002]

Telos [2004]

§  Robust low power operation §  8 MHz TI MSP430

§  48 KB code §  10 KB RAM

§  1 MB External Flash §  Chipcon 802.15.4 radio §  Active power: 3 mW §  Current draw, active: 21.8mA

1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012

Rene [11/2000]


Meet the Family

WeC [1999]

“Smart Rock”

Dot [9/2001]

Mica [1/2002]

Mica2 [12/2002]

MicaZ

Telos [2004]

§  Commercial product §  128 KB code §  4 KB data

§  512 KB Flash §  250 kbps 802.15.4 compliant radio

1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012

Rene [11/2000]


Meet the Family

WeC [1999]

“Smart Rock”

Dot [9/2001]

Mica [1/2002]

Mica2 [12/2002]

MicaZ

Telos [2004]

§  Processor-intensive apps §  Intel XScale CPU, 13~416MHz

§  32 MB SDRAM §  256 KB RAM

§  32 MB Flash §  Wireless MMX DSP co-proc §  2.4 GHz 802.15.4 Radio §  Camera interface

1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012

iMote2 2007

Rene [11/2000]


Meet the Family

WeC [1999]

“Smart Rock”

Dot [9/2001]

Mica [1/2002]

Mica2 [12/2002]

SunSpot [2007]

MicaZ

Telos [2004]

§  Java on sensors §  180 MHz, 32 bit ARM

§  4 MB Flash §  512 KB RAM

§  2.4 GHz 802.15.4 radio §  Temperature, light, accel. §  Netbeans plugin

1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012

iMote2 2007

Rene [11/2000]


Meet the Family

WeC [1999]

“Smart Rock”

Dot [9/2001]

Mica [1/2002]

Mica2 [12/2002]

SunSpot [2007]

MicaZ

Telos [2004]

1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012

iMote2 2007

Z1 [4/2010]

§  Rejuvenated Telos: §  16MHz Clock (vs. 8MHz) §  92KB ROM (vs. 48KB) §  2MB External Flash (vs. 1MB) §  Half power consumption §  8KB RAM (vs. 10KB L)

§  Digital 3 axis accelerometer

Rene [11/2000]


Meet the Family

WeC [1999]

“Smart Rock”

Dot [9/2001]

Mica [1/2002]

Mica2 [12/2002]

SunSpot [2007]

MicaZ

Telos [2004]

1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012

iMote2 2007

Z1 [4/2010]

§  Low power 32-bit: §  Atmel Cortex M3 SAM3U, 96MHz §  256 Flash, 52 KB SRAM §  wakeup < 10us

§  Multiradio: 3.7x faster throughput than Telos-like §  Still power hungry for low power apps

Egs, Opal [12/2011]

122 IEEE EMBEDDED SYSTEMS LETTERS, VOL. 3, NO. 4, DECEMBER 2011

Fig. 1. Functional diagram of the major Opal components.

Fig. 2. Opal platform.

over other available Cortex-M3 based microcontrollers thathad similar features. The MPU provides a way to protect thememory spaces of multiple simultaneously running threads [4].It also allows applications to securely update system code usingDeluge [5] by protecting the boot-loader’s memory space.

The most interesting feature that distinguishes Opal fromother mote platforms is the versatility of its radio components.Two low-power 802.15.4 compliant radios can run at bitratesbetween 250 Kbps and up to 2 Mbps. The outputs can beswitched between two separate antennas and power amplifierswith a maximum gain of 19.7 dB can be enabled on demandto increase the communication range. For compatibility rea-sons, a third non-802.15.4 radio can be loaded. We use the TICC1101 at 433 MHz for backwards compatibility. The radiocomponents provide significant versatility for meeting diverseapplication requirements. The multiple-input–multiple-output(MIMO) capabilities allow for high link reliability and highthroughput. In our evaluation of the platform, we focus on the802.15.4 compatible components without additional amplifiers.

We have mentioned security and power efficiency as perhapsthe two most important building blocks of real-world WSN ap-plications. Opal supports stronger-than-standard secure com-munications, actuation, and remote attestation through a trusted

platform module (TPM) chip. To support long-term outdoor de-ployments, Opal also includes a proprietary energy harvestinginput that feeds into a hardware-based Li-Ion battery chargingcircuit. This mechanism allows the microcontroller to be put todeep sleep mode while the batteries are recharged with solar orother ambient energy sources.

We focus the rest of the letter on evaluating Opal’s innovativeradio interface design and show that it fills a gap in the designspace of high throughput applications with low spatial energycost.

III. EVALUATION

To determine the suitability of the Opal platform for sup-porting high-speed applications, we report the range, throughputand energy consumption in various configurations (e.g., singleand dual radio mode). For ease of comparison we propose anew metric, called spatial energy cost (pJ/bit/m ), that com-bines three performance characteristics (energy, throughput, andrange) into a single metric. Note that the spatial energy costmetric augments the spatial capacity parameter in [6], [7] to in-clude energy efficiency. Effectively it measures a platform’s en-ergy cost to deliver a bit of information within a unit area.

A. Experimental Setup

To put things into perspective we evaluate Opal’s perfor-mance relative to both the TelosB [8] and an Iris-like platformwe call Iris . The TelosB was selected because of its familiarityto the WSN research community; the Iris was selected be-cause of its hardware similarities to Opal. The Iris is centeredaround an Atmel1281 MCU and the RF230 radio, which alsofeaturs in the Opal design; in addition the Iris can be extendedto drive an RF212 radio, the other radio that Opal includes.Thus, by comparing the Iris and Opal platforms we can isolateand study the impact of including a different MCU on systemperformance.

We tested all platforms in TinyOS. Note that we have not op-timized the network and serial port drivers, nor the operatingsystem to maximize performance of any of the platforms. In-stead, we focused on evaluating the standard drivers and out ofthe box performance of these platforms. Using compile-time di-rectives, the Opal and Iris nodes could be configured to useone of the two radios, or to run both of them at the same time,so three modes in total. Our experiments involved only point-to-point measurements, so no routing component was included. In-stead a simple application was used that submitted packets asfast as possible and the receiving node forwarded all packetsto a PC through a serial link (or a USB link in Opal’s case).Missing and corrupted packets are accounted for as we reportthroughput, i.e., the amount of user data per second effectivelyreceived when streaming packets with 100-byte payloads.

To measure the energy consumption we inserted a 10-Ohmshunt resistor between the battery pack and the sending plat-form, and measured the voltage drop with an oscilloscope. Thereported current draw is computed as the average value over thetime interval needed to send out a single packet. Note that thebaseline current drawn by the complete platform is included,so the reported numbers are higher than the raw TX numbersfrom the data sheets of the respective radio chip. For reference,

Rene [11/2000]


Meet the Family

WeC [1999]

“Smart Rock”

Dot [9/2001]

Mica [1/2002]

Mica2 [12/2002]

SunSpot [2007]

MicaZ

Telos [2004]

§  Two 32-bit microcontrollers: §  Jennic JN5148 SoC: §  16MHz, 128KB RAM, 128KB ROM §  ATmega 32u4: §  USB-capabilities

§  36mA in active mode §  SD-card slot §  Wireless inertial motion tracking

1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012

iMote2 2007

Z1 [4/2010]

Egs, Opal [12/2011]

122 IEEE EMBEDDED SYSTEMS LETTERS, VOL. 3, NO. 4, DECEMBER 2011

Fig. 1. Functional diagram of the major Opal components.

Fig. 2. Opal platform.

over other available Cortex-M3 based microcontrollers thathad similar features. The MPU provides a way to protect thememory spaces of multiple simultaneously running threads [4].It also allows applications to securely update system code usingDeluge [5] by protecting the boot-loader’s memory space.

The most interesting feature that distinguishes Opal fromother mote platforms is the versatility of its radio components.Two low-power 802.15.4 compliant radios can run at bitratesbetween 250 Kbps and up to 2 Mbps. The outputs can beswitched between two separate antennas and power amplifierswith a maximum gain of 19.7 dB can be enabled on demandto increase the communication range. For compatibility rea-sons, a third non-802.15.4 radio can be loaded. We use the TICC1101 at 433 MHz for backwards compatibility. The radiocomponents provide significant versatility for meeting diverseapplication requirements. The multiple-input–multiple-output(MIMO) capabilities allow for high link reliability and highthroughput. In our evaluation of the platform, we focus on the802.15.4 compatible components without additional amplifiers.

We have mentioned security and power efficiency as perhapsthe two most important building blocks of real-world WSN ap-plications. Opal supports stronger-than-standard secure com-munications, actuation, and remote attestation through a trusted

platform module (TPM) chip. To support long-term outdoor de-ployments, Opal also includes a proprietary energy harvestinginput that feeds into a hardware-based Li-Ion battery chargingcircuit. This mechanism allows the microcontroller to be put todeep sleep mode while the batteries are recharged with solar orother ambient energy sources.

We focus the rest of the letter on evaluating Opal’s innovativeradio interface design and show that it fills a gap in the designspace of high throughput applications with low spatial energycost.

III. EVALUATION

To determine the suitability of the Opal platform for sup-porting high-speed applications, we report the range, throughputand energy consumption in various configurations (e.g., singleand dual radio mode). For ease of comparison we propose anew metric, called spatial energy cost (pJ/bit/m ), that com-bines three performance characteristics (energy, throughput, andrange) into a single metric. Note that the spatial energy costmetric augments the spatial capacity parameter in [6], [7] to in-clude energy efficiency. Effectively it measures a platform’s en-ergy cost to deliver a bit of information within a unit area.

A. Experimental Setup

To put things into perspective we evaluate Opal’s perfor-mance relative to both the TelosB [8] and an Iris-like platformwe call Iris . The TelosB was selected because of its familiarityto the WSN research community; the Iris was selected be-cause of its hardware similarities to Opal. The Iris is centeredaround an Atmel1281 MCU and the RF230 radio, which alsofeaturs in the Opal design; in addition the Iris can be extendedto drive an RF212 radio, the other radio that Opal includes.Thus, by comparing the Iris and Opal platforms we can isolateand study the impact of including a different MCU on systemperformance.

We tested all platforms in TinyOS. Note that we have not op-timized the network and serial port drivers, nor the operatingsystem to maximize performance of any of the platforms. In-stead, we focused on evaluating the standard drivers and out ofthe box performance of these platforms. Using compile-time di-rectives, the Opal and Iris nodes could be configured to useone of the two radios, or to run both of them at the same time,so three modes in total. Our experiments involved only point-to-point measurements, so no routing component was included. In-stead a simple application was used that submitted packets asfast as possible and the receiving node forwarded all packetsto a PC through a serial link (or a USB link in Opal’s case).Missing and corrupted packets are accounted for as we reportthroughput, i.e., the amount of user data per second effectivelyreceived when streaming packets with 100-byte payloads.

To measure the energy consumption we inserted a 10-Ohmshunt resistor between the battery pack and the sending plat-form, and measured the voltage drop with an oscilloscope. Thereported current draw is computed as the average value over thetime interval needed to send out a single packet. Note that thebaseline current drawn by the complete platform is included,so the reported numbers are higher than the raw TX numbersfrom the data sheets of the respective radio chip. For reference,

Fig. 2: The jNode platform with a physical size of58x17x19mm. The bottom layer shows the combination ofsensor modules. The upper layer shows the Jennic JN5148networking module, the µSD-card and USB connector.

One reason could be the unavailablity of capable inves-tigation platforms. We believe that a specifically optimizedinvestigation and observation platform based on ad-hoc net-worked sensing systems (NSS) can provide the means tostudy how machine servicing may be enhanced. In [2], [7]functional requirements for an industrial servicing platformwere identified based on a service worker use-case: technlogiesfor industrial servicing can not be decided on a general level[2]we believe that providing a capable platform which enables theemulation of simpler systems, e.g. an (active) RFID system, isthe best approach. The requirements for an in-situ diagnosistool are given in the following.

B. Group Activity RecognitionNowadays, many of us constantly carry one or more in-

telligent device, and the number of intelligent systems in ourenvironment such as entertainment systems, vending machinesand informational displays is steadily increasing. Implicit pro-active interaction based on situational awareness is gettingmore important in order to prevent us from entering a stateof permanent distraction and informational overload. Onevision within pervasive and ubiquitous computing sees thesedevices changing from private, single-user devices to multi-user devices running private applications for those users whoare present. A challenge then becomes not only recognizingthe context of the single user who is interacting with thedevice, as is the case with mobile phones, but now attemptingto recognize the activity of a group of individuals who are ina specific environment or interacting with the system [8].

Using a distributed wearable platform for both sensing andprocessing aspects of activity recognition is advantageous inthat it allows the system to operate independent of existinginfrastructure and therefore widens the field of applications.The group activity is not necessarily the same as the sum ofthe activities of the individuals in it, but rather is a functionof the activity or context of all individuals in the group.

Therefore, data from wearable sensors on multiple users mustbe aggregated in order to infer the group context [3].

C. Embedded Motion TrackingWhile the previous use-cases have focussed on acquiring

kinetic information by attaching sensors directly to the objectsof interest, we can also monitor motion by attaching sensorsto tools or objects which are used in order to accomplish atask. Such approaches are for instance typically followed inliving lab environments where various rooms, furniture andevery-day tools are outfitted with sensors to derive especiallyhuman activities and contexts, as for instance also suggestedby work described in [9], [10].

In particular, we want to apply this approach to the domainof firefighter navigation in indoor environments. While thisproblem domain has been in the focus of ubicomp researchin the past [11], [12], these approaches usually concentrate onthe use of body-attached inertial sensors and/or the utilizationof ad-hoc sensor networks deployed in the environment [12].

D. Summary of the requirements and implications for aninvestigation platform

Based on the above described use-cases and correspondingrequirements we can summarize the specification for a kine-matic research platform as a system which provides:

1) a standardized wireless interface/protocol stack to con-nect nodes with each other and to external systems, theinterface further supports ad-hoc networks and providessome means of security

2) sufficient internal memory (RAM, EEPROM) for dataprocessing and short time storage

3) a sufficiently large memory for long-term storage4) high software configurability, e.g. freely programmable

system, support of reloading modules, over-the-air pro-gramming, hands-free serial

5) high hardware flexibility, e.g. various sensor boards,open hardware platform

6) sensors able to provide valuable data for machine mon-itoring, group user activity recognition and embeddedmotion monitoring

7) high battery capacity/highly power-efficient to allowlong-term monitoring

8) time synchronisation, e.g. highly accurate clocks, em-bedded into wireless implementation, special hardwarefor time measurements

9) limited dimension and packaging10) provision of signal processing algorithms and corre-

sponding capabilities of the micro-controller11) support of identification methods, e.g. rudimentary local-

ization capabilies, support of optical markers, emulationof (active) RFID systems

III. SYSTEM DESIGN

Three of the requirements introduced in the last section havemainly driven the design of the jNode, namely the ability tomonitor a large number of nodes for long periods of time in a

jNode [2012]

Rene [11/2000]


An Application Tour Habitat Monitoring

§  Great Duck Island Szewczyk et al., Sensys '04


An Application Tour Habitat Monitoring

§  California’s Coastal Redwood Forests Tolle et al. SenSys 2005

Temperature vs. Time

8

13

18

23

28

33

7/7/039:40

7/7/0313:41

7/7/0317:43

7/7/0321:45

8/7/031:47

8/7/035:49

8/7/039:51

8/7/0313:53

8/7/0317:55

8/7/0321:57

9/7/031:59

9/7/036:01

9/7/0310:03

Date

Tem

pera

ture

(C

)

Humidity vs. Time

35

45

55

65

75

85

95

Rel

Hum

idit

y (%

)

101 104 109 110 111


An Application Tour Glacier Monitoring

§  Glacsweb - Briksdalsbreen, Norway http://www.glacsweb.org!


An Application Tour Precision Agriculture

§  Lofar Agro - The Netherlands Langendoen et al., WPDRTS 2006


An Application Tour Volcano Monitoring

§  Volcán Reventador, Ecuador Welsh et al., SOSP 2005


An Application Tour Structure Monitoring

§ Structural Health Monitoring http://www.cs.berkeley.edu/~binetude/ggb/ !

Kim et al., IPSN 2007


An Application Tour Industrial Automation

§  Chemical Drums Storage Management http://www.cobis-online.de


An Application Tour Fire Monitoring

§  Fire Information Rescue Equipment (FIRE) http://fire.me.berkeley.edu


Challenges

§  Power consumption §  (Limited) energy supply

§  Processing capabilities §  8/16 bit microcontrollers §  no floating point arithm.

§  Communication §  Multi-hop §  Communication failures

§  Data storage §  Deployment

§  Lack of appropriate tools

§ Microcontroller § Memory § Radio § Sensors § Programming


Formalia

§  Organizers: DVS, WSN Lab

§  Course of studies: FB 20 and FB 18 §  Type of Activity: Seminar (2 SWS) §  Schedule: Block Seminar

§  no weekly meetings, coordinate with supervisor §  “marathon sit-down” at semester’s end

§  Examination: (see following list of assignments)


Seminar Assignments and Duties

§  1st Delivery: Preliminary Document (10%) §  Begin with literature research on topic in question §  Prepare a written report on your topic, in English §  Use the LaTeX style template provided in course’s homepage §  Include an Abstract, Introduction, […], Summary & Conclusion §  Check your progress with your supervisor regularly §  Submit the PDF

§  2nd Delivery: Peer Reviews (10%) §  Every group reviews the other groups’ documents §  Use the review form (will be provided), fill it in English §  Include a summary of the reviewed paper, comments for the authors,

list of positive and negative aspects §  Reviews must contain constructive critiques!


Seminar Assignments and Duties (II)

§  3rd Delivery: Final Documents and Slides (50%) §  Adapt the preliminary document with the received reviews §  Prepare the slides on the examined topic, in English

§  4th Delivery: Presentations (30%) §  ~10 minutes per person (~7 slides per person) §  Attendance is mandatory to all participants §  Everybody is expected to participate actively in the discussion

§  Q&A will be part of the evaluation


Schedule

§  28.04.2014 - Kick-Off meeting §  23.06.2014 – Delivery of the document’s preliminary version via

email (before midnight) §  24.06.2014 – Start of the review process §  07.07.2014 – End of the review process. Delivery of the filled Review

Forms. Begin adaption of the final document. §  21.07.2014 – Delivery of the document’s final version and the slides §  28.07.2014 – Oral presentations (every group)


Wireless Sensor Networks Seminar


Topics

Realistic, Real-World Experimentation using WSN Testbeds


Realism

Real-world deployments Testbeds Simulators

Environmental Factors Impact on WSNs


§  Temperature, humidity, fog, rain, snow etc. affect:

§  Low-power wireless links §  Sensor readings §  Sensor nodes‘ hardware

components

§  Task: Study How Environmental Factors Impact Wireless Sensor Networks

Sensor Node Selection using Mobility Prediction and Location Awareness


§  An exemplary application §  Select monitoring nodes

§  Challenge §  The sensors start moving!

§  Potential solution §  Mobility prediction §  Location awareness

Task: Find, summarize, compare approaches