Sriram Rajan Master’s Thesis Presentation Advisor : Dr. Georgios Lazarou Department of Electrical...

Sriram RajanMaster’s Thesis Presentation

Advisor : Dr. Georgios LazarouDepartment of Electrical and Computer Engineering

December 9th, 2005

Dynamically Controllable Applications for Wireless Sensor Networks

Base with Mote

Isolated Mica2Mote

of 42Dynamically Controllable Applications for Wireless Sensor Networks

Agenda

• Introduction to Wireless Sensor Networks

• Requirements for Designing Dynamically Controllable Applications

• Sensor Network Programming

• Related Work

• Research Contribution

• Results, Conclusion, and Future work


Introduction to Wireless Sensor Networks (Slide 1 of 3)

Why Sensor Networks ?

• Autonomous, early warning systems [1] for Tsunamis can be developed

• Small size, can be deployed right out of the box

“Sensor node” or “Mote” refers to a combination of the following items:

• Sensor (reports events)

• Processor (stores the Mote ID, processes readings, provides encryption to sensor messages)

• Radio (Send, Receive Messages)

Split-phase operations are used for data events

• Request event

• Continue executing other events or tasks until data is received



Base Station

• Has external power supply

• Can program the base node

• Used with base node to communicate with the Wireless Sensor Network (WSN)

Base Node

• Node connected to Base Station

• Provides processing capability to the Base Station

• Can send/ receive radio signals to/from the WSN

Base Station

and

Base node

Node 4

Node 1Node 2

Node 3

Node 5

Communication Interface




• Link between Host Computer and Base Station

Links are possible via LAN, Internet and Serial mediums

Host Computer

• Communicates the WSN via the communication interface.

Sensor Node

• Robust, sensor devices

• Capable of multi-hop communication

Base Station

and

Base node

Node 4

Node 1Node 2

Node 3

Node 5



The main requirements for implementing dynamically controllable applications are [7]:

1. Propagation : The data/control messages must reach all of the nodes in the network

2. Lifetime of the network : The data traffic in the sensor network must be minimal for effective communication within the sensor network

3. Efficient Power consumption : Any implementation must consider the limited power availability and must restrict the number of transmissions for the protocol

Problem Statement


Motivation – Why work on Application optimization ?

Efficient sensor network applications can be designed [6,9] that have better fault tolerance

• The approach of executing multiple operations dynamically can be exploited to design controllable applications

• Low cost of nodes and low maintenance requirements allow for easy implementation and rapid deployment

Sensor application failures


Summary of This Work

• Designed and developed a novel scheme for TinyOS application design that attains the following objectives:

Interchangeable modules at run-time

Controllable frequency of sensor operations, such as transmitting readings or performing actions at regular intervals

Ability to control the mote operation by terminating or resetting a mote to a particular state during operation

• Our scheme has been verified to work in TinyOS and has significant time and performance improvements.


TinyOS Elements

Events signaled

Commands used

Commands

Event Handlers

Legendmsg_recv(type,

data)

receiver

activity(

)

ini

t

Generic MessagingComponent

activity

()

receive

Send_msg thread

Internal State

packet_receiv

e (success)

init

Why TinyOS for WSN? Modular nature Extensive support of platforms Large user base Example : Calamari

application

TinyOS ComponentsA component stores the state of the system, consists of interfaces and events

Event are triggered by commands, signals or other events themselves . Example : event Timer.fired()

Sending messages is achieved using split-phase or using an event that calls an appropriate task.

Sample TinyOS Component [2]


Application framework

Clocks

Photo

ADC I2C

Software

Hardware

Application Layer and Routing logic

messaging

application

GenericComm module

AM Standard module

Rad

ioC

RC

Pac

ket

mod

ule

UA

RTPack

et

mod

ule

Radio Byte

CC1000RFM

UART Byte

packet

bit

byte Temperature

Application:

Combination of software and hardware, can also provide routing information. Example : “Send message only if light intensity > 4”

Messaging component:

Messaging functions to upper level components

Event handlers for lower-level components

Packet , Byte, Bit:

Software/ Hardware components that deal with packet-level, byte level and bit level processing

Sample Application Framework [3]


TinyOS Concurrency model [2]

• Concurrency implemented by using separate procedures:

Events (hardware interrupt handlers) and tasks

• Events preempt other events and tasks

• Those statements marked atomic or events with keyword async are never interrupted

• Event failures are common occurrence when the sensor is busy with another that cannot be interrupted

• The scheduler component runs these tasks in FIFO order, unless interrupted.


Related Work

Simplex Architecture [4, 5]

• Also used for reliable upgrade of communication software [4]

• An Arbiter code is used to switch between two working module implementations

First, the reliable module and the experimental module are processed in parallel.

If the error is within the acceptable threshold, experimental module is used

Otherwise, the reliable module is implemented.


Limitations of related work and solutions

• Upgrades results in significant sensor application downtime

• Dynamically Controllable Application (DCA) is proposed as a technique is designed in TinyOS to achieve dynamic:

State changes Control the frequency of

transmission and other events (variable changes)

Functionality changes

Limitations Solutions

• Processor overload as a result of the upgrade

• Reduce overload involved in upgrade [9, 10]

• Do not meet the static programming requirement in TinyOS

• Sensor operation remains unaffected in DCA

Solutions from this research


Our Dynamically Controllable Application (DCA) Scheme (Slide 1 of 4)

• Triggers an event after receiving a message from the base mote

• a high probability of an event interrupting the application’s operation (otherwise, the event is triggered again)

State control: • Identical to the

frequency control• In addition, involves

additional variable settings and declarationsBlock Diagram of the DCA scheme



Block Diagram of the DCA scheme

Frequency Control:• Sensor applications

typically use periodic logging or other sensor data reporting functions.

Module Control:• The hypothesis that a

module change could be achieved using DCA needed to be verified

• A module control component has therefore been included in the DCA mechanism


Block Diagram of the DCA scheme


Component and Messaging Interface:

• Uses message types provided by TinyOS to trigger appropriate events

Sensor Hardware and Radio Interface:

• Provides a medium to communicate



Clocks

Photo

ADC I2C

Software

Hardware

DCA Application

messaging

application

GenericComm module

AM Standard module

Rad

ioC

RC

Pac

ket

mod

ule

UA

RTPack

et

mod

ule

Radio Byte

CC1000RFM

UART Byte

packet

bit

byte Temperature

DCA Application Framework

Field Value

Source (16 bytes)Address of the source node

Action (8 bytes)Simple action code for each

unique action

Value (8 bytes)Frequency of operation and

other values

Module (16 bytes)This field decides which module is to be activated.

DCA Message Structure


Working of DCA Scheme (Slide 1 of 3)

Frequency and State changes:

• Application Design scheme that allows for:

Frequency changes Resets

• Changes are achieved when events are triggered

• An event is triggered when command messages are received

Bypasses the static redesign requirement of the original application

Flow chart for DCA frequency/ reset change


Module Changes• Implemented using the DCA scheme• DCA allows direct communication between the modules and

radio/messaging components• Uses start/stop commands to control the active module

Original Implementation (Without DCA)• Separate modules would need to be declared and used simultaneously

Working of DCA Scheme (Slide 2 of 3)


COTS Component A COTS Component BRead Transmit_FrequencyCOTS_Module_A.initialize()COTS_Module_A.start()

Output = COTS_Module_AWhile (Not(Stop_Request()))

Display_Output()End WhileCOTS_Module_A.stop()

Read Transmit_FrequencyCOTS_Module_B.initialize()COTS_Module_B.start()

Output = COTS_Module_BWhile (Not(Stop_Request()))

Display_Output()End WhileCOTS_Module_B.stop()

Original Application

Applications would need to be redesigned, recompiled, and loaded to the sensor nodes in order to implement this change in functionality.

Read Transmit_FrequencyCOTS_ModuleA.initialize()

COTS_ModuleB.initialize()COTS_ModuleA.start()Output = COTS_ModuleAWhile (Not(Stop_Request()))

If Timer.Fired()Transmit (value)

If Module.change()COTS_Module_A.stop()COTS_Module_B.start()

Output = COTS_Module_B

End While

Application using DCA

Applications that use the DCA scheme can easily change from one “Common Off the Shelf” (COTS) component (COTS_Module_A) to another (COTS_Module_B) provided these were included in the design phase.

Example for designing DCA applications


Experimental Setup

• Design or Development Failures must be anticipated during

the design of the application and debug messages provided for evaluation.

Several areas of the code can be tested simultaneously.

• Experimentation Experimentation is done with

Hardware motes and Simulation iteratively to isolate errors

Testing is performed to determine if application is suitable for deployment

• Deployment Final stage of

application implementation on Field motes

Performed after repetitive tests on simulator and hardware to meet loss threshold


Comparison of Hardware and Software Experimental setup

Software• MessageCenter application can be

used, though the communication is also possible via the TOSSIM [8]

• The simulator can directly inject messages to any node

• Verification, Time to completion, Code comparisons and Losses can be determined.

Hardware• Requires the MessageCenter or

similar application to communicate with base node.

• Uses the base node to communicate with other nodes

• Metrics used are primarily verification and time to completion


Validation and Testing Metrics

• Time to Completion

• Verification of operation

• Comparison of results with related work

• Testing for fault conformance


Cases Comparable scenarios

Case I : Implementing software reset in a node synchronization scenario such as Traffic light

“No comparable scenario with node synchronization”

Case II: Changing frequency of operation

Manual update of operation frequency and reloading application

Case III: Dynamic design to change the node functionality by redirecting the output of the working module

Manually updating the application configuration and initiating the upgrade

Cases for Testing and Validation


• 10 sets experiments performed on hardware setup with varying node startup sequence.

• Final set of experiments performed in simulation.

• Motes are numbered (Mote id) 1 to 4

• Initially all motes have their respective yellow LED’s blinking in State 1.

• Upon receiving the sync message, each node waits for a random amount of time based on its node id, then the traffic light operation is initiated.

• The reset signal shifts all nodes to State 1 for re-synchronization.

Setup

Case I: Software reset implementation (Slide 1 of 2)


Case I: Software reset implementation (Slide 2 of 2)

ModeSynchronization time in seconds

Re-synchronization time in seconds

Hardware 35 16

TOSSIM 23 45

• Hardware and software experiments have verified the operation and have obtained the time for completion of operation.

• In a few cases of hardware setup the synchronization was not achieved without the reset signal.

Results

Verification of Hardware/ Simulation operation


Case 2: Frequency change application comparison

Mechanism Time to complete

Code complexityPacket

transmission mechanism

Power sourceadded (in lines)

Case 2Insignificant (few ms on Hardware)

98From base node/

on demandExternal

(from base)

Incremental Upgrades[9]

25 seconds > 100Individual

nodes /periodicInternal (within

node)

Deluge [10] 23 seconds 2Individual

nodes /periodicInternal

• Two sets of experiments performed on both hardware and software simulation separately

• Initially the node is started with its default frequency

• The frequency is later changed by sending a message from the base node during its operation.

Setup• A readily available application that

transmits sensor data via radio (RFM) was used

• Application functionality was verified in both hardware and software implementations

Results

Comparison of Case 2 with related mechanisms


Case 3: Module change implementation (Slide 1 of 2)

• Identical setup was used for Hardware and Simulation experiment.

• The nodes were started with one module (radio for sending sensor output signals) and the output was directed to another component (led) after a random wait.

• The network was monitored for any transmission of stray or unwanted signals from the nodes to determine any failures in module transition.

Setup

Hypothesis

• Two or more modules can be dynamically replaced in an application

• This operation can be easily accomplished by combining two readily available components (Common Off the Shelf or “COTS”)


Results

With LED active

With Radio active

LED 45.97 0

CPU 50.88 52.43

Radio 126.57 149.71Energy consumption in Millijoules for implementing and completing Module

change operation

• The change in hardware functionality from one module to another was observed instantly.

• This simulation software readings (TOSSIM) also verified the change of functionality.

• The power requirements were linear and increased steadily with time across all sensor components.

Case 3: Module change implementation (Slide 2 of 2)


Case 3: Module change operation comparison

The upgrade protocol in [9, 10] was evaluated for the following metrics:

• Time to complete operation: Varies with the size of the network. Average of 1 minute. In contrast, the entire setup of DCA lasted only for 20 seconds.

• Downtime: The sensor is out of normal operation for up to 10 seconds during

the upgrade process from the experimental observation. However, the DCA application was successful in implementing the

module change without affecting the sensor operation.


Discussion of Results

1. A DCA scheme can be effectively implemented and tested using any TinyOS application.

2. The energy consumption is linear and increases steadily with time.

3. The operation of the sensor application remains unaffected.

4. The time to completion for DCA is lesser than that for upgrade protocols [9,10].


Conclusions

• A new scheme (DCA) has been developed Allows the user to bypass the static programming

requirement in TinyOS platform

Allows control over the application features, during the operation of the sensor network

• The results indicate that the DCA mechanism was found to be more time saving: in the order of few milliseconds compared to several seconds to minutes required for

implementing similar changes via upgrade protocols


Future Work

• In this thesis, losses were constant, depending on the network size, and irrespective of node spacing (2 -20 feet) in the experiments (this research and in [10])

Efficient node loss determination with lossy network setup

Simulations could be performed around the maximum sensor range of 500 feet

• Could be combined with upgrades to analyze the overall performance in terms of losses, time to completion and sensor downtime


References (Slide 1 of 4)

[1] P.E. ROSS, "Waiting and Waiting For the Next Killer Wave", IEEE Spectrum. Volume 42, Issue 3, Page 17.

[2] TinyOS Tutorial, Available: http://www.tinyos.net/tinyos-1.x/doc/tutorial/.

[3] Anna Hać, “Wireless Sensor Network Designs”, John Wiley and Sons Ltd. 2003, Pages 325-352

[4] Lui Sha, “Using Simplicity to Control Complexity”, IEEE SOFTWARE, July / August 2001.



[5] P.V. Krishnan, L. Sha, K. Mechitov, “Reliable Upgrade Of Group Communication Software In Sensor Networks”, Proceedings of the First IEEE International Workshop on Sensor Network Protocols and Applications, May 2003.

[6] Chalermek Intanagonwiwat, Ramesh Govindan, Deborah Estrin, John Heidemann, and Fabio Silva, “Directed Diffusion for Wireless Sensor Networking”, IEEE/ACM Transactions on Networking, VOL. 11, NO. 1, February 2003.

[7] Thanos Stathopoulos, John Heidemann, Deborah Esterin, “A Remote Code Update Mechanism For Wireless Sensor Networks”, Available: http://lecs.cs.ucla.edu/~thanos/moap-draft.pdf



[8] Philip Levis, Nelson Lee, Matt Welsh, David Culler, "Platforms: TOSSIM: Accurate And Scalable Simulation Of Entire Tinyos Applications", Proceedings of the 1st international conference on Embedded networked sensor systems, November 2003.

[9] Jaein Jeong and David Culler, “Incremental Network Programming for Wireless Sensors”, IEEE SECON 2004, 2004 1st Annual IEEE Communications Society Conference on Sensor and Ad Hoc Communications and Networks, October 2004 Pages: 25-33.



[10] Adam Chlipala, Jonathan Hui and Gilman Tolle, “Deluge: Data Dissemination in Multi-Hop Sensor Networks,” UC Berkeley CS294-1 Project Report, December 2003, Avaliable: http://www.cs.berkeley.edu/˜jwhui/research/projects/deluge/deluge_poster.ppt


Acknowledgements

• Dr. Lazarou for motivating me to pursue research and training me to work aggressively on research issues

• Mr. Hannigan for his encouragement, support, and motivation both as an employer and as a friend

• My thesis committee members Dr. Chu and Dr. Philip for patiently reviewing my thesis in a short time. They also encouraged me in my course work and motivated me to attain higher grades

• Still searching for words to thank Arun Ramakrishnan, Ashwini Mani, and Gaurav Marwah. Their assistance in patiently reviewing several revisions of my thesis helped me a lot

• Thanks to Sai Bushan for helping me getting started and going with Python scripting

• Thanks to Shivakumar, Sridhar, Marshall Crocker, Sanjay Patil, Sai Bushan for assisting and motivating me towards my defense

• A special thanks to Aravindh Ravichandran, Ezhil Nachiappan and Ekta Mathur for their understanding and assistance.

• Worldwide TinyOS community for their timely support in various programming issues


Questions?

Sriram Rajan Master’s Thesis Presentation Advisor : Dr. Georgios Lazarou Department of Electrical...

Documents

Transcript of Sriram Rajan Master’s Thesis Presentation Advisor : Dr. Georgios Lazarou Department of Electrical...