Simulation of Sensor Network

Transcription

1 Simulation of Sensor Network The NS 2 & The nesc NS 2 based SensorSim & TOSSIM for Mote 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

2 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 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.

3 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 About the NS 2 NS 2 Network Simulator Project 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 Latest version is 2.29 Released on Oct 22, 2005 Features of NS 2 Discrete event simulator Packet level Object Oriented Link layer and up Wired and wireless Code developed in C++ and OTcl (object TCL)

4 The NS 2Get started 1. Download the lastest ns snapshot from: 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 Included in ns allinone package 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 Time: 1.5 sec Time: 1.7 sec 1 2 Time: 2.0 sec Time: 1.8 sec

5 Event Driven Simulation Event Queue TX Pkt 1.5sec RX Pkt 1.7sec TX Pkt 1.5sec RX Ack 2.0sec Node 1 Module Simulation Finished! TX Ack 1.8sec RX Ack 2.0sec RX Pkt 1.7sec TX Ack 1.8sec Node 2 Module 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

6 Features of NS 2 (2/5) 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 used 1) to create base classes 2) when more processing is required (routing table computation, mobility movement, ) Features of NS 2 (3/5) C++ codes Fast to run, slower to change Protocol implementation Packet processing OTCL codes Slower to run, fast to change Configuration Manipulate existing C++ object

7 Features of NS 2 (4/5) OTcl and C++: The Duality Pure C++ objects Pure OTcl objects C++ C++/OTcl split objects OTcl ns -There were computers in Biblical times. Eve had an Apple. Features of NS 2 (5/5) 1. Applications: CBR, HTML, TELNET, FTP, 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 Satellite constellations Sensor Network (diffusion, gaf) Mobile IPv4 (without routing optimization)

8 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. NS 2 Environment Simulation Scenario 1 2 set ns_ [new Simulator] Tcl Script set node_(0) [$ns_ node] set node_(1) [$ns_ node] C++ Implementation class MobileNode : public Node { friend class PositionHandler; public: MobileNode();

9 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 Mobile Node Modules (2/2) 1. Mac Layer IEEE 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/r 2 ) at near distance and Two ray ground (1/r 4 ) 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

10 Wireless Simulation (1/2) Wireless Simulation in ns 2 (Mobile Node Diagram DSDV) Port Demux Agent (Src/Sink) Addr Demux RTagent (DSDV) LL ARP IFq MAC Radio Propagation Model NetIF Channel Wireless Simulation (2/2) Wireless Simulation in ns 2 (Mobile Node Diagram DSR) Port Demux Agent (Src/Sink) DSR LL ARP IFq MAC Radio Propagation Model NetIF Channel

11 NS 2 Mobile node Schematic endtry_ addr demux IP address port demux 255 Src/Sink Rtagent (DSDV, AODV, LGR) defaulttarget_ uptarget_ target_ LL arptable_ ARP dwontarget_ IFq dwontarget_ mac_ MAC uptarget_ downtarget_ uptarget_ propagation_ Radio NetIF Propagation Model Channel_ uptarget_ Channel NS 2 데이터패킷전달 (Send) endtry_ addr demux IP address port demux 255 Src/Sink Rtagent (DSDV, AODV, LGR) defaulttarget_ uptarget_ target_ LL arptable_ ARP dwontarget_ IFq dwontarget_ mac_ MAC uptarget_ downtarget_ uptarget_ propagation_ Radio NetIF Propagation Model Channel_ uptarget_ Channel

12 NS 2 데이터패킷전달 (Receive) endtry_ addr demux IP address port demux 255 Src/Sink Rtagent (DSDV, AODV, LGR) defaulttarget_ uptarget_ target_ LL arptable_ ARP dwontarget_ IFq dwontarget_ mac_ MAC uptarget_ downtarget_ uptarget_ propagation_ Radio NetIF Propagation Model Channel_ uptarget_ Channel NS 2 라우팅패킷 (Send) endtry_ addr demux IP address port demux 255 Src/Sink Rtagent (DSDV, AODV, LGR) defaulttarget_ uptarget_ target_ LL arptable_ ARP dwontarget_ IFq dwontarget_ mac_ MAC uptarget_ downtarget_ uptarget_ propagation_ Radio NetIF Propagation Model Channel_ uptarget_ Channel

13 NS 2 라우팅패킷 (Receive) endtry_ addr demux IP address port demux 255 Src/Sink Rtagent (DSDV, AODV, LGR) defaulttarget_ uptarget_ target_ LL arptable_ ARP dwontarget_ IFq dwontarget_ mac_ MAC uptarget_ downtarget_ uptarget_ propagation_ Radio NetIF Propagation Model Channel_ uptarget_ Channel NS 2 Primer 사용예제 (Hello World 작성하기 )

14 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% 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%

15 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 Basic OTcl Class Mom Mom instproc greet { { $self instvar age_ puts $age_ years old mom: How are you doing? Class Kid superclass Mom Kid instproc greet { { $self instvar age_ puts $age_ years old kid: What s up, dude? set mom [new Mom] $mom set age_ 45 set kid [new Kid] $kid set age_ 15 $mom greet $kid greet

16 Get Help 1. Main ns 2 web pages bonn.de/~greis/ns/ns.html 2. Mailing lists ns users@mash.cs.berkeley.edu ns announce@mash.cs.berkeley.edu 3. To subscribe majordomo@mash.cs.berkeley.edu 4. Ask your classmates because ns is popular Who Committed the Code 1. CMU 2. UC Berkeley 3. Sun Microsystem Inc. 4. USC/ISI

17 NS 2 based SensorSim Abstract the Real Mobile World into your Simulation 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 A Mobile Node Abstraction 1. Location Coordinates (x,y,z) 2. Movement Speed, Direction, Starting/Ending Location, Time Forwarding 4. Network stack for channel access IEEE

18 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) SensorSim Architecture (1/4) monitor and control hybrid network (local or remote) real sensor apps on virtual sensor nodes app GUI app app socket comm serial comm GUI Interface HS Interface V V V R V R modified event scheduler ns Ethernet gateway Gateway Machine RS232 Simulation Machine Proxies for real sensor nodes

19 SensorSim Architecture (2/4) Sensor Node Sensor Node User Node Wireless Channel Sensor Node Functional Model Wireless Channel SensorWare Sensor Stack3 Network Stack Sensor Stack2 Layer Network Layer Sensor Layer Sensor Stack1 Physical Layer MAC Layer Sensor Physical Layer Layer Physical Layer Sensor App Physical Layer Sensor Channel3 Sensor Channel2 Sensor Node Power Model Battery Model Radio CPU ADC (Sensor) Sensor Channel1 Target Node Sensor Channel SesnorSim based on ns 2 SensorSim Architecture (3/4) User Node User Application Network Stack Network Layer MAC Layer Physical Layer User Node Wireless Channel Sensor Node Wireless Channel Sensor Node Sensor Node Target Node Sensor Channel SesnorSim based on ns-2

20 SensorSim Architecture (4/4) User Node Wireless Channel Sensor Node Sensor Node Sensor Node Target Node Sensor Channel Target Node Target Application Sensor Stack Sensor Layer SesnorSim based on ns-2 Physical Layer Sensor Channel Sensor Node Model in SensorSim Node Function Model Micro Sensor Node Applications Network Protocol Stack Middleware Sensor Protocol Stack State Change Power Model (Energy Consumers and Providers) Radio Model Network Layer Sensor Layer CPU Model MAC Layer Physical Layer Status Check Sensor #1 Model Battery Model Physical Layer Sensor #2 Model Wireless Channel Sensor Channel

21 Implementing Mobile Node Implementing mobile node by Extending standard NS node Node Classifier:Forwarding Agent: Protocol Entity Routing Node Entry LL ARP LL LL:Link layer object IFQ:Interface queue MAC PHY Radio Propagation Model MAC MAC:Mac object MobileNode PHY PHY:Net interface CHANNEL Extending NS Packet Format Extending NS Packet Format to support wireless simulation header data Example: Get the pointer to the Mac header: p >access(hdr_mac::offset_); Source: ns 2/mac.cc cmn header ip header... LL MAC 802_11 ARP... ts_ ptype_ uid_ size_ iface_

22 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 Battery Model Energy Provider Radio Model CPU Model Geophone Model Microphone Model Energy Consumers operating voltage and power drained Efficiency % Discharge Current Ratio Radio Model k bit packet Transmit Electronics Tx Amplifier E tx_elec *k ε amp *k*d n d Example Values: E elec = 50nJ/bit ε amp = 100pJ/bit/m 2 k bit packet Receive Electronics E rx_elec *k

23 Power Model State Transceiver Amplifier Total Transmit ON(.925W) ON(.5W) 1.425W Receive ON(.925W) OFF(0W).925W Idle ON(.925W) OFF(0W).925W Sleep, Off OFF(0W) OFF(0W) 0W * Values Obtained from WaveLAN NIC Specs 1. An efficient power management scheme would enable the radio to go to sleep for some time period, thus conserving power resources. Power Management Example Case 1 Case 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

24 Power Management Model BZR event Off BZR event BZR event Transmit Off transmit BZR event BZR event Receive Transmit transmit done transmit Idle BZR event receive done Receive transmit Sleep transmit done timeout Idle timeout(3 sec) receive done receive Without Power Management With Power Management 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

25 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! 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 Simulator Workstation Gateway Machine Real App. x App. x App. y App. x Header Conversion socket comm serial comm RS232 gateway Agent Proxy Routing Routing MAC MAC Wireless Channel Node with Seismic Sensor Sensor Reports are transmitted to the applications running on the simulated nodes

26 Real Application Support 1. An example of real application support (implementation for Tcl scripts) 2. Applications use are synchronized through the simulator virtual clock UNIX process ns-2 environment Sensor Model Sensor Agent DSR Custom Routing Custom MAC INJECT( ) Free Thread Pool main() RX State Information Spawned Threads ( ) ( ) ( ) TX NetIf wireless channel Socket Connections Execution Environment 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 initiator Initiator Node 12

27 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. 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

28 Assembling Components Applications are Written by 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 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)

29 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) 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

30 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: interface Clock { command result_t setrate (char interval, char scale); event result_t fired (); Clock.nc 4. Interface provider must implement commands 5. Interface user must implement events Interface Example 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(); 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)

31 Split phase Interfaces 1. Operation request and completion are separate functions: 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 2. No blocking operations because tasks execute nonpreemptively 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

32 Parameterized Interfaces All boxes are components 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() {...

33 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 calls Application: linking/gluing interfaces (events, commands) Modules (2/4) 1. Module declaration Provides Uses 1) Which interfaces will be implemented by this module 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

34 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 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

35 Components and Interfaces Provides interfaces (multiple interfaces) (bi directional) Component Uses Interfaces (multiple interfaces) (bidirectional) Configurations 1. Wire components together (An application must connect a Main component to other components) 2. Connected elements must be compatible (interface interface, commandcommand, event event) 3. 3 wiring statements in nesc: endpoint1 = endpoint2 endpoint1 endpoint2 endpoint1 endpoint2 (equivalent: endpoint2 endpoint1)

36 Configuration Example 1. Blink application 2. Wiring Example BlinkC configuration BlinkC { implementation { components Main, BlinkM, ClockC, LedsC; Main.StdControl >BlinkM.StdControl; BlinkM.Clock >ClockC; BlinkM.Leds >LedsC; BlinkC.nc Configuration Main.StdControl > BlinkM.StdControl Component Interface Component Interface Implementation USES PROVIDES

37 Equals Sign A: provides I But A does not implement I but uses what is provided by B Hence A = B B: provides I Often used for hierarchical Configuration files see Example later Concurrency Model 1. Underlying execution model (TinyOS) Tasks and Events Split phase operation

38 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 Tasks Example Non preemptive

39 Event Example 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

40 Race Conditions 1. Solutions Access shared data exclusively within tasks Have all accesses within atomic statements 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

41 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 interrupt context 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) nesc model 1. The nesc model: Interfaces: 1) uses 2) provides Components: 1) modules 2) configurations 2. Application:= graph of components

42 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: TOSSIM for Mote Features 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.

43 TOSSIM Architecture Frames, Events, Models, Components, and Services 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

44 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 simulated seconds for 1000 motes takes minutes (depends on level of optimization, debugging symbols, etc.) 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

45 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 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

46 Simulation Time 1. Time at mote instruction cycle frequency 2. 4 MHz = 4 x 10 6 ticks/second 3. e.g. 400 ticks between 10Kb radio interrupts 4. Chosen as minimum value that allows accurate radio and system clock modeling 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

47 Communication Services 1. Allows user to drive, monitor, debug simulation 2. Command/event interface 3. Eg. TinyViz 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.

48 Evaluation 1. Scalability CntToLeds RfmToLeds CntToRfm 2. Completeness Surge TinyDB 3. Fidelity radio noise packet interactions subtle race conditions 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

49 TOSSIM Capabilities 1. Simulates large mote networks under Linux 2. Uses existing TinyOS code (different compilation) 3. Extensible network model 4. Logs network activity 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

50 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] 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

51 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 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)

52 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 ff ff de ad be ef Dynamic Packet Injection 1. Connect to port on host 2. Message format detailed in documentation system/tossim/doc/tossim.tex 3. Will be building dynamic injection tool

53 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 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

54 References 1. TOSSIM: Accurate and Scalable Simulation of Entire TinyOS Applications Phil Levis,Nelson Lee,Matt Welsh UC Berkeley TOSSIM website : 4. EmTOS : Q & A 1. 경청해주셔서감사합니다. 2. Q & A