Abstract
An intelligent transport system (ITS) is intended to streamline the operations of vehicles, manage vehicle traffic, and help drivers with safety and other information, as well as supply convenient applications for passengers. This system is essential for tackling the problems of a big city, like traffic congestion and a lack of a communication infrastructure or traffic engineering, among other factors. With these challenges in mind, we propose a vehicular cloud architecture to assist in the management of large cities. This will create a framework to support different types of services as well as provide storage mechanisms, access, and information management which includes tools for different modes of transport not only for citizens but also for commercial vehicles and emergency services like ambulances. In addition, it will be possible to increase the capacity for abstraction to meet information needs through the use of vehicular networks and the integration of VANETs with other networks, so as to provide relevant information for the monitoring and management of an intelligent transport system.
1. Introduction
Communication and information technology is the powerhouse behind some of the most important innovations in the automotive industry and in society in general as well. In the last two decades, mobile communications have changed our lifestyle by allowing the exchange of information, anywhere at any time. The use of these mobile communication systems in vehicles is expected to be a reality in the coming years, as companies, universities, and governments worldwide are devoting significant resources to improving vehicles and creating a safer infrastructure for road transport. This can be confirmed by a number of different projects and national and international initiatives carried out by government, industry, and academia devoted to vehicular networks [1–3].
Vehicular Ad Hoc Networks (VANETs) are a subclass of the ad hoc mobile networks that establish a wireless connection between vehicles and between vehicles and roadside devices. These networks have been given particular attention by the research community in the field of networks because of their benefits. They include applications that focus on road safety and how to make public roads more efficient for vehicles, while offering comfort and entertainment to passengers throughout their journey [4].
The current trend is to provide vehicles and roads with features that can make the transport infrastructure more secure and efficient and the time spent on the road more enjoyable. In this context, greater security is ensured by providing information about traffic congestion, accidents, hazardous road conditions, weather conditions, and the location of facilities (e.g., gas stations and restaurants). Greater efficiency is obtained by increasing the capacity of the road network, reducing pollution and congestion, making travel time more predictable, reducing operating costs for vehicles, providing more efficient logistics management, improving management and control of road networks, and increasing efficiency of public transport systems. Finally, making the journey more enjoyable means providing access to the Internet, with its tourist information/advertising, the ability to download files, and chat. These applications are typical examples of what can be called an intelligent transport system (ITS), which aims to improve efficiency, safety, and the fun of traveling, through the use of new technologies involving information and reports.
One means of checking the potential value of an intelligent transport system is to take as an example the study by Cintra (conducted at Harvard University in 2008), which showed that the traffic congestion cost in the city of São Paulo was approximately 33.5 billion reais per annum. Eighty-five percent of this cost is due to time lost in traffic, 13% is caused by fuel consumption, and 2% is due to increased air pollution [5]. These traffic jams can be aggravated when the city hosts a major event like World Youth Day or the FIFA World Cup. The time lost in congestion is greater during city events and causes particular harm to the vehicular traffic required for emergency services such as ambulances, police cars, and fire engines as it means they take longer to arrive at these places. In addition, it can discourage visitors from attending these events. The cost of traffic congestion can be reduced by means of VANETs which provide updated and dynamic information about the conditions of road traffic. In addition, VANETs can reduce the number of road accidents while providing drivers and passengers with applications for comfortable driving, such as location services, streaming, multimedia, local news, tourist information, and warning messages about conditions on the highway and in the streets of the city.
Vehicles can collect, transmit, and interpret information through a wide range of sensors, cameras, computers, and communication resources, and this can assist in the acquisition of data and help the drivers to make decisions to take appropriate actions [6]. With enough sensing capacity and the ability to act in an environment, vehicles can become an important tool for smart cities, not only in vehicle traffic management but also for picking up useful real-time information that can be used in resource management.
A smart city can be defined as an intelligent environment that embeds information and communication technologies and thus creates an interactive environment. This leads to better communication in the physical world and enables citizens to tackle problems and ensure better governance. From this perspective, an intelligent city (or more generally a smart space) refers to a physical environment in which communication and information technology and sensor systems disappear as they become embedded in physical objects and the environments in which we live, travel, and work [7]. A smart city must tackle various problems, such as traffic, security, natural disasters, and environmental monitoring. To obtain solutions, the urban data must be collected and disseminated through a communication infrastructure, which in turn requires integrated forms of heterogeneous and wireless communications.
The aim of these solutions is to create a framework to assist the management services of intelligent transport systems by offering support for different types of services, providing mechanisms for the storage of information, and enabling heterogeneous communication to be established between various devices. With this piece of information, it is possible to devise mechanisms for conducting the monitoring of intelligent transport systems for the management of a metropolis. Thus, it can improve the use of the computational resources needed to manage the entire infrastructure of a big city. This involves using all the resources of a cloud static website such as Amazon and the resources of the vehicle itself, that is, mobile cloud services.
The remainder of this paper is structured as follows. In the next section, we discuss some related solutions. Section 3 examines our proposed vehicular cloud-based framework to assist with the intelligent transport management of big cities. Section 4 analyzed the simulation results. Finally, Section 5 concludes this work and gives some directions for further work in the field.
2. Related Work
There are several studies in the literature that involve vehicular cloud computing such as the study by Olariu et al. [8] who proposed a new concept called vehicular cloud (VC). VC used underutilized vehicle resources to form a cloud by aggregating vehicular computing resources. It is worth noting that the proposed system does not offer any advantages to the capabilities of a conventional cloud because this proposal is only based on vehicle resources.
Mershad and Artail [9] proposed a mechanism which allowed vehicles in a vehicle network to find out information about necessary services from mobile cloud servers that are moving nearby. The authors proposed a system called CROWN, which depends on RSUs, which act as interfaces and cloud directories. This involves RSUs providing the recorded data to allow busted vehicles access to the necessary services that are in the cloud while they are within the RSU coverage area. The CROWN system did not consider the onboard computer to be a cloud computing entity that could be available to end users. The authors of [10] proposed the use of cloud computing services via RSU cloud, a vehicular cloud that uses the roadside infrastructure; this system makes it possible to benefit from services in private and public cloud vehicles. This work can be considered to offer a system that can assist vehicles in obtaining access to a conventional MSW cloud through the cloud gateway, to find the cloud service requested without the use of mobile computing resources.
A pure cloud formed of vehicles was proposed by Zingirian and Valenti [6] in which the authors developed a new sensor call service as a service (SenaaS) to serve communication platforms that supply the components of the sensor. This includes the vehicle sensors and devices for vehicle tracking applications such as cloud computing resources called sensor cloud service. This proposal is unable to make use of the traditional cloud to improve the computing power usually required for vehicles.
Hussain et al. [11] proposed a cloud which has three cloud components: vehicular clouds (VCs), vehicles using clouds (VUCs), and hybrid clouds (HCs). The VC is divided into two categories: a static cloud which refers to stationary vehicles and provides services to the cloud and a dynamic cloud which is configured through an on-demand ad hoc network. The VUC allows a vehicle to connect to the cloud with traditional RSUs while the HC is a combination of VC and VUC. It should be noted that this proposal requires the VC vehicles to be stopped. Furthermore, the vehicles can only interact with the traditional cloud through MSW, which acts as gateways. However, the vehicle cannot be connected to the MSW if the VC is not available.
El Sibai et al. [12, 13] proposed a connectivity-aware service provision mechanism, where the service provider vehicle is selected on the basis of several parameters such as the availability of the requested service and the mobility of the vehicles. This mechanism allows a service requester vehicle to form its own cloud. The services are exchanged between the service requester vehicle and the service provider vehicles. The requester carries this out by sending a request message via broadcast to its neighbors. Although the authors create a relay mechanism, this mechanism is unable to troubleshoot the broadcast storm and thus causes an overhead on the network.
Our solution is to assume that the vehicle has resource that can be used for any cloud service; that is, the vehicle becomes both a cloud user and a provider of resources to the cloud. The framework provides mechanisms that can enable the vehicles to access resources via an outer infrastructure; in addition, they can form cooperation mechanisms between themselves so that in the absence of a road shoulder the vehicles can have access to cloud resources.
3. A Vehicular Cloud-Based Framework for the Intelligent Transport Management of Big Cities
The main aim of the proposed framework called VICTiM, VehIcular Cloud Transport Management, is to provide assistance for the management services of intelligent transport systems and mechanisms for the storage of the information. This allows heterogeneous communication between multiple devices simultaneously by managing the mobility of vehicles, together with the information flows that are generated. This means that VICTiM can provide support for different types of services.
Apart from overcoming the challenges arising from the features of vehicular networks and vehicular clouds, the proposed framework is responsible for the following: Management and data storage. Allocation and sharing of resources. Interoperability between different devices.
The framework undertakes this by checking the best forms of communication and interaction between vehicle networks and other networks to support data flow and the needs of people, as well as handling all the resources requested by the demand for services.
The main established services that the cloud should provide are as follows. Cooperation as a Service (CaaS). The framework undertakes this by checking the best forms of communication and interaction between vehicle networks and other networks to support data flow and the needs of people, as well as handling all the resources requested by the demand for services. The main established services that the cloud should provide are as follows. Vehicular networks provide a wide range of new services such as road safety, traffic control, active traffic alerts, warnings of accidents, information about weather or traffic conditions, parking availability, and ads. A data dissemination mechanism is employed for the disclosure of information that is collected so that these services can use and share this piece of information. This requires establishing connectivity not only between vehicles but also between vehicles and roadside units and thus has a hybrid communication system for the discovery and dissemination services offered by the cloud. The system can handle communication with denser networks involving regions with a high number of cars due to the occurrence of an important event, where the network will have a huge amount of data traffic causing transmission congestion. Relay selection mechanisms are used to address this problem; that is, only vehicles or the selected roadside units allow for retransmission of the message. We will use the coverage area that is transmitting the message to select its relay, which may be from regions within that coverage area. A node will use the location of both the transmitter and relay to aid communication. This location will also be used for monitoring the way the regions close to the event check the degree of traffic congestion and also to recommend alternative routes through the monitoring and interpretation of the data at the events and in the neighboring regions. Information as a Service (INaaS). The cloud must provide services to pick up information about not only traffic conditions, but also possible incidents that may be taking place on the road, like accidents. This service will be carried out by disseminating the data about any event and also sending messages that make connections with vehicles. This service will receive information from mobile devices so that it can have more data in a given region and thus allow better inferences to be made about what is happening. The cloud will have geographical data about incidents occurring in nearby regions, which will allow an analysis and interpretation of data. This procedure will employ mathematical methods for the following: to calculate the extent of possible traffic jams, make a mobility prediction of individual drivers, recommend alternative routes to avoid congestion, and estimate the likely computational demands of the next event. After the interpretation, there will be a resource allocation.
3.1. VICTiM Overviewer
VICTiM is based on the work of Whaiduzzaman et al. [14]; however, it improves the communication between vehicles and vehicles with roadside units. Furthermore, VICTiM is a framework which is divided into three components: consumer, communications, and cloud. Figure 1 illustrates the abstraction of the VICTiM framework.
VICTiM abstraction.
3.1.1. Cloud Service
The cloud service refers to the data center where services to consumers are provided. The cloud server consists of a traditional fixed data center (which may be, e.g., Amazon, Google, or Microsoft) and mobile devices such as vehicles or people (smartphones) that temporarily belong to a cloud. This layer is subdivided into three sublayers: central cloud, cloudlets, and vehicular mobile cloud. The central cloud consists of a fixed data center which is virtualized and includes the computing infrastructure in the traditional cloud. The central cloud is interconnected through traditional networks and provides many features and computing services for consumers that are directly connected to the data center. This central cloud offers various types of software and applications that are run remotely over the Internet via a web browser interface or any of the specific programs.
The cloudlets are a set of devices connected to the roadside unit (RSU) to provide aid in the management of resources that are shared by the central cloud. This means that the cloudlets can assist in the management of resources within the central cloud.
The vehicular mobile cloud consists of a set of mobile computing resources and vehicles, which are not used by traditional cloud computing. These resources are interconnected through the vehicular network. The vehicular mobile cloud can be either fixed or mobile. In the case of the former, vehicles, RSUs, and/or passengers can rent their computing resources from other consumers that are in off-state (e.g., cars in parking lots or passengers waiting for a bus). In the case of the latter, the vehicular mobile cloud consists of vehicles that share their idle resources with the vehicles around them. This kind of vehicular mobile cloud is generally used when vehicles do not have communication with the RSU. It is one of the great challenges of this framework to establish a mechanism for management and search resources only between vehicles. There will be an examination and evaluation of this mechanism in this study.
3.1.2. Communication
The purpose of this layer is to ensure that the connection can be established between customers located in the lower layer and the cloud located in the upper layer. This layer consists of various communication devices and networks: vehicular networks, wireless sensor networks, and 3G/4G networks. In this layer, all the technological connections (the physical layer, data link layer, medium access control, routing protocols, etc.) are defined and determined in accordance with the communication device. The choice of technology in the lower layer also depends on the type of consumer. This layer will have to deal with a hybrid form of communication; that is, it will have to establish communication between vehicles to disseminate relevant information. It will also have to handle communication between the vehicle and roadside units for expected information from the cloud.
With regard to communication between the central cloud and ordering services, the vehicle will also have to communicate not only between vehicles but also with a roadside unit that may be a cell tower or WiFi Hotspot. For this to occur the vehicle will have work with more than one network interface at the same time, as well as with the mobility of the vehicle. An extension of the PMIPv6 protocol is employed for this; in addition to addressing the question of node mobility, this protocol will be responsible for the mobility and information flow in the network. The 802.21 protocol is also employed to capture the network state information and verifies if the base station is available for a new connection as can be seen in [4, 15]. The results showed that the use of more than one network technology at the same time provided better load balancing in messages that were sent and thus resulted in lower packet losses and shorter delays when there are a large number of participants. Furthermore, no delay in the applications exceeded the standard time established by ETSI. The flow control based on application classes prevented the packets from being overloaded in a single network, thus reducing both the delivery time of the messages and the number of lost packets.
For communication between vehicles, we developed a protocol aimed at the dissemination of data presented in [16, 17]. These protocols must be used to troubleshoot broadcast storms and network congestion since these problems are widespread on roads. The mechanisms for defining an area of interest, that is, an area where the message will be disseminated, mean that the mechanisms can thus eliminate the broadcast storm and maximize the dissemination of data between the network partitions and provide the whole network with a low overload, short delays, and greater coverage. Furthermore, this protocol had a sweet spot in which vehicles inside the sweet spot have a higher priority to rebroadcast the data; that is, vehicles inside those regions are assigned a lower delay to rebroadcast a packet.
The sweet spot is an area where vehicles inside it are best suited to continue performing the data dissemination. In other words, among all vehicles that receive a data packet to be forwarded, the transmission of a single vehicle within the sweet spot is enough to perform data dissemination efficiently. Vehicles located within the sweet spots are more likely to spread the information further and to reach a larger number of neighbors that could not be reached by the previous transmitter. For the sake of simplification, the shape of the communication area is considered to be a circle, but any shape works for the proposed solution. The communication area is decomposed into four quadrants, and in each quadrant one subarea of the quadrant is defined as a sweet spot. This region tries to eliminate the broadcast storm problem; nodes inside the sweet spot have a lower transmission delay and cancel the retransmissions to nodes that are not inside the sweet spot. Among the nodes inside the sweet spot, the one farthest away from the transmitter will retransmit earlier and will cancel unnecessary retransmissions as well.
Despite the fact that the sweet spot approach is effective in avoiding the broadcast storm problem, it does not deal with the network partition problem. Therefore, to solve this problem we use an autonomic computing mechanism that calculates the probability for a vehicle to disseminate the information or not. This calculates the probability and also assists the store-and-forward action when the network is partitioned, thereby preventing the information from being lost. The main objective of the autonomic technique is to decide if a message will be sent or not. The propagation efficiency is the relation between the number of transmitted messages by the number of received beacons. Beacons are used solely as a means for sensing the environment surrounding a vehicle.
The propagation efficiency is used to control the transmissions of a given vehicle; that is, if it is below an acceptable threshold, the node broadcasts the information; otherwise it does not. Periodically, the vehicle calculates the efficiency of its message delivery:
Besides the propagation efficiency, another factor that may influence message propagation is the message lifetime, which will limit data dissemination. Algorithm 1 shows the calculation of the propagation efficiency used to decide whether to propagate a message or not. Based on this mechanism, the node stores the packet until its efficiency is above a threshold or until one of the other parameters is achieved, thus enabling message delivery even in the presence of network partitions. The thresholdDown and thresholdUp are efficiency percentages, which represent the lowest and highest thresholds, respectively, which need to be respected for the vehicle to perform data dissemination. Those values were obtained by previous experiments.
(1) (2) (3) (4) (5) (6) (7) (8)
When an event occurs that needs to be propagated, the vehicle that detects it creates a message that will be disseminated to all vehicles within the area of interest (AoI). Upon receiving the message, each node verifies whether it is inside of the AoI. If it is not the case, the node discards the received message. Otherwise, the node verifies whether it is inside the sweet spot of the transmitting node, computes the waiting time, and schedules the message retransmission. Whenever a vehicle detects a network partition, which is indicated by the lack of beacons, it waits until it receives new beacons. The works [16, 17] describe in detail the operation of this algorithm, and the results of the simulations that were carried out showed that adopting the algorithm approach yielded the best coverage results, despite the fact that it has a slightly higher delay and overhead than some of the existing solutions.
This algorithm can be used for services that require data dissemination close to an event or a possible event that has produced a traffic jam. However, this algorithm does not address issues of allocation and search resources between vehicles. In view of this, we propose a search and management protocol of resources, which is an extension of the Gnutella protocol, in which the fields of the main control message protocol are altered. A ping message was added to the location of the vehicle that made the request, the resources that had to be allocated to the requester, and the identification and location of the controller (superpeer) and gateway. The pong has the same fields but these were added to the location and the id of the node that sent the ping message, the status of the requested services, the id gateway, and the controller that the node is connected to. The query message has the same location as the requester, the identification, and the location of the gateway and controller and the required resources. A queryHit message already has the confirmation and not the request of the resources, the identification, and location of the sender and the location and identification of the gateway and the controller it is connected to. The identification fields and location of the gateway and controller are essential info for routing components.
As well as the Gnutella messages, we also made use of 802.11p beacon messages for congestion control, because, with these, it is possible to pick up the values of speed, direction, and position. Moreover, they add shared resources beyond the field to give information about which resources the vehicle can share. This kind of message serves to assist in the maintenance of the nodes next to those which requested the controller. This facilitates the search for resources to create the controllers which are the most distant vehicles in the area of communication of the requesting and which are traveling in the same direction, that is, the two vehicles which are on the borders of the communications coverage area.
In making the allocated resource the vehicle needs to (i) have the same direction of the requester and the relative velocity between the requester vehicle and the vehicle that has resources to be shared, equal to 0 (the vehicles have the same speed), or (ii) have the same directions, and the distance of the requester to the other vehicle divided by the relative velocity between the requester and the other vehicle needs to be greater than the transmission delay plus the time of the resource use. Equation (2) shows the parameter that the vehicle needs to be allocated in case the relative velocity is greater than 0:
If there are any vehicles near the requester that meet the above requirements, the requester sends a message directly to the requested vehicle trying to allocate the resource. Otherwise, the vehicle sends a request to the controllers which have become the new requesters, which have already observed, between the vehicles connected to it, if someone meets the requested requirements. If the controller has allocated all the necessary resources, they send a confirmation response to the requester. Otherwise the controller forwards the request to the next controller, which will be the farthest vehicle in front or farther than this back, depending on the position of the new requester, which in turn executes the same process.
When a vehicle needs some resource of the vehicular cloud, then the requester checks among its neighbors if any vehicle meets the request. If yes the requester will store this piece of information and send a query message to the vehicle requesting the resource. Upon receiving the query, the vehicle checks whether the service is actually idle or not and responds with a query_hit. When the requester receives a query_hit it checks if the allocation occurred or not and updates the information in the vehicle. If the allocation was successful, the service is started. Otherwise, the requester selects the controllers from both the front and the back and sends a query to these controllers. Controllers receive a query to store all the information of the requester and then perform the process of checking if any of the vehicles connected to it meet the requirements; if so it sends a new query for these vehicles. Upon receiving the query check, the vehicle is actually the service or not and responds with a query_hit. When controllers receive a query_hit they store the entire information of the vehicle and send it to the requester, informing the allocation of required resources. However if the controller managed to allocate resource to any of the vehicles connected to it, the controller will first check its position in relation to the requester and then retransmit the request to a new controller, which will be the vehicle furthest to the front or the vehicle furthest to the back, depending on its position in relation to the vehicle that requested the resource.
This system has also changed the strategy of message transmission, because of the characteristics of the vehicular network. The strategy of transmission used is the same data dissemination mechanism as that described above.
3.1.3. Consumer
The consumer layer consists of end users (consumers), which can be either human or a vehicle that requires a cloud service (in this study only vehicles are taken into account). The consumer can be characterized as having some degree of mobility in the environment. By using communication and computing devices such as smartphones, onboard computers, and GPS, consumers can establish their service requests to adjacent layers through a manager and search resource mechanism. To this end, the consumer receives a resource response sent by the higher layers via the manager and search resource mechanism. In their region, consumers can create their own local network and thus request and offer services to other consumers.
4. Performance Analysis
This section describes the scenario and performance assessment of the management and search resources in a vehicular mobile network by means of simulation experiments using OMNeT++ 4.6 (https://omnetpp.org/), a network simulator, and an event-based network simulator. We also make use of the Simulator for Urban MObility 0.25.0 (SUMO) [18] to build the scenarios and the vehicle mobility model. Furthermore, the experiments rely on the Veins 4.3 (http://veins.car2x.org/) network framework, a well-known tool in the research community that implements the IEEE 802.11p protocol stack, signal attenuation caused by obstacles, and other features used in our analysis.
4.1. Scenario Description
In this work, we use a realistic scenario for the simulations, it is taken from OpenStreetMap (http://www.openstreetmap.org/). We considered 4.5 km of the SP-065 Highway (Dom Pedro I Highway), which is a highway in the State of São Paulo, Brazil. It is one of the most modern highways in the country and links the Anhanguera and Presidente Dutra highways and serves the cities of Campinas, Atibaia, and São Jose dos Campos.
Three types of vehicles are included in the network to ensure a near-to-real overtaking simulation. The first consists of vehicles capable of reaching a maximum speed of 120 km/h with a length of four meters, while the second consists of vehicles capable of reaching a maximum speed of 90 km/h with a length of 14 meters. Finally, the third includes vehicles of 18 meters long, which are capable of reaching a maximum speed of 90 km/h. This scenario can describe a network consisting of passenger cars, buses, and trucks. It should be noted that the number of vehicles for each type is different during the simulation period. We assumed a network comprising 50% cars, 25% buses, and 25% heavy trucks as seen in Table 1. Vehicles can move along the highway in two opposite directions. Moreover, vehicles are located on opposite sides of the highway moving at a constant rate. Each vehicle has 0 or 2 resources which can be shared; in other words, vehicles may not have any available resources or may have storage and computation resources or may have a network and computational resources or may have storage and network resources. The choice of these resources is made in a random manner thus diversifying the types of shared resources.
Types of vehicles.
When the simulation reaches a stable state, the vehicle that is in the middle of the highway initializes the process of search and cloud management by sending the request message (query message) and looking for 3 types of shared resources by the use of mobile vehicular cloud computing. This message is sent either to its neighbors or directly to the superpeers (controllers), thus establishing the entire management infrastructure.
The objective is to evaluate the search time for resources, how long it will take for these resources to become available, and the number of control messages generated in the network to establish the request and the maintenance of the network. Two simulation scenarios were carried out for this. We evaluated the solution alone by varying the rate of vehicles on the highway (500, 600, 700, 800, 900, and 1000 vehicles/hour) and also by varying the time that the service needs to be active (20, 40, and 60 s). The following metrics were used: (i) availability of service, (ii) lack of available service, and (iii) number of control messages generated which were disregarded and the standard control messages from the network (the beacons).
The bit rate was defined as 18 Mbit/s in the MAC layer and the transmission power tax 2.2 mW; thus, the communication range will be approximately 300 m under a two-ray ground propagation model [19]. Finally, in all the results, each point in the curves represents an average of 40 replications with a confidence interval of 95%. Table 2 shows the configuration and parameters that were used to execute the simulations.
Simulation parameters.
4.2. Results
Figure 2 shows the percentage of services delivered; that is, the protocol was able to allocate 100% of the demand for requested services. It can be seen that when the vehicle orders the 3 resources for 20 seconds, the protocol can meet 100% of the resource demand. This is because the vehicle still continued to allocate resources on the highway and thus a new allocation was not necessary. When we look at 40 and 60, it can be observed that there is a difference between them due to the service availability time that is necessary to establish new allocations. However, the denser the highway, the better the availability of the service. For example, if we analyze a point with 500 vehicles/hour, it can be seen that service delivery is around 90 percent for a service of 60 seconds, which is lower than with 1000 vehicles/hour.
Service availability.
Figure 3 shows the percentage of lack of services which is inversely proportional to the delivery of services. There is a low loss of service of around 15% due to the service time allocation so that a greater time allocation is needed for more messages to be exchanged. This is because the protocol must allocate the service that will be lost to another node. Furthermore, the protocol must predict when the node that is allocated may have left the area of management.
Service lack.
Figure 4 shows the number of generated control messages, excluding the beacon. We can observe that an accumulation of messages occurs when the number of vehicles increases; this occurs because the more the vehicles on the highway, the more the pings, and the vehicles will thus also receive more pong messages from the vehicles going forward. This means that it is not necessary to have new feature allocations owing to the displacement of the vehicle. In a scenario with 40 and 60, they are different, simply because the car will leave the monitored area and the protocol needs to make more allocations to keep the available resources. Hence, the greater the availability of resources, the larger the number of control messages.
Overhead.
To summarize, the solution proposal demonstrated a stable behavior, since even with the increase in vehicles or increased use of resources, the protocol did not show any sudden variation but retained its stability. In addition, the solution proposed had a high rate of service availability reaching about 85% availability in the worst case scenario (500 vehicles with 60 s of service allocation time).
5. Conclusion
In this paper, we proposed VICTiM, a vehicular cloud-based framework for the intelligent transport management of big cities. These provided mechanisms are for carrying out the storage of information and enabling heterogeneous communication between multiple devices while at the same time handling the mobility of vehicles and information flows generated. This included simulated model management and resource allocation, in which the module demonstrated a stable behavior, since even with the increase in vehicles or increased use of resources, the protocol did not show a sudden variation and retained its stability. In addition, the solution proposed showed a high rate of service availability reaching about 85% availability in the worst case scenario (500 vehicles with 60 s of service allocation time). In future work, we aim to adapt the management and search resource module to operate in urban scenarios and conduct tests that take into account the architecture as a whole.
Footnotes
Competing Interests
The author declares that they have no competing interests.
Acknowledgments
The author would like to thank the supporting organizations for funding this work, Grants no. 2015/11536-4 and no. 2015/18898-9, São Paulo Research Foundation (FAPESP).