Interoperability issues on heterogeneous wireless ... - Semantic Scholar

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 b

Federal University of Pernambuco (UFPE), Brazil Federal University of Paraná (UFPR), Brazil

a r t i c l e

i n f o

Article history: Available online 11 July 2014 Keywords: Smart cities Heterogeneous wireless communication Architecture Low cost Interoperability

a b s t r a c t Smart cities have become a reality around the world. They rely on wireless communication technologies, 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 interoperability questions in heterogeneous wireless networks for smart cities, and outlines a simple, modular architecture to deal with these complex issues. The architecture is composed by sensing, access network, Internet/cloud and application layers. Different features provided by the architecture, such as interoperability among technologies, low cost, reliability and security, have been evaluated through 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 performance 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 authentication 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 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 sustainable urban planning are required as a result of the huge migration 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 environments where they could live [2]. These challenges have led governments 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: [email protected] (M. Nogueira). http://dx.doi.org/10.1016/j.comcom.2014.07.005 0140-3664/Ó 2014 Elsevier B.V. All rights reserved.

Governments around the world, including the Japanese, 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]. Wireless 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 communication 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 solutions making expensive and complex the integration of devices, services and technologies. Big companies have promoted and sponsored the development of smart cities [7]. Hence, they encourage people to use their products, as software and hardware, that often

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

cannot interoperate with devices created by other companies. Analogously, 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 projects have emerged, such as SmartSantander [10], SOFIA [11], CitySense [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 theoretically revisits the challenges of applying heterogeneous wireless networks on smart cities, raising questions related to the interoperability 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 challenges 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 healthcare, producing diverse benefits. They allow real-time data diffusion 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 information, improving quality of life. These technologies offer new services, 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 parameters and characteristics need to be considered. The direct

5

application of optimization techniques to find the optimal setting for the network is a demanding task due to the dynamism of these networks and the existence of delay-sensitive applications, 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. Differently from other networks, heterogeneous ones need to deal with interferences caused by the diverse wireless communication technologies. Hence it is required new models and mechanisms 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 characteristics 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 considering 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 identities, 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 reliable to support features of multimedia applications and to provide 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. Guaranteeing 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 convenience ensured by smart cities [20]. Load balancing and scalability: It consists in a way to achieve an efficient resource sharing over heterogeneous wireless networks. 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 architectures, which together with interoperability and complexity include new algorithms and solutions for dealing with heterogeneous 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


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 purpose of this work is to outline a heterogeneous, low cost and extensible 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 heterogeneous wireless sensor motes and composing wireless sensor networks (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

Service Provider

due to the employed technologies. This layer also serves to carry the collected data through a local environment (i.e., approximately 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 temperature, 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 selforganization 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 investment, 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 provided by the involved networks. This layer also comprises databases 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.

Government/Companies

Data Server (Sensor as a Service) Data Storage

Cloud Provider (loT as a Service)

, Users Sensor Data Provider

Internet/Cloud

Roadside AP Mesh Gateway

Roadside AP

Fig. 1. Architecture overview.


The application layer: comprises of customers or applications that employ data collected by the sensing layer. These customers 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 functions 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 commodity and open hardware. Two routers have been applied to compose 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 protocols. 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 installation 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 (proactive 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 significantly 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 software 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 frontier between the sensing and access network layers in Fig. 1. Although two different gateways are shown, in fact a single gateway 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


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) capability. 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 information 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 seamless communication between the sensor motes and the mesh backbone. The system installed on the Arduino receives the data from a specific vendor interface (Xbee or SunSPOT) through serial communication. 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, Arduino and XBee Shield, serves as the base station for communication with the mesh network via the Ethernet interface. In the architecture, 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 corresponding 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. Services 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 architectural 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 providing these data as a service to the application layer. The Service Provider 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 network of operators. Thus, Storage as a Service (SaaS) and agreements among different data sources from distinct owners (governments, private institutions, etc.) may be shared in a distributed, 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 transmission 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 control as to maintain data privacy. In attempting to solve this problem, 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.


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 managers 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 differentiate the traffic from tuning mechanisms, such as differentiate services code point DSCP from IP packet. Energy saving policies may be implemented to avoid the unnecessary 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 module, 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 resolution module is responsible for avoiding inconsistencies in the execution of services. At the access network level, the interoperability between the heterogeneous networks is accomplished by the data server middleware 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 handover (change of point of access), network identification and selection, positioning, etc., in a heterogeneous scenario. The Internet/ Cloud domain provides interfaces through the Data Server Middleware, 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 responsible for collecting data on the sensing layer. It owns a type of middleware called sensor middleware, which provides a common interface via embedded socket, communicating with the data server middleware. The smart node also provides an interface-dependent 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 comprise, 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 reasons, 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 application 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 comprising 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 transmission 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 vehicles 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 compared 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 employing 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


Fig. 5. Web application.

Service Service Provider Provider

Data Data Server Server Security

P

TC

Light

MIH (MIIS)

Xbee/Mesh Gateway

Xbee Mote

PBM

Light

Storage

Temperature

Mesh Node SunSPOT/Mesh Gateway

Sound/Noise

Temperature Mesh Gateway Mesh Node

SunSPOT Mote Sound/Noise

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, indicated 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 circle 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 destination 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 scenarios and consists of 41.02% in the scenario without mobility and 30.39% in the scenario with slow mobility. MP-OLSR achieves better results in the same conditions, (10.81% and 13.39%, respectively). Contrary to our expectations, a single path approach achieves a higher PLR in a static scenario than in a scenario with

low mobility. A possible explanation for this is the reduction of 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 scenario. Parallel aligned results with reduced interference trigger the selection of a new best path. This scenario results in approximately 14 changes in the MPR in a five-minute interval. OLSR has obtained better results for jitter as depicted in Fig. 10(b). OLSR has achieved 141.69 ms in a static scenario and 60.36 ms in the mobile scenario. Using the same metric, MP-OLSR achieves 147.75 ms and 113.43 ms, respectively. One reason for this result lies in the fact that OLSR only employs the best path, while MP-OLSR computes the delay for the intermediate nodes. 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 scenario. 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 forwarded 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 scenarios, 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, respectively. This fact has led to better results being obtained for jitter with a single path routing approach, and represents an improvement 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 jamming 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


Fig. 7. Testbed measurements.

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 Manhattan 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 investigate 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 Simulator (NS2), version 2.34, using common parameters. The IEEE 802.11p standard is employed. Another similarity between the scenarios is the number of nodes and simulation areas: 50 nodes are distributed in an area of 1500 m 1500 m under 100 s of simulation. 35 variations of the mobility models have been generated for each protocol to calculate the confidence interval. The simulations were repeated 35 times, one for each mobility variation generated. 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 throughput results are similar to those of the RWP scenario. In both scenarios, 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 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


attack, which makes it impossible to adopt it in the architecture. Moreover, these results highlight the need to develop routing protocols 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 percent 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 specified authentication web page. It can be divided into two parts: the authentication server and gateway. The former was implemented with PHP language and PostgreSQL, and is responsible for checking information about clients such as their name and

Fig. 9. Testbed – Scenarios.

100

OLSR MP−OLSR

OLSR MP−OLSR

200

80

Jitter (ms)

PLR (%)

150 60

40

41.02

147.75

141.69

113.42

100

30.39

60.36

50

20

13.69

10.81

0

0 Static

Static

Mobile

(a) PLR Comparison 100

80

80

60

60

43.77

40

37.81

FPR (%)

FPR (%)

100

Node a Node b Node c

82.71

Mobile

(b) Jitter Comparison Node a Node b Node c

54.37

40

36.60

36.2 30.02

20

33.37

20

18.4 13.21

9.42 4.06

0

0 OLSR

MP−OLSR

(c) FPR Comparison in Static Scenario

OLSR

MP−OLSR

(d) FPR Comparison in Slow Mobility Scenario

Fig. 10. Testbed – Measurement results.

13


100

80

60

40

20

0

AODV MP−OLSR OLSR

AODV MP−OLSR OLSR

Packet Delivery Rate (%)

Packet Delivery Rate (%)

100

80

60

40

20

0 0

2

6

10

0

2

6

Fig. 14. PDR under jamming attacks – Manhattan

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

400

300 250 200 150

300 250 200 150

100

100

50

50

0

0 0

2

6

AODV MP−OLSR OLSR

350

Throughput (kbps)

Throughput (kbps)

400

AODV MP−OLSR OLSR

350

10

0

2

6

10

Percentage of Jammers (%)


Fig. 15. Throughput under jamming attacks – Manhattan.

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

25000

25000

AODV MP−OLSR OLSR

20000

AODV MP−OLSR OLSR

20000

Delay (ms)

Delay (ms)

10



15000

10000

5000

15000

10000

5000

0

0 0

2

6

10


0

2

6

10


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 WiFiDog, the gateway, has been developed in C language and is embedded 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 certificates, 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


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Þ complexity. 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, mechanisms and protocols must be designed to provide low cost interoperability, 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 carried 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 gateways is an important research topic since gateways offer the sensor 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 complete view from the end-to-end routing, taking into account, for example, the distribution of servers forming cloud computing services 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 discovering 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 complex with the increasing number of devices composing the networks 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 unlicensed communication from harming primary user communication. 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 congestion, even without priority, but at a lower financial cost. Fixed sensors 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 scenarios. 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 considered 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 privilege 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 outlined 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 technologies, 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 evaluated which employs low-cost gateway solutions to connect sensor 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


[10]

[11]

[12]

[13] [14] [15]

[16]

[17]

Manufacturing Competitiveness and Economic Sustainability, Springer International Publishing, pp. 13–16. 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. 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. 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. U. Berkeley, WSN Testbeds at UC Berkeley, 2014. . T-City, Friedrichshafen Smart City, 2014. . 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. 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. 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. (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. (accessed February, 2014). [27] Wireshark, Open-Source Packet Analyzer. (accessed February, 2014).