Multi-Paradigm Evaluation of Embedded Networked Wireless Systems

1

Multi-Paradigm Evaluation of Embedded Networked Wireless Systems

Rajive L. Bagrodia Professor

Computer Science Dept, UCLA [email protected]

DAWN PI Meeting,October 14, 2008

Joint work with Yi-Tao Wang and M.Varshney

mailto:[email protected]

2 DAWN Meeting Oct, 2008

Next Generation DOD NetworksNext Generation DOD Networks

Network Characteristics: Heterogeneous, Scalable, Mobile

3Computer Science

Department 3Design and Evaluation of Environmental Adaptive Wireless Systems

The Multi-Paradigm Evaluation Framework

Multi-Paradigm Testbed for Heterogeneous wireless networks

In-situ evaluation of applications, protocols or sub-networks

... in a high fidelity simulation environment

Simulated components: Radio, channel or complete sub-networks

3

QuickTime™ and aPNG decompressor

are needed to see this picture.

Application-centric

evaluation

Model heterogeneous

networks

Physical Emulation

Simulation


Embedded Networked Systems• Large class of embedded system are resource constrained

devices (e.g. sensors)• Important to capture the interactions between applications

and protocols with– Operating systems– Hardware– Other resources such as memory, CPU, clock drifts etc

• Typically part of heterogeneous networks• Emulation of embedded systems:

– Should capture the execution environment (OS & H/W)– Model environmental resources with high fidelity– Support heterogeneous networks (e.g. UAVs with UGS)


Current Tools

• Simulators (TOSSIM, EmTOS, etc)– Validates basic application behavior

– Lacks detailed simulation models• Restricts accuracy and expressiveness of their simulations• Cannot evaluate applications in deployment conditions

• Physical testbeds– Accurate

– Lacks spatial and temporal scalability

– Difficult to perform simulations under complex conditions

– Can’t repeat simulations


Our Target Heterogeneous Network

• Deploy TinyOS motes to replace aging SOS motes

• Must ensure:– TinyOS motes can

co-exist with SOS motes

– Maintain the network as SOS motes die off

• Impossible to model using existing tools– Too complex for current simulators

– Too large for physical testbeds


Outline

• Motivation

• Related approaches

• OS emulation

• SOS emulation via SenQ

• TinyOS emulation via TinyQ

• Heterogeneous network evaluation


Need for Operating System Emulation

Destination

Sender

Sleep Duration

(1024 ms)

Case Study: SMAC Mac Protocol

Wakeup Duration(300 ms)

Timer 1:backoff=rand(0,63

ms)

Timer 2:300-backoff ms

Protocol Implemented as:a) Pure simulation modelb) Emulation with SOS operating system

9 DAWN Meeting Oct, 2008 9

Emulation vs. Simulation

9

•Diagnosis: sleep schedule fall out of synchronization

•Backoff timer <10ms will expire at 10ms

•Timeouts > 250ms broken down in chunks of 250ms

10 DAWN Meeting Oct, 2008 1

0

Culprit: OS Timer Management

10

Set timer for 7ms

t

Timer Expire;Tx packet,

set timer for 293ms

t+7

Timer Expire;Set timer for 1024 ms,

Sleep

t+300

t+10 t+303

Set timer for 7ms

t

SOS minimum timer latency = 10ms

Skew = 3ms!!

256ms = 250ms timer + 6ms timerMax timer interval = 250ms

t+44 t+294

Set timer for 44ms

tSkew = 4ms!!

t+304

What actually happened....

What should have happened ...


OS Emulation Approaches

• Operating System emulation– Model the applications and protocol stack in context of the real

operating system– SenQ [msl.cs.ucla.edu/projects/senq]

• For TinyOS and SOS• Underlying QualNet network simulator• Support multi-tiered heterogeneous networks• High fidelity models for sensing channels, clock drifts, battery, power

consumption, CPU power– TOSSIM [www.cs.berkeley.edu/~pal/research/tossim.html]

• For SOS• Custom network simulator.• Logical connectivity, lack of multi-tiered networks and environmental

models


Emulation approaches (2)

• Hardware Emulation– Avrora [compilers.cs.ucla.edu/avrora]– Atemu [www.hynet.umd.edu/research/atemu]– Instruction cycle level emulation– Hardware resources modeled– (+) Highest fidelity for protocol emulation– (-) Slow execution time (much slower than real time)– (-) Lack scalability– (-) Lack of detailed models for channel and environment

– Good for small scale T&E (2-5 nodes) to be followed by OS level emulation (10-10000 nodes)


Computer ScienceDepartment 1

3

State-of-the-art•Network Simulators with sensor models

– SensorSim(2001), SWAN(2001)– (+) No need to migrate away from familiar platforms– (-) No emulation support

•Emulators with networking support – TOSSIM(2003), EmStar(2004), EmTOS(2004)– (+) Easy development-debugging-deployment cycle– (-) Discrete event simulation engine and channel models not

accurate– (-) Specific for given OS platform– (-) Does not support heterogeneous networks (IP, WiMAX etc)

•Instruction Cycle Emulation– Atemu(2004), Avrora(2005), Worldsens(2007)– (+) Greatest measure of software modeling fidelity– (-) Intractable for even moderate sized networks

13


SenQ Objectives• Ability to emulate sensor

applications & OS• Independent of underlying

sensor operating system• Integrate multiple sensor

OS in a single execution• Scalable to 10,000+ radios• Real-time or faster

execution• Support heterogeneous

networks• Flexible in configuring

scenarios

Sensing channel

Real implementations of TinyOS, SOS

Clock drift, Battery, Power consumption


SenQ Approach

Radio,Channel

Mobility

Parallel Sim.

IP Stack

WiMax Stack

Driver: H/W 2

Driver: H/W 1

Applications

OS

Protocols

Network Simulator

Sensor Node

Step 1

Step 2 Virtual Sensor Layer Driver: Virtual H/W Step 3

Process-orientedsimulation

Step 4

Battery

Clock

Sensing

ProcessorStep

5


SenQ Emulation: Key Features

• Sensor node appear as a “layer” in the discrete event network simulator (QualNet)

• Network simulator masquerades as “hardware platform” to sensor node

• Architecture supports any OS / multiple OS

• Efficient implementation: ~10,000 nodes

• Supports parallel emulation

• Supports modeling Heterogeneous Networks

17

SOS Emulation Results


• Clock = Oscillator + Counter + Zero-time

• Error in Oscillator ⇒ Clock Drift

– (Different definition of a second)

• f = fnom + ∆f0 + a.(t - t0) + ∆fn(t) + ∆fe(t)*

Clock Drift Models

Nominal frequency

Aging rate Environmental factor(temperature etc)Short term

variations(noise)

Long term variations

*White paper, Symmetricom


Case Study: Acoustic Sensing

tt+∆t1

t+∆t2

t+∆t3

∆t1

∆t2

∆t3

Algorithm Angle ϕ

ϕ


SenQ simulation study

• Benefits of SenQ–Easy configuration

–Repeatable execution

–Study tradeoffs

Clock drift: rand(0,5) μs/secSync. Protocol: RATSSync Beacon period: 2sec, 60sec

Variance: 0.64o 2.64o


Power Consumption Model• Inaccurate model of battery

– Reservoir of charge (U mA-sec)– Subtract, I (mA) * t (sec) from U after each event (Tx, Rx etc)

• Accurate model of battery– Non linear discharge– Recovery

– Model (Rakhmatov, 2002):

Ideal

Observed


Model Optimizations• Why the model does not

work?– Computationally expensive– Large memory requirement

• Optimizations– For small load magnitude and

intervals, found invariants that simplified the model

– Precompute the function in a lookup table (saves execution time)

– Merge multiple entries into one with a correction term (saves space)

Loss in accuracy < 0.1%


Impact of Processor Power Consumption

• Knowledge of power consumed by nodes in network is essential to avoid hot-spots or compare performance.

• Claim: power consumed by processor is substantial portion of total power consumed.

• Power consumed by processor is not a constant overhead.• It is state and context dependent but depends on what action is taken on

events

• Ignoring this component can predict incorrect trends or even inversion of results if only radio is considered


Processor Power Consumption

• Simulation– 49 node grid topology– 802.11b at 1Mbps– 600mA and 400mA for Tx and

Rx, resp– SA1100 processor at 133MHz.– 190.4mA/instruction– 3 CBR sessions between

random pairs.– Pre-computed routes

% Power consumed by processor

The ratio is not constant and depends on what role the node plays in simulation.


Incorrect Simulation Results

• Hot-spots are ignored (case 1 and 2) or mis-predicted (case 5).

• Relative % incorrectly predicted (Case 4, 6% vs. 21%).

• Inversion of results compared with simple model (cases 1, 3, 5).

• Summary– Processor power consumption is

significant contributor.– This overhead is not constant that can be

easily modeled.– Ignoring this component can predict

incorrect result.White bars: Power consumption by radio only (current simulators).

Black bars: Power consumption by both radio and processor (detailed model).


Incorrect Simulation Results

Summary– Processor power consumption is significant contributor.

– This overhead is not constant that can be easily modeled.

– Ignoring this component can predict incorrect result.


Emulation of TinyOS

• Override drivers to communicate with QualNet

• TinyOS applications think QualNet is just another hardware platform

• Hardware interactions (i.e., sending a packet) creates an event in QualNet

• Each mote runs in a separate thread


Accuracy of TinyQ

• Compared results from TinyQ to those from Harvard’s MoteLab– Application routes periodic packets from one sender to one receiver– Accurate wireless model provides identical results

94

95

96

97

98

99

100

2 6 10 14 18 22 26 30

Number of Motes

Avg. Packet Delivery Ratio (%)

MoteLab

TinyQ


Impact of Accurate Channel Models

• Multihop Oscilloscope: – Application distributed with TinyOS 2.x

– Route sensor readings to root mote using tree routing & CSMA MAC

– As node density increases MAC layer interference must decrease PDR


Performance of TinyQ (cont.)Application Description Execution Time (s)

TosSim TINYQBlink Blinks LEDs 0.52 1.19Blink Config Blinks LEDs 0.53 1.25DictionaryDemo Tracks reboots 0.64 1.28PriorityApp Tests pre-emption 0.53 1.15

Sense read and show sensor val 0.63 1.94

RadioCountToLedsincrement counter & broadcast 512.13 63.89

TestFTSP Imlement FTSP 723.59 73.64

Wwakkersync wake times among all nodes before sleeping 896.9 106.55

FreqHopListen on 2 freq and xmit on empty 578.64 66.02

RadioSenseTpLeds read & broadcast sensor val 624.63 57.96

PacketParrot log and rexmit incoming pkt 655.63 59.96

Oscilloscopeperiodically read & bcast sensor val 436.73 45.21

MultihopOscilloscope use tree routing to xmit 725.63 74.96


Performance of TinyQ

• Compared against TOSSIM using Blink (no radio)


Performance of TinyQ (cont.)

• Compared against TOSSIM using RadioCountToLeds (uses radio)


Performance of TinyQ (cont.)

• TinyQ was able to execute most applications that TOSSIM could

• Performs worse than TOSSIM on applications that don’t use the radio due to the extra emulation overhead

• Performs 10X better on applications that used the radio– TOSSIM uses a connectivity graph which leads to

thrashing when the network gets large

35

Heterogeneous Networks

Emulation of Heterogeneous networks


Case Study 1

OS: TinyOS/SOSStack: Surge/Tree routing/BMACRadio: 100kbps, 10s meter range

OS: Linux/WindowsStack: IP/AODV/802.11Radio: 802.11a/b

Sensors: OS Level EmulationWiFi: True Emulation Interoperable!


Heterogeneous Networks in SenQ

•Sensor subnet (1000 nodes)- SOS emulation, CC1100 radio model

• IP subnet (50 nodes)- QualNet simulation

- IP, AODV, UDP/TCP, 802.11 radio and MAC

•Gateway nodes (1-10 nodes)- Gateway batches K packets from sensors and then transmits

- SenQ support for interfacing diverse networks


Heterogeneous Networks in SenQ


Heterogeneous Network: Case Study 2

• Sensor network is emulated• IP network is simulated• Gateways are modeled as nodes with two network interfaces• 500 SOS nodes, 500 TinyOS nodes, 50 IP nodes spread randomly

over 400m x 400m terrain


Results: Heterogeneous Network

• TinyOS motes boot up at 30 simulation seconds

• SOS motes die between 40 and 60 simulation seconds


Results: Heterogeneous Network

• TinyOS application behaves correctly

• Also shows that 500 motes is not the optimum number of motes to cover area– Many motes are isolated

and cannot route to a gateway


Future Work

• Hybrid sensor network modeling (Yi-tao Wang)

•Integration of transport and vehicular comm network simulator (Yi Yang)

•Cross layer interactions between routing protocol and MAC interface using Multi-Paradigm Framework (Shrinivas Mohan)

Physical Emulation

Simulation

Multi-Paradigm Evaluation of Embedded Networked Wireless Systems

Documents

pi meeting

ugsdawn meeting

systemdawn meeting

simulationsdawn meeting

varshneydawn meeting

physical testbedsdawn

senqtinyos emulation

lack of multitiered