MAJOR PROJECT 2012 HOTSPOT PREVENTING ROUTING ALGORITHM
CHAPTER 1
INTRODUCTION
1.1 WIRELESS SENSOR NETWORKS
A wireless sensor network (WSN) consists of spatially distributed autonomous sensors to
monitor physical or environmental conditions, such as temperature, sound, vibration,
pressure, humidity, motion or pollutants and to cooperatively pass their data through the
network to a main location. The more modern networks are bi-directional, also enabling
control of sensor activity. The development of wireless sensor networks was motivated by
military applications such as battlefield surveillance; today such networks are used in many
industrial and consumer applications, such as industrial process monitoring and control,
machine health monitoring, and so on.
The WSN is built of "nodes" – from a few to several hundreds or even thousands, where
each node is connected to one (or sometimes several) sensors. Each such sensor network
node has typically several parts: a radio transceiver with an internal antenna or connection
to an external antenna, a microcontroller, an electronic circuit for interfacing with the
sensors and an energy source, usually a battery or an embedded form of energy harvesting.
A sensor node might vary in size from that of a shoebox down to the size of a grain of dust,
although functioning "motes" of genuine microscopic dimensions have yet to be created.
The cost of sensor nodes is similarly variable, ranging from a few to hundreds of dollars,
depending on the complexity of the individual sensor nodes. Size and cost constraints on
sensor nodes result in corresponding constraints on resources such as energy, memory,
computational speed and communications bandwidth. The topology of the WSNs can vary
from a simple star network to an advanced multi-hop wireless mesh network. The
propagation technique between the hops of the network can be routing or flooding.
In computer science and telecommunications, wireless sensor networks are an active
research area with numerous workshops and conferences arranged each year.
DEPT. OF CSE 1 COLLEGE OF ENGINEERING MUNNAR
MAJOR PROJECT 2012 HOTSPOT PREVENTING ROUTING ALGORITHM
Fig. 1.1: Typical multi-hop wireless sensor network architecture
1.2 ROUTING IN WSNs
In a packet switched network, the routing protocol decides the paths that packets should
take to go from a source node to a destination node. The routes chosen for delivering
packets can greatly affect the formation of hotspots in the network.
Routing in sensor networks is very challenging due to several characteristics that distinguish
them from contemporary communication and wireless ad hoc networks. First, due to the
relatively large number of sensor nodes, it is not possible to build a global addressing
scheme for the deployment of a large number of sensor nodes as the overhead of ID
maintenance is high. Thus, traditional IP-based protocols may not be applied to WSNs. In
WSNs, sometimes getting the data is more important than knowing the IDs of which nodes
sent the data. Second, in contrast to typical communication networks, almost all
applications of sensor networks require the flow of sensed data from multiple sources to a
particular BS. Third, sensor nodes are tightly constrained in terms of energy, processing,
and storage capacities. Thus, they require careful resource management.
The design of routing protocols in WSNs is influenced by many challenging factors. These
factors must be overcome before efficient communication can be achieved in WSNs. In the
following, we summarize some of the routing challenges and design issues that affect
routing process in WSNs.
DEPT. OF CSE 2 COLLEGE OF ENGINEERING MUNNAR
MAJOR PROJECT 2012 HOTSPOT PREVENTING ROUTING ALGORITHM
Node deployment: Node deployment in WSNs is application dependent and affects the
network topology and hence the performance of the routing protocol. The deployment can
be either deterministic or randomized. In deterministic deployment, the sensors are placed at
predetermined desired locations and data is routed through predetermined paths. However,
in random node deployment, the sensor nodes are scattered randomly creating an
infrastructure in an ad hoc manner. In a multi-hop WSN, each node plays a dual role as data
source and data router. The malfunctioning of some sensor can cause significant topological
changes and might require rerouting of packets.
Fault Tolerance: Some sensor nodes may fail or be non-operational due to lack of power,
physical damage, or environmental interference. The failure of sensor nodes should not
affect the overall task of the sensor network. If nodes fail, the routing protocols must
accommodate formation of new paths to route data. Therefore some bounded redundancy
may be needed in a fault-tolerant sensor network.
Scalability: The number of sensor nodes deployed in the sensing area may be in the order of
hundreds or thousands, or more. Any routing scheme must be able to work with this huge
number of sensor nodes.
Connectivity: High node density in sensor networks prevents them from being completely
isolated from each other. Therefore, sensor nodes are expected to be highly connected. This,
however, may not prevent the network topology from being variable and the network size
from being shrinking due to sensor node failures. In addition, connectivity depends on the,
possibly random, distribution of nodes.
Coverage: In WSNs, each sensor node obtains a certain view of the environment. A given
sensor's view of the environment is limited both in range and in accuracy; it can only cover
a limited physical area of the environment. Hence, area coverage is also an important design
parameter in WSNs.
Data Aggregation: Since sensor nodes may generate a fairly large amount of redundant
data. Similar packets from multiple nodes can be aggregated so that the number of
transmissions is reduced, hence saving energy. This technique has been used to achieve
energy efficiency and data transfer optimization in a number of routing protocols.
Quality of Service: In some applications, data should be delivered within a certain period of
time from the moment it is sensed; otherwise the data will be useless. Therefore bounded
latency for data delivery is a necessary criterion for time-constrained or delay sensitive
applications. However, in many applications, conservation of energy, which is directly
DEPT. OF CSE 3 COLLEGE OF ENGINEERING MUNNAR
MAJOR PROJECT 2012 HOTSPOT PREVENTING ROUTING ALGORITHM
related to network lifetime, is considered relatively more important than the quality of data
sent.
Routing protocols must select the best path to minimize the total power needed to route
packets in the network and to maximize the lifetime of the network. That is, these protocols
should be scalable to obtain different energy and quality operating points, as the relative
importance of different resources might change over the system lifetime. Also, wireless
sensor networks need protocols which are data centric, capable of effective data
aggregation, distribute energy dissipation evenly, efficiently use their limited energy to
increase the longevity of the network and avoid any single point bottleneck (except the
sink).
A very large number of routing algorithms have been developed for wireless sensor
networks. They deal with various design constraints like load balancing, energy efficiency
and delay constraints.
One of the most conventional approaches in the design of a routing protocol for sensor
networks is based on conserving the node’s energy. Thus many power aware routing
protocols have been proposed. QoS-aware protocols on the other hand consider end-to-end
delay requirements.
1.3 ABOUT PROJECT
Deployment of large number of sensor nodes for diverse applications and the presence of
application-specific constraints have posed many challenges to the design and management
of sensor networks. Smart embedded biomedical sensors have the potential to bring a
radical change in medical diagnosis. Such sensors can be implanted in various parts of the
human body for sensing and monitoring of biometrics. Networks of such embedded sensors
can be used in artificial retina, glucose level monitors, organ monitors, cancer detectors and
a wide range of other medical applications. Rapid development of in-vivo smart sensors to
remedy medical problems has a lot of benefits to individuals and the society as a whole.
Once the technology of developing such in-vivo sensor networks gets more developed, the
medical costs for correcting chronic medical conditions will be greatly reduced. Existing
communication protocols may not be appropriate for use in networks of biomedical sensors
since such networks impose some additional constraints on the protocols. Communication
radiation and power dissipation of the implanted sensor nodes can cause serious health
hazards. A high temperature of the embedded nodes for a very long time might damage the
DEPT. OF CSE 4 COLLEGE OF ENGINEERING MUNNAR
MAJOR PROJECT 2012 HOTSPOT PREVENTING ROUTING ALGORITHM
surrounding tissues. The heat produced by the sensor nodes might also foster the growth of
certain bacteria which would otherwise be absent. It might also have a subtle effect on the
enzymatic reactions inside the body. So the communication protocols must aim at reducing
the maximum temperature rise of the nodes in the in-vivo sensor network. There are certain
delay-sensitive medical applications where a large delay in communicating the sensed
information to the base-station might be fatal. Certain other real-time applications need to
transmit the sensed data with minimum delay to the base-station. So the communication
protocols also need to minimize the delay in communicating the sensed information to the
base-station.
1.4 ABOUT DEVELOPING TOOLS
1.4.1 FEATURES OF OPERATING SYSTEM (Windows 7)
Windows 7 is the current release of Microsoft Windows, a series of operating systems
produced by Microsoft for use on personal computers, including home and business
desktops, laptops, netbooks, tablet PCs, and media center PCs.
Windows 7 includes a number of new features, such as advances in touch and handwriting
recognition, support for virtual hard disks, improved performance on multi-core processors,
improved boot performance, DirectAccess, and kernel improvements. ReadyBoost on 32-bit
editions now supports up to 256 gigabytes of extra allocation. For developers, Windows 7
includes a new networking API with support for building SOAP-based web services in
native code (as opposed to .NET-based WCF web services), new features to shorten
application install times, reduced UAC prompts, simplified development of installation
packages, and improved globalization support through a new Extended Linguistic Services
API.
1.4.2 FEATURES OF SIMULATOR
OMNET++
OMNeT++ is an object-oriented modular discrete event network simulation
framework. It has a generic architecture, so it can be (and has been) used in various
problem domains:
_ modeling of wired and wireless communication networks
_ protocol modeling
DEPT. OF CSE 5 COLLEGE OF ENGINEERING MUNNAR
MAJOR PROJECT 2012 HOTSPOT PREVENTING ROUTING ALGORITHM
_ modeling of queuing networks
_ modeling of multiprocessors and other distributed hardware systems
_ validating of hardware architectures
_ evaluating performance aspects of complex software systems
_ in general, modeling and simulation of any system where the discrete event
approach is suitable, and can be conveniently mapped into entities communicating
by exchanging messages.
OMNeT++ itself is not a simulator of anything concrete, but rather provides
infrastructure and tools for writing simulations. One of the fundamental ingredients
of this infrastructure is component architecture for simulation models. Models are
assembled from reusable components termed modules. Well-written modules are
truly reusable, and can be combined in various ways like LEGO blocks.
Modules can be connected with each other via gates (other systems would call them
ports), and combined to form compound modules. The depth of module nesting is
not limited. Modules communicate through message passing, where messages may
carry arbitrary data structures.
Modules can pass messages along predefined paths via gates and connections, or
directly to their destination; the latter is useful for wireless simulations, for example.
Modules may have parameters that can be used to customize module behavior
and/or to parameterize the model’s topology. Modules at the lowest level of the
module hierarchy are called simple modules, and they encapsulate model behavior.
Simple modules are programmed in C++, and make use of the simulation library.
OMNeT++ simulations can be run under various user interfaces. Graphical,
animating user interfaces are highly useful for demonstration and debugging
purposes, and command-line user interfaces are best for batch execution.
The simulator as well as user interfaces and tools are highly portable. They are
tested on the most common operating systems (Linux, Mac OS/X, Windows), and
they can be compiled out of the box or after trivial modifications on most Unix-like
operating systems.
OMNeT++ also supports parallel distributed simulation. OMNeT++ can use several
mechanisms for communication between partitions of a parallel distributed
simulation, for example MPI or named pipes. The parallel simulation algorithm can
easily be extended or new ones can be plugged in. Models do not need any special
DEPT. OF CSE 6 COLLEGE OF ENGINEERING MUNNAR
MAJOR PROJECT 2012 HOTSPOT PREVENTING ROUTING ALGORITHM
instrumentation to be run in parallel – it is just a matter of configuration. OMNeT++
can even be used for classroom presentation of parallel simulation algorithms,
because simulations can be run in parallel even under the GUI that provides detailed
feedback on what is going on. OMNEST is the commercially supported version of
OMNeT++. OMNeT++ is free only for academic and non-profit use; for commercial
purposes, one needs to obtain OMNEST licenses from Simulcraft Inc.
MIXIM
Discrete event simulators like OMNeT++ are a standard tool to study protocols for
wired and wireless networks. In contrast to the wired channel, the wireless channel
has a complex influence on protocol performance and it requires in-depth
knowledge of the effects before a researcher can determine the right level of detail
necessary to make a sound performance analysis. If he needs a very detailed model,
an implementation from scratch is a tedious and error prone task, but this
implementation might be useful for other researchers as well. We therefore present
MiXiM, a mixed simulator combining various simulation frameworks developed for
wireless and mobile simulations in OMNeT++.
Although OMNeT++ provides a powerful and clear simulation framework, it lacks
of direct support and a concise modeling chain for wireless communication. Both is
provided by MiXiM. MiXiM joins and extends several existing simulation
frameworks developed for wireless and mobile simulations in OMNeT++. It
provides detailed models of the wireless channel (fading, etc.), wireless
connectivity, mobility models, models for obstacles and many communication
protocols especially at the Medium Access Control (MAC) level. Further, it
provides a user-friendly graphical representation of wireless and mobile networks in
OMNeT++, supporting debugging and defining even complex wireless scenarios.
Though still in development, MiXiM already is a powerful tool for performance
analysis of wireless networks. Its extensive functionality and clear concept may
motivate researches to contribute to this open-source project
1.5 RELATED WORKS
Routing in sensor networks is very challenging due to several characteristics that distinguish
them from contemporary communication and wireless ad hoc networks. One of the most
DEPT. OF CSE 7 COLLEGE OF ENGINEERING MUNNAR
MAJOR PROJECT 2012 HOTSPOT PREVENTING ROUTING ALGORITHM
conventional approaches in the design of a routing protocol for sensor networks is based on
conserving the node’s energy. Thus many power aware routing protocols have been
proposed. QoS-aware protocols on the other hand consider end-to-end delay requirements.
The above algorithms cannot be used in implanted biosensor networks, as they do not
consider heating of the tissues surrounding the nodes as a constraint. To our knowledge, the
only routing algorithms that consider the heat produced due to communication as a
constraint are the Thermal Aware Routing Algorithm or TARA and the Adaptive Least
Temperature Routing algorithm or ALTR.
1.5.1 TARA AND ALTR
TARA takes into consideration the heating factors resulting from the operation of sensor
nodes and routes data to minimize thermal effects in a heat-sensitive environment. It also
introduces less traffic congestion in the network because thermal-awareness of TARA
technically equals to a load balancing capability. TARA is compared with a shortest-hop
routing protocol. The smaller maximum temperature rise and average temperature rise of
TARA indicate that TARA is a safer routing solution for implanted applications without
significant degradation on delay performance. TARA routes the data away from high
temperature areas (hot spots). Basically, each node listens to its neighbor’s activity,
counting the packets they transmitted and received. The node can then evaluate the
communication radiation and power dissipation of its neighbors, and estimate their
temperature change. Once the temperature of one neighbor exceeds a predefined threshold,
the node would mark that neighbor as a hot spot and would route packets around the hot
spot area by a withdrawal strategy. The essence of this withdrawal strategy is as follows.
When a node gets a packet and all of its outgoing neighbors are hot spots, it returns the
packet to the sender (previous node). The previous node would try to send the packet to an
alternative node or may send it to the previous node. In summary, TARA tries to solve the
problem of tissue heating by a strategy that withdraws packets from heated zones and route
them through alternate paths. The ALTR algorithm previously aims at reducing the total
amount of heat produced in the network and does not address the issue of formation of
hotspots in the network. Hotspot Preventing Routing algorithm (HPR) that prevents the
formation of hotspots in the network and is more suitable for being used in embedded
biomedical sensor networks than ALTR algorithm, and compare its performance with
TARA and the Shortest Hop Routing (SHR) algorithm.
DEPT. OF CSE 8 COLLEGE OF ENGINEERING MUNNAR
MAJOR PROJECT 2012 HOTSPOT PREVENTING ROUTING ALGORITHM
CHAPTER 2
PROBLEM STATEMENT
Our company uses a system of wireless sensor nodes connected in network. The system can
be placed in any normal environment and uses one of the fastest wireless routing
techniques. But the problem on the current system is that sensor nodes get heated up faster
due to routing of data through common nodes thus leading to destruction of the nodes. Also
this creates problems in the network as failure of one node affects the routing of subsequent
packets. We need to avoid this problem by any means but it should not affect the delivery
rate of the packets.
DEPT. OF CSE 9 COLLEGE OF ENGINEERING MUNNAR
MAJOR PROJECT 2012 HOTSPOT PREVENTING ROUTING ALGORITHM
CHAPTER 3ALGORITHM
3.1 SETUP PHASE
The nodes exchange information about the initial temperature and the shortest path
information and build the routing tables.
3.2 ROUTING PHASE• Each sensor node handles two types of packets, those that originate at the node itself due
to sensing and those that are coming from other nodes to be routed to destination. Both
types of packets are treated in the same way by the node.
• Each node tries to route the packets in such a way that the packets get delivered to the
destination using the minimum number of hops, i.e. the shortest path, unless there is a
hotspot in the path.
• If the destination of the packet is a neighbouring node, the packet is forwarded directly to
the destination.
• Else if the next-hop in the shortest path to the destination has a temperature less than or
equal to the temperature of the node plus a threshold, the packet is forwarded to the next-
hop node in the shortest path to the destination.
• Else if the next hop in the shortest path to the destination has a temperature greater than
the temperature of the current node plus a threshold:
o The node predicts that the path under consideration goes through a hotspot
and tries to bypass the hotspot and route the packet.
o The node forwards the packet to the neighbour node that has not been visited
and has the least temperature or is the “coolestneighbour”.
o Each packet maintains a small list of nodes it has most recently visited. If the
“coolestneighbour” is already there in the list of recently visited nodes for
the packet, the packet is forwarded to the neighbour having second lowest
temperature among all the neighbouring nodes and so on.
• Experiments show that with the increase in the packet injection rate in the system, the
average temperature of the nodes increases. So does the variation in temperature among the
neighbouring nodes. The value of the threshold is dynamically set based on the local load
DEPT. OF CSE 10 COLLEGE OF ENGINEERING MUNNAR
MAJOR PROJECT 2012 HOTSPOT PREVENTING ROUTING ALGORITHM
(number of packets routed by the node over a past time window) and the temperature of the
neighbouring nodes. Both factors are given equal weight in calculating the threshold value.
• The temperature of a node gives a measure of the number of packets routed by it over a
past window and hence the load handled. Hence the threshold value depends on two
components:
o Component C1: A function of the average temperature of the neighbouring
nodes.
o Component C2: A function of the node’s own temperature.
• C1 and C2 are found out by experiments.
o C1 = k1 * √ avg_n
o C2 = k2 * √ temp_n
where k1 and k2 are constants, avg_nis the average temperature of the node’s neighbours
and temp_nis the temperature of the node.
• The threshold is calculated giving equal weights to the two components.
threshold = 0.5 * C1 + 0.5 * C2.
• The nodes periodically exchange their temperature information with the neighbors.
• Each packet has a hop-count which is incremented by one each time a node forwards a
packet.
• Once a node gets a packet, it checks the hop-count. If it is above a certain threshold value
MAX_HOPS, the packet is discarded. The value of MAX_HOPS depends on the diameter
of the sensor network.
DEPT. OF CSE 11 COLLEGE OF ENGINEERING MUNNAR
MAJOR PROJECT 2012 HOTSPOT PREVENTING ROUTING ALGORITHM
CHAPTER 4
IMPLEMENTATION
/*HSPRouting.cc*/
#include <limits>#include <algorithm>
#include "HSPRouting.h"#include <cassert>
Define_Module(HSPRouting);
void HSPRouting::initialize(int stage){
BaseNetwLayer::initialize(stage);
if(stage == 1) {
EV << "Host index=" << findHost()->getIndex() << ", Id="<< findHost()->getId() << endl;
EV << " host IP address=" << myNetwAddr << endl;EV << " host macaddress=" << arp->getMacAddr(myNetwAddr) <<
endl;macaddress = arp->getMacAddr(myNetwAddr);
sinkAddress = par("sinkAddress"); // 0headerLength = par ("headerLength");rssiThreshold = par("rssiThreshold");routeFloodsInterval = par("routeFloodsInterval");
stats = par("stats");trace = par("trace");debug = par("debug");useSimTracer = par("useSimTracer");floodSeqNumber = 0;
nbDataPacketsForwarded = 0;nbDataPacketsReceived = 0;nbDataPacketsSent = 0;nbDuplicatedFloodsReceived = 0;nbFloodsSent = 0;nbPureUnicastSent = 0;nbRouteFloodsSent = 0;nbRouteFloodsReceived = 0;nbUnicastFloodForwarded = 0;nbPureUnicastForwarded = 0;nbGetRouteFailures = 0;
DEPT. OF CSE 12 COLLEGE OF ENGINEERING MUNNAR
MAJOR PROJECT 2012 HOTSPOT PREVENTING ROUTING ALGORITHM
nbRoutesRecorded = 0;nbHops = 0;receivedRSSI.setName("receivedRSSI");routeRSSI.setName("routeRSSI");allReceivedRSSI.setName("allReceivedRSSI");receivedBER.setName("receivedBER");routeBER.setName("routeBER");allReceivedBER.setName("allReceivedBER");nextHopSelectionForSink.setName("nextHopSelectionForSink");
routeFloodTimer = new cMessage("route-flood-timer", SEND_ROUTE_FLOOD_TIMER);
if (routeFloodsInterval > 0 && myNetwAddr==sinkAddress)scheduleAt(simTime() + uniform(0.5, 1.5),
routeFloodTimer);
if(useSimTracer) { const char *tracerModulePath = "sim.simTracer"; cModule *modp =
simulation.getModuleByPath(tracerModulePath); tracer = check_and_cast<SimTracer *>(modp);}BaseMobility * mobility;mobility = check_and_cast<BaseMobility*>(getParentModule()-
>getSubmodule("mobility"));if(useSimTracer) {
// tracer->logPosition(myNetwAddr, mobility->getX(), mobility->getY());
}}
}
HSPRouting::~HSPRouting(){
cancelAndDelete(routeFloodTimer);}
void HSPRouting::handleSelfMsg(cMessage* msg){
if (msg->getKind() == SEND_ROUTE_FLOOD_TIMER) {// Send route flood packet and restart the timerint macBcastAddr = L2BROADCAST;int ipBcastAddr = L3BROADCAST;HSPRoutingPkt* pkt = new HSPRoutingPkt("route-flood",
ROUTE_FLOOD);pkt->setByteLength(headerLength);pkt->setInitialSrcAddr(myNetwAddr);pkt->setFinalDestAddr(ipBcastAddr);pkt->setSrcAddr(myNetwAddr);pkt->setDestAddr(ipBcastAddr);pkt->setNbHops(0);floodTable.insert(make_pair(myNetwAddr, floodSeqNumber));pkt->setSeqNum(floodSeqNumber);floodSeqNumber++;pkt->setIsFlood(1);pkt->setControlInfo(new NetwToMacControlInfo(macBcastAddr));sendDown(pkt);nbFloodsSent++;nbRouteFloodsSent++;
DEPT. OF CSE 13 COLLEGE OF ENGINEERING MUNNAR
MAJOR PROJECT 2012 HOTSPOT PREVENTING ROUTING ALGORITHM
scheduleAt(simTime() + routeFloodsInterval + uniform(0, 1), routeFloodTimer);
}else {
EV << "HSPRouting - handleSelfMessage: got unexpected message of kind " << msg->getKind() << endl;
delete msg;}
}
void HSPRouting::handleLowerMsg(cMessage* msg){
int macBcastAddr = L3BROADCAST;int bcastIpAddr = L2BROADCAST;HSPRoutingPkt* netwMsg = check_and_cast<HSPRoutingPkt*>(msg);int finalDestAddr = netwMsg->getFinalDestAddr();int initialSrcAddr = netwMsg->getInitialSrcAddr();int srcAddr = netwMsg->getSrcAddr();double rssi = static_cast<MacToNetwControlInfo*>(netwMsg-
>getControlInfo())->getRSSI();double ber = static_cast<MacToNetwControlInfo*>(netwMsg-
>getControlInfo())->getBitErrorRate();// Check whether the message is a flood and if it has to be forwarded.floodTypes floodType = updateFloodTable(netwMsg->getIsFlood(),
initialSrcAddr, finalDestAddr, netwMsg-
>getSeqNum());if(trace) { allReceivedRSSI.record(rssi); allReceivedBER.record(ber);}if (floodType == DUPLICATE) {
nbDuplicatedFloodsReceived++;delete netwMsg;
}else {
// If the message is a route flood, update the routing table.if (netwMsg->getKind() == ROUTE_FLOOD)
updateRouteTable(initialSrcAddr, srcAddr, rssi, ber);
if (finalDestAddr == myNetwAddr || finalDestAddr == bcastIpAddr) {
HSPRoutingPkt* msgCopy;if (floodType == FORWARD) {
// it's a flood.msgCopy = check_and_cast<HSPRoutingPkt*>(netwMsg-
>dup());netwMsg->setSrcAddr(myNetwAddr);
// ((NetwToMacControlInfo*) netwMsg->getControlInfo())->setNextHopMac(macBcastAddr);
netwMsg->removeControlInfo();netwMsg->setControlInfo(new
NetwToMacControlInfo(macBcastAddr));netwMsg->setNbHops(netwMsg->getNbHops()+1);sendDown(netwMsg);nbDataPacketsForwarded++;
}else
DEPT. OF CSE 14 COLLEGE OF ENGINEERING MUNNAR
MAJOR PROJECT 2012 HOTSPOT PREVENTING ROUTING ALGORITHM
msgCopy = netwMsg;if (msgCopy->getKind() == DATA) {
sendUp(decapsMsg(msgCopy));nbDataPacketsReceived++;
}else {
nbRouteFloodsReceived++;delete msgCopy;
}}else {
if (floodType == FORWARD) {netwMsg->setSrcAddr(myNetwAddr);
// ((NetwToMacControlInfo*) netwMsg->getControlInfo())->setNextHopMac(macBcastAddr);
netwMsg->removeControlInfo();netwMsg->setControlInfo(new
NetwToMacControlInfo(macBcastAddr));netwMsg->setNbHops(netwMsg->getNbHops()+1);sendDown(netwMsg);nbDataPacketsForwarded++;nbUnicastFloodForwarded++;
}else {
int nextHop = getRoute(finalDestAddr);if (nextHop == bcastIpAddr) {
// no route exist to destination, attempt to send to final destinationnextHop = finalDestAddr;nbGetRouteFailures++;
}netwMsg->setSrcAddr(myNetwAddr);netwMsg->setDestAddr(nextHop);
// ((NetwToMacControlInfo*) netwMsg->getControlInfo())->setNextHopMac(arp->getMacAddr(nextHop));
netwMsg->removeControlInfo();netwMsg->setControlInfo(new
NetwToMacControlInfo(arp->getMacAddr(nextHop)));netwMsg->setNbHops(netwMsg->getNbHops()+1);sendDown(netwMsg);nbDataPacketsForwarded++;nbPureUnicastForwarded++;
}}
}}
void HSPRouting::handleLowerControl(cMessage *msg){ delete msg;}
void HSPRouting::handleUpperMsg(cMessage* msg){
int finalDestAddr;int nextHopAddr;unsigned long nextHopMacAddr;HSPRoutingPkt* pkt = new HSPRoutingPkt(msg->getName(), DATA);NetwControlInfo* cInfo = dynamic_cast<NetwControlInfo*>(msg-
>removeControlInfo());int ipBcastAddr = L3BROADCAST;
DEPT. OF CSE 15 COLLEGE OF ENGINEERING MUNNAR
MAJOR PROJECT 2012 HOTSPOT PREVENTING ROUTING ALGORITHM
pkt->setByteLength(headerLength);
if ( cInfo == 0 ) { EV << "HSPRouting warning: Application layer did not specifiy a
destination L3 address\n" << "\tusing broadcast address instead\n"; finalDestAddr = ipBcastAddr;}else {
EV <<"HSPRouting: CInfo removed, netw addr="<< cInfo->getNetwAddr() <<endl;
finalDestAddr = cInfo->getNetwAddr();delete cInfo;
}
pkt->setFinalDestAddr(finalDestAddr);pkt->setInitialSrcAddr(myNetwAddr);pkt->setSrcAddr(myNetwAddr);pkt->setNbHops(0);
if (finalDestAddr == ipBcastAddr)nextHopAddr = ipBcastAddr;
elsenextHopAddr = getRoute(finalDestAddr, true);
pkt->setDestAddr(nextHopAddr);if (nextHopAddr == ipBcastAddr) {
nextHopMacAddr = L2BROADCAST;pkt->setIsFlood(1);nbFloodsSent++;floodTable.insert(make_pair(myNetwAddr, floodSeqNumber));pkt->setSeqNum(floodSeqNumber);floodSeqNumber++;nbGetRouteFailures++;
}else {
pkt->setIsFlood(0);nbPureUnicastSent++;nextHopMacAddr = arp->getMacAddr(nextHopAddr);
}pkt->setControlInfo(new NetwToMacControlInfo(nextHopMacAddr));assert(static_cast<cPacket*>(msg));pkt->encapsulate(static_cast<cPacket*>(msg));sendDown(pkt);nbDataPacketsSent++;
}
void HSPRouting::finish(){
if (stats) {recordScalar("nbDataPacketsForwarded",
nbDataPacketsForwarded);recordScalar("nbDataPacketsReceived", nbDataPacketsReceived);recordScalar("nbDataPacketsSent", nbDataPacketsSent);recordScalar("nbDuplicatedFloodsReceived",
nbDuplicatedFloodsReceived);recordScalar("nbFloodsSent", nbFloodsSent);recordScalar("nbPureUnicastSent", nbPureUnicastSent);recordScalar("nbRouteFloodsSent", nbRouteFloodsSent);recordScalar("nbRouteFloodsReceived", nbRouteFloodsReceived);
DEPT. OF CSE 16 COLLEGE OF ENGINEERING MUNNAR
MAJOR PROJECT 2012 HOTSPOT PREVENTING ROUTING ALGORITHM
recordScalar("nbUnicastFloodForwarded", nbUnicastFloodForwarded);
recordScalar("nbPureUnicastForwarded", nbPureUnicastForwarded);
recordScalar("nbGetRouteFailures", nbGetRouteFailures);recordScalar("nbRoutesRecorded", nbRoutesRecorded);recordScalar("meanNbHops", (double) nbHops / (double)
nbDataPacketsReceived);}
}
void HSPRouting::updateRouteTable(int origin, int lastHop, double rssi, double ber){
tRouteTable::iterator pos;
pos = routeTable.find(origin);if(trace) { receivedRSSI.record(rssi); receivedBER.record(ber);}if (pos == routeTable.end()) {
// A route towards origin does not exist yet.if (rssi > rssiThreshold) {
tRouteTableEntry newEntry;
newEntry.nextHop = lastHop;newEntry.rssi = rssi;if(trace) { routeRSSI.record(rssi); routeBER.record(ber);}routeTable.insert(make_pair(origin, newEntry));if(useSimTracer) { tracer->logLink(myNetwAddr, lastHop);}nbRoutesRecorded++;if (origin == 0 && trace) {
nextHopSelectionForSink.record(lastHop);}
}}else {
// tRouteTableEntry entry = pos->second;// if (entry.rssi > rssiThreshold) {// entry.nextHop = lastHop;// entry.rssi = rssi;// if (origin == 0)// nextHopSelectionForSink.record(lastHop);// }
}}
cMessage* HSPRouting::decapsMsg(HSPRoutingPkt *msg){
cMessage *m = msg->decapsulate();m->setControlInfo(new NetwControlInfo(msg->getSrcAddr()));nbHops = nbHops + msg->getNbHops();// delete the netw packetdelete msg;
DEPT. OF CSE 17 COLLEGE OF ENGINEERING MUNNAR
MAJOR PROJECT 2012 HOTSPOT PREVENTING ROUTING ALGORITHM
return m;}
HSPRouting::floodTypes HSPRouting::updateFloodTable(bool isFlood, int srcAddr, int destAddr, unsigned long seqNum){
if (isFlood) {tFloodTable::iterator pos = floodTable.lower_bound(srcAddr);tFloodTable::iterator posEnd =
floodTable.upper_bound(srcAddr);
while (pos != posEnd) {if (seqNum == pos->second)
return DUPLICATE; ++pos;
}floodTable.insert(make_pair(srcAddr, seqNum));if (destAddr == myNetwAddr)
return FORME;else
return FORWARD;}else
return NOTAFLOOD;}
int HSPRouting::getRoute(int destAddr, bool iAmOrigin){
// Find a route to dest address. tRouteTable::iterator pos = routeTable.find(destAddr);if (pos != routeTable.end())
return pos->second.nextHop;else
return L3BROADCAST;}
/*HSPRouting.h*/
#ifndef HSPRouting_h#define HSPRouting_h
#include <omnetpp.h>
#include <BaseNetwLayer.h>#include <BaseMobility.h>#include <fstream>#include "HSPRoutingPkt_m.h"#include "MacPkt_m.h"#include "BaseMacLayer.h"#include "SimTracer.h"#include "NetwControlInfo.h"#include "NetwToMacControlInfo.h"#include "MacToNetwControlInfo.h"
#include <map>#include <list>
DEPT. OF CSE 18 COLLEGE OF ENGINEERING MUNNAR
MAJOR PROJECT 2012 HOTSPOT PREVENTING ROUTING ALGORITHM
#include <math.h>
using namespace std;
class HSPRouting : public BaseNetwLayer{public: /** @brief Initialization of the module and some variables*/ virtual void initialize(int); virtual void finish();
~HSPRouting();
protected:enum messagesTypes { UNKNOWN=0, DATA, ROUTE_FLOOD, SEND_ROUTE_FLOOD_TIMER};
typedef enum floodTypes {NOTAFLOOD,FORWARD,FORME,DUPLICATE
} floodTypes;
typedef struct tRouteTableEntry {int nextHop;double rssi;
} tRouteTableEntry;
typedef map<int, tRouteTableEntry> tRouteTable;typedef multimap<int, unsigned long> tFloodTable;
tRouteTable routeTable;tFloodTable floodTable;
int headerLength;
// int myNetwAddr; int macaddress;
int sinkAddress;
bool useSimTracer;
double rssiThreshold;
double routeFloodsInterval;
unsigned long floodSeqNumber;
SimTracer *tracer; cMessage* routeFloodTimer;
long nbDataPacketsForwarded;
DEPT. OF CSE 19 COLLEGE OF ENGINEERING MUNNAR
MAJOR PROJECT 2012 HOTSPOT PREVENTING ROUTING ALGORITHM
long nbDataPacketsReceived; long nbDataPacketsSent; long nbDuplicatedFloodsReceived; long nbFloodsSent; long nbPureUnicastSent; long nbRouteFloodsSent; long nbRouteFloodsReceived; long nbUnicastFloodForwarded; long nbPureUnicastForwarded; long nbGetRouteFailures; long nbRoutesRecorded; long nbHops;
cOutVector receivedRSSI; cOutVector routeRSSI; cOutVector allReceivedRSSI; cOutVector allReceivedBER; cOutVector routeBER; cOutVector receivedBER; cOutVector nextHopSelectionForSink;
bool trace, stats, debug;
virtual void handleUpperMsg(cMessage* msg);
virtual void handleLowerMsg(cMessage* msg);
virtual void handleSelfMsg(cMessage* msg);
virtual void handleLowerControl(cMessage* msg);
virtual void updateRouteTable(int origin, int lastHop, double rssi, double ber);
cMessage* decapsMsg(HSPRoutingPkt *msg);
floodTypes updateFloodTable(bool isFlood, int srcAddr, int destAddr, unsigned long seqNum);
int getRoute(int destAddr, bool iAmOrigin = false);};
#endif
DEPT. OF CSE 20 COLLEGE OF ENGINEERING MUNNAR
MAJOR PROJECT 2012 HOTSPOT PREVENTING ROUTING ALGORITHM
CHAPTER 5
SIMULATION
5.1 QUICK OVER VIEW OF SIMULATION WITH OMNeT++
1. An OMNeT++ model is build from components (modules) which
communicate by exchanging messages. Modules can be nested, that is,
several modules can be grouped together to form a compound module. When creating
the model, you need to map your system into a hierarchy of communicating modules.
2. Define the model structure in the NED language. You can edit NED in a
text editor or in the graphical editor of the Eclipse-based OMNeT++
Simulation IDE.
3. The active components of the model (simple modules) have to be
programmed in C++, using the simulation kernel and class library
4. Provide a suitable omnetpp.ini to hold OMNeT++ configuration and
parameters to your model. A config file can describe several simulation
runs with different parameters.
5. Build the simulation program and run it. You'll link the code with the
OMNeT++ simulation kernel and one of the user interfaces OMNeT++
provides. There are command line (batch) and interactive, graphical user interfaces.
DEPT. OF CSE 21 COLLEGE OF ENGINEERING MUNNAR
MAJOR PROJECT 2012 HOTSPOT PREVENTING ROUTING ALGORITHM
6. Simulation results are written into output vector and output scalar files.
You can use the Analysis Tool in the Simulation IDE to visualize them.
Result files are text-based, so you can also process them with R, Matlab or other tools.
5.2 THE NED EDITOR
The NED Editor in graphical editing mode
The NED Editor can edit NED files both graphically or in text mode, and the user can
switch between the two modes at any time, using the tabs at the bottom of the editor
window.
In graphical mode, one can create compound modules, channels, and other component
types. Submodules can be created using the palette of available module types. Visual and
non-visual properties can be modified in the Properties View, or by dialogs invoked from
the context menu. The editor offers many features such as unlimited undo/redo, object
cloning, constrained move and resize, alignment of objects, and zooming.
Submodules can be pinned (having a fixed position), or unpinned (auto-layout). Graphical
features that can be edited are background image, background grid, default icons (via
display string inheritance), icon sizing and coloring, transmission range, and many others.
Properties view
The Properties View lets the user edit graphical and non-graphical properties of objects.
Special cell editors facilitate selecting colors, icons, etc. Undo and redo is supported for
property changes too. The Properties View is also used with other editors like the Result
Analysis editor, where it allows the user to customize charts and other objects.
The NED Editor in source editing mode
Text mode lets the user work with the NED source directly. When hitting Ctrl+Space, the
editor offers context-aware completion of keywords and module type, parameter, gate, and
submodule names. Template proposals to insert full compound module skeletons,
submodules, various connection structures, etc. are also available. Documentation of
DEPT. OF CSE 22 COLLEGE OF ENGINEERING MUNNAR
MAJOR PROJECT 2012 HOTSPOT PREVENTING ROUTING ALGORITHM
referenced module types can be viewed by hovering over the NED type name. The NED
source is continually parsed and validated as the user is typing, and errors are displayed in
real time on the left margin. Syntax highlighting, automatic indentation, and automatic
conversion from the OMNeT++ 3.x NED syntax are also provided.
Outline View
The Outline View shows the structure of NED files in both graphical and text editing mode,
and allows navigation, as well.
Other Views
The Module Hierarchy View and the NED Parameters View can also be used with the NED
Editor (they will display the submodule hierarchy and the parameters of the selected module
or submodule) – these views will be described with the Ini File Editor. Further related views
are the Problems View (which displays errors and warnings in NED files and other files),
and Tasks View (which shows a list of all FIXME and TODO comments found in NED
files and other source files.)
5.3 THE ini FILE EDITOR
The Ini File Editor lets the user configure simulation models for execution. It features both
form-based and source editing.
Form-based ini file editing
The Ini File editor considers all supported configuration options and offers them in several
forms, organized by topics. Descriptions and default values are displayed in tooltips, which
can be made persistent for easier reading. The structure of the ini file (sections and their
inheritance tree) is also visualized and editable via drag & drop and dialogs. Validation and
content assist (Ctrl+Space) are also provided where needed. The editor supports unlimited
undo/redo and automatic conversion from OMNeT++ 3.x ini files.
The ini file source editor
DEPT. OF CSE 23 COLLEGE OF ENGINEERING MUNNAR
MAJOR PROJECT 2012 HOTSPOT PREVENTING ROUTING ALGORITHM
The text editor lets the user work with the ini file directly, which is more efficient for
advanced users than forms. Unlimited undo/redo, syntax coloring, and completion of
configuration keys, values, and module parameter patterns (on Ctrl+Space) are provided. As
the user types, the file is continually analyzed and errors/warnings are displayed in real
time.
The editor considers all NED declarations (simple modules, compound modules, channels,
etc.) and can fully exploit this information to provide diagnostics and assistance to the user.
Looking at the network= configuration key, it knows the top-level compound module NED
type, and internally builds a static picture of the network by recursively enumerating the
top-level module's submodules, sub-submodules, sub-sub-submodules, etc., and continually
relates this information to the ini file contents. Thus, the editor always knows which ini file
keys match which module parameters, which are the ini file keys that are unused (will not
match anything), and which module parameters are still open (i.e. have no value assigned
yet). It displays this information in tooltips, as warnings, and in various views.
The Add Missing Keys dialog
To speed up the process of creating ini files from scratch, the editor offers an Add Missing
Keys dialog. After clicking OK, the editor will insert ini file keys for all open NED
parameters. The user will only need to supply the values.
Module Hierarchy View
The Module Hierarchy View displays the submodule hierarchy of the current
configuration's network, together with the module's parameters. It shows how module
parameters obtain their values (from NED, by applying a NED default value, or from the ini
file). It is able to resolve simple cases where a submodule type comes from a string
parameter (NED's like keyword). By using the context menu, the user can go to the NED
declaration of a module, submodule, parameter, gate, or to the place where a parameter gets
its value (in NED or in the ini file).
The View can be pinned to a particular editor to prevent its contents from changing when
the user switches across NED and ini file editors.
DEPT. OF CSE 24 COLLEGE OF ENGINEERING MUNNAR
MAJOR PROJECT 2012 HOTSPOT PREVENTING ROUTING ALGORITHM
The NED Parameters View
By default, the NED Parameters View displays the table of all unassigned NED parameters
in the current configuration's network and it can be switched over to show all parameters,
assigned or unassigned. For assigned parameters, it shows how they obtain their values
(from NED, by applying a NED default value, or from the ini file). The user can open the
relevant places in the NED files or the ini file. This View can also be pinned.
The Problems View
The Problems View presents errors, warnings, and info messages in NED files, ini files, and
other source files in a unified manner. Double-clicking on an item opens the corresponding
file and goes to the error's location. The view's contents can be filtered in various ways
(current file, current project, all projects, by severity, etc).
Other View
The Outline View displays the list of sections in the current ini file and can be used for
navigation as well.
5.4 SIMULATION LAUNCHER
The OMNeT++ IDE makes it possible to run simulations directly from the integrated
environment. It is possible to run a simulation as a normal C/C++ application and perform
C++ source-level debugging on it. The user can also run it as a standalone application
(under Tkenv or Cmdenv) or run batches of simulations where runs differ in module
parameter settings or random number seeds (NOTE: an Eclipse-based runtime environment
[“IDEEnv”] does not exist yet; it is planned for future releases).
The Run dialog showing a simulation launch configuration
In the Eclipse IDE, the various ways of launching a program under development is
described by launch configurations. There are various launch configuration types (C/C++
Application, Java Application, etc.). To launch a program for the first time, the user creates
an instance of a launch configuration, fills in a form (program name, command-line
arguments, etc.), and hits the Run button. OMNeT++ provides launch configuration types
DEPT. OF CSE 25 COLLEGE OF ENGINEERING MUNNAR
MAJOR PROJECT 2012 HOTSPOT PREVENTING ROUTING ALGORITHM
for simulations: one extends the normal “C/C++ Local Application” launch type with a
Simulation tab (for convenient editing of simulation-related command-line options), and a
standalone launch type for launching a simulation or running simulation batches. The
former can be used for C++ debugging, as well.
The dialog shows a standalone launch type for the QueueNet example simulation model.
Batch simulations can be launched by specifying more than one run number in the dialog.
Ini files allow the user to define various scenarios iterating over a list of values for certain
NED parameters, and/or do multiple runs with different seeds. The launch dialog helps the
user select the desired run numbers by showing which runs correspond to which parameters
and seed settings.
Multi-processor or multi-core computers can be exploited by specifying that more than one
process may be launched (i.e. may be running) at a time.
Progress View
The Progress View reports the status of simulation execution when you have a long-running
simulation, or you are executing several runs in a batch. It is possible to cancel the whole
batch operation with a single click, if necessary. Simulations run in separate processes that
do not block the IDE, so users can keep working while their simulations run in the
background. In the above screenshot, the number of processes to run in parallel was set to 2;
run #1 has already terminated (and is no longer shown), run #3 has already launched and
run #2 is still running.
Console View
Each running process sends its output to a separate console buffer within the Console View,
so the user can review the output after a simulation has finished. One can switch between
console buffers using the Console View's menu or toolbar, or by double-clicking on a
process in the Debug View.
The Debug View showing three runs in a simulation batch
The Debug View is another one of Eclipse's standard Views, but it is not only useful for
debugging. While the Progress View only shows currently executing processes, the Debug
DEPT. OF CSE 26 COLLEGE OF ENGINEERING MUNNAR
MAJOR PROJECT 2012 HOTSPOT PREVENTING ROUTING ALGORITHM
View displays the ones already terminated, as well, together with their exit codes. Processes
are marked with run numbers and launch times for easier identification. Double-clicking an
item reveals the process output in the Console View.
5.5 SEQUENCE CHART
The OMNeT++ simulation kernel is capable of logging various events during simulation:
scheduling and canceling self-messages, sending messages, display changes, module and
connection creation and deletion, user log messages, etc. The result is an event log file
which contains detailed information of the simulation, and later can be used for various
purposes, such as visualizing message exchanges among modules on a sequence chart. The
file format is line-based text to facilitate processing by third party tools.
A Sequence Chart showing ARP on a wireless network
An event log can be visualized with the Sequence Chart in the IDE. On the Sequence Chart,
events are represented as nodes, and message send/schedule/reuse operations as arrows. The
chart can be filtered according to modules, message types, and various other criteria. The
chart can also be filtered according to the causes/consequences of a particular event (this
works by following message arrows backward and forward in simulation time). The chart
timeline can be displayed in various modes, such as linear (simulation time), compact (non-
linear), and event number-based. Other features include sorting of module axes, displaying
state vector data on axes (using output vector files), zooming, and special navigation
options (bookmarks, zoom to message send, follow message send), and exporting the chart
in SVG format.
Both the Event Log Table and the Sequence Chart are capable of efficiently displaying
event log files of several gigabytes without requiring large amounts of memory.
The Event Log View
The Event Log Table displays the content of an event log file recorded during a simulation.
It supports raw and descriptive notations, line-based filtering for event log entry types and
DEPT. OF CSE 27 COLLEGE OF ENGINEERING MUNNAR
MAJOR PROJECT 2012 HOTSPOT PREVENTING ROUTING ALGORITHM
various parameters, search for free text, bookmarks, and special navigation options such as
"go to simulation time" or message arrival. The Event Log Table supports the same filtering
as the Sequence Chart.
SCAVE (Result Analysis)
Scave is the result analysis tool of OMNeT++ and its task is to help the user process and
visualize simulation results saved into vector and scalar files. Scave is designed so that the
user can work equally well on the output of a single simulation run (one or two files) and
the result of simulation batches (which may be several hundred files, possibly in multiple
directories). Ad-hoc browsing of the data is supported in addition to systematic and
repeatable processing. With the latter, all processing and charts are stored as “recipes”. For
example, if simulations need to be re-run due to a model bug or misconfiguration, existing
charts do not need to be drawn all over again. Simply replacing the old result files with the
new ones will result in the charts being automatically displayed with the new data.
Scave is implemented as a multi-page editor. What the editor edits is the “recipe,” which
includes what files to take as inputs, what data to select from them, what (optional)
processing to apply, and what kind of charts to create from them. The pages (tabs) of the
editor roughly correspond to these steps. You will see that Scave is much more than just a
union of the OMNeT++ 3.x Scalars and Plove tools.
Specifying input files for data analysis
The first page displays the result files that serve as input for the analysis. The upper half
specifies what files to select, by explicit filenames or by wildcards. The lower half shows
what files actually matched the input specification and what runs they contain. Note that
OMNeT++ result files contain a unique run ID and several metadata annotations in addition
to the actual recorded data. The third tree organizes simulation runs according to their
experiment—measurement—replication labels.
The underlying assumption is that users will organize their simulation-based research into
various “experiments”. An experiment will consist of several “measurements”, which are
typically (but not necessarily) simulations done with the same model but with different
parameter settings; that is, the user will explore the parameter space with several simulation
DEPT. OF CSE 28 COLLEGE OF ENGINEERING MUNNAR
MAJOR PROJECT 2012 HOTSPOT PREVENTING ROUTING ALGORITHM
runs. To gain statistical confidence in the results, each measurement will be possibly
repeated several times with different random number seeds. It is easy to set up such
scenarios with the improved ini files of OMNeT++ 4.1. Then, the experiment-measurement-
replication labels will be assigned more-or-less automatically – please refer to the ini file
document (“Configuring Simulations in OMNeT++ 4.1”) for more discussion.
Browsing vector and scalar data generated by the simulation
The second page displays results (vectors, scalars, and histograms) from all files in tables
and lets the user browse them. Results can be sorted and filtered. Simple filtering is possible
with combo boxes, or when that is not enough, the user can write arbitrarily complex filters
using a generic pattern matching expression language. Selected or filtered data can be
immediately plotted, or remembered in named datasets for further processing.
Defining datasets to be analyzed
It is possible to define reusable datasets that are basically recipes on how to select and
process data received from the simulation. You can add selection and data processing nodes
to a dataset. Chart drawing is possible at any point in the processing tree.
A Line Chart
Line charts are typically drawn from time-series data stored in vector files. Pre-processing
of the data is possible in the dataset. The line chart component can be configured freely to
display the vector data according to your needs.
A Bar Chart
Bar charts are created from scalar results and histograms. Relevant data can be grouped and
displayed via the Bar chart component. Colors, chart type, and other display attributes can
be set on the component.
Output Vector View
The Output Vector View can be used to inspect the raw numerical data when required. It
can show the original data read from the vector file, or the result of a computation. The user
DEPT. OF CSE 29 COLLEGE OF ENGINEERING MUNNAR
MAJOR PROJECT 2012 HOTSPOT PREVENTING ROUTING ALGORITHM
can select a point on the line chart or a vector in the Dataset View and its content will be
displayed.
Dataset View
The Dataset View is used to show the result items contained in the dataset. The content of
the view corresponds to the state of the dataset after the selected processing is performed.
5.6 MODELLING CONCEPTS
An OMNeT++ model consists of modules that communicate with message passing. The
active modules are termed simple modules; they are written in C++, using the simulation
class library. Simple modules can be grouped into compound modules and so forth; the
number of hierarchy levels is unlimited. The whole model, called network in OMNeT++, is
itself a compound module. Messages can be sent either via connections that span modules
or directly to other modules. The concept of simple and compound modules is similar to
DEVS atomic and coupled models.
In Figure below, boxes represent simple modules (gray background) and compound
modules. Arrows connecting small boxes represent connections and gates.
Figure 5.1: Modeling concepts
Modules communicate with messages that may contain arbitrary data, in addition to usual
attributes such as a timestamp. Simple modules typically send messages via gates, but it is
also possible to send them directly to their destination modules. Gates are the input and
output interfaces of modules: messages are sent through output gates and arrive through
DEPT. OF CSE 30 COLLEGE OF ENGINEERING MUNNAR
MAJOR PROJECT 2012 HOTSPOT PREVENTING ROUTING ALGORITHM
input gates. An input gate and output gate can be linked by a connection. Connections are
created within a single level of module hierarchy; within a compound module,
corresponding gates of two submodules, or a gate of one submodule and a gate of the
compound module can be connected. Connections spanning hierarchy levels are not
permitted, as they would hinder model reuse. Because of the hierarchical structure of the
model, messages typically travel through a chain of connections, starting and arriving in
simple modules. Compound modules act like "cardboard boxes" in the model, transparently
relaying messages between their inner realm and the outside world. Parameters such as
propagation delay, data rate and bit error rate, can be assigned to connections. One can also
define connection types with specific properties (termed channels) and reuse them in several
places. Modules can have parameters. Parameters are used mainly to pass configuration data
to simple modules, and to help define model topology. Parameters can take string, numeric,
or boolean values. Because parameters are represented as objects in the program,
parameters -- in addition to holding constants -- may transparently act as sources of random
numbers, with the actual distributions provided with the model configuration. They may
interactively prompt the user for the value, and they might also hold expressions referencing
other parameters. Compound modules may pass parameters or expressions of parameters to
their submodules.
Hierarchical Modules
An OMNeT++ model consists of hierarchically nested modules that communicate by
passing messages to each other. OMNeT++ models are often referred to as networks. The
top level module is the system module. The system module contains submodules that can
also contain submodules themselves. The depth of module nesting is unlimited, allowing the
user to reflect the logical structure of the actual system in the model structure.
Model structure is described in OMNeT++'s NED language.
Modules that contain submodules are termed compound modules, as opposed to simple
modules at the lowest level of the module hierarchy. Simple modules contain the algorithms
of the model. The user implements the simple modules in C++, using the OMNeT++
simulation class library.
DEPT. OF CSE 31 COLLEGE OF ENGINEERING MUNNAR
MAJOR PROJECT 2012 HOTSPOT PREVENTING ROUTING ALGORITHM
Module Types
Both simple and compound modules are instances of module types. In describing the model,
the user defines module types; instances of these module types serve as components for
more complex module types. Finally, the user creates the system module as an instance of a
previously defined module type; all modules of the network are instantiated as submodules
and sub-submodules of the system module.
When a module type is used as a building block, it makes no difference whether it is a
simple or compound module. This allows the user to split a simple module into several
simple modules embedded into a compound module, or vice versa, to aggregate the
functionality of a compound module into a single simple module, without affecting existing
users of the module type.
Module types can be stored in files separately from the place of their actual usage. This
means that the user can group existing module types and create component libraries.
Messages, Gates, Links
Modules communicate by exchanging messages. In an actual simulation, messages can
represent frames or packets in a computer network, jobs or customers in a queuing network
or other types of mobile entities. Messages can contain arbitrarily complex data structures.
Simple modules can send messages either directly to their destination or along a predefined
path, through gates and connections. The “local simulation time” of a module advances
when the module receives a message. The message can arrive from another module or from
the same module (self-messages are used to implement timers).
Gates are the input and output interfaces of modules; messages are sent out through output
gates and arrive through input gates.
Each connection (also called link) is created within a single level of the module hierarchy:
within a compound module, one can connect the corresponding gates of two submodules, or
a gate of one submodule and a gate of the compound module
Because of the hierarchical structure of the model, messages typically travel through a
series of connections, starting and arriving in simple modules. Compound modules act like
DEPT. OF CSE 32 COLLEGE OF ENGINEERING MUNNAR
MAJOR PROJECT 2012 HOTSPOT PREVENTING ROUTING ALGORITHM
“cardboard boxes” in the model, transparently relaying messages between their inner realm
and the outside world.
Modeling of Packet Transmissions
To facilitate the modeling of communication networks, connections can be used to model
physical links. Connections support the following parameters: data rate, propagation delay,
bit error rate and packet error rate, and may be disabled. These parameters and the
underlying algorithms are encapsulated into channel objects. The user can parameterize the
channel types provided by OMNeT++, and also create new ones.
When data rates are in use, a packet object is by default delivered to the target module at the
simulation time that corresponds to the end of the packet reception. Since this behavior is
not suitable for the modeling of some protocols (e.g. half-duplex Ethernet), OMNeT++
provides the possibility for the target module to specify that it wants the packet object to be
delivered to it when the packet reception starts.
Parameters
Modules can have parameters. Parameters can be assigned in either the NED files or the
configuration file omnetpp.ini.
Parameters can be used to customize simple module behavior, and to parameterize the
model topology.
Parameters can take string, numeric or boolean values, or can contain XML data trees.
Numeric values include expressions using other parameters and calling C functions, random
variables from different distributions, and values input interactively by the user.
Numeric-valued parameters can be used to construct topologies in a flexible way. Within a
compound module, parameters can define the number of submodules, number of gates, and
the way the internal connections are made.
Parameters can get their value from NED files or from the configuration (omnetpp.ini). A
default value can also be given (default(...)), which is used if the parameter is not
assigned otherwise.
DEPT. OF CSE 33 COLLEGE OF ENGINEERING MUNNAR
MAJOR PROJECT 2012 HOTSPOT PREVENTING ROUTING ALGORITHM
The Parameters used in our simulation is given below.
Node.ned
network WSNRouting {
parameters: double playgroundSizeX @unit(m); double playgroundSizeY @unit(m); double playgroundSizeZ @unit(m); double numHosts;
@display("bgb=$playgroundSizeX,$playgroundSizeY,white,,;bgp=10,50"); submodules: connectionManager: ConnectionManager { parameters: @display("p=225,40;b=42,42,rect,yellow;i=abstract/multicast");
} world: BaseWorldUtility { parameters: playgroundSizeX = playgroundSizeX; playgroundSizeY = playgroundSizeY; playgroundSizeZ = playgroundSizeZ; @display("p=30,0;i=misc/globe"); } node[numHosts]: Host802154_2400MHz { parameters: numHosts = numHosts; @display("p=75,130;b=42,42,rect,yellow;i=device/wifilaptop");
} connections allowunconnected:}
ini file
**.coreDebug = false**.debug = false**.playgroundSizeX = 1000 m**.playgroundSizeY = 1000 m**.playgroundSizeZ = 100 m**.numHosts = ${numHosts=5,25}
**.world.useTorus = false**.world.use2D = true
**.connectionManager.sendDirect = false**.connectionManager.pMax = 1.1mW**.connectionManager.sat = -100dBm**.connectionManager.alpha = 2.0**.connectionManager.carrierFrequency = 2.4E+9Hz
**.node[*].nic.phy.usePropagationDelay = false**.node[*].nic.phy.analogueModels = xmldoc("config.xml")
DEPT. OF CSE 34 COLLEGE OF ENGINEERING MUNNAR
MAJOR PROJECT 2012 HOTSPOT PREVENTING ROUTING ALGORITHM
**.node[*].nic.phy.sensitivity = -100dBm**.node[*].nic.phy.maxTXPower = 1.1mW**.node[*].nic.phy.initialRadioState = 0**.node[*].nic.phy.useThermalNoise = true
**.node[0].mobility.x = 10**.node[0].mobility.y = 10**.node[*].mobility.z = 100
**.node[1].mobility.x = 10 + 1*${dist=10,20,30,40,50}**.node[1].mobility.y = 10
**.node[2].mobility.x = 10 + 2*${dist}**.node[2].mobility.y = 10
**.node[3].mobility.x = 10 + 3*${dist}**.node[3].mobility.y = 10
**.node[4].mobility.x = 10 + 4*${dist}**.node[4].mobility.y = 10
**.node[5].mobility.x = 10**.node[5].mobility.y = 10 + ${dist}
**.node[6].mobility.x = 10 + 1*${dist}**.node[6].mobility.y = 10 + ${dist}
**.node[7].mobility.x = 10 + 2*${dist}**.node[7].mobility.y = 10 + ${dist}
**.node[8].mobility.x = 10 + 3*${dist}**.node[8].mobility.y = 10 + ${dist}
CHAPTER 6
RESULTS
DEPT. OF CSE 35 COLLEGE OF ENGINEERING MUNNAR
MAJOR PROJECT 2012 HOTSPOT PREVENTING ROUTING ALGORITHM
Fig 6.1: Initial Network Setup
Fig 6.2: Packet Transmission
CHAPTER 6
CONCLUSION & FUTURE ENHANCEMENTS
DEPT. OF CSE 36 COLLEGE OF ENGINEERING MUNNAR
MAJOR PROJECT 2012 HOTSPOT PREVENTING ROUTING ALGORITHM
HPR used for sensor network helps prevent the formation of hotspots and hence will reduce
the possibility of damage due to overheating of embedded sensor nodes. Since the HPR
algorithm also reduces average packet delivery delay, it is also suitable for being used in
delay sensitive and real-time biomedical applications. Thus HPR routing algorithm paves
the way towards development of new upcoming applications of wireless sensor network in
the field of medical science.
In our future work, we plan to run the proposed algorithm in other sensor network
topologies which includes biomedical sensor networks. We would also like to look at cross-
layer optimization to reduce the formation of hotspots, packet delivery delay and energy
consumption of the network and also increase the fault tolerance of the system.
Early detection using biosensors, enabling the patient to read and monitor the health status,
will shorten hospital stays and contribute to a better life quality. Today many decisions in a
hospital are taken on the basis of samples that have been analyzed in the laboratory on a
manual basis. The introduction of biosensors to automate the whole or part of these manual
processes will reduce the hospital costs considerably. The pressure on faster and more
efficient developments of drugs as well as the need for improving health care without
increasing costs makes it extremely important to provide likely scenarios for technology and
application. Biomedical sensors will be one of the main driving forces for a high quality
cost effective health care system. Biomedical sensor can provide significant improvements.
CHAPTER 7REFERENCES
DEPT. OF CSE 37 COLLEGE OF ENGINEERING MUNNAR
MAJOR PROJECT 2012 HOTSPOT PREVENTING ROUTING ALGORITHM
[1].Anirban Bag and Mostafa A. Bassiouni, “Hotspot Preventing Routing Algorithm for
Delay-sensitive Biomedical Sensor Networks,” in IEEE International Conference on
Communications. Alaska, 2003.
[2].http://omnetpp.org/doc/omnetpp/manual/usman.html
[3].Bag and M. A. Bassiouni, "Energy Efficient Thermal Aware Routing Algorithms for
Embedded Biomedical Sensor Networks," in IEEE IST-WSN'06. Vancouver,
Canada, 2006.
[4].L. Schwiebert, S. K. S. Gupta, and J. Weinmann, "Research challenges in wireless
networks of biomedical sensors," in Proceedings of the 7th annual international
conference on Mobile computing and networking. Rome, Italy: ACM Press,
2001.
[5].Q. Tang, N. Tummala, S. K. S. Gupta, and L. Schwiebert, "TARA: Thermal-Aware
Routing Algorithm for Implanted Sensor Networks," in Proceedings of Intl.
Conference on Distributed Computing in Sensor Systems (DCOSS). CA, USA:
Springer, 2005.
[6].Y. Prakash, S. Lalwani, S. K. S. Gupta, E. Elsharawy, and L. Schwiebert, "Towards
a Propagation Model for Wireless Biomedical Applications," in IEEE International
Conference on Communications. Alaska, 2003.
[7].V. Shankar, A. Natarajan, S. Gupta, and L. Schwiebert, "Energy-efficient Protocols
for Wireless Communication in Biosensor Networks," in 12th IEEE International
Symposium on Personal, Indoor and Mobile Radio Communications. San Diego,
USA, 2001.
[8].Furse, H. K. Lai, C. Estes, A. Mahadik, and A. Duncan, "An Implantable Antenna
for Communication with Implantable Medical Devices," in IEEE Antennas and
Propagation/ URSI International Symposium. Orlando, FL, USA, 1999.
DEPT. OF CSE 38 COLLEGE OF ENGINEERING MUNNAR