Introduction to Sensor Networks in NS2
In this post
The readers learn about
Sensor networks in brief
Wireless Sensor flooding protocol
Creating a wireless sensor cluster for flat and hierarchical topology using Mannasim framework.
Creating a new scenario for generating a flat topology or a hierarchical topology
9.1 Introduction to Sensor Networks
A wireless sensor network consists of nodes with limited energy, memory, bandwidth, computing power and sensing capabilities. Sensor nodes consist of a small processor to handle the events, a group of sensors, a transmitter/receiver, and a small battery with limited energy and in some nodes, an operating system to handle the tasking. TinyOS is one of the common operating systems for miniature sensor networks. Like ad hoc networks, sensor networks also have a set of protocols for low energy, clustering, MAC level, etc. Usually, most of the routing protocols of sensor networks are designed mainly to optimise the power in order to improve the battery life.
The routing of sensor nodes is to design a network that possesses many challenges like node deployment, energy consumption without losing accuracy, data reporting model, fault tolerance, scalability, node/link heterogeneity, network dynamics, transmission media, connectivity, coverage, data aggregation and quality of service.
The routing protocols in wireless sensor networks based on network structure are classified into
flat-based routing;
hierarchical routing and
location based routing.
In flat based routing all the nodes have same functionality which collaborate to perform sensing task. In hierarchical based routing nodes have different levels of functionalities. In location based routing nodes are referred by their positions.
The routing protocols in wireless sensor networks can also be classified into the following categories based on the protocol operation.
They are:
multi-path based routing,
query based routing,
negotiation based routing,
coherent based routing,
QoS based routing.
A sensor network normally constitutes a wireless ad-hoc network, meaning that each sensor supports a multi-hop routing algorithm (several nodes may forward data packets to the base station). Like any computer network, nodes in Wireless Sensor Networks (WSN) communicate with each other based on defined protocols. Applications are developed and executed on top of the protocols.
In general, the categorisation of sensor network protocols falls under various categories, as each component in the sensor nodes is participating in the routing and is dealing with a protocol. Here is the list of protocols that were supported in the OSI layers for Wireless Sensor Networks (This is only a list of protocols, there may be other lists of protocols too in these categories) [11]
9.2 Protocols under various OSI layers
Application Layer
Sensor Management Protocol (SMP)
SMP access nodes by using attribute based naming and location-based addressing
SMP provides the following tasks
Introducing rules related to data aggregation, attribute based naming
Exchanging data
Time synchronisation of the sensor nodes
Moving sensor nodes
Turning sensor nodes ON or OFF
Authentication, key and security
Reconfiguring the sensor networks
Task assignment and Data advertisement protocol (TADAP)
Interest dissemination
Users send their interest to a node or a network
The node advertises the available data to the users
Sensor Query and Data Dissemination Protocol (SQDDP)
The locations of the nodes that sense temperature higher than 70°F is attribute-based “Temperature read by the nodes in Region A” is location based naming.
Transport layer protocol
Bridge between the network layer and application layer (Demux/Mux)
Data delivery service between the source and sink with error control
To regulate the amount of traffic injected into the network via flow and congestion
Transport layer for WSN
Reliable Transport (Source to sink, Event detection, Event to sink)
Congestion control
Self configuration
Energy Awareness
Biased implementation
Constrained routing
Event to Sink Transport
Sink is interested only in the collective information of sensor nodes within the event radius and not in their data
The nodes within the event radius accumulate more packets to send to the sink ,that leads to congestion
Hence, the transport layer is helpful to control the congestion in the forward path for efficient data delivery to the sink
Sink to Sensor Transport
Sink to sensor data should be 100% efficient and lossless as this data contains application-specific data like OS binaries, Programming/retasking, Application specific Queries and commands
100% reliable delivery is required
More energy is consumed because the sink is with a powerful antenna for 100% delivery
multihop communication
Forward path congestion is more when compared with reverse path congestion
Network Layer principles
Power efficiency
Sensor networks are mostly data centric
attribute based addressing and location awareness
data aggregation
The routing protocol is easily integrated with other networks
Network layers Protocols
SMECN – Small Minimum Energy Communication Network
Create a subgraph of a Sensor node that contains a minimum energy Path
LEACH – Low Energy Adaptive Clustering Hierarchy
Form clusters to minimise energy dissipation
SAR – Sequential Assignment Routing – uses tree like structure
Flooding – broadcast to all neighbours regardless of their receive or not
Gossiping – sends data to one randomly selected neighbour
SPIN – Sends data to nodes only if they are interested based on ADV, REQ and DATA
The Data Link Layer provides
Medium Access Control
Establish communication links for data transfer to create basic network infrastructure
Regulate access to the shared media such that communication resources are fairly and efficiently shared between the nodes
Error Control
Forward Error Correction
Automatic Repeat Request
Retransmission of lost packets/frames
Overhead cost and retransmission cost
MAC of Bluetooth and Adhoc (TxPower = 20dBM) network is different from MAC of Sensor network, TxPower = 0 dBM
So MAC has built-in power conservation, mobility management, and failure recovery strategies
MAC protocols
Two types of MAC protocols are available
Scheduled based protocol
Contention based protocol
The MAC protocol is mainly responsible for providing a mechanism that controls access to the shared communication medium
Requirements of MAC
Energy Efficiency
Scalability
Latency
Fairness
Bandwidth utilization
Scheduled based protocols
Uses TDMA (Time Division Multiple Access)
Collision free
Best for single hop
Latency increases with the number of nodes
Non-adaptive (new nodes added are not included)
Not scalable
Nodes know ahead of time, so the nodes know their inactive time and they can goto sleep mode
Contention based protocols
Uses CSMA (Carrier Sense Multiple Access)
it adaptive (can add new nodes)
Strict synchronisation is not required
scalable
multihop
Energy Wasted in CBP
Collisions
Overhearing (packet not intended for it, but it accepts it)
Control packet overhead
Idle listening
LEACH (Low Energy Adaptive Clustering Hierarchy)
Schedule based protocol
Two phases: Initialisation and steady state phase
Initialisation Phase
Clusters are formed, and a CH is elected
Cluster head is formed and energy is evenly distributed so that all the nodes randomly die at sthe ame rate
Cluster head coordinates the activity, establishes TDMA
Steady State phase
All nodes transmit their sensed data as per TDMA, and then it go to sleep state
Collision within a cluster is not possible, but between clusters it is possible
So CDMA code is allotted to each cluste,r which results in poor bandwidth utilisation
Contention Based Protocols
IEEE 802.11 DCF is used for single hop and which is not sutiable for synchronization. Hence IEEE802.11PS (Power save) is used for WSN.
SMAC (Sensor MAC)
periodic listening and sleeping
Synchronisation (SYNC packet with information: Time left to Sleep)
Collision and overhearing are avoided
Message passing
First RTS/CTS reserved medium for the second packet and so on.
Time out MAC (TMAC)
Mainly for energy saving
The FRTS (Future Ready to Send ) packet is used.
Ta = CW + TxRTS + T
Data gathering MAC (DMAC)
Adaptive and energy efficient
Low-latency MAC
No RTS/CTS only ACK Packets
Efficient in data gathering
Parent nodes can extend the wakeup time for their child nodes
Child nodes can request parent nodes to extend their lifetime
Wise MAC (Wireless Sensor MAC)
All nodes wake up periodically to receive or transmit data over the medium.
MS MAC (Mobile Sensor MAC)
Border nodes inform the respective clusters that a new node reaches their area.
The mobile node quickly follows the schedule of a new cluster.
9.3 Wireless Sensor Networks Flooding Routing Protocol (WFRP)
Adding a new protocol, we have already seen in the OLSR protocol for wireless Adhoc networks. This topic will introduce the WSN Flooding routing protocol (WFRP) for NS2. In this protocol, the sink nodes send a beacon message periodically for a duration of time and other nodes in the network form or construct a route towards the sink nodes; in this way, this concept is called flooding. Later, other nodes report to the sink node a certain period using the UDP protocol. WFRP is more or less closely related to the Direct Diffusion protocol in a simple way. Of course, the Directed diffusion protocol is really a complex routing, whereas the WFRP is a simple implementation.
Installation of WFRP in NS2
The source of this code is represented in [12]. The readers can download the code from the CD attached herewith, or they can download it at https://dl.dropboxusercontent.com/u/24623828/wfrp.zip
Files to be modified
~ns-2.35/Makefile.in
~ns-2.35/queue/priqueue.cc
~ns-2.35/common/packet.h
~ns-2.35/trace/cmu-trace.h
~ns-2.35/trace/cmu-trace.cc
~ns-2.35/tcl/lib/ns-packet.tcl
~ns-2.35/tcl/lib/ns-lib.tcl
~ns-2.35/tcl/lib/ns-agent.tcl
~ns-2.35/tcl/lib/ns-mobilenode.tcl
Here are the following changes in ~ns-2.35/queue/priqueue.cc (as given in the Fig 9.1)
Fig 9.1 – WFRP Change in priqueue.cc
Three changes in the ~ns-2.35/common/packet.h file,
Change number 1
A new packet value has to be added
static const packet_t PT_WFRP = 73;
Change number 2
name_PT_WFRP[“WFRP”]=”wfrp”;
Change number 3
Protocols have to be verified for type checking as shown in Fig. 9.3
Fig 9.2 – WFRP Change in packet.h
Fig 9.3 – WFRP Change in packet.h
Fig 9.4 – WFRP Change in packet.h
There is a change in the ~ns-2.35/trace/cmu-trace.cc file, that includes the tracing information to the cmu-trace.cc to get the wfrp packets in the trace file. This is shown in Fig. 9.5
Defining the function void format_wfrp(Packet *p, int offset) in ~ns-2.35/trace/cmu-trace.h. This is shown in Fig 9.6
Addition of the new packet type WFRP in the ~ns-2.35/tcl/lib/ns-packet.tcl. This is shown in Figure 9.7
There are two changes in the ~ns-2.35/tcl/lib/ns-lib.tcl that indicate what has to be done by the agent and how to create and start the transmission by the agent. This is shown in Fig. 9.8 and Fig. 9.9.
There is a change in ~ns-2.35/tcl/lib/ns-mobile.tcl file to tell the special processing for the WFRP protocol. This is shown in Fig. 9.10
Finally, the source files' location has to be added to the Makefile as given below.
OBJ_CC =
wfrp/wfrp.o \
Next, the code has to be compiled using the command
./configure && make clean && make
Fig 9.5 –WFRP Change in cmu-trace.cc file
Fig 9.6 – WFRP Change in cmu-trace.h
Fig 9.7 – WFRP change in ns-packet.tcl
Fig 9.8 WFRP Change in ns-lib.tcl
Fig 9.9 – WFRP Change in ns-lib.tcl
Fig 9.10 – WFRP Change in ns-mobile.tcl
To test the WFRP protocol here is the listing for Tcl file that indicates the WFRP protocol in simulation.
Here is the sample trace file that indicates the presence of wfrp packets.
9.4 – Mannasim Framework for Wireless Sensor Networks
Mannasim is a detailed framework for simulation of sensor networks as a valid test bed for wireless sensor networks. There are numerous simulators, emulators or test beds were available for sensor networks, but most of them are either proprietary or very difficult. Mannasim really does a difficult work to simple and elaborative simulation and it is free and open source built over the NS2 (Network Simulator 2).
9.4.1 Simple Example
Steps involved in creating a sensor network simulation using Mannasim framework is
Step 1 – creating simulator object and create files for tracing and animation
Step 2: Define the antenna and physical layer details, though they are already defined as a default value in the ns-default.tcl file, still these values can be overridden in the Tcl file.
Step 3: Create the configuration parameters with the default values for wireless channel, mac, number of nodes, protocol, link layer, energy details etc as given below
Step 4: Step to create the common sesnsor node, cluster heads and access point nodes which is the real work done by the Mannasim Team. These details are shown shortly in the next topic. Set the node configuration for sensor nodes, the very first line being sensorNode ON which indicates the usage of sensor nodes in the node configuration.
Step 5: The access point nodes does not need any sensing or processing, so it is the simplest node configuration which is given below
This class is derived as AccessPointApp which will be accessed using the UDP protocol
Step 6: The transport protocol should be attached to the application and applications sent message destination address must be set.
Configuring the sensor node requires the adjustment of nodes position, motion characteristics (in the box example, 0 means that the sensor node is static) and the transport protocol
Stop time is mentioned to finish the AP (Access Point) Simulation.
Step 7: On demand networks require that the AP or other outsider send requests messages to the WSN. These messages specifies the situation when the network should provide data to the requester.
To create a request message to be send by the AP the following parameters should be set:
When requested data should be sent back to AP (for example, send data when temperature exceeds 25 celcius degrees).
request type - two values are possible: REAL (0) when sensor node drops all data all data from its buffer, gather new one, process and deliver it to the disseminating module. BUFFER (1) when sensor node process data from its buffer and give the results to the disseminating module.
The sample code provided below defines the request time, schedules when data structure that encapulates request data is created and when request message will be sent.
Step 8: Cluster head configuration. It is similar to the AP nodes but they sense and process the data, so the configuration should be according to its use. To create a sensor node just put in the tradicional node-config structure the -sensorNode ON command. So, for this cluster head, a sensor node application (as expected a ClusterHeadApp) and an instance of a processing module.
Step 9: Common node configuration. Common Nodes are added to the cluster head node for data processing and sensing. Cluster head application adjustments includes, besides transport protocol settings, sent messages destination address, dissemination interval and type (PERIODIC - 0, CONTINUOUS - 1, ON_DEMAND - 2 and EVENT_DRIVEN - 3). The wireless sensor node object, the transport protocol and the processing module just created are attached to the application also.
Concerning sensor node configuration the user should set it´s position, motion type (in the box example 0 means a static node), energy spent in processing tasks and node´s processor instruction per second rate. Cluster head application and transport protocol should be attached to sensor node.
To complete node configuration, attach the sensor node to the processing module and schedule application start and stop times.
The above Tcl can be run using the command ns filename.tcl to see the tracing and the energy occupation and data processing.
9.4.2 Mannasim Implementation
Mannasim uses two modules,
Mannasim Framework simulation
Script generation tool
Mannasim Framework
Mannasim uses a large number of classes for various data generators, sensors, nodes, etc. Some of these classes, along with their usage, is listed below. However, the readers are asked to see the source code in the DVD provided for more information of refer to [13].
The order of class description is defined as follows:
Sensor Node
sensorNode.h and sensorNode.cc
extends the MobileNode Class
methods
void sensorNode::selfTest()
void sensorNode::sleep()
void sensorNode::wakeUp()
double sensorNode::sensingPower()
double sensorNode::processingPower()
int sensorNode::instructionsPerSecond()
DataGenerator
dataGenerator.h and dataGenerator.cc
extends the TclObject class
TemperatureDataGenerator
temperatureDataGenerator.h and temperatureDataGenerator.cc
extends the DataGenerator class
TemperatureAppData
temperatureAppData.h and temperatureAppData.cc
extends AppData class
Processing
processing.h and processing.cc
extends TclObject Class
SensedData
sensedData.h and sensedData.cc
extends AppData class
OnDemandData
onDemandData.h and onDemandData.cc
extends SensedData class
OnDemandParameter
onDemandParameter.h and onDemandParameter.cc
extends AppData class
SensorBaseApp
sensorBaseApp.h and sensorBaseApp.cc
extends Application class of NS2
CommonNodeApp
commonNodeApp.h and commonNodeApp.cc
extends SensorBaseApp class
ClusterHeadApp
ClusterHeadApp.h and ClusterHeadApp.cc
extends SensorBaseApp class
This entire arrangement is for sensing – processing - dissemination
Mannasim Installation
Copy the Mannasim.tar.gz file from the CD provided along with this book
Untar it in the folder ~ns-2.35/ using the command
tar zxvf Mannasim.tar.gz
Copy the files from the ~ns-2.35/Mannasim/ns-modified-files/ to these locations
~ns-2.35/apps/udp.cc
~ns-2.35/common/ns-process.h
~ns-2.35/common/packet.cc
~ns-2.35/common/packet.h
~ns-2.35/Makefile.in
~ns-2.35/tcl/lib/ns-default.tcl
~ns-2.35/tcl/lib/ns-lib.tcl
Once everything is done, go to the terminal and type the commands one by one
Prompt]./configure
Prompt] make
If there are any errors, correct them. Once the simulation is done, test the sensors using the following files
https://dl.dropboxusercontent.com/u/24623828/mannasim/mannasim-rede-plana.tcl
https://dl.dropboxusercontent.com/u/24623828/mannasim/mannasim-rede-hierarquica.tcl
Run these files using
Here is the Listing for Hierarchical Simulation
Here is another listing for Planar Configuration
Prompt] ns mannasim-rede-plana.tcl
Here is the output screenshot of the above command
Fig 9.11 – Planar Simulation
Prompt] ns mannasim-rede-hierarquica.tcl
Here is the output screenshot for the above command
Fig 9.12 – hierarchical Simulation using Mannasim
Script Generation Tool
The script generation tool comes with a Java-based software that generates the above or below given Tcl code using its easier interface. Here are the sample screenshots that were used to create the Tcl script for running the Mannasim simulation.
Listing 9.3 deals with the hierarchical simulation of sensor networks, and listing 9.4 shows the planar or flat simulation of sensor networks using the script generation tool. These two listings are easy to understand as it is self-explanatory. The script, once generated, has the option to save it as an .xml file for future use without altering the parameters.
The script generation tool can be run using the ~ns-2.35/Mannasim/scriptgeneratorTool/msg-linux.sh file
Prompt] ./msg-linux.sh
Or
Prompt] bash msg-linux.sh
Screenshot for Script generation
Fig 9.13 – Basic Configuration
Fig 9.14 - Access point Configuration
Fig 9.15 - Cluster Head Selection
Fig 9.16 - Common Node Configuration
Using these script generations, the Tcl script can be triggered and using the trace files, the results can be determined. In Mannasim, there are two data generators were introduced: carbon monoxide data and temperature data. The readers can generate data of their choice depending on their application.
Conclusion:
This chapter briefs and implements the wireless sensor flooding routing protocol (WFRP), and it also implements a third-party framework called the Mannasim framework that does the simulation for carbon monoxide and temperature sensors. This chapter also shows the way to create a script to generate a wireless sensor network.
Comments
Post a Comment