A FRAMEWORK OF SDN AND NFV FOR

INTEGRATING IOT USING WSN

Abstract

Wireless Sensor Network (WSN) is constitute with large number of sensor nodes in an ad-hoc
manner. The WSN used to monitor the physical or environmental conditions. The WSN is self
configured network with tiny sensor nodes communicating among themselves using Internet of
Things(IoT). The sensor nodes utilize the battery power for network operations. In order to
maximize the lifetime of the nodes of WSN, it is necessary to improve the energy efficiency of
the system. An energy efficient mechanism is essential for improvement of data transmission
performance. To address the limitations of present state of the system, proposed 4G enable
Software Defined Network(SDN) mechanism in sensor nodes. This mechanism control the data
traffic from service provider to edge sensor nodes. The implementation is done using the
Network Simulator version 2. The proposed mechanism achieved better performance and the
evident shown in simulation results. The SDN based WSN network have high performance with
comparison conventional sensor networks in terms of packet delivery ratio, delay, throughput
and energy consumption.

Table of Contents
A FRAMEWORK OF SDN AND NFV FOR INTEGRATING IOT USING WSN .................................. 1
Abstract .................................................................................................................................................. 1
1.Introduction ......................................................................................................................................... 3
1.1 Wireless Sensor Networks.............................................................................................................. 3
1.2 Software Defined Network(SDN)s .................................................................................................. 5
1.3 Internet of Things .......................................................................................................................... 6
2. Literature Review .............................................................................................................................. 10
2.1 Introduction ................................................................................................................................. 10
2.2 Overview .......................................................................................... Error! Bookmark not defined.
2.3 SDN for Wireless Sensor Network ..................................................... Error! Bookmark not defined.
2.4 Software Defined Wireless Sensor Networks Architecture ................ Error! Bookmark not defined.
2.5 Implementation of SDN paradigm in WSN .................................................................................... 10
2.6 Software Defined Network for Energy Efficient Wireless Sensor Networks ...... Error! Bookmark not
defined.
2.7 Software Defined Sensor Networks Challenges ................................. Error! Bookmark not defined.
2.8 Topology Management ................................................................................................................ 17
2.8.1 Centralized TD............................................................................ Error! Bookmark not defined.
2.8.2 Decentralized and Distributed TD ............................................... Error! Bookmark not defined.
2.9 Routing Protocols ............................................................................. Error! Bookmark not defined.
2.9.1 Ad-hoc On Demand Routing Protocol ........................................ Error! Bookmark not defined.
2.9.2 Dynamic Source Routing protocol .............................................. Error! Bookmark not defined.
3. System Analysis ................................................................................................................................. 19
3.1 Existing System ............................................................................................................................ 21
3.1.1 Disadvantages ........................................................................................................................... 22
3.2 Proposed System ......................................................................................................................... 22
3.2.1 Advantages ........................................................................................................................... 22
3.3 UML Diagrams ............................................................................................................................. 22
3.3.1 Usecase Diagram................................................................................................................... 23
3.3.2 Sequence Diagrams ............................................................................................................... 24
3.3.3 Collaboration Diagram .......................................................................................................... 25
3.3.4 Activity Diagram .................................................................................................................... 25
3.3.5 Deployment Diagram ............................................................................................................ 26
3.4 System Requirements .................................................................................................................. 27
3.4.1 Hardware Requirements ........................................................................................................... 27
 3.4.2 Software Requirements ............................................................................................................ 27
3.5 Network Simulator ....................................................................................................................... 28
4. Proposed Methodology ..................................................................................................................... 33
4.1 Design Network ........................................................................................................................... 33
4.2 Configure SDN ............................................................................................................................. 33
4.3 Start data Transmission................................................................................................................ 33
4.4 Analyze QoS ................................................................................................................................. 33
5. Results............................................................................................................................................... 35
6. Conclusion ......................................................................................................................................... 50
References ............................................................................................................................................ 51

1.Introduction

1.1 Wireless Sensor Networks

Wireless sensor networks (WSNs) are interconnected sensor nodes that communicate wirelessly
to collect data about the surrounding environment. Nodes are generally low power and
distributed in an ad hoc, decentralized fashion. Although WSNs have gained a lot of popularity,
there are some serious limitations when implementing security imposed by resource limitations
in memory, computing, battery life, and bandwidth. A range of attacks can target privacy,
control, or availability. This chapter presents an overview of requirements for encryption,
authentication, lightweight public key infrastructure proposals, and key management in WSNs.
The problem of new WSN routing protocols taking into account energy use is reviewed. Next,
the chapter describes WSN as a major technology enabling the Internet of Things (IoT). Security
is expected to be a major challenge for IoT owing to the number of “things” and openness of the
system. In addition to the usual security goals (privacy, authentication, and access control), the
IoT should be intrusion tolerant and self-healing.

A wireless sensor network contains a large number of tiny sensor nodes that are densely
deployed either inside the phenomenon to be sensed or very close to it. Sensor nodes consist of
sensing, data processing, and communicating components. The position of sensor nodes need not
be engineered or predetermined. This allows random deployment in inaccessible terrain or
disaster relief operations. This also means that sensor network protocols and algorithms must
possess self-organizing capabilities. Another unique feature of sensor networks is the cooperative
effort of sensor nodes. Sensor nodes are fitted with an inboard processor. Instead of sending the
raw data to the nodes responsible for the fusion, they use their processing abilities to locally
carry out simple computations and transmit only required and partially processed data. In the
following sections we introduce wireless sensor networks briefly. Interested readers should refer
to references for more details.
Wireless sensor network applications require wireless ad hoc networking techniques. Although
many protocols and algorithms have been proposed for traditional wireless ad hoc networks, they
are not well suited for the unique features and application requirements of wireless sensor
networks. The differences between wireless sensor networks and traditional wireless ad hoc
networks are listed here :
 The number of sensor nodes in a wireless sensor network can be several orders of
magnitude higher than the nodes in a wireless ad hoc network.
 In a wireless sensor network, sensor nodes are densely deployed. Sensor nodes are prone
to failure.
 The topology of a wireless sensor network changes very frequently. Sensor nodes mainly
use broadcast communication paradigms whereas most traditional ad hoc networks are
based on point-to-point communications.
 Sensor nodes are limited in power, computational capabilities, and memory.
 Sensor nodes may not have global identification because of the large amount of overhead
and large number of sensors.

Another factor that distinguishes wireless sensor networks from traditional mobile ad hoc
networks (MANETs) is that the end goal is the detection/estimation of some event(s) of interest,
and not just communication. To improve detection performance, it is often quite useful to fuse
data from multiple sensors . Data fusion requires the transmission of data and control messages.
This need may impose constraints on network architecture.
The large number of sensing nodes may congest the network with information. To solve this
problem, some sensors, such as cluster heads, can aggregate the data, perform some computation,
and then broadcast the summarized new information.

Since large numbers of sensor nodes are densely deployed, neighbor nodes may be very close to
each other. Hence, multihop communication in wireless sensor networks is expected to consume
less power than traditional single hop communication. Furthermore, the transmission power level
can be kept low, which is highly desirable in covert operations. Multihop communication can
effectively overcome some of the signal propagation effects experienced in long-distance
wireless communication.

One of the most important constraints on sensor nodes is the low power consumption
requirement. Sensor nodes carry limited, generally irreplaceable power sources. Therefore, while
traditional networks aim to achieve high quality of service (QoS) provisions, wireless sensor
network protocols must focus primarily on power conservation. They must have built-in trade-
off mechanisms that give the end-user the option of prolonging network lifetime at the cost of
lower throughput or higher transmission delay. [https://www.sciencedirect.com/topics/computer-
science/wireless-sensor-networks]

1.2 Software Defined Network(SDN)s

SDN architecture presents a new solution that consists of separating the control plane from the
data plane which is typically coupled together. Network functions traditionally realized in
specific hardware can now be abstracted and virtualized on any equipment. A split between
control and data path nodes is performed, so a centralized controller has a global view of the
network while the data plane includes devices which simply forward packets following rules
expressed by the controller. In order to communicate between these two layers, an open standard
protocol is employed. This separation between the two layers simplifies the network
management and help to simply program network control.
The main concept of SDN architecture consists on the separation between control and
forwarding functions. The multiple components of an SDN architecture which is based on three
layers separated by open interfaces. The SDN application plane is a layer composed of a variety
of applications that communicate via Northbound APIs. It's responsible for management,
reporting functionalities such as monitoring or security. The SDN controller plane represents the
main entity in the network that facilitates the creation/destruction of network paths. Typical SDN
Controllers are OpenDaylight and Floodlight. The SDN data plane includes different devices
deprived from any intelligence. They simply execute the controller's rules. The SDN architecture
defines also the key interfaces between the different layers, which are East/West bound API that
are implemented by the different controllers of the SDN and used to facilitate communications
between them. Hyperflow is one representative example of such APIs. Southbound API is
implemented by the different forwarding devices in the SDN and enabling the communication
between these devices and the controllers. For such APIs, we can enumerate OpenFlow or
NetConf. The Northbound API is Implemented by the controllers of the SDN and used to
facilitate the communication between controllers and the network management applications. In
such SDN architecture, enhancing the QoE became easier by implementing specific algorithms
within the controller entity. The SDN manages in such case to enable new functionalities such as
QoE monitoring and enforcement functions.

1.3 Internet of Things

Nowadays Internet of Things (IoT) is widely adopted in many applications that its importance is
extending in our daily life. The IoT technology is also developing in the healthcare monitoring
system for providing effective emergency services to patients. It is also being used as an E-health
application on different aspects such as early detection of medical issues, emergency notification,
and computer-assisted rehabilitation. The IoT devices have become an indispensable part of
people’s daily life and these are connected with the sensor to monitor the health of the subject.
This sensing-based surveillance system acquires various data from the wards and diagnostic
equipment, and mines these data for efficient and automatic control of healthcare. The IoT
healthcare system provides efficient monitoring and tracking that helps to improve the resource
management of people. The distributed computing is used to handle healthcare data and provides
resource-sharing facilities like flexibility, data service integration with scalable data storage,
parallel processing, and security problems early.

The IoT is a computing concept that describes a future where every day physical objects will be
connected to the Internet and be able to identify themselves and interact locally or remotely
with other devices, IoT is expanding rapidly and it is transforming every application domain,
including healthcare by enabling the introduction of smart services that help improving health and
well-being, increase public safety, and enable a better service experience. Such smart services lead
to a better quality of living, and they are currently and extensively fueling the development of
healthcare domain under the cover, these smart services manage also a lot of data coming both
from conventional computing systems and novel IoT devices, such as wearable, sensor
networks, etc. To properly manage them, and contemporarily tackle the enormous data
availability registered over the last two decades.

IoT is the growing technology in the internet environment in conjunction with real-time
connected objects. It is popular in many different industries because of convergence from the
simple object into a smart object. This has a long-term impact on the health monitoring,
administration, and clinical service to patient’s physiological information. Patients are connected
with sensors and the data has been associated with control devices, then it forwards to the health-
monitoring unit. Sometimes data are stored in the cloud, which helps to manage the number of
data with security. An important area in the IoT is security because when dealing with data
transmission from the sensor to cloud center it is a possible loss of integrity and confidentiality
and also it is complex to encrypt the data received from low resource devices. Cloud is a
distributed environment so that it is the best option to store the medical data which more flexible
for remotely caring patients accessed by doctors and Vice Versa. The IoT and cloud start
handshake for real-time processing which turns to give complexity in architecture to sending and
receiving data.

The main role of the operators is the configuration of the low-level network to implement the
high-level network strategies in order to maintain and secure the communication and the
management of the network. In order to remedy these problems many solutions have been
proposed but which remain temporary solutions given the difficulty related to the change of the
network infrastructure. The network equipment is exclusive closed and vertically integrated
which makes the improvement and innovation very rare. SDN introduces new, more flexible
methods for configuring and managing networks. SDN (Software Defined Networking) allows to
decouple the control plane from the data plan present on the network equipment the SDN
controller, which is the heart of the SDN, receives application requests through the Northbound
APIs and translates them into rules that inject them in real time via Southbound APIs on network
devices, while taking advantage of the global view of the network to ensure reliable end-to end
data routing. SDN allows a centralized and programmable management of the network without
changing the general architecture of the latter. Internet of Things is an extension of the Internet
to things and places in the physical world, it provides intelligent services by facilitating the
activation of a billion devices worldwide with network connectivity, in order to collect
information from the physical world, exchange them and process them in real time. Today more
than 15 billion devices (sensor, smart car, smart phones, RFID, Apple Watch, Google glass,
smart home, smart citys and others) are connected to the Internet, and this number will have 50
billion by 2020. All of the objects connected to the Internet generate a huge amount of
information creating flow management, resource allocation, and security that is difficult to
maintain in the IOT network.Centralized control for real-time flow management, and the overall
network view for greater reliability offered by SDN are needed to address the issues related to
IOT. In this article we address in the second section : Constraints of the current networks and
how to overcome them with the application of SDN, in the third section : Architecture of the
SDN model, in the fourth section : Definition of the Internet of things, its architecture and these
requirements for the application of SDN, and in the section number five: The notion of
”Software Defines Internet of Things”, SDN techniques used on IOT, the architecture, as well as
some the different existing solutions.

IOT Network Requirements for SDN This part explores some constraints in the implementation
of IOT networks in an urban environment for the improvement of the different domains of
activities, these constraints can be overcome by the application of the SDN for the realization of
the notion ” Software Defines Internet of Things ”. We distinguish: 1) Effective network
management: The power of IOT technologies will allow billions of things to be connected to the
Internet within a few years, which will generate large amounts of data that must be processed in
an optimal and efficient manner, managing all these devices and the large amount of data that
they generate is a task that needs to be taken seriously. SDN technology enables the control and
distribution of traffic flows in an optimal way with minimizing delay and load balancing in the
network, exploiting the global network view and centralized control of data. The application of
SDN on IOT networks will allow efficient use of bandwidth by load balancing on the network
and the transfer of messages in a finer way. 2) Mobility: As it has been already mentioned at the
top billions of devices will be connected in the Internet of Things in the next few years, and users
must be able to use the different functions of their devices and access the IOT network to any
time and from any area without any problem. SDN technology allows these devices to be
controlled to allow users’mobility to be handled seamlessly. 3) Remedy the heavy use of
network resource: The overuse of the network by the users increases the load on the network
equipment which reduces the performances of the latter, to increase the efficiency of the network
it is necessary to draw up the plan of the quality of service asked by the users in advance, and
configure the network infrastructure for optimized traffic engineering. With the use of the SDN,
the SDN controller takes advantage of the global view of the network to define the optimal path
and the rules that must be applied to the data flow entering the network equipment, which makes
it possible to consume fewer network resources and to increase its efficiency. 4) Optimization of
energy management: A huge mass of data will be generated by the billion devices that will
connect to the IOT network, which involves a large number of data centers to process all this
information, a large amount of electrical energy will be consumed to power all These
datacenters, this require the establishment of energy-efficient data centers with an intelligent
energy management system to minimize their consumption. SDN technology will dynamically
enable or disable data-centers equipment based on usage by mapping network traffic efficiently,
via the SDN controller, to the correct server, creating SDN-based, energy-efficient IOT data
centers
2. Literature Review

2.1 Introduction

Conventional wireless sensor networks (WSNs) work as disseminated networks. Due to their
adaptable organization, advantageous access, and minimal expense, WSNs are generally utilized
in many fields, and numerous sensor hubs are furnished with different kinds of sensors to offer
types of assistance, including temperature observing, dampness checking, and even sound and
video observing, among others. Nonetheless, in many WSNs, sensors are ordinarily fueled by
batteries, and supplanting the exhausted batteries is cost restrictive or even unimaginable. The
energy limitations have caused imposing difficulties for the organization lifetime of the whole
WSN framework, which significantly restricts the utilization of WSNs. Subsequently, planning
an energy-effective calculation to control the transmission energy equilibrium of the multitude of
hubs is of specific significance.

Wireless sensor networks (WSNs) comprise individual hubs that speak with one another and
associate with the climate by detecting and controlling actual boundaries like temperature,
mugginess, and pressing factor level [1, 2]. These hubs incorporate calculation, detecting,
invitation, and wireless correspondence. Additionally, wireless sensor hubs are normally not
furnished with a force source while they just require a negligible measure of energy which is for
the most part

provided by incorporated batteries. WSN is utilized in a few applications, for example, wellbeing
checking, climate observing, fire identification, and accuracy agribusiness. WSN are truly
adaptable in their applications, anyway, they represent a basic test in view of their asset
requirements. The
a significant shortcoming of the wireless sensors comes from the asset limits of the sensor
equipment like preparing, memory, energy, and correspondence abilities. Furthermore, these
hubs won't just have to handle information however they would likewise be adaptable on
varieties in their

errands, they ought to be programmable during activities when different undertakings need. The
above issues are included to WSNs just in light of the fact that every hub is intended to have
every one of the functionalities from the actual layer to the application layer behaving like an
independent framework that performs the two information sending and organization control.
That may functions admirably particularly in limited scope WSN however it turns out to be
difficult to oversee when attempting to execute huge scope for low-power WSN. For this reason,
a few strategies have been proposed to beat these issues and SDN is one among them. SDN vows
to empower a sensible and practical organization that fits the requirements of high-data
transmission applications. The SDN model locations the vast majority of the difficulties assailing
WSNs, particularly the energy limitation, which is determinant for expanding the organization's
life expectancy. In SDN, a large portion of the energy concentrated capacities is taken out from
the actual hub to a consistently incorporated regulator. The hubs become gadgets with no
knowledge while capacities, for example, steering, significant preparing, and the executives are
taken care of at the regulator or application level.

2.2 Overview
In conventional networks, gadgets become hard to design and oversee as the organization
increase. Programming Defined Networking (SDN) [3] is an arising worldview that isolates the
control plane from the information plane. This partition of the control and the information plane
diminishes the intricacy of the organization set up and the executives. The information plane
comprises organization gadgets that have some essential exchanging and sending capacities and
the control plane contains the regulators. The organization hubs report nearby data to the
regulator which utilizes this data for directing and other systems administration assignments.
These steering choices are introduced in the type of stream rules in the stream tables of the
organization gadgets. The forward traffic is indicated by the stream rules in their stream table.
Subsequently, the organization gadgets won't do any intricate choices and the equipment could
be advanced for quick sending. Fig. 1 shows the SDN layer structure. The OpenFlow convention
is stream-based, each switch keeps a stream table, which comprises stream decisions that decide
the treatment of bundles. Stream passages for the most part comprise match fields, counters, and
directions/activities. The match field passage is utilized to coordinate with the approaching
bundles. At the point when a parcel is gotten, the header is removed whereupon the significant
fields are coordinated against the stream table passages.

2.3 SDN for Wireless Sensor Network

Programming characterized organizing (SDN) is a new systems administration engineering that

expects to work on network setup and geography for the executives. In SDN we decouple the
organization knowledge, the control plane, from the parcel sending framework, the information
plane. While SDN was at first presented for enormous scope endeavor networks it fundamentally
affects wireless sensor organization. Indeed, it guarantees improvement of organization the
board, and energy
effectiveness of WSN. The idea of Software Defined Wireless Sensor Networks (SDWSN) has
arisen because of the need for on-request and applications-explicit networks and furthermore the
decrease in the cost of sensors. SDWSN comprises sensor hubs including highlights that change
progressively as indicated by programming applications.

2.4 Software-Defined Wireless Sensor Networks Architecture

Actually, SDN and SDWSN structures are comparable as far as the executives since the initial
ones are represented by a regulator and the second ones by a sensor control worker. The
methodology of conveying another errand or application is through reinventing sensor hubs with
the code that a client needs to be run inside the organization relying upon application requests.
SDWSN joins an instrument to change the organization's arrangement with jobs. SDWSN
depends on three programming perceptible layers to satisfy their usefulness as displayed in Fig.
2. The actual layer called the information plane is made out of sensor hubs and it furthermore
contains the Software Defined Radio (SDR) that is utilized to control the media access. The
systems administration layer is called the control plane which is answerable for information
transmission across the organization, in which the SDN regulator is found. At last, the
application layer deals with that controls sensor hubs.

2.5 Implementation of SDN paradigm in WSN

Software-defined systems administration (SDN) is another organization engineering that plans to

improve on network design and geography the executives. In SDN we decouple the organization
knowledge, the control plane, from the bundle sending framework, the information plane.
Despite the fact that SDN was at first presented for huge scope undertaking and wired networks
it massively affects the proficiency and assets of the executives of WSN. Buratti et al. utilized a
WSN application for SDN estimations [5]. In their work, they utilized sensor hubs to quantify
the exhibition of SDWSN. To empower SDN they add a regulator that can be situated anyplace
in the organization to deal with the organization. This investigation of the connected work
showed that numerous applications that execute SDN worldview in remote sensor networks have
been directed, yet just not many of them have tried the effect of SDN on energy effectiveness in
WSN.

2.6 Software Defined Network for Energy Efficient Wireless Sensor Networks

Albeit SDN engineering has many advantages, its unique plan was for IP-based networks and
contrasts from the information-based WSN. Consequently, the SDN design can't be
straightforwardly carried out in WSN on the grounds that some complicated techniques can
cause tremendous load and along these lines decrease the lifetime of the organization. Luo et al.
[6] proposed a Software-Defined WSN (SD-WSN), a design including an unmistakable
detachment among information and control plane, and present

Sensor OpenFlow (SOF) is a standard correspondence convention between these two planes. The
information plane comprises sensors performing stream-based parcel sending, and the control
plane comprises one regulator that concentrates all the organization insight, performing network
control, for example, directing and QoS control. In another examination, Huang et al. [7]
proposed a supported learning-based technique to perform esteem repetition separating and load-
adjusting directing of information streams to further develop the energy productivity and self
versatility to ecological changes for WSN. the stream table of the OpenFlow, which is adjusted
according to the viewpoint of WSN, and the creator thinks about the area data and dumps energy
of the sensor hubs. Luo et al. [8] proposed a viable energy productivity plan of IWSNs
(Industrial Wireless Sensor Networks) utilizing SDN and NFV(Network work virtualization) for
modern applications. They utilize another design wherein they present a regulator and elaborate
the work process and calculation for various parts. The regulator incorporates a few sections
such as pre-processing, dozing hubs determination, group heads choice, and transfer hubs choice
and bunches development and appropriating VNF (Virtual Network work) cases and stream
tables to sensor hubs. They approve their methodology box reproductions by correlation with
two notable customary conventions. Liao et a. proposed [9] an energy-proficient SDN-based
information assortment procedure. In their technique, the sensor creates the information then it
gives the information quality like temperature, the sensor thinks about whether the handling
strategy for the temperature information is recorded in its stream table. In the event that it is
recorded, the information is handled by the standard. In the event that it isn't, the sensor asks the
regulator and updates the stream table. They utilize a powerful difference in stream table by
region to abstain from much communicating and clog in SDN workers. They assess their
methodology by figuring measurements, for example, The energy utilization for information
stockpiling a d recovering information with changing a number of detecting occasions. They
planned the stream table as per the constraints of WSN applications to guarantee that all
detecting information can meet the prerequisites of every application. Liao et

al.[10] propose clever engineering of software-defined remote sensor networks. we present the
idea of multi-energy-space dependent on the remaining energy. The primary thought is to make
the organization programmable and make the intricacy of sensor hubs as basic as could really be
expected. The sink hub in the control plane goes about as a regulator and has the entire control of
the whole organization by applying the SDN worldview. The sensor hubs in the information
plane go about as switches. Remote multi-jump secure channels are utilized to communicate
control messages from the regulator to sensor hubs. In the control plane, the regulator has a
stream table that is utilized to handle the information from the sensor hubs. The sending rules of
the stream table are adjusted by the actual regulator as per the predefined approaches. In the
information plane, the sensor hubs are outfitted with sensors to gather sensor information and
make streams themselves. The sensor hubs don't run the disseminated directing calculations.
They simply get the sending rules and fill the stream table which lessens significantly their
computation pressing factor and energy utilization. The regulator makes sending rules as per the
geography data and conveys them to the sensor hubs.

2.7 Software-Defined Sensor Networks Challenges

SDWSN gets the best provisions of the association of WSNs and SDNs because of the plan of
Sensor OpenFlow. One of the accomplished benefits is adaptability since they can uphold
different applications without putting in new software. Another advantage is the versatility for
speedy change in the organization's conduct because of the unified control. Furthermore, the
simplicity of the executives to control the organization through an open Application
Programming Interface (API) is a vital factor in these kinds of networks. SDWSNs have
motivated a few applications. Zeng et al. [11] propose the DASN a design that contained WSN
and SDN permitting performing various tasks having similar organization assets. This venture
expects to assemble a sensor network that can perform detecting undertakings dependent on
client prerequisites. These requests are looked at inside sensor hubs and, if the solicitations are
fulfilled, such demands are blended in with more information in the organization and are at long
last shown to the client's terminal. SDWSN presents some specialized tests in that the
exploration local area proposes a few arrangements. The principal issue has a place with
information streams, which are made out of parcels and there tending to. As opposed to SDWNs,
WSNs don't utilize IP addresses, yet utilize tending to through ascribes. The issue is tackled with
the consideration of IPv6 tending to inside WSNs. Similar to the past issue, the sensor Openflow
direct gives IP network in the sending of information, and WSN doesn't join this kind of tending
to. A way to deal with give an answer for such an issue is utilizing transport conventions over
WSN. Mahmud et al. [12] propose a way to deal with utilize the Openflow innovation in WSN.
It appoints an expense worth to all accessible courses in the organization and saves each figured
course in a tree structure. When the courses tree has been determined, the directing streamlining
agent picks the best course dependent on the number of bounces. All things considered, if an
issue happens in a sensor hub and it becomes latent, the course enhancer will pick the subsequent
best course following a few boundaries. Another test is the asset assignment and its
administration. In such a manner, Costanzo et al. [13] propose a few plans to oversee network
assets productively by utilizing information conglomeration just when it is important and by
offering adaptability in steering ways and energy saving in sensor hubs. To get these provisions
they utilize layered engineering which incorporates a transformation layer, virtualization layer,
and a regulator. Galluccio et al. propose SDN-WISE [14], which is an expansion of Sensor
OpenFlow. It utilizes SDN to improve on approaches arrangement in WSN that is made out of
sensor hubs from the various makers. SDN-WISE depends on various regulators and a
worldwide one that fills in as an intermediary between the information plane and different
regulators. Sensors hubs just take part in neighborhood control undertakings, eliminating from
errands like correspondence with the worldwide regulator.

2.8 Topology Management

The topology management may be a unique characteristic of SDN as compared to traditional

networks. However, TD may be a key component supporting the logically centralized network
management and control paradigm of SDN and may be a service provided by all SDN controller
platforms. The decoupling of the control plane from the info plane enables the SDN to possess a
logically centralized control of the network [12]. to realize the centralized control, a controller
(responsible to regulate the network centrally) should have a worldwide visibility of the
entire network. A controller incorporates various core modules that assist in executing various
SDN applications. Among the core modules, a topology management creates a topology of the
whole SDN infrastructure. The topology not only facilitates the controller but also assists the
appliance plane service to perform its operation using the network programmability.
The topology is critical to both the control plane and therefore the application plane because it
provides an abstract visibility of the whole network devices. Incorporating SDN in WSN leads
to moderate control traffic overhead for the sensor Network won't be overloaded. The control
traffic overhead is that the total number of bits of the packet-out messages sent per second [12].
The reduction within the number of the specified control messages within the TD
process features a direct impact on the control traffic overhead. the amount of Linked Layered
Discovery Protocol (LLDP) Packet-In messages received by the controller during a single
discovery round depends on the topology and is just twice the amount of active inter-switch
links within the network, one packet for every link direction. the entire number of LLDP Packet-
Out messages a controller must send per OFDP discovery round is that the total number of
ports within the network [12]. The reduction of the control traffic is achieved by using the
improved version OFDPv2 algorithm [12]. The OpenFlow protocol may be a guideline approach
used for communication between the controller and therefore the OpenFlow switches on the
southbound interface of the SDWSN [13]. The southbound interface bares requests and replies to
both the controller and therefore the OpenFlow switches [11]. The
updated topology information is critical to the controller in providing efficient control and
management of the network. As a result, the efficient TD is taken into account to be a
crucial characteristic for the controller. Developing a topology of the network requires switch
discovery, host discovery and interconnected switches’ discovery. Below we discuss different
papers on TD consistent with their approaches used, strengths, weaknesses and objectives.

2.8.1 Centralized TD
A centralized system, all stations depend upon one controller to transmit and receive
information. And it's easy to regulate but has low scalability. Pakzad et al. [12] proposed
“Efficient TD in OpenFlowbased Software Defined Networks” by implementing a
replacement TD approach OFDPv2 (OpenFlow discovery protocol version 2) by using POX
controller platform. OFDPv2 which has the goal of reducing the overhead of the TD mechanism
by reducing the amount of control messages that require to be sent by the controller. However,
Azzouni et al. [14] proposed “sOFTDP: Secure and Efficient TD Protocol for SDN”. they
need implemented sOFTDP as a TD module which is safer than OFDP. Lowekamp et al. [15]
proposed “TD for giant Ethernet Networks” by developing two approaches to enhance the
completeness of their forwarding databases. Their implementation requires access to just
one endpoint to perform the queries needed for TD. Abdolmaleki et al. [16] proposed “Fuzzy TD
protocol for SDN-based wireless sensor networks”. The proposed symbolic logic based solution,
called Fuzzy TD Protocol (FTDP) was implemented to enhance the efficiency of SDWSN. This
work is meant consistent with the SDN solution for WSNs. it's one among the primary works
that uses fuzzy theory in SDWSN. Their proposed solution fuzzy system within the control plan
has the target to extend the delivery rate of packets, reduce the packet loss, and increase the
remaining energy of the network so as to enhance the performance of SDWSN.

2.8.2 Decentralized and Distributed TD

Decentralization is that the process of transferring information, through more elements of a

network in order that nobody node are often control. it's moderate scalability. However, different
methods on TD were decentralized. In decentralized method, Bejerano et al. in [17] proposed
“Physical TD for giant multisubnet networks” where their algorithms believe standard Simple
Network Management Protocol (SNMP) Management Information Base (MIB)
information that's widely supported in modern IP networks with the foremost challenges in
determining the most complete set of path constraints for every skeleton path and another
challenge for heterogeneous Ethernet network is that the Complexity for physical TD. Another
method that relies on SNMP MIB information is proposed by Breitbart et al. in [18] “TD in
Heterogeneous IP Networks” by presenting algorithm for discovering topology in heterogeneous
IP networks within the context of a TD tool with difficulties like Limited local information and
transparency of elements across protocol layers.
A distributed system is extremely stable and one failure doesn’t do much damage and features
a few scalability. it's quite similar with decentralized except that each one the knowledge are
distributed among them. Below we discuss a number of the methods that are distributed TD.
Distributed systems are very stable and one failure doesn’t do much damage.

2.9 Routing Protocols

The information routing is most challenging task within the industrial wireless
environment thanks to the inherent characteristics of the wireless sensor networks as dense
deployment, nodes mobility and energy constraints. the main issues that require to be addressed
are maximizing network lifetime, minimizing latency, resource awareness, topological changes,
location awareness, scalability, reliability and real time data delivery. because the sensor
networks are a kind of Mobile Ad-hoc Networks (MANET), same routing protocols also can be
used for WSNs .

Routing Protocols

Proactive Routing Reactive Routing Hybrid Routing

Protocols Protocols Protocols

AODV DSDV ZRP

DSR OLSR

Fig 2.1 Types of routing protocols

As shown in figure 2.1, the routing protocols could also be classified as proactive reactive and
hybrid. Proactive routing protocol is additionally referred to as table driven routing protocol.
Each node is required to store routing information within the network. The network status is
updated either periodically or when the topology changes, leads to low latency, thereby suitable
for real-time traffic, but the bandwidth gets wasted thanks to periodic updates. Moreover, as
these protocols aren't energy efficient, its reliability is questionable as for as WSN cares .
Example protocols are Ballman ford Routing Protocol, Destination Sequenced Distance Vector
Routing (DSDV), Optimized Link State Routing Protocol (OLSR) and Source Tree Adaptive
Routing (STAR).

Reactive routing protocol discovers the route, when needed, hence called “On Demand routing
protocol”. the method of route discovery is completed by flooding the Route REQuest (RREQ)
packets throughout the network. Reactive routing protocol always uses the present status of
network hence the traffic is generated in bursty manner, which can create congestion during high
activities. the many delay may occur as a results of route discovery. But it saves energy and
bandwidth during inactivity period. It’s good for low traffic. Examples Protocols are Ad-Hoc
Ondemand Distance Vector (AODV), Dynamic Source Routing (DSR), Dynamic MANET On-
demand (DYMO) and site Aided Routing (LAR). The Hybrid routing protocol is that the mixed
structure of proactive and reactive routing protocol. the simplest features of proactive routing
protocol and reactive routing protocols as low latency and fewer bandwidth requirement
respectively are being incorporated in hybrid routing as attempts to strike balance between the
2 . the instance protocols are, Zone Routing Protocol (ZRP), Core-Extraction Distributed Ad-
hoc Routing (CEDAR). As for as real time reliable delivery is concern the reactive routing
protocols could also be used because it saves bandwidth and requires fewer resources which
can lead it, to be used for industries. The energy saving in inactive period improves reliability
and low traffic requirement makes reactive routing protocol suitable for WSNs.

2.9.1 Ad-hoc On Demand Routing Protocol

The unplanned On-Demand Distance Vector (AODV) may be a reactive routing protocol. On demand
basis it establishes a route to the destination hence it's called as AODV. It enables dynamic, self-starting,
multihop routing between participating nodes wishing to determine and maintain a billboard hoc
network. AODV allows obtaining routes quickly for brand spanking new destinations,
and doesn't require nodes to take care of routes to destinations that aren't in active communication.
AODV allows mobile nodes to reply to link breakages and changes in topology during a timely
manner. The operation of AODV is loop-free, and by avoiding the Bellman-Ford "counting to infinity"
problem offers quick convergence when the unplanned topology changes. When a node must know a
route to a selected destination it creates a Route Request, forward to sink node through intermediate
nodes. Intermediate node stores a reverse route. When the request reaches a sink node, creates a reply
which contains the amount of hops that are requiring reaching the destination. All intermediate node,
stores the forward route in their routing table. This route created from each node from source to
destination may be a hop-by-hop state and not the whole route as in source routing.

2.9.2 Dynamic Source Routing protocol

The Dynamic Source Routing protocol (DSR) is routing protocol designed for multihop wireless
networks where nodes are mobile. DSR allows the network to be completely self-organizing and
self-configuring. It uses the route discovery cycle for route discovery and uses the route
maintenance cycle to take care of the active routes. These cycles work together, discover and
maintain the route in reactive manner, create the routing packet overhead for searching the routes
dynamically. It prolongs the network life time, load balance, by providing flexibility to sender to
settle on and control route among selected routes to destination. When a node S wants to send a
packet to node D, but doesn't know a route to D, node S initiates a route discovery. Source node
S floods RREQ packet. The RREQ contains sender address, destination address and unique
request id determined by the sender. Each node appends its own identifier when it forwards the
RREQ packet. The Route REPly (RREP) are often send by reversing the RREQ as long as links
are bound to be bidirectional. If unidirectional links are allowed, then RREP may have a route
discovery for S from node D. Route discovery isn't needed if D already knows a route to node S.
If a route discovery is initiated by D for a route to S then the RREP is piggybacked on the RREQ
from D. DSR protocol provides loop- free routing, rapid recovery when routes within
the network change. The DSR protocol is meant mainly for mobile unplanned small networks
(Approx. 2 hundred nodes) with high mobility.

DSDV (Destination Sequenced Distance-Vector) it's a unicast proactive protocol adapted from
the RIP traditional, its main aim is to avoid the loops problems within the update of the routing
tables. For that reason, it adds a replacement field within the tables, the sequence number that
permits distinguish between an old table and a replacement one. DSDV applies an algorithm
based within the distance vector, this suggests that keep the tables with all its accessible
destinations along side the subsequent leap, the metric and variety of sequence of the
input within the generated table by the destination node. The tables are sent with diffusion
messages on a daily basis or when there's a big difference of the topology . A route is taken
into account better than other if it's a sequence number major or just in case of a tie, if the
space at the destination is minor. When a B node detects that the route to certain destination D is
lost, overflow the networks with an updated of that input during which is incremented the
sequence number in one and therefore the distance is marked as infinite. When an A node
receive this message, it incorporates to its table the updated of the input into D through B always
that there wasn't an input better to succeed in D. to realize certain consistency within
the routing table of every node by changing the topology , the updates must be frequents and
quick enough and thus each node can have a sensible vision of the network at a selected time.

3. System Analysis

3.1 Existing System

The traditional wireless sensor networks collect the information from sensor nodes and give the
instructions to sensor nodes to performs the functions. The wireless networks performs the
operations based on the battery power. The present system does not have any control
mechanisms. Its leads to high energy consumption in the network. The WSN have resource
constrained sensor nodes, due to low battery power the node will shutdown. So the network life
time also reduced.

3.1.1 Disadvantages

1. The sensor nodes consume high energy

2. The QoS of network will reduce.

3.2 Proposed System

The WSN have high energy consumption for network operations. To address the limitation of the
present system, proposed 4G enable SDN mechanism in WSN. This mechanism controls the data
flow between the services providers and sensor nodes in the network. Its also schedule the data
traffic in dynamic manner from one node to another node.

3.2.1 Advantages

1. Increase the network life time

2. Improve the QoS of the network.
3. Reduce the energy consumption

3.3 UML Diagrams

UML (Unified Modeling Language) is a standard language for specifying, visualizing, constructing, and
documenting the artifacts of software systems. There are a number of goals for developing UML but the
most important is to define some general purpose modeling language, which all modelers can use and it
also needs to be made simple to understand and use.
UML diagrams are not only made for developers but also for business users, common people, and
anybody interested to understand the system. The system can be a software 31 or non-software system.
Thus it must be clear that UML is not a development method rather it accompanies with processes to
make it a successful system. In conclusion, the goal of UML can be defined as a simple modeling
mechanism to model all possible practical systems in today’s complex environment.

A32 use case diagram is a way to summarize details of a system and the users within that system. It is
generally shown as a graphic depiction of interactions among different elements in a system. Use case
diagrams will specify the events in a system and how those events flow, however, use case diagram does
not describe how those events are implemented.

3.3.1 Usecase Diagram

The purpose of use case diagram is to capture the dynamic aspect of a system. However, this
definition is too generic to describe the purpose, as other four diagrams (activity, sequence,
collaboration, and Statechart) also have the same purpose. We will look into some specific
purpose, which will distinguish it from other four diagrams. Usecase diagrams are used 3 to
gather the requirements of a system including internal and external influences. These
requirements are mostly design requirements. Hence, when a system is analyzed to gather its
functionalities, use cases are prepared and actors are identified.
 Design Network

<<include>>
Configure SDN

4G Enable

system
Start Data Traffic

Analyze QoS

3.3.2 Sequence Diagrams

UML Sequence Diagrams are interaction diagrams that detail how operations are carried out.
They capture the interaction between objects in the context of a collaboration. Sequence
Diagrams are time focus and they show the order of the interaction visually by using the vertical
axis of the diagram to represent time what messages are sent and when.

Configure SDN Start Data Traffic Analyze QoS

user Design Network

1 : create network()

2 : Apply SDN Configuration()

3 : Start Data Transmission()

4 : Analysis network perfromance()

3.3.3 Collaboration Diagram
Collaboration diagrams are used to show how objects interact to perform the behavior of a
particular use case, or a part of a use case. Along with sequence diagrams, collaboration are used
by designers to define and clarify the roles of the objects that perform a 36 particular flow of
events of a use case. They are the primary source of information used to determining class
responsibilities and interfaces.

1 : create network()
user Design Network

2 : Apply SDN Configuration()

3 : Start Data Transmission()

4 : Analysis network perfromance()

Analyze QoS Configure SDN Start Data Traffic

3.3.4 Activity Diagram

The basic purposes of activity diagrams is similar to other four diagrams. It captures the dynamic
behavior of the system. Other four diagrams are used to show the message flow from one object
to another but activity diagram is used to show message flow from one activity to a3n7other.
Activity is a particular operation of the system. Activity diagrams are not only used for
visualizing the dynamic nature of a system, but they are also used to construct 38 the executable
system by using forward and reverse engineering techniques. The only missing thing in the
activity diagram is the message part. It does not show any message flow from one activity to
another. Activity diagram is sometimes considered as the flowchart. Although the diagrams look
like a flowchart, they are not. It shows different flows such as parallel, branched, concurrent, and
single.

Design Network

Configure SDN

Start Data Transmission

Analyze Results

3.3.5 Deployment Diagram

The term Deployment itself describes the purpose of the diagram. Deployment diagrams are used
for describing the hardware components, where software components 39 are deployed.
Component diagrams and deployment diagrams are closely related. Component diagrams are
used to describe the components and deployment diagrams shows how they are deployed in
hardware. UML is mainly designed to focus on the software artifacts of 32 a system. However,
these two diagrams are special diagrams used to focus on software and hardware components.
Most of the UML diagrams are used to handle logical components but deployment diagrams are
made to focus on the hardware topology of a system. Deployment diagrams are used by the
system engineers.

Sensor Node1 Sensor Node2 Sensor Node N

3.4 System Requirements

3.4.1 Hardware Requirements

 Processor - Pentium –III

 Speed - 1.1 Ghz

 RAM - 256 MB(min)

 Hard Disk - 20 GB

 Key Board - Standard Windows Keyboard

 Mouse - Two or Three Button Mouse

 Monitor - SVGA

3.4.2 Software Requirements

 Operating System - Windows/Linux

 Tool - Network Simulator (NS2).
 Programming Language - TCL (Tool Command Language).
3.5 Network Simulator

Network Simulator (Version 2), broadly known as NS2, is essentially an occasion driven
recreation apparatus that has demonstrated helpful in considering the unique idea of
correspondence organizations. Reenactment of wired just as remote organization capacities and
conventions (e.g., steering calculations, TCP, UDP) should be possible utilizing NS2. All in all,
NS2 gives clients a method of indicating such organization conventions and reenacting their
comparing practices. Because of its adaptability and measured nature, NS2 has acquired
consistent prevalence in the systems administration research local area since its introduction to
the world in 1989. From that point onward, a few upsets and updates have denoted the
developing development of the apparatus, on account of considerable commitments from the
major parts in the field. Among these are the University of California and Cornell University
who built up the REAL organization test system, the establishment on which NS depends on.
Since 1995 the Defense Advanced Research Projects Agency (DARPA) upheld 40 improvement
of NS through the Virtual InterNetwork Testbed (VINT) project. Right now, the National
Science Foundation (NSF) has joined the ride being developed. Last yet not the least, the
gathering of specialists and engineers locally are continually attempting to keep NS2 solid and
adaptable.

3.5.1 NS2 Architecture

NS2 gives clients an executable order ns which takes on info contention, the name of a Tcl
recreation scripting record. Clients are taking care of the name of a Tcl recreation content (which
sets up a reproduction) as an information contention of a NS2 executable order ns. By and large,
a recreation follow document is made, and is utilized to plot chart or potentially to make
movement. NS2 comprises of two key dialects: C++ and Object-arranged Tool Command
Language (OTcl). While the C++ characterizes the inner system (i.e., a backend) of the
recreation protests, the OTcl sets up reproduction by collecting and designing the items just as
planning discrete occasions (i.e., a frontend). The C++ and the OTcl are connected together
utilizing TclCL. Planned to a C++ object, factors in the OTcl areas are here and there alluded to
as handles. Reasonably, a handle (e.g., n as a Node handle) is only a string (e.g., _o10) in the
OTcl area, and doesn't contain any usefulness. All things considered, the usefulness (e.g.,
accepting a bundle) is characterized in the planned C++ object (e.g., of class Connector). In the
OTcl area, a handle goes about as a frontend which connects with clients and other OTcl objects.
It might characterizes its own methodology and factors to encourage the communication. Note
that the part techniques and factors in the OTcl space are called 41 example methodology
(instprocs) and case factors (instvars), individually. Prior to continuing further, the perusers are
urged to learn C++ and OTcl dialects. We allude the perusers to for the detail of C++, while a
short instructional exercise of Tcl and OTcl instructional exercise are given in Appendices A.1
and A.2, separately. NS2 gives countless inherent C++ objects. It is fitting to utilize these C++
objects to set up a reproduction utilizing a Tcl recreation content. In any case, advance clients
may discover these items inadequate. They need to build up their own C++ articles, and utilize
an OTcl design interface to assemble these items. After reenactment, NS2 yields either text-
based or liveliness based reproduction results.

To decipher these outcomes graphically and intuitively, apparatuses, for example, NAM
(Network AniMator) and XGraph are utilized. To dissect a specific conduct of the organization,
clients can extricate a pertinent subset of text-based information and change it to a more possible
introduction.

3.5.2 NS2 Installation

NS2 is a free recreation apparatus, which can be acquired from. It runs on different stages
including UNIX (or Linux), Windows, and Mac frameworks. Being created in 42 the Unix
climate, with nothing unexpected, NS2 has the smoothest ride there, thus does its establishment.
Except if in any case indicated, the conversation in this book depends on a Cygwin (UNIX
emulator) actuated Windows framework. NS2 source codes are conveyed in two structures: the
across the board suite and the segment astute. With the across the board 4b3undle, clients get all
the necessary parts alongside some discretionary segments. This is fundamentally a suggested
decision for the novices. This bundle gives an "introduce" content which arranges the NS2
climate and makes NS2 executable record utilizing the "make" utility. The current 4a4ll-in-one
suite consists of the following main components: NS release 2.30, Tcl/Tk release 8.4.13,
OTcl release 1.12, and TclCL release 1.18. and the following are the optional 23 components:
NAM release 1.12: NAM is an animation tool for viewing network simulation traces and packet
traces.
Zlib version 1.2.3: This is the required library for NAM.
Xgraph version 12.1: This is a data plotter with interactive buttons for panning, zooming,
printing, and selecting display options. The idea of the component-wise approach is to obtain the
above pieces and install them individually. This option save considerable amount 4of
downloading time and memory space. However, it could be troublesome for the beginners, and is
therefore recommended only for experienced users.

3.5.3 Linux Based Installation

The all-in-one suite can be installed in the Unix-based machines 4b4y simply running the install
script and following the instructions therein. The only requirement is a computer with a C++
compiler installed. The following commands show how the all-in-one NS2 suite can be installed
and validated, respectively:
shell>./install
shell>./validate
Validating NS2 involves simply running a number of working scripts that verify the essential
functionalities of the installed components.

3.5.4 Windows-Based Installation

To run NS2 on Windows-based operating systems, a bit of tweaking is required. Basically, the
idea is to make Windows-based machines emulate 4 2the functionality of the Unix-like
environment. A popular program that performs this job is Cygwin. After getting Cygwin to
work, the same procedure as that of Unix-based installation can be followed. For ease of
installation, it is recommended that the all-in-one package be used. The detailed description of
Windows-based installation can be found online at NS2’s Wiki site, where the information on
post-installation troubles can also be found. Note that by default Cygwin does not install all
packages necessary to run NS2. A user needs to manually install the addition packages.
3.5.5 Language Structure of NS2

NS2 consists mainly of two languages: C++ and OTcl. Each of these two languages has its own
strengths and weaknesses. NS2 beautifully integrates these two languages to draw out their
strengths. For most of the time, you would not need to know the integration mechanism. But you
need to know the strength and weaknesses of these two languages in order to apply them
properly. Perhaps, this is the question you most want to ask. The above provide the motivation of
having two languages. The guideline of selecting the language is provided below: OTcl is a
language for creating a network so that you don’t have to recompile the codes every time you
make changes to your simulation scenarios. It is also used to connect blocks (e.g., classifier,
links, agent) within each NS2 components (e.g., node). C++ defines internal mechanism of each
block. It does things like packet forwarding, scheduling events, collecting statistic, and so on.
According to the OOP concept, every component should be self-contained and should provide
interface to talk to other components. C++ is an OOP. Therefore, it defines these OOP
functionalities. What missing is how the components are linked together as 45 a programmer
should be the one who decide what NS2 components 4a6re needed and how they are linked
together (e.g., Node 1 to Node 3). And, you would tell NS2 to do so (i.e., linking components) by
using OTcl. C++: C++ is a compiled programming language. A C++ program needs to be
compiled (i.e., translated) into the executable machine code. Since the executable is in the form
of machine code, C++ program is very fast to run. However, the compilation process can be
quite annoying. Every tiny little change like adding “int x = 0;” will take few seconds.

OTcl: OTcl is an interpreted programming language. An OTcl program can run on the fly
without the need for compilation. Upon execution, the interpreter translates OTcl instructions to
machine code understandable to the operating system line by line. Therefore, OTcl codes run
more slowly than C++ codes do. The upside of OTcl codes is that every change takes effect
immediately. NS2 documentation suggests that C++ is slow to change but fast to run. OTcl is
slow to run but fast to change. As you might imagine, NS2 uses the last style, where the
configuration file is an OTcl file called “Tcl Simulation Script”. This file contains information
about 47 what you would like to simulate such as “set ns [new Simulator]”, “set n0 [$ns node]”,
and so on. This Tcl simulation script is just the input configuration file to a C++ program, “~ns-
2.35/ns.exe”. If you have a configuration file “simple.tcl”, you can run NS2 by executing

ns simple.tcl

where ns is the executable program obtained from compiling the entire NS2 codes using “make”
utility and simple.tcl is an input configuration file of the executable file ns.

3.5.6 Linkage Between C++ and OTcl

NS2 is an object oriented simulator written in OTcl and C++ languages. While OTcl acts as the
frontend (i.e., user interface), C++ acts as the backend running the actual simulation. As can be
seen from Fig. 3.1, class hierarchies of both languages can be either standalone or linked together
using an OTcl/C++ interface called TclCL. There are two types of classes in each domain. The
first type includes classes which are linked between the C++ and OTcl domains. In the literature,
these OTcl and C++ class hierarchies are referred to as the interpreted hierarchy and the
compiled hierarchy, respectively. The second type includes OTcl and C++ classes which are not
linked together. These classes are neither a part of the interpreted hierarchy nor a part of
compiled hierarchy. This chapter discusses how OTcl and C++ languages constitute NS2.
4. Proposed Methodology

4.1 Design Network

In this model we create the network topology with n number of wireless sensor nodes. For each
node assign a node id. In wireless sensor network every node have mobility. The wireless sensor
network nodes have capability of send, forward and receive data. The sensor recives the
information from SDN node which is enable 4G.

4.2 Configure SDN

In proposed sensor networks have service providers and 4G enable routers. The SDN configure
on this router to control the information from service providers to sensor nodes in the WSN. The
4G features enable by configuration MAC protocol. The SDN router schedule the data
transmission and control packet flow in the network.

4.3 Start Data Transmission

In data transmission the sender and receiver agents attach to nodes. To generate the packets in
the network use traffic generators. The traffic generators attach to sender agents. The data
transmission starting from service providers and send to sensor nodes in the network. The data
passing though SDN router. The data controlled and scheduled in 4G router for better
performance.

4.4 Analyze QoS

The implementation of SDN using 4G network improved the performance of WSN. The QoS of WSN is
improved and measured in various terms. Such as throughput, packet delivery ratio, delay and energy
consumption. The throughput and packet delivery ratio is increased . The delay and energy consumption
is reduced.
5. Results

NS2 version 2.35 is used to implement the proposed MAC layer approach for enhancing
transport of media in wireless networks. With proposed MAC layer optimization, the
performance of the wireless network with multimedia streaming is studied through simulations.
The observations are presented in this section. Table 1 shows the simulation environment used
for the study.

5.1 Simulation Environment

S No Parameter Type Parameter Value

1 Channel Type Wireless Channel
2 Radio-Propagation Propagation/TwoRayGround
3 Network Interface WirelessPhy
4 Interface Queue Type DropTail
5 Antenna Model OmniAntenna
6 Interface Queue Length 50
7 Routing Protocol AODV, DSDV
8 No.of Nodes 20
9 RXThresh_ 3000
10 CTSThreshold_ 2000
11 RTSThreshold_ 5000
12 dataRate_ 2MB
13 basicRate_ 1 MB

Table 1: Simulation Environment

As shown in Table 1, it is evident that different parameters are used as part of the simulation
environment. The radio propagation used for simulation is two ray ground. To evaluate the
proposed work, different performance metrics are used. They are provided in the next sub
section.

5.2 Performance Metrics

Performance metrics are used to evaluate the simulation results. The purpose of each metric is
described here.
 S No Metric Name Description
1 Packet Delivery It is the performance measure used to know the ratio
Ratio (PDR) between number of packets received and the number
of packets sent.
2 Throughput The rate of messages transferred successfully in
network.
3 Delay The time difference between packets received and
packet sent
4 Energy It is the measure used to know how much energy is
Consumption consumed by the network in data transmission,
sensing, data processing and idle sleep state.

Table 2: Performance Metrics

As shown in Table 2, four performance metrics are used to evaluate the proposed work in this
paper. They are PDR, throughput, average delay and energy consumption.

5.3 Simulation Results

Fig 5.1 Represent WSN network with 20 nodes

Fig 5.2 WSN network with three clusters , two 4G enable SDN routers and three service providers
Fig 5.3 Represent 4G enable router with node position
Fig 5.4 Represent link between the service provider and SDN router
Fig 5.5 Represent Link between SDN router and sensor node
Fig 5.6 Represent link between the destination and intermediate sensor node
Fig 5.7 Represent TCP packets transmission from service provider to sensor node through SDN router
Fig 5.8 Represent link between node 14 and node 12.
Fig 5.9 Represent packet transmission between the service provider and SDN router
Fig 5.10 Represent link between the Service Provider 1 and SDN router 2
Fig 5.11 Represent Link between the SDN router and Sensor node
Fig 5.12 Represent energy consumption graph. On X-axis taken simulation time and Y-axis taken
consumed energy in jouls
Fig 5.13 Represent Delay performance graph. On X-axis taken simulation time and Y-axis taken delay in
milli seconds.
Fig 5.14 Represent throughput performance graph. On X-axis taken simulation time and Y-axis
taken no. of bytes received.
 Fig 5.15 Represent PDR performance graph. On X-axis taken simulation time and Y-axis taken packet
delivery ratio.

6. Conclusion

WSNs play a significant role in the development of the Internet of Things. WSN is a bridge
between the real and virtual world. The wireless network consisting of many sensors is used for
monitoring the environmental status (e.g. temperature, voice, vibration, pressure, or movement).
The traditional sensor places the communication protocol on the node. Extension of network
lifetime using conservation of energy in sensor nodes is a major challenge faced by WSN as the
sensor nodes have limited battery power. This can be solved by introducing network
programmability that centralizes network management tasks using software defined network
(SDN). The proposed 4G enable SDN WSNs improves the performance. The proposed
mechanism achieve energy efficient.
7. References

1. A.S. Tanenbaum, and D.J. Wetherall, Computer Networks. 5th Edition, Prentice Hall,
Inc., USA, 2011.
2. D. Hucaby, "CCNP SWITCH 642-813 Official Certification Guide" ,Cisco Press,2010.
3. P. Oppenheimer, "Top Down Network Design", Cisco Press,2011.
4. M. Casado, F. Foster, and A. Guha, " Abstractions for softwaredefined networks.
Commun". ACM, Sep. 2014.
5. N. MCKEOWN, T. ANDERSON, H. BALAKRISHNAN,G. PARULKAR, L
PETERSON, J. REXFORD, SHENKER, S., and J. TURNER, "OpenFlow: Enabling
innovation in campus networks", ACM SIGCOMM Computer Communication Review,
V.38, 2(4) , 2008.
6. D. Kreutz, J. Yu, P. Verissimo, F. Ramos, C. Magalhaes, The KISS principle in
Software-Defined Networking: a framework for secure communications, IEEE Security
& Privacy, Volume: 16 , Issue: 5 , September/October 2018.
7. S. Azodolmolky, Software Defined Networking with OpenFlow, Packt Publishing, 1st
ed., October 2013.
8. F. Ramos, D. Kreutz, P. Verissimo, “Software-Defined Networks: On the Road to the
Softwarization of Networking“, Cutter IT Journal, May 2015.
9. M. Casado, N. Foster, and A. Guha, "Abstractions for softwaredefined networks," CM
Commun., vol. 57, no. 10, pp. 86–95, Sep. 2014.
10. Traffic Engineering in SDN-OpenFlow Networks,” Computer Networks, Vol. 71, pp. 1–
30, 2014.
11. B. N. Astuto, M. Mendonca, X. N. Nguyen, K. Obraczka, and T. Turletti, “A Survey of
Software-Defined Networking: Past, Present, and Future of Programmable Networks,”
IEEE Communications Surveys and Tutorials, Vol. 16, No. 3, pp.1617–1634, 2014.
12. A.-C. G. Anadiotis, G. Morabito, and S. Palazzo, “An SDN-Assisted Framework for
Optimal Deployment of MapReduce Functions in WSNs,” IEEE Transactions on Mobile
Computing, Vol. 15, No. 9, pp.2165–2178, 2016.
13. C. J. Bernardos, A. De La Oliva, P. Serrano, A. Banchs, L. M. Contreras, H. Jin, and J. C.
Zúniga, “An Architecture for Software Defined Wireless Networking,” IEEE Wireless
Communications, Vol. 21, No. 3, pp. 52–61, 2014.
14. T. Chen, M. Matinmikko, X. Chen, X. Zhou, and P. Ahokangas, “Software Defined
Mobile Networks: Concept, Survey, and Research Directions,” IEEE Communications
Magazine, Vol. 53, No. 11, pp. 126–133, 2015.
15. Wenxing, Liao, Wu Muqing, and Wu Yuewei. ”Energy-efficient algorithm based on
multi-dimensional energy space for software-defined wireless sensor networks.” Wireless
Communication Systems (ISWCS), 2016 International Symposium on. IEEE, 2016.
16. de Oliveira, Bruno Trevizan, and Cntia Borges Margi. ”Distributed control plane
architecture for software-defined Wireless Sensor Networks.” Consumer Electronics
(ISCE), 2016 IEEE International Symposium on. IEEE, 2016.
17. Sayyed, Ruby, et al. ”Resource optimization using software defined networking for smart
grid wireless sensor network.” Eco-friendly Computing and Communication Systems
(ICECCS), 2014 3rd International Conference on. IEEE, 2014.
18. Junli, Fang, Wang Yawen, and Shi Haibin. ”An improved energyefficient routing
algorithm in software define wireless sensor network.” Signal Processing,
Communications and Computing (ICSPCC), 2017. IEEE International Conference on.
IEEE, 2017.
19. Ejaz, Waleed, et al. ”Efficient wireless power transfer in software-defined wireless sensor
networks.” IEEE Sensors Journal 16.20 (2016): 7409- 7420.
20. Kahjogh, Behnam Ojaghi, and Greg Bernstein. ”Energy and latency optimization in
software defined wireless networks.” Ubiquitous and Future Networks (ICUFN), 2017
Ninth International Conference on. IEEE, 2017.
21. De Oliveira, Bruno Trevizan, Lucas Batista Gabriel, and Cintia Borges Margi.
”TinySDN: Enabling multiple controllers for software-defined wireless sensor networks.”
IEEE Latin America Transactions 13.11 (2015): 3690-3696.
22. Matlou, Omolemo Godwill, and Adnan M. Abu-Mahfouz. ”Utilising artificial
intelligence in software defined wireless sensor network.” Industrial Electronics Society,
IECON 2017-43rd Annual Conference of the IEEE. IEEE, 2017.
#Define network parameters
set val(chan) Channel/WirelessChannel ;# channel type
set val(prop) Propagation/TwoRayGround ;# radio-propagation model
set val(netif) Phy/WirelessPhy ;# network interface type
set val(mac) Mac/802_11 ;# MAC type
set val(ifq) Queue/DropTail/PriQueue ;# interface queue type
set val(ll) LL ;# link layer type
set val(ant) Antenna/OmniAntenna ;# antenna model
set val(ifqlen) 50 ;# max packet in ifq
set val(nn) 20 ;# number of mobilenodes
set val(rp) AODV ;# routing protocol
set val(x) 2000 ;# X dimension of topography
set val(y) 2000 ;# Y dimension of topography
set val(stop) 50.0 ;# time of simulation end
set val(energymodel) EnergyModel ;# Energy Model
set val(initialenergy) 100 ;# Energy Value

Mac/802_11 set CTSThreshold_ 2000

Mac/802_11 set RTSThreshold_ 5000
Mac/802_11 set basicRate_ 1Mb
Mac/802_11 set dataRate_ 5Mb

set ns [new Simulator]

set topo [new Topography]

$topo load_flatgrid $val(x) $val(y)
create-god $val(nn)

set tracefile [open wsnsdn.tr w]

$ns trace-all $tracefile

$ns use-newtrace

set namfile [open wsnsdn.nam w]

$ns namtrace-all $namfile
$ns namtrace-all-wireless $namfile $val(x) $val(y)

set chan [new $val(chan)];

# *** Throughput *** #

set f0 [open WSN_Throughput.tr w]

# *** Packet Delay Trace ***

set f1 [open WSN_Delay.tr w]

# *** PDR ***

set f2 [open WSN_PDR.tr w]

$ns node-config -adhocRouting $val(rp) \

-llType $val(ll) \
-macType $val(mac) \
-ifqType $val(ifq) \
 -ifqLen $val(ifqlen) \
-antType $val(ant) \
-propType $val(prop) \
-phyType $val(netif) \
-channel $chan \
-topoInstance $topo \
-agentTrace ON \
-routerTrace ON \
-macTrace ON \
-movementTrace ON \
-energyModel $val(energymodel) \
-initialEnergy 100 \
-rxPower 35.28e-3 \
-txPower 31.32e-3

set node_(0) [$ns node]

$node_(0) set X_ 203.321
$node_(0) set Y_ 1009.919
$node_(0) set Z_ 0.0

set node_(1) [$ns node]

$node_(1) set X_ 204.12
$node_(1) set Y_ 789.61
$node_(1) set Z_ 0.0

set node_(2) [$ns node]

$node_(2) set X_ 188.84
$node_(2) set Y_ 533.358
$node_(2) set Z_ 0.0

set node_(3) [$ns node]

$node_(3) set X_ 387.422
$node_(3) set Y_ 939.741
$node_(3) set Z_ 0.0

set node_(4) [$ns node]

$node_(4) set X_ 367.606
$node_(4) set Y_ 654.972
$node_(4) set Z_ 0.0

set node_(5) [$ns node]

$node_(5) set X_ 862.5
$node_(5) set Y_ 1196.75
$node_(5) set Z_ 0.0

set node_(6) [$ns node]

$node_(6) set X_ 1003.1
$node_(6) set Y_ 1091.6
$node_(6) set Z_ 0.0

set node_(7) [$ns node]

$node_(7) set X_ 428.92
$node_(7) set Y_ 390.91
$node_(7) set Z_ 0.0

set node_(8) [$ns node]

$node_(8) set X_ 724.51
$node_(8) set Y_ 1308.18
$node_(8) set Z_ 0.0

set node_(9) [$ns node]

$node_(9) set X_ 731.88
$node_(9) set Y_ 306.287
$node_(9) set Z_ 0.0

set node_(10) [$ns node]

$node_(10) set X_ 932.39
$node_(10) set Y_ 812.8128
$node_(10) set Z_ 0.0

set node_(11) [$ns node]

$node_(11) set X_ 547.8
$node_(11) set Y_ 290.9
$node_(11) set Z_ 0.0

set node_(12) [$ns node]

$node_(12) set X_ 778.2
$node_(12) set Y_ 1016.1
$node_(12) set Z_ 0.0

set node_(13) [$ns node]

$node_(13) set X_ 725.1
$node_(13) set Y_ 755.248
$node_(13) set Z_ 0.0

set node_(14) [$ns node]

$node_(14) set X_ 601.236
$node_(14) set Y_ 874.927
$node_(14) set Z_ 0.0

set node_(15) [$ns node]

$node_(15) set X_ 852.71
$node_(15) set Y_ 627.95
$node_(15) set Z_ 0.0

set node_(16) [$ns node]

$node_(16) set X_ 583.58
$node_(16) set Y_ 1114.47
$node_(16) set Z_ 0.0

set node_(17) [$ns node]

$node_(17) set X_ 572.59
$node_(17) set Y_ 640.981
$node_(17) set Z_ 0.0

set node_(18) [$ns node]

$node_(18) set X_ 565.21
$node_(18) set Y_ 478.134
$node_(18) set Z_ 0.0

set node_(19) [$ns node]

$node_(19) set X_ 787.12
$node_(19) set Y_ 434.323
$node_(19) set Z_ 0.0

for {set i 0} {$i < $val(nn)} {incr i} {

$ns initial_node_pos $node_($i) 60

############## Color Code ############

$ns color 0 blue

$ns color 1 red
$ns color 2 brown
$ns color 3 yellow
$ns color 4 hotpink
$ns color 5 black

$ns at 1.0 "$node_(0) label SP1"

$ns at 1.0 "$node_(1) label SP2"
$ns at 1.0 "$node_(2) label SP3"
$ns at 1.0 "$node_(3) label WR1"
$ns at 1.0 "$node_(4) label WR2"

for {set i 5} {$i < $val(nn)} {incr i} {

$ns at 1.0 "$node_($i) label SN($i)"

$ns at 1.0 "$node_(0) color red"

$node_(0) color "1"

$ns at 1.0 "$node_(1) color red"

$node_(1) color "1"

$ns at 1.0 "$node_(2) color red"

$node_(2) color "1"

$ns at 1.0 "$node_(5) color hotpink"

$node_(5) color "4"

$ns at 1.0 "$node_(6) color hotpink"

$node_(6) color "4"

$ns at 1.0 "$node_(8) color hotpink"

$node_(8) color "4"

$ns at 1.0 "$node_(12) color hotpink"

$node_(12) color "4"

$ns at 1.0 "$node_(16) color hotpink"

$node_(16) color "4"

$ns at 1.0 "$node_(10) color brown"

$node_(10) color "2"

$ns at 1.0 "$node_(13) color brown"

$node_(13) color "2"

$ns at 1.0 "$node_(14) color brown"

$node_(14) color "2"
$ns at 1.0 "$node_(15) color brown"
$node_(15) color "2"

$ns at 1.0 "$node_(17) color brown"

$node_(17) color "2"

$ns at 1.0 "$node_(7) color blue"

$node_(7) color "0"

$ns at 1.0 "$node_(9) color blue"

$node_(9) color "0"

$ns at 1.0 "$node_(11) color blue"

$node_(11) color "0"

$ns at 1.0 "$node_(18) color blue"

$node_(18) color "0"

$ns at 1.0 "$node_(19) color blue"

$node_(19) color "0"

# First Path

set tcp1 [new Agent/TCP/Newreno]

set sink1 [new Agent/TCPSink]
$ns attach-agent $node_(0) $tcp1
$ns attach-agent $node_(6) $sink1
$ns connect $tcp1 $sink1

#Traffic Generation
set ftp1 [new Application/FTP]
$ftp1 attach-agent $tcp1
$ftp1 set packet_size_ 512
$ftp1 set interval_ 0.05

$ns at 5.0 "$ftp1 start"

$ns at 49.0 "$ftp1 stop"

# Second Path

set udp2 [new Agent/UDP]

$ns attach-agent $node_(1) $udp2
set sink2 [new Agent/LossMonitor]
$ns attach-agent $node_(9) $sink2
$ns connect $udp2 $sink2

#Traffic Genertion
set cbr2 [new Application/Traffic/CBR]
$cbr2 attach-agent $udp2
$cbr2 set type_ CBR
$cbr2 set packet_size_ 512
$cbr2 set interval_ 0.01

$ns at 5.0 "$cbr2 start"

$ns at 48.5 "$cbr2 stop"

# Third Path

set tcp2 [new Agent/TCP/Newreno]

set sink3 [new Agent/TCPSink]
$ns attach-agent $node_(2) $tcp2
$ns attach-agent $node_(10) $sink3
$ns connect $tcp2 $sink3

#Traffic Generation
set ftp2 [new Application/FTP]
$ftp2 attach-agent $tcp2
$ftp2 set packet_size_ 512
$ftp2 set interval_ 0.05

$ns at 5.0 "$ftp2 start"

$ns at 49.0 "$ftp2 stop"

$ns at 0.5 "$ns trace-annotate \"WSN Simulation Started \""

set holdtime 0
set holdseq 0
set holdrate 0

# Function To record Statistcis (Throughput, PDR, End-to-End Delay)

proc record {} {

global sink2 f0 f1 f2 holdtime holdseq holdrate

set ns [Simulator instance]

set time 0.5 ;#Set Time Interval 0.5 Sec

set bw0 [$sink2 set bytes_]

set bw1 [$sink2 set lastPktTime_]

set bw2 [$sink2 set npkts_]

set now [$ns now]

set clock 1.7

set type 2.5
set maxdist 10

# Throughput

puts $f0 "$now [expr (($bw0+$holdrate)*8)/(2*$time)]"

# Record Packet Delay

if { $bw2 > $holdseq } {

puts $f1 "$now [expr ($bw1 - $holdtime)/($bw2 - $holdseq)/$type]"

} else {
puts $f1 "$now [expr ($bw2 - $holdseq)]"

#PDR

puts $f2 "$now [expr $bw2/4]"

$sink2 set bytes_ 0

$ns at [expr $now+$time] "record" ;# Schedule Record after $time interval sec
}
#Record Events

$ns at 0.0 "record"

proc finish {} {

global ns tracefile namfile f0 f1 f2

$ns flush-trace

close $tracefile
close $namfile

close $f0
close $f1
close $f2

exec xgraph WSN_Throughput.tr -geometry 800x400 -t "Throughput" -x "TIME" -y "Bytes

(pkts)" -bg white &
exec xgraph WSN_PDR.tr -geometry 800x400 -t "Packet Delivary Ratio" -x "TIME" -y
"PDR(%)" -bg white &
exec xgraph WSN_Delay.tr -geometry 800x400 -t "Delay" -x "TIME" -y "Delay(ms)" -bg white
&
exec xgraph WSN_Energy.tr -geometry 800x400 -t "Energy_Consumption" -x "TIME" -y
"Energy(J)" -bg white &
exec nam wsnsdn.nam &
exit 0

for {set i 0} {$i < $val(nn) } { incr i } {

$ns at $val(stop) "\$node_($i) reset"
}
$ns at $val(stop) "$ns nam-end-wireless $val(stop)"
$ns at $val(stop) "finish"
$ns at $val(stop) "puts \"done\" ; $ns halt"
$ns run