Simulation of Sensorpds4.egloos.com/pds/200702/23/35/07-simulation of... · ¾Physical activities are translated to events ¾Events are queued and processed in the order of their

Robot Sensor Networks

HanyangUniversity

Simulation of Sensor Network

The NS‐2 & The nesC

NS‐2 based SensorSim & TOSSIM for Mote


HanyangUniversity

Contents

1. Sensor Network Simulator

2. About the NS‐2

3. NS‐2 Primer

4. NS‐2 based SensorSim

5. About the nesC

6. TOSSIM for Mote


HanyangUniversity

Sensor Network Simulator

1. Sensor Network‐level Simulation Tools

Ns‐2 enhancements by ISI

Ns‐2 based SensorSim/SensorViz by UCLA

C++‐based LECSim by UCLA

PARSEC‐based NESLsim by UCLA

2. Node‐level Simulation Tools

MILAN by USC for WINS and μAMPS

ToS‐Sim for Motes

3. Processor‐level Simulation Tools

JoulesTrack by MIT


HanyangUniversity

Why Simulation ?

1. Helps in design improvements

2. Provides basis for real test‐bed deployment

3. Cost effective alternative

4. If anything goes wrong we can always go back to the drawing board.


HanyangUniversity

Sensor Networks & Simulation

1. Require large scale deployment ( smart dusts)

2. Deployed in remote & physically inaccessible places

3. Apps are deployed only once with little or no scope to re‐deploy (incase

of error) during the life time of the network devices

4. Early evaluation of the system is an integral part

5. Simulation can come quite handy in the early evaluation phase


HanyangUniversity

About the NS‐2

From the VINT (Virtual InterNet Testbed) project

Multi‐state collaboration

AT&T Research, Lawrence Berkeley National Laboratory (LBNL), UC

Berkeley, USC/ISI, Xerox PARC, ETH TIK

http://www.isi.edu/nsnam/ns/index.html

Latest version is 2.29 Released on Oct 22, 2005

NS‐2 Network Simulator Project

Discrete event simulator

Packet level

Object Oriented

Link layer and up

Wired and wireless

Code developed in C++ and OTcl (object TCL)

Features of NS‐2


HanyangUniversity

The NS‐2 Get started

1. Download the lastest ns snapshot from:

http://mash.cs.berkeley.edu/ns

2. Install ns in your system

Binary release is provided for windows 9x/NT

NS‐allinone package is strongly recommended

3. Download nam if visualization is needed

http://mash.cs.berkeley.edu/nam

Included in ns‐allinone package


HanyangUniversity

Introduction

1. ns‐2 is an discrete event driven simulation

Physical activities are translated to events

Events are queued and processed in the order of their scheduled occurrences

Time progresses as the events are processed

1 2

Time: 1.5 sec Time: 1.7 sec

Time: 1.8 secTime: 2.0 sec


HanyangUniversity

Event Driven Simulation

TX Pkt Event @ 1.5sec Node 1

Module

Node 2 Module

TX Pkt Ev

ent @

1.5secRX Pkt Event @

1.7sec

RX Pkt Event @ 1.7sec

TX Ack Event @ 1.8sec

TX Ack Event @ 1.8sec

RX Ack Event @ 2.0sec

RX Ack Ev

ent @

2.0sec

Event Queue

SimulationFinished!


HanyangUniversity

Features of NS‐2 (1/5)

1. Various modules were added to ns‐2 to simulate node mobility and

wireless networking

Mobile Node

MAC(802.11, 802.3, TDMA)

Radio Propagation Model

Channel

Multicast protocols, Satellite protocols, and many others

2. Codes are contributed from multiple research communities

Good: Large set of simulation modules

Bad: Level of support and documentation varies

3. The source code and documentation is currently maintained by VINT

project at ISI


HanyangUniversity


1. Code: C++ and Otcl

2. Otcl ‐ Object Tcl

interpreted language

does not require compilation

3. Each Class is mirrored both in C++ and OTCL

Object variables may alternatively be accessed from C++ or OTCL

Procedure calls between C++ and OTcl

4. OTCLmainly used:1) to aggregate objects to form various types of nodes

2) to access objects from the interpreter

3) to configure simulations

5. C++ mainly used1) to create base classes

2) when more processing is required (routing table computation, mobility movement, …)


HanyangUniversity


Fast to run, slower to change

Protocol implementation

Packet processing

C++ codes

Slower to run, fast to change

Configuration

Manipulate existing C++ object

OTCL codes


HanyangUniversity

C++ OTcl

Pure C++objects

Pure OTclobjects

C++/OTcl split objects

ns-There were computers in Biblical times. Eve had an Apple.

OTcl and C++: The Duality



HanyangUniversity


1. Applications:

CBR, HTML, TELNET, FTP, ...

2. Transport Protocols

UDP, TCP(reno, tahoe, vegas, sack), …

3. Routing Protocols

Unicast (static / dynamic)

Multicast (DVMRP, CBT)

4. Queue Models

5. Mobility

Local Mobility within a geographical area

Ad‐Hoc routing protocols (DSDV, DSR, AODV, TORA)

IEEE MAC 802.11

Satellite constellations

Sensor Network (diffusion, gaf)

Mobile IPv4 (without routing optimization)


HanyangUniversity

Why two languages? (Tcl & C++)

1. C++: Detailed protocol simulations require systems programming

language

byte manipulation, packet processing, algorithm implementation

Run time speed is important

Turn around time (run simulation, find bug, fix bug, recompile, re‐run) is

slower

Anything that requires processing each packet

Needs to change behavior of existing module

2. Tcl: Simulation of slightly varying parameters or configurations

quickly exploring a number of scenarios

iteration time (change the model and re‐run) is more important

Simple Configuration, Setup, Scenario

If it’s something that can be done without modifying existing Tcl module.


HanyangUniversity

NS‐2 Environment

Simulation Scenario

Tcl Script

C++ Implementation

1 2

set ns_ [new Simulator]

set node_(0) [$ns_ node]

set node_(1) [$ns_ node]

class MobileNode : public Node {

friend class PositionHandler;public:

MobileNode();••

}


HanyangUniversity

Mobile Node Modules (1/2)

1. Agent

Responsible for packet generations and receptions

Can think of it as an Application layer

CBR(Constant Bit Rate), TCP, Sink, FTP, etc.

2. RTagent(DSDV, TORA, AODV) or DSR

Ad‐hoc network routing protocols

Configure multi hop routes for packets

3. LL (Link Layer)

Runs data link protocols

Fragmentation and reassembly of packet

Runs Address Resolution Protocol(ARP) to resolve IP address to MAC

address conversions

4. IFq (Interface Queue)

PriQueue is implemented to give priority to routing protocol packets

Supports filter to remove packets destined to specific address


HanyangUniversity

Mobile Node Modules (2/2)

1. Mac Layer

IEEE 802.11 protocol is implemented

Uses RTS/CTS/DATA/ACK pattern for all unicast pkts and DATA for

broadcast pkts

2. NetIF (Network Interfaces)

Hardware interface used by mobilenode to access the channel

Simulates signal integrity, collision, tx error

Mark each transmitted packet with transmission power, wavelength etc.

3. Radio Propagation Model

Uses Friss‐space attenuation(1/r2) at near distance and Two ray ground (1/r4)

at far distance

Decides whether the packet can be received by the mobilenode with given

distance, transmit power and wavelength

Implements Omni Directional Antenna module which has unity gain for all

direction


HanyangUniversity

Wireless Simulation (1/2)

Agent(Src/Sink)

Po

rtD

em

ux

LL

IFq

MAC

NetIFRadio

PropagationModel

Channel

ARP

Ad

dr

De

mu

x

RTagent(DSDV)

Wireless Simulation in ns‐2 (Mobile Node Diagram ‐ DSDV)


HanyangUniversity

Agent(Src/Sink)

Po

rtD

em

ux

DSR

LL

IFq

MAC

NetIFRadio

PropagationModel

Channel

ARP

Wireless Simulation in ns‐2 (Mobile Node Diagram ‐ DSR)

Wireless Simulation (2/2)


HanyangUniversity

NS‐2 Mobile node Schematic

NetIF

MAC

IFq

LL

Rtagent (DSDV, AODV, LGR)

Src/Sink

ARP

NetIFRadioPropagationModel Channel_ uptarget_

Channel

uptarget_

uptarget_mac_

dwontarget_

dwontarget_

uptarget_

addrdemux

portdemux

endtry_

defaulttarget_

IP address255

target_arptable_

downtarget_

propagation_


HanyangUniversity

NS‐2 데이터패킷전달 (Send)

NetIF

MAC

IFq

LL

Src/Sink

ARP


Channel

uptarget_

uptarget_mac_

dwontarget_

dwontarget_

uptarget_

addrdemux

portdemux

endtry_

defaulttarget_

IP address255

target_arptable_

downtarget_

propagation_



HanyangUniversity

NS‐2 데이터패킷전달 (Receive)

NetIF

MAC

IFq

LL

Src/Sink

ARP


Channel

uptarget_

uptarget_mac_

dwontarget_

dwontarget_

uptarget_

addrdemux

portdemux

endtry_

defaulttarget_

IP address255

target_arptable_

downtarget_

propagation_



HanyangUniversity

NS‐2 라우팅패킷 (Send)

NetIF

MAC

IFq

LL

Src/Sink

ARP


Channel

uptarget_

uptarget_mac_

dwontarget_

dwontarget_

uptarget_

addrdemux

portdemux

endtry_

defaulttarget_

IP address255

target_arptable_

downtarget_

propagation_



HanyangUniversity

NS‐2 라우팅패킷 (Receive)

NetIF

MAC

IFq

LL

Src/Sink

ARP


Channel

uptarget_

uptarget_mac_

dwontarget_

dwontarget_

uptarget_

addrdemux

portdemux

endtry_

defaulttarget_

IP address255

target_arptable_

downtarget_

propagation_



HanyangUniversity

NS‐2 Primer

사용예제 (Hello World 작성하기)


HanyangUniversity

Hello World ‐ Interactive Mode

<prompt> % ns

% set ns [new Simulator]

_o3

% $ns at 1 “puts \“Hello World!\””

1

% $ns at 1.5 “exit”

2

% $ns run

Hello World!

<prompt> 72%


HanyangUniversity

Hello World ‐ Batch Mode

simple.tcl

set ns [new Simulator]

$ns at 1 “puts \“Hello World!\””

$ns at 1.5 “exit”

$ns run

<prompt> 74% ns simple.tcl

Hello World!

<prompt> 75%


HanyangUniversity

Basic tcl

set a 43

set b 27

proc test { a b } {

set c [expr $a + $b]

set d [expr [expr $a ‐ $b] * $c]

for {set k 0} {$k < 10} {incr k} {

if {$k < 5} {

puts “k < 5, pow = [expr pow($d, $k)]”

} else {

puts “k >= 5, mod = [expr $d % $k]”

}

}

}

test 43 27


HanyangUniversity

Basic OTcl

ClassMom

Mom instproc greet {} {

$self instvar age_

puts “$age_ years old mom: How are you doing?”

}

Class Kid ‐superclassMom

Kid instproc greet {} {

$self instvar age_

puts “$age_ years old kid: What’s up, dude?”

}

setmom [newMom]

$mom set age_ 45

set kid [new Kid]

$kid set age_ 15

$mom greet

$kid greet


HanyangUniversity

Get Help

1. Main ns‐2 web pages

http://titan.cs.uni‐bonn.de/~greis/ns/ns.html

http://mash.cs.berkeley.edu/ns

2. Mailing lists

ns‐[email protected]

ns‐[email protected]

3. To subscribe

[email protected]

4. Ask your classmates because ns is popular


HanyangUniversity

Who Committed the Code

1. CMU

2. UC Berkeley

3. Sun Microsystem Inc.

4. USC/ISI


HanyangUniversity

NS‐2 based SensorSim

1. Node

2. Packets

3. Wireless channel and channel access

4. Forwarding and routing

5. Radio propagation model

6. Trace/Visualization

7. Event scheduler to make everything running

Abstract the Real Mobile World into your Simulation


HanyangUniversity

A Mobile Node Abstraction

1. Location

Coordinates (x,y,z)

2. Movement

Speed, Direction, Starting/Ending Location, Time ...

3. Forwarding

4. Network stack for channel access

IEEE 802.11


HanyangUniversity

Why SensorSim?

1. Besides wireless communication, a sensor network simulator requires

Power models

Sensor channel models

1) Sensor functional models

2) Sensor events

3) Target Models

2. SensorSim builds up on ns‐2 and provides

Power Modeling (battery and radio)

Hybrid Simulation (real application support, interaction with real sensor nodes)


HanyangUniversity

SensorSim Architecture (1/4)

monitor and controlhybrid network

(local or remote)

Simulation Machine

Gateway Machine

ns

modified event scheduler

VR

V

VV

GUI appapp

R

real sensor apps onvirtual sensor nodes

gateway

socketcomm

serialcomm

HS InterfaceEthernet RS232

Proxies for realsensor nodes

GUI Interface

app


HanyangUniversity


Sensor Layer

Physical Layer

Sensor Stack3

Sensor Layer

Physical Layer

Sensor Stack2

Functional Model Sensor Node

SensorWarePower Model

Battery Model

Radio

CPU

ADC(Sensor)

Wireless Channel

Sensor Channel1

Network Layer

MAC Layer

Physical Layer

Network Stack

Sensor Layer

Physical Layer

Sensor Stack1

Sensor App

Sensor Channel2

Sensor Channel3Sensor Node

Sensor Node

Sensor Node

WirelessChannel

SensorChannel

UserNode

TargetNode

• SesnorSim based on ns‐2


HanyangUniversity


Wireless Channel

User ApplicationUser Node

Network Layer

Physical Layer

Network Stack

MAC Layer

Sensor Node

Sensor Node

Sensor Node

WirelessChannel

SensorChannel

UserNode

TargetNode

• SesnorSim based on ns-2


HanyangUniversity


Target Node Sensor Layer

Physical Layer

Sensor Stack

Sensor Channel

Target Application

Sensor Node

Sensor Node

Sensor Node

WirelessChannel

SensorChannel

UserNode

TargetNode

• SesnorSim based on ns-2


HanyangUniversity

Sensor Node Model in SensorSim

Node Function Model

Network Layer

Micro Sensor Node

Applications

Power Model(Energy Consumers and Providers)

Battery Model

Radio Model

CPU Model

Sensor #1 Model

Sensor #2 Model

MAC Layer

Physical Layer

Sensor Layer

Wireless Channel Sensor Channel

NetworkProtocol Stack

SensorProtocol Stack

Middleware

Physical Layer

State Change

StatusCheck


HanyangUniversity

Implementing Mobile Node

Classifier:Forwarding

Agent: Protocol Entity

Node Entry

Node

ARP

Radio Propagation Model

MobileNode

LL

MAC

PHY

LL

CHANNEL

LL

MAC

LL:Link layer object

IFQ:Interface queue

MAC:Mac object

PHY PHY:Net interface

Routing

Implementing mobile node by Extending “standard” NS node


HanyangUniversity

Extending NS Packet Format

header

data

ip header

……...

cmn headerts_

ptype_

uid_

size_

iface_

LL

MAC 802_11

……...

ARP

Example: Get the pointer to the Mac header:

p‐>access(hdr_mac::offset_);

Source: ns‐2/mac.cc

Extending NS Packet Format to support wireless simulation


HanyangUniversity

Battery Model

1. Ideally battery capacity is

decided by the amount of

active material stored in a cell

2. In reality, this depends on

how the battery is discharged

discharge rate

discharge profile

operating voltage and power

drained

Microphone Model

Geophone Model

CPU Model

Radio Model

•••

Energy Provider

Energy Consumers

Battery Model

Eff

icie

ncy

%

Discharge Current Ratio

100

0

50

1 2 3 4


HanyangUniversity

Radio Model

Example Values:

Eelec= 50nJ/bit

εamp= 100pJ/bit/m2

TransmitElectronics

Tx Amplifierk bit packet

Etx_elec*k εamp*k*dn

Receive Electronics

Erx_elec*k

k bit packet

d


HanyangUniversity

Power Model

1. An efficient power management scheme would enable the radio to go

to sleep for some time period, thus conserving power resources.

0WOFF(0W)OFF(0W)Sleep, Off

.925WOFF(0W)ON(.925W)Idle

.925WOFF(0W)ON(.925W)Receive

1.425WON(.5W)ON(.925W)Transmit

TotalAmplifierTransceiverState

*Values Obtained from WaveLAN NIC Specs


HanyangUniversity

Power Management Example

1. Using a 2Mbps WaveLAN NIC model in ns‐2

2. Dynamic Source Routing (DSR)

3. Case 1: node 0 transmits 512 byte packets every 2s to node 3 for 500s

4. Case 2: nodes 0, 6, 1 continually transmit to nodes 3, 4, 2

5. MAC Layer is responsible for the power control

4

12

3

0

5 6

Case 2

Case 1


HanyangUniversity

Power Management Model

Transmit Receive

Off

Idle

BZR event

BZR event

BZR event

receive done

transmit

transmitdone

Without Power Management

Transmit Receive

Sleep

Off

Idletransmit

timeout(3 sec)

BZR event

BZR event

transmit

transmitdone

BZR event

receivedone

receivetimeout

With Power Management


HanyangUniversity

Hybrid Simulation

1. Real application support

The same applications that run on the real nodes can also run on the

simulated nodes

2. Interaction with real nodes

Real sensor nodes can participate in the simulation

3. Advantages

Enables the use of real traffic from the sensor channel that is currently not

well understood and the models are not yet mature

Validate protocols and applications running on the real nodes by being

able to test these applications in large networks

Study the behavior of sensor network protocols and applications at scale


HanyangUniversity

Hybrid Simulation Challenges

1. Virtual Time Synchronization between ns and external entities

done between ns and external processes

2. Real and Virtual Time Synchronization

currently not done but exploring [Fall98]

only asynchronous applications on real nodes

3. Hybrid Modeling of Wireless Channel

collision between packets from real and virtual nodes

Open Problem !


HanyangUniversity

Interaction with Real Nodes

1. Real nodes are represented by proxies in the simulation

2. Real nodes can be placed anywhere in the simulation topology

MAC

Routing

Header Conversion

Wireless Channel

Proxy

MAC

Routing

Agent

App. y App. xApp. x

Gateway Machine

gateway

socketcomm

serialcomm

RS232

Simulator Workstation

Node withSeismic Sensor

Sensor Reports are transmitted to the applications running on the simulated nodes

Real App. x


HanyangUniversity

Real Application Support

1. An example of real application support (implementation for Tcl scripts)

2. Applications use are synchronized through the simulator virtual clock

Execution Environment

TXRX

main()

( )

( )

( )

Free Thread Pool

Spawned Threads

INJECT( )

State Information

Socket Connections

Sensor Model

802.11

DSR

NetIf

UNIX process

wireless channel

SensorAgent

CustomRouting

ns-2 environment

CustomMAC


HanyangUniversity

Example of Real Application Support

1. Tcl based application for finding the node with the minimum

battery level

Runs on real nodes as well as simulated nodes

Centralized Version

1) Each node is queried from the initiator

Distributed Version

1) Using mobile scripts

2) Results are collected at intermediate nodes and then delivered to the initiator1 2

3

4 56

789

13

0 10 11

12

Initiator Node


HanyangUniversity

SensorSim Problems

1. Still at pre‐release stage.

2. No Documentation.

3. The software currently has a very specific application hard‐coded.

4. It caters to only one base station.


HanyangUniversity

About the nesC

1. Dialect of C with support for components

Components provide and use interfaces

Create application by wiring together components using configurations

2. Whole‐program compilation and analysis

nesC compiles entire application into a single C file

Compiled to mote binary by back‐end C compiler (e.g., gcc)

Allows aggressive cross‐component inlining

Static race condition detection

3. nesC is a ‘static’ language

No function pointers (makes whole‐program analysis difficult)

No dynamic memory allocation

No dynamic component instantiation/destruction


HanyangUniversity

Assembling Components

1. Anatomy of a component

Interfaces

Implementation

Default handlers

2. Anatomy of an application

Main component for initialization, start,

Connected graph of components

Applications are Written by Assembling Components


HanyangUniversity

nesC

1. nesC application

1 or more components

Wire them together

Must have a MAIN component

2. Interfaces

3. Modules (implement your code)

4. Configurations (the wiring)


HanyangUniversity

Interfaces

1. Declare commands (implementer of this interface must implement these

commands)

2. Declare events (User of this interface, must implement these events ‐ call

back functions)


HanyangUniversity

Commands & Events

1. Commands:

deposit request parameters into the frame

are non‐blocking

need to return status .. postpone time consuming work by posting a task

can call lower level commands

2. events:

can call commands, signal events, post tasks, can not be signaled by

commands

preempt tasks, not vice‐versa

interrupt trigger the lowest level events

deposit the information into the frame


HanyangUniversity

Interfaces of Commands & Events

1. Define “public” methods that a component can use

2. Used for grouping functionality, like:

split‐phase operation (send, sendDone)

standard control interface (init, start, stop)

3. Describe bidirectional interaction:

4. Interface provider must implement commands

5. Interface user must implement events

interface Clock {

command result_t setRate (char interval, char scale);

event result_t fired ();

}

Clock.nc


HanyangUniversity

Interface Example

1. Interface is a type

2. Many instances of the interface may exist

3. A command or event in an interface is named i.f (Ex: Timer.start,

Timer.fired)

Timer.nc * filename for a bidirectional interface

interface Timer {

command result_t start (char type uint32_t interval);

command result_t stop();

event result_t fired();

}


HanyangUniversity

Split‐phase Interfaces

1. Operation request and completion are separate functions:

2. No blocking operations because tasks execute nonpreemptively

interface SendMsg {

command result_t send (uint16_t address, uint8_t length,

TOS_MsgPtr p);

event result_t sendDone (TOS_MsgPtr msg,

result_t success);

}

SendMsg.nc


HanyangUniversity

Parameterized Interfaces

1. Can associate a port with an interface, so that a provider can distinguish

users

2. Used because the provider doesn’t know how many users will be

connecting to it

module GenericCommM {

provides interface SendMsg [uint8_t id];

provides interface ReceiveMsg [uint8_t id];

…

}

implementation {…

}

GenericCommM.nc


HanyangUniversity

Parameterized Interfaces

All boxes are components


HanyangUniversity

nesC components

1. Two types of components

Modules contain implementation code

Configurations wire other components together

An application is defined with a single top‐level configuration

module TimerM {

provides {

interface StdControl;

interface Timer;

}

uses interface Clock;

}

implementation {

command result_t Timer.start(char type, uint32_t interval)

{ ...}

command result_t Timer.stop()

{ ... }

event void Clock.tick()

{ ... }

}


HanyangUniversity

Modules (1/4)

1. A module has:

Frame (internal state)

Tasks (computation)

Interface (events, commands)

2. Frame :

one per component

statically allocated

fixed size

Commands and Events are function callsApplication: linking/gluing interfaces (events, commands)


HanyangUniversity

Modules (2/4)

1. Module declaration

Provides

1) Which interfaces will be

implemented by this module

Uses

1) Which interfaces the module will

need to use

2. Module implementation

Interface methods implemented

1) All command for “provides” and

events for “uses”

module ExampleM {

provides {

interface StdControl;

}

uses {

interface Timer;

}

}

implementation {

...

command result_t StdControl.start(){

return call

Timer.start(TIMER_REPEAT,250);

}

...

event result_t Timer.fired(){

// do something

}

}


HanyangUniversity

Modules (3/4)

1. Calling commands and signaling

events

module TimerM {

provides interface StdControl;

provides interface Timer[uint8_t id];

uses interface Clock;…

}

implementation {

command result_t StdControl.stop() {

call Clock.setRate(TOS_I1PS, TOS_S1PS);

}

…

}

TimerM.nc


HanyangUniversity

Modules (4/4)

1. Tasks: a task is an independent

locus of control defined by a

function of storage class task

returning void and with no

arguments

2. Posting tasks: keyword post

module BlinkM {…

}

implementation {…

task void processing () {

if(state) call Leds.redOn();

else call Leds.redOff();

}

event result_t Timer.fired () {

state = !state;

post processing();

return SUCCESS;

}…

}

BlinkM.nc


HanyangUniversity

Components and Interfaces

Component

Provides interfaces(multiple interfaces)(bi‐directional)

Uses Interfaces(multiple interfaces)(bidirectional)


HanyangUniversity

Configurations

1. Wire components together (An application must connect a Main

component to other components)

2. Connected elements must be compatible (interface‐interface, command‐

command, event‐event)

3. 3 wiring statements in nesC:

endpoint1 = endpoint2

endpoint1 endpoint2

endpoint1 endpoint2 (equivalent: endpoint2 endpoint1)


HanyangUniversity

Configuration ‐ Example

1. Blink application

2. Wiring Example

configuration BlinkC {

}

implementation {

components Main, BlinkM, ClockC, LedsC;

Main.StdControl‐>BlinkM.StdControl;

BlinkM.Clock‐>ClockC;

BlinkM.Leds‐>LedsC;

}

BlinkC.nc

BlinkC


HanyangUniversity

Configuration

Main.StdControl ‐> BlinkM.StdControl

Component

Interface

Component

Interface Implementation

USES PROVIDES


HanyangUniversity

Equals Sign

A: provides I

B: provides I

But A does not implement I butuses what is provided by B

Hence A = B

Often used for hierarchical Configuration files – see Example later


HanyangUniversity

Concurrency Model

1. Underlying execution model (TinyOS)

Tasks and Events

Split phase operation


HanyangUniversity

Tasks and Events

1. Tasks

Deferred computation, Non‐preemptable by other tasks

Scheduled FCFS from task queue, When no tasks – CPU goes to sleep

Declare tasks with task keyword, Schedule tasks with post keyword

2. Events

Execution of an interrupt handler, Runs to completion

Can preempt tasks and can be preempted by other events

Declare events with event keyword (as part of interfaces)

Notify events with signal keyword

Signify completion of a split‐phase operation

1) Example: packet send via send command; then communication component will

signal send Done event when transmission is complete

2) Note: not all operations are split phase

Events from environment

1) Message reception

2) Clock firing


HanyangUniversity

Tasks Example

Non‐preemptive


HanyangUniversity

Event Example


HanyangUniversity

Split Phase

1. Because of the execution model, code should exist in small execution

pieces

2. Similar to asynchronous method calls

3. Separate initiation of method call from the return of the call

Call to split‐phase operation returns immediately

When work actually finishes the caller is notified via another method call


HanyangUniversity

Race Conditions

1. Solutions

Access shared data exclusively within tasks

Have all accesses within atomic statements


HanyangUniversity

Atomic Statements

bool busy; // gobal

.…

bool available;

….

atomic {

available = !busy;

busy = TRUE;

}

….

atomic busy = false;

nesC forbids calling commands or

signaling events in an atomic section


HanyangUniversity

Language features for concurrency

1. post

Puts a function on a task queue

Must be void foo(void)

void task do‐work() { //do something }

post do‐work();

2. atomic

Interrupts can preempt execution

Turn off interrupts with atomic{ }

E.g. to implement a semaphore

3. async

Use async to tell compiler that this code can be called from an interruptcontext – used to detect potential race conditions

4. norace

Use norace to tell compiler it was wrong about a race condition existing (the compiler usually suggests several false positives)


HanyangUniversity

nesC model

1. The nesC model:

Interfaces:

1) uses

2) provides

Components:

1) modules

2) configurations

2. Application:= graph of components


HanyangUniversity

Conclusion

1. Sensor networks raise a number of programming challenges

Much more restrictive than typical embedded systems

Reactive, concurrent programming model

2. nesC language features

“Components for free” – compile away overhead

Bidirectional interfaces

Lightweight, event‐driven concurrency

Static race condition detection

3. Efficient whole‐program optimization

Code size savings of 8% – 40% for a range of apps

Significant reduction in boundary crossing overhead

Inlining allows cross‐module optimizations

4. Code available for download at:

http://www.tinyos.net

http://nescc.sourceforge.net


HanyangUniversity

TOSSIM for Mote

1. A discrete event simulator

2. Utilizes TinyOS’s component based architecture

3. Integrates with TOS model by providing a new hardware resource

abstraction layer

4. TinyOS mote simulator

5. Scales to thousands of nodes

6. Compiles directly from TinyOS source

7. Simulates network at bit level

8. Replaces hardware with software components

9. Hardware interrupts are modeled as simulator events.

Features


HanyangUniversity

TOSSIM Architecture

Frames, Events, Models, Components, and Services


HanyangUniversity

Design Goals for TOSSIM

1. Scalability : able to handle large networks

2. Completeness : capture complete system behavior

3. Fidelity : Capture behavior at a fine‐grain

4. Bridging : the gap between algorithms and implementation


HanyangUniversity

Scalability

1. Individual mote resources very small

2. Static component memory model simplifies state management .

3. Smaller App footprint => smaller memory needed for simulation

4. Scales extremely well for network inactive applications .

5. Scales moderately for network intensive applications .

6. Tested with 1000 motes communicating over radio

7. 10 simulated seconds for 1000 motes takes 1.5‐3 minutes (depends on

level of optimization, debugging symbols, etc.)


HanyangUniversity

Completeness

1. Used Surge to evaluate completeness.

2. Surge requires complex interaction between TinyOS components.

3. TOSSIM help discover & debug some bugs in the Surge protocol

4. Previously, test‐bed instrumentation failed to figure out the bugs

5. TinDB group also used TOSSIM


HanyangUniversity

Fidelity

1. Emulating hardware at component level

2. Bit‐level simulation : capturing network at high fidelity

3. TOSSIM helped in debugging some TinyOS network, radio stack

problems

4. These problems were unnoticed during testbed deployment

5. Noticed as TOSSIM models radio at bit level –the most granular abstract

6. TOSSIM helped in debugging some TinyOS radio stack problems

7. These problems were unnoticed during testbed deployment

8. Noticed as TOSSIM models radio at bit level –the most granular abstract


HanyangUniversity

Bridging

1. ‘make sim’ instead of ‘make mica’

2. Instrumented nesC compiler

3. Compile application code to TOSSIM or hardware platform as needed

4. No change to application required

5. Tested code can be deployed right away


HanyangUniversity

Simulation Time

1. Time at mote instruction cycle frequency

2. 4 MHz = 4 x 106 ticks/second

3. e.g. 400 ticks between 10Kb radio interrupts

4. Chosen as minimum value that allows accurate radio and system clock

modeling


HanyangUniversity

Radio Models

1. Radio models external to TOSSIM

2. Models network as a directed graph of bit error probabilities.

3. Built‐in models : “Simple”,” Static”, “Space”


HanyangUniversity

Communication Services

1. Allows user to drive, monitor, debug simulation

2. Command/event interface

3. Eg. TinyViz


HanyangUniversity

Network Simulation

1. Most complex and fine grained component of TOSSIM

2. Almost perfect simulation of TinyOS networking stack at bit level

3. Combination of bit sampling and bit rate changes used for capturing the

entire stack.


HanyangUniversity

Evaluation

1. Scalability

CntToLeds

RfmToLeds

CntToRfm

2. Completeness

Surge

TinyDB

3. Fidelity

radio noise

packet interactions

subtle race conditions


HanyangUniversity

Possible Enhancements

1. CPU modeling : run‐instantly model

2. Energy modeling

3. Supporting thread based execution models

4. Supporting heterogeneous platforms

5. Allowing Different mote applications to run at once


HanyangUniversity

TOSSIM Capabilities

1. Simulates large mote networks under Linux

2. Uses existing TinyOS code (different compilation)

3. Extensible network model

4. Logs network activity


HanyangUniversity

Compiling TOSSIM

1. Similar makefile to FULLPC

2. Uses a few different component implementations

MAIN.c

RFM.c

POT.c

etc.

3. system/tossim

4. make –f MakefileTOS


HanyangUniversity

Running TOSSIM

1. A few command line parameters

2. main [OPTIONS] num_nodes

3. Network model: simple is default

[‐r <static|simple|space>]

4. Pause on system clock interrupts

[‐p usec]


HanyangUniversity

Debugging Output

1. dbg() commands in TinyOS source

2. Many dbg flags: DBG_SIM, DBG_RADIO, DBG_CLOCK, etc.

3. system/include/dbg_modes.h

4. > setenv DBG=route,boot,usr2


HanyangUniversity

External Communication

1. Tries to open sockets to listening servers at boot

Network packets

Network bits

Packet injection

2. Opens a server socket for dynamic network packet injection


HanyangUniversity

Network Traffic GUI

1. tools/TossimGUI.class

2. Reads in and displays network traffic

3. Allows packet source filtering

4. Static packet injection (at startup)


HanyangUniversity

Static Packet Injection

1. java TossimGUI [filename]

2. File contains packets to be received by nodes

3. <time> <moteID> <data0> <data1> … <data37>

4. tools/radio.txt

324122 2 ff ff 08 13 de ad be ef … 00 00 00 00


HanyangUniversity

Dynamic Packet Injection

1. Connect to port 10579 on host

2. Message format detailed in documentation

system/tossim/doc/tossim.tex

3. Will be building dynamic injection tool


HanyangUniversity

RFM Models

1. Simple: every mote in one cell

2. Static: connectivity determined at startup

3. Space: silly space‐based model which uses potentiometer settings: proof

of extensibility


HanyangUniversity

TOSSIM Internals

1. Based on tos4.2 TOSSIM (Culler)

2. Discrete event simulation

3. Models clock interrupts

4. Every event associated with specific mote

5. Array of mote structures

6. #define VAR(x) \ TOS_My_Frame[tos_state.current_node].x


HanyangUniversity

References

1. “TOSSIM: Accurate and Scalable Simulation of Entire TinyOS Applications” ‐ Phil Levis,Nelson Lee,Matt Welsh

2. www.tinyos.net

3. UC Berkeley TOSSIM website : www.cs.berkeley.edu/~pal/research/tossim.html

4. EmTOS :

http://lecs.cs.ucla.edu/~thanos/cs113EmTOS.ppt

5. http://webs.cs.berkeley.edu/weekly/simulator.ppt


HanyangUniversity

Q & A

1. 경청해주셔서감사합니다.

2. Q & A

Documents

Simulation of Sensorpds4.egloos.com/pds/200702/23/35/07-simulation of... · ¾Physical activities are translated to events ¾Events are queued and processed in the order of their