Computer Communications 58 (2015) 4–15

Contents lists available at ScienceDirect

Computer Communications
journal homepage: www.elsevier.com/locate/comcom

Interoperability issues on heterogeneous wireless communication

for smart cities
Edson Avelar a, Lorena Marques a, Diego dos Passos a, Ricardo Macedo b, Kelvin Dias a,
Michele Nogueira b,⇑
a
Federal University of Pernambuco (UFPE), Brazil
b
Federal University of Paraná (UFPR), Brazil

a r t i c l e i n f o a b s t r a c t

Article history: Smart cities have become a reality around the world. They rely on wireless communication technologies,
Available online 11 July 2014 and they have provided many benefits to society, such as monitoring road traffic in real-time, giving
continuous healthcare assistance to residents and managing the environment. This article revisits key
Keywords: interoperability questions in heterogeneous wireless networks for smart cities, and outlines a simple,
Smart cities modular architecture to deal with these complex issues. The architecture is composed by sensing, access
Heterogeneous wireless communication network, Internet/cloud and application layers. Different features provided by the architecture, such as
Architecture
interoperability among technologies, low cost, reliability and security, have been evaluated through
Low cost
Interoperability
experiments and simulations under different scenarios. The QoS support and the seamless connectivity
between pairs of heterogeneous technologies are proposed through a policy-based management (PBM)
framework and MIH (Media Independent Handover). Moreover, an 802.11 mesh backbone composed
of different types of mesh routers has been deployed for interconnecting the sensors and actuators to
the Internet. Key results from experiments in the backbone are examined. They compare: (i) the perfor-
mance of a single-path routing protocol (OLSR) with a multipath one (MP-OLSR); (ii) the monitoring
delays from the proposed low cost sunspot/mesh and arduino/mesh gateways; and (iii) the authentica-
tion mechanisms employed. Significant results from simulations allow the analysis of the reliability on
vehicular/mesh networks under jamming attacks by applying the OLSR and MP-OLSR routing protocols.
Finally, this article provides an overview of open research questions.
Ó 2014 Elsevier B.V. All rights reserved.

1. Introduction Governments around the world, including the Japanese,

In the last decade, there has been a growing demand for more
attractive and efficient cities, in an attempt to reduce the effects
of urbanization. Researchers believe that following the pattern of
social change of the 1990s in some countries, new policies for sus-
tainable urban planning are required as a result of the huge migra-
tion of people from rural areas to only a few large cities [1,2]. The
high concentration of people raised different challenges for the
government, such as uncontrolled growth, traffic congestion,
crime, waste resource management and others. Furthermore,
owing to globalization, cities started to compete with each other
to attract the best professionals, by providing them attractive envi-
ronments where they could live [2]. These challenges have led gov-
ernments to adopt technologically-based approaches and handle
the negative effects of urbanization via broadband interconnected
cities, known as Smart Cities.
⇑ Corresponding author.
E-mail address: michele@inf.ufpr.br (M. Nogueira).
Germany and Brazilian ones, have made financial investments
and efforts to apply Information and Communication Technologies
(ICTs) for solving the issues produced by urbanization [3,4]. Wire-
less communication, embedded systems and wireless sensors are
examples of ICTs that can benefit different dimensions of societies.
ICTs provide integration among services in cities, collect real-time
data, analyze them and lead better decisions. Those technologies
have been considered by academic and industrial projects in many
contexts, such as healthcare, intelligent transportation and energy
savings, supporting the inclusion and assisted living; exploiting
vehicle-to-vehicle and vehicle-to-infrastructure wireless commu-
nication to alleviate jam in the cities; and assisting the efficient
management of power distribution grids, respectively [5,6].
However, the use of ICTs today is based on commercial solu-
tions making expensive and complex the integration of devices,
services and technologies. Big companies have promoted and spon-
sored the development of smart cities [7]. Hence, they encourage
people to use their products, as software and hardware, that often

http://dx.doi.org/10.1016/j.comcom.2014.07.005
0140-3664/Ó 2014 Elsevier B.V. All rights reserved.
 E. Avelar et al. / Computer Communications 58 (2015) 4–15
cannot interoperate with devices created by other companies. Anal-
ogously, there is a significant amount of testbeds handling specific
aspects of smart cities via off-the-shelf devices [8,9]. An example is
the use of different sensor motes that, in general, are low cost but
follow specific standards for physical and link layers, without
defining how upper layers must work. This makes interoperability
difficult even among devices from the same manufacturer,
compromising network scalability.
As a result of government initiatives, several smart cities pro-
jects have emerged, such as SmartSantander [10], SOFIA [11], City-
Sense [12], Motescope [13], Friedrichshafen T-City [14] and others.
However, most of these projects follow the traditional approach of
employing expensive devices and proprietary software. There is a
lack of work on smart cities that focuses on simple and low cost
infrastructures. In this context, this study offers a low cost solution
based on commodity hardware and open source software.
The key contributions of this article are threefold. First, it theo-
retically revisits the challenges of applying heterogeneous wireless
networks on smart cities, raising questions related to the interop-
erability of wireless communication technologies. Next, it presents
a heterogeneous, low cost and simple architecture for wireless
communication and illustrates how the architecture can be
employed by analyzing the key results obtained from experimental
evaluations. Finally, it highlights open research issues, observed
from the experiments.
This article proceeds as follows. Section 2 points out the chal-
lenges for developing heterogeneous wireless communication to
smart cities. Section 3 describes the proposed architecture.
Section 4 analyzes the key results obtained from the experimental
evaluation of the architecture. Section 5 highlights open research
questions. Finally, Section 6 concludes the article.
2. Revisiting smart cities and heterogeneity challenges
on wireless communication
Wireless communication technologies have been a key feature
to evolve smart cities. They are employed in different sectors of
society, such as transportation, resources management and health-
care, producing diverse benefits. They allow real-time data diffu-
sion among devices in the network, facilitating the monitoring
and the control of devices and resources, such as energy and water.
Wireless communication provides a fast access to remote informa-
tion, improving quality of life. These technologies offer new ser-
vices, such as real-time environmental monitoring, that lead to
better decisions and actions by governments and enterprises.
Two key features of smart cities are their interoperability and
the coexistence of different wireless communication technologies.
These features have attracted considerable attention because they
involve issues related to the design of heterogeneous wireless
networks and their application in urban environments. These
networks comprise devices (base stations, smartphones, ad hoc
routers and others), different technologies and networks, such as
wireless local area, ad hoc or vehicular networks [15].
Heterogeneous wireless networks present different challenges
resulting from interoperability and intensified by their application
in smart cities. Resource and network management, QoS (Quality
of Service), security, reliability, load balancing and scalability are
the main research issues in wireless networks yielded by these
two aspects [16–18]. We briefly describe these issues, highlighting
their effects.
 Resource and network management: In face of the expected
heterogeneity, the opportunistic and efficient use of resources
is essential. However, it is complex, since many aspects param-
eters and characteristics need to be considered. The direct
5
application of optimization techniques to find the optimal set-
ting for the network is a demanding task due to the dynamism
of these networks and the existence of delay-sensitive applica-
tions, that require real-time decisions. Despite of heterogeneity,
final users are concerned with financial cost, requiring a
resource management that could keep the final cost low. Differ-
ently from other networks, heterogeneous ones need to deal
with interferences caused by the diverse wireless communica-
tion technologies. Hence it is required new models and mecha-
nisms that could be used for, respectively, analyzing and
managing interferences, considering also urban environmental
aspects.
 QoS: Providing high volume of data to multimedia applications
for smartphones, tablets and other final user devices demand
novel mechanisms to guarantee quality of service in face of
the discrepancies of wireless technologies and network charac-
teristics as scalability. Many services and applications offered
by smart cities are sensitive to QoS. Examples are healthcare
applications, such as long-term remote disease management
or telesurgeries, or applications for smart grids and intelligent
transportation systems.
 Security: Heterogeneity raises a high level of complexity for
networks. New characteristics must be managed and more
aspects need to be considered, intensifying existing security
vulnerabilities on networks or producing new ones. On the
other hand, smart cities provide applications and new services
closer to final users. These cities have been instigated to
improve the quality of life for residents and assist their daily
tasks. Hence, in order to deal with new security vulnerabilities
yielded by the complexity, security must be redesigned consid-
ering not only the weaknesses of wireless communication, but
also the new characteristics resulted from this interoperable
context. Mechanisms to deal with users authentication,
accounting and authorization must be rethinking, as well as
mechanisms to keep the availability of services and applications
even in the presence of attacks. Furthermore, mechanisms for
correctly identifying users and securely managing their identi-
ties, as identity management systems [19], are required, since
it is expected a huge amount of final users using smart cities
services and they need to be able to access them.
 Reliability: Heterogeneous networks must be sufficiently reli-
able to support features of multimedia applications and to pro-
vide a continuous service with few outages – one of the
requirements of smart cities. Reliability ensures continuity of
service for a specified period of time, and in general, is a period
that is enough to reach the conclusion of the service. Guarantee-
ing reliability is a critical aspect in attracting and maintaining
end users, as well as to achieve QoS. Services must be available
anywhere and anytime for end users, since people are expected
to be very dependent on the services as a result of the conve-
nience ensured by smart cities [20].
 Load balancing and scalability: It consists in a way to achieve
an efficient resource sharing over heterogeneous wireless net-
works. It can improve resource utilization, enlarge system
capacity, as well as provide better services for users [18]. Load
balancing depends on the network architecture and algorithms.
However, smart cities can provide hybrid network architec-
tures, which together with interoperability and complexity
include new algorithms and solutions for dealing with hetero-
geneous network requirements and features, such as scalability.
3. The proposed architecture
Most of the existing solutions for integrating different wireless
communication technologies and networks for smart cities depend
on expensive equipment, and only few of them seek to create
6 E. Avelar et al. / Computer Communications 58 (2015) 4–15
flexible and scalable architectures to address the interoperability
challenges described in Section 2. Among those existing solutions,
the only work that handles scalability with the support of a flexible
backbone employs a proprietary system, which makes it expensive
and difficult to modify. In addition, the original design of these
systems does not allow for improvements or an integration of
communication technologies and networks [12]. Hence, the pur-
pose of this work is to outline a heterogeneous, low cost and exten-
sible architecture with open source software, low cost wireless
routers and open/low cost sensors technology that takes into
account 3G/4G and Wi-Fi for providing end users in a smart city
with ubiquitous and diverse connectivity opportunities.
3.1. Overview
Fig. 1 illustrates the multilayer architecture proposed to provide
modularization, scalability and flexibility for the heterogeneous
wireless networks employed in smart cities. Four layers can be
observed, which moving from the bottom to the top are: sensing,
access network, Internet/cloud and application. The higher the
layer, the closer it is to the end users; whereas the lower the layer,
the closer it is to being able to handle raw data. The sensing layer is
responsible for monitoring the environment through heteroge-
neous wireless sensor motes and composing wireless sensor net-
works (WSN); it can also be embedded in the vehicles or
buildings of an urban environment. The access network layer,
which is also referred to as the backbone, supports communication
between different kinds of nodes and technologies; this layer is
often used for extending the range of the sensor network. The
Internet/cloud layer encompasses servers and the Internet, by
interfacing the applications and data communication of the end
users. The application layer comprises customers or applications
that address data collected by the sensing layer.
Next, one can find the main features of each layer.
 The sensing layer: consists of sensor motes able to perform
processing, gather information and communicate with each
other. These motes form networks with limited coverage range
Government/Companies
Service Provider
Data Server
(Sensor as a Service)
Data Storage
Mesh Gateway
Fig. 1. Architecture overview.
due to the employed technologies. This layer also serves to carry
the collected data through a local environment (i.e., approxi-
mately 10 m from sensor mote to sensor mote). Multiple sensors
can be used in this layer gathering different kind of data from the
environment, such as luminosity, noise, air pollution and temper-
ature, or from people, such as data about the electrical activity of
the heart (by electrocardiography – ECG), the electrical activity
produced by skeletal muscles (by electromyography – EMG)
and kin conductivity (by Galvanic Skin Response – GSR).
 The access network layer: from sensors to the Internet. It may
include routers that employ IEEE 802.11 technology (or other
types of wireless communication technology). The routers form
a wireless mesh network. This design decision provides self-
organization and self-configuration in the access network layer,
which is considered to be the backbone for the communication
among all the networks and technologies involved. The wireless
mesh backbone offers many benefits such as low upfront invest-
ment, reliability and scalability. This layer can also comprise
vehicular ad hoc networks (VANETs) and 2G/3G/4G networks,
which the later can act both for data propagation, coming from
VANETs and Mesh, and to network access for mobiles users.
Hence, the backbone is flexible enough to address both multihop
communication through 802.11 mesh/VANETs and wide or
metropolitan communication, receiving data directly from the
sensing layer. The backbone also aims at improving the energy
saving of motes, since gateways for different technologies,
belonging to the wireless backbone, can be spread around sensor
networks at the sensing layer. This can reduce the number of
required sensors and increase the sensing range.
 The Internet/Cloud layer: makes data available to users by the
Internet through servers, spread out in a particular area, or as a
service with cloud infrastructure. This layer is responsible for
processing and distributing all collected data and all data pro-
vided by the involved networks. This layer also comprises dat-
abases and web services, which manage data distribution and
their availability. Cloud technology in the context of smart cities
creates an environment in which sensor readings are handled as
service for end users.
,
Cloud Provider Users Sensor Data
(loT as a Service) Provider
Internet/Cloud
Roadside AP
Roadside AP
 E. Avelar et al. / Computer Communications 58 (2015) 4–15
 The application layer: comprises of customers or applications
that employ data collected by the sensing layer. These custom-
ers might be Web pages, smartphones enabled to receive data,
companies interested in sensing data for its specific business,
for example, services from the cloud with regard to private
information, social networks, other servers on the network or
any computer that has Internet connection.
Each layer of the architecture is only responsible for the func-
tions it performs by itself, and thus facilitates the understanding
and development of technological solutions. For example, the
applications for reading or providing data to users do not need to
know how these data were collected.
3.2. Architecture components
This section outlines the networking components of the
architecture, as well as the main software entities responsible for
managing, controlling and adapting communication between the
layers. These components can be specified as follows.
3.2.1. Low cost mesh backbone
In this proposal, we adopt a low cost solution based on a com-
modity and open hardware. Two routers have been applied to com-
pose the mesh backbone (Linksys WRT54GL and Soekris net5501).
Linksys WRT54GL is employed in the testbed deployed at Federal
University of Pernambuco. Those routers follow the IEEE 802.11g
standard in the unlicensed ISM (Industrial, Scientific and Medical)
2.4 GHz. Fig. 2 shows the physical placement of devices, being
the green icons representations of the WRT4GL routers, blue icons
representations of sensors, and the center icon representation of a
server.
This router was set up to execute in mesh mode through the
installation and configuration of an embedded linux distribution,
called OpenWRT [21]. Soekris net5501 employs a compact flash
module for data storage, which allows custom installations of
operating system. We took advantage of this feature and employed
the Debian Linux version 7 to run different kinds of routing proto-
cols. Each one of these routers leads to different solutions for the
implementation of the proposed architecture at a low cost.
Fig. 2. Sensing layer testbed scenario – The campus of the Federal University of
Pernambuco.
7
The basic unix tools of OpenWRT are supplied by BusyBox; the
other tools are available in separate modules. This is a simple and
low cost router available on the market. But with OpenWRT as
firmware, it can become very robust. The solution can be extended
to all routers compatible with OpenWRT and through this a wide
range of applications can be installed. In particular, the feature that
allows multi-hop routing is made possible through the installation
of a specific module that implements the OLSR (Optimized Link
State Routing) [22] routing protocol, originally designed for ad
hoc wireless networks. OLSR is a single path proactive protocol
that works in a distributed manner by being based on tables that
contain information about the network topology and estimations
about the quality of wireless links. The routing tables are changed
regularly, then they can support the decision-making process with
regard to the setting of routes.
The Debian Linux usage in Soekris net5501 enabled the installa-
tion of the Multipath Optimized Link State Routing (MP-OLSR).
MP-OLSR lies in a hybrid protocol, and combines the advantages
of both proactive and reactive routing [23,24]. This protocol
extends OLSR, by means of the discovery of multiple disjoint paths
that increase the reliability of packet delivery in ad hoc networks.
As OLSR, the MP-OLSR employs special nodes called Multipoint
Relays (MPRs) to flood the network with control information (pro-
active part). A MPR node can reach any node within the network
in two hops, even if the path requires them to use other MPRs.
Moreover, MP-OLSR conducts the detection of routes on demand
(the reactive part). The protocol is installed in Kernel version
3.2.0-29, which requires changes in the kernel’ s socket buffer
structure.
Soekris router also supports the addition of directional and
omnidirectional antennas. We apply two kinds of omnidirectional
antennas, an outdoor and indoor one. In the case of the outdoor
antenna, the aquario antennas are employed to work in 2.4 GHz
and 15 dBi. In the indoor, the aquario directional antennas are used
with 12 dBi and tuned in the same frequency. These antennas have
been installed around a huge area of the Polytechnic Center in
Federal University of Paraná, as illustrated in Fig. 3. The figure
shows the covered area by mesh routers. This mesh network
supports the integration of different networks, such as the sensor
networks, VANETs and others as well as those proposed in the
architecture displayed in Fig. 1.
3.2.2. Gateways
In general, current gateway solutions for smart cities consider
proprietary designs that might be a single gateway for the entire
network. However, this is not a scalable approach or could signifi-
cantly increase the cost of deploying a smart city, since there is a
need for a large number of such gateways to deal with the huge
amount of information. Within the scope of the Intelligent System
for Urban Traffic Monitoring (SIMTUR) project, we have developed
solutions relying on open hardware (Arduino, OpenWRT) and soft-
ware to connect the sensing layer to the backbone. In addition, two
kinds of gateways have been suggested to connect the sensing
equipment and access network layers of our proposal: Sunspot/
Mesh gateway and XBee/Mesh gateway.
The two gateways mentioned earlier are illustrated at the fron-
tier between the sensing and access network layers in Fig. 1.
Although two different gateways are shown, in fact a single gate-
way design can accomplish four different sensor technologies,
one for each Wi-Fi/Ethernet interface. Since the architecture adopts
a modular approach, it is easy to extend the architecture with other
sensors. The gateway, for instance, can be changed without any
modifications to the other layers.
The deployed gateways consist of an Arduino with an Ethernet
shield. Arduino is a development platform that provides an
open-source hardware solution and low-cost software for physical
8 E. Avelar et al. / Computer Communications 58 (2015) 4–15
Fig. 3. Mesh routers and their covered area in the campus of Federal University of
Paraná.
computation. Shields are boards that can be plugged on top of the
Arduino. The SunSPOT platform (Fig. 1) does not have an Ethernet
output to connect to the mesh router, but just has a serial interface.
In this case, it was also necessary to insert an Ethernet Shield in the
Arduino to mediate this communication. The Ethernet Shield is
used to provide the Arduino with the IEEE 802.3 (Ethernet) capa-
bility. This can be used for TCP/IP communication and if it has
proper software and configuration, can connect to a mesh network.
Thus, the Arduino works as a tunnel and only transfers the infor-
mation of the SunSPOT base station to the mesh router.
When the Ethernet communication is supported by the Arduino
libraries, it is possible to configure the TCP socket server for seam-
less communication between the sensor motes and the mesh back-
bone. The system installed on the Arduino receives the data from a
specific vendor interface (Xbee or SunSPOT) through serial com-
munication. Then, it establishes an Ethernet communication with
the mesh node and sends the information in JSON (JavaScript Object
Notation) format.
The XBee module is another shield which extends the Arduino
with a proprietary implementation of the ZigBee standard. We
have developed a XBee/Mesh gateway to allow the communication
between Xbee/Arduino and 802.11 mesh network. The platform
XBee/Arduino works as a ZigBee mote for the data collection and
transmission. The set, which is composed of Ethernet Shield, Ardu-
ino and XBee Shield, serves as the base station for communication
with the mesh network via the Ethernet interface. In the architec-
ture, the gateway has a software installed on the Arduino that
receives the data collected from the XBee network.
3.2.3. Software entities
Fig. 4 shows the following functional entities, software modules,
for each layer of the proposed architecture: service provider, data
server, access network softwares and smart node. For the sake of
clarity, Fig. 4 maps the functional modules to the corresponding
layers of the architecture depicted in Fig. 1. These modules can
either be placed at a particular device belonging to the correspond-
ing layer, or at a server, or else be distributed among the network
components of the architecture.
The service provider module is responsible for providing the
reading of sensor data as services for upper layer applications. Ser-
vices are provided through REST (Representational State Transfer),
a technology that is widely used to exchange information between
homogeneous or heterogeneous systems, and defines a set of archi-
tectural principles to design web services. REST is simple, easy of
use, besides being suitable for getting information from objects,
as well as turn them on and off. Thus, it has been widely deployed
in sensors and energy constraint devices.
While the function of the Data Server is only to handle data
received from sensors, the Service Provider has the goal of provid-
ing these data as a service to the application layer. The Service Pro-
vider was developed by means of Web Server and WebServices.
The web server was developed using PHP 5.3.5, Apache 2.2.17
and MySQL 5.5.8 over Ubuntu Server 12.04. The WebService was
developed using PHP and SOAP.
The data server module and storage of the Internet/Cloud
domain are, in fact, distributed entities and may be partially or
totally found in ISPs, virtualized datacenters and in the core net-
work of operators. Thus, Storage as a Service (SaaS) and agree-
ments among different data sources from distinct owners
(governments, private institutions, etc.) may be shared in a distrib-
uted, scalable, and secure way. The data server is the module that
has the function of processing and handling the gathered data from
the three layers of networks (sensing, access and global). It has
other important entities, such as the event controller, PBM (Policy
Based Management) and security module.
The event controller manages sensing requests made by the
service provider. This module also has an interface to the event
scheduler, which, in turn, is responsible for dealing with the event
prioritization and traffic differentiation. Thus, QoS provisioning can
be addressed depending on the application requirements. For
example, healthcare services and critical events, such as the trans-
mission of a car’s accident video, have higher priority than simply
humidity report.
A major issue of the Internet is the security, both in access con-
trol as to maintain data privacy. In attempting to solve this prob-
lem, the security module is responsible for both controlling the
user’s access, implementing AAA (Authentication, Authorization
and Accounting), and carrying out private data encryption. Thus,
private data are not accessible to unauthorized users and even if
a malicious user eavesdrops a private sensor reading, s/he would
not be able to read it.
Both the event controller and security module use policies
defined in PBM. This approach has been employed for managing
enterprise-wide networks and distributed systems. Such manage-
Fig. 4. Software architecture.
 E. Avelar et al. / Computer Communications 58 (2015) 4–15
ment could refer to the ability to observe and control the access to
a network using high-level abstracted rules and decisions. In PBM,
the Policy Enforcement Point (PEP) is the element that runs and
applies different policies. And the Policy Decision Point (PDP) is
responsible to interpret the policies stored in Policy Repository
(PR) and for the communication between PEP and PR.
In the proposed architecture, policies can be defined by manag-
ers and by network users, who respect the privilege levels defined
in security module. The PR can be pervaded by rules that will be
analyzed by the PDP. Policies related to load balancing (LB) should
govern the choice of, for example, the best gateway, network
access and routing from sensing layer to the end user in order to
distribute traffic in a most efficient way through the heterogeneous
network. QoS and QoE policies related to rules are created to differ-
entiate the traffic from tuning mechanisms, such as differentiate
services code point DSCP from IP packet.
Energy saving policies may be implemented to avoid the unnec-
essary usage of sensors and even optimize the usage of APs, BS and
wired switches. It worth mentioning that the four illustrated policy
groups may be combined and evaluated by the conflict-free mod-
ule, which is responsible for analyzing inconsistencies that may
arise from different policies being executed simultaneously. For
example, if ES and LB functionalities are executed over the same
object, one policy (ES) may request a node shutdown and another
(LB) that the traffic can pass through this node. Our conflict resolu-
tion module is responsible for avoiding inconsistencies in the exe-
cution of services.
At the access network level, the interoperability between the
heterogeneous networks is accomplished by the data server mid-
dleware and the MIH (Media Independent Handover Services)
[25]. IEEE 802.21 or MIH is a standard for the integration of IEEE
and non-IEEE networks such as 3GPP. MIH is composed of a set
of triggers, events and a database (MIIS – MIH Information Service)
that combines technologically-specific information to assist hand-
over (change of point of access), network identification and selec-
tion, positioning, etc., in a heterogeneous scenario. The Internet/
Cloud domain provides interfaces through the Data Server Middle-
ware, for example, to use the best network (e.g., the cheapest or the
best provisioned network), depending on the user profile.
The smart node is installed in sensor gateways, and is respon-
sible for collecting data on the sensing layer. It owns a type of mid-
dleware called sensor middleware, which provides a common
interface via embedded socket, communicating with the data ser-
ver middleware. The smart node also provides an interface-depen-
dent sensor to collect data from different sensors. For each sensor
is necessary to implement a specific interface.
4. Key results and implications
The proposed architecture is currently being implemented
within the Brazilian SIMTUR project. The key results yielded by
the different layers of the architecture are shown and these com-
prise, the application layer (Section 4.1), sensing layer (Section 4.2),
access network layer (Section 4.3) and security provisioning in
wireless mesh backbone (Section 4.5).
4.1. The application layer
Two platforms have been developed at the application layer, as
examples of applications that use the architecture. The first was a
web application that obtains data from web servers. Fig. 5 shows
the image of a logged user. On the left-hand side of the interface
shown in Fig. 5(a), it can be noted that the user has registered
several sensors: arduino01, arduino02 among others. Each sensor
has an identifier (ID) that is used for reading and identifying the
9
sensor. Readings are made by the user in the database and are
automatically updated in the web environment. For security rea-
sons, each user has an API-KEY that identifies and authenticates
this reading. The user inserts the API-KEY in the sensor reading
code. Before storing the data, the web server checks if the user
and API-KEY are registered in the database and the user has been
permitted to have access.
The user can retrieve the data by means of HTTP request from
the web interface, as illustrated in Fig. 5(a). S/He can also retrieve
by an Android application, as illustrated in Fig. 5(b). This applica-
tion makes the data request via webservice.
4.2. Sensing layer key results
This subsection outlines key results from the evaluation of the
802.11 mesh backbone integration with sensor networks compris-
ing of motes from two different companies. Following the scenario
illustrated in Fig. 6, we have configured the testbed around the
Center of Informatics of the Federal University of Pernambuco
(CIn-UFPE). This scenario includes the proposed sensor gateways
(SunSPOT/Mesh and Xbee/Mesh gateway), as outlined in Section 3.2.
In the experiments, the final users run the SIMTUR application
developed especially for the project. This application runs on
android and has communication interface via webservice with
the service provider. The plots in Fig. 7 are intended to give the real
readings (Fig. 7(a)–(c)) from sensors deployed by the testbed (light
intensity, sound intensity and temperature) for a 24 h period. The
aim of this is to demonstrate the effectiveness of end-to-end trans-
mission of our architecture (from sensing to application layer), as
well as the information that is available to the user via web
browsers and/or smartphones. In addition, it shows the difference
in terms of delay is negligible (Fig. 7)(d) when the two proposed
gateways (SunSPOT/Mesh and XBee/Mesh) are employed.
Fig. 7(a) shows the light intensity collected by the sensor motes.
Fig. 7(b) shows the noise pollution level in the evaluated interval.
Data were collected in a location at the campus of the University,
where there is a heavy traffic. The level of noise is due to the vehi-
cles moves along the avenue. Fig. 7(c) shows the variation in
temperature.
We observed the delay of the packets on the SunSPOT/Mesh and
XBee/Mesh gateway, as shown in Fig. 7(d), to check the time spent
on transmission in the embedded systems. The delay caused when
applying the SunSPOT/Mesh gateway is, on average, 20 ms,
whereas the delay with the XBee/Mesh gateway is about 15 ms.
This might be due to the fact that the SunSPOT does not have an
Ethernet communication interface, and thus, it is necessary to
insert an intermediate element for this operation.
4.3. Access network layer key results
This subsection examines the key results from the experimental
comparison carried out with regard to reliability in packet delivery.
As shown in Section 2, reliability is one of the requirements for
smart cities. Hence, a single path and a multipath routing are com-
pared at the access network layer, with the OLSR and MP-OLSR
protocols being used as reference-points to represent these
approaches. Experiments have been conducted at the Polytechnic
Center of the Federal University of Paraná, which involved employ-
ing the wireless mesh backbone, and a vehicular ad hoc network
composed of two notebooks and three cars with embedded vehicle
computers. Fig. 8 shows pictures of the experiments. Furthermore,
to conclude this subsection, a comparison of these two routing
approaches has been carried out by simulations in the presence
of the most damaging attack for wireless networks, the jamming
attack. This last comparison also intends to evaluate the impact
of security issues on the reliability of backbone.
10 E. Avelar et al. / Computer Communications 58 (2015) 4–15

Fig. 5. Web application.

low mobility. A possible explanation for this is the reduction of

Service
Service Provider
Provider the ETX metric of a path. This occurs because data traffic competes
with the control packets used to measure the quality of the links.
Another reason is related to the alignment of the nodes in a static
<<REST Communicaon>>
Autorized
scenario. Parallel aligned results with reduced interference trigger
Data
Data Server
Server t >>
Mobile User
the selection of a new best path. This scenario results in approxi-
cke
So
Security
TC
P mately 14 changes in the MPR in a five-minute interval.
<<
Light OLSR has obtained better results for jitter as depicted in
MIH Fig. 10(b). OLSR has achieved 141.69 ms in a static scenario and
(MIIS) Xbee/Mesh Xbee Mote
Temperature 60.36 ms in the mobile scenario. Using the same metric, MP-OLSR
Gateway
achieves 147.75 ms and 113.43 ms, respectively. One reason for
PBM
Storage
Light this result lies in the fact that OLSR only employs the best path,
while MP-OLSR computes the delay for the intermediate nodes.
<<TCP Socket>>

Mesh Node
SunSPOT/Mesh
Gateway
Mesh Gateway
Mesh Node
Fig. 6. Sensing layer testbed scenario.
Two scenarios have been employed: one with no mobility
(static scenario) and another with low mobility. Fig. 9(a) and (b)
illustrates the positioning of the nodes in each scenario, static
and low mobility, respectively. In the static one, the source node,
represented by S, is placed 70 m away from destination node, indi-
cated by D in the figure, while the intermediate nodes, a, b and c,
are positioned approximately 35 m from both. This alignment
results in uniform costs for paths. In the low mobility scenario,
the S and D nodes are static, and the vehicles a, b and c move in cir-
cle only in one direction with a speed of approximately 5 km/h
(18 m/s), which changes the costs of the routes through each node.
After the deployment of the nodes, the iperf tool [26] generates
UDP traffic under port number 104, from source node to destina-
tion node. Packet Loss Ratio (PLR), Forwarding Packets Ratio
(FPR) and jitter are employed as metrics to compare single path
and multipath routing.
Positive and negative factors can be observed in the results from
both protocols. The OLSR protocol shows a high PLR in both scenar-
ios and consists of 41.02% in the scenario without mobility and
30.39% in the scenario with slow mobility. MP-OLSR achieves bet-
ter results in the same conditions, (10.81% and 13.39%, respec-
tively). Contrary to our expectations, a single path approach
achieves a higher PLR in a static scenario than in a scenario with
Sound/Noise When investigating the behavior of single path and multipath
approaches, the Wireshark [27] tool is employed to analyze the
FPR on intermediate nodes for both approaches and for each sce-
Temperature nario. Fig. 10(c) shows the output recorded in a static scenario.
The diagram shows the FPR when the static scenario is considered.
OLSR represents the fact that the single path approach has for-
SunSPOT Mote Sound/Noise
warded most of the packets through the intermediate node a, in
total 82.71%. At the same time, MP-OLSR distributes the packets
in multiple paths under a, b and c nodes, and forwards 18.4%,
43.77% and 37.81% of packets for each node, respectively.
MP-OLSR employed three paths simultaneously in both scenar-
ios, Fig. 10(a), (c) and (d), generated a lower PLR. In a slow mobility
scenario, the choice of a single path route was easier on account of
the node mobility and resulted in few MPR variations. When
Fig. 10(d) is observed, it can be seen that intermediate nodes a
and b have forwarded 36.2% and 54.37% of their packets, respec-
tively. This fact has led to better results being obtained for jitter
with a single path routing approach, and represents an improve-
ment from the perspective of jitter. However, when a PLR metric
comparison was made, the multipath routing approach achieved
better results. These results suggest that a multipath routing
approach is more attractive to ensure the delivery of packets in
ad hoc networks like VANETs.
4.4. Reliability analysis under security issues
This section examines the impact of jamming attacks on access
network layer. This investigation evaluates the two previously
mentioned routing protocols in VANETs that were subject to jam-
ming attacks by conducting simulations. Jamming attacks occur in
link layer and physical layer, and keep the media access constantly
busy. As result, there is a poor performance for routing and this
 E. Avelar et al. / Computer Communications 58 (2015) 4–15 11

hampers the exchange of packets between pairs of vehicles in

VANETs.
Two simulation scenarios have been designed, each one with
different mobility models. The first one comprises the Random
Waypoint (RWP) mobility model and the second one the Manhat-
tan Grid model. Mobility in RWP is carried out in a random way
with no restrictions. In the Manhattan Grid model, the nodes are
forced to move in a grid that simulates the streets of a city, and
the movements in the simulations are realistic. In the simulations,
the maximum speed used in RWP was 15 m/s, the same average
speed as that employed in Manhattan Grid.
In each scenario, packet delivery rate (PDR), throughput and
delay metrics have been employed to evaluate the jamming attack
impact. Packet delivery rate is defined as the ratio of successfully
received packets number and total received packets number.
Throughput is obtained by the average rate of successful message
delivery of CBR traffics. These metrics have been used to investi-
gate the gradual increase of jammers, considering 0%, 2%, 6% and
10% of jammer nodes in the network.
Both scenarios have been implemented in the Network Simula-
tor (NS2), version 2.34, using common parameters. The IEEE
802.11p standard is employed. Another similarity between the sce-
narios is the number of nodes and simulation areas: 50 nodes are
distributed in an area of 1500 m  1500 m under 100 s of simula-
tion. 35 variations of the mobility models have been generated
for each protocol to calculate the confidence interval. The simula-
tions were repeated 35 times, one for each mobility variation gen-
erated. Figs. 11–13 show the results of the simulations that
followed the RWP mobility model.
Figs. 11 and 12 show similar results for throughput and packet
delivery rate, the only significant difference in performance is
when there are 2% of jammers nodes. In this case, OLSR is superior
to the other. However, with the addition of jammers, the protocols
tend to present the same performance. Fig. 13 show AODV delay
has the worst performance without jammers. Although, AODV
became the most efficient routing protocol in face of jamming
attacks.
Figs. 14–16 display the simulation results of the Manhattan
Grid mobility model. They show that there were small differences
between the results from the Manhattan Grid scenario and the
RWP scenario. The results of the packet delivery rate and through-
put results are similar to those of the RWP scenario. In both scenar-
ios, all the evaluated protocols have a comparable performance in
the presence of no ‘attacks’. With the introduction of one jammer
node, representing 2% of all the nodes, the OLSR routing protocol
has a slightly better performance than AODV and MP-OLSR, but
when there is an increase of jammers, the three protocols affected
Fig. 7. Testbed measurements.
the performance in a similar manner.
Nonetheless, this study has revealed the inefficiency of
MP-OLSR in providing security requirement in face of a jamming

Fig. 8. Pictures from the experiments.

12 E. Avelar et al. / Computer Communications 58 (2015) 4–15

attack, which makes it impossible to adopt it in the architecture.

Moreover, these results highlight the need to develop routing pro-
tocols that are able to survive this kind of attack. Security proposals
are handled by the security module displayed in the proposed
architecture.
This result shows the existence of a small number of perceptual
jammers in the network which can result in serious damage. The
three metrics in both scenarios show an absence of jammers which
means there is a one hundred percent network operability. If there
are just two percent of jammers, on average, fifty percent of the
network operability can become compromised. Similarly, six per-
cent of jammers in the network cause eighty percent damage. In
addition, ninety percent of operability is compromised with ten
percent of jammers. These outcomes highlight the damage caused
by jammers to networks, and suggest there is an urgent need for
further investigations into this kind of attack.

4.5. Security provisioning in wireless mesh backbone

In the architecture, all the equipment uses the WPA2 (Wi-Fi

Protected Access version2) standard. The network employs a
RADIUS (Remote Authentication Dial-In User Service) server to
access control. In this case, the RADIUS Server is used together with
WiFiDog and LDAP to provide authentication for the wireless mesh
users.
WiFiDog is a technology that redirects HTTP clients to a speci-
fied authentication web page. It can be divided into two parts:
Fig. 9. Testbed – Scenarios. the authentication server and gateway. The former was imple-
mented with PHP language and PostgreSQL, and is responsible
for checking information about clients such as their name and

100
OLSR 200 OLSR
MP−OLSR MP−OLSR

80
150 147.75
141.69
Jitter (ms)

60
PLR (%)

113.42
100
41.02
40
30.39
60.36
50
20
13.69
10.81

0 0
Static Mobile Static Mobile
(a) PLR Comparison (b) Jitter Comparison

100 100
Node a Node a
Node b Node b
Node c Node c
82.71
80 80

60 60
FPR (%)

FPR (%)

54.37

43.77
40 37.81 40 36.2 36.60
33.37
30.02

20 18.4 20
13.21
9.42
4.06
0 0
OLSR MP−OLSR OLSR MP−OLSR

(c) FPR Comparison in Static Scenario (d) FPR Comparison in Slow Mobility Scenario
Fig. 10. Testbed – Measurement results.
 E. Avelar et al. / Computer Communications 58 (2015) 4–15 13

100 100
AODV AODV
MP−OLSR MP−OLSR
OLSR OLSR

80 80

Packet Delivery Rate (%)

Packet Delivery Rate (%)

60 60

40 40

20 20

0 0
0 2 6 10 0 2 6 10
Percentage of Jammers (%) Percentage of Jammers (%)

Fig. 11. PDR under jamming attacks – RWP model. Fig. 14. PDR under jamming attacks – Manhattan

400 AODV
400 AODV
MP−OLSR MP−OLSR
OLSR OLSR
350 350

300 300

Throughput (kbps)
Throughput (kbps)

250 250

200 200

150 150

100 100

50 50

0 0
0 2 6 10 0 2 6 10
Percentage of Jammers (%) Percentage of Jammers (%)

Fig. 12. Throughput under jamming attacks – RWP model. Fig. 15. Throughput under jamming attacks – Manhattan.

25000 25000
AODV AODV
MP−OLSR MP−OLSR
OLSR OLSR
20000 20000
Delay (ms)

Delay (ms)

15000 15000

10000 10000

5000 5000

0 0
0 2 6 10 0 2 6 10
Percentage of Jammers (%) Percentage of Jammers (%)
Fig. 13. Delay under jamming attacks – RWP model. Fig. 16. Delay under jamming attacks – Manhattan.

password. The clients’ requests are intercepted by a firewall and
redirected to the authentication server. The second part of WiFi-
Dog, the gateway, has been developed in C language and is embed-
ded in hotspots, such as OpenWRT routers. After authentication,
the gateway redirects the traffic to the target page. The routers
connect the authentication server by means of the information
provided by the mobile users.
A RADIUS server provides a centralized authentication service
that can connect to any system which maintains user information,
such as the following: database, directory structure, digital certifi-
cates, among others. The deployment of a RADIUS server has two
key advantages: the use of authentication, authorization and
accounting and the support of a wide range of protocols for
authentication like LDAP. A LDAP directory generally follows the
14 E. Avelar et al. / Computer Communications 58 (2015) 4–15
X.500 model, which is a tree of nodes, each consisting of a set of
attributes with their corresponding values. An advantage of LDAP
in a structure of a relational database is the performance, since
any search in a balanced tree structure will have a N lnðNÞ com-
plexity. In addition, the LDAP structure creates access to policies
for users and groups, in a simplified manner. The WiFiDog is also
configured to support TLS/SSL and ensures that it will only answer
requests on port 443, which is the default for HTTPS.
5. Open questions
Despite the proposed architecture encompasses a wide range of
features related to the challenges highlighted in Section 2, there
are still open questions that have to be addressed to pave the
way for further development. This means that algorithms, mecha-
nisms and protocols must be designed to provide low cost interop-
erability, as well as resource optimization in heterogeneous
wireless networks for smart cities. The main open questions are
as follows.
Energy-aware algorithms: research into energy-aware routing
and gateway discovery for sensor and mesh networks has been car-
ried out for several years, but this new heterogeneous prospect
(which involves mobile sensors in VANETs and heterogeneous
fixed sensors, as well as the IEEE 802.11 mesh network), requires
innovative solutions. Sensors in VANETs do not suffer from energy
restrictions, but can be highly dynamic in terms of their current
location due to the mobility of the vehicles. The novel algorithms
could benefit if a choice is made about a part of the data path that
goes through VANETs or 802.11 Mesh and thus help to save the
battery for fixed sensors. Furthermore, efficiently discover gate-
ways is an important research topic since gateways offer the sen-
sor connectivity to the Internet, making a bridge between
distinct wireless access networks (e.g., 3G, 4G, and IEEE 802.11)
as well as between fixed ones (e.g., metro Ethernet). As a result,
the gateway discovery should be rethinking considering a com-
plete view from the end-to-end routing, taking into account, for
example, the distribution of servers forming cloud computing ser-
vices for the smart city. The reason for this is that the number of
flows will increase significantly when more people are involved
and when, in the near future there is a huge number of sensors
spread out across the cities. Thus, poorly designed routing and dis-
covering algorithms may lead to a waste of resources in both
access and backbone networks.
Interference, spectrum efficiency, and optimization in
higher layer protocols: Interference in communications in an
environment with different radio technologies operating with the
same frequency, such as IEEE 802.11 (Wi-Fi) and IEEE 802.15.4
(ZigBee), are well-known research topics and becoming more com-
plex with the increasing number of devices composing the net-
works of smart cities. It is of paramount importance, not only at
the level of the radio, but also at all layers of the protocol stack,
to address the question of the efficient usage of the spectrum
and to be able to align or innovate high level mechanisms such
as congestion control. Thus, mechanisms to integrate cognitive
radio networks with others using different technologies should
be deployed for heterogeneous smart city scenarios. These should
take account of sensing and spectrum mobility to prevent unli-
censed communication from harming primary user communica-
tion. VANETs aggravate this problem since spectrum sensing
becomes even harder for networks due to mobility.
Residents and sensor mobility: In both upper (application) and
lower (sensing) layers of any smart city architecture, mobility may
have a serious impact on seamless connectivity. Selecting the best
connectivity from the technologies in the access network layer is
an important question to be solved from the user’s perspective.
Some people may prefer to obtain data and video on traffic conges-
tion, even without priority, but at a lower financial cost. Fixed sen-
sors served by an access network layer based on VANETs would
suffer from intermittent interconnection. Techniques such as those
used by DTN (Delay Tolerant Networks) would help improve
mechanisms for providing connectivity for sensors in these scenar-
ios. Furthermore, since video applications (e.g., video monitoring)
are bandwidth intensive and power hungry, network selection
based on the lifetime of the battery of a device should be consid-
ered to avoid causing annoyance to the user. MIH could be
employed as a solution, but more investigation is required to
ensure the ABC (Always Best Connection) for heterogeneous
ecosystems [25].
6. Conclusion
Smart cities have become a reality, and heterogeneous wireless
networks support them. Owing to scientific and industrial
advances, there are different wireless communication technologies
and it is expected that there will be interoperability between them
to allow smart cities to offer all the benefits envisaged for society.
However, identifying interoperability issues is a challenge. Besides,
it would be valuable adopting non proprietary solutions to privi-
lege the evolution and the deployment of heterogeneous wireless
networks in smart cities. Hence, this article has pointed out the
interoperability issues that are raised by these networks and out-
lined an architecture that can bring about the low cost integration
of different wireless communication technologies and networks in
smart cities. The architecture resulted from a Brazilian government
initiative to encourage the development of smart cities for citizens.
It encompasses a wide range of wireless communication technolo-
gies, and is structured in layers. Furthermore, as part of the
proposed architecture, a low cost mesh network based on
commodity IEEE 802.11/Wi-Fi routers has been designed and eval-
uated which employs low-cost gateway solutions to connect sen-
sor motes to the Internet. This article has examined a set of key
results from simulations and experiments, based on the revisited
requirements of smart cities.
Acknowledgements
The authors would like to thank the anonymous reviewers for
their valuable comments and suggestions to improve the quality
of the paper. They are also grateful to the Center of Information
and Communication Technologies from the Brazilian Government
and RNP.
References
[1] C. Harrison, I. Donnelly, A theory of smart cities, in: Proceedings of the 55th
Annual Meeting of the ISSS, 2011.
[2] S. Hodgkinson, Is Your City Smart Enough? Tech. Rep. OI00130-007, OVUM,
London, UK, 2011.
[3] F. Gil-Castineira, E. Costa-Montenegro, F. Gonzalez-Castano, C. Lopez-Bravo, T.
Ojala, R. Bose, Experiences inside the ubiquitous Oulu smart city, Computer 44
(6) (2011) 48–55.
[4] C.B. Williams, G.J.J. Gulati, D.J. Yates, Predictors of on-line services and
e-participation: a cross-national comparison, in: International Conference on
Digital Government Research, ACM, New York, NY, USA, 2013, pp. 190–197.
[5] A.K. Debnath, H.C. Chin, M.M. Haque, B. Yuen, A methodological framework for
benchmarking smart transport cities, Cities 37 (2014) 47–56.
[6] J. Sanchez, R. Caire, N. Hadjsaid, ICT and power distribution modeling using
complex networks, in: PowerTech (POWERTECH), 2013 IEEE Grenoble, 2013,
pp. 1–6.
[7] N.G. Leigh, N.Z. Hoelzel, Smart growth’s blind side, J. Am. Plann. Assoc. 78 (1)
(2012) 87–103.
[8] F. Viani, F. Robol, A. Polo, P. Rocca, G. Oliveri, A. Massa, Wireless architectures
for heterogeneous sensing in smart home applications: concepts and real
implementation, Proc. IEEE 101 (11) (2013) 2381–2396.
[9] D. Matt, D. Spath, S. Braun, S. Schlund, D. Krause, Morgenstadt – urban
production in the city of the future, in: M.F. Zaeh (Ed.), Enabling
 E. Avelar et al. / Computer Communications 58 (2015) 4–15
Manufacturing Competitiveness and Economic Sustainability, Springer
International Publishing, pp. 13–16.
[10] L. Sanchez, J. Galache, V. Gutierrez, J. Hernandez, J. Bernat, A. Gluhak, T. Garcia,
Smartsantander: The meeting point between future internet research and
experimentation and the smart cities, in: Future Network & Mobile Summit
(FutureNetw), 2011, pp. 1–8.
[11] L. Filipponi, A. Vitaletti, G. Landi, V. Memeo, G. Laura, P. Pucci, Smart city: An
event driven architecture for monitoring public spaces with heterogeneous
sensors, in: Proceedings of the 4th International Conference on Sensor
Technologies and Applications (SENSORCOMM), IEEE, 2010, pp. 281–286.
[12] J. Bers, A. Gosain, I. Rose, M. Welsh, CitySense: The design and performance of
an urban wireless sensor network testbed, in: Proceedings of the IEEE
International Conference on Technologies for Homeland Security, Waltham,
MA, 2008, pp. 583–588.
[13] U. Berkeley, WSN Testbeds at UC Berkeley, 2014. <https://www.millennium.
berkeley.edu/sensornets>.
[14] T-City, Friedrichshafen Smart City, 2014. <http://www.gsma.com/
connectedliving/wp-content/uploads/2012/11/cltcityweb1012.pdf>.
[15] A. Damnjanovic, J. Montojo, J. Cho, H. Ji, J. Yang, P. Zong, UE’s role in LTE
advanced heterogeneous networks, IEEE Commun. Mag. 50 (2) (2012)
164–176.
[16] J. Cao, C. Zhang, Heterogeneous wireless networks, in: Seamless and Secure
Communications over Heterogeneous Wireless Networks, SpringerBriefs in
Computer Science, Springer, New York, 2014, pp. 9–26.
[17] S. Lashgari, A.S. Avestimehr, Timely Throughput of Heterogeneous Wireless
Networks: Fundamental Limits and Algorithms, CoRR abs/1201.5173.
15
[18] M.G.R. Alam, C. Biswas, N. Nower, M.S.A. Khan, A Reliable Semi-Distributed
Load Balancing Architecture of Heterogeneous Wireless Networks, CoRR abs/
1202.1918.
[19] J. Torres, M. Nogueira, G. Pujolle, A survey on identity management for the
future network, IEEE Commun. Surv. Tutorials 15 (2) (2013) 787–802.
[20] M.N. Lima, A.L. dos Santos, G. Pujolle, A survey of survivability in mobile ad hoc
networks, IEEE Commun. Surv. Tutorials 11 (1) (2009) 66–77.
[21] OpenWRT Project, Openwrt Wireless Freedom. <http://www.openwrt.org/>
(accessed February, 2014).
[22] T. Clausen, P. Jacquet, C. Adjih, A. Laouiti, P. Minet, P. Muhlethaler, A. Qayyum,
L. Viennot, et al., Optimized Link State Routing Protocol (OLSR).
[23] J. Yi, A. Adnane, S. David, B. Parrein, Multipath optimized link state routing for
mobile ad hoc networks, Ad Hoc Netw. 9 (1) (2011) 28–47, http://dx.doi.org/
10.1016/j.adhoc.2010.04.007.
[24] D. Radu, J. Yi, B. Parrein, QoE enhancement for H.264/SVC video transmission
in MANET using MP-OLSR protocol, in: International Symposium on signal,
Image, Video and Communications, Valenciennes, France, 2012, pp. 1–4.
[25] A. Pontes, D. dos Passos Silva, J. Jailton, O. Rodrigues, K.L. Dias, Handover
management in integrated WLAN and mobile WiMAX networks, Wireless
Commun. IEEE 15 (5) (2008) 86–95.
[26] Iperf, Distributed Applications Support Team. <http://iperf.sourceforge.net>
(accessed February, 2014).
[27] Wireshark, Open-Source Packet Analyzer. <http://www.wireshark.org>
(accessed February, 2014).