Smart sensing systems and dynamic wireless network infrastructures make future smart cities possible—from enabling applications such as environment monitoring, to a smart grid, and to smart mobility. In addition, they improve survivability in emergency situations. Technology-wise such applications demand robust and fault-tolerant wireless communication and widespread sensing capabilities, that is, a tremendous amount of data. Yet, even today, operators of infrastructure are struggling to keep up with the increasing data demand, as evidenced by a massive push toward newer technologies and more bandwidth for moving data.

We see a way out in the use of cars as a main ICT resource of smart cities. We believe that, by acting in two capacities, cars will play a major role in smart cities of tomorrow [2]: First, while driving they can provide access to the services of a powerful vehicular network – in essence acting as mobile base stations. They can be accessed by people in their homes or waiting at the curb, by devices in smart buildings, or by sensors deployed throughout the smart city. Second, cars themselves form a network with incredible processing and storage capacities, as well as sensing capabilities beyond any possible roadside deployment. Thus, cars can not only offer access to services but also offer services of their own. Further, by also including parked cars, both storage and processing capabilities can (to some degree) be made persistent in time and space.

Such a network formed by cars is different than typical Internet-based solutions that are readily available only in a certain geographic context and during a certain time interval. On the contrary, cars are ubiquitous. This holds even in critical emergency situations such as after disasters such as hurricanes or tsunamis [3]. Either way, these networked cars will play a big role in future cities by enabling a multitude of services in an architecture that we term Car4ICT.

Some first activities toward turning vehicles into a larger-scale networked system are already taking place [4]. Such architectures, however, commonly require high market penetration rates of the system, which is a problem in early market introduction—and even more so after disasters. Further, current approaches often focus on only a single application. Our architecture, in contrast, is able to support a huge variety of new applications both independent of and in conjunction with infrastructure.

Fig. 7.2 outlines our concept. Cars are collecting data from smart sensors along the road or they connect to smart buildings. They also provide services such as storage, processing power, or access to their sensors. They relay, distribute, and store data and connect people to this data or to the Internet. As a consequence of this design, our architecture is extensible and flexible. It can be used as a base for many applications such as distributed processing, monitoring, and sensing.

As Fig. 7.3 outlines, the same system can just as well be envisioned to provide communication support in case of a disaster. Many large cities are built in areas where disasters (eg, earthquakes, hurricanes) can cause widespread damage—also to infrastructure, particularly to installed communication infrastructure. If such an event occurs, our architecture can help emergency services by providing communication. Fig. 7.3 shows an early concept how Car4ICT can support the rescue staff in case of a disaster. Inside the disaster area people can connect to cars via ad hoc Wi-Fi (or other communication means which need no infrastructure) and send messages to nearby cars. Any such car can then take messages to an evacuation site where other vehicles might be waiting. If no other cars are in range during the drive to the site, cars transport the messages in a store-carry-forward manner. If other cars are in range, messages can be sent to them via short-range communication [eg, Dedicated Short-Range Communication (DSRC)] in a multihop fashion. Finally, there might be a car that is close enough to a working cellular base station and sends the data to the Internet, delivering the messages to people outside the disaster zone. Such a scenario works with Car4ICT because the whole concept is envisioned to be able to work without any external infrastructure – although it might make use of infrastructure if and where available.

In the following, we describe the envisioned Car4ICT architecture and sample use cases. In particular, we motivate the use of cars as a main ICT resource in smart cities – in a network architecture going beyond current information-centric networking (ICN) systems (based on Ref. [5]). We present a technique for the simulative performance evaluation of such a complex system (based on Ref. [6]) and conclude with a presentation of basic performance results that outline the capabilities of our architecture.

In much of this work the focus was on improving traffic safety, driving efficiency, and entertainment solutions based on data exchanged between cars. Early work on data exchange via ad hoc routing in vehicular networks demonstrated that routing works only in very local contexts; thus, clustering solutions have been investigated as an enabling technology [7]. Today, many network protocols and architectures are, in essence, broadcast protocols that have been augmented to be adaptive to network conditions – first and foremost to make them congestion aware. One example is Decentralized Congestion Control (DCC) [8]. The bases of these protocols are different communication technologies, of which a multitude have been investigated in the past years. Early solutions were based on the exclusive use of cellular networks such as Universal Mobile Telecommunications System (UMTS) or Long-Term Evolution (LTE); later research moved to using Wi-Fi access points as Roadside Units (RSUs) (ie, hotspots along the streets). More recently, a dedicated short-range radio solution based on Wireless Local Area Network (WLAN) technology was developed and standardized for vehicular networks as IEEE 802.11p. Standardization of Inter-Vehicle Communication (IVC) protocols is focusing on this in particular. In the United States, one of the driving forces is the DOT, which plans rulemaking to make IEEE 802.11p-based DSRC systems mandatory for new cars [9]; consequently, a standard called IEEE WAVE is developed. In Europe, ETSI ITS-G5 is planned to be rolled out as soon as cars are equipped with IEEE 802.11p radios. Japanese automakers have recently announced 760-MHz–based vehicle-to-vehicle and vehicle-to-roadside devices as part of an optional package offered in some 2015 model cars in Japan. In parallel to IEEE 802.11p, many other communication technologies are researched that are viable candidates for IVC in future smart cities. This includes visible light communication [10], Bluetooth [11], and millimeter-wave communications superimposed on radar signals [12]. While, traditionally, all these technologies were seen as alternative ways of transporting data, most recently, we observe a trend toward heterogeneous vehicular networking, the use of multiple communication technologies in parallel – each bringing individual strengths and compensating others’ weaknesses [13]. Along with many new challenges, this heterogeneous vehicular networking also offers great opportunities. It allows us to design applications and networks in a situation-aware and intelligent way.

Investigating a heterogeneous vehicular network, however, also means that appropriate simulation tool support needs to be guaranteed. Many established simulation tools for vehicular networking research fall short of providing the needed support for such a complex coupled system. First, vehicle mobility has to be adequately modeled – particularly as far as the influence of additional information on the mobility is concerned, for example, in terms of trips, routes, or driver behavior. Second, communication according to the different technologies has to be modeled – again, with a particular focus on the interrelation of packet transmissions using one technology on another. There exist well-established tools that can model network communication and its influence on vehicles’ movement patterns: Veins, iTETRIS, and VSimRTI. All of them have good support for mobility but are missing the tools to simulate heterogeneous networks; especially support for LTE networks is missing.

Similar to research on vehicular communication technologies, research on vehicular applications and architectures has been going on for many years now. In the most closely related proposals, cars are envisioned to become gateways for streaming multimedia content or simply providing Internet access to their occupants, or they become an enabler for emergency services. Gerla et al. propose the concept of a vehicular cloud [14], focusing on autonomous driving more than on services provisioning to users: The vehicular cloud is envisioned to provide sensor data and other information that is needed for autonomous vehicles. Other work investigated the establishing of clusters of parked vehicles to form an information hub [2]. Here, parked cars are organized using virtual coordinate-based routing concepts. Users are then able to store data inside (and retrieve data from) this network. Interdomain routing is envisioned to provide network connectivity and data management for disconnected operation. Another, already existing system is proposed by Barros [15]. It uses mesh routing between and across cars to provide Internet access to users. A similar solution coordinates delay-tolerant transfer of bulk data, for example, between data centers, via a vehicular network embedded in a centralized system [16]. In our Car4ICT architecture, we go one step further and enable a large-scale vehicular network to provide services to other cars, outside users, and even sensor systems in future smart cities.

Using Service Discovery Protocols in vehicular ad hoc networks (VANETs) has been investigated in recent years, although with no consent on a good solution. An early proposal, designed for mobile ad hoc networks (MANETs), is by Sailhan and Issarny [17]. By building a virtual overlay network they aim to reduce the load on the network. Based on network densities virtual Service Directories are established or removed. Services are described using the Web Service Description Language (WSDL) and sent following four geographic trajectories. This allows to search for a service and find one by also searching in the same four trajectories. As nodes in their evaluation randomly move with a speed of 1 m/s, it is unclear how well this works for VANETs, as cars are usually moving much faster. A protocol specifically designed for VANETs is proposed by Abrougui et al. [18]. Their system relies on infrastructure in the form of RSUs and on clustering mechanisms to reduce network load. RSUs are able to move small distances and are clustered around a service. Three types of services are supported in their approach: moving services, fixed services, and migratory ones. The last kind is fixed services staying in a certain region and is passed to other vehicles in case the current vehicle leaves the area. Lakas et al. present a service discovery solution with four different actors [19]. Instead of the usual three actors, Service Provider, Service Consumer, and Service Directory, they also see cars as mobile SDs. Requests are flooded via broadcast until a user providing the service is found or the lifetime of the message is over. Because they rely heavily on broadcast, the scalability of the proposed Service Discovery Protocol remains unknown.

For routing in vehicular networks, there exist a lot of suitable solutions for urban or rural environments. There are reactive and proactive approaches, as well as protocols focused on georouting. As evaluating and comparing them is out of the scope of this chapter, we refer to Ref. [4], which presents the best known algorithms.

The Car4ICT system will need to be able to identify available services in a location-based approach. The task of content identification is most closely related to future Internet research. At its core, a basic solution is to associate content with unique names. Here, concepts such as ICN [20] and Named Data Networking (NDN) [21] have been proposed. Applying the concepts of such ICN to vehicular networks has been proposed in Ref. [22], yet with a focus on a single-use, single-protocol network. By focusing only on IEEE 802.11p communication, the authors were able to move away from Internet Protocol (IP) and toward a new custom protocol to enable efficient ICN networking. Other architectures, by Wang et al. [23] and Grassi et al. [24], apply the concept of NDN to the vehicular domain. Both approaches, however, are targeting only a limited set of applications, optimizing the system for a specific use case and a specific communication technology. More recently, Internames [25] was proposed, a system that is envisioned to work with all kinds of approaches including IP, cellular, and ad hoc networks. At its core, Internames maps all names to locations as well as the needed protocol to reach them. Still, it focuses very much on one application domain. Our architecture tries to act as a base for a multitude of applications, building upon concepts described in these approaches such as the association of items with hash tags. Further, current ICN and NDN solutions commonly fall short when it comes to the specific requirements in the very dynamic and disruptive environment of vehicular networks, which we try to directly address in Car4ICT.

Building on this assumption, we aim to make the additional network of connected vehicles available to users. One use case might be to exploit the movement of a car when there is no other connection available—thus having a car deliver data to another region simply by exploiting its movement, either to the intended destination of the data or to an area where connectivity to the destination is available.

This enables the car network to act as central components of future ICT systems of smart cities. Our concept revolves around requesting services or offering them to users: either smart devices or, of course, people. Potential use cases are people offering storage space, unused CPU power, or devices offering access to smart sensors. Users are envisioned to request access to these services (eg, for processing large amounts of data on the go). Service requests and offers are mediated by cars, which act as coordinator: storing service offers and matching them with service requests. Two possible methods are allowed in the architecture: reactive service fulfillment where neighbors are actively queried once a request is received and proactive exchange of service tables. Once a request and one or more offers have been matched, the Car4ICT system compiles a list of offers and returns it to the requesting entity. People or devices can then elect to use a service, exchanging data with the entity offering the service—again mediated by the Car4ICT system, which employs the network of vehicles to relay the data between the user requesting and the one offering the service. Such data relaying can also be done in multiple possible ways, from routing to pure store-carry-forward.

We conducted an initial study of using a heterogeneous vehicular network for cooperative intersection collision avoidance according to an algorithm proposed by Tung et al. [7] to ensure that the combined simulation framework was behaving as expected. As a simple indication, Fig. 7.6 shows a sample result, the delay in the LTE uplink. As can be seen the delay increases with the frequency of sent messages. It also should be noted that the delay is shown independent of the transmission distance—this also adds longer delays for messages as more retransmissions are needed.

On top of Veins LTE, applications for such heterogeneous vehicular networks can be developed. Any application can decide to send the packet via a specific network stack or let a dedicated module—named Decision Maker—decide which network technology is better suited for the current transmission. The stack can be seen in Fig. 7.7. As Car4ICT is meant to work in exactly such a heterogeneous vehicular network where different technologies can flexibly be used when and where available, this simulation environment is the perfect fit for the evaluation and the validation of Car4ICT.

We added a new User module to the simulator that is able to run multiple applications and has a Connector that is in charge of connecting the user (and its applications) to the Car4ICT network. Applications then send messages to the Connector that in turn forwards it, if a connection exists, to a car. On the car side we developed the Car4ICT module. This module has three main tasks:

Figs. 7.8 and 7.9 shows screenshots of a running Car4ICT simulation. Both times, a user requests a service provided by another user (big dots). In the first case, shown in Fig. 7.8, service discovery remained unsuccessful. As the first car – the one the user connects to – does not have a corresponding entry in its service table, the request is sent further to other cars, but the request expires before reaching a valid destination. In the second case, shown in Fig. 7.9, a service is found and the user requesting it is informed. A thick line indicates the hops a data packet might take between the requesting user and the one offering the service. Note that there are two ways of answering to requests: proactively by sharing the service tables upfront and reactively by searching for a provider after a request cannot be answered.

We used the described simulation framework, implementing the outlined approach in detail. Each member (ie, each car) in the simulation periodically announces its presence to users nearby. We opted for implementing a proactive Car4ICT service discovery variant, exchanging service tables in fixed time intervals. Users periodically request different services. As long as the request cannot be matched to an offer by the Car4ICT architecture, the request is retried. When the request is successfully matched and a positive response is delivered to the user, we note the delay between first try and fulfillment as the discovery latency.

Our implementation supports all described ways of comparing service identifiers. The two most important ones for when a user is searching for a service are $\underline{\underline{h}}$ and ⊆. The first one, $\underline{\underline{h}}$, can be used to get an overview of all offered services of a certain kind in an area. Second, ⊆ helps a user to find a service with some prerequisites. The comparison = is mostly used when comparing new offered services if they do not already exist in the service table.

As the simulated traffic scenario we chose a challenging Manhattan Grid topology, populated by as much as 415 equipped cars/km² and down to as little as 35 equipped cars/km² taking random trips. Both road and building dimensions correspond to downtown Manhattan. Figs. 7.8 and 7.9 shows a small section of this scenario. Buildings next to each road shield radio transmissions across streets, thus cutting down further on the number of potential communication partners in low-density scenarios. To make the scenario more challenging, we add exactly five users connecting to a close-by vehicle and offering a service, five users requesting this service, and five more users offering unrelated services. This scenario closely mirrors the discussed use case of secure replicated storage, but with a tightly limited amount of available resources. All parameters are summarized in Table 7.2.

We illustrate results of our discovery latency evaluation in the form of an empirical cumulative distribution function (eCDF) as service requests can take anything from being instantaneously fulfilled to never being fulfilled (in increments of 2 s, the retry interval).

In Fig. 7.10 we show results for different traffic densities (measured in vehicles per square kilometer), given a service table broadcast interval of 10 s. As could be expected, traffic density has an immediate impact on discovery latency. While for high densities of 415 vehicles/km², it takes no more than 2 s to match 99% of service requests to a corresponding offer, at slightly lower densities of 85 vehicles/km² this fraction already drops to 90%, as can be seen in the zoomed-in part of the figure. At this density, fulfilling 99% takes as much as 12 s. At lower densities, even 30 s is not enough to fulfill 99% of requests. While this would be well in the acceptable range for M2M communication like in a distributed sensing use case, it would likely be above the tolerable threshold for a user-facing service.

We thus look to smaller service table broadcast intervals as a potential solution at low traffic densities. Fig. 7.11 illustrates our results, now using service table broadcast intervals as low as 0.1 s. We observed that adjusting the service table broadcast interval from 10 to 1 s was enough to achieve a better success rate than with these lower rates. Even for medium to low discovery latency constraints, system performance can be seen to be in an acceptable range, not just for M2M services but also for user-facing services such as in the discussed secure replicated storage use case. Decreasing the interval further yielded no substantial performance gain. Thus, while an adaptive service table broadcast interval would certainly help conserve channel capacity at high vehicle densities, configuring a moderate service table broadcast interval at any traffic density yields a system that delivers good performance at both high and low traffic densities.