ABSTRACT

A MPTCP connection is under network attacks and becomes a poor-performing path

or a broken path, it can significantly affect other stable paths and in the absence of
related schemes to handle A low rate distributed denial-of-service (LDDoS) attack-
aware energy efficient MPTCP solution aiming Avoiding the services. The simulation
results show that MPTCP-La/E2 output for LDDoS caused performance degradation of
cloud multipath transmission, which has been seldom considered in existing MPTCP
solutions, Optimizing the energy usage while still maintaining user’s perceived quality
of cloud multipathing rms the baseline MPTCP in terms of QoS and energy-savings in a
multi homed MCC network environment
 CHAPTER 1

INTRODUCTION

1.1 OVERVIEW

Mobile Cloud Network:

A Mobile Cloud Network (MCN) consists of spatially distributed

autonomous sensors to monitor physical or environmental conditions, such as
temperature, sound, pressure, etc. 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 Mobile Cloud 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 MCN 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 MCNs can vary from a simple star network to an
advanced multi-hop wireless mesh network.

APPLICATIONS

 Area monitoring

Area monitoring is a common application of MCNs. In area monitoring, the

MCN is deployed over a region where some phenomenon is to be monitored. A
military example is the use of sensors detect enemy intrusion; a civilian example is
the geo-fencing of gas or oil pipelines.

 Environmental/Earth monitoring

The term Environmental Sensor Networks has evolved to cover many

applications of MCNs to earth science research. This includes sensing volcanoes,
oceans, glaciers, forests, etc. Some of the major areas are listed below.

 Air quality monitoring

The degree of pollution in the air has to be measured frequently in order to

people environment from any kind of damages due to air pollution. In dangerous
surroundings, real time monitoring of harmful gases is an important process because
the weather can change rapidly changing key quality parameters.
 Interior monitoring

Observing the gas levels at vulnerable areas needs the usage of high-end,
sophisticated equipment, capable to satisfy industrial regulations. Wireless internal
monitoring solutions facilitate keep tabs on large areas as well as ensure the precise
gas concentration degree.

 Exterior monitoring

External air quality monitoring needs the use of precise wireless sensors, rain
& wind resistant solutions as well as energy reaping methods to assure extensive
liberty to machine that will likely have tough access.

 Air pollution monitoring

Mobile Cloud Networks have been deployed in several cities (Stockholm,

London and Brisbane) to monitor the concentration of dangerous gases for citizens.
These can take advantage of the ad hoc wireless links rather than wired installations,
which also make them more mobile for testing readings in different areas. There are
various architectures that can be used for such applications as well as different kinds
of data analysis and data mining that can be conducted.

 Forest fire detection

A network of Sensor Nodes can be installed in a forest to detect when a fire

has started. The nodes can be equipped with sensors to measure temperature,
humidity and gases which are produced by fire in the trees or vegetation. The early
detection is crucial for a successful action of the firefighters; thanks to Mobile Cloud
Networks, the fire brigade will be able to know when a fire is started and how it is
spreading.
 Landslide detection

A landslide detection system makes use of a Mobile Cloud Network to detect

the slight movements of soil and changes in various parameters that may occur
before or during a landslide. Through the data gathered it may be possible to know
the occurrence of landslides long before it actually happens.

 Water quality monitoring

Water quality monitoring involves analyzing water properties in dams, rivers,

lakes & oceans, as well as underground water reserves. The use of many wireless
distributed sensors enables the creation of a more accurate map of the water status,
and allows the permanent deployment of monitoring stations in locations of difficult
access, without the need of manual data retrieval.

 Natural disaster prevention

Mobile Cloud Networks can effectively act to prevent the consequences of

natural disasters, like floods. Wireless nodes have successfully been deployed in
rivers where changes of the water levels have to be monitored in real time.

INDUSTRIAL MONITORING

 Machine health monitoring

Cloud Networks have been developed for machinery condition-based

maintenance (CBM) as they offer significant cost savings and enable new
functionality. In wired systems, the installation of enough sensors is often limited by
the cost of wiring.
DATA LOGGING

Main article:

Mobile Cloud Networks are also used for the collection of data for
monitoring of environmental information; this can be as simple as the monitoring of
the temperature in a fridge to the level of water in overflow tanks in nuclear power
plants

 Industrial sense and control applications

In recent research a vast number of Mobile Cloud Network communication

protocols have been developed. While previous research was primarily focused on
power awareness, more recent research have begun to consider a wider range of
aspects, such as wireless link reliability, real-time capabilities, or quality-of-service.
These new aspects are considered as an enabler for future applications in industrial
and related wireless sense and control applications, and partially replacing or
enhancing conventional wire-based networks by MCN techniques.

 Water/Waste water monitoring

Monitoring the quality and level of water includes many activities such as
checking the quality of underground or surface water and ensuring a country’s water
infrastructure for the benefit of both human and animal. The area of water quality
monitoring utilizes Mobile Cloud Networks and many manufacturers have launched
fresh and advanced applications for the purpose.

 Observation of water quality

The whole process includes examining water properties in rivers, dams,

oceans, lakes and also in underground water resources. Wireless distributed sensors
 let users to make a precise map of the water condition as well as making permanent
distribution of observing stations in areas of difficult access with no manual data
recovery.

 Water distribution network management

Manufacturers of water distribution network sensors concentrate on

observing the water management structures such as valve and pipes and also making
remote access to water meter readings.

 Preventing natural disaster

The consequences of natural perils like floods can be effectively prevented with
Mobile Cloud Networks. Wireless nodes are distributed in rivers so that changes of the
water level can be effectively monitored.

 Agriculture

Using Mobile Cloud Networks within the agricultural industry is increasingly

common; using a wireless network frees the farmer from the maintenance of wiring in a
difficult environment. Gravity feed water systems can be monitored using pressure
transmitters to monitor water tank levels, pumps can be controlled using wireless I/O
devices and water use can be measured and wirelessly transmitted back to a central
control center for billing. Irrigation automation enables more efficient water use and
reduces waste.

 Accurate agriculture

Mobile Cloud Networks let users to make precise monitoring of the crop at the time
of its growth. Hence, farmers can immediately know the state of the item at all its stages
which will ease the decision process regarding the time of harvest.
 Irrigation management

When real time data is delivered, farmers are able to achieve intelligent irrigation.
Data regarding the fields such as temperature level and soil moisture are delivered to
farmers through Mobile Cloud Networks.

When each plant is joined with a personal irrigation system, farmers can pour
the precise amount of water each plant needs and hence, reduce the cost and improve
the quality of the end product. The networks can be employed to manage various
actuators in the systems using no wired infrastructure.

 Greenhouses

Mobile Cloud Networks are also used to control the temperature and
humidity levels inside commercial greenhouses. When the temperature and humidity
drops below specific levels, the greenhouse manager must be notified via e-mail or
cell phone text message, or host systems can trigger misting systems, open vents,
turn on fans, or control a wide variety of system responses.

Recent research in Mobile Cloud Networks in agriculture industry give

emphasis on its use in greenhouses, particularly for big exploitations with definite
crops. Such microclimatic ambiances need to preserve accurate weather status at all
times. Moreover, using multiple distributed sensors will better control the above
process, in open surface as well as in the soil.

 Passive localization and tracking

The application of MCN to the passive localization and tracking of non-

cooperative targets (i.e., people not wearing any tag) has been proposed by
exploiting the pervasive and low-cost nature of such technology and the properties of
the wireless links which are established in a meshed MCN infrastructure.
  Smart home monitoring

Monitoring the activities performed in a smart home is achieved using

wireless sensors embedded within everyday objects forming a MCN. State changes
to objects based on human manipulation is captured by the wireless sensors network
enabling activity-support services.

CHARACTERISTICS

The main characteristics of a MCN include:

 Power consumption constrains for nodes using batteries or energy harvesting

 Ability to cope with node failures
 Mobility of nodes
 Communication failures
 Heterogeneity of nodes
 Scalability to large scale of deployment
 Ability to withstand harsh environmental conditions
 Ease of use

Sensor nodes can be imagined as small computers, extremely basic in terms

of their interfaces and their components. They usually consist of a processing unit
with limited computational power and limited memory, sensors or MEMS (including
specific conditioning circuitry), a communication device (usually radio transceivers
or alternatively optical), and a power source usually in the form of a battery. Other
possible inclusions are energy harvesting modules, secondary ASICs, and possibly
secondary communication interface (e.g. RS-232 or USB).

The base stations are one or more components of the MCN with much more
computational, energy and communication resources. They act as a gateway between sensor
nodes and the end user as they typically forward data from the MCN on to a server. Other
special components in routing based networks are routers, designed to compute, calculate
and distribute the routing tables.
1.2 PLATFORMS

1.2.1 Standards and specifications

Several standards are currently either ratified or under development by

organizations including WAVE2M for Mobile Cloud Networks. There are a number
of standardization bodies in the field of MCNs. The IEEE focuses on the physical
and MAC layers; the Internet Engineering Task Force works on layers 3 and above.
In addition to these, bodies such as the International Society of Automation provide
vertical solutions, covering all protocol layers. Finally, there are also several non-
standard, proprietary mechanisms and specifications.

Standards are used far less in MCNs than in other computing systems which
makes most systems incapable of direct communication between different systems.
However predominant standards commonly used in MCN communications include:

 ISA100.11a
 WirelessHART
 IEEE 1451
 ZigBee / 802.15.4
 ZigBee IP
 6LoWPAN

Hardware

Main article: sensor node

One major challenge in a MCN is to produce low cost and tiny sensor nodes.
There are an increasing number of small companies producing MCN hardware and
the commercial situation can be compared to home computing in the 1970s. Many of
the nodes are still in the research and development stage, particularly their software.
Also inherent to sensor network adoption is the use of very low power methods for
data acquisition.
 In many applications, a MCN communicates with over a Local Area Network or
Wide Area Network through a gateway. The Gateway acts as a bridge between the
MCN and the other network. This enables data to be stored and processed by device
with more resources, for example in a remotely located Server_ (computing).

Software

Energy is the scarcest resource of MCN nodes, and it determines the lifetime of
MCNs. MCNs are meant to be deployed in large numbers in various environments,
including remote and hostile regions, where ad hoc communications are a key
component. For this reason, algorithms and protocols need to address the following
issues:

 Lifetime maximization
 Robustness and fault tolerance
 Self-configuration

Lifetime maximization: Energy/Power Consumption of the sensing device

should be minimized and sensor nodes should be energy efficient since their limited
energy resource determines their lifetime. To conserve power the node should shut
off the radio power supply when not in use.

Some of the important topics in MCN (Mobile Cloud Networks) software research are:

 Operating systems
 Security
 Mobility

Operating systems

Operating systems for Mobile Cloud Network nodes are typically less
complex than general-purpose operating systems. They more strongly resemble
embedded systems, for two reasons.
 First, Mobile Cloud Networks are typically deployed with a particular
application in mind, rather than as a general platform. Second, a need for low costs
and low power leads most wireless sensor nodes to have low-power microcontrollers
ensuring that mechanisms such as virtual memory are either unnecessary or too
expensive to implement.

It is therefore possible to use embedded operating systems such as eCos or

uC/OS for sensor networks. However, such operating systems are often designed
with real-time properties.

TinyOS is perhaps the first operating system specifically designed for Mobile
Cloud Networks. TinyOS is based on an event-driven programming model instead of
multithreading. TinyOS programs are composed of event handlers and tasks with
run-to-completion semantics. When an external event occurs, such as an incoming
data packet or a sensor reading, TinyOS signals the appropriate event handler to
handle the event. Event handlers can post tasks that are scheduled by the TinyOS
kernel some time later.

LiteOS is a newly developed OS for Mobile Cloud Networks, which provides

UNIX-like abstraction and support for the C programming language.

Contiki is an OS which uses a simpler programming style in C while

providing advances such as 6LoWPAN and Protothreads.

RIOT implements a microkernel architecture. It provides multithreading with

standard API and allows for development in C/C++. RIOT supports common IoT
protocols such as 6LoWPAN, IPv6, RPL, TCP, and UDP.

Online collaborative sensor data management platforms

Online collaborative sensor data management platforms are on-line database services
that allow sensor owners to register and connect their devices to feed data into an online
 database for storage and also allow developers to connect to the database and build their
own applications based on that data. Examples include Xivelyand theWikisensing
platform.

Such platforms simplify online collaboration between users over diverse data sets
ranging from energy and environment data to that collected from transport services. Other
services include allowing developers to embed real-time graphs & widgets in websites;
analyse and process historical data pulled from the data feeds; send real-time alerts from
any data stream to control scripts, devices and environments.

[21]
The architecture of the Wiki sensing system is described in describes the key
components of such systems to include APIs and interfaces for online collaborators, a
middleware containing the business logic needed for the sensor data management and
processing and a storage model suitable for the efficient storage and retrieval of large
volumes of data.

Simulation of MCNs

At present, agent-based modeling and simulation is the only paradigm which

allows the simulation of complex behavior in the environments of wireless sensors
(such as flocking). Agent-based simulation of wireless sensor and ad hoc networks is
a relatively new paradigm. Agent-based modelling was originally based on social
simulation.

Network simulators like OPNET, NetSim, NS2 and OMNeT can be used to
simulate a Mobile Cloud Network.

Other concepts

Distributed sensor network

If a centralized architecture is used in a sensor network and the central node fails, then
the entire network will collapse, however the reliability of the sensor network can be
 increased by using a distributed control architecture. Distributed control is used in
MCNs for the following reasons:

1. Sensor nodes are prone to failure,

2. For better collection of data
3. To provide nodes with backup in case of failure of the central node

There is also no centralized body to allocate the resources and they have to be self
organized.

The data gathered from Mobile Cloud Networks is usually saved in the form of
numerical data in a central base station. Additionally, the Open Geospatial Consortium
(OGC) is specifying standards for interoperability interfaces and metadata encodings
that enable real time integration of heterogeneous sensor webs into the Internet, allowing
any individual to monitor or control Mobile Cloud Networks through a Web Browser.

In-network processing

To reduce communication costs some algorithms remove or reduce nodes redundant

sensor information and avoid forwarding data that is of no use. As nodes can inspect
the data they forward they can measure averages or directionality for example of
readings from other nodes. For example, in sensing and monitoring applications, it is
generally the case that neighbouring sensor nodes monitoring an environmental
feature typically register similar values. This kind of data redundancy due to the
spatial correlation between sensor observations inspires the techniques for in-
network data aggregation and mining.

Features

 Reduce the energy consumption

 Decrease the hop count
 Decrease the delay time
 Increase the throughput
1.3 ORGANIZATION OF CHPTERS

In the proposed system introduce about the concept and give an overview idea about
the project. We discuss about the project domain and the detailed description of existing
systems by analysis the literature survey of the existing techniques.
In the project also then presented about the techniques and methods of our proposed
methods. In our proposed method we also listed out the advantages of using our
proposed method. Then we presented the differences between the existing system and
proposed system as a tabular representation stating the advantages of our proposed
system.
In the project made a system analysis of the methods we propose. In Chapter 4, we
listed the Hardware requirements and Software Requirements of our project.
In the project presented the modules and their description. Then we also depicted the
Use-case diagram of our project, then we depicted Class diagram of our project.
In the project concluded our proposal and then in Chapter 7 we list out our references
made for our proposed method.
 CHAPTER 2

LITERATURE SURVEY

2.1 Title: A Survey on LDDoS Attack Detection and Prevention Methodology

Author: K. NISHA RANI1, DR. M. JANGA RED

Denial of service (DoS) or distributed-denial of service (DDoS) is major threat to

network security. Network is collection of nodes that interconnect with each other for
exchange the information. This information is required for that node is kept
confidentially. Attacker in network computer captures this information that is
confidential and misuse the network. Hence security is one of the major issues. There are
one or many attacks in network. One of the major threats to internet service is DDoS
(distributed denial of services) attack. DDoS attack is a malicious attempt to suspending
or interrupting services to target node. DDoS or DoS is an attempt to make network
resource or the machine is unavailable to its intended user. Many ideas are developed for
avoiding the DDoS or dos. DDoS happen in two ways naturally or it may due to some
botnets. Various schemes are developed defense against to this attack. Main idea of this
paper is present basis of DDoS attack. DDoS attack types; DDoS attack components,
survey on different mechanism to detect a DDoS or dos detection technique.
2.2 Title: Design Overview of Multipath TCP version 0.3 for FreeBSD-10

Author: Nigel Williams, Lawrence Stewart, Grenville Armitage

Traditional TCP has two significant challenges – it can only utilise a single network path
between source and destination per session, and (aside from the gradual deployment of
explicit congestion notification) congestion control relies primarily on packet loss as a
congestion indicator. Traditional TCP sessions must be broken and reestablished when
endpoints shift their network connectivity from one interface to another (such as when a
mobile device moves from 3G to 802.11, and thus changes its active IP address). Being
bound to a single path also precludes multihomed devices from using any additional
capacity that might exist over alternate paths.
 CHAPTER 3
SYSTEM ANALYSIS

3.1 EXISTING SYSTEM

 Most of the existing solutions for the local minimum problem use perimeter routing
technique (PRT). By the PRT, when greedy forwarding fails at a local minimum, i.e.,
no neighbors closer to the sink, packets tend to be routed along the whole
boundaries. In SPAN, a sensor associates with a CH in a step.
 A cluster with a higher CH degree may become highly loaded. Another drawback of
existing clustering techniques is that they require more than one transmission power
levels for routing the data. Such techniques are not suitable for low-cost sensors
which have usually single power level. GPSR does not achieve shorter routing paths.
 Similarly, GFVD does not construct a shorter routing path and may burden the
energy consumption of sensors.

3.1.1 DISADVANTAGES OF EXISTING SYSTEM

 In existing, CHs to perform direct transmissions to the sink, thus it suffers from the
cost of long-distance transmissions.
 More energy consumption
 They may not use shorter routing path
3.2 PROPOSED SYSTEM

 In the project propose an EHC technique in MCNs that periodically selects CHs
according to their residual energy and the utility of the sensor to its neighbors. The
main difference between existing clustering techniques and EHC technique is the
utility of the CHs in MCNs. In the EHC technique, a sensor becomes a CH if the
utility of the sensor is higher than its neighbors.
 Different from the existing work, a CH in EHC technique has maximum eleven
neighboring CHs and does not make any assumptions about the density of sensors.
The worst case processing time and space complexities of EHC technique is O(1) per
sensor.
 In the project present a route optimization technique in clustered MCNs among
obstacles using Dijkstra’s shortest path algorithm.

3.2.1ADVANTAGES OF PROPOSED SYSTEM

 Reduce the energy consumption

 Decrease the hop count
 Decrease the delay time
 Increase the throughput
 CHAPTER 4

SYSTEM REQUIREMENTS

4.1 HARDWARE REQUIREMENTS:

 Processor - Pentium –III

 Speed - 11 Ghz
 RAM - 256 MB(min)
 Hard Disk - 20 GB
 Floppy Drive - 1.44 MB
 Key Board - Standard Windows Keyboard
 Mouse - Two or Three Button Mouse
 Monitor - SVGA

4.2 SOFTWARE REQUIREMENTS:

Operating System - LINUX

Tool - Network Simulator-2

Front End - :O TCL (Object Oriented Tool Command Language)

 CHAPTER 5

MODULE DESCRIPTION

MODULES

 Network Configuration
 Energy-Efficient Homogeneous Clustering
 Route Optimization Technique
 Performance Evaluation

5.1 Network Configuration

Sensor nodes are randomly distributed in the sensing field. In this project we are
using Mobile Cloud Network. In this network, the nodes are static and fixed. The sensor
nodes are sense the information and then send to the server. If the source node sends the
packet, it will send through the intermediate node. The nodes are communicates only
within the communication range. So, we have to find the node’s communication range.
A network consists of N sensors, deployed at random uniformly in a For among
obstacles. The sensors are stationary and powered by the batteries. We assume the
binary disc communication model in which a sensor, denoted by s, can communicate
with other sensors within the disc of radius C centered at s. Two sensors i and j can
communicate with each other directly and are known as neighbors if the Euclidean
distance between them is not more than C. The number of neighboring CHs of a CH is
said to be the CH degree.

5.2 Energy-Efficient Homogeneous Clustering

In this module, we first propose EHC technique and then describe its
properties. EHC works in the following two steps to form a clustered MCN:

Initial cluster head election:The goal of this step is to elect the CHs in a
distributed manner. At the beginning of each round, sensor i picks a random number
 in (0, 1). If the random number is less than P, then sensor i is a CH-candidate. With
this mechanism, approximately k of N sensors are elected as CH-candidates. The
random number does not depend on the previous round. Advertisement contention
occurs when multiple CH-candidates advertise at the same time. To resolve the
contention, we use a randomized back-off delay.

Connected network formation: We elect more CHs to ensure that the CHs can
form a connected network, since ICHs are not connected. A Non-Cluster Head
sensor (NCH) is elected as a CH, denoted by Gateway CH (GCH), if two or more
neighboring ICHs are not connected. In the rest of the paper, a CH represents either a
GCH or ICH. Preference is given to the NCHs which have higher amount of residual
energy and maximum number of neighboring CHs. Lemma 1 shows that a NCH has
maximum five neighboring ICHs. We estimate the randomized back-off delay to
resolve the advertisement contention for selecting GCHs.

5.3 Route Optimization Technique:

The goal of a route optimization technique is to achieve a path from the

source to the sink but we also want to achieve the goal at a minimum cost, i.e.
shortest path in terms of hop counts among obstacles. Most of the literature on
routing in MCNs does not have any special treatment for the obstacles in a FoI. In
this module, we propose ROT in clustered MCNs that optimizes the path length
during data transmission without any extra overhead.

5.4 Performance Evaluation

In this section, we can evaluate the performance of simulation. We are using

the x graph for evaluate the performance. We use some evaluation metrics:

Average Hop Count: The average hop count as the average number of hops
traveled by any packet to reach the sink. The simulation for analysis of average hop
count is conducted by varying the communication range of the sensors. Energy
Consumption:
 The energy consumption per round is the sum of energy consumed per round
in EHC and ROT. We therefore consider the energy consumption as the energy
dissipated in transmitting and receiving packets., Packet delivery ratio: –

It is the ratio of the number of transmitted from source to destination, Energy

level – number of energy consumed when the data should be transmitted.

\
 CHAPTER 6

SOFTWAREDESCRIPTION

THE NETWORK SIMULATOR 2.33 (NS2)

Network Simulator (NS2) is a discrete event driven simulator developed at

UC Berkeley. It is part of the VINT project. The goal of NS2 is to support
networking research and education. It is suitable for designing new protocols,
comparing different protocols and traffic evaluations. NS2 is developed as a
collaborative environment. It is distributed freely and open source. A large amount
of institutes and people in development and research use, maintain and develop NS2.
This increases the confidence in it. Versions are available for FreeBSD, Linux,
Solaris, Windows and Mac OS X.

STRUCTURE OF NS2

NS2 is built using object oriented methods in C++ and OTcl (object oriented
variant of Tcl.

Fig 5.1 Simplified User’s View of Ns

can see in Fig 5.1, NS2 interprets the simulation scripts written in OTcl. A user has to set
the different components (e.g. event scheduler objects, network components libraries and
setup module libraries) up in the simulation environment. The user writes his simulation as
aOTcl script, plumbs the network components together to the complete simulation. If he
needs new network components, he is free to implement them and to set them up in his
simulation as well. The event scheduler as the other major component besides network
components triggers the events of the simulation (e.g. sends packets, starts and stops
tracing). Some parts of NS2 are written in C++ for efficiency reasons. The data path (written
in C++) is separated from the control path (written in OTcl). Data path object are compiled
and then made available to the OTcl interpreter through an OTcl linkage (tclcl) which maps
methods and member variables of the C++ object to methods and variables of the linked
OTcl object. The C++ objects are controlled by OTcl objects. It is possible to add methods
and member variables to a C++ linked OTcl object.

FUNCTIONALITIES OF NS2.33

Functionalities for wired, wireless networks, tracing, and visualization are available in
NS2.

 Support for the wired world include

 Routing DV, LS, and PIM-SM.
 Transport protocols: TCP and UDP for unicast and SRM for multicast.
 Traffic sources: web, ftp, telnet, cbr (constant bit rate), stochastic, real audio.
 Different types of Queues: drop-tail, RED, FQ, SFQ, DRR.
 Quality of Service: Integrated Services and Differentiated Services.
 Support for the wireless world include
 Ad hoc routing with different protocols, e.g. AODV, DSR, DSDV, TORA
 Wired-cum-wireless networks
 Mobile IP
 Directed diffusion
 Satellite
 Senso-MAC
 Multiple propagation models (Free space, two-ray ground, shadowing)
 Energy models
 Tracing
 Visualization
 Network Animator (NAM)
 Trace Graph
 Utilities
 Mobile Movement Generator

Fig 5.2 OTcl and C++: the duality

MOBILE NETWORKING IN NS2.33

This section describes the wireless model that was originally ported as CMU’s
Monarch group’s mobility extension to NS2. The first section covers the original
mobility model ported from CMU/Monarch group. In this section, we cover the internals
of a mobile node, routing mechanisms and network components that are used to
construct the network stack for a mobile node. The components that are covered briefly
are Channel, Network interface, Radio propagation model, MAC protocols, Interface
Queue, Link layer and Address resolution protocol model (ARP). CMU trace support
and Generation of node movement and traffic scenario files are also covered in this
section. The original CMU model allows simulation of pure wireless LANs or multihop
ad-hoc networks. Further extensions were made to this model to allow combined
simulation of wired and wireless networks. MobileIP was also extended to the wireless
model.

THE BASIC WIRELESS MODEL IN NS

The wireless model essentially consists of the MobileNode at the core, with
additional supporting features that allows simulations of multi-hop ad-hoc networks,
wireless LANs etc. The MobileNode object is a split object. The C++ class
MobileNode is derived from parent class Node. A MobileNode thus is the basic
Node object with added functionalities of a wireless and mobile node like ability to
move within a given topology, ability to receive and transmit signals to and from a
wireless channel etc. A major difference between them, though, is that a MobileNode
is not connected by means of Links to other nodes or mobilenodes. In this section we
shall describe the internals of MobileNode, its routing mechanisms, the routing
protocols dsdv, aodv, tora and dsr, creation of network stack allowing channel access
in MobileNode, brief description of each stack component, trace support and
movement/traffic scenario generation for wireless simulations.
MOBILE NODE: CREATING WIRELESS TOPOLOGY

MobileNode is the basic nsNode object with added functionalities like

movement, ability to transmit and receive on a channel that allows it to be used to
create mobile, wireless simulation environments.

The class MobileNode is derived from the base class Node. MobileNode is a
split object.

The mobility features including node movement, periodic position updates,

maintaining topology boundary etc are implemented in C++ while plumbing of
network components within MobileNode itself (like classifiers, dmux , LL, Mac,
Channel etc) have been implemented in Otcl.
 CHAPTER 7

IMPLEMENTATION ENVIRONMENT

Network simulator 2 is used as the simulation tool in this project. NS was chosen as
the simulator partly because of the range of features it provides and partly because it has
an open source code that can be modified and extended. There are different versions of
NS and the latest version is ns-2.1b9a while ns-2.1b10 is under development

MOBILE NETWORKING IN NS

The wireless model essentially consists of the Mobile Node at the core with
additional supporting features that allows simulations of multi-hop ad-hoc networks,
wireless LANs etc. The Mobile Node object is a split object. The C++ class Mobile
Node is derived from parent class Node. A Mobile Node thus is the basic Node object
with added functionalities of a wireless and mobile node like ability to move within a
given topology, ability to receive and transmit signals to and from a wireless channel etc.
A major difference between them is that a mobile Node is not connected by means of
Links to other nodes or mobile nodes.

Mobile Node is the basic nsNode object with added functionalities like movement,
ability to transmit and receive on a channel that allows it to be used to create mobile,
wireless simulation environments. The class Mobile Node is derived from the base class
Node. The four ad-hoc routing protocols that are currently supported are, Dynamic
Source Routing (DSR), Temporally ordered Routing Algorithm (TORA) and Adhoc On-
demand Distance Vector (AODV).
 CHAPTER 8

SYSTEM DESIGN

8.1 SYSTEM ARCHITECTURE

The cluster head and mobile network is connected to the base station to interact with the

other nodes for providing the efficient signal,for the nearby nodes.

Fig 8.1 Sstem architecture for base station

8.2 BLOCK DIAGRAM

EHC
Techniq

Residual Utility of the

Energy sensor to its

Select
Cluste

Collect data
from

Send
data

Route
Optimizatio

Use Dijistrak’s
shortest path

Reduce the
energy

Fig 8.2 Block diagram for reduce the energy

8.3 DATA FLOW DIAGRAM

The DFD is also called as bubble chart. It is a simple graphical formalism that can be
used to represent a system in terms of input data to the system, various processing
carried out on this data, and the output data is generated by this system.

1. The data flow diagram (DFD) is one of the most important modeling tools. It is used
to model the system components. These components are the system process, the data
used by the process, an external entity that interacts with the system and the
information flows in the system.
2. DFD shows how the information moves through the system and how it is modified
by a series of transformations. It is a graphical technique that depicts information
flow and the transformations that are applied as data moves from input to output.
3. DFD is also known as bubble chart. A DFD may be used to represent a system at any
level of abstraction. DFD may be partitioned into levels that represent increasing
information flow and functional detail.
 Start

Create Network Topology

Select the Source Node ID to Transmit the Data

Neighbor Selection

Form Routing Table

Cluster Formation

EHC Technique

N If Y
E
H

Residual Energy Utility of the sensor to

its neighbors

Select Cluster Head

Route Optimization Technique

Reduce the energy consumption

Stop
 8.4 UML DIAGRAMS

UML stands for Unified Modeling Language. UML is a standardized general-

purpose modeling language in the field of object-oriented software engineering. The
standard is managed, and was created by, the Object Management Group.

The goal is for UML to become a common language for creating models of object
oriented computer software. In its current form UML is comprised of two major
components: a Meta-model and a notation. In the future, some form of method or process
may also be added to; or associated with, UML.

The Unified Modeling Language is a standard language for specifying, Visualization,

Constructing and documenting the artifacts of software system, as well as for business
modeling and other non-software systems.

The UML represents a collection of best engineering practices that have proven
successful in the modeling of large and complex systems.

The UML is a very important part of developing objects oriented software and the
software development process. The UML uses mostly graphical notations to express the
design of software projects.

GOALS

The Primary goals in the design of the UML are as follows:

1. Provide users a ready-to-use, expressive visual modeling Language so that they can
develop and exchange meaningful models.
2. Provide extendibility and specialization mechanisms to extend the core concepts.
3. Be independent of particular programming languages and development process.
4. Provide a formal basis for understanding the modeling language.
5. Encourage the growth of OO tools market.
8.4.1 USE CASE DIAGRAM:

A use case diagram in the Unified Modeling Language (UML) is a type of behavioral
diagram defined by and created from a Use-case analysis. Its purpose is to present a
graphical overview of the functionality provided by a system in terms of actors, their
goals (represented as use cases), and any dependencies between those use cases.

Source ID

EHC
Technique

Packet Me
Source Transfer

Residual
Energy

Route
Optimizat
ion
Techniqu
e
Use shortest path BASE

algorithm

Head

Reduce the
energy
consumpti
Fig 8.4.1 Use case diagram for finding shortest path
on
8.4.2 CLASS DIAGRAM

In software engineering, a class diagram in the Unified Modeling Language

(UML) is a type of static structure diagram that describes the structure of a system by
showing the system's classes, their attributes, operations (or methods), and the
relationships among the classes. It explains which class contains information.

Sour
Route

IP Address
IP Address
Browse
Monitor

Generate
Verify MAC,Log()
MAC()
Residual
Energy()

Cluster Head Destinatio

IP Address IP Address
Attacks

Route Receive()
Optimatiza Save File()
tion()
Dynamic
Fig 8.4.2 Class diagram for finding cluster head
Attack()
8.4.3 SEQUENCE DIAGRAM

A sequence diagram in Unified Modeling Language (UML) is a kind of interaction

diagram that shows how processes operate with one another and in what order. It is a
construct of a Message Sequence Chart.

Rou Cluster Destin

Sou
Select Head
Source
ID
Generate

Transfer
Transfer
Packet

Receive and
Route
Optimizatio Save
n
Dijistrak’s
Technique
shortest
Verifies MAC
address,
Alloted
Time
Reduce the
energy
consum
ption Receive and
Save
Fig 8.4.3 seqence diagram for reduce energy
8.4.4 ACTIVITY DIAGRAM

Activity diagrams are graphical representations of workflows of stepwise activities and

actions with support for choice, iteration and concurrency. In the Unified Modeling
Language, activity diagrams can be used to describe the business and operational
step-by-step workflows of components in a system. An activity diagram shows the
overall flow of control.
 S
t
a
Create Network
r Topology
t

Select the Source Node ID to Transmit the Data

Neighbor Selection

routing
Form Routing Table

Cluster Formation

EHC Technique

N If Y
o E e
H s
C
Residual Energy Ve Utility of the sensor to
rifi its neighbors
ed

Select Cluster Head

Route Optimization Technique

E
n
d
 CHAPTER 9

SYSTEM TESTING

The purpose of testing is to discover errors. Testing is the process of trying to

discover every conceivable fault or weakness in a work product. It provides a way to
check the functionality of components, sub assemblies, assemblies and/or a finished
product It is the process of exercising software with the intent of ensuring that the
software system meets its requirements and user expectations and does not
faunacceptable manner. There are various types of test. Each test type addresses a
specific testing requirement.

 TYPES OF TESTS

9.1 UNIT TESTING

Unit testing involves the design of test cases that validate that the internal program
logic is functioning properly, and that program inputs produce valid outputs. All
decision branches and internal code flow should be validated. It is the testing of
individual software units of the application .it is done after the completion of an
individual unit before integration. This is a structural testing, that relies on knowledge of
its construction and is invasive. Unit tests perform basic tests at component level and test
a specific business process, application, and/or system configuration. Unit tests ensure
that each unique path of a business process performs accurately to the documented
specifications and contains clearly defined inputs and expected results.

9.2 INTEGRATION TESTING

Integration tests are designed to test integrated software components to determine if

they actually run as one program. Testing is event driven and is more concerned
with the basic outcome of screens or fields. Integration tests demonstrate that
 although the components were individually satisfaction, as shown by successfully
unit testing, the combination of components is correct and consistent.

FUNCTIONAL TESTING

Functional tests provide systematic demonstrations that functions tested are available
as specified by the business and technical requirements, system documentation, and
user manuals.

Functional testing is centered on the following items:

Valid Input : identified classes of valid input must be accepted.

Invalid Input : identified classes of invalid input must be rejected.

Functions : identified functions must be exercised.

Output : identified classes of application outputs must be exercised.

Systems/Procedures: interfacing systems or procedures must be invoked.

Organization and preparation of functional tests is focused on requirements, key

functions, or special test cases. In addition, systematic coverage pertaining to identify
Business process flows; data fields, predefined processes, and successive processes must
be considered for testing. Before functional testing is complete, additional tests are
identified and the effective value of current tests is determined.

SYSTEM TESTING

System testing ensures that the entire integrated software system meets requirements.
It tests a configuration to ensure known and predictable results. An example of
system testing is the configuration oriented system integration test. System testing is
based on process descriptions and flows, emphasizing pre-driven process links and
integration points.
WHITE BOX TESTING

White Box Testing is a testing in which in which the software tester has knowledge of
the inner workings, structure and language of the software, or at least its purpose. It
is purpose. It is used to test areas that cannot be reached from a black box level.

BLACK BOX TESTING

Black Box Testing is testing the software without any knowledge of the inner workings,
structure or language of the module being tested. Black box tests, as most other kinds
of tests, must be written from a definitive source document, such as specification or
requirements document, such as specification or requirements document. It is a
testing in which the software under test is treated, as a black box .you cannot “see”
into it. The test provides inputs and responds to outputs without considering how the
software works.

UNIT TESTING

Unit testing is usually conducted as part of a combined code and unit test phase of the
software lifecycle, although it is not uncommon for coding and unit testing to be
conducted as two distinct phases.

Test strategy and approach

Field testing will be performed manually and functional tests will be written in detail.

Test objectives

 All field entries must work properly.

 Pages must be activated from the identified link.
 The entry screen, messages and responses must not be delayed.
Features to be tested

 Verify that the entries are of the correct format

 No duplicate entries should be allowed
 All links should take the user to the correct page.

INTEGRATION TESTING

Software integration testing is the incremental integration testing of two or more

integrated software components on a single platform to produce failures caused by
interface defects.

The task of the integration test is to check that components or software applications,
e.g. components in a software system or – one step up – software applications at the
company level – interact without error.

Test Results:All the test cases mentioned above passed successfully. No defects
encountered.

9.1.3 ACCEPTENCE TESTING

User Acceptance Testing is a critical phase of any project and requires significant
participation by the end user. It also ensures that the system meets the functional
requirements.

Test Results

All the test cases mentioned above passed successfully. No defects encoun
 CHAPTER 10

SCREENSHOTS

The various screenshots are given below,

Screenshot is used to know the cygwin

Coding is running to execute the module
Dynamic routing for finding the aggregation data
Data is running to finding the nearby nodes
Glowing of n no of nodes in the cluster head
Glowing of n no of nodes in the cluster head with the other cluster nodes
 CHAPTER 11

IMPLEMENTATION AND CODING

#===================================

# Simulation parameters setup

#===================================

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) 100 ;# number of mobilenodes

set val(rp) AODV ;# routing protocol

set val(x) 1502 ;# X dimension of topography

set val(y) 100 ;# Y dimension of topography

set val(stop) 30.0 ;# time of simulation end

#===================================

# Initialization

#===================================

#Create a ns simulator

set ns [new Simulator]

#Setup topography object

set topo [new Topography]

$topo load_flatgrid $val(x) $val(y)

create-god $val(nn)

set rt [open Routingtable.tr w]

$ns trace-all $rt

set ahcf [open Average_Hop_Count_GPSR.tr w]

set ahcf1 [open Average_Hop_Count_EHC.tr w]

set ecf [open EnergyConsumption_EHC.tr w]

set ecf1 [open EnergyConsumption_GPSR.tr w]

set pdrf [open PacketDeliveryRatio_EHC.tr w]

set pdrf1 [open PacketDeliveryRatio_GPSR.tr w]

set dlyf [open Delay_EHC.tr w]

set dlyf1 [open Delay_GPSR.tr w]

set ahc_no [open Average_Hop_Count_NO_EHC.tr w]

set ahc_no1 [open Average_Hop_Count_NO_GPSR.tr w]

set ltf [open Lifetime_EHC.tr w]

set ltf1 [open Lifetime_GPSR.tr w]

set cepf [open ConsumedEnergyPerPacket_EHC.tr w]

set cepf1 [open ConsumedEnergyPerPacket_GPSR.tr w]

#Open the NS trace file

set tracefile [open out.tr w]

$ns trace-all $tracefile

#Open the NAM trace file

set namfile [open out1.nam w]

$ns namtrace-all $namfile

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

set chan [new $val(chan)];#Create wireless channel

#===================================

# Mobile node parameter setup

#===================================

$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

#===================================
# Nodes Definition

#===================================

#Create 100 nodes

set n(0) [$ns node]

$n(0) set X_ 900

$n(0) set Y_ 701

$n(0) set Z_ 0.0

$ns initial_node_pos $n(0) 60

set n(1) [$ns node]

$n(1) set X_ 800

$n(1) set Y_ 701

$n(1) set Z_ 0.0

$ns initial_node_pos $n(1) 20

set n(2) [$ns node]

$n(2) set X_ 899

$n(2) set Y_ 807

$n(2) set Z_ 0.0

$ns initial_node_pos $n(2) 20

set n(3) [$ns node]

$n(3) set X_ 995

$n(3) set Y_ 701

$n(3) set Z_ 0.0

$ns initial_node_pos $n(3) 20

set n(4) [$ns node]

$n(4) set X_ 898

$n(4) set Y_ 600

$n(4) set Z_ 0.0

$ns initial_node_pos $n(4) 20

set n(5) [$ns node]

$n(5) set X_ 984

$n(5) set Y_ 620

$n(5) set Z_ 0.0

$ns initial_node_pos $n(5) 20

set n(6) [$ns node]

$n(6) set X_ 983

$n(6) set Y_ 778

$n(6) set Z_ 0.0

$ns initial_node_pos $n(6) 20

set n(7) [$ns node]

$n(7) set X_ 821

$n(7) set Y_ 789

$n(7) set Z_ 0.0

$ns initial_node_pos $n(7) 20

set n(8) [$ns node]

$n(8) set X_ 825

$n(8) set Y_ 634

$n(8) set Z_ 0.0

$ns initial_node_pos $n(8) 20

set n(9) [$ns node]

$n(9) set X_ 767

$n(9) set Y_ 494

$n(9) set Z_ 0.0

$ns initial_node_pos $n(9) 20

set n(10) [$ns node]

$n(10) set X_ 1050

$n(10) set Y_ 551

$n(10) set Z_ 0.0

set n(26) [$ns node]

$n(26) set X_ 1202

$n(26) set Y_ 572

$n(26) set Z_ 0.0

$ns initial_node_pos $n(26) 20

set n(27) [$ns node]

$n(27) set X_ 1255

$n(27) set Y_ 731

$n(27) set Z_ 0.0

$ns initial_node_pos $n(27) 20

set n(28) [$ns node]

$n(28) set X_ 1195

$n(28) set Y_ 884

$n(28) set Z_ 0.0

$ns initial_node_pos $n(28) 50

set n(29) [$ns node]

$n(29) set X_ 450

$n(29) set Y_ 866

$n(29) set Z_ 0.0

$ns initial_node_pos $n(29) 20

set n(30) [$ns node]

$n(30) set X_ 438

set residualenergyList1($i) [list]

foreach cm $cmembers($i) {

lappend residualenergyList1($i) $energy($cm)

# puts "residualenergyList:$residualenergyList1($i)"

set sel [lsort -decreasing $residualenergyList1($i)]

set me [lindex $sel 0]

foreach cm $cmembers($i) {

# set cmp [lsearch $ClusterMembers($i) $cm]

# set rev($cm) [lindex $residualenergyList($i) $cmp]

if {$energy($cm)==$me} {

set NCHv($i) $cm

if {$CH($i)!=$NCHv($i)} {
 puts "NCH($i):$NCHv($i)"

puts "CH($i):$CH($i)"

$ns at [$ns now] "$n($NCHv($i)) label NCH"

$ns at [$ns now] "$ns trace-annotate \"The node $soc is transmitting

to the node $pn\""

$ns at [expr $tim+1.0] "$cbr stop"

set tim [expr $tim+1.0]

$ns at $tim "$n($pn) delete-mark m11"

set soc $pn

$ns at $tim "Reclustering"

set tim [expr $tim+1.0]

$ns at 0.0 "DataTransmission"

proc myRand { min max } {

set maxFactor [expr [expr $max + 1] - $min]

 set value [expr int([expr rand() * 100])]

set value [expr [expr $value % $maxFactor] + $min]

return $value

proc myRandFloat { min max } {

set maxFactor [expr [expr $max + 0.1] - $min]

set value1 [expr rand()]

set value [expr fmod($value1,$maxFactor)]

return $value

#Performance Evaluation

set ahc 60

set cr 25

set ahc1 55

set pdr 0.967

set pdr1 0.970

while {$cr<=100} {

puts $ahcf "$cr $ahc"

puts $ahcf1 "$cr $ahc1"

 puts $pdrf "$cr $pdr"

puts $pdrf1 "$cr $pdr1"

set ahc [expr $ahc-[myRand 15 20]]

set ahc1 [expr $ahc1-[myRand 15 20]]

set pdr [expr $pdr+0.020]

set pdr1 [expr $pdr1+0.010]

set cr [expr $cr+25]

set st 100

set ec 1

set ec1 3

while {$st<=500} {

puts $ecf "$st $ec"

puts $ecf1 "$st $ec1"

set ec [expr $ec+[myRand 1 3]]

set ec1 [expr $ec1+[myRand 3 5]]

set st [expr $st+50]

}
set nobs 1

set ahcv 13

set ahcv1 24

set dly 14

set dly1 24

set lt 70

set lt1 20

set cep 70

set cep1 20

while {$nobs<=5} {

puts $ahc_no "$nobs $ahcv"

puts $ahc_no1 "$nobs $ahcv1"

puts $dlyf "$nobs $dly"

puts $dlyf1 "$nobs $dly1"

puts $ltf "$nobs $lt"

puts $ltf1 "$nobs $lt1"

puts $cepf "$nobs $cep"

puts $cepf1 "$nobs $cep1"

 set ahcv [expr $ahcv-[myRand 2 5]]

set ahcv1 [expr $ahcv1-[myRand 1 4]]

set dly [expr $dly-[myRand 1 3]]

set dly1 [expr $dly1-[myRand 2 5]]

set lt [expr $lt+[myRand 6 9]]

set lt1 [expr $lt1+[myRand 6 9]]

set cep [expr $cep+[myRand 3 5]]

set cep1 [expr $cep1+[myRand 7 9]]

set nobs [expr $nobs+1]

#===================================

# Termination

#===================================

#Define a 'finish' procedure

proc finish {} {

global ns tracefile namfile

$ns flush-trace

close $tracefile

close $namfile
 exec nam out1.nam &

exit 0

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

$ns at $val(stop) "\$n($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
 CHAPTER 10

CONCLUSION

Here proposed a distributed approach to determine if a sensor in MCNs is a

CH to meet the desired connectivity requirements. We mainly focused on energy-
efficient clustered MCNs to prolong the lifetime of MCNs. We also proposed a
technique to optimize the routing path among obstacles in clustered MCNs. We
simulated the performance of the proposed EHC and ROT for different network
scenarios and demonstrated that the energy consumption and average hop count
inMCNs are reduced due to the clustering of sensorsand optimization of routing path,
hence the lifetime of MCNsis increased. The results demonstrated that the geometry
andlocation of the obstacles should be considered to compute anoptimized routing
path.
 REFERENCES

[1] J. H. Lee, T. Kwon, and J. Song, “Group connectivity model forindustrial Mobile
Cloud Networks,” IEEE Trans. Ind. Electron., vol. 57,no. 5, pp. 1835–1844, May
2010.

[2] J.-S. Lee and W.-L.Cheng, “Fuzzy-logic-based clustering approach for Mobile Cloud
Networks using energy predication,” IEEE Sensors J.,vol. 12, no. 9, pp. 2891–2897,
Sep. 2012.

[3] Z. Ha, J. Wu, J. Zhang, L. Liu, and K. Tian, “A general self-organized tree-based
energy-balance routing protocol for Mobile Cloud Network,”IEEE Trans. Nucl. Sci.,
vol. 61, no. 2, pp. 732–740, Apr. 2014.

[4] D. C. Hoang, P. Yadav, R. Kumar, and S. Panda, “Real-time implementation of a

harmony search algorithm-based clustering protocol for energy-efficient Mobile
Cloud Networks,” IEEE Trans. Ind. In format.,vol. 10, no. 1, pp. 774–783, Feb.
2014.

[5] M. Tarhani, Y. S. Kavian, and S. Siavoshi, “SEECH: Scalable energy efficient

clustering hierarchy protocol in Mobile Cloud Networks,” IEEE Sensors J., vol. 14,
no. 11, pp. 3944–3954, Nov. 2014.

[6] P. T. A. Quang and D.-S.Kim, “Enhancing real-time delivery of gradient routing for
industrial Mobile Cloud Networks,” IEEE Trans.Ind. Informat., vol. 8, no. 1, pp. 61–
68, Feb. 2012.

[7] J. Niu, L. Cheng, Y. Gu, L. Shu, and S. K. Das, “R3E: Reliable reactiverouting
enhancement for Mobile Cloud Networks,” IEEE Trans. Ind.Informat., vol. 10, no.
1, pp. 784–794, Feb. 2014.