Cooperative download in vehicular environments.bak
1.
IEEE TRANSACTIONS ON MOBILE COMPUTING, VOL. 11, NO. 4, APRIL 2012 663 Cooperative Download in Vehicular Environments Oscar Trullols-Cruces, Student Member, IEEE, Marco Fiore, Member, IEEE, and Jose M. Barcelo-Ordinas, Member, IEEE Abstract—We consider a complex (i.e., nonlinear) road scenario where users aboard vehicles equipped with communication interfaces are interested in downloading large files from road-side Access Points (APs). We investigate the possibility of exploiting opportunistic encounters among mobile nodes so to augment the transfer rate experienced by vehicular downloaders. To that end, we devise solutions for the selection of carriers and data chunks at the APs, and evaluate them in real-world road topologies, under different AP deployment strategies. Through extensive simulations, we show that carry&forward transfers can significantly increase the download rate of vehicular users in urban/suburban environments, and that such a result holds throughout diverse mobility scenarios, AP placements and network loads. Index Terms—Vehicular networks, cooperative downloading, delay tolerant networking, carry&forward transmission. Ç1 INTRODUCTIONV EHICLES traveling within cities and along highways are technical reasons. We also assume that not all on-board regarded as most probable candidates for a complete users download large files all the time: indeed, one canintegration into mobile networks of the next generation. expect a behavior similar to that observed in wiredVehicle-to-infrastructure and vehicle-to-vehicle communi- networks, where the portion of queries for large contentscation could indeed foster a number of new applications of is small [1]. As a result, only a minor percentage of APs isnotable interest and critical importance, ranging from simultaneously involved in direct data transfers to down-danger warning to traffic congestion avoidance. It is, loader cars in their respective coverage area, and the http://ieeexploreprojects.blogspot.comhowever, easy to foresee that the availability of on board majority of APs is instead idle.communication capabilities will also determine a significant Within such a context, we study how opportunisticincrease in the number of mobile users regularly employing vehicle-to-vehicle communication can complement thebusiness and infotainment applications during their dis- infrastructure-based connectivity, so to speed up the down-placements. As a matter of fact, equipping vehicles with load process. We exploit the APs inactivity periods toWiMAX/LTE and/or WiFi capabilities would represent a transmit, to cars within range of idle APs, pieces of the dataclear invitation for passengers on cars or buses to behave being currently downloaded by other vehicles. Cars thatexactly as home-based network users. The phenomenon obtain information chunks this way can then transport the data in a carry&forward fashion [2], and deliver it to thewould thus affect not only lightweight services such as web destination vehicle, exploiting opportunistic contacts with it,browsing or e-mailing, but also resource-intensive ones as in Fig. 1. We remark that the concept of cooperativesuch as streaming or file sharing. download in vehicular networks has been already proposed In this paper, we focus on one of the latter tasks, namely for highway environments: however, unlike what happensthe download of large-sized files from the Internet. More over unidimensional highways, urban/suburban roadprecisely, we consider a urban scenario, where users aboard topologies present multiple route choices that make it hardcars can exploit roadside Access Points (APs) to access the to predict if vehicles will meet; moreover, the presence ofservers that host the desired contents. We consider that the traffic lights, stop and yield signs renders cars contactcoverage provided by the roadside APs is intermittent: this timings very variable. These key aspects make highway-is often the case, since, in presence of large urban, suburban, tailored solutions impracticable in complex nonlinear roadand rural areas, a pervasive deployment of APs dedicated scenarios, for which we are, to the best of our knowledge, theto vehicular access is often impractical, for economic and first to identify challenges and propose solutions. After a discussion of the literature, in Section 2, we outline. O. Trullols-Cruces and J.M. Barcelo-Ordinas are with the Departament the major challenges of vehicular cooperative download in d’Arquitectura de Computadors, Universitat Polite `cnica de Catalunya, urban environments and devise original solutions to them, in Mo `dul C6, Sala E208, Campus Nord UPC, Jordi Girona 1-3, Barcelona 08034, Spain. E-mail: {trullols, joseb}@ac.upc.edu. Section 3. In Section 4, we present the scenarios considered. M. Fiore is with the CITI Laboratory, INSA Lyon/INRIA, Bat. Chappe, for our performance evaluation, whose results are then 6 Avenue des Arts, Villeurbanne Cedex 69621, France. discussed in Section 5. Conclusions are drawn in Section 6. E-mail: marco.fiore@insa-lyon.fr.Manuscript received 2 Aug. 2010; revised 14 Feb. 2011; accepted 4 Mar. 2011;published online 29 Apr. 2011. 2 RELATED WORKFor information on obtaining reprints of this article, please send e-mail to:tmc@computer.org, and reference IEEECS Log Number TMC-2010-08-0362. The cooperative download of contents from users aboardDigital Object Identifier no. 10.1109/TMC.2011.100. vehicles has been first studied in [3], that introduced 1536-1233/12/$31.00 ß 2012 IEEE Published by the IEEE CS, CASS, ComSoc, IES, & SPS
2.
664 IEEE TRANSACTIONS ON MOBILE COMPUTING, VOL. 11, NO. 4, APRIL 2012 among vehicles, and in [19], for information dissemination purposes. However, the diverse goals in these works lead to in different approaches and results with respect to ours. More recently, the problem of AP placement to provide Internet access to vehicles has been addressed in [20], [21], and [22]. In all these works, however, the aim is to maximize vehicle-to-infrastructure coverage or contacts, and no cooperation among cars is considered.Fig. 1. Vehicle a downloads part of some content from AP A. The idle APB delegates another portion of the same content to a vehicle b. When bencounters a, vehicle-to-vehicle communication is employed to transfer 3 COOPERATIVE DOWNLOADto a the data carried by b. Let us first point out which are the major challenges in the realization of a vehicular cooperative download systemSPAWN, a protocol for the retrieval and sharing of contents within complex urban road environments. With reference tovehicular environments. SPAWN is designed for unidirec- the transfer model proposed in Section 1, we identify twotional traffic over a highway, and is built on the assumption main problems:that all on-road vehicles are active downloaders of a samecontent. Instead, we target urban environments where users . the selection of the carrier(s): contacts between cars inmay be interested in different contents. Similar considera- urban/suburban environments are not easily pre-tions hold for the works in [4] and [5]. dictable. Idle APs cannot randomly or inaccurately In [6], the highway scenario is replaced by a circular bus select vehicles to carry data chunks, or the latter risksroute within a campus, which, however, implies again to be never delivered to their destinations. Choosingeasily predictable vehicular contacts: indeed, the focus of the right carrier (s) for the right downloader vehiclethe work is on the prefetching and multihop transfer of data is a key issue in the scenarios we target;at each individual AP, while carry&forward communica- . the scheduling of the data chunks: determining whichtions are not taken into consideration. Conversely, Zhao parts of the content should be assigned to one orand Cao [7] and Yoon et al. [8] examine urban environ- multiple carriers, and choosing in particular the levelments. In [7], the authors study the upload of small-sized of redundancy in this assignment, plays a major rolecontents from vehicles to roadside gateways, rather than the in reducing the probability that destination vehicleslarge downloads we target. The work in [8] considers never receive portions of their files. http://ieeexploreprojects.blogspot.cominstead data transfers to vehicular users in grid-like road In the following, we first discuss the selection of carrierstopologies, but the focus is on the problem of optimizing at the APs, proposing to leverage historical informationdirect communications between cars and infrastructure, on large-scale traffic flows to drive data transferswithout taking into account cooperation among mobile decisions. Then, we outline several solutions to the chunkusers. Recently, the performance bounds of vehicular scheduling problem, that are characterized by differentcooperative download in urban scenarios have been studied levels of redundancy.in [9]: there, however, the authors assume perfect knowl-edge of the car traffic and outline a centralized optimal 3.1 Carriers Selectionsolution, rather than the distributed practical techniques we The first problem we address is that of the selection of dataenvisage in this work. chunk carriers at APs that are idle, i.e., that are currently not As far as opportunistic data exchange are concerned, the transferring data directly to vehicular downloaders. Aspotential of such a networking paradigm in vehicular previously discussed, these APs can opt to employ theirenvironments was first shown in [10], further explored in spare airtime to delegate, to mobile users within range,[11], [12], and exploited in [13], [14] among the others. portions of files being downloaded. Taking such a decisionHowever, most of these works focus on routing delay- means to answer to two questions: 1) which, among thetolerant information in vehicular networks, while none vehicles in range of an idle AP, should be picked as carriers, ifcopes with the problem of cooperative download. Also, any? and 2) which of the downloaders should these carrierstechniques for Medium Access Control [15] and network transport data for?coding [16] that have been proposed for cooperative The key to the answers is to know in advance whethervehicular download are orthogonal to the problems we (and possibly when) one or more cars currently withinaddress, and could complement the solutions outlined in coverage of an AP will meet a specific downloader vehicle,this paper. so to perform the selection that maximizes the download Finally, since we study the impact of the infrastructure rate. Also, by choosing carriers depending on their futuredeployment on the cooperative download, our work also contacts, the destination of the data becomes constrained torelates to the topic of AP placement in vehicular networks. the elected carriers, and the second question above isIn [17], the authors studied the impact of random AP inherently solved along with the first one. However,deployments on data routing in urban road topologies: we assuming that the roadside infrastructure has perfectwill prove that such an approach is inefficient when knowledge of the future route of each user is unrealistic,targeting cooperative download. More complex solutions other than raising privacy issues. At the same time, thefor the deployment of APs over road topologies have been movement of individual vehicles over urban road topologiesproposed in [18], to favor delay-tolerant data exchange cannot be easily predicted as in unidimensional highways.
3.
TRULLOLS-CRUCES ET AL.: COOPERATIVE DOWNLOAD IN VEHICULAR ENVIRONMENTS 665 We stress that such historical data refer to any two vehicles with movement patterns akin to those of b and a, and not to b and a only: thus, the data concerns vehicular flows rather than individual couples of cars. More formally, a contacts map is a set of one-to-one associations between keys, that encode the significant characteristics of two production phases, and values, that store the contacts properties for all couples of production phases that share such characteristics. The key for two generic production phases ph and pk is a vector Ikðph ; pk Þ Bb Aa Bb Aa of the formFig. 2. Notation for contacts map structure and construction. "À h Á À Á# " À h Á# " À k Á# t pBb À t pkAa pBb pAa A; ; ; ;We then adopt a probabilistic approach, by leveraging the t À h Á À Á#!fact that large-scale urban vehicular flows tend to follow v pBb À v pk Aa ;common movement patterns [23], [24], [25]. More precisely, vthe solution we propose leverages contacts maps, that are where , t, and v are the units (in degrees, seconds, andbuilt by exploiting historical data on contacts between car meters/second, respectively) used to discretize angles,flows, and then used to estimate the meeting probability times, and speeds. A couple of production phases is thusbetween downloaders and candidate data carriers. characterized by the identity of the AP involved in the3.1.1 Contacts Map second production phase, the time elapsed between the start of the two production phases, the direction of the twoWe denote as pk the kth production phase of vehicle a with Aa vehicles at the beginning of the respective productionrespect to AP A, i.e., the kth of the disjoint time intervals phases, and the difference between their speeds at thatduring which vehicle a can steadily download data from A same time. We remark that the identity of the other AP is[26]. From a specific AP perspective, we tag production not necessary: as detailed next, the first production phase isphases as local if they involve that particular AP: as an always a local one. A value is instead a vector of four fields:example, ph is a local production phase for AP B, 8 b; h. On Bb mthe other hand, we label as fab the mth forward phase of 1. nopps , the number of contact opportunities, i.e., the http://ieeexploreprojects.blogspot.com that the AP observed a couple ofvehicle b with respect to vehicle a, i.e., the mth of the number of timesdisjoint time intervals during which vehicle b can steadily production phases with characteristics as from theforward data to vehicle a. Note that production and associated key;forward phases do not necessarily correspond to actual 2. ncons , the number of actual contacts, i.e., the numberdata transfers, but just to contacts which could be exploited of times that vehicles from the aforementionedfor data transfers. We also use tðÁÞ to indicate the time at couples of production phases actually generated awhich a production or forward phase starts, and ÁtðÁÞ to tag forward phase;its duration. For production phases only, ðÁÞ denotes the 3. tdel , the average time elapsed between the start of thegeneral direction of movement1 of the vehicle at the last production phase and the start of the forwardbeginning of the production phase, and vðÁÞ its speed at phase, if any of the latter has ever occurred;that same time. The notation is summarized in Fig. 2. 4. tdur , the average duration of the forward phase, if Structure. A contacts map is a data structure that any has ever occurred.provides an AP with information on the probability of It is to be noticed that each AP builds its own contactscontact between a vehicle involved in a local production map, in which it stores only values associated with keysphase and another vehicle. With reference to the example in where the first production phase, as already said, is a localFig. 2, the contacts map at AP B allows B to know the one. As an example, an AP B will only store values for keysprobability of contact between the local vehicle b and the of the type Ikðph ; pk Þ, 8h; b; k; A; a. The rationale is that Bb Aageneric vehicle a. In particular, AP B knows that b started a local production phases represent the vehicle-to-infrastruc-local production phase ph at time tðph Þ, while moving ture contacts that an AP can exploit for carriers selection, Bb Bbwith direction ðph Þ and speed vðph Þ; also, let us assume B and are thus the only an AP is interested to record data for. Bb Bbhas been informed that a started a production phase pk Aa Construction. The steps for the construction of thewith AP A at time tðpk Þ, while moving with direction contacts map at an AP are best described by means of an Aaðpk Þ and speed vðpk Þ. Then, the contacts map at B allows example, so we consider once more the situation depicted in Aa Aato associate the couple of production phases ðph ; pk Þ to Fig. 2. When the production phase pk starts, the AP A logs Bb Aa Aahistorical data on the encounters between vehicles that have the time tðpk Þ, the relative vehicle identifier a, its general Aapreviously generated production phases at the two APs B direction ðpk Þ, and its current speed vðpk Þ. This informa- Aa Aaand A with timings and mobility similar to those of b and a. tion is shared, via the wired backbone, with other APs in the same area, and updated, when the production phase ends, 1. The general direction is obtained as the angle of movement between with the information on the duration Átðpk Þ. This way, Aathe location where the vehicle started its trip, and its current location. Thisrepresents a more reliable information than the instantaneous direction, and when the production phase pk terminates, AP B has Aait is not harder to obtain from a GPS receiver than the latter. memory of the event, including all related details. Similarly,
4.
666 IEEE TRANSACTIONS ON MOBILE COMPUTING, VOL. 11, NO. 4, APRIL 2012at the beginning of ph , B records and shares with other APs Bb Phases compatibility. Phases compatibility rules determineidentical information on the production phase, which is when two production phases generate an opportunity forthen updated at the end of ph . Bb cooperative download, as well as when a forward phase can Regarding the exchange of data among the APs, we represent a contact for a local production phase. These rulesemphasize that a generic AP does not need to be informed formally relate phases in a way that avoids inconsistenciesabout the vehicle-to-infrastructure contacts occurring at all in the resulting contacts maps, an event otherwise common,other APs in the network. Indeed, if two APs are too far especially when considering that phases often overlap inapart, they can avoid sharing production phase data, as the time and/or refer to a same AP (i.e., it can be that A and Bexcessive distance makes contacts too hard to predict and in all previous discussions are indeed the same AP). Weleads to unbounded carryforward transfer delays. Thus, first introduce the set of rules for the compatibility of a localin order to limit the traffic on the wired backbone and production phase with respect to a forward phase. A localguarantee system scalability, the reciprocal exchange of production phase ph is said to be compatible with a Bbinformation about production phases can be constrained to m 2 forward phase fab if the following conditions are verified:APs within limited geographical distance. Proceeding in our example, at the end of ph , AP B, as Bb 1. the forward phase has ended after the end of theevery other AP does at the end of its own local production local production phase, orphases, checks whether ph can be considered as an Bb À mÁ À mÁ À Á À Áopportunity for cooperative download with respect to other t fab þ Át fab t ph þ Át ph ; Bb Bbproduction phases it is aware of, i.e., if another production as b must receive the data from B before it canphase is compatible with ph . We will discuss production Bb forward them to a. Note that the position of thephases compatibility later in this section; for the moment, subscripts already implies that, for the phases to belet us assume that pk is compatible with ph . Then, B looks Aa Bbin its local contacts map for the value associated with key compatible, the same vehicle b must realize theIkðph ; pk Þ. If an entry is not found, it is created; in both production phase with B and be the potential carrier Bb Aacases, the nopps field in the entry is incremented. in the forward phase; Let us now assume that, later on, vehicle b meets vehicle 2. the forward phase is the first involving a and b and m ma, generating the forward phases fab and fba . We focus on satisfying rule 1 above to have terminated after thethe first one, as it is that of interest in our example. Both end of the local production phase, orvehicles record the forward phase start time tðfab Þ, as well m À nÁ À nÁ À h Á À h Áas the other vehicle identifier. Upon loss of contact, a and b 6 9n jt fab http://ieeexploreprojects.blogspot.com þ Át fab t pBb þ Át pBb ; À nÁ À mÁ m t fab t fab ;also log the forward phase duration Átðfab Þ. These samecars upload these information, together with similar data on which guarantees that at most one forward phase isall other forward phases they have experienced, to the next associated with each production phase;AP they encounter, which will again share them with the 3. the local production phase at B is the last, involvingAPs in the area. b and satisfying rule 1 above, that started before the m When AP B is notified of the forward phase fab , it tries to forward phase end, or munderstand if fab can be related to any of the opportunities À mÁ À mÁ À Á À Áit has previously recorded. Thus, B scans its database for 6 9n jt fab þ Át fab t pn þ Át pn ; Bb Bb m À Á À Álocal production phases compatible with fab ; once more, we t pn t ph ; Bb Bbwill discuss the compatibility between production andforward phases next. Assuming that ph satisfies the which guarantees that at most one production phase Bbcompatibility constraint, B then looks for production phases is associated with each forward phase.of vehicle a, with any AP, that are compatible with ph . B Bb Then, we introduce the rules that define the compat-finds again pk , and thus finally relates fab to the couple of ibility between two production phases. A production phase Aa mproduction phases ðph ; pk Þ. At this point, B retrieves the pk is said to be compatible with a local production phase Bb Aa Aavalue associated with the key Ikðph ; pk Þ, and updates the ph if the following conditions are verified: Bb Aa Bbncons , tdel , and tdur fields. The first is incremented by one, torecord that the opportunity previously stored actually 4. the first production phase has ended before the endgenerated a forward phase. The second and the third of the local production phase, orelements are updated using samples tðfab Þ À tðpBb Þ andm h À Á À Á À Á À Á m t ph þ Át ph t pk þ Át pk ; Bb Bb Aa AaÁtðfab Þ, respectively. The way these last updates areperformed depends on the desired level of detail on the which accounts for the fact that an AP can onlyvehicle-to-vehicle contact: in our case, we opted for keeping destine carryforward data to production phases ittrack of the mean of the samples. is aware of; 5. the first production phase has ended at most a time 2. A thorough study of the management of control messages over the T before the end of the local production phase, orbackbone of the infrastructured network is out of the scope of this paper. Inour tests, we imposed a maximum distance of 10 km among data-sharing À Á À Á À Á À ÁAPs, so to bound the delay between production and forward phases at t ph þ Át ph À t pk À Át pk Bb Bb Aa Aa T;approximately 15 minutes, given an average vehicular speed of 20 km/h inurban areas. that avoids considering obsolete production phases;
5.
TRULLOLS-CRUCES ET AL.: COOPERATIVE DOWNLOAD IN VEHICULAR ENVIRONMENTS 667Fig. 3. Example of phases compatibility. 6. the first production phase is the last, involving a and A as well as satisfying rules 1 and 2 above, to have ended before the end of the local production phase À Á À Á À Á À Á 6 9n j0 t ph þ Át ph À t pn À Át pn Bb Bb Aa Aa T; À n Á À k Á t pAa t pAa ; which guarantees that at most one production phase Fig. 4. Pseudocode for carriers selection at AP B. involving same vehicle/AP couple is associated with each local production phase. resulting from electing one (or some, or all) of the local Fig. 3 provides some examples of phases compatibility as vehicles as carrier (s) for data destined to a specificfrom the rules listed above. There, the first timeline depicts downloader vehicle a. The delivery potential is obtainedthe time intervals during which a vehicle a experiences as the sum of the individual contact probabilities p , pbproduction phases with APs A, C, and D, while the second derived from assigning data for the downloader a to eachtimeline reports the sequence of production phases of car b elected local carrier b.3 The process is repeated for eachwith APs B and E. Finally, the last timeline shows when known downloader car, and, in the end, the downloaderforward phases of b to a occur. vehicle associated with the highest delivery potential p isp Arrows from the second to the first timeline indicate chosen as the target of a carryforward transfer throughwhich production phases of a are compatible with those of http://ieeexploreprojects.blogspot.comb. As an example, p1 is not compatible with p1 because it local carriers that contributed to p Note that p is a potential p. p Aa Bb and not a probability: indeed, p can be higher than one to poccurred too early in time (i.e., it ended more than a time T counter uncertainties in probability estimates.before the end of p1 , see rule 5 above), while p2 is not Bb Aa 1 The framework for carriers selection run at a generic APcompatible with pBb because it is not yet concluded when 1 1 1 B is shown as pseudocode in Fig. 4. There, priority ispBb ends (rule 4). Similarly, pCa is not compatible with pBb always given to direct data transfers to downloader cars,since a more recent production phase between a and C, i.e., and fairness among them is provided by always picking thep2 , is compatible with p1 (rule 6). Conversely, p2 and p1 Ca Bb Ca Da vehicle that is the closest to the AP. The parameter IPminsatisfy all the compatibility conditions, and are thus controls the minimum delivery potential required tocompatible with p1 . Bb attempt cooperative download through local carriers. The Forward phase compatibilities are shown as arrows from 2 value of such parameter (line 01 in Fig. 4), together with thethe third to the second timeline. We can notice that fab is 2 1 1 way the delivery potential p k associated with the down- pAacompatible with pEb but not with pEb , since pEb is not the last loader production phase pk and its relative carriers list c k Aa Aa cproduction phase involving b and E to have ended before 2 2 2 are updated (lines 12 and 13 in Fig. 4), distinguish thethe end of fab (rule 3 above), while pEb is. Moreover, fab is following carriers selection algorithms.not compatible with p1 , because another forward phase of b Bb The Blind carriers selection algorithm aims at fullyto a, i.e., fab , already concluded after the end of p1 (rule 2). 1 Bb exploiting the airtime available at APs, by delivering data to3.1.2 Carriers Selection Algorithms all available local carriers whenever possible. This algo-Contacts maps can be exploited by APs to select local cars rithm does not make use of the contacts map, but randomlyas data carriers in the cooperative download process, by chooses a downloader car as the destination of the data: weretrieving their contact probability estimates with respect to thus employ it as a benchmark for the other schemes. Thedownloader vehicles. First, it is necessary that APs know pseudocode for potential and carriers list updating iswhich cars in their surroundings are interested in some outlined in Fig. 5, while IPmin is set to 0, so that cooperativecontent. Thus, every time a downloader vehicle starts a download is always attempted when at least one localproduction phase, the fact that it is requesting data, as well carrier is present.as the nature of the desired content, is attached to the usual The p-Driven carriers selection algorithm is a probabil-information on the production phase that the local AP ity-driven version of the Blind algorithm above. It againshares with other APs. This way, each AP can track tries to exploit as much as possible the APs wirelessdownloaders through their production phases history. 3. Thanks to the broadcast nature of the wireless channel, a single Thanks to such knowledge, an AP that has active local transmission is sufficient to transfer the same data to all elected localproduction phases can compute the delivery potential p a p carriers.
6.
668 IEEE TRANSACTIONS ON MOBILE COMPUTING, VOL. 11, NO. 4, APRIL 2012Fig. 5. Blind pseudocode for p k , c k update. pAa Aa c Fig. 7. p-Constrained pseudocode for p k , c k update. pAa Aa cFig. 6. p-Driven pseudocode for p k , c k update. pAa Aa cresources, but this time cooperative download destinationsare selected according to the delivery potential obtainedfrom the contacts map. As a matter of fact, carryforward data are consigned byeach AP to all available local vehicles, and destined to thedownloader vehicle which maximizes the sum of its contactprobabilities with all the local carriers, as detailed in thepseudocode of Fig. 6. We stress that noncompatibleproduction phases generate keys that are not present inthe contacts map, and are thus not considered forcooperative download. As the p-Driven algorithm isdesigned to exploit carryforward whenever there is aminimal chance of delivery, IPmin is set to 0: this allowscooperative download even in presence of very small http://ieeexploreprojects.blogspot.comdelivery potentials. Exploiting contacts maps, the p-Drivenscheme is, however, expected to be more precise than theBlind one in the selection of carriers. The p-Constrained carriers selection algorithm builds ontop of the p-Driven scheme, adding constraints on prob- Fig. 8. (p,t)-Constrained pseudocode for p k , c k update. pAa Aa cabilities, as from the pseudocode in Fig. 7. In particular,local vehicles with individual contact probability p b lower probability lower than IPind (lines 02 to 16 in Fig. 8). Every pthan IPind 0 are not considered for data carrying, and time the unprocessed local vehicle with maximum contactIPmin is set to a value higher than 0, so that downloader probability p pmax is processed, the algorithm exploitsvehicles with delivery potential p a lower than IPmin are information on the average time to contact (t ) and contact p deldiscarded. Thanks to the lower bounds on individual duration (t ) to predict the time interval during which the durprobability and delivery potential, the p-Constrained local vehicle will meet the downloader car a. Then, italgorithm is expected to further increase the delivery discretizes time with step T and tries to fit the estimated T,precision and reduce the load at APs with respect to the contact probability p pmax in one of the time steps within thep-Driven scheme. However, quality could come at cost of aforementioned time interval (lines 20 to 30 in Fig. 8).quantity, as the thresholds may hinder potentially success- The process is terminated when either the requiredful cooperation among vehicles. delivery potential IPmax has been reached (lines 31 to 33 in The (p,t)-Constrained carriers selection algorithm adds Fig. 8), or no more local vehicles are available (lines 17 to 19time constraints to the probability bounds of the p- in Fig. 8). In the second case, the delivery potentialConstrained scheme. It introduces a distributed database constraint is not fulfilled, as IPmin is higher than zero, andt a , maintained for each active downloader vehicle a by APs t thus no carriers can be selected for the current productionin a same area, controlling what portions of a’s airtime are 4 phase pk (see line 20 in Fig. 4). The (p,t)-Constrained Aaassigned to which specific carriers. As shown in the algorithm therefore employs information about contactpseudocode in Fig. 8, the (p,t)-Constrained algorithm times to improve the delivery precision, reducing the dataprocesses local vehicles b in decreasing order of contact carriers involved in the cooperative download.probability with the downloader car a, skipping those with 3.2 Chunk Scheduling 4. We recognize that maintaining such database can pose synchroniza-tion and consistency issues, whose management is out of the scope of this Upon selection of a destination for the carryforwardpaper. We however note that we do not require frequent updates or high transfer, jointly with the associated local carriers, an APaccuracy in a , since the update periodicity is in the order of seconds and t terrors in the database are overshadowed by inaccuracy in the contact must decide on which portion of the data the downloader isestimation. interested in is to be transferred to the carriers. To that end,
7.
TRULLOLS-CRUCES ET AL.: COOPERATIVE DOWNLOAD IN VEHICULAR ENVIRONMENTS 669Fig. 9. Flow diagrams of the (a) Global, (b) Hybrid, and (c) Local chunk scheduling algorithms.we assume that each content is divided into chunks, i.e., carryforward transfers. An AP can thus directly transfersmall portions of data that can be transferred as a single to a downloader within range chunks that were alreadyblock from the AP to the carriers, and then from the latter to scheduled, but through a carryforward delivery.the destination. Since a same chunk can be transferred by Namely, an AP can employ a direct transfer to aone or multiple APs to one or more carriers, the chunk downloader car to fill gaps in its chunk list. The Localscheduling problem yields a trade-off between the relia- scheduling is thus the most redundant among the schemesbility (i.e., the probability that a downloader will receive at we propose, trading some cooperative download potentialleast one copy of a chunk) and the redundancy (i.e., how for increased reliability in data delivery.many copies of a same chunk are carried around the roadtopology) of the data transfer. Next, we introduce threechunk scheduling schemes that embody growing levels of 4 EVALUATION SCENARIOSredundancy, and that are thus intended to provide In order to evaluate the cooperative download mechanismsincreasing communication reliability. outlined in the previous sections, we consider several large- The Global chunk scheduling assumes that APs scale vehicular traffic scenarios, that are representative ofmaintain per-vehicle distributed chunk databases, similar real-world road topologies. We also take into accountto the time databases a introduced before.5 These different deployments of APs, that, as we will show, have t tdatabases store information on which chunks have already a major impact on the download performance.been scheduled for either direct or carryforward delivery 4.1 Vehicular Mobilityto each downloader. The Global scheme, whose flow diagram is depicted in We selected real-world road topologies from the area ofFig. 9a, completely distributes the chunk scheduling among Zurich, Switzerland, to assess the performance of theAPs, since it forces an AP to pick a new, unscheduled chunk cooperative download solutions presented in the previousevery time it performs a direct or carryforward transfer. In sections. This choice was mainly driven by the availability http://ieeexploreprojects.blogspot.comother words, each chunk is scheduled for transfer just once of large-scale microscopic-level traces of the vehicularin the entire network. We stress that, even then, multiple mobility in the region, from the CS Department of ETHcarriers can be given the same chunk, as carriers selection Zurich [27]. The simulation techniques and mobility modelsalgorithms can (and usually do) identify more than one employed to generate the traces allow to reproducevehicle for a single carryforward transfer. vehicular movements over very large road topologies, yet The Hybrid chunk scheduling, in Fig. 9b, allows over- with a good degree of precision [28]. More precisely, thelapping between carryforward transfers scheduled by traces replicate macroscopic patterns of real-world vehicu-different APs. Indeed, in case of a data transfer to carriers, lar traffic flows, made up of thousand of cars, as well asan AP picks the first chunk that it has not yet scheduled, microscopic behaviors of individual drivers in urbanignoring the carryforward scheduling at the other APs. environments, such as pauses at intersections that dependConversely, nonoverlapping scheduling is still enforced for on roads capacity and congestion. This macro- anddirect chunk transfers: every time it has to deliver some micromobility realism is important in our study, since, onportion of a content to a downloader, an AP always selects a the one hand, we exploit large-scale properties of urbannew chunk, not yet scheduled by any other AP in the vehicular mobility in designing the cooperative downloadregion. The Hybrid scheme is thus implicitly more system, and, on the other, realistic small-scale mobility isredundant than the Global one, as different APs indepen- required to reproduce vehicle-to-vehicle and vehicle-to-APdently delegate carriers for a same data chunk. Also, note networking interactions. We stress that the mobility tracesthat the Hybrid scheme does not need the aforementioned we employed only reproduce important traffic arteries inper-vehicle chunk databases. As a matter of fact, it each scenario, while they do not consider movements overcommends that overlapping is avoided only for direct minor streets. This, however, does not impact our study,transfers, that, however, occur during contacts between APs since the traffic over minor roads is too sporadic to deserveand the downloader vehicle: as a consequence, the chunk the deployment of dedicated APs, and does not providescheduling history can be easily maintained at vehicles, and significant opportunities for collaboration among vehicles.communicated to the current AP at the beginning of the We focused on four scenarios, representing urban,local production phase. suburban, and rural areas within and nearby the city of The Local chunk scheduling is similar to the Hybrid Zurich. All the areas considered cover surfaces between 15 2scheme, since different APs can schedule the same chunks and 20 km , and frame several tens of kilometers of majorwhen delegating data to carriers. However, as shown in roads, whose layouts are shown in Fig. 10. In particular, theFig. 9c, it also allows overlapping between direct and Central Zurich scenario reproduces the downtown of Zurich, and it is thus characterized by dense traffic 5. The same observations on database maintenance apply here as well. uniformly distributed over the road layout. The West and
8.
670 IEEE TRANSACTIONS ON MOBILE COMPUTING, VOL. 11, NO. 4, APRIL 2012Fig. 10. The road topologies considered in our study, representing urban (b), suburban (a, c), and rural (d) areas in the canton of Zurich, Switzerland.North Zurich scenarios are representative of suburban through the road topology. Since the identity of down-areas, where the traffic congestion is less evident than in the loaders cannot be known in advance, the best option is tocity center, but still present over a few major freeways that deploy APs at those locations that a generic vehicle willattract most of the vehicular mobility. Finally, the Schlieren most probably visit along its route, i.e., the most congestedscenario portrays the street topology around a town not far intersections.from Zurich, characterized by a sparse presence of vehicles The Cross volume-based AP placement is designed toover most roads in the area. favor carryforward transfers, by increasing the potential for collaboration among vehicles. This technique exploits4.2 AP Deployment the predictability of large-scale urban vehicular trafficThe placement of APs over the urban road topology has a flows, which are known to follow common mobilitymajor influence on the cooperative download architecture. patterns over a road topology [23], [24], [25]. By studyingIn order to capture such an effect, we extend our analysis by such traffic dynamics, it is possible to determine the wayconsidering diverse AP deployments over the different road vehicular flows spread over the streets layout and employtopologies presented above. The goal of all the deployment this information to guide the AP placement. In thestrategies is to position, along a road topology, a given remainder of this section, we introduce the concept of crossnumber N of APs; in our performance evaluation, we will volume and employ it to determine the relative APdiscuss the impact of the value of N as well. deployment strategy. Under the Random AP positioning scheme, each point Let us imagine that the road topology is representedof the road topology has the same probability of being by a graph where vertices are mapped to intersections http://ieeexploreprojects.blogspot.comselected for the deployment of an AP. The resulting and edges to streets connecting them, as in Fig. 11. Theplacement may be considered representative of a comple- graph is undirected, and an edge exists even if thetely unplanned infrastructure [29], [30], and it is used in our corresponding road is one-way. Focusing on a particularperformance evaluation as a baseline for the other deploy- edge i of the graph, we can track all traffic leaving such 6ment techniques. We emphasize that the results we will edge, in both directions, and draw a map of howpresent for the Random positioning scheme were obtained vehicular flows (measured in vehicles/s) from i unfoldby generating different deployments at each simulation over the road topology. We refer to these flows as therun, so to avoid biases due to more or less favorable vehicular flows generated at i. As an example, in Fig. 11,random AP distributions. the dark gray arrows depict flows generated at edge i. The Density-based AP deployment technique aims at Different flows have different size, in vehicles/s, repre-maximizing the probability of direct data transfers from sented by their associated number (values in the exampleAPs to downloader vehicles. To that end, this techniques are only illustrative).places the APs at those crossroads where the traffic is Let us now consider a generic edge k 6¼ i, and isolate thedenser. The rationale behind such choice is that the volume flows passing in strict sequence through i and k. In thisof direct downloads is proportional to the number of APs case, we distinguish the two directions of movement over k,that a downloader vehicle encounters during its movement and define two traversing flows from i to k: ! . fik , the vehicular flow generated at i and subsequently traversing k in the ! direction; . fik , the vehicular flow generated at i and subse- quently traversing k in the direction. We do not impose any rule in defining the two directions at k, which, e.g., could be based on vertices numbering or geographical coordinates. Our only concern is that, for each edge, the two directions are unambiguously identified. Also, the direction at i is not specified, and a traversing flow could have visited its generating edge in any directionFig. 11. Sample vehicular flows over a road topology graph. Flowsgenerated at edge i are dark gray, while those generated at j are light 6. Note that we do not make any assumption on the origin of the traffic,gray. Assuming a travel time ¼ 1 at all edges, the partial cross volume that could thus be constituted of vehicles that started their trip from anhk is equal to minf6; 4g þ minf0; 0g ¼ 4, while the crossing volume hij ij intermediate point of the road, or that had previously arrived from ais 4 þ 3 ¼ 7. different road.
9.
TRULLOLS-CRUCES ET AL.: COOPERATIVE DOWNLOAD IN VEHICULAR ENVIRONMENTS 671(including both of them, if flows generated at i in opposite Finally, the concept of cross volume can be unbounddirections then merge at k in the same direction). from intermediate edges and related to couples of roads Traversing flows at an edge k can be translated to only. If I is the set of edges in the road topology graph, wetraversing volumes (measured in vehicles), by evaluating define the cross volume of i and j asthe average time vehicles spend to travel over the entire P kroad segment corresponding to edge k. Also in this case, we hij ¼ k2I hij ; if i 6¼ j; ð1Þcan distinguish the two directions of movement, and define 0; otherwise; !the two travel times tk and tk , in the ! and in the which implies that hij ¼ hji ! 0, 8i; j 2 I. The cross volumedirections, respectively. Considering again traversing flows hij provides a measure of the potential for contact, and thusfrom i, the two corresponding traversing volumes are cooperation, over the entire road network, among vehicles ! ¼ ! Á !; vik fik tk vik ¼ fik Á tk ; leaving edges i and j. We can exploit such a measure to formalize the problem of the AP deployment. Let us assumeand represent the average number of vehicles that, having that there are jI j N roads in the topology: the problemalready visited i during their trip, travel over k in the ! and becomes that of picking N out of the jI j edges of the graph direction, respectively. for AP deployment. We associate with each edge i a binary Let us now introduce a second group of flows, generated decision variable xiat an edge j 6¼ i, depicted in light gray in Fig. 11. The same consideration we made for flows generated at i are valid, 1; if an AP is deployed on the road mapped to i; xi ¼and, picked an edge k 6¼ j, we can compute the traversing 0; otherwise;volumes from j to k, ! and vjk . By considering both sets vjk and refer to their vector as x ¼ fx1 ; . . . ; xjI j g. Sinceof flows at once, we can define the partial cross volume of i opportunities for cooperation between vehicles are propor-and j at k, as tional to the crossing volume between each couple of È É È É min !; vjk þ min vik ; ! ; if k 6¼ i; k 6¼ j; vik vjk edges, the APs should be positioned so to maximize the hk ¼ ij sum of crossing volumes between each pair of APs over 0; otherwise: the whole road topology. This leads to the formulation of The partial cross volume hk corresponds to the amount ij the following mixed-integer quadratic programmingof traffic from i and j that merges at edge k. We notice that (MIQP) problem:hk only couples flows that travel on opposite directions ijover k, hence the name of partial crosshttp://ieeexploreprojects.blogspot.com volume. The rationale 1 max fðxÞ ¼ x0 Hx; ð2Þis the following: imagine one car that has visited edge i in x 2its trip, and now enters edge k in the ! direction: such a !car thus belongs to the fik flow. Considering vehicles that s:t: xi 2 f0; 1g; 8i 2 I; ð3Þcome from edge j and now travel over k, our car can Xgenerate two types of contacts: xi N: ð4Þ . with the vjk vehicles that travel in the opposite i2I direction. These contacts are certain, since u-turn are Here, that in (2) is the objective function to be not allowed on road segments connecting two maximized, with H ¼ fhij g being a jI j Â jI j matrix in IR, adjacent intersections; filled with the crossing volumes computed for each couple . with the ! vehicles that travel in the same of edges as in (1). Also, (3) states that xi is a binary variable, vjk direction. However, contacts are not certain in this 8i 2 I, whereas (4) bounds the overall number of APs to be case: the relative speed is close to zero7and contacts deployed to N. mostly depend on the position of the ! vehicles vjk By solving the optimization problem, we obtain an AP over k, when our car enters the road segment. deployment that, as originally stated, augments the Indeed, even if it enters edge k while some of the ! opportunities for carryforward transfers in the download vjk vehicles are nearby, and thus generates contacts with process. We note that this formulation solves the AP them, our car will only meet that very small fraction deployment problem from a large-scale viewpoint, i.e., it of the overall ! vehicles. vjk allows to determine the roads where APs should be Since there are ! cars such as the one considered positioned. However, it does not specifies the exact location vikabove, we couple ! with vjk , as these volumes corre- of each AP over the selected roads. In Section 5.2, we will vik spond to certain contacts, while we do not couple ! with show that such small-scale deployment has a negligible vik!, as these volumes have an unpredictable (and, in most impact on the performance of the system. vjkcases, negligible) contribution in terms of contacts. Such acoupling is performed by taking the minimum between thetwo facing traffic volumes, which is that imposing a more 5 PERFORMANCE EVALUATIONstrict constraint on the number of encounters. We conducted an extensive simulation campaign aimed at evaluating multiple aspects of cooperative download in 7. In the urban, suburban, and rural scenarios we consider, the low speed nonhighway vehicular networks. The computational com-limits and the reduced number of lanes hinder overtakings. This is provedby the fact that, in the scenarios in Section 4.1, we observed, on average, less plexity of the simulations, that reproduce the movementthan one overtaking per vehicle and per trip. and network traffic of several thousands of vehicles at a
10.
672 IEEE TRANSACTIONS ON MOBILE COMPUTING, VOL. 11, NO. 4, APRIL 2012time, prevented the use of a traditional network simulator,such as ns-2. Instead, we developed a dedicated simulator[31], which employs the mobility extracted from the Zurichtraces, models a random access channel contention, andimplements all the cooperative download techniquespreviously presented, but replaces the traditional packet-level simulation with a more scalable chunk-level one,avoiding the detailed reproduction of the entire networkstack at each node. In all our tests, a “best case” performance reference isprovided by an Oracle carriers selection algorithm. TheOracle scheme assumes that APs have a perfect knowledgeof the future trajectories of all vehicles, in terms of bothroutes and timings. This information is exploited duringproduction phases at APs to foresee contacts between localand downloader vehicles, and thus to pick carriers that arecertain to later meet their target downloader vehicle. TheOracle scheme exploits a per-downloader database, iden- Fig. 12. Average cooperative download rate (top) and undeliverytical to that employed in the (p,t)-Constrained algorithm, to ratio (bottom) for different carriers selection schemes, in the fouravoid that multiple carryforward transfers are scheduled road topologies.at a same time for the same downloader vehicle. Also, sincevehicular contacts are known in advance, any redundancy train the framework (i.e., gather the data necessary toin the scheduling of chunks is pointless: thus, only one deploy the APs and to build the contacts map at each APs),carrier can be selected for the transfer of each carryfor- and 10 runs to collect statistics. Each run simulated aroundward chunk, and we always couple the Oracle algorithm 3 hours of urban traffic, encompassing various vehicularwith the nonredundant Global chunk scheduling. Note that density conditions. For all results we measured 99 percentthe Oracle carriers selection algorithm is not optimal in that confidence intervals, reported as error bars in the plots.it does not take into account that multiple carryforward 5.1 Carriers Selection and Chunk Schedulingtransfers can be scheduled at the same time for different We first analyze the different carriers selection algorithmsdownloaders that are within transmission range of each http://ieeexploreprojects.blogspot.com techniques, detailed in Sections 3.1other. In such situation, since only one of the interfering and chunk schedulingdownloaders can receive its chunks, part of the data cannot and 3.2. Since we are interested in a comparative evaluationbe delivered to the second downloader. of the all these schemes, we select a particular AP The main metrics we are interested in evaluating are: deployment scenario (6 APs positioned according to the Cross volume-based strategy), and focus on the carryfor- . the download rate, i.e., the average file transfer speed ward download performance (as direct downloads are not experienced by downloader vehicles traveling influenced by they way we select carriers or chunks). We through the scenario. Such rate is the aggregate of will consider different AP deployments, and study their a direct rate, due to direct data downloads from APs, impact on direct download rates in Section 5.2. and a cooperative rate, due to carryforward trans- The average cooperative download rate, obtained from fers. According to our simulation settings, listed carryforward transfers, and the mean undelivery ratio are next, the maximum download rate achievable by a depicted in Fig. 12. There, we report the results obtained vehicular user is 5 Mbps, which corresponds to the under each road scenario by the different carrier selection case of a car continuously receiving data during its scheme, when coupled with a Global chunk scheduling. We whole trip through the simulation scenario; can notice how the Blind, p-Driven, p-Constrained, and . the undelivered chunk ratio, i.e., the average ratio of (p,t)-Constrained algorithms yield, in this order and chunks that are not delivered to a downloader vehicle, throughout all road scenarios, decreasing cooperative rates, computed over all those scheduled for that vehicle. as well as reduced undelivery ratios. Indeed, increasing the The system parameters were set for all simulations to precision of carryforward transfers also implies missingt ¼ 5s, ¼ 45 , v ¼ 5 m , T ¼ 500 s, T ¼ 1 s, IPmin ¼ 2:5, opportunities for vehicle-to-vehicle data exchanges. s TIPind ¼ 0:5. If not stated otherwise, an average of 10 The exact balance in the trade-off between thedownloader cars is present at the same time over the road cooperative download rate and the delivery precisiontopology, and a simple disc model is considered for signal varies with the road scenario. In suburban areas (West andpropagation, so to fulfill the low-complexity constraints North Zurich), a few major freeways attract most of theimposed by the size of the simulations. The net application- traffic in the region. On the one hand, such concentrationlevel data transmission rate over the wireless channel, results in a large number of vehicle-to-vehicle contacts,during both production and forward phases, is assumed and thus in higher cooperative rates with respect to otherequal to 5 Mbps for a transmission range of 100 m. The scenarios. On the other hand, it favors inaccurate carrierslatter values are consistent with the outcome of real-world selection algorithms, such as the Blind one, over moreexperiments on car-to-infrastructure [32] and car-to-car data precise schemes, such as the p-Driven and p-Constrainedtransfers [33]. For each simulation, we performed one run to ones: as a matter of fact, even randomly selected cars have
11.
TRULLOLS-CRUCES ET AL.: COOPERATIVE DOWNLOAD IN VEHICULAR ENVIRONMENTS 673Fig. 13. Average AP load (top) and number of carriers ferrying a same Fig. 14. Average cooperative download rate (top) and undeliverychunk (bottom) for different carriers selection schemes, in the four ratio (bottom) for different chunk scheduling algorithms, under theroad topologies. diverse carriers selection schemes. Results are averaged over all road topologies.a high probability of traveling on the same road, and thusto meet each other. In the rural Schlieren scenario, the mobility scenarios were observed also in this case. As asparsity of traffic leads to reduced car-to-car contacts and general comment, the increased redundancy introducedthus lower cooperative rates. Also, the higher heterogene- by the Hybrid and Local chunk scheduling leads, as oneity in the movement of vehicles, due to the absence of could expect, to lower cooperative rates but increasedtraffic-gathering roadways, makes the Blind scheme delivery precision. On a per-carriers selection algorithmextremely imprecise in delivering chunks, with respect to basis, however, differences can be spotted. In particular,contact map-based ones. Finally, the urban Central Zurich the Blind scheme suffers a dramatic 50 percent reductionscenario presents traffic densities that are similar to those in the cooperative rate when redundancy is increased in http://ieeexploreprojects.blogspot.comobservable in the suburban areas, but dynamics that are the chunk scheduling: indeed, scheduling multiple timescloser to those of the rural case: such scenario thus yield the same chunks impairs the major strength of the Blindhigh-cooperative rates but undelivery ratios that signifi- algorithm, i.e., the sheer number of unique chunks sentcantly vary under the diverse algorithms. out for randomly selected downloaders. Conversely, when However, we can notice that, no matter the road coupled with more redundant chunk schedulings, thescenario considered, the (p,t)-Constrained carriers selection algorithms based on contact maps enjoy a significantalgorithm significantly outperforms all the other solutions reduction in the undelivery ratio (from 35 to 65 percent,in terms of undelivery ratio. Indeed, the precision achieved depending on the algorithm) at some smaller cost (15 toby the (p,t)-Constrained algorithm in the carryforward 30 percent) in terms of cooperative rate.chunk delivery is comparable to that of the Oracle To conclude our analysis on carriers selection and chunkalgorithm. Although this latter scheme attains higher scheduling, we summarize the results in Fig. 15, showingcooperative rates, we can state that the overall performance the working points of each technique in the download rate/of the (p,t)-Constrained algorithm is not too far from that undelivery ratio space. The results, aggregated over all roadobtained through a perfect knowledge of future contacts topologies, evidence the trade-off between the downloadamong vehicles. volume and the reliability of the cooperative process. In In Fig. 13, we also report, for the same combinations ofcarriers selection algorithms and road scenarios, theaverage load measured at the APs, i.e., the percentage ofairtime used by an AP to transfer data to carriers, and themean number of carriers ferrying a same chunk to a targetdownloader. From the plots it is clear how more precisealgorithms result in a lower AP load and a smaller numberof carriers per chunk. In other words, a higher precision inthe carryforward delivery of chunks yields a lower chargeon the infrastructure and a reduced demand of resources bycooperating vehicles. The different chunk scheduling schemes are thencompared, in combination with every carriers selectionalgorithm, in Fig. 14. For the sake of brevity, the results Fig. 15. Cooperative download rate/undelivery ratio working points for different carriers selection schemes (left, with Global chunk scheduling)are aggregated over all four road topologies: indeed, the and chunk scheduling algorithms (right, with (p,t)-Constrained carrierssame behaviors we previously discussed for the diverse selection). Results are averaged over all road topologies.
12.
674 IEEE TRANSACTIONS ON MOBILE COMPUTING, VOL. 11, NO. 4, APRIL 2012Fig. 16. Download rates and undelivered chunks ratios for different road-level placement policies, averaged over all road topologies.particular, the nonlinear distribution of the working points,evidenced by the gray curves in the plot, seem to indicatethe (p,t)-Constrained carriers selection with Global chunkscheduling as the combination that better adapts to thedifferent scenarios.5.2 Impact of the AP Deployment Fig. 17. Average download rates (top) and undelivery ratio (bottom) forThe way the infrastructure is deployed can have a different AP deployment strategies, in the four road topologies. Resultssignificant impact on the performance of the cooperative refer to the (p,t)-Constrained carriers selection scheme.download framework. Thus, in this section, we evaluatehow the strategy employed for the AP placement and the ratio, which is comparable to that obtained under othernumber of fixed stations influence the rates and undelivery deployments. Conversely, the Density-based and the Cross volume-based AP placement lead to similar aggregate rates:ratios experienced by the downloader vehicles. In the light however, in the former the contribution of direct transfers isof the results in the previous section, we consider in the significantly larger than in the latter, that instead mainlyfollowing a (p,t)-Constrained carriers selection with Global leverages the cooperation among vehicles. Such result isscheduling as our default configuration. consistent with the objectives of the two strategies, that try to We initially demonstrate the negligible impact of the maximize, respectively, vehicle-to-infrastructure and vehi-small-scale deployment of APs under the Cross volume- cle-to-vehicle contacts. Interestingly, the Density-basedbased strategy outlined in Section http://ieeexploreprojects.blogspot.com 4.2. To that end, we strategy yields slightly higher undelivery ratios with respectcompare three policies for the placement of APs over the to the other deployments: as already discussed, deployingroads resulting from the optimization problem. The middle APs at intersections renders many opportunistic contactspolicy places an AP equidistant from the intersections that among vehicles unusable for planned data exchanges, anend the selected road segment, the intersection policy effect here exacerbated by the high densities of the junctionsdeploys an AP at the most crowded of such intersections, selected by the Density-based deployment.while the random policy picks a random location over the Focusing on the proportion between direct and coopera-selected road segment. Fig. 16 shows that the relevance of tive rates, we can observe that, depending on the roadroad-level deployment is minimal, as the three schemes topology and deployment scenario, the carryforwardachieve almost identical download rate and undelivered contribution typically varies between 35 and 60 percent ofchunk ratio. The only notable difference is in that the the total download rate, implying a remarkable 50 tointersection strategy favors direct downloads and penalizes 120 percent speedup in the download. As far as the roadcooperative ones: indeed, crossroads are characterized by topologies are concerned, the same considerations made inhigh densities of slow vehicles, and placing APs there the previous sections hold for the overall rates andfavors AP-to-vehicle transfers. At the same time, however, undelivery ratios. Moreover, different scenarios do notit deprives vehicles of transfer opportunities, since inter- appear to induce significant differences in the relativesections also represent network clustering points where car- performance of each deployment, nor in terms of theto-car contacts occur frequently [34], thus reducing the proportion between direct and cooperative rates.cooperative download rate. We thus consider APs to be One may wonder how different AP placements affectdeployed at the intermediate point of road segments, as this carriers selection algorithms other than the (p,t)-Con-appears to bring a slight advantage over the other policies strained one. In Fig. 18, we can observe that the strategyin terms of aggregate rate. adopted in the deployment of the infrastructure has a very The different AP deployment strategies discussed in similar influence on all the algorithms. The cooperativeSection 4.2 are compared in Fig. 17, in presence of six APs rates achieved by the diverse schemes are consistent withdeployed in each road scenario. It is clear that a Random AP those presented in the previous section, and thus have andeployment results in the worst performance, as both the even higher impact on the aggregate rate, with respect todirect rate, i.e., the portion of the total download rate due to the case of the (p,t)-Constrained algorithm studied above.chunks directly retrieved from APs, and the cooperative Such an improvement comes, however, at a high cost inrate, resulting instead from carryforward transfers, are terms of undelivered chunks, with the exception of thelower than in the other strategies. The reduced aggregate Oracle scheme, which is clearly favored by its preemptiverate does not even bring an advantage in terms of undelivery knowledge of future contacts.
13.
TRULLOLS-CRUCES ET AL.: COOPERATIVE DOWNLOAD IN VEHICULAR ENVIRONMENTS 675 Fig. 20. Average download rates and undelivery ratio for a varying number of concurrent downloaders and 10 APs. Results refer to the (p,t)-Constrained carriers selection scheme and are averaged over all road topologies. placement strategy struggles to find new locations that guarantee an increase in the crossing volumes, and thus picks positions that introduce very small gain in theFig. 18. Average download rates (top) and undelivery ratio (bottom) for download process. That is, the same reasoning made fordifferent AP deployment strategies, under the diverse carriers selection the Density-based deployment holds, exacerbated, in thealgorithms. Results are averaged over all road topologies. Cross volume-based case. Finally, it is interesting to note that, under all deploy- Not only the position, but also the number of the APs can ments, as the number of APs grows the ratio between directimpact the performance of the vehicular cooperative down- and cooperative rates is either unchanged or slightly shiftedload. In Fig. 19, we vary the number of APs deployed in in favor of the latter. Moreover, the undelivery ratioeach scenario, and show the average rates and undelivery remains constant. Thus, we can conclude that the positiveratio attained under the three AP placement strategies. impact of carryforward transfers on the download processUnder a Random deployment, both direct and cooperative persists as the number of APs deployed on the roadrates significantly increase as the infrastructure becomes topology varies.more pervasive. Additional APs imply a higher number ofdirect transfer opportunities for the downloaders, which 5.3 Scalability in the Number of Downloaders http://ieeexploreprojects.blogspot.comexplains the improved direct rate. Similarly, denser APs are We evaluate the scalability of the cooperative downloaddeployed closer to each other, making forward phases (i.e., framework by increasing the number of downloaderscontacts among vehicles) closer in time to production concurrently traveling over each scenario, up to 50. Thisphases (i.e., contacts between vehicles and APs) and thus last value corresponds to a stressed network, where theeasier to predict. vehicles actively downloading large-sized contents from The same behavior can be observed for the Density- the Internet jointly cover around one third of the wholebased strategy, which, however, shows a slower rates road surface with their transmission ranges. Such agrowth for high numbers of APs. This is explained by the condition creates a significative contention for the channel,fact that, while in the Random deployment each new AP since it is very probable for two downloaders to interferehas a similar impact on the download process, in the with each other, and thus impairs both direct andDensity-based case additional APs are located at intersec- cooperative download.tions characterized by decreasing vehicular densities. This notwithstanding, in Fig. 20 we can observe that theTherefore, the rate gain brought by the presence of extra system scales quite well, as each of 50 simultaneous usersAPs tends to be lower and lower. In the case of APs experiences an average aggregate rate that is only one halfpositioned according the Cross volume-based policy, the of the rate enjoyed by a lone downloader. We can alsorates increase is significantly lower than in the other cases. notice that cooperative transfers are affected more signifi-As a matter of fact, the optimization problem behind this cantly than direct ones: since direct transfers always have aFig. 19. Average download rates and undelivery ratio for a varying number of APs, under the diverse deployment strategies. Results refer to the (p,t)-Constrained carriers selection scheme and are averaged over all road topologies.
14.
676 IEEE TRANSACTIONS ON MOBILE COMPUTING, VOL. 11, NO. 4, APRIL 2012Fig. 21. PDF of the aggregate download rate for a varying number of Fig. 22. Scatterplot of the downloaded size versus the trip duration.concurrent downloaders (left, for the Density-based deployment) and Results refer to the (p,t)-Constrained carriers selection scheme inassociated fairness (right). Results refer to the (p,t)-Constrained presence of 10 APs, and are averaged over all road topologies.carriers selection scheme in presence of 10 APs, and are averagedover all road topologies.higher priority over carryforward ones, the increasingpresence of direct downloaders reduces the airtime thatAPs can dedicate to carriers, thus limiting the exploitationof the latter paradigm. The undelivery chunk ratio isinstead positively affected by the downloaders’ density: byincreasing the spectrum of targets, it is easier for the APs tofind one downloader that will encounter the local carrierswith high probability.5.4 Per-Downloader Performance AnalysisOne legitimate question at this point would be if theseaverage figures are representative of the experience of everydownloader. By looking at Fig. 21a, the answer seems to beno. Indeed, the cumulative distribution of the aggregate http://ieeexploreprojects.blogspot.comdownload rate shows a significative unfairness amongdownloaders: as an example, in presence of a Density-basedAP deployment8 and 10 concurrent downloaders, the leastfortunate 30 percent of the downloaders gets a goodput ofat most 700 Kbps, while the top 30 percent can retrieve thedesired content at a rate that is at least four times higher. To Fig. 23. Extract of per-route analysis results, referring to the Density-better capture such unfairness, in Fig. 21b we portray the based AP deployment in North Zurich (top) and to theboth cases, we based AP deployment in Central Zurich (bottom): in Cross volume-Jain’s fairness index associated with the distributions of report the average direct and cooperative rates over the possibleFig. 21a. We can notice that the index ranges between 0.5 vehicular trajectories, that are ordered by decreasing aggregate rateand 0.7, i.e., low values that confirm the scarce equity with (left), and the download rates over the road topology, where darker and thicker lines represent road segments with higher aggregate rates. Allwhich the overall download rate is distributed among results refer to the (p,t)-Constrained carriers selection scheme indownloaders. The number of concurrent downloaders presence of 10 APs.appears instead to have a minor impact on the fairness, asit only induces a slight reduction of the index. download sizes. Our conclusion is that the duration of the In order to understand the reason of the diverse trip is not the cause behind the unfairness observed in thedownload experience of the different users, we first observe download performance of different users.if there is a correlation between the amount of downloaded We then increase the level of detail of our analysis, anddata and the duration of the trip of a vehicle, intended as consider not just the duration of a trip, but its exactthe interval between the instants at which the car enters and trajectory. More precisely, we record all the possible routesexits the road scenario. The relative scatterplots are (i.e., ordered sequences of roads) traveled by downloaders,depicted in Fig. 22, where we also report the line and measure the average download rates experienced byrepresenting the maximum downloadable file size per trip users on each route. Figs. 23a and 23c show, for two samplelength, computed as the 5 Mbps data rate times the trip scenarios,9 the direct and cooperative rate attained byduration. Interestingly, we can observe that download sizes vehicles traveling along the different routes, that areclose to the maximum are attained by vehicles with short as ordered over the x-axis, by decreasing aggregate downloadwell as long trips. Moreover, downloaders engaged in rate. It appears now clear that the unfairness amongmedium-to-long trips can have very different download downloaders is the result of an unfairness among trajec-experiences, resulting in both very high and very low tories, as some routes allow average rates of 3 Mbps or 8. Similar results were obtained under the Cross volume-based 9. Similar results, omitted for the sake of brevity, were obtained for alldeployment. others combinations of AP deployment strategies and road topologies.
Clipping is a handy way to collect and organize the most important slides from a presentation. You can keep your great finds in clipboards organized around topics.
Be the first to comment