Integrated Validation System for the Simulation of Diverse Sensors in WSNs

Abstract

In wireless sensor networks (WSNs), sensors use different types of information, such as temperatures, humidity, magnetic fields, and sound; their communication distances and battery sizes and capacities may be different. Differences in communication distances and battery capacities when the same communication method is used affect the life of the entire sensor network topology. Tests for the maximum life of the sensor network topology require many sensor nodes and huge proportional costs. In addition, experiments to verify new ideas for WSNs as alternatives to existing methods also require large expenditures. Since experiments with the arrangement of actual sensors are expensive, such experiments are conducted using simulators so that solutions for protocol design and verification can be compared through software. Existing simulators are tailored to certain sensor characteristics, so that only quite limited results can be obtained through the implementation of simulated operations, simulations of sensor arrangements, and the comparison of limited information transmission routing functions provided by simulators. This paper proposes diverse sensor definable simulators (DSDs) for the performance of experiments on diverse sensors with different communication distances in WSN environments where Geography Markup Language (GML) based coordinates are utilized.

1. Introduction

Wireless sensor networks (WSNs) have been actively studied by many researchers thus far and are grafted on actual life areas (e.g., surveillance area, living room with sensors etc.). In WSN environments, diverse sensors are generally used depending on the types of data to be collected from sensing target regions, including temperature, humidity, magnetic fields, and sound. Events are sensed using these sensors and the data are transmitted to sink nodes through sensor networks. The transmitted information is applied to engines that have different roles in many application services. These include national safety, medical devices, senior citizens who live alone, traffic control and safety, process control, energy savings, weapon systems, distributed robots, manufacturing, and communication systems. To build up these WSN environments, many sensors and appropriate protocols for communication between them are necessary. Since protocols for communication between sensors are used differently according to their diverse types, it is not easy to set up optimum environments. Arranging sensors in target regions to test them for verification of theoretical contents is expensive. Sensor node arrangements require the use of many sensor nodes, along with arrangement algorithms. Finding and correcting errors in these sensor nodes require huge amounts of time and effort, and inspecting individual sensor nodes is practically impossible [1–4].

Therefore, to build up WSN environments, software simulators that enable prior testing, verification, and supplementation of theoretically designed contents are necessary. Thus far many simulator tools for the design and verification of WSNs have been developed, including GloMoSim [5], SNetSim [6], ATEMU [7], QualNet [8], NS2 [9], EmStar [10], TOSSIM [11], J-Sim [12], AVRORA [13], SWANS [14], SENSE [15], MSPsim [16], WSim [17], Atarraya [18], WSNet [19], AlgoSenSim [20], NetTopo [21], and SIDnet-SWANS [22]. However, although such simulators have been developed, tests are conducted using limited sensor information, so that only very restricted results are obtained, or large- or small-scale networks are insufficiently treated. In addition, since simulations are basically conducted with those types of sensors that are built in simulators, these simulations are not suitable of experiments on other sensors, new sensors, or combinations of sensors [1, 2, 23, 24].

Therefore, this paper proposes a diverse sensor definable simulators (DSDs) for performance experiments on diverse sensors with different communication distances not only in experimental environments but also in WSN environments where geography-markup-language- (GML-) based coordinates are utilized. The DSDs use GMLs that can be mapped with actual topography so that the simulations of target topography can be provided in more detail. This can create dynamic and diverse static arrangements of mobile sensor nodes (MSNs) and fixed sensor nodes (FSNs). In addition, this paper also proposes a simulator that provides not only basic sensor-setting methods but also functions for users to define sensor types so that more concrete experiments can be conducted. It provides functions for users to define additional sensor node types other than MSNs and FSNs, so that not only new sensor types but also existing diverse sensors can be universally simulated.

The remainder of the paper is composed as follows. In Section 2, simulators that have been developed as tools for the design and verification of existing WSNs are introduced in detail. In Section 3, the specification of the definition of sensor types in the DSDs proposed in the present paper is explained. In Sections 4 and 5, contents regarding the design and implementation of the DSDs are described.

2. Related Works

In this section, the characteristics and functions of simulators already developed for simulations of protocols, packet losses, coverage, and connectivity ratios in WSN are given (Table 1) [1].

Table 1

Characteristics and functions of the existed simulators.

Tools	Explanations
	A sensor, environment, and network simulator. Errors are common; wireless communication, noisy measurements, and node failures are to be expected. Network interacts heavily with environment. Highly constrained nodes (e.g., 4 k RAM, 2 AA batteries, and 20 msg/s radio) must operate for months; little supervision and experiments are time and space intensive.
	An open source TinyOS-based simulator from UC Berkeley. TOSSIM can simulate Mica2 series simulation from CrossBow. Main features are packet loss calculation and CRC sensing. However, it can only work with Mica2 series.
	A probabilistic WSN simulator running under the MATLAB environment. The tool supports the Gaussian and Rayleigh radio propagation models, complemented with two collision detection schemes and the following MICA2 MAC-layer communication protocol.
	A PARSEC- (C-based parallel simulation language) based discrete event simulator. GloMosim is a simulation environment for wireless mobile network. Like OSI 7-hierarchical model, GloMoSim is composed of number of layers. It monitors packet transmission status and verifies network model or transmission scenario; however, it cannot work as sensor network.
	GloMoSim's next version. QualNet is a massive wireless network simulator. It uses IEEE 802.11 MAC and Physical layer standard, and like GloMoSim it has several layers. When modules for layer are developed by different designers, the scenarios and models are being tested. Packet flow statistics can be checked through automatically collected data from each layer. Features for sensor network are designed as well, nevertheless, visualization of sensed objects.
	A determination of the location of sensor nodes is a simulation task that wireless sensor network localization simulator is designed for. The program comes with eight localization algorithms, while other required procedures may be implemented. Numerous parameters that define network topology include network size, locators deployment strategy, and antenna type, as well as the path loss and node mobility
	A command-line framework capable of simulating and analyzing programs developed for MEMSIC Mica2 and MicaZ sensor platforms. In the simulation each node has its own separated thread. It supports applications written using the Atmel and GNU assembler syntaxes.
	It allows researchers to simulate environment focusing on physical measures and phenomena. It also offers means to analyze energy consumption and provides mobility. Radio communication models involve a simple ideal physical layer, as well as more complex representations of fading, interference, delays, transmission errors, modulations, and channel access methods.
	It comprises simulation and visualization frameworks that share common elements for high level operations. The GUI, left figure, allows the user to view the network topology and control the properties of selected nodes. The simulator is designed to simplify studies of various WSNs algorithms. Consequently, modules are used to represent built-in and user-defined controlling, scheduling, routing, or clustering algorithms.
	It is an expansion of JiST, a PARSEC-based scattered event simulator. It is open source simulator, and compared to NS2 or GloMoSim, it can carry out massive network simulation; nevertheless, like other simulators it can only carry out protocol verification.
	TRMSim-WSN (trust and reputation models simulator for wireless sensor networks) is a software designed to help researchers study and compare trust and reputation models. The simulation can be run over a single randomly generated WSN or over a set of networks. The user is able to define parameters of the network, such as the percentage of clients and that of malicious nodes
	A Discrete event simulator and a popular general purpose network simulator mainly used in the studies of TCP, routing and multicast protocols. Although many ad hoc protocols are implemented, the framework lacks support for WSNs and only the module for directed diffusion is included.
	PAWiS (power aware wireless sensors) framework is capable of simulating different types of nodes and networks due to the modular design. Generated simulation log files can be analyzed by a special application that visualizes timings, interactions, and power requirements for each node. There is a module responsible for defining processor characteristics such as interrupt handling or power management.

As shown in Table 1, the tools operate simulations of certain sensors or provide limited results due to restrictions in their functions. Therefore, in the present paper, a framework will be provided in which diverse types of sensors, such as temperature, humidity, magnetic field, and sound sensors, can be used to simulate various performances, including the sensor arrangements necessary for WSNs.

3. Definition of Sensor Type

The DSDs proposed in the present paper provide a function to define basic sensor types necessary for the simulations of the functions and performance of WSNs using diverse sensor nodes. This definition of sensor types enables users to select the basic sensor node information necessary for simulator operation and colors for visualization.

First, information on sensors necessary for the definition of sensor types is given as follows.

• (1)

  Each sensor's identifier should be unique.

• (2)

  The definition of the types of sensor functions refers to temperature sensing, illumination sensing, magnetic field sensing, sound sensing capabilities, and so on, and the sensing ranges of sensors by type can be inputted in detail.

• (3)

  As sensors’ operation periods, the periods of basic sensors’ active states are entered.

• (4)

  As sensors’ operating time, the time for which the active mode of sensors should be maintained for operation should be entered.

• (5)

  The sensor sleeping time refers to the sleeping time when sensors are in the resting state.

• (6)

  The range of sensor communication is the range of communication for information transmission between sensors, and the values of the maximum range of communication and the basic range of communication are required.

• (7)

  Sensors’ battery sizes refer to the basic battery sizes of sensors, which indicate their capacities.

• (8)

  The definitions of the amounts of battery consumption by sensor function should be entered. In the case of mobile sensors, the rate of battery consumption during movements should be given (for instance, if 50 mA is consumed per 1 m, the migration length (1 m) and the amount of consumption (50 mA) should be entered). When sensors are in operation in the active mode, the operation time and the amount of consumption are required. When sensors are in operation in the sleep mode, the operation time and the amount of consumption are required.

• (9)

  The details of the residual battery capacity should be entered. As methods for obtaining the residual battery capacity, two methods, one for the user to prepare the formula and another to obtain the residual battery capacity relying on the DSDs, are provided. The formula is to be entered by the user with the sensor information entered earlier (the formula can be generated for the four fundamental arithmetic operations and parentheses can be used based on the priorities of operations). In the case of the method relying on DSDs, the residual battery capacity after deducting the amounts of battery consumption applying the rates of battery consumption for the operations of individual functions of independently operating sensors is calculated.

• (10)

  The information necessary for the prediction of battery life should be entered. When the user has entered a formula into the details for the residual battery capacity, information is provided so that the user can predict the life based on the entered formula considering the residual battery capacity. In the case of the method relying on DSDs, the expected life time is calculated for the residual battery capacity after deducting the amounts of battery consumption, applying the rates of battery consumption for the operations of independently operating sensors. In this case, the rates of battery consumption are rates accumulated in proportion to operating time in accordance with operations by function.

The three pieces of information to be added on the definition of sensor types for the visualization functions of DSDs simulators are as follows. (1) Information for sensor type division should be entered. If sensor division by type has not been set, unique colors will be randomly selected and applied. If the user wishes to select the colors, a list of colors not overlapping with each other will be shown so that the user can choose. When images are selected, it must be ensured that the same image is not used. (2) Values for color setting for sensor communication should be entered. Some colors are provided in addition to the colors basically applied so that the user can revise the colors. The colors can be easily observed using the visual part. (3) Values for sensors’ sensing color setting should be set. The colors applied to the range of sensing should be selected so that they do not overlap with the colors for previous sensors using the color table.

Basic information on sensors necessary for conducting simulations is also essential. Through this function, information on existing sensors can be entered and experimented and changes can be made to existing sensors to verify the efficiency of topology in relation to sensor functions. Trial simulations can be conducted by entering new sensor information, and added functions for visualized expression can be selectively provided so that the user can quickly understand diverse experiments and their results. In addition, the defined types can be stored as XML documents so that the information can be reused and applied in many fields, by not only the user but also by other users in DSDs-based systems. Figure 1 shows an XML schema configured for sensor type definition.

Figure 1

User-defined sensor type with XML schema.

4. Design of DSDs

The DSDs proposed in the present study are largely divided by function into a User Interface, a Target Area Manager, an Interaction Broker, a Map Manager, a Map Controller, a Node Manager, a Coordinate Converter, and a Viewer. The User Interface sets the user's definition of sensor node types, revisions and deletions of the defined types, and screen configuration information. The Target Area Manager manages sensing target regions set by the user and the Interaction Broker connects the node- and map-setting values set by the user to the system. The Map Controller applies the map-setting values entered by the user and the Node Manager manages the sensor types defined by the user in addition to the sensor types basically provided for independent operations. The Coordinate Converter processes data in order to provide the simulated states of operation to the Viewer. The Viewer finally provides simulations visually. Figure 2 gives a structural diagram of all of the functions of the DSDs.

Figure 2

Module Components of DSDs.

The User Interface Component is subdivided into a Map Interface, a Node Type Manager, and a View Mode. The Map Interface receives the entries of actual topography and mappable GML. The Node Type Manager consists of a Node Importer for adding node types defined by other DSDs in advance, a Node Exporter for storing the nodes types defined by the simulator currently in operation as XML documents, a Node Parser for adding read documents to the Node Manager, and Mobile Information and Fixed Information for receiving the entries of type addition, revision, and deletion for MSNs and FSNs. The View Mode is an interface for providing the screens operated by the DSDs so that they can be selected by the user; it is composed of Integration to operate MSN, FSN, or MSN and FSN simultaneously.

The Target Area Manager Component sets areas in target regions for which the GML documents read and analyze through the GML Importer should be observed for more detailed experiments. The Interaction Broker Component plays the role of a broker to send the set values entered by the user in the User Interface to the Map Controller and the Node Manager. The Map Manager Component plays the role of applying GML documents mappable with actual topography to the DSDs and managing the documents. It is composed of a GML Importer that adds the GML documents selected through the Map Interface of the User Interface to the simulator, a GML Parser that analyzes the added GML documents for application to the DSDs, a Map Layer that creates Map Objects for obstacles in the analyzed GML topography data and sends them to the Layer Manager, and a Layer Manager that manages the topographical information received from the Map Layer.

The Controller Component serves functions such as enlarging, reducing, area enlarging, and moving for the maps of the set values received through the Interaction Broker and managed by the Layer Manager. These functions are implemented when values have been entered through the Map Interface of the User Interface and the results are outputted on the Viewer through the Coordinate Converter. The Node Manager Component manages the sensor nodes types entered and defined by the user. It is subdivided into MSNs, which are mobile sensors, and FSNs, which are sensors at fixed locations. MSNs and FSNs are composed of Sensor Identifiers (S_IDs) that show the unique identifications of sensor nodes, Function Types (F_TYPEs) that define sensors’ sensing ranges and sensing types, Active Interval Time (A_IT) that shows the operating periods of sensors, Active Operator Time (A_OT) that shows operating times when sensors are in the active mode, Sleep Operator Time (S_OT) that shows operating times when sensors are in the sleep mode, Communication Max Ranges (CMRs) that show maximum communication ranges between sensors, and Communication Default Range (CDR) that shows the ranges of basic communication between sensors. MSNs are composed of Move Consumption (MC) that shows the amount of battery consumption during movements; Active Consumption (AC) that shows the amount of battery consumption when sensors are in the active mode; Sleep Consumption (SC) that shows the amount of battery consumption when sensors are in the sleep mode; the Formula of Battery Remaining (FBR) that shows a formula for obtaining the residual battery capacity of diverse sensors such as temperature, humidity, magnetic field, and sound sensors; and the Life Prediction of Battery (LPB) that predicts and shows lifecycles from the viewpoint of batteries in proportion to the residual battery capacity and operating time, which is calculated through the FBR when sensor nodes operate independently in cases where simulations are conducted.

The Coordinate Converter Component plays the role of processing and transmitting basic information on topography and nodes and data on their operating situations so that the information data can be displayed on the Viewer. The Viewer Component provides the data received through the Coordinate Converter to the user as visual information. The Viewer Component is composed of a Map Viewer for showing topography, an MSN Viewer that shows the situation of operation of MSNs and Mobile Sensor information, an FSN Viewer that shows the situation of operation of FSNs and Fixed Sensor information, and an Integration Viewer that shows MSNs and FSNs together so that they can be compared and analyzed.

5. Implementation of DSDs

The DSDs are composed of MSN Views, FSN Views, Integration Views, and Type List Views. Figure 3 shows a screen of MSN and FSN controlled by the DSDs. The control screen is set to hidden as a default option. The hidden state can be released through a right mouse click on the View to control sensor nodes for MSNs and FSNs. MSN Control enables the selection of sensing ranges, communication ranges, the number of sensor nodes to be operated, the range to be displayed on the screen, and the state of connection. Whereas the number of sensor nodes should be entered in the case of MSN Control, sensor node locations can be directly set on the screen in the case of FSN Control. FSN Control basically provides the same functions as those provided by the MSN Control.

Figure 3

Control view of MSN and FSN.

Figure 4 shows a screen of MSN operation that illustrates MSN movements.

Figure 4

Moving sensors in MSN execution.

Figure 5 shows a screen after selecting the FSN on the tab at the top to operate FSNs. For FSNs, the user sets the locations of sensor nodes individually. The CR in Figure 5 refers to the Communication Range between sensors and the number indicates the set range value. It can be seen that the view of communication between sensors varies with the value of the CR and that communication is possible only when the value of the CR is at least 30.

Figure 5

Operation of sensors in FSN execution.

Figure 6 shows the results of implementation of the Integration function in order to compare MSNs and FSNs simultaneously. The left side of Figure 6 shows an MSN operation screen and the right side shows FSNs for which the user sets sensor locations. The screen shows that the MSN has set the number of sensor nodes to 100 and gradually covers the target topography. When the MSN has finally completed its coverage, the number of sensor nodes falling short in terms of covering the entire target topography can be inferred.

Figure 6

Integration of MSN and FSN execution.

Figure 7 shows an execution screen where the user sets the definition of sensor types. The TYPE to select between MSN and FSN as sensor information, unique numbers of sensors, sensors’ sensing functions, the Active Interval Time to enter the period of switching between the active and sleep modes, the Active Mode Operation Time and Sleep Mode Operation Time indicating the active and sleep mode operating times, the Communication Max Range indicating the maximum communication range between sensors, the Communication Default Range indicating the default communication range between sensors, basic sensor battery sizes, the rate of battery consumption during movements in the case of Mobile Sensors, the rate of battery consumption during the active state, and the rate of battery consumption during sleep states should be essentially entered while the residual battery capacity formula can be selectively entered by the user.

Figure 7

User-defined sensor type.

Figure 8 shows a list of the sensor types defined by the user as shown in Figure 7. The sensor types defined previously can be selected from the table for revision or deletion.

Figure 8

Result of user-defined sensor types.

6. Conclusion and Future Research

The diverse sensor definable simulators (DSDs) proposed in the present paper are intended to provide frameworks in which various performances, including sensor arrangements necessary for WSNs, can be simulated using diverse types of sensors such as temperature, humidity, magnetic field, and sound sensors. Basically, functions to define the sensor types were provided so that the functions could be implemented. Since existing simulators operate simulations for the same types of sensor nodes or conduct simulations using only the limited types and functions of sensors defined in the simulator, restricted results are necessarily obtained. The DSDs were able simulate the target topography consisting of various types of sensors through experiments of diverse sensors. Furthermore, they could conduct additional experiments of new sensors to be made later. In addition, defined sensors were stored as XML documents so that they can be used in various application programs and the sensor types defined by the user can be reused.

In future work, precise logs will be set in the DSDs and log visualization will be provided. By setting precise logs, users will be able to select the activity types of individual sensors, and log visualization functions for the selected activities will be provided so that users can make the best selection during different simulation implementation processes.