mp3Content

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


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.



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



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



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



_ 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



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



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.



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.



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



(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.



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;



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++;



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



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);


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));


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;



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);



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;



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>



#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;



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



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.



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



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



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.



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



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



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



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



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



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



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.



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



“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.



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")



**.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[5].mobility.x = 10**.node[5].mobility.y = 10 + ${dist}

**.node[6].mobility.x = 10 + 1*${dist}**.node[6].mobility.y = 10 + ${dist}



CHAPTER 6

RESULTS



Fig 6.1: Initial Network Setup

Fig 6.2: Packet Transmission

CHAPTER 6

CONCLUSION & FUTURE ENHANCEMENTS



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



[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.


mp3Content

Documents

bit error

ieee international

unsigned long

transparently

standalone

launch configuration

special navigation

wireless sensor