1 Introduction

During the past few years, Intelligent Transportation Systems (ITS) have become a significant topic in research and development as their ambit is to enhance safety and efficiently in transportation systems via the use of advanced technologies [1]. The idea of ITS is not limited to road systems but can also be used for marine and aeronautic surroundings. However, most people indicate to road systems if they mention ITS.

ITSs are expected to offer fundamental services, which can be distinguished in ITS-services and value added services. Some examples of ITS-services are pre/post crash warning, electronic license plates and intelligent traffic flow control. Internet service provisioning, intelligent fleet management or detailed real time traffic flow information and advanced navigation services are some examples for value added services [31].

Value added services mainly access to the internet for their applications. Connection with the internet is generally necessary, and it can be gained by the vehicles via establishing sessions with Wi-Fi access points. Internet connectivity can also be achieved via the cellular GSM/GPRS or UTMS systems, which already have very high coverage.

ITS services enable applications in two main orientations: transportation safety and transportation efficiency. Many transportation safety and efficiency applications are location-specific. Typically, IEEE 802.11p/1609 is used for ITS services. Here, a lot of location information (e.g., GPS information) is already included in the message format of the Wave Short Message Protocol (WSMP, IEEE 1609.3). Thus, part of LIS functionality is already included in these technologies.

ITS safety services are often ad hoc based, have comparatively strict time requirements, and it is essential to determine end-to-end delays. Actually all of them depend to cooperative awareness beaconing at high beacon rates: 10 beacons/s or message period of 100 ms. For example, pre-crash sensing is dependent to a small communication range. Some of the ITS safety services have relatively demanding positioning requirements: lane change warning desires respective positioning accuracy of less than 2 m, whereas cooperative forward collision warning requires respective positioning accuracy of less than 1 m [41]. All vehicles and RSUs are to be location-aware, but GPS or other localization systems enable a coarser grained level of accuracy than the above-mentioned requirements. As a result, an efficient LIS is necessary to get more precise location information.

Vehicular Communication Networks (VCNs) are used to supply a communication platform for ITS services also for value added services in different road systems. To build up a VCN, various entities are used, among others: vehicles, roads infrastructure such as intelligent traffic lights, traffic signs, Road Side Units (RSUs) and wired or wireless backhaul networks that are applied to provide communication between these entities and to enable interconnection with the internet. Based on how the VCN is built up and which services are used, various types of communication are appeared, namely vehicle to vehicle communication (V2V) and vehicle to infrastructure communication (V2I) [2].

In comparison to other communication networks, VCNs come with major challenges: high mobility and velocity of vehicles that cause rapidly change topology of network and fast change of vehicle’s locations. Hence, location information of vehicles is needed for various purposes such as ITS services and value added services as well as for basic communication services in VCNs.

Location information services (LISs) or location management systems (LMSs) are used to provide this information, either in a proactive or a reactive manner [3]. LISs should provide location information about vehicles such as current location, speed, direction and report this information to other vehicles or network entities that require this information.

There are several approaches for LISs and some surveys on LMSs and LISs in mobile networks have been done. Rahaman et al. [4] classify existing location management schemes and present a taxonomy and survey of location management strategies that have been proposed in the literature over the years for mobile computing systems. Das et al. [5] present a performance comparison of three scalable location services for Mobile Ad hoc Network (MANET). However, to the best of our knowledge there is no comprehensive survey for LISs in VCNs. In this article, we want to give an overview about this topic and moreover, we present a classification for LISs.

The rest of this paper is organized as follows: Sect. 2 introduces the related terminology we used for LISs as well as for VCNs on basis of an environmental description. This also includes fundamentals of LISs. In Sect. 3 we define classification criteria for LISs and classify LISs on basis of the introduced criteria. In Sect. 4 we present LISs approaches for Vehicular Ad Hoc Networks (VANETs) and then we introduce LISs approaches for infrastructure-based VCNs in Sect. 5. After that we define some performance criteria and evaluate LISs based on these criteria in Sect. 6. Finally, we conclude in Sect. 7.

2 LIS for VCN: terminology and environmental description

In the first part of this section, we describe a general environment of VCNs. Here, we explain how VCNs are build up, used terminology, major characteristics and challenges toward VCNs. In the second part of this section we explain fundamentals of LISs in VCNs.

2.1 Vehicular Communication Networks

There are some participating entities in VCNs that build up this network. These entities are RSUs, navigation systems, positioning systems such as GPS and vehicles equipped with wireless communication.

There are 2 types of VCNs: Ad-hoc VCNs and Infrastructure-based VCNs. Ad-hoc VCNs or VANET is a self-configuring mobile ad hoc network of vehicles interconnected via a bandwidth constrained wireless medium. Vehicles are attached with a short range wireless radio so that they can act as information sources, information relays, and as recipients of information. There exist two main forms of communication in VANETs: Vehicle-to-Infrastructure (V2I) and Vehicle-to-Vehicle (V2V). While V2I refers to communication between vehicles and roadside equipment (e.g., base stations and RSUs), V2V relates to direct connectivity between vehicles without involving the intermediate infrastructure.

In infrastructure-based VCNs, RSUs can be connected to the backbone network in 3 forms: wired, wireless and combination of wired and wireless. Both of V2I and V2V communication participate in this category. Most applications rely on a hybrid form that combines both of these V2I and V2V techniques [42].

In order to provide seamless services in VCNs, the first step is to provide a stable wireless network access, including mobility support. To provide network access, several access technologies are established such as IEEE 802.11p/WAVE, IEEE 802.11 WLAN or 3G/4G. There are several ITS projects that use these wireless access technologies. IntelliDrive (sm) [34], NoW (Network on Wheels) [35] and SimTD (German ITS project) [36] are some examples that try to enable secure and reliable wireless communication among vehicles or between vehicles and roadway infrastructure.

VCNs provide wireless communication capabilities among devices in a certain range. This devices are either stations (STAs) installed in vehicles as on board units (OBUs) to provide wireless communication capability for another vehicles or Network Access Points (NAPs) strategically located in fixed points along the road, hence, usually referred to as road side units to provide wireless interfaces to vehicles within their radio coverage.

Vehicles without any device for communication cannot take part in VCNs so we use OBUs on vehicles to provide wireless communication. Here, we distinguish OBUs into 3 categories, OBUs that are fully integrated in vehicle (i.e., they were pre-installed by manufacture and are interconnected with all in-car sensors), OBUs that are partially integrated (i.e., vehicle was upgraded with an OBU and OBU is only interconnected to electric power) and finally OBUs that are not integrated (e.g., smart phones that are used as OBUs). In VANET, RSUs are considered as fixed OBUs but infrastructure-based RSUs differ because they can be interconnected to backbone network. RSUs are used to enhance communication as well as provide information for OBUs acquired by application servers or internet.

In ad hoc VCNs or VANET, there is a highly mobile wireless ad hoc network. This self-organizing network can be rapidly deployed without the need of any pre-installed infrastructure. In such networks, each OBU operates not only as a host but also as a router, forwarding packets for other OBUs. OBUs form a decentralized communication network by means of wireless multi hop routing and forwarding protocols. The topology of the network in VANET may change unpredictably and frequently. As a result, routing in ad hoc networks becomes a challenge due to this dynamic nature and needs to be solved. Also, in wireless vehicular sensor networks that are energy constrained, design and develop of energy efficient routing protocols has recently received considerable attention [51, 52]. Yen et al. [50] proposed a multi-constrained multicast routing protocol based on genetic algorithm so that it can be applied in VANET. We may use RSUs in VANET but they are standalone without any connection to backbone network. VANET is a good solution where there is no pre-installed infrastructure and OBUs act as client and server to provide applications in these networks, so developing VANET is cheaper than infrastructure-based VCNs but it suffers from reliability when dense of OBUs in a specific area is very low so that desired information cannot reach to destination OBUs and frequently disconnection occurs.

At the other side, RSUs can be wired or wireless connected to the backbone network of infrastructure-based VCNs. Actually, wired links can be replaced by any links with high bandwidth, low delay and low bit error rates. Such links are mentioned as backbone links, so that an RSU can exchange information with its neighboring RSUs. In case the backbone network is connected to the internet, OBUs can access the internet via RSUs. Infrastructure-based VCNs need more cost than VANET to be deployed and it can be used in city environments where pre-existing infrastructures exist so it helps to provide a more reliable network than VANET in these areas. Figure 1 illustrates VCNs in ad hoc and infrastructure-based environments. There is an opportunity to merge these two networks and use benefits of both. In a word, OBUs construct VANET and RSUs act as gateways and provide access to the infrastructure networks. This hybrid architecture has the advantage of scalability and economy [24].

Fig. 1
figure 1

Vehicular Communication Networks (VCNs). a Infrastructure-based VCNs. b Ad hoc VCNs

Full size image

In comparison to other communication networks, VCNs come with some general characteristics [6, 7]:

2.1.1 High mobility

Due to the nature of road systems and moving vehicles, the environment in which vehicular networks operate is extremely dynamic.

2.1.2 Highly dynamic topology

Due to high speed of movement between vehicles, the topology of the entire VCNs or at least parts of the VCNs is always variable.

2.1.3 Predictable mobility

Unlike general mobile ad hoc networks, where it is hard to predict the node’s mobility, vehicles that take part in VCNs have a very predictable movement because their motion is limited to roadway shape.

2.1.4 Frequently changing connectivity

The connectivity of the vehicular networks could also be changed frequently. Especially when the vehicles’ density is low, it has higher probability that the network is disconnected. To solve repeated and long-lived disconnections problems, opportunistic routing methods have been designed in which, at every hop, a vehicle determines whether it should forward or store-and-carry a message. Vasilakos et al. [49] presented a systematic exploration of delay tolerant networks (DTNs) concepts, protocols, and routing schemes also authors in [46] presented a taxonomy for opportunistic routing protocols in disruption tolerant networks. As a solution for large scale and sparse vehicular DTNs, Zeng et al. [47] proposed a directional routing and scheduling scheme named DRSS which can help to relay, carry and forward the packets by selecting the optimal routes via learning and predicting the network environment that enable good performance for routing toward the destination.

2.1.5 Potentially large scale

Unlike most of networks that usually consider a bounded area and low number of network nodes, VCNs can expand over the all road network and include many contributors in network.

2.1.6 OBU density

Density of vehicles equipped with OBUs varies dependent on the considered road system. In some road systems, (e.g., in rural areas) there may be only very few vehicles per kilometer. In contrast, there can be a very high number of vehicles at frequently used roads, (e.g., at highways or city roads).

2.1.7 Various communication environments

Vehicular networks are usually operated in two generic communications environments. In city scenarios the streets are often separated by buildings, trees and other obstacles. Therefore, there is not always a direct line of communications in the direction of intended data communication. But in highway traffic scenarios, the environment is comparatively simple and straight, because mobility of vehicles is limited to one dimensional movement.

2.1.8 OBU types

As we mentioned before, OBUs can be classified into 3 categories, first, OBUs that are fully integrated in vehicle, second, OBUs that are partially integrated and third OBUs that are not integrated in vehicles.

2.2 Fundamentals of location information services

LISs provide location information about vehicles with communication capability, such as current location, speed, direction and report this information to network entities or other vehicles that are equipped with OBUs, and require this information.

In traditional positioning systems, location information has typically been taken by a device and with the help of a satellite system (i.e., a GPS receiver) so each vehicle has only its own knowledge. With the help of LISs this information can be distributed and shared among other vehicles. Vehicle’s location is an important matter in this data-service world: it allow us to understand completely new service concepts (e.g., tracking applications [11–14]), moreover, it has the capability to make many messaging and vehicle internet services more relevant to clients as information adjusted to context (e.g., weather information adjusted to the region one is in). In addition location information can considerably improve service usability.

A large number of LISs in VCNs have been recently developed. We classify them into 2 categories: (1) LIS for ad hoc VCNs and (2) LIS for infrastructure-based VCNs. LISs are used in wireless ad hoc and hybrid networks. Below we explain their use cases in these two kinds of networks.

In VANET, consider the scenarios that two moving vehicles which are equipped with OBUs, exchange information, such as files sharing, instant messages, back-seat games and so on. Vehicles, provided by wireless communication devices, GPS and digital maps, dynamically set up ad hoc networks without the aid of infrastructure. Data packets can be relayed to destinations beyond the radio transmission range via multi-hops communication. Because of the scalability and low overhead, location-based routing protocols are used to forward packets in VANET. They all require a LIS, which helps the vehicles to convert destination’s IDs (address or name) to corresponding positions [8, 16–23].

Beside usefulness of LISs for ad hoc VCNs, it plays an important role in infrastructure-based VCNs. There are some applications and use cases for LISs where there exist some infrastructures such as RSUs that communicate with vehicles. LISs improve some applications such as mobility aware forwarding [15] or handoff mechanism (The process required to transfer the network connectivity of a vehicle from one RSU to another) [9, 10].

As we mentioned before LIS should provide location information about vehicles. For this purpose, LIS need to gather, store, analyze and distribute these location information to vehicles or network entities that require this information. Some positioning systems such as GPS are used for gathering position information of vehicles, when a vehicle enters to cover range of some RSUs, sends its position to one of the RSUs and consequently that RSU sends this information to location servers to maintain and store location information of vehicles. Now we have a large database with position information of vehicles and also a timestamp for each of this information that has been generated. So we have opportunity to analyze them and predict next location of vehicle for some applications such as vehicle tracking, improve handoff latency and mobility aware forwarding in advance.

Protecting the privacy of vehicles [25–27, 32, 33] is an important issue. A challenge comes up when try to protect vehicle’s privacy while construct a system that permits for flexible use of location information. Then the LIS system must be able to provide means to protect the privacy of a vehicle’s location. Unluckily, observing personal locations with a potentially un-trusted system causes privacy menace to the monitored individuals, because a hostile could abuse the location information gathered by the system and deduce personal susceptible information. We have 2 types of client that access to location information. One is the RSUs that use this information for some reason such as handoff process or mobility aware forwarding and the second type is the vehicles that want to access this information. For example driver of one vehicle may decide to know about the number of vehicles in next roadside to measure traffic density.

In VANET, based on LIS protocol, some specific vehicles act as location server and maintain location information of correspond vehicles and reply to location queries. Hence, it is probable that some kinds of adversary vehicles which act as location servers in ad hoc networks use this information for malicious purposes. But in infrastructure-based VCNs we can use some application servers to act as location servers and apply privacy approaches which mentioned before to protect from malicious vehicles. Moreover, reliability of LIS is guaranteed further when infrastructure is applied in vehicular networks and performance properties of LIS improves but we must bear the cost of implementation of infrastructure in road networks.

3 Classification criteria for LIS

In this section we explain about criteria that are used for classifying LISs in VCNs.

Our classification is based on three main criteria which are location server structures, network structure and message exchange patterns. These criteria consequently divided into sub-components that distinguish LISs in VCNs.

3.1 Location server structures

First criterion is structure of location servers that can be divided into distributed and centralized. In distributed case, location servers are repartitioned in whole of network and each location server maintains a part of all vehicles information. There are two kinds of data structure for distributed location servers, hierarchical-based and hash-based. For a hierarchical-based data structure, the network area is recursively divided into a hierarchy of smaller grids (squares). For each vehicle, one or more location servers in grids at each level of the hierarchy are chosen to maintain and store location information of vehicles. But in hash-based data structure, location servers are chosen via a hash function, which maps each vehicle to a rectangular or circular area called home region, virtual region, or home agent. Each vehicle sends its position information to the respective location servers in the home region. In VCNs, some specific vehicles or separate infrastructure can act as location server. In VANET, based on LIS protocol, specific vehicles act as location servers but in infrastructure-based VCNs there is a solution to use application servers (i.e., location servers that are connected to roadside backbone) to maintain location information of vehicles. Another kind of location server structure is centralized so that there is a central location server which maintains all information of vehicles in the system but it is not practicable in vehicular networks due to large scale of road systems.

3.2 Network structure

Second criterion is network structure which represents types of communication in vehicular network and divide into 3 categories, Infrastructure-based, ad hoc and hybrid. There are some fixed infrastructure devices like RSUs that vehicles communicate with them but in ad hoc networks there is no pre-existing infrastructure. In such networks, each vehicle operates not only as a host but also as a router and vehicles participate in routing by forwarding data packet for other vehicles. Combination of infrastructure-based and ad hoc constitute hybrid structure.

The main drawback of ad hoc structures for LISs is their limited scalability in highly dense vehicular networks with a large number of service requests. Ad hoc LISs are completely distributed and do not rely on any infrastructure. Although request and reply messages’ propagation is controlled in these structures, the number of messages exchanged in these structures become very high in large and dense networks with a large number of service requests. The increase in the number of exchanged messages leads to inefficient bandwidth usage, which could affect the success rate and the response time of these structures. We believe that an efficiently designed infrastructure-based LIS can improve the performance of a service in large-scale vehicular networks.

3.3 Message exchange patterns

Last important criterion is message exchange pattern in LISs which is divided into push-based, pull-based, event-based and periodically. Push-based and the pull-based gathering are methods for information gathering, scheduling, and dissemination. In a push-based system, the vehicles continuously monitor a broadcast process from the LIS system and retrieve the data items they require, thereby without making any explicit requests. In contrast, a pull-based method is an on demand traditional client-server system where the source vehicles initiate the data transfer by sending requests and the LIS system then makes a reply to satisfy the requests [28]. The concept of event-based and periodically message exchange can be defined by the factors that contribute in triggering of an update event. In a periodically update case, a vehicle sends its location update message periodically to the corresponded location server. But in event-based each vehicle sends update packet for some reasons such as when it turns left or right or every time when driving a determined distance, for instance, every 100 meters. LISs classification flowchart is illustrated in Fig. 2 based on mentioned criteria.

Fig. 2
figure 2

Location information services classification

Full size image

Comparison of LIS solutions are given in Table 1. We have compared 11 solutions for LISs in VCNs as the first eight solutions are LISs that were proposed for ad hoc VCNs and the last three solutions are LISs for infrastructure-based VCNs. These solutions are studied from literature and we will describe them in next section.

Table 1 Comparison of LIS solutions in VCNs
Full size table

We have selected these solutions because they all cover our three main criteria for classification. All of them were published less than 4 years ago and they apply the latest knowledge of VCNs in their solutions. Also to the best of our knowledge these solutions are the most used approaches in VCNs. Three of these approaches are peer reviewed at the direction of IEEE Communications Society subject matter experts for publication in the IEEE ICC 2009, 2011 proceedings [38]. One approach has been published in the IEEE Transactions on Vehicular Technology which is a journal that is dedicated solely to vehicular technology [39]. Also one approach has been published in the international journal for the computer and telecommunications industry (computer communications) in the Elsevier [40].

4 Location information services for ad-hoc VCNs

When two vehicles exchange information in an ad-hoc VCNs such as VANET, position-based routing algorithms are used for this purpose but as a prerequisite to position-based algorithms, source vehicle first should obtains the geographic position of destination vehicle before communication start.

This task is done via LISs in VANET which helps the vehicles to convert destination vehicles’ IDs (address or name) to corresponding positions. Generally, the LIS for ad-hoc VCNs is responsible for collecting the location updates from vehicles and handling the location requests issued from vehicles that need to discover other destination vehicles. In this section we introduce 8 solutions for LISs in ad-hoc VCNs. We can see list of studied LIS solutions for VANET in Table 2.

Table 2 List of studied solutions for LIS in VANET
Full size table

4.1 Density aware Map-Based Location Service (DMBLS)

Density aware Map-Based Location Service (DMBLS) [16] employs the street digital maps and the traffic density information to determine a three level-hierarchy of locations servers. Also DMBLS is a distributed infrastructure-less LIS designed for vehicular networks in urban environments. They assume that each vehicle knows its own geographic position thanks to the use of GPS. Furthermore, they consider that vehicles are equipped with digital maps to obtain more information about the road topology and the paths along which they are moving.

In their approach location servers are vehicles located near some road intersections with a high traffic density. Also DMBLS is deployed in a similar way to MBLS [17]. The geographic area representing a given city is partitioned in a hierarchy of regions. The highest level region, level-3, covers the whole area. It is further divided into four lower level-2 regions which are subsequently divided down to the level-1 regions. By using this partitioning strategy, they offer to build a hierarchy of distributed location servers with one location server level-3 (L3) at the top for the entire area and location servers level-1 (L1) at the bottom to manage locally the small regions defined for the level-1. The location server L1 stores fresh geographic coordinates of the vehicles depending to the low level area. Whereas, the location servers L2 and L3 maintain the information about all the vehicles respectively belonging to the areas they have to operate.

DMBLS define a set of location cell (LC) centered on waypoints with high traffic density in various levels of the hierarchy. Waypoints are vertices, where roads intersect, indicated by geographic coordinates with unique ID. Each vehicle sends a location update every time it crosses a new waypoint and departs from one road segment to another.

Here is an example of how a source vehicle finds the location of a long-range vehicle through the hierarchy of location servers. When a source vehicle S needs to communicate with a vehicle D out of its transmission range, it begins a location query to obtain its location. A query packet includes the source’s identifier, its position and the searched destination’s identifier. Any vehicle available within the cell which takes the request and has the location information in its cache forwards a response to the asking vehicle. An example of this process is represented in Fig. 3.

Fig. 3
figure 3

Location updates and queries in DMBLS

Full size image

In Fig. 3 vehicle S wants to find the location information of destination vehicle D. S sends a query to its corresponding location server at level-1 area which is placed at the waypoint w1. Any vehicle nearer to that waypoint, when obtaining the query, it probes for D’s location information in its database. However, since the vehicle D is located in a various level-2 area, the request is sent to the subsequent upper level and then to the highest level. Once the location server at level-3 located receives the query packet, it searches D’s identifier and finds out that D is placed at the lowest-level area and it is traveling between waypoints w9 and w10. A response packet including the geographic location of the destination and its speed is sent back to the source vehicle. Once the source vehicle S captures the response, it computes the current location of the D and maintains the location information for a period equal to the approximate time taken by the destination vehicle to cross the next waypoint.

DMBLS is a good solution for local communications because search request traverse only few hops to attain favorable location server. But if distances between the waypoints are mainly long then vehicles do not send location update for a long time that causes degrade in location accuracy and query success rate.

4.2 Map Based Location Service (MBLS)

Map Based Location Service (MBLS) [17] makes use of the street digital maps and the geographic data file to define a three level-hierarchy of locations servers. Also MBLS is a distributed infrastructure-less LIS designed for VANET so that the entire geographic area is partitioned into a hierarchy of squares wherein a waypoint is selected in each square to be the position of the location server. The highest level square (level-3) covers the whole area and it is also divided into four lower level-2 squares which are subsequently divided down to level-1 squares.

MBLS uses a predefined hash function to map each vehicle identifier to a corresponding waypoint at each level of the hierarchy. Then the closest vehicle to the selected waypoint will act as a location server and hold the location information. Location servers for a specific vehicle will exchange information in the direction of level-1 to level-3 to synchronize their database. This exchange will be sent in unicast way. The dividing of the area in a hierarchical formation assists in placing the location server in distributed way.

The MBLS applies navigation system by using Geographical Data File (GDF) from the digital-map database to obtain waypoints for choosing location server by mapping vehicle’s ID with waypoint and for sending location update while transit over the waypoints. Vehicles also use navigation system for specifying the path to the destination location. Location updates forwarded to location servers should be moderated between network load and information accuracy. To do this, MBLS exploits a strategy using map-based navigation system. MBLS utilizes the GDF from the digital map database of navigation system to obtain geographic path indicated by a sequence of waypoints to be traveled by the vehicle to reach its destination.

Location updates are forwarded only when vehicle passes a waypoint, where the vehicle travels to a new segment. Therefore, location information is represented as RECORD (Wi, Wj, S, D, Ts), where Wi, Wj, are waypoint’s IDs between which the vehicle is traveling, S is the speed (m/s) and D is direction in which the vehicle is moving and finally Ts indicates the timestamp (s) when the update is sent. To clarify the update process in MBLS, Fig. 4 is given below:

Fig. 4
figure 4

Distribution of waypoints and update process in MBLS

Full size image

In Fig. 4, vehicle D is traveling between waypoints W5 and W6 in the direction of W7 at speed equal to 50 m/s. Vehicle D forwards an update RECORD (W5, W6, 50, W7, 60.7) to its location server at level-1 when it passed W5 at time 60.7 s. So, D will transmit next update only when it passes the next waypoint (i.e., W6), where it changes the segment. After the obtaining of an update message by the location server at level-1, it then forwards the record to the next location server existent in level-2 square. The same way is followed by the location server at level-2 in order to the location server present in the level-3 square is updated.

The hierarchical distribution of location servers assist in improvement of query success ratio but the random selection of waypoints does not guarantee having vehicles available there to maintain the location information also it does not ensure the proximity of location servers in the hierarchy which causes increasing in update delay.

4.3 Responsible Sections Location Service (RSLS)

Responsible Sections Location Service (RSLS) [18] makes use of the street digital maps to define a distributed with hash-based data structure of locations servers. Also RSLS is an infrastructure-less LIS designed for VANET that is based on responsible sections (RS). The RS is a small circular region which is a crossroad or a bus stop in the city. In such areas vehicles are always moving with low speed or they are stopped, the possibility that no vehicle in one RS is very small. They choose vehicles placing in a RS to act as location servers to maintain vehicle’s positions and response to the position search requests. With the distributed hash-based RS selection algorithm, the related RSs of a vehicle can be specified by some arithmetic operations. RSLS considers that each vehicle can obtain its latest position via GPS receiver and have information of locations and names of all the RSs via digital maps. A vehicle acts as location servers only if it is placing in an RS.

The location update action is operated by the vehicle when (1) it has traveled higher than a threshold d or (2) a constant duration T (20 s) elapsed since last update time. When a vehicle begins to update its location, it produces packets with its current position forwarding to the regions of all its related RSs. When obtains a location update packet, the vehicle residing in corresponding RS of the updating vehicle, updates the determined record of its stored position table. The mediator vehicle also stores the latest position of the updating vehicle for a short time after sending the location updating packet.

When vehicle S desires to communicate with D, S must realize the position of the destination by sending query packet to the location servers of D. Firstly, S determines the set of RSs of D and then it chooses the closest responsible section W from the set. S forwards the position query of D to vehicles placing in W. Once location server in W obtains the querying request packet, it sends back the position of D to S. Another two kinds of vehicles can also response to the query: vehicle D itself and vehicles which know D’s position consisting those sent D’s location update packet a moment ago and those just move out of the target responsible section. If the requesting vehicle does not get the response from location servers during the wait timer, it attempts to forward location query to the next RS.

The process of location update in RSLS that a vehicle sends the location information to all its related RSs, improves query success rate but this mechanism suffers from high control packet overhead because lots of update packets will be produced every time a vehicle updates its location servers.

4.4 Vehicle Location Service (VLS)

In Vehicle Location Service (VLS) [8] network is partitioned into small regions also with the aim of digital maps, distributed location servers are constructed. VLS is an infrastructure-less and hash-based LIS which is designed for VANET and used in metropolitan environments. It attempts to avoid choosing servers in empty regions and it employs forwarding trees and adaptive update policies to decrease location update cost. A set of urban streets are selected also each street in divided into small road segment which form a cluster and the nearest vehicle to the center of a segment or slowest vehicle in that segment assumes to be the cluster header which may act as a location server for a given duration.

In VLS entire city is assumed to be rectangular and area is divided to M*N small regions which every vehicle has a corresponding location server in each region. All vehicles have the same algorithm to select location servers and they can obtain location server list of any vehicle according to its ID. They show that with increasing the number of regions, segmented by M*N, location update cost will be increased because more location servers require to update while in other hand, location query delay reduces because location discovery may be processed by one closer location server.

Dividing the network into some regions and recruiting a location server in each region improve reliability of this protocol because all these distributed servers have location information about a vehicle but at the other side, this mechanism suffers from lots of redundant control packet overhead which propagate in the network.

4.5 Region-based Location-Service-Management Protocol (RLSMP)

Region-based Location Service Management Protocol (RLSMP) [19] is a hierarchical distributed and infrastructure-less LIS that attempts to be scalable by employing message aggregation in location updating and in querying and can be used in VANET applications. Network area is divided into some clusters and each cluster consists of some cells. Each cell has a specific vehicle called a cell leader (CL) that is responsible for gathering the location information about all vehicles within the cell. Vehicles that are physically placed in the central cell of one cluster are responsible for maintaining current location information about all vehicles that belong to that cluster. This central cell is called the location service cell (LSC). Thus, the location information is locally kept inside one cluster.

The CL gathers the location information about all the vehicles in its cell and sends the gathered control message to the LSC of its cluster. Each CL maintains detailed information about the vehicles that it manages. This information includes the vehicle ID, the coordinates of the vehicle’s location, the time of the last update, and the velocity and direction of the vehicle’s movement. Then, a gathered location message is sent to the LSC containing the summarized information about the vehicles in the cell. Figure 5 shows a grid of 4 clusters, so that each cluster consists of 25 cells. LSCs are specified with grid lines.

Fig. 5
figure 5

Clusters and cells in RLSMP

Full size image

Update operation is performed whenever the vehicle travels a distance D from its current location, where D relates to the transmission range of the vehicle. All vehicles locating in the central cell element will then get these messages and can act as CLs. Because of locality awareness property of VANET, location servers are determined based on local traffic patterns considerations and RLSMP uses a spiral shape for location query when destination and source vehicle are not in a same cluster, then explore the source vehicles’ neighborhood since the destination search starts in clusters surrounding the local cluster of the source vehicles until it discovers information about locations of the destination.

RLSMP has locality-aware feature which means it has the ability to support local traffic patterns within the network, thereby it increases query success rate for local requests. CLs aggregate and forward location information messages in a spiral shape until it reaches the related LSCs. In addition, LSCs route DATA packets based on these messages but this location information may potentially be stale because of mentioned aggregation mechanism hence, due to unreachable destination vehicles, packet drops increases in the network.

4.6 Modified Region-based Location-Service-Management Protocol (MRLSMP)

Modified Region based Location Service Management Protocol (MRLSMP) [20] is a hierarchical distributed LIS which integrates the V2V and V2I communications and uses the location of vehicles as a criterion for constructing geographical clusters. That is, each vehicle automatically specifies its geographical cluster while traveling by mapping its GPS location into coordinates in the network. Cluster and cell definitions are same to RLSMP as Fig. 5. MRLSMP uses the road infrastructure (i.e., RSU) as location servers. Central cell of each cluster is the possible position for a RSU which is responsible for maintaining the current location of all the vehicles in that cluster as well as replying the queries about the vehicles location information.

In MRLSMP, the location updating includes two terms. The first term is about the messages forwarded by the vehicles to the cell leader (CL) that is responsible for gathering the location information about all the vehicles within the cell in order to update their locations. The second term is related to the updates forwarded from the CLs to the local RSU in order to update the location information of the vehicles that locate in that cluster. Location updates and querying messages are gathered using a tree structure and this aggregated location information are sent to the RSU as a root. MRLSMP define two kinds of query: 1) Local query that both the source and destination vehicles are registered in the same cluster and this query is replied by the local RSU. 2) Global query that the destination is not located in the local cluster where the source vehicle resides. In global queries the query messages are not sent directly. Instead, the messages are postponed for a pre- determined time. This delay is necessary for gathering queries which are forwarded by vehicles locating in that cluster. The gathered queries are sent pass through the different RSUs as shown in Fig. 6. The gathered querying messages are sent in a spiral around the local RSU where this spiral meets all surrounding RSUs until it discovers information about locations of the destinations. The different RSUs will make use of the information stored in their own tables to find the requested destinations’ IDs.

Fig. 6
figure 6

Spiral shape of the location information retrieval in MRLSMP

Full size image

Make use of RSUs in MRLSMP as location servers instead of vehicles in RLSMP, increase reliability of this LIS and eliminate LSC handoff overhead of RLSMP because when a vehicle is about to leave the central cell of a cluster in RLSMP, has to choose another vehicle and sends all the location information of that cluster to the chosen vehicle but these kinds of overhead do not occur in MRLSMP. On the other hand, if a vehicle moves from one cell to another in the middle of an RSU updating interval, the location query service will be unsuccessful in giving appropriate response to the query looking for that vehicle and hence, query success rate of this LIS will be declined.

4.7 Mobile Group based Location Service Management (MG-LSM)

The Mobile Group based Location Service Management (MG-LSM) [21] is a hierarchical distributed and infrastructure-less LIS that vehicles in neighborhood traveling to the same direction are dynamically organized into a group and one of the vehicles in the group, tend to be the one placed in the center of the group, become the group leader (GL). In MG-LSM network is divided into the regions, and each region is provided with a fixed location server, called region head (RH). The GL gathers and saves the exact location information of the vehicles in its group and updates the RH about the alterations in the group membership whenever they happen. The RH keeps the information reported by the GLs that are placed within its region, and replies to the location queries from the member vehicles of those GLs. Figure 7 illustrates an example of the groups and the regions for the MG-LSM.

Fig. 7
figure 7

Example of the groups and the regions in MG-LSM

Full size image

The GL of each group periodically broadcasts the GL advertisement. For the non-member vehicles, the GL advertisement message is applied for the group joining intention. Vehicles may realize the available GLs in their neighborhood through the GL advertisement messages. For the member vehicles of the corresponding group, the GL advertisement message is applied to certify the existence of the GL. While the vehicles stay in the group they send location update message to the GL periodically. If a member vehicle does not get the GL advertisement from its current GL for a specific number of times, it realizes that the group is no longer available, and also attempts to join another group in its neighborhood, if possible. If it cannot find one, it begins a new group on its own.

RH Updating mechanism occurs when there are some changes in the membership of GLs instead of periodically updates to RHs and hence, location management overhead of MG-LSM is declined in this way. On the other hand, since the membership changes have tendency to happen simultaneously at the traffic lights of intersections, network load increases in the junctions which subsequently causes high packet collisions in the network.

4.8 Intersection Location Service (ILS)

Intersection Location Service (ILS) [23] is a distributed LIS with hash-based data structure so that it has fault-tolerant methods for vehicular networks. Street intersection is the position of location servers. Location server for a specific intersection is one of the vehicles that are nearby the intersection and is variable over time as vehicles move. Every vehicle is hashed to associate with a location server and vehicles will update their own position to their location server when their position changes over the threshold. In ILS, the street intersections covered by the network are numbered from 0 to N. Each vehicle is dedicated a single location server, by hashing the vehicle’s unique identifier into an intersection identifier. Due to the highly dynamic nature of VANETs, it is probable that some intersections are vacant for certain durations. When location queries that are sent to temporarily vacant intersections will result in failures the Chord algorithm [43, 44] is applied for error recovery. Once a location server is specified for a given query, the query issued by a vehicle will be routed to the target location server.

Error recovery applied for unsuccessful location queries improves query success rate in ILS. On the other hand, dense of vehicles in street intersections is relatively high and recruiting location servers in every intersection incurs more network load and subsequently more packet collisions in these areas occurs specially when number of intersections for a fixed network size increases dramatically.

5 Location information services for infrastructure-based VCNs

In this section we describe three LISs that are used for infrastructure-based VCNs.

5.1 The region-based Hierarchical Location Service with Road-adapted Grids (HLSRG)

The region-based Hierarchical Location Service with Road-adapted Grids (HLSRG) [22] makes use of street digital maps to define hierarchical distributed location servers with hybrid network structure and divide the network into regions with three hierarchical levels. Location information is maintained in different region’s size of these levels. For property of locality aware in vehicular networks, HLSRG gathers packet locally and divide area in a road-adapted grid partition. In a general region partition, network is divided into regions with longitude and latitude. As a result, the boundaries of regions may cut through buildings and shade trees. Therefore, the success rate of packets forwarding may reduce.

The basic idea of road-adapted grid partition method is to choose the main artery to divide the network area into regions, so that boundaries of each region are roads. In each level 1 region, HLSRG selects an intersection which is closest to the center of the region to be the level 1 region center. Region centers are significant, vehicles in region’s centers have to gather location update packets in their regions and forward the packets to their related upper level. HLSRG establishes RSUs to maintain the location information for upper level. RSUs can help data forwarding in level 2 and level 3 regions and the vehicles moving within a level 1 region’s center can maintain location update packets forwarded from other vehicles in this level. Network division in HLSRG is illustrated in Fig. 8. Four level 1 regions form a level 2 region and four level 2 regions form a level 3 region, any level 1 region can belongs to only one level 2 region and level 3 region respectively.

Fig. 8
figure 8

Area partitioning in HLSRG

Full size image

RSUs in each region of level 2 are wired connect to another RSU where is in their related level 3 region’s center. The RSUs in level 3 regions have to discover vehicles which are far from its location. Therefore, authors in [22] devise each of them is wired connect to another four by direction east, west south and north in the same level. In order to get location of all vehicles, they devise that vehicles have to forward a location update packet to the level 1 region’s center when crossing a region or turning right/left. As a result, each level 1 region’s center keeps location information locally. Packets are gathered in each region apart and then combined to the related upper level orderly. The RSU in the level 2 region gathers the packets forwarded from level 1 region to its own table, and forwards the table to its related level3 region periodically. In order to reduce load of information in network the level 2 RSUs only maintain vehicle’s ID, time, and sender (ID of level 1 grid) in the packet forwarded from level 1 region, and the level 3 RSUs maintain the sender (ID of level 2 RSU), vehicle’s ID and time in the packet forwarded from level 2 RSU. If a vehicle needs to communicate with another one but has no information about the location, the source vehicle just needs to forward a location query packet to its closest level center (the closest level center could be a level 1 region, level 2 region or level 3 region center). After forwarding the query packet, the source vehicle has to wait for affirmation forwarded from the destination vehicle and then begin to communicate.

The road-adapted grid partition method that they have proposed can decrease a lot of overhead packets by preventing most of vehicles from sending location information update packet frequently. Also they set up RSUs as location servers for upper levels of hierarchy that makes their approach more stable in a large area. On the other hand, make use of roadside infrastructures such as RSUs in HLSRG which are wired connect to each other increases deployment cost of this LIS.

5.2 Mobility Management for efficient Data Delivery (MMDD)

In [37] authors propose a Mobility Management scheme for effective Data Delivery (MMDD) in vehicular networks. It is a distributed and hybrid LMS with push-based, event-based and periodically message exchange pattern that improves the data transmission between base stations (BSs) and vehicles in V2I systems through multi hop communication. The communication between vehicles and base stations in MMDD consists of four basic processes: service advertisement, registration, location update and data delivery as shown in Fig. 9(b). Service advertisement lets base stations to broadcast their information within their service area by periodically broadcasting BEACON messages within their communication range.

Fig. 9
figure 9

a MMDD architecture b MMDD processes

Full size image

Therefore, vehicles can together have access to numerous base stations, and they specify the best available station (i.e., delay-efficient) to receive some services such as internet via registration process. This process is adopted from their recent work on location- and delay- aware protocol known as PROMPT [45]. Vehicles update the registered base station with their position information within the process of location update. They study two schemes for vehicle location update: time-based and distance-based. The location information available at base stations is finally used for data packet delivery.

In their approach, base stations are internet gateways installed at constant locations along the road, and they can communicate with each other through wired connections. Vehicles moving in the network are equipped with wireless devices (e.g., OBUs) to communicate with each other and also with base stations. Vehicles are also equipped with GPS that assist them specify their location information. MMDD architecture is shown in Fig. 9(a).

All communication such as registration and update processes from vehicles to roadside infrastructures is performed by PROMPT which is a delay-aware protocol and hence, it results in less average packet delay in their LIS. But make use of base stations in MMDD which are wired connect to each other increases deployment cost of this approach.

5.3 Hierarchical Content Delivery Network (CDN)

In [30] authors design a hierarchical distributed and infrastructure-based LIS and they propose the hierarchical Content Delivery Network (CDN) architecture to supply network scaling specifications for ITS content delivery. They assume that ITS content can be, broadly, classified into three categories: (1) traffic information such as congestions, speed levels and incidents; (2) warning/ safety messages; and (3) road-side information.

Their architecture employs the implications and mechanisms of service orientation to address the demands of vehicular networks. Their architecture also forms services based on vehicle’s location relevancy and permits the information to be maintained near to its related areas. They define algorithms and message structure used within the architecture to manage content services and deliver them to vehicles. Those algorithms consist of content service addition, updating, deletion, discovery, consumption and maintenance across different infrastructure nodes.

They concentrate on designing a system that improves the following needs: scalability, reliability, mobility management, location-based search and geo-casting. In their approach vehicles are able to search all available content relevant to an area of interest. Furthermore proposed system has to be able to forward determined content to all vehicles within a specific area. Architecture of CDN is illustrated in Fig. 10.

Fig. 10
figure 10

System architecture of CDN

Full size image

The geographic area of the road network is divided into neighbor but separate hexagonal clusters/cell. They consider that within each geographic area, an RSU with storage capability works (hierarchy level 0) and caches part of ITS content. There is a particular kind of RSU, called gateway (represent level 1 of the hierarchy) in their approach that permits integration with internet. At the next higher level in the hierarchy, every few geographic areas are grouped together into geographic domains. Each geographic domain is operated by a domain manager (hierarchy level 2) and is linked to the internet through one or more gateways.

A domain manager keeps valid replicas of ITS content and it is configured to keep parent node address, child nodes addresses and area covered by its children. Domain managers can be grouped together, recursively, where a level N domain manger operates a number of hierarchy level N-1 domain managers. This grouping hangs on in order to a rooted-hierarchy is created.

The CDN architecture employs network hierarchies to obtain network scaling features also domain managers bring content closer to vehicles, thereby reduce content delivery time. On the other hand, it costs too much for deployment of RSUs and gateways which are wired connected to application servers. Also CDN is inefficient to deliver services to vehicles whenever vehicular network is almost dense and inter vehicle separation is less than 20 meters. ITS services in vehicular networks are determined by ITS content and service time. Different ITS contents relate to different user-satisfaction functions. To achieve maximal user-satisfaction, authors in [48] have developed a distributed heterogeneous media-service method which jointly solves the content distribution and cache update problems for peer-to-peer (P2P)-based vehicular networks. In CDN authors do not take into account the differences among the multiple services also vehicle opportunistic meet and service time are not considered. Therefore, it is a good idea to adapt CDN with the scheme proposed in [48] and improve the user-satisfaction of this LIS.

6 Evaluation

To evaluate studied LISs first we need to explain some performance properties that are mostly used for evaluating LISs. Performance properties are set of desirable factors used to measure the overall performance of LISs that include these properties:

  1. 1.

    Delay Represents the total duration measured from the time a request is generated to the time the reply is received by the source vehicle.

  2. 2.

    Overhead The number of LIS packets that are transmitted between vehicles or between road infrastructure and vehicles.

  3. 3.

    Query Success Rate The percentage of queries which have been successfully replied by the LIS.

Another property is location accuracy which is dependent to overhead. To provide location accuracy vehicles need to update location servers more than before which increases overhead in network. Also location accuracy and vehicle’s speed are related to each other as the higher speed is the less location accuracy occurs. Query success rate is mainly dependent to vehicle’s speed and vehicle’s density. In the VANET scenario, scalability issues [29] arise in several different contexts. The number of active vehicles has an impact on network connectivity and on the likelihood of congestion on the wireless channel. In addition, protocol design has a great impact on scalability. The most crucial bottleneck is the bandwidth limitation. We will discuss about performance properties of studied LISs based on their simulation results.

6.1 Density aware Map-Based Location Service (DMBLS)

They compare their approach with MBLS based on two factors: query success rate and request-to-reply delay.

  1. 1.

    Delay The maximum request-to-reply delay for a density of 300 vehicles moving with different speeds and network size of 2.4 km2 is found to be less than 70 ms that achieves an improvement compared to the MBLS for which an average value of 112 ms is observed.

  2. 2.

    Query success rate Their simulation result shows the query success ratio of DMBLS around 85 % at different velocity of 36, 72 and 108 km/h and for different vehicle’s density. The success rate increases with the network size since more vehicles can act as location servers in each level when the vehicle’s density is high.

6.2 Map Based Location Service (MBLS)

  1. 1.

    Delay The average request-to-reply delay for number of 200 vehicles moving at an average speed of 72 km/h in network size of 2.5 km2 is 112 ms.

  2. 2.

    Overhead The number of update’s record sent by the vehicle moving at an average speed of 72 km/h in network size of 2.5 km2 is found to be 15 packets for travelling a stretch of 2,000 m. The average number of requests which the source vehicle sends in the simulation is found to be 12 packets and also the number of reply packet received is 4.

  3. 3.

    Query success rate The query success ratio of MBLS varies from 86 % at velocity of 36 km/h to 58.92 % at velocity of 216 km/h for 200 vehicles in network size of 2.5 km2. Also the query success ratio is 67.3 % when number of vehicles are 150. The query success ratio increases to 85.18 % for 200 vehicles. Based on their simulation result, when vehicle’s speed increases, query success rate decreases furthermore as vehicle’s density increases gradually, the query success ratio slightly reduced mainly because of the packet loss occurring due to network congestion as the beacon signal traffic in the network increases.

6.3 Responsible Sections Location Service (RSLS)

  1. 1.

    Query success rate The query success rate of RSLS with the total number of 500 vehicles decreases from 88 to 78 % when vehicles speed up from 54 to 162 km/h. The query success rate of RSLS increases from 68 to 81 % with increasing the density of vehicles from 300 to 500 vehicles, when the maximum velocity is 90 km/h. It is because more and more vehicles can act as potential location servers and the failures of packet forwarding decrease.

6.4 Vehicle Location Service (VLS)

  1. 1.

    Delay When vehicle’s density is 500/km2, delay increases from 10 to 40 hops as network size grows from 2,000 m to 10,000 m.

  2. 2.

    Query success rate The query success rate of VLS with 500 vehicles per km2 decreases from 98 to 95 % when the side length of whole area varies from 2,000 m to 10,000 m, because VLS only chooses location servers from the cluster headers in street segments, so the probability of query invalidation decreases, especially in dense network.

6.5 Region-based Location Service Management Protocol (RLSMP)

  1. 1.

    Delay The average request to response delay when network size varies from 20 to 590 km2 with the number of 8 vehicles per km2 increases from 2 to 20 ms.

  2. 2.

    Overhead Total communication overhead when network size varies from 20 to 590 km2 with the number of 8 vehicles per km2 increases from 65 to 190 bytes. In order to reduce the location update overhead, RLSMP proposes that the CL should accumulate the location update information from the vehicles for a certain length of time instead of delivering them immediately to the LSC. Even though it may reduce the location update overhead, it results in inaccuracy for the location information maintained by LSC.

6.6 Modified Region-based Location-Service-Management Protocol (MRLSMP)

  1. 1.

    Overhead Total communication overhead when network size varies from 20 to 590 km2 with the number of 8 vehicles per km2 increases from 60 to 200 bytes.

6.7 Mobile Group based Location Service Management (MG-LSM)

  1. 1.

    Overhead They compared MG-LSM with RLSMP and MRLSMP and the simulation results show that the overhead of MG-LSM is the least among the three. Overhead of the MG-LSM and the RLSMP are approximately same together. When network size is 100 km2 and vehicle’s speed is between 36 to 40 km/h also number of vehicles in the system are 2,400, the location management overhead of MG-LSM is about 55*105 bytes.

  2. 2.

    Query success rate Based on their simulation results, when network size is 100 km2 and vehicle’s speed is between 36 to 40 km/h the percentage of successfully answered queries of MG-LSM is 96.67 % while query success rate of RLSMP is 83.34 % and in this case overhead of RLSMP is more than twice of MG-LSM’s overhead.

6.8 Intersection Location Service (ILS)

  1. 1.

    Query success rate The percentage of successfully answered queries of ILS with vehicle density of 99 per km2 and mean velocity of 144 km/h for velocity deviation of 18 km/h, decreases from 92 to 85 % when area size varies from 0.9 to 3.5 km2. Also query success rate in area size of 1.8 km2 with 320 vehicles reduces from 90 to 85 % when vehicle’s velocity increases from 36 to 144 km/h.

6.9 The region-based Hierarchical Location Service with Road-adapted Grids (HLSRG)

  1. 1.

    Delay When network size is 2 km2 and the number of vehicles varies from 300 to 600 whereas their speed is between 0 to 60 km/h, average request response delay of HLSRG is about 0.75 s. The HLSRG has less delay than the RLSMP because the RSUs help the HLSRG to forward packet for a long distance directly but the RLSMP has to forward a query packet with spiral shape around LSCs and costs more time than the HLSRG.

  2. 2.

    Overhead They have compared performance of HLSRG with RLSMP. When network size is 2 km2 and there are 500 vehicles with speeds between 0 to 60 km/h, simulation results show that communication overhead of HLSRG is about 4,300 packets. In more detail, the HLSRG location update overhead is half of RLSMP. Also HLSRG reduces location query overhead up to 15 % of RLSMP. Then, HLSRG reduces overhead up to 65 % of RLSMP. The main reason for this improvement is road-adapted grid partitioning in HLSRG.

  3. 3.

    Query success rate When network size is 2 km2 and number of vehicles varies from 300 to 600 whereas their speed is between 0 to 60 km/h then query success rate of HLSRG is about 95 % while this rate for RLSMP is 90 %. In RLSMP, when a source vehicle needs location information of destination, sends a location query packet to its corresponding LSC. If the LSC has no destination information, it has to wait and aggregate query packets for a specific waiting time. After waiting, the LSC will send the aggregated query packets to others LSC with spiral shape around LSC. Because of the spiral shape routing of LSC-Query cause location information overdue, the query may fail. In HLSRG, the location update/query packets are sent to level center immediately, and the RSU can help the HLSRG for data transmission. Therefore, the HLSRG has higher query success rate.

6.10 Mobility Management for efficient Data Delivery (MMDD)

Authors in [37] consider an urban road network of size 2.4 km2, in which each road has two lanes running in opposite directions. They randomly place 440 vehicles over the entire network. Vehicle’s speeds are selected randomly from a Gaussian distribution with mean 36 km/h and standard deviation of 5 km/h. Through a simulation study, they showed that MMDD approach is light-weight in terms of control packet overhead and it outperforms RLSMP, both in terms of delay performance and query success rate.

  1. 1.

    Delay When 440 vehicles with mean velocity of 36 km/h and standard deviation of 5 km/h travel in network size of 2.4 km2, average packet delay increases from 15 to 30 ms while location update interval varies from 10 to 50 s.

  2. 2.

    Overhead When 440 vehicles with mean velocity of 36 km/h and standard deviation of 5 km/h travel in network size of 2.4 km2, average number of control overhead decreases from 3,456 packet to 1,475 packet while update interval varies from 10 to 50 s.

  3. 3.

    Query success rate When 440 vehicles with mean velocity of 36 km/h and standard deviation of 5 km/h travel in network size of 2.4 km2, the percentage of successfully answered queries decreases from 96 to 93 % while location update interval varies from 10 to 50 s.

6.11 Hierarchical Content Delivery Network (CDN)

At lower vehicle density the CDN architecture performs very well meeting the requirements of on-the-road vehicles. But as the vehicle density gets higher (20 meters of inter-vehicle separation) the more the failure rate of vehicles trying to associate with the architecture infrastructure and this directly affects the ability of the infrastructure to deliver services to vehicles. Also for medium vehicle speeds the architecture delivers content services efficiently, however, as the vehicle’s speed increases, the more frequent the mobility management process, which negatively affects the performance of the CDN architecture.

  1. 1.

    Overhead The percentage of overhead is higher for smaller vehicle separation distances. This is due to a larger number of vehicles attempting to associate with and RSU which may forbid majority of vehicles from associating with the RSU. This is not the case for higher vehicle separation distances and consequently the overhead percentage decreases. For vehicle separation distance greater than 40 meters, the overhead percentage remains around the same range. In general when 30 vehicles with speed of 100 km/h travel within a road segment of 6 km and vehicle separation distance increases from 10 to 40 m then overhead percentage decrease from 16 to 13.5 % and for vehicle separation distance greater than 40 m, the overhead percentage remains around the same range of 13.5 %.

  2. 2.

    Query success rate When 30 vehicles with speed of 100 km/h travel within a road segment of 6 km, as the vehicle separation distance increases (above 50 m), the number of vehicles trying to associate with one RSU becomes low enough to maintain the total number of possible services delivered to vehicles and query success rate is approximately 100 %. This is not the case for lower vehicle separation distances. For vehicle separation distance equals to 20 meters the difference in the total number of services delivered to vehicles changes significantly as some vehicles are prevented association with RSU while others can associate and query success rate is approximately 70 % for vehicle separation distance of 20 meters also this value is around 20 % for separation distance of 10 meters. As the speed of the vehicle increases, the number of services delivered to each vehicle decrease. For higher speeds, the time a vehicle spends in proximity of an RSU is too low to deliver a complete service and this causes higher percentages of services interruption and requires more frequent mobility management. Table 3 in next page summarizes performance properties of studied LISs.

    Table 3 Performance properties of LIS solutions in VCNs
    Full size table

7 Conclusion

In this paper first we described a general environment of VCNs and explained how VCNs are build up. Ad-hoc VCN is a good approach where there is no pre-installed infrastructure such as RSU hence, OBUs equipped in the vehicles act as client and server to provide applications in these networks, so developing these networks is cheaper than infrastructure-based VCNs but it suffers from reliability in dense areas where desired information cannot reach to the destination’s OBUs and frequently disconnection occurs.

Furthermore, we presented fundamentals of LISs in VCNs and defined classification criteria for LISs also we distinguished studied LISs for ad-hoc VCNs and infrastructure-based VCNs, then we introduced how these solutions work. Our classification is based on three main criteria: location server structure, network structure and message exchange pattern. Location server structure defines the mechanism that location information of vehicles are stored, network structure represents type of communication in vehicular network and finally message exchange patterns are some methods for information gathering, scheduling, and dissemination moreover, they define the factors that contribute in triggering an update event.

After defining classification criteria we compared these literature’s LISs based on our introduced classification. LIS for ad-hoc VCNs is responsible for collecting the location updates from vehicles that are sending their current positions and handle the location requests issued from vehicles that need to discover other destination vehicles. Beside usefulness of LISs for ad hoc VCNs, it plays an important role in infrastructure-based VCNs. LISs improve some applications (e.g., mobility aware forwarding and handoff mechanism) in infrastructure-based VCNs. Finally we defined three performance criteria: Delay, Overhead and Query success rate and we evaluated mentioned LISs based on these criteria.