Wireless Sensor Networks Modeling and Simulation in Visualsense

Abolfazl Gandomi* *Department of Computer Engineering, Islamic Azad

University-Yazd Branch, Yazd,IRAN, E-mail: gandomi@iauyazd.ac.ir

Vahid Ayatollahi Tafti

Department of Computer Engineering, Islamic Azad

University-Taft Branch, Yazd,IRAN, E-mail: vahid.ayat@taftiau.ac.ir

Haydar Ghasemzadeh Yazd-acecr Higher education Institute Yazd,Iran E-mail:ghasemzadeh@yazdjdu.ac.ir

Abstract A wireless sensor network (WSN) is a wireless network consistsing of spatially distributed autonomous device using sensors to cooperatively monitor physical or environmental conditions, such as temperature, sound, vibration, pressure, motion or pollutants at different locations. A complete model of a sensor network is needed to improve upon its efficiency and design.Using a modeling and simulation tool called Visualsense models of these in this paper will discuss the implementation and creation of a sensor node in Visualsense.In the Visualsense analyses of a sensor network , several factors affecting a network are relized such as battery life and signal range of the device.Modeling of wireless sensor networks requires sophisticated modeling of communication channels, sensor channels, adhoc networking protocols,localization strategies,media access control protocols,energy consumption in sensor nodes,etc.this modeling framework is designed to support a component-based construction of such models. It is intended to enable the research community to share models of disjoint aspects of the sensor nets problem and to build models that include sophisticated elements from several aspects.

Keywords- Wireless Sensor Networks; Modeling; Collision; Simulation;

I. Introduction

A sensor network comprises of a large number of low-power wireless sensors spread across a geographical area that can be used to monitor and control the physical environment from remote locations.Each sensor node is battery powered and equipped with integrated sensors, data processing capabilities and short-range radio communications. In recent Years, wireless sensor networks have been emerged as a new type of adhoc networks that can deployed as fully automated systems[1]. The applications for WSNs are many and varied, but typically involving some kind of monitoring, tracking, or controlling. Specific applications for WSNs include habitat monitoring, object tracking, nuclear reactor control, fire detection, and traffic monitoring. In a typical application, a WSN is scattered in a region where it is meant to collect data through its sensor nodes.for example Area monitoring is a common application of WSNs. In area monitoring, the WSN is deployed over a region where some phenomenon is to be monitored. For example, a large quantity of sensor nodes could be deployed over a battlefield to detect enemy intrusion instead of using landmines[2].When the sensors detect the event being monitored (heat, pressure, sound, light, electro-magnetic field, vibration, etc), the event needs to be reported to one of the base stations, which can take appropriate action (e.g., send a message on the internet or to a satellite)[2][3]. Unique characteristics of a WSN include:

Ability to cope with node failures Mobility of nodes Dynamic network topology Communication failures Heterogeneity of nodes Large scale of deployment Unattended operation

II. Platforms

The main challenge is to produce low cost and tiny sensor nodes. With respect to these objectives, current sensor nodes are mainly prototypes. Energy is the scarcest resource of WSN nodes, and it determines the lifetime of WSNs. WSNs are meant to be deployed in large numbers in various environments, including remote and hostile regions, with ad-hoc communications as key. For this reason, algorithms and protocols need to address the following issues[4]: Lifetime maximization Robustness and fault tolerance Self-configuration

III. Operating systems

Operating systems for wireless sensor network nodes are typically less complex than general-purpose operating systems both because of the special requirements of sensor network applications and because of the resource constraints in sensor network hardware platforms. For example, sensor network applications are usually not interactive in the same way as applications for PCs. Because of this, the operating system does not need to include support for user interfaces. Furthermore, the resource constraints in terms of memory and memory mapping hardware support make mechanisms such as virtual memory either unnecessary or impossible to implement.TinyOS is perhaps the first operating system specifically designed for wireless sensor networks. Unlike most other operating systems, TinyOS is based on an event-driven programming model instead of multithreading. TinyOS programs are composed into event handlers and tasks with run to completion-semantics. When an external event occurs, such as an incoming data packet or a sensor reading, TinyOS calls the appropriate event handler to handle the event. Event handlers can post tasks that are scheduled by the TinyOS kernel some time later. Both the TinyOS system and programs written for TinyOS are written in a special programming language called nesC which is an extension to the C programming language. NesC is designed to detect race conditions between tasks and event handlers.

Second International Conference on Computer Research and Development

978-0-7695-4043-6/10 $26.00 © 2010 IEEE

DOI 10.1109/ICCRD.2010.72

251

IV. Modeling and Simulation

VisualSense is a modeling and simulation framework for wireless and sensor networks that builds on and leverages Ptolemy II[5]. Modeling of wireless network requires sophisticated representation and analysis of communication channels, sensors, ad-hoc networking protocols, localization strategies,media access control protocols, energy consumption in sensor nodes, etc. This modeling framework is designed to support a component-based construction of such models. It supports actor-oriented definition of network nodes, wireless communication channels, physical media such as acoustic channels, and wired subsystems. The software architecture consists of a set of base classes for defining channels and sensor nodes, a library of subclasses that provide certain specific channel models and node models, and an extensible visualization framework. Custom nodes can be defined by subclassing the base classes and defining the behavior in Java or by creating composite models using any of several Ptolemy II modeling environments. Custom channels can be defined by subclassing the WirelessChannel base class and by attaching functionality defined in VisualSense models. It is intended to enable the research community to share models of disjoint aspects of the sensor nets problem and to build models that include sophisticated elements from several aspects[5][6]. In the underlying discrete-event semantics of VisualSense, events occur instantaneously at a particular time. That is, they do not have a duration. To model collisions of messages that take time and share a common channel, the model must explicitly include the message duration[5]. A simple example of such a model is shown in figure 1. In this model, two transmitters share the same channel and transmit messages of fixed duration at random times. As the model executes, one of the transmitters moves in a circular pattern, starting far from the receiver, coming close, then moving away again. At the start, when it is far from the receiver, its messages get through to the receiver only if the other transmitter does not transmit a message that overlaps in time. Whether the message from the other transmitter gets through in the event of a collision depends on how far away the first transmitter is.If it is sufficiently far away, then the interfering power is not sufficient to prevent communication,so the message gets through. If it is closer, then the interfering power will be sufficient that neither message gets through[7][8]. Two plots are shown in figure1 . The upper plot shows the messages that are transmitted (in red and blue), giving a visual indication of when overlap occurs. The magnitude in the plot represents the received power. For the transmitter that is stationary, the receiver power is constant. For the transmitter that moves, the received power starts low, then rises to nearly equal the power of the stationary transmitter,then drops again. The lower plot indicates whether messages are lost. In the figure, a total of seven messages are lost, all but one of them from the mobile transmitter (shown in red).

FIGURE1: Model of collisions of messages that take time.

The duration of a message in this model is represented by an extra field added to the transmit properties by the channel. The parameters of the channel are shown at the lower right in figure 2. Notice that the defaultProperties parameter has value “{range=Infinity, power=Infinity, duration=1.0}”. The duration field in this record represents the duration of a message. Individual transmitters can override this by setting the outsideTransmitProperties parameters of their ports to give any desired duration.

FIGURE2:parameters for transmitter0.

The Receiver implementation is shown in figure 3. In this model, the value of the received signal is a boolean with value false if the originator is the fixed transmitter and value true if the originator is the mobile transmitter. The GetProperties actor is used to extract the received properties, which will include the received power and the message duration.

FIGURE 3: Model of power loss as a receiver moves into range and then close to a transmitter.

252

records are extracted by the RecordDisassembler actor and fed into the CollisionDetector actor, which determines which of the messages are received and which are lost. The rest of the model is devoted to constructing meaningful plots so that we get a visual rendition of the behavior. The CollisionDetector actor is fairly sophisticated.This actor assumes that the duration of messages is short relative to the rate at which the actors move. That is, the received power (and whether a receiver is in range) is determined once, at the time the message starts, and remains constant throughout the transmission.

V. Conclusion and Discussion This actor models a typical physical layer front end of a wireless receiver. It models a receiver where messages have a non-zero duration and messages can collide with one another, causing a failure to receive. A message is provided to this actor at the time corresponding to the start of its transmission. Along with the message (an arbitrary token), the inputs must provide the duration of the message and its power. The message spans an interval of time starting when it is provided to this actor and ending at that time plus the duration. If another message overlaps with a given message and has sufficient power, then the given message will be sent to the collided output. Otherwise it is sent to the received output. In both cases, the message appears at the corresponding output at the time it is received plus the duration (i.e. the time at which the message has been completed). The inputs are: • message: The message carried by each transmission. • power: The power of the received signal at the location of this receiver. • duration: The time duration of the transmission. The power and duration are typically delivered by the channel in the “properties” field of the transmission. The power is usually given as a power density (per unit area) so that a receiver can multiply it by its antenna area to determine the received power. It is in a linear scale (vs. DB), typically with units such as watts per square meter. The duration is a non-negative double, and the message is an arbitrary token. The outputs are: • received: The message received. This port produces an output only if the received power is sufficient and there are no collisions. The output is produced at a time equal to the time this actor receives the message plus the value received on the duration input. • collided: The message discarded. This port produces an output only if the received message collides with another message of sufficient power. The output is produced at a time equal to the time this actor receives the message plus the value received on the duration input. The value of the output is the message that cannot be received. This actor is typically used with a channel that delivers a properties record token that contains power and duration fields. These fields can be extracted by using a GetProperties actor followed by a RecordDisassembler. The PowerLossChannel, for example, can be used. However, in order for the type constraints to be satisfied, the PowerLossChannel's defaultProperties parameter must be augmented with a default value for the duration. Each transmitter can override that default with its own message duration and transmit power. Any message whose power

(as specified at the power input) is less than the value of the powerThreshold parameter is ignored. It will not cause collisions and is not produced at the collided output. The power-Threshold parameter thus specifies the power level at which the receiver simply fails to detect the signal. It is given in a linear scale (vs. DB) with the same units as the power input. The default value is zero, i.e. by default it won't ignore any received signal.Any message whose power exceeds powerThreshold has the potential of being successfully received, of failing to be received due to a collision, and of causing a collision. A message is successfully received if throughout its duration, its power exceeds the sum of all other message powers by at least SNRThreshold-InDB (which as the name suggests, is given in decibels, rather than in a linear scale, as is customary for power ratios). Formally, let the message power for the i-th message be at time t. Before the message is received and after its duration expires, this power is zero. The i-th message is successfully received if

ijtPjPtPi )()(

for all t where Pi(t)>0 , where P = 10^(SNRThresholdInDB/10), which is the signal to interference ratio in a linear scale.

FIGURE 4:number of elements .

In this model, two transmitters broadcast signals that may collide with one another.The receiver will correctly receive a signal if the signal to interfernce ratio is 3 dB or better , meaning that the received signal has at least twice the power of the interfering signal.when transmitter1 is far away from the receiver, it cannot interfere with the transmission of transmitter0.However,when it gets close,it can.

FIGURE 5:Message Power for Transmitter.

The upper plot shows the received power density (in watts per square meter) seen by receiver for both transmitters.it also shows the duration of the transmissions.if the transmissions overlap, then one of the

253

transmissions is surely lost.the second is lost only if its power is not greater than twice the power of the interferer.

FIGURE 6:Message Received for Transmitter.

The upper plot shows which messages were received and which were lost .the messages from transmitter1 will always be lost if they collide with messages from transmitter0.However, messages from transmitter0 can only be lost when transmitter1 is close to the receiver.

FIGURE7:Output for SNR thresholdInDB=20.

In this model, two transmitters send messages with duration 1.0 periodically . The messages from transmitter1 collide with every second message from transmitter0,causing both messages to be lost.

FIGURE8:Output for SNR thresholdInDB=3.

if you change the SNR thresholdInDB parameter of the receiver to 3 (3 dB is a factor of two in power),then the messages from transmitter0 will be successfully received despite the collision.if you then move transmitter1 closer to the receiver, then every second message from transmitter0 will again be lost.

REFERENCES

[1] Akyildiz, F. and kasimoglu,I. H. Wireless sensor and actor networks: research challenges. Elsevier Ad Hoc Network Journal.2 351-367, 2004.

[2] Han, C., Kumar, R., Shea, R., Kohler, E., and Srivastava, M. A dynamic operating system for sensor nodes. In Proceedings of the 3rd international Conference on Mobile Systems, Applications, and Services (Seattle, Washington, June 6-8, 2005). MobiSys '05. ACM Press, New York, NY, 163-176, 2005.

[3] Akyildiz, I., W. Su., Y. Sankarasubramaniam, and E. Cayirci , Wireless sensor networks: a survey. Computer Networks, 38, 393–422, 2002. [4] Holger, K., Willig, A.: Protocols and Architectures for Wireless Sensor Networks. Wiley, New York 2005. [5] P. Baldwin, “Sensor Networks Modeling and Simulation in Ptolemy II,” UC Berkeley, August 8, 2003. [6] Baldwin, p., Kohli, S., Lee, E. A., Liu, X. and Zhao,Y. Modeling of sensor nets in Ptolemy II. Proceedings of the 3rd international symposium on Information processing in sensor networks ACM, 2004. [7] Sung Park, Andreas Savvides, and Mani B. Srivastava, “SensorSim: A Simulation Framework for Sensor Networks,2000.

[8] Akyildiz, I.F., Melodia, T., Chowdhury, K.R.: A survey on wireless multimedia sensor networks. Comput. Netw. 51, 921–960,2007.

254