Performance Evaluation of Location-Based Service Discovery ...

This full text paper was peer reviewed at the direction of IEEE Communications Society subject matter experts for publication in the IEEE ICC 2010 proceedings

Performance Evaluation of Location-based Service Discovery Protocols for Vehicular Networks∗ Kaouther Abrougui Richard Werner Nelem Pazzi Azzedine Boukerche PARADISE Research Laboratory, SITE university of Ottawa Email:{abrougui, rwerner, boukerch}@site.uottawa.ca

Abstract— A considerable number of Vehicular Network (VN) applications have been developed recently. These applications range from security and safety to traffic information and service location. However, several research challenges remain open concerning efficient service discovery in large scale VNs. Most of the existing service discovery strategies present high overhead and poor performance when applied to VNs. Furthermore, existing context-aware and location-based service discovery protocols are either designed without considering the particularities of VNs or are not scalable with the increase of network density and number of requests. In this paper, we present novel context-aware and location-based service discovery protocols (Election-Based LocVSDP and Naive LocVSDP) that offer a scalable framework for the discovery of time-sensitive and location based services in large scale VNs. We conduct a concrete set of simulation experiments to evaluate the performance of our techniques and compare the results with an existing location-based discovery protocol (VITP). Simulation results indicate that our techniques outperform the VITP protocol in terms of success rate, average response time and bandwidth usage. In essence, both LocVSDP protocols show a gain of 20 percent in terms of success rate, use at least 90 percent less bandwidth than VITP and their average response time is at least 10 percent lower than VITP for successful query transactions.

I. I NTRODUCTION Vehicular networks have gained special attention from the research community. Security and safety; and traffic information and service location applications are two commonly known types of applications in Vehicular Networks. The former applications deal with the enhancement of vehicle safety on roads, while the latter help provide services to passengers in their vehicles, such as entertainment or localization services. Service discovery is a crucial challenge in such Vehicular Networks. Few existing projects in mobile ad hoc networks and vehicular networks have focused on proposing context-aware service discovery protocols [1]–[13]. Only few distributed location-based service discovery protocols have been designed with the characteristics of vehicular networks in mind [10], [11]. These protocols are designed for location-based service discovery in vehicular networks. They are designed for high speed type of networks as opposed to protocols cited in [1]–[3], they do not rely on service code migration as opposed to protocols cited in [4]–[6], and they are distributed and self-configurable as opposed to protocols cited in [7]–[9]. The main drawback of these protocols [10], [11] is their limited scalability in highly dense vehicular networks with a large number of service requests due to their infrastructure-less architecture. In our previous work [14], we have proposed a scalable locationaided gateway advertisement and discovery protocol for Vanets. The protocol in [14] does not rely on any infrastructure and the gateway ∗This work is partially supported by Canada Research Chair Program, NSERC, Ontario Distinguished Research Award Program, PREA/ Early Research Award, and OIT/MRI fund.

advertisement is location-aided and depends from gateway requesters locations. As opposed to this one, in this paper, we present efficient infrastructure-based context-aware and location-based service discovery protocols for vehicular networks (Election-Based and Naive LocVSDPs). The protocols infrastructure relies on wireless roadside routers distributed uniformly in the VN. Our protocols provide a scalable framework for the discovery of time-sensitive and locationbased services in a vehicular network. They help drivers to find services located in a desired region of interest, such as restaurants with their menus or gas stations with their price lists located close to the driver’s destination. For this purpose, the driver specifies the region of interest where he wants to find a service and a service request is propagated to the desired region of interest. The main features of LocVSDPs are: integrated into the network layer; they use channel diversity; and they find efficiently services located in the area specified in a driver’s request. Our protocols find the service provider and their routing information simultaneously which results in overall bandwidth savings. They use diverse channels to exchange discovery and routing packets, thereby decreasing the congestion on single channels and decreasing the delay of service discovery. Our locationbased service discovery protocols find services located in a region of interest specified in the driver’s request using an efficient locationbased propagation of the request and an efficient computation of the service reply. The remainder of this paper is organized as follows: Section 2 provides an overview of existing location-based service discovery protocols in vehicular networks. Section 3 presents a detailed description of our location-based service discovery techniques: the ElectionBased LocVSDP and the Naive LocVSDP. Section 4 presents the performance evaluation study of our protocols and their comparison to a related work. Section 4 concludes the paper.

II. R ELATED W ORKS Location-based service discovery protocols can be seen as contextaware service discovery protocols where the location is the main attribute to define the context. Few existing projects in mobile ad hoc networks have focused on proposing context-aware services [1]– [3]. In [1], Wu et al. proposed the Sentient Model. Their model uses a large collection of software components called Sentient Objects to abstract context-aware applications in ad hoc environment. In [2], Sivaharan et al. used the Sentient Objects to build sentient vehicles. These latter are context-aware vehicles communicating through the mobile ad hoc network. In [3] Julien et al. proposed the EgoSpaces model. In their model, the authors used data structures to store context aware resources available in the ad hoc network. Their model is based on agents: logical mobile agents operating over the physical mobile hosts. None of these context-aware service discovery were designed with the particularities of vehicular networks in mind. A few number of recent works in ad hoc and vehicular networks have focused on migratory services in order to accomplish the locationawareness in their protocols [4]–[6]. In these protocols, the service code has to migrate from one node to another for context-awareness purpose. Some recent projects have tried to deploy real services over mobile

978-1-4244-6404-3/10/$26.00 ©2010 IEEE


ad hoc and vehicular networks [7]–[9]. CarTel [7], is a mobile sensor computing system comprised of CarTel nodes; in an automotive context, nodes are automobiles. MetroSense [8], proposes a threetier architecture. It consists of a scalable architecture to support concurrent people-centric applications. UrbanSensing [9], seeks to settle technological approaches for using embedded and mobile sensing for the benefit of the community. These proposals are centralized architecture-based service discovery protocols and are easy to deploy and manage. They are also considered scalable. However, their scalability is valid only for restricted number of services. In addition, they are not self-configurable and they need constant maintenance to support new types of services. Moreover, the central point in this kind of architecture is a single point of failure. Finally, they require internet access or a reliable connection between the different components of the system for proper functioning. Only few distributed location-based service discovery protocols have been designed with the characteristics of vehicular networks in mind and without service code migration [10], [11]. In [11], Klimin et al. proposed a hybrid service discovery protocol in ad hoc vehicular networks. Their approach combines the proactive dissemination of advertisement messages and the reactive propagation of discovery requests. Dikaiakos et al. proposed in [10] location-aware services over vehicular ad hoc networks using car-to-car communication: Their protocol provides time-sensitive information about the traffic conditions and the available services on the roadside. They designed the Vehicular Information Transfer Protocol (VITP) for distributed services over a vehicular network. Protocols proposed in [10], [11] are designed for location-based service discovery in vehicular networks. They are designed for high speed type of networks as opposed to protocols cited in [1]–[3], they do not rely on service code migration as opposed to protocols cited in [4]–[6], and they are distributed and self-configurable as opposed to protocols cited in [7]–[9]. The main drawback of these protocols [10], [11] is their limited scalability in highly dense vehicular networks with a large number of service requests. In fact, these protocols are completely distributed and do not rely on any infrastructure. It is easy to think that a completely distributed service discovery protocol in vehicular networks that does not rely on any infrastructure is more efficient than protocols that rely on an infrastructure due to the high mobility of vehicles. However, we believe that an efficiently designed infrastructure-based service discovery protocol that considers the particularities of VN and the services provided, could improve the performance of a discovery protocol in large scale VN. For this purpose, we propose in this paper efficient locationbased infrastructure-based service discovery protocols for VN. Our protocols target mainly fixed services (the location of the service provider is fixed over the time).

III. P ROTOCOLS D ESCRIPTION In this section, we present our Location-based Vehicular Service Discovery Protocols: the Election-Based LocVSDP and the Naive LocVSDP. Our protocols are specially designed to find services located in a predetermined region specified by the driver: the region of interest. The main purpose of our protocols is to help drivers to locate services (such as restaurants with menus or gas stations with price lists) in a predetermined region. The framework on which we base our description is illustrated in Figure 1. The Election-Based LocVSDP can be divided into four separate phases: service advertisement, service request propagation, leader election and service reply generation, and service reply propagation.

A. Service advertisement phase Services advertise themselves by sending advertisement messages to the surrounding Roadside Routers. An advertisement message or a Location-based Vehicular Proactive Discovery (L − V P D) packet contains both routing information (source address, destination address, sender address, packet ID and time-to-live) and service information (packet type, service ID, service lifetime, service attributes

Fig. 1.

LocVSDP framework

and service location). An advertisement message or L−V P D packet is intercepted by the Integrated Modules of the neighboring roadside routers. In each Roadside Router, the Integrated Module that receives the service advertisement message or L − V P D packet separates the discovery information from the routing information. Discovery information is processed by the Service Module and the routing information is processed by the Routing Module. The Service Module adds the service information to its service table. If the service exists in the service table already, then the Service Module updates the information of the existing service. The Routing Module adds the routing information to its routing table. If the routing entry exists in the routing table already, then the Routing Module updates the routing information entry. In order to guarantee channel diversity, we assign an interface and a channel to every entry in the routing table such that messages are sent and received on diverse channels.

B. Service request propagation phase A driver generates a request for a service or a Location-based Vehicular Reactive Discovery (L − V RD) packet. In the service request, the user specifies the location where he wishes to find the service (the Region of Interest RI). The region of interest is specified by a disc area represented by the coordinates of the origin of the disc and the radius from the fixed origin. The L − V RD packet contains both routing information (source address, destination address, sender address, packet ID and time-to-live) and discovery information (packet type, requested service, service attributes, coordinates of the region of interest and the distance separating the sending node from the origin of the region of interest). The requester sends the service request L − V RD packet to the neighboring Roadside Routers. The neighboring roadside routers of the requesting vehicle receive the L − V RD packet and separate the service information from the routing information. The service information is processed by the service module and the routing information is handled by the routing module. For service request propagation, we implement a Location-aided Request Propagation mechanism for an efficient request propagation. Every Roadside Router that receives the service request or L − V RD packet determines through the location-aided request propagation mechanism whether it should forward the request or not in the following way: First, the Roadside Router checks whether it is inside the Region of Interest or not. If not, then the Roadside Router determines the distance that separates it from the origin of the region of interest. It compares this distance to the distance of the sending node received in the L − V RD packet. If the computed distance is shorter than the received distance, then the Roadside Router forwards the request message, otherwise, the request message is not forwarded. If the Roadside Router is inside the region of interest, then it forwards the service request and initiates a Leader Election process to elect a leader roadside router in the region of interest. The elected leader is the root of the computed spanning tree and is responsible for collecting local service replies from its children and for generating the reply message that will be sent to the requesting vehicle. We explain the leader election process and the local replies propagation in the next paragraph.


C. Leader election and service reply generation phase A leader roadside router is elected in the region of interest. This leader is responsible for generating the service reply and its propagation to the service requester. The reason from electing a leader in the region of interest is to avoid sending many service replies to the service requester. The leader sends an accurate reply to the service requester. A roadside router in the region of interest that receives a service request message starts the leader election process. It sets its current state to processing IDReq. We piggyback the ID of the request to the processing state because a roadside router can participate in many location-based service discovery processes. Then, the roadside router generates a leader election message election msg IDReq that contains the following information: its ID, distance to the origin of the region of interest, service provider of the requested service if its service table contains the requested service. The roadside router sends the election msg IDReq to its neighboring roadside routers. Any roadside router in the region of interest enters the processing IDReq state if one of the following events happen: (i) it receives a service request with the ID IDReq, or (ii) it receives an election msg IDReq. All the roadside routers in the processing IDReq state wait for a predetermined period of time P then they decide whether to enter the leader IDReq or the f ollower IDReq states. A roadside router decides to enter the leader IDReq state if and only if it has the minimum distance to the origin of the region of interest among its neighboring roadside routers. A roadside router decides to enter the f ollower IDReq state if and only if at least one of its neighboring roadside router has a shorter distance to the center of the region of interest than its distance to the center of the region of interest. A roadside router chooses its neighboring roadside router that has the minimum distance to the origin of the region of interest among its other neighbors as its parent (parent IDReq) in the spanning tree. At the end of the election process, a spanning tree including all the roadside routers in the region of interest is generated. The root of this spanning tree is the elected leader leader IDReq. After the construction of the spanning tree, the leaves send their replies to their corresponding parents. The local reply contains the service provider required by the service requester. The leader roadside router receives all the local replies from its children. After receiving all the local replies from its children. The leader generates a service reply message SRep msg and sends it to the requesting vehicle. The service reply contains either one service provider or multiple service providers depending from the request of the service requester. The service reply message includes the service providers located in the specified region of interest. This information will be cached by intermediate roadside routers during the service reply propagation phase. In our protocol, the election and the spanning tree construction processes are performed between roadside routers, which are assumed to be fixed and stable. Moreover, the election phase is executed for each service query. Thus, we do not need to maintain the elected leader and the constructed spanning tree after sending a service reply to the requester. Consequently, it is very rare that a leader becomes unavailable during a query processing. The discussion on the maintenance of the leader and the constructed spanning tree are out of the scope of this paper.

D. Service reply propagation phase In order to generate a reply message, a leader roadside router in the region of interest is elected as described in the previous section. This leader is responsible for solving the discovery query with the collaboration of other roadside routers in the region of interest, and responsible for generating the reply message and sending it to the requester. The integrated module of the leader roadside router generates the service reply message and sends it to the neighboring roadside router in the path to the requester vehicle. Every integrated module of an intermediate roadside router that receives the service reply separates the routing information from the service information.

The routing module determines the next hop in the path to the destination. The service module caches the service information in its service table. The service reply is propagated until it reaches the requesting vehicle.

E. Naive-LocVSDP We propose a naive version of LocVSDP by modifying the Leader election and service reply generation phase and the Service reply propagation phase. In Naive-LocVSDP, roadside routers in the region of interest specified in the driver request that receive a locationbased service request send directly their service replies to the service requester. Every roadside router in the region of interest that receives the location-based service request checks its service information table. If the requested service exists in the service table then a reply is sent back to the service requester with the provider information. If the service requested does not exist in the service information table. The roadside router sends a negative reply to the service requester.

F. Multi-channels and multi-interfaces LocVSDP In what follow, we shall explain how our LocVSDP protocol benefits from the channel diversity feature. Vehicular networks capacities and capabilities are improved when an efficient utilization of channels is taken into consideration. In our LocVSDP protocol we implement the multi-channels and multiinterfaces feature very simply and easily at the roadside routers. We assume that every roadside router is equipped with at least two interfaces (interface1 and interface2). Every interface uses a fixed channel different from the one used in the other interface of the same roadside router. In order to guarantee the connectivity in the vehicular network and to avoid channel switching costs, we assume that interface1 is set to the fixed channel1 and that interface2 is set to the fixed channel2. Thus the total number of channels is two. The usage of the different interfaces is handled at the routing module. This latter determines which interface is used for the propagation of LocVSDP message. We manage the usage of interfaces in such a way that sending and receiving messages are performed using different channels, which increases the bandwidth usage in the vehicular network.

IV. P ERFORMANCE EVALUATION In this section, we present the performance evaluation of the two versions of our location-based service discovery protocol (LocVSDP): the naive LocVSDP and the Election-Based LocVSDP. Then, we present the results of comparison of our protocols to the VITP protocol in a realistic traffic pattern. In the following we summarize the basic functionalities of VITP [10]. A VITP transaction consists of the following phases: the first one is a query phase. In this phase, the request is forwarded through intermediate vehicles to the targeted zone using a geographic routing. The intermediate vehicles could be non VITP-enabled. When the query reaches its targeted zone and is received by a VITP peer, the second phase, the computation phase, starts. In this phase, a VAHS is formed by the VITP peers to resolve the query. When a VAHS peer detects a predefined Return Condition, it generates a reply and sends it through the Vanet to the source road segment, from which the query was initiated using a geographic routing. This phase is the reply phase. In our simulation experiments, we varied the return condition from 1 to 10 service providers of the same service. As soon as the reply reaches the source road segment, VITP enters the last phase, which is the reply delivery phase. In this phase, the reply message is broadcast in the source segment. In the VITP protocol, the road is supposed to be divided in segments. The region of interest in VITP is defined as the coordinates of a starting point and predefined distance from the starting point. We have conducted an extensive set of experiments in the network simulator ns-2 [15]. In our experiments, we have varied the number of service requests from 10 to 100 requests.


We choose to evaluate the LocVSDP’s performance using mobility traces that correspond to realistic road-traffic pattern: highway traffic pattern. In this traffic pattern, vehicles move along a highway and vehicles use LocVSDP for location-based service discovery. We have used TrafficGen [16], [17] to derive the mobility traces related to the highway traffic pattern. We compare our algorithms to the VITP protocol and discuss the obtained results. In our experiments, we want to prove that our LocVSDP protocols are scalable in a highly dense vehicular network and with the increasing number of requests. For this purpose, we generate 1 Km long (L=1Km) and 0.02 Km large (l=0.02 Km) highway with four straight lanes. We use 10 fixed roadside routers uniformly distributed along the highway. We model the arrival process to the highway as a poisson process with an arrival rate (4λ), which is equal to the network density × average speed S of the vehicles. The arrival rate is split equally between the four lanes. We assume the random variable N that defines the number of vehicles in a road section of surface x. The probability that there are n vehicles in a road section of surface (x) is given by: ( Sx 4λ)n −4λ x S e (1) n! As we mentioned earlier, our purpose is to prove the scalability of our protocols when the density of the VN is high and with increasing number of requests. Thus, we assume the service level D according to the traffic flow state for different densities in [18], where the network is uncongested but borders are unstable. Accordingly, we assume that the average network density in vehicles is 120 vehicles/Km and vehicles are moving with an average speed S of 70km/h (≈20m/s). The simulation time is set to 300 seconds. Consequently, we deduce the arrival rate (4λ) for our simulations (λ = λ(x) = N (x)Sl ), where 4x ∞ N (x) = n=1 nP [N (x) = n]. The traffic generator described in [16] provides the rules of movement for cars along the highway when they face obstacles or slower cars. In this scenario, we choose the 802.11 as wireless medium with a data transmission rate of 11Mbps and a transmission range of 200 meters. The received signal strength threshold is set to 200 meters. We use a modified version of the manual routing protocol proposed in [19] for communication between roadside routers in the wireless backbone and for communication between roadside routers and vehicles, where routes are generated in hop by hop basis and avoiding routing loops. In our simulation, we consider 10 service providers providing the same service and 40 service clients requesting the same service. When a vehicle enters in the highway, it chooses a random time to initiate its request. We set the radius of the region of interest to 300 meters in our simulations. 1) Experimental results: In this section, we report on simulation experiments and compare our algorithms to the VITP protocol using a highway traffic model. We use the simulation environment illustrated in table I. In the course of our experiments, we define the request number as the number of service queries sent by vehicle clients. we choose to evaluate the performance of our algorithm using the following metrics: • success rate which indicates the average fraction of successful service transactions; • average response time which indicates the average time of successful request transactions. It measures the elapsed time for getting a valid service reply in response to a service request sent by a vehicle. This metrics takes into account several factors such as transmission and message processing delay, just to mention few; and • bandwidth usage which measures bandwidth needed to satisfy the driver’s service requests. In the course of our experiments, we varied the number of service requests between 10 and 100 requests. Service requests initial time is generated randomly. The following experimental data were obtained by averaging several runs with an interval of confidence between 90P [N (x) = n] =

TABLE I S IMULATION ENVIRONMENT FOR THE HIGHWAY SCENARIO Parameter Name Wireless medium Data transmission rate Transmission range (meters) Received signal strength threshold (meters) Average vehicle’s Speed (meter/second) Simulation time(seconds) Simulation area (meter2 ) Average density (vehicles/Km) Roadside router number Clients’ number servers’ number Region of interest surface (meter2 )

Parameter Value 802.11 11Mbps 200 200 20 300 1000 × 20 = 20, 000 120 10 40 10 Π × 3002

95 percent. We used a different seed for every run. The results are summarized in graphs 2(a), 2(b) and 2(c). Let us now turn to our results. Figure 2(a) plots the success rate of our LocVSDP protocols and the VITP protocol when 10 service providers providing the requested service exist in the region of interest specified in the location-based service request queries. As we can see, our LocVSDP protocols outperform considerably the VITP protocol in terms of success rate. The naive LocVSDP achieves almost 100 percent as success rate in the discovery of at least 90 percent of the service providers in the requested region of interest. The election-based LocVSDP (EBLocVSDP) succeeds as well to find at least 90 percent of the service providers in the specified region of interest with a rate that exceeds 95 percent when the number of requests increases from 10 to 100. However, the VITP protocol achieves lower success rate than the LocVSDP protocols even when the return condition is set to one service provider. Thus, the VITP protocol achieves lower than 80 percent as success rate in the discovery of only 10 percent of service providers of the requested service in the desired region of interest. The success rate in VITP decreases considerably with the increase of the return condition. The main reason behind the high success rate in our election-based LocVSDP protocol is mainly due to the fact that a unique service reply is generated by the elected leader in the desired region of interest to be returned to the requesting vehicle. The main reason behind the high success rate of the naive LocVSDP protocol is that every router in the region of interest returns a reply to the service requester. The reply could contain either the service provider information or an indication that the roadside router does not have the requested service in its service table. Figure 2(b) plots the bandwidth usage of our LocVSDP protocols and the VITP protocol when 10 different service providers of the requested service exist in the desired region of interest. We notice that our LocVSDP protocols outperform greatly the VITP protocol with different return conditions in terms of bandwidth usage. We notice also that for all protocols, the bandwidth usage increases with the increase of the number of requests. For the VITP protocol, we notice that the bandwidth usage decreases with the increase of the return condition when 10 service providers exist in the requested region of interest. This decrease in the bandwidth usage is not due to the good performance of the VITP protocol with the increase of the return condition but it is due to the bad performance of VITP when we increase the return condition. In fact, we have shown in Figure 2(a) that the success rate of VITP decreases drastically with the increase of the return condition to reach almost 0 percent for a return condition equal to 10. As observed in the Figure 2(b), the bandwidth usage of VITP with different return conditions is considerably higher than our LocVSDP protocols when 10 service providers exist in the region of interest. There are many weaknesses and reasons that explain the high bandwidth usage in VITP. First, vehicles in the VITP protocol have to discover their neighbors for the good functioning of the algorithm. Thus, every vehicle has to send a neighbor discovery


140

1e+06

80

60

2 EB-LocVSDP Naive-LocVSDP VITP cnt=1 VITP cnt=3 VITP cnt=5 VITP cnt=7 VITP cnt=10

Average Response Time

Success Rate

100

Bandwidth usage

120

1.2e+06 EB-LocVSDP Naive-LocVSDP VITP cnt=1 VITP cnt=3 VITP cnt=5 VITP cnt=7 VITP cnt=10

800000

600000

400000

40

1

0.5

200000

20

0

0 10

20

30

40

50 60 Request number

70

80

90

100

(a) Success Rate Fig. 2.

1.5

EB-LocVSDP Naive-LocVSDP VITP cnt=1 VITP cnt=3 VITP cnt=5 VITP cnt=7 VITP cnt=10

0 10

20

30

40

50 60 70 Request number

(b) Bandwidth usage

80

90

100

10

20

30

40

50 60 Request number

70

80

90

100

(c) Average response time

Performance comparison of LocVSDP to VITP in a Highway traffic scenario

message every one second, which incurs a useless overhead in the Vanet. In our LocVSDP protocol, there is no need for neighbor discovery for the good functioning of our protocols. Second, the VITP protocol does not rely on any infrastructure to reduce the number of messages exchanged in large scale Vanets. Thus during the query phase and the reply phase in VITP, a large number of messages is exchanged that increases the bandwidth usage in the Vanet. In opposite, our LocVSDP protocols rely on a backbone comprising roadside routers that function as directories and reduce the number of messages exchanged in the Vanet. Third, the computation phase in VITP is not deterministic, and during the computation of a reply, a vehicle in the region of interest may receive the same computation message many times. However, in our EB-LocVSDP protocol, the construction of a spanning tree and the election of a unique leader break the ties and permit to generate a unique reply in a restricted time and with less messages exchanged. Moreover, in our naive-LocVSDP protocol every roadside router sends its reply to the requester. Since the number of roadside routers is much lower than the number of vehicles in the Vanet, our naive-LocVSDP does not incur so much overhead. Figure 2(c) plots the average response time of our LocVSDP protocols and the VITP protocol when 10 different service providers of the requested service exist in the desired region of interest. It shows that the average response time of successful transactions in our election-based LocVSDP protocol is in the order of 65 milliseconds for a number of requests ranging from 10 to 100. The naive version of LocVSDP achieves less than 7 milliseconds as average response time for a number of requests ranging from 10 to 100. We notice also that the average response time for a query transaction in the VITP protocol increases with the increase of the return condition for a return condition between 10 and 50 percent of the available service providers in the region of interest and for a number of requests ranging from 10 to 100. However, the average response time of VITP decreases for a return condition more than 70 percent of the available service providers in the region of interest. This is mainly related to the success rate which is very low for the latter case and is not significant for the response time computation. In summary, the average response time of our LocVSDP protocols outperform the VITP protocol. It is in the order of tens of milliseconds in our protocols and in the order of hundreds of milliseconds in VITP.

V. C ONCLUSION In this paper, we presented our efficient and scalable location-based service discovery protocols for vehicular networks (EB-LocVSDP and Naive-LocVSDP). Our LocVSDP protocols find efficiently services in the specific region of interest included in a driver request message. They are built on top of the network layer allowing to find the service provider and its routing information at the same time. Our protocols aim at reducing congestion on single channels through a channel diversity mechanism that uses multiple channels and multiple interfaces for the propagation of service requests and replies. We discussed the performance evaluation of our protocols with an

extensive set of simulation experiments and we compared them to the VITP protocol using a realistic traffic pattern. A comparison study of our schemes with the existing location-based service discovery protocol VITP [10] has shown that our techniques outperform greatly the VITP protocol in terms of success rate, average response time and bandwidth usage.

R EFERENCES [1] M. Wu et al., “Novel component middleware for building dependable sentient computing applications,” in ECOOP04 Workshop on Component-oriented approaches to Context-aware Systems, 2004. [2] T. Sivaharan et al., “Cooperating sentient vehicles for next generation automobiles,” in Proc. ACM/Usenix MobiSys Int’l Workshop Applications of Mobile Embedded Systems (WAMES’04), 2004. [3] C. Julien and G.C. Roman, “Active coordination in ad hoc networks,” Lecture notes in computer science, pp. 199–215, 2004. [4] O. Riva, T. Nadeem, C. Borcea, and L. Iftode, “Context-Aware Migratory Services in Ad Hoc Networks,” IEEE TRANSACTIONS ON MOBILE COMPUTING, pp. 1313–1328, 2007. [5] S. Dolev, S. Gilbert, N.A. Lynch, E. Schiller, A.A. Shvartsman, and J.L. Welch, “Virtual Mobile Nodes for Mobile Ad Hoc Networks,” LECTURE NOTES IN COMPUTER SCIENCE, pp. 230–244, 2004. [6] R. Handorean, R. Sen, G. Hackmann, and G.C. Roman, “Context aware session management for services in ad hoc networks,” in IEEE International Conference on Services Computing, 2005, pp. 113–120. [7] B. Hull et al., “CarTel: A Distributed Mobile Sensor Computing System,” in 4th ACM SenSys, Boulder, CO, 2006, pp. 125–138. [8] A.T. Campbell, S.B. Eisenman, N.D. Lane, E. Miluzzo, and R.A. Peterson, “People-centric urban sensing,” in Proceedings of the 2nd annual international workshop on Wireless internet. ACM Press New York, NY, USA, 2006, p. 18. [9] “Urban Sensing Project,” in research.cens.ucla.edu/ projects/2006/Systems/Urban Sensing/. [10] MD. Dikaiakos et al., “Location-Aware Services over Vehicular AdHoc Networks using Car-to-Car Communication,” Selected Areas in Communications, IEEE Journal on, vol. 25, no. 8, pp. 1590–1602, 2007. [11] N. Klimin et al., “A hybrid approach for location-based service discovery in vehicular ad hoc networks,” Proc. of WIT, 2004. [12] A. Boukerche, “Handbook of Algorithms for Wireless Networking and Mobile Computing,” Chapman and Hall/CRC, 2005. [13] A. Boukerche, “Algorithms and Protocols for Wireless, Mobile Ad Hoc Networks,” John Wiley and Sons Inc, 2008. [14] A. Boukerche, K. Abrougui, and R.W. Pazzi, “An Efficient Hybrid Adaptive Location-aided Gateway Advertisement and Discovery Protocol for Heterogeneous Wireless and Mobile Networks,” in Globecom, 2009. [15] “The Network Simulator 2,” http://www.isi.edu/nsnam/ns/. [16] CJ Merlin and WB Heinzelman, “A study of safety applications in vehicular networks,” in Mobile Adhoc and Sensor Systems Conference, 2005. IEEE International Conference on, 2005, pp. 102–109. [17] C.J. Merlin and WB Heinzelman, “Highway Traffic Generator in C++,” Wireless Communications and Networking Group, available at www. ece. rochester. edu/research/wcng/code. html. [18] Adolf D. May, “Traffic Flow Fundamentals,” in Prentice Hall, 1990. [19] A. Raniwala and T. Chiueh, “Architecture and algorithms for an IEEE 802.11-based multi-channel wireless mesh network,” in Proceedings IEEE INFOCOM, 2005, vol. 3, pp. 2223–2234.