SENS: A Sensor Environment and Network Simulator

Get Complete Project Material File(s) Now! »

Design of WSN Simulator

The design, development, and deployment of sensor networks are application specific, mainly because of the distinctiveness of the considered deployment environment. Reliable generic predictive models for radio propagation or data correlation are seldom available. An absolute preliminary test phase is therefore essential, either utilizing particularly crafted testbeds or via sound simulations. Different WSN applications must be examined on a large scale, and under varying complex conditions to apprehend an adequately wide range of communications, both among sensor nodes, and with the environment. WSN simulator consists of multiple modules namely events, medium, node, environ-ment, protocols, transceiver, and applications [37]. Every category is described by an interface that defines its methods and events consumed and generated.
• Event: is an abstract base class which provides basic functionality for all other events. It includes the execution time of an event, and implements methods to: compare and distinguish events based on their execution times, print themselves to a string, determine whether events are equal, and provide an abstract method to the event.
• Medium: models the wireless medium. It allows nodes to send and receive data and infor-mation and is also capable for informing nodes of signals that affect it.
• Environment: is similar to the medium module but differs in the implementation. The implementation of the environment module has properties that are more related to the physical phenomenon modeled. Physical aspects of concern in WSNs include humidity, temperature, light, magnetic field, sound, chemical process, optical, etc.
• Node: which is the single sensor node of the network. It contains both hardware and software components. Essential hardware components are sensors/actuators, processor, transceiver, an energy source (battery). The software components could be network protocols, GPS, and applications.
• Transceiver: models the hardware transceiver for the sensor node. It models different transceiver states (i.e., awake, sleep, transmit, receive or standby), and their associated be-havior and power consumption.
• Physical Protocol: represents the lowest layer protocols in the network stack. It is usually implemented in the transceiver hardware. The main purpose of the physical layer is to send and receive sensed data. Besides that it provides services for carrier sensing, changing the state of the transceiver, received energy detection on received packets, etc.
• MAC Protocol: is represented by the second layer of the network stack. It is often imple-mented on the node’s processor. This layer provides services like setting and getting protocol parameters, state changing of the MAC layer (i.e., low power mode), etc. A good WSN simulator usually implements several MAC protocols.
• Routing Protocol: resides above the MAC protocol. It provides packet routing services for multi-hop communications between nodes.
• Application Layer: resides at the top of the network stack. It provides the interface between the lower layers and between the sensors and actuators as well.


Avrora was a research project by the UCLA Compilers Group and is an open-source cycle-accurate Java-based simulator for embedded sensing programs. It can emulate two common platforms, Mica2 and MicaZ, and run AVR elf-binary or assembly codes for both platforms. Unlike traditional simu-lators, which only simulate specific platforms, Avrora is independent to the language and operating system. It gives a framework for program analysis, allows static checking of embedded software and also an infrastructure for future program analysis research. Avrora emulates a network of motes, runs the actual microcontroller programs (rather than models of the software), and runs accurate simulations of the devices and the radio communication [47].
Avrora is an accurate, reliable and scalable simulator and provides hardware platform to run sensor programs. It has an almost complete implementation of the mica2 hardware platform. It is also capable of running an entire sensor network simulation with full timing accuracy, allowing programs to communicate via the radio using the software stack provided in TinyOS. It also has an extension point that will enable users to create a new simulation type and choose the kind of simulation to perform, depending on the number and orientation of the nodes. Developers claim that Avrora scales to networks of up to 10, 000 nodes and delivers as much as 20 times faster than the many other simulators with equivalent accuracy [48].
One significant limitation of Avrora is that it does not model clock drift, a phenomenon where sensor nodes may run at slightly different clock frequencies over time due to either temperature, manufacturing tolerances, or battery performance. Recently, developers have modeled distance at-tenuation for multi-hop scenarios, but have not yet been able to model mobility.

SENS: A Sensor Environment and Network Simulator

SENS is a customizable sensor network simulator written in C++, for WSN applications [49]. There exists a thin compatibility layer to enable direct portability between SENS and real sensor nodes. Multiple component implementations in SENS allow varying degrees of realism. Users can assemble application-specific environments; such environments are modeled in SENS by their various signal propagation characteristics. The corresponding source code that is executed on simulated sensor nodes in SENS can also be deployed on actual sensor nodes. This enables application portability. SENS is a wireless sensor network simulator with modular, layered architecture with customizable components which models network communication and the physical environment. It allows realistic simulations, by using values from real sensors to represent the behavior of component implementa-tions. Such action includes sound and radio signal strength characteristics and power usage [50].
The ability to develop portable applications is an essential feature of SENS, considering that WSN platforms continuously emerge as new sensor node implementations emerge. Another notable characteristic of SENS is its novel mechanism for modeling physical environments. WSN applica-tions feature tight integration of communication computation, and interaction with the physical environment. To give users with the flexibility of modeling the environment and its interaction with applications at different levels of detail, SENS defines an environment as a grid of interchangeable tiles [51]. SENS is less customizable than many other simulators, providing no opportunity to change the MAC protocol, along with other low-level network protocols. It does appear to use one of the most sophisticated environmental models and implements the use of sensors well. However, the only phenomenon detectable is sound. It can be argued as to whether or not it is better for a simulator to support several aspects well, or to support one phenomenon exceptionally well.

COOJA (COntiki Os JAva)

READ  Improvement of communication tables for WirelessHART devices 

COOJA is a Java application, all interactions with compiled Contiki code are made through Java Native Interface (JNI). It is a simulator for the Contiki node operating system. MSPSim can be integrated into COOJA, forming COOJA/MSPSim. It provides simultaneous cross-level simulation at application, operating system and machine code instruction set level [52]. COOJA links low-level simulation of sensor node hardware and simulation of high-level behavior in a single simulation. COOJA is adaptable and scalable to replace all levels of the system: operating system software, sensor node platforms, radio transceivers, and radio propagation models. As network communication is central to a WSN, the COOJA Simulator supports adding and using different radio mediums [53]. Initially, COOJA was a code level simulator for networks consisting of sensor nodes running on Contiki OS. Sensor nodes with different simulated hardware and different onboard software may co-exist in the same simulation. Code level simulation is achieved by compiling Contiki core, user processes, and individual simulation glue drivers into object code native to the simulator platform, and then executing this object code from COOJA. It can run the Contiki programs in two differ-ent ways: either by compiling the program code directly on the host CPU, or compiling it for the MSP430 hardware. It can simulate sensor networks simultaneously at different levels, including the operating system level and the network (application) level [54].
Nevertheless, due to its scalability, the simulator has relatively low efficiency. Simulating several nodes with many interfaces which requires a lot of calculations, especially when plugins are started and registered as observers to those interfaces. It supports a limited number of same node types; the simulator has to be restarted once and a while if the number of nodes exceeds permissible limit. A test interface GUI is also missing, thus making extensive and time-dependent simulations difficult [55].


Castalia was developed in C++ at the National ICT Australia [31]. It is an application-level sim-ulator for WSN based on OMNeT++. It can be used to evaluate various platform characteristics for particular applications, since it is very parametric, and can simulate a wide range of platforms. In Castalia, sensor nodes are implemented as compound modules, consisting of sub-modules that represent, for instance, network stack layers, application, and sensor. Node modules are connected to the wireless channel and physical process modules [56]. It is a generic simulator with a more realistic wireless channel and radio model based on measured data. Since it is based on the OM-NeT++ platform, it can be used by researchers and developers who want to test their distributed algorithms and/or protocols in a more realistic wireless channel and radio models, with a practical node behavior mainly relating to access of the radio [57].
Features of Castalia include: sensing device bias, physical process modeling, node clock drift, and several MAC and routing protocols implemented. Castalia has a highly tunable MAC protocol and a scalable parametric physical process model. Different physical process modules in Castalia represent various sensing devices (e.g., temperature, light, acceleration, pressure, etc.,). Castalia can consider sensing device noise, bias and node clock drift [57]. As Castalia is not sensor-platform specific, it is intended to give a generic framework for the first order validation of any algorithm before moving to its implementation in a particular sensor platform. It is not useful if one would like to test code compiled for a specific sensor node platform.


Shawn is a Java-based, open-source customizable sensor network simulator, designed to support simulation of large-scale networks. Rather than simulating a phenomenon, Shawn is designed to simulate the impact of the phenomenon. It claims to provide the highest abstract level and supports a more extensive network as compared to other conventional simulators such as NS-2, OmNeT++, SENSE, TOSSIM, and GloMoSim. However, more details on simulating WSN with Shawn can rarely be found in the literature. Its key features are persistence and decoupling of the simulation environment by introducing the concept of Tags. They attach both persistent and volatile data to individual nodes [58]. However, Shawn does not consider detailed simulations on the issues such as radio propagation properties or low-layer matters.


Emstar is a Linux-based framework which allows a range of runtime environments from classic sim-ulation to actual deployment. EmStar was intended to be compatible with two different types of nodes. Like the other emulators, it can be used to develop software for Mica2 motes. It also allows support for developing software for iPAQ based microservers. EmStar gives a flexible environment for transitioning between simulation and deployment for iPAQ-class sensor nodes running Linux. Users have three options: running many virtual nodes on a single host with a simulated network, running many virtual nodes on a single host with each virtual node bridged to a real-world one for networking, or running a single real node on a host with a network interface [59].

Table of contents :

List of Figures
List of Tables
1 Introduction 
1 Internet of Things (IoT)
1.1 Smart Cities
2 WirelessSensorNetwork
2.1 Wireless Sensor Node Architecture
2.2 Wireless Sensor Network Constraints
3 WSN communication stack
3.1 Cross Layers
3.2 MAC Layer and Upper Layers
3.3 PHY Layer
4 Characteristics of Noise in Wireless Channel
5 Interference Modeling
5.1 Gaussian Distribution
5.2 Alpha-Stable Distribution Model
6 System Model
7 WSNSimulator
7.1 Cupcarbon
8 Thesis Contribution
9 ThesisStructure.
2 Wireless Sensor Network Simulator 
1 Introduction
2 Importants of simulators for WSN
3 Design of WSN Simulator
4 WSNsimulators
4.1 NS-2
4.3 GLoMoSim
4.4 Avrora
4.5 SENS: A Sensor Environment and Network Simulator
4.6 COOJA (COntiki Os JAva)
4.7 Castalia
4.8 Shawn
4.9 EmStar
4.10 J-Sim
4.11 VisualSense
4.12 (J)Prowler
5 Analysis
6 CupCarbon:Wireless Sensor netwrok Simulator (SCI-WSN)
6.1 CupCarbon Plateform
6.2 Architecture of CupCarbon
3 LAN Protocols for CupCarbon 
1 Single-carrier vs Multi-carrier Systems
1.1 IEEE 802.11 Standard and Formats
2 Orthogonal Frequency Division Multiplexing (OFDM)
2.1 Principle of OFDM
2.2 Packet Format
2.3 Transceiver Scheme
2.4 Receiver
3 IEEE Standard 802.15.4
3.1 MAC Layer
3.2 IEEE 802.15.4 PHY Layer
4 Simulation Results
4.1 IEEE 802.11 Results
4.2 IEEE 802.15.4 Results
5 Integration of IEEE 802.11 and 802.15.4 in CupCarbon
5.1 Integration of simplified MAC in CupCarbon
5.2 Integration of PHY in CupCarbon
4 LPWAN Protocol for CupCarbon 
1.1 Network Structure
1.2 Packet Structure
1.3 Time on Air
1.4 Network Throughput
2 LoRa Technology
2.1 LoRa PHY Structure
2.2 PHY Performance
3 Interference in LoRa
4 CaptureEffect.
4.1 Capture Effect Scenarios
5 Non Orthogonal Multiple Access (NOMA)
5.1 Working Principle of NOMA
5.2 Successice Interference Cancellation
6 Integration in CupCarbon
5 Conclusion and Perspective 
1 Objectives
2 Contributions
3 Impact of the Thesis
4 Perspectives


Related Posts