Shawn A new approach to simulating wireless sensor networks. Simulation Models. Components of a Discrete-Event Simulation.

Transcription

1 Shawn A new approach to simulating wireless sensor networks Christos Koninis Simulation Models Continuous model: the state variables change in a continuous way, and not abruptly from one state to another (infinite number of states). Continuous simulation concerns the modeling over time of a system by a representation in which state variables change continuously with respect to time. Typically, we use differential equations, that give relationships for the rates of change of the state variables with time. Simulation Models Components of a Discrete-Event Simulation Discrete model: the state variables change only at a countable number of points in time. These points in time are the ones at which the event occurs/change in state. Each event occurs at an instant in time and marks a change of state in the system The operation of a system is represented as a chronological sequence of events Clock keep track of the current simulation time The clock may operate in one of two manners: Time Slicing Advances the model by a fixed amount each time, regardless of the absence of any events to carry out. Next Event Advances the model to the next event to be executed, regardless of the time interval. So time moves from event to event.

2 Components of a Discrete-Event Simulation Events List The simulation maintains at least one list of simulation events. It lists events that are pending as a result of previously simulated event but have yet to be simulated themselves. An event is described by the time at which it occurs and a type, indicating the code that will be used to simulate that event. Random-Number Generators The simulation needs to generate random variables of various kinds, depending on the system model A simulation could be returned with exactly the same behaviour. Components of a Discrete-Event Simulation Statistics The simulation typically keeps track of the system's statistics, which quantify the aspects of interest Important in validating the model and for providing performance measures. Ending Condition Theoretically a discrete-event simulation could run forever, when we stop? At specific time T After processing N number of events Other conditions Simulation Engine Logic The main loop of a discrete-event simulation is something like this: Start Initialize Ending Condition to FALSE. Initialize system state variables. Initialize Clock (usually starts at simulation time zero). Schedule an initial event (i.e., put some initial event into the Events List). While (Ending Condition is FALSE) then do the following: Set clock to next event time. Do next event and remove from the Events List. Update statistics. Shawn - Design Goals Open-source (BSD License) discrete event simulator for WSN, written in C++ Support for development and testing of highlevel algorithms and distributed protocols Can simulate very lage networks (>100k of nodes) The simulators generally spend much processing time on results that are of no interest to the algorithm. simulation of physical phenomena such as radio signal propagation characteristics and ISO/OSI layer protocols, e.g., media access control (MAC).

3 Shawn - Design Goals Shawn Scalability and application domain One central approach of Shawn is to simulate the effect caused by a phenomenon, not the phenomenon itself. Shawn is replacing low-level effects with abstract and exchangeable models the simulation can be used for huge networks in reasonable time For example, instead of simulating a complete MAC layer including the radio propagation model, its effects (i.e., packet loss and corruption) are modeled in Shawn. Application area for a number of simulators Abstraction level simulation of physical phenomena Low level ISO/OSI layer protocols Algorithmic /application level Scalability number of network nodes Shawn Protocol Development cycle Centralize rapid prototype version First results and performance impression Simplified decentralized version Prove that it runs in a decentralized manner and that it produce valid results Fully distributed implementation Measure performance number of messages, energy consumption, runtime, resilience to message loss Shawn - Architecture Shawn's architecture comprises three major parts: Sequencer the central coordinating unit, it configures the simulation, executes tasks, controls the simulation. Models Control and effect the way nodes communicating Simulation Environment Holds the virtual world in which the simulated sensor nodes reside.

4 Shawn - Models Shawn - Communication Model Three models form the foundation of Shawn: Communication Model Edge Model Transmission Model Models control the behavior for a particular simulation task Shawn distinguishes between models and their respective implementations Simplified and fast implementation Or more close approximations to reality Shawn maintains a repository of many model implementations It provides methods invoked to determine whether a node B is in reach of the node A By implementing this interface with user-defined code, arbitrary communication patterns can be realized. Shawn ships with a set of different Communication Model implementations like UDG,Q-UDG,RIM Shawn - Communication Model UDG (Quasi-Unit Disk Graph ) Two nodes can communicate bidirectional if the Euclidean distance d between the nodes is less than rmax Q-UDG (Unit Disk Graph) For 0 < d < r1 and d > r2, the behavior is equivalent to the UDG Model. For r1 < d <r2, the packet reception probability decreases linearly from 1 to 0. RIM (Radio Irregularity Model) Angle dependant range between a minimum and a maximum communication range Shawn - Edge Model The Edge Model provides a graph representation of the network. The simulated nodes are the vertices of the graph An edge between two nodes is added whenever the Communication Model returns true Used by Shawn to determine the potential recipients of a message by iterating over the neighbors of the sending node Centralized algorithms can directly get the neighboring nodes without echo/hello msgs

5 Shawn - Edge Model Shawn - Transmission Model Lazy Edge Model (Simple) does not store any information For small simulations with little communication Or hight mobility List Edge Model stores the complete graph time-consuming initial construction Faster node iteration Grid Edge Model uses a two-dimensional grid for arranging nodes according to their geometric position improving the lookup speed fully supporting mobility Whenever a node transmits a message, the behavior of the transmission channel may be completely different than for any other message transmitted earlier Cross traffic from other nodes Node movement The transmission model can arbitrarily delay, drop, or alter messages Choice of an implementation strongly depends on the simulation goal Shawn - Simulation Tasks Shawn - Sequencer Simulation Tasks are pieces of code that are invoked from the configuration of the simulation supplied by the user They are not directly related to the simulated application but they have access to the whole simulation environment Example uses: managing simulations gathering data from individual nodes (dump_transmission_stats) running centralized algorithms creation and parameterization of new simulation worlds (prepare_world edge_model=simple comm_model=disk_graph range =2 rect_world width=n height=m count=k processor=flood_the_worldr) Even the actual simulation is triggered using a task (simulation max_iterations=n) The sequencer is the control center of the simulation: it prepares the world in which the simulated nodes live instantiates and parameterizes the implementations of the models as designated by the configuration input and controls the simulation The sequencer consists of: Simulation Tasks Simulation Controller Event Scheduler

6 Shawn - Nodes and Processors Shawn - Event Scheduler The simulated Nodes reside in a single World instance The Nodes themselves serve as a container for so-called Processors Developers using Shawn implement their application logic as instances of these Processors Multiple applications can easily be combined in a single simulation Processor s API: void boot( ); bool process_message( MessageHandle& ); void work( ); Node& owner( ); void send( MessageHandle& ); Shawn logically arranges simulations into rounds (r = 0, 1, 2,...) The user may register Simulation Tasks as pre-step and post-step tasks that are executed immediately before At the beginning of each round, a node s work()-method is invoked Also the nodes or other elements of the simulation may register an event at any point in time Shawn - Modelling sensors and readings Shawn Case Study To model sensors and their corresponding sensor values, a generic framework called Readings and Sensors is provided Readings deliver position-dependent and timedependent values that can be arbitrarily typed Sensors are bound to a specific sensor node and deliver sensor readings Readings and sensors can be configured by the user and are referenced inside the simulation using unique names Shawn vs ns2 Simulations run a subroutine that is used in certain time synchronization protocols every node periodically broadcasts a message containing time stamps that is converted at the receiving node A total of 380 messages is sent by each node. This provides insight on the simulator s ability to dispatch a large amount of traffic. Environment consists of a square area whose size is the specified multiple of the nodes communication range

7 Shawn Case Study Shawn Performance Ns-2 does a lot more detailed computations than Shawn to arrive at the same results Performance metrics Runtime Memory consumption The node density describes the average number of nodes within a broadcast area. Ns-2 hits the one-day barrier for instances that Shawn finishes in less than one minute Simulation of a simple application that broadcasts a message every 250ms of simulated time The communication range of the sensor nodes is set to 50 length units and each simulation runs for 60 simulated time units The size of the simulated area is 500x500 length units Shawn Performance Shawn outperforms both other simulation tools by orders of magnitude Ns-2 performs a very detailed simulation of lower layers such as the physical and the data link layer while Shawn simply dispatches the messages using a simplified model TOSSIM that simulates an underlying TinyOSsupported hardware platform Q&A? REFERENCES A. Kr oller, D. Pfisterer, C. Buschmann, S.P. Fekete, and S. Fischer, Shawn: A new approach to simulating wireless sensor networks, Proceedings of the Design, Analysis, and Simulation of Distributed Systems (DASD 05), San Diego, (